Patrick Palka [Mon, 2 May 2022 11:01:33 +0000 (07:01 -0400)]
libstdc++: Don't use std::tolower in <charconv> [PR103911]
As with std::isdigit in r12-6281-gc83ecfbe74a5cf, we shouldn't be using
std::tolower in <charconv> either.
PR libstdc++/103911
libstdc++-v3/ChangeLog:
* src/c++17/floating_from_chars.cc (find_end_of_float): Accept
two delimeters for the exponent part in the form of a possibly
NULL string of length two. Don't use std::tolower.
(pattern): Adjust calls to find_end_of_float accordingly.
H.J. Lu [Fri, 6 May 2022 17:55:53 +0000 (10:55 -0700)]
x86: Add .note.GNU-stack section only for Linux
Add .note.GNU-stack section only for Linux since it may not be supported
on non-Linux OSes. __ELF__ isn't checked since these tests can only run
on Linux/x86 ELF systems.
Jakub Jelinek [Tue, 10 May 2022 16:34:08 +0000 (18:34 +0200)]
isel: Fix up gimple_expand_vec_set_expr [PR105528]
The following testcase ICEs (and only without -g), because we don't replace
one VEC_COND_EXPR with .VCOND* call.
We don't do that because gimple_expand_vec_set_expr adds some stmts before
*gsi and then uses gsi_remove to remove it. gsi_remove moves the iterator
to the next stmt and in the caller we then do gsi_next before looking at
another stmt, which means we can skip processing of one stmt, which in this
case happened to be a VEC_COND_EXPR but with -g is some debug stmt in
between. As we always emit some stmts before it, it is easy to update the
iterator to the last stmt emitted there, so that caller continues really
with the next stmt.
2022-05-10 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/105528
* gimple-isel.cc (gimple_expand_vec_set_expr): After gsi_remove
set *gsi to gsi_for_stmt (ass_stmt). Fix up function comment.
Eric Botcazou [Tue, 10 May 2022 07:33:16 +0000 (09:33 +0200)]
Fix internal error with vectorization on SPARC
This is a regression present since the 10.x series, but the underlying issue
has been there since the TARGET_VEC_PERM_CONST hook was implemented, in the
form of an ICE when expanding a constant VEC_PERM_EXPR in V4QI, while the
back-end only supports V8QI constant VEC_PERM_EXPRs.
gcc/
PR target/105292
* config/sparc/sparc.c (sparc_vectorize_vec_perm_const): Return
true only for 8-byte vector modes.
gcc/testsuite/
* gcc.target/sparc/20220510-1.c: New test.
Jonathan Wakely [Tue, 25 Jan 2022 10:11:36 +0000 (10:11 +0000)]
libstdc++: Define _GNU_SOURCE for secure_getenv on Cygwin [PR104217]
For GNU/Linux G++ defines _GNU_SOURCE automatically, but not for Cygwin.
This means secure_getenv is not declared by Cygwin's <stdlib.h>, even
though autoconf detected it is present in the library. Define it in the
source files that want to use secure_getenv.
Jonathan Wakely [Fri, 6 May 2022 20:19:17 +0000 (21:19 +0100)]
libstdc++: Fix deserialization for std::normal_distribution [PR105502]
This fixes a regression in std::normal_distribution deserialization that
caused the object to be left unchanged if the __state_avail value read
from the stream was false.
libstdc++-v3/ChangeLog:
PR libstdc++/105502
* include/bits/random.tcc
(operator>>(basic_istream<C,T>&, normal_distribution<R>&)):
Update state when __state_avail is false.
* testsuite/26_numerics/random/normal_distribution/operators/serialize.cc:
Check that deserialized object equals serialized one.
Jonathan Wakely [Fri, 6 May 2022 13:31:06 +0000 (14:31 +0100)]
libstdc++: Fix test that fails on Solaris [PR104731]
On Solaris the dirent::d_name member is a single char, causing this test
to fail with warnings about buffer overflow. Change the test to use a
union with additional space for writing a string to the d_name member.
libstdc++-v3/ChangeLog:
PR libstdc++/104731
* testsuite/27_io/filesystem/iterators/error_reporting.cc:
Use a trailing char array as storage for dirent::d_name.
Jakub Jelinek [Wed, 4 May 2022 08:07:36 +0000 (10:07 +0200)]
c++: Don't emit deprecated warnings on lambda declarations
On the following testcase, we emit deprecated warnings
even on merge declarations of those lambdas (the dg-bogus directives), while
IMHO we should emit them only when something actually calls those lambdas.
The following patch temporarily disables that diagnostics during
maybe_add_lambda_conv_op.
PR2173R1 also says that ambiguity between attribute-specifier-seq at the
end of requires-clause and attribute-specifier-seq from lambda-expression
should be resolved to attribute-specifier-seq for the latter. Do we need
to do anything about that? I mean, can a valid requires-clause end with
an attribute-specifier-seq? Say operator int [[]] is valid primary
expression, but requires operator int [[]] isn't valid, nor is
requires operator int, no?
2022-05-04 Jakub Jelinek <jakub@redhat.com>
* lambda.c: Include decl.h.
(maybe_add_lambda_conv_op): Temporarily override deprecated_state to
DEPRECATED_SUPPRESS.
Jakub Jelinek [Thu, 28 Apr 2022 10:33:59 +0000 (12:33 +0200)]
i386: Fix up ix86_gimplify_va_arg [PR105331]
On the following testcase we emit a bogus
'va_arg_tmp.5' may be used uninitialized
warning. The reason is that when gimplifying the addr = &temp;
statement, the va_arg_tmp temporary var for which we emit ADDR_EXPR
is not TREE_ADDRESSABLE, prepare_gimple_addressable emits some extra
code to initialize the newly addressable var from its previous value,
but it is a new variable which hasn't been initialized yet and will
be later, so we end up initializing it with uninitialized SSA_NAME:
va_arg_tmp.6 = va_arg_tmp.5_14(D);
addr.2_16 = &va_arg_tmp.6;
_17 = MEM[(double *)sse_addr.4_13];
MEM[(double * {ref-all})addr.2_16] = _17;
and with -O1 we actually don't DSE it before the warning is emitted.
If we make the temp TREE_ADDRESSABLE before the gimplification, then
this prepare_gimple_addressable path isn't taken and we effectively
omit the first statement above and so the bogus warning is gone.
I went through other backends and didn't find another instance of this
problem.
2022-04-28 Jakub Jelinek <jakub@redhat.com>
PR target/105331
* config/i386/i386.c (ix86_gimplify_va_arg): Mark va_arg_tmp
temporary TREE_ADDRESSABLE before trying to gimplify ADDR_EXPR
of it.
Jakub Jelinek [Wed, 27 Apr 2022 06:34:18 +0000 (08:34 +0200)]
asan: Fix up asan_redzone_buffer::emit_redzone_byte [PR105396]
On the following testcase, we have in main's frame 3 variables,
some red zone padding, 4 byte d, followed by 12 bytes of red zone padding, then
8 byte b followed by 24 bytes of red zone padding, then 40 bytes c followed
by some red zone padding.
The intended content of shadow memory for that is (note, each byte describes
8 bytes of memory):
f1 f1 f1 f1 04 f2 00 f2 f2 f2 00 00 00 00 00 f3 f3 f3 f3 f3
left red d mr b middle r c right red zone
f1 is left red zone magic
f2 is middle red zone magic
f3 is right red zone magic
00 when all 8 bytes are accessible
01-07 when only 1 to 7 bytes are accessible followed by inaccessible bytes
The -fdump-rtl-expand-details dump makes it clear that it misbehaves:
Flushing rzbuffer at offset -160 with: f1 f1 f1 f1
Flushing rzbuffer at offset -128 with: 04 f2 00 00
Flushing rzbuffer at offset -128 with: 00 00 00 f2
Flushing rzbuffer at offset -96 with: f2 f2 00 00
Flushing rzbuffer at offset -64 with: 00 00 00 f3
Flushing rzbuffer at offset -32 with: f3 f3 f3 f3
In the end we end up with
f1 f1 f1 f1 00 00 00 f2 f2 f2 00 00 00 00 00 f3 f3 f3 f3 f3
shadow bytes because at offset -128 there are 2 overlapping stores
as asan_redzone_buffer::emit_redzone_byte has flushed the temporary 4 byte
buffer in the middle.
The function is called with an offset and value. If the passed offset is
consecutive with the prev_offset + buffer size (off == offset), then
we handle it correctly, similarly if the new offset is far enough from the
old one (we then flush whatever was in the buffer and if needed add up to 3
bytes of 00 before actually pushing value.
But what isn't handled correctly is when the offset isn't consecutive to
what has been added last time, but it is in the same 4 byte word of shadow
memory (32 bytes of actual memory), like the above case where
we have consecutive 04 f2 and then skip one shadow memory byte (aka 8 bytes
of real memory) and then want to emit f2. Emitting that as a store
of little-endian 0x0000f204 followed by a store of 0xf2000000 to the same
address doesn't work, we want to emit 0xf200f204.
The following patch does that by pushing 1 or 2 00 bytes.
Additionally, as a small cleanup, instead of using
m_shadow_bytes.safe_push (value);
flush_if_full ();
in all of if, else if and else bodies it sinks those 2 stmts to the end
of function as all do the same thing.
2022-04-27 Jakub Jelinek <jakub@redhat.com>
PR sanitizer/105396
* asan.c (asan_redzone_buffer::emit_redzone_byte): Handle the case
where offset is bigger than off but smaller than m_prev_offset + 32
bits by pushing one or more 0 bytes. Sink the
m_shadow_bytes.safe_push (value); flush_if_full (); statements from
all cases to the end of the function.
Jakub Jelinek [Fri, 22 Apr 2022 11:38:11 +0000 (13:38 +0200)]
rtlanal: Fix up replace_rtx [PR105333]
The following testcase FAILs, because replace_rtx replaces a REG with
CONST_WIDE_INT inside of a SUBREG, which is an invalid transformation
because a SUBREG relies on SUBREG_REG having non-VOIDmode but
CONST_WIDE_INT has VOIDmode.
replace_rtx already has code to deal with it, but it was doing
it only for CONST_INTs. The following patch does it also for
VOIDmode CONST_DOUBLE or CONST_WIDE_INT.
2022-04-22 Jakub Jelinek <jakub@redhat.com>
PR rtl-optimization/105333
* rtlanal.c (replace_rtx): Use simplify_subreg or
simplify_unary_operation if CONST_SCALAR_INT_P rather than just
CONST_INT_P.
H.J. Lu [Fri, 29 Apr 2022 17:26:24 +0000 (10:26 -0700)]
x86: Add missing .note.GNU-stack to assembly source
Add .note.GNU-stack assembly source to avoid linker warning:
ld: warning: /tmp/ccPZSZ7Z.o: missing .note.GNU-stack section implies executable stack
ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker
FAIL: gcc.target/i386/iamcu/test_3_element_struct_and_unions.c compilation, -O0
The floating-point overloads of from_char are only declared if
_GLIBCXX_HAVE_USELOCALE is #defined as nonzero. That's exposed from
charconv as __cpp_lib_to_chars >= 201611L, so guard the test body with
that.
for libstdc++-v3/ChangeLog
PR c++/105324
* testsuite/20_util/from_chars/pr105324.cc: Guard test body
with conditional for floating-point overloads of from_char.
Alexandre Oliva [Tue, 3 May 2022 08:04:23 +0000 (05:04 -0300)]
testsuite: vect: update unaligned message
gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c covers ppc variants
that accept and reject misaligned accesses. The message that it
expects for rejection was removed in the gcc-11 development cycle by
commit r11-1969. The patch adjusted multiple tests to use the message
introduced in r11-1945, but missed this one.
for gcc/testsuite/ChangeLog
* gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c: Update
the expected message for the case in which unaligned accesses
are not allowed.
gcc/analyzer/ChangeLog:
PR analyzer/105252
* svalue.cc (cmp_cst): When comparing VECTOR_CSTs, compare the
types of the encoded elements before calling cmp_cst on them.
gcc/testsuite/ChangeLog:
PR analyzer/105252
* gcc.dg/analyzer/pr105252.c: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Jonathan Wakely [Thu, 28 Apr 2022 12:06:31 +0000 (13:06 +0100)]
libstdc++: Fix error reporting in filesystem::copy [PR99290]
The recursive calls to filesystem::copy should stop if any of them
reports an error.
libstdc++-v3/ChangeLog:
PR libstdc++/99290
* src/c++17/fs_ops.cc (fs::copy): Pass error_code to
directory_iterator constructor, and check on each iteration.
* src/filesystem/ops.cc (fs::copy): Likewise.
* testsuite/27_io/filesystem/operations/copy.cc: Check for
errors during recursion.
* testsuite/experimental/filesystem/operations/copy.cc:
Likewise.
Patrick Palka [Tue, 26 Apr 2022 14:53:38 +0000 (10:53 -0400)]
c++: decltype of non-dependent call of class type [PR105386]
We need to pass tf_decltype when instantiating a non-dependent decltype
operand, like tsubst does in the dependent case, so that we don't force
completion of a prvalue operand's class type.
PR c++/105386
gcc/cp/ChangeLog:
* semantics.c (finish_decltype_type): Pass tf_decltype to
instantiate_non_dependent_expr_sfinae.
Patrick Palka [Tue, 26 Apr 2022 01:49:00 +0000 (21:49 -0400)]
c++: ICE with requires-expr and -Wsequence-point [PR105304]
Here we're crashing from verify_sequence_points for this requires-expr
condition because it contains a templated CAST_EXPR with empty operand,
and verify_tree doesn't ignore this empty operand only because the
manual tail recursion that it performs for unary expression trees skips
the NULL test.
PR c++/105304
gcc/c-family/ChangeLog:
* c-common.c (verify_tree) [restart]: Move up to before the
NULL test.
Patrick Palka [Tue, 26 Apr 2022 01:46:56 +0000 (21:46 -0400)]
c++: partial ordering with dependent NTTP type [PR105289]
Here ever since r11-6483-ge2e2f3f2c9400f we're rejecting and crashing
on (respectively) two testcases that we used to accept in C++17 mode
since r8-1437-g3da557ec145823. Both testcases declare a partial
specialization of a primary template that has an NTTP with dependent
type, and the validity of these partial specializations is unclear and
the subject of PR86193 / CWG 455.
So for now, this minimal patch just aims to fix the crash in the second
testcase. During deduction, when checking whether the type of an NTTP
uses still-undeduced parameters, we were incorrectly substituting into
the previously substituted type instead of into its original type.
In passing this patch also downgrades the "not more specialized"
diagnostic from a permerror to a pedwarn.
PR c++/105289
PR c++/86193
gcc/cp/ChangeLog:
* pt.c (process_partial_specialization): Downgrade "partial
specialization isn't more specialized" diagnostic from permerror
to an on-by-default pedwarn.
(unify) <case TEMPLATE_PARM_INDEX>: When substituting into the
NTTP type a second time, use the original type not the
substituted type.
gcc/testsuite/ChangeLog:
* g++.dg/template/partial-specialization11.C: New test.
* g++.dg/template/partial-specialization12.C: New test.
Tamar Christina [Thu, 28 Apr 2022 11:32:26 +0000 (12:32 +0100)]
testsuite: Backport testsuite changes from GCC 12 to GCC 11
This backports the testsuite changes from mainline to GCC 11.
This enables some tests that were not running and fix some
unresolved cases. The test output are adjusted to what GCC 11 could detect.
Marek Polacek [Tue, 26 Apr 2022 20:12:58 +0000 (16:12 -0400)]
c++: enum in generic lambda at global scope [PR105398]
We crash compiling this test since r11-7993 which changed
lookup_template_class_1 so that we only call tsubst_enum when
!uses_template_parms (current_nonlambda_scope ())
But here current_nonlambda_scope () is the global NAMESPACE_DECL ::, which
doesn't have a type, therefore is considered type-dependent. So we don't
call tsubst_enum, and crash in tsubst_copy/CONST_DECL because we didn't
find the e1 enumerator.
I don't think any namespace can depend on any template parameter, so
this patch tweaks uses_template_parms.
PR c++/105398
gcc/cp/ChangeLog:
* pt.c (uses_template_parms): Return false for any NAMESPACE_DECL.
libphobos: Don't call free on the TLS array in the emutls destroy function.
Fixes a segfault seen on Darwin when a GC scan is ran after a thread has
been destroyed. As the global emutlsArrays hash still has a reference
to the array itself, and tries to iterate all elements.
Setting the length to zero frees all allocated elements in the array,
and ensures that it is skipped when the _d_emutls_scan is called.
Thomas W Rodgers [Fri, 22 Apr 2022 22:46:19 +0000 (15:46 -0700)]
libstdc++: Make atomic notify_one and notify_all non-const
<recording this here for future reference>
PR102994 "atomics: std::atomic<ptr>::wait is not marked const" raises the
issue that the current libstdc++ implementation marks the notify members
const, the implementation strategy used by libstdc++, as well as libc++
and the Microsoft STL, do not require the atomic to be mutable (it is hard
to conceive of a desirable implementation approach that would require it).
The original paper proposing the wait/notify functionality for atomics
(p1185) also had these members marked const for the first three revisions,
but that was changed without explanation in r3 and subsequent revisions of
the paper.
After raising the issue to the authors of p1185 and the author of the
libc++ implementation, the consensus seems to be "meh, it's harmless" so
there seems little appetite for an LWG issue to revisit the subject.
This patch changes the libstdc++ implementation to be in agreement with
the standard by removing const from those notify_one/notify_all members.
libstdc++-v3/ChangeLog:
PR libstdc++/102994
* include/bits/atomic_base.h (atomic_flag::notify_one,
notify_all): Remove const qualification.
(__atomic_base::notify_one, notify_all): Likewise.
* include/std/atomic (atomic<bool>::notify_one, notify_all):
Likewise.
(atomic::notify_one, notify_all): Likewise.
(atomic<T*>::notify_one, notify_all): Likewise.
(atomic_notify_one, atomic_notify_all): Likewise.
* testsuite/29_atomics/atomic/wait_notify/102994.cc: Adjust test
to account for change in notify_one/notify_all signature.
which has a COMPOUND_EXPR, so we get to cxx_eval_constant_expression
<case COMPOUND_EXPR>. The problem here is that we call
7044 /* Check that the LHS is constant and then discard it. */
7045 cxx_eval_constant_expression (ctx, op0,
7046 true, non_constant_p, overflow_p,
7047 jump_target);
where lval is always true, so the PARM_DECL 'yes' is not evaluated into
its value.
Fixed by always passing false for 'lval' in cxx_eval_logical_expression;
there's no case where we actually expect an lvalue from a TRUTH_*.
PR c++/105321
gcc/cp/ChangeLog:
* constexpr.c (cxx_eval_logical_expression): Always pass false for lval
to cxx_eval_constant_expression.
Marek Polacek [Tue, 12 Apr 2022 21:30:30 +0000 (17:30 -0400)]
c++: ambiguous call not diagnosed after DR2352 [PR97296]
DR 2352 changed the definitions of reference-related (so that it uses
"similar type" instead of "same type") and of reference-compatible (use
a standard conversion sequence). That means that reference-related is
now more broad, which means that we will be binding more things directly.
The original patch for DR 2352 caused some problems, which were fixed in
r276251 by creating a "fake" ck_qual in direct_reference_binding, so
that in
void f(int *); // #1
void f(const int * const &); // #2
int *x;
int main()
{
f(x); // call #1
}
we call #1. The extra ck_qual in #2 causes compare_ics to select #1,
which is a better match for "int *" because then we don't have to do
a qualification conversion.
Let's turn to the problem in this PR. We have
void f(const int * const &); // #1
void f(const int *); // #2
int *x;
int main()
{
f(x);
}
We arrive in compare_ics to decide which one is better. The ICS for #1
looks like
ck_ref_bind <- ck_qual <- ck_identity
const int *const & const int *const int *
and the ICS for #2 is
ck_qual <- ck_rvalue <- ck_identity
const int * int * int *
We strip the reference and then comp_cv_qual_signature when comparing two
ck_quals sees that "const int *" is a proper subset of "const int *const"
and we return -1. But that's wrong; presumably the top-level "const"
should be ignored and the call should be ambiguous. This patch adjust
the type of the "fake" ck_qual so that this problem doesn't arise.
PR c++/97296
gcc/cp/ChangeLog:
* call.c (direct_reference_binding): strip_top_quals when creating
a ck_qual.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/ref-bind4.C: Add dg-error.
* g++.dg/cpp0x/ref-bind8.C: New test.
Jonathan Wakely [Thu, 2 Sep 2021 14:29:22 +0000 (15:29 +0100)]
libstdc++: Remove "no stronger" assertion in compare exchange [PR102177]
P0418R2 removed some preconditions from std::atomic::compare_exchange_*
but we still enforce them via __glibcxx_assert. This removes those
assertions.
Signed-off-by: Jonathan Wakely <jwakely@redhat.com>
libstdc++-v3/ChangeLog:
PR c++/102177
* include/bits/atomic_base.h (__is_valid_cmpexch_failure_order):
New function to check if a memory order is valid for the failure
case of compare exchange operations.
(__atomic_base<I>::compare_exchange_weak): Simplify assertions
by using __is_valid_cmpexch_failure_order.
(__atomic_base<I>::compare_exchange_strong): Likewise.
(__atomic_base<P*>::compare_exchange_weak): Likewise.
(__atomic_base<P*>::compare_exchange_strong): Likewise.
(__atomic_impl::compare_exchange_weak): Add assertion.
(__atomic_impl::compare_exchange_strong): Likewise.
* include/std/atomic (atomic::compare_exchange_weak): Likewise.
(atomic::compare_exchange_strong): Likewise.
Jonathan Wakely [Thu, 9 Dec 2021 22:22:42 +0000 (22:22 +0000)]
libstdc++: Fix ambiguous comparisons for iterators in C++20
Since r11-1571 (c++: Refinements to "more constrained") was changed in
the front end, the following comment from stl_iterator.h stopped being
true:
// These extra overloads are not needed in C++20, because the ones above
// are constrained with a requires-clause and so overload resolution will
// prefer them to greedy unconstrained function templates.
The requires-clause is no longer considered when comparing unrelated
function templates. That means that the constrained operator== specified
in the standard is no longer more constrained than the pathological
comparison operators defined in the testsuite_greedy_ops.h header. This
was causing several tests to FAIL in C++20 mode:
FAIL: 23_containers/deque/types/1.cc (test for excess errors)
FAIL: 23_containers/vector/types/1.cc (test for excess errors)
FAIL: 24_iterators/move_iterator/greedy_ops.cc (test for excess errors)
FAIL: 24_iterators/normal_iterator/greedy_ops.cc (test for excess errors)
FAIL: 24_iterators/reverse_iterator/greedy_ops.cc (test for excess errors)
The solution is to restore some of the non-standard comparison operators
that are more specialized than the greedy operators in the testsuite.
libstdc++-v3/ChangeLog:
* include/bits/stl_iterator.h (operator==, operator<=>): Define
overloads for homogeneous specializations of reverse_iterator,
__normal_iterator and move_iterator.
Jonathan Wakely [Fri, 26 Nov 2021 22:53:02 +0000 (22:53 +0000)]
libstdc++: Fix test that fails in C++20 mode
This test was written to verify that the LWG 3265 changes work. But
those changes were superseded by LWG 3435, and the test is now incorrect
according to the current draft. The assignment operator is now
constrained to also require convertibility, which makes the test fail.
Change the Iter type to be convertible from int*, but make it throw an
exception if that conversion is used. Change the test from compile-only
to run, so we verify that the exception isn't thrown.
libstdc++-v3/ChangeLog:
* testsuite/24_iterators/move_iterator/dr3265.cc: Fix test to
account for LWG 3435 resolution.
Fritz Reese [Tue, 19 Apr 2022 20:45:46 +0000 (16:45 -0400)]
fortran: Fix conv of UNION constructors [PR105310]
This fixes an ICE when a UNION is the (1+8*2^n)-th field in a DEC
STRUCTURE when compiled with -finit-derived -finit-local-zero.
The problem was CONSTRUCTOR_APPEND_ELT from within gfc_conv_union_initializer
modified the vector pointer, but the pointer was passed by-value,
so the old pointer from the caller (gfc_conv_structure) pointed to freed
memory.
PR fortran/105310
gcc/fortran/ChangeLog:
* trans-expr.c (gfc_conv_union_initializer): Pass vec* by reference.
Jonathan Wakely [Thu, 21 Apr 2022 10:26:49 +0000 (11:26 +0100)]
libstdc++: Remove bogus assertion in std::from_chars [PR105324]
I'm not sure what I was thinking when I added this assertion, maybe it
was supposed to be alignment == 1 (which is what the pmr::string actually
uses). The simplest fix is to just remove the assertion.
The assertion is no longer enabled by default on trunk, but it's still
there for the --enablke-libstdcxx-debug build, and is still wrong. The
fix is needed on the gcc-11 branch.
Jonathan Wakely [Fri, 30 Jul 2021 12:56:14 +0000 (13:56 +0100)]
libstdc++: Use secure_getenv for filesystem::temp_directory_path() [PR65018]
This adds a configure check for the GNU extension secure_getenv and then
uses it for looking up TMPDIR and similar variables.
Signed-off-by: Jonathan Wakely <jwakely@redhat.com>
libstdc++-v3/ChangeLog:
PR libstdc++/65018
* configure.ac: Check for secure_getenv.
* config.h.in: Regenerate.
* configure: Regenerate.
* src/filesystem/ops-common.h (get_temp_directory_from_env): New
helper function to obtain path from the environment.
* src/c++17/fs_ops.cc (fs::temp_directory_path): Use new helper.
* src/filesystem/ops.cc (fs::temp_directory_path): Likewise.
* testsuite/27_io/filesystem/operations/temp_directory_path.cc:
Print messages if test cannot be run.
* testsuite/experimental/filesystem/operations/temp_directory_path.cc:
Likewise. Fix incorrect condition. Use "TMP" to work with
Windows as well as POSIX.
Jonathan Wakely [Tue, 30 Nov 2021 22:04:49 +0000 (22:04 +0000)]
libstdc++: Ensure C++20 std::stringstream definitions use correct ABI
The definitions of the new C++20 members of std::stringstream etc are
missing when --with-default-libstdcxx-abi=gcc4-compatible is used,
because all the explicit instantiations in src/c++20/sstream-inst.cc are
skipped.
This ensures the contents of that file are compiled with the new ABI, so
the same set of symbols are exported regardless of which ABI is active
by default.
libstdc++-v3/ChangeLog:
* src/c++20/sstream-inst.cc (_GLIBCXX_USE_CXX11_ABI): Define to
select new ABI.
Jonathan Wakely [Wed, 17 Nov 2021 15:05:43 +0000 (15:05 +0000)]
libstdc++: Use std::construct_at in net::ip::address
Using placement-new isn't valid in constant expressions, so this
replaces it with std::construct_at (via the std::_Construct function
that is usable before C++20).
libstdc++-v3/ChangeLog:
* include/experimental/internet (address): Use std::_Construct
to initialize union members.
Jonathan Wakely [Wed, 22 Sep 2021 12:56:21 +0000 (13:56 +0100)]
libstdc++: Improvements to standard error category objects (part deux)
In r12-3860 the error categories in <system_error> were made final and
immortal, but I missed the categories for <future> and <ios>. This makes
the same changes to those.
libstdc++-v3/ChangeLog:
* src/c++11/cxx11-ios_failure.cc (io_error_category): Define
class and virtual functions as 'final'.
(io_category_instance): Use constinit union to make the object
immortal.
* src/c++11/future.cc (future_error_category): Define class and
virtual functions as 'final'.
(future_category_instance): Use constinit union.
Jonathan Wakely [Mon, 1 Nov 2021 11:32:39 +0000 (11:32 +0000)]
libstdc++: Reorder constraints on std::span::span(Range&&) constructor.
In PR libstdc++/103013 Tim Song pointed out that we could reorder the
constraints of this constructor. That's worth doing just to reduce the
work the compiler has to do during overload resolution, even if it isn't
needed to make the code in the PR work.
Jonathan Wakely [Tue, 30 Nov 2021 16:18:23 +0000 (16:18 +0000)]
libstdc++: Avoid unwanted allocations in filesystem::path
When using COW strings, accessing _M_pathname[0] and similar non-const
accessors can cause the string to "leak", meaning it reallocates itself
if it shares ownership with another string object.
This causes test failures for --enable-fully-dynamic-string builds:
/home/jwakely/src/gcc/libstdc++-v3/testsuite/experimental/filesystem/path/construct/90634.cc:62: void test01(): Assertion 'bytes_allocated == 0' failed.
FAIL: experimental/filesystem/path/construct/90634.cc execution test
This FAIL happens because the fully-dynamic move constructor results in
shared ownership, so for path(std::move(std::string("foo"))) the
_M_pathname member shares ownership with the temporary, and the
non-const accesses in _M_split_cmpts() cause a new copy of the string to
be allocated. This un-sharing is wasteful, and entirely unnecessary when
sharing ownership with an rvalue that is about to release its ownership
anyway. Even for lvalues, sharing ownership is not a problem and
reallocating a unique copy of the string is wasteful.
This removes non-const accesses of _M_pathname in the
path::_M_split_cmpts() members.
libstdc++-v3/ChangeLog:
* src/c++17/fs_path.cc (path::_M_split_cmpts()): Remove
micro-optimization for "/" path.
* src/filesystem/path.cc (path::_M_split_cmpts()): Only access
the contents of _M_pathname using const member functions.
The problem is that allocator_traits<allocator<void>>::construct(a, p)
now uses std::_Construct(p), which only does a static_cast<void*>(p) and
so fails if the pointer has cv-quals.
This changes std::_Construct (and the related std::_Construct_novalue)
to use a C-style cast to (void*) which matches the effects of the
"voidify" helper in the C++20 standard.
libstdc++-v3/ChangeLog:
* include/bits/stl_construct.h (_Construct, _Construct_novalue):
Also cast away cv-qualifiers when converting pointer to void.
* testsuite/20_util/allocator/void.cc: Test construct function
with cv-qualified types.
Jonathan Wakely [Wed, 5 Jan 2022 16:25:47 +0000 (16:25 +0000)]
libstdc++: Do not use std::isdigit in <charconv> [PR103911]
This avoids a potential race condition if std::setlocale is used
concurrently with std::from_chars.
libstdc++-v3/ChangeLog:
PR libstdc++/103911
* include/std/charconv (__from_chars_alpha_to_num): Return
char instead of unsigned char. Change invalid return value to
127 instead of using numeric trait.
(__from_chars_alnum): Fix comment. Do not use std::isdigit.
Change type of variable to char.
Jonathan Wakely [Wed, 26 Jan 2022 16:08:51 +0000 (16:08 +0000)]
libstdc++: Avoid overflow in ranges::advance(i, n, bound)
When (bound - i) or n is the most negative value of its type, the
negative of the value will overflow. Instead of abs(n) >= abs(bound - i)
use n >= (bound - i) when positive and n <= (bound - i) when negative.
The function has a precondition that they must have the same sign, so
this works correctly. The precondition check can be moved into the else
branch, and simplified.
The standard requires calling ranges::advance(i, bound) even if i==bound
is already true, which is technically observable, but that's pointless.
We can just return n in that case. Similarly, for i!=bound but n==0 we
are supposed to call ranges::advance(i, n), but that's pointless. An LWG
issue to allow omitting the pointless calls is expected to be filed.
libstdc++-v3/ChangeLog:
* include/bits/ranges_base.h (ranges::advance): Avoid signed
overflow. Do nothing if already equal to desired result.
* testsuite/24_iterators/range_operations/advance_overflow.cc:
New test.
Jonathan Wakely [Thu, 3 Mar 2022 22:20:32 +0000 (22:20 +0000)]
libstdc++: Fix test failure on AIX
This fixes a test failure due to a non-reserved name in an AIX system
header (included via <pthread.h>). That name clashes with one of the
names we check our own headers for, so skip checking that name on AIX.
libstdc++-v3/ChangeLog:
* testsuite/17_intro/names.cc (func): Undef on AIX.
Jonathan Wakely [Wed, 13 Apr 2022 13:09:33 +0000 (14:09 +0100)]
libstdc++: Use LTLIBICONV when linking libstdc++.so [PR93602]
This fixes missing libiconv symbols when libstdc++ is built on a system
that has libiconv installed. If the libiconv headers are found then
libstdc++ depends on libiconv_open etc instead of libc's iconv_open. But
without this fix libstdc++ is not linked to the libiconv library that
provides the definitions of those symbols.
As discussed in PR 93602 this changed means that libstdc++.so.6 might
have an rpath pointing to the location of the libiconv.so library. If
that is not desired, then GCC must be configured to link to a static
libiconv.a instead, using either --with-libiconv-type=static or an
in-tree build of libiconv.
This happens because operator new might be replaced with something that
writes to this->_M_negative_sign_size and so the basic_string::copy call
could use a non-zero size to write to a zero-length buffer.
The solution suggested by Richi is to cache the size in a local variable
so that the compiler knows it won't be changed between the allocation
and the copy.
libstdc++-v3/ChangeLog:
PR middle-end/104966
* include/bits/locale_facets_nonio.tcc
(__moneypunct_cache::_M_cache): Store string sizes in local
variable that doesn't escape.
Jakub Jelinek [Tue, 19 Apr 2022 16:58:59 +0000 (18:58 +0200)]
sparc: Preserve ORIGINAL_REGNO in epilogue_renumber [PR105257]
The following testcase ICEs, because the pic register is
(reg:DI 24 %i0 [109]) and is used in the delay slot of a return.
We invoke epilogue_renumber and that changes it to
(reg:DI 8 %o0) which no longer satisfies sparc_pic_register_p
predicate, so we don't recognize the insn anymore.
The following patch fixes that by preserving ORIGINAL_REGNO if
specified, so we get (reg:DI 8 %o0 [109]) instead.
2022-04-19 Jakub Jelinek <jakub@redhat.com>
PR target/105257
* config/sparc/sparc.c (epilogue_renumber): If ORIGINAL_REGNO,
use gen_raw_REG instead of gen_rtx_REG and copy over also
ORIGINAL_REGNO. Use return 0; instead of /* fallthrough */.
Jakub Jelinek [Thu, 21 Apr 2022 07:43:30 +0000 (09:43 +0200)]
emit-rtl: Fix -fcompare-debug bug with label references in debug insns [PR105203]
When we compute LABEL_NUSES from scratch, mark_all_labels doesn't call
mark_jump_label on DEBUG_INSNs:
if (NONDEBUG_INSN_P (insn))
mark_jump_label (PATTERN (insn), insn, 0);
and so doesn't increment LABEL_NUSES from references in DEBUG_INSNs.
But, when we call emit_copy_of_insn_after e.g. when duplicating some
DEBUG_INSNs, we call it even on those, which then results in LABEL_NUSES
differences and -fcompare-debug failures.
The following patch makes sure we don't call it on DEBUG_INSNs.
2022-04-21 Jakub Jelinek <jakub@redhat.com>
PR debug/105203
* emit-rtl.c (emit_copy_of_insn_after): Don't call mark_jump_label
on DEBUG_INSNs.
gcov-profile: Allow negative counts of indirect calls [PR105282]
TOPN metrics are histograms that contain overall count and per-bucket
count. Overall count can be negative when two profiles merge and some
of per-bucket metrics are disacarded.
Noticed as an ICE on python PGO build where gcc crashes as:
during IPA pass: modref
a.c:36:1: ICE: in stream_out_histogram_value, at value-prof.cc:340
36 | }
| ^
stream_out_histogram_value(output_block*, histogram_value_t*)
gcc/value-prof.c:340
gcc/ChangeLog:
PR gcov-profile/105282
* value-prof.c (stream_out_histogram_value): Allow negative counts
on HIST_TYPE_INDIR_CALL.
Matthias Kretz [Wed, 15 Dec 2021 08:45:06 +0000 (09:45 +0100)]
c++: don't ICE on NAMESPACE_DECL inside FUNCTION_DECL
Code like
void swap() {
namespace __variant = __detail::__variant;
...
}
create a NAMESPACE_DECL where the CP_DECL_CONTEXT is a FUNCTION_DECL.
DECL_TEMPLATE_INFO fails on NAMESPACE_DECL and therefore must be handled
first in the assertion.
Jakub Jelinek [Tue, 19 Apr 2022 16:27:41 +0000 (18:27 +0200)]
c++: Fix up CONSTRUCTOR_PLACEHOLDER_BOUNDARY handling [PR105256]
The CONSTRUCTOR_PLACEHOLDER_BOUNDARY bit is supposed to separate
PLACEHOLDER_EXPRs that should be replaced by one object or subobjects of it
(variable, TARGET_EXPR slot, ...) from other PLACEHOLDER_EXPRs that should
be replaced by different objects or subobjects.
The bit is set when finding PLACEHOLDER_EXPRs inside of a CONSTRUCTOR, not
looking into nested CONSTRUCTOR_PLACEHOLDER_BOUNDARY ctors, and we prevent
elision of TARGET_EXPRs (through TARGET_EXPR_NO_ELIDE) whose initializer
is a CONSTRUCTOR_PLACEHOLDER_BOUNDARY ctor. The following testcase ICEs
though, we don't replace the placeholders in there at all, because
CONSTRUCTOR_PLACEHOLDER_BOUNDARY isn't set on the TARGET_EXPR_INITIAL
ctor, but on a ctor nested in such a ctor. replace_placeholders should be
run on the whole TARGET_EXPR slot.
So, the following patch fixes it by moving the CONSTRUCTOR_PLACEHOLDER_BOUNDARY
bit from nested CONSTRUCTORs to the CONSTRUCTOR containing those (but only
if it is closely nested, if there is some other tree sandwiched in between,
it doesn't do it).
2022-04-19 Jakub Jelinek <jakub@redhat.com>
PR c++/105256
* typeck2.c (process_init_constructor_array,
process_init_constructor_record, process_init_constructor_union): Move
CONSTRUCTOR_PLACEHOLDER_BOUNDARY flag from CONSTRUCTOR elements to the
containing CONSTRUCTOR.
That is, support for cris-linux-gnu was removed in gcc-11, but
install.texi wasn't adjusted accordingly. Also, unfortunately the
developer-related sites are gone with no replacements. And, CRIS is
used in other chip series as well, but allude rather than list.
The generated manpages, info, pdf and html were sanity-checked.
gcc:
* doc/install.texi <CRIS>: Remove references to removed websites and
adjust for cris-*-elf being the only remaining toolchain.
(cherry picked from commit d2a0a5d4ad23f1974c72ef8abaa55c1707c0b27f)
git://gcc.gnu.org / gcc.git / log