Hello,
I come to you because I have an issue regarding gcc optimization in the 4.x
branch which really puzzles me.
I have a rather big program here which compiles perfectly on a whole bunch
of architectures (x86, amd64, ppc, sparc, ...) with older versions (3.3,
3.4) with -O3 -fno-strict-aliasing. It even works with 2.9-aix51-020209 on
AIX ;) It also works with 4.0 and 4.1 with -O0 (tested only on x86).
But it fails as soon as I use -O1 on v4.x. It even fails with
-O1 -fno-defer-pop -fno-guess-branch-probability -fno-cprop-registers
-fno-loop-optimize -fno-if-conversion -fno-if-conversion2
-fno-merge-constants -fno-tree-ccp -fno-tree-dce -fno-tree-dominator-opts
-fno-tree-dse -fno-tree-ter -fno-tree-lrs -fno-tree-sra
-fno-tree-copyrename -no-ftree-fre -fno-tree-ch -fno-delayed-branch
According to the documentation, this should be very close to -O0 since I
disable all the flags enabled by -O1. The difference should come from what
the documentation implies when stating: "Not all optimizations are
controlled directly by a flag. Only optimizations that have a flag are
listed". I guess that my problem comes from one of the not listed
optimizations.
The symptoms are a segfault near the end of the program with the following
valgrind backtrace:
==13387== Jump to the invalid address stated on the next line
==13387== at 0x34938BFF: ???
==13387== by 0x406602F: gras_process_exit (rl_process.c:23)
==13387== by 0x40450EE: gras_exit (gras.c:74)
==13387== by 0x804E216: main (datadesc_usage.c:662)
==13387== Address 0x34938BFF is not stack'd, malloc'd or (recently) free'd
==13387==
==13387== Process terminating with default action of signal 11 (SIGSEGV)
==13387== Access not within mapped region at address 0x34938BFF
==13387== at 0x34938BFF: ???
==13387== by 0x406602F: gras_process_exit (rl_process.c:23)
==13387== by 0x40450EE: gras_exit (gras.c:74)
==13387== by 0x804E216: main (datadesc_usage.c:662)
==13387==
==13387== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 21 from 2)
Here is the code of gras_process_exit():
void gras_process_exit() {
gras_procdata_exit();
free(_gras_procdata);
}
Line 23 of this file is the call to gras_procdata_exit(). As you can see,
there is no reason for this call to get unresolved by valgrind. Why "???" ?
And moreover, why 0x34938BFF? It seems a bit strange to me (too far from the
other addresses).
If someone wants to play with the code, it's available from our CVS here:
cvs -d :pserver:anonymous@xxxxxxxxxxxxxxxxxxx:/cvsroot/simgrid co simgrid
but 20000 lines are ways too much for a proper bug repport, I guess.
I write to this mailing list because I have no idea of where to look at. I
just wanted to check if someone already experienced something like that
before.
If someone can help me, that would be just wonderful. If not, I'm doomed to
3.x versions...
Thanks in advance,
Mt.
PS: please CC me as I'm not on the list yet.
--
Oh, I am a C programmer and I'm okay.
I muck with indices and structs all day.
And when it works, I shout hoo-ray.
Oh, I am a C programmer and I'm okay.
Attachment:
signature.asc
Description: Digital signature
