| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
We ICE on the simple:
struct X { const X* x = this; };
constexpr const X& x = X{};
where store_init_value initializes 'x' with
&TARGET_EXPR <D.2768, {.x=(const struct X *) &<PLACEHOLDER_EXPR struct X>}>
but we must lifetime-extend via extend_ref_init_temps and we get
_ZGR1x_.x = (const struct X *) &<PLACEHOLDER_EXPR struct X> >>>;, (const struct X &) &_ZGR1x_;
Since 'x' was declared constexpr, we do cxx_constant_init and we hit
the preeval code added in r269003 while evaluating the INIT_EXPR:
_ZGR1x_.x = (const struct X *) &<PLACEHOLDER_EXPR struct X> >>>
but we have no ctx.ctor or ctx.object here so lookup_placeholder won't
find anything that could replace X and we ICE on
7861 /* A placeholder without a referent. We can get here when
7862 checking whether NSDMIs are noexcept, or in massage_init_elt;
7863 just say it's non-constant for now. */
7864 gcc_assert (ctx->quiet);
because cxx_constant_init means !ctx->quiet. It's not correct that
there isn't a referent. I think the following patch is a pretty
straightforward fix: pass the _ZGR var down to maybe_constant_init so
that it can replace the PLACEHOLDER_EXPR with _ZGR1x_.
The commented assert in the test doesn't pass: we complain that _ZGR1x_
isn't a constexpr variable because we don't implement DR2126 (PR101588).
PR c++/107079
gcc/cp/ChangeLog:
* call.cc (set_up_extended_ref_temp): Pass var to maybe_constant_init.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/constexpr-nsdmi2.C: New test.
|
|
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.
|
|
For standard excess precision, like the C FE we parse floating
point constants as EXCESS_PRECISION_EXPR of promoted REAL_CST
rather than the nominal REAL_CST, and as the following testcase
shows the constants might need mangling.
The following patch mangles those as fold_convert of the REAL_CST
to EXCESS_PRECISION_EXPR type, i.e. how they were mangled before.
I'm not really sure EXCESS_PRECISION_EXPR can appear elsewhere
in expressions that would need mangling, tried various testcases
but haven't managed to come up with one. If that is possible,
we'd keep ICEing on it without/with this patch, and the big question
is how to mangle those; they could be mangled as casts from the
promoted type back to nominal, but then in the mangled expressions
one could see the effects of excess precision. Until we have
a reproducer, that is just theoretical though.
2023-02-09 Jakub Jelinek <jakub@redhat.com>
PR c++/108698
* mangle.cc (write_expression, write_template_arg): Handle
EXCESS_PRECISION_EXPR with REAL_CST operand as
write_template_arg_literal on fold_convert of the REAL_CST
to EXCESS_PRECISION_EXPR type.
* g++.dg/cpp0x/pr108698.C: New test.
|
|
|
|
After r13-5684-g59e0376f607805 the (pruned) callee of a non-dependent
CALL_EXPR is a bare FUNCTION_DECL rather than ADDR_EXPR of FUNCTION_DECL.
This innocent change revealed that cp_tree_equal doesn't first check
dependence of a CALL_EXPR before treating a FUNCTION_DECL callee as a
dependent name, which leads to us incorrectly accepting the first two
testcases below and rejecting the third:
* In the first testcase, cp_tree_equal incorrectly returns true for
the two non-dependent CALL_EXPRs f(0) and f(0) (whose CALL_EXPR_FN
are different FUNCTION_DECLs) which causes us to treat #2 as a
redeclaration of #1.
* Same issue in the second testcase, for f<int*>() and f<char>().
* In the third testcase, cp_tree_equal incorrectly returns true for
f<int>() and f<void(*)(int)>() which causes us to conflate the two
dependent specializations A<decltype(f<int>()(U()))> and
A<decltype(f<void(*)(int)>()(U()))>.
This patch fixes this by making called_fns_equal treat two callees as
dependent names only if the overall CALL_EXPRs are dependent, via a new
convenience function call_expr_dependent_name that is like dependent_name
but also checks dependence of the overall CALL_EXPR.
PR c++/107461
gcc/cp/ChangeLog:
* cp-tree.h (call_expr_dependent_name): Declare.
* pt.cc (iterative_hash_template_arg) <case CALL_EXPR>: Use
call_expr_dependent_name instead of dependent_name.
* tree.cc (call_expr_dependent_name): Define.
(called_fns_equal): Adjust to take two CALL_EXPRs instead of
CALL_EXPR_FNs thereof. Use call_expr_dependent_name instead
of dependent_name.
(cp_tree_equal) <case CALL_EXPR>: Adjust call to called_fns_equal.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/overload5.C: New test.
* g++.dg/cpp0x/overload5a.C: New test.
* g++.dg/cpp0x/overload6.C: New test.
|
|
|
|
In this test case, we find ourselves evaluating 't' which is
((const struct carray *) this)->data_[VIEW_CONVERT_EXPR<long int>(index)]
in cxx_eval_array_reference. ctx->object is non-null, a RESULT_DECL, so
we replace it with 't':
new_ctx.object = t; // result_decl replaced
and then we go to cxx_eval_constant_expression to evaluate an
AGGR_INIT_EXPR, where we end up evaluating an INIT_EXPR (which is in the
body of the constructor for seed_or_index):
((struct seed_or_index *) this)->value_ = NON_LVALUE_EXPR <0>
whereupon in cxx_eval_store_expression we go to the probe loop
where the 'this' is evaluated to
ze_set.tables_.first_table_.data_[0]
so the 'object' is ze_set, but that isn't in ctx->global->get_value_ptr
so we fail with a bogus error. ze_set is not there because it comes
from a different constexpr context (it's not in cv_cache either).
The problem started with r12-2304 where I added the new_ctx.object
replacement. That was to prevent a type mismatch: the type of 't'
and ctx.object were different.
It seems clear that we shouldn't have replaced ctx.object here.
The cxx_eval_array_reference I mentioned earlier is called from
cxx_eval_store_expression:
6257 init = cxx_eval_constant_expression (&new_ctx, init, vc_prvalue,
6258 non_constant_p, overflow_p);
which already created a new context, whose .object we should be
using unless, for instance, INIT contained a.b and we're evaluating
the 'a' part, which I think was the case for r12-2304; in that case
ctx.object has to be something different.
It no longer seems necessary to replace new_ctx.object (likely due to
changes in empty class handling).
PR c++/108158
gcc/cp/ChangeLog:
* constexpr.cc (cxx_eval_array_reference): Don't replace
new_ctx.object.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1y/constexpr-108158.C: New test.
|
|
Here the ahead-of-time overload set pruning in finish_call_expr is
unintentionally returning a CALL_EXPR whose (pruned) callee is wrapped
in an ADDR_EXPR, despite the original callee not being wrapped in an
ADDR_EXPR. This ends up causing a bogus declaration mismatch error in
the below testcase because the call to min in #1 gets expressed as a
CALL_EXPR of ADDR_EXPR of FUNCTION_DECL, whereas the level-lowered call
to min in #2 gets expressed instead as a CALL_EXPR of FUNCTION_DECL.
This patch fixes this by stripping the spurious ADDR_EXPR appropriately.
Thus the first call to min now also gets expressed as a CALL_EXPR of
FUNCTION_DECL, matching the behavior before r12-6075-g2decd2cabe5a4f.
PR c++/107461
gcc/cp/ChangeLog:
* semantics.cc (finish_call_expr): Strip ADDR_EXPR from
the selected callee during overload set pruning.
gcc/testsuite/ChangeLog:
* g++.dg/template/call9.C: New test.
|
|
Here we're crashing from check_bases_and_members due to
CLASSTYPE_DESTRUCTOR being an OVERLOAD which, due to the pruning
performed by add_method, should only happen if there is no viable
destructor or the destructor is ambiguous because of unsatisfied
or ambiguous constraints.
This patch fixes this by making check_bases_and_members naturally handle
CLASSTYPE_DESTRUCTOR being an OVERLOAD. It's then convenient to prune
the OVERLOAD after effectively diagnosing the overload resolution
failure in check_methods.
PR c++/96745
gcc/cp/ChangeLog:
* class.cc (check_methods): Diagnose an unviable OVERLOAD
set for CLASSTYPE_DESTRUCTOR differently from an ambiguous one.
Then prune the OVERLOAD to a single function.
(check_bases_and_members): Handle CLASSTYPE_DESTRUCTOR being
an OVERLOAD when calling deduce_noexcept_on_destructor.
Document why it has to be called before check_methods.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-dtor1.C: New test.
|
|
In check_methods we're unnecessarily checking satisfaction for all
constructors and assignment operators, even those that don't look like
copy/move special members. In the testcase below this manifests as an
unstable satisfaction error because the satisfaction result is first
determined to be false during check_methods (since A<int> is incomplete
at this point) and later true after completion of A<int>.
This patch fixes this simply by swapping the order of the
constraint_satisfied_p and copy/move_fn_p tests.
PR c++/108579
gcc/cp/ChangeLog:
* class.cc (check_methods): Swap order of constraints_satisfied_p
and copy/move_fn_p tests.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-pr108579.C: New test.
|
|
|
|
Here we crash in the middle end because warn_logical_operator calls
build_range_check which calls various fold_* functions and those
don't work too well when we're still processing template trees. For
instance here we crash because we're converting a RECORD_TYPE to bool.
At this point VIEW_CONVERT_EXPR<struct Foo>(b) hasn't yet been converted
to Foo::operator bool (&b).
I was excited to fix this with instantiation_dependent_expression_p
which can now be called from c-family/ as well, but the problem isn't
that the expression is dependent. So, p_t_d it is.
PR c++/107755
gcc/cp/ChangeLog:
* call.cc (build_new_op): Don't call warn_logical_operator when
processing a template.
gcc/testsuite/ChangeLog:
* g++.dg/warn/Wlogical-op-4.C: New test.
|
|
evaluation [PR108607]
While potential_constant_expression_1 handled most of OMP_* codes (by saying that
they aren't potential constant expressions), OMP_SCOPE was missing in that list.
I've also added OMP_SCAN, though that is less important (similarly to OMP_SECTION
it ought to appear solely inside of OMP_{FOR,SIMD} resp. OMP_SECTIONS).
As the testcase shows, it isn't enough, potential_constant_expression_1
can catch only some cases, as soon as one uses switch or ifs where at least
one of the possible paths could be constant expression, we can run into the
same codes during cxx_eval_constant_expression, so this patch handles those
there as well.
2023-02-01 Jakub Jelinek <jakub@redhat.com>
PR c++/108607
* constexpr.cc (cxx_eval_constant_expression): Handle OMP_*
and OACC_* constructs as non-constant.
(potential_constant_expression_1): Handle OMP_SCAN and OMP_SCOPE.
* g++.dg/gomp/pr108607.C: New test.
|
|
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.
|
|
|
|
We also need to split up a CONSTRUCTOR in cp_genericize_init if we need to
add extra copy constructor calls to deal with CWG2403.
PR c++/108559
gcc/cp/ChangeLog:
* cp-gimplify.cc (any_non_eliding_target_exprs): New.
(cp_genericize_init): Check it.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1z/aggr-base13.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.
|
|
|
|
In this PR, we are crashing because we've encountered a UDL where a
string-literal is expected. This patch makes the parser reject string
and character UDLs in all places where the grammar requires a
string-literal and not a user-defined-string-literal.
I've introduced two new wrappers; the existing cp_parser_string_literal
was renamed to cp_parser_string_literal_common and should not be called
directly. finish_userdef_string_literal is renamed from
cp_parser_userdef_string_literal.
PR c++/105300
gcc/c-family/ChangeLog:
* c-pragma.cc (handle_pragma_message): Warn for CPP_STRING_USERDEF.
gcc/cp/ChangeLog:
* parser.cc: Remove unnecessary forward declarations.
(cp_parser_string_literal): New wrapper.
(cp_parser_string_literal_common): Renamed from
cp_parser_string_literal. Add a bool parameter. Give an error when
UDLs are not permitted.
(cp_parser_userdef_string_literal): New wrapper.
(finish_userdef_string_literal): Renamed from
cp_parser_userdef_string_literal.
(cp_parser_primary_expression): Call cp_parser_userdef_string_literal
instead of cp_parser_string_literal.
(cp_parser_linkage_specification): Move a variable declaration closer
to its first use.
(cp_parser_static_assert): Likewise.
(cp_parser_operator): Call cp_parser_userdef_string_literal instead of
cp_parser_string_literal.
(cp_parser_asm_definition): Move a variable declaration closer to its
first use.
(cp_parser_asm_specification_opt): Move variable declarations closer to
their first use.
(cp_parser_asm_operand_list): Likewise.
(cp_parser_asm_clobber_list): Likewise.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/udlit-error1.C: New test.
|
|
[PR108503]
My recent change to deduce structured binding vars earlier caused the following
invalid testcase to ICE. The problem is that because at cp_convert_omp_range_for
when !processing_template_decl we aren't yet ready to finalize the structured bindings
(e.g. can't emit there associated code) but need to deduce types of the vars so that
we don't get errors if we parse invalid uses of those vars in inner loops of the
collapsed construct. This is done by temporarily bumping processing_template_decl
around the call to cp_finish_decomp. Unfortunately, as we can't finalize it yet,
the types of the vars will be deduced, but their DECL_VALUE_EXPR is not finalized
yet and if say fold_for_warn tries to constant expression evaluate them, it
recurses on DECL_VALUE_EXPR and ICEs because it sees e.g. ARRAY_REF (with NULL type)
on a VAR_DECL with class type.
The following patch works around that by temporarily hiding the DECL_VALUE_EXPRs
by clearing DECL_HAS_VALUE_EXPR_P in that case during cp_convert_omp_range_for
and arranging for cp_finish_omp_range_for to set it back before doing the
final cp_finish_decomp.
2023-01-25 Jakub Jelinek <jakub@redhat.com>
PR c++/108503
* parser.cc (cp_convert_omp_range_for): If cp_finish_decomp has been
called in !processing_template_decl with processing_template_decl
temporarily set, clear DECL_HAS_VALUE_EXPR_P on the vars temporarily.
(cp_finish_omp_range_for): And set it back again here.
* g++.dg/gomp/pr108503.C: New test.
|
|
|
|
Before the P1169R4 changes, operator () of a lambda was
always a method, so it was fine to pass method_p = 1 unconditionally,
but it isn't always the case, so this patch adds a check for whether
it is a method or nor.
2023-01-25 Jakub Jelinek <jakub@redhat.com>
PR c++/108525
* mangle.cc (write_closure_type_name): Don't assume all
lambda operator() fns are methods.
* g++.dg/cpp23/static-operator-call5.C: New test.
|
|
|
|
Since r11-2095 we pass flags to cp_lexer_get_preprocessor_token, and
cp_lexer_new_main passes C_LEX_STRING_NO_JOIN when lexing most of the
translation unit, but doesn't do that for the very first token; as a
result, if the first token is a string literal, we try to join strings and
get confused if that encounters a pragma.
PR c++/108504
gcc/cp/ChangeLog:
* parser.cc (cp_lexer_new_main): Pass C_LEX_STRING_NO_JOIN for first
token, too.
gcc/testsuite/ChangeLog:
* g++.dg/ext/pragma1.C: New test.
|
|
tsubst_lambda_expr uses build_memfn_type to build a METHOD_TYPE for the new
lamba op(). This is not what we want for a C++23 static op(), but since we
also use that METHOD_TYPE to communicate the closure type down to
tsubst_function_decl, let's wait and turn it back at that point.
PR c++/108526
gcc/cp/ChangeLog:
* pt.cc (tsubst_function_decl): Handle static lambda.
gcc/testsuite/ChangeLog:
* g++.dg/cpp23/static-operator-call5.C: New test.
|
|
As reported by Andrew Pinski, structured bindings (with the exception
of the ones using std::tuple_{size,element} and get which are really
standalone variables in addition to the binding one) also use
DECL_VALUE_EXPR and needs the same treatment in static initializers.
On Sun, Jan 22, 2023 at 07:19:07PM -0500, Jason Merrill wrote:
> Though, actually, why not instead fix expand_expr_real_1 (and staticp) to
> look through DECL_VALUE_EXPR?
Doing it when emitting the initializers seems to be too late to me,
we in various spots try to put parts of the static var DECL_INITIAL expressions
into the IL, or e.g. for varpool purposes remember which vars are referenced
there.
This patch moves it to record_reference, which is called from varpool_node::analyze
and so about the same time as gimplification of the bodies which also
replaces DECL_VALUE_EXPRs.
2023-01-24 Jakub Jelinek <jakub@redhat.com>
PR c++/108474
* cgraphbuild.cc: Include gimplify.h.
(record_reference): Replace VAR_DECLs with DECL_HAS_VALUE_EXPR_P with
their corresponding DECL_VALUE_EXPR expressions after unsharing.
* cp-gimplify.cc (cp_fold_r): Revert 2023-01-19 changes.
* g++.dg/cpp1z/decomp57.C: New test.
* g++.dg/cpp1z/decomp58.C: New test.
|
|
In r13-2978 I tried to eliminate TARGET_EXPR around TARGET_EXPR by
discarding the outer one, but as in this testcase that breaks if the
TARGET_EXPR_SLOT of the outer one is used elsewhere. But it should always
be safe to strip the inner one; if its slot were reused, there would be a
COMPOUND_EXPR around the TARGET_EXPR.
For 107329, if we're setting *walk_subtrees, we also need to fold
TARGET_EXPR_CLEANUP.
PR c++/107303
PR c++/107329
gcc/cp/ChangeLog:
* cp-gimplify.cc (cp_fold_r) [TARGET_EXPR]: In case of double
TARGET_EXPR, keep the outer one instead of the inner one.
(maybe_replace_decl): New.
gcc/testsuite/ChangeLog:
* g++.dg/ext/builtin-shufflevector-5.C: New test.
* g++.dg/init/new51.C: New test.
|
|
|
|
With -ffold-simple-inlines, we turn calls to std::move into the static_cast
equivalent. In this testcase, this exposes the FindResult temporary to copy
elision which is not specified by the standard, through an optimization in
gimplify_modify_expr_rhs. Since the type is not TREE_ADDRESSABLE, this is
not detectable by the user, so we just need to soften the assert.
PR c++/107267
gcc/cp/ChangeLog:
* cp-gimplify.cc (cp_gimplify_init_expr): Allow unexpected elision
of trivial types.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/move2.C: New test.
|
|
We shouldn't emit "right operand of comma operator has no effect"
when that comma operator was created by the compiler for "new int{}".
convert_to_void/COMPOUND_EXPR already checks warning_suppressed_p so
we can just suppress -Wunused-value.
PR c++/107797
gcc/cp/ChangeLog:
* cvt.cc (ocp_convert): copy_warning when creating a new
COMPOUND_EXPR.
* init.cc (build_new_1): Suppress -Wunused-value on
compiler-generated COMPOUND_EXPRs.
gcc/testsuite/ChangeLog:
* g++.dg/warn/Wunused-value-1.C: New test.
|
|
The transformation done by r13-4564 to use the iterator constructor instead
of the initializer-list constructor breaks if the iterator pointers are
themselves treated as elements of an initializer-list, so check for that.
PR c++/108195
gcc/cp/ChangeLog:
* call.cc (build_user_type_conversion_1): Check whether the
iterators also find a list ctor.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/initlist-vect2.C: New test.
|
|
In r13-4469 we started to build the RESULT_DECL in grokdeclarator, while we
still know the location of the return type. But in this testcase, we hit
that code again when parsing the explicit instantiation, and clobber the
DECL_RESULT that was previously used in parsing the function. So, only set
DECL_RESULT if it isn't already set.
PR c++/108496
gcc/cp/ChangeLog:
* decl.cc (grokdeclarator): Check whether DECL_RESULT is already
set.
gcc/testsuite/ChangeLog:
* g++.dg/template/explicit-instantiation5.C: New test.
|
|
This PR points out a case where we are not extending the lifetime of a
temporary when the subobject is denoted by a pointer-to-member operation.
These rules were clarified in C++20 by CWG1299.
There are other cases that also need to be handled under CWG1299, but are
not fixed by this patch.
PR c++/53288
DR 1299
gcc/cp/ChangeLog:
* call.cc (extend_ref_init_temps_1): Handle ptrmem expression.
gcc/testsuite/ChangeLog:
* g++.dg/init/lifetime4.C: New test.
|
|
|
|
[PR108437]
As the following testcases shows, when adding static operator[]
support I've missed that the 2 build_min_non_dep_op_overload functions
need to be adjusted. The first one we only use for the single index
case, but as cp_tree_code_length (ARRAY_REF) is 2, we were running
into an assertion there which compared nargs and expected_nargs.
For ARRAY_REF, the operator[] is either a non-static member or newly
static member, never out of class and for the static member case
if user uses single index the operator[] needs to have a single
argument as well, but the function is called with 2 - the object
it is invoked on and the index. We need to evaluate side-effects
of the object and use just a single argument in the call - the index.
The other build_min_non_dep_op_overload overload has been added
solely for ARRAY_REF - CALL_EXPR is the other operator that accepts
variable number of operands but that one goes through different
routines. There we asserted it is a METHOD_TYPE, so again
we shouldn't assert that but handle the case when it is not one
by making sure object's side-effects are evaluated if needed and
passing all the index arguments to the static operator[].
2023-01-19 Jakub Jelinek <jakub@redhat.com>
PR c++/108437
* cp-tree.h (keep_unused_object_arg): Declare.
* call.cc (keep_unused_object_arg): No longer static.
* tree.cc (build_min_non_dep_op_overload): Handle ARRAY_REF
with overload being static member function.
* g++.dg/cpp23/subscript12.C: New test.
* g++.dg/cpp23/subscript13.C: New test.
|
|
[PR53932]
For anonymous union members we create artificial VAR_DECLs which
have DECL_VALUE_EXPR for the actual COMPONENT_REF. That works
just fine inside of functions (including global dynamic constructors),
because during gimplification such VAR_DECLs are gimplified as
their DECL_VALUE_EXPR. This is also done during regimplification.
But references to these artificial vars in DECL_INITIAL expressions
aren't ever replaced by the DECL_VALUE_EXPRs, so we end up either
with link failures like on the testcase below, or worse ICEs with
LTO.
The following patch fixes those during cp_fully_fold_init where we
already walk all the trees (!data->genericize means that
function rather than cp_fold_function).
2023-01-19 Jakub Jelinek <jakub@redhat.com>
PR c++/53932
* cp-gimplify.cc (cp_fold_r): During cp_fully_fold_init replace
DECL_ANON_UNION_VAR_P VAR_DECLs with their corresponding
DECL_VALUE_EXPR.
* g++.dg/init/pr53932.C: New test.
|
|
|
|
|
|
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.
|
|
precision [PR108285]
On the following testcase trunk emits a false positive warning on ia32.
convert_like_internal is there called with type of double and
expr EXCESS_PRECISION_EXPR with float type with long double operand
2.L * (long double) x.
Now, for the code generation we do the right thing, cp_convert
to double from that 2.L * (long double) x, but we call even
cp_convert_and_check with that and that emits the -Wfloat-conversion
warning. Looking at what the C FE does in this case, it calls
convert_and_check with the EXCESS_PRECISION_EXPR expression rather
than its operand, and essentially uses the operand for code generation
and EXCESS_PRECISION_EXPR itself for warnings.
The following patch does that too for the C++ FE.
2023-01-13 Jakub Jelinek <jakub@redhat.com>
PR c++/108285
* cvt.cc (cp_convert_and_check): For EXCESS_PRECISION_EXPR
use its operand except that for warning purposes use the original
EXCESS_PRECISION_EXPR.
* call.cc (convert_like_internal): Only look through
EXCESS_PRECISION_EXPR when calling cp_convert, not when calling
cp_convert_and_check.
* g++.dg/warn/pr108285.C: New test.
|
|
|
|
!processing_template_decl [PR108047]
The last testcase in this patch ICEs, because
maybe_init_list_as_range -> maybe_init_list_as_array
calls maybe_constant_init in:
/* Don't do this if the conversion would be constant. */
first = maybe_constant_init (first);
if (TREE_CONSTANT (first))
return NULL_TREE;
but maybe_constant_init shouldn't be called when processing_template_decl.
While we could replace that call with fold_non_dependent_init, my limited
understanding is that this is an optimization and even if we don't optimize
it when processing_template_decl, build_user_type_conversion_1 will be
called again during instantiation with !processing_template_decl if it is
every instantiated and we can do the optimization only then.
2023-01-09 Jakub Jelinek <jakub@redhat.com>
PR c++/105838
PR c++/108047
PR c++/108266
* call.cc (maybe_init_list_as_range): Always return NULL_TREE if
processing_template_decl.
* g++.dg/tree-ssa/initlist-opt2.C: New test.
* g++.dg/tree-ssa/initlist-opt3.C: New test.
|
|
|
|
When tentatively parsing what is really an elaborated-type-specifier
containing a template-id first as a class-specifier, we may form a
CPP_TEMPLATE_ID token that later gets reused by the fallback parse if
the tentative parse fails. These special tokens also capture the access
checks that have been deferred while parsing the template-id. But here
we form such a token when the access check state is dk_no_check, and so
the token captures no access checks. This effectively bypasses access
checking for the template-id during the subsequent parse as an
elaborated-type-specifier.
This patch fixes this by using dk_deferred instead of dk_no_check when
parsing the class name of a class-head.
PR c++/108275
gcc/cp/ChangeLog:
* parser.cc (cp_parser_class_head): Use dk_deferred instead of
dk_no_check when parsing the class name.
gcc/testsuite/ChangeLog:
* g++.dg/parse/access14.C: New test.
|
|
The comment in the loop says that we shouldn't add a map clause if such
a clause exists already, but the loop was actually using OMP_CLAUSE_DECL
on any clause. Target construct can have various clauses which don't
have OMP_CLAUSE_DECL at all (e.g. nowait, device or if) or clause
where it means something different (e.g. privatization clauses, allocate,
depend).
So, only check OMP_CLAUSE_DECL on OMP_CLAUSE_MAP clauses.
2023-01-05 Jakub Jelinek <jakub@redhat.com>
PR c++/108286
* semantics.cc (finish_omp_target_clauses): Ignore clauses other than
OMP_CLAUSE_MAP.
* testsuite/libgomp.c++/pr108286.C: New test.
|
|
|
|
We typically ignore mark_used failure when in a non-SFINAE context for
sake of better error recovery. But in mark_single_function we're
instead ignoring mark_used failure in a SFINAE context, which ends up
causing the second static_assert here to incorrectly fail.
PR c++/108282
gcc/cp/ChangeLog:
* decl2.cc (mark_single_function): Ignore mark_used failure
only in a non-SFINAE context rather than in a SFINAE one.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-requires34.C: New test.
|
