This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug inline-asm/68095] "cc" clobber with Flag Output Operands


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

jbeulich at novell dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jbeulich at novell dot com

--- Comment #7 from jbeulich at novell dot com ---
I don't think duplicate clobber specifications should be an error. Otherwise
you'd be limiting (or complicating) the use in (perhaps multiple nested levels
of) macros.

And the traditional x86 behavior of always clobbering CC and FPSR isn't really
set in stone: As previously proposed
(https://gcc.gnu.org/ml/gcc-patches/2014-10/msg03251.html) an "inverse" clobber
could be used to suppress that behavior. I'm in the process of updating that
patch for re-submission.

Finally I'd like to note that for me in plain 6.1.0

void test(void)
{
  int v;

  asm ("" : "=@ccz" (v) :: "cc");
  asm ("" : "=@ccz" (v) :: "flags");
}

causes an internal compiler error due to expand_asm_stmt()'s initial conflict
checking (3rd pass) being insufficient for the final check (when about to store
the clobbers) to not trigger. A possible x86-specific approach might be to
detect and report the conflict in ix86_md_asm_adjust() and remove the bad
clobber there. But a generic approach would seem better, yet I have no idea how
that would need to be done.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]