On Thu, 26 Nov 2020, Thomas Koenig wrote:
> > What do you need this information for anyway?
>
> It's a check if the simplification to constants of these
> floating point types is done correctly.
Well, GCC's handling of the various FP formats is in the middle end (see
gcc/real.c and the various instances of `struct real_format' there), so
all the language frontends are supposed to be getting this right as long
as the backend has wired the correct structs to its FP data types. E.g.
the VAX backend does it in gcc/config/vax/vax-modes.def:
RESET_FLOAT_FORMAT (SF, vax_f_format);
RESET_FLOAT_FORMAT (DF, vax_d_format);
and then `-mg' overrides it further:
if (TARGET_G_FLOAT)
REAL_MODE_FORMAT (DFmode) = &vax_g_format;
and this:
#undef TARGET_DEFAULT
#define TARGET_DEFAULT MASK_G_FLOAT
has made it the default with my VAX/Linux work (still overridable with
`-md', though I can see the GCC manual is badly behind here now that I had
a look there).
> Another interesting thing to look at would be selected_real_kind.
>
> selected_real_kind(precision, range) will give you the kind
> number of a real type with at least precision digits and a range
> from 10**-range to 10**range, or -1 if there is nothing that
> matches. There should be a runtime version and a compile-time
> version, both of which should be correct :-)
A compile-time version is handled by the middle end, so it is supposed to
be always right, as noted above. Now a run-time version might be another
matter, although usually you'd just use the compile-time if possible, e.g.
(using an example with C, which I am more familiar with) the `nan' library
function will typically be implemented as a call to `__builtin_nan' on the
GNU system, so it will produce the same as the said intrinsic.
Maciej
