| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
Implement C2x auto, a more restricted version of the C++ feature
(closer to GNU C __auto_type in terms of what's supported).
Since the feature is very close to GNU C __auto_type, much of the
implementation can be shared. The main differences are:
* Any prior declaration of the identifier in an outer scope is
shadowed during the initializer (whereas __auto_type leaves any such
declaration visible until the initializer ends and the scope of the
__auto_type declaration itself starts). (A prior declaration in the
same scope is undefined behavior.)
* The standard feature supports braced initializers (containing a
single expression, optionally followed by a comma).
* The standard feature disallows the declaration from declaring
anything that's not an ordinary identifier (thus, the initializer
cannot declare a tag or the members of a structure or union), while
making it undefined behavior for it to declare more than one
ordinary identifier. (For the latter, while I keep the existing
error from __auto_type in the case of more than one declarator, I
don't restrict other ordinary identifiers from being declared in
inner scopes such as GNU statement expressions. I do however
disallow defining the members of an enumeration inside the
initializer (if the enum definition has no tag, that doesn't
actually violate a constraint), to avoid an enum type becoming
accessible beyond where it would have been without auto.
(Preventing new types from escaping the initializer - thus, ensuring
that anything written with auto corresponds to something that could
have been written without auto, modulo multiple evaluation of VLA
size expressions when not using auto - is a key motivation for some
restrictions on what can be declared in the initializer.)
The rule on shadowing and restrictions on other declarations in the
initializer are actually general rules for what C2x calls
underspecified declarations, a description that covers constexpr as
well as auto (in particular, this disallows a constexpr initializer
from referencing the variable being initialized). Thus, some of the
code added for those restrictions will also be of use in implementing
C2x constexpr.
auto with a type specifier remains a storage class specifier with the
same meaning as before (i.e. a redundant storage class specifier for
use at block scope).
Note that the feature is only enabled in C2x mode (-std=c2x or
-std=gnu2x); in older modes, a declaration with auto and no type is
treated as a case of implicit int (only accepted at block scope).
Since many of the restrictions on C2x auto are specified as undefined
behavior rather than constraint violations, it would be possible to
support more features from C++ auto without requiring diagnostics (but
maybe not a good idea, if it isn't clear exactly what semantics might
be given to such a feature in a future revision of C; and
-Wc23-c2y-compat should arguably warn for any such future feature
anyway). For now the features are limited to something close to
what's supported with __auto_type, with the differences as discussed
above between the two features.
Bootstrapped with no regressions for x86_64-pc-linux-gnu.
gcc/c/
* c-decl.cc (in_underspecified_init, start_underspecified_init)
(finish_underspecified_init): New.
(shadow_tag_warned, parser_xref_tag, start_struct, start_enum):
Give errors inside initializers of underspecified declarations.
(grokdeclarator): Handle (erroneous) case of C2X auto on a
parameter.
(declspecs_add_type): Handle c2x_auto_p case.
(declspecs_add_scspec): Handle auto possibly setting c2x_auto_p in
C2X mode.
(finish_declspecs): Handle c2x_auto_p.
* c-parser.cc (c_parser_declaration_or_fndef): Handle C2X auto.
* c-tree.h (C_DECL_UNDERSPECIFIED): New macro.
(struct c_declspecs): Add c2x_auto_p.
(start_underspecified_init, finish_underspecified_init): New
prototypes.
* c-typeck.cc (build_external_ref): Give error for underspecified
declaration referenced in its initializer.
gcc/testsuite/
* gcc.dg/c2x-auto-1.c, gcc.dg/c2x-auto-2.c, gcc.dg/c2x-auto-3.c,
gcc.dg/c2x-auto-4.c, gcc.dg/gnu2x-auto-1.c: New tests.
|
|
|
|
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.
|
|
Previously we've been allowing that comma only in C++ when in attribute
form (which was the reason why it has been allowed), but 5.1 allows that
even in pragma form in C/C++ (with clarifications in 5.2) and 5.2
also in Fortran (which this patch doesn't implement).
Note, for directives which take an argument (== unnamed clause),
comma is not allowed in between the directive name and the argument,
like the directive-1.c testcase shows.
2022-10-28 Jakub Jelinek <jakub@redhat.com>
gcc/c/
* c-parser.cc (c_parser_omp_all_clauses): Allow optional
comma before the first clause.
(c_parser_omp_allocate, c_parser_omp_atomic, c_parser_omp_depobj,
c_parser_omp_flush, c_parser_omp_scan_loop_body,
c_parser_omp_ordered, c_finish_omp_declare_variant,
c_parser_omp_declare_target, c_parser_omp_declare_reduction,
c_parser_omp_requires, c_parser_omp_error,
c_parser_omp_assumption_clauses): Likewise.
gcc/cp/
* parser.cc (cp_parser_omp_all_clauses): Allow optional comma
before the first clause even in pragma syntax.
(cp_parser_omp_allocate, cp_parser_omp_atomic, cp_parser_omp_depobj,
cp_parser_omp_flush, cp_parser_omp_scan_loop_body,
cp_parser_omp_ordered, cp_parser_omp_assumption_clauses,
cp_finish_omp_declare_variant, cp_parser_omp_declare_target,
cp_parser_omp_declare_reduction_exprs, cp_parser_omp_requires,
cp_parser_omp_error): Likewise.
gcc/testsuite/
* c-c++-common/gomp/directive-1.c: New test.
* c-c++-common/gomp/clauses-6.c: New test.
* c-c++-common/gomp/declare-variant-2.c (f75a): Declare.
(f75): Use f75a as variant instead of f1 and don't expect error.
* g++.dg/gomp/clause-4.C (foo): Don't expect error on comma
before first clause.
* gcc.dg/gomp/clause-2.c (foo): Likewise.
|
|
C2x adds support for enums with a fixed underlying type specified
("enum e : long long;" and similar). Implement this in the C front
end. The same representation is used for these types as in C++, with
two macros moved from cp-tree.h to c-common.h.
Such enums can have bool as the underlying type, and various C
front-end code checking for boolean types is adjusted to use a new
C_BOOLEAN_TYPE_P to handle such enums the same way as bool. (Note
that for C++ we have bug 96496 that enums with underlying type bool
don't work correctly there.)
There are various issues with the wording for such enums in the
current C2x working draft (including but not limited to wording in the
accepted paper that failed to make it into the working draft), which I
intend to raise in NB comments. I think what I've implemented and
added tests for matches the intent.
Bootstrapped with no regressions for x86_64-pc-linux-gnu.
PR c/61469
gcc/c-family/
* c-common.h (ENUM_UNDERLYING_TYPE, ENUM_FIXED_UNDERLYING_TYPE_P):
New. Moved from cp/cp-tree.h.
* c-warn.cc (warnings_for_convert_and_check): Do not consider
conversions to enum with underlying type bool to overflow.
gcc/c/
* c-convert.cc (c_convert): Handle enums with underlying boolean
type like bool.
* c-decl.cc (shadow_tag_warned): Allow shadowing declarations for
enums with enum type specifier, but give errors for storage class
specifiers, qualifiers or alignment specifiers in non-definition
declarations of such enums.
(grokdeclarator): Give error for non-definition use of type
specifier with an enum type specifier.
(parser_xref_tag): Add argument has_enum_type_specifier. Pass it
to lookup_tag and use it to set ENUM_FIXED_UNDERLYING_TYPE_P.
(xref_tag): Update call to parser_xref_tag.
(start_enum): Add argument fixed_underlying_type. Complete enum
type with a fixed underlying type given in the definition. Give
error for defining without a fixed underlying type in the
definition if one was given in a prior declaration. Do not mark
enums with fixed underlying type as packed for -fshort-enums.
Store the enum type in the_enum.
(finish_enum): Do not adjust types of values or check their range
for an enum with a fixed underlying type. Set underlying type of
enum and variants.
(build_enumerator): Check enumeration constants for enum with
fixed underlying type against that type and convert to that type.
Increment in the underlying integer type, with handling for bool.
(c_simulate_enum_decl): Update call to start_enum.
(declspecs_add_type): Set specs->enum_type_specifier_ref_p.
* c-objc-common.cc (c_get_alias_set): Use ENUM_UNDERLYING_TYPE
rather than recomputing an underlying type based on size.
* c-parser.cc (c_parser_declspecs)
(c_parser_struct_or_union_specifier, c_parser_typeof_specifier):
Set has_enum_type_specifier for type specifiers.
(c_parser_enum_specifier): Handle enum type specifiers.
(c_parser_struct_or_union_specifier): Update call to
parser_xref_tag.
(c_parser_omp_atomic): Check for boolean increment or decrement
using C_BOOLEAN_TYPE_P.
* c-tree.h (C_BOOLEAN_TYPE_P): New.
(struct c_typespec): Add has_enum_type_specifier.
(struct c_declspecs): Add enum_type_specifier_ref_p.
(struct c_enum_contents): Add enum_type.
(start_enum, parser_xref_tag): Update prototypes.
* c-typeck.cc (composite_type): Allow for enumerated types
compatible with bool.
(common_type, comptypes_internal, perform_integral_promotions):
Use ENUM_UNDERLYING_TYPE.
(parser_build_binary_op, build_unary_op, convert_for_assignment)
(c_finish_return, c_start_switch, build_binary_op): Check for
boolean types using C_BOOLEAN_TYPE_P.
gcc/cp/
* cp-tree.h (ENUM_FIXED_UNDERLYING_TYPE_P, ENUM_UNDERLYING_TYPE):
Remove. Moved to c-common.h.
gcc/testsuite/
* gcc.dg/c11-enum-4.c, gcc.dg/c11-enum-5.c, gcc.dg/c11-enum-6.c,
gcc.dg/c2x-enum-6.c, gcc.dg/c2x-enum-7.c, gcc.dg/c2x-enum-8.c,
gcc.dg/gnu2x-enum-1.c: New tests.
|
|
|
|
[PR107358]
As mentioned earlier in the C++ excess precision support mail, the following
testcase is broken with excess precision both in C and C++ (though just in C++
it was triggered in real-world code).
scalar_to_vector is called in both FEs after the excess precision promotions
(or stripping of EXCESS_PRECISION_EXPR), so we can then get invalid
diagnostics that say float vector + float involves truncation (on ia32
from long double to float).
The following patch fixes that by calling scalar_to_vector on the operands
before the excess precision promotions, let scalar_to_vector just do the
diagnostics (it does e.g. fold_for_warn so it will fold
EXCESS_PRECISION_EXPR around REAL_CST to constants etc.) but will then
do the actual conversions using the excess precision promoted operands
(so say if we have vector double + (float + float) we don't actually do
vector double + (float) ((long double) float + (long double) float)
but
vector double + (double) ((long double) float + (long double) float)
2022-10-24 Jakub Jelinek <jakub@redhat.com>
PR c++/107358
gcc/c/
* c-typeck.cc (build_binary_op): Pass operands before excess precision
promotions to scalar_to_vector call.
gcc/cp/
* typeck.cc (cp_build_binary_op): Pass operands before excess precision
promotions to scalar_to_vector call.
gcc/testsuite/
* c-c++-common/pr107358.c: New test.
* g++.dg/cpp1y/pr68180.C: Remove -fexcess-precision=fast from
dg-options.
|
|
... unless marked noreturn.
This should not get in anyone's way, but should permit the use of main()
in freestanding more easily, especially for writing test cases that
should work both in freestanding and hosted modes.
gcc/c/ChangeLog:
* c-decl.cc (finish_function): Ignore hosted when deciding
whether to implicitly return zero, but check noreturn.
* c-objc-common.cc (c_missing_noreturn_ok_p): Loosen the
requirements to just MAIN_NAME_P when hosted, or `int main'
otherwise.
gcc/cp/ChangeLog:
* cp-tree.h (DECL_MAIN_P): Move most logic, besides the hosted
check, from here...
(DECL_MAIN_ANY_P): ... to here, so that it can be reused ...
(DECL_MAIN_FREESTANDING_P): ... here, with an additional
constraint on (hosted OR return type == int)
* decl.cc (finish_function): Use DECL_MAIN_FREESTANDING_P
instead of DECL_MAIN_P, to loosen the hosted requirement, but
check noreturn, before adding implicit returns.
gcc/testsuite/ChangeLog:
* gcc.dg/noreturn-4.c: Removed.
* g++.dg/freestanding-main.C: New test.
* g++.dg/freestanding-nonint-main.C: New test.
* gcc.dg/freestanding-main.c: New test.
* gcc.dg/freestanding-nonint-main.c: New test.
|
|
|
|
The GIMPLE FE was designed to defer semantic error checking to the
GIMPLE IL verifier. But that can end up causing spurious ICEs
earlier and in fact it will report an internal error. The following
tries to improve the situation by explicitely calling into the
verifier from the parser and intructing it to not ICE but instead
zap the parsed body after an error is discovered.
PR c/107305
PR c/107306
gcc/c/
* gimple-parser.cc (c_parser_parse_gimple_body): Verify
the parsed IL and zap the body on error.
gcc/
* tree-cfg.h (verify_gimple_in_seq): Add parameter to
indicate whether to emit an ICE. Add return value.
(verify_gimple_in_cfg): Likewise.
* tree-cfg.cc (verify_gimple_in_seq): Likewise.
(verify_gimple_in_cfg): Likewise.
gcc/testsuite/
* gcc.dg/gimplefe-error-15.c: New testcase.
|
|
|
|
As noted in bug 101764, a declaration "enum tag;" is invalid in
standard C after a definition, as well as when no definition is
visible; we had a pedwarn-if-pedantic for the forward declaration
case, but were missing one for the other case. Add that missing
diagnostic (if pedantic only).
(These diagnostics will need to be appropriately conditioned when
support is added for C2x enums with fixed underlying type, since "enum
tag : type;" is OK both before and after a definition.)
Bootstrapped with no regressions for x86_64-pc-linux-gnu.
PR c/107164
gcc/c/
* c-decl.cc (shadow_tag_warned): If pedantic, diagnose "enum tag;"
with previous declaration visible.
gcc/testsuite/
* gcc.dg/c99-tag-4.c, gcc.dg/c99-tag-5.c, gcc.dg/c99-tag-6.c: New
tests.
|
|
C2x has two enhancements to enumerations: allowing enumerations whose
values do not all fit in int (similar to an existing extension), and
allowing an underlying type to be specified (as in C++). This patch
implements the first of those enhancements.
Apart from adjusting diagnostics to reflect this being a standard
feature, there are some semantics differences from the previous
extension:
* The standard feature gives all the values of such an enum the
enumerated type (while keeping type int if that can represent all
values of the enumeration), where previously GCC only gave those
values outside the range of int the enumerated type. This change
was previously requested in PR 36113; it seems unlikely that people
are depending on the detail of the previous extension that some
enumerators had different types to others depending on whether their
values could be represented as int, and this patch makes the change
to types of enumerators unconditionally (if that causes problems in
practice we could always make it conditional on C2x mode instead).
* The types *while the enumeration is being defined*, for enumerators
that can't be represented as int, are now based more directly on the
types of the expressions used, rather than a possibly different type
with the right precision constructed using c_common_type_for_size.
Again, this change is made unconditionally.
* Where overflow (or wraparound to 0, in the case of an unsigned type)
when 1 is implicitly added to determine the value of the next
enumerator was previously an error, it now results in a wider type
with the same signedness (as the while-being-defined type of the
previous enumerator) being chosen, if available.
When a type is chosen in such an overflow case, or when a type is
chosen for the underlying integer type of the enumeration, it's
possible that (unsigned) __int128 is chosen. Although C2x allows for
such types wider than intmax_t to be considered extended integer
types, we don't have various features required to do so (integer
constant suffixes; sufficient library support would also be needed to
define the associated macros for printf/scanf conversions, and
<stdint.h> typedef names would need to be defined). Thus, there are
also pedwarns for exceeding the range of intmax_t / uintmax_t, as
while in principle exceeding that range is OK, it's only OK in a
context where the relevant types meet the requirements for extended
integer types, which does not currently apply here.
Bootstrapped with no regressions for x86_64-pc-linux-gnu. Also
manually checked diagnostics for c2x-enum-3.c with -m32 to confirm the
diagnostics in that { target { ! int128 } } test are as expected.
PR c/36113
gcc/c-family/
* c-common.cc (c_common_type_for_size): Add fallback to
widest_unsigned_literal_type_node or
widest_integer_literal_type_node for precision that may not
exactly match the precision of those types.
gcc/c/
* c-decl.cc (finish_enum): If any enumerators do not fit in int,
convert all to the type of the enumeration. pedwarn if no integer
type fits all enumerators and default to
widest_integer_literal_type_node in that case. Otherwise pedwarn
for type wider than intmax_t.
(build_enumerator): pedwarn for enumerators outside the range of
uintmax_t or intmax_t, and otherwise use pedwarn_c11 for
enumerators outside the range of int. On overflow, attempt to
find a wider type that can hold the value of the next enumerator.
Do not convert value to type determined with
c_common_type_for_size.
gcc/testsuite/
* gcc.dg/c11-enum-1.c, gcc.dg/c11-enum-2.c, gcc.dg/c11-enum-3.c,
gcc.dg/c2x-enum-1.c, gcc.dg/c2x-enum-2.c, gcc.dg/c2x-enum-3.c,
gcc.dg/c2x-enum-4.c, gcc.dg/c2x-enum-5.c: New tests.
* gcc.dg/pr30260.c: Explicitly use -std=gnu11. Update expected
diagnostics.
* gcc.dg/torture/pr25183.c: Update expected diagnostics.
|
|
|
|
Here is a complete patch to add std::bfloat16_t support on
x86 (AArch64 and ARM left for later). Almost no BFmode optabs
are added by the patch, so for binops/unops it extends to SFmode
first and then truncates back to BFmode.
For {HF,SF,DF,XF,TF}mode -> BFmode conversions libgcc has implementations
of all those conversions so that we avoid double rounding, for
BFmode -> {DF,XF,TF}mode conversions to avoid growing libgcc too much
it emits BFmode -> SFmode conversion first and then converts to the even
wider mode, neither step should be imprecise.
For BFmode -> HFmode, it first emits a precise BFmode -> SFmode conversion
and then SFmode -> HFmode, because neither format is subset or superset
of the other, while SFmode is superset of both.
expr.cc then contains a -ffast-math optimization of the BF -> SF and
SF -> BF conversions if we don't optimize for space (and for the latter
if -frounding-math isn't enabled either).
For x86, perhaps truncsfbf2 optab could be defined for TARGET_AVX512BF16
but IMNSHO should FAIL if !flag_finite_math || flag_rounding_math
|| !flag_unsafe_math_optimizations, because I think the insn doesn't
raise on sNaNs, hardcodes round to nearest and flushes denormals to zero.
By default (unless x86 -fexcess-precision=16) we use float excess
precision for BFmode, so truncate only on explicit casts and assignments.
The patch introduces a single __bf16 builtin - __builtin_nansf16b,
because (__bf16) __builtin_nansf ("") will drop the sNaN into qNaN,
and uses f16b suffix instead of bf16 because there would be ambiguity on
log vs. logb - __builtin_logbf16 could be either log with bf16 suffix
or logb with f16 suffix. In other cases libstdc++ should mostly use
__builtin_*f for std::bfloat16_t overloads (we have a problem with
std::nextafter though but that one we have also for std::float16_t).
2022-10-14 Jakub Jelinek <jakub@redhat.com>
gcc/
* tree-core.h (enum tree_index): Add TI_BFLOAT16_TYPE.
* tree.h (bfloat16_type_node): Define.
* tree.cc (excess_precision_type): Promote bfloat16_type_mode
like float16_type_mode.
(build_common_tree_nodes): Initialize bfloat16_type_node if
BFmode is supported.
* expmed.h (maybe_expand_shift): Declare.
* expmed.cc (maybe_expand_shift): No longer static.
* expr.cc (convert_mode_scalar): Don't ICE on BF -> HF or HF -> BF
conversions. If there is no optab, handle BF -> {DF,XF,TF,HF}
conversions as separate BF -> SF -> {DF,XF,TF,HF} conversions, add
-ffast-math generic implementation for BF -> SF and SF -> BF
conversions.
* builtin-types.def (BT_BFLOAT16, BT_FN_BFLOAT16_CONST_STRING): New.
* builtins.def (BUILT_IN_NANSF16B): New builtin.
* fold-const-call.cc (fold_const_call): Handle CFN_BUILT_IN_NANSF16B.
* config/i386/i386.cc (classify_argument): Handle E_BCmode.
(ix86_libgcc_floating_mode_supported_p): Also return true for BFmode
for -msse2.
(ix86_mangle_type): Mangle BFmode as DF16b.
(ix86_invalid_conversion, ix86_invalid_unary_op,
ix86_invalid_binary_op): Remove.
(TARGET_INVALID_CONVERSION, TARGET_INVALID_UNARY_OP,
TARGET_INVALID_BINARY_OP): Don't redefine.
* config/i386/i386-builtins.cc (ix86_bf16_type_node): Remove.
(ix86_register_bf16_builtin_type): Use bfloat16_type_node rather than
ix86_bf16_type_node, only create it if still NULL.
* config/i386/i386-builtin-types.def (BFLOAT16): Likewise.
* config/i386/i386.md (cbranchbf4, cstorebf4): New expanders.
gcc/c-family/
* c-cppbuiltin.cc (c_cpp_builtins): If bfloat16_type_node,
predefine __BFLT16_*__ macros and for C++23 also
__STDCPP_BFLOAT16_T__. Predefine bfloat16_type_node related
macros for -fbuilding-libgcc.
* c-lex.cc (interpret_float): Handle CPP_N_BFLOAT16.
gcc/c/
* c-typeck.cc (convert_arguments): Don't promote __bf16 to
double.
gcc/cp/
* cp-tree.h (extended_float_type_p): Return true for
bfloat16_type_node.
* typeck.cc (cp_compare_floating_point_conversion_ranks): Set
extended{1,2} if mv{1,2} is bfloat16_type_node. Adjust comment.
gcc/testsuite/
* lib/target-supports.exp (check_effective_target_bfloat16,
check_effective_target_bfloat16_runtime, add_options_for_bfloat16):
New.
* gcc.dg/torture/bfloat16-basic.c: New test.
* gcc.dg/torture/bfloat16-builtin.c: New test.
* gcc.dg/torture/bfloat16-builtin-issignaling-1.c: New test.
* gcc.dg/torture/bfloat16-complex.c: New test.
* gcc.dg/torture/builtin-issignaling-1.c: Allow to be includable
from bfloat16-builtin-issignaling-1.c.
* gcc.dg/torture/floatn-basic.h: Allow to be includable from
bfloat16-basic.c.
* gcc.target/i386/vect-bfloat16-typecheck_2.c: Adjust expected
diagnostics.
* gcc.target/i386/sse2-bfloat16-scalar-typecheck.c: Likewise.
* gcc.target/i386/vect-bfloat16-typecheck_1.c: Likewise.
* g++.target/i386/bfloat_cpp_typecheck.C: Likewise.
libcpp/
* include/cpplib.h (CPP_N_BFLOAT16): Define.
* expr.cc (interpret_float_suffix): Handle bf16 and BF16 suffixes for
C++.
libgcc/
* config/i386/t-softfp (softfp_extensions): Add bfsf.
(softfp_truncations): Add tfbf xfbf dfbf sfbf hfbf.
(CFLAGS-extendbfsf2.c, CFLAGS-truncsfbf2.c, CFLAGS-truncdfbf2.c,
CFLAGS-truncxfbf2.c, CFLAGS-trunctfbf2.c, CFLAGS-trunchfbf2.c): Add
-msse2.
* config/i386/libgcc-glibc.ver (GCC_13.0.0): Export
__extendbfsf2 and __trunc{s,d,x,t,h}fbf2.
* config/i386/sfp-machine.h (_FP_NANSIGN_B): Define.
* config/i386/64/sfp-machine.h (_FP_NANFRAC_B): Define.
* config/i386/32/sfp-machine.h (_FP_NANFRAC_B): Define.
* soft-fp/brain.h: New file.
* soft-fp/truncsfbf2.c: New file.
* soft-fp/truncdfbf2.c: New file.
* soft-fp/truncxfbf2.c: New file.
* soft-fp/trunctfbf2.c: New file.
* soft-fp/trunchfbf2.c: New file.
* soft-fp/truncbfhf2.c: New file.
* soft-fp/extendbfsf2.c: New file.
libiberty/
* cp-demangle.h (D_BUILTIN_TYPE_COUNT): Increment.
* cp-demangle.c (cplus_demangle_builtin_types): Add std::bfloat16_t
entry.
(cplus_demangle_type): Demangle DF16b.
* testsuite/demangle-expected (_Z3xxxDF16b): New test.
|
|
Implement the C2x feature of storage class specifiers in compound
literals. Such storage class specifiers (static, register or
thread_local; also constexpr, but we don't yet have C2x constexpr
support implemented) can be used before the type name (not mixed with
type specifiers, unlike in declarations) and have the same semantics
and constraints as for declarations of named objects. Also allow GNU
__thread to be used, given that thread_local can be.
Bootstrapped with no regressions for x86_64-pc-linux-gnu.
gcc/c/
* c-decl.cc (build_compound_literal): Add parameter scspecs.
Handle storage class specifiers.
* c-parser.cc (c_token_starts_compound_literal)
(c_parser_compound_literal_scspecs): New.
(c_parser_postfix_expression_after_paren_type): Add parameter
scspecs. Call pedwarn_c11 for use of storage class specifiers.
Update call to build_compound_literal.
(c_parser_cast_expression, c_parser_sizeof_expression)
(c_parser_alignof_expression): Handle storage class specifiers for
compound literals. Update calls to
c_parser_postfix_expression_after_paren_type.
(c_parser_postfix_expression): Update syntax comment.
* c-tree.h (build_compound_literal): Update prototype.
* c-typeck.cc (c_mark_addressable): Diagnose taking address of
register compound literal.
gcc/testsuite/
* gcc.dg/c11-complit-1.c, gcc.dg/c11-complit-2.c,
gcc.dg/c11-complit-3.c, gcc.dg/c2x-complit-2.c,
gcc.dg/c2x-complit-3.c, gcc.dg/c2x-complit-4.c,
gcc.dg/c2x-complit-5.c, gcc.dg/c2x-complit-6.c,
gcc.dg/c2x-complit-7.c, gcc.dg/c90-complit-2.c,
gcc.dg/gnu2x-complit-1.c, gcc.dg/gnu2x-complit-2.c: New tests.
|
|
|
|
Add the following new option -fstrict-flex-arrays[=n] and a corresponding
attribute strict_flex_array to GCC:
'-fstrict-flex-arrays'
Control when to treat the trailing array of a structure as a flexible array
member for the purpose of accessing the elements of such an array.
The positive form is equivalent to '-fstrict-flex-arrays=3', which is the
strictest. A trailing array is treated as a flexible array member only when
it declared as a flexible array member per C99 standard onwards.
The negative form is equivalent to '-fstrict-flex-arrays=0', which is the
least strict. All trailing arrays of structures are treated as flexible
array members.
'-fstrict-flex-arrays=LEVEL'
Control when to treat the trailing array of a structure as a flexible array
member for the purpose of accessing the elements of such an array. The value
of LEVEL controls the level of strictness
The possible values of LEVEL are the same as for the
'strict_flex_array' attribute (*note Variable Attributes::).
You can control this behavior for a specific trailing array field
of a structure by using the variable attribute 'strict_flex_array'
attribute (*note Variable Attributes::).
'strict_flex_array (LEVEL)'
The 'strict_flex_array' attribute should be attached to the trailing
array field of a structure. It controls when to treat the trailing array
field of a structure as a flexible array member for the purposes of accessing
the elements of such an array. LEVEL must be an integer betwen 0 to 3.
LEVEL=0 is the least strict level, all trailing arrays of
structures are treated as flexible array members. LEVEL=3 is the
strictest level, only when the trailing array is declared as a
flexible array member per C99 standard onwards ('[]'), it is
treated as a flexible array member.
There are two more levels in between 0 and 3, which are provided to
support older codes that use GCC zero-length array extension
('[0]') or one-element array as flexible array members('[1]'): When
LEVEL is 1, the trailing array is treated as a flexible array member
when it is declared as either '[]', '[0]', or '[1]'; When
LEVEL is 2, the trailing array is treated as a flexible array member
when it is declared as either '[]', or '[0]'.
This attribute can be used with or without the
'-fstrict-flex-arrays'. When both the attribute and the option
present at the same time, the level of the strictness for the
specific trailing array field is determined by the attribute.
gcc/c-family/ChangeLog:
* c-attribs.cc (handle_strict_flex_array_attribute): New function.
(c_common_attribute_table): New item for strict_flex_array.
* c.opt: (fstrict-flex-arrays): New option.
(fstrict-flex-arrays=): New option.
gcc/c/ChangeLog:
* c-decl.cc (flexible_array_member_type_p): New function.
(one_element_array_type_p): Likewise.
(zero_length_array_type_p): Likewise.
(add_flexible_array_elts_to_size): Call new utility
routine flexible_array_member_type_p.
(is_flexible_array_member_p): New function.
(finish_struct): Set the new DECL_NOT_FLEXARRAY flag.
gcc/cp/ChangeLog:
* module.cc (trees_out::core_bools): Stream out new bit
decl_not_flexarray.
(trees_in::core_bools): Stream in new bit decl_not_flexarray.
gcc/ChangeLog:
* doc/extend.texi: Document strict_flex_array attribute.
* doc/invoke.texi: Document -fstrict-flex-arrays[=n] option.
* print-tree.cc (print_node): Print new bit decl_not_flexarray.
* tree-core.h (struct tree_decl_common): New bit field
decl_not_flexarray.
* tree-streamer-in.cc (unpack_ts_decl_common_value_fields): Stream
in new bit decl_not_flexarray.
* tree-streamer-out.cc (pack_ts_decl_common_value_fields): Stream
out new bit decl_not_flexarray.
* tree.cc (array_at_struct_end_p): Update it with the new bit field
decl_not_flexarray.
* tree.h (DECL_NOT_FLEXARRAY): New flag.
gcc/testsuite/ChangeLog:
* g++.dg/strict-flex-array-1.C: New test.
* gcc.dg/strict-flex-array-1.c: New test.
|
|
|
|
C2x adds typeof as a standard feature. In general this follows
existing GNU C semantics very closely, but there are various ways in
which the implementation involves more than simply enabling the
keyword for C2x:
* As well as typeof, there is a typeof_unqual variant, which removes
all qualifiers and _Atomic from the resulting type (whereas typeof
preserves qualifiers and _Atomic on qualified or atomic (lvalue or
type name) operands).
* The typeof keyword is disabled by -fno-asm, so enabling it for C2x
needs to be implemented in a way that preserves the disabling by
-fno-asm for older standard versions (which having -fno-asm having
no effect on it in C2x mode). This is done via adding a new D_EXT11
mask (which is also where the C++ front-end change comes from, to
handle D_EXT11 appropriately there for -fno-asm and
-fno-gnu-keywords).
* GNU typeof treats the noreturn property of a function (as specified
in standard C with _Noreturn or [[noreturn]]) as being part of the
type of a pointer to function, but it is not part of the type in
standard terms. Thus a special case is needed in the typeof
implementation, just like in the _Generic implementation, to avoid
treating it as a type for standard typeof. It seems plausible this
is being used when copying the type of one object to another using
typeof, so the existing semantics are preserved for __typeof__, and
for typeof in pre-C2x modes, while typeof for C2x or later has the
standard semantics.
* It turns out that, even after Martin Uecker's changes in this area,
there were still cases where rvalues could wrongly have a qualified
or atomic type in GCC. This applied to ++ and -- increment and
decrement expressions, and also to calls to functions returning an
atomic type. (For the latter, the working draft doesn't actually
explicitly exclude the function call expression having an atomic
type, but given all the changes that have gone into C17 and C2x to
avoid rvalues ever having qualified types, and given that
lvalue-to-rvalue conversion removes both qualifiers and _Atomic, it
seems unlikely that this (or casts, where GCC already removes
_Atomic) is actually intended as a route to allow an
_Atomic-qualified rvalue; I've noted this to raise as an NB comment
on the CD ballot.)
Bootstrapped with no regressions for x86_64-pc-linux-gnu. OK to
commit (C+
gcc/
* doc/invoke.texi (-fno-asm): Update description of effects on
typeof keyword.
gcc/c-family/
* c-common.cc (c_common_reswords): Mark typeof as D_EXT11. Add
typeof_unqual.
* c-common.h (enum rid): Add RID_TYPEOF_UNQUAL.
(D_EXT11): New macro. Values of subsequent macros updated.
gcc/c/
* c-parser.cc (c_parse_init): Add D_EXT11 to mask if flag_no_asm
and not C2x.
(c_keyword_starts_typename, c_token_starts_declspecs)
(c_parser_declspecs, c_parser_objc_selector): Handle
RID_TYPEOF_UNQUAL.
(c_parser_typeof_specifier): Handle RID_TYPEOF_UNQUAL.
Distinguish typeof for C2x from __typeof__ for all standard
versions and typeof before C2x.
* c-typeck.cc (build_function_call_vec): Use unqualified version
of non-void return type.
(build_unary_op): Use unqualified type for increment and
decrement.
gcc/cp/
* lex.cc (init_reswords): Handle D_EXT11.
gcc/testsuite/
* gcc.dg/c11-typeof-1.c, gcc.dg/c2x-typeof-1.c,
gcc.dg/c2x-typeof-2.c, gcc.dg/c2x-typeof-3.c,
gcc.dg/gnu11-typeof-1.c, gcc.dg/gnu11-typeof-2.c,
gcc.dg/gnu2x-typeof-1.c: New tests.
|
|
Now that [[assume (cond)]] support is in, this simple patch makes
#pragma omp assume holds(cond)
use it.
2022-10-06 Jakub Jelinek <jakub@redhat.com>
* c-parser.cc (c_parser_omp_assumption_clauses): Emit IFN_ASSUME
call for holds clause on assume construct.
* parser.cc (cp_parser_omp_assumption_clauses): Emit IFN_ASSUME
call for holds clause on assume construct.
* c-c++-common/gomp/assume-4.c: New test.
|
|
The following patch implements C++23 P1774R8 - Portable assumptions
paper, by introducing support for [[assume (cond)]]; attribute for C++.
In addition to that the patch adds [[gnu::assume (cond)]]; and
__attribute__((assume (cond))); support to both C and C++.
As described in C++23, the attribute argument is conditional-expression
rather than the usual assignment-expression for attribute arguments,
the condition is contextually converted to bool (for C truthvalue conversion
is done on it) and is never evaluated at runtime.
For C++ constant expression evaluation, I only check the simplest conditions
for undefined behavior, because otherwise I'd need to undo changes to
*ctx->global which happened during the evaluation (but I believe the spec
allows that and we can further improve later).
The patch uses a new internal function, .ASSUME, to hold the condition
in the FEs. At gimplification time, if the condition is simple/without
side-effects, it is gimplified as if (cond) ; else __builtin_unreachable ();
and otherwise for now dropped on the floor. The intent is to incrementally
outline the conditions into separate artificial functions and use
.ASSUME further to tell the ranger and perhaps other optimization passes
about the assumptions, as detailed in the PR.
When implementing it, I found that assume entry hasn't been added to
https://eel.is/c++draft/cpp.cond#6
Jonathan said he'll file a NB comment about it, this patch assumes it
has been added into the table as 202207L when the paper has been voted in.
With the attributes for both C/C++, I'd say we don't need to add
__builtin_assume with similar purpose, especially when __builtin_assume
in LLVM is just weird. It is strange for side-effects in function call's
argument not to be evaluated, and LLVM in that case (annoyingly) warns
and ignores the side-effects (but doesn't do then anything with it),
if there are no side-effects, it will work like our
if (!cond) __builtin_unreachable ();
2022-10-06 Jakub Jelinek <jakub@redhat.com>
PR c++/106654
gcc/
* internal-fn.def (ASSUME): New internal function.
* internal-fn.h (expand_ASSUME): Declare.
* internal-fn.cc (expand_ASSUME): Define.
* gimplify.cc (gimplify_call_expr): Gimplify IFN_ASSUME.
* fold-const.h (simple_condition_p): Declare.
* fold-const.cc (simple_operand_p_2): Rename to ...
(simple_condition_p): ... this. Remove forward declaration.
No longer static. Adjust function comment and fix a typo in it.
Adjust recursive call.
(simple_operand_p): Adjust function comment.
(fold_truth_andor): Adjust simple_operand_p_2 callers to call
simple_condition_p.
* doc/extend.texi: Document assume attribute. Move fallthrough
attribute example to its section.
gcc/c-family/
* c-attribs.cc (handle_assume_attribute): New function.
(c_common_attribute_table): Add entry for assume attribute.
* c-lex.cc (c_common_has_attribute): Handle
__have_cpp_attribute (assume).
gcc/c/
* c-parser.cc (handle_assume_attribute): New function.
(c_parser_declaration_or_fndef): Handle assume attribute.
(c_parser_attribute_arguments): Add assume_attr argument,
if true, parse first argument as conditional expression.
(c_parser_gnu_attribute, c_parser_std_attribute): Adjust
c_parser_attribute_arguments callers.
(c_parser_statement_after_labels) <case RID_ATTRIBUTE>: Handle
assume attribute.
gcc/cp/
* cp-tree.h (process_stmt_assume_attribute): Implement C++23
P1774R8 - Portable assumptions. Declare.
(diagnose_failing_condition): Declare.
(find_failing_clause): Likewise.
* parser.cc (assume_attr): New enumerator.
(cp_parser_parenthesized_expression_list): Handle assume_attr.
Remove identifier variable, for id_attr push the identifier into
expression_list right away instead of inserting it before all the
others at the end.
(cp_parser_conditional_expression): New function.
(cp_parser_constant_expression): Use it.
(cp_parser_statement): Handle assume attribute.
(cp_parser_expression_statement): Likewise.
(cp_parser_gnu_attribute_list): Use assume_attr for assume
attribute.
(cp_parser_std_attribute): Likewise. Handle standard assume
attribute like gnu::assume.
* cp-gimplify.cc (process_stmt_assume_attribute): New function.
* constexpr.cc: Include fold-const.h.
(find_failing_clause_r, find_failing_clause): New functions,
moved from semantics.cc with ctx argument added and if non-NULL,
call cxx_eval_constant_expression rather than fold_non_dependent_expr.
(cxx_eval_internal_function): Handle IFN_ASSUME.
(potential_constant_expression_1): Likewise.
* pt.cc (tsubst_copy_and_build): Likewise.
* semantics.cc (diagnose_failing_condition): New function.
(find_failing_clause_r, find_failing_clause): Moved to constexpr.cc.
(finish_static_assert): Use it. Add auto_diagnostic_group.
gcc/testsuite/
* gcc.dg/attr-assume-1.c: New test.
* gcc.dg/attr-assume-2.c: New test.
* gcc.dg/attr-assume-3.c: New test.
* g++.dg/cpp2a/feat-cxx2a.C: Add colon to C++20 features
comment, add C++20 attributes comment and move C++20
new features after the attributes before them.
* g++.dg/cpp23/feat-cxx2b.C: Likewise. Test
__has_cpp_attribute(assume).
* g++.dg/cpp23/attr-assume1.C: New test.
* g++.dg/cpp23/attr-assume2.C: New test.
* g++.dg/cpp23/attr-assume3.C: New test.
* g++.dg/cpp23/attr-assume4.C: New test.
|
|
|
|
The following patch adds support for the begin declare target construct,
which is another spelling for declare target construct without clauses
(where it needs paired end declare target), but unlike that one accepts
clauses.
This is an OpenMP 5.1 feature, implemented with 5.2 clarification because
in 5.1 we had a restriction in the declare target chapter shared by
declare target and begin declare target that if there are any clauses
specified at least one of them needs to be to or link. But that
was of course meant just for declare target and not begin declare target,
because begin declare target doesn't even allow to/link/enter clauses.
In addition to that, the patch also makes device_type clause duplication
an error (as stated in 5.1) and similarly makes declare target with
just device_type clause an error rather than warning.
What this patch doesn't do is:
1) OpenMP 5.1 also added an indirect clause, we don't support that
neither on declare target nor begin declare target
and I couldn't find it in our features pages (neither libgomp.texi
nor web)
2) I think device_type(nohost)/device_type(host) support can't work for
variables (in 5.0 it only talked about procedures so this could be
also thought as 5.1 feature that we should just add to the list
and implement)
3) I don't see any use of the "omp declare target nohost" attribute, so
I'm not sure if device_type(nohost) works at all
2022-10-04 Jakub Jelinek <jakub@redhat.com>
gcc/c-family/
* c-omp.cc (c_omp_directives): Uncomment begin declare target
entry.
gcc/c/
* c-lang.h (struct c_omp_declare_target_attr): New type.
(current_omp_declare_target_attribute): Change type from
int to vec<c_omp_declare_target_attr, va_gc> *.
* c-parser.cc (c_parser_translation_unit): Adjust for that change.
If last pushed directive was begin declare target, use different
wording and simplify format strings for easier translations.
(c_parser_omp_clause_device_type): Uncomment
check_no_duplicate_clause call.
(c_parser_omp_declare_target): Adjust for the
current_omp_declare_target_attribute type change, push { -1 }.
Use error_at rather than warning_at for declare target with
only device_type clauses.
(OMP_BEGIN_DECLARE_TARGET_CLAUSE_MASK): Define.
(c_parser_omp_begin): Add begin declare target support.
(c_parser_omp_end): Adjust for the
current_omp_declare_target_attribute type change, adjust
diagnostics wording and simplify format strings for easier
translations.
* c-decl.cc (current_omp_declare_target_attribute): Change type from
int to vec<c_omp_declare_target_attr, va_gc> *.
(c_decl_attributes): Adjust for the
current_omp_declare_target_attribute type change. If device_type
was present on begin declare target, add "omp declare target host"
and/or "omp declare target nohost" attributes.
gcc/cp/
* cp-tree.h (struct omp_declare_target_attr): Rename to ...
(cp_omp_declare_target_attr): ... this. Add device_type member.
(omp_begin_assumes_data): Rename to ...
(cp_omp_begin_assumes_data): ... this.
(struct saved_scope): Change types of omp_declare_target_attribute
and omp_begin_assumes.
* parser.cc (cp_parser_omp_clause_device_type): Uncomment
check_no_duplicate_clause call.
(cp_parser_omp_all_clauses): Fix up pasto, c_name for OMP_CLAUSE_LINK
should be "link" rather than "to".
(cp_parser_omp_declare_target): Adjust for omp_declare_target_attr
to cp_omp_declare_target_attr changes, push -1 as device_type. Use
error_at rather than warning_at for declare target with only
device_type clauses.
(OMP_BEGIN_DECLARE_TARGET_CLAUSE_MASK): Define.
(cp_parser_omp_begin): Add begin declare target support. Adjust
for omp_begin_assumes_data to cp_omp_begin_assumes_data change.
(cp_parser_omp_end): Adjust for the
omp_declare_target_attr to cp_omp_declare_target_attr and
omp_begin_assumes_data to cp_omp_begin_assumes_data type changes,
adjust diagnostics wording and simplify format strings for easier
translations.
* semantics.cc (finish_translation_unit): Likewise.
* decl2.cc (cplus_decl_attributes): If device_type was present on
begin declare target, add "omp declare target host" and/or
"omp declare target nohost" attributes.
gcc/testsuite/
* c-c++-common/gomp/declare-target-4.c: Move tests that are now
rejected into declare-target-7.c.
* c-c++-common/gomp/declare-target-6.c: Adjust expected diagnostics.
* c-c++-common/gomp/declare-target-7.c: New test.
* c-c++-common/gomp/begin-declare-target-1.c: New test.
* c-c++-common/gomp/begin-declare-target-2.c: New test.
* c-c++-common/gomp/begin-declare-target-3.c: New test.
* c-c++-common/gomp/begin-declare-target-4.c: New test.
* g++.dg/gomp/attrs-9.C: Add begin declare target tests.
* g++.dg/gomp/attrs-18.C: New test.
libgomp/
* libgomp.texi (Support begin/end declare target syntax in C/C++):
Mark as implemented.
|
|
|
|
C2x adds a standard [[noreturn]] attribute (which can also be spelt
[[_Noreturn]] for use with <stdnoreturn.h>), so allowing non-returning
functions to be declared in a manner compatible with C++; the
_Noreturn function specifier remains available but is marked
obsolescent.
Implement this attribute. It's more restricted than GNU
__attribute__ ((noreturn)) - that allows function pointers but using
the standard attribute on a function pointer is a constraint
violation. Thus, the attribute gets its own handler that checks for a
FUNCTION_DECL before calling the handler for the GNU attribute. Tests
for the attribute are based on those for C11 _Noreturn and for other
C2x attributes.
Bootstrapped with no regressions for x86_64-pc-linux-gnu.
gcc/c-family/
* c-lex.cc (c_common_has_attribute): Handle noreturn attribute for
C.
gcc/c/
* c-decl.cc (handle_std_noreturn_attribute): New function.
(std_attribute_table): Add _Noreturn and noreturn.
gcc/testsuite/
* gcc.dg/c2x-attr-noreturn-1.c, gcc.dg/c2x-attr-noreturn-2.c,
gcc.dg/c2x-attr-noreturn-3.c: New tests.
* gcc.dg/c2x-has-c-attribute-2.c: Also test __has_c_attribute for
noreturn attribute.
|
|
|
|
The following patch implements OpenMP 5.1
#pragma omp assume
#pragma omp assumes
and
#pragma omp begin assumes
#pragma omp end assumes
directive support for C and C++. Currently it doesn't remember
anything from the assumption clauses for later, so is mainly
to support the directives and diagnose errors in their use.
If the recently posted C++23 [[assume (cond)]]; support makes it
in, the intent is that this can be easily adjusted at least for
the #pragma omp assume directive with holds clause(s) to use
the same infrastructure. Now, C++23 portable assumptions are slightly
different from OpenMP 5.1 assumptions' holds clause in that C++23
assumption holds just where it appears, while OpenMP 5.1 assumptions
hold everywhere in the scope of the directive. For assumes
directive which can appear at file or namespace scope it is the whole
TU and everything that functions from there call at runtime, for
begin assumes/end assumes pair all the functions in between those
directives and everything they call and for assume directive the
associated (currently structured) block. I have no idea how to
represents such holds to be usable for optimizers, except to
make
#pragma omp assume holds (cond)
block;
expand essentially to
[[assume (cond)]];
block;
or
[[assume (cond)]];
block;
[[assume (cond)]];
for now. Except for holds clause, the other assumptions are
OpenMP related, I'd say we should brainstorm where it would be
useful to optimize based on such information (I guess e.g. in target
regions it easily could) and only when we come up with something
like that think about how to propagate the assumptions to the optimizers.
2022-09-27 Jakub Jelinek <jakub@redhat.com>
gcc/c-family/
* c-pragma.h (enum pragma_kind): Add PRAGMA_OMP_ASSUME,
PRAGMA_OMP_ASSUMES and PRAGMA_OMP_BEGIN. Rename
PRAGMA_OMP_END_DECLARE_TARGET to PRAGMA_OMP_END.
* c-pragma.cc (omp_pragmas): Add assumes and begin.
For end rename PRAGMA_OMP_END_DECLARE_TARGET to PRAGMA_OMP_END.
(omp_pragmas_simd): Add assume.
* c-common.h (c_omp_directives): Declare.
* c-omp.cc (omp_directives): Rename to ...
(c_omp_directives): ... this. No longer static. Uncomment
assume, assumes, begin assumes and end assumes entries.
In end declare target entry rename PRAGMA_OMP_END_DECLARE_TARGET
to PRAGMA_OMP_END.
(c_omp_categorize_directive): Adjust for omp_directives to
c_omp_directives renaming.
gcc/c/
* c-lang.h (current_omp_begin_assumes): Declare.
* c-parser.cc: Include bitmap.h.
(c_parser_omp_end_declare_target): Rename to ...
(c_parser_omp_end): ... this. Handle also end assumes.
(c_parser_omp_begin, c_parser_omp_assumption_clauses,
c_parser_omp_assumes, c_parser_omp_assume): New functions.
(c_parser_translation_unit): Also diagnose #pragma omp begin assumes
without corresponding #pragma omp end assumes.
(c_parser_pragma): Use %s in may only be used at file scope
diagnostics to decrease number of translatable messages. Handle
PRAGMA_OMP_BEGIN and PRAGMA_OMP_ASSUMES. Handle PRAGMA_OMP_END
rather than PRAGMA_OMP_END_DECLARE_TARGET and call c_parser_omp_end
for it rather than c_parser_omp_end_declare_target.
(c_parser_omp_construct): Handle PRAGMA_OMP_ASSUME.
* c-decl.cc (current_omp_begin_assumes): Define.
gcc/cp/
* cp-tree.h (struct omp_begin_assumes_data): New type.
(struct saved_scope): Add omp_begin_assumes member.
* parser.cc: Include bitmap.h.
(cp_parser_omp_assumption_clauses, cp_parser_omp_assume,
cp_parser_omp_assumes, cp_parser_omp_begin): New functions.
(cp_parser_omp_end_declare_target): Rename to ...
(cp_parser_omp_end): ... this. Handle also end assumes.
(cp_parser_omp_construct): Handle PRAGMA_OMP_ASSUME.
(cp_parser_pragma): Handle PRAGMA_OMP_ASSUME, PRAGMA_OMP_ASSUMES
and PRAGMA_OMP_BEGIN. Handle PRAGMA_OMP_END rather than
PRAGMA_OMP_END_DECLARE_TARGET and call cp_parser_omp_end
for it rather than cp_parser_omp_end_declare_target.
* pt.cc (apply_late_template_attributes): Also temporarily clear
omp_begin_assumes.
* semantics.cc (finish_translation_unit): Also diagnose
#pragma omp begin assumes without corresponding
#pragma omp end assumes.
gcc/testsuite/
* c-c++-common/gomp/assume-1.c: New test.
* c-c++-common/gomp/assume-2.c: New test.
* c-c++-common/gomp/assume-3.c: New test.
* c-c++-common/gomp/assumes-1.c: New test.
* c-c++-common/gomp/assumes-2.c: New test.
* c-c++-common/gomp/assumes-3.c: New test.
* c-c++-common/gomp/assumes-4.c: New test.
* c-c++-common/gomp/begin-assumes-1.c: New test.
* c-c++-common/gomp/begin-assumes-2.c: New test.
* c-c++-common/gomp/begin-assumes-3.c: New test.
* c-c++-common/gomp/begin-assumes-4.c: New test.
* c-c++-common/gomp/declare-target-6.c: New test.
* g++.dg/gomp/attrs-1.C (bar): Add n1 and n2 arguments, add
tests for assume directive.
* g++.dg/gomp/attrs-2.C (bar): Likewise.
* g++.dg/gomp/attrs-9.C: Add n1 and n2 variables, add tests for
begin assumes directive.
* g++.dg/gomp/attrs-15.C: New test.
* g++.dg/gomp/attrs-16.C: New test.
* g++.dg/gomp/attrs-17.C: New test.
|
|
|
|
This patch changes c_tree_equal to work more like cp_tree_equal, be
more strict in what it accepts. The ICE on the first testcase was
due to INTEGER_CST wi::wide (t1) == wi::wide (t2) comparison which
ICEs if the two constants have different precision, but as the second
testcase shows, being too lenient in it can also lead to miscompilation
of valid OpenMP programs where we think certain expression is the same
even when it isn't and can be guaranteed at runtime to represent different
memory location. So, the patch looks through only NON_LVALUE_EXPRs
and for constants as well as casts requires that the types match before
actually comparing the constant values or recursing on the cast operands.
2022-09-24 Jakub Jelinek <jakub@redhat.com>
PR c/106981
gcc/c/
* c-typeck.cc (c_tree_equal): Only strip NON_LVALUE_EXPRs at the
start. For CONSTANT_CLASS_P or CASE_CONVERT: return false if t1 and
t2 have different types.
gcc/testsuite/
* c-c++-common/gomp/pr106981.c: New test.
libgomp/
* testsuite/libgomp.c-c++-common/pr106981.c: New test.
|
|
|
|
I added c_expr::m_decimal in r13-2386-gbedfca647a9e9c1a as part of the
implementation of -Wxor-used-as-pow, but I missed various places where
the field needed to be initialized.
Fixed thusly.
gcc/c-family/ChangeLog:
PR c/106830
* c-warn.cc (check_for_xor_used_as_pow): Don't try checking
values that don't fit in uhwi.
gcc/c/ChangeLog:
PR c/106830
* c-parser.cc (c_parser_initelt): Initialize m_decimal.
(c_parser_cast_expression): Likewise.
(c_parser_alignof_expression): Likewise.
(c_parser_postfix_expression_after_paren_type): Likewise.
(c_parser_postfix_expression_after_primary): Likewise.
(c_parser_expression): Likewise.
(c_parser_omp_variable_list): Likewise.
(c_parser_transaction_expression): Likewise.
* c-tree.h (c_expr::set_error): Likewise.
* c-typeck.cc (c_expr_sizeof_expr): Likewise.
(parser_build_unary_op): Likewise.
(parser_build_binary_op): Likewise.
(digest_init): Likewise.
(pop_init_level): Likewise.
* gimple-parser.cc (c_parser_gimple_call_internal): Likewise.
gcc/testsuite/ChangeLog:
PR c/106830
* gcc.dg/Wxor-used-as-pow-pr106830.c: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
|
|
|
|
A trivial fix for maybe_warn_for_null_address where we print an
inform note without first checking the return value of a warning
call.
PR c/106947
gcc/c/ChangeLog:
* c-typeck.cc (maybe_warn_for_null_address): Don't emit stray
notes.
gcc/testsuite/ChangeLog:
* c-c++-common/Waddress-7.c: New test.
|
|
|
|
All frontends replicate this, so move it.
gcc/
* tree.cc (build_common_tree_nodes): Initialize void_list_node
here.
gcc/ada/
* gcc-interface/trans.cc (gigi): Do not initialize void_list_node.
gcc/c-family/
* c-common.h (build_void_list_node): Remove.
* c-common.cc (c_common_nodes_and_builtins): Do not initialize
void_list_node.
gcc/c/
* c-decl.cc (build_void_list_node): Remove.
gcc/cp/
* decl.cc (cxx_init_decl_processing): Inline last
build_void_list_node call.
(build_void_list_node): Remove.
gcc/d/
* d-builtins.cc (d_build_c_type_nodes): Do not initialize
void_list_node.
gcc/fortran/
* f95-lang.cc (gfc_init_decl_processing): Do not initialize
void_list_node.
gcc/go/
* go-lang.cc (go_langhook_init): Do not initialize
void_list_node.
gcc/jit/
* dummy-frontend.cc (jit_langhook_init): Do not initialize
void_list_node.
gcc/lto/
* lto-lang.cc (lto_build_c_type_nodes): Do not initialize
void_list_node.
|
|
|
|
This patch adjusts OpenMP/OpenACC clause list handling in a couple of
places, in preparation for the following mapping-clause expansion rework
patch. Firstly mapping groups are removed as a whole in the C and C++
front-ends when an error is detected, which avoids leaving "badly-formed"
mapping clause groups in the list.
Secondly, reindexing of the omp_mapping_group hashmap (during
omp_build_struct_sibling_lists) has been reimplemented, fixing some
tricky corner-cases where mapping groups are removed from a list at the
same time as it is being reordered.
Thirdly, code to check if a different clause on the same directive maps
the whole of a struct that we have a component mapping for (for example)
has been outlined, removing a bit of code duplication.
2022-09-13 Julian Brown <julian@codesourcery.com>
gcc/
* gimplify.cc (omp_group_last): Allow GOMP_MAP_ATTACH_DETACH after
GOMP_MAP_STRUCT (for reindexing).
(omp_gather_mapping_groups): Reimplement using...
(omp_gather_mapping_groups_1): This new function. Stop processing at
GATHER_SENTINEL.
(omp_group_base): Allow GOMP_MAP_TO_PSET without any following node.
(omp_index_mapping_groups): Reimplement using...
(omp_index_mapping_groups_1): This new function. Handle
REINDEX_SENTINEL.
(omp_reindex_mapping_groups, omp_mapped_by_containing_struct): New
functions.
(omp_tsort_mapping_groups_1): Adjust handling of base group being the
same as current group. Use omp_mapped_by_containing_struct.
(omp_build_struct_sibling_lists): Use omp_mapped_by_containing_struct
and omp_reindex_mapping_groups. Robustify group deletion for reordered
lists.
(gimplify_scan_omp_clauses): Update calls to
omp_build_struct_sibling_lists.
gcc/c/
* c-typeck.cc (c_finish_omp_clauses): Remove whole mapping node group
on error.
gcc/cp/
* semantics.cc (finish_omp_clauses): Likewise.
|
|
|
|
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.
|
|
|
|
omp_cur_iteration - 1
For normal sink vectors, we just check that the token is CPP_NUMBER and with
INTEGER_CST value, while for omp_cur_iteration I was additionally requiring
integer_type_node type (so only 1, 001, 0x0001 but not 1L or 1ULL etc.).
I think we need to clarify what we actually should allow in the standard, until
then it is better to be consistent.
2022-09-06 Jakub Jelinek <jakub@redhat.com>
gcc/c/
* c-parser.cc (c_parser_omp_clause_doacross_sink): Don't verify val
in omp_cur_iteration - 1 has integer_type_node type.
gcc/cp/
* parser.cc (cp_parser_omp_clause_doacross_sink): Don't verify val
in omp_cur_iteration - 1 has integer_type_node type.
gcc/testsuite/
* c-c++-common/gomp/doacross-6.c (corge): Don't expect an error here.
Add a few further tests.
|
|
|
|
The following patch implements part of the OpenMP 5.2 changes related
to ordered loops and with the assumed resolution of
https://github.com/OpenMP/spec/issues/3302 issues.
The changes are:
1) the depend clause on stand-alone ordered constructs has been renamed
to doacross (because depend clause has different syntax on other
constructs) with some syntax changes below, depend clause is deprecated
(we'll deprecate stuff on the GCC side only when we have everything else
from 5.2 implemented)
depend(source) -> doacross(source:) or doacross(source:omp_cur_iteration)
depend(sink:vec) -> doacross(sink:vec) (where vec has the same syntax
as before)
2) in 5.1 and before it has been significant whether ordered clause has or
doesn't have an argument, if it didn't, only block-associated ordered
could appear in the body, if it did, only stand-alone ordered could appear
in the body, all loops had to be perfectly nested, no associated
range-based for loops, no linear clause on work-sharing loop and ordered
clause with an argument wasn't allowed on composite for simd.
In 5.2, whether ordered clause has or doesn't have an argument is
insignificant (except for bugs in the standard, #3302 mentions those),
if the argument is missing, it is simply treated as equal to collapse
argument (if any, otherwise 1). The implementation better should be able
to differentiate between ordered and doacross loops at compile time
which previously was through the absence or presence of the argument,
now it is done through looking at the body of the construct lexically
and looking for stand-alone ordered constructs. If there are any,
it is to be handled as doacross loop, otherwise it is ordered loop
(but in that case ordered argument if present must be equal to collapse
argument - 5.2 says instead it must be one, but that is clearly wrong
and mentioned in #3302) - stand-alone ordered constructs must appear
lexically in the body (and had to before as well). For the restrictions
mentioned above, the for simd restriction is gone (stand-alone ordered
can't appear in simd construct, so that is enough), and the other rules
are expected to be changed into something related to presence of
stand-alone ordered constructs in the body
3) 5.2 allows a new syntax, doacross(sink:omp_cur_iteration-1), which
means wait for previous iteration in the iteration space of all the
associated loops
The following patch implements that, except that we sorry for now
on the doacross(sink:omp_cur_iteration-1) syntax during omp expansion
because library side isn't done yet for it. It doesn't implement it for
the Fortran FE either.
Incrementally, I'd like to change the way we differentiate between
stand-alone and block-associated ordered constructs, because the current
way of looking for presence of doacross clause doesn't work well if those
clauses are removed because they had been invalid (wrong syntax or
unknown variables in it etc.) and of course implement
doacross(sink:omp_cur_iteration-1).
2022-09-03 Jakub Jelinek <jakub@redhat.com>
gcc/
* tree-core.h (enum omp_clause_code): Add OMP_CLAUSE_DOACROSS.
(enum omp_clause_depend_kind): Remove OMP_CLAUSE_DEPEND_SOURCE
and OMP_CLAUSE_DEPEND_SINK, add OMP_CLAUSE_DEPEND_INVALID.
(enum omp_clause_doacross_kind): New type.
(struct tree_omp_clause): Add subcode.doacross_kind member.
* tree.h (OMP_CLAUSE_DEPEND_SINK_NEGATIVE): Remove.
(OMP_CLAUSE_DOACROSS_KIND): Define.
(OMP_CLAUSE_DOACROSS_SINK_NEGATIVE): Define.
(OMP_CLAUSE_DOACROSS_DEPEND): Define.
(OMP_CLAUSE_ORDERED_DOACROSS): Define.
* tree.cc (omp_clause_num_ops, omp_clause_code_name): Add
OMP_CLAUSE_DOACROSS entries.
* tree-nested.cc (convert_nonlocal_omp_clauses,
convert_local_omp_clauses): Handle OMP_CLAUSE_DOACROSS.
* tree-pretty-print.cc (dump_omp_clause): Don't handle
OMP_CLAUSE_DEPEND_SOURCE and OMP_CLAUSE_DEPEND_SINK. Handle
OMP_CLAUSE_DOACROSS.
* gimplify.cc (gimplify_omp_depend): Don't handle
OMP_CLAUSE_DEPEND_SOURCE and OMP_CLAUSE_DEPEND_SINK.
(gimplify_scan_omp_clauses): Likewise. Handle OMP_CLAUSE_DOACROSS.
(gimplify_adjust_omp_clauses): Handle OMP_CLAUSE_DOACROSS.
(find_standalone_omp_ordered): New function.
(gimplify_omp_for): When OMP_CLAUSE_ORDERED is present, search
body for OMP_ORDERED with OMP_CLAUSE_DOACROSS and if found,
set OMP_CLAUSE_ORDERED_DOACROSS.
(gimplify_omp_ordered): Don't handle OMP_CLAUSE_DEPEND_SINK or
OMP_CLAUSE_DEPEND_SOURCE, instead check OMP_CLAUSE_DOACROSS, adjust
diagnostics that presence or absence of ordered clause parameter
is irrelevant. Handle doacross(sink:omp_cur_iteration-1). Use
actual user name of the clause - doacross or depend - in diagnostics.
* omp-general.cc (omp_extract_for_data): Don't set fd->ordered
if !OMP_CLAUSE_ORDERED_DOACROSS (t). If
OMP_CLAUSE_ORDERED_DOACROSS (t) but !OMP_CLAUSE_ORDERED_EXPR (t),
set fd->ordered to -1 and set it after the loop in that case to
fd->collapse.
* omp-low.cc (check_omp_nesting_restrictions): Don't handle
OMP_CLAUSE_DEPEND_SOURCE nor OMP_CLAUSE_DEPEND_SINK, instead check
OMP_CLAUSE_DOACROSS. Use actual user name of the clause - doacross
or depend - in diagnostics. Diagnose mixing of stand-alone and
block associated ordered constructs binding to the same loop.
(lower_omp_ordered_clauses): Don't handle OMP_CLAUSE_DEPEND_SINK,
instead handle OMP_CLAUSE_DOACROSS.
(lower_omp_ordered): Look for OMP_CLAUSE_DOACROSS instead of
OMP_CLAUSE_DEPEND.
(lower_depend_clauses): Don't handle OMP_CLAUSE_DEPEND_SOURCE and
OMP_CLAUSE_DEPEND_SINK.
* omp-expand.cc (expand_omp_ordered_sink): Emit a sorry for
doacross(sink:omp_cur_iteration-1).
(expand_omp_ordered_source_sink): Use
OMP_CLAUSE_DOACROSS_SINK_NEGATIVE instead of
OMP_CLAUSE_DEPEND_SINK_NEGATIVE. Use actual user name of the clause
- doacross or depend - in diagnostics.
(expand_omp): Look for OMP_CLAUSE_DOACROSS clause instead of
OMP_CLAUSE_DEPEND.
(build_omp_regions_1): Likewise.
(omp_make_gimple_edges): Likewise.
* lto-streamer-out.cc (hash_tree): Handle OMP_CLAUSE_DOACROSS.
* tree-streamer-in.cc (unpack_ts_omp_clause_value_fields): Likewise.
* tree-streamer-out.cc (pack_ts_omp_clause_value_fields): Likewise.
gcc/c-family/
* c-pragma.h (enum pragma_omp_clause): Add PRAGMA_OMP_CLAUSE_DOACROSS.
* c-omp.cc (c_finish_omp_depobj): Check also for OMP_CLAUSE_DOACROSS
clause and diagnose it. Don't handle OMP_CLAUSE_DEPEND_SOURCE and
OMP_CLAUSE_DEPEND_SINK. Assert kind is not OMP_CLAUSE_DEPEND_INVALID.
gcc/c/
* c-parser.cc (c_parser_omp_clause_name): Handle doacross.
(c_parser_omp_clause_depend_sink): Renamed to ...
(c_parser_omp_clause_doacross_sink): ... this. Add depend_p argument.
Handle parsing of doacross(sink:omp_cur_iteration-1). Use
OMP_CLAUSE_DOACROSS_SINK_NEGATIVE instead of
OMP_CLAUSE_DEPEND_SINK_NEGATIVE, build OMP_CLAUSE_DOACROSS instead
of OMP_CLAUSE_DEPEND and set OMP_CLAUSE_DOACROSS_DEPEND flag on it.
(c_parser_omp_clause_depend): Use OMP_CLAUSE_DOACROSS_SINK and
OMP_CLAUSE_DOACROSS_SOURCE instead of OMP_CLAUSE_DEPEND_SINK and
OMP_CLAUSE_DEPEND_SOURCE, build OMP_CLAUSE_DOACROSS for depend(source)
and set OMP_CLAUSE_DOACROSS_DEPEND on it.
(c_parser_omp_clause_doacross): New function.
(c_parser_omp_all_clauses): Handle PRAGMA_OMP_CLAUSE_DOACROSS.
(c_parser_omp_depobj): Use OMP_CLAUSE_DEPEND_INVALID instead of
OMP_CLAUSE_DEPEND_SOURCE.
(c_parser_omp_for_loop): Don't diagnose here linear clause together
with ordered with argument.
(c_parser_omp_simd): Don't diagnose ordered clause with argument on
for simd.
(OMP_ORDERED_DEPEND_CLAUSE_MASK): Add PRAGMA_OMP_CLAUSE_DOACROSS.
(c_parser_omp_ordered): Handle also doacross and adjust for it
diagnostic wording.
* c-typeck.cc (c_finish_omp_clauses): Handle OMP_CLAUSE_DOACROSS.
Don't handle OMP_CLAUSE_DEPEND_SOURCE and OMP_CLAUSE_DEPEND_SINK.
gcc/cp/
* parser.cc (cp_parser_omp_clause_name): Handle doacross.
(cp_parser_omp_clause_depend_sink): Renamed to ...
(cp_parser_omp_clause_doacross_sink): ... this. Add depend_p
argument. Handle parsing of doacross(sink:omp_cur_iteration-1). Use
OMP_CLAUSE_DOACROSS_SINK_NEGATIVE instead of
OMP_CLAUSE_DEPEND_SINK_NEGATIVE, build OMP_CLAUSE_DOACROSS instead
of OMP_CLAUSE_DEPEND and set OMP_CLAUSE_DOACROSS_DEPEND flag on it.
(cp_parser_omp_clause_depend): Use OMP_CLAUSE_DOACROSS_SINK and
OMP_CLAUSE_DOACROSS_SOURCE instead of OMP_CLAUSE_DEPEND_SINK and
OMP_CLAUSE_DEPEND_SOURCE, build OMP_CLAUSE_DOACROSS for depend(source)
and set OMP_CLAUSE_DOACROSS_DEPEND on it.
(cp_parser_omp_clause_doacross): New function.
(cp_parser_omp_all_clauses): Handle PRAGMA_OMP_CLAUSE_DOACROSS.
(cp_parser_omp_depobj): Use OMP_CLAUSE_DEPEND_INVALID instead of
OMP_CLAUSE_DEPEND_SOURCE.
(cp_parser_omp_for_loop): Don't diagnose here linear clause together
with ordered with argument.
(cp_parser_omp_simd): Don't diagnose ordered clause with argument on
for simd.
(OMP_ORDERED_DEPEND_CLAUSE_MASK): Add PRAGMA_OMP_CLAUSE_DOACROSS.
(cp_parser_omp_ordered): Handle also doacross and adjust for it
diagnostic wording.
* pt.cc (tsubst_omp_clause_decl): Use
OMP_CLAUSE_DOACROSS_SINK_NEGATIVE instead of
OMP_CLAUSE_DEPEND_SINK_NEGATIVE.
(tsubst_omp_clauses): Handle OMP_CLAUSE_DOACROSS.
(tsubst_expr): Use OMP_CLAUSE_DEPEND_INVALID instead of
OMP_CLAUSE_DEPEND_SOURCE.
* semantics.cc (cp_finish_omp_clause_depend_sink): Rename to ...
(cp_finish_omp_clause_doacross_sink): ... this.
(finish_omp_clauses): Handle OMP_CLAUSE_DOACROSS. Don't handle
OMP_CLAUSE_DEPEND_SOURCE and OMP_CLAUSE_DEPEND_SINK.
gcc/fortran/
* trans-openmp.cc (gfc_trans_omp_clauses): Use
OMP_CLAUSE_DOACROSS_SINK_NEGATIVE instead of
OMP_CLAUSE_DEPEND_SINK_NEGATIVE, build OMP_CLAUSE_DOACROSS
clause instead of OMP_CLAUSE_DEPEND and set OMP_CLAUSE_DOACROSS_DEPEND
on it.
gcc/testsuite/
* c-c++-common/gomp/doacross-2.c: Adjust expected diagnostics.
* c-c++-common/gomp/doacross-5.c: New test.
* c-c++-common/gomp/doacross-6.c: New test.
* c-c++-common/gomp/nesting-2.c: Adjust expected diagnostics.
* c-c++-common/gomp/ordered-3.c: Likewise.
* c-c++-common/gomp/sink-3.c: Likewise.
* gfortran.dg/gomp/nesting-2.f90: Likewise.
|
|
|
|
PR c/90885 notes various places in real-world code where people have
written C/C++ code that uses ^ (exclusive or) where presumbably they
meant exponentiation.
For example
https://codesearch.isocpp.org/cgi-bin/cgi_ppsearch?q=2%5E32&search=Search
currently finds 11 places using "2^32", and all of them appear to be
places where the user means 2 to the power of 32, rather than 2
exclusive-orred with 32 (which is 34).
This patch adds a new -Wxor-used-as-pow warning to the C and C++
frontends to complain about ^ when the left-hand side is the decimal
constant 2 or the decimal constant 10.
This is the same name as the corresponding clang warning:
https://clang.llvm.org/docs/DiagnosticsReference.html#wxor-used-as-pow
As per the clang warning, the warning suggests converting the left-hand
side to a hexadecimal constant if you really mean xor, which suppresses
the warning (though this patch implements a fix-it hint for that, whereas
the clang implementation only has a fix-it hint for the initial
suggestion of exponentiation).
I initially tried implementing this without checking for decimals, but
this version had lots of false positives. Checking for decimals
requires extending the lexer to capture whether or not a CPP_NUMBER
token was decimal. I added a new DECIMAL_INT flag to cpplib.h for this.
Unfortunately, c_token and cp_tokens both have only an unsigned char for
their flags (as captured by c_lex_with_flags), whereas this would add
the 12th flag to cpp_tokens. Of the first 8 flags, all but BOL are used
in the C or C++ frontends, but BOL is not, so I moved that to a higher
position, using its old value for the new DECIMAL_INT flag, so that it
is representable within an unsigned char.
Example output:
demo.c:5:13: warning: result of '2^8' is 10; did you mean '1 << 8' (256)? [-Wxor-used-as-pow]
5 | int t2_8 = 2^8;
| ^
| --
| 1<<
demo.c:5:12: note: you can silence this warning by using a hexadecimal constant (0x2 rather than 2)
5 | int t2_8 = 2^8;
| ^
| 0x2
demo.c:21:15: warning: result of '10^6' is 12; did you mean '1e6'? [-Wxor-used-as-pow]
21 | int t10_6 = 10^6;
| ^
| ---
| 1e
demo.c:21:13: note: you can silence this warning by using a hexadecimal constant (0xa rather than 10)
21 | int t10_6 = 10^6;
| ^~
| 0xa
gcc/c-family/ChangeLog:
PR c/90885
* c-common.h (check_for_xor_used_as_pow): New decl.
* c-lex.cc (c_lex_with_flags): Add DECIMAL_INT to flags as appropriate.
* c-warn.cc (check_for_xor_used_as_pow): New.
* c.opt (Wxor-used-as-pow): New.
gcc/c/ChangeLog:
PR c/90885
* c-parser.cc (c_parser_string_literal): Clear ret.m_decimal.
(c_parser_expr_no_commas): Likewise.
(c_parser_conditional_expression): Likewise.
(c_parser_binary_expression): Clear m_decimal when popping the
stack.
(c_parser_unary_expression): Clear ret.m_decimal.
(c_parser_has_attribute_expression): Likewise for result.
(c_parser_predefined_identifier): Likewise for expr.
(c_parser_postfix_expression): Likewise for expr.
Set expr.m_decimal when handling a CPP_NUMBER that was a decimal
token.
* c-tree.h (c_expr::m_decimal): New bitfield.
* c-typeck.cc (parser_build_binary_op): Clear result.m_decimal.
(parser_build_binary_op): Call check_for_xor_used_as_pow.
gcc/cp/ChangeLog:
PR c/90885
* cp-tree.h (class cp_expr): Add bitfield m_decimal. Clear it in
existing ctors. Add ctor that allows specifying its value.
(cp_expr::decimal_p): New accessor.
* parser.cc (cp_parser_expression_stack_entry::flags): New field.
(cp_parser_primary_expression): Set m_decimal of cp_expr when
handling numbers.
(cp_parser_binary_expression): Extract flags from token when
populating stack. Call check_for_xor_used_as_pow.
gcc/ChangeLog:
PR c/90885
* doc/invoke.texi (Warning Options): Add -Wxor-used-as-pow.
gcc/testsuite/ChangeLog:
PR c/90885
* c-c++-common/Wxor-used-as-pow-1.c: New test.
* c-c++-common/Wxor-used-as-pow-fixits.c: New test.
* g++.dg/parse/expr3.C: Convert 2 to 0x2 to suppress
-Wxor-used-as-pow.
* g++.dg/warn/Wparentheses-10.C: Likewise.
* g++.dg/warn/Wparentheses-18.C: Likewise.
* g++.dg/warn/Wparentheses-19.C: Likewise.
* g++.dg/warn/Wparentheses-9.C: Likewise.
* g++.dg/warn/Wxor-used-as-pow-named-op.C: New test.
* gcc.dg/Wparentheses-6.c: Convert 2 to 0x2 to suppress
-Wxor-used-as-pow.
* gcc.dg/Wparentheses-7.c: Likewise.
* gcc.dg/precedence-1.c: Likewise.
libcpp/ChangeLog:
PR c/90885
* include/cpplib.h (BOL): Move macro to 1 << 12 since it is
not used by C/C++'s unsigned char token flags.
(DECIMAL_INT): New, using 1 << 6, so that it is visible as
part of C/C++'s 8 bits of token flags.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
|
|
|
|
C2x has completely removed unprototyped functions, so that () now
means the same as (void) in both function declarations and
definitions, where previously that change had been made for
definitions only. Implement this accordingly.
This is a change where GNU/Linux distribution builders might wish to
try builds with a -std=gnu2x default to start early on getting old
code fixed that still has () declarations for functions taking
arguments, in advance of GCC moving to -std=gnu2x as default maybe in
GCC 14 or 15; I don't know how much such code is likely to be in
current use.
Bootstrapped with no regressions for x86_64-pc-linux-gnu.
gcc/c/
* c-decl.cc (grokparms): Handle () in a function declaration the
same as (void) for C2X.
gcc/testsuite/
* gcc.dg/c11-unproto-3.c, gcc.dg/c2x-unproto-3.c,
gcc.dg/c2x-unproto-4.c: New tests.
* gcc.dg/c2x-old-style-definition-6.c, gcc.dg/c2x-unproto-1.c,
gcc.dg/c2x-unproto-2.c: Update for removal of unprototyped
functions.
|
|
|
