Iain Buclaw [Thu, 21 Apr 2022 13:25:26 +0000 (14:25 +0100)]
d: Merge upstream dmd
eb7bee331, druntime
27834edb, phobos
ac296f80c.
D front-end changes:
- Import dmd v2.100.0-beta.1.
- Print deprecation messages for scope violations unless
`-frevert=dip1000' is used.
- Fixed a missed case of switch case fallthrough not being caught by
the compiler.
D runtime changes:
- Import druntime v2.100.0-beta.1.
Phobos changes:
- Import phobos v2.100.0-beta.1.
gcc/d/ChangeLog:
* dmd/MERGE: Merge upstream dmd
eb7bee331.
* dmd/VERSION: Update version to v2.100.0-beta.1.
* d-lang.cc (d_handle_option): Handle OPT_frevert_dip1000.
* lang.opt (frevert=dip1000): New option.
libphobos/ChangeLog:
* libdruntime/MERGE: Merge upstream druntime
27834edb.
* src/MERGE: Merge upstream phobos
ac296f80c.
* src/Makefile.am (PHOBOS_DSOURCES): Add std/int128.d.
* src/Makefile.in: Regenerate.
Patrick Palka [Thu, 21 Apr 2022 16:11:01 +0000 (12:11 -0400)]
libstdc++: Avoid ASCII assumptions in floating_from_chars.cc
In starts_with_ci and in __floating_from_chars_hex's inf/nan handling,
we were assuming that the letters are contiguous and that 'A' + 32 == 'a'
which is true for ASCII but not for other character encodings.
This patch fixes starts_with_ci by using a constexpr lookup table that
maps uppercase letters to lowercase, and fixes __floating_from_chars_hex
by using __from_chars_alnum_to_val.
libstdc++-v3/ChangeLog:
* include/std/charconv (__from_chars_alnum_to_val_table):
Simplify initialization of __lower/__upper_letters.
(__from_chars_alnum_to_val): Default the template parameter to
false.
* src/c++17/floating_from_chars.cc (starts_with_ci): Don't
assume the uppercase and lowercase letters are contiguous.
(__floating_from_chars_hex): Likewise.
Marek Polacek [Thu, 21 Apr 2022 14:27:38 +0000 (10:27 -0400)]
c++: Remove unused parameter
gcc/cp/ChangeLog:
* constexpr.cc (cxx_eval_logical_expression): Remove unused
parameter.
(cxx_eval_constant_expression) <case TRUTH_ANDIF_EXPR>,
<case TRUTH_OR_EXPR>: Adjust calls to cxx_eval_logical_expression.
Marek Polacek [Wed, 20 Apr 2022 20:02:52 +0000 (16:02 -0400)]
c++: wrong error with constexpr COMPOUND_EXPR [PR105321]
Here we issue a bogus error for the first assert in the test. Therein
we have
<retval> = (void) (VIEW_CONVERT_EXPR<bool>(yes) || handle_error ());, VIEW_CONVERT_EXPR<int>(value);
which has a COMPOUND_EXPR, so we get to cxx_eval_constant_expression
<case COMPOUND_EXPR>. The problem here is that we call
7044 /* Check that the LHS is constant and then discard it. */
7045 cxx_eval_constant_expression (ctx, op0,
7046 true, non_constant_p, overflow_p,
7047 jump_target);
where lval is always true, so the PARM_DECL 'yes' is not evaluated into
its value.
Fixed by always passing false for 'lval' in cxx_eval_logical_expression;
there's no case where we actually expect an lvalue from a TRUTH_*.
PR c++/105321
gcc/cp/ChangeLog:
* constexpr.cc (cxx_eval_logical_expression): Always pass false for lval
to cxx_eval_constant_expression.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/constexpr-105321.C: New test.
Fritz Reese [Tue, 19 Apr 2022 20:45:46 +0000 (16:45 -0400)]
fortran: Fix conv of UNION constructors [PR105310]
This fixes an ICE when a UNION is the (1+8*2^n)-th field in a DEC
STRUCTURE when compiled with -finit-derived -finit-local-zero.
The problem was CONSTRUCTOR_APPEND_ELT from within gfc_conv_union_initializer
modified the vector pointer, but the pointer was passed by-value,
so the old pointer from the caller (gfc_conv_structure) pointed to freed
memory.
PR fortran/105310
gcc/fortran/ChangeLog:
* trans-expr.cc (gfc_conv_union_initializer): Pass vec* by reference.
gcc/testsuite/ChangeLog:
* gfortran.dg/dec_union_12.f90: New test.
Patrick Palka [Thu, 21 Apr 2022 12:34:59 +0000 (08:34 -0400)]
libstdc++: Work around modules ICE in <charconv> [PR105297]
This makes the initializer for __table in __from_chars_alnum_to_val
dependent in an artificial way, which works around the reported modules
testsuite ICE by preventing the compiler from evaluating the initializer
parse time.
Compared to the alternative workaround of using a non-local class type
for __table, this workaround has the advantage of slightly speeding up
compilation of <charconv>, since now the table won't get built (via
constexpr evaluation) until the integer std::from_chars overload is
instantiated.
PR c++/105297
PR c++/105322
libstdc++-v3/ChangeLog:
* include/std/charconv (__from_chars_alnum_to_val): Make
initializer for __table dependent in an artificial way.
Jonathan Wakely [Thu, 21 Apr 2022 10:26:49 +0000 (11:26 +0100)]
libstdc++: Remove bogus assertion in std::from_chars [PR105324]
I'm not sure what I was thinking when I added this assertion, maybe it
was supposed to be alignment == 1 (which is what the pmr::string actually
uses). The simplest fix is to just remove the assertion.
The assertion is no longer enabled by default on trunk, but it's still
there for the --enablke-libstdcxx-debug build, and is still wrong. The
fix is needed on the gcc-11 branch.
libstdc++-v3/ChangeLog:
PR libstdc++/105324
* src/c++17/floating_from_chars.cc (buffer_resource::do_allocate):
Remove assertion.
* testsuite/20_util/from_chars/pr105324.cc: New test.
Martin Liska [Thu, 21 Apr 2022 08:17:34 +0000 (10:17 +0200)]
Support --compress-debug-sections for ld.mold.
gcc/ChangeLog:
* configure.ac: Enable compressed debug sections for mold
linker.
* configure: Regenerate.
Jakub Jelinek [Thu, 21 Apr 2022 07:43:30 +0000 (09:43 +0200)]
emit-rtl: Fix -fcompare-debug bug with label references in debug insns [PR105203]
When we compute LABEL_NUSES from scratch, mark_all_labels doesn't call
mark_jump_label on DEBUG_INSNs:
if (NONDEBUG_INSN_P (insn))
mark_jump_label (PATTERN (insn), insn, 0);
and so doesn't increment LABEL_NUSES from references in DEBUG_INSNs.
But, when we call emit_copy_of_insn_after e.g. when duplicating some
DEBUG_INSNs, we call it even on those, which then results in LABEL_NUSES
differences and -fcompare-debug failures.
The following patch makes sure we don't call it on DEBUG_INSNs.
2022-04-21 Jakub Jelinek <jakub@redhat.com>
PR debug/105203
* emit-rtl.cc (emit_copy_of_insn_after): Don't call mark_jump_label
on DEBUG_INSNs.
* gfortran.dg/g77/pr105203.f: New test.
Ian Lance Taylor [Wed, 20 Apr 2022 21:22:41 +0000 (14:22 -0700)]
runtime: use correct field name for PPC32 GLIBC registers
One of these days we will get this right.
Fixes PR go/105315
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/401374
GCC Administrator [Thu, 21 Apr 2022 00:16:32 +0000 (00:16 +0000)]
Daily bump.
Ed Catmur [Mon, 18 Apr 2022 22:09:04 +0000 (23:09 +0100)]
c++: Fall through for arrays of T vs T cv [PR104996]
If two arrays do not have the exact same element type including
qualification, this could be e.g. f(int (&&)[]) vs. f(int const (&)[]),
which can still be distinguished by the lvalue-rvalue tiebreaker.
By tightening this branch (in accordance with the letter of the Standard) we
fall through to the next branch, which tests whether they have different
element type ignoring qualification and returns 0 in that case; thus we only
actually fall through in the T[...] vs. T cv[...] case, eventually
considering the lvalue-rvalue tiebreaker at the end of compare_ics.
Signed-off-by: Ed Catmur <ed@catmur.uk>
PR c++/104996
gcc/cp/ChangeLog:
* call.cc (compare_ics): When comparing list-initialization
sequences, do not return early.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/initlist129.C: New test.
Jonathan Wakely [Wed, 20 Apr 2022 12:50:14 +0000 (13:50 +0100)]
libstdc++: Fix macro checked by test
The macro being tested here is wrong, but just happens to have the same
value as the one supposed to be tests.
libstdc++-v3/ChangeLog:
* testsuite/21_strings/basic_string_view/operations/copy/char/constexpr.cc:
Check correct feature test macro.
Jonathan Wakely [Wed, 13 Apr 2022 13:09:33 +0000 (14:09 +0100)]
libstdc++: Use LTLIBICONV when linking libstdc++.so [PR93602]
This fixes missing libiconv symbols when libstdc++ is built on a system
that has libiconv installed. If the libiconv headers are found then
libstdc++ depends on libiconv_open etc instead of libc's iconv_open. But
without this fix libstdc++ is not linked to the libiconv library that
provides the definitions of those symbols.
As discussed in PR 93602 this changed means that libstdc++.so.6 might
have an rpath pointing to the location of the libiconv.so library. If
that is not desired, then GCC must be configured to link to a static
libiconv.a instead, using either --with-libiconv-type=static or an
in-tree build of libiconv.
libstdc++-v3/ChangeLog:
PR libstdc++/93602
* doc/xml/manual/prerequisites.xml: Document libiconv
workarounds.
* doc/html/manual/setup.html: Regenerate.
* src/Makefile.am (CXXLINK): Add $(LTLIBICONV).
* src/Makefile.in: Regenerate.
Richard Biener [Mon, 21 Mar 2022 13:08:25 +0000 (14:08 +0100)]
tree-optimization/104912 - ensure cost model is checked first
The following makes sure that when we build the versioning condition
for vectorization including the cost model check, we check for the
cost model and branch over other versioning checks. That is what
the cost modeling assumes, since the cost model check is the only
one accounted for in the scalar outside cost. Currently we emit
all checks as straight-line code combined with bitwise ops which
can result in surprising ordering of checks in the final assembly.
Since loop_version accepts only a single versioning condition
the splitting is done after the fact.
The result is a 1.5% speedup of 416.gamess on x86_64 when compiling
with -Ofast and tuning for generic or skylake. That's not enough
to recover from the slowdown when vectorizing but it now cuts off
the expensive alias versioning test.
2022-03-21 Richard Biener <rguenther@suse.de>
PR tree-optimization/104912
* tree-vect-loop-manip.cc (vect_loop_versioning): Split
the cost model check to a separate BB to make sure it is
checked first and not combined with other version checks.
Richard Biener [Wed, 20 Apr 2022 08:17:24 +0000 (10:17 +0200)]
tree-optimization/105312 - fix ISEL VCOND expansion
The following aligns ISEL VEC_COND_EXPR expansion using VCOND
with the optab query done by vector lowering. Instead of only
allowing the signed optab to provide EQ/NE compares we allow both
here though since there seems to be no documented canonicalization.
2022-04-20 Richard Biener <rguenther@suse.de>
PR tree-optimization/105312
* gimple-isel.cc (gimple_expand_vec_cond_expr): Query both
VCOND and VCONDU for EQ and NE.
* gcc.target/arm/pr105312.c: New testcase.
Jan Hubicka [Wed, 20 Apr 2022 09:00:33 +0000 (11:00 +0200)]
Fix overflows in ipa-modref-tree.cc
gcc/ChangeLog:
2022-04-20 Jan Hubicka <hubicka@ucw.cz>
PR ipa/103818
* ipa-modref-tree.cc (modref_access_node::closer_pair_p): Use
poly_offset_int to avoid overflow.
(modref_access_node::update2): likewise.
gcc/testsuite/ChangeLog:
2022-04-20 Jan Hubicka <hubicka@ucw.cz>
* gcc.c-torture/compile/103818.c: New test.
Jakub Jelinek [Wed, 20 Apr 2022 07:24:18 +0000 (09:24 +0200)]
cgraph: Fix up semantic_interposition handling [PR105306]
cgraph_node has a semantic_interposition flag which should mirror
opt_for_fn (decl, flag_semantic_interposition). But it actually is
initialized not from that, but from flag_semantic_interposition in the
explicit symtab_node (symtab_type t)
: type (t), resolution (LDPR_UNKNOWN), definition (false), alias (false),
...
semantic_interposition (flag_semantic_interposition),
...
x_comdat_group (NULL_TREE), x_section (NULL)
{}
ctor. I think that might be fine for varpool nodes, but since
flag_semantic_interposition is now implied from -Ofast it isn't correct
for cgraph nodes, unless we guarantee that cgraph node for a particular
function decl is always created while that function is
current_function_decl. That is often the case, but not always as the
following function shows.
Because symtab_node's ctor doesn't know for which decl the cgraph node
is being created, the following patch keeps that as is, but updates it from
opt_for_fn (decl, flag_semantic_interposition) when we know that, or for
clones copies that flag (often it is then overridden in
set_new_clone_decl_and_node_flags, but not always).
2022-04-20 Jakub Jelinek <jakub@redhat.com>
PR ipa/105306
* cgraph.cc (cgraph_node::create): Set node->semantic_interposition
to opt_for_fn (decl, flag_semantic_interposition).
* cgraphclones.cc (cgraph_node::create_clone): Copy over
semantic_interposition flag.
* g++.dg/opt/pr105306.C: New test.
GCC Administrator [Wed, 20 Apr 2022 00:16:26 +0000 (00:16 +0000)]
Daily bump.
Ian Lance Taylor [Tue, 19 Apr 2022 13:49:22 +0000 (06:49 -0700)]
libgo: make a couple of sed uses POSIX compliant
Patch from Jonathan Wakely.
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/401054
Sergei Trofimovich [Fri, 15 Apr 2022 07:35:27 +0000 (08:35 +0100)]
gcov-profile: Allow negative counts of indirect calls [PR105282]
TOPN metrics are histograms that contain overall count and per-bucket
count. Overall count can be negative when two profiles merge and some
of per-bucket metrics are disacarded.
Noticed as an ICE on python PGO build where gcc crashes as:
during IPA pass: modref
a.c:36:1: ICE: in stream_out_histogram_value, at value-prof.cc:340
36 | }
| ^
stream_out_histogram_value(output_block*, histogram_value_t*)
gcc/value-prof.cc:340
gcc/ChangeLog:
PR gcov-profile/105282
* value-prof.cc (stream_out_histogram_value): Allow negative counts
on HIST_TYPE_INDIR_CALL.
Richard Henderson [Tue, 19 Apr 2022 17:28:42 +0000 (10:28 -0700)]
MAINTAINERS: Update my email address.
2022-04-19 Richard Henderson <rth@gcc.gnu.org>
* MAINTAINERS: Update my email address.
Jakub Jelinek [Tue, 19 Apr 2022 16:58:59 +0000 (18:58 +0200)]
sparc: Preserve ORIGINAL_REGNO in epilogue_renumber [PR105257]
The following testcase ICEs, because the pic register is
(reg:DI 24 %i0 [109]) and is used in the delay slot of a return.
We invoke epilogue_renumber and that changes it to
(reg:DI 8 %o0) which no longer satisfies sparc_pic_register_p
predicate, so we don't recognize the insn anymore.
The following patch fixes that by preserving ORIGINAL_REGNO if
specified, so we get (reg:DI 8 %o0 [109]) instead.
2022-04-19 Jakub Jelinek <jakub@redhat.com>
PR target/105257
* config/sparc/sparc.cc (epilogue_renumber): If ORIGINAL_REGNO,
use gen_raw_REG instead of gen_rtx_REG and copy over also
ORIGINAL_REGNO. Use return 0; instead of /* fallthrough */.
* gcc.dg/pr105257.c: New test.
Jakub Jelinek [Tue, 19 Apr 2022 16:27:41 +0000 (18:27 +0200)]
c++: Fix up CONSTRUCTOR_PLACEHOLDER_BOUNDARY handling [PR105256]
The CONSTRUCTOR_PLACEHOLDER_BOUNDARY bit is supposed to separate
PLACEHOLDER_EXPRs that should be replaced by one object or subobjects of it
(variable, TARGET_EXPR slot, ...) from other PLACEHOLDER_EXPRs that should
be replaced by different objects or subobjects.
The bit is set when finding PLACEHOLDER_EXPRs inside of a CONSTRUCTOR, not
looking into nested CONSTRUCTOR_PLACEHOLDER_BOUNDARY ctors, and we prevent
elision of TARGET_EXPRs (through TARGET_EXPR_NO_ELIDE) whose initializer
is a CONSTRUCTOR_PLACEHOLDER_BOUNDARY ctor. The following testcase ICEs
though, we don't replace the placeholders in there at all, because
CONSTRUCTOR_PLACEHOLDER_BOUNDARY isn't set on the TARGET_EXPR_INITIAL
ctor, but on a ctor nested in such a ctor. replace_placeholders should be
run on the whole TARGET_EXPR slot.
So, the following patch fixes it by moving the CONSTRUCTOR_PLACEHOLDER_BOUNDARY
bit from nested CONSTRUCTORs to the CONSTRUCTOR containing those (but only
if it is closely nested, if there is some other tree sandwiched in between,
it doesn't do it).
2022-04-19 Jakub Jelinek <jakub@redhat.com>
PR c++/105256
* typeck2.cc (process_init_constructor_array,
process_init_constructor_record, process_init_constructor_union): Move
CONSTRUCTOR_PLACEHOLDER_BOUNDARY flag from CONSTRUCTOR elements to the
containing CONSTRUCTOR.
* g++.dg/cpp0x/pr105256.C: New test.
Richard Biener [Wed, 13 Apr 2022 11:49:45 +0000 (13:49 +0200)]
tree-optimization/104010 - fix SLP scalar costing with patterns
When doing BB vectorization the scalar cost compute is derailed
by patterns, causing lanes to be considered live and thus not
costed on the scalar side. For the testcase in PR104010 this
prevents vectorization which was done by GCC 11. PR103941
shows similar cases of missed optimizations that are fixed by
this patch.
2022-04-13 Richard Biener <rguenther@suse.de>
PR tree-optimization/104010
PR tree-optimization/103941
* tree-vect-slp.cc (vect_bb_slp_scalar_cost): When
we run into stmts in patterns continue walking those
for uses outside of the vectorized region instead of
marking the lane live.
* gcc.target/i386/pr103941-1.c: New testcase.
* gcc.target/i386/pr103941-2.c: Likewise.
Patrick Palka [Tue, 19 Apr 2022 14:20:04 +0000 (10:20 -0400)]
libstdc++: Stop defining _GLIBCXX_ASSERTIONS in floating_to_chars.cc
Assertions were originally enabled in the compiled-in floating-point
std::to_chars implementation to help shake out any bugs, but they
apparently impose a significant performance penalty, most notably for
the hex formatting which is around 25% slower with assertions enabled.
This seems too high a cost for unconditionally enabling them.
The newly added calls to __builtin_unreachable work around the compiler
no longer knowing that the set of valid values of 'fmt' is limited (which
was previously upheld by an assert).
libstdc++-v3/ChangeLog:
* src/c++17/floating_to_chars.cc (_GLIBCXX_ASSERTIONS): Don't
define.
(__floating_to_chars_shortest): Add __builtin_unreachable calls to
squelch false-positive -Wmaybe-uninitialized and -Wreturn-type
warnings.
(__floating_to_chars_precision): Likewise.
Philipp Fent [Thu, 14 Apr 2022 16:06:02 +0000 (17:06 +0100)]
libstdc++: Add pretty printer for std::span
This improves the debug output for C++20 spans.
Before:
{static extent =
18446744073709551615, _M_ptr = 0x7fffffffb9a8, _M_extent = {_M_extent_value = 2}}
Now with StdSpanPrinter:
std::span of length 2 = {1, 2}
Signed-off-by: Philipp Fent <fent@in.tum.de>
libstdc++-v3/ChangeLog:
* python/libstdcxx/v6/printers.py (StdSpanPrinter): Define.
* testsuite/libstdc++-prettyprinters/cxx20.cc: Test it.
Richard Biener [Tue, 19 Apr 2022 11:48:02 +0000 (13:48 +0200)]
tree-optimization/104880 - move testcase
This renames the testcase to something picked up by the suites regexp.
2022-04-19 Richard Biener <rguenther@suse.de>
PR tree-optimization/104880
* g++.dg/opt/pr104880.cc: Rename to ...
* g++.dg/opt/pr104880.C: ... this.
Jonathan Wakely [Tue, 19 Apr 2022 08:55:30 +0000 (09:55 +0100)]
libstdc++: Fix syntax error in libbacktrace configuration
Using == instead of = causes a configuration error with dash as the
shell:
checking whether to build libbacktrace support... /home/devel/building/work/src/gcc-12-
20220417/libstdc++-v3/configure: 77471: test: auto: unexpected operator
/home/devel/building/work/src/gcc-12-
20220417/libstdc++-v3/configure: 77474: test: auto: unexpected operator
auto
This means we fail to change the value from "auto" to "no" and so this
test passes:
GLIBCXX_CONDITIONAL(ENABLE_BACKTRACE, [test "$enable_libstdcxx_backtrace" != no])
This leads to the libbacktrace directory being included in the build
without being configured properly, and bootstrap fails.
libstdc++-v3/ChangeLog:
* acinclude.m4 (GLIBCXX_ENABLE_BACKTRACE): Fix shell operators.
* configure: Regenerate.
GCC Administrator [Tue, 19 Apr 2022 00:16:28 +0000 (00:16 +0000)]
Daily bump.
Hans-Peter Nilsson [Mon, 18 Apr 2022 22:30:43 +0000 (00:30 +0200)]
doc/install.texi: CRIS: Remove gone websites. Adjust CRIS targets
That is, support for cris-linux-gnu was removed in gcc-11, but
install.texi wasn't adjusted accordingly. Also, unfortunately the
developer-related sites are gone with no replacements. And, CRIS is
used in other chip series as well, but allude rather than list.
The generated manpages, info, pdf and html were sanity-checked.
gcc:
* doc/install.texi <CRIS>: Remove references to removed websites and
adjust for cris-*-elf being the only remaining toolchain.
Hans-Peter Nilsson [Mon, 18 Apr 2022 22:30:24 +0000 (00:30 +0200)]
doc/invoke.texi: CRIS: Remove references to cris-axis-linux-gnu
...and related options. These stale bits were overlooked when support
for "Linux/GNU" and CRIS v32 was removed, before the gcc-11 release.
Resulting pdf, html and info inspected for sanity.
gcc:
* doc/invoke.texi <CRIS>: Remove references to options for removed
subtarget cris-axis-linux-gnu and tweak wording accordingly.
Sören Tempel [Fri, 15 Apr 2022 09:04:15 +0000 (11:04 +0200)]
libgo: only add signum to siglist if it doesn't exist yet
This fixes a build issue on musl libc where the same signal number
is used for SIGIO and SIGPOLL. This causes a compilation error since
the signal numbers must be unique for the signal table.
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/400595
A. Wilcox [Sun, 30 Aug 2020 15:30:07 +0000 (17:30 +0200)]
runtime: add special handling for signal 34
The musl libc uses signal 34 internally for setgid (similar to how glibc
uses signal 32 and signal 33). For this reason, special handling is
needed for this signal in the runtime. The gc implementation already
handles the signal accordingly. As such, this commit intends to
simply copy the behavior of the Google Go implementation to libgo.
See https://go.dev/issues/39343
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/400594
Patrick Palka [Mon, 18 Apr 2022 21:22:55 +0000 (17:22 -0400)]
libstdc++: Micro-optimize __from_chars_pow2_base
In the first iteration of __from_chars_pow2_base's main loop, we need
to remember the value of the leading significant digit for sake of the
overflow check at the end (for base > 2).
This patch manually unrolls this first iteration so as to not encumber
the entire loop with logic that only the first iteration needs. This
seems to significantly improve performance:
Base Before After (seconds, lower is better)
2 9.36 9.37
8 3.66 2.93
16 2.93 1.91
32 2.39 2.24
libstdc++-v3/ChangeLog:
* include/std/charconv (__from_chars_pow2_base): Manually
unroll the first iteration of the main loop and simplify
accordingly.
Kewen Lin [Mon, 18 Apr 2022 02:34:51 +0000 (21:34 -0500)]
testsuite: Skip pr105250.c for powerpc and s390 [PR105266]
This test case pr105250.c is like its related pr105140.c, which
suffers the error with message like "{AltiVec,vector} argument
passed to unprototyped" on powerpc and s390. So like commits
r12-8025 and r12-8039, this fix is to add the dg-skip-if for
powerpc*-*-* and s390*-*-*.
gcc/testsuite/ChangeLog:
PR testsuite/105266
* gcc.dg/pr105250.c: Skip for powerpc*-*-* and s390*-*-*.
GCC Administrator [Mon, 18 Apr 2022 00:16:32 +0000 (00:16 +0000)]
Daily bump.
GCC Administrator [Sun, 17 Apr 2022 00:16:26 +0000 (00:16 +0000)]
Daily bump.
Gerald Pfeifer [Sat, 16 Apr 2022 13:29:34 +0000 (07:29 -0600)]
doc: Adjust mingw-w64 download link
gcc:
* doc/install.texi (Specific): Adjust mingw-w64 download link.
GCC Administrator [Sat, 16 Apr 2022 00:16:31 +0000 (00:16 +0000)]
Daily bump.
Ian Lance Taylor [Sat, 26 Mar 2022 00:23:50 +0000 (17:23 -0700)]
compiler: revert `for package-scope "a = b; b = x" just set "a = x"`
Revert CL 245098. It caused incorrect initialization ordering.
Adjust the runtime package to work even with the CL reverted.
Original description of CL 245098:
This avoids requiring an init function to initialize the variable.
This can only be done if x is a static initializer.
The go1.15rc1 runtime package relies on this optimization.
The package has a variable "var maxSearchAddr = maxOffAddr".
The maxSearchAddr variable is used by code that runs before package
initialization is complete.
For golang/go#51913
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/395994
Patrick Palka [Fri, 15 Apr 2022 18:41:14 +0000 (14:41 -0400)]
libstdc++: Avoid double-deref of __first in ranges::minmax [PR104858]
PR libstdc++/104858
libstdc++-v3/ChangeLog:
* include/bits/ranges_algo.h (__minmax_fn): Avoid dereferencing
__first twice at the start.
* testsuite/25_algorithms/minmax/constrained.cc (test06): New test.
Paul A. Clarke [Mon, 21 Feb 2022 18:24:58 +0000 (12:24 -0600)]
rs6000: Move more g++.dg powerpc tests to g++.target
Also adjust DejaGnu directives, as specifically requiring "powerpc*-*-*" is no
longer required.
2022-04-15 Paul A. Clarke <pc@us.ibm.com>
gcc/testsuite
* g++.dg/debug/dwarf2/const2.C: Move to g++.target/powerpc.
* g++.dg/other/darwin-minversion-1.C: Likewise.
* g++.dg/eh/ppc64-sighandle-cr.C: Likewise.
* g++.dg/eh/simd-5.C: Likewise.
* g++.dg/eh/simd-4.C: Move to g++.target/powerpc, adjust dg directives.
* g++.dg/eh/uncaught3.C: Likewise.
* g++.dg/other/spu2vmx-1.C: Likewise.
Marek Polacek [Thu, 14 Apr 2022 17:48:15 +0000 (13:48 -0400)]
c++: wrong error with variadic concept [PR105268]
Here we issue a wrong error for the
template<typename T = S<C_many<int>>> void g();
line in the testcase. I surmise that's because we mistakenly parse
C_many<int> as a placeholder-type-specifier, and things go wrong from
there. We are in a default argument so we should reject parsing C_many<int>
as a placeholder-type-specifier, which would mean creating a new parameter.
We want C_many<int> to be a concept-id instead.
It's interesting to see why the same problem didn't occur for C_one<int>.
In that case, cp_parser_placeholder_type_specifier -> finish_type_constraints
-> build_type_constraint -> build_concept_check -> build_standard_check ->
coerce_template_parms fails the parse here:
8916 nargs = inner_args ? NUM_TMPL_ARGS (inner_args) : 0;
8917 if ((nargs - variadic_args_p > nparms && !variadic_p)
8918 || (nargs < nparms - variadic_p
8919 && require_all_args
8920 && !variadic_args_p
8921 && (!use_default_args
8922 || (TREE_VEC_ELT (parms, nargs) != error_mark_node
8923 && !TREE_PURPOSE (TREE_VEC_ELT (parms, nargs))))))
8924 {
8925 bad_nargs:
...
8943 return error_mark_node;
because nargs is 2 (the targs are <WILDCARD_DECL, int>) while nparms is
1 (for the one 'typename' in the tparam list of C_one). But for
C_many<int> variadic_p is true so we don't return error_mark_node but
<type_argument_pack>.
This patch does not issue any error for the !tentative case because
I didn't figure out how to trigger that. So it adds an assert instead.
PR c++/105268
gcc/cp/ChangeLog:
* parser.cc (cp_parser_placeholder_type_specifier): Return
error_mark_node when trying to build up a constrained parameter in
a default argument.
gcc/testsuite/ChangeLog:
* g++.dg/concepts/variadic6.C: New test.
Patrick Palka [Fri, 15 Apr 2022 13:34:09 +0000 (09:34 -0400)]
libstdc++: Optimize integer std::from_chars
This applies the following optimizations to the integer std::from_chars
implementation:
1. Use a lookup table for converting an alphanumeric digit to its
base-36 value instead of using a range test (for 0-9) and switch
(for a-z and A-Z). The table is constructed using a C++14
constexpr function which doesn't assume a particular character
encoding or __CHAR_BIT__ value. This new conversion function
__from_chars_alnum_to_val is templated on whether we care
only about the decimal digits, in which case we can perform the
conversion with a single subtraction since the digit characters
are guaranteed to be contiguous (unlike the letters).
2. Generalize __from_chars_binary to handle all power-of-two bases.
This function (now named __from_chars_pow2_base) is also templated
on whether we care only about the decimal digits for the benefit of
faster digit conversion for base 2, 4 and 8.
3. In __from_chars_digit, use
static_cast<unsigned char>(__c - '0') < __base
instead of
'0' <= __c && __c <= ('0' + (__base - 1)).
as the digit recognition test (exhaustively verified that the two
tests are equivalent).
4. In __from_chars_alnum, use a nested loop to consume the rest of the
digits in the overflow case (mirroring __from_chars_digit) so that
the main loop doesn't have to maintain the overflow flag __valid.
At this point, __from_chars_digit is nearly identical to
__from_chars_alnum, so this patch merges the two functions by removing
the former and templatizing the latter according to whether we care only
about the decimal digits. Finally,
5. In __from_chars_alnum, maintain a lower bound on the number of
unused bits in the result and use it to omit the overflow check
when it's safe to do so.
In passing, this patch replaces the non-portable function ascii_to_hexit
used by __floating_from_chars_hex with the new conversion function.
Some runtime measurements for a simple 15-line benchmark that roundtrips
printing/parsing 200 million integers via std::to/from_chars (average of
5 runs):
Base Before After (seconds, lower is better)
2 9.37 9.37
3 15.79 12.13
8 4.15 3.67
10 4.90 3.86
11 6.84 5.03
16 4.14 2.93
32 3.85 2.39
36 5.22 3.26
libstdc++-v3/ChangeLog:
* include/std/charconv (__from_chars_alnum_to_val_table): Define.
(__from_chars_alnum_to_val): Define.
(__from_chars_binary): Rename to ...
(__from_chars_pow2_base): ... this. Generalize to handle any
power-of-two base using __from_chars_alnum_to_val.
(__from_chars_digit): Optimize digit recognition to a single
test instead of two tests. Use [[__unlikely___]] attribute.
(__from_chars_alpha_to_num): Remove.
(__from_chars_alnum): Use __from_chars_alnum_to_val. Use a
nested loop for the overflow case. Maintain a lower bound
on the number of available bits in the result and use it to
omit the overflow check.
(from_chars): Adjust appropriately.
* src/c++17/floating_from_chars.cc (ascii_to_hexit): Remove.
(__floating_from_chars_hex): Use __from_chars_alnum_to_val
to recognize a hex digit instead.
Hongyu Wang [Fri, 15 Apr 2022 02:51:06 +0000 (10:51 +0800)]
i386: Correct target attribute for crc32 intrinsics
Complile _mm_crc32_u8/16/32/64 intrinsics with -mcrc32
would meet target specific option mismatch. Correct target pragma
to fix.
gcc/ChangeLog:
* config/i386/smmintrin.h: Correct target pragma from sse4.1
and sse4.2 to crc32 for crc32 intrinsics.
gcc/testsuite/ChangeLog:
* gcc.target/i386/crc32-6.c: Adjust dg-error message.
* gcc.target/i386/crc32-7.c: New test.
Jason Merrill [Thu, 14 Apr 2022 21:49:47 +0000 (17:49 -0400)]
c++: unsigned int32_t enum promotion [PR102804]
There's been an extension for a long time to allow applying 'unsigned' to an
int typedef, but that was confusing the integer promotion code. Fixed by
forgetting about the typedef in that case.
I'm going to make this an unconditional pedwarn in stage 1.
PR c++/102804
gcc/cp/ChangeLog:
* decl.cc (grokdeclarator): Drop typedef used with 'unsigned'.
gcc/testsuite/ChangeLog:
* g++.dg/ext/unsigned-typedef1.C: New test.
Jason Merrill [Thu, 14 Apr 2022 21:35:35 +0000 (17:35 -0400)]
c++: using in diagnostics [PR102987]
The expression pretty-printing code crashed on a location wrapper with no
type, and didn't know what to do with a USING_DECL.
PR c++/102987
gcc/cp/ChangeLog:
* error.cc (dump_expr): Handle USING_DECL.
[VIEW_CONVERT_EXPR]: Just look through location wrapper.
gcc/testsuite/ChangeLog:
* g++.dg/diagnostic/using1.C: New test.
GCC Administrator [Fri, 15 Apr 2022 00:16:48 +0000 (00:16 +0000)]
Daily bump.
Joseph Myers [Thu, 14 Apr 2022 22:58:51 +0000 (22:58 +0000)]
Update gcc de.po, fr.po, sv.po
* de.po, fr.po, sv.po: Update.
David Malcolm [Thu, 14 Apr 2022 13:52:00 +0000 (09:52 -0400)]
analyzer: fix escaping of pointer arithmetic [PR105264]
PR analyzer/105264 reports that the analyzer can fail to treat
(PTR + IDX) and PTR[IDX] as referring to the same memory under
some situations.
There are various ways in which this can happen when IDX is a
symbolic value, due to having several ways in which such memory
regions can be referred to symbolically. I attempted to fix this by
being smarter when folding svalues and regions, but this fix
seems too fiddly to attempt in stage 4.
Instead, this less ambitious patch fixes a false positive from
-Wanalyzer-use-of-uninitialized-value by making the analyzer's escape
analysis smarter, so that it treats *PTR as escaping when
(PTR + OFFSET) is passed to an external function, and thus
it treats *PTR as possibly-initialized (the "passing &PTR[IDX]" case
was already working).
gcc/analyzer/ChangeLog:
PR analyzer/105264
* region-model-reachability.cc (reachable_regions::handle_parm):
Use maybe_get_deref_base_region rather than just region_svalue, to
handle pointer arithmetic also.
* svalue.cc (svalue::maybe_get_deref_base_region): New.
* svalue.h (svalue::maybe_get_deref_base_region): New decl.
gcc/testsuite/ChangeLog:
PR analyzer/105264
* gcc.dg/analyzer/torture/symbolic-10.c: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Ian Lance Taylor [Wed, 13 Apr 2022 21:37:12 +0000 (14:37 -0700)]
runtime: use regset indexes for PPC register values
Using names depended on <asm/ptrace.h>, which glibc includes somewhere
but musl did not. Change to just always use indexes.
Based on patch by Sören Tempel.
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/400214
Jason Merrill [Thu, 14 Apr 2022 19:34:14 +0000 (15:34 -0400)]
c++: constexpr trivial -fno-elide-ctors [PR104646]
The constexpr constructor checking code got confused by the expansion of a
trivial copy constructor; we don't need to do that checking for defaulted
ctors, anyway.
PR c++/104646
gcc/cp/ChangeLog:
* constexpr.cc (maybe_save_constexpr_fundef): Don't do extra
checks for defaulted ctors.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/constexpr-fno-elide-ctors1.C: New test.
Iain Sandoe [Thu, 14 Apr 2022 19:08:14 +0000 (20:08 +0100)]
libgccjit: Fix a bootstrap break for some targets.
Some targets use 'long long unsigned int' for unsigned HW int, and this
leads to a Werror=format= fail for two print cases in jit-playback.cc
introduced in r12-8117-g30f7c83e9cfe (Add support for bitcasts [PR104071])
As discussed on IRC, casting to (long) seems entirely reasonable for the
values (since they are type sizes).
tested that this fixes bootstrap on x86_64-darwin19 and running check-jit.
Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
gcc/jit/ChangeLog:
* jit-playback.cc (new_bitcast): Cast values returned by tree_to_uhwi
to 'long' to match the print format.
Jason Merrill [Thu, 14 Apr 2022 12:16:45 +0000 (08:16 -0400)]
c++: lambda and the current instantiation [PR82980]
When a captured variable is type-dependent, we've expressed the type of the
capture field and proxy with a decltype variant. But if the type is "the
current instantiation", we need to be able to see that so that we can do
lookup inside it just like we could with the captured variable itself.
I also tried looking through lambda capture in
cp_parser_postfix_dot_deref_expression, but this way seems cleaner. I plan
to treat more types as deducible in stage 1.
I considered also using this in do_auto_deduction, but think that would be
wrong: [temp.dep.expr] says an id-expression is type-dependent if it is
"associated by name lookup with a variable declared with a type that
contains a placeholder type where the initializer is type-dependent". That
doesn't clearly exclude deducing a dependent type from the initializer, but
it seems like a barrier, and other implementations agree.
PR c++/82980
gcc/cp/ChangeLog:
* lambda.cc (type_deducible_expression_p): New.
(lambda_capture_field_type): Check it.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/lambda/lambda-current-inst1.C: New test.
Indu Bhagat [Thu, 14 Apr 2022 17:02:45 +0000 (10:02 -0700)]
Refactor and update CTF testcases [PR105089]
This commit splits the ctf-array-2.c into ctf-array-5.c and
ctf-variables.c with the following responsibilities:
[1] ctf-array-2.c: Test CTF generation for unsized arrays.
[2] ctf-array-5.c: Test CTF generation for unsized but initialized array.
[3] ctf-variables-3.c: Test CTF generation for extern variable with defining
decl.
Earlier all three tests above were being done in ctf-array-2.c. The
checks around [3] were very loose in the original version of ctf-array-2.c
in that the testcase was only checking that the types are as expected. The
compiler was emitting two CTF variable records as follows:
Variables:
_CTF_NEWSTR -> 5: const const char [0] (size 0x0) -> 4: const char [0] (size 0x0)
_CTF_NEWSTR -> 8: const const char [8] (size 0x8) -> 7: const char [8] (size 0x8)
This is incorrect behaviour as it creates ambiguity. The testcase
ctf-variables-3.c now has added checks that only one CTF variable record
is expected.
2022-04-14 Indu Bhagat <indu.bhagat@oracle.com>
gcc/testsuite/ChangeLog:
PR debug/105089
* gcc.dg/debug/ctf/ctf-array-2.c: Refactor testcase. Move some
checks ...
* gcc.dg/debug/ctf/ctf-array-5.c: ... to here.
* gcc.dg/debug/ctf/ctf-variables-3.c: ... and here. Add
additional checks for one CTF variable and one CTF object info
record.
Indu Bhagat [Thu, 14 Apr 2022 17:01:22 +0000 (10:01 -0700)]
CTF for extern variable fix [PR105089]
The CTF format cannot differentiate between a non-defining extern
variable declaration vs. a defining variable declaration (unlike DWARF).
So, the correct behaviour wrt the compiler generating CTF for such
extern variables (i.e., when both the defining and non-defining decl
are present in the same CU) is to simply emit the CTF variable
correspoding to the defining declaration.
To carry out the above, following changes are introduced via the patch:
1. The CTF container (ctfc.h) now keeps track of the non-defining declarations
(by noting the DWARF attribute DW_AT_specification) in a new ctfc_ignore_vars
hashtable. Such book-keeping is necessary because the CTF container should
not rely on the order of DWARF DIEs presented to it at generation time.
2. At the time of ctf_add_variable (), the DW_AT_specification DIE if present
is added in the ctfc_ignore_vars hashtable. The CTF variable generation for
the defining declaration continues as normal.
3. If the ctf_add_variable () is asked to generate CTF variable for a DIE
present in the ctfc_ignore_vars, it skips generating CTF for it.
4. Recall that CTF variables are pre-processed before emission. Till now, the
only pre-processing that was being done was to sort them in order of their
names. Now an additional step is added: If the CTF variable which
corresponds to the non-defining declaration is indeed present in the ctfc_vars
hashtable (because the corresponding DWARF DIE was encountered first by the
CTF generation engine), skip that CTF variable from output.
An important side effect of such a workflow above is that CTF for the C type
of the non-defining decl will remain in the CTF dictionary (and will be
emitted in the output section as well). This type can be pruned by the
link-time de-duplicator as usual, if deemed unused.
2022-04-14 Indu Bhagat <indu.bhagat@oracle.com>
gcc/ChangeLog:
PR debug/105089
* ctfc.cc (ctf_dvd_ignore_insert): New function.
(ctf_dvd_ignore_lookup): Likewise.
(ctf_add_variable): Keep track of non-defining decl DIEs.
(new_ctf_container): Initialize the new hash-table.
(ctfc_delete_container): Empty hash-table.
* ctfc.h (struct ctf_container): Add new hash-table.
(ctf_dvd_ignore_lookup): New declaration.
(ctf_add_variable): Add additional argument.
* ctfout.cc (ctf_dvd_preprocess_cb): Skip adding CTF variable
record for non-defining decl for which a defining decl exists
in the same TU.
(ctf_preprocess): Defer updating the number of global objts
until here.
(output_ctf_header): Use ctfc_vars_list_count as some CTF
variables may not make it to the final output.
(output_ctf_vars): Likewise.
* dwarf2ctf.cc (gen_ctf_variable): Skip generating CTF variable
if this is known to be a non-defining decl DIE.
Indu Bhagat [Thu, 14 Apr 2022 17:00:25 +0000 (10:00 -0700)]
ctfc: get rid of the static variable in ctf_list_add_ctf_vars ()
2022-04-14 Indu Bhagat <indu.bhagat@oracle.com>
gcc/ChangeLog:
* ctfc.h (struct ctf_container): Introduce a new member.
* ctfout.cc (ctf_list_add_ctf_vars): Use it instead of static
variable.
Palmer Dabbelt [Thu, 14 Apr 2022 16:22:58 +0000 (17:22 +0100)]
libstdc++: Default to mutex-based atomics on RISC-V
The RISC-V port requires libatomic to be linked in order to resolve
various atomic functions, which results in builds that have
"--with-libstdcxx-lock-policy=auto" defaulting to mutex-based locks.
Changing this to direct atomics breaks the ABI, this forces the auto
detection mutex-based atomics on RISC-V in order to avoid a silent ABI
break for users.
See Bug 84568 for more discussion. In the long run there may be a way
to get the higher-performance atomics without an ABI flag day, but
that's going to be a much more complicated operation. We don't even
have support for the inline atomics yet, but given that some folks have
been discussing hacks to make these libatomic routines appear implicitly
it seems prudent to just turn off the automatic detection for RISC-V.
libstdc++-v3/ChangeLog:
* acinclude.m4 (GLIBCXX_ENABLE_LOCK_POLICY): Force auto to mutex
for RISC-V.
* configure: Regenerate.
Jonathan Wakely [Thu, 14 Apr 2022 10:54:26 +0000 (11:54 +0100)]
libstdc++: Fix incorrect IS number in doc comment
libstdc++-v3/ChangeLog:
* doc/xml/manual/intro.xml: Fix comment.
David Malcolm [Wed, 13 Apr 2022 16:02:07 +0000 (12:02 -0400)]
analyzer: fix ICE comparing VECTOR_CSTs [PR105252]
gcc/analyzer/ChangeLog:
PR analyzer/105252
* svalue.cc (cmp_cst): When comparing VECTOR_CSTs, compare the
types of the encoded elements before calling cmp_cst on them.
gcc/testsuite/ChangeLog:
PR analyzer/105252
* gcc.dg/analyzer/pr105252.c: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Jakub Jelinek [Thu, 14 Apr 2022 11:47:34 +0000 (13:47 +0200)]
simplify-rtx: Don't assume shift count has the same mode as the shift [PR105247]
The following testcase ICEs on ia64. It is UB at runtime, but we shouldn't
ICE on it...
The problem is that on ia64, the shift count (last operand of ASHIFT etc.)
is promoted to DImode (using zero-extension), while most other targets
use much narrower modes (say QImode). If we try to simplify a shift
and the shift count is CONST_INT or other VOIDmode integer constant
which isn't properly sign extended for the first operand's mode
(in the testcase the shift count is 0xfffffff8U and it is a SImode shift),
then we ICE during wide_int wop1 = pop1; in the first hunk, INTVAL == 0xfffffff8U
is not valid for SImode. I think in theory we could run into this even
on other targets, say if they use SImode or HImode shift counts for e.g.
QImode shifts. I hope word size is the upper bound of what a reasonable
target should use, using e.g. multiple registers for the shift count is
insane, so the following patch if op1 has VOIDmode and int_mode
is narrower than word uses word_mode for extraction of the value.
2022-04-14 Jakub Jelinek <jakub@redhat.com>
PR target/105247
* simplify-rtx.cc (simplify_const_binary_operation): For shifts
or rotates by VOIDmode constant integer shift count use word_mode
for the operand if int_mode is narrower than word.
* gcc.c-torture/compile/pr105247.c: New test.
Robin Dapp [Mon, 4 Apr 2022 12:28:56 +0000 (14:28 +0200)]
testsuite/s390: Silence warning in pr80725.c
This test case checks that we do not ICE but FAILs because of
-Wint-to-pointer-cast. Silence this warning.
gcc/testsuite/ChangeLog:
* gcc.target/s390/pr80725.c: Add -Wno-int-to-pointer-cast.
Robin Dapp [Tue, 12 Apr 2022 16:05:34 +0000 (18:05 +0200)]
s390: Add scheduler description for z16.
This patch adds the scheduler description for the z16 machine.
gcc/ChangeLog:
* config/s390/s390.cc (s390_get_sched_attrmask): Add z16.
(s390_get_unit_mask): Likewise.
(s390_is_fpd): Likewise.
(s390_is_fxd): Likewise.
* config/s390/s390.h (s390_tune_attr): Set max tune level to z16.
* config/s390/s390.md (z900,z990,z9_109,z9_ec,z10,z196,zEC12,z13,z14,z15):
Add z16.
(z900,z990,z9_109,z9_ec,z10,z196,zEC12,z13,z14,z15,z16):
Likewise.
* config/s390/3931.md: New file.
Jonathan Wakely [Thu, 14 Apr 2022 09:37:09 +0000 (10:37 +0100)]
libstdc++: Add new headers to <bits/stdc++.h> PCH
libstdc++-v3/ChangeLog:
* include/precompiled/stdc++.h: Include <stacktrace> and
<stdatomic.h> for C++23.
Jonathan Wakely [Thu, 14 Apr 2022 09:28:03 +0000 (10:28 +0100)]
libstdc++: Fix missing and incorrect feature test macros [PR105269]
libstdc++-v3/ChangeLog:
PR libstdc++/105269
* include/bits/stl_vector.h (__cpp_lib_constexpr_vector):
Define.
* include/c_compatibility/stdatomic.h (__cpp_lib_stdatomic_h):
Define.
* include/std/optional (__cpp_lib_optional): Define new value
for C++23.
(__cpp_lib_monadic_optional): Remove.
* include/std/version (__cpp_lib_constexpr_vector): Define.
(__cpp_lib_stdatomic_h): Define.
(__cpp_lib_optional): Define new value for C++23.
(__cpp_lib_monadic_optional): Remove.
* testsuite/20_util/optional/monadic/and_then.cc: Adjust.
* testsuite/20_util/optional/requirements.cc: Adjust for C++23.
* testsuite/20_util/optional/version.cc: Likewise.
* testsuite/23_containers/vector/cons/constexpr.cc: Check
feature test macro.
* testsuite/29_atomics/headers/stdatomic.h/c_compat.cc:
Likewise.
* testsuite/20_util/optional/monadic/version.cc: Removed.
* testsuite/23_containers/vector/requirements/version.cc: New test.
* testsuite/29_atomics/headers/stdatomic.h/version.cc: New test.
Jason Merrill [Thu, 14 Apr 2022 01:56:03 +0000 (21:56 -0400)]
c++: alignment of local typedef in template [PR65211]
Because common_handle_aligned_attribute only applies the alignment to the
TREE_TYPE of a typedef, not the DECL_ORIGINAL_TYPE, we need to copy it
explicitly in tsubst.
PR c++/65211
gcc/cp/ChangeLog:
* pt.cc (tsubst_decl) [TYPE_DECL]: Copy TYPE_ALIGN.
gcc/testsuite/ChangeLog:
* g++.target/i386/vec-tmpl1.C: New test.
Jason Merrill [Wed, 13 Apr 2022 20:42:25 +0000 (16:42 -0400)]
c++: local fn and generic lambda [PR97219]
When instantiating the op() for a generic lambda, we can no longer do name
lookup inside function scopes enclosing the lambda, so we need to remember
the lookup result from processing the definition of the lambda. So the code
in finish_call_expr to throw away the lookup result and instead look it up
again at instantiation time needs to be adjusted. The approach I take is to
only discard the result if the local extern comes from dependent scope; once
the enclosing function template is instantiated and we're regenerating the
lambda, then we can remember the result of lookup. We also need any default
arguments to be instantiated at that point.
PR c++/97219
gcc/cp/ChangeLog:
* name-lookup.cc (dependent_local_decl_p): New.
* cp-tree.h (dependent_local_decl_p): Declare.
* semantics.cc (finish_call_expr): Use it.
* pt.cc (tsubst_arg_types): Also substitute default args
for local externs.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1y/lambda-generic-local-fn1.C: New test.
Jason Merrill [Wed, 13 Apr 2022 18:49:04 +0000 (14:49 -0400)]
c++: template conversion op [PR101698]
Asking for conversion to a dependent type also makes a BASELINK dependent.
PR c++/101698
gcc/cp/ChangeLog:
* pt.cc (tsubst_baselink): Also check dependent optype.
gcc/testsuite/ChangeLog:
* g++.dg/template/conv19.C: New test.
Jason Merrill [Wed, 13 Apr 2022 17:23:08 +0000 (13:23 -0400)]
c++: NRV and ref-extended temps [PR101442]
This issue goes back to r83221, where the cleanup for extended ref temps
changed from being unconditional to being tied to the declaration they
formed part of the initializer for.
The named return value optimization changes the cleanup for the NRV variable
to only run on the EH path; we don't want that change to affect temporary
cleanups. The perform_member_init change isn't necessary (there 'decl' is a
COMPONENT_REF), it's just for consistency.
PR c++/101442
gcc/cp/ChangeLog:
* decl.cc (cp_finish_decl): Don't pass decl to push_cleanup.
* init.cc (perform_member_init): Likewise.
* semantics.cc (push_cleanup): Adjust comment.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/initlist-nrv1.C: New test.
Jason Merrill [Wed, 13 Apr 2022 16:44:54 +0000 (12:44 -0400)]
c++: add test [PR105265]
This was fixed by r12-1165, but good to have a test that doesn't need
-fno-elide-constructors.
PR c++/105265
PR c++/100838
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/initlist-new6.C: New test.
GCC Administrator [Thu, 14 Apr 2022 00:16:40 +0000 (00:16 +0000)]
Daily bump.
Ian Lance Taylor [Wed, 13 Apr 2022 21:41:50 +0000 (14:41 -0700)]
go.test: update issue10441.go to current upstream version
This test only needs to be compiled, not linked.
Richard Sandiford [Wed, 13 Apr 2022 16:53:54 +0000 (17:53 +0100)]
aarch64: Make sure the UF divides the VF [PR105254]
In this PR, we were trying to set the unroll factor to a value higher
than the minimum VF (or more specifically, to a value that doesn't
divide the VF). I guess there are two approaches to this: let the
target pick any value it likes and make target-independent code pare
it back to something that makes sense, or require targets to supply
sensible values from the outset. This patch goes for the latter
approach.
gcc/
PR tree-optimization/105254
* config/aarch64/aarch64.cc
(aarch64_vector_costs::determine_suggested_unroll_factor): Take a
loop_vec_info as argument. Restrict the unroll factor to values
that divide the VF.
(aarch64_vector_costs::finish_cost): Update call accordingly.
gcc/testsuite/
PR tree-optimization/105254
* g++.dg/vect/pr105254.cc: New test.
Tobias Burnus [Wed, 13 Apr 2022 16:40:52 +0000 (18:40 +0200)]
OpenMP/Fortran: Fix EXIT in loop diagnostic [PR105242]
gcc/fortran/ChangeLog:
PR fortran/105242
* match.cc (match_exit_cycle): Handle missing OMP LOOP, DO and SIMD
directives in the EXIT/CYCLE diagnostic.
gcc/testsuite/ChangeLog:
PR fortran/105242
* gfortran.dg/gomp/loop-exit.f90: New test.
Jason Merrill [Tue, 12 Apr 2022 21:46:59 +0000 (17:46 -0400)]
c++: empty base constexpr -fno-elide-ctors [PR105245]
The patch for 100111 extended our handling of empty base elision to the case
where the derived class has no other fields, but we still need to make sure
that there's some initializer for the derived object.
PR c++/105245
PR c++/100111
gcc/cp/ChangeLog:
* constexpr.cc (cxx_eval_store_expression): Build a CONSTRUCTOR
as needed in empty base handling.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1y/constexpr-empty2.C: Add -fno-elide-constructors.
Iain Buclaw [Wed, 13 Apr 2022 12:34:49 +0000 (13:34 +0100)]
d: Merge upstream dmd
4d1bfcf14, druntime
9ba9a6ae, phobos
c0cc5e917.
D front-end changes:
- Import dmd v2.099.1.
- Added `@mustuse' attribute, implmenting DIP 1038.
- Added `.tupleof` property for static arrays
D runtime changes:
- Import druntime v2.099.1.
Phobos changes:
- Import phobos v2.099.1.
- Zlib bindings have been updated to 1.2.12.
gcc/d/ChangeLog:
* Make-lang.in (D_FRONTEND_OBJS): Add d/common-bitfields.o,
d/mustuse.o.
* d-ctfloat.cc (CTFloat::isIdentical): Don't treat NaN values as
identical.
* dmd/MERGE: Merge upstream dmd
4d1bfcf14.
* expr.cc (ExprVisitor::visit (VoidInitExp *)): New.
libphobos/ChangeLog:
* libdruntime/MERGE: Merge upstream druntime
9ba9a6ae.
* src/MERGE: Merge upstream phobos
c0cc5e917.
Richard Biener [Wed, 13 Apr 2022 12:53:40 +0000 (14:53 +0200)]
tree-optimization/105263 - reassoc and DFP
reassoc has certain tricks which in the end depend on the ability
to undo them. For DFP creating a -1. constant is easy but
re-identifying is appearantly not - real_minus_onep rejects those
outright for DFP. So we have to disable (at least) this one trick.
2022-04-13 Richard Biener <rguenther@suse.de>
PR tree-optimization/105263
* tree-ssa-reassoc.cc (try_special_add_to_ops): Do not consume
negates in multiplication chains with DFP.
* gcc.dg/pr105263.c: New testcase.
Jakub Jelinek [Wed, 13 Apr 2022 13:44:51 +0000 (15:44 +0200)]
tree.cc: Use useless_type_conversion_p in tree_builtin_call_types_compatible_p while in gimple form [PR105253]
tree_builtin_call_types_compatible_p uses TYPE_MAIN_VARIANT comparisons
or tree_nop_conversion_p to ensure a builtin has correct GENERIC arguments.
Unfortunately this regressed when get_call_combined_fn is called during
GIMPLE optimizations. E.g. when number_of_iterations_popcount is called,
it doesn't ensure TYPE_MAIN_VARIABLE compatible argument type, it picks
__builtin_popcount{,l,ll} based just on types' precision and doesn't
fold_convert the arg to the right type. We are in GIMPLE, such conversions
are useless...
So, either we'd need to fix number_of_iterations_popcount to add casts
and inspect anything else that creates CALL_EXPRs late, or we can
in tree_builtin_call_types_compatible_p just use the GIMPLE type
comparisons (useless_type_conversion_p) when we are in GIMPLE form and
the TYPE_MAIN_VARIANT comparison or tree_nop_conversion_p test otherwise.
I think especially this late in stage4 the latter seems safer to me.
2022-04-13 Jakub Jelinek <jakub@redhat.com>
PR middle-end/105253
* tree.cc (tree_builtin_call_types_compatible_p): If PROP_gimple,
use useless_type_conversion_p checks instead of TYPE_MAIN_VARIANT
comparisons or tree_nop_conversion_p checks.
* gcc.target/i386/pr105253.c: New test.
Jakub Jelinek [Wed, 13 Apr 2022 13:43:34 +0000 (15:43 +0200)]
c++: Treat alignas align_expr and aligned attribute's operand as manifestly constant evaluation [PR105233]
The following testcase fails, because we only constant evaluate the
alignas argument as non-manifestly constant-evaluated and as
__builtin_is_constant_evaluated appears, we make it non-constant
(the reason is that we often try to evaluate some expression without
manifestly_const_eval perhaps even multiple times before actually
evaluating it with manifestly_const_eval (e.g. when folding for warnings
and in many other places), and we don't want __builtin_is_constant_evaluated
to evaluate to false in those cases, because we could get a different
result from when we actually evaluate it with manifestly_const_eval
set).
Now, for alignas the standard seems to be clear, it says the
argument is constant-expression, which means we should
manifestly-constant-eval it.
Attributes are a fuzzy area, they are extensions and various attributes
take e.g. identifiers, or string literals etc. as arguments.
Either we can just treat alignas as manifestly-const-eval, for that
we'd need some way how to differentiate between alignas and gnu::aligned
or aligned attribute.
Another possibility is what the patch below implements, treat
both alignas and gnu::aligned and aligned attribute's argument as
manifestly-const-eval and not do that for other attributes.
Another is to go through all attributes and figure out for which
such treatment is useful (e.g. those that expect INTEGER_CST as argument),
and either add a new column in the attribute table or have another table
in the C++ FE to find out which attribute needs that.
Another is do that for all the attribute arguments that are EXPR_P
and see what breaks (bet that it could be quite risky this late in
GCC 12 cycle and especially for backporting).
2022-04-13 Jakub Jelinek <jakub@redhat.com>
PR c++/105233
* decl2.cc (cp_check_const_attributes): For aligned attribute
pass manifestly_const_eval=true to fold_non_dependent_expr.
* g++.dg/cpp2a/is-constant-evaluated13.C: New test.
Martin Jambor [Wed, 13 Apr 2022 13:08:59 +0000 (15:08 +0200)]
testsuite: Increase auto-inlining param in gcc.dg/ipa/remref-7.c (PR 105183)
A scan dump of testsuite gcc.dg/ipa/remref-7.c fails on a number of
platforms. I investigated only i?86-*-* with -mno-sse but assume the
issue is the same on all of the affected platform.
Because function bar is not inlined there even though it is only
called once, the process that is being tested is simply not triggered.
This can be "fixed" by increasing parameter max-inline-insns-auto to
something high, I randomly picked 100.
I have only manually tested the change but hopefully that is enough.
gcc/testsuite/ChangeLog:
2022-04-08 Martin Jambor <mjambor@suse.cz>
PR testsuite/105183
* gcc.dg/ipa/remref-7.c: Add --param max-inline-insns-auto=100 to options.
Marek Polacek [Tue, 12 Apr 2022 21:30:30 +0000 (17:30 -0400)]
c++: ambiguous call not diagnosed after DR2352 [PR97296]
DR 2352 changed the definitions of reference-related (so that it uses
"similar type" instead of "same type") and of reference-compatible (use
a standard conversion sequence). That means that reference-related is
now more broad, which means that we will be binding more things directly.
The original patch for DR 2352 caused some problems, which were fixed in
r276251 by creating a "fake" ck_qual in direct_reference_binding, so
that in
void f(int *); // #1
void f(const int * const &); // #2
int *x;
int main()
{
f(x); // call #1
}
we call #1. The extra ck_qual in #2 causes compare_ics to select #1,
which is a better match for "int *" because then we don't have to do
a qualification conversion.
Let's turn to the problem in this PR. We have
void f(const int * const &); // #1
void f(const int *); // #2
int *x;
int main()
{
f(x);
}
We arrive in compare_ics to decide which one is better. The ICS for #1
looks like
ck_ref_bind <- ck_qual <- ck_identity
const int *const & const int *const int *
and the ICS for #2 is
ck_qual <- ck_rvalue <- ck_identity
const int * int * int *
We strip the reference and then comp_cv_qual_signature when comparing two
ck_quals sees that "const int *" is a proper subset of "const int *const"
and we return -1. But that's wrong; presumably the top-level "const"
should be ignored and the call should be ambiguous. This patch adjust
the type of the "fake" ck_qual so that this problem doesn't arise.
PR c++/97296
gcc/cp/ChangeLog:
* call.cc (direct_reference_binding): strip_top_quals when creating
a ck_qual.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/ref-bind4.C: Add dg-error.
* g++.dg/cpp0x/ref-bind8.C: New test.
Richard Biener [Wed, 13 Apr 2022 08:41:41 +0000 (10:41 +0200)]
middle-end/105259 - adjust gcc.target/i386/auto-init-4.c
This adjusts the FAILing testcase to only check for the pieces
that work. The bug tracks improving pattern-init for long double.
2022-04-13 Richard Biener <rguenther@suse.de>
PR middle-end/105259
* gcc.target/i386/auto-init-4.c: Adjust.
Hongyu Wang [Wed, 13 Apr 2022 06:51:36 +0000 (14:51 +0800)]
i386: Fix infinite loop under -mrelax-cmpxchg-loop [PR 103069]
For -mrelax-cmpxchg-loop which relaxes atomic_fetch_<logic> loops,
there is a missing set to %eax when compare fails, which would result
in infinite loop in some benchmark. Add set to %eax to avoid it.
gcc/ChangeLog:
PR target/103069
* config/i386/i386-expand.cc (ix86_expand_cmpxchg_loop):
Add missing set to target_val at pause label.
Jakub Jelinek [Wed, 13 Apr 2022 08:12:56 +0000 (10:12 +0200)]
attribs: Restrict decl_attributes DECL_FUNCTION_SPECIFIC_TARGET changes to targets that care about target attributes/pragmas [PR105234]
The following code is rejected e.g. on mips64el-linux (but I think many
other targets which don't support target attribute or pragma).
The problem is that the change to decl_attributes below is done
unconditionally and with just #pragma GCC push_options/pop_options pair
we have target_option_default_node NULL, but after popping options
target_option_current_node becomes non-NULL and this decl_attribute
spot fills in DECL_FUNCTION_SPECIFIC_TARGET of a subset of a functions.
Those appearing before push_options/pop_options will have it NULL and
as target_option_default_node is also NULL on those targets, the default
can_inline_p will refuse to inline any functions defined with NULL
DECL_FUNCTION_SPECIFIC_TARGET into any function with non-NULL
DECL_FUNCTION_SPECIFIC_TARGET (even when nothing in the options really
changed).
The following patch restricts that snippet to targets that care (initialize
target_option_default_node to non-NULL to the command line options early)
which include all targets that actually implement target attribute and/or
pragma.
2022-04-13 Jakub Jelinek <jakub@redhat.com>
PR target/105234
* attribs.cc (decl_attributes): Don't set
DECL_FUNCTION_SPECIFIC_TARGET if target_option_default_node is
NULL.
* gcc.c-torture/compile/pr105234.c: New test.
Richard Biener [Wed, 13 Apr 2022 06:52:57 +0000 (08:52 +0200)]
tree-optimization/105250 - adjust fold_convertible_p PR105140 fix
The following reverts the original PR105140 fix and goes for instead
applying the additional fold_convert constraint for VECTOR_TYPE
conversions also to fold_convertible_p. I did not try sanitizing
all of this at this point.
2022-04-13 Richard Biener <rguenther@suse.de>
PR tree-optimization/105250
* fold-const.cc (fold_convertible_p): Revert
r12-7979-geaaf77dd85c333, instead check for size equality
of the vector types involved.
* gcc.dg/pr105250.c: New testcase.
Richard Biener [Wed, 13 Apr 2022 07:54:58 +0000 (09:54 +0200)]
Revert "tree-optimization/104912 - ensure cost model is checked first"
This reverts commit
ac8340ee4d1e65f3fd41c547b16895875f4aefa7.
Richard Biener [Mon, 21 Mar 2022 13:08:25 +0000 (14:08 +0100)]
tree-optimization/104912 - ensure cost model is checked first
The following makes sure that when we build the versioning condition
for vectorization including the cost model check, we check for the
cost model and branch over other versioning checks. That is what
the cost modeling assumes, since the cost model check is the only
one accounted for in the scalar outside cost. Currently we emit
all checks as straight-line code combined with bitwise ops which
can result in surprising ordering of checks in the final assembly.
Since loop_version accepts only a single versioning condition
the splitting is done after the fact.
The result is a 1.5% speedup of 416.gamess on x86_64 when compiling
with -Ofast and tuning for generic or skylake. That's not enough
to recover from the slowdown when vectorizing but it now cuts off
the expensive alias versioning test.
2022-03-21 Richard Biener <rguenther@suse.de>
PR tree-optimization/104912
* tree-vect-loop-manip.cc (vect_loop_versioning): Split
the cost model check to a separate BB to make sure it is
checked first and not combined with other version checks.
Jakub Jelinek [Wed, 13 Apr 2022 07:47:45 +0000 (09:47 +0200)]
scev: Fix a comment typo
When looking at the kernel __popcountdi2 issue, I've noticed a comment typo.
2022-04-13 Jakub Jelinek <jakub@redhat.com>
* tree-scalar-evolution.cc (expression_expensive_p): Fix a comment typo.
Jakub Jelinek [Wed, 13 Apr 2022 07:46:53 +0000 (09:46 +0200)]
libgomp: Fix a documentation typo
This fixes a typo in the 5.0 feature support table.
2022-04-13 Jakub Jelinek <jakub@redhat.com>
* libgomp.texi: Fix a typo - mutexinouset -> mutexinoutset.
Alexandre Oliva [Wed, 13 Apr 2022 01:41:46 +0000 (22:41 -0300)]
ppc: testsuite: skip pr60203 on no ldbl128
If neither 128-bit long double format is available, skip pr60203.c.
for gcc/testsuite/ChangeLog
* gcc.target/powerpc/pr60203.c: Skip on no 128-bit long double.
Alexandre Oliva [Wed, 13 Apr 2022 01:41:45 +0000 (22:41 -0300)]
ppc: testsuite: PROMOTE_MODE fallout pr56605 [PR102146]
The test expects a compare of DImode values, but after the removal of
PROMOTE_MODE from rs6000/, we get SImode. Adjust the expectations.
for gcc/testsuite/ChangeLog
PR target/102146
* gcc.target/powerpc/pr56605.c: Accept SImode compare operand.
Xi Ruoyao [Wed, 6 Apr 2022 22:38:47 +0000 (06:38 +0800)]
mips: testsuite: enforce -ffat-lto-objects for pr102024-4.c
The body of func is optimized away with -flto -fno-fat-lto-objects, so
the psABI inform is not emitted, causing a test failure.
gcc/testsuite/
* gcc.target/mips/pr102024-4.c (dg-options): Add
-ffat-lto-objects.
GCC Administrator [Wed, 13 Apr 2022 00:16:34 +0000 (00:16 +0000)]
Daily bump.
Jonathan Wakely [Tue, 12 Apr 2022 16:56:45 +0000 (17:56 +0100)]
libstdc++: Prefer to use mmap instead of malloc in libbacktrace
As reported in PR libbacktrace/105240, libbacktrace leaks memory when
using malloc for allocations. I originally thought it would be simpler
to just use malloc unconditionally (because it's supported on all
targets) but the leaks make that problematic.
This adds libbacktrace's detection for mmap to the libstdc++
configury, so that we use mmap.c and mmapio.c when possible. This avoids
the leaks seen previously, at least on linux.
libstdc++-v3/ChangeLog:
* acinclude.m4 (GLIBCXX_ENABLE_BACKTRACE): Check for mmap.
* config.h.in: Regenerate.
* configure: Regenerate.
Jonathan Wakely [Tue, 12 Apr 2022 16:17:20 +0000 (17:17 +0100)]
libstdc++: shrink-to-fit in std::basic_stacktrace::current(skip, max)
If a large stacktrace is reduced to a max depth that is less than half
the capacity it will now be reallocated to remove the unused capacity.
libstdc++-v3/ChangeLog:
* include/std/stacktrace (basic_stacktrace::current): Reallocate
a smaller container if the unused capacity is larger than the
used size.
Jonathan Wakely [Tue, 12 Apr 2022 15:48:31 +0000 (16:48 +0100)]
libstdc++: Use allocator to construct std::stacktrace_entry objects
Because std::basic_stacktrace<A> is an allocator-aware container its
elements should be initialized using allocator_traits<A>::construct and
destroyed using allocator_traits<A>::destroy.
This adds new _M_clone and _M_assign helper functions to construct
elements correctly and uses those functions instead of calling
std::uninitialized_copy_n.
The _Impl::_M_destroy function needs to be passed an allocator to
destroy the elements correctly, so is replaced by _M_resize which can
also be used to trim the container to a smaller size.
Because destroying and creating std::stacktrace_entry objects is cheap,
the copy/move assignment operators can just destroy all existing
elements and use _Impl._M_clone or _Impl._M_assign to create new ones.
libstdc++-v3/ChangeLog:
* include/std/stacktrace (basic_stacktrace): Use _Impl::_M_clone
or _Impl::_M_assign to initialize elements in allocated storage.
(basic_stacktrace::_M_clear()): Use _Impl::_M_resize instead of
_Impl::_M_destroy.
(basic_stacktrace::_Impl::_M_destroy()): Replace with ...
(basic_stacktrace::_Impl::_M_resize(size_type, allocator&)): New
function.
(basic_stacktrace::_Impl::_M_push_back): Use _M_xclone. Construct
new element using allocator.
(basic_stacktrace::_Impl::_M_clone): New function.
(basic_stacktrace::_Impl::_M_xclone): New function.
(basic_stacktrace::_Impl::_M_assign): New function.
Jonathan Wakely [Tue, 12 Apr 2022 09:35:43 +0000 (10:35 +0100)]
libstdc++: Use nothrow new in std::stacktrace
We can avoid the overhead of handling a bad_alloc exception from
std::allocator<std::stacktrace_entry>::allocate by just calling the
nothrow operator new instead.
libstdc++-v3/ChangeLog:
* include/std/stacktrace (basic_stacktrace::_Impl::_M_allocate):
Use nothrow new instead of try block for std::allocator.
(basic_stacktrace::_Impl::_M_deallocate): Use delete for
std::allocator.
Jonathan Wakely [Mon, 11 Apr 2022 20:15:40 +0000 (21:15 +0100)]
libstdc++: Reduce memory usage in std::stacktrace::current
This adds an alternative callback for use in the overload of
basic_stacktrace::current that takes a max_depth parameter. The new
callback will not allow the container to grow past the initial capacity,
which is set to the specified maximum depth. This avoids allocating
memory for hundreds of frames only to discard them again because of a
small maximum depth limit.
For larger maximum depths the normal callback is used, with a smaller
initial capacity that can grow as needed. The container will be resized
to the given max depth after the entire backtrace has been produced
(relying on the fact that std::stacktrace_entry objects are trivially
destructible to elide their destruction).
Currently the value for "larger" limits is 128, so a max depth <= 128
will allocate capacity for exactly that many frames. A larger max depth
(or an unspecified max depth) will use an initial capacity of 64 frames
and grow as needed. Since each frame is only a uintptr_t value it might
be reasonable to increase the first value so that memory usage can be
capped for larger maximum depths.
This change also delays the creation of the libbacktrace state until we
actually need it, so that the state is not created if allocation fails.
libstdc++-v3/ChangeLog:
* include/std/stacktrace (basic_stacktrace::current): Replace
calls to _M_reserve and _S_curr_cb with call to _M_prepare.
Check return value of backtrace_simple when max depth given.
(basic_stacktrace::_M_reserve): Remove.
(basic_stacktrace::_S_curr_cb): Remove.
(basic_stacktrace::_M_prepare(size_type)): New function to
reserve initial capacity and return callback.
(basic_stacktrace::_Impl::_M_allocate): Remove check for 0 < n
and remove redundant zeroing of _M_frames and _M_capacity.
(basic_stacktrace::_Impl::_M_push_back): Add [[unlikely]]
attribute. Assign _Impl instead of swapping.
* testsuite/19_diagnostics/stacktrace/current.cc: New test.
Antoni Boucher [Tue, 12 Apr 2022 21:25:04 +0000 (17:25 -0400)]
libgccjit: Add support for setting the alignment [PR104293]
gcc/jit/
PR jit/104293
* docs/_build/texinfo/libgccjit.texi: Regenerate.
* docs/topics/compatibility.rst (LIBGCCJIT_ABI_24): New ABI tag.
* docs/topics/expressions.rst: Add documentation for the
functions gcc_jit_lvalue_set_alignment and
gcc_jit_lvalue_get_alignment.
* jit-playback.h: New function (set_alignment).
* jit-recording.cc: New function (set_alignment).
* jit-recording.h: New functions (set_alignment, get_alignment)
and new field (m_alignment).
* libgccjit.cc: New functions (gcc_jit_lvalue_get_alignment,
gcc_jit_lvalue_set_alignment)
* libgccjit.h: New functions (gcc_jit_lvalue_get_alignment,
gcc_jit_lvalue_set_alignment)
* libgccjit.map (LIBGCCJIT_ABI_24): New ABI tag.
gcc/testsuite/
PR jit/104293
* jit.dg/all-non-failing-tests.h: Mention
test-setting-alignment.
* jit.dg/test-setting-alignment.c: New test.