https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63177
Peter Bergner changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
at gcc dot gnu.org |bergner at gcc dot
gnu.org
--- Comment #5 from Peter Bergner ---
Hmmm, it must be the extra use of rs6000_offsettable_memref_p() that disables
the update forms. I'll have a look.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85755
Peter Bergner changed:
What|Removed |Added
URL|https://gcc.gnu.org/ml/gcc- |https://gcc.gnu.org/ml/gcc-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85755
--- Comment #7 from Peter Bergner ---
Author: bergner
Date: Fri Jun 8 17:17:45 2018
New Revision: 261340
URL: https://gcc.gnu.org/viewcvs?rev=261340&root=gcc&view=rev
Log:
gcc/
PR target/85755
* config/rs6000/rs6000.c (mem_opera
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85755
--- Comment #10 from Peter Bergner ---
Author: bergner
Date: Mon Jun 11 18:23:28 2018
New Revision: 261441
URL: https://gcc.gnu.org/viewcvs?rev=261441&root=gcc&view=rev
Log:
gcc/
Backport from mainline
2018-06-08 Peter Bergner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85755
--- Comment #11 from Peter Bergner ---
Author: bergner
Date: Mon Jun 11 18:25:37 2018
New Revision: 261442
URL: https://gcc.gnu.org/viewcvs?rev=261442&root=gcc&view=rev
Log:
gcc/
Backport from mainline
2018-06-08 Peter Bergner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85755
Peter Bergner changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86222
Peter Bergner changed:
What|Removed |Added
CC||acsawdey at gcc dot gnu.org
--- Comment
erity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: bergner at gcc dot gnu.org
Target Milestone: ---
We don't mangle __ieee128 correctly when compiling with -mlong-double-64
-mabi=ieeelongdouble. We should alw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86285
--- Comment #1 from Peter Bergner ---
Setting a breakpoint at rs6000_mangle_type(tree type), I'm seeing:
(gdb) p type
$23 = (const_tree) 0x758413b0
(gdb) ptree type
constant 64>
unit-size constant 8>
align:64 warn_if_not_align:0 s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86285
--- Comment #2 from Peter Bergner ---
When we compile using -mlong-double-64 -mabi=ibmlongdouble, we get what I'd
expect:
(gdb) ptree type
constant 128>
unit-size constant 16>
align:128 warn_if_not_align:0 symtab:0 alias-set -1 canoni
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: bergner at gcc dot gnu.org
Target Milestone: ---
bergner@pike:~/gcc/BUGS/IEEE128$ cat divkc.i
typedef __complex float __cfloat128 __attribute__((mode(KC)));
__cfloat128
divide
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86324
--- Comment #1 from Peter Bergner ---
I thought I had Segher's PR82625 patch applied but didn't. I'm rebuilding with
that fix to see if this still FAILs with that fix or not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86324
--- Comment #2 from Peter Bergner ---
Ok, it still fails even with Segher's patch. I'll try and track things down.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86324
--- Comment #3 from Peter Bergner ---
And a complementary bug for a __ibm128 complex type when using
-mabi=ibmlongdouble:
bergner@pike:~/gcc/BUGS/PR86324$ cat divic.i
typedef __complex float __cfloat128 __attribute__((mode(IC)));
__cfloat128
di
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86324
--- Comment #4 from Peter Bergner ---
So talking with Joseph on IRC, he said if K[FC]mode or I[FC}mode are the same
as long double, then we should translate the mode attribute in
c-attribs.c:handle_mode_attribute() to return the T[FC]mode instead
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86324
Peter Bergner changed:
What|Removed |Added
Target Milestone|--- |8.2
--- Comment #5 from Peter Bergner -
||2018-06-28
Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot
gnu.org
Ever confirmed|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91050
--- Comment #15 from Peter Bergner ---
Author: bergner
Date: Wed Jul 31 17:18:40 2019
New Revision: 273941
URL: https://gcc.gnu.org/viewcvs?rev=273941&root=gcc&view=rev
Log:
PR target/91050
* config/rs6000/rs6000.opt (mdejagnu-cp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91050
Peter Bergner changed:
What|Removed |Added
Status|NEW |RESOLVED
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70010
Peter Bergner changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70010
Peter Bergner changed:
What|Removed |Added
Status|NEW |RESOLVED
URL|https://gcc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83387
Peter Bergner changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83387
--- Comment #3 from Peter Bergner ---
(In reply to Sebastian Huber from comment #2)
> Is -msoft-float supported on 64-bit PowerPC? It is not important for us. I
> just copied the 32-bit multilibs without much thought.
It is used by the linux ker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83387
--- Comment #5 from Peter Bergner ---
(In reply to Sebastian Huber from comment #4)
> If I remove the -msoft-float, the two example source files compile
> (-mno-altivec seems to cause no harm).
Well the first question, is do you really need to u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80210
--- Comment #20 from Peter Bergner ---
Author: bergner
Date: Thu Dec 14 17:43:32 2017
New Revision: 255655
URL: https://gcc.gnu.org/viewcvs?rev=255655&root=gcc&view=rev
Log:
gcc/
Backport from mainline
2017-10-02 Peter Bergner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80210
--- Comment #21 from Peter Bergner ---
Author: bergner
Date: Fri Dec 15 03:41:16 2017
New Revision: 255671
URL: https://gcc.gnu.org/viewcvs?rev=255671&root=gcc&view=rev
Log:
gcc/
Backport from mainline
2017-10-02 Peter Bergner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80210
Peter Bergner changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #22 from Peter Bergne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83387
Peter Bergner changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83387
--- Comment #9 from Peter Bergner ---
...and the parallel with the FP reg use (33 and 34) come from:
expand_call():
valreg = hard_function_value (build_pointer_type (rettype),
fndecl, NULL, (pass == 0));
har
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83387
--- Comment #13 from Peter Bergner ---
(In reply to Sebastian Huber from comment #12)
> (In reply to Peter Bergner from comment #9)
> [...]
> > Here, you can see that on ELFv2, we always assume HW FP regs are avialable,
> > because we're forcing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83387
Peter Bergner changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51513
Peter Bergner changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #11 from Peter Bergne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83387
--- Comment #18 from Peter Bergner ---
Author: bergner
Date: Thu Jan 4 14:36:35 2018
New Revision: 256250
URL: https://gcc.gnu.org/viewcvs?rev=256250&root=gcc&view=rev
Log:
PR target/83387
* config/rs6000/rs6000.c (rs6000_discov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83387
Peter Bergner changed:
What|Removed |Added
Status|NEW |ASSIGNED
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83387
Peter Bergner changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83387
Peter Bergner changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #20 from Peter Bergne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83399
Peter Bergner changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83399
--- Comment #6 from Peter Bergner ---
A better test case which "looks" valid to me and still ICEs with -O1
-mabi=elfv2 -S (on LE):
typedef __attribute__((altivec(vector__))) int v4si_t;
int
foo (void)
{
v4si_t a, u, v, y;
u = __builtin_altiv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83399
--- Comment #8 from Peter Bergner ---
Created attachment 43064
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43064&action=edit
Proposed fix
I'm testing the attached patch.
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: bergner at gcc dot gnu.org
Target Milestone: ---
Running an "old" gcc with "-mcpu=native" that's doesn't have basic support for
the processor it is
|bergner at gcc dot
gnu.org
--- Comment #10 from Peter Bergner ---
Patch submitted. I'm also changing the keyword to ice-on-valid-code, since I
think the minimal test case in Comment 6 is valid, unlike the original test
case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83399
--- Comment #12 from Peter Bergner ---
(In reply to Segher Boessenkool from comment #11)
> It is not valid: (void *)&a - 32 does not point inside a (or just behind
> it).
>
> Perhaps you can make it valid using uintptr_t. Either way: should n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83743
--- Comment #3 from Peter Bergner ---
(In reply to Segher Boessenkool from comment #2)
> The driver asks the kernel, and the kernel knows. It's just a string.
Correct, the kernel passes a string to the driver and the driver blindly uses
it as i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83399
--- Comment #13 from Peter Bergner ---
Author: bergner
Date: Wed Jan 10 20:49:36 2018
New Revision: 256453
URL: https://gcc.gnu.org/viewcvs?rev=256453&root=gcc&view=rev
Log:
gcc/
PR target/83399
* config/rs6000/rs6000.c (print_op
||2018-01-10
Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #5 from Peter Bergner ---
Going through the kernel cputable.c file and comparing it to rs6000-cpus.def, I
think the name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83399
--- Comment #14 from Peter Bergner ---
Author: bergner
Date: Tue Jan 23 18:18:25 2018
New Revision: 256993
URL: https://gcc.gnu.org/viewcvs?rev=256993&root=gcc&view=rev
Log:
gcc/
Back port from mainline
2018-01-10 Peter Bergner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56010
--- Comment #6 from Peter Bergner ---
Created attachment 43227
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43227&action=edit
Proposed patch
I'm testing the attached patch, which should also fix PR83743. Can those of
you that have hit t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56010
Peter Bergner changed:
What|Removed |Added
Attachment #43227|0 |1
is obsolete|
||bergner at gcc dot gnu.org
Resolution|--- |DUPLICATE
--- Comment #1 from Peter Bergner ---
This is being tracked in PR83758.
*** This bug has been marked as a duplicate of bug 83758 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83758
Peter Bergner changed:
What|Removed |Added
CC||doko at gcc dot gnu.org
--- Comment #20
at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #5 from Peter Bergner ---
Patch submitted to fix this and PR56010.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83399
--- Comment #15 from Peter Bergner ---
Author: bergner
Date: Thu Jan 25 16:50:08 2018
New Revision: 257058
URL: https://gcc.gnu.org/viewcvs?rev=257058&root=gcc&view=rev
Log:
gcc/
Back port from mainline
2018-01-10 Peter Bergner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83399
Peter Bergner changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83399
Peter Bergner changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #17 from Peter Bergne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56010
--- Comment #9 from Peter Bergner ---
(In reply to Segher Boessenkool from comment #8)
>> This kernel AT_PLATFORM name should strip the '+' off:
>> .platform = "power7+", -> "power7"
>
> We probably should have a -mcpu=power7+, we have power5+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83926
Peter Bergner changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83926
--- Comment #9 from Peter Bergner ---
So the problem is that the splitter for vsx_div_v2di unconditionally calls
gen_divdi3() , which assumes we have a 64-bit integer HW div insn. If you do a
scalar 64-bit div, we notice we don't have that HW in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83926
--- Comment #10 from Peter Bergner ---
A similar error happens with the __builtin_vsx_udiv_2di() that happens with
__builtin_vsx_div_2di(), which shows the splitter for vsx_udiv_v2di calling
gen_udivdi3() directly:
[bergner@makalu-lp1 PR83926]$
at gcc dot gnu.org |bergner at gcc dot
gnu.org
--- Comment #11 from Peter Bergner ---
I have two patches 1) modify gen_[u]divdi3() to handle calling the lib func
__[u]divdi3 when needed and 2) Call expand_divmod() in the vsx_[u]div_v2di
splitters. I'm evaluating which generates better code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56010
--- Comment #11 from Peter Bergner ---
Author: bergner
Date: Thu Feb 1 18:26:51 2018
New Revision: 257305
URL: https://gcc.gnu.org/viewcvs?rev=257305&root=gcc&view=rev
Log:
PR target/56010
PR target/83743
* config/rs6000
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83743
--- Comment #6 from Peter Bergner ---
Author: bergner
Date: Thu Feb 1 18:26:51 2018
New Revision: 257305
URL: https://gcc.gnu.org/viewcvs?rev=257305&root=gcc&view=rev
Log:
PR target/56010
PR target/83743
* config/rs6000/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56010
Peter Bergner changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
URL|https://gcc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83743
Peter Bergner changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
URL|https://gcc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83743
--- Comment #8 from Peter Bergner ---
Author: bergner
Date: Mon Feb 5 19:17:37 2018
New Revision: 257392
URL: https://gcc.gnu.org/viewcvs?rev=257392&root=gcc&view=rev
Log:
Back port from mainline
2018-02-01 Peter Bergner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56010
--- Comment #13 from Peter Bergner ---
Author: bergner
Date: Mon Feb 5 19:17:37 2018
New Revision: 257392
URL: https://gcc.gnu.org/viewcvs?rev=257392&root=gcc&view=rev
Log:
Back port from mainline
2018-02-01 Peter Bergner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83743
Peter Bergner changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #9 from Peter Bergner
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: bergner at gcc dot gnu.org
Target Milestone: ---
Calling the __builtin_vec_sld() builtin with an invalid 3rd argument (should be
an int), we end up generating invalid gimple and we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84220
Peter Bergner changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83926
Peter Bergner changed:
What|Removed |Added
Keywords|ra |
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84227
Peter Bergner changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org
--- Comment
||bergner at gcc dot gnu.org
--- Comment #2 from Peter Bergner ---
Confirmed.
||2018-02-08
CC||bergner at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from Peter Bergner ---
This is a test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81143
--- Comment #2 from Peter Bergner ---
Author: bergner
Date: Thu Feb 8 20:40:32 2018
New Revision: 257504
URL: https://gcc.gnu.org/viewcvs?rev=257504&root=gcc&view=rev
Log:
PR target/81143
* gcc.target/powerpc/pr79799-2.c: Use __
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81143
Peter Bergner changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81143
Peter Bergner changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #4 from Peter Bergner
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: bergner at gcc dot gnu.org
Target Milestone: ---
The following test case shows poor code generation on powerpc64le-linux:
bergner@pike:~/gcc/BUGS/PR88845$ cat struct.i
struct s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89310
--- Comment #1 from Peter Bergner ---
Before combine, we have the following rtl:
(insn # # # 2 (set (reg/v:DI 122 [ argD.2825 ])
(reg:DI 3 3 [ argD.2825 ])) "struct.i":8:1# {*movdi_internal64}
(expr_list:REG_DEAD (reg:DI 3 3 [ argD.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89313
--- Comment #2 from Peter Bergner ---
I'll have a look.
at gcc dot gnu.org |bergner at gcc dot
gnu.org
--- Comment #3 from Peter Bergner ---
This is not a bug in my code, it's just that before my commit, we did not catch
the illegal asm constraint usage and LRA "fixed" up the code without
complaining, but given it generated code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89313
--- Comment #4 from Peter Bergner ---
Actually, the error message:
z1.c:7:1: error: unable to generate reloads for impossible constraints:
is a new LRA test that I added as part of one of my other commits that is
catching the illegal regist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89313
--- Comment #5 from Peter Bergner ---
I'm testing a patch that gives a better error message and eliminates the ICE:
[bergner@dagger1 PR89313]$ cat pr89313.i
long f;
long g (void)
{
register long z asm ("rax");
asm ("foo %0, %1, %2" : "=&r"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89313
Peter Bergner changed:
What|Removed |Added
Keywords|ice-on-invalid-code |ice-on-valid-code
Target|x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88845
--- Comment #4 from Peter Bergner ---
Author: bergner
Date: Wed Mar 6 15:36:43 2019
New Revision: 269428
URL: https://gcc.gnu.org/viewcvs?rev=269428&root=gcc&view=rev
Log:
gcc/
PR rtl-optimization/88845
* config/rs6000/rs6000.c
||https://gcc.gnu.org/ml/gcc-
||patches/2019-03/msg00148.ht
||ml
Resolution|--- |FIXED
Assignee|unassigned at gcc dot gnu.org |bergner at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89313
--- Comment #7 from Peter Bergner ---
Author: bergner
Date: Wed Mar 27 16:59:15 2019
New Revision: 269969
URL: https://gcc.gnu.org/viewcvs?rev=269969&root=gcc&view=rev
Log:
gcc/
PR rtl-optimization/89313
* function.c (matching_co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89313
Peter Bergner changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89853
--- Comment #1 from Peter Bergner ---
Cut and paste error? The two data sets look the same to me...or am I missing
something?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89853
--- Comment #3 from Peter Bergner ---
I don't have access to that type of machine and honestly don't know the ISA
well enough to know the differences between what runs well and what doesn't
just by looking at the code. Can you point out some cod
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89853
--- Comment #5 from Peter Bergner ---
(In reply to Martin Liška from comment #4)
> Just for the record, my Ryzen machine periodic tester probably improved due
> to the revision:
> https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=158.377.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89853
--- Comment #7 from Peter Bergner ---
(In reply to Martin Jambor from comment #6)
> Hi, the assembly of the most affected function does not change at all, just
> its offset (is 0x10 bytes bigger). Aligning the loops in the function a bit
> more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89865
Peter Bergner changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #14 from Peter Bergner ---
(In reply to Segher Boessenkool from comment #12)
> Disposition:
> 0:r111 l0 03:r112 l0 41:r113 l0 22:r114 l0 3
> 5:r116 l0 44:r117 l0 0
>
> If r116 had been
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #18 from Peter Bergner ---
(In reply to Segher Boessenkool from comment #15)
> Popping a5(r116,l0) -- assign reg 3
> Popping a3(r112,l0) -- assign reg 4
> Popping a2(r114,l0) -- assign reg 3
> Popping a0(r11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #22 from Peter Bergner ---
(In reply to Wilco from comment #21)
> (In reply to Vladimir Makarov from comment #20)
>> The question is why p116 conflicts with hr0. Before RA we have
>
> That's a bug since register copies should not cr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #24 from Peter Bergner ---
So improve_allocation() initially looks at using r0, but disregards it because
check_hard_reg_p() returns false for r0, and that is because we fail this test:
/* Checking only profitable hard regs. */
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #26 from Peter Bergner ---
(In reply to Vladimir Makarov from comment #25)
> (In reply to Peter Bergner from comment #24)
>> I don't know why r0 isn't in profitable_regs for pseudo 116.
>
> Profitable regs there contain also conflic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #28 from Peter Bergner ---
Vlad, in looking at add_insn_allocno_copies(), it looks like it relies on
seeing REG_DEAD notes on whether to record a copy/shuffle that should be
handled. Shouldn't we instead be looking at whether the sou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #29 from Peter Bergner ---
(In reply to Segher Boessenkool from comment #27)
> > Note: I'm assuming we're missing a \n after p116's empty conflicts above?
>
> The code is
Right. I already whipped up a patch that gives me:
;; a5(r1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #32 from Peter Bergner ---
(In reply to Peter Bergner from comment #26)
> (In reply to Vladimir Makarov from comment #25)
> > (In reply to Peter Bergner from comment #24)
> >> I don't know why r0 isn't in profitable_regs for pseudo 11
301 - 400 of 1504 matches
Mail list logo
