This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Adding __float128 (i.e TS 18661-3) [v2]

On Fri, 10 Jun 2016, Paul E. Murphy wrote:

> 	Implementation support for the ISO C11 7.12.3
> 	classification macros:
>         __finiteF
>         __fpclassifyF
>         __isinfF
>         __isnanF
>         __issignalingF
>         __signbitF

Noting that, if we add support for _FloatN / _FloatNx APIs in future in 
cases where those types are ABI-compatible with another type that already 
has such __* functions, exported aliases are *not* added for those 
internal functions.  For example, if a platform where long double is 
binary128 gains *f128 API support, then the public functions would get 
public *f128 aliases (so they can be used without including system 
headers, as allowed by ISO C), but there would be no __finitef128 alias, 
etc. (and the same would apply to __*_finite in that case).  (Cf. how in 
the case where long double = double, such functions only have *l aliases 
as compat symbols if LDBL_CLASSIFY_COMPAT because they were unnecessarily 
exported on some platforms but new platforms should not have those 

> Likewise, through libm via complex.h:
>         cbrtF
>         ceilF

These are math.h functions, not complex.h functions.

> Macros needing altered in math.h:

>         signbit

Remark on signbit: in GCC 6, __builtin_signbit is type-generic and works 
with sNaNs.  So with GCC 6, you don't actually need __signbitF backing 
functions.  But (a) there would still need to be a new __GNUC_PREREQ (6, 
0) definition of signbit in math.h using type-generic __builtin_signbit 
and (b) __signbitF might still be relevant for working with any non-GNU 
compilers without type-generic __builtin_signbit but with __float128 

> [8] Does this imply a case whereby __STDC_WANT_IEC_60559_TYPES_EXT__ is 
> defined, but not __STDC_WANT_IEC_60559_BFP_EXT__ within tgmath.h which 
> would result in next{up,down}F being declared but not 
> next{up,down}{f,,l} when using the next{up,down} macros?

If __STDC_WANT_IEC_60559_BFP_EXT__ is not defined, <tgmath.h> does not 
define nextup and nextdown macros at all.  See where TS 18661-1 says 
"After 7.25#1, insert the paragraph: [1a] The following identifiers are 
defined as type-generic macros only if __STDC_WANT_IEC_60559_BFP_EXT__ is 
defined as a macro at the point in the source file where <tgmath.h> is 
first included:".  TS 18661-2 modifies this to define some of those macros 
also if __STDC_WANT_IEC_60559_DFP_EXT__ is defined, but that's not 
relevant to glibc; TS 18661-3 does not modify it further, so if you define 
__STDC_WANT_IEC_60559_TYPES_EXT__ but neither 
__STDC_WANT_IEC_60559_BFP_EXT__ nor __STDC_WANT_IEC_60559_DFP_EXT__ then 
you get nextup for the new types but not the old ones, and no nextup 
type-generic macro.

Joseph S. Myers

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]