https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100952
--- Comment #2 from HaoChen Gui ---
For pr81348.c, the lxsihzx and vextsh2d are no long needed as the HI to DI mode
promotion is removed by my patch. The short could be loaded directly.
addis 9,2,.LANCHOR0+4@toc@ha
lha 9,.LANCHOR0+4@toc@l(9)
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100952
--- Comment #3 from HaoChen Gui ---
For pr56605.c, the pseudo is not taken mode promotion. The original combined
insn
compare:CC (and:DI (reg:DI 206)
changes to
compare:CC (and:SI (subreg:SI (reg:DI 206) 0)
So the dump scan fails. I will change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100952
--- Comment #4 from HaoChen Gui ---
For fusion-p10-ldcmpi.c and prefix-no-update.c, the optimization doesn't work
when mode promotion is disabled. I will do further investigation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100952
--- Comment #6 from HaoChen Gui ---
Seurer,
Could you provide detail info about test? Such as config and build option. I
tested the build on P10 and no failure on parity_1.f90. Thanks.
PASS: gfortran.dg/parity_1.f90 -O0 (test for excess err
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100952
--- Comment #7 from HaoChen Gui ---
PASS: gfortran.dg/parity_1.f90 -O0 execution test
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=98179
HaoChen Gui changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103316
HaoChen Gui changed:
What|Removed |Added
CC||guihaoc at gcc dot gnu.org
--- Comment #1
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=105030
HaoChen Gui changed:
What|Removed |Added
Host||powerpc-*-linux-gnu
--- Comment #1 from H
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() ou
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, &atemp);
>fo
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 imp
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 Fo
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/pipermail/gcc-patches/2022-Februa
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=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=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=102146
--- Comment #9 from HaoChen Gui ---
Could you backport the patch to GCC11? Thanks.
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=103605
HaoChen Gui changed:
What|Removed |Added
CC||guihaoc at gcc dot gnu.org
--- Comment #2
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, 3.0
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
Componen
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
--- 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 #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 #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=100694
HaoChen Gui changed:
What|Removed |Added
CC||guihaoc at gcc dot gnu.org
--- Comment #5
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=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
> -B/home/sawdey/work/g
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 the
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=103498
HaoChen Gui changed:
What|Removed |Added
CC||guihaoc at gcc dot gnu.org
--- Comment #1
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=103109
HaoChen Gui changed:
What|Removed |Added
Resolution|--- |FIXED
CC|
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=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=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 pa
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=93127
HaoChen Gui changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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=103197
HaoChen Gui changed:
What|Removed |Added
CC||guihaoc at gcc dot gnu.org
--- Comment #1
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=103124
HaoChen Gui changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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=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
--- 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. I
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 #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
--- 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=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 #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 a/gcc/co
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=100868
HaoChen Gui changed:
What|Removed |Added
Resolution|--- |FIXED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100736
HaoChen Gui changed:
What|Removed |Added
CC||guihaoc at gcc dot gnu.org
--- Comment #2
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=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=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
Comp
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 trunk
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=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: gcc.target/pow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102169
HaoChen Gui changed:
What|Removed |Added
CC||guihaoc at gcc dot gnu.org
--- Comment #4
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=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
--- 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=100866
HaoChen Gui changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
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=105414
HaoChen Gui changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
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=103316
HaoChen Gui changed:
What|Removed |Added
Status|NEW |RESOLVED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101865
--- Comment #4 from HaoChen Gui ---
Codes in rs6000-cpus.def,
#define ISA_2_7_MASKS_SERVER(ISA_2_6_MASKS_SERVER \
| OPTION_MASK_P8_VECTOR\
|
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?
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 user
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=103605
HaoChen Gui changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
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=106769
HaoChen Gui changed:
What|Removed |Added
Status|ASSIGNED|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=108728
HaoChen Gui changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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=108812
HaoChen Gui changed:
What|Removed |Added
Resolution|--- |FIXED
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=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=88558
HaoChen Gui changed:
What|Removed |Added
CC||guihaoc at gcc dot gnu.org
Assig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116030
--- Comment #2 from HaoChen Gui ---
Peter, the root cause of the issue is the combine is done at ira pass. There is
no split pass after ira and reload. So the split has to been done after reload,
which causes the ICE. Jeff (Jiufu) is working on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54063
HaoChen Gui changed:
What|Removed |Added
CC||guihaoc at gcc dot gnu.org
--- Comment #26
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: ta
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);
vecto
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 CC
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=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=111449
HaoChen Gui changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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 f
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 f
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=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
Sever
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
HaoChen Gui changed:
What|Removed |Added
CC||guihaoc at gcc dot gnu.org
--- Comment #2
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&action=edit
ira dump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106769
HaoChen Gui changed:
What|Removed |Added
Last reconfirmed||2023-05-31
Status|UNCONFIRMED
1 - 100 of 109 matches
Mail list logo
