Re: Are f.p. manipulation functions only used in initialization?

"FX" <coudert@xxxxxxxxxxxxx> wrote in message
news:fvqh4r$1n5d$1@xxxxxxxxxxxxx

Is there some way to 'unfix' PR323 so that Win64 works like gawd &
Billy Kahan intended?

If you expect any kind of answer, you need to provide a clear,
self-contained question.

C:\gfortran\clf\kahan>type finit.s
.text
..globl _xfinit_
.def _xfinit_; .scl 2; .type 32; .endef
_xfinit_:
..globl XFINIT
.def XFINIT; .scl 2; .type 32; .endef
XFINIT:
finit
ret
..globl _getcw_
.def _getcw_; .scl 2; .type 32; .endef
_getcw_:
..globl GETCW
.def GETCW; .scl 2; .type 32; .endef
GETCW:
xorl %eax, %eax
push %rax
fstcw (%rsp)
pop %rax
ret

C:\gfortran\clf\kahan>type kahan.f90
program kahan
implicit none
integer, parameter :: C_INT16_T = selected_int_kind(4)
integer(C_INT16_T), external :: getcw

write(*,'(a,z4.4)') 'Initial control word = ', getcw()
call xfinit
write(*,'(a,z4.4)') 'After reset control word = ', getcw()
end program kahan

C:\gfortran\clf\kahan>as finit.s -ofinit.o

C:\gfortran\clf\kahan>gfortran kahan.f90 finit.o -okahan

C:\gfortran\clf\kahan>kahan
Initial control word = 027F
After reset control word = 037F

C:\gfortran\clf\kahan>ifort kahan.f90 finit.o
Intel(R) Fortran Compiler for Intel(R) EM64T-based applications, Version 9.1
Build 20061104
Copyright (C) 1985-2006 Intel Corporation. All rights reserved.
ifort: Command line warning: unrecognized source type 'finit.o'; object file
ass
umed

Microsoft (R) Incremental Linker Version 8.00.40310.39
Copyright (C) Microsoft Corporation. All rights reserved.

-out:kahan.exe
-subsystem:console
kahan.obj
finit.o

C:\gfortran\clf\kahan>kahan
Initial control word = 027F
After reset control word = 037F

The problem is that on Win64, the default value for the floating
point control word seems to be z'027F' which sets precision control
to 53 bits. This is not an issue for ifort because its extra
precision KIND is quadruple precision. For gfortran this is a big
problem because its extra precision KIND is extended precision and
so needs precision control set to 64 bits. As can be seen from the
above example, if gfortran were sporting enough to just issue an
FINIT at program start, precision control would be set to 64 bits
and life could go on from there. It's rather silly to set precision
control at 53 bits as Microsoft seems to want to do because on Win64
you are guaranteed SSE2 so that if you wanted to avoid 80-bit (i.e.
64-bit precision) temporaries you could just use SSE2 for your
calculations and your code would be more performant as well.

Setting the hardware default, z'037F', as by FINIT on program entry
seems to me to make sense on Win64, but I am not sure whether some
Microsoft library that gfortran needs will behave in an unexpected
manner given this setting. For sure REAL(10) arithmetic is busted
without this setting. Microsoft doesn't know if they are on foot or
horseback regarding x87 on Win64. For e.g. an early version of ml64
considered mmx operations an error because the programmers for that
assembler had heard a rumor that Win64 wouldn't preserve x87 state
across task switches. In fact it's only for ring-0 code that x87
state doesn't get preserved, so for ordinary ring-3 code x87 and so
mmx operations are OK.

The gcc docs state that 64-bit precision (as opposed to 53-bit
precision) is the default but these docs are hopelessly out of date
for Win64.

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end


.

Relevant Pages

  • Re: critical floating point incompatibility
    ... this value sets the precision ... The default setting of the x87 floating ... point control word on the AMD64 is 0x37F. ... environment to the i386 default for i386 binaries. ...
    (freebsd-hackers)
  • Re: critical floating point incompatibility
    ... this value sets the precision ... point control word on the AMD64 is 0x37F. ... environment to the i386 default for i386 binaries. ... program Carl had sent me more than a year ago for testing ...
    (freebsd-hackers)
  • Re: critical floating point incompatibility
    ... port is 0x127F. ... this value sets the precision ... The default setting of the x87 floating ... point control word on the AMD64 is 0x37F. ...
    (freebsd-hackers)
  • Re: Display of Single Data Exported
    ... So, Access provides the currency data type, which is not a floating point ... It stores exactly 4 places of precision after the ... Microsoft introduced a scalable point data type - a Number ...
    (microsoft.public.access.tablesdbdesign)
  • Re: LDBL_MAX -1.#QNAN0e+000 with MinGW?
    ... Microsoft is perfectly right to do that since the C standard EXPLICITELY ... the compiler to the run time library and this is surely not Microsoft's ... there are numbers that are rappresentable with 80bit float ... The CPU is in 64 Bit (double precision), ...
    (comp.lang.c)
Loading