g++: осторожно, знаковое переполнение

8 лет назад, # ^ |

-35

Я бы назвал это багом — компилятор слишком много на себя берёт.

→ Ответить

dreamzor

8 лет назад, # ^ |

← Rev. 2 →

+15

Это не баг, это — неопределенное поведение, при котором компилятор вправе делать все_что_угодно.

→ Ответить

8 лет назад, # ^ |

-12

Должно быть хоть какое-то логичное ограничение, где это самое неопределённое поведение может вылезти. Получается, что из-за undefined behaviour где-то, где его результат ни на что не влияет (кроме вывода на экран в данном случае), undefined behaviour распространяется на другой участок кода, где всё как раз прекрасно defined. Так можно докатится до ситуации, где компилятор, заметив где-то потенциальное переполнение просто рубит всё программу и заменяет одним NOP'ом. Очень эффективная оптимизация — если что-то может не работать, зачем вообще это делать.

Хорошо, я согласен, что формально требования стандарта выполнены. Всё равно остаётся вопрос:

Если оптимизация настолько умна, то почему она режет код вместо того, чтобы выдать warning о потенциальном переполнении?

→ Ответить

riadwaw

8 лет назад, # ^ |

← Rev. 2 →

+13

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

→ Ответить

http://kristerw.blogspot.com/2016/02/how-undefined-signed-overflow-enables.html

8 лет назад, # ^ |

-15

AlexDmitriev,

Ещё один вопрос — я с трудом представляю ситуацию, когда эта оптимизация (насколько я понял — aggressive-loop-optimization) может быть полезной. Точнее не представляю. Это либо кривой код, который лучше бы исправить, либо просто ошибка. Нормальный код, которому может принести пользу такая оптимизация... Не знаю, разве что параметризированный шаблон приходит в голову, где конкретный параметр шаблона позволяет "схлопнуть" цикл, которй может понадобится в общем случае. Мне кажется эта оптимизация evil :)

→ Ответить

slycelote

8 лет назад, # ^ |

→ Ответить

8 лет назад, # ^ |

И комментарии внизу очень похожи на мои, весело. Так что я просто прочитал там — остался при своём мнении (it's evil), но лучше понял обе точки зрения — спасибо!

→ Ответить

8 лет назад, # ^ |

+20

Хорошо, когда редактор умный

→ Ответить

8 лет назад, # ^ |

Или когда оптимизатор тупой — на MSVC 2013 никаких проблем :)

→ Ответить

dalex

8 лет назад, # ^ |

+43

Да на MSVC вообще не бывает проблем, я помню только одну, о которой постили на CF, а о багах g++ упоминали точно не менее пяти раз. А еще здесь минусуют за упоминание этого факта :)

→ Ответить

MikeMirzayanov

8 лет назад, # ^ |

А так?

#include <iostream>
#include <set>
int main()
{
    for (int i = 0; i < 300; i++)
    {
        std::set<int> s;
        s.insert(i * 12345678);
        std::cout << i << " " << std::endl;
    }
}

→ Ответить

8 лет назад, # ^ |

А так молчит

→ Ответить

8 лет назад, # ^ |

← Rev. 2 →

Это не редактор умный, а g++.

Если будете из консоли компилировать код с -Wall -Wextra, то в точности те же самые варнинги получите.

→ Ответить

8 лет назад, # ^ |

Я компилирую без -Wall -Wextra, и тем не менее получил уведомление о возможной ошибке, так что таки редактор.

→ Ответить

8 лет назад, # ^ |

← Rev. 2 →

+10

Прошу прощения, речь не в -Wall и -Wextra, просто я их использую всегда. Дейсвительно, и без них те же варнинги g++ даёт.

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

Очевидно, что это не g++.

→ Ответить

8 лет назад, # ^ |

Что я делаю не так? Мой компилятор молчит без дополнительных флагов, а редактор всё равно подсказывает

→ Ответить

8 лет назад, # ^ |

Возможно у вас просто несколько разных g++-ов стоит.

→ Ответить

8 лет назад, # ^ |

У меня один g++. Скорее у вашего g++ выставлен флаг -Wall, или ему подобные, поумолчанию — сделайте g++ -dumpspecs или посмотрите по переменным окружения

→ Ответить

8 лет назад, # ^ |

← Rev. 6 →

Нет. И там и там ничего нет.

→ Ответить

Djok216

8 лет назад, # |

← Rev. 2 →

+22

Last sentence is written in russian, on eng interface :(

→ Ответить

tenshi_kanade

8 лет назад, # |

This is so strange! I tested it on my machine, and it does indeed run infinitely.

It's interesting I believe. Why does that happen?

→ Ответить

8 лет назад, # ^ |

← Rev. 2 →

+117

There is russian explanation from yeputons, so I am just translating:

-Waggresive-loop-optimization option is turned on by -O2,

Optimizer infers that because i*12345678 should never overflow, i will never be higher then 173, which means that i < 300 is always true, so it replaces condition "i < 300" with true.

→ Ответить

gvaibhav21

8 лет назад, # ^ |

+52

strange, if you replace endl with '\n' , the code no longer runs infinitely

→ Ответить

8 лет назад, # ^ |

+10

My take on this is that std::endl flushes cache, so the output operation happens in the cycle, so output is produced within the cycle and is expected to conform to language rules, which means no overflow is expected and optimization works.

If do you "\n", cache is flushed after the cycle ends, so there is no external output within the cycle, which somehow turns off optimization.

Strange indeed. It probably takes a guy from g++ development team to tell exactly what happens.

→ Ответить

yeputons

8 лет назад, # |

+23

By the way, it looks like it's possible to disable that behavior in GCC with a special key: -fno-strict-overflow

→ Ответить

tyamgin

8 лет назад, # |

+24

Это баян, конечно.

Вот ещё интересный пример:

int arr[4];

bool in_array(int a) {
	for(int i = 0; i <= 4; i++)
		if (arr[i] == a)
			return true;
	return false;
}

Функция всегда возвращает true

http://ideone.com/z9npmc

→ Ответить

vlad8

8 лет назад, # ^ |

Объясните почему?)

→ Ответить

tyamgin

8 лет назад, # ^ |

+22

Компилятор имеет право считать что UB в коде нет.

Если i доходит до 4, то получим UB (выход за пределы массива). Значит i не дойдет до 4. Значит раньше мы вышли с return true.

Следовательно заменяет весь код на return true

→ Ответить

iskhakovt

8 лет назад, # ^ |

clang 3.9.0 не воспроизводится.

→ Ответить

https://habrahabr.ru/post/229963/

8 лет назад, # ^ |

← Rev. 2 →

+24

А ещё есть почти легендарный код, который своим выполнением "опровергает" великую теорему ферма.

int fermat (void)
{
  const int MAX = 1000;
  int a=1,b=1,c=1;
  while (1) {
    if (((a*a*a) == ((b*b*b)+(c*c*c)))) return 1;
    a++;
    if (a>MAX) {
      a=1;
      b++;
    }
    if (b>MAX) {
      b=1;
      c++;
    }      
    if (c>MAX) {
      c=1;
    }
  }
  return 0;
}

#include <stdio.h>

int main (void)
{
  if (fermat()) {
    printf ("Fermat's Last Theorem has been disproved.\n");
  } else {
    printf ("Fermat's Last Theorem has not been disproved.\n");
  }
  return 0;
}

→ Ответить

vlad8

8 лет назад, # ^ |

← Rev. 4 →

+27

И он неверен, по крайней мере в C11:

C11 clarifies the answer to this question, in the draft C11 standard section 6.8.5 Iteration statements added the following paragraph:

An iteration statement whose controlling expression is not a constant expression,156) that performs no input/output operations, does not access volatile objects, and performs no synchronization or atomic operations in its body, controlling expression, or (in the case of a for statement) its expression-3, may be assumed by the implementation to terminate.157)

and footnote 157 says:

This is intended to allow compiler transformations such as removal of empty loops even when termination cannot be proven.

whose controlling expression is not a constant expression !!!!!!!!

Верный код есть в статье из которой и сделали статью на Хабре, понятия не идею зачем автор изменил код.

const int MAX = 1000; int a=1,b=1,c=1; while ((c*c*c) != ((a*a*a)+(b*b*b))) { a++; if (a>MAX) { a=1; b++; } if (b>MAX) { b=1; c++; } if (c>MAX) { c=1; } }

Здесь не константа в условии.

На моем компьютере код с Хабра выполняется честно, потому я решил разобраться. Напишите если я что-то не так понял и у кого-то он работает

→ Ответить

8 лет назад, # ^ |

Да, вы правы.

И это касается не только с++11, но и других стандартов (например ansi, c11, c99, c++03, ...)

→ Ответить

riadwaw

8 лет назад, # ^ |

Вы говорили про c++11, а процитировали про c11

→ Ответить

tyamgin

8 лет назад, # ^ |

Что такое 1000?

→ Ответить