* [Bug c++/111897] Initialization of _Float16 with f.p. constant gives false warning
2023-10-20 14:40 [Bug c++/111897] New: Initialization of _Float16 with f.p. constant gives false warning agner at agner dot org
2023-10-20 15:29 ` [Bug c++/111897] " redi at gcc dot gnu.org
2023-10-21 5:41 ` agner at agner dot org
@ 2023-10-25 7:40 ` agner at agner dot org
2023-10-25 9:31 ` redi at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: agner at agner dot org @ 2023-10-25 7:40 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111897
--- Comment #3 from Agner Fog <agner at agner dot org> ---
I have asked the authors of the linked document. They say that the example in
the document is wrong. The latest version still has the error in the example:
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p1467r9.html
The compiler should give warnings for all of these:
_Float16 A = 1.5;
_Float16 B(1.5);
_Float16 C{1.5};
but no warning for integers:
_Float16 D = 2;
It is fine to give a warning rather than an error message when the intention is
obvious and there is no ambiguity.
Below is my conversation with David Olsen:
That’s correct. Conversions between integral and floating-point types are
standard conversions, in both directions, which means they are implicit
conversions. That was covered by preexisting wording in the standard, so P1467
doesn’t talk about those conversions. There isn’t a good way for the standard
to clearly specify which conversions are lossless and which are potentially
lossy, so we didn’t try to limit int/float conversions involving extended
floating-point types to just the safe conversions.
From: Agner Fog <agner@agner.org>
Sent: Tuesday, October 24, 2023 10:26 PM
To: David Olsen <dolsen@nvidia.com>; griwes@griwes.info
Subject: Re: Problem with P1467R4 C++ std. proposal
Thank you for a clear answer.
I don't see any mentioning of implicit conversion from integer to extended
floating point types. Is that allowed?
gcc 13.1 gives no warning for implicit conversion from integer to float16:
_Float16 A = 3; // no warning
_Float16 A = 3.; // warning
Is that correct?
- Agner
On 24/10/2023 19.29, David Olsen wrote:
The final version of P1467 is R9,
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p1467r9.html . The
GCC 13 release notes contain a link to that version. Where do you see the link
to R4?
The issue of initialization of extended floating-point type variables was
raised and discussed during the standardization process. R9 contains a long
discussion of the issue, with some of the ways that we tried to fix the problem
of initialization.
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p1467r9.html#implicit-constant
After some back and forth, the consensus was to leave the implicit conversion
rules unchanged for initialization, because the potential solutions have their
own problems. So all of
_Float16 A = 1.5;
_Float16 B(1.5);
_Float16 C{1.5};
are ill-formed and should result in a compiler diagnostic. I am pleased
that GCC reports only a warning and not a hard error, since the user's intent
is obvious.
Yes, the example in section 5.6.1 is wrong. The mistake is still there in
R9 of the paper. It should be
float f32 = 1.0f;
std::float16_t f16 = 2.0f16;
std::bfloat16_t b16 = 3.0bf16;
On the more general issue of how much the new extended floating-point types
should behave like the existing standard floating-point types, there was a long
and useful discussion about this topic at a committee meeting in Feb 2020.
There is general agreement that many of the defaults in C++ are wrong and can
make it easier to write badly behaving code. Whenever new features are added,
there is tension between the consistency of having them behave like existing
features and the safety of choosing different defaults that makes it easier to
write correct code. These competing goals and the consequences and tradeoffs
of both of them were explicitly laid out and discussed at the Feb 2020 meeting,
and at the end of the discussion there was strong consensus (though not
unanimity) to go with safety over consistency for implicit conversions of
extended floating-point types.
int16_t is in the std namespace in C++. For C compatibility it is also
available at global scope if you include <stdint.h> (defined by the C standard)
instead of <cstdint> (defined by the C++ standard). The C++ standard doesn't
define any names at global scope other than 'operator new' and 'operator
delete'. Defining float16_t to be a global scope would have been a huge
departure from existing practice.
-----Original Message-----
From: Agner Fog <agner@agner.org>
Sent: Tuesday, October 24, 2023 8:03 AM
To: David Olsen <dolsen@nvidia.com>; griwes@griwes.info
Subject: Problem with P1467R4 C++ std. proposal
Dear David Olsen and Michał Dominiak
I don't know who to contact regarding C++ standard development, so I am
taking the liberty to contact you as the authors of P1467R4,
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1467r4.html#implicit
It is unclear whether the rules for implicit conversion relate to
initialization and assignment.
gcc version 13.1 gives warnings for the following cases with reference to
the above document:
_Float16 A = 1.5;
_Float16 B(1.5);
_Float16 C{1.5};
The last one should probably not have a warning, the other ones are
unclear. Initialization with an integer constant gives no warning message.
The example in 5.6.1 in your document has:
std::float16_t f16 = 2.0;
Is this example wrong, or are there different rules for implicit conversion
during initialization?
In my opinion, it is a serious problem that the C++ language becomes so
complicated and inconsistent that nobody can master it, apparently not even the
people who write the standard.
The only consistent rule would be that if implicit conversion between
double and float is permitted, then implicit conversion between other floating
point types should be permitted as well. The alleged problem that implicit
conversion can lead to buggy code should be solved with compiler warnings, not
error messages.
Another inconsistency is that float16_t is in the std:: namespace, while
int16_t is not. I think it is unnecessary to put float16_t and other new types
in the std namespace because everything ending in "_t" is already considered
reserved names. Adding std:: to everything makes the code kludgy.
Best regards, and thank you for your work,
Agner Fog,
computer scientist,
Technical University of Denmark
^ permalink raw reply [flat|nested] 5+ messages in thread