[Bug target/115934] [15 Regression] nvptx vs. ivopts: replace constant_multiple_of with aff_combination_constant_multiple_p [PR114932]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115934 Tamar Christina changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot gnu.org

[Bug target/115936] [15 Regression] GCN vs. ivopts: replace constant_multiple_of with aff_combination_constant_multiple_p [PR114932]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115936 Tamar Christina changed: What|Removed |Added Ever confirmed|0 |1 CC|

[Bug target/115936] [15 Regression] GCN vs. ivopts: replace constant_multiple_of with aff_combination_constant_multiple_p [PR114932]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115936 Tamar Christina changed: What|Removed |Added Target Milestone|--- |15.0 --- Comment #2 from Tamar Christ

[Bug target/115934] [15 Regression] nvptx vs. ivopts: replace constant_multiple_of with aff_combination_constant_multiple_p [PR114932]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115934 --- Comment #4 from Tamar Christina --- This one looks a bit like costing, before the patch IVopts had: : inv_expr 1: -element_7(D) inv_expr 2: (signed int) rite_5(D) - (signed int) element_7(D) and after the patch it generates a few

[Bug target/115936] [15 Regression] GCN vs. ivopts: replace constant_multiple_of with aff_combination_constant_multiple_p [PR114932]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115936 --- Comment #4 from Tamar Christina --- (In reply to Richard Biener from comment #3) > iv->step should never be a pointer type That's what I initially thought too. My suspicion is that there is some code that tries to create the 0 offset. I'l

[Bug target/115934] [15 Regression] nvptx vs. ivopts: replace constant_multiple_of with aff_combination_constant_multiple_p [PR114932]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115934 --- Comment #7 from Tamar Christina --- (In reply to Thomas Schwinge from comment #6) > Tamar, Richard, thanks for having a look. > > (In reply to Tamar Christina from comment #4) > > This one looks a bit like costing, [...] > > I see. So we

[Bug target/115936] [15 Regression] GCN vs. ivopts: replace constant_multiple_of with aff_combination_constant_multiple_p [PR114932]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115936 --- Comment #5 from Tamar Christina --- (In reply to Richard Biener from comment #3) > iv->step should never be a pointer type This is created by SCEV. simple_iv_with_niters in the case where no CHREC is found creates an IV with base == ev, of

[Bug target/115936] [15 Regression] GCN vs. ivopts: replace constant_multiple_of with aff_combination_constant_multiple_p [PR114932]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115936 --- Comment #6 from Tamar Christina --- (In reply to Richard Biener from comment #3) > iv->step should never be a pointer type This is created by SCEV. simple_iv_with_niters in the case where no CHREC is found creates an IV with base == ev, of

[Bug tree-optimization/115936] [15 Regression] GCN vs. ivopts: replace constant_multiple_of with aff_combination_constant_multiple_p [PR114932]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115936 Tamar Christina changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 115531, which changed state. Bug 115531 Summary: vectorizer generates inefficient code for masked conditional update loops https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115531 What|Removed

[Bug tree-optimization/115531] vectorizer generates inefficient code for masked conditional update loops

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115531 Tamar Christina changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED

[Bug fortran/90608] Inline non-scalar minloc/maxloc calls

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90608 --- Comment #20 from Tamar Christina --- Hi Mikael, I did regression testing on x86_64 and AArch64 and only found one test-ism. I think I understand most of the patch to be able to deal with any fallout, would it be ok if I fix the test-ism and

[Bug ipa/106783] [12/13/14/15 Regression] ICE in ipa-modref.cc:analyze_function since r12-5247-ga34edf9a3e907de2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106783 --- Comment #8 from Tamar Christina --- (In reply to Jan Hubicka from comment #6) > The problem is that n/=0 is undefined behavior (so we can optimize out call > to function doing divide by zero), while __builtin_trap is observable and we > do n

[Bug fortran/90608] Inline non-scalar minloc/maxloc calls

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90608 --- Comment #22 from Tamar Christina --- (In reply to Mikael Morin from comment #21) > (In reply to Tamar Christina from comment #20) > > Hi Mikael, > > > > I did regression testing on x86_64 and AArch64 and only found one test-ism. > > > > I t

[Bug tree-optimization/116074] [15 regression] ICE when building harfbuzz-9.0.0 on arm64 (related_int_vector_mode, at stor-layout.cc:581)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116074 Tamar Christina changed: What|Removed |Added Last reconfirmed||2024-07-25 Assignee|unassig

[Bug tree-optimization/116074] [15 regression] ICE when building harfbuzz-9.0.0 on arm64 (related_int_vector_mode, at stor-layout.cc:581)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116074 --- Comment #7 from Tamar Christina --- The backend is returning TImode for get_vectype_for_scalar_type for historical reasons where large integer modes were considered struct types and this vector modes. However they're not modes the vectorize

[Bug tree-optimization/116074] [15 regression] ICE when building harfbuzz-9.0.0 on arm64 (related_int_vector_mode, at stor-layout.cc:581)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116074 --- Comment #8 from Tamar Christina --- Going with a backend fix instead.

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 116074, which changed state. Bug 116074 Summary: [15 regression] ICE when building harfbuzz-9.0.0 on arm64 (related_int_vector_mode, at stor-layout.cc:581) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116074 W

[Bug target/116074] [15 regression] ICE when building harfbuzz-9.0.0 on arm64 (related_int_vector_mode, at stor-layout.cc:581)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116074 Tamar Christina changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug libstdc++/116140] [15 Regression] 5-35% slowdown of 483.xalancbmk and 523.xalancbmk_r since r15-2356-ge69456ff9a54ba

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116140 --- Comment #1 from Tamar Christina --- Yeah, we've noticed it as well. The weird thing is that the dynamic instruction count went up by a lot. So it looks like some inlining or something did not happen.

[Bug tree-optimization/116812] [15 Regression] ICE on valid code at -O2 with "-fno-tree-dce -fno-tree-dse" on x86_64-linux-gnu: verify_flow_info failed

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116812 Tamar Christina changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot gnu.org

[Bug tree-optimization/116817] [15 Regression] ICE on libajantv2-16.2: in compute_live_loop_exits, at tree-ssa-loop-manip.cc:250 since r15-3768-g4150bcd205ebb6

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116817 --- Comment #4 from Tamar Christina --- I see, I haven't checked that the value being compared is actually loop invariant. In this case it's a reduction value and it can't be lifted out of the loop. Basically in GCC 14 and earlier this was a

[Bug tree-optimization/116817] [15 Regression] ICE on libajantv2-16.2: in compute_live_loop_exits, at tree-ssa-loop-manip.cc:250

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116817 Tamar Christina changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED

[Bug tree-optimization/116812] [15 Regression] ICE on valid code at -O2 with "-fno-tree-dce -fno-tree-dse" on x86_64-linux-gnu: verify_flow_info failed

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116812 Tamar Christina changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug tree-optimization/116817] [15 Regression] ICE on libajantv2-16.2: in compute_live_loop_exits, at tree-ssa-loop-manip.cc:250 since r15-3768-g4150bcd205ebb6

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116817 Tamar Christina changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigne

[Bug tree-optimization/116817] [15 Regression] ICE on libajantv2-16.2: in compute_live_loop_exits, at tree-ssa-loop-manip.cc:250 since r15-3768-g4150bcd205ebb6

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116817 --- Comment #5 from Tamar Christina --- Waiting for regression testing to finish and will submit. The condition used before to check for loop invariant is !internal_def. This of course fails when it's a reduction, which is what happened here.

[Bug target/116371] The SME2 svpext intrinsics are missing a _lane suffix

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116371 Tamar Christina changed: What|Removed |Added CC||tnfchris at gcc dot gnu.org --- Comme

[Bug tree-optimization/116583] vectorizable_slp_permutation cannot handle even/odd extract from VLA vector

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116583 --- Comment #3 from Tamar Christina --- (In reply to Richard Biener from comment #2) > Another example this shows is for gcc.dg/vect/slp-42.c - we definitely can > do the interleaving scheme as non-SLP vectorization shows. > > gcc.dg/vect/slp-4

[Bug fortran/90608] Inline non-scalar minloc/maxloc calls

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90608 --- Comment #33 from Tamar Christina --- Many Thanks Mikael! I see the functions being inlined now!

[Bug tree-optimization/116817] [15 Regression] ICE on libajantv2-16.2: in compute_live_loop_exits, at tree-ssa-loop-manip.cc:250 since r15-3768-g4150bcd205ebb6

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116817 Tamar Christina changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED

[Bug tree-optimization/116855] [14/15 Regression] Unsafe early-break vectorization

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116855 Tamar Christina changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot gnu.org -

[Bug tree-optimization/116950] New: IVopts missed unification of duplicate IVs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116950 Bug ID: 116950 Summary: IVopts missed unification of duplicate IVs Product: gcc Version: 15.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal

[Bug tree-optimization/116956] [15 Regression] ICE when building PALM with -O3 -march=armv9-a in vect_analyze_loop_1 after r15-2192-g0c5c0c959c2e59

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116956 Tamar Christina changed: What|Removed |Added CC||tnfchris at gcc dot gnu.org --- Comme

[Bug tree-optimization/116855] [14/15 Regression] Unsafe early-break vectorization

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116855 --- Comment #6 from Tamar Christina --- > Actually, what I wish is that we could allow vectorization on early break > case for arbitrary address pointer (knowing nothing about alignment and > bound) based on some sort of assumption specified via

<    4   5   6   7   8   9