Eric Blake wrote:
> * m4/utimens.m4 (gl_UTIMENS): Include correct headers.
...
> diff --git a/m4/utimens.m4 b/m4/utimens.m4
...
> +#include
Thanks. That fixed it for me, too.
On 11/03/2010 05:10 PM, Eric Blake wrote:
> I'm running out of time today to get to the bottom of this, so if anyone
> else wants to help out, great. If not, I'll see if I can resume testing
> tomorrow and get a minimal test case that exposes the compiler bug, as
> well as try and isolate ways to
* tests/test-ceilf1.c (main): Ensure correct sign of result.
* tests/test-ceill.c (main): Likewise.
* tests/test-floorf1.c (main): Likewise.
* tests/test-floorl.c (main): Likewise.
* tests/test-round1.c (main): Likewise.
* tests/test-roundf1.c (main): Likewise.
* tests/test-roundl.c (main): Likewis
* m4/frexp.m4 (gl_FUNC_FREXP_WORKS): Compute -0.0 in a way that
works with more compilers.
* tests/minus-zero.h: New file.
* modules/ceilf-tests (Files): Include it.
* modules/ceill-tests (Files): Likewise.
* modules/floorf-tests (Files): Likewise.
* modules/floorl-tests (Files): Likewise.
* module
* lib/isnan.c (FUNC): Compute run-time NaN under ICC as well.
Signed-off-by: Eric Blake
---
On a Linux x86_64 system where isnan() fails to recognize pseudo-nan
long doubles, ICC 10.1 fails to compile isnan.c with:
../../gllib/isnan.c(133): error: floating-point operation result is out of range
Eric Blake writes:
> In my minus_zero cleanups, I noticed that these tests were rather
> weak; it's possible that there are implementations that return 0.0
> when they should be returning -0.0, so let's test that explicitly.
> The new checks should work even on systems that lack -0.0 (if there
>
Eric Blake writes:
> Refactors everything so that future compiler workarounds necessary
> to get at -0.0 can be limited to a single test file (.m4 files may
> need more efforts, though). Tested that all of these tests still
> pass with gcc; there are still some ICC failures, but I think they
> a
