[sisyphus] Странности при переходе объединении двух целых в вещественное на x86_64

[Victor Forsyuk]

2009/8/13 Kirill A. Shutemov <kirill на shutemov.name>

> >>
> >> Это ничего не значит. Точнее значит лишь то, что работа оптимизатора
> >> различается между версиями компилятора.
> >>
> >> То, что криво написаный код иногда работает -- не аргумент. Если вы
> >> желаете отказаться от подбного рода оптимизиций -- используйте
> >> -fno-strict-aliasing.
> >>
> >
> > Я вот сижу и думаю (нет, это не по поводу этого кода), если даже с
> полностью
> > выключенной оптимизацией компилятор (gcc 4.4) создает код, отказывающийся
> > работать, тогда как скомпилированный gcc 4.3 работает - стоит разбираться
> с
> > кодом или это в любом случае регрессия компилятора?
>
>
> Зависит от.
>
> > Кому-то интересно будет посмотреть?
>
> Давай. Только не два мегабайта кода. Локализуй до 50-100 строк, не больше.
>
>
Если бы у меня было время всё бросить и сесть с отладчиком локализуя до 100
строк кода я бы не отказал себе в удовольствии самому покопаться. Но эта
задача у меня в самом конце TODO, а если это действительно баг в gcc, то его
стоило бы локализовать пораньше...

Проблема обнаружилась в liblensfun. Эту библиотеку сейчас использует ufraw.
Скомпилированный при помощи gcc 4.3 код отлично работает в ufraw. Для
компиляции gcc 4.4 пришлось приложить патчик на тему const char, но он тут
даже теоретически не может быть при чем, поскольку чинит сборку своего
makedep и ABI посему никак сломать не мог.

Если использовать gcc 4.4, то даже с "-O0" компилируется нерабочий код.
Симптом: ufraw при открытии любого файла зависает, вероятно где-то
зацикливаясь(?).
----------- следующая часть -----------
Вложение в формате HTML было удалено...
URL: <http://lists.altlinux.org/pipermail/sisyphus/attachments/20090817/c563c7bc/attachment-0001.html>