http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51840
--- Comment #4 from Timo Kreuzer <timo.kreuzer at reactos dot org> 2012-09-15
12:16:38 UTC ---
Update: I fought a bit with GCC and made clear that my Kung Fu is better than
GCC's ;-)
I solved this issue with a workaround. I forced a number of constraints upon
GCC, that made it cry and stop shuffling the code around. These constraints
will make certain optimizations by moving code around useless, so assuming that
gcc will do the right thing, it won't move code onto pathes between the asm
goto and the actual label address.
So here's my code:
int
example1(int param)
{
int value = 0;
if (param > 2)
{
label1:
asm goto ("movl %0, %%ecx\n\tjmp %l[label3]\n" : : "i"(&&label3) :
"ecx" : label3, labelx);
}
value = 1;
if (param > 1)
{
label2:
asm goto ("movl %0, %%ecx\n\tjmp %l[label3]\n" : : "i"(&&label3) :
"ecx" : label3, labelx);
}
value = 2;
label3:
return value;
labelx:(void)0;
void *plabel;
asm volatile ("#" : "=a"(plabel) : "p"(&&label1), "p"(&&label2),
"p"(&&label3), "p"(&&labelx) : "memory");
goto *plabel;
}
Almost the same as before, with exception to the additional labelx construct.
First the asm instruction makes GCC think the addresses of all the labels might
be used here and after it we have plabel being eax containing something that
GCC doesn't know anything about.
The goto basically tells GCC that there are pathes between these labels.
GCC won't insert any "lazy" evaluation of constants into a codepath between
label1 and the static label3 address, because due to the additional asm goto
reference to labelx, it would need to add this code in the path between label1
and labelx as well. But since there is a virtual goto from labelx back to
label1, it would put the code into the inner of a loop, which it will try to
avoid.
Anyway this is a huge hack and works rather on the principle of good faith,
than on hard specifications.
Maybe someone finds an approach that is proovable to result in the right thing.
Or some gcc dev does the right thing and fixes asm goto.
