------- Comment #5 from jakub at gcc dot gnu dot org 2010-05-11 09:00 -------
I'd say the testcase is invalid, of course GCC must not ICE on it though,
but you can't expect it to do what you want.
I don't think we guarantee anywhere that the jump is exactly to the user
label provided, so you should jump to %l[f_yes] or %l[f_no], certainly never to
integer argument of &&f_yes or &&f_no. I believe GCC must be allowed to jump
to some internal label elsewhere and execute some instructions before jumping
to the user label. Otherwise we'd have to make all these edges from asm goto
abnormal.
That said, it doesn't make a difference on the trunk in this case, as you can
see by using jmp %l[f_yes] # %P0
FYI, on redhat/gcc-4_4-branch which has asm goto and __builtin_unreachable
backported the testcase works (the user labels (%P0 and %P1) are placed
non-sensically because of PR42739) when using the %l[f_yes]/%l[f_no] and the
testcase doesn't ICE. With PR42739 the user labels make more sense, but with
__builtin_unreachable it ICEs, so I guess this PR is related to PR42739 (the
ICE part) and to SSA expand which creates wrong RTL (the rest).
OT, we have a bug in the documentation:
@smallexample
int frob(int x)
@{
int y;
asm goto ("frob %%r5, %1; jc %l[error]; mov (%2), %%r5"
: : "r"(x), "r"(&y) : "r5", "memory" : error);
return y;
error:
return -1;
@}
@end smallexample
I guess that %1 should have been %0 and %2 should have been %1.
--
jakub at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rth at gcc dot gnu dot org
Target Milestone|--- |4.5.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44071
