The following testcase FAILs, because replace_rtx replaces a REG with
CONST_WIDE_INT inside of a SUBREG, which is an invalid transformation
because a SUBREG relies on SUBREG_REG having non-VOIDmode but
CONST_WIDE_INT has VOIDmode.
replace_rtx already has code to deal with it, but it was doing
it only for CONST_INTs. The following patch does it also for
VOIDmode CONST_DOUBLE or CONST_WIDE_INT.
2022-04-22 Jakub Jelinek <jakub@redhat.com>
PR rtl-optimization/105333
* rtlanal.cc (replace_rtx): Use simplify_subreg or
simplify_unary_operation if CONST_SCALAR_INT_P rather than just
CONST_INT_P.
* gcc.dg/pr105333.c: New test.
This testcase does not generate anywhere near optimal code for 32-bit
code. For p10 it actually now fails this testcase, after the previous
patch. Let's xfail it.
2022-04-21 Segher Boessenkool <segher@kernel.crashing.org>
gcc/testsuite/
PR target/103197
PR target/102146
* gcc.target/powerpc/bswap-brw.c: Add xfail on scan-assembler for -m32.
RA now chooses GEN_OR_VSX_REGS in most cases. This is great in most
cases, but we often (or always?) use {l,st}{f,xs}iwzx now, which is
problematic because the integer load and store insns can use cheaper
addressing modes. We can fix that by putting a small penalty on the
instruction alternatives for those.
2022-04-21 Segher Boessenkool <segher@kernel.crashing.org>
PR target/103197
PR target/102146
* config/rs6000/rs6000.md (zero_extendqi<mode>2 for EXTQI): Disparage
the "Z" alternatives in {l,st}{f,xs}iwzx.
(zero_extendhi<mode>2 for EXTHI): Ditto.
(zero_extendsi<mode>2 for EXTSI): Ditto.
(*movsi_internal1): Ditto.
(*mov<mode>_internal1 for QHI): Ditto.
(movsd_hardfloat): Ditto.
This is true if we have -mpowerpc64.
2022-04-21 Segher Boessenkool <segher@kernel.crashing.org>
gcc/testsuite/
* lib/target-supports.exp (check_effective_target_has_arch_ppc64): New.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
...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.
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
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
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.
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*-*-*.
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
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.
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.
