Richard Biener [Thu, 1 Oct 2020 13:12:35 +0000 (15:12 +0200)]
tree-optimization/97236 - fix bad use of VMAT_CONTIGUOUS
This avoids using VMAT_CONTIGUOUS with single-element interleaving
when using V1mode vectors. Instead keep VMAT_ELEMENTWISE but
continue to avoid load-lanes and gathers.
2020-10-01 Richard Biener <rguenther@suse.de>
PR tree-optimization/97236
* tree-vect-stmts.c (get_group_load_store_type): Keep
VMAT_ELEMENTWISE for single-element vectors.
Nathan Sidwell [Thu, 1 Oct 2020 13:47:36 +0000 (06:47 -0700)]
c++: pushdecl_top_level must set context
I discovered pushdecl_top_level was not setting the decl's context,
and we ended up with namespace-scope decls with NULL context. That
broke modules. Then I discovered a couple of places where we set the
context to a FUNCTION_DECL, which is also wrong. AFAICT the literals
in question belong in global scope, as they're comdatable entities.
But create_temporary would use current_scope for the context before we
pushed it into namespace scope.
This patch asserts the context is NULL and then sets it to the frobbed
global_namespace.
Jan Hubicka [Thu, 1 Oct 2020 13:03:19 +0000 (15:03 +0200)]
Fix ICE in ipa_edge_args_sum_t::duplicate
PR ipa/97244
* ipa-fnsummary.c (pass_free_fnsummary::execute): Free
also indirect inlining datastructure.
* ipa-modref.c (pass_ipa_modref::execute): Do not free them here.
* ipa-prop.c (ipa_free_all_node_params): Do not crash when info does
not exist.
(ipa_unregister_cgraph_hooks): Likewise.
Nathan Sidwell [Thu, 1 Oct 2020 12:05:06 +0000 (05:05 -0700)]
c++: Refactor lookup_and_check_tag
It turns out I'd already found lookup_and_check_tag's control flow
confusing, and had refactored it on the modules branch. For instance,
it continually checks 'if (decl &&$ condition)' before finally getting
to 'else if (!decl)'. why not just check !decl first and be done?
Well, it is done thusly.
Tom de Vries [Thu, 1 Oct 2020 09:08:58 +0000 (11:08 +0200)]
[testsuite] Enable pr94600-{1,3}.c tests for nvptx
When compiling test-case pr94600-1.c for nvptx, this gimple mem move:
...
MEM[(volatile struct t0 *)655404B] ={v} a0[0];
...
is expanded into a memcpy, but when compiling pr94600-2.c instead, this similar
gimple mem move:
...
MEM[(volatile struct t0 *)655404B] ={v} a00;
...
is expanded into a 32-bit load/store pair.
In both cases, emit_block_move is called.
In the latter case, can_move_by_pieces (4 /* byte-size */, 32 /* bit-align */)
is called, which returns true (because by_pieces_ninsns returns 1, which is
smaller than the MOVE_RATIO of 4).
In the former case, can_move_by_pieces (4 /* byte-size */, 8 /* bit-align */)
is called, which returns false (because by_pieces_ninsns returns 4, which is
not smaller than the MOVE_RATIO of 4).
So the difference in code generation is explained by the alignment. The
difference in alignment comes from the move sources: a0[0] vs. a00. Both
have the same type with 8-bit alignment, but a00 is on stack, which based on
the base stack align and stack variable placement happens to result in a
32-bit alignment.
Enable test-cases pr94600-{1,3}.c for nvptx by forcing the currently 8-byte
aligned variables to have a 32-bit alignment for STRICT_ALIGNMENT targets.
Tested on nvptx.
gcc/testsuite/ChangeLog:
2020-10-01 Tom de Vries <tdevries@suse.de>
* gcc.dg/pr94600-1.c: Force 32-bit alignment for a0 for !non_strict_align
targets. Remove target clauses from scan tests.
* gcc.dg/pr94600-3.c: Same.
Jakub Jelinek [Thu, 1 Oct 2020 09:18:35 +0000 (11:18 +0200)]
c++: Fix up default initialization with consteval default ctor [PR96994]
> > The following testcase is miscompiled (in particular the a and i
> > initialization). The problem is that build_special_member_call due to
> > the immediate constructors (but not evaluated in constant expression mode)
> > doesn't create a CALL_EXPR, but returns a TARGET_EXPR with CONSTRUCTOR
> > as the initializer for it,
>
> That seems like the bug; at the end of build_over_call, after you
>
> > call = cxx_constant_value (call, obj_arg);
>
> You need to build an INIT_EXPR if obj_arg isn't a dummy.
That works. obj_arg is NULL if it is a dummy from the earlier code.
2020-10-01 Jakub Jelinek <jakub@redhat.com>
PR c++/96994
* call.c (build_over_call): If obj_arg is non-NULL, return INIT_EXPR
setting obj_arg to call.
Jakub Jelinek [Thu, 1 Oct 2020 09:16:44 +0000 (11:16 +0200)]
c++: Handle std::construct_at on automatic vars during constant evaluation [PR97195]
As mentioned in the PR, we only support due to a bug in constant expressions
std::construct_at on non-automatic variables, because we VERIFY_CONSTANT the
second argument of placement new, which fails verification if it is an
address of an automatic variable.
The following patch fixes it by not performing that verification, the
placement new evaluation later on will verify it after it is dereferenced.
2020-10-01 Jakub Jelinek <jakub@redhat.com>
PR c++/97195
* constexpr.c (cxx_eval_call_expression): Don't VERIFY_CONSTANT the
second argument.
Jakub Jelinek [Thu, 1 Oct 2020 09:04:56 +0000 (11:04 +0200)]
s390: Fix up s390_atomic_assign_expand_fenv
The following patch fixes
-FAIL: gcc.dg/pr94780.c (internal compiler error)
-FAIL: gcc.dg/pr94780.c (test for excess errors)
-FAIL: gcc.dg/pr94842.c (internal compiler error)
-FAIL: gcc.dg/pr94842.c (test for excess errors)
on s390x-linux. The fix is essentially the same as has been applied to many
other targets (i386, aarch64, arm, rs6000, alpha, riscv).
2020-10-01 Jakub Jelinek <jakub@redhat.com>
* config/s390/s390.c (s390_atomic_assign_expand_fenv): Use
TARGET_EXPR instead of MODIFY_EXPR for the first assignments to
fenv_var and old_fpc. Formatting fixes.
Richard Biener [Thu, 1 Oct 2020 07:29:32 +0000 (09:29 +0200)]
tree-optimization/97255 - missing vector bool pattern of SRAed bool
SRA tends to use VIEW_CONVERT_EXPR when replacing bool fields with
unsigned char fields. Those are not handled in vector bool pattern
detection causing vector true values to leak. The following fixes
this by turning those into b ? 1 : 0 as well.
2020-10-01 Richard Biener <rguenther@suse.de>
* tree-vect-patterns.c (vect_recog_bool_pattern): Also handle
VIEW_CONVERT_EXPR.
gcc/testsuite/:
PR target/97250
* gcc.target/i386/x86-64-v2.c: New test.
* gcc.target/i386/x86-64-v3.c: New test.
* gcc.target/i386/x86-64-v3-haswell.c: New test.
* gcc.target/i386/x86-64-v3-skylake.c: New test.
* gcc.target/i386/x86-64-v4.c: New test.
Alan Modra [Mon, 28 Sep 2020 07:12:33 +0000 (16:42 +0930)]
[RS6000] Adjust gcc asm for power10
Generate assembly with .localentry,1 functions using @notoc calls.
This patch makes libgcc.a asm look the same as power10 pcrel as far as
toc/notoc is concerned.
Otherwise calling between functions that advertise as using the TOC
and those that don't, will require linker call stubs in statically
linked code.
gcc/
* config/rs6000/ppc-asm.h: Support __PCREL__ code.
libgcc/
* config/rs6000/morestack.S,
* config/rs6000/tramp.S: Support __PCREL__ code.
libitm/
* config/powerpc/sjlj.S: Support __PCREL__ code.
Alan Modra [Mon, 28 Sep 2020 06:53:01 +0000 (16:23 +0930)]
[RS6000] -mno-minimal-toc vs. power10 pcrelative
We've had this hack in the libgcc config to build libgcc with
-mcmodel=small for powerpc64 for a long time. It wouldn't be a bad
thing if someone who knows the multilib machinery well could arrange
for -mcmodel=small to be passed just for ppc64 when building for
earlier than power10. But for now, make -mno-minimal-toc do nothing
when pcrel. Which will do the right thing for any project that has
copied libgcc's trick.
We want this if configuring using --with-cpu=power10 to build a
power10 pcrel libgcc. --mcmodel=small turns off pcrel.
gcc/
* config/rs6000/linux64.h (SUBSUBTARGET_OVERRIDE_OPTIONS): Don't
set -mcmodel=small for -mno-minimal-toc when pcrel.
libgcc/
* config/rs6000/t-linux: Document purpose of -mno-minimal-toc.
despite the 'explicit' deduction guide in a copy-list-initialization
context. That's because in deduction_guides_for we first find the
user-defined deduction guide (#2), and then ctor_deduction_guides_for
creates artificial deduction guides: one from the tuple(T) constructor and
a copy guide. So we end up with these three guides:
Then, in do_class_deduction, we prune this set, and get rid of (1).
Then overload resolution selects (3) and we succeed.
But [over.match.list]p1 says "In copy-list-initialization, if an explicit
constructor is chosen, the initialization is ill-formed." It also goes
on to say that this differs from other situations where only converting
constructors are considered for copy-initialization. Therefore for
list-initialization we consider explicit constructors and complain if one
is chosen. E.g. convert_like_internal/ck_user can give an error.
So my logic runs that we should not prune the deduction_guides_for guides
in a copy-list-initialization context, and only complain if we actually
choose an explicit deduction guide. This matches clang++/EDG/msvc++.
gcc/cp/ChangeLog:
PR c++/90210
* pt.c (do_class_deduction): Don't prune explicit deduction guides
in copy-list-initialization. In copy-list-initialization, if an
explicit deduction guide was selected, give an error.
gcc/testsuite/ChangeLog:
PR c++/90210
* g++.dg/cpp1z/class-deduction73.C: New test.
Jonathan Wakely [Wed, 30 Sep 2020 20:14:43 +0000 (21:14 +0100)]
libstdc++: Fix test_and_acquire / set_and_release for EABI guard variables
The default definitions of _GLIBCXX_GUARD_TEST_AND_ACQUIRE and
_GLIBCXX_GUARD_SET_AND_RELEASE in libsupc++/guard.cc only work for the
generic (IA64) ABI, because they test/set the first byte of the guard
variable. For EABI we need to use the least significant bit, which means
using the first byte is wrong for big endian targets.
This has been wrong since r224411, but previously it only caused poor
performance. The _GLIBCXX_GUARD_TEST_AND_ACQUIRE at the very start of
__cxa_guard_acquire would always return false even if the initialization
was actually complete. Before my r11-3484 change the atomic compare
exchange would have loaded the correct value, and then returned 0 as
expected when the initialization is complete. After my change, in the
single-threaded case there is no redundant check for init being
complete, because I foolishly assumed that the check at the start of the
function actually worked.
The default definition of _GLIBCXX_GUARD_SET_AND_RELEASE is also wrong
for big endian EABI, but appears to work because it sets the wrong bit
but then the buggy TEST_AND_ACQUIRE tests that wrong bit as well. Also,
the buggy SET_AND_RELEASE macro is only used for targets with threads
enabled but no futex syscalls.
This should fix the regressions introduced by my patch, by defining
custom versions of the TEST_AND_ACQUIRE and SET_AND_RELEASE macros that
are correct for EABI.
libstdc++-v3/ChangeLog:
* config/cpu/arm/cxxabi_tweaks.h (_GLIBCXX_GUARD_TEST_AND_ACQUIRE):
(_GLIBCXX_GUARD_SET_AND_RELEASE): Define for EABI.
Jonathan Wakely [Wed, 30 Sep 2020 17:24:48 +0000 (18:24 +0100)]
libstdc++: Use __is_same instead of __is_same_as
PR 92271 added __is_same as another spelling of __is_same_as. Since
Clang also spells it __is_same, let's just use that consistently.
It appears that Intel icc sets __GNUC__ to 10, but only supports
__is_same_as. If we only use __is_same for __GNUC__ >= 11 then we won't
break icc again (it looks like we broke previous versions of icc when we
started using __is_same_as).
libstdc++-v3/ChangeLog:
* include/bits/c++config (_GLIBCXX_HAVE_BUILTIN_IS_SAME):
Define for GCC 11 or when !__is_identifier(__is_same).
(_GLIBCXX_BUILTIN_IS_SAME_AS): Remove.
* include/std/type_traits (is_same, is_same_v): Replace uses
of _GLIBCXX_BUILTIN_IS_SAME_AS.
Jan Hubicka [Wed, 30 Sep 2020 16:00:42 +0000 (18:00 +0200)]
Fix some fnspec strings in trans-decl.c
* trans-decl.c (gfc_build_intrinsic_function_decls): Add traling dots
to spec strings so they match the number of parameters; do not use
R and W for non-pointer parameters. Drop pointless specifier on
caf_stop_numeric and caf_get_team.
arm: [testsuite] Skip thumb2-cond-cmp tests on Cortex-M [PR94595]
Since r204778 (g571880a0a4c512195aa7d41929ba6795190887b2), we favor
branches over IT blocks on Cortex-M. As a result, instead of
generating two nested IT blocks in thumb2-cond-cmp-[1234].c, we
generate either a single IT block, or use branches depending on
conditions tested by the program.
Since this was a deliberate change and the tests still pass as
expected on Cortex-A, this patch skips them when targetting
Cortex-M. The avoids the failures on Cortex M3, M4, and M33. This
patch makes the testcases unsupported on Cortex-M7 although they pass
in this case because this CPU has different branch costs.
I tried to relax the scan-assembler directives using eg. cmpne|subne
or cmpgt|ble but that seemed fragile.
Richard Biener [Wed, 30 Sep 2020 14:12:20 +0000 (16:12 +0200)]
amend SLP reduction testcases
This amends SLP reduction testcases that currently trigger
vect_attempt_slp_rearrange_stmts eliding load permutations to
verify this is actually happening.
Joel Hutton [Wed, 30 Sep 2020 14:08:13 +0000 (15:08 +0100)]
[SLP][VECT] Add check to fix 96837
The following patch adds a simple check to prevent slp stmts from
vector constructors being rearranged. vect_attempt_slp_rearrange_stmts
tries to rearrange to avoid a load permutation.
This fixes PR target/96837
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96827
gcc/ChangeLog:
2020-09-29 Joel Hutton <joel.hutton@arm.com>
PR target/96837
* tree-vect-slp.c (vect_analyze_slp): Do not call
vect_attempt_slp_rearrange_stmts for vector constructors.
gcc/testsuite/ChangeLog:
2020-09-29 Joel Hutton <joel.hutton@arm.com>
PR target/96837
* gcc.dg/vect/bb-slp-49.c: New test.
Tamar Christina [Wed, 30 Sep 2020 13:46:16 +0000 (14:46 +0100)]
middle-end: Refactor refcnt to use SLP_TREE_REF_COUNT for consistency
This is a small refactoring which introduces SLP_TREE_REF_COUNT and replaces
the uses of refcnt with it. This for consistency between the other properties.
A similar patch was pre-approved last year but since there are more use now I am
sending it for review anyway.
gcc/ChangeLog:
* tree-vectorizer.h (SLP_TREE_REF_COUNT): New.
* tree-vect-slp.c (_slp_tree::_slp_tree, _slp_tree::~_slp_tree,
vect_free_slp_tree, vect_build_slp_tree, vect_print_slp_tree,
slp_copy_subtree, vect_attempt_slp_rearrange_stmts): Use it.
Now hiddenness is managed by name-lookup, we no longer need DECL_HIDDEN_FRIEND_P.
This removes it. Mainly by deleting its bookkeeping, but there are a couple of uses
1) two name lookups look at it to see if they found a hidden thing.
In one we have the OVERLOAD, so can record OVL_HIDDEN_P. In the other
we're repeating a lookup that failed, but asking for hidden things --
so if that succeeds we know the thing was hidden. (FWIW CWG recently
discussed whether template specializations and instantiations should
see such hidden templates anyway, there is compiler divergence.)
2) We had a confusing setting of KOENIG_P when building a
non-dependent call. We don't repeat that lookup at instantiation time
anyway.
gcc/cp/
* cp-tree.h (struct lang_decl_fn): Remove hidden_friend_p.
(DECL_HIDDEN_FRIEND_P): Delete.
* call.c (add_function_candidate): Drop assert about anticipated
decl.
(build_new_op_1): Drop koenig lookup flagging for hidden friend.
* decl.c (duplicate_decls): Drop HIDDEN_FRIEND_P updating.
* name-lookup.c (do_pushdecl): Likewise.
(set_decl_namespace): Discover hiddenness from OVL_HIDDEN_P.
* pt.c (check_explicit_specialization): Record found_hidden
explicitly.
Paul Thomas [Wed, 30 Sep 2020 12:44:39 +0000 (13:44 +0100)]
This patch fixes PR97045 - unlimited polymorphic array element selectors.
2020-30-09 Paul Thomas <pault@gcc.gnu.org>
gcc/fortran
PR fortran/97045
* trans-array.c (gfc_conv_array_ref): Make sure that the class
decl is passed to build_array_ref in the case of unlimited
polymorphic entities.
* trans-expr.c (gfc_conv_derived_to_class): Ensure that array
refs do not preceed the _len component. Free the _len expr.
* trans-stmt.c (trans_associate_var): Reset 'need_len_assign'
for polymorphic scalars.
* trans.c (gfc_build_array_ref): When the vptr size is used for
span, multiply by the _len field of unlimited polymorphic
entities, when non-zero.
gcc/testsuite/
PR fortran/97045
* gfortran.dg/select_type_50.f90 : New test.
Tom de Vries [Tue, 29 Sep 2020 08:10:06 +0000 (10:10 +0200)]
[nvptx] Add type arg to TARGET_LIBC_HAS_FUNCTION
GCC has a target hook TARGET_LIBC_HAS_FUNCTION, which tells the compiler
which functions it can expect to be present in libc.
The default target hook does not include the sincos functions.
The nvptx port of newlib does include sincos and sincosf, but not sincosl.
The target hook TARGET_LIBC_HAS_FUNCTION does not distinguish between sincos,
sincosf and sincosl, so if we enable it for the sincos functions, then for
test.c:
...
long double x, a, b;
int main (void) {
x = 0.5;
a = sinl (x);
b = cosl (x);
printf ("a: %f\n", (double)a);
printf ("b: %f\n", (double)b);
return 0;
}
...
we introduce a regression:
...
$ gcc test.c -lm -O2
unresolved symbol sincosl
collect2: error: ld returned 1 exit status
...
Add a type argument to target hook TARGET_LIBC_HAS_FUNCTION_TYPE, and use it
in nvptx_libc_has_function_type to enable sincos and sincosf, but not sincosl.
Build and reg-tested on x86_64-linux.
Build and tested on nvptx.
gcc/ChangeLog:
2020-09-28 Tobias Burnus <tobias@codesourcery.com>
Tom de Vries <tdevries@suse.de>
H.J. Lu [Wed, 23 Sep 2020 19:11:45 +0000 (12:11 -0700)]
x86: Use SET operation in MOVDIRI and MOVDIR64B
Since MOVDIRI and MOVDIR64B write to memory, similar to UNSPEC_MOVNT,
use SET operation in MOVDIRI and MOVDIR64B patterns with UNSPEC instead
of UNSPECV.
gcc/
PR target/97184
* config/i386/i386.md (UNSPECV_MOVDIRI): Renamed to ...
(UNSPEC_MOVDIRI): This.
(UNSPECV_MOVDIR64B): Renamed to ...
(UNSPEC_MOVDIR64B): This.
(movdiri<mode>): Use SET operation.
(@movdir64b_<mode>): Likewise.
Tom de Vries [Wed, 30 Sep 2020 09:51:41 +0000 (11:51 +0200)]
[testsuite] Re-enable pr94600-{1,3}.c tests for arm
Before commit 7e437162001 "[testsuite] Require non_strict_align in
pr94600-{1,3}.c", some tests were failing for nvptx, because volatile stores
were expected, but memcpy's were found instead.
This was traced back to this bit in compute_record_mode:
...
/* If structure's known alignment is less than what the scalar
mode would need, and it matters, then stick with BLKmode. */
if (mode != BLKmode
&& STRICT_ALIGNMENT
&& ! (TYPE_ALIGN (type) >= BIGGEST_ALIGNMENT
|| TYPE_ALIGN (type) >= GET_MODE_ALIGNMENT (mode)))
{
/* If this is the only reason this type is BLKmode, then
don't force containing types to be BLKmode. */
TYPE_NO_FORCE_BLK (type) = 1;
mode = BLKmode;
}
...
which got triggered for nvptx, but not for x86_64.
The commit disabled the tests for non_strict_align effective target, but
that had the effect for the arm target that those tests were disabled, even
though they were passing before.
Further investigation in compute_record_mode shows that the if-condition
evaluates to false for arm because, because TYPE_ALIGN (type) == 32, while
it's 8 for nvptx. This again can be explained by the
PCC_BITFIELD_TYPE_MATTERS setting, which is 1 for arm, but 0 for nvptx.
Re-enable the test for arm by using effective target
(non_strict_align || pcc_bitfield_type_matters).
PR target/97150 AArch64: 2nd parameter of unsigned Neon scalar shift intrinsics should be signed
In this PR the second argument to the intrinsics should be signed but we
use an unsigned one erroneously.
The corresponding builtins are already using the correct types so it's
just a matter of correcting the signatures in arm_neon.h
PR target/96313 AArch64: vqmovun* return types should be unsigned
In this PR we have the wrong return type for some intrinsics. It should
be unsigned, but we implement it as signed.
Fix this by adjusting the type qualifiers used when creating the
builtins and fixing the type in the arm_neon.h intrinsic.
With the adjustment in qualifiers we now don't need to cast the result
when returning.
Bootstrapped and tested on aarch64-none-linux-gnu.
movti lacked an way of zeroing an FPR, meaning that we'd do:
mov x0, 0
mov x1, 0
fmov d0, x0
fmov v0.d[1], x1
instead of just:
movi v0.2d, #0
movtf had the opposite problem for GPRs: we'd generate:
movi v0.2d, #0
fmov x0, d0
fmov x1, v0.d[1]
instead of just:
mov x0, 0
mov x1, 0
Also, there was an unnecessary earlyclobber on the GPR<-GPR movtf
alternative (but not the movti one). The splitter handles overlap
correctly.
The TF splitter used aarch64_reg_or_imm, but the _imm part only
accepts integer constants, not floating-point ones. The patch
changes it to nonmemory_operand instead.
gcc/
* config/aarch64/aarch64.c (aarch64_split_128bit_move_p): Add a
function comment. Tighten check for FP moves.
* config/aarch64/aarch64.md (*movti_aarch64): Add a w<-Z alternative.
(*movtf_aarch64): Handle r<-Y like r<-r. Remove unnecessary
earlyclobber. Change splitter predicate from aarch64_reg_or_imm
to nonmemory_operand.
gcc/testsuite/
* gcc.target/aarch64/movtf_1.c: New test.
* gcc.target/aarch64/movti_1.c: Likewise.
Alex Coplan [Wed, 30 Sep 2020 08:02:47 +0000 (09:02 +0100)]
arm: Fix ICEs in no-literal-pool.c on MVE [PR97251]
This patch fixes ICEs when compiling
gcc/testsuite/gcc.target/arm/pure-code/no-literal-pool.c with
-mfp16-format=ieee -mfloat-abi=hard -march=armv8.1-m.main+mve
-mpure-code.
The existing conditions in the movsf/movdf expanders (as well as the
no_literal_pool patterns) were too restrictive, requiring
TARGET_HARD_FLOAT instead of TARGET_VFP_BASE, which caused unrecognised
insns when compiling this testcase with integer MVE and -mpure-code.
* config/rs6000/rs6000.md (tablejump): Simplify.
(tablejumpsi): Merge this ...
(tablejumpdi): ... and this ...
(@tablejump<mode>_normal): ... into this.
(tablejumpsi_nospec): Merge this ...
(tablejumpdi_nospec): ... and this ...
(@tablejump<mode>_nospec): ... into this.
(*tablejump<mode>_internal1): Delete, rename to ...
(@tablejump<mode>_insn_normal): ... this.
(*tablejump<mode>_internal1_nospec): Delete, rename to ...
(@tablejump<mode>_insn_nospec): ... this.
Marek Polacek [Thu, 24 Sep 2020 18:30:50 +0000 (14:30 -0400)]
c++: Implement -Wrange-loop-construct [PR94695]
This new warning can be used to prevent expensive copies inside range-based
for-loops, for instance:
struct S { char arr[128]; };
void fn () {
S arr[5];
for (const auto x : arr) { }
}
where auto deduces to S and then we copy the big S in every iteration.
Using "const auto &x" would not incur such a copy. With this patch the
compiler will warn:
q.C:4:19: warning: loop variable 'x' creates a copy from type 'const S' [-Wrange-loop-construct]
4 | for (const auto x : arr) { }
| ^
q.C:4:19: note: use reference type 'const S&' to prevent copying
4 | for (const auto x : arr) { }
| ^
| &
As per Clang, this warning is suppressed for trivially copyable types
whose size does not exceed 64B. The tricky part of the patch was how
to figure out if using a reference would have prevented a copy. To
that point, I'm using the new function called ref_conv_binds_directly_p.
This warning is enabled by -Wall. Further warnings of similar nature
should follow soon.
gcc/c-family/ChangeLog:
PR c++/94695
* c.opt (Wrange-loop-construct): New option.
gcc/cp/ChangeLog:
PR c++/94695
* call.c (ref_conv_binds_directly_p): New function.
* cp-tree.h (ref_conv_binds_directly_p): Declare.
* parser.c (warn_for_range_copy): New function.
(cp_convert_range_for): Call it.
David Edelsohn [Sun, 9 Aug 2020 18:26:44 +0000 (14:26 -0400)]
testsuite: Remove unnecessary DWARF2 xfails on AIX
A number of DWARF2 testsuite xfails no longer trigger on AIX. This patch
removes the unnecessary XFAIL decorations that cause extraneous notices
that clutter the testsuite output.
PR analyzer/95188 reports that diagnostics from
-Wanalyzer-unsafe-call-within-signal-handler use the wrong
source location when reporting the signal-handler registration
event in the diagnostic_path. The diagnostics erroneously use the
location of the first stmt in the basic block containing the call
to "signal", rather than that of the call itself.
Jim Wilson [Tue, 29 Sep 2020 00:13:40 +0000 (17:13 -0700)]
Fix GCC 10+ build failure with zstd version 1.2.0 or older.
Extends the configure check for zstd.h to also verify the zstd version,
since gcc requires features that only exist in 1.3.0 and newer. Without
this patch we get a build error for lto-compress.c when using an old zstd
version.
This patch moves the handling of decl-hiddenness entirely into the
name lookup machinery, where it belongs. We need a few new flags,
because pressing the existing OVL_HIDDEN_P into play for non-function
decls doesn't work well. For a local binding we only need one marker,
as there cannot be both a hidden implicit typedef and a hidden
function. That's not true for namespace-scope, where they could both
be hidden.
The name-lookup machinery maintains the existing decl_hidden and co
flags, and asserts have been sprinkled around to make sure they are
consistent. The next series of patches will remove those old markers.
(we'll need to keep one, as there are some special restrictions on
redeclaring friend functions with in-class definitions or default args.)
gcc/cp/
* cp-tree.h (ovl_insert): Change final parm to hidden-or-using
indicator.
* name-lookup.h (HIDDEN_TYPE_BINDING_P): New.
(struct cxx_binding): Add type_is_hidden flag.
* tree.c (ovl_insert): Change using_p parm to using_or_hidden,
adjust.
(ovl_skip_hidden): Assert we never see a naked hidden decl.
* decl.c (xref_tag_1): Delete unhiding friend from here (moved to
lookup_elaborated_type_1).
* name-lookup.c (STAT_TYPE_HIDDEN_P, STAT_DECL_HIDDEN_P): New.
(name_lookup::search_namespace_only): Check new hidden markers.
(cxx_binding_make): Clear HIDDEN_TYPE_BINDING_P.
(update_binding): Update new hidden markers.
(lookup_name_1): Check HIDDEN_TYPE_BINDING_P and simplify friend
ignoring.
(lookup_elaborated_type_1): Use new hidden markers. Reveal the
decl here.
Here are a few cleanups, prior to landing the hidden decl changes.
1) Clear cxx_binding flags in the allocator, not at each user of the allocator.
2) Refactor update_binding. The logic was getting too convoluted.
3) Set friendliness and anticipatedness before pushing a template decl (not after).
gcc/cp/
* name-lookup.c (create_local_binding): Do not clear
INHERITED_VALUE_BINDING_P here.
(name_lookup::process_binding): Move done hidden-decl triage to ...
(name_lookup::search_namespace_only): ... here, its only caller.
(cxx_binding_make): Clear flags here.
(push_binding): Not here.
(pop_local_binding): RAII.
(update_binding): Refactor.
(do_pushdecl): Assert we're never revealing a local binding.
(do_pushdecl_with_scope): Directly call do_pushdecl.
(get_class_binding): Do not clear LOCAL_BINDING_P here.
* pt.c (push_template_decl): Set friend & anticipated before
pushing.
David Edelsohn [Sun, 27 Sep 2020 15:47:25 +0000 (11:47 -0400)]
testsuite: Prevent spellcheck-inttypes failures on AIX.
AIX stdio.h implicitly includes sys/types.h, which implicitly includes
inttypes.h. With a recent AIX header fixincludes change to unilaterally
define STDC Macros, the GCC testsuite uses of inttypes now fails.
This patch explicitly defines the _STD_TYPES_T macro when the test is
run on AIX so that the inttypes.h header behaves as the testcase requires.
gcc/testsuite/ChangeLog:
2020-09-29 David Edelsohn <dje.gcc@gmail.com>
* g++.dg/spellcheck-inttypes.C: Define _STD_TYPES_T on AIX.
* gcc.dg/spellcheck-inttypes.c: Same.
c++: Identifier type value should not update binding
This simplification removes some unneeded behaviour in
set_identifier_type_value_with_scope, which was updating the namespace
binding. And causing update_binding to have to deal with meeting two
implicit typedefs. But the typedef is already there, and there's no
other way to have two such typedef's collide (we'll already have dealt
with that in lookup_elaborated_type).
So, let's kill this crufty code.
gcc/cp/
* name-lookup.c (update_binding): We never meet two implicit
typedefs.
(do_pushdecl): Adjust set_identifier_type_value_with_scope calls.
(set_identifier_type_value_with_scope): Do not update binding in
the namespace-case. Assert it is already there.
Richard Biener [Tue, 29 Sep 2020 13:02:47 +0000 (15:02 +0200)]
tree-optimization/97241 - fix ICE in reduction vectorization
The following moves an ad-hoc attempt at discovering the SLP node
for a stmt to the place where we can find it in lock-step when
we find the stmt itself.
2020-09-29 Richard Biener <rguenther@suse.de>
PR tree-optimization/97241
* tree-vect-loop.c (vectorizable_reduction): Move finding
the SLP node for the reduction stmt to a better place.
Andrew Stubbs [Thu, 17 Sep 2020 11:53:39 +0000 (12:53 +0100)]
libgomp: disable barriers in nested teams
Both GCN and NVPTX allow nested parallel regions, but the barrier
implementation did not allow the nested teams to run independently of each
other (due to hardware limitations). This patch fixes that, under the
assumption that each thread will create a new subteam of one thread, by
simply not using barriers when there's no other thread to synchronise.
libgomp/ChangeLog:
* config/gcn/bar.c (gomp_barrier_wait_end): Skip the barrier if the
total number of threads is one.
(gomp_team_barrier_wake): Likewise.
(gomp_team_barrier_wait_end): Likewise.
(gomp_team_barrier_wait_cancel_end): Likewise.
* config/nvptx/bar.c (gomp_barrier_wait_end): Likewise.
(gomp_team_barrier_wake): Likewise.
(gomp_team_barrier_wait_end): Likewise.
(gomp_team_barrier_wait_cancel_end): Likewise.
* testsuite/libgomp.c-c++-common/nested-parallel-unbalanced.c: New test.
The AArch32 port now has three vector extensions: iwMMXt, Neon
and MVE. We already have some named expanders that are shared
by all three, and soon we'll need more.
One way of handling this would be to use define_mode_iterators
that specify the condition for each mode. For example,
etc. However, we'll need several mode iterators, and it would
be repetitive to specify the mode condition every time.
This patch therefore introduces per-mode macros that say whether
we can perform general arithmetic on the mode. Initially there are
two sets of macros:
ARM_HAVE_NEON_<MODE>_ARITH
true if Neon can handle general arithmetic on <MODE>
ARM_HAVE_<MODE>_ARITH
true if any vector extension can handle general arithmetic on <MODE>
The macro definitions themselves are undeniably ugly, but hopefully
they're justified by the simplifications they allow.
The patch converts the addition patterns to use this scheme.
Previously there were three copies of the V8HF and V4HF addition
patterns for Neon:
(1) *add<VDQ:mode>3_neon, which provided plus:VnHF even without
TARGET_NEON_FP16INST. This was probably harmless since all the
named patterns had an appropriate guard, but it is possible that
something could have tried to generate the plus directly, such as
by using a REG_EQUAL note to generate a new pattern.
(2) addv8hf3_neon and addv4hf3, which had the correct
TARGET_NEON_FP16INST target condition, but unnecessarily required
flag_unsafe_math_optimizations. Unlike VnSF operations, VnHF
operations do not force flush to zero.
(3) add<VH:mode>3_fp16, which provided plus:VnHF with the
correct conditions (TARGET_NEON_FP16INST, with no
flag_unsafe_math_optimizations test).
The patch in essence renames add<VH:mode>3_fp16 to *add<VH:mode>3_neon
(part of *add<VDQ:mode>3_neon) and removes the other two patterns.
gcc/
* config/arm/arm.h (ARM_HAVE_NEON_V8QI_ARITH, ARM_HAVE_NEON_V4HI_ARITH)
(ARM_HAVE_NEON_V2SI_ARITH, ARM_HAVE_NEON_V16QI_ARITH): New macros.
(ARM_HAVE_NEON_V8HI_ARITH, ARM_HAVE_NEON_V4SI_ARITH): Likewise.
(ARM_HAVE_NEON_V2DI_ARITH, ARM_HAVE_NEON_V4HF_ARITH): Likewise.
(ARM_HAVE_NEON_V8HF_ARITH, ARM_HAVE_NEON_V2SF_ARITH): Likewise.
(ARM_HAVE_NEON_V4SF_ARITH, ARM_HAVE_V8QI_ARITH, ARM_HAVE_V4HI_ARITH)
(ARM_HAVE_V2SI_ARITH, ARM_HAVE_V16QI_ARITH, ARM_HAVE_V8HI_ARITH)
(ARM_HAVE_V4SI_ARITH, ARM_HAVE_V2DI_ARITH, ARM_HAVE_V4HF_ARITH)
(ARM_HAVE_V2SF_ARITH, ARM_HAVE_V8HF_ARITH, ARM_HAVE_V4SF_ARITH):
Likewise.
* config/arm/iterators.md (VNIM, VNINOTM): Delete.
* config/arm/vec-common.md (add<VNIM:mode>3, addv8hf3)
(add<VNINOTM:mode>3): Replace with...
(add<VDQ:mode>3): ...this new expander.
* config/arm/neon.md (*add<VDQ:mode>3_neon): Use the new
ARM_HAVE_NEON_<MODE>_ARITH macros as the C condition.
(addv8hf3_neon, addv4hf3, add<VFH:mode>3_fp16): Delete in
favor of the above.
(neon_vadd<VH:mode>): Use gen_add<mode>3 instead of
gen_add<mode>3_fp16.
gcc/testsuite/
* gcc.target/arm/armv8_2-fp16-arith-2.c: Expect FP16 vectorization
even without -ffast-math.
Martin Liska [Thu, 24 Sep 2020 11:34:13 +0000 (13:34 +0200)]
switch conversion: make a rapid speed up
gcc/ChangeLog:
PR tree-optimization/96979
* tree-switch-conversion.c (jump_table_cluster::can_be_handled):
Make a fast bail out.
(bit_test_cluster::can_be_handled): Likewise here.
* tree-switch-conversion.h (get_range): Use wi::to_wide instead
of a folding.
gcc/testsuite/ChangeLog:
PR tree-optimization/96979
* g++.dg/tree-ssa/pr96979.C: New test.
RISC-V/libgcc: Use `-fasynchronous-unwind-tables' for LIB2_DIVMOD_FUNCS
Use `-fasynchronous-unwind-tables' rather than `-fexceptions
-fnon-call-exceptions' in LIB2_DIVMOD_FUNCS compilation flags so as to
provide unwind tables for the affected functions while not pulling the
unwinder proper, which is not required here.
Beyond saving program space it fixes a RISC-V glibc build error due to
unsatisfied `malloc' and `free' references from the unwinder causing
link errors with `ld.so' where libgcc has been built at -O0.
libgcc/
* config/riscv/t-elf (LIB2_DIVMOD_EXCEPTION_FLAGS): New
variable.
David Malcolm [Mon, 28 Sep 2020 20:53:53 +0000 (16:53 -0400)]
analyzer: remove unused field
I added this field (and the struct itself) in the rewrite of region and
value-handling (808f4dfeb3a95f50f15e71148e5c1067f90a126d), but the field
was never used.
David Malcolm [Mon, 28 Sep 2020 19:42:31 +0000 (15:42 -0400)]
analyzer: fix ICE on non-pointer longjmp [PR97233]
gcc/analyzer/ChangeLog:
PR analyzer/97233
* analyzer.cc (is_longjmp_call_p): Require the initial argument
to be a pointer.
* engine.cc (exploded_node::on_longjmp): Likewise.
gcc/testsuite/ChangeLog:
PR analyzer/97233
* gcc.dg/analyzer/pr97233.c: New test.
This is the irange storage class. It is used to allocate the
minimum amount of storage needed for a given irange. Storage is
automatically freed at destruction of the storage class.
It is meant for long term storage, as opposed to int_range_max
which is meant for intermediate temporary results on the stack.
The general gist is:
irange_allocator alloc;
// Allocate an irange of 5 sub-ranges.
irange *p = alloc.allocate (5);
// Allocate an irange of 3 sub-ranges.
irange *q = alloc.allocate (3);
// Allocate an irange with as many sub-ranges as are currently
// used in "some_other_range".
irange *r = alloc.allocate (some_other_range);
Patrick Palka [Mon, 28 Sep 2020 16:05:32 +0000 (12:05 -0400)]
libstdc++: Rearrange some range adaptors' data members
Since the standard range adaptors are specified to derive from the empty
class view_base, having their first data member store the underlying
view is suboptimal, for if the underlying view also derives from
view_base then the two view_base subobjects will be adjacent; this
prevents the compiler from applying the empty base optimization to elide
away the storage for these two empty bases.
This patch improves the situation by declaring the _M_base data member
last instead of first in each range adaptor that has more than one data
member, so that the empty base optimization can apply in more cases.
libstdc++-v3/ChangeLog:
* include/std/ranges (filter_view): Declare the data member
_M_base last instead of first, and adjust constructors' member
initializer lists accordingly.
(transform_view): Likewise.
(take_view): Likewise.
(take_while_view): Likewise.
(drop_view): Likewise.
(drop_while_view): Likewise.
(join_view): Likewise.
(split_view): Likewise (and tweak nearby formatting).
(reverse_view): Likewise.
* testsuite/std/ranges/adaptors/sizeof.cc: Update expected
sizes.
Patrick Palka [Mon, 28 Sep 2020 15:54:57 +0000 (11:54 -0400)]
libstdc++: Reduce the size of an unbounded iota_view
libstdc++-v3/ChangeLog:
* include/std/ranges (iota_view::_M_bound): Give it
[[no_unique_address]].
* testsuite/std/ranges/iota/iota_view.cc: Check that an
unbounded iota_view has minimal size.
projects / thirdparty / gcc.git / log
