* [Bug testsuite/98771] [10/11 regression] gcc.dg/strcmpopt_8.c FAILs
2021-01-20 14:55 [Bug testsuite/98771] New: [10/11 regression] gcc.dg/strcmpopt_8.c FAILs ro at gcc dot gnu.org
@ 2021-01-20 14:56 ` ro at gcc dot gnu.org
2021-01-20 14:57 ` ro at gcc dot gnu.org
` (9 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: ro at gcc dot gnu.org @ 2021-01-20 14:56 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug testsuite/98771] [10/11 regression] gcc.dg/strcmpopt_8.c FAILs
2021-01-20 14:55 [Bug testsuite/98771] New: [10/11 regression] gcc.dg/strcmpopt_8.c FAILs ro at gcc dot gnu.org
2021-01-20 14:56 ` [Bug testsuite/98771] " ro at gcc dot gnu.org
@ 2021-01-20 14:57 ` ro at gcc dot gnu.org
2021-01-22 0:30 ` msebor at gcc dot gnu.org
` (8 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: ro at gcc dot gnu.org @ 2021-01-20 14:57 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug testsuite/98771] [10/11 regression] gcc.dg/strcmpopt_8.c FAILs
2021-01-20 14:55 [Bug testsuite/98771] New: [10/11 regression] gcc.dg/strcmpopt_8.c FAILs ro at gcc dot gnu.org
2021-01-20 14:56 ` [Bug testsuite/98771] " ro at gcc dot gnu.org
2021-01-20 14:57 ` ro at gcc dot gnu.org
@ 2021-01-22 0:30 ` msebor at gcc dot gnu.org
2021-01-22 9:25 ` ro at CeBiTec dot Uni-Bielefeld.DE
` (7 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: msebor at gcc dot gnu.org @ 2021-01-22 0:30 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug testsuite/98771] [10/11 regression] gcc.dg/strcmpopt_8.c FAILs
2021-01-20 14:55 [Bug testsuite/98771] New: [10/11 regression] gcc.dg/strcmpopt_8.c FAILs ro at gcc dot gnu.org
` (2 preceding siblings ...)
2021-01-22 0:30 ` msebor at gcc dot gnu.org
@ 2021-01-22 9:25 ` ro at CeBiTec dot Uni-Bielefeld.DE
2021-01-22 10:12 ` jakub at gcc dot gnu.org
` (6 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: ro at CeBiTec dot Uni-Bielefeld.DE @ 2021-01-22 9:25 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug testsuite/98771] [10/11 regression] gcc.dg/strcmpopt_8.c FAILs
2021-01-20 14:55 [Bug testsuite/98771] New: [10/11 regression] gcc.dg/strcmpopt_8.c FAILs ro at gcc dot gnu.org
` (3 preceding siblings ...)
2021-01-22 9:25 ` ro at CeBiTec dot Uni-Bielefeld.DE
@ 2021-01-22 10:12 ` jakub at gcc dot gnu.org
2021-01-22 10:30 ` jakub at gcc dot gnu.org
` (5 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-01-22 10:12 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug testsuite/98771] [10/11 regression] gcc.dg/strcmpopt_8.c FAILs
2021-01-20 14:55 [Bug testsuite/98771] New: [10/11 regression] gcc.dg/strcmpopt_8.c FAILs ro at gcc dot gnu.org
` (4 preceding siblings ...)
2021-01-22 10:12 ` jakub at gcc dot gnu.org
@ 2021-01-22 10:30 ` jakub at gcc dot gnu.org
2021-01-24 14:26 ` ro at CeBiTec dot Uni-Bielefeld.DE
` (4 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-01-22 10:30 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug testsuite/98771] [10/11 regression] gcc.dg/strcmpopt_8.c FAILs
2021-01-20 14:55 [Bug testsuite/98771] New: [10/11 regression] gcc.dg/strcmpopt_8.c FAILs ro at gcc dot gnu.org
` (5 preceding siblings ...)
2021-01-22 10:30 ` jakub at gcc dot gnu.org
@ 2021-01-24 14:26 ` ro at CeBiTec dot Uni-Bielefeld.DE
2021-01-25 9:04 ` cvs-commit at gcc dot gnu.org
` (3 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: ro at CeBiTec dot Uni-Bielefeld.DE @ 2021-01-24 14:26 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug testsuite/98771] [10/11 regression] gcc.dg/strcmpopt_8.c FAILs
2021-01-20 14:55 [Bug testsuite/98771] New: [10/11 regression] gcc.dg/strcmpopt_8.c FAILs ro at gcc dot gnu.org
` (6 preceding siblings ...)
2021-01-24 14:26 ` ro at CeBiTec dot Uni-Bielefeld.DE
@ 2021-01-25 9:04 ` cvs-commit at gcc dot gnu.org
2021-01-25 9:10 ` [Bug testsuite/98771] [10 " jakub at gcc dot gnu.org
` (2 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-01-25 9:04 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug testsuite/98771] [10 regression] gcc.dg/strcmpopt_8.c FAILs
2021-01-20 14:55 [Bug testsuite/98771] New: [10/11 regression] gcc.dg/strcmpopt_8.c FAILs ro at gcc dot gnu.org
` (7 preceding siblings ...)
2021-01-25 9:04 ` cvs-commit at gcc dot gnu.org
@ 2021-01-25 9:10 ` jakub at gcc dot gnu.org
2021-01-29 19:19 ` cvs-commit at gcc dot gnu.org
2021-01-29 19:24 ` jakub at gcc dot gnu.org
10 siblings, 0 replies; 12+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-01-25 9:10 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug testsuite/98771] [10 regression] gcc.dg/strcmpopt_8.c FAILs
2021-01-20 14:55 [Bug testsuite/98771] New: [10/11 regression] gcc.dg/strcmpopt_8.c FAILs ro at gcc dot gnu.org
` (8 preceding siblings ...)
2021-01-25 9:10 ` [Bug testsuite/98771] [10 " jakub at gcc dot gnu.org
@ 2021-01-29 19:19 ` cvs-commit at gcc dot gnu.org
2021-01-29 19:24 ` jakub at gcc dot gnu.org
10 siblings, 0 replies; 12+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-01-29 19:19 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug testsuite/98771] [10 regression] gcc.dg/strcmpopt_8.c FAILs
2021-01-20 14:55 [Bug testsuite/98771] New: [10/11 regression] gcc.dg/strcmpopt_8.c FAILs ro at gcc dot gnu.org
` (9 preceding siblings ...)
2021-01-29 19:19 ` cvs-commit at gcc dot gnu.org
@ 2021-01-29 19:24 ` jakub at gcc dot gnu.org
10 siblings, 0 replies; 12+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-01-29 19:24 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 12+ messages in thread