aboutsummaryrefslogtreecommitdiff
path: root/gcc/ginclude
AgeCommit message (Collapse)AuthorFilesLines
2024-01-03Update copyright years.Jakub Jelinek13-13/+13
2023-11-07c: Refer more consistently to C23 not C2XJoseph Myers2-13/+13
Continuing the move to refer to C23 in place of C2X throughout the source tree, update documentation, diagnostics, comments, variable and function names, etc., to use the C23 name. Testsuite updates are left for a future patch, except for testcases that test diagnostics that previously mentioned C2X (but in those testcases, sometimes other comments are updated, not just the diagnostic expectations). Bootstrapped with no regressions for x86_64-pc-linux-gnu. gcc/ * builtins.def (DEF_C2X_BUILTIN): Rename to DEF_C23_BUILTIN and use flag_isoc23 and function_c23_misc. * config/rl78/rl78.cc (rl78_option_override): Compare lang_hooks.name with "GNU C23" not "GNU C2X". * coretypes.h (function_c2x_misc): Rename to function_c23_misc. * doc/cpp.texi (@code{__has_attribute}): Refer to C23 instead of C2x. * doc/extend.texi: Likewise. * doc/invoke.texi: Likewise. * dwarf2out.cc (highest_c_language, gen_compile_unit_die): Compare against and return "GNU C23" language string instead of "GNU C2X". * ginclude/float.h: Refer to C23 instead of C2X in comments. * ginclude/stdint-gcc.h: Likewise. * glimits.h: Likewise. * tree.h: Likewise. gcc/ada/ * gcc-interface/utils.cc (flag_isoc2x): Rename to flag_isoc23. gcc/c-family/ * c-common.cc (flag_isoc2x): Rename to flag_isoc23. (c_common_reswords): Use D_C23 instead of D_C2X. * c-common.h: Refer throughout to C23 instead of C2X in comments. (D_C2X): Rename to D_C23. (flag_isoc2x): Rename to flag_isoc23. * c-cppbuiltin.cc (builtin_define_float_constants): Use flag_isoc23 instead of flag_isoc2x. Refer to C23 instead of C2x in comments. * c-format.cc: Use STD_C23 instead of STD_C2X and flag_isoc23 instead of flag_isoc2x. Refer to C23 instead of C2X in comments. * c-format.h: Use STD_C23 instead of STD_C2X. * c-lex.cc: Use warn_c11_c23_compat instead of warn_c11_c2x_compat and flag_isoc23 instead of flag_isoc2x. Refer to C23 instead of C2X in diagnostics. * c-opts.cc: Use flag_isoc23 instead of flag_isoc2x. Refer to C23 instead of C2X in comments. (set_std_c2x): Rename to set_std_c23. * c.opt (Wc11-c23-compat): Use CPP(cpp_warn_c11_c23_compat) CppReason(CPP_W_C11_C23_COMPAT) Var(warn_c11_c23_compat) instead of CPP(cpp_warn_c11_c2x_compat) CppReason(CPP_W_C11_C2X_COMPAT) Var(warn_c11_c2x_compat). gcc/c/ * c-decl.cc: Use flag_isoc23 instead of flag_isoc2x and c23_auto_p instead of c2x_auto_p. Refer to C23 instead of C2X in diagnostics and comments. * c-errors.cc: Use flag_isoc23 instead of flag_isoc2x and warn_c11_c23_compat instead of warn_c11_c2x_compat. Refer to C23 instead of C2X in comments. * c-parser.cc: Use flag_isoc23 instead of flag_isoc2x, warn_c11_c23_compat instead of warn_c11_c2x_compat, c23_auto_p instead of c2x_auto_p and D_C23 instead of D_C2X. Refer to C23 instead of C2X in diagnostics and comments. * c-tree.h: Refer to C23 instead of C2X in comments. (struct c_declspecs): Rename c2x_auto_p to c23_auto_p. * c-typeck.cc: Use flag_isoc23 instead of flag_isoc2x and warn_c11_c23_compat instead of warn_c11_c2x_compat. Refer to C23 instead of C2X in diagnostics and comments. gcc/fortran/ * gfortran.h (gfc_real_info): Refer to C23 instead of C2X in comment. gcc/lto/ * lto-lang.cc (flag_isoc2x): Rename to flag_isoc23. gcc/testsuite/ * gcc.dg/binary-constants-2.c: Refer to C23 instead of C2X. * gcc.dg/binary-constants-3.c: Likewise. * gcc.dg/bitint-23.c: Likewise. * gcc.dg/bitint-26.c: Likewise. * gcc.dg/bitint-27.c: Likewise. * gcc.dg/c11-attr-syntax-1.c: Likewise. * gcc.dg/c11-attr-syntax-2.c: Likewise. * gcc.dg/c11-floatn-1.c: Likewise. * gcc.dg/c11-floatn-2.c: Likewise. * gcc.dg/c11-floatn-3.c: Likewise. * gcc.dg/c11-floatn-4.c: Likewise. * gcc.dg/c11-floatn-5.c: Likewise. * gcc.dg/c11-floatn-6.c: Likewise. * gcc.dg/c11-floatn-7.c: Likewise. * gcc.dg/c11-floatn-8.c: Likewise. * gcc.dg/c2x-attr-syntax-4.c: Likewise. * gcc.dg/c2x-attr-syntax-6.c: Likewise. * gcc.dg/c2x-attr-syntax-7.c: Likewise. * gcc.dg/c2x-binary-constants-2.c: Likewise. * gcc.dg/c2x-floatn-5.c: Likewise. * gcc.dg/c2x-floatn-6.c: Likewise. * gcc.dg/c2x-floatn-7.c: Likewise. * gcc.dg/c2x-floatn-8.c: Likewise. * gcc.dg/c2x-nullptr-4.c: Likewise. * gcc.dg/c2x-qual-2.c: Likewise. * gcc.dg/c2x-qual-3.c: Likewise. * gcc.dg/c2x-qual-6.c: Likewise. * gcc.dg/cpp/c11-warning-1.c: Likewise. * gcc.dg/cpp/c11-warning-2.c: Likewise. * gcc.dg/cpp/c11-warning-3.c: Likewise. * gcc.dg/cpp/c2x-warning-2.c: Likewise. * gcc.dg/cpp/gnu11-elifdef-3.c: Likewise. * gcc.dg/cpp/gnu11-elifdef-4.c: Likewise. * gcc.dg/cpp/gnu11-warning-1.c: Likewise. * gcc.dg/cpp/gnu11-warning-2.c: Likewise. * gcc.dg/cpp/gnu11-warning-3.c: Likewise. * gcc.dg/cpp/gnu2x-warning-2.c: Likewise. * gcc.dg/dfp/c11-constants-1.c: Likewise. * gcc.dg/dfp/c11-constants-2.c: Likewise. * gcc.dg/dfp/c2x-constants-2.c: Likewise. * gcc.dg/dfp/constants-pedantic.c: Likewise. * gcc.dg/pr30260.c: Likewise. * gcc.dg/system-binary-constants-1.c: Likewise. libcpp/ * directives.cc: Refer to C23 instead of C2X in diagnostics and comments. (STDC2X): Rename to STDC23. * expr.cc: Use cpp_warn_c11_c23_compat instead of cpp_warn_c11_c2x_compat and CPP_W_C11_C23_COMPAT instead of CPP_W_C11_C2X_COMPAT. Refer to C23 instead of C2X in diagnostics and comments. * include/cpplib.h: Refer to C23 instead of C2X in diagnostics and comments. (CLK_GNUC2X): Rename to CLK_GNUC23. (CLK_STDC2X): Rename to CLK_STDC23. (CPP_W_C11_C2X_COMPAT): Rename to CPP_W_C11_C23_COMPAT. * init.cc: Use GNUC23 instead of GNUC2X, STDC23 instead of STDC2X and cpp_warn_c11_c23_compat instead of cpp_warn_c11_c2x_compat. * lex.cc (maybe_va_opt_error): Refer to C23 instead of C2X in diagnostic. * macro.cc (_cpp_arguments_ok): Refer to C23 instead of C2X in comment.
2023-08-12Add stdckdint.h header for C23Jakub Jelinek1-0/+40
This patch adds <stdckdint.h> header, which defines ckd_{add,sub,mul} using __builtin_{add,sub,mul}_overflow. As requested, it doesn't pedantically diagnose things which work just fine, e.g. inputs with plain char, bool, bit-precise integer or enumerated types and result pointer to plain char or bit-precise integer. The header will #include_next <stdckdint.h> so that C library can supply its part if the header implementation in the future needs to be split between parts under the control of the compiler and parts under the control of C library. 2023-08-12 Jakub Jelinek <jakub@redhat.com> * Makefile.in (USER_H): Add stdckdint.h. * ginclude/stdckdint.h: New file. * gcc.dg/stdckdint-1.c: New test. * gcc.dg/stdckdint-2.c: New test.
2023-01-23[PATCH 6/15] arm: Add pointer authentication for stack-unwinding runtimeAndrea Corallo1-1/+2
This patch adds authentication for when the stack is unwound when an exception is taken. All the changes here are done to the runtime code in libgcc's unwinder code for Arm target. All the changes are guarded under defined (__ARM_FEATURE_PAC_DEFAULT) and activated only if the +pacbti feature is switched on for the architecture. This means that switching on the target feature via -march or -mcpu is sufficient and -mbranch-protection need not be enabled. This ensures that the unwinder is authenticated only if the PACBTI instructions are available in the non-NOP space as it uses AUTG. Just generating PAC/AUT instructions using -mbranch-protection will not enable authentication on the unwinder. Pre-approved with the requested changes here <https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586555.html>. gcc/ChangeLog: * ginclude/unwind-arm-common.h (_Unwind_VRS_RegClass): Introduce new pseudo register class _UVRSC_PAC. libgcc/ChangeLog: * config/arm/pr-support.c (__gnu_unwind_execute): Decode exception opcode (0xb4) for saving RA_AUTH_CODE and authenticate with AUTG if found. * config/arm/unwind-arm.c (struct pseudo_regs): New. (phase1_vrs): Introduce new field to store pseudo-reg state. (phase2_vrs): Likewise. (_Unwind_VRS_Get): Load pseudo register state from virtual reg set. (_Unwind_VRS_Set): Store pseudo register state to virtual reg set. (_Unwind_VRS_Pop): Load pseudo register value from stack into VRS. Co-Authored-By: Tejas Belagod <tbelagod@arm.com> Co-Authored-By: Srinath Parvathaneni <srinath.parvathaneni@arm.com>
2023-01-16Update copyright years.Jakub Jelinek12-12/+12
2022-11-13ginclude: C2x header version macrosJoseph Myers5-0/+17
C2x adds __STDC_VERSION_*_H__ macros to individual headers with interface changes compared to C17. All the new header features in headers provided by GCC have now been implemented, so define those macros to the value given in the current working draft. Bootstrapped with no regressions for x86_64-pc-linux-gnu. gcc/ * ginclude/float.h [__STDC_VERSION__ > 201710L] (__STDC_VERSION_FLOAT_H__): New macro. * ginclude/stdarg.h [__STDC_VERSION__ > 201710L] (__STDC_VERSION_STDARG_H__): New macro. * ginclude/stdatomic.h [__STDC_VERSION__ > 201710L] (__STDC_VERSION_STDATOMIC_H__): New macro. * ginclude/stddef.h [__STDC_VERSION__ > 201710L] (__STDC_VERSION_STDDEF_H__): New macro. * ginclude/stdint-gcc.h [__STDC_VERSION__ > 201710L] (__STDC_VERSION_STDINT_H__): New macro. * glimits.h [__STDC_VERSION__ > 201710L] (__STDC_VERSION_LIMITS_H__): New macro. gcc/testsuite/ * gcc.dg/c11-float-8.c, gcc.dg/c11-limits-1.c, gcc.dg/c11-stdarg-4.c, gcc.dg/c11-stdatomic-3.c, gcc.dg/c11-stddef-1.c, gcc.dg/c11-stdint-1.c, gcc.dg/c2x-float-13.c, gcc.dg/c2x-limits-1.c, gcc.dg/c2x-stdarg-5.c, gcc.dg/c2x-stdatomic-1.c, gcc.dg/c2x-stddef-1.c, gcc.dg/c2x-stdint-1.c: New tests.
2022-10-28c: tree: target: C2x (...) function prototypes and va_start relaxationJoseph Myers1-0/+4
C2x allows function prototypes to be given as (...), a prototype meaning a variable-argument function with no named arguments. To allow such functions to access their arguments, requirements for va_start calls are relaxed so it ignores all but its first argument (i.e. subsequent arguments, if any, can be arbitrary pp-token sequences). Implement this feature accordingly. The va_start relaxation in <stdarg.h> is itself easy: __builtin_va_start already supports a second argument of 0 instead of a parameter name, and calls get converted internally to the form using 0 for that argument, so <stdarg.h> just needs changing to use a variadic macro that passes 0 as the second argument of __builtin_va_start. (This is done only in C2x mode, on the expectation that users of older standard would expect unsupported uses of va_start to be diagnosed.) For the (...) functions, it's necessary to distinguish these from unprototyped functions, whereas previously C++ (...) functions and unprototyped functions both used NULL TYPE_ARG_TYPES. A flag is added to tree_type_common to mark the (...) functions; as discussed on gcc@, doing things this way is likely to be safer for unchanged code in GCC than adding a different form of representation in TYPE_ARG_TYPES, or adding a flag that instead signals that the function is unprototyped. There was previously an option -fallow-parameterless-variadic-functions to enable support for (...) prototypes. The support was incomplete - it treated the functions as unprototyped, and only parsed some declarations, not e.g. "int g (int (...));". This option is changed into a no-op ignored option; (...) is always accepted syntactically, with a pedwarn_c11 call to given required diagnostics when appropriate. The peculiarity of a parameter list with __attribute__ followed by '...' being accepted with that option is removed. Interfaces in tree.cc that create function types are adjusted to set this flag as appropriate. It is of course possible that some existing users of the functions to create variable-argument functions actually wanted unprototyped functions in the no-named-argument case, rather than functions with a (...) prototype; some such cases in c-common.cc (for built-in functions and implicit function declarations) turn out to need updating for that reason. I didn't do anything to change how the C++ front end creates (...) function types. It's very likely there are unchanged places in the compiler that in fact turn out to need changes to work properly with (...) function prototypes. Target setup_incoming_varargs hooks, where they used the information passed about the last named argument, needed updating to avoid using that information in the (...) case. Note that apart from the x86 changes, I haven't done any testing of those target changes beyond building cc1 to check for syntax errors. It's possible further target-specific fixes will be needed; target maintainers should watch out for failures of c2x-stdarg-4.c or c2x-stdarg-split-1a.c, the execution tests, which would indicate that this feature is not working correctly. Those tests also verify the case where there are named arguments but the last named argument has a declaration that results in undefined behavior in previous C standard versions, such as a type changed by the default argument promotions. Bootstrapped with no regressions for x86_64-pc-linux-gnu. gcc/ * config/aarch64/aarch64.cc (aarch64_setup_incoming_varargs): Check TYPE_NO_NAMED_ARGS_STDARG_P. * config/alpha/alpha.cc (alpha_setup_incoming_varargs): Likewise. * config/arc/arc.cc (arc_setup_incoming_varargs): Likewise. * config/arm/arm.cc (arm_setup_incoming_varargs): Likewise. * config/csky/csky.cc (csky_setup_incoming_varargs): Likewise. * config/epiphany/epiphany.cc (epiphany_setup_incoming_varargs): Likewise. * config/fr30/fr30.cc (fr30_setup_incoming_varargs): Likewise. * config/frv/frv.cc (frv_setup_incoming_varargs): Likewise. * config/ft32/ft32.cc (ft32_setup_incoming_varargs): Likewise. * config/i386/i386.cc (ix86_setup_incoming_varargs): Likewise. * config/ia64/ia64.cc (ia64_setup_incoming_varargs): Likewise. * config/loongarch/loongarch.cc (loongarch_setup_incoming_varargs): Likewise. * config/m32r/m32r.cc (m32r_setup_incoming_varargs): Likewise. * config/mcore/mcore.cc (mcore_setup_incoming_varargs): Likewise. * config/mips/mips.cc (mips_setup_incoming_varargs): Likewise. * config/mmix/mmix.cc (mmix_setup_incoming_varargs): Likewise. * config/nds32/nds32.cc (nds32_setup_incoming_varargs): Likewise. * config/nios2/nios2.cc (nios2_setup_incoming_varargs): Likewise. * config/riscv/riscv.cc (riscv_setup_incoming_varargs): Likewise. * config/rs6000/rs6000-call.cc (setup_incoming_varargs): Likewise. * config/sh/sh.cc (sh_setup_incoming_varargs): Likewise. * config/visium/visium.cc (visium_setup_incoming_varargs): Likewise. * config/vms/vms-c.cc (vms_c_common_override_options): Do not set flag_allow_parameterless_variadic_functions. * doc/invoke.texi (-fallow-parameterless-variadic-functions): Do not document option. * function.cc (assign_parms): Call assign_parms_setup_varargs for TYPE_NO_NAMED_ARGS_STDARG_P case. * ginclude/stdarg.h [__STDC_VERSION__ > 201710L] (va_start): Make variadic macro. Pass second argument of 0 to __builtin_va_start. * target.def (setup_incoming_varargs): Update documentation. * doc/tm.texi: Regenerate. * tree-core.h (struct tree_type_common): Add no_named_args_stdarg_p. * tree-streamer-in.cc (unpack_ts_type_common_value_fields): Unpack TYPE_NO_NAMED_ARGS_STDARG_P. * tree-streamer-out.cc (pack_ts_type_common_value_fields): Pack TYPE_NO_NAMED_ARGS_STDARG_P. * tree.cc (type_cache_hasher::equal): Compare TYPE_NO_NAMED_ARGS_STDARG_P. (build_function_type): Add argument no_named_args_stdarg_p. (build_function_type_list_1, build_function_type_array_1) (reconstruct_complex_type): Update calls to build_function_type. (stdarg_p, prototype_p): Return true for (...) functions. (gimple_canonical_types_compatible_p): Compare TYPE_NO_NAMED_ARGS_STDARG_P. * tree.h (TYPE_NO_NAMED_ARGS_STDARG_P): New. (build_function_type): Update prototype. gcc/c-family/ * c-common.cc (def_fn_type): Call build_function_type for zero-argument variable-argument function. (c_common_nodes_and_builtins): Build default_function_type with build_function_type. * c.opt (fallow-parameterless-variadic-functions): Mark as ignored option. gcc/c/ * c-decl.cc (grokdeclarator): Pass arg_info->no_named_args_stdarg_p to build_function_type. (grokparms): Check arg_info->no_named_args_stdarg_p before converting () to (void). (build_arg_info): Initialize no_named_args_stdarg_p. (get_parm_info): Set no_named_args_stdarg_p. (start_function): Pass TYPE_NO_NAMED_ARGS_STDARG_P to build_function_type. (store_parm_decls): Count (...) functions as prototyped. * c-parser.cc (c_parser_direct_declarator): Allow '...' after open parenthesis to start parameter list. (c_parser_parms_list_declarator): Always allow '...' with no arguments, call pedwarn_c11 and set no_named_args_stdarg_p. * c-tree.h (struct c_arg_info): Add field no_named_args_stdarg_p. * c-typeck.cc (composite_type): Handle TYPE_NO_NAMED_ARGS_STDARG_P. (function_types_compatible_p): Compare TYPE_NO_NAMED_ARGS_STDARG_P. gcc/fortran/ * trans-types.cc (gfc_get_function_type): Do not use build_varargs_function_type_vec for unprototyped function. gcc/lto/ * lto-common.cc (compare_tree_sccs_1): Compare TYPE_NO_NAMED_ARGS_STDARG_P. gcc/objc/ * objc-next-runtime-abi-01.cc (build_next_objc_exception_stuff): Use build_function_type to build type of objc_setjmp_decl. gcc/testsuite/ * gcc.dg/c11-stdarg-1.c, gcc.dg/c11-stdarg-2.c, gcc.dg/c11-stdarg-3.c, gcc.dg/c2x-stdarg-1.c, gcc.dg/c2x-stdarg-2.c, gcc.dg/c2x-stdarg-3.c, gcc.dg/c2x-stdarg-4.c, gcc.dg/gnu2x-stdarg-1.c, gcc.dg/torture/c2x-stdarg-split-1a.c, gcc.dg/torture/c2x-stdarg-split-1b.c: New tests. * gcc.dg/Wold-style-definition-2.c, gcc.dg/format/sentinel-1.c: Update expected diagnostics. * gcc.dg/c2x-nullptr-1.c (test5): Cast unused parameter to (void). * gcc.dg/diagnostic-token-ranges.c: Use -pedantic. Expect warning in place of error.
2022-10-13c: Do not use *_IS_IEC_60559 == 2Joseph Myers1-2/+1
A late change for C2x (addressing comments from the second round of editorial review before the CD ballot, postdating the most recent public working draft) removed the value 2 for *_IS_IEC_60559 (a new <float.h> macro added in C2x). Adjust the implementation accordingly not to use this value. Bootstrapped with no regressions for x86_64-pc-linux-gnu. gcc/ * ginclude/float.h (FLT_IS_IEC_60559, DBL_IS_IEC_60559) (LDBL_IS_IEC_60559): Update comment. gcc/c-family/ * c-cppbuiltin.cc (builtin_define_float_constants): Do not use value 2 for *_IS_IEC_60559. gcc/testsuite/ * gcc.dg/c2x-float-10.c: Do not expect value 2 for *_IS_IEC_60559.
2022-10-07undef offsetof before defining it in stddef.hOlivier Hainque1-0/+1
This prevents redefinition warnings by -Wsystem-headers on OSses where system headers happen to provide a definition of their own, such as VxWorks. 2022-02-15 Olivier Hainque <hainque@adacore.com> gcc/ * ginclude/stddef.h: #undef offsetof before #define.
2022-09-15float.h: Do not define INFINITY for C2x when infinities not supportedJoseph Myers1-1/+3
C2x has changed the rules for defining INFINITY in <float.h> so it is no longer defined when float does not support infinities, instead of being defined to an expression that overflows at translation time. Thus, make the definition conditional on __FLT_HAS_INFINITY__ (this is already inside a C2x-conditional part of <float.h>, because previous C standard versions only had this macro in <math.h>). Bootstrapped with no regressions for x86_64-pc-linux-gnu. Also did a spot test of the case of no infinities supported by building cc1 for vax-netbsdelf and testing compiling the new c2x-float-11.c test with it. gcc/ * ginclude/float.h (INFINITY): Define only if [__FLT_HAS_INFINITY__]. gcc/testsuite/ * gcc.dg/c2x-float-2.c: Require inff effective-target. * gcc.dg/c2x-float-11.c: New test.
2022-09-12stdatomic.h: Do not define ATOMIC_VAR_INIT for C2xJoseph Myers1-0/+2
The <stdatomic.h> macro ATOMIC_VAR_INIT, previously declared obsolete, is removed completely in C2x; disable it for C2x in GCC's implementation. (Although ATOMIC_* are reserved names for this header, disabling the macro for C2x still seems appropriate.) Bootstrapped with no regressions for x86_64-pc-linux-gnu. gcc/ * ginclude/stdatomic.h [defined __STDC_VERSION__ && __STDC_VERSION__ > 201710L] (ATOMIC_VAR_INIT): Do not define. gcc/testsuite/ * gcc.dg/atomic/c2x-stdatomic-var-init-1.c: New test.
2022-09-09stddef.h: Add C2x unreachable macroJoseph Myers1-0/+4
C2x adds a macro unreachable to stddef.h, with the same semantics as __builtin_unreachable. Define this macro accordingly. Bootstrapped with no regressions for x86_64-pc-linux-gnu. gcc/ * ginclude/stddef.h [__STDC_VERSION__ > 201710L] (unreachable): New macro. gcc/testsuite/ * gcc.dg/c11-unreachable-1.c, gcc.dg/c2x-unreachable-1.c: New tests.
2022-09-07c: New C2x keywordsJoseph Myers2-4/+4
C2x follows C++ in making alignas, alignof, bool, false, static_assert, thread_local and true keywords; implement this accordingly. This implementation makes them normal keywords in C2x mode just like any other keyword (C2x leaves open the possibility of implementation using predefined macros instead - thus, there aren't any testcases asserting that they aren't macros). As in C++ and previous versions of C, true and false are handled like signed 1 and 0 in #if (there was an intermediate state in some C2x drafts where they had different macro expansions that were unsigned in #if). Bootstrapped with no regressions for x86_64-pc-linux-gnu. As with the removal of unprototyped functions, this change has a high risk of breaking some old code and people doing GNU/Linux distribution builds may wish to see how much is broken in a build with a -std=gnu2x default. gcc/ * ginclude/stdalign.h [defined __STDC_VERSION__ && __STDC_VERSION__ > 201710L]: Disable all content. * ginclude/stdbool.h [defined __STDC_VERSION__ && __STDC_VERSION__ > 201710L] (bool, true, false): Do not define. gcc/c-family/ * c-common.cc (c_common_reswords): Use D_C2X instead of D_CXXONLY for alignas, alignof, bool, false, static_assert, thread_local and true. gcc/c/ * c-parser.cc (c_parser_static_assert_declaration_no_semi) (c_parser_alignas_specifier, c_parser_alignof_expression): Allow for C2x spellings of keywords. (c_parser_postfix_expression): Handle RID_TRUE and RID_FALSE. gcc/testsuite/ * gcc.dg/c11-keywords-1.c, gcc.dg/c2x-align-1.c, gcc.dg/c2x-align-6.c, gcc.dg/c2x-bool-2.c, gcc.dg/c2x-static-assert-3.c, gcc.dg/c2x-static-assert-4.c, gcc.dg/c2x-thread-local-1.c: New tests. * gcc.dg/c2x-bool-1.c: Update expectations. libcpp/ * include/cpplib.h (struct cpp_options): Add true_false. * expr.cc (eval_token): Check true_false not cplusplus to determine whether to handle true and false keywords. * init.cc (struct lang_flags): Add true_false. (lang_defaults): Update. (cpp_set_lang): Set true_false.
2022-08-25c: Implement C23 nullptr (N3042)Marek Polacek1-0/+8
This patch implements the C23 nullptr literal: <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3042.htm> (with wording fixes from N3047), which is intended to replace the problematic definition of NULL which might be either of integer type or void*. Since C++ has had nullptr for over a decade now, it was relatively easy to just move the built-in node definitions from the C++ FE to the C/C++ common code. Also, our DWARF emitter already handles NULLPTR_TYPE by emitting DW_TAG_unspecified_type. However, I had to handle a lot of contexts such as ?:, comparison, conversion, etc. There are some minor differences, e.g. in C you can do bool b = nullptr; but in C++ you have to use direct-initialization: bool b{nullptr}; And I think that nullptr_t n = 0; is only valid in C++. Of course, C doesn't have to handle mangling, RTTI, substitution, overloading, ... This patch also defines nullptr_t in <stddef.h>. However, it does not define __STDC_VERSION_STDDEF_H__ yet, because we don't know yet what value it should be defined to. gcc/c-family/ChangeLog: * c-common.cc (c_common_reswords): Enable nullptr in C2X. (c_common_nodes_and_builtins): Create the built-in node for nullptr. * c-common.h (enum c_tree_index): Add CTI_NULLPTR, CTI_NULLPTR_TYPE. (struct c_common_resword): Resize the disable member. (D_C2X): Add. (nullptr_node): Define. (nullptr_type_node): Define. (NULLPTR_TYPE_P): Define. * c-pretty-print.cc (c_pretty_printer::simple_type_specifier): Handle NULLPTR_TYPE. (c_pretty_printer::direct_abstract_declarator): Likewise. (c_pretty_printer::constant): Likewise. gcc/c/ChangeLog: * c-convert.cc (c_convert) <case POINTER_TYPE>: Handle NULLPTR_TYPE. Give a better diagnostic when converting to nullptr_t. * c-decl.cc (c_init_decl_processing): Perform C-specific nullptr initialization. * c-parser.cc (c_parse_init): Maybe OR D_C2X into mask. (c_parser_postfix_expression): Handle RID_NULLPTR. * c-typeck.cc (null_pointer_constant_p): Return true when expr is nullptr_node. (build_unary_op) <case TRUTH_NOT_EXPR>: Handle NULLPTR_TYPE. (build_conditional_expr): Handle the case when the second/third operand is NULLPTR_TYPE and third/second operand is POINTER_TYPE. (convert_for_assignment): Handle converting an expression of type nullptr_t to pointer/bool. (build_binary_op) <case TRUTH_XOR_EXPR>: Handle NULLPTR_TYPE. <case EQ_EXPR>: Handle comparing operands of type nullptr_t. gcc/cp/ChangeLog: * cp-tree.h (enum cp_tree_index): Remove CTI_NULLPTR, CTI_NULLPTR_TYPE. Move it to c_tree_index. (nullptr_node): No longer define here. (nullptr_type_node): Likewise. (NULLPTR_TYPE_P): Likewise. * decl.cc (cxx_init_decl_processing): Only keep C++-specific nullptr initialization; move the shared code to c_common_nodes_and_builtins. gcc/ChangeLog: * ginclude/stddef.h: Define nullptr_t. gcc/testsuite/ChangeLog: * gcc.dg/c11-nullptr-1.c: New test. * gcc.dg/c17-nullptr-1.c: New test. * gcc.dg/c17-nullptr-2.c: New test. * gcc.dg/c2x-nullptr-1.c: New test. * gcc.dg/c2x-nullptr-2.c: New test. * gcc.dg/c2x-nullptr-3.c: New test. * gcc.dg/c2x-nullptr-4.c: New test. * gcc.dg/c2x-nullptr-5.c: New test.
2022-08-08C: Implement C2X N2653 char8_t and UTF-8 string literal changesTom Honermann1-0/+6
This patch implements the core language and compiler dependent library changes adopted for C2X via WG14 N2653. The changes include: - Change of type for UTF-8 string literals from array of const char to array of const char8_t (unsigned char). - A new atomic_char8_t typedef. - A new ATOMIC_CHAR8_T_LOCK_FREE macro defined in terms of the existing __GCC_ATOMIC_CHAR8_T_LOCK_FREE predefined macro. gcc/ChangeLog: * ginclude/stdatomic.h (atomic_char8_t, ATOMIC_CHAR8_T_LOCK_FREE): New typedef and macro. gcc/c/ChangeLog: * c-parser.cc (c_parser_string_literal): Use char8_t as the type of CPP_UTF8STRING when char8_t support is enabled. * c-typeck.cc (digest_init): Allow initialization of an array of character type by a string literal with type array of char8_t. gcc/c-family/ChangeLog: * c-lex.cc (lex_string, lex_charconst): Use char8_t as the type of CPP_UTF8CHAR and CPP_UTF8STRING when char8_t support is enabled. * c-opts.cc (c_common_post_options): Set flag_char8_t if targeting C2x. gcc/testsuite/ChangeLog: * gcc.dg/atomic/c2x-stdatomic-lockfree-char8_t.c: New test. * gcc.dg/atomic/gnu2x-stdatomic-lockfree-char8_t.c: New test. * gcc.dg/c11-utf8str-type.c: New test. * gcc.dg/c17-utf8str-type.c: New test. * gcc.dg/c2x-utf8str-type.c: New test. * gcc.dg/c2x-utf8str.c: New test. * gcc.dg/gnu2x-utf8str-type.c: New test. * gcc.dg/gnu2x-utf8str.c: New test.
2022-01-03Update copyright years.Jakub Jelinek12-12/+12
2021-12-14[PATCH] stddef.h: add support for musl typedef macro guardsSören Tempel1-0/+9
The stddef.h header checks/sets various hardcoded toolchain/os specific macro guards to prevent redefining types such as ptrdiff_t, wchar_t, or size_t. However, without this patch, the file does not check/set the typedef macro guards for musl libc. This causes types such as size_t to be defined twice for files which include both musl's stdlib.h as well as GCC's ginclude/stddef.h. This is, for example, the case for libgo/sysinfo.c. If libgo/sysinfo.c has multiple typedefs for size_t this confuses -fdump-go-spec and causes size_t not to be included in the generated type definitions thereby causing a gcc-go compilation failure on Alpine Linux Edge (which uses musl libc) with the following error: sysinfo.go:7765:13: error: use of undefined type '_size_t' 7765 | type Size_t _size_t | ^ libcall_posix.go:49:35: error: non-integer len argument in make 49 | b := make([]byte, len) | This commit fixes this issue by ensuring that ptrdiff_t, wchar_t, and size_t are only defined once in the pre-processed libgo/sysinfo.c file by enhancing gcc/ginclude/stddef.h with musl-specific typedef macro guards. gcc/ChangeLog: * ginclude/stddef.h (__DEFINED_ptrdiff_t): Add support for musl libc typedef macro guard. (__DEFINED_size_t): Ditto. (__DEFINED_wchar_t): Ditto.
2021-01-04Update copyright years.Jakub Jelinek12-12/+12
2020-11-26C: Do not drop qualifiers in typeof for _Atomic types. [PR65455,PR92935]Martin Uecker1-7/+7
2020-11-25 Martin Uecker <muecker@gwdg.de> gcc/c/ PR c/65455 PR c/92935 * c-parser.c (c_parser_declaration_or_fndef): Remove redundant code to drop qualifiers of _Atomic types for __auto_type. (c_parser_typeof_specifier): Do not drop qualifiers of _Atomic types for __typeof__. gcc/ PR c/65455 PR c/92935 * ginclude/stdatomic.h: Use comma operator to drop qualifiers. gcc/testsuite/ PR c/65455 PR c/92935 * gcc.dg/typeof-2.c: Adapt test.
2020-11-17float.h: Handle C2x __STDC_WANT_IEC_60559_EXT__Joseph Myers1-1/+2
TS 18661-1 and 18661-2 have various definitions conditional on __STDC_WANT_IEC_60559_BFP_EXT__ and __STDC_WANT_IEC_60559_DFP_EXT__ macros. When those TSes were integrated into C2x, most of the feature test macro conditionals were removed (with declarations for decimal FP becoming conditional only on whether decimal FP is supported by the implementation and those for binary FP becoming unconditionally required). A few tests of those feature test macros remained for declarations that appeared only in Annex F and not in the main part of the standard. A change accepted for C2x at the last WG14 meeting (but not yet added to the working draft in git) was to replace both those macros by __STDC_WANT_IEC_60559_EXT__; if __STDC_WANT_IEC_60559_EXT__ is defined, the specific declarations in the headers will then depend on which features are supported by the implementation, as for declarations not controlled by a feature test macro at all. Thus, add a check of __STDC_WANT_IEC_60559_EXT__ for CR_DECIMAL_DIG in float.h, the only case of this change relevant to GCC. Bootstrapped with no regressions for x86_64-pc-linux-gnu. gcc/ 2020-11-17 Joseph Myers <joseph@codesourcery.com> * ginclude/float.h (CR_DECIMAL_DIG): Also define for [__STDC_WANT_IEC_60559_EXT__]. gcc/testsuite/ 2020-11-17 Joseph Myers <joseph@codesourcery.com> * gcc.dg/cr-decimal-dig-3.c: New test.
2020-11-17float.h: C2x *_IS_IEC_60559 macrosJoseph Myers1-0/+9
C2x adds float.h macros that say whether float, double and long double match an IEC 60559 (IEEE 754) format and operations. Add these macros to GCC's float.h. Bootstrapped with no regressions for x86_64-pc-linux-gnu. gcc/c-family/ 2020-11-17 Joseph Myers <joseph@codesourcery.com> * c-cppbuiltin.c (builtin_define_float_constants): Define "*_IS_IEC_60559__" macros. gcc/ 2020-11-17 Joseph Myers <joseph@codesourcery.com> * ginclude/float.h [__STDC_VERSION__ > 201710L] (FLT_IS_IEC_60559, DBL_IS_IEC_60559, LDBL_IS_IEC_60559): New macros. gcc/testsuite/ 2020-11-17 Joseph Myers <joseph@codesourcery.com> * gcc.dg/c11-float-6.c, gcc.dg/c2x-float-10.c: New tests.
2020-11-17float.h: C2x decimal signaling NaN macrosJoseph Myers1-0/+8
C2x adds macros for decimal floating-point signaling NaNs to <float.h>. Add these macros to GCC's <float.h> implementation. Note that the current C2x draft has these under incorrect names D32_SNAN, D64_SNAN, D128_SNAN. The intent was to change the naming convention to be consistent with other <float.h> macros when they were moved to <float.h>, so DEC32_SNAN, DEC64_SNAN, DEC128_NAN, which this patch uses (as does the current draft integration of TS 18661-3 as an Annex to C2x, for its _Decimal* and _Decimal*x types). Bootstrapped with no regressions for x86_64-pc-linux-gnu. gcc/ 2020-11-17 Joseph Myers <joseph@codesourcery.com> * ginclude/float.h (DEC32_SNAN, DEC64_SNAN, DEC128_SNAN): New C2x macros. gcc/testsuite/ 2020-11-17 Joseph Myers <joseph@codesourcery.com> * gcc.dg/dfp/c2x-float-dfp-7.c, gcc.dg/dfp/c2x-float-dfp-8.c: New tests. * gcc.dg/c2x-float-no-dfp-3.c: Also check that DEC32_SNAN, DEC64_SNAN and DEC128_SNAN are not defined.
2020-11-17float.h: C2x NaN and Inf macrosJoseph Myers1-0/+66
C2x adds macros for NaNs and infinities to <float.h>, some of them previously in <math.h> (and some still in <math.h> as well in C2x as an obsolescent feature). Add these macros to GCC's <float.h> implementation. This omits the macros for DFP signaling NaNs, leaving those to be added in a separate patch. However, it includes the _FloatN / _FloatNx macros (conditional on __STDC_WANT_IEC_60559_TYPES_EXT__) in the current draft version of the integration of TS 18661-3 into C2x as an Annex. As GCC allows duplicate macro definitions with different expansions in system headers, it should be OK if <math.h> defines INFINITY or NAN with a slightly different expansion (e.g. different choice of whether there is whitespace between tokens); tests are added including <float.h> and <math.h> in either order. Because <float.h> uses #undef on all macros before defining them, even with -Wsystem-headers there could only ever be issues when <math.h> is included after <float.h>. Bootstrapped with no regressions on x86_64-pc-linux-gnu. gcc/ 2020-11-17 Joseph Myers <joseph@codesourcery.com> * ginclude/float.h (INFINITY, NAN, FLT_SNAN, DBL_SNAN, LDBL_SNAN) (FLT16_SNAN, FLT32_SNAN, FLT64_SNAN, FLT128_SNAN, FLT32X_SNAN) (FLT64X_SNAN, FLT128X_SNAN, DEC_INFINITY, DEC_NAN): New C2x macros. * doc/sourcebuild.texi (Effective-Target Keywords): Document inff. gcc/testsuite/ 2020-11-17 Joseph Myers <joseph@codesourcery.com> * lib/target-supports.exp (check_effective_target_inff): New. * gcc.dg/c11-float-4.c, gcc.dg/c11-float-5.c, gcc.dg/c11-float-dfp-2.c, gcc.dg/c2x-float-2.c, gcc.dg/c2x-float-3.c, gcc.dg/c2x-float-4.c, gcc.dg/c2x-float-5.c, gcc.dg/c2x-float-6.c, gcc.dg/c2x-float-7.c, gcc.dg/c2x-float-8.c, gcc.dg/c2x-float-9.c, gcc.dg/c2x-float-no-dfp-3.c, gcc.dg/c2x-float-no-dfp-4.c, gcc.dg/dfp/c2x-float-dfp-4.c, gcc.dg/dfp/c2x-float-dfp-5.c, gcc.dg/dfp/c2x-float-dfp-6.c, gcc.dg/torture/float128-nan-floath.c, gcc.dg/torture/float128x-nan-floath.c, gcc.dg/torture/float16-nan-floath.c, gcc.dg/torture/float32-nan-floath.c, gcc.dg/torture/float32x-nan-floath.c, gcc.dg/torture/float64-nan-floath.c, gcc.dg/torture/float64x-nan-floath.c, gcc.dg/torture/floatn-nan-floath.h: New tests.
2020-10-29stdbool.h: Update true and false expansions for C2xJoseph Myers1-0/+5
C2x has changed the expansions of the true and false macros in <stdbool.h> so that they have type _Bool (including in #if conditions, i.e. an unsigned type in that context). Use the new expansions in GCC's <stdbool.h> for C2x. See bug 82272 for related discussion (but this patch does *not* implement the warning discussed there). Note that it's possible there may be a further change to make bool, true and false keywords (there was support in principle for that at the April WG14 meeting). But currently these expansions of type _Bool are what C2x requires and there isn't actually a paper before WG14 at present that would introduce the new keywords. Bootstrapped with no regressions on x86_64-pc-linux-gnu. gcc/ 2020-10-29 Joseph Myers <joseph@codesourcery.com> * ginclude/stdbool.h [__STDC_VERSION__ > 201710L] (true, false): Define with type _Bool. gcc/testsuite/ 2020-10-29 Joseph Myers <joseph@codesourcery.com> * gcc.dg/c11-bool-1.c, gcc.dg/c2x-bool-1.c, gcc.dg/c99-bool-4.c: New tests.
2020-09-02c++: Stop defining true, false and bool as macros in <stdbool.h>Jonathan Wakely1-7/+0
Since r216679 these macros have only been defined in C++98 mode, rather than all modes. That is permitted as a GNU extension because that header doesn't exist in the C++ standard until C++11, so we can make it do whatever we want for C++98. But as discussed in the PR c++/60304 comments, these macros shouldn't ever be defined for C++. This patch removes the macro definitions for C++98 too. The new test already passed for C++98 (and the conversion is ill-formed in C++11 and later) so this new test is arguably unnecessary. gcc/ChangeLog: PR c++/60304 * ginclude/stdbool.h (bool, false, true): Never define for C++. gcc/testsuite/ChangeLog: PR c++/60304 * g++.dg/warn/Wconversion-null-5.C: New test.
2020-01-01Update copyright years.Jakub Jelinek12-12/+12
From-SVN: r279813
2019-11-13Add C2x *_NORM_MAX constants to <float.h>.Joseph Myers1-0/+12
C2x adds <float.h> constants FLT_NORM_MAX, DBL_NORM_MAX and LDBL_NORM_MAX. These are for the maximum "normalized" finite floating-point number, where the given definition of normalized is that all possible values with MANT_DIG significand digits (leading one not zero) can be represented with that exponent. The effect of that definition is that these macros are the same as the corresponding MAX macros for all formats except IBM long double, where the NORM_MAX value has exponent 1 smaller than the MAX one so that all 106 digits can be 1. This patch adds those macros to GCC. They are only defined for float, double and long double; C2x does not include such macros for DFP types, and while the integration of TS 18661-3 into C2x has not yet occurred, the draft proposed text does not add them for the _FloatN / _FloatNx types (where they would always be the same as the MAX macros). Bootstrapped with no regressions on x86_64-pc-linux-gnu. Also tested compilation of the new test for powerpc-linux-gnu to confirm the check of LDBL_NORM_MAX in the IBM long double case does get properly optimized out. gcc: * ginclude/float.c [__STDC_VERSION__ > 201710L] (FLT_NORM_MAX, DBL_NORM_MAX, LDBL_NORM_MAX): Define. * real.c (get_max_float): Add norm_max argument. * real.h (get_max_float): Update prototype. * builtins.c (fold_builtin_interclass_mathfn): Update calls to get_max_float. gcc/c-family: * c-cppbuiltin.c (builtin_define_float_constants): Also define NORM_MAX constants. Update call to get_max_float. (LAZY_HEX_FP_VALUES_CNT): Update value to include NORM_MAX constants. gcc/d: * d-target.cc (define_float_constants): Update call to get_max_float. gcc/testsuite: * gcc.dg/c11-float-3.c, gcc.dg/c2x-float-1.c: New tests. From-SVN: r278145
2019-10-10Update DFP macros in float.h for C2x and TS 18661-2.Joseph Myers1-12/+35
GCC's <float.h> includes various macros for decimal floating-point types, defined if __STDC_WANT_DEC_FP__, as defined in TS 24732. TS 18661-2 and C2X make some changes to those macros. In TS 18661-2, they are to be defined if __STDC_WANT_IEC_60559_DFP_EXT__, and the *_SUBNORMAL_MIN macros are renamed to *_TRUE_MIN. In C2X, the macros are to be defined whenever DFP is supported, without needing any feature test macro to be defined. This patch updates the header accordingly. There is no existing predefined macro for whether the target supports DFP; rather than adding a new macro for that purpose, this patch changes the predefined macros used in <float.h> so that they are only defined when DFP is supported and thus can be used as conditionals; this is the same way predefined macros for _FloatN and _FloatNx types work. Although formally TR 24732 and TS 18661-2 say nothing about implementations lacking DFP support, it seems appropriate to avoid defining the macros in <float.h>, in the absence of DFP support, even if the respective feature test macros are defined. Bootstrapped with no regressions on x86_64-pc-linux-gnu. Also tested the c2x-float-no-dfp-* tests for aarch64-linux-gnu to make sure they do pass in a no-DFP configuration. gcc: * ginclude/float.h [!__DEC32_MANT_DIG__]: Do not define DFP macros. [__STDC_WANT_IEC_60559_DFP_EXT__ || __STDC_VERSION__ > 201710L]: Also define DFP macros for these conditions. [!__STDC_WANT_DEC_FP__] (DEC32_SUBNORMAL_MIN, DEC64_SUBNORMAL_MIN, DEC128_SUBNORMAL_MIN): Do not define. [__STDC_WANT_IEC_60559_DFP_EXT__ || __STDC_VERSION__ > 201710L] (DEC32_TRUE_MIN, DEC64_TRUE_MIN, DEC128_TRUE_MIN): New macros. gcc/c-family: * c-cppbuiltin.c (c_cpp_builtins): Do not define macros for DFP types if DFP not supported. gcc/testsuite: * gcc.dg/c11-float-dfp-1.c, gcc.dg/c2x-float-no-dfp-1.c, gcc.dg/c2x-float-no-dfp-2.c, gcc.dg/dfp/c2x-float-dfp-1.c, gcc.dg/dfp/c2x-float-dfp-2.c, gcc.dg/dfp/c2x-float-dfp-3.c, gcc.dg/dfp/tr24732-float-dfp-1.c, gcc.dg/dfp/ts18661-2-float-dfp-1.c: New tests. From-SVN: r276854
2019-10-03Define WIDTH macros for C2x.Joseph Myers1-2/+3
As part of the integration of TS 18661-1 into C2x, many features became unconditional features not depending on any feature test macro being defined. This patch updates the conditionals on the *_WIDTH macros in limits.h and stdint.h accordingly so that they are defined for C2x. The macro CR_DECIMAL_DIG in float.h does still require __STDC_WANT_IEC_60559_BFP_EXT__ to be defined, and a test for this is added. Bootstrapped with no regressions on x86_64-pc-linux-gnu. gcc: * ginclude/stdint-gcc.h [__STDC_WANT_IEC_60559_BFP_EXT__]: Change condition on WIDTH macros to [__STDC_WANT_IEC_60559_BFP_EXT__ || (__STDC_VERSION__ && __STDC_VERSION__ > 201710L)]. * glimits.h: Likewise. gcc/testsuite: * gcc.dg/cr-decimal-dig-2.c: New test. * gcc.dg/limits-width-2.c: New test. Based on limits-width-1.c. * gcc.dg/stdint-width-2.c: New test. Based on stdint-width-1.c. From-SVN: r276497
2019-09-10[ARM/FDPIC v6 06/24] [ARM] FDPIC: Add support for c++ exceptionsChristophe Lyon1-1/+1
The main difference with existing support is that function addresses are function descriptor addresses instead. This means that all code dealing with function pointers now has to cope with function descriptors instead. For the same reason, Linux kernel helpers can no longer be called by dereferencing their address, so we implement wrappers that directly call the kernel helpers. When restoring a function address, we also have to restore the FDPIC register value (r9). 2019-09-10 Christophe Lyon <christophe.lyon@st.com> Mickaël Guêné <mickael.guene@st.com> gcc/ * ginclude/unwind-arm-common.h (unwinder_cache): Add reserved5 field. libgcc/ * config/arm/linux-atomic.c (__kernel_cmpxchg): Add FDPIC support. (__kernel_dmb): Likewise. (__fdpic_cmpxchg): New function. (__fdpic_dmb): New function. * config/arm/unwind-arm.h (FDPIC_REGNUM): New define. (gnu_Unwind_Find_got): New function. (_Unwind_decode_typeinfo_ptr): Add FDPIC support. * unwind-arm-common.inc (UCB_PR_GOT): New. (funcdesc_t): New struct. (get_eit_entry): Add FDPIC support. (unwind_phase2): Likewise. (unwind_phase2_forced): Likewise. (__gnu_Unwind_RaiseException): Likewise. (__gnu_Unwind_Resume): Likewise. (__gnu_Unwind_Backtrace): Likewise. * unwind-pe.h (read_encoded_value_with_base): Likewise. libstdc++/ * libsupc++/eh_personality.cc (get_ttype_entry): Add FDPIC support. Co-Authored-By: Mickaël Guêné <mickael.guene@st.com> From-SVN: r275568
2019-06-24Define C11 macros such as FLT_DECIMAL_DIG for C++17Jonathan Wakely1-1/+2
* testsuite/18_support/headers/cfloat/values_c++17.cc: New test. From-SVN: r272615
2019-01-01Update copyright years.Jakub Jelinek12-12/+12
From-SVN: r267494
2018-06-25stddef.h: Remove an obsolete comment on FreeBSD 5.Gerald Pfeifer1-3/+3
* ginclude/stddef.h: Remove an obsolete comment on FreeBSD 5. Simplify logic for FreeBSD (twice). From-SVN: r262121
2018-06-24stddef.h: Simplify conditions around avoiding re-definition of __size_t.Maya Rashish1-4/+3
* ginclude/stddef.h: Simplify conditions around avoiding re-definition of __size_t. From-SVN: r261998
2018-06-20* ginclude/stddef.h: Limit #include <machine/ansi.h> to NetBSD.Maya Rashish1-15/+5
From-SVN: r261797
2018-01-03Update copyright years.Jakub Jelinek12-12/+12
From-SVN: r256169
2017-11-15Add __builtin_tgmath for better tgmath.h implementation (bug 81156).Joseph Myers1-63/+19
Various implementations of C99/C11 <tgmath.h> have the property that their macro expansions contain many copies of the macro arguments, so resulting in exponential blowup of the size of macro expansions where a call to such a macro contains other such calls in the macro arguments. This patch adds a (C-only) language feature __builtin_tgmath designed to avoid this problem by implementing the <tgmath.h> function selection rules directly in the compiler. The effect is that type-generic macros can be defined simply as #define pow(a, b) __builtin_tgmath (powf, pow, powl, \ cpowf, cpow, cpowl, a, b) as in the example added to the manual, with each macro argument expanded exactly once. The details of __builtin_tgmath are as described in the manual. This is C-only since C++ uses function overloading and just defines <ctgmath> to include <ccomplex> and <cmath>. __builtin_tgmath handles C99/C11 type-generic macros, and _FloatN, _FloatNx and decimal floating-point types (following the proposed resolution to the floating-point TS DR#9 that makes the rules for finding a common type from arguments to a type-generic macro follow the usual arithmetic conversions after adjustment of integer arguments to _Decimal64 or double - or to _Complex double in the case of GNU complex integer arguments). Type-generic macros for functions from TS 18661 that round their results to a narrower type are handled, but there are still some unresolved questions regarding such macros so further changes in that regard may be needed in future. The current implementation follows an older version of the DR#13 resolution (allowing a function for a wide-enough argument type to be selected if no exactly-matching function is available), but with appropriate calls to __builtin_tgmath is still fully compatible with the latest version of the resolution (not yet in the DR log), and allowing such not-exactly-matching argument types to be chosen in that case avoids needing another special case to treat integers as _Float64 instead of double in certain cases. Regarding other possible language/library features, not currently implemented in GCC: * Imaginary types could be naturally supported by allowing cases where the type-generic type is an imaginary type T and arguments or return types may be T (as at present), or the corresponding real type to T (as at present), or (new) the corresponding real type if T is real or imaginary but T if T is complex. (tgmath.h would need a series of functions such as static inline _Imaginary double __sin_imag (_Imaginary double __x) { return _Imaginary_I * sinh (__imag__ __x); } to be used in __builtin_tgmath calls.) * __builtin_tgmath would use the constant rounding direction in the presence of support for the FENV_ROUND / FENV_DEC_ROUND pragmas. Support for those would also require a new __builtin_<something> to cause a non-type-generic call to use the constant rounding direction (it seems cleaner to add a new __builtin_<something> when required than to make __builtin_tgmath handle a non-type-generic case with only one function argument). * TS 18661-5 __STDC_TGMATH_OPERATOR_EVALUATION__ would require new __builtin_<something> that evaluates with excess range and precision like arithmetic operators do. * The proposed C bindings for IEEE 754-2018 augmented arithmetic operations involve struct return types. As currently implemented __builtin_tgmath does not handle those, but support could be added. There are many error cases that the implementation diagnoses. I've tried to ensure reasonable error messages for erroneous uses of __builtin_tgmath, but the errors for erroneous uses of the resulting type-generic macros (that is, when the non-function arguments have inappropriate types) are more important as they are more likely to be seen by users. GCC's own tgmath.h, as used for some targets, is updated in this patch. I've tested those changes minimally, via adjusting gcc.dg/c99-tgmath-* locally to use that tgmath.h version. I've also run the glibc testsuite (which has much more thorough tests of correctness of tgmath.h function selection) with a glibc patch to use __builtin_tgmath in glibc's tgmath.h. Bootstrapped with no regressions on x86_64-pc-linux-gnu. PR c/81156 gcc: * doc/extend.texi (Other Builtins): Document __builtin_tgmath. * ginclude/tgmath.h (__tg_cplx, __tg_ldbl, __tg_dbl, __tg_choose) (__tg_choose_2, __tg_choose_3, __TGMATH_REAL_1_2) (__TGMATH_REAL_2_3): Remove macros. (__TGMATH_CPLX, __TGMATH_CPLX_2, __TGMATH_REAL, __TGMATH_REAL_2) (__TGMATH_REAL_3, __TGMATH_CPLX_ONLY): Define using __builtin_tgmath. (frexp, ldexp, nexttoward, scalbn, scalbln): Define using __TGMATH_REAL_2. (remquo): Define using __TGMATH_REAL_3. gcc/c: * c-parser.c (check_tgmath_function): New function. (enum tgmath_parm_kind): New enum. (c_parser_postfix_expression): Handle __builtin_tgmath. gcc/c-family: * c-common.c (c_common_reswords): Add __builtin_tgmath. * c-common.h (enum rid): Add RID_BUILTIN_TGMATH. gcc/testsuite: * gcc.dg/builtin-tgmath-1.c, gcc.dg/builtin-tgmath-2.c, gcc.dg/builtin-tgmath-err-1.c, gcc.dg/builtin-tgmath-err-2.c, gcc.dg/dfp/builtin-tgmath-dfp-err.c, gcc.dg/dfp/builtin-tgmath-dfp.c: New tests. From-SVN: r254749
2017-01-01Update copyright years.Jakub Jelinek12-12/+12
From-SVN: r243994
2016-11-23[Patch 6/17] Migrate excess precision logic to use TARGET_EXCESS_PRECISIONJames Greenhalgh1-10/+62
gcc/ * toplev.c (init_excess_precision): Delete most logic. * tree.c (excess_precision_type): Rewrite to use TARGET_EXCESS_PRECISION. * doc/invoke.texi (-fexcess-precision): Document behaviour in a more generic fashion. * ginclude/float.h: Wrap definition of FLT_EVAL_METHOD in __STDC_WANT_IEC_60559_TYPES_EXT__. gcc/c-family/ * c-common.c (excess_precision_mode_join): New. (c_ts18661_flt_eval_method): New. (c_c11_flt_eval_method): Likewise. (c_flt_eval_method): Likewise. * c-common.h (excess_precision_mode_join): New. (c_flt_eval_method): Likewise. * c-cppbuiltin.c (c_cpp_flt_eval_method_iec_559): New. (cpp_iec_559_value): Call it. (c_cpp_builtins): Modify logic for __LIBGCC_*_EXCESS_PRECISION__, call c_flt_eval_method to set __FLT_EVAL_METHOD__ and __FLT_EVAL_METHOD_TS_18661_3__. gcc/testsuite/ * gcc.dg/fpermitted-flt-eval-methods_3.c: New. * gcc.dg/fpermitted-flt-eval-methods_4.c: Likewise. From-SVN: r242776
2016-09-19Define TS 18661-1 CR_DECIMAL_DIG in <float.h>.Joseph Myers1-0/+7
TS 18661-1 defines a macro CR_DECIMAL_DIG in <float.h>, for the number of decimal digits for which conversions between decimal character strings and (IEEE) binary formats, in both directions, are correctly rounded. This patch implements support for this macro in GCC's <float.h>. The definition __UINTMAX_MAX__ is the right one for GCC's conversions of floating constants, since I made those use MPFR to make them correctly rounding. The macro also covers standard library functions such as strtod and printf. The definition is also correct for current glibc. If any targets' libcs support correct rounding in a way that conforms to TS 18661-1 with a smaller value of CR_DECIMAL_DIG, making <float.h> reflect that could not be done in isolation without changes to the interpretation of floating constants as well, since a smaller CR_DECIMAL_DIG requires double rounding of floating constants (first to CR_DECIMAL_DIG decimal digits, then to the desired binary format). Boostrapped with no regressions on x86_64-pc-linux-gnu. gcc: * ginclude/float.h [__STDC_WANT_IEC_60559_BFP_EXT__] (CR_DECIMAL_DIG): New macro. gcc/testsuite: * gcc.dg/cr-decimal-dig-1.c: New test. From-SVN: r240249
2016-09-19Make max_align_t respect _Float128.Joseph Myers1-0/+8
The _FloatN, _FloatNx, _DecimalN and _DecimalNx types are specified in such a way that they are basic types, meaning that max_align_t must be at least as aligned as those types. On 32-bit x86, max_align_t is currently 8-byte aligned, but _Decimal128 and _Float128 are 16-byte aligned, so the alignment of max_align_t needs to increase to meet the standard requirements for these types. This patch implements such an increase. Because max_align_t needs to be usable for C++ as well as for C, <stddef.h> can't actually refer to _Float128, but needs to use __float128 (or some other notation for the type) instead. And since __float128 is architecture-specific, there isn't a preprocessor conditional that means "__float128 is available" (whereas one could test __FLT128_MANT_DIG__ to see if _Float128 is available; __SIZEOF_FLOAT128__ is available on x86 only). But I believe the only case that actually has an alignment problem here is 32-bit x86, and <stddef.h> already has lots of conditional specific to particular architectures or OSes, so this patch uses a conditional on __i386__; that also is the minimal change that ensures neither size nor alignment of max_align_t is changed in any case other than where it is necessary. If any other architectures turn out to have such an issue, it will show up as failures of one of the testcases added by this patch. Such an increase is of course an ABI change, but a reasonably safe one, in that max_align_t doesn't tend to appear in library interfaces (rather, it's something to use when writing allocators and similar code; most matches found on codesearch.debian.net look like copies of the gnulib stddef.h module rather than anything actually using max_align_t at all). max_align_t_align has a corresponding change (adding _Float128 to the types considered). (I think glibc malloc alignment should also increase to 16-byte on 32-bit x86 so it works for allocating objects of these types, which is now straightforward given the fix made for 32-bit powerpc.) Bootstrapped with no regressions on x86_64-pc-linux-gnu, and spot-tested with -m32 that the new float128-align.c test now compiles where previously it didn't. gcc: * ginclude/stddef.h (max_align_t) [__i386__]: Add __float128 element. gcc/c-family: * c-common.c (max_align_t_align): Also consider alignment of float128_type_node. gcc/testsuite: * gcc.dg/float128-align.c, gcc.dg/float128x-align.c, gcc.dg/float16-align.c, gcc.dg/float32-align.c, gcc.dg/float32x-align.c, gcc.dg/float64-align.c, gcc.dg/float64x-align.c, gcc.dg/floatn-align.h: New tests. From-SVN: r240248
2016-09-09Define TS 18661-1 type width macros in <limits.h> and <stdint.h>.Joseph Myers1-0/+101
TS 18661-1 defines <limits.h> and <stdint.h> macros for widths of standard integer types and the typedefs defined in, or whose limits are defined in, <stdint.h>. (The connection to the main floating-point subject matter of TS 18661-1 is that these are intended to be used with the fromfp functions to convert from floating point to integer types of any width in any rounding direction, though these macros may be of more general use.) This patch implements support for these macros in GCC's <limits.h> and <stdint.h>. To avoid needing to implement fixincludes for system headers where GCC wraps the system libc's <stdint.h> in hosted mode, the test for the <stdint.h> macros uses -ffreestanding (I'll add the macros to glibc's headers separately) - but as usual for new features in these headers, platforms (primarily OpenBSD) that use USER_H to avoid using GCC's headers at all will have failures until the system headers have the feature added or appropriate fixincludes are implemented. The header macros are implemented using appropriate new predefined macros, with the code avoiding defining more such macros than necessary (so one predefined macro suffices for corresponding signed and unsigned types, while no such predefined macros are needed for the exact-width types such as int8_t). Bootstrapped with no regressions on x86_64-pc-linux-gnu. gcc: * doc/cpp.texi (__SCHAR_WIDTH__, __SHRT_WIDTH__, __INT_WIDTH__) (__LONG_WIDTH__, __LONG_LONG_WIDTH__, __PTRDIFF_WIDTH__) (__SIG_ATOMIC_WIDTH__, __SIZE_WIDTH__, __WCHAR_WIDTH__) (__WINT_WIDTH__, __INT_LEAST8_WIDTH__, __INT_LEAST16_WIDTH__) (__INT_LEAST32_WIDTH__, __INT_LEAST64_WIDTH__) (__INT_FAST8_WIDTH__, __INT_FAST16_WIDTH__, __INT_FAST32_WIDTH__) (__INT_FAST64_WIDTH__, __INTPTR_WIDTH__, __INTMAX_WIDTH__): Document. * ginclude/stdint-gcc.h [__STDC_WANT_IEC_60559_BFP_EXT__]: Define width macros from TS 18661-1. * glimits.h [__STDC_WANT_IEC_60559_BFP_EXT__]: Likewise. gcc/c-family: * c-cppbuiltin.c (builtin_define_type_width): New function. (builtin_define_stdint_macros, c_cpp_builtins): Define type width macros. gcc/testsuite: * gcc.dg/limits-width-1.c, gcc.dg/stdint-width-1.c: New tests. From-SVN: r240048
2016-08-19Implement C _FloatN, _FloatNx types.Joseph Myers1-1/+182
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_* <float.h> 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 <https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01702.html> (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 <math.h>, 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 <tgmath.h> 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. From-SVN: r239625
2016-01-29Test __cplusplus instead of __GXX_EXPERIMENTAL_CXX0X__Jonathan Wakely1-1/+2
* ginclude/stdarg.h: Test __cplusplus instead of __GXX_EXPERIMENTAL_CXX0X__. From-SVN: r232977
2016-01-29PR c++/69462: Provide FLT_EVAL_METHOD and DECIMAL_DIG in float.h.Jonathan Wakely1-1/+2
gcc/ChangeLog PR c++/69462 * ginclude/float.h: Also provide FLT_EVAL_METHOD and DECIMAL_DIG for C++-11. From-SVN: r232970
2016-01-04Update copyright years.Jakub Jelinek12-12/+12
From-SVN: r232055
2015-12-16PR c/68868 - atomic_init emits an unnecessary fenceMartin Sebor1-6/+4
gcc/ChangeLog * ginclude/stdatomic.h (atomic_init): Use atomic_store instead of plain assignment. gcc/testsuite/ChangeLog * testsuite/gcc.dg/atomic/stdatomic-init.c: New test. From-SVN: r231733
2015-11-18Add out-of-line versions of some <stdatomic.h> functions (PR c/65083).Joseph Myers1-0/+7
PR c/65083 notes that some functions in <stdatomic.h> are normal functions, not generic functions, and so need to have out-of-line copies that can be called when macro expansion is suppressed (unlike the generic functions where DR#419 makes it undefined if you suppress a macro expansion). This patch adds such out-of-line definitions in libatomic for those six functions, at a new LIBATOMIC_1.2 symbol version, as trivial wrappers to the <stdatomic.h> macros, along with declarations of those functions in <stdatomic.h>. Tests are added that are based on the corresponding tests for the macros, but with parentheses around the function names to force the out-of-line functions to be used. Bootstrapped with no regressions on x86_64-pc-linux-gnu. gcc: * ginclude/stdatomic.h (atomic_thread_fence, atomic_signal_fence) (atomic_flag_test_and_set, atomic_flag_test_and_set_explicit) (atomic_flag_clear, atomic_flag_clear_explicit): Declare as functions before defining as macros. gcc/testsuite: * gcc.dg/atomic/stdatomic-fence-2.c, gcc.dg/atomic/stdatomic-flag-2.c: New tests. libatomic: * fence.c, flag.c: New files. * Makefile.am (libatomic_la_SOURCES): Add fence.c and flag.c. * Makefile.in: Regenerate. * configure.ac (libtool_VERSION): Change to 3:0:2. * configure: Regenerate. * libatomic.map (LIBATOMIC_1.2): New symbol version. From-SVN: r230578
2015-01-09unwind-arm-common.h: Revert previous commit.Andreas Tobler1-8/+0
gcc: * ginclude/unwind-arm-common.h: Revert previous commit. libstdc++-v3: * libsupc++/unwind-cxx.h: Revert previous commit. From-SVN: r219392
2015-01-09configure.ac: Don't add ${libgcj} for arm*-*-freebsd*.Andreas Tobler1-0/+8
toplevel: * configure.ac: Don't add ${libgcj} for arm*-*-freebsd*. * configure: Regenerate. gcc: * config.gcc (arm*-*-freebsd*): New configuration. * config/arm/freebsd.h: New file. * config.host: Add extra components for arm*-*-freebsd*. * config/arm/arm.h: Introduce MAX_SYNC_LIBFUNC_SIZE. * config/arm/arm.c (arm_init_libfuncs): Use MAX_SYNC_LIBFUNC_SIZE. libgcc: * config.host (arm*-*-freebsd*): Add new configuration for arm*-*-freebsd*. * config/arm/freebsd-atomic.c: New file. * config/arm/t-freebsd: Likewise. * config/arm/unwind-arm.h: Add __FreeBSD__ to the list of 'PC-relative indirect' OS's. libatomic: * configure.tgt: Exclude arm*-*-freebsd* from try_ifunc. libstdc++-v3: * configure.host: Add arm*-*-freebsd* port_specific_symbol_files. From-SVN: r219388
generated by cgit v1.1 at 2024-11-10 01:22:59 +0000