So, having looked at the -E output of the compiles I guess it has something to do with how enum defines it results. And how that gets parsed here:

Goes over my head in any case.

#define _GL_FLOAT_STRLEN_BOUND_L(t, pointlen)                          \
(1 + _GL_##t##_PREC_BOUND + pointlen + 1                             \
   + _GL_FLOAT_EXPONENT_STRLEN_BOUND (t##_MIN_10_EXP, t##_MAX_10_EXP))
#define FLT_STRLEN_BOUND_L(pointlen) _GL_FLOAT_STRLEN_BOUND_L ( FLT, pointlen)
#define DBL_STRLEN_BOUND_L(pointlen) _GL_FLOAT_STRLEN_BOUND_L ( DBL, pointlen)
#define LDBL_STRLEN_BOUND_L(pointlen) _GL_FLOAT_STRLEN_BOUND_L (LDBL, pointlen)

/* Looser bounds that are locale-independent and are integral constant
   expressions. */
#define FLT_STRLEN_BOUND FLT_STRLEN_BOUND_L (MB_LEN_MAX)
#define DBL_STRLEN_BOUND DBL_STRLEN_BOUND_L (MB_LEN_MAX)
#define LDBL_STRLEN_BOUND LDBL_STRLEN_BOUND_L (MB_LEN_MAX)

/* Looser, locale-independent bounds that include the trailing null byte. */
#define FLT_BUFSIZE_BOUND ( FLT_STRLEN_BOUND + 1)
#define DBL_BUFSIZE_BOUND ( DBL_STRLEN_BOUND + 1)
#define LDBL_BUFSIZE_BOUND (LDBL_STRLEN_BOUND + 1)

#endif /* _GL_FTOASTR_H */

Then in od.c we have this:
#define PRINT_FLOATTYPE(N, T, FTOASTR, BUFSIZE)                         \
PRINT_FIELDS (N, T, fmt_string _GL_UNUSED,                      \
                char buf[BUFSIZE];                                      \
                FTOASTR (buf, sizeof buf, 0, 0, x);                     \
                xprintf ("%*s", adjusted_width, buf))

PRINT_TYPE (print_s_char, signed char)
PRINT_TYPE (print_char, unsigned char)
PRINT_TYPE (print_s_short, short int)
PRINT_TYPE (print_short, unsigned short int)
PRINT_TYPE (print_int, unsigned int)
PRINT_TYPE (print_long, unsigned long int)
PRINT_TYPE (print_long_long, unsigned_long_long_int)

PRINT_FLOATTYPE (print_float, float, ftoastr, FLT_BUFSIZE_BOUND)
PRINT_FLOATTYPE (print_double, double, dtoastr, DBL_BUFSIZE_BOUND)
PRINT_FLOATTYPE (print_long_double, long double, ldtoastr, LDBL_BUFSIZE_BOUND)

which in od.i becomes (only the first PRINT_FLOATTYPE output), for readability.

static void print_float (size_t fields, size_t blank, void const *block, char const *fmt_string, int width, int pad) { float const *p = block; uintmax_t i;
int pad_remaining = pad; for (i = fields; blank < i; i--) { int next_pad = pad * (i - 1) / fields; int adjusted_width = pad_remaining - next_pad + width;
float x = *p++; char buf[( (1 + _GL_FLT_PREC_BOUND + 4 + 1 + ( -100 < (-37) && (38) < 100 ? 3 : -1000 < (-37) && (38) < 1000 ? 4 : -10000 < (-37) && (38) <
10000 ? 5 : -100000 < (-37) && (38) < 100000 ? 6 : -1000000 < (-37) && (38) < 1000000 ? 7 : ((((sizeof (int) * (8) - (! ((__typeof__ (int)) 0 < (__typeof_
_ (int)) -1))) * 146 + 484) / 485) + (! ((__typeof__ (int)) 0 < (__typeof__ (int)) -1))) )) + 1)]; ftoastr (buf, sizeof buf, 0, 0, x); xprintf ("%*s", adju
sted_width, buf); pad_remaining = next_pad; } }

Aren't macros fun!

Anyway, if this is the "workings" of the bug, then maybe I can get it submitted for a bugfix.

So, before I do any try and submit a bugreport to IBM - please verify that the above is "the bug" - perhaps showing how your compiler completes the "od.i" code.

Michael

On Wed, Jun 18, 2014 at 9:16 PM, Michael Felt <mamfelt@gmail.com> wrote:

I am confused by what is in git regarding ftoastr.h

The enum code has been around "forever" and not caused a problem. I think the problem lies elsewhere because version 8.20 builds fine.

root@x093:[/data/prj/gnu/coreutils]diff ./coreutils-8.22/lib/ftoastr.h ./coreutils-8.15/lib/ftoastr.h
3c3
<    Copyright (C) 2010-2013 Free Software Foundation, Inc.
---
>    Copyright (C) 2010-2012 Free Software Foundation, Inc.

So, I do not understand the why the change to ftoastr.h is being considered. The motivation that AIX compiler "has a bug" seems misleading as this identifer has worked well for ftoast.c for many years.

The simple "include" of ftoastr.h to src/od.c and src/getlimits.c seems to be making assumptions that ftoastr.c has not. So, maybe there is another more elegant solution?

On Wed, Jun 18, 2014 at 8:59 PM, Michael Felt <mamfelt@gmail.com> wrote:

Curious why you are calling this a compiler bug. I am not a POSIX nerd, but it looks as if the old code was compiler independent, and now it is dependent on something.

Just one difference in od.c that shows a change in identifer conventions.

What is the origin of the _GL_* identifiers? "Unix" or "Not Unix"?

from diff -u ./coreutils-8.20/src/od.c ./coreutils-8.22/src/od.c

@@ -1050,8 +1056,8 @@
}

static void
-format_address_none (uintmax_t address ATTRIBUTE_UNUSED,
-                     char c ATTRIBUTE_UNUSED)
+format_address_none (uintmax_t address _GL_UNUSED,
+                     char c _GL_UNUSED)
{
}

I also note that the identifiers involved go back to at least coreutils 8.9 in ./lib/ftoastr.h

So, this has been known, and managed, for a long time.

It is your code, so you can call it a bug if you wish - I am thinking, for now, that it is a dependency on something not found by default when using the xlc compilers. But I may be wrong :p@me

On Fri, Jun 13, 2014 at 5:37 PM, Pádraig Brady <P@draigbrady.com> wrote:

On 06/13/2014 02:38 PM, Michael Felt wrote:

> make[2]: Entering directory `/data/prj/gnu/coreutils/coreutils-8.22'
> CC src/od.o
> "src/od.c", line 432.47: 1506-045 (S) Undeclared identifier
> _GL_FLT_PREC_BOUND.

> CC src/getlimits.o

> "src/getlimits.c", line 112.53: 1506-045 (S) Undeclared identifier
> _GL_LDBL_PREC_BOUND.

I think Paul has already avoided this AIX compiler bug,
and so this will be fixed in the upcoming coreutils-8.23
http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=6f053ff1

thanks,
Pádraig.