Can you check gcc 4.8.1 RC1?

Unfortunately, basically same issue:

...
/bin/bash ../../../libtool --tag CXX --tag disable-shared   --mode=compile /home/ernie/gcc-4.8-4.8.1
/build2/./gcc/xgcc -shared-libgcc -B/home/ernie/gcc-4.8-4.8.1/build2/./gcc -nostdinc++ -L/home/ernie
/gcc-4.8-4.8.1/build2/powerpc-linux-gnuspe/libstdc++-v3/src -L/home/ernie/gcc-4.8-4.8.1/build2/power
pc-linux-gnuspe/libstdc++-v3/src/.libs -B/usr/powerpc-linux-gnuspe/bin/ -B/usr/powerpc-linux-gnuspe/
lib/ -isystem /usr/powerpc-linux-gnuspe/include -isystem /usr/powerpc-linux-gnuspe/sys-include    -I
/home/ernie/gcc-4.8-4.8.1/gcc-4.8.1/libstdc++-v3/../libgcc -I/home/ernie/gcc-4.8-4.8.1/build2/powerp
c-linux-gnuspe/libstdc++-v3/include/powerpc-linux-gnuspe -I/home/ernie/gcc-4.8-4.8.1/build2/powerpc-
linux-gnuspe/libstdc++-v3/include -I/home/ernie/gcc-4.8-4.8.1/gcc-4.8.1/libstdc++-v3/libsupc++  -pre
fer-pic -D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi  -
fdiagnostics-show-location=once   -ffunction-sections -fdata-sections  -frandom-seed=hash_tr1.lo -gd
warf-4 -g3 -O0  -c -o hash_tr1.lo ../../../../../../gcc-4.8.1/libstdc++-v3/src/c++98/hash_tr1.cc
libtool: compile:  /home/ernie/gcc-4.8-4.8.1/build2/./gcc/xgcc -shared-libgcc -B/home/ernie/gcc-4.8-
4.8.1/build2/./gcc -nostdinc++ -L/home/ernie/gcc-4.8-4.8.1/build2/powerpc-linux-gnuspe/libstdc++-v3/
src -L/home/ernie/gcc-4.8-4.8.1/build2/powerpc-linux-gnuspe/libstdc++-v3/src/.libs -B/usr/powerpc-li
nux-gnuspe/bin/ -B/usr/powerpc-linux-gnuspe/lib/ -isystem /usr/powerpc-linux-gnuspe/include -isystem
 /usr/powerpc-linux-gnuspe/sys-include -I/home/ernie/gcc-4.8-4.8.1/gcc-4.8.1/libstdc++-v3/../libgcc
-I/home/ernie/gcc-4.8-4.8.1/build2/powerpc-linux-gnuspe/libstdc++-v3/include/powerpc-linux-gnuspe -I/home/ernie/gcc-4.8-4.8.1/build2/powerpc-linux-gnuspe/libstdc++-v3/include -I/home/ernie/gcc-4.8-4.8.1/gcc-4.8.1/libstdc++-v3/libsupc++ -D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=hash_tr1.lo -gdwarf-4 -g3 -O0 -c ../../../../../../gcc-4.8.1/libstdc++-v3/src/c++98/hash_tr1.cc  -fPIC -DPIC -D_GLIBCXX_SHARED -o hash_tr1.o
In file included from ../../../../../../gcc-4.8.1/libstdc++-v3/src/c++98/hash_tr1.cc:28:0:
../../../../../../gcc-4.8.1/libstdc++-v3/src/c++98/hash-long-double-tr1-aux.cc: In member function 'std::size_t std::tr1::hash<_Tp>::operator()(_Tp) const [with _Tp = long double; std::size_t = unsigned int]':
../../../../../../gcc-4.8.1/libstdc++-v3/src/c++98/hash-long-double-tr1-aux.cc:54:7: error: unrecognizable insn:
       }
       ^
(insn 318 317 178 12 (set (reg:TI 4 4)
        (mem/c:TI (plus:SI (reg:SI 5 5)
                (const_int 256 [0x100])) [0 %sfp+256 S16 A128])) ../../../../../../gcc-4.8.1/libstdc++-v3/src/c++98/hash-long-double-tr1-aux.cc:49 -1
     (nil))
../../../../../../gcc-4.8.1/libstdc++-v3/src/c++98/hash-long-double-tr1-aux.cc:54:7: internal compiler error: in extract_insn, at recog.c:2150
0x10861797 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*)
        ../../gcc-4.8.1/gcc/rtl-error.c:109
0x108617eb _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
        ../../gcc-4.8.1/gcc/rtl-error.c:117
0x107fb863 extract_insn(rtx_def*)
        ../../gcc-4.8.1/gcc/recog.c:2150
0x107fb3a3 extract_insn_cached(rtx_def*)
        ../../gcc-4.8.1/gcc/recog.c:2053
0x105624df cleanup_subreg_operands(rtx_def*)
        ../../gcc-4.8.1/gcc/final.c:3008
0x10840cef reload(rtx_def*, int)
        ../../gcc-4.8.1/gcc/reload1.c:1240
0x106b5d37 do_reload
        ../../gcc-4.8.1/gcc/ira.c:4631
0x106b6033 rest_of_handle_reload
        ../../gcc-4.8.1/gcc/ira.c:4731
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <file:///usr/share/doc/gcc-4.8/README.Bugs> for instructions.
make[8]: *** [hash_tr1.lo] Error 1
make[8]: Leaving directory `/home/ernie/gcc-4.8-4.8.1/build2/powerpc-linux-gnuspe/libstdc++-v3/src/debug/c++98'
make[7]: *** [all-recursive] Error 1
make[7]: Leaving directory `/home/ernie/gcc-4.8-4.8.1/build2/powerpc-linux-gnuspe/libstdc++-v3/src/debug'
make[6]: *** [build-debug] Error 2
make[6]: Leaving directory `/home/ernie/gcc-4.8-4.8.1/build2/powerpc-linux-gnuspe/libstdc++-v3/src'
make[5]: *** [all-recursive] Error 1
make[5]: Leaving directory `/home/ernie/gcc-4.8-4.8.1/build2/powerpc-linux-gnuspe/libstdc++-v3/src'
make[4]: *** [all-recursive] Error 1
make[4]: Leaving directory `/home/ernie/gcc-4.8-4.8.1/build2/powerpc-linux-gnuspe/libstdc++-v3'
make[3]: *** [all] Error 2
make[3]: Leaving directory `/home/ernie/gcc-4.8-4.8.1/build2/powerpc-linux-gnuspe/libstdc++-v3'
make[2]: *** [all-stage1-target-libstdc++-v3] Error 2
...

Configuration was done like this:

../gcc-4.8.1/configure -v --with-pkgversion='Debian 4.8.1' --with-bugurl='file:///usr/share/doc/gcc-4.8/README.Bugs' --enable-languages=c,c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id  --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libitm --enable-plugin --with-system-zlib --enable-secureplt --disable-multilib --enable-multiarch --with-cpu=8548 --enable-e500_double --with-long-double-128 --enable-checking=release --build=powerpc-linux-gnuspe --host=powerpc-linux-gnuspe --target=powerpc-linux-gnuspe

I think this should <target>, anyway.

FWIW, I just tried with GCC 4.7.3, configured and built the same way, and it works. The files

    libstdc++-v3/src/c++98/hash_tr1.cc
    libstdc++-v3/src/c++98/hash-long-double-tr1-aux.cc

haven't changed really.

More info: I just checked that the issue is still present in 4.8.2.

Without --with-long-double-128, the problem doesn't occur.

Any hint where I should look for?

Thanks in advance!

I searched the differences between 4.7 and 4.8. It turned out that the patch that I'm attaching fixes the issue.

Any comments?

Can it be applied to the 4.8 line?

Thanks,

Roland

Created attachment 31415 [details]
Fix as described

Mike, can you apply the patch to the 4.8 branch?

Thanks, David

On Wed, Dec 11, 2013 at 04:37:20PM +0000, dje at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57386
> 
> --- Comment #8 from David Edelsohn <dje at gcc dot gnu.org> ---
> Mike, can you apply the patch to the 4.8 branch?
> 
> Thanks, David

Note, the patch no longer applies to the trunk due to adding a PTImode case.
I'll test both gcc 4.8/trunk with the patch for both.

Sorry for breaking this, and went unresponsive.

Please apply this patch only to 4.8.0 for now. The trunk needs some additional care, I'm working on this separately and will open a separate bug when it's ready.

Would be nice if you could have a look at powerpc-linux-gnuspe anyway, though. ;-)

On Thu, Dec 12, 2013 at 08:11:23AM +0000, stigge at antcom dot de wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57386
> 
> --- Comment #10 from Roland Stigge <stigge at antcom dot de> ---
> Please apply this patch only to 4.8.0 for now. The trunk needs some additional
> care, I'm working on this separately and will open a separate bug when it's
> ready.
> 
> Would be nice if you could have a look at powerpc-linux-gnuspe anyway, though.
> ;-)

Is there any way I can test powerpc-linux-gnuspe on a power7 running Linux?
Right now, I can only do visual code inspection of the .s file.

Created attachment 31428 [details]
pr57386.patch01-gcc48

On Thu, Dec 12, 2013 at 12:22:13AM +0000, meissner at linux dot vnet.ibm.com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57386
> 
> --- Comment #9 from Michael Meissner <meissner at linux dot vnet.ibm.com> ---
> On Wed, Dec 11, 2013 at 04:37:20PM +0000, dje at gcc dot gnu.org wrote:
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57386
> > 
> > --- Comment #8 from David Edelsohn <dje at gcc dot gnu.org> ---
> > Mike, can you apply the patch to the 4.8 branch?
> > 
> > Thanks, David
> 
> Note, the patch no longer applies to the trunk due to adding a PTImode case.
> I'll test both gcc 4.8/trunk with the patch for both.
> 
> Sorry for breaking this, and went unresponsive.

I tested this patch lifted from the bugzilla, and it does fix the problem for
GCC 4.8.  I'm also including the appropriate patch for GCC 4.9 (different due
to the surrounding code being different).  While there are other problems with
SPE in GCC 4.9, I feel this patch is safe to apply.

I have bootstraped the patch on a power7 running linux powerpc64 and there were
no regressions between the unpatched gcc 4.8 and the build with the patch
attached.

I have verified that the bug is fixed when I build a SPE compiler with the
patch attached for the GCC 4.8 patch.

I have also bootstraped the GCC 4.9 patch on a power7 running linux powerpc64.
As I write this message, I haven't done the make check regression test, but I
will do that shortly.

Are these patches ok to apply?  I can apply just the 4.8 patch or both the 4.8
and 4.9 patches.

2013-12-12  Roland Stigge  <stigge@antcom.de>
	    Michael Meissner  <meissner@linux.vnet.ibm.com>

	* config/rs6000/rs6000.c (rs6000_legitimate_offset_address_p):
	Only check TFmode for SPE constants.  Don't check TImode or
	TDmode.

Created attachment 31429 [details]
pr57386.patch01-gcc49

Yes, both patches are good, thanks. :-)

I currently can't give you developer's access to one of my e500v2 machines. But I hope I can provide it for the future. Will tell you directly when it's ready at some point.

You would need the hardware for testing because all other power*s are incompatible.

Author: meissner
Date: Tue Jan  7 19:57:11 2014
New Revision: 206401

URL: http://gcc.gnu.org/viewcvs?rev=206401&root=gcc&view=rev
Log:
2014-01-07  Roland Stigge  <stigge@antcom.de>
	    Michael Meissner  <meissner@linux.vnet.ibm.com>

	PR 57386/target
	* config/rs6000/rs6000.c (rs6000_legitimate_offset_address_p):
	Only check TFmode for SPE constants.  Don't check TImode or
	TDmode.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/rs6000/rs6000.c

Author: meissner
Date: Tue Jan  7 20:10:01 2014
New Revision: 206402

URL: http://gcc.gnu.org/viewcvs?rev=206402&root=gcc&view=rev
Log:
2014-01-07  Roland Stigge  <stigge@antcom.de>
	    Michael Meissner  <meissner@linux.vnet.ibm.com>

	PR 57386/target
	* config/rs6000/rs6000.c (rs6000_legitimate_offset_address_p):
	Only check TFmode for SPE constants.  Don't check TImode or
	TDmode.


Modified:
    branches/gcc-4_8-branch/gcc/ChangeLog
    branches/gcc-4_8-branch/gcc/config/rs6000/rs6000.c

I have checked the GCC 4.8, 4.9, 5.x, and current 6.x trunk, and I cannot reproduce this problem (patch was applied in 2014).  I checked -O0, -O1, -O2, and -O3 optimization levels.