[Bug c/11103] New: asm-specifier conflicts with asm clobber list

[Bug c/11103] New: asm-specifier conflicts with asm clobber list

[mdb@gnu.org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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

           Summary: asm-specifier conflicts with asm clobber list
           Product: gcc
           Version: 3.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: mdb@gnu.org
                CC: gcc-bugs@gcc.gnu.org
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: xscal-elf

Using the gcc 3.2.2 xscale-elf-gcc compiler had no problems with the test case.

Using the gcc 3.3 xscale-elf-gcc compiler will produce the following
messages:

blkpg-test.c: In function `blk_ioctl':
blkpg-test.c:13: error: asm-specifier for variable `myr1' conflicts with asm
clobber list

The basic problem is that the gcc code generator does NOT like the user
forcing the use of registers r0 and r1 for the inline assembler.

The workaround would appear to be to elide the asm("r1") and the two
asm("r0") extensions and let gcc choose the register for the code...
which really only works correctly if that is what the __put_user_1
function will accept.

In the real world, this problem is found by building the file
linux-2.4.19/drivers/block/blkpg.c which results in the error

blkpg.c: In function `blk_ioctl':
blkpg.c:285: warning: comparison between signed and unsigned
blkpg.c:252: error: asm-specifier for variable `__r1' conflicts with asm clobber
list


Release:
gcc 3.3

Target:
xscale-elf

Environment:
Redhat 7.3 GNU/Linux: uname -a says:
Linux mdb-lnx 2.4.20-13.7 #1 Mon May 12 13:13:52 EDT 2003 i686 unknown

How-To-Repeat:
cat <<EOF > blkpg-test.c
/*
 * -------------- blkpg-test.c ---------------
 * xscale-elf-gcc -c blkpg-test.c
 */

int __put_user_1 (void *, unsigned int);
int
blk_ioctl (unsigned long long *arg)
{
    const register unsigned long long myr1 asm("r1") = 0;
    const register unsigned long long *ptr asm("r0") = arg;
    register int res asm("r0");
    __asm__ __volatile__ ("bl   __put_user_1"
                          : "=&r" (res)
                          : "0" (ptr), "r" (myr1)
                          : "r2", "lr");
    return(res);
}
EOF
xscale-elf-gcc -c blkpg-test.c



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug inline-asm/11103] [3.3/3.4 regression] asm-specifier conflicts with asm clobber list

[dhazeghi@yahoo.com]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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


dhazeghi@yahoo.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rearnsha@gcc.gnu.org
             Status|UNCONFIRMED                 |NEW
          Component|c                           |inline-asm
     Ever Confirmed|                            |1
  GCC build triplet|                            |i686-pc-linux-gnu
 GCC target triplet|xscal-elf                   |xscale-elf
   Last reconfirmed|0000-00-00 00:00:00         |2003-06-08 05:51:47
               date|                            |
            Summary|asm-specifier conflicts with|[3.3/3.4 regression] asm-
                   |asm clobber list            |specifier conflicts with asm
                   |                            |clobber list


------- Additional Comments From dhazeghi@yahoo.com  2003-06-08 05:51 -------
Confirmed with gcc 3.3 and mainline (20030608). I think this belongs in the inline-asm category 
though. Richard, would you mind commenting on whether the code in question is legal? Thanks,

Dara

[Bug inline-asm/11103] [3.3/3.4 regression] asm-specifier conflicts with asm clobber list

[dank@kegel.com]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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


dank@kegel.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dank@kegel.com


------- Additional Comments From dank@kegel.com  2003-06-08 09:39 -------
I get a similar error,
error: asm-specifier for variable `_a1' conflicts with asm clobber list
compiling glibc-2.3.2 with gcc-3.3 for arm-linux.
In the real world, you should be able to reproduce this like so:

wget http://www.kegel.com/crossgcc/crosstool-0.6.tar.gz
tar -xzvf crosstool-0.6.tar.gz
cd crosstool-0.6
eval `cat arm.dat` `cat gcc3.3-glibc2.3.2.dat` sh all.sh

Here's the problem boiled down as small as I can easily get it
(this is the output of 
$ cd build/arm-unknown-linux-gnu/gcc-3.3-glibc-2.3.2/glibc-2.3.2/signal
$ arm-unknown-linux-gnu-gcc -E ../linuxthreads/sysdeps/pthread/sigaction.c
cut down by hand and reformatted with indent):

-- snip --

cat > bug.c <<_EOF_
extern int *__errno_location (void) __attribute__ ((__const__));
struct kernel_sigaction {
    //__sighandler_t k_sa_handler;
    unsigned long sa_flags;
    void (*sa_restorer) (void);
    //sigset_t sa_mask;
};

int __libc_sigaction(sig, act, oact)
int sig;
const struct sigaction *act;
struct sigaction *oact;
{
    int result;
    struct kernel_sigaction kact, koact;

    result = ( {
            unsigned int _sys_result = ( {
                    unsigned int _sys_result; {
                        register int _a1 asm("a1");
                        register int _a4 asm("a4") = (int)(64 / 8);
                        register int _a3 asm("a3") = (int)(oact ? (&koact) :
((void *)0));
                        register int _a2 asm("a2") = (int)(act ? (&kact) :
((void *)0));
                        _a1 = (int) (sig);
              asm volatile ("swi    %1  @ syscall " "rt_sigaction": "=r" (_a1):
"i"(((0x900000 + 174))), "r"(_a1), "r"(_a2), "r"(_a3), "r"(_a4):"a1",
                            "memory");
                        _sys_result = _a1;
                    } (int) _sys_result;
                });
            if (__builtin_expect(((unsigned int) (_sys_result) >= 0xfffff001u),
0)) {
        ((*__errno_location()) = ((-(_sys_result))));
                _sys_result = (unsigned int) -1;} (int) _sys_result;});

    return result;
}
_EOF_
arm-unknown-linux-gnu-gcc bug.c

-- snip --

Re: [Bug inline-asm/11103] [3.3/3.4 regression] asm-specifier conflicts with asm clobber list

[Richard Earnshaw]

gcc-bugzilla@gcc.gnu.org said:
> Confirmed with gcc 3.3 and mainline (20030608). I think this belongs
> in the inline-asm category  though. Richard, would you mind commenting
> on whether the code in question is legal? Thanks, 

The error is perfectly correct, as I see it, and the manual supports this 
view:


>    You may not write a clobber description in a way that overlaps with
> an input or output operand.  For example, you may not have an operand
> describing a register class with one member if you mention that
> register in the clobber list.  There is no way for you to specify that
> an input operand is modified without also specifying it as an output
> operand. Note that if all the output operands you specify are for this
> purpose (and hence unused), you will then also need to specify
> `volatile' for the `asm' construct, as described below, to prevent GNU
> CC from deleting the `asm' statement as unused. 

  myr1 is a long long, so will occupy r1 and r2.  Since r2 is clobbered by 
the pattern gcc is complaining that myr1 overlaps the clobber list: the 
compiler has no way of knowing that the first instruction of an ASM 
sequence doesn't use r2 in a way that would destroy myr1.

Note, I think the whole asm construct here is somewhat bogus, the compiler 
could legitimately produce the following code for it and claim that it has 
met the "specification" requested:

	stmfd	sp!, {r4, lr}
	mov	r3, r1		// myr1 into safe registers (myr1 is now dead).
	mov	r4, r2
	mov	r1, r0
	// Input registers are r1, r3 and r4.  Output regs are r1 (tied to input)
	bl  __put_user_1	// User's asm instruction
	mov	r0, r1		// Assign r1 result (from asm) to res.
	ldmfd	sp!, {r4, pc}

The key point here is that nothing in the ASM can say which specific 
register an input argument must appear in or where the result will be 
returned -- that might be a weakness in the way our ASM is specified, but 
that is life.

[Bug inline-asm/11103] [3.3/3.4 regression] asm-specifier conflicts with asm clobber list

[dhazeghi@yahoo.com]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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


dhazeghi@yahoo.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID


------- Additional Comments From dhazeghi@yahoo.com  2003-06-11 15:38 -------
As Richard noted (http://gcc.gnu.org/ml/gcc-bugs/2003-06/msg01134.html), the behavior of 
the compiler seems to be correct, and so the bug appears to be in the code here. I am marking this 
bug as invalid, but if for some reason this turns out to be incorrect, we can reopen this.

[Bug inline-asm/11103] [3.3/3.4 regression] asm-specifier conflicts with asm clobber list

[dank@kegel.com]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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



------- Additional Comments From dank@kegel.com  2003-06-11 15:53 -------
Ah, so I should open this as a glibc bug, then?  OK, I'll try that.

[Bug inline-asm/11103] [3.3/3.4 regression] asm-specifier conflicts with asm clobber list

[dank@kegel.com]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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



------- Additional Comments From dank@kegel.com  2003-06-15 14:47 -------
Supposedly fixed in glibc cvs; see
http://bugs.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=glibc&pr=5051

Re: [Bug inline-asm/11103] [3.3/3.4 regression] asm-specifier conflicts with asm clobber list

[Hans-Peter Nilsson]

On Mon, 9 Jun 2003, Richard Earnshaw wrote:
> gcc-bugzilla@gcc.gnu.org said:
> > Confirmed with gcc 3.3 and mainline (20030608). I think this belongs
> > in the inline-asm category  though. Richard, would you mind commenting
> > on whether the code in question is legal? Thanks,
>
> The error is perfectly correct, as I see it, and the manual supports this
> view:

Agreed.  (Whew, I don't have to argue for it again. :-)

> Note, I think the whole asm construct here is somewhat bogus, the compiler
> could legitimately produce the following code for it and claim that it has
> met the "specification" requested:

No it can't.  It is written in stone^W^Win the manual that
asm-declared registers that feed into asms in the source aren't
moved around and renamed by GCC to appear in different registers
in the asm.  Modulo GCC bugs, of course, so I suggest add checks
in the asm.  See for example gcc.dg/asmreg-1.c.

> 	stmfd	sp!, {r4, lr}
> 	mov	r3, r1		// myr1 into safe registers (myr1 is now dead).
> 	mov	r4, r2
> 	mov	r1, r0
> 	// Input registers are r1, r3 and r4.  Output regs are r1 (tied to input)
> 	bl  __put_user_1	// User's asm instruction
> 	mov	r0, r1		// Assign r1 result (from asm) to res.
> 	ldmfd	sp!, {r4, pc}
>
> The key point here is that nothing in the ASM can say which specific
> register an input argument must appear in or where the result will be

By feeding specific asm-declared variables, it does.

> returned -- that might be a weakness in the way our ASM is specified, but
> that is life.

It would be, if it wasn't documented to work (Explicit Reg
Vars):

These local variables are sometimes convenient for use with the
extended @code{asm} feature (@pxref{Extended Asm}), if you want
to write one output of the assembler instruction directly into a
particular register.  (This will work provided the register you
specify fits the constraints specified for that operand in the
@code{asm}.)

Maybe it can bw said in stronger words, but it *is* documented.

brgds, H-P
PS.  I'm a week behind on list traffic.