This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug fortran/41403] [4.3/4.4/4.5 Regression] miscompilation of goto/label using code
- From: "rguenth at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 20 Sep 2009 14:05:08 -0000
- Subject: [Bug fortran/41403] [4.3/4.4/4.5 Regression] miscompilation of goto/label using code
- References: <bug-41403-10743@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #8 from rguenth at gcc dot gnu dot org 2009-09-20 14:05 -------
On the tree level we end up with the correct (but unfortunately unfolded)
main ()
{
int icon01;
<bb 2>:
if (&label_001263 == &label_001262)
goto <bb 5> (label_001265);
else
goto <bb 3> (label_001262);
label_001262:
if (&label_001263 == &label_001263)
goto <bb 5> (label_001265);
else
goto <bb 4> (label_001263);
label_001263:
# icon01_1 = PHI <1262(4), 1263(3), 1262(2)>
label_001265:
label_001271:
if (icon01_1 != 1263)
goto <bb 7>;
else
goto <bb 8>;
<bb 7>:
abort ();
<bb 8>:
return 0;
Note that comparing addresses of labels is inherently fragile as they may
collapse to a single location (like it happens here):
main:
pushl %ebp
movl %esp, %ebp
andl $-16, %esp
.L4:
.L3:
.L2:
.L5:
movl $.L3, %eax
cmpl $.L4, %eax
jne .L6
call abort
.L6:
movl $0, %eax
movl %ebp, %esp
popl %ebp
ret
forcing addresses of non-equivalent labels to compare non-equal would be
a way out here, but I think the Fortran frontend relies on a
fragile area of label address comparisons - labels are supposed to be
jumped to only.
That is, the Frontend presents us with
i.0 = -2;
ivfail = 0;
i.0 = -1;
i.1 = &__label_001263;
if ((logical(kind=4)) __builtin_expect (i.0 != -1, 0))
{
_gfortran_runtime_error_at (&"At line 3 of file t.f"[1]{lb: 1 sz: 1},
&"Assigned label is not a target label"[1]{lb: 1 sz: 1});
}
if (i.1 == &__label_001262) goto __label_001262;
if (i.1 == &__label_001263) goto __label_001263;
if (i.1 == &__label_001264) goto __label_001264;
...
but instead it should have used a computed goto, like
C.0 = { &__label_001262, &__label_001263, &__label_001264 };
goto *C.0[i - 1262];
for assigned goto.
Thus, this is a frontend issue with assigned goto (a deleted feature btw).
--
rguenth at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|middle-end |fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41403