Re: [Patch][LTO] Set proper DECL_ALIGN in offload_handle_link_vars (PR94233)
On Sat, 21 Mar 2020, Tobias Burnus wrote: > On 3/21/20 8:03 AM, Richard Biener wrote: > > >> OK for the trunk? > > It should be TYPE_ALIGN (type). OK with that change. > > I am confused. The patch has: > + SET_DECL_ALIGN (link_ptr_var, TYPE_ALIGN (ptr_type_node)); > which looks correct and to uses already TYPE_ALIGN?!? > > > Note this fails to honor target bits so it might be better to lay out the > > decl properly? > > However, that's a good point. Let's do it properly by calling layout_decl > — indirectly, by calling build_decl. > > OK? OK. Thanks, Richard.
RE: [PATCH PR94026] combine missed opportunity to simplify comparisons with zero
> -Original Message- > From: Segher Boessenkool [mailto:seg...@kernel.crashing.org] > Sent: Friday, March 20, 2020 9:38 AM > To: Yangfei (Felix) > Cc: gcc-patches@gcc.gnu.org; Zhanghaijian (A) > Subject: Re: [PATCH PR94026] combine missed opportunity to simplify > comparisons with zero > > On Thu, Mar 19, 2020 at 01:43:40AM +, Yangfei (Felix) wrote: > > 2. Given that the patterns for ubfx and ubfiz are already not simple, I am > afraid the pattern we got by combining the three would be much complex. > > And even more complex when further merged with insn 14 here in order to > make sure that we are doing a equality comparison with zero. > > It will be just as simple as with the other approach: I think the problem here is how to make sure we are doing a ***equality*** comparison with zero. We can only do the transformation under this condition. Then I see combine tries the following pattern: 173 Failed to match this instruction: 174 (set (reg:SI 101) 175 (ne:SI (and:SI (lshiftrt:SI (reg:SI 102) 176 (const_int 8 [0x8])) 177 (const_int 6 [0x6])) 178 (const_int 0 [0]))) But this cannot match a 'tst' instruction as the above pattern does not clobber the CC flag register. Also this means that we depend on specific uses cases, so may need different patterns to match all possible cases. > > > Another approach: > > > > > > Trying 7 -> 9: > > > 7: r99:SI=r103:SI>>0x8 > > > REG_DEAD r103:SI > > > 9: cc:CC_NZ=cmp(r99:SI&0x6,0) > > > REG_DEAD r99:SI > > > Failed to match this instruction: > > > (set (reg:CC_NZ 66 cc) > > > (compare:CC_NZ (and:SI (lshiftrt:SI (reg:SI 103) > > > (const_int 8 [0x8])) > > > (const_int 6 [0x6])) > > > (const_int 0 [0]))) > > > > > > This can be recognised as just that "tst" insn, no? But combine (or > > > simplify-rtx) should get rid of the shift here, just the "and" is > > > simpler after all (it just needs to change the constant for that). > > > > No, this does not mean an equality comparison with zero. I have mentioned > this in my previous mail. > > This should be simplified to > (set (reg:CC_NZ 66 cc) > (compare:CC_NZ (and:SI (reg:SI 103) > (const_int 1536)) > (const_int 0))) > (but it isn't), and that is just *and3nr_compare0, which is a "tst" > instruction. If this is fixed (in simplify-rtx.c), it will work as you want. But I don't think it's correct for logic in simplify-rtx.c to further simplify this rtl: (compare:CC_NZ (and:SI (lshiftrt:SI (reg:SI 102) (const_int 8 [0x8])) (const_int 6 [0x6])) (const_int 0 [0])) The reason is that it knows nothing about CC_NZ. CC_NZ is aarch64-port specific and it does not necessarily mean a equality comparison with zero. Correct me if I missed anything. Thanks, Felix
[PATCH] ipa/94245 - avoid folding when we want an ADDR_EXPR
Another case where build_fold_addr_expr is harmful.
Bootstrap/regtest running on x86_64-unknown-linux-gnu.
2020-03-23 Richard Biener
PR ipa/94245
* ipa-prop.c (ipa_read_jump_function): Build the ADDR_EXRP
directly rather than also folding it via build_fold_addr_expr.
---
gcc/ipa-prop.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/ipa-prop.c b/gcc/ipa-prop.c
index a77130ded39..71ac0e104d2 100644
--- a/gcc/ipa-prop.c
+++ b/gcc/ipa-prop.c
@@ -4625,7 +4625,7 @@ ipa_read_jump_function (class lto_input_block *ib,
{
tree t = stream_read_tree (ib, data_in);
if (flag && prevails)
- t = build_fold_addr_expr (t);
+ t = build1 (ADDR_EXPR, build_pointer_type (TREE_TYPE (t)), t);
ipa_set_jf_constant (jump_func, t, cs);
}
break;
--
2.13.7
[PATCH] tree-optimization/94266 - aovid propagating addresses of TARGET_MEM_REFs
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2020-03-23 Richard Biener
PR tree-optimization/94266
* tree-ssa-forwprop.c (pass_forwprop::execute): Do not propagate
addresses of TARGET_MEM_REFs.
---
gcc/tree-ssa-forwprop.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/gcc/tree-ssa-forwprop.c b/gcc/tree-ssa-forwprop.c
index 61b4eec271b..234c1f7dd7d 100644
--- a/gcc/tree-ssa-forwprop.c
+++ b/gcc/tree-ssa-forwprop.c
@@ -2712,6 +2712,7 @@ pass_forwprop::execute (function *fun)
if ((!base
|| !DECL_P (base)
|| decl_address_invariant_p (base))
+ && TREE_CODE (base) != TARGET_MEM_REF
&& !stmt_references_abnormal_ssa_name (stmt)
&& forward_propagate_addr_expr (lhs, rhs, true))
{
--
2.16.4
[PATCH] Check endianess detection.
Hi. As seen in the PR, sparc64 LTO test-suite fails due to missing definition of __BIG_ENDIAN__ macro. That said, I updated the endianess detection to use __BYTE_ORDER__. I tested the detection on x86_64-linux-gnu, ppc64-linux-gnu and lto.exp testsuite survives on a sparc64-linux machine. Ready to be installed? Thanks, Martin include/ChangeLog: 2020-03-23 Martin Liska PR lto/94249 * plugin-api.h: Use __BYTE_ORDER__ instead of __BIG_ENDIAN__ which is not defined on sparc64 target. --- include/plugin-api.h | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/include/plugin-api.h b/include/plugin-api.h index 673f136ce68..5a45ce773f7 100644 --- a/include/plugin-api.h +++ b/include/plugin-api.h @@ -89,16 +89,18 @@ struct ld_plugin_symbol char *version; /* This is for compatibility with older ABIs. The older ABI defined only 'def' field. */ -#ifdef __BIG_ENDIAN__ +#if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__ char unused; char section_kind; char symbol_type; char def; -#else +#elif __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ char def; char symbol_type; char section_kind; char unused; +#else +#error "Could not detect architecture endianess" #endif int visibility; uint64_t size;
Re: [PR 94044] ICE with sizeof & argument pack
Hi Nathan: Tested variadic-sizeof4.C on x86, x86_64 with native compiler Tested variadic-sizeof4.C on aarch64, arm-eabi, riscv32, riscv64, mips, mips64 and nds32 with cross compiler. And tested g++/dg.exp on arm-eabi with this patch, no new fail introduced. On Mon, Mar 23, 2020 at 2:27 AM Jim Wilson wrote: > > On Fri, Mar 20, 2020 at 8:41 AM Nathan Sidwell wrote: > > If it could be tested on arm &| riscv, that'd be additional verification. > > I did riscv testing, both cross and native, and didn't see any new > problems with the patch. > > Jim
Re: [PATCH] Check endianess detection.
On Mon, Mar 23, 2020 at 10:25:32AM +0100, Martin Liška wrote: > Hi. > > As seen in the PR, sparc64 LTO test-suite fails due to missing > definition of __BIG_ENDIAN__ macro. That said, I updated the > endianess detection to use __BYTE_ORDER__. > > I tested the detection on x86_64-linux-gnu, ppc64-linux-gnu and > lto.exp testsuite survives on a sparc64-linux machine. Those are GCC specific macros, are you sure plugin-api.h will be always compiled just with GCC and no other compiler? You can use them but should be prepared for some fallback (e.g. endian.h, whatever else). And there is also PDP endian... Jakub
[RFC] Should widening_mul should consider block frequency?
Hi,
I created a bug for this issue:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94269
Looks like widening_mul phase may move multiply instruction from outside the
loop to inside the loop, merging with one add instruction inside the loop.
This will increase the cost of the loop at least on aarch64 (4 cycles vs 1
cycle). I think widening_mul should consider block frequency when doing such a
combination.
I mean something like:
diff --git a/gcc/tree-ssa-math-opts.c b/gcc/tree-ssa-math-opts.c
index 54ba035..4439452 100644
--- a/gcc/tree-ssa-math-opts.c
+++ b/gcc/tree-ssa-math-opts.c
@@ -2721,7 +2721,10 @@ convert_plusminus_to_widen (gimple_stmt_iterator *gsi,
gimple *stmt,
{
if (!has_single_use (rhs1)
|| !is_widening_mult_p (rhs1_stmt, &type1, &mult_rhs1,
- &type2, &mult_rhs2))
+ &type2, &mult_rhs2)
+ || (gimple_bb (rhs1_stmt) != gimple_bb (stmt)
+ && gimple_bb (rhs1_stmt)->count.to_frequency(cfun)
+< gimple_bb (stmt)->count.to_frequency(cfun)))
return false;
add_rhs = rhs2;
conv_stmt = conv1_stmt;
@@ -2730,7 +2733,10 @@ convert_plusminus_to_widen (gimple_stmt_iterator *gsi,
gimple *stmt,
{
if (!has_single_use (rhs2)
|| !is_widening_mult_p (rhs2_stmt, &type1, &mult_rhs1,
- &type2, &mult_rhs2))
+ &type2, &mult_rhs2)
+ || (gimple_bb (rhs2_stmt) != gimple_bb (stmt)
+ && gimple_bb (rhs2_stmt)->count.to_frequency(cfun)
+< gimple_bb (stmt)->count.to_frequency(cfun)))
return false;
add_rhs = rhs1;
conv_stmt = conv2_stmt;
Comments?
Thanks,
Felix
Re: [PATCH] Check endianess detection.
On 3/23/20 10:43 AM, Jakub Jelinek wrote: On Mon, Mar 23, 2020 at 10:25:32AM +0100, Martin Liška wrote: Hi. As seen in the PR, sparc64 LTO test-suite fails due to missing definition of __BIG_ENDIAN__ macro. That said, I updated the endianess detection to use __BYTE_ORDER__. I tested the detection on x86_64-linux-gnu, ppc64-linux-gnu and lto.exp testsuite survives on a sparc64-linux machine. Those are GCC specific macros, are you sure plugin-api.h will be always compiled just with GCC and no other compiler? And Clang supports that. The header file is used for GCC LTO plug-in (which is like a run-time library) and then it's consumed by binutils. So I don't how much portable it should be? You can use them but should be prepared for some fallback (e.g. endian.h, whatever else). And there is also PDP endian... Huh, are we talking about something so complex like: https://github.com/llvm-mirror/compiler-rt/blob/master/lib/builtins/int_endianness.h Btw. do we force our run-time libraries to be built with GCC? Thanks, Martin Jakub
Re: [PATCH] Check endianess detection.
On Mon, Mar 23, 2020 at 11:00:21AM +0100, Martin Liška wrote: > On 3/23/20 10:43 AM, Jakub Jelinek wrote: > > On Mon, Mar 23, 2020 at 10:25:32AM +0100, Martin Liška wrote: > > > Hi. > > > > > > As seen in the PR, sparc64 LTO test-suite fails due to missing > > > definition of __BIG_ENDIAN__ macro. That said, I updated the > > > endianess detection to use __BYTE_ORDER__. > > > > > > I tested the detection on x86_64-linux-gnu, ppc64-linux-gnu and > > > lto.exp testsuite survives on a sparc64-linux machine. > > > > Those are GCC specific macros, are you sure plugin-api.h will be always > > compiled just with GCC and no other compiler? > > And Clang supports that. The header file is used for GCC LTO plug-in > (which is like a run-time library) and then it's consumed by binutils. > So I don't how much portable it should be? GCC only supports that since GCC 4.6 and Clang copied that from that. If it is only used in the LTO plugin and nothing else, I guess you can rely in it being compiled by GCC only, but if it is e.g. used by binutils itself too, then no. > > You can use them but should be prepared for some fallback (e.g. endian.h, > > whatever else). > > And there is also PDP endian... > > Huh, are we talking about something so complex like: > https://github.com/llvm-mirror/compiler-rt/blob/master/lib/builtins/int_endianness.h I'd say even that is very simplified. E.g. on glibc there is with its macros, etc. > Btw. do we force our run-time libraries to be built with GCC? Some of our run-time libraries rely on being built by GCC, sure. But I thought include/ is shared with binutils and there we don't really say which compiler must be used to compile it. Jakub
Re: [PATCH] Check endianess detection.
On 3/23/20 11:10 AM, Jakub Jelinek wrote: On Mon, Mar 23, 2020 at 11:00:21AM +0100, Martin Liška wrote: On 3/23/20 10:43 AM, Jakub Jelinek wrote: On Mon, Mar 23, 2020 at 10:25:32AM +0100, Martin Liška wrote: Hi. As seen in the PR, sparc64 LTO test-suite fails due to missing definition of __BIG_ENDIAN__ macro. That said, I updated the endianess detection to use __BYTE_ORDER__. I tested the detection on x86_64-linux-gnu, ppc64-linux-gnu and lto.exp testsuite survives on a sparc64-linux machine. Those are GCC specific macros, are you sure plugin-api.h will be always compiled just with GCC and no other compiler? And Clang supports that. The header file is used for GCC LTO plug-in (which is like a run-time library) and then it's consumed by binutils. So I don't how much portable it should be? GCC only supports that since GCC 4.6 and Clang copied that from that. If it is only used in the LTO plugin and nothing else, I guess you can rely in it being compiled by GCC only, but if it is e.g. used by binutils itself too, then no. All right... You can use them but should be prepared for some fallback (e.g. endian.h, whatever else). And there is also PDP endian... Huh, are we talking about something so complex like: https://github.com/llvm-mirror/compiler-rt/blob/master/lib/builtins/int_endianness.h I'd say even that is very simplified. E.g. on glibc there is with its macros, etc. Btw. do we force our run-time libraries to be built with GCC? Some of our run-time libraries rely on being built by GCC, sure. But I thought include/ is shared with binutils and there we don't really say which compiler must be used to compile it. ... and can we then rely on configure detection of the endianess done by bfd and gold: gold/config.h:#define GOLD_DEFAULT_BIG_ENDIAN false bfd/PORTING: TARGET_IS_BIG_ENDIAN_P Should be defined if is big-endian. ? Martin Jakub
Re: [PATCH] Check endianess detection.
On Mon, Mar 23, 2020 at 11:28:00AM +0100, Martin Liška wrote: > > > > You can use them but should be prepared for some fallback (e.g. > > > > endian.h, > > > > whatever else). > > > > And there is also PDP endian... > > > > > > Huh, are we talking about something so complex like: > > > https://github.com/llvm-mirror/compiler-rt/blob/master/lib/builtins/int_endianness.h > > > > I'd say even that is very simplified. E.g. on glibc there is > > with its macros, etc. > > > > > Btw. do we force our run-time libraries to be built with GCC? > > > > Some of our run-time libraries rely on being built by GCC, sure. > > But I thought include/ is shared with binutils and there we don't really say > > which compiler must be used to compile it. > > ... and can we then rely on configure detection of the endianess done by bfd > and gold: > > gold/config.h:#define GOLD_DEFAULT_BIG_ENDIAN false > > bfd/PORTING: > TARGET_IS_BIG_ENDIAN_P > Should be defined if is big-endian. I don't think so. That is about the target, but you care about the host. Wouldn't it be much easier not to do this and simply use macros for bits from the full 32-bit value (and use shifts)? Jakub
Re: [Patch]+[RFC] AMDGCN offloading – use amdgcn-amdhsa vs. amdgcn-unknown-amdhsa
On 20/03/2020 21:08, Tobias Burnus wrote: Dear all, normally, the target triplet does not play much of a role as it is not really exposed to the user. However, for offloading, it appears often: * In distribution use, offloading support is compiled in, but not enabled by default; one needs to use -foffload=… explicitly. * Even with the default build (all offload targets are enabled by default), one still might need to specify the host triplet – if, e.g., NVidia and GCN are both supported — as AMDGCN needs a -march=, i.e. -foffload==-march=... Coming to offloading: * for Nvidia, everyone uses "nvptx-none" * for AMDGCN is was initially "amdgcn-unknown-amdhsa" However, when Matthias build it for Debian, he shortened it to "amdgcn-amdhsa" – as did Richard for SUSE. Cf https://salsa.debian.org/toolchain-team/gcc/-/blob/master/debian/rules2 andhttps://build.opensuse.org/package/view_file/devel:gcc/gcc10/gcc.spec.in?expand=1 This shortening makes it user friendlier and I like it, but it now causes that the offloading target is not recognized by the testsuite – and I think one also should update the documentation. OK – or do you have better/additional suggestions? The patch looks OK to me, as far as fixing the immediate problem goes. I hadn't realised this test was so fragile though. :-( Perhaps it should also recognise the standard names used in the OpenACC documentation? In this case "radeon". (I don't recall, off hand, if OpenMP uses standard device names.) Andrew
Re: [PR 94044] ICE with sizeof & argument pack
On 3/23/20 5:36 AM, Kito Cheng wrote: Hi Nathan: Tested variadic-sizeof4.C on x86, x86_64 with native compiler Tested variadic-sizeof4.C on aarch64, arm-eabi, riscv32, riscv64, mips, mips64 and nds32 with cross compiler. And tested g++/dg.exp on arm-eabi with this patch, no new fail introduced. On Mon, Mar 23, 2020 at 2:27 AM Jim Wilson wrote: On Fri, Mar 20, 2020 at 8:41 AM Nathan Sidwell wrote: If it could be tested on arm &| riscv, that'd be additional verification. I did riscv testing, both cross and native, and didn't see any new problems with the patch. Thanks for checking guys. Committed. nathan -- Nathan Sidwell
Re: [PATCH PR94026] combine missed opportunity to simplify comparisons with zero
On Mon, Mar 23, 2020 at 07:46:17AM +, Yangfei (Felix) wrote: > I think the problem here is how to make sure we are doing a ***equality*** > comparison with zero. > We can only do the transformation under this condition. > Then I see combine tries the following pattern: > > 173 Failed to match this instruction: > 174 (set (reg:SI 101) > 175 (ne:SI (and:SI (lshiftrt:SI (reg:SI 102) > 176 (const_int 8 [0x8])) > 177 (const_int 6 [0x6])) > 178 (const_int 0 [0]))) Like I said, this should be simplified to (set (reg:SI 10) (ne:SI (and:SI (reg:SI 102) (const_int 1536)) (const_int 0))) > But this cannot match a 'tst' instruction as the above pattern does not > clobber the CC flag register. combine can (and will) add such clobbers itself, if the pattern matches otherwise, so that is not an issue. > > This should be simplified to > > (set (reg:CC_NZ 66 cc) > > (compare:CC_NZ (and:SI (reg:SI 103) > > (const_int 1536)) > > (const_int 0))) > > (but it isn't), and that is just *and3nr_compare0, which is a "tst" > > instruction. If this is fixed (in simplify-rtx.c), it will work as you > > want. > > But I don't think it's correct for logic in simplify-rtx.c to further > simplify this rtl: > > (compare:CC_NZ (and:SI (lshiftrt:SI (reg:SI 102) > (const_int 8 [0x8])) > (const_int 6 [0x6])) > (const_int 0 [0])) > The reason is that it knows nothing about CC_NZ. Yeah, maybe not in simplify-rtx.c, hrm. There is SELECT_CC_MODE for these things, and combine knows about that (not many passes do). Segher
Re: [PATCH] Check endianess detection.
On 3/23/20 11:35 AM, Jakub Jelinek wrote: I don't think so. That is about the target, but you care about the host. I see. Wouldn't it be much easier not to do this and simply use macros for bits from the full 32-bit value (and use shifts)? That would make the current small hack even bigger. Note that plugin-api.h provides reasonable ways how to extend the API. That said, I incline to implement lto_plugin_symbols_v2 and use it in the corresponding function add_symbols_v2. @Richi: Can you please express your opinion? Thanks, Martin
Re: [PATCH V3][gcc] libgccjit: introduce version entry points
On Fri, 20 Mar 2020, David Malcolm wrote: > On Wed, 2020-03-18 at 23:51 +0100, Andrea Corallo wrote: > > Hi all, > > > > Updated version of the patch mainly addressing comments on the > > concurrency issues. > > > > I came to the conclusions that the caching should be done in the > > function that we decide to be thread safe. However I haven't touched > > parse_basever in any direction in the hope of having this still in > > stage4. As result I've mostly applied the mutex solution. > > > > 'make check-jit' runs clean > > > > Bests > > > > Andrea > > > > gcc/jit/ChangeLog > > 2020-??-?? Andrea Corallo > > David Malcolm > > > > * docs/topics/compatibility.rst (LIBGCCJIT_ABI_13): New ABI tag > > plus add version paragraph. > > * libgccjit++.h (namespace gccjit::version): Add new namespace. > > * libgccjit.c (gcc_jit_version_major, gcc_jit_version_minor) > > (gcc_jit_version_patchlevel): New functions. > > * libgccjit.h (LIBGCCJIT_HAVE_gcc_jit_version): New macro. > > (gcc_jit_version_major, gcc_jit_version_minor) > > (gcc_jit_version_patchlevel): New functions. > > * libgccjit.map (LIBGCCJIT_ABI_13) New ABI tag. > > > > gcc/testsuite/ChangeLog > > 2020-??-?? Andrea Corallo > > > > * jit.dg/test-version.c: New testcase. > > * jit.dg/all-non-failing-tests.h: Add test-version.c. > > > diff --git a/gcc/testsuite/jit.dg/all-non-failing-tests.h > > b/gcc/testsuite/jit.dg/all-non-failing-tests.h > > index 0272e6f846f..cba4ac51cc9 100644 > > --- a/gcc/testsuite/jit.dg/all-non-failing-tests.h > > +++ b/gcc/testsuite/jit.dg/all-non-failing-tests.h > > @@ -8,6 +8,13 @@ > > hooks provided by each test case. */ > > #define COMBINED_TEST > > > > +/* test-version.c */ > > +#define create_code create_code_version > > +#define verify_code verify_code_version > > +#include "test-version.c" > > +#undef create_code > > +#undef verify_code > > + > > /* test-accessing-bitfield.c */ > > #define create_code create_code_accessing_bitfield > > #define verify_code verify_code_accessing_bitfield > > Please add the new test to the header in its alphabetical location, > i.e. between: > > /* test-vector-types.cc: We don't use this, since it's C++. */ > > and > > /* test-volatile.c */ > > An entry also needs to be added to the "testcases" array at the end of > the header (again, in the alphabetical-sorted location). > > OK by me with that change (assuming you re-test the patch), but given > we're in stage 4, it's probably worth double-checking with a release > manager. I've CCed Jakub and Richi. I don't really care. Richard.
[Patch] lto/lto.c – used $ or . in generated linkptr name
As discussed in IRC, it makes sense to use '$' or '.' as
separator instead of '_' – and, if it is not available,
use a '__' prefix besides the '_' suffix separator.
OK?
Tobias
-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander
Walter
lto/lto.c – used $ or . in generated linkptr name
* lto.c (offload_handle_link_vars): Reduce chance of
naming clashes of generated linkptr variable.
diff --git a/gcc/lto/lto.c b/gcc/lto/lto.c
index 467b922eedf..cd34d6c9e7a 100644
--- a/gcc/lto/lto.c
+++ b/gcc/lto/lto.c
@@ -561,11 +561,9 @@ offload_handle_link_vars (void)
DECL_ATTRIBUTES (var->decl)))
{
tree type = build_pointer_type (TREE_TYPE (var->decl));
- tree var_name = DECL_ASSEMBLER_NAME (var->decl);
- char *new_name
- = ACONCAT ((IDENTIFIER_POINTER (var_name), "_linkptr", NULL));
tree link_ptr_var = build_decl (UNKNOWN_LOCATION, VAR_DECL,
- get_identifier (new_name), type);
+ clone_function_name (var->decl,
+ "linkptr"), type);
TREE_USED (link_ptr_var) = 1;
TREE_STATIC (link_ptr_var) = 1;
DECL_ARTIFICIAL (link_ptr_var) = 1;
Re: [Patch] lto/lto.c – used $ or . in generated linkptr name
On Mon, Mar 23, 2020 at 02:10:08PM +0100, Tobias Burnus wrote:
> As discussed in IRC, it makes sense to use '$' or '.' as
> separator instead of '_' – and, if it is not available,
> use a '__' prefix besides the '_' suffix separator.
>
> OK?
Ok (the function does what we want, although for vars is a little bit
misnamed).
> lto/lto.c – used $ or . in generated linkptr name
>
> * lto.c (offload_handle_link_vars): Reduce chance of
> naming clashes of generated linkptr variable.
>
> diff --git a/gcc/lto/lto.c b/gcc/lto/lto.c
> index 467b922eedf..cd34d6c9e7a 100644
> --- a/gcc/lto/lto.c
> +++ b/gcc/lto/lto.c
> @@ -561,11 +561,9 @@ offload_handle_link_vars (void)
> DECL_ATTRIBUTES (var->decl)))
>{
> tree type = build_pointer_type (TREE_TYPE (var->decl));
> - tree var_name = DECL_ASSEMBLER_NAME (var->decl);
> - char *new_name
> - = ACONCAT ((IDENTIFIER_POINTER (var_name), "_linkptr", NULL));
> tree link_ptr_var = build_decl (UNKNOWN_LOCATION, VAR_DECL,
> - get_identifier (new_name), type);
> + clone_function_name (var->decl,
> + "linkptr"), type);
> TREE_USED (link_ptr_var) = 1;
> TREE_STATIC (link_ptr_var) = 1;
> DECL_ARTIFICIAL (link_ptr_var) = 1;
Jakub
[PATCH] match.pd: recognize a signed rotate
Hi all,
A rotate of a signed integer is not recognized so far.
int32_t f (int32_t x)
{
return (x << 5) | (int32_t)((uint32_t)x >> 27);
}
The code above is unoptimized in contrast to a version consisting only
of unsigned integers. I'm wondering if this is intended or not. Since
GCC has well defined behavior for shifts where the first operand is
signed, I assumed that this also holds for rotates.
The attached patch adds a pattern to match.pd for such signed rotates.
Any comments about this?
Note, for the sake of simplicity the attached patch does not handle the
case where the input is a signed integer and the result is an unsigned,
i.e., the following case is not covered:
uint32_t f (int32_t x)
{
return (x << 5) | ((uint32_t)x >> 27);
}
My gut feeling was that it's not worth it to have another pattern for
such an impure rotate. Maybe I'm wrong?
Cheers,
Stefan
diff --git a/gcc/match.pd b/gcc/match.pd
index 9cb37740f1e..0297f8c9c89 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -2986,6 +2986,18 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
{ tree rotate_type = TREE_TYPE (@0); }
(convert (rotate (convert:rotate_type @1) @2))
+/* Recognize a signed rotate: assume that X is signed and C1+C2=width(X) holds,
+ then (X << C1) | (s)((u)X >> C2) -> X r>> C2 where (s) and (u) denote the
+ signed and unsigned types of X, respectively. */
+(simplify
+ (bit_ior
+ (lshift @0 INTEGER_CST@1)
+ (convert (rshift@3 (convert @0) INTEGER_CST@2)))
+ (if (wi::eq_p (wi::add (wi::to_wide (@1), wi::to_wide (@2)),
+ TYPE_PRECISION (TREE_TYPE (@0)))
+ && TYPE_UNSIGNED (TREE_TYPE (@3)))
+ (rrotate @0 @2)))
+
/* Simplifications of conversions. */
/* Basic strip-useless-type-conversions / strip_nops. */
[Patch] libgomp – fix declare target link handling (PR94251)
This patch fixes two issues:
(a) The target size is the pointer size and
host size is the variable size itself; thus, it fails often.
(b) Only the host variable has the link-var bit flip, hence,
we need to check this one not the target var's size.
With this patch, the test case passes on AMDGCN.
OK?
Tobias
PS: Unfortunately, all those patches do not help with nvptx,
which still fails (PR 81689) at run-time startup with
ptxas /tmp/ccSRPv5o.o, line 120; error : State space mismatch between
instruction and address in instruction 'ld'
-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander
Walter
libgomp – fix declare target link handling (PR94251)
PR libgomp/94251
* target.c (gomp_load_image_to_device): Fix link
variable handling.
diff --git a/libgomp/target.c b/libgomp/target.c
index 0ff727de47d..c99dd5196fa 100644
--- a/libgomp/target.c
+++ b/libgomp/target.c
@@ -1648,8 +1648,9 @@ gomp_load_image_to_device (struct gomp_device_descr *devicep, unsigned version,
{
struct addr_pair *target_var = &target_table[num_funcs + i];
uintptr_t target_size = target_var->end - target_var->start;
+ bool is_link_var = link_bit & (uintptr_t) host_var_table[i * 2 + 1];
- if ((uintptr_t) host_var_table[i * 2 + 1] != target_size)
+ if (!is_link_var && (uintptr_t) host_var_table[i * 2 + 1] != target_size)
{
gomp_mutex_unlock (&devicep->lock);
if (is_register_lock)
@@ -1663,7 +1664,7 @@ gomp_load_image_to_device (struct gomp_device_descr *devicep, unsigned version,
= k->host_start + (size_mask & (uintptr_t) host_var_table[i * 2 + 1]);
k->tgt = tgt;
k->tgt_offset = target_var->start;
- k->refcount = target_size & link_bit ? REFCOUNT_LINK : REFCOUNT_INFINITY;
+ k->refcount = is_link_var ? REFCOUNT_LINK : REFCOUNT_INFINITY;
k->virtual_refcount = 0;
k->aux = NULL;
array->left = NULL;
Re: [Patch] libgomp – fix declare target link handling (PR94251)
On Mon, Mar 23, 2020 at 02:40:12PM +0100, Tobias Burnus wrote: > This patch fixes two issues: > > (a) The target size is the pointer size and > host size is the variable size itself; thus, it fails often. > > (b) Only the host variable has the link-var bit flip, hence, > we need to check this one not the target var's size. > > With this patch, the test case passes on AMDGCN. > OK? I'm puzzled on why it (probably?) happend to work when 4a38b02b4ed0 has been committed, given that the testcase did contain variables in link clauses that didn't have pointer sizes themselves. Anyway, your patch looks good to me. > PS: Unfortunately, all those patches do not help with nvptx, > which still fails (PR 81689) at run-time startup with > ptxas /tmp/ccSRPv5o.o, line 120; error : State space mismatch between > instruction and address in instruction 'ld' Can you post the PTX assembly and perhaps some RTL dump? > libgomp – fix declare target link handling (PR94251) > > PR libgomp/94251 > * target.c (gomp_load_image_to_device): Fix link > variable handling. Thanks. Jakub
Re: [PING^2][PATCH] Fix documentation of -mpoke-function-name ARM option
On 22/03/2020 18:15, Jérémy Lefaure wrote: > Hi Wilco, > > On Mon, Mar 09, 2020 at 05:53:41PM +, Wilco Dijkstra wrote: >> Hi, >> >> There is no single PC offset that is correct given CPUs may use different >> offsets. > > Isn't it always an offset of 8 in ARM mode and 4 bytes in Thumb mode ? > At least in ARMv7 and in AArch32 state in ARMv8 ? > No, it depends on the architecture version. Prior to ARMv5 it was implementation defined. Some cores would use +12 in Arm state, others +8. > >> GCC may also schedule the instruction that stores the PC. This feature used >> to >> work on early Arms but is no longer functional or useful today, so the best >> way >> forward is to remove it altogether. There are many similar options that have >> been deprecated for years. >> > I didn't know that this feature is no longer working. Thank your for the > info. The poke-function-name feature depends on the long-deprecated APCS variant of the procedure call standard (the AAPCS has been the standard for well over 10 years now). I don't think we should be adding (or, now, even trying to fix) features that are dependent on it. We will be moving away from codegen support for this type of frame layout in the not too distant future. R. > > > Thank your for having reviewed my patch, > Jérémy >
[PATCH] tree-optimization/94261 - avoid IL adjustments in SLP analysis
The remaining IL adjustment done by SLP analysis turns out harmful
since we share them in the now multiple analyses states. It turns
out we do not actually need those apart from the case where we
reorg scalar stmts during re-arrangement when optimizing load
permutations in SLP reductions. But that isn't needed either now
since we only need to permute non-isomorphic parts which now
reside in separate SLP nodes who are all leafs.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
CPU2006 was OK with -Ofast -march=haswell.
Richard.
2020-03-23 Richard Biener
PR tree-optimization/94261
* tree-vect-slp.c (vect_get_and_check_slp_defs): Remove
IL operand swapping code.
(vect_slp_rearrange_stmts): Do not arrange isomorphic
nodes that would need operation code adjustments.
---
gcc/tree-vect-slp.c | 54 -
1 file changed, 8 insertions(+), 46 deletions(-)
diff --git a/gcc/tree-vect-slp.c b/gcc/tree-vect-slp.c
index e43d03b43de..f6331eeea86 100644
--- a/gcc/tree-vect-slp.c
+++ b/gcc/tree-vect-slp.c
@@ -562,52 +562,6 @@ again:
/* Swap operands. */
if (swapped)
{
- if (first_op_cond)
- {
- /* If there are already uses of this stmt in a SLP instance then
-we've committed to the operand order and can't swap it. */
- if (STMT_VINFO_NUM_SLP_USES (stmt_info) != 0)
- {
- if (dump_enabled_p ())
- dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
-"Build SLP failed: cannot swap operands of "
-"shared stmt %G", stmt_info->stmt);
- return -1;
- }
-
- /* To get rid of this swapping we have to move the stmt code
-to the SLP tree as well (and gather it here per stmt). */
- gassign *stmt = as_a (stmt_info->stmt);
- tree cond = gimple_assign_rhs1 (stmt);
- enum tree_code code = TREE_CODE (cond);
-
- /* Swap. */
- if (*swap == 1)
- {
- swap_ssa_operands (stmt, &TREE_OPERAND (cond, 0),
-&TREE_OPERAND (cond, 1));
- TREE_SET_CODE (cond, swap_tree_comparison (code));
- }
- /* Invert. */
- else
- {
- swap_ssa_operands (stmt, gimple_assign_rhs2_ptr (stmt),
-gimple_assign_rhs3_ptr (stmt));
- if (STMT_VINFO_REDUC_IDX (stmt_info) == 1)
- STMT_VINFO_REDUC_IDX (stmt_info) = 2;
- else if (STMT_VINFO_REDUC_IDX (stmt_info) == 2)
- STMT_VINFO_REDUC_IDX (stmt_info) = 1;
- bool honor_nans = HONOR_NANS (TREE_OPERAND (cond, 0));
- code = invert_tree_comparison (TREE_CODE (cond), honor_nans);
- gcc_assert (code != ERROR_MARK);
- TREE_SET_CODE (cond, code);
- }
- }
- else
- {
- /* Commutative ops need not reflect swapping, ops are in
-the SLP tree. */
- }
if (dump_enabled_p ())
dump_printf_loc (MSG_NOTE, vect_location,
"swapped operands to match def types in %G",
@@ -1815,6 +1769,14 @@ vect_slp_rearrange_stmts (slp_tree node, unsigned int
group_size,
if (SLP_TREE_SCALAR_STMTS (node).exists ())
{
gcc_assert (group_size == SLP_TREE_SCALAR_STMTS (node).length ());
+ /* ??? Computation nodes are isomorphic and need no rearrangement.
+This is a quick hack to cover those where rearrangement breaks
+semantics because only the first stmt is guaranteed to have the
+correct operation code due to others being swapped or inverted. */
+ stmt_vec_info first = SLP_TREE_SCALAR_STMTS (node)[0];
+ if (is_gimple_assign (first->stmt)
+ && gimple_assign_rhs_code (first->stmt) == COND_EXPR)
+ return;
vec tmp_stmts;
tmp_stmts.create (group_size);
tmp_stmts.quick_grow (group_size);
--
2.16.4
[PATCH 0/2] arm: Enable assembling when testing MVE
Hi, This patch series changes all MVE tests into assembly tests so we check whether the generated assembly is syntactically correct. The first patch of the series fixes an issue this caught where the instructions don't allow destination and source registers to be the same. Andre Vieira (2): arm: Add earlyclobber to MVE instructions that require it testsuite, arm: Change tests to assemble
[PATCH 1/2] arm: Add earlyclobber to MVE instructions that require it
Hi, This patch adds an earlyclobber to the MVE instructions that require it and were missing it. These are vrev64 and 32-bit element variants of vcadd, vhcadd vcmul, vmull[bt] and vqdmull[bt]. Regression tested on arm-none-eabi. Is this OK for trunk? Cheers, Andre 2020-03-23 Andre Vieira * config/arm/mve.md (earlyclobber_32): New mode attribute. (mve_vrev64q_*, mve_vcaddq*, mve_vhcaddq_*, mve_vcmulq_*, mve_vmull[bt]q_*, mve_vqdmull[bt]q_*): Add appropriate early clobbers. diff --git a/gcc/config/arm/mve.md b/gcc/config/arm/mve.md index 2e28d9d8408127dd52b9d16c772e7f27a47d390a..0cd67962a2641a3be46fe67819e093c0a712751b 100644 --- a/gcc/config/arm/mve.md +++ b/gcc/config/arm/mve.md @@ -411,6 +411,8 @@ (define_mode_attr MVE_B_ELEM [ (V16QI "V16QI") (V8HI "V8QI") (V4SI "V4QI")]) (define_mode_attr MVE_H_ELEM [ (V8HI "V8HI") (V4SI "V4HI")]) (define_mode_attr V_sz_elem1 [(V16QI "b") (V8HI "h") (V4SI "w") (V8HF "h") (V4SF "w")]) +(define_mode_attr earlyclobber_32 [(V16QI "=w") (V8HI "=w") (V4SI "=&w") + (V8HF "=w") (V4SF "=&w")]) (define_int_iterator VCVTQ_TO_F [VCVTQ_TO_F_S VCVTQ_TO_F_U]) (define_int_iterator VMVNQ_N [VMVNQ_N_U VMVNQ_N_S]) @@ -856,7 +858,7 @@ (define_insn "mve_vrndaq_f" ;; (define_insn "mve_vrev64q_f" [ - (set (match_operand:MVE_0 0 "s_register_operand" "=w") + (set (match_operand:MVE_0 0 "s_register_operand" "=&w") (unspec:MVE_0 [(match_operand:MVE_0 1 "s_register_operand" "w")] VREV64Q_F)) ] @@ -967,7 +969,7 @@ (define_insn "mve_vcvtq_to_f_" ;; (define_insn "mve_vrev64q_" [ - (set (match_operand:MVE_2 0 "s_register_operand" "=w") + (set (match_operand:MVE_2 0 "s_register_operand" "=&w") (unspec:MVE_2 [(match_operand:MVE_2 1 "s_register_operand" "w")] VREV64Q)) ] @@ -1541,7 +1543,7 @@ (define_insn "mve_vbrsrq_n_" ;; (define_insn "mve_vcaddq_rot270_" [ - (set (match_operand:MVE_2 0 "s_register_operand" "=w") + (set (match_operand:MVE_2 0 "s_register_operand" "") (unspec:MVE_2 [(match_operand:MVE_2 1 "s_register_operand" "w") (match_operand:MVE_2 2 "s_register_operand" "w")] VCADDQ_ROT270)) @@ -1556,7 +1558,7 @@ (define_insn "mve_vcaddq_rot270_" ;; (define_insn "mve_vcaddq_rot90_" [ - (set (match_operand:MVE_2 0 "s_register_operand" "=w") + (set (match_operand:MVE_2 0 "s_register_operand" "") (unspec:MVE_2 [(match_operand:MVE_2 1 "s_register_operand" "w") (match_operand:MVE_2 2 "s_register_operand" "w")] VCADDQ_ROT90)) @@ -1841,7 +1843,7 @@ (define_insn "mve_vhaddq_" ;; (define_insn "mve_vhcaddq_rot270_s" [ - (set (match_operand:MVE_2 0 "s_register_operand" "=w") + (set (match_operand:MVE_2 0 "s_register_operand" "") (unspec:MVE_2 [(match_operand:MVE_2 1 "s_register_operand" "w") (match_operand:MVE_2 2 "s_register_operand" "w")] VHCADDQ_ROT270_S)) @@ -1856,7 +1858,7 @@ (define_insn "mve_vhcaddq_rot270_s" ;; (define_insn "mve_vhcaddq_rot90_s" [ - (set (match_operand:MVE_2 0 "s_register_operand" "=w") + (set (match_operand:MVE_2 0 "s_register_operand" "") (unspec:MVE_2 [(match_operand:MVE_2 1 "s_register_operand" "w") (match_operand:MVE_2 2 "s_register_operand" "w")] VHCADDQ_ROT90_S)) @@ -2096,7 +2098,7 @@ (define_insn "mve_vmulhq_" ;; (define_insn "mve_vmullbq_int_" [ - (set (match_operand: 0 "s_register_operand" "=w") + (set (match_operand: 0 "s_register_operand" "") (unspec: [(match_operand:MVE_2 1 "s_register_operand" "w") (match_operand:MVE_2 2 "s_register_operand" "w")] VMULLBQ_INT)) @@ -2111,7 +2113,7 @@ (define_insn "mve_vmullbq_int_" ;; (define_insn "mve_vmulltq_int_" [ - (set (match_operand: 0 "s_register_operand" "=w") + (set (match_operand: 0 "s_register_operand" "") (unspec: [(match_operand:MVE_2 1 "s_register_operand" "w") (match_operand:MVE_2 2 "s_register_operand" "w")] VMULLTQ_INT)) @@ -2621,7 +2623,7 @@ (define_insn "mve_vbicq_n_" ;; (define_insn "mve_vcaddq_rot270_f" [ - (set (match_operand:MVE_0 0 "s_register_operand" "=w") + (set (match_operand:MVE_0 0 "s_register_operand" "") (unspec:MVE_0 [(match_operand:MVE_0 1 "s_register_operand" "w") (match_operand:MVE_0 2 "s_register_operand" "w")] VCADDQ_ROT270_F)) @@ -2636,7 +2638,7 @@ (define_insn "mve_vcaddq_rot270_f" ;; (define_insn "mve_vcaddq_rot90_f" [ - (set (match_operand:MVE_0 0 "s_register_operand" "=w") + (set (match_operand:MVE_0 0 "s_register_operand" "") (unspec:MVE_0 [(match_operand:MVE_0 1 "s_register_operand" "w") (match_operand:MVE_0 2 "s_register_operand" "w")] VCADDQ_ROT90_F)) @@ -2831,7 +2833,7 @@ (define_insn "mve_vcmpneq_n
Re: [PATCH v3] c++: template keyword in a typename-specifier [PR94057]
On 3/20/20 7:02 PM, Marek Polacek wrote:
On Fri, Mar 20, 2020 at 02:12:49PM -0400, Jason Merrill wrote:
On 3/20/20 1:06 PM, Marek Polacek wrote:
Wonderful. I've added a bunch of tests, and some from the related DRs too.
But I had a problem with the class-or-decltype case: if we have
template struct D : T::template B::template C {};
then we still require all the 'template' keywords here (as does clang). So I'm
kind of confused, but I don't think it's a big deal right now.
This seems related enough that I'd like to fix it at the same time; why
doesn't your patch fix it? Is it because typename_p is false?
Ah, I was mistaken. Of course we need the template keyword here: it's a member
of an
unknown specialization!
That's why it's needed in contexts where we don't know whether or not
we're naming a type. But where we do know that, as in a base-specifier,
it isn't necessary. This is exactly DR 1710: "The keyword template is
optional in a ... class-or-decltype (Clause 11.7 [class.derived])"
Jason
[PATCH][PPC64] [PR88877]
Attached patch fixes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88877.
ChangeLog Entry.
2020-03-23 Kamlesh Kumar
* rtl.h : Defined Tuple for bundling rtx, mode and
unsignedness default as 0
Added Extra argument (unsignedp) in emit_library_call and
emit_library_call_value.
* except.c : Likewise.
* explow.c : Likewise.
* expmed.c : Likewise.
* expr.c : Likewise.
* optabs.c : Likewise.
* asan.c : Likewise.
* builtins.c : Likewise.
* calls.c : Likewise.
* cfgexpand.c : Likewise.
* config/aarch64/aarch64.c : Likewise.
* config/aarch64/aarch64.h : Likewise.
* config/aarch64/atomics.md : Likewise.
* config/alpha/alpha.c : Likewise.
* config/arc/arc.c : Likewise.
* config/arc/elf.h : Likewise.
* config/arc/linux.h : Likewise.
* config/arm/arm.c : Likewise.
* config/bfin/bfin.md : Likewise.
* config/c6x/c6x.c : Likewise.
* config/csky/csky.c : Likewise.
* config/frv/frv.c : Likewise.
* config/i386/i386-expand.c : Likewise.
* config/i386/i386.c : Likewise.
* config/ia64/ia64.c : Likewise.
* config/ia64/ia64.md : Likewise.
* config/m32r/m32r.c : Likewise.
* config/m68k/linux.h : Likewise.
* config/m68k/m68k.c : Likewise.
* config/microblaze/microblaze.c : Likewise.
* config/mips/mips.h : Likewise.
* config/mips/sdemtk.h : Likewise.
* config/nds32/nds32.h : Likewise.
* config/nios2/nios2.c : Likewise.
* config/or1k/or1k.c : Likewise.
* config/pa/pa.c : Likewise.
* config/pa/pa.md : Likewise.
* config/pru/pru.c : Likewise.
* config/riscv/riscv.h : Likewise.
* config/riscv/riscv.md : Likewise.
* config/rl78/rl78.c : Likewise.
* config/rs6000/rs6000-string.c : Likewise.
* config/rs6000/rs6000.c : Likewise.
* config/rs6000/rs6000.md : Likewise.
* config/rs6000/vsx.md : Likewise.
* config/sh/sh.c : Likewise.
* config/sparc/sparc.c : Likewise.
* config/tilegx/tilegx.c : Likewise.
* config/tilepro/tilepro.c : Likewise.
* config/visium/visium.c : Likewise.
* config/xtensa/xtensa.c : Likewise.
* testsuite/gcc.target/powerpc/pr88877.c : Newtest
diff --git a/gcc/asan.c b/gcc/asan.c
index cc8f9122e3d..ec4d6bdc161 100644
--- a/gcc/asan.c
+++ b/gcc/asan.c
@@ -1488,7 +1488,7 @@ asan_emit_stack_protection (rtx base, rtx pbase, unsigned int alignb,
ret = emit_library_call_value (ret, NULL_RTX, LCT_NORMAL, ptr_mode,
GEN_INT (asan_frame_size
+ base_align_bias),
- TYPE_MODE (pointer_sized_int_node));
+ TYPE_MODE (pointer_sized_int_node), 0);
/* __asan_stack_malloc_[n] returns a pointer to fake stack if succeeded
and NULL otherwise. Check RET value is NULL here and jump over the
BASE reassignment in this case. Otherwise, reassign BASE to RET. */
@@ -1615,7 +1615,7 @@ asan_emit_stack_protection (rtx base, rtx pbase, unsigned int alignb,
emit_library_call (ret, LCT_NORMAL, ptr_mode, addr, ptr_mode,
GEN_INT (asan_frame_size + base_align_bias),
TYPE_MODE (pointer_sized_int_node),
- orig_addr, ptr_mode);
+ orig_addr, ptr_mode, 0);
}
lab = gen_label_rtx ();
emit_jump (lab);
@@ -1715,7 +1715,7 @@ asan_emit_allocas_unpoison (rtx top, rtx bot, rtx_insn *before)
top = convert_memory_address (ptr_mode, top);
bot = convert_memory_address (ptr_mode, bot);
emit_library_call (ret, LCT_NORMAL, ptr_mode,
- top, ptr_mode, bot, ptr_mode);
+ top, ptr_mode, bot, ptr_mode, 0);
do_pending_stack_adjust ();
rtx_insn *insns = get_insns ();
diff --git a/gcc/builtins.c b/gcc/builtins.c
index 53bae599d3e..99fa50bd515 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -2979,7 +2979,7 @@ expand_builtin_powi (tree exp, rtx target)
target = emit_library_call_value (optab_libfunc (powi_optab, mode),
target, LCT_CONST, mode,
-op0, mode, op1, mode2);
+op0, mode, op1, mode2, 0);
return target;
}
@@ -5858,7 +5858,7 @@ expand_asan_emit_allocas_unpoison (tree exp)
OPTAB_LIB_WIDEN);
rtx ret = init_one_libfunc ("__asan_allocas_unpoison");
ret = emit_library_call_value (ret, NULL_RTX, LCT_NORMAL, ptr_mode,
- top, ptr_mode, bot, ptr_mode);
+ top, ptr_mode, bot, ptr_mode, 0);
return ret;
}
diff --git a/gcc/calls.c b/gcc/calls.c
index 4c3a8f3c215..20324ff6f04 100644
--- a/gcc/calls.c
+++ b/gcc/calls.c
@@ -5247,7 +5247,7 @@ emit_library_call_value_1 (int retval, rtx orgfun, rtx value,
{
rtx val = args[i].first;
function_arg_info arg (args[i].second, /*named=*/true);
- int unsigned_p = 0;
+ int unsigned_p = GET_THIRD(args[i]);
/* We cannot convert the arg value to the mode the library wants here;
must do it earlier wh
Re: [PATCH] avoid -Wredundant-tags on a first declaration in use (PR 93824)
On 3/21/20 5:59 PM, Martin Sebor wrote: + /* Diagnose class/struct/union mismatches. IS_DECLARATION is false +for alias definition. */ + bool decl_class = (is_declaration +&& cp_parser_declares_only_class_p (parser)); cp_parser_check_class_key (parser, key_loc, tag_type, type, false, cp_parser_declares_only_class_p (parser)); Don't you need to use the new variable? Don't your testcases exercise this? + /* When TYPE is the use of an implicit specialization of a previously +declared template set TYPE_DECL to the type of the primary template +for the specialization and look it up in CLASS2LOC below. For uses +of explicit or partial specializations TYPE_DECL already points to +the declaration of the specialization. +IS_USE is clear so that the type of an implicit instantiation rather +than that of a partial specialization is determined. */ + type_decl = TREE_TYPE (type_decl); + if (TREE_CODE (type_decl) != TEMPLATE_DECL) + type_decl = TYPE_MAIN_DECL (type_decl); The comment is no longer relevant to the code. The remaining code also seems like it would have no effect; we already know type_decl is TYPE_MAIN_DECL (type). Jason
Re: [Patch, 9/10 Regression] fortran: ICE in build_entry_thunks PR93814
Apologies, 2nd attempt:
gcc/fortran/ChangeLog:
Steven G. Kargl
PR fortran/93814
* resolve.c (gfc_verify_binding_labels): Handle symbols with
the subroutine attribute separately from symbols with the
function attribute.
gcc/testsuite/ChanheLog:
Mark Eggleston
PR fortran/93814
* gfortran.dg/pr93814.f90: New test.
OK to commit?
On 22/03/2020 17:46, Thomas Koenig wrote:
Hi Mark,
Please find attached Steve Kargl's fix for PR93814.
The attached patch does not match the ChangeLog; it seems to
be for PR93484.
Regards
Thomas
--
https://www.codethink.co.uk/privacy.html
>From 743b915bfef6c798e3b001ff8759739e9fc52ec1 Mon Sep 17 00:00:00 2001
From: Mark Eggleston
Date: Fri, 21 Feb 2020 10:52:52 +
Subject: [PATCH] fortran: ICE in build_entry_thunks PR93814
Patch provided by Steve Kargl. Test case provided by G. Steinmetz.
gcc/fortran/ChangeLog:
PR fortran/93814
* resolve.c (gfc_verify_binding_labels): Handle symbols with
the subroutine attribute separately from symbols with the
function attribute.
gcc/testsuite/ChanheLog:
PR fortran/93814
* gfortran.dg/pr93814.f90: New test.
---
gcc/fortran/resolve.c | 23 ---
gcc/testsuite/gfortran.dg/pr93814.f90 | 8
2 files changed, 28 insertions(+), 3 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/pr93814.f90
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 8f5267fde05..81d855eaa54 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -12236,9 +12236,26 @@ gfc_verify_binding_labels (gfc_symbol *sym)
return;
}
- if ((sym->attr.function || sym->attr.subroutine)
- && ((gsym->type != GSYM_SUBROUTINE && gsym->type != GSYM_FUNCTION)
- || (gsym->defined && sym->attr.if_source != IFSRC_IFBODY))
+ if (sym->attr.function
+ && (gsym->type != GSYM_FUNCTION
+ || (gsym->defined && sym->attr.if_source != IFSRC_IFBODY))
+ && (sym != gsym->ns->proc_name)
+ && (module != gsym->mod_name
+ || strcmp (gsym->sym_name, sym->name) != 0
+ || (module && strcmp (module, gsym->mod_name) != 0)))
+{
+ /* Print an error if the procedure is defined multiple times; we have to
+ exclude references to the same procedure via module association or
+ multiple checks for the same procedure. */
+ gfc_error ("Procedure %qs with binding label %qs at %L uses the same "
+ "global identifier as entity at %L", sym->name,
+ sym->binding_label, &sym->declared_at, &gsym->where);
+ sym->binding_label = NULL;
+}
+
+ if (sym->attr.subroutine
+ && (gsym->type != GSYM_SUBROUTINE
+ || (gsym->defined && sym->attr.if_source != IFSRC_IFBODY))
&& (sym != gsym->ns->proc_name && sym->attr.entry == 0)
&& (module != gsym->mod_name
|| strcmp (gsym->sym_name, sym->name) != 0
diff --git a/gcc/testsuite/gfortran.dg/pr93814.f90 b/gcc/testsuite/gfortran.dg/pr93814.f90
new file mode 100644
index 000..9eb818ca478
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr93814.f90
@@ -0,0 +1,8 @@
+! { dg-do compile }
+! Test case by G. Steinmetz
+
+function f() bind(c)
+character :: f, g ! { dg-error "1" }
+entry g() bind(c) ! { dg-error "Procedure 'g' with binding label 'g'" }
+end
+
--
2.11.0
Re: [PATCH] Check endianess detection.
Hi.
There's a patch draft that will do the proper versioning of API.
It's a subject for discussion.
Martin
>From b3f88adc91c36649bec3ed125b3e36ee89143bab Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Mon, 23 Mar 2020 16:01:29 +0100
Subject: [PATCH] Introduce ld_plugin_symbol_v2 for LTO plugin.
---
include/plugin-api.h| 40 ++---
lto-plugin/lto-plugin.c | 50 +
2 files changed, 68 insertions(+), 22 deletions(-)
diff --git a/include/plugin-api.h b/include/plugin-api.h
index 673f136ce68..34ccae85ff8 100644
--- a/include/plugin-api.h
+++ b/include/plugin-api.h
@@ -87,25 +87,30 @@ struct ld_plugin_symbol
{
char *name;
char *version;
- /* This is for compatibility with older ABIs. The older ABI defined
- only 'def' field. */
-#ifdef __BIG_ENDIAN__
- char unused;
- char section_kind;
- char symbol_type;
- char def;
-#else
- char def;
- char symbol_type;
- char section_kind;
- char unused;
-#endif
+ int def;
int visibility;
uint64_t size;
char *comdat_key;
int resolution;
};
+/* A symbol belonging to an input file managed by the plugin library
+ (version 2). */
+
+struct ld_plugin_symbol_v2
+{
+ char *name;
+ char *version;
+ int def;
+ int visibility;
+ uint64_t size;
+ char *comdat_key;
+ int resolution;
+ char symbol_type;
+ char section_kind;
+ uint16_t unused;
+};
+
/* An object's section. */
struct ld_plugin_section
@@ -237,6 +242,14 @@ enum ld_plugin_status
(*ld_plugin_add_symbols) (void *handle, int nsyms,
const struct ld_plugin_symbol *syms);
+/* The linker's interface for adding symbols from a claimed input file
+ (version 2). */
+
+typedef
+enum ld_plugin_status
+(*ld_plugin_add_symbols_v2) (void *handle, int nsyms,
+ const struct ld_plugin_symbol_v2 *syms);
+
/* The linker's interface for getting the input file information with
an open (possibly re-opened) file descriptor. */
@@ -475,6 +488,7 @@ struct ld_plugin_tv
ld_plugin_register_all_symbols_read tv_register_all_symbols_read;
ld_plugin_register_cleanup tv_register_cleanup;
ld_plugin_add_symbols tv_add_symbols;
+ld_plugin_add_symbols_v2 tv_add_symbols_v2;
ld_plugin_get_symbols tv_get_symbols;
ld_plugin_add_input_file tv_add_input_file;
ld_plugin_message tv_message;
diff --git a/lto-plugin/lto-plugin.c b/lto-plugin/lto-plugin.c
index ca6c84a1ffd..ea3faa89205 100644
--- a/lto-plugin/lto-plugin.c
+++ b/lto-plugin/lto-plugin.c
@@ -114,6 +114,7 @@ struct plugin_symtab
int nsyms;
struct sym_aux *aux;
struct ld_plugin_symbol *syms;
+ struct ld_plugin_symbol_v2 *syms_v2;
unsigned long long id;
};
@@ -163,7 +164,8 @@ static ld_plugin_register_cleanup register_cleanup;
static ld_plugin_add_input_file add_input_file;
static ld_plugin_add_input_library add_input_library;
static ld_plugin_message message;
-static ld_plugin_add_symbols add_symbols, add_symbols_v2;
+static ld_plugin_add_symbols add_symbols;
+static ld_plugin_add_symbols_v2 add_symbols_v2;
static struct plugin_file_info *claimed_files = NULL;
static unsigned int num_claimed_files = 0;
@@ -290,8 +292,6 @@ parse_table_entry (char *p, struct ld_plugin_symbol *entry,
else
entry->comdat_key = xstrdup (entry->comdat_key);
- entry->unused = entry->section_kind = entry->symbol_type = 0;
-
t = *p;
check (t <= 4, LDPL_FATAL, "invalid symbol kind found");
entry->def = translate_kind[t];
@@ -320,7 +320,7 @@ parse_table_entry (char *p, struct ld_plugin_symbol *entry,
Returns the address of the next entry. */
static char *
-parse_table_entry_extension (char *p, struct ld_plugin_symbol *entry)
+parse_table_entry_extension (char *p, struct ld_plugin_symbol_v2 *entry)
{
unsigned char t;
enum ld_plugin_symbol_type symbol_types[] =
@@ -384,9 +384,15 @@ parse_symtab_extension (char *data, char *end, struct plugin_symtab *out)
- section_kind
. */
+ out->syms_v2 = xrealloc (out->syms_v2,
+ out->nsyms * sizeof (struct ld_plugin_symbol_v2));
+ memset (out->syms_v2, 0, out->nsyms * sizeof (struct ld_plugin_symbol_v2));
+
if (version == 1)
-for (i = 0; i < out->nsyms; i++)
- data = parse_table_entry_extension (data, &out->syms[i]);
+{
+ for (i = 0; i < out->nsyms; i++)
+ data = parse_table_entry_extension (data, &out->syms_v2[i]);
+}
}
/* Free all memory that is no longer needed after writing the symbol
@@ -409,6 +415,11 @@ free_1 (struct plugin_file_info *files, unsigned num_files)
}
free (symtab->syms);
symtab->syms = NULL;
+ if (symtab->syms_v2)
+ {
+ free (symtab->syms_v2);
+ symtab->syms_v2 = NULL;
+ }
}
}
@@ -519,6 +530,11 @@ free_symtab (struct plugin_symtab *symtab)
{
free (symtab->syms);
symtab->syms = NULL;
+ if (symtab->syms_v2)
+{
+ free (symtab->syms_v2);
+ symtab->syms_v2 = NULL;
+}
free (symtab->aux);
symtab->aux = NULL;
Re: [PATCH v2] c++: Fix wrong no post-decrement operator error in template [PR94190]
On Tue, Mar 17, 2020 at 04:05:31PM -0400, Jason Merrill wrote:
> On 3/16/20 10:01 PM, Marek Polacek wrote:
> > On Mon, Mar 16, 2020 at 05:12:15PM -0400, Jason Merrill wrote:
> > > On 3/16/20 10:57 AM, Marek Polacek wrote:
> > > > Now that convert_like creates an IMPLICIT_CONV_EXPR when it converts
> > > > something that involves a class in a template, we must be prepared to
> > > > handle it. In this test, we have a class S and we're converting it
> > > > to long int& using a user-defined conversion since we're performing
> > > > -- on it. So cp_build_unary_op/POSTDECREMENT_EXPR calls
> > > > build_expr_type_conversion which gets the IMPLICIT_CONV_EXPR. Before
> > > > the convert_like change it got *S::operator long int &(&b) whose type
> > > > is long int but now it gets IMPLICIT_CONV_EXPR(b) whose type
> > > > is a reference type.
> > >
> > > So you need to make sure that your IMPLICIT_CONV_EXPR gets
> > > convert_from_reference'd at some point.
> >
> > Perhaps like the following?
> >
> > Bootstrapped/regtested on x86_64-linux, built Boost/cmcstl2.
> >
> > -- >8 --
> > Now that convert_like creates an IMPLICIT_CONV_EXPR when it converts
> > something that involves a class in a template, we must be prepared to
> > handle it. In this test, we have a class S and we're converting it
> > to long int& using a user-defined conversion since we're performing
> > -- on it. So cp_build_unary_op/POSTDECREMENT_EXPR calls
> > build_expr_type_conversion which gets the IMPLICIT_CONV_EXPR. Before
> > the convert_like change it got *S::operator long int &(&b) whose type
> > is long int but now it gets IMPLICIT_CONV_EXPR(b) whose type
> > is a reference type. But the !MAYBE_CLASS_TYPE_P switch doesn't handle
> > reference types and so we complain.
> >
> > Fixed by calling convert_from_reference on the result of convert_like.
> >
> > PR c++/94190 - wrong no post-decrement operator error in template.
> > * call.c (build_new_op_1): Use convert_from_reference on the result
> > of convert_like.
>
> The result of convert_like should already be dereferenced in this case. I
> think convert_like should only return a bare reference for ck_ref_bind,
> where we're explicitly requesting one.
I tried to adjust all the appropriate return ...; in convert_like to return
convert_from_reference (...); and then remove unnecessary calls to
convert_from_reference after a call to convert_like elsewhere in the codebase,
but that fails very badly.
But it seems we can use convert_from_reference in convert_like when returning
the new IMPLICIT_CONV_EXPR, like this:
Bootstrapped/regtested on x86_64-linux, ok for trunk?
-- >8 --
Now that convert_like creates an IMPLICIT_CONV_EXPR when it converts
something that involves a class in a template, we must be prepared to
handle it. In this test, we have a class S and we're converting it
to long int& using a user-defined conversion since we're performing
-- on it. So cp_build_unary_op/POSTDECREMENT_EXPR calls
build_expr_type_conversion which gets the IMPLICIT_CONV_EXPR. Before
the convert_like change it got *S::operator long int &(&b) whose type
is long int but now it gets IMPLICIT_CONV_EXPR(b) whose type
is a reference type. But the !MAYBE_CLASS_TYPE_P switch doesn't handle
reference types and so we complain.
Fixed by calling convert_from_reference on the result of convert_like.
PR c++/94190 - wrong no post-decrement operator error in template.
* call.c (convert_like_real): Use convert_from_reference on the result.
* g++.dg/conversion/op7.C: New test.
---
gcc/cp/call.c | 5 -
gcc/testsuite/g++.dg/conversion/op7.C | 22 ++
2 files changed, 26 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/g++.dg/conversion/op7.C
diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 65a3ea35dee..bae4b2c0f52 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -7389,7 +7389,10 @@ convert_like_real (conversion *convs, tree expr, tree
fn, int argnum,
if (processing_template_decl
&& convs->kind != ck_identity
&& (CLASS_TYPE_P (totype) || CLASS_TYPE_P (TREE_TYPE (expr
-return build1 (IMPLICIT_CONV_EXPR, totype, expr);
+{
+ expr = build1 (IMPLICIT_CONV_EXPR, totype, expr);
+ return convs->kind == ck_ref_bind ? expr : convert_from_reference (expr);
+}
switch (convs->kind)
{
diff --git a/gcc/testsuite/g++.dg/conversion/op7.C
b/gcc/testsuite/g++.dg/conversion/op7.C
new file mode 100644
index 000..c6401d109b4
--- /dev/null
+++ b/gcc/testsuite/g++.dg/conversion/op7.C
@@ -0,0 +1,22 @@
+// PR c++/94190 - wrong no post-decrement operator error in template.
+
+struct S { operator long & (); } b;
+
+template void
+foo ()
+{
+ b--;
+ ++b;
+ --b;
+ b++;
+ !b;
+ ~b;
+ +b;
+ -b;
+}
+
+void
+bar ()
+{
+ foo<0> ();
+}
base-commit: a3586eeb88414e77c7cccb69362b8d04562536b6
--
Marek Polacek • Red Hat, Inc. • 300 A St, Boston, MA
Re: [stage1] [PATCH] Make target_clones resolver fn static if possible.
Hi.
The patch was supposed to be a next stage1 material, but then PR94271
was reported. The patch for it includes the hunk and one more that
leaves unique_name and resolution for the "default" clone. That will
align the symbol with other target clones and it's name will become
privatized eventually in LTO.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
>From 1431a34f70128bdce59c94dad1d10f91673f63eb Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Thu, 16 Jan 2020 10:38:41 +0100
Subject: [PATCH] Make target_clones resolver fn static if possible.
gcc/ChangeLog:
2020-03-17 Martin Liska
PR target/93274
PR ipa/94271
* config/i386/i386-features.c (make_resolver_func): Drop
public flag for resolver.
* config/rs6000/rs6000.c (make_resolver_func): Add comdat
group for resolver and drop public flag if possible.
* multiple_target.c (create_dispatcher_calls): Drop unique_name
and resolution as we want to enable LTO privatization of the default
symbol.
gcc/testsuite/ChangeLog:
2020-03-17 Martin Liska
PR target/93274 PR lto/94271
* gcc.target/i386/pr81213-2.c: New test.
* gcc.target/i386/pr81213.c: Add additional source.
* gcc.dg/lto/pr94271_0.c: New test.
* gcc.dg/lto/pr94271_1.c: New test.
---
gcc/config/i386/i386-features.c | 3 +++
gcc/config/rs6000/rs6000.c| 12
gcc/multiple_target.c | 4
gcc/testsuite/gcc.dg/lto/pr94271_0.c | 13 +
gcc/testsuite/gcc.dg/lto/pr94271_1.c | 17 +
gcc/testsuite/gcc.target/i386/pr81213-2.c | 11 +++
gcc/testsuite/gcc.target/i386/pr81213.c | 7 +--
7 files changed, 61 insertions(+), 6 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/lto/pr94271_0.c
create mode 100644 gcc/testsuite/gcc.dg/lto/pr94271_1.c
create mode 100644 gcc/testsuite/gcc.target/i386/pr81213-2.c
diff --git a/gcc/config/i386/i386-features.c b/gcc/config/i386/i386-features.c
index 6528832487e..3c70279dc7c 100644
--- a/gcc/config/i386/i386-features.c
+++ b/gcc/config/i386/i386-features.c
@@ -2777,6 +2777,9 @@ make_resolver_func (const tree default_decl,
DECL_COMDAT (decl) = 1;
make_decl_one_only (decl, DECL_ASSEMBLER_NAME (decl));
}
+ else
+TREE_PUBLIC (ifunc_alias_decl) = 0;
+
/* Build result decl and add to function_decl. */
t = build_decl (UNKNOWN_LOCATION, RESULT_DECL, NULL_TREE, ptr_type_node);
DECL_CONTEXT (t) = decl;
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 07f7cf516ba..7505a0e1e8e 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -23894,6 +23894,18 @@ make_resolver_func (const tree default_decl,
DECL_INITIAL (decl) = make_node (BLOCK);
DECL_STATIC_CONSTRUCTOR (decl) = 0;
+ if (DECL_COMDAT_GROUP (default_decl)
+ || TREE_PUBLIC (default_decl))
+{
+ /* In this case, each translation unit with a call to this
+ versioned function will put out a resolver. Ensure it
+ is comdat to keep just one copy. */
+ DECL_COMDAT (decl) = 1;
+ make_decl_one_only (decl, DECL_ASSEMBLER_NAME (decl));
+}
+ else
+TREE_PUBLIC (dispatch_decl) = 0;
+
/* Build result decl and add to function_decl. */
tree t = build_decl (UNKNOWN_LOCATION, RESULT_DECL, NULL_TREE, ptr_type_node);
DECL_CONTEXT (t) = decl;
diff --git a/gcc/multiple_target.c b/gcc/multiple_target.c
index cccfd2774db..c1cfe8ff978 100644
--- a/gcc/multiple_target.c
+++ b/gcc/multiple_target.c
@@ -178,10 +178,6 @@ create_dispatcher_calls (struct cgraph_node *node)
node->externally_visible = false;
node->forced_by_abi = false;
node->set_section (NULL);
- node->unique_name = ((node->resolution == LDPR_PREVAILING_DEF_IRONLY
- || node->resolution == LDPR_PREVAILING_DEF_IRONLY_EXP)
- && !flag_incremental_link);
- node->resolution = LDPR_PREVAILING_DEF_IRONLY;
DECL_ARTIFICIAL (node->decl) = 1;
node->force_output = true;
diff --git a/gcc/testsuite/gcc.dg/lto/pr94271_0.c b/gcc/testsuite/gcc.dg/lto/pr94271_0.c
new file mode 100644
index 000..2ce7d65411a
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/lto/pr94271_0.c
@@ -0,0 +1,13 @@
+/* PR lto/94271 */
+/* { dg-lto-do link } */
+
+int a;
+
+static int __attribute__ ((target_clones ("default", "avx512f"))) fast_clamp ()
+{}
+
+void
+c ()
+{
+ a = fast_clamp ();
+}
diff --git a/gcc/testsuite/gcc.dg/lto/pr94271_1.c b/gcc/testsuite/gcc.dg/lto/pr94271_1.c
new file mode 100644
index 000..db9bc9df6db
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/lto/pr94271_1.c
@@ -0,0 +1,17 @@
+int aa;
+
+static inline int __attribute__ ((target_clones ("default", "avx512f")))
+fast_clamp ()
+{}
+
+void
+b ()
+{
+ aa = fast_clamp ();
+}
+
+int
+main ()
+{
+ return 0;
+}
diff --git a/gcc/testsuite/gcc.target/i386/pr81213-2.c b/gcc/testsuite/gcc.target/i386/pr81213-2.c
new file mode 100644
index 000..a80622cb184
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386
Re: [PATCH] Check endianess detection.
On March 23, 2020 1:43:30 PM GMT+01:00, "Martin Liška" wrote: >On 3/23/20 11:35 AM, Jakub Jelinek wrote: >> I don't think so. That is about the target, but you care about the >host. > >I see. > >> Wouldn't it be much easier not to do this and simply use macros for >bits >> from the full 32-bit value (and use shifts)? > >That would make the current small hack even bigger. Note that >plugin-api.h >provides reasonable ways how to extend the API. That said, I incline >to implement lto_plugin_symbols_v2 and use it in the corresponding >function >add_symbols_v2. > >@Richi: Can you please express your opinion? Since lto-plugin is a host tool it is compiled by the system compiler which means we either have to properly detect host endianess or do shifting, leaving the layout unchanged. Richard. >Thanks, >Martin
Re: [RFC] Should widening_mul should consider block frequency?
On Mon, Mar 23, 2020 at 10:53 AM Yangfei (Felix) wrote:
>
> Hi,
>
> I created a bug for this issue:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94269
> Looks like widening_mul phase may move multiply instruction from outside
> the loop to inside the loop, merging with one add instruction inside the loop.
> This will increase the cost of the loop at least on aarch64 (4 cycles vs 1
> cycle). I think widening_mul should consider block frequency when doing such
> a combination.
> I mean something like:
As written in the PR I'd follow fma generation and restrict defs to the same BB.
Richard.
> diff --git a/gcc/tree-ssa-math-opts.c b/gcc/tree-ssa-math-opts.c
> index 54ba035..4439452 100644
> --- a/gcc/tree-ssa-math-opts.c
> +++ b/gcc/tree-ssa-math-opts.c
> @@ -2721,7 +2721,10 @@ convert_plusminus_to_widen (gimple_stmt_iterator *gsi,
> gimple *stmt,
> {
>if (!has_single_use (rhs1)
> || !is_widening_mult_p (rhs1_stmt, &type1, &mult_rhs1,
> - &type2, &mult_rhs2))
> + &type2, &mult_rhs2)
> + || (gimple_bb (rhs1_stmt) != gimple_bb (stmt)
> + && gimple_bb (rhs1_stmt)->count.to_frequency(cfun)
> +< gimple_bb (stmt)->count.to_frequency(cfun)))
> return false;
>add_rhs = rhs2;
>conv_stmt = conv1_stmt;
> @@ -2730,7 +2733,10 @@ convert_plusminus_to_widen (gimple_stmt_iterator *gsi,
> gimple *stmt,
> {
>if (!has_single_use (rhs2)
> || !is_widening_mult_p (rhs2_stmt, &type1, &mult_rhs1,
> - &type2, &mult_rhs2))
> + &type2, &mult_rhs2)
> + || (gimple_bb (rhs2_stmt) != gimple_bb (stmt)
> + && gimple_bb (rhs2_stmt)->count.to_frequency(cfun)
> +< gimple_bb (stmt)->count.to_frequency(cfun)))
> return false;
>add_rhs = rhs1;
>conv_stmt = conv2_stmt;
>
> Comments?
>
> Thanks,
> Felix
RE: [PATCH 1/2] arm: Add earlyclobber to MVE instructions that require it
Hi Andre, > -Original Message- > From: Andre Vieira (lists) > Sent: 23 March 2020 14:38 > To: gcc-patches@gcc.gnu.org > Cc: Kyrylo Tkachov > Subject: [PATCH 1/2] arm: Add earlyclobber to MVE instructions that require > it > > > Hi, > > This patch adds an earlyclobber to the MVE instructions that require it and > were missing it. These are vrev64 and 32-bit element variants of vcadd, > vhcadd vcmul, vmull[bt] and vqdmull[bt]. > > Regression tested on arm-none-eabi. > > Is this OK for trunk? Ok. Thanks, Kyrill > > Cheers, > Andre > > 2020-03-23 Andre Vieira > > * config/arm/mve.md (earlyclobber_32): New mode attribute. > (mve_vrev64q_*, mve_vcaddq*, mve_vhcaddq_*, mve_vcmulq_*, > mve_vmull[bt]q_*, mve_vqdmull[bt]q_*): Add appropriate early > clobbers.
Re: [PATCH] match.pd: recognize a signed rotate
On Mon, Mar 23, 2020 at 2:23 PM Stefan Schulze Frielinghaus via
Gcc-patches wrote:
>
> Hi all,
>
> A rotate of a signed integer is not recognized so far.
>
> int32_t f (int32_t x)
> {
> return (x << 5) | (int32_t)((uint32_t)x >> 27);
> }
>
> The code above is unoptimized in contrast to a version consisting only
> of unsigned integers. I'm wondering if this is intended or not. Since
> GCC has well defined behavior for shifts where the first operand is
> signed, I assumed that this also holds for rotates.
>
> The attached patch adds a pattern to match.pd for such signed rotates.
> Any comments about this?
>
> Note, for the sake of simplicity the attached patch does not handle the
> case where the input is a signed integer and the result is an unsigned,
> i.e., the following case is not covered:
>
> uint32_t f (int32_t x)
> {
> return (x << 5) | ((uint32_t)x >> 27);
> }
>
> My gut feeling was that it's not worth it to have another pattern for
> such an impure rotate. Maybe I'm wrong?
I wonder if we can leverage the bswap pass for rotate detection
(see find_bswap_or_nop which matches the symbolic number
against either 1:1 or byte-swapped variants, to be added would be
rotate and shift patterns).
Richard.
> Cheers,
> Stefan
Re: [PATCH 24/25] Ignore LLVM's blank lines.
Hi!
Now that I'm looking into enabling AMD GCN offloading in my builds, I
have a few concerns here. ;-)
On 2018-09-14T10:18:12-0600, Jeff Law wrote:
> On 9/5/18 5:52 AM, a...@codesourcery.com wrote:
>>
>> The GCN toolchain must use the LLVM assembler and linker because there's no
>> binutils port. The LLVM tools do not have the same diagnostic style as
>> binutils
For reference:
'libgomp.c++/../libgomp.c-c++-common/function-not-offloaded.c', for
example:
ld: error: undefined symbol: foo()
>>> referenced by /tmp/ccNzknBD.o:(main._omp_fn.0)
>>> referenced by /tmp/ccNzknBD.o:(main._omp_fn.0)
ld: error: undefined symbol: __gxx_personality_v0
>>> referenced by /tmp/ccNzknBD.o:(.data+0x13)
collect2: error: ld returned 1 exit status
mkoffload: fatal error:
[...]/build-gcc/./gcc/x86_64-pc-linux-gnu-accel-amdgcn-amdhsa-gcc returned 1
exit status
Note the blank line between the two "diagnostic blocks".
>> so the "blank line(s) in output" tests are inappropriate (and very
>> noisy).
>> gcc/testsuite/
>> * lib/gcc-dg.exp (gcc-dg-prune): Ignore blank lines from the LLVM
>> linker.
>> * lib/target-supports.exp (check_effective_target_llvm_binutils): New.
> This is fine. It's a NOP for other targets, so feel free to commit when
> it's convenient for you.
See below, is it really "a NOP for other targets"?
| --- a/gcc/testsuite/lib/gcc-dg.exp
| +++ b/gcc/testsuite/lib/gcc-dg.exp
| @@ -361,7 +361,7 @@ proc gcc-dg-prune { system text } {
|
| # Complain about blank lines in the output (PR other/69006)
| global allow_blank_lines
| -if { !$allow_blank_lines } {
| +if { !$allow_blank_lines && ![check_effective_target_llvm_binutils]} {
| set num_blank_lines [llength [regexp -all -inline "\n\n" $text]]
| if { $num_blank_lines } {
| global testname_with_flags
(That got re-worked a bit, per .)
| --- a/gcc/testsuite/lib/target-supports.exp
| +++ b/gcc/testsuite/lib/target-supports.exp
| @@ -9129,6 +9129,14 @@ proc check_effective_target_offload_hsa { } {
| } "-foffload=hsa" ]
| }
|
| +# Return 1 if the compiler has been configured with hsa offloading.
(Is this conceptually really appropriate to have here in
'gcc/testsuite/', given that all 'mkoffload'-based offloading testing
happens in libgomp only?) (And, 'hsa' copy'n'pasto should be 'amdgcn'?)
| +
| +proc check_effective_target_offload_gcn { } {
| +return [check_no_compiler_messages offload_gcn assembly {
| + int main () {return 0;}
| +} "-foffload=amdgcn-unknown-amdhsa" ]
| +}
This is too specific: "amdgcn-unknown-amdhsa" is often spelled just
"amdgcn-amdhsa", for example.
Our current '-foffload' syntax is not amenable to such variations; we
really need to re-work that. (That's also one of the reasons why
"-foffload* undocumented" is still open,
and hasn't seen any further work: the '-foffload' as we've currently got
it implemented is somewhat useful, yes, but needs to be improved to be
really useful for users -- as well as for ourselves, as we're seeing
here.) For example, consider you'd like to do offloading compilation to
include code for two different AMD GCN ISAs (fat binaries). Or, once
that is supported for OpenACC, "offloading" to several different
multicore CPU ISAs/variations. Can't specify such things given the
current syntax; we need some kind of abstraction from offload target.
(But that's a separate discussion, of course.)
Anyway, per the current code here, if instead of amdgcn-unknown-amdhsa I
configure GCC for amdgcn-amdhsa offload target, this test will not work.
| +# Return 1 if this target uses an LLVM assembler and/or linker
| +proc check_effective_target_llvm_binutils { } {
| +return [expr { [istarget amdgcn*-*-*]
| +|| [check_effective_target_offload_gcn] } ]
| +}
Unless I'm understanding something wrong, this (second condition here)
means that all the checking added for
"Extraneous newline emitted between error messages in GCC 6" will be void
as soon as GCC is configured for AMD GCN offloading. (This
effective-target here doesn't just apply to AMD GCN offloading
compliation, but to *all* standard GCC testsuite checking, doesn't it?)
That seems problematic to me: conceptually, but also in practice, given
that more and more users (for example, major GNU/Linux distributions) are
enabling GCC offloading compilation.
So here is a different proposal. The problem we're having is that the
AMD GCN 'as' (that is, 'llvm-mc') prints "unsuitable" diagnostics (as
quoted at the top of my email).
How about having a simple wrapper around it, to post-process its 'stderr'
to remove any blank linkes between "diagnostic blocks"? Then we could
remove this fragile 'check_effective_target_llvm_binutils' etc.?
I shall offer to implement the simple shell script, and suppose this
could live in 'gcc/config/gcn/'? ("Just" need to figur
[PATCH] Fix ICE PR94144
Hi all,
I'd like to submit this for PR94144.
The patch prevent 'simplify_logical_relational_operation' to generate
insn with a float only operator with non float operands.
In the PR the following
(ior:SI (gt:SI (reg:CC 66 cc)
(const_int 0 [0]))
(le:SI (reg:CC 66 cc)
(const_int 0 [0])))
was simplified into
(ordered:SI (reg:CC 66 cc)
(const_int 0 [0]))
causing ICE.
Bootstrapped on x86_64-linux-gnu and aarch64-unknown-linux-gnu does
not introduce testsuite regressions.
Andrea
gcc/ChangeLog
2020-??-?? Andrea Corallo
PR target/94144
* simplify-rtx.c (simplify_logical_relational_operation): Guard
against incoherent insn generation.
gcc/testsuite/ChangeLog
2020-??-?? Andrea Corallo
PR target/94144
* gcc.dg/pr94144.c: New test.
>From c2e9e920f4b65327753e75cede3312e70154190b Mon Sep 17 00:00:00 2001
From: Andrea Corallo
Date: Fri, 20 Mar 2020 16:36:40 +
Subject: [PATCH] PR94144
---
gcc/simplify-rtx.c | 13 +
gcc/testsuite/gcc.dg/pr94144.c | 24
2 files changed, 37 insertions(+)
create mode 100644 gcc/testsuite/gcc.dg/pr94144.c
diff --git a/gcc/simplify-rtx.c b/gcc/simplify-rtx.c
index dd3d85156c3e..758088ce5b97 100644
--- a/gcc/simplify-rtx.c
+++ b/gcc/simplify-rtx.c
@@ -2255,6 +2255,19 @@ simplify_logical_relational_operation (enum rtx_code code, machine_mode mode,
op0 = XEXP (op1, 0);
op1 = XEXP (op1, 1);
+ /* If 'code' is floating point only then the two ops must both be
+ float, otherwise give up. */
+ if ((!FLOAT_MODE_P (GET_MODE (op0))
+ || !FLOAT_MODE_P (GET_MODE (op1)))
+ && (code == ORDERED
+ || code == UNORDERED
+ || code == UNLT
+ || code == UNLE
+ || code == UNGT
+ || code == UNGE
+ || code == UNEQ))
+return 0;
+
return simplify_gen_relational (code, mode, VOIDmode, op0, op1);
}
diff --git a/gcc/testsuite/gcc.dg/pr94144.c b/gcc/testsuite/gcc.dg/pr94144.c
new file mode 100644
index ..ed8cee7ce591
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr94144.c
@@ -0,0 +1,24 @@
+/* PR target/94144 */
+/* { dg-do compile } */
+/* { dg-options "-O3" } */
+
+int a, b, z;
+int c(int d, int e) {
+ return d && e > 0 && d > 5 - e ? 0 : d + e;
+}
+int k();
+
+void h(int);
+
+void f(short d) {
+ int g = !(0 < d);
+ h(d);
+ if (b) {
+unsigned i[1];
+i[0] = g = 0;
+for (; g <= 8; g++)
+ d || k();
+if (c(!(i[0] <= z) >= d, d) != a)
+ k();
+ }
+}
--
2.17.1
Re: [PATCH] match.pd: recognize a signed rotate
On Mon, Mar 23, 2020 at 04:29:12PM +0100, Richard Biener wrote: > I wonder if we can leverage the bswap pass for rotate detection > (see find_bswap_or_nop which matches the symbolic number > against either 1:1 or byte-swapped variants, to be added would be > rotate and shift patterns). That pass can only handle cases where the shift counts are multiple of BITS_PER_UNIT, the whole infrastructure is based on being able to track movements of bytes. Jakub
Re: [PATCH] Check endianess detection.
On Mon, Mar 23, 2020 at 4:07 PM Martin Liška wrote:
>
> Hi.
>
> There's a patch draft that will do the proper versioning of API.
Would sth like this be preferred on the binutils side or would
splitting up the 'def' field via shift&masking better?
@@ -87,25 +87,30 @@ struct ld_plugin_symbol
{
char *name;
char *version;
- /* This is for compatibility with older ABIs. The older ABI defined
- only 'def' field. */
-#ifdef __BIG_ENDIAN__
- char unused;
...
+ int def;
int visibility;
uint64_t size;
char *comdat_key;
int resolution;
};
+/* A symbol belonging to an input file managed by the plugin library
+ (version 2). */
+
+struct ld_plugin_symbol_v2
+{
+ char *name;
+ char *version;
+ int def;
+ int visibility;
+ uint64_t size;
+ char *comdat_key;
+ int resolution;
+ char symbol_type;
+ char section_kind;
+ uint16_t unused;
+};
I think for ease of use you should do
struct ld_plugin_symbol_v2
{
ld_plugin_symbol v1_data;
char symbol_type;
char section_kind;
uint16_t unused;
}
also please avoid 'char', either use uint8_t or
at least unsigned char. I guess since you're extending
the type anyway using two plain 'int' would better follow
the rest of the data structure.
> It's a subject for discussion.
- status = add_symbols_v2 (file->handle, lto_file.symtab.nsyms,
-lto_file.symtab.syms);
+ {
+ /* Merge symtab::syms and symtab::syms_v2 data. */
+ for (unsigned int i = 0; i < lto_file.symtab.nsyms; i++)
+ {
I think lto-plugin should internally always parse into the "full" format,
using defaults for entries not in IL files. Only the interfacing with
the linker should then decide.
>
> Martin
Re: [PATCH] match.pd: recognize a signed rotate
On Mon, Mar 23, 2020 at 4:34 PM Jakub Jelinek wrote: > > On Mon, Mar 23, 2020 at 04:29:12PM +0100, Richard Biener wrote: > > I wonder if we can leverage the bswap pass for rotate detection > > (see find_bswap_or_nop which matches the symbolic number > > against either 1:1 or byte-swapped variants, to be added would be > > rotate and shift patterns). > > That pass can only handle cases where the shift counts are multiple of > BITS_PER_UNIT, the whole infrastructure is based on being able to track > movements of bytes. That's true, but also an artifact of the symbolic number encoding. > Jakub >
Re: [PATCH] Fix ICE PR94144
On Mon, 2020-03-23 at 16:32 +0100, Andrea Corallo wrote: > Hi all, > > I'd like to submit this for PR94144. > > The patch prevent 'simplify_logical_relational_operation' to generate > insn with a float only operator with non float operands. > > > In the PR the following > > (ior:SI (gt:SI (reg:CC 66 cc) >(const_int 0 [0])) > (le:SI (reg:CC 66 cc) >(const_int 0 [0]))) > > was simplified into > > (ordered:SI (reg:CC 66 cc) > (const_int 0 [0])) > > causing ICE. > > Bootstrapped on x86_64-linux-gnu and aarch64-unknown-linux-gnu does > not introduce testsuite regressions. > > Andrea > > gcc/ChangeLog > > 2020-??-?? Andrea Corallo > > PR target/94144 > * simplify-rtx.c (simplify_logical_relational_operation): Guard > against incoherent insn generation. I've got a more complete fix for this that I'll be submitting today. jeff
Re: [PATCH] Check endianess detection.
On Mon, Mar 23, 2020 at 8:39 AM Richard Biener
wrote:
>
> On Mon, Mar 23, 2020 at 4:07 PM Martin Liška wrote:
> >
> > Hi.
> >
> > There's a patch draft that will do the proper versioning of API.
>
> Would sth like this be preferred on the binutils side or would
> splitting up the 'def' field via shift&masking better?
>
> @@ -87,25 +87,30 @@ struct ld_plugin_symbol
> {
>char *name;
>char *version;
> - /* This is for compatibility with older ABIs. The older ABI defined
> - only 'def' field. */
> -#ifdef __BIG_ENDIAN__
> - char unused;
> ...
> + int def;
>int visibility;
>uint64_t size;
>char *comdat_key;
>int resolution;
> };
>
> +/* A symbol belonging to an input file managed by the plugin library
> + (version 2). */
> +
> +struct ld_plugin_symbol_v2
> +{
> + char *name;
> + char *version;
> + int def;
> + int visibility;
> + uint64_t size;
> + char *comdat_key;
> + int resolution;
> + char symbol_type;
> + char section_kind;
> + uint16_t unused;
> +};
>
> I think for ease of use you should do
>
> struct ld_plugin_symbol_v2
> {
> ld_plugin_symbol v1_data;
> char symbol_type;
> char section_kind;
> uint16_t unused;
> }
>
> also please avoid 'char', either use uint8_t or
> at least unsigned char. I guess since you're extending
> the type anyway using two plain 'int' would better follow
> the rest of the data structure.
>
> > It's a subject for discussion.
>
> - status = add_symbols_v2 (file->handle, lto_file.symtab.nsyms,
> -lto_file.symtab.syms);
> + {
> + /* Merge symtab::syms and symtab::syms_v2 data. */
> + for (unsigned int i = 0; i < lto_file.symtab.nsyms; i++)
> + {
>
> I think lto-plugin should internally always parse into the "full" format,
> using defaults for entries not in IL files. Only the interfacing with
> the linker should then decide.
Can we use
#if __has_include ()
...
#ifdef __BYTE_ORDER
#if __BYTE_ORDER == __BIG_ENDIAN
...
We support V2 interface only if defines __BYTE_ORDER?
--
H.J.
Re: [PATCH] avoid -Wredundant-tags on a first declaration in use (PR 93824)
On 3/23/20 8:49 AM, Jason Merrill wrote:
On 3/21/20 5:59 PM, Martin Sebor wrote:
+ /* Diagnose class/struct/union mismatches. IS_DECLARATION is
false
+ for alias definition. */
+ bool decl_class = (is_declaration
+ && cp_parser_declares_only_class_p (parser));
cp_parser_check_class_key (parser, key_loc, tag_type, type,
false,
cp_parser_declares_only_class_p (parser));
Don't you need to use the new variable?
Don't your testcases exercise this?
Of course they do. This was a leftover from an experiment after I put
the initial updated patch together. On final review I decided to adjust
some comments and forgot to restore the original use of the variable.
+ /* When TYPE is the use of an implicit specialization of a
previously
+ declared template set TYPE_DECL to the type of the primary template
+ for the specialization and look it up in CLASS2LOC below. For uses
+ of explicit or partial specializations TYPE_DECL already points to
+ the declaration of the specialization.
+ IS_USE is clear so that the type of an implicit instantiation
rather
+ than that of a partial specialization is determined. */
+ type_decl = TREE_TYPE (type_decl);
+ if (TREE_CODE (type_decl) != TEMPLATE_DECL)
+ type_decl = TYPE_MAIN_DECL (type_decl);
The comment is no longer relevant to the code. The remaining code also
seems like it would have no effect; we already know type_decl is
TYPE_MAIN_DECL (type).
I removed the block of code.
Martin
PS I would have preferred to resolve just the reported problem in this
patch and deal with the template specializations more fully (and with
aliases) in a followup. As it is, it has grown bigger and more complex
than I'm comfortable with, especially with the template specializations,
harder for me to follow, and obviously a lot more time-consuming not
just to put together but also to review. Although this revision handles
many more template specialization cases correctly, there still are other
(arguably corner) cases that it doesn't. I suspect getting those right
might even require a design change, which I see as out of scope at this
time (not to mention my ability).
PR c++/94078 - bogus and missing -Wmismatched-tags on an instance of a template
PR c++/93824 - bogus -Wredundant-tags on a first declaration in use
PR c++/93810 - missing -Wmismatched-tags and -Wredundant-tags on a typedef of an implicit class template specialization
gcc/cp/ChangeLog:
PR c++/94078
PR c++/93824
PR c++/93810
* cp-tree.h (most_specialized_partial_spec): Declare.
* parser.c (cp_parser_elaborated_type_specifier): Distinguish alias
from declarations.
(class_decl_loc_t::class_decl_loc_t): Add an argument.
(class_decl_loc_t::add): Same.
(class_decl_loc_t::add_or_diag_mismatched_tag): Same.
(class_decl_loc_t::is_decl): New member function.
(class_decl_loc_t::class_key_loc_t): Add a new member.
(specialization_of): New function.
(cp_parser_check_class_key): Move code...
(class_decl_loc_t::add): ...to here. Add parameters. Avoid issuing
-Wredundant-tags on first-time declarations in other declarators.
Correct handling of template specializations.
(class_decl_loc_t::diag_mismatched_tags): Also expect to be called
when -Wredundant-tags is enabled. Use primary template or partial
specialization as the guide for uses of implicit instantiations.
* pt.c (most_specialized_partial_spec): Declare extern.
gcc/testsuite/ChangeLog:
PR c++/94078
PR c++/93824
PR c++/93810
* g++.dg/warn/Wmismatched-tags-3.C: New test.
* g++.dg/warn/Wmismatched-tags-4.C: New test.
* g++.dg/warn/Wmismatched-tags-5.C: New test.
* g++.dg/warn/Wmismatched-tags-6.C: New test.
* g++.dg/warn/Wredundant-tags-3.C: Remove xfails.
* g++.dg/warn/Wredundant-tags-6.C: New test.
* g++.dg/warn/Wredundant-tags-7.C: New test.
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 0783b3114f2..9c4447202fc 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -6944,6 +6944,7 @@ extern int comp_template_args (tree, tree, tree * = NULL,
extern int template_args_equal (tree, tree, bool = false);
extern tree maybe_process_partial_specialization (tree);
extern tree most_specialized_instantiation (tree);
+extern tree most_specialized_partial_spec (tree, tsubst_flags_t);
extern void print_candidates (tree);
extern void instantiate_pending_templates (int);
extern tree tsubst_default_argument (tree, int, tree, tree,
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index cbd5510a8fb..8851940710e 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -18937,9 +18937,12 @@ cp_parser_elaborated_type_specifier (cp_parser* parser,
cp_parser_maybe_warn_enum_key (parser, key_loc, type, scoped_key);
else
{
- /* Diagnose class/struct/union mismatches. */
+ /* Diagnose class/struct/union mismatches. IS_DECLARATION is false
+ for alias definition. */
+ bool decl_class = (is_declara
[PATCH] S/390: Fix PR91628
Hi,
this patch picks up Robin Dapps patch __tls_get_offset-in-separate.S.
See "Bugzilla 91628 - libdruntime uses glibc internal symbol on s390"
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91628)
The original purpose was to get rid of the usage of the glibc-internal
symbol __tls_get_addr_internal.
The patch has not applied as is, therefore I've just regenerated the
configure and Makefiles.
Furthermore if build with multilib, the file
gcc/libphobos/libdruntime/config/systemz/get_tls_offset.S is used
for both configurations: systemz and s390.
Therefore both implementations are now in the systemz file which
uses an "#ifdef __s390x__" in order to distinguish both cases.
The s390 file is just including the systemz one.
Bye,
Stefan
--
libphobos/ChangeLog:
2019-11-27 Robin Dapp
2020-03-23 Stefan Liebler
* configure: Regenerate.
* libdruntime/Makefile.am: Add s390x and s390.
* libdruntime/Makefile.in: Regenerate.
* libdruntime/config/s390/get_tls_offset.S: New file.
* libdruntime/config/systemz/get_tls_offset.S: New file.
* libdruntime/gcc/sections/elf_shared.d: Use ibmz_get_tls_offset.
* m4/druntime/cpu.m4: Add s390x and s390.
commit db977cdbfc3449dfd730b639cd762588202cbb94
Author: Stefan Liebler
Date: Mon Mar 16 15:06:08 2020 +0100
S/390: Fix PR91628
This patch picks up Robin Dapps patch __tls_get_offset-in-separate.S.
See "Bugzilla 91628 - libdruntime uses glibc internal symbol on s390"
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91628)
The patch has not applied as is, therefore I've just regenerated the
configure and Makefiles.
Furthermore if build with multilib, the file
gcc/libphobos/libdruntime/config/systemz/get_tls_offset.S is used
for both configurations: systemz and s390.
Therefore both implementations are now in the systemz file which
uses an "#ifdef __s390x__" in order to distinguish both cases.
The s390 file is just including the systemz one.
libphobos/ChangeLog:
2019-11-27 Robin Dapp
2020-03-23 Stefan Liebler
* configure: Regenerate.
* libdruntime/Makefile.am: Add s390x and s390.
* libdruntime/Makefile.in: Regenerate.
* libdruntime/config/s390/get_tls_offset.S: New file.
* libdruntime/config/systemz/get_tls_offset.S: New file.
* libdruntime/gcc/sections/elf_shared.d: Use ibmz_get_tls_offset.
* m4/druntime/cpu.m4: Add s390x and s390.
diff --git a/libphobos/configure b/libphobos/configure
index 9cad270b2eb..04a6e6aeb0f 100755
--- a/libphobos/configure
+++ b/libphobos/configure
@@ -683,6 +683,10 @@ DRUNTIME_OS_AIX_FALSE
DRUNTIME_OS_AIX_TRUE
DRUNTIME_OS_UNIX_FALSE
DRUNTIME_OS_UNIX_TRUE
+DRUNTIME_CPU_S390_FALSE
+DRUNTIME_CPU_S390_TRUE
+DRUNTIME_CPU_SYSTEMZ_FALSE
+DRUNTIME_CPU_SYSTEMZ_TRUE
DRUNTIME_CPU_X86_FALSE
DRUNTIME_CPU_X86_TRUE
DRUNTIME_CPU_POWERPC64_FALSE
@@ -11644,7 +11648,7 @@ else
lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
lt_status=$lt_dlunknown
cat > conftest.$ac_ext <<_LT_EOF
-#line 11647 "configure"
+#line 11651 "configure"
#include "confdefs.h"
#if HAVE_DLFCN_H
@@ -11750,7 +11754,7 @@ else
lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
lt_status=$lt_dlunknown
cat > conftest.$ac_ext <<_LT_EOF
-#line 11753 "configure"
+#line 11757 "configure"
#include "confdefs.h"
#if HAVE_DLFCN_H
@@ -14012,6 +14016,12 @@ fi
i[34567]86|x86_64)
druntime_target_cpu_parsed="x86"
;;
+ s390x)
+ druntime_target_cpu_parsed="s390x"
+ ;;
+ s390)
+ druntime_target_cpu_parsed="s390"
+ ;;
esac
if test "$druntime_target_cpu_parsed" = "aarch64"; then
DRUNTIME_CPU_AARCH64_TRUE=
@@ -14061,6 +14071,22 @@ else
DRUNTIME_CPU_X86_FALSE=
fi
+ if test "$druntime_target_cpu_parsed" = "s390x"; then
+ DRUNTIME_CPU_SYSTEMZ_TRUE=
+ DRUNTIME_CPU_SYSTEMZ_FALSE='#'
+else
+ DRUNTIME_CPU_SYSTEMZ_TRUE='#'
+ DRUNTIME_CPU_SYSTEMZ_FALSE=
+fi
+
+ if test "$druntime_target_cpu_parsed" = "s390"; then
+ DRUNTIME_CPU_S390_TRUE=
+ DRUNTIME_CPU_S390_FALSE='#'
+else
+ DRUNTIME_CPU_S390_TRUE='#'
+ DRUNTIME_CPU_S390_FALSE=
+fi
+
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for target OS" >&5
@@ -15561,6 +15587,14 @@ if test -z "${DRUNTIME_CPU_X86_TRUE}" && test -z "${DRUNTIME_CPU_X86_FALSE}"; th
as_fn_error $? "conditional \"DRUNTIME_CPU_X86\" was never defined.
Usually this means the macro was only invoked conditionally." "$LINENO" 5
fi
+if test -z "${DRUNTIME_CPU_SYSTEMZ_TRUE}" && test -z "${DRUNTIME_CPU_SYSTEMZ_FALSE}"; then
+ as_fn_error $? "conditional \"DRUNTIME_CPU_SYSTEMZ\" was never defined.
+Usually this means the macro was only invoked conditionally." "$LINENO" 5
+fi
+if test -z "${DRUNTIME_CPU_S390_TRUE}" && test -z "${DRUNTIME_CPU_S390_FALSE}"; then
+ as_fn_error $? "conditional \"DRUNTIME
[PATCH] S/390: Fix layout of struct sigaction_t
Hi,
the ordering of some fields in struct sigaction on s390x (64bit)
differs compared to s390 and other architectures.
This patch adjusts this order according to the definition of
/sysdeps/unix/sysv/linux/s390/bits/sigaction.h
Without this fix e.g. the call
sigaction( suspendSignalNumber, &sigusr1, null ) in thread.d
leads to setting the sa_restorer field to 0x.
In case a signal, the signal handler returns to this address
and the process stops with a SIGILL.
This was observable in several execution testcases on s390x:
libphobos.druntime/core/thread.d
libphobos.druntime_shared/core/thread.d
libphobos.thread/tlsgc_sections.d
libphobos.allocations/tls_gc_integration.d
libphobos.phobos/std/parallelism.d
libphobos.phobos_shared/std/parallelism.d
libphobos.shared/host.c
libphobos.shared/linkD.c
libphobos.shared/linkDR.c
libphobos.shared/link_linkdep.d
libphobos.shared/load.d
libphobos.shared/loadDR.c
libphobos.shared/load_linkdep.d
libphobos.shared/load_loaddep.d
Bye,
Stefan
--
libphobos/ChangeLog:
2020-03-23 Stefan Liebler
* libphobos/libdruntime/core/sys/posix/signal.d:
Add struct sigaction_t for SystemZ.
commit 0986df3847c287c144b2e38d3ec1d423b934d7a8
Author: Stefan Liebler
Date: Tue Mar 17 17:00:44 2020 +0100
S/390: Fix layout of struct sigaction_t
The ordering of some fields in struct sigaction on s390x (64bit)
differs compared to s390 and other architectures.
This patch adjusts this order according to the definition of
/sysdeps/unix/sysv/linux/s390/bits/sigaction.h
Without this fix e.g. the call
sigaction( suspendSignalNumber, &sigusr1, null ) in thread.d
leads to setting the sa_restorer field to 0x.
In case a signal, the signal handler returns to this address
and the process stops with a SIGILL.
This was observable in several execution testcases on s390x:
libphobos.druntime/core/thread.d
libphobos.druntime_shared/core/thread.d
libphobos.thread/tlsgc_sections.d
libphobos.allocations/tls_gc_integration.d
libphobos.phobos/std/parallelism.d
libphobos.phobos_shared/std/parallelism.d
libphobos.shared/host.c
libphobos.shared/linkD.c
libphobos.shared/linkDR.c
libphobos.shared/link_linkdep.d
libphobos.shared/load.d
libphobos.shared/loadDR.c
libphobos.shared/load_linkdep.d
libphobos.shared/load_loaddep.d
libphobos/ChangeLog:
2020-03-23 Stefan Liebler
* libphobos/libdruntime/core/sys/posix/signal.d:
Add struct sigaction_t for SystemZ.
diff --git a/libphobos/libdruntime/core/sys/posix/signal.d b/libphobos/libdruntime/core/sys/posix/signal.d
index ed3985eee4d..5abcdac1355 100644
--- a/libphobos/libdruntime/core/sys/posix/signal.d
+++ b/libphobos/libdruntime/core/sys/posix/signal.d
@@ -575,24 +575,51 @@ else
version (CRuntime_Glibc)
{
-struct sigaction_t
+version (SystemZ)
{
-static if ( true /* __USE_POSIX199309 */ )
+struct sigaction_t
{
-union
+static if ( true /* __USE_POSIX199309 */ )
+{
+union
+{
+sigfn_t sa_handler;
+sigactfn_t sa_sigaction;
+}
+}
+else
{
sigfn_t sa_handler;
-sigactfn_t sa_sigaction;
}
+int __glibc_reserved0;
+int sa_flags;
+
+void function() sa_restorer;
+
+sigset_tsa_mask;
}
-else
+}
+else
+{
+struct sigaction_t
{
-sigfn_t sa_handler;
-}
-sigset_tsa_mask;
-int sa_flags;
+static if ( true /* __USE_POSIX199309 */ )
+{
+union
+{
+sigfn_t sa_handler;
+sigactfn_t sa_sigaction;
+}
+}
+else
+{
+sigfn_t sa_handler;
+}
+sigset_tsa_mask;
+int sa_flags;
-void function() sa_restorer;
+void function() sa_restorer;
+}
}
}
else version (CRuntime_Musl)
Re: [PATCH] Check endianess detection.
On 3/23/20 5:06 PM, H.J. Lu wrote: #if __has_include () ... #ifdef __BYTE_ORDER #if __BYTE_ORDER == __BIG_ENDIAN ... We support V2 interface only if defines __BYTE_ORDER? Right now we rely on __BIG_ENDIAN__ which is a weak endianess detection. So we either need a very robust endianess detection (as mention in this thread): https://github.com/llvm-mirror/compiler-rt/blob/master/lib/builtins/int_endianness.h or we'll come up with ld_plugin_symbol_v2 or we will shift values in 'int def' in order to support symbol_type and section_kind. What do you prefer H.J.? Thanks, Martin
Re: [PATCH] Check endianess detection.
On Mon, Mar 23, 2020 at 10:17 AM Martin Liška wrote: > > On 3/23/20 5:06 PM, H.J. Lu wrote: > > #if __has_include () > > ... > > #ifdef __BYTE_ORDER > > #if __BYTE_ORDER == __BIG_ENDIAN > > ... > > > > We support V2 interface only if defines __BYTE_ORDER? > > Right now we rely on __BIG_ENDIAN__ which is a weak endianess detection. > So we either need a very robust endianess detection (as mention in this > thread): > https://github.com/llvm-mirror/compiler-rt/blob/master/lib/builtins/int_endianness.h I prefer this one. > or > > we'll come up with ld_plugin_symbol_v2 > > or > > we will shift values in 'int def' in order to support symbol_type and > section_kind. > > What do you prefer H.J.? > Thanks, > Martin -- H.J.
[PATCH v2][ARM][GCC][12x]: MVE ACLE intrinsics to set and get vector lane.
Hello Kyrill, Following patch is the rebased version of v1. (version v1) https://gcc.gnu.org/pipermail/gcc-patches/2019-November/534346.html Hello, This patch supports following MVE ACLE intrinsics to get and set vector lane. vsetq_lane_f16, vsetq_lane_f32, vsetq_lane_s16, vsetq_lane_s32, vsetq_lane_s8, vsetq_lane_s64, vsetq_lane_u8, vsetq_lane_u16, vsetq_lane_u32, vsetq_lane_u64, vgetq_lane_f16, vgetq_lane_f32, vgetq_lane_s16, vgetq_lane_s32, vgetq_lane_s8, vgetq_lane_s64, vgetq_lane_u8, vgetq_lane_u16, vgetq_lane_u32, vgetq_lane_u64. Please refer to M-profile Vector Extension (MVE) intrinsics [1] for more details. [1] https://developer.arm.com/architectures/instruction-sets/simd-isas/helium/mve-intrinsics Regression tested on arm-none-eabi and found no regressions. Ok for trunk? Thanks, Srinath. gcc/ChangeLog: 2019-11-08 Srinath Parvathaneni Andre Vieira Mihail Ionescu * config/arm/arm_mve.h (vsetq_lane_f16): Define macro. (vsetq_lane_f32): Likewise. (vsetq_lane_s16): Likewise. (vsetq_lane_s32): Likewise. (vsetq_lane_s8): Likewise. (vsetq_lane_s64): Likewise. (vsetq_lane_u8): Likewise. (vsetq_lane_u16): Likewise. (vsetq_lane_u32): Likewise. (vsetq_lane_u64): Likewise. (vgetq_lane_f16): Likewise. (vgetq_lane_f32): Likewise. (vgetq_lane_s16): Likewise. (vgetq_lane_s32): Likewise. (vgetq_lane_s8): Likewise. (vgetq_lane_s64): Likewise. (vgetq_lane_u8): Likewise. (vgetq_lane_u16): Likewise. (vgetq_lane_u32): Likewise. (vgetq_lane_u64): Likewise. (__ARM_NUM_LANES): Likewise. (__ARM_LANEQ): Likewise. (__ARM_CHECK_LANEQ): Likewise. (__arm_vsetq_lane_s16): Define intrinsic. (__arm_vsetq_lane_s32): Likewise. (__arm_vsetq_lane_s8): Likewise. (__arm_vsetq_lane_s64): Likewise. (__arm_vsetq_lane_u8): Likewise. (__arm_vsetq_lane_u16): Likewise. (__arm_vsetq_lane_u32): Likewise. (__arm_vsetq_lane_u64): Likewise. (__arm_vgetq_lane_s16): Likewise. (__arm_vgetq_lane_s32): Likewise. (__arm_vgetq_lane_s8): Likewise. (__arm_vgetq_lane_s64): Likewise. (__arm_vgetq_lane_u8): Likewise. (__arm_vgetq_lane_u16): Likewise. (__arm_vgetq_lane_u32): Likewise. (__arm_vgetq_lane_u64): Likewise. (__arm_vsetq_lane_f16): Likewise. (__arm_vsetq_lane_f32): Likewise. (__arm_vgetq_lane_f16): Likewise. (__arm_vgetq_lane_f32): Likewise. (vgetq_lane): Define polymorphic variant. (vsetq_lane): Likewise. * config/arm/mve.md (mve_vec_extract): Define RTL pattern. (mve_vec_extractv2didi): Likewise. (mve_vec_extract_sext_internal): Likewise. (mve_vec_extract_zext_internal): Likewise. (mve_vec_set_internal): Likewise. (mve_vec_setv2di_internal): Likewise. * config/arm/neon.md (vec_set): Move RTL pattern to vec-common.md file. (vec_extract): Rename to "neon_vec_extract". (vec_extractv2didi): Rename to "neon_vec_extractv2didi". * config/arm/vec-common.md (vec_extract): Define RTL pattern common for MVE and NEON. (vec_set): Move RTL pattern from neon.md and modify to accept both MVE and NEON. gcc/testsuite/ChangeLog: 2019-11-08 Srinath Parvathaneni Andre Vieira Mihail Ionescu * gcc.target/arm/mve/intrinsics/vgetq_lane_f16.c: New test. * gcc.target/arm/mve/intrinsics/vgetq_lane_f32.c: Likewise. * gcc.target/arm/mve/intrinsics/vgetq_lane_s16.c: Likewise. * gcc.target/arm/mve/intrinsics/vgetq_lane_s32.c: Likewise. * gcc.target/arm/mve/intrinsics/vgetq_lane_s64.c: Likewise. * gcc.target/arm/mve/intrinsics/vgetq_lane_s8.c: Likewise. * gcc.target/arm/mve/intrinsics/vgetq_lane_u16.c: Likewise. * gcc.target/arm/mve/intrinsics/vgetq_lane_u32.c: Likewise. * gcc.target/arm/mve/intrinsics/vgetq_lane_u64.c: Likewise. * gcc.target/arm/mve/intrinsics/vgetq_lane_u8.c: Likewise. * gcc.target/arm/mve/intrinsics/vsetq_lane_f16.c: Likewise. * gcc.target/arm/mve/intrinsics/vsetq_lane_f32.c: Likewise. * gcc.target/arm/mve/intrinsics/vsetq_lane_s16.c: Likewise. * gcc.target/arm/mve/intrinsics/vsetq_lane_s32.c: Likewise. * gcc.target/arm/mve/intrinsics/vsetq_lane_s64.c: Likewise. * gcc.target/arm/mve/intrinsics/vsetq_lane_s8.c: Likewise. * gcc.target/arm/mve/intrinsics/vsetq_lane_u16.c: Likewise. * gcc.target/arm/mve/intrinsics/vsetq_lane_u32.c: Likewise. * gcc.target/arm/mve/intrinsics/vsetq_lane_u64.c: Likewise. * gcc.target/arm/mve/intrinsics/vsetq_lane_u8.c: Likewise. ### Attachment also inlined for ease of reply### diff
[PATCH v2][ARM][GCC][13x]: MVE ACLE scalar shift intrinsics.
Hello Kyrill,
Following patch is the rebased version of v1.
(version v1) https://gcc.gnu.org/pipermail/gcc-patches/2019-November/534350.html
Hello,
This patch supports following MVE ACLE scalar shift intrinsics.
sqrshr, sqrshrl, sqrshrl_sat48, sqshl, sqshll, srshr, srshrl, uqrshl,
uqrshll, uqrshll_sat48, uqshl, uqshll, urshr, urshrl, lsll, asrl.
Please refer to M-profile Vector Extension (MVE) intrinsics [1] for more
details.
[1]
https://developer.arm.com/architectures/instruction-sets/simd-isas/helium/mve-intrinsics
Regression tested on arm-none-eabi and found no regressions.
Ok for trunk?
Thanks,
Srinath.
gcc/ChangeLog:
2019-11-08 Srinath Parvathaneni
* config/arm/arm-builtins.c (LSLL_QUALIFIERS): Define builtin qualifier.
(UQSHL_QUALIFIERS): Likewise.
(ASRL_QUALIFIERS): Likewise.
(SQSHL_QUALIFIERS): Likewise.
* config/arm/arm_mve.h (__ARM_BIG_ENDIAN): Check to not support MVE in
Big-Endian Mode.
(sqrshr): Define macro.
(sqrshrl): Likewise.
(sqrshrl_sat48): Likewise.
(sqshl): Likewise.
(sqshll): Likewise.
(srshr): Likewise.
(srshrl): Likewise.
(uqrshl): Likewise.
(uqrshll): Likewise.
(uqrshll_sat48): Likewise.
(uqshl): Likewise.
(uqshll): Likewise.
(urshr): Likewise.
(urshrl): Likewise.
(lsll): Likewise.
(asrl): Likewise.
(__arm_lsll): Define intrinsic.
(__arm_asrl): Likewise.
(__arm_uqrshll): Likewise.
(__arm_uqrshll_sat48): Likewise.
(__arm_sqrshrl): Likewise.
(__arm_sqrshrl_sat48): Likewise.
(__arm_uqshll): Likewise.
(__arm_urshrl): Likewise.
(__arm_srshrl): Likewise.
(__arm_sqshll): Likewise.
(__arm_uqrshl): Likewise.
(__arm_sqrshr): Likewise.
(__arm_uqshl): Likewise.
(__arm_urshr): Likewise.
(__arm_sqshl): Likewise.
(__arm_srshr): Likewise.
* config/arm/arm_mve_builtins.def (LSLL_QUALIFIERS): Use builtin
qualifier.
(UQSHL_QUALIFIERS): Likewise.
(ASRL_QUALIFIERS): Likewise.
(SQSHL_QUALIFIERS): Likewise.
* config/arm/mve.md (mve_uqrshll_sat_di): Define RTL pattern.
(mve_sqrshrl_sat_di): Likewise
(mve_uqrshl_si): Likewise
(mve_sqrshr_si): Likewise
(mve_uqshll_di): Likewise
(mve_urshrl_di): Likewise
(mve_uqshl_si): Likewise
(mve_urshr_si): Likewise
(mve_sqshl_si): Likewise
(mve_srshr_si): Likewise
(mve_srshrl_di): Likewise
(mve_sqshll_di): Likewise
gcc/testsuite/ChangeLog:
2019-11-08 Srinath Parvathaneni
* gcc.target/arm/mve/intrinsics/asrl.c: New test.
* gcc.target/arm/mve/intrinsics/lsll.c: Likewise.
* gcc.target/arm/mve/intrinsics/sqrshr.c: Likewise.
* gcc.target/arm/mve/intrinsics/sqrshrl_sat48.c: Likewise.
* gcc.target/arm/mve/intrinsics/sqrshrl_sat64.c: Likewise.
* gcc.target/arm/mve/intrinsics/sqshl.c: Likewise.
* gcc.target/arm/mve/intrinsics/sqshll.c: Likewise.
* gcc.target/arm/mve/intrinsics/srshr.c: Likewise.
* gcc.target/arm/mve/intrinsics/srshrl.c: Likewise.
* gcc.target/arm/mve/intrinsics/uqrshl.c: Likewise.
* gcc.target/arm/mve/intrinsics/uqrshll_sat48.c: Likewise.
* gcc.target/arm/mve/intrinsics/uqrshll_sat64.c: Likewise.
* gcc.target/arm/mve/intrinsics/uqshl.c: Likewise.
* gcc.target/arm/mve/intrinsics/uqshll.c: Likewise.
* gcc.target/arm/mve/intrinsics/urshr.c: Likewise.
* gcc.target/arm/mve/intrinsics/urshrl.c: Likewise.
* lib/target-supports.exp:
(check_effective_target_arm_v8_1m_mve_fp_ok_nocache): Modify to not
support MVE floating point in Big Endian mode.
(check_effective_target_arm_v8_1m_mve_ok_nocache): Modify to not
support MVE integer in Big Endian mode.
### Attachment also inlined for ease of reply###
diff --git a/gcc/config/arm/arm-builtins.c b/gcc/config/arm/arm-builtins.c
index
96d8adcd37eb3caf51c71d66af0331f9d1924b92..56f0db21ea95dcd738877daba27f1cb60f0d5a32
100644
--- a/gcc/config/arm/arm-builtins.c
+++ b/gcc/config/arm/arm-builtins.c
@@ -762,6 +762,26 @@ arm_strsbwbu_p_qualifiers[SIMD_MAX_BUILTIN_ARGS]
qualifier_unsigned, qualifier_unsigned};
#define STRSBWBU_P_QUALIFIERS (arm_strsbwbu_p_qualifiers)
+static enum arm_type_qualifiers
+arm_lsll_qualifiers[SIMD_MAX_BUILTIN_ARGS]
+ = { qualifier_unsigned, qualifier_unsigned, qualifier_none};
+#define LSLL_QUALIFIERS (arm_lsll_qualifiers)
+
+static enum arm_type_qualifiers
+arm_uqshl_qualifiers[SIMD_MAX_BUILTIN_ARGS]
+ = { qualifier_unsigned, qualifier_unsigned, qualifier_const};
+#define UQSHL_QUALIFIERS (arm_uqshl_qualifiers)
+
+static enum arm_type_qualifiers
+arm_asrl_qualifiers[SIMD_MAX_BUILTIN_ARGS]
+ = { qualifier_none, qualifier_none, quali
[PATCH v2][ARM][GCC][14x]: MVE ACLE whole vector left shift with carry intrinsics.
Hello Kyrill,
Following patch is the rebased version of v1.
(version v1) https://gcc.gnu.org/pipermail/gcc-patches/2019-November/534344.html
Hello,
This patch supports following MVE ACLE whole vector left shift with carry
intrinsics.
vshlcq_m_s8, vshlcq_m_s16, vshlcq_m_s32, vshlcq_m_u8, vshlcq_m_u16,
vshlcq_m_u32.
Please refer to M-profile Vector Extension (MVE) intrinsics [1] for more
details.
[1]
https://developer.arm.com/architectures/instruction-sets/simd-isas/helium/mve-intrinsics
Regression tested on arm-none-eabi and found no regressions.
Ok for trunk?
Thanks,
Srinath.
gcc/ChangeLog:
2019-11-08 Srinath Parvathaneni
Andre Vieira
Mihail Ionescu
* config/arm/arm_mve.h (vshlcq_m_s8): Define macro.
(vshlcq_m_u8): Likewise.
(vshlcq_m_s16): Likewise.
(vshlcq_m_u16): Likewise.
(vshlcq_m_s32): Likewise.
(vshlcq_m_u32): Likewise.
(__arm_vshlcq_m_s8): Define intrinsic.
(__arm_vshlcq_m_u8): Likewise.
(__arm_vshlcq_m_s16): Likewise.
(__arm_vshlcq_m_u16): Likewise.
(__arm_vshlcq_m_s32): Likewise.
(__arm_vshlcq_m_u32): Likewise.
(vshlcq_m): Define polymorphic variant.
* config/arm/arm_mve_builtins.def (QUADOP_NONE_NONE_UNONE_IMM_UNONE):
Use builtin qualifier.
(QUADOP_UNONE_UNONE_UNONE_IMM_UNONE): Likewise.
* config/arm/mve.md (mve_vshlcq_m_vec_): Define RTL pattern.
(mve_vshlcq_m_carry_): Likewise.
(mve_vshlcq_m_): Likewise.
gcc/testsuite/ChangeLog:
2019-11-08 Srinath Parvathaneni
Andre Vieira
Mihail Ionescu
* gcc.target/arm/mve/intrinsics/vshlcq_m_s16.c: New test.
* gcc.target/arm/mve/intrinsics/vshlcq_m_s32.c: Likewise.
* gcc.target/arm/mve/intrinsics/vshlcq_m_s8.c: Likewise.
* gcc.target/arm/mve/intrinsics/vshlcq_m_u16.c: Likewise.
* gcc.target/arm/mve/intrinsics/vshlcq_m_u32.c: Likewise.
* gcc.target/arm/mve/intrinsics/vshlcq_m_u8.c: Likewise.
### Attachment also inlined for ease of reply###
diff --git a/gcc/config/arm/arm_mve.h b/gcc/config/arm/arm_mve.h
index
f2d80ee636003ac58f70ddc25db15e129e228906..14b6ec857bffd85b67c781f554faffde1b2abc6b
100644
--- a/gcc/config/arm/arm_mve.h
+++ b/gcc/config/arm/arm_mve.h
@@ -2546,6 +2546,12 @@ typedef struct { uint8x16_t val[4]; } uint8x16x4_t;
#define urshrl(__p0, __p1) __arm_urshrl(__p0, __p1)
#define lsll(__p0, __p1) __arm_lsll(__p0, __p1)
#define asrl(__p0, __p1) __arm_asrl(__p0, __p1)
+#define vshlcq_m_s8(__a, __b, __imm, __p) __arm_vshlcq_m_s8(__a, __b,
__imm, __p)
+#define vshlcq_m_u8(__a, __b, __imm, __p) __arm_vshlcq_m_u8(__a, __b,
__imm, __p)
+#define vshlcq_m_s16(__a, __b, __imm, __p) __arm_vshlcq_m_s16(__a, __b,
__imm, __p)
+#define vshlcq_m_u16(__a, __b, __imm, __p) __arm_vshlcq_m_u16(__a, __b,
__imm, __p)
+#define vshlcq_m_s32(__a, __b, __imm, __p) __arm_vshlcq_m_s32(__a, __b,
__imm, __p)
+#define vshlcq_m_u32(__a, __b, __imm, __p) __arm_vshlcq_m_u32(__a, __b,
__imm, __p)
#endif
/* For big-endian, GCC's vector indices are reversed within each 64 bits
@@ -16671,6 +16677,60 @@ __arm_srshr (int32_t value, const int shift)
return __builtin_mve_srshr_si (value, shift);
}
+__extension__ extern __inline int8x16_t
+__attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
+__arm_vshlcq_m_s8 (int8x16_t __a, uint32_t * __b, const int __imm,
mve_pred16_t __p)
+{
+ int8x16_t __res = __builtin_mve_vshlcq_m_vec_sv16qi (__a, *__b, __imm, __p);
+ *__b = __builtin_mve_vshlcq_m_carry_sv16qi (__a, *__b, __imm, __p);
+ return __res;
+}
+
+__extension__ extern __inline uint8x16_t
+__attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
+__arm_vshlcq_m_u8 (uint8x16_t __a, uint32_t * __b, const int __imm,
mve_pred16_t __p)
+{
+ uint8x16_t __res = __builtin_mve_vshlcq_m_vec_uv16qi (__a, *__b, __imm, __p);
+ *__b = __builtin_mve_vshlcq_m_carry_uv16qi (__a, *__b, __imm, __p);
+ return __res;
+}
+
+__extension__ extern __inline int16x8_t
+__attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
+__arm_vshlcq_m_s16 (int16x8_t __a, uint32_t * __b, const int __imm,
mve_pred16_t __p)
+{
+ int16x8_t __res = __builtin_mve_vshlcq_m_vec_sv8hi (__a, *__b, __imm, __p);
+ *__b = __builtin_mve_vshlcq_m_carry_sv8hi (__a, *__b, __imm, __p);
+ return __res;
+}
+
+__extension__ extern __inline uint16x8_t
+__attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
+__arm_vshlcq_m_u16 (uint16x8_t __a, uint32_t * __b, const int __imm,
mve_pred16_t __p)
+{
+ uint16x8_t __res = __builtin_mve_vshlcq_m_vec_uv8hi (__a, *__b, __imm, __p);
+ *__b = __builtin_mve_vshlcq_m_carry_uv8hi (__a, *__b, __imm, __p);
+ return __res;
+}
+
+__extension__ extern __inline int32x4_t
+__attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
+__arm_vshlcq_m_s32 (int32x4_t __a, uint32_t * __b, const
Re: [committed][gcc] libgccjit: handle long literals in playback::context::new_string_literal
Hi all,
attached the final version of the patch for the 200 characters limit
for literal strings addressing comments on the missing "testcases"
array entry (apologies) and alphabetic order.
make check-jit is passing clean.
Pushed into trunk.
Best Regards
Andrea
gcc/jit/ChangeLog
2020-03-23 Andrea Corallo
* jit-playback.h
(gcc::jit::playback::context m_recording_ctxt): Remove
m_char_array_type_node field.
* jit-playback.c
(playback::context::context) Remove m_char_array_type_node from member
initializer list.
(playback::context::new_string_literal) Fix logic to handle string
length > 200.
gcc/testsuite/ChangeLog
2020-03-23 Andrea Corallo
* jit.dg/all-non-failing-tests.h: Add test-long-string-literal.c.
* jit.dg/test-long-string-literal.c: New testcase.
diff --git a/gcc/jit/jit-playback.h b/gcc/jit/jit-playback.h
index 904cc167a0c..074434a9f6b 100644
--- a/gcc/jit/jit-playback.h
+++ b/gcc/jit/jit-playback.h
@@ -322,7 +322,6 @@ private:
auto_vec m_functions;
auto_vec m_globals;
- tree m_char_array_type_node;
tree m_const_char_ptr;
/* Source location handling. */
diff --git a/gcc/jit/jit-playback.c b/gcc/jit/jit-playback.c
index da687002a72..d2c8bb4c154 100644
--- a/gcc/jit/jit-playback.c
+++ b/gcc/jit/jit-playback.c
@@ -88,7 +88,6 @@ playback::context::context (recording::context *ctxt)
: log_user (ctxt->get_logger ()),
m_recording_ctxt (ctxt),
m_tempdir (NULL),
-m_char_array_type_node (NULL),
m_const_char_ptr (NULL)
{
JIT_LOG_SCOPE (get_logger ());
@@ -670,9 +669,14 @@ playback::rvalue *
playback::context::
new_string_literal (const char *value)
{
- tree t_str = build_string (strlen (value), value);
- gcc_assert (m_char_array_type_node);
- TREE_TYPE (t_str) = m_char_array_type_node;
+ /* Compare with c-family/c-common.c: fix_string_type. */
+ size_t len = strlen (value);
+ tree i_type = build_index_type (size_int (len));
+ tree a_type = build_array_type (char_type_node, i_type);
+ /* build_string len parameter must include NUL terminator when
+ building C strings. */
+ tree t_str = build_string (len + 1, value);
+ TREE_TYPE (t_str) = a_type;
/* Convert to (const char*), loosely based on
c/c-typeck.c: array_to_pointer_conversion,
@@ -2701,10 +2705,6 @@ playback::context::
replay ()
{
JIT_LOG_SCOPE (get_logger ());
- /* Adapted from c-common.c:c_common_nodes_and_builtins. */
- tree array_domain_type = build_index_type (size_int (200));
- m_char_array_type_node
-= build_array_type (char_type_node, array_domain_type);
m_const_char_ptr
= build_pointer_type (build_qualified_type (char_type_node,
diff --git a/gcc/testsuite/jit.dg/all-non-failing-tests.h b/gcc/testsuite/jit.dg/all-non-failing-tests.h
index 0272e6f846f..b2acc74ae95 100644
--- a/gcc/testsuite/jit.dg/all-non-failing-tests.h
+++ b/gcc/testsuite/jit.dg/all-non-failing-tests.h
@@ -178,6 +178,13 @@
#undef create_code
#undef verify_code
+/* test-long-string-literal.c */
+#define create_code create_code_long_string_literal
+#define verify_code verify_code_long_string_literal
+#include "test-long-string-literal.c"
+#undef create_code
+#undef verify_code
+
/* test-quadratic.c */
#define create_code create_code_quadratic
#define verify_code verify_code_quadratic
@@ -342,6 +349,9 @@ const struct testcase testcases[] = {
{"long_names",
create_code_long_names,
verify_code_long_names},
+ {"long_string_literal",
+ create_code_long_string_literal,
+ verify_code_long_string_literal},
{"quadratic",
create_code_quadratic,
verify_code_quadratic},
diff --git a/gcc/testsuite/jit.dg/test-long-string-literal.c b/gcc/testsuite/jit.dg/test-long-string-literal.c
new file mode 100644
index 000..6caaa781c0b
--- /dev/null
+++ b/gcc/testsuite/jit.dg/test-long-string-literal.c
@@ -0,0 +1,54 @@
+#include
+#include
+#include
+#include
+
+#include "libgccjit.h"
+
+#include "harness.h"
+
+const char very_long_string[] =
+ "abcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabc"
+ "abcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabc"
+ "abcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabc"
+ "abcabcabcabcabcabcabcabcabcabca";
+
+void
+create_code (gcc_jit_context *ctxt, void *user_data)
+{
+ /* Build the test_fn. */
+ gcc_jit_function *f =
+gcc_jit_context_new_function (
+ ctxt, NULL,
+ GCC_JIT_FUNCTION_EXPORTED,
+ gcc_jit_context_get_type(ctxt,
+ GCC_JIT_TYPE_CONST_CHAR_PTR),
+"test_long_string_literal",
+0, NULL, 0);
+ gcc_jit_block *blk =
+gcc_jit_function_new_block (f, "init_block");
+
+ /* very_long_string is longer than 200 characters to specifically
+ check that the previous limitation no longer apply. */
+
+ assert (sizeof (very_long_string) > 200);
+ gcc_jit_rvalue *res =
+gcc_jit_context_new_string_literal (ctxt, ver
RE: [PATCH v2][ARM][GCC][12x]: MVE ACLE intrinsics to set and get vector lane.
Hi Srinath, > -Original Message- > From: Srinath Parvathaneni > Sent: 23 March 2020 17:43 > To: gcc-patches@gcc.gnu.org > Cc: Kyrylo Tkachov > Subject: [PATCH v2][ARM][GCC][12x]: MVE ACLE intrinsics to set and get > vector lane. > > Hello Kyrill, > > Following patch is the rebased version of v1. > (version v1) https://gcc.gnu.org/pipermail/gcc-patches/2019- > November/534346.html > > > > Hello, > > This patch supports following MVE ACLE intrinsics to get and set vector lane. > > vsetq_lane_f16, vsetq_lane_f32, vsetq_lane_s16, vsetq_lane_s32, > vsetq_lane_s8, vsetq_lane_s64, vsetq_lane_u8, vsetq_lane_u16, > vsetq_lane_u32, vsetq_lane_u64, vgetq_lane_f16, vgetq_lane_f32, > vgetq_lane_s16, vgetq_lane_s32, vgetq_lane_s8, vgetq_lane_s64, > vgetq_lane_u8, vgetq_lane_u16, vgetq_lane_u32, vgetq_lane_u64. > > Please refer to M-profile Vector Extension (MVE) intrinsics [1] for more > details. > [1] https://developer.arm.com/architectures/instruction-sets/simd- > isas/helium/mve-intrinsics > > Regression tested on arm-none-eabi and found no regressions. > > Ok for trunk? Thanks, I've pushed this patch to master. Kyrill > > Thanks, > Srinath. > > gcc/ChangeLog: > > 2019-11-08 Srinath Parvathaneni > Andre Vieira > Mihail Ionescu > > * config/arm/arm_mve.h (vsetq_lane_f16): Define macro. > (vsetq_lane_f32): Likewise. > (vsetq_lane_s16): Likewise. > (vsetq_lane_s32): Likewise. > (vsetq_lane_s8): Likewise. > (vsetq_lane_s64): Likewise. > (vsetq_lane_u8): Likewise. > (vsetq_lane_u16): Likewise. > (vsetq_lane_u32): Likewise. > (vsetq_lane_u64): Likewise. > (vgetq_lane_f16): Likewise. > (vgetq_lane_f32): Likewise. > (vgetq_lane_s16): Likewise. > (vgetq_lane_s32): Likewise. > (vgetq_lane_s8): Likewise. > (vgetq_lane_s64): Likewise. > (vgetq_lane_u8): Likewise. > (vgetq_lane_u16): Likewise. > (vgetq_lane_u32): Likewise. > (vgetq_lane_u64): Likewise. > (__ARM_NUM_LANES): Likewise. > (__ARM_LANEQ): Likewise. > (__ARM_CHECK_LANEQ): Likewise. > (__arm_vsetq_lane_s16): Define intrinsic. > (__arm_vsetq_lane_s32): Likewise. > (__arm_vsetq_lane_s8): Likewise. > (__arm_vsetq_lane_s64): Likewise. > (__arm_vsetq_lane_u8): Likewise. > (__arm_vsetq_lane_u16): Likewise. > (__arm_vsetq_lane_u32): Likewise. > (__arm_vsetq_lane_u64): Likewise. > (__arm_vgetq_lane_s16): Likewise. > (__arm_vgetq_lane_s32): Likewise. > (__arm_vgetq_lane_s8): Likewise. > (__arm_vgetq_lane_s64): Likewise. > (__arm_vgetq_lane_u8): Likewise. > (__arm_vgetq_lane_u16): Likewise. > (__arm_vgetq_lane_u32): Likewise. > (__arm_vgetq_lane_u64): Likewise. > (__arm_vsetq_lane_f16): Likewise. > (__arm_vsetq_lane_f32): Likewise. > (__arm_vgetq_lane_f16): Likewise. > (__arm_vgetq_lane_f32): Likewise. > (vgetq_lane): Define polymorphic variant. > (vsetq_lane): Likewise. > * config/arm/mve.md (mve_vec_extract): Define > RTL > pattern. > (mve_vec_extractv2didi): Likewise. > (mve_vec_extract_sext_internal): Likewise. > (mve_vec_extract_zext_internal): Likewise. > (mve_vec_set_internal): Likewise. > (mve_vec_setv2di_internal): Likewise. > * config/arm/neon.md (vec_set): Move RTL pattern to vec- > common.md > file. > (vec_extract): Rename to > "neon_vec_extract". > (vec_extractv2didi): Rename to "neon_vec_extractv2didi". > * config/arm/vec-common.md (vec_extract): > Define RTL > pattern common for MVE and NEON. > (vec_set): Move RTL pattern from neon.md and modify to > accept both > MVE and NEON. > > gcc/testsuite/ChangeLog: > > 2019-11-08 Srinath Parvathaneni > Andre Vieira > Mihail Ionescu > > * gcc.target/arm/mve/intrinsics/vgetq_lane_f16.c: New test. > * gcc.target/arm/mve/intrinsics/vgetq_lane_f32.c: Likewise. > * gcc.target/arm/mve/intrinsics/vgetq_lane_s16.c: Likewise. > * gcc.target/arm/mve/intrinsics/vgetq_lane_s32.c: Likewise. > * gcc.target/arm/mve/intrinsics/vgetq_lane_s64.c: Likewise. > * gcc.target/arm/mve/intrinsics/vgetq_lane_s8.c: Likewise. > * gcc.target/arm/mve/intrinsics/vgetq_lane_u16.c: Likewise. > * gcc.target/arm/mve/intrinsics/vgetq_lane_u32.c: Likewise. > * gcc.target/arm/mve/intrinsics/vgetq_lane_u64.c: Likewise. > * gcc.target/arm/mve/intrinsics/vgetq_lane_u8.c: Likewise. > * gcc.target/arm/mve/intrinsics/vsetq_lane_f16.c: Likewise. > * gcc.target/arm/mve/intrinsics/vsetq_lane_f32.c: Likewise. > * gcc.target/arm/mve/intrinsics/vsetq_lane_s16.c: Likewise. > * gcc.target/arm/mve/intrinsics/vsetq_lane_s32.c: Likewise. > * gcc.target/arm/mve/intrinsics/vsetq_lane_s64.c: Likewise. > * gcc.target/arm/mve/intrinsics
RE: [PATCH v2][ARM][GCC][13x]: MVE ACLE scalar shift intrinsics.
Hi Srinath,
> -Original Message-
> From: Srinath Parvathaneni
> Sent: 23 March 2020 17:44
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH v2][ARM][GCC][13x]: MVE ACLE scalar shift intrinsics.
>
> Hello Kyrill,
>
> Following patch is the rebased version of v1.
> (version v1) https://gcc.gnu.org/pipermail/gcc-patches/2019-
> November/534350.html
>
>
>
> Hello,
>
> This patch supports following MVE ACLE scalar shift intrinsics.
>
> sqrshr, sqrshrl, sqrshrl_sat48, sqshl, sqshll, srshr, srshrl, uqrshl, uqrshll,
> uqrshll_sat48, uqshl, uqshll, urshr, urshrl, lsll, asrl.
>
> Please refer to M-profile Vector Extension (MVE) intrinsics [1] for more
> details.
> [1] https://developer.arm.com/architectures/instruction-sets/simd-
> isas/helium/mve-intrinsics
>
> Regression tested on arm-none-eabi and found no regressions.
>
> Ok for trunk?
Thanks, I've pushed this patch to master.
Kyrill
>
> Thanks,
> Srinath.
>
> gcc/ChangeLog:
>
> 2019-11-08 Srinath Parvathaneni
>
> * config/arm/arm-builtins.c (LSLL_QUALIFIERS): Define builtin
> qualifier.
> (UQSHL_QUALIFIERS): Likewise.
> (ASRL_QUALIFIERS): Likewise.
> (SQSHL_QUALIFIERS): Likewise.
> * config/arm/arm_mve.h (__ARM_BIG_ENDIAN): Check to not
> support MVE in
> Big-Endian Mode.
> (sqrshr): Define macro.
> (sqrshrl): Likewise.
> (sqrshrl_sat48): Likewise.
> (sqshl): Likewise.
> (sqshll): Likewise.
> (srshr): Likewise.
> (srshrl): Likewise.
> (uqrshl): Likewise.
> (uqrshll): Likewise.
> (uqrshll_sat48): Likewise.
> (uqshl): Likewise.
> (uqshll): Likewise.
> (urshr): Likewise.
> (urshrl): Likewise.
> (lsll): Likewise.
> (asrl): Likewise.
> (__arm_lsll): Define intrinsic.
> (__arm_asrl): Likewise.
> (__arm_uqrshll): Likewise.
> (__arm_uqrshll_sat48): Likewise.
> (__arm_sqrshrl): Likewise.
> (__arm_sqrshrl_sat48): Likewise.
> (__arm_uqshll): Likewise.
> (__arm_urshrl): Likewise.
> (__arm_srshrl): Likewise.
> (__arm_sqshll): Likewise.
> (__arm_uqrshl): Likewise.
> (__arm_sqrshr): Likewise.
> (__arm_uqshl): Likewise.
> (__arm_urshr): Likewise.
> (__arm_sqshl): Likewise.
> (__arm_srshr): Likewise.
> * config/arm/arm_mve_builtins.def (LSLL_QUALIFIERS): Use builtin
> qualifier.
> (UQSHL_QUALIFIERS): Likewise.
> (ASRL_QUALIFIERS): Likewise.
> (SQSHL_QUALIFIERS): Likewise.
> * config/arm/mve.md (mve_uqrshll_sat_di): Define RTL
> pattern.
> (mve_sqrshrl_sat_di): Likewise
> (mve_uqrshl_si): Likewise
> (mve_sqrshr_si): Likewise
> (mve_uqshll_di): Likewise
> (mve_urshrl_di): Likewise
> (mve_uqshl_si): Likewise
> (mve_urshr_si): Likewise
> (mve_sqshl_si): Likewise
> (mve_srshr_si): Likewise
> (mve_srshrl_di): Likewise
> (mve_sqshll_di): Likewise
>
> gcc/testsuite/ChangeLog:
>
> 2019-11-08 Srinath Parvathaneni
>
> * gcc.target/arm/mve/intrinsics/asrl.c: New test.
> * gcc.target/arm/mve/intrinsics/lsll.c: Likewise.
> * gcc.target/arm/mve/intrinsics/sqrshr.c: Likewise.
> * gcc.target/arm/mve/intrinsics/sqrshrl_sat48.c: Likewise.
> * gcc.target/arm/mve/intrinsics/sqrshrl_sat64.c: Likewise.
> * gcc.target/arm/mve/intrinsics/sqshl.c: Likewise.
> * gcc.target/arm/mve/intrinsics/sqshll.c: Likewise.
> * gcc.target/arm/mve/intrinsics/srshr.c: Likewise.
> * gcc.target/arm/mve/intrinsics/srshrl.c: Likewise.
> * gcc.target/arm/mve/intrinsics/uqrshl.c: Likewise.
> * gcc.target/arm/mve/intrinsics/uqrshll_sat48.c: Likewise.
> * gcc.target/arm/mve/intrinsics/uqrshll_sat64.c: Likewise.
> * gcc.target/arm/mve/intrinsics/uqshl.c: Likewise.
> * gcc.target/arm/mve/intrinsics/uqshll.c: Likewise.
> * gcc.target/arm/mve/intrinsics/urshr.c: Likewise.
> * gcc.target/arm/mve/intrinsics/urshrl.c: Likewise.
> * lib/target-supports.exp:
> (check_effective_target_arm_v8_1m_mve_fp_ok_nocache): Modify to
> not
> support MVE floating point in Big Endian mode.
> (check_effective_target_arm_v8_1m_mve_ok_nocache): Modify to not
> support MVE integer in Big Endian mode.
>
>
> ### Attachment also inlined for ease of reply
> ###
>
>
> diff --git a/gcc/config/arm/arm-builtins.c b/gcc/config/arm/arm-builtins.c
> index
> 96d8adcd37eb3caf51c71d66af0331f9d1924b92..56f0db21ea95dcd738877dab
> a27f1cb60f0d5a32 100644
> --- a/gcc/config/arm/arm-builtins.c
> +++ b/gcc/config/arm/arm-builtins.c
> @@ -762,6 +762,26 @@
> arm_strsbwbu_p_qualifiers[SIMD_MAX_BUILTIN_ARGS]
>qualifier_unsigned, qualifier_unsigned}; #define
> STRSBWBU_P_QUALIFIERS (arm_strsbwbu_p_qualifiers)
>
> +static enum arm_type_qualifiers
> +arm_lsll_qualifiers[SIMD_MAX_BUILTIN_ARGS]
> + = { qualifier_unsi
RE: [PATCH v2][ARM][GCC][14x]: MVE ACLE whole vector left shift with carry intrinsics.
Hi Srinath,
> -Original Message-
> From: Srinath Parvathaneni
> Sent: 23 March 2020 17:45
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH v2][ARM][GCC][14x]: MVE ACLE whole vector left shift with
> carry intrinsics.
>
> Hello Kyrill,
>
> Following patch is the rebased version of v1.
> (version v1) https://gcc.gnu.org/pipermail/gcc-patches/2019-
> November/534344.html
>
>
> Hello,
>
> This patch supports following MVE ACLE whole vector left shift with carry
> intrinsics.
>
> vshlcq_m_s8, vshlcq_m_s16, vshlcq_m_s32, vshlcq_m_u8, vshlcq_m_u16,
> vshlcq_m_u32.
>
> Please refer to M-profile Vector Extension (MVE) intrinsics [1] for more
> details.
> [1] https://developer.arm.com/architectures/instruction-sets/simd-
> isas/helium/mve-intrinsics
>
> Regression tested on arm-none-eabi and found no regressions.
>
> Ok for trunk?
Thanks, I've pushed this patch to master.
Kyrill
>
> Thanks,
> Srinath.
>
> gcc/ChangeLog:
>
> 2019-11-08 Srinath Parvathaneni
> Andre Vieira
> Mihail Ionescu
>
> * config/arm/arm_mve.h (vshlcq_m_s8): Define macro.
> (vshlcq_m_u8): Likewise.
> (vshlcq_m_s16): Likewise.
> (vshlcq_m_u16): Likewise.
> (vshlcq_m_s32): Likewise.
> (vshlcq_m_u32): Likewise.
> (__arm_vshlcq_m_s8): Define intrinsic.
> (__arm_vshlcq_m_u8): Likewise.
> (__arm_vshlcq_m_s16): Likewise.
> (__arm_vshlcq_m_u16): Likewise.
> (__arm_vshlcq_m_s32): Likewise.
> (__arm_vshlcq_m_u32): Likewise.
> (vshlcq_m): Define polymorphic variant.
> * config/arm/arm_mve_builtins.def
> (QUADOP_NONE_NONE_UNONE_IMM_UNONE):
> Use builtin qualifier.
> (QUADOP_UNONE_UNONE_UNONE_IMM_UNONE): Likewise.
> * config/arm/mve.md (mve_vshlcq_m_vec_): Define
> RTL pattern.
> (mve_vshlcq_m_carry_): Likewise.
> (mve_vshlcq_m_): Likewise.
>
> gcc/testsuite/ChangeLog:
>
> 2019-11-08 Srinath Parvathaneni
> Andre Vieira
> Mihail Ionescu
>
> * gcc.target/arm/mve/intrinsics/vshlcq_m_s16.c: New test.
> * gcc.target/arm/mve/intrinsics/vshlcq_m_s32.c: Likewise.
> * gcc.target/arm/mve/intrinsics/vshlcq_m_s8.c: Likewise.
> * gcc.target/arm/mve/intrinsics/vshlcq_m_u16.c: Likewise.
> * gcc.target/arm/mve/intrinsics/vshlcq_m_u32.c: Likewise.
> * gcc.target/arm/mve/intrinsics/vshlcq_m_u8.c: Likewise.
>
>
> ### Attachment also inlined for ease of reply
> ###
>
>
> diff --git a/gcc/config/arm/arm_mve.h b/gcc/config/arm/arm_mve.h index
> f2d80ee636003ac58f70ddc25db15e129e228906..14b6ec857bffd85b67c781f5
> 54faffde1b2abc6b 100644
> --- a/gcc/config/arm/arm_mve.h
> +++ b/gcc/config/arm/arm_mve.h
> @@ -2546,6 +2546,12 @@ typedef struct { uint8x16_t val[4]; } uint8x16x4_t;
> #define urshrl(__p0, __p1) __arm_urshrl(__p0, __p1) #define lsll(__p0, __p1)
> __arm_lsll(__p0, __p1) #define asrl(__p0, __p1) __arm_asrl(__p0, __p1)
> +#define vshlcq_m_s8(__a, __b, __imm, __p) __arm_vshlcq_m_s8(__a,
> +__b, __imm, __p) #define vshlcq_m_u8(__a, __b, __imm, __p)
> +__arm_vshlcq_m_u8(__a, __b, __imm, __p) #define vshlcq_m_s16(__a,
> +__b, __imm, __p) __arm_vshlcq_m_s16(__a, __b, __imm, __p) #define
> +vshlcq_m_u16(__a, __b, __imm, __p) __arm_vshlcq_m_u16(__a, __b,
> +__imm, __p) #define vshlcq_m_s32(__a, __b, __imm, __p)
> +__arm_vshlcq_m_s32(__a, __b, __imm, __p) #define vshlcq_m_u32(__a,
> +__b, __imm, __p) __arm_vshlcq_m_u32(__a, __b, __imm, __p)
> #endif
>
> /* For big-endian, GCC's vector indices are reversed within each 64 bits @@
> -16671,6 +16677,60 @@ __arm_srshr (int32_t value, const int shift)
>return __builtin_mve_srshr_si (value, shift); }
>
> +__extension__ extern __inline int8x16_t __attribute__
> +((__always_inline__, __gnu_inline__, __artificial__))
> +__arm_vshlcq_m_s8 (int8x16_t __a, uint32_t * __b, const int __imm,
> +mve_pred16_t __p) {
> + int8x16_t __res = __builtin_mve_vshlcq_m_vec_sv16qi (__a, *__b,
> +__imm, __p);
> + *__b = __builtin_mve_vshlcq_m_carry_sv16qi (__a, *__b, __imm, __p);
> + return __res;
> +}
> +
> +__extension__ extern __inline uint8x16_t __attribute__
> +((__always_inline__, __gnu_inline__, __artificial__))
> +__arm_vshlcq_m_u8 (uint8x16_t __a, uint32_t * __b, const int __imm,
> +mve_pred16_t __p) {
> + uint8x16_t __res = __builtin_mve_vshlcq_m_vec_uv16qi (__a, *__b,
> +__imm, __p);
> + *__b = __builtin_mve_vshlcq_m_carry_uv16qi (__a, *__b, __imm, __p);
> + return __res;
> +}
> +
> +__extension__ extern __inline int16x8_t __attribute__
> +((__always_inline__, __gnu_inline__, __artificial__))
> +__arm_vshlcq_m_s16 (int16x8_t __a, uint32_t * __b, const int __imm,
> +mve_pred16_t __p) {
> + int16x8_t __res = __builtin_mve_vshlcq_m_vec_sv8hi (__a, *__b, __imm,
> +__p);
> + *__b = __builtin_mve_vshlcq_m_carry_sv8hi (__a, *__b, __imm, __p);
> + return __res;
> +}
> +
> +__extension__ extern __inline uint16x8_t __attribute__
[PATCH] rs6000: Allow FPRs to change between SDmode and DDmode [PR94254]
g:497498c878d48754318e486428e2aa30854020b9 caused lra to cycle on some SDmode reloads for power6. As explained in more detail in the PR comments, the problem was a conflict between two target hooks: rs6000_secondary_memory_needed_mode required SDmode FPR reloads to use DDmode memory (rightly, since using SDmode memory wouldn't make progress) but rs6000_can_change_mode_class didn't allow FPRs to change from SDmode to DDmode. Previously lra ignored that and changed the mode anyway. >From what Segher says, it sounds like the "from_size < 8 || to_size < 8" check is mostly there for SF<->64-bit subregs, and that SDmode is stored in the way that target-independent code expects. This patch therefore allows SD<->DD changes. I wondered about checking for SD<->64-bit changes instead, but that seemed like an unnecessary generalisation for this stage. Bootstrapped and regression-tested on powerpc64le-unknown-linux-gnu, both with default settings and with --with-cpu=power6. (For power6 I reverted the lra patch to do the before testing, since the build hanged otherwise.) The patch fixed the regressing testcases and introduced no other test changes. Zdenek confirms that it also fixes powerpc-linux-gnu builds. OK to install? Richard 2020-03-23 Richard Sandiford gcc/ PR target/94254 * config/rs6000/rs6000.c (rs6000_can_change_mode_class): Allow FPRs to change between SDmode and DDmode. --- gcc/config/rs6000/rs6000.c | 9 + 1 file changed, 9 insertions(+) diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c index 07f7cf516ba..2354aceb3f7 100644 --- a/gcc/config/rs6000/rs6000.c +++ b/gcc/config/rs6000/rs6000.c @@ -12307,6 +12307,15 @@ rs6000_can_change_mode_class (machine_mode from, if (!BYTES_BIG_ENDIAN && (to == TDmode || from == TDmode)) return false; + /* Allow SD<->DD changes, since SDmode values are stored in +the low half of the DDmode, just like target-independent +code expects. We need to allow at least SD->DD since +rs6000_secondary_memory_needed_mode asks for that change +to be made for SD reloads. */ + if ((to == DDmode && from == SDmode) + || (to == SDmode && from == DDmode)) + return true; + if (from_size < 8 || to_size < 8) return false;
Re: [PATCH] c: Fix up cfun->function_end_locus on invalid function bodies [PR94239]
On Sat, Mar 21, 2020 at 09:40:24AM +0100, Jakub Jelinek wrote:
> Hi!
>
> On Thu, Mar 19, 2020 at 09:38:30PM +, Joseph Myers wrote:
> > The second patch is OK.
>
> Unfortunately the patch broke
> +FAIL: gcc.dg/pr20245-1.c (internal compiler error)
> +FAIL: gcc.dg/pr20245-1.c (test for excess errors)
> +FAIL: gcc.dg/pr28419.c (internal compiler error)
> +FAIL: gcc.dg/pr28419.c (test for excess errors)
> on some targets (and under valgrind on the rest of them).
>
> Those functions don't have the opening { and so c_parser_compound_statement
> returned error_mark_node before initializing *endlocp.
> So, either we can initialize it in that case too:
> --- gcc/c/c-parser.c 2020-03-20 22:09:39.659411721 +0100
> +++ gcc/c/c-parser.c 2020-03-21 09:36:44.455705261 +0100
> @@ -5611,6 +5611,8 @@ c_parser_compound_statement (c_parser *p
>if we have just prepared to enter a function body. */
>stmt = c_begin_compound_stmt (true);
>c_end_compound_stmt (brace_loc, stmt, true);
> + if (endlocp)
> + *endlocp = brace_loc;
>return error_mark_node;
> }
>stmt = c_begin_compound_stmt (true);
> or perhaps simpler initialize it to the function_start_locus at the
> beginning and have those functions without { have function_start_locus ==
> function_end_locus like the __GIMPLE functions (where propagating the
> closing } seemed too difficult).
>
> The following patch has been successfully bootstrapped/regtested on
> x86_64-linux and i686-linux and tested on the testcases under valgrind,
> ok for trunk (or do you prefer the above hunk instead)?
>
> 2020-03-21 Jakub Jelinek
>
> PR gcov-profile/94029
> PR c/94239
> * c-parser.c (c_parser_declaration_or_fndef): Initialize endloc to
> the function_start_locus location. Don't do that afterwards for the
> __GIMPLE body parsing.
I'm fine with this one, thanks.
Marek
Re: [PATCH] c++: Avoid a suspicious -Wnoexcept warning [PR93805]
On 3/22/20 5:14 PM, Patrick Palka wrote:
In this PR we're emitting -Wnoexcept warnings about potentially-throwing NSDMIs
when computing the noexcept specification of a class's defaulted default
constructor. Alhough these warnings are in some sense valid, this patch takes
the route of suppressing them, because:
1. the warning message is confusing in its current form;
2. warning for 'struct C { B b = B(); };' but not for 'struct C { B b; };'
is inconsistent; and
3. emitting a warning here arguably doesn't fall under the umbrella of
-Wnoexcept, whose documentation says it warns only when a
noexcept-expression evaluates to false, but there are noexcept-expressions
here.
Tested on x86_64-pc-linux-gnu, does this look OK to commit?
Let's add a comment to maybe_noexcept_warning suggesting that we might
in future want to do something like walk_subtrees in the case of a
defaulted function. OK with that change.
Jason
gcc/cp/ChangeLog:
PR c++/93805
* method.c (walk_field_subobs): Pass tf_none as the complain argument to
expr_noexcept_p.
gcc/testsuite/ChangeLog:
PR c++/93805
* g++.dg/warn/Wnoexcept2.C: New test.
---
gcc/cp/method.c| 2 +-
gcc/testsuite/g++.dg/warn/Wnoexcept2.C | 15 +++
2 files changed, 16 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/g++.dg/warn/Wnoexcept2.C
diff --git a/gcc/cp/method.c b/gcc/cp/method.c
index c131fd41536..41b9ff86bdd 100644
--- a/gcc/cp/method.c
+++ b/gcc/cp/method.c
@@ -1988,7 +1988,7 @@ walk_field_subobs (tree fields, special_function_kind
sfk, tree fnname,
if (nsdmi == error_mark_node)
*spec_p = error_mark_node;
else if (*spec_p != error_mark_node
- && !expr_noexcept_p (nsdmi, complain))
+ && !expr_noexcept_p (nsdmi, tf_none))
*spec_p = noexcept_false_spec;
}
/* Don't do the normal processing. */
diff --git a/gcc/testsuite/g++.dg/warn/Wnoexcept2.C
b/gcc/testsuite/g++.dg/warn/Wnoexcept2.C
new file mode 100644
index 000..60541be3575
--- /dev/null
+++ b/gcc/testsuite/g++.dg/warn/Wnoexcept2.C
@@ -0,0 +1,15 @@
+// PR c++/93805
+// { dg-do compile { target c++11 } }
+// { dg-additional-options "-Wnoexcept" }
+
+struct B
+{
+ B() {}
+};
+
+struct C
+{
+ B b = B();
+};
+
+C c; // { dg-bogus "noexcept-expression" }
Re: [PATCH] c++: Avoid a suspicious -Wnoexcept warning [PR93805]
On Mon, 23 Mar 2020, Jason Merrill wrote:
> On 3/22/20 5:14 PM, Patrick Palka wrote:
> > In this PR we're emitting -Wnoexcept warnings about potentially-throwing
> > NSDMIs
> > when computing the noexcept specification of a class's defaulted default
> > constructor. Alhough these warnings are in some sense valid, this patch
> > takes
> > the route of suppressing them, because:
> >
> >1. the warning message is confusing in its current form;
> >2. warning for 'struct C { B b = B(); };' but not for 'struct C { B b;
> > };'
> > is inconsistent; and
> >3. emitting a warning here arguably doesn't fall under the umbrella of
> > -Wnoexcept, whose documentation says it warns only when a
> > noexcept-expression evaluates to false, but there are
> > noexcept-expressions
> > here.
> >
> > Tested on x86_64-pc-linux-gnu, does this look OK to commit?
>
> Let's add a comment to maybe_noexcept_warning suggesting that we might in
> future want to do something like walk_subtrees in the case of a defaulted
> function. OK with that change.
>
> Jason
Thanks, patch committed with a comment to that effect added to
maybe_noexcept_warning. Here is the final patch:
-- >8 --
gcc/cp/ChangeLog:
PR c++/93805
* except.c (maybe_noexcept_warning): Add TODO comment.
* method.c (walk_field_subobs): Pass tf_none to expr_noexcept_p.
gcc/testsuite/ChangeLog:
PR c++/93805
* g++.dg/warn/Wnoexcept2.C: New test.
---
gcc/cp/ChangeLog | 6 ++
gcc/cp/except.c| 5 -
gcc/cp/method.c| 2 +-
gcc/testsuite/ChangeLog| 5 +
gcc/testsuite/g++.dg/warn/Wnoexcept2.C | 15 +++
5 files changed, 31 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/warn/Wnoexcept2.C
diff --git a/gcc/cp/ChangeLog b/gcc/cp/ChangeLog
index 3340f47d506..59db03c0b07 100644
--- a/gcc/cp/ChangeLog
+++ b/gcc/cp/ChangeLog
@@ -1,3 +1,9 @@
+2020-03-23 Patrick Palka
+
+ PR c++/93805
+ * except.c (maybe_noexcept_warning): Add TODO.
+ * method.c (walk_field_subobs): Pass tf_none to expr_noexcept_p.
+
2020-03-23 nathans
PR c++/94044
diff --git a/gcc/cp/except.c b/gcc/cp/except.c
index 262ba5d309c..7e93c51f9ea 100644
--- a/gcc/cp/except.c
+++ b/gcc/cp/except.c
@@ -1160,7 +1160,10 @@ struct GTY(()) pending_noexcept {
static GTY(()) vec *pending_noexcept_checks;
/* FN is a FUNCTION_DECL that caused a noexcept-expr to be false. Warn if
- it can't throw. */
+ it can't throw.
+
+ TODO: Consider extending -Wnoexcept to do something like walk_subtrees in
the
+ case of a defaulted function that obtained a noexcept(false) spec. */
static void
maybe_noexcept_warning (tree fn)
diff --git a/gcc/cp/method.c b/gcc/cp/method.c
index c131fd41536..41b9ff86bdd 100644
--- a/gcc/cp/method.c
+++ b/gcc/cp/method.c
@@ -1988,7 +1988,7 @@ walk_field_subobs (tree fields, special_function_kind
sfk, tree fnname,
if (nsdmi == error_mark_node)
*spec_p = error_mark_node;
else if (*spec_p != error_mark_node
- && !expr_noexcept_p (nsdmi, complain))
+ && !expr_noexcept_p (nsdmi, tf_none))
*spec_p = noexcept_false_spec;
}
/* Don't do the normal processing. */
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 1d053e07721..5f079f1fca9 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,8 @@
+2020-03-23 Patrick Palka
+
+ PR c++/93805
+ * g++.dg/warn/Wnoexcept2.C: New test.
+
2020-03-23 Jakub Jelinek
PR c++/91993
diff --git a/gcc/testsuite/g++.dg/warn/Wnoexcept2.C
b/gcc/testsuite/g++.dg/warn/Wnoexcept2.C
new file mode 100644
index 000..60541be3575
--- /dev/null
+++ b/gcc/testsuite/g++.dg/warn/Wnoexcept2.C
@@ -0,0 +1,15 @@
+// PR c++/93805
+// { dg-do compile { target c++11 } }
+// { dg-additional-options "-Wnoexcept" }
+
+struct B
+{
+ B() {}
+};
+
+struct C
+{
+ B b = B();
+};
+
+C c; // { dg-bogus "noexcept-expression" }
--
2.26.0.rc1.11.g30e9940356
rs6000 - allow builtin initialization regardless of mask
rs6000 - allow builtin initialization regardless of mask
Hi,
Disable the code that limits initialization of builtins based
on the rs6000_builtin_mask. This allows all built-ins to be
properly referenced when building code using #pragma for cpu
targets newer than what was specified by the -mcpu default.
The use of built-ins is still properly limited by logic within
altivec_resolve_overloaded_builtin().
I'm still reviewing test results for any regressions.
OK for master?
Thanks,
-Will
2020-03-23 Will Schmidt
gcc/
* config/rs6000/rs6000-call.c altivec_init_builtins(): Remove code
to skip defining builtins based on builtin_mask.
testsuite/
* gcc.target/powerpc/pragma6.c: New.
* gcc.target/powerpc/pragma7.c: New.
* gcc.target/powerpc/pragma8.c: New.
* gcc.target/powerpc/pragma9.c: New.
* gcc.target/powerpc/pragma_misc9.c: New.
* gcc.target/powerpc/vsu/vec-all-nez-7.c: Update error message.
* gcc.target/powerpc/vsu/vec-any-eqz-7.c: Update error message.
diff --git a/gcc/config/rs6000/rs6000-call.c b/gcc/config/rs6000/rs6000-call.c
index 5906064..e08621a 100644
--- a/gcc/config/rs6000/rs6000-call.c
+++ b/gcc/config/rs6000/rs6000-call.c
@@ -12067,11 +12067,10 @@ altivec_init_builtins (void)
{
const struct builtin_description *d;
size_t i;
tree ftype;
tree decl;
- HOST_WIDE_INT builtin_mask = rs6000_builtin_mask;
tree pvoid_type_node = build_pointer_type (void_type_node);
tree pcvoid_type_node
= build_pointer_type (build_qualified_type (void_type_node,
@@ -12429,39 +12428,21 @@ altivec_init_builtins (void)
/* Add the DST variants. */
d = bdesc_dst;
for (i = 0; i < ARRAY_SIZE (bdesc_dst); i++, d++)
{
- HOST_WIDE_INT mask = d->mask;
-
/* It is expected that these dst built-in functions may have
d->icode equal to CODE_FOR_nothing. */
- if ((mask & builtin_mask) != mask)
- {
- if (TARGET_DEBUG_BUILTIN)
- fprintf (stderr, "altivec_init_builtins, skip dst %s\n",
-d->name);
- continue;
- }
def_builtin (d->name, void_ftype_pcvoid_int_int, d->code);
}
/* Initialize the predicates. */
d = bdesc_altivec_preds;
for (i = 0; i < ARRAY_SIZE (bdesc_altivec_preds); i++, d++)
{
machine_mode mode1;
tree type;
- HOST_WIDE_INT mask = d->mask;
-
- if ((mask & builtin_mask) != mask)
- {
- if (TARGET_DEBUG_BUILTIN)
- fprintf (stderr, "altivec_init_builtins, skip predicate %s\n",
-d->name);
- continue;
- }
if (rs6000_overloaded_builtin_p (d->code))
mode1 = VOIDmode;
else
{
@@ -12504,19 +12485,10 @@ altivec_init_builtins (void)
d = bdesc_abs;
for (i = 0; i < ARRAY_SIZE (bdesc_abs); i++, d++)
{
machine_mode mode0;
tree type;
- HOST_WIDE_INT mask = d->mask;
-
- if ((mask & builtin_mask) != mask)
- {
- if (TARGET_DEBUG_BUILTIN)
- fprintf (stderr, "altivec_init_builtins, skip abs %s\n",
-d->name);
- continue;
- }
/* Cannot define builtin if the instruction is disabled. */
gcc_assert (d->icode != CODE_FOR_nothing);
mode0 = insn_data[d->icode].operand[0].mode;
diff --git a/gcc/testsuite/gcc.target/powerpc/pragma_misc9.c
b/gcc/testsuite/gcc.target/powerpc/pragma_misc9.c
new file mode 100644
index 000..a861895
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/pragma_misc9.c
@@ -0,0 +1,47 @@
+/* { dg-do compile { target { powerpc*-*-* } } } */
+/* { dg-require-effective-target powerpc_p9vector_ok } */
+/* { dg-require-effective-target lp64 } */
+/* { dg-options "-mdejagnu-cpu=power9 -maltivec -O2" } */
+
+/* Ensure that if we set a pragma gcc target for an
+ older processor, we do not compile builtins that
+ the older target does not support. */
+
+#include
+
+vector bool int
+test1 (vector signed int a, vector signed int b)
+{
+ return vec_cmpnez (a, b);
+}
+
+#pragma GCC target ("cpu=power8")
+vector bool int
+test2 (vector signed int a, vector signed int b)
+{
+ return vec_cmpnez (a, b);
+ /* { dg-error "'__builtin_altivec_vcmpnezw' requires the '-mcpu=power9'
option" "" { target *-*-* } .-1 } */
+}
+
+#pragma GCC target ("cpu=power7")
+vector signed int
+test3 (vector signed int a, vector signed int b)
+{
+ return vec_mergee (a, b);
+ /* { dg-error "'__builtin_altivec_vmrgew_v4si' requires the
'-mpower8-vector' option" "" { target *-*-* } .-1 } */
+}
+
+#pragma GCC target ("cpu=power6")
+vector signed int
+test4 (vector int a, vector int b)
+{
+ return vec_sldw (a, b, 2);
+ /* { dg-error "'__builtin_vsx_xxsldwi_4si' requires the '-mvsx' option" "" {
target *-*-* } .-1 } */
+}
+
+vector int
+test5 (vector int a, vector int b)
+{
+ return vec_add (a, b);
+}
+
diff --git a/gcc/testsuite/gcc.target/powerpc/pragma_power6.c
b/g
[PATCH], Set -mpcrel by default on Linux 64-bit systems for -mcpu=future
This is a revision of a patch that I've submitted several times. It makes
-mpcrel the default on Linux 64-bit systems that use ELF v2, use the medium
code mode, and if the user did not disable prefixed load/store instructions for
-mcpu=future.
Previous versions of the patch had two macros that the target os could set, one
to say that the target os supported prefixed instructions with large numeric
offsets, and the second whether PC-relative prefixed load/store instructions
could be generated. Segher asked that we drop the capability to configure
whether prefixed numeric load/store instructions would be enabled by default,
and this patch does this. All of the PC-relative support is in the master
branch, we just need to enable it by default.
Is this patch acceptable to be committed to the master branch. I have done
various tests with this patch, including most recently bootstraping and running
make check. I have built the Spec 2017 benchmark suite with this patch.
2020-03-23 Michael Meissner
* config/rs6000/linux64.h (PCREL_SUPPORTED_BY_OS): Enable -mpcrel
for -mcpu=future by default on 64-bit systems with medium code
model.
* config/rs6000/rs6000-cpus.def (ISA_FUTURE_MASKS_SERVER): Do not
define the bits for -mprefixed or -mpcrel here.
(OTHER_FUTURE_MASKS): Define the bits for -mprefixed and -mpcrel
here.
* config/rs6000/rs6000.c (PCREL_SUPPORTED_BY_OS): If not defined,
don't enable -mpcrel by default.
(rs6000_option_override_internal): Enable -mpcrel on systems that
support it, if the user did not do -mno-pcrel.
--- /tmp/QuuFm5_linux64.h 2020-03-20 20:15:38.321862650 -0400
+++ gcc/config/rs6000/linux64.h 2020-03-20 18:36:33.654484833 -0400
@@ -640,3 +640,11 @@ extern int dot_symbols;
enabling the __float128 keyword. */
#undef TARGET_FLOAT128_ENABLE_TYPE
#define TARGET_FLOAT128_ENABLE_TYPE 1
+
+/* Enable support for PC-relative addressing on the 'future' system. Currently
+ this support only exits for the ELF v2 object file format using the medium
+ code model. */
+#undef PCREL_SUPPORTED_BY_OS
+#define PCREL_SUPPORTED_BY_OS (TARGET_FUTURE && TARGET_PREFIXED \
+&& ELFv2_ABI_CHECK \
+&& (TARGET_CMODEL == CMODEL_MEDIUM))
--- /tmp/sO5cAE_rs6000-cpus.def 2020-03-20 20:15:38.331862575 -0400
+++ gcc/config/rs6000/rs6000-cpus.def 2020-03-20 17:05:17.347638233 -0400
@@ -75,11 +75,10 @@
| OPTION_MASK_P8_VECTOR\
| OPTION_MASK_P9_VECTOR)
-/* Support for a future processor's features. Do not enable -mpcrel until it
- is fully functional. */
+/* Support for a future processor's features. The addressing related options
+ (like -mprefixed, -mpcrel) are not set here. */
#define ISA_FUTURE_MASKS_SERVER(ISA_3_0_MASKS_SERVER
\
-| OPTION_MASK_FUTURE \
-| OPTION_MASK_PREFIXED)
+| OPTION_MASK_FUTURE)
/* Flags that need to be turned off if -mno-future. */
#define OTHER_FUTURE_MASKS (OPTION_MASK_PCREL \
--- /tmp/xQt3Pd_rs6000.c2020-03-20 20:15:38.343862485 -0400
+++ gcc/config/rs6000/rs6000.c 2020-03-20 20:11:02.942928364 -0400
@@ -98,6 +98,12 @@
#endif
#endif
+/* Set up the defaults for whether PC-relative addressing is supported by the
+ target system. */
+#ifndef PCREL_SUPPORTED_BY_OS
+#define PCREL_SUPPORTED_BY_OS 0
+#endif
+
/* Support targetm.vectorize.builtin_mask_for_load. */
tree altivec_builtin_mask_for_load;
@@ -4012,6 +4018,11 @@ rs6000_option_override_internal (bool gl
rs6000_isa_flags &= ~OPTION_MASK_FLOAT128_HW;
}
+ /* Enable -mprefixed by default on 64-bit 'future' systems. */
+ if (TARGET_FUTURE && TARGET_POWERPC64
+ && (rs6000_isa_flags_explicit & OPTION_MASK_PREFIXED) == 0)
+rs6000_isa_flags |= OPTION_MASK_PREFIXED;
+
/* -mprefixed (and hence -mpcrel) requires -mcpu=future. */
if (TARGET_PREFIXED && !TARGET_FUTURE)
{
@@ -4173,6 +4184,11 @@ rs6000_option_override_internal (bool gl
rs6000_isa_flags &= ~OPTION_MASK_PCREL;
}
+ /* If the OS has support for PC-relative relocations, enable it now. */
+ if (PCREL_SUPPORTED_BY_OS
+ && (rs6000_isa_flags_explicit & OPTION_MASK_PCREL) == 0)
+rs6000_isa_flags |= OPTION_MASK_PCREL;
+
if (TARGET_DEBUG_REG || TARGET_DEBUG_TARGET)
rs6000_print_isa_options (stderr, 0, "after subtarget", rs6000_isa_flags);
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797
[committed] [P1][PR target/94238] Don't create invalid comparisons
As outlined in the BZ simplify_logical_relational_operation does not validate
that the comparison code it selects is ultimately valid for the mode of the
comparison.
So we could have something like:
(ior (lt (...)) (gt (...))
Which it happily turns into
(ltgt (...))
Which is not valid for integral modes.
This patch validates the selected comparison code is valid for the comparison's
mode using the rules in rtl.def. It's always safe to reject a particular
simplification.
I've also verified this fixes 94144 which is a similar problem showing up on
aarch64 and that it doesn't cause regressions in the tester.
I'm committing this to the trunk.
Jeff
commit fd25ae64e3ffaa95abb60e74af45031d2f5f900f
Author: Jeff Law
Date: Mon Mar 23 17:55:20 2020 -0600
Verify the code used for the optimized comparison is
valid for the comparison's mode.
PR rtl-optimization/90275
PR target/94238
PR target/94144
* simplify-rtx.c (comparison_code_valid_for_mode): New function.
(simplify_logical_relational_operation): Use it.
PR target/94144
PR target/94238
* gcc.c-torture/compile/pr94144.c: New test.
* gcc.c-torture/compile/pr94238.c: New test.
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 9ba58273c21..3b926703957 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,11 @@
+2020-03-23 Jeff Law
+
+ PR rtl-optimization/90275
+ PR target/94238
+ PR target/94144
+ * simplify-rtx.c (comparison_code_valid_for_mode): New function.
+ (simplify_logical_relational_operation): Use it.
+
2020-03-23 Jakub Jelinek
PR c++/91993
diff --git a/gcc/simplify-rtx.c b/gcc/simplify-rtx.c
index dd3d85156c3..28c2dc69ae7 100644
--- a/gcc/simplify-rtx.c
+++ b/gcc/simplify-rtx.c
@@ -2215,6 +2215,53 @@ mask_to_comparison (int mask)
}
}
+/* Return true if CODE is valid for comparisons of mode MODE, false
+ otherwise.
+
+ It is always safe to return false, even if the code was valid for the
+ given mode as that will merely suppress optimizations. */
+
+static bool
+comparison_code_valid_for_mode (enum rtx_code code, enum machine_mode mode)
+{
+ switch (code)
+{
+ /* These are valid for integral, floating and vector modes. */
+ case NE:
+ case EQ:
+ case GE:
+ case GT:
+ case LE:
+ case LT:
+ return (INTEGRAL_MODE_P (mode)
+ || FLOAT_MODE_P (mode)
+ || VECTOR_MODE_P (mode));
+
+ /* These are valid for floating point modes. */
+ case LTGT:
+ case UNORDERED:
+ case ORDERED:
+ case UNEQ:
+ case UNGE:
+ case UNGT:
+ case UNLE:
+ case UNLT:
+ return FLOAT_MODE_P (mode);
+
+ /* These are filtered out in simplify_logical_operation, but
+we check for them too as a matter of safety. They are valid
+for integral and vector modes. */
+ case GEU:
+ case GTU:
+ case LEU:
+ case LTU:
+ return INTEGRAL_MODE_P (mode) || VECTOR_MODE_P (mode);
+
+ default:
+ gcc_unreachable ();
+}
+}
+
/* Simplify a logical operation CODE with result mode MODE, operating on OP0
and OP1, which should be both relational operations. Return 0 if no such
simplification is possible. */
@@ -2252,6 +2299,10 @@ simplify_logical_relational_operation (enum rtx_code
code, machine_mode mode,
code = mask_to_comparison (mask);
+ /* Many comparison codes are only valid for certain mode classes. */
+ if (!comparison_code_valid_for_mode (code, mode))
+return 0;
+
op0 = XEXP (op1, 0);
op1 = XEXP (op1, 1);
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 5f079f1fca9..28adfd8b580 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,10 @@
+2020-03-23 Jeff Law
+
+ PR target/94144
+ PR target/94238
+ * gcc.c-torture/compile/pr94144.c: New test.
+ * gcc.c-torture/compile/pr94238.c: New test.
+
2020-03-23 Patrick Palka
PR c++/93805
diff --git a/gcc/testsuite/gcc.c-torture/compile/pr94144.c
b/gcc/testsuite/gcc.c-torture/compile/pr94144.c
new file mode 100644
index 000..4358e0a7b00
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/compile/pr94144.c
@@ -0,0 +1,18 @@
+
+int a, b, z;
+int c(int d, int e) { return d && e > 0 && d > 5 - e ? 0 : d + e; }
+int k();
+void h(int);
+void f(short d) {
+ int g = !(0 < d);
+ h(d);
+ if (b) {
+unsigned i[1];
+i[0] = g = 0;
+for (; g <= 8; g++)
+ d || k();
+if (c(!(i[0] <= z) >= d, d) != a)
+ k();
+ }
+}
+
diff --git a/gcc/testsuite/gcc.c-torture/compile/pr94238.c
b/gcc/testsuite/gcc.c-torture/compile/pr94238.c
new file mode 100644
index 000..5a96a64d85b
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/compile/pr94238.c
@@ -0,0 +1,22 @@
+enum { false, true } a;
+int b, c, d, e, f;
+int fn3()
Re: [PATCH] Add C++2a wait/notify_one/notify_all support to std::atomic<>
Updated patch, fixes some whitespace issues along with ensuring that
libstdc++-v3/include/Makefile.in is regenerated.
>From 2f707faab97abde776bc7c6e06f7a7c471711962 Mon Sep 17 00:00:00 2001
From: Thomas Rodgers
Date: Thu, 12 Mar 2020 17:50:09 -0700
Subject: [PATCH] Add C++2a wait/notify_one/notify_all support to std::atomic<>
* include/Makefile.am (bits_headers): Add new header.
* include/Makefile.in: Regenerate.
* include/bits/atomic_base.h (__atomic_base<_Itp>:wait): Define.
(__atomic_base<_Itp>::notify_one): Likewise.
(__atomic_base<_Itp>::notify_all): Likewise.
(__atomic_base<_Ptp*>::wait): Likewise.
(__atomic_base<_Ptp*>::notify_one): Likewise.
(__atomic_base<_Ptp*>::notify_all): Likewise.
(__atomic_impl::wait): Likewise.
(__atomic_impl::notify_one): Likewise.
(__atomic_impl::notify_all): Likewise.
(__atomic_float<_Fp>::wait): Likewise.
(__atomic_float<_Fp>::notify_one): Likewise.
(__atomic_float<_Fp>::notify_all): Likewise.
(__atomic_ref<_Tp>::wait): Likewise.
(__atomic_ref<_Tp>::notify_one): Likewise.
(__atomic_ref<_Tp>::notify_all): Likewise.
(atomic_wait<_Tp>): Likewise.
(atomic_wait_explicit<_Tp>): Likewise.
(atomic_notify_one<_Tp>): Likewise.
(atomic_notify_all<_Tp>): Likewise.
* include/bits/atomic_wait.h: New file.
* include/std/atomic (atomic::wait): Define.
(atomic::wait_one): Likewise.
(atomic::wait_all): Likewise.
(atomic<_Tp>::wait): Likewise.
(atomic<_Tp>::wait_one): Likewise.
(atomic<_Tp>::wait_all): Likewise.
(atomic<_Tp*>::wait): Likewise.
(atomic<_Tp*>::wait_one): Likewise.
(atomic<_Tp*>::wait_all): Likewise.
* testsuite/29_atomic/atomic/wait_notify/atomic_refs.cc: New test.
* testsuite/29_atomic/atomic/wait_notify/bool.cc: Likewise.
* testsuite/29_atomic/atomic/wait_notify/integrals.cc: Likewise.
* testsuite/29_atomic/atomic/wait_notify/floats.cc: Likewise.
* testsuite/29_atomic/atomic/wait_notify/pointers.cc: Likewise.
* testsuite/29_atomic/atomic/wait_notify/generic.h: New File.
Tested x86_64-pc-linux-gnu.
---
libstdc++-v3/include/Makefile.am | 1 +
libstdc++-v3/include/Makefile.in | 1 +
libstdc++-v3/include/bits/atomic_base.h | 178 ++-
libstdc++-v3/include/bits/atomic_wait.h | 284 ++
libstdc++-v3/include/std/atomic | 61
.../atomic/wait_notify/atomic_refs.cc | 103 +++
.../29_atomics/atomic/wait_notify/bool.cc | 57
.../29_atomics/atomic/wait_notify/floats.cc | 32 ++
.../29_atomics/atomic/wait_notify/generic.h | 88 ++
.../atomic/wait_notify/integrals.cc | 56
.../29_atomics/atomic/wait_notify/pointers.cc | 59
11 files changed, 919 insertions(+), 1 deletion(-)
create mode 100644 libstdc++-v3/include/bits/atomic_wait.h
create mode 100644 libstdc++-v3/testsuite/29_atomics/atomic/wait_notify/atomic_refs.cc
create mode 100644 libstdc++-v3/testsuite/29_atomics/atomic/wait_notify/bool.cc
create mode 100644 libstdc++-v3/testsuite/29_atomics/atomic/wait_notify/floats.cc
create mode 100644 libstdc++-v3/testsuite/29_atomics/atomic/wait_notify/generic.h
create mode 100644 libstdc++-v3/testsuite/29_atomics/atomic/wait_notify/integrals.cc
create mode 100644 libstdc++-v3/testsuite/29_atomics/atomic/wait_notify/pointers.cc
diff --git a/libstdc++-v3/include/Makefile.am b/libstdc++-v3/include/Makefile.am
index 80aeb3f8959..d195a721fd5 100644
--- a/libstdc++-v3/include/Makefile.am
+++ b/libstdc++-v3/include/Makefile.am
@@ -100,6 +100,7 @@ bits_headers = \
${bits_srcdir}/allocated_ptr.h \
${bits_srcdir}/allocator.h \
${bits_srcdir}/atomic_base.h \
+ ${bits_srcdir}/atomic_wait.h \
${bits_srcdir}/atomic_futex.h \
${bits_srcdir}/basic_ios.h \
${bits_srcdir}/basic_ios.tcc \
diff --git a/libstdc++-v3/include/Makefile.in b/libstdc++-v3/include/Makefile.in
index eb437ad8d8d..f19c3342f06 100644
--- a/libstdc++-v3/include/Makefile.in
+++ b/libstdc++-v3/include/Makefile.in
@@ -445,6 +445,7 @@ bits_headers = \
${bits_srcdir}/allocated_ptr.h \
${bits_srcdir}/allocator.h \
${bits_srcdir}/atomic_base.h \
+ ${bits_srcdir}/atomic_wait.h \
${bits_srcdir}/atomic_futex.h \
${bits_srcdir}/basic_ios.h \
${bits_srcdir}/basic_ios.tcc \
diff --git a/libstdc++-v3/include/bits/atomic_base.h b/libstdc++-v3/include/bits/atomic_base.h
index 87fe0bd6000..b4fbe2c6eb3 100644
--- a/libstdc++-v3/include/bits/atomic_base.h
+++ b/libstdc++-v3/include/bits/atomic_base.h
@@ -37,6 +37,11 @@
#include
#include
+#if __cplusplus > 201703L
+#include
+#include
+#endif
+
#ifndef _GLIBCXX_ALWAYS_INLINE
#define _GLIBCXX_ALWAYS_INLINE inline __attribute__((__always_inline__))
#endif
@@ -134,7 +139,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
return __ret;
}
-
// Base types for atomics.
template
struct __atomic_base;
@@ -542,6 +546,35 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
__cmpexch_failure_order(__m));
}
+#if __cplusplus > 201703L
+ _GLIBCXX_ALWAYS_INLINE void
+ wait(__int_typ
[PING 2][PATCH] issue -Walloca even when alloca is a system header macro [PR94004]
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542113.html On 3/16/20 6:00 PM, Martin Sebor wrote: On 3/16/20 3:41 PM, Jeff Law wrote: On Mon, 2020-03-16 at 11:39 -0600, Martin Sebor via Gcc-patches wrote: Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-March/541521.html I think Jakub indicated the test was incorrect. Please resolve that issue and repost. I think the core patch is OK, so we just need to fixup the test. The test is correct as is, it just doesn't exercise the fix when there's no that defines alloca as a macro (i.e., in the case that doesn't matter). It passes either way, but it doesn't pass with Jakub's suggestion. I didn't look into why. Anyway, attached is an updated patch with a modified test that does exercise the fix regardless of whether or not the system does have an alloca macro in its header. Martin
RE: [PATCH PR94026] combine missed opportunity to simplify comparisons with zero
Hi! > -Original Message- > From: Segher Boessenkool [mailto:seg...@kernel.crashing.org] > Sent: Monday, March 23, 2020 8:10 PM > To: Yangfei (Felix) > Cc: gcc-patches@gcc.gnu.org; Zhanghaijian (A) > Subject: Re: [PATCH PR94026] combine missed opportunity to simplify > comparisons with zero > > Yeah, maybe not in simplify-rtx.c, hrm. There is SELECT_CC_MODE for these > things, and combine knows about that (not many passes do). I modified combine emitting a simple AND operation instead of making one zero_extract for this scenario. Attached please find the new patch. Hope this solves both of our concerns. gcc +2020-03-24 Felix Yang + + PR rtl-optimization/94026 + * combine.c (make_compound_operation_int): If we are have (and + (lshiftrt X C) M) and M is a constant that would select a field + of bits within an item, but not the entire word, fold this into + a simple AND if we are in an equality comparison. gcc/testsuite +2020-03-24 Felix Yang + + PR rtl-optimization/94026 + * gcc.dg/pr94026.c: New test. Thanks, Felix pr94026-v1.patch Description: pr94026-v1.patch
[PATCH] Fix handling of --with{,out}-zstd option.
Hi. The patch respects --without-zstd and reports an error when we can't find header file with --with-zstd. Ready to be installed? Thanks, Martin gcc/ChangeLog: 2020-03-23 Martin Liska PR lto/94259 * configure.ac: Respect --without-zstd and report error when we can't find header file with --with-zstd. * configure: Regenerate. --- gcc/configure| 13 + gcc/configure.ac | 9 +++-- 2 files changed, 16 insertions(+), 6 deletions(-) diff --git a/gcc/configure b/gcc/configure index 5381e107bce..b4231fe7b7e 100755 --- a/gcc/configure +++ b/gcc/configure @@ -9962,13 +9962,15 @@ fi case "x$with_zstd" in x) ;; xno) -ZSTD_INCLUDE=no -ZSTD_LIB=no +ZSTD_INCLUDE= +ZSTD_LIB= ;; *) ZSTD_INCLUDE=$with_zstd/include ZSTD_LIB=$with_zstd/lib ;; esac + +if test "x$with_zstd" != xno; then if test "x$with_zstd_include" != x; then ZSTD_INCLUDE=$with_zstd_include fi @@ -10017,6 +10019,8 @@ if test $gcc_cv_header_zstd_h = yes; then $as_echo "#define HAVE_ZSTD_H 1" >>confdefs.h +else +as_fn_error $? "Unable to find zstd.h. See config.log for details." "$LINENO" 5 fi # LTO can use zstd compression algorithm @@ -10081,6 +10085,7 @@ fi ZSTD_LIB="$LIBS" LIBS="$save_LIBS" +fi @@ -18980,7 +18985,7 @@ else lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 lt_status=$lt_dlunknown cat > conftest.$ac_ext <<_LT_EOF -#line 18983 "configure" +#line 18988 "configure" #include "confdefs.h" #if HAVE_DLFCN_H @@ -19086,7 +19091,7 @@ else lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 lt_status=$lt_dlunknown cat > conftest.$ac_ext <<_LT_EOF -#line 19089 "configure" +#line 19094 "configure" #include "confdefs.h" #if HAVE_DLFCN_H diff --git a/gcc/configure.ac b/gcc/configure.ac index 0d6230e0ca1..0051963c85d 100644 --- a/gcc/configure.ac +++ b/gcc/configure.ac @@ -1334,13 +1334,15 @@ AC_ARG_WITH(zstd-lib, case "x$with_zstd" in x) ;; xno) -ZSTD_INCLUDE=no -ZSTD_LIB=no +ZSTD_INCLUDE= +ZSTD_LIB= ;; *) ZSTD_INCLUDE=$with_zstd/include ZSTD_LIB=$with_zstd/lib ;; esac + +if test "x$with_zstd" != xno; then if test "x$with_zstd_include" != x; then ZSTD_INCLUDE=$with_zstd_include fi @@ -1369,6 +1371,8 @@ AC_MSG_RESULT($gcc_cv_header_zstd_h) if test $gcc_cv_header_zstd_h = yes; then AC_DEFINE(HAVE_ZSTD_H, 1, [Define if you have a working header file.]) +else +as_fn_error $? "Unable to find zstd.h. See config.log for details." "$LINENO" 5 fi # LTO can use zstd compression algorithm @@ -1378,6 +1382,7 @@ AC_SEARCH_LIBS(ZSTD_compress, zstd) ZSTD_LIB="$LIBS" LIBS="$save_LIBS" AC_SUBST(ZSTD_LIB) +fi dnl Disabled until we have a complete test for buggy enum bitfields. dnl gcc_AC_C_ENUM_BF_UNSIGNED
