On Fri, Jun 28, 2013 at 11:25:26AM -0600, Eric Blake wrote:
> On 06/27/2013 08:29 PM, Jack Howarth wrote:
> > I have identified the difference between the builds of m4 1.4.16 on
> > darwin11,
> > which doesn't exhibit the test-vasprintf-posix failure in the m4 testsuite,
> > and
>
> Thanks for the report. m4 1.4.16 uses an old version of gnulib; can you
> please retest with the latest m4.git:branch-1.4 contents? If that fixes
> the problem (because it uses newer gnulib), then I have nothing further
> to do (except release m4 1.4.17 - still on my todo list); if it still
> reproduces, then we should take this report upstream to gnulib.
Eric,
I am not having any luck with the bootstrap working if I do...
git clone git://git.savannah.gnu.org/m4.git
cd m4
bootstrap
It fails with...
Makefile.am:152: error: 'pkglibexecdir' is not a legitimate directory for
'LTLIBRARIES'
This is against fink's autoconf 2.69 and automake 1.12. Can you email me a
tarball of
the regenerated m4 trunk directory?
Jack
ps Jeremy Huddleston Sequoia at Apple had the following observations...
-------------------------------------------------------------------------------------------------------------------------
The fact that result=0 is a good thing. That conftest is producing a bitmask
of bugs it hit. In the case of Snow Leopard,
+it hit:
/* This catches a FreeBSD 6.1 bug: it doesn't round. */
if (sprintf (buf, "%.2a %d", 1.51, 33, 44, 55) < 0
|| (strcmp (buf, "0x1.83p+0 33") != 0
&& strcmp (buf, "0x3.05p-1 33") != 0
&& strcmp (buf, "0x6.0ap-2 33") != 0
&& strcmp (buf, "0xc.14p-3 33") != 0))
result |= 4;
/* This catches a FreeBSD 6.1 bug. See
<http://lists.gnu.org/archive/html/bug-gnulib/2007-04/msg00107.html> */
if (sprintf (buf, "%010a %d", 1.0 / 0.0, 33, 44, 55) < 0
|| buf[0] == '0')
result |= 8;
And on Lion, it just hits the result=4 case
---------------------------------------------------------------------------------------------------------------------------
It looks like they're trying to catch the same bug as conftest.c but chose %.0a
which revealed something different.
If we change 1.51 to 1.52, it passes … so this looks like a rounding issue.
#include <assert.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int main() {
char *result;
int retval = asprintf (&result, "%.0a %d", 1.51, 33, 44, 55);
printf("result: %s\n", result);
assert(result != NULL);
assert(strcmp (result, "0x2p+0 33") == 0 || strcmp (result, "0x3p-1 33") ==
0 || strcmp (result, "0x6p-2 33") == 0 ||
+strcmp (result, "0xcp-3 33") == 0);
assert(retval == strlen (result));
free(result);
return 0;
}
--------------------------------------------------------------------------------------------------------------------------
It's not a numerics issue. The actual bits in memory are correct. It looks
like just a formatting issue, so it's likely
+something in gdtoa.
conftest is correct in that we don't have *THAT* bug.
The test-vasprintf-posix in m4 incorrectly assumes we do have that bug because
we fail that assert, but it's really tripping
+over this:
printf("%.0a\n", 1.51);
-- SL: 0x2p+0
-- Lion: 0x2p+0
-- ML: 0x1p+0
-- Cab: 0x1p+0
I'd recommend changing the m4 test from 1.51 to 1.52 and then possibly adding
another check for this rounding bug if that
+matters to them.
>
> --
> Eric Blake eblake redhat com +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
>
