gcc -Wp,-MD,init/.main.o.d -nostdinc -iwithprefix include -D__KERNEL__ -Iinclude -Wall -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -ffreestanding -std=gnu89 -O2 -fomit-frame-pointer -pipe -msoft-float -mpreferred-stack-boundary=2 -march=pentium3 -Iinclude/asm-i386/mach-default -Wdeclaration-after-statement -DKBUILD_BASENAME=main -DKBUILD_MODNAME=main -c -o init/.tmp_main.o init/main.c init/main.c: In function `unknown_bootoption': include/asm/string.h:190: error: `asm' operand requires impossible reload include/asm/string.h:190: error: `asm' operand requires impossible reload include/asm/string.h:129: error: `asm' operand requires impossible reload init/main.c:197: error: insn does not satisfy its constraints: (insn 611 481 200 5 (set (reg:SI 1 dx) (reg/v/f:SI 22 xmm1 [orig:89 s ] [89])) 36 {*movsi_1} (nil) (nil)) init/main.c:197: confused by earlier errors, bailing out make[1]: *** [init/main.o] Error 1 make: *** [init] Error 2 Works with any of -march=i386, -march=i586, -march=i686, -march=pentium4, -march=athlon
Created attachment 7789 [details] Preprocessed source
/* reduced testcase, use "-O1 -march=pentium3" */ int unknown_bootoption (void) { int i, j, k, l; for (i = 0; i < 2; i++) asm volatile("" :"=a" (j), "=&S" (k), "=&c" (l) :"1" (0), "2" (0)); return 0; }
Hmm, it worked with 2004-12-11.
Worked in 2004-12-17 too, broken in 2004-12-20 and 2004-12-21 (I don't have -18 and -19)
Must be a cc1 issue - 2004-12-21 with 2004-12-17's /usr/libexec/gcc/*/3.4.4/cc1 works
Introduced with: 2004-12-19 Richard Henderson <rth@redhat.com> * config/i386/i386.c (ix86_hard_regno_mode_ok): Always accept all SSE, MMX, 3DNOW modes in SSE registers; always accept all MMX, 3DNOW modes in MMX registers. * config/i386/i386.h (VALID_SSE2_REG_MODE): Don't include VALID_MMX_REG_MODE. * config/i386/i386.md (movv4sf_internal, movv4si_internal, movv2di_internal, movv2si_internal, movv4hi_internal, movv2sf_internal, movv2df_internal, movv8hi_internal, movv16qi_internal, movti_internal): Add leading '*' to name. (movv2di_internal, movv2df_internal, movv8hi_internal, movv16qi_internal, movv2df, movv8hi, movv16qi, movv2di, pushv2di, pushv8hi, pushv16qi): Enable for SSE1. (movv2si_internal, movv4hi_internal): Add SSE alternatives. (movv8qi_internal, movv2sf_internal): Likewise. (movtf): Simplify conditional. (movv2sf, pushv2sf): Enable for MMX.
Investigating.
Why do we allow MMX modes in SSE regs now? The following patchlet is sufficient to fix the problem: Index: config/i386/i386.c =================================================================== RCS file: /cvs/gcc/gcc/gcc/config/i386/i386.c,v retrieving revision 1.635.2.18 diff -u -p -r1.635.2.18 i386.c --- config/i386/i386.c 20 Dec 2004 05:37:36 -0000 1.635.2.18 +++ config/i386/i386.c 22 Dec 2004 12:21:42 -0000 @@ -14931,9 +14931,7 @@ ix86_hard_regno_mode_ok (int regno, enum out of SSE registers, even when no operation instructions are available. */ return (VALID_SSE_REG_MODE (mode) - || VALID_SSE2_REG_MODE (mode) - || VALID_MMX_REG_MODE (mode) - || VALID_MMX_REG_MODE_3DNOW (mode)); + || VALID_SSE2_REG_MODE (mode)); } if (MMX_REGNO_P (regno)) {
I can't do much more at this point.
Subject: Re: [3.4 Regression] -march=pentium3 breaks linux kernel compiles w/ gcc-3_4-branch as of 2004/12/20 > Why do we allow MMX modes in SSE regs now? Because x86-64 calling conventions demand it. r~
And, actually, we allowed MMX modes with -msse2 before, so there must be another explanation of why things wouldn't have been failing with -march=pentium4.
> > Why do we allow MMX modes in SSE regs now? > > Because x86-64 calling conventions demand it. The calling conventions for vector types I presume? The problem is that SImode slipped through the cracks so the register allocator now jumps from SIREG to INT_SSE_REGS for SImode pseudos. Is that an unintended side-effect?
> And, actually, we allowed MMX modes with -msse2 before, so there must be another > explanation of why things wouldn't have been failing with -march=pentium4. Allocation ordering considerations?
Apparently register move costs. Testing a Large Hack to prevent this suddenly appearing on the 3.4 branch. For mainline, move pattern constraints should be fixed, and folks will have to make sure to use -mno-sse when sse is not desired. Plus, -mno-sse will have to be fixed such that it's effective when -march implies sse[23], and we'll have to add extra code to not ICE on x86-64 when the ABI specifies that parameters go in disabled registers.
FWIW i compiled a full 3.3-hammer compiled 2.6.10rc3 x86-64 kernel for suspicious use of %xmm or %mm and there wasn't any. There also is a warning in all 2.6 x86-64 kernels for kernel FPU use at runtime. So at least on x86-64 it doesn't seem to be a real issue in practice.
Subject: Bug 19102 CVSROOT: /cvs/gcc Module name: gcc Branch: gcc-3_4-branch Changes by: rth@gcc.gnu.org 2004-12-23 01:31:20 Modified files: gcc : ChangeLog gcc/config/i386: i386.c Log message: PR target/19102 * config/i386/i386.c (x86_inter_unit_moves): Disable. (ix86_hard_regno_mode_ok): Disallow SSE2 and MMX scalar modes in SSE registers when only SSE1 enabled. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=2.2326.2.750&r2=2.2326.2.751 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.635.2.18&r2=1.635.2.19
http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01777.html