https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114732
--- Comment #6 from HaoChen Gui ---
(In reply to Segher Boessenkool from comment #3)
> 1001, 0101, 0011 I mean of course.
>
> In some ways CCmode models this better than CCFPmode, but we do not actually
> model
> the SO bit (bit 3) at all in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114732
--- Comment #1 from HaoChen Gui ---
A straightforward test case. It passes when compiling with O0 and aborts when
compiling with O2.
//test.c
#include
#define BCD_POS0 12// 0xC
#define BCD_NEG 13// 0xD
void abort (void);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114732
Bug ID: 114732
Summary: ge can't be reversed to unlt for bcd compares
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93802
HaoChen Gui changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113325
Bug ID: 113325
Summary: unnecessary byte swap for memory clear
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112707
HaoChen Gui changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112707
--- Comment #9 from HaoChen Gui ---
(In reply to Segher Boessenkool from comment #8)
> Yeah, it tested for ISA 2.04 before. That was an attempt at including 476
> probably?
>
> We really should have a TARGET_FCTID, on for TARGET_POWERPC64 or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112707
HaoChen Gui changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111449
HaoChen Gui changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112417
HaoChen Gui changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |guihaoc at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112417
Bug ID: 112417
Summary: expand_builtin_return shoud check alignment for the
memory reference
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88558
HaoChen Gui changed:
What|Removed |Added
CC||guihaoc at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111449
Bug ID: 111449
Summary: memcmp (p,q,16) == 0 can be optimized better on ppc64
with vector comparison instructions
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96762
HaoChen Gui changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108812
HaoChen Gui changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110034
HaoChen Gui changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108728
HaoChen Gui changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110034
--- Comment #5 from HaoChen Gui ---
(In reply to Vladimir Makarov from comment #4)
> Thank you for providing the test case.
>
> To be honest I don't see why assigning to hr3 to r134 is better.
> Currently we have the following assignments:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106769
HaoChen Gui changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110429
HaoChen Gui changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103605
HaoChen Gui changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104124
HaoChen Gui changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107013
HaoChen Gui changed:
What|Removed |Added
CC||joseph at codesourcery dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110331
--- Comment #1 from HaoChen Gui ---
Even the P9 assembly is not good, as vextu* has a higher lantency than mfvsrd.
li 9,12
vextubrx 3,9,2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110429
Bug ID: 110429
Summary: Redundant vector extract instruction on P9
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110331
Bug ID: 110331
Summary: ppc64 vec_extract with constant index is suboptimal on
P8
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106769
--- Comment #3 from HaoChen Gui ---
(In reply to Peter Bergner from comment #2)
> I wonder if Ajit's REE changes catch this unneeded zero extension?
mfvsrwz can be defined as a zero-extend on a vector select other than a SI mode
move from "wa"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106769
HaoChen Gui changed:
What|Removed |Added
Last reconfirmed||2023-05-31
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110034
--- Comment #3 from HaoChen Gui ---
Created attachment 55215
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55215=edit
ira dump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110034
HaoChen Gui changed:
What|Removed |Added
CC||guihaoc at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106769
HaoChen Gui changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |guihaoc at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110034
Bug ID: 110034
Summary: The first popped allcono doesn't take precedence over
later popped in ira coloring
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54063
HaoChen Gui changed:
What|Removed |Added
CC||guihaoc at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103628
HaoChen Gui changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |guihaoc at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100952
HaoChen Gui changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100866
HaoChen Gui changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108004
--- Comment #4 from HaoChen Gui ---
$cat asm_test.c
#include
unsigned long foo() {
unsigned long res;
__asm__ ("li 3,0x\n\t"
"li 4,0xfff1\n\t"
"and. 3,3,4\n\t"
"mfcr %0"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108004
--- Comment #3 from HaoChen Gui ---
(In reply to Andrew Pinski from comment #2)
> Especially when it comes to signed comparisons.
>From the ISA,
For all fixed-point instructions in which Rc=1, and for
addic., andi., and andis., the first three
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108004
Bug ID: 108004
Summary: x-form logical operations with dot instructions are
not emitted.
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103109
--- Comment #4 from HaoChen Gui ---
(In reply to Peter Bergner from comment #3)
> (In reply to HaoChen Gui from comment #2)
> > Fixed by r13-2107.
>
> This is marked version = GCC 12. Were you planning on backporting this?
Not sure if the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107013
Bug ID: 107013
Summary: Add fmin/fmax to RTL codes
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102316
HaoChen Gui changed:
What|Removed |Added
CC||guihaoc at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103109
HaoChen Gui changed:
What|Removed |Added
Resolution|--- |FIXED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102146
--- Comment #20 from HaoChen Gui ---
(In reply to Segher Boessenkool from comment #19)
> Hi guys,
>
> What testcases are still failing? I'm a bit lost :-)
pr56605.c is still not fixed.
+FAIL: gcc.target/powerpc/pr56605.c scan-rtl-dump-times
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103498
HaoChen Gui changed:
What|Removed |Added
CC||guihaoc at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95737
HaoChen Gui changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100694
--- Comment #6 from HaoChen Gui ---
I made a patch to convert ashift to move when the second operand is const0_rtx.
With the patch, the expand dump is just like aarch64's. But the problem is
still there.
I tested the patch with SPECint. All
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100996
--- Comment #2 from HaoChen Gui ---
(In reply to acsawdey from comment #0)
> The fusion-p10-addadd.c test case does not get vector add-add fusion when
> compiling with -m32:
>
> /home/sawdey/work/gcc/trunk/build/gcc/xgcc
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100996
HaoChen Gui changed:
What|Removed |Added
Resolution|--- |INVALID
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100694
HaoChen Gui changed:
What|Removed |Added
CC||guihaoc at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103316
HaoChen Gui changed:
What|Removed |Added
Status|NEW |RESOLVED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102146
--- Comment #15 from HaoChen Gui ---
As r12-8128 was revoked, failure of pr56605.c is still not fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105414
HaoChen Gui changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105414
--- Comment #8 from HaoChen Gui ---
(In reply to Jakub Jelinek from comment #7)
> Sure, but you don't want to do that at least if flag_trapping_math.
> Otherwise, the predicate would be tree_expr_signaling_nan_p and real_nan
> function with "",
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105414
--- Comment #6 from HaoChen Gui ---
(In reply to Richard Biener from comment #4)
> I think you want
>
> (if (!tree_expr_maybe_signaling_nan_p (@0))
> ...
>
> instead.
Thanks so much for comments. Do we have a way to return a NaN directly in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105414
--- Comment #3 from HaoChen Gui ---
For fmin/max behavior, I referred the this ticket.
https://sourceware.org/bugzilla/show_bug.cgi?id=20947
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105414
--- Comment #2 from HaoChen Gui ---
(In reply to Andrew Pinski from comment #1)
> What target is this on?
I tested it on ppc64le. But I think it should be on all targets?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105414
Bug ID: 105414
Summary: constant folding for fmin/max(snan, snan) is wrong
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103605
--- Comment #6 from HaoChen Gui ---
gcc -O0 -fsignaling-nans -D_WANT_SNAN -lm -o main main.c && ./main
(nan, 3.0), fmin: 3.0, builtin: 3.0, xsmincdp: 3.0, xsmindp: 3.0
(3.0, nan), fmin: 3.0, builtin: nan, xsmincdp: nan, xsmindp: 3.0
(snan,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103605
HaoChen Gui changed:
What|Removed |Added
CC||guihaoc at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102146
--- Comment #10 from HaoChen Gui ---
(In reply to HaoChen Gui from comment #9)
> Could you backport the patch to GCC11? Thanks.
Please ignore it as the patch has problem. Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102146
--- Comment #9 from HaoChen Gui ---
Could you backport the patch to GCC11? Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105030
--- Comment #13 from HaoChen Gui ---
Could we use the original alias set if the tree code of 'atemp' is var_decl? Is
it safe? In which situation we shall use alias-set zero? Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105030
--- Comment #11 from HaoChen Gui ---
I tested C source code with Ofast. The Ofast enables data store race. It should
do store motion but it fails. The problem is on cselim pass. It does
conditional store replacement. The 'atemp' is converted to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102146
--- Comment #5 from HaoChen Gui ---
For prefix-no-update.c, the patch Segher proposed in PR103197 could fix it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102146
--- Comment #4 from HaoChen Gui ---
(In reply to Richard Biener from comment #2)
> What's the status on the remaining failures?
For pr56605.c，I already submitted a patch. Waiting for review.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105030
--- Comment #9 from HaoChen Gui ---
Escaped for 'atemp' doesn't be set with Fortran source code, while it's set
with C source code. 'auto_var_in_fn_p + pt_solution_includes' works for Fortran
code. But if the function is a head of the loop in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105030
--- Comment #7 from HaoChen Gui ---
The original case comes from a Fortran program. I rewrote it with C. As the
arguments are passed by reference in Fortran (by default), the problem is
common. But I am not sure if it has a large performance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105030
--- Comment #5 from HaoChen Gui ---
(In reply to Richard Biener from comment #4)
> something like
>
> void *bar (void *x)
> {
> *(double *)x = 1.;
> }
>
> void foo(int n)
> {
>double atemp;
>pthread_create (..., bar, );
>for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105030
--- Comment #3 from HaoChen Gui ---
(In reply to Richard Biener from comment #2)
> That occured to me as well - I think the answer is maybe. In principle
> foo() could launch a thread and make the 'atemp' available to it. As long
> as foo()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105030
HaoChen Gui changed:
What|Removed |Added
Host||powerpc-*-linux-gnu
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105030
Bug ID: 105030
Summary: store motion if-change flag causes if-conversion
optimization can't be taken.
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103316
HaoChen Gui changed:
What|Removed |Added
CC||guihaoc at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98179
HaoChen Gui changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103124
HaoChen Gui changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100952
--- Comment #16 from HaoChen Gui ---
prefix-no-update.c should be fixed by the patch Segher proposed in PR103197.
pr56605.c got a wrong fixed and failed with GCC11. I will submit a patch to fix
it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103197
HaoChen Gui changed:
What|Removed |Added
CC||guihaoc at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95737
--- Comment #9 from HaoChen Gui ---
Add a pattern to convert the plus mode to DI.
+(define_insn_and_split "*my_split"
+ [(set (match_operand:DI 0 "gpc_reg_operand")
+ (sign_extend:DI (plus:SI (match_operand:SI 1 "ca_operand")
+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93127
HaoChen Gui changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95737
HaoChen Gui changed:
What|Removed |Added
CC||guihaoc at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103784
--- Comment #4 from HaoChen Gui ---
output with "-fdump-tree-optimized=/dev/stdout"
;; Function foo (foo, funcdef_no=0, decl_uid=3317, cgraph_uid=1,
symbol_order=0)
Removing basic block 5
_Bool foo (int a, int b)
{
_Bool _1;
_Bool _5;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103784
--- Comment #2 from HaoChen Gui ---
Sorry, I pasted wrong codes. Here are the correct ones.
//test.c
#include
bool foo (int a, int b)
{
if (a > 2)
return false;
if (b < 10)
return true;
return false;
}
//assembly with the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103784
Bug ID: 103784
Summary: suboptimal code for returning bool value on target ppc
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100952
--- Comment #13 from HaoChen Gui ---
Issue for fusion-p10-ldcmpi.c was fixed by r12-1655.
https://gcc.gnu.org/pipermail/gcc-cvs/2021-June/349357.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100736
--- Comment #4 from HaoChen Gui ---
Yes, there is a question. With my patch, the test case generates following
assembly. Seems they have the same latency (cror vs. crnot). I wonder why we
need reverse the CR bit comparison when finite-math-only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100736
HaoChen Gui changed:
What|Removed |Added
CC||guihaoc at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100868
HaoChen Gui changed:
What|Removed |Added
Resolution|--- |FIXED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103124
--- Comment #5 from HaoChen Gui ---
(In reply to Segher Boessenkool from comment #4)
> Skipping mode TI for zero_extend lowering.
> Splitting mode TI for ashift lowering with shift amounts =
> Splitting mode TI for lshiftrt lowering with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93453
--- Comment #8 from HaoChen Gui ---
I refined the patch and put all things in a helper - change_pseudo_and_mask. As
you mentioned, it's still a band-aid. The perfect solution might be a better
version of nonzero_bits. Thanks.
diff --git
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93453
--- Comment #6 from HaoChen Gui ---
Sehger,
Yes, I found that the nonzero_bits doesn't return exact value in other pass.
So calling nonzero_bits in md file is bad as it can't be recognized in other
pass.
Right now I want to convert a single
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93453
--- Comment #4 from HaoChen Gui ---
For the second issue, I drafted following insn_and_split pattern. It tries to
combine the shift and ior when the nonzero_bits of operands[3] matches the
condition.
(define_insn_and_split "*rotl3_insert_8"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103124
--- Comment #3 from HaoChen Gui ---
My solution is to split the move (from TI to V1TI) into one vsx_concat_v2di and
one V2DI to V1TI move. Thus, TI register 122 can be decomposed.
(insn 12 11 17 2 (set (reg:V1TI 121 [ b ])
(subreg:V1TI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93453
HaoChen Gui changed:
What|Removed |Added
CC||guihaoc at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103124
--- Comment #2 from HaoChen Gui ---
//lower-subreg.c
/* If this is a cast from one mode to another, where the modes
have the same size, and they are not tieable, then mark this
register as non-decomposable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103124
--- Comment #1 from HaoChen Gui ---
Build command gcc -O2 -S test.c -mcpu=power9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103124
Bug ID: 103124
Summary: PPC: "mr" instruction is unnecessary when extending DI
to V1TI
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102169
HaoChen Gui changed:
What|Removed |Added
CC||guihaoc at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102146
--- Comment #1 from HaoChen Gui ---
For pr81348.c, it was already fixed by r11-8941. Segher backported it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100952#c12
PASS: gcc.target/powerpc/pr81348.c (test for excess errors)
PASS:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101865
--- Comment #9 from HaoChen Gui ---
(In reply to Tulio Magno Quites Machado Filho from comment #7)
> (In reply to HaoChen Gui from comment #6)
> > Does _ARCH_PWR8 impact anything during the compiling?
>
> I can answer this question from an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101865
--- Comment #6 from HaoChen Gui ---
(In reply to Segher Boessenkool from comment #5)
> (In reply to HaoChen Gui from comment #4)
> > I wonder if it's a Power8 architecture when those 6 options are all
> > disabled. Or it is regressed to Power7?
1 - 100 of 106 matches
Mail list logo
