The bitfield-struct t0 in gcc.dg/pr94600-1.c ..-4.c is assigned to a
pointer that is a (volatile-and-pointer-)cast literal, so gcc doesn't
need to be otherwise told that the address is aligned. But, variants
pr94600-5.c ..-8.c are assigned through a "volatile t0 *", and rely on
the *type* being naturally aligned, or that the machine has
non-strict-alignment moves.
Unfortunately, systems exist (for some definitions of exist) where
such structs aren't always naturally aligned, for example if it
contains only (small) bitfields, even though the size is a naturally
accessible size. Specifically, the mmix-knuth-mmixware port has only
*byte* alignment for this struct. (If an int is added to the struct,
alignment is promoted.) IOW, a prerequisite of the test is false: the
struct doesn't have the same alignment as an integer of the same size.
The effect is assignment in byte-size pieces, and the test fails.
(For a non-volatile assignment, memcpy is called.) That's easily
fixable by defining the type as having a specific alignment. This is
also closer to the type in the original code, and also as the first
variants aren't affected, no second thought or re-visit of pre-fixed
compiler is needed. I don't plan to back-port this to gcc-10 branch
however. I did sanity-check that the tests still pass on
ppc64le-linux.
gcc/testsuite:
PR middle-end/94600
* gcc.dg/pr94600-5.c, gcc.dg/pr94600-6.c, gcc.dg/pr94600-7.c,
gcc.dg/pr94600-8.c: Align t0 to 4-byte boundary.
P1975R0 tweaks the static_cast wording: it says that "An expression e can be
explicitly converted to a type T if [...] T is an aggregate type having a first
element x and there is an implicit conversion sequence from e to the type of
x." This already works for classes, e.g.:
struct Aggr { int x; int y; };
Aggr a = static_cast<Aggr>(1);
for which we create TARGET_EXPR <D.2111, {.x=1}>.
The proposal also mentions "If T is ``array of unknown bound of U'',
this direct-initialization defines the type of the expression as U[1]" which
suggest that this should work for arrays (they're aggregates too, after all):
int (&&r)[3] = static_cast<int[3]>(42);
int (&&r2)[1] = static_cast<int[]>(42);
So I handled that specifically in build_static_cast_1: wrap the
expression in { } and initialize from that. For the 'r' case above
this creates TARGET_EXPR <D.2083, {42}>.
There are multiple things in play, as usual, so the tests test brace
elision, narrowing, explicit constructors, and lifetime extension too.
I think it's in line with what we discussed on the core reflector.
gcc/cp/ChangeLog:
PR c++/92812
* typeck.c (build_static_cast_1): Implement P1975R0 by allowing
static_cast to aggregate type.
gcc/testsuite/ChangeLog:
PR c++/92812
* g++.dg/cpp2a/paren-init27.C: New test.
* g++.dg/cpp2a/paren-init28.C: New test.
* g++.dg/cpp2a/paren-init29.C: New test.
* g++.dg/cpp2a/paren-init30.C: New test.
* g++.dg/cpp2a/paren-init31.C: New test.
* g++.dg/cpp2a/paren-init32.C: New test.
The following patch tightens the predicates of the peephole2 from my recent
"Integer min/max improvements patch" to only hoist clearing a register when
that register is a general register. Calling ix86_expand_clear with regs
other than GENERAL_REGS is not supported.
2020-08-12 Roger Sayle <roger@nextmovesoftware.com>
Uroš Bizjak <ubizjak@gmail.com>
gcc/ChangeLog
PR target/96558
* config/i386/i386.md (peephole2): Only reorder register clearing
instructions to allow use of xor for general registers.
gcc/testsuite/ChangeLog
PR target/96558
* gcc.dg/pr96558.c: New test.
The C++ LWG recently confirmed that self-move assignment should not have
undefined behaviour for standard containers (see the proposed resolution
of LWG 2839). The result should be a valid but unspecified value, just
like other times when a container is moved from.
Our std::list, std::__cxx11::basic_string and unordered containers all
have bugs which result in undefined behaviour.
For std::list the problem is that we clear the previous contents using
_M_clear() instead of clear(). This means the _M_next, _M_prev and
_M_size members are not zeroed, and so after we "update" them (with
their existing values), we are left with dangling pointers and a
non-zero size, but no elements.
For the unordered containers the problem is similar. _Hashtable first
deallocates the existing contents, then takes ownership of the pointers
from the RHS object (which has just had its contents deallocated so the
pointers are dangling).
For std::basic_string it's a little more subtle. When the string is
local (i.e. fits in the SSO buffer) we use char_traits::copy to copy the
contents from this->data() to __rhs.data(). When &__rhs == this that
copy violates the precondition that the ranges don't overlap. We only
need to check for self-move for this case where it's local, because the
only other case that can be true for self-move is that it's non-local
but the allocators compare equal. In that case the data pointer is
neither deallocated nor leaked, so the result is well-defined.
This patch also makes a small optimization for std::deque move
assignment, to use the efficient move when is_always_equal is false, but
the allocators compare equal at runtime.
Finally, we need to remove all the Debug Mode checks which abort the
program when a self-move is detected, because it's not undefined to do
that.
Before PR 85828 can be closed we should also look into fixing
std::shuffle so it doesn't do any redundant self-swaps.
libstdc++-v3/ChangeLog:
PR libstdc++/85828
* include/bits/basic_string.h (operator=(basic_string&&)): Check
for self-move before copying with char_traits::copy.
* include/bits/hashtable.h (operator=(_Hashtable&&)): Check for
self-move.
* include/bits/stl_deque.h (_M_move_assign1(deque&&, false_type)):
Check for equal allocators.
* include/bits/stl_list.h (_M_move_assign(list&&, true_type)):
Call clear() instead of _M_clear().
* include/debug/formatter.h (__msg_self_move_assign): Change
comment.
* include/debug/macros.h (__glibcxx_check_self_move_assign):
(_GLIBCXX_DEBUG_VERIFY): Remove.
* include/debug/safe_container.h (operator=(_Safe_container&&)):
Remove assertion check for safe move and make it well-defined.
* include/debug/safe_iterator.h (operator=(_Safe_iterator&&)):
Remove assertion check for self-move.
* include/debug/safe_local_iterator.h
(operator=(_Safe_local_iterator&&)): Likewise.
* testsuite/21_strings/basic_string/cons/char/self_move.cc: New test.
* testsuite/23_containers/deque/cons/self_move.cc: New test.
* testsuite/23_containers/forward_list/cons/self_move.cc: New test.
* testsuite/23_containers/list/cons/self_move.cc: New test.
* testsuite/23_containers/set/cons/self_move.cc: New test.
* testsuite/23_containers/unordered_set/cons/self_move.cc: New test.
* testsuite/23_containers/vector/cons/self_move.cc: New test.
As mentioned in the PR, let's consider the following example:
int
__attribute__((noinline))
foo(int arg)
{
if (arg == 3)
return 1;
if (arg == 4)
return 123;
__builtin_unreachable ();
}
during WPA we find all calls of the function
(yes the call with value 5 is UBSAN):
Node: foo/0:
param [0]: 5 [loc_time: 4, loc_size: 2, prop_time: 0, prop_size: 0]
3 [loc_time: 3, loc_size: 3, prop_time: 0, prop_size: 0]
ctxs: VARIABLE
Bits: value = 0x5, mask = 0x6
in LTRANS we have the following VRP info:
# RANGE [3, 3] NONZERO 3
when we AND masks in get_default_value we end up with 6 & 3 = 2 (0x010).
That means the only second (least significant bit) is unknown and
value (5 = 0x101) & ~mask gives us either 7 (0x111) or 5 (0x101).
That's why if (arg_2(D) == 3) gets optimized to false.
gcc/ChangeLog:
PR ipa/96482
* ipa-cp.c (ipcp_bits_lattice::meet_with_1): Drop value bits
for bits that are unknown.
(ipcp_bits_lattice::set_to_constant): Likewise.
* tree-ssa-ccp.c (get_default_value): Add sanity check that
IPA CP bit info has all bits set to zero in bits that
are unknown.
gcc/testsuite/ChangeLog:
PR ipa/96482
* gcc.dg/ipa/pr96482.c: New test.
Report diagnostic information instead of ICE if it generats fp/simd for
return register when fp/simd is disabled by -mgeneral-regs-only.
gcc/ChangeLog:
* config/aarch64/aarch64.c (aarch64_function_value): Add if
condition to check ag_mode after entering if condition of
aarch64_vfp_is_call_or_return_candidate. If TARGET_FLOAT is
set as false by -mgeneral-regs-only, report the diagnostic
information of -mgeneral-regs-only imcompatible with the use
of fp/simd register(s).
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/mgeneral-regs_1.c: Add the comment that
-mgeneral-regs-only is compatible with the use of vector type
used in the test case.
As the testcase in the PR shows (not included in the patch, as
it seems quite fragile to observe unrolling in the IL), the introduction of
flag_cunroll_grow_size broke optimize attribute related to loop unrolling.
The problem is that the new option flag is set (if not set explicitly) only
in process_options and in rs6000_option_override_internal (and there only if
global_init_p). So, this means that while it is Optimization option, it
will only be set based on the command line -funroll-loops/-O3/-fpeel-loops
or -funroll-all-loops, which means that if command line does include any of
those, it is enabled even for functions that will through optimize attribute
have all of those disabled, and if command line does not include those,
it will not be enabled for functions that will through optimize attribute
have any of those enabled.
process_options is called just once, so IMHO it should be handling only
non-Optimization option adjustments (various other options suffer from that
too, but as this is a regression from 10.1 on the 10 branch, changing those
is not appropriate). Similarly, rs6000_option_override_internal is called
only once (with global_init_p) and then for target attribute handling, but
not for optimize attribute handling.
This patch moves the unrolling related handling from process_options into
finish_options which is invoked whenever the options are being finalized,
and the rs6000 specific parts into the override_options_after_change hook
which is called for optimize attribute handling (and unfortunately also
th cfun changes, but what the hook does is cheap) and I've added a call to
that from rs6000_override_options_internal, so it is also called on cmdline
processing and for target attribute.
Furthermore, it stops using AUTODETECT_VALUE, which can work only once,
and instead uses the global_options_set.x_... flags.
2020-08-12 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/96535
* toplev.c (process_options): Move flag_unroll_loops and
flag_cunroll_grow_size handling from here to ...
* opts.c (finish_options): ... here. For flag_cunroll_grow_size,
don't check for AUTODETECT_VALUE, but instead check
opts_set->x_flag_cunroll_grow_size.
* common.opt (funroll-completely-grow-size): Default to 0.
* config/rs6000/rs6000.c (TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE):
Redefine.
(rs6000_override_options_after_change): New function.
(rs6000_option_override_internal): Call it. Move there the
flag_cunroll_grow_size, unroll_only_small_loops and
flag_rename_registers handling.
In absence of nvptx-enabling for effective target sync_int_long (see PR96494),
copy a few test-cases to gcc.target/nvptx.
Tested on nvptx.
gcc/testsuite/ChangeLog:
* gcc.target/nvptx/ia64-sync-1.c: New test.
* gcc.target/nvptx/ia64-sync-2.c: New test.
* gcc.target/nvptx/ia64-sync-3.c: New test.
* gcc.target/nvptx/ia64-sync-4.c: New test.
If char is unsigned, then comparisons of the char array elements against
negative integers in the test will fail as values in the array will always
be positive, and will remain so when promoted to signed int.
2020-08-12 Kwok Cheung Yeung <kcy@codesourcery.com>
PR testsuite/96519
gcc/testsuite/
* gcc.dg/ia64-sync-5.c (AC, init_qi, test_qi): Change element type to
signed char.
When compiling builtin-object-size-21.c for nvptx, cc1 times out while
emitting the initializer for global variable xm3_3.
With x86_64, we are able to emit the initializer with a few lines of assembly:
...
xm3_3:
.byte 0
.zero 9223372036854775803
.byte 1
.byte 2
.byte 3
...
but with nvptx, we don't have some something similar available, and thus
generate:
...
.visible .global .align 1 .u32 xm3_3[2305843009213693952] =
{ 0, 0, 0, ...
...
Introduce an effective target large_initializer, returning false for nvptx,
and require it for test-cases with large initializers.
Tested on nvptx with make check-gcc.
gcc/testsuite/ChangeLog:
PR testsuite/96566
* lib/target-supports.exp (check_effective_target_large_initializer):
New proc.
* gcc.dg/builtin-object-size-21.c: Require large_initializer.
* gcc.dg/strlenopt-55.c: Same.
When compiling test-case builtin-object-size-21.c, cc1 emits:
...
.visible .global .align 1 .u32 xm3_3[-2305843009213693951] =
...
for:
...
struct Ax_m3 { char a[PTRDIFF_MAX - 3], ax[]; };
struct Ax_m3 xm3_3 = { { 0 }, { 1, 2, 3 } };
...
Fix this by:
- changing the printing format for unsigned HOST_WIDE_INT init_frag.remaining
to HOST_WIDE_INT_PRINT_UNSIGNED
- changing the type of local variable elt_size in nvptx_assemble_decl_begin
to unsigned HOST_WIDE_INT.
such that we have:
...
.visible .global .align 1 .u32 xm3_3[2305843009213693952] =
...
where 2305843009213693952 == 0x2000000000000000, so the array is claiming
0x8000000000000000 bytes, which is one more than PTRDIFF_MAX. This is due
to using .u32 instead of .u8, so strictly speaking we should downgrade to
using .u8 in this case, but that corner-case problem doesn't look urgent
enough to fix in this commit.
Build on nvptx, tested with make check-gcc.
gcc/ChangeLog:
* config/nvptx/nvptx.c (nvptx_assemble_decl_begin): Make elt_size an
unsigned HOST_WIDE_INT. Print init_frag.remaining using
HOST_WIDE_INT_PRINT_UNSIGNED.
The stack-protector-1.c test fails when compiled for Cortex-M:
- for Cortex-M0/M1, str r0, [sp #-8]! is not supported
- for Cortex-M3/M4..., the assembler complains that "use of r13 is
deprecated"
This patch replaces the str instruction with
sub sp, sp, #8
str r0, [sp]
and removes the check for r13, which is unlikely to leak the canary
value.
2020-08-11 Christophe Lyon <christophe.lyon@linaro.org>
gcc/testsuite/
* gcc.target/arm/stack-protector-1.c: Adapt code to Cortex-M
restrictions.
This patch fixes an incorrect parameter passing for $gcc_opts, which
produces a DejaGnu error: (DejaGnu) proc "gcc_opts" does not exist.
2020-08-12 Christophe Lyon <christophe.lyon@linaro.org>
gcc/testsuite/
* gcc.target/arm/multilib.exp: Fix parameter passing for gcc_opts.
The recent fix for mul_widen_cost revealed an interesting
quirk of ira/reload register allocation on x86_64. As shown in
https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551648.html
for gcc.target/i386/pr71321.c we generate the following code that
performs unnecessary register shuffling.
movl $-51, %edx
movl %edx, %eax
mulb %dil
Various discussions in bugzilla seem to point to reload preferring
not to load constants directly into CLASS_LIKELY_SPILLED_P registers.
Whatever the cause, one solution (workaround), that doesn't involve
rewriting a register allocator, is to use peephole2 to spot this
wierdness and eliminate it. With this peephole2 the above three
instructions (from pr71321.c) are replaced with:
movl $-51, %eax
mulb %dil
2020-08-12 Roger Sayle <roger@nextmovesoftware.com>
Uroš Bizjak <ubizjak@gmail.com>
gcc/ChangeLog
* config/i386/i386.md (peephole2): Reduce unnecessary
register shuffling produced by register allocation.
gcc/ChangeLog:
* ipa-fnsummary.c (evaluate_conditions_for_known_args): Use vec<>
instead of std::vector<>.
(evaluate_properties_for_edge): Same.
(ipa_fn_summary_t::duplicate): Same.
(estimate_ipcp_clone_size_and_time): Same.
* vec.h (<T, A, vl_embed>::embedded_size): Change vec_embedded
type to contain a char[].
For the testcase a symbol with a TLS reloc and an unary minus is being
generated. The backend didn't handle this correctly.
In s390_cannot_force_const_mem an unary minus on a symbolic constant
is rejected now since gas would not allow this.
legitimize_tls_address now makes the NEG rtx the outermost operation
by pulling it out of the CONST rtx.
gcc/ChangeLog:
PR target/96308
* config/s390/s390.c (s390_cannot_force_const_mem): Reject an
unary minus for everything not being a numeric constant.
(legitimize_tls_address): Move a NEG out of the CONST rtx.
gcc/testsuite/ChangeLog:
PR target/96308
* g++.dg/pr96308.C: New test.
The testcase failed because our backend refuses to generate vector
compare instructions for signaling operators with -fno-trapping-math
-fno-finite-math-only.
gcc/ChangeLog:
PR target/96456
* config/s390/s390.h (TARGET_NONSIGNALING_VECTOR_COMPARE_OK): New
macro.
* config/s390/vector.md (vcond_comparison_operator): Use new macro
for the check.
gcc/testsuite/ChangeLog:
PR target/96456
* gcc.target/s390/pr96456.c: New test.
Respect DR 526 in implementation of std::[forward_]list remove/remove_if/unique.
[forward_]list::remove was already implementing it but the implementation has
been modified to generalize the following pattern. All nodes to remove are
collected in an intermediate [forward_]list which purpose is just to be
detroyed once out of scope.
libstdc++-v3/ChangeLog:
PR libstdc++/91620
* include/bits/forward_list.tcc (forward_list<>::remove): Collect nodes
to destroy in an intermediate forward_list.
(forward_list<>::remove_if, forward_list<>::unique): Likewise.
* include/bits/list.tcc (list<>::remove, list<>::unique): Likewise.
(list<>::remove_if): Likewise.
* include/debug/forward_list (forward_list<>::_M_erase_after): Remove.
(forward_list<>::erase_after): Adapt.
(forward_list<>::remove, forward_list<>::remove_if): Collect nodes to
destroy in an intermediate forward_list.
(forward_list<>::unique): Likewise.
* include/debug/list (list<>::remove, list<>::unique): Likewise.
(list<>::remove_if): Likewise.
* testsuite/23_containers/forward_list/operations/91620.cc: New test.
* testsuite/23_containers/list/operations/91620.cc: New test.
The testcases no longer are failing due to operator new, so
remove the xfails to reduce testsuite summary noise.
gcc/testsuite/ChangeLog:
2020-08-11 David Edelsohn <dje.gcc@gmail.com>
* g++.dg/opt/flifetime-dse2.C: Remove AIX xfail.
* g++.dg/opt/flifetime-dse4.C: Remove AIX xfail.
These two tests fail on AIX because <sys/thread.h> defines struct thread
in the global namespace (despite it not being a reserved name). That
means the using-declaration that adds it to the global namespace causes
a redeclaration error.
libstdc++-v3/ChangeLog:
* testsuite/30_threads/thread/cons/84535.cc: Use a custom
namespace.
* testsuite/30_threads/thread/cons/lwg2097.cc: Likewise.
Make the experimental Networking TS code work without std::mutex and
std::condition_variable.
libstdc++-v3/ChangeLog:
PR libstdc++/89760
* include/experimental/executor [!_GLIBCXX_HAS_GTHREADS]:
(execution_context::mutex_type): Define dummy mutex type.
(system_context): Use execution_context::mutex_type.
(system_context) [!_GLIBCXX_HAS_GTHREADS]: Define dummy
thread and condition variable types.
[!_GLIBCXX_HAS_GTHREADS] (system_context::_M_run()): Do not
define.
(system_context::_M_post) [!_GLIBCXX_HAS_GTHREADS]: Throw
an exception when threads aren't available.
(strand::running_in_this_thread()): Defer to _M_state.
(strand::_State::running_in_this_thread()): New function.
(use_future_t): Do not depend on _GLIBCXX_USE_C99_STDINT_TR1.
* include/experimental/io_context (io_context): Use the
execution_context::mutex_type alias. Replace stack of thread
IDs with counter.
* testsuite/experimental/net/execution_context/use_service.cc:
Enable test for non-pthread targets.
libstdc++-v3/ChangeLog:
* include/std/stop_token: Check _GLIBCXX_HAS_GTHREADS using
#ifdef instead of #if.
(stop_token::_S_yield()): Check _GLIBCXX_HAS_GTHREADS before
using __gthread_yield.
The only function in namespace std::this_thread that actually depends on
thread support being present is this_thread::get_id(). The other
functions (yield, sleep_for and sleep_until) can be defined for targets
without gthreads.
A small change is needed in std::this_thread::sleep_for which currently
uses the __gthread_time_t typedef. Since it just calls nanosleep
directly, it should use timespec directly instead of the typedef.
Even std::this_thread::get_id() could be made to work, the only
difficulty is that it returns a value of type std:🧵:id and
std::thread is only defined when gthreads support exists.
libstdc++-v3/ChangeLog:
* include/std/thread [!_GLIBCXX_HAS_GTHREADS] (this_thread::yield)
(this_thread::sleep_until): Define.
[!_GLIBCXX_HAS_GTHREADS] (this_thread::sleep_for): Define. Replace
use of __gthread_time_t typedef with timespec.
* src/c++11/thread.cc [!_GLIBCXX_HAS_GTHREADS] (__sleep_for):
Likewise.
* testsuite/30_threads/this_thread/2.cc: Moved to...
* testsuite/30_threads/this_thread/yield.cc: ...here.
* testsuite/30_threads/this_thread/3.cc: Moved to...
* testsuite/30_threads/this_thread/sleep_for-mt.cc: ...here.
* testsuite/30_threads/this_thread/4.cc: Moved to...
* testsuite/30_threads/this_thread/sleep_until-mt.cc: ...here.
* testsuite/30_threads/this_thread/58038.cc: Add
dg-require-sleep.
* testsuite/30_threads/this_thread/60421.cc: Likewise.
* testsuite/30_threads/this_thread/sleep_for.cc: New test.
* testsuite/30_threads/this_thread/sleep_until.cc: New test.
As the testcase shows, we would ICE if the type of the first argument of
various atomic builtins was pointer to (non-void) incomplete type, we would
assume that TYPE_SIZE_UNIT must be non-NULL. This patch diagnoses it
instead. And also changes the TREE_CODE != INTEGER_CST check to
!tree_fits_uhwi_p, as we use tree_to_uhwi after this and at least in theory
the int could be too large and not fit.
2020-08-11 Jakub Jelinek <jakub@redhat.com>
PR c/96545
* c-common.c (get_atomic_generic_size): Require that first argument's
type points to a complete type and use tree_fits_uhwi_p instead of
just INTEGER_CST TREE_CODE check for the TYPE_SIZE_UNIT.
* c-c++-common/pr96545.c: New test.
At GIMPLE e.g. for __builtin_memmove we optimize away (to just the return
value) noop copies where src == dest, but at the RTL we don't, and as the
testcase shows, in some cases such copies can appear only at the RTL level
e.g. from trying to copy an aggregate by value argument to the same location
as it already has. If the block move is expanded e.g. piecewise, we
actually manage to optimize it away, as the individual memory copies are
seen as noop moves, but if the target optabs are used, often the sequences
stay until final.
2020-08-11 Jakub Jelinek <jakub@redhat.com>
PR rtl-optimization/96539
* expr.c (emit_block_move_hints): Don't copy anything if x and y
are the same and neither is MEM_VOLATILE_P.
* gcc.target/i386/pr96539.c: New test.
My changes to get_narrower to support COMPOUND_EXPRs apparently
used a wrong type for the COMPOUND_EXPRs, while e.g. the rhs
type was unsigned short, the COMPOUND_EXPR got int type as that was the
original type of op. The type of COMPOUND_EXPR should be always the type
of the rhs.
2020-08-11 Jakub Jelinek <jakub@redhat.com>
PR c/96549
* tree.c (get_narrower): Use TREE_TYPE (ret) instead of
TREE_TYPE (win) for COMPOUND_EXPRs.
* gcc.c-torture/execute/pr96549.c: New test.
This patch avoids both PRED_LOOP_GUARD and PRED_LOOP_GUARD_WITH_RECURSION to be
attached to one edge. We have logic that prevents same predictor to apply to
one edge twice, but since we split LOOP_GUARD to two more specialized cases,
this no longer fires.
Double prediction happens in exchange benchmark and leads to unrealistically
low hitrates on some edges which in turn leads to bad IPA profile and misguides
ipa-cp.
Unforutnately it seems that the bad profile also leads to bit better
performance by disabling some of loop stuff, but that really ought to be done
in some meaningful way, not by an accident.
gcc/ChangeLog:
2020-08-11 Jan Hubicka <hubicka@ucw.cz>
* predict.c (not_loop_guard_equal_edge_p): New function.
(maybe_predict_edge): New function.
(predict_paths_for_bb): Use it.
(predict_paths_leading_to_edge): Use it.
gcc/testsuite/ChangeLog:
2020-08-11 Jan Hubicka <hubicka@ucw.cz>
* gcc.dg/ipa/ipa-clone-2.c: Lower threshold from 500 to 400.
AIX linker is not able to merge identical type descriptors in a single
symbol if there are coming from different object or shared object files.
This results into several pointers referencing the same type
descriptors.
Thus, eqtype is needed to ensure that these different symbols will be
considered as the same type descriptor.
Fixesgolang/go#39276
gcc/go/ChangeLog:
* go-c.h (struct go_create_gogo_args): Add need_eqtype field.
* go-lang.c (go_langhook_init): Set need_eqtype.
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/235697
This patch adds a new DejaGNU directive, dg-ice, as outlined in the
proposal here:
https://gcc.gnu.org/pipermail/gcc-patches/2020-July/550913.html
It means that it's expected that the compiler crashes with an internal
compiler error when compiling test with such a directive.
A minor optimization could be to use -pass-exit-codes and then check for
ICE_EXIT_CODE return code instead of using string match.
gcc/ChangeLog:
* doc/sourcebuild.texi: Document dg-ice.
gcc/testsuite/ChangeLog:
* lib/gcc-dg.exp (gcc-dg-test-1): Handle dg-ice.
(cleanup-after-saved-dg-test): Reset expect_ice.
* lib/prune.exp (prune_ices): New.
* lib/target-supports-dg.exp (dg-ice): New.
To make amends for the recent (temporary) testsuite failure
of my new gcc.target/i386/minmax-9.c when compiled with -m32,
this patch improves the -m32 code we generate for the examples
in that test case.
The trick is to expand smin(x,0) as "x < 0 ? x : 0" instead
of the current "x <= 0 ? x : 0", as the former can take
advantage of sign_bit_mask operations.
2020-08-10 Roger Sayle <roger@nextmovesoftware.com>
gcc/ChangeLog
* config/i386/i386-expand.c (ix86_expand_int_movcc): Expand
signed MIN_EXPR against zero as "x < 0 ? x : 0" instead of
"x <= 0 ? x : 0" to enable sign_bit_compare_p optimizations.
gcc/testsuite/ChangeLog
* gcc.target/i386/minmax-12.c: New test.
The support for the old std::unique_ptr implementation was failing,
because it tried to work on a typedef instead of the underlying type.
The test supposed to verify the support worked wasn't using a typedef,
so didn't notice the problem.
libstdc++-v3/ChangeLog:
* python/libstdcxx/v6/printers.py (UniquePointerPrinter.__init__):
Use gdb.Type.strip_typedefs().
* testsuite/libstdc++-prettyprinters/compat.cc: Use a typedef in
the emulated old type.
gcc/fortran/ChangeLog:
PR fortran/96556
* frontend-passes.c (doloop_contained_function_call):
Do not dereference a NULL pointer for value.function.esym.
gcc/testsuite/ChangeLog:
PR fortran/96556
* gfortran.dg/do_check_15.f90: New test.
The following valid testcase is rejected, because cxx_eval_binary_expression
is called on the SPACESHIP_EXPR with lval = true, as the address of the
spaceship needs to be passed to a method call.
After recursing on the operands and calling genericize_spaceship which turns
it into a TARGET_EXPR with initialization, we call cxx_eval_constant_expression
on it which succeeds, but then we fall through into code that will
VERIFY_CONSTANT (r) which FAILs because it is an address of a variable. Rather
than avoiding that for lval = true and SPACESHIP_EXPR, the patch just tail
calls cxx_eval_constant_expression - I believe that call should perform all
the needed verifications.
2020-08-10 Jakub Jelinek <jakub@redhat.com>
PR c++/96497
* constexpr.c (cxx_eval_binary_expression): For SPACESHIP_EXPR, tail
call cxx_eval_constant_expression after genericize_spaceship to avoid
undesirable further VERIFY_CONSTANT.
* g++.dg/cpp2a/spaceship-constexpr3.C: New test.
When resolving the address of a template-id, we need to drop functions
whose associated constraints are not satisfied, as per [over.over]. We
do so in resolve_address_of_overloaded_function, but not in
resolve_overloaded_unification or resolve_nondeduced_context, which
seems like an oversight.
gcc/cp/ChangeLog:
* pt.c (resolve_overloaded_unification): Drop functions with
unsatisfied constraints.
(resolve_nondeduced_context): Likewise.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-fn5.C: New test.
* g++.dg/concepts/fn8.C: Generalize dg-error directive to accept
"no matching function ..." diagnostic.
* g++.dg/cpp2a/concepts-fn1.C: Likewise.
* g++.dg/cpp2a/concepts-ts2.C: Likewise.
* g++.dg/cpp2a/concepts-ts3.C: Likewise.
The configure switch should only affect the optional Filesystem TS, not
the std::filesystem features of C++17.
libstdc++-v3/ChangeLog:
PR libstdc++/94681
* acinclude.m4 (GLIBCXX_CHECK_FILESYSTEM_DEPS): Do not depend on
$enable_libstdcxx_filesystem_ts.
* configure: Regenerate.
