* config/rs6000/freebsd64.h (SUBSUBTARGET_OVERRIDE_OPTIONS): Use
rs6000_linux64_override_options.
* config/rs6000/linux64.h (SUBSUBTARGET_OVERRIDE_OPTIONS): Break
out to..
* config/rs6000/rs6000.c (rs6000_linux64_override_options): ..this,
new function. Tweak non-biarch test and clearing of
profile_kernel to work with freebsd64.h.
There are only a couple of asserts remaining using this macro, and
nothing using TYPE_HIDDEN_P. Killed thusly.
gcc/cp/
* cp-tree.h (DECL_ANTICIPATED): Adjust comment.
(DECL_HIDDEN_P, TYPE_HIDDEN_P): Delete.
* tree.c (ovl_insert): Delete DECL_HIDDEN_P assert.
(ovl_skip_hidden): Likewise.
Since a889e06ac6 the following fails.
In file included from ../../gcc/tree-ssa-propagate.h:25:0,
from ../../gcc/config/rs6000/rs6000.c:78:
../../gcc/value-query.h:90:31: error: ‘irange’ has not been declared
virtual bool range_of_expr (irange &r, tree name, gimple * = NULL) = 0;
^~~~~~
../../gcc/value-query.h:91:31: error: ‘irange’ has not been declared
virtual bool range_on_edge (irange &r, edge, tree name);
^~~~~~
../../gcc/value-query.h:92:31: error: ‘irange’ has not been declared
virtual bool range_of_stmt (irange &r, gimple *, tree name = NULL);
^~~~~~
In file included from ../../gcc/tree-ssa-propagate.h:25:0,
from ../../gcc/config/rs6000/rs6000-call.c:67:
../../gcc/value-query.h:90:31: error: ‘irange’ has not been declared
virtual bool range_of_expr (irange &r, tree name, gimple * = NULL) = 0;
^~~~~~
../../gcc/value-query.h:91:31: error: ‘irange’ has not been declared
virtual bool range_on_edge (irange &r, edge, tree name);
^~~~~~
../../gcc/value-query.h:92:31: error: ‘irange’ has not been declared
virtual bool range_of_stmt (irange &r, gimple *, tree name = NULL);
gcc/ChangeLog:
* config/rs6000/rs6000-call.c: Include value-range.h.
* config/rs6000/rs6000.c: Likewise.
When running:
...
$ gcc.sh src/gcc/testsuite/gcc.target/nvptx/abi-complex-arg.c -S -dP
...
we have in abi-complex-arg.s:
...
//(insn 3 5 4 2
// (set
// (reg:QI 23)
// (truncate:QI (reg:SI 22))) "abi-complex-arg.c":38:1 29 {truncsiqi2}
// (nil))
cvt.u32.u32 %r23, %r22; // 3 [c=4] truncsiqi2/0
...
The cvt.u32.u32 can be written shorter and clearer as mov.u32.
Fix this in define_insn "truncsi<QHIM>2".
Tested on nvptx.
gcc/ChangeLog:
2020-10-01 Tom de Vries <tdevries@suse.de>
PR target/80845
* config/nvptx/nvptx.md (define_insn "truncsi<QHIM>2"): Emit mov.u32
instead of cvt.u32.u32.
This patch does several things at once:
(1) Add vector compare patterns (vec_cmp and vec_cmpu).
(2) Add vector selects between floating-point modes when the
values being compared are integers (affects vcond and vcondu).
(3) Add vector selects between integer modes when the values being
compared are floating-point (affects vcond).
(4) Add standalone vector select patterns (vcond_mask).
(5) Tweak the handling of compound comparisons with zeros.
Unfortunately it proved too difficult (for me) to separate this
out into a series of smaller patches, since everything is so
inter-related. Defining only some of the new patterns does
not leave things in a happy state.
The handling of comparisons is mostly taken from the vcond patterns.
This means that it remains non-compliant with IEEE: “quiet” comparisons
use signalling instructions. But that shouldn't matter for floats,
since we require -funsafe-math-optimizations to vectorize for them
anyway.
It remains the case that comparisons and selects aren't implemented
at all for HF vectors. Implementing those feels like separate work.
gcc/
PR target/96528
PR target/97288
* config/arm/arm-protos.h (arm_expand_vector_compare): Declare.
(arm_expand_vcond): Likewise.
* config/arm/arm.c (arm_expand_vector_compare): New function.
(arm_expand_vcond): Likewise.
* config/arm/neon.md (vec_cmp<VDQW:mode><v_cmp_result>): New pattern.
(vec_cmpu<VDQW:mode><VDQW:mode>): Likewise.
(vcond<VDQW:mode><VDQW:mode>): Require operand 5 to be a register
or zero. Use arm_expand_vcond.
(vcond<V_cvtto><V32:mode>): New pattern.
(vcondu<VDQIW:mode><VDQIW:mode>): Generalize to...
(vcondu<VDQW:mode><v_cmp_result): ...this. Require operand 5
to be a register or zero. Use arm_expand_vcond.
(vcond_mask_<VDQW:mode><v_cmp_result>): New pattern.
(neon_vc<cmp_op><mode>, neon_vc<cmp_op><mode>_insn): Add "@" marker.
(neon_vbsl<mode>): Likewise.
(neon_vc<cmp_op>u<mode>): Reexpress as...
(@neon_vc<code><mode>): ...this.
gcc/testsuite/
* lib/target-supports.exp (check_effective_target_vect_cond_mixed): Add
arm neon targets.
* gcc.target/arm/neon-compare-1.c: New test.
* gcc.target/arm/neon-compare-2.c: Likewise.
* gcc.target/arm/neon-compare-3.c: Likewise.
* gcc.target/arm/neon-compare-4.c: Likewise.
* gcc.target/arm/neon-compare-5.c: Likewise.
* gcc.target/arm/neon-vcond-gt.c: Expect comparisons with zero.
* gcc.target/arm/neon-vcond-ltgt.c: Likewise.
* gcc.target/arm/neon-vcond-unordered.c: Likewise.
* config/i386/t-rtems: Change from mtune to march when building
multilibs. The mtune argument tunes or optimizes for a specific
CPU model but does not ensure the generated code is appropriate
for the CPU model. Prior to this patch, i386 compatible code
was always generated but tuned for later models.
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.
* gcc.dg/vect/pr97236.c: New testcase.
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.
gcc/cp/
* name-lookup.c (pushdecl_top_level): Assert incoming context is
null, add global_namespace context.
(pushdecl_top_level_and_finish): Likewise.
* pt.c (get_template_parm_object): Clear decl context before
pushing.
* semantics.c (finish_compound_literal): Likewise.
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.
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.
gcc/cp/
* decl.c (lookup_and_check_tag): Refactor.
This moves the recent entry for Neoverse N2 down and adds a comment in
order to preserve the existing order/structure in arm-cpus.in.
gcc/ChangeLog:
* config/arm/arm-cpus.in: Fix ordering, move Neoverse N2 down.
* config/arm/arm-tables.opt: Regenerate.
* config/arm/arm-tune.md: Regenerate.
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.
> > 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.
* g++.dg/cpp2a/consteval18.C: New test.
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.
* g++.dg/cpp2a/constexpr-new14.C: New test.
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.
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.
* g++.dg/vect/pr97255.cc: New testcase.
These micro-architecture levels are defined in the x86-64 psABI:
https://gitlab.com/x86-psABIs/x86-64-ABI/-/commit/77566eb03bc6a326811cb7e9
PTA_NO_TUNE is introduced so that the new processor alias table entries
do not affect the CPU tuning setting in ix86_tune.
The tests depend on the macros added in commit 92e652d8c2
("i386: Define __LAHF_SAHF__ and __MOVBE__ macros, based on ISA flags").
gcc/:
PR target/97250
* config/i386/i386.h (PTA_NO_TUNE, PTA_X86_64_BASELINE)
(PTA_X86_64_V2, PTA_X86_64_V3, PTA_X86_64_V4): New.
* common/config/i386/i386-common.c (processor_alias_table):
Add "x86-64-v2", "x86-64-v3", "x86-64-v4".
* config/i386/i386-options.c (ix86_option_override_internal):
Handle new PTA_NO_TUNE processor table entries.
* doc/invoke.texi (x86 Options): Document new -march values.
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.
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.
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.
This PR points out that we accept
template<typename T> struct tuple { tuple(T); }; // #1
template<typename T> explicit tuple(T t) -> tuple<T>; // #2
tuple t = { 1 };
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:
(1) template<class T> tuple(T) -> tuple<T> [DECL_NONCONVERTING_P]
(2) template<class T> tuple(tuple<T>) -> tuple<T>
(3) template<class T> tuple(T) -> tuple<T>
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.
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.
Resolves:
PR middle-end/97189 - ICE on redeclaration of a function with VLA argument and attribute access
gcc/ChangeLog:
PR middle-end/97189
* attribs.c (attr_access::array_as_string): Avoid assuming a VLA
access specification string contains a closing bracket.
gcc/c-family/ChangeLog:
PR middle-end/97189
* c-attribs.c (append_access_attr): Use the function declaration
location for a warning about an attribute access argument.
gcc/testsuite/ChangeLog:
PR middle-end/97189
* gcc.dg/attr-access-2.c: Adjust caret location.
* gcc.dg/Wvla-parameter-6.c: New test.
* gcc.dg/Wvla-parameter-7.c: New test.
gcc/ChangeLog:
PR c/97206
* attribs.c (attr_access::array_as_string): Avoid modifying a shared
type in place and use build_type_attribute_qual_variant instead.
gcc/testsuite/ChangeLog:
PR c/97206
* gcc.dg/Warray-parameter-7.c: New test.
* gcc.dg/Warray-parameter-8.c: New test.
* gcc.dg/Wvla-parameter-5.c: New test.
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.
Accelerators with fixed thread-counts will break if nested teams are expected
to have multiple threads each.
libgomp/ChangeLog:
2020-09-29 Andrew Stubbs <ams@codesourcery.com>
* parallel.c (gomp_resolve_num_threads): Ignore nest_var on nvptx
and amdgcn targets.
* 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.
2020-09-30 Jan Hubicka <hubicka@ucw.cz>
* trans-io.c (gfc_build_io_library_fndecls): Add trailing dots so
length of spec string matches number of arguments.
Add a testcase for PR target/96827 which was fixed by r11-3559:
commit 97b798d80b
Author: Joel Hutton <joel.hutton@arm.com>
Date: Wed Sep 30 15:08:13 2020 +0100
[SLP][VECT] Add check to fix 96837
PR target/96827
* gcc.target/i386/pr96827.c: New test.
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.
2020-09-07 Christophe Lyon <christophe.lyon@linaro.org>
gcc/testsuite/
PR target/94595
* gcc.target/arm/thumb2-cond-cmp-1.c: Skip if arm_cortex_m.
* gcc.target/arm/thumb2-cond-cmp-2.c: Skip if arm_cortex_m.
* gcc.target/arm/thumb2-cond-cmp-3.c: Skip if arm_cortex_m.
* gcc.target/arm/thumb2-cond-cmp-4.c: Skip if arm_cortex_m.
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.
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.
