In article <[EMAIL PROTECTED]>, Bruce Evans<[EMAIL PROTECTED]> writes:
> Example of how fixing this breaks a similar assertion for DBL_ESPILON: > %%% > $ cat z.c [...] > $ cc -o z z.c > $ ./z > LDBL_EPSILON failed test 1 with prec 2 > $ cc -O -o z z.c. > $ ./z > LDBL_EPSILON failed test 1 with prec 2 > DBL_EPSILON failed test 2 with prec 3 > %%% > The full brokenness only shows up with -O. 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)? Regards, Loren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
