Patrick Palka [Fri, 11 Feb 2022 14:01:51 +0000 (09:01 -0500)]
libstdc++: Implement P2325 changes to default-constructibility of views
NB: This backport of r12-1606 to the 11 branch deliberately omits parts
of P2325R3 so as to maximize backward compatibility with pre-P2325R3 code.
In particular, we don't remove the default ctors for back_insert_iterator,
front_insert_iterator, ostream_iterator, ref_view and basic_istream_view.
===
This implements the wording changes of P2325R3 "Views should not be
required to be default constructible". Changes are relatively
straightforward, besides perhaps those to __box (which now stands
for copyable-box instead of semiregular-box) and __non_propagating_cache.
For __box, this patch implements the recommended practice to also avoid
std::optional when the boxed type is nothrow_move/copy_constructible.
For __non_propagating_cache, now that it's used by split_view::_M_current,
we need to add assignment from a value of the underlying type to the
subset of the std::optional API implemented for the cache (needed by
split_view::begin()). Hence the new __non_propagating_cache::operator=
overload.
In passing, this fixes the undesirable list-init in the constructors of
the partial specialization of __box as reported in PR100475 comment #7.
PR libstdc++/103904
libstdc++-v3/ChangeLog:
* include/bits/iterator_concepts.h (weakly_incrementable): Remove
default_initializable requirement.
* include/bits/ranges_base.h (ranges::view): Likewise.
* include/bits/ranges_util.h (subrange): Constrain the default
ctor.
* include/bits/stl_iterator.h (common_iterator): Constrain the
default ctor.
(counted_iterator): Likewise.
* include/std/ranges (__detail::__box::operator=): Handle
self-assignment in the primary template.
(__detail::__box): In the partial specialization: adjust
constraints as per P2325. Add specialized operator= for the
case when the wrapped type is not copyable. Constrain the
default ctor. Avoid list-initialization.
(single_view): Constraint the default ctor.
(iota_view): Relax semiregular constraint to copyable.
Constrain the default ctor.
(iota_view::_Iterator): Constraint the default ctor.
(ref_view): Remove the default ctor. Remove NSDMIs.
(ref_view::_Iterator): Constrain the default ctor.
(__detail::__non_propagating_cache::operator=): Define overload
for assigning from a value of the underlying type.
(filter_view): Likewise.
(filter_view::_Iterator): Likewise.
(transform_view): Likewise.
(transform_view::_Iterator): Likewise.
(take_view): Likewise.
(take_view::_Iterator): Likewise.
(take_while_view): Likewise.
(take_while_view::_Iterator): Likewise.
(drop_while_view): Likewise.
(drop_while_view::_Iterator): Likewise.
(join_view): Likewise.
(split_view::_OuterIter::__current): Adjust after changing the
type of _M_current.
(split_view::_M_current): Wrap it in a __non_propagating_cache.
(split_view::split_view): Constrain the default ctor.
(common_view): Constrain the default ctor.
(reverse_view): Likewise.
(elements_view): Likewise.
* include/std/span (enable_view<span<_ElementType, _Extent>>):
Define this partial specialization to true unconditionally.
* include/std/version (__cpp_lib_ranges): Adjust value.
* testsuite/std/ranges/adaptors/detail/semiregular_box.cc:
Rename to ...
* testsuite/std/ranges/adaptors/detail/copyable_box.cc: ... this.
(test02): Adjust now that __box is copyable-box not
semiregular-box.
(test03): New test.
* testsuite/std/ranges/p2325.cc: New test.
* testsuite/std/ranges/single_view.cc (test06): New test.
* testsuite/std/ranges/view.cc: Adjust now that view doesn't
require default_initializable.
Thomas Rodgers [Thu, 10 Feb 2022 18:12:36 +0000 (10:12 -0800)]
libstdc++: Strengthen memory order for atomic<T>::wait/notify
This changes the memory order used in the spin wait code to match
that of libc++.
libstdc++-v3/ChangeLog:
* include/bits/atomic_wait.h (__waiter_base::_S_do_spin,
__waiter_base::_S_do_spin_v): Change memory order from relaxed
to acquire.
Thomas Rodgers [Wed, 9 Feb 2022 20:29:19 +0000 (12:29 -0800)]
libstdc++: Fix deadlock in atomic wait [PR104442]
This issue was observed as a deadlock in
29_atomics/atomic/wait_notify/100334.cc on vxworks. When a wait is
"laundered" (e.g. type T* does not suffice as a waitable address for the
platform's native waiting primitive), the address waited is that of the
_M_ver member of __waiter_pool_base, so several threads may wait on the
same address for unrelated atomic<T> objects. As noted in the PR, the
implementation correctly exits the wait for the thread whose data
changed, but not for any other threads waiting on the same address.
As noted in the PR the __waiter::_M_do_wait_v member was correctly exiting
but the other waiters were not reloading the value of _M_ver before
re-entering the wait.
Moving the spin call inside the loop accomplishes this, and is
consistent with the predicate accepting version of __waiter::_M_do_wait.
libstdc++-v3/ChangeLog:
PR libstdc++/104442
* include/bits/atomic_wait.h (__waiter::_M_do_wait_v): Move spin
loop inside do loop so that threads failing the wait, reload
_M_ver.
liuhongt [Wed, 9 Feb 2022 05:14:43 +0000 (13:14 +0800)]
ICE: QImode(not SImode) operand should be passed to gen_vec_initv16qiqi in ashlv16qi3.
ix86_expand_vector_init expects vals to be a parallel containing
values of individual fields which should be either element mode of the
vector mode, or a vector mode with the same element mode and smaller
number of elements.
But in the expander ashlv16qi3, the second operand is SImode which
can't be directly passed to gen_vec_initv16qiqi.
gcc/ChangeLog:
PR target/104451
* config/i386/sse.md (<insn><mode>3): lowpart_subreg
operands[2] from SImode to QImode.
gcc/testsuite/ChangeLog:
PR target/104451
* gcc.target/i386/pr104451.c: New test.
Patrick Palka [Tue, 8 Feb 2022 14:11:29 +0000 (09:11 -0500)]
c++: satisfaction value of type const bool [PR104410]
Here constant evaluation of the atomic constraint use_func_v<T>
sensibly yields an INTEGER_CST of type const bool, but the assert in
satisfaction_value expects unqualified bool. So let's just relax the
assert to accept cv-qualified bool.
PR c++/104410
gcc/cp/ChangeLog:
* constraint.cc (satisfaction_value): Relax assert to accept
cv-qualified bool.
Harald Anlauf [Tue, 1 Feb 2022 22:33:24 +0000 (23:33 +0100)]
Fortran: reject simplifying TRANSFER for MOLD with storage size 0
gcc/fortran/ChangeLog:
PR fortran/104311
* check.c (gfc_calculate_transfer_sizes): Checks for case when
storage size of SOURCE is greater than zero while the storage size
of MOLD is zero and MOLD is an array shall not depend on SIZE.
gcc/testsuite/ChangeLog:
PR fortran/104311
* gfortran.dg/transfer_simplify_15.f90: New test.
Uros Bizjak [Thu, 3 Feb 2022 23:21:11 +0000 (00:21 +0100)]
i386: Do not use %ecx DRAP for functions that use __builtin_eh_return [PR104362]
%ecx can't be used for both DRAP register and eh_return. Adjust find_drap_reg
to choose %edi for functions that uses __builtin_eh_return to avoid the assert
in ix86_expand_epilogue that enforces this rule.
2022-02-03 Uroš Bizjak <ubizjak@gmail.com>
gcc/ChangeLog:
PR target/104362
* config/i386/i386.c (find_drap_reg): For 32bit targets
return DI_REG if function uses __builtin_eh_return.
gcc/testsuite/ChangeLog:
PR target/104362
* gcc.target/i386/pr104362.c: New test.
Martin Liska [Wed, 2 Feb 2022 13:21:51 +0000 (14:21 +0100)]
lto: fix error handling for -Wl,-plugin-opt=debug
When one uses something like: -Wl,-plugin-opt=debug,
we end up with lto1 WPA invocation that has 'debug'
on command line. We interpret that as input filename.
The patch moves resolution checking later so that we end up with
a reasonable error message:
lto1: fatal error: open debug failed: No such file or directory
compilation terminated.
PR lto/104333
gcc/lto/ChangeLog:
* lto-common.c (read_cgraph_and_symbols): Move resolution
checking for number of files later and report a reasonable
error message.
* lto-object.c (lto_obj_file_open): Make error fatal.
Ilya Leoshkevich [Fri, 28 Jan 2022 12:34:24 +0000 (13:34 +0100)]
IBM Z: fix `section type conflict` with -mindirect-branch-table
s390_code_end () puts indirect branch tables into separate sections and
tries to switch back to wherever it was in the beginning by calling
switch_to_section (current_function_section ()).
First of all, this is unnecessary - the other backends don't do it.
Furthermore, at this time there is no current function, but if the
last processed function was cold, in_cold_section_p remains set. This
causes targetm.asm_out.function_section () to call
targetm.section_type_flags (), which in absence of current function
decl classifies the section as SECTION_WRITE. This causes a section
type conflict with the existing SECTION_CODE.
gcc/ChangeLog:
* config/s390/s390.c (s390_code_end): Do not switch back to
code section.
gcc/testsuite/ChangeLog:
* gcc.target/s390/nobp-section-type-conflict.c: New test.
Xi Ruoyao [Sun, 30 Jan 2022 17:15:20 +0000 (01:15 +0800)]
fold-const: do not fold NaN result from non-NaN operands [PR95115]
These operations should raise an invalid operation exception at runtime.
So they should not be folded during compilation unless -fno-trapping-math
is used.
gcc/
PR middle-end/95115
* fold-const.c (const_binop): Do not fold NaN result from
non-NaN operands.
Thomas Rodgers [Mon, 31 Jan 2022 21:39:44 +0000 (13:39 -0800)]
Strengthen memory order for atomic<T>::wait/notify
This matches the memory order in libc++.
libstdc++-v3/ChangeLog:
* include/bits/atomic_wait.h: Change memory order from
Acquire/Release with relaxed loads to SeqCst+Release for
accesses to the waiter's count.
Richard Biener [Tue, 7 Dec 2021 10:13:39 +0000 (11:13 +0100)]
tree-optimization/103596 - fix missed propagation into switches
may_propagate_copy unnecessarily restricts propagating non-abnormals
into places that currently contain an abnormal SSA name but are
not the PHI argument for an abnormal edge. This causes VN to
not elide a CFG path that it assumes is elided, resulting in
released SSA names in the IL.
The fix is to enhance the may_propagate_copy API to specify the
destination is _not_ a PHI argument. I chose to not update only
the relevant caller in VN and the may_propagate_copy_into_stmt API
at this point because this is a regression and needs backporting.
2021-12-07 Richard Biener <rguenther@suse.de>
PR tree-optimization/103596
* tree-ssa-sccvn.c (eliminate_dom_walker::eliminate_stmt):
Note we are not propagating into a PHI argument to may_propagate_copy.
* tree-ssa-propagate.h (may_propagate_copy): Add
argument specifying whether we propagate into a PHI arg.
* tree-ssa-propagate.c (may_propagate_copy): Likewise.
When not doing so we can replace an abnormal with
something else.
(may_propagate_into_stmt): Update may_propagate_copy calls.
(replace_exp_1): Move propagation checking code to
propagate_value and rename to ...
(replace_exp): ... this and elide previous wrapper.
(propagate_value): Perform checking with adjusted
may_propagate_copy call and dispatch to replace_exp.
Richard Biener [Tue, 30 Nov 2021 13:08:19 +0000 (14:08 +0100)]
tree-optimization/103489 - fix ICE when bool pattern recog fails
bool pattern recog currently does not handle cycles correctly
and when it fails we can ICE later vectorizing PHIs with
mismatched bool and non-bool vector types. The following avoids
blindly trusting bool pattern recog here and verifies things
more thoroughly in vectorizable_phi. A bool pattern recog fix
is for GCC 13.
2021-11-30 Richard Biener <rguenther@suse.de>
PR tree-optimization/103489
* tree-vect-loop.c (vectorizable_phi): Verify argument
vector type compatibility to mitigate bool pattern recog
bug.
Eric Botcazou [Fri, 28 Jan 2022 10:04:06 +0000 (11:04 +0100)]
Fix wrong operator for universal_integer operands in instance
This is a regression present on mainline and 11 branch: the transformation
applied during expansion by Narrow_Large_Operation would incorrectly perform
name resolution for the operator again.
gcc/ada/
PR ada/104258
* exp_ch4.adb (Narrow_Large_Operation): Also copy the entity, if
any, when rewriting the operator node.
gcc/testsuite/
* gnat.dg/generic_comp.adb: New test.
Jason Merrill [Thu, 6 Jan 2022 14:45:26 +0000 (09:45 -0500)]
c++: nested catch in ctor fn-try-block [PR61611]
Being in_function_try_handler isn't enough to satisfy the condition of
reaching the end of such a handler; in this case, we're reaching the end of
a handler within that handler, so we don't want the special semantics.
PR c++/61611
gcc/cp/ChangeLog:
* except.c (in_nested_catch): New.
(expand_end_catch_block): Check it.
Harald Anlauf [Thu, 20 Jan 2022 21:36:50 +0000 (22:36 +0100)]
Fortran: fix simplification of TRANSFER for zero-sized character array result
gcc/fortran/ChangeLog:
PR fortran/104127
* simplify.c (gfc_simplify_transfer): Ensure that the result
typespec is set up for TRANSFER with MOLD of type CHARACTER
including character length even if the result is a zero-sized
array.
gcc/testsuite/ChangeLog:
PR fortran/104127
* gfortran.dg/transfer_simplify_11.f90: Fix logic.
* gfortran.dg/transfer_simplify_13.f90: New test.
The function aarch64_evpc_ins would reuse the target even though
it might be the same register as the two inputs.
Instead of checking to see if we can reuse the target, just use the
original input directly.
Committed as approved after bootstrapped and tested on
aarch64-linux-gnu with no regressions.
Note the testcases are not backported as __builtin_shufflevector
does not exist in GCC 11.
PR target/101529
gcc/ChangeLog:
* config/aarch64/aarch64.c (aarch64_evpc_ins): Don't use target
as an input, use original one.
Harald Anlauf [Tue, 25 Jan 2022 20:56:39 +0000 (21:56 +0100)]
Fortran: MOLD argument to TRANSFER intrinsic having storage size zero
gcc/fortran/ChangeLog:
PR fortran/104227
* check.c (gfc_calculate_transfer_sizes): Fix checking of arrays
passed as MOLD argument to the TRANSFER intrinsic for having
storage size zero.
gcc/testsuite/ChangeLog:
PR fortran/104227
* gfortran.dg/transfer_check_6.f90: New test.
Jakub Jelinek [Wed, 26 Jan 2022 10:58:27 +0000 (11:58 +0100)]
testsuite: Fix up pr104188.c testcase for i686-linux [PR104188]
On i686-linux this new testcase FAILs with:
cc1: warning: SSE instruction set disabled, using 387 arithmetics
FAIL: gcc.target/i386/pr104188.c (test for excess errors)
Excess errors:
cc1: warning: SSE instruction set disabled, using 387 arithmetics
This is because it uses -mfpmath=sse, but -msse2 isn't on. Fixed
by adding -msse2 to dg-options and requiring sse2_runtime effective
target.
In GCC 7.x and earlier, while it had -mabi=ieeelongdouble option, that option
was undocumented and unsupported.
In GCC 8.1 that option got documented and -mabi=ieeelongdouble long double started
to be mangled as U10__float128.
In GCC 9 and backported to before 8.2 release, that mangling changed to
u9__ieee128 and a support for emitting compatibility mangling aliases have
been added.
Unfortunately, as mentioned in the PR, those don't really work well in many
cases, the free_lang_data pass throws away important trees, so e.g. with
-flto -ffat-lto-objects the compiler often ICEs on templates that involve
IEEE quad long double arguments etc. because the mangling was done too late
(at final time).
Furthermore, lto1's mangler is not the C++ mangler, so with -flto it would
often emit as "mangled identifiers" something that wasn't a valid assembler
identifier, e.g. operator+ etc.
While it is possible to do such mangling earlier, e.g. at the same time when
the C++ FE emits its mangling aliases and untested proof of concept is in
the PR, there seems to be agreement that we shouldn't bother with this
ABI compatibility with something that probably nobody really used.
GCC 8.2 already uses the new mangling, it was just a few months, but more
importantly, libstdc++ support for IEEE quad long double on
powerpc64le-linux was only added in GCC 11, and glibc support for that some
weeks after 8.2 got released.
We ICE because #3 and #2 have the same type, but their canonical types
differ: TYPE_CANONICAL (#3) == #2 but TYPE_CANONICAL (#2) == #1.
The member functions #1 and #2 have the same type. However, since their
noexcept-specifier is deferred, when parsing them, we create a variant for
both of them, because DEFERRED_PARSE cannot be compared. In other words,
build_cp_fntype_variant's
tree v = TYPE_MAIN_VARIANT (type);
for (; v; v = TYPE_NEXT_VARIANT (v))
if (cp_check_qualified_type (v, type, type_quals, rqual, raises, late))
return v;
will *not* find an existing variant when creating a method_type for #2, so we
have to create a new one.
But then we perform delayed parsing and call fixup_deferred_exception_variants
for #1 and #2. f_d_e_v will replace TYPE_RAISES_EXCEPTIONS with the newly
parsed noexcept-specifier. It also sets TYPE_CANONICAL (#2) to #1. Both
noexcepts turned out to be the same, so now we have two equivalent variants in
the list! I.e.,
+-----------------+ +-----------------+ +-----------------+
| main | | #2 | | #1 |
| S S::<T379>(S*) |----->| S S::<T37c>(S*) |----->| S S::<T37a>(S*) |----->NULL
| - | | noex(T::value) | | noex(T::value) |
+-----------------+ +-----------------+ +-----------------+
Then we get to #3. As for #1 and #2, grokdeclarator calls build_memfn_type,
which ends up calling build_cp_fntype_variant, which will use the loop
above to look for an existing variant. The first one that matches
cp_check_qualified_type will be used, so we use #2 rather than #1, and the
TYPE_CANONICAL mismatch follows. Hopefully that makes sense.
As for the fix, I didn't think I could rewrite the method_type #2 with #1
because the type may have escaped via decltype. So my approach is to
elide #2 from the list, so when looking for a matching variant, we always
find #1 (#2 remains live though, which admittedly sounds sort of dodgy).
PR c++/101715
gcc/cp/ChangeLog:
* tree.c (fixup_deferred_exception_variants): Remove duplicate
variants after parsing the exception specifications.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/noexcept72.C: New test.
* g++.dg/cpp0x/noexcept73.C: New test.
Jakub Jelinek [Fri, 21 Jan 2022 10:16:50 +0000 (11:16 +0100)]
optabs: Don't create pseudos in prepare_cmp_insn when not allowed [PR102478]
cond traps can be created during ce3 after reload (and e.g. PR103028
recently fixed some ce3 cond trap related bug, so I think often that
works fine and we shouldn't disable cond traps after RA altogether),
but it calls prepare_cmp_insn. This function can fail, so I don't
see why we couldn't make it work after RA (in most cases it already
just works). The first hunk is just an optimization which doesn't
make sense after RA, so I've guarded it with can_create_pseudo_p.
The second hunk is just a theoretical case, I don't have a testcase for it.
prepare_cmp_insn has some other spots that can create pseudos, like when
both operands have VOIDmode, or when it is BLKmode comparison, or
not OPTAB_DIRECT, but I think none of that applies to ce3, we punt on
BLKmode earlier, use OPTAB_DIRECT and shouldn't be comparing two
VOIDmode CONST_INTs.
2022-01-21 Jakub Jelinek <jakub@redhat.com>
PR rtl-optimization/102478
* optabs.c (prepare_cmp_insn): If !can_create_pseudo_p (), don't
force_reg constants and for -fnon-call-exceptions fail if copy_to_reg
would be needed.
Jakub Jelinek [Thu, 20 Jan 2022 10:58:20 +0000 (11:58 +0100)]
dwarf2out: Fix -gsplit-dwarf on riscv [PR103874]
riscv*-*-* are the only modern targets that !HAVE_AS_LEB128 (apparently
due to some aggressive linker optimizations).
As the following testcase shows, we mishandle in index_rnglists the
!HAVE_AS_LEB128 && !have_multiple_function_sections case.
output_rnglists does roughly:
FOR_EACH_VEC_SAFE_ELT (ranges_table, i, r)
{
...
if (block_num > 0)
{
...
if (HAVE_AS_LEB128)
{
if (!have_multiple_function_sections)
{
// code not using r->*_entry
continue;
}
// code that sometimes doesn't use r->*_entry,
// sometimes r->begin_entry
}
else if (dwarf_split_debug_info)
{
// code that uses both r->begin_entry and r->end_entry
}
else
{
// code not using r->*_entry
}
}
else if (block_num < 0)
{
if (!have_multiple_function_sections)
gcc_unreachable ();
...
}
}
and index_rnglists is what sets up those r->{begin,end}_entry members.
The code did an early if (!have_multiple_function_sections) continue;
which is fine for the HAVE_AS_LEB128 case, because r->*_entry is not
used in that case, but not for !HAVE_AS_LEB128 that uses it anyway.
2022-01-20 Jakub Jelinek <jakub@redhat.com>
PR debug/103874
* dwarf2out.c (index_rnglists): For !HAVE_AS_LEB128 and
block_num > 0, index entry even if !have_multiple_function_sections.
Jakub Jelinek [Wed, 19 Jan 2022 14:03:45 +0000 (15:03 +0100)]
match.pd, optabs: Avoid vectorization of {FLOOR,CEIL,ROUND}_{DIV,MOD}_EXPR [PR102860]
power10 has modv4si3 expander and so vectorizes the following testcase
where Fortran modulo is FLOOR_MOD_EXPR.
optabs_for_tree_code indicates that the optab for all the *_MOD_EXPR
variants is umod_optab or smod_optab, but that isn't true, that optab
actually expands just TRUNC_MOD_EXPR. For the other tree codes expmed.cc
has code how to adjust the TRUNC_MOD_EXPR into those by emitting some
extra comparisons and conditional updates. Similarly for *_DIV_EXPR,
except in that case it actually needs both division and modulo.
While it would be possible to handle it in expmed.cc for vectors as well,
we'd need to be sure all the vector operations we need for that are
available, and furthermore we wouldn't account for that in the costing.
So, IMHO it is better to stop pretending those non-truncating (and
non-exact) div/mod operations have an optab. For GCC 13, we should
IMHO pattern match these in tree-vect-patterns.cc and transform them
to truncating div/mod with follow-up adjustments and let the vectorizer
vectorize that. As written in the PR, for signed operands:
r = x %[fl] y;
is
r = x % y; if (r && (x ^ y) < 0) r += y;
and
d = x /[fl] y;
is
r = x % y; d = x / y; if (r && (x ^ y) < 0) --d;
and
r = x %[cl] y;
is
r = x % y; if (r && (x ^ y) >= 0) r -= y;
and
d = /[cl] y;
is
r = x % y; d = x / y; if (r && (x ^ y) >= 0) ++d;
(too lazy to figure out rounding div/mod now). I'll create a PR
for that.
The patch also extends a match.pd optimization that floor_mod on
unsigned operands is actually trunc_mod.
2022-01-19 Jakub Jelinek <jakub@redhat.com>
PR middle-end/102860
* match.pd (x %[fl] y -> x % y): New simplification for
unsigned integral types.
* optabs-tree.c (optab_for_tree_code): Return unknown_optab
for {CEIL,FLOOR,ROUND}_{DIV,MOD}_EXPR with VECTOR_TYPE.
Jakub Jelinek [Wed, 19 Jan 2022 08:17:54 +0000 (09:17 +0100)]
i386: Fix *aes<aeswideklvariant>u8
grep '{[^|}]*}"' *.md
found another spot, though dunno if we have sufficient effective targets
etc. to add an -masm=intel test for it (and my installed binutils doesn't
support it anyway).
Binutils trunk testsuite shows the argument isn't omitted even in the Intel
syntax:
grep aesencwide *.s
keylocker.s: aesencwide128kl 126(%edx)
keylocker.s: aesencwide256kl 126(%edx)
keylocker.s: aesencwide128kl [edx+126]
keylocker.s: aesencwide256kl [edx+126]
property-10.s: aesencwide128kl (%eax)
x86-64-keylocker.s: aesencwide128kl 126(%rdx)
x86-64-keylocker.s: aesencwide256kl 126(%rdx)
x86-64-keylocker.s: aesencwide128kl [rdx+126]
x86-64-keylocker.s: aesencwide256kl [rdx+126]
and doesn't use any WHATEVER PTR.
2022-01-19 Jakub Jelinek <jakub@redhat.com>
* config/i386/sse.md (*aes<aeswideklvariant>u*): Use %0 instead of
{%0}.
Jakub Jelinek [Tue, 18 Jan 2022 23:42:18 +0000 (00:42 +0100)]
c++: Fix handling of temporaries with consteval ctors and non-trivial dtors [PR104055]
The following testcase is miscompiled. We see the constructor is immediate,
in build_over_call we trigger:
if (obj_arg && is_dummy_object (obj_arg))
{
call = build_cplus_new (DECL_CONTEXT (fndecl), call, complain);
obj_arg = NULL_TREE;
}
which makes call a TARGET_EXPR with the dtor in TARGET_EXPR_CLEANUP,
but then call cxx_constant_value on it. In cxx_eval_outermost_constant_expr
it triggers the:
else if (TREE_CODE (t) != CONSTRUCTOR)
{
r = get_target_expr_sfinae (r, tf_warning_or_error | tf_no_cleanup);
TREE_CONSTANT (r) = true;
}
which wraps the CONSTRUCTOR r into a new TARGET_EXPR, but one without
dtors (I think we need e.g. the TREE_CONSTANT for the callers),
and finally build_over_call uses that.
The following patch fixes that by using get_target_expr instead
of get_target_expr_sfinae + TREE_CONSTANT (r) = true if t is
a TARGET_EXPR with non-NULL TARGET_EXPR_CLEANUP.
2022-01-19 Jakub Jelinek <jakub@redhat.com>
PR c++/104055
* constexpr.c (cxx_eval_outermost_constant_expr): If t is a
TARGET_EXPR with TARGET_EXPR_CLEANUP, use get_target_expr rather
than get_target_expr_sfinae with tf_no_cleanup, and don't set
TREE_CONSTANT.
Jakub Jelinek [Wed, 12 Jan 2022 08:47:46 +0000 (09:47 +0100)]
c++: Silence -Wuseless-cast warnings during move [PR103480]
This is maybe just a shot in the dark, but IMHO we shouldn't be diagnosing
-Wuseless-cast on casts the compiler adds on its own when calling its move
function. We don't seem to warn when user calls std::move either.
We call move on elinit (*NON_LVALUE_EXPR <(struct C[2] &&) &D.2497->b>)[0]
so it is already an xvalue_p and try to static_cast it to struct C &&.
But we don't warn e.g. on std::move (std::move (whatever)).
Fixed by not doing the static cast and just returning expr from move
if expr is already an xvalue.
2022-01-11 Jakub Jelinek <jakub@redhat.com>
Jason Merrill <jason@redhat.com>
PR c++/103480
* tree.c (move): If expr is xvalue_p, just return expr without
build_static_cast.
Jakub Jelinek [Tue, 11 Jan 2022 18:11:51 +0000 (19:11 +0100)]
c-family: Fix up -W*conversion on bitwise &/|/^ [PR101537]
The following testcases emit a bogus -Wconversion warning. This is because
conversion_warning function doesn't handle BIT_*_EXPR (only unsafe_conversion_p
that is called during the default: case, and that one doesn't handle
SAVE_EXPRs added because the unsigned char & or | operands promoted to int
have side-effects and =| or =& is used.
The patch handles BIT_IOR_EXPR/BIT_XOR_EXPR like the last 2 operands of
COND_EXPR by recursing on the two operands, if either of them doesn't fit
into the narrower type, complain. BIT_AND_EXPR too, but first it needs to
handle some special cases that unsafe_conversion_p does, namely when one
of the two operands is a constant.
This fixes completely the pr101537.c test and for C also pr103881.c
and doesn't regress anything in the testsuite, for C++ pr103881.c still
emits the bogus warnings.
This is because while the C FE emits in that case a SAVE_EXPR that
conversion_warning can handle already, C++ FE emits
TARGET_EXPR <D.whatever, ...>, something | D.whatever
etc. and conversion_warning handles COMPOUND_EXPR by "recursing" on the
rhs. To handle that case, we'd need for TARGET_EXPR on the lhs remember
in some hash map the mapping from D.whatever to the TARGET_EXPR and when
we see D.whatever, use corresponding TARGET_EXPR initializer instead.
2022-01-11 Jakub Jelinek <jakub@redhat.com>
PR c/101537
PR c/103881
gcc/c-family/
* c-warn.c (conversion_warning): Handle BIT_AND_EXPR, BIT_IOR_EXPR
and BIT_XOR_EXPR.
gcc/testsuite/
* c-c++-common/pr101537.c: New test.
* c-c++-common/pr103881.c: New test.
Jakub Jelinek [Mon, 10 Jan 2022 19:49:11 +0000 (20:49 +0100)]
c++: Ensure some more that immediate functions aren't gimplified [PR103912]
Immediate functions should never be emitted into assembly, the FE doesn't
genericize them and does various things to ensure they aren't gimplified.
But the following testcase ICEs anyway due to that, because the consteval
function returns a lambda, and operator() of the lambda has
decl_function_context of the consteval function. cgraphunit.c then
does:
/* Preserve a functions function context node. It will
later be needed to output debug info. */
if (tree fn = decl_function_context (decl))
{
cgraph_node *origin_node = cgraph_node::get_create (fn);
enqueue_node (origin_node);
}
which enqueues the immediate function and then tries to gimplify it,
which results in ICE because it hasn't been genericized.
When I try similar testcase with constexpr instead of consteval and
static constinit auto instead of auto in main, what happens is that
the functions are gimplified, later ipa.c discovers they aren't reachable
and sets body_removed to true for them (and clears other flags) and we end
up with a debug info which has the foo and bar functions without
DW_AT_low_pc and other code specific attributes, just stuff from its BLOCK
structure and in there the lambda with DW_AT_low_pc etc.
The following patch attempts to emulate that behavior early, so that cgraph
doesn't try to gimplify those and pretends they were already gimplified
and found unused and optimized away.
2022-01-10 Jakub Jelinek <jakub@redhat.com>
PR c++/103912
* semantics.c (expand_or_defer_fn): For immediate functions, set
node->body_removed to true and clear analyzed, definition and
force_output.
* decl2.c (c_parse_final_cleanups): Ignore immediate functions for
expand_or_defer_fn.
Jakub Jelinek [Thu, 6 Jan 2022 08:29:34 +0000 (09:29 +0100)]
ifcvt: Check for asm goto at the end of then_bb/else_bb in ifcvt [PR103908]
On the following testcase, RTL ifcvt sees then_bb
(note 7 6 8 3 [bb 3] NOTE_INSN_BASIC_BLOCK)
(insn 8 7 9 3 (set (mem/c:SI (symbol_ref:DI ("b") [flags 0x2] <var_decl 0x7fdccf5b0cf0 b>) [1 b+0 S4 A32])
(const_int 1 [0x1])) "pr103908.c":6:7 81 {*movsi_internal}
(nil))
(jump_insn 9 8 13 3 (parallel [
(asm_operands/v ("# insn 1") ("") 0 []
[]
[
(label_ref:DI 21)
] pr103908.c:7)
(clobber (reg:CC 17 flags))
]) "pr103908.c":7:5 -1
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil))
-> 21)
and similarly else_bb (just with a different asm_operands template).
It checks that those basic blocks have a single successor and
uses last_active_insn which intentionally skips over JUMP_INSNs, sees
both basic blocks contain the same set and merges them (or if the
sets are different, attempts some other noce optimization).
But we can't assume that the jump, even when it has only a single successor,
has no side-effects.
The following patch fixes it by punting if test_bb ends with a JUMP_INSN
that isn't onlyjump_p.
2022-01-06 Jakub Jelinek <jakub@redhat.com>
PR rtl-optimization/103908
* ifcvt.c (bb_valid_for_noce_process_p): Punt on bbs ending with
asm goto.
Jakub Jelinek [Sat, 1 Jan 2022 05:29:36 +0000 (06:29 +0100)]
objc: Fix handling of break stmt inside of switch inside of ObjC foreach [PR103639]
The r11-3302-g3696a50beeb73f changes broke the following ObjC testcase.
in_statement is either 0 (not in a looping statement), various IN_* flags
for various kinds of looping statements (or OpenMP structured blocks) or
those flags ored with IN_SWITCH_STMT when a switch appears inside of those
contexts. This is because break binds to switch in that last case, but
continue binds to the looping construct in that case.
The c_finish_bc_stmt function performs diagnostics on incorrect
break/continue uses and then checks if in_statement & IN_OBJC_FOREACH
and in that case jumps to the label provided by the caller, otherwise
emits a BREAK_STMT or CONTINUE_STMT. This is incorrect if we have
ObjC foreach with switch nested in it and break inside of that,
in_statement in that case is IN_OBJC_FOREACH | IN_SWITCH_STMT and
is_break is true. We want to handle it like other breaks inside of
switch, i.e. emit a BREAK_STMT.
The following patch fixes that.
2022-01-01 Jakub Jelinek <jakub@redhat.com>
PR objc/103639
* c-typeck.c (c_finish_bc_stmt): For break inside of switch inside of
ObjC foreach, emit normal BREAK_STMT rather than goto to label.
Jakub Jelinek [Thu, 30 Dec 2021 21:23:58 +0000 (22:23 +0100)]
libcpp: Fix up ##__VA_OPT__ handling [PR89971]
In the following testcase we incorrectly error about pasting / token
with padding token (which is a result of __VA_OPT__); instead we should
like e.g. for ##arg where arg is empty macro argument clear PASTE_LEFT
flag of the previous token if __VA_OPT__ doesn't add any real tokens
(which can happen either because the macro doesn't have any tokens
passed to ... (i.e. __VA_ARGS__ expands to empty) or when __VA_OPT__
doesn't have any tokens in between ()s).
2021-12-30 Jakub Jelinek <jakub@redhat.com>
PR preprocessor/89971
libcpp/
* macro.c (replace_args): For ##__VA_OPT__, if __VA_OPT__ expands
to no tokens at all, drop PASTE_LEFT flag from the previous token.
gcc/testsuite/
* c-c++-common/cpp/va-opt-9.c: New test.
Jakub Jelinek [Thu, 30 Dec 2021 13:25:19 +0000 (14:25 +0100)]
c-family: Use BULTINS_LOCATION for predefined macros changed upon optimize or target pragmas [PR103012]
The following testcases ICE when an optimize or target pragma
is followed by a long line (4096+ chars).
This is because on such long lines we can't use columns anymore,
but the cpp_define calls performed by c_cpp_builtins_optimize_pragma
or from the backend hooks for target pragma are done on temporary
buffers and expect to get columns from whatever line they appear on
(which happens to be the long line after optimize/target pragma),
and we run into:
#0 fancy_abort (file=0x3abec67 "../../libcpp/line-map.c", line=502, function=0x3abecfc "linemap_add") at ../../gcc/diagnostic.c:1986
#1 0x0000000002e7c335 in linemap_add (set=0x7ffff7fca000, reason=LC_RENAME, sysp=0, to_file=0x41287a0 "pr103012.i", to_line=3) at ../../libcpp/line-map.c:502
#2 0x0000000002e7cc24 in linemap_line_start (set=0x7ffff7fca000, to_line=3, max_column_hint=128) at ../../libcpp/line-map.c:827
#3 0x0000000002e7ce2b in linemap_position_for_column (set=0x7ffff7fca000, to_column=1) at ../../libcpp/line-map.c:898
#4 0x0000000002e771f9 in _cpp_lex_direct (pfile=0x40c3b60) at ../../libcpp/lex.c:3592
#5 0x0000000002e76c3e in _cpp_lex_token (pfile=0x40c3b60) at ../../libcpp/lex.c:3394
#6 0x0000000002e610ef in lex_macro_node (pfile=0x40c3b60, is_def_or_undef=true) at ../../libcpp/directives.c:601
#7 0x0000000002e61226 in do_define (pfile=0x40c3b60) at ../../libcpp/directives.c:639
#8 0x0000000002e610b2 in run_directive (pfile=0x40c3b60, dir_no=0, buf=0x7fffffffd430 "__OPTIMIZE__ 1\n", count=14) at ../../libcpp/directives.c:589
#9 0x0000000002e650c1 in cpp_define (pfile=0x40c3b60, str=0x2f784d1 "__OPTIMIZE__") at ../../libcpp/directives.c:2513
#10 0x0000000002e65100 in cpp_define_unused (pfile=0x40c3b60, str=0x2f784d1 "__OPTIMIZE__") at ../../libcpp/directives.c:2522
#11 0x0000000000f50685 in c_cpp_builtins_optimize_pragma (pfile=0x40c3b60, prev_tree=<optimization_node 0x7fffea042000>, cur_tree=<optimization_node 0x7fffea042020>)
at ../../gcc/c-family/c-cppbuiltin.c:600
assertion that LC_RENAME doesn't happen first.
I think the right fix is emit those predefined macros upon
optimize/target pragmas with BUILTINS_LOCATION, like we already do
for those macros at the start of the TU, they don't appear in columns
of the next line after it. Another possibility would be to force them
at the location of the pragma.
Jakub Jelinek [Thu, 30 Dec 2021 13:23:18 +0000 (14:23 +0100)]
shrink-wrapping: Fix up prologue block discovery [PR103860]
The following testcase is miscompiled, because a prologue which
contains subq $8, %rsp instruction is emitted at the start of
a basic block which contains conditional jump that depends on
flags register set in an earlier basic block, the prologue instruction
then clobbers those flags.
Normally this case is checked by can_get_prologue predicate, but this
is done only at the start of the loop. If we update pro later in the
loop (because some bb shouldn't be duplicated) and then don't push
anything further into vec and the vec is already empty (this can happen
when the new pro is already in bb_with bitmask and either has no successors
(that is the case in the testcase where that bb ends with a trap) or
all the successors are already in bb_with, then the loop doesn't iterate
further and can_get_prologue will not be checked.
The following simple patch makes sure we call can_get_prologue even after
the last former iteration when vec is already empty and only break from
the loop afterwards (and only if the updating of pro done because of
!can_get_prologue didn't push anything into vec again).
2021-12-30 Jakub Jelinek <jakub@redhat.com>
PR rtl-optimization/103860
* shrink-wrap.c (try_shrink_wrapping): Make sure can_get_prologue is
called on pro even if nothing further is pushed into vec.
Jakub Jelinek [Tue, 28 Dec 2021 16:41:24 +0000 (17:41 +0100)]
fold-const: Fix up fold_truth_andor_1 shift handling [PR103813]
Some time ago I've changed const_binop -> wide_int_binop, so that it punts
on shifts by negative count. fold_truth_andor_1 doesn't check the results
of const_binop (?SHIFT_EXPR, ) though and assumes they will be always
non-NULL, which is no longer the case.
2021-12-28 Jakub Jelinek <jakub@redhat.com>
PR middle-end/103813
* fold-const.c (fold_truth_andor_1): Punt of const_binop LSHIFT_EXPR
or RSHIFT_EXPR returns NULL. Formatting fix.
In the following testcase we have a -fcompare-debug failure, because
can_move_invariant_reg doesn't ignore DEBUG_INSNs in its decisions.
In the testcase we have due to uninitialized variable:
loop_header
debug_insn using pseudo84
pseudo84 = invariant
insn using pseudo84
end loop
and with -g decide not to move the pseudo84 = invariant before the
loop header; in this case not resetting the debug insns might be fine.
But, we could have also:
pseudo84 = whatever
loop_header
debug_insn using pseudo84
pseudo84 = invariant
insn using pseudo84
end loop
and in that case not resetting the debug insns would result in wrong-debug.
And, we don't really have generally a good substitution on what pseudo84
contains, it could inherit various values from different paths.
So, the following patch ignores DEBUG_INSNs in the decisions, and if there
are any that previously prevented the optimization, resets them before
return true.
2021-12-28 Jakub Jelinek <jakub@redhat.com>
PR rtl-optimization/103837
* loop-invariant.c (can_move_invariant_reg): Ignore DEBUG_INSNs in
the decisions whether to return false or continue and right before
returning true reset those debug insns that previously caused
returning false.
Jakub Jelinek [Tue, 28 Dec 2021 16:39:23 +0000 (17:39 +0100)]
optabs: Fix up checking for CALLs in newly added code by double-word divmod [PR103838]
These two spots are meant to punt if the newly added code contains
any CALL_INSNs, because in that case having a large sequence of insns
that also calls something is undesirable, better have one call that
is optimized in itself well.
The functions do last = get_last_insn (); before emitting any insns
(and expand_binop as the ultimate caller uses delete_insns_since if
the expansion fails), but the checks were incorrect for 2 reasons:
1) it checked not just what follows after that last insn, but also
the last insn itself; so, if the division or modulo is immediately
preceded by a CALL_INSN, then we punt; this also causes -fcompare-debug
failures if the CALL_INSN is with -g followed by one or more DEBUG_INSNs
2) if get_last_insn () is NULL (i.e. emitting into a new sequence), then
we didn't check anything
2021-12-28 Jakub Jelinek <jakub@redhat.com>
PR debug/103838
* optabs.c (expand_doubleword_mod, expand_doubleword_divmod): Only
check newly added insns for CALL_P, not the last insn of previous
code.
Jakub Jelinek [Tue, 14 Dec 2021 11:02:55 +0000 (12:02 +0100)]
c: Fix ICE on deferred pragma in unknown attribute arguments [PR103587]
We ICE on the following testcase, because c_parser_balanced_token_sequence
when encountering a deferred pragma will just use c_parser_consume_token
which the FE doesn't allow for CPP_PRAGMA tokens (and if that wasn't
the case, it could ICE on CPP_PRAGMA_EOL similarly).
We don't know in what exact context the pragma appears when we don't
know what those arguments semantically mean, so I think we should just
skip over them, like e.g. the C++ FE does. And, I think (/[/{ vs. )/]/}
from outside of the pragma shouldn't be paired with those inside of
the pragma and it doesn't seem to be necessary to check that inside of
the pragma line itself all the paren kinds are balanced.
2021-12-14 Jakub Jelinek <jakub@redhat.com>
PR c/103587
* c-parser.c (c_parser_balanced_token_sequence): For CPP_PRAGMA,
consume the pragma and silently skip to the pragma eol.
Harald Anlauf [Tue, 11 Jan 2022 21:06:10 +0000 (22:06 +0100)]
Fortran: fix ICE and wrong code with TRANSFER and CHARACTER(kind=4)
gcc/fortran/ChangeLog:
PR fortran/83079
* target-memory.c (gfc_interpret_character): Result length is
in bytes and thus depends on the character kind.
* trans-intrinsic.c (gfc_conv_intrinsic_transfer): Compute correct
string length for the result of the TRANSFER intrinsic and for
temporaries for the different character kinds.
gcc/testsuite/ChangeLog:
PR fortran/83079
* gfortran.dg/transfer_char_kind4.f90: New test.
Marek Polacek [Mon, 17 Jan 2022 21:26:01 +0000 (16:26 -0500)]
c-family: Have -Wformat-diag accept "decl-specifier" [PR103758]
I'm tired of seeing
cp/parser.c:15923:55: warning: misspelled term 'decl' in format; use 'declaration' instead [-Wformat-diag]
cp/parser.c:15925:57: warning: misspelled term 'decl' in format; use 'declaration' instead [-Wformat-diag]
every time I compile cp/parser.c, which happens...a lot. I'd like my
compilation to be free of warnings, otherwise I'm going to miss some
important ones.
"decl-specifiers" is a C++ grammar term; it is not actual code, so
should not be wrapped with %< %>. I hope we can accept it as an exception
in check_tokens.
It was surrounded by %< %> in cp_parser_decl_specifier_seq, so fix that.
Marek Polacek [Fri, 17 Dec 2021 19:34:12 +0000 (14:34 -0500)]
c-family: Have -Wformat-diag accept "decl-specifier" [PR103758]
I'm tired of seeing
cp/parser.c:15923:55: warning: misspelled term 'decl' in format; use 'declaration' instead [-Wformat-diag]
cp/parser.c:15925:57: warning: misspelled term 'decl' in format; use 'declaration' instead [-Wformat-diag]
every time I compile cp/parser.c, which happens...a lot. I'd like my
compilation to be free of warnings, otherwise I'm going to miss some
important ones.
"decl-specifiers" is a C++ grammar term; it is not actual code, so
should not be wrapped with %< %>. I hope we can accept it as an exception
in check_tokens.
It was surrounded by %< %> in cp_parser_decl_specifier_seq, so fix that.
Mikael Morin [Mon, 17 Jan 2022 10:45:46 +0000 (11:45 +0100)]
Fortran: Ignore KIND argument of a few more intrinsics. [PR103789]
After PR97896 for which some code was added to ignore the KIND argument
of the INDEX intrinsics, and PR87711 for which that was extended to LEN_TRIM
as well, this propagates it further to MASKL, MASKR, SCAN and VERIFY.
PR fortran/103789
gcc/fortran/ChangeLog:
* trans-array.c (arg_evaluated_for_scalarization): Add MASKL, MASKR,
SCAN and VERIFY to the list of intrinsics whose KIND argument is to be
ignored.
Mikael Morin [Sun, 16 Jan 2022 17:33:36 +0000 (18:33 +0100)]
testsuite: Enrich tests with variants failing on the branch.
Backporting the fix for pr103789 on the 11 branch revealed a lack of test
coverage for the tests provided with that fix. Indeed, the tests use the KIND
argument of the respective intrinsics only with keyword arguments.
This adds variants with non-keyword arguments.
The tests enriched this way fail on the branch if the fix is cherry-picked
straightforwardly. The fix will have to be tweaked slightly there.
* gfortran.dg/maskl_1.f90: Enrich test with usages of MASKL with
a non-keyword KIND argument.
* gfortran.dg/maskr_1.f90: Same for MASKR.
* gfortran.dg/scan_3.f90: Same for SCAN.
* gfortran.dg/verify_3.f90: Same for VERIFY.
Mikael Morin [Fri, 7 Jan 2022 21:34:59 +0000 (22:34 +0100)]
Fortran: Ignore KIND argument of a few more intrinsics. [PR103789]
After PR97896 for which some code was added to ignore the KIND argument
of the INDEX intrinsics, and PR87711 for which that was extended to LEN_TRIM
as well, this propagates it further to MASKL, MASKR, SCAN and VERIFY.
PR fortran/103789
gcc/fortran/ChangeLog:
* trans-array.c (arg_evaluated_for_scalarization): Add MASKL, MASKR,
SCAN and VERIFY to the list of intrinsics whose KIND argument is to be
ignored.
gcc/testsuite/ChangeLog:
* gfortran.dg/maskl_1.f90: New test.
* gfortran.dg/maskr_1.f90: New test.
* gfortran.dg/scan_3.f90: New test.
* gfortran.dg/verify_3.f90: New test.
Mikael Morin [Sun, 16 Jan 2022 15:26:15 +0000 (16:26 +0100)]
Fortran: Fix KIND argument index for LEN_TRIM.
The mainline code to check whether an argument has to be included in
scalarization uses only the name of a dummy argument object to recognize a
specific argument of an intrinsic procedure. On the 11 branch, the dummy
argument object is not available and the code uses a mix of check for
argument name (for keyword arguments) and argument index (for non-keyword ones).
This makes backports non-straightforward in this area, as the argument indexes
depend on the intrinsics.
This change fixes a bogus backport for LEN_TRIM, whose KIND argument index
should be different from that of INDEX.
PR fortran/87711
PR fortran/97896
gcc/fortran/ChangeLog:
* trans-array.c (arg_evaluated_for_scalarization): Handle keyword and
non-keyword arguments separatedly. Adapt the expected argument index
for KIND to each intrinsic in the non-keyword case.
gcc/testsuite/ChangeLog:
* gfortran.dg/index_5.f90: Enrich test with usages of INDEX with
a non-keyword KIND argument.
* gfortran.dg/len_trim.f90: Same for LEN_TRIM.
Harald Anlauf [Wed, 12 Jan 2022 20:24:49 +0000 (21:24 +0100)]
Fortran: fix error recovery on bad structure constructor in DATA statement
gcc/fortran/ChangeLog:
PR fortran/67804
* primary.c (gfc_match_structure_constructor): Recover from errors
that occurred while checking for a valid structure constructor in
a DATA statement.
gcc/testsuite/ChangeLog:
PR fortran/67804
* gfortran.dg/pr93604.f90: Adjust to changed diagnostics.
* gfortran.dg/pr67804.f90: New test.
PR fortran/101762
* expr.c (gfc_check_pointer_assign): For pointer initialization
targets, check that subscripts and substring indices in
specifications are constant expressions.
gcc/testsuite/ChangeLog:
PR fortran/101762
* gfortran.dg/pr101762.f90: New test.
Eric Botcazou [Fri, 14 Jan 2022 18:49:21 +0000 (19:49 +0100)]
Fix reverse scalar storage order issues in IPA-SRA
The IPA-SRA pass introduced in GCC 10 does not always play nice with the
reverse scalar storage order that can be used in structures/records/unions.
Reading the code, the pass apparently correctly detects it but fails to
propagate the information to the rewriting phase in some cases and, in
particular, does not stream it for LTO.
gcc/
* ipa-param-manipulation.c (ipa_dump_adjusted_parameters): Dump
reverse flag as "reverse" for the sake of consistency.
* ipa-sra.c: Fix copyright year.
(ipa_sra_function_summaries::duplicate): Copy the reverse flag.
(dump_isra_access): Tweak dump line.
(isra_write_node_summary): Write the reverse flag.
(isra_read_node_info): Read it.
(pull_accesses_from_callee): Test its consistency and copy it.
gcc/testsuite/
* gnat.dg/lto25.adb: New test.
* gnat.dg/opt96.adb: Likewise.
* gnat.dg/opt96_pkg.ads, gnat.dg/opt96_pkg.adb: New helper.
Patrick Palka [Tue, 11 Jan 2022 18:00:48 +0000 (13:00 -0500)]
c++: dependent bases and 'this' availability [PR103831]
Here during satisfaction of B's constraints we're failing to reject the
object-less call to the non-static member function A::size ultimately
because satisfaction is performed in the (access) context of the class
template B, which has a dependent base, and so the any_dependent_bases_p
check within build_new_method_call causes us to not reject the call.
(Subsequent constexpr evaluation of the call succeeds since the function
is effectively static.)
This patch fixes this by refining the any_dependent_bases_p check within
build_new_method_call: if we're in a context where 'this' is unavailable,
then we cannot resolve the implicit object regardless of the presence of
a dependent base. So let's also check current_class_ptr alongside a_d_b_p.
PR c++/103831
gcc/cp/ChangeLog:
* call.c (build_new_method_call): Consider dependent bases only
if 'this' is available.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-class3.C: New test.
* g++.dg/template/non-dependent18.C: New test.
projects / people / ms / gcc.git / log
