caxapa.ru :: Баг в GCC, а не в Clang и вообще совершенно про противоположное, мол нет оптимизации. Остального не понял -- научись выражать мысли на понятном языке. Гудвин не прав, т.к. при использовании стандартных же любых конструкций языка (без упакованных структур) "баг" воспроизвести невозможно. А то, что он воспроизводится при использовании упакованных структур совершенно естесственно, и кстати в баге gcc есть на это комментарий (см. ссылку) -- вот так проблему можно обойти. Какие

fk0, легенда (24.07.2020 16:56, просмотров: 822) ответил RxTx на Ты написал в прошлом сообщении (цитирую твои слова): "а с некой абстрактной моделью вычислительной машины заданной СТАНДАРТОМ ЯЗЫКА". Ты выражение "стандарт языка" понимаешь как-то не так как все люди? Какие еще "оптимизаторы", какие "кодогенераторы" в стандарте языка C? Вот я тебя и прошу подтвердить твою же фразу. Мне еще в 2-3х сообщениях требовать с тебя цитату из стандарта? Или не будем валять дурака, и ты уже все понял, что по стандарту языка C прав именно

Баг в GCC, а не в Clang и вообще совершенно про противоположное, мол нет оптимизации. Остального не понял -- научись выражать мысли на понятном языке. Гудвин не прав, т.к. при использовании стандартных же любых конструкций языка (без упакованных структур) "баг" воспроизвести невозможно. А то, что он воспроизводится при использовании упакованных структур совершенно естесственно, и кстати в баге gcc есть на это комментарий (см. ссылку) -- вот так проблему можно обойти. Какие

кодогенераторы: в процессе генерации кода (промежуточного 3-адресного, ассемблерного) из исходника на C/C++ генерируемый код зависит от типа. Что тут ещё непонятного. В C++ шаблоны могут по разному раскрываться для разных типов, есть argument dependent lookup, для арифметических операций генерируется разный код в зависимости от типа, разные типы по разному передаются в аргументы функции... Оптимизатор уже работает с внутренним представлением, оно там в виде дерева операций, например, во внутреннем коде. Эти операции уже сгенерированы в зависимости от типа как надо и от типа ничего не зависит, работает некая абстрактная машина. Но сама информация о типе, о его выравнивании, достаётся оптимизатором чтобы выбрать какую версию memcpy вызвать. Вот и вся хитрость. То, что кто-то там считал про memcpy никакого значения не имеет. В рамках абстракций введённых в стандарте упакованные структуры невозможны и никаких проблем не возникает. Они возникают только в рамках кривых нестандартных полумер (полумер потому, что упаковку самого объекта структуры сделали, а про то что сделать с типами лежащими внутри -- совершенно не продумано).

Обход проблемы:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50417#c26

Причём здесь я? Если ты решил меня пообсуждать -- сразу идёшь нахуй.

[ZX]

Ответить

- Давай укоротим проблему, насколько это возможно, т.к. нет времени и я устал. С GCC и багом вряд ли я был прав, несмотря на то что внутри armcc.exe v4 v5 масса строк "GCC" и отсутствует "CLANG", armcc это отдельный компилятор. В v6 он называется armclang. Со стандартом вышло смешно. Формально ты привел действительно ровно то, что я спросил. И бессмысленно утверждать что разумеется вопрос был о прямых виновниках разговора: о функции memcpy (она оговорена в стандарте) и о 6.2 RxTx(1116 знак., 24.07.2020 22:30)
  - На счёт memcpy: с одной стороны да, ты можешь подсунуть невыравненный адрес и всё должно работать. И действительно, если ты руками там как-то аллоцировал память, посчитал адрес, он оказался невыравненный -- всё будет работать. Будет вызвана "неоптимальная" версия memcpy. А в случае с гудвиновским багом компилятор был обманут: ему сказали, что будеут копировать вот такой-то тип, а этот тип никак не может лежать на невыравненном адресе, следовательно, компилятор знает, если fk0(1323 знак., 25.07.2020 02:24, ссылка)
  - Я привожу в пример C++ потому, что зная как он работает начинает приоткрываться принцип работы и C компилятора тоже (благо внутри там у GCC и Clang для обоих языков один "движок"). В языке C нет некоторых вещей (шаблонов, ADL), что не даёт понять, например, почему тип важен и как тип может управлять компиляцией. Для C программиста может быть не очевидно, а C++ программист запросто может написать свой самодельный memcpy ровно с такими же "багами" пользуясь только средствами fk0(196 знак., 25.07.2020 01:57, ссылка)
    - Не надо в простой как грабли и предсказуемый C тянуть угар из плюсов. memcpy простейшая фунцкия с нетипизированными указтелями и не надо сюда вносить лишние сущности! Если хотите типизированный xxxcpy он должен быть объявлен как-то так: intcpy(int* src, int* dst, size_t item_count) - 3m(25.07.2020 10:17)
      - Суть "угара" в том, чтоб можно было понять работу компилятора. Там примерно то же самое сделано внутри. - fk0(25.07.2020 14:06)

Микроконтроллеры