[Bug c/52381] New: asm goto output operands

[Bug c/52381] New: asm goto output operands

[marc.glisse at normalesup dot org]

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

             Bug #: 52381
           Summary: asm goto output operands
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: marc.glisse@normalesup.org


Hello,

asm goto doesn't allow output operands (this is documented). I haven't found an
enhancement request about it, but I think it is obvious that it is wanted. What
I would like to ask in the meantime is for a more specific error message than:

ex.c: In function 'h':
ex.c:4:42: error: expected ':' before string constant

or in the case of g++:

ex.cc: In function 'void h(int)':
ex.cc:4:42: error: expected ':' or '::' before string constant
ex.cc:4:74: error: undefined named operand 'g_'

Something like: "asm goto doesn't allow output operands" would be great. It
took me a while to understand what was wrong by reading the doc, even with the
nice column indication.

silly example (yes, the contraints don't make sense, it doesn't matter) that
gave the messages above:
void f(int);
void g();
void h(int i){
  asm goto( "cmpl %1, %0\n\tje %l[g_]" : "+g" (i) : "i" (42) : "cc" : g_);
  return f(i);
g_:
  return g();
}

[Bug c/52381] asm goto output operands diagnostics

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
           Keywords|                            |diagnostic
   Last reconfirmed|                            |2012-02-27
     Ever Confirmed|0                           |1
            Summary|asm goto output operands    |asm goto output operands
                   |                            |diagnostics
           Severity|enhancement                 |normal

--- Comment #1 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-02-27 09:22:52 UTC ---
I don't think asm goto was designed to contain more than a computed jump
instruction.  And I don't know how reliably we could allocate registers
for outputs on the multiple outgoing edges.

So, it's definitely by design.

Confirmed for the diagnostic issue.

[Bug c/52381] asm goto output operands diagnostics

[marc.glisse at normalesup dot org]

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

--- Comment #2 from Marc Glisse <marc.glisse at normalesup dot org> 2012-02-27 21:08:44 UTC ---
(In reply to comment #1)
> I don't think asm goto was designed to contain more than a computed jump
> instruction.  And I don't know how reliably we could allocate registers
> for outputs on the multiple outgoing edges.
> 
> So, it's definitely by design.

Note that if output was only reliable on the fall-through path, it would
already be useful. It may not have to be all-edges-or-nothing (or it may have
to, I don't know enough). Although that could be confusing...

> Confirmed for the diagnostic issue.

Thanks. While I am asking, I guess that since asm goto involves control flow it
never gets reordered (as opposed to regular asm), but if someone feels like
adding a sentence with this guarantee to the doc it would be helpful too.

[Bug c/52381] asm goto output operands diagnostics

[timo.kreuzer at reactos dot org]

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

Timo Kreuzer <timo.kreuzer at reactos dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |timo.kreuzer at reactos dot
                   |                            |org

--- Comment #3 from Timo Kreuzer <timo.kreuzer at reactos dot org> 2013-01-10 13:49:11 UTC ---
I support this feature request.
As an exmple I'd like to mention the x86 instruction cmpxchg.
While GCC has 2 CAS builtins (__sync_bool_compare_and_swap and
__sync_val_compare_and_swap) neither of these supports what the x86 cmpxchg
instruction does, namely returning both a boolean value indicating success AND
the previous value of the memory operand in case of failure.

So here's the code that would handle this, if output operand was usable.

try_again:

    // do something

    asm goto
    (
        "lock cmpxchg %%ecx, %[Destination] \t\n"
        "jnz %l[try_again] \t\n"
        : "=c"(Exchange) // <= does not work
        : [Destination]"m"(Destination), [Comparand]"a"(Comparand),
[Exchange]"c"(Exchange)
        : "memory"
        : try_again
    );

Note that in this case the output is needed on the jump path.

[Bug c/52381] asm goto output operands diagnostics

[schwab@linux-m68k.org]

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

--- Comment #4 from Andreas Schwab <schwab@linux-m68k.org> 2013-01-10 14:12:54 UTC ---
Like __atomic_compare_exchange_n?

[Bug c/52381] asm goto output operands diagnostics

[timo.kreuzer at reactos dot org]

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

--- Comment #5 from Timo Kreuzer <timo.kreuzer at reactos dot org> 2013-01-11 14:55:15 UTC ---
(In reply to comment #4)
> Like __atomic_compare_exchange_n?

Oh, didn't know of this one, thanks.
But I'm sure there are other similar things you could solve with the output of
asm goto ;-)

[Bug c/52381] asm goto output operands diagnostics

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52381

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |11.0
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Fixed in GCC 11 by allowing output operands in inline-asm gotos.

That is the code is accepted ...