[Bug inline-asm/11203] source doesn't compile with -O0 but they compile with -O3

["michaelni at gmx dot at" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #39 from michaelni at gmx dot at  2007-02-27 22:50 -------
(In reply to comment #38)
> (In reply to comment #37)
> > now if there is a unwritten rule that "m" operands and variations of them
> > cannot be copied anywhere, then it would be very desireable to have a asm
> > constraint like "m" without this restriction this would resolve this and
> > several other bugs
> > also it would be very nice if such a dont copy restriction on "m" if it does
> > exist could be documented
> 
> Copying "m" operands onto the stack might not be such a great thing to wish
> for.  Imagine if you used asm("movaps %xmm0, %0": "=m"(x[i]));  If x[i] is only
> 32-bits, and gcc copied it onto the stack, then writing 16 bytes with movaps
> wouldn't also write to x[i+1] to x[i+3] as intended.  I know there is a plenty
> of asm code in ffmpeg that overwrites or overreads memory operands and will
> fail if gcc tried to move them onto the stack.  There is also alignment. 
> movaps requires an aligned address, and maybe you have chosen x and i in such a
> way that it will be aligned.  But when gcc copies the value onto the stack, how
> is it supposed to know what alignment it needs?

well the data type used in "m"() must of course be correct, that is here a
128bit type, alignment can be handled like with all other types, double also
gets aligned if the architecture needs it, so a uint128_t or sse128 or whatever
can as well, the example you show is a fairly obscure special case in respect
to moving "m" to the stack, in the end theres a need for a "m" like constraint
which must not be moveable and a "m" like constraint which should be moveable
(to the stack for example) the exact letters used are irrelevant


-- 


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