https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108729
--- Comment #2 from Kewen Lin ---
*** Bug 108731 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108731
Kewen Lin changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
||2023-02-14
Ever confirmed|0 |1
CC||linkw at gcc dot gnu.org
--- Comment #1 from Kewen Lin ---
Confirmed, it's similar to PR108729, need the has_arch_ppc64 checking for used
bif scalar_insert_exp.
|NEW
CC||linkw at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Kewen Lin ---
Confirmed.
Error message is:
gcc/testsuite/gcc.target/powerpc/bfp/scalar-test-data-class-12.c:31:3: error
||2023-02-14
CC||linkw at gcc dot gnu.org,
||meissner at gcc dot gnu.org,
||segher at gcc dot gnu.org
Ever confirmed|0 |1
|--- |DUPLICATE
CC||linkw at gcc dot gnu.org
--- Comment #1 from Kewen Lin ---
As the comments in PR107396 (same symptom), this one is duplicated of that one,
and it's Power9 specific (but not BE only?).
*** This bug has been marked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107396
--- Comment #2 from Kewen Lin ---
*** Bug 108726 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108272
Kewen Lin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108348
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108396
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108415
--- Comment #4 from Kewen Lin ---
(In reply to Peter Bergner from comment #3)
> (In reply to Kewen Lin from comment #2)
> > The contradictory thing is that we can have TARGET_VSX and TARGET_SOFT_FLOAT
> > (!TARGET_HARD_FLOAT) together with the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108415
--- Comment #2 from Kewen Lin ---
(In reply to Segher Boessenkool from comment #1)
> Soft float does not conflict with anything (anything that does not need
> FP registers that is). But yes, we really should neuter -mmodulo.
The contradictory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108240
--- Comment #13 from Kewen Lin ---
(In reply to Martin Liška from comment #11)
> One more test-case that started to ICE with the same revision:
>
> ./xgcc -B.
> /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-2.c
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108396
--- Comment #4 from Kewen Lin ---
(In reply to Segher Boessenkool from comment #3)
> (In reply to Kewen Lin from comment #2)
> > Unfortunately we don't have the testing coverage in testsuite for the
> > expected name vec_vsubcuq (in
Regression] PPCLE: |[12/13 Regression] PPCLE:
|vec_vsubcuq missing |vec_vsubcuq missing since
||r12-5752-gd08236359eb229
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108240
Kewen Lin changed:
What|Removed |Added
Summary|[13 Regression] ICE in |[13 Regression] Error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108240
--- Comment #9 from Kewen Lin ---
I filed one new bug PR108415 for the ICE itself to avoid the confusion here.
This ICE is not a regression, it's a latent bug, because:
1) Without the culprit commit r13-4894 (like using r13-4893 or reverting
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |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
CC: bergner at gcc dot gnu.org, linkw at gcc dot gnu.org,
marxin at gcc dot gnu.org, segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108240
--- Comment #8 from Kewen Lin ---
(In reply to Segher Boessenkool from comment #7)
> -m64 requires 64-bit instructions. We will ICE if we try to generate code
> for -m64 without support for 64-bit insns enabled in the compiler. For
> example,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108348
--- Comment #6 from Kewen Lin ---
(In reply to Peter Bergner from comment #5)
> (In reply to Kewen Lin from comment #1)
> > diff --git a/gcc/config/rs6000/rs6000-call.cc
> > b/gcc/config/rs6000/rs6000-call.cc
> > index 59c51fa3579..6767a1f541c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108348
--- Comment #4 from Kewen Lin ---
(In reply to Kewen Lin from comment #3)
> There seem to be two alternatives to fix this, one is to raise error in
> rs6000_pass_by_reference like what we do in rs6000_function_arg, but we need
> something like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108348
--- Comment #3 from Kewen Lin ---
There seem to be two alternatives to fix this, one is to raise error in
rs6000_pass_by_reference like what we do in rs6000_function_arg, but we need
something like mma_return_type_error to avoid re-erroring;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108348
--- Comment #2 from Kewen Lin ---
This is a 32 bit specific issue, the function rs6000_pass_by_reference has:
/* Allow -maltivec -mabi=no-altivec without warning. Altivec vector
modes only exist for GCC vector types if -maltivec. */
|1
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
Last reconfirmed||2023-01-10
Target Milestone|--- |13.0
CC||linkw at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108240
--- Comment #6 from Kewen Lin ---
(In reply to Kewen Lin from comment #5)
> (In reply to Segher Boessenkool from comment #4)
> > (In reply to Kewen Lin from comment #3)
> > > With the culprit commit r13-4894, we always implicitly enable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108272
--- Comment #4 from Kewen Lin ---
(In reply to Arseny Solokha from comment #3)
> (In reply to Kewen Lin from comment #2)
> > Created attachment 54192 [details]
> > untested patch
> >
> > Hi @Arseny, I hope this patch can help to clear all the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108240
--- Comment #5 from Kewen Lin ---
(In reply to Segher Boessenkool from comment #4)
> (In reply to Kewen Lin from comment #3)
> > With the culprit commit r13-4894, we always implicitly enable powerpc64 for
> > both explicit and implicit 64 bit,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108272
--- Comment #2 from Kewen Lin ---
Created attachment 54192
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54192=edit
untested patch
Hi @Arseny, I hope this patch can help to clear all the ICEs about unexpected
uses of MMA opaque types in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106736
Kewen Lin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106680
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108273
Kewen Lin changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org,
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: linkw at gcc dot gnu.org
Target Milestone: ---
Test case gcc.target/powerpc/pr105586.c fails with -fcompare-debug failure on
Power10 (P10 specific) if I applied one patch to fix the current inaccurate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106736
--- Comment #17 from Kewen Lin ---
(In reply to Arseny Solokha from comment #16)
> (In reply to Kewen Lin from comment #15)
> > Thanks for reporting, confirmed. The function
> > rs6000_opaque_type_invalid_use_p only handles gassign, this
||segher at gcc dot gnu.org
Ever confirmed|0 |1
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
Target Milestone|--- |13.0
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108240
Kewen Lin changed:
What|Removed |Added
Target|poiwerpc|powerpc
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108240
--- Comment #2 from Kewen Lin ---
Well, there are two issues here:
1) the ICE itself, it's independent of option powerpc64 handling, without the
culprit commit r13-4894 but with an explicit option -m64, the ICE is still
reproducible. So this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106736
--- Comment #15 from Kewen Lin ---
(In reply to Arseny Solokha from comment #14)
> W/ gcc 13.0.0 20221225 snapshot (g:febb58d28bfa4b544ec7ffec2d61f46d25205ff0)
> I still get this ICE when compiling
>
||ice-on-valid-code
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
--- Comment #1 from Kewen Lin ---
Thanks for reporting! Confirmed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105818
Kewen Lin changed:
What|Removed |Added
URL|https://gcc.gnu.org/piperma |https://gcc.gnu.org/piperma
gnu.org |linkw at gcc dot gnu.org
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2022-12-20
Target Milestone|--- |13.0
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: linkw at gcc dot gnu.org
Target Milestone: ---
In the review of patch [1] for PR105818, Honza pointed out
"I think we should generally avoid doing decisions about size/speed
optimizations so early
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99889
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90259
Kewen Lin changed:
What|Removed |Added
Target|powerpc-e300c3-linux-gnu|powerpc*-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105480
--- Comment #11 from Kewen Lin ---
(In reply to jos...@codesourcery.com from comment #10)
> For scalar isnan see bug 66462. (The claim in bug 66462 comment 19 that
> there was ever a working version of that patch ready to go in is
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105480
--- Comment #8 from Kewen Lin ---
(In reply to Richard Biener from comment #7)
> (In reply to Kewen Lin from comment #6)
> > Both fcmpu and fcmp would trap for sNaN, is it expected with the current GCC
> > implementation?
>
> But the key is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105480
Kewen Lin changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105480
Kewen Lin changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
Ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107412
Kewen Lin changed:
What|Removed |Added
Target Milestone|--- |13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107412
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
|RESOLVED
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
CC||linkw at gcc dot gnu.org
Target|powerpc64le-linux-gnu |powerpc64le-linux-gnu
|powerpc64-linux-gnuhppa-lin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90259
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=90259
--- Comment #6 from Kewen Lin ---
(In reply to Arseny Solokha from comment #5)
> Created attachment 53808 [details]
> -mdebug=target dump
>
> (In reply to Kewen Lin from comment #4)
> > Could you provide one dump file for -mdebug=target?
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90259
--- Comment #4 from Kewen Lin ---
(In reply to Arseny Solokha from comment #3)
> Aha! I've just managed to reproduce it even w/ the current gcc 13 snapshot
> by adding -fstack-protector-all to the list of command line arguments:
>
> %
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107412
--- Comment #3 from Kewen Lin ---
(In reply to Segher Boessenkool from comment #2)
> Make sure we only use "plain" accesses on machines that allow all unaligned
> accesses? p8 and later I think. The load-with-length insns are even later,
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
--- Comment #20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107240
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98603
Kewen Lin changed:
What|Removed |Added
CC||asolokha at gmx dot com
--- Comment #5 from
|--- |DUPLICATE
CC||linkw at gcc dot gnu.org
--- Comment #6 from Kewen Lin ---
The bisection shows the extra ICE dump was gone since r11-6562 (for fixing
PR98603), by checking the bug description of PR98603, I believed this is one
dup
||2022-10-27
Ever confirmed|0 |1
CC||linkw at gcc dot gnu.org,
||rguenth at gcc dot gnu.org
--- Comment #2 from Kewen Lin ---
The bisection shows this issue
|WAITING
Ever confirmed|0 |1
CC||linkw at gcc dot gnu.org
--- Comment #2 from Kewen Lin ---
I'm going to do bisection to see which commit makes this pass, but it's weird
that even with the mentioned snapshot
at gcc dot gnu.org |linkw at gcc dot gnu.org
Ever confirmed|0 |1
Last reconfirmed||2022-10-26
Keywords||missed-optimization
Target||powerpc64le-linux-gnu
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: linkw at gcc dot gnu.org
Target Milestone: ---
test case:
===
#define N 16
int src[N];
int dest[N];
void foo (){
for (int i = 0; i < (N-1); i++)
des
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88132
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107338
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
at gcc dot gnu.org |linkw at gcc dot gnu.org
--- Comment #4 from Kewen Lin ---
(In reply to avieira from comment #3)
> Hi Kewen,
>
> I believe you are right. I was waiting for a powerpc machine in the board
> farm, but I suspect I can reproduce this with an aarch64 BE target an
|NEW
CC||linkw at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Kewen Lin ---
Confirmed, this issue is BE specific.
vect__ifc__10.14_55 = MEM [(struct s *)_22];
vect__ifc__10.15_57 = MEM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96072
Kewen Lin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100645
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107240
--- Comment #8 from Kewen Lin ---
(In reply to Kewen Lin from comment #7)
> Well, it does helps vect-bitfield-write-{2,3}.c, but it doesn't help
> vect-bitfield-write-{2,3,4}.c since they do require vector/vector shift
Oops, typo here, should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107299
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107240
--- Comment #7 from Kewen Lin ---
Well, it does helps vect-bitfield-write-{2,3}.c, but it doesn't help
vect-bitfield-write-{2,3,4}.c since they do require vector/vector shift
supports.
I guess it might be a good idea to add the vect_long_long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107240
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107160
--- Comment #18 from Kewen Lin ---
Thanks for the prompt fix! I just verified it fixed the SPEC2006 447.dealII
regression perfectly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107160
--- Comment #11 from Kewen Lin ---
> > > Btw, I've fixed a SLP reduction issue two days ago in
> > > r13-3226-gee467644c53ee2
> > > though that looks unrelated?
> >
> > Thanks for the information, I'll double check it.
> >
To rebase to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107160
--- Comment #9 from Kewen Lin ---
>
> The above doesn't look wrong (but may miss the rest of the IL). On
> x86_64 this looks like
>
>[local count: 105119324]:
> # sum0_41 = PHI
> # sum1_39 = PHI
> # sum2_37 = PHI
> # sum3_35 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107160
Kewen Lin changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107160
Kewen Lin changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107160
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=99888
Kewen Lin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99889
Bug 99889 depends on bug 99888, which changed state.
Bug 99888 Summary: Add powerpc ELFv2 support for -fpatchable-function-entry*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99888
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99888
Kewen Lin changed:
What|Removed |Added
CC||giuliano.belinassi at gmail
dot co
||linkw at gcc dot gnu.org
Status|NEW |RESOLVED
--- Comment #4 from Kewen Lin ---
r13-2984 makes gcc emit error for -fpatchable-function-entry=1 on ppc64le if
the relavant function needs dual entry, I think we can close this one.
*** This bug has
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106516
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322
--- Comment #54 from Kewen Lin ---
(In reply to Mathieu Malaterre from comment #53)
> Closing. I do not believe that Debian gcc-12 (12.2.0-3) really is an update
> to git 20220920 from the gcc-12 branch. Sorry for the noise.
OK. Thanks for the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104482
Kewen Lin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105485
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96072
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=106833
--- Comment #16 from Kewen Lin ---
(In reply to Peter Bergner from comment #15)
> (In reply to Kewen Lin from comment #14)
> > Should be fixed on trunk
>
> I assume this is broken on the release branches too and we'll need backports?
Good
dot gnu.org |linkw at gcc dot gnu.org
Status|UNCONFIRMED |RESOLVED
--- Comment #14 from Kewen Lin ---
Should be fixed on trunk, opened PR106941 for conversion as Segher's comments.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106941
Bug 106941 depends on bug 106833, which changed state.
Bug 106833 Summary: Miss to handle OPAQUE_TYPE specially in verify_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106833
What|Removed |Added
Severity: minor
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: linkw at gcc dot gnu.org
CC: bergner at gcc dot gnu.org, hubicka at gcc dot gnu.org,
rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96072
Kewen Lin changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96072
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100645
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=100645
Kewen Lin changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106345
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106736
--- Comment #12 from Kewen Lin ---
(In reply to Segher Boessenkool from comment #11)
> (In reply to Peter Bergner from comment #10)
> > (In reply to Segher Boessenkool from comment #9)
> > > When MMA is not enabled,
> > ...
> > > the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106833
--- Comment #11 from Kewen Lin ---
One modified case from pr102347.c (same option set is used), which can
reproduce the ICE without any gcc source adjustment.
#pragma GCC target "cpu=power10"
int main ()
{
float *b;
const __vector_quad c;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106833
--- Comment #10 from Kewen Lin ---
(In reply to Segher Boessenkool from comment #9)
> Although, preferably we should not allow assigning one opaque type to another
> opaque type just because they will eventually use the same mode, not without
>
301 - 400 of 894 matches
Mail list logo
