https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105940
--- Comment #6 from Kewen Lin ---
(In reply to Kewen Lin from comment #4)
> (In reply to Richard Biener from comment #2)
> > (In reply to Kewen Lin from comment #1)
> > > Created attachment 53126 [details]
> > > move_applying
> >
> > LGTM (mayb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105940
Kewen Lin changed:
What|Removed |Added
Attachment #53126|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105940
--- Comment #8 from Kewen Lin ---
(In reply to Kewen Lin from comment #6)
> (In reply to Kewen Lin from comment #4)
> > (In reply to Richard Biener from comment #2)
> > > (In reply to Kewen Lin from comment #1)
> > > > Created attachment 53126 [
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105940
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106091
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106091
--- Comment #3 from Kewen Lin ---
Created attachment 53268
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53268&action=edit
tested patch
at gcc dot gnu.org |linkw at gcc dot gnu.org
Ever confirmed|0 |1
CC||linkw at gcc dot gnu.org
Status|UNCONFIRMED |ASSIGNED
--- Comment #1 from Kewen Lin ---
Thanks for reporting!
For
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106345
--- Comment #2 from Kewen Lin ---
Two more failures related to required tuning setting:
PASS->FAIL: gcc.target/powerpc/compress-float-ppc.c scan-assembler lfs
PASS->FAIL: gcc.target/powerpc/compress-float-ppc-pic.c scan-assembler lfs
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: linkw at gcc dot gnu.org
Target Milestone: ---
In regression testing for the patch to add unroll factor suggestion to
vectorizer for port rs6000, one failure got exposed on Power10 (with partial
vector in length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100328
--- Comment #8 from Kewen Lin ---
(In reply to rsand...@gcc.gnu.org from comment #7)
> (In reply to Kewen Lin from comment #6)
> > Created attachment 51066 [details]
> > aarch64 XPASS failure list
> >
> > The patch v3 bootstrapped and regressio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101291
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101291
--- Comment #2 from Kewen Lin ---
(In reply to Kewen Lin from comment #1)
> Hi Jeff, what's the option and stanza?
The reason why I asked is that I can't simply reproduce it locally at O2, with
C compiler it likely runs forever. I guess what y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100328
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
|--- |FIXED
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
CC||linkw at gcc dot gnu.org
--- Comment #4 from Kewen Lin ---
Should be fixed on trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 100696, which changed state.
Bug 100696 Summary: mult_higpart is not vectorized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100696
What|Removed |Added
--
: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: linkw at gcc dot gnu.org
Target Milestone: ---
I happened to spot this when I was working to add one new pattern for Power10
divide extended. Now
at gcc dot gnu.org |linkw at gcc dot gnu.org
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
--- Comment #1 from Kewen Lin ---
I have a untested patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101596
--- Comment #2 from Kewen Lin ---
Created attachment 51200
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51200&action=edit
Untested patch
Still need test cases to be added.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101596
--- Comment #3 from Kewen Lin ---
Formal patch has been posted at
https://gcc.gnu.org/pipermail/gcc-patches/2021-July/576071.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101596
Kewen Lin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: linkw at gcc dot gnu.org
Target Milestone: ---
For SPEC2017 bmk 508.namd_r, it's observed that it degraded by -3.73%
at -O2 -ftree-slp-vectorize vs baseline -O2 on Power9 with either default cost
model or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101944
--- Comment #1 from Kewen Lin ---
The original costing shows the vectorized version wins, by checking
the costings, it missed to model the cost of lane extraction, the
patch was posted in:
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/57
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101944
--- Comment #2 from Kewen Lin ---
Back to the optimized IR, I thought the problem is that the vectorized
version has longer critical path for the reduc_plus result (latency in total).
For vectorized version,
_51 = diffa_41(D) *
1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101944
--- Comment #5 from Kewen Lin ---
(In reply to Richard Biener from comment #3)
> On x86 we even have
>
> Vector cost: 136
> Scalar cost: 196
>
> note that we seem to vectorize the reduction but that only happens with
> -ffast-math, not -O2
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: linkw at gcc dot gnu.org
Target Milestone: ---
This is a test case reduced from SPEC2017 bmk 541.leela_r source FastBoard.cpp,
when I was investigating the O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102054
Kewen Lin changed:
What|Removed |Added
CC||crazylht at gmail dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102062
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102059
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=102059
--- Comment #9 from Kewen Lin ---
One more reduced test case:
fail cmd: gcc -c -O2 -flto -mcpu=power8
pass cmd: gcc -c -O2 -flto -mcpu=power8 -mno-htm -mno-power8-fusion
--
__attribute__((always_inline)) int foo(int *b) {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102059
--- Comment #13 from Kewen Lin ---
(In reply to Richard Biener from comment #10)
> OPTION_MASK_P8_FUSION is purely optimization and shouldn't prevent inlining,
> no?
>
> As of HTM it would make the testcase a user error - when using -mcpu=power
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102059
--- Comment #14 from Kewen Lin ---
(In reply to Richard Biener from comment #11)
> Note that x86 uses for example
>
> else if (caller_opts->x_ix86_fpmath != callee_opts->x_ix86_fpmath
>/* If the calle doesn't use FP expressions di
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102059
--- Comment #15 from Kewen Lin ---
(In reply to Florian Weimer from comment #12)
> (In reply to Richard Biener from comment #10)
> > As of HTM it would make the testcase a user error - when using -mcpu=power10
> > it would require building with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102059
--- Comment #17 from Kewen Lin ---
Created attachment 51357
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51357&action=edit
Fix some issues in rs6000_can_inline_p
As Martin pointed out, currently function rs6000_can_inline_p just returns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102059
--- Comment #18 from Kewen Lin ---
(In reply to Martin Liška from comment #16)
> >
> > Thanks for the example, it looks useful! Now the field fp_expressions is
> > generic, one target specific summary class seems required then. And not sure
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113507
Kewen Lin changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at g
|--- |FIXED
CC||linkw at gcc dot gnu.org
--- Comment #4 from Kewen Lin ---
Already fixed by r12-2889-g8464894c86b03e.
||2024-03-13
Ever confirmed|0 |1
CC||linkw at gcc dot gnu.org
--- Comment #1 from Kewen Lin ---
These new test cases require "-Wno-psabi" to suppress the warning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114320
--- Comment #3 from Kewen Lin ---
(In reply to Nathaniel Shead from comment #2)
> Sorry about that. I've not been able to work out what configure flags I need
> to pass to cause this to error in the first place (I don't normally develop
> for po
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: linkw at gcc dot gnu.org
Target Milestone: ---
When I was doing a patch to make us only have two 128bit fp on rs6000, I found
that we can have long double with ieee128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112980
--- Comment #6 from Kewen Lin ---
(In reply to Martin Jambor from comment #5)
> I'd like to ping this, are there plans to implement this in the near-ish
> term?
Some weeks ago, Naveen had been doing some experiments to see if there is a
better
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114402
Kewen Lin changed:
What|Removed |Added
Target||powerpc64*-linux-gnu
Keywords|
|ASSIGNED
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114402
--- Comment #1 from Kewen Lin ---
Currently the only pattern to match IEEE128 comparison is:
;; IEEE 128-bit comparisons
(define_insn "*cmp_hw"
[(set (match_operand:CCFP 0 "cc_reg_operand" "=y")
(compare:CCFP (match_operand:IEEE128 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112980
--- Comment #8 from Kewen Lin ---
Hi @Michael, @Martin, could you help to confirm/clarify what triggers you to be
interested in this feature, is it for some user space usage or not?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112980
--- Comment #10 from Kewen Lin ---
Created attachment 57844
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57844&action=edit
patch changing the current implementation
Considering the current implementation is not useful at all for both ke
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112980
--- Comment #11 from Kewen Lin ---
(In reply to Giuliano Belinassi from comment #9)
> Yes, this is for userspace livepatching.
>
> Assume the following example:
> https://godbolt.org/z/b9M8nMbo1
>
> As one can see, the sequence of 14 nops are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88309
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
--- Comment #4
gcc dot gnu.org |linkw at gcc dot gnu.org
--- Comment #6 from Kewen Lin ---
(In reply to Andrew Pinski from comment #5)
> (In reply to Kewen Lin from comment #4)
> > Hi Andrew, thanks for digging into this! William has not worked on GCC
> > project any more, will you make a
ormal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: linkw at gcc dot gnu.org
Target Milestone: ---
This is an issue which I happened to spot when I have been working on patches
for PR112993.
=== test case ===
#define TYPE _Float128
#
at gcc dot gnu.org |linkw at gcc dot gnu.org
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=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
--- 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
||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=110740
Kewen Lin changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org,
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
Attachment #55587|0 |1
is obsolete|
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=110729
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
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
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=110741
Kewen Lin changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org,
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=110776
Kewen Lin changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #3 f
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
--- 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
--- 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
Kewen Lin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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=110795
Kewen Lin changed:
What|Removed |Added
Resolution|--- |INVALID
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110741
Kewen Lin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
dot gnu.org |linkw at gcc dot gnu.org
Status|UNCONFIRMED |RESOLVED
--- Comment #11 from Kewen Lin ---
Should be fixed on trunk, thanks all!
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111021
Kewen Lin changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org,
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
--- 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 #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
Kewen Lin changed:
What|Removed |Added
Summary|[14 Regression] Serial |[14 Regression] Serial
|b
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=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=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=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=108812
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
--- Comment #4
|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&#
: 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
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
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
Kewen Lin changed:
What|Removed |Added
Ever confirmed|0 |1
Resolution|INVALID
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
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
|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=104024
--- Comment #7 from Kewen Lin ---
*** Bug 111371 has been marked as a duplicate of this bug. ***
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=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
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=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
Keywords||wrong-code
CC|
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
--- 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
601 - 700 of 967 matches
Mail list logo
