[Bug rust/108102] New: rust bootstrap comparison failure on s390x-linux-gnu

[Bug rust/108102] New: rust bootstrap comparison failure on s390x-linux-gnu

[doko at gcc dot gnu.org]

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

            Bug ID: 108102
           Summary: rust bootstrap comparison failure on s390x-linux-gnu
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rust
          Assignee: unassigned at gcc dot gnu.org
          Reporter: doko at gcc dot gnu.org
                CC: dkm at gcc dot gnu.org, gcc-rust at gcc dot gnu.org
  Target Milestone: ---

seen with trunk 20221214 on s390x-linux-gnu:

make[5]: Leaving directory '/<<PKGBUILDDIR>>/build'
Comparing stages 2 and 3
Bootstrap comparison failure!
gcc/rust/rust-hir-trait-resolve.o differs
make[4]: *** [Makefile:31113: compare] Error 1

full build log at
https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/test/+build/24937231

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug rust/108102] rust bootstrap comparison failure on s390x-linux-gnu

[doko at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |s390x-linux-gnu

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug rust/108102] rust bootstrap comparison failure on s390x-linux-gnu

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So what are the differences in
stage2-gcc/rust/rust-hir-trait-resolve.o
vs.
stage3-gcc/rust/rust-hir-trait-resolve.o
(or prev-gcc/ vs. gcc/ if it was moved back already)?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug rust/108102] rust bootstrap comparison failure on s390x-linux-gnu

[marxin at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2022-12-15
             Status|UNCONFIRMED                 |WAITING
     Ever confirmed|0                           |1
                 CC|                            |marxin at gcc dot gnu.org

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug rust/108102] rust bootstrap comparison failure on s390x-linux-gnu

[stefansf at linux dot ibm.com]

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

Stefan Schulze Frielinghaus <stefansf at linux dot ibm.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |stefansf at linux dot ibm.com

--- Comment #2 from Stefan Schulze Frielinghaus <stefansf at linux dot ibm.com> ---
Can confirm. Happens with --with-arch=arch13 and started since adding rust to
languages via commit r13-4676-ga75f038c069cc3.

$ diff <(objdump -d stage2-gcc/rust/rust-hir-trait-resolve.o) \
       <(objdump -d stage3-gcc/rust/rust-hir-trait-resolve.o)
2c2
< stage2-gcc/rust/rust-hir-trait-resolve.o:     file format elf64-s390
---
> stage3-gcc/rust/rust-hir-trait-resolve.o:     file format elf64-s390
1939,1940c1939,1940
<     24ec:     e3 20 f2 50 00 24       stg     %r2,592(%r15)
<     24f2:     e3 30 f1 28 00 04       lg      %r3,296(%r15)
---
>     24ec:     e3 30 f1 28 00 04       lg      %r3,296(%r15)
>     24f2:     e3 20 f2 50 00 24       stg     %r2,592(%r15)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug middle-end/108102] rust bootstrap comparison failure on s390x-linux-gnu

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |build
          Component|rust                        |middle-end

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug middle-end/108102] rust bootstrap comparison failure on s390x-linux-gnu

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|1                           |0
             Status|WAITING                     |UNCONFIRMED

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Moved to middle-end since the code that is causing issues is c++ code.

Can you attach the preprocessed source? I wonder if this is a -g0 vs -g issue
...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug middle-end/108102] rust bootstrap comparison failure on s390x-linux-gnu

[stefansf at linux dot ibm.com]

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

--- Comment #4 from Stefan Schulze Frielinghaus <stefansf at linux dot ibm.com> ---
I was playing around with this and was wondering how can I actually execute the
stageN compiler? From the output of make I see two compilations for object
rust-hir-trait-resolve.o. Thus the first one must be for stage2 and the second
one for stage3. For the former the command line is

/devel/gcc/build/./prev-gcc/xg++ -B/devel/gcc/build/./prev-gcc/
-B/devel/gcc/dst/s390x-ibm-linux-gnu/bin/ -nostdinc++
-B/devel/gcc/build/prev-s390x-ibm-linux-gnu/libstdc++-v3/src/.libs
-B/devel/gcc/build/prev-s390x-ibm-linux-gnu/libstdc++-v3/libsupc++/.libs 
-I/devel/gcc/build/prev-s390x-ibm-linux-gnu/libstdc++-v3/include/s390x-ibm-linux-gnu
 -I/devel/gcc/build/prev-s390x-ibm-linux-gnu/libstdc++-v3/include 
-I/devel/gcc/src/libstdc++-v3/libsupc++
-L/devel/gcc/build/prev-s390x-ibm-linux-gnu/libstdc++-v3/src/.libs
-L/devel/gcc/build/prev-s390x-ibm-linux-gnu/libstdc++-v3/libsupc++/.libs 
-fno-PIE -c  -DIN_GCC_FRONTEND -g -O2 -fno-checking -gtoggle -DIN_GCC    
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute
-Wconditionally-supported -Woverloaded-virtual -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -Werror -Wno-unused-parameter
-fno-common  -DHAVE_CONFIG_H -I. -Irust -I/devel/gcc/src/gcc
-I/devel/gcc/src/gcc/rust -I/devel/gcc/src/gcc/../include
-I/devel/gcc/src/gcc/../libcpp/include -I/devel/gcc/src/gcc/../libcody 
-I/devel/gcc/src/gcc/../libdecnumber -I/devel/gcc/src/gcc/../libdecnumber/dpd
-I../libdecnumber -I/devel/gcc/src/gcc/../libbacktrace   -o
rust/rust-hir-trait-resolve.o -MT rust/rust-hir-trait-resolve.o -MMD -MP -MF
rust/.deps/rust-hir-trait-resolve.TPo -g -O2 -fno-checking -gtoggle -I
/devel/gcc/src/gcc/rust -I /devel/gcc/src/gcc/rust/lex -I
/devel/gcc/src/gcc/rust/parse -I /devel/gcc/src/gcc/rust/ast -I
/devel/gcc/src/gcc/rust/analysis -I /devel/gcc/src/gcc/rust/backend -I
/devel/gcc/src/gcc/rust/expand -I /devel/gcc/src/gcc/rust/hir/tree -I
/devel/gcc/src/gcc/rust/hir -I /devel/gcc/src/gcc/rust/resolve -I
/devel/gcc/src/gcc/rust/util -I /devel/gcc/src/gcc/rust/typecheck -I
/devel/gcc/src/gcc/rust/checks/lints -I /devel/gcc/src/gcc/rust/checks/errors
-I /devel/gcc/src/gcc/rust/checks/errors/privacy -I
/devel/gcc/src/gcc/rust/util -I /devel/gcc/src/gcc/rust/metadata
/devel/gcc/src/gcc/rust/typecheck/rust-hir-trait-resolve.cc

and the current working directory was most likely /devel/gcc/build/gcc.
Creating a symlink from $build/stage1-gcc to $build/prev-gcc and then running
the command from above doesn't do the trick. There is probably an easier way
which I miss. Any hints?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug middle-end/108102] rust bootstrap comparison failure on s390x-linux-gnu

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Stefan Schulze Frielinghaus from comment #4) 
> and the current working directory was most likely /devel/gcc/build/gcc.
> Creating a symlink from $build/stage1-gcc to $build/prev-gcc and then
> running the command from above doesn't do the trick. There is probably an
> easier way which I miss. Any hints?

See stage2-start/stage3-start I think.

See
https://gcc.gnu.org/onlinedocs/gccint/Makefile.html#Makefile

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug middle-end/108102] rust bootstrap comparison failure on s390x-linux-gnu

[stefansf at linux dot ibm.com]

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

--- Comment #6 from Stefan Schulze Frielinghaus <stefansf at linux dot ibm.com> ---
Created attachment 54154
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54154&action=edit
preprocessed rust-hir-trait-resolve.cc

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug middle-end/108102] rust bootstrap comparison failure on s390x-linux-gnu

[stefansf at linux dot ibm.com]

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

--- Comment #7 from Stefan Schulze Frielinghaus <stefansf at linux dot ibm.com> ---
The difference in the assembly output shown in comment 2 happens in function

void
AssociatedImplTrait::setup_associated_types (
  const TyTy::BaseType *self, const TyTy::TypeBoundPredicate &bound)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug middle-end/108102] rust bootstrap comparison failure on s390x-linux-gnu

[stefansf at linux dot ibm.com]

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

--- Comment #8 from Stefan Schulze Frielinghaus <stefansf at linux dot ibm.com> ---
Created attachment 54277
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54277&action=edit
reduced version of the initial problem

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug middle-end/108102] rust bootstrap comparison failure on s390x-linux-gnu

[stefansf at linux dot ibm.com]

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

--- Comment #9 from Stefan Schulze Frielinghaus <stefansf at linux dot ibm.com> ---
Created attachment 54278
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54278&action=edit
RTL dump of sched2 if compiled without debug information

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug middle-end/108102] rust bootstrap comparison failure on s390x-linux-gnu

[stefansf at linux dot ibm.com]

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

--- Comment #10 from Stefan Schulze Frielinghaus <stefansf at linux dot ibm.com> ---
Created attachment 54279
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54279&action=edit
RTL dump of sched2 if compiled with debug information

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug middle-end/108102] rust bootstrap comparison failure on s390x-linux-gnu

[stefansf at linux dot ibm.com]

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

--- Comment #11 from Stefan Schulze Frielinghaus <stefansf at linux dot ibm.com> ---
Please find attached a reduced version of the initial problem.  If compiled
with

g++ -O2 -march=arch13 -fno-exceptions (-g)

there is still a difference whether build with debug information or not:

diff <(objdump -d reduced.o-without-debug) <(objdump -d reduced.o-with-debug)
2c2
< reduced.o-without-debug:     file format elf64-s390
---
> reduced.o-with-debug:     file format elf64-s390
94,97c94,97
<  1b8: e5 48 f0 a8 00 00       mvghi   168(%r15),0
<  1be: e3 50 f0 c8 00 04       lg      %r5,200(%r15)
<  1c4: 41 30 f0 a0             la      %r3,160(%r15)
<  1c8: e3 50 f0 a0 00 24       stg     %r5,160(%r15)
---
>  1b8: e3 50 f0 c8 00 04       lg      %r5,200(%r15)
>  1be: e5 48 f0 a8 00 00       mvghi   168(%r15),0
>  1c4: e3 50 f0 a0 00 24       stg     %r5,160(%r15)
>  1ca: 41 30 f0 a0             la      %r3,160(%r15)

The corresponding insns are:

Without debug information:

mvghi => insn 207
lg    => insn 206
la    => insn 310
stg   => insn 312

With debug information:

lg    => insn 427
mvghi => insn 428
stg   => insn 533
la    => insn 531

In split3 the order of the insns are the same and change in sched2 where we
have:

Without debug information:

;;   ======================================================
;;   -- basic block 14 from 87 to 355 -- after reload
;;   ======================================================

;;        0--> b  0: i  87 %r2=0                                   :nothing
;;        1--> b  0: i  88 {%r2=call
[`_ZN4Rust4TyTy9ParamType7resolveEv'];clobber %r14;}:nothing
;;        2--> b  0: i 207 [%r15+0xa8]=0                           :nothing
;;        3--> b  0: i 206 %r5=[%r15+0xc8]                         :nothing
;;        4--> b  0: i 310 %r3=%r15+0xa0                           :nothing
;;        5--> b  0: i 312 [%r15+0xa0]=%r5                         :nothing
;;        6--> b  0: i 311 %r2=%r15+0xc0                           :nothing
;;        7--> b  0: i  96 {call
[`_ZNSt6vectorIPN4Rust4TyTy8BaseTypeESaIS3_EE17_M_realloc_insertIN9__gnu_cxx17__normal_iteratorIPS3_S5_EEEEvT_'];clobber
%r14;}:nothing
;;        8--> b  0: i 355 pc=L174                                 :nothing
;;      Ready list (final):
;;   total time = 8
;;   new head = 87
;;   new tail = 355

With debug information:

;;   ======================================================
;;   -- basic block 14 from 201 to 585 -- after reload
;;   ======================================================

;;        0--> b  0: i 201 debug_marker                            :nothing
;;        0--> b  0: i 202 %r2=0                                   :nothing
;;        1--> b  0: i 203 {%r2=call
[`_ZN4Rust4TyTy9ParamType7resolveEv'];clobber %r14;}:nothing
;;        1--> b  0: i 204 debug_marker                            :nothing
;;        1--> b  0: i 205 loc %r15+0xc0                           :nothing
;;        1--> b  0: i 206 debug_marker                            :nothing
;;        1--> b  0: i 207 loc %r15+0xc0                           :nothing
;;        1--> b  0: i 208 debug_marker                            :nothing
;;        1--> b  0: i 210 loc debug_implicit_ptr                  :nothing
;;        1--> b  0: i 211 loc [%r15+0xc8]                         :nothing
;;        1--> b  0: i 212 debug_marker                            :nothing
;;        1--> b  0: i 214 loc clobber                             :nothing
;;        1--> b  0: i 215 loc clobber                             :nothing
;;        1--> b  0: i 216 loc clobber                             :nothing
;;        2--> b  0: i 427 %r5=[%r15+0xc8]                         :nothing
;;        3--> b  0: i 428 [%r15+0xa8]=0                           :nothing
;;        4--> b  0: i 533 [%r15+0xa0]=%r5                         :nothing
;;        5--> b  0: i 531 %r3=%r15+0xa0                           :nothing
;;        6--> b  0: i 532 %r2=%r15+0xc0                           :nothing
;;        7--> b  0: i 222 {call
[`_ZNSt6vectorIPN4Rust4TyTy8BaseTypeESaIS3_EE17_M_realloc_insertIN9__gnu_cxx17__normal_iteratorIPS3_S5_EEEEvT_'];clobber
%r14;}:nothing
;;        7--> b  0: i 223 loc clobber                             :nothing
;;        8--> b  0: i 585 pc=L373                                 :nothing
;;      Ready list (final):
;;   total time = 8
;;   new head = 201
;;   new tail = 585

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug middle-end/108102] rust bootstrap comparison failure on s390x-linux-gnu

[stefansf at linux dot ibm.com]

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

--- Comment #12 from Stefan Schulze Frielinghaus <stefansf at linux dot ibm.com> ---
The culprit seems to be that s390_sched_init is not called in one particular
case. We have the following basic blocks and edges:

6 --> 12 --> 13 --> 14

The edges from 12 to 13 and 13 to 14 are fall-through edges which means in
function s390_sched_init we "inherit" last_scheduled_unit_distance from the
previous block, i.e., we do not zero it. The edge from 6 to 12 is a
non-fall-through edge which means if we schedule bb 12, then s390_sched_init
will be called and last_scheduled_unit_distance will be zeroed. The culprit
seems to be that bb 12 is empty if no debug information is generated or in case
debug information is generated then it contains only debug insns. Thus, in the
non-debug case when bb 12 is empty it is never scheduled and therefore
s390_sched_init is never called and therefore last_scheduled_unit_distance is
never zeroed. We also see this once inspecting last_scheduled_unit_distance at
the very beginning of function schedule_block for bb 13 where we have:

non-debug: 2 2 0 2 34 0 34 29
    debug: 0 0 0 0 0 0 0 0

In the debug-case we "inherit" for bb 13 from bb 12
last_scheduled_unit_distance which got cleared once bb 12 was scheduled. In the
non-debug case we also "inherit" the array but it did not get cleared in bb 12
because it was never scheduled.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug middle-end/108102] rust bootstrap comparison failure on s390x-linux-gnu

[doko at gcc dot gnu.org]

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

--- Comment #13 from Matthias Klose <doko at gcc dot gnu.org> ---
this isn't seen anymore with current trunk. close as worksforme?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug middle-end/108102] rust bootstrap comparison failure on s390x-linux-gnu

[stefansf at linux dot ibm.com]

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

--- Comment #14 from Stefan Schulze Frielinghaus <stefansf at linux dot ibm.com> ---
I'm still working on this and currently test a new patch which should fix the
scheduler handling in the backend.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug middle-end/108102] rust bootstrap comparison failure on s390x-linux-gnu

[cvs-commit at gcc dot gnu.org]

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

--- Comment #15 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Stefan Schulze Frielinghaus
<stefansf@gcc.gnu.org>:

https://gcc.gnu.org/g:452db716d8debb6e09b85e4a0c0e73a047ed5c1d

commit r13-5964-g452db716d8debb6e09b85e4a0c0e73a047ed5c1d
Author: Stefan Schulze Frielinghaus <stefansf@linux.ibm.com>
Date:   Mon Feb 13 15:33:38 2023 +0100

    IBM zSystems: Do not propagate scheduler state across basic blocks
[PR108102]

    So far we propagate scheduler state across basic blocks within EBBs and
    reset the state otherwise.  In certain circumstances the entry block of
    an EBB might be empty, i.e., no_real_insns_p is true.  In those cases
    scheduler state is not reset and subsequently wrong state is propagated
    to following blocks of the same EBB.

    Since the performance benefit of tracking state across basic blocks is
    questionable on modern hardware, simply reset the state for each basic
    block.

    Fix also resetting f{p,x}d_longrunning.

    gcc/ChangeLog:

            PR target/108102
            * config/s390/s390.cc (s390_bb_fallthru_entry_likely): Remove.
            (struct s390_sched_state): Initialise to zero.
            (s390_sched_variable_issue): For better debuggability also emit
            the current side.
            (s390_sched_init): Unconditionally reset scheduler state.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug middle-end/108102] rust bootstrap comparison failure on s390x-linux-gnu

[stefansf at linux dot ibm.com]

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

--- Comment #16 from Stefan Schulze Frielinghaus <stefansf at linux dot ibm.com> ---
Fixed in mainline. Fine for me to close this now.

-- 
You are receiving this mail because:
You are on the CC list for the bug.