This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]