[PATCH PR94201] aarch64：ICE in tiny code model for ilp32
Hi The testcase pr78255.c triggers ice when testing GCC trunk on aarch64 with -mabi=ilp32 -fPIC. Case path: gcc/testsuite/gcc.target/aarch64/pr78255.c The ICE is caused by insufficient support for the tiny code model under ilp32 mode with fPIC option, where a SI mode register might be used for the ldr instruction. However, current md pattern for UNSPEC_GOTTINYPIC only support DI mode register as its operator. A simple solution is to add the pattern in tiny code model to support ilp32 mode. Attached please find the proposed patch. Newly add test fail without the patch and pass after applying the patch. Bootstrap and tested on aarch64 Linux platform. No new regression witnessed. Any suggestion? Thanks, Duan bo Log: gcc: +2020-03-16 Duan bo + + PR c/94201 + * config/aarch64/aarch64.md (ldr_got_tiny_): New pattern. + (ldr_got_tiny_sidi): Likewise. + * config/aarch64/aarch64.c: new pattern added to support ilp32 in tiny code model. gcc/testsuite: +2020-03-16 Duan bo + + PR c/94201 + * gcc.target/aarch64/pr94201.c：New test. pr94201-v0.patch Description: pr94201-v0.patch
RE: [PATCH PR94026] combine missed opportunity to simplify comparisons with zero
Hi, > -Original Message- > From: Segher Boessenkool [mailto:seg...@kernel.crashing.org] > Sent: Tuesday, March 17, 2020 1:58 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 Mon, Mar 16, 2020 at 06:29:39AM +, Yangfei (Felix) wrote: > > Sorry for not getting your point here. > > Trying 7 -> 8: > 7: r99:SI=r103:SI>>0x8 > REG_DEAD r103:SI > 8: r100:SI=r99:SI&0x6 > REG_DEAD r99:SI > Failed to match this instruction: > (set (reg:SI 100) > (and:SI (lshiftrt:SI (reg:SI 103) > (const_int 8 [0x8])) > (const_int 6 [0x6]))) > > That should match already, perhaps with a splitter. aarch64 does not have > very generic rotate-and-mask (or -insert) instructions, so the > aarch64 backend needs to help combine with the less trivial cases. > > If you have a splitter for *this* one, all else will probably work > "automatically": you split it to two ubfm, and the second of those can then > merge into the compare instruction, and everything works out. Do you mean splitting the above pattern into a combination of ubfx and ubfiz? (Both are aliases of ubfm). I still don't see how the benefit can be achieved. The following is the expected assembly for the test case: tst x0, 1536 csetw0, ne ret This may not happen when the remaining ubfx is there. Also what instruction be matched when ubfiz is merged into the compare? Anything I missed? > > Also, this issue is there for ports like x86. If we go that way, then we > > need > to handle each port affected. > > Yes, you need to do target-specific stuff in every backend separately. > > > So I am inclined to handle this in an arch-independent way. > > But you don't. The transformation you do looks to be actively harmful on > many targets. (I haven't tested it yet, that takes 8h currently). Now I know your concern about zero_extract. Maybe this should be mentioned in docs like gccint. Also it's interesting to see how this may affect on those archs. Thanks, Felix
Re: [PATCH v2] c++: Fix wrong no post-decrement operator error in template [PR94190]
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 &() 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 &() 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.
* g++.dg/conversion/op7.C: New test.
---
gcc/cp/call.c | 3 +++
gcc/testsuite/g++.dg/conversion/op7.C | 22 ++
2 files changed, 25 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/conversion/op7.C
diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 1715acc0ec3..d8b28573b95 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -6426,6 +6426,7 @@ build_new_op_1 (const op_location_t , enum tree_code
code, int flags,
{
conv = strip_standard_conversion (conv);
arg1 = convert_like (conv, arg1, complain);
+ arg1 = convert_from_reference (arg1);
}
if (arg2)
@@ -6435,6 +6436,7 @@ build_new_op_1 (const op_location_t , enum tree_code
code, int flags,
{
conv = strip_standard_conversion (conv);
arg2 = convert_like (conv, arg2, complain);
+ arg2 = convert_from_reference (arg2);
}
}
@@ -6445,6 +6447,7 @@ build_new_op_1 (const op_location_t , enum tree_code
code, int flags,
{
conv = strip_standard_conversion (conv);
arg3 = convert_like (conv, arg3, complain);
+ arg3 = convert_from_reference (arg3);
}
}
}
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: 2691ffe6dbaffb704593dd6220178c28848b3855
--
Marek Polacek • Red Hat, Inc. • 300 A St, Boston, MA
Re: [PATCH] issue -Walloca even when alloca is a system header macro [PR94004]
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
PR middle-end/94004 - missing -Walloca on calls to alloca due to -Wno-system-headers
gcc/testsuite/ChangeLog:
PR middle-end/94004
* gcc.dg/Walloca-larger-than-3.c: New test.
* gcc.dg/Walloca-larger-than-3.h: New test header.
* gcc.dg/Wvla-larger-than-4.c: New test.
gcc/ChangeLog:
PR middle-end/94004
* gimple-ssa-warn-alloca.c (pass_walloca::execute): Issue warnings
even for alloca calls resulting from system macro expansion.
Include inlining context in all warnings.
diff --git a/gcc/gimple-ssa-warn-alloca.c b/gcc/gimple-ssa-warn-alloca.c
index dfe40c9c02a..9e80e5dbbd9 100644
--- a/gcc/gimple-ssa-warn-alloca.c
+++ b/gcc/gimple-ssa-warn-alloca.c
@@ -510,11 +510,12 @@ pass_walloca::execute (function *fun)
gsi_next ())
{
gimple *stmt = gsi_stmt (si);
- location_t loc = gimple_location (stmt);
-
if (!gimple_alloca_call_p (stmt))
continue;
+ location_t loc = gimple_nonartificial_location (stmt);
+ loc = expansion_point_location_if_in_system_header (loc);
+
const bool is_vla
= gimple_call_alloca_for_var_p (as_a (stmt));
@@ -528,7 +529,7 @@ pass_walloca::execute (function *fun)
}
else if (warn_alloca)
{
- warning_at (loc, OPT_Walloca, "use of %");
+ warning_at (loc, OPT_Walloca, "%Guse of %", stmt);
continue;
}
else if (warn_alloca_limit < 0)
@@ -564,10 +565,12 @@ pass_walloca::execute (function *fun)
{
auto_diagnostic_group d;
if (warning_at (loc, wcode,
-is_vla ? G_("argument to variable-length "
- "array may be too large")
-: G_("argument to % may be too "
- "large"))
+(is_vla
+ ? G_("%Gargument to variable-length "
+ "array may be too large")
+ : G_("%Gargument to % may be too "
+ "large")),
+stmt)
&& t.limit != 0)
{
print_decu (t.limit, buff);
@@ -582,47 +585,57 @@ pass_walloca::execute (function *fun)
{
auto_diagnostic_group d;
if (warning_at (loc, wcode,
-is_vla ? G_("argument to variable-length"
- " array is too large")
-: G_("argument to % is too large"))
+(is_vla
+ ? G_("%Gargument to variable-length"
+ " array is too large")
+ : G_("%Gargument to % is too large")),
+stmt)
&& t.limit != 0)
{
print_decu (t.limit, buff);
inform (loc, "limit is %wu bytes, but argument is %s",
- is_vla ? warn_vla_limit : adjusted_alloca_limit,
- buff);
+ is_vla ? warn_vla_limit : adjusted_alloca_limit,
+ buff);
}
}
break;
case ALLOCA_BOUND_UNKNOWN:
warning_at (loc, wcode,
- is_vla ? G_("variable-length array bound is unknown")
- : G_("% bound is unknown"));
+ (is_vla
+ ? G_("%Gvariable-length array bound is unknown")
+ : G_("%G% bound is unknown")),
+ stmt);
break;
case ALLOCA_UNBOUNDED:
warning_at (loc, wcode,
- is_vla ? G_("unbounded use of variable-length array")
- : G_("unbounded use of %"));
+ (is_vla
+ ? G_("%Gunbounded use of variable-length array")
+ : G_("%Gunbounded use of %")),
+ stmt);
break;
case ALLOCA_IN_LOOP:
gcc_assert (!is_vla);
- warning_at (loc, wcode, "use of % within a loop");
+ warning_at (loc, wcode,
+ "%Guse of % within a loop", stmt);
break;
case ALLOCA_CAST_FROM_SIGNED:
gcc_assert (invalid_casted_type != NULL_TREE);
warning_at (loc, wcode,
- is_vla ? G_("argument to variable-length array "
- "may be too large due to "
- "conversion from %qT to %qT")
- : G_("argument to % may be too large "
- "due to conversion from %qT to %qT"),
- invalid_casted_type, size_type_node);
+ (is_vla
+ ? G_("%Gargument to variable-length array "
+"may be too large due to "
+"conversion from %qT to %qT")
+ : G_("%Gargument to % may be too large "
+"due to conversion from %qT to %qT")),
+ stmt, invalid_casted_type, size_type_node);
break;
case ALLOCA_ARG_IS_ZERO:
warning_at (loc, wcode,
- is_vla ? G_("argument to variable-length array "
- "is zero")
- : G_("argument to % is zero"));
+ (is_vla
+ ?
[PATCH d/92309] Committed fix for assignment to anonymous union member corrupts sibling members in struct
Hi,
This patch fixes a logic bug in the adjustment of nested fields in
anonymous aggregates in the D front-end, closing PR d/92309.
Bootstrapped and tested on x86_64-linux-gnu, and committed to trunk.
Regards
Iain.
---
gcc/d/ChangeLog:
PR d/92309
* types.cc (fixup_anonymous_offset): Don't set DECL_FIELD_OFFSET on
anonymous fields.
gcc/testsuite/ChangeLog:
PR d/92309
* gdc.dg/pr92309.d: New test.
---
gcc/d/types.cc | 10 +++---
gcc/testsuite/gdc.dg/pr92309.d | 25 +
2 files changed, 32 insertions(+), 3 deletions(-)
create mode 100644 gcc/testsuite/gdc.dg/pr92309.d
diff --git a/gcc/d/types.cc b/gcc/d/types.cc
index 736f128422c..866da965b40 100644
--- a/gcc/d/types.cc
+++ b/gcc/d/types.cc
@@ -234,16 +234,20 @@ insert_aggregate_field (tree type, tree field, size_t
offset)
static void
fixup_anonymous_offset (tree fields, tree offset)
{
+ /* No adjustment in field offset required. */
+ if (integer_zerop (offset))
+return;
+
while (fields != NULL_TREE)
{
- /* Traverse all nested anonymous aggregates to update their offset.
-Set the anonymous decl offset to its first member. */
+ /* Traverse all nested anonymous aggregates to update the offset of their
+fields. Note that the anonymous field itself is not adjusted, as it
+already has an offset relative to its outer aggregate. */
tree ftype = TREE_TYPE (fields);
if (TYPE_NAME (ftype) && IDENTIFIER_ANON_P (TYPE_IDENTIFIER (ftype)))
{
tree vfields = TYPE_FIELDS (ftype);
fixup_anonymous_offset (vfields, offset);
- DECL_FIELD_OFFSET (fields) = DECL_FIELD_OFFSET (vfields);
}
else
{
diff --git a/gcc/testsuite/gdc.dg/pr92309.d b/gcc/testsuite/gdc.dg/pr92309.d
new file mode 100644
index 000..01ebc40d336
--- /dev/null
+++ b/gcc/testsuite/gdc.dg/pr92309.d
@@ -0,0 +1,25 @@
+// https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92309
+// { dg-do run { target hw } }
+// { dg-skip-if "needs gcc/config.d" { ! d_runtime } }
+
+union U
+{
+struct
+{
+size_t a;
+size_t b;
+union
+{
+size_t c;
+size_t d;
+}
+}
+}
+
+void main()
+{
+U u;
+assert(u.a == 0);
+u.d = 1;
+assert(u.a == 0);
+}
--
2.20.1
Re: [PATCH] c++: Fix access checking for __is_assignable and __is_constructible (c++/94197)
On 3/16/20 6:13 PM, Ville Voutilainen wrote: On Mon, 16 Mar 2020 at 23:25, Ville Voutilainen wrote: Tested on Linux-PPC64. This ain't no regression. But it seems to hamper attempts to fix library regressions (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94033). It occurred to me that this can be done in one place. 2020-03-17 Ville Voutilainen gcc/ PR c++/94197 * cp/method.c (assignable_expr): Use cp_unevaluated. (is_xible_helper): Push a non-deferred access check for the stub objects created by assignable_expr and constructible_expr. It occurs to me that we don't need to defer access control in instantiate_template_1 if we're instantiating an alias template, but this patch is OK as is. Jason
[committed] libstdc++: Add default constructor to net::service_already_exists (PR 94199)
The service_already_exists exception type specified in the TS doesn't
have any constructors defined. Since its base class isn't default
constructible, that means has no usable constructors. This may be a
defect in the TS.
This patch fixes it by adding a default constructor, but making it
private. The make_service function is declared as a friend to be able to
call that private constructor.
PR libstdc++/94199
* include/experimental/executor (service_already_exists): Add default
constructor. Declare make_service to be a friend.
* testsuite/experimental/net/execution_context/make_service.cc: New
test.
Tested powerpc64le-linux, committed to master.
I'll backport it to gcc-9 too.
commit c62f5e6e1f457462b1cea74792833821bbea64bb
Author: Jonathan Wakely
Date: Mon Mar 16 22:53:42 2020 +
libstdc++: Add default constructor to net::service_already_exists (PR 94199)
The service_already_exists exception type specified in the TS doesn't
have any constructors defined. Since its base class isn't default
constructible, that means has no usable constructors. This may be a
defect in the TS.
This patch fixes it by adding a default constructor, but making it
private. The make_service function is declared as a friend to be able to
call that private constructor.
PR libstdc++/94199
* include/experimental/executor (service_already_exists): Add
default
constructor. Declare make_service to be a friend.
* testsuite/experimental/net/execution_context/make_service.cc: New
test.
diff --git a/libstdc++-v3/include/experimental/executor
b/libstdc++-v3/include/experimental/executor
index 5577623bb47..6955ead6bf5 100644
--- a/libstdc++-v3/include/experimental/executor
+++ b/libstdc++-v3/include/experimental/executor
@@ -127,7 +127,14 @@ inline namespace v1
/// An extensible, type-safe, polymorphic set of services.
class execution_context;
- class service_already_exists : public logic_error { };
+ class service_already_exists : public logic_error
+ {
+template
+ friend _Service&
+ make_service(execution_context&, _Args&&...);
+
+service_already_exists() : logic_error("service already exists") { }
+ };
template struct is_executor;
diff --git
a/libstdc++-v3/testsuite/experimental/net/execution_context/make_service.cc
b/libstdc++-v3/testsuite/experimental/net/execution_context/make_service.cc
new file mode 100644
index 000..f134add48b5
--- /dev/null
+++ b/libstdc++-v3/testsuite/experimental/net/execution_context/make_service.cc
@@ -0,0 +1,36 @@
+// Copyright (C) 2020 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library. This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3. If not see
+//
Re: [PATCH] driver: Improve the generated help text for alias options with arguments
On Mon, Mar 16, 2020 at 6:11 PM Lewis Hyatt wrote: > Regarding -Wmissing-format-attribute, that is an interesting case, it's the > only > instance in any *.opt that has an = sign in the Alias target. If I understand > correctly, this one can't use the 3-argument form of Alias() because > -Wno-missing-format-attribute is actually an alias for > -Wno-suggest-attribute=format, rather than -Wsuggest-attribute=. I > think that one could be left as is or else my patch would need to check for > an = > sign in the alias target and handle this case as well, but that may lead to > other surprises in the future. Sorry, please disregard the above paragraph, that was my mistake... Those kinds of aliases with an = are used frequently. I guess the current behavior is probably best for them. -Lewis
Re: [PATCH] c++: Fix access checking for __is_assignable and __is_constructible (c++/94197)
On Mon, 16 Mar 2020 at 23:25, Ville Voutilainen
wrote:
>
> Tested on Linux-PPC64.
>
> This ain't no regression. But it seems to hamper attempts to fix library
> regressions (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94033).
It occurred to me that this can be done in one place.
2020-03-17 Ville Voutilainen
gcc/
PR c++/94197
* cp/method.c (assignable_expr): Use cp_unevaluated.
(is_xible_helper): Push a non-deferred access check for
the stub objects created by assignable_expr and constructible_expr.
testsuite/
PR c++/94197
* g++.dg/ext/pr94197.C: New.
diff --git a/gcc/cp/method.c b/gcc/cp/method.c
index 790d5704092..3427750f64e 100644
--- a/gcc/cp/method.c
+++ b/gcc/cp/method.c
@@ -1739,11 +1739,10 @@ check_nontriv (tree *tp, int *, void *)
static tree
assignable_expr (tree to, tree from)
{
- ++cp_unevaluated_operand;
+ cp_unevaluated cp_uneval_guard;
to = build_stub_object (to);
from = build_stub_object (from);
tree r = cp_build_modify_expr (input_location, to, NOP_EXPR, from, tf_none);
- --cp_unevaluated_operand;
return r;
}
@@ -1806,6 +1805,7 @@ constructible_expr (tree to, tree from)
static tree
is_xible_helper (enum tree_code code, tree to, tree from, bool trivial)
{
+ deferring_access_check_sentinel acs (dk_no_deferred);
if (VOID_TYPE_P (to) || ABSTRACT_CLASS_TYPE_P (to)
|| (from && FUNC_OR_METHOD_TYPE_P (from)
&& (TYPE_READONLY (from) || FUNCTION_REF_QUALIFIED (from
diff --git a/gcc/testsuite/g++.dg/ext/pr94197.C b/gcc/testsuite/g++.dg/ext/pr94197.C
new file mode 100644
index 000..768bfbac0a6
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ext/pr94197.C
@@ -0,0 +1,75 @@
+// { dg-do compile }
+// { dg-options "-std=c++11" }
+
+template
+ T&& declval() noexcept;
+
+template
+struct bool_constant
+{
+ static constexpr bool value = B;
+ using type = bool_constant;
+};
+
+using true_type = bool_constant;
+using false_type = bool_constant;
+
+template
+ struct __is_nt_constructible_impl
+ : public false_type
+ { };
+
+template
+ struct __is_nt_constructible_impl
+ : public bool_constant(declval()))>
+ { };
+
+template
+ using __is_nothrow_constructible_impl
+= __is_nt_constructible_impl<__is_constructible(T, Arg), T, Arg>;
+
+template
+ struct __is_nothrow_copy_constructible_impl
+ : public __is_nothrow_constructible_impl
+ { };
+
+template
+ struct is_nothrow_copy_constructible
+ : public __is_nothrow_copy_constructible_impl::type
+ { };
+
+template
+ struct __is_nt_assignable_impl
+ : public false_type
+ { };
+
+template
+ struct __is_nt_assignable_impl
+ : public bool_constant() = declval())>
+ { };
+
+template
+ using __is_nothrow_assignable_impl
+= __is_nt_assignable_impl<__is_assignable(T, Arg), T, Arg>;
+
+template
+ struct __is_nothrow_copy_assignable_impl
+ : public __is_nothrow_assignable_impl
+ { };
+
+template
+ struct is_nothrow_copy_assignable
+ : public __is_nothrow_copy_assignable_impl::type
+ { };
+
+struct NType
+{
+ NType();
+private:
+ NType(const NType&);
+ NType& operator=(const NType&);
+};
+
+
+static_assert( !is_nothrow_copy_constructible::value, "" );
+static_assert( !is_nothrow_copy_assignable::value, "" );
Re: [PATCH] driver: Improve the generated help text for alias options with arguments
On Mon, Mar 16, 2020 at 06:11:08PM +, Richard Sandiford wrote: > Lewis Hyatt via Gcc-patches writes: ... > > FWIW there are three other options currently affected by this change > > (-Wimplicit-fallthrough, -fcf-protection, and -flive-patching). The change > > for > > -Wimplicit-fallthrough I think is particularly helpful: > > > > -Wimplicit-fallthrough Same as -Wimplicit-fallthrough=. Use the > > latter option instead. > > becomes > > -Wimplicit-fallthrough Same as -Wimplicit-fallthrough=3 (or, in > > negated form, -Wimplicit-fallthrough=0). > > I also see: > > - -ftail-call-workaround Same as -ftail-call-workaround=. Use the > latter option instead. > + -ftail-call-workaround Same as -ftail-call-workaround=1 (or, in > negated form, -ftail-call-workaround=0). >-ftail-call-workaround=<0,2> Disallow tail call optimization when a > calling routine may have omitted character lengths. > ... >--imacros Same as -imacros. Use the latter option > instead. >--imacros= Same as -imacros. Use the latter option > instead. >--include Same as -include. Use the latter option > instead. > - --include-barrier Same as -I. Use the latter option instead. > + --include-barrier Same as -I-. >--include-directory Same as -I. Use the latter option instead. >--include-directory-after Same as -idirafter. Use the latter option > instead. >--include-directory-after= Same as -idirafter. Use the latter option > instead. > ... > - -WnormalizedSame as -Wnormalized=. Use the latter option > instead. > + -WnormalizedSame as -Wnormalized=nfc (or, in negated form, > -Wnormalized=none). >-Wnormalized=[none|id|nfc|nfkc] Warn about non-normalized Unicode strings. > > I agree all of these look like improvements, especially the > --include-barrier one. But I think the include ones also show > that the "Use the latter option instead." decision is independent > of whether the option is defined to be an alias. > > FWIW, there's also: > > Wmissing-format-attribute > C ObjC C++ ObjC++ Warning Alias(Wsuggest-attribute=format) > ; > > which still ends up as: > > -Wmissing-format-attribute Same as -Wsuggest-attribute=format. Use the > latter option instead. > > Not really my area though, so I don't have any specific suggestion > about how to separate the cases. > Right, sorry, in my first email I only mentioned the options output by --help=common, but there were a few more as well. Thanks very much for trying it out and for the feedback. The rule I implemented was to change the help output for all alias options with no documentation if they also specify the extra 2nd option (or 2nd and 3rd options) to the Alias directive. For example, -include-barrier is like this: -include-barrier C ObjC C++ ObjC++ Alias(I, -) It serves to provide the argument '-' to the option '-I', so it is eligible for the new text. The others are like this one: -include-directory-after C ObjC C++ ObjC++ Separate Alias(idirafter) MissingArgError(missing path after %qs) Since that one doesn't pass the extra args to Alias, I interpreted it to mean this is the case for which the "Use the latter option" directive was intended to apply. (-idirafter has been designated as preferable to -include-directory-after). Regarding -Wmissing-format-attribute, that is an interesting case, it's the only instance in any *.opt that has an = sign in the Alias target. If I understand correctly, this one can't use the 3-argument form of Alias() because -Wno-missing-format-attribute is actually an alias for -Wno-suggest-attribute=format, rather than -Wsuggest-attribute=. I think that one could be left as is or else my patch would need to check for an = sign in the alias target and handle this case as well, but that may lead to other surprises in the future. Thanks! -Lewis
[PATCH] d: Committed fix multiple definition error when using mixins and interfaces.
Hi,
When generating thunks in the D front-end, they need not necesarily be
in the same compilation unit as the module where the target function is
declared. When this happens, don't make the thunk public. Later on
expand_thunk will be called with force_gimple_thunk=true, so the thunk
can never be made weak due to differing implementations between modules.
Bootstrapped and tested on x86_64-linux-gnu, and committed to trunk.
Regards
Iain.
---
gcc/d/ChangeLog:
PR d/92216
* decl.cc (make_thunk): Don't set TREE_PUBLIC on thunks if the target
function is external to the current compilation.
gcc/testsuite/ChangeLog:
PR d/92216
* gdc.dg/imports/pr92216.d: New.
* gdc.dg/pr92216.d: New test.
---
gcc/d/decl.cc | 7 +--
gcc/testsuite/gdc.dg/imports/pr92216.d | 22 ++
gcc/testsuite/gdc.dg/pr92216.d | 13 +
3 files changed, 40 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/gdc.dg/imports/pr92216.d
create mode 100644 gcc/testsuite/gdc.dg/pr92216.d
diff --git a/gcc/d/decl.cc b/gcc/d/decl.cc
index 3824060feb9..7afb1aa0292 100644
--- a/gcc/d/decl.cc
+++ b/gcc/d/decl.cc
@@ -1803,8 +1803,11 @@ make_thunk (FuncDeclaration *decl, int offset)
DECL_CONTEXT (thunk) = d_decl_context (decl);
- /* Thunks inherit the public access of the function they are targetting. */
- TREE_PUBLIC (thunk) = TREE_PUBLIC (function);
+ /* Thunks inherit the public access of the function they are targetting.
+ When the function is outside the current compilation unit however, then
the
+ thunk must be kept private to not conflict. */
+ TREE_PUBLIC (thunk) = TREE_PUBLIC (function) && !DECL_EXTERNAL (function);
+
DECL_EXTERNAL (thunk) = 0;
/* Thunks are always addressable. */
diff --git a/gcc/testsuite/gdc.dg/imports/pr92216.d
b/gcc/testsuite/gdc.dg/imports/pr92216.d
new file mode 100644
index 000..b8c71c03420
--- /dev/null
+++ b/gcc/testsuite/gdc.dg/imports/pr92216.d
@@ -0,0 +1,22 @@
+module imports.pr92216;
+
+class B : I
+{
+protected override void getStruct(){}
+mixin A!();
+
+}
+
+mixin template A()
+{
+public void* getS()
+{
+return null;
+}
+}
+
+public interface I
+{
+public void* getS();
+protected void getStruct();
+}
diff --git a/gcc/testsuite/gdc.dg/pr92216.d b/gcc/testsuite/gdc.dg/pr92216.d
new file mode 100644
index 000..330604c9c89
--- /dev/null
+++ b/gcc/testsuite/gdc.dg/pr92216.d
@@ -0,0 +1,13 @@
+// https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92216
+// { dg-options "-I $srcdir/gdc.dg" }
+// { dg-do compile }
+// { dg-final { scan-assembler
"_DT16_D7imports7pr922161B8__mixin24getSMFZPv\[: \t\n\]" } }
+// { dg-final { scan-assembler-not "(.globl|.global)\[
\]+_DT16_D7imports7pr922161B8__mixin24getSMFZPv" } }
+module pr92216;
+
+private import imports.pr92216;
+
+class C : B
+{
+protected override void getStruct() {}
+}
--
2.20.1
Re: [PATCH v2] c++: Fix parsing of invalid enum specifiers [PR90995]
On 3/15/20 7:35 PM, Jakub Jelinek wrote:
On Sun, Mar 15, 2020 at 05:21:59PM -0400, Jason Merrill wrote:
Let's use temp_override.
So like this?
Yes, thanks.
Bootstrapped/regtested on x86_64-linux and i686-linux.
2020-03-15 Jakub Jelinek
PR c++/90995
* parser.c (cp_parser_enum_specifier): Use temp_override for
parser->colon_corrects_to_scope_p, replace goto out with return.
If scoped enum or enum with underlying type is not followed by
{ or ;, call error_at rather than cp_parser_error. Formatting fixes.
* g++.dg/cpp0x/enum40.C: New test.
--- gcc/cp/parser.c.jj 2020-03-14 08:14:47.125740994 +0100
+++ gcc/cp/parser.c 2020-03-15 22:39:09.003266300 +0100
@@ -19001,9 +19001,7 @@ cp_parser_enum_specifier (cp_parser* par
bool is_unnamed = false;
tree underlying_type = NULL_TREE;
cp_token *type_start_token = NULL;
- bool saved_colon_corrects_to_scope_p = parser->colon_corrects_to_scope_p;
-
- parser->colon_corrects_to_scope_p = false;
+ temp_override cleanup (parser->colon_corrects_to_scope_p, false);
/* Parse tentatively so that we can back up if we don't find a
enum-specifier. */
@@ -19043,24 +19041,24 @@ cp_parser_enum_specifier (cp_parser* par
push_deferring_access_checks (dk_no_check);
nested_name_specifier
- = cp_parser_nested_name_specifier_opt (parser,
-/*typename_keyword_p=*/true,
-/*check_dependency_p=*/false,
-/*type_p=*/false,
-/*is_declaration=*/false);
+= cp_parser_nested_name_specifier_opt (parser,
+ /*typename_keyword_p=*/true,
+ /*check_dependency_p=*/false,
+ /*type_p=*/false,
+ /*is_declaration=*/false);
if (nested_name_specifier)
{
tree name;
identifier = cp_parser_identifier (parser);
- name = cp_parser_lookup_name (parser, identifier,
-enum_type,
-/*is_template=*/false,
-/*is_namespace=*/false,
-/*check_dependency=*/true,
-/*ambiguous_decls=*/NULL,
-input_location);
+ name = cp_parser_lookup_name (parser, identifier,
+ enum_type,
+ /*is_template=*/false,
+ /*is_namespace=*/false,
+ /*check_dependency=*/true,
+ /*ambiguous_decls=*/NULL,
+ input_location);
if (name && name != error_mark_node)
{
type = TREE_TYPE (name);
@@ -19142,21 +19140,20 @@ cp_parser_enum_specifier (cp_parser* par
{
cp_parser_error (parser, "expected %<{%>");
if (has_underlying_type)
- {
- type = NULL_TREE;
- goto out;
- }
+ return NULL_TREE;
}
/* An opaque-enum-specifier must have a ';' here. */
if ((scoped_enum_p || underlying_type)
&& cp_lexer_next_token_is_not (parser->lexer, CPP_SEMICOLON))
{
- cp_parser_error (parser, "expected %<;%> or %<{%>");
if (has_underlying_type)
{
- type = NULL_TREE;
- goto out;
+ error_at (cp_lexer_peek_token (parser->lexer)->location,
+ "expected %<;%> or %<{%>");
+ return NULL_TREE;
Hmm, what happens if we commit_to_tentative_parse before the
cp_parser_error if has_underlying_type? That would also get us a
diagnostic in this case even in enclosing tentative context.
And yes, I think returning error_mark_node seems appropriate; this is an
enum-specifier, just an ill-formed one.
}
+ else
+ cp_parser_error (parser, "expected %<;%> or %<{%>");
}
}
@@ -19172,9 +19169,7 @@ cp_parser_enum_specifier (cp_parser* par
push_scope (nested_name_specifier);
}
else if (TREE_CODE (nested_name_specifier) == NAMESPACE_DECL)
- {
- push_nested_namespace (nested_name_specifier);
- }
+ push_nested_namespace (nested_name_specifier);
}
/* Issue an error message if type-definitions are forbidden here. */
@@ -19334,12 +19329,8 @@ cp_parser_enum_specifier (cp_parser* par
pop_scope (nested_name_specifier);
}
else if (TREE_CODE (nested_name_specifier) == NAMESPACE_DECL)
- {
- pop_nested_namespace (nested_name_specifier);
- }
+ pop_nested_namespace (nested_name_specifier);
}
- out:
-
Re: [PATCH] c: Handle MEM_REF in c_fully_fold* [PR94179]
On Mon, 2020-03-16 at 09:23 +0100, Jakub Jelinek via Gcc-patches wrote:
> Hi!
>
> The recent match.pd changes can generate a MEM_REF which can be seen by the
> C FE folding routines. Unlike the C++ FE, they weren't expected in the C FE
> yet. MEM_REF should be handled like INDIRECT_REF, except that it has two
> operands rather than just one and that we should preserve the type of the
> second operand. Given that it already has to be an INTEGER_CST with pointer
> type, I think we are fine, the recursive call should return the INTEGER_CST
> unmodified and STRIP_TYPE_NOPS will not strip anything.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2020-03-16 Jakub Jelinek
>
> PR c/94179
> * c-fold.c (c_fully_fold_internal): Handle MEM_REF.
>
> * gcc.c-torture/compile/pr94179.c: New test.
>
> --- gcc/c/c-fold.c.jj 2020-01-12 11:54:36.208416501 +0100
> +++ gcc/c/c-fold.c2020-03-15 17:26:42.863491563 +0100
> @@ -346,6 +346,7 @@ c_fully_fold_internal (tree expr, bool i
> case UNGT_EXPR:
> case UNGE_EXPR:
> case UNEQ_EXPR:
> +case MEM_REF:
>/* Binary operations evaluating both arguments (increment and
>decrement are binary internally in GCC). */
>orig_op0 = op0 = TREE_OPERAND (expr, 0);
> @@ -435,6 +436,14 @@ c_fully_fold_internal (tree expr, bool i
> || TREE_CODE (TREE_TYPE (orig_op0)) == FIXED_POINT_TYPE)
> && TREE_CODE (TREE_TYPE (orig_op1)) == INTEGER_TYPE)
> warn_for_div_by_zero (loc, op1);
> + if (code == MEM_REF
> + && ret != expr
> + && TREE_CODE (ret) == MEM_REF)
> + {
> + TREE_READONLY (ret) = TREE_READONLY (expr);
> + TREE_SIDE_EFFECTS (ret) = TREE_SIDE_EFFECTS (expr);
> + TREE_THIS_VOLATILE (ret) = TREE_THIS_VOLATILE (expr);
> + }
>goto out;
I don't particularly like modifying what RET points to in this way, but it's the
same that we're already doing for INDIRECT_REF. So OK.
jeff
Re: [PATCH] issue -Walloca even when alloca is a system header macro [PR94004]
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. jeff >
[PATCH] c++: Fix access checking for __is_assignable and __is_constructible (c++/94197)
Tested on Linux-PPC64.
This ain't no regression. But it seems to hamper attempts to fix library
regressions (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94033).
2020-03-16 Ville Voutilainen
gcc/
PR c++/94197
* cp/method.c (assignable_expr, constructible_expr): Push
a deferred access check for the stub object.
testsuite/
PR c++/94197
* g++.dg/ext/pr94197.C: New.
diff --git a/gcc/cp/method.c b/gcc/cp/method.c
index 790d5704092..b429ea48049 100644
--- a/gcc/cp/method.c
+++ b/gcc/cp/method.c
@@ -1739,11 +1739,11 @@ check_nontriv (tree *tp, int *, void *)
static tree
assignable_expr (tree to, tree from)
{
- ++cp_unevaluated_operand;
+ cp_unevaluated cp_uneval_guard;
+ deferring_access_check_sentinel acs (dk_no_deferred);
to = build_stub_object (to);
from = build_stub_object (from);
tree r = cp_build_modify_expr (input_location, to, NOP_EXPR, from, tf_none);
- --cp_unevaluated_operand;
return r;
}
@@ -1759,6 +1759,7 @@ constructible_expr (tree to, tree from)
{
tree expr;
cp_unevaluated cp_uneval_guard;
+ deferring_access_check_sentinel acs (dk_no_deferred);
if (CLASS_TYPE_P (to))
{
tree ctype = to;
diff --git a/gcc/testsuite/g++.dg/ext/pr94197.C b/gcc/testsuite/g++.dg/ext/pr94197.C
new file mode 100644
index 000..768bfbac0a6
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ext/pr94197.C
@@ -0,0 +1,75 @@
+// { dg-do compile }
+// { dg-options "-std=c++11" }
+
+template
+ T&& declval() noexcept;
+
+template
+struct bool_constant
+{
+ static constexpr bool value = B;
+ using type = bool_constant;
+};
+
+using true_type = bool_constant;
+using false_type = bool_constant;
+
+template
+ struct __is_nt_constructible_impl
+ : public false_type
+ { };
+
+template
+ struct __is_nt_constructible_impl
+ : public bool_constant(declval()))>
+ { };
+
+template
+ using __is_nothrow_constructible_impl
+= __is_nt_constructible_impl<__is_constructible(T, Arg), T, Arg>;
+
+template
+ struct __is_nothrow_copy_constructible_impl
+ : public __is_nothrow_constructible_impl
+ { };
+
+template
+ struct is_nothrow_copy_constructible
+ : public __is_nothrow_copy_constructible_impl::type
+ { };
+
+template
+ struct __is_nt_assignable_impl
+ : public false_type
+ { };
+
+template
+ struct __is_nt_assignable_impl
+ : public bool_constant() = declval())>
+ { };
+
+template
+ using __is_nothrow_assignable_impl
+= __is_nt_assignable_impl<__is_assignable(T, Arg), T, Arg>;
+
+template
+ struct __is_nothrow_copy_assignable_impl
+ : public __is_nothrow_assignable_impl
+ { };
+
+template
+ struct is_nothrow_copy_assignable
+ : public __is_nothrow_copy_assignable_impl::type
+ { };
+
+struct NType
+{
+ NType();
+private:
+ NType(const NType&);
+ NType& operator=(const NType&);
+};
+
+
+static_assert( !is_nothrow_copy_constructible::value, "" );
+static_assert( !is_nothrow_copy_assignable::value, "" );
Re: [PATCH] c++: Fix wrong no post-decrement operator error in template [PR94190]
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 &() 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. Jason
Re: [PATCH] avoid modifying type in attribute access handler [PR94098]
On 3/16/20 4:41 PM, Martin Sebor wrote:
The recent fix to avoid modifying in place the type argument in
handle_access_attribute (PR 92721) was incomplete and didn't fully
resolve the problem (an ICE in the C++ front-end). The attached
patch removes the remaining modification that causes the ICE. In
addition, the change adjusts checking calls to functions declared
with the attribute to scan all its instances.
The attached patch was tested on x86_64-linux.
I'm puzzled that the ICE only triggers in the C++ front-end and not
also in C. The code that issues the internal error is in comptypes()
in cp/typeck.c and has this comment:
/* The two types are structurally equivalent, but their
canonical types were different. This is a failure of the
canonical type propagation code.*/
internal_error
("canonical types differ for identical types %qT and %qT",
t1, t2);
What is "the canonical type propagation code" it refers to?
Generally, code that makes sure that TYPE_CANONICAL equality is
equivalent to type identity, not any one specific place.
Is it valid to modify the type in an attribute handler
Only if (flags & ATTR_FLAG_TYPE_IN_PLACE).
If not, and if modifying a type in place is not valid I'd expect
decl_attributes to enforce it. I looked for other attribute handlers
to see if any also modify the type argument in place (by adding or
removing attributes) but couldn't really find any. So if it is
invalid I'd like to add such an assertion (probably for GCC 11) but
before I do I want to make sure I'm not missing something.
Generally messing with _ATTRIBUTES happens in decl_attributes: changing
it directly if it's a DECL or ATTR_FLAG_TYPE_IN_PLACE, otherwise using
build_type_attribute_variant. If you need to do it in your handler, you
should follow the same pattern.
Jason
[PATCH] LRA: fix for PR94185
The following committed patch solves https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94185 The patch was successfully bootstrapped and tested on x86-64.
[PATCH] avoid modifying type in attribute access handler [PR94098]
The recent fix to avoid modifying in place the type argument in
handle_access_attribute (PR 92721) was incomplete and didn't fully
resolve the problem (an ICE in the C++ front-end). The attached
patch removes the remaining modification that causes the ICE. In
addition, the change adjusts checking calls to functions declared
with the attribute to scan all its instances.
The attached patch was tested on x86_64-linux.
I'm puzzled that the ICE only triggers in the C++ front-end and not
also in C. The code that issues the internal error is in comptypes()
in cp/typeck.c and has this comment:
/* The two types are structurally equivalent, but their
canonical types were different. This is a failure of the
canonical type propagation code.*/
internal_error
("canonical types differ for identical types %qT and %qT",
t1, t2);
What is "the canonical type propagation code" it refers to? Is it
valid to modify the type in an attribute handler and does it in C++
just require updating some other code somewhere else?
If not, and if modifying a type in place is not valid I'd expect
decl_attributes to enforce it. I looked for other attribute handlers
to see if any also modify the type argument in place (by adding or
removing attributes) but couldn't really find any. So if it is
invalid I'd like to add such an assertion (probably for GCC 11) but
before I do I want to make sure I'm not missing something.
Martin
PR c++/94098 - ICE on attribute access redeclaration
gcc/c-family/ChangeLog:
PR c++/94098
* c-attribs.c (handle_access_attribute): Avoid setting TYPE_ATTRIBUTES
here.
gcc/ChangeLog:
PR c++/94098
* calls.c (init_attr_rdwr_indices): Iterate over all access attributes.
gcc/testsuite/ChangeLog:
PR c++/94098
* g++.dg/ext/attr-access-2.C: New test.
diff --git a/gcc/c-family/c-attribs.c b/gcc/c-family/c-attribs.c
index 9abf81d0248..9fa2a8ecefc 100644
--- a/gcc/c-family/c-attribs.c
+++ b/gcc/c-family/c-attribs.c
@@ -4190,15 +4190,13 @@ handle_access_attribute (tree *node, tree name, tree args,
{
/* Repeat for the previously declared type. */
attrs = TYPE_ATTRIBUTES (TREE_TYPE (node[1]));
- tree new_attrs
- = append_access_attrs (node[1], attrs, attrstr, code, idxs);
- if (!new_attrs)
+ tree attrs1 = append_access_attrs (node[1], attrs, attrstr, code, idxs);
+ if (!attrs1)
return NULL_TREE;
attrs = remove_attribute (IDENTIFIER_POINTER (name), attrs);
- new_attrs = tree_cons (NULL_TREE, new_attrs, NULL_TREE);
- new_attrs = tree_cons (name, new_attrs, attrs);
- TYPE_ATTRIBUTES (TREE_TYPE (node[1])) = new_attrs;
+ attrs1 = tree_cons (NULL_TREE, attrs1, NULL_TREE);
+ new_attrs = tree_cons (name, attrs1, attrs);
}
/* Recursively call self to "replace" the documented/external form
diff --git a/gcc/calls.c b/gcc/calls.c
index 4c3a8f3c215..5bd922779af 100644
--- a/gcc/calls.c
+++ b/gcc/calls.c
@@ -1873,7 +1873,7 @@ struct rdwr_access_hash: int_hash { };
typedef hash_map rdwr_map;
/* Initialize a mapping for a call to function FNDECL declared with
- attribute access. Each attribute poisitional operand inserts one
+ attribute access. Each attribute positional operand inserts one
entry into the mapping with the operand number as the key. */
static void
@@ -1882,54 +1882,50 @@ init_attr_rdwr_indices (rdwr_map *rwm, tree fntype)
if (!fntype)
return;
- tree access = TYPE_ATTRIBUTES (fntype);
- /* If the function's type has no attributes there's nothing to do. */
- if (!access)
-return;
-
- access = lookup_attribute ("access", access);
- if (!access)
-return;
-
- /* The TREE_VALUE of an attribute is a TREE_LIST whose TREE_VALUE
- is the attribute argument's value. */
- tree mode = TREE_VALUE (access);
- gcc_assert (TREE_CODE (mode) == TREE_LIST);
- mode = TREE_VALUE (mode);
- gcc_assert (TREE_CODE (mode) == STRING_CST);
-
- const char *modestr = TREE_STRING_POINTER (mode);
- for (const char *m = modestr; *m; )
+ for (tree access = TYPE_ATTRIBUTES (fntype);
+ (access = lookup_attribute ("access", access));
+ access = TREE_CHAIN (access))
{
- attr_access acc = { };
-
- switch (*m)
+ /* The TREE_VALUE of an attribute is a TREE_LIST whose TREE_VALUE
+ is the attribute argument's value. */
+ tree mode = TREE_VALUE (access);
+ gcc_assert (TREE_CODE (mode) == TREE_LIST);
+ mode = TREE_VALUE (mode);
+ gcc_assert (TREE_CODE (mode) == STRING_CST);
+
+ const char *modestr = TREE_STRING_POINTER (mode);
+ for (const char *m = modestr; *m; )
{
- case 'r': acc.mode = acc.read_only; break;
- case 'w': acc.mode = acc.write_only; break;
- default: acc.mode = acc.read_write; break;
- }
+ attr_access acc = { };
- char *end;
- acc.ptrarg = strtoul (++m, , 10);
- m = end;
- if (*m == ',')
- {
- acc.sizarg = strtoul (++m, , 10);
+
Please confirm
Attn; Email user, We are pleased to announce that your "#e-mail#" was nominated as one of the 28 recipients under the Second category in the online DONATION SWEEPSTAKE 2020 Prospect as part of the Bill & Melinda Gates Foundation to relief Humanitarian struggle. For claims and clearance, kindly reply back with your SERIAL details: Bill/Melinda-S28/79712 OR call: +44-7443676180 on how to receive your donation cash prize of 650,000.00 Euro. Ms. JENET LAUREN SECRETARY. This email was sent by the shareware version of Postman Professional.
Re: [PATCH v2] generate EH info for volatile asm statements (PR93981)
On Mon, Mar 16, 2020 at 07:46:57PM +, Richard Sandiford wrote: > > The write to "x" *before the asm* is deleted. I cannot think of any > > interpretation where that is correct (this does not involve inline asm > > at all: it is deleting an observable side effect before the exception). > > It's correct under the contract above :-) That cannot be, because the generated code does the wrong thing before the asm is executed already (and without UB there is no time travel). > > Yes, obviously. The other option is to accept that almost all existing > > inline asm will have UB, with -fnon-call-exceptions. I think that is > > an even less desirable option. (I'm assuming we do not want that option). > Normally, for SSA names in something like: > > _1 = foo () > > the definition of _1 does not take place when foo throws. But that is not how RTL works, afaik. Segher
RE: Gcc-patches Digest, Vol 1, Issue 113
Hi Adam, Right now I am passing "[http://raghavpa_...@primary-proxy.gslb.intranet.barcapint.com:8080]https://www2.1010data.com/cgi-bin/gw; For gateway option Should I change it to "[http://raghavpa_...@primary-proxy.gslb.intranet.barcapint.com:8080]https://www2.1010data.com/cgi-bin/prime-latest; I'll send the log shortly. Best, Partha Raghavan I Director Quantitative Analytics - Securitized Products Tel (212) 526 2884 I Mobile (203) 979 9307 Email partha.ragha...@barclays.com BARCLAYS 745 7th Avenue I 7th Floor I New York NY 10019 Restricted - External -Original Message- From: Gcc-patches On Behalf Of gcc-patches-requ...@gcc.gnu.org Sent: Monday, March 16, 2020 15:47 To: gcc-patches@gcc.gnu.org Subject: Gcc-patches Digest, Vol 1, Issue 113 This mail originated from outside our organisation - gcc-patches-requ...@gcc.gnu.org Send Gcc-patches mailing list submissions to gcc-patches@gcc.gnu.org To subscribe or unsubscribe via the World Wide Web, visit https://clicktime.symantec.com/35jUogceMkVm7KSP5dvs1xq6H2?u=http%3A%2F%2Fgcc.gnu.org%2Fmailman%2Flistinfo%2Fgcc-patches or, via email, send a message with subject or body 'help' to gcc-patches-requ...@gcc.gnu.org You can reach the person managing the list at gcc-patches-ow...@gcc.gnu.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Gcc-patches digest..." _ This message is for information purposes only, it is not a recommendation, advice, offer or solicitation to buy or sell a product or service nor an official confirmation of any transaction. It is directed at persons who are professionals and is not intended for retail customer use. Intended for recipient only. This message is subject to the terms at: www.barclays.com/emaildisclaimer. For important disclosures, please see: www.barclays.com/salesandtradingdisclaimer regarding market commentary from Barclays Sales and/or Trading, who are active market participants; https://www.investmentbank.barclays.com/disclosures/barclays-global-markets-disclosures.html regarding our standard terms for the Investment Bank of Barclays where we trade with you in principal-to-principal wholesale markets transactions; and in respect of Barclays Research, including disclosures relating to specific issuers, please see http://publicresearch.barclays.com. _ If you are incorporated or operating in Australia, please see https://www.home.barclays/disclosures/importantapacdisclosures.html for important disclosure. _ How we use personal information see our privacy notice https://www.investmentbank.barclays.com/disclosures/personalinformationuse.html _
Re: [PATCH v2] generate EH info for volatile asm statements (PR93981)
Segher Boessenkool writes: > On Mon, Mar 16, 2020 at 05:47:03PM +, Richard Sandiford wrote: >> Segher Boessenkool writes: >> >> we do delete "x = 1" for f1. I think that's the expected behaviour. >> >> We don't yet delete the initialisation in f2, but I think in principle >> >> we could. >> > >> > Right. And this is incorrect if the asm may throw. >> >> Well... >> >> >> So the kind of contract I was advocating was: >> >> >> >> - the compiler can't make any assumptions about what the asm does >> >> or doesn't do to output operands when an exception is raised >> >> >> >> - the source code can't make any assumption about the values bound >> >> to output operands when an exception is raised >> >> ...with this interpretation, the deletions above would be correct even >> if the asm throws. > > The write to "x" *before the asm* is deleted. I cannot think of any > interpretation where that is correct (this does not involve inline asm > at all: it is deleting an observable side effect before the exception). It's correct under the contract above :-) >> > And the easiest (and only feasible?) way to do this is for the compiler >> > to automatically make an input for every output as well, imo. >> >> Modifying the asm like that feels a bit dangerous, > > Yes, obviously. The other option is to accept that almost all existing > inline asm will have UB, with -fnon-call-exceptions. I think that is > an even less desirable option. > >> And the other problem >> still exists: he compiler might assume that the output isn't modified >> unless the asm completes normally. > > I don't understand what this means? As far as the compiler is concerned > any asm is just one instruction? And it all executes completely always. > You need to do things with the constraints to tell the compiler it does > not know some of the values around. If you have both an input and an > output for a variable, the compiler does not know what value is written > to it, and it might just be the one that was the input already (which is > the same effect as not writing it at all). Normally, for SSA names in something like: _1 = foo () the definition of _1 does not take place when foo throws. Similarly for non-call exceptions on other statements. It sounds like what you're describing requires the corresponding definition to happen for memory outputs regardless of whether the asm throws or not, so that the memory appears to change on both excecution paths. Otherwise, the compiler would be able to assume that the memory operand still has its original value in the exception handler. Richard
Re: [PATCH v2] generate EH info for volatile asm statements (PR93981)
On Mon, Mar 16, 2020 at 05:47:03PM +, Richard Sandiford wrote: > Segher Boessenkool writes: > >> we do delete "x = 1" for f1. I think that's the expected behaviour. > >> We don't yet delete the initialisation in f2, but I think in principle > >> we could. > > > > Right. And this is incorrect if the asm may throw. > > Well... > > >> So the kind of contract I was advocating was: > >> > >> - the compiler can't make any assumptions about what the asm does > >> or doesn't do to output operands when an exception is raised > >> > >> - the source code can't make any assumption about the values bound > >> to output operands when an exception is raised > > ...with this interpretation, the deletions above would be correct even > if the asm throws. The write to "x" *before the asm* is deleted. I cannot think of any interpretation where that is correct (this does not involve inline asm at all: it is deleting an observable side effect before the exception). > > And the easiest (and only feasible?) way to do this is for the compiler > > to automatically make an input for every output as well, imo. > > Modifying the asm like that feels a bit dangerous, Yes, obviously. The other option is to accept that almost all existing inline asm will have UB, with -fnon-call-exceptions. I think that is an even less desirable option. > And the other problem > still exists: he compiler might assume that the output isn't modified > unless the asm completes normally. I don't understand what this means? As far as the compiler is concerned any asm is just one instruction? And it all executes completely always. You need to do things with the constraints to tell the compiler it does not know some of the values around. If you have both an input and an output for a variable, the compiler does not know what value is written to it, and it might just be the one that was the input already (which is the same effect as not writing it at all). Segher
Re: c: ignore initializers for elements of variable-size types [PR93577]
Christophe Lyon via Gcc-patches writes:
> On Wed, 11 Mar 2020 at 00:37, Joseph Myers wrote:
>>
>> On Tue, 10 Mar 2020, Christophe Lyon wrote:
>>
>> > sizeless-1.c and sizeless-2.c have the same code, but the latter is
>> > compiled with -msve-vector-bits=256 and expects different
>> > warnings/errors.
>> > For line 33:
>> > svint8_t *invalid_sve_sc_ptr = &(svint8_t) { *global_sve_sc_ptr };
>> > we now have:
>> > sizeless-1.c:33:44: error: empty scalar initializer
>> > sizeless-1.c:33:44: note: (near initialization for '(anonymous)')
>> > and
>> > sizeless-2.c:33:44: error: initializer element is not constant
>> > sizeless-2.c:33:44: note: (near initialization for 'invalid_sve_sc_ptr')
>> > sizeless-2.c:33:44: error: SVE type 'svint8_t' does not have a fixed size
>> > so I think the error comes from the compound literal being treated
>> > differently with -msve-vector-bits=256
>>
>> I think the sizeless-2.c diagnostics are correct while there's a problem
>> in the sizeless-1.c case (the initializer is not empty, so it should not
>> be diagnosed as such).
>>
>> Does the process_init_element code
>>
>> /* Ignore elements of an initializer for a variable-size type.
>> Those are diagnosed in digest_init. */
>> if (COMPLETE_TYPE_P (constructor_type)
>> && TREE_CODE (TYPE_SIZE (constructor_type)) != INTEGER_CST)
>> return;
>>
>> fire for the sizeless-1.c case? If so, maybe it needs to be restricted in
>> some way to apply only to variable size structs / unions / arrays rather
>> than whatever kind of variable-size type the SVE types are.
>
> It does. Type_size has POLY_INT_CST type.
>
> The attached small patch fixes the problem (tested on arm and aarch64).
> OK?
Thanks for doing this. I'd wondered whether it should be based on
this or on VECTOR_TYPE_P, but FWIW, I agree basing it on this is best.
> diff --git a/gcc/c/c-typeck.c b/gcc/c/c-typeck.c
> index d8025de..1302486 100644
> --- a/gcc/c/c-typeck.c
> +++ b/gcc/c/c-typeck.c
> @@ -9968,7 +9968,8 @@ process_init_element (location_t loc, struct
> c_expr value, bool implicit,
>/* Ignore elements of an initializer for a variable-size type.
> Those are diagnosed in digest_init. */
>if (COMPLETE_TYPE_P (constructor_type)
> - && TREE_CODE (TYPE_SIZE (constructor_type)) != INTEGER_CST)
> + && TREE_CODE (TYPE_SIZE (constructor_type)) != INTEGER_CST
> + && TREE_CODE (TYPE_SIZE (constructor_type)) != POLY_INT_CST)
Not worth respinning over, but since it hasn't been applied yet:
a shorter alternative is to replace the != INTEGER_CST test with
!poly_int_tree_p.
> diff --git a/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/sizeless-1.c
> b/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/sizeless-1.c
> index ec892a3..e53b871 100644
> --- a/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/sizeless-1.c
> +++ b/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/sizeless-1.c
> @@ -83,7 +83,6 @@ statements (int n)
>svint8_t array[2]; /* { dg-error {array elements cannot have SVE
> type 'svint8_t'} } */
>svint8_t zero_length_array[0]; /* { dg-error {array elements cannot
> have SVE type 'svint8_t'} } */
>svint8_t empty_init_array[] = {}; /* { dg-error {array elements
> cannot have SVE type 'svint8_t'} } */
> - /* { dg-error {empty scalar
> initializer} "" { target *-*-* } .-1 } */
>typedef svint8_t vla_type[n]; /* { dg-error {array elements cannot
> have SVE type 'svint8_t'} } */
>
>/* Assignment. */
> diff --git a/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/sizeless-2.c
> b/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/sizeless-2.c
> index 7174393..9986d27 100644
> --- a/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/sizeless-2.c
> +++ b/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/sizeless-2.c
> @@ -83,7 +83,6 @@ statements (int n)
>svint8_t array[2]; /* { dg-error {array elements cannot have SVE
> type 'svint8_t'} } */
>svint8_t zero_length_array[0]; /* { dg-error {array elements cannot
> have SVE type 'svint8_t'} } */
>svint8_t empty_init_array[] = {}; /* { dg-error {array elements
> cannot have SVE type 'svint8_t'} } */
> - /* { dg-error {empty scalar
> initializer} "" { target *-*-* } .-1 } */
>typedef svint8_t vla_type[n]; /* { dg-error {array elements cannot
> have SVE type 'svint8_t'} } */
>
>/* Assignment. */
Jeff pointed out off-list that using:
N: ... /* { dg-error {...} } */
N+1: /* { dg-error {...} "" { target *-*-* } .-1 } */
led to two identical test names for line N. This was causing the
results to fluctuate when using contrib/compare_tests (which I admit
I don't do, so hadn't noticed). Your patch fixes the cases that
mattered, but for future-proofing reasons, this patch adds proper
test names for the remaining instances.
Tested on aarch64-linux-gnu and committed as obvious.
Richard
2020-03-16 Richard Sandiford
gcc/testsuite/
*
Re: [PATCH] driver: Improve the generated help text for alias options with arguments
Lewis Hyatt via Gcc-patches writes: > Hello- > > Currently, if an option is both undocumented and an alias for a second option, > the help text generated by gcc --help directs the reader to use the other > option instead. This makes sense for deprecated options, but it seems this > pattern is also used for another case, namely when an option exists so as to > pass a default argument to another option. For instance this one, from > common.opt: > > - > fdiagnostics-color > Common Alias(fdiagnostics-color=,always,never) > ; > > fdiagnostics-color= > Driver Common Joined RejectNegative Var(flag_diagnostics_show_color) > Enum(diagnostic_color_rule) Init(DIAGNOSTICS_COLOR_NO) > -fdiagnostics-color=[never|always|auto] Colorize diagnostics. > - > > This is nice because it means you can say -fdiagnostics-color as a shorthand > for -fdiagnostics-color=always, or -fno-diagnostics-color as a shorthand for > -fdiagnostics-color=never. However, the generated help text does not describe > it this way: > > - > $ gcc --help=common | grep fdiagnostics-color > -fdiagnostics-color Same as -fdiagnostics-color=. Use the latter > option instead. > -fdiagnostics-color=[never|always|auto] Colorize diagnostics. > - > > Perhaps I am wrong and the non-argument usage is indeed meant to be > deprecated, > but it feels more like it was intended as a convenience and could be > documented > as such. What actually prompted this patch is that I am adding a new option > for > GCC 11 with these never/always/auto semantics and I am a bit confused whether > I > am supposed to add the aliased version or not. Feels like it's nice to add it, > but then the --help output says the opposite... > > Anyway, the attached patch would change the help output to the following... If > that seems to be an improvement and closer to the intended behavior, please > let > me know. Thanks! > > - > -fdiagnostics-color Same as -fdiagnostics-color=always (or, in > negated form, -fdiagnostics-color=never). > -fdiagnostics-color=[never|always|auto] Colorize diagnostics. > - > > FWIW there are three other options currently affected by this change > (-Wimplicit-fallthrough, -fcf-protection, and -flive-patching). The change for > -Wimplicit-fallthrough I think is particularly helpful: > > -Wimplicit-fallthrough Same as -Wimplicit-fallthrough=. Use the latter > option instead. > becomes > -Wimplicit-fallthrough Same as -Wimplicit-fallthrough=3 (or, in negated > form, -Wimplicit-fallthrough=0). I also see: - -ftail-call-workaround Same as -ftail-call-workaround=. Use the latter option instead. + -ftail-call-workaround Same as -ftail-call-workaround=1 (or, in negated form, -ftail-call-workaround=0). -ftail-call-workaround=<0,2> Disallow tail call optimization when a calling routine may have omitted character lengths. ... --imacros Same as -imacros. Use the latter option instead. --imacros= Same as -imacros. Use the latter option instead. --include Same as -include. Use the latter option instead. - --include-barrier Same as -I. Use the latter option instead. + --include-barrier Same as -I-. --include-directory Same as -I. Use the latter option instead. --include-directory-after Same as -idirafter. Use the latter option instead. --include-directory-after= Same as -idirafter. Use the latter option instead. ... - -WnormalizedSame as -Wnormalized=. Use the latter option instead. + -WnormalizedSame as -Wnormalized=nfc (or, in negated form, -Wnormalized=none). -Wnormalized=[none|id|nfc|nfkc] Warn about non-normalized Unicode strings. I agree all of these look like improvements, especially the --include-barrier one. But I think the include ones also show that the "Use the latter option instead." decision is independent of whether the option is defined to be an alias. FWIW, there's also: Wmissing-format-attribute C ObjC C++ ObjC++ Warning Alias(Wsuggest-attribute=format) ; which still ends up as: -Wmissing-format-attribute Same as -Wsuggest-attribute=format. Use the latter option instead. Not really my area though, so I don't have any specific suggestion about how to separate the cases. Thanks, Richard
Re: [PATCH PR94026] combine missed opportunity to simplify comparisons with zero
On Mon, Mar 16, 2020 at 06:29:39AM +, Yangfei (Felix) wrote: > Sorry for not getting your point here. Trying 7 -> 8: 7: r99:SI=r103:SI>>0x8 REG_DEAD r103:SI 8: r100:SI=r99:SI&0x6 REG_DEAD r99:SI Failed to match this instruction: (set (reg:SI 100) (and:SI (lshiftrt:SI (reg:SI 103) (const_int 8 [0x8])) (const_int 6 [0x6]))) That should match already, perhaps with a splitter. aarch64 does not have very generic rotate-and-mask (or -insert) instructions, so the aarch64 backend needs to help combine with the less trivial cases. If you have a splitter for *this* one, all else will probably work "automatically": you split it to two ubfm, and the second of those can then merge into the compare instruction, and everything works out. > Also, this issue is there for ports like x86. If we go that way, then we > need to handle each port affected. Yes, you need to do target-specific stuff in every backend separately. > So I am inclined to handle this in an arch-independent way. But you don't. The transformation you do looks to be actively harmful on many targets. (I haven't tested it yet, that takes 8h currently). > > What should be tested is what new combinations are done, and which are *no > > longer* done. > > In theory, we won't lose but emit more zero_extract with my patch. Which is a bad idea. How many machine insns are there matters; the cost of those matters (assuming that matches reality well, which it has to anyway); latency matters. How many insns are zero_extract instead of something else is not a good indicator of performance. Segher
Re: [PATCH v2] generate EH info for volatile asm statements (PR93981)
Segher Boessenkool writes:
> On Fri, Mar 13, 2020 at 01:31:19PM +, Richard Sandiford wrote:
>> This might not be what you mean, but for:
>>
>> int
>> f1 (void)
>> {
>> int x = 1;
>> asm volatile ("": "=m" (x));
>> return x;
>> }
>>
>> struct s { int i[5]; };
>> struct s
>> f2 (void)
>> {
>> struct s x = { 1, 2, 3, 4, 5 };
>> asm volatile ("": "=m" (x));
>> return x;
>> }
>>
>> we do delete "x = 1" for f1. I think that's the expected behaviour.
>> We don't yet delete the initialisation in f2, but I think in principle
>> we could.
>
> Right. And this is incorrect if the asm may throw.
Well...
>
>> So the kind of contract I was advocating was:
>>
>> - the compiler can't make any assumptions about what the asm does
>> or doesn't do to output operands when an exception is raised
>>
>> - the source code can't make any assumption about the values bound
>> to output operands when an exception is raised
...with this interpretation, the deletions above would be correct even
if the asm throws.
> And the easiest (and only feasible?) way to do this is for the compiler
> to automatically make an input for every output as well, imo.
Modifying the asm like that feels a bit dangerous, And the other problem
still exists: he compiler might assume that the output isn't modified
unless the asm completes normally.
Thanks,
Richard
RE: [PATCH v3][ARM][GCC][1/x]: MVE ACLE intrinsics framework patch.
Hi Srinath, I've pushed the first three of the patches for you to master: [ARM][GCC][3/x]: MVE ACLE intrinsics framework patch. [ARM][GCC][2/x]: MVE ACLE intrinsics framework patch. [ARM][GCC][1/x]: MVE ACLE intrinsics framework patch. For this first one I adjusted the add_options directives for mve to actually add armv8.1-m.main+mve or armv8.1-m.main+mve.fp to the march line so that the tests don't appear as UNSUPPORTED when running the testsuite without any explicit options specified. Please keep an eye out for any fallout in the coming days (though I've smoked tested the patches myself before committing) Thanks, Kyrill -Original Message- From: Gcc-patches On Behalf Of Srinath Parvathaneni Sent: 16 March 2020 10:53 To: Kyrill Tkachov ; gcc-patches@gcc.gnu.org Subject: Re: [PATCH v3][ARM][GCC][1/x]: MVE ACLE intrinsics framework patch. Hi Kyrill, > This is ok but please bootstrap it on arm-none-linux-gnueabihf as well. I have bootstrapped this patch on arm-none-linux-gnueabihf and found no issues. There is problem with git commit rights, could you commit this patch on my behalf. Regards SRI From: Kyrill Tkachov Sent: 12 March 2020 11:15 To: Srinath Parvathaneni ; gcc-patches@gcc.gnu.org Subject: Re: [PATCH v3][ARM][GCC][1/x]: MVE ACLE intrinsics framework patch. Hi Srinath, On 3/10/20 6:19 PM, Srinath Parvathaneni wrote: > Hello Kyrill, > > This patch addresses all the comments in patch version v2. > (version v2) > https://gcc.gnu.org/pipermail/gcc-patches/2020-February/540415.html > > > > Hello, > > This patch creates the required framework for MVE ACLE intrinsics. > > The following changes are done in this patch to support MVE ACLE > intrinsics. > > Header file arm_mve.h is added to source code, which contains the > definitions of MVE ACLE intrinsics and different data types used in > MVE. Machine description file mve.md is also added which contains the > RTL patterns defined for MVE. > > A new reigster "p0" is added which is used in by MVE predicated > patterns. A new register class "VPR_REG" > is added and its contents are defined in REG_CLASS_CONTENTS. > > The vec-common.md file is modified to support the standard move > patterns. The prefix of neon functions which are also used by MVE is > changed from "neon_" to "simd_". > eg: neon_immediate_valid_for_move changed to > simd_immediate_valid_for_move. > > In the patch standard patterns mve_move, mve_store and move_load for > MVE are added and neon.md and vfp.md files are modified to support > this common patterns. > > Please refer to Arm reference manual [1] for more details. > > [1] https://developer.arm.com/docs/ddi0553/latest > > Regression tested on target arm-none-eabi and armeb-none-eabi and > found no regressions. > > Ok for trunk? This is ok but please bootstrap it on arm-none-linux-gnueabihf as well. Thanks, Kyrill > > Thanks, > Srinath > > gcc/ChangeLog: > > 2020-03-06 Andre Vieira > Mihail Ionescu > Srinath Parvathaneni > > * config.gcc (arm_mve.h): Include mve intrinsics header file. > * config/arm/aout.h (p0): Add new register name for MVE predicated > cases. > * config/arm-builtins.c (ARM_BUILTIN_SIMD_LANE_CHECK): Define > macro > common to Neon and MVE. > (ARM_BUILTIN_NEON_LANE_CHECK): Renamed to > ARM_BUILTIN_SIMD_LANE_CHECK. > (arm_init_simd_builtin_types): Disable poly types for MVE. > (arm_init_neon_builtins): Move a check to arm_init_builtins > function. > (arm_init_builtins): Use ARM_BUILTIN_SIMD_LANE_CHECK instead of > ARM_BUILTIN_NEON_LANE_CHECK. > (mve_dereference_pointer): Add function. > (arm_expand_builtin_args): Call to mve_dereference_pointer > when MVE is > enabled. > (arm_expand_neon_builtin): Moved to arm_expand_builtin function. > (arm_expand_builtin): Moved from arm_expand_neon_builtin function. > * config/arm/arm-c.c (__ARM_FEATURE_MVE): Define macro for MVE > and MVE > with floating point enabled. > * config/arm/arm-protos.h (neon_immediate_valid_for_move): > Renamed to > simd_immediate_valid_for_move. > (simd_immediate_valid_for_move): Renamed from > neon_immediate_valid_for_move function. > * config/arm/arm.c (arm_options_perform_arch_sanity_checks): > Generate > error if vfpv2 feature bit is disabled and mve feature bit is also > disabled for HARD_FLOAT_ABI. > (use_return_insn): Check to not push VFP regs for MVE. > (aapcs_vfp_allocate): Add MVE check to have same Procedure > Call Standard > as Neon. > (aapcs_vfp_allocate_return_reg): Likewise. > (thumb2_legitimate_address_p): Check to return 0 on valid Thumb-2 > address operand for MVE. > (arm_rtx_costs_internal): MVE check to determine cost of rtx. > (neon_valid_immediate): Rename to
Re: [PATCH] issue -Walloca even when alloca is a system header macro [PR94004]
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-March/541521.html On 3/4/20 2:06 PM, Martin Sebor wrote: A 2017 change that propagated call location to GIMPLE statements had the unexpected (though not incorrect) effect of setting the location on calls to __builtin_alloca. When such calls are the result of the expansion of the alloca macro defined in a system header like , the change prevents -Walloca and -Walloca-larger-than warnings from being issued unless -Wsystem-headers is also used, effectively defeating the point of the first two warnings in most code. The attached patch changes -Walloca to use the location of the point of the macro expansion rather than that of its definition, restoring the intended behavior. In addition, to make the warnings (mainly -Wvla) in inlined code easier to debug, the patch also arranges for the warnings to include their inlining context. Tested on x86_64-linux. Martin
[PATCH] c++: Fix constexpr evaluation of self-modifying CONSTRUCTORs [PR94066]
In this PR, we are performing constexpr evaluation of a CONSTRUCTOR of type
union U which looks like
{.a=foo (&)}.
Since the function foo takes a reference to the CONSTRUCTOR we're building, it
could potentially modify the CONSTRUCTOR from under us. In particular since U
is a union, the evaluation of a's initializer could change the active member
from a to another member -- something which cxx_eval_bare_aggregate doesn't
expect to happen.
Upon further investigation, it turns out this issue is not limited to
constructors of UNION_TYPE and not limited to cxx_eval_bare_aggregate either.
For example, within cxx_eval_store_expression we may be evaluating an assignment
such as (this comes from the test pr94066-2.C):
((union U *) this)->a = TARGET_EXPR ;
where evaluation of foo could change the active member of *this, which was set
earlier in cxx_eval_store_expression to 'a'. And if U is a RECORD_TYPE, then
evaluation of foo could add new fields to *this, thereby making stale the 'valp'
pointer to the target constructor_elt through which we're later assigning.
So in short, it seems that both cxx_eval_bare_aggregate and
cxx_eval_store_expression do not anticipate that a constructor_elt's initializer
could modify the underlying CONSTRUCTOR as a side-effect.
To fix this problem, this patch makes cxx_eval_bare_aggregate and
cxx_eval_store_expression recompute the pointer to the constructor_elt through
which we're assigning, after the initializer has been evaluated.
I am worried that the use of get_or_insert_ctor_field in cxx_eval_bare_aggregate
might introduce quadratic behavior where there wasn't before. I wonder if
there's a cheap heuristic we can use in cxx_eval_bare_aggregate to determine
whether "self-modification" took place, and in which case we could avoid calling
get_or_insert_ctor_field and do the fast thing we that we were doing before the
patch.
Tested on x86_64-pc-linux-gnu, but a full bootstrap is in progress. Does this
look like the right approach?
gcc/cp/ChangeLog:
PR c++/94066
* constexpr.c (get_or_insert_ctor_field): Split out (while adding
handling for VECTOR_TYPEs) from ...
(cxx_eval_store_expression): ... here. Record the sequence of indexes
into INDEXES that yields the suboject we're assigning to. After
evaluating the initializer of the store expression, recompute valp using
INDEXES.
(cxx_eval_bare_aggregate): Use get_or_insert_ctor_field to recompute the
pointer to the constructor_elt we're assigning through after evaluating
each initializer.
gcc/testsuite/ChangeLog:
PR c++/94066
* g++.dg/cpp1y/pr94066.C: New test.
* g++.dg/cpp1y/pr94066-2.C: New test.
* g++.dg/cpp1y/pr94066-3.C: New test.
* g++.dg/cpp1y/pr94066-4.C: New test.
* g++.dg/cpp1y/pr94066-5.C: New test.
---
gcc/cp/constexpr.c | 184 +++--
gcc/testsuite/g++.dg/cpp1y/pr94066-2.C | 21 +++
gcc/testsuite/g++.dg/cpp1y/pr94066-3.C | 21 +++
gcc/testsuite/g++.dg/cpp1y/pr94066-4.C | 22 +++
gcc/testsuite/g++.dg/cpp1y/pr94066-5.C | 18 +++
gcc/testsuite/g++.dg/cpp1y/pr94066.C | 20 +++
6 files changed, 210 insertions(+), 76 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/cpp1y/pr94066-2.C
create mode 100644 gcc/testsuite/g++.dg/cpp1y/pr94066-3.C
create mode 100644 gcc/testsuite/g++.dg/cpp1y/pr94066-4.C
create mode 100644 gcc/testsuite/g++.dg/cpp1y/pr94066-5.C
create mode 100644 gcc/testsuite/g++.dg/cpp1y/pr94066.C
diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index 192face9a3a..9fcf9f33457 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -3144,6 +3144,88 @@ find_array_ctor_elt (tree ary, tree dindex, bool insert)
return -1;
}
+/* Return a pointer to the constructor_elt of CTOR which matches INDEX. If no
+ matching constructor_elt exists, then add it to CTOR. Emit an appropriate
+ diagnostic if CTOR constructs a UNION_TYPE and adding INDEX would change the
+ active member of the union, unless QUIET is true. */
+
+static constructor_elt *
+get_or_insert_ctor_field (tree ctor, tree index,
+ bool quiet, bool *non_constant_p)
+{
+ tree type = TREE_TYPE (ctor);
+ if (TREE_CODE (type) == VECTOR_TYPE && index == NULL_TREE)
+{
+ CONSTRUCTOR_APPEND_ELT (CONSTRUCTOR_ELTS (ctor), index, NULL_TREE);
+ return _ELTS (ctor)->last();
+}
+ else if (TREE_CODE (type) == ARRAY_TYPE || TREE_CODE (type) == VECTOR_TYPE)
+{
+ HOST_WIDE_INT i = find_array_ctor_elt (ctor, index, /*insert*/true);
+ gcc_assert (i >= 0);
+ constructor_elt *cep = CONSTRUCTOR_ELT (ctor, i);
+ gcc_assert (cep->index == NULL_TREE
+ || TREE_CODE (cep->index) != RANGE_EXPR);
+ return cep;
+}
+ else
+{
+ gcc_assert (TREE_CODE (index) == FIELD_DECL);
+
+ /* We must keep the CONSTRUCTOR's ELTS in FIELD order.
+Usually we meet initializers in
[PATCH v4][ARM][GCC][3/x]: MVE ACLE intrinsics framework patch.
Hello Kyrill,
> What is the point of repeating the scan-assembler directives here? The
> first scan-assembler should be redundant given the scan-assembler-times ?
> Otherwise ok.
In this patch testcases are modified by removing the redundant
scan-assembler directive.
Please commit to trunk on my behalf.
Regards,
SRI.
Hello,
This patch is part of MVE ACLE intrinsics framework.
The patch supports the use of emulation for the single-precision arithmetic
operations for MVE. This changes are to support the MVE ACLE intrinsics which
operates on vector floating point arithmetic operations.
Please refer to Arm reference manual [1] for more details.
[1] https://developer.arm.com/docs/ddi0553/latest
Regression tested on target arm-none-eabi and armeb-none-eabi and found no
regressions.
Ok for trunk?
Thanks,
Srinath.
gcc/ChangeLog:
2020-03-06 Andre Vieira
Srinath Parvathaneni
* config/arm/arm.c (arm_libcall_uses_aapcs_base): Modify function to add
emulator calls for dobule precision arithmetic operations for MVE.
2020-03-06 Srinath Parvathaneni
* gcc.target/arm/mve/intrinsics/mve_libcall1.c: New test.
* gcc.target/arm/mve/intrinsics/mve_libcall2.c: Likewise.
### Attachment also inlined for ease of reply###
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index
b40904a40e0979af4285fdbd85bfae55abea25dd..b3dfa285f016268714002b0217964c81e0a4840e
100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -5754,9 +5754,25 @@ arm_libcall_uses_aapcs_base (const_rtx libcall)
/* Values from double-precision helper functions are returned in core
registers if the selected core only supports single-precision
arithmetic, even if we are using the hard-float ABI. The same is
-true for single-precision helpers, but we will never be using the
-hard-float ABI on a CPU which doesn't support single-precision
-operations in hardware. */
+true for single-precision helpers except in case of MVE, because in
+MVE we will be using the hard-float ABI on a CPU which doesn't support
+single-precision operations in hardware. In MVE the following check
+enables use of emulation for the single-precision arithmetic
+operations. */
+ if (TARGET_HAVE_MVE)
+ {
+ add_libcall (libcall_htab, optab_libfunc (add_optab, SFmode));
+ add_libcall (libcall_htab, optab_libfunc (sdiv_optab, SFmode));
+ add_libcall (libcall_htab, optab_libfunc (smul_optab, SFmode));
+ add_libcall (libcall_htab, optab_libfunc (neg_optab, SFmode));
+ add_libcall (libcall_htab, optab_libfunc (sub_optab, SFmode));
+ add_libcall (libcall_htab, optab_libfunc (eq_optab, SFmode));
+ add_libcall (libcall_htab, optab_libfunc (lt_optab, SFmode));
+ add_libcall (libcall_htab, optab_libfunc (le_optab, SFmode));
+ add_libcall (libcall_htab, optab_libfunc (ge_optab, SFmode));
+ add_libcall (libcall_htab, optab_libfunc (gt_optab, SFmode));
+ add_libcall (libcall_htab, optab_libfunc (unord_optab, SFmode));
+ }
add_libcall (libcall_htab, optab_libfunc (add_optab, DFmode));
add_libcall (libcall_htab, optab_libfunc (sdiv_optab, DFmode));
add_libcall (libcall_htab, optab_libfunc (smul_optab, DFmode));
diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_libcall1.c
b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_libcall1.c
new file mode 100644
index
..7c38d3102d26d8d7f6358258018a993df8298b4d
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_libcall1.c
@@ -0,0 +1,67 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target arm_v8_1m_mve_ok } */
+/* { dg-additional-options "-march=armv8.1-m.main+mve -mfloat-abi=hard -mthumb
-mfpu=auto" } */
+
+float
+foo (float a, float b, float c)
+{
+ return a + b + c;
+}
+
+/* { dg-final { scan-assembler-times "bl\\t__aeabi_fadd" 2 } } */
+
+float
+foo1 (float a, float b, float c)
+{
+ return a - b - c;
+}
+
+/* { dg-final { scan-assembler-times "bl\\t__aeabi_fsub" 2 } } */
+
+float
+foo2 (float a, float b, float c)
+{
+ return a * b * c;
+}
+
+/* { dg-final { scan-assembler-times "bl\\t__aeabi_fmul" 2 } } */
+
+float
+foo3 (float b, float c)
+{
+ return b / c;
+}
+
+/* { dg-final { scan-assembler "bl\\t__aeabi_fdiv" } } */
+
+int
+foo4 (float b, float c)
+{
+ return b < c;
+}
+
+/* { dg-final { scan-assembler "bl\\t__aeabi_fcmplt" } } */
+
+int
+foo5 (float b, float c)
+{
+ return b > c;
+}
+
+/* { dg-final { scan-assembler "bl\\t__aeabi_fcmpgt" } } */
+
+int
+foo6 (float b, float c)
+{
+ return b != c;
+}
+
+/* { dg-final { scan-assembler "bl\\t__aeabi_fcmpeq" } } */
+
+int
+foo7 (float b, float c)
+{
+ return b == c;
+}
+
+/* { dg-final { scan-assembler-times "bl\\t__aeabi_fcmpeq" 2 } } */
diff --git
[PATCH PR d/92792]: Committed reset libtool_VERSION to 1:0:0
Hi, This patch resets the libphobos soversion. Firstly, because Phobos, being template heavy, makes no attempt at being backwards compatible with previous versions. Even improvements in attribute inference in the compiler can have the effect of changing the mangling of many symbols, which is what I think happened in the case of the PR. Secondly, the current versioning scheme corresponds to the upstream release version of Phobos, which in hindsight was a mistake to have done. Cc Matthias who has been running with this patch in Debian for a while now. https://sources.debian.org/src/gcc-10/10-20200312-2/debian/patches/libphobos-soversion.diff/ Bootstrapped and tested on x86_64-linux-gnu, and committed to trunk. Regards Iain. --- libphobos/ChangeLog: 2020-03-16 Iain Buclaw PR d/92792 * Makefile.in: Regenerate. * configure: Regenerate. * configure.ac (libtool_VERSION): Reset to 1:0:0. * libdruntime/Makefile.in: Regenerate. --- libphobos/Makefile.in | 2 +- libphobos/configure | 2 +- libphobos/configure.ac| 2 +- libphobos/libdruntime/Makefile.in | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/libphobos/Makefile.in b/libphobos/Makefile.in index 4e6d0448525..6a774e96126 100644 --- a/libphobos/Makefile.in +++ b/libphobos/Makefile.in @@ -15,7 +15,7 @@ @SET_MAKE@ # Makefile for the toplevel directory of the D Standard library. -# Copyright (C) 2006-2019 Free Software Foundation, Inc. +# Copyright (C) 2006-2020 Free Software Foundation, Inc. # # GCC is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by diff --git a/libphobos/configure b/libphobos/configure index 741e23ea7a8..9cad270b2eb 100755 --- a/libphobos/configure +++ b/libphobos/configure @@ -15359,7 +15359,7 @@ SPEC_PHOBOS_DEPS="$LIBS" # Libdruntime / phobos soname version -libtool_VERSION=76:3:0 +libtool_VERSION=1:0:0 # Set default flags (after DRUNTIME_WERROR!) diff --git a/libphobos/configure.ac b/libphobos/configure.ac index be4d85eaa9f..69c635f405b 100644 --- a/libphobos/configure.ac +++ b/libphobos/configure.ac @@ -201,7 +201,7 @@ SPEC_PHOBOS_DEPS="$LIBS" AC_SUBST(SPEC_PHOBOS_DEPS) # Libdruntime / phobos soname version -libtool_VERSION=76:3:0 +libtool_VERSION=1:0:0 AC_SUBST(libtool_VERSION) # Set default flags (after DRUNTIME_WERROR!) diff --git a/libphobos/libdruntime/Makefile.in b/libphobos/libdruntime/Makefile.in index 63422308c65..44361f9c818 100644 --- a/libphobos/libdruntime/Makefile.in +++ b/libphobos/libdruntime/Makefile.in @@ -15,7 +15,7 @@ @SET_MAKE@ # Makefile for the D runtime library. -# Copyright (C) 2012-2019 Free Software Foundation, Inc. +# Copyright (C) 2012-2020 Free Software Foundation, Inc. # # GCC is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by -- 2.20.1
C++ Patch ping
Hi! I'd like to ping the https://gcc.gnu.org/ml/gcc-patches/2020-March/541542.html P2 PR91993 patch If you think it is too dangerous for GCC10 and should be postponed, I can ping it after 10.1 is released, or e.g. if you think for GCC10 we should for all codes handle that way only orig_op0 and not orig_op1, I can tweak that too (in that case, unless something reorders the operands of the binary expressions, it shouldn't evaluate side-effects differently from the order we've been using in the past). Thanks Jakub
Re: [PATCH 1/n] Remove SLP_INSTANCE_GROUP_SIZE
On Mon, 16 Mar 2020, Martin Liška wrote: > On 3/16/20 2:49 PM, Richard Biener wrote: > > If folks think this is useful I can do that (but expect it to see > > rebases frequently). > > Frequent rebasing is fine to me. refs/users/rguenth/heads/slp-reorg Richard.
[PATCH] c++: Fix wrong no post-decrement operator error in template [PR94190]
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 &() 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. Thus, use non_reference, which is
used in the function when looking for the best conversion candidate.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
PR c++/94190 - wrong no post-decrement operator error in template.
* cvt.c (build_expr_type_conversion): Use non_reference.
* g++.dg/conversion/op7.C: New test.
---
gcc/cp/cvt.c | 2 +-
gcc/testsuite/g++.dg/conversion/op7.C | 22 ++
2 files changed, 23 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/g++.dg/conversion/op7.C
diff --git a/gcc/cp/cvt.c b/gcc/cp/cvt.c
index 22a72c08c45..0c285ed4fe9 100644
--- a/gcc/cp/cvt.c
+++ b/gcc/cp/cvt.c
@@ -1732,7 +1732,7 @@ build_type_conversion (tree xtype, tree expr)
tree
build_expr_type_conversion (int desires, tree expr, bool complain)
{
- tree basetype = TREE_TYPE (expr);
+ tree basetype = non_reference (TREE_TYPE (expr));
tree conv = NULL_TREE;
tree winner = NULL_TREE;
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: 5a3c42b227bbe9e7acb5335088d2255262311bd8
--
Marek Polacek • Red Hat, Inc. • 300 A St, Boston, MA
Re: [PATCH 1/2] c++: Replay errors during diagnosis of constraint satisfaction failures
Hi Martin,
On Sun, 15 Mar 2020, Martin Sebor wrote:
> On 3/11/20 4:18 PM, Patrick Palka via Gcc-patches wrote:
> ...
> > Hmm, like this? This version introduces a new static member function
> > diagnosing_failed_constraint::replay_errors_p that checks
> > current_constraint_diagnosis_depth, and also sets max_depth_exceeded_p
> > when appropriate.
> >
> ...
>
> Just one small quoting nit:
>
>
> > @@ -3368,11 +3464,25 @@ diagnose_constraints (location_t loc, tree t, tree
> > args)
> > {
> > inform (loc, "constraints not satisfied");
> > + if (concepts_diagnostics_max_depth == 0)
> > +return;
> > +
> > /* Replay satisfaction, but diagnose errors. */
> > if (!args)
> > constraint_satisfaction_value (t, tf_warning_or_error);
> > else
> > constraint_satisfaction_value (t, args, tf_warning_or_error);
> > +
> > + static bool suggested_p;
> > + if (concepts_diagnostics_max_depth_exceeded_p
> > + && current_constraint_diagnosis_depth == 0
> > + && !suggested_p)
> > +{
> > + inform (UNKNOWN_LOCATION,
> > + "set -fconcepts-diagnostics-depth= to at least %d for more
> > detail",
> > + concepts_diagnostics_max_depth + 1);
>
>
> Can you please quote the option name in the diagnostic (e.g., by using
> "set %qs to...", "-fconcepts-diagnostics-depth=" or equivalent) to avoid
> -Wformat-diag? It won't cause errors (yet) but will eventually need to
> be cleaned up.
Yes sure, consider it done. I've amended the patch locally with this
change.
>
> Thanks
> Martin
>
>
Re: [PATCH][RFC] API extension for binutils (type of symbols).
On 3/16/20 3:34 PM, H.J. Lu wrote: It is LDPT_ADD_SYMBOLS_V2, not LDPT_GET_SYMBOLS_V2. Sorry. It's fixed now. Martin
Re: [PATCH][RFC] API extension for binutils (type of symbols).
On Mon, Mar 16, 2020 at 6:50 AM Martin Liška wrote: > > On 3/16/20 12:12 PM, H.J. Lu wrote: > > (enum ld_plugin_tag): Add LDPT_GET_SYMBOLS_V and > > ^^^ Typo, > > Thank you. I fixed that in my development branch. Still not right. It should be 2020-03-12 Martin Liska PR binutils/25640 * plugin-api.h (struct ld_plugin_symbol): Split int def into 4 char fields. (enum ld_plugin_symbol_type): New. (enum ld_plugin_symbol_section_flags): New. (enum ld_plugin_tag): Add LDPT_ADD_SYMBOLS_V2 and LDPT_GET_SYMBOLS_V4. It is LDPT_ADD_SYMBOLS_V2, not LDPT_GET_SYMBOLS_V2. -- H.J.
Re: [PATCH 1/n] Remove SLP_INSTANCE_GROUP_SIZE
On 3/16/20 2:49 PM, Richard Biener wrote: If folks think this is useful I can do that (but expect it to see rebases frequently). Frequent rebasing is fine to me. Martin
Re: [PATCH][RFC] API extension for binutils (type of symbols).
On 3/16/20 12:12 PM, H.J. Lu wrote: (enum ld_plugin_tag): Add LDPT_GET_SYMBOLS_V and ^^^ Typo, Thank you. I fixed that in my development branch. Martin
Re: [PATCH 1/n] Remove SLP_INSTANCE_GROUP_SIZE
On Mon, 16 Mar 2020, Martin Liška wrote: > On 3/16/20 1:16 PM, Richard Biener wrote: > > This is a part of a WIP series doing vectorizer rework. To be committed > > when stage1 opens. > > Hi. > > Have you considered publishing a public git branch where you will maintain > the suggested vectorization patches? If folks think this is useful I can do that (but expect it to see rebases frequently). Richard.
Re: [PATCH 1/n] Remove SLP_INSTANCE_GROUP_SIZE
On 3/16/20 1:16 PM, Richard Biener wrote: This is a part of a WIP series doing vectorizer rework. To be committed when stage1 opens. Hi. Have you considered publishing a public git branch where you will maintain the suggested vectorization patches? Thanks, Martin
Custom soccer jersey
Dear Sir/Madam, We are offer custom sportswear with 5PC MOQ, and wicking fabric Digital printing , Embroidery printing and screen printing is ok . Sample first is ok ,and paypal payment, Sample time 7 days . 1000 pcs production time is 15 day Wish your soon reply Elvis lau
[PATCH 2/n] move-permutation-validity-check
This is a part of a WIP series doing vectorizer rework. To be committed
when stage1 opens.
This delays the SLP permutation check to vectorizable_load and optimizes
permutations only after all SLP instances have been generated and the
vectorization factor is determined.
2020-02-24 Richard Biener
* tree-vect-slp.c ...
* gcc.dg/vect/bb-slp-pr68892.c: Adjust for not supported
SLP permutations becoming builds from scalars.
* gcc.dg/vect/bb-slp-pr78205.c: Likewise.
* gcc.dg/vect/bb-slp-34.c: Likewise.
---
gcc/testsuite/gcc.dg/vect/bb-slp-34.c | 3 +-
gcc/testsuite/gcc.dg/vect/bb-slp-pr68892.c | 7 +-
gcc/testsuite/gcc.dg/vect/bb-slp-pr78205.c | 6 +-
gcc/tree-vect-loop.c | 3 +
gcc/tree-vect-slp.c| 263 +++--
gcc/tree-vect-stmts.c | 48 +-
gcc/tree-vectorizer.h | 4 +-
7 files changed, 153 insertions(+), 181 deletions(-)
diff --git a/gcc/testsuite/gcc.dg/vect/bb-slp-34.c
b/gcc/testsuite/gcc.dg/vect/bb-slp-34.c
index ffd6ce25f64..c51c7706adc 100644
--- a/gcc/testsuite/gcc.dg/vect/bb-slp-34.c
+++ b/gcc/testsuite/gcc.dg/vect/bb-slp-34.c
@@ -32,5 +32,4 @@ int main()
return 0;
}
-/* ??? XFAILed because we access "excess" elements with the permutation. */
-/* { dg-final { scan-tree-dump "basic block vectorized" "slp2" { target
vect_perm xfail { ! { aarch64*-*-* arm*-*-* } } } } } */
+/* { dg-final { scan-tree-dump "basic block vectorized" "slp2" { target
vect_perm } } } */
diff --git a/gcc/testsuite/gcc.dg/vect/bb-slp-pr68892.c
b/gcc/testsuite/gcc.dg/vect/bb-slp-pr68892.c
index 216883fc0c4..8cd3a6a1274 100644
--- a/gcc/testsuite/gcc.dg/vect/bb-slp-pr68892.c
+++ b/gcc/testsuite/gcc.dg/vect/bb-slp-pr68892.c
@@ -13,7 +13,8 @@ void foo(void)
b[3] = a[3][0];
}
-/* ??? The profitability check is not reached because we give up on the
- gaps we access earlier. */
+/* ??? Due to the gaps we fall back to scalar loads which makes the
+ vectorization profitable. */
/* { dg-final { scan-tree-dump "not profitable" "slp2" { xfail *-*-* } } } */
-/* { dg-final { scan-tree-dump-times "Basic block will be vectorized" 0 "slp2"
} } */
+/* { dg-final { scan-tree-dump-times "BB vectorization with gaps at the end of
a load is not supported" 1 "slp2" } } */
+/* { dg-final { scan-tree-dump-times "Basic block will be vectorized" 1 "slp2"
} } */
diff --git a/gcc/testsuite/gcc.dg/vect/bb-slp-pr78205.c
b/gcc/testsuite/gcc.dg/vect/bb-slp-pr78205.c
index e02502a3fc1..f5dc5340792 100644
--- a/gcc/testsuite/gcc.dg/vect/bb-slp-pr78205.c
+++ b/gcc/testsuite/gcc.dg/vect/bb-slp-pr78205.c
@@ -19,7 +19,9 @@ void foo ()
}
/* We may not vectorize the store to x[] as it accesses c out-of bounds
- but we do want to vectorize the other two store groups. */
+ but we do want to vectorize the other two store groups. But we may
+ end up using scalar loads to vectorize the last group. */
/* { dg-final { scan-tree-dump-times "basic block vectorized" 1 "slp2" } } */
-/* { dg-final { scan-tree-dump-times "x\\\[\[0-1\]\\\] = " 2 "optimized" } } */
+/* { dg-final { scan-tree-dump-times "BB vectorization with gaps at the end of
a load is not supported" 1 "slp2" } } */
+/* { dg-final { scan-tree-dump-times " = c\\\[4\\\];" 1 "optimized" } } */
diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c
index e7c3daefb92..fb9e98f0ced 100644
--- a/gcc/tree-vect-loop.c
+++ b/gcc/tree-vect-loop.c
@@ -2043,6 +2043,9 @@ vect_analyze_loop_2 (loop_vec_info loop_vinfo, bool
, unsigned *n_stmts)
/* Update the vectorization factor based on the SLP decision. */
vect_update_vf_for_slp (loop_vinfo);
+
+ /* Optimize the SLP graph with the vectorization factor fixed. */
+ vect_optimize_slp (loop_vinfo);
}
bool saved_can_fully_mask_p = LOOP_VINFO_CAN_FULLY_MASK_P (loop_vinfo);
diff --git a/gcc/tree-vect-slp.c b/gcc/tree-vect-slp.c
index 3308e1791f1..32e6a0beaed 100644
--- a/gcc/tree-vect-slp.c
+++ b/gcc/tree-vect-slp.c
@@ -1850,6 +1850,9 @@ vect_attempt_slp_rearrange_stmts (slp_instance slp_instn)
unsigned int lidx;
slp_tree node, load;
+ if (SLP_INSTANCE_LOADS (slp_instn).is_empty ())
+return false;
+
/* Compare all the permutation sequences to the first one. We know
that at least one load is permuted. */
node = SLP_INSTANCE_LOADS (slp_instn)[0];
@@ -1926,7 +1929,7 @@ vect_attempt_slp_rearrange_stmts (slp_instance slp_instn)
/* Gather loads in the SLP graph NODE and populate the INST loads array. */
static void
-vect_gather_slp_loads (slp_instance inst, slp_tree node,
+vect_gather_slp_loads (vec , slp_tree node,
hash_set )
{
if (visited.add (node))
@@ -1939,14 +1942,14 @@ vect_gather_slp_loads (slp_instance inst, slp_tree node,
stmt_vec_info stmt_info = SLP_TREE_SCALAR_STMTS (node)[0];
if (STMT_VINFO_GROUPED_ACCESS (stmt_info)
&& DR_IS_READ
[PATCH 1/n] Remove SLP_INSTANCE_GROUP_SIZE
This is a part of a WIP series doing vectorizer rework. To be committed
when stage1 opens.
This removes the SLP_INSTANCE_GROUP_SIZE member since the number of
lanes throughout a SLP subgraph is not necessarily constant.
* tree-vectorizer.h (SLP_INSTANCE_GROUP_SIZE): Remove.
(_slp_instance::group_size): Likewise.
* ...
---
gcc/tree-vect-data-refs.c | 12 ++--
gcc/tree-vect-loop.c | 2 +-
gcc/tree-vect-slp.c | 46 ++
gcc/tree-vect-stmts.c | 26 +-
gcc/tree-vectorizer.h | 10 +-
5 files changed, 51 insertions(+), 45 deletions(-)
diff --git a/gcc/tree-vect-data-refs.c b/gcc/tree-vect-data-refs.c
index 0192aa64636..db92c818287 100644
--- a/gcc/tree-vect-data-refs.c
+++ b/gcc/tree-vect-data-refs.c
@@ -695,7 +695,7 @@ vect_slp_analyze_data_ref_dependence (vec_info *vinfo,
disambiguating the loads. */
static bool
-vect_slp_analyze_node_dependences (slp_instance instance, slp_tree node,
+vect_slp_analyze_node_dependences (slp_tree node,
vec stores,
stmt_vec_info last_store_info)
{
@@ -704,7 +704,7 @@ vect_slp_analyze_node_dependences (slp_instance instance,
slp_tree node,
group. */
stmt_vec_info last_access_info = vect_find_last_scalar_stmt_in_slp (node);
vec_info *vinfo = last_access_info->vinfo;
- for (unsigned k = 0; k < SLP_INSTANCE_GROUP_SIZE (instance); ++k)
+ for (unsigned k = 0; k < SLP_TREE_SCALAR_STMTS (node).length (); ++k)
{
stmt_vec_info access_info = SLP_TREE_SCALAR_STMTS (node)[k];
if (access_info == last_access_info)
@@ -794,12 +794,12 @@ vect_slp_analyze_instance_dependence (slp_instance
instance)
stmt_vec_info last_store_info = NULL;
if (store)
{
- if (! vect_slp_analyze_node_dependences (instance, store, vNULL, NULL))
+ if (! vect_slp_analyze_node_dependences (store, vNULL, NULL))
return false;
/* Mark stores in this instance and remember the last one. */
last_store_info = vect_find_last_scalar_stmt_in_slp (store);
- for (unsigned k = 0; k < SLP_INSTANCE_GROUP_SIZE (instance); ++k)
+ for (unsigned k = 0; k < SLP_TREE_SCALAR_STMTS (store).length (); ++k)
gimple_set_visited (SLP_TREE_SCALAR_STMTS (store)[k]->stmt, true);
}
@@ -810,7 +810,7 @@ vect_slp_analyze_instance_dependence (slp_instance instance)
slp_tree load;
unsigned int i;
FOR_EACH_VEC_ELT (SLP_INSTANCE_LOADS (instance), i, load)
-if (! vect_slp_analyze_node_dependences (instance, load,
+if (! vect_slp_analyze_node_dependences (load,
store
? SLP_TREE_SCALAR_STMTS (store)
: vNULL, last_store_info))
@@ -821,7 +821,7 @@ vect_slp_analyze_instance_dependence (slp_instance instance)
/* Unset the visited flag. */
if (store)
-for (unsigned k = 0; k < SLP_INSTANCE_GROUP_SIZE (instance); ++k)
+for (unsigned k = 0; k < SLP_TREE_SCALAR_STMTS (store).length (); ++k)
gimple_set_visited (SLP_TREE_SCALAR_STMTS (store)[k]->stmt, false);
return res;
diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c
index 53fccb715ef..e7c3daefb92 100644
--- a/gcc/tree-vect-loop.c
+++ b/gcc/tree-vect-loop.c
@@ -6527,7 +6527,7 @@ vectorizable_reduction (stmt_vec_info stmt_info, slp_tree
slp_node,
which each SLP statement has its own initial value and in which
that value needs to be repeated for every instance of the
statement within the initial vector. */
- unsigned int group_size = SLP_INSTANCE_GROUP_SIZE (slp_node_instance);
+ unsigned int group_size = SLP_TREE_SCALAR_STMTS (slp_node).length ();
if (!neutral_op
&& !can_duplicate_and_interleave_p (loop_vinfo, group_size,
TREE_TYPE (vectype_out)))
diff --git a/gcc/tree-vect-slp.c b/gcc/tree-vect-slp.c
index 9d17e3386fa..3308e1791f1 100644
--- a/gcc/tree-vect-slp.c
+++ b/gcc/tree-vect-slp.c
@@ -1846,7 +1846,6 @@ vect_slp_rearrange_stmts (slp_tree node, unsigned int
group_size,
static bool
vect_attempt_slp_rearrange_stmts (slp_instance slp_instn)
{
- unsigned int group_size = SLP_INSTANCE_GROUP_SIZE (slp_instn);
unsigned int i, j;
unsigned int lidx;
slp_tree node, load;
@@ -1854,14 +1853,16 @@ vect_attempt_slp_rearrange_stmts (slp_instance
slp_instn)
/* Compare all the permutation sequences to the first one. We know
that at least one load is permuted. */
node = SLP_INSTANCE_LOADS (slp_instn)[0];
- if (!node->load_permutation.exists ())
+ if (!SLP_TREE_LOAD_PERMUTATION (node).exists ())
return false;
+ unsigned int group_size = SLP_TREE_LOAD_PERMUTATION (node).length ();
for (i = 1; SLP_INSTANCE_LOADS (slp_instn).iterate (i, ); ++i)
{
- if (!load->load_permutation.exists ())
+
Re: [PATCH v3][ARM][GCC][2/x]: MVE ACLE intrinsics framework patch.
Hi Kyrill, I have re-based this patch, please commit the following patch on my behalf. https://gcc.gnu.org/pipermail/gcc-patches/2020-March/541826.html Regards, SRI. From: Gcc-patches on behalf of Srinath Parvathaneni Sent: 16 March 2020 10:54 To: Kyrill Tkachov ; gcc-patches@gcc.gnu.org Subject: Re: [PATCH v3][ARM][GCC][2/x]: MVE ACLE intrinsics framework patch. Hi Kyrill, > Ok, but make sure it bootstraps on arm-none-linux-gnueabihf (as with the other patches in this series) I have bootstrapped this patch on arm-none-linux-gnueabihf and found no issues. There is problem with git commit rights, could you commit this patch on my behalf. Regards SRI. From: Kyrill Tkachov Sent: 12 March 2020 11:16 To: Srinath Parvathaneni ; gcc-patches@gcc.gnu.org Subject: Re: [PATCH v3][ARM][GCC][2/x]: MVE ACLE intrinsics framework patch. Hi Srinath, On 3/10/20 6:19 PM, Srinath Parvathaneni wrote: > Hello Kyrill, > > This patch addresses all the comments in patch version v2. > (version v2) > https://gcc.gnu.org/pipermail/gcc-patches/2020-February/540416.html > > > > > Hello, > > This patch is part of MVE ACLE intrinsics framework. > This patches add support to update (read/write) the APSR (Application > Program Status Register) > register and FPSCR (Floating-point Status and Control Register) > register for MVE. > This patch also enables thumb2 mov RTL patterns for MVE. > > A new feature bit vfp_base is added. This bit is enabled for all VFP, > MVE and MVE with floating point > extensions. This bit is used to enable the macro TARGET_VFP_BASE. For > all the VFP instructions, RTL patterns, > status and control registers are guarded by TARGET_HAVE_FLOAT. But > this patch modifies that and the > common instructions, RTL patterns, status and control registers > bewteen MVE and VFP are guarded by > TARGET_VFP_BASE macro. > > The RTL pattern set_fpscr and get_fpscr are updated to use > VFPCC_REGNUM because few MVE intrinsics > set/get carry bit of FPSCR register. > > Please refer to Arm reference manual [1] for more details. > [1] https://developer.arm.com/docs/ddi0553/latest > > Regression tested on target arm-none-eabi and armeb-none-eabi and > found no regressions. > > Ok for trunk? Ok, but make sure it bootstraps on arm-none-linux-gnueabihf (as with the other patches in this series) Thanks, Kyrill > > Thanks, > Srinath > gcc/ChangeLog: > > 2020-03-06 Andre Vieira > Mihail Ionescu > Srinath Parvathaneni > > * common/config/arm/arm-common.c (arm_asm_auto_mfpu): When > vfp_base > feature bit is on and -mfpu=auto is passed as compiler option, > do not > generate error on not finding any match fpu. Because in this > case fpu > is not required. > * config/arm/arm-cpus.in (vfp_base): Define feature bit, this > bit is > enabled for MVE and also for all VFP extensions. > (VFPv2): Modify fgroup to enable vfp_base feature bit when > ever VFPv2 > is enabled. > (MVE): Define fgroup to enable feature bits mve, vfp_base and > armv7em. > (MVE_FP): Define fgroup to enable feature bits is fgroup MVE > and FPv5 > along with feature bits mve_float. > (mve): Modify add options in armv8.1-m.main arch for MVE. > (mve.fp): Modify add options in armv8.1-m.main arch for MVE with > floating point. > * config/arm/arm.c (use_return_insn): Replace the > check with TARGET_VFP_BASE. > (thumb2_legitimate_index_p): Replace TARGET_HARD_FLOAT with > TARGET_VFP_BASE. > (arm_rtx_costs_internal): Replace "TARGET_HARD_FLOAT || > TARGET_HAVE_MVE" > with TARGET_VFP_BASE, to allow cost calculations for copies in > MVE as > well. > (arm_get_vfp_saved_size): Replace TARGET_HARD_FLOAT with > TARGET_VFP_BASE, to allow space calculation for VFP registers > in MVE > as well. > (arm_compute_frame_layout): Likewise. > (arm_save_coproc_regs): Likewise. > (arm_fixed_condition_code_regs): Modify to enable using > VFPCC_REGNUM > in MVE as well. > (arm_hard_regno_mode_ok): Replace "TARGET_HARD_FLOAT || > TARGET_HAVE_MVE" > with equivalent macro TARGET_VFP_BASE. > (arm_expand_epilogue_apcs_frame): Likewise. > (arm_expand_epilogue): Likewise. > (arm_conditional_register_usage): Likewise. > (arm_declare_function_name): Add check to skip printing .fpu > directive > in assembly file when TARGET_VFP_BASE is enabled and > fpu_to_print is > "softvfp". > * config/arm/arm.h (TARGET_VFP_BASE): Define. > * config/arm/arm.md (arch): Add "mve" to arch. > (eq_attr "arch" "mve"): Enable on TARGET_HAVE_MVE is true. > (vfp_pop_multiple_with_writeback): Replace "TARGET_HARD_FLOAT > || TARGET_HAVE_MVE" with equivalent macro TARGET_VFP_BASE. > *
[PATCH v2][ARM][GCC][3/3x]: MVE intrinsics with ternary operands.
Hello Kyrill, Following patch is the rebased version of v1. (version v1) https://gcc.gnu.org/pipermail/gcc-patches/2019-November/534322.html Hello, This patch supports following MVE ACLE intrinsics with ternary operands. vrmlaldavhaxq_s32, vrmlsldavhaq_s32, vrmlsldavhaxq_s32, vaddlvaq_p_s32, vcvtbq_m_f16_f32, vcvtbq_m_f32_f16, vcvttq_m_f16_f32, vcvttq_m_f32_f16, vrev16q_m_s8, vrev32q_m_f16, vrmlaldavhq_p_s32, vrmlaldavhxq_p_s32, vrmlsldavhq_p_s32, vrmlsldavhxq_p_s32, vaddlvaq_p_u32, vrev16q_m_u8, vrmlaldavhq_p_u32, vmvnq_m_n_s16, vorrq_m_n_s16, vqrshrntq_n_s16, vqshrnbq_n_s16, vqshrntq_n_s16, vrshrnbq_n_s16, vrshrntq_n_s16, vshrnbq_n_s16, vshrntq_n_s16, vcmlaq_f16, vcmlaq_rot180_f16, vcmlaq_rot270_f16, vcmlaq_rot90_f16, vfmaq_f16, vfmaq_n_f16, vfmasq_n_f16, vfmsq_f16, vmlaldavaq_s16, vmlaldavaxq_s16, vmlsldavaq_s16, vmlsldavaxq_s16, vabsq_m_f16, vcvtmq_m_s16_f16, vcvtnq_m_s16_f16, vcvtpq_m_s16_f16, vcvtq_m_s16_f16, vdupq_m_n_f16, vmaxnmaq_m_f16, vmaxnmavq_p_f16, vmaxnmvq_p_f16, vminnmaq_m_f16, vminnmavq_p_f16, vminnmvq_p_f16, vmlaldavq_p_s16, vmlaldavxq_p_s16, vmlsldavq_p_s16, vmlsldavxq_p_s16, vmovlbq_m_s8, vmovltq_m_s8, vmovnbq_m_s16, vmovntq_m_s16, vnegq_m_f16, vpselq_f16, vqmovnbq_m_s16, vqmovntq_m_s16, vrev32q_m_s8, vrev64q_m_f16, vrndaq_m_f16, vrndmq_m_f16, vrndnq_m_f16, vrndpq_m_f16, vrndq_m_f16, vrndxq_m_f16, vcmpeqq_m_n_f16, vcmpgeq_m_f16, vcmpgeq_m_n_f16, vcmpgtq_m_f16, vcmpgtq_m_n_f16, vcmpleq_m_f16, vcmpleq_m_n_f16, vcmpltq_m_f16, vcmpltq_m_n_f16, vcmpneq_m_f16, vcmpneq_m_n_f16, vmvnq_m_n_u16, vorrq_m_n_u16, vqrshruntq_n_s16, vqshrunbq_n_s16, vqshruntq_n_s16, vcvtmq_m_u16_f16, vcvtnq_m_u16_f16, vcvtpq_m_u16_f16, vcvtq_m_u16_f16, vqmovunbq_m_s16, vqmovuntq_m_s16, vqrshrntq_n_u16, vqshrnbq_n_u16, vqshrntq_n_u16, vrshrnbq_n_u16, vrshrntq_n_u16, vshrnbq_n_u16, vshrntq_n_u16, vmlaldavaq_u16, vmlaldavaxq_u16, vmlaldavq_p_u16, vmlaldavxq_p_u16, vmovlbq_m_u8, vmovltq_m_u8, vmovnbq_m_u16, vmovntq_m_u16, vqmovnbq_m_u16, vqmovntq_m_u16, vrev32q_m_u8, vmvnq_m_n_s32, vorrq_m_n_s32, vqrshrntq_n_s32, vqshrnbq_n_s32, vqshrntq_n_s32, vrshrnbq_n_s32, vrshrntq_n_s32, vshrnbq_n_s32, vshrntq_n_s32, vcmlaq_f32, vcmlaq_rot180_f32, vcmlaq_rot270_f32, vcmlaq_rot90_f32, vfmaq_f32, vfmaq_n_f32, vfmasq_n_f32, vfmsq_f32, vmlaldavaq_s32, vmlaldavaxq_s32, vmlsldavaq_s32, vmlsldavaxq_s32, vabsq_m_f32, vcvtmq_m_s32_f32, vcvtnq_m_s32_f32, vcvtpq_m_s32_f32, vcvtq_m_s32_f32, vdupq_m_n_f32, vmaxnmaq_m_f32, vmaxnmavq_p_f32, vmaxnmvq_p_f32, vminnmaq_m_f32, vminnmavq_p_f32, vminnmvq_p_f32, vmlaldavq_p_s32, vmlaldavxq_p_s32, vmlsldavq_p_s32, vmlsldavxq_p_s32, vmovlbq_m_s16, vmovltq_m_s16, vmovnbq_m_s32, vmovntq_m_s32, vnegq_m_f32, vpselq_f32, vqmovnbq_m_s32, vqmovntq_m_s32, vrev32q_m_s16, vrev64q_m_f32, vrndaq_m_f32, vrndmq_m_f32, vrndnq_m_f32, vrndpq_m_f32, vrndq_m_f32, vrndxq_m_f32, vcmpeqq_m_n_f32, vcmpgeq_m_f32, vcmpgeq_m_n_f32, vcmpgtq_m_f32, vcmpgtq_m_n_f32, vcmpleq_m_f32, vcmpleq_m_n_f32, vcmpltq_m_f32, vcmpltq_m_n_f32, vcmpneq_m_f32, vcmpneq_m_n_f32, vmvnq_m_n_u32, vorrq_m_n_u32, vqrshruntq_n_s32, vqshrunbq_n_s32, vqshruntq_n_s32, vcvtmq_m_u32_f32, vcvtnq_m_u32_f32, vcvtpq_m_u32_f32, vcvtq_m_u32_f32, vqmovunbq_m_s32, vqmovuntq_m_s32, vqrshrntq_n_u32, vqshrnbq_n_u32, vqshrntq_n_u32, vrshrnbq_n_u32, vrshrntq_n_u32, vshrnbq_n_u32, vshrntq_n_u32, vmlaldavaq_u32, vmlaldavaxq_u32, vmlaldavq_p_u32, vmlaldavxq_p_u32, vmovlbq_m_u16, vmovltq_m_u16, vmovnbq_m_u32, vmovntq_m_u32, vqmovnbq_m_u32, vqmovntq_m_u32, vrev32q_m_u16. 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-10-29 Andre Vieira Mihail Ionescu Srinath Parvathaneni * config/arm/arm_mve.h (vrmlaldavhaxq_s32): Define macro. (vrmlsldavhaq_s32): Likewise. (vrmlsldavhaxq_s32): Likewise. (vaddlvaq_p_s32): Likewise. (vcvtbq_m_f16_f32): Likewise. (vcvtbq_m_f32_f16): Likewise. (vcvttq_m_f16_f32): Likewise. (vcvttq_m_f32_f16): Likewise. (vrev16q_m_s8): Likewise. (vrev32q_m_f16): Likewise. (vrmlaldavhq_p_s32): Likewise. (vrmlaldavhxq_p_s32): Likewise. (vrmlsldavhq_p_s32): Likewise. (vrmlsldavhxq_p_s32): Likewise. (vaddlvaq_p_u32): Likewise. (vrev16q_m_u8): Likewise. (vrmlaldavhq_p_u32): Likewise. (vmvnq_m_n_s16): Likewise. (vorrq_m_n_s16): Likewise. (vqrshrntq_n_s16): Likewise. (vqshrnbq_n_s16): Likewise. (vqshrntq_n_s16): Likewise. (vrshrnbq_n_s16): Likewise. (vrshrntq_n_s16): Likewise. (vshrnbq_n_s16): Likewise. (vshrntq_n_s16): Likewise. (vcmlaq_f16): Likewise. (vcmlaq_rot180_f16): Likewise. (vcmlaq_rot270_f16): Likewise.
[PATCH v2][ARM][GCC][1/3x]: MVE intrinsics with ternary operands.
Hello Kyrill, Following patch is the rebased version of v1. (version v1) https://gcc.gnu.org/pipermail/gcc-patches/2019-November/534358.html Hello, This patch supports following MVE ACLE intrinsics with ternary operands. vabavq_s8, vabavq_s16, vabavq_s32, vbicq_m_n_s16, vbicq_m_n_s32, vbicq_m_n_u16, vbicq_m_n_u32, vcmpeqq_m_f16, vcmpeqq_m_f32, vcvtaq_m_s16_f16, vcvtaq_m_u16_f16, vcvtaq_m_s32_f32, vcvtaq_m_u32_f32, vcvtq_m_f16_s16, vcvtq_m_f16_u16, vcvtq_m_f32_s32, vcvtq_m_f32_u32, vqrshrnbq_n_s16, vqrshrnbq_n_u16, vqrshrnbq_n_s32, vqrshrnbq_n_u32, vqrshrunbq_n_s16, vqrshrunbq_n_s32, vrmlaldavhaq_s32, vrmlaldavhaq_u32, vshlcq_s8, vshlcq_u8, vshlcq_s16, vshlcq_u16, vshlcq_s32, vshlcq_u32, vabavq_s8, vabavq_s16, vabavq_s32. 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-10-23 Andre Vieira Mihail Ionescu Srinath Parvathaneni * config/arm/arm-builtins.c (TERNOP_UNONE_UNONE_UNONE_IMM_QUALIFIERS): Define qualifier for ternary operands. (TERNOP_UNONE_UNONE_NONE_NONE_QUALIFIERS): Likewise. (TERNOP_UNONE_NONE_UNONE_IMM_QUALIFIERS): Likewise. (TERNOP_NONE_NONE_UNONE_IMM_QUALIFIERS): Likewise. (TERNOP_UNONE_UNONE_NONE_IMM_QUALIFIERS): Likewise. (TERNOP_UNONE_UNONE_NONE_UNONE_QUALIFIERS): Likewise. (TERNOP_UNONE_UNONE_IMM_UNONE_QUALIFIERS): Likewise. (TERNOP_UNONE_NONE_NONE_UNONE_QUALIFIERS): Likewise. (TERNOP_NONE_NONE_NONE_IMM_QUALIFIERS): Likewise. (TERNOP_NONE_NONE_NONE_UNONE_QUALIFIERS): Likewise. (TERNOP_NONE_NONE_IMM_UNONE_QUALIFIERS): Likewise. (TERNOP_NONE_NONE_UNONE_UNONE_QUALIFIERS): Likewise. (TERNOP_UNONE_UNONE_UNONE_UNONE_QUALIFIERS): Likewise. (TERNOP_NONE_NONE_NONE_NONE_QUALIFIERS): Likewise. * config/arm/arm_mve.h (vabavq_s8): Define macro. (vabavq_s16): Likewise. (vabavq_s32): Likewise. (vbicq_m_n_s16): Likewise. (vbicq_m_n_s32): Likewise. (vbicq_m_n_u16): Likewise. (vbicq_m_n_u32): Likewise. (vcmpeqq_m_f16): Likewise. (vcmpeqq_m_f32): Likewise. (vcvtaq_m_s16_f16): Likewise. (vcvtaq_m_u16_f16): Likewise. (vcvtaq_m_s32_f32): Likewise. (vcvtaq_m_u32_f32): Likewise. (vcvtq_m_f16_s16): Likewise. (vcvtq_m_f16_u16): Likewise. (vcvtq_m_f32_s32): Likewise. (vcvtq_m_f32_u32): Likewise. (vqrshrnbq_n_s16): Likewise. (vqrshrnbq_n_u16): Likewise. (vqrshrnbq_n_s32): Likewise. (vqrshrnbq_n_u32): Likewise. (vqrshrunbq_n_s16): Likewise. (vqrshrunbq_n_s32): Likewise. (vrmlaldavhaq_s32): Likewise. (vrmlaldavhaq_u32): Likewise. (vshlcq_s8): Likewise. (vshlcq_u8): Likewise. (vshlcq_s16): Likewise. (vshlcq_u16): Likewise. (vshlcq_s32): Likewise. (vshlcq_u32): Likewise. (vabavq_u8): Likewise. (vabavq_u16): Likewise. (vabavq_u32): Likewise. (__arm_vabavq_s8): Define intrinsic. (__arm_vabavq_s16): Likewise. (__arm_vabavq_s32): Likewise. (__arm_vabavq_u8): Likewise. (__arm_vabavq_u16): Likewise. (__arm_vabavq_u32): Likewise. (__arm_vbicq_m_n_s16): Likewise. (__arm_vbicq_m_n_s32): Likewise. (__arm_vbicq_m_n_u16): Likewise. (__arm_vbicq_m_n_u32): Likewise. (__arm_vqrshrnbq_n_s16): Likewise. (__arm_vqrshrnbq_n_u16): Likewise. (__arm_vqrshrnbq_n_s32): Likewise. (__arm_vqrshrnbq_n_u32): Likewise. (__arm_vqrshrunbq_n_s16): Likewise. (__arm_vqrshrunbq_n_s32): Likewise. (__arm_vrmlaldavhaq_s32): Likewise. (__arm_vrmlaldavhaq_u32): Likewise. (__arm_vshlcq_s8): Likewise. (__arm_vshlcq_u8): Likewise. (__arm_vshlcq_s16): Likewise. (__arm_vshlcq_u16): Likewise. (__arm_vshlcq_s32): Likewise. (__arm_vshlcq_u32): Likewise. (__arm_vcmpeqq_m_f16): Likewise. (__arm_vcmpeqq_m_f32): Likewise. (__arm_vcvtaq_m_s16_f16): Likewise. (__arm_vcvtaq_m_u16_f16): Likewise. (__arm_vcvtaq_m_s32_f32): Likewise. (__arm_vcvtaq_m_u32_f32): Likewise. (__arm_vcvtq_m_f16_s16): Likewise. (__arm_vcvtq_m_f16_u16): Likewise. (__arm_vcvtq_m_f32_s32): Likewise. (__arm_vcvtq_m_f32_u32): Likewise. (vcvtaq_m): Define polymorphic variant. (vcvtq_m): Likewise. (vabavq): Likewise. (vshlcq): Likewise. (vbicq_m_n): Likewise. (vqrshrnbq_n): Likewise. (vqrshrunbq_n): Likewise. * config/arm/arm_mve_builtins.def (TERNOP_UNONE_UNONE_UNONE_IMM_QUALIFIERS): Use the builtin
[PATCH v2][ARM][GCC][2/3x]: MVE intrinsics with ternary operands.
Hello Kyrill, Following patch is the rebased version of v1. (version v1) https://gcc.gnu.org/pipermail/gcc-patches/2019-November/534355.html Hello, This patch supports following MVE ACLE intrinsics with ternary operands. vpselq_u8, vpselq_s8, vrev64q_m_u8, vqrdmlashq_n_u8, vqrdmlahq_n_u8, vqdmlahq_n_u8, vmvnq_m_u8, vmlasq_n_u8, vmlaq_n_u8, vmladavq_p_u8, vmladavaq_u8, vminvq_p_u8, vmaxvq_p_u8, vdupq_m_n_u8, vcmpneq_m_u8, vcmpneq_m_n_u8, vcmphiq_m_u8, vcmphiq_m_n_u8, vcmpeqq_m_u8, vcmpeqq_m_n_u8, vcmpcsq_m_u8, vcmpcsq_m_n_u8, vclzq_m_u8, vaddvaq_p_u8, vsriq_n_u8, vsliq_n_u8, vshlq_m_r_u8, vrshlq_m_n_u8, vqshlq_m_r_u8, vqrshlq_m_n_u8, vminavq_p_s8, vminaq_m_s8, vmaxavq_p_s8, vmaxaq_m_s8, vcmpneq_m_s8, vcmpneq_m_n_s8, vcmpltq_m_s8, vcmpltq_m_n_s8, vcmpleq_m_s8, vcmpleq_m_n_s8, vcmpgtq_m_s8, vcmpgtq_m_n_s8, vcmpgeq_m_s8, vcmpgeq_m_n_s8, vcmpeqq_m_s8, vcmpeqq_m_n_s8, vshlq_m_r_s8, vrshlq_m_n_s8, vrev64q_m_s8, vqshlq_m_r_s8, vqrshlq_m_n_s8, vqnegq_m_s8, vqabsq_m_s8, vnegq_m_s8, vmvnq_m_s8, vmlsdavxq_p_s8, vmlsdavq_p_s8, vmladavxq_p_s8, vmladavq_p_s8, vminvq_p_s8, vmaxvq_p_s8, vdupq_m_n_s8, vclzq_m_s8, vclsq_m_s8, vaddvaq_p_s8, vabsq_m_s8, vqrdmlsdhxq_s8, vqrdmlsdhq_s8, vqrdmlashq_n_s8, vqrdmlahq_n_s8, vqrdmladhxq_s8, vqrdmladhq_s8, vqdmlsdhxq_s8, vqdmlsdhq_s8, vqdmlahq_n_s8, vqdmladhxq_s8, vqdmladhq_s8, vmlsdavaxq_s8, vmlsdavaq_s8, vmlasq_n_s8, vmlaq_n_s8, vmladavaxq_s8, vmladavaq_s8, vsriq_n_s8, vsliq_n_s8, vpselq_u16, vpselq_s16, vrev64q_m_u16, vqrdmlashq_n_u16, vqrdmlahq_n_u16, vqdmlahq_n_u16, vmvnq_m_u16, vmlasq_n_u16, vmlaq_n_u16, vmladavq_p_u16, vmladavaq_u16, vminvq_p_u16, vmaxvq_p_u16, vdupq_m_n_u16, vcmpneq_m_u16, vcmpneq_m_n_u16, vcmphiq_m_u16, vcmphiq_m_n_u16, vcmpeqq_m_u16, vcmpeqq_m_n_u16, vcmpcsq_m_u16, vcmpcsq_m_n_u16, vclzq_m_u16, vaddvaq_p_u16, vsriq_n_u16, vsliq_n_u16, vshlq_m_r_u16, vrshlq_m_n_u16, vqshlq_m_r_u16, vqrshlq_m_n_u16, vminavq_p_s16, vminaq_m_s16, vmaxavq_p_s16, vmaxaq_m_s16, vcmpneq_m_s16, vcmpneq_m_n_s16, vcmpltq_m_s16, vcmpltq_m_n_s16, vcmpleq_m_s16, vcmpleq_m_n_s16, vcmpgtq_m_s16, vcmpgtq_m_n_s16, vcmpgeq_m_s16, vcmpgeq_m_n_s16, vcmpeqq_m_s16, vcmpeqq_m_n_s16, vshlq_m_r_s16, vrshlq_m_n_s16, vrev64q_m_s16, vqshlq_m_r_s16, vqrshlq_m_n_s16, vqnegq_m_s16, vqabsq_m_s16, vnegq_m_s16, vmvnq_m_s16, vmlsdavxq_p_s16, vmlsdavq_p_s16, vmladavxq_p_s16, vmladavq_p_s16, vminvq_p_s16, vmaxvq_p_s16, vdupq_m_n_s16, vclzq_m_s16, vclsq_m_s16, vaddvaq_p_s16, vabsq_m_s16, vqrdmlsdhxq_s16, vqrdmlsdhq_s16, vqrdmlashq_n_s16, vqrdmlahq_n_s16, vqrdmladhxq_s16, vqrdmladhq_s16, vqdmlsdhxq_s16, vqdmlsdhq_s16, vqdmlahq_n_s16, vqdmladhxq_s16, vqdmladhq_s16, vmlsdavaxq_s16, vmlsdavaq_s16, vmlasq_n_s16, vmlaq_n_s16, vmladavaxq_s16, vmladavaq_s16, vsriq_n_s16, vsliq_n_s16, vpselq_u32, vpselq_s32, vrev64q_m_u32, vqrdmlashq_n_u32, vqrdmlahq_n_u32, vqdmlahq_n_u32, vmvnq_m_u32, vmlasq_n_u32, vmlaq_n_u32, vmladavq_p_u32, vmladavaq_u32, vminvq_p_u32, vmaxvq_p_u32, vdupq_m_n_u32, vcmpneq_m_u32, vcmpneq_m_n_u32, vcmphiq_m_u32, vcmphiq_m_n_u32, vcmpeqq_m_u32, vcmpeqq_m_n_u32, vcmpcsq_m_u32, vcmpcsq_m_n_u32, vclzq_m_u32, vaddvaq_p_u32, vsriq_n_u32, vsliq_n_u32, vshlq_m_r_u32, vrshlq_m_n_u32, vqshlq_m_r_u32, vqrshlq_m_n_u32, vminavq_p_s32, vminaq_m_s32, vmaxavq_p_s32, vmaxaq_m_s32, vcmpneq_m_s32, vcmpneq_m_n_s32, vcmpltq_m_s32, vcmpltq_m_n_s32, vcmpleq_m_s32, vcmpleq_m_n_s32, vcmpgtq_m_s32, vcmpgtq_m_n_s32, vcmpgeq_m_s32, vcmpgeq_m_n_s32, vcmpeqq_m_s32, vcmpeqq_m_n_s32, vshlq_m_r_s32, vrshlq_m_n_s32, vrev64q_m_s32, vqshlq_m_r_s32, vqrshlq_m_n_s32, vqnegq_m_s32, vqabsq_m_s32, vnegq_m_s32, vmvnq_m_s32, vmlsdavxq_p_s32, vmlsdavq_p_s32, vmladavxq_p_s32, vmladavq_p_s32, vminvq_p_s32, vmaxvq_p_s32, vdupq_m_n_s32, vclzq_m_s32, vclsq_m_s32, vaddvaq_p_s32, vabsq_m_s32, vqrdmlsdhxq_s32, vqrdmlsdhq_s32, vqrdmlashq_n_s32, vqrdmlahq_n_s32, vqrdmladhxq_s32, vqrdmladhq_s32, vqdmlsdhxq_s32, vqdmlsdhq_s32, vqdmlahq_n_s32, vqdmladhxq_s32, vqdmladhq_s32, vmlsdavaxq_s32, vmlsdavaq_s32, vmlasq_n_s32, vmlaq_n_s32, vmladavaxq_s32, vmladavaq_s32, vsriq_n_s32, vsliq_n_s32, vpselq_u64, vpselq_s64. 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 In this patch new constraints "Rc" and "Re" are added, which checks the constant is with in the range of 0 to 15 and 0 to 31 respectively. Also a new predicates "mve_imm_15" and "mve_imm_31" are added, to check the the matching constraint Rc and Re respectively. Regression tested on arm-none-eabi and found no regressions. Ok for trunk? Thanks, Srinath. gcc/ChangeLog: 2019-10-25 Andre Vieira Mihail Ionescu Srinath Parvathaneni * config/arm/arm_mve.h (vpselq_u8): Define macro. (vpselq_s8): Likewise. (vrev64q_m_u8): Likewise. (vqrdmlashq_n_u8): Likewise. (vqrdmlahq_n_u8): Likewise. (vqdmlahq_n_u8): Likewise. (vmvnq_m_u8): Likewise. (vmlasq_n_u8): Likewise.
Re: [PATCH] libstdc++: Skip 91371.cc for x32.
On 13/03/20 20:38 +0100, Uros Bizjak via Libstdc++ wrote:
x32 does not support MS ABI, skip testcases that require it.
2020-03-13 Uroš Bizjak
* testsuite/20_util/bind/91371.cc: Skip for x32.
* testsuite/20_util/is_function/91371.cc: Ditto.
* testsuite/20_util/is_member_function_pointer/91371.cc: Ditto.
* testsuite/20_util/is_object/91371.cc: Ditto.
Tested on x86_64-linux-gnu {,-mx32}.
Fixes -mx32 libstdc++ failures in [1].
OK for mainline?
OK, thanks.
Re: [PATCH][RFC] API extension for binutils (type of symbols).
On Thu, Mar 12, 2020 at 7:54 AM Martin Liška wrote: > > Hi. > > There's updated version of the patch. > Changes from the previous version: > - comment added to ld_plugin_symbol > - new section renamed to ext_symtab > - assert added for loop iterations in produce_symtab and > produce_symtab_extension > > Martin 2020-03-12 Martin Liska * plugin-api.h (struct ld_plugin_symbol): Split int def into 4 char fields. (enum ld_plugin_symbol_type): New. (enum ld_plugin_symbol_section_flags): New. (enum ld_plugin_tag): Add LDPT_GET_SYMBOLS_V and ^^^ Typo, should be LDPT_ADD_SYMBOLS_V2. LDPT_GET_SYMBOLS_V4. -- H.J.
Re: [PATCH v3][ARM][GCC][2/x]: MVE ACLE intrinsics framework patch.
Hi Kyrill, > Ok, but make sure it bootstraps on arm-none-linux-gnueabihf (as with the other patches in this series) I have bootstrapped this patch on arm-none-linux-gnueabihf and found no issues. There is problem with git commit rights, could you commit this patch on my behalf. Regards SRI. From: Kyrill Tkachov Sent: 12 March 2020 11:16 To: Srinath Parvathaneni ; gcc-patches@gcc.gnu.org Subject: Re: [PATCH v3][ARM][GCC][2/x]: MVE ACLE intrinsics framework patch. Hi Srinath, On 3/10/20 6:19 PM, Srinath Parvathaneni wrote: > Hello Kyrill, > > This patch addresses all the comments in patch version v2. > (version v2) > https://gcc.gnu.org/pipermail/gcc-patches/2020-February/540416.html > > > > > Hello, > > This patch is part of MVE ACLE intrinsics framework. > This patches add support to update (read/write) the APSR (Application > Program Status Register) > register and FPSCR (Floating-point Status and Control Register) > register for MVE. > This patch also enables thumb2 mov RTL patterns for MVE. > > A new feature bit vfp_base is added. This bit is enabled for all VFP, > MVE and MVE with floating point > extensions. This bit is used to enable the macro TARGET_VFP_BASE. For > all the VFP instructions, RTL patterns, > status and control registers are guarded by TARGET_HAVE_FLOAT. But > this patch modifies that and the > common instructions, RTL patterns, status and control registers > bewteen MVE and VFP are guarded by > TARGET_VFP_BASE macro. > > The RTL pattern set_fpscr and get_fpscr are updated to use > VFPCC_REGNUM because few MVE intrinsics > set/get carry bit of FPSCR register. > > Please refer to Arm reference manual [1] for more details. > [1] https://developer.arm.com/docs/ddi0553/latest > > Regression tested on target arm-none-eabi and armeb-none-eabi and > found no regressions. > > Ok for trunk? Ok, but make sure it bootstraps on arm-none-linux-gnueabihf (as with the other patches in this series) Thanks, Kyrill > > Thanks, > Srinath > gcc/ChangeLog: > > 2020-03-06 Andre Vieira > Mihail Ionescu > Srinath Parvathaneni > > * common/config/arm/arm-common.c (arm_asm_auto_mfpu): When > vfp_base > feature bit is on and -mfpu=auto is passed as compiler option, > do not > generate error on not finding any match fpu. Because in this > case fpu > is not required. > * config/arm/arm-cpus.in (vfp_base): Define feature bit, this > bit is > enabled for MVE and also for all VFP extensions. > (VFPv2): Modify fgroup to enable vfp_base feature bit when > ever VFPv2 > is enabled. > (MVE): Define fgroup to enable feature bits mve, vfp_base and > armv7em. > (MVE_FP): Define fgroup to enable feature bits is fgroup MVE > and FPv5 > along with feature bits mve_float. > (mve): Modify add options in armv8.1-m.main arch for MVE. > (mve.fp): Modify add options in armv8.1-m.main arch for MVE with > floating point. > * config/arm/arm.c (use_return_insn): Replace the > check with TARGET_VFP_BASE. > (thumb2_legitimate_index_p): Replace TARGET_HARD_FLOAT with > TARGET_VFP_BASE. > (arm_rtx_costs_internal): Replace "TARGET_HARD_FLOAT || > TARGET_HAVE_MVE" > with TARGET_VFP_BASE, to allow cost calculations for copies in > MVE as > well. > (arm_get_vfp_saved_size): Replace TARGET_HARD_FLOAT with > TARGET_VFP_BASE, to allow space calculation for VFP registers > in MVE > as well. > (arm_compute_frame_layout): Likewise. > (arm_save_coproc_regs): Likewise. > (arm_fixed_condition_code_regs): Modify to enable using > VFPCC_REGNUM > in MVE as well. > (arm_hard_regno_mode_ok): Replace "TARGET_HARD_FLOAT || > TARGET_HAVE_MVE" > with equivalent macro TARGET_VFP_BASE. > (arm_expand_epilogue_apcs_frame): Likewise. > (arm_expand_epilogue): Likewise. > (arm_conditional_register_usage): Likewise. > (arm_declare_function_name): Add check to skip printing .fpu > directive > in assembly file when TARGET_VFP_BASE is enabled and > fpu_to_print is > "softvfp". > * config/arm/arm.h (TARGET_VFP_BASE): Define. > * config/arm/arm.md (arch): Add "mve" to arch. > (eq_attr "arch" "mve"): Enable on TARGET_HAVE_MVE is true. > (vfp_pop_multiple_with_writeback): Replace "TARGET_HARD_FLOAT > || TARGET_HAVE_MVE" with equivalent macro TARGET_VFP_BASE. > * config/arm/constraints.md (Uf): Define to allow modification > to FPCCR > in MVE. > * config/arm/thumb2.md (thumb2_movsfcc_soft_insn): Modify > target guard > to not allow for MVE. > * config/arm/unspecs.md (UNSPEC_GET_FPSCR): Move to volatile > unspecs > enum. > (VUNSPEC_GET_FPSCR): Define. > * config/arm/vfp.md (thumb2_movhi_vfp): Add support for VMSR
Re: [PATCH v3][ARM][GCC][1/x]: MVE ACLE intrinsics framework patch.
Hi Kyrill, > This is ok but please bootstrap it on arm-none-linux-gnueabihf as well. I have bootstrapped this patch on arm-none-linux-gnueabihf and found no issues. There is problem with git commit rights, could you commit this patch on my behalf. Regards SRI From: Kyrill Tkachov Sent: 12 March 2020 11:15 To: Srinath Parvathaneni ; gcc-patches@gcc.gnu.org Subject: Re: [PATCH v3][ARM][GCC][1/x]: MVE ACLE intrinsics framework patch. Hi Srinath, On 3/10/20 6:19 PM, Srinath Parvathaneni wrote: > Hello Kyrill, > > This patch addresses all the comments in patch version v2. > (version v2) > https://gcc.gnu.org/pipermail/gcc-patches/2020-February/540415.html > > > > Hello, > > This patch creates the required framework for MVE ACLE intrinsics. > > The following changes are done in this patch to support MVE ACLE > intrinsics. > > Header file arm_mve.h is added to source code, which contains the > definitions of MVE ACLE intrinsics > and different data types used in MVE. Machine description file mve.md > is also added which contains the > RTL patterns defined for MVE. > > A new reigster "p0" is added which is used in by MVE predicated > patterns. A new register class "VPR_REG" > is added and its contents are defined in REG_CLASS_CONTENTS. > > The vec-common.md file is modified to support the standard move > patterns. The prefix of neon functions > which are also used by MVE is changed from "neon_" to "simd_". > eg: neon_immediate_valid_for_move changed to > simd_immediate_valid_for_move. > > In the patch standard patterns mve_move, mve_store and move_load for > MVE are added and neon.md and vfp.md > files are modified to support this common patterns. > > Please refer to Arm reference manual [1] for more details. > > [1] https://developer.arm.com/docs/ddi0553/latest > > Regression tested on target arm-none-eabi and armeb-none-eabi and > found no regressions. > > Ok for trunk? This is ok but please bootstrap it on arm-none-linux-gnueabihf as well. Thanks, Kyrill > > Thanks, > Srinath > > gcc/ChangeLog: > > 2020-03-06 Andre Vieira > Mihail Ionescu > Srinath Parvathaneni > > * config.gcc (arm_mve.h): Include mve intrinsics header file. > * config/arm/aout.h (p0): Add new register name for MVE predicated > cases. > * config/arm-builtins.c (ARM_BUILTIN_SIMD_LANE_CHECK): Define > macro > common to Neon and MVE. > (ARM_BUILTIN_NEON_LANE_CHECK): Renamed to > ARM_BUILTIN_SIMD_LANE_CHECK. > (arm_init_simd_builtin_types): Disable poly types for MVE. > (arm_init_neon_builtins): Move a check to arm_init_builtins > function. > (arm_init_builtins): Use ARM_BUILTIN_SIMD_LANE_CHECK instead of > ARM_BUILTIN_NEON_LANE_CHECK. > (mve_dereference_pointer): Add function. > (arm_expand_builtin_args): Call to mve_dereference_pointer > when MVE is > enabled. > (arm_expand_neon_builtin): Moved to arm_expand_builtin function. > (arm_expand_builtin): Moved from arm_expand_neon_builtin function. > * config/arm/arm-c.c (__ARM_FEATURE_MVE): Define macro for MVE > and MVE > with floating point enabled. > * config/arm/arm-protos.h (neon_immediate_valid_for_move): > Renamed to > simd_immediate_valid_for_move. > (simd_immediate_valid_for_move): Renamed from > neon_immediate_valid_for_move function. > * config/arm/arm.c (arm_options_perform_arch_sanity_checks): > Generate > error if vfpv2 feature bit is disabled and mve feature bit is also > disabled for HARD_FLOAT_ABI. > (use_return_insn): Check to not push VFP regs for MVE. > (aapcs_vfp_allocate): Add MVE check to have same Procedure > Call Standard > as Neon. > (aapcs_vfp_allocate_return_reg): Likewise. > (thumb2_legitimate_address_p): Check to return 0 on valid Thumb-2 > address operand for MVE. > (arm_rtx_costs_internal): MVE check to determine cost of rtx. > (neon_valid_immediate): Rename to simd_valid_immediate. > (simd_valid_immediate): Rename from neon_valid_immediate. > (simd_valid_immediate): MVE check on size of vector is 128 bits. > (neon_immediate_valid_for_move): Rename to > simd_immediate_valid_for_move. > (simd_immediate_valid_for_move): Rename from > neon_immediate_valid_for_move. > (neon_immediate_valid_for_logic): Modify call to > neon_valid_immediate > function. > (neon_make_constant): Modify call to neon_valid_immediate > function. > (neon_vector_mem_operand): Return VFP register for POST_INC or > PRE_DEC > for MVE. > (output_move_neon): Add MVE check to generate vldm/vstm > instrcutions. > (arm_compute_frame_layout): Calculate space for saved VFP > registers for > MVE. > (arm_save_coproc_regs): Save coproc registers for MVE. >
Re: [PATCH] Add new wa_noexecstack testsuite effective target.
On 3/16/20 11:07 AM, Rainer Orth wrote: Minus the quoting, it's only 59 chars long... Ah ok. I will make better next time ;) Martin
Re: [PATCH] Add new wa_noexecstack testsuite effective target.
Hi Martin, >>> gcc/testsuite/ChangeLog: >>> >>> 2020-03-16 Martin Liska >>> >>> PR lto/94157 >>> * gcc.dg/lto/pr94157_0.c: Add wa_noexecstack effective >>> target filter. >>> * lib/target-supports.exp: Add >>> check_effective_target_wa_noexecstack. >> One question (because I noticed it in several of your patch submissions >> lately): do you have a particularly short line length configure for >> ChangeLogs or in general? > > I use contrib/vimrc with line length limit 80 chars. > >> Many of the lines are way below a 75 >> character limit, which doesn't improve readablity... > > Thanks for the notice. Do you really suffer from lines slighly > longer than 80 chars? I would (at least a bit), but here I see quite the opposite: lines way way shorter than 80 (or even 75) chars for no appararent reason. Maybe it's your mailer mangling them? See e.g. the first line of your ChangeLog snippet above: >>> * gcc.dg/lto/pr94157_0.c: Add wa_noexecstack effective >>> target filter. Minus the quoting, it's only 59 chars long... Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
[PATCH libphobos]: Committed merge upstream druntime and phobos
Hi,
This patch merges the libphobos implementation with upstream druntime
6c45dd3a, and phobos 68cc18adb.
This change surrounds the gcc-style asm operands with parentheses, as
the old style of optionally omitting is now deprecated.
This is being applied first before the changes to the compiler to
introduce the deprecation.
Bootstrapped and tested on x86_64-linux-gnu, and committed to trunk.
Regards
Iain.
---
libphobos/libdruntime/MERGE | 2 +-
libphobos/libdruntime/core/cpuid.d | 36 ++---
libphobos/src/MERGE | 2 +-
libphobos/src/std/algorithm/iteration.d | 2 +-
libphobos/src/std/math.d| 20 +++---
5 files changed, 33 insertions(+), 29 deletions(-)
diff --git a/libphobos/libdruntime/MERGE b/libphobos/libdruntime/MERGE
index 0e2c5d1c139..54ae72fa54e 100644
--- a/libphobos/libdruntime/MERGE
+++ b/libphobos/libdruntime/MERGE
@@ -1,4 +1,4 @@
-7915b6a399fbb6d9c0db351eb5a8fda7e43fe8c5
+6c45dd3a6523a21887cb9a883eeb3abd40375dc1
The first line of this file holds the git revision number of the last
merge done from the dlang/druntime repository.
diff --git a/libphobos/libdruntime/core/cpuid.d
b/libphobos/libdruntime/core/cpuid.d
index f68465736e7..d35e7d5449f 100644
--- a/libphobos/libdruntime/core/cpuid.d
+++ b/libphobos/libdruntime/core/cpuid.d
@@ -510,7 +510,7 @@ void getcacheinfoCPUID2()
uint numinfos = 1;
do {
version (GNU) asm pure nothrow @nogc {
-"cpuid" : "=a" a[0], "=b" a[1], "=c" a[2], "=d" a[3] : "a" 2;
+"cpuid" : "=a" (a[0]), "=b" (a[1]), "=c" (a[2]), "=d" (a[3]) : "a"
(2);
} else asm pure nothrow @nogc {
mov EAX, 2;
cpuid;
@@ -554,7 +554,7 @@ void getcacheinfoCPUID4()
for (;;) {
uint a, b, number_of_sets;
version (GNU) asm pure nothrow @nogc {
-"cpuid" : "=a" a, "=b" b, "=c" number_of_sets : "a" 4, "c"
cachenum : "edx";
+"cpuid" : "=a" (a), "=b" (b), "=c" (number_of_sets) : "a" (4), "c"
(cachenum) : "edx";
} else asm pure nothrow @nogc {
mov EAX, 4;
mov ECX, cachenum;
@@ -594,7 +594,7 @@ void getAMDcacheinfo()
{
uint dummy, c5, c6, d6;
version (GNU) asm pure nothrow @nogc {
-"cpuid" : "=a" dummy, "=c" c5 : "a" 0x8000_0005 : "ebx", "edx";
+"cpuid" : "=a" (dummy), "=c" (c5) : "a" (0x8000_0005) : "ebx", "edx";
} else asm pure nothrow @nogc {
mov EAX, 0x8000_0005; // L1 cache
cpuid;
@@ -613,7 +613,7 @@ void getAMDcacheinfo()
ubyte numcores = 1;
if (max_extended_cpuid >= 0x8000_0008) {
version (GNU) asm pure nothrow @nogc {
-"cpuid" : "=a" dummy, "=c" numcores : "a" 0x8000_0008 : "ebx",
"edx";
+"cpuid" : "=a" (dummy), "=c" (numcores) : "a" (0x8000_0008) :
"ebx", "edx";
} else asm pure nothrow @nogc {
mov EAX, 0x8000_0008;
cpuid;
@@ -624,7 +624,7 @@ void getAMDcacheinfo()
}
version (GNU) asm pure nothrow @nogc {
-"cpuid" : "=a" dummy, "=c" c6, "=d" d6 : "a" 0x8000_0006 : "ebx";
+"cpuid" : "=a" (dummy), "=c" (c6), "=d" (d6) : "a" (0x8000_0006) :
"ebx";
} else asm pure nothrow @nogc {
mov EAX, 0x8000_0006; // L2/L3 cache
cpuid;
@@ -653,7 +653,7 @@ void getCpuInfo0B()
uint a, b, c, d;
do {
version (GNU) asm pure nothrow @nogc {
-"cpuid" : "=a" a, "=b" b, "=c" c, "=d" d : "a" 0x0B, "c" level;
+"cpuid" : "=a" (a), "=b" (b), "=c" (c), "=d" (d) : "a" (0x0B), "c"
(level);
} else asm pure nothrow @nogc {
mov EAX, 0x0B;
mov ECX, level;
@@ -686,8 +686,10 @@ void cpuidX86()
uint* venptr = cast(uint*)cf.vendorID.ptr;
version (GNU)
{
-asm pure nothrow @nogc { "cpuid" : "=a" max_cpuid, "=b" venptr[0],
"=d" venptr[1], "=c" venptr[2] : "a" 0; }
-asm pure nothrow @nogc { "cpuid" : "=a" max_extended_cpuid : "a"
0x8000_ : "ebx", "ecx", "edx"; }
+asm pure nothrow @nogc {
+"cpuid" : "=a" (max_cpuid), "=b" (venptr[0]), "=d" (venptr[1]),
"=c" (venptr[2]) : "a" (0);
+"cpuid" : "=a" (max_extended_cpuid) : "a" (0x8000_) : "ebx",
"ecx", "edx";
+}
}
else
{
@@ -730,7 +732,7 @@ void cpuidX86()
cf.probablyAMD = cf.vendorID == "AuthenticAMD";
uint apic = 0; // brand index, apic id
version (GNU) asm pure nothrow @nogc {
-"cpuid" : "=a" a, "=b" apic, "=c" cf.miscfeatures, "=d" cf.features :
"a" 1;
+"cpuid" : "=a" (a), "=b" (apic), "=c" (cf.miscfeatures), "=d"
(cf.features) : "a" (1);
} else {
asm pure nothrow @nogc {
mov EAX, 1; // model, stepping
@@ -753,7 +755,7 @@ void cpuidX86()
if (max_cpuid >= 7)
{
version (GNU) asm pure nothrow @nogc {
-"cpuid" : "=a" a, "=b" cf.extfeatures, "=c"
[PATCH d]: Committed merge with upstream dmd
Hi,
This patch merges the D front-end implementation with upstream dmd
b061bd744.
Fixes an ICE in the parser, and deprecates a previously allowed style of
syntax that deviated from GNU-style extended asm.
Bootstrapped and tested on x86_64-linux-gnu, and committed to trunk.
Regards
Iain.
---
gcc/testsuite/ChangeLog:
2020-03-16 Iain Buclaw
* gdc.dg/asm1.d: Add new test for ICE in asm parser.
* gdc.dg/asm5.d: New test.
---
gcc/d/dmd/MERGE | 2 +-
gcc/d/dmd/iasmgcc.c | 30 +++---
gcc/testsuite/ChangeLog | 5 +
gcc/testsuite/gdc.dg/asm1.d | 9 +
gcc/testsuite/gdc.dg/asm5.d | 12
5 files changed, 54 insertions(+), 4 deletions(-)
create mode 100644 gcc/testsuite/gdc.dg/asm5.d
diff --git a/gcc/d/dmd/MERGE b/gcc/d/dmd/MERGE
index b017c037d74..6cbc4e37819 100644
--- a/gcc/d/dmd/MERGE
+++ b/gcc/d/dmd/MERGE
@@ -1,4 +1,4 @@
-e9420cfbf5cd0cf9e6e398603e009ccc8e14d324
+b061bd744cb4eb94a7118581387d988d4ec25e97
The first line of this file holds the git revision number of the last
merge done from the dlang/dmd repository.
diff --git a/gcc/d/dmd/iasmgcc.c b/gcc/d/dmd/iasmgcc.c
index cecbdefe41a..548453321db 100644
--- a/gcc/d/dmd/iasmgcc.c
+++ b/gcc/d/dmd/iasmgcc.c
@@ -13,6 +13,7 @@
#include "scope.h"
#include "declaration.h"
+#include "errors.h"
#include "parse.h"
#include "statement.h"
@@ -23,8 +24,8 @@ Statement *semantic(Statement *s, Scope *sc);
* Parse list of extended asm input or output operands.
* Grammar:
* | Operands:
- * | SymbolicName(opt) StringLiteral AssignExpression
- * | SymbolicName(opt) StringLiteral AssignExpression , Operands
+ * | SymbolicName(opt) StringLiteral ( AssignExpression )
+ * | SymbolicName(opt) StringLiteral ( AssignExpression ), Operands
* |
* | SymbolicName:
* | [ Identifier ]
@@ -54,7 +55,9 @@ static int parseExtAsmOperands(Parser *p, GccAsmStatement *s)
case TOKlbracket:
if (p->peekNext() == TOKidentifier)
{
+// Skip over openings `[`
p->nextToken();
+// Store the symbolic name
name = p->token.ident;
p->nextToken();
}
@@ -63,12 +66,32 @@ static int parseExtAsmOperands(Parser *p, GccAsmStatement
*s)
p->error(s->loc, "expected identifier after `[`");
goto Lerror;
}
+// Look for closing `]`
p->check(TOKrbracket);
+// Look for the string literal and fall through
+if (p->token.value != TOKstring)
+goto Ldefault;
// fall through
case TOKstring:
constraint = p->parsePrimaryExp();
-arg = p->parseAssignExp();
+// @@@DEPRECATED@@@
+// Old parser allowed omitting parentheses around the
expression.
+// Deprecated in 2.091. Can be made permanent error after 2.100
+if (p->token.value != TOKlparen)
+{
+arg = p->parseAssignExp();
+deprecation(arg->loc, "`%s` must be surrounded by
parentheses", arg->toChars());
+}
+else
+{
+// Look for the opening `(`
+p->check(TOKlparen);
+// Parse the assign expression
+arg = p->parseAssignExp();
+// Look for the closing `)`
+p->check(TOKrparen);
+}
if (!s->args)
{
@@ -86,6 +109,7 @@ static int parseExtAsmOperands(Parser *p, GccAsmStatement *s)
break;
default:
+Ldefault:
p->error("expected constant string constraint for operand, not
`%s`",
p->token.toChars());
goto Lerror;
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index ab0406656d2..32a51b96a0e 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,8 @@
+2020-03-16 Iain Buclaw
+
+ * gdc.dg/asm1.d: Add new test for ICE in asm parser.
+ * gdc.dg/asm5.d: New test.
+
2020-03-16 Bin Cheng
PR tree-optimization/94125
diff --git a/gcc/testsuite/gdc.dg/asm1.d b/gcc/testsuite/gdc.dg/asm1.d
index 7b00e4d54ec..3fcfd6a58c1 100644
--- a/gcc/testsuite/gdc.dg/asm1.d
+++ b/gcc/testsuite/gdc.dg/asm1.d
@@ -29,6 +29,15 @@ void parse3()
// { dg-error "found 'EOF' when expecting ';'" "" { target *-*-* } .-4 }
}
+void parse4()
+{
+int expr;
+asm
+{
+"%name" : [name] string (expr); // { dg-error "expected constant
string constraint for operand, not 'string'" }
+}
+}
+
void semantic1()
{
{
diff --git a/gcc/testsuite/gdc.dg/asm5.d
Re: [PATCH] Add new wa_noexecstack testsuite effective target.
On 3/16/20 9:48 AM, Rainer Orth wrote:
Hi Martin,
It's fix for Darwin target and similar others which do
not support the asembler directive.
Ready for master?
I'm usually all for using effective-target keywords instead of ad-hoc
tests or target lists, but this seems like a single-use case and thus a
bit too much. Maybe restrict to gas instead?
Yes, good idea!
Or is it possible to
change the test in a way that doesn't depend on special unportable
target assembler options? I haven't looked admittedly.
If none of this works out:
* Please change the keyword to as_execstack (assuming that an assembler
supports the positive form support the negative one, too). "wa"
doesn't tell me anything...
* This needs documenting in sourcebuild.texi, as always.
So, if there's really no other option: ok with those changes.
gcc/testsuite/ChangeLog:
2020-03-16 Martin Liska
PR lto/94157
* gcc.dg/lto/pr94157_0.c: Add wa_noexecstack effective
target filter.
* lib/target-supports.exp: Add
check_effective_target_wa_noexecstack.
One question (because I noticed it in several of your patch submissions
lately): do you have a particularly short line length configure for
ChangeLogs or in general?
I use contrib/vimrc with line length limit 80 chars.
Many of the lines are way below a 75
character limit, which doesn't improve readablity...
Thanks for the notice. Do you really suffer from lines slighly
longer than 80 chars?
Martin
Rainer
>From 023c3b3e8c530b98fdc6bae91e2dc58aa2336c2f Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Mon, 16 Mar 2020 09:24:44 +0100
Subject: [PATCH] Filter a test-case with gas.
gcc/testsuite/ChangeLog:
2020-03-16 Martin Liska
PR lto/94157
* gcc.dg/lto/pr94157_0.c: Add gas effective
target filter.
---
gcc/testsuite/gcc.dg/lto/pr94157_0.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/gcc/testsuite/gcc.dg/lto/pr94157_0.c b/gcc/testsuite/gcc.dg/lto/pr94157_0.c
index 3bca677c4fb..a6e308b855b 100644
--- a/gcc/testsuite/gcc.dg/lto/pr94157_0.c
+++ b/gcc/testsuite/gcc.dg/lto/pr94157_0.c
@@ -1,4 +1,5 @@
/* { dg-lto-do link } */
+/* { dg-require-effective-target gas } */
/* { dg-lto-options { { -O0 -fipa-vrp -flto -Wa,--noexecstack -Wa,--noexecstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack } } } */
int main() {
--
2.25.1
Re: [PING PATCH coroutines] Do not strip cleanup_point when promote temporaries out of current stmt
On Wed, Mar 11, 2020 at 5:07 PM Iain Sandoe wrote: > > Bin.Cheng wrote: > > > On Thu, Mar 5, 2020 at 10:18 PM Iain Sandoe wrote: > > >> With current trunk + Bin’s two approved patches. > >> > >> I see no change in the testcase (lambda-09-capture-object.C) before / after > >> the patch > >> (it fails for me at -O0 only - in both cases). > > > > > I tried exactly what you did, however, the result is different. > > I am a bit concerned that we get different results - yesterday I retested > this on: > Linux : x86_64-linux (cfarm gcc122) > Darwin (x86_64-darwin16), > with the same results on both platforms. > > 1) I applied the two testcases (note I have renamed > lambda-09-capture-object.C => lambda-11-capture-object.C so that the test > numbers are sequential). However, I have not changed the test in any other > way. > > Native configuration is x86_64-pc-linux-gnu > > === g++ tests === > > Schedule of variations: > unix/-m32 > unix/-m64 > > Running target unix/-m32 > Using /usr/share/dejagnu/baseboards/unix.exp as board description file for > target. > Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. > Using /home/iains/gcc-master/src-patched/gcc/testsuite/config/default.exp as > tool-and-target-specific interface file. > Running > /home/iains/gcc-master/src-patched/gcc/testsuite/g++.dg/coroutines/coroutines.exp > ... > FAIL: g++.dg/coroutines/co-await-syntax-10.C (internal compiler error) > FAIL: g++.dg/coroutines/co-await-syntax-10.C (test for excess errors) > FAIL: g++.dg/coroutines/torture/lambda-11-capture-object.C (internal compiler > error) > FAIL: g++.dg/coroutines/torture/lambda-11-capture-object.C (test for excess > errors) > Running > /home/iains/gcc-master/src-patched/gcc/testsuite/g++.dg/coroutines/torture/coro-torture.exp > ... > FAIL: g++.dg/coroutines/torture/lambda-11-capture-object.C -O0 (internal > compiler error) > FAIL: g++.dg/coroutines/torture/lambda-11-capture-object.C -O0 (test for > excess errors) > > Running target unix/-m64 > Using /usr/share/dejagnu/baseboards/unix.exp as board description file for > target. > Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. > Using /home/iains/gcc-master/src-patched/gcc/testsuite/config/default.exp as > tool-and-target-specific interface file. > Running > /home/iains/gcc-master/src-patched/gcc/testsuite/g++.dg/coroutines/coroutines.exp > ... > FAIL: g++.dg/coroutines/co-await-syntax-10.C (internal compiler error) > FAIL: g++.dg/coroutines/co-await-syntax-10.C (test for excess errors) > FAIL: g++.dg/coroutines/torture/lambda-11-capture-object.C (internal compiler > error) > FAIL: g++.dg/coroutines/torture/lambda-11-capture-object.C (test for excess > errors) > Running > /home/iains/gcc-master/src-patched/gcc/testsuite/g++.dg/coroutines/torture/coro-torture.exp > ... > FAIL: g++.dg/coroutines/torture/lambda-11-capture-object.C -O0 (internal > compiler error) > FAIL: g++.dg/coroutines/torture/lambda-11-capture-object.C -O0 (test for > excess errors) > > ^^ so, this shows that both tests fail (co-await-syntax-10.C is expected) > > 2) I apply Bin’s patch (Pickup more CO_AWAIT_EXPR expanding cases) (which is > approved) > > Native configuration is x86_64-pc-linux-gnu > > === g++ tests === > > Schedule of variations: > unix/-m32 > unix/-m64 > > Running target unix/-m32 > Using /usr/share/dejagnu/baseboards/unix.exp as board description file for > target. > Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. > Using /home/iains/gcc-master/src-patched/gcc/testsuite/config/default.exp as > tool-and-target-specific interface file. > Running > /home/iains/gcc-master/src-patched/gcc/testsuite/g++.dg/coroutines/coroutines.exp > ... > FAIL: g++.dg/coroutines/torture/lambda-11-capture-object.C (internal compiler > error) > FAIL: g++.dg/coroutines/torture/lambda-11-capture-object.C (test for excess > errors) > Running > /home/iains/gcc-master/src-patched/gcc/testsuite/g++.dg/coroutines/torture/coro-torture.exp > ... > FAIL: g++.dg/coroutines/torture/lambda-11-capture-object.C -O0 (internal > compiler error) > FAIL: g++.dg/coroutines/torture/lambda-11-capture-object.C -O0 (test for > excess errors) > > Running target unix/-m64 > Using /usr/share/dejagnu/baseboards/unix.exp as board description file for > target. > Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. > Using /home/iains/gcc-master/src-patched/gcc/testsuite/config/default.exp as > tool-and-target-specific interface file. > Running > /home/iains/gcc-master/src-patched/gcc/testsuite/g++.dg/coroutines/coroutines.exp > ... > FAIL: g++.dg/coroutines/torture/lambda-11-capture-object.C (internal compiler > error) > FAIL: g++.dg/coroutines/torture/lambda-11-capture-object.C (test for excess > errors) > Running >
Re: [PATCH] Add new wa_noexecstack testsuite effective target.
Hi Martin, > It's fix for Darwin target and similar others which do > not support the asembler directive. > > Ready for master? I'm usually all for using effective-target keywords instead of ad-hoc tests or target lists, but this seems like a single-use case and thus a bit too much. Maybe restrict to gas instead? Or is it possible to change the test in a way that doesn't depend on special unportable target assembler options? I haven't looked admittedly. If none of this works out: * Please change the keyword to as_execstack (assuming that an assembler supports the positive form support the negative one, too). "wa" doesn't tell me anything... * This needs documenting in sourcebuild.texi, as always. So, if there's really no other option: ok with those changes. > gcc/testsuite/ChangeLog: > > 2020-03-16 Martin Liska > > PR lto/94157 > * gcc.dg/lto/pr94157_0.c: Add wa_noexecstack effective > target filter. > * lib/target-supports.exp: Add > check_effective_target_wa_noexecstack. One question (because I noticed it in several of your patch submissions lately): do you have a particularly short line length configure for ChangeLogs or in general? Many of the lines are way below a 75 character limit, which doesn't improve readablity... Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
[PATCH] Add new wa_noexecstack testsuite effective target.
Hi.
It's fix for Darwin target and similar others which do
not support the asembler directive.
Ready for master?
Thanks,
Martin
gcc/testsuite/ChangeLog:
2020-03-16 Martin Liska
PR lto/94157
* gcc.dg/lto/pr94157_0.c: Add wa_noexecstack effective
target filter.
* lib/target-supports.exp: Add
check_effective_target_wa_noexecstack.
---
gcc/testsuite/gcc.dg/lto/pr94157_0.c | 1 +
gcc/testsuite/lib/target-supports.exp | 10 ++
2 files changed, 11 insertions(+)
diff --git a/gcc/testsuite/gcc.dg/lto/pr94157_0.c b/gcc/testsuite/gcc.dg/lto/pr94157_0.c
index 3bca677c4fb..3745fee217f 100644
--- a/gcc/testsuite/gcc.dg/lto/pr94157_0.c
+++ b/gcc/testsuite/gcc.dg/lto/pr94157_0.c
@@ -1,4 +1,5 @@
/* { dg-lto-do link } */
+/* { dg-require-effective-target wa_noexecstack } */
/* { dg-lto-options { { -O0 -fipa-vrp -flto -Wa,--noexecstack -Wa,--noexecstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack } } } */
int main() {
diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index ca3895c2269..589192d9edb 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -1022,6 +1022,16 @@ proc check_effective_target_fgnu_tm {} {
} "-fgnu-tm"]
}
+# Return 1 if compilation with -Wa,--noexecstack is error-free for trivial
+# code, 0 otherwise.
+
+proc check_effective_target_wa_noexecstack {} {
+return [check_no_compiler_messages wa_noexecstack object {
+ void foo (void) { }
+} "-Wa,--noexecstack"]
+}
+
+
# Return 1 if the target supports mmap, 0 otherwise.
proc check_effective_target_mmap {} {
[PATCH] c: Handle MEM_REF in c_fully_fold* [PR94179]
Hi!
The recent match.pd changes can generate a MEM_REF which can be seen by the
C FE folding routines. Unlike the C++ FE, they weren't expected in the C FE
yet. MEM_REF should be handled like INDIRECT_REF, except that it has two
operands rather than just one and that we should preserve the type of the
second operand. Given that it already has to be an INTEGER_CST with pointer
type, I think we are fine, the recursive call should return the INTEGER_CST
unmodified and STRIP_TYPE_NOPS will not strip anything.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2020-03-16 Jakub Jelinek
PR c/94179
* c-fold.c (c_fully_fold_internal): Handle MEM_REF.
* gcc.c-torture/compile/pr94179.c: New test.
--- gcc/c/c-fold.c.jj 2020-01-12 11:54:36.208416501 +0100
+++ gcc/c/c-fold.c 2020-03-15 17:26:42.863491563 +0100
@@ -346,6 +346,7 @@ c_fully_fold_internal (tree expr, bool i
case UNGT_EXPR:
case UNGE_EXPR:
case UNEQ_EXPR:
+case MEM_REF:
/* Binary operations evaluating both arguments (increment and
decrement are binary internally in GCC). */
orig_op0 = op0 = TREE_OPERAND (expr, 0);
@@ -435,6 +436,14 @@ c_fully_fold_internal (tree expr, bool i
|| TREE_CODE (TREE_TYPE (orig_op0)) == FIXED_POINT_TYPE)
&& TREE_CODE (TREE_TYPE (orig_op1)) == INTEGER_TYPE)
warn_for_div_by_zero (loc, op1);
+ if (code == MEM_REF
+ && ret != expr
+ && TREE_CODE (ret) == MEM_REF)
+ {
+ TREE_READONLY (ret) = TREE_READONLY (expr);
+ TREE_SIDE_EFFECTS (ret) = TREE_SIDE_EFFECTS (expr);
+ TREE_THIS_VOLATILE (ret) = TREE_THIS_VOLATILE (expr);
+ }
goto out;
case ADDR_EXPR:
--- gcc/testsuite/gcc.c-torture/compile/pr94179.c.jj2020-03-15
17:14:20.782511288 +0100
+++ gcc/testsuite/gcc.c-torture/compile/pr94179.c 2020-03-15
17:13:48.913984847 +0100
@@ -0,0 +1,9 @@
+/* PR c/94179 */
+
+struct S { char c, d, e[64]; } a;
+
+unsigned char *
+foo (int b)
+{
+ return (unsigned char *)((char *)[b != 0] - (char *)&((struct S *)0)->d);
+}
Jakub
Re: [PATCH] tree-inline: Fix a -fcompare-debug issue in the inliner [PR94167]
On Sat, 14 Mar 2020, Jakub Jelinek wrote:
> Hi!
>
> The following testcase fails with -fcompare-debug. The problem is that
> bar is marked as address_taken only with -g and not without.
> I've tracked it down to insert_init_stmt calling gimple_regimplify_operands
> even on DEBUG_STMTs. That function will just insert normal stmts before
> the DEBUG_STMT if the DEBUG_STMT operand isn't gimple val or invariant.
> While DCE will turn those statements into debug temporaries, it can cause
> differences in SSA_NAMEs and more importantly, the ipa references are
> generated from those before the DCE happens.
> On the testcase, the DEBUG_STMT value is (int)bar.
>
> We could generate DEBUG_STMTs with debug temporaries instead, but I fail to
> see the reason to do that, DEBUG_STMTs allow other expressions and all we
> want to ensure is that the expressions aren't too large (arbitrarily
> complex), but during inlining/function versioning I don't see why something
> would queue a DEBUG_STMT with arbitrarily complex expressions in there.
>
> So, this patch just doesn't regimplify DEBUG_STMTs. Bootstrapped/regtested
> on x86_64-linux and i686-linux, ok for trunk?
OK.
Thanks,
Richard.
> 2020-03-14 Jakub Jelinek
>
> PR debug/94167
> * tree-inline.c (insert_init_stmt): Don't gimple_regimplify_operands
> DEBUG_STMTs.
>
> * gcc.dg/pr94167.c: New test.
>
> --- gcc/tree-inline.c.jj 2020-03-04 12:58:35.033528551 +0100
> +++ gcc/tree-inline.c 2020-03-13 16:19:04.129493354 +0100
> @@ -3361,10 +3361,10 @@ insert_init_stmt (copy_body_data *id, ba
> gimple_assign_set_rhs1 (init_stmt, rhs);
> }
>gsi_insert_after (, init_stmt, GSI_NEW_STMT);
> - gimple_regimplify_operands (init_stmt, );
> -
>if (!is_gimple_debug (init_stmt))
> {
> + gimple_regimplify_operands (init_stmt, );
> +
> tree def = gimple_assign_lhs (init_stmt);
> insert_init_debug_bind (id, bb, def, def, init_stmt);
> }
> --- gcc/testsuite/gcc.dg/pr94167.c.jj 2020-03-13 16:33:34.046632902 +0100
> +++ gcc/testsuite/gcc.dg/pr94167.c2020-03-13 16:33:08.353012748 +0100
> @@ -0,0 +1,33 @@
> +/* PR debug/94167 */
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -fcompare-debug" } */
> +
> +struct S { int g, h; signed char i; int j; signed char k; int l[4]; } a, c;
> +struct T { signed char g; } e;
> +int *b, d;
> +static void foo ();
> +
> +void
> +bar (void)
> +{
> + while (d)
> +{
> + int k;
> + struct T f[3];
> + foo (bar, a);
> + for (k = 0;; k++)
> + f[k] = e;
> +}
> +}
> +
> +static inline void
> +foo (int x, struct S y, struct T z)
> +{
> + for (z.g = 2; z.g; z.g--)
> +{
> + c = a = y;
> + *b |= 6;
> + if (y.g)
> + break;
> +}
> +}
>
> Jakub
>
>
--
Richard Biener
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
Re: [PATCH] reassoc: Avoid code generation to depend on hash_map traversal [PR94166]
On Sat, 14 Mar 2020, Jakub Jelinek wrote:
> Hi!
>
> On the following testcase, if there is ASLR, the compiler generates
> different code each time (out of 1000 invocations 994 unique assembler
> contents). The problem is that undistribute_bitref_for_vector uses
> a hash_map from a tree (SSA_NAME) to a vector and such a hash_map is
> by default doing pointer hashing on the SSA_NAME rather than using
> something stable (SSA_NAME_VERSION).
> One possible way would be to use SSA_NAME_VERSION as hash function,
> but given that we from the hash_map traversal just populate a vector
> which is then sorted, I think it is easier to make the sort callback
> use SSA_NAME_VERSION as secondary sorting key and thus ensure stable
> sort (that is generally desirable anyway).
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
OK.
Thanks,
Richard.
> 2020-03-14 Jakub Jelinek
>
> PR tree-optimization/94166
> * tree-ssa-reassoc.c (sort_by_mach_mode): Use SSA_NAME_VERSION
> as secondary comparison key.
>
> * gcc.dg/pr94166.c: New test.
>
> --- gcc/tree-ssa-reassoc.c.jj 2020-01-12 11:54:38.510381771 +0100
> +++ gcc/tree-ssa-reassoc.c2020-03-13 14:06:32.358085863 +0100
> @@ -1793,8 +1793,11 @@ sort_by_mach_mode (const void *p_i, cons
> return 1;
>else if (mode1 < mode2)
> return -1;
> - else
> -return 0;
> + if (SSA_NAME_VERSION (tr1) < SSA_NAME_VERSION (tr2))
> +return -1;
> + else if (SSA_NAME_VERSION (tr1) > SSA_NAME_VERSION (tr2))
> +return 1;
> + return 0;
> }
>
> /* Cleanup hash map for VECTOR information. */
> --- gcc/testsuite/gcc.dg/pr94166.c.jj 2020-03-13 14:36:46.382260562 +0100
> +++ gcc/testsuite/gcc.dg/pr94166.c2020-03-13 14:40:32.536916640 +0100
> @@ -0,0 +1,24 @@
> +/* PR tree-optimization/94166 */
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -fcompare-debug" } */
> +
> +typedef int __m128i __attribute__((__may_alias__, __vector_size__(4 * sizeof
> (int;
> +unsigned int b[512];
> +
> +void
> +foo (unsigned int *x, __m128i *y)
> +{
> +#define A(n) __m128i v##n = y[n];
> +#define B(n) A(n##0) A(n##1) A(n##2) A(n##3) A(n##4) A(n##5) A(n##6) A(n##7)
> \
> + A(n##8) A(n##9) A(n##a) A(n##b) A(n##c) A(n##d) A(n##e) A(n##f)
> +#define C(n) B(n##0) B(n##1) B(n##2) B(n##3) B(n##4) B(n##5) B(n##6) B(n##7)
> + C(0x)
> +#undef A
> +#define A(n) *(__m128i *) [4 * n] = v##n;
> + C(0x)
> +#undef A
> +#define A(n) + b[4 * n] + b[4 * n + 1] + b[4 * n + 2] + b[4 * n + 3]
> + *x = *x
> + C(0x)
> + ;
> +}
>
> Jakub
>
>
--
Richard Biener
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
RE: [PATCH PR94026] combine missed opportunity to simplify comparisons with zero
Hi, > -Original Message- > From: Segher Boessenkool [mailto:seg...@kernel.crashing.org] > Sent: Saturday, March 14, 2020 12:07 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 Fri, Mar 13, 2020 at 03:21:18AM +, Yangfei (Felix) wrote: > > > On Wed, Mar 04, 2020 at 08:39:36AM +, Yangfei (Felix) wrote: > > > > This is a simple fix for PR94026. > > > > With this fix, combine will try make an extraction if we are in > > > > a equality > > > comparison and this is an AND > > > > with a constant which is power of two minus one. Shift here > > > > should be an > > > constant. For example, combine > > > > will transform (compare (and (lshiftrt x 8) 6) 0) to (compare > > > > (zero_extract > > > (x 2 9)) 0). > > > > > > Why is that a good thing? > > > > The reported test case is reduced from spec2017 541.leela_r. I have pasted > original code snippet on the bugzilla. > > We found other compilers like aocc/llvm can catch this pattern and simplify > > it. > > That wasn't my question, let me rephrase: why would writing it as zero_extract > (instead of as a more canonical form) be wanted? Sorry for not getting your point here. > The aarch backend only has zero_extract formulations for most of the bitfield > instructions. If you fix that problem, all of this should go away? Like, the > testcase in the PR starts with > > Trying 7 -> 8: > 7: r99:SI=r103:SI>>r104:SI#0 > REG_DEAD r104:SI > REG_DEAD r103:SI > 8: r100:SI=r99:SI&0x6 > REG_DEAD r99:SI > Failed to match this instruction: > (set (reg:SI 100) > (and:SI (ashiftrt:SI (reg:SI 103) > (subreg:QI (reg:SI 104) 0)) > (const_int 6 [0x6]))) > > and that should match already (that's an ubfm (ubfx))? For aarch64, if we use "ubfm/ubfx" for the reduced test case, then we still need to do a compare with zero. Then we won't get the benefit. For aarch64, we need to emit a "tst" instruction here. So we need to catch something like: 149 (set (reg:CC_NZ 66 cc) 150 (compare:CC_NZ (and:SI (lshiftrt:SI (reg:SI 102) 151 (const_int 8 [0x8])) 152 (const_int 6 [0x6])) 153 (const_int 0 [0]))) But this pattern is not accurate enough: we can only accept equality comparison with zero here (as indicated by the checking of equality_comparison in my original patch). Also, this issue is there for ports like x86. If we go that way, then we need to handle each port affected. So I am inclined to handle this in an arch-independent way. I looked into tree phases like fwprop & fold-const before, but didn't see an appropriate point to catch this opportunity. Then I came to the combine phase. > > > > (There should be thorough tests on many archs, showing it helps on > > > average, and it doesn't regress anything. I can do that for you, but not > right now). > > > > I only have aarch64 & x86_64 linux available and have tested this patch with > spec17 on both platforms. > > No obvious improvement & regression witnessed. This is expected as only > one instruction is reduced here. > > What should be tested is what new combinations are done, and which are *no > longer* done. In theory, we won't lose but emit more zero_extract with my patch. > > > In general, we should have *fewer* zero_extract, not more. > > Some reasons for that: > > 1) All those can be expressed with simpler operations as well; > 2) Most very similar expressions cannot be expressed as zero_extract, > although many architectures can handle (some of) those just fine; > 3) The optimizers do not handle zero_extract very well at all (this includes > simplify-rtx, to start with). > > sign_extract is nastier -- we really want to have a sign_extend that works on > separate bits, not as coarse as address units as we have now -- but it > currently > isn't handled much either. Thanks for explaining this. I have to admit that I didn't realize this issue when I was creating my original patch. Felix
