* [Bug target/67383] reload_cse_simplify_operands fails on ARMV7-M
[not found] <bug-67383-4@http.gcc.gnu.org/bugzilla/>
@ 2015-08-28 13:13 ` david.cock at inf dot ethz.ch
2015-08-28 13:16 ` david.cock at inf dot ethz.ch
` (4 subsequent siblings)
5 siblings, 0 replies; 6+ messages in thread
From: david.cock at inf dot ethz.ch @ 2015-08-28 13:13 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67383
--- Comment #1 from david.cock at inf dot ethz.ch ---
Fails in exactly the same manner on the following versions:
arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.8.4 20140725
(release) [ARM/embedded-4_8-branch revision 213147]
arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.9.3 20150529
(release) [ARM/embedded-4_9-branch revision 224288]
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug target/67383] reload_cse_simplify_operands fails on ARMV7-M
[not found] <bug-67383-4@http.gcc.gnu.org/bugzilla/>
2015-08-28 13:13 ` [Bug target/67383] reload_cse_simplify_operands fails on ARMV7-M david.cock at inf dot ethz.ch
@ 2015-08-28 13:16 ` david.cock at inf dot ethz.ch
2015-08-28 14:55 ` rearnsha at gcc dot gnu.org
` (3 subsequent siblings)
5 siblings, 0 replies; 6+ messages in thread
From: david.cock at inf dot ethz.ch @ 2015-08-28 13:16 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67383
--- Comment #2 from david.cock at inf dot ethz.ch ---
The problem does not occur in:
arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.6.2 20121016
(release) [ARM/embedded-4_6-branch revision 192487]
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug target/67383] reload_cse_simplify_operands fails on ARMV7-M
[not found] <bug-67383-4@http.gcc.gnu.org/bugzilla/>
2015-08-28 13:13 ` [Bug target/67383] reload_cse_simplify_operands fails on ARMV7-M david.cock at inf dot ethz.ch
2015-08-28 13:16 ` david.cock at inf dot ethz.ch
@ 2015-08-28 14:55 ` rearnsha at gcc dot gnu.org
2015-10-08 21:16 ` vmakarov at gcc dot gnu.org
` (2 subsequent siblings)
5 siblings, 0 replies; 6+ messages in thread
From: rearnsha at gcc dot gnu.org @ 2015-08-28 14:55 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67383
Richard Earnshaw <rearnsha at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2015-08-28
CC| |vmakarov at redhat dot com
Ever confirmed|0 |1
--- Comment #3 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
Confirmed.
Something really odd going on here. The two input reload registers partially
overlap!
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug target/67383] reload_cse_simplify_operands fails on ARMV7-M
[not found] <bug-67383-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2015-08-28 14:55 ` rearnsha at gcc dot gnu.org
@ 2015-10-08 21:16 ` vmakarov at gcc dot gnu.org
2015-10-14 17:26 ` renlin at gcc dot gnu.org
2015-10-16 8:14 ` ramana at gcc dot gnu.org
5 siblings, 0 replies; 6+ messages in thread
From: vmakarov at gcc dot gnu.org @ 2015-10-08 21:16 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67383
Vladimir Makarov <vmakarov at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |vmakarov at gcc dot gnu.org
--- Comment #4 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
I've tried to reproduce it on gcc-4.9 branch as of today but failed. The
problem with constraints and overlapped hard regs was probably fixed by
backported patches.
Still I have another problem:
../lib/mm/mm.c: In function ‘chunk_node’:
../lib/mm/mm.c:430:1: internal compiler error: in assign_by_spills, at
lra-assigns.c:1357
0x853dd5 assign_by_spills
/home/cygnus/vmakarov/build1/gcc-4.9-branch/gcc/gcc/lra-assigns.c:1357
0x854617 lra_assign()
/home/cygnus/vmakarov/build1/gcc-4.9-branch/gcc/gcc/lra-assigns.c:1503
0x84de9c lra(_IO_FILE*)
/home/cygnus/vmakarov/build1/gcc-4.9-branch/gcc/gcc/lra.c:2388
0x80ca16 do_reload
/home/cygnus/vmakarov/build1/gcc-4.9-branch/gcc/gcc/ira.c:5474
0x80ca16 rest_of_handle_reload
/home/cygnus/vmakarov/build1/gcc-4.9-branch/gcc/gcc/ira.c:5615
0x80ca16 execute
/home/cygnus/vmakarov/build1/gcc-4.9-branch/gcc/gcc/ira.c:5644
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
The problem is in assigning a hard reg to reload pseudo 442 for insns
Choosing alt 0 in insn 153: (0) =&r (1) %0 (2) r {*arm_adddi3}
Creating newreg=441, assigning class GENERAL_REGS to r441
Creating newreg=442 from oldreg=268, assigning class GENERAL_REGS to r442
153: {r441:DI=r441:DI+r442:DI;clobber cc:CC;}
REG_DEAD r268:DI
REG_UNUSED cc:CC
REG_EQUIV [sp:SI+0x10]
Inserting insn reload before:
642: r441:DI=[sp:SI+0x8]
644: r442:DI=r268:DI
Inserting insn reload after:
643: [sp:SI+0x10]=r441:DI
We canot use hard reg 0, 1, 2 as they live through insn 153:
...
153: {r272:DI=r268:DI+r159:DI;clobber cc:CC;}
REG_DEAD r268:DI
REG_UNUSED cc:CC
REG_EQUIV [sp:SI+0x10]
...
159: call [`debug_printf'] argc:0x20
REG_DEAD r1:SI
REG_DEAD r0:SI
REG_DEAD r2:DI
Hard reg 7 (FP), 9 (thread), 10 (pic), 13 (sp), 15 (pc) are fixed. So
we have only one hole for DI value containing 2 regs (4, 5) and pair
(4,5) is assigned to 441 and there are no regs for 442.
By the way, reload pass also gives up for this case:
../lib/mm/mm.c:430:1: error: unable to find a register to spill in class
‘GENERAL_REGS’
../lib/mm/mm.c:430:1: error: this is the insn:
(insn 153 136 139 10 (parallel [
(set (reg:DI 272 [ D.9125 ])
(plus:DI (reg:DI 268 [ D.9125 ])
(reg:DI 159 [ D.9125 ])))
(clobber (reg:CC 100 cc))
]) ../lib/mm/mm.c:349 2 {*arm_adddi3}
(expr_list:REG_DEAD (reg:DI 268 [ D.9125 ])
(expr_list:REG_UNUSED (reg:CC 100 cc)
(expr_list:REG_EQUIV (mem:DI (plus:SI (reg/f:SI 13 sp)
(const_int 16 [0x10])) [0 S8 A64])
(nil)))))
Interesting enough that LRA on the trunk has no such problem but I had no time
to figure why.
>From gcc-bugs-return-499056-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Oct 08 21:19:57 2015
Return-Path: <gcc-bugs-return-499056-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 120492 invoked by alias); 8 Oct 2015 21:19:57 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 115846 invoked by uid 48); 8 Oct 2015 21:19:53 -0000
From: "ryan.burn at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/67901] New: [concepts] overloading bug when considered more specialized vs more constrained
Date: Thu, 08 Oct 2015 21:19:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 6.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ryan.burn at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone
Message-ID: <bug-67901-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-10/txt/msg00611.txt.bz2
Content-length: 3311
https://gcc.gnu.org/bugzilla/show_bug.cgi?idg901
Bug ID: 67901
Summary: [concepts] overloading bug when considered more
specialized vs more constrained
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ryan.burn at gmail dot com
Target Milestone: ---
I think the below code should compile.
>From section 14.6.6.2:
Partial ordering selects which of two function templates is more specialized
than the other by transforming each template in turn (see next paragraph) and
performing template argument de- duction using the function type. The deduction
process determines whether one of the templates is more specialized than the
other. If so, the more specialized template is the one chosen by the partial
ordering process. If both deductions succeed, the partial ordering selects the
more
constrained template as described by the rules in 14.10.3.
And since the first version of apply_odd_arguments is more specialized, it
should be selected before considering which version is more constrained.
/////////////////////////////////////////////////////////////////////
template <class Functor, class ArgumentFirst, class ArgumentSecond>
//requires true // works if uncommented
decltype(auto) apply_odd_arguments(const Functor& functor,
ArgumentFirst argument_first,
ArgumentSecond argument_second) {
return functor(argument_first);
}
template <class Functor, class ArgumentFirst, class ArgumentSecond,
class... ArgumentsRest>
requires sizeof...(ArgumentsRest) % 2 == 0
decltype(auto) apply_odd_arguments(const Functor& functor,
ArgumentFirst argument_first,
ArgumentSecond argument_second,
ArgumentsRest... arguments_rest) {
return apply_odd_arguments([&](auto... arguments) {
return functor(argument_first, arguments...);
}, arguments_rest...);
}
int main() {
auto f = [](int i1, int i2) {
return i1+i2;
};
apply_odd_arguments(f, 1, 2, 3, 4);
return 0;
}
/////////////////////////////////////////////////////////////////////
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug target/67383] reload_cse_simplify_operands fails on ARMV7-M
[not found] <bug-67383-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2015-10-08 21:16 ` vmakarov at gcc dot gnu.org
@ 2015-10-14 17:26 ` renlin at gcc dot gnu.org
2015-10-16 8:14 ` ramana at gcc dot gnu.org
5 siblings, 0 replies; 6+ messages in thread
From: renlin at gcc dot gnu.org @ 2015-10-14 17:26 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67383
renlin at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |renlin at gcc dot gnu.org
--- Comment #5 from renlin at gcc dot gnu.org ---
(In reply to Vladimir Makarov from comment #4)
> I've tried to reproduce it on gcc-4.9 branch as of today but failed. The
> problem with constraints and overlapped hard regs was probably fixed by
> backported patches.
>
> Still I have another problem:
>
> ../lib/mm/mm.c: In function ‘chunk_node’:
> ../lib/mm/mm.c:430:1: internal compiler error: in assign_by_spills, at
> lra-assigns.c:1357
> 0x853dd5 assign_by_spills
>
> /home/cygnus/vmakarov/build1/gcc-4.9-branch/gcc/gcc/lra-assigns.c:1357
> 0x854617 lra_assign()
>
> /home/cygnus/vmakarov/build1/gcc-4.9-branch/gcc/gcc/lra-assigns.c:1503
> 0x84de9c lra(_IO_FILE*)
> /home/cygnus/vmakarov/build1/gcc-4.9-branch/gcc/gcc/lra.c:2388
> 0x80ca16 do_reload
> /home/cygnus/vmakarov/build1/gcc-4.9-branch/gcc/gcc/ira.c:5474
> 0x80ca16 rest_of_handle_reload
> /home/cygnus/vmakarov/build1/gcc-4.9-branch/gcc/gcc/ira.c:5615
> 0x80ca16 execute
> /home/cygnus/vmakarov/build1/gcc-4.9-branch/gcc/gcc/ira.c:5644
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See <http://gcc.gnu.org/bugs.html> for instructions.
>
> The problem is in assigning a hard reg to reload pseudo 442 for insns
>
> Choosing alt 0 in insn 153: (0) =&r (1) %0 (2) r {*arm_adddi3}
> Creating newreg=441, assigning class GENERAL_REGS to r441
> Creating newreg=442 from oldreg=268, assigning class GENERAL_REGS to
> r442
> 153: {r441:DI=r441:DI+r442:DI;clobber cc:CC;}
> REG_DEAD r268:DI
> REG_UNUSED cc:CC
> REG_EQUIV [sp:SI+0x10]
> Inserting insn reload before:
> 642: r441:DI=[sp:SI+0x8]
> 644: r442:DI=r268:DI
> Inserting insn reload after:
> 643: [sp:SI+0x10]=r441:DI
>
> We canot use hard reg 0, 1, 2 as they live through insn 153:
>
> ...
> 153: {r272:DI=r268:DI+r159:DI;clobber cc:CC;}
> REG_DEAD r268:DI
> REG_UNUSED cc:CC
> REG_EQUIV [sp:SI+0x10]
> ...
> 159: call [`debug_printf'] argc:0x20
> REG_DEAD r1:SI
> REG_DEAD r0:SI
> REG_DEAD r2:DI
>
> Hard reg 7 (FP), 9 (thread), 10 (pic), 13 (sp), 15 (pc) are fixed. So
> we have only one hole for DI value containing 2 regs (4, 5) and pair
> (4,5) is assigned to 441 and there are no regs for 442.
In this particular case, hard register 12 is free, and hard register 11 can be
spilled to accommodate this DImode pseudo register.
However, the target hook HARD_REGNO_MODE_OK rejects register pairs start from
odd number (11 in this case.) So find_hard_regno_for() failed.
I have found r209615 relaxes the target hook. In thumb2 mode, any register pair
is allowed. I have verified, it fix this ICE.
I will do a full regression test first, If no new issues, I will backport it to
branch 4.9
>From gcc-bugs-return-499564-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Oct 14 17:29:38 2015
Return-Path: <gcc-bugs-return-499564-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 76511 invoked by alias); 14 Oct 2015 17:29:38 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 76482 invoked by uid 48); 14 Oct 2015 17:29:34 -0000
From: "wmi at google dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/67443] [5/6 regression] DSE removes required store instruction
Date: Wed, 14 Oct 2015 17:29:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Version: 5.2.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: wmi at google dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.3
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-67443-4-LNkpjn3va7@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-67443-4@http.gcc.gnu.org/bugzilla/>
References: <bug-67443-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-10/txt/msg01119.txt.bz2
Content-length: 1288
https://gcc.gnu.org/bugzilla/show_bug.cgi?idg443
--- Comment #6 from wmi at google dot com ---
(In reply to Dominik Vogt from comment #3)
> I think the Rtl in comment 1 ist correct. Note that "i" is stored at
> 0x00000000.xx000000 and "j" is stored at 0x00000000.000000xx. That is the
> reason for the rather confusing mask in insn 9. Your test program compiles
> and runs fine for me.
I am not familiar with s390 assembly. please correct me if I am wrong:
This is the assembly generated for my testcase:
.globl _Z3fooP1A
.type _Z3fooP1A, @function
_Z3fooP1A:
.LFB0:
larl %r5,.L3
mvi 0(%r2),3 // move 0x00000000.00000003 to 0(%r2)
l %r1,.L4-.L3(%r5) // load 0xff000000 to %r1
n %r1,0(%r2) // %r1 = %r1 & 0(%r2) 0x00000000.00000000
oill %r1,5 // %r1 = %r1 | 5 = 0x00000000.00000005
st %r1,0(%r2) // store 0x00000000.00000005 to 0(%r2)
br %r14
.section .rodata
.align 8
.L3:
.L4:
.long -16777216
.align 2
.previous
According to the asm sequence above, the result of a should be:
0x00000000.00000005, but the correct result should be 0x00000000.03000005,
right?
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug target/67383] reload_cse_simplify_operands fails on ARMV7-M
[not found] <bug-67383-4@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2015-10-14 17:26 ` renlin at gcc dot gnu.org
@ 2015-10-16 8:14 ` ramana at gcc dot gnu.org
5 siblings, 0 replies; 6+ messages in thread
From: ramana at gcc dot gnu.org @ 2015-10-16 8:14 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67383
Ramana Radhakrishnan <ramana at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ramana at gcc dot gnu.org
--- Comment #6 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
Created attachment 36524
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36524&action=edit
reduced testcase
Here's a reduced testcase.
^ permalink raw reply [flat|nested] 6+ messages in thread