[Bug target/19549] New: Register allocation problem in inline asm on x86.

[Bug target/19549] New: Register allocation problem in inline asm on x86.

[drab at kepler dot fjfi dot cvut dot cz]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3289 bytes --]

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.

-- 
           Summary: Register allocation problem in inline asm on x86.
           Product: gcc
           Version: 4.0.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: target
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: drab at kepler dot fjfi dot cvut dot cz
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19549

[Bug target/19549] Register allocation problem in inline asm on x86.

[drab at kepler dot fjfi dot cvut dot cz]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|                            |3.4.1 4.0.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19549

[Bug target/19549] Register allocation problem in inline asm on x86.

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-20 21:04 -------


*** This bug has been marked as a duplicate of 11203 ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19549

[Bug target/19549] Register allocation problem in inline asm on x86.

[falk at debian dot org]

------- Additional Comments From falk at debian dot org  2005-01-21 15:05 -------
Reporter says in PR 11203 this does happen even at -O2, so it's not a duplicate
of PR 11203.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|DUPLICATE                   |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19549

[Bug target/19549] Register allocation problem in inline asm on x86.

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-21 15:15 -------
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 ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19549

[Bug target/19549] Register allocation problem in inline asm on x86.

[falk at debian dot org]

------- Additional Comments From falk at debian dot org  2005-01-21 15:50 -------
(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...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19549

[Bug target/19549] Register allocation problem in inline asm on x86.

[steven at gcc dot gnu dot org]

------- Additional Comments From steven at gcc dot gnu dot org  2005-01-22 12:07 -------
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 
 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19549

[Bug target/19549] Register allocation problem in inline asm on x86.

[falk at debian dot org]

------- Additional Comments From falk at debian dot org  2005-01-22 15:23 -------
(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 :-)

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19549