float, math: Fix 'int' to 'long double' conversion on Linux/SPARC64

2011-09-30 Thread Bruno Haible
It started as a test failure on Linux/SPARC64: test-logl.c:42: assertion failed FAIL: test-logl I tried to fix it by activating the gnulib replacement code for logl(). But the bug persisted. Debugging it in detail, it turned out to be a bug in the 'int' to 'long double' conversion. The glibc

Re: Getting AC_PROG_CC_C99

2011-09-30 Thread Paul Eggert
On 09/30/11 08:57, Andrew W. Nosenko wrote: > Assuming that AC_PROG_CC_C99 is not available (e.g. doesn't exists and > never existed), and only one macro is AC_PROG_CC_STDC, how I should to > express that "c99 is required"? Or "c99 or better is required"? Right now, you can't. That would need to

Re: Getting AC_PROG_CC_C99

2011-09-30 Thread Andrew W. Nosenko
On Fri, Sep 30, 2011 at 17:02, Paul Eggert wrote: > On 09/30/11 02:06, Bruno Haible wrote: >>  -- Macro: AC_PROG_CC_STDC >>      If the C compiler cannot compile ISO Standard C (currently C99), >>      ... >> >> sounds like this macro will then be modified to enable C1X instead of C99. > > Yes. >

utimens failures on Linux

2011-09-30 Thread Bruno Haible
Hi Eric, On a Linux 2.6.32 / PowerPC machine [1], I'm seeing these three test failures: test-futimens.h:144: assertion failed FAIL: test-futimens test-utimens.h:121: assertion failed FAIL: test-utimens test-utimens.h:121: assertion failed FAIL: test-utimensat Both in 32-bit and in 64

Re: Getting AC_PROG_CC_C99

2011-09-30 Thread Gary V. Vaughan
[Re-adding bug-autoconf] Hi Bruno, On 30 Sep 2011, at 16:56, Bruno Haible wrote: > Gary V. Vaughan wrote: >> But why emit a warning when >> we can just fix-up the definition on the fly? ... >> This changeset fixes AC_PROG_CC_C99 >> (and effectively AC_PROG_CC_STDC) whether it is called before or

Re: Getting AC_PROG_CC_C99

2011-09-30 Thread Paul Eggert
On 09/30/11 02:06, Bruno Haible wrote: > -- Macro: AC_PROG_CC_STDC > If the C compiler cannot compile ISO Standard C (currently C99), > ... > > sounds like this macro will then be modified to enable C1X instead of C99. Yes. > But I expect that many packages will not need this. It sho

Re: Getting AC_PROG_CC_C99

2011-09-30 Thread Bruno Haible
Gary V. Vaughan wrote: > I don't think many users will find this before they are already bitten. > > IMHO, the two main places in gnulib that people see instructions are in > the output of gnulib-tool itself: > > ... > Don't forget to > ... > - invoke gl_EARLY in ./configure.ac, right aft

Re: Getting AC_PROG_CC_C99

2011-09-30 Thread Bruno Haible
Gary V. Vaughan wrote: > But why emit a warning when > we can just fix-up the definition on the fly? ... > This changeset fixes AC_PROG_CC_C99 > (and effectively AC_PROG_CC_STDC) whether it is called before or > after gl_EARLY, directly or by AC_PROG_CC_STDC, or even not at all! > ... > +[AC_PROVID

Re: Getting AC_PROG_CC_C99

2011-09-30 Thread Bruno Haible
Paul Eggert wrote: > I don't think the autoconf patch would be that easy, as one would > need to handle a mixture of AC_PROG_CC_C99, AC_PROG_CC_C89, and > AC_PROG_CC_STDC calls. Again, I expect the only thing that's > saved us is that people just use AC_PROG_CC_STDC. Hmm, maybe > Autoconf should

Re: Getting AC_PROG_CC_C99

2011-09-30 Thread Bruno Haible
Gary V. Vaughan wrote: > > Do you have some specific modules in mind which could > > be simplified by use of AC_REQUIRE([AC_PROG_CC_STDC])? > > I hadn't even considered the possibility of simplifying any specific macros, > I was thinking entirely about whether whole modules could be skipped by > p