[Bug target/32187] Complex __float128 is rejected

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32187

--- Comment #13 from Andrew Pinski  ---
(In reply to jos...@codesourcery.com from comment #12)
> You can now use _Complex _Float128.  Given that, it's not obvious that 
> _Complex __float128, with the legacy __float128 type name, should be 
> supported (although not supporting that means also not supporting _Complex 
> __ibm128 for powerpc64le; both are built-in typedefs, and no _Float* 
> keyword can be used for __ibm128).
> 
> _Float128 isn't supported for C++, although there's the argument that 
> there std::complex<__float128> is the thing support should be added / 
> enabled for, rather than adding to the support for C-style complex types 
> in C++.

C++'s _Float128 support was added with r13-2887-b04208895fed34 .

[Bug target/32187] Complex __float128 is rejected

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32187

--- Comment #12 from joseph at codesourcery dot com  ---
You can now use _Complex _Float128.  Given that, it's not obvious that 
_Complex __float128, with the legacy __float128 type name, should be 
supported (although not supporting that means also not supporting _Complex 
__ibm128 for powerpc64le; both are built-in typedefs, and no _Float* 
keyword can be used for __ibm128).

_Float128 isn't supported for C++, although there's the argument that 
there std::complex<__float128> is the thing support should be added / 
enabled for, rather than adding to the support for C-style complex types 
in C++.

[Bug target/32187] Complex __float128 is rejected

[jsm28 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32187

--- Comment #11 from Joseph S. Myers  ---
Author: jsm28
Date: Fri Aug 19 17:43:26 2016
New Revision: 239625

URL: https://gcc.gnu.org/viewcvs?rev=239625=gcc=rev
Log:
Implement C _FloatN, _FloatNx types.

ISO/IEC TS 18661-3:2015 defines C bindings to IEEE interchange and
extended types, in the form of _FloatN and _FloatNx type names with
corresponding fN/FN and fNx/FNx constant suffixes and FLTN_* / FLTNX_*
 macros.  This patch implements support for this feature in
GCC.

The _FloatN types, for N = 16, 32, 64 or >= 128 and a multiple of 32,
are types encoded according to the corresponding IEEE interchange
format (endianness unspecified; may use either the NaN conventions
recommended in IEEE 754-2008, or the MIPS NaN conventions, since the
choice of convention is only an IEEE recommendation, not a
requirement).  The _FloatNx types, for N = 32, 64 and 128, are IEEE
"extended" types: types extending a narrower format with range and
precision at least as big as those specified in IEEE 754 for each
extended type (and with unspecified representation, but still
following IEEE semantics for their values and operations - and with
the set of values being determined by the precision and the maximum
exponent, which means that while Intel "extended" is suitable for
_Float64x, m68k "extended" is not).  These types are always distinct
from and not compatible with each other and the standard floating
types float, double, long double; thus, double, _Float64 and _Float32x
may all have the same ABI, but they are three still distinct types.
The type names may be used with _Complex to construct corresponding
complex types (unlike __float128, which acts more like a typedef name
than a keyword - thus, this patch may be considered to fix PR
c/32187).  The new suffixes can be combined with GNU "i" and "j"
suffixes for constants of complex types (e.g. 1.0if128, 2.0f64i).

The set of types supported is implementation-defined.  In this GCC
patch, _Float32 is SFmode if that is suitable; _Float32x and _Float64
are DFmode if that is suitable; _Float128 is TFmode if that is
suitable; _Float64x is XFmode if that is suitable, and otherwise
TFmode if that is suitable.  There is a target hook to override the
choices if necessary.  "Suitable" means both conforming to the
requirements of that type, and supported as a scalar type including in
libgcc.  The ABI is whatever the back end does for scalars of that
mode (but note that _Float32 is passed without promotion in variable
arguments, unlike float).  All the existing issues with exceptions and
rounding modes for existing types apply equally to the new type names.

No GCC port supports a floating-point format suitable for _Float128x.
Although there is HFmode support for ARM and AArch64, use of that for
_Float16 is not enabled.  Supporting _Float16 would require additional
work on the excess precision aspects of TS 18661-3: there are new
values of FLT_EVAL_METHOD, which are not currently supported in GCC,
and FLT_EVAL_METHOD == 0 now means that operations and constants on
types narrower than float are evaluated to the range and precision of
float.  Implementing that, so that _Float16 gets evaluated with excess
range and precision, would involve changes to the excess precision
infrastructure so that the _Float16 case is enabled by default, unlike
the x87 case which is only enabled for -fexcess-precision=standard.
Other differences between _Float16 and __fp16 would also need to be
disentangled.

GCC has some prior support for nonstandard floating-point types in the
form of __float80 and __float128.  Where these were previously types
distinct from long double, they are made by this patch into aliases
for _Float64x / _Float128 if those types have the required properties.

In principle the set of possible _FloatN types is infinite.  This
patch hardcodes the four such types for N <= 128, but with as much
code as possible using loops over types to minimize the number of
places with such hardcoding.  I don't think it's likely any further
such types will be of use in future (or indeed that formats suitable
for _Float128x will actually be implemented).  There is a corner case
that all _FloatN, for N >= 128 and a multiple of 32, should be treated
as keywords even when the corresponding type is not supported; I
intend to deal with that in a followup patch.

Tests are added for various functionality of the new types, mostly
using type-generic headers.  The tests use dg-add-options to pass any
extra options needed to enable the types; this is wired up to use the
same options as for __float128 on powerpc to enable _Float128 and
_Float64x, and effective-target keywords for runtime support do the
same hardware test as for __float128 to make sure the VSX instructions
generated by those options are supported.  (Corresponding additions
would be needed for _Float16 on ARM as well if that were enabled with
-mfp16-format=ieee required to use it rather than 

[Bug target/32187] Complex __float128 is rejected

[emsr at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32187

--- Comment #10 from emsr at gcc dot gnu.org ---
Author: emsr
Date: Tue Aug 16 14:56:55 2016
New Revision: 239504

URL: https://gcc.gnu.org/viewcvs?rev=239504=gcc=rev
Log:
Commit Joseph Myers Implement C _FloatN, _FloatNx types [version 5] to the
branch.
This is to test impact on my use of __float128 and comlex.
gcc:
2016-07-22  Joseph Myers  

PR c/32187
* tree-core.h (TI_COMPLEX_FLOAT16_TYPE)
(TI_COMPLEX_FLOATN_NX_TYPE_FIRST, TI_COMPLEX_FLOAT32_TYPE)
(TI_COMPLEX_FLOAT64_TYPE, TI_COMPLEX_FLOAT128_TYPE)
(TI_COMPLEX_FLOAT32X_TYPE, TI_COMPLEX_FLOAT64X_TYPE)
(TI_COMPLEX_FLOAT128X_TYPE, TI_FLOAT16_TYPE, TI_FLOATN_TYPE_FIRST)
(TI_FLOATN_NX_TYPE_FIRST, TI_FLOAT32_TYPE, TI_FLOAT64_TYPE)
(TI_FLOAT128_TYPE, TI_FLOATN_TYPE_LAST, TI_FLOAT32X_TYPE)
(TI_FLOATNX_TYPE_FIRST, TI_FLOAT64X_TYPE, TI_FLOAT128X_TYPE)
(TI_FLOATNX_TYPE_LAST, TI_FLOATN_NX_TYPE_LAST): New enum
tree_index values.
(NUM_FLOATN_TYPES, NUM_FLOATNX_TYPES, NUM_FLOATN_NX_TYPES): New
macros.
(struct floatn_type_info): New structure type.
(floatn_nx_types): New variable declaration.
* tree.h (FLOATN_TYPE_NODE, FLOATN_NX_TYPE_NODE)
(FLOATNX_TYPE_NODE, float128_type_node, float64x_type_node)
(COMPLEX_FLOATN_NX_TYPE_NODE): New macros.
* tree.c (floatn_nx_types): New variable.
(build_common_tree_nodes): Initialize _FloatN, _FloatNx and
corresponding complex types.
* target.def (floatn_mode): New hook.
* targhooks.c: Include "real.h".
(default_floatn_mode): New function.
* targhooks.h (default_floatn_mode): New prototype.
* doc/extend.texi (Floating Types): Document _FloatN and _FloatNx
types.
* doc/sourcebuild.texi (float@var{n}, float@var{n}x): Document new
effective-target keywords.
* doc/tm.texi.in (TARGET_FLOATN_MODE): New @hook.
* doc/tm.texi: Regenerate.
* ginclude/float.h (LDBL_DECIMAL_DIG): Define to
__LDBL_DECIMAL_DIG__, not __DECIMAL_DIG__.
[__STDC_WANT_IEC_60559_TYPES_EXT__]: Define macros from TS
18661-3.
* real.h (struct real_format): Add field ieee_bits.
* real.c (ieee_single_format, mips_single_format)
(motorola_single_format, spu_single_format, ieee_double_format)
(mips_double_format, motorola_double_format)
(ieee_extended_motorola_format, ieee_extended_intel_96_format)
(ieee_extended_intel_128_format)
(ieee_extended_intel_96_round_53_format, ibm_extended_format)
(mips_extended_format, ieee_quad_format, mips_quad_format)
(vax_f_format, vax_d_format, vax_g_format, decimal_single_format)
(decimal_double_format, decimal_quad_format, ieee_half_format)
(arm_half_format, real_internal_format: Initialize ieee_bits
field.
* config/i386/i386.c (ix86_init_builtin_types): Do not initialize
float128_type_node.  Set float80_type_node to float64x_type_node
if appropriate and long_double_type_node not appropriate.
* config/ia64/ia64.c (ia64_init_builtins): Likewise.
* config/pdp11/pdp11.c (pdp11_f_format, pdp11_d_format):
Initialize ieee_bits field.
* config/rs6000/rs6000.c (TARGET_FLOATN_MODE): New macro.
(rs6000_init_builtins): Set ieee128_float_type_node to
float128_type_node.
(rs6000_floatn_mode): New function.

gcc/c:
2016-07-22  Joseph Myers  

PR c/32187
* c-tree.h (cts_floatn_nx): New enum c_typespec_keyword value.
(struct c_declspecs): Add field floatn_nx_idx.
* c-decl.c (declspecs_add_type, finish_declspecs): Handle _FloatN
and _FloatNx type specifiers.
* c-parser.c (c_keyword_starts_typename, c_token_starts_declspecs)
(c_parser_declspecs, c_parser_attribute_any_word)
(c_parser_objc_selector): Use CASE_RID_FLOATN_NX.
* c-typeck.c (c_common_type): Handle _FloatN and _FloatNx types.
(convert_arguments): Avoid promoting _FloatN and _FloatNx types
narrower than double.

gcc/c-family:
2016-07-22  Joseph Myers  

PR c/32187
* c-common.h (RID_FLOAT16, RID_FLOATN_NX_FIRST, RID_FLOAT32)
(RID_FLOAT64, RID_FLOAT128, RID_FLOAT32X, RID_FLOAT64X)
(RID_FLOAT128X): New enum rid values.
(CASE_RID_FLOATN_NX): New macro.
* c-common.c (c_common_reswords): Add _FloatN and _FloatNx
keywords.
(c_common_type_for_mode): Check for _FloatN and _FloatNx and
corresponding complex types.
(c_common_nodes_and_builtins): For non-C++, register _FloatN and
_FloatNx and corresponding complex types.
(keyword_begins_type_specifier): Use CASE_RID_FLOATN_NX.
* c-cppbuiltin.c (builtin_define_float_constants): Check _FloatN
   

[Bug target/32187] Complex __float128 is rejected

[and_j_rob at yahoo dot com]

--- Comment #9 from and_j_rob at yahoo dot com  2010-05-03 07:22 ---
Created an attachment (id=20540)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20540action=view)
Was a C/C++ comparison

I found a similar problem while comparing C/C++ complexes, I'm on a x86_64 mac,
and was trying to learn about how the ABI works (with the attached code) when I
stumbled upon this.

Here is an overview of different combinations of floats and languages.

complex*..|.C..|.C++
++
long double.|.(good).|.(good)
__float80...|.(syntax error).|.(good)
__float128..|.(syntax error).|.(internal compiler error)

the ICE is
test.cpp:25: internal compiler error: in write_builtin_type, at
cp/mangle.c:1793

so I think what caused the ICE was the std::complex__float128 snippet.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32187

[Bug target/32187] Complex __float128 is rejected

[ktietz at gcc dot gnu dot org]

--- Comment #7 from ktietz at gcc dot gnu dot org  2009-09-27 09:25 ---
The new attribute basetype_mode (see
http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01907.html for patch) could
provide a way to solve this, as it makes sure that it is associated to the base
type, instead of the current type declaration as mode attribute does.

by defining __float128 as '#define __float128 float __attribute__
((basetype_mode(DF)))'

Constructs like '__complex__ DFtype z;' getting handled proper, too.

Maybe this is a way to solve this issue.

Kai


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32187

[Bug target/32187] Complex __float128 is rejected

[ktietz at gcc dot gnu dot org]

--- Comment #8 from ktietz at gcc dot gnu dot org  2009-09-27 09:28 ---
(In reply to comment #7)
 The new attribute basetype_mode (see
 http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01907.html for patch) could
 provide a way to solve this, as it makes sure that it is associated to the 
 base
 type, instead of the current type declaration as mode attribute does.
 
 by defining __float128 as '#define __float128 float __attribute__
 ((basetype_mode(DF)))'
 
 Constructs like '__complex__ DFtype z;' getting handled proper, too.
Err, I meant here of course '__complex__ __float128 z;'

 Maybe this is a way to solve this issue.
 
 Kai
 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32187

[Bug target/32187] Complex __float128 is rejected

[jsm28 at gcc dot gnu dot org]

--- Comment #6 from jsm28 at gcc dot gnu dot org  2008-07-02 10:31 ---
*** Bug 36692 has been marked as a duplicate of this bug. ***


-- 

jsm28 at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||hjl dot tools at gmail dot
   ||com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32187

[Bug target/32187] Complex __float128 is rejected

[fxcoudert at gcc dot gnu dot org]

--- Comment #5 from fxcoudert at gcc dot gnu dot org  2007-06-25 20:26 
---
(In reply to comment #2)
 there probably is a case for allowing certain such typedefs to be treated 
 like keywords with regard to adding _Complex, signed or unsigned.

I second that. Can a decision be reached on whether or not this is a bug, so
that we can work on libgfortran accordingly?

(for us, being able to use _Complex __float128 would really be a lot simpler)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32187

[Bug target/32187] Complex __float128 is rejected

[ubizjak at gmail dot com]

--- Comment #1 from ubizjak at gmail dot com  2007-06-02 19:44 ---
Is this a parser problem? Compilation fails even for generic:

--cut here--
typedef float DFtype __attribute__((mode(DF)));

__complex__ DFtype z;

void test(void) { z = 1.0+2.0i; }
--cut here--


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32187

[Bug target/32187] Complex __float128 is rejected

[joseph at codesourcery dot com]

--- Comment #2 from joseph at codesourcery dot com  2007-06-02 20:09 ---
Subject: Re:  Complex __float128 is rejected

On Sat, 2 Jun 2007, ubizjak at gmail dot com wrote:

 Is this a parser problem? Compilation fails even for generic:
 
 --cut here--
 typedef float DFtype __attribute__((mode(DF)));
 
 __complex__ DFtype z;

Of course, 6.7.2 paragraph 2 does not include _Complex typedef-name in the 
possible sets of type specifiers.  __float128 is a built-in typedef, but 
there probably is a case for allowing certain such typedefs to be treated 
like keywords with regard to adding _Complex, signed or unsigned.

You should be able to use

typedef _Complex float TCtype __attribute__((mode(TC)));

or similar to access _Complex __float128 at present.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32187

[Bug target/32187] Complex __float128 is rejected

[gdr at cs dot tamu dot edu]

--- Comment #3 from gdr at cs dot tamu dot edu  2007-06-02 20:28 ---
Subject: Re:  Complex __float128 is rejected

joseph at codesourcery dot com [EMAIL PROTECTED] writes:

| Subject: Re:  Complex __float128 is rejected
| 
| On Sat, 2 Jun 2007, ubizjak at gmail dot com wrote:
| 
|  Is this a parser problem? Compilation fails even for generic:
|  
|  --cut here--
|  typedef float DFtype __attribute__((mode(DF)));
|  
|  __complex__ DFtype z;
| 
| Of course, 6.7.2 paragraph 2 does not include _Complex typedef-name in the 
| possible sets of type specifiers.

Out of curiosity, do you happen to know why typedefs to floating point
types should be disallowed?

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32187

[Bug target/32187] Complex __float128 is rejected

[joseph at codesourcery dot com]

--- Comment #4 from joseph at codesourcery dot com  2007-06-02 21:35 ---
Subject: Re:  Complex __float128 is rejected

On Sat, 2 Jun 2007, gdr at cs dot tamu dot edu wrote:

 | Of course, 6.7.2 paragraph 2 does not include _Complex typedef-name in the 
 | possible sets of type specifiers.
 
 Out of curiosity, do you happen to know why typedefs to floating point
 types should be disallowed?

Typedefs have never been allowed along with other type specifiers; it's 
much the same as not allowing unsigned T or T unsigned where T is a 
typedef for int.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32187