[Bug target/37072] New: -mfancy-math-387 should be the default in FreeBSD
-mno-fancy-math-387 disables generation of fsqrt, fsin, and several other instructions. It was needed long ago when FreeBSD supported FPUless 80386 and 80486 systems via a partial in-kernel emulator that couldn't cope with these instructions. Support for FPUless x86 machines was dropped many years ago, and the emulator is gone, so -mfancy-math-387 should be the default for FreeBSD. http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/gcc/config/i386/freebsd.h.diff?r1=1.75;r2=1.76 -- Summary: -mfancy-math-387 should be the default in FreeBSD Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: das at FreeBSD dot ORG GCC build triplet: amd64-undermydesk-freebsd GCC host triplet: amd64-undermydesk-freebsd GCC target triplet: i386-undermydesk-freebsd http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37072
[Bug c/37073] New: -fno-math-errno should be the default on FreeBSD
The FreeBSD math library doesn't support the SysV mistake of setting errno in
libm functions, and never has. As on Darwin, -fno-math-errno should be the
default.
Darwin changes the default by adding an override for every relevant machine
config. There needs to be a cleaner way to do this.
Doc changes for this and bug 37072:
Index: doc/invoke.texi
===
--- doc/invoke.texi (revision 181538)
+++ doc/invoke.texi (working copy)
@@ -5677,7 +5677,8 @@
The default is @option{-fmath-errno}.
-On Darwin systems, the math library never sets @code{errno}. There is
therefore
+On Darwin and FreeBSD systems, the math library never sets @code{errno}.
+There is therefore
no reason for the compiler to consider the possibility that it might,
and @option{-fno-math-errno} is the default.
@@ -9507,7 +9508,7 @@
@opindex mno-fancy-math-387
Some 387 emulators do not support the @code{sin}, @code{cos} and
@code{sqrt} instructions for the 387. Specify this option to avoid
-generating those instructions. This option is the default on FreeBSD,
+generating those instructions. This option is the default on
OpenBSD and [EMAIL PROTECTED] This option is overridden when @option{-march}
indicates that the target cpu will always have an FPU and so the
instruction will not need emulation. As of revision 2.6.1, these
--
Summary: -fno-math-errno should be the default on FreeBSD
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: das at FreeBSD dot ORG
GCC build triplet: amd64-undermydesk-freebsd
GCC host triplet: amd64-undermydesk-freebsd
GCC target triplet: amd64-undermydesk-freebsd
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37073
[Bug tree-optimization/17884] asm 'volatile' is not honored as documented
--- Additional Comments From das at FreeBSD dot ORG 2005-01-14 21:34
---
Here's another test case that shows that gcc 3.4.2 on i386 will reschedule other
instructions (in particular, other asms that are not volatile) across a volatile
asm:
#include
#define __fldenv(env) __asm __volatile("fldenv %0" : : "m" (env))
#define __fnstsw(__sw) __asm("fnstsw %0" : "=am" (*(__sw)))
#define __ldmxcsr(csr) __asm __volatile("ldmxcsr %0" : : "m" (csr))
#define __stmxcsr(csr) __asm("stmxcsr %0" : "=m" (*(csr)))
typedef struct {
struct {
uint32_tcontrol;
uint32_tstatus;
uint32_ttag;
charother[16];
} x87;
uint32_tmxcsr;
} fenv_t;
int feraiseexcept(int __excepts);
int
feupdateenv(const fenv_t *envp)
{
int mxcsr, status;
__fnstsw(&status);
__stmxcsr(&mxcsr);
__fldenv(envp->x87);/* volatile */
__ldmxcsr(envp->mxcsr); /* volatile */
feraiseexcept((mxcsr | status) & 0x3f);
return (0);
}
The code generated at -O2 is as follows:
feupdateenv:
pushl %ebp
movl%esp, %ebp
subl$20, %esp
movl8(%ebp), %eax
#APP
fnstsw -4(%ebp)
stmxcsr -8(%ebp)
fldenv (%eax)
ldmxcsr 28(%eax)
fnstsw %eax <--- should be movl -4(%ebp), %eax
#NO_APP
orl -8(%ebp), %eax
andl$63, %eax
pushl %eax
callferaiseexcept
xorl%eax, %eax
leave
ret
The fnstsw is moved (duplicated, actually) across the fldenv and ldmxcsr, which
are volatile. At -O1, gcc gets this "right".
My vote is to fix the code rather than the documentation; if volatile asms don't
act as sequence points, then in code such as the above, it becomes necessary to
apply the sledgehammer of marking *all* asms volatile. This is because there's
no way to express to gcc that an asm reads from a hard register such as the
FPSR. If the instructions that write the FPSR (already marked volatile in the
example) acted as sequence points, we would be guaranteed that instructions that
read the FPSR could not be moved past them, without having to make the latter
volatile.
Note that even if you don't go with my idea, the following proposal isn't quite
accurate:
> From this it appears that the only effect of 'asm volatile' that users
> can safely rely on is that such an instruction will not be deleted.
It is also true (hopefully) that volatile asms cannot be reordered with respect
to each other, w.r.t. function calls, etc. This is not true of ordinary asms,
as seen above.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17884
[Bug target/17778] [3.4/4.0 Regression] regression in evaluating long double hexadecimal constants
--- Additional Comments From das at FreeBSD dot ORG 2004-11-12 03:54 --- Subject: Re: [3.4/4.0 Regression] regression in evaluating long double hexadecimal constants Yes, this appears to fix the problem. Thanks! Your timing is impeccable, by the way. Over in FreeBSDland, this bug recently generated discussion about whether we really need to reduce the npx precision on i386 anymore. The precision was originally reduced because gcc didn't used to evaluate expressions involving doubles with the appropriate rounding when the FPU rounding mode was set to extended precision, but gcc seems to be somewhat better in this respect in 3.X. I think the consensus is that we would like to move to extended precision, but it's not yet clear how to do this without breaking older programs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17778
