| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
When we disallow TYPE_PRECISION on VECTOR_TYPEs it shows that
shorten_binary_op performs some checks on that that are likely
harmless in the end. The following bails out early for
VECTOR_TYPE operations to avoid those questionable checks.
gcc/c-family/
* c-common.cc (shorten_binary_op): Exit early for VECTOR_TYPE
operations.
|
|
|
|
It seems prudent to add C++26 now that the first C++26 papers have been
approved. I followed commit r11-6920 as well as r8-3237.
Since C++23 is essentially finished and its __cplusplus value has
settled to 202302L, I've updated cpp_init_builtins and marked
-std=c++2b Undocumented and made -std=c++23 no longer Undocumented.
As for __cplusplus, I've chosen 202400L:
$ xg++ -std=c++26 -dM -E -x c++ - < /dev/null | grep cplusplus
#define __cplusplus 202400L
I've verified the patch with a simple test, exercising the new
directives. Don't forget to update your GXX_TESTSUITE_STDS!
This patch does not add -Wc++26-extensions.
gcc/c-family/ChangeLog:
* c-common.h (cxx_dialect): Add cxx26 as a dialect.
* c-opts.cc (set_std_cxx26): New.
(c_common_handle_option): Set options when -std={c,gnu}++2{c,6} is
enabled.
(c_common_post_options): Adjust comments.
* c.opt: Add options for -std=c++26, std=c++2c, -std=gnu++26,
and -std=gnu++2c.
(std=c++2b): Mark as Undocumented.
(std=c++23): No longer Undocumented.
gcc/ChangeLog:
* doc/cpp.texi (__cplusplus): Document value for -std=c++26 and
-std=gnu++26. Document that for C++23, its value is 202302L.
* doc/invoke.texi: Document -std=c++26 and -std=gnu++26.
* dwarf2out.cc (highest_c_language): Handle GNU C++26.
(gen_compile_unit_die): Likewise.
libcpp/ChangeLog:
* include/cpplib.h (c_lang): Add CXX26 and GNUCXX26.
* init.cc (lang_defaults): Add rows for CXX26 and GNUCXX26.
(cpp_init_builtins): Set __cplusplus to 202400L for C++26.
Set __cplusplus to 202302L for C++23.
gcc/testsuite/ChangeLog:
* lib/target-supports.exp (check_effective_target_c++23): Return
1 also if check_effective_target_c++26.
(check_effective_target_c++23_down): New.
(check_effective_target_c++26_only): New.
(check_effective_target_c++26): New.
* g++.dg/cpp23/cplusplus.C: Adjust expected value.
* g++.dg/cpp26/cplusplus.C: New test.
|
|
|
|
Implement -ffp-contract=on for C and C++ without changing default
behavior (=off for -std=cNN, =fast for C++ and -std=gnuNN).
gcc/c-family/ChangeLog:
* c-gimplify.cc (fma_supported_p): New helper.
(c_gimplify_expr) [PLUS_EXPR, MINUS_EXPR]: Implement FMA
contraction.
gcc/ChangeLog:
* common.opt (fp_contract_mode) [on]: Remove fallback.
* config/sh/sh.md (*fmasf4): Correct flag_fp_contract_mode test.
* doc/invoke.texi (-ffp-contract): Update.
* trans-mem.cc (diagnose_tm_1): Skip internal function calls.
|
|
|
|
macOS SDK headers using the CF_ENUM macro can expand to invalid C++ code
of the form:
typedef enum T : BaseType T;
i.e. an elaborated-type-specifier with an additional enum-base.
Upstream LLVM can be made to accept the above construct with
-Wno-error=elaborated-enum-base.
This patch adds the -Welaborated-enum-base warning to GCC and adjusts
the C++ parser to emit this warning instead of rejecting this code
outright.
The macro expansion in the macOS headers occurs in the case that the
compiler declares support for enums with underlying type using
__has_feature, see
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618450.html
GCC rejecting this construct outright means that GCC fails to bootstrap
on Darwin in the case that it (correctly) implements __has_feature and
declares support for C++ enums with underlying type.
With this patch, GCC can bootstrap on Darwin in combination with the
(WIP) __has_feature patch posted at:
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/617878.html
gcc/c-family/ChangeLog:
* c.opt (Welaborated-enum-base): New.
gcc/ChangeLog:
* doc/invoke.texi: Document -Welaborated-enum-base.
gcc/cp/ChangeLog:
* parser.cc (cp_parser_enum_specifier): Don't reject
elaborated-type-specifier with enum-base, instead emit new
Welaborated-enum-base warning.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/enum40.C: Adjust expected diagnostics.
* g++.dg/cpp0x/forw_enum6.C: Likewise.
* g++.dg/cpp0x/elab-enum-base.C: New test.
|
|
|
|
Quoting "How a computer should talk to people" (as quoted
in "Concepts Error Messages for Humans"):
"Various negative tones or actions are unfriendly: being manipulative,
not giving a second chance, talking down, using fashionable slang,
blaming. We must not seem to blame the person. We should avoid suggesting
that the person is inadequate. Phrases like "you forgot" may seem
harmless, but what if a computer said this to you four or five times in
two minutes? Anyway, the person may disagree, so why risk offense?"
gcc/c-family/ChangeLog:
PR c/84890
* known-headers.cc
(suggest_missing_header::~suggest_missing_header): Reword note to
avoid negative tone of "forgetting".
gcc/cp/ChangeLog:
PR c/84890
* name-lookup.cc (missing_std_header::~missing_std_header): Reword
note to avoid negative tone of "forgetting".
gcc/testsuite/ChangeLog:
PR c/84890
* g++.dg/cpp2a/srcloc3.C: Update expected message.
* g++.dg/lookup/missing-std-include-2.C: Likewise.
* g++.dg/lookup/missing-std-include-3.C: Likewise.
* g++.dg/lookup/missing-std-include-6.C: Likewise.
* g++.dg/lookup/missing-std-include.C: Likewise.
* g++.dg/spellcheck-inttypes.C: Likewise.
* g++.dg/spellcheck-stdint.C: Likewise.
* g++.dg/spellcheck-stdlib.C: Likewise.
* gcc.dg/spellcheck-inttypes.c: Likewise.
* gcc.dg/spellcheck-stdbool.c: Likewise.
* gcc.dg/spellcheck-stdint.c: Likewise.
* gcc.dg/spellcheck-stdlib.c: Likewise.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
|
|
|
|
While looking at PRs about cases where we don't perform the named return
value optimization, it occurred to me that it might be useful to have a
warning for that.
This does not fix PR58487, but might be interesting to people watching it.
PR c++/58487
gcc/c-family/ChangeLog:
* c.opt: Add -Wnrvo.
gcc/ChangeLog:
* doc/invoke.texi: Document it.
gcc/cp/ChangeLog:
* typeck.cc (want_nrvo_p): New.
(check_return_expr): Handle -Wnrvo.
gcc/testsuite/ChangeLog:
* g++.dg/opt/nrv25.C: New test.
|
|
|
|
Warnings from -Wstringop-overflow do not appear for parameters declared
as VLAs when the bound refers to a parameter forward declaration. This
is fixed by splitting the loop that passes through parameters into two,
first only recording the positions of all possible size expressions
and then processing the parameters.
PR c/109970
gcc/c-family:
* c-attribs.cc (build_attr_access_from_parms): Split loop to first
record all parameters.
gcc/testsuite:
* gcc.dg/pr109970.c: New test.
|
|
|
|
gcc/c-family/ChangeLog:
* c-ada-spec.cc (has_static_fields): Use _P() defines from tree.h.
(dump_ada_declaration): Ditto.
(dump_ada_structure): Ditto.
* c-common.cc (unsafe_conversion_p): Ditto.
(shorten_compare): Ditto.
(pointer_int_sum): Ditto.
(c_common_truthvalue_conversion): Ditto.
(scalar_to_vector): Ditto.
* c-common.h (gnu_vector_type_p): Ditto.
* c-omp.cc (c_omp_depend_t_p): Ditto.
(c_omp_split_clauses): Ditto.
* c-ubsan.cc (ubsan_instrument_division): Ditto.
* c-warn.cc (conversion_warning): Ditto.
(warnings_for_convert_and_check): Ditto.
gcc/c/ChangeLog:
* c-convert.cc (c_convert): Ditto.
* c-decl.cc (merge_decls): Ditto.
* c-parser.cc (c_parser_omp_clause_reduction): Ditto.
(c_parser_omp_declare_reduction): Ditto.
* c-typeck.cc (build_component_ref): Ditto.
(convert_argument): Ditto.
(pointer_diff): Ditto.
(build_unary_op): Ditto.
(build_c_cast): Ditto.
(build_modify_expr): Ditto.
(store_init_value): Ditto.
(constexpr_init_fits_real_type): Ditto.
(check_constexpr_init): Ditto.
(c_finish_return): Ditto.
(handle_omp_array_sections_1): Ditto.
(c_finish_omp_clauses): Ditto.
* gimple-parser.cc (c_finish_gimple_return): Ditto.
libcc1/ChangeLog:
* libcc1plugin.cc (plugin_float_type): Ditto.
* libcp1plugin.cc (plugin_reactivate_decl): Ditto.
(plugin_get_float_type): Ditto.
|
|
|
|
WG14 decided to change the printf %B format from a recommended
extension to an optional feature defined in normative text. Thus,
change the format checking to handle %B like %b, so not diagnosing it
with -Wformat -std=c2x -pedantic, just as with other optional
normatively defined features (such as decimal floating point and its
associated formats, for example).
Bootstrapped with no regressions for x86_64-pc-linux-gnu.
gcc/c-family/
* c-format.cc (print_char_table): Handle %B like %b.
gcc/testsuite/
* gcc.dg/format/c2x-printf-1.c: Test %B here.
* gcc.dg/format/ext-9.c: Do not test %B here.
|
|
|
|
WG14 decided that __has_c_attribute should return the same value
(equal to the intended __STDC_VERSION__ value) for all standard
attributes in C2x, with values associated with when an attribute was
added to the working draft (or had semantics added or changed in the
working draft) only being used in earlier stages of development of
that draft. The intent is that the values for existing attributes
increase in future standard versions only if there are new features /
semantic changes for those attributes. Implement this change for GCC.
Bootstrapped with no regressions for x86_64-pc-linux-gnu.
gcc/c-family/
* c-lex.cc (c_common_has_attribute): Use 202311 as
__has_c_attribute return for all C2x attributes.
gcc/testsuite/
* gcc.dg/c2x-has-c-attribute-2.c: Expect 202311L return value from
__has_c_attribute for all C2x attributes.
|
|
This adds the feature-test macro for PR0849R8, as per
https://github.com/cplusplus/CWG/issues/281.
gcc/c-family/ChangeLog:
* c-cppbuiltin.cc (c_cpp_builtins): Predefine __cpp_auto_cast
for C++23.
gcc/testsuite/ChangeLog:
* g++.dg/cpp23/feat-cxx2b.C: Test __cpp_auto_cast.
|
|
|
|
In <https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613687.html>
we discussed that the copy_node in ubsan_maybe_instrument_array_ref
is redundant, but also that it'd be best to postpone the optimization
to GCC 14. So I'm making that change now.
gcc/c-family/ChangeLog:
* c-ubsan.cc (ubsan_maybe_instrument_array_ref): Don't copy_node.
|
|
|
|
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>
|
|
The patch for PR91415 fixed -Wsequence-point to treat shifts and ARRAY_REF
as sequenced in C++17, and COMPONENT_REF as well. But this is unnecessary
for COMPONENT_REF, since the RHS is just a FIELD_DECL with no actual
evaluation, and in this testcase handling COMPONENT_REF as sequenced blows
up fast in a deep inheritance tree. Instead, look through it.
PR c++/107163
gcc/c-family/ChangeLog:
* c-common.cc (verify_tree): Don't use sequenced handling
for COMPONENT_REF.
gcc/testsuite/ChangeLog:
* g++.dg/warn/Wsequence-point-5.C: New test.
|
|
|
|
On the following testcase, the C FE decides to shorten the division because
it has a guarantee that INT_MIN / -1 division won't be encountered, the
first operand is widened from narrower unsigned and/or the second operand is
a constant other than all ones (in this case both are true).
The problem is that the narrower type in this case is _Bool and
ubsan_instrument_division only instruments it if op0's type is INTEGER_TYPE
or REAL_TYPE. Strangely this doesn't happen in C++ FE.
Anyway, we only shorten divisions if the INT_MIN / -1 case is impossible,
so I think we should be fine even with -fstrict-enums in C++ in case it
shortened to ENUMERAL_TYPEs.
The following patch just instruments those on the ubsan_instrument_division
side. Perhaps only the first hunk and testcase might be needed because
we shouldn't shorten if the other case could be triggered.
2023-03-17 Jakub Jelinek <jakub@redhat.com>
PR c/109151
* c-ubsan.cc (ubsan_instrument_division): Handle all scalar integral
types rather than just INTEGER_TYPE.
* c-c++-common/ubsan/div-by-zero-8.c: New test.
|
|
|
|
In this PR we are dealing with a missing .UBSAN_BOUNDS, so the
out-of-bounds access in the test makes the program crash before
a UBSan diagnostic was emitted. In C and C++, c_genericize gets
a[b] = a[b] | c;
but in C, both a[b] are one identical shared tree (not in C++ because
cp_fold/ARRAY_REF created two same but not identical trees). Since
ubsan_walk_array_refs_r keeps a pset, in C we produce
a[.UBSAN_BOUNDS (0B, SAVE_EXPR <b>, 8);, SAVE_EXPR <b>;] = a[b] | c;
because the LHS is walked before the RHS.
Since r7-1900, we gimplify the RHS before the LHS. So the statement above
gets gimplified into
_1 = a[b];
c.0_2 = c;
b.1 = b;
.UBSAN_BOUNDS (0B, b.1, 8);
With this patch we produce:
a[b] = a[.UBSAN_BOUNDS (0B, SAVE_EXPR <b>, 8);, SAVE_EXPR <b>;] | c;
which gets gimplified into:
b.0 = b;
.UBSAN_BOUNDS (0B, b.0, 8);
_1 = a[b.0];
therefore we emit a runtime error before making the bad array access.
I think it's OK that only the RHS gets a .UBSAN_BOUNDS, as in few lines
above: the instrumented array access dominates the array access on the
LHS, and I've verified that
b = 0;
a[b] = (a[b], b = -32768, a[0] | c);
works as expected: the inner a[b] is OK but we do emit an error for the
a[b] on the LHS.
For GCC 14, we could apply
<https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613687.html>
since the copy_node doesn't seem to be needed.
PR sanitizer/108060
PR sanitizer/109050
gcc/c-family/ChangeLog:
* c-gimplify.cc (ubsan_walk_array_refs_r): For a MODIFY_EXPR, instrument
the RHS before the LHS.
gcc/testsuite/ChangeLog:
* c-c++-common/ubsan/bounds-17.c: New test.
* c-c++-common/ubsan/bounds-18.c: New test.
* c-c++-common/ubsan/bounds-19.c: New test.
* c-c++-common/ubsan/bounds-20.c: New test.
* c-c++-common/ubsan/bounds-21.c: New test.
|
|
|
|
There can be too many extensions and seems I didn't get everything right in
the previously posted patch.
The following incremental patch ought to fix that.
The code can deal with quite a few sign/zero extensions at various spots
and it is important to deal with all of them right.
On the argument that contains BIT_NOT_EXPR we have:
MSB bits#4 bits#3 BIT_NOT_EXPR bits#2 bits#1 LSB
where bits#1 is one or more bits (TYPE_PRECISION (TREE_TYPE (arg0))
at the end of the function) we don't know anything about, for the purposes
of this warning it is VARYING that is inverted with BIT_NOT_EXPR to some other
VARYING bits;
bits#2 is one or more bits (TYPE_PRECISION (TREE_TYPE (op0)) -
TYPE_PRECISION (TREE_TYPE (arg0)) at the end of the function)
which are known to be 0 before the BIT_NOT_EXPR and 1 after it.
bits#3 is zero or more bits from the TYPE_PRECISION (TREE_TYPE (op0))
at the end of function to the TYPE_PRECISION (TREE_TYPE (op0)) at the
end of the function to TYPE_PRECISION (TREE_TYPE (op0)) at the start
of the function, which are either zero extension or sign extension.
And bits#4 is zero or more bits from the TYPE_PRECISION (TREE_TYPE (op0))
at the start of the function to TYPE_PRECISION (result_type), which
again can be zero or sign extension.
Now, vanilla trunk as well as the previously posted patch mishandles the
case where bits#3 are sign extended (as bits#2 are known to be all set,
that means bits#3 are all set too) but bits#4 are zero extended and are
thus all 0.
The patch fixes it by tracking the lowest bit which is known to be clear
above the known to be set bits (if any, otherwise it is precision of
result_type).
2023-03-04 Jakub Jelinek <jakub@redhat.com>
PR c/107465
* c-warn.cc (warn_for_sign_compare): Don't warn for unset bits
above innermost zero extension of BIT_NOT_EXPR result.
* c-c++-common/Wsign-compare-2.c (f18): New test.
|
|
The following patch fixes multiple bugs in warn_for_sign_compare related to
the BIT_NOT_EXPR related warnings.
My understanding is that what those 3 warnings are meant to warn (since 1995
apparently) is the case where we have BIT_NOT_EXPR of a zero-extended
value, so in result_type the value is something like:
0b11111111XXXXXXXX (e.g. ~ of a 8->16 bit zero extension)
0b000000000000000011111111XXXXXXXX (e.g. ~ of a 8->16 bit zero extension
then zero extended to 32 bits)
0b111111111111111111111111XXXXXXXX (e.g. ~ of a 8->16 bit zero extension
then sign extended to 32 bits)
and the intention of the warning is to warn when this is compared against
something that has some 0 bits at the place where the above has guaranteed
1 bits, either ensured through comparison against constant where we know
the bits exactly, or through zero extension from some narrower type where
again we know at least some upper bits are zero extended.
The bugs in the warning code are:
1) misunderstanding of the {,c_common_}get_narrower APIs - the unsignedp
it sets is only meaningful if the function actually returns something
narrower (in that case it says whether the narrower value is then
sign (0) or zero (1) extended to the originally passed value.
Though op0 or op1 at this point might be already narrower than
result_type, and if the function doesn't return anything narrower,
it all depends on whether the passed in op{0,1} had TYPE_UNSIGNED
type or not
2) the code didn't check at all whether the BIT_NOT_EXPR operand
was actually zero extended (i.e. that it was narrower and unsignedp
was set to 1 for it), all it did is check that unsignedp from the
call was 1. But that isn't well defined thing, if the argument
is returned as is, the function sets unsignedp to 0, but if there
is e.g. a useless cast to the same or compatible type in between,
it can return 1 if the cast is unsigned; now, if BIT_NOT_EXPR
operand is not zero extended, we know nothing at all about any bits
in the operand containing BIT_NOT_EXPR, so there is nothing to warn
about
3) the code was actually testing both operands after calling
c_common_get_narrower on them and on the one with BIT_NOT_EXPR
again for constants; I think that is just wrong in case the BIT_NOT_EXPR
operand wouldn't be fully folded, the warning makes sense only if the
other operand not having BIT_NOT_EXPR in it is constant
4) as can be seen from the above bit pattern examples, the upper bits above
(in the patch arg0) aren't always all 1s, there could be some zero extension
above it and from it one would have 0s, so that needs to be taken into
account for the choice which constant bits to test for being always set
otherwise warning is emitted, or for the zero extension guaranteed zero
bits
5) the patch also simplifies the handling, we only do it if one but not
both operands are BIT_NOT_EXPR after first {,c_common_}get_narrower,
so we can just use std::swap to ensure it is the first one
6) the code compared bits against HOST_BITS_PER_LONG, which made sense
back in 1995 when the values were stored into long, but now that they
are HOST_WIDE_INT should test HOST_BITS_PER_WIDE_INT (or we could rewrite
the stuff to wide_int, not done in the patch)
2023-03-04 Jakub Jelinek <jakub@redhat.com>
PR c/107465
* c-warn.cc (warn_for_sign_compare): If c_common_get_narrower
doesn't return a narrower result, use TYPE_UNSIGNED to set unsignedp0
and unsignedp1. For the one BIT_NOT_EXPR case vs. one without,
only check for constant in the non-BIT_NOT_EXPR operand, use std::swap
to simplify the code, only warn if BIT_NOT_EXPR operand is extended
from narrower unsigned, fix up computation of mask for the constant
cases and for unsigned other operand case handle differently
BIT_NOT_EXPR result being sign vs. zero extended.
* c-c++-common/Wsign-compare-2.c: New test.
* c-c++-common/pr107465.c: New test.
|
|
-Wshift-overflow warning [PR107846]
The r13-1100-gacb1e6f43dc2bbedd124 change added match.pd narrowing
of left shifts, and while I believe the C++ FE calls the warning on unfolded
trees, the C FE folds them and so left shifts where integral promotion
happened and so were done in int type will be usually narrowed back to
char/signed char/unsigned char/short/unsigned short left shifts if the
shift count is constant and fits into the precision of the var being
shifted.
One possibility would be to restrict the match.pd optimization to GIMPLE
only, another don't fold in C FE before this warning (well, we need to
fold the shift count operand to constant if possible), the following patch
just takes integral promotion into account in the warning code.
2023-03-04 Jakub Jelinek <jakub@redhat.com>
PR c/107846
* c-warn.cc: Include langhooks.h.
(maybe_warn_shift_overflow): Set type0 to what TREE_TYPE (op0)
promotes to rather than TREE_TYPE (op0) itself, if TREE_TYPE (op0)
is narrower than type0 and unsigned, use wi::min_precision with
UNSIGNED and fold_convert op0 to type0 before emitting the warning.
* gcc.dg/pr107846.c: New test.
|
|
|
|
We used to define WINT_TYPE to WCHAR_TYPE, so that both wint_t and
wchar_t mapped to the same underlying type, but this caused a glitch
in Wstringop-overflow-6.C: on vxworks, wint_t is typedef'ed to
wchar_t, headers got included in the test that declared functions that
take wint_t parameters, and those conflicted with the builtin
declarations that had wint_t mapped to the underlying integral type.
The problem is that, in C++, wchar_t is a distinct type. Having
wint_t be a typedef to wchar_t in the headers, but a typedef to
wchar_t's underlying integral type in builtins, makes for mismatches
between the declarations.
This patch defines WINT_TYPE to "wchar_t" for vxworks, and adjusts the
fallout, namely:
- since wchar_t may not have been defined yet when
c_common_nodes_and_builtins runs, use the node already reserved for
wchar_t for wint_t when WINT_TYPE is defined to wchar_t.
- for the same reason, when WINT_TYPE is wchar_t and we're not
compiling C++ where wchar_t is a compiler built-in, define
__WINT_TYPE__ to WCHAR_TYPE rather than WINT_TYPE, because wchar_t
may not even be defined in the translation unit.
- recognize and handle wchar_type_node when type_suffix is called for
wint_type_node.
for gcc/ChangeLog
* config/vx-common.h (WINT_TYPE): Alias to "wchar_t".
for gcc/c-family/ChangeLog
* c-common.cc (c_common_nodes_and_builtins): Take
wchar_type_node for wint_type_node when aliased.
(c_stddef_cpp_builtins): Define __WINT_TYPE__, when aliased to
wchar_t, to the underlying type rather than wchar_t in
non-C++.
* c-cppbuiltin.cc (type_suffix): Handle wchar_type_node.
|
|
|
|
Since r11-557, cp_finish_decl can call check_initializer even in
a template for a constexpr initializer. That ultimately leads to
convert_for_assignment and check_address_or_pointer_of_packed_member,
where we crash, because it doesn't expect that the CALL_EXPR is
a function object. Q has a constexpr operator(), but since we're
in a template, q(0) is a CALL_EXPR whose CALL_EXPR_FN is just
a VAR_DECL; it hasn't been converted to Q::operator<int>(&q, 0) yet.
I propose to robustify check_address_or_pointer_of_packed_member.
var-templ74.C has an XFAIL, subject to 107939.
I noticed that our -Waddress-of-packed-member tests weren't testing
member functions, added thus. (I was tempted to check
FUNCTION_POINTER_TYPE_P but that doesn't include METHOD_TYPE.)
PR c++/107938
gcc/c-family/ChangeLog:
* c-warn.cc (check_address_or_pointer_of_packed_member): Check
POINTER_TYPE_P.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1y/var-templ73.C: New test.
* g++.dg/cpp1y/var-templ74.C: New test.
* g++.dg/warn/Waddress-of-packed-member3.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.
|
|
|
|
This translation PR mentioned the description is a little bit weird.
2023-02-23 Jakub Jelinek <jakub@redhat.com>
PR translation/108890
* c.opt (fcontracts): Fix description.
|
|
|
|
This fixes a compile-time hog with UBSan. This only happened in cc1 but
not cc1plus. The problem is ultimately that c_genericize_control_stmt/
STATEMENT_LIST -> walk_tree_1 doesn't use a hash_set to remember visited
nodes, so it kept on recursing for a long time. We should be able to
use the pset that c_genericize created. We just need to use walk_tree
instead of walk_tree_w_d so that the pset is explicit.
PR c/108880
gcc/c-family/ChangeLog:
* c-gimplify.cc (c_genericize_control_stmt) <case STATEMENT_LIST>: Pass
pset to walk_tree_1.
(c_genericize): Call walk_tree with an explicit pset.
gcc/testsuite/ChangeLog:
* c-c++-common/ubsan/pr108880.c: New test.
|
|
|
|
When constructing the specifier string when merging an access attribute
that encodes information about VLA arguments, the string was constructed
in random order by iterating through a hash table. Fix this by iterating
though the list of arguments.
gcc/c-family/Changelog:
PR c/105660
* c-attribs.cc (append_access_attr): Use order of arguments when
construction string.
(append_access_attr_idxs): Rename and make static.
* c-warn.cc (warn_parm_array_mismatch): Add assertion.
gcc/testsuite/ChangeLog:
PR c/105660
* gcc.dg/pr105660-1.c: New test.
* gcc.dg/pr105660-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.
|
|
|
|
In recent years this error has been coming up more because other compilers
don't diagnose it as consistently. So let's add a flag for it, and be more
lenient about cases that aren't likely to cause bugs.
gcc/ChangeLog:
* doc/invoke.texi: Document -Wno-changes-meaning.
gcc/c-family/ChangeLog:
* c.opt: Add -Wno-changes-meaning.
gcc/cp/ChangeLog:
* class.cc (note_name_declared_in_class): Change from permerror to
-Wchanges-meaning pedwarn, forcing -pedantic-errors for most cases.
gcc/testsuite/ChangeLog:
* g++.dg/warn/changes-meaning2.C: New test.
* g++.dg/warn/changes-meaning3.C: New test.
|
|
|
|
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.
|
