[Bug tree-optimization/94167] New: pr71109.c -fcompare-debug failures on x86_64 and powerpc64le

[Bug tree-optimization/94167] New: pr71109.c -fcompare-debug failures on x86_64 and powerpc64le

[zhroma at gcc dot gnu.org]

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

            Bug ID: 94167
           Summary: pr71109.c -fcompare-debug failures on x86_64 and
                    powerpc64le
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: zhroma at gcc dot gnu.org
  Target Milestone: ---

Running
gcc -O2 -fcompare-debug gcc/testsuite/gcc.c-torture/compile/pr71109.c
fails with recent master on powerpc64le.
I also checked that same happens on x86 with recent 9.3.0 and old 5.5.0 ubuntu.

On master, first dump file with difference is fixup_cfg3

--
I've compared (on powerpc64le) usual regtest results and '-fcompare-debug'
results and there are like ~10 more failures, two of them already reported as
PR94166.

Certainly, there are actually a lot of cases when -fcompare-debug dumps
differs, but .o files have same code, so that can only be catched "manually"
(e.g. using RUNTESTFLAGS="--target_board=unix/-fcompare-debug" or bootstrapping
--with-build-config=bootstrap-debug-lean).  And I'm not sure how much community
bothers about fixing issues like this one.

[Bug debug/94167] [8/9/10 Regression] pr71109.c -fcompare-debug failures on x86_64 and powerpc64le

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2020-03-13
   Target Milestone|---                         |8.5
     Ever confirmed|0                           |1
          Component|tree-optimization           |debug
            Summary|pr71109.c -fcompare-debug   |[8/9/10 Regression]
                   |failures on x86_64 and      |pr71109.c -fcompare-debug
                   |powerpc64le                 |failures on x86_64 and
                   |                            |powerpc64le
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Started with r0-111525-gd7da5cc85cdef4207d10e8b79dce79ed12353fb9
Will try to have a quick look.

[Bug debug/94167] [8/9/10 Regression] pr71109.c -fcompare-debug failures on x86_64 and powerpc64le

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The first changes seems to appear in the inline ipa dump:
-bar/5 (bar) @0x7face3ee7000
+bar/5 (bar) @0x7f637349f438
   Type: function definition analyzed
   Visibility: externally_visible public
+  Address is taken.
   References: 
-  Referring: 
+  Referring: foo.constprop.0/8 (addr)
...
-foo.constprop.0/8 (foo.constprop) @0x7face3ee75a0
+foo.constprop.0/8 (foo.constprop) @0x7f63734ab2d0
   Type: function definition analyzed
   Visibility: artificial
-  References: a/0 (write)c/1 (write)a/0 (read)b/3 (read)
+  References: bar/5 (addr)a/0 (write)c/1 (write)a/0 (read)b/3 (read)
which means something is pushing &bar from
  # DEBUG D#2 => (int) bar
which doesn't appear in any non-debug stmts.

[Bug debug/94167] [8/9/10 Regression] pr71109.c -fcompare-debug failures on x86_64 and powerpc64le

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 48029
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48029&action=edit
gcc10-pr94167.patch

Untested fix.

[Bug debug/94167] [8/9/10 Regression] pr71109.c -fcompare-debug failures on x86_64 and powerpc64le

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:6d44c881286762628afce5169d921a388ae6a1ff

commit r10-7186-g6d44c881286762628afce5169d921a388ae6a1ff
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Mon Mar 16 09:03:59 2020 +0100

    tree-inline: Fix a -fcompare-debug issue in the inliner [PR94167]

    The following testcase fails with -fcompare-debug.  The problem is that
    bar is marked as address_taken only with -g and not without.
    I've tracked it down to insert_init_stmt calling gimple_regimplify_operands
    even on DEBUG_STMTs.  That function will just insert normal stmts before
    the DEBUG_STMT if the DEBUG_STMT operand isn't gimple val or invariant.
    While DCE will turn those statements into debug temporaries, it can cause
    differences in SSA_NAMEs and more importantly, the ipa references are
    generated from those before the DCE happens.
    On the testcase, the DEBUG_STMT value is (int)bar.

    We could generate DEBUG_STMTs with debug temporaries instead, but I fail to
    see the reason to do that, DEBUG_STMTs allow other expressions and all we
    want to ensure is that the expressions aren't too large (arbitrarily
    complex), but during inlining/function versioning I don't see why something
    would queue a DEBUG_STMT with arbitrarily complex expressions in there.

    2020-03-16  Jakub Jelinek  <jakub@redhat.com>

            PR debug/94167
            * tree-inline.c (insert_init_stmt): Don't
gimple_regimplify_operands
            DEBUG_STMTs.

            * gcc.dg/pr94167.c: New test.

[Bug debug/94167] [8/9 Regression] pr71109.c -fcompare-debug failures on x86_64 and powerpc64le

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[8/9/10 Regression]         |[8/9 Regression] pr71109.c
                   |pr71109.c -fcompare-debug   |-fcompare-debug failures on
                   |failures on x86_64 and      |x86_64 and powerpc64le
                   |powerpc64le                 |

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed on the trunk so far.

[Bug debug/94167] [8/9 Regression] pr71109.c -fcompare-debug failures on x86_64 and powerpc64le

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:378e830538afd4a02e41674cc9161fa59b5e09a9

commit r9-8397-g378e830538afd4a02e41674cc9161fa59b5e09a9
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Mon Mar 16 09:03:59 2020 +0100

    tree-inline: Fix a -fcompare-debug issue in the inliner [PR94167]

    The following testcase fails with -fcompare-debug.  The problem is that
    bar is marked as address_taken only with -g and not without.
    I've tracked it down to insert_init_stmt calling gimple_regimplify_operands
    even on DEBUG_STMTs.  That function will just insert normal stmts before
    the DEBUG_STMT if the DEBUG_STMT operand isn't gimple val or invariant.
    While DCE will turn those statements into debug temporaries, it can cause
    differences in SSA_NAMEs and more importantly, the ipa references are
    generated from those before the DCE happens.
    On the testcase, the DEBUG_STMT value is (int)bar.

    We could generate DEBUG_STMTs with debug temporaries instead, but I fail to
    see the reason to do that, DEBUG_STMTs allow other expressions and all we
    want to ensure is that the expressions aren't too large (arbitrarily
    complex), but during inlining/function versioning I don't see why something
    would queue a DEBUG_STMT with arbitrarily complex expressions in there.

    2020-03-16  Jakub Jelinek  <jakub@redhat.com>

            PR debug/94167
            * tree-inline.c (insert_init_stmt): Don't
gimple_regimplify_operands
            DEBUG_STMTs.

            * gcc.dg/pr94167.c: New test.

[Bug debug/94167] [8 Regression] pr71109.c -fcompare-debug failures on x86_64 and powerpc64le

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[8/9 Regression] pr71109.c  |[8 Regression] pr71109.c
                   |-fcompare-debug failures on |-fcompare-debug failures on
                   |x86_64 and powerpc64le      |x86_64 and powerpc64le

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed for 9.4+ too.

[Bug debug/94167] [8 Regression] pr71109.c -fcompare-debug failures on x86_64 and powerpc64le

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-8 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:7fdfea793bdf47510a8ac6ff11dbf46288ae47a6

commit r8-10468-g7fdfea793bdf47510a8ac6ff11dbf46288ae47a6
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Mon Mar 16 09:03:59 2020 +0100

    tree-inline: Fix a -fcompare-debug issue in the inliner [PR94167]

    The following testcase fails with -fcompare-debug.  The problem is that
    bar is marked as address_taken only with -g and not without.
    I've tracked it down to insert_init_stmt calling gimple_regimplify_operands
    even on DEBUG_STMTs.  That function will just insert normal stmts before
    the DEBUG_STMT if the DEBUG_STMT operand isn't gimple val or invariant.
    While DCE will turn those statements into debug temporaries, it can cause
    differences in SSA_NAMEs and more importantly, the ipa references are
    generated from those before the DCE happens.
    On the testcase, the DEBUG_STMT value is (int)bar.

    We could generate DEBUG_STMTs with debug temporaries instead, but I fail to
    see the reason to do that, DEBUG_STMTs allow other expressions and all we
    want to ensure is that the expressions aren't too large (arbitrarily
    complex), but during inlining/function versioning I don't see why something
    would queue a DEBUG_STMT with arbitrarily complex expressions in there.

    2020-03-16  Jakub Jelinek  <jakub@redhat.com>

            PR debug/94167
            * tree-inline.c (insert_init_stmt): Don't
gimple_regimplify_operands
            DEBUG_STMTs.

            * gcc.dg/pr94167.c: New test.

    (cherry picked from commit 378e830538afd4a02e41674cc9161fa59b5e09a9)

[Bug debug/94167] [8 Regression] pr71109.c -fcompare-debug failures on x86_64 and powerpc64le

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Should be now fixed for 8.5 too.