------- 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