[Bug target/96015] New: [regression] gcc-10.1.0 miscompiles Python on hppa

[Bug target/96015] New: [regression] gcc-10.1.0 miscompiles Python on hppa

[slyfox at inbox dot ru]

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

            Bug ID: 96015
           Summary: [regression] gcc-10.1.0 miscompiles Python on hppa
           Product: gcc
           Version: 10.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: slyfox at inbox dot ru
                CC: dave.anglin at bell dot net, law at redhat dot com
  Target Milestone: ---
            Target: hppa2.0-unknown-linux-gnu

Originally reported as https://bugs.gentoo.org/729570 where gcc-10.1.0
miscompiles Python into generating invalid bytecode. I shrunk Python's code
into single file that illustrates the problem:

// $ cat bug_test.c
/*
   The test is extracted from Python-3.9.0 miscompilation
   on hppa2.0: https://bugs.gentoo.org/729570

   Original bug happens as an invalid bytecode generation
   due to bad results from 'long_richcompare(0xFFFFffff, 1, EQ)' calls.

Failure example:
  $ hppa2.0-unknown-linux-gnu-gcc -lm -Wsign-compare -Wall -O1 bug_test.c -o
good-bug
  $ hppa2.0-unknown-linux-gnu-gcc -lm -Wsign-compare -Wall -O2 bug_test.c -o
bad-bug
  $ ./good-bug
  long_richcompare(2, 1, EQ) = FALSE (expect FALSE)
  $ ./bad-bug
  long_richcompare(2, 1, EQ) = TRUE (expect FALSE)

*/

// We use '__attribute__((noipa));' aggressively to simulate
// unavailable function definitions from outside translation units.

static int cmp(int *lhs, int *rhs)
{
    int sign = *lhs - *rhs;

    // semantically this should be 'return 0;' but this condition is not
    // supposed to trigger on our input data.
    if (sign == 0) return 1;

    return sign;
}

static int yes(void) __attribute__((noipa));
static int yes(void) { return 1; }

static int long_richcompare(int *self, int *other, int op)
__attribute__((noipa));
static int long_richcompare(int *self, int *other, int op)
{
    int result;

    if (!yes() || !yes())
        return 0;

    if (self == other)
        result = 0;
    else
        result = cmp(self, other);

    // has to force jump table
    switch (op) {
        // only 0 case is used on actual data
        case 0: return (result == 0);

        case 1: return 0;
        case 3: return 0;
        case 5: if (result == 0) return 1; else return 0;
        default:
            __builtin_unreachable();
    }
}

#include <stdio.h>

int main() {
    int l = 2;
    int r = 1;

    int res = long_richcompare(&l, &r, 0);
    printf("long_richcompare(2, 1, EQ) = %s (expect FALSE)\n", res ? "TRUE" :
"FALSE");
}

[Bug target/96015] [regression] gcc-10.1.0 miscompiles Python on hppa

[slyfox at inbox dot ru]

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

--- Comment #1 from Sergei Trofimovich <slyfox at inbox dot ru> ---
Created attachment 48814
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48814&action=edit
bug_test.c

Selfcontained example.

[Bug target/96015] [regression] gcc-10.1.0 miscompiles Python on hppa

[slyfox at inbox dot ru]

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

--- Comment #2 from Sergei Trofimovich <slyfox at inbox dot ru> ---
Happens both on gcc-10.1.0 and gcc from main development branch. Here is the
example of -O1/-O2 difference:

$ hppa2.0-unknown-linux-gnu-gcc -lm -Wsign-compare -Wall -fno-PIE -no-pie
-fno-stack-protector -O1 bug_test.c -o good-bug
$ hppa2.0-unknown-linux-gnu-gcc -lm -Wsign-compare -Wall -fno-PIE -no-pie
-fno-stack-protector -O2 bug_test.c -o bad-bug

$ ./good-bug
long_richcompare(2, 1, EQ) = FALSE (expect FALSE)
$ ./bad-bug
long_richcompare(2, 1, EQ) = TRUE (expect FALSE)

GCC was built as:

$ hppa2.0-unknown-linux-gnu-gcc -v
Reading specs from /home/slyfox/dev/git/gcc-hppa2.0/gcc/specs
COLLECT_GCC=/home/slyfox/dev/git/gcc-hppa2.0/gcc/xgcc
COLLECT_LTO_WRAPPER=/home/slyfox/dev/git/gcc-hppa2.0/gcc/lto-wrapper
Target: hppa2.0-unknown-linux-gnu
Configured with: ../gcc/configure --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=hppa2.0-unknown-linux-gnu
--prefix=/home/slyfox/dev/git/gcc-hppa2.0/../gcc-hppa2.0-installed
--with-sysroot=/usr/hppa2.0-unknown-linux-gnu --disable-bootstrap
--enable-languages=c --disable-nls CFLAGS='-O2 -g' CXXFLAGS='-O2 -g'
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.0.0 20200701 (experimental) (GCC)

[Bug target/96015] [regression] gcc-10.1.0 miscompiles Python on hppa

[slyfox at inbox dot ru]

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

--- Comment #3 from Sergei Trofimovich <slyfox at inbox dot ru> ---
Reproducible on both qemu-hppa and on real "PA8600 (PCX-W+) 9000/785/C3600"
machine.

[Bug target/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |10.2
           Keywords|                            |wrong-code
            Summary|[regression] gcc-10.1.0     |[10/11 Regression]
                   |miscompiles Python on hppa  |gcc-10.1.0 miscompiles
                   |                            |Python on hppa

[Bug target/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

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

--- Comment #4 from Martin Liška <marxin at gcc dot gnu.org> ---
Thank you for the report.
What system do you use that can cross compile (and link) the test-case in order
to run it in qemu?

[Bug target/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa

[slyfox at inbox dot ru]

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

--- Comment #5 from Sergei Trofimovich <slyfox at inbox dot ru> ---
I ran the test in qemu-hppa (qemu user binary emulation) against Gentoo's
hppa2.0 root system as:
    /usr/bin/qemu-hppa -L /usr/hppa2.0-unknown-linux-gnu/ "$@"
where /usr/hppa2.0-unknown-linux-gnu/ is a hppa SYSROOT.

Cross-compiler is generated with Gentoo's 'crossdev' tool as:
   # crossdev hppa2.0-unknown-linux-gnu
The command builds cross-binutils, cross-gcc with
--sysroot=/usr/hppa2.0-unknown-linux-gnu/ and puts glibc into
/usr/hppa2.0-unknown-linux-gnu/.

Full native root system is also at
http://distfiles.gentoo.org/releases/hppa/autobuilds/current-stage3-hppa2.0/
(stage3-hppa2.0-*.tar.bz2 tarballs). Should be good enough to be used for
qemu-hppa as-is.

I also plan to pass through the assembly dump this evening to get the idea
where incorrect code got generated to spare you the debugging.

[Bug target/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa

[slyfox at inbox dot ru]

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

--- Comment #6 from Sergei Trofimovich <slyfox at inbox dot ru> ---
Created attachment 48816
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48816&action=edit
bad-bug.S

bad-bug.S is miscompiled file generated by main gcc (not clear what is wrong
yet).

Generated as:
    $gcc/xgcc -B$gcc/gcc -lm -Wsign-compare -Wall -fno-PIE -no-pie
-fno-stack-protector -O2 -S bug_test.c -o bad-bug.S

[Bug target/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška <marxin at gcc dot gnu.org> ---
There's ASM diff in between GCC 9 and 10 version:

diff -u good.s bad.s
--- good.s      2020-07-01 15:04:58.315839436 +0200
+++ bad.s       2020-07-01 15:04:30.684040487 +0200
@@ -30,7 +30,7 @@
 .L15:
        ldi 0,%r28
 .L3:
-.L25:
+.L26:
        ldw -84(%r30),%r2
        ldw -60(%r30),%r4
        ldw -56(%r30),%r3
@@ -39,16 +39,14 @@
 .L22:
        bl yes,%r2
        nop
-       comib,=,n 0,%r28,.L25
+       comib,=,n 0,%r28,.L26
        ldi 0,%r28
-       comclr,<> %r4,%r5,%r0
-       b,n .L23
        comiclr,<< 5,%r3,%r0
-       b,n .L24
-.L6:
-.L23:
-       comib,<< 5,%r3,.L26
+       b,n .L25
+.L12:
+       b .L3
        ldi 1,%r28
+.L25:
        ldil L'.L8,%r28
        ldo R'.L8(%r28),%r28
        ldwx,s %r3(%r28),%r28
@@ -65,34 +63,6 @@
        .word .L12
        .end_brtab
        .text
-.L12:
-       ldi 1,%r28
-.L26:
-       ldw -84(%r30),%r2
-       ldw -60(%r30),%r4
-       ldw -56(%r30),%r3
-       bv %r0(%r2)
-       ldwm -64(%r30),%r5
-.L24:
-       ldil L'.L11,%r28
-       ldo R'.L11(%r28),%r28
-       ldwx,s %r3(%r28),%r28
-       bv,n %r0(%r28)
-       .section        .rodata
-       .align 4
-.L11:
-       .begin_brtab
-       .word .L14
-       .word .L15
-       .word .L6
-       .word .L15
-       .word .L6
-       .word .L15
-       .end_brtab
-       .text
-.L14:
-       b .L3
-       copy %r3,%r28
        .EXIT
        .PROCEND
        .size   long_richcompare, .-long_richcompare
@@ -143,4 +113,4 @@
        .EXIT
        .PROCEND
        .size   main, .-main
-       .ident  "GCC: (SUSE Linux) 9.3.1 20200406 [revision
6db837a5288ee3ca5ec504fbd5a765817e556ac2]"
+       .ident  "GCC: (SUSE Linux) 10.1.1 20200625 [revision
c91e43e9363bd119a695d64505f96539fa451bf2]"

[Bug target/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa

[marxin at gcc dot gnu.org]

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

--- Comment #8 from Martin Liška <marxin at gcc dot gnu.org> ---
And first change happens in pr96015.c.299r.bbro which is likely a reason why a
jump table is partially copied.

[Bug target/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa

[slyfox at inbox dot ru]

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

--- Comment #9 from Sergei Trofimovich <slyfox at inbox dot ru> ---
(In reply to Martin Liška from comment #7)
> There's ASM diff in between GCC 9 and 10 version:
> 
> diff -u good.s bad.s
> --- good.s	2020-07-01 15:04:58.315839436 +0200
> +++ bad.s	202
0-07-01 15:04:30.684040487 +0200

Hm, interesting! I think both these files are broken. Let's me try to elaborate
b annotating bad-bug.S. All the test does is to print result of comparison of
'2' and '1' stored in memory:

    *lhs = 2; *rhs = 1;
    int sign = *lhs - *rhs;
    return sign;

But in bad-bug.S we never read from memory! (IPA is disabled to make functions
somewhat opaque):

"""
main:
        ldi 2,%r28
        stw %r2,-20(%r30)
        ldo 64(%r30),%r30
        stw %r28,-52(%r30) ; store '2' in RAM
        ldo -56(%r30),%r19 ; get RAM address
        ldi 1,%r28
        ldi 0,%r24         ; arg3 = '0'
        stw %r28,-56(%r30) ; store '1' in RAM
        copy %r19,%r25     ; arg1 = &2
        bl long_richcompare,%r2
        ldo -52(%r30),%r26 ; arg0 = &1 (delay slot, executed before branch)
... (all ok so far)
long_richcompare:
        stw %r2,-20(%r30)
        stwm %r5,64(%r30)
        copy %r26,%r5        ; arg0 = &1
        stw %r4,-60(%r30)
        copy %r25,%r4        ; arg1 = &2
        stw %r3,-56(%r30)
        bl yes,%r2
        copy %r24,%r3        ; arg2 = 0 (delay slot, is it safe in general to 
        comiclr,= 0,%r28,%r0 ; if (!yes()) ...
        b,n .L22             ; go to actual comparison
.L15:
        ldi 0,%r28           ; fall through to 'return 0;' (not interesting)
.L3:
.L26:
        ldw -84(%r30),%r2
        ldw -60(%r30),%r4
        ldw -56(%r30),%r3
        bv %r0(%r2)
        ldwm -64(%r30),%r5
.L22:
        bl yes,%r2
        nop
        comib,=,n 0,%r28,.L26 ; if ( .. || !yes()) return 0; (not interesting)
        ldi 0,%r28
        comiclr,<< 5,%r3,%r0 ; check if 'arg3 < 5' to fit into jump table,
otherwise skip (nullify) next instruction and run .L3
        b,n .L25             ; handle jump table
.L12:
        b .L3    ; return 0; (not interesting, fall through)
        ldi 1,%r28
.L25:
        ldil L'.L8,%r28        ;
        ldo R'.L8(%r28),%r28   ; load jump table address
        ldwx,s %r3(%r28),%r28  ; load target at .L8[arg2 * 4]
        bv,n %r0(%r28)         ; jump on target, should be .L12
        .section        .rodata
        .align 4
.L8:
        .begin_brtab
        .word .L12
        .word .L15
        .word .L12
        .word .L15
        .word .L12
        .word .L12
        .end_brtab
"""

Note: during the whole execution at no point in time 'long_richcompare()' tried
to dereference arg0 and arg1 inputs (%r4, %r5 registers).

For comparison compiling with -O1 keeps the loads around:

good-bug.S:

"""
main:                       ; same as above
        stw %r2,-20(%r30)
        ldo 64(%r30),%r30
        ldi 2,%r28
        stw %r28,-56(%r30)
        ldi 1,%r28
        ldo -52(%r30),%r19
        stw %r28,-52(%r30)
        ldi 0,%r24
        copy %r19,%r25
        bl long_richcompare,%r2
        ldo -56(%r30),%r26
...
long_richcompare:
        stw %r2,-20(%r30)
        stwm %r5,64(%r30)
        stw %r4,-60(%r30)
        stw %r3,-56(%r30)
        copy %r26,%r4       ; arg0
        copy %r25,%r3       ; arg1
        bl yes,%r2
        copy %r24,%r5       ; arg2
        or,= %r28,%r0,%r28  ; result = 0
        b,n .L11            ; 
.L2:
        ldw -84(%r30),%r2
.L12:
        ldw -60(%r30),%r4
        ldw -56(%r30),%r3
        bv %r0(%r2)         ; return
        ldwm -64(%r30),%r5
.L11:
        bl yes,%r2
        nop
        movb,= %r28,%r28,.L12 ; if(!yes()) return ...
        ldw -84(%r30),%r2
        comb,=,n %r3,%r4,.L9  ; if(arg0 == arg1) (at branch) diff = 0;
        ldw 0(%r4),%r28       
        ldw 0(%r3),%r19
        sub %r28,%r19,%r28    ; diff = *arg0 - *arg1
        comiclr,<> 0,%r28,%r0
        ldi 1,%r28
.L4:
        comiclr,>>= 5,%r5,%r0
        b,n .L6
        ldil L'.L7,%r19
        ldo R'.L7(%r19),%r19
        ldwx,s %r5(%r19),%r19
        bv,n %r0(%r19)        ; handle jump table, at .L8
        .section        .rodata
        .align 4
.L7:
        .begin_brtab
        .word .L8
        .word .L10
        .word .L6
        .word .L10
        .word .L6
        .word .L6
        .end_brtab
        .text
.L9:
        b .L4
        ldi 0,%r28
.L8:
        comiclr,<> 0,%r28,%r28    ; if (result == 0)
        ldi 1,%r28                ;     result = 1;
        b .L12                    ; return
        ldw -84(%r30),%r2
.L6:
        comiclr,<> 0,%r28,%r28
        ldi 1,%r28
        b .L12
        ldw -84(%r30),%r2
.L10:
        b .L2
        ldi 0,%r28
"""

[Bug target/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa

[slyfox at inbox dot ru]

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

--- Comment #10 from Sergei Trofimovich <slyfox at inbox dot ru> ---
Created attachment 48820
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48820&action=edit
good-bug.S

[Bug target/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa

[slyfox at inbox dot ru]

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

--- Comment #11 from Sergei Trofimovich <slyfox at inbox dot ru> ---
Looking at -fdump-tree-all:
    $gcc/xgcc -B$gcc -lm -Wsign-compare -Wall -fno-PIE -no-pie
-fno-stack-protector -O2 -S bug_test.c -o bad-bug.S -fdump-tree-all

I see that stores are eliminated at 'bad-bug.c.191t.cddce3' stage:

Was (at bad-bug.c.190t.dse3):

"""
__attribute__((noipa, noinline, noclone, no_icf))
long_richcompare (int * self, int * other, int op)
{
  int sign;
  int result;
  int _1;
  int _2;
  int _5;
  int prephitmp_6;
  int _13;
  int _16;

  <bb 2> [local count: 1073741823]:
  _1 = yes ();
  if (_1 == 0)
    goto <bb 11>; [51.12%]
  else
    goto <bb 3>; [48.88%]

  <bb 3> [local count: 524844999]:
  _2 = yes ();
  if (_2 == 0)
    goto <bb 11>; [34.00%]
  else
    goto <bb 4>; [66.00%]

  <bb 4> [local count: 346397698]:
  if (self_11(D) == other_12(D))
    goto <bb 7>; [30.00%]
  else
    goto <bb 5>; [70.00%]

  <bb 5> [local count: 242478389]:
  _13 = *self_11(D);
  _16 = *other_12(D);
  sign_17 = _13 - _16;
  if (sign_17 == 0)
    goto <bb 13>; [34.00%]
  else
    goto <bb 6>; [66.00%]

  <bb 6> [local count: 160035736]:
  goto <bb 13>; [100.00%]

  <bb 7> [local count: 103919309]:
  switch (op_14(D)) <default: <L12> [33.33%], case 0: <L6> [16.67%], case 1:
<L29> [33.33%], case 3: <L29> [33.33%], case 5: <L14> [16.67%]>

  <bb 8> [local count: 23093180]:
<L29>:
  goto <bb 12>; [100.00%]

  <bb 9> [local count: 115465900]:
  # prephitmp_6 = PHI <0(13), 1(7)>
<L6>:
  goto <bb 12>; [100.00%]

  <bb 10> [count: 0]:
<L12>:
  __builtin_unreachable ();

  <bb 11> [local count: 727344125]:

  <bb 12> [local count: 1073741824]:
  # _5 = PHI <0(13), prephitmp_6(9), 0(11), 0(8), 1(7)>
<L14>:
  return _5;

  <bb 13> [local count: 242478389]:
  # result_21 = PHI <1(5), sign_17(6)>
  switch (op_14(D)) <default: <L12> [33.33%], case 0: <L6> [16.67%], case 1:
<L14> [50.00%], case 3: <L14> [50.00%], case 5: <L14> [50.00%]>
}
"""

Became (at bad-bug.c.191t.cddce3):

"""
Removing basic block 5
__attribute__((noipa, noinline, noclone, no_icf))
long_richcompare (int * self, int * other, int op)
{
  int sign;
  int result;
  int _1;
  int _2;
  int _5;
  int prephitmp_6;

  <bb 2> [local count: 1073741823]:
  _1 = yes ();
  if (_1 == 0)
    goto <bb 9>; [51.12%]
  else
    goto <bb 3>; [48.88%]

  <bb 3> [local count: 524844999]:
  _2 = yes ();
  if (_2 == 0)
    goto <bb 9>; [34.00%]
  else
    goto <bb 4>; [66.00%]

  <bb 4> [local count: 346397698]:
  if (self_11(D) == other_12(D))
    goto <bb 5>; [30.00%]
  else
    goto <bb 11>; [70.00%]

  <bb 5> [local count: 103919309]:
  switch (op_14(D)) <default: <L12> [33.33%], case 0: <L6> [16.67%], case 1:
<L29> [33.33%], case 3: <L29> [33.33%], case 5: <L14> [16.67%]>

  <bb 6> [local count: 23093180]:
<L29>:
  goto <bb 10>; [100.00%]

  <bb 7> [local count: 115465900]:
  # prephitmp_6 = PHI <0(11), 1(5)>
<L6>:
  goto <bb 10>; [100.00%]

  <bb 8> [count: 0]:
<L12>:
  __builtin_unreachable ();

  <bb 9> [local count: 727344125]:

  <bb 10> [local count: 1073741824]:
  # _5 = PHI <0(11), prephitmp_6(7), 0(9), 0(6), 1(5)>
<L14>:
  return _5;

  <bb 11> [local count: 242478389]:
  switch (op_14(D)) <default: <L12> [33.33%], case 0: <L6> [16.67%], case 1:
<L14> [50.00%], case 3: <L14> [50.00%], case 5: <L14> [50.00%]>

}
"""


Note: the following block disappeared completely:
"""
  <bb 5> [local count: 242478389]:
  _13 = *self_11(D);
  _16 = *other_12(D);
"""

[Bug target/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa

[law at redhat dot com]

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

--- Comment #12 from Jeffrey A. Law <law at redhat dot com> ---
The block in question goes away because it serves no purpose:

  <bb 5> [local count: 242478389]:
  _13 = *self_11(D);
  _16 = *other_12(D);
  sign_17 = _13 - _16;
  if (sign_17 == 0)
    goto <bb 13>; [34.00%]
  else
    goto <bb 6>; [66.00%]

  <bb 6> [local count: 160035736]:
  goto <bb 13>; [100.00%]


Note that bb6 just transfers control to bb13 with no other side effects.  As a
result bb5 is equivalent to:

  <bb 5> [local count: 242478389]:
  _13 = *self_11(D);
  _16 = *other_12(D);
  sign_17 = _13 - _16;
  if (sign_17 == 0)
    goto <bb 13>; [34.00%]
  else
    goto <bb 13>; [66.00%]


With both arms of the conditional going to the same place and no other uses of
sign_17 the whole block just turns into

  goto <bb13>;

I see nothing wrong with what was done by DCE.  The problem must be earlier in
the optimizer pipeline.

[Bug target/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa

[law at redhat dot com]

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

--- Comment #13 from Jeffrey A. Law <law at redhat dot com> ---
Hmm, there's a control dependency though in bb13:

  <bb 13> [local count: 242478389]:
  # result_21 = PHI <1(5), sign_17(6)>
  switch (op_14(D)) <default: <L12> [33.33%], case 0: <L6> [16.67%], case 1:
<L14> [50.00%], case 3: <L14> [50.00%], case 5: <L14> [50.00%]>
}

So I'd hazard a guess that sign_17 either has the value 1 here or that
result_21 is unused, otherwise you're right that cddce shouldn't remove the
block.

[Bug target/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa

[slyfox at inbox dot ru]

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

--- Comment #14 from Sergei Trofimovich <slyfox at inbox dot ru> ---
Created attachment 48821
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48821&action=edit
bad-bug.c.191t.cddce3

bad-bug.c.191t.cddce3 is the full file generated by -fdump-tree-all-all.

[Bug target/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa

[slyfox at inbox dot ru]

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

--- Comment #15 from Sergei Trofimovich <slyfox at inbox dot ru> ---
Created attachment 48822
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48822&action=edit
bad-bug.c.190t.dse3

bad-bug.c.190t.dse3 previous tree phase for comparison.

[Bug target/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa

[slyfox at inbox dot ru]

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

--- Comment #16 from Sergei Trofimovich <slyfox at inbox dot ru> ---
If I looks at bad-bug.c.190t.dse3 I see 'self' and 'other' refer to the same
.MEM_10 memory location in 'basic block 5'. I think it should not, 'basic block
4' jumps into bb5 only when self != other. Do I read it correctly?

;;   basic block 4, loop depth 0, count 346397698 (estimated locally), maybe
hot
;;    prev block 3, next block 5, flags: (NEW, REACHABLE, VISITED)
;;    pred:       3 [66.0% (guessed)]  count:346397697 (estimated locally)
(FALSE_VALUE,EXECUTABLE)
  if (self_11(D) == other_12(D))
    goto <bb 7>; [30.00%]
  else
    goto <bb 5>; [70.00%]
;;    succ:       7 [30.0% (guessed)]  count:103919308 (estimated locally)
(TRUE_VALUE,EXECUTABLE)
;;                5 [70.0% (guessed)]  count:242478390 (estimated locally)
(FALSE_VALUE,EXECUTABLE)

;;   basic block 5, loop depth 0, count 242478389 (estimated locally), maybe
hot
;;    prev block 4, next block 6, flags: (NEW, REACHABLE, VISITED)
;;    pred:       4 [70.0% (guessed)]  count:242478390 (estimated locally)
(FALSE_VALUE,EXECUTABLE)
  # VUSE <.MEM_10>
  _13 = *self_11(D);
  # VUSE <.MEM_10>
  _16 = *other_12(D);
  sign_17 = _13 - _16;
  if (sign_17 == 0)
    goto <bb 13>; [34.00%]
  else
    goto <bb 6>; [66.00%]
;;    succ:       13 [34.0% (guessed)]  count:82442653 (estimated locally)
(TRUE_VALUE,EXECUTABLE)
;;                6 [66.0% (guessed)]  count:160035736 (estimated locally)
(FALSE_VALUE,EXECUTABLE)

[Bug target/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2020-07-02

--- Comment #17 from Martin Liška <marxin at gcc dot gnu.org> ---
Well, I'm looking at the optimized tree dump for hppa and seems fine to me:

__attribute__((noipa, noinline, noclone, no_icf))
long_richcompare (int * self, int * other, int op)
{
  int _1;
  int _2;
  int _5;
  int prephitmp_6;

  <bb 2> [local count: 1073741823]:
  _1 = yes ();
  if (_1 == 0)
    goto <bb 9>; [51.12%]
  else
    goto <bb 3>; [48.88%]

  <bb 3> [local count: 524844999]:
  _2 = yes ();
  if (_2 == 0)
    goto <bb 9>; [34.00%]
  else
    goto <bb 4>; [66.00%]

  <bb 4> [local count: 346397698]:
  if (self_11(D) == other_12(D))
    goto <bb 5>; [30.00%]
  else
    goto <bb 11>; [70.00%]

  <bb 5> [local count: 103919309]:
  switch (op_14(D)) <default: <L12> [33.33%], case 0: <L6> [16.67%], case 1:
<L14> [33.33%], case 3: <L14> [33.33%], case 5: <L34> [16.67%]>

  <bb 6> [local count: 17319885]:
<L34>:
  goto <bb 10>; [100.00%]

  <bb 7> [local count: 115465900]:
  # prephitmp_6 = PHI <1(5), op_14(D)(11)>
<L6>:
  goto <bb 10>; [100.00%]

  <bb 8> [count: 0]:
<L12>:
  __builtin_unreachable ();

  <bb 9> [local count: 727344125]:

  <bb 10> [local count: 1073741824]:
  # _5 = PHI <1(6), prephitmp_6(7), 0(9), 0(5), 0(11)>
<L14>:
  return _5;

  <bb 11> [local count: 242478389]:
  switch (op_14(D)) <default: <L12> [33.33%], case 0: <L6> [16.67%], case 1:
<L14> [50.00%], case 3: <L14> [50.00%], case 5: <L14> [50.00%]>

}

we go to bb_2, then as yes() == 0 is false, to bb_3 and bb_4.
In bb_4 we jump to bb_11, from which we go to L6 (aka bb_7).
# prephitmp_6 = PHI <1(5), op_14(D)(11)>

here we set prephitmp_6 = op_14 = 0;
go to bb_10, here _5 = prephitmp_6 = 0;
return _5. So the function properly returns 0.

For me tree optimized dump is correct, so likely a target issue.

@Sergei: Is GCC 9 working properly?
Would it be possible to bisect that?

[Bug target/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

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

--- Comment #18 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
If the control flow goes through .L12:

.L12:
        b .L3    ; return 0; (not interesting, fall through)
        ldi 1,%r28

the return value will be 1 since ldi is in the delay slot of the branch.

What happens if you compile with -O2 -fno-delayed-branch instead?

[Bug target/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa

[slyfox at inbox dot ru]

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

--- Comment #19 from Sergei Trofimovich <slyfox at inbox dot ru> ---
Created attachment 48827
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48827&action=edit
bad.S

[Bug target/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa

[slyfox at inbox dot ru]

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

--- Comment #20 from Sergei Trofimovich <slyfox at inbox dot ru> ---
Created attachment 48828
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48828&action=edit
good.S

[Bug target/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa

[slyfox at inbox dot ru]

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

--- Comment #21 from Sergei Trofimovich <slyfox at inbox dot ru> ---
(In reply to Eric Botcazou from comment #18)
> If the control flow goes through .L12:
> 
> .L12:
>         b .L3    ; return 0; (not interesting, fall through)
> 	ldi 1,%r28
> 
> the return value will be 1 since ldi is in the delay slot of the branch.
> 
> What happens if you compile with -O2 -fno-delayed-branch instead?

Oh, -fno-delayed-branch makes test magically pass! Attaching both bad.S and
good.S for comparison.

[Bug target/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa

[slyfox at inbox dot ru]

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

--- Comment #22 from Sergei Trofimovich <slyfox at inbox dot ru> ---
(In reply to Martin Liška from comment #17)
> For me tree optimized dump is correct, so likely a target issue.

Yeah, I agree. I finally understood why memory loads disappear (duh!).

> @Sergei: Is GCC 9 working properly?
> Would it be possible to bisect that?

gcc-9 seems to work, bu I'm not sure if it's intentional or unrelated
optimization passes change the code enough.

I'll try to cook up even smaller example given that -fno-delayed-branch seems
to be a culprit and then bisect gcc.

[Bug target/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa

[slyfox at inbox dot ru]

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

--- Comment #23 from Sergei Trofimovich <slyfox at inbox dot ru> ---
cvise managed to shrink example down to the following:

"""
int b, c;
int a() __attribute__((noipa));
int a(int *d, int *f, int g) {
  int e;
  if (d == f)
    e = 0;
  else
    e = 1;
  switch (g) {
  case 0:
    return e;
  case 1:
  case 3:
  case 5:
    if (e)
      return 10;
  default:
    __builtin_unreachable();
  }
}
int main() { return a(&b, &c, 0); }
"""


$ hppa2.0-unknown-linux-gnu-gcc -O2 bug_test.c -o bad; ./bad; echo $?
0
$ hppa2.0-unknown-linux-gnu-gcc -O2 bug_test.c -o good -fno-delayed-branch;
./good; echo $?
1

gcc-9.2.0 returns '1' in both cases. I'll bisect gcc against this example.

[Bug target/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa

[slyfox at inbox dot ru]

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

--- Comment #24 from Sergei Trofimovich <slyfox at inbox dot ru> ---
(In reply to Sergei Trofimovich from comment #23)
> cvise managed to shrink example down to the following:

For completeness assembly output difference is very clear now:

$ hppa2.0-unknown-linux-gnu-gcc -O2 -S ../bug_test.c -o bug.S
a:
        bv %r0(%r2)
        ldi 0,%r28

$ hppa2.0-unknown-linux-gnu-gcc -O2 -S ../bug_test.c -o bug.S
-fno-delayed-branch
a:
        comclr,<> %r26,%r25,%r0
        b,n .L11
        nop
.L4:
.L12:
        ldil L'.L6,%r28
        ldo R'.L6(%r28),%r28
        ldwx,s %r24(%r28),%r28
        bv,n %r0(%r28)
        .section        .rodata
        .align 4
.L6:
        .begin_brtab
        .word .L8
        .word .L5
        .word .L4
        .word .L5
        .word .L4
        .word .L5
        .end_brtab
        .text
.L5:
        ldi 10,%r28
        bv,n %r0(%r2)
.L11:
        ldi 0,%r28
        bv,n %r0(%r2)
.L8:
        ldi 1,%r28
        bv,n %r0(%r2)

[Bug target/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa

[slyfox at inbox dot ru]

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

--- Comment #25 from Sergei Trofimovich <slyfox at inbox dot ru> ---
(In reply to Sergei Trofimovich from comment #22)
> (In reply to Martin Liška from comment #17)
> > For me tree optimized dump is correct, so likely a target issue.
> 
> Yeah, I agree. I finally understood why memory loads disappear (duh!).
> 
> > @Sergei: Is GCC 9 working properly?
> > Would it be possible to bisect that?
> 
> gcc-9 seems to work, bu I'm not sure if it's intentional or unrelated
> optimization passes change the code enough.
> 
> I'll try to cook up even smaller example given that -fno-delayed-branch
> seems to be a culprit and then bisect gcc.

Bisected down to:

$ git bisect good
8c3785c43d490d4f234e21c9dee6bb1bb8d1dbdf is the first bad commit
commit 8c3785c43d490d4f234e21c9dee6bb1bb8d1dbdf
Author: Martin Liska <mliska@suse.cz>
Date:   Wed Dec 4 11:13:49 2019 +0100

    Initialize a BB count in switch lowering.

    2019-12-04  Martin Liska  <mliska@suse.cz>

            * tree-switch-conversion.c
(switch_decision_tree::try_switch_expansion):
            Initialize count of newly created BB.

    From-SVN: r278959

 gcc/ChangeLog                | 5 +++++
 gcc/tree-switch-conversion.c | 1 +
 2 files changed, 6 insertions(+)

[Bug rtl-optimization/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|target                      |rtl-optimization
             Status|WAITING                     |ASSIGNED

--- Comment #26 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
I'm going to have a look.

[Bug rtl-optimization/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa

[slyfox at inbox dot ru]

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

--- Comment #27 from Sergei Trofimovich <slyfox at inbox dot ru> ---
If it's of any help by slightly expanding case switch I reproduced very similar
problem on both hppa and sh4 (but not on sparc or mips) with:

"""
int b, c;
int a() __attribute__((noipa));
int a(int *d, int *f, int g) {
  int e;
  if (d == f)
    e = 0;
  else
    e = 1;
  switch (g) {
  case 0:
    return e;
  case 1:
      return 7;
  case 2:
      return 8;
  case 3:
      return 8;
  case 4:
      return 1;
  case 5:
    if (e)
      return 10;
  default:
    __builtin_unreachable();
  }
}
int main() { return a(&b, &c, 0); }
"""

$ sh4-unknown-linux-gnu-gcc -fno-PIE -no-pie -fno-stack-protector
-U_FORTIFY_SOURCE -O2 bug_test.c -o bad-bug; ./bad-bug; echo $?
8

$ sh4-unknown-linux-gnu-gcc -fno-PIE -no-pie -fno-stack-protector
-U_FORTIFY_SOURCE -O2 -fno-delayed-branch bug_test.c -o good-bug; ./good-bug;
echo $?
1

bad-bug.S:

a:
        cmp/eq  r4,r5  ; if (d == f) // not our case
        bt/s    .L21   ;     goto .L21; something complicated on jump tables
         mov     #5,r1 ; +delay slot
.L6:
        .align 1
.L13:
        .align 1
.L14:
        rts            ; return 8
         mov     #8,r0 ; +delay slot
        .align 1
.L17:
        rts
         mov     #1,r0
        .align 1
.L21:
        mov     #4,r1
        cmp/hi  r1,r6
        bt/s    .L6
         mov     r6,r2
        mova    .L8,r0
        add     r2,r2
        mov.w   @(r0,r2),r1
        braf    r1
         nop
.L9:
        .align 2
.L8:
        .word   .L10-.L9
        .word   .L15-.L9
        .word   .L14-.L9
        .word   .L14-.L9
        .word   .L17-.L9
        .align 1
.L15:
        rts
        mov     #7,r0
        .align 1
.L10:
        rts
        mov     r6,r0

good-bug.S:

a:
        cmp/eq  r4,r5
        bt      .L21
         mov     #5,r1
        cmp/hi  r1,r6
        bf      .L22
.L6:
        .align 1
.L22:
        mova    .L12,r0
        mov.b   @(r0,r6),r6
        braf    r6
         nop
.L13:
        .align 2
.L12:
        .byte   .L17-.L13
        .byte   .L15-.L13
        .byte   .L14-.L13
        .byte   .L14-.L13
        .byte   .L17-.L13
        .byte   .L11-.L13
        .align 1
.L14:
        mov     #8,r0
        rts
         nop
        .align 1
.L17:
        mov     #1,r0
        rts
        nop
        .align 1
.L21:
        mov     #4,r1
        cmp/hi  r1,r6
        bt      .L6
         mova    .L8,r0
        mov     r6,r2
        add     r2,r2
        mov.w   @(r0,r2),r1
        braf    r1
         nop
.L9:
        .align 2
.L8:
        .word   .L10-.L9
        .word   .L15-.L9
        .word   .L14-.L9
        .word   .L14-.L9
        .word   .L17-.L9
        .align 1
.L15:
        mov     #7,r0
        rts
         nop
        .align 1
.L11:
        mov     #10,r0
        rts
         nop
        .align 1
.L10:
        mov     r6,r0
        rts
         nop

Might be not backend-specific? Or pa and sh have a similar bug.

[Bug rtl-optimization/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa

[marxin at gcc dot gnu.org]

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

--- Comment #28 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to Sergei Trofimovich from comment #25)
> (In reply to Sergei Trofimovich from comment #22)
> > (In reply to Martin Liška from comment #17)
> > > For me tree optimized dump is correct, so likely a target issue.
> > 
> > Yeah, I agree. I finally understood why memory loads disappear (duh!).
> > 
> > > @Sergei: Is GCC 9 working properly?
> > > Would it be possible to bisect that?
> > 
> > gcc-9 seems to work, bu I'm not sure if it's intentional or unrelated
> > optimization passes change the code enough.
> > 
> > I'll try to cook up even smaller example given that -fno-delayed-branch
> > seems to be a culprit and then bisect gcc.
> 
> Bisected down to:
> 
> $ git bisect good
> 8c3785c43d490d4f234e21c9dee6bb1bb8d1dbdf is the first bad commit
> commit 8c3785c43d490d4f234e21c9dee6bb1bb8d1dbdf
> Author: Martin Liska <mliska@suse.cz>
> Date:   Wed Dec 4 11:13:49 2019 +0100
> 
>     Initialize a BB count in switch lowering.
> 
>     2019-12-04  Martin Liska  <mliska@suse.cz>
> 
>             * tree-switch-conversion.c
> (switch_decision_tree::try_switch_expansion):
>             Initialize count of newly created BB.
> 
>     From-SVN: r278959
> 
>  gcc/ChangeLog                | 5 +++++
>  gcc/tree-switch-conversion.c | 1 +
>  2 files changed, 6 insertions(+)

Thank you for the bisection. However, this one is not a culprit commit, it only
made it visible.
Let's wait for can Erik find out.

[Bug rtl-optimization/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa

[ebotcazou at gcc dot gnu.org]

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

--- Comment #29 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
It's again __builtin_unreachable making a mess in the RTL stream:

(note 23 11 24 [bb 3] NOTE_INSN_BASIC_BLOCK)
(jump_insn:TI 24 23 15 (set (pc)
        (if_then_else (leu (reg/v:SI 24 %r24 [orig:99 g ] [99])
                (const_int 5 [0x5]))
            (label_ref:SI 81)
            (pc))) 30 {*pa.md:1413}
     (int_list:REG_BR_PROB 536870916 (nil))
 -> 81)
(code_label 15 24 17 4 (nil) [2 uses])
(barrier 17 15 16)
(note 16 17 81 [bb 4] NOTE_INSN_BASIC_BLOCK)
(code_label 81 16 43 12 (nil) [1 uses])
(note 43 81 25 [bb 5] NOTE_INSN_BASIC_BLOCK)
(jump_insn:TI 25 43 26 (parallel [
            (set (pc)
                (mem:SI (plus:SI (mult:SI (reg/v:SI 24 %r24 [orig:99 g ] [99])
                            (const_int 4 [0x4]))
                        (label_ref 26)) [0  S4 A32]))
            (clobber (reg:SI 28 %r28))
        ]) 198 {casesi32}
     (expr_list:REG_DEAD (reg/v:SI 24 %r24 [orig:99 g ] [99])
        (expr_list:REG_UNUSED (reg:SI 28 %r28)
            (nil)))
 -> 26)

relax_delay_slots sees that jump_insn 24 jumps to the next active instruction
so it proceeds with removing it.  Its target label 81 has only one use so it is
removed too.  At this point delete_related_insns thinks that it can also remove
all the instructions after label 81 down to the next label because of the
presence of barrier 17:

  /* If INSN was a label, delete insns following it if now unreachable.  */

  if (was_code_label && prev && BARRIER_P (prev))
    {
      enum rtx_code code;
      while (next)
        {

[Bug rtl-optimization/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa

[ebotcazou at gcc dot gnu.org]

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

--- Comment #30 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
Not clear what the right fix is...  The hot spot in relax_delay_slots:

      /* If this is a jump insn, see if it now jumps to a jump, jumps to
         the next insn, or jumps to a label that is not the last of a
         group of consecutive labels.  */
      if (is_a <rtx_jump_insn *> (insn)
          && (condjump_p (insn) || condjump_in_parallel_p (insn))
          && !ANY_RETURN_P (target_label = JUMP_LABEL (insn)))
        {
          rtx_jump_insn *jump_insn = as_a <rtx_jump_insn *> (insn);
          target_label
            = skip_consecutive_labels (follow_jumps (target_label, jump_insn,
                                                     &crossing));
          if (ANY_RETURN_P (target_label))
            target_label = find_end_label (target_label);

          if (target_label
              && next_active_insn (as_a<rtx_insn *> (target_label)) == next
              && ! condjump_in_parallel_p (jump_insn)
              && ! (next && switch_text_sections_between_p (jump_insn, next)))
            {
              delete_jump (jump_insn);
              continue;
            }

IIRC Jeff already dealt with this kind of issues in the past, so maybe he knows
what the best way out would be?

[Bug rtl-optimization/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa

[slyfox at inbox dot ru]

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

--- Comment #31 from Sergei Trofimovich <slyfox at inbox dot ru> ---
(In reply to Martin Liška from comment #28)
> > Bisected down to:
> > 
> > $ git bisect good
> > 8c3785c43d490d4f234e21c9dee6bb1bb8d1dbdf is the first bad commit
> > commit 8c3785c43d490d4f234e21c9dee6bb1bb8d1dbdf
> > Author: Martin Liska <mliska@suse.cz>
> > Date:   Wed Dec 4 11:13:49 2019 +0100
> > 
> >     Initialize a BB count in switch lowering.

> Thank you for the bisection. However, this one is not a culprit commit, it
> only made it visible.
> Let's wait for can Erik find out.

For my own curiosity I applied "Initialize a BB count in switch lowering." to
gcc-9 and found that it's indeed is already broken.

I attempted a bisection between gcc-8 and gcc-9 while applying this patch to
get the idea where it surfaced. Got arrived at:

$ git bisect good
9427422ddacdf1c2914adfb6e8edca87f250fdfc is the first bad commit
commit 9427422ddacdf1c2914adfb6e8edca87f250fdfc
Author: Jeff Law <law@redhat.com>
Date:   Wed Apr 3 10:03:37 2019 -0600

    re PR rtl-optimization/81025 (gcc ICE while building glibc for MIPS
soft-float multi-lib variant)

            PR rtl-optimization/81025
            * reorg.c (skip_consecutive_labels): Do not skip past a BARRIER.

    From-SVN: r270129

 gcc/ChangeLog |  5 +++++
 gcc/reorg.c   | 15 ++++++++++++++-
 2 files changed, 19 insertions(+), 1 deletion(-)

https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=9427422ddacdf1c2914adfb6e8edca87f250fdfc

[Bug rtl-optimization/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|ebotcazou at gcc dot gnu.org       |unassigned at gcc dot gnu.org
             Status|ASSIGNED                    |NEW

--- Comment #32 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
OK, thanks, deferring to Jeff's judgment then.

[Bug rtl-optimization/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa

[law at redhat dot com]

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

--- Comment #33 from Jeffrey A. Law <law at redhat dot com> ---
Have I mentioned before that I think __builtin_unreachable is fundamentally
broken/wrong :-)


I could argue that the BARRIER in the IL is wrong because it doesn't actually
line up with the semantics of the instruction stream.  But that's probably a
losing battle with those who think that __builtin_unreachable's current
behavior is sensible.

One thought would be to turn a conditional jump followed by a barrier into an
unconditional jump in jump.c.  But I fear that just papers over the problem and
that we'd see the same issue raise its head again in a slightly perturbed form
that wasn't recognized by jump.c, but tripped the same code as we have now in
reorg.c.

Another thought would be to detect this in relax_delay_slots and twiddle the
transformation to avoid the problematic behavior.  I think we could detect just
by seeing if there's a barrier after INSN in the same hunk of code that Eric
quoted and changing the behavior slightly when that's detected.

I hate special casing things like that and there's a reasonable chance other
parts of GCC are affected by the same problem.  That may argue for implementing
both approaches.

But I'd really just like to change how __builtin_unreachable works.

Eric, thoughts?

jeff

[Bug rtl-optimization/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa

[ebotcazou at gcc dot gnu.org]

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

--- Comment #34 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> Eric, thoughts?

Another possibility would be to remove the problematic barriers during the
barriers pass that is run just before reorg:

/* Some old code expects exactly one BARRIER as the NEXT_INSN of a
   non-fallthru insn.  This is not generally true, as multiple barriers
   may have crept in, or the BARRIER may be separated from the last
   real insn by one or more NOTEs.

   This simple pass moves barriers and removes duplicates so that the
   old code is happy.
 */
static unsigned int
cleanup_barriers (void)

but this may void the fix for PR rtl-optimization/81025.

In the end I think that the safest route is indeed probably to patch the hot
spot in relax_delay_slots.  There is already a similar guard for text section
switches by means of switch_text_sections_between_p.  The condition would be
LABEL_NUSES of 
JUMP_LABEL equal to 1 and presence of a BARRIER between the jump and next
insns.

[Bug rtl-optimization/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa

[law at redhat dot com]

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

--- Comment #35 from Jeffrey A. Law <law at redhat dot com> ---
That's a reasonable idea Eric -- the barriers are primarily there for the
benefit of CFG building and manipulation and thus provide marginal, if any,
benefit once we hit the reorg pass.

I recall 81025 being particularly difficult to reproduce, but once understood
it was pretty obvious what was going on.  We could certainly look at your idea
and see how it interacts with shrink-wrapping and the dwarf bits.

I don't mind putting it on my todo list, but it's likely stage3 before I'd be
able to reasonably look at it.

[Bug rtl-optimization/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.2                        |10.3

--- Comment #36 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 10.2 is released, adjusting target milestone.

[Bug rtl-optimization/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4

--- Comment #37 from Richard Biener <rguenth at gcc dot gnu.org> ---
Not sure if we have a primary/secondary target with delay slots that might run
into this issue.

[Bug rtl-optimization/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa

[law at redhat dot com]

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

--- Comment #38 from Jeffrey A. Law <law at redhat dot com> ---
sparc might be able to trip this.

[Bug rtl-optimization/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa

[mikpelinux at gmail dot com]

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

--- Comment #39 from Mikael Pettersson <mikpelinux at gmail dot com> ---
I tried the few test cases listed in this PR with gcc-11 on sparcv9-linux-gnu,
but wasn't able to observe any miscompilation.

[Bug rtl-optimization/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |ebotcazou at gcc dot gnu.org

--- Comment #40 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
I'll give it a try next week.

[Bug rtl-optimization/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa

[cvs-commit at gcc dot gnu.org]

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

--- Comment #41 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Eric Botcazou <ebotcazou@gcc.gnu.org>:

https://gcc.gnu.org/g:20f28986a8d3cad3c848d1e7da48f4bea7637298

commit r11-7154-g20f28986a8d3cad3c848d1e7da48f4bea7637298
Author: Eric Botcazou <ebotcazou@adacore.com>
Date:   Tue Feb 9 19:49:18 2021 +0100

    Fix miscompilation of Python on HP-PA/Linux

    This is the miscompilation of Python at -O2 on HP-PA/Linux present
    on the mainline and 10 branch, caused by the presence of a call to
    __builtin_unreachable () in the middle of a heavily branchy code,
    which confuses the reorg pass.

    gcc/
            PR rtl-optimization/96015
            * reorg.c (skip_consecutive_labels): Minor comment tweaks.
            (relax_delay_slots): When deleting a jump to the next active
            instruction over a barrier, first delete the barrier if the
            jump is the only way to reach the target label.

[Bug rtl-optimization/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa

[cvs-commit at gcc dot gnu.org]

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

--- Comment #42 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Eric Botcazou
<ebotcazou@gcc.gnu.org>:

https://gcc.gnu.org/g:b1d2ed3ad54378e8798dab27c841418f3f60cff2

commit r10-9354-gb1d2ed3ad54378e8798dab27c841418f3f60cff2
Author: Eric Botcazou <ebotcazou@adacore.com>
Date:   Tue Feb 9 19:49:18 2021 +0100

    Fix miscompilation of Python on HP-PA/Linux

    This is the miscompilation of Python at -O2 on HP-PA/Linux present
    on the mainline and 10 branch, caused by the presence of a call to
    __builtin_unreachable () in the middle of a heavily branchy code,
    which confuses the reorg pass.

    gcc/
            PR rtl-optimization/96015
            * reorg.c (skip_consecutive_labels): Minor comment tweaks.
            (relax_delay_slots): When deleting a jump to the next active
            instruction over a barrier, first delete the barrier if the
            jump is the only way to reach the target label.

[Bug rtl-optimization/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

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

--- Comment #43 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
This should be fixed on the 10 branch.

[Bug rtl-optimization/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa

[dave.anglin at bell dot net]

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

--- Comment #44 from dave.anglin at bell dot net ---
On 2021-02-09 2:01 p.m., ebotcazou at gcc dot gnu.org wrote:
> This should be fixed on the 10 branch.
Thank you Eric 😁