The number of trailing 0s is significant. The lexer/parser looks at the length of the token to determine what type the value is.
I’d like to confirm the proposed option for enabling HexFloat.
We propose to introduce the -mzos-float-kind=hex|ieee flag to select the floating point representation format be used. This option will be recognized only if the appropriate -target/-triple is given. If -moos-float-kind is not given, then the default for the target will be used.
Does that imply that an exact number of digits must be supplied for the literal to be valid? E.g., 0xS0000000. and 0xS000000000. are ill-formed literals?
Have you considered something like this:
0xS00000000.: hex_fp320xSL0000000000000000.: hex_fp640xSQ00000000000000000000000000000000.: hex_fp128
I think that is ok, but could be generalized. IEEE 754 specifies both binary and decimal so “ieee” is arguably ambiguous (not that I think anyone would expect “ieee” to select a decimal representation). An alternative would be -mzos-float-kind=hex|bin(ary)|dec(imal)
Should the option be limited to just z/OS? Might someone want to enable hex FP for Linux on IBM Z (z/Architecture, z/Series, System Z, … I so wish IBM would stop changing its branding for these systems)?
The existing options that start with -mzos are all z/OS specific because they interact with z/OS specific filesystem details. I think we could drop the zos- prefix on the new option in favor of -mfloat-kind=.... The option value would clearly have to be validated for support by the target, but that is straight forward.
Yes, those literals would not be well-formed. I did consider using different prefixes, but decided against that.
I’m not overly concerned about IEEE covering both binary and decimal, as decimal is a separate type at the C/C++ level. HexFloat is different in that it selects a different format for the language types float/double.
Would it be expected that compile-time arithmetic (e.g., C++ constexpr) should support operating on such values in the manner you describe?