This is the mail archive of the gcc-patches@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: PR 17884



On Oct 12, 2004, at 4:35 PM, Fariborz Jahanian wrote:



On Oct 12, 2004, at 4:17 PM, Dale Johannesen wrote:



On Oct 12, 2004, at 3:31 PM, Fariborz Jahanian wrote:
+instruction.)  Note that even a volatile @code{asm} instruction
+can be moved relative to other code, including across jump
+instructions.  For example, you can't use a volatile @code{asm}
For example, you can't use floating point instructions to set the
bits of a floating point control register and expect those instructions
not [to] be moved...

No, I want to make it clear that the asm is setting the FPCR. If I add "other" as below does that help?

Why? it could be set by asm or a normal c expression. As in:


        sum = xDD.d[0] + xDD.d[1];
        asm volatile("mtfsf 255,%0" : : "f" (fpenv));

(which is from the example which started it all).

The mtfsf is the only thing here that changes the FP control register (FPSCR).
However, if it's confused you, it's obviously not a very good example. How
about this:


For example, on many targets there is a system register which can be set to
control the rounding mode of floating point operations. You might try
setting it with a volatile asm, like this PowerPC example:


       asm volatile("mtfsf 255,%0" : : "f" (fpenv));
       sum = x + y;

This will not work reliably, as the compiler may move the addition back
before the volatile asm.


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