arm: Fix polymorphic variants failing with undefined reference to `__ARM_undef` error.
This patch fixes the issue mentioned in PR101016, which is mve polymorphic variants
failing at linking with undefined reference to "__ARM_undef" error.
arm: Fix the mve multilib for the broken cmse support (pr99939).
The current CMSE support in the multilib build for
"-march=armv8.1-m.main+mve -mfloat-abi=hard -mfpu=auto" is broken
as specified in PR99939 and this patch fixes the issue.
PR target/99939
* gcc.target/arm/cmse/cmse-18.c: Add separate scan-assembler
directives check for target is v8.1-m.main+mve or not before
comparing the assembly output.
* gcc.target/arm/cmse/cmse-20.c: New test.
PR target/99939
* config/arm/cmse_nonsecure_call.S: Add __ARM_FEATURE_MVE
macro.
* config/arm/t-arm: To link cmse.o and cmse_nonsecure_call.o
on passing -mcmse option.
Jonathan Wakely [Fri, 18 Jun 2021 10:08:19 +0000 (11:08 +0100)]
libstdc++: Suppress -Wstringop-overread warning in test
When compiled with -m32 -O2 -D_GLIBCXX_USE_CXX11_ABI=0 we get a warning
for 21_strings/basic_string/cons/char/1.cc:
bits/char_traits.h:409:56: warning: ‘void* __builtin_memcpy(void*, const void*, unsigned int)’ reading 1073741821 bytes from a region of size 19 [-Wstringop-overread]
The warning is legitimate, even if that line cannot be reached because
we throw std::length_error before getting there. Since the invalid
length is deliberate (and mentioned in a comment) just suppress the
warning, so that the test can verify we get the exception.
Also remove an unused typedef that produces another warning.
libstdc++-v3/ChangeLog:
* testsuite/21_strings/basic_string/cons/char/1.cc: Use
diagnostic pragma to suppress -Wstringop-overread error.
Jonathan Wakely [Thu, 17 Jun 2021 13:11:22 +0000 (14:11 +0100)]
libstdc++: Simplify constexpr checks in std::char_traits [PR 91488]
This removes the 'static' keyword from the helper functions added by
r8-1294 to detect whether the char_traits member functions can be
evaluated at compile time. This prevents the "inlining failed" error
reported in the PR.
The new testcase from the PR is added to the libitm testsuite, because
that's where we can be sure it's OK to use the -fgnu-tm option.
As a drive-by fix, the feature test macros for C++20 P0980R1 support are
made to depend on whether __cpp_lib_is_constant_evaluated is defined.
Signed-off-by: Jonathan Wakely <jwakely@redhat.com>
PR libstdc++/91488
libstdc++-v3/ChangeLog:
* include/bits/basic_string.h (__cpp_lib_constexpr_string): Only
define C++20 value when std::is_constant_evaluated is available.
* include/bits/char_traits.h (__cpp_lib_constexpr_char_traits):
Likewise.
(__constant_string_p, __constant_array_p): Give external
linkage.
* include/std/version (__cpp_lib_constexpr_char_traits)
(__cpp_lib_constexpr_string): Only define C++20 values when
is_constant_evaluated is available.
libitm/ChangeLog:
* testsuite/libitm.c++/libstdc++-pr91488.C: New test.
Jakub Jelinek [Fri, 18 Jun 2021 09:20:40 +0000 (11:20 +0200)]
stor-layout: Don't create DECL_BIT_FIELD_REPRESENTATIVE for QUAL_UNION_TYPE [PR101062]
> The following patch does create them, but treats all such bitfields as if
> they were in a structure where the particular bitfield is the only field.
While the patch passed bootstrap/regtest on the trunk, when trying to
backport it to 11 branch the bootstrap failed with
atree.ads:3844:34: size for "Node_Record" too small
errors. Turns out the error is not about size being too small, but actually
about size being non-constant, and comes from:
/* In a FIELD_DECL of a RECORD_TYPE, this is a pointer to the storage
representative FIELD_DECL. */
#define DECL_BIT_FIELD_REPRESENTATIVE(NODE) \
(FIELD_DECL_CHECK (NODE)->field_decl.qualifier)
/* For a FIELD_DECL in a QUAL_UNION_TYPE, records the expression, which
if nonzero, indicates that the field occupies the type. */
#define DECL_QUALIFIER(NODE) (FIELD_DECL_CHECK (NODE)->field_decl.qualifier)
so by setting up DECL_BIT_FIELD_REPRESENTATIVE in QUAL_UNION_TYPE we
actually set or modify DECL_QUALIFIER and then construct size as COND_EXPRs
with those bit field representatives (e.g. with array type) as conditions
which doesn't fold into constant.
The following patch fixes it by not creating DECL_BIT_FIELD_REPRESENTATIVEs
for QUAL_UNION_TYPE as there is nowhere to store them,
Shall we change tree.h to document that DECL_BIT_FIELD_REPRESENTATIVE
is valid also on UNION_TYPE?
I see:
tree-ssa-alias.c- if (TREE_CODE (type1) == RECORD_TYPE
tree-ssa-alias.c: && DECL_BIT_FIELD_REPRESENTATIVE (field1))
tree-ssa-alias.c: field1 = DECL_BIT_FIELD_REPRESENTATIVE (field1);
tree-ssa-alias.c- if (TREE_CODE (type2) == RECORD_TYPE
tree-ssa-alias.c: && DECL_BIT_FIELD_REPRESENTATIVE (field2))
tree-ssa-alias.c: field2 = DECL_BIT_FIELD_REPRESENTATIVE (field2);
Shall we change that to || == UNION_TYPE or do we assume all fields
are overlapping in a UNION_TYPE already?
At other spots (asan, ubsan, expr.c) it is unclear what will happen
if they see a QUAL_UNION_TYPE with a DECL_QUALIFIER (or does the Ada FE
lower that somehow)?
Jakub Jelinek [Wed, 16 Jun 2021 10:17:55 +0000 (12:17 +0200)]
stor-layout: Create DECL_BIT_FIELD_REPRESENTATIVE even for bitfields in unions [PR101062]
The following testcase is miscompiled on x86_64-linux, the bitfield store
is implemented as a RMW 64-bit operation at d+24 when the d variable has
size of only 28 bytes and scheduling moves in between the R and W part
a store to a different variable that happens to be right after the d
variable.
The reason for this is that we weren't creating
DECL_BIT_FIELD_REPRESENTATIVEs for bitfields in unions.
The following patch does create them, but treats all such bitfields as if
they were in a structure where the particular bitfield is the only field.
2021-06-16 Jakub Jelinek <jakub@redhat.com>
PR middle-end/101062
* stor-layout.c (finish_bitfield_representative): For fields in unions
assume nextf is always NULL.
(finish_bitfield_layout): Compute bit field representatives also in
unions, but handle it as if each bitfield was the only field in the
aggregate.
Patrick Palka [Thu, 17 Jun 2021 13:46:07 +0000 (09:46 -0400)]
libstdc++: Non-triv-copyable extra args aren't simple [PR100940]
This force-enables perfect forwarding call wrapper semantics whenever
the extra arguments of a partially applied range adaptor aren't all
trivially copyable, so as to avoid incurring unnecessary copies of
potentially expensive-to-copy objects (such as std::function objects)
when invoking the adaptor.
PR libstdc++/100940
libstdc++-v3/ChangeLog:
* include/std/ranges (__adaptor::_Partial): For the "simple"
forwarding partial specializations, also require that
the extra arguments are trivially copyable.
* testsuite/std/ranges/adaptors/100577.cc (test04): New test.
Patrick Palka [Thu, 17 Jun 2021 13:46:04 +0000 (09:46 -0400)]
libstdc++: Refine range adaptors' "simple extra args" mechanism [PR100940]
The _S_has_simple_extra_args mechanism is used to simplify forwarding
of range adaptor's extra arguments when perfect forwarding call wrapper
semantics isn't required for correctness, on a per-adaptor basis.
Both views::take and views::drop are flagged as such, but it turns out
perfect forwarding semantics are needed for these adaptors in some
contrived cases, e.g. when their extra argument is a move-only class
that's implicitly convertible to an integral type.
To fix this, we could just clear the flag for views::take/drop as with
views::split, but that'd come at the cost of acceptable diagnostics
for ill-formed uses of these adaptors (see PR100577).
This patch instead allows adaptors to parameterize their
_S_has_simple_extra_args flag according the types of the captured extra
arguments, so that we could conditionally disable perfect forwarding
semantics only when the types of the extra arguments permit it. We
then use this finer-grained mechanism to safely disable perfect
forwarding semantics for views::take/drop when the extra argument is
integer-like, rather than incorrectly always disabling it. Similarly,
for views::split, rather than always enabling perfect forwarding
semantics we now safely disable it when the extra argument is a scalar
or a view, and recover good diagnostics for these common cases.
PR libstdc++/100940
libstdc++-v3/ChangeLog:
* include/std/ranges (__adaptor::_RangeAdaptor): Document the
template form of _S_has_simple_extra_args.
(__adaptor::__adaptor_has_simple_extra_args): Add _Args template
parameter pack. Try to treat _S_has_simple_extra_args as a
variable template parameterized by _Args.
(__adaptor::_Partial): Pass _Arg/_Args to the constraint
__adaptor_has_simple_extra_args.
(views::_Take::_S_has_simple_extra_args): Templatize according
to the type of the extra argument.
(views::_Drop::_S_has_simple_extra_args): Likewise.
(views::_Split::_S_has_simple_extra_args): Define.
* testsuite/std/ranges/adaptors/100577.cc (test01, test02):
Adjust after changes to _S_has_simple_extra_args mechanism.
(test03): Define.
Peter Bergner [Mon, 14 Jun 2021 21:55:18 +0000 (16:55 -0500)]
rs6000: MMA builtin usage ICEs when used in a #pragma omp parallel and using -fopenmp [PR100777]
Using an MMA builtin within an openmp parallel code block, leads to an SSA
verification ICE on the temporaries we create while expanding the MMA builtins
at gimple time. The solution is to use create_tmp_reg_or_ssa_name(), which
knows when to create either an SSA or register temporary.
2021-06-14 Peter Bergner <bergner@linux.ibm.com>
gcc/
PR target/100777
* config/rs6000/rs6000-call.c (rs6000_gimple_fold_mma_builtin): Use
create_tmp_reg_or_ssa_name().
gcc/testsuite/
PR target/100777
* gcc.target/powerpc/pr100777.c: New test.
Peter Bergner [Thu, 10 Jun 2021 18:54:12 +0000 (13:54 -0500)]
rs6000: Add new __builtin_vsx_build_pair and __builtin_mma_build_acc built-ins
The __builtin_vsx_assemble_pair and __builtin_mma_assemble_acc built-ins
currently assign their first source operand to the first VSX register
in a pair/quad, their second operand to the second register in a pair/quad, etc.
This is not endian friendly and forces the user to generate different calls
depending on endianness. In agreement with the POWER LLVM team, we've
decided to lightly deprecate the assemble built-ins and replace them with
"build" built-ins that automatically handle endianness so the same built-in
call and be used for both little-endian and big-endian compiles. We are not
removing the assemble built-ins, since there is code in the wild that use
them, but we are removing their documentation to encourage the use of the
new "build" variants.
gcc/
* config/rs6000/rs6000-builtin.def (build_pair): New built-in.
(build_acc): Likewise.
* config/rs6000/rs6000-call.c (mma_expand_builtin): Swap assemble
source operands in little-endian mode.
(rs6000_gimple_fold_mma_builtin): Handle VSX_BUILTIN_BUILD_PAIR.
(mma_init_builtins): Likewise.
* config/rs6000/rs6000.c (rs6000_split_multireg_move): Handle endianness
ordering for the MMA assemble and build source operands.
* doc/extend.texi (__builtin_vsx_build_acc, __builtin_mma_build_pair):
Document.
(__builtin_mma_assemble_acc, __builtin_mma_assemble_pair): Remove
documentation.
Peter Bergner [Mon, 31 May 2021 03:45:55 +0000 (22:45 -0500)]
rs6000: MMA test case ICEs using -O3 [PR99842]
The mma_assemble_input_operand predicate does not accept reg+reg indexed
addresses which can lead to ICEs. The lxv and lxvp instructions have
indexed forms (lxvx and lxvpx), so the simple solution is to just allow
indexed addresses in the predicate.
2021-05-30 Peter Bergner <bergner@linux.ibm.com>
gcc/
PR target/99842
* config/rs6000/predicates.md(mma_assemble_input_operand): Allow
indexed form addresses.
Martin Sebor [Thu, 17 Jun 2021 18:18:53 +0000 (12:18 -0600)]
Backported from trunk:
Teach compute_objsize about placement new [PR100876].
Resolves:
PR c++/100876 - -Wmismatched-new-delete should understand placement new when it's not inlined
gcc/ChangeLog:
PR c++/100876
* builtins.c (gimple_call_return_array): Check for attribute fn spec.
Handle calls to placement new.
(ndecl_dealloc_argno): Avoid placement delete.
gcc/testsuite/ChangeLog:
PR c++/100876
* g++.dg/warn/Wmismatched-new-delete-4.C: New test.
* g++.dg/warn/Wmismatched-new-delete-5.C: New test.
* g++.dg/warn/Wstringop-overflow-7.C: New test.
* g++.dg/warn/Wfree-nonheap-object-6.C: New test.
* g++.dg/analyzer/placement-new.C: Prune out expected warning.
Martin Sebor [Thu, 17 Jun 2021 18:08:15 +0000 (12:08 -0600)]
Backported from trunk:
PR middle-end/100732 - ICE on sprintf %s with integer argument
gcc/ChangeLog:
PR middle-end/100732
* gimple-fold.c (gimple_fold_builtin_sprintf): Avoid folding calls
with either source or destination argument of invalid type.
* tree-ssa-uninit.c (maybe_warn_pass_by_reference): Avoid checking
calls with arguments of invalid type.
gcc/testsuite/ChangeLog:
PR middle-end/100732
* gcc.dg/tree-ssa/builtin-snprintf-11.c: New test.
* gcc.dg/tree-ssa/builtin-snprintf-12.c: New test.
* gcc.dg/tree-ssa/builtin-sprintf-28.c: New test.
* gcc.dg/tree-ssa/builtin-sprintf-29.c: New test.
* gcc.dg/uninit-pr100732.c: New test.
Aaron Sawdey [Wed, 3 Mar 2021 00:06:37 +0000 (18:06 -0600)]
Backported from trunk:
Fusion patterns for add-logical/logical-add
This patch modifies the function in genfusion.pl for generating
the logical-logical patterns so that it can also generate the
add-logical and logical-add patterns which are very similar.
Also backported from trunk and combined with the add-logical patch
because that revealed problems on gcc-11.
Add needed earlyclobber to fusion patterns
The add-logical and add-add fusion patterns all have constraint
alternatives "=0,1,&r,r" for the output (3). The inputs 0 and 1
are used in the first fusion instruction and then either may be
reused as a temp for the output of the first insn which is
input to the second. However, if input 2 is the same as 0 or 1,
it gets clobbered unexpectedly. So the first 2 alts need to be
"=&0,&1,&r,r" instead to indicate that in alts 0 and 1, the
register used for 3 is earlyclobber, hence can't be the same as
input 2.
This was actually encountered in the backport of the add-logical
fusion patch to gcc-11. Some code in go hit this case:
<runtime.fillAligned+520>: andc r30,r30,r9
r30 now (~(x|((x&c)+c)))&(~c) --> this is new x
<runtime.fillAligned+524>: b <runtime.fillAligned+288>
<runtime.fillAligned+288>: addi r31,r31,-1
r31 now m-1
<runtime.fillAligned+292>: srd r31,r30,r31
r31 now x>>(m-1)
<runtime.fillAligned+296>: subf r30,r31,r30
r30 now x-(x>>(m-1))
<runtime.fillAligned+300>: or r30,r30,r30 # mdoom
nop
<runtime.fillAligned+304>: not r3,r30
r3 now ~(x-(x>>(m-1))) -- WHOOPS
The or r30,r30,r30 was meant to be or-ing in the earlier value
of r30 which was overwritten by the output of the subf.
Combined ChangeLog (needed for the scripts to understand):
gcc/ChangeLog
* config/rs6000/genfusion.pl (gen_logical_addsubf): Refactor to
add generation of logical-add and add-logical fusion pairs. Add
earlyclobber to alts 0/1.
(gen_addadd): Add earlyclobber to alts 0/1.
* config/rs6000/rs6000-cpus.def: Add new fusion to ISA 3.1 mask
and powerpc mask.
* config/rs6000/rs6000.c (rs6000_option_override_internal): Turn on
logical-add and add-logical fusion by default.
* config/rs6000/rs6000.opt: Add -mpower10-fusion-logical-add and
-mpower10-fusion-add-logical options.
* config/rs6000/fusion.md: Regenerate file.
gcc/testsuite/ChangeLog:
* gcc.target/powerpc/fusion-p10-logadd.c: New file.
Jakub Jelinek [Wed, 16 Jun 2021 11:10:48 +0000 (13:10 +0200)]
testsuite: Use noipa attribute instead of noinline, noclone
I've noticed this test now on various arches sometimes FAILs, sometimes
PASSes (the line 12 test in particular).
The problem is that a = 0; initialization in the caller no longer happens
before the f(&a) call as what the argument points to is only used in
debug info.
Making the function noipa forces the caller to initialize it and still
tests what the test wants to test, namely that we don't consider *p as
valid location for the c variable at line 18 (after it has been overwritten
with *p = 1;).
2021-06-16 Jakub Jelinek <jakub@redhat.com>
* gcc.dg/guality/pr49888.c (f): Use noipa attribute instead of
noinline, noclone.
Jakub Jelinek [Wed, 16 Jun 2021 08:45:27 +0000 (10:45 +0200)]
libffi: Fix up x86_64 classify_argument
As the following testcase shows, libffi didn't handle properly
classify_arguments of structures at byte offsets not divisible by
UNITS_PER_WORD. The following patch adjusts it to match what
config/i386/ classify_argument does for that and also ports the
PR38781 fix there (the second chunk).
* src/x86/ffi64.c (classify_argument): For FFI_TYPE_STRUCT set words
to number of words needed for type->size + byte_offset bytes rather
than just type->size bytes. Compute pos before the loop and check
total size of the structure.
* testsuite/libffi.call/nested_struct12.c: New test.
Jakub Jelinek [Tue, 15 Jun 2021 09:36:47 +0000 (11:36 +0200)]
expr: Fix up VEC_PACK_TRUNC_EXPR expansion [PR101046]
The following testcase ICEs, because we have a mode mismatch.
VEC_PACK_TRUNC_EXPR's operands have different modes from the result
(same vector mode size but twice as large element),
but we were passing non-NULL subtarget with the mode of the result
to the expansion of its arguments, so the VEC_PERM_EXPR in one of the
operands which had V8SImode operands and result had V16HImode target.
Fixed by clearing the subtarget if we are changing mode.
2021-06-15 Jakub Jelinek <jakub@redhat.com>
PR target/101046
* expr.c (expand_expr_real_2) <case VEC_PACK_FIX_TRUNC_EXPR,
case VEC_PACK_TRUNC_EXPR>: Clear subtarget when changing mode.
Jakub Jelinek [Fri, 11 Jun 2021 10:59:43 +0000 (12:59 +0200)]
simplify-rtx: Fix up simplify_logical_relational_operation for vector IOR [PR101008]
simplify_relational_operation callees typically return just const0_rtx
or const_true_rtx and then simplify_relational_operation attempts to fix
that up if the comparison result has vector mode, or floating mode,
or punt if it has scalar mode and vector mode operands (it doesn't know how
exactly to deal with the scalar masks).
But, simplify_logical_relational_operation has a special case, where
it attempts to fold (x < y) | (x >= y) etc. and if it determines it is
always true, it just returns const_true_rtx, without doing the dances that
simplify_relational_operation does.
That results in an ICE on the following testcase, where such folding happens
during expansion (of debug stmts into DEBUG_INSNs) and we ICE because
all of sudden a VOIDmode rtx appears where it expects a vector (V4SImode)
rtx.
The following patch fixes that by moving the adjustement into a separate
helper routine and using it from both simplify_relational_operation and
simplify_logical_relational_operation.
2021-06-11 Jakub Jelinek <jakub@redhat.com>
PR rtl-optimization/101008
* simplify-rtx.c (relational_result): New function.
(simplify_logical_relational_operation,
simplify_relational_operation): Use it.
Jakub Jelinek [Thu, 10 Jun 2021 07:28:27 +0000 (09:28 +0200)]
ifcvt: Fix -fcompare-debug bug [PR100852]
The following testcase fails -fcompare-debug, because it is ifcvt optimized
into umin only with -g0 and not with -g - the function(s) use
prev_nonnote_insn, which without -g finds a real insn the code is looking
for, while with -g finds a DEBUG_INSN.
2021-06-10 Jakub Jelinek <jakub@redhat.com>
PR debug/100852
* ifcvt.c (noce_get_alt_condition, noce_try_abs): Use
prev_nonnote_nondebug_insn instead of prev_nonnote_insn.
Jakub Jelinek [Mon, 7 Jun 2021 07:28:31 +0000 (09:28 +0200)]
fold-const: Fix up fold_read_from_vector [PR100887]
The callers of fold_read_from_vector expect that the index they pass is
an index of an element in the vector and the function does that most of the
time. But we allow CONSTRUCTORs with VECTOR_TYPE to have VECTOR_TYPE
elements and in that case every CONSTRUCTOR element represents not just one
index (with the exception of V1 vectors), but multiple.
So returning zero vector if i >= CONSTRUCTOR_NELTS or returning some
CONSTRUCTOR_ELT's value might not be what the callers expect.
Fixed by punting if the first element has vector type.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
In theory we could instead recurse (and assert that for CONSTRUCTORs of
vector elements we have always all elements specified like tree-cfg.c
verifies?) after adjusting the index appropriately.
2021-06-07 Jakub Jelinek <jakub@redhat.com>
PR target/100887
* fold-const.c (fold_read_from_vector): Return NULL if trying to
read from a CONSTRUCTOR with vector type elements.
Jakub Jelinek [Mon, 7 Jun 2021 07:25:37 +0000 (09:25 +0200)]
tree-inline: Fix up __builtin_va_arg_pack handling [PR100898]
The following testcase ICEs, because gimple_call_arg_ptr (..., 0)
asserts that there is at least one argument, while we were using
it even if we didn't copy anything just to get a pointer from/to which
the zero arguments should be copied.
Fixed by guarding the memcpy calls. Also, the code was calling
gimple_call_num_args too many times - 5 times instead of 2, so the patch
adds two temporaries for those.
2021-06-07 Jakub Jelinek <jakub@redhat.com>
PR middle-end/100898
* tree-inline.c (copy_bb): Only use gimple_call_arg_ptr if memcpy
should copy any arguments. Don't call gimple_call_num_args
on id->call_stmt or call_stmt more than once.
Jakub Jelinek [Sun, 6 Jun 2021 17:37:06 +0000 (19:37 +0200)]
openmp: Call c_omp_adjust_map_clauses even for combined target [PR100902]
When looking at in_reduction support for target, I've noticed that
c_omp_adjust_map_clauses is not called for the combined target case.
The following patch fixes it.
Unfortunately, there are other issues.
One is (also mentioned in the PR) that currently the pointer attachment
stuff seems to be clause ordering dependent (the standard says that clause
ordering on the same construct does not matter), the baz and qux cases
in the PR are rejected while when swapped it is accepted.
Note, the order of clauses in GCC really is treated as insignificant
initially and only later on the compiler can adjust the ordering (e.g. when
we sort map clauses based on what they refer to etc.) and in particular,
clauses from parsing is reverse of the order in user code, while
c_omp_split_clauses performed for combined/composite constructs typically
reverses that ordering, i.e. makes it follow the user code ordering.
And another one is I'm slightly afraid c_omp_adjust_map_clauses might
misbehave in templates, though haven't tried to verify it with testcases.
When processing_template_decl, the non-dependent clauses will be handled
usually the same as when not in a template, but dependent clauses aren't
processed or only limited processing is done there, and rest is deferred
till later. From quick skimming of c_omp_adjust_map_clauses, it seems
it might not be very happy about non-processed map clauses that might
still have the TREE_LIST representation of array sections, or might
not have finalized decls or base decls etc.
So, for this I wonder if cp_parser_omp_target (and other cp/parser.c
callers of c_omp_adjust_map_clauses) shouldn't call it only
if (!processing_template_decl) - perhaps you could add
cp_omp_adjust_map_clauses wrapper that would be
if (!processing_template_decl)
c_omp_adjust_map_clauses (...);
- and call c_omp_adjust_map_clauses from within pt.c after the clauses
are tsubsted and finish_omp_clauses is called again.
2021-06-06 Jakub Jelinek <jakub@redhat.com>
PR c/100902
* c-parser.c (c_parser_omp_target): Call c_omp_adjust_map_clauses
even when target is combined with other constructs.
* parser.c (cp_parser_omp_target): Call c_omp_adjust_map_clauses
even when target is combined with other constructs.
Jakub Jelinek [Fri, 4 Jun 2021 09:20:02 +0000 (11:20 +0200)]
x86: Fix ix86_expand_vector_init for V*TImode [PR100887]
We have vec_initv4tiv2ti and vec_initv2titi patterns which call
ix86_expand_vector_init and assume it works for those modes. For the
case of construction from two half-sized vectors, the code assumes it
will always succeed, but we have only insn patterns with SImode and DImode
element types. QImode and HImode element types are already handled
by performing it with same sized vectors with SImode elements and the
following patch extends that to V*TImode vectors.
2021-06-04 Jakub Jelinek <jakub@redhat.com>
PR target/100887
* config/i386/i386-expand.c (ix86_expand_vector_init): Handle
concatenation from half-sized modes with TImode elements.
Jason Merrill [Wed, 16 Jun 2021 20:09:59 +0000 (16:09 -0400)]
c++: static memfn from non-dependent base [PR101078]
After my patch for PR91706, or before that with the qualified call,
tsubst_baselink returned a BASELINK with BASELINK_BINFO indicating a base of
a still-dependent derived class. We need to look up the relevant base binfo
in the substituted class.
PR c++/101078
gcc/cp/ChangeLog:
* pt.c (tsubst_baselink): Update binfos in non-dependent case.
Jason Merrill [Mon, 14 Jun 2021 21:37:43 +0000 (17:37 -0400)]
libcpp: location comparison within macro [PR100796]
The patch for 96391 changed linemap_compare_locations to give up on
comparing locations from macro expansions if we don't have column
information. But in this testcase, the BOILERPLATE macro is multiple lines
long, so we do want to compare locations within the macro. So this patch
moves the LINE_MAP_MAX_LOCATION_WITH_COLS check inside the block, to use it
for failing gracefully.
PR c++/100796
PR preprocessor/96391
libcpp/ChangeLog:
* line-map.c (linemap_compare_locations): Only use comparison with
LINE_MAP_MAX_LOCATION_WITH_COLS to avoid abort.
gcc/testsuite/ChangeLog:
* g++.dg/plugin/location-overflow-test-pr100796.c: New test.
* g++.dg/plugin/plugin.exp: Run it.
Jason Merrill [Fri, 11 Jun 2021 20:55:30 +0000 (16:55 -0400)]
c++: constexpr and array[0] [PR101029]
build_vec_init_elt exits early if we're initializing a zero-element array,
so build_vec_init needs to do the same to avoid trying to instantiate things
after we've already started throwing important bits away.
Richard Biener [Fri, 11 Jun 2021 07:33:58 +0000 (09:33 +0200)]
middle-end/101009 - fix distance vector recording
This fixes recording of distance vectors in case the DDR has just
constant equal indexes. In that case we expect distance vectors
with zero distances to be recorded which is what was done when
any distance was computed for affine indexes.
2021-06-11 Richard Biener <rguenther@suse.de>
PR middle-end/101009
* tree-data-ref.c (build_classic_dist_vector_1): Make sure
to set *init_b to true when we encounter a constant equal
index pair.
(compute_affine_dependence): Also dump the actual DR_REF.
The following fixes the SLP FMA patterns to preserve reduction
info and the reduction vectorization to consider internal function
call defs for the reduction stmt.
2021-06-09 Richard Biener <rguenther@suse.de>
PR tree-optimization/100981
gcc/
* tree-vect-loop.c (vect_create_epilog_for_reduction): Use
gimple_get_lhs to also handle calls.
* tree-vect-slp-patterns.c (complex_pattern::build): Transfer
reduction info.
gcc/testsuite/
* gfortran.dg/vect/pr100981-1.f90: New testcase.
libgomp/
* testsuite/libgomp.fortran/pr100981-2.f90: New testcase.
Richard Biener [Mon, 14 Jun 2021 12:57:26 +0000 (14:57 +0200)]
tree-optimization/100934 - properly mark irreducible regions for DOM
The jump threading code requires marked irreducible regions for the
purpose of validating jump threading paths but DOM fails to provide
that resulting in mised number of iteration upper bounds clearing.
2021-06-14 Richard Biener <rguenther@suse.de>
PR tree-optimization/100934
* tree-ssa-dom.c (pass_dominator::execute): Properly
mark irreducible regions.
Aaron Sawdey [Fri, 11 Jun 2021 18:49:18 +0000 (13:49 -0500)]
Do not check if SMS succeeds on powerpc
Backported from trunk.
These tests have become unstable and SMS either succeeds or doesn't
depending on things like changes in instruction latency. Removing
the scan-rtl-dump-times checks for powerpc*-*-*.
Jonathan Wakely [Mon, 14 Jun 2021 19:31:00 +0000 (20:31 +0100)]
libstdc++: Fix common_reference for non-reference results [PR100894]
The result of COMMON-REF(A&, B&&) where they have no common reference
type should be ill-formed. Our implementation fails to check that the
COMMON-REF result is a reference, so is well-formed when it shouldn't
be. This means that common_reference uses that result when it shouldn't
do.
The fix is to reject the result of COMMON-REF(A, B) if it's not a
reference, so that common_reference falls through to the next case,
which uses COND-RES, which yields the correct non-reference result.
Signed-off-by: Jonathan Wakely <jwakely@redhat.com>
libstdc++-v3/ChangeLog:
PR libstdc++/100894
* include/std/type_traits (__common_ref_impl<X&, Y&>): Only
use the type if it's a reference.
* testsuite/20_util/common_reference/100894.cc: New test.
Jonathan Wakely [Mon, 14 Jun 2021 12:17:40 +0000 (13:17 +0100)]
libstdc++: Add explicit -std=gnu++17 option to test
This test has no -std option so when the testsuite is run with
-std=gnu++20 or later, this test will use that. The recent addition of
no_unique_address will cause it to FAIL, because that's a reserved word
after C++17. Add an explicit option, so that this test alays uses
exactly C++17.
Jonathan Wakely [Mon, 14 Jun 2021 09:58:15 +0000 (10:58 +0100)]
libstdc++: Use reserved name for attribute [PR101055]
The no_unique_address attribute is not a reserved name until C++20, so
to use it in C++11/14/17 modes we should use the __no_unique_address_
form. We already use that form when using the attribute, but not in the
__has_cpp_attribute check.
libstdc++-v3/ChangeLog:
PR libstdc++/101055
* include/std/tuple: Use reserved form of attribute name.
* testsuite/17_intro/headers/c++2011/all_attributes.cc: Add
check for no_unique_address.
* testsuite/17_intro/headers/c++2014/all_attributes.cc:
Likewise.
* testsuite/17_intro/headers/c++2017/all_attributes.cc:
Likewise.
Patrick Palka [Tue, 18 May 2021 04:28:44 +0000 (00:28 -0400)]
libstdc++: Fix up semiregular-box partial specialization [PR100475]
This makes the in-place constructor of our partial specialization of
__box for already-semiregular types perform direct-non-list-initialization
(in accordance with the specification of the primary template), and
additionally makes the member function data() use std::__addressof.
libstdc++-v3/ChangeLog:
PR libstdc++/100475
* include/std/ranges (__box::__box): Use non-list-initialization
in member initializer list of in-place constructor of the
partial specialization for semiregular types.
(__box::operator->): Use std::__addressof.
* testsuite/std/ranges/adaptors/detail/semiregular_box.cc
(test02): New test.
* testsuite/std/ranges/single_view.cc (test04): New test.
Jonathan Wakely [Fri, 11 Jun 2021 18:18:11 +0000 (19:18 +0100)]
libstdc++: Fix filesystem::path comparisons for C++23
In C++23 there is a basic_string_view(Range&&) constructor, which is
constrained to take a range (specifically, a contiguous_range). When the
filesystem::path comparison operators call lhs.compare(rhs) the overload
taking a string_view is considered, which means checking whether path
satisfies the range concept. That satisfaction result changes depending
whether path::iterator is complete, which is ill-formed; no diagnostic
required. To avoid the problem, this change ensures that the overload
resolution is performed in a context where path::iterator is complete
and the range concept is satisfied. (The result of overload resolution
is always that the compare(const path&) overload is the best match, but
we still have to consider the compare(basic_string_view<value_type>) one
to decide if it even participates in overload resolution).
For std::filesystem::path we can't define the comparison operators later
in the file, because they are hidden friends, so a new helper is
introduced that gets defined when everything else is complete.
For std::experimental::filesystem::path we can just move the definitions
of the comparison operators later in the file.
Signed-off-by: Jonathan Wakely <jwakely@redhat.com>
libstdc++-v3/ChangeLog:
* include/bits/fs_path.h (operator==, operator<=>): Use new
_S_compare function.
(path::_S_compare): New function to call path::compare in a
context where path::iterator is complete.
* include/experimental/bits/fs_path.h (operator<, operator==):
Define after path::iterator is complete.
* testsuite/27_io/filesystem/path/native/conv_c++23.cc: New
test.
* testsuite/experimental/filesystem/path/native/conv_c++23.cc:
New test.
Jonathan Wakely [Wed, 9 Jun 2021 10:03:15 +0000 (11:03 +0100)]
libstdc++: Fix constraint on std::optional assignment [PR 100982]
libstdc++-v3/ChangeLog:
PR libstdc++/100982
* include/std/optional (optional::operator=(const optional<U>&)):
Fix value category used in is_assignable check.
* testsuite/20_util/optional/assignment/100982.cc: New test.
Jonathan Wakely [Mon, 7 Jun 2021 12:02:15 +0000 (13:02 +0100)]
libstdc++: Constrain three-way comparison for std::optional [PR 98842]
The operator<=>(const optional<T>&, const U&) operator is supposed to be
constrained with three_way_comparable_with<U, T> so that it can only be
used when T and U are weakly-equality-comparable and also three-way
comparable.
Adding that constrain completely breaks std::optional comparisons,
because it causes constraint recursion. To avoid that, an additional
check that U is not a specialization of std::optional is needed. That
appears to be a defect in the standard and should be reported to LWG.
Signed-off-by: Jonathan Wakely <jwakely@redhat.com>
libstdc++-v3/ChangeLog:
PR libstdc++/98842
* include/std/optional (operator<=>(const optional<T>& const U&)):
Add missing constraint and add workaround for template
recursion.
* testsuite/20_util/optional/relops/three_way.cc: Check that
type without equality comparison cannot be compared when wrapped
in std::optional.
Jonathan Wakely [Fri, 4 Jun 2021 19:28:04 +0000 (20:28 +0100)]
libstdc++: Implement LWG 3403 for std::ranges::ssize
I already changed the constraints for ranges::ssize to use ranges::size,
this implements the rest of LWG 3403, so that the returned type is the
signed type corresponding to the result of ranges::size.
Signed-off-by: Jonathan Wakely <jwakely@redhat.com>
libstdc++-v3/ChangeLog:
* include/bits/ranges_base.h (_SSize): Return the result of
ranges::size converted to the wider of make-signed-like-t<S> and
ptrdiff_t, rather than the ranges different type.
* testsuite/std/ranges/access/ssize.cc: Adjust expected result
for an iota_view that uses an integer class type for its
difference_type.
Jonathan Wakely [Fri, 4 Jun 2021 14:59:38 +0000 (15:59 +0100)]
libstdc++: Fix value categories used by ranges access CPOs [PR 100824]
The implementation of P2091R0 was incomplete, so that some range access
CPOs used perfect forwarding where they should not. This fixes it by
consistently operating on lvalues.
Some additional changes that are not necessary to fix the bug:
Modify the __as_const helper to simplify its usage. Instead of deducing
the value category from its argument, and requiring callers to forward
the argument as the correct category, add a non-deduced template
parameter which is used for the value category and accept the argument
as an lvalue. This means callers say __as_const<T>(t) instead of
__as_const(std::forward<T>(t)).
Always use an lvalue reference type as the template argument for the
_S_noexcept helpers, so that we only instantiate one specialization for
lvalues and rvalues of the same type.
Move some helper concepts and functions from namespace std::__detail
to ranges::__cust_access, to be consistent with the ranges::begin CPO.
This ensures that the __adl_begin concept and the _Begin::operator()
function are in the same namespace, so unqualified lookup is consistent
and the poison pills for begin are visible to both.
Simplified static assertions for arrays, because the expression a+0 is
already ill-formed for an array of incomplete type.
Signed-off-by: Jonathan Wakely <jwakely@redhat.com>
libstdc++-v3/ChangeLog:
PR libstdc++/100824
* include/bits/iterator_concepts.h (__detail::__decay_copy)
(__detail::__member_begin, __detail::__adl_begin): Move to
namespace ranges::__cust_access.
(__detail::__ranges_begin): Likewise, and rename to __begin.
Remove redundant static assertion.
* include/bits/ranges_base.h (_Begin, _End, _RBegin, _REnd):
Use lvalue in noexcept specifier.
(__as_const): Add non-deduced parameter for value category.
(_CBegin, _CEnd, _CRBegin, _CREnd, _CData): Adjust uses of
__as_const.
(__member_size, __adl_size, __member_empty, __size0_empty):
(__eq_iter_empty, __adl_data): Use lvalue objects in
requirements.
(__sentinel_size): Likewise. Add check for conversion to
unsigned-like.
(__member_data): Allow non-lvalue types to satisfy the concept,
but use lvalue object in requirements.
(_Size, _SSize): Remove forwarding to always use an lvalue.
(_Data): Likewise. Add static assertion for arrays.
* testsuite/std/ranges/access/cdata.cc: Adjust expected
behaviour for rvalues. Add negative tests for ill-formed
expressions.
* testsuite/std/ranges/access/data.cc: Likewise.
* testsuite/std/ranges/access/empty.cc: Adjust expected
behaviour for rvalues.
* testsuite/std/ranges/access/size.cc: Likewise.
Iain Buclaw [Fri, 11 Jun 2021 17:33:07 +0000 (19:33 +0200)]
d: foreach over a tuple doesn't work on 16-bit targets (PR100999)
Improves semantic passes in the front-end around the `foreach' and
`static foreach' statements to be more resilient to compiling in a
minimal D runtime environment. Checking of the index type has been
improved as well so now there won't be needless compiler errors when
using 8 or 16-bit integers as index types when the size fits the
expected loop range.
gcc/d/ChangeLog:
PR d/100999
* dmd/cond.c (lowerArrayAggregate): Run CTFE interpret on foreach
input range.
(createTupleType): Don't generate typeinfo when disabled.
(lowerNonArrayAggregate): Suppress errors when running type semantic.
(staticForeachPrepare): Don't run CTFE interpret from here.
* dmd/dinterpret.c (ctfeInterpret): Add more shortcut cases.
* dmd/expression.c (Expression::checkPostblit): Don't generate
typeinfo when type is missing from library.
* dmd/expressionsem.c (resolvePropertiesX): Remove early error.
* dmd/statementsem.c (StatementSemanticVisitor::declareVariable):
Don't override index type.
(StatementSemanticVisitor::makeTupleForeachBody): Check index type is
integral and index range fits type size.
(StatementSemanticVisitor::visit (ForeachStatement*)): Adjust index
range before testing.
libphobos/ChangeLog:
PR d/100999
* src/std/typecons.d (template Proxy): Check for field or property
functions as the else branch.
gcc/testsuite/ChangeLog:
PR d/100999
* gdc.test/compilable/staticforeach.d: Add new tests.
* gdc.test/fail_compilation/diag16976.d: Likewise.
* gdc.test/fail_compilation/fail117.d: Likewise.
* gdc.test/fail_compilation/fail238_m32.d: Likewise.
* gdc.test/fail_compilation/fail238_m64.d: Likewise.
* gdc.test/fail_compilation/fail7424b.d: Likewise.
* gdc.test/fail_compilation/fail7424c.d: Likewise.
* gdc.test/fail_compilation/fail7424d.d: Likewise.
* gdc.test/fail_compilation/fail7424e.d: Likewise.
* gdc.test/fail_compilation/fail7424f.d: Likewise.
* gdc.test/fail_compilation/fail7424g.d: Likewise.
* gdc.test/fail_compilation/fail7424h.d: Likewise.
* gdc.test/fail_compilation/fail7424i.d: Likewise.
* gdc.test/fail_compilation/fail9766.d: Likewise.
* gdc.test/fail_compilation/ice9406.d: Likewise.
* gdc.test/compilable/extra-files/minimal/object.d: New file.
* gdc.test/compilable/interpret5.d: New test.
* gdc.test/compilable/minimal3.d: New test.
* gdc.test/compilable/test21742.d: New test.
* gdc.test/compilable/test22006.d: New test.
* gdc.test/fail_compilation/b12504.d: New test.
* gdc.test/fail_compilation/fail22006.d: New test.
* gdc.test/fail_compilation/test21927.d: New test.
* gdc.test/fail_compilation/test21939.d: New test.
Aaron Sawdey [Tue, 2 Mar 2021 23:50:52 +0000 (17:50 -0600)]
Add insn types for fusion pairs
This adds new values for insn attr type for p10 fusion. The genfusion.pl
script is modified to use them, and fusion.md regenerated to capture
the new patterns. There are also some formatting only changes to
fusion.md that apparently weren't captured after a previous commit
of genfusion.pl.
Backport from trunk.
gcc/
* config/rs6000/rs6000.md (define_attr "type"): Add types for fusion.
* config/rs6000/genfusion.pl (gen_ld_cmpi_p10): Use new fusion types.
(gen_2logical): Use new fusion types.
* config/rs6000/fusion.md: Regenerate.
gcc/testsuite/
* gcc.dg/sms-4.c: Xfail for powerpc because changes in
instruction latency cause SMS to work or fail.
Patrick Palka [Thu, 10 Jun 2021 22:31:18 +0000 (18:31 -0400)]
c++: normalization of non-templated return-type-req [PR100946]
Here the satisfaction cache is conflating the satisfaction value of the
two return-type-requirements because the corresponding constrained
'auto's have level 2, but they capture an empty current_template_parms.
This ultimately causes the satisfaction cache to think the type
constraint doesn't depend on the deduced type of the expression.
When normalizing the constraints on an 'auto', the assumption made by
normalize_placeholder_type_constraints is that the level of the 'auto'
is one greater than the depth of the captured current_template_parms, an
assumption which is not holding here. So this patch just makes n_p_t_c
adjust the normalization context appropriately in this situation.
PR c++/100946
gcc/cp/ChangeLog:
* constraint.cc (normalize_placeholder_type_constraints): When
normalizing a non-templated return-type-requirement, add a dummy
level to initial_parms.
Patrick Palka [Thu, 3 Jun 2021 13:49:30 +0000 (09:49 -0400)]
libstdc++: Simplify range adaptors' forwarding of bound args [PR100577]
r11-8053 rewrote the range adaptor implementation in conformance with
P2281R1, making partial application act like a SFINAE-friendly perfect
forwarding call wrapper. Making SFINAE-friendliness coexist with
perfect forwarding here requires adding fallback deleted operator()
overloads (as described in e.g. section 5.5 of P0847R6). But
unfortunately, as reported in PR100577, this necessary technique of
using of deleted overloads regresses diagnostics for ill-formed calls to
partially applied range adaptors in GCC.
Although GCC's diagnostics can arguably be improved here by having the
compiler explain why the other candidates weren't viable when overload
resolution selects a deleted candidate, we can also largely work around
this on the library side (and achieve more concise diagnostics than by
a frontend-side improvement alone) if we take advantage of the
observation that not all range adaptors need perfect forwarding call
wrapper semantics, in fact only views::split currently needs it, because
all other range adaptors either take no extra arguments or only
arguments that are expected to be freely/cheaply copyable, e.g. function
objects and integer-like types. (The discussion section in P2281R1 goes
into detail about why views::split is special.)
To that end, this introduces opt-in flags for denoting a range adaptor
as having "simple" extra arguments (in the case of a range adaptor
non-closure) or having a "simple" call operator (in the case of a range
adaptor closure). These flags are then used to conditionally simplify
the operator() for the generic _Partial and _Pipe class templates, down
from needing three overloads thereof (including one defined as deleted)
to just needing a single overload. The end result is that diagnostic
quality is restored for all adaptors except for views::split, and
diagnostics for the adaptors are generally made more concise since
there's only a single _Partial/_Pipe overload to diagnose instead of
three of them.
libstdc++-v3/ChangeLog:
PR libstdc++/100577
* include/std/ranges (_RangeAdaptorClosure): Document
_S_has_simple_call_op mechanism.
(_RangeAdaptor): Document _S_has_simple_extra_args mechanism.
(__closure_has_simple_call_op): New concept.
(__adaptor_has_simple_extra_args): Likewise.
(_Partial<_Adaptor, _Args...>): New partial specialization.
(_Partial<_Adaptor, _Arg>): Likewise.
(_Pipe<_Lhs, _Rhs>): Likewise.
(views::_All::_S_has_simple_call_op): Define to true.
(views::_Filter::_S_has_simple_extra_args): Likewise.
(views::_Transform::_S_has_simple_extra_args): Likewise.
(views::_Take::_S_has_simple_extra_args): Likewise.
(views::_TakeWhile::_S_has_simple_extra_args): Likewise.
(views::_Drop::_S_has_simple_extra_args): Likewise.
(views::_DropWhile::_S_has_simple_extra_args): Likewise.
(views::_Join::_S_has_simple_call_op): Likewise.
(views::_Split): Document why we don't define
_S_has_simple_extra_args to true for this adaptor.
(views::_Common::_S_has_simple_call_op): Define to true.
(views::_Reverse::_S_has_simple_call_op): Likewise.
(views::_Elements::_S_has_simple_call_op): Likewise.
* testsuite/std/ranges/adaptors/100577.cc: New test.
Patrick Palka [Thu, 3 Jun 2021 16:30:29 +0000 (12:30 -0400)]
libstdc++: Avoid hard error in ranges::unique_copy [PR100770]
Here, in the constexpr if condition within ranges::unique_copy, when
input_iterator<_Out> isn't satisfied we must avoid substituting into
iter_value_t<_Out> because the latter isn't necessarily well-formed
then. To that end, this patch factors out the condition into a concept
and uses it throughout.
This patch also makes the definition of our testsuite
output_iterator_wrapper more minimal by setting its value_type, pointer
and reference member types to void. This means our existing tests for
unique_copy already exercise the fix for this bug, so we don't need
to add another test. The only other fallout of this testsuite iterator
change appears in std/ranges/range.cc, where the use of range_value_t
on a test_output_range is now ill-formed.
PR libstdc++/100770
libstdc++-v3/ChangeLog:
* include/bits/ranges_algo.h (__detail::__can_reread_output):
Factor out this concept from ...
(__unique_copy_fn::operator()): ... here. Use the concept
throughout.
* testsuite/std/ranges/range.cc: Remove now ill-formed use
of range_value_t on an output_range.
* testsuite/util/testsuite_iterators.h (output_iterator_wrapper):
Define value_type, pointer and reference member types to void.
Patrick Palka [Fri, 21 May 2021 03:39:05 +0000 (23:39 -0400)]
libstdc++: Fix access issue in iota_view::_Sentinel [PR100690]
libstdc++-v3/ChangeLog:
PR libstdc++/100690
* include/std/ranges (iota_view::_Sentinel::_M_distance_from):
Split out this member function from ...
(iota_view::_Sentinel::operator-): ... here, for sake of access
control.
* testsuite/std/ranges/iota/iota_view.cc (test05): New test.
Patrick Palka [Thu, 6 May 2021 13:11:44 +0000 (09:11 -0400)]
libstdc++: Implement LWG 3533 changes to foo_view::iterator::base()
libstdc++-v3/ChangeLog:
* include/std/ranges (filter_view::_Iterator::base): Make the
const& overload unconstrained and return a const reference as
per LWG 3533. Make unconditionally noexcept.
(transform_view::_Iterator::base): Likewise.
(elements_view::_Iterator::base): Likewise.
Patrick Palka [Thu, 6 May 2021 13:11:42 +0000 (09:11 -0400)]
libstdc++: Implement LWG 3391 changes to move/counted_iterator::base()
libstdc++-v3/ChangeLog:
* include/bits/stl_iterator.h (move_iterator::base): Make the
const& overload unconstrained and return a const reference as
per LWG 3391. Make unconditionally noexcept.
(counted_iterator::base): Likewise.
* testsuite/24_iterators/move_iterator/lwg3391.cc: New test.
* testsuite/24_iterators/move_iterator/move_only.cc: Adjust
has_member_base concept to decay-copy the result of base().
Patrick Palka [Tue, 18 May 2021 14:21:27 +0000 (10:21 -0400)]
libstdc++: Fix access issue in elements_view::_Sentinel [PR100631]
In the earlier commit r12-854 I forgot to also rewrite the other operator-
overload in terms of the split-out member function _M_distance_from.
libstdc++-v3/ChangeLog:
PR libstdc++/100631
* include/std/ranges (elements_view::_Sentinel::operator-): Use
_M_distance_from in the other operator- overload too.
* testsuite/std/ranges/adaptors/elements.cc (test06): Augment test.
Patrick Palka [Tue, 18 May 2021 04:26:07 +0000 (00:26 -0400)]
libstdc++: Fix miscellaneous issues with elements_view::_Sentinel [PR100631]
libstdc++-v3/ChangeLog:
PR libstdc++/100631
* include/std/ranges (elements_view::_Iterator): Also befriend
_Sentinel<!_Const>.
(elements_view::_Sentinel::_M_equal): Templatize.
(elements_view::_Sentinel::_M_distance_from): Split out from ...
(elements_view::_Sentinel::operator-): ... here. Depend on
_Base2 instead of _Base in the return type.
* testsuite/std/ranges/adaptors/elements.cc (test06, test07):
New tests.
Patrick Palka [Thu, 20 May 2021 18:08:17 +0000 (14:08 -0400)]
libstdc++: Implement missing P0896R4 changes to reverse_iterator [PR100639]
This implements the P0896R4 changes to reverse_iterator's member types
value_type, difference_type and reference in C++20 mode, which fixes
taking the reverse_iterator of an iterator with a non-integral
difference_type (such as iota_view<long long>).
libstdc++-v3/ChangeLog:
PR libstdc++/100639
* include/bits/stl_iterator.h (reverse_iterator::difference_type):
In C++20 mode, define in terms of iter_difference_t as per P0896R4.
(reverse_iterator::reference): Likewise, but with iter_reference_t.
(reverse_iterator::value_type): Likewise, but with iter_value_t.
* testsuite/std/ranges/adaptors/reverse.cc (test08): New test.
* testsuite/24_iterators/reverse_iterator/100639.cc: New test.
Iain Buclaw [Thu, 10 Jun 2021 17:59:23 +0000 (19:59 +0200)]
d: Fix ICE in TypeInfoDeclaration, at dmd/declaration.c (PR100967)
Generate a stub TypeInfo class even if the root Object class is missing.
The front-end will take care of issuing an error and abort the
compilation when running semantic on constructed TypeInfo objects.
The errors issued by the code generation pass relating to missing or
disabled RTTI has been consolidated into a single function, so that a
meaningful error will be emitted before the front-end terminates.
gcc/d/ChangeLog:
PR d/100967
* d-frontend.cc (getTypeInfoType): Move TypeInfo checks to
check_typeinfo_type and call new function.
* d-tree.h (check_typeinfo_type): Declare.
* typeinfo.cc: Include dmd/scope.h.
(create_frontend_tinfo_types): Generate front-end types even if Object
is missing.
(build_typeinfo): Move TypeInfo checks to check_typeinfo_type and call
new function.
(check_typeinfo_type): New function.
Iain Buclaw [Wed, 9 Jun 2021 17:37:22 +0000 (19:37 +0200)]
d: Respect explicit align(N) type alignment (PR100935)
It was previously the natural type alignment, defined as the maximum of
the field alignments for an aggregate. Make sure an explicit align(N)
overrides it.
gcc/d/ChangeLog:
PR d/100935
* dmd/mtype.c (Type::getProperty): Prefer explicit alignment over
natural alignment for alignof property.
gcc/testsuite/ChangeLog:
PR d/100935
* gdc.test/compilable/aggr_alignment.d: Add test cases.
Marek Polacek [Mon, 7 Jun 2021 20:06:00 +0000 (16:06 -0400)]
c++: explicit() ignored on deduction guide [PR100065]
When we have explicit() with a value-dependent argument, we can't
evaluate it at parsing time, so cp_parser_function_specifier_opt stashes
the argument into the decl-specifiers and grokdeclarator then stores it
into explicit_specifier_map, which is then used when substituting the
function decl. grokdeclarator stores it for constructors and conversion
functions, but we also need to do it for deduction guides, otherwise
we'll forget that we've seen an explicit-specifier as in the attached
test.
PR c++/100065
gcc/cp/ChangeLog:
* decl.c (grokdeclarator): Store a value-dependent
explicit-specifier even for deduction guides.
Eric Botcazou [Wed, 9 Jun 2021 10:37:47 +0000 (12:37 +0200)]
Fix old thinko in warning on pointer for storage order purposes
gcc/c
PR c/100920
* c-typeck.c (convert_for_assignment): Test fndecl_built_in_p to
spot built-in functions. Do not warn on pointer assignment and
initialization for storage order purposes if the RHS is a call
to a DECL_IS_MALLOC function.
gcc/testsuite/
* gcc.dg/sso-14.c: New test.
ARC processor can use LP instruction to implement zero overlay loops.
The current inplementation doesn't handle the unlikely situation when
the loop iterator is located in memory. Refurbish the loop_end insn
pattern into a define_insn_and_split pattern.
Rework the (u)maddhisi4 patterns and use VMAC2H(U) instruction instead
of the 64bit MAC(U) instruction.
This fixes the next execute.exp failures:
arith-rand-ll.c -O2 execution test
arith-rand-ll.c -O3 execution test
pr78726.c -O2 execution test
pr78726.c -O3 execution test
ARCv2HS can use a limited number of instructions to implement 64bit
moves. The VADD2 is used as a 64bit move, the LDD/STD are 64 bit loads
and stores. All those instructions are not baseline, hence we need to
provide alternatives when they are not available or cannot be generate
due to instruction restriction.
This patch is cleaning up those move patterns, and updates splits
instruction lengths.
Thomas Rodgers [Tue, 8 Jun 2021 22:51:53 +0000 (15:51 -0700)]
libstdc++: Fix Wrong param type in :atomic_ref<_Tp*>::wait [PR100889]
libstdc++-v3/ChangeLog:
PR libstdc++/100889
* include/bits/atomic_base.h (atomic_ref<_Tp*>::wait):
Change parameter type from _Tp to _Tp*.
* testsuite/29_atomics/atomic_ref/wait_notify.cc: Extend
coverage of types tested.
Jason Merrill [Tue, 8 Jun 2021 13:19:58 +0000 (09:19 -0400)]
c++: braced-list overload resolution [PR100963]
My PR969626 patch made us ignore template candidates when there's a perfect
non-template candidate. In this case, we were considering B(int) a perfect
match for B({0}), but the brace elision makes it imperfect.
Jason Merrill [Fri, 16 Apr 2021 15:13:40 +0000 (11:13 -0400)]
c++: alias with same name as base fn [PR91706]
This is a bit complex. Looking up c<T> in the definition of D::c finds
C::c, OK. Looking up c in the definition of E finds D::c, OK. Since the
alias is not dependent, we strip it from the template argument, leaving
using E = A<decltype(c<T>())>;
where 'c' still refers to C::c. But instantiating E looks up 'c' again and
finds D::c, which isn't a function, and sadness ensues.
I think the bug here is looking up 'c' in D at instantiation time; the
declaration we found before is not dependent. This seems to happen because
baselink_for_fns gets BASELINK_BINFO wrong; it is supposed to be the base
where lookup found the functions, C in this case.
Jason Merrill [Mon, 7 Jun 2021 21:51:24 +0000 (17:51 -0400)]
c++: fix modules binfo merging
My coming fix for PR91706 caused some regressions in the modules testsuite.
This turned out to be because the change to properly use the base subobject
BINFO as BASELINK_BINFO hit problems with the code for merging binfos. The
tree reader needed a typo fix. The duplicate_hash function was crashing on
the BINFO for a variadic base in <variant>. I started fixing the hash
function, but then noticed that there's no ::equal function defined;
duplicate_hash just uses pointer equality, so we might as well also
use the normal pointer hash for the moment.
Patrick Palka [Thu, 3 Jun 2021 13:37:11 +0000 (09:37 -0400)]
c++: using-enum and access specifiers [PR100862]
When copying the enumerators imported by a class-scope using-enum
declaration, we need to override current_access_specifier so that
finish_member_declaration gives the copies the same access as the
using-enum decl. (A class-scope using-enum is processed late, so
current_access_specifier at this point is otherwise set to the last
access specifier within the class.) To that end, this patch makes
handle_using_decl call set_current_access_from_decl accordingly.
For consistency, this patch makes build_enumerator use
set_current_access_from_decl too.
PR c++/100862
gcc/cp/ChangeLog:
* pt.c (set_current_access_from_decl): Move to ...
* class.c (set_current_access_from_decl): ... here.
(handle_using_decl): Use it to propagate the access of the
using-enum decl to the copy of the imported enumerator.
* cp-tree.h (set_current_access_from_decl): Declare.
* decl.c (build_enumerator): Simplify using make_temp_override
and set_current_access_from_decl.
Patrick Palka [Fri, 4 Jun 2021 17:46:53 +0000 (13:46 -0400)]
c++: tsubst_function_decl and excess arg levels [PR100102]
Here, when instantiating the dependent alias template
duration::__is_harmonic with args={{T,U},{int}}, we find ourselves
substituting the function decl _S_gcd. Since we have more arg levels
than _S_gcd has parm levels, an old special case in tsubst_function_decl
causes us to unwantedly reduce args to its innermost level, yielding
args={int}, which leads to a nonsensical substitution into the decl
context and eventually a crash.
The comment for this special case refers to three examples for which we
ought to see more arg levels than parm levels here, but none of the
examples actually demonstrate this. In the first example, when
defining S<int>::f(U) parms_depth is 2 and args_depth is 1, and
later when instantiating say S<int>::f<char> both depths are 2. In the
second example, when substituting the template friend declaration
parms_depth is 2 and args_depth is 1, and later when instantiating f
both depths are 1. Finally, the third example is invalid since we can't
specialize a member template of an unspecialized class template like
that.
Given that this reduction code seems no longer relevant for its
documented purpose and that it causes problems as in the PR, this patch
just removes it. Note that as far as bootstrap/regtest is concerned,
this code is dead; the below two tests would be the first to reach it.
PR c++/100102
gcc/cp/ChangeLog:
* pt.c (tsubst_function_decl): Remove old code for reducing
args when it has excess levels.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/alias-decl-72.C: New test.
* g++.dg/cpp0x/alias-decl-72a.C: New test.
projects / thirdparty / gcc.git / log
