https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87390
--- Comment #17 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
(In reply to jos...@codesourcery.com from comment #16)
> On Wed, 26 Sep 2018, vincent-gcc at vinc17 dot net wrote:
> > which distinction?
>
> The one you made above, between values that can be represented in the
> target type, and those that cannot and are thus rounded.
Then this distinction is also applied in the first paragraph: that's why there
is a parenthesis "(if the source value is represented in the precision and
range of its type)", meaning that the value can also change (and the full
description is in the second paragraph). The way it is specified is a bit ugly,
but I assume that this comes from the modification for TC3, and they didn't
want to rewrite everything at this point.
Note also that...
> > > demotions and explicit conversions (second paragraph); it does not apply
> > > in the first paragraph (implicit promotions).
This is wrong. The first paragraph does not concern only implicit promotions.
If you cast a float expression to double, this is an explicit conversion, and
there are still 2 cases: If the value is exactly representable, it is
unchanged; if the value is not exactly representable, it is rounded (that part
is actually described in the second paragraph, as I've just said above).
> > Analogous? Where does the C standard say that?
>
> It doesn't say so directly. Rather, if you apply your comparison
> (comment#12) of 6.3.1.4 and 6.3.1.5 ("in both cases, either the value can
> be represented exactly, in which case it is unchanged, or it cannot, in
> which case it is rounded"), I think it has to be one of 6.3.1.4 with
> 6.3.1.5 paragraph 2, and in 6.3.1.5 paragraph 2 there is no excess
> precision in the result of the conversion.
6.3.1.5p2 is only about explicit conversions and function calls (otherwise,
types are not demoted magically). But in my example, d == i + 1, no demotion is
involved.
> I see no reason here, if someone has explicitly chosen an old standard
> mode (-std=c99), to deviate from the interpretations of ambiguities used
> since excess precision support was first added, given that the changes in
> C11 did not results from the Defect Report process but from a separate
> paper outside of that process.
I think that C11 just clarified. There hasn't been a defect report against C99,
AFAIK. If you think that 6.3.1.5 implies a conversion to the semantic type,
then this should not be done just for values of integer source, but also for
those of floating-point source. But as I've said, this somewhat defeats the
purpose of extra precision and range.
