https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
Jan Hubicka changed:
What|Removed |Added
Summary|[12/13/14/15 Regression]|[12/13/14 Regression] Wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
--- Comment #19 from Jan Hubicka ---
> Note I didn't check if it helps the testcase ..
I will check.
>
> > >
> > > A "nicer" solution might be to add a informational operand
> > > to TARGET_MEM_REF, representing the base pointer to be used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
--- Comment #18 from rguenther at suse dot de ---
On Wed, 14 Feb 2024, hubicka at ucw dot cz wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
>
> --- Comment #17 from Jan Hubicka ---
> > > I guess PTA gets around by tracking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
--- Comment #17 from Jan Hubicka ---
> > I guess PTA gets around by tracking points-to set also for non-pointer
> > types and consequently it also gives up on any such addition.
>
> It does. But note it does _not_ for POINTER_PLUS where it
> > I guess PTA gets around by tracking points-to set also for non-pointer
> > types and consequently it also gives up on any such addition.
>
> It does. But note it does _not_ for POINTER_PLUS where it treats
> the offset operand as non-pointer.
>
> > I think it is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
--- Comment #16 from rguenther at suse dot de ---
On Tue, 13 Feb 2024, hubicka at ucw dot cz wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
>
> --- Comment #15 from Jan Hubicka ---
> >
> > IVOPTs does the above but it does it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
--- Comment #15 from Jan Hubicka ---
>
> IVOPTs does the above but it does it (or should) as
>
> offset = (uintptr) - (uintptr)
> val = *((T *)((uintptr)base1 + i + offset))
>
> which is OK for points-to as no POINTER_PLUS_EXPR is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
--- Comment #14 from rguenther at suse dot de ---
On Tue, 13 Feb 2024, hubicka at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
>
> --- Comment #13 from Jan Hubicka ---
> So my understanding is that ivopts does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
--- Comment #13 from Jan Hubicka ---
So my understanding is that ivopts does something like
offset = -
and then translate
val = base2[i]
to
val = *((base1+i)+offset)
Where (base1+i) is then an iv variable.
I wonder if we consider doing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
--- Comment #12 from Alex Coplan ---
Here is an alternative testcase that also fails in the same way on the GCC 12
and 13 branches:
void foo(int x, int y, int z, int d, int *buf)
{
for(int i = z; i < y-z; ++i)
for(int j = 0; j < d; ++j)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
--- Comment #11 from Richard Biener ---
Btw, there's related IPA modref wrong-code issues where IPA and late summaries
are merged incorrectly (also receiving no attention)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
Richard Biener changed:
What|Removed |Added
Target||aarch64
--- Comment #10 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
--- Comment #9 from Andrew Pinski ---
_57 = [(int *)0B + _56 + _55 * 1];
*_57 = _14;
The fix for PR 110702 must not have been enough.
Or rather this part of the explanation was fully true:
```
The patch below
recognizes the fallback
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
--- Comment #8 from Jan Hubicka ---
I will take a look. Mod-ref only reuses the code detecting errneous paths in
ssa-split-paths, so that code will get confused, too. It makes sense for ivopts
to compute difference of two memory allocations,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
--- Comment #7 from Alex Coplan ---
(In reply to Andrew Pinski from comment #6)
> (In reply to Jakub Jelinek from comment #5)
> > My bisection points to r12-5915-ge93809f62363ba4b233858005aef652fb550e896
>
> Which means it is related to bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
--- Comment #6 from Andrew Pinski ---
(In reply to Jakub Jelinek from comment #5)
> My bisection points to r12-5915-ge93809f62363ba4b233858005aef652fb550e896
Which means it is related to bug 110702 .
Again try -fno-ivopts . I suspect ivopts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2024-02-06
17 matches
Mail list logo
