https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683
--- Comment #26 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:8fc5593df8e0d36cc5bd8ea21097a491a634a866
commit r14-9639-g8fc5593df8e0d36cc5bd8ea21097a491a634a866
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683
--- Comment #25 from rguenther at suse dot de ---
On Fri, 22 Mar 2024, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683
>
> --- Comment #24 from Jakub Jelinek ---
> (In reply to Richard Biener from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683
--- Comment #24 from Jakub Jelinek ---
(In reply to Richard Biener from comment #23)
> It looks like this could go to suitable_reference_p instead?
You mean return false for those making them not suitable at all?
I thought without a write such
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683
--- Comment #23 from Richard Biener ---
It looks like this could go to suitable_reference_p instead?
That said, I do wonder why with my patch split_data_refs_to_components
doesn't fixup. I think it's supposed to handle the case where
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683
Jakub Jelinek changed:
What|Removed |Added
Attachment #57768|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683
--- Comment #21 from Jakub Jelinek ---
Created attachment 57768
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57768=edit
gcc14-pr111683.patch
Updated patch which uses wi::multiple_of_p but doesn't regress pr71083.c.
To be precise, it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683
--- Comment #20 from Jakub Jelinek ---
That is true. I've been also wondering whether e.g. for the pr71083.c case we
couldn't just look through all COMPONENT_REFs of the DR_REF (and maybe
ARRAY_REFs with constant indexes) and check type size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683
--- Comment #19 from Richard Biener ---
But note that {0, +, 3 } and {2, + , 3} with size 2 will still eventually
overlap. See dr_analyze_indices where we attempt to make DR_INIT a
multiple of the element size (probably also not a perfect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683
--- Comment #18 from Jakub Jelinek ---
Using wi::multiple_of_p is what I've tried first but that regressed the
generated code for pr71083.c (the test still PASSed, but predcom no longer
triggered on it).
I think it has access size 3 and step 4,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683
--- Comment #17 from Jakub Jelinek ---
Created attachment 57767
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57767=edit
gcc14-pr111683.patch
Patch I've tested overnight for this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683
--- Comment #16 from Richard Biener ---
Created attachment 57766
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57766=edit
patch
Oddly enough the following patch doesn't fix it but it correctly prevents us
from recording the access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683
Richard Biener changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683
Jakub Jelinek changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683
--- Comment #13 from Andrew Pinski ---
(In reply to Jakub Jelinek from comment #12)
> Further simplified without any headers, -O1 works, -O2 fails.
For this testcase (at -O3), GCC 4.7.4 works but 4.8.1 fails.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683
--- Comment #12 from Jakub Jelinek ---
Further simplified without any headers, -O1 works, -O2 fails.
double a[2] = { 0.8147, 0.9058 };
double b[6] = { 0.1576, 0.9706, 1, 1, 1, 1 };
double c[16];
typedef double U __attribute__ ((vector_size(16),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683
Jakub Jelinek changed:
What|Removed |Added
Priority|P1 |P2
--- Comment #11 from Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683
--- Comment #10 from Andrew Pinski ---
Created attachment 57678
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57678=edit
testcase that fails all the way back to GCC 4.8.x
This one fails until GCC 4.8.1, works in GCC 4.7.4 but that is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683
--- Comment #9 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #8)
> Note with the reduced testcase in comment #7, -fno-tree-vrp has no effect on
> it any more so it might make sense to do another bisection on that testcase.
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683
Andrew Pinski changed:
What|Removed |Added
Keywords|needs-reduction |
--- Comment #8 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683
--- Comment #7 from Andrew Pinski ---
Created attachment 57677
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57677=edit
Slightly more reduced
Removes the extra induction variables and manually unroll the inner loop.
What I am seeing is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683
--- Comment #6 from Sam James ---
Created attachment 57660
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57660=edit
reduced.c
Bit smaller.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683
--- Comment #5 from kugan at gcc dot gnu.org ---
-O3 -fno-tree-vectorize and -O3 -fno-tree-vrp works. I looked at the ever
dump and it is not doing anything suspicious. Looks like range_info usage in
vectoriser is causing the problem.
22 matches
Mail list logo
