-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
,
||linkw at gcc dot gnu.org,
||segher at gcc dot gnu.org
Last reconfirmed||2023-09-26
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
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
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
Kewen Lin changed:
What|Removed |Added
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/piperma
||il/gcc-patches/2024-July/65
||8826.html
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
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/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||bergner at gcc dot gnu.org,
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=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=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
: 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
||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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114842
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
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=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=116170
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
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=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=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
|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
|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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109149
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109082
Kewen Lin changed:
What|Removed |Added
CC||linkw 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: ---
When I was investigating PR109082, I happened to find that in
gcc/config/rs6000/emmintrin.h, we have different definitions
||powerpc*-linux-gnu
Last reconfirmed||2023-03-17
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
Status|UNCONFIRMED |ASSIGNED
--- Comment #1 from Kewen Lin ---
The pair _mm_srli_si128 and
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: linkw at gcc dot gnu.org
Target Milestone: ---
When I was constructing test case for PR109069, I found that rs6000 specific
pass pass_analyze_swaps doesn't try to preserve REG_EQUAL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109259
Kewen Lin changed:
What|Removed |Added
Severity|normal |enhancement
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109167
Kewen Lin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109082
Kewen Lin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
Severity: critical
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: linkw at gcc dot gnu.org
Target Milestone: ---
Commit r13-6873-g776a5bb5894315 changed BB insns walking order under the
assumption that the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109311
Kewen Lin changed:
What|Removed |Added
Priority|P3 |P2
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108815
Kewen Lin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108807
--- Comment #6 from Kewen Lin ---
(In reply to Jeffrey A. Law from comment #5)
> Kewen, is this BZ fixed on the trunk? If so we should update the title by
> dropping the "/13" so that's not flagged as a gcc-13 regression.
Yes, thanks for remin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108807
Kewen Lin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102146
--- Comment #23 from Kewen Lin ---
*** Bug 105267 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105267
Kewen Lin changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
||linkw at gcc dot gnu.org
Last reconfirmed||2023-04-26
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
Summary|gcc.target/powerpc/float128 |[12/13 Regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109069
Kewen Lin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108758
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
||linkw at gcc dot gnu.org
--- Comment #1 from Kewen Lin ---
This is dup of PR108985, it missed to backport
r13-6406-ga2926653ebbc88e8bba335563fa86b44651598d6 to gcc-11 release branch.
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: linkw at gcc dot gnu.org
Target Milestone: ---
On Power9,
- at option -Ofast, 557.xz_r degraded -1.06%.
- at option -Ofast, 511.povray_r degraded -1.24%.
On Power10,
- at option -O2, 520.omnetpp_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109858
--- Comment #3 from Kewen Lin ---
(In reply to Hongtao.liu from comment #2)
> Does https://gcc.gnu.org/pipermail/gcc-patches/2023-May/617431.html help?
Sorry, I just measured those degraded bmks with this fix, the results showed it
didn't help.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109858
--- Comment #6 from Kewen Lin ---
(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/pipermail/gcc-patches/2023-May/617431.html help?
>
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
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
|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
||il/gcc-patches/2024-April/6
||48994.html
CC||linkw at gcc dot gnu.org
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114614
Kewen Lin changed:
What|Removed |Added
Target Milestone|--- |14.0
Status|ASSIGNED
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=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=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
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=114662
Kewen Lin changed:
What|Removed |Added
Component|lto |testsuite
Target Milestone|---
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=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=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=114744
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
Ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114744
Kewen Lin changed:
What|Removed |Added
Target Milestone|--- |14.0
Status|ASSIGNED
||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=88309
Kewen Lin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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
|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
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
||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=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.
|--- |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
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=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
--- 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=114846
Kewen Lin changed:
What|Removed |Added
Attachment #58067|0 |1
is obsolete|
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=112980
Kewen Lin changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
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=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
|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
|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.
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
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 #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=111427
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
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
:
|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=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
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=111380
Kewen Lin changed:
What|Removed |Added
Keywords||wrong-code
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111366
Kewen Lin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
: 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=111522
Kewen Lin changed:
What|Removed |Added
Resolution|--- |INVALID
CC|
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=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=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=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=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=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=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 #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
701 - 800 of 967 matches
Mail list logo
