This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug fortran/41403] [4.3/4.4/4.5 Regression] miscompilation of goto/label using code



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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]