GNU bug report logs - #69770
[PATCH] build: strengthen 16 bit float support checks

Previous Next

Full log

Message #28 received at 69770 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pádraig Brady <P <at> draigBrady.com>,
 Grisha Levit <grishalevit <at> gmail.com>, 69770 <at> debbugs.gnu.org
Subject: Re: bug#69770: [PATCH] build: strengthen 16 bit float support checks
Date: Thu, 14 Mar 2024 22:21:11 -0700

On 2024-03-14 06:03, Pádraig Brady wrote:
> 
>> How about leaving it AC_COMPILE_IFELSE, but ensuring that -O1 or better
>> is used when the compiler supports -O1? That way we don't have to worry
>> about running the program, because (with the "volatile") clang will
>> error out.
>>
>> Alternatively perhaps there's some way to check for the bug using
>> preprocessor macros like __FLT16_MANT_DIG__, __FLT16_MAX_EXP__,
>> __clang_major__, and __aarch64__. (This could be more fragile, though,
>> as clang presumably will fix the bug eventually.)
> 
> That would probably work for this edge case, but it's brittle
> and I'm worried about other combinations of
> compiler versions, complier options, and architectures.

Sure, but one cannot resolve such worries completely, as compiler errors 
are inherently brittle: even a runtime test cannot prove their absence.

As I understand it, __bf16 is a real zoo: sometimes hardware supports 
it, sometimes it doesn't, sometimes the software emulation library is 
there, sometimes it's not, and so forth. Running a program on a 
development host is likely to not match the runtime behavior on a 
production host, so AC_RUN_IFELSE is reasonably likely to produce a 
false positive, which is worse than a false negative.

Another issue, which is somewhat related, is that coreutils's current 
macro BF16_SUPPORTED is too broad. Because __bf16 has so many bugs, 
currently it's probably a mistake to say __bf16 is fully supported 
anywhere. Even GCC is buggy; see for example:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114347

which I just now discovered when writing this email. The question isn't 
so much whether __bf16 is supported, it's whether it's supported well 
enough to compile and run GNU od.


Come to think of it, for 'od' we might be better off avoiding __bf16 
entirely, and simply converting the bits by hand into a 'float' 
variable. This would likely be more portable, as it would work even with 
compilers that lack __bf16, or that have __bf16 bugs relevant to 'od'. 
And that way we could remove the configure-time test entirely. (There 
would be endianness issues but they're easily addressible.)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.