идея была такая чтоб угол обрезать в диапазон -пи...пи и свернуть его в «кольцо». поэтому инт и операция и чтоб резать кратные 2пи компоненты.

я в ахерении. код переписал на uint в итоге. печально что люди не понимают что уб это не значит рандом. это значит что мы сгенерим идейно правильный код но ЕСЛИ у вас переполнится то никаких гарантий. а не генерим что хотим

Можешь кинуть что-нибудь на почитать о такой оптимизации? Я немного не в курсе, а с сишкой работаю: хотелось бы знать где не наткнуться.

я не понимаю что конкретно триггерит гцц. вырежу код - скажу точнее. щас пока никак я дурак чайник кофе выпил и мне херово

Ок, подпишусь на тред, чтоб не пропустить)

Кстати, в оригинале

int x = 8191 & y;

int x = 8192 & y;

я в ахерении. код переписал на uint в итоге.

А не ты ли в другой теме заявлял

надо в стандарт написать что вообще всё ub. чтоб дураки не писали на наших языках

А теперь поджал хвост и убежал на uint у которого нет UB.

говно есть полезно и здорово

http://neurosciencenews.com/fecal-transplants-cognition-6474/
да

GC в каждый дом. Исключения в каждый деструктор.

А потом майнкрафтодети вопят, что кубики (реально кубики, почти никакого сложного 3D) тормозят.

Я не понял, кто из них гигантская клизма, а кто сандвич с дерьмом?

Используй Rust, нет UB (на самом деле есть, но не в таком количестве и не в safe Rust), есть все гарантии GC, скорость очень близкая к C

А какая разница?

Разница принципиальная. Примерно как между пепси и кока-колой.

f(x(), y()) - это UB или нет?

UB

Что? Где? Порядкок вычисления x, y не определен, да, но при чем здесь UB?

Если какое-то поведение не определено, то это неопреденное поведение

Есть разница между «undefined order» и «undefined behavior». Это не одно и тоже

Считаешь ли ты багом в компиляторе что эта программа печатает «value is: 0» ?

Тред не дочитал, но баг здесь заключается только в том, что разработчик не читал документацию на компилятор.

В частности,

-O2 turns on all optimization flags specified by -O. It also turns on the following optimization flags: <...> -fstrict-overflow

-fstrict-overflow
Allow the compiler to assume strict signed overflow rules, depending on the language being compiled. For C (and C++) this means that overflow when doing arithmetic with signed numbers is undefined, which means that the compiler may assume that it does not happen. This permits various optimizations. For example, the compiler assumes that an expression like «i + 10 > i» is always true for signed «i». This assumption is only valid if signed overflow is undefined, as the expression is false if «i + 10» overflows when using twos complement arithmetic. When this option is in effect any attempt to determine whether an operation on signed numbers overflows must be written carefully to not actually involve overflow.

С такой позиции a * 8 == 0 только если a == 0, что оптимизатор и проверяет.

Да, все верно. Я хотел добиться такого анализа от автора треда, но не судьба. Кстати что интересно, на gcc можно обойти эту проблему переписав код так:

void foo(int a) {
    int x = a * 8;
    if (x == 0) {
        return;
    }
    bar(x);
}

Чтобы ни было в y, UB или не UB

UB может быть не в y, а в программе, и в таком случае никаких гарантий на поведение программы не даётся, на то оно и undefined.

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

Чем докажешь что ты не античеловек?

я предлагаю генерить код, который отражает написанное в программе. это что, невыполнимое требование?

Осиль сборку без оптимизаций.

Некорректная программа НЕ ДОЛЖНА собираться. И тут не работает отмазка «компилятор не владеет результатом исполнения программы» - компилятор руководствуется при таких оптимизациях ИМЕННО что РЕЗУЛЬТАТОМ. При этом этот результат(компиляции) НИКАК и НИЧЕМ не определён.
Т.к. компилятор ЗНАЕТ, что он генерит ГОВНО и НИКАК на это не реагирует.

Есть 100500 способов прострелить себе ногу. Напиши проверку для всех этих 100500 способов. Давай, обанкроть pvs студию.

ну хотя бы потому что XOR в обратную сторону не работает, иначе бы криптографии не было.

Что?

Опции уровня `-fstrict-overflow` дают интересное решение: выделить код для опасных операций с int в отдельную библиотеку, и собирать её строго с флагом `-fstrict-overflow`.

-fstrict-overflow включена всегда для любого кода, как тебе библиотека поможет?

Да он читал документацию, но считает что комплиятор (и документация его) - говно

Будто что-то плохое.

А теперь поджал хвост и убежал на uint у которого нет UB.

Так автор по прежнему мнит себя д'Артаньяном, просто «дураки добрались и до GCC».

Кстати, забавная фиксация на расте, раньше только джава фигурировала. Это при том, что языки очень разные, даже с точки зрения «безопасности».

есть все гарантии GC

Ну преувеличивать не надо - не все. Нормальный GC циклические ссылки собирать умеет.

Доброго всем дня наверно

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

Вот я тут вернулся таки и что мы видим. Какие-то GC, кококо. Вы вообще о чем?

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

ПОЧЕМУ ВЫ УРОДЫ ДУМАЕТЕ ЧТО РАЗ ПЕРЕПОЛНЕНИЕ МОЖЕТ БЫТЬ, ТО НАДО ГЕНЕРИТЬ КОД КАК ЕСЛИ БЫ ПЕРЕПОЛНЕНИЕ ВСЕГДА БУДЕТ?

Ну что такого сложного в утверждении, что «переполнение может быть» не равно «переполнение всегда будет»? что непонятного в том, что код, который UB ПРИ ПЕРЕПОЛНЕНИИ не должен быть UB без переполнения потому что ПЕРЕПОЛНЕНИЯ НЕТ?

Алё, казлины. Если UB при переполнении, то если переполнения нет, UB нет. Что непонятного в этом одном предложении? Вы что, ненормальные что ли?

В стандарте написано, что if(переполнение & int) then UB. это не значит, что if(int) then UB. это не значит, что можно генерить шизокод только потому что у вас int написано.

Тут или понятно или не о чем говорить дальше.

* * *

Ну и да, по мелочи. Ответим тем, кому мы не могли ответить ранее.

компилятор не должен оптимизировать вызов функции atoi. Тут дело даже не в том, что atoi лежит в либлиотеке, и может быть переопределена через LD_PRELOAD. но просто потому что это функция. а если ты её оказывается умеешь вычислять то это жаба в чистом виде, где язык это не только сам язык, но и вот эти рюшечки которые компилятор тоже понимает оказывается. а почему только atoi? а snprintf почему нет? а QWidget::show() можно мне также оптимизировать? почему нет-то? э, алё. только не надо про стандарт. это вам захтелось инлайнить эту никому не нужную функцию. она же никому не нужна. простите, сдающие лабы студенты, я не вас имел ввиду. ну, просто оно не нужно. зачем?

Попытки мне вот этим явно ошибочным поведением компилятора что-то доказать в плане «вот наше UB -это правильно» да пошел ты в жопу, товарищ. То что компилятор генерит говнокод не повод для оправдания этого говнокода. Это только в вашей жабе извращались чтоб повторить ошибку fpu 8086 при вычислении синуса чтоб была совместимость. У нас не так.

А вас мы выгоним из С и С++. Идите в ад уроды.

ничего что то, что сотворили разрабы gcc с компилятором, делает его несовместимым с программированием? какой нахер strict oveflow. ну расскажи мне, что такого происходит с int при overflow, что результат становится принципиально неопределен?

в кубиках тормозит построение mesha.

компилятор не должен оптимизировать вызов функции atoi.

Кококо, покажи мне хоть один компилятор который инлайнит (или вычисляет) вызов atoi (strtol). Мне иногда кажется что ты не с этой планеты.

в том самом примере, с какого бодуна проверка (x*8==0) стала всегда true?

ну я слушаю уже. с какого бодуна не-const х * 8 был выкинут. расскажи мне про эти оптимизации уже. может просто у нас слово оптимизации разное означает?

Достанем твой пример из небытия:

#include <stdio.h>
#include <stdlib.h>

void bar(int x) {
    printf("value is: %d\n", x);
}

void foo(int a) {
    if (a * 8 == 0) {
        return;
    }
    bar(a * 8);
}

int main() {
    int z = atoi("536870912");
    foo(z);
}

если не const,

foo(a=!const) {
    if (!const-a * 8 всегда ли == 0) {
        return;
    }
}

Я то могу рассказать, странно что ты этого не знаешь:

1) умножение никогда не может переполнится

2) следовательно x * 8 может быть нулем только если x == 0

3) заменяем if (x * 8 == 0) на if (x == 0)

4) получаем граблями когда приходит число которое переполняет умножение

объясни мне пожалуйста, что ты пропустил между (3) и (4). там явно должны быть какие-то логические рассуждения как мы от (3) перешли к (4).

ничего что то, что сотворили разрабы gcc с компилятором, делает его несовместимым с программированием?

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

где ты в стандарте прочитал, что можно при слове int делать некорректный код?

Если UB при переполнении, то если переполнения нет, UB нет.

Компилятор исходит из предположения, что UB не будет. В тех случаях, когда переполнения на самом деле нет, сгенерированный компилятором код должен отработать нормально. Однако никто не обещает, что сгенерированный код при этом будет близок к исходному коду на Си.

де ты в стандарте прочитал, что можно при слове int делать некорректный код?

Однако никто не обещает, что сгенерированный код при этом будет близок к исходному коду на Си.

деревня дураков.жпг

я с тобой больше спорить не буду. ты unfixable. иди глючь дальше со своими друзьями.

где ты в стандарте прочитал, что можно при слове int делать некорректный код?

Сгенерированный компилятором код будет давать корректные результаты (так называемые сайд-эффекты) в тех случаях, когда UB не наступает. При этом сгенерированный компилятором код может быть весьма далек от того, что было написано в исходниках. Поэтому в случаях когда UB таки наступает, результаты работы этого кода (и программы в целом) могут быть абсолютно невменяемыми.

иди глючь дальше со своими друзьями.

1. Если ты об авторах gcc, clang и стандартов, то это не мои друзья.

2. С твоим нынешним подходом, глючить на современных компиляторах де-факто будет лично *твой* код. Куда бы ты тут на форуме меня ни посылал...

>могут быть абсолютно невменяемыми.

какое-то печальное зрелище.

ну вот правда. с самого начала треда я говорю что нельзя генерить говнокод. я это писал раз 20. и что мы видим в итоге?

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

вы мне уроды весь тред доказывали что можно генерить говнокод потому что может быть UB а значит похеру танцуем. а теперь чо? что-то пошло не так. зомби сбились в кучу и тупят. но всё равно и кучи слышно рычание: а мы можем «оптимизировать» как хотим, тут же в стандарте написано UB.

тут просто не о чем говорить. как с педерастами. ахтунг это не извращение, ахтунг это норма, пустите нас в школы учить детей, гомофобы нападают на нашу новую школьную программу...

в жабу себе оптимизируйте.

объясни мне пожалуйста, что ты пропустил между (3) и (4).

0) Программист Петя хотел чтобы в функцию bar не попал ноль

0.1) Программист Петя написал код

...

3) Компилятор заменил функцию

void foo(int a) {
    if (a * 8 == 0) {
        return;
    }
    bar(a * 8);
}

void foo(int a) {
    if (a == 0) {
        return;
    }
    bar(a * 8);
}

3.1) Новый код будет работать правильно для всех чисел кроме 536870912, потому что это число вызывает UB

3.2) Петя не проверил входные данные и допустил такое что число 536870912 пришло по сети (или из файла, или из atoi) и попало на вход функции foo.

3.3) Случился UB и программа сработала не так как хотел Петя

4) Петя бежит постить на лор что разрабы gcc дауны и такого не может быть чтобы 0 пришел в bar, потому что «он же проверил»

Эй алё. Куда пропал, жабоглот?

Мы внимательно слушаем вообще-то, на каком основании удалилась проверка на ноль. Ты нам расскажешь наконец, на каком основании эта проверка удалилась? удалиться она может только если её результат = const, т.е. все входные аргументы выражения=const. теперь расскажи нам как константой в твоём коде стало «a».

на каком основании удалилась проверка на ноль.

Проверка на ноль осталась, умножение удалилось. Ты что читать не умеешь?

вы мне уроды весь тред доказывали

Я так понял, что по существу вопроса тебе сказать больше нечего, и поэтому ты сорвался в собачий визг и лай — какие тут все уроды и пидоры, а ты весь бедняжка и на эмоциях негодуешь.

Okay.

На будущее совет - постарайся все-таки держать себя в руках, не по-мужски это.

Ты что читать не умеешь?

Похоже, у него истерика, на глазах пелена =)

Тред — жесть, конечно. ТС — неадекватен. Всем подошедшим к теме с конструктивном спасибо, было интересно и познавательно.