[Bug c/68014] New: ICE when using Flag Output Operands

[Bug c/68014] New: ICE when using Flag Output Operands

[gccbugzilla at limegreensocks dot com]

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

            Bug ID: 68014
           Summary: ICE when using Flag Output Operands
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: minor
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gccbugzilla at limegreensocks dot com
  Target Milestone: ---

This code:

   #ifndef __GCC_ASM_FLAG_OUTPUTS__
   #error Not Defined
   #else

   int main()
   {
      int x;
      asm volatile("# %0" : "=@ccc"(x));
   }

   #endif

Gives this error:

   internal compiler error: in print_reg

I can't think of any way you could ever use the @cc parameter in the template. 
It seems like any attempt to do this should be invalid by definition.  Perhaps
@cc shouldn't even be issued one of the (limited number of) parameter #'s? 
That would solve the problem.  But for sure, ICE is not the right answer.

Note that the docs do say "the operand should not be referenced within the
assembler template via %0 etc, as there's no corresponding text in the assembly
language."

But there is a difference between "should not", "can not" and ICE.

[Bug inline-asm/68014] ICE when using Flag Output Operands

[gccbugzilla at limegreensocks dot com]

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

David <gccbugzilla at limegreensocks dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|minor                       |enhancement

--- Comment #1 from David <gccbugzilla at limegreensocks dot com> ---
In fact, if someone works on this bug before v6 is released (when all this gets
set in stone), I'd like to suggest an alternative for this 'flags' feature.

In short, I'm wondering if the current approach:

    bool boolval;
    asm("setc" : "=@ccc"(boolval));

should be changed to something more like:

    #define RETURNSCARRY __attribute__((asm_returnconditioncode(carry))

    bool boolval = RETURNSCARRY asm("setc" : );

In addition to it being (arguably) easier to read/understand, trying to cram
the flags into an output operand just doesn't fit:

- You can't use %0 inside the template or else you get an ICE (above).
- While the ICE can be fixed, it's not like %0 can actually be used inside the
template, so it isn't really an operand anyway.
- Using "@cc" as a constraint doesn't get rejected by earlier versions of the
compiler.  It compiles, but doesn't do what you expect.  This unnecessarily
opens the door for confusing bugs.
- Using "@cc" as a constraint mucks up multi-alternative.

Possible problems:

- It does remove the ability to return more than 1 condition code from a single
asm, but is that even a thing?
- The return value would need to be treated as an output when determining
whether the asm is volatile.  if (RETURNSCARRY asm("setc" : )) is not volatile,
even though it has 'no' output operands.
- Turning the asm statement into the asm function makes the already "not
standards compliant" extended asm even less standards compliant.

Perhaps internally this would be handled the same (the attribute causes a
'hidden' output operand to get added to the list), but treating it as a return
value is more consistent with how flags work.

[Bug target/68014] ICE when using Flag Output Operands

[segher at gcc dot gnu.org]

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

Segher Boessenkool <segher at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-10-29
                 CC|                            |segher at gcc dot gnu.org
          Component|inline-asm                  |target
     Ever confirmed|0                           |1

--- Comment #2 from Segher Boessenkool <segher at gcc dot gnu.org> ---
Confirmed the ICE.  It is a target bug: the x86 backend has an assert
here that we're not trying to print text for the flags register, it
should do output_operand_lossage or similar instead.

For other targets (e.g. those with multiple condition registers) it
_is_ useful to be able to refer to %0 here.

For @cc being silently accepted by older compilers (but meaning CX):
that's unfortunate, but you can check __GCC_ASM_FLAG_OUTPUTS__ making
this mostly moot.