https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114642
Kewen Lin changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114614
Kewen Lin changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114567
Kewen Lin changed:
What|Removed |Added
Target Milestone|--- |15.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114567
Bug ID: 114567
Summary: rs6000: explicit _Float128 doesn't generate optimal
code
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88309
Kewen Lin changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gc
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 from
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114402
Kewen Lin changed:
What|Removed |Added
CC||bergner 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114402
Bug ID: 114402
Summary: rs6000: ICE when long double is ieee128 format by
default but without vsx
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: norm
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114320
Kewen Lin changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101461
Kewen Lin changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113507
Kewen Lin changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org,
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 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113535
Kewen Lin changed:
What|Removed |Added
Last reconfirmed||2024-01-22
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113535
Bug ID: 113535
Summary: rs6000, testsuite: Re-visit the current vect_* for
Power
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Prio
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112980
Kewen Lin changed:
What|Removed |Added
CC||matz at gcc dot gnu.org
Last reconfirmed|
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 fro
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 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111850
Kewen Lin changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at g
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 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109987
Kewen Lin changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at g
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111480
Kewen Lin changed:
What|Removed |Added
Last reconfirmed||2024-01-08
Ever confirmed|0
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 reco
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112751
Kewen Lin changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
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 from
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101444
Kewen Lin changed:
What|Removed |Added
Resolution|--- |DUPLICATE
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113100
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
Status
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113029
Bug ID: 113029
Summary: sel-sched2 ICE in verify_target_availability
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl
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 ]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112995
Kewen Lin changed:
What|Removed |Added
Known to fail||11.4.0
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112995
Bug ID: 112995
Summary: sel-sched2 ICE without checking verify_changes
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: r
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112993
Kewen Lin changed:
What|Removed |Added
Last reconfirmed||2023-12-13
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112993
Bug ID: 112993
Summary: rs6000: Rework precision for 128bit float types and
modes
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: build, ice-checking,
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112788
Kewen Lin changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112778
Kewen Lin changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org,
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/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112725
Kewen Lin changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112751
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
Last reconfirmed
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112411
Kewen Lin changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112340
Kewen Lin changed:
What|Removed |Added
Last reconfirmed||2023-11-07
Status|UNCONFIRMED
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 fro
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 795 matches
Mail list logo