Normally cp_parser_base_clause prevents unexpanded packs, but in a lambda
check_for_bare_parameter_packs allows it. Then we weren't finding the
pack when scanning the lambda body.
This doesn't fix a valid variant like
template <class... Ts> void sink (Ts&&...);
template <class... Ts>
void f() {
sink ([] { struct S : Ts { }; }...);
}
int main() {
f<int>();
}
but that's a much bigger project.
gcc/cp/ChangeLog:
PR c++/100006
* pt.c (find_parameter_packs_r) [TAG_DEFN]: Look into bases.
gcc/testsuite/ChangeLog:
PR c++/100006
* g++.dg/cpp0x/lambda/lambda-variadic13.C: New test.
A TEMPLATE_INFO is a natural fit for what LAMBDA_EXPR_REGENERATED_FROM
and LAMBDA_EXPR_REGENERATING_TARGS hold, so let's use it instead.
gcc/cp/ChangeLog:
* cp-tree.h (LAMBDA_EXPR_REGENERATED_FROM)
(LAMBDA_EXPR_REGENERATING_TARGS): Replace these with ...
(LAMBDA_EXPR_REGEN_INFO): ... this.
(tree_lambda_expr::regenerated_from)
(tree_lambda_expr::regenerating_targs): Replace these with ...
(tree_lambda_expr::regen_info): ... this.
* constraint.cc (satisfy_declaration_constraints): Adjust
accordingly.
* lambda.c (build_lambda_expr): Likewise.
* pt.c (regenerated_lambda_fn_p): Likewise.
(most_general_lambda): Likewise.
(tsubst_lambda_expr): Likewise.
__dp_sign precision indicates that we found out what iterator comes first or
last in the range. __dp_sign_max_size is the same plus it gives the information
of the max size of the range that is to say the max_size value such that
distance(lhs, rhs) < max_size.
Thanks to this additional information we are able to tell when a copy of n elements
to that range will fail even if we do not know exactly how large it is.
This patch makes sure that we are properly using this information.
libstdc++-v3/ChangeLog:
PR libstdc++/99402
* include/debug/helper_functions.h (__can_advance(_InputIterator,
const std::pair<_Diff, _Distance_precision>&, int)): New.
(__can_advance(const _Safe_iterator<>&,
const std::pair<_Diff, _Distance_precision>&, int)): New.
* include/debug/macros.h (__glibcxx_check_can_increment_dist): New,
use latter.
(__glibcxx_check_can_increment_range): Adapt to use latter.
(__glibcxx_check_can_decrement_range): Likewise.
* include/debug/safe_iterator.h
(_Safe_iterator<>::_M_can_advance(const std::pair<_Diff, _Distance_precision>&,
int)): New.
(__can_advance(const _Safe_iterator<>&,
const std::pair<_Diff, _Distance_precision>&, int)): New.
* include/debug/safe_iterator.tcc
(_Safe_iterator<>::_M_can_advance(const std::pair<_Diff, _Distance_precision>&,
int)): New.
(_Safe_iterator<>::_M_valid_range(const _Safe_iterator<>&,
std::pair<difference_type, _Distance_precision>&, bool)): Adapt for
__dp_sign_max_size.
(__copy_move_a): Adapt to use __glibcxx_check_can_increment_dist.
(__copy_move_backward_a): Likewise.
(__equal_aux): Likewise.
* include/debug/stl_iterator.h (__can_advance(const std::reverse_iterator<>&,
const std::pair<_Diff, _Distance_precision>&, int)): New.
(__can_advance(const std::move_iterator<>&,
const std::pair<_Diff, _Distance_precision>&, int)): New.
* testsuite/25_algorithms/copy/debug/99402.cc: New test.
If a toolchain is configured with --with-cpu=X and gcc is
then run with an explicit -march=Y option, we ignore the
X cpu setting and tune for generic Y code:
if (!selected_cpu)
{
if (selected_arch)
{
------> selected_cpu = &all_cores[selected_arch->ident];
aarch64_isa_flags = arch_isa;
explicit_arch = selected_arch->arch;
}
else
{
/* Get default configure-time CPU. */
selected_cpu = aarch64_get_tune_cpu (aarch64_none);
aarch64_isa_flags = TARGET_CPU_DEFAULT >> 6;
}
if (selected_tune)
explicit_tune_core = selected_tune->ident;
}
…
if (!selected_tune)
selected_tune = selected_cpu;
But after a push/pop_options pair, we simply did:
selected_tune = aarch64_get_tune_cpu (ptr->x_explicit_tune_core);
In the above scenario, ptr->x_explicit_tune_core is aarch64_none,
so we fall back on the default configure-time CPU. This means
that before the push_options we tuned for generic Y but after
the pop_options we tuned for X.
This was picked up by an assertion failure in cl_optimization_compare.
The ICE itself is a GCC 11 regression, but the problem that it shows
up is much older.
gcc/
* config/aarch64/aarch64.c (aarch64_option_restore): If the
architecture was specified explicitly and the tuning wasn't,
tune for the architecture rather than the configured default CPU.
When we have a member function with auto parameter like this:
struct S {
void f(auto);
};
cp_parser_member_declaration -> grokfield produces a FUNCTION_DECL
"void S::foo(auto:1)", and then finish_fully_implicit_template turns
that FUNCTION_DECL into a TEMPLATE_DECL. The bug here is that we only
call cp_parser_save_default_args for a FUNCTION_DECL. As a consequence,
abbrev10.C is rejected because we complain that the default argument has
not been defined, and abbrev11.C ICEs, because we don't re-parse the
delayed noexcept, so the DEFERRED_PARSE tree leaks into tsubst* where we
crash. This patch fixes both issues.
gcc/cp/ChangeLog:
PR c++/99806
* parser.c (cp_parser_member_declaration): Call
cp_parser_save_default_args even for function templates. Use
STRIP_TEMPLATE on the declaration we're passing.
gcc/testsuite/ChangeLog:
PR c++/99806
* g++.dg/concepts/abbrev10.C: New test.
* g++.dg/concepts/abbrev11.C: New test.
Not all hosts can link static executables. It depends on which
development libraries are installed.
gcc/testsuite/
* gcc.target/aarch64/pr70398.c: Require a target that can link
static executables.
These tests are passing on all my runs, and it looks like
they are for Christophe's runs too. We can reapply with a
tighter target selector if this is still a problem for some
configurations.
gcc/testsuite/
* g++.target/aarch64/bfloat_cpp_typecheck.C: Remove XFAILs.
With SVE we can vectorise an additional loop. (Well, more really,
since the count doesn't include epilogue loops for SVE.)
gcc/testsuite/
* gfortran.dg/vect/vect-8.f90: Expect 24 loops to be vectorized
with SVE.
This patch adds XFAILs for some tests that fail with variable-length
vectors.
For pr96573.c I'd wondered about instead extending the regexp.
The code we generate isn't very good though, so it doesn't seem
worth matching. (Fixing the bad code is on the todo list.)
gcc/testsuite/
* g++.dg/tree-ssa/pr83518.C: XFAIL for vect_variable_length.
* gcc.dg/pr96573.c: Likewise.
* gcc.dg/tree-ssa/pr84512.c: Likewise.
* gcc.dg/vect/bb-slp-43.c: Likewise.
* gcc.dg/vect/slp-reduc-11.c: Likewise.
This test was failing on aarch64 targets because we inlined the
test function into main, making it vectorisable.
gcc/testsuite/
* gcc.dg/vect/pr65947-7.c: Add a noipa attribute. Expect the
loop to vectorized if vect_fold_extract_last.
mem-shift-canonical.c started failing after the fix for PR97684.
We used to generate things like:
add x7, x1, x5, lsl 2 // 54 [c=4 l=4] *add_lsl_di
ld1 {v0.s}[1], [x7] // 18 [c=4 l=4] aarch64_simd_vec_setv4si/2
where the add_lsl_di was generated by LRA. After PR97684 we generate:
ldr s1, [x1, x5, lsl 2] // 17 [c=4 l=4] *zero_extendsidi2_aarch64/3
ins v0.s[1], v1.s[0] // 18 [c=4 l=4] aarch64_simd_vec_setv4si/0
Which one is better is an interesting question. However, it was really
only a fluke that we generated the original code. The pseudo that
becomes s1 in the new code above has a REG_EQUIV note:
(insn 17 16 18 3 (set (reg:SI 111 [ MEM[(int *)b_25(D) + ivtmp.9_30 * 4] ])
(mem:SI (plus:DI (mult:DI (reg:DI 101 [ ivtmp.9 ])
(const_int 4 [0x4]))
(reg/v/f:DI 105 [ b ])) [2 MEM[(int *)b_25(D) + ivtmp.9_30 * 4]+0 S4 A32])) "gcc/testsuite/gcc.target/aarch64/mem-shift-canonical.c":21:18 52 {*movsi_aarch64}
(expr_list:REG_EQUIV (mem:SI (plus:DI (mult:DI (reg:DI 101 [ ivtmp.9 ])
(const_int 4 [0x4]))
(reg/v/f:DI 105 [ b ])) [2 MEM[(int *)b_25(D) + ivtmp.9_30 * 4]+0 S4 A32])
(nil)))
(insn 18 17 19 3 (set (reg:V4SI 109 [ MEM[(int *)a_23(D) + ivtmp.9_30 * 4] ])
(vec_merge:V4SI (vec_duplicate:V4SI (reg:SI 111 [ MEM[(int *)b_25(D) + ivtmp.9_30 * 4] ]))
(subreg:V4SI (reg:SI 110 [ MEM[(int *)a_23(D) + ivtmp.9_30 * 4] ]) 0)
(const_int 2 [0x2]))) "gcc/testsuite/gcc.target/aarch64/mem-shift-canonical.c":21:18 1683 {aarch64_simd_vec_setv4si}
(expr_list:REG_DEAD (reg:SI 111 [ MEM[(int *)b_25(D) + ivtmp.9_30 * 4] ])
(expr_list:REG_DEAD (reg:SI 110 [ MEM[(int *)a_23(D) + ivtmp.9_30 * 4] ])
(nil))))
Before the PR, IRA didn't allocate a register to r111 and so LRA
rematerialised the REG_EQUIV note inside insn 18, leading to the
reload. Now IRA allocates a register instead.
So I think this is working as expected, in the sense that IRA is now
doing what the backend asked it to do. If the backend prefers the first
version (and it might not), it needs to do more than it's currently
doing to promote the use of lane loads. E.g. it should probably have a
combine define_split that splits the combination of insn 17 and insn 18
into an ADD + an LD1.
I think for now the best thing is to use a different approach to
triggering the original bug. The asm in the new test ICEs with the
r11-2903 LRA patch reverted and passes with it applied.
gcc/testsuite/
* gcc.target/aarch64/mem-shift-canonical.c: Use an asm instead
of relying on vectorisation.
This patch XFAILs the remaining regressions in PR87763. We should
still fix them at some point, but that's not GCC 11 material.
gcc/testsuite/
PR target/87763
* gcc.target/aarch64/insv_1.c: XFAIL two scan tests.
For the reasons discussed in PR78314, ieee_support_halting
doesn't work correctly for arm* and aarch64*. I think the
easiest thing is to skip these tests until the PR is fixed.
This doesn't mean that the PR is unimportant. It just doesn't
seem useful to have the unpredictable failures described in the
PR trail given that the problem is known and has been analysed.
gcc/testsuite/
PR libfortran/78314
* gfortran.dg/ieee/ieee_6.f90: Skip for arm* and aarch64*.
* gfortran.dg/ieee/ieee_8.f90: Likewise.
gcc.dg/torture/tls/tls-reload-1.c started ICEing for SVE some time
during the GCC 11 cycle (not sure when). The problem is that we
had an output reload on a call_insn, which isn't a supported
combination.
This patch uses LR_REGNUM instead. The resulting "blr x30"
might not perform as well on some CPUs, but in this context
the difference shouldn't be noticeable.
gcc/
* config/aarch64/aarch64.md (tlsdesc_small_sve_<mode>): Use X30
as the temporary register.
I keep forgetting that a constexpr function in C++11 has to be a single
return statement.
libstdc++-v3/ChangeLog:
PR libstdc++/99985
* include/bits/hashtable.h (_Hashtable::_S_nothrow_move()): Fix
to be a valid constexpr function in C++11.
* testsuite/23_containers/unordered_set/cons/99985.cc: New test.
pthread_setspecific second argument is const void *, so that one can
call it even with pointers to const, but the function only stores the
pointer and does nothing else, so the new assumption of -Wmaybe-uninitialized
that functions taking such pointers will read from what those pointers
will point to is wrong. Maybe it would be useful to have some whitelist
of functions that surely don't do that.
Anyway, in this case it is easy to workaround the warning by moving the
pthread_setspecific call after the initialization without slowing anything
down.
2021-04-09 Jakub Jelinek <jakub@redhat.com>
PR libgomp/99984
* team.c (gomp_thread_start): Call pthread_setspecific for
!(defined HAVE_TLS || defined USE_EMUTLS) only after local_thr
has been initialized to avoid false positive warning.
GCC uses TLS common for both public common / BSS and local common / BSS.
This patch reverts to use .comm directive to allocate TLS
common / BSS. This also changes the priority of section selection
to use BSS before data section.
gcc/ChangeLog:
* config/rs6000/rs6000.c (rs6000_xcoff_select_section): Select
TLS BSS before TLS data.
* config/rs6000/xcoff.h (ASM_OUTPUT_TLS_COMMON): Use .comm.
gcc/testsuite/ChangeLog:
* g++.dg/gomp/tls-5.C: Expect tbss failure on AIX.
The <ranges> header currently copies some simple algorithms from
<bits/ranges_algo.h>, which was originally done in order to avoid a
circular dependency with the header. This is no longer an issue since
the latter header now includes <bits/ranges_util.h> instead of all of
<ranges>.
This means we could now just include <bits/ranges_algo.h> and remove the
copied algorithms, but that'd increase the size of <ranges> by ~10%.
And we can't use the corresponding STL-style algorithms here because
they assume input iterators are copyable. So this patch instead
simplifies these copied algorithms, removing their constraints and
unused parameters, and keeps them around. In a subsequent patch we're
going to copy (a simplified version of) ranges::find into <ranges> as
well.
libstdc++-v3/ChangeLog:
* include/std/ranges (__detail::find_if): Simplify.
(__detail::find_if_not): Likewise.
(__detail::min): Remove.
(__detail::mismatch): Simplify.
(take_view::size): Use std::min instead of __detail::min.
While we're modifying elements_view, this also implements the one-line
resolution of LWG 3492.
libstdc++-v3/ChangeLog:
* include/std/ranges (__detail::__returnable_element): New
concept.
(elements_view): Use this concept in its constraints. Add
missing private access specifier.
(elements_view::_S_get_element): Define as per LWG 3502.
(elements_view::operator*, elements_view::operator[]): Use
_S_get_element.
(elements_view::operator++): Remove unnecessary constraint
as per LWG 3492.
* testsuite/std/ranges/adaptors/elements.cc (test05): New test.
If pdflatex runs out of memory the build fails with no hint what's
wrong. This adds another grep command to the makefile so that an
out-of-memory error will result in more information being shown.
As suggested in https://bugzilla.redhat.com/show_bug.cgi?id=1841056
using lualatex can be used as a workaround.
libstdc++-v3/ChangeLog:
* doc/Makefile.am (stamp-pdf-doxygen): Also grep for
out-of-memory error in log file.
* doc/Makefile.in: Regenerate.
Similar to r11-8009 but for /* @} */ comments this time, which should
be /** @} */ for Doxygen to recognize them.
libstdc++-v3/ChangeLog:
* include/bits/random.h: Fix doxygen group commands.
* include/bits/regex_constants.h: Likewise.
* include/tr1/random.h: Likewise.
We currently substitute through a lambda's constraints whenever we
regenerate it via tsubst_lambda_expr. This is the wrong approach
because it can lead to hard errors due to constraints being evaluated
out of order (as in the testcase concepts-lambda17.C below), and because
it doesn't mesh well with the recently added REQUIRES_EXPR_EXTRA_ARGS
mechanism for delaying substitution into requires-expressions, which is
the cause of this PR.
But in order to avoid substituting through a lambda's constraints during
regeneration, we need to be able to get at all in-scope template
parameters and corresponding template arguments during constraint
checking of a lambda's op(). And this information is not easily
available when we need it, it seems.
To that end, the approach that this patch takes is to add two new fields
to LAMBDA_EXPR (and remove one): LAMBDA_EXPR_REGENERATED_FROM
(replacing LAMBDA_EXPR_INSTANTIATED), and LAMBDA_EXPR_REGENERATING_TARGS.
The former allows us to obtain the complete set of template parameters
that are in-scope for a lambda's op(), and the latter gives us all outer
template arguments that were used to regenerate the lambda (analogous to
the TI_TEMPLATE and TI_ARGS of a TEMPLATE_INFO, respectively).
LAMBDA_EXPR_REGENERATING_TARGS is not strictly necessary -- in an
earlier prototype, I walked LAMBDA_EXPR_EXTRA_SCOPE to build up this set
of outer template arguments on demand, but it seems cleaner to do it this
way. (We'd need to walk LAMBDA_EXPR_EXTRA_SCOPE and not DECL/TYPE_CONTEXT
because the latter skips over variable template scopes.)
This patch also renames the predicate instantiated_lambda_fn_p to
regenerated_lambda_fn_p, for sake of consistency with the rest of the
patch which uses "regenerated" instead of "instantiated".
gcc/cp/ChangeLog:
PR c++/99874
* constraint.cc (get_normalized_constraints_from_decl): Handle
regenerated lambdas.
(satisfy_declaration_constraints): Likewise. Check for
dependent args later.
* cp-tree.h (LAMBDA_EXPR_INSTANTIATED): Replace with ...
(LAMBDA_EXPR_REGENERATED_FROM): ... this.
(LAMBDA_EXPR_REGENERATING_TARGS): New.
(tree_lambda_expr::regenerated_from): New data member.
(tree_lambda_expr::regenerating_targs): New data member.
(add_to_template_args): Declare.
(regenerated_lambda_fn_p): Likewise.
(most_general_lambda): Likewise.
* lambda.c (build_lambda_expr): Set LAMBDA_EXPR_REGENERATED_FROM
and LAMBDA_EXPR_REGENERATING_TARGS.
* pt.c (add_to_template_args): No longer static.
(tsubst_function_decl): Unconditionally propagate constraints on
the substituted function decl.
(instantiated_lambda_fn_p): Rename to ...
(regenerated_lambda_fn_p): ... this. Check
LAMBDA_EXPR_REGENERATED_FROM instead of
LAMBDA_EXPR_INSTANTIATED.
(most_general_lambda): Define.
(enclosing_instantiation_of): Adjust after renaming
instantiated_lambda_fn_p.
(tsubst_lambda_expr): Don't set LAMBDA_EXPR_INSTANTIATED. Set
LAMBDA_EXPR_REGENERATED_FROM and LAMBDA_EXPR_REGENERATING_TARGS.
Don't substitute or set constraints on the regenerated lambda.
gcc/testsuite/ChangeLog:
PR c++/99874
* g++.dg/cpp2a/concepts-lambda16.C: New test.
* g++.dg/cpp2a/concepts-lambda17.C: New test.
In the testcase below, we're crashing during constraint checking of the
implicitly generated deduction guides for the nested class template A::B
because we never substitute the outer template arguments (for A) into
the constraint, neither ahead of time nor as part of satisfaction.
Ideally we'd like to avoid substituting into a constraint ahead of
time, but the "flattening" vector 'tsubst_args' is constructed under the
assumption that all outer template arguments are already substituted in,
and eliminating this assumption to yield a flattening vector that
includes outer (generic) template arguments suitable for substituting
into the constraint would be tricky and error-prone. So this patch
takes the approximate approach of substituting the outer arguments into
the constraint ahead of time, so that the subsequent substitution of
'tsubst_args' is coherent and so later satisfaction just works.
gcc/cp/ChangeLog:
PR c++/97679
* pt.c (build_deduction_guide): Document OUTER_ARGS. Substitute
them into the propagated constraints.
gcc/testsuite/ChangeLog:
PR c++/97679
* g++.dg/cpp2a/concepts-ctad3.C: New test.
When looking into PR99420, I have noticed several comment typos.
2021-04-08 Jakub Jelinek <jakub@redhat.com>
* c-warn.c (do_warn_double_promotion): Fix comment typo,
occured -> occurred.
(check_alignment_of_packed_member): Fix a comment typo,
memeber -> member.
(warn_parm_ptrarray_mismatch): Fix comment typos, os -> of
and onless -> unless.
(warn_parm_array_mismatch): Fix comment typos, declaratation
-> declaration and woud -> would. Fix up comment indentation.
This puts the logic for the noexcept-specifier in one place, and then
reuses it elsewhere. This means checking whether the move constructor
can throw doesn't need to do overload resolution and then check whether
some other constructor can throw, we just get the answer directly.
libstdc++-v3/ChangeLog:
* include/bits/hashtable.h (_Hashtable::_S_nothrow_move()):
New function to determine noexcept-specifier for move
constructors.
(_Hashtable): Use _S_nothrow_move() on move constructors.
* testsuite/23_containers/unordered_map/cons/noexcept_move_construct.cc:
Correct static assertion message.
* testsuite/23_containers/unordered_multimap/cons/noexcept_move_construct.cc:
Likewise.
* testsuite/23_containers/unordered_multiset/cons/noexcept_move_construct.cc:
Likewise.
* testsuite/23_containers/unordered_set/cons/noexcept_move_construct.cc:
Likewise.
scan-lto-assembler was looking for the old dump names instead of
the new ones. There are only two uses of this:
gcc.target/nios2/custom-fp-lto.c
gcc.target/aarch64/pr70044.c
Both of them use single source files, so I think they both want
the same behaviour.
gcc/testsuite/
* lib/scanasm.exp (scan-lto-assembler): Update expected name
of dump file.
Some AArch64 tests force -mbig-endian and indirectly include stdint.h.
However, not all OSes support both endiannesses, leading to:
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_get-be.c -O0 (test for excess errors)
UNRESOLVED: gcc.target/aarch64/advsimd-intrinsics/bf16_get-be.c -O1 check-function-bodies test_vget_high_bf16
UNRESOLVED: gcc.target/aarch64/advsimd-intrinsics/bf16_get-be.c -O1 check-function-bodies test_vget_low_bf16
etc. This patch adds an (admittedly special-purpose) target
selector for this.
gcc/
* doc/sourcebuild.texi (stdint_types_mbig_endian): Document.
gcc/testsuite/
* lib/target-supports.exp
(check_effective_target_stdint_types_mbig_endian): New proc.
* gcc.target/aarch64/advsimd-intrinsics/bf16_get-be.c: Require
stdint_types_mbig_endian.
* gcc.target/aarch64/advsimd-intrinsics/bfdot-2.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vdot-3-2.c: Likewise.
The sve/vcond_3.c tests had started to fail after PR97690/99305,
because we were generating:
a = VEC_COND_EXPR <cond, { 0, ... }, { 1, ... }>;
b = a << 15;
instead of:
a = VEC_COND_EXPR <cond, { 0, ... }, { 1<<15, ... }>;
We already have a match.pd rule to handle this kind of thing,
but it didn't handle shifts.
gcc/
* match.pd: Extend vec_cond folds to handle shifts.
Here we were complaining about binding the lvalue reference to the rvalue
result of converting from float to int, but didn't mention that conversion.
Talk about the type of the initializer instead.
gcc/cp/ChangeLog:
PR c++/91849
* call.c (convert_like_internal): Improve reference diagnostic.
gcc/testsuite/ChangeLog:
PR c++/91849
* g++.dg/conversion/pr66211.C: Adjust diagnostic.
* g++.dg/conversion/ref7.C: New test.
The comment for a peephole provided for the `*bit<mode>' pattern to be
produced in comparison elimination from a sequence involving a bitwise
complement operation of one input operand followed by a bitwise AND
operation between a bitwise complement of said intermediate result and
the other input operand (which corresponds to a sequence of MCOM and BIC
machine instructions) incorrectly refers to the first operation as MNEG
(which is the machine instruction for arithmetic negation) rather than
MCOM as it is supposed to. Fix it.
gcc/
* config/vax/vax.md: Fix comment for `*bit<mode>' pattern's
peephole.
When cxx_bind_parameters_in_call is called e.g. on a method on an automatic
variable, we evaluate the argument and because ADDR_EXPR of an automatic
decl is not TREE_CONSTANT, we set *non_constant_args and don't cache it.
But when it is called on an object located on the heap (allocated using
C++20 constexpr new) where we represent it as TREE_STATIC artificial
var, or when it is called on a static var that is currently being
constructed, such ADDR_EXPRs are TREE_CONSTANT and we happily cache
such calls, but they can in those cases have side-effects in the heap
or static var objects and so caching them means such side-effects will
happen only once and not as many times as that method or function is called.
Furthermore, as Patrick mentioned in the PR, the argument doesn't need to be
just ADDR_EXPR of the heap or static var or its components, but it could be
a CONSTRUCTOR that has the ADDR_EXPR embedded anywhere.
And the incorrectly cached function doesn't need to modify the pointed vars
or their components, but some caller could be changing them in between the
call that was cached and the call that used the cached result.
The following patch fixes it by setting *non_constant_args also when
the argument contains somewhere such an ADDR_EXPR, either of a heap
artificial var or component thereof, or of a static var currently being
constructed (where for that it uses the same check as
cxx_eval_store_expression, ctx->global->values.get (...); addresses of
other static variables would be rejected by cxx_eval_store_expression
and therefore it is ok to cache such calls).
2021-04-08 Jakub Jelinek <jakub@redhat.com>
PR c++/99859
* constexpr.c (addr_of_non_const_var): New function.
(cxx_bind_parameters_in_call): Set *non_constant_args to true
even if cp_walk_tree on arg with addr_of_non_const_var callback
returns true.
* g++.dg/cpp1y/constexpr-99859-1.C: New test.
* g++.dg/cpp1y/constexpr-99859-2.C: New test.
* g++.dg/cpp2a/constexpr-new18.C: New test.
* g++.dg/cpp2a/constexpr-new19.C: New test.
This works around the remaining reported execution FAILs of this test on
AIX, Solaris and Darwin. Eventually we should rewrite this test to be
less fragile, but there's not enough time to do that for GCC 11.
libstdc++-v3/ChangeLog:
PR libstdc++/98384
* testsuite/20_util/to_chars/long_double.cc: Don't run the test
on targets without a large long double. XFAIL the execution on
targets with a non-conforming printf.
