aboutsummaryrefslogtreecommitdiff
path: root/gcc/c
AgeCommit message (Collapse)AuthorFilesLines
2023-05-01Daily bump.GCC Administrator1-0/+11
2023-04-30Improve error message for excess elements in array initializer from {"a"}Andrew Pinski1-1/+1
So char arrays are not the only type that be initialized from {"a"}. We can have wchar_t (L"") and char16_t (u"") types too. So let's print out the type of the array instead of just saying char. Note in the testsuite I used regex . to match '[' and ']' as I could not figure out how many '\' I needed. OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions. gcc/c/ChangeLog: * c-typeck.cc (process_init_element): Print out array type for excessive elements. gcc/testsuite/ChangeLog: * gcc.dg/init-bad-1.c: Update error message. * gcc.dg/init-bad-2.c: Likewise. * gcc.dg/init-bad-3.c: Likewise. * gcc.dg/init-excess-3.c: Likewise. * gcc.dg/pr61096-1.c: Likewise.
2023-04-30Fix C/107926: Wrong error message when initializing char arrayAndrew Pinski1-5/+10
The problem here is the code which handles {"a"} is supposed to handle the case where the is something after the string but it only handles the case where there is another string so we go down the other path and error out saying "excess elements in struct initializer" even though this was a character array. To fix this, we need to move the ckeck if the initializer is a string after the check for array and initializer. OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions. Thanks, Adnrew Pinski gcc/c/ChangeLog: PR c/107926 * c-typeck.cc (process_init_element): Move the check for string cst until after the error message. gcc/testsuite/ChangeLog: PR c/107926 * gcc.dg/init-excess-3.c: New test.
2023-04-29Daily bump.GCC Administrator1-0/+4
2023-04-28Fix autoprofiledbootstrap buildEugene Rozenfeld1-3/+29
1. Fix gcov version 2. Merge perf data collected when compiling the compiler and runtime libraries 3. Fix documentation typo Tested on x86_64-pc-linux-gnu. ChangeLog: * Makefile.in: Define PROFILE_MERGER * Makefile.tpl: Define PROFILE_MERGER gcc/c/ChangeLog: * Make-lang.in: Merge perf data collected when compiling cc1 and runtime libraries gcc/cp/ChangeLog: * Make-lang.in: Merge perf data collected when compiling cc1plus and runtime libraries gcc/lto/ChangeLog: * Make-lang.in: Merge perf data collected when compiling lto1 and runtime libraries gcc/ChangeLog: * doc/install.texi: Fix documentation typo
2023-04-28Daily bump.GCC Administrator1-0/+14
2023-04-27c: Fix up error-recovery on non-empty VLA initializers [PR109409]Jakub Jelinek1-4/+7
On the following testcase we ICE, because after we emit the variable-sized object may not be initialized except with an empty initializer error we don't really reset the initializer to error_mark_node and then at -Wformat checking time we ICE on seeing STRING_CST initializer for a VLA. The following patch just arranges for error_mark_node to be returned after the error diagnostics. 2023-04-27 Jakub Jelinek <jakub@redhat.com> PR c/109409 * c-parser.cc (c_parser_initializer): Move diagnostics about initialization of variable sized object with non-empty initializer after c_parser_expr_no_commas call and ret.set_error (); after it. * gcc.dg/pr109409.c: New test.
2023-04-27c: Fix up error-recovery on functions initialized as variables [PR109412]Jakub Jelinek1-0/+5
The change to allow empty initializers in C broke error-recovery on the following testcase. We are emitting function %qD is initialized like a variable error early; if the initializer is non-empty, we just emit another error that the initializer is invalid. Previously if it was empty, we'd emit another error that scalar is being initialized by empty initializer (not really correct), but now we instead just try to build_zero_cst for the FUNCTION_TYPE and ICE on it. The following patch just emits the same diagnostics for the empty initializers as we emit for the non-empty ones. 2023-04-27 Jakub Jelinek <jakub@redhat.com> PR c/107682 PR c/109412 * c-typeck.cc (pop_init_level): If constructor_type is FUNCTION_TYPE, reject empty initializer as invalid. * gcc.dg/pr109412.c: New test.
2023-04-27Daily bump.GCC Administrator1-0/+5
2023-04-26More last_stmt removalRichard Biener1-2/+1
This adjusts more users of last_stmt where it is clear that debug stmt skipping is unnecessary. In most cases this also allowed significant code simplification. gcc/c/ * gimple-parser.cc (c_parser_parse_gimple_body): Avoid last_stmt. gcc/ * gimple-range-path.cc (path_range_query::compute_outgoing_relations): Avoid last_stmt. * ipa-pure-const.cc (pass_nothrow::execute): Likewise. * predict.cc (apply_return_prediction): Likewise. * sese.cc (set_ifsese_condition): Likewise. Simplify. * tree-cfg.cc (assert_unreachable_fallthru_edge_p): Avoid last_stmt. (make_edges_bb): Likewise. (make_cond_expr_edges): Likewise. (end_recording_case_labels): Likewise. (make_gimple_asm_edges): Likewise. (cleanup_dead_labels): Likewise. (group_case_labels): Likewise. (gimple_can_merge_blocks_p): Likewise. (gimple_merge_blocks): Likewise. (find_taken_edge): Likewise. Also handle empty fallthru blocks. (gimple_duplicate_sese_tail): Avoid last_stmt. (find_loop_dist_alias): Likewise. (gimple_block_ends_with_condjump_p): Likewise. (gimple_purge_dead_eh_edges): Likewise. (gimple_purge_dead_abnormal_call_edges): Likewise. (pass_warn_function_return::execute): Likewise. (execute_fixup_cfg): Likewise. * tree-eh.cc (redirect_eh_edge_1): Likewise. (pass_lower_resx::execute): Likewise. (pass_lower_eh_dispatch::execute): Likewise. (cleanup_empty_eh): Likewise. * tree-if-conv.cc (if_convertible_bb_p): Likewise. (predicate_bbs): Likewise. (ifcvt_split_critical_edges): Likewise. * tree-loop-distribution.cc (create_edge_for_control_dependence): Likewise. (loop_distribution::transform_reduction_loop): Likewise. * tree-parloops.cc (transform_to_exit_first_loop_alt): Likewise. (try_transform_to_exit_first_loop_alt): Likewise. (transform_to_exit_first_loop): Likewise. (create_parallel_loop): Likewise. * tree-scalar-evolution.cc (get_loop_exit_condition): Likewise. * tree-ssa-dce.cc (mark_last_stmt_necessary): Likewise. (eliminate_unnecessary_stmts): Likewise. * tree-ssa-dom.cc (dom_opt_dom_walker::set_global_ranges_from_unreachable_edges): Likewise. * tree-ssa-ifcombine.cc (ifcombine_ifandif): Likewise. (pass_tree_ifcombine::execute): Likewise. * tree-ssa-loop-ch.cc (entry_loop_condition_is_static): Likewise. (should_duplicate_loop_header_p): Likewise. * tree-ssa-loop-ivcanon.cc (create_canonical_iv): Likewise. (tree_estimate_loop_size): Likewise. (try_unroll_loop_completely): Likewise. * tree-ssa-loop-ivopts.cc (tree_ssa_iv_optimize_loop): Likewise. * tree-ssa-loop-manip.cc (ip_normal_pos): Likewise. (canonicalize_loop_ivs): Likewise. * tree-ssa-loop-niter.cc (determine_value_range): Likewise. (bound_difference): Likewise. (number_of_iterations_popcount): Likewise. (number_of_iterations_cltz): Likewise. (number_of_iterations_cltz_complement): Likewise. (simplify_using_initial_conditions): Likewise. (number_of_iterations_exit_assumptions): Likewise. (loop_niter_by_eval): Likewise. (estimate_numbers_of_iterations): Likewise.
2023-04-26Daily bump.GCC Administrator1-0/+5
2023-04-25'omp scan' struct block seq update for OpenMP 5.xTobias Burnus1-2/+20
While OpenMP 5.0 required a single structured block before and after the 'omp scan' directive, OpenMP 5.1 changed this to a 'structured block sequence, denoting 2 or more executable statements in OpenMP 5.1 (whoops!) and zero or more in OpenMP 5.2. This commit updates C/C++ to accept zero statements (but till requires the '{' ... '}' for the final-loop-body) and updates Fortran to accept zero or more than one statements. If there is no preceeding or succeeding executable statement, a warning is shown. gcc/c/ChangeLog: * c-parser.cc (c_parser_omp_scan_loop_body): Handle zero exec statements before/after 'omp scan'. gcc/cp/ChangeLog: * parser.cc (cp_parser_omp_scan_loop_body): Handle zero exec statements before/after 'omp scan'. gcc/fortran/ChangeLog: * openmp.cc (gfc_resolve_omp_do_blocks): Handle zero or more than one exec statements before/after 'omp scan'. * trans-openmp.cc (gfc_trans_omp_do): Likewise. libgomp/ChangeLog: * testsuite/libgomp.c-c++-common/scan-1.c: New test. * testsuite/libgomp.c/scan-23.c: New test. * testsuite/libgomp.fortran/scan-2.f90: New test. gcc/testsuite/ChangeLog: * g++.dg/gomp/attrs-7.C: Update dg-error/dg-warning. * gfortran.dg/gomp/loop-2.f90: Likewise. * gfortran.dg/gomp/reduction5.f90: Likewise. * gfortran.dg/gomp/reduction6.f90: Likewise. * gfortran.dg/gomp/scan-1.f90: Likewise. * gfortran.dg/gomp/taskloop-2.f90: Likewise. * c-c++-common/gomp/scan-6.c: New test. * gfortran.dg/gomp/scan-8.f90: New test.
2023-04-21Daily bump.GCC Administrator1-0/+6
2023-04-20c: Avoid -Wenum-int-mismatch warning for redeclaration of builtin ↵Jakub Jelinek1-1/+8
acc_on_device [PR107041] The new -Wenum-int-mismatch warning triggers with -Wsystem-headers in <openacc.h>, for obvious reasons the builtin acc_on_device uses int type argument rather than enum which isn't defined yet when the builtin is created, while the OpenACC spec requires it to have acc_device_t enum argument. The header makes sure it has int underlying type by using negative and __INT_MAX__ enumerators. I've tried to make the builtin typegeneric or just varargs, but that changes behavior e.g. when one calls it with some C++ class which has cast operator to acc_device_t, so the following patch instead disables the warning for this builtin. 2023-04-20 Jakub Jelinek <jakub@redhat.com> PR c/107041 * c-decl.cc (diagnose_mismatched_decls): Avoid -Wenum-int-mismatch warning on acc_on_device declaration. * gcc.dg/goacc/pr107041.c: New test.
2023-03-29Daily bump.GCC Administrator1-0/+6
2023-03-28Don't emit -Wxor-used-as-pow on macro expansions [PR107002]David Malcolm1-1/+1
PR c/107002 reports an assertion failure from deep inside the diagnostic_shows_locus when attempting to print fix-it hints relating to -Wxor-used-as-pow. The case involves macro expansions with -ftrack-macro-expansion=0. It doesn't seem to make much sense to emit this warning for macro expansions, so this patch updates the warning not to (which seems to also be clang's behavior). The patch also adds some bulletproofing to diagnostic-show-locus.cc to be more robust against such invalid fix-it hints. Doing so fixes the ICE. gcc/c-family/ChangeLog: PR c/107002 * c-common.h (check_for_xor_used_as_pow): Add "rhs_loc" param. * c-warn.cc (check_for_xor_used_as_pow): Add "rhs_loc" param. Reject cases where involving macro expansions. gcc/c/ChangeLog: PR c/107002 * c-typeck.cc (parser_build_binary_op): Update for new param of check_for_xor_used_as_pow. gcc/cp/ChangeLog: PR c/107002 * parser.cc (cp_parser_binary_expression): Update for new param of check_for_xor_used_as_pow. gcc/ChangeLog: PR c/107002 * diagnostic-show-locus.cc (column_range::column_range): Factor out assertion conditional into... (column_range::valid_p): ...this new function. (line_corrections::add_hint): Don't attempt to consolidate hints if it would lead to invalid column_range instances. gcc/testsuite/ChangeLog: PR c/107002 * c-c++-common/Wxor-used-as-pow-1.c: Add macro test. * c-c++-common/Wxor-used-as-pow-pr107002-0.c: New test. * c-c++-common/Wxor-used-as-pow-pr107002-1.c: New test. * c-c++-common/Wxor-used-as-pow-pr107002-2.c: New test. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2023-03-11Daily bump.GCC Administrator1-0/+6
2023-03-10c, c++, cgraphunit: Prevent duplicated -Wunused-value warnings [PR108079]Jakub Jelinek1-1/+4
On the following testcase, we warn with -Wunused-value twice, once in the FEs and later on cgraphunit again with slightly different wording. The following patch fixes that by registering a warning suppression in the FEs when we warn and not warning in cgraphunit anymore if that happened. 2023-03-10 Jakub Jelinek <jakub@redhat.com> PR c/108079 gcc/ * cgraphunit.cc (check_global_declaration): Don't warn for unused variables which have OPT_Wunused_variable warning suppressed. gcc/c/ * c-decl.cc (pop_scope): Suppress OPT_Wunused_variable warning after diagnosing it. gcc/cp/ * decl.cc (poplevel): Suppress OPT_Wunused_variable warning after diagnosing it. gcc/testsuite/ * c-c++-common/Wunused-var-18.c: New test.
2023-03-01Daily bump.GCC Administrator1-0/+7
2023-02-28ubsan: Honor -fstrict-flex-arrays= in -fsanitize=bounds [PR108894]Jakub Jelinek1-30/+1
While this isn't really a regression, the -fstrict-flex-arrays* option is new in GCC 13 and so I think we should make -fsanitize=bounds play with it well from the beginning. The current behavior is that -fsanitize=bounds considers all trailing arrays as flexible member-like arrays and both -fsanitize=bounds and -fsanitize=bounds-strict because of a bug don't even instrument [0] arrays at all, not as trailing nor when followed by other members. I think -fstrict-flex-arrays* options can be considered as language mode changing options, by default flexible member-like arrays are handled like flexible arrays, but that option can change the set of the arrays which are treated like that. So, -fsanitize=bounds should change with that on what is considered acceptable and what isn't. While -fsanitize=bounds-strict should reject them all always to continue previous behavior. The following patch implements that. To support [0] array instrumentation, I had to change the meaning of the bounds argument to .UBSAN_BOUNDS, previously it was the TYPE_MAX_VALUE of the domain unless ignore_off_by_one (used for taking address of the array element rather than accessing it; in that case 1 is added to the bound argument) and the later lowered checks were if (index > bound) report_failure (). The problem with that is that for [0] arrays where (at least for C++) the max value is all ones, for accesses that condition will be never true; for addresses of elements it was working (in C++) correctly before. This patch changes it to add 1 + ignore_off_by_one, so -1 becomes 0 or 1 for &array_ref and changing the lowering to be if (index >= bound) report_failure (). Furthermore, as C represents the [0] arrays with NULL TYPE_MAX_VALUE, I treated those like the C++ ones. 2023-02-28 Jakub Jelinek <jakub@redhat.com> PR sanitizer/108894 gcc/ * ubsan.cc (ubsan_expand_bounds_ifn): Emit index >= bound comparison rather than index > bound. * gimple-fold.cc (gimple_fold_call): Use tree_int_cst_lt rather than tree_int_cst_le for IFN_UBSAN_BOUND comparison. * doc/invoke.texi (-fsanitize=bounds): Document that whether flexible array member-like arrays are instrumented or not depends on -fstrict-flex-arrays* options of strict_flex_array attributes. (-fsanitize=bounds-strict): Document that flexible array members are not instrumented. gcc/c-family/ * c-common.h (c_strict_flex_array_level_of): Declare. * c-common.cc (c_strict_flex_array_level_of): New function, moved and renamed from c-decl.cc's strict_flex_array_level_of. * c-ubsan.cc (ubsan_instrument_bounds): Fix comment typo. For C check c_strict_flex_array_level_of whether a trailing array should be treated as flexible member like. Handle C [0] arrays. Add 1 + index_off_by_one rather than index_off_by_one to bounds and use tree_int_cst_lt rather than tree_int_cst_le for idx vs. bounds comparison. gcc/c/ * c-decl.cc (strict_flex_array_level_of): Move to c-common.cc and rename to c_strict_flex_array_level_of. (is_flexible_array_member_p): Adjust caller. gcc/testsuite/ * gcc.dg/ubsan/bounds-4.c: New test. * gcc.dg/ubsan/bounds-4a.c: New test. * gcc.dg/ubsan/bounds-4b.c: New test. * gcc.dg/ubsan/bounds-4c.c: New test. * gcc.dg/ubsan/bounds-4d.c: New test. * g++.dg/ubsan/bounds-1.C: New test.
2023-02-19Daily bump.GCC Administrator1-0/+21
2023-02-18C: Detect all variably modified types [PR108375]Martin Uecker6-41/+50
Some variably modified types were not detected correctly. Define C_TYPE_VARIABLY_MODIFIED via TYPE_LANG_FLAG 6 in the CFE. This flag records whether a type is variably modified and is set for all such types including arrays with variably modified element type or structures and unions with variably modified members. This is then used to detect such types in the C FE and middle-end (via the existing language hook). gcc/c/ChangeLog: PR c/108375 * c-decl.cc (decl_jump_unsafe): Use c_type_variably_modified_p. (diagnose_mismatched_decl): Dito. (warn_about_goto): Dito: (c_check_switch_jump_warnings): Dito. (finish_decl): Dito. (finish_struct): Dito. (grokdeclarator): Set C_TYPE_VARIABLY_MODIFIED. (finish_struct): Set C_TYPE_VARIABLY_MODIFIED. * c-objc-common.cc (c_var_mod_p): New function. (c_var_unspec_p): Remove. * c-objc-common.h: Set lang hook. * c-parser.cc (c_parser_declararion_or_fndef): Use c_type_variably_modified_p. (c_parser_typeof_specifier): Dito. (c_parser_has_attribute_expression): Dito. (c_parser_generic_selection): Dito. * c-tree.h: Define C_TYPE_VARIABLY_MODIFIED and define c_var_mode_p. * c-typeck.cc: Remove c_vla_mod_p and use C_TYPE_VARIABLY_MODIFIED. gcc/testsuite/ChangeLog: PR c/108375 * gcc.dg/pr108375-1.c: New test. * gcc.dg/pr108375-2.c: New test.
2023-02-17Daily bump.GCC Administrator1-0/+5
2023-02-16don't declare header-defined functions both static and inlinePatrick Palka1-3/+3
Many functions defined in our headers are declared 'static inline' which is a C idiom whose use predates our move to C++ as the implementation language. But in C++ the inline keyword is more than just a compiler hint, and is sufficient to give the function the intended semantics. In fact declaring a function both static and inline is a pessimization since static effectively disables the desired definition merging behavior enabled by inline, and is also a source of (harmless) ODR violations when a static inline function gets called from a non-static inline one (such as tree_operand_check calling tree_operand_length). This patch mechanically fixes the vast majority of occurrences of this anti-pattern throughout the compiler's headers via the command line sed -i 's/^static inline/inline/g' gcc/*.h gcc/*/*.h There's also a manual change to remove the redundant declarations of is_ivar and lookup_category in gcc/objc/objc-act.cc which would otherwise conflict with their modified definitions in objc-act.h (due to the difference in staticness). Besides fixing some ODR violations, this speeds up stage1 cc1plus by about 2% and reduces the size of its text segment by 1.5MB. gcc/ChangeLog: * addresses.h: Mechanically drop 'static' from 'static inline' functions via s/^static inline/inline/g. * asan.h: Likewise. * attribs.h: Likewise. * basic-block.h: Likewise. * bitmap.h: Likewise. * cfghooks.h: Likewise. * cfgloop.h: Likewise. * cgraph.h: Likewise. * cselib.h: Likewise. * data-streamer.h: Likewise. * debug.h: Likewise. * df.h: Likewise. * diagnostic.h: Likewise. * dominance.h: Likewise. * dumpfile.h: Likewise. * emit-rtl.h: Likewise. * except.h: Likewise. * expmed.h: Likewise. * expr.h: Likewise. * fixed-value.h: Likewise. * gengtype.h: Likewise. * gimple-expr.h: Likewise. * gimple-iterator.h: Likewise. * gimple-predict.h: Likewise. * gimple-range-fold.h: Likewise. * gimple-ssa.h: Likewise. * gimple.h: Likewise. * graphite.h: Likewise. * hard-reg-set.h: Likewise. * hash-map.h: Likewise. * hash-set.h: Likewise. * hash-table.h: Likewise. * hwint.h: Likewise. * input.h: Likewise. * insn-addr.h: Likewise. * internal-fn.h: Likewise. * ipa-fnsummary.h: Likewise. * ipa-icf-gimple.h: Likewise. * ipa-inline.h: Likewise. * ipa-modref.h: Likewise. * ipa-prop.h: Likewise. * ira-int.h: Likewise. * ira.h: Likewise. * lra-int.h: Likewise. * lra.h: Likewise. * lto-streamer.h: Likewise. * memmodel.h: Likewise. * omp-general.h: Likewise. * optabs-query.h: Likewise. * optabs.h: Likewise. * plugin.h: Likewise. * pretty-print.h: Likewise. * range.h: Likewise. * read-md.h: Likewise. * recog.h: Likewise. * regs.h: Likewise. * rtl-iter.h: Likewise. * rtl.h: Likewise. * sbitmap.h: Likewise. * sched-int.h: Likewise. * sel-sched-ir.h: Likewise. * sese.h: Likewise. * sparseset.h: Likewise. * ssa-iterators.h: Likewise. * system.h: Likewise. * target-globals.h: Likewise. * target.h: Likewise. * timevar.h: Likewise. * tree-chrec.h: Likewise. * tree-data-ref.h: Likewise. * tree-iterator.h: Likewise. * tree-outof-ssa.h: Likewise. * tree-phinodes.h: Likewise. * tree-scalar-evolution.h: Likewise. * tree-sra.h: Likewise. * tree-ssa-alias.h: Likewise. * tree-ssa-live.h: Likewise. * tree-ssa-loop-manip.h: Likewise. * tree-ssa-loop.h: Likewise. * tree-ssa-operands.h: Likewise. * tree-ssa-propagate.h: Likewise. * tree-ssa-sccvn.h: Likewise. * tree-ssa.h: Likewise. * tree-ssanames.h: Likewise. * tree-streamer.h: Likewise. * tree-switch-conversion.h: Likewise. * tree-vectorizer.h: Likewise. * tree.h: Likewise. * wide-int.h: Likewise. gcc/c-family/ChangeLog: * c-common.h: Mechanically drop static from static inline functions via s/^static inline/inline/g. gcc/c/ChangeLog: * c-parser.h: Mechanically drop static from static inline functions via s/^static inline/inline/g. gcc/cp/ChangeLog: * cp-tree.h: Mechanically drop static from static inline functions via s/^static inline/inline/g. gcc/fortran/ChangeLog: * gfortran.h: Mechanically drop static from static inline functions via s/^static inline/inline/g. gcc/jit/ChangeLog: * jit-dejagnu.h: Mechanically drop static from static inline functions via s/^static inline/inline/g. * jit-recording.h: Likewise. gcc/objc/ChangeLog: * objc-act.h: Mechanically drop static from static inline functions via s/^static inline/inline/g. * objc-map.h: Likewise. * objc-act.cc: Remove the redundant redeclarations of is_ivar and lookup_category.
2023-02-11Daily bump.GCC Administrator1-0/+10
2023-02-10c: Allow conversions of null pointer constants to nullptr_tJoseph Myers3-6/+23
WG14 has agreed to allow conversions (explicit and implicit) from null pointer constants to nullptr_t; update GCC's nullptr_t implementation to match. Bootstrapped with no regressions for x86_64-pc-linux-gnu. gcc/c/ * c-convert.cc (c_convert): Allow conversion of a null pointer constant to nullptr_t. * c-typeck.cc (null_pointer_constant_p): Remove static. (convert_for_assignment): Allow conversion of a null pointer constant to nullptr_t. (digest_init): Handle NULLPTR_TYPE among scalar conversions. * c-tree.h (null_pointer_constant_p): Declare. gcc/testsuite/ * gcc.dg/c2x-nullptr-1.c: Test conversion of null pointer constants to nullptr_t. * gcc.dg/c2x-nullptr-3.c: Do not expect errors for conversion of null pointer constants to nullptr_t. Do test errors for conversion of other values to nullptr_t and for unary '+' on nullptr_t.
2023-02-10Daily bump.GCC Administrator1-0/+5
2023-02-09OpenMP: Parse align clause in allocate directive in C/C++Tobias Burnus1-23/+65
gcc/c/ChangeLog: * c-parser.cc (c_parser_omp_allocate): Parse align clause and check for restrictions. gcc/cp/ChangeLog: * parser.cc (cp_parser_omp_allocate): Parse align clause and check for restrictions. gcc/testsuite/ChangeLog: * c-c++-common/gomp/allocate-5.c: Extend for align clause.
2023-02-09Daily bump.GCC Administrator1-0/+7
2023-02-08c: Update checks on constexpr pointer initializersJoseph Myers1-15/+10
WG14 has agreed a change of the rules on constexpr pointer initializers, so that a (constant) null value that is not a null pointer constant is accepted in that context, rather than only accepting null pointer constants. (In particular, this means that a constexpr variable of pointer type can be used to initializer another such variable.) Remove the null pointer constant restriction in GCC, instead checking just whether the value is null. Bootstrapped with no regressions for x86_64-pc-linux-gnu. gcc/c/ * c-typeck.cc (check_constexpr_init): Remove argument null_pointer_constant. Only check pointer initializers for being null. (digest_init): Update calls to check_constexpr_init. gcc/testsuite/ * gcc.dg/c2x-constexpr-1.c: Test initialization of constexpr pointers with null values that are not null pointer constants. * gcc.dg/c2x-constexpr-3.c: Test initialization of constexpr pointers with non-null values, not with null values that are not null pointer constants.
2023-02-03Daily bump.GCC Administrator1-0/+15
2023-02-02c: Update nullptr_t comparison checksJoseph Myers1-2/+6
WG14 has agreed to allow equality comparisons between pointers and nullptr_t values that are not null pointer constants (this was previously an exceptional case where such nullptr_t values were handled differently from null pointer constants; other places in the standard allowed nullptr_t values, whether or not those values are null pointer constants, in the same contexts as null pointer constants); see the wording at the end of N3077. Update GCC's implementation to match this change. There are also changes to allow null pointer constants of integer or pointer type to be converted to nullptr_t (by assignment, cast or conversion as if by assignment), which I'll deal with separately. Bootstrapped with no regressions for x86_64-pc-linux-gnu. gcc/c/ * c-typeck.cc (build_binary_op): Allow comparisons between pointers and nullptr_t values that are not null pointer constants. gcc/testsuite/ * gcc.dg/c2x-constexpr-3.c: Do not expect comparison of nullptr_t and pointer to be disallowed. * gcc.dg/c2x-nullptr-1.c: Test comparisons of nullptr_t and pointers are allowed. * gcc.dg/c2x-nullptr-3.c: Do not test that comparisons of nullptr_t and pointers are disallowed.
2023-02-02c: Update checks on constexpr floating-point initializersJoseph Myers1-43/+68
WG14 has agreed some changes (detailed at the end of N3082) to the rules on constexpr initializers for floating types. Update GCC's implementation to match: binary initializers are now allowed for decimal types, and real initializers for complex types, but signaling NaN initializers can't be used for a different type with the same mode. There are also changes to the constexpr rules for pointer types (allowing null pointer address constants that aren't null pointer constants), which I'll deal with separately. Bootstrapped with no regressions for x86_64-pc-linux-gnu. gcc/c/ * c-typeck.cc: Include "realmpfr.h". (constexpr_init_fits_real_type): Do not allow signaling NaN conversions to different types with the same mode. Handle conversions from binary to decimal types. (check_constexpr_init): Do not disallow real initializers for complex types. Do not disallow binary initializers for decimal floating types. gcc/testsuite/ * gcc.dg/c2x-constexpr-1.c: Test constexpr initializers of complex types with real initializers are allowed. * gcc.dg/c2x-constexpr-3.c: Do not test for constexpr initializers of complex types with real initializers being disallowed. * gcc.dg/c2x-constexpr-8.c: Add tests of signaling NaN complex initializers. * gcc.dg/c2x-constexpr-9.c: Add more tests. * gcc.dg/dfp/c2x-constexpr-dfp-1.c: Add tests of binary floating initializers for decimal types. * gcc.dg/dfp/c2x-constexpr-dfp-2.c: Change tests of binary initializers for decimal types. Add more tests of decimal initializers for binary types.
2023-02-01Daily bump.GCC Administrator1-0/+6
2023-01-31c++: fix ICE with -Wduplicated-cond [PR107593]Marek Polacek1-0/+8
Here we crash because a CAST_EXPR, representing T(), doesn't have its operand, and operand_equal_p's STRIP_ANY_LOCATION_WRAPPER doesn't expect that. (o_e_p is called from warn_duplicated_cond_add_or_warn.) In the past we've adjusted o_e_p to better cope with template codes, but in this case I think we just want to avoid attempting to warn about inst-dependent expressions; I don't think I've ever envisioned -Wduplicated-cond to warn about them. Also destroy the chain when an inst-dependent expression is encountered to not warn in Wduplicated-cond4.C. The ICE started with r12-6022, two-stage name lookup for overloaded operators, which gave dependent operators a TREE_TYPE (in particular, DEPENDENT_OPERATOR_TYPE), so we no longer bail out here in o_e_p: /* Similar, if either does not have a type (like a template id), they aren't equal. */ if (!TREE_TYPE (arg0) || !TREE_TYPE (arg1)) return false; PR c++/107593 PR c++/108597 gcc/c-family/ChangeLog: * c-common.h (instantiation_dependent_expression_p): Declare. * c-warn.cc (warn_duplicated_cond_add_or_warn): If the condition is dependent, invalidate the chain. gcc/c/ChangeLog: * c-objc-common.cc (instantiation_dependent_expression_p): New. gcc/cp/ChangeLog: * cp-tree.h (instantiation_dependent_expression_p): Don't declare here. gcc/testsuite/ChangeLog: * g++.dg/warn/Wduplicated-cond3.C: New test. * g++.dg/warn/Wduplicated-cond4.C: New test. * g++.dg/warn/Wduplicated-cond5.C: New test.
2023-01-28Daily bump.GCC Administrator1-0/+5
2023-01-27c: Disallow braces around C2x auto initializersJoseph Myers1-12/+1
WG14 agreed at this week's meeting to remove support for braces around auto scalar initializers, as incompatible with C++ auto handling of braced initializers; thus remove that support in GCC. Bootstrapped with no regressions for x86_64-pc-linux-gnu. gcc/c/ * c-parser.cc (c_parser_declaration_or_fndef): Do not allow braces around auto initializer. gcc/testsuite/ * gcc.dg/c2x-auto-1.c, gcc.dg/c2x-auto-3.c: Expect braces around auto initializers to be disallowed.
2023-01-17Daily bump.GCC Administrator1-0/+7
2023-01-16Update copyright years.Jakub Jelinek18-18/+18
2023-01-16c, c++: Allow ignoring -Winit-self through pragmas [PR105593]Jakub Jelinek1-1/+1
As mentioned in the PR, various x86 intrinsics need to return an uninitialized vector. Currently they use self initialization to avoid -Wuninitialized warnings, which works fine in C, but doesn't work in C++ where -Winit-self is enabled in -Wall. We don't have an attribute to mark a variable as knowingly uninitialized (the uninitialized attribute exists but means something else, only in the -ftrivial-auto-var-init context), and trying to suppress either -Wuninitialized or -Winit-self inside of the _mm_undefined_ps etc. intrinsic definitions doesn't work, one needs to currently disable through pragmas -Wuninitialized warning at the point where _mm_undefined_ps etc. result is actually used, but that goes against the intent of those intrinsics. The -Winit-self warning option actually doesn't do any warning, all we do is record a suppression for -Winit-self if !warn_init_self on the decl definition and later look that up in uninit pass. The following patch changes those !warn_init_self tests which are true only based on the command line option setting, not based on GCC diagnostic pragma overrides to !warning_enabled_at (DECL_SOURCE_LOCATION (decl), OPT_Winit_self) such that it takes them into account. 2023-01-16 Jakub Jelinek <jakub@redhat.com> PR c++/105593 gcc/c/ * c-parser.cc (c_parser_initializer): Check warning_enabled_at at the DECL_SOURCE_LOCATION (decl) for OPT_Winit_self instead of warn_init_self. gcc/cp/ * decl.cc (cp_finish_decl): Check warning_enabled_at at the DECL_SOURCE_LOCATION (decl) for OPT_Winit_self instead of warn_init_self. gcc/testsuite/ * c-c++-common/Winit-self3.c: New test. * c-c++-common/Winit-self4.c: New test. * c-c++-common/Winit-self5.c: New test.
2023-01-15Daily bump.GCC Administrator1-0/+10
2023-01-14c++: Avoid incorrect shortening of divisions [PR108365]Jakub Jelinek1-6/+2
The following testcase is miscompiled, because we shorten the division in a case where it should not be shortened. Divisions (and modulos) can be shortened if it is unsigned division/modulo, or if it is signed division/modulo where we can prove the dividend will not be the minimum signed value or divisor will not be -1, because e.g. on sizeof(long long)==sizeof(int)*2 && __INT_MAX__ == 0x7fffffff targets (-2147483647 - 1) / -1 is UB but (int) (-2147483648LL / -1LL) is not, it is -2147483648. The primary aim of both the C and C++ FE division/modulo shortening I assume was for the implicit integral promotions of {,signed,unsigned} {char,short} and because at this point we have no VRP information etc., the shortening is done if the integral promotion is from unsigned type for the divisor or if the dividend is an integer constant other than -1. This works fine for char/short -> int promotions when char/short have smaller precision than int - unsigned char -> int or unsigned short -> int will always be a positive int, so never the most negative. Now, the C FE checks whether orig_op0 is TYPE_UNSIGNED where op0 is either the same as orig_op0 or that promoted to int, I think that works fine, if it isn't promoted, either the division/modulo common type will have the same precision as op0 but then the division/modulo is unsigned and so without UB, or it will be done in wider precision (e.g. because op1 has wider precision), but then op0 can't be minimum signed value. Or it has been promoted to int, but in that case it was again from narrower type and so never minimum signed int. But the C++ FE was checking if op0 is a NOP_EXPR from TYPE_UNSIGNED. First of all, not sure if the operand of NOP_EXPR couldn't be non-integral type where TYPE_UNSIGNED wouldn't be meaningful, but more importantly, even if it is a cast from unsigned integral type, we only know it can't be minimum signed value if it is a widening cast, if it is same precision or narrowing cast, we know nothing. So, the following patch for the NOP_EXPR cases checks just in case that it is from integral type and more importantly checks it is a widening conversion, and then next to it also allows op0 to be just unsigned, promoted or not, as that is what the C FE will do for those cases too and I believe it must work - either the division/modulo common type will be that unsigned type, then we can shorten and don't need to worry about UB, or it will be some wider signed type but then it can't be most negative value of the wider type. And changes both the C and C++ FEs to do the same thing, using a helper function in c-family. 2023-01-14 Jakub Jelinek <jakub@redhat.com> PR c++/108365 * c-common.h (may_shorten_divmod): New static inline function. * c-typeck.cc (build_binary_op): Use may_shorten_divmod for integral division or modulo. * typeck.cc (cp_build_binary_op): Use may_shorten_divmod for integral division or modulo. * c-c++-common/pr108365.c: New test. * g++.dg/opt/pr108365.C: New test. * g++.dg/warn/pr108365.C: New test.
2023-01-13Replace flag_strict_flex_arrays with DECL_NOT_FLEXARRAY in middle-end.Qing Zhao1-0/+28
We should not directly check flag_strict_flex_arrays in the middle end. Instead, check DECL_NOT_FLEXARRAY(array_field_decl) which is set by C/C++ FEs according to -fstrict-flex-arrays and the corresponding attribute attached to the array_field. As a result, We will lose the LEVEL information of -fstrict-flex-arrays in the middle end. -Wstrict-flex-arrays will not be able to issue such information. update the testing cases accordingly. gcc/ChangeLog: * attribs.cc (strict_flex_array_level_of): Move this function to ... * attribs.h (strict_flex_array_level_of): Remove the declaration. * gimple-array-bounds.cc (array_bounds_checker::check_array_ref): replace the referece to strict_flex_array_level_of with DECL_NOT_FLEXARRAY. * tree.cc (component_ref_size): Likewise. gcc/c/ChangeLog: * c-decl.cc (strict_flex_array_level_of): ... here. gcc/testsuite/ChangeLog: * gcc.dg/Warray-bounds-flex-arrays-1.c: Delete the level information from the message issued by -Wstrict-flex-arrays. * gcc.dg/Warray-bounds-flex-arrays-2.c: Likewise. * gcc.dg/Warray-bounds-flex-arrays-3.c: Likewise. * gcc.dg/Warray-bounds-flex-arrays-4.c: Likewise. * gcc.dg/Warray-bounds-flex-arrays-5.c: Likewise. * gcc.dg/Warray-bounds-flex-arrays-6.c: Likewise. * gcc.dg/Wstrict-flex-arrays-2.c: Likewise. * gcc.dg/Wstrict-flex-arrays-3.c: Likewise. * gcc.dg/Wstrict-flex-arrays.c: Likewise.
2023-01-12Daily bump.GCC Administrator1-0/+6
2023-01-11c: Don't emit DEBUG_BEGIN_STMTs for K&R function argument declarations ↵Jakub Jelinek1-0/+3
[PR105972] K&R function parameter declarations are handled by calling recursively c_parser_declaration_or_fndef in a loop, where each such call will add_debug_begin_stmt at the start. Now, if the K&R function definition is not a nested function, building_stmt_list_p () is false and so we don't emit the DEBUG_BEGIN_STMTs anywhere, but if it is a nested function, we emit it in the containing function at the point of the nested function definition. As the following testcase shows, it can cause ICEs if the containing function has var-tracking disabled but nested function has them enabled, as the DEBUG_BEGIN_STMTs are added to the containing function which shouldn't have them but MAY_HAVE_DEBUG_MARKER_STMTS is checked already for the nested function, or just wrong experience in the debugger. The following patch ensures we don't emit any such DEBUG_BEGIN_STMTs for the K&R function parameter declarations even in nested functions. 2023-01-11 Jakub Jelinek <jakub@redhat.com> PR c/105972 * c-parser.cc (c_parser_declaration_or_fndef): Disable debug non-bind markers for K&R function parameter declarations of nested functions. * gcc.dg/pr105972.c: New test.
2023-01-10Daily bump.GCC Administrator1-0/+4
2023-01-09c: Check for modifiable static compound literals in inline definitionsJoseph Myers1-0/+7
The C rule against modifiable objects with static storage duration in inline definitions should apply to compound literals (using the C2x feature of storage-class specifiers for compound literals) just as to variables. Add a call to record_inline_static for compound literals to make sure this case is detected. Bootstrapped with no regressions for x86_64-pc-linux-gnu. gcc/c/ * c-decl.cc (build_compound_literal): Call record_inline_static. gcc/testsuite/ * gcc.dg/c2x-complit-8.c: New test.
2023-01-07Daily bump.GCC Administrator1-0/+8
2023-01-06c: C2x semantics for __builtin_tgmathJoseph Myers1-22/+20
__builtin_tgmath implements <tgmath.h> semantics for integer generic arguments that handle cases involving _FloatN / _FloatNx types as specified in TS 18661-3 plus some defect fixes. C2x has further changes to the semantics for <tgmath.h> macros with such types, which should also be considered defect fixes (although handled through the integration of TS 18661-3 in C2x rather than through an issue tracking process). Specifically, the rules were changed because of problems raised with using the macros with the evaluation format types such as float_t and _Float32_t: the older version of the rules didn't allow passing _FloatN / _FloatNx types to the narrowing macros returning float or double, or passing float / double / long double to the narrowing macros returning _FloatN / _FloatNx, which was a problem with the evaluation format types which could be either kind of type depending on the value of FLT_EVAL_METHOD. Thus the new rules allow cases of mixing types which were not allowed before - which is not itself a problem for __builtin_tgmath - and, as part of the changes, the handling of integer arguments was also changed: if there is any _FloatNx generic argument, integer generic arguments are treated as _Float32x (not double), while the rule about treating integer arguments to narrowing macros returning _FloatN or _FloatNx as _Float64 not double was removed (no longer needed now double is a valid argument to such macros). Implement the changes for __builtin_tgmath. (The changes also added a rule that if any argument is _DecimalNx, integer arguments are treated as _Decimal64x, but GCC doesn't support _DecimalNx types so nothing is done about that.) I have a corresponding glibc patch to update glibc test expectations for C2x and also ensure that appropriate semantics are followed when GCC 7 through 12 are used with <tgmath.h> (avoiding __builtin_tgmath in cases where it doesn't match the C2x semantics). Bootstrapped with no regressions for x86_64-pc-linux-gnu. gcc/ * doc/extend.texi (__builtin_tgmath): Do not restate standard rule for handling real integer types. gcc/c/ * c-parser.cc (c_parser_postfix_expression): Handle integer generic arguments to functions passed to __builtin_tgmath as _Float32x if any argument has _FloatNx or _Complex _FloatNx type. Do not handle integer arguments to some narrowing functions as _Float64. gcc/testsuite/ * gcc.dg/builtin-tgmath-3.c: Update expectations and add more tests.
2023-01-02Update Copyright year in ChangeLog filesJakub Jelinek1-1/+1
2022 -> 2023