[Bug testsuite/98771] New: [10/11 regression] gcc.dg/strcmpopt_8.c FAILs

[Bug testsuite/98771] New: [10/11 regression] gcc.dg/strcmpopt_8.c FAILs

[ro at gcc dot gnu.org]

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

            Bug ID: 98771
           Summary: [10/11 regression] gcc.dg/strcmpopt_8.c FAILs
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: testsuite
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ro at gcc dot gnu.org
                CC: msebor at gcc dot gnu.org
  Target Milestone: ---
            Target: i386-pc-solaris2.11, sparc-sun-solaris2.11

Created attachment 50012
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50012&action=edit
i386-pc-solaris2.11 64-bit strcmpopt_8.c.033t.forwprop1

As originally reported in PR tree-optimization/92683, the gcc.dg/strcmpopt_8.c
test still FAILs on both Solaris/x86 and SPARC:

* on x86 with -m64 only:

FAIL: gcc.dg/strcmpopt_8.c scan-tree-dump-not forwprop1 "strncmp"

* on sparc with -m64 only:

FAIL: gcc.dg/strcmpopt_8.c (test for excess errors)

Excess errors:
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/strcmpopt_8.c:22:15: warning:
'__builtin_strncmp' specified bound 18446744073709551615 exceeds maximum object
size 9223372036854775807 [-Wstringop-overread]
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/strcmpopt_8.c:22:15: warning:
'__builtin_strncmp' specified bound 18446744073709551615 exceeds maximum object
size 9223372036854775807 [-Wstringop-overread]
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/strcmpopt_8.c:22:15: warning:
'__builtin_strncmp' specified bound 18446744073709551615 exceeds maximum object
size 9223372036854775807 [-Wstringop-overread]
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/strcmpopt_8.c:22:15: warning:
'__builtin_strncmp' specified bound 18446744073709551615 exceeds maximum object
size 9223372036854775807 [-Wstringop-overread]
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/strcmpopt_8.c:22:15: warning:
'__builtin_strncmp' specified bound 18446744073709551615 exceeds maximum object
size 9223372036854775807 [-Wstringop-overread]
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/strcmpopt_8.c:22:15: warning:
'__builtin_strncmp' specified bound 18446744073709551615 exceeds maximum object
size 9223372036854775807 [-Wstringop-overread]
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/strcmpopt_8.c:22:15: warning:
'__builtin_strncmp' specified bound 18446744073709551615 exceeds maximum object
size 9223372036854775807 [-Wstringop-overread]

FAIL: gcc.dg/strcmpopt_8.c scan-tree-dump-not forwprop1 "strncmp"

This only happens with 32-bit-default compilers, the corresponding
64-bit-default
compilers don't show the failure.

I'm attaching both the amd64 and sparcv9 dumps (which are effectively
identical).

[Bug testsuite/98771] [10/11 regression] gcc.dg/strcmpopt_8.c FAILs

[ro at gcc dot gnu.org]

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

--- Comment #1 from Rainer Orth <ro at gcc dot gnu.org> ---
Created attachment 50013
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50013&action=edit
64-bit sparc-sun-solaris2.11 strcmpopt_8.c.033t.forwprop1

[Bug testsuite/98771] [10/11 regression] gcc.dg/strcmpopt_8.c FAILs

[ro at gcc dot gnu.org]

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

Rainer Orth <ro at gcc dot gnu.org> changed:

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

[Bug testsuite/98771] [10/11 regression] gcc.dg/strcmpopt_8.c FAILs

[msebor at gcc dot gnu.org]

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

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2021-01-22
             Status|UNCONFIRMED                 |WAITING

--- Comment #2 from Martin Sebor <msebor at gcc dot gnu.org> ---
I can't reproduce these failures with my solaris2.11 cross.  The dump and the
warnings indicate that it's only the strncmp calls with a bound of SIZE_MAX
that aren't folded in your environment, like this one:

  void f (void)
  { 
    if (!(0 > __builtin_strncmp ("123", "12345", __SIZE_MAX__)))
      __builtin_abort ();   // should be eliminated
  }

All other calls, including those with SIZE_MAX - 1, are folded successfully. 
The folding happens in fold_const_call() in fold-const-call.c:

    case CFN_BUILT_IN_STRNCMP:
      if (!host_size_t_cst_p (arg2, &s2))
        return NULL_TREE;
      if (s2 == 0
          && !TREE_SIDE_EFFECTS (arg0)
          && !TREE_SIDE_EFFECTS (arg1))
        return build_int_cst (type, 0);
      else if ((p0 = c_getstr (arg0)) && (p1 = c_getstr (arg1)))
        return build_int_cst (type, strncmp (p0, p1, s2));
      return NULL_TREE;

I wonder if the host_size_t_cst_p() test passes for you.  If the native GCC's
size_t is a 32-bit type then that might explain why it would fail, but then I'm
not sure what lets the calls with SIZE_MAX - 1 be folded.

[Bug testsuite/98771] [10/11 regression] gcc.dg/strcmpopt_8.c FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #2 from Martin Sebor <msebor at gcc dot gnu.org> ---
> I can't reproduce these failures with my solaris2.11 cross.  The dump and the

Please note that the failure only occurs for i386-pc-solaris2.11 and
sparc-sun-solaris2.11 compilers with -m64.

> warnings indicate that it's only the strncmp calls with a bound of SIZE_MAX
> that aren't folded in your environment, like this one:
>
>   void f (void)
>   { 
>     if (!(0 > __builtin_strncmp ("123", "12345", __SIZE_MAX__)))
>       __builtin_abort ();   // should be eliminated
>   }

I've used that testcase for my further attempts.

> All other calls, including those with SIZE_MAX - 1, are folded successfully. 
> The folding happens in fold_const_call() in fold-const-call.c:
[...]
> I wonder if the host_size_t_cst_p() test passes for you.  If the native GCC's

It doesn't: the function always returns false.  Further debugging is
impossible right now, though: all attempts to access the args are
greeted with

dwarf2_find_location_expression: Corrupted DWARF expression.

by gdb 10.1.  Yet another boon of the DWARF-5 switch, I guess ;-(

> size_t is a 32-bit type then that might explain why it would fail, but then I'm

Of course it is (unsigned int), just as on i686-pc-linux-gnu.  What else
would it be in a 32-bit environment?

> not sure what lets the calls with SIZE_MAX - 1 be folded.

Indeed, and beyond that it's strange that the failure doesn't occur on
other multilibbed 32-bit targets (e.g. on i686-pc-linux-gnu with -m64).

[Bug testsuite/98771] [10/11 regression] gcc.dg/strcmpopt_8.c FAILs

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #3)
> Please note that the failure only occurs for i386-pc-solaris2.11 and
> sparc-sun-solaris2.11 compilers with -m64.

Martin, you can easily simulate that by changing
host_size_t_cst_p:
       && (wi::min_precision (wi::to_wide (t), UNSIGNED)
-          <= sizeof (size_t) * CHAR_BIT))
+          <= sizeof (unsigned) * CHAR_BIT))

That will make your 64-bit gcc behave like Rainer's 32-bit gcc targeting -m64.
I'd say we want to kill that function or adjust it all.
Perhaps change it into writing unsigned HOST_WIDE_INT value instead of size_t,
and then in the callers if that s2 is > SIZE_MAX see whether we care or not.
E.g. on:
      if (!host_size_t_cst_p (arg2, &s2))
        return NULL_TREE;
      if (s2 == 0
          && !TREE_SIDE_EFFECTS (arg0)
          && !TREE_SIDE_EFFECTS (arg1))
        return build_int_cst (type, 0);
      else if ((p0 = c_getstr (arg0)) && (p1 = c_getstr (arg1)))
        return build_int_cst (type, strncmp (p0, p1, s2));
when the adjusted (and probably renamed) function writes unsigned HOST_WIDE_INT
s2 if it satisfies tree_fits_uhwi_p, the s2 == 0 test should remain, but
I think the other use should be either strncmp (p0, p1, MIN (s2, SIZE_MAX));
or s2 > SIZE_MAX ? strcmp (p0, p1) : strncmp (p0, p1, s2);, for warnings
perhaps the former is better.

The
CFN_BUILT_IN_BCMP/CFN_BUILT_IN_MEMCMP case is fine as is, because it compares
s2 <= s0 && s2 <= s1 and memchr too.

[Bug testsuite/98771] [10/11 regression] gcc.dg/strcmpopt_8.c FAILs

[jakub at gcc dot gnu.org]

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

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|WAITING                     |ASSIGNED

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 50028
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50028&action=edit
gcc11-pr98771.patch

Untested fix.

[Bug testsuite/98771] [10/11 regression] gcc.dg/strcmpopt_8.c FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> Created attachment 50028
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50028&action=edit
> gcc11-pr98771.patch
>
> Untested fix.

I've now managed to test the patch on i386-pc-solaris2.11,
sparc-sun-solaris2.11 and (for good measure) amd64-pc-solaris2.11,
sparcv9-sun-solaris2.11.  The failures are gone.  Thanks.

[Bug testsuite/98771] [10/11 regression] gcc.dg/strcmpopt_8.c FAILs

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 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:b7a0507ad9f07492a37325a2f494ed933b217a9a

commit r11-6885-gb7a0507ad9f07492a37325a2f494ed933b217a9a
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Mon Jan 25 10:03:40 2021 +0100

    fold: Fix up strn{case,}cmp folding [PR98771]

    As mentioned in the PR, the compiler behaves differently during strncmp
    and strncasecmp folding between 32-bit and 64-bit hosts targeting 64-bit
    target.  I think that is highly undesirable.

    The culprit is the host_size_t_cst_p predicate that is used by
    fold_const_call, which punts if the target size_t constants don't fit into
    host size_t.  This patch gets rid of that behavior, instead it punts the
    same when it doesn't fit into uhwi.

    The predicate was used for strncmp and strncasecmp folding and for bcmp,
memcmp and
    memchr folding.
    The constant is in all cases compared to 0, we can do that whether it fits
    into size_t or unsigned HOST_WIDE_INT, then it is used in s2 <= s0 or
    s2 <= s1 comparisons where s0 and s1 already have uhwi type and represent
    the sizes of the objects.
    The important difference is for strn{,case}cmp folding, we pass that s2
    value as the last argument to the host functions comparing the c_getstr
    results.  If s2 fits into size_t, then my patch makes no difference,
    but if it is larger, we know the 2 c_getstr objects need to fit into the
    host address space, so larger s2 should just act essentially as strcmp
    or strcasecmp; as none of those objects can occupy 100% of the address
    space, using MIN (SIZE_MAX, s2) achieves that.

    2021-01-25  Jakub Jelinek  <jakub@redhat.com>

            PR testsuite/98771
            * fold-const-call.c (host_size_t_cst_p): Renamed to ...
            (size_t_cst_p): ... this.  Check and store unsigned HOST_WIDE_INT
            value rather than host size_t.
            (fold_const_call): Change type of s2 from size_t to
            unsigned HOST_WIDE_INT.  Use size_t_cst_p instead of
            host_size_t_cst_p.  For strncmp calls, pass MIN (s2, SIZE_MAX)
            instead of s2 as last argument.

[Bug testsuite/98771] [10 regression] gcc.dg/strcmpopt_8.c FAILs

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[10/11 regression]          |[10 regression]
                   |gcc.dg/strcmpopt_8.c FAILs  |gcc.dg/strcmpopt_8.c FAILs

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

[Bug testsuite/98771] [10 regression] gcc.dg/strcmpopt_8.c FAILs

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-9320-gc20cd1688aed7014b52ed03cde143b6327a89e7a
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Mon Jan 25 10:03:40 2021 +0100

    fold: Fix up strn{case,}cmp folding [PR98771]

    As mentioned in the PR, the compiler behaves differently during strncmp
    and strncasecmp folding between 32-bit and 64-bit hosts targeting 64-bit
    target.  I think that is highly undesirable.

    The culprit is the host_size_t_cst_p predicate that is used by
    fold_const_call, which punts if the target size_t constants don't fit into
    host size_t.  This patch gets rid of that behavior, instead it punts the
    same when it doesn't fit into uhwi.

    The predicate was used for strncmp and strncasecmp folding and for bcmp,
memcmp and
    memchr folding.
    The constant is in all cases compared to 0, we can do that whether it fits
    into size_t or unsigned HOST_WIDE_INT, then it is used in s2 <= s0 or
    s2 <= s1 comparisons where s0 and s1 already have uhwi type and represent
    the sizes of the objects.
    The important difference is for strn{,case}cmp folding, we pass that s2
    value as the last argument to the host functions comparing the c_getstr
    results.  If s2 fits into size_t, then my patch makes no difference,
    but if it is larger, we know the 2 c_getstr objects need to fit into the
    host address space, so larger s2 should just act essentially as strcmp
    or strcasecmp; as none of those objects can occupy 100% of the address
    space, using MIN (SIZE_MAX, s2) achieves that.

    2021-01-25  Jakub Jelinek  <jakub@redhat.com>

            PR testsuite/98771
            * fold-const-call.c (host_size_t_cst_p): Renamed to ...
            (size_t_cst_p): ... this.  Check and store unsigned HOST_WIDE_INT
            value rather than host size_t.
            (fold_const_call): Change type of s2 from size_t to
            unsigned HOST_WIDE_INT.  Use size_t_cst_p instead of
            host_size_t_cst_p.  For strncmp calls, pass MIN (s2, SIZE_MAX)
            instead of s2 as last argument.

[Bug testsuite/98771] [10 regression] gcc.dg/strcmpopt_8.c FAILs

[jakub at gcc dot gnu.org]

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

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

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

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