: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: linkw at gcc dot gnu.org
CC: jan.wassenberg at gmail dot com, john_platts at hotmail dot
com,
linkw at gcc dot gnu.org, malat at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111366
Kewen Lin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111380
Kewen Lin changed:
What|Removed |Added
Keywords||wrong-code
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
--- Comment #18 from Kewen Lin ---
(In reply to Richard Biener from comment #17)
> it stores to a different object - but seeing the CLOBBERs, does
> -fstack-reuse=none fix the issue? Is r1 the stack pointer?
Just tried with -fstack-reuse=none,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
--- Comment #16 from Kewen Lin ---
Tracing down it with template specialization, the aborting happens on
auto vn_b = Load(dn, in_b.get());
HWY_ASSERT_VEC_EQ(
dw, vw_signed_max,
SatWidenMulPairwiseAdd(
dw, InterleaveLow
:
|ldp_stp_{15,16,17,18}.c |ldp_stp_{15,16,17,18}.c
|test failures |test failures since
||r14-4579
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108396
--- Comment #10 from Kewen Lin ---
(In reply to Carl Love from comment #9)
> I made a copy of rs6000-overload.def and then with a series of emacs macros
> converted the list of builtins to a script to grep for the builtins in the
> test director
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111427
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
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=111591
Kewen Lin changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #13 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
--- Comment #8 from Kewen Lin ---
(In reply to Richard Biener from comment #7)
> I suppose it works with -fno-tree-vectorize ontop of the flags?
Appending -fno-tree-vectorize at the end of the given flags in #c1
(-mstrict-align version), it sti
,
||linkw at gcc dot gnu.org,
||segher at gcc dot gnu.org
Last reconfirmed||2023-09-26
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
-code |testsuite-fail
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
CC||linkw at gcc dot gnu.org
Ever confirmed|0 |1
Status|UNCONFIRMED |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111367
--- Comment #13 from Kewen Lin ---
(In reply to Michael Meissner from comment #12)
> Basically I did not consider the case. IIRC, you only need the stack
> protect DI mode case if the stack is large enough (more than 32K). I don't
> think 32-b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111367
--- Comment #10 from Kewen Lin ---
Thanks for both of your comments!
(In reply to Peter Bergner from comment #8)
> Mike will know better than I, but I like the idea of the patch!
Looking forward to Mike's reply. :)
(In reply to Segher Boessen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111367
Kewen Lin changed:
What|Removed |Added
Keywords||wrong-code
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111367
--- Comment #6 from Kewen Lin ---
Created attachment 55919
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55919&action=edit
tested patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111367
Kewen Lin changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #5 from Kewen Lin ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111366
--- Comment #17 from Kewen Lin ---
(In reply to Mathieu Malaterre from comment #16)
> Interesting, the following works for me:
>
> % /usr/bin/c++ -O1 -mcpu=power8 -mno-htm -flto=auto -c skeleton_test.cc
Yeah, the suggestion on an extra option
gnu.org |linkw at gcc dot gnu.org
CC||linkw at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Last reconfirmed||2023-09-12
--- Comment #4 from Kewen Lin ---
Confirmed, I'll have a look first.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104024
--- Comment #7 from Kewen Lin ---
*** Bug 111371 has been marked as a duplicate of this bug. ***
|RESOLVED
CC||linkw at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
--- Comment #1 from Kewen Lin ---
It's a dup of PR104024.
*** This bug has been marked as a duplicate of bug 104024 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111366
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=111366
Kewen Lin changed:
What|Removed |Added
Status|REOPENED|NEW
--- Comment #13 from Kewen Lin ---
I'd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111366
Kewen Lin changed:
What|Removed |Added
Ever confirmed|0 |1
Resolution|INVALID
gcc dot gnu.org |linkw at gcc dot gnu.org
Ever confirmed|0 |1
Last reconfirmed||2023-09-12
Target||powerpc*-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111366
--- Comment #10 from Kewen Lin ---
(In reply to Jan Wassenberg from comment #5)
> Thanks for reporting this. One might think this is caused by -mcpu=power9
> clashing with our #pragma target altivec,vsx,power8-vector.
>
> However, what makes th
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: linkw at gcc dot gnu.org
Target Milestone: ---
We have the different behaviors for the case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111366#c8 with and without -flto,
it's unexpected. Previously there are
|RESOLVED
CC||linkw at gcc dot gnu.org
--- Comment #9 from Kewen Lin ---
It looks to me that the error message is expected, because the source code
forces the function as always_inline, users would like it to be inlined always,
it&#
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108812
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111228
--- Comment #2 from Kewen Lin ---
(In reply to Peter Bergner from comment #1)
> Confirmed. The testsuite log shows for vsx-extract-6.c and vsx-extract-7.c:
>
> gcc.target/powerpc/vsx-extract-6.c: \\mxxpermdi\\M found 2 times
> FAIL: gcc.target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111212
--- Comment #4 from Kewen Lin ---
btw, I think the field "known to work" isn't quite exact, at least I verified
it failed with powerpc64 gcc 12.3.0 with -m32, as which release PR96762 was
filed for, I'd expect it also fail for gcc 11.4.0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111212
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96762
Kewen Lin changed:
What|Removed |Added
CC||malat at debian dot org
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110740
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111021
Kewen Lin changed:
What|Removed |Added
Summary|[14 Regression] Serial |[14 Regression] Serial
|b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111021
--- Comment #14 from Kewen Lin ---
(In reply to Kewen Lin from comment #13)
> (In reply to Richard Biener from comment #12)
> > I think a "too broad" dependence isn't bad. The cris specific solution also
> > looks manageable, though I wonder wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111021
--- Comment #13 from Kewen Lin ---
(In reply to Richard Biener from comment #12)
> I think a "too broad" dependence isn't bad. The cris specific solution also
> looks manageable, though I wonder what's special about x-protos.h, knowing
> very l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111021
--- Comment #10 from Kewen Lin ---
(In reply to Hans-Peter Nilsson from comment #7)
> Exactly; I'm happy that we seem to be on the same page here.
>
> I'm testing a patch for CRIS (making the hook function just a wrapper,
> reverting the cris-p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111021
Kewen Lin changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org,
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
--- Comment #2 from Kewen Lin ---
Thanks for reporting, I think the culprit is r14-3093 instead of r14-3092?
I think the other build/gen*.cc building don't have this issue, since none of
them includes recog.h thems
dot gnu.org |linkw at gcc dot gnu.org
Status|UNCONFIRMED |RESOLVED
--- Comment #11 from Kewen Lin ---
Should be fixed on trunk, thanks all!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110741
Kewen Lin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110795
Kewen Lin changed:
What|Removed |Added
Resolution|--- |INVALID
Status|ASSIGNED
gcc dot gnu.org |linkw at gcc dot gnu.org
Last reconfirmed||2023-07-27
Ever confirmed|0 |1
--- Comment #3 from Kewen Lin ---
I'll have a look first.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110776
Kewen Lin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110776
--- Comment #9 from Kewen Lin ---
(In reply to Iain Sandoe from comment #8)
> (In reply to rguent...@suse.de from comment #7)
> > On Tue, 25 Jul 2023, linkw at gcc dot gnu.org wrote:
> >
> > > https://gcc.gnu.org/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110776
--- Comment #6 from Kewen Lin ---
(In reply to rguent...@suse.de from comment #5)
> On Tue, 25 Jul 2023, linkw at gcc dot gnu.org wrote:
>
> I think apart from the consideration what a single element vector
> is compared to a scala
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110776
Kewen Lin changed:
What|Removed |Added
Target|powerpc-darwin |powerpc-darwin,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110776
Kewen Lin changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #3 f
gcc dot gnu.org |linkw at gcc dot gnu.org
Ever confirmed|0 |1
Last reconfirmed||2023-07-24
--- Comment #2 from Kewen Lin ---
Thanks for reporting and sorry for the breakage. I'll have a look first.
(In reply to Iain Sandoe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110741
Kewen Lin changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org,
gcc dot gnu.org |linkw at gcc dot gnu.org
CC||linkw at gcc dot gnu.org
Ever confirmed|0 |1
Last reconfirmed||2023-07-21
--- Comment #1 from Kewen Lin ---
Confirmed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99889
Kewen Lin changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #5 from Kewe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110729
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110744
Kewen Lin changed:
What|Removed |Added
Component|other |tree-optimization
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110740
Kewen Lin changed:
What|Removed |Added
Attachment #55587|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110740
--- Comment #3 from Kewen Lin ---
Created attachment 55587
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55587&action=edit
trial-patch
This patch can fix the exposed failures on
gcc.target/powerpc/p9-vec-length-epil-{1,8}.c, fully testin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110740
Kewen Lin changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org,
||linkw at gcc dot gnu.org
Last reconfirmed||2023-07-20
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Kewen Lin ---
I'll have a look first,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110744
--- Comment #6 from Kewen Lin ---
The root cause is that the length and bias handling about LEN_STORE in sccvn
was missed to be updated, the below diff can fix the failure.
diff --git a/gcc/tree-ssa-sccvn.cc b/gcc/tree-ssa-sccvn.cc
index 11061a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110744
--- Comment #5 from Kewen Lin ---
(In reply to Li Pan from comment #2)
> Hi there,
>
> Just try to reproduce this bug with powerPC cross compiler (sorry we don't
> have a real powerPC) with the below options. Unfortunately, I failed to
> reprod
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110744
Kewen Lin changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110652
Kewen Lin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109880
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109971
Kewen Lin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110652
Kewen Lin changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #5 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110652
--- Comment #4 from Kewen Lin ---
I can't reproduce this on ppc64le with both the default bootstrapping checking
option --enable-checking=yes,extra and the reported --enable-checking=release.
I'm going to test it on cfarm x86 machine.
If the er
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110652
Kewen Lin changed:
What|Removed |Added
Last reconfirmed||2023-07-14
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 82255, which changed state.
Bug 82255 Summary: Vectorizer cost model overcounts cost of some vectorized
loads
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82255
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82255
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110531
--- Comment #11 from Kewen Lin ---
(In reply to Hao Liu from comment #10)
> > foo is just an example for not getting inlined, the point here is extra
> > cost paid.
>
> My point is that the case is different from the original case in
> tree-ve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110531
--- Comment #8 from Kewen Lin ---
(In reply to Hao Liu from comment #7)
> > int foo() {
> > bool a = true;
> > bool b;
> > if (a || b)
> > return 1;
> > b = true;
> > return 0;
> > }
> >
> > still has the warning, it looks somethi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110531
--- Comment #6 from Kewen Lin ---
It's an arguable topic, I can't find the thread that previously some reviewers
told me it's not always good to initialize the local variable. IIRC, the case
is that I initialized one variable at the top, but the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110531
--- Comment #3 from Kewen Lin ---
(In reply to Hao Liu from comment #2)
> > Is the warning from some static analyzer?
>
> No. I just find it maybe a bug while looking at the code.
>
> > slp should be true always (always do analyze slp), it doe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110531
Kewen Lin changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #1 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 109858, which changed state.
Bug 109858 Summary: [14 Regression] r14-172 caused some SPEC2017 bmk to degrade
on Power
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109858
What|Removed |A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109858
Kewen Lin changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109932
Kewen Lin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104024
--- Comment #6 from Kewen Lin ---
(In reply to Martin Jambor from comment #5)
> I have just seen a similar ICE with a ppc64le cross-compiler. Running
>
> ~/cross/bin/ppc64le-linux-gnu-gcc
> /home/worker/buildworker/tiber-option-juggler/build/g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110248
--- Comment #7 from Kewen Lin ---
(In reply to Richard Biener from comment #6)
> (In reply to rsand...@gcc.gnu.org from comment #5)
> > ivopts does have code to treat ifn pointer arguments specially,
> > see get_mem_type_for_internal_fn &co. Bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110248
--- Comment #2 from Kewen Lin ---
Can you extend the current hook legitimate_address_p with one default value
nullptr gimple* argument? When middle-end passes like ivopts want to query with
the constructed address reference, it can pass the gimp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110248
Kewen Lin changed:
What|Removed |Added
Keywords||missed-optimization
CC|
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: linkw at gcc dot gnu.org
Target Milestone: ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110230
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110230
Kewen Lin changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110089
Kewen Lin changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comment #7 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108699
Kewen Lin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101169
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109971
--- Comment #10 from Kewen Lin ---
(In reply to JuzheZhong from comment #9)
> (In reply to Kewen Lin from comment #8)
> > I did SPEC2017 int/fp evaluation on Power10 at Ofast and an extra explicit
> > --param=vect-partial-vector-usage=2 (the def
|linkw at gcc dot gnu.org |juzhe.zhong at rivai
dot ai
--- Comment #8 from Kewen Lin ---
I did SPEC2017 int/fp evaluation on Power10 at Ofast and an extra explicit
--param=vect-partial-vector-usage=2 (the default is 1 on Power), baseline
r14-1241 vs. new r14-1242, the results showed that it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110011
--- Comment #6 from Kewen Lin ---
btw, one simple fix is under testing:
diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
index 3f129ea37d2..330c6a6fa5f 100644
--- a/gcc/config/rs6000/rs6000.cc
+++ b/gcc/config/rs6000/rs600
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110011
--- Comment #5 from Kewen Lin ---
(In reply to Vincent Lefèvre from comment #4)
> (In reply to Kewen Lin from comment #3)
> > Thanks for reporting, this exposes one issue that: when encoding KFmode
> > constant into toc, it uses the format for t
,
||g...@the-meissners.org,
||linkw at gcc dot gnu.org,
||segher at gcc dot gnu.org
Status|NEW |ASSIGNED
Assignee|unassigned at
|1
Keywords||ice-on-valid-code
CC||bergner at gcc dot gnu.org,
||linkw at gcc dot gnu.org,
||segher at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109971
Kewen Lin changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109971
Kewen Lin changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
|ASSIGNED
Ever confirmed|0 |1
CC||linkw at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
Keywords||ice-on-invalid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109610
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
--- Comment #12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109858
--- Comment #9 from Kewen Lin ---
(In reply to Kewen Lin from comment #6)
> (In reply to Hongtao.liu from comment #5)
> > (In reply to Kewen Lin from comment #3)
> > > (In reply to Hongtao.liu from comment #2)
> > > > Does https://gcc.gnu.org/pi
201 - 300 of 956 matches
Mail list logo
