[Bug target/61231] New: [4.9/4.10 Regression] bootstrap comparision failure on powerpc64le-linux-gnu

[Bug target/61231] New: [4.9/4.10 Regression] bootstrap comparision failure on powerpc64le-linux-gnu

[doko at gcc dot gnu.org]

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

            Bug ID: 61231
           Summary: [4.9/4.10 Regression] bootstrap comparision failure on
                    powerpc64le-linux-gnu
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: doko at gcc dot gnu.org

Seen on the trunk r210608, and the 4.9 branch r210592 on powerpc64le-linux-gnu,
using the 4.8.3 release candidate (plus the one rs6000 update) as a bootstrap
compiler:

trunk:
Comparing stages 2 and 3
warning: gcc/cc1objplus-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1obj-checksum.o differs
warning: gcc/cc1-checksum.o differs
Bootstrap comparison failure!
gcc/ada/exp_attr.o differs
gcc/ada/exp_atag.o differs
gcc/ada/eval_fat.o differs
libiberty/xstrdup.o differs
libiberty/pic/argv.o differs
libiberty/pic/choose-temp.o differs
libiberty/pic/regex.o differs
libiberty/argv.o differs
libiberty/choose-temp.o differs
powerpc64le-linux-gnu/libstdc++-v3/src/debug/c++98/list.o differs
Makefile:21206: recipe for target 'compare' failed
make[4]: *** [compare] Error 1

4.9 branch:
Comparing stages 2 and 3
warning: gcc/cc1objplus-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1obj-checksum.o differs
warning: gcc/cc1-checksum.o differs
Bootstrap comparison failure!
gcc/d/argtypes.dmd.o differs
libiberty/choose-temp.o differs
Makefile:20526: recipe for target 'compare' failed
make[4]: *** [compare] Error 1

[Bug target/61231] [4.9/4.10 Regression] bootstrap comparision failure on powerpc64le-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |build
           Priority|P3                          |P1
   Target Milestone|---                         |4.9.1

[Bug target/61231] [4.9/4.10 Regression] bootstrap comparision failure on powerpc64le-linux-gnu

[doko at gcc dot gnu.org]

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

--- Comment #1 from Matthias Klose <doko at gcc dot gnu.org> ---
so this happens because I had sys/sdt.h installed during the build, and
automatically gets picked up during the build.

So probably an invalid issue, or should the inclusion of this header be guarded
for architectures that are actually supported by systemtap?

[Bug target/61231] [4.9/4.10 Regression] bootstrap comparision failure on powerpc64le-linux-gnu

[fche at redhat dot com]

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

Frank Ch. Eigler <fche at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fche at redhat dot com

--- Comment #2 from Frank Ch. Eigler <fche at redhat dot com> ---
(Note that strictly speaking, systemtap per se doesn't need to support
an architecture for the sys/sdt.h header file to work there.  gdb is 
a fully independent client of sys/sdt.h markers.)

Perhaps the way to go forward is to have the gcc configury test-compile
some toy sys/sdt.h code [1], and activate the probes only if that works.

[1]
#include <sys/sdt.h>

int main ()
{
   DTRACE_PROBE(foo,bar);
   return 0;
}

[Bug target/61231] [4.9/4.10 Regression] bootstrap comparision failure on powerpc64le-linux-gnu

[doko at gcc dot gnu.org]

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

--- Comment #3 from Matthias Klose <doko at gcc dot gnu.org> ---
is test/compile sufficient, or do you have to run it?

[Bug target/61231] [4.9/4.10 Regression] bootstrap comparision failure on powerpc64le-linux-gnu

[fche at redhat dot com]

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

--- Comment #4 from Frank Ch. Eigler <fche at redhat dot com> ---
> is test/compile sufficient, or do you have to run it?

Just compile.

[Bug target/61231] [4.9/4.10 Regression] bootstrap comparision failure on powerpc64le-linux-gnu

[doko at gcc dot gnu.org]

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

Matthias Klose <doko at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vmakarov at gcc dot gnu.org

--- Comment #5 from Matthias Klose <doko at gcc dot gnu.org> ---
I was wrong about blaming the sys/sdt.h, header, and filed PR61257 for that.

Now I tracked down (with enough coffee I hope) r210519 as the patch introducing
the bootstrap failure.  Reverting it lets the bootstrap succeed on
powerpc64le-linux-gnu.

The build is configured with:

         --enable-secureplt
         --with-cpu=power7
         --with-tune=power8
         --disable-multilib
         --enable-multiarch
         --disable-werror
         --with-long-double-128
         --enable-checking=release
         --build=powerpc64le-linux-gnu
         --host=powerpc64le-linux-gnu
         --target=powerpc64le-linux-gnu

[Bug target/61231] [4.9/4.10 Regression] bootstrap comparision failure on powerpc64le-linux-gnu

[bergner at gcc dot gnu.org]

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

--- Comment #6 from Peter Bergner <bergner at gcc dot gnu.org> ---
Created attachment 32828
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32828&action=edit
Test case that errors out with invalid assembly on big-endian



[bergner@makalu-lp1 BUGS]$
/home/bergner/gcc/build/gcc-fsf-mainline-r210518/gcc/xg++
-B/home/bergner/gcc/build/gcc-fsf-mainline-r210518/gcc/ -c -O2 -m64 pr61231.ii 
[bergner@makalu-lp1 BUGS]$
/home/bergner/gcc/build/gcc-fsf-mainline-r210520/gcc/xg++
-B/home/bergner/gcc/build/gcc-fsf-mainline-r210520/gcc -c -O2 -m64 pr61231.ii 
/tmp/ccNkPBLm.s: Assembler messages:
/tmp/ccNkPBLm.s:65: Error: operand out of domain (2 is not a multiple of 4)

The problematic assembly is:

        lwa 3,2(31)

The problem is that the offset for the lwa instruction needs to be a multiple
of 4.  I'm not exactly sure that Vlad's patch is at fault here.  It could be
that it's just exposing a latent bug?

[Bug target/61231] [4.9/4.10 Regression] bootstrap comparision failure on powerpc64le-linux-gnu

[bergner at gcc dot gnu.org]

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

--- Comment #7 from Peter Bergner <bergner at gcc dot gnu.org> ---
I meant to add that the issue I'm seeing on BE is due to the same patch that
Matthias is having a problem with, namely 210520 (trunk) 210519 (4.9).

[Bug target/61231] [4.9/4.10 Regression] bootstrap comparision failure on powerpc64le-linux-gnu

[amodra at gmail dot com]

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

Alan Modra <amodra at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2014-05-21
                 CC|                            |amodra at gmail dot com
           Assignee|unassigned at gcc dot gnu.org      |amodra at gmail dot com
     Ever confirmed|0                           |1

--- Comment #9 from Alan Modra <amodra at gmail dot com> ---
So, what's happening here on the testcase is that before r210519, from the ira
dump for pseudo reg 171 we have

a15 (r171,l0) best GENERAL_REGS, allocno GENERAL_REGS

a15(r171,l0) costs: BASE_REGS:0,0 GENERAL_REGS:0,0 NON_SPECIAL_REGS:3264,3264
LINK_REGS:1224,1224 CTR_REGS:1224,1224 LINK_OR_CTR_REGS:1224,1224
SPECIAL_REGS:1224,1224 SPEC_OR_GEN_REGS:1224,1224 NON_FLOAT_REGS:4896,4896
ALL_REGS:4896,4896 MEM:0,0

and after

a15 (r171,l0) best NO_REGS, allocno NO_REGS

a15(r171,l0) costs: BASE_REGS:0,0 GENERAL_REGS:0,0 NON_SPECIAL_REGS:1224,1224
LINK_REGS:1224,1224 CTR_REGS:1224,1224 LINK_OR_CTR_REGS:1224,1224
SPECIAL_REGS:1224,1224 SPEC_OR_GEN_REGS:1224,1224 NON_FLOAT_REGS:2448,2448
ALL_REGS:2448,2448 MEM:-320,-320

(hmm, negative cost, is that really allowed??)

Going into reload, both before and after r210519, we have

(insn 57 60 59 10 (set (reg:SI 171 [ MEM[(char * {ref-all})data_p_9(D) + 2B] ])
        (mem:SI (plus:DI (reg/v/f:DI 151 [ data_p ])
                (const_int 2 [0x2])) [0 MEM[(char * {ref-all})data_p_9(D) +
2B]+0 S4 A8])) /src/tmp/pr61231.ii:68 442 {*movsi_internal1}
     (expr_list:REG_EQUIV (mem:SI (plus:DI (reg/v/f:DI 151 [ data_p ])
                (const_int 2 [0x2])) [0 MEM[(char * {ref-all})data_p_9(D) +
2B]+0 S4 A8])
        (nil)))
(insn 59 57 61 10 (set (reg:DI 3 3)
        (sign_extend:DI (reg:SI 171 [ MEM[(char * {ref-all})data_p_9(D) + 2B]
]))) /src/tmp/pr61231.ii:68 29 {*extendsidi2_nocell}
     (expr_list:REG_DEAD (reg:SI 171 [ MEM[(char * {ref-all})data_p_9(D) + 2B]
])
        (nil)))

So before r210519, reload puts reg 171 into a gpr and we keep both insn 57
(which results in lwz) and insn 59 (which results in extsw).  After r210519,
insn 57 is deleted because reg 171 has an equivalent mem, and the mem from insn
57 is inserted into insn 59.  This matches the "m" constraint on
extendsidi2_nocell so reload thinks everything is good.  THE lwa_operand
PREDICATE IS NOT CHECKED AGAIN!  Which is standard reload behaviour..

This is a bug in rs6000.md.  extendsidi2_nocell ought to be using the "Y"
constraint, and there needs to be a small modification to mem_operand_gpr to
make it work with SImode.

[Bug target/61231] [4.9/4.10 Regression] bootstrap comparision failure on powerpc64le-linux-gnu

[vmakarov at gcc dot gnu.org]

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

--- Comment #10 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
(In reply to Alan Modra from comment #9)
> So, what's happening here on the testcase is that before r210519, from the
> ira dump for pseudo reg 171 we have
> 
> a15 (r171,l0) best GENERAL_REGS, allocno GENERAL_REGS
> 
> a15(r171,l0) costs: BASE_REGS:0,0 GENERAL_REGS:0,0
> NON_SPECIAL_REGS:3264,3264 LINK_REGS:1224,1224 CTR_REGS:1224,1224
> LINK_OR_CTR_REGS:1224,1224 SPECIAL_REGS:1224,1224 SPEC_OR_GEN_REGS:1224,1224
> NON_FLOAT_REGS:4896,4896 ALL_REGS:4896,4896 MEM:0,0
> 
> and after
> 
> a15 (r171,l0) best NO_REGS, allocno NO_REGS
> 
> a15(r171,l0) costs: BASE_REGS:0,0 GENERAL_REGS:0,0
> NON_SPECIAL_REGS:1224,1224 LINK_REGS:1224,1224 CTR_REGS:1224,1224
> LINK_OR_CTR_REGS:1224,1224 SPECIAL_REGS:1224,1224 SPEC_OR_GEN_REGS:1224,1224
> NON_FLOAT_REGS:2448,2448 ALL_REGS:2448,2448 MEM:-320,-320
> 
> (hmm, negative cost, is that really allowed??)
> 
>

Yes, it is allowed.  It might be a saving.  For example, if you have insn
loading pseudo from a equivalent memory.  Assigning the equivalent memory will
remove the insn.

There is also a discrepancy between LRA and reload in many cases (e.g. in
treatment constraints with only 'm').  The patch which triggered the bug was
for x86 using LRA.  PPC is using reload by default.  I guess switching to LRA
would remove some future troubles.

[Bug target/61231] [4.9/4.10 Regression] bootstrap comparision failure on powerpc64le-linux-gnu

[bergner at gcc dot gnu.org]

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

--- Comment #11 from Peter Bergner <bergner at gcc dot gnu.org> ---
Looking at some stage2 and stage3 obj files that Matthias sent me, there are
actual code differences between the stage2 and stage3 compiles.  The following
code shows one example.  The difference seems to be that the stage2 compile
uses an extra non-volatile register to hold one formal argument that will be
used as a param for one of the calls, while the stage 3 compile stores it onto
the stack and then reloads it just before it's used as a param.

Vlad, can you think of any way that your change might affect this?  It seems
suspicious that your patch forces some pseudos to memory similar to what we are
seeing here.

Matthias, you said on some systems, you don't see this issue, while on some
others (newer?) you do.  Can you explain what is different between your good
and failing builds?

./stage2-libiberty/pic/xstrdup.o:     | ./stage3-libiberty/pic/xstrdup.o:     

<xstrdup>:                              <xstrdup>:
   0:   addis   r2,r12,0                   0:   addis   r2,r12,0
   4:   addi    r2,r2,0                    4:   addi    r2,r2,0 
   8:   mflr    r0                         8:   mflr    r0
   c:   std     r30,-16(r1)           |    c:   std     r31,-8(r1)
  10:   std     r31,-8(r1)            |   10:   std     r0,16(r1)
  14:   mr      r30,r3                |   14:   stdu    r1,-64(r1)
  18:   std     r0,16(r1)             |   18:   std     r3,32(r1)
  1c:   stdu    r1,-48(r1)            |   1c:   bl      1c <xstrdup+0x1c>
  20:   bl      20 <xstrdup+0x20>     |   20:   nop
  24:   nop                           |   24:   addi    r31,r3,1
  28:   addi    r31,r3,1              |   28:   mr      r3,r31  
  2c:   mr      r3,r31                |   2c:   bl      2c <xstrdup+0x2c>
  30:   bl      30 <xstrdup+0x30>     |   30:   nop
  34:   nop                           |   34:   ld      r4,32(r1)
  38:   mr      r4,r30                |   38:   mr      r5,r31  
  3c:   mr      r5,r31                |   3c:   bl      3c <xstrdup+0x3c>
  40:   bl      40 <xstrdup+0x40>     |   40:   nop
  44:   nop                           |   44:   addi    r1,r1,64
  48:   addi    r1,r1,48              |   48:   ld      r0,16(r1)
  4c:   ld      r0,16(r1)             |   4c:   ld      r31,-8(r1)
  50:   ld      r30,-16(r1)           |   50:   mtlr    r0
  54:   ld      r31,-8(r1)            |   54:   blr
  58:   mtlr    r0                    |   58:   .long 0x0
  5c:   blr                           |   5c:   .long 0x1000000
  60:   .long 0x0                     |   60:   .long 0x180
  64:   .long 0x1000000               <
  68:   .long 0x280                   <

[Bug target/61231] [4.9/4.10 Regression] bootstrap comparision failure on powerpc64le-linux-gnu

[vmakarov at gcc dot gnu.org]

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

--- Comment #12 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
(In reply to Peter Bergner from comment #11)

> Vlad, can you think of any way that your change might affect this?  It seems
> suspicious that your patch forces some pseudos to memory similar to what we
> are seeing here.
> 

Sorry, for the troubles. I believe now it might affect.  People have also
problem with aarch64 after the patch.  I am working on it.  If I do not solve
the problem soon, I'll revert the patch.

[Bug target/61231] [4.9/4.10 Regression] bootstrap comparision failure on powerpc64le-linux-gnu

[amodra at gcc dot gnu.org]

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

--- Comment #13 from Alan Modra <amodra at gcc dot gnu.org> ---
Author: amodra
Date: Fri May 23 01:17:41 2014
New Revision: 210835

URL: http://gcc.gnu.org/viewcvs?rev=210835&root=gcc&view=rev
Log:
    PR target/61231
    * config/rs6000/rs6000.c (mem_operand_gpr): Handle SImode.
    * config/rs6000/rs6000.md (extendsidi2_lfiwax, extendsidi2_nocell):
    Use "Y" constraint rather than "m".


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

[Bug target/61231] [4.9/4.10 Regression] bootstrap comparision failure on powerpc64le-linux-gnu

[amodra at gcc dot gnu.org]

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

--- Comment #14 from Alan Modra <amodra at gcc dot gnu.org> ---
Author: amodra
Date: Fri May 23 01:24:08 2014
New Revision: 210836

URL: http://gcc.gnu.org/viewcvs?rev=210836&root=gcc&view=rev
Log:
    PR target/61231
    * config/rs6000/rs6000.c (mem_operand_gpr): Handle SImode.
    * config/rs6000/rs6000.md (extendsidi2_lfiwax, extendsidi2_nocell):
    Use "Y" constraint rather than "m".


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

[Bug target/61231] [4.9/4.10 Regression] bootstrap comparision failure on powerpc64le-linux-gnu

[amodra at gcc dot gnu.org]

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

--- Comment #15 from Alan Modra <amodra at gcc dot gnu.org> ---
Author: amodra
Date: Fri May 23 01:28:23 2014
New Revision: 210837

URL: http://gcc.gnu.org/viewcvs?rev=210837&root=gcc&view=rev
Log:
    PR target/61231
    * config/rs6000/rs6000.c (mem_operand_gpr): Handle SImode.
    * config/rs6000/rs6000.md (extendsidi2_lfiwax, extendsidi2_nocell):
    Use "Y" constraint rather than "m".


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

[Bug target/61231] [4.9/4.10 Regression] bootstrap comparision failure on powerpc64le-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Is this fixed now?

[Bug target/61231] [4.9/4.10 Regression] bootstrap comparision failure on powerpc64le-linux-gnu

[doko at gcc dot gnu.org]

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

Matthias Klose <doko at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #17 from Matthias Klose <doko at gcc dot gnu.org> ---
yes, this works now on the 4.9 branch and the trunk.