https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
Richard Biener changed:
What|Removed |Added
CC||iii at linux dot ibm.com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
Richard Biener changed:
What|Removed |Added
Blocks||93105
--- Comment #31 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
--- Comment #30 from Alexander Cherepanov ---
Sure, I've filed pr93105. Thanks for the analysis!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
--- Comment #29 from Alexander Monakov ---
(In reply to Alexander Cherepanov from comment #28)
> I see the same even with pure pointers. I guess RTL doesn't care about such
> differences but it means the problem could bite a relatively innocent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
--- Comment #28 from Alexander Cherepanov ---
I see the same even with pure pointers. I guess RTL doesn't care about such
differences but it means the problem could bite a relatively innocent code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
Richard Biener changed:
What|Removed |Added
CC||aleksei.voity...@bell-sw.co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
--- Comment #26 from Richard Biener ---
(In reply to Richard Biener from comment #25)
> When considering the patch from comment#18 additional data is that only
> 95802 out of 636160 disambiguations that ultimately require base_alias_check
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
--- Comment #25 from Richard Biener ---
When considering the patch from comment#18 additional data is that only
95802 out of 636160 disambiguations that ultimately require base_alias_check
involve non-CONST_INT_P "other" operand. That is out of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
--- Comment #24 from Richard Biener ---
On GCC testcases one large group of MEMs only disambiguated through
base_alias_check is disambiguations agains DSEs group_info->base_mem
which is BLKmode mems based on some "base" pointer. This base_mem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
--- Comment #23 from Richard Biener ---
(In reply to Richard Biener from comment #22)
> Things we fail to disambiguate are
>
> (mem:TF (pre_dec:SI (reg/f:SI 7 sp)) [0 S16 A8])
> vs.
> (mem/c:TF (plus:SI (reg/f:SI 19 frame)
> (const_int -16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
--- Comment #22 from Richard Biener ---
Things we fail to disambiguate are
(mem:TF (pre_dec:SI (reg/f:SI 7 sp)) [0 S16 A8])
vs.
(mem/c:TF (plus:SI (reg/f:SI 19 frame)
(const_int -16 [0xfff0])) [1 S16 A128])
or
(mem:SI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
--- Comment #21 from Richard Biener ---
Created attachment 45389
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45389=edit
statistic patch
patch I added to record statistics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
--- Comment #20 from Richard Biener ---
For stage3/gcc/*.o statistics show we perform 21051052 base_alias_check calls
and in the end 706852 times it is the one that would have disambiguated
things compared to if we remove it (thus as if we do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
--- Comment #19 from Richard Biener ---
(In reply to Richard Biener from comment #18)
> So for find_base_term to compute sth conservative we'd need to track
> RTX_SURELY_NON_POINTER (what RTX is surely _not_ based on a pointer
> and thus can be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
Richard Biener changed:
What|Removed |Added
Last reconfirmed|2018-06-04 00:00:00 |2019-1-8
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
--- Comment #17 from rguenther at suse dot de ---
On Mon, 4 Jun 2018, amonakov at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
>
> Alexander Monakov changed:
>
>What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
--- Comment #15 from Richard Biener ---
IMHO as RTL drops the difference between pointers and integers (of the same
mode)
it has to drop the assumption that pointer arithmetic has to stay inside a
pointed-to object similar to how it has to drop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
Richard Biener changed:
What|Removed |Added
Last reconfirmed|2016-10-19 00:00:00 |2018-6-4
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
Richard Biener changed:
What|Removed |Added
CC||pascal_cuoq at hotmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
Richard Biener changed:
What|Removed |Added
Keywords||alias
Last reconfirmed|2011-06-09
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
CC||jdemeyer at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
--- Comment #7 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-06-10
09:50:28 UTC ---
The alias.c machinery is clearly based on the fundamental assumption of pointer
arithmetics, i.e. that you aren't allowed to compute a difference unless
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
--- Comment #8 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-10
09:59:06 UTC ---
(In reply to comment #7)
The alias.c machinery is clearly based on the fundamental assumption of
pointer
arithmetics, i.e. that you aren't allowed to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
--- Comment #9 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-06-10
10:55:53 UTC ---
Creating that pointer is perfectly valid - you are allowed to cast a
pointer to an uintptr_t and back, which is what the code does (in some
obfuscated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
--- Comment #10 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-10
11:13:53 UTC ---
(In reply to comment #9)
Creating that pointer is perfectly valid - you are allowed to cast a
pointer to an uintptr_t and back, which is what the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
--- Comment #4 from rguenther at suse dot de rguenther at suse dot de
2011-06-09 10:08:55 UTC ---
On Thu, 9 Jun 2011, jakub at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
Jakub Jelinek jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
--- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-09
10:22:57 UTC ---
The testcase also fails similarly without the volatile qualification of d
when compiling with -O -fno-tree-fre -fno-tree-forwprop -fno-tree-reassoc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2011-06-09
10:38:37 UTC ---
find_base_value/find_base_term seem to be overly optimistic, prefer to return
something over being conservative. E.g. if both operands of PLUS or MINUS
return
32 matches
Mail list logo
