Баги есть везде: http://blogs.msdn.com/b/vcblog/archive/2012/08/10/10338661.aspx

См. особенно вторую таблицу.

It works correctly for me, both with and without -O2. My g++ is old, though.

$ g++ --version
g++ (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I remember there is a bug with ST::reverse() with -O2. I rarely use it.

why the result is right when x starts with -1 ? ...

1. Если включить -Wstrict-overflow, то gcc предупреждает, что упростил выражение до константы. Он хотя бы честный :)
2. У g++ есть опция -E, которая показывает что сделал препроцессор. А нет какой-нибудь такой же опции, чтобы показать, что сделал оптимизатор? Какое-то промежуточное состояние до того, как в asm это все перобразовали хотя бы. В асемблере тоже можно порыться, но понятно, что это сложнее.

А какое минимальное изменение нужно внести в сэмпл, чтобы он начал корректно работать после оптизации на проблемных g++?

А почему бы не добавить в компиляторы clang? Там подобные баги встречаются гораздо реже.

Why the compile command is not "g++ -o a a.cpp -O2" ?

«Можно взять большое количество ACCEPTED решений Codeforces (те, что на g++). Перетестировать их под valgrind и без оптимизаций (чтобы убедиться, что всё с ними точно ОК). И делать такое regression тестирование новых компиляторов. Вышла новая версия g++ — перетестировал под ней пару десятков тысяч решений. Что-то не сошлось — посмотрел и зафайлил баг.»

Я предполагаю, что 99% решений, которые не сдадутся но новой версии — случаи проезда по памяти, неверных указателей, неинициализированных переменных, нечищенной памяти, Undefined Behaviour, Compiler Specified Behaviour, хотя valgring может отсеет много.

Не могу быть уверен без эксперимента, но мне кажется, что это оооочень вероятная ситуация.

I am an active stackoverflow user and every now and then I see some code that demonstrates strange behavior in g++. I remember very clearly a case when compiling with optimizations caused abs(-1) to eval to -1. You can imagine what this could cause to some programs!

I regret so much I could not find that thread to link here.

I compile the code with -O2 -S and view the assembly code. I find that the code only simply checks whether n is equal to 3. If yes, the code outputs 2 1 0, else always outputs -1. The assembly code is here, https://gist.github.com/klogk/9994674. If changing the conditional statement into 3*x+3, the code will work fine. I guess that the reason is the wrong optimization for evaluation such bool statements.

This situation often happens in POJ. G++ got WA,but C++ got ac finally know the reason.

I used gdb to debug the program, and the program will always break the for loop if the first n == x + (x + 1) + (x + 2) is false. It seems that if I change the expression into n <= x + (x + 1) + (x + 2), it works fine. The optimizer must have confirmed once n != x + (x + 1) + (x + 2), it would never do. It is not because n will always be greater than the rhs. Instead the it might be resulted from number theory, and the derivation makes some mistakes.

Bug also found in shortened version, gcc 4.7.1

#include <stdio.h>
int main() {
    int n, x;
    scanf("%d", &n);
    for (x = 0; x <= n; x++)
        if (n == x + x + x + 3)
            return 0;
    puts("-1");
    return 0;
}

If changed into x * 3 + 3, it would be correct.

My gcc version is 4.8.2.

I can get the correct answer when I use g++ -O2 -fno-tree-ch, so I think -ftree-ch option enabled by -O may lead to some wrong optimization.

(maybe) Another bug found in the last year's ICPC Asia Nanjing Regional Contest. I coded a snippet like this, in order to test whether "-O2" in our compiler command line works correctly.

#include <stdio.h>

int main(void)
{
	int x = 0;
	int sum = 0;
	unsigned int i = 0;
	for(i = 0U;i < (1U<<31U);i++)
	{
		x++;
		sum += x;
	}
	printf("%d\n",sum);
	return 0;
}

To my surprise, this code runs for more than 10 seconds without anything outputed. Objdump shows the whole snippet was optimized as a "while(true);". But without -O2 this code works in about 5 seconds.

We tried all g++ versions we have at that time, 3.4.2(carried along with Dev-Cpp 4.9.9.2), 4.4.7, 4.6.3, 4.7.2, 4.8.1 and even 4.9pre. Among them only 3.4.2 works. But obviously we can't use this so-old one on judge workstations.

This fact forced us to double check many suspicious TLE solution during contest.

Я репортил пару багов оптимизатора VS 2005, но не следил чем дело закончивалось, это могли быть и не баги. Там есть куча тонкостей. Например нельзя устраивать переполнение в цикле for. т.е. for (unsigned i = 1; i; ++i) по идее undefined behavior

The idea to use Codeforces submissions as regression tests is great and would help the open source community a lot! However it's always possible that programs exhibit undefined behaviour without valgrind noticing, so it's probably still a lot of work to manually extract the failing part of the program and verify whether there is indeed a regression or the code is just wrong

Hey, I am getting a similar kind of problem. My code in g++ in my computer is giving a right answer, however the output from the file compiled on codeforces' server is giving a different, hence wrong answer.

http://codeforces.me/contest/496/submission/9178052

care to have a look? Is there any solution to it?

Thanks.

This code is causing bug even without -O2 (tested on GCC 4.8.1):

#include <stdio.h>

// Returns 1 if a*b causes overflow, for a>=0 and b>=0; 0 otherwise
bool mul_overflow(long long a, long long b) {
	//printf("a=%lld\n", a);
	if (a < 0) return true;
	if (b <= 1) return false;
	return (a*b < 0) || mul_overflow(a+a, b/2);
}

int main() {
	printf("%d", mul_overflow(1LL<<33, 1LL<<30));
}

1. Run it without -O2. The output is correct: 1
2. Uncomment the printf and run it without -O2. The output is incorrect: despite it prints 1, it should print O(log b) values of a, and it prints just 1: "a=8589934592".
3. Run it with -O2. The output is incorrect: 0
4. Uncomment the print and run it with -O2. The output is correct: it prints 1, and all values of a until it gets to the answer.

Sorry to post here after 3 months, but I found a very annoying bug somewhere in g++.

My AC code for problem 474E didn't work at home. You can find it easily, it's my last submission.

In fact:

• it's AC here on Codeforces using g++
• it's also AC here using Visual C++
• it works at home with g++ 4.7.1 without options
• it doesn't work at home with g++ 4.7.1 with options recommended by andreyv (http://codeforces.me/blog/entry/15547), namely -fdump-tree-optimized -fno-tree-ch -Wall -Wextra -pedantic -std=c++11 -O2 -Wshadow -Wformat=2 -Wfloat-equal -Wconversion -Wlogical-op -Wcast-qual -Wcast-align -fwhole-program -D_GLIBCXX_DEBUG -D_GLIBCXX_DEBUG_PEDANTIC -lmcheck -D_FORTIFY_SOURCE=2 -fstack-protector

It does random crap at a time, some indexes go to some values like 2123421 rather than 2 without any reason...

I think that there is a problem with an optimization who guesses the value of a variable wrongly. It seemed to be deterministic (the crap variables were always the same) but totally unlogical.

I know that some of you here are g++ experts. Personally, I simply use these options because they're nice for debugging, but I don't know if they're unstable. In fact, I never really try to find out :D

I think the same problem can happen to some of you, because my code is a pretty classical segment tree code.

If you find what the fuck happened, please let me know. Thanks ! :-)