GCC пищит или sizeof(u32) != 4

Открою тебе секрет: можно собирать сборку с отладочной информацией и одновременно со включенными оптимизациями.

Открою тебе секрет: можно собирать сборку с отладочной информацией и одновременно со включенными оптимизациями.

трепло же ты какое... ничего тебе доверить нельзя, все секреты выбалтываешь

А при чем тут sizeof(u32)?

Вероятнее всего, с -O0 он генерирует универсальный код, не вычислив sizeof(val) * 8

а там -O0. SHA1 сильно базируется на rol

И неужели нету современных реализаций с использованием SIMD?

Так с оптимизацией вылезут все UB в говнокоде, так неспортивно.

Ага, чтобы потом вместо шагов а, б, ц получить константу на выходе. Гдб от этого раком воет.

Попробуй собирать с -Og.

Многие баги можно отладить и с -O2. Просто придётся смириться с тем, что GDB будет скакать по строчкам не в том порядке, в котором ты ожидаешь. А для сложных багов можно временно запускать версию с -O0 и терпеть потери производительности.

Для сложных багов в распоряжении обычно только core-файл.

Рекомендую купить камни с поддержкой аппаратного SHA :)

бред, когда уже детей по банят с лорчика, а то считать разучились, по ссылке как раз sizeof(uint) == 4 потому что 32 в итоге

Совсем анон слепой пошел. sizeof(u32) равен 4. И это известно еще до компиляции. Вот только gcc про то что 4 * 8 можно сократить до 32 и заюзать ror забыл и сгенерировал тонну кода.

С -O0 он и не должен об этом вспоминать. Он генерит код в лоб, как если бы там было любое значение.

sizeof - это не функция.

Это все равно что в

#define AAA (5)

i = AAA;

Как видишь, в gcc это выражение раскрывается не на том же этапе, как просто 32.

и в чем же тогда разница, если 32 - n он раскрывает в одну инструкцию, а <32> - n - нет?

В том, что твой #define AAA (5) развернет препроцессор еще до компиляции, а 8*4 может посчитается сходу компилятором, а оператор sizeof на первом проходе он оставит напотом и в итоге с концами при -O0.
Чему тут негодовать не очень ясно - просил О0 - на те код без любых движений в сторону оптимизаций.

потому что sizeof — это оператор, который, например, для массивов переменной длины должен вычисляться?

без любых движений в сторону оптимизаций.

Хмм.

gcc -Q -O0 --help=optimizers
gcc -Q -O3 --help=optimizers

Попробуй xxhash, а также всякие SIMD реализации других хэш функций типа adler32.

И?
Какие-то опции где-то неотключаемы, где-то невключаемы.

-O0 не выключает оптимизации, он:

-O0 Reduce compilation time and make debugging produce the expected results.

Т.е. движения в сторону оптимизаций при -O0 всё же имеются.

Т.е. движения в сторону оптимизаций при -O0 всё же имеются.

Т.е., он был был бы рад сделать еще хуже?

Странный вывод.

Надо ещё добавить, что некоторые оптимизации в GCC нельзя выключить, потому что даже настроек для них нет. Например if (0) { something(); } он выкидывает очень рано и выключить это не представляется возможным.

Вывод в том, что для разных архитектур/таржетов куча всего существует, чего-то специфического, чего-то обобщенного, потому и с -O0 для чего-то названо оптимизацией, для чего-то нормой.

if (0) { something(); } он выкидывает очень рано и выключить это не представляется возможным.

Куда?

Куда?

В вакуум.

тупой авто поста, который пытается учить gcc как ему лучше при этом отключает все оптимизации
и да, дебаг информацию можно оставлять и при -O3, учите основы

-O0 НЕ отключает оптимизации. Читай мануал.

Clang так и делает. При -O0 не оптимизируется вообще ничего - что гарантирует что ВЕСЬ код останется, даже если там невообразимая хрень.

Не могём. Мы тут активно избавляемся от юза сторонних либ, потому что даже openssl которую мы юзаем раз в N дней падает у себя в кишках. Обновить не можем, потому что на узлах ядро заморожено (а обновить 2к+ узлов которые разбросаны по стране с вероятностью сделать кирпич достаточно проблематично). Поэтому пишем такие приложения которые в идеальном случае вообще ни от чего не зависят. Написали базовую либу с реализацией практически всего что может пригодиться, поверх нее намутили еще пару и этим и пользуемся. По скорости кстати интересные вещи - memcpy/memmove/memset из либы под linux работает чуть медленее (из-за дополнительных проверок), зато под minix дает ощутимый буст скорости. Будет время - запилю пост с вайнингом почему миникс такое говно.

Зачем использовать какой-то «u32», когда есть stdint.h и uint32_t?

Вот такое тоже генерит ror (-std=c++14):

u32 func1(u32 val, u32 n)
{
    constexpr int shr = sizeof(val) * 8;
    return val >> n | val << (shr - n);
}

Я подозреваю спекуляцию на UB signed integer overflow: https://wandbox.org/permlink/UqGgcXpKTb8kVzHP

typeof(sizeof(val) * 8) = unsigned long
typeof(32)              = int

ЛОЛ 32ul тоже генерирует shr, https://godbolt.org/g/vVsh8w

u32 func2(u32 val, u32 n)
{
    return val >> n | val << (32ul - n);
}

Я подозреваю спекуляцию на UB signed integer overflow

Откуда спекуляция? Сдвигается беззнаковое.

Вот когда в c89 завезут stdint вот тогда и поговорим.

Откуда спекуляция? Сдвигается беззнаковое.

В случае 32 - n, а не сдвиг. Просто лень дальше думать.

Вот когда в c89 завезут stdint вот тогда и поговорим.
когда в c89 завезут

Скорее с89 куда-то вывезут (на катафалке и с лопатами).

Что-то с 1990го года не спешат. Наверное катафалки закончились или все еще компилируются на моднявых недоязычках. А с89 вечен. Все конторы типа Keil и проч всегда сначала делают поддержку с89 для своих компиляторов, а уже потом лет через 15 - с99 и последующих.

Гомопроблемы проприетарщиков со штатом состоящим из полутора престарелых макак.

Что-то с 1990го года не спешат.

Если вы хотите видеть в результирующем коде нужную вам последовательность инструкций, вы и должны написать их, то есть на ассемблере. А не заниматься 30 лет онанизмом, перебирая -Ox под разные версии компилятора, выискивать этот код и сокрушаться, что в очередной раз компилятор более (пусть и не очень) уровня генерит не то.

во во, clang при -O0 вообще никаких роров в обеих случаях не генерит, да и не обязан, но школьник бегает доказывает что аяяй какой компилятор ему рор не вставил

вы и должны написать их, то есть на ассемблере

На все архитектуры разом?

На все архитектуры разом?

Креативное цитирование детектед. Какой хочет автор увидеть, на том и писать.