а еще можно репортить баги и не делать UB

А еще лучше код вообще не писать. Я не люблю, когда компилятор пытается меня нагнуть, предлагая переписывать старый работающий логичный код, заменяя на нелогичный бред. А еще идиоты, пихающие рапоследний багнутый компилятор в дистрибутив и выпиливающие нормально работающие, заставляя ставить сторонние тулчейны. Я понимаю что ломать работающее это модно и молодежно, так как чинить сломанное это уже не круто, но по-моему это уже беспредел. Когда они уже угомонятся? Наплодили еще макак, написать пару строчек не может, зато про UB всё знает... все вместо того чтобы фичи писать сидят с одного на другой стандарты переходят и на компиляторы надрачивают... :(

Например сброс знака по (a & 0x7fffffff) не работает

Как не работает? Должно работать вроде, судя по документации.

Проверено, не работает. Не работает даже так

(int)((unsigned)a & 0x7fffffffU)

У меня нет под рукой 8.2, но вот я проверил на онлайн-компиляторе: https://godbolt.org/z/a5VMVm

int myabs(int num) {
    return num & 0x7FFFFFFF;
}

myabs:
        push    rbp
        mov     rbp, rsp
        mov     DWORD PTR [rbp-4], edi
        mov     eax, DWORD PTR [rbp-4]
        and     eax, 2147483647
        pop     rbp
        ret

myabs:
        mov     eax, edi
        and     eax, 2147483647
        ret

Это ты багнутый, а разработчики компилятора следуют стандарту.

А еще лучше код вообще не писать.

Всем станет лучше (в т.ч. и тебе), если ты перестанешь писать код.

Возможно или дебиановцы это сломали, конечно, или где-то наоборот починили. Но пока у меня так, и нини. Архитектура - arm. Минимальный пример:

#include <stdio.h>

int foo(const char *s)
{
        int r = 0;
        while(*s) {
                r += ((r * 20891 + *s *200) | *s ^ 4 | *s ^ 3 ) ^ (r >> 1);
                s++;
        }
        return r & 0x7fffffff;
}
int foo2(int c)
{
        return c & 0x7fffffff;
}

int main()
{
        int result = foo("simple simple some words whatever");
        printf("result: %d %08x\n", result, result);
        result = foo2(-100);
        printf("result: %d %08x\n", result, result);
        return 0;
}

Вывод:

result: -369875866 e9f42466
result: 2147483548 7fffff9c

Вот такая вот странная фигня.

Разработчики компилятора стремятся нагадить везде, где стандарт не написал, что так можно. Проактивное вредительство - это новая фишка, да.

Дык может вам всем просто сдохнуть вместе с хипстанутыми разработчиками и оставить нормальных людей в покое?

Да, забыл сказать - компилировать с -O2, без оптимизаций не прявляется.

Ага, с -O тоже не проявляется, осталось найти багнутую оптимизацию.

Вывод:

result: -369875866 e9f42466
 result: 2147483548 7fffff9c

Вот такая вот странная фигня.

Ты хоть сам знаешь, какой он должен быть?

ну вот точно не отридцательный.

Каноничный вывод:

result: 1777607782 69f42466
result: 2147483548 7fffff9c

если непонятно что делает foo() - делает число из строки, уникальное для данного набора и короче по длине и более дешевое в обработке. В итоге человеку проще писать, а компутеру проще читать. https://ru.wikipedia.org/wiki/Хеширование

Каноничный вывод:

«Каноничный» — «по стандарту»?

Чё ты мне стандартом в морду тычешь? У прадедов работало, у дедов работало, у меня всё работало, пока какой-то моржовый хер стандарт не почитал и не сломал всё.

Достаточно было не говнокодить. Используй говнокомпилятор с говнокодом, если это критично. Ничего нового.

Где ты тут говнокод усмотрел, а?

разве проблема не в int r; r >> 1; ?

дык а в чем там может быть проблема? Почему оно решает забить приложить & 0x7fffffff? И почему они решили вдруг сломать устоявшееся поведение? Типа знаковый сдвиг, ага, могу поистерить и рандомно погадить... Но прикол в том что поведение самого сдвига не изменилось, оно дальше решило нагадить...

У него там целочисленное переполнение еще.

Собери с -fsanitize=undefined и узри.

$ clang -O2 -Wall -Wextra -fsanitize=undefined ub.c -o ub
ub.c:7:50: warning: '^' within '|' [-Wbitwise-op-parentheses]
                r += ((r * 20891 + *s *200) | *s ^ 4 | *s ^ 3 ) ^ (r >> 1);
                                            ~ ~~~^~~
ub.c:7:50: note: place parentheses around the '^' expression to silence this warning
                r += ((r * 20891 + *s *200) | *s ^ 4 | *s ^ 3 ) ^ (r >> 1);
                                                 ^
                                              (     )
ub.c:7:59: warning: '^' within '|' [-Wbitwise-op-parentheses]
                r += ((r * 20891 + *s *200) | *s ^ 4 | *s ^ 3 ) ^ (r >> 1);
                                                     ~ ~~~^~~
ub.c:7:59: note: place parentheses around the '^' expression to silence this warning
                r += ((r * 20891 + *s *200) | *s ^ 4 | *s ^ 3 ) ^ (r >> 1);
                                                          ^
                                                       (     )
2 warnings generated.
[~/repo]-[%] ./ub
ub.c:7:26: runtime error: signed integer overflow: 481340559 * 20891 cannot be represented in type 'int'
ub.c:7:19: runtime error: signed integer overflow: 1752892743 + 454394588 cannot be represented in type 'int'
result: 1777607782 69f42466
result: 2147483548 7fffff9c

Знаковое переполнение — UB. Чини свой код.

И что, это влияет на & 0x7fffffff которое вообще убирает знак? И кстати шланг это правильно компилирует. То есть это скорее баг компилятора чем UB.

Ты, кажется, не понимаешь, что такое UB.

И слишком самоуверен.

Ну плевать мне в этом месте на целочисленное переполнение. Пущай переполняется. Отсебятину зачем гнать? Что потом будет? Будем sin(x) = 2 возвращать или sqrt отридцательный, если где-то рядом большое число не влезло в тип? Стандартное поведение - подрезать до типа, нечего мне мозги компостировать. А потом выполнить побитовую логическую операцию, а не болт на нее положить. UB не дает права гнать отсебятину или случайные числа генерить вместо ответов. Еще биткойны начните там майнить, типа раз UB значит можно... :(

Ты не знаешь, что такое UB, и пишешь чушь.

Отсебятину зачем гнать?

Потому что это UB.

Что потом будет?

Что угодно.

Стандартное поведение - подрезать до типа

Нет, стандарт говорит, что это UB.

UB не дает права гнать отсебятину или случайные числа генерить вместо ответов

Даёт.

gcc version 8.2.0 (Gentoo 8.2.0-r2 p1.2)

result: 1777607782 69f42466
result: 2147483548 7fffff9c

-O2

если с -O2 работает, буду глядеть патчи

When surprised, update your models, зачем бомбить-то?

result: 1777607782 69f42466
result: 2147483548 7fffff9c

точно такой же выхлоп у шланга

clang version 6.0.1 (tags/RELEASE_601/final)

шланг с этим кодом работает, речь тут про gcc,

set -x; for i in {0..3}; do gcc test.c -O$i -o test && ./test; done
+ for i in {0..3}
+ gcc test.c -O0 -o test
+ ./test
result: 1777607782 69f42466
result: 2147483548 7fffff9c
+ for i in {0..3}
+ gcc test.c -O1 -o test
+ ./test
result: 1777607782 69f42466
result: 2147483548 7fffff9c
+ for i in {0..3}
+ gcc test.c -O2 -o test
+ ./test
result: 1777607782 69f42466
result: 2147483548 7fffff9c
+ for i in {0..3}
+ gcc test.c -O3 -o test
+ ./test
result: 1777607782 69f42466
result: 2147483548 7fffff9c

Точно такой же выхлоп с clang 6.0.1

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

Вот это таки говнокод...

Ох лол, ты вообще не в курсе как это работает

https://mirror.leaseweb.com/gentoo/distfiles/gcc-8.2.0-patches-1.2.tar.bz2

https://mirror.leaseweb.com/gentoo/distfiles/gcc-8.2.0.tar.xz

Спасибо огромное!

вот еще ebuild на всякий случай https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-devel/gcc/gcc-8.2.0-r2.ebuild

...
DEPEND="${RDEPEND}
	elibc_glibc? ( >=sys-libs/glibc-2.13 )
	>=${CATEGORY}/binutils-2.20"
...

сброс знака по (a & 0x7fffffff)
портабельный ассемблер

ну-ну

Че ну-ну, на системах, использующих допкод, где знак - MSB (почти все), это работает

Проблема в том что у GCC под ARM по непонятным для меня причинам сhar - без знаковый (0-255). Соотвецтвенно в цикле к цулому r всегда плюсуется положительное число. Компилятор сщитает что результатом работы цикла не может быть отрицательное значение в r (кроме как через переполнение которое UB). А следовательно последняя команда (r & 0x7fffffff) - лишняя так как никогда (кроме UB на которое пофиг) не меняет результат.

Вот он ее и выкинул, я - бы для портабельности кода сделал так:

int foo(const char *_s)
{
        unsigned int r = 0;
        unsigned char *s = (unsigned char*)(_s);
        while(*s) {
                r += ((r * 20891 + *s *200) | *s ^ 4 | *s ^ 3 ) ^ (r >> 1);
                s++;
        }
        return r & 0x7fffffff;
}

А я-то думаю, где скотинко, а вон оно как.

Например сброс знака по (a & 0x7fffffff) не работает

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

много всего вообще теперь не работает

довольно распространенное явление

У прадедов работало, у дедов работало, у меня всё работало, пока какой-то моржовый хер стандарт не почитал и не сломал всё.

не признаёт себя говнокодером

Оч странно это всё.

Какой сейчас более-менее адекватный gcc, 5.4?

Только 2.95

-fsigned-char / -funsigned-char результат меняет?

сброс знака

#include <stdlib.h>

int main(void)
{
   int a = -42;
   a = abs(a);
   return a;
}

gcc test.c
./a.out
echo $?
42

что пишут в официальной документации по поводу сброса знака?

вы абсолютно правы, коллега:

http://pubs.opengroup.org/onlinepubs/9699919799/functions/abs.html