public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug target/60606] New: ICE [ARM] error: insn does not satisfy its constraints
@ 2014-03-21 8:09 d.salikhov at samsung dot com
2014-03-21 9:10 ` [Bug target/60606] " y.gribov at samsung dot com
` (8 more replies)
0 siblings, 9 replies; 10+ messages in thread
From: d.salikhov at samsung dot com @ 2014-03-21 8:09 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60606
Bug ID: 60606
Summary: ICE [ARM] error: insn does not satisfy its constraints
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: d.salikhov at samsung dot com
Created attachment 32414
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32414&action=edit
Code sample reproducing the bug
Reproduced on 4.8.0+ and on trunk.
*How to reproduce:*
Compile sample code in attachment by "arm-v7a9-linux-gnueabi-gcc -S ice.c"
*Compiler output:*
ice.c: In function 'alpha':
ice.c:5:1: error: insn does not satisfy its constraints:
}
^
(insn 5 2 6 (set (reg:SI 3 r3 [orig:110 pc.0 ] [110])
(reg/v:SI 15 pc [ pc ])) ice.c:4 641 {*arm_movsi_vfp}
(nil))
ice.c:5:1: internal compiler error: in note_invalid_constants, at
config/arm/arm.c:13693
0x83e1907 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/salikhov/work/toolchain_repos/ta_sdk/./gcc_experimental/gcc/rtl-error.c:109
0x83e1945 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/salikhov/work/toolchain_repos/ta_sdk/./gcc_experimental/gcc/rtl-error.c:120
0x85e4b49 note_invalid_constants
/home/salikhov/work/toolchain_repos/ta_sdk/./gcc_experimental/gcc/config/arm/arm.c:13693
0x85e4b49 arm_reorg
/home/salikhov/work/toolchain_repos/ta_sdk/./gcc_experimental/gcc/config/arm/arm.c:14031
0x83e17b8 rest_of_handle_machine_reorg
/home/salikhov/work/toolchain_repos/ta_sdk/./gcc_experimental/gcc/reorg.c:3939
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.
*Commit introducing the bug:*
git hash: bffbb863ff0f267b5111bfa95b42c99cd0474424
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@189350
138bc75d-0d04-0410-961f-82ee72b054a4
arm-v7a9-linux-gnueabi-gcc -v output:
Using built-in specs.
COLLECT_GCC=../../toolchain_repos/ta_sdk/cortex-cross-tools_exp/bin/arm-v7a9-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/home/salikhov/work/toolchain_repos/ta_sdk/cortex-cross-tools_exp/libexec/gcc/arm-v7a9-linux-gnueabi/4.8.3/lto-wrapper
Target: arm-v7a9-linux-gnueabi
Configured with:
/home/salikhov/work/toolchain_repos/ta_sdk/./gcc_experimental/configure
--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu
--target=arm-v7a9-linux-gnueabi --disable-libmudflap --disable-libssp
--with-gnu-as --with-gnu-ld --disable-lto --disable-nls
--prefix=/home/salikhov/work/toolchain_repos/ta_sdk/cortex-cross-tools_exp
--disable-shared --disable-threads --disable-libssp --disable-libquadmath
--without-headers --with-newlib --disable-decimal-float --disable-libffi
--enable-languages=c
--with-sysroot=/home/salikhov/work/toolchain_repos/ta_sdk/cortex-cross-tools_exp/arm-v7a9-linux-gnueabi/sys-root/
--with-gmp=/home/salikhov/work/toolchain_repos/ta_sdk/cortex-cross-tools_exp
--with-mpfr=/home/salikhov/work/toolchain_repos/ta_sdk/cortex-cross-tools_exp
--with-mpc=/home/salikhov/work/toolchain_repos/ta_sdk/cortex-cross-tools_exp
--disable-libgomp --disable-libatomic --with-interwork --with-cpu=cortex-a9
--with-arch=armv7-a --with-mode=arm --with-tune=cortex-a9 --with-fpu=vfpv3
--with-float=softfp
Thread model: single
gcc version 4.8.3 20140321 (prerelease) (GCC)
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug target/60606] ICE [ARM] error: insn does not satisfy its constraints
2014-03-21 8:09 [Bug target/60606] New: ICE [ARM] error: insn does not satisfy its constraints d.salikhov at samsung dot com
@ 2014-03-21 9:10 ` y.gribov at samsung dot com
2014-03-21 9:28 ` d.salikhov at samsung dot com
` (7 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: y.gribov at samsung dot com @ 2014-03-21 9:10 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60606
Yury Gribov <y.gribov at samsung dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |y.gribov at samsung dot com
--- Comment #1 from Yury Gribov <y.gribov at samsung dot com> ---
(In reply to D.Salikhov from comment #0)
> Compile sample code in attachment by "arm-v7a9-linux-gnueabi-gcc -S ice.c"
For my 4.9 with --enable-checking this fails earlier during LRA:
tmp.c: In function 'alpha':
tmp.c:5:1: internal compiler error: in check_rtl, at lra.c:2070
}
^
0x9a3545 check_rtl
/home/ygribov/src/gcc-master/gcc/lra.c:2070
0x9a3fc7 lra(_IO_FILE*)
/home/ygribov/src/gcc-master/gcc/lra.c:2449
0x952374 do_reload
/home/ygribov/src/gcc-master/gcc/ira.c:5457
0x9526c2 rest_of_handle_reload
/home/ygribov/src/gcc-master/gcc/ira.c:5598
0x95270c execute
/home/ygribov/src/gcc-master/gcc/ira.c:5627
The problematic RTL seems to be
(insn 5 2 6 2 (set (reg:SI 3 r3 [orig:110 D.4140 ] [110])
(reg/v:SI 15 pc [ pc ])) tmp.c:4 663 {*arm_movsi_vfp}
(nil))
Indeed movsi patterns in arm.md does not allow pc in RHS:
(define_insn "*arm_movsi_insn"
[(set (match_operand:SI 0 "nonimmediate_operand" "=rk,r,r,r,rk,m")
(match_operand:SI 1 "general_operand" "rk, I,K,j,mi,rk"))]
I'm not sure whether this is a bug or a feature. As a workaround you could
simply do
register unsigned long pc;
asm("mov %0, pc" : "=r"(pc));
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug target/60606] ICE [ARM] error: insn does not satisfy its constraints
2014-03-21 8:09 [Bug target/60606] New: ICE [ARM] error: insn does not satisfy its constraints d.salikhov at samsung dot com
2014-03-21 9:10 ` [Bug target/60606] " y.gribov at samsung dot com
@ 2014-03-21 9:28 ` d.salikhov at samsung dot com
2014-03-26 15:03 ` rearnsha at gcc dot gnu.org
` (6 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: d.salikhov at samsung dot com @ 2014-03-21 9:28 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60606
--- Comment #2 from D.Salikhov <d.salikhov at samsung dot com> ---
I suppose it is a bug as according to ARM Architecture Reference Manual,
A8.8.13 AND (immediate), pc is valid register for using in 'AND' instruction as
an input.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug target/60606] ICE [ARM] error: insn does not satisfy its constraints
2014-03-21 8:09 [Bug target/60606] New: ICE [ARM] error: insn does not satisfy its constraints d.salikhov at samsung dot com
2014-03-21 9:10 ` [Bug target/60606] " y.gribov at samsung dot com
2014-03-21 9:28 ` d.salikhov at samsung dot com
@ 2014-03-26 15:03 ` rearnsha at gcc dot gnu.org
2014-03-27 5:03 ` d.salikhov at samsung dot com
` (5 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: rearnsha at gcc dot gnu.org @ 2014-03-26 15:03 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60606
Richard Earnshaw <rearnsha at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |WONTFIX
--- Comment #3 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
> register unsigned long pc asm("pc");
I think it's a mistake to permit this sort of construct.
What does:
a = pc;
b = a+pc;
generate for b? Is it exactly twice a (the compiler doesn't see pc changing,
so is free to assume that it doesn't), just more than twice a (how much more?)
or just less than twice a (different scheduling)? What happens if the user
writes
pc = 3; // ???
The point is that while it might be valid to use pc in assembly instructions,
the constructs you get in high-level languages are essentially meaningless.
As has been pointed out, in the few cases where you really need to extract the
program counter you can write an inline assembly statement that explicitly
references the PC.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug target/60606] ICE [ARM] error: insn does not satisfy its constraints
2014-03-21 8:09 [Bug target/60606] New: ICE [ARM] error: insn does not satisfy its constraints d.salikhov at samsung dot com
` (2 preceding siblings ...)
2014-03-26 15:03 ` rearnsha at gcc dot gnu.org
@ 2014-03-27 5:03 ` d.salikhov at samsung dot com
2014-03-27 17:37 ` [Bug target/60606] [ARM] ICE with asm ("mov ...", pc) ramana at gcc dot gnu.org
` (4 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: d.salikhov at samsung dot com @ 2014-03-27 5:03 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60606
D.Salikhov <d.salikhov at samsung dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |UNCONFIRMED
Resolution|WONTFIX |---
--- Comment #4 from D.Salikhov <d.salikhov at samsung dot com> ---
(In reply to Richard Earnshaw from comment #3)
> > register unsigned long pc asm("pc");
>
> I think it's a mistake to permit this sort of construct.
>
> What does:
>
> a = pc;
> b = a+pc;
>
> generate for b? Is it exactly twice a (the compiler doesn't see pc
> changing, so is free to assume that it doesn't), just more than twice a (how
> much more?) or just less than twice a (different scheduling)? What happens
> if the user writes
>
> pc = 3; // ???
>
> The point is that while it might be valid to use pc in assembly
> instructions, the constructs you get in high-level languages are essentially
> meaningless.
Well, even if I use PC incorrectly (actually I don't), it shouldn't lead to
ICE. At least, there should be a sensible error message from compiler but not
internal error.
>
> As has been pointed out, in the few cases where you really need to extract
> the program counter you can write an inline assembly statement that
> explicitly references the PC.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug target/60606] [ARM] ICE with asm ("mov ...", pc)
2014-03-21 8:09 [Bug target/60606] New: ICE [ARM] error: insn does not satisfy its constraints d.salikhov at samsung dot com
` (3 preceding siblings ...)
2014-03-27 5:03 ` d.salikhov at samsung dot com
@ 2014-03-27 17:37 ` ramana at gcc dot gnu.org
2014-05-19 4:42 ` d.salikhov at samsung dot com
` (3 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: ramana at gcc dot gnu.org @ 2014-03-27 17:37 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60606
Ramana Radhakrishnan <ramana at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |ice-on-invalid-code
Priority|P3 |P5
Status|UNCONFIRMED |NEW
Last reconfirmed| |2014-03-27
CC| |ramana at gcc dot gnu.org
Summary|ICE [ARM] error: insn does |[ARM] ICE with asm ("mov
|not satisfy its constraints |...", pc)
Ever confirmed|0 |1
--- Comment #5 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
(In reply to D.Salikhov from comment #4)
> (In reply to Richard Earnshaw from comment #3)
> > > register unsigned long pc asm("pc");
> >
> > I think it's a mistake to permit this sort of construct.
> >
> > What does:
> >
> > a = pc;
> > b = a+pc;
> >
> > generate for b? Is it exactly twice a (the compiler doesn't see pc
> > changing, so is free to assume that it doesn't), just more than twice a (how
> > much more?) or just less than twice a (different scheduling)? What happens
> > if the user writes
> >
> > pc = 3; // ???
> >
> > The point is that while it might be valid to use pc in assembly
> > instructions, the constructs you get in high-level languages are essentially
> > meaningless.
>
> Well, even if I use PC incorrectly (actually I don't), it shouldn't lead to
> ICE. At least, there should be a sensible error message from compiler but
> not internal error.
>
True, the compiler shouldn't ICE, but writing an inline assembler statement of
that form, to read the value of the PC is just broken. The value of PC you read
may not be what you expect it to be and allowing such a form is just wrong. It
would be just any old PC. In a function asm ("mov ..., pc") will not give you
the same result relative to other statements in the function all the time.
>From your program it appears as though you want to check Thumbness - is a
static time answer not good enough ? You can get information that from
pre-processor macros.
Anyway, patches welcome if you want to fix it.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug target/60606] [ARM] ICE with asm ("mov ...", pc)
2014-03-21 8:09 [Bug target/60606] New: ICE [ARM] error: insn does not satisfy its constraints d.salikhov at samsung dot com
` (4 preceding siblings ...)
2014-03-27 17:37 ` [Bug target/60606] [ARM] ICE with asm ("mov ...", pc) ramana at gcc dot gnu.org
@ 2014-05-19 4:42 ` d.salikhov at samsung dot com
2014-08-26 17:07 ` jsm28 at gcc dot gnu.org
` (2 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: d.salikhov at samsung dot com @ 2014-05-19 4:42 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60606
--- Comment #6 from D.Salikhov <d.salikhov at samsung dot com> ---
Created attachment 32817
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32817&action=edit
Yet another code sample
Add less factitious code sample reproducing the issue.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug target/60606] [ARM] ICE with asm ("mov ...", pc)
2014-03-21 8:09 [Bug target/60606] New: ICE [ARM] error: insn does not satisfy its constraints d.salikhov at samsung dot com
` (5 preceding siblings ...)
2014-05-19 4:42 ` d.salikhov at samsung dot com
@ 2014-08-26 17:07 ` jsm28 at gcc dot gnu.org
2014-08-26 17:08 ` jsm28 at gcc dot gnu.org
2014-09-03 7:23 ` yroux at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: jsm28 at gcc dot gnu.org @ 2014-08-26 17:07 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60606
--- Comment #7 from Joseph S. Myers <jsm28 at gcc dot gnu.org> ---
Author: jsm28
Date: Tue Aug 26 17:06:31 2014
New Revision: 214526
URL: https://gcc.gnu.org/viewcvs?rev=214526&root=gcc&view=rev
Log:
Fix ARM ICE for register var asm ("pc") (PR target/60606).
PR target/60606
PR target/61330
* varasm.c (make_decl_rtl): Clear DECL_ASSEMBLER_NAME and
DECL_HARD_REGISTER and return for invalid register specifications.
* cfgexpand.c (expand_one_var): If expand_one_hard_reg_var clears
DECL_HARD_REGISTER, call expand_one_error_var.
* config/arm/arm.c (arm_hard_regno_mode_ok): Do not allow
CC_REGNUM with non-MODE_CC modes.
(arm_regno_class): Return NO_REGS for PC_REGNUM.
testsuite:
* gcc.dg/torture/pr60606-1.c, gcc.target/arm/pr60606-2.c,
gcc.target/arm/pr60606-3.c, gcc.target/arm/pr60606-4.c: New tests.
Added:
trunk/gcc/testsuite/gcc.dg/torture/pr60606-1.c
trunk/gcc/testsuite/gcc.target/arm/pr60606-2.c
trunk/gcc/testsuite/gcc.target/arm/pr60606-3.c
trunk/gcc/testsuite/gcc.target/arm/pr60606-4.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgexpand.c
trunk/gcc/config/arm/arm.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/varasm.c
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug target/60606] [ARM] ICE with asm ("mov ...", pc)
2014-03-21 8:09 [Bug target/60606] New: ICE [ARM] error: insn does not satisfy its constraints d.salikhov at samsung dot com
` (6 preceding siblings ...)
2014-08-26 17:07 ` jsm28 at gcc dot gnu.org
@ 2014-08-26 17:08 ` jsm28 at gcc dot gnu.org
2014-09-03 7:23 ` yroux at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: jsm28 at gcc dot gnu.org @ 2014-08-26 17:08 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60606
Joseph S. Myers <jsm28 at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
Target Milestone|--- |5.0
--- Comment #8 from Joseph S. Myers <jsm28 at gcc dot gnu.org> ---
Fixed (making this a normal error) for GCC 5.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug target/60606] [ARM] ICE with asm ("mov ...", pc)
2014-03-21 8:09 [Bug target/60606] New: ICE [ARM] error: insn does not satisfy its constraints d.salikhov at samsung dot com
` (7 preceding siblings ...)
2014-08-26 17:08 ` jsm28 at gcc dot gnu.org
@ 2014-09-03 7:23 ` yroux at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: yroux at gcc dot gnu.org @ 2014-09-03 7:23 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60606
--- Comment #9 from Yvan Roux <yroux at gcc dot gnu.org> ---
Author: yroux
Date: Wed Sep 3 07:23:01 2014
New Revision: 214847
URL: https://gcc.gnu.org/viewcvs?rev=214847&root=gcc&view=rev
Log:
gcc/
2014-09-03 Yvan Roux <yvan.roux@linaro.org>
Backport from trunk r214526.
2014-08-26 Joseph Myers <joseph@codesourcery.com>
PR target/60606
PR target/61330
* varasm.c (make_decl_rtl): Clear DECL_ASSEMBLER_NAME and
DECL_HARD_REGISTER and return for invalid register specifications.
* cfgexpand.c (expand_one_var): If expand_one_hard_reg_var clears
DECL_HARD_REGISTER, call expand_one_error_var.
* config/arm/arm.c (arm_hard_regno_mode_ok): Do not allow
CC_REGNUM with non-MODE_CC modes.
(arm_regno_class): Return NO_REGS for PC_REGNUM.
gcc/testsuite/
2014-09-03 Yvan Roux <yvan.roux@linaro.org>
Backport from trunk r214526.
2014-08-26 Joseph Myers <joseph@codesourcery.com>
PR target/60606
PR target/61330
* gcc.dg/torture/pr60606-1.c, gcc.target/arm/pr60606-2.c,
gcc.target/arm/pr60606-3.c, gcc.target/arm/pr60606-4.c: New tests.
Added:
branches/linaro/gcc-4_9-branch/gcc/testsuite/gcc.dg/torture/pr60606-1.c
branches/linaro/gcc-4_9-branch/gcc/testsuite/gcc.target/arm/pr60606-2.c
branches/linaro/gcc-4_9-branch/gcc/testsuite/gcc.target/arm/pr60606-3.c
branches/linaro/gcc-4_9-branch/gcc/testsuite/gcc.target/arm/pr60606-4.c
Modified:
branches/linaro/gcc-4_9-branch/gcc/ChangeLog.linaro
branches/linaro/gcc-4_9-branch/gcc/cfgexpand.c
branches/linaro/gcc-4_9-branch/gcc/config/arm/arm.c
branches/linaro/gcc-4_9-branch/gcc/testsuite/ChangeLog.linaro
branches/linaro/gcc-4_9-branch/gcc/varasm.c
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2014-09-03 7:23 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-03-21 8:09 [Bug target/60606] New: ICE [ARM] error: insn does not satisfy its constraints d.salikhov at samsung dot com
2014-03-21 9:10 ` [Bug target/60606] " y.gribov at samsung dot com
2014-03-21 9:28 ` d.salikhov at samsung dot com
2014-03-26 15:03 ` rearnsha at gcc dot gnu.org
2014-03-27 5:03 ` d.salikhov at samsung dot com
2014-03-27 17:37 ` [Bug target/60606] [ARM] ICE with asm ("mov ...", pc) ramana at gcc dot gnu.org
2014-05-19 4:42 ` d.salikhov at samsung dot com
2014-08-26 17:07 ` jsm28 at gcc dot gnu.org
2014-08-26 17:08 ` jsm28 at gcc dot gnu.org
2014-09-03 7:23 ` yroux at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).