LINUX.ORG.RU

О неопределённом поведении и багах оптимизатора clang на примере разбора цикла статей Криса Латтнера, разработчика clang.

 , , , ,


11

10

про ud2 - лень читать комменты - но кто-то должен был оставить вот этот цикл из трех постов:

http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_21.html

stevejobs, спасибо за ссылки. С интересом почитал. Ответ получился довольно длинным, даже движок форума не хочет принимать его в таком виде в качестве простого камента, поэтому я решил, что он тянет на отдельную тему. Тем более, что здесь разбирается не какой-то мелкий баг/фича clang'а, а общий подход к созданию оптимизатора, основанный на изложении и анализе статей одного из разработчиков этого компилятора Криса Латтнера (Chris Lattner). Ну и ещё мне пришлось полностью переписать один из его примеров, чтоб он начал работать и иллюстрировать излагаемые им идеи. Если хочешь, можешь послать ему код, чтоб вставил в свою статью вместо своего, не рабочего. Я не возражаю.

А для тех, кто не в теме, это продолжение темы Вызов никогда не вызываемой функции.

Основная мысль автора цикла статей, как я понял, выражена ближе к концу 3-ей статьи в короткой фразе:

c) is a lot of work to implement.

Т. е. автор, по сути, соглашается, что они реализовали какую-то дичь с этими оптимизациями, объясняя некоторые причины: что де оптимизатор не знает, что на входе получает компилятор и даже не знает, что получает он сам на предыдущем проходе, ну и некоторые другие причины. А в конце говорит: но переделывать эту неудачную архитектуру нам лень, поэтому пользуйтесь тем, что есть. Что ж, fixed. В любом случае, статьи полезны, т. к. проливают свет на реальное (и довольно печальное) положение дел, связанных с оптимизациями в компиляторе clang.

Теперь разберу примеры из статей.

1. В первом примере автор пытается показать, почему к указателю на int нельзя обращаться как к указателю на float:

float *P;
 void zero_array() {
   int i;
   for (i = 0; i < 10000; ++i)
     P[i] = 0.0f;
 }

int main() {
  P = (float*)&P;  // cast causes TBAA violation in zero_array.
  zero_array();
}

Этот код — полная дичь. Он будет вылетать и с оптимизациями, и без них, потому что в переменную P (которая по умолчанию инициализируется 0), записывается её собственный адрес, а дальше, начиная с этого адреса, записываются ещё 40000 байт, которые непременно выдут за границы выделенной памяти.

Я немного переделал этот пример, чтоб он заработал, добавив сразу после P массив достаточного размера, в который и будут записываться числа (тоже undefined, но по факту работает с обоими компиляторами — clang и gcc), и заменив запись 0 на запись адреса &P+1, для чего ввёл объединение ufp, т. к. иначе на первой же итерации P будет указывать на 0, после чего на 2-й итерации произойдёт сегфолт. Ну и ещё добавил printf'ы для вывода информации и return, как того требует gcc и стандарт. Тут же отмечу, что мне пришлось слегка повозиться с unsigned *p, объявленным внутри функции print_array(). Сначала я сделал его глобальным, объявив до указателя float *P, и получил похожий на приведённый, но не совсем верный вывод: вместо ожидаемого 0x601268, 0x0, 0x0, 0x601268 программа без оптимизаций выдавала 0x601268, 0x0, 0x601268, 0x0. После установки watchpoint'а в дебагере выяснилось, что массив повторно модифицируется функцией print_array(). Просмотр адресов глобальных переменных &P и &p показал, что и clang, и gcc вставляют p после P и перед массивом arr, хотя в тексте программы она была объявлена первой. Видимо, компиляторы зачем-то сортируют переменные по типам и располагают указатели на float раньше указателей на unsigned. После переноса unsigned *p внутрь функции, всё стало работать, как и ожидалось. Вот мой рабочий (хоть и намеренно некорректный) вариант:

#include <stdio.h>

float *P;

float arr[10000];

union ufp
{
  float** p; float f;
} fp={&P+1};

void zero_array() {
   int i;
   for (i = 0; i < 10000; ++i)
     P[i] = fp.f;
 }

void print_array() {
   int i;
   unsigned *p;
   printf("&P==%p, P==%p\n", &P, P);
   for(i = -2; i < 10000; ++i)
    {
      p=(unsigned*)P;
      printf("&P[%i]==%p, P[%i]==%f (%p: 0x%X)\n", i, &P[i], i, P[i], p+i, *(p+i));
    }
}

int main() {
  P = (float*)&P;  // cast causes TBAA violation in zero_array.
  zero_array();
  //P=(float*)(&P+1); // restoring P for optimizer
  print_array();
  return 0;
}

При компиляции clang'ом без оптимизации:

clang -o zero_array zero_array.c

этот вариант выдаёт следующее:

&P==0x601260, P==0x601268
&P[-2]==0x601260, P[-2]==0.000000 (0x601260: 0x601268)
&P[-1]==0x601264, P[-1]==0.000000 (0x601264: 0x0)
&P[0]==0x601268, P[0]==0.000000 (0x601268: 0x0)
&P[1]==0x60126c, P[1]==0.000000 (0x60126c: 0x601268)
&P[2]==0x601270, P[2]==0.000000 (0x601270: 0x601268)
&P[3]==0x601274, P[3]==0.000000 (0x601274: 0x601268)
&P[4]==0x601278, P[4]==0.000000 (0x601278: 0x601268)
[skip]
&P[9994]==0x60ae90, P[9994]==0.000000 (0x60ae90: 0x601268)
&P[9995]==0x60ae94, P[9995]==0.000000 (0x60ae94: 0x601268)
&P[9996]==0x60ae98, P[9996]==0.000000 (0x60ae98: 0x601268)
&P[9997]==0x60ae9c, P[9997]==0.000000 (0x60ae9c: 0x601268)
&P[9998]==0x60aea0, P[9998]==0.000000 (0x60aea0: 0x601268)
&P[9999]==0x60aea4, P[9999]==0.000000 (0x60aea4: 0x601268)

и корректно завершается.

Если же включить оптимизацию:

clang -o zero_array -O2 zero_array.c

то получаем следующее:

$ ./zero_array
&P==0x601260, P==0x60126800601268
Ошибка сегментирования

Кстати, такой же результат будет, если откомпилировать эту программу компилятором gcc с включённой оптимизацией (там только адреса будут немного другими). Избавиться от этой ошибки можно 2 способами:

  1. Закомментировав вызов print_array() в функции main().

    Очевидно, что в этом случае никакого вывода мы не получим.

  2. Раскомментировав в main() строчку
    P=(float*)(&P+1); // restoring P for optimizer

    Тогда мы получим такой вывод:

    &P==0x601260, P==0x601268
    &P[-2]==0x601260, P[-2]==0.000000 (0x601260: 0x601268)
    &P[-1]==0x601264, P[-1]==0.000000 (0x601264: 0x0)
    &P[0]==0x601268, P[0]==0.000000 (0x601268: 0x601268)
    &P[1]==0x60126c, P[1]==0.000000 (0x60126c: 0x601268)
    &P[2]==0x601270, P[2]==0.000000 (0x601270: 0x601268)
    &P[3]==0x601274, P[3]==0.000000 (0x601274: 0x601268)
    &P[4]==0x601278, P[4]==0.000000 (0x601278: 0x601268)
    [skip]
    &P[9994]==0x60ae90, P[9994]==0.000000 (0x60ae90: 0x601268)
    &P[9995]==0x60ae94, P[9995]==0.000000 (0x60ae94: 0x601268)
    &P[9996]==0x60ae98, P[9996]==0.000000 (0x60ae98: 0x601268)
    &P[9997]==0x60ae9c, P[9997]==0.000000 (0x60ae9c: 0x601268)
    &P[9998]==0x60aea0, P[9998]==0.000000 (0x60aea0: 0x0)
    &P[9999]==0x60aea4, P[9999]==0.000000 (0x60aea4: 0x0)
    

Проблема тут очевидна: в цикле в P[i] записывается адрес &P+1. Но указатель P указывает на самого себя благодаря присвоению P = (float*)&P. Соответственно, элемент P[0] находится по тому же адресу, что и P. Когда при 1-й итерации цикла мы записываем туда адрес следующего элемента, указатель P меняется. В 64-битной ОС размер указателя равен 8 байтам, а размер float — 4, т. е. P у нас теперь указывает на начало arr. Дальше мы записываем 1-ый элемент от нового начала массива, т. е. по сути 3-й элемент, пропуская таким образом 2 элемента.

Когда же мы включаем оптимизатор (и в clang, и в gcc), он записывает все двойные слова подряд, начиная с 0-ого (в P[-1] у нас 0 потому, что мы перезаписали его после вызова zero_array(), чтобы программа не вылетела при вызове print_array()). Поэтому в первых 2 элементах у нас записано число 0x601268 (если представлять его как беззнаковое целое длиной в 4 байта), но 1-ые 2 элемента одновременно являются адресом, на который указывает P, т. е. адресом 0x0060126800601268 (0x601268 повторенное 2 раза). Если ничего не выводить, то всё тоже проходит успешно. Но как только мы вызываем print_array() (не модифицировав этот дикий адрес), программа сразу пытается отобразить содержимое не валидного адреса 0x601268, а того самого 0x0060126800601268, которого в нашем адресном пространстве просто нет. И получает сегфолт.

Почему printf отображает значения с плавающей точкой, которые в целочисленном виде выглядят как 0x601268, нулями, а не NAN, как по идее должно бы было быть, я не знаю. Видимо, это баг стандартной библиотеки (надо будет послать багрепорт, если никто мне не объяснит, что они правы).

Кстати, оба компилятора по неведомым мне причинам при оптимизации (а я пробовал разные уровни оптимизации) почему-то вместо записи поля fp.f memset'ом продолжают генерить цикл, только более короткий, чем без оптимизации (ассемблерные листинги я тут приводить не буду, кому интересно, могут сами откомпилировать с опцией -S). Хотя при записи константы 0 компилятор clang с вкючённой оптимизацией вместо цикла вызывает memset (gcc и в этом случае генерит цикл).

На всякий случай укажу версии использованных компиляторов:

$ clang --version
Debian clang version 3.5.0-10 (tags/RELEASE_350/final) (based on LLVM 3.5.0)
Target: x86_64-pc-linux-gnu
Thread model: posix

$ gcc --version
gcc (Debian 4.9.2-10) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.
Это свободно распространяемое программное обеспечение. Условия копирования
приведены в исходных текстах. Без гарантии каких-либо качеств, включая 
коммерческую ценность и применимость для каких-либо целей.

К сожалению, мне пришлось писать рабочую программу за автора статьи, который не удосужился даже проверить тот код, который опубликовал (хотя там и без проверки видно, что код по-любому не рабочий, хоть оптимизируй, хоть нет). Впрочем, автор всё честно объяснил:

c) is a lot of work to implement.

Такие они, разработчики clang'а.

Но идею я понял: при заполнении массива 0 или другими значениями в цикле, опасно одновременно менять указатель на этот массив. Но при чём тут изначальное утверждение о том, что

It is undefined behavior to cast an int* to a float* and dereference it (accessing the «int» as if it were a «float»).

Как это утверждение иллюстрируется данным примером?

Я уже не говорю о том, что оптимизировать циклы в memset нет никакой необходимости, потому что программист и сам может это сделать, сократив не только получившийся бинарник, но и исходник. А если программисту до этого нет дела, то почему компилятору должно быть дело? Тем более, если программист сделал цикл намеренно, то компилятору совсем незачем это исправлять. Думаю, именно поэтому gcc и не сворачивает циклы в memset. Я уже не говорю о том, что если уж вы сворачиваете их в memset, то будьте последовательны. Почему при заполнении массива константой 0 вместо цикла clang вызывает memset, а при заполнении того же массива одной не меняющейся переменной длиной в 4 байта оставляет цикл? Грош цена такой оптимизации.

Вот заменить вызов memset на ассемблерную команду rep stos действительно было бы полезно, но почему-то ни clang, ни gcc этого не делают.

2. Во втором примере автор цикла показывает, как смертельный указатель может запутать оптимизатор clang так, что тот сгенерит очередную фигню вместо исполняемого кода. Вот пример смертельного кода из 2-й статьи:

void contains_null_check(int *P) {
  int dead = *P;
  if (P == 0)
    return;
  *P = 4;
}

Очевидно, что если передать функции contains_null_check() NULL, то код будет непереносимым (undefined behavior). В защищённом режиме при попытке разыменования такого указателя произойдёт сегфолт. (UPD: практически аналогичная ошибка в ядре Linux 2.6.30 и 2.6.18 для Red Hat привела к серьёзной уязвимости, причём при разыменовании указателя система не падала.) Однако в реальном режиме такой код вполне законный. Более того, если мы рассматриваем язык си как системный язык, то в некоторых случаях без подобного кода в реальном режиме не обойтись. Что у нас лежит по адресу 0 в реальном режиме? — Указатель на обработчик 0-ого прерывания (деление на 0). А что если я хочу зарегистрировать свой обработчик? Для этого и существует неопределённое поведение: в одних системах оно работает так, а в других иначе. Но разработчики clang'а считают, что «неопределённое поведение» — это индульгенция на генерацию разного бреда вместо нормального кода.

Но вернёмся к статье. Автор описывает 2 варианта поведения оптимизатора.

  1. В первом варианте сначала проверяется избыточный код, а затем избыточные проверки. Выглядит это примерно так:
    void contains_null_check_after_DCE(int *P) {
      //int dead = *P;     // deleted by the optimizer.
      if (P == 0)
        return;
      *P = 4;
    }
    

    На этом этапе совершенно справедливо выпилили переменную dead, т. к. она нигде не используется.

    Далее идёт проверка избыточности проверок и делается правильный вывод о том, что проверка P на равенство 0 нужна. Она остаётся. Всё работает, как и задумывалось (и даже не падает в защищённом режиме на радость быдлокодерам).

  2. Во втором варианте оптимизатор сначала проверяет проверки программиста на избыточность, а затем выпиливает ненужные переменные:
    void contains_null_check_after_RNCE(int *P) {
      int dead = *P;
      if (false)  // P was dereferenced by this point, so it can't be null 
        return;
      *P = 4;
    }
    

    Здесь оптимизатор почему-то решил, что раз *P разыменовывается без проверки, то он априори 0 быть не может и проверять его необходимости нет. А то, что программист мог ошибиться, разработчикам оптимизатора даже в голову не приходит. Как и то, что помимо защищённого режима есть ещё и реальный. А бывают ещё компиляторы для разных контроллеров и встроенных специализированных систем, где разыменовывать 0 указатели бывает нужно и иногда даже необходимо. Или clang такие системы не поддерживает? И никогда не сможет поддержать с подобным подходом, ориентированным на работу только защищённых многозадачных ОС.

    Но вернёмся к статье. На следующем этапе выпиливается переменная dead и проверка на 0 и остаётся:

    void contains_null_check_after_RNCE_and_DCE(int *P) {
      *P = 4;
    }
    

    Если раньше программа корректно работала в реальном режиме, а в защищённом падала, то теперь в реальном режиме вектор 0-ого прерывания перезаписывается адресом 4. В результате при любой ошибке деления компьютер намертво зависает (хотя реальный режим clang, как я понимаю, не поддерживает и никогда не сможет поддержать с таким шикарным легаси).

3. Третий пример я разбирать не буду, т. к. согласен с автором, что оптимизация «x > x+1 всегда false» может быть полезна при использовании макросов. А для проверки переполнения существуют константы MAX_*.

4. Четвёртый пример — почти из поста Вызов никогда не вызываемой функции. Его уже разобрали по полочкам, сломали все копья, какие только можно было сломать, в т. ч. и я, поэтому здесь повторяться не буду. Единственно, скажу, что мне было непонятно, зачем заменять вызов функции по 0-ому адресу с неизбежным сегфолтом на недопустимую инструкцию ud2. Автор поясняет во 2-й статье:

2. Clang has an experimental -fcatch-undefined-behavior mode that inserts runtime checks to find violations like shift amounts out of range, some simple array out of range errors, etc. This is limited because it slows down the application's runtime and it can't help you with random pointer dereferences (like Valgrind can), but it can find other important bugs. Clang also fully supports the -ftrapv flag (not to be confused with -fwrapv) which causes signed integer overflow bugs to trap at runtime (GCC also has this flag, but it is completely unreliable/buggy in my experience). Here is a quick demo of -fcatch-undefined-behavior:

В вольном пересказе: мы всегда так делаем, чтобы показать, что код содержит участки с неопределённым поведением. И плевать, что недопустимая инструкция не указывает на некорректный код. Просто ничего лучшего мы не придумали.

Мне, кстати, удалось получить бинарник с такой инструкцией безо всяких экспериментальных флагов.

И напоследок 2 эпические цитаты. Первая из начала 1-ой статьи. Она очень понравилась dzidzitop:

It turns out that C is not a «high level assembler» like many experienced C programmers (particularly folks with a low-level focus) like to think

Вот оно что оказывается. Си — это та же ява, чуть более быстрая и более опасная. А для написания системных вещей переходите на настоящий ассемблер! Кен Томпсон гомерически хохочет и Деннис Ритчи переворачивается в гробу.

А вторая из 3-ей, заключительной статьи:

Ultimately, undefined behavior is valuable to the optimizer because it is saying «this operation is invalid - you can assume it never happens».

В вольном пересказе это обозначает: «Вау! Неопределённое поведение! Ворочу куда хочу!»

UPD: Вот хочу добавить сюда ещё несколько ответов на вопросы, на которые приходится отвечать по всему треду одно и то же:

1. То, что ub обозначает «делай, что хочешь!», мягко говоря, неправда. Вот, что написано в стандарте C99:

3.4.3

1 undefined behavior

behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this International Standard imposes no requirements

2 NOTE Possible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message).

3 EXAMPLE An example of undefined behavior is the behavior on integer overflow.

Т. е. в стандарте чётко прописаны 3 действия, из которых разработчики компиляторов могут выбрать любое:

1. Игнорировать ситуацию. Смотрим в Ожегове, что обозначает слово «игнорировать»:

Умышленно не заметить, не принять во внимание.

Т. е. «игнорировать» — это сделать вид, что всё нормально и пройти мимо, а не модифицировать или удалять такой код, и уж тем более делать на его основе какие-то бредовые предположения.

2. Компилировать и выполнять такой код в соответствии с документацией, с выводом предупреждающих сообщений или без них. Т. е. напишите явно в документации, что если мы встречаем 0 указатель, то делаем то-то и то-то, и делайте. Но не в тихую.

3. Прерывать компиляцию и/или выполнение с обязательным выводом диагностических сообщений.

И всё. Ни о каком «что хочешь» в стандарте речи не идёт. Вот тут мне в каментах подсказали, что «with unpredictable results» обозначает «что хочешь». Но на самом деле это обозначает лишь то, что результаты могут быть непредсказуемыми, а совсем не то, что компилятор может делать всё, что угодно (хотя разработчикам таких компиляторов подобная трактовка очень удобна).

Ну и тот же человек считает, что «это notes», а значит неважно, что там написано. Но т. н. неопределённое поведение при переполнении целого — вообще example из того же пункта:

EXAMPLE An example of undefined behavior is the behavior on integer overflow.

И больше я нигде никаких упоминаний об ub при арифметическом переполнении не нашёл. Про переполнение при сдвигах — нашёл. А в других случаях — нет. Но все почему-то на этот example ссылаются.

2. Многие говорят, что быдлокодеры должны страдать. Но серьёзные уязвимости, связанные с ub, а точнее с непредсказуемой реакцией компилятора на ub, в разное время обнаруживались в ядре Linux, во FreeBSD и в GDK-Pixbuf, затрагивающая Chromium, Firefox и VLC. Подробнее см. в этом комментарии, чтоб не раздувать и без того длинный верхний пост. Здесь только скажу, что уязвимость в ядре Linux связана с ошибкой, идентичной со 2-м примером из разбираемых статей.

3. Автор статей и многие в этом треде утверждают, что автоматически отыскать такие ошибки очень сложно и дорого, а то и вовсе невозможно. Но это тоже не так. В Интернете я нашёл такой пример си++ программы с ub:

#include <iostream>
int main()
{
    for (int i = 0; i < 300; i++)
        std::cout << i << " " << i * 12345678 << std::endl;
}

Программа из-за переполнения временного результата на 174-й итерации при использовании ключа оптимизации -O2 в g++ попадает в бесконечный цикл.

Запустив компиляцию, я получил следующие предупреждения (причём безо всяких опций -W что-то_там):

$ g++ -o infinity_loop -O2 infinity_loop.cpp
infinity_loop.cpp: В функции «int main()»:
infinity_loop.cpp:5:38: предупреждение: iteration 174u invokes undefined behavior [-Waggressive-loop-optimizations]
         std::cout << i << " " << i * 12345678 << std::endl;
                                      ^
infinity_loop.cpp:4:5: замечание: containing loop
     for (int i = 0; i < 300; i++)
     ^

А ведь здесь случай куда менее очевидный, чем простое разыменование NULL-указателя.

4. Наконец, на Хабре я вычитал, что стандартный макрос

#define offsetof(st, m) ((size_t)(&((st *)0)->m))

тоже содержит UB. Правда, к ошибкам и уязвимостям это пока не приводит. Но именно, что пока, UB ведь, а значит любой компилятор имеет полное право, встретив вызов этого макроса, отформатировать диск, как утверждают создатели компиляторов и многие лорчане.

UPD 2: Вот тут Sorcerer в комментарии кинул ссылку на письмо Линуса Торвальдса в рассылке от 12 января 2009 года, где он пишет о том, что думает о некоторых оптимизациях. Приведу несколько фрагментов этого письма в своём переводе:

Type-based aliasing — это тупость. Это такая невероятная тупость, что даже не смешно. Оно испорчено. И gcc взял испорченную концепцию и настолько её раздул, следуя букве-закона, что получилась бессмысленная вещь.

[skip]

Это НЕНОРМАЛЬНО. Это так невероятно безумно, что люди, которые делают это, просто должны избавиться от своего убожества, прежде чем они смогут восстановить. Но реальные gcc программисты действительно думали, что это имеет смысл, потому что стандарт это позволяет и даёт компилятору максимальную свободу, — потому что он может делать теперь вещи БЕЗУСЛОВНО АБСУРДНЫЕ.

И компиляторщикам абсолютно абсурдные вещи часто кажутся действительно хорошими, потому что им больше не надо беспокоиться о конечном результате: работает оно или нет, — они просто получили добро тупить во имя оптимизации.

[skip] И если кто-то жалуется, что компилятор невменяемый, компиляторщики скажут «ня, ня, разработчики стандарта сказали, что так можно», с абсолютным отсутствием анализа, имеет ли оно СМЫСЛ.

По любому, однажды вы начинаете делать глупости, подобно этой, думая, что стандарт имеет больше смысла, чем человек, пользующийся головой 5 секунд, внезапно вы оказываетесь в ситуации, когда возможно дико переместить хранилище, и всё это 'корректно'.

[skip]

Угадайте, что произойдёт, если вы имеете такой безумный склад ума и пытаетесь сделать безопасный код без alias'а, — вы займёте лишнее пространство на стеке.

По факту, Linux использует -fno-strict-aliasing из-за чертовски веской причины: потому что в gcc понятие «strict aliasing» является огромной зловонной кучей д-рьма. Linux использует этот флаг не потому, что Linux исполняется быстро и свободно, он использует этот флаг, потому что _не_ использует тот безумный флаг.

Type-based aliasing неприемлемо тупо для начала, и gcc вознёс этот идиотизм до совершенно новых высот, фактически не обращая внимания даже на статически видимый aliasing.

Линус

Оригинал (на английском):

Type-based aliasing is _stupid_. It's so incredibly stupid that it's not even funny. It's broken. And gcc took the broken notion, and made it more so by making it a «by-the-letter-of-the-law» thing that makes no sense.

[skip]

That's INSANE. It's so incredibly insane that people who do that should just be put out of their misery before they can reproduce. But real gcc developers really thought that it makes sense, because the standard allows it, and it gives the compiler the maximal freedom - because it can now do things that are CLEARLY NONSENSICAL.

And to compiler people, being able to do things that are clearly nonsensical seems to often be seen as a really good thing, because it means that they no longer have to worry about whether the end result works or not - they just got permission to do stupid things in the name of optimization.

[skip] And if somebody complains that the compiler is insane, the compiler people would say «nyaah, nyaah, the standards people said we can do this», with absolutely no introspection to ask whether it made any SENSE.

Anyway, once you start doing stupid things like that, and once you start thinking that the standard makes more sense than a human being using his brain for 5 seconds, suddenly you end up in a situation where you can move stores around wildly, and it's all 'correct'.

[skip]

Guess what happens if you have that kind of insane mentality, and you then try to make sure that they really don't alias, so you allocate extra stack space.

The fact is, Linux uses -fno-strict-aliasing for a damn good reason: because the gcc notion of «strict aliasing» is one huge stinking pile of sh*t. Linux doesn't use that flag because Linux is playing fast and loose, it uses that flag because _not_ using that flag is insane.

Type-based aliasing is unacceptably stupid to begin with, and gcc took that stupidity to totally new heights by making it actually more important than even statically visible aliasing.

Linus

И ещё спасибо anonymous'у за камент с ещё одним сообщением на ту же тему того же автора от 26 февраля 2003 года.

Ну и от себя добавлю, что не только Линусу не нравится aliasing. Microsoft тоже не спешит реализовывать его в своём Visual C++. Т. е. не нравится это тем, кто помимо разработки компиляторов создаёт и другой софт с использованием этого компилятора, например ОС. А те, кто создают только компиляторы для сферических программистов в вакууме, рьяно эту фичу реализуют, хоть их и никто не заставляет.

Ну и напоследок оставлю несколько полезных ссылок на память:

Стандарт C11 (последний) (pdf), Стандарт C99 (pdf),

http: //read.pudn.com/downloads133/doc/565041/ANSI_ISO%2B9899-1990%2B%5B1%5D.pdf (Стандарт C89) (pdf),

http: //web.archive.org/web/20030222051144/http: //home.earthlink.net/~bobbitts/c89.txt (Стандарт C89) (txt),

https: //web.archive.org/web/20170325025026/http: // www .open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4660.pdf (Стандарт C++17) (последний) (pdf),

Стандарт C++14 (pdf), Стандарт C++11 (pdf),

бумажный перевод стандарта C++17, выполненный Зуевым и Чуприновым, Москва, 2016, на основе Working Draft, Standard for Programming Language C++ от 22 мая 2015 года (номер документа n4527) за 4945 руб. (надеюсь, что эту ссылку не сочтут за рекламу, т. к. к авторам я никакого отношения не имею), а здесь можно скачать начало перевода (предисловие и содержание), ну и ещё торрент-ссылку видел на эту книгу, но здесь её публиковать не буду,

статья на Хабре (из песочницы) от 2014 г. Неопределенное поведение в C++, ещё одна статья там же от 2016 года Находим ошибки в коде компилятора GCC с помощью анализатора PVS-Studio, Разыменовывание нулевого указателя приводит к неопределённому поведению и Про C++ алиасинг, ловкие оптимизации и подлые баги. Это так, ссылки на заметку.

Некоторые ссылки парсер ЛОР'а не принял, поэтому мне пришлось разделить их пробелами, превратив в текст, который можно скопировать в адресную строку браузера, удалив пробелы. Там, где http встречается дважды в 1 строке — не ошибка, а именно такие ссылки.

★★

Последнее исправление: aureliano15 (всего исправлений: 2)

Ответ на: комментарий от anonymous

Переменная используется способом X, откуда следует, что её значение не равно Б.

«Оттуда» ничего не следует. Комбинация Х&Б объявлена как приводящая к undefined behaviour - так буквально в стандарте написано и ничего сверх этого. Отсюда не следует, что вариант значения Б невозможен. В приведённом мною примере вариант Б по прежнему невозможен, но в переменной будет лежать именно ноль.

Дизассемблирование раздела .bss:

00000000 <_ZL2Do>:
   0:	00 00                	add    %al,(%eax)
	...
ckotinko ☆☆☆
()
Ответ на: комментарий от anonymous

ок, я был неправ. действительно, 0=nullptr. покажите на меня пальцем и посмейтесь.

вопрос-то в данном треде стоит ширше, ширее:

если мы попали в ситуацию, когда некоторая оптимизация явно использует UB, то должен ли компилятор предупреждение? делается утверждение, что если уж компилятор решил воспользоваться UB для отсечки некоторых вариантов, то ему следует об этом известить программиста.

Даже если программист сам виноват. Ну виноват. Но компилятор-то мог бы и предупредить - в других случаях UB он предупреждает.

Кроме того, я ведь утверждал что: из того, что вариант значения приводит к UB, не следует его исключать, а следует оставить чтение не-константной переменной как есть. Пусть падает. Не следовало сводить переменную к константе. Всё.

Даже так скажем:

пусть из null следует UB. но из !UB не следует !null

А->B=1

!A->!B !=1

из первого уравнения следует, что допустимые комбинации (0,0),(0,1),(1,1). но комбинация (0,1) во втором уравнении даст 0: 1->0=0

ckotinko ☆☆☆
()
Последнее исправление: ckotinko (всего исправлений: 1)
Ответ на: комментарий от anonymous

да, коряво сформулировал. т.к. имеется ввиду не !UB а UB=1 и отбрасывание этого варианта.

ckotinko ☆☆☆
()
Ответ на: комментарий от Sorcerer

Линус про strict aliasing

Да это ж ckotinko перелогинился!

Ну вообще да, они правы что стандарт угребищен. Имхо, компиляторам _нужно_ ему следовать как можно безумнее, чтобы комитет задумался (или кто-нибудь форкнул стандарт).

anonymous
()
Ответ на: комментарий от anonymous

Имхо, компиляторам _нужно_ ему следовать как можно безумнее, чтобы комитет задумался

Сынок, я тебя разочарую. Множества членов комитета и написателей компиляторов пересекаются.

Комитет по стандартизации это не какие-то оторванные от жизни академики, которые только и делают, что пишут стандарт и выдумывают как бы поиздеваться над обычными разработчиками. Они сами сотрудники компаний-гигантов (MS, Intel, Google, FB) и писатели как стандарта и компиляторов, так и кода на этом языке.

anonymous
()
Ответ на: комментарий от aureliano15

С99 и C11 постулируют, что *((void *) 0) - это undefined behaviour. Смирись. Или форкни Си и разреши там обращение по нулевому адресу.

А что там было и чего не было у K&R - уже давно почти всем пофиг.

dzidzitop ★★
()
Ответ на: комментарий от ckotinko

что если уж компилятор решил воспользоваться UB для отсечки некоторых вариантов, то ему следует об этом известить программиста.

Уверен, что компиляция каждой программы родит десятки подобных «предупреждений». Хотя бы потому, что не каждый UB вообще можно увидеть во время компиляции, а оптимизируют рантайм с рассчётом на корректность программы.

dzidzitop ★★
()
Ответ на: комментарий от anonymous

Папа?!

Все верно, но чему это противоречит? Стандарт может казаться хорош, пока его идеи не реализованы. Вся эта муета там уже декады, но раньше не особо стреляла, и всем было пофиг. А теперь и простым кодерам чем дальше, тем яснее в какой жопе си.

Если еще не ясно - погодите пока в этих UB вылезет новый heartbleed, это дело времени.

anonymous
()
Ответ на: комментарий от anonymous

Вся эта муета там уже декады, но раньше не особо стреляла, и всем было пофиг.

Блогпосты от 2011/05 и оно уже тогда вовсю среляло.

А теперь и простым кодерам чем дальше, тем яснее в какой жопе си.

Если бы простые кодеры не были инфантильными дебилами, то им бы становилось яснее, что в жопе они.

anonymous
()
Ответ на: комментарий от anonymous

Блогпосты от 2011/05 и оно уже тогда вовсю среляло.

Да. А си стандартизован в 89-м. У тебя что-то не сходится?

Если бы простые кодеры не были инфантильными дебилами, то им бы становилось яснее, что в жопе они.

Раскрой мысль, как личные качества влияют на язык или компилятор.

anonymous
()
Ответ на: комментарий от anonymous

Да. А си стандартизован в 89-м.

Да. А strict aliasing в 99-м.

У тебя что-то не сходится?

А у тебя?

Раскрой мысль, как личные качества влияют на язык или компилятор.

Никак.

Но не-инфантильный человек исправляет свои представления, а не обвиняет компилятор в несоответствии им.

anonymous
()
Ответ на: комментарий от anonymous

Так речь изначально была про UB вообще.

Strict aliasing - да, отдельная бомба. Смягчается тем что методы борьбы известны: есть опция gcc, есть атрибут gcc, кто-то из-за него перевел код на C++ с наследованием (видел такую историю в сети). А вендовозы его просто не заметили. Так что пошумели и успокоились.

В остальном согласен.

anonymous
()
Ответ на: комментарий от anonymous

https://lkml.org/lkml/2003/2/26/158

From	(Linus Torvalds)
Subject	Re: Invalid compilation without -fno-strict-aliasing
Date	Wed, 26 Feb 2003 17:26:37 +0000 (UTC)
In article <20030225234646.GB30611@bougret.hpl.hp.com>,
Jean Tourrilhes  <jt@bougret.hpl.hp.com> wrote:
>
>	It looks like a compiler bug to me...

Why do you think the kernel uses "-fno-strict-aliasing"?

The gcc people are more interested in trying to find out what can be
allowed by the c99 specs than about making things actually _work_. The
aliasing code in particular is not even worth enabling, it's just not
possible to sanely tell gcc when some things can alias.

>	Some users have complained that when the following code is
>compiled without the -fno-strict-aliasing, the order of the write and
>memcpy is inverted (which mean a bogus len is mem-copied into the
>stream).

The "problem" is that we inline the memcpy(), at which point gcc won't
care about the fact that it can alias, so they'll just re-order
everything and claim it's out own fault.  Even though there is no sane
way for us to even tell gcc about it. 

I tried to get a sane way a few years ago, and the gcc developers really
didn't care about the real world in this area. I'd be surprised if that
had changed, judging by the replies I have already seen.

I'm not going to bother to fight it. 

			Linus

https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg01647.html

Linus Torvalds Mon, 12 Jan 2009 11:44:14 -0800


On Mon, 12 Jan 2009, Andi Kleen wrote:
>
> What I find nonsensical is that -fno-strict-aliasing generates
> better code here. Normally one would expect the compiler seeing
> more aliases with that option and then be more conservative
> regarding any sharing. But it seems to be the other way round
> here.

No, that's not the surprising part. And in fact, now that you mention it, 
I can even tell you why gcc does what it does.

But you'll need some background to it:

Type-based aliasing is _stupid_. It's so incredibly stupid that it's not 
even funny. It's broken. And gcc took the broken notion, and made it more 
so by making it a "by-the-letter-of-the-law" thing that makes no sense.

пошумели и успокоились.

Ну кто как. Один вот поциент как минимум на протяжении 6 лет успокоиться не мог. Наверняка не успокоился до сих пор.

anonymous
()
Ответ на: комментарий от aureliano15

все предположения о том что будет за пределами defined behavior - это их личная фантазия

Это не фантазия, а стандарт, п. 3.4.3.

Я и говорю, фантазия, там это чётко задокументированно:

ignoring the situation completely with unpredictable results

Касательно примера - неправильное использование volatile. Правильно так:

#include <stdio.h>
#include <limits.h>

int main()
{
 int volatile x = INT_MAX,
              y;

 y = x + 1;

 if(y>x)
  printf("x+1>x\n");
 if(y<x)
  printf("x+1<x\n");
 return 0;
}

Далее получаем идентичное поведение:

$ gcc t.c -O3 && ./a.out 
x+1<x
$ gcc t.c -O0 && ./a.out 
x+1<x
alexanius ★★
()
Ответ на: комментарий от anonymous

Strict aliasing - да, отдельная бомба. Смягчается тем что методы борьбы известны: писать нормальный код, не нарушающий strict-aliasing.

fixed

alexanius ★★
()
Ответ на: комментарий от anonymous

А strict aliasing в 99-м.

Или тоже в 89-м?

anonymous
()
Ответ на: комментарий от alexanius

писать нормальный код, не нарушающий strict-aliasing

... и не забывать при этом пинать оптимизаторы компиляторов, которые пытаются портить код, включая дурака

Sorcerer ★★★★★
()
Ответ на: комментарий от alexanius

писать нормальный код, не нарушающий strict-aliasing

Тогда забудь про сишные эмуляции ООП, включая glib/gtk.

anonymous
()
Ответ на: комментарий от Sorcerer

... и не забывать при этом пинать оптимизаторы компиляторов, которые пытаются портить код, включая дурака

Хоть один случай испорченного кода (не считая багов)?

alexanius ★★
()
Ответ на: комментарий от anonymous

Тогда забудь про сишные эмуляции ООП, включая glib/gtk.

А где там нарушения strict-aliasing? Глянул пример использования GObject с wiki, вроде всё норм.

alexanius ★★
()
Ответ на: комментарий от alexanius

Хоть один случай испорченного кода

uint32_t func(uint32_t *arg)
{
    uint16_t *arg2 = (void *)arg;

    *arg = 1;
    *arg2 = 2;

    return *arg;
}

Знает ли компилятор, что arg и arg2 указывают на одно место? Да. Делает ли он из этого выводы? Как минимум gcc - нет, и даже не предупреждает, что включил дурака.

Sorcerer ★★★★★
()
Ответ на: комментарий от Sorcerer

Это пользователь включил дурака, написав такой код. Компилятор имеет полное право разорвать зависимость в этом случае.

alexanius ★★
()
Ответ на: комментарий от Sorcerer

Ну так испорчен уже исходник. И в той же рассылке объяснялось, почему gcc делает именно так.

anonymous
()
Ответ на: комментарий от alexanius

Это пользователь включил дурака, написав такой код.

Да лана. Ну вот такая железка, которая при четных данных должна получать 32-битные данные, а при нечетных - 16-битные. И не такое бывало с железками, на которых изобрели Cи. Там даже регистры общего назначения можно было прочитать и изменить по верхним адресам памяти, не говоря уже о танцах с железом. Ну да, тут напрашивается проверка статусного регистра, но могли бы и впендюрить микрозадержку, а если устройство электровеник, то и скорость шины тоже не мало и иногда достаточно.

vodz ★★★★★
()
Ответ на: комментарий от alexanius

Компилятор имеет полное право разорвать зависимость в этом случае.

Ну а мы можем пнуть такой качающий права компилятор.

Sorcerer ★★★★★
()
Ответ на: комментарий от alexanius

Глянул пример использования GObject с wiki, вроде всё норм

Короче, про них настаивать не буду, там надо еще продраться через макросы. Если у них строгий pImpl без инлайнов, то может и всё норм. Но где-то были жалобы, что их объектная система в 99-м превратилась в тыкву.

Самое тут приятное, что поломали совместимость без явно показанного профита.

anonymous
()
Ответ на: комментарий от vodz

К счастью C не стоит на месте и значительно изменился со времён K&R. Касательно случая с железками это уже подмножество языка, для которого не действуют некоторые положения стандарта. Т.е. либо нужно доработать компилятор чтобы по опции -march=my_cool_arch ряд анализов и оптимизаций не выполнялся, либо отключать их руками через опции.

alexanius ★★
()
Ответ на: комментарий от Sorcerer

Ну а мы можем пнуть такой качающий права компилятор.

Не сомневаюсь. Всегда можно отказаться от одного компилятора в пользу другого/написать собственный. Очень хочу на это посмотреть :)

alexanius ★★
()
Ответ на: комментарий от alexanius

Т.е. либо нужно доработать компилятор

Чтобы он молча не своевольничал: «мы лучше знаем что вы имели в виду, но на самом деле просто нихрена не смогли выцепить из оптимизатора его решения по выкидыванию с его точки зрения ненужного». И волшебным образом не было б этого страча и топика как такового.

компилятор чтобы по опции -march=my_cool_arch ряд анализов и оптимизаций не выполнялся

И этот человек говорит о стандартах языка... Нет. Не надо делать несовмеcтимую фигню. Надо чтобы при включении оптимизатора были сообщения, что код подозрителен, выкинут и упрощён до «XXX».

vodz ★★★★★
()
Ответ на: комментарий от alexanius

Всегда можно отказаться от одного компилятора в пользу другого/написать собственный.

Зачем? Достаточно пинать. Т.е. знать об этих его сумасбродствах.

Sorcerer ★★★★★
()
Ответ на: комментарий от anonymous

Для этого дан union. Теперь уже как единственно верный метод.

Тот метод использовался именно для аппаратуры, когда требовалось именно на данной архитектуре получить одну по шине mov, но с разной размерностью и текущей endian. Гарантирует ли эти все условия union?

vodz ★★★★★
()
Ответ на: комментарий от vodz

Надо чтобы при включении оптимизатора были сообщения, что код подозрителен

$ cat warn1.c

int main(void)
{
	unsigned long a;

	a = 5;
	*(unsigned short *)&a = 4;
}
$ gcc warn1.c -O2 -Wall
warn1.c: In function ‘main’:
warn1.c:6:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
  *(unsigned short *)&a = 4;
  ^

Deleted
()
Ответ на: комментарий от vodz

Формулировка непонятна. union гарантирует что одни и те же данные можно корректно читать и писать через любые нужные типы, то есть там где обычно ломают strict aliasing, в частности тут: О неопределённом поведении и багах оптимизатора clang на примере разбора цикла статей Криса Латтнера, разработчика clang. (комментарий)

anonymous
()
Ответ на: комментарий от anonymous

Формулировка непонятна

Вот смотрите. На PDP-11 код:

*(short *)p = 1;
*(long *)p = 2;
на самом делал следующее: записать в в память по адресу p единичку, по адресу p+1 нолик в виде одного mov. Так требовала аппаратура, чтобы по общей шине для предотвращения race была одна mov, memcpy не годилось. А следующая строка делала не то, что думают сегодняшние писатели на x86/Itanium-ов, там был не little и не big endian, а был pdp-endian. Вторая строка записывала по адресу p и p+1 нолики, по адресу p+2 двойку, ну и по адресу p+3 тоже нуль. То есть не единичка заменится двойкой, а ноликом, а двойка пойдёт совершенно в другое слово. Кто это программировал, тот это самое и хотел, так как это был системозависимый код. Потому Си и был полуассемблером, на него можно было положиться, что именно что написано то и будет переведено в ассемблерные инструкции текущей архитектуры, если не задана оптимизация. Надо регистр, так и пишите регистр. Не было б инструкции mov (x)+,y, не было б в языке ++...

union гарантирует

Что будет как-то утоптано. А вот эти извраты, которые обозвали «strict-aliasing» и делались, чтобы 100% гарантировать что будет процессором исполнено именно то что хочется, а не как язык реализует этот union.

vodz ★★★★★
()
Ответ на: комментарий от dzidzitop

Уверен, что компиляция каждой программы родит десятки подобных «предупреждений»

уверен, что заяви я такое, от меня бы потребовали пруфов. но то скотинка, нерукопожатая практически ватная тварь.

Я вот уверен, что собраный «шлангом» код собирался в итоге llvmом. в нем любое llvm::Value например может быть ...

http://llvm.org/doxygen/classllvm_1_1Value.html

...в нашем случае релевантен llvm::ConstantPointerNull.

ckotinko ☆☆☆
()
Ответ на: если не задана оптимизация от anonymous

а сейчас иначе?

Так мы пишем в топике, где рассматривается пример, что оптимизатор не просто выкидывает не нужное, а вообще делает ни на что не похожее, молча.

vodz ★★★★★
()
Ответ на: комментарий от vodz

если не задана оптимизация

а если сабж посмотреть?

anonymous
()

и хабр в курсе печалей тс-а

https://habrahabr.ru/post/339356/

Если вы хотите выяснять отношения с языками программирования, почему они такие глючные и ваша программа дает сбой — то вы выбрали не ту специальность.

anonymous
()
Ответ на: комментарий от vodz

Понятно. Но вот это:

100% гарантировать что будет процессором исполнено именно то что хочется

ведь и раньше не гарантировалось, этого можно было ждать только от конкретного компилятора с конкретными опциями. Сейчас добавилась еще одна нужная опция.

Хотя соглашусь что описанное - естественное поведение. И в этом плане C99 подложил свинью, не только поломав совместимость, но и вообще отломав кусок от самой сути си.

anonymous
()
Ответ на: комментарий от anonymous

вчера убегал с работы и постил абыкак, поэтому написал плохо и неверно. история правок как бы вот.

да,действительно. а как описать «отбрасывание B если B=1». бу. алгебры логики в данном случае походу недостаточно, ибо имеется скажем так «прямое следствие» и «обратное».

ckotinko ☆☆☆
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.