public inbox for glibc-cvs@sourceware.org
help / color / mirror / Atom feed
* [glibc] Define __STDC_IEC_60559_BFP__ and __STDC_IEC_60559_COMPLEX__
@ 2021-09-24 20:12 Joseph Myers
  0 siblings, 0 replies; only message in thread
From: Joseph Myers @ 2021-09-24 20:12 UTC (permalink / raw)
  To: glibc-cvs

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=8807e560c04cdaac1c7cca2c2104e43156b2708d

commit 8807e560c04cdaac1c7cca2c2104e43156b2708d
Author: Joseph Myers <joseph@codesourcery.com>
Date:   Fri Sep 24 20:11:56 2021 +0000

    Define __STDC_IEC_60559_BFP__ and __STDC_IEC_60559_COMPLEX__
    
    TS 18661-1 and C2X specify predefined macros __STDC_IEC_60559_BFP__
    and __STDC_IEC_60559_COMPLEX__, making __STDC_IEC_559__ and
    __STDC_IEC_559_COMPLEX__ obsolescent (but still included in the
    standard).  Now that we have all the functions from TS 18661-1, define
    these macros in stdc-predef.h, under the same conditions in which the
    older macros are defined, since support for the floating-point
    features in TS 18661-1 is now at the same level as that for those in
    C11 and before (all library functions and other library APIs present,
    but no standard pragma support).
    
    The macros are defined for now with their TS 18661-1 values.  C2X will
    give them new values (listed as yyyymmL in the working drafts until
    the final standard), at which point there will be the question of what
    value to use in stdc-predef.h (where it could depend on
    __STDC_VERSION__, but not on feature test macros defined by the user).
    My inclination then would be to use the C2X value unconditionally
    rather than using an older value to indicate TS support, and only have
    any C standard version conditionals for the value when subsequent C
    standard versions define further values.
    
    (Note that I'm also inclined, when we implement the C2X change to the
    return types of fromfp functions, to make that change unconditional
    much like the change made to the types of totalorder functions, with
    the old version only supported with compat symbols for already-linked
    programs and not as an API for newly built objects.  So using the C2X
    value would also accurately reflect not supporting the versions of
    APIs in the TS where those ended up being incompatible with the first
    version actually added to the standard.)
    
    Tested for x86_64.

Diff:
---
 NEWS                  | 3 +++
 include/stdc-predef.h | 4 ++++
 2 files changed, 7 insertions(+)

diff --git a/NEWS b/NEWS
index 889578bf39..9ae04b2f20 100644
--- a/NEWS
+++ b/NEWS
@@ -32,6 +32,9 @@ Major new features:
   - ffma, ffmal, dfmal and corresponding fMfmafN, fMfmafNx, fMxfmafN and
     fMxfmafNx functions.
 
+* The __STDC_IEC_60559_BFP__ and __STDC_IEC_60559_COMPLEX__ macros are
+  predefined as specified in TS 18661-1:2014.
+
 Deprecated and removed features, and other changes affecting compatibility:
 
 * The r_version update in the debugger interface makes the glibc binary
diff --git a/include/stdc-predef.h b/include/stdc-predef.h
index e130c462a7..ea9425277b 100644
--- a/include/stdc-predef.h
+++ b/include/stdc-predef.h
@@ -36,17 +36,21 @@
 #ifdef __GCC_IEC_559
 # if __GCC_IEC_559 > 0
 #  define __STDC_IEC_559__		1
+#  define __STDC_IEC_60559_BFP__ 	201404L
 # endif
 #else
 # define __STDC_IEC_559__		1
+# define __STDC_IEC_60559_BFP__ 	201404L
 #endif
 
 #ifdef __GCC_IEC_559_COMPLEX
 # if __GCC_IEC_559_COMPLEX > 0
 #  define __STDC_IEC_559_COMPLEX__	1
+#  define __STDC_IEC_60559_COMPLEX__	201404L
 # endif
 #else
 # define __STDC_IEC_559_COMPLEX__	1
+# define __STDC_IEC_60559_COMPLEX__	201404L
 #endif
 
 /* wchar_t uses Unicode 10.0.0.  Version 10.0 of the Unicode Standard is


^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2021-09-24 20:12 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-09-24 20:12 [glibc] Define __STDC_IEC_60559_BFP__ and __STDC_IEC_60559_COMPLEX__ Joseph Myers

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).