On Dec 15, 2009, at 12:28 AM, Paolo Bonzini wrote: > On 12/14/2009 09:31 PM, John Regehr wrote: >> Ok, thanks for the feedback Andi. Incidentally, the LLVM folks seem to >> agree with both of your suggestions. I'll re-run everything w/o frame >> pointers and ignoring testcases where some compiler warns about use of >> uninitialized local. I hate the way these warnings are not totally >> reliable, but realistically if GCC catches most cases (which it almost >> certainly will) the ones that slip past won't be too much of a problem. > > I also wonder if you have something like LTO enabled.
No, he doesn't enable LLVM LTO. Even if it did, LTO wouldn't touch the 'CC1000SendReceiveP*' definitions because they are not static (unless he explicitly built with an export map). I haven't analyzed what is going on in this example though. The code is probably using some undefined behavior and getting zapped. -Chris > This function produces completely bogus code in LLVM, presumably because > some kind of LTO proves that CC1000SendReceiveP is never written. Of course, > this assumption would be wrong at runtime in a real program. > > http://embed.cs.utah.edu/embarrassing/src_harvested_dec_09/015306.c > > Of course the answer is not to disable LTO, but rather to add an > "initializer" function that does > > volatile void *p; > memcpy (CC1000SendReceiveP__f, p, sizeof (CC1000SendReceiveP__f)); > memcpy (CC1000SendReceiveP__count, p, sizeof (CC1000SendReceiveP__count)); > memcpy (CC1000SendReceiveP__rxBuf, p, sizeof (CC1000SendReceiveP__rxBuf)); > > ... and to make all variables non-static (otherwise the initializer would > have to be in the same file, but that would perturb your results). > > I also agree with others that the frame pointer default is special enough to > warrant adding a special -f option to compilers that generate it, if some > other compilers do not generate it. > > Paolo >
