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.
Avi Kivity [Mon, 7 Jun 2021 15:19:05 +0000 (11:19 -0400)]
libstdc++: add missing typename for dependent type in ranges::elements_view [PR100900]
Clang complains about the missing typename. I believe it's not required
in a more complete implementation of C++, but it's nicer to support
less complete implementations.
Correct implementation of random_init() when -fcoarray=lib is given.
Backport from mainline.
2021-06-06 Andre Vehreschild <vehre@gcc.gnu.org>
Steve Kargl <kargl@gcc.gnu.org>
gcc/fortran/ChangeLog:
PR fortran/98301
* trans-decl.c (gfc_build_builtin_function_decls): Move decl.
* trans-intrinsic.c (conv_intrinsic_random_init): Use bool for
lib-call of caf_random_init instead of logical (4-byte).
* trans.h: Add tree var for random_init.
libgfortran/ChangeLog:
PR fortran/98301
* caf/libcaf.h (_gfortran_caf_random_init): New function.
* caf/single.c (_gfortran_caf_random_init): New function.
* gfortran.map: Added fndecl.
* intrinsics/random_init.f90: Implement random_init.
Iain Buclaw [Fri, 4 Jun 2021 17:38:26 +0000 (19:38 +0200)]
d: Fix ICE in gimplify_var_or_parm_decl, at gimplify.c:2755 (PR100882)
Constructor calls for temporaries were reusing the TARGET_EXPR_SLOT of a
TARGET_EXPR for an assignment, which later got passed to `build_assign',
which stripped away the outer TARGET_EXPR, leaving a reference to a lone
temporary with no declaration.
This stripping away of the TARGET_EXPR also discarded any cleanups that
may have been assigned to the expression as well.
So now the reuse of TARGET_EXPR_SLOT has been removed, and
`build_assign' now constructs assignments inside the TARGET_EXPR_INITIAL
slot. This has also been extended to `return_expr', to deal with
possibility of a TARGET_EXPR being returned.
gcc/d/ChangeLog:
PR d/100882
* d-codegen.cc (build_assign): Construct initializations inside
TARGET_EXPR_INITIAL.
(compound_expr): Remove intermediate expressions that have no
side-effects.
(return_expr): Construct returns inside TARGET_EXPR_INITIAL.
* expr.cc (ExprVisitor::visit (CallExp *)): Remove useless assignment
to TARGET_EXPR_SLOT.
gcc/testsuite/ChangeLog:
PR d/100882
* gdc.dg/pr100882a.d: New test.
* gdc.dg/pr100882b.d: New test.
* gdc.dg/pr100882c.d: New test.
* gdc.dg/torture/pr100882.d: New test.
Harald Anlauf [Fri, 4 Jun 2021 17:23:48 +0000 (19:23 +0200)]
Fortran - ICE in inline_matmul_assign
Restrict inlining of matmul to those cases where assignment to the
result array does not need special treatment.
gcc/fortran/ChangeLog:
PR fortran/99839
* frontend-passes.c (inline_matmul_assign): Do not inline matmul
if the assignment to the resulting array if it is not of canonical
type (real/integer/complex/logical).
gcc/testsuite/ChangeLog:
PR fortran/99839
* gfortran.dg/inline_matmul_25.f90: New test.
Eric Botcazou [Thu, 3 Jun 2021 11:29:32 +0000 (13:29 +0200)]
Fix miscompilation of predicate on bit-packed array types
This is a regression present on the mainline and 11 branch in the form of a
miscompilation by the new mod/ref IPA pass of code that passes constrained
bit-packed array objets in a call to a subprograms taking unconstrained
bit-packed array parameters, which occurs for predicate on bit-packed array
types for example.
gcc/ada/
* gcc-interface/decl.c (gnat_to_gnu_entity) <E_Array_Type>: Add PAT
local constant and use it throughout. If it is set, use a ref-all
pointer type for the pointer-to-array field of the fat pointer type.
<E_Array_Subtype>: Add PAT local constant and use it throughout.
gcc/testsuite/
* gnat.dg/bit_packed_array6.adb: New test.
* gnat.dg/bit_packed_array6_pkg.ads: New helper.
Eric Botcazou [Thu, 3 Jun 2021 10:39:39 +0000 (12:39 +0200)]
Tame fix for PR ipa/99122
The return part has a major performance impact in Ada where variable-sized
types are first-class citizens, but it turns out that it is not exercized
in the testsuite yet, so back it out for now.
gcc/
PR ipa/99122
* tree-inline.c (inline_forbidden_p): Remove test on return type.
gcc/testsuite/
* gnat.dg/inline22.adb: New test.
Eric Botcazou [Mon, 10 May 2021 15:41:01 +0000 (17:41 +0200)]
Remove call to gcc_unreachable in range-op.cc
The Ada testcase happens to stumble on the call to gcc_unreachable in
operator_bitwise_xor::op1_range, but there is nothing wrong going on
and it's safe to let it go through.
gcc/
* range-op.cc (get_bool_state): Adjust head comment.
(operator_not_equal::op1_range): Fix comment.
(operator_bitwise_xor::op1_range): Remove call to gcc_unreachable.
gcc/testsuite/
* gnat.dg/specs/opt5.ads: New test.
* gnat.dg/specs/opt5_pkg.ads: New helper.
Alex Coplan [Wed, 19 May 2021 14:52:45 +0000 (15:52 +0100)]
arm: Fix ICE with CMSE nonsecure calls on Armv8.1-M [PR100333]
As the PR shows, we ICE shortly after expanding nonsecure calls for Armv8.1-M.
For Armv8.1-M, we have TARGET_HAVE_FPCXT_CMSE. As it stands, the expander
(arm.md:nonsecure_call_internal) moves the callee's address to a register (with
copy_to_suggested_reg) only if !TARGET_HAVE_FPCXT_CMSE.
However, looking at the pattern which the insn appears to be intended to
match (thumb2.md:*nonsecure_call_reg_thumb2_fpcxt), it requires the
callee's address to be in a register.
This patch therefore just forces the callee's address into a register in
the expander.
gcc/ChangeLog:
PR target/100333
* config/arm/arm.md (nonsecure_call_internal): Always ensure
callee's address is in a register.
gcc/testsuite/ChangeLog:
PR target/100333
* gcc.target/arm/cmse/pr100333.c: New test.
Jonathan Wakely [Thu, 20 May 2021 15:39:06 +0000 (16:39 +0100)]
libstdc++: Use __builtin_unreachable for constexpr assertions [PR 100676]
The current implementation of compile-time precondition checks causes
compilation to fail by calling a non-constexpr function declared at
block scope. This breaks the CUDA compiler, which wraps some libstdc++
headers in a pragma that declares everything as a __host__ __device__
function, but others are not wrapped and so everything is a __host__
function. The local declaration thus gets redeclared as two different
types of function, which doesn't work.
Just use __builtin_unreachable to make constant evaluation fail, instead
of the local function declaration. Also simplify the assertion macros,
which has the side effect of giving simpler compilation errors when
using Clang.
libstdc++-v3/ChangeLog:
PR libstdc++/100676
* include/bits/c++config (__glibcxx_assert_1): Rename to ...
(__glibcxx_constexpr_assert): ... this.
(__glibcxx_assert_impl): Use __glibcxx_constexpr_assert.
(__glibcxx_assert): Define as either __glibcxx_constexpr_assert
or __glibcxx_assert_impl.
(__glibcxx_assert_2): Remove
* include/debug/macros.h (_GLIBCXX_DEBUG_VERIFY_AT_F): Use
__glibcxx_constexpr_assert instead of __glibcxx_assert_1.
* testsuite/21_strings/basic_string_view/element_access/char/back_constexpr_neg.cc:
Adjust expected error.
* testsuite/21_strings/basic_string_view/element_access/char/constexpr_neg.cc:
Likewise.
* testsuite/21_strings/basic_string_view/element_access/char/front_constexpr_neg.cc:
Likewise.
Likewise.
* testsuite/21_strings/basic_string_view/element_access/wchar_t/back_constexpr_neg.cc:
Likewise.
* testsuite/21_strings/basic_string_view/element_access/wchar_t/constexpr_neg.cc:
Likewise.
* testsuite/21_strings/basic_string_view/element_access/wchar_t/front_constexpr_neg.cc:
Likewise.
* testsuite/23_containers/span/back_neg.cc: Likewise.
* testsuite/23_containers/span/front_neg.cc: Likewise.
* testsuite/23_containers/span/index_op_neg.cc: Likewise.
Jonathan Wakely [Tue, 1 Jun 2021 15:02:45 +0000 (16:02 +0100)]
libstdc++: Fix return value of std::ranges::advance [PR 100833]
The three-argument form of ranges::advance is supposed to return the
difference between the second argument and the distance the iterator was
advanced. When a non-random-access iterator is not advanced (because it
already equals the sentinel) we were returning 0 rather than n - 0.
libstdc++-v3/ChangeLog:
PR libstdc++/100833
* include/bits/ranges_base.h (ranges::advance(iter, n, sentinel)):
Fix return value for no-op case.
* testsuite/24_iterators/range_operations/advance.cc: Test
return values of three-argument overload.
Jonathan Wakely [Wed, 26 May 2021 16:32:53 +0000 (17:32 +0100)]
libstdc++: Change [range.iter.op] functions to function objects [PR 100768]
The standard specifies std::ranges::distance etc as function templates,
but it also requires them to not be found by ADL, and to suppress ADL
when normal unqualified lookup does find them. That means they need to
be function objects.
libstdc++-v3/ChangeLog:
PR libstdc++/100768
* include/bits/ranges_base.h (advance, distance, next, prev):
Replace function templates with function objects.
* testsuite/24_iterators/headers/iterator/synopsis_c++20.cc:
Adjust for changes to function objects.
* testsuite/std/ranges/adaptors/elements.cc: Add using
declarations for names from namespace ranges.
* testsuite/std/ranges/adaptors/transform.cc: Likewise.
* testsuite/24_iterators/range_operations/100768.cc: New test.
Jonathan Wakely [Tue, 1 Jun 2021 10:00:16 +0000 (11:00 +0100)]
libstdc++: Fix installation of python hooks [PR 99453]
When no shared library is installed, the new code to determine the name
of the -gdb.py file yields an empty string. Use the name of the static
library in that case.
libstdc++-v3/ChangeLog:
PR libstdc++/99453
* python/Makefile.am: Use archive name for printer hook if no
dynamic library name is available.
* python/Makefile.in: Regenerate.
projects / thirdparty / gcc.git / log
