Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
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.
|
|
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.
|
|
|
|
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
|
|
|
|
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.
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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>
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
|
|
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.
|
|
|
|
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.
|
|
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.
|
|
|
|
[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.
|
|
|
|
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.
|
|
|
|
__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.
|
|
2022 -> 2023
|