gcc-9.0.0-alpha20181202 snapshot (r266729) for x86_64 ICEs when compiling gcc/testsuite/gcc.target/m68k/pr45015.c w/ -O1 (-Og) -ftrapv: % x86_64-unknown-linux-gnu-gcc-9.0.0-alpha20181202 -O1 -ftrapv -c gcc/testsuite/gcc.target/m68k/pr45015.c gcc/testsuite/gcc.target/m68k/pr45015.c: In function 'foo': gcc/testsuite/gcc.target/m68k/pr45015.c:16:7: error: 'asm' operand has impossible constraints 16 | __asm__ ("move.l %2, %0; move.l %3, %1" : "=d" (b), "=d" (c) : "g<>" (y[j]), "d" (w)); | ^~~~~~~ during RTL pass: reload gcc/testsuite/gcc.target/m68k/pr45015.c:26:1: internal compiler error: in lra_assign, at lra-assigns.c:1624 26 | } | ^ 0xb897d0 lra_assign(bool&) /var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/lra-assigns.c:1624 0xb8443d lra(_IO_FILE*) /var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/lra.c:2508 0xb3b929 do_reload /var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/ira.c:5469 0xb3b929 execute /var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/ira.c:5653
Hmm, m68k asms may contain m68k specific constraints that do not make sense on x86.
Not a target problem.
Started with r257077. In any case, it seems to be a LRA error-recovery bug. We first properly diagnose that the inline asm has constraints that are impossible to resolve ("=d" on two different variables). Vlad, do you think you could have a look?
(In reply to Jakub Jelinek from comment #3) > Started with r257077. In any case, it seems to be a LRA error-recovery bug. > We first properly diagnose that the inline asm has constraints that are > impossible to resolve ("=d" on two different variables). Vlad, do you think > you could have a look? Yes, constraints are impossible and LRA should generate error "operand has impossible constraints". I am working on it and the fix will be ready today or tomorrow.
Author: vmakarov Date: Thu Dec 13 20:54:27 2018 New Revision: 267109 URL: https://gcc.gnu.org/viewcvs?rev=267109&root=gcc&view=rev Log: 2018-12-13 Vladimir Makarov <vmakarov@redhat.com> PR rtl-optimization/88414 * lra-int.h (lra_asm_error_p): New. * lra-assigns.c (lra_assign): Check lra_asm_error_p for checking call crossed pseudo assignment correctness. (lra_split_hard_reg_for): Set up lra_asm_error_p. * lra-constraints.c (curr_insn_transform): Ditto. * lra.c (lra_asm_error_p): New. (lra): Reset lra_asm_error_p. 2018-12-13 Vladimir Makarov <vmakarov@redhat.com> PR rtl-optimization/88414 * gcc.target/i386/pr88414.c: New. Added: trunk/gcc/testsuite/gcc.target/i386/pr88414.c Modified: trunk/gcc/ChangeLog trunk/gcc/lra-assigns.c trunk/gcc/lra-constraints.c trunk/gcc/lra-int.h trunk/gcc/lra.c trunk/gcc/testsuite/ChangeLog
Resolved on the trunk.
On 10.x and 9.x with checking enabled The test case for this produces the following output for i686-apple-darwin9 (actually any Darwin N from 9 - 17). /src-local/gcc-master/gcc/testsuite/gcc.target/i386/pr88414.c:15:7: error: ‘asm’ operand has impossible constraints 15 | asm volatile ("" : "=d" (b), "=d" (c) : "r" (y[j]), "d" (w)); /* { dg-error "'asm' operand has impossible constraints" } */ | ^~~ during RTL pass: reload /src-local/gcc-master/gcc/testsuite/gcc.target/i386/pr88414.c:25:1: internal compiler error: maximum number of LRA assignment passes is achieved (30) 25 | } | ^ ** when checking is disabled (i.e. set to release) the case hangs (which hangs the test suite). ** From 11.x+ the diagnostic is emitted and the test case finishes OK. This is the patch that 'fixes' this: r11-209-g74dc179a6da33cd00f6d4a93fbb97dc84f610126 Would it. or some equivalent, be appropriate for 10.4? (since IMO a hang is less user-friendly than an ICE) - of course, the code is invalid either way ...