Re: Processor-specific code

On 2005-04-17 19:34:40 -0700, Brooks Moses wrote: > Yes, the standard refers to changing the rounding mode "if the processor > supports [it]" -- but consider what the standard means by "processor": > "The combination of a computing system and the means by which programs > are transformed for use on

Re: Processor-specific code

On Sun, 17 Apr 2005, Geoffrey Keating wrote: > > I thought we acted like it is "off", allowing CSE and constant folding > > which might be affected by changes in rounding mode. Certainly some of > > Stephen Moshier's testcases (attached to bug 20785) fail. > > The flag that controls this is -f

Re: Processor-specific code

I believe that you understand incorrectly. Of course, you're right. We can choose not to support alteration of rounding mode, but we might want to add that nice feature into gfortran. So, I'll stop invoking the standard, but I still think it would be interesting. Of course, since noone seems to

Re: Processor-specific code

"Joseph S. Myers" <[EMAIL PROTECTED]> writes: > On Thu, 14 Apr 2005, Richard Henderson wrote: > > > On Thu, Apr 14, 2005 at 10:47:26AM -0700, Steve Kargl wrote: > > > Does gcc support > > > #pragma STDC FENV_ACCESS > > > > No, but we currently act like access is "on". > > I thought we acted li

Re: Processor-specific code

Paul Koning <[EMAIL PROTECTED]> writes: > > "Dave" == Dave Korn <[EMAIL PROTECTED]> writes: > > Dave> Original Message > >> From: Paul Koning Sent: 15 April 2005 17:56 > > >>> "Dave" == Dave Korn <[EMAIL PROTECTED]> writes: > >> > Dave> Doesn't the C language spec require th

Re: Processor-specific code

FX Coudert wrote: [attribution lost] > > You'll find that globally changing the rounding mode will screw up > > libm functions. Which is pretty much going to make this useless. > > OK. I didn't know that, and it's going to be annoying. So, the GNU libm > doesn't enable us to call mathematical fun

Re: Processor-specific code

You'll find that globally changing the rounding mode will screw up libm functions. Which is pretty much going to make this useless. OK. I didn't know that, and it's going to be annoying. So, the GNU libm doesn't enable us to call mathematical function with non-default rounding mode? IIUC, this i

Re: Processor-specific code

On 2005-04-15 18:56:23 +0100, Paul Brook wrote: > On Friday 15 April 2005 18:43, Vincent Lefevre wrote: > > It is not possible to change the rounding precision with . > > That's because it's an x86/m68k specific implementation detail and > the compiler should be setting it for you. Setting the ro

Re: Processor-specific code

On Friday, April 15, 2005, at 09:55 AM, Paul Koning wrote: That only works if the notion of switchable rounding mode exists. It doesn't on VAX, PDP-11, PDP-10, ... What, you mean VAX isn't turing complete? :-)

Re: Processor-specific code

On Friday 15 April 2005 18:43, Vincent Lefevre wrote: > On 2005-04-14 10:35:06 -0700, Richard Henderson wrote: > > All that said, C99 has to control just about anything you > > could want about the fpu. > > It is not possible to change the rounding precision with . That's because it's an x86/m68k

Re: Processor-specific code

On 2005-04-14 10:35:06 -0700, Richard Henderson wrote: > All that said, C99 has to control just about anything you > could want about the fpu. It is not possible to change the rounding precision with . -- Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 100% accessible valida

RE: Processor-specific code

> "Dave" == Dave Korn <[EMAIL PROTECTED]> writes: Dave> Original Message >> From: Paul Koning Sent: 15 April 2005 17:56 >>> "Dave" == Dave Korn <[EMAIL PROTECTED]> writes: >> Dave> Doesn't the C language spec require the mode to be switchable Dave> at runtime? >> Dave> In

RE: Processor-specific code

Original Message >From: Richard Earnshaw >Sent: 15 April 2005 18:08 >> In any case, the ARM or Alpha isn't prevented from working in such a >> fashion just because the rounding mode is encoded in the instruction; it >> just means that fp primitives have to be compiled as intrinsics that

RE: Processor-specific code

Original Message >From: Paul Koning >Sent: 15 April 2005 17:56 >> "Dave" == Dave Korn <[EMAIL PROTECTED]> writes: > > Dave> Doesn't the C language spec require the mode to be switchable > Dave> at runtime? > > Dave> In any case, the ARM or Alpha isn't prevented from working in >

RE: Processor-specific code

On Fri, 2005-04-15 at 17:49, Dave Korn wrote: > Original Message > >From: Richard Earnshaw > >Sent: 15 April 2005 17:42 > > > On Fri, 2005-04-15 at 15:50, Robert Dewar wrote: > >> Richard Earnshaw wrote: > >> > >>> Not all environments can change the rounding mode dynamically. For > >>>

RE: Processor-specific code

> "Dave" == Dave Korn <[EMAIL PROTECTED]> writes: Dave> Doesn't the C language spec require the mode to be switchable Dave> at runtime? Dave> In any case, the ARM or Alpha isn't prevented from working in Dave> such a fashion just because the rounding mode is encoded in the Dave> instruct

RE: Processor-specific code

Original Message >From: Richard Earnshaw >Sent: 15 April 2005 17:42 > On Fri, 2005-04-15 at 15:50, Robert Dewar wrote: >> Richard Earnshaw wrote: >> >>> Not all environments can change the rounding mode dynamically. For >>> example, on the FPA co-processor for ARM, rounding is set by the

Re: Processor-specific code

On Fri, 2005-04-15 at 15:50, Robert Dewar wrote: > Richard Earnshaw wrote: > > > Not all environments can change the rounding mode dynamically. For > > example, on the FPA co-processor for ARM, rounding is set by the > > instruction selected -- so the concept of having an environment variable > >

Re: Processor-specific code

Richard Earnshaw wrote: Not all environments can change the rounding mode dynamically. For example, on the FPA co-processor for ARM, rounding is set by the instruction selected -- so the concept of having an environment variable to control this is meaningless. Right, such a feature obviously does

Re: Processor-specific code

On Thu, 2005-04-14 at 18:35, Richard Henderson wrote: > On Thu, Apr 14, 2005 at 05:27:16PM +0200, François-Xavier Coudert wrote: > > No, since reading GFORTRAN_FPU_* variables changes the FPU mode when the > > library is loaded, while TR 15580 commands will be ran afterwards (during > > execution

Re: Processor-specific code

[speaking of an environnement variable used to set IEEE rounding mode] You'll find that globally changing the rounding mode will screw up libm functions. Which is pretty much going to make this useless. Further, when folks need rounding modes other than round-to-nearest, they tend to need to switc

Re: Processor-specific code

On Thu, 14 Apr 2005, Richard Henderson wrote: > On Thu, Apr 14, 2005 at 10:47:26AM -0700, Steve Kargl wrote: > > Does gcc support > > #pragma STDC FENV_ACCESS > > No, but we currently act like access is "on". I thought we acted like it is "off", allowing CSE and constant folding which might be

Re: Processor-specific code

On Thu, Apr 14, 2005 at 10:47:26AM -0700, Steve Kargl wrote: > Does gcc support > #pragma STDC FENV_ACCESS No, but we currently act like access is "on". r~

Re: Processor-specific code

On Apr 14, 2005, at 1:47 PM, Steve Kargl wrote: Does gcc support #pragma STDC FENV_ACCESS No, there is a bug about that somewhere. -- Pinski

Re: Processor-specific code

On Thu, Apr 14, 2005 at 10:35:06AM -0700, Richard Henderson wrote: > On Thu, Apr 14, 2005 at 05:27:16PM +0200, Fran?ois-Xavier Coudert wrote: > > No, since reading GFORTRAN_FPU_* variables changes the FPU mode when the > > library is loaded, while TR 15580 commands will be ran afterwards (during

Re: Processor-specific code

On Thu, Apr 14, 2005 at 05:27:16PM +0200, François-Xavier Coudert wrote: > No, since reading GFORTRAN_FPU_* variables changes the FPU mode when the > library is loaded, while TR 15580 commands will be ran afterwards (during > execution). You'll find that globally changing the rounding mode will

Re: Processor-specific code

Can you explain in a little more detail what you are trying to accomplish? gfortran can already pass the -m and -f options suppported by gcc. For example, -ffast-math works. Runtime library reads GFORTRAN_FPU_* environment variables if they exist, and set up the FPU accordingly. One other thing

Re: Processor-specific code

On Thu, Apr 14, 2005 at 04:39:30PM +0200, Fran??ois-Xavier Coudert wrote: > > I'm working on implementation of the different FPU options for libgfortran, > the runtime library for gfortran (e.g., on which floating-point exception > do we want a SIGFPE to be raised, what rounding-mode does the us

Processor-specific code

that, and we'll have to include some processor-specific code. How does the build system allow that? Can we have a system of MACRO defined depending on the target processor (something like TARGET_FPU_IS_PPC)? PS: If I said something stupid or offended your sense of riguor, please don'