Building on gcc112 is stuck in msgfmt

2017-08-28 Thread Martin Liška
Hello. I've just repeatedly seen stuck in build process: make[5]: Entering directory `/home/marxin/Programming/gcc/objdir/powerpc64le-unknown-linux-gnu/libstdc++-v3/po' msgfmt -o de.mo ../../../../libstdc++-v3/po/de.po 49__asm volatile ("sc; mfcr %0" Missing separate debuginfos, use: de

GNU MPFR 3.1.6 Release Candidate

2017-08-28 Thread Vincent Lefevre
The release of GNU MPFR 3.1.6 ("canard à l'orange", patch level 6) is imminent. Please help to make this release as good as possible by downloading and testing this release candidate: http://www.mpfr.org/mpfr-3.1.6/mpfr-3.1.6-rc1.tar.xz http://www.mpfr.org/mpfr-3.1.6/mpfr-3.1.6-rc1.tar.bz2 http://

Re: Building on gcc112 is stuck in msgfmt

2017-08-28 Thread Jeff Law
On 08/28/2017 01:16 AM, Martin Liška wrote: > Hello. > > I've just repeatedly seen stuck in build process: > > make[5]: Entering directory > `/home/marxin/Programming/gcc/objdir/powerpc64le-unknown-linux-gnu/libstdc++-v3/po' > msgfmt -o de.mo ../../../../libstdc++-v3/po/de.po > > 49__as

Re: gcc torture test pr52286.c

2017-08-28 Thread Jeff Law
On 08/27/2017 09:33 PM, Paul S wrote: > I've ported gcc to a 16 bit CPU and have all torture tests passing bar > one, pr52286.c > > The offending lines of code are > > long a, b = 0; > asm ("" : "=r" (a) : "0" (0)); I wouldn't use a matching constraint here. Something like this is probably c

Re: gcc torture test pr52286.c

2017-08-28 Thread Michael Matz
Hi, On Mon, 28 Aug 2017, Jeff Law wrote: > > long a, b = 0; > > asm ("" : "=r" (a) : "0" (0)); > I wouldn't use a matching constraint here. Something like this is > probably closer to what you want: > > asm ("" : "=r" (a) : "n" (0)); > > The "n" says accept any immediate integer constant w

Re: gcc torture test pr52286.c

2017-08-28 Thread Jeff Law
On 08/28/2017 11:33 AM, Michael Matz wrote: > Hi, > > On Mon, 28 Aug 2017, Jeff Law wrote: > >>> long a, b = 0; >>> asm ("" : "=r" (a) : "0" (0)); >> I wouldn't use a matching constraint here. Something like this is >> probably closer to what you want: >> >> asm ("" : "=r" (a) : "n" (0)); >>

Re: gcc torture test pr52286.c

2017-08-28 Thread Michael Matz
Hi, On Mon, 28 Aug 2017, Jeff Law wrote: > I can't remember matching constraints ever working that way. They do work exactly so. These uses are all correct, though they place some random value into x: int x, y, z; y = z = init(); asm ("" : "=r" (x) : "r" (y+z)); asm ("" : "=r" (x) : "

Re: gcc torture test pr52286.c

2017-08-28 Thread Michael Matz
Hi, On Mon, 28 Aug 2017, Paul S wrote: > I've ported gcc to a 16 bit CPU and have all torture tests passing bar one, > pr52286.c > > The offending lines of code are > > long a, b = 0; > asm ("" : "=r" (a) : "0" (0)); > > > which should cause zero to be assigned to the "a" SI sized variabl

Re: gcc torture test pr52286.c

2017-08-28 Thread Michael Matz
Hi, On Mon, 28 Aug 2017, Michael Matz wrote: > On Mon, 28 Aug 2017, Jeff Law wrote: > > > I can't remember matching constraints ever working that way. > > They do work exactly so. FWIW, I was momentarily worried that there once was a world where you were right. If so (and I don't believe it)

Re: Building on gcc112 is stuck in msgfmt

2017-08-28 Thread Bill Seurer
On 08/28/2017 02:16 AM, Martin Liška wrote: Hello. I've just repeatedly seen stuck in build process: make[5]: Entering directory `/home/marxin/Programming/gcc/objdir/powerpc64le-unknown-linux-gnu/libstdc++-v3/po' msgfmt -o de.mo ../../../../libstdc++-v3/po/de.po 49__asm volatile ("sc;

Re: Building on gcc112 is stuck in msgfmt

2017-08-28 Thread Martin Liška
On 08/28/2017 04:06 PM, Jeff Law wrote: On 08/28/2017 01:16 AM, Martin Liška wrote: Hello. I've just repeatedly seen stuck in build process: make[5]: Entering directory `/home/marxin/Programming/gcc/objdir/powerpc64le-unknown-linux-gnu/libstdc++-v3/po' msgfmt -o de.mo ../../../../libstdc++-v3

Re: gcc torture test pr52286.c

2017-08-28 Thread Paul S
Thanks Michael (and Jeff) I shared your view about the mode of the output register not being reflected to the input until I saw (asm_operands:SI ("") ("=r") 0 [ (reg:HI 30) ] then I was unsure whether the input was affecting the output or the output mode w

Re: gcc torture test pr52286.c

2017-08-28 Thread Jeff Law
On 08/28/2017 11:56 AM, Michael Matz wrote: > Hi, > > On Mon, 28 Aug 2017, Jeff Law wrote: > >> I can't remember matching constraints ever working that way. > > They do work exactly so. These uses are all correct, though they place > some random value into x: Hmm, maybe I've spent too much tim

operand_equal_p() and SSA_NAME

2017-08-28 Thread Martin Sebor
operand_equal_p() doesn't handle SSA_NAMEs and returns false for operands in that form even when they have equal values (when both are ADDR_EXPR of the same decl). Yet the function is extensively relied on in the middle end where I would expect it be beneficial to have it handle SSA_NAMEs. At a

Re: operand_equal_p() and SSA_NAME

2017-08-28 Thread Andrew Pinski
On Mon, Aug 28, 2017 at 7:46 PM, Martin Sebor wrote: > operand_equal_p() doesn't handle SSA_NAMEs and returns false for > operands in that form even when they have equal values (when both > are ADDR_EXPR of the same decl). Yet the function is extensively > relied on in the middle end where I woul

Re: operand_equal_p() and SSA_NAME

2017-08-28 Thread Jeff Law
On 08/28/2017 08:46 PM, Martin Sebor wrote: > operand_equal_p() doesn't handle SSA_NAMEs and returns false for > operands in that form even when they have equal values (when both > are ADDR_EXPR of the same decl). Yet the function is extensively > relied on in the middle end where I would expect i

Re: operand_equal_p() and SSA_NAME

2017-08-28 Thread Jeff Law
On 08/28/2017 09:46 PM, Andrew Pinski wrote: > On Mon, Aug 28, 2017 at 7:46 PM, Martin Sebor wrote: >> operand_equal_p() doesn't handle SSA_NAMEs and returns false for >> operands in that form even when they have equal values (when both >> are ADDR_EXPR of the same decl). Yet the function is exte