gcc compiler problem in Slack 13
root
not present in the 4.2.4 version of Slack 12.2
I found the problem when I recompiled a data
analysis program that I wrote and have used
for over 15 years. Overall the package is
about 56K lines of code, and I found the
problem in a chunk of about 1K lines. If
I turn off optimization (O3) the problem goes
away. I can't see any way that I can reproduce
the problem in a small enough chunk of code
for the compiler development group.
It is easy enough for me to go back to 4.2.4
but I would like to help the compiler people
find and fix the bug.
Any suggestions?
Grant
Stay with O2 optimisation?
1k lines source way too big, can't you narrow it down with some sort
of logging as runtime goes through that section?
Grant.
--
http://bugsplatter.id.au
Henrik Carlqvist
> On Sun, 15 Nov 2009 06:09:47 +0000 (UTC), root <NoE...@home.org> wrote:
>>I turn off optimization (O3) the problem goes away.
> Stay with O2 optimisation?
Yes, usually O2 is better than O3. As O2 optimizes more for size it can
even produce faster code than O3 which optimizes more for speed as smaller
size might mean less cache misses.
At http://www.gentoo.org/doc/en/gcc-optimization.xml there are som strong
words agains O3:
-8<-------------------------------------
-O3: This is the highest level of optimization possible, and also the
riskiest. It will take a longer time to compile your code with this
option, and in fact it should not be used system-wide with gcc 4.x. The
behavior of gcc has changed significantly since version 3.x. In 3.x, -O3
has been shown to lead to marginally faster execution times over -O2, but
this is no longer the case with gcc 4.x. Compiling all your packages with
-O3 will result in larger binaries that require more memory, and will
significantly increase the odds of compilation failure or unexpected
program behavior (including errors). The downsides outweigh the benefits;
remember the principle of diminishing returns. Using -O3 is not
recommended for gcc 4.x.
-8<-------------------------------------
If it is really true that -O3 in known to "increase the odds of
compilation failure or unexpected program behavior (including errors)" it
would seem strange to me that the gcc developers allow gcc to still have
such a switch. The safe way would be to keep -O3 for backward compability
but give it the same effect as using the safe -O2.
However, if there still is some interest in finding the cause of the bug
in this case it might be possible to narrow it down further by trying
different optimizations that gets set with -O3. Those optimizations are
-finline-functions
-funswitch-loops
-fgcse-after-reload
regards Henrik
--
The address in the header is only to prevent spam. My real address is:
hc3(at)poolhem.se Examples of addresses which go to spammers:
root@localhost postmaster@localhost
root
>
> However, if there still is some interest in finding the cause of the bug
> in this case it might be possible to narrow it down further by trying
> different optimizations that gets set with -O3. Those optimizations are
>
> -finline-functions
> -funswitch-loops
> -fgcse-after-reload
>
> regards Henrik
Once again, thanks very much for your informative response.
I will change my Makefile to use O2, but in this case
the problem was *not* in the compiler, it was my problem.
The problem was an unitialized variable that, until now,
had not caused a problem. This particular section of
code has been unused since I rewrote and tested software
I wrote for a group at Caltech. The original was in Fortran.
I never used the section of code after rewriting it in C.
While the code passed three different test programs, it
was still wrong, which only became evident when I revisited
the code on Saturday.
allend
needed to use -fpack-struct option to the compiler to solve.
Ah, the joys of reading old data files that use a packed byte format!
root
The compiler difference is proving profound for me. Stuff keeps
popping up in which code that has run for years now fails. As an
example, routine A calls an intermediate routine B which forwards
the calling arguments to B onto routine C. In A and C the arguments
are ints, but in B I had declared them float. Doesn't work. I have
to change the declaration in B to correspond to how it was called
from A. It is as if the compiler did a type conversion when going
from A to B, but, since C was not in this package it could not
undo the conversion.
I know this sounds complicated, but I thank the compiler for
finding this stuff. The option -Wall doesn't show all the
stuff, and shows some stuff that isn't wrong.
Henrik Carlqvist
> The option -Wall doesn't show all the stuff, and shows some stuff that
> isn't wrong.
If you are writing ansi C code the option -pedantic might show many
useful warnings.
D Herring
> The problem was an unitialized variable that, until now,
> had not caused a problem.
For uninitialized variables and related obscure bugs, valgrind is your
friend. It runs slowly, and expect to spend a few hours learning to
decipher its output, but stuff like "conditional depends on
uninitialized value" can save days of head scratching.
- Daniel