On Thu, 31 Oct 2002, Loren James Rittle wrote: > In article <[EMAIL PROTECTED]>, > Bruce Evans<[EMAIL PROTECTED]> writes: > > When I run your program against gcc mainline (for 3.3 release) with > the patch I have staged from RTH to correctly match our FP hardware > default setup, I see: > > S rittle@latour; /usr/local/beta-gcc/bin/gcc t.c > S rittle@latour; a.out > LDBL_EPSILON failed test 2 with prec 3 > S rittle@latour; /usr/local/beta-gcc/bin/gcc -O t.c > S rittle@latour; a.out > LDBL_EPSILON failed test 2 with prec 3 > DBL_EPSILON failed test 2 with prec 3 > S rittle@latour; /usr/local/beta-gcc/bin/gcc -O2 t.c > S rittle@latour; a.out > LDBL_EPSILON failed test 2 with prec 3 > DBL_EPSILON failed test 2 with prec 3 > S rittle@latour; /usr/local/beta-gcc/bin/gcc -O3 t.c > S rittle@latour; a.out > LDBL_EPSILON failed test 2 with prec 3 > DBL_EPSILON failed test 2 with prec 3 > > I.e. the only time it "fails" is when the user made a call to change > the default precision. Is that gcc 3.3 behavior acceptable (at least > until gcc can be further refined to attempt to handle user override of > the FP control word)?
Yes, this is the correct behaviour IMO. I don't see how any user override of the control word (except possibly of the rounding mode) can be expected to work right outside of an FENV_ACCESS section. Constants like DBL_EPSILON presumably don't apply in such sections. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
