https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
--- Comment #35 from rguenther at suse dot de ---
On Tue, 16 Apr 2024, rearnsha at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
>
> --- Comment #34 from Richard Earnshaw ---
> To be honest, I'm more concerned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
--- Comment #34 from Richard Earnshaw ---
To be honest, I'm more concerned that we aren't eliminating a lot of these
copies during the gimple optimization phase. The memcpy is really a type
punning step (that's strictly ISO C compliant, rather
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
Richard Biener changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
--- Comment #32 from Richard Biener ---
(In reply to Richard Earnshaw from comment #31)
> While that does seem to fix the bug, it's at the cost of 6 additional stores
> in the problematic test that are redundant other than changing the alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
--- Comment #31 from Richard Earnshaw ---
While that does seem to fix the bug, it's at the cost of 6 additional stores in
the problematic test that are redundant other than changing the alias set view.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
--- Comment #30 from Richard Biener ---
I have tested the following since that might confuse the redundant store
removal sanity checks. It bootstraps fine on x86-64-unknown-linux-gnu but
causes
FAIL: gcc.dg/tree-ssa/ssa-dse-36.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
--- Comment #29 from Richard Earnshaw ---
Sorry, I was looking at the wrong pair of insns. The earlier store to that
location was insn 111.
111: [r212:SI (1 MEM[(struct Vec128 *)_179]+0 S4 A64)] = {r0:SI..r3:SI}
It appears that the problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
--- Comment #28 from Richard Biener ---
(In reply to Richard Earnshaw from comment #27)
> (In reply to Richard Earnshaw from comment #26)
> > (In reply to Richard Biener from comment #25)
> > > I think it's more interesting why
> > >
> > > *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
--- Comment #27 from Richard Earnshaw ---
(In reply to Richard Earnshaw from comment #26)
> (In reply to Richard Biener from comment #25)
> > I think it's more interesting why
> >
> > * 119: [r216:SI (2 MEM[(struct Vec128 *)_179]+0 S4 A64)] =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
--- Comment #26 from Richard Earnshaw ---
(In reply to Richard Biener from comment #25)
> I think it's more interesting why
>
> * 119: [r216:SI (2 MEM[(struct Vec128 *)_179]+0 S4 A64)] =
> {r0:SI..r3:SI}
>
> isn't considered as dependence?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
--- Comment #25 from Richard Biener ---
I think it's more interesting why
* 119: [r216:SI (2 MEM[(struct Vec128 *)_179]+0 S4 A64)] =
{r0:SI..r3:SI}
isn't considered as dependence? Why does the earlier insn even come into
play? What's the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
--- Comment #24 from Andrew Pinski ---
(In reply to Richard Earnshaw from comment #21)
> With my new testcase, compiled on an arm-none-eabi cross with
>
> cc1plus ../hwy-pr111231-cpp.cc -mfpu=neon-vfpv4 -mfloat-abi=hard
> -mfp16-format=ieee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
--- Comment #23 from Richard Earnshaw ---
#0 ptr_deref_may_alias_decl_p (ptr=0x75e0c678, decl=0x75dff000)
at /home/rearnsha/gnusrc/gcc-cross/gcc-13/gcc/tree-ssa-alias.cc:295
#1 0x01768173 in indirect_ref_may_alias_decl_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
--- Comment #22 from Richard Earnshaw ---
(Previous analysis is based on gcc-13 branch)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
Richard Earnshaw changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
--- Comment #20 from Richard Earnshaw ---
Created attachment 57928
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57928=edit
fully preprocessed testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
Richard Biener changed:
What|Removed |Added
Priority|P1 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
--- Comment #19 from Richard Earnshaw ---
This is another problem with (I suspect) incorrect aliasing information. If I
compile with -fno-strict-aliasing, I get
88: f4432a1fvst1.8 {d18-d19}, [r3 :64] // {>E} SP+96/16
8c:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
Sam James changed:
What|Removed |Added
Target Milestone|--- |12.4
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
Sam James changed:
What|Removed |Added
Known to fail||14.0
Known to work|
21 matches
Mail list logo
