GCC 4.8 made me chose Clang

[lucasart]

I made a very stupid mistake today: updated my Ubuntu from 13.04 to 13.10. One of the reasons I did that, was to upgrade to GCC 4.8. So there I was, all excited to compile DiscoCheck with GCC 4.8... How stupid I was!

I compiled the exact same code with:
* GCC 4.7.3, with or without flto (link time optimization): All good, verified by total node count on a depth=12 run of 20 positions.
* GCC 4.8.1, with of without flto: both compiles are wrong. Neither have the correct node count, and both versions don't even have the same node counts (ie. they are both broken in different ways).
* not only the GCC 4.8 compiles are all broken, but they are slower than the ones of GCC 4.7.

So I have now a compiler that SILENTLY breaks my code. This is totally unacceptable. And there is no way to find out where the problem comes from, so I'm completely screwed as far as GCC is concerned. Perhaps a git bissect, but I really don't have the patience for that. The fact that GCC now makes broken and slower compiles, is enough to put me off it for the foreseeable future. Writing a chess program is a complicated enough task already, if we can't even rely on the compiler to produce correct code, we're doomed!

The good news however is Clang:
* Clang managed to produce a correct compile (correct node count).

But:
* clang does not accept GNU extensions (std=c++11 but not std=gnu++11). That means I need to throw away variable length arrays. They were so nice for triangular PV array on the stack, without them, I will now have to rely on an ugle global structure.
* clang does not accept flto (link time optimization). This was a great source of performance in GCC 4.7.3 when compiling my code, as I hate to have to inline everything: I prefer to rely on flto to do it for me.
* the Clang compile is 10% slower than GCC 4.7 !

Anyway, I guess I'll have to bite the bullet and only use Clang from now on, until an acceptable version of GCC resurfaces. I will miss VLA though

Has anyone experienced similar issues with GCC 4.8 ?

[Michel]

Perhaps a git bissect, but I really don't have the patience for that.

Why not? git bisect is very fast.

It may well be that this whole thing hides a bug in your code. Compiler errors are extremely rare.

[trojanfoe]

* clang does not accept GNU extensions (std=c++11 but not std=gnu++11). That means I need to throw away variable length arrays. They were so nice for triangular PV array on the stack, without them, I will now have to rely on an ugle global structure.

That isn't true; I've just compiled this, without complaint, using Apple clang 5.0 (I used -std=c++11):

Code: Select all

#include <cstdio>
#include <cstring>

FILE * concat_fopen (char *s1, char *s2, char *mode)
{
   char str[strlen (s1) + strlen (s2) + 1];
   strcpy (str, s1);
   strcat (str, s2);
   return fopen (str, mode);
}

* clang does not accept flto (link time optimization). This was a great source of performance in GCC 4.7.3 when compiling my code, as I hate to have to inline everything: I prefer to rely on flto to do it for me.

Apple clang 5.0 does support LTO and as that is based on LLVM 3.3 SVN, I'm surprised it's not in the non-Apple version.

* the Clang compile is 10% slower than GCC 4.7 !

No idea about that; I've never compared.

I would strongly suspect that your code is non-portable and slightly broken if it's suddenly started breaking with gcc 4.8. You mention the use of variable length array, which is a feature I would never consider using if I wanted to create portable code (std::vector is the portable variable-length array).

You might be better off getting it to work with gcc 4.8 and thus having a better code base, rather than assuming these faults are with the compiler rather than your code.

[Codesquid]

GCC 4.8.1, with of without flto: both compiles are wrong. Neither have the correct node count, and both versions don't even have the same node counts (ie. they are both broken in different ways).

So I have now a compiler that SILENTLY breaks my code.

What makes you sure it's a problem with GCC and not a very subtle bug in your code, e.g. a reliance on undefined or implementation specific behavior?

And there is no way to find out where the problem comes from, so I'm completely screwed as far as GCC is concerned.

There is: Dump the search trees, compare the output with the two compiles. Find the difference and iteratively narrow it down. Eventually you'll find a line of code that behaves differently.

[geko]

hi Lucas,
Valgrind detect "Conditional jump or move depends on uninitialised value(s)"
and exit with

Code: Select all

./src/types.h:107: int opp_color(int): Assertion `color_ok(color)' failed.

Try to fix this error

best
Giuseppe

[lucasart]

Perhaps a git bissect, but I really don't have the patience for that.

Why not? git bisect is very fast.

It may well be that this whole thing hides a bug in your code. Compiler errors are extremely rare.

OK, I've done the git bisect, and the offending commit is as follows:
https://github.com/lucasart/chess/commi ... f37b895be5

From this commit onwards, the node counts start to diverge: GCC 4.7, GCC 4.6, and Clang produce correct compiles, but not GCC 4.8.

I've been staring at the code for this commit for a while, and I really don't see anything wrong with it. I'll try to reimplement the same thing in a different way to see what happens.

[mcostalba]

I've been staring at the code for this commit for a while, and I really don't see anything wrong with it.

Remove it piece by piece until you find the offending statement.

[Codesquid]

OK, I've done the git bisect, and the offending commit is as follows:
https://github.com/lucasart/chess/commi ... f37b895be5

From this commit onwards, the node counts start to diverge: GCC 4.7, GCC 4.6, and Clang produce correct compiles, but not GCC 4.8.

I've been staring at the code for this commit for a while, and I really don't see anything wrong with it. I'll try to reimplement the same thing in a different way to see what happens.

Maybe this change merely triggers a problem elsewhere?

[mar]

Hmm, I just tried to compile my engine with gcc 4.8 and it's not broken. It even seems faster...

[lucasart]

I've been staring at the code for this commit for a while, and I really don't see anything wrong with it.

Remove it piece by piece until you find the offending statement.

Ah yes, why didn't I think of that? Thanks for the tip.

So basically, I make a copy of my source tree before the commit, and start rewriting this commit, bit by bit, until it breaks (GCC 4.8 and Clang produce different bench signature).