From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 1A674384B06F; Tue, 1 Jun 2021 11:09:12 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1A674384B06F From: "acoplan at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/100854] New: TS 18661-3 and backwards-incompatible setting of __FLT_EVAL_METHOD__ Date: Tue, 01 Jun 2021 11:09:11 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c X-Bugzilla-Version: 12.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: acoplan at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2021 11:09:12 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D100854 Bug ID: 100854 Summary: TS 18661-3 and backwards-incompatible setting of __FLT_EVAL_METHOD__ Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: acoplan at gcc dot gnu.org Target Milestone: --- GCC implements TS 18661-3. On arm and aarch64, this means that an -march st= ring that includes fp16 results in GCC defining __FLT_EVAL_METHOD__ to 16. This is backwards-incompatible with libraries conforming to C99 which inter= pret values other than 0, 1, or 2 as implementation defined. See newlib's use of __FLT_EVAL_METHOD__ in math.h: https://sourceware.org/git/?p=3Dnewlib-cygwin.git;a=3Dblob;f=3Dnewlib/libc/= include/math.h;h=3Dba1a8a17ef4368eabb7a0d116f50b6a7d34546ce;hb=3DHEAD#l144 On AArch64, we define three variants of __FLT_EVAL_METHOD__: $ aarch64-linux-gnu-gcc -xc /dev/null -E -dM | grep FLT_EVAL #define __FLT_EVAL_METHOD__ 0 #define __FLT_EVAL_METHOD_TS_18661_3__ 0 #define __FLT_EVAL_METHOD_C99__ 0 Adding fp16 to the -march, we see that all three of these macros take the v= alue 16: $ aarch64-linux-gnu-gcc -march=3Darmv8.2-a+fp16 -xc /dev/null -E -dM | grep FLT_EVAL #define __FLT_EVAL_METHOD__ 16 #define __FLT_EVAL_METHOD_TS_18661_3__ 16 #define __FLT_EVAL_METHOD_C99__ 16 This is a little surprising. Based on the name of __FLT_EVAL_METHOD_C99__, = you might expect it to only take values defined by C99. Forcing -std=3Dc99, we see that __FLT_EVAL_METHOD__ itself takes a C99-conf= orming value, but the others do not: $ aarch64-linux-gnu-gcc -march=3Darmv8.2-a+fp16 -std=3Dc99 -xc /dev/null -E= -dM | grep FLT_EVAL #define __FLT_EVAL_METHOD__ 0 #define __FLT_EVAL_METHOD_TS_18661_3__ 16 #define __FLT_EVAL_METHOD_C99__ 16 It seems that the behaviour of __FLT_EVAL_METHOD_C99__ is the exact opposit= e of what the name suggests. Notably the __FLT_EVAL_METHOD_C99__ macro is AArch64-specific. It isn't implemented on the arm port: $ ./arm-eabi-gcc -xc /dev/null -E -dM -march=3Darmv8-a+simd | grep FLT_EVAL #define __FLT_EVAL_METHOD__ 0 #define __FLT_EVAL_METHOD_TS_18661_3__ 0 $ ./arm-eabi-gcc -xc /dev/null -E -dM -march=3Darmv8.2-a+fp16 | grep FLT_EV= AL #define __FLT_EVAL_METHOD__ 16 #define __FLT_EVAL_METHOD_TS_18661_3__ 16 $ ./arm-eabi-gcc -xc /dev/null -E -dM -march=3Darmv8.2-a+fp16 -std=3Dc99 | = grep FLT_EVAL #define __FLT_EVAL_METHOD__ 0 #define __FLT_EVAL_METHOD_TS_18661_3__ 16 It would be useful if GCC provided a portable pre-defined __FLT_EVAL_METHOD= __ variant that was guaranteed to only take values defined by C99/C11. As it stands, GCC with -march=3Darmv8.2-a+fp16 (or any -mcpu/-march that implies = fp16) on arm and aarch64 fails to compile any file that includes newlib's math.h. This could be considered a bug in TS 18661-3 which stipulates that __FLT_EVAL_METHOD__ take backwards-incompatible values. Either way, it seems that GCC should provide a way to recover a conforming __FLT_EVAL_METHOD__ without forcing the user to compile everything in a strict standards-confor= ming mode (-std=3Dc{99,11}). At a minimum, the __FLT_EVAL_METHOD_C99__ builtin macro should probably be removed from the AArch64 backend as its current behaviour is entirely unhelpful. Ideally, GCC would define a new macro (portable across all architectures implementing fp16) which is guaranteed to only take values defined by C99/C= 11.=