This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: Implement C _FloatN, _FloatNx types
- From: FX <fxcoudert at gmail dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: gcc-patches at gcc dot gnu dot org, fortran at gcc dot gnu dot org, jason at redhat dot com, richard dot earnshaw at arm dot com, nickc at redhat dot com, ramana dot radhakrishnan at arm dot com, marcus dot shawcroft at arm dot com, dje dot gcc at gmail dot com, segher at kernel dot crashing dot org, meissner at linux dot vnet dot ibm dot com, murphyp at linux dot vnet dot ibm dot com, bje at gnu dot org
- Date: Tue, 21 Jun 2016 17:17:02 +0200
- Subject: Re: Implement C _FloatN, _FloatNx types
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 20 dot 1606211202040 dot 4526 at digraph dot polyomino dot org dot uk>
> Fortran note: I took the conservative approach of renaming the
> float128_type_node used in the Fortran front end, since I wasn't sure
> if it's safe to make the front end always use the language-independent
> node (which follows C rules - thus, being distinct from long double
> even if that has binary128 format).
In the Fortran front-end, float128_type_node is defined as the (expectedly unique) floating-point type for which mode_precision is equal to 128 but not equal to LONG_DOUBLE_TYPE_SIZE. That is, it is garanteed that float128_type_node is not long_double_type_node.
If fact, if there is a long double type with precision of 128, then float128_type_node is NULL.
Would that match the (new) C behavior? I think it does.
FX