[Bug tree-optimization/91322] [10 regression] alias-4 test failure

[Bug tree-optimization/91322] [10 regression] alias-4 test failure

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1

[Bug tree-optimization/91322] [10 regression] alias-4 test failure

[marxin at gcc dot gnu.org]

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

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

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

--- Comment #1 from Martin Liška <marxin at gcc dot gnu.org> ---
I've just run the test-case on aarch64 and it works fine (-O2, -O2 -flto, -O3
-flto -fno-early-inlining). And lto.exp testsuite works fine on aarch64.
@Wilco: Can you please double-check?

[Bug tree-optimization/91322] [10 regression] alias-4 test failure

[wdijkstr at arm dot com]

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

Wilco <wdijkstr at arm dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wdijkstr at arm dot com

--- Comment #2 from Wilco <wdijkstr at arm dot com> ---
(In reply to Martin Liška from comment #1)
> I've just run the test-case on aarch64 and it works fine (-O2, -O2 -flto,
> -O3 -flto -fno-early-inlining). And lto.exp testsuite works fine on aarch64.
> @Wilco: Can you please double-check?

Yes it now works on AArch64, but I still see failures on Arm.

[Bug tree-optimization/91322] [10 regression] alias-4 test failure

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to Wilco from comment #2)
> (In reply to Martin Liška from comment #1)
> > I've just run the test-case on aarch64 and it works fine (-O2, -O2 -flto,
> > -O3 -flto -fno-early-inlining). And lto.exp testsuite works fine on aarch64.
> > @Wilco: Can you please double-check?
> 
> Yes it now works on AArch64, but I still see failures on Arm.

Can you please analyze (or bisect that) what happens?

[Bug tree-optimization/91322] [10 regression] alias-4 test failure

[marxin at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |avieira at gcc dot gnu.org,
                   |                            |clyon at gcc dot gnu.org

--- Comment #4 from Martin Liška <marxin at gcc dot gnu.org> ---
I'm adding ARM guys, I hope they can try to reproduce that.

[Bug tree-optimization/91322] [10 regression] alias-4 test failure

[clyon at gcc dot gnu.org]

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

--- Comment #5 from Christophe Lyon <clyon at gcc dot gnu.org> ---
Created attachment 48183
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48183&action=edit
executable asm from objdump

[Bug tree-optimization/91322] [10 regression] alias-4 test failure

[clyon at gcc dot gnu.org]

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

--- Comment #6 from Christophe Lyon <clyon at gcc dot gnu.org> ---
Created attachment 48184
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48184&action=edit
GCC passes dumps

[Bug tree-optimization/91322] [10 regression] alias-4 test failure

[clyon at gcc dot gnu.org]

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

--- Comment #7 from Christophe Lyon <clyon at gcc dot gnu.org> ---
Created attachment 48185
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48185&action=edit
qemu execution trace

[Bug tree-optimization/91322] [10 regression] alias-4 test failure

[hubicka at gcc dot gnu.org]

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

--- Comment #8 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Do we have compile farm machine where this can be reproduced?

[Bug tree-optimization/91322] [10 regression] alias-4 test failure

[marxin at gcc dot gnu.org]

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

--- Comment #9 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to Jan Hubicka from comment #8)
> Do we have compile farm machine where this can be reproduced?

I guess we don't have any.

[Bug tree-optimization/91322] [10 regression] alias-4 test failure

[wdijkstr at arm dot com]

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

--- Comment #10 from Wilco <wdijkstr at arm dot com> ---
(In reply to Christophe Lyon from comment #6)
> Created attachment 48184 [details]
> GCC passes dumps

So according to that, in 105t.vrp1 it removes the branch and unconditionally
calls abort:

Folding statement: _4 = _3 == 0B;
Matching expression match.pd:1737, gimple-match.c:708
Matching expression match.pd:1740, gimple-match.c:772
Matching expression match.pd:1747, gimple-match.c:826
Not folded
Folding statement: if (_5 == 0)
gimple_simplified to if (1 != 0)
Folded into: if (1 != 0)

Folding statement: return;
Not folded
Folding statement: __builtin_abort ();
Not folded
Removing dead stmt _5 = __builtin_constant_p (_4);


It doesn't make sense, these are the VRP ranges:

_1: short int * * VARYING
_2: short int * * VARYING
_3: short int * VARYING
_4: bool VARYING
_5: int [0, 0]
_10: struct a * VARYING

So somehow it decides that __builtin_constant_p (VARYING) == [0,0]???

[Bug tree-optimization/91322] [10 regression] alias-4 test failure

[hubicka at gcc dot gnu.org]

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

--- Comment #11 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
The problem is that on ARM sizeof (short) == sizeof (int)
and LTO will glob all short and int pointers together.  So this is missed
optimization only.

We do this globing sort of by design. For GCC11 I plan to refine type merging
again a bit but until then we could either xfail this testcase or change int to
long which is 4 bytes.

Not a release blocker though.

I would welcome if someone could test the testcase adjustment (I was doing LTO
by hand)

diff --git a/gcc/testsuite/g++.dg/lto/alias-4_0.C
b/gcc/testsuite/g++.dg/lto/alias-4_0.C
index 410c3140baf..0ab12adef5b 100644
--- a/gcc/testsuite/g++.dg/lto/alias-4_0.C
+++ b/gcc/testsuite/g++.dg/lto/alias-4_0.C
@@ -5,7 +5,7 @@ short *ptr_init, **ptr=&ptr_init;

 __attribute__ ((used))
 struct a {
-  int *aptr;
+  long *aptr;
 } a, *aptr=&a;

 void

[Bug tree-optimization/91322] [10 regression] alias-4 test failure

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Which ARM target has 16-bit int?
I don't see INT_TYPE_SIZE nor SHORT_TYPE_SIZE defined in config/arm/*, neither
BITS_PER_WORD, so all depends on UNITS_PER_WORD, which is 4 and thus short is
16-bit and int is 32-bit.

Re: [Bug tree-optimization/91322] [10 regression] alias-4 test failure

[Jan Hubicka]

> Which ARM target has 16-bit int?
> I don't see INT_TYPE_SIZE nor SHORT_TYPE_SIZE defined in config/arm/*, neither
> BITS_PER_WORD, so all depends on UNITS_PER_WORD, which is 4 and thus short is
> 16-bit and int is 32-bit.

Hmm, you are right - I messed up target triplets. With arm-linux-gnueabi
I see 4 byte int and the testcase calls abort.
However it is still missed optimization.  I will check why we end up
with different code than x86 LTO.

Honza

[Bug tree-optimization/91322] [10 regression] alias-4 test failure

[hubicka at ucw dot cz]

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

--- Comment #13 from Jan Hubicka <hubicka at ucw dot cz> ---
> Which ARM target has 16-bit int?
> I don't see INT_TYPE_SIZE nor SHORT_TYPE_SIZE defined in config/arm/*, neither
> BITS_PER_WORD, so all depends on UNITS_PER_WORD, which is 4 and thus short is
> 16-bit and int is 32-bit.

Hmm, you are right - I messed up target triplets. With arm-linux-gnueabi
I see 4 byte int and the testcase calls abort.
However it is still missed optimization.  I will check why we end up
with different code than x86 LTO.

Honza

[Bug tree-optimization/91322] [10 regression] g++.dg/lto/alias-4_0.C test failure

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[10 regression] alias-4     |[10 regression]
                   |test failure                |g++.dg/lto/alias-4_0.C test
                   |                            |failure
             Status|WAITING                     |NEW
           Keywords|                            |alias, missed-optimization
             Target|                            |arm

--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
FAIL: g++.dg/lto/alias-4 cp_lto_alias-4_0.o-cp_lto_alias-4_0.o execute  -O3
-flto -fno-early-inlining 

on periodic testing on armv8l-linux-gnueabihf

Adjusting summary - we also have gcc.dg/alias-4.c.

So we're failing to disambiguate loads against stores here for some reason
(we sure need either IPA PTA or TBAA for this to work - it's unclear
what's special here about 'arm' - all loads and stores are pointers
and there's one aggregate assignment involving struct a, also containing
a pointer)

  # VUSE <.MEM_6(D)>
  # PT = nonlocal escaped null
  _1 = ptrD.5611;
  # .MEM_7 = VDEF <.MEM_6(D)>
  *_1 = 0B;
  # VUSE <.MEM_7>
  # PT = nonlocal escaped null
  _10 = aptrD.5614;
  # .MEM_11 = VDEF <.MEM_7>
  *_10 = aD.5615;
  # VUSE <.MEM_11>
  # PT = nonlocal escaped null
  _2 = ptrD.5611;
  # VUSE <.MEM_11>
  # PT = nonlocal escaped null
  _3 = *_2;
  _4 = _3 == 0B;

So I'm quite sure the missed optimization isn't a regression?  (can somebody
quickly check GCC 9 whether the testcase is optimized there on ARM?)

Which makes it a testsuite issue to solve for GCC 10, for example by
xfail-ing it on affected platforms.

The actual issue can probably be simplified quite a bit into a testcase
for alias analysis and FRE1.

[Bug tree-optimization/91322] [10 regression] g++.dg/lto/alias-4_0.C test failure

[wilco at gcc dot gnu.org]

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

--- Comment #15 from Wilco <wilco at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #14)

> So I'm quite sure the missed optimization isn't a regression?  (can somebody
> quickly check GCC 9 whether the testcase is optimized there on ARM?)

It fails on both AArch64 and Arm all the way back to GCC6 (oldest compiler I
tried). So it's not a regression but this is all target independent so I
wouldn't expect this to fail.

[Bug tree-optimization/91322] [10 regression] g++.dg/lto/alias-4_0.C test failure

[cvs-commit at gcc dot gnu.org]

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

--- Comment #16 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jan Hubicka <hubicka@gcc.gnu.org>:

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

commit r10-7654-gf60979edbfcf6ce2cbf2cb09b8af8c125ff7774f
Author: Jan Hubicka <jh@suse.cz>
Date:   Thu Apr 9 14:12:36 2020 +0200

    Avoid g++.dg/lto/alias-4_0.C test failure on ARM [PR91322]

            PR tree-optimization/91322
            * g++.dg/lto/alias-4_0.C: Avoid conflict with va_list on ARM and
add
            a template testing that.

[Bug tree-optimization/91322] [10 regression] g++.dg/lto/alias-4_0.C test failure

[hubicka at gcc dot gnu.org]

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

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

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

--- Comment #17 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
So this turned out to be disabled ODR based TBAA for this struct since on ARM
the builtin va_list type has same structure.
I fixed the fialure by adjusting the structure and next stage1 we can make ODR
TBAA to not give up in this case.