https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103622
--- Comment #3 from Kewen Lin ---
> One thought seems to check instance->fntype first and take (skip) it as
> mismatch if it's NULL.
This looks like a bad idea, to use long double as the type instead of float128
when type float128 isn't suppor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
--- Comment #1
,
||linkw at gcc dot gnu.org,
||segher at gcc dot gnu.org,
||wschmidt at gcc dot gnu.org
--- Comment #1 from Kewen Lin ---
Probably started to fail from r12-5752.
In the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
--- Comment #2 from Kewen Lin ---
> One fix seems to introduce one stanza for 128bit long double like previous
> RS6000_BTM_LDBL128 which is enabled only if (TARGET_LONG_DOUBLE_128 &&
> TARGET_HARD_FLOAT && !TARGET_IEEEQUAD), and guard
> __buil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103625
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
||2021-12-10
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=103627
--- Comment #2 from Kewen Lin ---
Confirmed. But even if I reverted my previous commit r12-5590 which introduced
this test case (from PR102347) into testsuites, this ICE still exists. So it's
not a regression related to the commit but a latent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103625
--- Comment #6 from Kewen Lin ---
(In reply to Bill Schmidt from comment #4)
> Kewen, how did you confirm this? My cross doesn't accept -mvsx as valid.
>
> $ /home/wschmidt/gcc/build/gcc-e300/gcc/xgcc -c -O2 -mvsx pr103625.c
> -B/home/wschmidt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103702
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=103702
Kewen Lin changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #2 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103622
--- Comment #10 from Kewen Lin ---
> test.c: In function ‘get_float128_exponent’:
> test.c:4:5: note: overloaded builtin ‘__builtin_vec_scalar_extract_exp’ is
> implemented by builtin ‘__builtin_vsx_scalar_extract_expq’
>4 | return __bui
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102347
Kewen Lin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
Assignee: unassigned at gcc dot gnu.org
Reporter: linkw at gcc dot gnu.org
Target Milestone: ---
As PR102347 discussed and tested, aarch64 also does too strict built-in
function decl check. Here is one test case copied from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102347
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102347
--- Comment #19 from Kewen Lin ---
Filed PR103727 for aarch64 issue tracking.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103627
--- Comment #3 from Kewen Lin ---
Also failed with r12-0.
I looked into the ICE with -mcpu=power6 -m32 on BE, the direct reason is that
we turn off VSX flag but still leave MMA, when it wants to emit one move for
V16QI it has to use multiple wo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103627
--- Comment #4 from Kewen Lin ---
For test.c, even we are on ppc64le P9, it can also get ICE:
extern float *dest;
extern __vector_quad src;
int
foo ()
{
__builtin_mma_disassemble_acc (dest, &src);
return 0;
}
$ gcc test.c -mcpu=power10 -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
--- Comment #12 from Kewen Lin ---
(In reply to Arseny Solokha from comment #11)
> Unfortunately, I still have exactly the same ICE on this testcase w/ 12.0.0
> alpha20211219 snapshot:
>
> % powerpc-e300c3-linux-gnu-gcc-12.0.0 -mcpu=401 tt.c
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
--- Comment #14 from Kewen Lin ---
> % powerpc-e300c3-linux-gnu-gcc-12.0.0 -v
> Using built-in specs.
> COLLECT_GCC=powerpc-e300c3-linux-gnu-gcc-12.0.0
> COLLECT_LTO_WRAPPER=/usr/libexec/gcc/powerpc-e300c3-linux-gnu/12.0.0/lto-
> wrapper
> Targe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
--- Comment #15 from Kewen Lin ---
>
> I tried it on a x86_64 cfarm machine:
>
> /home/linkw/gcc/gcc-test/configure --host=x86_64-pc-linux-gnu
> --target=powerpc-e300c3-linux-gnu --build=x86_64-pc-linux-gnu
> --prefix=/home/linkw/gcc/install/g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
--- Comment #17 from Kewen Lin ---
(In reply to Arseny Solokha from comment #16)
> Could there be any ld, or as, or glibc features involved that gcc's
> configure detects at build time?
Good point, what's the version of binutils you used? Does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
--- Comment #20 from Kewen Lin ---
(In reply to Arseny Solokha from comment #19)
> (In reply to Kewen Lin from comment #17)
> > (In reply to Arseny Solokha from comment #16)
> > > Could there be any ld, or as, or glibc features involved that gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
Kewen Lin changed:
What|Removed |Added
Last reconfirmed|2021-12-10 00:00:00 |2021-12-27
--- Comment #21 from Kewen Lin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104004
Kewen Lin changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
|1
CC||avieira at gcc dot gnu.org,
||linkw at gcc dot gnu.org
Last reconfirmed||2022-01-14
--- Comment #1 from Kewen Lin ---
I think it's caused by r12-6240, si
||rguenth at gcc dot gnu.org,
||rsandifo at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
--- Comment #2 from Kewen Lin ---
With further investigation, this isn't duplicated. Now we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104015
--- Comment #4 from Kewen Lin ---
Hi Andre,
Thanks for the detailed explanations all below!
(In reply to avieira from comment #3)
> Hi Kewen,
>
> Thanks for the analysis. The param_vect_partial_vector_usage suggestion
> seems valid, but that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104015
--- Comment #9 from Kewen Lin ---
(In reply to rsand...@gcc.gnu.org from comment #6)
> I think the patch in comment 2 is the correct fix (OK to commit).
>
Thanks for the review and approval Richard!
I totally agree this test case can be fragi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103702
--- Comment #4 from Kewen Lin ---
Patch was posted with the link
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587309.html, still
pending on review.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104015
--- Comment #11 from Kewen Lin ---
(In reply to rsand...@gcc.gnu.org from comment #10)
> Checking the number of tries might be useful, but if so, I think
> it should be done by a test that was written for that specific
> purpose. The tst can th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104015
Kewen Lin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103702
Kewen Lin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102059
--- Comment #30 from Kewen Lin ---
(In reply to pc from comment #27)
> There was a commit related to this bug, but it is still in ASSIGNED state,
> so I'm not sure if this was to be considered "fixed", but...
>
> Chip discovered that, with a bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102059
--- Comment #32 from Kewen Lin ---
(In reply to Michael Meissner from comment #31)
> Created attachment 52383 [details]
> Simpler patch to fix the problem with power8-fusion.
>
> This patch just ignores the -mpower8-fusion option in the callee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102059
Kewen Lin changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102059
--- Comment #35 from Kewen Lin ---
> I don't think the r12-6219 commit qualifies for backporting. What about the
> comment#31 patch? Does it address the issue for Eigen on the branches?
Got it. comment#31 patch can only address the mismatch i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103627
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
||linkw at gcc dot gnu.org
Ever confirmed|0 |1
Last reconfirmed||2022-02-16
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
--- Comment #1 from Kewen Lin ---
Confirmed.
Can't reproduce
|NEW
CC||linkw at gcc dot gnu.org
Last reconfirmed||2022-02-17
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
--- Comment #1 from Kewen Lin ---
Confirmed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
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=104004
Kewen Lin changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99197
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
--- Comment #25 from Kewen Lin ---
The key difference from the previous bif support is that: previously we checked
TARGET_HARD_FLOAT but now we didn't. I think we still need to check it, as the
document here
https://gcc.gnu.org/onlinedocs/gcc/Ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
--- Comment #26 from Kewen Lin ---
Created attachment 52474
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52474&action=edit
Untested patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104024
--- Comment #2 from Kewen Lin ---
Created attachment 52475
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52475&action=edit
Tested patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104024
Kewen Lin changed:
What|Removed |Added
Status|NEW |ASSIGNED
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: linkw at gcc dot gnu.org
Target Milestone: ---
For the case:
#include "stdbool.h"
#define N 256
typedef char T;
extern T a[N];
extern T b[N];
extern T c[N];
extern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104024
--- Comment #4 from Kewen Lin ---
(In reply to Segher Boessenkool from comment #3)
> Most of those options were removed. Does this problem (adjusted properly,
> those options are now enabled iff you use -mcpu=power10 or later) still
> happen on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
--- Comment #31 from Kewen Lin ---
Thanks for the comments, Segher and Peter! Your comments answered my question
in mind that the current unpack/pack pattern supports are complete or not.
IIUC, to cover it for both soft-float and hard-float case
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=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=96072
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
Status
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 fr
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=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
---
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=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 ques
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=105485
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
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=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=106516
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
||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=99888
Kewen Lin changed:
What|Removed |Added
CC||giuliano.belinassi at gmail
dot co
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
Status|ASSIGNED|RESOLVED
Resolution|---
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=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
CC||rguenth at gcc dot gnu.org,
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
--- 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 r13-32
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=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=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 e
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 #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 b
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=96072
Kewen Lin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
|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
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 and I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107338
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
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
: 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
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
|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 mentione
||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 was
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 of that
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=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=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,
> but
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:
>
> % powerpc-e3
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?
>
> I'
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
|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=107412
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
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=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=105480
Kewen Lin changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org,
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 -fs
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
> incorrect
301 - 400 of 956 matches
Mail list logo
