https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64669
Richard Henderson changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64669
--- Comment #14 from Richard Henderson ---
Author: rth
Date: Wed Jan 21 15:47:49 2015
New Revision: 219951
URL: https://gcc.gnu.org/viewcvs?rev=219951&root=gcc&view=rev
Log:
PR target/64669
* ccmp.c (used_in_cond_stmt_p): Remove.
(expand_ccmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64669
--- Comment #13 from Jiong Wang ---
(In reply to Richard Henderson from comment #11)
> Created attachment 34506 [details]
> proposed patch
>
> This is what I'm currently testing.
passed profiledbootstrap on top of 219849.
spec2kint/spec2k6int b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64669
--- Comment #12 from Jakub Jelinek ---
There is no
typedef __SIZE_TYPE__ size_t;
in the testcase
(or sed -i -e s/size_t/__SIZE_TYPE__/g pr64669.C ).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64669
Richard Henderson changed:
What|Removed |Added
Assignee|jiwang at gcc dot gnu.org |rth at gcc dot gnu.org
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64669
--- Comment #10 from Jiong Wang ---
(In reply to Richard Henderson from comment #8)
> Indeed, if I force used_in_cond_stmt_p to return false, which forces
> the use of the emit_cstore path, which means we return a proper
> boolean value instead o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64669
--- Comment #9 from Andrew Pinski ---
(In reply to Richard Henderson from comment #8)
> I think I was wrong to approve the ccmp patch with the used_in_cond_stmt_p
> logic in the first place, and that it should all be removed.
I tend to agree bec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64669
--- Comment #8 from Richard Henderson ---
Indeed, if I force used_in_cond_stmt_p to return false, which forces
the use of the emit_cstore path, which means we return a proper
boolean value instead of a CCmode value, the test case doesn't ICE.
Mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64669
--- Comment #7 from Richard Henderson ---
(In reply to Jiong Wang from comment #5)
> although there is no correctness issue with the "if (_27 <= 0)", but I think
> for boolean type "<= 0" is exactly "== 0", so the "<" is uncessary.
True, but at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64669
--- Comment #6 from Jiong Wang ---
(In reply to Jiong Wang from comment #5)
> Created attachment 34502 [details]
> kk.ii
>
this testcase reproduce exactly what Jakub reported.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64669
--- Comment #5 from Jiong Wang ---
Created attachment 34502
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34502&action=edit
kk.ii
attachment is the reduced testcase.
./cc1 -g -O2 -fprofile-use -fno-exceptions -fno-rtti
-fasynchronous-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64669
--- Comment #4 from Jiong Wang ---
haven't enable go front end,
../gcc/configure --enable-languages=c,c++,fortran --disable-libsanitizer
--enable-checking=release --disable-werror
with make -j16 profiledbootstrap, I got several
../../../gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64669
--- Comment #3 from Jakub Jelinek ---
That was the --disable-werror.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64669
--- Comment #2 from Richard Henderson ---
Hmm. I'm not even getting that far with r219852
gcc/expmed.h: In function ‘void init_expmed()’:
gcc/expmed.h:613:77: error: array subscript is above array bounds
[-Werror=array-bounds]
return &this_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64669
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64669
Jakub Jelinek changed:
What|Removed |Added
CC||jiwang at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64669
Jakub Jelinek changed:
What|Removed |Added
Target||aarch64-linux
Status|UNCONFI
17 matches
Mail list logo
