Package: coreutils;
Reported by: Michael Felt <mamfelt <at> gmail.com>
Date: Fri, 13 Jun 2014 13:39:01 UTC
Severity: normal
Done: Paul Eggert <eggert <at> cs.ucla.edu>
Bug is archived. No further changes may be made.
Message #46 received at 17773 <at> debbugs.gnu.org (full text, mbox):
From: Michael Felt <mamfelt <at> gmail.com> To: Pádraig Brady <P <at> draigbrady.com>, Paul Eggert <eggert <at> cs.ucla.edu> Cc: 17773 <at> debbugs.gnu.org Subject: Re: bug#17773: AIX build errors with coreutils-8.22 Date: Wed, 18 Jun 2014 21:51:38 +0200
[Message part 1 (text/plain, inline)]
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 <at> 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 <at> 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 <at> 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 <at> me
>>
>>
>> On Fri, Jun 13, 2014 at 5:37 PM, Pádraig Brady <P <at> 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.
>>>
>>
>>
>
[Message part 2 (text/html, inline)]
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.