Средства и методы разработки

GCC. Потеря точности вычислений плавающей точки в приложении с ключами компилятора по умолчанию (предположительно). Какие ключи покрутить? Пугает, что подобное может всплыть где-нибудь в моём проекте. Подробности ниже (много букв). 

Есть проект ArgyllCMS. По данным измерений, выполняет расчёты 3d и 4d LUT, в итоге, включаемых в "цветовой профиль" устройства - принтера или сканера - устройства вывода или ввода цветовой информации. Штука довольно сложная - нужно находить соответствие 4х-мерному входу 3х-мерного выхода и в обратном направлении - 3х-мерному входу 4х-мерного выхода. При этом, соблюдая ряд ограничений, например, границы "цветового охвата" устройства, целевую "генерацию чёрного" и общий лимит чернил (total ink limit, TIL).

Для примера, вывод в процессе построения простого цветового профиля 4-х канального устройства вывода:

Estimating white point
Approximate White point XYZ = 0.80060709 0.82611489 0.66530101, Lab = 92.844078 0.796675 1.495786
Creating optimised per channel curves
Initial White Point XYZ 0.800607 0.826115 0.665301, Lab 92.844078 0.796675 1.495786
About to optimise temporary matrix
 100%
About to optimise a common ord 0 input curve and matrix
 100%
About to optimise a common input curve and matrix
 100%
About to optimise input curves and matrix
 100%
About to optimise output curves and matrix
 100%
About to optimise input curves and matrix again
 100%
About to optimise input, matrix and output together
 100%
About to adjust a and b output curves for white point
About to create grid position input curves
Create final clut from scattered data
**********************************************************************************************************************************************************************************************************************************************************
Doing White point fine tune:
Before fine tune, rel WP = XYZ 0.964143 0.999927 0.824966, Lab 99.997193 0.001679 -0.009730
After fine tune, rel WP = XYZ 0.964203 1.000000 0.824905, Lab 100.000000 -0.000000 0.000000
                 abs WP = XYZ 0.80055652 0.82605477 0.66534975, Lab 92.841438 0.798162 1.486688
White point XYZ = 0.80055652 0.82605477 0.66534975, Lab = 92.841438 0.798162 1.486688
Find black point
Neutral black direction (Lab) =                     13.544112 0.216654 0.403549
Black point XYZ = 0.00868917 0.00890596 0.00752847, Lab = 8.044637 0.408805 -0.339367
Done A to B table creation
Setting up B to A table lookup
Creating B to A tables
Rev cache RAM = 26800 Mbytes
Initializing nnrev arrays...
There is 1 rev cache instance with 26800 Mbytes limit
nnrev initialization done
Initializing nnrev arrays...
There are 2 rev cache instances with 13400 Mbytes limit
nnrev initialization done
100%
Done B to A tables
Creating gamut boundary table
100%
Done gamut boundary table
Profile check complete, peak err = 1.925068, avg err = 0.368567, RMS = 0.440609

Проблема в следующем: код, скомпилированный автором, работает нормально и в Windows, и в Linux. Код, скомпилированный мной в Linux, для вычислений сопоставлений 3d<>3d работает нормально, 4d>3d нормально, а вот 4d>3d с дефектами. См. для примера, картинку. На графике - ровное - результат работы сборки автора, неровное - результат моей сборки.

Это график ещё с 2018г. Для справки - на графике кривые для получения серого клина. По оси X - плотность серого, слева белый, справа - глубокий чёрный. По Y - процент подачи чернил по каждому из 4х каналов принтера - голубому, пурпурному и чёрному. Оба варианта, кривой и гладкий (правильный) получены на одном и том же ПК, кривой - в Linux, гладкий - в Windows. Причём, дефект - изломы кривых, наблюдался и c моей сборкой, и со сборкой автора. Я присылал автору, Грэму Гиллу, исходные данные и команды, давшие такой результат. Грэм не смог повторить проблему в своём окружении. У него всё получалось гладко, и в Windows, и в Linux. Написал только, что: "Best guess though is some sort of numerical issue due to different compilers. The code shouldn't be so sensitive to such a thing..." Больше ему не удалось ничего выяснить, так как не получилось повторить проблему (сильно не старался, кроме меня, ни от кого жалоб не было).

Какое-то время, я строил цветовые профили в Windows, используя сборку автора системы, полагая, что в Linux оно не работает должным образом. Теперь снова вернулся к вопросу. Проверил свою сборку ArgyllCMS. Так же, ломает кривые и результат не применим на практике из-за дефектов. Ранее автор не публиковал сборки для Linux из-за разношёрстности систем. Но теперь публикует и его сборка у меня запустилась и даёт хорошие результаты. Собственно, вопрос: чем могут отличаться сборки GCC и что может приводить к существенным ошибкам в вычислениях?