The following test code -- test.c ------------------------------------- void f (int *a) { asm volatile("" : "=m" (*a), "=m" (*a), "=m" (*a), "=m" (*a), "=m" (*a), "=m" (*a), "=m" (*a) ); } ----------------------------------------------- when compiled with ----------------------------------------------- gcc -march=athlon-xp -m32 -o test.s -S test.c ----------------------------------------------- using the following GCC ----------------------------------------------- $ gcc -v Using built-in specs. Configured with: ../../../gcc-CVS-20050120/gcc-CVS-20050120/configure --host=x86_64-pc-linux-gnu --prefix=/usr/local/opt/gcc-4.0 --exec-prefix=/usr/local/opt/gcc-4.0 --sysconfdir=/etc --libdir=/usr/local/opt/gcc-4.0/lib64 --libexecdir=/usr/local/opt/gcc-4.0/libexec64 --sharedstatedir=/var --localstatedir=/var --program-suffix=-4.0 --with-x-includes=/usr/X11R6/include --with-x-libraries=/usr/X11R6/lib64 --enable-shared --enable-static --with-gnu-as --with-gnu-ld --with-stabs --enable-threads=posix --enable-version-specific-runtime-libs --disable-coverage --enable-gather-detailed-mem-stats --disable-libgcj --disable-checking --enable-multilib --with-x --enable-cmath --enable-libstdcxx-debug --enable-fast-character --enable-hash-synchronization --with-system-zlib --with-libbanshee --with-demangler-in-ld --with-arch=athlon64 --disable-libada --enable-languages=c,c++,f95,objc Thread model: posix gcc version 4.0.0 20050120 (experimental) $ ----------------------------------------------- or compiled by a native x86 compiler compiled from the same sources, fails with the following error: ----------------------------------------------- test.c: In function ‘f’: test.c:3: error: can't find a register in class ‘GENERAL_REGS’ while reloading ‘asm’ ----------------------------------------------- It also fails the same way with the following compiler: ----------------------------------------------- $ gcc -v Reading specs from /usr/lib64/gcc/x86_64-mandrake-linux-gnu/3.4.1/specs Configured with: ../configure --prefix=/usr --libdir=/usr/lib64 --with-slibdir=/lib64 --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --enable-long-long --enable-__cxa_atexit --enable-clocale=gnu --disable-libunwind-exceptions --enable-languages=c,c++,ada,f77,objc,java --host=x86_64-mandrake-linux-gnu --with-system-zlib Thread model: posix gcc version 3.4.1 (Mandrakelinux 10.1 3.4.1-4mdk) $ ----------------------------------------------- But when compiled natively for x86_64, both mentioned compilers work fine.
*** This bug has been marked as a duplicate of 11203 ***
Reporter says in PR 11203 this does happen even at -O2, so it's not a duplicate of PR 11203.
It still a dup of bug 11203 and here is why, the a gets placed in different register for the inline-asm at -O0 but -O1 and above, we use the same register/offset but PR 11203 has a testcase where it does not compile at -O0 to -O3 but that is because the memory operands share in common areas. Anyways this inline-asm is useless as the operands are all the same which is why it works at -O1 but not at -O0 and you just ran out of registers on x86 because we don't do any optimization at all at -O0. *** This bug has been marked as a duplicate of 11203 ***
(In reply to comment #3) > It still a dup of bug 11203 and here is why, the a gets placed in different register for the inline-asm at > -O0 but -O1 and above, we use the same register/offset but PR 11203 has a testcase where it does not > compile at -O0 to -O3 but that is because the memory operands share in common areas. > > Anyways this inline-asm is useless as the operands are all the same which is why it works at -O1 I can't quite follow. The reporter says this test case does *not* compile at -O1. In my opinion, gcc should be able to compile this asm at -O1 and above. Maybe somebody else can comment on this...
Falk, sorry but Andrew is right. First of all, it *does* compile for me at -O[123] on i686, but not at -O0 because reload can't find a register. I tried GCC 3.3, 3.4, and 4.0, and -march={i386,i686,athlon-xp,pentium4}, and all these versions behave the same. Second, both PRs concern a basically overly constrained asm. I am sure I mentioned in PR11203 that any success in compiling such asm is just luck. Not a GCC bug
(In reply to comment #5) > Second, both PRs concern a basically overly constrained asm. I am > sure I mentioned in PR11203 that any success in compiling such asm > is just luck. > > Not a GCC bug We do in fact completely agree, except for the interpretation of the words "invalid" and "bug". I would have closed it as "wontfix" instead of "invalid". Of course, the effect for the users is exactly the same :-)