| Summary: | ICE: in match_reload, at lra-constraints.c:1060 | ||
|---|---|---|---|
| Product: | gcc | Reporter: | 吳建興 <fdgkhdkgh> |
| Component: | rtl-optimization | Assignee: | Vladimir Makarov <vmakarov> |
| Status: | ASSIGNED --- | ||
| Severity: | normal | CC: | aoliva, jakub, vmakarov |
| Priority: | P3 | Keywords: | ice-on-valid-code, inline-asm, ra |
| Version: | 10.0 | ||
| Target Milestone: | --- | ||
| Host: | Target: | ||
| Build: | Known to work: | ||
| Known to fail: | Last reconfirmed: | 2020-01-21 00:00:00 | |
Thank you for the report. I've started working on it. As changes in constraint processing needs a lot of testing, I think the patch will be read on Friday or on the next week. Sorry, I did a mistake in PR number and automatic commits reporting did not work. Here are the patches fixing the PR: https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=280133 https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=280135 https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=280136 Author: vmakarov Date: Fri Jan 10 20:45:19 2020 New Revision: 280138 URL: https://gcc.gnu.org/viewcvs?rev=280138&root=gcc&view=rev Log: 2020-01-10 Vladimir Makarov <vmakarov@redhat.com> PR inline-asm/93027 * gcc.target/i386/pr93027.c: Use the right PR number in the test. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/pr93027.c The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>: https://gcc.gnu.org/g:3a26c7b3a3569a5e1b6f0342e50aefe76ad0ec4d commit r10-6190-g3a26c7b3a3569a5e1b6f0342e50aefe76ad0ec4d Author: Jakub Jelinek <jakub@redhat.com> Date: Thu Jan 23 22:50:40 2020 +0100 testsuite: Require lp64 target rather x86_64-*-* in pr93027.c. [PR93027] I've noticed this test failed on x86_64-linux with -m32 or -mx32 testing, the triplet doesn't really say which actual multilib it is, and the test really works with lp64. 2020-01-23 Jakub Jelinek <jakub@redhat.com> PR inline-asm/93027 * gcc.target/i386/pr93027.c: Require lp64 target rather x86_64-*-*. So fixed for trunk? GCC 9 seems to ICE on this too in the same spot (but with -fchecking only or --enable-checking=yes), GCC 8 in extract_constraint_insn (but again with checking only). FWIW, with or without optimization, this testcase allocates inout f and in &w to the same register in the .reload dump. If the asm code used %0, expecting it to be initially 0 as it should, it would fail:
int main (void) {
int f = 0, w, z;
asm volatile(
"movl\t%0, %1"
: "+m&l"(f), "=g" (z)
: "0a"(&w)
);
if (z)
__builtin_abort ();
return 0;
}
|
g++ ./hi.c INPUT: int main() { int f= 0, w; asm volatile( "" : "+m&l"(f) : "0a"(&w) ); } OUTPUT: during RTL pass: reload ./bug.cc: In function ‘int main()’: ./bug.cc:9:1: internal compiler error: in match_reload, at lra-constraints.c:1060 9 | } | ^ 0x2b55f43 match_reload ../.././gcc/lra-constraints.c:1058 0x2b9c03f curr_insn_transform ../.././gcc/lra-constraints.c:4306 0x2ba4656 lra_constraints(bool) ../.././gcc/lra-constraints.c:5009 0x2b102b4 lra(_IO_FILE*) ../.././gcc/lra.c:2437 0x28e6954 do_reload ../.././gcc/ira.c:5518 0x28e6954 execute ../.././gcc/ira.c:5704 It is probably the same bug in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84985