Критическая ошибка gcc

[@int02h]

А вот действительно интересно, программируют ли атомные или космические станции, да и вообще проекты с крайне высокой ответственностью с использованием таких «обычных» средств как gcc?

[@aviaconstructor]

Нет! Конечно же все атомные станции пишут на средствах необычных — вижуальнике, например! :)

[@int02h]

Ну Вы шутник :) При всем уважении к Basic'у, но может там на нем программируют?

[@tehdeel]

тру стори. управление спутниками бывает и на делфи и на вб.

[@ValdikSS]

Судя по вашему аватару, в Омске.

[@tehdeel]

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

[@uranik]

Выходит Бауманка и РосКосмос (делфи и вб) хуже чем Кембридж и НАСА (gcc и java)?

[@int02h]

Видимо дело не в средствах разработки, а в грамотности их использования.

[@mikhanoid]

Неа. Средства не обычные. Там используются системы автоматического доказательства корректности. Проверяется формальная корректность и всё такое прочее. Даже на уровне процессоров. Применяется нечто вроде этого: compcert.inria.fr/doc/

[@Ilya_Smelykh]

Такие вещи программируют на безопасных языках программирования, таких как Ada, например и компилируют другими компиляторами. Ну и многофазный процесс тестирования.

[@amdf]

Мне пришлось некоторое время работать над бортовой программой одного из блоков самолёта SSJ-100. Нам запрещалось использовать опции комплятора, включающие оптимизацию, обосновывалось это именно непредсказуемостью результата оптимизации.

[@mikhanoid]

А какие там процессоры использовались, если не секрет? ПРосто любопытно

[@amdf]

В моём блоке использовался PowerPC 603e.

[@andrewsh]

Может, проще было порой подсматривать в ассемблерный листинг?

[@AlexTikhonov]

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

Просто несколько лет назад пришлось делать кросс-компайл одного проекта на С++ под одну realtime OS, для которой и пришлось докупать отдельный компилятор.

[@dio_t]

Вы не поверите, эти платные средства разработки есть ничто иное как toolchain портированный по конкретную RTOS(VXworks, LynxOS, и т.д.).

[@AlexTikhonov]

Я не то, чтоб поверю, я это знаю :)

Но, насколько я был проинформирован, при заключении контракта на приобретение были указанны компенсации за ошибки, которые могли привести к финансовым потерям.

В моем конкретном случае, компиляторы использовались для построения системы контроля качества при производстве стекол для boing'ов на одном из заводов.

И отвечал я на вопрос что используется в проектах «с крайне высокой ответственностью», и говорил про гарантии, а не про то, что используется какой-то уникальный компилятор.

[@dio_t]

А ну значит не совсем точно вас понял. Я одно время занимался поддержкой GDB для LynxOS (=

[@int02h]

Если не секрет, то какого хотя бы порядка стоимость компилятора?

[@tzlom]

Ох как раздули багу в Development ветке GCC, вам бы не на хабр а в жёлтую газетёнку писать

[@TheShock]

Согласен. Особенно желтая до слепоты фраза:

Будьте аккуратны при написании программ для атомных станций и ядерных боеголовок с применением gcc :)

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

[@emaxx]

А почему g++ 4.6.0 стал вдруг девелопмент-веткой?

[@tzlom]

оке, криво выразился, но

$ eix sys-devel/gcc
[I] sys-devel/gcc
     Available versions:  
//Свечение из глаз заслоняет строки
        (4.5)   (~)4.5.1-r1!s (~)4.5.2!s
        (4.6)   [M]**4.6.0!s             <-- как бэ намекает нам что
                                             на этом мир собирать не стоит

[@yeputons]

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

Это баг хотя бы пофиксили.
А вот такой код на некоторых компьютерах выдаёт, что значение функции без побочных эффектов от побайтово равных значений различно.
Причём никаких проблем с неточным хранением чисел в даблах там, вроде бы, нет — запас приличный.
Впрочем, это баг 10-летней давности, который до сих пор не закрывают (возможно, это связано с различиями в работе даблов на разных платформах).

[@9mm]

Ага, с багодаблами недавно как раз сталкивался.

[@mordet]

Кто же станет сравнивать два double с помощью оператора ==? Это моветон.

[@9mm]

Спасибо кэп, но читать нужно внимательнее:

значение функции без побочных эффектов от побайтово равных значений различно.

[@ElleSolomina]

ну вы блин даёте, а ну идти учить матчасть!!! :)

double переменная с плавающей точкой! Т.е. 1e3 не обязательно равно 10e2 и т.д. Используйте сравнение с определённой точностью и будет вам счастье. Вот пример реализации такого приведения:

#define ROUND(num, denom) (((num) + (static_cast(denom)/2.0)))

или если совсем по православному

inline double ROUND(double p_num, const double p_denom)
{
return p_num + p_denom / 2.0;
}


ps: эту же функцию стоит применять при приведении double к int или к другому целочисленному типу, иначе так же получите проблемы. Поскольку число с плавающей точкой не округляется а обрезается до целой части при таком приведении.

[@ElleSolomina]

прошу прощения если написал сумбурно, был в шоке :)

[@yeputons]

Спасибо за информацию, но даблы в моём примере в тех местах, где надо, сравниваются с точностью до 1e-9.

Фича программы как раз в том, что в main даблы должны сравниваться побайтно, что было явно виден баг оптимизатора. Если у нас функция rdn не имеет побочных эффектов, а аргументы побайтово равны, не должна ли она каждый раз возвращать одинаковый результат? Что же происходит внутри в этом случае — не суть важно.

А теперь, если всё-таки хотим, можем посмотреть на функцию rdn(double x): в первой строке идёт округление дабла. Согласен, если x=0.999999999, то результат будет нулём. Но затем мы прибавляем к этому числу пять (согласитесь, больше погрешности на порядки?), а потом в цикле while уменьшаем число, пока результат строго больше x с определённой точностью.

[@yeputons]

Прошу прощения, я сам был в шоке, а потом понял, что вы комментируете не мой код, а код из репорта :)

[@ElleSolomina]

C++ сам по себе шокирует, а ошибки в нём шокируют ещё больше :)

[@BearOff]

Навеяло:
"В свою очередь, один дабел весит столько же, сколько два лаци."

[@tipok]

Что-то я не понял, как вообще «std::vector» можно использовать с gcc? Это-ж одна из фич с++, а не чистого с. Так что с gcc — всё в порядке, нужно опасаться g++

[@billyevans]

gcc так же GNU Compiler Collection и gcc и g++ его части

[@AlexTikhonov]

Дополню:
The GNU Compiler Collection includes front ends for C, C++, Objective-C, Fortran, Java, Ada, and Go, as well as libraries for these languages (libstdc++, libgcj,...) (src)

А std::vector входит в libstdc++.

[@mxc]

Gcc вообще критичный дальше некуда
rsdn.ru/forum/cpp/3358519.1.aspx