https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98138
--- Comment #19 from Kewen Lin ---
(In reply to rguent...@suse.de from comment #18)
> I think this misses a :s on the negate_expr_p, but I'm not sure this
> "works", so eventually && single_use (@1), given the original expression
> doesn't go awa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98138
--- Comment #17 from Kewen Lin ---
ccp1:
t0_83 = a0_79 + a1_80;
t1_84 = a0_79 - a1_80;
t2_85 = a2_81 + a3_82;
t3_86 = a2_81 - a3_82;
_63 = t0_83 + t2_85;
tmp[i_71][0] = _63;
_64 = t0_83 - t2_85;
tmp[i_71][2] = _64;
_65 = t1_84
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98138
--- Comment #15 from Kewen Lin ---
It looks r15-2820-gab18785840d7b8 has made the case in #c1 vectorized, nice!
But CPUBench has unsigned type in HADAMARD4:
#if BIT_DEPTH > 8
typedef uint32_t sum_t;
typedef uint64_t sum2_t;
#else
ty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108184
Kewen Lin changed:
What|Removed |Added
Assignee|linkw at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115427
Kewen Lin changed:
What|Removed |Added
Resolution|--- |INVALID
Assignee|linkw at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117721
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
--- Comment #4 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116266
--- Comment #5 from Kewen Lin ---
Created attachment 59656
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59656&action=edit
WIP-patch for P8_VECTOR
I had a WIP patch for P8 VECTOR rework, it needs some more changes on bif and
rs6000_vecto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116266
Kewen Lin changed:
What|Removed |Added
Assignee|linkw at gcc dot gnu.org |unassigned at gcc dot
gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114567
Kewen Lin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103515
Kewen Lin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112980
Kewen Lin changed:
What|Removed |Added
URL|https://gcc.gnu.org/piperma |https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116461
--- Comment #3 from Kewen Lin ---
(In reply to Andrew Pinski from comment #2)
> The easiest fix is todo:
> ```
> for (int i = 0; i < N; ++i)
> {
> a[i] = BASE1 + i * 5;
> b[i] = BASE2 - i * 4;
> /* b[i] cannot be 0 as tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116462
Kewen Lin changed:
What|Removed |Added
Target Milestone|--- |15.0
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116461
Kewen Lin changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116415
--- Comment #8 from Kewen Lin ---
Some more information: bisection showed it started to fail from
r12-4240-g2b8453c401b699 which enabled vectorization at -O2. But by further
checking, I confirmed that commit just exposed this latent issue, if we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116030
Kewen Lin changed:
What|Removed |Added
Summary|ICE "could not split insn" |[15 regression] ICE "could
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112993
Bug 112993 depends on bug 116170, which changed state.
Bug 116170 Summary: [15 regression] ICE unrecognizable insn since
r15-2084-g33dca0a4c1c421
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116170
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116170
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116170
--- Comment #6 from Kewen Lin ---
(In reply to Segher Boessenkool from comment #4)
> Is that strong enough? A const_vector (or a const_anything) as lhs of a set
> does not make sense at all. How did we even try this, is some more generic
> thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116148
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114842
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116266
Kewen Lin changed:
What|Removed |Added
Target Milestone|--- |15.0
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116266
Bug ID: 116266
Summary: rs6000: P10 vector insn ICE with -mno-vsx
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116148
--- Comment #11 from Kewen Lin ---
Well, I guess the hppa issue isn't due to endianness any more, but the
signedness of char. 0x8f as signed char would be promoted to ff8f, which is
unexpected.
Could you help to verify it can pass with -fun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116148
--- Comment #10 from Kewen Lin ---
(In reply to John David Anglin from comment #9)
> These two are reversed:
> Breakpoint 2 at 0x105a8: file
> /home/dave/gnu/gcc/gcc/gcc/testsuite/c-c++-common/fam-in-union-alone-in-
> struct-2.c, line 49.
> (gdb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105359
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116170
Kewen Lin changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116170
--- Comment #2 from Kewen Lin ---
Reduced test case:
$ cat test.i
int a, d;
_Float128 b, c;
void e() {
int f = 0;
if (a)
if (b || c)
f = 1;
if (d)
e(f ? 0 : b);
}
Options: -w -fstack-protector-strong -ffloat-store -O2 -mcpu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116170
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116148
Kewen Lin changed:
What|Removed |Added
Status|NEW |ASSIGNED
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116148
Kewen Lin changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115713
Kewen Lin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108977
Kewen Lin changed:
What|Removed |Added
Target Milestone|11.5|12.3
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96373
--- Comment #27 from Kewen Lin ---
(In reply to Richard Earnshaw from comment #25)
> (In reply to Kewen Lin from comment #24)
>
> > OK, thanks for the comments, I'll mark PR108977 as won't fix then.
> It would be more normal to mark it as fixed,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115962
Kewen Lin changed:
What|Removed |Added
Severity|normal |enhancement
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115962
Bug ID: 115962
Summary: rs6000: Rework precision for 128bit float types and
modes
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: internal-improvement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112993
Kewen Lin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96373
--- Comment #24 from Kewen Lin ---
(In reply to Richard Biener from comment #23)
> (In reply to Kewen Lin from comment #22)
> > As PR108977 requires these fixes are backported to GCC11, I'm curious that
> > do we plan to backport the fixes to GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96373
--- Comment #22 from Kewen Lin ---
As PR108977 requires these fixes are backported to GCC11, I'm curious that do
we plan to backport the fixes to GCC11 as well?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114189
Bug 114189 depends on bug 115659, which changed state.
Bug 115659 Summary: powerpc fallout from removing vcond{,u,eq} patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115659
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115659
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115688
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110040
--- Comment #4 from Kewen Lin ---
(In reply to Peter Bergner from comment #3)
> Kewen and Segher, is this something we want backported or just call it good
> and close as FIXED? I ask since the patch just adds a simple splitter which
> doesn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115713
--- Comment #6 from Kewen Lin ---
(In reply to Richard Biener from comment #5)
> The docs are at least imprecise. Surely command-line -maltivec with
> target ("no-vsx") shouldn't revert to whatever is default with the target
> opts.
Thanks for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115713
Kewen Lin changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115466
Kewen Lin changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115355
Kewen Lin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106069
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Assignee|unassigned at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115739
Kewen Lin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115739
--- Comment #4 from Kewen Lin ---
(In reply to Eric Botcazou from comment #3)
> The fix is OK for mainline, thanks!
Thanks Eric! btw, a formal patch was sent at
https://gcc.gnu.org/pipermail/gcc-patches/2024-July/656136.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115739
Kewen Lin changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115739
Kewen Lin changed:
What|Removed |Added
Last reconfirmed||2024-07-02
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115713
--- Comment #3 from Kewen Lin ---
(In reply to Peter Bergner from comment #2)
> (In reply to Kewen Lin from comment #0)
> > As Peter found in the PR115688, there isn't a warning for:
> >
> > long __attribute__ ((target ("no-altivec,vsx")))
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115659
--- Comment #10 from Kewen Lin ---
(In reply to Richard Biener from comment #9)
> I think the inversion code wants to check invert_tree_comparison and see if
> the inverted compare is supported and only if not fall back to inverting the
> compar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115688
--- Comment #8 from Kewen Lin ---
> > -mabi={no-,}altivec is only for the 32-bit ABIs. All the 64-bit ABIs had
> > either only compatible changes to support VMX, or only ever had support for
> > it in the first place.
> In that case, -mabi=no-a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115714
Kewen Lin changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115714
Bug ID: 115714
Summary: rs6000: Refine option -mabi={no-}altivec handlings
with some related option
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115713
--- Comment #1 from Kewen Lin ---
There IS a warning for:
long __attribute__ ((target ("vsx,no-altivec")))
foo1 (void)
{
return 0;
}
, interesting. :)
It's due to that we enable altivec when parsing vsx in target attribute, but
don't consid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115688
Kewen Lin changed:
What|Removed |Added
CC||meissner at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115713
Kewen Lin changed:
What|Removed |Added
Last reconfirmed||2024-06-30
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115713
Bug ID: 115713
Summary: rs6000: Miss warning for incompatible no-altivec and
vsx in target attribute
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115688
--- Comment #2 from Kewen Lin ---
The assertion does expose an inconsistent combination !TARGET_ALTIVEC but
TARGET_VSX wiht 32-bit target attribute -mvsx. There is one special handling
for altivec_abi:
/* Disable VSX and Altivec silently if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115688
Kewen Lin changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115659
--- Comment #8 from Kewen Lin ---
Inspired by Andrew's comments, it looks we can have:
c = x CMP y
r = c ? 0 : z => r = ~c & z (1)
r = c ? z : 0 => r = c & z (2)
r = c ? -1 : z => r = c | z (3)
r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115659
--- Comment #7 from Kewen Lin ---
> > > (simplify
> > > (vec_cond @0 @1 integer_all_ones_p)
> > > (bit_ior (view_convert @0) @1))
> > > ```
> >
> > Missing negate for the vector one?
>
> No because vector true is already -1 :).
I could be w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115659
--- Comment #5 from Kewen Lin ---
(In reply to Andrew Pinski from comment #2)
> Note I think this could help scalar code too:
> ```
> int a[1], b[1], c[1];
>
> void
> test (void)
> {
> a[0] = (b[0] == c[0]) ? -1 : a[0];
> }
>
> void
> test1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115659
--- Comment #4 from Kewen Lin ---
(In reply to Richard Biener from comment #3)
>c = x CMP y
>r = c ? -1 : z => r = c ? c : z
>r = c ? z : 0 => r = c ? z : c
>
> this is probably best left for ISEL. I agree the transforms elim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115659
--- Comment #1 from Kewen Lin ---
Now isel has some handling on x CMP y ? -1 : 0 to x CMP y,
/* Try to fold x CMP y ? -1 : 0 to x CMP y. */
if (can_compute_op0
&& integer_minus_onep (op1)
&& int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115659
Kewen Lin changed:
What|Removed |Added
Blocks||114189
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115659
Bug ID: 115659
Summary: powerpc fallout from removing vcond{,u,eq} patterns
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115612
--- Comment #1 from Kewen Lin ---
Thanks for filing this!
For the given example, previously split1 splits ordered test into unordered
test + xor, late-combine pass recombines them into ordered test then split2
fails to create a pseduo after RA.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114846
Kewen Lin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114846
--- Comment #17 from Kewen Lin ---
(In reply to Peter Bergner from comment #11)
> Have we done the backports so we can just mark this bug a FIXED? ...or do
> we still need to push the backports?
(In reply to Segher Boessenkool from comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115466
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
--- Comment #2 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115262
--- Comment #3 from Kewen Lin ---
(In reply to Peter Bergner from comment #2)
> (In reply to Jeffrey A. Law from comment #1)
> > It looks like the test wants to see xxsel, but after that change we get
> > xxlor and what looks like a slight diff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115427
--- Comment #5 from Kewen Lin ---
(In reply to rguent...@suse.de from comment #4)
> On Tue, 11 Jun 2024, linkw at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115427
> >
> > --- Comment #3 from Kewen Lin ---
> > (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115427
--- Comment #3 from Kewen Lin ---
(In reply to Richard Biener from comment #2)
> The canonical way would be to handle these in the ISEL pass and remove
> the (fallback) expansion. But then we can see whether the expander FAILs
> (ideally expand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115427
Kewen Lin changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
K
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115427
Bug ID: 115427
Summary: fallback for interclass mathfn bifs like isinf,
isfinite, isnormal
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115355
--- Comment #11 from Kewen Lin ---
(In reply to Jens Seifert from comment #10)
> Does this affect loop vectorize and slp vectorize ?
>
> -fno-tree-loop-vectorize avoids loop vectorization to be performed and
> workarounds this issue. Does the s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115355
--- Comment #9 from Kewen Lin ---
(In reply to Peter Bergner from comment #7)
> The test fails when setToIdentityBAD's index var is unsigned int. It passes
> when using unsigned long long, unsigned long, unsigned short and unsigned
> char. Whe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115355
--- Comment #8 from Kewen Lin ---
(In reply to Peter Bergner from comment #5)
> FYI, fails for me with gcc 12 and later and works with gcc 11. It also
> fails with -O3 -mcpu=power10.
Thanks for the information, bisection shows r12-4496 is the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115355
Kewen Lin changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115282
Kewen Lin changed:
What|Removed |Added
Last reconfirmed||2024-05-31
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114846
--- Comment #10 from Kewen Lin ---
(In reply to Peter Bergner from comment #9)
> (In reply to Kewen Lin from comment #8)
> > Should be fixed on trunk, it's not a regression, but we probably want
> > backporting this?
>
> For code correctness bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114846
--- Comment #8 from Kewen Lin ---
Should be fixed on trunk, it's not a regression, but we probably want
backporting this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112980
Kewen Lin changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114402
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114846
Kewen Lin changed:
What|Removed |Added
Attachment #58067|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114846
--- Comment #5 from Kewen Lin ---
Created attachment 58067
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58067&action=edit
untested patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113535
--- Comment #1 from Kewen Lin ---
One issue: https://gcc.gnu.org/pipermail/gcc-patches/2024-April/650171.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114846
Kewen Lin changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44793
Kewen Lin changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114846
--- Comment #2 from Kewen Lin ---
As https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114843#c8, we may need some
similar handling like r14-6440-g4b421728289e6f.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114846
Kewen Lin changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114842
--- Comment #1 from Kewen Lin ---
We can extend powerpc_vsx to consider current_compiler_flags, it means that if
a test case has an explicit -mvsx, even if users specify -mno-vsx it's still
able to be tested if powerpc_vsx checking concludes VSX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114842
Kewen Lin changed:
What|Removed |Added
Target||powerpc*-linux-gnu
Assignee|unass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114842
Bug ID: 114842
Summary: rs6000: Adjust some test cases with powerpc_vsx_ok
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88309
Kewen Lin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105359
Kewen Lin changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
1 - 100 of 806 matches
Mail list logo
