Bug 36424
| Summary: | i586 FTBFS: 2.3.2-alt1 не пересобирается посредством gcc8 по-умолчанию | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Sisyphus | Reporter: | Sergey Y. Afonin <asy> | ||||||
| Component: | libslang2 | Assignee: | Sergey Y. Afonin <asy> | ||||||
| Status: | CLOSED FIXED | QA Contact: | qa-sisyphus | ||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | aen, asy, darktemplaralt, iv, ldv, rider, vsu | ||||||
| Version: | unstable | ||||||||
| Hardware: | all | ||||||||
| OS: | Linux | ||||||||
| Attachments: |
|
||||||||
Надо исправить пакет slang2. Только у пакета slang2 нет мантейнера. (In reply to comment #2) > Только у пакета slang2 нет мантейнера. Это не хорошо... А на сколько плохи варианты с gcc7, либо с -O0 для i586 на время отсутствия мантейнера? (In reply to comment #3) > (In reply to comment #2) > > > Только у пакета slang2 нет мантейнера. > > Это не хорошо... А на сколько плохи варианты с gcc7, либо с -O0 для i586 на > время отсутствия мантейнера? Очень плохи. (In reply to comment #1) > Надо исправить пакет slang2. Вот тут http://lists.jedsoft.org/lists/slang-users/2019/0000001.html есть патч, с ним тесты проходят (на i586, остальное не смотрел пока). Но автор предполагает, что проблема всё же в оптимизаторе GCC. slang2-2.3.2-alt2 -> sisyphus: Mon Apr 08 2019 Sergey Y. Afonin <asy@altlinux.ru> 2.3.2-alt2 - fixed gcc8 optimization on i586 (ALT #36424) Спасибо! (In reply to comment #5) > (In reply to comment #1) > > > Надо исправить пакет slang2. > > Вот тут http://lists.jedsoft.org/lists/slang-users/2019/0000001.html есть патч, > с ним тесты проходят (на i586, остальное не смотрел пока). Но автор > предполагает, что проблема всё же в оптимизаторе GCC. Автор не умеет азы знаковой целочисленной арифметики: просто не в курсе, что результат знакового целочисленного переполнения не определён. Прискорбно. (В ответ на комментарий №8) > (In reply to comment #5) > > (In reply to comment #1) > > > > > Надо исправить пакет slang2. > > > > Вот тут http://lists.jedsoft.org/lists/slang-users/2019/0000001.html есть патч, > > с ним тесты проходят (на i586, остальное не смотрел пока). Но автор > > предполагает, что проблема всё же в оптимизаторе GCC. > > Автор не умеет азы знаковой целочисленной арифметики: просто не в курсе, что > результат знакового целочисленного переполнения не определён. Прискорбно. Не менее прискорбно и состояние кодогенерации в gcc-8, которое часто (заметно чаще, чем прошлые версии) уравнивает "неопределённое поведение" с генерацией мусора. (In reply to comment #9) > (В ответ на комментарий №8) > > (In reply to comment #5) > > > (In reply to comment #1) > > > > > > > Надо исправить пакет slang2. > > > > > > Вот тут http://lists.jedsoft.org/lists/slang-users/2019/0000001.html есть патч, > > > с ним тесты проходят (на i586, остальное не смотрел пока). Но автор > > > предполагает, что проблема всё же в оптимизаторе GCC. > > > > Автор не умеет азы знаковой целочисленной арифметики: просто не в курсе, что > > результат знакового целочисленного переполнения не определён. Прискорбно. > > Не менее прискорбно и состояние кодогенерации в gcc-8, которое часто (заметно > чаще, чем прошлые версии) уравнивает "неопределённое поведение" с генерацией > мусора. Это публичная позиция проекта gcc. В каждой новой версии gcc появляются новые оптимизации, часть из них полагается на отсутствие UB. Не хотите мусора - либо убирайте UB, либо выключайте оптимизацию. (In reply to comment #8) > Автор не умеет азы знаковой целочисленной арифметики: просто не в курсе, что > результат знакового целочисленного переполнения не определён. Прискорбно. А может быть автор в курсе, что в этом месте не может быть переполнения ввиду наличия каких-то иных условий в других частях кода? Оптимизация, как я понимаю, в new_num_elements/dims[i] упёрлась? (In reply to comment #11) > (In reply to comment #8) > > > Автор не умеет азы знаковой целочисленной арифметики: просто не в курсе, что > > результат знакового целочисленного переполнения не определён. Прискорбно. > > А может быть автор в курсе, что в этом месте не может быть переполнения Нет, он же проверяет результат переполнения. А результат этот не определён. Вы видели патч, который приложили? Там изменена проверка того самого результата переполнения, который не определён. (In reply to comment #12) > Нет, он же проверяет результат переполнения. А результат этот не определён. > Вы видели патч, который приложили? Там изменена проверка того самого > результата переполнения, который не определён. Видел. Добавлением проверки new_num_elements на отрицательное значение, которого в принципе может и не ожидаться никогда, но это надо уже код смотреть подробно, а то вдруг я напрасно предполагаю. Хотя там есть SLuindex_Type и не очень тогда понятно, почему автор им не воспользовался, если отрицательное значение не ожидается. Такой вот патч тоже помогает, как минимум в сборке: --- a/slang/src/slarray.c +++ b/slang/src/slarray.c @@ -366,7 +366,7 @@ SLang_create_array1 (SLtype type, int read_only, VOID_STAR data, num_elements = 1; for (i = 0; i < num_dims; i++) { - SLindex_Type new_num_elements; + SLuindex_Type new_num_elements; at->dims[i] = dims[i]; new_num_elements = dims[i] * num_elements; if (dims[i] && (new_num_elements/dims[i] != num_elements)) Или gcc8 как-то проверяет, что new_num_elements действительно может уйти в отрицательное значение, а не просто предполагат на основе фрагмента кода? (In reply to comment #13) > Или gcc8 как-то проверяет, что new_num_elements действительно может уйти в > отрицательное значение, а не просто предполагат на основе фрагмента кода? Не очень важно, что делает gcc; просто не нужно использовать результат, значение которого не определено. Правильно было бы как-то так, наверное: - if (dims[i] && (new_num_elements/dims[i] != num_elements)) + if (dims[i] && (INT_MAX/dims[i] < num_elements)) если бы мы могли сказать, что SLindex_Type всегда int. Там, кстати, ниже, около строки 400, ещё одна похожая проверка: http://git.altlinux.org/gears/s/slang2.git?p=slang2.git;a=blob;f=slang/src/slarray.c;h=d26aaece9c67711a96904e3bcf73f5b53b7bcc6c;hb=sisyphus#l399 Подозреваю, что там такого ещё много. Зачем там вообще знаковая арифметика? Неужели num_elements может легально принимать отрицательные значения? Почему вообще num_elements знаковый? (В ответ на комментарий №14) > - if (dims[i] && (new_num_elements/dims[i] != num_elements)) > + if (dims[i] && (INT_MAX/dims[i] < num_elements)) Есть вероятность, что даже такая проверка уже не поможет после того, как код с undefined behavior уже выполнен (при вычислении new_num_elements произошло переполнение). > Подозреваю, что там такого ещё много. Да, и не только в этом файле. Если подходить к данному вопросу формально, то даже арифметические операции в slarith.inc, выполняемые при интерпретации кода на SLang, нужно как-то защищать от переполнения (хотя с этим кодом оптимизатор вряд ли способен сделать что-то неожиданное). Либо нужно собирать весь этот код с -fwrapv (или вообще -fno-strict-overflow — кто знает, что они там делают с указателями), поскольку имеющиеся там проверки на переполнение рассчитаны именно на такое поведение компилятора. (In reply to comment #16) > (В ответ на комментарий №14) > Либо нужно собирать весь этот код с -fwrapv (или вообще -fno-strict-overflow — > кто знает, что они там делают с указателями), поскольку имеющиеся там проверки > на переполнение рассчитаны именно на такое поведение компилятора. Я бы рекомендовал -fno-strict-overflow для всех таких пакетов. (In reply to comment #16) > Есть вероятность, что даже такая проверка уже не поможет после того, как код с > undefined behavior уже выполнен (при вычислении new_num_elements произошло > переполнение). Кстати да, действительно. Что-то я на if зациклился. А почему тогда у компилятора оптимизатор срабатывать начинает при добавлении ещё одной проверки с вероятно неопределённым значением? Или это просто "так получилось"? (In reply to comment #17) > Я бы рекомендовал -fno-strict-overflow для всех таких пакетов. То есть, это делает поведение предсказуемым в плане однозначного получения отрицательного значения при переполнении? Created attachment 8091 [details]
slarray-ub.patch
Автор согласен с ситуацией в плане ub и предлагает такой вариант.
(In reply to comment #20) > Created an attachment (id=8091) [details] > slarray-ub.patch > > Автор согласен с ситуацией в плане ub и предлагает такой вариант. Из check_overflow_mult_ui я не понял условия > (a/(SLuindex_Type)b) > UINT_MAX) (In reply to comment #21) > Из check_overflow_mult_ui я не понял условия > > > (a/(SLuindex_Type)b) > UINT_MAX) В том плане, каким образом результат может превысить UINT_MAX, если a имеет тип UINT? (In reply to comment #21) > Из check_overflow_mult_ui я не понял условия > > > (a/(SLuindex_Type)b) > UINT_MAX) Видимо должно быть так: (a > UINT_MAX/(SLuindex_Type)b) (In reply to comment #8) > Автор не умеет азы знаковой целочисленной арифметики: просто не в курсе, что > результат знакового целочисленного переполнения не определён. Прискорбно. Кстати, если посмотреть краткое резюме на сайте, он астрофизик и работает по специальности. И, наверное, имеет какое-то право не уследить за изменениями в C/C++. Надо просто подсказать иногда. Created attachment 8094 [details] slarray-ub.patch Патч со скорректированным if (см. Comment #23) |
Description
Sergey Y. Afonin 2019-03-26 15:40:22 MSK