savinov_ao21 апр 2011 в 19:08

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

1 мин

+20

Комментарии 40

int02h 21 апр 2011 в 19:24

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

aviaconstructor 21 апр 2011 в 20:26

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

int02h 22 апр 2011 в 04:57

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

tehdeel 22 апр 2011 в 08:05

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

ValdikSS 22 апр 2011 в 08:19

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

tehdeel 22 апр 2011 в 10:10

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

uranik 22 апр 2011 в 15:03

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

int02h 22 апр 2011 в 19:14

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

НЛО прилетело и опубликовало эту надпись здесь

mikhanoid 22 апр 2011 в 08:43

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

НЛО прилетело и опубликовало эту надпись здесь

Ilya_Smelykh 22 апр 2011 в 06:50

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

amdf 22 апр 2011 в 06:55

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

mikhanoid 22 апр 2011 в 08:45

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

amdf 22 апр 2011 в 09:07

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

andrewsh 22 апр 2011 в 12:38

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

НЛО прилетело и опубликовало эту надпись здесь

AlexTikhonov 22 апр 2011 в 07:36

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

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

dio_t 22 апр 2011 в 08:23

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

AlexTikhonov 22 апр 2011 в 09:43

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

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

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

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

dio_t 22 апр 2011 в 09:47

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

int02h 22 апр 2011 в 19:19

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

tzlom 21 апр 2011 в 19:38

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

TheShock 21 апр 2011 в 19:42

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

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

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

emaxx 21 апр 2011 в 19:46

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

tzlom 21 апр 2011 в 20:25

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

$ 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 22 апр 2011 в 06:39

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

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

9mm 22 апр 2011 в 07:43

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

mordet 22 апр 2011 в 07:43

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

9mm 3 мая 2011 в 16:13

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

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

ElleSolomina 22 апр 2011 в 08:04

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

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 22 апр 2011 в 08:06

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

yeputons 22 апр 2011 в 08:50

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

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

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

yeputons 22 апр 2011 в 08:51

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

ElleSolomina 22 апр 2011 в 09:07

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

BearOff 22 апр 2011 в 10:45

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

tipok 22 апр 2011 в 08:33

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

billyevans 22 апр 2011 в 09:30

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

AlexTikhonov 22 апр 2011 в 10:10

Дополню:
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 24 мая 2011 в 17:55

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий