[Bug c/28583] New: ICE in default_secondary_reload, at targhooks.c:532 when building libgcc2.c as _divsc3.o

[dhowells at redhat dot com]

I've come across the following whilst trying to build a gcc cross-compiler:

/warthog/frv/gcc/build/./gcc/xgcc -B/warthog/frv/gcc/build/./gcc/
-B/opt/frv-4.1/frv-linux-gnu/bin/ -B/opt/frv-4.1/frv-linux-gnu/lib/ -isystem
/opt/frv-4.1/frv-linux-gnu/include -isystem
/opt/frv-4.1/frv-linux-gnu/sys-include -O2  -O2 -g -O2  -DIN_GCC
-DCROSS_COMPILE   -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition  -isystem ./include  -fPIC -g
-DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I.
-I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include
-I../../gcc/gcc/../libcpp/include  -I../../gcc/gcc/../libdecnumber
-I../libdecnumber -DL_divsc3 -fvisibility=hidden -DHIDE_EXPORTS -c
../../gcc/gcc/libgcc2.c -o libgcc/./_divsc3.o
../../gcc/gcc/libgcc2.c: In function ‘__divsc3’:
../../gcc/gcc/libgcc2.c:1910: internal compiler error: in
default_secondary_reload, at targhooks.c:532

The compiler sources were pulled by Subversion from the gcc repository:

Path: .
URL: svn://gcc.gnu.org/svn/gcc/trunk
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 115899
Node Kind: directory
Schedule: normal
Last Changed Author: schwab
Last Changed Rev: 115899
Last Changed Date: 2006-08-03 10:28:37 +0100 (Thu, 03 Aug 2006)
Properties Last Updated: 2006-08-01 21:01:27 +0100 (Tue, 01 Aug 2006)

The binutils tools being used were:

warthog>./as --version
GNU assembler 2.14-frv-060512-1 20031112

And the tools necessary for the compiler can be obtained from:

http://people.redhat.com/~dhowells/frv/as
http://people.redhat.com/~dhowells/frv/ld
http://people.redhat.com/~dhowells/frv/ar
http://people.redhat.com/~dhowells/frv/ranlib
http://people.redhat.com/~dhowells/frv/nm
http://people.redhat.com/~dhowells/frv/objdump
http://people.redhat.com/~dhowells/frv/strip

Or in a huge tarball with lots of other stuff from:

ftp://ftp.ges.redhat.com/private/releng/frv-060512-Fc6734/tools.tar.bz2

I've reproduced this problem compiling gcc on on an SMP i686 box and a UP
x86_64 box.  On both boxes the native compiler was installed from the
gcc-4.1.1-1.fc5 Fedora Core 5 RPMs:

warthog>gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre
--with-cpu=generic --host=x86_64-redhat-linux
Thread model: posix
gcc version 4.1.1 20060525 (Red Hat 4.1.1-1)
warthog255>ssh hades gcc -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre
--with-cpu=generic --host=i386-redhat-linux
Thread model: posix
gcc version 4.1.1 20060525 (Red Hat 4.1.1-1)


The partially built gcc claims its version to be:

warthog>./gcc/xgcc -v
Using built-in specs.
Target: frv-linux-gnu
Configured with: ../gcc/configure --target=frv-linux-gnu --prefix=/opt/frv-4.1
--enable-languages=c --with-build-time-tools=/opt/frv-4.1/frv-linux-gnu/bin/
--with-as=/opt/frv-4.1/frv-linux-gnu/bin/frv-linux-gnu-as
Thread model: posix
gcc version 4.2.0 20060803 (experimental)


I configured the package with the configuration line you can see above and
then just ran "make".


The intermediate compiler can be used to trigger the bug with following
command line:

./gcc/xgcc -B./gcc -O2  -c wibble.c -o wibble.o

from within the build directory.  wibble.c is the attached preprocessed and
stripped down version of libgcc2.c.

Note that adding:

#define __builtin_expect(X, Y) (X)

to the top of the file seems to make the problem go away.

David


-- 
   Summary: ICE in default_secondary_reload, at targhooks.c:532 when
building libgcc2.c as _divsc3.o
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
    ReportedBy: dhowells at redhat dot com
 GCC build triplet: x86_64-unknown-linux-gnu, i686-pc-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu, i686-pc-linux-gnu
GCC target triplet: frv-unknown-linux-gnu


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

[Bug c/28583] ICE in default_secondary_reload, at targhooks.c:532 when building libgcc2.c as _divsc3.o

[dhowells at redhat dot com]

--- Comment #1 from dhowells at redhat dot com  2006-08-03 13:38 ---
Created an attachment (id=12004)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12004&action=view)
Stripped down testcase for the bug

I get the error on line 92 of this source file:

warthog>./gcc/xgcc -B./gcc -O2  -c wibble.c -o wibble.o
wibble.c: In function ‘__divsc3’:
wibble.c:92: internal compiler error: in default_secondary_reload, at
targhooks.c:532
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.


-- 


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

[Bug tree-optimization/94527] New: RFE: Add an __attribute__ that marks a function as freeing an object

[dhowells at redhat dot com]

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

Bug ID: 94527
   Summary: RFE: Add an __attribute__ that marks a function as
freeing an object
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dhowells at redhat dot com
  Target Milestone: ---

Would it be possible to add a function attribute to indicate that the function
is going to destroy the object a the parameter points to (ie. a free()-like
function)?  Perhaps something like:

void free(const volatile void *ptr) __attribute__((free(1)));

where the free(N) attribute indicates the parameter number[*].

[*] Note that it's possible that a free()-like function might also take
additional parameters to provide context and that context won't be destroyed.

The compiler could then warn upon future access through the pointer.

[Bug tree-optimization/94527] RFE: Add an __attribute__ that marks a function as freeing an object

[dhowells at redhat dot com]

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

--- Comment #1 from dhowells at redhat dot com  ---
To quote Linus Torvalds,
https://lore.kernel.org/lkml/CAHk-=wg2Vsb0JETo24=tc-t2drwmopmrfknc__r5sz6tenb...@mail.gmail.com/

> Think of it this way: free() doesn't really change the data, it kills
> the lifetime of it. You can't access it afterwards - you can neither
> read it nor write it validly. That is a completely different - and
> independent - operation from writing to it.

Side note: I'd really love to be able to describe that operation, but
there's sadly no such extension.

So the _real_ prototype for 'free()'-like operations should be something like

void free(const volatile killed void *ptr);

where that "killed" also tells the compiler that the pointer lifetime
is dead, so that using it afterwards is invalid. So that the compiler
could warn us about some of the most trivial use-after-free cases.

Because we've had even those trivially stupid ones

Yes, obviously various analysis systems do exactly that kind of
analysis (and usually go much further), but then it's external things
like coverity etc.

The point being that the lifetime of an object is independent from
being able to write to an object, and the "const" in the "free()" is
not "I promise to not write to it", but "I can accept a constant
pointer".

We've had a number of places in the kernel where we do that kind of
"lifetime" marking explicitly by assigning a NULL (or invalid value)
to the pointer when we free it.

I have this dim memory of us even (long long long ago) trying to use a
#define kfree() ... to do that, but it turns out to be basically
impossible to get the proper "use once" semantics, so it doesn't work
if the argument to kfree() has side effects.

[Bug c/58073] New: Suboptimal optimisation of ((x & 0x70) == 0x00 && (x & 0x70) == 0x10 && (x & 0x70) == 0x20) on x86_64

[dhowells at redhat dot com]

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

Bug ID: 58073
   Summary: Suboptimal optimisation of ((x & 0x70) == 0x00 && (x &
0x70) == 0x10 && (x & 0x70) == 0x20) on x86_64
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
      Reporter: dhowells at redhat dot com

Created attachment 30605
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30605&action=edit
Demonstration source code

When the attached demo code is compiled with gcc-4.8.1, two of the cases
optimise fine and the third case is optimised suboptimally - probably because
it initially matches the optimisation for the second case.

Going through the cases individually for 'shift' being 4:

 (1) return (mask(d) == (0x0 << shift));

This is rendered as a single TEST instruction in x86_64 asm:

   0:   f6 07 70testb  $0x70,(%rdi)
   3:   0f 94 c0sete   %al
   6:   c3  retq   

which is good.

 (2) return (mask(d) == (0x0 << shift) ||
mask(d) == (0x1 << shift));

This is also rendered as a single TEST instruction:

  10:   f6 07 60testb  $0x60,(%rdi)
  13:   0f 94 c0sete   %al
  16:   c3  retq   

which is again good.  The problem comes with the third case:

 (3) return (mask(d) == (0x0 << shift) ||
   mask(d) == (0x1 << shift) ||
   mask(d) == (0x2 << shift));

This is rendered as:

  20:   8b 17   mov(%rdi),%edx
  22:   b8 01 00 00 00  mov$0x1,%eax
  27:   f6 c2 60test   $0x60,%dl
  2a:   74 09   je 35 
  2c:   83 e2 70and$0x70,%edx
  2f:   83 fa 20cmp$0x20,%edx
  32:   0f 94 c0sete   %al
  35:   f3 c3   repz retq 

which is odd.  I would expect the thing to be turned into MOV, AND, CMP, SETE,
RETQ since the numbers it is checking for lie adjacent to each other, starting
from zero.

I think what has happened is that the first two comparisons matched the
optimisation for case (2) - resulting in three extra instructions.

The compilation command line was:

gcc -O2 -c foo.c -Wall && objdump -d foo.o

The compiler version:

Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.1/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin
--enable-initfini-array --enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-isl=/builddir/build/BUILD/gcc-4.8.1-20130603/obj-x86_64-redhat-linux/isl-install
--with-cloog=/builddir/build/BUILD/gcc-4.8.1-20130603/obj-x86_64-redhat-linux/cloog-install
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.8.1 20130603 (Red Hat 4.8.1-1) (GCC) 

as supplied by Fedora: gcc-4.8.1-1.fc19.x86_64

[Bug c/58073] Suboptimal optimisation of ((x & 0x70) == 0x00 && (x & 0x70) == 0x10 && (x & 0x70) == 0x20) on x86_64

[dhowells at redhat dot com]

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

--- Comment #1 from dhowells at redhat dot com  ---
Interestingly, the suboptimality shifts if the 'shift' value in the demo
program is changed to 0:

Going through the cases individually::

 (1) return (mask(d) == (0x0 << shift));

This is rendered as a single TEST instruction in x86_64 asm:

   0:   f6 07 07testb  $0x7,(%rdi)
   3:   0f 94 c0sete   %al
   6:   c3  retq   

which is fine.

 (2) return (mask(d) == (0x0 << shift) ||
mask(d) == (0x1 << shift));

is rendered as:

  10:   8b 07   mov(%rdi),%eax
  12:   83 e0 07and$0x7,%eax
  15:   83 f8 01cmp$0x1,%eax
  18:   0f 96 c0setbe  %al
  1b:   c3  retq   

which is not what I'd expect.  What happened to the single TEST instruction
that was produced for shift = 4?

And then:

 (3) return (mask(d) == (0x0 << shift) ||
   mask(d) == (0x1 << shift) ||
   mask(d) == (0x2 << shift));

which is rendered as:

  20:   8b 07   mov(%rdi),%eax
  22:   83 e0 07and$0x7,%eax
  25:   83 f8 02cmp$0x2,%eax
  28:   0f 96 c0setbe  %al
  2b:   c3  retq   

which is good (and which is similar to what I'd've expected case 3 to generate
when shift = 4).

[Bug target/52971] gcc ICE with an sh64 cross-compilation

[dhowells at redhat dot com]

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

dhowe...@redhat.com  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #2 from dhowells at redhat dot com  
2012-06-01 13:31:06 UTC ---
Those fix it for me.

[Bug c/52971] New: gcc ICE with an sh64 cross-compilation

[dhowells at redhat dot com]

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

 Bug #: 52971
   Summary: gcc ICE with an sh64 cross-compilation
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dhowe...@redhat.com


Created attachment 27149
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27149
ICE producer

I have built a cross-compiler toolchain for sh64 that can also compile for
32-bit SH.  All the 32-bit Linux kernel SH defconfigs that I've fed it have
worked, but the primary 64-bit SH defconfig fails with a gcc SEGV/ICE on at
least one of the files.

I've distilled the C code that produced the ICE down to a few lines (see
attachment).  This is compiled with:

sh64-linux-gnu-gcc -m5-32media-nofpu -ml -Wa,-isa=shmedia -O2 -c ice.c
ice.c: In function ‘part_pack_uuid’:
ice.c:8:3: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

The gcc build was configured with:

AR_FOR_TARGET=/usr/bin/sh64-linux-gnu-ar \
AS_FOR_TARGET=/usr/bin/sh64-linux-gnu-as \
DLLTOOL_FOR_TARGET=/usr/bin/sh64-linux-gnu-dlltool \
LD_FOR_TARGET=/usr/bin/sh64-linux-gnu-ld \
NM_FOR_TARGET=/usr/bin/sh64-linux-gnu-nm \
OBJDUMP_FOR_TARGET=/usr/bin/sh64-linux-gnu-objdump \
RANLIB_FOR_TARGET=/usr/bin/sh64-linux-gnu-ranlib \
STRIP_FOR_TARGET=/usr/bin/sh64-linux-gnu-strip \
WINDRES_FOR_TARGET=/usr/bin/sh64-linux-gnu-windres \
WINDMC_FOR_TARGET=/usr/bin/sh64-linux-gnu-windmc \
LDFLAGS='-Wl,-z,relro ' \
../gcc-4.7.0-RC-20120302/configure --disable-dependency-tracking
--disable-silent-rules --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin
--sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share
--includedir=/usr/include --libexecdir=/usr/libexec --localstatedir=/var
--sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info
--build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu
--target=sh64-linux --enable-targets=all --program-prefix=sh64-linux-gnu-
--enable-languages=c --without-headers --enable-sjlj-exceptions
--with-system-libunwind --disable-nls --disable-threads --disable-shared
--disable-libmudflap --disable-libssp --disable-libgomp --disable-libquadmath
--disable-gold --disable-decimal-float --enable-checking=
--enable-gnu-unique-object --enable-linker-build-id --disable-plugin
--enable-nls --with-system-zlib
--with-bugurl=http://bugzilla.redhat.com/bugzilla/ --enable-obsolete
--with-multilib-list=m1,m2,m2e,m4,m4-single,m4-single-only,m2a,m2a-single,m5-32media,m5-32media-nofpu,m5-compact,m5-compact-nofpu,m5-64media,m5-64media-nofpu

From gcc-4.7.0-RC-20120302.tar.bz2 downloaded from the gcc website.

The binutils used was binutils-2.22.52.0.1.tar.bz2 with the patches from the
Fedora rawhide binutils srpm applied.  This was configured thusly:

LDFLAGS='-Wl,-z,relro ' \
../binutils-2.22.52.0.1/configure --disable-dependency-tracking
--disable-silent-rules --enable-checking --prefix=/usr --exec-prefix=/usr
--bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share
--includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec
--localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man
--infodir=/usr/share/info --build=x86_64-redhat-linux-gnu
--host=x86_64-redhat-linux-gnu --target=sh64-elf
--program-prefix=sh64-linux-gnu- --disable-shared --enable-64-bit-bfd
--enable-targets=sh64-linux,sh-elf,sh-linux,sh4-linux
--with-bugurl=http://bugzilla.redhat.com/bugzilla/

And a symlink emplaced at /usr/sh64-linux to point to the /usr/sh64-elf/
directory  so that the cross-compiler could find it.

For reference, the cross-gcc and cross-binutils are built as RPMs for Fedora
using spec files or SRPMs similar to those that can be found in
http://people.redhat.com/~dhowells/cross/

[Bug c++/51445] New: g++ sometimes miscompiles code for the avr target

[dhowells at redhat dot com]

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

 Bug #: 51445
   Summary: g++ sometimes miscompiles code for the avr target
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dhowe...@redhat.com


Created attachment 26013
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26013
Test data: Reduced version of w5100.cpp

I'm trying to build stuff for my Arduino board, but the compiler occasionally
clobbers the return value of a function it just called.  This is notable in the
Arduino Ethernet library where the interactions with the W5100 chipset go
interestingly wrong.

Someone pointed me at a fix they'd come up with:

http://code.google.com/p/arduino/issues/detail?id=605&start=200

whereby they observe the results of two 8-bit function calls are not being
correctly assembled into a 16-bit result in the following code:

...
static uint16_t read##name(SOCKET _s) {  \
uint16_t res = readSn(_s, address);  \
res = (res << 8) + readSn(_s, address + 1);  \
return res;  \
}

However, replacing the above with:

...
static uint16_t read##name(SOCKET _s) {  \
uint16_t res = readSn(_s, address);  \
uint16_t res2 = readSn(_s,address + 1);  \
res = res << 8;  \
res2 = res2 & 0xFF;  \
res = res | res2;\
return res;  \
}

Works.  I have also fallen foul of this problem.  They used 4.5.1 of their gcc,
I'm using 4.6.1:

Using built-in specs.
COLLECT_GCC=/usr/bin/avr-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/avr/4.6.1/lto-wrapper
Target: avr
Configured with: ../gcc-4.6.1/configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --target=avr --enable-languages=c,c++ --disable-nls
--disable-libssp --with-system-zlib --enable-version-specific-runtime-libs
--with-pkgversion='Fedora 4.6.1-3.fc16'
--with-bugurl=https://bugzilla.redhat.com/
Thread model: single
gcc version 4.6.1 (Fedora 4.6.1-3.fc16) 

obtained by download from the Fedora 16 yum repository.  The associated
binutils is:

avr-binutils-2.20-2.fc16.x86_64

I've had a colleague build my testcase on a Debian system using the binary
packages available there and the resulting binary from that misbehaves in the
same way as building on Fedora.

Compiling the attached testcase file with the following command:

avr-gcc -g -Os -w -mmcu=atmega328p -ffunction-sections -fdata-sections -o tmp.o
-c tmp.cpp

and then disassembling the resulting object file:

avr-objdump -C -d tmp.o | less

I see that the W5100Class::send_data_processing() method incorrectly clobbers
the result of the first call to W5100Class::readSn() as made by
W5100::readSnTX_WR():

  26:   0e 94 00 00 call0   ; 0x0

  2a:   81 2f   mov r24, r17
  2c:   65 e2   ldi r22, 0x25   ; 37
  2e:   70 e0   ldi r23, 0x00   ; 0
  30:   0e 94 00 00 call0   ; 0x0


The problem, if I understand the calling convention correctly, is that the
function returns its result in R24 - but this is being clobbered by the very
next instruction which overwrites it with the contents of R17 (the destination
register is supposed to be on the left).

I can't seem to remove much else from the test case without the problem going
away (snip off the implementation of W5100Class::execCmdSn() for example).

Also, there's a #if in testcase.  Flip the condition from 1 to 0 and the
resulting code is markedly different:

  24:   0e 94 00 00 call0   ; 0x0

  28:   e8 2e   mov r14, r24
  2a:   81 2f   mov r24, r17
  2c:   65 e2   ldi r22, 0x25   ; 37
  2e:   70 e0   ldi r23, 0x00   ; 0
  30:   0e 94 00 00 call0   ; 0x0


As can be seen, an extra line has appeared after the first CALL instruction,
saving the result of that call into R14 before copying R17 into R24.

[Bug target/51445] g++ sometimes miscompiles code for the avr target

[dhowells at redhat dot com]

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

dhowe...@redhat.com  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #1 from dhowells at redhat dot com  
2011-12-11 13:56:37 UTC ---
The problem appears to be fixed in gcc-4.6.2.

[Bug c++/87235] New: g++ doesn't implement sparse initialisation of arrays

[dhowells at redhat dot com]

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

Bug ID: 87235
   Summary: g++ doesn't implement sparse initialisation of arrays
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dhowells at redhat dot com
  Target Milestone: ---

Created attachment 44662
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44662&action=edit
Testcase

g++ doesn't implement simple sparse array initialisations, such as:

int a[] = {
[3] = 99,
[5] = 82,
};

This can be seen by compiling the attached program with "g++ -c x.cpp".

g++ produces lots of "sorry, unimplemented: non-trivial designated initializers
not supported" errors.

[Bug c++/87235] g++ doesn't implement sparse initialisation of arrays

[dhowells at redhat dot com]

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

--- Comment #1 from dhowells at redhat dot com  ---
g++ -v gives:

Using built-in specs.
COLLECT_GCC=/usr/bin/g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin
--enable-initfini-array --with-isl --enable-libmpx
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-gnu-indirect-function --enable-cet --with-tune=generic
--with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 8.1.1 20180712 (Red Hat 8.1.1-5) (GCC)

[Bug c++/84874] New: internal compiler error: in reshape_init_class, at cp/decl.c:5800

[dhowells at redhat dot com]

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

Bug ID: 84874
   Summary: internal compiler error: in reshape_init_class, at
cp/decl.c:5800
   Product: gcc
   Version: 7.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dhowells at redhat dot com
  Target Milestone: ---

Created attachment 43663
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43663&action=edit
Test case

I'm seeing the following ICE:

g++ -Wall ice.cpp
ice.cpp: In function ‘void sema_init(semaphore*)’:
ice.cpp:30:2: internal compiler error: in reshape_init_class, at cp/decl.c:5800
  };
  ^

I've attached the preprocessed dump.

I think the code should produce an error (as it does if compiled for C).

The compiler is the Fedora 27 compiler, gcc-7.3.1-5.fc27.x86_64.

[Bug target/55351] can't build libgcc for -m5-compact variant in SH64

[dhowells at redhat dot com]

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



--- Comment #2 from dhowells at redhat dot com  
2012-11-20 15:09:42 UTC ---

The first hunk of the patch that adds:



   MULTILIB_EXCEPTIONS = *m5-64media* *m5-64media-nofpu*



to gcc/config/sh/t-linux causes the sh-linux-gnu build to fail.  Commenting out

this line allows both sh- and sh64-linux-gnu to build.

[Bug target/69747] New: c6x cross-compiler fails with "Error: inconsistent uses of .cfi_sections"

[dhowells at redhat dot com]

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

Bug ID: 69747
   Summary: c6x cross-compiler fails with "Error: inconsistent
uses of .cfi_sections"
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dhowells at redhat dot com
  Target Milestone: ---

When building both gcc-5.3.1 and gcc-6 for c6x, the builds fail when
configuring libgcc with the following error:

/tmp/cc6wIVaX.s: Assembler messages:
/tmp/cc6wIVaX.s:12: Error: inconsistent uses of .cfi_sections

This can be tested in the build tree with:

   echo 'int main() { return 0; }' | ./gcc/xgcc -x c -c -g - -B ./gcc
-fexceptions

The gcc being built is the following:

%global DATE 20151207
%global SVNREV 231358
%global gcc_version 5.3.1

gcc is configured as follows:

CC=gcc \
CXX=g++ \
CFLAGS='-O2 -g -Wall -Wformat-security -fexceptions -fstack-protector-strong
--param=ssp-buffer-size=4 -grecord-gcc-switches
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -mtune=generic' \
CXXFLAGS=' -O2 -g -Wformat-security -fstack-protector-strong
--param=ssp-buffer-size=4 -grecord-gcc-switches
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -mtune=generic ' \
CFLAGS_FOR_TARGET='-g -O2 -Wall -fexceptions' \
AR_FOR_TARGET=/usr/bin/c6x-linux-gnu-ar \
AS_FOR_TARGET=/usr/bin/c6x-linux-gnu-as \
DLLTOOL_FOR_TARGET=/usr/bin/c6x-linux-gnu-dlltool \
LD_FOR_TARGET=/usr/bin/c6x-linux-gnu-ld \
NM_FOR_TARGET=/usr/bin/c6x-linux-gnu-nm \
OBJDUMP_FOR_TARGET=/usr/bin/c6x-linux-gnu-objdump \
RANLIB_FOR_TARGET=/usr/bin/c6x-linux-gnu-ranlib \
READELF_FOR_TARGET=/usr/bin/c6x-linux-gnu-readelf \
STRIP_FOR_TARGET=/usr/bin/c6x-linux-gnu-strip \
WINDRES_FOR_TARGET=/usr/bin/c6x-linux-gnu-windres \
WINDMC_FOR_TARGET=/usr/bin/c6x-linux-gnu-windmc \
LDFLAGS='-Wl,-z,relro ' \
../gcc-5.3.1-20151207/configure --bindir=/usr/bin
--build=x86_64-redhat-linux-gnu --datadir=/usr/share --disable-decimal-float
--disable-dependency-tracking --disable-gold --disable-libgcj --disable-libgomp
--disable-libmudflap --disable-libquadmath --disable-libssp
--disable-libunwind-exceptions --disable-shared --disable-silent-rules
--disable-sjlj-exceptions --disable-threads --with-ld=/usr/bin/c6x-linux-gnu-ld
--enable-__cxa_atexit --enable-checking=release --enable-gnu-indirect-function
--enable-gnu-unique-object --enable-initfini-array --enable-languages=c,c++
--enable-linker-build-id --enable-lto --enable-nls --enable-obsolete
--enable-plugin --enable-targets=all --exec-prefix=/usr
--host=x86_64-redhat-linux-gnu --includedir=/usr/include
--infodir=/usr/share/info --libexecdir=/usr/libexec --localstatedir=/var
--mandir=/usr/share/man --prefix=/usr --program-prefix=c6x-linux-gnu-
--sbindir=/usr/sbin --sharedstatedir=/var/lib --sysconfdir=/etc
--target=c6x-uclinux --with-bugurl=http://bugzilla.redhat.com/bugzilla/
--with-isl --with-linker-hash-style=gnu --with-newlib
--with-plugin-ld=/usr/bin/c6x-linux-gnu-ld
--with-sysroot=/usr/c6x-linux-gnu/sys-root --with-system-libunwind
--with-system-zlib --without-headers

The binutils is binutils-2.26 configured for the same target.

[Bug target/69747] c6x cross-compiler fails with "Error: inconsistent uses of .cfi_sections"

[dhowells at redhat dot com]

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

--- Comment #1 from dhowells at redhat dot com  ---
This gcc also fails:

%global DATE 20160205
%global SVNREV 233185
%global gcc_version 6.0.0

[Bug target/69750] New: ICE in sh64 targetted gcc-6

[dhowells at redhat dot com]

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

Bug ID: 69750
   Summary: ICE in sh64 targetted gcc-6
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dhowells at redhat dot com
  Target Milestone: ---

When cross-building gcc-6 for sh64, the builds fail when configuring libgcc
with an ICE.  This can be replicated by running the following command in the
build directory:

  echo 'int main() { return 0; }' | ./gcc/xgcc -x c -c -g - -B ./gcc
-fexceptions

The gcc being built is the following:

%global DATE 20160205
%global SVNREV 233185
%global gcc_version 6.0.0

gcc is configured as follows:

CC=gcc \
CXX=g++ \
CFLAGS='-O2 -g -Wall -Wformat-security -fexceptions -fstack-protector-strong
--param=ssp-buffer-size=4 -grecord-gcc-switches -mtune=generic' \
+echo ' -O2 -g -Wall -Wformat-security -fexceptions -fstack-protector-strong
--param=ssp-buffer-size=4 -grecord-gcc-switches -mtune=generic ' \
+sed 's/ -Wall / /g;s/ -fexceptions / /g' \
+sed 's/ -Werror=format-security / -Wformat -Werror=format-security /' \
CXXFLAGS=' -O2 -g -Wformat-security -fstack-protector-strong
--param=ssp-buffer-size=4 -grecord-gcc-switches -mtune=generic ' \
CFLAGS_FOR_TARGET='-g -O2 -Wall -fexceptions' \
AR_FOR_TARGET=/usr/bin/sh64-linux-gnu-ar \
AS_FOR_TARGET=/usr/bin/sh64-linux-gnu-as \
DLLTOOL_FOR_TARGET=/usr/bin/sh64-linux-gnu-dlltool \
LD_FOR_TARGET=/usr/bin/sh64-linux-gnu-ld \
NM_FOR_TARGET=/usr/bin/sh64-linux-gnu-nm \
OBJDUMP_FOR_TARGET=/usr/bin/sh64-linux-gnu-objdump \
RANLIB_FOR_TARGET=/usr/bin/sh64-linux-gnu-ranlib \
READELF_FOR_TARGET=/usr/bin/sh64-linux-gnu-readelf \
STRIP_FOR_TARGET=/usr/bin/sh64-linux-gnu-strip \
WINDRES_FOR_TARGET=/usr/bin/sh64-linux-gnu-windres \
WINDMC_FOR_TARGET=/usr/bin/sh64-linux-gnu-windmc \
LDFLAGS='-Wl,-z,relro ' \
../gcc-6.0.0-20160205/configure --bindir=/usr/bin
--build=x86_64-redhat-linux-gnu --datadir=/usr/share --disable-decimal-float
--disable-dependency-tracking --disable-gold --disable-libgcj --disable-libgomp
--disable-libmpx --disable-libquadmath --disable-libssp
--disable-libunwind-exceptions --disable-shared --disable-silent-rules
--disable-sjlj-exceptions --disable-threads
--with-ld=/usr/bin/sh64-linux-gnu-ld --enable-__cxa_atexit
--enable-checking=release --enable-gnu-unique-object --enable-initfini-array
--enable-languages=c,c+--enable-linker-build-id --enable-lto --enable-nls
--enable-obsolete --enable-plugin --enable-targets=all --exec-prefix=/usr
--host=x86_64-redhat-linux-gnu --includedir=/usr/include
--infodir=/usr/share/info --libexecdir=/usr/libexec --localstatedir=/var
--mandir=/usr/share/man --prefix=/usr --program-prefix=sh64-linux-gnu-
--sbindir=/usr/sbin --sharedstatedir=/var/lib --sysconfdir=/etc
--target=sh64-linux-elf --with-bugurl=http://bugzilla.redhat.com/bugzilla/
--with-isl --with-linker-hash-style=gnu --with-newlib
--with-plugin-ld=/usr/bin/sh64-linux-gnu-ld
--with-sysroot=/usr/sh64-linux-gnu/sys-root --with-system-libunwind
--with-system-zlib --without-headers
--with-multilib-list=m5-32media,m5-32media-nofpu,m5-compact,m5-compact-nofpu,m5-64media,m5-64media-nofpu

The binutils is binutils-2.26 configured for the same target.

[Bug target/69750] ICE in sh64 targetted gcc-6

[dhowells at redhat dot com]

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

--- Comment #1 from dhowells at redhat dot com  ---
Doing gdb ./gcc/cc1 and running it with:

r -quiet foo.c -g -fexceptions -o /tmp/cc5gm5ki.s 

shows the failure as:

Program received signal SIGSEGV, Segmentation fault.
_IO_vfprintf_internal (s=s@entry=0x7bfff4e0, 
format=format@entry=0xea2d7b "*%s%s%ld", ap=ap@entry=0x7bfff608)
at vfprintf.c:1311
1311  f = lead_str_end = __find_specmb ((const UCHAR_T *) format);


Asking for a backtrace gives at least 6000 entries, starting like this:

#0  _IO_vfprintf_internal (s=s@entry=0x7bfff4e0, 
format=format@entry=0xea2d7b "*%s%s%ld", ap=ap@entry=0x7bfff608)
at vfprintf.c:1311
#1  0x766e488b in __IO_vsprintf (string=0x7bfff7b0 "\004", 
format=0xea2d7b "*%s%s%ld", args=args@entry=0x7bfff608)
at iovsprintf.c:42
#2  0x766c7e57 in __sprintf (s=s@entry=0x7bfff7b0 "\004", 
format=format@entry=0xea2d7b "*%s%s%ld") at sprintf.c:32
#3  0x00b716f4 in force_const_mem (mode=mode@entry=SImode, 
x=x@entry=0x7fffea163e70) at ../../gcc-6.0.0-20160205/gcc/varasm.c:3732
#4  0x006cdc43 in emit_move_insn (x=x@entry=0x7fffea163eb8, 
y=y@entry=0x7fffea163e70) at ../../gcc-6.0.0-20160205/gcc/expr.c:3559
#5  0x006b3c70 in force_reg (mode=mode@entry=SImode, 
x=x@entry=0x7fffea163e70) at ../../gcc-6.0.0-20160205/gcc/explow.c:631
#6  0x006b490e in force_reg (x=0x7fffea163e70, mode=SImode)
at ../../gcc-6.0.0-20160205/gcc/explow.c:451
#7  memory_address_addr_space (mode=SImode, x=0x7fffea163e70, 
as=) at ../../gcc-6.0.0-20160205/gcc/explow.c:457
#8  0x006a0775 in change_address_1 (memref=0x7fffea163ea0, 
mode=SImode, mode@entry=VOIDmode, addr=0x7fffea163e70, 
validate=validate@entry=1, inplace=)
at ../../gcc-6.0.0-20160205/gcc/emit-rtl.c:2127
#9  0x006a3880 in replace_equiv_address (memref=, 
addr=, inplace=inplace@entry=true)
at ../../gcc-6.0.0-20160205/gcc/emit-rtl.c:2399
#10 0x006b467a in validize_mem (ref=, 
ref@entry=0x7fffea163ea0) at ../../gcc-6.0.0-20160205/gcc/explow.c:495

at this point, #4-#10 repeat:

#11 0x006cdbbb in emit_move_insn (x=x@entry=0x7fffea163e58, 
y=0x7fffea163ea0, y@entry=0x7fffea163e10)
at ../../gcc-6.0.0-20160205/gcc/expr.c:3582
#12 0x006b3c70 in force_reg (mode=mode@entry=SImode, 
x=x@entry=0x7fffea163e10) at ../../gcc-6.0.0-20160205/gcc/explow.c:631
#13 0x006b490e in force_reg (x=0x7fffea163e10, mode=SImode)
at ../../gcc-6.0.0-20160205/gcc/explow.c:451
#14 memory_address_addr_space (mode=SImode, x=0x7fffea163e10, 
as=) at ../../gcc-6.0.0-20160205/gcc/explow.c:457
#15 0x006a0775 in change_address_1 (memref=0x7fffea163e40, 
mode=SImode, mode@entry=VOIDmode, addr=0x7fffea163e10, 
validate=validate@entry=1, inplace=)
at ../../gcc-6.0.0-20160205/gcc/emit-rtl.c:2127
#16 0x006a3880 in replace_equiv_address (memref=, 
addr=, inplace=inplace@entry=true)
at ../../gcc-6.0.0-20160205/gcc/emit-rtl.c:2399

and repeat:

#17 0x006b467a in validize_mem (ref=, 
ref@entry=0x7fffea163e40) at ../../gcc-6.0.0-20160205/gcc/explow.c:495
#18 0x006cdbbb in emit_move_insn (x=x@entry=0x7fffea163df8, 
...

[Bug target/69747] c6x cross-compiler fails with "Error: inconsistent uses of .cfi_sections"

[dhowells at redhat dot com]

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

--- Comment #3 from dhowells at redhat dot com  ---
Hmmm...  It works with binutils-2.25, so it looks like it may be.

[Bug target/69747] c6x cross-compiler fails with "Error: inconsistent uses of .cfi_sections"

[dhowells at redhat dot com]

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

--- Comment #4 from dhowells at redhat dot com  ---
OTOH, looking at the output from gcc, I see:

...
.cfi_sections   .debug_frame
.align  2
.global main
.cfi_sections .debug_frame, .c6xabi.exidx
...

binutils-2.25 is okay with this.  If I add ", .c6xabi.exidx" to the end of the
first .cfi_sections directive, binutils-2.26 is okay also.  It may be that
binutils has got more strict and this is actually a gcc bug.

[Bug target/69747] c6x cross-compiler fails with "Error: inconsistent uses of .cfi_sections"

[dhowells at redhat dot com]

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

--- Comment #5 from dhowells at redhat dot com  ---
The consistency check in the binutils source code:

  if (cfi_sections_set && cfi_sections != sections)
as_bad (_("inconsistent uses of .cfi_sections"));

is added between 2.25 and 2.26 by commit:

commit 2f0c68f23bb3132cd5ac466ca8775c0d9e4960cd
Author: Catherine Moore 
Date:   Thu May 28 14:50:36 2015 -0700
Compact EH Support

so it looks like gcc is at fault.

[Bug rtl-optimization/69764] [5 Regression] ICE on x86_64-linux-gnu at -O0 (in decompose, at rtl.h:2107)

[dhowells at redhat dot com]

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

dhowells at redhat dot com  changed:

   What|Removed |Added

 CC||dhowells at redhat dot com

--- Comment #15 from dhowells at redhat dot com  ---
(In reply to Andreas Schwab from comment #7)
> ...
> In file included from ../../../libgcc/libgcc2.c:56:0:
> ../../../libgcc/libgcc2.c: In function ‘__mulvsi3’:
> ../../../libgcc/libgcc2.h:208:19: internal compiler error: in
> maybe_legitimize_operand, at optabs.c:6893
>  #define __NW(a,b) __ ## a ## si ## b
>^
> ../../../libgcc/libgcc2.h:299:19: note: in expansion of macro ‘__NW’
>  #define __mulvSI3 __NW(mulv,3)
>^~~~
> ../../../libgcc/libgcc2.c:152:1: note: in expansion of macro ‘__mulvSI3’
>  __mulvSI3 (Wtype a, Wtype b)
>  ^
> 0x9ab2ce maybe_legitimize_operand
> ../../gcc/optabs.c:6893
> ...

I'm seeing exactly this backtrace also building Fedora the cross-gcc-6 m68k
target, but the error goes away with the patch from bug 69885.

[Bug target/70821] New: x86_64: __atomic_fetch_add/sub() uses XADD rather than DECL in some cases

[dhowells at redhat dot com]

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

Bug ID: 70821
   Summary: x86_64: __atomic_fetch_add/sub() uses XADD rather than
DECL in some cases
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dhowells at redhat dot com
  Target Milestone: ---

Created attachment 38346
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38346&action=edit
Test program

__atomic_fetch_add/sub() uses XADD rather than DECL when subtracting 1 from the
counter if the result is acted upon, but where this could be done through the
condition flags.  For instance:

   static __always_inline bool atomic_sub_and_test(int i, atomic_t *v)
   {
  return __atomic_sub_fetch(&v->counter, i, __ATOMIC_SEQ_CST);
   }

   const char *test_atomic_dec_and_test(atomic_t *counter)
   {
  if (atomic_sub_and_test(1, counter))
 return "foo";
  return "bar";
   }

produces:

  17:   83 c8 ffor $0x,%eax
  1a:   f0 0f c1 07 lock xadd %eax,(%rdi)
  1e:   ba 00 00 00 00  mov$0x0,%edx
  23:   ff c8   dec%eax
  25:   b8 00 00 00 00  mov$0x0,%eax
  2a:   48 0f 44 c2 cmove  %rdx,%rax
  2e:   c3  retq   

when it should produce something more like this, which I get when adding 1
instead of subtracting 1, but with a DECL rather than an INCL:

  46:   f0 ff 07lock incl (%rdi)
  49:   ba 00 00 00 00  mov$0x0,%edx
  4e:   b8 00 00 00 00  mov$0x0,%eax
  53:   48 0f 44 c2 cmove  %rdx,%rax
  57:   c3  retq   

Note that adding or subtracting 2 and testing the zeroness of the result gives
SUBL/ADDL as expected.  If the result is not tested, DECL is generated as
expected:

  13:   f0 ff 0flock decl (%rdi)
  16:   c3  retq   

See the attached test program.

This is the case for both:

gcc version 5.3.1 20151207 (Red Hat 5.3.1-2) (GCC)
gcc version 6.0.0 20160219 (Red Hat Cross 6.0.0-0.1) (GCC)

The following version of gcc:

gcc version 4.8.5 20150623 (Red Hat 4.8.5-2.x) (GCC) 

also produces XADD rather than INCL/DECL/ADDL/SUBL if the result is looked at
at all.

[Bug target/70823] New: x86_64: __atomic_fetch_and/or/xor() should perhaps use BTR/BTS/BTC if they can

[dhowells at redhat dot com]

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

Bug ID: 70823
   Summary: x86_64: __atomic_fetch_and/or/xor() should perhaps use
BTR/BTS/BTC if they can
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dhowells at redhat dot com
  Target Milestone: ---

Created attachment 38347
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38347&action=edit
Test source

If given a mask that clears, sets or flips a single bit and the result is
checked for just that bit and reduced to bool, then the __atomic_fetch_and, _or
and _xor functions should consider using BTR, BTS or BTC as appropriate.

So, something like:

   static __always_inline bool test_and_set_bit(unsigned bit, unsigned long
*ptr)
   {
  unsigned long mask = 1UL << (bit & (BITS_PER_LONG - 1));
  unsigned long old;

  ptr += bit / BITS_PER_LONG;

  old = __atomic_fetch_or(ptr, mask, __ATOMIC_SEQ_CST);
  return old & mask;
   }

where the mask is constructed by 1UL << bitnr.  As things stand, for the
example above, the result ends up with a CMPXCHG loop rather a BTS instruction:

   b:   89 f9   mov%edi,%ecx
   d:   ba 01 00 00 00  mov$0x1,%edx
  12:   c1 ef 06shr$0x6,%edi
  15:   48 d3 e2shl%cl,%rdx
  18:   89 f9   mov%edi,%ecx
  1a:   48 8b 04 ce mov(%rsi,%rcx,8),%rax
  1e:   49 89 c0mov%rax,%r8
  21:   48 89 c7mov%rax,%rdi
  24:   49 09 d0or %rdx,%r8
  27:   f0 4c 0f b1 04 ce   lock cmpxchg %r8,(%rsi,%rcx,8)
  2d:   75 ef   jne1e 
  2f:   48 85 fatest   %rdi,%rdx
  32:   0f 95 c0setne  %al
  35:   c3  retq   

Could we instead get something like:

bts%edi,(%rsi)
setne  %al
retq

See the attached test source which should be compiled to a .s file.

This is the case for all of:

gcc version 5.3.1 20151207 (Red Hat 5.3.1-2) (GCC)
gcc version 6.0.0 20160219 (Red Hat Cross 6.0.0-0.1) (GCC)
gcc version 4.8.5 20150623 (Red Hat 4.8.5-2.x) (GCC)

[Bug target/70825] New: x86_64: __atomic_compare_exchange_n() accesses stack unnecessarily

[dhowells at redhat dot com]

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

Bug ID: 70825
   Summary: x86_64: __atomic_compare_exchange_n() accesses stack
unnecessarily
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dhowells at redhat dot com
  Target Milestone: ---

Created attachment 38349
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38349&action=edit
Example code

__atomic_compare_exchange_n() stores the 'expected' value and, if not
discarded, the old value on the stack rather than in a register and then may
immediately retrieve the old value from there back into the register from
whence it just came.

For example:

   static __always_inline int atomic_cmpxchg(atomic_t *v, int old, int new)
   {
  int cur = old;
  if (__atomic_compare_exchange_n(&v->counter, &cur, new, false,
  __ATOMIC_SEQ_CST,
  __ATOMIC_RELAXED))
 return cur;
  return cur;
   }

   void test_atomic_cmpxchg(atomic_t *counter)
   {
  atomic_cmpxchg(counter, 23, 42);
   }

produces:

   0:   ba 2a 00 00 00  mov$0x2a,%edx
   5:   b8 17 00 00 00  mov$0x17,%eax
   a:   c7 44 24 fc 17 00 00movl   $0x17,-0x4(%rsp)
  11:   00 
  12:   f0 0f b1 17 lock cmpxchg %edx,(%rdi)
  16:   c3  retq   

Note line a where 0x17 is stored at -04(%rsp) unnecessarily (the value is
dicarded).  Note also that this value is in %eax at the time and could be saved
from there rather than using an immediate operand.

And then:

   int test_atomic_cmpxchg_2(atomic_t *counter)
   {
  return atomic_cmpxchg(counter, 23, 42);
   }

where the value is returned, we get something like:

  20:   ba 2a 00 00 00  mov$0x2a,%edx
  25:   b8 17 00 00 00  mov$0x17,%eax
  2a:   c7 44 24 fc 17 00 00movl   $0x17,-0x4(%rsp)
  31:   00 
  32:   f0 0f b1 17 lock cmpxchg %edx,(%rdi)
  36:   74 04   je 3c 
  38:   89 44 24 fc mov%eax,-0x4(%rsp)
  3c:   8b 44 24 fc mov-0x4(%rsp),%eax
  40:   c3  retq   

In this case, the return value is being constructed on the stack whereas the
value we actually want to return is in %eax at the conclusion of the CMPXCHG,
so lines 2a & 36-3c are redundant.

Changing atomic_cmpxchg() slightly:

  static __always_inline int atomic_cmpxchg_B(atomic_t *v, int old, int new)
   {
  int cur = old;
  if (__atomic_compare_exchange_n(&v->counter, &cur, new, false,
  __ATOMIC_SEQ_CST,
  __ATOMIC_RELAXED))
-->  return old;
  return cur;
   }

does generate code that's somewhat better:

  a0:   ba 2a 00 00 00  mov$0x2a,%edx
  a5:   b8 17 00 00 00  mov$0x17,%eax
  aa:   c7 44 24 fc 17 00 00movl   $0x17,-0x4(%rsp)
  b1:   00 
  b2:   f0 0f b1 17 lock cmpxchg %edx,(%rdi)
  b6:   ba 17 00 00 00  mov$0x17,%edx
  bb:   0f 45 d0cmovne %eax,%edx
  be:   89 d0   mov%edx,%eax
  c0:   c3  retq   

However, given the fact that old == cur must hold true if the CMPXCHG
succeeded,  lines b6-be are redundant. Note that the unnecessary store (line
aa) is still there.

Note that clang does somewhat better than gcc:

  50:   b9 2a 00 00 00  mov$0x2a,%ecx
  55:   b8 17 00 00 00  mov$0x17,%eax
  5a:   f0 0f b1 0f lock cmpxchg %ecx,(%rdi)
  5e:   c3  retq   
  5f:   90  nop

See the attached example code which should be compiled to a .s file.

This is the case for all of:

gcc version 5.3.1 20151207 (Red Hat 5.3.1-2) (GCC)
gcc version 6.0.0 20160219 (Red Hat Cross 6.0.0-0.1) (GCC)
gcc version 4.8.5 20150623 (Red Hat 4.8.5-2.x) (GCC)

[Bug target/49244] __sync or __atomic builtins will not emit 'lock bts/btr/btc'

[dhowells at redhat dot com]

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

--- Comment #6 from dhowells at redhat dot com  ---
I'm looking to implement Linux kernel atomics with C++-11 intrinsics, so being
able to reduce a CMPXCHG-loop to BTR/BTS/BTC would be really handy.

[Bug target/70821] x86_64: __atomic_fetch_add/sub() uses XADD rather than DECL in some cases

[dhowells at redhat dot com]

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

--- Comment #3 from dhowells at redhat dot com  ---
Yes, I'm testing with -Os.

[Bug target/70821] x86_64: __atomic_fetch_add/sub() uses XADD rather than DECL in some cases

[dhowells at redhat dot com]

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

--- Comment #4 from dhowells at redhat dot com  ---
The patch works, thanks:

001c :
  1c:   f0 ff 0flock decl (%rdi)
  1f:   ba 00 00 00 00  mov$0x0,%edx
  24:   b8 00 00 00 00  mov$0x0,%eax
  29:   48 0f 44 c2 cmove  %rdx,%rax
  2d:   c3  retq

[Bug target/49244] __sync or __atomic builtins will not emit 'lock bts/btr/btc'

[dhowells at redhat dot com]

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

--- Comment #7 from dhowells at redhat dot com  ---
We should also be able to reduce:

bool
test_bit (int *a, int bit)
{
  uint mask = (1u << bit);

  return (__atomic_load_n (a, __ATOMIC_xxx) & mask) != 0;
}

to a BT instruction on x86.

[Bug target/49244] __sync or __atomic builtins will not emit 'lock bts/btr/btc'

[dhowells at redhat dot com]

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

--- Comment #9 from dhowells at redhat dot com  ---
> BTW: A low-hanging fruit in this area would be using new asm flags feature,

Heh - I remember asking for that years ago and being told it couldn't be done.

[Bug target/49244] __sync or __atomic builtins will not emit 'lock bts/btr/btc'

[dhowells at redhat dot com]

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

--- Comment #10 from dhowells at redhat dot com  ---
A partial optimisation could be made if the mask is constant and only contains
one bit (or/xor) or only lacks one bit (and).  That is the most common case in
the kernel by far, but it would still leave instances where the bit number is
dynamic.

[Bug target/49244] __sync or __atomic builtins will not emit 'lock bts/btr/btc'

[dhowells at redhat dot com]

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

--- Comment #13 from dhowells at redhat dot com  ---
Very nice:-)

There are a couple of under optimisations yet.  Firstly:

   #define BITS_PER_LONG (sizeof(long) * 8)
   #define _BITOPS_LONG_SHIFT 6
   static __always_inline bool test_and_change_bit(long bit, volatile unsigned
long *ptr)
   {
unsigned long mask = 1UL << (bit & (BITS_PER_LONG - 1));
unsigned long old;
ptr += bit >> _BITOPS_LONG_SHIFT;
old = __atomic_fetch_xor(ptr, mask, __ATOMIC_SEQ_CST);
return old & mask;
   }
   bool change_bit_3(unsigned long *p, long n)
   {
return test_and_change_bit(n, p);
   }

is compiled to:

0048 :
  48:   48 89 f0mov%rsi,%rax
  4b:   83 e6 3fand$0x3f,%esi
  4e:   48 c1 f8 06 sar$0x6,%rax
  52:   f0 48 0f bb 34 c7   lock btc %rsi,(%rdi,%rax,8)
  58:   0f 92 c0setb   %al
  5b:   c3  retq   

on x86, lines 48-4e are redundant as the btc instruction will do that for you. 
I don't know whether it's more efficient this way or not, though.

Secondly:

   static __always_inline bool test_bit(long bit, const unsigned long *ptr)
   {
unsigned long mask = 1UL << (bit & (BITS_PER_LONG - 1));
unsigned long old;
ptr += bit >> _BITOPS_LONG_SHIFT;
old = __atomic_load_n(ptr, __ATOMIC_RELAXED);
return old & mask;
   }
   bool read_bit(unsigned long *p)
   {
return test_bit(3, p);
   }

is compiled to:

 :
   0:   48 8b 07mov(%rdi),%rax
   3:   48 c1 e8 03 shr$0x3,%rax
   7:   83 e0 01and$0x1,%eax
   a:   c3  retq   

but could actually be either a TEST instruction or a BT instruction.

Still, thanks very much for looking at this!

[Bug target/49244] __sync or __atomic builtins will not emit 'lock bts/btr/btc'

[dhowells at redhat dot com]

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

--- Comment #14 from dhowells at redhat dot com  ---
Okay, I built and booted an x86_64 kernel that had the XXX_bit() and
test_and_XXX_bit() ops altered to use __atomic_fetch_YYY() funcs.  The core
kernel ended up ~8K larger in the .text segment.  Examining ext4_resize_begin()
as an example, this statement:

if (test_and_set_bit_lock(EXT4_RESIZING, &EXT4_SB(sb)->s_resize_flags))
ret = -EBUSY;

looks like this in the unpatched kernel:

   0x812169f3 <+122>:   lock btsl $0x0,0x3b8(%rax)
   0x812169fc <+131>:   jb 0x81216a02
   0x812169fe <+133>:   xor%edx,%edx
   0x81216a00 <+135>:   jmp0x81216a07
   0x81216a02 <+137>:   mov$0xfff0,%edx
   0x81216a07 <+142>:   mov%edx,%eax


and like this in the patched kernel:

   0x81217414 <+122>:   xor%edx,%edx
   0x81217416 <+124>:   lock btsq $0x0,0x3b8(%rax)
   0x81217420 <+134>:   setb   %dl
   0x81217423 <+137>:   neg%edx
   0x81217425 <+139>:   and$0xfff0,%edx
   0x81217428 <+142>:   mov%edx,%eax

So it looks good here at least:-)

This also suggests there's an error in the current x86_64 kernel implementation
as the kernel bitops are supposed to operate on machine word-size locations, so
it should be using BTSQ not BTSL - which would make the __atomic_fetch_or()
variant a byte shorter - and involving no conditional jumps.

[Bug target/49244] __sync or __atomic builtins will not emit 'lock bts/btr/btc'

[dhowells at redhat dot com]

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

--- Comment #17 from dhowells at redhat dot com  ---
(In reply to Paolo Bonzini from comment #16)
> > ...
> > it should be using BTSQ not BTSL
> 
> Why?  Since bts adjust the memory address according to the bit number, btsl
> and btsq are entirely the same instruction.

I suppose that's fair - the actual implementation is entirely up to the arch.

Should Jakub's optimisation patch be fixed to generate BT?L rather than BT?Q
instructions?

[Bug target/49244] __sync or __atomic builtins will not emit 'lock bts/btr/btc'

[dhowells at redhat dot com]

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

--- Comment #18 from dhowells at redhat dot com  ---
(In reply to Paolo Bonzini from comment #16)
> > This also suggests there's an error in the current x86_64 kernel 
> > implementation 
> > as the kernel bitops are supposed to operate on machine word-size 
> > locations, so 
> > it should be using BTSQ not BTSL
> 
> Why?  Since bts adjust the memory address according to the bit number, btsl
> and btsq are entirely the same instruction.

Actually, no.  BTSL takes a 32-bit bit number, whereas BTSQ takes a 64-bit bit
number if I read the manual correctly.

So, since test_and_set_bit() in the kernel takes a long bit number, BTSQ is the
right thing to use.

In practice, I don't imagine this is likely to be a real problem.  I don't
envision it as being likely that we will ever have a contiguous bitmap with
>=2^31 bits in it.

[Bug target/70973] New: x86: Can the __atomic_*() operations be made to list the LOCK prefixes?

[dhowells at redhat dot com]

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

Bug ID: 70973
   Summary: x86: Can the __atomic_*() operations be made to list
the LOCK prefixes?
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dhowells at redhat dot com
  Target Milestone: ---

When generating x86 code, the Linux kernel constructs a list of the LOCK
prefixes it applies to inline assembly-coded atomic operations.  This allows
the LOCK prefixes to be NOP'd out if there's only one CPU online.

Would it be possible to duplicate this in gcc?

What the kernel does is this:

   #ifdef CONFIG_SMP
   #define LOCK_PREFIX_HERE \
".pushsection .smp_locks,\"a\"\n"   \
".balign 4\n"   \
".long 671f - .\n" /* offset */ \
".popsection\n" \
"671:"

   #define LOCK_PREFIX LOCK_PREFIX_HERE "\n\tlock; "

   #else /* ! CONFIG_SMP */
   #define LOCK_PREFIX_HERE ""
   #define LOCK_PREFIX ""
   #endif

placing a 32-bit relative pointer in the .smp_locks section (we're assuming
that .smp_locks isn't going to be more than 2G away from the .text section).

Note, however, some LOCK prefixes apparently cannot be dispensed with, so the
listing cannot be unconditional via a command-line flag.

Would it be possible to provide a constant to OR with the memorder parameter to
flag that this atomic op should be listed in .smp_locks? E.g.:

   orig = __atomic_fetch_or(ptr, mask, __ATOMIC_ACQUIRE |
__ATOMIC_RECORD_LOCK);

This might also be useful in userspace.  So, for example, pthread
initialisation could replace a bunch of NOPs with a bunch of LOCKs so that
single-threaded processes don't get a performance penalty from LOCKed
instructions.

[Bug target/70973] x86: Can the __atomic_*() operations be made to list the LOCK prefixes?

[dhowells at redhat dot com]

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

--- Comment #1 from dhowells at redhat dot com  ---
There may be space that can be used in the memorder parameter:

"The memory order parameter is a signed int, but only the lower 16 bits are
reserved for the memory order. The remainder of the signed int is reserved for
target use and should be 0. Use of the predefined atomic values ensures proper
usage."

[Bug target/71153] New: aarch64 __atomic_fetch_and() generates probably incorrect double inversion

[dhowells at redhat dot com]

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

Bug ID: 71153
   Summary: aarch64 __atomic_fetch_and() generates probably
incorrect double inversion
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dhowells at redhat dot com
  Target Milestone: ---

Compiling this code:

static __always_inline
void clear_bit_unlock(long bit, volatile unsigned long *addr)
{
unsigned long mask = 1UL << (bit & (64 - 1));
addr += bit >> 6;
__atomic_fetch_and(addr, ~mask, __ATOMIC_RELEASE);
}

void bar_clear_bit_unlock(unsigned long *p)
{
clear_bit_unlock(22, p);
}

for aarch64-linux-gnu with "-march=armv8-a+lse -Os" generates a double negation
of the mask value in the assembly:

007c :
  7c:   92a00801mov x1, #0xffbf // #-4194305
  80:   aa2103e1mvn x1, x1
  84:   f8611001ldclrl  x1, x1, [x0]
  88:   d65f03c0ret

The instruction at 7c is loading an inverted value into x1 (it's actually a
MOVN instruction according to the opcode table that I can find); the value in
x1 is then inverted *again* by the MVN instruction.

Now, I can't find a description of how the LDCLRL instruction works, so I can't
say that it doesn't invert the parameter a third time (ie. apply an A AND-NOT B
operation), but it looks suspicious.  If nothing else, the MOVN and MOV could
be condensed into just a MOV.

If a parameter is used instead of a constant:

void foo_clear_bit_unlock(long bit, unsigned long *p)
{
clear_bit_unlock(bit, p);
}

then two MVN instructions are generated:

0048 :
  48:   12001403and w3, w0, #0x3f
  4c:   9346fc02asr x2, x0, #6
  50:   d2800020mov x0, #0x1// #1
  54:   8b020c21add x1, x1, x2, lsl #3
  58:   9ac32000lsl x0, x0, x3
  5c:   aa2003e0mvn x0, x0
  60:   aa2003e2mvn x2, x0
  64:   f8621022ldclrl  x2, x2, [x1]
  68:   d65f03c0ret

The C code appears to be correct, because on x86_64 it generates:

004c :
  4c:   f0 48 81 27 ff ff bflock andq $0xffbf,(%rdi)
  53:   ff 
  54:   c3  retq

[Bug target/71153] aarch64 __atomic_fetch_and() generates probably incorrect double inversion

[dhowells at redhat dot com]

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

--- Comment #1 from dhowells at redhat dot com  ---
(In reply to dhowe...@redhat.com from comment #0)
> ... If nothing else, the MOVN and MOV could be condensed into just a MOV. ...

The MOVN and the MVN could be condensed, that is.

[Bug target/71153] aarch64 LSE __atomic_fetch_and() generates inversion for constants

[dhowells at redhat dot com]

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

--- Comment #4 from dhowells at redhat dot com  ---
That looks better here:

007c :
  7c:   d2a00801mov x1, #0x40   // #4194304
  80:   f8611001ldclrl  x1, x1, [x0]
  84:   d65f03c0ret

But foo_clear_bit_unlock() still contains the double MVN instructions.  From
the patch you posted, I take it that only affects constant integer parameters.

[Bug target/71162] New: powerpc64 __atomics should probably emit bne- after stdcx.

[dhowells at redhat dot com]

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

Bug ID: 71162
   Summary: powerpc64 __atomics should probably emit bne- after
stdcx.
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dhowells at redhat dot com
  Target Milestone: ---

On powerpc64, __atomic_fetch_or(), for example, emits a BNE instruction after
the STDCX. instruction to work out whether it needs to retry.  For example,
compiling this:

static __always_inline
bool iso_test_and_set_bit(long bit, volatile unsigned long *addr, int memorder)
{
unsigned long mask = 1UL << (bit & (64 - 1));
unsigned long old;

addr += bit >> 6;
old = __atomic_fetch_or(addr, mask, memorder);
return old & mask;
}

long iso_t_a_s(long bit, volatile unsigned long *addr)
{
return iso_test_and_set_bit(bit, addr, __ATOMIC_SEQ_CST);
}

produces this:

00e4 <.iso_t_a_s>:
  e4:   7c 00 04 ac hwsync
  e8:   54 6a 06 be clrlwi  r10,r3,26
  ec:   7c 63 36 74 sradi   r3,r3,6
  f0:   39 20 00 01 li  r9,1
  f4:   78 63 1f 24 rldicr  r3,r3,3,60
  f8:   7d 29 50 36 sld r9,r9,r10
  fc:   7c 84 1a 14 add r4,r4,r3
 100:   7c 60 20 a8 ldarx   r3,0,r4
 104:   7c 6a 4b 78 or  r10,r3,r9
 108:   7d 40 21 ad stdcx.  r10,0,r4
 10c:   40 82 ff f4 bne 100 <.iso_t_a_s+0x1c>
 110:   4c 00 01 2c isync
 114:   7d 29 18 38 and r9,r9,r3
 118:   30 69 ff ff addic   r3,r9,-1
 11c:   7c 63 49 10 subfe   r3,r3,r9
 120:   4e 80 00 20 blr

with gcc-6.1.1 targetted at powerpc64-linux-gnu and -Os.

Hopefully the need to retry is unlikely, so BNE- should probably be emitted
rather than BNE.

[Bug target/49244] __sync or __atomic builtins will not emit 'lock bts/btr/btc'

[dhowells at redhat dot com]

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

--- Comment #20 from dhowells at redhat dot com  ---
Here's a further underoptimisation with -Os:

bool foo_test_and_change_bit(unsigned long *p)
{
return test_and_change_bit(83, p);
}

is compiled to:

0015 :
  15:   f0 48 0f ba 7f 08 13lock btcq $0x13,0x8(%rdi)
  1c:   0f 92 c0setb   %al
  1f:   c3  retq   

However, the bit number on BTCQ is an imm8, so the displacement on the memory
operand is unnecessary if the bit number will fit inside the imm8.

[Bug target/71153] aarch64 LSE __atomic_fetch_and() generates inversion for constants

[dhowells at redhat dot com]

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

--- Comment #8 from dhowells at redhat dot com  ---
(In reply to Andrew Pinski from comment #7)
> Created attachment 38509 [details]
> Full fix which needs full testing

This is looking good:

0058 :
  58:   12001403and w3, w0, #0x3f
  5c:   9346fc02asr x2, x0, #6
  60:   d2800020mov x0, #0x1// #1
  64:   8b020c21add x1, x1, x2, lsl #3
  68:   9ac32000lsl x0, x0, x3
  6c:   f8601020ldclrl  x0, x0, [x1]
  70:   d65f03c0ret

0074 :
  74:   d2a00801mov x1, #0x40   // #4194304
  78:   f8611001ldclrl  x1, x1, [x0]
  7c:   d65f03c0ret

[Bug target/71191] New: aarch64 and others: __atomic_load;arithmetic;__atomic_compare_exchange loops should be able to generate better code with LL/SC-type constructs than a CAS loop

[dhowells at redhat dot com]

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

Bug ID: 71191
   Summary: aarch64 and others:
__atomic_load;arithmetic;__atomic_compare_exchange
loops should be able to generate better code with
LL/SC-type constructs than a CAS loop
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dhowells at redhat dot com
  Target Milestone: ---

In the kernel, we have various bits of code that boil down to:

int cur = __atomic_load_n(&v->counter, __ATOMIC_RELAXED);
int new;
do {
new = do_something_to cur;
} while (!__atomic_compare_exchange_n(&v->counter,
&cur, new,
false,
__ATOMIC_SEQ_CST,
__ATOMIC_RELAXED));

and:

int cur = __atomic_load_n(&v->counter, __ATOMIC_RELAXED);
int new;
do {
if (new == not_this_value)
break;
new = do_something_to cur;
} while (!__atomic_compare_exchange_n(&v->counter,
&cur, new,
false,
__ATOMIC_SEQ_CST,
__ATOMIC_RELAXED));

For example:

static __always_inline int __atomic_add_unless(atomic_t *v,
   int addend, int unless)
{
int cur = __atomic_load_n(&v->counter, __ATOMIC_RELAXED);
int new;

do {
if (__builtin_expect(cur == unless, 0))
break;
new = cur + addend;
} while (!__atomic_compare_exchange_n(&v->counter,
  &cur, new,
  false,
  __ATOMIC_SEQ_CST,
  __ATOMIC_RELAXED));
return cur;
}

int test_atomic_add_unless(atomic_t *counter)
{
return __atomic_add_unless(counter, 0x56, 0x23);
}

If the CPU has LL/SC constructs available, something like this is probably
better implemented using that than a CMPXCHG loop - _provided_ the bit between
the __atomic_load and the __atomic_compare_exchange doesn't resolve to more
than a few instructions

So, using armv8-a as an example, the test_atomic_add_unless() function above
compiles to:

test_atomic_add_unless:
sub sp, sp, #16 # unnecessary
ldr w1, [x0]# __atomic_load_n()
str w1, [sp, 12]# bug 70825
.L5:
ldr w1, [sp, 12]# bug 70825
cmp w1, 35
beq .L4
ldr w3, [sp, 12]# bug 70825
add w1, w1, 86
.L7:
ldaxr   w2, [x0]# }
cmp w2, w3  # } __atomic_compare_exchange()
bne .L8 # }
stlxr   w4, w1, [x0]# }
cbnzw4, .L7 # }
.L8:
beq .L4
str w2, [sp, 12]# bug 70825
b   .L5
.L4:
ldr w0, [sp, 12]# bug 70825
add sp, sp, 16  # unnecessary
ret

Removing the bits added by gcc by bug 70825 and using registers throughout,
this can be reduced to:

test_atomic_add_unless:
ldr w1, [x0]# __atomic_load_n()
.L5:
cmp w1, 35
beq .L4
add w2, w1, 86
mov w3, w1
.L7:
ldaxr   w1, [x0]# }
cmp w1, w3  # } __atomic_compare_exchange()
bne .L5 # }
stlxr   w4, w2, [x0]# }
cbnzw4, .L7 # }
.L4:
mov w1, w0
ret

However, the atomic load, the arithmetic and the compare exchange can be
condensed further by moving the arithmetic inside the LL/SC section:

test_atomic_add_unless:
.L7:
ldaxr   w1, [x0]# __atomic_load_n()

[Bug target/71191] aarch64 and others: __atomic_load;arithmetic;__atomic_compare_exchange loops should be able to generate better code with LL/SC-type constructs than a CAS loop

[dhowells at redhat dot com]

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

--- Comment #3 from dhowells at redhat dot com  ---
Created attachment 38522
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38522&action=edit
atomic_add_unless() test code

Here's a .c file containing the C code I referenced.

[Bug target/71191] aarch64 and others: __atomic_load;arithmetic;__atomic_compare_exchange loops should be able to generate better code with LL/SC-type constructs than a CAS loop

[dhowells at redhat dot com]

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

--- Comment #5 from dhowells at redhat dot com  ---
(In reply to Ramana Radhakrishnan from comment #4)
> (In reply to dhowe...@redhat.com from comment #0)
> > ...
> > If the CPU has LL/SC constructs available, something like this is probably
> > better implemented using that than a CMPXCHG loop - _provided_ the bit
> > between the __atomic_load and the __atomic_compare_exchange doesn't resolve
> > to more than a few instructions
> 
> Making the compiler deal with "doesn't resolve to more than a few
> instructions" and dealing with architecture restrictions will be the fun
> part here.
> 
> It's architecture specific as to what can or cannot go into the loop. On
> AArch64 there are restrictions on what kind of instructions can go into
> these LL/SC loops using the exclusive instructions i.e. the LDAXR / STLXR
> instructions.  For e.g. these loops cannot contain other loads and stores
> and we work pretty hard to make sure that there is no accidental spilling
> inside these loops. See PR69904 for an example of where an optimization was
> skirting on the edges of the architecture - aarch32 is quite similar to
> aarch64 in this respect. 

I agree that this won't be easy.  I'm quite okay with it being limited to only
arithmetic instructions and branches out of the protected section (and
definitely no memory accesses).  Further, defining what is meant by a "few
instructions" I can see is also tricky.

> This is probably a bit harder to do in a generic manner rather than just
> adding combine patterns as we will be doing that in the backend till kingdom
> come.

Adding some set patterns might well suffice.  Something approximating
add-unless would be really good as the kernel uses that a lot.

> I'm leaving this as a target bug for now and marking it as relevant to both
> the backends but I suspect this affects other architectures too that have
> LL/SC style atomics.

powerpc64 definitely.

[Bug target/71191] aarch64 and others: __atomic_load;arithmetic;__atomic_compare_exchange loops should be able to generate better code with LL/SC-type constructs than a CAS loop

[dhowells at redhat dot com]

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

--- Comment #6 from dhowells at redhat dot com  ---
There are a couple of ways the problem could be reduced in scope.  Most of the
constructs that the kernel has that fall into this category are conditional
adds/subtracts:

typedef struct { int counter; } atomic_t;
bool atomic_inc_unless_negative(atomic_t *v)
bool atomic_dec_unless_positive(atomic_t *v)
bool atomic_inc_not_zero(atomic_t *v)
bool atomic_dec_if_positive(atomic_t *v)
bool atomic_add_unless(atomic_t *v, int addend, int unless)

all of which conform to a pattern that looks like:

({
TYPE cur = __atomic_load_n(PTR, __ATOMIC_RELAXED);
TYPE new;
bool added = true;

do {
if (cur COMPARISON COMPAREND) {
added = false;
break;
}
new = cur + ADDEND;
} while (!__atomic_compare_exchange_n(PTR,
  &cur, new,
  false,
  __ATOMIC_SEQ_CST,
  __ATOMIC_RELAXED));
added;
})

where PTR is a pointer to the memory variable to be modified, TYPE is the type
of *PTR, ADDEND and COMPAREND are integer values and COMPARISON is a numeric
comparison.  Then there's:

bool atomic_inc_not_zero_hint(atomic_t *v, int hint)

This is similar to the above, except that hint is used in place of the initial
__atomic_load_n().  Note that if you're doing LL/SC rather than a CAS loop, the
hint is of no interest.

And then there is:

int __atomic_add_unless(atomic_t *v, int addend, int unless)

which returns the original value of v->counter instead of an indication as to
the success.  I would probably replace this with something like:

bool atomic_add_unless_return(atomic_t *v, int addend, int unless, int
*_orig)

and return the original value of v->counter through the *_orig so that it
conforms more closely with the pattern above.


So the two ways to reduce the scope of the problem that I'm thinking of are:

 (1) Add very restricted patterns.  Just a single comparison and an add.

 (2) Add extra intrinsics.  I presume there would need to be one per
comparison:

bool __atomic_fetch_add_if_eq(T *ptr, T addend, T comparend, T *_orig,
 int memorder_yes, int memorder_no);
bool __atomic_fetch_add_if_ne(...);
bool __atomic_fetch_add_if_lt(...);
bool __atomic_fetch_add_if_le(...);
bool __atomic_fetch_add_if_gt(...);
bool __atomic_fetch_add_if_ge(...);

[Bug tree-optimization/72785] [7 Regression] kernel build error since r236831

[dhowells at redhat dot com]

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

--- Comment #21 from dhowells at redhat dot com  ---
(In reply to Markus Trippelsdorf from comment #20)
> *** Bug 78879 has been marked as a duplicate of this bug. ***

Kernel bug or not, it should be noted that this means that you cannot use gcc
from r236831 to compile any kernel from the introduction and use of ilog2() to
the current day - and these kernel versions cannot be retroactively fixed.

[Bug target/79404] New: h8300: ICE at gcc/ira.c:5541 whilst building libgcc

[dhowells at redhat dot com]

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

Bug ID: 79404
   Summary: h8300: ICE at gcc/ira.c:5541 whilst building libgcc
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dhowells at redhat dot com
  Target Milestone: ---

Created attachment 40686
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40686&action=edit
Test code

When building a cross compiler for h8300, an ICE occurs whilst it is building
libgcc:

/data/fedora/cross-gcc/ice.i: In function ‘__lshrdi3’:
/data/fedora/cross-gcc/ice.i:80:1: internal compiler error: Segmentation fault
 }
 ^
0x92805f crash_signal
../../gcc-7.0.1-20170204/gcc/toplev.c:333
0x7e13fb allocno_copy_cost_saving
../../gcc-7.0.1-20170204/gcc/ira-color.c:2764
0x7e9f83 improve_allocation
../../gcc-7.0.1-20170204/gcc/ira-color.c:2837
0x7e9f83 color_allocnos
../../gcc-7.0.1-20170204/gcc/ira-color.c:3141
0x7eb5b7 color_pass
../../gcc-7.0.1-20170204/gcc/ira-color.c:3250
0x7d7465 ira_traverse_loop_tree(bool, ira_loop_tree_node*, void
(*)(ira_loop_tree_node*), void (*)(ira_loop_tree_node*))
../../gcc-7.0.1-20170204/gcc/ira-build.c:1781
0x7e6c67 do_coloring
../../gcc-7.0.1-20170204/gcc/ira-color.c:3401
0x7e6c67 color
../../gcc-7.0.1-20170204/gcc/ira-color.c:4771
0x7e6c67 ira_color()
../../gcc-7.0.1-20170204/gcc/ira-color.c:4886
0x7d0ce3 ira
../../gcc-7.0.1-20170204/gcc/ira.c:5249
0x7d0ce3 execute
../../gcc-7.0.1-20170204/gcc/ira.c:5541


gcc is configured as:

// Target: h8300-elf
// Configured with: ../gcc-7.0.1-20170204/configure --bindir=/usr/bin
--build=x86_64-redhat-linux-gnu --datadir=/usr/share --disable-decimal-float
--disable-dependency-tracking --disable-gold --disable-libgcj --disable-libgomp
--disable-libmpx --disable-libquadmath --disable-libssp
--disable-libunwind-exceptions --disable-shared --disable-silent-rules
--disable-sjlj-exceptions --disable-threads
--with-ld=/usr/bin/h8300-linux-gnu-ld --enable-__cxa_atexit
--enable-checking=release --enable-gnu-unique-object --enable-initfini-array
--enable-languages=c,c++ --enable-linker-build-id --enable-lto --enable-nls
--enable-obsolete --enable-plugin --enable-targets=all --exec-prefix=/usr
--host=x86_64-redhat-linux-gnu --includedir=/usr/include
--infodir=/usr/share/info --libexecdir=/usr/libexec --localstatedir=/var
--mandir=/usr/share/man --prefix=/usr --program-prefix=h8300-linux-gnu-
--sbindir=/usr/sbin --sharedstatedir=/var/lib --sysconfdir=/etc
--target=h8300-elf --with-bugurl=http://bugzilla.redhat.com/bugzilla/
--with-gcc-major-version-only --with-isl --with-newlib
--with-plugin-ld=/usr/bin/h8300-linux-gnu-ld
--with-sysroot=/usr/h8300-linux-gnu/sys-root --with-system-libunwind
--with-system-zlib --without-headers --with-linker-hash-style=gnu
// Thread model: single
// gcc version 7.0.1 20170204 (Red Hat Cross 7.0.1-1) (GCC)

using binutils-2.27 cross-built for target h8300-elf.

The command to build the test source is:

/data/fedora/cross-gcc/gcc-7.0.1-20170204/h8300-linux-gnu/gcc/xgcc \
-B/data/fedora/cross-gcc/gcc-7.0.1-20170204/h8300-linux-gnu/gcc/ \
-B/usr/h8300-elf/bin/ \
-B/usr/h8300-elf/lib/ \
-O2 \
-c /data/fedora/cross-gcc/ice.i \
-o _lshrdi3.o

[Bug target/79404] h8300: ICE at gcc/ira.c:5541 whilst building libgcc

[dhowells at redhat dot com]

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

--- Comment #1 from dhowells at redhat dot com  ---
gcc is SVNREV 245184 plus the Fedora patches.

[Bug target/79404] h8300: ICE at gcc/ira.c:5541 whilst building libgcc

[dhowells at redhat dot com]

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

--- Comment #2 from dhowells at redhat dot com  ---
(In reply to dhowe...@redhat.com from comment #1)
> gcc is SVNREV 245184 plus the Fedora patches.

Also occurs with all patches dropped.

[Bug target/79404] h8300: ICE at gcc/ira.c:5541 whilst building libgcc

[dhowells at redhat dot com]

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

--- Comment #3 from dhowells at redhat dot com  ---
Program received signal SIGSEGV, Segmentation fault.
0x007e13fb in allocno_copy_cost_saving (
allocno=allocno@entry=0x149f340, hard_regno=2)
at ../../gcc-7.0.1-20170204/gcc/ira-color.c:2764
2764  cost += cp->freq *
ira_register_move_cost[allocno_mode][rclass][rclass];

(gdb) p cp
$1 = (ira_copy_t) 0x14cee38
(gdb) p cp->freq
$2 = 194

   0x007e13f0 <+176>:   mov%r9,%rdx
   0x007e13f3 <+179>:   add0x12a4860(,%r10,8),%rdx
=> 0x007e13fb <+187>:   movzwl (%rdx,%r11,1),%edx

r9 0x8  8
r100x21b539
r110x38 56
rdx0x8  8

$3 = (target_ira_int *) 0x12a4860 
(gdb) p &((struct target_ira_int*)0)->x_ira_register_move_cost
$4 = (move_table *(*)[39]) 0x10a0
(gdb) p 0x10a0/8
$5 = 532

So r10 is the offset of x_ira_register_move_cost/8 + 7 where allocno_mode is 7
(DImode).

But:

(gdb) p default_target_ira_int.x_ira_register_move_cost[7]
$8 = (move_table *) 0x0

(gdb) p default_target_ira_int.x_ira_register_move_cost 
$2 = {0x12f7170, 0x12f7170, 0x13e8f80, 0x0, 0x14876f0, 0x1487450, 0x14875a0, 
  0x0 }

[Bug target/79462] New: sh: Stack smashing detected when building __ashrdi3 in libgcc

[dhowells at redhat dot com]

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

Bug ID: 79462
   Summary: sh: Stack smashing detected when building __ashrdi3 in
libgcc
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dhowells at redhat dot com
  Target Milestone: ---

Stack smashing is detected on some host arches (i686, ppc64, for example, but
not x86_64) when building libgcc for an sh-target cross compiler:

/builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/xgcc
-B/builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/
-B/usr/sh-linux-gnu/bin/ -B/usr/sh-linux-gnu/lib/ -isystem
/usr/sh-linux-gnu/include -isystem /usr/sh-linux-gnu/sys-include-g -O2
-Wall -fexceptions -m2 -O2  -g -O2 -Wall -fexceptions -DIN_GCC 
-DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition 
-isystem ./include   -fpic -DNO_FPSCR_VALUES -w -Wno-sync-nand -g -DIN_LIBGCC2
-fbuilding-libgcc -fno-stack-protector -Dinhibit_libc  -fpic -DNO_FPSCR_VALUES
-w -Wno-sync-nand -I. -I. -I../../.././gcc
-I../../../../gcc-7.0.1-20170209/libgcc
-I../../../../gcc-7.0.1-20170209/libgcc/.
-I../../../../gcc-7.0.1-20170209/libgcc/../gcc
-I../../../../gcc-7.0.1-20170209/libgcc/../include  -DHAVE_CC_TLS  -o
_ashrdi3.o -MT _ashrdi3.o -MD -MP -MF _ashrdi3.dep -DL_ashrdi3 -c
../../../../gcc-7.0.1-20170209/libgcc/libgcc2.c -fvisibility=hidden
-DHIDE_EXPORTS
*** stack smashing detected ***:
/builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1 terminated
=== Backtrace: =
/lib64/libc.so.6(+0x969b8)[0x3fff947069b8]
/lib64/libc.so.6(__fortify_fail+0x54)[0x3fff947d2fc4]
/lib64/libc.so.6(__stack_chk_fail+0x20)[0x3fff947d2f60]
/builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1(_Z14gen_cbranchdi4P7rtx_defS0_S0_S0_+0xd4)[0x10b904c4]
/builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1(_Z23emit_cmp_and_jump_insnsP7rtx_defS0_8rtx_codeS0_12machine_modeiS0_i+0x170)[0x105e4b70]
/builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1(_Z23do_compare_rtx_and_jumpP7rtx_defS0_8rtx_codei12machine_modeS0_P14rtx_code_labelS4_i+0x214)[0x102ff1a4]
/builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1[0x105ed30c]
/builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1(_Z12expand_binop12machine_mode9optab_tagP7rtx_defS2_S2_i13optab_methods+0x1d54)[0x105ec814]
/builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1(_Z12expand_binop12machine_mode9optab_tagP7rtx_defS2_S2_i13optab_methods+0x5b8)[0x105eb078]
/builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1[0x1039e220]
/builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1(_Z18expand_expr_real_2P12separate_opsP7rtx_def12machine_mode15expand_modifier+0x3aa8)[0x103ca268]
/builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1(_Z18expand_expr_real_1P9tree_nodeP7rtx_def12machine_mode15expand_modifierPS2_b+0x2f54)[0x103b6d14]
/builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1[0x103c5f7c]
/builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1(_Z17expand_assignmentP9tree_nodeS0_b+0x5b8)[0x103c2e68]
/builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1[0x102743e0]
/builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1[0x10276178]
/builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1[0x1027ca08]
/builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1(_Z16execute_one_passP8opt_pass+0x334)[0x10611e54]
/builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1[0x10612e04]
/builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1(_Z17execute_pass_listP8functionP8opt_pass+0x38)[0x10612ea8]
/builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1(_ZN11cgraph_node6expandEv+0x170)[0x102b85d0]
/builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1[0x102ba0e4]
/builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1(_ZN12symbol_table25finalize_compilation_unitEv+0x1ec)[0x102bc61c]
/builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1[0x1071e04c]
/builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1(_ZN6toplev4mainEiPPc+0xfcc)[0x101199ec]
/builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1(main+0x54)[0x1011bb34]
/lib64/libc.so.6(+0x22b20)[0x3fff94692b20]
/lib64/libc.so.6(__libc_start_main+0xb8)[0x3fff94692d18]
=== Memory map: 
1000-1110 r-xp  fc:05 9181442   
/builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/gcc/cc1
1110-1113 r--p 010f fc:05 9181442   
/builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/gcc/cc1
1113-1114 rw-p 0112 fc:05 9181442   
/builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/gcc

[Bug target/79462] sh: Stack smashing detected when building __ashrdi3 in libgcc

[dhowells at redhat dot com]

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

--- Comment #1 from dhowells at redhat dot com  ---
Here's the configuration command for hosting on ppc64le:

CFLAGS='-O2 -g -Wall -Wformat-security -fexceptions -fstack-protector-strong
--param=ssp-buffer-size=4 -grecord-gcc-switches -mcpu=power8 -mtune=power8' \
CXXFLAGS=' -O2 -g -Wformat-security -fstack-protector-strong
--param=ssp-buffer-size=4 -grecord-gcc-switches -mcpu=power8 -mtune=power8 ' \
CFLAGS_FOR_TARGET='-g -O2 -Wall -fexceptions' \
AR_FOR_TARGET=/usr/bin/sh-linux-gnu-ar \
AS_FOR_TARGET=/usr/bin/sh-linux-gnu-as \
DLLTOOL_FOR_TARGET=/usr/bin/sh-linux-gnu-dlltool \
LD_FOR_TARGET=/usr/bin/sh-linux-gnu-ld \
NM_FOR_TARGET=/usr/bin/sh-linux-gnu-nm \
OBJDUMP_FOR_TARGET=/usr/bin/sh-linux-gnu-objdump \
RANLIB_FOR_TARGET=/usr/bin/sh-linux-gnu-ranlib \
READELF_FOR_TARGET=/usr/bin/sh-linux-gnu-readelf \
STRIP_FOR_TARGET=/usr/bin/sh-linux-gnu-strip \
WINDRES_FOR_TARGET=/usr/bin/sh-linux-gnu-windres \
WINDMC_FOR_TARGET=/usr/bin/sh-linux-gnu-windmc \
LDFLAGS='-Wl,-z,relro ' \
configure --bindir=/usr/bin --build=ppc64le-redhat-linux-gnu
--datadir=/usr/share --disable-decimal-float --disable-dependency-tracking
--disable-gold --disable-libgcj --disable-libgomp --disable-libmpx
--disable-libquadmath --disable-libssp --disable-libunwind-exceptions
--disable-shared --disable-silent-rules --disable-sjlj-exceptions
--disable-threads --with-ld=/usr/bin/sh-linux-gnu-ld --enable-__cxa_atexit
--enable-checking=release --enable-gnu-unique-object --enable-initfini-array
--enable-languages=c,c++ --enable-linker-build-id --enable-lto --enable-nls
--enable-obsolete --enable-plugin --enable-secureplt --enable-targets=all
--exec-prefix=/usr --host=ppc64le-redhat-linux-gnu --includedir=/usr/include
--infodir=/usr/share/info --libexecdir=/usr/libexec --localstatedir=/var
--mandir=/usr/share/man --prefix=/usr --program-prefix=sh-linux-gnu-
--sbindir=/usr/sbin --sharedstatedir=/var/lib --sysconfdir=/etc
--target=sh-linux-gnu --with-bugurl=http://bugzilla.redhat.com/bugzilla/
--with-gcc-major-version-only --with-isl --with-newlib
--with-plugin-ld=/usr/bin/sh-linux-gnu-ld
--with-sysroot=/usr/sh-linux-gnu/sys-root --with-system-libunwind
--with-system-zlib --without-headers
--with-multilib-list=m1,m2,m2e,m2a,m2a-single,m4,m4-single,m4-single-only,m4-nofpu
--with-linker-hash-style=gnu

Other arches would be similar.

The gcc-7 version in question would be:

%global DATE 20170209
%global SVNREV 245310

The binutils in 2.27 cross-compiled for sh.

[Bug target/79462] [7 Regression] sh: Stack smashing detected when building __ashrdi3 in libgcc

[dhowells at redhat dot com]

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

--- Comment #8 from dhowells at redhat dot com  ---
The patch works for me, thanks!

[Bug target/79404] [7 Regression] h8300: ICE at gcc/ira.c:5541 whilst building libgcc

[dhowells at redhat dot com]

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

--- Comment #6 from dhowells at redhat dot com  ---
That builds now, thanks!

[Bug c/77491] New: Suboptimal code produced with unnecessary moving of values on/off stack

[dhowells at redhat dot com]

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

Bug ID: 77491
   Summary: Suboptimal code produced with unnecessary moving of
values on/off stack
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dhowells at redhat dot com
  Target Milestone: ---

Created attachment 39567
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39567&action=edit
Test source

The attached program produces unnecessary instructions moving registers on and
off of the stack.  Compiled with Fedora 24 gcc-6.1.1-3 20160621, using gcc -Os,
for the first function I see:

 :
   0:   9c  pushfq 
   1:   59  pop%rcx
   2:   fa  cli
   3:   8b 07   mov(%rdi),%eax
   5:   89 44 24 fc mov%eax,-0x4(%rsp)
   9:   8b 54 24 fc mov-0x4(%rsp),%edx
   d:   83 fa 17cmp$0x17,%edx
  10:   0f 94 c0sete   %al
  13:   75 06   jne1b 
  15:   c7 07 2b 00 00 00   movl   $0x2b,(%rdi)
  1b:   51  push   %rcx
  1c:   9d  popfq  
  1d:   8b 54 24 fc mov-0x4(%rsp),%edx
  21:   89 16   mov%edx,(%rsi)
  23:   c3  retq   

The instruction at 9 is unnecessary - either the value in EDX could be moved
directly to EAX, or the comparison at d could be made against EAX.

The instructions at 5, 1d and 21 could be combined to place the result directly
in (ESI) rather than shuffling it on and off the stack.

Looking at the second function:

0024 :
  24:   9c  pushfq 
  25:   58  pop%rax
  26:   fa  cli
  27:   8b 17   mov(%rdi),%edx
  29:   89 54 24 fc mov%edx,-0x4(%rsp)
  2d:   8b 54 24 fc mov-0x4(%rsp),%edx
  31:   83 fa 17cmp$0x17,%edx
  34:   75 06   jne3c 
  36:   c7 07 2b 00 00 00   movl   $0x2b,(%rdi)
  3c:   50  push   %rax
  3d:   9d  popfq  
  3e:   8b 44 24 fc mov-0x4(%rsp),%eax
  42:   89 44 24 f8 mov%eax,-0x8(%rsp)
  46:   8b 44 24 f8 mov-0x8(%rsp),%eax
  4a:   c3  retq   

It would be best if the flags were stashed in ECX, not EAX, as happens with the
first function.  This would allow the return value to be set in instruction 27.
 The comparison in 31 could then be against EAX directly.  Instructions 29, 2d,
3e, 42 and 46 are all redundant.

Changing the #if in the code to disable the inline asm doesn't show all that
much improvement in either function.  Doing this also allows it to be built for
aarch64 - which also shows unnecessary stack shuffling:

 :
   0:   d10043ffsub sp, sp, #0x10
   4:   b942ldr w2, [x0]
   8:   b9000fe2str w2, [sp,#12]
   c:   b9400fe2ldr w2, [sp,#12]
  10:   71005c5fcmp w2, #0x17
  14:   1a9f17e3csetw3, eq
  18:   5461b.ne24 
  1c:   52800562mov w2, #0x2b   // #43
  20:   b902str w2, [x0]
  24:   b9400fe0ldr w0, [sp,#12]
  28:   b920str w0, [x1]
  2c:   2a0303e0mov w0, w3
  30:   910043ffadd sp, sp, #0x10
  34:   d65f03c0ret

0038 :
  38:   d10043ffsub sp, sp, #0x10
  3c:   b941ldr w1, [x0]
  40:   b9000fe1str w1, [sp,#12]
  44:   b9400fe1ldr w1, [sp,#12]
  48:   71005c3fcmp w1, #0x17
  4c:   5461b.ne58 
  50:   52800561mov w1, #0x2b   // #43
  54:   b901str w1, [x0]
  58:   b9400fe0ldr w0, [sp,#12]
  5c:   b9000be0str w0, [sp,#8]
  60:   b9400be0ldr w0, [sp,#8]
  64:   910043ffadd sp, sp, #0x10
  68:   d65f03c0ret

[Bug target/77599] New: M68K: __builtin_bswap32() isn't compiled correctly with -mshort

[dhowells at redhat dot com]

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

Bug ID: 77599
   Summary: M68K: __builtin_bswap32() isn't compiled correctly
with -mshort
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dhowells at redhat dot com
  Target Milestone: ---

The following test code:

unsigned long x(unsigned long y)
{
return __builtin_bswap32(y);
}

is miscompiled for m68k when -mshort is specified.  Compiling with

m68k-linux-gnu-gcc -m68000 -S /tmp/3.c -o - -mshort

I see:

x:
link.w %fp,#0
move.l 8(%fp),%d0
ror.w #8,%d0
move.w %d0,%d0
and.l #65535,%d0
unlk %fp
rts

dropping the -mshort I see:

x:
link.w %fp,#0
move.l 8(%fp),%d0
ror.w #8,%d0
swap %d0
ror.w #8,%d0
unlk %fp
rts

I'm using a gcc-6.1.1 cross-compiler built for x86_64, but the problem also
shows up on gcc-5.3.1.  The gcc-6.1.1 compiler is svn rev 237634, dated 
20160621.

[Bug target/77600] New: M68K: gcc generates rubbish with -mshort

[dhowells at redhat dot com]

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

Bug ID: 77600
   Summary: M68K: gcc generates rubbish with -mshort
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dhowells at redhat dot com
  Target Milestone: ---

In certain cases gcc wants to generate the equivalent of:

move.b (%a0,-1),foo

but instead of generating:

moveq #-1.%d0
moveb(%a0,%d0.l)

or similar it generates the bogus sequence:

moveq #0,%d0
not.w %d0

which would be the fast way of generating a 16-bit -1 value rather than a
32-bit value.

Compiling:

void *my_memcpy(void *d, const void *s, long sz)
{
unsigned char *dp = d;
const unsigned char *sp = s;
while (sz--)
*dp++ = *sp++;
return d;
}

with:

m68k-linux-gnu-gcc -m68000 -S /tmp/memcpy.c -o - -O2 -mshort

produces:

my_memcpy:
link.w %fp,#0
move.l %a3,-(%sp)
move.l %a2,-(%sp)
move.l 8(%fp),%a0
move.l 16(%fp),%d0
jeq .L6
move.l %a0,%a2
ext.l %d0  <--- isn't the size a 'long int'?
lea (%a0,%d0.l),%a3
move.l 12(%fp),%a1
moveq #0,%d0   <--- dodgy bit
not.w %d0  <---
.L3:
addq.l #1,%a1
move.b (%a1,%d0.l),(%a2)+  <--- should this be %d0.w as the index?
cmp.l %a2,%a3
jne .L3
.L6:
move.l %a0,%d0
move.l (%sp)+,%a2
move.l (%sp)+,%a3
unlk %fp
rts

Dropping the -mshort, I see:

my_memcpy:
link.w %fp,#0
move.l %a2,-(%sp)
move.l 8(%fp),%a0
move.l 12(%fp),%a1
tst.l 16(%fp)
jeq .L6
move.l %a0,%a2
move.l 16(%fp),%d0
add.l %a1,%d0
.L3:
move.b (%a1)+,(%a2)+
cmp.l %a1,%d0
jne .L3
.L6:
move.l %a0,%d0
move.l (%sp)+,%a2
unlk %fp
rts

which looks correct, though there's a test of sz and then sz is loaded into %d0
in two separate instructions; possibly these two could be combined since move
to data reg sets the condition flags.

I'm using a gcc-6.1.1 cross-compiler built for x86_64, but the problem also
shows up on gcc-5.3.1.  The gcc-6.1.1 compiler is svn rev 237634, dated 
20160621.

[Bug target/77599] M68K: __builtin_bswap32() isn't compiled correctly with -mshort

[dhowells at redhat dot com]

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

--- Comment #1 from dhowells at redhat dot com  ---
warthog>m68k-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/m68k-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/m68k-linux-gnu/6.1.1/lto-wrapper
Target: m68k-linux-gnu
Configured with: ../gcc-6.1.1-20160427/configure --bindir=/usr/bin
--build=x86_64-redhat-linux-gnu --datadir=/usr/share --disable-decimal-float
--disable-dependency-tracking --disable-gold --disable-libgcj --disable-libgomp
--disable-libmpx --disable-libquadmath --disable-libssp
--disable-libunwind-exceptions --disable-shared --disable-silent-rules
--disable-sjlj-exceptions --disable-threads
--with-ld=/usr/bin/m68k-linux-gnu-ld --enable-__cxa_atexit
--enable-checking=release --enable-gnu-unique-object --enable-initfini-array
--enable-languages=c,c++ --enable-linker-build-id --enable-lto --enable-nls
--enable-obsolete --enable-plugin --enable-targets=all --exec-prefix=/usr
--host=x86_64-redhat-linux-gnu --includedir=/usr/include
--infodir=/usr/share/info --libexecdir=/usr/libexec --localstatedir=/var
--mandir=/usr/share/man --prefix=/usr --program-prefix=m68k-linux-gnu-
--sbindir=/usr/sbin --sharedstatedir=/var/lib --sysconfdir=/etc
--target=m68k-linux-gnu --with-bugurl=http://bugzilla.redhat.com/bugzilla/
--with-isl --with-newlib --with-plugin-ld=/usr/bin/m68k-linux-gnu-ld
--with-sysroot=/usr/m68k-linux-gnu/sys-root --with-system-libunwind
--with-system-zlib --without-headers --with-linker-hash-style=gnu
Thread model: single
gcc version 6.1.1 20160427 (Red Hat Cross 6.1.1-1) (GCC)

[Bug target/77600] M68K: gcc generates rubbish with -mshort

[dhowells at redhat dot com]

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

--- Comment #1 from dhowells at redhat dot com  ---
warthog>m68k-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/m68k-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/m68k-linux-gnu/6.1.1/lto-wrapper
Target: m68k-linux-gnu
Configured with: ../gcc-6.1.1-20160427/configure --bindir=/usr/bin
--build=x86_64-redhat-linux-gnu --datadir=/usr/share --disable-decimal-float
--disable-dependency-tracking --disable-gold --disable-libgcj --disable-libgomp
--disable-libmpx --disable-libquadmath --disable-libssp
--disable-libunwind-exceptions --disable-shared --disable-silent-rules
--disable-sjlj-exceptions --disable-threads
--with-ld=/usr/bin/m68k-linux-gnu-ld --enable-__cxa_atexit
--enable-checking=release --enable-gnu-unique-object --enable-initfini-array
--enable-languages=c,c++ --enable-linker-build-id --enable-lto --enable-nls
--enable-obsolete --enable-plugin --enable-targets=all --exec-prefix=/usr
--host=x86_64-redhat-linux-gnu --includedir=/usr/include
--infodir=/usr/share/info --libexecdir=/usr/libexec --localstatedir=/var
--mandir=/usr/share/man --prefix=/usr --program-prefix=m68k-linux-gnu-
--sbindir=/usr/sbin --sharedstatedir=/var/lib --sysconfdir=/etc
--target=m68k-linux-gnu --with-bugurl=http://bugzilla.redhat.com/bugzilla/
--with-isl --with-newlib --with-plugin-ld=/usr/bin/m68k-linux-gnu-ld
--with-sysroot=/usr/m68k-linux-gnu/sys-root --with-system-libunwind
--with-system-zlib --without-headers --with-linker-hash-style=gnu
Thread model: single
gcc version 6.1.1 20160427 (Red Hat Cross 6.1.1-1) (GCC)

[Bug tree-optimization/72785] [7 Regression] kernel build error since r236831

[dhowells at redhat dot com]

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

dhowells at redhat dot com  changed:

   What|Removed |Added

 CC||dhowells at redhat dot com

--- Comment #13 from dhowells at redhat dot com  ---
Another possibility, at least for handling ilog2(), could be to provide
__builtin_ilog2(unsigned long x) as an alternative.

Note that the kernel ilog2() has the property that the result is undefined if
x==0 (and will jump to ilog2_NaN() if x is constant 0).

[Bug tree-optimization/72785] [7 Regression] kernel build error since r236831

[dhowells at redhat dot com]

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

--- Comment #15 from dhowells at redhat dot com  ---
(In reply to Jakub Jelinek from comment #14)
> (In reply to dhowe...@redhat.com from comment #13)
> ...
> Ugh, no.  Why not just x && (x & -x) == x ? __builtin_ctz (x) : -1
> (or ctzl or ctzll depending on what the type is)?

Comparing the kernel's ilog2() to your suggestion:

int kernel_ilog2(unsigned long x)
{
return ilog2(x);
}

int jakub_ilog2(unsigned long x)
{
return x && (x & -x) == x ? __builtin_ctz (x) : -1;
}

compiled with -Os for x86_64 gives:

 :
   0:   83 c8 ffor $0x,%eax
   3:   48 0f bd c7 bsr%rdi,%rax
   7:   c3  retq   

0008 :
   8:   83 c8 ffor $0x,%eax
   b:   48 85 fftest   %rdi,%rdi
   e:   74 17   je 27 
  10:   48 89 famov%rdi,%rdx
  13:   0f bc c7bsf%edi,%eax
  16:   48 f7 daneg%rdx
  19:   48 21 faand%rdi,%rdx
  1c:   48 39 d7cmp%rdx,%rdi
  1f:   ba ff ff ff ff  mov$0x,%edx
  24:   0f 45 c2cmovne %edx,%eax
  27:   c3  retq   

Note that in the kernel variant, the initial OR instruction is superfluous, but
is required by fls() and fls64() which x86_64 is using behind the scenes.  Not
all arches, however, use fls() and fls64() to implement ilog2().

[Bug tree-optimization/72785] [7 Regression] kernel build error since r236831

[dhowells at redhat dot com]

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

--- Comment #16 from dhowells at redhat dot com  ---
I guess the following could be used:

int clz_ilog2(unsigned long x)
{
return __builtin_clz(x);
}

which compiles to:

0027 :
  27:   0f bd c7bsr%edi,%eax
  2a:   83 f0 1fxor$0x1f,%eax
  2d:   c3  retq   

though the XOR is superfluous - for any valid input to ilog2(), I think the
output is always in the range 0-31.

[Bug tree-optimization/72785] [7 Regression] kernel build error since r236831

[dhowells at redhat dot com]

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

--- Comment #17 from dhowells at redhat dot com  ---
(In reply to dhowe...@redhat.com from comment #16)
> ...
> 0027 :
>   27:   0f bd c7bsr%edi,%eax
>   2a:   83 f0 1fxor$0x1f,%eax
>   2d:   c3  retq   
> 
> though the XOR is superfluous - for any valid input to ilog2(), I think the
> output is always in the range 0-31.

Ah - it's not actually an AND, so the XOR isn't necessarily superfluous.

[Bug c/78317] New: "if (x & constant) z |= constant" should not be rendered with jumps and conditional moves

[dhowells at redhat dot com]

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

Bug ID: 78317
   Summary: "if (x & constant) z |= constant" should not be
rendered with jumps and conditional moves
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dhowells at redhat dot com
  Target Milestone: ---

Created attachment 40025
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40025&action=edit
Test code

The following code:

unsigned test1(unsigned x)
{
unsigned z = 0;
if (x & 0x10)
z |= 0x10;
return z;
}

on x86_64 compiled with -Os to:

   0:   89 f8   mov%edi,%eax
   2:   ba 10 00 00 00  mov$0x10,%edx
   7:   83 e0 10and$0x10,%eax
   a:   0f 45 c2cmovne %edx,%eax
   d:   c3  retq   

when what it should probable do is what clang does:

   0:   83 e7 10and$0x10,%edi
   3:   89 f8   mov%edi,%eax
   5:   c3  retq   

as the bit can be transferred by an AND and an OR.

Further, two or more such statements can be combined, for instance:

unsigned test2(unsigned x)
{
unsigned z = 0;
if (x & 0x10)
z |= 0x10;
if (x & 0x40)
z |= 0x40;
return z;
}

but gcc gives the following:

   e:   89 f8   mov%edi,%eax
  10:   ba 10 00 00 00  mov$0x10,%edx
  15:   83 e0 10and$0x10,%eax
  18:   0f 45 c2cmovne %edx,%eax
  1b:   89 c2   mov%eax,%edx
  1d:   83 ca 40or $0x40,%edx
  20:   40 80 e7 40 and$0x40,%dil
  24:   0f 45 c2cmovne %edx,%eax
  27:   c3  retq   

when clang gives:

   6:   83 e7 50and$0x50,%edi
   9:   89 f8   mov%edi,%eax
   b:   c3  retq   


If z isn't passed in, but rather is initialised to another argument, say y:

unsigned test3(unsigned x, unsigned y)
{
unsigned z = y;
if (x & 0x10)
z |= 0x10;
return z;
}

unsigned test4(unsigned x, unsigned y)
{
unsigned z = y;
if (x & 0x10)
z |= 0x10;
if (x & 0x40)
z |= 0x40;
return z;
}

then gcc gives:

0028 :
  28:   89 f2   mov%esi,%edx
  2a:   89 f0   mov%esi,%eax
  2c:   83 ca 10or $0x10,%edx
  2f:   40 80 e7 10 and$0x10,%dil
  33:   0f 45 c2cmovne %edx,%eax
  36:   c3  retq   

0037 :
  37:   89 f2   mov%esi,%edx
  39:   89 f0   mov%esi,%eax
  3b:   83 ca 10or $0x10,%edx
  3e:   40 f6 c7 10 test   $0x10,%dil
  42:   0f 45 c2cmovne %edx,%eax
  45:   89 c2   mov%eax,%edx
  47:   83 ca 40or $0x40,%edx
  4a:   40 80 e7 40 and$0x40,%dil
  4e:   0f 45 c2cmovne %edx,%eax
  51:   c3  retq   

and clang gives:

000c :
   c:   83 e7 10and$0x10,%edi
   f:   09 f7   or %esi,%edi
  11:   89 f8   mov%edi,%eax
  13:   c3  retq   

0014 :
  14:   89 f8   mov%edi,%eax
  16:   83 e0 10and$0x10,%eax
  19:   09 f0   or %esi,%eax
  1b:   83 e7 40and$0x40,%edi
  1e:   09 c7   or %eax,%edi
  20:   89 f8   mov%edi,%eax
  22:   c3  retq   

Both gcc and clang give suboptimal code for test4().  What they should do is:

and$0x50,%edi
or %esi,%edi
mov%edi,%eax
retq

Note that gcc also produces similarly suboptimal output for targets other than
x86_64.

[Bug tree-optimization/78317] "if (x & constant) z |= constant" should not be rendered with jumps and conditional moves

[dhowells at redhat dot com]

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

--- Comment #5 from dhowells at redhat dot com  ---
Note that the issue doesn't require the value to be returned directly to
trigger it:

struct A { unsigned a; };
struct B { unsigned b; };
unsigned test5(struct A *x, struct B *y)
{
unsigned z = 0;
if (x->a & 0x10)
z |= 0x10;
if (x->a & 0x40)
z |= 0x40;
y->b = z;
}

is rendered as:

  52:   8b 17   mov(%rdi),%edx
  54:   b9 10 00 00 00  mov$0x10,%ecx
  59:   89 d0   mov%edx,%eax
  5b:   83 e0 10and$0x10,%eax
  5e:   0f 45 c1cmovne %ecx,%eax
  61:   89 c1   mov%eax,%ecx
  63:   83 c9 40or $0x40,%ecx
  66:   80 e2 40and$0x40,%dl
  69:   0f 45 c1cmovne %ecx,%eax
  6c:   89 06   mov%eax,(%rsi)
  6e:   c3  retq   

by gcc -Os, but:

  23:   8b 07   mov(%rdi),%eax
  25:   83 e0 50and$0x50,%eax
  28:   89 06   mov%eax,(%rsi)
  2a:   c3  retq   

by clang -Os.

[Bug target/65052] ICE in c6x-uclinux target when building libgcc

[dhowells at redhat dot com]

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

--- Comment #6 from dhowells at redhat dot com  ---
Fixed how?  Is Nick's patch good?

[Bug target/65649] New: gcc generates overlarge constants for microblaze-linux-gnu

[dhowells at redhat dot com]

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

Bug ID: 65649
   Summary: gcc generates overlarge constants for
microblaze-linux-gnu
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dhowells at redhat dot com

Whilst compiling libgcc for microblaze-linux-gnu, gcc produces overlarge
constants that don't fit into a 32-bits (microblaze is a 32-bit arch), eg:

addikr23,r0,0xb746a0003f80

the assembler complains about these:

_powisf2.s:71: Fatal error: operand must be a constant or a label

if it is hosted on a 32-bit arch (eg. i386) but not if it's hosted on a 64-bit
arch (eg. x86_64).  This is logged here:

https://sourceware.org/bugzilla/show_bug.cgi?id=18189

However, gcc shouldn't be producing these at all.

Reducing the preprocessed C to the bare function gives:

float __powisf2 (float x, int m)
{
  unsigned int n = m < 0 ? -m : m;
  float y = n % 2 ? x : 1;
  while (n >>= 1)
{
  x = x * x;
  if (n % 2)
y = y * x;
}
  return m < 0 ? 1/y : y;
}

Reducing it still further to:

float __powisf2 (float x, int m)
{
  unsigned int n = m < 0 ? -m : m;
  float y = n % 2 ? x : 1;
  return y;
}

gives the error _only_ if -g is supplied.  Looking at the assembly output of
this, the dodgy instruction is now:

addik   r3,r0,0xb745e0003f80

with -g and:

addik   r3,r0,0x3f80

without.

The compilation line is:

/root/cross-gcc/gcc-5.0.0-20150319/microblaze-linux-gnu/gcc/xgcc
-B/root/cross-gcc/gcc-5.0.0-20150319/microblaze-linux-gnu/gcc/
-B/usr/microblaze-linux-gnu/bin/ -B/usr/microblaze-linux-gnu/lib/ -O2 -fPIC
-fbuilding-libgcc -fno-exceptions -fno-stack-protector -fvisibility=hidden -o
_powisf2.o -c _powisf2.i --save-temps -g

[Bug target/65649] gcc generates overlarge constants for microblaze-linux-gnu

[dhowells at redhat dot com]

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

--- Comment #1 from dhowells at redhat dot com  ---
Created attachment 35201
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35201&action=edit
Assembler output from larger reduced case

Here is the assembler output from the larger reduced case.  The dodgy constant
occurs on line 71 and also on line 124.

[Bug target/65649] gcc generates overlarge constants for microblaze-linux-gnu

[dhowells at redhat dot com]

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

--- Comment #2 from dhowells at redhat dot com  ---
gcc was based on the gcc-5.0.0-20150319 tarball generated from the gcc branch
redhat/gcc-5-branch plus the patches for the Fedora rawhide gcc and cross-gcc.

Configuration was:

CC=gcc \
CXX=g++ \
CFLAGS='-O2 -g -Wall -Wformat-security -fexceptions -fstack-protector-strong
--param=ssp-buffer-size=4 -grecord-gcc-switches -mtune=atom
-fasynchronous-unwind-tables' \
CXXFLAGS=' -O2 -g -Wformat-security -fstack-protector-strong
--param=ssp-buffer-size=4 -grecord-gcc-switches -mtune=atom
-fasynchronous-unwind-tables ' \
CFLAGS_FOR_TARGET='-g -O2 -Wall -fno-exceptions' \
AR_FOR_TARGET=/usr/bin/microblaze-linux-gnu-ar \
AS_FOR_TARGET=/usr/bin/microblaze-linux-gnu-as \
DLLTOOL_FOR_TARGET=/usr/bin/microblaze-linux-gnu-dlltool \
LD_FOR_TARGET=/usr/bin/microblaze-linux-gnu-ld \
NM_FOR_TARGET=/usr/bin/microblaze-linux-gnu-nm \
OBJDUMP_FOR_TARGET=/usr/bin/microblaze-linux-gnu-objdump \
RANLIB_FOR_TARGET=/usr/bin/microblaze-linux-gnu-ranlib \
READELF_FOR_TARGET=/usr/bin/microblaze-linux-gnu-readelf \
STRIP_FOR_TARGET=/usr/bin/microblaze-linux-gnu-strip \
WINDRES_FOR_TARGET=/usr/bin/microblaze-linux-gnu-windres \
WINDMC_FOR_TARGET=/usr/bin/microblaze-linux-gnu-windmc \
LDFLAGS='-Wl,-z,relro ' \
../gcc-5.0.0-20150319/configure --bindir=/usr/bin --build=i686-redhat-linux-gnu
--datadir=/usr/share --disable-decimal-float --disable-dependency-tracking
--disable-gold --disable-libgcj --disable-libgomp --disable-libmudflap
--disable-libquadmath --disable-libssp --disable-libunwind-exceptions
--disable-nls --disable-plugin --disable-shared --disable-silent-rules
--disable-sjlj-exceptions --disable-threads
--with-ld=/usr/bin/microblaze-linux-gnu-ld --enable-__cxa_atexit
--enable-checking=release --enable-gnu-indirect-function
--enable-gnu-unique-object --enable-initfini-array --enable-languages=c,c++
--enable-linker-build-id --enable-nls --enable-obsolete --enable-plugin
--enable-targets=all --exec-prefix=/usr --host=i686-redhat-linux-gnu
--includedir=/usr/include --infodir=/usr/share/info --libexecdir=/usr/libexec
--localstatedir=/var --mandir=/usr/share/man --prefix=/usr
--program-prefix=microblaze-linux-gnu- --sbindir=/usr/sbin
--sharedstatedir=/var/lib --sysconfdir=/etc --target=microblaze-linux-gnu
--with-bugurl=http://bugzilla.redhat.com/bugzilla/ --with-isl
--with-linker-hash-style=gnu --with-newlib
--with-sysroot=/usr/microblaze-linux-gnu/sys-root --with-system-libunwind
--with-system-zlib --without-headers

And the build:

make -C microblaze-linux-gnu -j16 tooldir=/usr all-gcc
make -C microblaze-linux-gnu -j16 tooldir=/usr all-target-libgcc

The microblaze binutils was binutils-2.25 plus the Fedora F21 patches from the
cross-binutils targetted at microblaze-linux-gnu.

[Bug target/65052] ICE in c6x-uclinux target when building libgcc

[dhowells at redhat dot com]

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

--- Comment #8 from dhowells at redhat dot com  ---
This seems to work for me, thanks!

[Bug target/66140] New: ICE at extract_insn, at recog.c:2343 when compiling for alpha with gcc-5.1.1

[dhowells at redhat dot com]

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

Bug ID: 66140
   Summary: ICE at extract_insn, at recog.c:2343 when compiling
for alpha with gcc-5.1.1
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dhowells at redhat dot com
  Target Milestone: ---

Created attachment 35539
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35539&action=edit
Reduced test case

I'm seeing the following ICE:

alpha-linux-gnu-gcc -O2 -c alpha-reduced.c
alpha-reduced.c: In function 'lpfc_bg_scsi_prep_dma_buf_s3':
alpha-reduced.c:51:1: error: unrecognizable insn:
 }
 ^
(insn 88 87 89 9 (set (reg:DI 3 $3)
(mem:DI (and:DI (plus:DI (mem/c:DI (plus:DI (reg/f:DI 30 $30)
(const_int 64 [0x40])) [6 %sfp+0 S8 A64])
(const_int 3 [0x3]))
(const_int -8 [0xfff8])) [0  S8 A64]))
alpha-reduced.c:35 -1
 (nil))
alpha-reduced.c:51:1: internal compiler error: in extract_insn, at recog.c:2343

with the attached test case when cross-compiling for alpha with gcc-5.1.1.

The compiler is built from SVN rev 222331 dated 20150422 with no patches
applied and is running on an x86_64 Linux system.  The binutils is 2.25 based.

The compiler was configured thus:

CC=gcc \
CXX=g++ \
CFLAGS='-O2 -g -Wall -Wformat-security -fexceptions -fstack-protector-strong
--param=ssp-buffer-size=4 -grecord-gcc-switches -mtune=generic' \
CXXFLAGS=' -O2 -g -Wformat-security -fstack-protector-strong
--param=ssp-buffer-size=4 -grecord-gcc-switches -mtune=generic ' \
CFLAGS_FOR_TARGET='-g -O2 -Wall -fexceptions' \
AR_FOR_TARGET=/usr/bin/alpha-linux-gnu-ar \
AS_FOR_TARGET=/usr/bin/alpha-linux-gnu-as \
DLLTOOL_FOR_TARGET=/usr/bin/alpha-linux-gnu-dlltool \
LD_FOR_TARGET=/usr/bin/alpha-linux-gnu-ld \
NM_FOR_TARGET=/usr/bin/alpha-linux-gnu-nm \
OBJDUMP_FOR_TARGET=/usr/bin/alpha-linux-gnu-objdump \
RANLIB_FOR_TARGET=/usr/bin/alpha-linux-gnu-ranlib \
READELF_FOR_TARGET=/usr/bin/alpha-linux-gnu-readelf \
STRIP_FOR_TARGET=/usr/bin/alpha-linux-gnu-strip \
WINDRES_FOR_TARGET=/usr/bin/alpha-linux-gnu-windres \
WINDMC_FOR_TARGET=/usr/bin/alpha-linux-gnu-windmc \
LDFLAGS='-Wl,-z,relro ' \
../gcc-5.1.1-20150422/configure --bindir=/usr/bin
--build=x86_64-redhat-linux-gnu --datadir=/usr/share --disable-decimal-float
--disable-dependency-tracking --disable-gold --disable-libgcj --disable-libgomp
--disable-libmudflap --disable-libquadmath --disable-libssp
--disable-libunwind-exceptions --disable-nls --disable-plugin --disable-shared
--disable-silent-rules --disable-sjlj-exceptions --disable-threads
--with-ld=/usr/bin/alpha-linux-gnu-ld --enable-__cxa_atexit
--enable-checking=release --enable-gnu-indirect-function
--enable-gnu-unique-object --enable-initfini-array --enable-languages=c,c++
--enable-linker-build-id --enable-nls --enable-obsolete --enable-plugin
--enable-targets=all --exec-prefix=/usr --host=x86_64-redhat-linux-gnu
--includedir=/usr/include --infodir=/usr/share/info --libexecdir=/usr/libexec
--localstatedir=/var --mandir=/usr/share/man --prefix=/usr
--program-prefix=alpha-linux-gnu- --sbindir=/usr/sbin --sharedstatedir=/var/lib
--sysconfdir=/etc --target=alpha-linux-gnu
--with-bugurl=http://bugzilla.redhat.com/bugzilla/ --with-isl
--with-linker-hash-style=gnu --with-newlib
--with-sysroot=/usr/alpha-linux-gnu/sys-root --with-system-libunwind
--with-system-zlib --without-headers

and built thus:

AR_FOR_TARGET=/usr/bin/alpha-linux-gnu-ar \
AS_FOR_TARGET=/usr/bin/alpha-linux-gnu-as \
DLLTOOL_FOR_TARGET=/usr/bin/alpha-linux-gnu-dlltool \
LD_FOR_TARGET=/usr/bin/alpha-linux-gnu-ld \
NM_FOR_TARGET=/usr/bin/alpha-linux-gnu-nm \
OBJDUMP_FOR_TARGET=/usr/bin/alpha-linux-gnu-objdump \
RANLIB_FOR_TARGET=/usr/bin/alpha-linux-gnu-ranlib \
READELF_FOR_TARGET=/usr/bin/alpha-linux-gnu-readelf \
STRIP_FOR_TARGET=/usr/bin/alpha-linux-gnu-strip \
WINDRES_FOR_TARGET=/usr/bin/alpha-linux-gnu-windres \
WINDMC_FOR_TARGET=/usr/bin/alpha-linux-gnu-windmc \
make -C alpha-linux-gnu -j5 tooldir=/usr all-gcc
make -C alpha-linux-gnu -j5 tooldir=/usr all-target-libgcc

[Bug target/66140] ICE at extract_insn, at recog.c:2343 when compiling for alpha with gcc-5.1.1

[dhowells at redhat dot com]

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

--- Comment #3 from dhowells at redhat dot com  ---
The compiler works now, thanks!

[Bug target/68459] New: ICE when compiling for alpha with -O3

[dhowells at redhat dot com]

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

Bug ID: 68459
   Summary: ICE when compiling for alpha with -O3
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dhowells at redhat dot com
  Target Milestone: ---

Created attachment 36782
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36782&action=edit
Reduced test case

When compiling the attached test case for alpha-linux-gnu with -O3, the
compiler segfaults and produces the following:

alpha-linux-gnu-gcc -c -O3 /tmp/bz1265791-testcase.c 
/tmp/bz1265791-testcase.c: In function ‘synchronize_rcu_tasks’:
/tmp/bz1265791-testcase.c:8:6: internal compiler error: Segmentation fault
 void synchronize_rcu_tasks(void)
  ^

/usr/libexec/gcc/alpha-linux-gnu/5.2.1/cc1 -quiet -v /tmp/bz1265791-testcase.c
-quiet -dumpbase bz1265791-testcase.c -auxbase bz1265791-testcase -O3 -version
-o /tmp/ccf0UqVc.s

I caught it in gdb:

Program received signal SIGSEGV, Segmentation fault.
fold_builtin_alloca_with_align (stmt=0x719436c0)
at ../../gcc-5.2.1-20150716/gcc/tree-ssa-ccp.c:2067
2067&& TREE_CODE (BLOCK_SUPERCONTEXT (block)) == FUNCTION_DECL))


and I got the following backtrace:

#0  fold_builtin_alloca_with_align (stmt=0x719436c0)
at ../../gcc-5.2.1-20150716/gcc/tree-ssa-ccp.c:2067
#1  ccp_fold_stmt (gsi=0x7fffd8a0)
at ../../gcc-5.2.1-20150716/gcc/tree-ssa-ccp.c:2172
#2  0x00a07c17 in substitute_and_fold_dom_walker::before_dom_children (
this=0x7fffd960, bb=0x7191faf8)
at ../../gcc-5.2.1-20150716/gcc/tree-ssa-propagate.c:1177
#3  0x00b8dfe8 in dom_walker::walk (this=0x7fffd960, 
bb=0x7191faf8) at ../../gcc-5.2.1-20150716/gcc/domwalk.c:188
#4  0x00a0762a in substitute_and_fold (
get_value_fn=get_value_fn@entry=0x9942f0 , 
fold_fn=fold_fn@entry=0x99bfa0 , 
do_dce=do_dce@entry=true)
at ../../gcc-5.2.1-20150716/gcc/tree-ssa-propagate.c:1272
#5  0x00993b41 in ccp_finalize ()
at ../../gcc-5.2.1-20150716/gcc/tree-ssa-ccp.c:941
#6  do_ssa_ccp () at ../../gcc-5.2.1-20150716/gcc/tree-ssa-ccp.c:2382
#7  (anonymous namespace)::pass_ccp::execute (this=)
at ../../gcc-5.2.1-20150716/gcc/tree-ssa-ccp.c:2414
#8  0x0083aa9e in execute_one_pass (pass=pass@entry=0x12221d0)
at ../../gcc-5.2.1-20150716/gcc/passes.c:2330
#9  0x0083aeb6 in execute_pass_list_1 (pass=0x12221d0)
at ../../gcc-5.2.1-20150716/gcc/passes.c:2382
---Type  to continue, or q  to quit---
#10 0x0083aec8 in execute_pass_list_1 (pass=0x1222050, 
pass@entry=0x1221f90) at ../../gcc-5.2.1-20150716/gcc/passes.c:2383
#11 0x0083af09 in execute_pass_list (fn=0x7193cf18, pass=0x1221f90)
at ../../gcc-5.2.1-20150716/gcc/passes.c:2393
#12 0x005fa268 in cgraph_node::expand (this=this@entry=0x7183a300)
at ../../gcc-5.2.1-20150716/gcc/cgraphunit.c:1895
#13 0x005fb4ac in expand_all_functions ()
at ../../gcc-5.2.1-20150716/gcc/cgraphunit.c:2031
#14 symbol_table::compile (this=0x7183c000)
at ../../gcc-5.2.1-20150716/gcc/cgraphunit.c:2384
#15 0x005fc8b8 in symbol_table::finalize_compilation_unit (
this=0x7183c000) at ../../gcc-5.2.1-20150716/gcc/cgraphunit.c:2461
#16 0x005114cb in c_write_global_declarations ()
at ../../gcc-5.2.1-20150716/gcc/c/c-decl.c:10798
#17 0x008d8d55 in compile_file ()
at ../../gcc-5.2.1-20150716/gcc/toplev.c:613
#18 0x004fde1f in do_compile ()
at ../../gcc-5.2.1-20150716/gcc/toplev.c:2067
#19 toplev::main (this=this@entry=0x7fffdce0, argc=argc@entry=13, 
argv=argv@entry=0x7fffdde8)
at ../../gcc-5.2.1-20150716/gcc/toplev.c:2165
#20 0x004fe7aa in main (argc=13, argv=0x7fffdde8)
at ../../gcc-5.2.1-20150716/gcc/main.c:39

[Bug target/68459] ICE when compiling for alpha with -O3

[dhowells at redhat dot com]

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

--- Comment #1 from dhowells at redhat dot com  ---
The backtrace was obtained from a compiler built from unpatched gcc sources
produced from a gcc SVN branch with the following parameters:

SVNREV 225895
DATE 20150716
gcc_version 5.2.1

The compiler was configured as follows:

CC=gcc \
CXX=g++ \
CFLAGS='-O2 -g -Wall -Wformat-security -fexceptions -fstack-protector-strong
--param=ssp-buffer-size=4 -grecord-gcc-switches -mtune=generic' \
CXXFLAGS=' -O2 -g -Wformat-security -fstack-protector-strong
--param=ssp-buffer-size=4 -grecord-gcc-switches -mtune=generic ' \
CFLAGS_FOR_TARGET='-g -O2 -Wall -fexceptions' \
AR_FOR_TARGET=/usr/bin/alpha-linux-gnu-ar \
AS_FOR_TARGET=/usr/bin/alpha-linux-gnu-as \
DLLTOOL_FOR_TARGET=/usr/bin/alpha-linux-gnu-dlltool \
LD_FOR_TARGET=/usr/bin/alpha-linux-gnu-ld \
NM_FOR_TARGET=/usr/bin/alpha-linux-gnu-nm \
OBJDUMP_FOR_TARGET=/usr/bin/alpha-linux-gnu-objdump \
RANLIB_FOR_TARGET=/usr/bin/alpha-linux-gnu-ranlib \
READELF_FOR_TARGET=/usr/bin/alpha-linux-gnu-readelf \
STRIP_FOR_TARGET=/usr/bin/alpha-linux-gnu-strip \
WINDRES_FOR_TARGET=/usr/bin/alpha-linux-gnu-windres \
WINDMC_FOR_TARGET=/usr/bin/alpha-linux-gnu-windmc \
LDFLAGS='-Wl,-z,relro ' \
../gcc-5.2.1-20150716/configure --bindir=/usr/bin
--build=x86_64-redhat-linux-gnu --datadir=/usr/share --disable-decimal-float
--disable-dependency-tracking --disable-gold --disable-libgcj --disable-libgomp
--disable-libmudflap --disable-libquadmath --disable-libssp
--disable-libunwind-exceptions --disable-nls --disable-plugin --disable-shared
--disable-silent-rules --disable-sjlj-exceptions --disable-threads
--with-ld=/usr/bin/alpha-linux-gnu-ld --enable-__cxa_atexit
--enable-checking=release --enable-gnu-indirect-function
--enable-gnu-unique-object --enable-initfini-array --enable-languages=c,c++
--enable-linker-build-id --enable-nls --enable-obsolete --enable-plugin
--enable-targets=all --exec-prefix=/usr --host=x86_64-redhat-linux-gnu
--includedir=/usr/include --infodir=/usr/share/info --libexecdir=/usr/libexec
--localstatedir=/var --mandir=/usr/share/man --prefix=/usr
--program-prefix=alpha-linux-gnu- --sbindir=/usr/sbin --sharedstatedir=/var/lib
--sysconfdir=/etc --target=alpha-linux-gnu
--with-bugurl=http://bugzilla.redhat.com/bugzilla/ --with-isl
--with-linker-hash-style=gnu --with-newlib
--with-sysroot=/usr/alpha-linux-gnu/sys-root --with-system-libunwind
--with-system-zlib --without-headers

The binutils was a 2.25.1 cross hosted on x86_64 and targetted at
alpha-linux-gnu.

[Bug target/68538] New: ICE in gen_reg_rtx, at emit-rtl.c:1027 when cross-compiling for cris-linux-gnu target

[dhowells at redhat dot com]

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

Bug ID: 68538
   Summary: ICE in gen_reg_rtx, at emit-rtl.c:1027 when
cross-compiling for cris-linux-gnu target
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dhowells at redhat dot com
  Target Milestone: ---

Created attachment 36834
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36834&action=edit
Test program

I'm getting the following when compiling for a cris-linux-gnu target with
gcc-5.2.1:

warthog>cris-linux-gnu-gcc -O2 -c output.c
output.c: In function ‘cfq_completed_request’:
output.c:51:1: internal compiler error: in gen_reg_rtx, at emit-rtl.c:1027
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://bugzilla.redhat.com/bugzilla/> for instructions.
Preprocessed source stored into /tmp/cc89FntN.out file, please attach this to
your bugreport.

A testcase is attached.

[Bug target/68538] ICE in gen_reg_rtx, at emit-rtl.c:1027 when cross-compiling for cris-linux-gnu target

[dhowells at redhat dot com]

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

--- Comment #1 from dhowells at redhat dot com  ---
The cross-compiler was built from unpatched gcc sources produced from a gcc SVN
branch with the following parameters:

DATE 20151104
SVNREV 229753
gcc_version 5.2.1

The compiler was configured as:

CXXFLAGS=' -O2 -g -Wformat-security -fstack-protector-strong
--param=ssp-buffer-size=4 -grecord-gcc-switches -mtune=generic ' \
CFLAGS_FOR_TARGET='-g -O2 -Wall -fexceptions' \
AR_FOR_TARGET=/usr/bin/cris-linux-gnu-ar \
AS_FOR_TARGET=/usr/bin/cris-linux-gnu-as \
DLLTOOL_FOR_TARGET=/usr/bin/cris-linux-gnu-dlltool \
LD_FOR_TARGET=/usr/bin/cris-linux-gnu-ld \
NM_FOR_TARGET=/usr/bin/cris-linux-gnu-nm \
OBJDUMP_FOR_TARGET=/usr/bin/cris-linux-gnu-objdump \
RANLIB_FOR_TARGET=/usr/bin/cris-linux-gnu-ranlib \
READELF_FOR_TARGET=/usr/bin/cris-linux-gnu-readelf \
STRIP_FOR_TARGET=/usr/bin/cris-linux-gnu-strip \
WINDRES_FOR_TARGET=/usr/bin/cris-linux-gnu-windres \
WINDMC_FOR_TARGET=/usr/bin/cris-linux-gnu-windmc \
LDFLAGS='-Wl,-z,relro ' \
../gcc-5.2.1-20151104/configure --bindir=/usr/bin
--build=x86_64-redhat-linux-gnu --datadir=/usr/share --disable-decimal-float
--disable-dependency-tracking --disable-gold --disable-libgcj --disable-libgomp
--disable-libmudflap --disable-libquadmath --disable-libssp
--disable-libunwind-exceptions --disable-nls --disable-plugin --disable-shared
--disable-silent-rules --disable-sjlj-exceptions --disable-threads
--with-ld=/usr/bin/cris-linux-gnu-ld --enable-__cxa_atexit
--enable-checking=release --enable-gnu-indirect-function
--enable-gnu-unique-object --enable-initfini-array --enable-languages=c,c++
--enable-linker-build-id --enable-nls --enable-obsolete --enable-plugin
--enable-targets=all --exec-prefix=/usr --host=x86_64-redhat-linux-gnu
--includedir=/usr/include --infodir=/usr/share/info --libexecdir=/usr/libexec
--localstatedir=/var --mandir=/usr/share/man --prefix=/usr
--program-prefix=cris-linux-gnu- --sbindir=/usr/sbin --sharedstatedir=/var/lib
--sysconfdir=/etc --target=cris-linux-gnu
--with-bugurl=http://bugzilla.redhat.com/bugzilla/ --with-isl
--with-linker-hash-style=gnu --with-newlib
--with-sysroot=/usr/cris-linux-gnu/sys-root --with-system-libunwind
--with-system-zlib --without-headers

And built with:

AR_FOR_TARGET=/usr/bin/cris-linux-gnu-ar \
AS_FOR_TARGET=/usr/bin/cris-linux-gnu-as \
DLLTOOL_FOR_TARGET=/usr/bin/cris-linux-gnu-dlltool \
LD_FOR_TARGET=/usr/bin/cris-linux-gnu-ld \
NM_FOR_TARGET=/usr/bin/cris-linux-gnu-nm \
OBJDUMP_FOR_TARGET=/usr/bin/cris-linux-gnu-objdump \
RANLIB_FOR_TARGET=/usr/bin/cris-linux-gnu-ranlib \
READELF_FOR_TARGET=/usr/bin/cris-linux-gnu-readelf \
STRIP_FOR_TARGET=/usr/bin/cris-linux-gnu-strip \
WINDRES_FOR_TARGET=/usr/bin/cris-linux-gnu-windres \
WINDMC_FOR_TARGET=/usr/bin/cris-linux-gnu-windmc \
make -C cris-linux-gnu -j5 tooldir=/usr all-gcc
make -C cris-linux-gnu -j5 tooldir=/usr all-target-libgcc

The binutils was 2.25.1 built as a cross for cris-linux-gnu.

[Bug c/65052] ICE in c6x-uclinux target when building libgcc

[dhowells at redhat dot com]

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

--- Comment #1 from dhowells at redhat dot com  ---
This can be produced by the following minimal source:

typedef int DItype __attribute__ ((mode (DI)));
typedef int shift_count_type __attribute__((mode (__libgcc_shift_count__)));
int __gnu_lshrdi3 (DItype u, shift_count_type b)
{
  if (b == 0)
return u;
}

[Bug c/65052] New: ICE in c6x-uclinux target when building libgcc

[dhowells at redhat dot com]

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

Bug ID: 65052
   Summary: ICE in c6x-uclinux target when building libgcc
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dhowells at redhat dot com

When building libgcc using a c6x-uclinux gcc-5 that I've just built, I see the
following ICE:

/data/fedora/cross-gcc/tmp/build/./gcc/xgcc
-B/data/fedora/cross-gcc/tmp/build/./gcc/ -B/usr/c6x-uclinux/bin/
-B/usr/c6x-uclinux/lib/ -isystem /usr/c6x-uclinux/include -isystem
/usr/c6x-uclinux/sys-include-O2 -g -Wall -fexceptions
-fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches
-mbig-endian -O2  -O2 -g -Wall -fexceptions -fstack-protector-strong
--param=ssp-buffer-size=4 -grecord-gcc-switches  -DIN_GCC 
-DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition 
-isystem ./include   -msdata=none -msdata=none -fPIC -g -DIN_LIBGCC2
-fbuilding-libgcc -fno-stack-protector -Dinhibit_libc  -msdata=none
-msdata=none -fPIC -I. -I. -I../../.././gcc
-I../../../../gcc-5.0.0-20150210/libgcc
-I../../../../gcc-5.0.0-20150210/libgcc/.
-I../../../../gcc-5.0.0-20150210/libgcc/../gcc
-I../../../../gcc-5.0.0-20150210/libgcc/../include  -DHAVE_CC_TLS -DUSE_EMUTLS
-o _lshrdi3.o -MT _lshrdi3.o -MD -MP -MF _lshrdi3.dep -DL_lshrdi3 -c
../../../../gcc-5.0.0-20150210/libgcc/libgcc2.c -fvisibility=hidden
-DHIDE_EXPORTS
../../../../gcc-5.0.0-20150210/libgcc/libgcc2.c: In function '__gnu_lshrdi3':
../../../../gcc-5.0.0-20150210/libgcc/libgcc2.c:426:1: error: insn does not
satisfy its constraints:
 }
 ^
(insn 86 72 8 2 (cond_exec (eq (reg:SI 0 A0)
(const_int 0 [0]))
(unspec [
(label_ref:SI 36)
(const_int 0 [0])
] UNSPEC_REAL_JUMP))
../../../../gcc-5.0.0-20150210/libgcc/libgcc2.c:405 439 {*p real_jump}
 (nil))
../../../../gcc-5.0.0-20150210/libgcc/libgcc2.c:426:1: internal compiler error:
in extract_constrain_insn_cached, at recog.c:2258
0x885148 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc-5.0.0-20150210/gcc/rtl-error.c:110
0x88516f _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc-5.0.0-20150210/gcc/rtl-error.c:121
0x85d159 extract_constrain_insn_cached(rtx_insn*)
../../gcc-5.0.0-20150210/gcc/recog.c:2258
0xb0cb77 internal_dfa_insn_code(rtx_insn*)
../../gcc-5.0.0-20150210/gcc/config/c6x/c6x.md:407
0xb0be79 dfa_insn_code
/data/fedora/cross-gcc/tmp/build/gcc/insn-automata.c:735634
0xb0be79 state_transition(void*, rtx_def*)
/data/fedora/cross-gcc/tmp/build/gcc/insn-automata.c:735655
0xbbe910 prune_ready_list
../../gcc-5.0.0-20150210/gcc/haifa-sched.c:6278
0xbbf907 prune_ready_list
../../gcc-5.0.0-20150210/gcc/haifa-sched.c:6193
0xbbf907 schedule_block(basic_block_def**, void*)
../../gcc-5.0.0-20150210/gcc/haifa-sched.c:6604
0xc14e06 schedule_ebb(rtx_insn*, rtx_insn*, bool)
../../gcc-5.0.0-20150210/gcc/sched-ebb.c:557
0xc15516 schedule_ebbs()
../../gcc-5.0.0-20150210/gcc/sched-ebb.c:676
0xb0435b c6x_reorg
../../gcc-5.0.0-20150210/gcc/config/c6x/c6x.c:5998
0x883fb9 execute
../../gcc-5.0.0-20150210/gcc/reorg.c:4064
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://bugzilla.redhat.com/bugzilla/> for instructions.
Makefile:466: recipe for target '_lshrdi3.o' failed
make[3]: *** [_lshrdi3.o] Error 1
make[3]: Leaving directory
'/data/fedora/cross-gcc/tmp/build/c6x-uclinux/be/libgcc'

[Bug c/65052] ICE in c6x-uclinux target when building libgcc

[dhowells at redhat dot com]

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

--- Comment #2 from dhowells at redhat dot com  ---
Compiled with:

/data/fedora/cross-gcc/tmp/build/./gcc/xgcc
-B/data/fedora/cross-gcc/tmp/build/gcc/ -B/usr/c6x-uclinux/bin/ -O2 -c min.i

[Bug c/65052] ICE in c6x-uclinux target when building libgcc

[dhowells at redhat dot com]

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

--- Comment #3 from dhowells at redhat dot com  ---
The compiler was built as:

#!/bin/bash

cd /data/fedora/cross-gcc/tmp/
tar xf /tmp/gcc-5.0.0-20150210.tar.bz2
mkdir build
cd build

CC=gcc \
CXX=g++ \
CFLAGS='-O2 -g -Wall -fexceptions -fstack-protector-strong
--param=ssp-buffer-size=4 -grecord-gcc-switches -mtune=generic' \
CXXFLAGS=' -O2 -g -Wformat -fstack-protector-strong --param=ssp-buffer-size=4
-grecord-gcc-switches -mtune=generic ' \
CFLAGS_FOR_TARGET=' -O2 -g -Wall -fexceptions -fstack-protector-strong
--param=ssp-buffer-size=4 -grecord-gcc-switches ' \
AR_FOR_TARGET=/usr/bin/c6x-linux-gnu-ar \
AS_FOR_TARGET=/usr/bin/c6x-linux-gnu-as \
DLLTOOL_FOR_TARGET=/usr/bin/c6x-linux-gnu-dlltool \
LD_FOR_TARGET=/usr/bin/c6x-linux-gnu-ld \
NM_FOR_TARGET=/usr/bin/c6x-linux-gnu-nm \
OBJDUMP_FOR_TARGET=/usr/bin/c6x-linux-gnu-objdump \
RANLIB_FOR_TARGET=/usr/bin/c6x-linux-gnu-ranlib \
READELF_FOR_TARGET=/usr/bin/c6x-linux-gnu-readelf \
STRIP_FOR_TARGET=/usr/bin/c6x-linux-gnu-strip \
WINDRES_FOR_TARGET=/usr/bin/c6x-linux-gnu-windres \
WINDMC_FOR_TARGET=/usr/bin/c6x-linux-gnu-windmc \
LDFLAGS='-Wl,-z,relro ' \
nice -19 ../gcc-5.0.0-20150210/configure \
--bindir=/usr/bin \
--build=x86_64-redhat-linux-gnu \
--datadir=/usr/share \
--disable-decimal-float \
--disable-dependency-tracking \
--disable-gold \
--disable-libgcj \
--disable-libgomp \
--disable-libmudflap \
--disable-libquadmath \
--disable-libssp \
--disable-libunwind-exceptions \
--disable-nls \
--disable-plugin \
--disable-shared \
--disable-silent-rules \
--disable-sjlj-exceptions \
--disable-threads \
--with-ld=/usr/bin/c6x-linux-gnu-ld \
--enable-__cxa_atexit \
--enable-checking=release \
--enable-gnu-indirect-function \
--enable-gnu-unique-object \
--enable-initfini-array \
--enable-languages=c,c++ \
--enable-linker-build-id \
--enable-nls \
--enable-obsolete \
--enable-plugin \
--enable-targets=all \
--exec-prefix=/usr \
--host=x86_64-redhat-linux-gnu \
--includedir=/usr/include \
--infodir=/usr/share/info \
--libexecdir=/usr/libexec \
--localstatedir=/var \
--mandir=/usr/share/man \
--prefix=/usr \
--program-prefix=c6x-linux-gnu- \
--sbindir=/usr/sbin \
--sharedstatedir=/var/lib \
--sysconfdir=/etc \
--target=c6x-uclinux \
--with-bugurl=http://bugzilla.redhat.com/bugzilla/ \
--with-isl \
--with-linker-hash-style=gnu \
--with-newlib \
--with-sysroot=/usr/c6x-linux-gnu/sys-root \
--with-system-libunwind \
--with-system-zlib \
--without-headers

echo "=== BUILDING c6x-linux"
AR_FOR_TARGET=/usr/bin/c6x-linux-gnu-ar \
AS_FOR_TARGET=/usr/bin/c6x-linux-gnu-as \
DLLTOOL_FOR_TARGET=/usr/bin/c6x-linux-gnu-dlltool \
LD_FOR_TARGET=/usr/bin/c6x-linux-gnu-ld \
NM_FOR_TARGET=/usr/bin/c6x-linux-gnu-nm \
OBJDUMP_FOR_TARGET=/usr/bin/c6x-linux-gnu-objdump \
RANLIB_FOR_TARGET=/usr/bin/c6x-linux-gnu-ranlib \
READELF_FOR_TARGET=/usr/bin/c6x-linux-gnu-readelf \
STRIP_FOR_TARGET=/usr/bin/c6x-linux-gnu-strip \
WINDRES_FOR_TARGET=/usr/bin/c6x-linux-gnu-windres \
WINDMC_FOR_TARGET=/usr/bin/c6x-linux-gnu-windmc \
nice -19 make tooldir=/usr all-gcc

echo "=== BUILDING LIBGCC c6x-linux"
nice -19 make tooldir=/bin all-target-libgcc


---
binutils-2.25 was used for the cross compiler.

The compiler was built with:

gcc version 4.9.2 20141101 (Red Hat 4.9.2-1) (GCC)
binutils-2.24

[Bug target/61737] New: ICE when building libgcc for cris cross-compiler

[dhowells at redhat dot com]

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

Bug ID: 61737
   Summary: ICE when building libgcc for cris cross-compiler
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dhowells at redhat dot com

Created attachment 33082
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33082&action=edit
Reduced preprocessed source that induces the error message

When trying to build a cross-compiler for cris with libgcc, I get the following
error and several others like it (make -j is in operation) during the compiler
build:

/data/fedora/cross-gcc/gcc-4.9.0-20140702/cris-linux-gnu/./gcc/xgcc
-B/data/fedora/cross-gcc/gcc-4.9.0-20140702/cris-linux-gnu/./gcc/
-B/usr/cris-linux-gnu/bin/ -B/usr/cris-linux-gnu/lib/ -isystem
/usr/cris-linux-gnu/include -isystem /usr/cris-linux-gnu/sys-include-g -O2
-O2  -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include   -fPIC -g -DIN_LIBGCC2
-fbuilding-libgcc -fno-stack-protector -Dinhibit_libc  -fPIC -I. -I.
-I../.././gcc -I../../../gcc-4.9.0-20140702/libgcc
-I../../../gcc-4.9.0-20140702/libgcc/.
-I../../../gcc-4.9.0-20140702/libgcc/../gcc
-I../../../gcc-4.9.0-20140702/libgcc/../include  -DHAVE_CC_TLS -DUSE_EMUTLS -o
_subvsi3.o -MT _subvsi3.o -MD -MP -MF _subvsi3.dep -DL_subvsi3 -c
../../../gcc-4.9.0-20140702/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS
../../../gcc-4.9.0-20140702/libgcc/libgcc2.c: In function ‘__subvsi3’:
../../../gcc-4.9.0-20140702/libgcc/libgcc2.c:122:1: error: unrecognizable insn:
 }
 ^
(call_insn 27 26 28 7 (parallel [
(call (mem:QI (symbol_ref:SI ("abort") [flags 0x41] ) [0 __builtin_abort S1 A8])
(const_int 0 [0]))
(clobber (reg:SI 16 srp))
]) ../../../gcc-4.9.0-20140702/libgcc/libgcc2.c:119 -1
 (expr_list:REG_NORETURN (const_int 0 [0])
(expr_list:REG_EH_REGION (const_int 0 [0])
(nil)))
(nil))
../../../gcc-4.9.0-20140702/libgcc/libgcc2.c:122:1: internal compiler error: in
extract_insn, at recog.c:2202
0x71c16a _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc-4.9.0-20140702/gcc/rtl-error.c:109
0x71c199 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc-4.9.0-20140702/gcc/rtl-error.c:117
0x6ee18a extract_insn(rtx_def*)
../../gcc-4.9.0-20140702/gcc/recog.c:2202
0x5d08d0 instantiate_virtual_regs_in_insn
../../gcc-4.9.0-20140702/gcc/function.c:1607
0x5d08d0 instantiate_virtual_regs
../../gcc-4.9.0-20140702/gcc/function.c:1925
0x5d08d0 execute
../../gcc-4.9.0-20140702/gcc/function.c:1975
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://bugzilla.redhat.com/bugzilla/> for instructions.
The bug is not reproducible, so it is likely a hardware or OS problem.


I'm also very intrigued by that last line - I can reproduce it quite easily.

Anyway, I've added a reduced libgcc2.i that causes the error to occur.  I don't
think it'll help because you need the intermediate-stage compiler binaries
also.

System gcc being used to build the cross-compiler:
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.2/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin
--enable-initfini-array --enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-isl=/builddir/build/BUILD/gcc-4.8.2-20131212/obj-x86_64-redhat-linux/isl-install
--with-cloog=/builddir/build/BUILD/gcc-4.8.2-20131212/obj-x86_64-redhat-linux/cloog-install
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.8.2 20131212 (Red Hat 4.8.2-7) (GCC)

[Bug target/61737] ICE when building libgcc for cris cross-compiler

[dhowells at redhat dot com]

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

--- Comment #1 from dhowells at redhat dot com  ---
I needed the following change to gcc (courtesy of Nick Clifton) to get cris-gcc
to build at all, even without libgcc:

Index: gcc/config.gcc
===
--- gcc/config.gcc
+++ gcc/config.gcc
@@ -1130,7 +1130,7 @@
 crisv32-*-linux* | cris-*-linux*)
 tm_file="dbxelf.h elfos.h ${tm_file} gnu-user.h linux.h glibc-stdint.h
cris/linux.h"
 # We need to avoid using t-linux, so override default tmake_file
-tmake_file="cris/t-cris cris/t-linux t-slibgcc t-linux"
+tmake_file="${tmake_file} cris/t-cris cris/t-linux t-slibgcc"
 extra_options="${extra_options} cris/linux.opt"
 case $target in
   cris-*-*)

This behaviour can be produced with the SVNREV 212237 (2014-07-02) gcc-4.9.0
compiler tarball plus one patch and then the following config:

AR_FOR_TARGET=/usr/bin/cris-linux-gnu-ar \
AS_FOR_TARGET=/usr/bin/cris-linux-gnu-as \
DLLTOOL_FOR_TARGET=/usr/bin/cris-linux-gnu-dlltool \
LD_FOR_TARGET=/usr/bin/cris-linux-gnu-ld \
NM_FOR_TARGET=/usr/bin/cris-linux-gnu-nm \
OBJDUMP_FOR_TARGET=/usr/bin/cris-linux-gnu-objdump \
RANLIB_FOR_TARGET=/usr/bin/cris-linux-gnu-ranlib \
STRIP_FOR_TARGET=/usr/bin/cris-linux-gnu-strip \
WINDRES_FOR_TARGET=/usr/bin/cris-linux-gnu-windres \
WINDMC_FOR_TARGET=/usr/bin/cris-linux-gnu-windmc \
LDFLAGS='-Wl,-z,relro ' \
../gcc-4.9.0-20140702/configure --bindir=/usr/bin
--build=x86_64-redhat-linux-gnu \
  --datadir=/usr/share --disable-decimal-float --disable-dependency-tracking \
  --disable-gold --disable-libgomp --disable-libmudflap --disable-libquadmath \
  --disable-libssp --disable-nls --disable-plugin --disable-shared \
  --disable-silent-rules --disable-sjlj-exceptions --disable-threads \
  --enable-checking= --enable-gnu-unique-object --enable-initfini-array \
  --enable-languages=c,c++ --enable-linker-build-id --enable-nls
--enable-obsolete \
  --enable-targets=all --exec-prefix=/usr --host=x86_64-redhat-linux-gnu \
  --includedir=/usr/include --infodir=/usr/share/info --libexecdir=/usr/libexec
\
  --localstatedir=/var --mandir=/usr/share/man --prefix=/usr \
  --program-prefix=cris-linux-gnu- --sbindir=/usr/sbin
--sharedstatedir=/var/lib \
  --sysconfdir=/etc --target=cris-linux-gnu \
  --with-bugurl=http://bugzilla.redhat.com/bugzilla/ \
  --with-linker-hash-style=gnu --with-newlib
--with-sysroot=/usr/cris-linux-gnu/sys-root \
  --with-system-libunwind --with-system-zlib --without-headers --without-isl \
  --without-cloog

The binutils is:
cris-linux-gnu-as -v
GNU assembler version 2.24.0 (cris-linux-gnu) using BFD version version
2.24.0-4.fc20 20140613

The compiler is built with:
AR_FOR_TARGET=/usr/bin/cris-linux-gnu-ar \
AS_FOR_TARGET=/usr/bin/cris-linux-gnu-as \
DLLTOOL_FOR_TARGET=/usr/bin/cris-linux-gnu-dlltool \
LD_FOR_TARGET=/usr/bin/cris-linux-gnu-ld \
NM_FOR_TARGET=/usr/bin/cris-linux-gnu-nm \
OBJDUMP_FOR_TARGET=/usr/bin/cris-linux-gnu-objdump \
RANLIB_FOR_TARGET=/usr/bin/cris-linux-gnu-ranlib \
STRIP_FOR_TARGET=/usr/bin/cris-linux-gnu-strip \
WINDRES_FOR_TARGET=/usr/bin/cris-linux-gnu-windres \
WINDMC_FOR_TARGET=/usr/bin/cris-linux-gnu-windmc \
make -C cris-linux-gnu tooldir=/usr all-gcc

libgcc is built with:
make -C cris-linux-gnu tooldir=/usr all-target-libgcc

[Bug target/61737] ICE when building libgcc for cris cross-compiler

[dhowells at redhat dot com]

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

--- Comment #2 from dhowells at redhat dot com  ---
This also appears to occur for --target=sh64-linux on an unpatched gcc tree.

[Bug target/61737] ICE when building libgcc for cris cross-compiler

[dhowells at redhat dot com]

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

--- Comment #10 from dhowells at redhat dot com  ---
(In reply to Hans-Peter Nilsson from comment #7)
> (In reply to dhowe...@redhat.com from comment #0)
> > I'm also very intrigued by that last line - I can reproduce it quite easily.
> 
> This is a RH local patch in your host gcc (by Jakub, IIRC) to help users
> re-running the actual ICEing command adding -save-temps.  I'm guessing it
> has a bug and accidentally drops some option required to reproduce the ICE...

It's in the gcc-4.9.0-20140702 tarball.

[Bug target/61737] ICE when building libgcc for cris cross-compiler

[dhowells at redhat dot com]

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

--- Comment #11 from dhowells at redhat dot com  ---
(In reply to Hans-Peter Nilsson from comment #3)
> > libgcc is built with:
> > make -C cris-linux-gnu tooldir=/usr all-target-libgcc
> 
> I'd expect "make all-target-libgcc" to Just Work.

So would I.  However, it doesn't work for all arches that the SRPM builds a
cross-compiler for.  I need the compiler to build the kernel, but not normally
libgcc, however, I've been asked to build libgcc if I can.  The arches for
which I can't build libgcc include: cris, sh, sh64 and tile.

[Bug target/61737] ICE when building libgcc for cris cross-compiler

[dhowells at redhat dot com]

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

--- Comment #12 from dhowells at redhat dot com  ---
(In reply to Hans-Peter Nilsson from comment #6)
> Created attachment 33121 [details]
> Patch to config.gcc
> 
> Correct patch to config.gcc required to actually build the compiler proper.

Okay, I've tried that.  I can't see that it makes any obvious difference.  Is
there something I should look for?

[Bug c/61812] New: gcc ICE says "The bug is not reproducible, so it is likely a hardware or OS problem."

[dhowells at redhat dot com]

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

Bug ID: 61812
   Summary: gcc ICE says "The bug is not reproducible, so it is
likely a hardware or OS problem."
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dhowells at redhat dot com

gcc ICE says "The bug is not reproducible, so it is likely a hardware or OS
problem." at the end - even when this isn't true.

[Bug c/61812] gcc ICE incorrectly says "The bug is not reproducible, so it is likely a hardware or OS problem."

[dhowells at redhat dot com]

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

--- Comment #1 from dhowells at redhat dot com  ---
For an example ICE, see: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61737

This is easily reproducible, so the line is incorrect.  It might be better
stated conditionally:

"If the bug is not reproducible, it is likely a hardware or OS problem."

[Bug target/61737] ICE when building libgcc for cris cross-compiler

[dhowells at redhat dot com]

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

--- Comment #15 from dhowells at redhat dot com  ---
(In reply to Hans-Peter Nilsson from comment #14)
> Could you please consider open a separate PR for the "is not reproducible"
> misdisagnosis?

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

[Bug c/61812] gcc ICE incorrectly says "The bug is not reproducible, so it is likely a hardware or OS problem."

[dhowells at redhat dot com]

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

--- Comment #3 from dhowells at redhat dot com  ---
Hmmm... It appears you're right.  The 'upstream tarball' in the Fedora gcc SRPM
seems already to be altered from what's upstream - even before the spec file
applies any patches to it.  I wonder where it is coming from.

[Bug c/61812] gcc ICE incorrectly says "The bug is not reproducible, so it is likely a hardware or OS problem."

[dhowells at redhat dot com]

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

--- Comment #5 from dhowells at redhat dot com  ---
(In reply to Andrew Pinski from comment #4)
> Also even though it might be a true gcc issue, it does not say it is a
> hardware issue, the message says likely. This could also mean a gc or a
> memory issue inside gcc. Except detecting that vs a memory issue is much
> harder.

It's a bug with the code on the redhat/ branch that generates this message. 
The problem is that when it detects an ICE, the gcc driver runs the cc1 binary
twice more and compares the output - but the output contains a userspace
pointer from within gcc itself, eg:

(call (mem:QI (symbol_ref:SI ("abort") [flags 0x41] ) [0 __builtin_abort S1 A8])


and this may legitimately differ due to the kernel mapping things in different
places during execve() and mmap().

[Bug target/61737] ICE when building libgcc for cris cross-compiler

[dhowells at redhat dot com]

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

--- Comment #19 from dhowells at redhat dot com  ---
This seems to have done the trick, thanks!

[Bug c/61844] New: ICE when building libgcc for sh64 cross-compiler

[dhowells at redhat dot com]

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

Bug ID: 61844
   Summary: ICE when building libgcc for sh64 cross-compiler
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dhowells at redhat dot com

When trying to build a cross-compiler for sh64 with libgcc, I get the following
error and several others like it (make -j is in operation) during the compiler
build:

/data/fedora/cross-gcc/gcc-4.9.0-20140702/sh64-linux-gnu/./gcc/xgcc
-B/data/fedora/cross-gcc/gcc-4.9.0-20140702/sh64-linux-gnu/./gcc/
-B/usr/sh64-linux/bin/ -B/usr/sh64-linux/lib/ -isystem /usr/sh64-linux/include
-isystem /usr/sh64-linux/sys-include-g -O2 -mb -O2  -g -O2 -DIN_GCC 
-DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition 
-isystem ./include   -fpic -DNO_FPSCR_VALUES -w -Wno-sync-nand -g -DIN_LIBGCC2
-fbuilding-libgcc -fno-stack-protector -Dinhibit_libc  -fpic -DNO_FPSCR_VALUES
-w -Wno-sync-nand -I. -I. -I../../.././gcc
-I../../../../gcc-4.9.0-20140702/libgcc
-I../../../../gcc-4.9.0-20140702/libgcc/.
-I../../../../gcc-4.9.0-20140702/libgcc/../gcc
-I../../../../gcc-4.9.0-20140702/libgcc/../include  -DHAVE_CC_TLS -DUSE_EMUTLS
-o _addvsi3.o -MT _addvsi3.o -MD -MP -MF _addvsi3.dep -DL_addvsi3 -c
../../../../gcc-4.9.0-20140702/libgcc/libgcc2.c -fvisibility=hidden
-DHIDE_EXPORTS
../../../../gcc-4.9.0-20140702/libgcc/libgcc2.c: In function ‘__addvsi3’:
../../../../gcc-4.9.0-20140702/libgcc/libgcc2.c:84:1: error: insn does not
satisfy its constraints:
 }
 ^
(insn 27 51 52 3 (set (reg:SI 1 r1 [172])
(mem/c:SI (plus:SI (reg:SI 2 r2)
(reg:SI 12 r12)) [0  S4 A32]))
../../../../gcc-4.9.0-20140702/libgcc/libgcc2.c:81 260 {*movsi_media}
 (nil))
../../../../gcc-4.9.0-20140702/libgcc/libgcc2.c:84:1: internal compiler error:
in reload_cse_simplify_operands, at postreload.c:411
0x73b24a _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc-4.9.0-20140702/gcc/rtl-error.c:109
0x73b26f _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc-4.9.0-20140702/gcc/rtl-error.c:120
0x6f2aa0 reload_cse_simplify_operands
../../gcc-4.9.0-20140702/gcc/postreload.c:411
0x6f48cc reload_cse_simplify
../../gcc-4.9.0-20140702/gcc/postreload.c:181
0x6f48cc reload_cse_regs_1
../../gcc-4.9.0-20140702/gcc/postreload.c:220
0x6f4cbb reload_cse_regs
../../gcc-4.9.0-20140702/gcc/postreload.c:68
0x6f4cbb rest_of_handle_postreload
../../gcc-4.9.0-20140702/gcc/postreload.c:2332
0x6f4cbb execute
../../gcc-4.9.0-20140702/gcc/postreload.c:2368
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://bugzilla.redhat.com/bugzilla/> for instructions.
Preprocessed source stored into /tmp/cce3xHzL.out file, please attach this to
your bugreport.

The same reduced test that causes bug 61737 to ICE causes this one to ICE. 
This can be found here:

https://gcc.gnu.org/bugzilla/attachment.cgi?id=33082

[Bug c/61844] ICE when building libgcc for sh64 cross-compiler

[dhowells at redhat dot com]

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

--- Comment #1 from dhowells at redhat dot com  ---
System compiler being used:

Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.3/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin
--enable-initfini-array --enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-isl=/builddir/build/BUILD/gcc-4.8.3-20140624/obj-x86_64-redhat-linux/isl-install
--with-cloog=/builddir/build/BUILD/gcc-4.8.3-20140624/obj-x86_64-redhat-linux/cloog-install
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.8.3 20140624 (Red Hat 4.8.3-1) (GCC)

[Bug c/61844] ICE when building libgcc for sh64 cross-compiler

[dhowells at redhat dot com]

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

--- Comment #2 from dhowells at redhat dot com  ---
Created attachment 33144
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33144&action=edit
Old, no-longer functional patch to libgcc

I was given the attached patch when I was on gcc-4.7 but it doesn't seem to
help with gcc-4.9.  The problem occurs with or without the patch.

[Bug c/61844] ICE when building libgcc for sh64 cross-compiler

[dhowells at redhat dot com]

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

--- Comment #3 from dhowells at redhat dot com  ---
The compiler is configured thusly:

AR_FOR_TARGET=/usr/bin/sh64-linux-gnu-ar \
AS_FOR_TARGET=/usr/bin/sh64-linux-gnu-as \
DLLTOOL_FOR_TARGET=/usr/bin/sh64-linux-gnu-dlltool \
LD_FOR_TARGET=/usr/bin/sh64-linux-gnu-ld \
NM_FOR_TARGET=/usr/bin/sh64-linux-gnu-nm \
OBJDUMP_FOR_TARGET=/usr/bin/sh64-linux-gnu-objdump \
RANLIB_FOR_TARGET=/usr/bin/sh64-linux-gnu-ranlib \
STRIP_FOR_TARGET=/usr/bin/sh64-linux-gnu-strip \
WINDRES_FOR_TARGET=/usr/bin/sh64-linux-gnu-windres \
WINDMC_FOR_TARGET=/usr/bin/sh64-linux-gnu-windmc \
LDFLAGS='-Wl,-z,relro ' \
../gcc-4.9.0-20140702/configure --bindir=/usr/bin
--build=x86_64-redhat-linux-gnu --datadir=/usr/share --disable-decimal-float
--disable-dependency-tracking --disable-gold --disable-libgomp
--disable-libmudflap --disable-libquadmath --disable-libssp --disable-nls
--disable-plugin --disable-shared --disable-silent-rules
--disable-sjlj-exceptions --disable-threads --enable-checking=
--enable-gnu-unique-object --enable-initfini-array --enable-languages=c,c++
--enable-linker-build-id --enable-nls --enable-obsolete --enable-targets=all
--exec-prefix=/usr --host=x86_64-redhat-linux-gnu --includedir=/usr/include
--infodir=/usr/share/info --libexecdir=/usr/libexec --localstatedir=/var
--mandir=/usr/share/man --prefix=/usr --program-prefix=sh64-linux-gnu-
--sbindir=/usr/sbin --sharedstatedir=/var/lib --sysconfdir=/etc
--target=sh64-linux --with-bugurl=http://bugzilla.redhat.com/bugzilla/
--with-linker-hash-style=gnu --with-newlib
--with-sysroot=/usr/sh64-linux-gnu/sys-root --with-system-libunwind
--with-system-zlib --without-headers --without-isl --without-cloog
--with-multilib-list=m5-32media,m5-32media-nofpu,m5-compact,m5-compact-nofpu,m5-64media,m5-64media-nofpu

The binutils is:
sh64-linux-gnu-as -v
GNU assembler version 2.24.0 (sh64-linux) using BFD version version
2.24.0-4.fc20 20140613

The compiler is built:

AR_FOR_TARGET=/usr/bin/sh64-linux-gnu-ar \
AS_FOR_TARGET=/usr/bin/sh64-linux-gnu-as \
DLLTOOL_FOR_TARGET=/usr/bin/sh64-linux-gnu-dlltool \
LD_FOR_TARGET=/usr/bin/sh64-linux-gnu-ld \
NM_FOR_TARGET=/usr/bin/sh64-linux-gnu-nm \
OBJDUMP_FOR_TARGET=/usr/bin/sh64-linux-gnu-objdump \
RANLIB_FOR_TARGET=/usr/bin/sh64-linux-gnu-ranlib \
STRIP_FOR_TARGET=/usr/bin/sh64-linux-gnu-strip \
WINDRES_FOR_TARGET=/usr/bin/sh64-linux-gnu-windres \
WINDMC_FOR_TARGET=/usr/bin/sh64-linux-gnu-windmc \
make -C sh64-linux-gnu -j12 tooldir=/usr all-gcc

Then libgcc is built:

make -C sh64-linux-gnu -j12 tooldir=/usr all-target-libgcc

[Bug c/61844] ICE when building libgcc for sh64 cross-compiler

[dhowells at redhat dot com]

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

--- Comment #4 from dhowells at redhat dot com  ---
This behaviour can be produced with the SVNREV 212237 (2014-07-02) gcc-4.9.0
compiler tarball and no extra patches.

[Bug c/61844] ICE when building libgcc for sh64 cross-compiler

[dhowells at redhat dot com]

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

--- Comment #5 from dhowells at redhat dot com  ---
Note that I also see a number of warnings like:

/usr/bin/sh64-linux-gnu-nm: _sdivsi3_s.o: File format is ambiguous