[pushed] c++: Fix DMI with lambda 'this' capture [PR94205]

[Jason Merrill via Gcc-patches]

We represent 'this' in a default member initializer with a PLACEHOLDER_EXPR.
Normally in constexpr evaluation when we encounter one it refers to
ctx->ctor, but when we're creating a temporary of class type, that replaces
ctx->ctor, so a PLACEHOLDER_EXPR that refers to the type of the member being
initialized needs to be replaced before that happens.

This patch fixes the testcase below, but not the original testcase from the PR,
which is still broken due to PR94219.

Tested x86_64-pc-linux-gnu, applying to trunk and 9.

gcc/cp/ChangeLog
2020-03-31  Jason Merrill  

PR c++/94205
* constexpr.c (cxx_eval_constant_expression) [TARGET_EXPR]: Call
replace_placeholders.
* typeck2.c (store_init_value): Fix arguments to
fold_non_dependent_expr.
---
 gcc/cp/constexpr.c|  6 ++
 gcc/cp/tree.c |  2 +-
 gcc/cp/typeck2.c  |  2 +-
 gcc/testsuite/g++.dg/cpp0x/constexpr-nsdmi2.C | 20 +++
 gcc/testsuite/g++.dg/cpp1z/lambda-this4.C | 13 
 5 files changed, 41 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/constexpr-nsdmi2.C
 create mode 100644 gcc/testsuite/g++.dg/cpp1z/lambda-this4.C

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index e85b3c113f0..91f0c3ba269 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -5553,6 +5553,12 @@ cxx_eval_constant_expression (const constexpr_ctx *ctx, 
tree t,
tree init = TARGET_EXPR_INITIAL (t);
if ((AGGREGATE_TYPE_P (type) || VECTOR_TYPE_P (type)))
  {
+   if (ctx->object)
+ /* If the initializer contains any PLACEHOLDER_EXPR, we need to
+resolve them before we create a new CONSTRUCTOR for the
+temporary.  */
+ init = replace_placeholders (init, ctx->object);
+
/* We're being expanded without an explicit target, so start
   initializing a new object; expansion with an explicit target
   strips the TARGET_EXPR before we get here.  */
diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
index a2172dea0d8..5eb0dcd717a 100644
--- a/gcc/cp/tree.c
+++ b/gcc/cp/tree.c
@@ -3239,7 +3239,7 @@ replace_placeholders_r (tree* t, int* walk_subtrees, 
void* data_)
a PLACEHOLDER_EXPR has been encountered.  */
 
 tree
-replace_placeholders (tree exp, tree obj, bool *seen_p)
+replace_placeholders (tree exp, tree obj, bool *seen_p /*= NULL*/)
 {
   /* This is only relevant for C++14.  */
   if (cxx_dialect < cxx14)
diff --git a/gcc/cp/typeck2.c b/gcc/cp/typeck2.c
index bff4ddbcf81..cf1cb5ace66 100644
--- a/gcc/cp/typeck2.c
+++ b/gcc/cp/typeck2.c
@@ -871,7 +871,7 @@ store_init_value (tree decl, tree init, vec** 
cleanups, int flags)
 {
   bool const_init;
   tree oldval = value;
-  value = fold_non_dependent_expr (value);
+  value = fold_non_dependent_expr (value, tf_warning_or_error, true, decl);
   if (DECL_DECLARED_CONSTEXPR_P (decl)
  || (DECL_IN_AGGR_P (decl)
  && DECL_INITIALIZED_IN_CLASS_P (decl)))
diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-nsdmi2.C 
b/gcc/testsuite/g++.dg/cpp0x/constexpr-nsdmi2.C
new file mode 100644
index 000..c51f734a134
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/constexpr-nsdmi2.C
@@ -0,0 +1,20 @@
+// PR c++/94205
+// { dg-do compile { target c++14 } }
+
+struct S
+{
+  struct A
+  {
+S *p;
+constexpr A(S* p): p(p) {}
+constexpr operator int() { p->i = 5; return 6; }
+  };
+  int i;
+  int a = A(this);
+};
+
+
+constexpr S s = {};
+
+#define SA(X) static_assert((X),#X)
+SA(s.i == 5 && s.a == 6);
diff --git a/gcc/testsuite/g++.dg/cpp1z/lambda-this4.C 
b/gcc/testsuite/g++.dg/cpp1z/lambda-this4.C
new file mode 100644
index 000..5d968791491
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1z/lambda-this4.C
@@ -0,0 +1,13 @@
+// PR c++/94205
+// { dg-do compile { target c++17 } }
+
+struct S
+{
+  int i;
+  int a = [this] { this->i = 5; return 6; } ();
+};
+
+
+constexpr S s = {};
+
+static_assert (s.i == 5 && s.a == 6);

base-commit: f14b41d27124601284347a10d496362c8b4b8e1c
-- 
2.18.1

Re: [PATCH] PR lto/94249: Correct endianness detection with the __BYTE_ORDER macro

[Hans-Peter Nilsson]

On Tue, 31 Mar 2020, Maciej W. Rozycki wrote:
> Correct an issue with GCC commit 906b3eb9df6c ("Improve endianess
> detection.") and fix a typo in the __BYTE_ORDER fallback macro check
> that causes compilation errors like:
>
> .../include/plugin-api.h:162:2: error: #error "Could not detect architecture 
> endianess"
>
> on systems that do not provide the __BYTE_ORDER__ macro.

> Index: binutils/include/plugin-api.h
> ===
> --- binutils.orig/include/plugin-api.h
> +++ binutils/include/plugin-api.h
> @@ -51,7 +51,7 @@
>  /* Older GCC releases (<4.6.0) can make detection from glibc macros.  */
>  #if defined(__GLIBC__) || defined(__GNU_LIBRARY__) || defined(__ANDROID__)
>  #include 
> -#ifdef _BYTE_ORDER
> +#ifdef __BYTE_ORDER
>  #if __BYTE_ORDER == __LITTLE_ENDIAN
>  #define PLUGIN_LITTLE_ENDIAN 1
>  #elif __BYTE_ORDER == __BIG_ENDIAN

FWIW, I was about to commit that as obvious, also the bignum.h
inclusion thing!

The only question being, how the typo passed any kind of testing
in the first place...  No actually, there's also the question
why the plugin-API needs to bother with host endianness.  It's
not like endians are going to be different between plugins and
gcc on host.

brgds, H-P

Re: [PATCH] [ARC] Allow more ABIs in GLIBC_DYNAMIC_LINKER

[Vineet Gupta via Gcc-patches]

FWIW this change needs a pairing glibc change so must NOT be included for 
upcoming
2020.x release which still has old version of glibc !

-Vineet


On 3/31/20 10:57 AM, Vineet Gupta wrote:
> Well its a hard requirement considering glibc is still using gcc-9 !
>
> Thx,
> -Vineet
>
> On 3/31/20 9:26 AM, Alexey Brodkin wrote:
>> Hi Claus,
>>
>>> -Original Message-
>>> From: linux-snps-arc  On Behalf 
>>> Of Claudiu Zissulescu
>>> Ianculescu
>>> Sent: Tuesday, March 31, 2020 1:07 PM
>>> To: Vineet Gupta 
>>> Cc: linux-snps-...@lists.infradead.org; gcc-patches@gcc.gnu.org; Claudiu 
>>> Zissulescu
>>> 
>>> Subject: Re: [PATCH] [ARC] Allow more ABIs in GLIBC_DYNAMIC_LINKER
>>>
>>> Pushed.
>> Is this one eligible for being back-ported to older GCCs?
>> At least GCC 9.x would be really good.
>>
>> -Alexey
>>  
> ___
> linux-snps-arc mailing list
> linux-snps-...@lists.infradead.org
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_mailman_listinfo_linux-2Dsnps-2Darc=DwICAg=DPL6_X_6JkXFx7AXWqB0tg=c14YS-cH-kdhTOW89KozFhBtBJgs1zXscZojEZQ0THs=xnl4FBxLN70UDZIvD2NTxyfPAenrfQsdij0DBuPImCI=YnG2GxYtFIbUU0FesR19TV7fz0ILe8xncKLnRiqBhOc=
>  

Re: PATCH -- Fix degree trignometric functions

[Fritz Reese via Gcc-patches]

On Fri, Mar 27, 2020 at 7:36 PM Fritz Reese  wrote:
>
> On Fri, Mar 6, 2020 at 6:18 PM Steve Kargl
>  wrote:
> [...]
> > TL;DR version.
> >
> >   Fix the simplification and handling of the degree trigonometric functions.
> >   This includes fixing a number of ICEs.  See PR 93871.
>
> An updated version of the patch is attached. Regression tests (and new
> test cases) are pending.
>

Patch with regression tests attached, and rebased onto master
(013fca64fc...). The new and updated tests cover several issues
discovered and discussed in PR 93871 at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871 . I am
bootstrapping and testing now. If everything passes, does this look OK
to commit?

gcc/fortran/ChangeLog:

PR fortran/93871
* gfortran.h (GFC_ISYM_ACOSD, GFC_ISYM_ASIND, GFC_ISYM_ATAN2D,
GFC_ISYM_ATAND, GFC_ISYM_COSD, GFC_ISYM_COTAND, GFC_ISYM_SIND,
GFC_ISYM_TAND): New.
* intrinsic.c (add_functions): Remove check for flag_dec_math.
Give degree trig functions simplification and name resolution
functions (e.g, gfc_simplify_atrigd () and gfc_resolve_atrigd ()).
(do_simplify): Remove special casing of degree trig functions.
* intrinsic.h (gfc_simplify_acosd, gfc_simplify_asind,
gfc_simplify_atand, gfc_simplify_cosd, gfc_simplify_cotand,
gfc_simplify_sind, gfc_simplify_tand, gfc_resolve_trigd2): Add new
prototypes.
(gfc_simplify_atrigd, gfc_simplify_trigd, gfc_resolve_cotan,
resolve_atrigd): Remove prototypes of deleted functions.
* iresolve.c (is_trig_resolved, copy_replace_function_shallow,
gfc_resolve_cotan, get_radians, get_degrees, resolve_trig_call,
gfc_resolve_atrigd, gfc_resolve_atan2d): Delete functions.
(gfc_resolve_trigd, gfc_resolve_trigd2): Resolve to library functions.
* simplify.c (rad2deg, deg2rad, gfc_simplify_acosd, gfc_simplify_asind,
gfc_simplify_atand, gfc_simplify_atan2d, gfc_simplify_cosd,
gfc_simplify_sind, gfc_simplify_tand, gfc_simplify_cotand): New
functions.
(gfc_simplify_atan2): Fix error message.
(simplify_trig_call, gfc_simplify_trigd, gfc_simplify_atrigd,
radians_f): Delete functions.
* trans-intrinsic.c: Add LIB_FUNCTION decls for sind, cosd, tand.
(rad2deg, gfc_conv_intrinsic_atrigd, gfc_conv_intrinsic_cotan,
gfc_conv_intrinsic_cotand, gfc_conv_intrinsic_atan2d): New functions.
(gfc_conv_intrinsic_function): Handle ACOSD, ASIND, ATAND, COTAN,
COTAND, ATAN2D.
* trigd_fe.inc: New file. Included by simplify.c to implement
simplify_sind, simplify_cosd, simplify_tand with code common to the
libgfortran implementation.

libgfortran/ChangeLog:

PR fortran/93871
* Makefile.am, Makefile.in: New make rule for intrinsics/trigd.c.
* gfortran.map: New routines for {sind, cosd, tand}X{r4, r8, r10, r16}.
* intrinsics/trigd.c, intrinsics/trigd_lib.inc, intrinsics/trigd.inc:
New files. Defines native degree-valued trig functions.

gcc/testsuite/ChangeLog:

PR fortran/93871
* gfortran.dg/dec_math.f90: Extend coverage to real(10) and real(16).
* gfortran.dg/dec_math_2.f90: New test.
* gfortran.dg/dec_math_3.f90: Likewise.
* gfortran.dg/dec_math_4.f90: Likewise.
* gfortran.dg/dec_math_5.f90: Likewise.
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index 96037629f5f..371f77be64d 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -357,6 +357,7 @@ enum gfc_isym_id
   GFC_ISYM_ACCESS,
   GFC_ISYM_ACHAR,
   GFC_ISYM_ACOS,
+  GFC_ISYM_ACOSD,
   GFC_ISYM_ACOSH,
   GFC_ISYM_ADJUSTL,
   GFC_ISYM_ADJUSTR,
@@ -369,10 +370,13 @@ enum gfc_isym_id
   GFC_ISYM_ANINT,
   GFC_ISYM_ANY,
   GFC_ISYM_ASIN,
+  GFC_ISYM_ASIND,
   GFC_ISYM_ASINH,
   GFC_ISYM_ASSOCIATED,
   GFC_ISYM_ATAN,
   GFC_ISYM_ATAN2,
+  GFC_ISYM_ATAN2D,
+  GFC_ISYM_ATAND,
   GFC_ISYM_ATANH,
   GFC_ISYM_ATOMIC_ADD,
   GFC_ISYM_ATOMIC_AND,
@@ -410,8 +414,10 @@ enum gfc_isym_id
   GFC_ISYM_CONJG,
   GFC_ISYM_CONVERSION,
   GFC_ISYM_COS,
+  GFC_ISYM_COSD,
   GFC_ISYM_COSH,
   GFC_ISYM_COTAN,
+  GFC_ISYM_COTAND,
   GFC_ISYM_COUNT,
   GFC_ISYM_CPU_TIME,
   GFC_ISYM_CSHIFT,
@@ -598,6 +604,7 @@ enum gfc_isym_id
   GFC_ISYM_SIGNAL,
   GFC_ISYM_SI_KIND,
   GFC_ISYM_SIN,
+  GFC_ISYM_SIND,
   GFC_ISYM_SINH,
   GFC_ISYM_SIZE,
   GFC_ISYM_SLEEP,
@@ -618,6 +625,7 @@ enum gfc_isym_id
   GFC_ISYM_SYSTEM,
   GFC_ISYM_SYSTEM_CLOCK,
   GFC_ISYM_TAN,
+  GFC_ISYM_TAND,
   GFC_ISYM_TANH,
   GFC_ISYM_TEAM_NUMBER,
   GFC_ISYM_THIS_IMAGE,
diff --git a/gcc/fortran/intrinsic.c b/gcc/fortran/intrinsic.c
index 3012187ddae..17f5efc6566 100644
--- a/gcc/fortran/intrinsic.c
+++ b/gcc/fortran/intrinsic.c
@@ -3281,116 +3281,130 @@ add_functions (void)
 
   make_generic ("loc", GFC_ISYM_LOC, GFC_STD_GNU);
 
-  if (flag_dec_math)
-{
-  add_sym_1 ("acosd", GFC_ISYM_ACOS, CLASS_ELEMENTAL, ACTUAL_YES, 

Re: [PATCH v2 3/9] aarch64: Add cmp_*_carryinC patterns

[Richard Henderson via Gcc-patches]

On 3/31/20 11:34 AM, Richard Sandiford wrote:
>> +(define_insn "*cmp3_carryinC"
>> +  [(set (reg:CC CC_REGNUM)
>> +(compare:CC
>> +  (ANY_EXTEND:
>> +(match_operand:GPI 0 "register_operand" "r"))
>> +  (plus:
>> +(ANY_EXTEND:
>> +  (match_operand:GPI 1 "register_operand" "r"))
>> +(match_operand: 2 "aarch64_borrow_operation" ""]
>> +   ""
>> +   "sbcs\\tzr, %0, %1"
>> +  [(set_attr "type" "adc_reg")]
>> +)
> 
> I guess this feeds into your reply to Segher's comment for 7/9,
> but I think:
> 
>(compare:CC X Y)
> 
> is always supposed to be the NZCV flags result of X - Y, as computed in
> the mode of X and Y.  If so, it seems like the type of extension should
> matter.  E.g. the N flag ought to be set for:
> 
>   (compare:CC
> (sign_extend 0xf...)
> (plus (sign_extend 0x7...)
>   (ltu ...)))
> 
> but ought to be clear for:
> 
>   (compare:CC
> (zero_extend 0xf...)
> (plus (zero_extend 0x7...)
>   (ltu ...)))
> 
> If so, I guess this is a bug in the existing code...

The subject of CCmodes is a sticky one.  It mostly all depends on what combine
is able to do with the patterns.

For instance, your choice of example above, even for signed, the N bit cannot
be examined by itself, because that would only be valid for a comparison
against zero, like

(compare (plus (reg) (reg))
 (const_int 0))

For this particular bit of rtl, the only valid comparison is N == V, i.e. GE/LT.

If we add a new CC mode for this, what would you call it?  Probably not
CC_NVmode, because to me that implies you can use either N or V, but it doesn't
imply you must examine both.

If we add more CC modes, does that mean that we have to improve SELECT_CC_MODE
to match those patterns?  Or do we add new CC modes just so that combine's use
of SELECT_CC_MODE *cannot* match them?


r~

[committed] d: Merge UDAs between function prototype and definitions (PR90136)

[Iain Buclaw via Gcc-patches]

Hi,

This change fixes the symbol merging in get_symbol_decl to also consider
prototypes.  This allows the ability to set user defined attributes on
the prototype of a function, which then get applied to the definition,
if found later in the compilation.

The lowering of UDAs to GCC attributes has been commonized into a single
function called apply_user_attributes.

Bootstrapped and tested on x86_64-linux-gnu.  Comitted to mainline.

Regards
Iain
---

gcc/d/ChangeLog:

PR d/90136
* d-attribs.cc: Include dmd/attrib.h.
(build_attributes): Redeclare as static.
(apply_user_attributes): New function.
* d-tree.h (class UserAttributeDeclaration): Remove.
(build_attributes): Remove.
(apply_user_attributes): Declare.
(finish_aggregate_type): Remove attrs argument.
* decl.cc (get_symbol_decl): Merge declaration prototypes with
definitions.  Use apply_user_attributes.
* modules.cc (layout_moduleinfo_fields): Remove last argument to
finish_aggregate_type.
* typeinfo.cc (layout_classinfo_interfaces): Likewise.
* types.cc (layout_aggregate_members): Likewise.
(finish_aggregate_type): Remove attrs argument.
(TypeVisitor::visit (TypeEnum *)): Use apply_user_attributes.
(TypeVisitor::visit (TypeStruct *)): Remove last argument to
finish_aggregate_type.  Use apply_user_attributes.
(TypeVisitor::visit (TypeClass *)): Likewise.

gcc/testsuite/ChangeLog:

PR d/90136
* gdc.dg/pr90136a.d: New test.
* gdc.dg/pr90136b.d: New test.
* gdc.dg/pr90136c.d: New test.

---
 gcc/d/d-attribs.cc  | 27 +-
 gcc/d/d-tree.h  |  6 ++--
 gcc/d/decl.cc   | 49 +++--
 gcc/d/modules.cc|  2 +-
 gcc/d/typeinfo.cc   |  2 +-
 gcc/d/types.cc  | 31 +
 gcc/testsuite/gdc.dg/pr90136a.d | 21 ++
 gcc/testsuite/gdc.dg/pr90136b.d | 21 ++
 gcc/testsuite/gdc.dg/pr90136c.d |  9 ++
 11 files changed, 117 insertions(+), 51 deletions(-)
 create mode 100644 gcc/testsuite/gdc.dg/pr90136a.d
 create mode 100644 gcc/testsuite/gdc.dg/pr90136b.d
 create mode 100644 gcc/testsuite/gdc.dg/pr90136c.d

diff --git a/gcc/d/d-attribs.cc b/gcc/d/d-attribs.cc
index bba6f516ea3..69434c639e7 100644
--- a/gcc/d/d-attribs.cc
+++ b/gcc/d/d-attribs.cc
@@ -22,6 +22,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "system.h"
 #include "coretypes.h"
 
+#include "dmd/attrib.h"
 #include "dmd/declaration.h"
 #include "dmd/mtype.h"
 
@@ -234,7 +235,7 @@ uda_attribute_p (const char *name)
`gcc.attribute.Attribute'.  This symbol is internally recognized by the
compiler and maps them to their equivalent GCC attribute.  */
 
-tree
+static tree
 build_attributes (Expressions *eattrs)
 {
   if (!eattrs)
@@ -319,6 +320,30 @@ build_attributes (Expressions *eattrs)
   return attribs;
 }
 
+/* If any GCC attributes are found in the declaration SYM, apply them to the
+   type or decl NODE.  */
+
+void
+apply_user_attributes (Dsymbol *sym, tree node)
+{
+  if (!sym->userAttribDecl)
+{
+  if (DECL_P (node) && DECL_ATTRIBUTES (node) != NULL)
+   decl_attributes (, DECL_ATTRIBUTES (node), 0);
+
+  return;
+}
+
+  location_t saved_location = input_location;
+  input_location = make_location_t (sym->loc);
+
+  Expressions *attrs = sym->userAttribDecl->getAttributes ();
+  decl_attributes (, build_attributes (attrs),
+  TYPE_P (node) ? ATTR_FLAG_TYPE_IN_PLACE : 0);
+
+  input_location = saved_location;
+}
+
 /* Built-in attribute handlers.  */
 
 /* Handle a "noreturn" attribute; arguments as in
diff --git a/gcc/d/d-tree.h b/gcc/d/d-tree.h
index 0f831c754c0..89feb9e7010 100644
--- a/gcc/d/d-tree.h
+++ b/gcc/d/d-tree.h
@@ -29,7 +29,6 @@ class FuncDeclaration;
 class StructDeclaration;
 class TypeInfoDeclaration;
 class VarDeclaration;
-class UserAttributeDeclaration;
 class Expression;
 class ClassReferenceExp;
 class Module;
@@ -485,7 +484,7 @@ extern bool doing_semantic_analysis_p;
 /* In d-attribs.c.  */
 extern tree insert_type_attribute (tree, const char *, tree = NULL_TREE);
 extern tree insert_decl_attribute (tree, const char *, tree = NULL_TREE);
-extern tree build_attributes (Expressions *);
+extern void apply_user_attributes (Dsymbol *, tree);
 
 /* In d-builtins.cc.  */
 extern const attribute_spec d_langhook_attribute_table[];
@@ -681,8 +680,7 @@ extern tree make_array_type (Type *, unsigned 
HOST_WIDE_INT);
 extern tree make_struct_type (const char *, int n, ...);
 extern tree insert_type_modifiers (tree, unsigned);
 extern void insert_aggregate_field (tree, tree, size_t);
-extern void finish_aggregate_type (unsigned, unsigned, tree,
-  UserAttributeDeclaration *);
+extern void finish_aggregate_type (unsigned, unsigned, tree);
 extern tree build_ctype 

[committed] d: Add always_inline to the internal attribute table.

[Iain Buclaw via Gcc-patches]

Hi,

This patch adds always_inline to the d_langhook_common_attribute_table.
The attribute is not directly accessible from user code, rather it is
indirectly added from the @forceinline attribute.  Even so, a handler
should be present for it to prevent false positive warnings.

Said warnings are not something that could happen currently, but will
become a problem from fixing PR90136 later.

Bootstrapped and tested on x86_linux-gnu.  Committed to mainline.

Regards
Iain
---

gcc/d/ChangeLog:

* d-attribs.cc (d_langhook_common_attribute_table): Add always_inline.
(handle_always_inline_attribute): New function.

---
 gcc/d/d-attribs.cc | 16 
 1 file changed, 16 insertions(+)

diff --git a/gcc/d/d-attribs.cc b/gcc/d/d-attribs.cc
index c3b80ed5b9d..bba6f516ea3 100644
--- a/gcc/d/d-attribs.cc
+++ b/gcc/d/d-attribs.cc
@@ -52,6 +52,7 @@ static tree handle_type_generic_attribute (tree *, tree, 
tree, int, bool *);
 static tree handle_transaction_pure_attribute (tree *, tree, tree, int, bool 
*);
 static tree handle_returns_twice_attribute (tree *, tree, tree, int, bool *);
 static tree handle_fnspec_attribute (tree *, tree, tree, int, bool *);
+static tree handle_always_inline_attribute (tree *, tree, tree, int, bool *);
 
 /* D attribute handlers for user defined attributes.  */
 static tree d_handle_noinline_attribute (tree *, tree, tree, int, bool *);
@@ -137,6 +138,8 @@ const attribute_spec d_langhook_common_attribute_table[] =
 handle_type_generic_attribute, NULL),
   ATTR_SPEC ("fn spec", 1, 1, false, true, true, false,
 handle_fnspec_attribute, NULL),
+  ATTR_SPEC ("always_inline", 0, 0, true,  false, false, false,
+handle_always_inline_attribute, NULL),
   ATTR_SPEC (NULL, 0, 0, false, false, false, false, NULL, NULL),
 };
 
@@ -565,6 +568,19 @@ handle_fnspec_attribute (tree *node ATTRIBUTE_UNUSED, tree 
ARG_UNUSED (name),
   return NULL_TREE;
 }
 
+/* Handle a "always_inline" attribute; arguments as in
+   struct attribute_spec.handler.  */
+
+static tree
+handle_always_inline_attribute (tree *node, tree ARG_UNUSED (name),
+   tree ARG_UNUSED (args), int ARG_UNUSED (flags),
+   bool *no_add_attrs ATTRIBUTE_UNUSED)
+{
+  gcc_assert (TREE_CODE (*node) == FUNCTION_DECL);
+
+  return NULL_TREE;
+}
+
 /* Language specific attribute handlers.  */
 
 /* Handle a "noinline" attribute.  */
-- 
2.20.1

Re: [PATCH v3 2/4] libffi/test: Fix compilation for build sysroot

[Maciej W. Rozycki via Gcc-patches]

On Mon, 30 Mar 2020, Mike Stump wrote:

> > I have actually considered extracting the bits already, but I hesitated 
> > putting that forward that as having looked at the part that we require I 
> > have thought it to be very messy:
> 
> Yeah, sometimes it's like that.  I glanced at the work, if you think 
> it's a step forward, I'd support importing it, my take, import from 
> upstream isn't a bad way to go.

 So I looked into it some more and interestingly enough all the commits I 
have listed in the previous message have already been made as of libffi's 
commit c82cc159426d ("Merge pull request #166 from chevah/master") that we 
imported with our commit b1760f7f915a ("Merge libffi to upstream commit 
c82cc159426d8d4402375fa1ae3f045b9cf82e16").

 That merge was extensively discussed starting from: 
, however no 
mention was as to why the local.exp part had been omitted from the merge.  
Perhaps it was considered not necessary for integrating with the GCC tree, 
although I would think that keeping the divergence to the minimum is 
preferable, and it looks to me that our requirements boil down essentially 
to adding multilib support and making some further, minor tweaks to match 
the rest of the tree.  Whereas the diff between the Makefile systems as at 
libffi's commit c82cc159426d and our commit b1760f7f915a looks to me quite 
substantial.

 Perhaps Richard will be able to provide some input here.

> > So I am in favour of retaining the mechanism rather than using my earlier 
> > proposal, however I'm in two minds as to how to proceed.  Integrating the 
> > change as it is will make us having clutter left in the tree after `make 
> > distclean', but we can do it right away.
> 
> I'd support this.  distclean is one rm -rf away from being clean enough.  
> I'd not let that gate or hold up the import.

 While doing further work on finding a solution that would be acceptable 
(to me anyway), I actually found two further upstream libffi commits:

- commit 6b6df1a7bb37 ("[PATCH] Adds `local.exp` to CLEANFILES"),

- commit 6cf0dea78a5a ("[PATCH] Change CLEANFILES to DISTCLEANFILES"),

both beyond our merge point, that fix this shortcoming.  Still there's no 
Makefile dependency, so if configure.ac is patched or local.exp removed, 
then it is not regenerated, and all that would not be required if what 
automake provides was used.

> If there is work that we want that's more to do with in tree building 
> and testing (sys root fun, multilibs), while not ideal, we can deviate 
> from upstream to support that.  Though, if there is a way to naturally 
> support that, that upstream can accept, that'd be better.

 I did some work now to reduce the divergence and will be posting patch 
series shortly to both upstream libffi and our version.  Hopefully that'll 
be acceptable, at least the initial, minimal change from each series.

 If not, for a reference, here's an updated version of the patch I posted 
last time.  It includes the two upstream libffi commits I have mentioned 
above.

 Let's see how it goes.  Thank you for your input.

  Maciej
---
 libffi/Makefile.am   |3 +++
 libffi/Makefile.in   |4 
 libffi/configure |5 +
 libffi/configure.ac  |5 +
 libffi/testsuite/Makefile.am |2 ++
 libffi/testsuite/Makefile.in |1 +
 6 files changed, 20 insertions(+)

gcc-test-libffi-cc-for-target.diff
Index: gcc/libffi/Makefile.am
===
--- gcc.orig/libffi/Makefile.am
+++ gcc/libffi/Makefile.am
@@ -15,6 +15,9 @@ EXTRA_DIST = LICENSE ChangeLog.v1 Change
libffi.xcodeproj/project.pbxproj\
libtool-ldflags
 
+# local.exp is generated by configure
+DISTCLEANFILES = local.exp
+
 # Automake Documentation:
 # If your package has Texinfo files in many directories, you can use the
 # variable TEXINFO_TEX to tell Automake where to find the canonical
Index: gcc/libffi/Makefile.in
===
--- gcc.orig/libffi/Makefile.in
+++ gcc/libffi/Makefile.in
@@ -454,6 +454,9 @@ EXTRA_DIST = LICENSE ChangeLog.v1 Change
libtool-ldflags
 
 
+# local.exp is generated by configure
+DISTCLEANFILES = local.exp
+
 # Automake Documentation:
 # If your package has Texinfo files in many directories, you can use the
 # variable TEXINFO_TEX to tell Automake where to find the canonical
@@ -1674,6 +1677,7 @@ installcheck: installcheck-recursive
-rm -f src/x86/$(am__dirstamp)
-rm -f src/xtensa/$(DEPDIR)/$(am__dirstamp)
-rm -f src/xtensa/$(am__dirstamp)
+   -test -z "$(DISTCLEANFILES)" || rm -f $(DISTCLEANFILES)
 
 maintainer-clean-generic:
@echo "This command is intended for maintainers to use"
Index: gcc/libffi/configure
===
--- gcc.orig/libffi/configure
+++ 

[PATCH] Fix an error in extend.texi

[Zackery Spytz via Gcc-patches]

diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index e0e7f540c219..f1f2064df459 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -2817,7 +2817,7 @@ the same type as the target function.  As a result of
the @code{copy}
 attribute the alias also shares the same attributes as the target.

 @smallexample
-#define StrongAlias(TagetFunc, AliasDecl)   \
+#define StrongAlias(TargetFunc, AliasDecl)  \
   extern __typeof__ (TargetFunc) AliasDecl  \
 __attribute__ ((alias (#TargetFunc), copy (TargetFunc)));

Re: [PATCH] c++: Fix ICE in tsubst_default_argument [PR92010]

[Patrick Palka via Gcc-patches]

On Tue, 31 Mar 2020, Jason Merrill wrote:

> On 3/30/20 6:46 PM, Patrick Palka wrote:
> > On Mon, 30 Mar 2020, Jason Merrill wrote:
> > > On 3/30/20 3:58 PM, Patrick Palka wrote:
> > > > On Thu, 26 Mar 2020, Jason Merrill wrote:
> > > > 
> > > > > On 3/22/20 9:21 PM, Patrick Palka wrote:
> > > > > > This patch relaxes an assertion in tsubst_default_argument that
> > > > > > exposes
> > > > > > a
> > > > > > latent
> > > > > > bug in how we substitute an array type into a cv-qualified wildcard
> > > > > > function
> > > > > > parameter type.  Concretely, the latent bug is that given the
> > > > > > function
> > > > > > template
> > > > > > 
> > > > > >  template void foo(const T t);
> > > > > > 
> > > > > > one would expect the type of foo to be void(const int*), but
> > > > > > we
> > > > > > (seemingly prematurely) strip function parameter types of their
> > > > > > top-level
> > > > > > cv-qualifiers when building the function's TYPE_ARG_TYPES, and
> > > > > > instead
> > > > > > end
> > > > > > up
> > > > > > obtaining void(int*) as the type of foo after substitution
> > > > > > and
> > > > > > decaying.
> > > > > > 
> > > > > > We still however correctly substitute into and decay the formal
> > > > > > parameter
> > > > > > type,
> > > > > > obtaining const int* as the type of t after substitution.  But this
> > > > > > then
> > > > > > leads
> > > > > > to us tripping over the assert in tsubst_default_argument that
> > > > > > verifies
> > > > > > the
> > > > > > formal parameter type and the function type are consistent.
> > > > > > 
> > > > > > Assuming it's too late at this stage to fix the substitution bug, we
> > > > > > can
> > > > > > still
> > > > > > relax the assertion like so.  Tested on x86_64-pc-linux-gnu, does
> > > > > > this
> > > > > > look
> > > > > > OK?
> > > > > 
> > > > > This is core issues 1001/1322, which have not been resolved.  Clang
> > > > > does
> > > > > the
> > > > > substitution the way you suggest; EDG rejects the testcase because the
> > > > > two
> > > > > substitutions produce different results.  I think it would make sense
> > > > > to
> > > > > follow the EDG behavior until this issue is actually resolved.
> > > > 
> > > > Here is what I have so far towards that end.  When substituting into the
> > > > PARM_DECLs of a function decl, we now additionally check if the
> > > > aforementioned Core issues are relevant and issue a (fatal) diagnostic
> > > > if so.  This patch checks this in tsubst_decl  rather
> > > > than in tsubst_function_decl for efficiency reasons, so that we don't
> > > > have to perform another traversal over the DECL_ARGUMENTS /
> > > > TYPE_ARG_TYPES just to implement this check.
> > > 
> > > Hmm, this seems like writing more complicated code for a very marginal
> > > optimization; how many function templates have so many parameters that
> > > walking
> > > over them once to compare types will have any effect on compile time?
> > 
> > Good point... though I just tried implementing this check in
> > tsubst_function_decl, and it seems it might be just as complicated to
> > implement it there instead, at least if we want to handle function
> > parameter packs correctly.
> > 
> > If we were to implement this check in tsubst_function_decl, then since
> > we have access to the instantiated function, it would presumably suffice
> > to compare its substituted DECL_ARGUMENTS with its substituted
> > TYPE_ARG_TYPES to see if they're consistent.  Doing so would certainly
> > catch the original testcase, i.e.
> > 
> >template
> >  void foo(const T);
> >int main() { foo(0); }
> > 
> > because the DECL_ARGUMENTS of foo would be {const int*} and its
> > TYPE_ARG_TYPES would be {int*}.  But apparently it doesn't catch the
> > corresponding testcase that uses a function parameter pack, i.e.
> > 
> >template
> >  void foo(const Ts...);
> >int main() { foo(0); }
> > 
> > because it turns out we don't strip top-level cv-qualifiers from
> > function parameter packs from TYPE_ARG_TYPES at declaration time, as we
> > do with regular function parameters.  So in this second testcase both
> > DECL_ARGUMENTS and TYPE_ARG_TYPES of foo would be {const int*},
> > and yet we would (presumably) want to reject this instantiation too.
> > 
> > So it seems comparing TYPE_ARG_TYPES and DECL_ARGUMENTS from
> > tsubst_function_decl would not suffice, and we would still need to do a
> > variant of the trick that's done in this patch, i.e. substitute into
> > each dependent parameter type stripped of its top-level cv-qualifiers,
> > to see if these cv-qualifiers make a material difference in the
> > resulting function type.  Or maybe there's yet another way to detect
> > this?
> 
> I think let's go ahead with comparing TYPE_ARG_TYPES and DECL_ARGUMENTS; the
> problem comes when they disagree.  If we're handling pack expansions wrong,
> that's a separate issue.

Hm, comparing TYPE_ARG_TYPES and DECL_ARGUMENTS for compatibility seems
to be exposing a latent 

Re: [PATCH V4][gcc] libgccjit: introduce version entry points

[Andrea Corallo]

David Malcolm  writes:

> On Tue, 2020-03-31 at 14:05 +0200, Andrea Corallo wrote:
>> Hi all,
>> 
>> Updated version of the patch addressing last comments.
>
> Thanks.
>
>> Regression clean, okay to apply?
>
> OK

Committed as 63b2923dc6f5.

Thanks

  Andrea

Re: [PATCH v2 3/9] aarch64: Add cmp_*_carryinC patterns

[Richard Sandiford]

Richard Henderson  writes:
> Duplicate all usub_*_carryinC, but use xzr for the output when we
> only require the flags output.  The signed versions use sign_extend
> instead of zero_extend for combine's benefit.
>
> These will be used shortly for TImode comparisons.
>
>   * config/aarch64/aarch64.md (cmp3_carryinC): New.
>   (*cmp3_carryinC_z1): New.
>   (*cmp3_carryinC_z2): New.
>   (*cmp3_carryinC): New.
> ---
>  gcc/config/aarch64/aarch64.md | 50 +++
>  1 file changed, 50 insertions(+)
>
> diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
> index a996a5f1c39..9b1c3f797f9 100644
> --- a/gcc/config/aarch64/aarch64.md
> +++ b/gcc/config/aarch64/aarch64.md
> @@ -3440,6 +3440,18 @@
> ""
>  )
>  
> +(define_expand "cmp3_carryinC"
> +   [(set (reg:CC CC_REGNUM)
> +  (compare:CC
> +(ANY_EXTEND:
> +  (match_operand:GPI 0 "register_operand"))
> +(plus:
> +  (ANY_EXTEND:
> +(match_operand:GPI 1 "register_operand"))
> +  (ltu: (reg:CC CC_REGNUM) (const_int 0)]
> +   ""
> +)
>  (define_insn "*usub3_carryinC_z1"
>[(set (reg:CC CC_REGNUM)
>   (compare:CC
> @@ -3457,6 +3469,19 @@
>[(set_attr "type" "adc_reg")]
>  )
>  
> +(define_insn "*cmp3_carryinC_z1"
> +  [(set (reg:CC CC_REGNUM)
> + (compare:CC
> +   (const_int 0)
> +   (plus:
> + (ANY_EXTEND:
> +   (match_operand:GPI 0 "register_operand" "r"))
> + (match_operand: 1 "aarch64_borrow_operation" ""]
> +   ""
> +   "sbcs\\tzr, zr, %0"
> +  [(set_attr "type" "adc_reg")]
> +)
> +
>  (define_insn "*usub3_carryinC_z2"
>[(set (reg:CC CC_REGNUM)
>   (compare:CC
> @@ -3472,6 +3497,17 @@
>[(set_attr "type" "adc_reg")]
>  )
>  
> +(define_insn "*cmp3_carryinC_z2"
> +  [(set (reg:CC CC_REGNUM)
> + (compare:CC
> +   (ANY_EXTEND:
> + (match_operand:GPI 0 "register_operand" "r"))
> +   (match_operand: 1 "aarch64_borrow_operation" "")))]
> +   ""
> +   "sbcs\\tzr, %0, zr"
> +  [(set_attr "type" "adc_reg")]
> +)
> +
>  (define_insn "*usub3_carryinC"
>[(set (reg:CC CC_REGNUM)
>   (compare:CC
> @@ -3490,6 +3526,20 @@
>[(set_attr "type" "adc_reg")]
>  )
>  
> +(define_insn "*cmp3_carryinC"
> +  [(set (reg:CC CC_REGNUM)
> + (compare:CC
> +   (ANY_EXTEND:
> + (match_operand:GPI 0 "register_operand" "r"))
> +   (plus:
> + (ANY_EXTEND:
> +   (match_operand:GPI 1 "register_operand" "r"))
> + (match_operand: 2 "aarch64_borrow_operation" ""]
> +   ""
> +   "sbcs\\tzr, %0, %1"
> +  [(set_attr "type" "adc_reg")]
> +)

I guess this feeds into your reply to Segher's comment for 7/9,
but I think:

   (compare:CC X Y)

is always supposed to be the NZCV flags result of X - Y, as computed in
the mode of X and Y.  If so, it seems like the type of extension should
matter.  E.g. the N flag ought to be set for:

  (compare:CC
(sign_extend 0xf...)
(plus (sign_extend 0x7...)
  (ltu ...)))

but ought to be clear for:

  (compare:CC
(zero_extend 0xf...)
(plus (zero_extend 0x7...)
  (ltu ...)))

If so, I guess this is a bug in the existing code...

Thanks,
Richard

Re: [Patch] libgomp – fix handling of 'target enter data'

[Jakub Jelinek via Gcc-patches]

On Tue, Mar 31, 2020 at 07:41:40PM +0200, Tobias Burnus wrote:
> On 3/31/20 5:35 PM, Jakub Jelinek via Gcc-patches wrote:
> 
> > Doing the mappings separately is intentional, while for target data or
> > target region mappings it is very likely they will be all released together
> > as well, so it doesn't matter if they all go from the single same mapping,
> > for target enter data it is often not the case.
> > If everything is mapped together, then it can't be really freed until all
> > the mappings get refcount of 0.
> > So, instead of the change you've posted, there should be in
> > GOMP_target_enter_exit_data code to also handle GOMP_MAP_TO_PSET and put the
> > right number of mappings after it in one block and leave the rest separate.
> 
> Done in that way – including adding a rational comment :-)
> 
> OK for mainline?

LGTM, thanks.

> libgomp – fix handling of 'target enter data'
> 
>   * target.c (GOMP_target_enter_exit_data): Handle PSET/MAP_POINTER.
>   * testsuite/libgomp.fortran/target-enter-data-1.f90: New.

Jakub

Re: [PATCH] [ARC] Allow more ABIs in GLIBC_DYNAMIC_LINKER

[Vineet Gupta via Gcc-patches]

Well its a hard requirement considering glibc is still using gcc-9 !

Thx,
-Vineet

On 3/31/20 9:26 AM, Alexey Brodkin wrote:
> Hi Claus,
>
>> -Original Message-
>> From: linux-snps-arc  On Behalf 
>> Of Claudiu Zissulescu
>> Ianculescu
>> Sent: Tuesday, March 31, 2020 1:07 PM
>> To: Vineet Gupta 
>> Cc: linux-snps-...@lists.infradead.org; gcc-patches@gcc.gnu.org; Claudiu 
>> Zissulescu
>> 
>> Subject: Re: [PATCH] [ARC] Allow more ABIs in GLIBC_DYNAMIC_LINKER
>>
>> Pushed.
> Is this one eligible for being back-ported to older GCCs?
> At least GCC 9.x would be really good.
>
> -Alexey
>  

Re: [Patch] libgomp – fix handling of 'target enter data'

[Tobias Burnus]

On 3/31/20 5:35 PM, Jakub Jelinek via Gcc-patches wrote:


Doing the mappings separately is intentional, while for target data or
target region mappings it is very likely they will be all released together
as well, so it doesn't matter if they all go from the single same mapping,
for target enter data it is often not the case.
If everything is mapped together, then it can't be really freed until all
the mappings get refcount of 0.
So, instead of the change you've posted, there should be in
GOMP_target_enter_exit_data code to also handle GOMP_MAP_TO_PSET and put the
right number of mappings after it in one block and leave the rest separate.


Done in that way – including adding a rational comment :-)

OK for mainline?

Tobias

-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter
libgomp – fix handling of 'target enter data'

	* target.c (GOMP_target_enter_exit_data): Handle PSET/MAP_POINTER.
	* testsuite/libgomp.fortran/target-enter-data-1.f90: New.

 libgomp/target.c   | 13 +++-
 .../libgomp.fortran/target-enter-data-1.f90| 36 ++
 2 files changed, 48 insertions(+), 1 deletion(-)

diff --git a/libgomp/target.c b/libgomp/target.c
index c99dd5196fa..36425477dcb 100644
--- a/libgomp/target.c
+++ b/libgomp/target.c
@@ -2480,7 +2480,9 @@ GOMP_target_enter_exit_data (int device, size_t mapnum, void **hostaddrs,
 	}
 }
 
-  size_t i;
+  /* The variables are mapped separately such that they can be released
+ independently.  */
+  size_t i, j;
   if ((flags & GOMP_TARGET_FLAG_EXIT_DATA) == 0)
 for (i = 0; i < mapnum; i++)
   if ((kinds[i] & 0xff) == GOMP_MAP_STRUCT)
@@ -2489,6 +2491,15 @@ GOMP_target_enter_exit_data (int device, size_t mapnum, void **hostaddrs,
 			 [i], true, GOMP_MAP_VARS_ENTER_DATA);
 	  i += sizes[i];
 	}
+  else if ((kinds[i] & 0xff) == GOMP_MAP_TO_PSET)
+	{
+	  for (j = i + 1; j < mapnum; j++)
+	if (!GOMP_MAP_POINTER_P (get_kind (true, kinds, j) & 0xff))
+	  break;
+	  gomp_map_vars (devicep, j-i, [i], NULL, [i],
+			 [i], true, GOMP_MAP_VARS_ENTER_DATA);
+	  i += j - i - 1;
+	}
   else
 	gomp_map_vars (devicep, 1, [i], NULL, [i], [i],
 		   true, GOMP_MAP_VARS_ENTER_DATA);
diff --git a/libgomp/testsuite/libgomp.fortran/target-enter-data-1.f90 b/libgomp/testsuite/libgomp.fortran/target-enter-data-1.f90
new file mode 100644
index 000..91dedebf0a0
--- /dev/null
+++ b/libgomp/testsuite/libgomp.fortran/target-enter-data-1.f90
@@ -0,0 +1,36 @@
+program main
+  implicit none
+  integer, allocatable, dimension(:) :: AA, BB, CC, DD
+  integer :: i, N = 20
+
+  allocate(BB(N))
+  AA = [(i, i=1,N)]
+
+  !$omp target enter data map(alloc: BB)
+  !$omp target enter data map(to: AA)
+
+  !$omp target
+BB = 3 * AA
+  !$omp end target
+
+  !$omp target exit data map(delete: AA)
+  !$omp target exit data map(from: BB)
+
+  if (any (BB /= [(3*i, i=1,N)])) stop 1
+  if (any (AA /= [(i, i=1,N)])) stop 2
+
+
+  CC = 31 * BB
+  DD = [(-i, i=1,N)]
+
+  !$omp target enter data map(to: CC) map(alloc: DD)
+
+  !$omp target
+DD = 5 * CC
+  !$omp end target
+
+  !$omp target exit data map(delete: CC) map(from: DD)
+
+  if (any (CC /= [(31*3*i, i=1,N)])) stop 3
+  if (any (DD /= [(31*3*5*i, i=1,N)])) stop 4
+end

Re: [PATCH V4][gcc] libgccjit: introduce version entry points

[David Malcolm via Gcc-patches]

On Tue, 2020-03-31 at 14:05 +0200, Andrea Corallo wrote:
> Hi all,
> 
> Updated version of the patch addressing last comments.

Thanks.

> Regression clean, okay to apply?

OK

> Bests
> 
>   Andrea
> 
> gcc/jit/ChangeLog
> 2020-??-??  Andrea Corallo  
>   David Malcolm  
> 
>   * docs/topics/compatibility.rst (LIBGCCJIT_ABI_13): New ABI tag
>   plus add version paragraph.
>   * libgccjit++.h (namespace gccjit::version): Add new namespace.
>   * libgccjit.c (gcc_jit_version_major, gcc_jit_version_minor)
>   (gcc_jit_version_patchlevel): New functions.
>   * libgccjit.h (LIBGCCJIT_HAVE_gcc_jit_version): New macro.
>   (gcc_jit_version_major, gcc_jit_version_minor)
>   (gcc_jit_version_patchlevel): New functions.
>   * libgccjit.map (LIBGCCJIT_ABI_13) New ABI tag.
> 
> gcc/testsuite/ChangeLog
> 2020-??-??  Andrea Corallo  
> 
>   * jit.dg/test-version.c: New testcase.
>   * jit.dg/all-non-failing-tests.h: Add test-version.c.

Re: [PATCH v2 1/9] aarch64: Accept 0 as first argument to compares

[Richard Henderson via Gcc-patches]

On 3/31/20 9:55 AM, Richard Sandiford wrote:
>>  (define_insn "cmp"
>>[(set (reg:CC CC_REGNUM)
>> -(compare:CC (match_operand:GPI 0 "register_operand" "rk,rk,rk")
>> -(match_operand:GPI 1 "aarch64_plus_operand" "r,I,J")))]
>> +(compare:CC (match_operand:GPI 0 "aarch64_reg_or_zero" "rk,rk,rkZ")
>> +(match_operand:GPI 1 "aarch64_plus_operand" "I,J,rZ")))]
>>""
>>"@
>> -   cmp\\t%0, %1
>> cmp\\t%0, %1
>> -   cmn\\t%0, #%n1"
>> -  [(set_attr "type" "alus_sreg,alus_imm,alus_imm")]
>> +   cmn\\t%0, #%n1
>> +   cmp\\t%0, %1"
>> +  [(set_attr "type" "alus_imm,alus_imm,alus_sreg")]
>>  )
>>  
>>  (define_insn "fcmp"
> 
> ...does adding 'Z' to operand 1 enable any new combinations?

Not useful ones, on reflection, but given it's a valid combination, it's easier
to include it than not.

I can certainly remove that.

r~

Re: [PATCH] c++: Fix ICE in tsubst_default_argument [PR92010]

[Jason Merrill via Gcc-patches]

On 3/30/20 6:46 PM, Patrick Palka wrote:

On Mon, 30 Mar 2020, Jason Merrill wrote:

On 3/30/20 3:58 PM, Patrick Palka wrote:

On Thu, 26 Mar 2020, Jason Merrill wrote:


On 3/22/20 9:21 PM, Patrick Palka wrote:

This patch relaxes an assertion in tsubst_default_argument that exposes
a
latent
bug in how we substitute an array type into a cv-qualified wildcard
function
parameter type.  Concretely, the latent bug is that given the function
template

 template void foo(const T t);

one would expect the type of foo to be void(const int*), but we
(seemingly prematurely) strip function parameter types of their
top-level
cv-qualifiers when building the function's TYPE_ARG_TYPES, and instead
end
up
obtaining void(int*) as the type of foo after substitution and
decaying.

We still however correctly substitute into and decay the formal
parameter
type,
obtaining const int* as the type of t after substitution.  But this then
leads
to us tripping over the assert in tsubst_default_argument that verifies
the
formal parameter type and the function type are consistent.

Assuming it's too late at this stage to fix the substitution bug, we can
still
relax the assertion like so.  Tested on x86_64-pc-linux-gnu, does this
look
OK?


This is core issues 1001/1322, which have not been resolved.  Clang does
the
substitution the way you suggest; EDG rejects the testcase because the two
substitutions produce different results.  I think it would make sense to
follow the EDG behavior until this issue is actually resolved.


Here is what I have so far towards that end.  When substituting into the
PARM_DECLs of a function decl, we now additionally check if the
aforementioned Core issues are relevant and issue a (fatal) diagnostic
if so.  This patch checks this in tsubst_decl  rather
than in tsubst_function_decl for efficiency reasons, so that we don't
have to perform another traversal over the DECL_ARGUMENTS /
TYPE_ARG_TYPES just to implement this check.


Hmm, this seems like writing more complicated code for a very marginal
optimization; how many function templates have so many parameters that walking
over them once to compare types will have any effect on compile time?


Good point... though I just tried implementing this check in
tsubst_function_decl, and it seems it might be just as complicated to
implement it there instead, at least if we want to handle function
parameter packs correctly.

If we were to implement this check in tsubst_function_decl, then since
we have access to the instantiated function, it would presumably suffice
to compare its substituted DECL_ARGUMENTS with its substituted
TYPE_ARG_TYPES to see if they're consistent.  Doing so would certainly
catch the original testcase, i.e.

   template
 void foo(const T);
   int main() { foo(0); }

because the DECL_ARGUMENTS of foo would be {const int*} and its
TYPE_ARG_TYPES would be {int*}.  But apparently it doesn't catch the
corresponding testcase that uses a function parameter pack, i.e.

   template
 void foo(const Ts...);
   int main() { foo(0); }

because it turns out we don't strip top-level cv-qualifiers from
function parameter packs from TYPE_ARG_TYPES at declaration time, as we
do with regular function parameters.  So in this second testcase both
DECL_ARGUMENTS and TYPE_ARG_TYPES of foo would be {const int*},
and yet we would (presumably) want to reject this instantiation too.

So it seems comparing TYPE_ARG_TYPES and DECL_ARGUMENTS from
tsubst_function_decl would not suffice, and we would still need to do a
variant of the trick that's done in this patch, i.e. substitute into
each dependent parameter type stripped of its top-level cv-qualifiers,
to see if these cv-qualifiers make a material difference in the
resulting function type.  Or maybe there's yet another way to detect
this?


I think let's go ahead with comparing TYPE_ARG_TYPES and DECL_ARGUMENTS; 
the problem comes when they disagree.  If we're handling pack expansions 
wrong, that's a separate issue.


Jason

[committed] d: Use memset to fill alignment holes with zeroes.

[Iain Buclaw via Gcc-patches]

Hi,

This patch removes the manual insertion of padding for fields in
constructed struct literals, and instead uses memset() on the
declaration being initialized.

When compiling optimized builds, the intent is usually missed, and
alignment holes end up with non-zero values in them anyway.

Bootstrapped and tested on x86_64-linux-gnu.  Committed to mainline.

Regards
Iain.
---

gcc/d/ChangeLog:

PR d/94424
* d-codegen.cc (build_alignment_field): Remove.
(build_struct_literal): Don't insert alignment padding.
* expr.cc (ExprVisitor::visit (AssignExp *)): Call memset before
assigning struct literals.

gcc/testsuite/ChangeLog:

PR d/94424
* gdc.dg/pr94424.d: New test.

---
 gcc/d/d-codegen.cc | 44 
 gcc/d/expr.cc  | 20 +---
 gcc/testsuite/gdc.dg/pr94424.d | 19 +++
 3 files changed, 36 insertions(+), 47 deletions(-)
 create mode 100644 gcc/testsuite/gdc.dg/pr94424.d

diff --git a/gcc/d/d-codegen.cc b/gcc/d/d-codegen.cc
index 3895a59c224..66af2b4da30 100644
--- a/gcc/d/d-codegen.cc
+++ b/gcc/d/d-codegen.cc
@@ -1076,26 +1076,6 @@ build_array_struct_comparison (tree_code code, 
StructDeclaration *sd,
   return compound_expr (body, result);
 }
 
-/* Create an anonymous field of type ubyte[T] at OFFSET to fill
-   the alignment hole between OFFSET and FIELDPOS.  */
-
-static tree
-build_alignment_field (tree type, HOST_WIDE_INT offset, HOST_WIDE_INT fieldpos)
-{
-  tree atype = make_array_type (Type::tuns8, fieldpos - offset);
-  tree field = create_field_decl (atype, NULL, 1, 1);
-
-  SET_DECL_OFFSET_ALIGN (field, TYPE_ALIGN (atype));
-  DECL_FIELD_OFFSET (field) = size_int (offset);
-  DECL_FIELD_BIT_OFFSET (field) = bitsize_zero_node;
-  DECL_FIELD_CONTEXT (field) = type;
-  DECL_PADDING_P (field) = 1;
-
-  layout_decl (field, 0);
-
-  return field;
-}
-
 /* Build a constructor for a variable of aggregate type TYPE using the
initializer INIT, an ordered flat list of fields and values provided
by the frontend.  The returned constructor should be a value that
@@ -,14 +1091,8 @@ build_struct_literal (tree type, vec *init)
   vec *ve = NULL;
   HOST_WIDE_INT offset = 0;
   bool constant_p = true;
-  bool fillholes = true;
   bool finished = false;
 
-  /* Filling alignment holes this only applies to structs.  */
-  if (TREE_CODE (type) != RECORD_TYPE
-  || CLASS_TYPE_P (type) || TYPE_PACKED (type))
-fillholes = false;
-
   /* Walk through each field, matching our initializer list.  */
   for (tree field = TYPE_FIELDS (type); field; field = DECL_CHAIN (field))
 {
@@ -1163,15 +1137,6 @@ build_struct_literal (tree type, vec *init)
  HOST_WIDE_INT fieldpos = int_byte_position (field);
  gcc_assert (value != NULL_TREE);
 
- /* Insert anonymous fields in the constructor for padding out
-alignment holes in-place between fields.  */
- if (fillholes && offset < fieldpos)
-   {
- tree pfield = build_alignment_field (type, offset, fieldpos);
- tree pvalue = build_zero_cst (TREE_TYPE (pfield));
- CONSTRUCTOR_APPEND_ELT (ve, pfield, pvalue);
-   }
-
  /* Must not initialize fields that overlap.  */
  if (fieldpos < offset)
{
@@ -1214,15 +1179,6 @@ build_struct_literal (tree type, vec *init)
break;
 }
 
-  /* Finally pad out the end of the record.  */
-  if (fillholes && offset < int_size_in_bytes (type))
-{
-  tree pfield = build_alignment_field (type, offset,
-  int_size_in_bytes (type));
-  tree pvalue = build_zero_cst (TREE_TYPE (pfield));
-  CONSTRUCTOR_APPEND_ELT (ve, pfield, pvalue);
-}
-
   /* Ensure that we have consumed all values.  */
   gcc_assert (vec_safe_is_empty (init) || ANON_AGGR_TYPE_P (type));
 
diff --git a/gcc/d/expr.cc b/gcc/d/expr.cc
index fcf9bc5880a..0ed50ee2d9e 100644
--- a/gcc/d/expr.cc
+++ b/gcc/d/expr.cc
@@ -1054,14 +1054,13 @@ public:
tree t1 = build_expr (e->e1);
tree t2 = convert_for_assignment (build_expr (e->e2),
  e->e2->type, e->e1->type);
+   StructDeclaration *sd = ((TypeStruct *) tb1)->sym;
 
/* Look for struct = 0.  */
if (e->e2->op == TOKint64)
  {
/* Use memset to fill struct.  */
gcc_assert (e->op == TOKblit);
-   StructDeclaration *sd = ((TypeStruct *) tb1)->sym;
-
tree tmemset = builtin_decl_explicit (BUILT_IN_MEMSET);
tree result = build_call_expr (tmemset, 3, build_address (t1),
   t2, size_int (sd->structsize));
@@ -1079,7 +1078,22 @@ public:
this->result_ = compound_expr (result, t1);
  }
else
- this->result_ = build_assign (modifycode, t1, t2);
+ {
+   /* Simple struct literal assignment.  */
+ 

Re: [PATCH v2 1/9] aarch64: Accept 0 as first argument to compares

[Richard Sandiford]

Richard Henderson  writes:
> While cmp (extended register) and cmp (immediate) uses ,
> cmp (shifted register) uses .  So we can perform cmp xzr, x0.
>
> For ccmp, we only have  as an input.
>
>   * config/aarch64/aarch64.md (cmp): For operand 0, use
>   aarch64_reg_or_zero.  Shuffle reg/reg to last alternative
>   and accept Z.
>   (@ccmpcc): For operand 0, use aarch64_reg_or_zero and Z.
>   (@ccmpcc_rev): Likewise.

Looks good, but...

> ---
>  gcc/config/aarch64/aarch64.md | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
> index c7c4d1dd519..b9ae51e48dd 100644
> --- a/gcc/config/aarch64/aarch64.md
> +++ b/gcc/config/aarch64/aarch64.md
> @@ -502,7 +502,7 @@
>  [(match_operand 0 "cc_register" "")
>   (const_int 0)])
> (compare:CC_ONLY
> - (match_operand:GPI 2 "register_operand" "r,r,r")
> + (match_operand:GPI 2 "aarch64_reg_or_zero" "rZ,rZ,rZ")
>   (match_operand:GPI 3 "aarch64_ccmp_operand" "r,Uss,Usn"))
> (unspec:CC_ONLY
>   [(match_operand 5 "immediate_operand")]
> @@ -542,7 +542,7 @@
>   [(match_operand 5 "immediate_operand")]
>   UNSPEC_NZCV)
> (compare:CC_ONLY
> - (match_operand:GPI 2 "register_operand" "r,r,r")
> + (match_operand:GPI 2 "aarch64_reg_or_zero" "rZ,rZ,rZ")
>   (match_operand:GPI 3 "aarch64_ccmp_operand" "r,Uss,Usn"]
>""
>"@
> @@ -3961,14 +3961,14 @@
>  
>  (define_insn "cmp"
>[(set (reg:CC CC_REGNUM)
> - (compare:CC (match_operand:GPI 0 "register_operand" "rk,rk,rk")
> - (match_operand:GPI 1 "aarch64_plus_operand" "r,I,J")))]
> + (compare:CC (match_operand:GPI 0 "aarch64_reg_or_zero" "rk,rk,rkZ")
> + (match_operand:GPI 1 "aarch64_plus_operand" "I,J,rZ")))]
>""
>"@
> -   cmp\\t%0, %1
> cmp\\t%0, %1
> -   cmn\\t%0, #%n1"
> -  [(set_attr "type" "alus_sreg,alus_imm,alus_imm")]
> +   cmn\\t%0, #%n1
> +   cmp\\t%0, %1"
> +  [(set_attr "type" "alus_imm,alus_imm,alus_sreg")]
>  )
>  
>  (define_insn "fcmp"

...does adding 'Z' to operand 1 enable any new combinations?
I guess it allows (compare:CC (const_int 0) (const_int 0)),
but it's borderline whether that should be valid rtl.

Richard

RE: [PATCH] [ARC] Allow more ABIs in GLIBC_DYNAMIC_LINKER

[Alexey Brodkin via Gcc-patches]

Hi Claus,

> -Original Message-
> From: linux-snps-arc  On Behalf 
> Of Claudiu Zissulescu
> Ianculescu
> Sent: Tuesday, March 31, 2020 1:07 PM
> To: Vineet Gupta 
> Cc: linux-snps-...@lists.infradead.org; gcc-patches@gcc.gnu.org; Claudiu 
> Zissulescu
> 
> Subject: Re: [PATCH] [ARC] Allow more ABIs in GLIBC_DYNAMIC_LINKER
> 
> Pushed.

Is this one eligible for being back-ported to older GCCs?
At least GCC 9.x would be really good.

-Alexey
 

[GCC][PATCH][ARM]: Fix for MVE ACLE intrinsics with writeback (PR94317).

[Srinath Parvathaneni]

Hello,

Following MVE ACLE intrinsics have an issue with writeback to the base address.

vldrdq_gather_base_wb_s64, vldrdq_gather_base_wb_u64, 
vldrdq_gather_base_wb_z_s64,
vldrdq_gather_base_wb_z_u64, vldrwq_gather_base_wb_s32, 
vldrwq_gather_base_wb_u32,
vldrwq_gather_base_wb_z_s32, vldrwq_gather_base_wb_z_u32, 
vldrwq_gather_base_wb_f32,
vldrwq_gather_base_wb_z_f32.

This patch fixes the bug reported in PR94317 by adding separate builtin calls 
to update
the result and writeback to base address for the above intrinsics.

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:

2020-03-31  Srinath Parvathaneni  

PR target/94317
* config/arm/arm-builtins.c (LDRGBWBXU_QUALIFIERS): Define.
(LDRGBWBXU_Z_QUALIFIERS): Likewise.
* config/arm/arm_mve.h (__arm_vldrdq_gather_base_wb_s64): Modify
intrinsic defintion by adding a new builtin call to writeback into base
address.
(__arm_vldrdq_gather_base_wb_u64): Likewise.
(__arm_vldrdq_gather_base_wb_z_s64): Likewise.
(__arm_vldrdq_gather_base_wb_z_u64): Likewise.
(__arm_vldrwq_gather_base_wb_s32): Likewise.
(__arm_vldrwq_gather_base_wb_u32): Likewise.
(__arm_vldrwq_gather_base_wb_z_s32): Likewise.
(__arm_vldrwq_gather_base_wb_z_u32): Likewise.
(__arm_vldrwq_gather_base_wb_f32): Likewise.
(__arm_vldrwq_gather_base_wb_z_f32): Likewise.
* config/arm/arm_mve_builtins.def (vldrwq_gather_base_wb_z_u): Modify
builtin's qualifier.
(vldrdq_gather_base_wb_z_u): Likewise.
(vldrwq_gather_base_wb_u): Likewise.
(vldrdq_gather_base_wb_u): Likewise.
(vldrwq_gather_base_wb_z_s): Likewise.
(vldrwq_gather_base_wb_z_f): Likewise.
(vldrdq_gather_base_wb_z_s): Likewise.
(vldrwq_gather_base_wb_s): Likewise.
(vldrwq_gather_base_wb_f): Likewise.
(vldrdq_gather_base_wb_s): Likewise.
(vldrwq_gather_base_nowb_z_u): Define builtin.
(vldrdq_gather_base_nowb_z_u): Likewise.
(vldrwq_gather_base_nowb_u): Likewise.
(vldrdq_gather_base_nowb_u): Likewise.
(vldrwq_gather_base_nowb_z_s): Likewise.
(vldrwq_gather_base_nowb_z_f): Likewise.
(vldrdq_gather_base_nowb_z_s): Likewise.
(vldrwq_gather_base_nowb_s): Likewise.
(vldrwq_gather_base_nowb_f): Likewise.
(vldrdq_gather_base_nowb_s): Likewise.
* config/arm/mve.md (mve_vldrwq_gather_base_nowb_v4si): Define RTL
pattern.
(mve_vldrwq_gather_base_wb_v4si): Modify RTL pattern.
(mve_vldrwq_gather_base_nowb_z_v4si): Define RTL pattern.
(mve_vldrwq_gather_base_wb_z_v4si): Modify RTL pattern.
(mve_vldrwq_gather_base_wb_fv4sf): Modify RTL pattern.
(mve_vldrwq_gather_base_nowb_fv4sf): Define RTL pattern.
(mve_vldrwq_gather_base_wb_z_fv4sf): Modify RTL pattern.
(mve_vldrwq_gather_base_nowb_z_fv4sf): Define RTL pattern.
(mve_vldrdq_gather_base_nowb_v4di): Define RTL pattern.
(mve_vldrdq_gather_base_wb_v4di):  Modify RTL pattern.
(mve_vldrdq_gather_base_nowb_z_v4di): Define RTL pattern.
(mve_vldrdq_gather_base_wb_z_v4di):  Modify RTL pattern.

gcc/testsuite/ChangeLog:

2020-03-31  Srinath Parvathaneni  

PR target/94317
* gcc.target/arm/mve/intrinsics/vldrdq_gather_base_wb_s64.c: Modify
* gcc.target/arm/mve/intrinsics/vldrdq_gather_base_wb_u64.c: Likewise.
* gcc.target/arm/mve/intrinsics/vldrdq_gather_base_wb_z_s64.c: Likewise.
* gcc.target/arm/mve/intrinsics/vldrdq_gather_base_wb_z_u64.c: Likewise.
* gcc.target/arm/mve/intrinsics/vldrwq_gather_base_wb_f32.c: Likewise.
* gcc.target/arm/mve/intrinsics/vldrwq_gather_base_wb_s32.c: Likewise.
* gcc.target/arm/mve/intrinsics/vldrwq_gather_base_wb_u32.c: Likewise.
* gcc.target/arm/mve/intrinsics/vldrwq_gather_base_wb_z_f32.c: Likewise.
* gcc.target/arm/mve/intrinsics/vldrwq_gather_base_wb_z_s32.c: Likewise.
* gcc.target/arm/mve/intrinsics/vldrwq_gather_base_wb_z_u32.c: Likewise.



### Attachment also inlined for ease of reply###


diff --git a/gcc/config/arm/arm-builtins.c b/gcc/config/arm/arm-builtins.c
index 
56f0db21ea95dcd738877daba27f1cb60f0d5a32..832b9107424fd9a4a0ee272b773b3d0929172370
 100644
--- a/gcc/config/arm/arm-builtins.c
+++ b/gcc/config/arm/arm-builtins.c
@@ -719,6 +719,17 @@ 
arm_quinop_unone_unone_unone_unone_imm_unone_qualifiers[SIMD_MAX_BUILTIN_ARGS]
   (arm_quinop_unone_unone_unone_unone_imm_unone_qualifiers)
 
 static enum arm_type_qualifiers
+arm_ldrgbwbxu_qualifiers[SIMD_MAX_BUILTIN_ARGS]
+  = { qualifier_unsigned, qualifier_unsigned, qualifier_immediate};
+#define 

Re: [AArch64] Backporting -moutline-atomics to gcc 9.x and 8.x

[Pop, Sebastian via Gcc-patches]

Ping, can we have the -moutline-atomics patches committed to the gcc-9 branch?

Thanks,
Sebastian 

On 3/24/20, 7:24 PM, "Pop, Sebastian"  wrote:

Hi Kyrill,

Thanks for pointing out the two missing bug fixes.
Please see attached all the back-ported patches.
All the patches from trunk applied cleanly with no conflicts (except for 
the ChangeLog files) to the gcc-9 branch.
An up to date gcc-9 branch on which I applied the attached patches has 
passed bootstrap on aarch64-linux (Graviton2 with 64 N1 cores) and make check 
with no extra fails.
Kyrill, could you please commit the attached patches to the gcc-9 branch?

As we still don't have a copyright assignment on file, would it be possible 
for ARM to finish the backport to the gcc-8 branch of these patches and the 
atomics cleanup patches mentioned below?

I did a `git log config/aarch64/atomics.md` and there is a follow-up patch 
to the atomics cleanup patches:

commit e21679a8bb17aac603b8704891e60ac502200629
Author: Jakub Jelinek 
Date:   Wed Nov 21 17:41:03 2018 +0100

re PR target/87839 (ICE in final_scan_insn_1, at final.c:3070)

PR target/87839
* config/aarch64/atomics.md (@aarch64_compare_and_swap): 
Use
rIJ constraint for aarch64_plus_operand rather than rn.

* gcc.target/aarch64/pr87839.c: New test.

From-SVN: r266346

That is fixing code modified in this cleanup patch:

commit d400fda3a8c3330f77eb9d51874f5482d3819a9f
Author: Richard Henderson 
Date:   Wed Oct 31 09:42:39 2018 +

aarch64: Improve cas generation


Thanks,
Sebastian


On 3/11/20, 5:11 AM, "Kyrill Tkachov"  wrote:

CAUTION: This email originated from outside of the organization. Do not 
click links or open attachments unless you can confirm the sender and know the 
content is safe.



Hi Sebastian,

On 3/9/20 9:47 PM, Pop, Sebastian wrote:
> Hi,
>
> Please see attached the patches to add -moutline-atomics to the gcc-9 
branch.
> Tested on graviton2 aarch64-linux with bootstrap and
> `make check` passes with no new fails.
> Tested `make check` on glibc built with gcc-9 with and without 
"-moutline-atomics"
> and CFLAGS=" -O2 -g -fno-stack-protector -U_FORTIFY_SOURCE".
>
> Ok to commit to gcc-9 branch?

Since this feature enables backwards-compatible deployment of LSE
atomics, I'd support that.

That is okay with me in principle after GCC 9.3 is released (the branch
is currently frozen).

However, there have been a few follow-up patches to fix some bugs
revealed by testing.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91833

and

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91834

come to mind.

Can you please make sure the fixes for those are included as well?


>
> Does this mechanical `git am *.patch` require a copyright assignment?
> I am still working with my employer on getting the FSF assignment 
signed.
>
> Thanks,
> Sebastian
>
> PS: For gcc-8 backports there are 5 cleanup and improvement patches
> that are needed for -moutline-atomics patches to apply cleanly.
> Should these patches be back-ported in the same time as the flag 
patches,
> or should I update the patches to apply to the older code base?

Hmm... normally I'd be for them. In this case I'd want to make sure that
there aren't any fallout fixes that we're missing.

Did these patches have any bug reports against them?

Thanks,

Kyrill


> Here is the list of the extra patches:
>
>  From 77f33f44baf24c22848197aa80962c003dd7b3e2 Mon Sep 17 00:00:00 
2001
> From: Richard Henderson 
> Date: Wed, 31 Oct 2018 09:29:29 +
> Subject: [PATCH] aarch64: Simplify LSE cas generation
>
> The cas insn is a single insn, and if expanded properly need not
> be split after reload.  Use the proper inputs for the insn.
>
>  * config/aarch64/aarch64.c (aarch64_expand_compare_and_swap):
>  Force oldval into the rval register for TARGET_LSE; emit the 
compare
>  during initial expansion so that it may be deleted if unused.
>  (aarch64_gen_atomic_cas): Remove.
>  * config/aarch64/atomics.md 
(@aarch64_compare_and_swap_lse):
>  Change = to +r for operand 0; use match_dup for operand 2;
>  remove is_weak and mod_f operands as unused.  Drop the split
>  

Re: [Patch] libgomp – fix handling of 'target enter data'

[Jakub Jelinek via Gcc-patches]

On Tue, Mar 31, 2020 at 05:14:17PM +0200, Tobias Burnus wrote:
> gomp_map_vars_internal contains:
> 
>   if ((kind & typemask) == GOMP_MAP_TO_PSET)
> {
>   size_t j;
>   for (j = i + 1; j < mapnum; j++)
> if (!GOMP_MAP_POINTER_P (get_kind (short_mapkind, kinds, j)
> 
> where one accesses not only the i-th hostaddr but items following it.
> 
> On the other hand, in GOMP_target_enter_exit_data one currently has:
> 
> for (i = 0; i < mapnum; i++)
>   if ((kinds[i] & 0xff) == GOMP_MAP_STRUCT) …
>   else
> gomp_map_vars (devicep, 1, [i], NULL, [i], [i],
>true, GOMP_MAP_VARS_ENTER_DATA);
> passing the argument one by one.
> 
> I first thought to pass all non MAP_STRUCT items as block before the
> MAP_STRUCT, then a MAP_STRUCT and then try to group the next items.

Doing the mappings separately is intentional, while for target data or
target region mappings it is very likely they will be all released together
as well, so it doesn't matter if they all go from the single same mapping,
for target enter data it is often not the case.
If everything is mapped together, then it can't be really freed until all
the mappings get refcount of 0.
So, instead of the change you've posted, there should be in
GOMP_target_enter_exit_data code to also handle GOMP_MAP_TO_PSET and put the
right number of mappings after it in one block and leave the rest separate.

Jakub

[Patch] libgomp – fix handling of 'target enter data'

[Tobias Burnus]

gomp_map_vars_internal contains:

  if ((kind & typemask) == GOMP_MAP_TO_PSET)
{
  size_t j;
  for (j = i + 1; j < mapnum; j++)
if (!GOMP_MAP_POINTER_P (get_kind (short_mapkind, kinds, j)

where one accesses not only the i-th hostaddr but items following it.

On the other hand, in GOMP_target_enter_exit_data one currently has:

for (i = 0; i < mapnum; i++)
  if ((kinds[i] & 0xff) == GOMP_MAP_STRUCT) …
  else
gomp_map_vars (devicep, 1, [i], NULL, [i], [i],
   true, GOMP_MAP_VARS_ENTER_DATA);
passing the argument one by one.

I first thought to pass all non MAP_STRUCT items as block before the
MAP_STRUCT, then a MAP_STRUCT and then try to group the next items.

However, I could not find a difference between MAP_STRUCT and not,
hence, I now decided to simply pass the data on "as is".

OK for mainline? (What about older versions?)

Cheers,

Tobias

-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter
libgomp – fix handling of 'target enter data'

	* target.c (GOMP_target_enter_exit_data): Call gomp_map_vars with
	multiples args at once.
	* testsuite/libgomp.fortran/target-enter-data-1.f90: New.

 libgomp/target.c   | 13 ++--
 .../libgomp.fortran/target-enter-data-1.f90| 36 ++
 2 files changed, 38 insertions(+), 11 deletions(-)

diff --git a/libgomp/target.c b/libgomp/target.c
index c99dd5196fa..3de85434f5d 100644
--- a/libgomp/target.c
+++ b/libgomp/target.c
@@ -2480,18 +2480,9 @@ GOMP_target_enter_exit_data (int device, size_t mapnum, void **hostaddrs,
 	}
 }
 
-  size_t i;
   if ((flags & GOMP_TARGET_FLAG_EXIT_DATA) == 0)
-for (i = 0; i < mapnum; i++)
-  if ((kinds[i] & 0xff) == GOMP_MAP_STRUCT)
-	{
-	  gomp_map_vars (devicep, sizes[i] + 1, [i], NULL, [i],
-			 [i], true, GOMP_MAP_VARS_ENTER_DATA);
-	  i += sizes[i];
-	}
-  else
-	gomp_map_vars (devicep, 1, [i], NULL, [i], [i],
-		   true, GOMP_MAP_VARS_ENTER_DATA);
+gomp_map_vars (devicep, mapnum, hostaddrs, NULL, sizes, kinds,
+		   true, GOMP_MAP_VARS_ENTER_DATA);
   else
 gomp_exit_data (devicep, mapnum, hostaddrs, sizes, kinds);
 }
diff --git a/libgomp/testsuite/libgomp.fortran/target-enter-data-1.f90 b/libgomp/testsuite/libgomp.fortran/target-enter-data-1.f90
new file mode 100644
index 000..91dedebf0a0
--- /dev/null
+++ b/libgomp/testsuite/libgomp.fortran/target-enter-data-1.f90
@@ -0,0 +1,36 @@
+program main
+  implicit none
+  integer, allocatable, dimension(:) :: AA, BB, CC, DD
+  integer :: i, N = 20
+
+  allocate(BB(N))
+  AA = [(i, i=1,N)]
+
+  !$omp target enter data map(alloc: BB)
+  !$omp target enter data map(to: AA)
+
+  !$omp target
+BB = 3 * AA
+  !$omp end target
+
+  !$omp target exit data map(delete: AA)
+  !$omp target exit data map(from: BB)
+
+  if (any (BB /= [(3*i, i=1,N)])) stop 1
+  if (any (AA /= [(i, i=1,N)])) stop 2
+
+
+  CC = 31 * BB
+  DD = [(-i, i=1,N)]
+
+  !$omp target enter data map(to: CC) map(alloc: DD)
+
+  !$omp target
+DD = 5 * CC
+  !$omp end target
+
+  !$omp target exit data map(delete: CC) map(from: DD)
+
+  if (any (CC /= [(31*3*i, i=1,N)])) stop 3
+  if (any (DD /= [(31*3*5*i, i=1,N)])) stop 4
+end

[PATCH] x86: Insert ENDBR if function will be called indirectly

[H.J. Lu via Gcc-patches]

Since constant_call_address_operand has

;; Test for a pc-relative call operand
(define_predicate "constant_call_address_operand"
  (match_code "symbol_ref")
{
  if (ix86_cmodel == CM_LARGE || ix86_cmodel == CM_LARGE_PIC
  || flag_force_indirect_call)
return false;
  if (TARGET_DLLIMPORT_DECL_ATTRIBUTES && SYMBOL_REF_DLLIMPORT_P (op))
return false;
  return true;
})

even if cgraph_node::get (cfun->decl)->only_called_directly_p () returns
false, the fuction may still be called indirectly.  Copy the logic from
constant_call_address_operand to rest_of_insert_endbranch to insert ENDBR
at function entry if function will be called indirectly.

gcc/

PR target/94417
* config/i386/i386-features.c (rest_of_insert_endbranch): Insert
ENDBR at function entry if function will be called indirectly.

gcc/testsuite/

PR target/94417
* gcc.target/i386/pr94417-1.c: New test.
* gcc.target/i386/pr94417-2.c: Likewise.
* gcc.target/i386/pr94417-3.c: Likewise.
---
 gcc/config/i386/i386-features.c   |  7 ++-
 gcc/testsuite/gcc.target/i386/pr94417-1.c | 20 
 gcc/testsuite/gcc.target/i386/pr94417-2.c | 21 +
 gcc/testsuite/gcc.target/i386/pr94417-3.c | 19 +++
 4 files changed, 66 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/pr94417-1.c
 create mode 100644 gcc/testsuite/gcc.target/i386/pr94417-2.c
 create mode 100644 gcc/testsuite/gcc.target/i386/pr94417-3.c

diff --git a/gcc/config/i386/i386-features.c b/gcc/config/i386/i386-features.c
index 66b120d21a7..78fb373db6e 100644
--- a/gcc/config/i386/i386-features.c
+++ b/gcc/config/i386/i386-features.c
@@ -1963,7 +1963,12 @@ rest_of_insert_endbranch (void)
   && (!flag_manual_endbr
  || lookup_attribute ("cf_check",
   DECL_ATTRIBUTES (cfun->decl)))
-  && !cgraph_node::get (cfun->decl)->only_called_directly_p ())
+  && (!cgraph_node::get (cfun->decl)->only_called_directly_p ()
+ || ix86_cmodel == CM_LARGE
+ || ix86_cmodel == CM_LARGE_PIC
+ || flag_force_indirect_call
+ || (TARGET_DLLIMPORT_DECL_ATTRIBUTES
+ && DECL_DLLIMPORT_P (cfun->decl
 {
   /* Queue ENDBR insertion to x86_function_profiler.  */
   if (crtl->profile && flag_fentry)
diff --git a/gcc/testsuite/gcc.target/i386/pr94417-1.c 
b/gcc/testsuite/gcc.target/i386/pr94417-1.c
new file mode 100644
index 000..5bbe057fa8f
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr94417-1.c
@@ -0,0 +1,20 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target lp64 } */
+/* { dg-options "-O2 -fcf-protection -mcmodel=large" } */
+/* { dg-final { scan-assembler-times {\mendbr} 2 } } */
+
+extern void ext (void);
+
+__attribute((noclone, noinline))
+static
+void
+foo (void)
+{
+  ext ();
+}
+
+void
+bar (void)
+{
+  foo ();
+}
diff --git a/gcc/testsuite/gcc.target/i386/pr94417-2.c 
b/gcc/testsuite/gcc.target/i386/pr94417-2.c
new file mode 100644
index 000..9eb0f5b2141
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr94417-2.c
@@ -0,0 +1,21 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target lp64 } */
+/* { dg-require-effective-target fpic } */
+/* { dg-options "-O2 -fpic -mcmodel=large -fcf-protection" } */
+/* { dg-final { scan-assembler-times {\mendbr} 2 } } */
+
+extern void ext (void);
+
+__attribute((noclone, noinline))
+static
+void
+foo (void)
+{
+  ext ();
+}
+
+void
+bar (void)
+{
+  foo ();
+}
diff --git a/gcc/testsuite/gcc.target/i386/pr94417-3.c 
b/gcc/testsuite/gcc.target/i386/pr94417-3.c
new file mode 100644
index 000..07c451796c2
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr94417-3.c
@@ -0,0 +1,19 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fcf-protection -mforce-indirect-call" } */
+/* { dg-final { scan-assembler-times {\mendbr} 2 } } */
+
+extern void ext (void);
+
+__attribute((noclone, noinline))
+static
+void
+foo (void)
+{
+  ext ();
+}
+
+void
+bar (void)
+{
+  foo ();
+}
-- 
2.25.1

New Serbian PO file for 'cpplib' (version 10.1-b20200209)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'cpplib' has been submitted
by the Serbian team of translators.  The file is available at:

https://translationproject.org/latest/cpplib/sr.po

(This file, 'cpplib-10.1-b20200209.sr.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

https://translationproject.org/latest/cpplib/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/cpplib.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Contents of PO file 'cpplib-10.1-b20200209.sr.po'

[Translation Project Robot]

cpplib-10.1-b20200209.sr.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.

Re: [PATCH] ICE: in vectorizable_load, at tree-vect-stmts.c:9173

[Richard Sandiford]

"Yangfei (Felix)"  writes:
>> > I think I need a sponsor if this patch can go separately.
>> 
>> Yeah, please fill in the form on:
>> 
>>https://sourceware.org/cgi-bin/pdw/ps_form.cgi
>> 
>> listing me as sponsor.
>
> Hmm, I already have an account : - )  

Oops, yes.  I should have checked, sorry.

> But my networking does not work well and I am having some trouble committing 
> the patch.  
> Could you please help commit this patch?  

OK, pushed to master.

Thanks,
Richard

[[committed]] d: Use d_comdat_linkage on generated internal decl.

[Iain Buclaw via Gcc-patches]

Hi,

This patch adds weak linkage to internal TypeInfo data on top of the
existing DECL_COMDAT, which helps in the unlikely event that two of the
same TypeInfo data ends up in multiple places.

Tested on x86_64-linux-gnu and committed to mainline.

Regards
Iain
---

gcc/d/ChangeLog:

* typeinfo.cc (TypeInfoVisitor::internal_reference): Call
d_comdat_linkage on generated decl.

---
 gcc/d/typeinfo.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/d/typeinfo.cc b/gcc/d/typeinfo.cc
index 07011deaf6f..90a44944f4c 100644
--- a/gcc/d/typeinfo.cc
+++ b/gcc/d/typeinfo.cc
@@ -358,7 +358,7 @@ class TypeInfoVisitor : public Visitor
 DECL_EXTERNAL (decl) = 0;
 TREE_PUBLIC (decl) = 1;
 DECL_VISIBILITY (decl) = VISIBILITY_INTERNAL;
-DECL_COMDAT (decl) = 1;
+d_comdat_linkage (decl);
 d_pushdecl (decl);
 
 return decl;
-- 
2.20.1

[PATCH] PR lto/94249: Correct endianness detection with the __BYTE_ORDER macro

[Maciej W. Rozycki]

Correct an issue with GCC commit 906b3eb9df6c ("Improve endianess 
detection.") and fix a typo in the __BYTE_ORDER fallback macro check 
that causes compilation errors like:

.../include/plugin-api.h:162:2: error: #error "Could not detect architecture 
endianess"

on systems that do not provide the __BYTE_ORDER__ macro.

include/
PR lto/94249
* plugin-api.h: Fix a typo in the __BYTE_ORDER macro check.
---
On Tue, 24 Mar 2020, Martin Liška wrote:

> >> +/* Detect endianess based on _BYTE_ORDER.  */
> >> +#if _BYTE_ORDER == _LITTLE_ENDIAN
> > 
> > So most likely _BYTE_ORDER and _LITTLE_ENDIAN macros will not be defined.
> > Which means this will be handled as #if 0 == 0 and override the
> >> +#define PLUGIN_LITTLE_ENDIAN 1
> > 
> > will define also PLUGIN_LITTLE_ENDIAN.
> 
> Ok, for being sure, I've wrapped all equality comparison with corresponding
> check of the LHS is defined.

 This change, when merged into binutils, caused BFD to fail building in 
one of my configurations:

In file included from .../bfd/elflink.c:31:
.../bfd/../include/plugin-api.h:162:2: error: #error "Could not detect 
architecture endianess"
make[4]: *** [elflink.lo] Error 1

This is due to a missing underscore in the:

#ifdef _BYTE_ORDER

check.

 OK to apply this hopefully obvious fix to GCC and then merge to binutils?

 NB if posting as an attachment please try matching the message subject 
with the change heading as otherwise it takes a lot of effort to track the 
patch submission corresponding to a given commit.

  Maciej
---
 include/plugin-api.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

binutils-include-plugin-api-byte-order.diff
Index: binutils/include/plugin-api.h
===
--- binutils.orig/include/plugin-api.h
+++ binutils/include/plugin-api.h
@@ -51,7 +51,7 @@
 /* Older GCC releases (<4.6.0) can make detection from glibc macros.  */
 #if defined(__GLIBC__) || defined(__GNU_LIBRARY__) || defined(__ANDROID__)
 #include 
-#ifdef _BYTE_ORDER
+#ifdef __BYTE_ORDER
 #if __BYTE_ORDER == __LITTLE_ENDIAN
 #define PLUGIN_LITTLE_ENDIAN 1
 #elif __BYTE_ORDER == __BIG_ENDIAN

[committed] amdgcn: generalize vector insn modes

[Andrew Stubbs]

This is a somewhat large patch that does nothing. :-)

The output mddump file has only whitespace changes, plus a few constant 
64's replaced by GET_MODE_NUNITS that always evaluate to 64.


The point is that I can add more vector modes, in a future patch, 
without also making all these mechanical substitutions.


Andrew
amdgcn: generalize vector insn modes

Replace all relevant explicit uses of V64 vectors with an iterator (albeit
with only one entry).  This is prerequisite to adding extra vector lengths.

The changes are purely mechanical: comparing the mddump files from before
and after shows only white-space differences and the use of GET_MODE_NUNITS.

2020-03-31  Andrew Stubbs  

	gcc/
	* config/gcn/gcn-valu.md (V_QI, V_HI, V_HF, V_SI, V_SF, V_DI, V_DF):
	New mode iterators.
	(vnsi, VnSI, vndi, VnDI): New mode attributes.
	(mov): Use  in place of V64DI.
	(mov_exec): Likewise.
	(mov_sgprbase): Likewise.
	(reload_out): Likewise.
	(*vec_set_1): Use GET_MODE_NUNITS instead of constant 64.
	(gather_loadv64si): Rename to ...
	(gather_load): ... this, and use  in place of V64SI,
	and  in place of V64DI.
	(gather_insn_1offset): Use  in place of V64DI.
	(gather_insn_1offset_ds): Use  in place of V64SI.
	(gather_insn_2offsets): Use  and .
	(scatter_storev64si): Rename to ...
	(scatter_store): ... this, and use  and .
	(scatter_expr): Use  and .
	(scatter_insn_1offset): Likewise.
	(scatter_insn_1offset_ds): Likewise.
	(scatter_insn_2offsets): Likewise.
	(ds_bpermute): Use .
	(addv64si3_vcc): Rename to ...
	(add3_vcc): ... this, and use V_SI.
	(addv64si3_vcc_dup): Rename to ...
	(add3_vcc_dup): ... this, and use V_SI.
	(addcv64si3): Rename to ...
	(addc3): ... this, and use V_SI.
	(subv64si3_vcc): Rename to ...
	(sub3_vcc): ... this, and use V_SI.
	(subcv64si3): Rename to ...
	(subc3): ... this, and use V_SI.
	(addv64di3): Rename to ...
	(add3): ... this, and use V_DI.
	(addv64di3_exec): Rename to ...
	(add3_exec): ... this, and use V_DI.
	(subv64di3): Rename to ...
	(sub3): ... this, and use V_DI.
	(subv64di3_exec): Rename to ...
	(sub3_exec): ... this, and use V_DI.
	(addv64di3_zext): Rename to ...
	(add3_zext): ... this, and use V_DI and .
	(addv64di3_zext_exec): Rename to ...
	(add3_zext_exec): ... this, and use V_DI and .
	(addv64di3_zext_dup): Rename to ...
	(add3_zext_dup): ... this, and use V_DI and .
	(addv64di3_zext_dup_exec): Rename to ...
	(add3_zext_dup_exec): ... this, and use V_DI and .
	(addv64di3_zext_dup2): Rename to ...
	(add3_zext_dup2): ... this, and use V_DI and .
	(addv64di3_zext_dup2_exec): Rename to ...
	(add3_zext_dup2_exec): ... this, and use V_DI and .
	(addv64di3_sext_dup2): Rename to ...
	(add3_sext_dup2): ... this, and use V_DI and .
	(addv64di3_sext_dup2_exec): Rename to ...
	(add3_sext_dup2_exec): ... this, and use V_DI and .
	(mulv64si3_highpart): Rename to ...
	(mul3_highpart): ... this and use V_SI and .
	(mulv64di3): Rename to ...
	(mul3): ... this, and use V_DI and .
	(mulv64di3_exec): Rename to ...
	(mul3_exec): ... this, and use V_DI and .
	(mulv64di3_zext): Rename to ...
	(mul3_zext): ... this, and use V_DI and .
	(mulv64di3_zext_exec): Rename to ...
	(mul3_zext_exec): ... this, and use V_DI and .
	(mulv64di3_zext_dup2): Rename to ...
	(mul3_zext_dup2): ... this, and use V_DI and .
	(mulv64di3_zext_dup2_exec): Rename to ...
	(mul3_zext_dup2_exec): ... this, and use V_DI and .
	(v64di3): Rename to ...
	(3): ... this, and use V_DI and .
	(v64di3_exec): Rename to ...
	(3_exec): ... this, and use V_DI and .
	(v64si3): Rename to ...
	(3): ... this, and use V_SI and .
	(vv64si3): Rename to ...
	(v3): ... this, and use V_SI and .
	(v64si3): Rename to ...
	(3): ... this, and use V_SI.
	(subv64df3): Rename to ...
	(sub3): ... this, and use V_DF.
	(truncv64di2): Rename to ...
	(trunc2): ... this, and use .
	(truncv64di2_exec): Rename to ...
	(trunc2_exec): ... this, and use .
	(v64di2): Rename to ...
	(2): ... this, and use .
	(v64di2_exec): Rename to ...
	(2_exec): ... this, and use .
	(vec_cmpv64qidi): Rename to ...
	(vec_cmpdi): ... this, and use .
	(vec_cmpv64qidi_exec): Rename to ...
	(vec_cmpdi_exec): ... this, and use .
	(vcond_mask_di): Use .
	(maskloaddi): Likewise.
	(maskstoredi): Likewise.
	(mask_gather_loadv64si): Rename to ...
	(mask_gather_load): ... this, and use  and .
	(mask_scatter_storev64si): Rename to ...
	(mask_scatter_store): ... this, and use  and .
	(*_dpp_shr_v64di): Rename to ...
	(*_dpp_shr_): ... this, and use V_DI and .
	(*plus_carry_in_dpp_shr_v64si): Rename to ...
	(*plus_carry_in_dpp_shr_): ... this, and use V_SI.
	(*plus_carry_dpp_shr_v64di): Rename to ...
	(*plus_carry_dpp_shr_): ... this, and use V_DI and .
	(vec_seriesv64si): Rename to ...
	(vec_series): ... this, and use V_SI.
	(vec_seriesv64di): Rename to ...
	(vec_series): ... this, and use V_DI.

diff --git a/gcc/config/gcn/gcn-valu.md b/gcc/config/gcn/gcn-valu.md
index 475d2d4e61e..24843a0b43e 100644
--- a/gcc/config/gcn/gcn-valu.md
+++ b/gcc/config/gcn/gcn-valu.md
@@ -16,6 +16,23 @@
 
 ;; 

Re: [PATCH] Check DECL_CONTEXT of new/delete operators.

[Martin Liška]

On 3/31/20 2:29 PM, Jan Hubicka wrote:

Well, I basically went through all pointers and tried to get rid of as
many of them as possible.  CONTEXT pointers do increase size of SCCs
that increases chance they will not get merged and also processing time
of merging algorithm.  I guess if we need to stream more contexts we
could do that (and check the effect on merging and average SCC size)


Ok, do we want to stream contexts just for the new/delete operators?
Can you please prepare a streaming patch?

Thank you,
Martin

Re: [PATCH] Check DECL_CONTEXT of new/delete operators.

[Jan Hubicka]

> On Mon, Mar 30, 2020 at 10:41 AM Martin Liška  wrote:
> >
> > Hi.
> >
> > The patch ensures that a deleted new/delete pair has a same context.
> > That will fix the issue presented in the PR.
> >
> > Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> 
> I think this will break the DCE with LTO since we strip quite some
> DECL_CONTEXT in free-lang-data.
> 
> Honza - do you remember why we strip DECL_CONTEXT for methods
> which will most likely keep their containing record types live through
> their this
> arguments?  Quoting:
> 
>   /* We need to keep field decls associated with their trees. Otherwise tree
>  merging may merge some fileds and keep others disjoint wich in turn will
>  not do well with TREE_CHAIN pointers linking them.
> 
>  Also do not drop containing types for virtual methods and tables because
>  these are needed by devirtualization.
>  C++ destructors are special because C++ frontends sometimes produces
>  virtual destructor as an alias of non-virtual destructor.  In
>  devirutalization code we always walk through aliases and we need
>  context to be preserved too.  See PR89335  */
>   if (TREE_CODE (decl) != FIELD_DECL
>   && ((TREE_CODE (decl) != VAR_DECL && TREE_CODE (decl) != FUNCTION_DECL)
>   || (!DECL_VIRTUAL_P (decl)
>   && (TREE_CODE (decl) != FUNCTION_DECL
>   || !DECL_CXX_DESTRUCTOR_P (decl)
> DECL_CONTEXT (decl) = fld_decl_context (DECL_CONTEXT (decl));
> 
> and fld_decl_context stripping up to the next non-TYPE context (unless VLA).

Well, I basically went through all pointers and tried to get rid of as
many of them as possible.  CONTEXT pointers do increase size of SCCs
that increases chance they will not get merged and also processing time
of merging algorithm.  I guess if we need to stream more contexts we
could do that (and check the effect on merging and average SCC size)

Honza
> 
> Richard.
> 
> > Ready to be installed?
> > Thanks,
> > Martin
> >
> > gcc/ChangeLog:
> >
> > 2020-03-30  Martin Liska  
> >
> > PR c++/94314
> > * tree-ssa-dce.c (propagate_necessity): Verify that
> > DECL_CONTEXT of a new/delete operators do match.
> >
> > gcc/testsuite/ChangeLog:
> >
> > 2020-03-30  Martin Liska  
> >
> > PR c++/94314
> > * g++.dg/pr94314.C: New test.
> > ---
> >   gcc/testsuite/g++.dg/pr94314.C | 84 ++
> >   gcc/tree-ssa-dce.c | 31 +
> >   2 files changed, 105 insertions(+), 10 deletions(-)
> >   create mode 100644 gcc/testsuite/g++.dg/pr94314.C
> >
> >

[PATCH][committed] arc: Update operand printing

[Claudiu Zissulescu via Gcc-patches]

Use HOST_WIDE_INT_PRINT_DEC macro instead of %ld for format printing.

Committed as obvious.

gcc/
-xx-xx  Claudiu Zissulescu  

* config/arc/arc.c (arc_print_operand): Use
HOST_WIDE_INT_PRINT_DEC macro.
---
 gcc/ChangeLog| 5 +
 gcc/config/arc/arc.c | 6 +++---
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 9da7a4a76b7..3d4e798a2f1 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+2020-03-31  Claudiu Zissulescu  
+
+   * config/arc/arc.c (arc_print_operand): Use
+   HOST_WIDE_INT_PRINT_DEC macro.
+
 2020-03-31  Claudiu Zissulescu  
 
* config/arc/arc.h (ASM_FORMAT_PRIVATE_NAME): Fix it.
diff --git a/gcc/config/arc/arc.c b/gcc/config/arc/arc.c
index 922ccc5c9f9..6b96c5e4bf5 100644
--- a/gcc/config/arc/arc.c
+++ b/gcc/config/arc/arc.c
@@ -4530,7 +4530,7 @@ arc_print_operand (FILE *file, rtx x, int code)
 
 case 'c':
   if (GET_CODE (x) == CONST_INT)
-fprintf (file, "%ld", INTVAL (x) );
+fprintf (file, HOST_WIDE_INT_PRINT_DEC, INTVAL (x) );
   else
 output_operand_lossage ("invalid operands to %%c code");
 
@@ -4724,7 +4724,7 @@ arc_print_operand (FILE *file, rtx x, int code)
  /* No special treatment for jli_fixed functions.  */
  if (code == 'j')
break;
- fprintf (file, "%ld\t; @",
+ fprintf (file, HOST_WIDE_INT_PRINT_DEC "\t; @",
   TREE_INT_CST_LOW (TREE_VALUE (TREE_VALUE (attrs;
  assemble_name (file, XSTR (x, 0));
  return;
@@ -4745,7 +4745,7 @@ arc_print_operand (FILE *file, rtx x, int code)
  tree attrs = (TREE_TYPE (SYMBOL_REF_DECL (x)) != error_mark_node
? TYPE_ATTRIBUTES (TREE_TYPE (SYMBOL_REF_DECL (x)))
: NULL_TREE);
- fprintf (file, "%ld\t; @",
+ fprintf (file, HOST_WIDE_INT_PRINT_DEC "\t; @",
   TREE_INT_CST_LOW (TREE_VALUE (TREE_VALUE (attrs;
  assemble_name (file, XSTR (x, 0));
  return;
-- 
2.24.1

[PATCH V4][gcc] libgccjit: introduce version entry points

[Andrea Corallo]

Hi all,

Updated version of the patch addressing last comments.

Regression clean, okay to apply?

Bests

  Andrea

gcc/jit/ChangeLog
2020-??-??  Andrea Corallo  
David Malcolm  

* docs/topics/compatibility.rst (LIBGCCJIT_ABI_13): New ABI tag
plus add version paragraph.
* libgccjit++.h (namespace gccjit::version): Add new namespace.
* libgccjit.c (gcc_jit_version_major, gcc_jit_version_minor)
(gcc_jit_version_patchlevel): New functions.
* libgccjit.h (LIBGCCJIT_HAVE_gcc_jit_version): New macro.
(gcc_jit_version_major, gcc_jit_version_minor)
(gcc_jit_version_patchlevel): New functions.
* libgccjit.map (LIBGCCJIT_ABI_13) New ABI tag.

gcc/testsuite/ChangeLog
2020-??-??  Andrea Corallo  

* jit.dg/test-version.c: New testcase.
* jit.dg/all-non-failing-tests.h: Add test-version.c.
>From 181082c1dfc02521f3f1b44c058af26b0884614a Mon Sep 17 00:00:00 2001
From: AndreaCorallo 
Date: Sun, 8 Mar 2020 13:46:33 +
Subject: [PATCH] Add new version entry point

---
 gcc/jit/docs/topics/compatibility.rst| 33 ++
 gcc/jit/libgccjit++.h| 22 ++
 gcc/jit/libgccjit.c  | 46 
 gcc/jit/libgccjit.h  | 16 +++
 gcc/jit/libgccjit.map|  9 +++-
 gcc/testsuite/jit.dg/all-non-failing-tests.h | 10 +
 gcc/testsuite/jit.dg/test-version.c  | 26 +++
 7 files changed, 161 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/jit.dg/test-version.c

diff --git a/gcc/jit/docs/topics/compatibility.rst b/gcc/jit/docs/topics/compatibility.rst
index a6faee0810e..0c0ce070d72 100644
--- a/gcc/jit/docs/topics/compatibility.rst
+++ b/gcc/jit/docs/topics/compatibility.rst
@@ -61,6 +61,28 @@ You can see the symbol tags provided by libgccjit.so using ``objdump``:
LIBGCCJIT_ABI_0
[...snip...]
 
+Programmatically checking version
+***
+
+Client code can programmatically check libgccjit version using:
+
+.. function::  int gcc_jit_version_major (void)
+
+   Return libgccjit major version.  This is analogous to __GNUC__ in C code.
+
+.. function::  int gcc_jit_version_minor (void)
+
+   Return libgccjit minor version.  This is analogous to
+   __GNUC_MINOR__ in C code.
+
+.. function::  int gcc_jit_version_patchlevel (void)
+
+   Return libgccjit patchlevel version.  This is analogous to
+   __GNUC_PATCHLEVEL__ in C code.
+
+.. note:: These entry points has been added with ``LIBGCCJIT_ABI_13``
+  (see below).
+
 ABI symbol tags
 ***
 
@@ -182,3 +204,14 @@ entrypoints:
 
 ``LIBGCCJIT_ABI_12`` covers the addition of
 :func:`gcc_jit_context_new_bitfield`
+
+``LIBGCCJIT_ABI_13``
+
+``LIBGCCJIT_ABI_13`` covers the addition of version functions via API
+entrypoints:
+
+  * :func:`gcc_jit_version_major`
+
+  * :func:`gcc_jit_version_minor`
+
+  * :func:`gcc_jit_version_patchlevel`
diff --git a/gcc/jit/libgccjit++.h b/gcc/jit/libgccjit++.h
index 82a62d614c5..69e67766640 100644
--- a/gcc/jit/libgccjit++.h
+++ b/gcc/jit/libgccjit++.h
@@ -49,6 +49,8 @@ namespace gccjit
   class timer;
   class auto_time;
 
+  namespace version {};
+
   /* Errors within the API become C++ exceptions of this class.  */
   class error
   {
@@ -1913,6 +1915,26 @@ auto_time::~auto_time ()
   m_timer.pop (m_item_name);
 }
 
+namespace version
+{
+inline int
+major_v ()
+{
+  return gcc_jit_version_major ();
+}
+
+inline int
+minor_v ()
+{
+  return gcc_jit_version_minor ();
+}
+
+inline int
+patchlevel_v ()
+{
+  return gcc_jit_version_patchlevel ();
+}
+} // namespace version
 } // namespace gccjit
 
 #endif /* #ifndef LIBGCCJIT_PLUS_PLUS_H */
diff --git a/gcc/jit/libgccjit.h b/gcc/jit/libgccjit.h
index 21a0dc09b03..1c5a12e9c01 100644
--- a/gcc/jit/libgccjit.h
+++ b/gcc/jit/libgccjit.h
@@ -1487,6 +1487,22 @@ gcc_jit_context_new_rvalue_from_vector (gcc_jit_context *ctxt,
 	size_t num_elements,
 	gcc_jit_rvalue **elements);
 
+#define LIBGCCJIT_HAVE_gcc_jit_version
+
+/* Functions to retrive libgccjit version.
+   Analogous to __GNUC__, __GNUC_MINOR__, __GNUC_PATCHLEVEL__ in C code.
+
+   These API entrypoints were added in LIBGCCJIT_ABI_13; you can test for their
+   presence using
+ #ifdef LIBGCCJIT_HAVE_gcc_jit_version
+ */
+extern int
+gcc_jit_version_major (void);
+extern int
+gcc_jit_version_minor (void);
+extern int
+gcc_jit_version_patchlevel (void);
+
 #ifdef __cplusplus
 }
 #endif /* __cplusplus */
diff --git a/gcc/jit/libgccjit.c b/gcc/jit/libgccjit.c
index 83055fc297b..a29e9885e59 100644
--- a/gcc/jit/libgccjit.c
+++ b/gcc/jit/libgccjit.c
@@ -23,6 +23,8 @@ along with GCC; see the file COPYING3.  If not see
 #include "coretypes.h"
 #include "timevar.h"
 #include "typed-splay-tree.h"
+#include "cppbuiltin.h"
+#include 
 
 #include "libgccjit.h"
 #include "jit-recording.h"
@@ -3175,3 +3177,47 @@ 

[PATCH][committed] arc: Cleanup compilation warning

[Claudiu Zissulescu via Gcc-patches]

Committed as obvious.

gcc/
-xx-xx  Claudiu Zissulescu  

* config/arc/arc.h (ASM_FORMAT_PRIVATE_NAME): Fix it.
---
 gcc/ChangeLog| 6 +-
 gcc/config/arc/arc.h | 6 +++---
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 928c7939925..9da7a4a76b7 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,10 +1,14 @@
+2020-03-31  Claudiu Zissulescu  
+
+   * config/arc/arc.h (ASM_FORMAT_PRIVATE_NAME): Fix it.
+
 2020-03-31  Srinath Parvathaneni  
 
* config/arm/arm_mve.h (vbicq): Define MVE intrinsic polymorphic
variant.
(__arm_vbicq): Likewise.
 
-2020-0-31  Vineet Gupta 
+2020-03-31  Vineet Gupta 
 
* config/arc/linux.h: GLIBC_DYNAMIC_LINKER support BE/arc700.
 
diff --git a/gcc/config/arc/arc.h b/gcc/config/arc/arc.h
index be1d5cb21e7..fd6e21adfaa 100644
--- a/gcc/config/arc/arc.h
+++ b/gcc/config/arc/arc.h
@@ -1136,9 +1136,9 @@ do {  
\
 /* Store in OUTPUT a string (made with alloca) containing
an assembler-name for a local static variable named NAME.
LABELNO is an integer which is different for each call.  */
-#define ASM_FORMAT_PRIVATE_NAME(OUTPUT, NAME, LABELNO) \
-( (OUTPUT) = (char *) alloca (strlen ((NAME)) + 10),   \
-  sprintf ((OUTPUT), "%s.%d", (NAME), (LABELNO)))
+#define ASM_FORMAT_PRIVATE_NAME(OUTPUT, NAME, LABELNO) \
+  ((OUTPUT) = (char *) alloca (strlen ((NAME)) + 10),  \
+   sprintf ((OUTPUT), "%s.%u", (NAME), (unsigned int)(LABELNO)))
 
 /* The following macro defines the format used to output the second
operand of the .type assembler directive.  Different svr4 assemblers
-- 
2.24.1

RE: [PATCH] ICE: in vectorizable_load, at tree-vect-stmts.c:9173

[Yangfei (Felix)]

Hi!

> -Original Message-
> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
> Sent: Tuesday, March 31, 2020 4:55 PM
> To: Yangfei (Felix) 
> Cc: gcc-patches@gcc.gnu.org; rguent...@suse.de
> Subject: Re: [PATCH] ICE: in vectorizable_load, at tree-vect-stmts.c:9173
> >
> > Yes, I have modified accordingly.  Attached please find the adapted patch.
> > Bootstrapped and tested on aarch64-linux-gnu.  Newly add test will fail
> without the patch and pass otherwise.
> 
> Looks good.  OK for master.

Thanks for reviewing this.  

> > I think I need a sponsor if this patch can go separately.
> 
> Yeah, please fill in the form on:
> 
>https://sourceware.org/cgi-bin/pdw/ps_form.cgi
> 
> listing me as sponsor.

Hmm, I already have an account : - )  
But my networking does not work well and I am having some trouble committing 
the patch.  
Could you please help commit this patch?  

Felix

RE: [GCC][ARM][PATCH]: Add MVE ACLE intrinsics vbicq_n_* polymorphic variant support.

[Kyrylo Tkachov]

Hi Srinath,

> -Original Message-
> From: Srinath Parvathaneni 
> Sent: 31 March 2020 10:19
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Earnshaw ; Kyrylo Tkachov
> 
> Subject: [GCC][ARM][PATCH]: Add MVE ACLE intrinsics vbicq_n_*
> polymorphic variant support.
> 
> Hello,
> 
> For the following MVE ACLE intrinsics, polymorphic variant support is missing
> on the trunk.
> 
> vbicq_n_s16, vbicq_n_s32, vbicq_n_u16 and vbicq_n_u32.
> 
> This patch add the polymorphic variant support for above intrinsics.
> 
> Please refer to M-profile Vector Extension (MVE) intrinsics [1]  for more
> details.
> [1] https://developer.arm.com/architectures/instruction-sets/simd-
> isas/helium/mve-intrinsics
> 
> Regression tested on arm-none-eabi and found no regressions.
> 
> Ok for trunk?

Thanks, I've pushed this patch to master.
Kyrill

> 
> Thanks,
> Srinath.
> 
> gcc/ChangeLog:
> 
> 2020-03-30  Srinath Parvathaneni  
> 
> * config/arm/arm_mve.h (vbicq): Define MVE intrinsic polymorphic
>   variant.
>   (__arm_vbicq): Likewise.
> 
> 2020-03-30  Srinath Parvathaneni  
> 
>   * gcc.target/arm/mve/intrinsics/vbicq_n_s16.c: Modify.
>   * gcc.target/arm/mve/intrinsics/vbicq_n_s32.c: Likewise.
>   * gcc.target/arm/mve/intrinsics/vbicq_n_u16.c: Likewise.
>   * gcc.target/arm/mve/intrinsics/vbicq_n_u32.c: Likewise.
> 
> 
> ### Attachment also inlined for ease of reply
> ###
> 
> 
> diff --git a/gcc/config/arm/arm_mve.h b/gcc/config/arm/arm_mve.h index
> 14b6ec857bffd85b67c781f554faffde1b2abc6b..d14ca24068e0bc5e75fa19177
> 18a09a2ec3d9cbe 100644
> --- a/gcc/config/arm/arm_mve.h
> +++ b/gcc/config/arm/arm_mve.h
> @@ -20704,6 +20704,10 @@ extern void *__ARM_undef;  #define
> __arm_vbicq(p0,p1) ({ __typeof(p0) __p0 = (p0); \
>__typeof(p1) __p1 = (p1); \
>_Generic( (int (*)[__ARM_mve_typeid(__p0)][__ARM_mve_typeid(__p1)])0,
> \
> +  int (*)[__ARM_mve_type_int16x8_t][__ARM_mve_type_int32_t]:
> + __arm_vbicq_n_s16 (__ARM_mve_coerce(__p0, int16x8_t),
> + __ARM_mve_coerce1(__p1, int)), \  int
> + (*)[__ARM_mve_type_int32x4_t][__ARM_mve_type_int32_t]:
> + __arm_vbicq_n_s32 (__ARM_mve_coerce(__p0, int32x4_t),
> + __ARM_mve_coerce1(__p1, int)), \  int
> + (*)[__ARM_mve_type_uint16x8_t][__ARM_mve_type_int32_t]:
> + __arm_vbicq_n_u16 (__ARM_mve_coerce(__p0, uint16x8_t),
> + __ARM_mve_coerce1(__p1, int)), \  int
> + (*)[__ARM_mve_type_uint32x4_t][__ARM_mve_type_int32_t]:
> + __arm_vbicq_n_u32 (__ARM_mve_coerce(__p0, uint32x4_t),
> + __ARM_mve_coerce1(__p1, int)), \
>int (*)[__ARM_mve_type_int8x16_t][__ARM_mve_type_int8x16_t]:
> __arm_vbicq_s8 (__ARM_mve_coerce(__p0, int8x16_t),
> __ARM_mve_coerce(__p1, int8x16_t)), \
>int (*)[__ARM_mve_type_int16x8_t][__ARM_mve_type_int16x8_t]:
> __arm_vbicq_s16 (__ARM_mve_coerce(__p0, int16x8_t),
> __ARM_mve_coerce(__p1, int16x8_t)), \
>int (*)[__ARM_mve_type_int32x4_t][__ARM_mve_type_int32x4_t]:
> __arm_vbicq_s32 (__ARM_mve_coerce(__p0, int32x4_t),
> __ARM_mve_coerce(__p1, int32x4_t)), \ @@ -24095,6 +24099,10 @@
> extern void *__ARM_undef;  #define __arm_vbicq(p0,p1) ({ __typeof(p0)
> __p0 = (p0); \
>__typeof(p1) __p1 = (p1); \
>_Generic( (int (*)[__ARM_mve_typeid(__p0)][__ARM_mve_typeid(__p1)])0,
> \
> +  int (*)[__ARM_mve_type_int16x8_t][__ARM_mve_type_int32_t]:
> + __arm_vbicq_n_s16 (__ARM_mve_coerce(__p0, int16x8_t),
> + __ARM_mve_coerce1(__p1, int)), \  int
> + (*)[__ARM_mve_type_int32x4_t][__ARM_mve_type_int32_t]:
> + __arm_vbicq_n_s32 (__ARM_mve_coerce(__p0, int32x4_t),
> + __ARM_mve_coerce1(__p1, int)), \  int
> + (*)[__ARM_mve_type_uint16x8_t][__ARM_mve_type_int32_t]:
> + __arm_vbicq_n_u16 (__ARM_mve_coerce(__p0, uint16x8_t),
> + __ARM_mve_coerce1(__p1, int)), \  int
> + (*)[__ARM_mve_type_uint32x4_t][__ARM_mve_type_int32_t]:
> + __arm_vbicq_n_u32 (__ARM_mve_coerce(__p0, uint32x4_t),
> + __ARM_mve_coerce1(__p1, int)), \
>int (*)[__ARM_mve_type_int8x16_t][__ARM_mve_type_int8x16_t]:
> __arm_vbicq_s8 (__ARM_mve_coerce(__p0, int8x16_t),
> __ARM_mve_coerce(__p1, int8x16_t)), \
>int (*)[__ARM_mve_type_int16x8_t][__ARM_mve_type_int16x8_t]:
> __arm_vbicq_s16 (__ARM_mve_coerce(__p0, int16x8_t),
> __ARM_mve_coerce(__p1, int16x8_t)), \
>int (*)[__ARM_mve_type_int32x4_t][__ARM_mve_type_int32x4_t]:
> __arm_vbicq_s32 (__ARM_mve_coerce(__p0, int32x4_t),
> __ARM_mve_coerce(__p1, int32x4_t)), \ diff --git
> a/gcc/testsuite/gcc.target/arm/mve/intrinsics/vbicq_n_s16.c
> b/gcc/testsuite/gcc.target/arm/mve/intrinsics/vbicq_n_s16.c
> index
> 96b9699d6b166954f0d5900abc47c64e18416d0c..ecc48503fc2d2b16c9135c41
> 2df22f748874750c 100644
> --- a/gcc/testsuite/gcc.target/arm/mve/intrinsics/vbicq_n_s16.c
> +++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/vbicq_n_s16.c
> @@ -10,4 +10,10 @@ foo (int16x8_t a)
>return vbicq_n_s16 (a, 1);
>  }
> 
> -/* { dg-final { scan-assembler "vbic.i16"  }  } */
> +int16x8_t
> +foo1 (int16x8_t a)
> +{
> +  return vbicq (a, 1);
> +}
> +
> +/* { dg-final { scan-assembler-times "vbic.i16" 2 

Re: [PATCH] [ARC] Allow more ABIs in GLIBC_DYNAMIC_LINKER

[Claudiu Zissulescu Ianculescu via Gcc-patches]

Pushed.

Thank you,
Claudiu

On Sun, Mar 29, 2020 at 2:05 AM Vineet Gupta via Gcc-patches
 wrote:
>
> Enable big-endian suffixed dynamic linker per glibc multi-abi support.
>
> And to avoid a future churn and version pairingi hassles, also allow
> arc700 although glibc for ARC currently doesn't support it.
>
> gcc/
> -xx-xx  Vineet Gupta 
> +
> +   * config/arc/linux.h: GLIBC_DYNAMIC_LINKER support BE/arc700
>
> Signed-off-by: Vineet Gupta 
> ---
>  gcc/ChangeLog  | 4 
>  gcc/config/arc/linux.h | 2 +-
>  2 files changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/gcc/ChangeLog b/gcc/ChangeLog
> index 86ad683a6cb0..c26a748fd51b 100644
> --- a/gcc/ChangeLog
> +++ b/gcc/ChangeLog
> @@ -1,3 +1,7 @@
> +2020-03-28  Vineet Gupta 
> +
> +   * config/arc/linux.h: GLIBC_DYNAMIC_LINKER support BE/arc700
> +
>  2020-03-28  Jakub Jelinek  
>
> PR c/93573
> diff --git a/gcc/config/arc/linux.h b/gcc/config/arc/linux.h
> index 0b99da3fcdaf..1bbeccee7115 100644
> --- a/gcc/config/arc/linux.h
> +++ b/gcc/config/arc/linux.h
> @@ -29,7 +29,7 @@ along with GCC; see the file COPYING3.  If not see
>  }  \
>while (0)
>
> -#define GLIBC_DYNAMIC_LINKER   "/lib/ld-linux-arc.so.2"
> +#define GLIBC_DYNAMIC_LINKER   
> "/lib/ld-linux-arc%{mbig-endian:eb}%{mcpu=arc700:700}.so.2"
>  #define UCLIBC_DYNAMIC_LINKER  "/lib/ld-uClibc.so.0"
>
>  /* Note that the default is to link against dynamic libraries, if they are
> --
> 2.20.1
>

RE: [GCC][ARM][PATCH]: Add support for MVE ACLE intrinsics polymorphic variants for +mve.fp option.

[Kyrylo Tkachov]

Hi Srinath,

> -Original Message-
> From: Srinath Parvathaneni 
> Sent: 25 March 2020 18:48
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Earnshaw ; Kyrylo Tkachov
> 
> Subject: [GCC][ARM][PATCH]: Add support for MVE ACLE intrinsics
> polymorphic variants for +mve.fp option.
> 
> Hello,
> 
> For the following MVE ACLE intrinsics, polymorphic variant supports only
> +mve option, support for +mve.fp is missing.
> 
> vabavq_p_s16, vabavq_p_s32, vabavq_p_s8, vabavq_p_u16, vabavq_p_u32,
> vabavq_p_u8, vabavq_s16, vabavq_s32, vabavq_s8, vabavq_u16,
> vabavq_u32, vabavq_u8, vaddlvaq_p_s32, vaddlvaq_p_u32, vaddlvaq_s32,
> vaddlvaq_u32, vaddlvq_p_s32, vaddlvq_p_u32, vaddlvq_u32,
> vaddvaq_p_s16, vaddvaq_p_s32, vaddvaq_p_s8, vaddvaq_p_u16,
> vaddvaq_p_u32, vaddvaq_p_u8, vaddvaq_s16, vaddvaq_s32, vaddvaq_s8,
> vaddvaq_u16, vaddvaq_u32, vaddvaq_u8, vaddvq_p_s16, vaddvq_p_s32,
> vaddvq_p_s8, vaddvq_p_u16, vaddvq_p_u32, vaddvq_p_u8, vaddvq_s8,
> vaddvq_u16, vaddvq_u32, vaddvq_u8, vcmpcsq_m_n_u16,
> vcmpcsq_m_n_u32, vcmpcsq_m_n_u8, vcmpcsq_m_u16, vcmpcsq_m_u32,
> vcmpcsq_m_u8, vcmpcsq_n_u16, vcmpcsq_n_u32, vcmpcsq_n_u8,
> vcmpcsq_u16, vcmpcsq_u32, vcmpcsq_u8, vcmpeqq_n_f16, vcmpeqq_n_f32,
> vcmpgeq_m_n_s16, vcmpgeq_m_n_s32, vcmpgeq_m_n_s8,
> vcmpgtq_m_n_f16, vcmpgtq_m_n_f32, vcmpgtq_n_f16, vcmpgtq_n_f32,
> vcmphiq_m_n_u16, vcmphiq_m_n_u32, vcmphiq_m_n_u8, vcmphiq_m_u16,
> vcmphiq_m_u32, vcmphiq_m_u8, vcmphiq_n_u16, vcmphiq_n_u32,
> vcmphiq_n_u8, vcmphiq_u16, vcmphiq_u32, vcmphiq_u8,
> vcmpleq_m_n_f16, vcmpleq_m_n_f32, vcmpleq_n_f16, vcmpleq_n_f32,
> vcmpltq_m_n_f16, vcmpltq_m_n_f32, vcmpneq_m_n_f16,
> vcmpneq_m_n_f32, vcmpneq_n_f16, vcmpneq_n_f32, vmaxavq_p_s16,
> vmaxavq_p_s32, vmaxavq_p_s8, vmaxavq_s16, vmaxavq_s32, vmaxavq_s8,
> vmaxq_x_s16, vmaxq_x_s32, vmaxq_x_s8, vmaxq_x_u16, vmaxq_x_u32,
> vmaxq_x_u8, vmaxvq_p_s16, vmaxvq_p_s32, vmaxvq_p_s8, vmaxvq_p_u16,
> vmaxvq_p_u32, vmaxvq_p_u8, vmaxvq_s16, vmaxvq_s32, vmaxvq_s8,
> vmaxvq_u16, vmaxvq_u32, vmaxvq_u8, vminavq_p_s16, vminavq_p_s32,
> vminavq_p_s8, vminavq_s16, vminavq_s32, vminavq_s8, vminq_x_s16,
> vminq_x_s32, vminq_x_s8, vminq_x_u16, vminq_x_u32, vminq_x_u8,
> vminvq_p_s16, vminvq_p_s32, vminvq_p_s8, vminvq_p_u16, vminvq_p_u32,
> vminvq_p_u8, vminvq_s16, vminvq_s32, vminvq_s8, vminvq_u16,
> vminvq_u32, vminvq_u8, vmladavaq_p_s16, vmladavaq_p_s32,
> vmladavaq_p_s8, vmladavaq_p_u16, vmladavaq_p_u32, vmladavaq_p_u8,
> vmladavaq_s16, vmladavaq_s32, vmladavaq_s8, vmladavaq_u16,
> vmladavaq_u32, vmladavaq_u8, vmladavaxq_s16, vmladavaxq_s32,
> vmladavaxq_s8, vmladavq_p_s16, vmladavq_p_s32, vmladavq_p_s8,
> vmladavq_p_u16, vmladavq_p_u32, vmladavq_p_u8, vmladavq_s16,
> vmladavq_s32, vmladavq_s8, vmladavq_u16, vmladavq_u32, vmladavq_u8,
> vmladavxq_p_s16, vmladavxq_p_s32, vmladavxq_p_s8, vmladavxq_s16,
> vmladavxq_s32, vmladavxq_s8, vmlaldavaq_s16, vmlaldavaq_s32,
> vmlaldavaq_u16, vmlaldavaq_u32, vmlaldavaxq_s16, vmlaldavaxq_s32,
> vmlaldavq_p_s16, vmlaldavq_p_s32, vmlaldavq_p_u16, vmlaldavq_p_u32,
> vmlaldavq_s16, vmlaldavq_s32, vmlaldavq_u16, vmlaldavq_u32,
> vmlaldavxq_p_s16, vmlaldavxq_p_s32, vmlsdavaq_s16, vmlsdavaq_s32,
> vmlsdavaq_s8, vmlsdavaxq_s16, vmlsdavaxq_s32, vmlsdavaxq_s8,
> vmlsdavq_p_s16, vmlsdavq_p_s32, vmlsdavq_p_s8, vmlsdavq_s16,
> vmlsdavq_s32, vmlsdavq_s8, vmlsdavxq_p_s16, vmlsdavxq_p_s32,
> vmlsdavxq_p_s8, vmlsdavxq_s16, vmlsdavxq_s32, vmlsdavxq_s8,
> vmlsldavaq_s16, vmlsldavaq_s32, vmlsldavaxq_s16, vmlsldavaxq_s32,
> vmlsldavq_p_s16, vmlsldavq_p_s32, vmlsldavq_s16, vmlsldavq_s32,
> vmlsldavxq_p_s16, vmlsldavxq_p_s32, vmlsldavxq_s16, vmlsldavxq_s32,
> vmovlbq_x_s16, vmovlbq_x_s8, vmovlbq_x_u16, vmovlbq_x_u8,
> vmovltq_x_s16, vmovltq_x_s8, vmovltq_x_u16, vmovltq_x_u8,
> vmulhq_x_s16, vmulhq_x_s32, vmulhq_x_s8, vmulhq_x_u16, vmulhq_x_u32,
> vmulhq_x_u8, vmullbq_int_x_s16, vmullbq_int_x_s32, vmullbq_int_x_s8,
> vmullbq_int_x_u16, vmullbq_int_x_u32, vmullbq_int_x_u8,
> vmullbq_poly_x_p16, vmullbq_poly_x_p8, vmulltq_int_x_s16,
> vmulltq_int_x_s32, vmulltq_int_x_s8, vmulltq_int_x_u16, vmulltq_int_x_u32,
> vmulltq_int_x_u8, vmulltq_poly_x_p16, vmulltq_poly_x_p8,
> vrmlaldavhaq_s32, vrmlaldavhaq_u32, vrmlaldavhaxq_s32,
> vrmlaldavhq_p_s32, vrmlaldavhq_p_u32, vrmlaldavhq_s32,
> vrmlaldavhq_u32, vrmlaldavhxq_p_s32, vrmlaldavhxq_s32,
> vrmlsldavhaq_s32, vrmlsldavhaxq_s32, vrmlsldavhq_p_s32, vrmlsldavhq_s32,
> vrmlsldavhxq_p_s32, vrmlsldavhxq_s32, vstrbq_p_s16, vstrbq_p_s32,
> vstrbq_p_s8, vstrbq_p_u16, vstrbq_p_u32, vstrbq_p_u8, vstrbq_s16,
> vstrbq_s32, vstrbq_s8, vstrbq_scatter_offset_p_s16,
> vstrbq_scatter_offset_p_s32, vstrbq_scatter_offset_p_s8,
> vstrbq_scatter_offset_p_u16, vstrbq_scatter_offset_p_u32,
> vstrbq_scatter_offset_p_u8, vstrbq_scatter_offset_s16,
> vstrbq_scatter_offset_s32, vstrbq_scatter_offset_s8,
> vstrbq_scatter_offset_u16, vstrbq_scatter_offset_u32,
> vstrbq_scatter_offset_u8, vstrbq_u16, vstrbq_u32, vstrbq_u8,
> vstrdq_scatter_base_p_s64, vstrdq_scatter_base_p_u64,
> vstrdq_scatter_base_s64, vstrdq_scatter_base_u64,
> 

[GCC][ARM][PATCH]: Add MVE ACLE intrinsics vbicq_n_* polymorphic variant support.

[Srinath Parvathaneni]

Hello,

For the following MVE ACLE intrinsics, polymorphic variant support is missing 
on the trunk.

vbicq_n_s16, vbicq_n_s32, vbicq_n_u16 and vbicq_n_u32.

This patch add the polymorphic variant support for above intrinsics.

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:

2020-03-30  Srinath Parvathaneni  

* config/arm/arm_mve.h (vbicq): Define MVE intrinsic polymorphic
variant.
(__arm_vbicq): Likewise.

2020-03-30  Srinath Parvathaneni  

* gcc.target/arm/mve/intrinsics/vbicq_n_s16.c: Modify.
* gcc.target/arm/mve/intrinsics/vbicq_n_s32.c: Likewise.
* gcc.target/arm/mve/intrinsics/vbicq_n_u16.c: Likewise.
* gcc.target/arm/mve/intrinsics/vbicq_n_u32.c: Likewise.


### Attachment also inlined for ease of reply###


diff --git a/gcc/config/arm/arm_mve.h b/gcc/config/arm/arm_mve.h
index 
14b6ec857bffd85b67c781f554faffde1b2abc6b..d14ca24068e0bc5e75fa1917718a09a2ec3d9cbe
 100644
--- a/gcc/config/arm/arm_mve.h
+++ b/gcc/config/arm/arm_mve.h
@@ -20704,6 +20704,10 @@ extern void *__ARM_undef;
 #define __arm_vbicq(p0,p1) ({ __typeof(p0) __p0 = (p0); \
   __typeof(p1) __p1 = (p1); \
   _Generic( (int (*)[__ARM_mve_typeid(__p0)][__ARM_mve_typeid(__p1)])0, \
+  int (*)[__ARM_mve_type_int16x8_t][__ARM_mve_type_int32_t]: __arm_vbicq_n_s16 
(__ARM_mve_coerce(__p0, int16x8_t), __ARM_mve_coerce1(__p1, int)), \
+  int (*)[__ARM_mve_type_int32x4_t][__ARM_mve_type_int32_t]: __arm_vbicq_n_s32 
(__ARM_mve_coerce(__p0, int32x4_t), __ARM_mve_coerce1(__p1, int)), \
+  int (*)[__ARM_mve_type_uint16x8_t][__ARM_mve_type_int32_t]: 
__arm_vbicq_n_u16 (__ARM_mve_coerce(__p0, uint16x8_t), __ARM_mve_coerce1(__p1, 
int)), \
+  int (*)[__ARM_mve_type_uint32x4_t][__ARM_mve_type_int32_t]: 
__arm_vbicq_n_u32 (__ARM_mve_coerce(__p0, uint32x4_t), __ARM_mve_coerce1(__p1, 
int)), \
   int (*)[__ARM_mve_type_int8x16_t][__ARM_mve_type_int8x16_t]: __arm_vbicq_s8 
(__ARM_mve_coerce(__p0, int8x16_t), __ARM_mve_coerce(__p1, int8x16_t)), \
   int (*)[__ARM_mve_type_int16x8_t][__ARM_mve_type_int16x8_t]: __arm_vbicq_s16 
(__ARM_mve_coerce(__p0, int16x8_t), __ARM_mve_coerce(__p1, int16x8_t)), \
   int (*)[__ARM_mve_type_int32x4_t][__ARM_mve_type_int32x4_t]: __arm_vbicq_s32 
(__ARM_mve_coerce(__p0, int32x4_t), __ARM_mve_coerce(__p1, int32x4_t)), \
@@ -24095,6 +24099,10 @@ extern void *__ARM_undef;
 #define __arm_vbicq(p0,p1) ({ __typeof(p0) __p0 = (p0); \
   __typeof(p1) __p1 = (p1); \
   _Generic( (int (*)[__ARM_mve_typeid(__p0)][__ARM_mve_typeid(__p1)])0, \
+  int (*)[__ARM_mve_type_int16x8_t][__ARM_mve_type_int32_t]: __arm_vbicq_n_s16 
(__ARM_mve_coerce(__p0, int16x8_t), __ARM_mve_coerce1(__p1, int)), \
+  int (*)[__ARM_mve_type_int32x4_t][__ARM_mve_type_int32_t]: __arm_vbicq_n_s32 
(__ARM_mve_coerce(__p0, int32x4_t), __ARM_mve_coerce1(__p1, int)), \
+  int (*)[__ARM_mve_type_uint16x8_t][__ARM_mve_type_int32_t]: 
__arm_vbicq_n_u16 (__ARM_mve_coerce(__p0, uint16x8_t), __ARM_mve_coerce1(__p1, 
int)), \
+  int (*)[__ARM_mve_type_uint32x4_t][__ARM_mve_type_int32_t]: 
__arm_vbicq_n_u32 (__ARM_mve_coerce(__p0, uint32x4_t), __ARM_mve_coerce1(__p1, 
int)), \
   int (*)[__ARM_mve_type_int8x16_t][__ARM_mve_type_int8x16_t]: __arm_vbicq_s8 
(__ARM_mve_coerce(__p0, int8x16_t), __ARM_mve_coerce(__p1, int8x16_t)), \
   int (*)[__ARM_mve_type_int16x8_t][__ARM_mve_type_int16x8_t]: __arm_vbicq_s16 
(__ARM_mve_coerce(__p0, int16x8_t), __ARM_mve_coerce(__p1, int16x8_t)), \
   int (*)[__ARM_mve_type_int32x4_t][__ARM_mve_type_int32x4_t]: __arm_vbicq_s32 
(__ARM_mve_coerce(__p0, int32x4_t), __ARM_mve_coerce(__p1, int32x4_t)), \
diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/vbicq_n_s16.c 
b/gcc/testsuite/gcc.target/arm/mve/intrinsics/vbicq_n_s16.c
index 
96b9699d6b166954f0d5900abc47c64e18416d0c..ecc48503fc2d2b16c9135c412df22f748874750c
 100644
--- a/gcc/testsuite/gcc.target/arm/mve/intrinsics/vbicq_n_s16.c
+++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/vbicq_n_s16.c
@@ -10,4 +10,10 @@ foo (int16x8_t a)
   return vbicq_n_s16 (a, 1);
 }
 
-/* { dg-final { scan-assembler "vbic.i16"  }  } */
+int16x8_t
+foo1 (int16x8_t a)
+{
+  return vbicq (a, 1);
+}
+
+/* { dg-final { scan-assembler-times "vbic.i16" 2 }  } */
diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/vbicq_n_s32.c 
b/gcc/testsuite/gcc.target/arm/mve/intrinsics/vbicq_n_s32.c
index 
b262c835134b932968013b9abedb54c7ab901ae0..013cdf15cfd974ab82379d95e68b5a1bdf8936ca
 100644
--- a/gcc/testsuite/gcc.target/arm/mve/intrinsics/vbicq_n_s32.c
+++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/vbicq_n_s32.c
@@ -10,4 +10,10 @@ foo (int32x4_t a)
   return vbicq_n_s32 (a, 1);
 }
 
-/* { dg-final { scan-assembler "vbic.i32"  }  } */
+int32x4_t
+foo1 (int32x4_t a)
+{
+  return vbicq (a, 1);

[PATCH 1/2] RISC-V: Update march parser

[Kito Cheng]

 - The arch string rule has changed in latest spec, it introduced new
   multi-letter extension prefix with 'h' and 'z', and drop `sx`. also
   adjust parsing order for 's' and 'x'.

gcc/ChangeLog

* riscv-common.c (parse_sv_or_non_std_ext): Rename to
parse_multiletter_ext.
(parse_multiletter_ext): Add parsing `h` and `z`, drop `sx`,
adjust parsing order for 's' and 'x'.

gcc/testsuite/ChangeLog

* gcc.target/riscv/arch-3.c: Adjust option.
* gcc.target/riscv/arch-5.c: New.
* gcc.target/riscv/attribute-9.c: Adjust option and test
condition.
---
 gcc/common/config/riscv/riscv-common.c   | 40 ++--
 gcc/testsuite/gcc.target/riscv/arch-3.c  |  2 +-
 gcc/testsuite/gcc.target/riscv/arch-5.c  |  5 +++
 gcc/testsuite/gcc.target/riscv/attribute-9.c |  4 +-
 4 files changed, 28 insertions(+), 23 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/riscv/arch-5.c

diff --git a/gcc/common/config/riscv/riscv-common.c 
b/gcc/common/config/riscv/riscv-common.c
index d2ef83b1971..a2e8d7003cc 100644
--- a/gcc/common/config/riscv/riscv-common.c
+++ b/gcc/common/config/riscv/riscv-common.c
@@ -70,8 +70,8 @@ private:
 
   const char *parse_std_ext (const char *);
 
-  const char *parse_sv_or_non_std_ext (const char *, const char *,
-  const char *);
+  const char *parse_multiletter_ext (const char *, const char *,
+const char *);
 
 public:
   ~riscv_subset_list ();
@@ -357,7 +357,7 @@ riscv_subset_list::parse_std_ext (const char *p)
 {
   char subset[2] = {0, 0};
 
-  if (*p == 'x' || *p == 's')
+  if (*p == 'x' || *p == 's' || *p == 'h' || *p == 'z')
break;
 
   if (*p == '_')
@@ -399,20 +399,20 @@ riscv_subset_list::parse_std_ext (const char *p)
   return p;
 }
 
-/* Parsing function for non-standard and supervisor extensions.
+/* Parsing function for multi-letter extensions.
 
Return Value:
  Points to the end of extensions.
 
Arguments:
  `p`: Current parsing position.
- `ext_type`: What kind of extensions, 'x', 's' or 'sx'.
+ `ext_type`: What kind of extensions, 's', 'h', 'z' or 'x'.
  `ext_type_str`: Full name for kind of extension.  */
 
 const char *
-riscv_subset_list::parse_sv_or_non_std_ext (const char *p,
-   const char *ext_type,
-   const char *ext_type_str)
+riscv_subset_list::parse_multiletter_ext (const char *p,
+ const char *ext_type,
+ const char *ext_type_str)
 {
   unsigned major_version = 0;
   unsigned minor_version = 0;
@@ -429,11 +429,6 @@ riscv_subset_list::parse_sv_or_non_std_ext (const char *p,
   if (strncmp (p, ext_type, ext_type_len) != 0)
break;
 
-  /* It's non-standard supervisor extension if it prefix with sx.  */
-  if ((ext_type[0] == 's') && (ext_type_len == 1)
- && (*(p + 1) == 'x'))
-   break;
-
   char *subset = xstrdup (p);
   char *q = subset;
   const char *end_of_version;
@@ -494,21 +489,26 @@ riscv_subset_list::parse (const char *arch, location_t 
loc)
   if (p == NULL)
 goto fail;
 
-  /* Parsing non-standard extension.  */
-  p = subset_list->parse_sv_or_non_std_ext (p, "x", "non-standard extension");
+  /* Parsing supervisor extension.  */
+  p = subset_list->parse_multiletter_ext (p, "s", "supervisor extension");
 
   if (p == NULL)
 goto fail;
 
-  /* Parsing supervisor extension.  */
-  p = subset_list->parse_sv_or_non_std_ext (p, "s", "supervisor extension");
+  /* Parsing hypervisor extension.  */
+  p = subset_list->parse_multiletter_ext (p, "h", "hypervisor extension");
 
   if (p == NULL)
 goto fail;
 
-  /* Parsing non-standard supervisor extension.  */
-  p = subset_list->parse_sv_or_non_std_ext
-(p, "sx", "non-standard supervisor extension");
+  /* Parsing sub-extensions.  */
+  p = subset_list->parse_multiletter_ext (p, "z", "sub-extension");
+
+  if (p == NULL)
+goto fail;
+
+  /* Parsing non-standard extension.  */
+  p = subset_list->parse_multiletter_ext (p, "x", "non-standard extension");
 
   if (p == NULL)
 goto fail;
diff --git a/gcc/testsuite/gcc.target/riscv/arch-3.c 
b/gcc/testsuite/gcc.target/riscv/arch-3.c
index 6aaa0a650fa..124699405c5 100644
--- a/gcc/testsuite/gcc.target/riscv/arch-3.c
+++ b/gcc/testsuite/gcc.target/riscv/arch-3.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O -march=rv32ixbar_sabc_sxfoo -mabi=ilp32" } */
+/* { dg-options "-O -march=rv32isabc_xbar -mabi=ilp32" } */
 int foo()
 {
 }
diff --git a/gcc/testsuite/gcc.target/riscv/arch-5.c 
b/gcc/testsuite/gcc.target/riscv/arch-5.c
new file mode 100644
index 000..b0a1bd445fe
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/arch-5.c
@@ -0,0 +1,5 @@
+/* { dg-do compile } */
+/* { dg-options "-O 

[PATCH 2/2] RISC-V: Handle implied extension for -march parser.

[Kito Cheng]

  - Implied rule are introduced into latest RISC-V isa spec.

  - Only implemented D implied F-extension. Zicsr and Zifence are not
implement yet, so the rule not included in this patch.

gcc/ChangeLog

* common/config/riscv/riscv-common.c (riscv_implied_info_t): New.
(riscv_implied_info): New.
(riscv_subset_list): Add handle_implied_ext.
(riscv_subset_list::handle_implied_ext): New.
(riscv_subset_list::parse_std_ext): Call handle_implied_ext.

gcc/testsuite/ChangeLog

* gcc.target/riscv/arch-6.c: New.
* gcc.target/riscv/attribute-11.c: New.
---
 gcc/common/config/riscv/riscv-common.c| 39 +++
 gcc/testsuite/gcc.target/riscv/arch-6.c   |  5 +++
 gcc/testsuite/gcc.target/riscv/attribute-11.c |  6 +++
 3 files changed, 50 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/riscv/arch-6.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/attribute-11.c

diff --git a/gcc/common/config/riscv/riscv-common.c 
b/gcc/common/config/riscv/riscv-common.c
index a2e8d7003cc..24100cfae74 100644
--- a/gcc/common/config/riscv/riscv-common.c
+++ b/gcc/common/config/riscv/riscv-common.c
@@ -44,6 +44,20 @@ struct riscv_subset_t
   struct riscv_subset_t *next;
 };
 
+/* Type for implied ISA info.  */
+struct riscv_implied_info_t
+{
+  const char *ext;
+  const char *implied_ext;
+};
+
+/* Implied ISA info, must end with NULL sentinel.  */
+riscv_implied_info_t riscv_implied_info[] =
+{
+  {"d", "f"},
+  {NULL, NULL}
+};
+
 /* Subset list.  */
 class riscv_subset_list
 {
@@ -73,6 +87,8 @@ private:
   const char *parse_multiletter_ext (const char *, const char *,
 const char *);
 
+  void handle_implied_ext (const char *, int, int);
+
 public:
   ~riscv_subset_list ();
 
@@ -394,11 +410,34 @@ riscv_subset_list::parse_std_ext (const char *p)
 
   subset[0] = std_ext;
 
+  handle_implied_ext (subset, major_version, minor_version);
+
   add (subset, major_version, minor_version);
 }
   return p;
 }
 
+
+/* Check any implied extensions for EXT with version
+   MAJOR_VERSION.MINOR_VERSION.  */
+void
+riscv_subset_list::handle_implied_ext (const char *ext,
+  int major_version,
+  int minor_version)
+{
+  riscv_implied_info_t *implied_info;
+  for (implied_info = _implied_info[0];
+   implied_info->ext;
+   ++implied_info)
+{
+  if (strcmp (ext, implied_info->ext) != 0)
+   continue;
+
+  /* TODO: Implied extension might use differet version.  */
+  add (implied_info->implied_ext, major_version, minor_version);
+}
+}
+
 /* Parsing function for multi-letter extensions.
 
Return Value:
diff --git a/gcc/testsuite/gcc.target/riscv/arch-6.c 
b/gcc/testsuite/gcc.target/riscv/arch-6.c
new file mode 100644
index 000..b36dccbf46b
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/arch-6.c
@@ -0,0 +1,5 @@
+/* { dg-do compile } */
+/* { dg-options "-O -march=rv32id -mabi=ilp32" } */
+int foo()
+{
+}
diff --git a/gcc/testsuite/gcc.target/riscv/attribute-11.c 
b/gcc/testsuite/gcc.target/riscv/attribute-11.c
new file mode 100644
index 000..a8649508b2f
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/attribute-11.c
@@ -0,0 +1,6 @@
+/* { dg-do compile } */
+/* { dg-options "-O -mriscv-attribute -march=rv32id -mabi=ilp32" } */
+int foo()
+{
+}
+/* { dg-final { scan-assembler ".attribute arch, \"rv32i2p0_f2p0_d2p0\"" } } */
-- 
2.25.2

Re: [PATCH] aarch64: Fix up aarch64_compare_and_swaphi pattern [PR94368]

[Richard Sandiford]

Jakub Jelinek  writes:
> Hi!
>
> The following testcase ICEs in final_scan_insn_1.  The problem is in the
> @aarch64_compare_and_swaphi define_insn_and_split, since 9 it uses
> aarch64_plushi_operand predicate for the "expected value" operand, which
> allows either 0..0xfff constants or 0x1000..0xf000 constants (i.e. HImode
> values which when zero extended are either 0..0xfff or (0..0xfff) << 12).
> The problem is that RA doesn't care about predicates, it honors just
> constraints and the used constraint on the operand is n, which means any
> HImode CONST_SCALAR_INT.  In the testcase LRA thus propagates the -1
> value into the insn.
> This is a define_insn_and_split which requires mandatory split.
> But during split2 pass, we check the predicate (and don't check
> constraints), which fails and thus we don't split it and during final ICE
> because the mandatory splitting didn't happen.
>
> The following patch fixes it by adding a matching constraint to the
> predicate and using it.
>
> Bootstrapped/regtested on aarch64-linux, ok for trunk?

OK, thanks.

Richard

> 2020-03-31  Jakub Jelinek  
>
>   PR target/94368
>   * config/aarch64/constraints.md (Uph): New constraint.
>   * config/aarch64/atomics.md (cas_short_expected_imm): New mode attr.
>   (@aarch64_compare_and_swap): Use it instead of n in operand 2's
>   constraint.
>
>   * gcc.dg/pr94368.c: New test.
>
> --- gcc/config/aarch64/constraints.md.jj  2020-01-17 19:35:54.101144322 
> +0100
> +++ gcc/config/aarch64/constraints.md 2020-03-30 11:39:29.554441681 +0200
> @@ -233,6 +233,13 @@ (define_constraint "Up3"
>(and (match_code "const_int")
> (match_test "(unsigned) exact_log2 (ival) <= 4")))
>  
> +(define_constraint "Uph"
> +  "@internal
> +  A constraint that matches HImode integers zero extendable to
> +  SImode plus_operand."
> +  (and (match_code "const_int")
> +   (match_test "aarch64_plushi_immediate (op, VOIDmode)")))
> +
>  (define_memory_constraint "Q"
>   "A memory address which uses a single base register with no offset."
>   (and (match_code "mem")
> --- gcc/config/aarch64/atomics.md.jj  2020-01-17 14:46:41.464792827 +0100
> +++ gcc/config/aarch64/atomics.md 2020-03-30 11:42:02.256180919 +0200
> @@ -38,6 +38,8 @@ (define_expand "@atomic_compare_and_swap
>  
>  (define_mode_attr cas_short_expected_pred
>[(QI "aarch64_reg_or_imm") (HI "aarch64_plushi_operand")])
> +(define_mode_attr cas_short_expected_imm
> +  [(QI "n") (HI "Uph")])
>  
>  (define_insn_and_split "@aarch64_compare_and_swap"
>[(set (reg:CC CC_REGNUM)   ;; bool out
> @@ -47,7 +49,8 @@ (define_insn_and_split "@aarch64_compare
>(match_operand:SHORT 1 "aarch64_sync_memory_operand" "+Q"))) ;; memory
> (set (match_dup 1)
>  (unspec_volatile:SHORT
> -  [(match_operand:SHORT 2 "" "rn")  ;; 
> expected
> +  [(match_operand:SHORT 2 ""
> +   "r")  ;; expected
> (match_operand:SHORT 3 "aarch64_reg_or_zero" "rZ");; desired
> (match_operand:SI 4 "const_int_operand")  ;; 
> is_weak
> (match_operand:SI 5 "const_int_operand")  ;; mod_s
> --- gcc/testsuite/gcc.dg/pr94368.c.jj 2020-03-30 11:47:18.573497812 +0200
> +++ gcc/testsuite/gcc.dg/pr94368.c2020-03-30 11:25:54.002642049 +0200
> @@ -0,0 +1,25 @@
> +/* PR target/94368 */
> +/* { dg-do compile { target fpic } } */
> +/* { dg-options "-fpic -O1 -fcommon" } */
> +
> +int b, c, d, e, f, h;
> +short g;
> +int foo (int) __attribute__ ((__const__));
> +
> +void
> +bar (void)
> +{
> +  while (1)
> +{
> +  while (1)
> + {
> +   __atomic_load_n (, 0);
> +   if (foo (2))
> + __sync_val_compare_and_swap (, 0, f);
> +   b = 1;
> +   if (h == e)
> + break;
> + }
> +  __sync_val_compare_and_swap (, -1, f);
> +}
> +}
>
>   Jakub

Re: [PATCH] ICE: in vectorizable_load, at tree-vect-stmts.c:9173

[Richard Sandiford]

"Yangfei (Felix)"  writes:
> Hi!
>
>> -Original Message-
>> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
>> Sent: Monday, March 30, 2020 8:08 PM
>> To: Yangfei (Felix) 
>> Cc: gcc-patches@gcc.gnu.org; rguent...@suse.de
>> Subject: Re: [PATCH] ICE: in vectorizable_load, at tree-vect-stmts.c:9173
>> 
>> "Yangfei (Felix)"  writes:
>> > Hi!
>> >> -Original Message-
>> >> From: Yangfei (Felix)
>> >> Sent: Monday, March 30, 2020 5:28 PM
>> >> To: gcc-patches@gcc.gnu.org
>> >> Cc: 'rguent...@suse.de' 
>> >> Subject: [PATCH] ICE: in vectorizable_load, at tree-vect-stmts.c:9173
>> >>
>> >> Hi,
>> >>
>> >> New bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94398
>> >>
>> >> With -mstrict-align, aarch64_builtin_support_vector_misalignment will
>> >> returns false when misalignment factor is unknown at compile time.
>> >> Then vect_supportable_dr_alignment returns dr_unaligned_unsupported,
>> >> which triggers the ICE.  I have pasted the call trace on the bug report.
>> >>
>> >> vect_supportable_dr_alignment is expected to return either dr_aligned
>> >> or dr_unaligned_supported for masked operations.
>> >> But it seems that this function only catches internal_fn
>> >> IFN_MASK_LOAD & IFN_MASK_STORE.
>> >> We are emitting a mask gather load here for this test case.
>> >> As backends have their own vector misalignment support policy, I am
>> >> supposing this should be better handled in the auto-vect shared code.
>> >>
>> >
>> > I can only reply to comment on the bug here as my account got locked by the
>> bugzilla system for now.
>> 
>> Sorry to hear that.  What was the reason?
>
> Looks like it got filtered by spamassassin.  Admin has helped unlocked it.  
>
>> > The way Richard (rsandifo) suggests also works for me and I agree it should
>> be more consistent and better for compile time.
>> > One question here: when will a IFN_MASK_LOAD/IFN_MASK_STORE be
>> passed to vect_supportable_dr_alignment?
>> 
>> I'd expect that to happen in the same cases as for unmasked load/stores.
>> It certainly will for unconditional loads and stores that get masked via 
>> full-loop
>> masking.
>> 
>> In principle, the same rules apply to both masked and unmasked accesses.
>> But for SVE, both masked and unmasked accesses should support misalignment,
>> which is why I think the current target hook is probably wrong for SVE +
>> -mstrict-align.
>
> I stopped looking into the backend further when I saw no distinction for 
> different type of access
> in the target hook aarch64_builtin_support_vector_misalignment. 
>
>> > @@ -8051,8 +8051,15 @@ vectorizable_store (stmt_vec_info stmt_info,
>> gimple_stmt_iterator *gsi,
>> >auto_vec dr_chain (group_size);
>> >oprnds.create (group_size);
>> >
>> > -  alignment_support_scheme
>> > -= vect_supportable_dr_alignment (first_dr_info, false);
>> > +  /* Strided accesses perform only component accesses, alignment
>> > + is irrelevant for them.  */
>> > +  if (STMT_VINFO_STRIDED_P (first_dr_info->stmt)
>> > +  && !STMT_VINFO_GROUPED_ACCESS (first_dr_info->stmt))
>> 
>> I think this should be based on memory_access_type ==
>> VMAT_GATHER_SCATTER instead.  At this point, STMT_VINFO_* describes
>> properties of the original scalar access(es) while memory_access_type
>> describes the vector implementation strategy.  It's the latter that matters
>> here.
>> 
>> Same thing for loads.
>
> Yes, I have modified accordingly.  Attached please find the adapted patch.  
> Bootstrapped and tested on aarch64-linux-gnu.  Newly add test will fail 
> without the patch and pass otherwise.  

Looks good.  OK for master.

> I think I need a sponsor if this patch can go separately.  

Yeah, please fill in the form on:

   https://sourceware.org/cgi-bin/pdw/ps_form.cgi

listing me as sponsor.

Thanks,
Richard

Re: [PATCH] store-merging: Allow enums during bswap recognition [PR94403]

[Richard Biener]

On Tue, 31 Mar 2020, Jakub Jelinek wrote:

> Hi!
> 
> The following testcase is optimized with char/unsigned char/signed char,
> but not with std::byte.  The following patch fixes that.  Didn't use
> INTEGRAL_TYPE_P because bswapping bools is just too weird.

Is it?

> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for GCC11 (or is
> it simple enough that we want it in GCC10 already)?

OK for GCC 10.

Richard.

> 2020-03-31  Jakub Jelinek  
> 
>   PR tree-optimization/94403
>   * gimple-ssa-store-merging.c (verify_symbolic_number_p): Allow also
>   ENUMERAL_TYPE lhs_type.
> 
>   * g++.dg/tree-ssa/pr94403.C: New test.
> 
> --- gcc/gimple-ssa-store-merging.c.jj 2020-03-20 09:33:03.602112329 +0100
> +++ gcc/gimple-ssa-store-merging.c2020-03-30 18:30:31.723341519 +0200
> @@ -315,7 +315,8 @@ verify_symbolic_number_p (struct symboli
>  
>lhs_type = gimple_expr_type (stmt);
>  
> -  if (TREE_CODE (lhs_type) != INTEGER_TYPE)
> +  if (TREE_CODE (lhs_type) != INTEGER_TYPE
> +  && TREE_CODE (lhs_type) != ENUMERAL_TYPE)
>  return false;
>  
>if (TYPE_PRECISION (lhs_type) != TYPE_PRECISION (n->type))
> --- gcc/testsuite/g++.dg/tree-ssa/pr94403.C.jj2020-03-30 
> 18:42:28.563719010 +0200
> +++ gcc/testsuite/g++.dg/tree-ssa/pr94403.C   2020-03-30 18:51:21.135828389 
> +0200
> @@ -0,0 +1,37 @@
> +// PR tree-optimization/94403
> +// Only test on some 64-bit targets which do have bswap{si,di}2 patterns and
> +// are either big or little endian (not pdp endian).
> +// { dg-do compile { target { lp64 && { i?86-*-* x86_64-*-* powerpc*-*-* 
> aarch64*-*-* } } } }
> +// { dg-require-effective-target store_merge }
> +// { dg-options "-O2 -fdump-tree-store-merging -std=c++17" }
> +
> +namespace std {
> +  template 
> +  void swap (T& t1, T& t2) { T tmp (t1); t1 = t2; t2 = tmp; }
> +  enum class byte : unsigned char {};
> +}
> +
> +unsigned
> +bswap32 (unsigned int x)
> +{
> +  unsigned int y = x;
> +  std::byte *bytes = reinterpret_cast ();
> +  std::swap (bytes[0], bytes[3]);
> +  std::swap (bytes[1], bytes[2]);
> +  return y;
> +}
> +
> +unsigned long long
> +bswap64 (unsigned long long x)
> +{
> +  unsigned long long y = x;
> +  std::byte *bytes = reinterpret_cast ();
> +  std::swap (bytes[0], bytes[7]);
> +  std::swap (bytes[1], bytes[6]);
> +  std::swap (bytes[2], bytes[5]);
> +  std::swap (bytes[3], bytes[4]);
> +  return y;
> +}
> +
> +/* { dg-final { scan-tree-dump-times "__builtin_bswap64" 1 "store-merging" } 
> } */
> +/* { dg-final { scan-tree-dump-times "__builtin_bswap32" 1 "store-merging" } 
> } */
> 
>   Jakub
> 
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)

Re: [PATCH] fold-const: Fix division folding with vector operands [PR94412]

[Richard Biener]

On Tue, 31 Mar 2020, Jakub Jelinek wrote:

> Hi!
> 
> The following testcase is miscompiled since 4.9, we treat unsigned
> vector types as if they were signed and "optimize" negations across it.
> 
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
> trunk?

OK.

Richard.

> 2020-03-31  Marc Glisse  
>   Jakub Jelinek  
> 
>   PR middle-end/94412
>   * fold-const.c (fold_binary_loc) : Use
>   ANY_INTEGRAL_TYPE_P instead of INTEGRAL_TYPE_P.
> 
>   * gcc.c-torture/execute/pr94412.c: New test.
> 
> --- gcc/fold-const.c.jj   2020-03-19 10:23:34.106114042 +0100
> +++ gcc/fold-const.c  2020-03-30 23:00:32.273551465 +0200
> @@ -11148,11 +11148,11 @@ fold_binary_loc (location_t loc, enum tr
>  
>/* Convert -A / -B to A / B when the type is signed and overflow is
>undefined.  */
> -  if ((!INTEGRAL_TYPE_P (type) || TYPE_OVERFLOW_UNDEFINED (type))
> +  if ((!ANY_INTEGRAL_TYPE_P (type) || TYPE_OVERFLOW_UNDEFINED (type))
> && TREE_CODE (op0) == NEGATE_EXPR
> && negate_expr_p (op1))
>   {
> -   if (INTEGRAL_TYPE_P (type))
> +   if (ANY_INTEGRAL_TYPE_P (type))
>   fold_overflow_warning (("assuming signed overflow does not occur "
>   "when distributing negation across "
>   "division"),
> @@ -11162,11 +11162,11 @@ fold_binary_loc (location_t loc, enum tr
>   TREE_OPERAND (arg0, 0)),
> negate_expr (op1));
>   }
> -  if ((!INTEGRAL_TYPE_P (type) || TYPE_OVERFLOW_UNDEFINED (type))
> +  if ((!ANY_INTEGRAL_TYPE_P (type) || TYPE_OVERFLOW_UNDEFINED (type))
> && TREE_CODE (arg1) == NEGATE_EXPR
> && negate_expr_p (op0))
>   {
> -   if (INTEGRAL_TYPE_P (type))
> +   if (ANY_INTEGRAL_TYPE_P (type))
>   fold_overflow_warning (("assuming signed overflow does not occur "
>   "when distributing negation across "
>   "division"),
> --- gcc/testsuite/gcc.c-torture/execute/pr94412.c.jj  2020-03-30 
> 23:12:17.499118691 +0200
> +++ gcc/testsuite/gcc.c-torture/execute/pr94412.c 2020-03-30 
> 23:12:00.701367149 +0200
> @@ -0,0 +1,28 @@
> +/* PR middle-end/94412 */
> +
> +typedef unsigned V __attribute__ ((__vector_size__ (sizeof (unsigned) * 2)));
> +
> +void
> +foo (V *v, V *w)
> +{
> +  *w = -*v / 11;
> +}
> +
> +void
> +bar (V *v, V *w)
> +{
> +  *w = -18 / -*v;
> +}
> +
> +int
> +main ()
> +{
> +  V a = (V) { 1, 0 };
> +  V b = (V) { 3, __INT_MAX__ };
> +  V c, d;
> +  foo (, );
> +  bar (, );
> +  if (c[0] != -1U / 11 || c[1] != 0 || d[0] != 0 || d[1] != -18U / 
> -__INT_MAX__)
> +__builtin_abort ();
> +  return 0;
> +}
> 
>   Jakub
> 
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)

Re: [PATCH] forwprop: Pattern recognize more rotates [PR94344]

[Richard Biener]

On Tue, 31 Mar 2020, Jakub Jelinek wrote:

> Hi!
> 
> The following patch adjusts simplify_rotate to recognize more rotates,
> basically we allow even some same precision integral -> integral
> conversions, with the requirement that the RSHIFT_EXPR operand has to be
> done in unsigned type (i.e. logical right shift), so that we compensate for
> the combiner no longer being able to simplify those into rotates on some
> targets.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

OK.

Thanks,
Richard.

> 2020-03-31  Jakub Jelinek  
> 
>   PR rtl-optimization/94344
>   * tree-ssa-forwprop.c (simplify_rotate): Handle also same precision
>   conversions, either on both operands of |^+ or just one.  Handle
>   also extra same precision conversion on RSHIFT_EXPR first operand
>   provided RSHIFT_EXPR is performed in unsigned type.
> 
>   * gcc.dg/pr94344.c: New test.
> 
> --- gcc/tree-ssa-forwprop.c.jj2020-03-23 19:43:00.309774530 +0100
> +++ gcc/tree-ssa-forwprop.c   2020-03-30 14:50:16.303668479 +0200
> @@ -1562,14 +1562,14 @@ simplify_rotate (gimple_stmt_iterator *g
>for (i = 0; i < 2; i++)
>  defcodefor_name (arg[i], _code[i], _arg1[i], _arg2[i]);
>  
> -  /* Look through narrowing conversions.  */
> +  /* Look through narrowing (or same precision) conversions.  */
>if (CONVERT_EXPR_CODE_P (def_code[0])
>&& CONVERT_EXPR_CODE_P (def_code[1])
>&& INTEGRAL_TYPE_P (TREE_TYPE (def_arg1[0]))
>&& INTEGRAL_TYPE_P (TREE_TYPE (def_arg1[1]))
>&& TYPE_PRECISION (TREE_TYPE (def_arg1[0]))
>== TYPE_PRECISION (TREE_TYPE (def_arg1[1]))
> -  && TYPE_PRECISION (TREE_TYPE (def_arg1[0])) > TYPE_PRECISION (rtype)
> +  && TYPE_PRECISION (TREE_TYPE (def_arg1[0])) >= TYPE_PRECISION (rtype)
>&& has_single_use (arg[0])
>&& has_single_use (arg[1]))
>  {
> @@ -1579,6 +1579,21 @@ simplify_rotate (gimple_stmt_iterator *g
> defcodefor_name (arg[i], _code[i], _arg1[i], _arg2[i]);
>   }
>  }
> +  else
> +{
> +  /* Handle signed rotate; the RSHIFT_EXPR has to be done
> +  in unsigned type but LSHIFT_EXPR could be signed.  */
> +  i = (def_code[0] == LSHIFT_EXPR || def_code[0] == RSHIFT_EXPR);
> +  if (CONVERT_EXPR_CODE_P (def_code[i])
> +   && (def_code[1 - i] == LSHIFT_EXPR || def_code[1 - i] == RSHIFT_EXPR)
> +   && INTEGRAL_TYPE_P (TREE_TYPE (def_arg1[i]))
> +   && TYPE_PRECISION (rtype) == TYPE_PRECISION (TREE_TYPE (def_arg1[i]))
> +   && has_single_use (arg[i]))
> + {
> +   arg[i] = def_arg1[i];
> +   defcodefor_name (arg[i], _code[i], _arg1[i], _arg2[i]);
> + }
> +}
>  
>/* One operand has to be LSHIFT_EXPR and one RSHIFT_EXPR.  */
>for (i = 0; i < 2; i++)
> @@ -1608,8 +1623,33 @@ simplify_rotate (gimple_stmt_iterator *g
>if (!operand_equal_for_phi_arg_p (def_arg1[0], def_arg1[1])
>|| !types_compatible_p (TREE_TYPE (def_arg1[0]),
> TREE_TYPE (def_arg1[1])))
> -return false;
> -  if (!TYPE_UNSIGNED (TREE_TYPE (def_arg1[0])))
> +{
> +  if ((TYPE_PRECISION (TREE_TYPE (def_arg1[0]))
> +!= TYPE_PRECISION (TREE_TYPE (def_arg1[1])))
> +   || (TYPE_UNSIGNED (TREE_TYPE (def_arg1[0]))
> +   == TYPE_UNSIGNED (TREE_TYPE (def_arg1[1]
> + return false;
> +
> +  /* Handle signed rotate; the RSHIFT_EXPR has to be done
> +  in unsigned type but LSHIFT_EXPR could be signed.  */
> +  i = def_code[0] != RSHIFT_EXPR;
> +  if (!TYPE_UNSIGNED (TREE_TYPE (def_arg1[i])))
> + return false;
> +
> +  tree tem;
> +  enum tree_code code;
> +  defcodefor_name (def_arg1[i], , , NULL);
> +  if (!CONVERT_EXPR_CODE_P (code)
> +   || !INTEGRAL_TYPE_P (TREE_TYPE (tem))
> +   || TYPE_PRECISION (TREE_TYPE (tem)) != TYPE_PRECISION (rtype))
> + return false;
> +  def_arg1[i] = tem;
> +  if (!operand_equal_for_phi_arg_p (def_arg1[0], def_arg1[1])
> +   || !types_compatible_p (TREE_TYPE (def_arg1[0]),
> +   TREE_TYPE (def_arg1[1])))
> + return false;
> +}
> +  else if (!TYPE_UNSIGNED (TREE_TYPE (def_arg1[0])))
>  return false;
>  
>/* CNT1 + CNT2 == B case above.  */
> --- gcc/testsuite/gcc.dg/pr94344.c.jj 2020-03-30 14:49:53.005016600 +0200
> +++ gcc/testsuite/gcc.dg/pr94344.c2020-03-30 14:47:41.495981569 +0200
> @@ -0,0 +1,53 @@
> +/* PR rtl-optimization/94344 */
> +/* { dg-do compile { target { ilp32 || lp64 } } } */
> +/* { dg-options "-O2 -fdump-tree-forwprop1" } */
> +/* { dg-final { scan-tree-dump-times " r>> 27;" 4 "forwprop1" } } */
> +/* { dg-final { scan-tree-dump-times " r>> 59;" 4 "forwprop1" } } */
> +
> +int
> +f1 (int x)
> +{
> +  return (x << 5) | (int)((unsigned int)x >> 27);
> +}
> +
> +unsigned int
> +f2 (int x)
> +{
> +  return (x << 5) | ((unsigned int)x >> 27);
> +}
> +
> +long long int
> +f3 (long long int x)
> +{
> +  return (x << 5) | (long long 

RE: [PATCH] ICE: in vectorizable_load, at tree-vect-stmts.c:9173

[Yangfei (Felix)]

Hi!

> -Original Message-
> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
> Sent: Monday, March 30, 2020 8:08 PM
> To: Yangfei (Felix) 
> Cc: gcc-patches@gcc.gnu.org; rguent...@suse.de
> Subject: Re: [PATCH] ICE: in vectorizable_load, at tree-vect-stmts.c:9173
> 
> "Yangfei (Felix)"  writes:
> > Hi!
> >> -Original Message-
> >> From: Yangfei (Felix)
> >> Sent: Monday, March 30, 2020 5:28 PM
> >> To: gcc-patches@gcc.gnu.org
> >> Cc: 'rguent...@suse.de' 
> >> Subject: [PATCH] ICE: in vectorizable_load, at tree-vect-stmts.c:9173
> >>
> >> Hi,
> >>
> >> New bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94398
> >>
> >> With -mstrict-align, aarch64_builtin_support_vector_misalignment will
> >> returns false when misalignment factor is unknown at compile time.
> >> Then vect_supportable_dr_alignment returns dr_unaligned_unsupported,
> >> which triggers the ICE.  I have pasted the call trace on the bug report.
> >>
> >> vect_supportable_dr_alignment is expected to return either dr_aligned
> >> or dr_unaligned_supported for masked operations.
> >> But it seems that this function only catches internal_fn
> >> IFN_MASK_LOAD & IFN_MASK_STORE.
> >> We are emitting a mask gather load here for this test case.
> >> As backends have their own vector misalignment support policy, I am
> >> supposing this should be better handled in the auto-vect shared code.
> >>
> >
> > I can only reply to comment on the bug here as my account got locked by the
> bugzilla system for now.
> 
> Sorry to hear that.  What was the reason?

Looks like it got filtered by spamassassin.  Admin has helped unlocked it.  

> > The way Richard (rsandifo) suggests also works for me and I agree it should
> be more consistent and better for compile time.
> > One question here: when will a IFN_MASK_LOAD/IFN_MASK_STORE be
> passed to vect_supportable_dr_alignment?
> 
> I'd expect that to happen in the same cases as for unmasked load/stores.
> It certainly will for unconditional loads and stores that get masked via 
> full-loop
> masking.
> 
> In principle, the same rules apply to both masked and unmasked accesses.
> But for SVE, both masked and unmasked accesses should support misalignment,
> which is why I think the current target hook is probably wrong for SVE +
> -mstrict-align.

I stopped looking into the backend further when I saw no distinction for 
different type of access
in the target hook aarch64_builtin_support_vector_misalignment. 

> > @@ -8051,8 +8051,15 @@ vectorizable_store (stmt_vec_info stmt_info,
> gimple_stmt_iterator *gsi,
> >auto_vec dr_chain (group_size);
> >oprnds.create (group_size);
> >
> > -  alignment_support_scheme
> > -= vect_supportable_dr_alignment (first_dr_info, false);
> > +  /* Strided accesses perform only component accesses, alignment
> > + is irrelevant for them.  */
> > +  if (STMT_VINFO_STRIDED_P (first_dr_info->stmt)
> > +  && !STMT_VINFO_GROUPED_ACCESS (first_dr_info->stmt))
> 
> I think this should be based on memory_access_type ==
> VMAT_GATHER_SCATTER instead.  At this point, STMT_VINFO_* describes
> properties of the original scalar access(es) while memory_access_type
> describes the vector implementation strategy.  It's the latter that matters
> here.
> 
> Same thing for loads.

Yes, I have modified accordingly.  Attached please find the adapted patch.  
Bootstrapped and tested on aarch64-linux-gnu.  Newly add test will fail without 
the patch and pass otherwise.  
I think I need a sponsor if this patch can go separately.  

Thanks,
Felix


pr94398-v1.patch
Description: pr94398-v1.patch

[PATCH v3] Fix alignment for local variable [PR90811]

[Kito Cheng]

 - The alignment for local variable was adjust during estimate_stack_frame_size,
   however it seems wrong spot to adjust that, expand phase will adjust that
   but it little too late to some gimple optimization, which rely on certain
   target hooks need to check alignment, forwprop is an example for
   that, result of simplify_builtin_call rely on the alignment on some
   target like ARM or RISC-V.

 - This patch fix gfortran.dg/pr45636.f90 for arm and riscv.

 - Regression test on riscv32/riscv64 and x86_64-linux-gnu, no new fail
   introduced.

gcc/ChangeLog

PR target/90811
* Makefile.in (OBJS): Add tree-adjust-alignment.o.
* tree-adjust-alignment.cc (pass_data_adjust_alignment): New.
(pass_adjust_alignment): New.
(-pass_adjust_alignment::execute): New.
(make_pass_adjust_alignment): New.
* tree-pass.h (make_pass_adjust_alignment): New.
* passes.def: Add pass_adjust_alignment.
---
 gcc/Makefile.in  |  1 +
 gcc/passes.def   |  1 +
 gcc/tree-adjust-alignment.cc | 88 
 gcc/tree-pass.h  |  1 +
 4 files changed, 91 insertions(+)
 create mode 100644 gcc/tree-adjust-alignment.cc

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index fa9923bb270..9b73288f776 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1545,6 +1545,7 @@ OBJS = \
ubsan.o \
sanopt.o \
sancov.o \
+   tree-adjust-alignment.o \
tree-call-cdce.o \
tree-cfg.o \
tree-cfgcleanup.o \
diff --git a/gcc/passes.def b/gcc/passes.def
index 2bf2cb78fc5..92cbe587a8a 100644
--- a/gcc/passes.def
+++ b/gcc/passes.def
@@ -183,6 +183,7 @@ along with GCC; see the file COPYING3.  If not see
   NEXT_PASS (pass_oacc_device_lower);
   NEXT_PASS (pass_omp_device_lower);
   NEXT_PASS (pass_omp_target_link);
+  NEXT_PASS (pass_adjust_alignment);
   NEXT_PASS (pass_all_optimizations);
   PUSH_INSERT_PASSES_WITHIN (pass_all_optimizations)
   NEXT_PASS (pass_remove_cgraph_callee_edges);
diff --git a/gcc/tree-adjust-alignment.cc b/gcc/tree-adjust-alignment.cc
new file mode 100644
index 000..1269f93e56a
--- /dev/null
+++ b/gcc/tree-adjust-alignment.cc
@@ -0,0 +1,88 @@
+/* Adjust alignment for local variable.
+   Copyright (C) 2003-2020 Free Software Foundation, Inc.
+   Contributed by Dorit Naishlos 
+
+This file is part of GCC.
+
+GCC 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.
+
+GCC 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 GCC; see the file COPYING3.  If not see
+.  */
+
+#include "config.h"
+#include "system.h"
+#include "coretypes.h"
+#include "backend.h"
+#include "target.h"
+#include "tree.h"
+#include "gimple.h"
+#include "tree-pass.h"
+#include "cgraph.h"
+#include "fold-const.h"
+#include "gimple-iterator.h"
+#include "tree-cfg.h"
+#include "cfgloop.h"
+#include "tree-vectorizer.h"
+#include "tm_p.h"
+
+namespace {
+
+const pass_data pass_data_adjust_alignment =
+{
+  GIMPLE_PASS, /* type */
+  "adjust_alignment", /* name */
+  OPTGROUP_NONE, /* optinfo_flags */
+  TV_NONE, /* tv_id */
+  0, /* properties_required */
+  0, /* properties_provided */
+  0, /* properties_destroyed */
+  0, /* todo_flags_start */
+  0, /* todo_flags_finish */
+};
+
+class pass_adjust_alignment : public gimple_opt_pass
+{
+public:
+  pass_adjust_alignment (gcc::context *ctxt)
+: gimple_opt_pass (pass_data_adjust_alignment, ctxt)
+  {}
+
+  virtual unsigned int execute (function *);
+
+}; // class pass_adjust_alignment
+
+} // anon namespace
+
+/* Entry point to adjust_alignment pass.  */
+unsigned int
+pass_adjust_alignment::execute (function *fun) {
+  size_t i;
+  tree var;
+  struct cgraph_node *node;
+  unsigned int align;
+
+  FOR_EACH_LOCAL_DECL (fun, i, var)
+{
+  align = LOCAL_DECL_ALIGNMENT (var);
+
+  gcc_assert (align >= DECL_ALIGN (var));
+
+  SET_DECL_ALIGN (var, align);
+}
+  return 0;
+}
+
+gimple_opt_pass *
+make_pass_adjust_alignment (gcc::context *ctxt)
+{
+  return new pass_adjust_alignment (ctxt);
+}
diff --git a/gcc/tree-pass.h b/gcc/tree-pass.h
index a1207a20a3c..576b3f67434 100644
--- a/gcc/tree-pass.h
+++ b/gcc/tree-pass.h
@@ -480,6 +480,7 @@ extern gimple_opt_pass *make_pass_sprintf_length 
(gcc::context *ctxt);
 extern gimple_opt_pass *make_pass_walloca (gcc::context *ctxt);
 extern gimple_opt_pass *make_pass_coroutine_lower_builtins (gcc::context 
*ctxt);
 extern gimple_opt_pass *make_pass_coroutine_early_expand_ifns (gcc::context 
*ctxt);
+extern gimple_opt_pass 

Re: [PATCH 2/2] [aarch64] Rework fpcr fpsr getter/setter builtins

[Andrea Corallo]

Richard Earnshaw  writes:

> On 17/03/2020 12:34, Wilco Dijkstra wrote:
>> Hi Andrea,
>> I think the first part is fine when approved, but the 2nd part is
>> problematic like Szabolcs
>> already pointed out. We can't just change the ABI or semantics, and these 
>> builtins are critical
>> for GLIBC performance. We would first need to change GLIBC back to using 
>> inline assembler
>> so it will still write zeroes in the top 32 bits (since that is the current 
>> ABI).
>> Cheers,
>> Wilco
>> 
>
> No, you shouldn't ever arbitrarily write zeros to the upper bits (or
> even worse, write garbage as we do now).  That's the whole point of 
> these patches.
>
> R.

Hi Richard,

FWIW I agree with you but, what should we do now?  Shall I push the
first patch at least?

Thanks

  Andrea

[PATCH] fold-const: Fix division folding with vector operands [PR94412]

[Jakub Jelinek via Gcc-patches]

Hi!

The following testcase is miscompiled since 4.9, we treat unsigned
vector types as if they were signed and "optimize" negations across it.

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?

2020-03-31  Marc Glisse  
Jakub Jelinek  

PR middle-end/94412
* fold-const.c (fold_binary_loc) : Use
ANY_INTEGRAL_TYPE_P instead of INTEGRAL_TYPE_P.

* gcc.c-torture/execute/pr94412.c: New test.

--- gcc/fold-const.c.jj 2020-03-19 10:23:34.106114042 +0100
+++ gcc/fold-const.c2020-03-30 23:00:32.273551465 +0200
@@ -11148,11 +11148,11 @@ fold_binary_loc (location_t loc, enum tr
 
   /* Convert -A / -B to A / B when the type is signed and overflow is
 undefined.  */
-  if ((!INTEGRAL_TYPE_P (type) || TYPE_OVERFLOW_UNDEFINED (type))
+  if ((!ANY_INTEGRAL_TYPE_P (type) || TYPE_OVERFLOW_UNDEFINED (type))
  && TREE_CODE (op0) == NEGATE_EXPR
  && negate_expr_p (op1))
{
- if (INTEGRAL_TYPE_P (type))
+ if (ANY_INTEGRAL_TYPE_P (type))
fold_overflow_warning (("assuming signed overflow does not occur "
"when distributing negation across "
"division"),
@@ -11162,11 +11162,11 @@ fold_binary_loc (location_t loc, enum tr
TREE_OPERAND (arg0, 0)),
  negate_expr (op1));
}
-  if ((!INTEGRAL_TYPE_P (type) || TYPE_OVERFLOW_UNDEFINED (type))
+  if ((!ANY_INTEGRAL_TYPE_P (type) || TYPE_OVERFLOW_UNDEFINED (type))
  && TREE_CODE (arg1) == NEGATE_EXPR
  && negate_expr_p (op0))
{
- if (INTEGRAL_TYPE_P (type))
+ if (ANY_INTEGRAL_TYPE_P (type))
fold_overflow_warning (("assuming signed overflow does not occur "
"when distributing negation across "
"division"),
--- gcc/testsuite/gcc.c-torture/execute/pr94412.c.jj2020-03-30 
23:12:17.499118691 +0200
+++ gcc/testsuite/gcc.c-torture/execute/pr94412.c   2020-03-30 
23:12:00.701367149 +0200
@@ -0,0 +1,28 @@
+/* PR middle-end/94412 */
+
+typedef unsigned V __attribute__ ((__vector_size__ (sizeof (unsigned) * 2)));
+
+void
+foo (V *v, V *w)
+{
+  *w = -*v / 11;
+}
+
+void
+bar (V *v, V *w)
+{
+  *w = -18 / -*v;
+}
+
+int
+main ()
+{
+  V a = (V) { 1, 0 };
+  V b = (V) { 3, __INT_MAX__ };
+  V c, d;
+  foo (, );
+  bar (, );
+  if (c[0] != -1U / 11 || c[1] != 0 || d[0] != 0 || d[1] != -18U / 
-__INT_MAX__)
+__builtin_abort ();
+  return 0;
+}

Jakub

[PATCH] store-merging: Allow enums during bswap recognition [PR94403]

[Jakub Jelinek via Gcc-patches]

Hi!

The following testcase is optimized with char/unsigned char/signed char,
but not with std::byte.  The following patch fixes that.  Didn't use
INTEGRAL_TYPE_P because bswapping bools is just too weird.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for GCC11 (or is
it simple enough that we want it in GCC10 already)?

2020-03-31  Jakub Jelinek  

PR tree-optimization/94403
* gimple-ssa-store-merging.c (verify_symbolic_number_p): Allow also
ENUMERAL_TYPE lhs_type.

* g++.dg/tree-ssa/pr94403.C: New test.

--- gcc/gimple-ssa-store-merging.c.jj   2020-03-20 09:33:03.602112329 +0100
+++ gcc/gimple-ssa-store-merging.c  2020-03-30 18:30:31.723341519 +0200
@@ -315,7 +315,8 @@ verify_symbolic_number_p (struct symboli
 
   lhs_type = gimple_expr_type (stmt);
 
-  if (TREE_CODE (lhs_type) != INTEGER_TYPE)
+  if (TREE_CODE (lhs_type) != INTEGER_TYPE
+  && TREE_CODE (lhs_type) != ENUMERAL_TYPE)
 return false;
 
   if (TYPE_PRECISION (lhs_type) != TYPE_PRECISION (n->type))
--- gcc/testsuite/g++.dg/tree-ssa/pr94403.C.jj  2020-03-30 18:42:28.563719010 
+0200
+++ gcc/testsuite/g++.dg/tree-ssa/pr94403.C 2020-03-30 18:51:21.135828389 
+0200
@@ -0,0 +1,37 @@
+// PR tree-optimization/94403
+// Only test on some 64-bit targets which do have bswap{si,di}2 patterns and
+// are either big or little endian (not pdp endian).
+// { dg-do compile { target { lp64 && { i?86-*-* x86_64-*-* powerpc*-*-* 
aarch64*-*-* } } } }
+// { dg-require-effective-target store_merge }
+// { dg-options "-O2 -fdump-tree-store-merging -std=c++17" }
+
+namespace std {
+  template 
+  void swap (T& t1, T& t2) { T tmp (t1); t1 = t2; t2 = tmp; }
+  enum class byte : unsigned char {};
+}
+
+unsigned
+bswap32 (unsigned int x)
+{
+  unsigned int y = x;
+  std::byte *bytes = reinterpret_cast ();
+  std::swap (bytes[0], bytes[3]);
+  std::swap (bytes[1], bytes[2]);
+  return y;
+}
+
+unsigned long long
+bswap64 (unsigned long long x)
+{
+  unsigned long long y = x;
+  std::byte *bytes = reinterpret_cast ();
+  std::swap (bytes[0], bytes[7]);
+  std::swap (bytes[1], bytes[6]);
+  std::swap (bytes[2], bytes[5]);
+  std::swap (bytes[3], bytes[4]);
+  return y;
+}
+
+/* { dg-final { scan-tree-dump-times "__builtin_bswap64" 1 "store-merging" } } 
*/
+/* { dg-final { scan-tree-dump-times "__builtin_bswap32" 1 "store-merging" } } 
*/

Jakub

[PATCH] forwprop: Pattern recognize more rotates [PR94344]

[Jakub Jelinek via Gcc-patches]

Hi!

The following patch adjusts simplify_rotate to recognize more rotates,
basically we allow even some same precision integral -> integral
conversions, with the requirement that the RSHIFT_EXPR operand has to be
done in unsigned type (i.e. logical right shift), so that we compensate for
the combiner no longer being able to simplify those into rotates on some
targets.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2020-03-31  Jakub Jelinek  

PR rtl-optimization/94344
* tree-ssa-forwprop.c (simplify_rotate): Handle also same precision
conversions, either on both operands of |^+ or just one.  Handle
also extra same precision conversion on RSHIFT_EXPR first operand
provided RSHIFT_EXPR is performed in unsigned type.

* gcc.dg/pr94344.c: New test.

--- gcc/tree-ssa-forwprop.c.jj  2020-03-23 19:43:00.309774530 +0100
+++ gcc/tree-ssa-forwprop.c 2020-03-30 14:50:16.303668479 +0200
@@ -1562,14 +1562,14 @@ simplify_rotate (gimple_stmt_iterator *g
   for (i = 0; i < 2; i++)
 defcodefor_name (arg[i], _code[i], _arg1[i], _arg2[i]);
 
-  /* Look through narrowing conversions.  */
+  /* Look through narrowing (or same precision) conversions.  */
   if (CONVERT_EXPR_CODE_P (def_code[0])
   && CONVERT_EXPR_CODE_P (def_code[1])
   && INTEGRAL_TYPE_P (TREE_TYPE (def_arg1[0]))
   && INTEGRAL_TYPE_P (TREE_TYPE (def_arg1[1]))
   && TYPE_PRECISION (TREE_TYPE (def_arg1[0]))
 == TYPE_PRECISION (TREE_TYPE (def_arg1[1]))
-  && TYPE_PRECISION (TREE_TYPE (def_arg1[0])) > TYPE_PRECISION (rtype)
+  && TYPE_PRECISION (TREE_TYPE (def_arg1[0])) >= TYPE_PRECISION (rtype)
   && has_single_use (arg[0])
   && has_single_use (arg[1]))
 {
@@ -1579,6 +1579,21 @@ simplify_rotate (gimple_stmt_iterator *g
  defcodefor_name (arg[i], _code[i], _arg1[i], _arg2[i]);
}
 }
+  else
+{
+  /* Handle signed rotate; the RSHIFT_EXPR has to be done
+in unsigned type but LSHIFT_EXPR could be signed.  */
+  i = (def_code[0] == LSHIFT_EXPR || def_code[0] == RSHIFT_EXPR);
+  if (CONVERT_EXPR_CODE_P (def_code[i])
+ && (def_code[1 - i] == LSHIFT_EXPR || def_code[1 - i] == RSHIFT_EXPR)
+ && INTEGRAL_TYPE_P (TREE_TYPE (def_arg1[i]))
+ && TYPE_PRECISION (rtype) == TYPE_PRECISION (TREE_TYPE (def_arg1[i]))
+ && has_single_use (arg[i]))
+   {
+ arg[i] = def_arg1[i];
+ defcodefor_name (arg[i], _code[i], _arg1[i], _arg2[i]);
+   }
+}
 
   /* One operand has to be LSHIFT_EXPR and one RSHIFT_EXPR.  */
   for (i = 0; i < 2; i++)
@@ -1608,8 +1623,33 @@ simplify_rotate (gimple_stmt_iterator *g
   if (!operand_equal_for_phi_arg_p (def_arg1[0], def_arg1[1])
   || !types_compatible_p (TREE_TYPE (def_arg1[0]),
  TREE_TYPE (def_arg1[1])))
-return false;
-  if (!TYPE_UNSIGNED (TREE_TYPE (def_arg1[0])))
+{
+  if ((TYPE_PRECISION (TREE_TYPE (def_arg1[0]))
+  != TYPE_PRECISION (TREE_TYPE (def_arg1[1])))
+ || (TYPE_UNSIGNED (TREE_TYPE (def_arg1[0]))
+ == TYPE_UNSIGNED (TREE_TYPE (def_arg1[1]
+   return false;
+
+  /* Handle signed rotate; the RSHIFT_EXPR has to be done
+in unsigned type but LSHIFT_EXPR could be signed.  */
+  i = def_code[0] != RSHIFT_EXPR;
+  if (!TYPE_UNSIGNED (TREE_TYPE (def_arg1[i])))
+   return false;
+
+  tree tem;
+  enum tree_code code;
+  defcodefor_name (def_arg1[i], , , NULL);
+  if (!CONVERT_EXPR_CODE_P (code)
+ || !INTEGRAL_TYPE_P (TREE_TYPE (tem))
+ || TYPE_PRECISION (TREE_TYPE (tem)) != TYPE_PRECISION (rtype))
+   return false;
+  def_arg1[i] = tem;
+  if (!operand_equal_for_phi_arg_p (def_arg1[0], def_arg1[1])
+ || !types_compatible_p (TREE_TYPE (def_arg1[0]),
+ TREE_TYPE (def_arg1[1])))
+   return false;
+}
+  else if (!TYPE_UNSIGNED (TREE_TYPE (def_arg1[0])))
 return false;
 
   /* CNT1 + CNT2 == B case above.  */
--- gcc/testsuite/gcc.dg/pr94344.c.jj   2020-03-30 14:49:53.005016600 +0200
+++ gcc/testsuite/gcc.dg/pr94344.c  2020-03-30 14:47:41.495981569 +0200
@@ -0,0 +1,53 @@
+/* PR rtl-optimization/94344 */
+/* { dg-do compile { target { ilp32 || lp64 } } } */
+/* { dg-options "-O2 -fdump-tree-forwprop1" } */
+/* { dg-final { scan-tree-dump-times " r>> 27;" 4 "forwprop1" } } */
+/* { dg-final { scan-tree-dump-times " r>> 59;" 4 "forwprop1" } } */
+
+int
+f1 (int x)
+{
+  return (x << 5) | (int)((unsigned int)x >> 27);
+}
+
+unsigned int
+f2 (int x)
+{
+  return (x << 5) | ((unsigned int)x >> 27);
+}
+
+long long int
+f3 (long long int x)
+{
+  return (x << 5) | (long long int)((unsigned long long int)x >> 59);
+}
+
+unsigned long long int
+f4 (long long int x)
+{
+  return (x << 5) | ((unsigned long long int)x >> 59);
+}
+
+int
+f5 (int x)
+{
+  return (int)((unsigned int)x >> 27) | (x << 5);
+}
+
+unsigned int
+f6 (int x)
+{
+ 

Re: [PATCH V3][gcc] libgccjit: introduce version entry points

[Andrea Corallo]

David Malcolm  writes:

> Andrea: I've pushed my proposed fix for the above to master as
> 3809bcd6c0ee324cbd855c68cee104c8bf134dbe.  Does this fix the issue you
> were seeing?
>
> Thanks
> Dave

Hi,

yes super! I'll update the patch thanks.

  Andrea

[PATCH] combine: Fix split_i2i3 ICE [PR94291]

[Jakub Jelinek via Gcc-patches]

Hi!

The following testcase ICEs on armv7hl-linux-gnueabi.
try_combine is called on:
(gdb) p debug_rtx (i3)
(insn 20 12 22 2 (set (mem/c:SI (plus:SI (reg/f:SI 102 sfp)
(const_int -4 [0xfffc])) [1 x+0 S4 A32])
(reg:SI 125)) "pr94291.c":7:8 241 {*arm_movsi_insn}
 (expr_list:REG_DEAD (reg:SI 125)
(nil)))
(gdb) p debug_rtx (i2)
(insn 12 7 20 2 (parallel [
(set (reg:CC 100 cc)
(compare:CC (reg:SI 121 [  ])
(const_int 0 [0])))
(set (reg:SI 125)
(reg:SI 121 [  ]))
]) "pr94291.c":7:8 248 {*movsi_compare0}
 (expr_list:REG_UNUSED (reg:CC 100 cc)
(nil)))
and tries to recognize cc = r121 cmp 0; [sfp-4] = r121 parallel,
but that isn't recognized, so it splits it into two: split_i2i3
[sfp-4] = r121 followed by cc = r121 cmp 0 which is recognized, but
ICEs because the code below insist that the SET_DEST of newi2pat
(or first set in PARALLEL thereof) must be a REG or SUBREG of REG,
but it is a MEM in this case.  I don't see any condition that would
guarantee that, perhaps for the swap_i2i3 case it was somehow guaranteed.

As the code just wants to update LOG_LINKS and LOG_LINKS are only for
registers, not for MEM or anything else, the patch just doesn't update those
if it isn't a REG or SUBREG of REG.

Bootstrapped/regtested on armv7hl-linux-gnueabi and powerpc64le-linux, ok
for trunk?

2020-03-31  Jakub Jelinek  

PR rtl-optimization/94291
* combine.c (try_combine): For split_i2i3, don't assume SET_DEST
must be a REG or SUBREG of REG; if it is not one of these, don't
update LOG_LINKs.

* gcc.dg/pr94291.c: New test.

--- gcc/combine.c.jj2020-02-25 13:56:19.514076091 +0100
+++ gcc/combine.c   2020-03-30 17:23:17.579654895 +0200
@@ -4351,25 +4351,29 @@ try_combine (rtx_insn *i3, rtx_insn *i2,
   if (GET_CODE (x) == PARALLEL)
x = XVECEXP (newi2pat, 0, 0);
 
-  /* It can only be a SET of a REG or of a SUBREG of a REG.  */
-  unsigned int regno = reg_or_subregno (SET_DEST (x));
-
-  bool done = false;
-  for (rtx_insn *insn = NEXT_INSN (i3);
-  !done
-  && insn
-  && NONDEBUG_INSN_P (insn)
-  && BLOCK_FOR_INSN (insn) == this_basic_block;
-  insn = NEXT_INSN (insn))
+  if (REG_P (SET_DEST (x))
+ || (GET_CODE (SET_DEST (x)) == SUBREG
+ && REG_P (SUBREG_REG (SET_DEST (x)
{
- struct insn_link *link;
- FOR_EACH_LOG_LINK (link, insn)
-   if (link->insn == i3 && link->regno == regno)
- {
-   link->insn = i2;
-   done = true;
-   break;
- }
+ unsigned int regno = reg_or_subregno (SET_DEST (x));
+
+ bool done = false;
+ for (rtx_insn *insn = NEXT_INSN (i3);
+  !done
+  && insn
+  && NONDEBUG_INSN_P (insn)
+  && BLOCK_FOR_INSN (insn) == this_basic_block;
+  insn = NEXT_INSN (insn))
+   {
+ struct insn_link *link;
+ FOR_EACH_LOG_LINK (link, insn)
+   if (link->insn == i3 && link->regno == regno)
+ {
+   link->insn = i2;
+   done = true;
+   break;
+ }
+   }
}
 }
 
--- gcc/testsuite/gcc.dg/pr94291.c.jj   2020-03-30 17:22:47.876092906 +0200
+++ gcc/testsuite/gcc.dg/pr94291.c  2020-03-30 17:22:22.230471072 +0200
@@ -0,0 +1,14 @@
+/* PR rtl-optimization/94291 */
+/* { dg-do compile } */
+/* { dg-options "-Og" } */
+
+unsigned a;
+
+unsigned
+foo (void)
+{
+  unsigned x
+= (__builtin_sub_overflow ((long long) a, 0, )
+   ? 1 : (__INTPTR_TYPE__) __builtin_memmove (, foo, 1));
+  return a;
+}

Jakub

[PATCH] aarch64: Fix up aarch64_compare_and_swaphi pattern [PR94368]

[Jakub Jelinek via Gcc-patches]

Hi!

The following testcase ICEs in final_scan_insn_1.  The problem is in the
@aarch64_compare_and_swaphi define_insn_and_split, since 9 it uses
aarch64_plushi_operand predicate for the "expected value" operand, which
allows either 0..0xfff constants or 0x1000..0xf000 constants (i.e. HImode
values which when zero extended are either 0..0xfff or (0..0xfff) << 12).
The problem is that RA doesn't care about predicates, it honors just
constraints and the used constraint on the operand is n, which means any
HImode CONST_SCALAR_INT.  In the testcase LRA thus propagates the -1
value into the insn.
This is a define_insn_and_split which requires mandatory split.
But during split2 pass, we check the predicate (and don't check
constraints), which fails and thus we don't split it and during final ICE
because the mandatory splitting didn't happen.

The following patch fixes it by adding a matching constraint to the
predicate and using it.

Bootstrapped/regtested on aarch64-linux, ok for trunk?

2020-03-31  Jakub Jelinek  

PR target/94368
* config/aarch64/constraints.md (Uph): New constraint.
* config/aarch64/atomics.md (cas_short_expected_imm): New mode attr.
(@aarch64_compare_and_swap): Use it instead of n in operand 2's
constraint.

* gcc.dg/pr94368.c: New test.

--- gcc/config/aarch64/constraints.md.jj2020-01-17 19:35:54.101144322 
+0100
+++ gcc/config/aarch64/constraints.md   2020-03-30 11:39:29.554441681 +0200
@@ -233,6 +233,13 @@ (define_constraint "Up3"
   (and (match_code "const_int")
(match_test "(unsigned) exact_log2 (ival) <= 4")))
 
+(define_constraint "Uph"
+  "@internal
+  A constraint that matches HImode integers zero extendable to
+  SImode plus_operand."
+  (and (match_code "const_int")
+   (match_test "aarch64_plushi_immediate (op, VOIDmode)")))
+
 (define_memory_constraint "Q"
  "A memory address which uses a single base register with no offset."
  (and (match_code "mem")
--- gcc/config/aarch64/atomics.md.jj2020-01-17 14:46:41.464792827 +0100
+++ gcc/config/aarch64/atomics.md   2020-03-30 11:42:02.256180919 +0200
@@ -38,6 +38,8 @@ (define_expand "@atomic_compare_and_swap
 
 (define_mode_attr cas_short_expected_pred
   [(QI "aarch64_reg_or_imm") (HI "aarch64_plushi_operand")])
+(define_mode_attr cas_short_expected_imm
+  [(QI "n") (HI "Uph")])
 
 (define_insn_and_split "@aarch64_compare_and_swap"
   [(set (reg:CC CC_REGNUM) ;; bool out
@@ -47,7 +49,8 @@ (define_insn_and_split "@aarch64_compare
   (match_operand:SHORT 1 "aarch64_sync_memory_operand" "+Q"))) ;; memory
(set (match_dup 1)
 (unspec_volatile:SHORT
-  [(match_operand:SHORT 2 "" "rn");; 
expected
+  [(match_operand:SHORT 2 ""
+ "r")  ;; expected
(match_operand:SHORT 3 "aarch64_reg_or_zero" "rZ")  ;; desired
(match_operand:SI 4 "const_int_operand");; 
is_weak
(match_operand:SI 5 "const_int_operand");; mod_s
--- gcc/testsuite/gcc.dg/pr94368.c.jj   2020-03-30 11:47:18.573497812 +0200
+++ gcc/testsuite/gcc.dg/pr94368.c  2020-03-30 11:25:54.002642049 +0200
@@ -0,0 +1,25 @@
+/* PR target/94368 */
+/* { dg-do compile { target fpic } } */
+/* { dg-options "-fpic -O1 -fcommon" } */
+
+int b, c, d, e, f, h;
+short g;
+int foo (int) __attribute__ ((__const__));
+
+void
+bar (void)
+{
+  while (1)
+{
+  while (1)
+   {
+ __atomic_load_n (, 0);
+ if (foo (2))
+   __sync_val_compare_and_swap (, 0, f);
+ b = 1;
+ if (h == e)
+   break;
+   }
+  __sync_val_compare_and_swap (, -1, f);
+}
+}

Jakub