savinov_ao Apr 21 2011 at 23:08

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

1 min

2.9K

C++*

+20

Comments 40

int02h Apr 21 2011 at 23:24

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

aviaconstructor Apr 22 2011 at 00:26

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

int02h Apr 22 2011 at 08:57

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

tehdeel Apr 22 2011 at 12:05

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

ValdikSS Apr 22 2011 at 12:19

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

tehdeel Apr 22 2011 at 14:10

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

uranik Apr 22 2011 at 19:03

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

int02h Apr 22 2011 at 23:14

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

UFO landed and left these words here

mikhanoid Apr 22 2011 at 12:43

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

UFO landed and left these words here

Ilya_Smelykh Apr 22 2011 at 10:50

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

amdf Apr 22 2011 at 10:55

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

mikhanoid Apr 22 2011 at 12:45

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

amdf Apr 22 2011 at 13:07

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

andrewsh Apr 22 2011 at 16:38

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

UFO landed and left these words here

AlexTikhonov Apr 22 2011 at 11:36

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

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

dio_t Apr 22 2011 at 12:23

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

AlexTikhonov Apr 22 2011 at 13:43

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

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

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

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

dio_t Apr 22 2011 at 13:47

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

int02h Apr 22 2011 at 23:19

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

tzlom Apr 21 2011 at 23:38

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

TheShock Apr 21 2011 at 23:42

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

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

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

emaxx Apr 21 2011 at 23:46

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

tzlom Apr 22 2011 at 00: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 Apr 22 2011 at 10:39

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

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

9mm Apr 22 2011 at 11:43

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

mordet Apr 22 2011 at 11:43

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

9mm May 3 2011 at 20:13

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

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

ElleSolomina Apr 22 2011 at 12: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 Apr 22 2011 at 12:06

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

yeputons Apr 22 2011 at 12:50

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

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

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

yeputons Apr 22 2011 at 12:51

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

ElleSolomina Apr 22 2011 at 13:07

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

BearOff Apr 22 2011 at 14:45

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

tipok Apr 22 2011 at 12:33

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

billyevans Apr 22 2011 at 13:30

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

AlexTikhonov Apr 22 2011 at 14: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 May 24 2011 at 21:55

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