https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100363
Nick Desaulniers changed:
What|Removed |Added
CC||ndesaulniers at google dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100363
--- Comment #19 from rguenther at suse dot de ---
On Tue, 4 May 2021, vgupta at synopsys dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100363
>
> --- Comment #18 from Vineet Gupta ---
> (In reply to Richard Biener from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100363
--- Comment #18 from Vineet Gupta ---
(In reply to Richard Biener from comment #9)
> (In reply to Linus Torvalds from comment #8)
> > (In reply to Alexander Monakov from comment #7)
> > >
> > > Most likely the issue is that sout/sfrom are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100363
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100363
--- Comment #16 from Andrew Pinski ---
(In reply to Vineet Gupta from comment #15)
> The problem is is indeed gone. I need to analyze the assembly fully how it
> prevents the bad case. e.g. I'm still not comfortable seeing the loop
> entered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100363
--- Comment #15 from Vineet Gupta ---
(In reply to Linus Torvalds from comment #14)
> (In reply to Vineet Gupta from comment #13)
> > Sorry the workaround proposed by Alexander doesn't seem to cure it (patch
> > attached), outcome is the same
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100363
--- Comment #14 from Linus Torvalds ---
(In reply to Vineet Gupta from comment #13)
> Sorry the workaround proposed by Alexander doesn't seem to cure it (patch
> attached), outcome is the same
Vineet - it's not the ldd/std that is necessarily
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100363
--- Comment #13 from Vineet Gupta ---
Sorry the workaround proposed by Alexander doesn't seem to cure it (patch
attached), outcome is the same
mov lp_count,r13;5 #, bnd.65
lp @.L201 ; lp_count:@.L50->@.L201
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100363
--- Comment #12 from Vineet Gupta ---
Created attachment 50742
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50742=edit
kernel patch as proposed on comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100363
--- Comment #11 from Linus Torvalds ---
(In reply to Linus Torvalds from comment #10)
>
> This particular code comes
> from some old version of zlib, and I can't test because I don't have the ARC
> background to make any sense of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100363
--- Comment #10 from Linus Torvalds ---
(In reply to Richard Biener from comment #9)
>
> Note alignment has nothing to do with strict-aliasing (-fno-strict-aliasing
> you mean btw).
I obviously meant -fno-strict-aliasing, yes.
But I think
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100363
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100363
--- Comment #8 from Linus Torvalds ---
(In reply to Alexander Monakov from comment #7)
>
> Most likely the issue is that sout/sfrom are misaligned at runtime, while
> the vectorized code somewhere relies on them being sufficiently aligned for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100363
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100363
--- Comment #6 from Vineet Gupta ---
(In reply to Linus Torvalds from comment #4)
> (In reply to Andrew Pinski from comment #1)
> > The loop gets vectorized, I don't see the problem really.
>
>
> See
>
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100363
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |UNCONFIRMED
Ever confirmed|1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100363
Andrew Pinski changed:
What|Removed |Added
Component|middle-end |tree-optimization
Keywords|
17 matches
Mail list logo
