[Cfp-interest 1490] Re: Action item: Constant expressions _Float16

[Damian McGuckin]

On Tue, 18 Feb 2020, Rajan Bhakta wrote:

> For my action item:
>    Rajan: Ensure casting to _Float16 won't cause a problem with the using
> INFINITY wherever a constant expression can be used change we proposed.
> 
> From 6.6p1, it fits the description.
> From 6.6p3 and 4 (constraints), none are violated.
> From 6.6p6 has floating constants as immediate operands of casts which
> applies if INFINITY is a floating constant.
> From 6.6p8 has casts on converting arithmetic to arithmetic types which fits
> this case as _Float16 is an interchange type which is a real floating type
> which is a floating type which is an arithmetic type, and INFINITY has a
> real floating type.
> From 6.4.4.2 it says INFINITY is not directly a floating constant (from the
> grammar). It needs to be constructed out of a digit-sequence or some other
> means.
> From 6.6p10, implementations can support other constant expressions. This
> catch-all seems to allow nearly anything.
> From 7.12p4 it says INFINITY IS a constant expression.
> 
> So given 7.12p4 + 6.6p8 I would say that casting to _Float16 will not cause
> a problem.

I agree. But if INFINITY appears in an otherwise _Float16 expression and 
the INFINITY is not cast to _Float16, won't that promote the _Float16 
expression to the type of INFINITY which is _Float32 or float?  Is that 
wanted?

My apologies if this has been addressed before I joined the conversation.

Regards - Damian

Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer