https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109636
Tamar Christina changed:
What|Removed |Added
Assignee|ktkachov at gcc dot gnu.org|tnfchris at gcc dot
gnu.org
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113364
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=113364
--- Comment #9 from Tamar Christina ---
vect_create_epilog_for_reduction needs to handle the case where the vectorizer
has picked a different exit than the main one.
diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
index eccf0953bba..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113425
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113425
--- Comment #4 from Tamar Christina ---
(In reply to Christophe Lyon from comment #3)
> What I meant by arm-* is that we see the same issue on several of the
> configurations we test, as can be seen on
> https://linaro.atlassian.net/browse/GNU-1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113539
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113539
Tamar Christina changed:
What|Removed |Added
Priority|P3 |P1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113441
--- Comment #6 from Tamar Christina ---
Hello,
I can bisect it if you want. it should only take a few seconds.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112600
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113441
--- Comment #9 from Tamar Christina ---
So on SVE the change is cost modelling.
Bisect landed on g:33c2b70dbabc02788caabcbc66b7baeafeb95bcf which changed the
compiler's defaults to using the new throughput matched cost modelling used be
newer c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113552
Bug ID: 113552
Summary: [11/12/13/14 Regression] vectorizer generates calls to
vector math routines with 1 simd lane.
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113552
Tamar Christina changed:
What|Removed |Added
Target Milestone|--- |14.0
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113364
--- Comment #13 from Tamar Christina ---
Yes I had to rerun my baseline after updating trunk. Will post patch once peak
finishes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113364
--- Comment #14 from Tamar Christina ---
Yes I had to rerun my baseline after updating trunk. Will post patch once peak
finishes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113552
--- Comment #3 from Tamar Christina ---
(In reply to Richard Biener from comment #1)
> Hum, the vectorizer looks at the simd specs and if it says 1-lane variants
> (simdlen == 1) are available it will happily create them.
>
My understanding is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113552
--- Comment #4 from Tamar Christina ---
(In reply to nsz from comment #2)
> is this fortran only?
>
No it should be C as well, I was just reducing from a Fortran workload that
failed so I can see what the vectorizer was doing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113552
Tamar Christina changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #5 from Tamar Christi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113441
--- Comment #16 from Tamar Christina ---
(In reply to rguent...@suse.de from comment #13)
> > > You could check if we call this with sane values.
> >
> > Do you mean it's RISC-V backend cost model issue ?
>
> I responded to Tamar which means a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113552
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=113441
--- Comment #17 from Tamar Christina ---
Ok, bisected to
g:2efe3a7de0107618397264017fb045f237764cc7 is the first bad commit
commit 2efe3a7de0107618397264017fb045f237764cc7
Author: Hao Liu
Date: Wed Dec 6 14:52:19 2023 +0800
tree-optimiz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113441
--- Comment #22 from Tamar Christina ---
for me with `-fno-vect-cost-model` on without this commit we generate
https://gist.github.com/Mistuke/d9252bfcb2aa766327c5f377e162f5b7 for the loop
and with the commit well.. it doesn't fit on the screen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113441
--- Comment #23 from Tamar Christina ---
tamar:~/gcc-dsg/test$ extract-toolchain gcc 2efe3a7de01
A 1514 files
D 0 files
M 0 files
Extracted 'origin/manygcc-basepoints-gcc-14-6292-g2f512f6fcdd:2efe3a7de01'
> ./bin/gcc -S -o ../
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113441
--- Comment #25 from Tamar Christina ---
> > void record_nonwrapping_chrec (tree chrec)
> > {
> > - CHREC_NOWRAP(chrec) = 1;
> > + CHREC_NOWRAP(chrec) = 0;
> >
> >if (dump_file && (dump_flags & TDF_SCEV))
> > {
>
> Hmmm. With exp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113364
--- Comment #15 from Tamar Christina ---
Ok, the fix fixes the ICE but after rebasing to trunk I get a misscompile
during bootstrap which miscompiles the x86 backend.
This is likely related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113539
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113364
--- Comment #16 from Tamar Christina ---
Ok, I've submitted the patch since the ICE and miscompare are unrelated.
I'll keep this ticket open in any case. The miscompares didn't happen based on
commits from ~2 weeks ago, So this will give me a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
--- Comment #18 from Tamar Christina ---
(In reply to Richard Biener from comment #7)
> I do wonder whether LOOP_VINFO_EARLY_BREAKS_VECT_PEELED actually works (since
> without early exits we cannot handle a non-empty latch because of correctness
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
--- Comment #20 from Tamar Christina ---
(In reply to rguent...@suse.de from comment #19)
> > Am 23.01.2024 um 18:06 schrieb tnfchris at gcc dot gnu.org
> > :
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
> >
> > --- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113561
Tamar Christina changed:
What|Removed |Added
Resolution|--- |DUPLICATE
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113364
Tamar Christina changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113555
Tamar Christina changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113364
--- Comment #19 from Tamar Christina ---
*** Bug 113555 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113364
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109636
Tamar Christina changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113588
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=113588
--- Comment #4 from Tamar Christina ---
The change Richi made this morning to only allow may_be_zero for the last exit
makes it not rotate this loop anymore.
However the bug is simply that if the final exit has a memory access it should
be che
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
--- Comment #17 from Tamar Christina ---
Well the mid-end has generated the right precision. The type it generates is
vector(4) vexit_reduc_67;
so it does say it's a single bit boolean.
Isn't this just an expand problem?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
--- Comment #25 from Tamar Christina ---
So I think probably what's miscompiled is this loop
for (s=string; *s; s +=2 )
I think we currently incorrectly vectorize that. i.e. I think it's the same as
PR113588. I'm finishing testing for that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113661
Tamar Christina changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112644
Tamar Christina changed:
What|Removed |Added
CC||acoplan at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113661
--- Comment #2 from Tamar Christina ---
*** This bug has been marked as a duplicate of bug 113576 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
Tamar Christina changed:
What|Removed |Added
CC||acoplan at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113588
Tamar Christina changed:
What|Removed |Added
CC||acoplan at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113661
--- Comment #3 from Tamar Christina ---
arg wrong one again. anyway, this is a duplicate
*** This bug has been marked as a duplicate of bug 113588 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
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=113576
--- Comment #24 from Tamar Christina ---
Just to avoid confusion, are you still working on this one Richi?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
--- Comment #26 from Tamar Christina ---
Ah great, just checking it wasn't left unattended :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113659
--- Comment #2 from Tamar Christina ---
looks like get_virtual_phi returned NULL. but this loop shouldn't have
vectorized. The submitted fix for PR113588 "fixes" it too by not allowing it
to be vectorized.
Such loops need to be handled differ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112644
Tamar Christina changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113502
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113682
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51492
--- Comment #12 from Tamar Christina ---
(In reply to JuzheZhong from comment #11)
> Hi, Tamar.
>
> We are interested in supporting saturating and rounding.
Awesome!
>
> We may need to support scalar first.
>
> Do you have any suggestions ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51492
--- Comment #14 from Tamar Christina ---
Awesome! Feel free to reach out if you need any help.
It’s likely easier to start with add and sub and get things pipe cleaned and
expand incrementally than to try and do it all at once.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113731
Tamar Christina changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
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=113750
Tamar Christina changed:
What|Removed |Added
Assignee|gaius at gcc dot gnu.org |tnfchris at gcc dot
gnu.org
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
--- Comment #4 from Tamar Christina ---
Narrowed down the change part that caused the failure, but it should have been
correct to do. So looking into why the change caused the failure. Please
hold..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113771
Tamar Christina changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113731
Tamar Christina changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113539
Tamar Christina changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
--- Comment #6 from Tamar Christina ---
The reason for the miscompile popping up is this change from the previous patch
diff --git a/gcc/tree-vect-data-refs.cc b/gcc/tree-vect-data-refs.cc
index 109d4ce5192..df3eab2e8d5 100644
--- a/gcc/tree-ve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51492
--- Comment #17 from Tamar Christina ---
(In reply to Li Pan from comment #16)
> I have a try like below and finally have the Standard Name "SAT_ADD". Could
> you please help to double-check if my understanding is correct?
>
> Given below exampl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113731
--- Comment #9 from Tamar Christina ---
(In reply to Matthias Klose from comment #8)
> the proposed patch doesn't fix the amdgcn-amdhsa bootstrap.
So what is the error with the patch? The output can't be the same as the
function was removed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
--- Comment #10 from Tamar Christina ---
(In reply to Richard Biener from comment #9)
> Another bug in the dependence checking code is
>
> if (dr_may_alias_p (dr_ref, dr_read, loop_nest))
>
> which will end up using TBAA - dr_m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113731
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113750
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113808
--- Comment #2 from Tamar Christina ---
I guess whether that code is correct depends on which exit was picked though.
I'll look at dump too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115464
Tamar Christina changed:
What|Removed |Added
Last reconfirmed||2024-06-12
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115464
Tamar Christina changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115464
--- Comment #6 from Tamar Christina ---
(In reply to Richard Sandiford from comment #5)
> In this kind of situation, we should go through a fresh pseudo rather than
> try to take the subreg directly.
I did try that but fwprop pushed it back in.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115464
--- Comment #7 from Tamar Christina ---
(In reply to Tamar Christina from comment #6)
> (In reply to Richard Sandiford from comment #5)
> > In this kind of situation, we should go through a fresh pseudo rather than
> > try to take the subreg dir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115464
--- Comment #10 from Tamar Christina ---
Thanks for the fix, but I don't think it's sufficient.
what I meant with the earlier comment was that the subregs are broken in
general, so not just the one generated by the undef fast path.
i.e.
#incl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115531
Bug ID: 115531
Summary: vectorizer generates inefficient code for masked
conditional update loops
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: miss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115531
--- Comment #3 from Tamar Christina ---
(In reply to Andrew Pinski from comment #1)
> I suspect PR 20999 would fix this ...
> but we have to be careful since without masked stores, you could still
> vectorize this unlike the transformed version.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115534
Bug ID: 115534
Summary: intermediate stack use not eliminated
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115537
Bug ID: 115537
Summary: [15 Regression] vectorizable_reduction ICEs after
g:d66b820f392aa9a7c34d3cddaf3d7c73bf23f82d
Product: gcc
Version: 15.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115534
--- Comment #2 from Tamar Christina ---
(In reply to Andrew Pinski from comment #1)
> I suspect there is a dup of this already. See the bug which I made this one
> blocking for a list of related bugs.
Most of the other bugs relate to the argume
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115537
--- Comment #5 from Tamar Christina ---
Thanks for the fix!
I think the testcase needs SVE enabled to ICE no?
shouldn't that be -mcpu=neoverse-v1 and not -mcpu=neoverse-n1?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115534
--- Comment #5 from Tamar Christina ---
(In reply to Andrew Pinski from comment #4)
> This might be improved by
> https://gcc.gnu.org/pipermail/gcc-patches/2024-June/654819.html . Or it
> might be the case the vectorizer case needs to be improve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115597
Bug ID: 115597
Summary: [15 Regression] vectorizer takes 20+ h compiling
510.parest in SPECCPU2017 since
g:46bb4ce4d30ab749d40f6f4cef6f1fb7c7813452
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115597
--- Comment #3 from Tamar Christina ---
>
> Can you check whether that fixes the issue?
>
> diff --git a/gcc/tree-vect-slp.cc b/gcc/tree-vect-slp.cc
> index 9465d94de1a..212d5f97f7d 100644
> --- a/gcc/tree-vect-slp.cc
> +++ b/gcc/tree-vect-slp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115597
--- Comment #4 from Tamar Christina ---
(In reply to Richard Biener from comment #2)
> Ah, I feared this would happen - this case seems to be because of a lot of
> VEC_PERM nodes(?) which are not handled by the CSE process as well as the
> two-o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115120
--- Comment #4 from Tamar Christina ---
You asked why this doesn't happen with a normal vector loop Richi.
For a normal loop when IVcannon adds the downward counting loop there are two
main differences.
1. for a single exit loop, the downward
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115623
Tamar Christina changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115623
--- Comment #4 from Tamar Christina ---
novect3.c: In function 'void f(char*, int)':
novect3.c:4:9: error: missing loop condition in loop with 'GCC novector' pragma
before ';' token
4 | for (;;i++)
|
should do it, will send
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115531
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=115629
Bug ID: 115629
Summary: Inefficient if-convert of masked conditionals
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115120
--- Comment #5 from Tamar Christina ---
considering ivopts bails out on doloop prediction for multiple exits anyway,
what do you think about:
diff --git a/gcc/tree-ssa-loop-ivcanon.cc b/gcc/tree-ssa-loop-ivcanon.cc
index 5ef24a91917..d1b25ad7de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88545
--- Comment #11 from Tamar Christina ---
(In reply to Jonathan Wakely from comment #9)
> Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2024-June/653731.html
>
> Rerunning benchmarks with this patch would be very welcome.
OK, I have te
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115629
--- Comment #4 from Tamar Christina ---
(In reply to Richard Biener from comment #3)
> So we now tail-merge the two b[i] loading blocks. Can you check SVE
> code-gen with this? If that fixes the PR consider adding a SVE testcase.
Thanks, the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88545
--- Comment #12 from Tamar Christina ---
I had a bug in the benchmark, I forgot to set taskset,
These are the correct ones:
++---+-+-+
| NEEDLE | scalar 1x | vect| memchr |
++---+-+--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115629
--- Comment #6 from Tamar Christina ---
(In reply to rguent...@suse.de from comment #5)
> > In this case, the second load is conditional on the first load mask, which
> > means it's already done an AND.
> > And crucially inverting it means you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115623
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90608
--- Comment #19 from Tamar Christina ---
Hi Mikael,
It looks like the last version of your patch already gets inlined in the call
sites we cared about.
Would it be possible for you to upstream it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104265
--- Comment #4 from Tamar Christina ---
(In reply to Richard Biener from comment #3)
> Note the SLP discovery opportunity is from the "reduction" PHI to the
> return which merges control flow to a zero/one flag.
Right, so I get what you mean he
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104265
--- Comment #5 from Tamar Christina ---
Also for fully masked architectures we can instead of recreating the vectors
just mask out the irrelevant values.
But we should still order the exits based on complexity.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115799
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115866
Bug ID: 115866
Summary: missed optimization vectorizing switch statements.
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115866
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=115934
--- Comment #1 from Tamar Christina ---
Hi, thanks for the report, could you tell me a target triple I can use for
nvptx?
701 - 800 of 834 matches
Mail list logo
