[Bug optimization/12108] wrong code generated in the presence of asm("...")

["anton at a0 dot complang dot tuwien dot ac dot at" <gcc-bugzilla at gcc dot gnu dot org>]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12108



------- Additional Comments From anton at a0 dot complang dot tuwien dot ac dot at  2003-09-12 11:37 -------
Subject: Re:  wrong code generated in the presence of asm("...")

falk at debian dot org wrote:
> I don't think gcc does, or should guarantee anything about the value of labels
> except that jumping to them works. Can you provide a test case where a goto hits
> the wrong place? Otherwise I don't think this is a bug.

This bug exists independent of the labels stuff.  Even if I remove the
labels and all references to them, the faulting code is still the
same.  I.e., a conftest.c like this:

int foo(int);
main()
{
  exit(foo(0)!=16);
}
int foo(int x)
{
  if (x) {
    asm(".skip 16"); /* or ".space 16" or somesuch */
  }
  return 0;
}

still produces a SIGILL and the assembly code for foo looks like this:

foo
        .PROC
        .CALLINFO FRAME=0,NO_CALLS
        .ENTRY
        comiclr,= 0,%r26,%r0
        .skip 16
L$0003
        bv %r0(%r2)
        ldi 0,%r28
        .EXIT
        .PROCEND

Concerning a test case where the goto hits the wrong place: I have
played around with the second example (with "y++") a little, and it
seems that as soon as I insert a goto, the label corresponding to
label1 is produced in the right place.  This might be so by design,
but also by accident, so I feel a little nervous about relying on it.
In any case, a version that works (around the bug on hppa) is:

int foo(int,int,int);
main()
{
  exit(foo(0,0,0)!=16);
}
int y;
int foo(int x, int y, int z)
{
  static void *labels[]={&&label1,&&label2};
  if (x) {
    y++;
  label1:
    asm(".skip 16"); /* or ".space 16" or somesuch */
  label2: ;
  }
  {
  if (y) goto *labels[z];
  return labels[1]-labels[0];
  }
}

Whether gcc should guarantee something about the values of labels
beyond being able to goto there: There are a number of systems that
work by copying code between two labels (as-values) at run-time; e.g.,
Gforth, qemu and Tempo.  These systems require more than just being
able to goto labels.  gcc-2.95 provides for this on all platforms I
have tested.  I think future gccs should provide for it, too (maybe
requiring special flags like -fno-reorder-blocks, but certainly in one
way or the other).

- anton