This adds more guards to the VEC_PERM_EXPR scan, namely that
we also could end up with load-lanes and of course no vectorization
at all. Need dependent scans (scan-if-scan-X PASSed ...).
2021-01-21 Richard Biener <rguenther@suse.de>
PR testsuite/97299
* gcc.dg/vect/slp-reduc-3.c: Amend target selectors.
If SRC had been assigned a mode narrower than the copy, we can't
always link DEST into the chain even they have same
hard_regno_nregs(i.e. HImode/SImode in i386 backend).
i.e
kmovw %k0, %edi
vmovd %edi, %xmm2
vpshuflw $0, %xmm2, %xmm0
kmovw %k0, %r8d
kmovd %k0, %r9d
...
- movl %r9d, %r11d
+ vmovd %xmm2, %r11d
gcc/ChangeLog:
PR rtl-optimization/98694
* regcprop.c (copy_value): If SRC had been assigned a mode
narrower than the copy, we can't link DEST into the chain even
they have same hard_regno_nregs(i.e. HImode/SImode in i386
backend).
gcc/testsuite/ChangeLog:
PR rtl-optimization/98694
* gcc.target/i386/pr98694.c: New test.
g++.dg/warn/Wstringop-overflow-6.C tests for a bogus overflow warning in
system headers. This testcase was generating a -Wchar-subscript warning
on AIX because ctype_inline.h was subscripting AIX _OBJ_DATA using a char.
The _M_table case cast the subscript to unsigned char, but the _OBJ_DATA
case did not.
The investigation also exposed that AIX has added a thread-safe variant
of access to __lc_type that had not been applied to the libstdc++
implementation.
This patch casts the subscript to unsigned char and adds the THREAD_SAFE
variant. libstdc++ always is compiled with pthreads, but it is good
to make the situation explicit and to document the appropriate usage.
Bootstrapped on powerpc-ibm-aix7.2.3.0.
libstdc++-v3/ChangeLog:
* config/os/aix/ctype_inline.h (bool ctype<char>:: is): Cast
_OBJ_DATA subscript to unsigned char. Add _THREAD_SAFE access to
__lc_type.
(const char* ctype<char>:: is): Same.
Adjust testcase to so the ADD that is expected to overflow cannot
be optimized.
gcc/testsuite
* gcc.dg/torture/ftrapv-2.c: Make overflow instruction unremovable.
On Wed, Jan 20, 2021 at 05:04:39PM +0100, Florian Weimer wrote:
> Sorry, this appears to cause OpenMP task state corruption in RPM. We
> have only seen this on s390x.
Haven't actually verified it, but my suspection is that this is a caller
stack corruption.
We play with fire with the GOMP_task API/ABI extensions, the GOMP_task
function used to be:
void
GOMP_task (void (*fn) (void *), void *data, void (*cpyfn) (void *, void *),
long arg_size, long arg_align, bool if_clause, unsigned flags);
and later:
void
GOMP_task (void (*fn) (void *), void *data, void (*cpyfn) (void *, void *),
long arg_size, long arg_align, bool if_clause, unsigned flags,
void **depend);
and later:
void
GOMP_task (void (*fn) (void *), void *data, void (*cpyfn) (void *, void *),
long arg_size, long arg_align, bool if_clause, unsigned flags,
void **depend, int priority);
and now:
void
GOMP_task (void (*fn) (void *), void *data, void (*cpyfn) (void *, void *),
long arg_size, long arg_align, bool if_clause, unsigned flags,
void **depend, int priority, void *detach)
and which of those depend, priority and detach argument is present depends
on the bits in flags.
I'm afraid the compiler just decided to spill the detach = NULL store in
if ((flags & GOMP_TASK_FLAG_DETACH) == 0)
detach = NULL;
on s390x into the argument stack slot. Not a problem if the caller passes
all those 10 arguments, but if not, can clobber random stack location.
This hack should fix it up. Priority doesn't need changing, but I've
changed it anyway just to be safe. With the patch none of the 3 arguments
are ever modified, so I'd hope gcc doesn't decide to spill something
unrelated there.
2021-01-20 Jakub Jelinek <jakub@redhat.com>
* task.c (GOMP_task): Rename priority argument to priority_arg,
add priority automatic variable and modify that variable. Instead of
clearing detach argument when GOMP_TASK_FLAG_DETACH bit is not set,
check flags for that bit.
I'd forgotten that left shifting a negative value is UB until C++20.
Insert some casts to do unsigned shifts.
PT c++/98625
gcc/cp/
* module.cc (bytes_in::i, bytes_in::wi): Avoid left shift of
signed type.
In certain intrinsics use cases GCC leaves SETs of a bottom-element vec
select lying around:
(vec_select:DI (reg:V2DI 34 v2 [orig:128 __o ] [128])
(parallel [
(const_int 0 [0])
])))
This can be treated as a simple move in aarch64 when done between SIMD
registers for all normal widths.
These go through the aarch64_get_lane pattern.
This patch adds a splitter there to simplify these extracts to a move
that can, perhaps, be optimised a way.
Another benefit is if the destination is memory we can use a simpler STR
instruction rather than ST1-lane.
gcc/
* config/aarch64/aarch64-simd.md (aarch64_get_lane<mode>):
Convert to define_insn_and_split. Split into simple move when moving
bottom element.
gcc/testsuite/
* gcc.target/aarch64/vdup_lane_2.c: Scan for fmov rather than
dup.
One of the advantages of LRA is that you can create new pseudos from it
just fine. The code in rs6000_emit_le_vsx_store was not aware of this.
This patch changes that, in the process fixing PR98549 (where it is
shown that we do call rs6000_emit_le_vsx_store during LRA, which we
used to assert can not happen).
2021-01-20 Segher Boessenkool <segher@kernel.crashing.org>
* config/rs6000/rs6000.c (rs6000_emit_le_vsx_store): Change assert.
Adjust comment. Simplify code.
As mentioned in the PR, with -gdwarf-5 (or -g now) -flto -ffat-lto-objects,
users can't strip the LTO sections with
strip -p -R .gnu.lto_* -R .gnu.debuglto_* -N __gnu_lto_v1
anymore when GCC is configured against recent binutils.
The problem is that in that case .gnu.debuglto_.debug_line_str section is
then used, which is fine for references to strings in .gnu.debuglto_.*
sections, but not when those references are in .debug_info section too;
those should really reference separate strings in .debug_line_str section.
For .gnu.debuglto_.debug_str vs. .debug_str we handle it right, we
reset_indirect_string the strings and thus force creation of new labels for
the second time.
But for DW_FORM_line_strp as the patch shows, there were multiple problems.
First one was that reset_indirect_string, even when called through traverse
on debug_line_str_hash, didn't do anything at all (fixed by first hunk).
The second bug was that the DW_FORM_line_strp strings, which were supposed
to be only visible through debug_line_str_hash, leaked into debug_str_hash
(second hunk).
And the third thing is that when we reset debug_line_str_hash, we should
still make those strings DW_FORM_line_strp if they are accessed.
One could do it by reinstantiating DW_FORM_line_strp right away in
reset_indirect_string and not clear debug_line_str_hash, but that has the
disadvantage that we then force emitting .debug_line_str strings that aren't
really needed - we need those from the CU DIEs' DW_AT_name and
DW_AT_comp_dir attributes, but when emitting .debug_line section through
assembler, we don't need to emit the strings we only needed for
.gnu.debuglto_.debug_line which is always emitted by the compiler.
2021-01-20 Jakub Jelinek <jakub@redhat.com>
PR debug/98765
* dwarf2out.c (reset_indirect_string): Also reset indirect strings
with DW_FORM_line_strp form.
(prune_unused_types_update_strings): Don't add into debug_str_hash
indirect strings with DW_FORM_line_strp form.
(adjust_name_comp_dir): New function.
(dwarf2out_finish): Call it on CU DIEs after resetting
debug_line_str_hash.
Patch cf2ac1c30a for solving PR97969 was
assumed for targets with absent 3-op add insn. But the original patch did
not check this. This patch adds the check.
gcc/ChangeLog:
PR rtl-optimization/98722
* lra-eliminations.c (eliminate_regs_in_insn): Check that target
has no 3-op add insn to transform insns containing two pluses.
gcc/testsuite/ChangeLog:
PR rtl-optimization/98722
* g++.target/s390/pr98722.C: New.
The following tries to handle overflow in the integer computations
done by lambda ops of dependence analysis by failing instead of
silently continuing with overflowed values.
It also avoids treating large unsigned CHREC_RIGHT as negative
unless the chrec is of pointer type and avoids the most negative
integer value to avoid excessive overflow checking (with this
the fix for PR98758 can be partly simplified as seen).
I've added add_hwi and mul_hwi functions computing HOST_WIDE_INT
signed sum and product with indicating overflow, they hopefully
get matched to the appropriate internal functions.
I don't have any testcases triggering overflow in any of the
guarded computations.
2021-01-20 Richard Biener <rguenther@suse.de>
* hwint.h (add_hwi): New function.
(mul_hwi): Likewise.
* tree-data-ref.c (initialize_matrix_A): Properly translate
tree constants and avoid HOST_WIDE_INT_MIN.
(lambda_matrix_row_add): Avoid undefined integer overflow
and return true on such overflow.
(lambda_matrix_right_hermite): Handle overflow from
lambda_matrix_row_add gracefully. Simplify previous fix.
(analyze_subscript_affine_affine): Likewise.
This patch adds patterns for optimizing
x < y || y == XXX_MIN to x <= y-1
x >= y && y != XXX_MIN to x > y-1
if y is an integer with TYPE_OVERFLOW_WRAPS.
This fixes pr96674.
Tested on x86_64-pc-linux-gnu.
For this function
bool f(unsigned a, unsigned b)
{
return (b == 0) | (a < b);
}
the code without the patch is
test esi,esi
sete al
cmp esi,edi
seta dl
or eax,edx
ret
the code with the patch is
sub esi,0x1
cmp esi,edi
setae al
ret
PR tree-optimization/96674
gcc/
* match.pd: New patterns: x < y || y == XXX_MIN --> x <= y - 1
x >= y && y != XXX_MIN --> x > y - 1
gcc/testsuite
* gcc.dg/pr96674.c: New tests.
Here, during partial instantiation of the generic lambda, we do
tsubst_copy on the CLASS_PLACEHOLDER_TEMPLATE for U{0} which yields a
(level-lowered) TEMPLATE_TEMPLATE_PARM rather than the corresponding
TEMPLATE_DECL. This later confuses do_class_deduction which expects
that a CLASS_PLACEHOLDER_TEMPLATE is always a TEMPLATE_DECL.
gcc/cp/ChangeLog:
PR c++/95434
* pt.c (tsubst) <case TEMPLATE_TYPE_PARM>: If tsubsting
CLASS_PLACEHOLDER_TEMPLATE yields a TEMPLATE_TEMPLATE_PARM,
adjust to its TEMPLATE_TEMPLATE_PARM_TEMPLATE_DECL.
gcc/testsuite/ChangeLog:
PR c++/95434
* g++.dg/cpp2a/lambda-generic9.C: New test.
When parsing the base-clause of a class declaration, we need to defer
access checking until the entire base-clause has been seen, so that
access can be properly checked relative to the scope of the class with
all its bases attached. This allows us to accept the declaration of
struct D from Example 2 of [class.access.general] (access12.C below).
Similarly when substituting into the base-clause of a class template,
which is the subject of PR82613.
gcc/cp/ChangeLog:
PR c++/82613
* parser.c (cp_parser_class_head): Defer access checking when
parsing the base-clause until all bases are seen and attached
to the class type.
* pt.c (instantiate_class_template): Likewise when substituting
into dependent bases.
gcc/testsuite/ChangeLog:
PR c++/82613
* g++.dg/parse/access12.C: New test.
* g++.dg/template/access35.C: New test.
duplicate_and_interleave is the main fallback way of loading
a repeating sequence of elements into variable-length vectors.
The code handles cases in which the number of elements in the
sequence is potentially several times greater than the number
of elements in a vector.
Let:
- NE be the (compile-time) number of elements in the sequence
- NR be the (compile-time) number of vector results and
- VE be the (run-time) number of elements in each vector
The basic approach is to duplicate each element into a
separate vector, giving NE vectors in total, then use
log2(NE) rows of NE permutes to generate NE results.
In the worst case — when VE has no known compile-time factor
and NR >= NE — all of these permutes are necessary. However,
if VE is known to be a multiple of 2**F, then each of the
first F permute rows produces duplicate results; specifically,
the high permute for a given pair is the same as the low permute.
The code dealt with this by reusing the low result for the
high result. This part was OK.
However, having duplicate results from one row meant that the
next row did duplicate work. The redundancies would be optimised
away by later passes, but the code tried to avoid generating them
in the first place. This is the part that went wrong.
Specifically, NR is typically less than NE when some permutes are
redundant, so the code tried to use NR to reduce the amount of work
performed. The problem was that, although it correctly calculated
a conservative bound on how many results were needed in each row,
it chose the wrong results for anything other than the final row.
This doesn't usually matter for fully-packed SVE vectors. We first
try to coalesce smaller elements into larger ones, so normally
VE ends up being 2**VQ (where VQ is the number of 128-bit blocks
in an SVE vector). In that situation we'd only apply the faulty
optimisation to the final row, i.e. the case it handled correctly.
E.g. for things like:
void
f (long *x)
{
for (int i = 0; i < 100; i += 8)
{
x[i] += 1;
x[i + 1] += 2;
x[i + 2] += 3;
x[i + 3] += 4;
x[i + 4] += 5;
x[i + 5] += 6;
x[i + 6] += 7;
x[i + 7] += 8;
}
}
(already tested by the testsuite), we'd have 3 rows of permutes
producing 4 vector results. The schemne produced:
1st row: 8 results from 4 permutes, highs duplicates of lows
2nd row: 8 results from 8 permutes (half of which are actually redundant)
3rd row: 4 results from 4 permutes
However, coalescing elements is trickier for unpacked vectors,
and at the moment we don't try to do it (see the GET_MODE_SIZE
check in can_duplicate_and_interleave_p). Unpacked vectors
therefore stress the code in ways that packed vectors didn't.
The patch fixes this by removing the redundancies from each row,
rather than trying to work around them later. This also removes
the redundant work in the second row of the example above.
gcc/
PR tree-optimization/98535
* tree-vect-slp.c (duplicate_and_interleave): Use quick_grow_cleared.
If the high and low permutes are the same, remove the high permutes
from the working set and only continue with the low ones.
The following patch fixes two bugs in the access_ref::inform_access function
(plus some formatting nits).
The first problem is that ref can be various things, e.g. *_DECL, or
SSA_NAME, or IDENTIFIER_NODE. And allocfn is non-NULL only if ref is
(at least originally) an SSA_NAME initialized to the result of some
allocator function (but not e.g. __builtin_alloca_with_align which is
handled differently).
A few lines above the last hunk of this patch in builtins.c, the code uses
if (mode == access_read_write || mode == access_write_only)
{
if (allocfn == NULL_TREE)
{
if (*offstr)
inform (loc, "at offset %s into destination object %qE of size %s",
offstr, ref, sizestr);
else
inform (loc, "destination object %qE of size %s", ref, sizestr);
return;
}
if (*offstr)
inform (loc,
"at offset %s into destination object of size %s "
"allocated by %qE", offstr, sizestr, allocfn);
else
inform (loc, "destination object of size %s allocated by %qE",
sizestr, allocfn);
return;
}
so if allocfn is NULL, it prints whatever ref is, if it is non-NULL,
it prints instead the allocation function. But strangely the hunk
a few lines below wasn't consistent with that and instead printed the
first form only if DECL_P (ref) and would ICE if ref wasn't a decl but
still allocfn was NULL. Fixed by making it consistent what the code does
earlier.
Another bug is that the code earlier contains an ugly hack for VLAs and was
assuming that SSA_NAME_IDENTIFIER must be non-NULL on the lhs of
__builtin_alloca_with_align. While that is likely true for the cases where
the compiler emits this builtin for VLAs (and it will also be true that
the name of the VLA in that case can be taken from that identifier up to the
first .), the builtin is user accessible as the testcase shows, so one can
have any other SSA_NAME in there. I think it would be better to add some
more reliable way how to identify VLA names corresponding to
__builtin_alloca_with_align allocations, perhaps internal fn or whatever,
but that is beyond the scope of this patch.
2021-01-20 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/98721
* builtins.c (access_ref::inform_access): Don't assume
SSA_NAME_IDENTIFIER must be non-NULL. Print messages about
object whenever allocfn is NULL, rather than only when DECL_P
is true. Use %qE instead of %qD for that. Formatting fixes.
* gcc.dg/pr98721-1.c: New test.
* gcc.dg/pr98721-2.c: New test.
This fixes some int arithmetic issues and a bogus truncation.
2021-01-20 Richard Biener <rguenther@suse.de>
PR tree-optimization/98758
* tree-data-ref.c (int_divides_p): Use lambda_int arguments.
(lambda_matrix_right_hermite): Avoid undefinedness with
signed integer abs and multiplication.
(analyze_subscript_affine_affine): Use lambda_int.
* gcc.dg/torture/pr98758.c: New testcase.
Similarly to how we handle erroneous operands to e.g. allocate clause,
this change just removes those clauses instead of accessing TYPE_MAIN_VARIANT
of its type, which doesn't work on error_mark_node. Also, just for good
measure, bails out if TYPE_NAME is NULL.
2021-01-20 Jakub Jelinek <jakub@redhat.com>
PR c++/98742
* semantics.c (finish_omp_clauses) <case OMP_CLAUSE_DETACH>: If
error_operand_p, remove clause without further checking. Check
for non-NULL TYPE_NAME.
* c-c++-common/gomp/task-detach-2.c: New test.
PR debug/98751 reports an issue in which most of libgccjit's tests
fails in DWARF 5 handling with
`.Ldebug_loc2' is already defined"
asm errors.
The bogus label is being emitted at the 3rd in-process iteration, at:
31673 ASM_OUTPUT_LABEL (asm_out_file, loc_section_label);
which on the initial iteration emits:
145 │ .Ldebug_loc0:
on the 2nd iteration:
145 │ .Ldebug_loc1:
and on the 3rd iteration:
145 │ .Ldebug_loc2:
which is a duplicate of a label emitted earlier:
138 │ .section .debug_loclists,"",@progbits
139 │ .long .Ldebug_loc3-.Ldebug_loc2
140 │ .Ldebug_loc2:
141 │ .value 0x5
142 │ .byte 0x8
143 │ .byte 0
144 │ .long 0
145 │ .Ldebug_loc2:
The issue seems to be that init_sections_and_labels creates the label
ASM_GENERATE_INTERNAL_LABEL (loc_section_label, DEBUG_LOC_SECTION_LABEL,
generation);
where "generation" is a static local to init_sections_and_labels that
increments, and thus eventually hits the duplicate value.
It appears that this value is intended to be either 0 or 1, but in
the libgccjit case the compilation code can be invoked an arbitrary
number of times in-process, and hence can eventually lead to a
label name collision.
This patch adds code to dwarf2out_c_finalize (called by
toplev::finalize in libgccjit) to reset the generation counts,
fixing the issue.
gcc/ChangeLog:
PR debug/98751
* dwarf2out.c (output_line_info): Rename static variable
"generation", moving it out of the function to...
(output_line_info_generation): New.
(init_sections_and_labels): Likewise, renaming the variable to...
(init_sections_and_labels_generation): New.
(dwarf2out_c_finalize): Reset the new variables.
This patch re-enables the DWARF5 tests that seem to be functioning again.
It adds a comment to pr41445-7.c that any changes in lines need to be
reflected in the expected output.
The patch also allows for additional failures in ucs.c and reflects that
builtin-sprintf-warn-20.c requires 4 byte wide char support.
gcc/testsuite/ChangeLog:
* gcc.dg/cpp/ucs.c: Expect Invalid warning for 2byte wchar.
* gcc.dg/debug/dwarf2/inline6.c: Remove skip AIX.
* gcc.dg/debug/dwarf2/lang-c11.c: Remove skip AIX.
* gcc.dg/debug/dwarf2/pr41445-7.c: Remove skip AIX.
* gcc.dg/debug/dwarf2/pr41445-8.c: Remove skip AIX.
* gcc.dg/tree-ssa/builtin-sprintf-warn-20.c: Require 4byte wchar.
maybe_instantiate_noexcept doesn't expect to see error_mark_node, but
the new callsite I introduced in r11-6476 can pass error_mark_node to
it. So cope.
gcc/cp/ChangeLog:
PR c++/98659
* pt.c (maybe_instantiate_noexcept): Return false if FN is
error_mark_node.
gcc/testsuite/ChangeLog:
PR c++/98659
* g++.dg/template/deduce8.C: New test.
My recent patch that introduced push_using_decl_bindings didn't
handle USING_DECL redeclaration, therefore things broke. This patch
amends that by breaking out a part of finish_nonmember_using_decl
out to a separate function, push_using_decl_bindings, and calling it.
It needs an overload, because name_lookup is only available inside
of name-lookup.c.
gcc/cp/ChangeLog:
PR c++/98687
* name-lookup.c (push_using_decl_bindings): New, broken out of...
(finish_nonmember_using_decl): ...here.
* name-lookup.h (push_using_decl_bindings): Update declaration.
* pt.c (tsubst_expr): Update the call to push_using_decl_bindings.
gcc/testsuite/ChangeLog:
PR c++/98687
* g++.dg/lookup/using64.C: New test.
* g++.dg/lookup/using65.C: New test.
gcc/ChangeLog:
PR middle-end/98664
* tree-ssa-live.c (remove_unused_scope_block_p): Keep scopes for
all functions, even if they're not declared artificial or inline.
* tree.c (tree_inlined_location): Use macro expansion location
only if scope traversal fails to expose one.
gcc/testsuite/ChangeLog:
PR middle-end/98664
* gcc.dg/Wvla-larger-than-4.c: Adjust expected output.
* gcc.dg/plugin/diagnostic-test-inlining-3.c: Same.
* g++.dg/warn/Wfree-nonheap-object-5.C: New test.
* gcc.dg/Wfree-nonheap-object-4.c: New test.
This patch removes a vestigial use of dk_no_check from
cp_parser_late_parsing_for_member, which ideally should have been
removed as part of the PR41437 patch that improved access checking
inside templates. This allows us to correctly reject f1 and f2 in
the testcase access34.C below (whereas before we'd only reject f3).
Additional testing revealed a new access issue when late-parsing a hidden
friend within a class template. In the testcase friend68.C below, we're
tripping over the checking assert from friend_accessible_p(f, S::j, S, S)
during lookup of j in x.j (for which type_dependent_object_expression_p
returns false, which is why we're doing the lookup at parse time). The
reason for the assert failure is that DECL_FRIENDLIST(S) contains f but
DECL_BEFRIENDING_CLASSES(f) is empty, and so friend_accessible_p (which
looks at DECL_BEFRIENDING_CLASSES) wants to return false, but is_friend
(which looks at DECL_FRIENDLIST) returns true.
For sake of symmetry one would expect that DECL_BEFRIENDING_CLASSES(f)
contains S, but add_friend avoids updating DECL_BEFRIENDING_CLASSES when
the class type (S in this case) is dependent, for some reason.
This patch works around this issue by making friend_accessible_p
consider the DECL_FRIEND_CONTEXT of the access scope. Thus we sidestep
the DECL_BEFRIENDING_CLASSES / DECL_FRIENDLIST asymmetry issue while
correctly validating the x.j access at parse time.
A earlier version of this patch checked friend_accessible_p instead of
protected_accessible_p in the DECL_FRIEND_CONTEXT hunk below, but this
had the side effect of making us accept the ill-formed testcase friend69.C
below (ill-formed because the hidden friend g is not actually a member
of A, so g doesn't have access to B's members despite B befriending A).
gcc/cp/ChangeLog:
PR c++/41437
PR c++/58993
* search.c (friend_accessible_p): If scope is a hidden friend
defined inside a dependent class, consider access from the
class.
* parser.c (cp_parser_late_parsing_for_member): Don't push a
dk_no_check access state.
gcc/testsuite/ChangeLog:
PR c++/41437
PR c++/58993
* g++.dg/opt/pr87974.C: Adjust.
* g++.dg/template/access34.C: New test.
* g++.dg/template/friend68.C: New test.
* g++.dg/template/friend69.C: New test.
Since certain members of a class are a complete-class context
[class.mem.general]p7, we delay their parsing untile the whole class has
been parsed. For instance, NSDMIs and noexcept-specifiers. The order
in which we perform this delayed parsing matters; we were first parsing
NSDMIs and only they did we parse noexcept-specifiers. That turns out
to be wrong: since NSDMIs may use noexcept-specifiers, we must process
noexcept-specifiers first. Otherwise we'll ICE in code that doesn't
expect to see DEFERRED_PARSE.
This doesn't just shift the problem, noexcept-specifiers can use members
with a NSDMI just fine, and I've also tested a similar test with this
member function:
bool f() { return __has_nothrow_constructor (S<true>); }
and that compiled fine too.
gcc/cp/ChangeLog:
PR c++/98333
* parser.c (cp_parser_class_specifier_1): Perform late-parsing
of NSDMIs before late-parsing of noexcept-specifiers.
gcc/testsuite/ChangeLog:
PR c++/98333
* g++.dg/cpp0x/noexcept62.C: New test.
There's no need for this function to have an object, so make it
static and avoid UB.
PR c++/98624
gcc/cp/
* module.cc (trees_out::write_location): Make static.
memrefs_conflict_p assumes that:
[XB + XO, XB + XO + XS)
does not alias
[YB + YO, YB + YO + YS)
whenever:
[XO, XO + XS)
does not intersect
[YO, YO + YS)
In other words, the accesses can alias only if XB == YB at runtime.
However, this doesn't cope correctly with section anchors.
For example, if XB is an anchor symbol and YB is at offset
XO from the anchor, then:
[XB + XO, XB + XO + XS)
overlaps
[YB, YB + YS)
whatever the value of XO is. In other words, when doing the
alias check for two symbols whose local definitions are in
the same block, we should apply the known difference between
their block offsets to the intersection test above.
gcc/
PR rtl-optimization/92294
* alias.c (compare_base_symbol_refs): Take an extra parameter
and add the distance between two symbols to it. Enshrine in
comments that -1 means "either 0 or 1, but we can't tell
which at compile time".
(memrefs_conflict_p): Update call accordingly.
(rtx_equal_for_memref_p): Likewise. Take the distance between symbols
into account.
Hi,
This is a follow-up fix to clean up pr91799. Per review of test results,
it appears that the combination of target and dg-require stanzas is
not sufficient to properly limit the test to 64-bit only on darwin.
This adds an additional dg-require clause to limit the test to 64-bit
environments.
Tested on power7 and power8 using assorted variations of
make -k check-gcc-c "RUNTESTFLAGS=powerpc.exp=pr88233.c
--target_board=unix/'{-mcpu=power7,-mcpu=power6,-mcpu=power8}''{-m32,-m64}'"
PR target/91799
2021-01-19 Will Schmidt <will_schmidt@vnet.ibm.com>
gcc/testsuite/ChangeLog:
* gcc.target/powerpc/pr88233.c: Update dg- stanzas.
The following avoids ICEing on a indirect calls with a fnspec
in modref analysis.
2021-01-19 Richard Biener <rguenther@suse.de>
PR ipa/98330
* ipa-modref.c (analyze_stmt): Only record a summary for a
direct call.
* g++.dg/pr98330.C: New testcase.
* gcc.dg/pr98330.c: Likewise.
Since SSA names do leak into global tree data structures like
TYPE_SIZE or in this case GFC_DECL_SAVED_DESCRIPTOR because of
frontend bugs we have to be careful to wipe references to the
CFG when we deconstruct SSA form because we now do ggc_free that.
2021-01-19 Richard Biener <rguenther@suse.de>
PR middle-end/98638
* tree-ssanames.c (fini_ssanames): Zero SSA_NAME_DEF_STMT.
Enable a define FIX_LEON3FT_TN0018 for the LEON3FT targets affected
by the GRLIB-TN-0018 errata described here:
https://www.gaisler.com/notes
gcc/
* config/sparc/rtemself.h (TARGET_OS_CPP_BUILTINS): Add
built-in define __FIX_LEON3FT_TN0018.
This fixes input_location leaking with an invalid BLOCK from
expand_call_inline to tree_function_versioning via clone
materialization.
2021-01-19 Richard Biener <rguenther@suse.de>
PR ipa/97673
* tree-inline.c (tree_function_versioning): Set input_location
to UNKNOWN_LOCATION throughout the function.
* gfortran.dg/pr97673.f90: New testcase.
IPA-SRA already contains a check to figure out that an otherwise dead
parameter is actually required because of non-call exceptions, but it
is not present at the equivalent spot where SRA figures out whether
the return statement is used for anything useful. This patch adds
that condition there.
Unfortunately, even though this patch should be good enough for any
normal (I'd even say reasonable) use of the compiler, it hints that
when the user manually switches all sorts of DCE, IPA-SRA would
probably leave behind problematic statements manipulating what
originally were return values, just like it does for parameters (PR
93385). Fixing this properly might unfortunately be a separate issue
from the mentioned bug because the LHS of a call is changed during
call redirection and the caller often is not a clone. But I'll see
what I can do.
Meanwhile, the patch below has been bootstrapped and tested on x86_64.
gcc/ChangeLog:
2021-01-18 Martin Jambor <mjambor@suse.cz>
PR ipa/98690
* ipa-sra.c (ssa_name_only_returned_p): New parameter fun. Check
whether non-call exceptions allow removal of a statement.
(isra_analyze_call): Pass the appropriate function to
ssa_name_only_returned_p.
gcc/testsuite/ChangeLog:
2021-01-18 Martin Jambor <mjambor@suse.cz>
PR ipa/98690
* g++.dg/ipa/pr98690.C: New test.
Think about this case:
./multilib-generator rv32imc-ilp32-rv32imac,rv32imacxthead-f
Here are 2 problems:
1. A unexpected 'xtheadf' extension was made.
2. The arch 'rv32imac' was not be created.
This modification fix these two, and also sorts 'multi-letter'.
gcc/ChangeLog:
* config/riscv/arch-canonicalize (longext_sort): New function for
sorting 'multi-letter'.
* config/riscv/multilib-generator: Adjusting the loop of 'alt' in
'alts'. The 'arch' may not be the first of 'alts'.
(_expand_combination): Add underline for the 'ext' without '*'.
This is because, a single-letter extension can always be treated well
with a '_' prefix, but it cannot be separated out if it is appended
to a multi-letter.
This change reads go:embed directives and attaches them to variables.
We still don't do anything with the directives.
This change also reads the file passed in the -fgo-embedcfg option.
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/281533
