Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, LaptevVV, Вы писали:

S>>>На 64 битах результат подтверждаю.
LVV>>В смысле — в 100 раз хуже gcc?

_>В 100 раз хуже и gcc и себя самого (но только при наличие никчемной строки).

Не нужно потешаться над такими сложными продуктами как компиляторы. Мне приходилось очень часто сталкиваться с багами как GCC, так и MSVC.
Вот к примеру чуть более года назад столкнулся с ошибочной кодогенерацией GCC 4.8, который предоставляет Google для сборки андройда. Собирал я тогда 6-ой андройд для мобилки (до этого собирал 4-ый андрой при помощи GCC 4.7). Так вот после сборки оказалось, что WiFi драйвер по страшному чудит. В dmesg логе было видно место возникновения паники, но в этом месте ничего криминального не было. При чём небольшое изменения кода смещало место возникновения паники.
При исследовании при помощи изменения кода и просмотра ARM кода в IDA удалось понять, что бага не в коде, а в компиляторе. И проблема была в том, что эта версия GCC при обильном инлайне нескольких функций начинала некорректно работать с переменными на стеке. В IDA отчётливо наблюдал тот факт, что место на стеке использовалось несколькими переменными. Т.е. с какого то перепугу GCC посчитала, что далее по коду переменная Х уже не используется и можно регистр R использовать для новой переменной N. И это была роковая ошибка GCC (регистр R содержал лютую дичь), из-за которой сбой происходил только после нескольких возвратов из функций.
Использование GCC 4.9.4 решило проблему.

А буквально недавно пришлось компилить OpenSSH-Win32 под VS2010 SP1. Так вот при линковке sshd.exe линкер просто падал. Но подал с выдачей названия c-файла, который он посчитал дурным. Довольно быстро локализовал проблемное место: обычный switch и три case. Пришлось один из кейсов вынести за предел switch'а , что бы кодогенерация была корректной. В дизасм заглядывать было влом.