https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102218
--- Comment #4 from Tamar Christina ---
(In reply to ktkachov from comment #3)
> Does this need to be backported to other release versions as it's a
> wrong-code bug?
Yes Ideally. I did ask for backport but was only approved for master.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108172
Tamar Christina changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot
gnu.org
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108172
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105451
Bug ID: 105451
Summary: miss optimizations due to inconsistency in complex
numbers associativity
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: misse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94793
Tamar Christina changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102218
Tamar Christina changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105874
Bug ID: 105874
Summary: [13 Regression] Incorrect codegen and ICE since
g:ed6fd2aed58f2cca99f15331bf68999c0e6df370
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105874
--- Comment #3 from Tamar Christina ---
(In reply to Roger Sayle from comment #1)
> Hi Tamar.
> I'm truly sorry for the inconvenience. Can you try reducing again now that
> the load_register_parameters issue with the "small const structs as
> i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105874
--- Comment #5 from Tamar Christina ---
Ah, great, Thanks Roger!
I did end up reducing it to:
template class b {
public:
int c[a];
int operator[](long d) const { return c[d]; }
};
class board {
bool is_eye(int, int);
static const b<2>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105874
--- Comment #8 from Tamar Christina ---
Can confirm that the benchmark works again.
Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106063
--- Comment #3 from Tamar Christina ---
(In reply to Richard Biener from comment #2)
>
> but after vector lowering only vector operations that are handled by the
> target may be introduced. The pattern
>
We can't tell that we're after veclow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106063
--- Comment #4 from Tamar Christina ---
Ah, there's optimize_vectors_before_lowering_p,
would you prefer I check the operation or just gate the pattern on the above
Richi?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106106
Bug ID: 106106
Summary: SRA scalarizes structure copies
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106106
--- Comment #2 from Tamar Christina ---
(In reply to Richard Biener from comment #1)
> SRA is eliding 'v' by doing what it does, so it essentially changes
> it looks like providing __builtin_neon_vld2_lanev2sf with float32x2x2
> argument and ret
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106106
--- Comment #4 from Tamar Christina ---
>
> Is the fact that float32x2x2_t is an aggregate with a field named 'val'
> part of the neon API?
Yeah, it's mandated by ACLE
https://arm-software.github.io/acle/main/acle.html#vector-array-data-types-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106137
Bug ID: 106137
Summary: baremetal cross builds broken in libgfortran since
g:133d0d422ebd18dbd215cfa5394aff9f938e7060
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106137
--- Comment #3 from Tamar Christina ---
(In reply to Jakub Jelinek from comment #1)
> Could you please attach
> */libgfortran/Makefile
> */libgfortran/config.h
> from the build dir before/after that commit?
Waiting for a build to finish to grab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106137
--- Comment #4 from Tamar Christina ---
(In reply to Jakub Jelinek from comment #2)
> Created attachment 53224 [details]
> gcc13-pr106137.patch
>
> Perhaps this patch could fix this?
The patch does fix the build! I also have the 4 files you as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106196
Bug ID: 106196
Summary: [13 Regression] vect_do_peeling ICE since
g:3769ad4ccea9589b3f7edaef901cb542aa10f49a
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Key
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106217
Bug ID: 106217
Summary: [11/12/13 Regression] sinking of loads prevents
vectorization
Product: gcc
Version: 11.3.1
Status: UNCONFIRMED
Keywords: missed-optimiz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106196
Tamar Christina changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106196
--- Comment #6 from Tamar Christina ---
(In reply to Richard Biener from comment #5)
> (In reply to Tamar Christina from comment #4)
> > Some benchmarks are still failing with the same error, just different line
> > I am reducing a testcase now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106196
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106253
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106253
--- Comment #10 from Tamar Christina ---
For completeness, I reduced the Armhf failure and that seems to happen on
bswap.
#include
#include
void
__sha256_process_block (uint32_t *buffer, size_t len, uint32_t *W)
{
for (unsigned int t = 0; t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101326
Bug ID: 101326
Summary: std::optional returns forced through stack
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101326
--- Comment #1 from Tamar Christina ---
last example for x86 should have been
foo():# @foo()
xor eax, eax
mov dl, 1
ret
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101363
Tamar Christina changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101363
--- Comment #3 from Tamar Christina ---
Bootstrap turns on -Werror so the warning generated in
gcc/config/aarch64/aarch64.c at aarch64_simd_lane_bounds for the use of `%K`
becomes fatal.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101363
--- Comment #6 from Tamar Christina ---
yeah, the ICEs don't make sense to me either, let me see if I can debug one of
them.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101372
Bug ID: 101372
Summary: [12 Regression] Bootstrap failure compiling
gcc/cp/module.cc
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101372
--- Comment #2 from Tamar Christina ---
yes revering r12-2132 does indeed fix it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101457
Tamar Christina changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101457
Tamar Christina changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92538
Tamar Christina changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101553
Bug ID: 101553
Summary: [12 Regression] armhf builds broken on
-Werror=array-bounds
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: build
Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101553
Tamar Christina changed:
What|Removed |Added
Target Milestone|--- |12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101553
--- Comment #2 from Tamar Christina ---
Thanks, I didn't see the patch, I've pinged the maintainers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101750
--- Comment #2 from Tamar Christina ---
(In reply to Richard Biener from comment #1)
> On x86_64 the testcase is optimized to the following now:
> not sure how we conclude that 'n' is not written to anywhere. The issue
> persists even when I re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101750
--- Comment #4 from Tamar Christina ---
(In reply to rguent...@suse.de from comment #3)
> On Tue, 3 Aug 2021, tnfchris at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101750
> >
> > --- Comment #2 from Tamar Christ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101750
--- Comment #5 from Tamar Christina ---
And yes the same semantics apply to 'i', but if I read it right the patch in
r12-2523 is tracking variables that are read but never written to. So 'i'
escaped the same issue because it's written to somewh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101750
--- Comment #7 from Tamar Christina ---
(In reply to rguent...@suse.de from comment #6)
> On Wed, 4 Aug 2021, tnfchris at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101750
> >
> > --- Comment #5 from Tamar Christ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101750
Tamar Christina changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101842
Bug ID: 101842
Summary: Vectorizer doesn't vectorize when loop bound depends
on two independent variables that are unknown
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101842
--- Comment #3 from Tamar Christina ---
(In reply to Richard Biener from comment #2)
> OK, so with a hack like the following we vectorize the BB as
>
> vect__1.10_62 = MEM [(float *)p_34];
> vect_powmult_9.11_61 = vect__1.10_62 * vect__1.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101842
--- Comment #5 from Tamar Christina ---
(In reply to Richard Biener from comment #4)
> (In reply to Tamar Christina from comment #3)
> > (In reply to Richard Biener from comment #2)
> > > OK, so with a hack like the following we vectorize the BB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91598
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95967
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91598
--- Comment #13 from Tamar Christina ---
(In reply to Maxim Kuvyrkov from comment #12)
> (In reply to Tamar Christina from comment #11)
> > Can this issue be closed? all inline assembly have been removed from
> > arm_neon.h but backporting these
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95964
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95962
Tamar Christina changed:
What|Removed |Added
Last reconfirmed||2021-08-12
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91753
Tamar Christina changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47562
Bug 47562 depends on bug 91753, which changed state.
Bug 91753 Summary: Bad register allocation of multi-register types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91753
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95958
Bug 95958 depends on bug 91753, which changed state.
Bug 91753 Summary: Bad register allocation of multi-register types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91753
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98877
Bug 98877 depends on bug 91753, which changed state.
Bug 91753 Summary: Bad register allocation of multi-register types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91753
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101197
Tamar Christina changed:
What|Removed |Added
Build|x86_64-linux-gnu|x86_64-linux-gnu,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101197
--- Comment #8 from Tamar Christina ---
(In reply to Jakub Jelinek from comment #6)
> Shouldn't that be a different PR with details? I mean, this PR is that we
> should expand shorter memmove inline even if the regions do overlap.
Sure, I'm st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101197
--- Comment #10 from Tamar Christina ---
(In reply to cqwrteur from comment #9)
> (In reply to Tamar Christina from comment #8)
> > (In reply to Jakub Jelinek from comment #6)
> > > Shouldn't that be a different PR with details? I mean, this PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101197
--- Comment #13 from Tamar Christina ---
(In reply to cqwrteur from comment #12)
> (In reply to cqwrteur from comment #11)
> > (In reply to Tamar Christina from comment #10)
> > > (In reply to cqwrteur from comment #9)
> > > > (In reply to Tamar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101197
--- Comment #18 from Tamar Christina ---
(In reply to Martin Liška from comment #17)
> Waiting for Tamara's test-case now.
> Btw. can you please share a pointer to the Github repsitory?
Sure, it's this project and this particular call
https://g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98877
Tamar Christina changed:
What|Removed |Added
Version|11.0|12.0
--- Comment #5 from Tamar Christi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113808
Tamar Christina changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot
gnu.org
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113808
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
--- Comment #15 from Tamar Christina ---
(In reply to Sam James from comment #14)
> Created attachment 57390 [details]
> test.c
>
> I'll try reducing it preprocessed now (couldn't do it before as checking w/
> clang as well in the reduction scr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
--- Comment #17 from Tamar Christina ---
(In reply to Sam James from comment #16)
> Created attachment 57393 [details]
> test.c
>
> OK, all done now (I figured I'd let cvise finish). No more :)
>
> By the way, this fails on arm64 too (at least
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
--- Comment #18 from Tamar Christina ---
Loop that gets miscompiled is the initialization loop:
while (parse_tables_n-- && i < 306)
table[i++] = 0;
and indeed, the compiler seems to also be ignori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
--- Comment #19 from Tamar Christina ---
Ok, removing all the noise shows that this is the same issue as I saw before.
The code out of the vectorizer is correct, but cunroll does a dodgee unrolling.
-fdisable-tree-cunroll confirms it's the unr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
--- Comment #20 from Tamar Christina ---
[local count: 21718864]:
...
_54 = (short unsigned int) bits_106;
_26 = _54 >> 9;
_88 = _139 + 7;
_89 = _88 & 7;
_111 = _26 + 10;
[local count: 181308616]:
# i_66 = PHI
# parse_table
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
--- Comment #22 from Tamar Christina ---
(In reply to Richard Biener from comment #21)
> loop->nb_iterations_upper_bound exactly is an upper bound on the number of
> latch executions, so maybe I'm missing the point here. When we update it it
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
--- Comment #23 from Tamar Christina ---
small standalone reducer:
#include
#include
#include
#define N 306
#define NEEDLE 136
__attribute__ ((noipa, noinline))
int use(int x[N])
{
printf("res=%d\n", x[NEEDLE]);
return x[NEEDLE];
}
__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
--- Comment #24 from Tamar Christina ---
The case I thought would go wrong with the above fix is:
#include
#include
#include
#define N 306
#define NEEDLE 135
__attribute__ ((noipa, noinline))
int use(int x[N])
{
printf("res=%d\n", x[NEED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
Tamar Christina changed:
What|Removed |Added
Component|middle-end |tree-optimization
Priority|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113903
Bug ID: 113903
Summary: sched1 should schedule across EBBS
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
Tamar Christina changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113903
--- Comment #2 from Tamar Christina ---
(In reply to Alexander Monakov from comment #1)
> Lifting those insns from the L8 BB to the L10 BB requires duplicating them
> on all incoming edges targeting L8, doesn't it?
>
No, because they're unused
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107071
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56
Tamar Christina changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112376
Tamar Christina changed:
What|Removed |Added
Last reconfirmed||2024-02-15
Summary|[14 Reg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56
--- Comment #14 from Tamar Christina ---
(In reply to Richard Biener from comment #13)
> I didn't add STMT_VINFO_SLP_VECT_ONLY, I'm quite sure we can now do both SLP
> of masked loads and stores, so yes, STMT_VINFO_SLP_VECT_ONLY (when we formed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56
--- Comment #15 from Tamar Christina ---
and just -O3 -march=armv8-a+sve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56
--- Comment #21 from Tamar Christina ---
(In reply to Richard Biener from comment #18)
> diff --git a/gcc/tree-vect-slp.cc b/gcc/tree-vect-slp.cc
> index 7cf9504398c..8deeecfd4aa 100644
> --- a/gcc/tree-vect-slp.cc
> +++ b/gcc/tree-vect-slp.cc
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113295
Tamar Christina changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113295
--- Comment #2 from Tamar Christina ---
bisected to
commit g:2f46e3578d45ff060a0a329cb39d4f52878f9d5a
Author: Richard Sandiford
Date: Thu Dec 14 13:46:16 2023 +
aarch64: Improve handling of accumulators in early-ra
Being very s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113295
--- Comment #3 from Tamar Christina ---
I'm however able to reproduce it at -Ofast alone, no need for `-flto`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113295
Tamar Christina changed:
What|Removed |Added
Keywords|needs-bisection |
Summary|[14 Regression] S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113441
Tamar Christina changed:
What|Removed |Added
Ever confirmed|0 |1
Summary|[14 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113257
--- Comment #5 from Tamar Christina ---
(In reply to Sam James from comment #3)
> (In reply to Richard Earnshaw from comment #2)
> I'm missing why the combination then works though?
So we've made several changes here over time.
-mcpu=native do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114061
Bug ID: 114061
Summary: GCC fails vectorization when using __builtin_prefetch
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114061
--- Comment #2 from Tamar Christina ---
(In reply to Andrew Pinski from comment #1)
> I thought there was already one recorded about this.
I could only find https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103938 about an
ICE when prefetching a vec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114061
--- Comment #4 from Tamar Christina ---
(In reply to Andrew Pinski from comment #3)
> Confirmed.
>
> Though maybe we should drop them in the vectorized version of the loop. HW
> prefetchers usually do a decent job and sometimes (maybe most) SW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114063
Bug ID: 114063
Summary: Use IFN_CHECK_RAW_PTRS/IFN_CHECK_WAR_PTRS for
Advanced. SIMD
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimizati
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114068
Tamar Christina changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114068
--- Comment #12 from Tamar Christina ---
looks like the moving of the store didn't update a stray out of block use of
the MEM.
working on patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114068
--- Comment #13 from Tamar Christina ---
Created attachment 57510
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57510&action=edit
candidate-patch1.patch
candidate patch being tested.
I was hoping to correct it during peeling itself when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114068
--- Comment #14 from Tamar Christina ---
patch submitted
https://gcc.gnu.org/pipermail/gcc-patches/2024-February/646415.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114081
Tamar Christina changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot
gnu.org
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114099
--- Comment #8 from Tamar Christina ---
Created attachment 57537
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57537&action=edit
uses.patch
new code seems sensitive to visitation order as get_virtual_phi returns NULL
for blocks which don
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113441
--- Comment #27 from Tamar Christina ---
Created attachment 57538
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57538&action=edit
proposed1.patch
proposed patch, this gets the gathers and scatters back. doing regression run.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86530
--- Comment #8 from Tamar Christina ---
(In reply to Andrew Pinski from comment #6)
> With my patch for V4QI, we still don't get the best code:
> vect_perm_even_271 = VEC_PERM_EXPR 4, 6 }>;
> vect_perm_even_273 = VEC_PERM_EXPR 4, 6 }>;
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113441
Tamar Christina changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
--- Comme
301 - 400 of 834 matches
Mail list logo
