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.
