at gcc dot gnu.org |linkw at gcc dot gnu.org
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
--- Comment #1 from Kewen Lin ---
It can be reproduced even without cross build.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103196
--- Comment #5 from Kewen Lin ---
(In reply to Richard Biener from comment #4)
> Or adjust the testcase. Please?
Thanks for the suggestion! I adjusted the test case by making it not unrolled
any more, as the patch posted at
https://gcc.gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102059
Kewen Lin changed:
What|Removed |Added
Assignee|linkw at gcc dot gnu.org |meissner at gcc dot
gnu.org
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: linkw at gcc dot gnu.org
Target Milestone: ---
- Test case -
$cat new_test.c
typedef vector unsigned int v4u;
extern v4u vg;
v4u testXXPERMDI(void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104930
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=104930
--- Comment #2 from Kewen Lin ---
It's regressed from r12-5752-gd08236359eb229, in the new bif infrastructure we
don't use the type opaque_V4SI_type_node for prototype of overloaded built-in
functions any more.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104482
--- Comment #2 from Kewen Lin ---
One fix has been posted via
https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591768.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105002
Kewen Lin changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
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 ---
Confirmed, it's not a d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105002
--- Comment #4 from Kewen Lin ---
Created attachment 52668
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52668&action=edit
Untested patch
Putting it through testing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105002
Kewen Lin changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104930
--- Comment #3 from Kewen Lin ---
Created attachment 52669
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52669&action=edit
A trial patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104930
--- Comment #4 from Kewen Lin ---
Hi @Peter and @Segher, do you agree that the previous behavior is better? That
is users don't need one extra option ‘-flax-vector-conversions’ to get more
accurate warnings.
The associated trial patch tries to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104967
Kewen Lin changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105002
--- Comment #5 from Kewen Lin ---
Patch was just posted at
https://gcc.gnu.org/pipermail/gcc-patches/2022-March/592204.html.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104967
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
||linkw at gcc dot gnu.org
Status|UNCONFIRMED |RESOLVED
--- Comment #2 from Kewen Lin ---
The bisection shows r11-7579 fixed it. As the symptom of one duplicated PR99392
which is also powerpc64 -m32 only, I think this one is also duplicated of
PR90448
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90448
--- Comment #16 from Kewen Lin ---
*** Bug 90226 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105002
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
||2022-04-07
Ever confirmed|0 |1
CC||bergner at gcc dot gnu.org,
||linkw at gcc dot gnu.org
--- Comment #1 from Kewen Lin ---
On current trunk (GCC12), this issue is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103196
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
Assignee: unassigned at gcc dot gnu.org
Reporter: linkw at gcc dot gnu.org
CC: asolokha at gmx dot com, bergner at gcc dot gnu.org,
linkw at gcc dot gnu.org, segher at gcc dot gnu.org
Depends on: 103623
Target Milestone
|--- |FIXED
Assignee|linkw at gcc dot gnu.org |segher at gcc dot
gnu.org
URL|https://gcc.gnu.org/piperma |
|il/gcc-patches/2021-Decembe |
|r/586712.html,https://gcc.g |
|nu.org/pipermail/gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105234
--- Comment #13 from Kewen Lin ---
Just noticed this, many thanks for triaging and fixing!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105266
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105266
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=104482
Kewen Lin changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
gcc dot gnu.org |linkw at gcc dot gnu.org
Target|powerpc-e300c3-linux-gnu|powerpc*-linux-gnu
Last reconfirmed||2022-04-14
Ever confirmed|0 |1
CC||linkw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105271
Kewen Lin changed:
What|Removed |Added
Summary|ICE in extract_insn, at |[12 Regression] ICE in
|r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105266
Kewen Lin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105313
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105267
--- Comment #1 from Kewen Lin ---
*** Bug 105313 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
CC||linkw at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105271
Kewen Lin changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105325
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105334
--- Comment #5 from Kewen Lin ---
Oops, sorry that I just verified the original case in PR103623 previously,
missed to find it doesn't have pack bif.
Maybe we could add one test case to cover both unpack and pack ICEs, such as:
$cat gcc/testsu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105325
--- Comment #10 from Kewen Lin ---
(In reply to Jakub Jelinek from comment #9)
> where it no longer satisfies the predicate but does satisfy the constraint.
> It is unclear if there is any matching constraint for ds_form_mem_operand,
> maybe wY?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105271
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103605
--- Comment #7 from Kewen Lin ---
(In reply to pc from comment #5)
> I modified the testcase from comment #3 to clear-before and check-after
> FE_INVALID exception bit for each operation:
> --
> $ /opt/gcc-nightly/trunk/bin/gcc -O2 -o xsmindp-te
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105334
Kewen Lin changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106365
Kewen Lin changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106365
--- Comment #3 from Kewen Lin ---
(In reply to Richard Biener from comment #2)
> What's the semantic of .LEN_STORE? I can't find documentation for this :/
> There's docs for the len_store optab but how 'mask' and 'bias' relate to its
> operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106365
--- Comment #6 from Kewen Lin ---
(In reply to Richard Biener from comment #5)
> I will try to add handling for .MASK_STORE, hopefully that will be good
> enough to massage the code for .LEN_STORE (which IIRC is "easier" since it's
> a contiguou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106365
--- Comment #10 from Kewen Lin ---
(In reply to Richard Biener from comment #7)
> Created attachment 53323 [details]
> prototype
>
> I'm testing this - for .LEN_STORE you mainly have to compute pd.rhs_off,
> pd.offset, pd.size and do a single
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106365
--- Comment #12 from Kewen Lin ---
(In reply to Richard Biener from comment #9)
> Created attachment 53328 [details]
> patch
>
Thanks! Sorry that I didn't see this attachment when posting the above
comment.
> + MEM [(int *)&out + 16B] = {
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: linkw at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org, rsandifo at gcc dot gnu.org,
segher at gcc dot gnu.org
Depends on: 106365
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106365
--- Comment #14 from Kewen Lin ---
> I think that DSE doesn't handle the store IFNs yet - maybe adding handling
> to initialize_ao_ref_for_dse would be enough - but I think it cannot yet
> handle a "conservative" start (for .MASK_STORES), but .L
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106378
--- Comment #2 from Kewen Lin ---
(In reply to Richard Biener from comment #1)
> Created attachment 53330 [details]
> patch
>
> I am testing this on x86_64-linux.
I confirmed this attachment can make two case above to get expected optimized
IR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106396
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106010
Kewen Lin changed:
What|Removed |Added
CC||seurer at gcc dot gnu.org
--- Comment #8 fr
|1
Status|UNCONFIRMED |WAITING
CC||linkw at gcc dot gnu.org
--- Comment #1 from Kewen Lin ---
I wasn't able to reproduce this with cross build compiler w/i either latest
trunk or the mentioned snapsho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106419
--- Comment #3 from Kewen Lin ---
(In reply to Arseny Solokha from comment #2)
> I don't set --enable-default-pie anymore when configuring gcc, so here's the
> difference. Therefore, it stops ICEing if I add -fPIE or -fPIC when
> compiling the t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106415
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106419
Kewen Lin changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #5 from Kewen Lin ---
Than
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106419
Kewen Lin changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106345
Kewen Lin changed:
What|Removed |Added
CC||seurer at gcc dot gnu.org
--- Comment #4 fr
|--- |DUPLICATE
CC||linkw at gcc dot gnu.org
--- Comment #4 from Kewen Lin ---
See comment 1 of PR106345, it's due to incorrect effective target checking.
*** This bug has been marked as a duplicate of bug 106345 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106419
--- Comment #9 from Kewen Lin ---
(In reply to Segher Boessenkool from comment #8)
> So for which pseudo and which hard register did this ICE, and what did the
> code look like at that point?
The culprit pseudo is r133, the values of those rela
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106091
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
|1
CC||linkw at gcc dot gnu.org
Last reconfirmed||2022-08-03
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
--- Comment #1 from Kewen Lin ---
cat test.c
extern int a;
int
|--- |WORKSFORME
CC||linkw at gcc dot gnu.org
--- Comment #3 from Kewen Lin ---
Marked resolved as Arseny's latest comment.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106069
--- Comment #21 from Kewen Lin ---
I didn't look into this in details, but something in the culprit commit caught
my eyes, take altivec_vmrghh as example:
Before the patch, the pattern
[(set (match_operand:V8HI 0 "register_operand" "=v")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106069
--- Comment #23 from Kewen Lin ---
> Ideally we would avoid semantic difference of RTL depending on the target.
> If that's not avoidable there should be target macros/hooks that specify
> the desired semantics.
Not sure, IMHO it seems it doe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99888
--- Comment #2 from Kewen Lin ---
Created attachment 53405
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53405&action=edit
untested patch
With the attached patch, for -fpatchable-function-entry=5,2 it gets:
foo:
.LFB0:
.cfi_start
||linkw at gcc dot gnu.org
Last reconfirmed||2022-08-04
Status|UNCONFIRMED |NEW
--- Comment #2 from Kewen Lin ---
Confirmed, this is a test issue, power10 and up specific.
The difference comes from the function thud, it aims to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99888
--- Comment #4 from Kewen Lin ---
(In reply to Segher Boessenkool from comment #3)
> Your second option isn't correct: all these nops should be consecutive. Your
> option 1 is fine :-)
Good point! It's lucky that I chose option 1. :)
||linkw at gcc dot gnu.org
Summary|[rs6000] sub-optimal|[rs6000] sub-optimal 64bit
|constant generation |constant generation for P10
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322
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=106322
--- Comment #32 from Kewen Lin ---
(In reply to Mathieu Malaterre from comment #30)
> (In reply to Martin Liška from comment #29)
> > (In reply to Kewen Lin from comment #28)
> > > Sorry for the breakage, I'll have a look tomorrow.
> > >
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322
--- Comment #37 from Kewen Lin ---
(In reply to Andrew Pinski from comment #36)
> You might need to do -O2 -fPIE -pie to reproduce the issue as debian is
> configured with --enable-default-pie
Thanks for the hint! I can reproduce this but it ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322
--- Comment #38 from Kewen Lin ---
Created attachment 53428
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53428&action=edit
untested patch
A untested patch which can make it pass.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322
--- Comment #40 from Kewen Lin ---
> >diff --git a/gcc/internal-fn.cc b/gcc/internal-fn.cc
> >index d666f67..7d8b4ac2200 100644
> >--- a/gcc/internal-fn.cc
> >+++ b/gcc/internal-fn.cc
> >@@ -3750,7 +3750,12 @@ static bool
> > direct_optab_su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322
--- Comment #41 from Kewen Lin ---
(In reply to Kewen Lin from comment #40)
> > >diff --git a/gcc/internal-fn.cc b/gcc/internal-fn.cc
> > >index d666f67..7d8b4ac2200 100644
> > >--- a/gcc/internal-fn.cc
> > >+++ b/gcc/internal-fn.cc
> > >@@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322
--- Comment #44 from Kewen Lin ---
(In reply to Richard Biener from comment #43)
> (In reply to Richard Biener from comment #42)
> > I think this goes wrong in vectorizable_operation which does
> >
> > if (using_emulated_vectors_p
> > &
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99888
--- Comment #6 from Kewen Lin ---
(In reply to Fangrui Song from comment #5)
> * There is a restriction on the number of instructions between the function
> label and the .localentry directive.
> * For -fpatchable-function-entry=N[,M], M nops mus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99889
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
Ever confirmed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322
Kewen Lin changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #45 from Kewen Lin --
gcc dot gnu.org |linkw at gcc dot gnu.org
--- Comment #2 from Kewen Lin ---
By checking the related materials and discussions, I think the original issue
does still exist even if the recent trunk makes the linking error gone because
of comdat flag being introduced onto the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106345
--- Comment #9 from Kewen Lin ---
(In reply to Michael Meissner from comment #8)
> Note, the gcc.target/powerpc/pr92398.p9-.c test fails when the compiler is
> configured for either --with-cpu=power9 or --with-cpu=power10. No
> --with-tune= was
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106681
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106516
Kewen Lin changed:
What|Removed |Added
CC||meissner at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106680
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106516
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=106516
--- Comment #7 from Kewen Lin ---
(In reply to Peter Bergner from comment #6)
> (In reply to Kewen Lin from comment #5)
> > Created attachment 53492 [details]
> > Adjust pr104992.c with vect_int_mod
> >
> > > So it sounds like we want a generic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103353
Kewen Lin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322
--- Comment #49 from Kewen Lin ---
Hi Richi,
One thing I'm not sure about is that if we want to backport this to gcc-11 and
gcc-10? Although the failure got exposed by .MULH pattern recog which is only
in gcc-12, IMHO the underlying issue exist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99888
--- Comment #10 from Kewen Lin ---
By searching the history of this feature, I found its initial versions only
proposed to place nops after the function entry, such as: v2[1], then it's
requested to be more generic to handle some "exploited atomi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99888
--- Comment #11 from Kewen Lin ---
Oops, the reference links in #c10 are:
[1] https://gcc.gnu.org/pipermail/gcc-patches/2016-September/458210.html
[2] https://gcc.gnu.org/pipermail/gcc-patches/2016-September/458287.html
[3] https://gcc.gnu.org/p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106736
Kewen Lin changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106736
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=106736
--- Comment #7 from Kewen Lin ---
(In reply to Peter Bergner from comment #5)
> (In reply to Kewen Lin from comment #4)
> > Thanks for the comments! One patch guarding these types is attached, it can
> > fix the ICE.
>
> That won't work, becaus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106682
Kewen Lin changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
|1
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
Last reconfirmed||2022-08-29
--- Comment #2 from Kewen Lin ---
Confirmed, I can reproduce it with cfarm machine gcc110, the issue is exactly
like what its comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106736
Kewen Lin changed:
What|Removed |Added
Attachment #53513|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106682
Kewen Lin changed:
What|Removed |Added
Component|target |testsuite
Resolution|---
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: linkw at gcc dot gnu.org
Target Milestone: ---
This is from one encountered ICE when using const type:
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600751.html
As the above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106833
Kewen Lin changed:
What|Removed |Added
Keywords||ice-checking
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106833
--- Comment #4 from Kewen Lin ---
(In reply to Richard Biener from comment #2)
> (In reply to Kewen Lin from comment #1)
> > IMHO this is an omission when we were adding supports for opaque type, const
> > __vector_quad and __vector_quad should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106833
--- Comment #5 from Kewen Lin ---
> > I'm quoting tree.def, emphasis mine:
> >
> > /* This is for types that will use MODE_OPAQUE in the back end. They are
> > meant
> >to be able to go in a register of some sort but are _EXPLICITLY NOT TO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106833
--- Comment #8 from Kewen Lin ---
Created attachment 53542
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53542&action=edit
Specially handle opaque type in verify_type
(In reply to Segher Boessenkool from comment #7)
> (In reply to rguent
301 - 400 of 956 matches
Mail list logo
