> что регистра стека в общем случае может и не быть, а он заменяется фреймом вызова, адреса в котором заполняет компилятор
Я не понял что вы имеете ввиду, но если у вас есть своя идея на этот счёт — то ОК.
Регистр флагов — легко. Любая арифметическая команда в x86 обновляет регистр флагов. Это обеспечивает наличие цепочки зависимостей из-за регистра флагов для очень большого количества команд. Хотя на самом деле в подавляющем большинстве случаев все эти флаги от арифметики никому не нужны. Нужны условные переходы и условная пересылка, и если очень сильно хотите — то примитивы для арифметики произвольной точности (которые с carry in и carry out).
If a side effect on a scalar object is unsequenced relative to either a different side effect
on the same scalar object or a value computation using the value of the same scalar
object, the behavior is undefined.
Я сильно извиняюсь, совсем забыл что для MemorySanitizer нужно использовать инструментированную стандартую библиотеку C++, а я использовал обычную — отсюда ложное срабатывание (считалось что n не инициализирована, но она инициализируется кодом в стандартной библиотеке во время чтения из cin). Перпроверил — в вашей программе всё ОК, остальные не перепроверял.
Вы правы! Я вчера прогнал топовые решения под AddressSanitizer, Undefined Behavior Sanitizer — ничего не нашёл и совсем забыл про Memory Sanitizer. Как оказалось, зря — там всё плохо.
В решениях bklim, dark1ight, Icemore, madkite, MaSaK, Mrrl, ripatti, udalov, vbarinov, VladVR, ZhekSooN есть использование значений неинициализированных переменных.
Что такое Extended ASCII Codes? (Такого понятия нет в стандарте.) Я понимаю что ошибок не было, но это добрая воля компилятора (по стандарту он мог бы и отказаться это компилировать).
Строго говоря, компилятор не обязан допускать во входном коде символы за пределами extended character set. Clang ориентирован на UTF-8, поэтому на не-UTF-8 он ругается. (А мог бы и вообще ошибку кидать — и был бы прав.)
Кроме того, библиотеки, собранные clang и gcc совместимы по ABI.
> что регистра стека в общем случае может и не быть, а он заменяется фреймом вызова, адреса в котором заполняет компилятор
Я не понял что вы имеете ввиду, но если у вас есть своя идея на этот счёт — то ОК.
Регистр флагов — легко. Любая арифметическая команда в x86 обновляет регистр флагов. Это обеспечивает наличие цепочки зависимостей из-за регистра флагов для очень большого количества команд. Хотя на самом деле в подавляющем большинстве случаев все эти флаги от арифметики никому не нужны. Нужны условные переходы и условная пересылка, и если очень сильно хотите — то примитивы для арифметики произвольной точности (которые с carry in и carry out).
Как это вы совместили rsp/rbp в одном регистре?!
Уберите регистр флагов. Простои конвейера из-за зависимостей команд по этому регистру — очень плохая вещь, которую принципиально никак не исправить.
Вот некоторым атомам вообще нужно в коротких функциях перед ret поставить пару nop и в результате будет быстрее.
Сделайте честное сравнение с одинаковыми алгоритмами.
В FreeBSD уже ушли с GCC, Debian на подходе.
Перепроверил ваше решение — всё ОК.
Термин «UTF-8 последовательность» — согласно спецификации Unicode (в версии 6.2 это определение D86 в главе 3).
В решениях bklim, dark1ight, Icemore, madkite, MaSaK, Mrrl, ripatti, udalov, vbarinov, VladVR, ZhekSooN есть использование значений неинициализированных переменных.
Вообще-то, компилятор не придирается, а выдаёт полезные диагностики.
К чему ещё в вашей программе можно «придраться»?
А почему не 3.2?