Мужики, такой вопрос к вам. ОС- WinXP SP1. Тачка- П4 3Ггц 512 Рема.
Одна и та же программа. В предыдущих версиях ФПЦ и во всех версиях Делфи 3+ компилируется без проблем. Работает как часы. Всевозможные лики, промахи давно подчищены. Решил откомпилировать прогу новой версией FPC от 24 Feb 2005. Всё нормально скомпилировалось. Запускаю. Прога минут 10 работает-- потом вылетает с invalid floating point operation. Думаю, может систему просто сглючило, хотя ни одно приложение не глючит-- перезапускаю. Пол часа отработало-- опять аут с той же глюкой. Запускаю третий раз-- буквально через две минуты работы слетает. Полный бред.
Компилю в предыдущих версиях FPC -- всё классно, днями работает--не вылетает. Дельфёй 6.0-- днями работает и не вылетает. Опять компилю новым ФПЦ-- 15 минут отработало, слетело.
Что за бред? Может кто-то сталкивался, знает как побороть эту фигню???

А на чем хоть слетает-то?

Дык в том то и проблемма, оставил всю дебажную инфу уже, отрубил все какие есть оптимизации.
Окромя как invalid floating point operation и адресс--ничего другого не выдаёт. Дебагера нормального нет. Так бы можно было посмотреть. И самое хреновое-- в абсолютно разные моменты времени происходит. Нет такого, чтоб чётко при какой-то операции в программе, или через определённый интервал. То же самое скомпилированное в Делфи или ФПЦ предыдушей версии--работает как часы. Блин хоть бери и дифом разруливай все изменения, что произошли 8((.  
Конечно, можно загрузить в OllyDbg и посмотреть на уровне асма, где и что---но это неправильный подход.

А как насчет опции -gl?
Мне часто помогает, когда неохота отлаживать по строкам

Может не в тему, но я как-то читал о том, что иногда происходит некорректное перепрограммирование регистров проца отвечающих за режимы работы с плавающей запятой. Это может вылазить всякого рода багами... Может отсюда ноги растут? Правда я это читал про работу вообще, а не в FPS.

> Окромя как invalid floating point operation и адресс--ничего
> другого не выдаёт


А адрес каждый раз разный?

Сорри, долго не заходил. В общем там всё совсем плохо, попробовал даже на релизе 2.0. Короче со всей дебагой эта штука выдаёт ошибку на 417( по моему, сейчас на работе) строчке lcltype --то секция определения констант, никакого там эксепшна быть не должно. Ну да ладно, подумал я. Может просто юнит глюкавый, да и нужен мне с него был хедер БМП. Вынул я хедер БМПхи, ушёл от lcltype. Ну, думал, может теперь всё ништяк будет. Фиг вам. Поработало минут 10--завалилось. Запустил опять--поработало полчаса и завалилось. И главное.... Показывает тот же самый эксепшн.. на 417 строчке другого юнита. Я уже решил дойти до максимума мароазма, убрал этот юнит с uses. Запустил... То же самое поведение, тот же самый эксепшн.. 417 строка другого юнита. 8(((
После этого я вернулся на Делфи, всё как часы теперь работает. Для прикола скомпилировал компилятором версии до 24 февраля. То же всё как часы. Такая подляна....

Может быть, такая ошибка возможно появляется из за переполнения стека, либо просто со стеком работа неправильно ведётся?

Гм,... сумневаюсь. Ассемблерных вставок(моих) там 100%нет, рекурсию,-- я со студентческих времён всосал догму про избегание рекурсий там где это возможно. Да и проявилась бы эта ошибка тогда и на предыдущей версии Фрипаскаля и на Делфи. А её там нет. 8(

А случаем инструкции компилятору использования ММХ не используешь? А-то там после таких операций нужно восстанавливать регистры сопроцессора, не помню какая инструкция, EMMS кажется, забыл.

Не, ММХ не юзю. Сырцы такие, что фактически без изменений компилируются и в Делфи и в ФриПаскале. А в делфи модуля ммх и типов ммхатых нет. Да и генерировать код я уже даже под 386 поставил, поотрубал все оптимизации. То же самое.

Не используй оптимизацию по регистрам и FPU одновременно! Поскольку в компиляторе FPC с этим глюки.

Я ж написал, что поотрубал все оптимизации. Про проблеммы с размещением переменных по регистам--эт я знаю, это у него хроническое 8)