The existing TypeInfo errors can be cryptic. This alters the diagnostic
to include which expression is requiring `object.TypeInfo'.
gcc/d/ChangeLog:
* d-tree.h (check_typeinfo_type): Add Expression* parameter.
(build_typeinfo): Likewise. Declare new override.
* expr.cc (ExprVisitor): Call build_typeinfo with Expression*.
* typeinfo.cc (check_typeinfo_type): Include expression in the
diagnostic message.
(build_typeinfo): New override.
gcc/testsuite/ChangeLog:
* gdc.dg/rtti1.d: New test.
(cherry picked from commit e55eda2385)
Here during ahead of time instantiation of the value-dependent but not
type-dependent decltype expression (5 % N) == 0, cp_build_binary_op folds
the operands of the == via cp_fully_fold, which performs speculative
constexpr evaluation, and from which we crash for (5 % N) due to the
value-dependence.
Since the operand folding performed by cp_build_binary_op appears to
be solely for sake of diagnosing overflow, and since these diagnostics
are suppressed when in an unevaluated context, this patch avoids this
crash by suppressing cp_build_binary_op's operand folding accordingly.
PR c++/105756
gcc/cp/ChangeLog:
* typeck.cc (cp_build_binary_op): Don't fold operands
when c_inhibit_evaluation_warnings.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/decltype82.C: New test.
(cherry picked from commit 0ecb6b906f)
My previous patch for 105761 avoided copying DECL_TEMPLATE_INFO from a
friend to a later definition, but in this testcase we have first a
non-friend declaration and then a definition, and we need to avoid copying
in that case as well. But we do still want to set new_template_info to
avoid GC trouble.
With this change, the modules dump correctly identifies ::foo as a
non-template function in tpl-friend-2_a.C.
Along the way I noticed that the duplicate_decls handling of
DECL_UNIQUE_FRIEND_P was backwards for templates, where we don't clobber
DECL_LANG_SPECIFIC (olddecl) with DECL_LANG_SPECIFIC (newdecl) like we do
for non-templates.
PR c++/105852
PR c++/105761
gcc/cp/ChangeLog:
* decl.cc (duplicate_decls): Avoid copying template info
from non-templated friend even if newdecl isn't a definition.
Correct handling of DECL_UNIQUE_FRIEND_P on templates.
* pt.cc (non_templated_friend_p): New.
* cp-tree.h (non_templated_friend_p): Declare it.
gcc/testsuite/ChangeLog:
* g++.dg/modules/tpl-friend-2_a.C: Adjust expected dump.
* g++.dg/template/friend74.C: New test.
split_double operates with the 'word that comes first in memory in the
target' terminology, while gen_lowpart operates with the 'value
representing some low-order bits of X' terminology. They are not
equivalent and must be dealt with differently on little- and big-endian
targets.
gcc/
PR target/105879
* config/xtensa/xtensa.md (movdi): Rename 'first' and 'second'
to 'lowpart' and 'highpart' so that they match 'gen_lowpart' and
'gen_highpart' bitwise semantics and fix order of highpart and
lowpart depending on target endianness.
(cherry picked from commit e94c6dbfb5)
This new function was added for gcc 11.1 but is not exported from the
shared library. Depending on inlining decisions, its callers might get
inlined but an external definition be needed for this function. That
then fails to link.
Since we can't add the export to the gcc-11 release branch now, mark it
always_inline. We can consider exporting it for gcc-13 if/when we bump
the shared library version (and maybe also for gcc-12 which is currently
at the same version as trunk). For now, the attribute will solve the
problem on all affected branches. The function is small enough that
force-inlining it shouldn't cause problems.
libstdc++-v3/ChangeLog:
PR libstdc++/105671
* include/std/sstream (basic_stringbuf::_M_high_mark): Add
always_inline attribute.
(cherry picked from commit de57440858)
On a 16-bit target such as msp430 we get errors about narrowing long
values to size_t, which is only 16-bit. When --enable-libstdcxx-pch is
used the <bits/extc++.h> header breaks the build because of these
narrowing errors.
libstdc++-v3/ChangeLog:
PR libstdc++/105681
* include/ext/pb_ds/detail/resize_policy/hash_prime_size_policy_imp.hpp:
Limit ga_sizes array to values that fit in size_t.
* include/ext/random [__SIZE_WIDTH < 32] (sfmt86243)
(sfmt86243_64, sfmt132049, sfmt132049_64, sfmt216091)
(sfmt216091_64): Do not declare.
(cherry picked from commit 367740bf6d)
Since the COW std::string was moved to its own header, we don't need the
atomic dispatch helpers in the definition of std::__cxx11::string. Move
the inclusion of the <ext/atomicity.h> header to <bits/cow_string.h>
where it's needed.
libstdc++-v3/ChangeLog:
* include/bits/basic_string.h: Do not include <ext/atomicity.h>
here.
* include/bits/cow_string.h: Include it here.
(cherry picked from commit f3e22baec0)
Here, when we see the second declaration of f we match it with the first
one, copy over DECL_TEMPLATE_INFO, and then try to use it when parsing the
definition, leading to confusion.
PR c++/105761
gcc/cp/ChangeLog:
* decl.cc (duplicate_decls): Don't copy DECL_TEMPLATE_INFO
from a hidden friend.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1y/auto-fn64.C: New test.
In this testcase, leaving ctx->ctor pointing to the enclosing object meant
that evaluating the initializer for the subobject clobbered previous
initializers for the enclosing object. So do update ctx->ctor, just don't
add it to the enclosing object ctor.
PR c++/105795
gcc/cp/ChangeLog:
* constexpr.cc (cxx_eval_bare_aggregate): Always call
init_subob_ctx.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1z/constexpr-aggr-base1.C: New test.
The Zbb support has introduced ctz and clz to the backend, but some
transformations in GCC need to know what the value of c[lt]z at zero
is. This affects how the optab is generated and may suppress use of
CLZ/CTZ in tree passes.
Among other things, this is needed for the transformation of
table-based ctz-implementations, such as in deepsjeng, to work
(see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90838).
Prior to this change, the test case from PR90838 would compile to
on RISC-V targets with Zbb:
myctz:
lui a4,%hi(.LC0)
ld a4,%lo(.LC0)(a4)
neg a5,a0
and a5,a5,a0
mul a5,a5,a4
lui a4,%hi(.LANCHOR0)
addi a4,a4,%lo(.LANCHOR0)
srli a5,a5,58
sh2add a5,a5,a4
lw a0,0(a5)
ret
After this change, we get:
myctz:
ctz a0,a0
andi a0,a0,63
ret
Testing this with deepsjeng_r (from SPEC 2017) against QEMU, this
shows a clear reduction in dynamic instruction count:
- before 1961888067076
- after 1907928279874 (2.75% reduction)
This also merges the various target-specific test-cases (for x86-64,
aarch64 and riscv) within gcc.dg/pr90838.c.
This extends the macros (i.e., effective-target keywords) used in
testing (lib/target-supports.exp) to reliably distinguish between RV32
and RV64 via __riscv_xlen (i.e., the integer register bitwidth) :
testing for ILP32 could be misleading (as ILP32 is a valid memory
model for 64bit systems).
gcc/ChangeLog:
* config/riscv/riscv.h (CLZ_DEFINED_VALUE_AT_ZERO): Implement.
(CTZ_DEFINED_VALUE_AT_ZERO): Same.
* doc/sourcebuild.texi: add documentation for RISC-V specific
test target keywords
gcc/testsuite/ChangeLog:
* gcc.dg/pr90838.c: Add additional flags (dg-additional-options)
when compiling for riscv64 and subsume gcc.target/aarch64/pr90838.c
and gcc.target/i386/pr95863-2.c.
* gcc.target/aarch64/pr90838.c: Removed.
* gcc.target/i386/pr95863-2.c: Removed.
* lib/target-supports.exp: Recognize RV32 or RV64 via XLEN
Signed-off-by: Philipp Tomsich <philipp.tomsich@vrull.eu>
Signed-off-by: Manolis Tsamis <manolis.tsamis@vrull.eu>
Co-authored-by: Manolis Tsamis <manolis.tsamis@vrull.eu>
(cherry picked from commit 16f7fcadac)
This avoids matching strlen to a pointer result, avoiding ICEing
because of an integer adjustment using PLUS_EXPR on pointers.
2022-06-01 Richard Biener <rguenther@suse.de>
PR tree-optimization/105786
* tree-loop-distribution.cc
(loop_distribution::transform_reduction_loop): Only do strlen
replacement for integer type reductions.
* gcc.dg/torture/pr105786.c: New testcase.
(cherry picked from commit 57a8fb92ac)
There's heuristic to detect ptr[1].a[...] out of bound accesses
reasoning that if ptr points to an array of aggregates a trailing
incomplete array has to have size zero. The following more
thoroughly constrains the cases this applies to avoid false
positive diagnostics.
2022-05-25 Richard Biener <rguenther@suse.de>
PR tree-optimization/105726
* gimple-ssa-warn-restrict.cc (builtin_memref::set_base_and_offset):
Constrain array-of-flexarray case more.
* g++.dg/warn/Warray-bounds-27.C: New testcase.
(cherry picked from commit e7c482b080)
This is another place where we fail to pass down the mode of a
CONST_INT.
2022-05-24 Richard Biener <rguenther@suse.de>
PR middle-end/105711
* expmed.cc (extract_bit_field_as_subreg): Add op0_mode parameter
and use it.
(extract_bit_field_1): Pass down the mode of op0 to
extract_bit_field_as_subreg.
* gcc.target/i386/pr105711.c: New testcase.
(cherry picked from commit 91c7c5edd2)
Under extreme register pressure, compiler can use FP <--> int
moves as a cheap alternate to spilling to memory.
This was seen with SPEC2017 FP benchmark 507.cactu:
ML_BSSN_Advect.cc:ML_BSSN_Advect_Body()
| fmv.d.x fa5,s9 # PDupwindNthSymm2Xt1, PDupwindNthSymm2Xt1
| .LVL325:
| ld s9,184(sp) # _12469, %sfp
| ...
| .LVL339:
| fmv.x.d s4,fa5 # PDupwindNthSymm2Xt1, PDupwindNthSymm2Xt1
|
The FMV instructions could be costlier (than stack spill) on certain
micro-architectures, thus this needs to be a per-cpu tunable
(default being to inhibit on all existing RV cpus).
Testsuite run with new test reports 10 failures without the fix
corresponding to the build variations of pr105666.c
| === gcc Summary ===
|
| # of expected passes 123318 (+10)
| # of unexpected failures 34 (-10)
| # of unexpected successes 4
| # of expected failures 780
| # of unresolved testcases 4
| # of unsupported tests 2796
gcc/ChangeLog:
* config/riscv/riscv.cc: (struct riscv_tune_param): Add
fmv_cost.
(rocket_tune_info): Add default fmv_cost 8.
(sifive_7_tune_info): Ditto.
(thead_c906_tune_info): Ditto.
(optimize_size_tune_info): Ditto.
(riscv_register_move_cost): Use fmv_cost for int<->fp moves.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/pr105666.c: New test.
Signed-off-by: Vineet Gupta <vineetg@rivosinc.com>
(cherry picked from commit b646d7d279)
In r12-3643 I improved our handling of type names after . or -> when
unqualified lookup doesn't find anything, but it needs to handle auto
specially.
PR c++/105734
gcc/cp/ChangeLog:
* parser.cc (cp_parser_postfix_dot_deref_expression): Use typeof
if the expression has auto type.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/auto57.C: New test.
This testcase demonstrates that the issue in PR105623 is not limited to
templates, so we should do the marking in a less template-specific place.
PR c++/105779
gcc/cp/ChangeLog:
* call.cc (resolve_args): Call mark_single_function here.
* pt.cc (unify_one_argument): Not here.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1y/auto-fn63.C: New test.
Here ever since r10-7313-gb599bf9d6d1e18, reduced_constant_expression_p
in C++11/14 is rejecting the marked sub-aggregate initializer (of type S)
W w = {.D.2445={.s={.D.2387={.m=0}, .b=0}}};
^
ultimately because said initializer has CONSTRUCTOR_NO_CLEARING set,
hence the function must verify that all fields of S are initialized.
And before C++17 it doesn't expect to see base class fields (since
next_initializable_field skips over them), so the presence thereof
causes r_c_e_p to return false.
The reason r10-7313-gb599bf9d6d1e18 causes this is because in that
commit we began using CONSTRUCTOR_NO_CLEARING to precisely track whether
we're in middle of activating a union member. This ends up affecting
clear_no_implicit_zero, which recurses into sub-aggregate initializers
only if the outer initializer has CONSTRUCTOR_NO_CLEARING set. After
that commit, the outer union initializer above no longer has the flag
set at this point and so clear_no_implicit_zero no longer recurses into
the marked inner initializer.
But arguably r_c_e_p should be able to accept the marked initializer
regardless of whether CONSTRUCTOR_NO_CLEARING is set. The primary bug
therefore seems to be that r_c_e_p relies on next_initializable_field
which skips over base class fields in C++11/14. To fix this, this patch
introduces a new helper function next_subobject_field which is like
next_initializable_field except that it never skips base class fields,
and makes r_c_e_p use it. This patch then renames next_initializable_field
to next_aggregate_field (and makes it skip over vptr fields again).
NB: This minimal backport of r13-211-g0c7bce0ac184c0 for 12.2 just adds
next_subobject_field and makes reduced_constant_expression_p use it.
PR c++/105491
gcc/cp/ChangeLog:
* constexpr.cc (reduced_constant_expression_p): Use
next_subobject_field instead.
* cp-tree.h (next_subobject_field): Declare.
* decl.cc (next_subobject_field): Define.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/constexpr-union7.C: New test.
* g++.dg/cpp0x/constexpr-union7a.C: New test.
* g++.dg/cpp2a/constinit17.C: New test.
(cherry picked from commit 0c7bce0ac1)
We currently check satisfaction in the context of the constrained
declaration (which may be wrong, see PR104111). When checking C<int>
for S<int>, we currently substitute into the lambda in the context of
S<T> (rather than S<int>, which seems wrong if the above isn't wrong), so
the new closure type thinks its context is S<T>, which confuses debug
output. For the moment, let's work around all of this by overriding the
context of the closure.
PR c++/105652
gcc/cp/ChangeLog:
* pt.cc (tsubst_lambda_expr): Don't let a namespace-scope lambda
instantiate into a class-scope lambda.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-lambda20.C: New test.
Here, alias_ctad_tweaks expect tsubst_decl of a FUNCTION_DECL to return a
FUNCTION_DECL. A reasonable expectation, but in this case we were replacing
the template args of the class-scope deduction guide with equivalent args,
so looking in the hash table we found the partial instantiation stored when
instantiating A<int>, which is a TEMPLATE_DECL. It's fine for that to be
what is stored, but tsubst_function_decl should never return it.
PR c++/105655
gcc/cp/ChangeLog:
* pt.cc (build_template_decl): Add assert.
(tsubst_function_decl): Don't return a template.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/class-deduction-alias13.C: New test.
Since my patch for PR90451, we defer mark_used of single functions as late
as possible. And since my r12-1273, we keep BASELINK from lookup around
rather than reconstruct it later. These both made us try to instantiate g
with a function type that still had 'auto' as its return type.
PR c++/105623
gcc/cp/ChangeLog:
* decl2.cc (mark_used): Copy type from fn to BASELINK.
* pt.cc (unify_one_argument): Call mark_single_function.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1y/auto-fn62.C: New test.
The problem here is that first check_initializer calls
build_aggr_init_full_exprs, which does overload resolution, but then in the
case of failed constexpr throws away the result and does it again in
build_functional_cast. But in the first overload resolution,
reshape_init_array_1 decided to reuse the inner CONSTRUCTORs because
tf_error is set, so we know we're committed. But the second pass gets
confused by the CONSTRUCTORs with non-init-list types.
Fixed by avoiding a second pass: instead, pass the call from build_aggr_init
to build_cplus_new, which will turn it into a TARGET_EXPR. I don't bother
to change the object argument because it will be replaced later in
simplify_aggr_init_expr.
PR c++/102307
gcc/cp/ChangeLog:
* decl.cc (check_initializer): Use build_cplus_new in case of
constexpr failure.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1z/constexpr-array2.C: New test.
As of gdc-12, the lexer expects there 4 bytes of zero padding at the end
of the source buffer to mark the end of input. Sometimes when reading
from stdin, the data at the end of input is garbage rather than zeroes.
Fix that by explicitly calling memset past the end of the buffer.
PR d/105544
gcc/d/ChangeLog:
* d-lang.cc (d_parse_file): Zero padding past the end of the stdin
buffer so the D lexer has a sentinel to stop parsing at.
(cherry picked from commit a0bc7fd421)
PR 105639 shows that code with type-mismatches can trigger an assert
after runnning into a branch that was inteded only for references to
variables - as opposed to references to functions. Fixed by moving
the condition from the assert to the guarding if statement.
gcc/ChangeLog:
2022-05-25 Martin Jambor <mjambor@suse.cz>
PR ipa/105639
* ipa-prop.cc (propagate_controlled_uses): Check type of the
constant before adding a LOAD reference.
gcc/testsuite/ChangeLog:
2022-05-25 Martin Jambor <mjambor@suse.cz>
PR ipa/105639
* gcc.dg/ipa/pr105639.c: New test.
(cherry picked from commit f571596f8c)
The first part of the following testcase (m1-m3 macros and its use)
regressed with my PR89971 fix, but as the m1,m4-m5 and its use part shows,
the problem isn't new, we can emit a CPP_PADDING token to avoid it from
being adjacent to whatever comes after the __VA_OPT__ (in this case there
is nothing afterwards, true).
In most cases these CPP_PADDING tokens don't matter, all other
callers of cpp_get_token_with_location either ignore CPP_PADDING tokens
completely (e.g. c_lex_with_flags) or they just remember them and
take them into account when printing stuff whether there should be
added whitespace or not (scan_translation_unit + token_streamer::stream).
So, I think we should just ignore CPP_PADDING tokens the same way in
_cpp_parse_expr.
2022-05-27 Jakub Jelinek <jakub@redhat.com>
PR preprocessor/105732
* expr.cc (_cpp_parse_expr): Handle CPP_PADDING by just another
token.
* c-c++-common/cpp/va-opt-10.c: New test.
(cherry picked from commit 58a40e76eb)
since apparently _aligned_malloc requires freeing with _aligned_free and:
/* Defined if gomp_aligned_alloc doesn't use fallback version
and free can be used instead of gomp_aligned_free. */
#define GOMP_HAVE_EFFICIENT_ALIGNED_ALLOC 1
so the second condition isn't satisfied. For uses inside of the OpenMP
allocators we can still use _aligned_malloc but we need to call _aligned_free
in gomp_aligned_free.
2022-05-28 Jakub Jelinek <jakub@redhat.com>
PR libgomp/105745
* libgomp.h (GOMP_HAVE_EFFICIENT_ALIGNED_ALLOC): Don't define for
defined(HAVE__ALIGNED_MALLOC) case.
* alloc.c (gomp_aligned_alloc): Move defined(HAVE__ALIGNED_MALLOC)
handling as last option before fallback instead of first.
(gomp_aligned_free): For defined(HAVE__ALIGNED_MALLOC) call
_aligned_free.
(cherry picked from commit 42fd2cd932)
The following testcase triggers a false positive UBSan binding a reference
to null diagnostics.
In the FE we instrument conversions from pointer to reference type
to diagnose at runtime if the operand of such a conversion is 0.
The problem is that a GENERIC folding folds
((const struct Bar *) ((const struct Foo *) this)->data) + (sizetype) range_check (x)
conversion to const struct Bar & by converting to that the first
operand of the POINTER_PLUS_EXPR. But that changes when the -fsanitize=null
binding to reference runtime check occurs. Without the optimization,
it is invoked on the result of the POINTER_PLUS_EXPR, and as range_check
call throws, that means it never triggers in the testcase.
With the optimization, it checks whether this->data is NULL and it is.
The following patch avoids that optimization during GENERIC folding when
-fsanitize=null is enabled and it is a cast from non-REFERENCE_TYPE to
REFERENCE_TYPE.
2022-05-27 Jakub Jelinek <jakub@redhat.com>
PR sanitizer/105729
* fold-const.cc (fold_unary_loc): Don't optimize (X &) ((Y *) z + w)
to (X &) z + w if -fsanitize=null during GENERIC folding.
* g++.dg/ubsan/pr105729.C: New test.
(cherry picked from commit e2f014fcef)
On the following testcase with -Os asan pass sees:
<bb 6> [local count: 354334800]:
# h_21 = PHI <h_15(6), 0(5)>
*c.3_5 = *d.2_4;
h_15 = h_21 + 1;
if (h_15 != 3)
goto <bb 6>; [75.00%]
else
goto <bb 7>; [25.00%]
<bb 7> [local count: 118111600]:
*c.3_5 = MEM[(struct a *)&b + 12B];
_13 = c.3_5->x;
return _13;
It instruments the
*c.3_5 = *d.2_4;
assignment by adding
.ASAN_CHECK (7, c.3_5, 4, 4);
.ASAN_CHECK (6, d.2_4, 4, 4);
before it (which later lowers to checking the corresponding shadow
memory). But when considering instrumentation of
*c.3_5 = MEM[(struct a *)&b + 12B];
it doesn't instrument anything, because it sees that *c.3_5 store is
already instrumented in a dominating block and so there is no need
to instrument *c.3_5 store again (i.e. add another
.ASAN_CHECK (7, c.3_5, 4, 4);
). That is true, but misses the fact that we still want to
instrument the MEM[(struct a *)&b + 12B] load.
The following patch fixes that by changing has_stmt_been_instrumented_p
to consider both store and load in the assignment if it does both
(returning true iff both have been instrumented).
That matches how we handle e.g. builtin calls, where we also perform AND
of all the memory locs involved in the call.
I've verified that we still don't add the redundant
.ASAN_CHECK (7, c.3_5, 4, 4);
call but just add
_18 = &MEM[(struct a *)&b + 12B];
.ASAN_CHECK (6, _18, 4, 4);
to instrument the load.
2022-05-25 Jakub Jelinek <jakub@redhat.com>
PR sanitizer/105714
* asan.cc (has_stmt_been_instrumented_p): For assignments which
are both stores and loads, return true only if both destination
and source have been instrumented.
* gcc.dg/asan/pr105714.c: New test.
(cherry picked from commit af02daff55)
The gimple_parm_array_size function comment talks about pointe parameters
but doesn't actually verify it, it checks whether an attribute is present
on the function and then just uses TREE_TYPE (TREE_TYPE (var)) which
assumes a pointer type (or in theory could work for ARRAY_TYPE but
c-family languages which only have that attribute will never have ARRAY_TYPE
parameters; and for VECTOR_TYPE/COMPLEX_TYPE it would mean something quite
different).
So, this patch punts early if var doesn't have pointer/reference type.
2022-05-19 Jakub Jelinek <jakub@redhat.com>
PR c/105635
* pointer-query.cc (gimple_parm_array_size): Return NULL if var
doesn't have pointer or reference type.
* gcc.dg/pr105635.c: New test.
(cherry picked from commit 3b4daa0b3c)
This fixes the printers to work with std::__8::atomic and
std::__v8::ios_errc and std::__v8::future_errc.
libstdc++-v3/ChangeLog:
* python/libstdcxx/v6/printers.py (StdErrorCodePrinter): Make
lookup for ios_errc and future_errc check versioned namespace.
(StdAtomicPrinter): Strip versioned namespace from typename.
(cherry picked from commit 11e1ee1b38)
libstdc++-v3/ChangeLog:
* python/libstdcxx/v6/printers.py (StdSpanPrinter.__init__):
Strip typename from version namespace.
(cherry picked from commit ace4b7f295)
GCC Administrator
Iain Buclaw
Patrick Palka
Joseph Myers
Jason Merrill
Max Filippov
Jonathan Wakely
liuhongt
Philipp Tomsich
Richard Biener
Martin Sebor
Vineet Gupta
Martin Jambor
Jakub Jelinek
François Dumont