[Bug middle-end/40078] New: passing label to inline asm "i" constraint generates bad code

[Bug middle-end/40078] New: passing label to inline asm "i" constraint generates bad code

[scovich at gmail dot com]

Somewhat to my surprise, the gcc accepts the following inline asm syntax:

asm("jmp %0" : : "i"(&&some_label));

The output is what you'd expect: assuming some_label (in C/C++) is associated
with the assembler label .LLBF4 gives:

jmp .LLBF4

Unfortunately, the optimizer plays havoc with things by happily eliminating the
code associated with that label if it is otherwise unused. Consider the
following code: 

static inline int foo() { return 10; }
int could_be_anything;
long test_label(int volatile* ptr) {
    int rval = 0;
    int dummy = 5;
    static void* const gotos[2] = {&&DONE, &&ERROR};
    asm volatile("jmp %0\n\t nop": :"i"(&&ERROR),"i"(&foo),"r"(dummy));
    //goto *gotos[could_be_anything];
 DONE:
    return rval;
 ERROR:
    rval = 1;
    goto DONE;
}

This function should return 1 after jumping from ERROR to DONE. Instead, the
code for ERROR is eliminated by the optimizer; you either get a return value of
zero or an infinite loop depending on whether the label started below or above
the asm block (I get the latter):

foo:
        jmp     %o7+8
         mov    10, %o0
        .size   foo, .-foo
test_label:
.LL4:
.LL5:
        mov     5, %g1
! 8 "test_label.c" 1
        jmp .LL4
         nop
! 0 "" 2
        jmp     %o7+8
         mov    0, %o0
        .size   test_label, .-test_label


The compiler correctly recognizes that both dummy and foo are in use and does
not eliminate them, but ERROR gets the axe unless the computed goto is enabled. 

In theory the inconsistency should be easy to fix -- just mark the label as
in-use if it gets passed to a live inline asm block (exactly how functions and
variables are currently treated). If for some reason that's impossible or
undesirable, it should at least generate a diagnostic.


-- 
           Summary: passing label to inline asm "i" constraint  generates
                    bad code
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: scovich at gmail dot com
GCC target triplet: sparc-sun-solaris2.10


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

[Bug middle-end/40078] passing label to inline asm "i" constraint generates bad code

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2009-05-08 22:52 -------
This is by design, first inline-asm is not allowed to change control flow.
Second labels can be moved if they are not used normally in the program.  In
this case they are not used normally.  Addresses of labels are only designed
for computed gotos and any other use causes undefined behavior of their
placement.

Yes:
asm("jmp %0" : : "i"(&&some_label));

is valid as the address of a label is a constant but GCC does not look into the
string and how you use it.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


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

[Bug middle-end/40078] passing label to inline asm "i" constraint generates bad code

[scovich at gmail dot com]

------- Comment #2 from scovich at gmail dot com  2009-05-08 23:24 -------
Sorry to bring this back up, but I'm not sure if comments show up in a
meaningful way on closed bugs...

1. where does is it documented that inline asm can't change control flow? I
can't find it in the info pages, nor anywhere in google except this bug and
another which was also resolved-invalid with a comment that it's "clearly
commented." The docs say you can do control flow within a single asm (if your
assembler supports local labels), but the only other mention is the part that
says you can't jump between asm blocks because the compiler has no way to know
that you did it.

2. It makes sense that anything related to stack frames (ret, call) would be a
snake pit, but is there some reason why local gotos are inherently unsafe?
Unlike an asm-asm jump, the compiler knows all the places control might go (you
can only jump out once, after all), and presumably users wouldn't pass in
labels they don't intend to use. It seems like the compiler could just treat
the asm block accepting labels as a basic block containing a computed goto --
control could fall out the bottom of the block or jump any of the labels which
were passed in. 

3. Supporting local gotos would help work around the annoyance of getting
condition codes out of an asm block efficiently -- pass in the label to a
branch instruction and voila!

In any case, I'm happy to accept a, "go away," but would be extremely
interested to hear the reasons behind this limitation given that it seems so
close to working on accident.


-- 

scovich at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


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

[Bug middle-end/40078] passing label to inline asm "i" constraint generates bad code

[mirq-gccboogs at rere dot qmqm dot pl]

------- Comment #3 from mirq-gccboogs at rere dot qmqm dot pl  2010-03-21 01:08 -------
In case you're still interested, there is 'asm goto' coming in gcc 4.5.


-- 


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

[Bug middle-end/40078] passing label to inline asm "i" constraint generates bad code

[ebotcazou at gcc dot gnu dot org]

------- Comment #4 from ebotcazou at gcc dot gnu dot org  2010-09-20 22:12 -------
GCC 4.5 now supports asm gotos.


-- 

ebotcazou at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |WONTFIX
   Target Milestone|---                         |4.5.0


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