RE: [PATCH] Aarch32/64: Support __FLT_EVAL_METHOD__ values other than 0, 1, 2

Torbjorn SVENSSON via Newlib <[email protected]>
Newsgroups gmane.comp.lib.newlib
Message-ID <AM6PR10MB219782B2F7F7A1264D56EEA181E59@AM6PR10MB2197.EURPRD10.PROD.OUTLOOK.COM>
Hello,

It would have been easier to review the patch if it was inline, but this will have to do anyway.
I think there is a typo in math.h. Aren't you supposed to do "#ifndef" and not "#ifdef"?

Kind regards,
Torbjörn


ST Restricted

-----Original Message-----
From: Newlib <[email protected]> On Behalf Of Andrea Corallo
Sent: den 4 april 2022 10:39
To: [email protected]
Cc: [email protected]
Subject: [PATCH] Aarch32/64: Support __FLT_EVAL_METHOD__ values other than 0, 1, 2

Hi all,

when _Float16 in native precision is supported GCC defines
__FLT_EVAL_METHOD__ to 16 as per ISO/IEC TS 18661-3.

Ex:

$ ./arm-none-eabi-gcc -mthumb -march=armv8.1-m.main+fp  -mfloat-abi=softfp -xc /dev/null -E -dM | grep FLT_EVAL
#define __FLT_EVAL_METHOD__ 16
#define __FLT_EVAL_METHOD_TS_18661_3__ 16

Unfortunately libc/include/math.h understands only values 0, 1 and 2
leading to have newlib non compilable for those configurations.

I think in newlib we should either:

1- Handle __FLT_EVAL_METHOD__ == 16
2- Build in a C mode which does not enable _Float16 (ex -std=c11)
3- Build without the _FloatN extensions -fpermitted-flt-eval-methods=c11

I think 1 should be the favorite approach.

ISO/IEC 9899:201x [1] suggests that for other values of FLT_EVAL_METHOD
other than 0, 1, 2 the definition of float_t and double_t is
implementation-defined.

The suggested patch implements that for arm and Aarch64.

Note, some previous discussion on this topic can be found here [2] as
follow-up to a patch addressing the same issue (only for the
case__FLT_EVAL_METHOD__ == 16 case).

Best Regards

  Andrea

[1] <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf>
[2] <https://sourceware.org/legacy-ml/newlib/2019/msg00597.html>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.