[Bug inline-asm/39440] User Manual: describe asm ("%a0,%c0"::)

[gccbugzilla at limegreensocks dot com]

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

David  changed:

   What|Removed |Added

 CC||gccbugzilla@limegreensocks.
   ||com

--- Comment #4 from David  ---
(In reply to Ian Lance Taylor from comment #3)

Since I am working on the extended asm docs, this might be something I could
look at.  The question is, which ones get doc'ed?  The letters acln are
platform neutral (see output_asm_insn in final.c).  Anything beyond that is
platform specific.  Do we really want to doc every letter for every platform?
(yikes!)

I don't own a vax, pdp, sparc, or most of the other 40 odd platforms supported
by gcc.  There's no way I could test modifiers to see if they produce what I
think they do for most platforms, which makes doc'ing them problematical. 

I could take a look at the ones for i386, but there's no point in even doing
that until there's agreement about which ones to doc.  

Who decides?  Or if I'm the person doing the work, do I get to?

[Bug target/89482] arm aarch32 inline assembly w constraints generate s registers instead of d

[gccbugzilla at limegreensocks dot com]

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

--- Comment #7 from David  ---
(In reply to ktkachov from comment #6)
> I think David (CC'ed) was interested in this?
Well, the news here is mixed.

While I attempted to write this (see
https://www.limegreensocks.com/arm/Extended-Asm.html#AArch64Operandmodifiers),
I don't actually speak ARM assembler.  AAR, my confidence in my attempts to
explain things or give examples is limited.  I'm not excited about posting a
doc patch that turns out to be stupid when viewed by ARM experts.

Unless someone who does speak ARM is prepared to comment/review, I'm not sure
how to proceed.  And the few people I know who do speak ARM aren't responding.

- David

[Bug target/89482] arm aarch32 inline assembly w constraints generate s registers instead of d

[gccbugzilla at limegreensocks dot com]

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

--- Comment #9 from David  ---
(In reply to Ciro Santilli from comment #8)

- I haven't posted a patch file since I wasn't sure that I was all that close
to being done.  But I'm certainly not opposed to the idea.  Were you
volunteering to move this forward?

- "document the aarch32 modifiers" It's been discussed, but since I'm already
unable to move aarch64 forward...

- As I've mentioned, I'm not enough of an ARM expert to explain why things are
they way they are.  It's possible that the reason there are "both 't' and 'w'"
has to do with history.  Additionally, remember that machine constraints aren't
just for inline asm.  They are used in the MD files as well where the
differences may have more meaning.

[Bug target/89482] arm aarch32 inline assembly w constraints generate s registers instead of d

[gccbugzilla at limegreensocks dot com]

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

--- Comment #11 from David  ---
(In reply to Ciro Santilli from comment #10)
> If I do start work, I'll ping here to avoid work duplication.

Do.  I have some resources I could email you.

[Bug libstdc++/69562] New: cow-stdexcept.cc compile errors due to __GXX_WEAK__

[gccbugzilla at limegreensocks dot com]

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

Bug ID: 69562
   Summary: cow-stdexcept.cc compile errors due to __GXX_WEAK__
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gccbugzilla at limegreensocks dot com
  Target Milestone: ---

Building gcc trunk (232969) on cygwin64 using this config line:

/cygdrive/c/cygwin64/src/gcc-trunk/configure --enable-languages=c,c++
--disable-multilib --disable-nls --disable-win32-registry
--enable-checking=release --disable-bootstrap
--enable-version-specific-runtime-libs --disable-fixed-point
--prefix=/home/david/los3b

gives the errors below.

This problem began with checkin 232453, and (as a workaround) can be resolved
by adding this line to the top of cow-stdexcept.cc:

#undef __GXX_WEAK__

Possibly related:

The system build of gcc (5.2.0) does not define __GXX_WEAK__.  However in the
build directory, gcc/xgcc.exe, prev-gcc/xgcc.exe and stage1-gcc/xgcc.exe all
define it as 1.

FWIW, using -enable-bootstrap does not resolve the problem.


libc++11convenience.a(cow-stdexcept.o): In function
`_txnal_cow_string_C1_for_exceptions(void*, char const*, void*)':
4/src/gcc-trunk/libstdc++-v3/src/c++11/cow-stdexcept.cc:236:(.text$_Z35_txnal_cow_string_C1_for_exceptionsPvPKcS_+0x2c):
relocation truncated to fit: R_X86_64_PC32 against undefined symbol `_ITM_RU1'
4/src/gcc-trunk/libstdc++-v3/src/c++11/cow-stdexcept.cc:248:(.text$_Z35_txnal_cow_string_C1_for_exceptionsPvPKcS_+0x39):
relocation truncated to fit: R_X86_64_PC32 against undefined symbol
`transaction clone for operator)'
4/src/gcc-trunk/libstdc++-v3/src/c++11/cow-stdexcept.cc:267:(.text$_Z35_txnal_cow_string_C1_for_exceptionsPvPKcS_+0x5d):
relocation truncated to fit: R_X86_64_PC32 against undefined symbol
`_ITM_memcpyRtWn'
libc++11convenience.a(cow-stdexcept.o): In function `txnal_read_ptr':
4/src/gcc-trunk/libstdc++-v3/src/c++11/cow-stdexcept.cc:278:(.text$_Z23_txnal_cow_string_c_strPKv+0x1):
relocation truncated to fit: R_X86_64_PC32 against undefined symbol `_ITM_RU8'
4/src/gcc-trunk/libstdc++-v3/src/c++11/cow-stdexcept.cc:278:(.text$_Z23_txnal_sso_string_c_strPKv+0x1):
relocation truncated to fit: R_X86_64_PC32 against undefined symbol `_ITM_RU8'
4/src/gcc-trunk/libstdc++-v3/src/c++11/cow-stdexcept.cc:278:(.text$_Z20_txnal_cow_string_D1Pv+0x5):
relocation truncated to fit: R_X86_64_PC32 against undefined symbol `_ITM_RU8'
libc++11convenience.a(cow-stdexcept.o): In function
`_txnal_cow_string_D1(void*)':
4/src/gcc-trunk/libstdc++-v3/src/c++11/cow-stdexcept.cc:324:(.text$_Z20_txnal_cow_string_D1Pv+0x1e):
relocation truncated to fit: R_X86_64_PC32 against undefined symbol
`_ITM_addUserCommitAction'
libc++11convenience.a(cow-stdexcept.o): In function `transaction clone for
std::logic_error::logic_error(char const*)':
4/src/gcc-trunk/libstdc++-v3/src/c++11/cow-stdexcept.cc:408:(.text$_ZGTtNSt11logic_errorC1EPKc+0x2e):
relocation truncated to fit: R_X86_64_PC32 against undefined symbol
`_ITM_memcpyRnWt'
libc++11convenience.a(cow-stdexcept.o): In function `transaction clone for
std::logic_error::logic_error(std::__cxx11::basic_string, std::allocator > const&)':
4/src/gcc-trunk/libstdc++-v3/src/c++11/cow-stdexcept.cc:408:(.text$_ZGTtNSt11logic_errorC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE+0x2e):
relocation truncated to fit: R_X86_64_PC32 against undefined symbol
libc++11convenience.a(cow-stdexcept.o): In function `txnal_read_ptr':
4/src/gcc-trunk/libstdc++-v3/src/c++11/cow-stdexcept.cc:278:(.text$_ZGTtNSt11logic_errorC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE+0x36):
relocation truncated to fit: R_X86_64_PC32 against undefined symbol
libc++11convenience.a(cow-stdexcept.o): In function `transaction clone for
std::logic_error::~logic_error()':
4/src/gcc-trunk/libstdc++-v3/src/c++11/cow-stdexcept.cc:408:(.text$_ZGTtNSt11logic_errorD0Ev+0x1a):
additional relocation overflows omitted from the output

[Bug libstdc++/69562] cow-stdexcept.cc compile errors due to __GXX_WEAK__

[gccbugzilla at limegreensocks dot com]

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

David  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from David  ---
Fixed using 233007.

*** This bug has been marked as a duplicate of bug 69506 ***

[Bug bootstrap/69506] [6 Regression] check-in 232454 seems to cause problems with cygwin builds

[gccbugzilla at limegreensocks dot com]

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

David  changed:

   What|Removed |Added

 CC||gccbugzilla@limegreensocks.
   ||com

--- Comment #7 from David  ---
*** Bug 69562 has been marked as a duplicate of this bug. ***

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

[gccbugzilla at limegreensocks dot com]

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

--- Comment #6 from David  ---
Created attachment 37621
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37621&action=edit
Patch for missing clobber validations

I have created a patch (attached) that does the check I am describing.  And
while I was at it, I added a few other validations for clobber conditions.  The
patch includes testcases, but in short, these lines (which currently produce no
messages) would all give errors:

  __asm__ volatile("":::"eax","eax");
  __asm__ volatile("":::"memory", "memory");
  __asm__ volatile("":::"cc", "cc");
  __asm__ volatile("":"=@ccc"(c)::"cc");

[Bug target/69716] New: asm generates invalid register name

[gccbugzilla at limegreensocks dot com]

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

Bug ID: 69716
   Summary: asm generates invalid register name
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gccbugzilla at limegreensocks dot com
  Target Milestone: ---

While this is a problem with inline asm, it seems like it would be
target-specific which is why I set component: target.

I can produce the problem several ways.  This is probably the simplest:

unsigned char a = 0;
asm volatile("mov $0, %0" : "=r"(a) : : "ax", "bx", "cx", "dx");

Compile this with gcc -m32 -S, and you see:

mov $0, %sil

However, sil is not a valid register name on x86 (although it is on x64).

You can get similar behavior with:

   unsigned char a, b, c, d, e;
   asm volatile("# %0 %1 %2 %3 %4" : "=r"(a),"=r"(b),"=r"(c),"=r"(d),"=r"(e));

This generates:

# %dil %sil %bl %cl %dl

Neither dil nor sil are valid register names for 32bit.

[Bug target/62109] __gthr_i486_lock_cmp_xchg missing clobber

[gccbugzilla at limegreensocks dot com]

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

--- Comment #14 from David  ---
I understand that stage 3 is now closed too.  I don't have svn write access, so
I can't check this in myself.

[Bug inline-asm/69899] gcc ICE on invalid code on x86_64-linux-gnu in "replace_reg"

[gccbugzilla at limegreensocks dot com]

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

David  changed:

   What|Removed |Added

 CC||gccbugzilla@limegreensocks.
   ||com

--- Comment #2 from David  ---
To confirm the ice and to provide more details:

double a;
fn1(){ asm("" : "=t"(a) : "0u"(0));   } // replace_reg at reg-stack.c:687
fn2(){ asm("" : "=t"(a) : "0u"(0.0)); } // No ICE
fn3(){ asm("" : "=t"(a) :  "u"(0.0)); } // change_stack at reg-stack.c:2522

fn1 is the OP's code.  Changing the input to a float (0.0 vs 0) resolves the
first ICE, but removing the "0" from the input constraint throws another.

[Bug inline-asm/30527] Use of input/output operands in __asm__ templates not fully documented

[gccbugzilla at limegreensocks dot com]

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

David  changed:

   What|Removed |Added

 CC||gccbugzilla@limegreensocks.
   ||com

--- Comment #5 from David  ---
These modifiers are intended primarily for use by Machine Descriptions.  As a
result, some of them aren't going to be meaningful/usable by inline asm code. 
And it makes sense to leave open the option to change their meaning should
future MD work require it, something that documenting them all would prevent.

On the other hand, some of these values are indeed quite useful for inline asm.

The compromise, as evidenced by 6.43.2.7 (added in v5.x), is to document
certain commonly needed/used modifiers (such as the %k0 referenced above).

If there is some additional modifier that you need, I'd recommend opening a new
bug and making an explicit case for it.

In the meantime, I recommend closing this bug (as fixed).

[Bug inline-asm/39440] User Manual: describe asm ("%a0,%c0"::)

[gccbugzilla at limegreensocks dot com]

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

--- Comment #5 from David  ---
This is a duplicate of 30527.

A subset of the most commonly needed/used modifiers have been added to the docs
as of 5.x (including the %c0 referenced above).  For this reason, I recommend
this bug be closed.

If there is some additional modifier that you need, I'd recommend opening a new
bug and making an explicit case for it.

[Bug inline-asm/43319] Lack of documentation on asm extension

[gccbugzilla at limegreensocks dot com]

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

David  changed:

   What|Removed |Added

 CC||gccbugzilla@limegreensocks.
   ||com

--- Comment #3 from David  ---
This is a duplicate of 30527.

A subset of the most commonly needed/used modifiers have been added to the docs
as of 5.x (including the %c1 referenced above).

%P (also mentioned above) is not currently documented, and I see no reason that
it should be.  An examination of glibc suggests that instead of using the
undocumented/unsupported %P1, they can accomplish what they need with the
already documented %c1.

[Bug other/68610] configure failure in libssp

[gccbugzilla at limegreensocks dot com]

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

--- Comment #2 from David  ---
Yes, this still occurs with trunk Revision 239974.  I'm using MSYS2 under
Windows and my current configure line is:

../gcctrunk/configure --enable-languages=c,c++ --target=x86_64-w64-mingw32
--build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --disable-multilib
--disable-nls --disable-win32-registry --enable-checking=release
--disable-bootstrap --enable-version-specific-runtime-libs
--disable-fixed-point --prefix=/home/david/gccb --enable-twoprocess
--with-native-system-header-dir=/mingw64/include

None of which turns out to be important.

Looking at libssp/configure.ac, we see this code for testing to see if
fstack-protector works:

AC_MSG_CHECKING([whether -fstack-protector works])
save_CFLAGS="$CFLAGS"
CFLAGS="$CFLAGS -fstack-protector -Werror"
AC_TRY_COMPILE([
void __attribute__((noinline)) bar (char *x)
{
  __builtin_memset (x, 0, 64);
}],[char buf[64]; bar (buf);],
[AC_MSG_RESULT(yes)],
[AC_MSG_RESULT(no)])
CFLAGS="$save_CFLAGS"

Note how it saves the CFLAGS, explicitly sets Werror, then does the
AC_TRY_COMPILE.  Contrast this with the code that immediately follows which
attempts to do the same thing for visibility:

AC_MSG_CHECKING([whether hidden visibility is supported])
AC_TRY_COMPILE([
void __attribute__((visibility ("hidden"))) bar (void) {}],,
[ssp_hidden=yes],[ssp_hidden=no])
AC_MSG_RESULT($ssp_hidden)
if test x$ssp_hidden = xyes; then
  AC_DEFINE([HAVE_HIDDEN_VISIBILITY],[1],[__attribute__((visibility
("hidden"))) supported])
fi

If visibility is NOT supported, the compiler will produce a warning.  However,
since in this case Werror is NOT being specified, the compile 'succeeds,' and
visibility is assumed to be supported, even though the compiler explicitly said
it wasn't.

I've learned a lot about how configure scripts work since I originally posted
this bug.  Hopefully this helps makes the problem clearer.

[Bug middle-end/58670] asm goto miscompilation

[gccbugzilla at limegreensocks dot com]

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

David  changed:

   What|Removed |Added

 CC||gccbugzilla@limegreensocks.
   ||com

--- Comment #5 from David  ---
What's the status here?  While there was a checkin (r203383 & r203384), this
sample code still does not work correctly (4.9.0 x86_64-w64-mingw32).  The
fall-thru case works, but if the jump inside the asm is taken, eax does not get
set to zero when it clearly should.

My -O2 output is:

004014e0 :
  4014e0:test   ecx,ecx
  4014e2:movDWORD PTR [rsp+0x10],edx
  4014e6:jne4014f3 
  4014e8:btsDWORD PTR [rsp+0x10],0x1
  4014ee:jb 401500 
  4014f0:xoreax,eax
  4014f2:ret
  4014f3:moveax,0xfffd
  4014f8:nopDWORD PTR [rax+rax*1+0x0]
  401500:repz ret 
  401502:data32 data32 data32 data32 nop WORD PTR cs:[rax+rax*1+0x0]

[Bug middle-end/58670] asm goto miscompilation

[gccbugzilla at limegreensocks dot com]

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

--- Comment #8 from David  ---
I can confirm what Kai had to say in comment 7.  Using a newer build resolves
both the original problem reported by Jakub and the problem I saw in comment 5.

[Bug target/62109] __gthr_i486_lock_cmp_xchg missing clobber

[gccbugzilla at limegreensocks dot com]

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

--- Comment #4 from David  ---
(In reply to Mikael Pettersson from comment #3)
> Do you have a test case which fails without your patch?

I do not.  But this is a "by definition" thing.

This instruction is intended to emulate the Windows InterlockedCompareExchange
instruction (see the comments above the code).  And all Windows Interlocked*
instructions perform an implicit compiler barrier.  After all, it does no good
for the 'lock' prefix to prevent the processor from re-ordering instructions if
the compiler does it while building the code.  Moving loads or stores past this
statement makes a mess of thread synchronization.

That said, this instruction was only intended to be used on Win95 (neither NT
nor Win98 need it).  Not exactly a common platform these days.  But it's
possible someone is still using this, or will copy this asm block for their own
use, so it should still be correct.

[Bug inline-asm/65436] Max number of extended asm +input operands currently limited to 15

[gccbugzilla at limegreensocks dot com]

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

David  changed:

   What|Removed |Added

 CC||gccbugzilla@limegreensocks.
   ||com

--- Comment #2 from David  ---
In fact, this effect of '+' is explicitly documented at
:

Operands using the '+' constraint modifier count as two operands (that is, both
as input and output) towards the total maximum of 30 operands per asm
statement.

Have you actually hit this limit?  Or is this a theoretical discussion?

[Bug target/62109] __gthr_i486_lock_cmp_xchg missing clobber

[gccbugzilla at limegreensocks dot com]

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

--- Comment #6 from David  ---
Actually, the code already uses InterlockedCompareExchange.  UNLESS users
explicitly tell it not to:

#ifdef __GTHREAD_I486_INLINE_LOCK_PRIMITIVES
static inline long
__gthr_i486_lock_cmp_xchg(long *__dest, long __xchg, long __comperand)
{
  long result;
  __asm__ __volatile__ ("\n\
lock\n\
cmpxchg{l} {%4, %1|%1, %4}\n"
: "=a" (result), "=m" (*__dest)
: "0" (__comperand), "m" (*__dest), "r" (__xchg)
: "cc");
  return result;
}
#define __GTHR_W32_InterlockedCompareExchange __gthr_i486_lock_cmp_xchg
#else  /* __GTHREAD_I486_INLINE_LOCK_PRIMITIVES */
#define __GTHR_W32_InterlockedCompareExchange InterlockedCompareExchange
#endif /* __GTHREAD_I486_INLINE_LOCK_PRIMITIVES */

Since we are talking about postponing this to stage 1 (which I do not object
to), what if we change this to something like:

#ifdef __GTHREAD_I486_INLINE_LOCK_PRIMITIVES
#error "__GTHREAD_I486_INLINE_LOCK_PRIMITIVES is no longer supported. Remove
this definition to use system calls for Win98 and above."
#else  /* __GTHREAD_I486_INLINE_LOCK_PRIMITIVES */
#define __GTHR_W32_InterlockedCompareExchange InterlockedCompareExchange
#endif /* __GTHREAD_I486_INLINE_LOCK_PRIMITIVES */

Then wait to see if anyone cares.

I am ok with either fixing it (by adding the "memory" clobber) or removing it
(since the problem it was intended to fix only happens on OSs that aren't
supported anymore).  But leaving it "as-is" leaves open the possibility that
people are using this without even knowing it (and getting
nearly-impossible-to-track-down timing problems).  Or that someone might
copy/paste this code into their own projects.

[Bug target/62109] __gthr_i486_lock_cmp_xchg missing clobber

[gccbugzilla at limegreensocks dot com]

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

--- Comment #8 from David  ---
(In reply to Kai Tietz from comment #7)
The first code block in comment #6 is what is in the code now.  As you can see,
it already has the #define you are describing.  I don't understand what you
mean by "change it to" this, since it is already there.

Are you suggesting we delete the entire #ifdef
__GTHREAD_I486_INLINE_LOCK_PRIMITIVES block and replace it with the single
#define?  I would be ok with that.  Using the #error (the second code block in
comment #6) seemed like a more backward-compatible way to do this, since it
would tell people what has happened and what to do to fix it rather than
(silently) assuming we know what they want to do.

But I am ok with either of these two solutions.

[Bug inline-asm/65436] Max number of extended asm +output operands currently limited to 15

[gccbugzilla at limegreensocks dot com]

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

--- Comment #7 from David  ---
While I don't yet see a case here to justify making this change generally, it
may be useful to change this for private builds of gcc.  For those cases,
change this line in gcc/genconfig.c:

  max_recog_operands = 29;  /* We will add 1 later.  */

This generates MAX_RECOG_OPERANDS in insn-config.h, which controls the number
of parameters for asm statements.

Like Andrew, I would be interested to see what you are doing that modifies > 15
registers in inline asm on x86.  My gut says there's got to be a cleaner way
than throwing more parameters at it, but maybe not.

[Bug inline-asm/65741] New: Missed loop optimization with asm

[gccbugzilla at limegreensocks dot com]

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

Bug ID: 65741
   Summary: Missed loop optimization with asm
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gccbugzilla at limegreensocks dot com

Trimming the code down to minimal:

int main()
{
   int lo;

   for(int x=0; x < 10; x++)
   {
  asm ( "# asm here" : "=r" (lo));
   }

   return lo;
}

Compile with: c++.exe -O2 -m64 -S loop.cpp
x86_64-w64-mingw32 5.0.0

The -O2 optimization correctly detects that the asm statement can be moved
outside the loop (and moves it).  However, it then leaves an empty loop:

movl$10, %edx
/APP
 # 7 "loop.cpp" 1
#
 # 0 "" 2
.p2align 4,,10
/NO_APP
.L2:
subl$1, %edx
jne .L2

With the asm moved, the .L2 loop serves no purpose.  I expected it to get
optimized out.

Even more perplexing is that if the asm has 2 outputs, it *doesn't* get moved
outside the loop:

int main()
{
   int hi, lo;

   for(int x=0; x < 10; x++)
   {
  asm  ( "# asm here" : "=r" (lo), "=r" (hi));
   }

   return hi * lo;
}

movl$10, %edx
.p2align 4,,10
.L2:
/APP
 # 7 "loop.cpp" 1
# asm here
 # 0 "" 2
/NO_APP
subl$1, %edx
jne .L2

I expected this asm to get moved just like the other one did.

[Bug c++/67776] New: Missing warning when using asm labels

[gccbugzilla at limegreensocks dot com]

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

Bug ID: 67776
   Summary: Missing warning when using asm labels
   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: ---

When compiling this code:

void f(void)
{
   int foo asm("myfoo") = 42;
}

using: gcc -c sta7.c

I (correctly) get the warning message: 

   warning: ignoring asm-specifier for non-static local variable 'foo'

However, if I rename the file from sta7.c to sta7.cpp, I no longer get the
warning.  Since the variable is still a non-static local variable, I expected
to still get the warning.

While not particularly interesting of itself, this makes me wonder what other c
error checking might be getting skipped in c++.

[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 target/62109] __gthr_i486_lock_cmp_xchg missing clobber

[gccbugzilla at limegreensocks dot com]

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

--- Comment #10 from David  ---
(In reply to Kai Tietz from comment #5)
> This patch is clear stage 1 material. 

We're in stage 1.  Is it time?

The patch adds the memory clobber, but I think the conclusion here was to
remove __gthr_i486_lock_cmp_xchg since it only applies to (the no longer
supported) win95.

[Bug target/62109] __gthr_i486_lock_cmp_xchg missing clobber

[gccbugzilla at limegreensocks dot com]

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

David  changed:

   What|Removed |Added

  Attachment #33302|0   |1
is obsolete||

--- Comment #12 from David  ---
Created attachment 36577
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36577&action=edit
Update patch per comment 11

Instead of just adding the clobber, this second patch removes the whole routine
that was only needed on win95.  It also removes the (no longer used) define for
__GTHREAD_I486_INLINE_LOCK_PRIMITIVES and updates the comment.

Note that I do not have commit privileges to svn, which is why I post this here
rather than to the patches ml.

[Bug inline-asm/68084] Inverted conditions generated for x86 inline assembly "flag output constraints"

[gccbugzilla at limegreensocks dot com]

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

David  changed:

   What|Removed |Added

 CC||gccbugzilla@limegreensocks.
   ||com

--- Comment #1 from David  ---
Created attachment 36580
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36580&action=edit
Possible fix

As I read the code, I think the logic for 'ae' is just backwards.  Try this.

[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  changed:

   What|Removed |Added

   Severity|minor   |enhancement

--- Comment #1 from David  ---
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 inline-asm/68095] New: "cc" clobber with Flag Output Operands

[gccbugzilla at limegreensocks dot com]

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

Bug ID: 68095
   Summary: "cc" clobber with Flag Output Operands
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: inline-asm
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gccbugzilla at limegreensocks dot com
  Target Milestone: ---

Normally when trying to use a register and clobber it at the same time, the
compiler kicks out an error (operand has impossible constraints).  However that
doesn't happen when using Flag Output Operands and the "cc" clobber:

  asm ("cmp %2, %1" : "=@ccc"(r) : "m"(*p), "ri"(2): "cc");

Should this be a conflict?

On the other hand, the asm is changing the flags.  So is the "cc" *required*? 
But it doesn't seem to be:

  asm ("cmp %2, %1" : "=@ccc"(r) : "m"(*p), "ri"(2));

Now that asm flags are a real thing, we should pick one and enforce it.

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

[gccbugzilla at limegreensocks dot com]

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

--- Comment #1 from David  ---
On further reflection, perhaps the best solution is even simpler.

It is my understanding that the "cc" clobber is redundant.  Internally, the
flags are clobbered whether you set this or not.  And I can't see how this
behavior can ever change now that it has been like this for so long.

As a result, perhaps the solution is to just change the docs for the "cc"
clobber to say that it is meaningless.  Maybe something like:

"cc" This clobber is only kept for historical reasons.  It no longer has any
effect on the generation of code.

[Bug inline-asm/10396] Constraint alternatives cause error " `asm' operand requires impossible reload"

[gccbugzilla at limegreensocks dot com]

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

David  changed:

   What|Removed |Added

 CC||gccbugzilla@limegreensocks.
   ||com

--- Comment #22 from David  ---
Despite the impression you may get from comments 17-21, gcc DOES support
multi-alternatives with inline asm (see
https://gcc.gnu.org/ml/gcc/2015-10/msg00249.html).

I do not have an arm build with which to test, but using 5.2 on x64, the
samples in this bug do not produce errors.  Perhaps in the 7-12 years since
they were added, something got fixed?  Or maybe this problem is
platform-specific.

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

[gccbugzilla at limegreensocks dot com]

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

--- Comment #3 from David  ---
> "=@ccc"(r) does not output to the "cc" register, it 
> outputs to a general register.  

Actually, I don't believe it does.

In v5, you *did* have to use "setc %0" with a general register AND it generated
an extra "cmp" instruction (very irritating).  But this code:

int main()
{
   int x;

   do {
  asm volatile("setc" : "=@ccc"(x) : : "cc");
   } while (!x);
}

Compiled with -O2, now outputs:

.L2:
/APP
setc
/NO_APP
jnc .L2

No general register required.  It really is just using the flags.  

So it still looks to me like we are both clobbering flags (implying that they
are changed but not output) and outputting them.  Allowing both at once seems
bad.

> The "cc" clobber is not deprecated, not on other targets anyway.

As I look at final_scan_insn() in final.c, it appears to always call
CC_STATUS_INIT for both basic and extended asm.  And while not all platforms
may implement CC_STATUS_INIT, my assumption was that if the platform supported
the "cc" clobber, this was where the implementation was.

If there is no way to NOT clobber, then "cc" becomes an unenforced comment,
rather than a directive to change the behavior of the compiler.  If that's
true, updating the docs to say so seems reasonable.

[Bug target/62109] __gthr_i486_lock_cmp_xchg missing clobber

[gccbugzilla at limegreensocks dot com]

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

--- Comment #13 from David  ---
Rumor has it that Phase 1 may be closing soon.  Is there something else I need
to do here?

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

[gccbugzilla at limegreensocks dot com]

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

--- Comment #5 from David  ---
> the target code adds a cc clobber always.

Agreed.  On i386, there is no way to say that an extended asm doesn't clobber
"cc", so it only serves as a comment on that specific platform.

> There is no conflict.

I believe we may be talking about two different things.  From the point of view
of -da and -S, no conflicting code is generated.  The output is correct and
functions as expected.

But looking at the definition of a clobber:

- "values changed by the AssemblerTemplate, beyond those listed as outputs."
- "Clobber descriptions may not in any way overlap with an input or output
operand."

It's hard to reconcile those statements with this code (which the compiler
currently accepts):

asm("bt $0, %1" : "@ccc" (vout) : "r" (vin) : "cc");

Looking at -da output, it looks like "cc" generates "clobber reg:CC", while @cc
generates "set reg:CC".  It makes no sense to ever generate both, which is what
this C statement implies.

I believe the correct way to write this (which the compiler also accepts and
generates identical code) is:

asm("bt $0, %1" : "@ccc" (vout) : "r" (vin));

Silently ignoring the user's attempt to simultaneously use and clobber cc is a
logical guess about what the user really wants.  But I'm saying the compiler
should instead treat that the same way it treats simultaneously clobbering and
using other things.  For example:  asm volatile ("" : "=a"(a) :: "eax")
generates an "impossible constraints" error.

If I have not convinced you to generate an error for the simultaneously use,
can I at least write a doc patch for this to help clarify things for users? 
Something that points out that there is no way to disable "cc" for i386, and
provides a sample for using @cc?

[Bug inline-asm/61692] ICE in extract_insn in recog.c for asm with many parameters

[gccbugzilla at limegreensocks dot com]

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

--- Comment #4 from David  ---
(In reply to m...@gcc.gnu.org from comment #3)
> This test case isn't portable.  If upped to 40 then it would be more
> portable.

What platform supports more than 30 operands?

As near as I can see, MAX_RECOG_OPERANDS always resolves to 30.  Testing the
difference between 30 and 31 is the edge case.  

So yeah, we could also try 40, but that seems like an arbitrary number.  Why
not 50?  150?

What am I missing here?

[Bug inline-asm/64681] gcc assign wrong register for arm inline assembly

[gccbugzilla at limegreensocks dot com]

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

David  changed:

   What|Removed |Added

 CC||gccbugzilla@limegreensocks.
   ||com

--- Comment #4 from David  ---
Until very recently, *none* of the modifiers were documented.  In the current
docs
(https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#i386Operandmodifiers),
only the i386 modifiers are doc'ed.

That said, you can always check out the gcc source.  For example:

The comments above output_asm_insn in
https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/final.c?view=co&content-type=text%2Fplain
describe some global modifiers.

For i386-specific modifiers, look above ix86_print_operand in
https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/config/i386/i386.c?view=co&content-type=text%2Fplain

For arm, look above arm_print_operand in
https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/config/arm/arm.c?view=co&content-type=text%2Fplain

Presumably there are similar sections for other configs.

[Bug target/62109] __gthr_i486_lock_cmp_xchg missing clobber

[gccbugzilla at limegreensocks dot com]

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

--- Comment #2 from David  ---
Attaching a patch was just the clearest way I knew to show the problem.

My hope was that posting it here would allow someone who knew how to submit
patches to take this the rest of the way.

[Bug inline-asm/61692] ICE in extract_insn in recog.c for asm with many parameters

[gccbugzilla at limegreensocks dot com]

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

David  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from David  ---
Patch solves problem.

[Bug inline-asm/61740] Fixes for minor problems in asm_fprintf and output_asm_insn

[gccbugzilla at limegreensocks dot com]

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

David  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from David  ---
Too much in one bug.  I'll open separate bugs for the parts that are still
interesting.

[Bug inline-asm/63900] New: memory constrains needlessly doing memory clobber

[gccbugzilla at limegreensocks dot com]

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

Bug ID: 63900
   Summary: memory constrains needlessly doing memory clobber
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gccbugzilla at limegreensocks dot com

Using a constraint like this:

   "=m" ( *(struct { char __x[BUFSIZE]; } *)b)

only works for very specific sizes of BUFSIZE (1, 2, 4, 8, 16).  All other
sizes (3, 12, 1000, etc) cause gcc to (silently) fall back to doing a full
memory clobber.

-
#include 

#define MYSIZE 8

inline void 
__stosb(unsigned char *Dest, unsigned char Data, size_t Count)
{
   struct _reallybigstruct { char x[MYSIZE]; } 
  *p = (struct _reallybigstruct *)Dest;

   __asm__ __volatile__ ("rep stosb"
  : "+D" (Dest), "+c" (Count), "=m" (*p)
  : [Data] "a" (Data)
  //: "memory"
   );
}

int main()
{
   unsigned char buff[100], buff2[100];

   buff[5] = 'A';
   buff2[5] = 'M';
   asm("#" : : "r" (buff2));

   __stosb(buff, 'B', sizeof(buff));
   printf("%c %c\n", buff[5], buff2[5]);
}
-

Compile this (4.9.0 x86_64-win32-seh-rev2, using -m64 -O2) with MYSIZE 8 and
look at the -S output.  If this is NOT doing a full clobber, gcc should be able
to just print buff2[5] by moving 77 into r8d before calling printf (which it
does).

Change MYSIZE to 3 (or 12, 1000, 0xfff, etc) we see the value getting read
from memory before calling printf, indicating the asm performed a full clobber
(affecting buff2) instead of just clobbering buff as was intended.

[Bug inline-asm/63900] memory constrains needlessly doing memory clobber

[gccbugzilla at limegreensocks dot com]

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

--- Comment #5 from David  ---
I agree that the benefit for 3 bytes isn't going to be a big win.  And
certainly this sample, created from scratch solely to illustrate the problem,
can be better written.  

For a more real-world sample, how about something like this:

   "=m" ( *(struct { char __x[0xfff]; } *)__dest)

This code is from glib's __strcpy_g() (I believe the linux kernel also uses
this technique).  The intent here appears to be to tell gcc "flush all of
__dest, even though I don't actually know how big it is."  If only very
specific sizes can be used in memory constraints, rather than avoiding the
memory clobber, they are actually still causing one, just implicitly.

And worse, it is entirely possible that the compiler doesn't have *any* of
__dest in registers.  In that case, performing a "memory" clobber (either
explicitly or implicitly) can be a big expense, that has zero gain.  But of
course there's no way the asm can know that.

I should probably also point out that using memory constraints to avoid a
clobber isn't something I just made up.  It has been in the docs since at least
3.3.6.

The "memory" clobber is an essential tool in a number of cases, but it is a
blunt one.  Being able to inform gcc exactly what you need flushed can't help
but result in better code.  The fact that it does work (albeit in highly
limited circumstances) is what makes me hope it can work more generally.

[Bug libgcc/61662] New: Incorrect value calculated for _lrotl on LLP64 systems

[gccbugzilla at limegreensocks dot com]

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

Bug ID: 61662
   Summary: Incorrect value calculated for _lrotl on LLP64 systems
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gccbugzilla at limegreensocks dot com

Created attachment 33037
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33037&action=edit
Proposed patch

There is a problem in ia32intrin.h.  Extracting bits of the code to highlight
the problem, we get:

#ifdef __x86_64__
#define _lrotl(a,b)__rolq((a), (b)) // rotate left qword
#else
#define _lrotl(a,b)__rold((a), (b)) // rotate left dword
#endif

This works correctly for linux, since on linux, longs use 8 bytes on 64bit and
4 bytes on 32bit (aka LP64).  However, in native Windows, longs are 4 bytes for
both (aka LLP64).  

So on 64bit Windows, 4 byte longs get promoted to a qword, bits get rotated
into the upper bytes, then get truncated when cast back into a 4 byte long. 
Oops.

The problem here is that using "#ifdef __x86_64__" to determine the size of a
long does not reliably yield the correct result.

While gcc provides a define named __SIZEOF_LONG__, it doesn't seem like this is
used very often outside of the testsuite.  Therefore the proposed patch
(attached) uses the __LP64__ define.

Testcase:

   printf("sizeof(long): %d sizeof(ptr): %d "
  "_lrotl(0x8000,1): 0x%lx _lrotr(1,1): 0x%lx\n", 
  sizeof(long), sizeof(void *), _lrotl(0x8000, 1), _lrotr(1,1));

64bit Windows yields:

sizeof(long): 4 sizeof(ptr): 8 _lrotl(0x8000,1): 0x0 _lrotr(1,1): 0x0

Applying the patch yields:

sizeof(long): 4 sizeof(ptr): 8 _lrotl(0x8000,1): 0x1 _lrotr(1,1):
0x8000

[Bug inline-asm/61692] New: ICE in extract_insn in recog.c for asm with many parameters

[gccbugzilla at limegreensocks dot com]

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

Bug ID: 61692
   Summary: ICE in extract_insn in recog.c for asm with many
parameters
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gccbugzilla at limegreensocks dot com

There is an ICE coming from recog.c in extract_insn.  The problem occurs when
you have 30 inputs and 1 goto in an asm instruction.  That's 31 operands and
MAX_RECOG_OPERANDS only allows 30.

The problem comes from this line in expand_asm_operands in cfgexpand.c:

  if (ninputs + noutputs > MAX_RECOG_OPERANDS)

Changing that to:

  if (ninputs + noutputs + nlabels > MAX_RECOG_OPERANDS)

generates the (expected) message:

  error: more than 30 operands in 'asm'

You can see the ICE with this code:

int main()
{
loop:

   asm goto (""
  : /* no outputs */
  : "r" (0), "r" (1), "r" (2), "r" (3), "r" (4), 
"r" (5), "r" (6), "r" (7), "r" (8), "r" (9), 
"r" (10), "r" (11), "r" (12), "r" (13), "r" (14), 
"r" (15), "r" (16), "r" (17), "r" (18), "r" (19),
"r" (20), "r" (21), "r" (22), "r" (23), "r" (24), 
"r" (25), "r" (26), "r" (27), "r" (28), "r" (29)
  : /* no clobbers */
  : loop);
}

[Bug inline-asm/61740] New: Fixes for minor problems in asm_fprintf and output_asm_insn

[gccbugzilla at limegreensocks dot com]

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

Bug ID: 61740
   Summary: Fixes for minor problems in asm_fprintf and
output_asm_insn
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gccbugzilla at limegreensocks dot com

Created attachment 33087
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33087&action=edit
Proposed patch

The attached patch fixes 4 inline asm issues in asm_fprintf and
output_asm_insn.  They vary in importance from minor to trivial.

1) Compiling this inline asm statement (correctly) reports "unterminated
assembly dialect alternative":

asm("{" :);

But this one does not:

asm("{stuff" :);

This patch reports all unterminated dialects (for both att & intel) in both
output_asm_insn & asm_fprintf:

  asm("{" :);
  asm("{nop" :);

  asm("{|" :);
  asm("{nop|" :);
  asm("{nop|nop" :);

  asm("{||" :);
  asm("{nop||" :);
  asm("{nop|nop|" :);
  asm("{nop||nop" :);
  asm("{nop|nop|nop" :);

2) In r198641, output_asm_insn was modified to add support for escaping the
dialect characters: {|}.  This feature was not added to asm_fprintf (which also
supports dialects).  This patch updates asm_fprintf to support escaping dialect
characters, so that it truly will "handle alternate assembler dialects here,
just like output_asm_insn."

3) There are two format strings (%@ %r) defined for asm_fprintf in c-format.c
that are only available for arm.  Any attempt to use them from other platforms
results in an ICE.  Since the entire purpose of these tables is to validate
format strings, these entries should only be defined when building arm.

While I could have simply wrapped the offending table entries in an #ifdef
__arm__, that does not appear to be consistent with the standard used by the
rest of gcc.  Following the example of the related macro
(ASM_FPRINTF_EXTENSIONS), I created a macro named ASM_FPRINTF_TABLE that can be
created on a per-platform basis to define platform-specific formats.  Like
ASM_FPRINTF_EXTENSIONS, this is (currently) only implemented on arm.

4) asm_fprintf uses a fixed size buffer (buf[10]) that it copies data into, but
it never checks to see if it is overrunning the buffer.  While 10 bytes is
almost certainly sufficient for most valid uses, not checking at all seems bad.
 There are legal (if unlikely) printf modifiers that require more than 10
bytes.  Rather than depend upon people to not violate this restriction, this
patch performs a simple check for overruns.

An 11 byte example: asm_fprintf(asm_out_file, "%-160.140x", 12);

[Bug target/61662] Incorrect value calculated for _lrotl on LLP64 systems

[gccbugzilla at limegreensocks dot com]

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

--- Comment #2 from David  ---
Sent July 9, 2014: https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00604.html

[Bug target/62109] New: __gthr_i486_lock_cmp_xchg missing clobber

[gccbugzilla at limegreensocks dot com]

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

Bug ID: 62109
   Summary: __gthr_i486_lock_cmp_xchg missing clobber
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gccbugzilla at limegreensocks dot com

Created attachment 33302
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33302&action=edit
Update __gthr_i486_lock_cmp_xchg to add memory clobber

InterlockedCompareExchange is an implicit memory barrier.  Such being the case,
the asm needs to use the "memory" clobber.

[Bug other/68610] New: configure failure in libssp

[gccbugzilla at limegreensocks dot com]

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

Bug ID: 68610
   Summary: configure failure in libssp
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gccbugzilla at limegreensocks dot com
  Target Milestone: ---

I was trying to figure out why I was getting this warning from ssp.c in libssp
when building gcc on i386:

  warning: visibility attribute not supported in this configuration; ignored

Configure checks to see if this attribute is supported and sets a #define, so I
was puzzled why that wasn't working.  After looking thru the configure script,
it appears that the configure check is failing because compiling the test code
throws a 'warning' instead of an error:

  conftest.c:12:1: warning: visibility attribute not supported in this
configuration; ignored [-Wattributes]

And the reason it does seems to be that ac_c_werror_flag is assumed to contain
the switch to turn the warning into an error (-Werror), when in fact it is
undefined.  Setting this to -Werror causes the configure check to correctly
detect that visibility isn't supported, and the warning from ssp.c disappears.

A lot of gcc's configure scripts use ac_c_werror_flag, but I'm not sure it ever
gets set to -Werror.  Sometimes it gets set to "yes", but that can't be right.

[Bug inline-asm/68843] ICE with "u" input constraint

[gccbugzilla at limegreensocks dot com]

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

David  changed:

   What|Removed |Added

 CC||gccbugzilla@limegreensocks.
   ||com

--- Comment #3 from David  ---
(In reply to Uroš Bizjak from comment #1)
> There are several non-intuitive rules that one has to follow to avoid ICEs
> with x87 asm operands.

Someone else was just complaining about the doc example for using floating
point (https://gcc.gnu.org/ml/gcc-help/2015-10/msg00088.html).  If there is no
practical way to make this work, perhaps the docs should reflect this? 
Alternately, perhaps a couple examples that show the right way?

[Bug inline-asm/68843] ICE with "u" input constraint

[gccbugzilla at limegreensocks dot com]

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

--- Comment #7 from David  ---
Would a doc patch be appropriate too?

[Bug inline-asm/49611] Inline asm should support input/output of flags

[gccbugzilla at limegreensocks dot com]

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

--- Comment #10 from David  ---
There was some discussion of this on the gcc mailing list.  Not sure what
became of it: https://gcc.gnu.org/ml/gcc/2015-05/msg6.html

[Bug inline-asm/49611] Inline asm should support input/output of flags

[gccbugzilla at limegreensocks dot com]

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

--- Comment #11 from David  ---
Apparently this feature has been checked in:
https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#FlagOutputOperands

[Bug inline-asm/49611] Inline asm should support input/output of flags

[gccbugzilla at limegreensocks dot com]

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

--- Comment #14 from David  ---
(In reply to Jeremy from comment #12)

> It probably does a setcc on x86 which doesn't really gain much

I don't have a 6.0 build to test with yet, but I don't believe that's quite
correct.  Looking at the testsuite that got checked in with it, we see both:

asm-flag-2.c:
/* { dg-final { scan-assembler "seta" } } */

asm-flag-3.c:
/* { dg-final { scan-assembler "ja" } } */

[Bug inline-asm/49611] Inline asm should support input/output of flags

[gccbugzilla at limegreensocks dot com]

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

--- Comment #16 from David  ---
I've tried it now and it seems to do good things.  This code:

int main(int argc, char *argv[])
{
   char x;

   asm("setc" : "=@ccc"(x));

   if (!x)
  return 6;
   else
  return argc;
}

produces this output (-O3):

movl$6, %eax
/APP
 # 6 "./r.cpp" 1
setc
 # 0 "" 2
/NO_APP
cmovc   %ebx, %eax
addq$32, %rsp
popq%rbx
ret

Although a minor variation (change "return argc" to "return 7") ends up doing
setc+cmpb, so it's not a perfect solution.

Still, if I were Richard, I'd be closing this bug.  If someone has optimization
issues with his solution, that's a new bug.

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

[gccbugzilla at limegreensocks dot com]

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

--- Comment #8 from David  ---
I doubt this patch is ever going anywhere.  Now that v6 has shipped, producing
an error for both using and clobbering flags would "break backward
compatibility."  On the plus side it would probably have caught your ice.  You
may want to file the ice as a separate bug.

Is there a bug for the !cc clobber thing?  I'd like to see that.