||il/gcc-patches/2024-April/6
||48994.html
CC||linkw at gcc dot gnu.org
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot
|1
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
Last reconfirmed||2024-04-08
CC||linkw at gcc dot gnu.org
--- Comment #1 from Kewen Lin ---
It requires effective target
at gcc dot gnu.org |linkw at gcc dot gnu.org
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
#
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
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
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=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 #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=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
|ASSIGNED
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114402
Kewen Lin changed:
What|Removed |Added
Target||powerpc64*-linux-gnu
Keywords|
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
: 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=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
||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.
|--- |FIXED
CC||linkw at gcc dot gnu.org
--- Comment #4 from Kewen Lin ---
Already fixed by r12-2889-g8464894c86b03e.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113507
Kewen Lin changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at g
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
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 #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 #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=113652
Kewen Lin changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
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
--- 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|[14 regression] Failed |Failed bootstrap on ppc
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113652
--- Comment #7 from Kewen Lin ---
oops, I meant --enable-checking rather than --checking.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113652
--- Comment #6 from Kewen Lin ---
I think this is related to r10-580-ge154242724b084 and this failure is expected
and a use error.
With it applied, we don't always pass -many to assembler with CHECKING_P
enabled. Actually compilers (gcc-13, gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113507
Kewen Lin changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
,
||dje at gcc dot gnu.org,
||linkw at gcc dot gnu.org
--- Comment #2 from Kewen Lin ---
Guessing /usr/local/bin/ld is a gnu ld? Based on what I heard before, gnu ld
has some problems on aix, people pass object files to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109705
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
--- Comment #7
at gcc dot gnu.org |linkw at gcc dot gnu.org
CC||bergner at gcc dot gnu.org
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: linkw at gcc dot gnu.org
Target Milestone: ---
Inspired by PR109705, open this for tracking the revisit of vect_* checking for
Power and fix some if needed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112980
--- Comment #4 from Kewen Lin ---
(In reply to Naveen N Rao from comment #2)
> I don't really have a preference, though I tend to agree that nops before
> the local entry point aren't that useful. Even with the current approach,
> not all functi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111850
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99888
--- Comment #16 from Kewen Lin ---
(In reply to Michael Matz from comment #15)
> Umm. I just noticed this one as we now try to implement userspace live
> patching
> for ppc64le. The point of the "before" NOPs is (and always was) that they
> are
||2024-01-18
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
Ever confirmed|0 |1
See Also||https://gcc.gnu.org/bugzill
||a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113317
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113418
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 #4 from Kewen Lin ---
Just realized that we also escalated test issue to P1, I'm going to make a
patch for the test case update.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113341
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
--- Comment #9
gcc dot gnu.org |linkw at gcc dot gnu.org
--- Comment #3 from Kewen Lin ---
As discussed in PR113115, I'm going to give option power{8,9}-vector removal a
shot.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113115
--- Comment #7 from Kewen Lin ---
(In reply to Peter Bergner from comment #5)
> I really dislike the -mpower{8,9}-vector options, but maybe it's too late to
> remove them for this release? I'm not sure how involved/invasive that patch
> would b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113100
Kewen Lin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111480
Kewen Lin changed:
What|Removed |Added
Component|testsuite |target
Keywords|testsuite-fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112751
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112606
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113115
Kewen Lin changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109987
Kewen Lin changed:
What|Removed |Added
CC||fkastl at suse dot cz
--- Comment #2 from K
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
CC||linkw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112606
Kewen Lin changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
Last
||il/gcc-patches/2024-January
||/642091.html
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113100
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=60031
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106682
Kewen Lin changed:
What|Removed |Added
CC||seurer at gcc dot gnu.org
--- Comment #4 fr
||linkw at gcc dot gnu.org
Status|UNCONFIRMED |RESOLVED
--- Comment #4 from Kewen Lin ---
Dup.
*** This bug has been marked as a duplicate of bug 106682 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113100
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85099
Bug 85099 depends on bug 112995, which changed state.
Bug 112995 Summary: sel-sched2 ICE without checking verify_changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112995
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112995
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
Resolution|FIXED |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
--- Comment #43 from Kewen Lin ---
Created attachment 56899
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56899&action=edit
Previously reduced case for comment 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
--- Comment #42 from Kewen Lin ---
(In reply to Richard Biener from comment #41)
> What's the "other" testcase? Do we know that doesn't suffer from the same
> uninitialized issue?
For "other" test cases, I guessed he referred to my comment #c3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
--- Comment #38 from Kewen Lin ---
I found this has been marked as resolved but it seems that the patch in comment
#34 hasn't been pushed, is it intended? or did I miss something that one commit
was pushed but wasn't associated to this PR?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113029
Kewen Lin changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113029
--- Comment #2 from Kewen Lin ---
I noticed there are some existing PRs (PR107984, PR99328, PR88652, PR84842) on
verify_target_availability ICE, and in PR84842 there is a tentative patch, I
tried to make it fit with the latest trunk, but this st
: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: linkw at gcc dot gnu.org
Target Milestone: ---
Test case:
#include
#define c(d, g) g, d
#define e(d, g) g, d
vector double f, n;
int m;
int k;
void j (vector double, double, double);
vector double combine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112995
--- Comment #3 from Kewen Lin ---
(In reply to Andrew Pinski from comment #2)
> fselective-scheduling has so many issues.
ah, thanks a lot for pointing this out.
I was testing the impact of my proposed scheduling change and found this
feature
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112995
--- Comment #1 from Kewen Lin ---
Initially we have:
(insn 31 6 10 2 (set (reg/v:SI 9 9 [orig:119 c ] [119])
(reg/v:SI 64 0 [orig:119 c ] [119])) "test.i":5:5 555
{*movsi_internal1}
(expr_list:REG_DEAD (reg/v:SI 64 0 [orig:119 c ]
gnu.org,
||segher at gcc dot gnu.org
Target||powerpc64le-linux-gnu
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: linkw at gcc dot gnu.org
Target Milestone: ---
With selective scheduling 2 enabled by default, I failed to build gcc with
non-bootstrap on Power10, one reduced test case is listed below:
int a[];
int b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112993
Bug 112993 depends on bug 112788, which changed state.
Bug 112788 Summary: [14 regression] ICEs in fold_range, at range-op.cc:206
after r14-5972-gea19de921b01a6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112788
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112788
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
|1
Keywords|build, ice-checking,|internal-improvement
|ice-on-valid-code |
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
Status|UNCONFIRMED |ASSIGNED
, ice-on-valid-code
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112788
--- Comment #5 from Kewen Lin ---
One workaround patch was posted at
https://gcc.gnu.org/pipermail/gcc-patches/2023-December/639140.html.
We also found that with default long double format ieee128 the culprit commit
caused the libquadmath libra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112788
Kewen Lin changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
|1
CC||linkw at gcc dot gnu.org,
||meissner at gcc dot gnu.org,
||segher at gcc dot gnu.org
Last reconfirmed||2023-12-01
,
||bergner at gcc dot gnu.org,
||linkw at gcc dot gnu.org,
||segher at gcc dot gnu.org
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112725
--- Comment #4 from Kewen Lin ---
(In reply to Jakub Jelinek from comment #3)
> Agreed, so like this?
Yes, thanks for the prompt fix! The rs6000 part is OK for trunk!
> 2023-11-29 Jakub Jelinek
>
> PR target/112725
> * config/
||bergner at gcc dot gnu.org,
||g...@the-meissners.org,
||linkw at gcc dot gnu.org,
||segher at gcc dot gnu.org
Last reconfirmed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112751
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112707
--- Comment #10 from Kewen Lin ---
(In reply to HaoChen Gui from comment #9)
> (In reply to Segher Boessenkool from comment #8)
> > Yeah, it tested for ISA 2.04 before. That was an attempt at including 476
> > probably?
> >
> > We really shoul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111828
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
|NEW
Last reconfirmed||2023-11-07
CC||linkw at gcc dot gnu.org,
||rguenth at gcc dot gnu.org,
||rsandifo at gcc dot gnu.org
|ASSIGNED
Assignee|unassigned at gcc dot gnu.org |guojiufu at gcc dot
gnu.org
Ever confirmed|0 |1
CC||linkw at gcc dot gnu.org
--- Comment #1 from Kewen Lin ---
test issue, assigning to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
--- Comment #32 from Kewen Lin ---
> case pass, but the original test case (#c1) can't pass with this, it can't
> pass with -fstack-reuse=none + -fno-strict-aliasing + -O2 either, I think
> the original case still suffers another latent bug.
We
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111828
Kewen Lin changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111828
--- Comment #9 from Kewen Lin ---
Peter had a check on gnu assembler (Thanks!) and found that even with -mpower10
specified it's still able to assemble HTM insns, so it means that for some
callee with power8 attributed has HTM inline asm, it can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
--- Comment #31 from Kewen Lin ---
Thanks for the explanation from both of you!
(In reply to Richard Biener from comment #30)
> Created attachment 56175 [details]
> prototype patch
I confirmed that this fix can make test case (#c9 + #c10) and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111367
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111784
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
--- Comment #26 from Kewen Lin ---
(In reply to Richard Biener from comment #25)
> (In reply to Kewen Lin from comment #24)
> > (In reply to Richard Biener from comment #22)
> > > I see the mems properly get their base adjusted:
> > >
> > > (in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
--- Comment #24 from Kewen Lin ---
(In reply to Richard Biener from comment #22)
> I see the mems properly get their base adjusted:
>
> (insn 384 383 0 (set (mem/c:V2DI (plus:DI (reg/f:DI 112 virtual-stack-vars)
> (const_int 16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
--- Comment #21 from Kewen Lin ---
For optimized IR:
a$raw$3_220 = D.39813.rawD.30221[3];
vect_a_raw_4_70.539_1584 = MEM [(short intD.20
*)&D.39813 + 8B];
_1640 = a$raw$0_221 & 255;
_1649 = a$raw$1_74 & 255;
_1658 = a$raw$2_264 & 255
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111850
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101169
--- Comment #6 from Kewen Lin ---
PR111850 reminded me this bug, the sub-optimal issue described in #comment 4
has been fixed on latest trunk, I think it's r14-4664-g04c9cf5c786b94.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111828
Kewen Lin changed:
What|Removed |Added
Priority|P3 |P4
--- Comment #8 from Kewen Lin ---
(In r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111828
--- Comment #3 from Kewen Lin ---
(In reply to Peter Bergner from comment #1)
> (In reply to Kewen Lin from comment #0)
> > Technically speaking we are able to parse the inline asm string and figure
> > out it's HTM related or not. Excepting fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
--- Comment #20 from Kewen Lin ---
(In reply to Richard Biener from comment #19)
> So maybe it's the same issue as PR90348 (you can verify the RTL expansion
> dump on whether the two involved decls are coalesced and see whether that's
> valid).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111522
Kewen Lin changed:
What|Removed |Added
Resolution|--- |INVALID
CC|
101 - 200 of 956 matches
Mail list logo
