[Bug target/69401] gcc 5.3.0/6.1.0 on microblaze: internal compiler error: in gen_reg_rtx, at emit-rtl.c:1027

[thomas.petazz...@free-electrons.com]

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

--- Comment #6 from Thomas Petazzoni  ---
I see Eric Gallager added bug 68538 in the "See also" section. However, I don't
see how they can be related: 68538 has been fixed, and the fix was only in
CRIS-specific files.

This bug however is only about Microblaze, so I don't see how it can be related
to a bug that was fixed in CRIS-specific code.

[Bug target/71124] New: Compiler enters infinite loop on Microblaze with -O1/-O2/-O3

[thomas.petazz...@free-electrons.com]

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

Bug ID: 71124
   Summary: Compiler enters infinite loop on Microblaze with
-O1/-O2/-O3
   Product: gcc
   Version: 4.9.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thomas.petazz...@free-electrons.com
  Target Milestone: ---

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

The attached preprocessed C++ file (generated from the assimp project) causes
g++ 4.9.3 to enter an infinite loop if an optimization level of -O1, -O2 or -O3
is used. With no optimization flags, or with the -Os flag, the compiler works
fine.

I.e:

microblazeel-linux-g++ -O1 -c test.cpp
microblazeel-linux-g++ -O2 -c test.cpp
microblazeel-linux-g++ -O3 -c test.cpp

never terminate.

While:

microblazeel-linux-g++ -c test.cpp
microblazeel-linux-g++ -Os -c test.cpp

terminate properly.

[Bug target/71124] Compiler enters infinite loop on Microblaze with -O1/-O2/-O3

[thomas.petazz...@free-electrons.com]

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

Thomas Petazzoni  changed:

   What|Removed |Added

Version|4.9.3   |6.1.0

--- Comment #1 from Thomas Petazzoni  ---
This bug still exists with gcc 6.1.0, in the same condition (same test case,
same architecture, same optimization levels that work / don't work).

[Bug target/69401] gcc 5.3.0 on microblaze: internal compiler error: in gen_reg_rtx, at emit-rtl.c:1027

[thomas.petazz...@free-electrons.com]

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

--- Comment #2 from Thomas Petazzoni  ---
This still happens with gcc 6.1. With gcc 6.1:

 - The file can be built with no optimization, with and without -fPIC
 - The file can be built in -O2 or -O3 without -fPIC
 - The compiler aborts when either -O2 or -O3 is used in combination with -fPIC

I will attach an updated version of the pre-processed file, which can be used
with gcc 6. The previous version of flann was causing some unrelated build
failures with gcc 6.

[Bug target/69401] gcc 5.3.0 on microblaze: internal compiler error: in gen_reg_rtx, at emit-rtl.c:1027

[thomas.petazz...@free-electrons.com]

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

--- Comment #3 from Thomas Petazzoni  ---
Created attachment 38510
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38510&action=edit
Pre-processed source code

[Bug target/63261] Microblaze 4.9.1, Error: PC relative branch to label which is not in the instruction space

[thomas.petazz...@free-electrons.com]

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

--- Comment #1 from Thomas Petazzoni  ---
This bug still exists in gcc 5.4.0 on Microblaze.

[Bug target/69401] gcc 5.3.0/6.1.0 on microblaze: internal compiler error: in gen_reg_rtx, at emit-rtl.c:1027

[thomas.petazz...@free-electrons.com]

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

--- Comment #4 from Thomas Petazzoni  ---
Any input?

I'm facing a similar problem with the gpsd software: on gcc 6.x and gcc 7.x,
one file fails to build with an ICE:

rtcm2_json.c: In function 'json_rtcm2_read':
rtcm2_json.c:258:1: internal compiler error: in gen_reg_rtx, at emit-rtl.c:1026

You need the combination of -O2 and -fPIC for the bug to appear. If either -O2
or -fPIC are omitted, the builds works fine:

gpsd-3.16$ microblazeel-buildroot-linux-uclibc-gcc -fPIC -c -x c rtcm2_json.os 
gpsd-3.16$ microblazeel-buildroot-linux-uclibc-gcc -O2  -c -x c rtcm2_json.os 
gpsd-3.16$ microblazeel-buildroot-linux-uclibc-gcc -O2 -fPIC -c -x c
rtcm2_json.os 
rtcm2_json.c: In function 'json_rtcm2_read':
rtcm2_json.c:258:1: internal compiler error: in gen_reg_rtx, at emit-rtl.c:1026
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

I'll attach rtcm2_json.os (preprocessed source code) to ease reproduction of
the build problem.

[Bug target/69401] gcc 5.3.0/6.1.0 on microblaze: internal compiler error: in gen_reg_rtx, at emit-rtl.c:1027

[thomas.petazz...@free-electrons.com]

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

--- Comment #5 from Thomas Petazzoni  ---
Created attachment 41764
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41764&action=edit
Pre-processed code from gpsd

Code from gpsd that triggers an ICE on Microblaze when building with -O2 -fPIC.

[Bug target/71749] Define _REENTRANT on ARC when -pthread is passed

[thomas.petazz...@free-electrons.com]

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

--- Comment #3 from Thomas Petazzoni  ---
Will you submit the patch to gcc mainline yourself?

[Bug target/71749] Define _REENTRANT on ARC when -pthread is passed

[thomas.petazz...@free-electrons.com]

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

--- Comment #5 from Thomas Petazzoni  ---
Sure, feel free to submit it. If that's easier for the gcc submission process,
feel free to submit it under your own name: for such a small contribution, I
really don't care if my authorship is preserved.

[Bug target/71124] Compiler enters infinite loop on Microblaze with -O1/-O2/-O3

[thomas.petazz...@free-electrons.com]

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

--- Comment #2 from Thomas Petazzoni  ---
Created attachment 39970
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39970&action=edit
Another test case demonstration the problem

This additional test case comes from ffmpeg 3.2. This file builds fine with
-Os, but makes the compiler use 100% CPU time indefinitely with -O1, -O2 or
-O3.

[Bug middle-end/61207] Win64 gcc 4.9.0: ICE at -Os compiling some C++ code

[thomas.petazz...@free-electrons.com]

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

Thomas Petazzoni  changed:

   What|Removed |Added

 CC||thomas.petazzoni@free-elect
   ||rons.com

--- Comment #2 from Thomas Petazzoni  ---
Interestingly, I have the exact same error while compiling some C++ code in Qt5
on an ARM platform:

svg/SVGPathElement.h: In member function 'virtual WebCore::FloatRect
WebCore::SVGPathElement::_ZTv0_n24_N7WebCore14SVGPathElement7getBBoxENS_12SVGLocatable19StyleUpdateStrategyE(WebCore::SVGLocatable::StyleUpdateStrategy)':
svg/SVGPathElement.h:95:23: internal compiler error: in
expand_expr_addr_expr_1, at expr.c:7669
 virtual FloatRect getBBox(StyleUpdateStrategy = AllowStyleUpdate);
   ^
Please submit a full bug report,
with preprocessed source if appropriate.

The file is also built with -Os. This is with gcc 4.9.1.

More build output at
http://autobuild.buildroot.org/results/9fd/9fdbe9bb3bd32276f9793fa60d802756811c1abe/build-end.log.

[Bug middle-end/61207] Win64 gcc 4.9.0: ICE at -Os compiling some C++ code

[thomas.petazz...@free-electrons.com]

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

--- Comment #4 from Thomas Petazzoni  ---
(In reply to Kai Tietz from comment #3)
> Hmm, does it help to specify additional option '-fno-ms-extensions'?

No, it doesn't help. In fact in my case, it isn't a -Os problem, but a -O3
problem. I had both the compile command line, with -O3 being last. So in the
end, I tested the following cases:

* -O2 -> builds fine
* -Os -> builds fine
* -O3 -> breaks
* -O3 -fno-ms-extensions -> breaks

If you want to have a look at the code, I've put the pre-processed version of
the file at http://free-electrons.com/~thomas/pub/SVGAllInOne.cpp.xz.

I'm able to reproduce the bug under Ubuntu, using the Ubuntu ARM g++ compiler,
which uses gcc 4.9.1 :

# Default -> OK

thomas@skate:/tmp$ arm-linux-gnueabihf-g++ -c SVGAllInOne.cpp 

# -O2 -> OK

thomas@skate:/tmp$ arm-linux-gnueabihf-g++ -O2 -c SVGAllInOne.cpp 

# -Os -> OK

thomas@skate:/tmp$ arm-linux-gnueabihf-g++ -Os -c SVGAllInOne.cpp 

# -O3 -> NOK

thomas@skate:/tmp$ arm-linux-gnueabihf-g++ -O3 -c SVGAllInOne.cpp 
In file included from svg/SVGAnimateMotionElement.cpp:37:0,
 from svg/SVGAllInOne.cpp:36:
svg/SVGPathElement.h: In member function ‘virtual WebCore::FloatRect
WebCore::SVGPathElement::_ZTv0_n24_N7WebCore14SVGPathElement7getBBoxENS_12SVGLocatable19StyleUpdateStrategyE(WebCore::SVGLocatable::StyleUpdateStrategy)’:
svg/SVGPathElement.h:95:23: internal compiler error: in
expand_expr_addr_expr_1, at expr.c:7649
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Preprocessed source stored into /tmp/cccMXXZg.out file, please attach this to
your bugreport.

# -O3 -fno-ms-extensions -> NOK

thomas@skate:/tmp$ arm-linux-gnueabihf-g++ -O3 -fno-ms-extensions -c
SVGAllInOne.cpp 
In file included from svg/SVGAnimateMotionElement.cpp:37:0,
 from svg/SVGAllInOne.cpp:36:
svg/SVGPathElement.h: In member function ‘virtual WebCore::FloatRect
WebCore::SVGPathElement::_ZTv0_n24_N7WebCore14SVGPathElement7getBBoxENS_12SVGLocatable19StyleUpdateStrategyE(WebCore::SVGLocatable::StyleUpdateStrategy)’:
svg/SVGPathElement.h:95:23: internal compiler error: in
expand_expr_addr_expr_1, at expr.c:7649
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Beware that the C++ source file is 7 MB in size, and takes a little while to
build:

$ time arm-linux-gnueabihf-g++ -O2 -c SVGAllInOne.cpp 
real0m32.544s
user0m32.032s
sys0m0.431s

[Bug libstdc++/58393] Please relax feature check for std::to_string and std::sto* for uClibc

[thomas.petazz...@free-electrons.com]

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

Thomas Petazzoni  changed:

   What|Removed |Added

 CC||thomas.petazzoni@free-elect
   ||rons.com

--- Comment #2 from Thomas Petazzoni  ---
I am one of the core developers of Buildroot, an embedded Linux build system,
which offers amongst other choices, the possibility of building a Linux system
based on the uClibc library. As such, we are facing the same problem as the one
reported by Nicolas Cavallari in this bug report: uClibc doesn't implement the
C99 complex maths functions, and this prevents libstdc++ from providing many
std-c++11 methods that are clearly unrelated to complex maths.

Has any progress been made towards applying Nicolas's patch?

[Bug target/63261] New: Microblaze 4.9.1, Error: PC relative branch to label which is not in the instruction space

[thomas.petazz...@free-electrons.com]

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

Bug ID: 63261
   Summary: Microblaze 4.9.1, Error: PC relative branch to label
 which is not in the instruction space
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thomas.petazz...@free-electrons.com

When building the fxload program (see
http://sourceforge.net/projects/linux-hotplug/files/fxload/2008_10_13/) with
gcc 4.9.1, binutils 2.24, on the Microblaze EL architecture, the build fails
with:

/home/buildroot/instance-1/output/host/usr/bin/microblazeel-buildroot-linux-gnu-gcc
-c -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64  -pipe -Os
-g2  main.c -o main.o
{standard input}: Assembler messages:
{standard input}: Error: PC relative branch to label logerror which is not in
the instruction space
{standard input}: Error: PC relative branch to label logerror which is not in
the instruction space
{standard input}: Error: PC relative branch to label logerror which is not in
the instruction space
{standard input}: Error: PC relative branch to label logerror which is not in
the instruction space
{standard input}: Error: PC relative branch to label logerror which is not in
the instruction space
{standard input}: Error: PC relative branch to label logerror which is not in
the instruction space
{standard input}: Error: PC relative branch to label logerror which is not in
the instruction space
make[1]: *** [main.o] Error 1
make[1]: *** Waiting for unfinished jobs
{standard input}: Assembler messages:
{standard input}:6463: Error: operation combines symbols in different segments
{standard input}:6464: Error: operation combines symbols in different segments
{standard input}:6467: Error: operation combines symbols in different segments
{standard input}:6468: Error: operation combines symbols in different segments
{standard input}:6477: Error: operation combines symbols in different segments
{standard input}:6478: Error: operation combines symbols in different segments
{standard input}:6481: Error: operation combines symbols in different segments
{standard input}:6482: Error: operation combines symbols in different segments
{standard input}:6488: Error: operation combines symbols in different segments
{standard input}:6489: Error: operation combines symbols in different segments
{standard input}:6492: Error: operation combines symbols in different segments
{standard input}:6493: Error: operation combines symbols in different segments
{standard input}:6502: Error: operation combines symbols in different segments
{standard input}:6503: Error: operation combines symbols in different segments
{standard input}:6509: Error: operation combines symbols in different segments
make[1]: *** [ezusb.o] Error 1

The logerror() function does not seem to have anything really special. It is
defined in main.c:

void logerror(const char *format, ...)
__attribute__ ((format (__printf__, 1, 2)));

void logerror(const char *format, ...)
{
va_list ap;
va_start(ap, format);

if(dosyslog)
vsyslog(LOG_ERR, format, ap);
else
vfprintf(stderr, format, ap);
va_end(ap);
}

And used from both main.o and ezusb.o, with ezusb.c carrying this definition:

extern void logerror(const char *format, ...)
__attribute__ ((format (printf, 1, 2)));

This bug was originally reported to binutils (see
https://sourceware.org/bugzilla/show_bug.cgi?id=17329 for all the details), but
the binutils developers said it's a gcc bug.

And indeed: the bug appears when building the program with -Os and -g or -O2
and -g, but not if building with just -Os, -O2 or -g. It's the combination of
an optimization flag *and* -g that causes the bug.

[Bug other/69038] New: sparc64 compilation fails with error: unable to find a register to spill in class 'FP_REGS'

[thomas.petazz...@free-electrons.com]

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

Bug ID: 69038
   Summary: sparc64 compilation fails with error: unable to find a
register to spill in class 'FP_REGS'
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thomas.petazz...@free-electrons.com
  Target Milestone: ---

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

When building the libvips library with sparc64 gcc 5.3.0, the build fails with:

nohalo.cpp: In function 'void
vips_interpolate_nohalo_interpolate(VipsInterpolate*, void*, VipsRegion*,
double, double)':
nohalo.cpp:1571:1: error: unable to find a register to spill in class 'FP_REGS'
 }
 ^
nohalo.cpp:1571:1: error: this is the insn:
(insn 555 554 3791 8 (set (reg:DF 32 %f0)
(float:DF (reg:SI 1852 [ MEM[base: p_139, index: _138, offset: 0B]+-3
]))) nohalo.cpp:1463 155 {floatsidf2}
 (expr_list:REG_DEAD (reg:SI 1852 [ MEM[base: p_139, index: _138, offset:
0B]+-3 ])
(nil)))

This build failure happens at -O1, -O2, -Os, but not at -O0:

test@build:~/buildroot/output/build/libvips-7.42.2/libvips/resample$
/home/test/buildroot/output/host/usr/bin/sparc64-buildroot-linux-gnu-g++ -c -O0
 .libs/nohalo.c
test@build:~/buildroot/output/build/libvips-7.42.2/libvips/resample$
/home/test/buildroot/output/host/usr/bin/sparc64-buildroot-linux-gnu-g++ -c -O1
 .libs/nohalo.c
nohalo.cpp: In function 'void
vips_interpolate_nohalo_interpolate(VipsInterpolate*, void*, VipsRegion*,
double, double)':
nohalo.cpp:1571:1: error: unable to find a register to spill in class 'FP_REGS'
 }
 ^
nohalo.cpp:1571:1: error: this is the insn:
(insn 721 720 722 8 (set (reg:DF 32 %f0)
(float:DF (reg:SI 2281 [ MEM[base: p_139, index: _138, offset: 0B]+-3
]))) nohalo.cpp:1463 155 {floatsidf2}
 (expr_list:REG_DEAD (reg:SI 2281 [ MEM[base: p_139, index: _138, offset:
0B]+-3 ])
(nil)))
nohalo.cpp:1571: confused by earlier errors, bailing out
test@build:~/buildroot/output/build/libvips-7.42.2/libvips/resample$
/home/test/buildroot/output/host/usr/bin/sparc64-buildroot-linux-gnu-g++ -c -O2
 .libs/nohalo.c
nohalo.cpp: In function 'void
vips_interpolate_nohalo_interpolate(VipsInterpolate*, void*, VipsRegion*,
double, double)':
nohalo.cpp:1571:1: error: unable to find a register to spill in class 'FP_REGS'
 }
 ^
nohalo.cpp:1571:1: error: this is the insn:
(insn 837 773 775 8 (set (reg:DF 32 %f0)
(float:DF (reg:SI 2333 [ MEM[base: p_139, index: _5583, offset: 0B]+-3
]))) nohalo.cpp:1463 155 {floatsidf2}
 (expr_list:REG_DEAD (reg:SI 2333 [ MEM[base: p_139, index: _5583, offset:
0B]+-3 ])
(nil)))
nohalo.cpp:1571: confused by earlier errors, bailing out
test@build:~/buildroot/output/build/libvips-7.42.2/libvips/resample$
/home/test/buildroot/output/host/usr/bin/sparc64-buildroot-linux-gnu-g++ -c -Os
 .libs/nohalo.c
nohalo.cpp: In function 'void
vips_interpolate_nohalo_interpolate(VipsInterpolate*, void*, VipsRegion*,
double, double)':
nohalo.cpp:1571:1: error: unable to find a register to spill in class 'FP_REGS'
 }
 ^
nohalo.cpp:1571:1: error: this is the insn:
(insn 555 554 3791 8 (set (reg:DF 32 %f0)
(float:DF (reg:SI 1852 [ MEM[base: p_139, index: _138, offset: 0B]+-3
]))) nohalo.cpp:1463 155 {floatsidf2}
 (expr_list:REG_DEAD (reg:SI 1852 [ MEM[base: p_139, index: _138, offset:
0B]+-3 ])
(nil)))
nohalo.cpp:1571: confused by earlier errors, bailing out

In attachment, the pre-processed source file that allows to reproduce the
issue.

[Bug target/69038] compilation error: unable to find a register to spill in class 'FP_REGS'

[thomas.petazz...@free-electrons.com]

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

--- Comment #2 from Thomas Petazzoni  ---
Sure, here it is:

Using built-in specs.
COLLECT_GCC=/home/test/buildroot/output/host/usr/bin/sparc64-buildroot-linux-gnu-g++.br_real
Target: sparc64-buildroot-linux-gnu
Configured with: ./configure --prefix=/home/test/buildroot/output/host/usr
--sysconfdir=/home/test/buildroot/output/host/etc --enable-static
--target=sparc64-b
uildroot-linux-gnu
--with-sysroot=/home/test/buildroot/output/host/usr/sparc64-buildroot-linux-gnu/sysroot
--disable-__cxa_atexit --with-gnu-ld --disable-libssp --disable-multilib
--with-gmp=/home/test/buildroot/output/host/usr
--with-mpfr=/home/test/buildroot/output/host/usr --with-pkgversion='Buildroot
2016.02-git-00574-g4ef0ef3-dirty' --with-bugurl=http://bugs.buildroot.net/
--disable-libquadmath --disable-libsanitizer --enable-tls --disable-libmudflap
--enable-threads --with-mpc=/home/test/buildroot/output/host/usr --without-isl
--without-cloog --disable-decimal-float --with-cpu=ultrasparc
--enable-languages=c,c++
--with-build-time-tools=/home/test/buildroot/output/host/usr/sparc64-buildroot-linux-gnu/bin
--enable-shared --disable-libgomp
Thread model: posix
gcc version 5.3.0 (Buildroot 2016.02-git-00574-g4ef0ef3-dirty) 
COLLECT_GCC_OPTIONS='-v' '-c' '-Os' '-shared-libgcc' '-mcpu=ultrasparc'

/home/test/buildroot/output/host/usr/libexec/gcc/sparc64-buildroot-linux-gnu/5.3.0/cc1plus
-quiet -v -isysroot
/home/test/buildroot/output/host/usr/sparc64-buildroot-linux-gnu/sysroot
-D_GNU_SOURCE -D__sparc_v9__ -D__arch64__ .libs/nohalo.c -mvis -quiet -dumpbase
nohalo.c -mcpu=ultrasparc -auxbase nohalo -Os -version -o /tmp/ccHnYVn9.s
GNU C++ (Buildroot 2016.02-git-00574-g4ef0ef3-dirty) version 5.3.0
(sparc64-buildroot-linux-gnu)
compiled by GNU C version 4.4.5, GMP version 6.1.0, MPFR version 3.1.3,
MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"/home/test/buildroot/output/host/usr/sparc64-buildroot-linux-gnu/sysroot/usr/local/include"
#include "..." search starts here:
#include <...> search starts here:

/home/test/buildroot/output/host/usr/lib/gcc/sparc64-buildroot-linux-gnu/5.3.0/../../../../sparc64-buildroot-linux-gnu/include/c++/5.3.0

/home/test/buildroot/output/host/usr/lib/gcc/sparc64-buildroot-linux-gnu/5.3.0/../../../../sparc64-buildroot-linux-gnu/include/c++/5.3.0/sparc64-buildroot-linux-gnu

/home/test/buildroot/output/host/usr/lib/gcc/sparc64-buildroot-linux-gnu/5.3.0/../../../../sparc64-buildroot-linux-gnu/include/c++/5.3.0/backward

/home/test/buildroot/output/host/usr/lib/gcc/sparc64-buildroot-linux-gnu/5.3.0/include

/home/test/buildroot/output/host/usr/lib/gcc/sparc64-buildroot-linux-gnu/5.3.0/include-fixed

/home/test/buildroot/output/host/usr/lib/gcc/sparc64-buildroot-linux-gnu/5.3.0/../../../../sparc64-buildroot-linux-gnu/include

/home/test/buildroot/output/host/usr/sparc64-buildroot-linux-gnu/sysroot/usr/include
End of search list.
GNU C++ (Buildroot 2016.02-git-00574-g4ef0ef3-dirty) version 5.3.0
(sparc64-buildroot-linux-gnu)
compiled by GNU C version 4.4.5, GMP version 6.1.0, MPFR version 3.1.3,
MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: f99a20b2afe7fa95fb8df4625860a9b3
nohalo.cpp: In function 'void
vips_interpolate_nohalo_interpolate(VipsInterpolate*, void*, VipsRegion*,
double, double)':
nohalo.cpp:1571:1: error: unable to find a register to spill in class 'FP_REGS'
 }
 ^
nohalo.cpp:1571:1: error: this is the insn:
(insn 555 554 3791 8 (set (reg:DF 32 %f0)
(float:DF (reg:SI 1852 [ MEM[base: p_139, index: _138, offset: 0B]+-3
]))) nohalo.cpp:1463 155 {floatsidf2}
 (expr_list:REG_DEAD (reg:SI 1852 [ MEM[base: p_139, index: _138, offset:
0B]+-3 ])
(nil)))
nohalo.cpp:1571: confused by earlier errors, bailing out

[Bug c++/69401] New: gcc 5.3.0 on microblaze: internal compiler error: in gen_reg_rtx, at emit-rtl.c:1027

[thomas.petazz...@free-electrons.com]

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

Bug ID: 69401
   Summary: gcc 5.3.0 on microblaze: internal compiler error: in
gen_reg_rtx, at emit-rtl.c:1027
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thomas.petazz...@free-electrons.com
  Target Milestone: ---

When building some C++ file from the flann library
(http://www.cs.ubc.ca/research/flann/) for Microblaze, gcc 5.3.0 fails with:

   internal compiler error: in gen_reg_rtx, at emit-rtl.c:1027

The problem was narrowed down to only happen with the combination of -O3 and
-fPIC. If one of these options is not used, the problem does not occur.

The attached flann.ii file is the preprocessed file, and the problem can be
reproduced by running:

$ microblaze-buildroot-linux-gnu-g++ -c -O3 -fPIC flann.ii

Here is the output of microblaze-buildroot-linux-gnu-g++ when building this
flann.ii file:

zino@mytesting:~/buildroot/output/build/flann-04b4a56533faf8c8228d011d05ba376038364b49/src/cpp$
 /home/zino/buildroot/output/host/usr/bin/microblaze-buildroot-linux-gnu-g++ -c
-O3 -v -fPIC flann.ii
Using built-in specs.
COLLECT_GCC=/home/zino/buildroot/output/host/usr/bin/microblaze-buildroot-linux-gnu-g++.br_real
Target: microblaze-buildroot-linux-gnu
Configured with: ./configure --prefix=/home/zino/buildroot/output/host/usr
--sysconfdir=/home/zino/buildroot/output/host/etc --enable-static
--target=microblaze-buildroot-linux-gnu
--with-sysroot=/home/zino/buildroot/output/host/usr/microblaze-buildroot-linux-gnu/sysroot
--disable-__cxa_atexit --with-gnu-ld --disable-libssp --disable-multilib
--with-gmp=/home/zino/buildroot/output/host/usr
--with-mpfr=/home/zino/buildroot/output/host/usr --with-pkgversion='Buildroot
2016.02-git-00894-gaa112f2' --with-bugurl=http://bugs.buildroot.net/
--disable-libquadmath --enable-tls --disable-libmudflap --enable-threads
--with-mpc=/home/zino/buildroot/output/host/usr --without-isl --without-cloog
--disable-decimal-float --enable-languages=c,c++
--with-build-time-tools=/home/zino/buildroot/output/host/usr/microblaze-buildroot-linux-gnu/bin
--enable-shared --disable-libgomp
Thread model: posix
gcc version 5.3.0 (Buildroot 2016.02-git-00894-gaa112f2) 
COLLECT_GCC_OPTIONS='-c' '-O3' '-v' '-fPIC' '-shared-libgcc'

/home/zino/buildroot/output/host/usr/libexec/gcc/microblaze-buildroot-linux-gnu/5.3.0/cc1plus
-fpreprocessed flann.ii -quiet -dumpbase flann.ii -auxbase flann -O3 -version
-fPIC -o /tmp/cc6LK1Zx.s
GNU C++ (Buildroot 2016.02-git-00894-gaa112f2) version 5.3.0
(microblaze-buildroot-linux-gnu)
compiled by GNU C version 5.3.1 20160101, GMP version 6.1.0, MPFR
version 3.1.3, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (Buildroot 2016.02-git-00894-gaa112f2) version 5.3.0
(microblaze-buildroot-linux-gnu)
compiled by GNU C version 5.3.1 20160101, GMP version 6.1.0, MPFR
version 3.1.3, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 72192880c32f68d631b343345080a169
In file included from
/home/zino/buildroot/output/build/flann-04b4a56533faf8c8228d011d05ba376038364b49/src/cpp/flann/algorithms/all_indices.h:35:0,
 from
/home/zino/buildroot/output/build/flann-04b4a56533faf8c8228d011d05ba376038364b49/src/cpp/flann/flann.hpp:45,
 from
/home/zino/buildroot/output/build/flann-04b4a56533faf8c8228d011d05ba376038364b49/src/cpp/flann/flann.h:476,
 from
/home/zino/buildroot/output/build/flann-04b4a56533faf8c8228d011d05ba376038364b49/src/cpp/flann/flann.cpp:31:
/home/zino/buildroot/output/build/flann-04b4a56533faf8c8228d011d05ba376038364b49/src/cpp/flann/algorithms/nn_index.h:
In member function ‘int flann::NNIndex::knnSearch(const
flann::Matrix&, flann::Matrix&,
flann::Matrix&, size_t, const
flann::SearchParams&) const [with Distance = flann::KL_Divergence;
typename Distance::ElementType = double; typename Distance::ResultType =
double; size_t = unsigned int]’:
/home/zino/buildroot/output/build/flann-04b4a56533faf8c8228d011d05ba376038364b49/src/cpp/flann/algorithms/nn_index.h:357:5:
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://bugs.buildroot.net/> for instructions.

This bug might be related to bug #68538 (same error message), but it happens on
Microblaze and not CRIS.

[Bug c++/69401] gcc 5.3.0 on microblaze: internal compiler error: in gen_reg_rtx, at emit-rtl.c:1027

[thomas.petazz...@free-electrons.com]

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

--- Comment #1 from Thomas Petazzoni  ---
Created attachment 37413
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37413&action=edit
Preprocessed source file

[Bug target/65151] [SH][4.9 Regression] Internal compiler error when trying to build libav 11.2 on sh4

[thomas.petazz...@free-electrons.com]

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

Thomas Petazzoni  changed:

   What|Removed |Added

 CC||thomas.petazzoni@free-elect
   ||rons.com

--- Comment #11 from Thomas Petazzoni  ---
(In reply to Jakub Jelinek from comment #10)
> GCC 4.9.3 has been released.

This problem still occurs with GCC 4.9.3, as far as I can see.

[Bug target/65151] [SH][4.9 Regression] Internal compiler error when trying to build libav 11.2 on sh4

[thomas.petazz...@free-electrons.com]

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

--- Comment #13 from Thomas Petazzoni  ---
(In reply to John Paul Adrian Glaubitz from comment #12)
> (In reply to Thomas Petazzoni from comment #11)
> > (In reply to Jakub Jelinek from comment #10)
> > > GCC 4.9.3 has been released.
> > 
> > This problem still occurs with GCC 4.9.3, as far as I can see.
> 
> I'm actually not sure. There have been many changes to the SH backend ever
> since and as Debian moved from libav to ffmpeg as the default library, I
> haven't had a chance to test-build libav for a long time.

I am quite sure, see
http://autobuild.buildroot.org/results/09b/09b08d329e632365dd8371371706dbeaa10539a3/build-end.log:

libavcodec/dpxenc.c: In function 'encode_frame':
libavcodec/dpxenc.c:162:1: internal compiler error: in
elimination_costs_in_insn, at reload1.c:3638

The toolchain, available at
http://autobuild.buildroot.org/toolchains/tarballs/br-sh4-full-2015.05-496-g85945aa.tar.bz2,
uses gcc 4.9.3.

[Bug target/71749] New: Define _REENTRANT on ARC when -pthread is passed

[thomas.petazz...@free-electrons.com]

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

Bug ID: 71749
   Summary: Define _REENTRANT on ARC when -pthread is passed
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thomas.petazz...@free-electrons.com
  Target Milestone: ---

Created attachment 38827
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38827&action=edit
Patch that defines _REENTRANT on ARC when -pthread is passed

When -pthread is passed, gcc should define _REENTRANT to make the C library use
reentrant version of various functions, and also because userspace code
sometimes checks _REENTRANT to decide if thread support is available or not
(see ax_pthread.m4 in autoconf-archive).

The attached patch makes sure _REENTRANT gets defined on ARC when -pthread is
specified.

[Bug target/71750] New: Define _REENTRANT on Blackfin when -pthread is passed

[thomas.petazz...@free-electrons.com]

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

Bug ID: 71750
   Summary: Define _REENTRANT on Blackfin when -pthread is passed
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thomas.petazz...@free-electrons.com
  Target Milestone: ---

Created attachment 38828
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38828&action=edit
Patch that defines _REENTRANT on Blackfin when -pthread is passed

When -pthread is passed, gcc should define _REENTRANT to make the C library use
reentrant version of various functions, and also because userspace code
sometimes checks _REENTRANT to decide if thread support is available or not
(see ax_pthread.m4 in autoconf-archive).

The attached patch makes sure _REENTRANT gets defined on Blackfin when -pthread
is specified.

[Bug target/65151] [SH][4.9 Regression] Internal compiler error when trying to build libav 11.2 on sh4

[thomas.petazz...@free-electrons.com]

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

--- Comment #16 from Thomas Petazzoni  ---
Yes, I confirm the issue is fixed in gcc 5.