Gcc - can we control compilation options?

[hugo]

Trying to solve DISUBSTR, I am getting 'wrong answer'. After some helpful clues I grabbed gcc-4.0.0 (I have gcc-4.1.2 installed as my default compiler), and have now determined that my code succeeds with gcc-4.0.0 with -O0, but fails with -O1.

Given that I seem to be hitting an optimisation bug in gcc, is there any way to specify that my code should be compiled without optimisation? Or do I have to find what the optimisation bug is and develop a specific workaround for it?

This is already rather frustrating: I've spent a lot of hours to get to this point, and I feel this is rather a distraction from the intention of the SPOJ site as a whole and of the DISUBSTR problem in particular - particularly since the same optimisation bug doesn't exist in the (slightly) more recent version of gcc that I have installed by default.

Hugo van der Sanden

[Adrian_Kosowski]

Trying to solve DISUBSTR, I am getting 'wrong answer'. After some helpful clues I grabbed gcc-4.0.0 (I have gcc-4.1.2 installed as my default compiler), and have now determined that my code succeeds with gcc-4.0.0 with -O0, but fails with -O1.

It is also possible that your code contains a nasty bug which only becomes aparent sometimes, with optimisation enabled. Such bugs include uninitialised local variables and out-of-bounds pointers.

PS. Indeed, your solution works fine both with and without optimisation on gcc 4.1.2. So, if you are positive this is no bug on your part, you can probably wait for the next compiler upgrade and rejudge (in under 2 months) .

[hugo]

It is also possible that your code contains a nasty bug which only becomes aparent sometimes, with optimisation enabled. Such bugs include uninitialised local variables and out-of-bounds pointers.

Indeed, and I do plan to track down what the problem is; expect to hear irritated mutterings while I do though.

[...]you can probably wait for the next compiler upgrade and rejudge

Heh, thanks for that. Would still be cool to have an option to disable the optimisation though - bugs in gcc optimisation are not exactly unheard of.

Hugo

[hugo]

It is also possible that your code contains a nasty bug which only becomes aparent sometimes, with optimisation enabled. Such bugs include uninitialised local variables and out-of-bounds pointers.

Indeed, and I do plan to track down what the problem is; expect to hear irritated mutterings while I do though.

Mutter mutter ... after splitting my source to two files to control differential optimisation, I narrowed it down to the hash_remove() function. 7 steps of progressive simplification later I found that I could solve the problem by ... removing "hash[hi] = -1" to a separate function. I can't actually see anything wrong in the disassembly of the simplified hash_remove(), but I suspect either it has got its registers in a twist (and I'm not seeing it), or it is tripping over the pipelines. But I think I've run out of energy to pursue it for now.

Damn, I miss coding ARM assembler now.

Hugo

[Adrian_Kosowski]

But I think I've run out of energy to pursue it for now.

Assuming the bug has been fixed in the latest gcc, tracing the exact problem wouldn't be all that useful anyway.

I'm still surprised that the problem already comes up with -O1, which should be "safe" for most purposes by design.