Hi,
I'm not sure this qualifies as a bug or not, but there might be some room for
improvement here.
Given the following piece of code, compiled with gcc 4.1.2 without
optimization:
int main(int argc, char **argv)
{
main_start:
printf("%x %x %x %d\n", &&main_start, &&blah_start, &&blah_end,
&&blah_end - &&blah_start);
goto blah_end;
blah_start:
__asm__ __volatile__ ("int $0x80");
blah_end:
return 1;
}
I get the results: 80483b5 80483b5 80483ed 56
First of all gcc obviously determines the inline assembler is dead code and
removes it. This doesn't seem really bad in most cases, although the inline
assembler has been marked volatile. Should gcc remove unreachable volatile
inline assembler like this? If so, is there any (non-hackish) way to instruct
the compiler to keep off? Wasn't volatile meant for this in the first place?
Second, after dead code removal the label 'blah_start' is at the same address
as the label 'main_start', which seems very counter-intuitive.
There will probably be a good reason for this (I can imagine after dead code
removal you're left with an empty basic block, which can be reordered in any
way you want), but wouldn't it be more clear if this will give the same results
as one would get when removing the inline assembler by hand? I.e. where the
address of blah_start will be equal to the address of blah_end, which is what
one would expect in the first place? Or does some part of some standard outline
this leads to undefined behaviour?
I hope someone has a bit of time to spare to shed some light on this issue.
With kind regards,
-- Ronald Huizer
--
Summary: gcc 4.1.2 labels in removed dead code weirdness
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: scrippie at xs4all dot nl
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32480
