https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116461
--- Comment #3 from Kewen Lin ---
(In reply to Andrew Pinski from comment #2)
> The easiest fix is todo:
> ```
> for (int i = 0; i < N; ++i)
> {
> a[i] = BASE1 + i * 5;
> b[i] = BASE2 - i * 4;
> /* b[i] cannot be 0 as tha
|1
Assignee|unassigned at gcc dot gnu.org |bernd.edlinger at
hotmail dot de
Last reconfirmed||2024-08-23
CC||linkw at gcc dot gnu.org
Status|UNCONFIRMED |ASSIGNED
|ASSIGNED
CC||linkw at gcc dot gnu.org
Last reconfirmed||2024-08-23
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
--- Comment #1 from Kewen Lin ---
Confirmed, this is a test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116415
--- Comment #8 from Kewen Lin ---
Some more information: bisection showed it started to fail from
r12-4240-g2b8453c401b699 which enabled vectorization at -O2. But by further
checking, I confirmed that commit just exposed this latent issue, if we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116030
Kewen Lin changed:
What|Removed |Added
Summary|ICE "could not split insn" |[15 regression] ICE "could
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112993
Bug 112993 depends on bug 116170, which changed state.
Bug 116170 Summary: [15 regression] ICE unrecognizable insn since
r15-2084-g33dca0a4c1c421
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116170
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116170
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116170
--- Comment #6 from Kewen Lin ---
(In reply to Segher Boessenkool from comment #4)
> Is that strong enough? A const_vector (or a const_anything) as lhs of a set
> does not make sense at all. How did we even try this, is some more generic
> thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116148
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114842
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
||powerpc*
Status|UNCONFIRMED |ASSIGNED
Keywords||ice-on-valid-code
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
Last reconfirmed||2024-08-07
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: linkw at gcc dot gnu.org
Target Milestone: ---
I happened to notice that our Power10 vector instructions are only guarded with
TARGET_POWER10, some ICE is like:
#include "altivec.h"
vector unsigned char
foo (vecto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116148
--- Comment #11 from Kewen Lin ---
Well, I guess the hppa issue isn't due to endianness any more, but the
signedness of char. 0x8f as signed char would be promoted to ff8f, which is
unexpected.
Could you help to verify it can pass with -fun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116148
--- Comment #10 from Kewen Lin ---
(In reply to John David Anglin from comment #9)
> These two are reversed:
> Breakpoint 2 at 0x105a8: file
> /home/dave/gnu/gcc/gcc/gcc/testsuite/c-c++-common/fam-in-union-alone-in-
> struct-2.c, line 49.
> (gdb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105359
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116170
Kewen Lin changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116170
--- Comment #2 from Kewen Lin ---
Reduced test case:
$ cat test.i
int a, d;
_Float128 b, c;
void e() {
int f = 0;
if (a)
if (b || c)
f = 1;
if (d)
e(f ? 0 : b);
}
Options: -w -fstack-protector-strong -ffloat-store -O2 -mcpu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116170
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
||https://gcc.gnu.org/piperma
||il/gcc-patches/2024-July/65
||8826.html
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
||linkw at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Last reconfirmed||2024-07-31
--- Comment #3 from Kewen Lin ---
(In reply to Andrew Pinski from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > This testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115713
Kewen Lin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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=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=115962
Kewen Lin changed:
What|Removed |Added
Severity|normal |enhancement
CC|
-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=112993
Kewen Lin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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=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=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=115688
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
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=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=115713
Kewen Lin changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
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=115355
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=115739
Kewen Lin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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
CC||ebotcazou at gcc dot gnu.org
--- Comment #2
|--- |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=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")))
> >
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=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
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
Ever confirmed|0 |1
Target Milestone|--- |15.0
: 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
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
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
||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
: 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
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
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=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=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 #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 #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 #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
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
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
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.
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=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=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=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=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=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
Kewen Lin changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
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=115355
--- Comment #11 from Kewen Lin ---
(In reply to Jens Seifert from comment #10)
> Does this affect loop vectorize and slp vectorize ?
>
> -fno-tree-loop-vectorize avoids loop vectorization to be performed and
> workarounds this issue. Does the s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115355
--- Comment #9 from Kewen Lin ---
(In reply to Peter Bergner from comment #7)
> The test fails when setToIdentityBAD's index var is unsigned int. It passes
> when using unsigned long long, unsigned long, unsigned short and unsigned
> char. Whe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115355
--- Comment #8 from Kewen Lin ---
(In reply to Peter Bergner from comment #5)
> FYI, fails for me with gcc 12 and later and works with gcc 11. It also
> fails with -O3 -mcpu=power10.
Thanks for the information, bisection shows r12-4496 is the
|1
Last reconfirmed||2024-06-05
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
--- Comment #4 from Kewen Lin ---
Thanks for reporting, I'll have a look first.
|NEW
CC||linkw at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Kewen Lin ---
(In reply to Richard Biener from comment #1)
> I don't see a good reason why, but I don't have a BE cr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114846
--- Comment #10 from Kewen Lin ---
(In reply to Peter Bergner from comment #9)
> (In reply to Kewen Lin from comment #8)
> > Should be fixed on trunk, it's not a regression, but we probably want
> > backporting this?
>
> For code correctness bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114846
--- Comment #8 from Kewen Lin ---
Should be fixed on trunk, it's not a regression, but we probably want
backporting this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112980
Kewen Lin changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114402
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114846
Kewen Lin changed:
What|Removed |Added
Attachment #58067|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114846
--- Comment #5 from Kewen Lin ---
Created attachment 58067
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58067&action=edit
untested patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113535
--- Comment #1 from Kewen Lin ---
One issue: https://gcc.gnu.org/pipermail/gcc-patches/2024-April/650171.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114846
Kewen Lin changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
|--- |WORKSFORME
CC||linkw at gcc dot gnu.org
--- Comment #26 from Kewen Lin ---
libgcc/config.host on gcc-11 has:
powerpc-*-rtems*)
tmake_file="${tmake_file} rs6000/t-ppccomm rs6000/t-savresfgpr
rs6000/t-crtstuff t-crtstuff-p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114846
--- Comment #2 from Kewen Lin ---
As https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114843#c8, we may need some
similar handling like r14-6440-g4b421728289e6f.
||2024-04-25
Status|UNCONFIRMED |NEW
CC||bergner at gcc dot gnu.org,
||linkw at gcc dot gnu.org,
||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114842
--- Comment #1 from Kewen Lin ---
We can extend powerpc_vsx to consider current_compiler_flags, it means that if
a test case has an explicit -mvsx, even if users specify -mno-vsx it's still
able to be tested if powerpc_vsx checking concludes VSX
|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
Last reconfirmed||2024-04-25
Target Milestone|--- |15.0
Ever confirmed|0 |1
Status|UNCONFIRMED |ASSIGNED
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: linkw at gcc dot gnu.org
Target Milestone: ---
The current effective target powerpc_vsx_ok is mainly to check if it's fine to
specify -mvsx (without any warnings etc.) and can finally result in a object
fil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88309
Kewen Lin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
||2024-04-23
Keywords||missed-optimization
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
CC||linkw at gcc dot gnu.org
Ever confirmed|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114744
Kewen Lin changed:
What|Removed |Added
Target Milestone|--- |14.0
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114744
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
Ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112980
--- Comment #17 from Kewen Lin ---
(In reply to Michael Matz from comment #16)
> (In reply to Kewen Lin from comment #15)
> > I agree, thanks for the comments! btw, I'm not fighting for the current
> > implementation, just want to know more deta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114567
--- Comment #1 from Kewen Lin ---
This is power8 LE specific, for KFmode its mov expander calls
rs6000_emit_le_vsx_move, so it's with V1TI subreg, then rs6000 specific pass
swaps generate one MEM with AND -16, which make combine unable to optimi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114662
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114662
Kewen Lin changed:
What|Removed |Added
Component|lto |testsuite
Target Milestone|---
gnu.org |linkw at gcc dot gnu.org
CC||linkw at gcc dot gnu.org
Last reconfirmed||2024-04-10
Status|UNCONFIRMED |ASSIGNED
--- Comment #2 from Kewen Lin ---
I think this is a test issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114664
--- Comment #8 from Kewen Lin ---
(In reply to Peter Bergner from comment #7)
> (In reply to Andrew Pinski from comment #6)
> > Pre-IRA fix was done to specifically reject this:
> > https://inbox.sourceware.org/gcc-patches/
> > ab3a6199070202165
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112980
--- Comment #15 from Kewen Lin ---
(In reply to Michael Matz from comment #14)
> Hmm? But this is not how the global-to-local hand-off is implemented (and
> expected by tooling): a fall-through. The global entry sets up the GOT
> register, the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112980
--- Comment #13 from Kewen Lin ---
(In reply to Giuliano Belinassi from comment #12)
> With your patch we have:
>
> > .LPFE0:
> > ...
> Which seems what is expected.
Hi Giuliano, thanks for your time on testing it! Could you kindly help to
ex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114614
Kewen Lin changed:
What|Removed |Added
Target Milestone|--- |14.0
Status|ASSIGNED
1 - 100 of 956 matches
Mail list logo
