Имам следния въпрос - налага ни се да работим с различни компилатори, и с различни версии на някой от тях. С някой от тях срещаме проблеми - т.е. бъгове. По-точно всички имат бъгове, но някой са безобидни, други са сериозни. Лошото е че често, особено с gcc, има регресии и в нови версии се появяват проблеми, които ги е нямало в по-стари.
За да "вземем на въоръжение" даден компилатор или нова версия просто, трябва да направим някакъв тест (верификация) че няма да счупи изпълнимия ни код, като мине през него. Това е валидно за всички компоненти - вътрешен сорс, външни библиотеки/сорсове, инструменти и т.н. В момента съм на тема проверка на компилатора. Та значи някой има ли идея за подобен 'test suite"? Безплатен или платен, е, стига да е в границите на поносимото?
Знам че примерно gcc имат доста тестове, но явно не достатъчно, поне в нашата насока - embedded C. Казвам го заради срещнати реални проблеми с 4.5.2 и 4.7.2. Накрая се оказва че има отворени бъг репорти за тези неща, но не мога да разчитам на това че някой вече го е видял, т.е. готов съм да инвестирам ресурси в това да проверявам за себе си.
Простата постановка с тестване на резултатния продукт не е ефективна, поне при нас - възможно е да има спящи проблеми които да са пропуснати при тестването. Справка - всеки се е сблъсквал с това за себе си, а и тойота го имат тоя проблем. Т.е. изчистването на развойния процес е базовата стъпка, тестването си следва.

ти изби рибата

Я кажи бъг на gcc че ми стана интересно?

Иначе задачата е нерешима и това се вижда от самолет... Няма начин на 100% да провериш дали едно предварително неизвестно множество съответства на друго неизвестно множество

Сега, ако точно на теб трябва да ти посочвам url-а на bugzilla-та на GNU... Ама добре, щом не я знаеш:
http://gcc.gnu.org/bugzilla/buglist.cgi?component=c&product=gcc&resolution=---

Чакай да позная - ти май си мислише че gcc няма бъгове?

Както и да е, конкретният бъг при нас се проявява като неправилно поведение за volatile променлива при ниво на оптимизация, различно от 0. ID на бъга трябва ли ти? Ето ти линк: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56098


Конкретно по темата - трябва ми такова, ама по-евтино:
http://www.ace.nl/compiler/supertest.html

Естествено че няма перфектен софтуер и точно поради същата причина не може да има и надежден верификатор... то ако имаше други преди теб да се бяха сетили да го пуснат

Просто ми стана любопитно какво си настъпал, защото ползвам gcc от доста време и не ми се е случвало да го хващам в крачка. Иначе при всеки нов релийз редовно има бъгове, но общо взето се чистят много бързо. Наясно си предполагам колко линукс дистрибуции се компилират и колко други неща, включая и самото gcc... така че ако не работиш с най-най-най последната версия и след като другите преди теб са успели да компилират тонища софтуер трябва да си голям кърък да настъпиш нова мина

Учудването ми беше не по-малко когато ме информираха за този бъг, нещо основополагащо в ебмеддед. Само че го видях и към последната по онова време версия на gcc-то си го имаше, т.е. към онзи момент нямаше заобикаляне освен оптимизация 0. Към момента е решен, и има добавен test case, т.е. очаква се повече да не го видим (ако test case-а е достатъчно добър). Остава въпросът каква е следващата "мотика" (цитат).

Относно не-моженето - не е като да не може, точно тия ACE имат доста сериозен suite. Дали е надежден? Сигурно не е на 100%, ама едно е 1е-6, друго е 1е-12 вероятност. По-точно разликата е точно колкото да минеш сертификация, и да не минеш.
"Сещането" за пускането е едната част от работата. Трябва някой да ти го даде, или да си го напишеш. С даването (купуването) явно не става (за гцц), така че са се хванали да си го пишат. Като стигнат нивото примерно на тия ACE, ще съм спокоен че са на качеството им (може би, то само като брой test case-ове не е достатъчно).

И просто като информация - във връзка с темата за low cost boards - тексаският ARM компилатор е минал през и издържал този suite - чекни SafeTI. Още една "дреболия" в негова полза. Не казвам че го е минал от раз, т.е. писачите на тексас, били те в анадола или индия, едва ли са много добри. Просто са ги сцепили от работа докато стане като хората. Но на клиента не му пука - получава по-високо качество, за което си плаща. Дали си заслужава цената? Това е въпрос, на който всеки трябва да си отговори сам за себе си.

Мнението ми е, че си губиш времето. Знам че с това не ти помагам особено да си намериш решение на проблемите, но понякога е полезно и да знаеш дали проблемът е решим. В случая да тестваш gcc с верификатор е точно толкова полезно, колкото и ония уредчета в контакта за намаляване на сметките за ток.

Все пак ако имаш повечко свободно време те съветвам да го отделиш в подобрения на твоя софтуер. Нямам идея какво точно програмираш, но ако можеш примерно да си правиш неща от сорта на селф тест ще ти бъде далеч по-полезно. Вероятността в твоя код да има бъг е няколко порядъка по-висока отколкото в gcc. С това не искам да те засегна, при всички е така и е нормано да е така, защото с тестове или без тестове голяма част от проблемите на едно изделие рано или късно стават видими. И тъй като gcc (а и други компилатори) е в основата на милиони изделия, евентуален проблем в него има милион пъти по-голяма вероятност да избие на повърхността, отколкото софтуер който се ползва само в едно-две изделия...

Хм, едното няма общо с другото. И двете трябва да се свършат. Моите (нашите) неща са си наши, и там има много трески за дялане, но са си наши и имаме много възможности.
Инструментите (като gcc) трябва просто да работят. Това са като слоевете в софтуера. Редовите програмисти очакват компилатора да работи. Проверяват си кода статично със скъпи чекъри и си правят модулни тестове. Бозата с volatile беше трудна за хващане, и едно от затрудненията беше очакването че компилатора работи коректно.
Така де, номера да кажа на някого да пише по-добър код не върви, ако на код, който е мина всякакви чекъри и review от няколко човека, компилатора прави мизерии и забавя проекта.

Разбирам, ама това е положението...

Един истински верификатор би имал далеч по-голяма сложност от самото gcc, няма кой да седне да се занимава....

Тия верификатори дето гледаш дебнат за стандартни/често срещани проблеми... Определено ще са ти полезни ако седнеш да си пишеш собствен компилатор, обаче за gcc - забрави! Пак ти казвам, че става дума за супер-дупер използван инструмент. Ей на - аз от няколко години съм с лайнукс (както и много други хора). Почти всичко дето ползвам е резултат от гцц-то. Като голяма част от програмите (включая всички гцц тулчейни) съм си ги дърпал на сорс и компилирал лично.
Нали се сещаш че ако имаше стандартни и елементарни бъгове компа ми щеше да зависва през 5 мин...
От друга страна ти се натъкнал на мина... но забележи че това са бъгове дето нямат хващане. Трябва ти определена последователност в кода плюс специален хардуер за да разбереш че е имало едно излишно четене. Абсурд!

с изследване на компилатори се занимават аспиранти и докторанти във богословския факултет, които вече имат магистърска степен по математика...

както миро добре дефинира задачата, тя е "да провериш дали едно предварително неизвестно множество съответства на друго неизвестно множество". можеш бавно и славно да попълваш едното множество с твои виждания за мотики, които или ти си настъпвал, или си чувал другите да настъпват. или пък с мотики, които ползваш в твоите програми. и целенасочено да тестваш поведението им за наличие във второто множество. нещо такова се опитва да прави configure (autoconf, automake и приятели) - да установят някакво множество на мотики и да се опитат да адаптират текущата задача към него,

подходите са експериментален, научен или с купуване на чужд набор мотики. въпрос на баланс време-пари е кой да избереш.

разбира се, много е неприятно, когато основен инструмент започне да се дъни във фундаментални неща. за съжаление нещата станаха много по-сложни, отколкото може да ги следи обикновена биологична единица. едно време процесорите се правеха от десетина души екип, имаха по стотина инструкции, който хардуерно се изпълняваха с транзистори направо. сега процесорите се компилират, няма жив човек, който да може да проследи какво прави дори някой под-модул със стотина хиляди транзистора вътре. съответно и компилаторите последваха комплексността на желязото. дори Мур надали си е представял до къде ще стигне днешната железария, когато е постулирал закона си, дори наскоро обяви, че очаква закона му да престане да действа, поради достигане на атомното ниво.

но нямам спомен някой да е постолирал някаква зависимост за софтуера. първия дос за епъл беше 4К. дос 3.1 за РС беше стотина. вин-7 е над 2GB, при това прословутия notepad.exe продължава да не може да работи с файлове по-големи от 64К (един DS-сегмент)... разходите за верифициране отдавна надхвърлиха разходите за писане. това роди и концепцията ХР (eXtreme programming) - два етажа писачи бълват някакъв код на кило, после два етажа цъкачи правят списъци с бъгове. над тях два етажа координатори движат тикети между двете групи и ги сортират по спешност. качеството няма значение, защото се компенсира с количество. при това евтино количество. в крайна сметка подхода дава резултати - за 6м вадиш прототип, зарибяваш клиентите. после ги доиш 10 години с ъпдейти през 2 седмици и страскащо дълги списъци с бъгфиксове. на етажите с шефовете всички са доволни - производителя: "цъкачите са фанали 20К бъга за месец"; клиента: "тия са страшно добра фирма, виж колко бъга са отстранили, при това само на цената на поддръжката". в тази ситуация обикновено има и един-два етажа тунеядци, занимаващи се със "сертификация", разбирай теоретично и практическо сектанство.

и някъде между етажите, в някой килер, уж имало един доблестен програмист, който за чест и слава пишел gcc и го дарявал на хората...
аааа, забравих и за мармота, дето завива едни компилатори със станиол

Не мисля така.
Ето 4МБ файл с 34151 реда.

Относно темата: Ако целта е регрешън тест, не виждам какъв е проблема това да се направи.
Това обаче може да ти гарантира единствено, че няма регресии за твоето приложение.

добре, признавам прогреса. останал съм в заблуда заради разликата в поведението на notepad и wordpad...
но духа на написаното остава същия.

Сори за офтопика, ама...
ДедоБоре тия мотики за нищо ги нямате вече... Освен да ги настъпвате, вземете ги хванете както трябва - за дръжката.