[Cfp-interest 1522] Re: request for input

[Joseph Myers]

On Mon, 2 Mar 2020, Jim Thomas wrote:

> In trying to redo the annex for TS-3 to not require support for any 
> particular interchange and extended types, I feel more strongly that 
> this would be the more useful approach. I believe some implementations 
> need nomenclature and rules for at least one extra floating type (for 
> _Float16, _Float80, or _Float128 in particular), but would balk at 
> having to also support _Float32, _Float64, and _Float32x, especially 
> when they already support equivalent types as float and double.

There's no such thing as _Float80 (that's not a width corresponding to an 
IEEE interchange encoding).

If you already support an equivalent type, supporting the extra name, and 
corresponding function aliases, is easy (whether the type is a distinct 
type, which is what you want to simplify use of _Generic without needing 
conditions in the user code for whether the types are distinct or not, or 
just acts as a typedef name rather than a distinct type).

(If the type is a distinct type, it's very clear that e.g. the functions 
for _Float64 can have the same addresses as the functions for double, 
because little is specified about the results of converting function 
pointers from one type to another.  If it's a typedef, it's a bit less 
clear, see what I wrote in reflector message 14590 (25 Jan 2017), though 
normal library practice does often have e.g. ldexp = scalbn.)

> One of Jens's ideas was to replace new math functions with type-generic 
> macros. Though this is problematic for math functions in general (see 
> Joseph’s (SC22WG14.17170) N2426), these operations (that round result to 
> specified type) are somewhat special. IEC 60559 describes them as 
> generic operations, e.g., compare the IEC 60559 description of these 
> operations:

I think the same principle still applies to them - if e.g. libffi gets 
support for these types, then if you have normal functions any language 
runtime can bind to the functions, just like other C functions, without 
needing special C code, but if you only have type-generic macros then 
other-language bindings are more complicated.

> Implementations shall provide the following formatOf 
> general-computational operations, for destinations of all supported 
> arithmetic formats, and, for each destination format, for operands of 
> all supported arithmetic formats with the same radix as the destination 
> format.
> 
> ― formatOf-addition(source1, source2)
> 
> vs it’s description of other operations such as
> 
> Implementations shall provide the following homogeneous general-computational operations for all supported arithmetic formats: 
> 
> ― sourceFormat roundToIntegralTiesToEven(source)

The difference here is that formatOf-addition is one operation per format 
(with the format name as part of the operation name), generic over the 
other two formats, while roundToIntegralTiesToEven has a name independent 
of format and is generic over one format.  I.e. most operations are 
generic over at least one format in IEEE 754, and language bindings 
represent that in the most appropriate way for the language in question.  
I don't think the difference between a format name forming or not forming 
part of the name of the operation is relevant to type-specific versus 
type-generic bindings in C.

> Also, these operations (that round to narrower type) are correctly 
> rounded. So, for example, any faddsuffix function invocation would 
> produce the same result provided it’s arguments weren’t narrowed (with 
> loss of range and/or precision) to a parameter type, and It seems 

The tricky thing - the reason why the tgmath.h rules need to specify 
exactly how the underlying function is determined rather than just saying 
any function with wide-enough parameters is used - is integer types, which 
may get narrowed even when floating arguments don't (e.g. an 
implementation where binary64 is the widest floating-point format can't 
avoid narrowing long long arguments to these functions).

> What do you think?

Functions with defined parameter types are well-understood and work well 
in C and we know the TS specification for the functions can be implemented 
without problems.

Type-generic macros have proven much trickier in practice and many more 
issues have shown up in the past with attempts to specify particular 
type-generic macros in the standard C library.  I think we ended up with a 
reasonable specification for the tgmath.h macros after DR#13, but 
inventing type-generic macros is a high-risk area and I'd be wary of 
adding anything new there to the standard that doesn't come with 
implementation experience from the TS.

-- 
Joseph S. Myers
joseph at codesourcery.com