Marek Polacek [Sat, 4 Dec 2021 17:07:41 +0000 (12:07 -0500)]
c++: Fix for decltype and bit-fields [PR95009]
Here, decltype deduces the wrong type for certain expressions involving
bit-fields. Unlike in C, in C++ bit-field width is explicitly not part
of the type, so I think decltype should never deduce to 'int:N'. The
problem isn't that we're not calling unlowered_expr_type--we are--it's
that is_bitfield_expr_with_lowered_type only handles certain codes, but
not others. For example, += works fine but ++ does not.
This also fixes decltype-bitfield2.C where we were crashing (!), but
unfortunately it does not fix 84516 or 70733 where the problem is likely
a missing call to unlowered_expr_type. It occurs to me now that typeof
likely has had the same issue, but this patch should fix that too.
Harald Anlauf [Sat, 27 Nov 2021 20:43:52 +0000 (21:43 +0100)]
Fortran: improve expansion of constant array expressions within constructors
gcc/fortran/ChangeLog:
PR fortran/102787
* array.c (expand_constructor): When encountering a constant array
expression or array section within a constructor, simplify it to
enable better expansion.
Harald Anlauf [Fri, 26 Nov 2021 20:00:35 +0000 (21:00 +0100)]
Fortran: improve check of arguments to the RESHAPE intrinsic
gcc/fortran/ChangeLog:
PR fortran/103411
* check.c (gfc_check_reshape): Improve check of size of source
array for the RESHAPE intrinsic against the given shape when pad
is not given, and shape is a parameter. Try other simplifications
of shape.
gcc/testsuite/ChangeLog:
PR fortran/103411
* gfortran.dg/pr68153.f90: Adjust test to improved check.
* gfortran.dg/reshape_7.f90: Likewise.
* gfortran.dg/reshape_9.f90: New test.
Harald Anlauf [Thu, 2 Dec 2021 21:33:49 +0000 (22:33 +0100)]
Fortran: improve checking of array specifications
gcc/fortran/ChangeLog:
PR fortran/103505
* array.c (match_array_element_spec): Try to simplify array
element specifications to improve early checking.
* expr.c (gfc_try_simplify_expr): New. Try simplification of an
expression via gfc_simplify_expr. When an error occurs, roll
back.
* gfortran.h (gfc_try_simplify_expr): Declare it.
gcc/testsuite/ChangeLog:
PR fortran/103505
* gfortran.dg/pr103505.f90: New test.
Jakub Jelinek [Sat, 4 Dec 2021 10:00:09 +0000 (11:00 +0100)]
libcpp: Fix up handling of deferred pragmas [PR102432]
The https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557903.html
change broke the following testcases. The problem is when a pragma
namespace allows expansion (i.e. p->is_nspace && p->allow_expansion),
e.g. the omp or acc namespaces do, then when parsing the second pragma
token we do it with pfile->state.in_directive set,
pfile->state.prevent_expansion clear and pfile->state.in_deferred_pragma
clear (the last one because we don't know yet if it will be a deferred
pragma or not). If the pragma line only contains a single name
and newline after it, and there exists a function-like macro with the
same name, the preprocessor needs to peek in funlike_invocation_p
the next token whether it isn't ( but in this case it will see a newline.
As pfile->state.in_directive is set, we don't read anything after the
newline, pfile->buffer->need_line is set and CPP_EOF is lexed, which
funlike_invocation_p doesn't push back. Because name is a function-like
macro and on the pragma line there is no ( after the name, it isn't
expanded, and control flow returns to do_pragma. If name is valid
deferred pragma, we set pfile->state.in_deferred_pragma (and really
need it set so that e.g. end_directive later on doesn't eat all the
tokens from the pragma line).
Before Nathan's change (which unfortunately didn't contain rationale
on why it is better to do it like that), this wasn't a problem,
next _cpp_lex_direct called when we want next token would return
CPP_PRAGMA_EOF when it saw buffer->need_line, which would turn off
pfile->state.in_deferred_pragma and following get token would already
read the next line. But Nathan's patch replaced it with an assertion
failure that now triggers and CPP_PRAGMA_EOL is done only when lexing
the '\n'. Except for this special case that works fine, but in
this case it doesn't because when peeking the token we still didn't know
that it will be a deferred pragma.
I've tried to fix that up in do_pragma by detecting this and pushing
CPP_PRAGMA_EOL as lookahead, but that doesn't work because end_directive
still needs to see pfile->state.in_deferred_pragma set.
So, this patch affectively reverts part of Nathan's change, CPP_PRAGMA_EOL
addition isn't done only when parsing the '\n', but is now done in both
places, in the first one instead of the assertion failure.
2021-12-04 Jakub Jelinek <jakub@redhat.com>
PR preprocessor/102432
* lex.c (_cpp_lex_direct): If buffer->need_line while
pfile->state.in_deferred_pragma, return CPP_PRAGMA_EOL token instead
of assertion failure.
* c-c++-common/gomp/pr102432.c: New test.
* c-c++-common/goacc/pr102432.c: New test.
Iain Buclaw [Thu, 2 Dec 2021 00:53:51 +0000 (01:53 +0100)]
libphobos: Push all callee-save registers on the stack before GC scan on ARM
This is the library fix for PR103520 that also prevents the garbage
collector from releasing live memory. However this requires that the
host compiler has been patched with this fix, so the GC will remain
disabled in the D front-end for now until enough time has passed for
this to have trickled down into enough releases.
libphobos/ChangeLog:
* libdruntime/core/thread/osthread.d (callWithStackShell): Push all
callee-save registers on the stack for AArch64 and ARM.
which is a REFERENCE_REF_P and we evaluate its operand to 3, so we end
up with *3 and that fails. Sounds like we need to get rid of the
REFERENCE_REF_P then. That is what tsubst_copy_and_build/INDIRECT_REF
will do:
if (REFERENCE_REF_P (t))
{
/* A type conversion to reference type will be enclosed in
such an indirect ref, but the substitution of the cast
will have also added such an indirect ref. */
r = convert_from_reference (r);
}
so I think it's reasonable to call instantiate_non_dependent_expr_sfinae.
The transposition nolto -> notlo is confusing and it makes the long
name even harder to read than it already is - I kept reading it as
"not lo" until I realized it was a simple typo.
Fixes: 5269b24605b1 (Silence warning in LTO mode on VxWorks)
lto-plugin/
* lto-plugin.c: Fix -linker-output-auto-notlo-rel ->
-linker-output-auto-nolto-rel typo.
(process_option): Adjust accordingly, accepting both old and
new spelling.
gcc/
* config/vxworks.h (LTO_PLUGIN_SPEC): Adapt to corrected
spelling of -linker-output-auto-nolto-rel.
Martin Jambor [Wed, 1 Dec 2021 13:13:35 +0000 (14:13 +0100)]
ipa-sra: Check also ECF_LOOPING_CONST_OR_PURE when evaluating calls
in PR 103267 Honza found out that IPA-SRA does not look at
ECF_LOOPING_CONST_OR_PURE when evaluating if a call can have side
effects. Fixed with this patch. The testcase infinitely loops in a
const function, so it would not make a good addition to the testsuite.
gcc/ChangeLog:
2021-11-29 Martin Jambor <mjambor@suse.cz>
PR ipa/103267
* ipa-sra.c (scan_function): Also check ECF_LOOPING_CONST_OR_PURE flag.
Jakub Jelinek [Wed, 1 Dec 2021 09:16:57 +0000 (10:16 +0100)]
simplify-rtx: Punt on simplify_associative_operation with large operands [PR102356]
Seems simplify_associate_operation is quadratic, which isn't a big deal
for use during combine and other similar RTL passes, because those never
try to combine expressions from more than a few instructions and because
those instructions need to be recognized the machine description also bounds
how many expressions can appear in there.
var-tracking has depth limits only for some cases and unlimited depth
for the vt_expand_loc though:
/* This is the value used during expansion of locations. We want it
to be unbounded, so that variables expanded deep in a recursion
nest are fully evaluated, so that their values are cached
correctly. We avoid recursion cycles through other means, and we
don't unshare RTL, so excess complexity is not a problem. */
#define EXPR_DEPTH (INT_MAX)
/* We use this to keep too-complex expressions from being emitted as
location notes, and then to debug information. Users can trade
compile time for ridiculously complex expressions, although they're
seldom useful, and they may often have to be discarded as not
representable anyway. */
#define EXPR_USE_DEPTH (param_max_vartrack_expr_depth)
IMO for very large expressions it isn't worth trying to reassociate though,
in fact e.g. for the new testcase below keeping it as is has bigger chance
of generating smaller debug info which the dwarf2out.c part of the change
tries to achieve - if a binary operation has the same operands, we can
use DW_OP_dup and not bother computing the possibly large operand again.
The patch fixes it by adding a counter to simplify_context and counting
how many times simplify_associative_operation has been called during
a single outermost simplify_* call, and once it reaches some maximum
(currently 64), it stops reassociating.
Another possibility to deal with the power expressions in debug info
would be to introduce some new RTL operation for the pow{,i} (x, n)
case, allow that solely in debug insns and expand those into DWARF
using a loop. But that seems like quite a lot of work for something rarely
used (especially when powi for larger n is only useful for 0 and 1 inputs
because anything else overflows).
2021-12-01 Jakub Jelinek <jakub@redhat.com>
PR rtl-optimization/102356
* rtl.h (simplify_context): Add assoc_count member and
max_assoc_count static member.
* simplify-rtx.c (simplify_associative_operation): Don't reassociate
more than max_assoc_count times within one outermost simplify_* call.
Eric Botcazou [Tue, 30 Nov 2021 09:17:09 +0000 (10:17 +0100)]
Fix -freorder-blocks-and-partition glitch with Windows SEH (continued)
This fixes a thinko in the fix for the -freorder-blocks-and-partition
glitch with SEH on 64-bit Windows:
https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565208.html
Even if no exceptions are active, e.g. in C, we need to consider calls.
gcc/
PR target/103274
* config/i386/i386.c (ix86_output_call_insn): Beef up comment about
nops emitted with SEH.
* config/i386/winnt.c (i386_pe_seh_unwind_emit): When switching to
the cold section, emit a nop before the directive if the previous
active instruction is a call.
Peter Bergner [Tue, 16 Nov 2021 18:14:22 +0000 (12:14 -0600)]
rs6000: MMA test case emits wrong code when building a vector pair [PR102976]
PR102976 shows a test case where we generate wrong code when building
a vector pair from 2 vector registers. The bug here is that with unlucky
register assignments, we can clobber one of the input operands before
we write both registers of the output operand. The solution is to use
early-clobbers in the assemble pair and accumulator patterns.
Jakub Jelinek [Sat, 27 Nov 2021 12:00:55 +0000 (13:00 +0100)]
bswap: Fix UB in find_bswap_or_nop_finalize [PR103435]
On gcc.c-torture/execute/pr103376.c in the following code we trigger UB
in the compiler. n->range is 8 because it is 64-bit load and rsize is 0
because it is a bswap sequence with load and known to be 0:
/* Find real size of result (highest non-zero byte). */
if (n->base_addr)
for (tmpn = n->n, rsize = 0; tmpn; tmpn >>= BITS_PER_MARKER, rsize++);
else
rsize = n->range;
The shifts then shift uint64_t by 64 bits. For this case mask is 0
and we want both *cmpxchg and *cmpnop as 0, the operation can be done as
both nop and bswap and callers will prefer nop.
2021-11-27 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/103435
* gimple-ssa-store-merging.c (find_bswap_or_nop_finalize): Avoid UB if
n->range - rsize == 8, just clear both *cmpnop and *cmpxchg in that
case.
Jakub Jelinek [Wed, 24 Nov 2021 09:30:32 +0000 (10:30 +0100)]
openmp: Fix up handling of kind(host) and kind(nohost) in ACCEL_COMPILERs [PR103384]
As the testcase shows, we weren't handling kind(host) and kind(nohost) properly
in the ACCEL_COMPILERs, the code written in there is valid for the host
compiler only, where if we are maybe offloaded, we defer resolution after IPA,
otherwise return 0 for kind(nohost) and accept it for kind(host). Note,
omp_maybe_offloaded is false after IPA. If ACCEL_COMPILER is defined, it is
the other way around, but also we know we are after IPA.
2021-11-24 Jakub Jelinek <jakub@redhat.com>
PR middle-end/103384
gcc/
* omp-general.c (omp_context_selector_matches): For ACCEL_COMPILER,
return 0 for kind(host) and continue for kind(nohost).
libgomp/
* testsuite/libgomp.c/declare-variant-2.c: New test.
Jakub Jelinek [Tue, 23 Nov 2021 09:30:02 +0000 (10:30 +0100)]
openmp: Fix up handling of reduction clauses on the loop construct [PR102431]
We were using unshare_expr and walk_tree_without_duplicate replacement
of the placeholder vars. The OMP_CLAUSE_REDUCTION_{INIT,MERGE} can contain
other trees that need to be duplicated though, e.g. BLOCKs referenced in
BIND_EXPR(s), or local VAR_DECLs. This patch uses the inliner code to copy
all of that. There is a slight complication that those local VAR_DECLs or
placeholders don't have DECL_CONTEXT set, they will get that only when
they are gimplified later on, so this patch sets DECL_CONTEXT for those
temporarily and resets it afterwards.
2021-11-23 Jakub Jelinek <jakub@redhat.com>
PR middle-end/102431
* gimplify.c (replace_reduction_placeholders): Remove.
(note_no_context_vars): New function.
(gimplify_omp_loop): For OMP_PARALLEL's BIND_EXPR create a new
BLOCK. Use copy_tree_body_r with walk_tree instead of unshare_expr
and replace_reduction_placeholders for duplication of
OMP_CLAUSE_REDUCTION_{INIT,MERGE} expressions. Ensure all mentioned
automatic vars have DECL_CONTEXT set to non-NULL before doing so
and reset it afterwards for those vars and their corresponding
vars.
* c-c++-common/gomp/pr102431.c: New test.
* g++.dg/gomp/pr102431.C: New test.
Jakub Jelinek [Sun, 21 Nov 2021 20:08:04 +0000 (21:08 +0100)]
fortran, debug: Fix up DW_AT_rank [PR103315]
For DW_AT_rank we were emitting
.uleb128 0x4 # DW_AT_rank
.byte 0x97 # DW_OP_push_object_address
.byte 0x23 # DW_OP_plus_uconst
.uleb128 0x1c
.byte 0x6 # DW_OP_deref
on 64-bit and
.uleb128 0x4 # DW_AT_rank
.byte 0x97 # DW_OP_push_object_address
.byte 0x23 # DW_OP_plus_uconst
.uleb128 0x10
.byte 0x6 # DW_OP_deref
on 32-bit. I think this is wrong, as dtype.rank field in the descriptor
has unsigned char type, not pointer type nor pointer sized integral.
E.g. if we have a
REAL :: a(..)
dummy argument, which is passed as a reference to the function descriptor,
we want to evaluate a->dtype.rank. The above DWARF expressions perform
*(uintptr_t *)(a + 0x1c)
and
*(uintptr_t *)(a + 0x10)
respectively. The following patch changes those to:
.uleb128 0x5 # DW_AT_rank
.byte 0x97 # DW_OP_push_object_address
.byte 0x23 # DW_OP_plus_uconst
.uleb128 0x1c
.byte 0x94 # DW_OP_deref_size
.byte 0x1
and
.uleb128 0x5 # DW_AT_rank
.byte 0x97 # DW_OP_push_object_address
.byte 0x23 # DW_OP_plus_uconst
.uleb128 0x10
.byte 0x94 # DW_OP_deref_size
.byte 0x1
which perform
*(unsigned char *)(a + 0x1c)
and
*(unsigned char *)(a + 0x10)
respectively.
2021-11-21 Jakub Jelinek <jakub@redhat.com>
PR debug/103315
* trans-types.c (gfc_get_array_descr_info): Use DW_OP_deref_size 1
instead of DW_OP_deref for DW_AT_rank.
Jakub Jelinek [Fri, 19 Nov 2021 09:05:01 +0000 (10:05 +0100)]
c++: Fix up -fstrong-eval-order handling of call arguments [PR70796]
For -fstrong-eval-order (default for C++17 and later) we make sure to
gimplify arguments in the right order, but as the following testcase
shows that is not enough.
The problem is that some lvalues can satisfy the is_gimple_val / fb_rvalue
predicate used by gimplify_arg for is_gimple_reg_type typed expressions,
or is_gimple_lvalue / fb_either used for other types.
E.g. in foo we have:
C::C (&p, ++i, ++i)
before gimplification where i is an automatic int variable and without this
patch gimplify that as:
i = i + 1;
i = i + 1;
C::C (&p, i, i);
which means that the ctor is called with the original i value incremented
by 2 in both arguments, while because the call is CALL_EXPR_ORDERED_ARGS
the first argument should be different. Similarly in qux we have:
B::B (&p, TARGET_EXPR <D.2274, *(const struct A &) A::operator++ (&i)>,
TARGET_EXPR <D.2275, *(const struct A &) A::operator++ (&i)>)
and gimplify it as:
_1 = A::operator++ (&i);
_2 = A::operator++ (&i);
B::B (&p, MEM[(const struct A &)_1], MEM[(const struct A &)_2]);
but because A::operator++ returns the passed in argument, again we have
the same value in both cases due to gimplify_arg doing:
/* Also strip a TARGET_EXPR that would force an extra copy. */
if (TREE_CODE (*arg_p) == TARGET_EXPR)
{
tree init = TARGET_EXPR_INITIAL (*arg_p);
if (init
&& !VOID_TYPE_P (TREE_TYPE (init)))
*arg_p = init;
}
which is perfectly fine optimization for calls with unordered arguments,
but breaks the ordered ones.
Lastly, in corge, we have before gimplification:
D::foo (NON_LVALUE_EXPR <p>, 3, ++p)
and gimplify it as
p = p + 4;
D::foo (p, 3, p);
which is again wrong, because the this argument isn't before the
side-effects but after it.
The following patch adds cp_gimplify_arg wrapper, which if ordered
and is_gimple_reg_type forces non-SSA_NAME is_gimple_variable
result into a temporary, and if ordered, not is_gimple_reg_type
and argument is TARGET_EXPR bypasses the gimplify_arg optimization.
So, in foo with this patch we gimplify it as:
i = i + 1;
i.0_1 = i;
i = i + 1;
C::C (&p, i.0_1, i);
in qux as:
_1 = A::operator++ (&i);
D.2312 = MEM[(const struct A &)_1];
_2 = A::operator++ (&i);
B::B (&p, D.2312, MEM[(const struct A &)_2]);
where D.2312 is a temporary and in corge as:
p.9_1 = p;
p = p + 4;
D::foo (p.9_1, 3, p);
The is_gimple_reg_type forcing into a temporary should be really cheap
(I think even at -O0 it should be optimized if there is no modification in
between), the aggregate copies might be more expensive but I think e.g. SRA
or FRE should be able to deal with those if there are no intervening
changes. But still, the patch tries to avoid those when it is cheaply
provable that nothing bad happens (if no argument following it in the
strong evaluation order doesn't have TREE_SIDE_EFFECTS, then even VAR_DECLs
etc. shouldn't be modified after it). There is also an optimization to
avoid doing that for this or for arguments with reference types as nothing
can modify the parameter values during evaluation of other argument's
side-effects.
I've tried if e.g.
int i = 1;
return i << ++i;
doesn't suffer from this problem as well, but it doesn't, the FE uses
SAVE_EXPR <i>, SAVE_EXPR <i> << ++i;
in that case which gimplifies the way we want (temporary in the first
operand).
2021-11-19 Jakub Jelinek <jakub@redhat.com>
PR c++/70796
* cp-gimplify.c (cp_gimplify_arg): New function.
(cp_gimplify_expr): Use cp_gimplify_arg instead of gimplify_arg,
pass true as last argument to it if there are any following
arguments in strong evaluation order with side-effects.
Jakub Jelinek [Wed, 17 Nov 2021 16:31:40 +0000 (17:31 +0100)]
libcpp: Fix up handling of block comments in -fdirectives-only mode [PR103130]
Normal preprocessing, -fdirectives-only preprocessing before the Nathan's
rewrite, and all other compilers I've tried on godbolt treat even \*/
as end of a block comment, but the new -fdirectives-only handling doesn't.
2021-11-17 Jakub Jelinek <jakub@redhat.com>
PR preprocessor/103130
* lex.c (cpp_directive_only_process): Treat even \*/ as end of block
comment.
Jakub Jelinek [Wed, 17 Nov 2021 13:18:42 +0000 (14:18 +0100)]
lim: Reset flow sensitive info even for pointers [PR103192]
Since 2014 is lim clearing SSA_NAME_RANGE_INFO for integral SSA_NAMEs
if moving them from conditional contexts inside of a loop into unconditional
before the loop, but as the miscompilation of gimplify.c shows, we need to
treat pointers the same, even for them we need to reset whether the pointer
can/can't be null or the recorded pointer alignment.
This fixes
-FAIL: libgomp.c/../libgomp.c-c++-common/target-in-reduction-2.c (internal compiler error)
-FAIL: libgomp.c/../libgomp.c-c++-common/target-in-reduction-2.c (test for excess errors)
-UNRESOLVED: libgomp.c/../libgomp.c-c++-common/target-in-reduction-2.c compilation failed to produce executable
-FAIL: libgomp.c++/../libgomp.c-c++-common/target-in-reduction-2.c (internal compiler error)
-FAIL: libgomp.c++/../libgomp.c-c++-common/target-in-reduction-2.c (test for excess errors)
-UNRESOLVED: libgomp.c++/../libgomp.c-c++-common/target-in-reduction-2.c compilation failed to produce executable
-FAIL: libgomp.c++/target-in-reduction-2.C (internal compiler error)
-FAIL: libgomp.c++/target-in-reduction-2.C (test for excess errors)
-UNRESOLVED: libgomp.c++/target-in-reduction-2.C compilation failed to produce executable
on both x86_64 and i686.
2021-11-17 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/103192
* tree-ssa-loop-im.c (move_computations_worker): Use
reset_flow_sensitive_info instead of manually clearing
SSA_NAME_RANGE_INFO and do it for all SSA_NAMEs, not just ones
with integral types.
Jakub Jelinek [Wed, 17 Nov 2021 12:45:53 +0000 (13:45 +0100)]
ranger: Fix up fold_using_range::range_of_address [PR103255]
If on &base->member the offset isn't constant or isn't zero and
-fdelete-null-pointer-checks and not -fwrapv-pointer and base has a range
that doesn't include NULL, we return the range of the base.
Usually it isn't a big deal, because for most pointers we just use
varying, range_zero and range_nonzero ranges and nothing beyond that,
but if a pointer is initialized from a constant, we actually track the
exact range and in that case this causes miscompilation.
As discussed on IRC, I think doing something like:
offset_int off2;
if (off_cst && off.is_constant (&off2))
{
tree cst = wide_int_to_tree (sizetype, off2 / BITS_PER_UNIT);
// adjust range r with POINTER_PLUS_EXPR cst
if (!range_includes_zero_p (&r))
return true;
}
// Fallback
r = range_nonzero (TREE_TYPE (gimple_assign_rhs1 (stmt)));
return true;
could work, given that most of the pointer ranges are just the simple ones
perhaps it is too much for little benefit.
2021-11-17 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/103255
* gimple-range.cc (fold_using_range::range_of_address): Return
range_nonzero rather than unadjusted base's range. Formatting fixes.
Jakub Jelinek [Thu, 11 Nov 2021 09:14:04 +0000 (10:14 +0100)]
dwarf2out: Fix up field_byte_offset [PR101378]
For PCC_BITFIELD_TYPE_MATTERS field_byte_offset has quite large code
to deal with it since many years ago (see it e.g. in GCC 3.2, although it
used to be on HOST_WIDE_INTs, then on double_ints, now on offset_ints).
But that code apparently isn't able to cope with members with empty class
types with [[no_unique_address]] attribute, because the empty classes have
non-zero type size but zero decl size and so one can end up from the
computation with negative offset or offset 1 byte smaller than it should be.
For !PCC_BITFIELD_TYPE_MATTERS, we just use
tree_result = byte_position (decl);
which seems exactly right even for the empty classes or anything which is
not a bitfield (and for which we don't add DW_AT_bit_offset attribute).
So, instead of trying to handle those no_unique_address members in the
current already very complicated code, this limits it to bitfields.
stor-layout.c PCC_BITFIELD_TYPE_MATTERS handling also affects only
bitfields, twice it checks DECL_BIT_FIELD and once DECL_BIT_FIELD_TYPE.
As discussed, this patch uses DECL_BIT_FIELD_TYPE check, because
DECL_BIT_FIELD might be cleared for some bitfields with bitsizes
multiple of BITS_PER_UNIT and e.g.
struct S { int e; int a : 1, b : 7, c : 8, d : 16; } s;
struct T { int a : 1, b : 7; long long c : 8; int d : 16; } t;
int
main ()
{
s.c = 0x55;
s.d = 0xaaaa;
t.c = 0x55;
t.d = 0xaaaa;
s.e++;
}
has different debug info with DECL_BIT_FIELD check.
2021-11-11 Jakub Jelinek <jakub@redhat.com>
PR debug/101378
* dwarf2out.c (field_byte_offset): Do the PCC_BITFIELD_TYPE_MATTERS
handling only for DECL_BIT_FIELD_TYPE decls.
Jakub Jelinek [Fri, 5 Nov 2021 15:39:14 +0000 (16:39 +0100)]
x86: Make stringop_algs::stringop_strategy ctor constexpr [PR100246]
> Several older compilers fail to build modern GCC because of missing
> or incomplete C++11 support.
>
> * config/i386/i386.h (struct stringop_algs): Define a CTOR for
> this type.
Unfortunately, as mentioned in my
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583289.html
mail, without the new dyninit pass this causes dynamic initialization of
many variables, 6.5KB _GLOBAL__sub_I_* on x86_64 and 12.5KB on i686.
The following patch makes the ctor constexpr so that already the FE
is able to statically initialize all those.
I have tested on godbolt a reduced testcase without a constructor,
with constructor and with constexpr constructor.
clang before 3.3 is unhappy about all the 3 cases, clang 3.3 and 3.4
is ok with ctor and ctor with constexpr and optimizes it into static
initialization, clang 3.5+ is ok with all 3 versions and optimizes,
gcc 4.8 and 5+ is ok with all 3 versions and no ctor and ctor with constexpr
is optimized, gcc 4.9 is unhappy about the no ctor case and happy with the
other two.
2021-11-05 Jakub Jelinek <jakub@redhat.com>
PR bootstrap/100246
* config/i386/i386.h
(stringop_algs::stringop_strategy::stringop_strategy): Make the ctor
constexpr.
Jakub Jelinek [Fri, 5 Nov 2021 09:20:10 +0000 (10:20 +0100)]
dwarf2out: Fix up CONST_WIDE_INT handling once more [PR103046]
My last change to CONST_WIDE_INT handling in add_const_value_attribute broke
handling of CONST_WIDE_INT constants like ((__uint128_t) 1 << 120).
wi::min_precision (w1, UNSIGNED) in that case 121, but wide_int::from
creates a wide_int that has 0 and 0xff00000000000000ULL in its elts and
precision 121. When we output that, we output both elements and thus emit
0, 0xff00000000000000 instead of the desired 0, 0x0100000000000000.
IMHO we should actually pass machine_mode to add_const_value_attribute from
callers, so that we know exactly what precision we want. Because
hypothetically, if say mode is OImode and the CONST_WIDE_INT value fits into
128 bits or 192 bits, we'd emit just those 128 or 192 bits but debug info
users would expect 256 bits.
On
typedef unsigned __int128 U;
int
main ()
{
U a = (U) 1 << 120;
U b = 0xffffffffffffffffULL;
U c = ((U) 0xffffffff00000000ULL) << 64;
return 0;
}
vanilla gcc incorrectly emits 0, 0xff00000000000000 for a,
0xffffffffffffffff alone (DW_FORM_data8) for b and 0, 0xffffffff00000000
for c. gcc with the previously posted PR103046 patch emits
0, 0x0100000000000000 for a, 0xffffffffffffffff alone for b and
0, 0xffffffff00000000 for c. And with this patch we emit
0, 0x0100000000000000 for a, 0xffffffffffffffff, 0 for b and
0, 0xffffffff00000000 for c.
So, the patch below certainly causes larger debug info (well, 128-bit
integers are pretty rare), but in this case the question is if it isn't
more correct, as debug info consumers generally will not know if they
should sign or zero extend the value in DW_AT_const_value.
The previous code assumes they will always zero extend it...
2021-11-05 Jakub Jelinek <jakub@redhat.com>
PR debug/103046
* dwarf2out.c (add_const_value_attribute): Add MODE argument, use it
in CONST_WIDE_INT handling. Adjust recursive calls.
(add_location_or_const_value_attribute): Pass DECL_MODE (decl) to
new add_const_value_attribute argument.
(tree_add_const_value_attribute): Pass TYPE_MODE (type) to new
add_const_value_attribute argument.
Jakub Jelinek [Thu, 21 Oct 2021 08:27:44 +0000 (10:27 +0200)]
openmp: For default(none) ignore variables created by ubsan_create_data [PR64888]
We weren't ignoring the ubsan variables created by c-ubsan.c before gimplification
(others are added later). One way to fix this would be to introduce further
UBSAN_ internal functions and lower it later (sanopt pass) like other ifns,
this patch instead recognizes those magic vars by name/name of type and DECL_ARTIFICIAL
and TYPE_ARTIFICIAL.
2021-10-21 Jakub Jelinek <jakub@redhat.com>
PR middle-end/64888
gcc/c-family/
* c-omp.c (c_omp_predefined_variable): Return true also for
ubsan_create_data created artificial variables.
gcc/testsuite/
* c-c++-common/ubsan/pr64888.c: New test.
Jakub Jelinek [Tue, 19 Oct 2021 07:24:57 +0000 (09:24 +0200)]
c++: Don't reject calls through PMF during constant evaluation [PR102786]
The following testcase incorrectly rejects the c initializer,
while in the s.*a case cxx_eval_* sees .__pfn reads etc.,
in the s.*&S::foo case get_member_function_from_ptrfunc creates
expressions which use INTEGER_CSTs with type of pointer to METHOD_TYPE.
And cxx_eval_constant_expression rejects any INTEGER_CSTs with pointer
type if they aren't 0.
Either we'd need to make sure we defer such folding till cp_fold but the
function and pfn_from_ptrmemfunc is used from lots of places, or
the following patch just tries to reject only non-zero INTEGER_CSTs
with pointer types if they don't point to METHOD_TYPE in the hope that
all such INTEGER_CSTs with POINTER_TYPE to METHOD_TYPE are result of
folding valid pointer-to-member function expressions.
I don't immediately see how one could create such INTEGER_CSTs otherwise,
cast of integers to PMF is rejected and would have the PMF RECORD_TYPE
anyway, etc.
2021-10-19 Jakub Jelinek <jakub@redhat.com>
PR c++/102786
* constexpr.c (cxx_eval_constant_expression): Don't reject
INTEGER_CSTs with type POINTER_TYPE to METHOD_TYPE.
Covers cases where functions that handle the extracted strings ignore
the explicit length. This isn't something that's known to happen in the
current front-end, but the self-hosted front-end has been observed to do
this in its conversions between D and C-style strings.
Jonathan Wakely [Thu, 25 Nov 2021 23:29:08 +0000 (23:29 +0000)]
libstdc++: Make std::pointer_traits SFINAE-friendly [PR96416]
This is a simplified version of r12-5532 for the release branches. It
still removes the problematic static_assert, but rather than making
std::pointer_traits completely empty when the element_type can't be
deduced, it just disables element_type and pointer_to. Additionally, the
pointer_to member is not completely absent when element_type is cv void,
it just has an unusable signature.
This is sufficient to avoid errors outside the immediate context when
trying to use std::to_address.
libstdc++-v3/ChangeLog:
PR libstdc++/96416
* include/bits/ptr_traits.h (pointer_traits): Remove
static_assert checking for valid element_type.
(pointer_traits::element_type, pointer_traits::pointer_to):
Do not define when element type cannot be deduced.
* testsuite/20_util/pointer_traits/lwg3545.cc: New test.
* testsuite/20_util/to_address/1_neg.cc: Adjust dg-error line.
* testsuite/20_util/to_address/lwg3545.cc: New test.
Martin Liska [Thu, 25 Nov 2021 13:41:50 +0000 (14:41 +0100)]
d: fix ASAN in option processing
Fixes:
==129444==ERROR: AddressSanitizer: global-buffer-overflow on address 0x00000666ca5c at pc 0x000000ef094b bp 0x7fffffff8180 sp 0x7fffffff8178
READ of size 4 at 0x00000666ca5c thread T0
#0 0xef094a in parse_optimize_options ../../gcc/d/d-attribs.cc:855
#1 0xef0d36 in d_handle_optimize_attribute ../../gcc/d/d-attribs.cc:916
#2 0xef107e in d_handle_optimize_attribute ../../gcc/d/d-attribs.cc:887
#3 0xff85b1 in decl_attributes(tree_node**, tree_node*, int, tree_node*) ../../gcc/attribs.c:829
#4 0xef2a91 in apply_user_attributes(Dsymbol*, tree_node*) ../../gcc/d/d-attribs.cc:427
#5 0xf7b7f3 in get_symbol_decl(Declaration*) ../../gcc/d/decl.cc:1346
#6 0xf87bc7 in get_symbol_decl(Declaration*) ../../gcc/d/decl.cc:967
#7 0xf87bc7 in DeclVisitor::visit(FuncDeclaration*) ../../gcc/d/decl.cc:808
#8 0xf83db5 in DeclVisitor::build_dsymbol(Dsymbol*) ../../gcc/d/decl.cc:146
for the following test-case: gcc/testsuite/gdc.dg/attr_optimize1.d.
gcc/d/ChangeLog:
* d-attribs.cc (parse_optimize_options): Check index before
accessing cl_options.
Jonathan Wakely [Wed, 24 Nov 2021 13:17:54 +0000 (13:17 +0000)]
libstdc++: Do not use memset in constexpr calls to ranges::fill_n [PR101608]
libstdc++-v3/ChangeLog:
PR libstdc++/101608
* include/bits/ranges_algobase.h (__fill_n_fn): Check for
constant evaluation before using memset.
* testsuite/25_algorithms/fill_n/constrained.cc: Check
byte-sized values as well.
Jonathan Wakely [Tue, 17 Aug 2021 14:06:22 +0000 (15:06 +0100)]
libstdc++: Fix vector<bool> printer tests to work in debug mode
This fixes a compilation error in debug mode, due to std::_Bit_reference
not being defined, because it's in namespace std::__cxx1998 instead. We
can refer to it as vector<bool>::reference instead, which always works.
That fixes some compilation errors in debug mode, but the tests fail at
run-time instead because the printers for vector<bool> helpers are only
registered for the std namespace, not std::__cxx1998. That is fixed by
using add_container to register the printers instead of add_version, as
the former registers them in the std and std::__cxx1998 namespaces.
Signed-off-by: Jonathan Wakely <jwakely@redhat.com>
libstdc++-v3/ChangeLog:
* python/libstdcxx/v6/printers.py (StdBitReferencePrinter): Use
'std::vector<bool>::reference' as type name, not _Bit_reference.
(build_libstdcxx_dictionary): Register printers for vector<bool>
types in debug mode too.
* testsuite/libstdc++-prettyprinters/simple.cc: Adjust expected
output for invalid _Bit_reference. Use vector<bool>::reference
instead of _Bit_reference.
* testsuite/libstdc++-prettyprinters/simple11.cc: Likewise.
Jonathan Wakely [Wed, 24 Nov 2021 11:41:01 +0000 (11:41 +0000)]
libstdc++: Replace hyphens in effective target keywords
An effective target like foo-bar-baz will match a target selector of
*-*-* and cause problems in the testsuite. Several libstdc++ et keywords
are of the form foo-bar, which could still be a problem for *-*
selectors.
Replace hyphens with underscores in the et keywords "debug-mode",
"cxx11-abi", etc.
libstdc++-v3/ChangeLog:
* testsuite/lib/libstdc++.exp: Rename effective target keywords
to avoid dashes in the name.
* testsuite/*: Update effective targe keywords.
Jan Hubicka [Sat, 20 Nov 2021 23:35:22 +0000 (00:35 +0100)]
Fix looping flag discovery in ipa-pure-const
The testcase shows situation where there is non-trivial cycle in the callgraph
involving a noreturn call. This cycle is important for const function discovery
but not important for pure. IPA pure const uses same strongly connected
components for both propagations which makes it to get suboptimal result
(does not detect the pure flag). However local pure const gets the situation
right becaue it processes functions in right order. This hits rarely
executed code in propagate_pure_const that merge results with previously
known state that has long standing bug in it that makes it to throw away
the looping flag.
Bootstrapped/regtested x86_64-linux.
gcc/ChangeLog:
2021-11-21 Jan Hubicka <hubicka@ucw.cz>
PR ipa/103052
* ipa-pure-const.c (propagate_pure_const): Fix merging of loping flag.
gcc/testsuite/ChangeLog:
2021-11-21 Jan Hubicka <hubicka@ucw.cz>
PR ipa/103052
* gcc.c-torture/execute/pr103052.c: New test.
Harald Anlauf [Tue, 23 Nov 2021 16:51:38 +0000 (17:51 +0100)]
Fortran: fix scalarization for intrinsic LEN_TRIM with present KIND argument
gcc/fortran/ChangeLog:
PR fortran/87711
PR fortran/87851
* trans-array.c (arg_evaluated_for_scalarization): Add LEN_TRIM to
list of intrinsics for which an optional KIND argument needs to be
removed before scalarization.
gcc/testsuite/ChangeLog:
PR fortran/87711
PR fortran/87851
* gfortran.dg/len_trim.f90: New test.
PR middle-end/103059: reload: Also accept ASHIFT with indexed addressing
Correct a `vax-netbsdelf' target regression ultimately caused by commit c605a8bf9270 ("VAX: Accept ASHIFT in address expressions") (needed for
LRA) and as of commit 4a960d548b7d ("Avoid invalid loop transformations
in jump threading registry.") causing a build error in libgcc:
.../libgcc/libgcov-driver.c: In function 'gcov_do_dump':
.../libgcc/libgcov-driver.c:686:1: error: insn does not satisfy its constraints:
686 | }
| ^
(insn 2051 2050 2052 185 (set (reg/f:SI 0 %r0 [555])
(plus:SI (ashift:SI (mem/c:SI (plus:SI (reg/f:SI 13 %fp)
(const_int -28 [0xffffffffffffffe4])) [40 %sfp+-28 S4 A32])
(const_int 3 [0x3]))
(plus:SI (reg/v/f:SI 9 %r9 [orig:176 fn_buffer ] [176])
(const_int 24 [0x18])))) ".../libgcc/libgcov-driver.c":172:40 614 {movaddrdi}
(nil))
during RTL pass: postreload
.../libgcc/libgcov-driver.c:686:1: internal compiler error: in extract_constrain_insn, at recog.c:2670
0x1122a5ff _fatal_insn(char const*, rtx_def const*, char const*, int, char const*)
.../gcc/rtl-error.c:108
0x1122a697 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
.../gcc/rtl-error.c:118
0x111b5f2f extract_constrain_insn(rtx_insn*)
.../gcc/recog.c:2670
0x11143eef reload_cse_simplify_operands
.../gcc/postreload.c:407
0x11142fdb reload_cse_simplify
.../gcc/postreload.c:132
0x11143533 reload_cse_regs_1
.../gcc/postreload.c:238
0x11142ce7 reload_cse_regs
.../gcc/postreload.c:66
0x1114af33 execute
.../gcc/postreload.c:2355
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
This is because reload does not recognize the ASHIFT form of scaled
indexed addressing that the offending commit enabled the backend to
produce, and as seen in the RTL above lets the pseudo holding the
index part become the original memory reference rather than reloading it
into a hard register.
Fix it then by adding said form to reload, removing the build failure
and numerous similar regressions throughout `vax-netbsdelf' test suites
run with the source as at right before the build regression.
Cf. <https://gcc.gnu.org/pipermail/gcc-patches/2021-March/567256.html>,
and commit 6b3034eaba83 ("lra: Canonicalize mult to shift in address
reloads").
gcc/
PR middle-end/103059
* reload.c (find_reloads_address_1): Also accept the ASHIFT form
of indexed addressing.
(find_reloads): Adjust accordingly.
Jonathan Wakely [Mon, 4 Oct 2021 22:14:30 +0000 (23:14 +0100)]
libstdc++: Simplify constraints for std::any construction
libstdc++-v3/ChangeLog:
* include/std/utility (__is_in_place_type_v): Define
variable template to detect in_place_type_t specializations.
(__is_in_place_type): Replace class template with alias
template using __is_in_place_type_v.
* include/std/any (any(T&&)): Check __is_in_place_type first and
avoid instantiating is_copy_constructible unnecessarily.
Jonathan Wakely [Tue, 9 Nov 2021 23:45:36 +0000 (23:45 +0000)]
libstdc++: Disable gthreads weak symbols for glibc 2.34 [PR103133]
Since Glibc 2.34 all pthreads symbols are defined directly in libc not
libpthread, and since Glibc 2.32 we have used __libc_single_threaded to
avoid unnecessary locking in single-threaded programs. This means there
is no reason to avoid linking to libpthread now, and so no reason to use
weak symbols defined in gthr-posix.h for all the pthread_xxx functions.
libstdc++-v3/ChangeLog:
PR libstdc++/100748
PR libstdc++/103133
* config/os/gnu-linux/os_defines.h (_GLIBCXX_GTHREAD_USE_WEAK):
Define for glibc 2.34 and later.
Jonathan Wakely [Tue, 9 Nov 2021 10:31:18 +0000 (10:31 +0000)]
libstdc++: Make spurious std::random_device FAIL less likely
It's possible that independent reads from /dev/random and /dev/urandom
could produce the same value by chance. Retry if that happens. The
chances of it happening twice are miniscule.
libstdc++-v3/ChangeLog:
* testsuite/26_numerics/random/random_device/cons/token.cc:
Retry if random devices produce the same value.
Jonathan Wakely [Wed, 13 Oct 2021 21:32:28 +0000 (22:32 +0100)]
libstdc++: Add missing constexpr to std::optional (P2231R1)
This implements the changes in P2231R1 which make std::optional fully
constexpr in C++20.
libstdc++-v3/ChangeLog:
* include/bits/stl_construct.h (_Construct): Use
std::construct_at when constant evaluated.
* include/std/optional (_Storage, _Optional_payload, optional):
Add constexpr as specified by P2231R1.
* include/std/version (__cpp_lib_optional): Update value for
C++20.
* testsuite/20_util/optional/requirements.cc: Check feature test
macro.
* testsuite/20_util/optional/constexpr/assign.cc: New test.
* testsuite/20_util/optional/constexpr/cons/conv.cc: New test.
* testsuite/20_util/optional/constexpr/modifiers.cc: New test.
* testsuite/20_util/optional/constexpr/swap.cc: New test.
* testsuite/20_util/optional/version.cc: New test.
Jonathan Wakely [Tue, 27 Jul 2021 13:50:28 +0000 (14:50 +0100)]
libstdc++: Simplify std::optional::value()
The structure of these functions likely dates from the time before G++
fully supported C++14 extended constexpr, so that the throw expression
had to be the operand of a conditional expression. That is not true now,
so we can use a more straightforward version of the code.
We can also simplify the declaration of __throw_bad_optional_access by
using the C++11-style [[noreturn]] attribute so that a separate
declaration isn't needed.
libstdc++-v3/ChangeLog:
* include/experimental/optional (__throw_bad_optional_access):
Replace GNU attribute with C++11 attribute.
(optional::value, optional::value_or): Use if statements
instead of conditional expressions.
* include/std/optional (__throw_bad_optional_access)
(optional::value, optional::value_or): Likewise.
Jonathan Wakely [Mon, 4 Oct 2021 14:22:00 +0000 (15:22 +0100)]
libstdc++: Support printing volatile pointers (P1147R1)
To avoid needing to export a new symbol from the library (for now) the
new member function uses __attribute__((always_inline)).
libstdc++-v3/ChangeLog:
* include/std/ostream (operator<<(const volatile void*)):
Add new overload, as per P1147R1.
* testsuite/27_io/basic_ostream/inserters_other/char/volatile_ptr.cc:
New test.
Jonathan Wakely [Wed, 22 Sep 2021 12:56:21 +0000 (13:56 +0100)]
libstdc++: Improvements to standard error category objects
This ensures that the objects returned by std::generic_category() and
std::system_category() are initialized before any code starts executing,
and are not destroyed at the end of the program. This means it is always
safe to access them, even during startup and termination. See LWG 2992
and P1195R0 for further discussion of this.
Additionally, make the types of those objects final, which might
potentially allow additional devirtualization opportunities. The types
are not visible to users, so there is no way they can derive from them,
so making them final has no semantic change.
Finally, add overrides for equivalent(int, const error_condition&) to
those types, to avoid the second virtual call that would be performed by
the base class definition of the function. Because we know what
default_error_condition(int) does for the derived type, we don't need to
make a virtual call.
Signed-off-by: Jonathan Wakely <jwakely@redhat.com>
libstdc++-v3/ChangeLog:
* src/c++11/system_error.cc (generic_error_category): Define
class and virtual functions as 'final'.
(generic_error_category::equivalent(int, const error_condition&)):
Override.
(system_error_category): Define class and virtual functions as
'final'.
(system_error_category::equivalent(int, const error_condition&)):
Override.
(generic_category_instance, system_category_instance): Use
constinit union to make the objects immortal.
Jonathan Wakely [Thu, 26 Aug 2021 23:20:31 +0000 (00:20 +0100)]
libstdc++: Name std::function template parameter
This avoids "<template-parameter-2-2>" being shown in the diagnostics
for ill-formed uses of std::function constructor:
In instantiation of 'std::function<_Res(_ArgTypes ...)>::function(_Functor&&)
[with _Functor = f(f()::_Z1fv.frame*)::<lambda()>;
<template-parameter-2-2> = void; _Res = void; _ArgTypes = {}]'
Instead we get:
In instantiation of 'std::function<_Res(_ArgTypes ...)>::function(_Functor&&)
[with _Functor = f(f()::_Z1fv.frame*)::<lambda()>;
_Constraints = void; _Res = void; _ArgTypes = {}]'
Signed-off-by: Jonathan Wakely <jwakely@redhat.com>
libstdc++-v3/ChangeLog:
* include/bits/std_function.h (function::function(F&&)): Give
name to defaulted template parameter, to improve diagnostics.
Use markdown for more doxygen comments.
Jonathan Wakely [Thu, 26 Aug 2021 13:01:36 +0000 (14:01 +0100)]
libstdc++: Avoid a move in std::function construction (LWG 2447)
This makes the std::function constructor use perfect forwarding, to
avoid an unnecessary move-construction of the target. This means we need
to rewrite the _Function_base::_Base_manager::_M_init_functor function
to use a forwarding reference, and so can reuse it for the clone
operation.
Also simplify the SFINAE constraints on the constructor, by combining
the !is_same_v<remove_cvref_t<F>, function> constraint into the
_Callable trait.
Signed-off-by: Jonathan Wakely <jwakely@redhat.com>
libstdc++-v3/ChangeLog:
* include/bits/std_function.h (_function_base::_Base_manager):
Replace _M_init_functor with a function template using a
forwarding reference, and a pair of _M_create function
templates. Reuse _M_create for the clone operation.
(function::_Decay_t): New alias template.
(function::_Callable): Simplify by using _Decay.
(function::function(F)): Change parameter to forwarding
reference, as per LWG 2447. Add noexcept-specifier. Simplify
constraints.
(function::operator=(F&&)): Add noexcept-specifier.
* testsuite/20_util/function/cons/lwg2774.cc: New test.
* testsuite/20_util/function/cons/noexcept.cc: New test.
Antony Polukhin [Tue, 17 Aug 2021 12:50:53 +0000 (13:50 +0100)]
libstdc++: Optimize std::seed_seq construction
When std::seed_seq is constructed from random access iterators we can
detect the internal vector size in O(1). Reserving memory for elements
in such cases may avoid multiple memory allocations.
Signed-off-by: Jonathan Wakely <jwakely@redhat.com>
libstdc++-v3/ChangeLog:
* include/bits/random.tcc (seed_seq::seed_seq): Reserve capacity
if distance is O(1).
* testsuite/26_numerics/random/pr60037-neg.cc: Adjust dg-error
line number.
Jonathan Wakely [Thu, 26 Aug 2021 12:13:27 +0000 (13:13 +0100)]
libstdc++: Add static assertions for std::function requirements
Add static assertions to std::function, so that more user-friendly
diagnostics are given when trying to store a non-copyable target object.
These preconditions were added as "Mandates:" by LWG 2447, but I'm
committing them separately from implementing that, to allow just this
change to be backported more easily.
Signed-off-by: Jonathan Wakely <jwakely@redhat.com>
libstdc++-v3/ChangeLog:
* include/bits/std_function.h (function::function(F)): Add
static assertions to check constructibility requirements.
Jonathan Wakely [Thu, 22 Jul 2021 10:57:38 +0000 (11:57 +0100)]
libstdc++: Initialize all subobjects of std::function
The std::function::swap member swaps each data member unconditionally,
resulting in -Wmaybe-uninitialized warnings for a default constructed
object. This happens because the _M_invoker and _M_functor members are
only initialized if the function has a target.
This change ensures that all subobjects are zero-initialized on
construction.
Signed-off-by: Jonathan Wakely <jwakely@redhat.com>
libstdc++-v3/ChangeLog:
* include/bits/std_function.h (_Function_base): Add
default member initializers and define constructor as defaulted.
(function::_M_invoker): Add default member initializer.
Tim Adye [Fri, 4 Jun 2021 14:59:38 +0000 (15:59 +0100)]
libstdc++: Optimize std::any_cast by replacing indirect call
This significantly improves the performance of std::any_cast, by
avoiding an indirect call to the _S_manage function through a function
pointer. Before we make that indirect call we've already established
that the contained value has the expected type, which means we also know
the manager type, and so can call one of its members directly.
We also know the precise type in the any::emplace functions, because
we've just constructed that type, so we can use the new member there
too. That doesn't seem to affect performance, but we might as well use
the new _S_access function anyway.
Signed-off-by: Tim Adye <Tim.Adye@cern.ch> Signed-off-by: Jonathan Wakely <jwakely@redhat.com>
libstdc++-v3/ChangeLog:
* include/std/any (any::_Manager::_S_access): New static
function to access the contained value.
(any::emplace, __any_caster): Use _S_access member of the
manager type.
Jonathan Wakely [Tue, 20 Apr 2021 15:16:13 +0000 (16:16 +0100)]
libstdc++: Do not allocate a zero-size vector<bool> [PR 100153]
The vector<bool>::shrink_to_fit() implementation will allocate new
storage even if the vector is empty. That then leads to the
end-of-storage pointer being non-null and equal to the _M_start._M_p
pointer, which means that _M_end_addr() has undefined behaviour.
The fix is to stop doing a useless zero-sized allocation in
shrink_to_fit(), so that _M_start._M_p and _M_end_of_storage are both
null after an empty vector shrinks.
Signed-off-by: Jonathan Wakely <jwakely@redhat.com>
libstdc++-v3/ChangeLog:
PR libstdc++/100153
* include/bits/vector.tcc (vector<bool>::_M_shrink_to_fit()):
When size() is zero just deallocate and reset.
The previous message told you something was wrong, but not why it
happened or why it's bad. This changes it to explain that the function
is being misused.
Signed-off-by: Jonathan Wakely <jwakely@redhat.com>
libstdc++-v3/ChangeLog:
* include/bits/move.h (forward(remove_reference_t<T>&&)):
Improve text of static_assert.
* testsuite/20_util/forward/c_neg.cc: Adjust dg-error.
* testsuite/20_util/forward/f_neg.cc: Likewise.
Jonathan Wakely [Fri, 5 Nov 2021 11:25:27 +0000 (11:25 +0000)]
libstdc++: Add xfail to pretty printer tests that fail in C++20
For some reason the type printer for std::string doesn't work in C++20
mode, so std::basic_string<char, char_traits<char>, allocator<char> is
printed out in full rather than being shown as std::string. It's
probably related to the fact that the extern template declarations are
disabled for C++20, but I don't know why that affects GDB.
For now I'm just marking the relevant tests as XFAIL. That requires
adding support for target selectors to individual GDB directives such as
note-test and whatis-regexp-test.
libstdc++-v3/ChangeLog:
* testsuite/lib/gdb-test.exp: Add target selector support to the
dg-final directives.
* testsuite/libstdc++-prettyprinters/80276.cc: Add xfail for
C++20.
* testsuite/libstdc++-prettyprinters/libfundts.cc: Likewise.
* testsuite/libstdc++-prettyprinters/prettyprinters.exp: Tweak
comment.
Jonathan Wakely [Wed, 10 Nov 2021 11:43:46 +0000 (11:43 +0000)]
libstdc++: Fix test for libstdc++ not including <unistd.h> [PR100117]
The <cxxx> headers for the C library are not under our control, so we
can't prevent them from including <unistd.h>. Change the PR 49745 test
to only include the C++ library headers, not the <cxxx> ones.
To ensure <bits/stdc++.h> isn't included automatically we need to use
no_pch to disable PCH.
libstdc++-v3/ChangeLog:
PR libstdc++/100117
* testsuite/17_intro/headers/c++1998/49745.cc: Explicitly list
all C++ headers instead of including <bits/stdc++.h>
Jonathan Wakely [Thu, 21 Jul 2016 19:38:51 +0000 (20:38 +0100)]
libstdc++: Fix out-of-bound array accesses in testsuite
I fixed some undefined behaviour in string tests in r238609, but I only
fixed the narrow char versions. This applies the same fixes to the
wchar_t ones. These problems were found when testing a patch to make
std::basic_string usable in constexpr.
libstdc++-v3/ChangeLog:
* testsuite/21_strings/basic_string/modifiers/append/wchar_t/1.cc:
Fix reads past the end of strings.
* testsuite/21_strings/basic_string/operations/compare/wchar_t/1.cc:
Likewise.
* testsuite/experimental/string_view/operations/compare/wchar_t/1.cc:
Likewise.
Martin Liska [Wed, 24 Nov 2021 09:15:34 +0000 (10:15 +0100)]
jit: Initialize function::m_blocks in ctor
This resolves the problem reported here:
https://mail.gnu.org/archive/html/bug-gnu-emacs/2021-11/msg00606.html
https://bugzilla.opensuse.org/show_bug.cgi?id=1192951
Jonathan Wakely [Thu, 4 Nov 2021 22:50:02 +0000 (22:50 +0000)]
libstdc++: Fix pretty printing of std::unique_ptr [PR103086]
Since std::tuple started using [[no_unique_address]] the tuple<T*, D>
member of std::unique_ptr<T, D> has two _M_head_impl subobjects, in
different base classes. That means this printer code is ambiguous:
In older versions of GDB it happened to work by chance, because GDB
returned the last _M_head_impl member and std::tuple's base classes are
stored in reverse order, so the last one was the T* element of the
tuple. Since GDB 11 it returns the first _M_head_impl, which is the
deleter element.
The fix is for the printer to stop using an ambiguous field name and
cast the tuple to the correct base class before accessing the
_M_head_impl member.
Instead of fixing this in both UniquePointerPrinter and StdPathPrinter a
new unique_ptr_get function is defined to do it correctly. That is
defined in terms of new tuple_get and _tuple_impl_get functions.
It would be possible to reuse _tuple_impl_get to access each element in
StdTuplePrinter._iterator.__next__, but that already does the correct
casting, and wouldn't be much simpler anyway.
libstdc++-v3/ChangeLog:
PR libstdc++/103086
* python/libstdcxx/v6/printers.py (_tuple_impl_get): New helper
for accessing the tuple element stored in a _Tuple_impl node.
(tuple_get): New function for accessing a tuple element.
(unique_ptr_get): New function for accessing a unique_ptr.
(UniquePointerPrinter, StdPathPrinter): Use unique_ptr_get.
* python/libstdcxx/v6/xmethods.py (UniquePtrGetWorker): Cast
tuple to its base class before accessing _M_head_impl.
Jonathan Wakely [Tue, 16 Nov 2021 21:03:21 +0000 (21:03 +0000)]
libstdc++: Fix std::type_info::before for ARM [PR103240]
The r179236 fix for std::type_info::operator== should also have been
applied to std::type_info::before. Otherwise two distinct types can
compare equivalent due to using a string comparison, when they should do
a pointer comparison.
libstdc++-v3/ChangeLog:
PR libstdc++/103240
* libsupc++/tinfo2.cc (type_info::before): Use unadjusted name
to check for the '*' prefix.
* testsuite/util/testsuite_shared.cc: Add type_info object for
use in new test.
* testsuite/18_support/type_info/103240.cc: New test.
Jonathan Wakely [Tue, 23 Nov 2021 12:28:22 +0000 (12:28 +0000)]
libstdc++: Fix circular dependency for bitmap_allocator [PR103381]
<ext/bitmap_allocator.h> includes <function>, and since C++17 that
includes <unordered_map>. If std::allocator is defined in terms of
__gnu_cxx::bitmap_allocator then you get a circular reference and
bootstrap fails when compiling src/c++17/*.cc.
libstdc++-v3/ChangeLog:
PR libstdc++/103381
* include/ext/bitmap_allocator.h: Include <bits/stl_function.h>
instead of <functional>.
Jonathan Wakely [Thu, 22 Jul 2021 13:37:24 +0000 (14:37 +0100)]
libstdc++: Use std::addressof in ranges::uninitialized_xxx [PR101571]
Make the ranges::uninitialized_xxx algorithms use std::addressof to
protect against iterator types that overload operator&.
Signed-off-by: Jonathan Wakely <jwakely@redhat.com>
libstdc++-v3/ChangeLog:
PR libstdc++/101571
* include/bits/ranges_uninitialized.h (_DestroyGuard): Change
constructor parameter to reference and use addressof.
* testsuite/util/testsuite_iterators.h: Define deleted operator&
overloads for test iterators.
git://gcc.gnu.org / gcc.git / log