https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66230
--- Comment #2 from gpnuma at centaurean dot com ---
I understand you're short of time but this problem is very difficult to
reproduce !!
I did try to compile and link with -fsanitize=undefined this morning, now
here's the interesting part :
* no warning was generated by ubsan
* everything works fine
As soon as I remove -fsanitize=undefined, I get the segfault again, so I
suspect the problem happens during the optimization stages.
The fact that if I add a useless line of code like printf("...") at the start
of the called function cancelling the problem makes me wonder if it could be
that the function pointer is not properly "captured" by gcc or that it
"changes" after optimizations.
Here is what I'm doing to be more accurate :
1) I have a set of functions at the top of a file (functionA, functionB, ...)
2) At the bottom of that file I have another function which stores the function
pointers of these functions using &functionA, &functionB etc... in an array.
3) Later on, I access the functions using an index to that array, and with gcc
4.8 / -O3 *only*, this fails and segfaults.
So my thinking is maybe the function pointers are stored correctly, but then
the optimizer "changes" this function's address or the function itself making
the initial pointer wrong which leads to a segfault... just a wild guess.
I think that adding the printf or a void function maybe adds some sort of
"unoptimizable" code at the start (like IO) and therefore the initial stored
pointer is unchanged after optimizations.
Oh yeah, it's worth mentioning that otherwise (if I don't put a bogus printf)
the first line of code of the function is a __builtin_memcpy which is probably
highly optimizable.
I'll try to come up with a short code example if I get the time later on.
Thank you
Guillaume
