https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88775
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88775
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|8.3 |8.4
--- Comment #19 from Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88775
--- Comment #18 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #17)
> Without the #c11 patch (+ removal of the !INTEGRAL_TYPE_P special case from
> the above committed change + fixing up ptrs_compare_unequal, or something
> equivale
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88775
--- Comment #17 from Jakub Jelinek ---
Without the #c11 patch (+ removal of the !INTEGRAL_TYPE_P special case from the
above committed change + fixing up ptrs_compare_unequal, or something
equivalent like the VRP change) I'm afraid there isn't mu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88775
--- Comment #16 from Jakub Jelinek ---
Author: jakub
Date: Tue Jan 15 08:11:00 2019
New Revision: 267931
URL: https://gcc.gnu.org/viewcvs?rev=267931&root=gcc&view=rev
Log:
PR tree-optimization/88775
* match.pd (cmp (convert1?@2 a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88775
--- Comment #15 from Jakub Jelinek ---
Created attachment 45411
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45411&action=edit
gcc9-pr88775-2.patch
The following incremental patch (untested except for this testcase and
comparisons_pointe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88775
--- Comment #14 from Jakub Jelinek ---
Of course only for equality comparisons, for non-equality the code is ok as is.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88775
--- Comment #13 from Jakub Jelinek ---
Seems it is the:
/* When the addresses are not directly of decls compare base and offset.
This implements some remaining parts of fold_comparison address
comparisons but still no complete part of it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88775
--- Comment #12 from Jakub Jelinek ---
Unfortunately the #c11 patch breaks the
20_util/function_objects/comparisons_pointer.cc testcase (wonder if your VRP
patch would break it too), where the testcase does exactly what has been
discussed on IRC:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88775
--- Comment #11 from Jakub Jelinek ---
Created attachment 45405
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45405&action=edit
gcc9-pr88775.patch
Full patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88775
--- Comment #10 from Jakub Jelinek ---
I get pretty much the same thing with:
--- gcc/match.pd.jj 2019-01-07 17:59:24.100931144 +0100
+++ gcc/match.pd2019-01-10 14:45:31.870509916 +0100
@@ -1660,6 +1660,19 @@ (define_operator_list CON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88775
--- Comment #9 from Richard Biener ---
Created attachment 45404
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45404&action=edit
VRP patch
This makes VRP register asserts for the pointer variants. This doesn't help
until after ifcombine b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88775
--- Comment #8 from Jakub Jelinek ---
"hello" string literal surely can be followed by anything else, but don't we
consider it UB?
int
foo (void)
{
int a = 0;
for (int i = 0; i < 32; i++)
a += "hello"[i];
return a;
}
warning: iteration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88775
--- Comment #7 from Richard Biener ---
So after the patch we have
__x.5_4 = (long unsigned int) "hello";
__y.6_5 = (long unsigned int) _3;
if (__x.5_4 != __y.6_5)
goto ; [75.00%]
else
goto ; [25.00%]
[local count: 805306369]:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88775
--- Comment #6 from Jakub Jelinek ---
Author: jakub
Date: Thu Jan 10 10:56:56 2019
New Revision: 267800
URL: https://gcc.gnu.org/viewcvs?rev=267800&root=gcc&view=rev
Log:
PR tree-optimization/88775
* include/bits/stl_function.h (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88775
--- Comment #5 from Richard Biener ---
Created attachment 45401
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45401&action=edit
VN patch
Turns f() into just
[local count: 1073741824]:
_3 = &MEM[(struct basic_string *)s_2(D)].D.18989
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88775
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88775
--- Comment #3 from Richard Biener ---
So the
if (__x.7_6 < __y.8_7)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 38463891]:
if (__x.7_6 > __y.8_7)
goto ; [50.00%]
else
goto ; [50.00%]
fails to merge to != beca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88775
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88775
--- Comment #2 from Jonathan Wakely ---
Probably not. I don't think sanitizers flag the unspecified comparisons, so we
could just always do the uintptr_t comparisons for C++98/11. The patch looks
good to me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88775
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
21 matches
Mail list logo
