cvs commit: src/lib/msun/alpha fenv.h src/lib/msun/amd64 fenv.h
src/lib/msun/arm fenv.h src/lib/msun/i387 fenv.h src/lib/msun/ia64
fenv.h src/lib/msun/powerpc fenv.h src/lib/msun/sparc64 fenv.h
kris at obsecurity.org
Fri Jan 14 05:28:30 PST 2005
On Fri, Jan 14, 2005 at 08:24:33AM -0500, David Schultz wrote:
> On Fri, Jan 14, 2005, Kris Kennaway wrote:
> > On Fri, Jan 14, 2005 at 07:09:23AM +0000, David Schultz wrote:
> > > das 2005-01-14 07:09:23 UTC
> > >
> > > FreeBSD src repository
> > >
> > > Modified files:
> > > lib/msun/alpha fenv.h
> > > lib/msun/amd64 fenv.h
> > > lib/msun/arm fenv.h
> > > lib/msun/i387 fenv.h
> > > lib/msun/ia64 fenv.h
> > > lib/msun/powerpc fenv.h
> > > lib/msun/sparc64 fenv.h
> > > Log:
> > > Mark all inline asms that read the floating-point control or status
> > > registers as volatile. Instructions that *wrote* to FP state were
> > > already marked volatile, but apparently gcc has license to move
> > > non-volatile asms past volatile asms. This broke amd64's feupdateenv
> > > at -O2 due to a WAR conflict between fnstsw and fldenv there.
> > Do you think this is likely to the cause of the build failures
> > reported with a number of ports when world is compiled with -O2
> > (i.e. does the feupdateenv failure cascade to other commonly-used
> > parts of the code)?
> No, this would lead to a runtime failure, and I would be surprised
> if very many ports use fenv.h anyway.
Someone needs to revert amd64 back to using -O in the meantime, then.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-amd64/attachments/20050114/858532ee/attachment.bin
More information about the freebsd-amd64