> Достаточно на другой машине собрать gcc, а им - собрать gcc. Можно
> для сравнения собрать gcc clang и этим собранным gcc пересобрать себя.
> Если будут различия - дизасм и прочий анализ, вряд ли их
> будет много. После чего можно этот gcc фиксировать как эталонный.

На другой машине придётся собрать именно эту версию gcc. Если предположить, что в gcc нет багов, которые могут приводить к тому, что оптимизация неустойчива, то этого будет достаточно. Если предположить, что расположение файлов на диске не влияет на работу, configure && make -- если они генеря правила make, а потом обрабатывая их, и обращаясь к списку файлов в директории, сортируют этот список прежде чем использовать, а не используют в том виде в котором ядро выдало. Если не сортируют, то оказывается, что ещё tar может повлиять на воспроизводимость сборки. Я не вижу, как могут повлиять на воспроизводимость флаги -jN для make, но я вот нисколько не буду удивлён, если они могут повлиять.

Это то, что я навскидку придумал. Я не затрагивал, например, работу ld -- я никогда не вникал в деталях что и как он делает, но он выпоняет довольно сложную работу, для того, чтобы даже смена минорной версии могла бы привести к изменению результатов. Всякие там его скрипты, про которые я иногда вижу упоминания, но не вдавался в подробности как они работают, как их писать, патчатся ли эти скрипты мейнтейнерами gentoo, лежат ли они на диске или для ELF они вкомпилированы в ld статически...

Короче, ваш энтузиазм, вида "достаточно взять и собрать", для меня выглядит скорее проявлением эффекта Даннинга-Крюгера, чем аргументом. Может я ошибаюсь, но если так, то намекните хотя бы на свой опыт создания бинарей бит-в-бит на разных машинах.