https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113652
Kewen Lin changed:
What|Removed |Added
Summary|[14 regression] Failed |Failed bootstrap on ppc
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113652
--- Comment #11 from Kewen Lin ---
In gcc, lfiwzx is guarded with TARGET_LFIWZX => TARGET_POPCNTD (ISA2.06), while
-mvsx will guarantee TARGET_POPCNTD (ISA_2_6_MASKS_SERVER) set, so it considers
lfiwzx is supported. IMHO the underlying philosoph
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113652
Kewen Lin changed:
What|Removed |Added
Summary|Failed bootstrap on ppc |[14 regression] Failed
|u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113652
Kewen Lin changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106680
--- Comment #7 from Kewen Lin ---
(In reply to Sebastian Huber from comment #6)
> It seems that the change
>
> commit acc727cf02a1446dc00f8772f3f479fa3a508f8e
> Author: Kewen Lin
> Date: Tue Dec 27 04:13:07 2022 -0600
>
> rs6000: Rework
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106680
--- Comment #9 from Kewen Lin ---
Note that now we only disable implicit powerpc64 for -m32 when the
OS_MISSING_POWERPC64 is set.
/* Don't expect powerpc64 enabled on those OSes with OS_MISSING_POWERPC64,
since they do not save and resto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106680
--- Comment #11 from Kewen Lin ---
(In reply to Sebastian Huber from comment #8)
> Yes, it seems that -mcpu=e6500 -mno-powerpc64 yields the right code for the
> attached test case (with or without the -m32).
The default is -m32 I guess? :)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106680
--- Comment #12 from Kewen Lin ---
(In reply to Sebastian Huber from comment #10)
> (In reply to Kewen Lin from comment #9)
> > Note that now we only disable implicit powerpc64 for -m32 when the
> > OS_MISSING_POWERPC64 is set.
> >
> > /* Don
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: linkw at gcc dot gnu.org
Target Milestone: ---
This is filed as follow up for the discussion in [1].
The optabs for isfinite and isnormal would be landed soon, the
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
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
--- 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
> >
> > --- C
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=115466
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
--- Comment #2
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=114846
Kewen Lin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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.
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: linkw at gcc dot gnu.org
Target Milestone: ---
Applying the patch dropping vcond{,u,eq}_optab support
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114189#c2), there is only one
failure on both BE and LE:
FAIL
at gcc dot gnu.org |linkw at gcc dot gnu.org
Ever confirmed|0 |1
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114189
[Bug 114189] Target implements obsolete vcond{,u,eq} expanders
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
--- 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 #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 #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 #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=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=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
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: linkw at gcc dot gnu.org
Target Milestone: ---
As Peter found in the PR115688, there isn't a warning for:
long __attribute__ ((target ("no-altivec,vsx&quo
||powerpc*
Status|UNCONFIRMED |ASSIGNED
Target Milestone|--- |15.0
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
CC||bergner at gcc dot gnu.org
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
--- 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
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: linkw at gcc dot gnu.org
Target Milestone: ---
As Peter found in [1], even with altivec flag explicitly unset, we can still
have altivec_abi set, it's unexpected.
A
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
Ever confirmed|0 |1
Target Milestone|--- |15.0
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=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=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")))
> >
|--- |15.0
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
Status|UNCONFIRMED |ASSIGNED
--- Comment #1 from Kewen Lin ---
Thanks for reporting! I'll take a look at this.
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
--- 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
Status|ASSIGNED|RESOLVED
Resolution|---
dot gnu.org |linkw at gcc dot gnu.org
Status|NEW |RESOLVED
--- Comment #52 from Kewen Lin ---
Should be fixed on trunk and affected release branches now.
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=115466
Kewen Lin changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
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=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=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=115688
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
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=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=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=112993
Kewen Lin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
-improvement
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: linkw at gcc dot gnu.org
CC: amacleod at redhat dot com, andy at gwentswordclub dot
co.uk,
bergner at gcc dot
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=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=108977
Kewen Lin changed:
What|Removed |Added
Target Milestone|11.5|12.3
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115713
Kewen Lin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
|il/gcc-patches/2024-May/651 |il/gcc-patches/2024-Novembe
|025.html|r/668608.html
Assignee|linkw at gcc dot gnu.org |matz at gcc dot gnu.org
--- Comment #22 from Kewen Lin ---
(In reply to Giuliano Belinassi from comment #20)
>
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=115427
Kewen Lin changed:
What|Removed |Added
Resolution|--- |INVALID
Assignee|linkw at gcc
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=116266
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=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=117721
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
--- Comment #4
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=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=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
901 - 967 of 967 matches
Mail list logo
