Implement C _FloatN, _FloatNx types

Programming / Compilers / GCC - jsm28 [138bc75d-0d04-0410-961f-82ee72b054a4] - 19 August 2016 12:43 UTC

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 unconditionally available. Of course, -mfp16-format=alternative enables use of a format which is not compatible with the requirements of the _Float16 type.)

C++ note: no support for the new types or constant suffixes is added for C++. C++ decimal floating-point support was very different from the C support, using class types, and the same may well apply to any future C++ bindings for IEEE interchange and extended types. There is a case, however, for supporting at least *f128 constants in C++, so that code using __float128 can use the newer style for constants throughout rather than needing to use the older *q constants in C++. Also, if built-in functions are added that may provide a way in which the types could leak into C++ code.

Fortran note: the float128_type_node used in the Fortran front end is renamed to gfc_float128_type_node, since the semantics are different: in particular, if long double has binary128 format, then the new language-independent float128_type_node is a distinct type that also has binary128 format, but the Fortran node is expected to be NULL in that case. Likewise, Fortran's complex_float128_type_node is renamed to gfc_complex_float128_type_node.

PowerPC note: the back end had an inconsistency that if TFmode was binary128, *q constants were TFmode instead of KFmode but __float128 was KFmode. This patch follows the same logic as for *q constants, so that _Float128 prefers TFmode (and __float128 becomes an alias for _Float128).

ARM note: __fp16 is promoted to double (by convert_arguments) when passed without a prototype / in variable arguments. But this is only about the argument promotion; it is not handled as promoting in c-common.c:self_promoting_args_p / c-typeck.c:c_type_promotes_to, meaning that a K&R function definition for an argument of type __fp16 corresponds to a prototype with an argument of that type, not to one with an argument of type double, whereas a float argument in a K&R function definition corresponds to a double prototype argument - and the same functions are also what's involved in making va_arg give a warning and generate a call to abort when called with type float. This is preserved by this patch, while arranging for _Float16 not to be promoted when passed without a prototype / in variable arguments (the promotion of float being considered a legacy feature, not applied to any new types in C99 or later).

TS 18661-3 extends the set of decimal floating-point types similarly, and adds new constant suffixes for the existing types, but this patch does not do anything regarding that extension.

This patch does nothing regarding built-in functions, although type-generic functions such as __builtin_isinf work for the new types and associated tests are included. There are at least two levels of built-in function support possible for these types. The minimal level, implemented in (which needs updating to use dg-add-options), adds built-in functions similar to those x86 has for __float128: __builtin_inf* __builtin_huge_val*, __builtin_nan*, __builtin_nans*, __builtin_fabs*, __builtin_copysign*. That would be sufficient for glibc to use the *f128 names for built-in functions by default with *q used only for backwards compatibility when using older GCC versions. That would also allow c_cpp_builtins's flag_building_libgcc code, defining __LIBGCC_%s_FUNC_EXT__, to use such suffixes rather than the present code hardcoding logic about target-specific constant suffixes and how those relate to function suffixes.

Full built-in function support would cover the full range of built-in functions for existing floating-point types, adding variants for all the new types, except for a few obsolescent functions and non-type-generic variants of type-generic functions. Some but not all references to such functions in GCC use macros such as CASE_FLT_FN to be type-generic; a fair amount of work would be needed to identify all places to update. Adding all those functions would enable optimizations (for constant arguments and otherwise) for TS 18661-3 functions, but it would also substantially expand the enum listing built-in functions (and we've had problems with the size of that enum in the past), and increase the amount of built-in function initialization to do - I don't know what the startup cost involved in built-in function initialization is, but it would be something to consider when adding such a large set of functions.

There are also a range of optimizations, in match.pd and elsewhere, that only operate on the three standard floating-point types. Ideally those would be made generic to all floating-point types, but this patch does nothing in that regard. Special care would be needed regarding making sure library functions to which calls are generated actually exist. For example, if sqrt is called on an argument of type _Float32, and the result converted to _Float32, this is equivalent to doing a square root operation directly on _Float32. But if the user's libm does not have the sqrtf32 function, or the name is not reserved because __STDC_WANT_IEC_60559_TYPES_EXT__ was not defined before including , you can only do that optimization if you convert to a call to sqrtf instead.

DECIMAL_DIG now relates to all supported floating-point formats, not just float, double and long double; I've raised the question with WG14 of how this relates to the formula for DECIMAL_DIG in C11 not considering this. TS 18661-3 says it also covers non-arithmetic formats only supported by library conversion functions; this patch does not add any target hooks to allow for the case where there are such formats wider than any supported for arithmetic types (where e.g. libc supports conversions involving the binary128 representation, but the _Float128 type is not supported).

GCC provides its own for some targets. No attempt is made to adapt this to handle the new types.

Nothing is done regarding debug info for the new types (see the "Debugger support for __float128 type?" thread on gcc@, Sep/Oct 2015).

No __SIZEOF_*__ macros are added for the new types.

Nothing is done with do_warn_double_promotion.

Nothing is done to include the new types in those determining max_align_t, although properly it should be sufficiently aligned for any of those types.

The logic for usual arithmetic conversions in c_common_type relies on TYPE_PRECISION for floating-point types, which is less than ideal (doesn't necessarily correspond to whether one type's values are subset of another); looking in more detail at the formats might be better. But since I included code in build_common_tree_nodes to work around rs6000 KFmode having precision 113 not 128, I think it should work. Ideally one might have errors in generic code for the case where the two types do not have one type's values a subset of the other (which is undefined behavior). But the only case where this can actually occur is mixing IBM long double with binary128 on powerpc, and rs6000_invalid_binary_op deals with that at present. TS 18661-3 does not fully specify the type resulting from the usual arithmetic conversions in the case where two _FloatNx types have the same set of
values; I arranged the code to prefer the greater value of N in that case.

The __FP_FAST_FMA* macros are not extended to cover the new types, since there are no corresponding built-in functions (if built-in fmafN, fmafNx are added, the macros should be extended, and the new macros documented). Also, only a limited set of modes is handled in mode_has_fma.

Diagnostics relating to the use of the new types with -pedantic do not try to distinguish them from purely nonstandard types such as __int128 and constant suffixes such as *q.

If you use an unsupported _FloatN / _FloatNx type you get a warning about the type defaulting to int after the warning about the type not being supported. That's less than ideal, but it's also a pre-existing condition if you use __int128 on a 32-bit system where it's unsupported.

Bootstrapped with no regressions on x86_64-pc-linux-gnu. Other back-end changes minimally tested by building cc1 for ia64-linux-gnu, powerpc64le-linux-gnu, pdp11-none (the last failed for unrelated reasons).

PR c/32187 gcc:
- 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 and dg-add-options keywords. (float@var{n}_runtime, float@var{n}x_runtime, floatn_nx_runtime): 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:
- 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:
- 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 and _FloatNx types for the widest type for determining DECIMAL_DIG. Define __LDBL_DECIMAL_DIG__ as well as __DECIMAL_DIG__ for long double. Handle FMA_SUFFIX being NULL. (c_cpp_builtins): Call builtin_define_float_constants for _FloatN and _FloatNx types.
- c-lex.c (interpret_float): Handle _FloatN and _FloatNx constants.
- c-pretty-print.c (pp_c_floating_constant): Handle _FloatN and _FloatNx types.

gcc/fortran:
- trans-types.h (float128_type_node): Rename to gfc_float128_type_node. (complex_float128_type_node): Rename to gfc_complex_float128_type_node.
- iso-c-binding.def, trans-intrinsic.c, trans-types.c: All users changed.

gcc/testsuite:
- lib/target-supports.exp (check_effective_target_float16) (check_effective_target_float32, check_effective_target_float64) (check_effective_target_float128, check_effective_target_float32x) (check_effective_target_float64x) (check_effective_target_float128x) (check_effective_target_float16_runtime) (check_effective_target_float32_runtime) (check_effective_target_float64_runtime) (check_effective_target_float128_runtime) (check_effective_target_float32x_runtime) (check_effective_target_float64x_runtime) (check_effective_target_float128x_runtime) (check_effective_target_floatn_nx_runtime) (add_options_for_float16, add_options_for_float32) (add_options_for_float64, add_options_for_float128) (add_options_for_float32x, add_options_for_float64x) (add_options_for_float128x): New procedures.
- gcc.dg/dfp/floatn.c, gcc.dg/float128-typeof.c, gcc.dg/float128x-typeof.c, gcc.dg/float16-typeof.c, gcc.dg/float32-typeof.c, gcc.dg/float32x-typeof.c, gcc.dg/float64-typeof.c, gcc.dg/float64x-typeof.c, gcc.dg/floatn-arithconv.c, gcc.dg/floatn-errs.c, gcc.dg/floatn-typeof.h, gcc.dg/torture/float128-basic.c, gcc.dg/torture/float128-complex.c, gcc.dg/torture/float128-floath.c, gcc.dg/torture/float128-tg.c, gcc.dg/torture/float128x-basic.c, gcc.dg/torture/float128x-complex.c, gcc.dg/torture/float128x-floath.c, gcc.dg/torture/float128x-tg.c, gcc.dg/torture/float16-basic.c, gcc.dg/torture/float16-complex.c, gcc.dg/torture/float16-floath.c, gcc.dg/torture/float16-tg.c, gcc.dg/torture/float32-basic.c, gcc.dg/torture/float32-complex.c, gcc.dg/torture/float32-floath.c, gcc.dg/torture/float32-tg.c, gcc.dg/torture/float32x-basic.c, gcc.dg/torture/float32x-complex.c, gcc.dg/torture/float32x-floath.c, gcc.dg/torture/float32x-tg.c, gcc.dg/torture/float64-basic.c, gcc.dg/torture/float64-complex.c, gcc.dg/torture/float64-floath.c, gcc.dg/torture/float64-tg.c, gcc.dg/torture/float64x-basic.c, gcc.dg/torture/float64x-complex.c, gcc.dg/torture/float64x-floath.c, gcc.dg/torture/float64x-tg.c, gcc.dg/torture/floatn-basic.h, gcc.dg/torture/floatn-complex.h, gcc.dg/torture/floatn-convert.c, gcc.dg/torture/floatn-floath.h, gcc.dg/torture/floatn-tg.h, gcc.dg/torture/fp-int-convert-float128-ieee-timode.c, gcc.dg/torture/fp-int-convert-float128-ieee.c, gcc.dg/torture/fp-int-convert-float128x-timode.c, gcc.dg/torture/fp-int-convert-float128x.c, gcc.dg/torture/fp-int-convert-float16-timode.c, gcc.dg/torture/fp-int-convert-float16.c, gcc.dg/torture/fp-int-convert-float32-timode.c, gcc.dg/torture/fp-int-convert-float32.c, gcc.dg/torture/fp-int-convert-float32x-timode.c, gcc.dg/torture/fp-int-convert-float32x.c, gcc.dg/torture/fp-int-convert-float64-timode.c, gcc.dg/torture/fp-int-convert-float64.c, gcc.dg/torture/fp-int-convert-float64x-timode.c, gcc.dg/torture/fp-int-convert-float64x.c: New tests.
- gcc.dg/torture/fp-int-convert.h (TEST_I_F): Add argument for maximum exponent of floating-point type. Use it in testing whether 0x8...0 fits in the floating-point type. Always treat -1 (signed 0xf...f) as fitting in the floating-point type. (M_OK1): New macro.
- gcc.dg/torture/fp-int-convert-double.c, gcc.dg/torture/fp-int-convert-float.c, gcc.dg/torture/fp-int-convert-float128-timode.c, gcc.dg/torture/fp-int-convert-float128.c, gcc.dg/torture/fp-int-convert-float80-timode.c, gcc.dg/torture/fp-int-convert-float80.c, gcc.dg/torture/fp-int-convert-long-double.c, gcc.dg/torture/fp-int-convert-timode.c: Update calls to TEST_I_F.

libcpp:
- include/cpplib.h (CPP_N_FLOATN, CPP_N_FLOATNX) (CPP_N_WIDTH_FLOATN_NX, CPP_FLOATN_SHIFT, CPP_FLOATN_MAX): New macros.
- expr.c (interpret_float_suffix): Handle fN, fNx, FN and FNx suffixes.

82c85ab Implement C _FloatN, _FloatNx types.
gcc/ChangeLog | 62 +++++++
gcc/c-family/ChangeLog | 25 +++
gcc/c-family/c-common.c | 38 ++++
gcc/c-family/c-common.h | 14 ++
gcc/c-family/c-cppbuiltin.c | 45 +++--
gcc/c-family/c-lex.c | 31 ++++
gcc/c-family/c-pretty-print.c | 10 ++
gcc/c/ChangeLog | 14 ++
gcc/c/c-decl.c | 115 +++++++++++-
gcc/c/c-parser.c | 5 +
gcc/c/c-tree.h | 4 +
gcc/c/c-typeck.c | 62 +++++--
gcc/config/i386/i386.c | 23 ++-
gcc/config/ia64/ia64.c | 32 ++--
gcc/config/pdp11/pdp11.c | 2 +
gcc/config/rs6000/rs6000.c | 56 +++++-
gcc/doc/extend.texi | 31 +++-
gcc/doc/sourcebuild.texi | 25 +++
gcc/doc/tm.texi | 18 ++
gcc/doc/tm.texi.in | 2 +
gcc/fortran/ChangeLog | 10 ++
gcc/fortran/iso-c-binding.def | 8 +-
gcc/fortran/trans-intrinsic.c | 6 +-
gcc/fortran/trans-types.c | 8 +-
gcc/fortran/trans-types.h | 4 +-
gcc/ginclude/float.h | 183 +++++++++++++++++++-
gcc/real.c | 24 +++
gcc/real.h | 11 ++
gcc/target.def | 20 +++
gcc/targhooks.c | 87 ++++++++++
gcc/targhooks.h | 1 +
gcc/testsuite/ChangeLog | 74 ++++++++
gcc/testsuite/gcc.dg/dfp/floatn.c | 20 +++
gcc/testsuite/gcc.dg/float128-typeof.c | 9 +
gcc/testsuite/gcc.dg/float128x-typeof.c | 9 +
gcc/testsuite/gcc.dg/float16-typeof.c | 9 +
gcc/testsuite/gcc.dg/float32-typeof.c | 9 +
gcc/testsuite/gcc.dg/float32x-typeof.c | 9 +
gcc/testsuite/gcc.dg/float64-typeof.c | 9 +
gcc/testsuite/gcc.dg/float64x-typeof.c | 9 +
gcc/testsuite/gcc.dg/floatn-arithconv.c | 50 ++++++
gcc/testsuite/gcc.dg/floatn-errs.c | 44 +++++
gcc/testsuite/gcc.dg/floatn-typeof.h | 22 +++
gcc/testsuite/gcc.dg/torture/float128-basic.c | 9 +
gcc/testsuite/gcc.dg/torture/float128-complex.c | 9 +
gcc/testsuite/gcc.dg/torture/float128-floath.c | 61 +++++++
gcc/testsuite/gcc.dg/torture/float128-tg.c | 9 +
gcc/testsuite/gcc.dg/torture/float128x-basic.c | 9 +
gcc/testsuite/gcc.dg/torture/float128x-complex.c | 9 +
gcc/testsuite/gcc.dg/torture/float128x-floath.c | 61 +++++++
gcc/testsuite/gcc.dg/torture/float128x-tg.c | 9 +
gcc/testsuite/gcc.dg/torture/float16-basic.c | 9 +
gcc/testsuite/gcc.dg/torture/float16-complex.c | 9 +
gcc/testsuite/gcc.dg/torture/float16-floath.c | 61 +++++++
gcc/testsuite/gcc.dg/torture/float16-tg.c | 9 +
gcc/testsuite/gcc.dg/torture/float32-basic.c | 9 +
gcc/testsuite/gcc.dg/torture/float32-complex.c | 9 +
gcc/testsuite/gcc.dg/torture/float32-floath.c | 61 +++++++
gcc/testsuite/gcc.dg/torture/float32-tg.c | 9 +
gcc/testsuite/gcc.dg/torture/float32x-basic.c | 9 +
gcc/testsuite/gcc.dg/torture/float32x-complex.c | 9 +
gcc/testsuite/gcc.dg/torture/float32x-floath.c | 61 +++++++
gcc/testsuite/gcc.dg/torture/float32x-tg.c | 9 +
gcc/testsuite/gcc.dg/torture/float64-basic.c | 9 +
gcc/testsuite/gcc.dg/torture/float64-complex.c | 9 +
gcc/testsuite/gcc.dg/torture/float64-floath.c | 61 +++++++
gcc/testsuite/gcc.dg/torture/float64-tg.c | 9 +
gcc/testsuite/gcc.dg/torture/float64x-basic.c | 9 +
gcc/testsuite/gcc.dg/torture/float64x-complex.c | 9 +
gcc/testsuite/gcc.dg/torture/float64x-floath.c | 61 +++++++
gcc/testsuite/gcc.dg/torture/float64x-tg.c | 9 +
gcc/testsuite/gcc.dg/torture/floatn-basic.h | 141 +++++++++++++++
gcc/testsuite/gcc.dg/torture/floatn-complex.h | 76 ++++++++
gcc/testsuite/gcc.dg/torture/floatn-convert.c | 104 +++++++++++
gcc/testsuite/gcc.dg/torture/floatn-floath.h | 52 ++++++
gcc/testsuite/gcc.dg/torture/floatn-tg.h | 113 ++++++++++++
.../gcc.dg/torture/fp-int-convert-double.c | 10 +-
.../gcc.dg/torture/fp-int-convert-float.c | 10 +-
.../torture/fp-int-convert-float128-ieee-timode.c | 16 ++
.../gcc.dg/torture/fp-int-convert-float128-ieee.c | 20 +++
.../torture/fp-int-convert-float128-timode.c | 3 +-
.../gcc.dg/torture/fp-int-convert-float128.c | 11 +-
.../torture/fp-int-convert-float128x-timode.c | 16 ++
.../gcc.dg/torture/fp-int-convert-float128x.c | 20 +++
.../gcc.dg/torture/fp-int-convert-float16-timode.c | 16 ++
.../gcc.dg/torture/fp-int-convert-float16.c | 20 +++
.../gcc.dg/torture/fp-int-convert-float32-timode.c | 16 ++
.../gcc.dg/torture/fp-int-convert-float32.c | 20 +++
.../torture/fp-int-convert-float32x-timode.c | 16 ++
.../gcc.dg/torture/fp-int-convert-float32x.c | 20 +++
.../gcc.dg/torture/fp-int-convert-float64-timode.c | 16 ++
.../gcc.dg/torture/fp-int-convert-float64.c | 20 +++
.../torture/fp-int-convert-float64x-timode.c | 16 ++
.../gcc.dg/torture/fp-int-convert-float64x.c | 20 +++
.../gcc.dg/torture/fp-int-convert-float80-timode.c | 3 +-
.../gcc.dg/torture/fp-int-convert-float80.c | 11 +-
.../gcc.dg/torture/fp-int-convert-long-double.c | 10 +-
.../gcc.dg/torture/fp-int-convert-timode.c | 6 +-
gcc/testsuite/gcc.dg/torture/fp-int-convert.h | 24 +--
gcc/testsuite/lib/target-supports.exp | 129 ++++++++++++++
gcc/tree-core.h | 47 +++++
gcc/tree.c | 44 +++++
gcc/tree.h | 13 ++
libcpp/ChangeLog | 9 +
libcpp/expr.c | 118 +++++++++++--
libcpp/include/cpplib.h | 7 +
106 files changed, 2932 insertions(+), 126 deletions(-)

Upstream: gcc.gnu.org

  • Share