This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: [Bug inline-asm/11103] [3.3/3.4 regression] asm-specifier conflicts with asm clobber list
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: gcc-bugzilla at gcc dot gnu dot org, dhazeghi at yahoo dot com
- Cc: gcc-bugs at gcc dot gnu dot org, Richard dot Earnshaw at arm dot com
- Date: Mon, 09 Jun 2003 15:03:33 +0100
- Subject: Re: [Bug inline-asm/11103] [3.3/3.4 regression] asm-specifier conflicts with asm clobber list
- Organization: ARM Ltd.
- Reply-to: Richard dot Earnshaw at arm dot com
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.