Angelo Graziosi wrote:
> Dave Korn wrote:
>> IIUC this is basically fixed in GCC
>> HEAD now and 4.5.0 shouldn't suffer the same problem.
>
> Just for completeness...
>
> With 4.5-20090827 snapshot, it does:
>
> $ g++-4.5 arg_bug.cpp -o0 -o arg_bug
>
> $ ./arg_bug.exe
> 0.785398
> 0.785398
> 1
> -3.06287e-17
Thanks for checking up on this. It's possible we might need to add some
kind of fpu mode init to the CRT. On the other hand, comment #127 in the PR
suggests to me that maybe we need to use the new command-line flag. Hang on a
minute... "-fexcess-precision=standard" works only for C and ObjC.
> $ g++-4 comp_2.cc -o0 -o comp_2 -I /usr/include/octave-3.2.0/octave
>
> $ ./comp_2.exe
> 0.785398
> 0.785398
> 1
> -3.06287e-17
>
> $ g++-4 comp_2.cc -o0 -o comp_2 -I /usr/include/octave-3.2.0/octave
> -fexcess-pr
> ecision=standard
> cc1plus: sorry, unimplemented: -fexcess-precision=standard for C++
>
> $
Bah. Still, at least the -ffloat-store workaround still helps, for this
case at any rate. Also, if you get GCC to use SSE instructions, there's no
issue with excess precision:
> $ g++-4 comp_2.cc -o0 -o comp_2 -I /usr/include/octave-3.2.0/octave
> -march=pent
> ium4 -msse -mfpmath=sse
>
> $ ./comp_2.exe
> 0.785398
> 0.785398
> 0
> 0
>
> $
However it does look like it's not going to get fully fixed for C++ until
someone with some serious language-lawyering skills can spend some time
defining the exact semantics.
cheers,
DaveK
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
