[Bug tree-optimization/105517] New: [13 Regression] Missing diagnostic after recent optimizer improvements

[Bug tree-optimization/105517] New: [13 Regression] Missing diagnostic after recent optimizer improvements

[law at gcc dot gnu.org]

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

            Bug ID: 105517
           Summary: [13 Regression] Missing diagnostic after recent
                    optimizer improvements
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: law at gcc dot gnu.org
  Target Milestone: ---

This change:

commit ee1cb43bc76de800efa0ade687b0cd28e62a5f82
Author: Richard Biener <rguenther@suse.de>
Date:   Wed Jan 26 15:34:54 2022 +0100

    tree-optimization/104162 - CSE of &MEM[ptr].a[i] and ptr + CST

    This adds the capability to value-numbering of treating complex
    address expressions where the offset becomes invariant as equal
    to a POINTER_PLUS_EXPR.  This restores CSE that is now prevented
    by early lowering of &MEM[ptr + CST] to a POINTER_PLUS_EXPR.

    Unfortunately this regresses gcc.dg/asan/pr99673.c again, so
    the testcase is adjusted accordingly.

    2022-01-26  Richard Biener  <rguenther@suse.de>

            PR tree-optimization/104162
            * tree-ssa-sccvn.cc (vn_reference_lookup): Handle
            &MEM[_1 + 5].a[i] like a POINTER_PLUS_EXPR if the offset
            becomes invariant.
            (vn_reference_insert): Likewise.

            * gcc.dg/tree-ssa/ssa-fre-99.c: New testcase.
            * gcc.dg/asan/pr99673.c: Adjust.


Is causing various ports (ft32-elf for example) to fail the Warray-bounds.c
test:

Running /home/jlaw/test/gcc/gcc/testsuite/gcc.dg/dg.exp ...
FAIL: c-c++-common/Warray-bounds.c  -Wc++-compat   (test for warnings, line
187)
FAIL: c-c++-common/Warray-bounds.c  -Wc++-compat   (test for warnings, line
188)

I think you ought to be able to see this with just a cross compiler and
shouldn't need a full cross environment.  I haven't debugged this in any way
other than bisection.

[Bug tree-optimization/105517] [13 Regression] Missing diagnostic after recent optimizer improvements

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |13.0
     Ever confirmed|0                           |1
            Version|unknown                     |13.0
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org
   Last reconfirmed|                            |2022-05-09
           Keywords|                            |testsuite-fail
             Status|UNCONFIRMED                 |ASSIGNED

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
I will have a look and adjust the testcase.

[Bug tree-optimization/105517] [13 Regression] Missing diagnostic after recent optimizer improvements

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |i?86-*-*

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
I can reproduce on x86_64 with -m32.

  T (p->a1x[-1].a1);

and the both failing

  T (p->a1x[DIFF_MAX].a1);
  T (p->a1x[SIZE_MAX].a1);

resolve to the same value now.  At FRE1 we still have

  &p_74(D)->a1x[-1].a1;

and

  &p_74(D)->a1x[2147483647].a1;
  &p_74(D)->a1x[4294967295].a1;

the address calculations overflow in ways that make the addresses appear
the same.

[Bug tree-optimization/105517] [13 Regression] Missing diagnostic after recent optimizer improvements

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:

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

commit r13-205-gfaabc751d0bb7e7fe86abfe8991b0307d585874a
Author: Richard Biener <rguenther@suse.de>
Date:   Mon May 9 11:33:44 2022 +0200

    tree-optimization/105517 - avoid offset truncation during VN

    When value-numbering an address expression like
    &p_74(D)->a1x[4294967295].a1; we are accumulating the byte offset
    in an 64bit integer.  When later exploiting the duality between
    that and a POINTER_PLUS_EXPR we should avoid truncating that
    offset to fit in the target specific sizetype.  While such
    overflows are generally undefined behavior, exploiting this
    may leads to spurious missing diagnostics.

    2022-05-09  Richard Biener  <rguenther@suse.de>

            PR tree-optimization/105517
            * tree-ssa-sccvn.cc (vn_reference_lookup): Make sure the
accumulated
            offset can be represented in the POINTER_PLUS_EXPR IL.
            (vn_reference_insert): Likewise.
            * poly-int.h (sext_hwi): Add poly version of sext_hwi.

[Bug tree-optimization/105517] [13 Regression] Missing diagnostic after recent optimizer improvements

[rguenth at gcc dot gnu.org]

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

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

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

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed.