Re: [PATCH] Allow new/delete operator deletion only for replaceable.

[Martin Liška]

Hi.

We've got one another sneaky test-case (thank you Marc ;) ):

$ cat pr94314-array.C
#include 
#include 

int count = 0;

__attribute__((malloc, noinline)) void* operator new[](unsigned long sz) {
  ++count;
  return ::operator new(sz);
}

void operator delete[](void* ptr) noexcept {
  --count;
  ::operator delete(ptr);
}

void operator delete[](void* ptr, std::size_t sz) noexcept {
  --count;
  ::operator delete(ptr, sz);
}

int main() {
  delete[] new int[1];
  if (count != 0)
__builtin_abort ();
}

I bet we need to include the Honza's fix for inline stacks.
Or it the test-case invalid?

Thanks,
Martin

Re: [PATCH] c++: Fix wrong paren-init of aggregates interference [PR93790]

[Jason Merrill via Gcc-patches]

On 4/8/20 5:52 PM, Marek Polacek wrote:

This PR points out that we are rejecting valid code in C++20.  The
problem is that we were surreptitiously transforming

   T& t(e)

into

   T& t{e}

which is wrong, because the type of e had a conversion function to T,
while aggregate initialization of t from e doesn't work.  Therefore, I
was violating a design principle of P0960, which says that any existing
meaning of A(b) should not change.  So I think we should only attempt to
aggregate-initialize if the original expression was ill-formed.

Another design principle is that () should work where {} works, so this:

   struct S { int i; };
   const S& s(1);

has to keep working.  Thus the special handling for paren-lists with one
element.  (A paren-list with more than one element would give you "error:
expression list treated as compound expression in initializer" C++17.)

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?


OK.


PR c++/93790
* call.c (initialize_reference): If the reference binding failed, maybe
try initializing from { }.
* decl.c (grok_reference_init): For T& t(e), set
LOOKUP_AGGREGATE_PAREN_INIT but don't build up a constructor yet.

* g++.dg/cpp2a/paren-init23.C: New test.
* g++.dg/init/aggr14.C: New test.
---
  gcc/cp/call.c | 14 ++
  gcc/cp/decl.c | 19 ---
  gcc/testsuite/g++.dg/cpp2a/paren-init23.C | 19 +++
  gcc/testsuite/g++.dg/init/aggr14.C| 14 ++
  4 files changed, 63 insertions(+), 3 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/paren-init23.C
  create mode 100644 gcc/testsuite/g++.dg/init/aggr14.C

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 02220ffb3a1..1f3d9d23b5b 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -12196,6 +12196,20 @@ initialize_reference (tree type, tree expr,
  
conv = reference_binding (type, TREE_TYPE (expr), expr, /*c_cast_p=*/false,

flags, complain);
+  /* If this conversion failed, we're in C++20, and we have something like
+ A& a(b) where A is an aggregate, try again, this time as A& a{b}.  */
+  if ((!conv || conv->bad_p)
+  && (flags & LOOKUP_AGGREGATE_PAREN_INIT))
+{
+  tree e = build_constructor_single (init_list_type_node, NULL_TREE, expr);
+  CONSTRUCTOR_IS_DIRECT_INIT (e) = true;
+  CONSTRUCTOR_IS_PAREN_INIT (e) = true;
+  conversion *c = reference_binding (type, TREE_TYPE (e), e,
+/*c_cast_p=*/false, flags, complain);
+  /* If this worked, use it.  */
+  if (c && !c->bad_p)
+   expr = e, conv = c;
+}
if (!conv || conv->bad_p)
  {
if (complain & tf_error)
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index a6a1340e631..1447b89e692 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -5568,9 +5568,22 @@ grok_reference_init (tree decl, tree type, tree init, 
int flags)
  && !DECL_DECOMPOSITION_P (decl)
  && (cxx_dialect >= cxx2a))
{
- init = build_constructor_from_list (init_list_type_node, init);
- CONSTRUCTOR_IS_DIRECT_INIT (init) = true;
- CONSTRUCTOR_IS_PAREN_INIT (init) = true;
+ /* We don't know yet if we should treat const A& r(1) as
+const A& r{1}.  */
+ if (list_length (init) == 1)
+   {
+ flags |= LOOKUP_AGGREGATE_PAREN_INIT;
+ init = build_x_compound_expr_from_list (init, ELK_INIT,
+ tf_warning_or_error);
+   }
+ /* If the list had more than one element, the code is ill-formed
+pre-C++20, so we can build a constructor right away.  */
+ else
+   {
+ init = build_constructor_from_list (init_list_type_node, init);
+ CONSTRUCTOR_IS_DIRECT_INIT (init) = true;
+ CONSTRUCTOR_IS_PAREN_INIT (init) = true;
+   }
}
else
init = build_x_compound_expr_from_list (init, ELK_INIT,
diff --git a/gcc/testsuite/g++.dg/cpp2a/paren-init23.C 
b/gcc/testsuite/g++.dg/cpp2a/paren-init23.C
new file mode 100644
index 000..6038f63be5a
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/paren-init23.C
@@ -0,0 +1,19 @@
+// PR c++/93790 - wrong paren-init of aggregates interference.
+// { dg-do compile { target c++2a } }
+
+struct S {
+  int i;
+};
+const S& s(1);
+
+struct A {
+  int i;
+  A(int);
+};
+const A& a(1);
+
+struct B {
+  int i;
+  B(int) = delete;
+};
+const B& b(1); // { dg-error "use of deleted function" }
diff --git a/gcc/testsuite/g++.dg/init/aggr14.C 
b/gcc/testsuite/g++.dg/init/aggr14.C
new file mode 100644
index 000..538b467d467
--- /dev/null
+++ b/gcc/testsuite/g++.dg/init/aggr14.C
@@ -0,0 +1,14 @@
+// PR c++/93790 - wrong paren-init of aggregates interference.
+// { dg-do compile }
+
+struct S {};
+class S_refwrap {
+S& Sref_;
+public:
+

[committed, obvious] Require pthread effective target for test case using -pthread option.

[Sandra Loosemore]

I noticed g++.dg/tree-ssa/pr93940.C was giving an error on nios2-elf due 
to lack of support for the -pthread option on this bare-metal target.  I 
cut and pasted this fix from other existing testcases.  Committed as 
obvious.


-Sandra
commit fe1837143f1bf1d6b072a3973b00576ee17c30a9
Author: Sandra Loosemore 
Date:   Wed Apr 8 20:55:20 2020 -0700

Require pthread effective target for test case using -pthread option.

2020-04-08  Sandra Loosemore  

	gcc/testsuite/
	* g++.dg/tree-ssa/pr93940.C: Require pthread target.

diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index d597508..45e7005 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,7 @@
+2020-04-08  Sandra Loosemore  
+
+	* g++.dg/tree-ssa/pr93940.C: Require pthread target.
+
 2020-04-09  Kewen Lin  
 
 	PR testsuite/94079
diff --git a/gcc/testsuite/g++.dg/tree-ssa/pr93940.C b/gcc/testsuite/g++.dg/tree-ssa/pr93940.C
index b656aad..111b33e 100644
--- a/gcc/testsuite/g++.dg/tree-ssa/pr93940.C
+++ b/gcc/testsuite/g++.dg/tree-ssa/pr93940.C
@@ -1,4 +1,5 @@
 /* { dg-do compile } */
+/* { dg-require-effective-target pthread } */
 /* { dg-options "-Og --coverage -pthread -fdump-tree-optimized -std=c++17" } */
 using uint16_t = unsigned short;
 

Re: [PATCH PR93674]Avoid introducing IV of enumeral type in case of -fstrict-enums

[bin.cheng via Gcc-patches]

--
Sender:Richard Biener 
Sent At:2020 Mar. 20 (Fri.) 18:12
Recipient:bin.cheng 
Cc:Andrew Pinski ; GCC Patches 
Subject:Re: [PATCH PR93674]Avoid introducing IV of enumeral type in case of 
-fstrict-enums


On Fri, Mar 20, 2020 at 10:27 AM bin.cheng  wrote:
>
> --
> Sender:Richard Biener 
> Sent At:2020 Mar. 3 (Tue.) 17:36
> Recipient:Andrew Pinski 
> Cc:bin.cheng ; GCC Patches 
> 
> Subject:Re: [PATCH PR93674]Avoid introducing IV of enumeral type in case of 
> -fstrict-enums
>
>
> On Mon, Mar 2, 2020 at 6:14 PM Andrew Pinski  wrote:
> >
> > On Mon, Mar 2, 2020 at 1:40 AM Richard Biener
> >  wrote:
> > >
> > > On Mon, Mar 2, 2020 at 9:07 AM bin.cheng  
> > > wrote:
> > > >
> > > > Hi,
> > > > This is a simple fix for PR93674.  It adds cand carefully for enumeral 
> > > > type iv_use in
> > > > case of -fstrict-enums, it also avoids computing, replacing iv_use with 
> > > > the candidate
> > > > so that no IV of enumeral type is introduced with -fstrict-enums option.
> > > >
> > > > Testcase is also added.  Bootstrap and test on x86_64.  Any comment?
> > >
> > > I think we should avoid enum-typed (or bool-typed) IVs in general, not 
> > > just
> > > with -fstrict-enums.  That said, the ENUMERAL_TYPE checks should be
> > > !(INTEGER_TYPE || POINTER_TYPE_P) checks.
> >
> > Maybe even check type_has_mode_precision_p or
> > TYPE_MIN_VALUE/TYPE_MAX_VALUE have the same as the min/max for that
> > precision/signedness.
>
> Indeed we don't want non-mode precision INTEGER_TYPE IVs either.  I wouldn't
> check TYPE_MIN/MAX_VALUE here though.
>
> Here is the updated patch with more checks.  I also removed the 
> computation/elimination part for now.

+  if ((TREE_CODE (basetype) != INTEGER_TYPE && !POINTER_TYPE_P (basetype))
+  || !type_has_mode_precision_p (basetype))
+{
+  if (!CONVERT_EXPR_P (iv->base))
+   return;
+
+  /* Specially handle such iv_use if it's converted from other ones by
+adding candidate for the source iv.  */
+  base = TREE_OPERAND (iv->base, 0);
+  basetype = TREE_TYPE (base);
+  if (!INTEGRAL_TYPE_P (basetype))
+   return;

I think this is too lax - you'll happily add another non-INTEGER_TYPE
or non-mode-precision IV through this handling.  If the conversion
is not value-preserving the IV may also be useless (also the step
might see truncation in its type adjustment).  With a widening
conversion there's the issue with different wrap-around behavior.
I guess in most cases we'll not be able to use the IV if it is "bogus"
so all this might be harmless.

The original idea is to depend on the condition that the result won't be a 
legal IV in
case of widening.  For narrowing, it won't be a problem except what you 
mentioned
about non-INTEGER_TYPE or non-mode-precision issue.

Was there any reason to handle this special case?  Why not simply
do sth like
The reason is to strength reduce (conversion) operation in RHS by introducing 
appropriate
candidate.
And right, your proposed code looks better and more general.

+  if ((TREE_CODE (basetype) != INTEGER_TYPE && !POINTER_TYPE_P (basetype)))
+  || !type_has_mode_precision_p (basetype))
+{
 basetype = lang_hooks.type_for_mode (TYPE_MODE (basetype),
TYPE_UNSIGNED (basetype));
 tree step = fold_convert (basetype, iv->step);
 add_candidate (...);

?

The following also looks bogus:

+  if (basetype == generic_type_for (basetype))
+   step = fold_convert (basetype, step);

don't we add IVs in generic_type_for () and thus the conversion is
always necessary
anyways?  (it has the wrong type from the conversion we just stripped)

This is now discarded.
Patch updated and tested on x86_64.  Is it OK?

Thanks,
bin

2020-04-09  Bin Cheng  
Richard Biener  

PR tree-optimization/93674
* tree-ssa-loop-ivopts.c (langhooks.h): New include.
(add_iv_candidate_for_use): For iv_use of non integer or pointer type,
or non-mode precision type, add candidate in unsigned type with the
same precision.

gcc/testsuite
2020-04-09  Bin Cheng  

PR tree-optimization/93674
* g++.dg/pr93674.C: New test.

0001-Add-unsigned-type-iv_cand-for-iv_use-with-non-mode-p.patch
Description: Binary data

[PATCH] c++: Stray RESULT_DECLs in result of constexpr function call [PR94034]

[Patrick Palka via Gcc-patches]

When evaluating the initializer of 'a' in the following example

  struct A { A *p = this; };
  constexpr A foo() { return {}; }
  constexpr A a = foo();

the PLACEHOLDER_EXPR for 'this' in the aggregate initializer returned by foo
gets resolved to the RESULT_DECL of foo.  But due to guaranteed RVO, the 'this'
should really be resolved to ''.

It seems to me that the right approach would be to immediately resolve the
PLACEHOLDER_EXPR to the correct target object during evaluation of 'foo()', so
that we could use 'this' to access objects adjacent to the current object in the
ultimate storage location.  (I think #c2 of PR c++/94537 is an example of such
usage of 'this', which currently doesn't work.  But as #c1 shows we don't seem
to handle this case correctly in non-constexpr initialization either.)

I haven't yet been able to make a solution using the above approach work --
making sure we use the ultimate object instead of the RESULT_DECL whenever we
access ctx->global->values is proving to be tricky and subtle.

As a simpler stopgap solution, this patch fixes this stray RESULT_DECL issue by
replacing all occurrences of the RESULT_DECL in the result of a constexpr
function call with the current object under construction.  This doesn't allow
one to access adjacent objects using the 'this' pointer, but besides that it
seems functionally equivalent to the above approach.

Is this stopgap solution adequate, or should I continue working on a more
correct approach?

This patch passes "make check-c++", and a full bootstrap/regtest is in progress.

gcc/cp/ChangeLog:

PR c++/94034
* constexpr.c (replace_result_decl_data): New struct.
(replace_result_decl_data_r): New function.
(replace_result_decl): New function.
(cxx_eval_call_expression): Rename local variable 'res' to
'result_decl' and move its declaration to an outer scope.  Use
replace_result_decl.

gcc/testsuite/ChangeLog:

PR c++/94034
* g++.dg/cpp1y/constexpr-nsdmi7.C: New test.
* g++.dg/cpp1y/constexpr-nsdmi8.C: New test.
---
 gcc/cp/constexpr.c| 68 +--
 gcc/testsuite/g++.dg/cpp1y/constexpr-nsdmi7.C | 21 ++
 gcc/testsuite/g++.dg/cpp1y/constexpr-nsdmi8.C | 45 
 3 files changed, 127 insertions(+), 7 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp1y/constexpr-nsdmi7.C
 create mode 100644 gcc/testsuite/g++.dg/cpp1y/constexpr-nsdmi8.C

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index 96497ab85d7..c011f2c7722 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -2029,6 +2029,50 @@ cxx_eval_dynamic_cast_fn (const constexpr_ctx *ctx, tree 
call,
   return cp_build_addr_expr (obj, complain);
 }
 
+/* Data structure used by replace_result_decl and replace_result_decl_r.  */
+
+struct replace_result_decl_data
+{
+  /* The RESULT_DECL we want to replace.  */
+  tree decl;
+  /* What we're replacing every occurrence of DECL with.  */
+  tree to;
+  /* Whether we've performed any replacements.  */
+  bool changed;
+};
+
+/* Helper function for replace_result_decl, called through cp_walk_tree.  */
+
+static tree
+replace_result_decl_r (tree *tp, int *walk_subtrees, void *data)
+{
+  replace_result_decl_data *d = (replace_result_decl_data *) data;
+
+  if (*tp == d->decl)
+{
+  *tp = unshare_expr (d->to);
+  d->changed = true;
+}
+  else if (TYPE_P (*tp))
+*walk_subtrees = 0;
+
+  return NULL_TREE;
+}
+
+/* Replace every occurrence of DECL, a RESULT_DECL, with (an unshared copy of)
+   TO within *TP.  Returns true iff a replacement was performed.  */
+
+static bool
+replace_result_decl (tree *tp, tree decl, tree to)
+{
+  gcc_assert (TREE_CODE (decl) == RESULT_DECL
+ && same_type_ignoring_top_level_qualifiers_p (TREE_TYPE (decl),
+   TREE_TYPE (to)));
+  replace_result_decl_data data = { decl, to, false };
+  cp_walk_tree_without_duplicates (tp, replace_result_decl_r, );
+  return data.changed;
+}
+
 /* Subroutine of cxx_eval_constant_expression.
Evaluate the call expression tree T in the context of OLD_CALL expression
evaluation.  */
@@ -2381,6 +2425,7 @@ cxx_eval_call_expression (const constexpr_ctx *ctx, tree 
t,
 }
   else
 {
+  tree result_decl = NULL_TREE;
   bool cacheable = true;
   if (result && result != error_mark_node)
/* OK */;
@@ -2395,13 +2440,13 @@ cxx_eval_call_expression (const constexpr_ctx *ctx, 
tree t,
}
   else if (tree copy = get_fundef_copy (ctx, new_call.fundef))
{
- tree body, parms, res;
+ tree body, parms;
  releasing_vec ctors;
 
  /* Reuse or create a new unshared copy of this function's body.  */
  body = TREE_PURPOSE (copy);
  parms = TREE_VALUE (copy);
- res = TREE_TYPE (copy);
+ result_decl = TREE_TYPE (copy);
 
  /* Associate the bindings with the remapped 

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

[Vineet Gupta via Gcc-patches]

Hi Claudiu,

For glibc needs can this be backported to gcc-9 please !

Thx,
-Vineet

On 3/31/20 3:06 AM, Claudiu Zissulescu Ianculescu wrote:
> 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
>>
> ___
> 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=7FgpX6o3vAhwMrMhLh-4ZJey5kjdNUwOL2CWsFwR4T8=MrObyH2ki95_7m_xHpnWX-k9eIMOsxMuSa48qhxYOCY=3ggbGwaiJuSFnFECy0ItuwBBMDAcriwCdSc3GA0UFig=
>  

[committed] libphobos: Add --enable-libphobos-checking configure option (PR94305)

[Iain Buclaw via Gcc-patches]

Hi,

As GDCFLAGS is overriden by the top-level make file with '-O2 -g',
libphobos ends up always being built with all contracts, invariants, and
asserts compiled in.  This adds a new configurable that defaults to omit
compiling any run-time checks into the library using '-frelease'.

Other choices either set the flags '-fno-release', enabling all run-time
checks, or '-fassert', which only compiles in asserts.

The omission of compiling in contracts results in a smaller library
size, with faster build times.

Bootstrapped and regression tested on x86_64-linux-gnu, and committed to
mainline.

Regards
Iain.

--
libphobos/ChangeLog:

PR d/94305
* Makefile.in: Regenerate.
* configure: Regenerate.
* configure.ac: Add --enable-libphobos-checking and substitute
CHECKING_DFLAGS.  Remove -frelease from GDCFLAGS.
* libdruntime/Makefile.am: Add CHECKING_DFLAGS to AM_DFLAGS.
* libdruntime/Makefile.in: Regenerate.
* src/Makefile.am: Add CHECKING_DFLAGS to AM_DFLAGS.
* src/Makefile.in: Regenerate.
* testsuite/Makefile.in: Regenerate.
* testsuite/testsuite_flags.in: Add -fno-release -funittest to
--gdcflags.
---
 libphobos/Makefile.in  |  1 +
 libphobos/configure| 40 +++---
 libphobos/configure.ac | 29 +--
 libphobos/libdruntime/Makefile.am  |  2 +-
 libphobos/libdruntime/Makefile.in  |  3 +-
 libphobos/src/Makefile.am  |  2 +-
 libphobos/src/Makefile.in  |  3 +-
 libphobos/testsuite/Makefile.in|  1 +
 libphobos/testsuite/testsuite_flags.in |  2 +-
 9 files changed, 72 insertions(+), 11 deletions(-)

diff --git a/libphobos/Makefile.in b/libphobos/Makefile.in
index 98d35641a95..b464d605232 100644
--- a/libphobos/Makefile.in
+++ b/libphobos/Makefile.in
@@ -207,6 +207,7 @@ CCASFLAGS = @CCASFLAGS@
 CC_FOR_BUILD = @CC_FOR_BUILD@
 CFLAGS = @CFLAGS@
 CFLAGS_FOR_BUILD = @CFLAGS_FOR_BUILD@
+CHECKING_DFLAGS = @CHECKING_DFLAGS@
 CPP = @CPP@
 CPPFLAGS = @CPPFLAGS@
 CYGPATH_W = @CYGPATH_W@
diff --git a/libphobos/configure b/libphobos/configure
index f458ad3b086..af597b2525b 100755
--- a/libphobos/configure
+++ b/libphobos/configure
@@ -637,6 +637,7 @@ WARN_DFLAGS
 GDCFLAGSX
 libtool_VERSION
 SPEC_PHOBOS_DEPS
+CHECKING_DFLAGS
 ENABLE_LIBPHOBOS_FALSE
 ENABLE_LIBPHOBOS_TRUE
 gdc_include_dir
@@ -842,6 +843,7 @@ with_cross_host
 enable_version_specific_runtime_libs
 with_toolexeclibdir
 enable_libphobos
+enable_libphobos_checking
 '
   ac_precious_vars='build_alias
 host_alias
@@ -1488,6 +1490,11 @@ Optional Features:
   Specify that runtime libraries should be installed
   in a compiler-specific directory
   --enable-libphobos  Enable libphobos
+  --enable-libphobos-checking[=LIST]
+  enable expensive run-time checks. With LIST, enable
+  only specific categories of checks. Categories are:
+  yes,no,all,none,release. Flags are: assert or other
+  strings
 
 Optional Packages:
   --with-PACKAGE[=ARG]use PACKAGE [ARG=yes]
@@ -11642,7 +11649,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 11645 "configure"
+#line 11652 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -11748,7 +11755,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 11751 "configure"
+#line 11758 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -15288,6 +15295,31 @@ else
 fi
 
 
+# Enable expensive internal checks
+# Check whether --enable-libphobos-checking was given.
+if test "${enable_libphobos_checking+set}" = set; then :
+  enableval=$enable_libphobos_checking; ac_checking_flags="${enableval}"
+else
+  ac_checking_flags=release
+fi
+
+IFS="${IFS=}"; ac_save_IFS="$IFS"; IFS="$IFS,"
+for check in release $ac_checking_flags
+do
+   case $check in
+   # These set all the flags to specific states
+   yes|all) RELEASE_FLAG="-fno-release" ; ASSERT_FLAG= ;;
+   no|none|release) RELEASE_FLAG="-frelease" ; ASSERT_FLAG= ;;
+   # These enable particular checks
+   assert) ASSERT_FLAG="-fassert" ;;
+   # Accept
+   *) ;;
+   esac
+done
+IFS="$ac_save_IFS"
+CHECKING_DFLAGS="$RELEASE_FLAG $ASSERT_FLAG"
+
+
 # Add drtbegin.o/drtend.o to startfile/endfile specs in libgphobos.spec
 if test "$DCFG_MINFO_BRACKETING" = "false"; then
 DRTSTUFF_SPEC=$srcdir/src/drtstuff.spec
@@ -15306,12 +15338,12 @@ libtool_VERSION=1:0:0
 
 # Set default flags (after DRUNTIME_WERROR!)
 if test -z "$GDCFLAGS"; then
-GDCFLAGS="-g -frelease -O2"
+GDCFLAGS="-g -O2"
 fi
 
 
 if test -z "$GDCFLAGSX"; then
-GDCFLAGSX="-g -fno-release -funittest"
+GDCFLAGSX="-g"
 fi
 
 
diff --git 

[committed] libphobos: Remove --enable-thread-lib configure option.

[Iain Buclaw via Gcc-patches]

Hi,

This is another old option that doesn't make sense as a configurable.
So the option has been removed, and the check for AC_SEARCH_LIBS moved
into the main configure.ac file.

Bootstrapped and regression tested on x86_64-linux-gnu, and committed to
mainline.

Regards
Iain.

---
libphobos/ChangeLog:

* configure: Regenerate.
* configure.ac: Use AC_SEARCH_LIBS for pthread_create.
* m4/druntime/libraries.m4: Remove DRUNTIME_LIBRARIES_THREAD.
---
 libphobos/configure| 78 ++
 libphobos/configure.ac |  2 +-
 libphobos/m4/druntime/libraries.m4 | 26 --
 3 files changed, 4 insertions(+), 102 deletions(-)

diff --git a/libphobos/configure b/libphobos/configure
index 108518d86aa..f458ad3b086 100755
--- a/libphobos/configure
+++ b/libphobos/configure
@@ -835,7 +835,6 @@ enable_libtool_lock
 with_gcc_major_version_only
 enable_werror
 enable_druntime_gc
-enable_thread_lib
 with_libatomic
 with_libbacktrace
 with_target_system_zlib
@@ -1485,9 +1484,6 @@ Optional Features:
   --disable-libtool-lock  avoid locking (might break parallel builds)
   --enable-werror turns on -Werror [default=no]
   --enable-druntime-gcenable D runtime garbage collector (default: yes)
-  --enable-thread-lib=
-  specify linker option for the system thread library
-  (default: autodetect)
   --enable-version-specific-runtime-libs
   Specify that runtime libraries should be installed
   in a compiler-specific directory
@@ -11646,7 +11642,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 11649 "configure"
+#line 11645 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -11752,7 +11748,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 11755 "configure"
+#line 11751 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -14480,17 +14476,7 @@ if test "$ac_res" != no; then :
 
 fi
 
-
-  enable_thread_lib=yes
-  # Check whether --enable-thread-lib was given.
-if test "${enable_thread_lib+set}" = set; then :
-  enableval=$enable_thread_lib;
-fi
-
-
-  if test "x$enable_thread_lib" = "xyes"; then :
-
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for library containing 
pthread_create" >&5
+  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for library containing 
pthread_create" >&5
 $as_echo_n "checking for library containing pthread_create... " >&6; }
 if ${ac_cv_search_pthread_create+:} false; then :
   $as_echo_n "(cached) " >&6
@@ -14534,64 +14520,6 @@ ac_res=$ac_cv_search_pthread_create
 if test "$ac_res" != no; then :
   test "$ac_res" = "none required" || LIBS="$ac_res $LIBS"
 
-fi
-
-
-else
-
-if test "x$enable_thread_lib" = "xno"; then :
-
-  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for thread library" >&5
-$as_echo_n "checking for thread library... " >&6; }
-  { $as_echo "$as_me:${as_lineno-$LINENO}: result: disabled" >&5
-$as_echo "disabled" >&6; }
-
-else
-
-  as_ac_Lib=`$as_echo "ac_cv_lib_$enable_thread_lib''_pthread_create" | 
$as_tr_sh`
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for pthread_create in 
-l$enable_thread_lib" >&5
-$as_echo_n "checking for pthread_create in -l$enable_thread_lib... " >&6; }
-if eval \${$as_ac_Lib+:} false; then :
-  $as_echo_n "(cached) " >&6
-else
-  ac_check_lib_save_LIBS=$LIBS
-LIBS="-l$enable_thread_lib  $LIBS"
-cat > conftest.$ac_ext <<_ACEOF
-module mod;
- extern(C) int pthread_create();
-
-extern(C) int main() {
-  pthread_create(); return 0;
-}
-_ACEOF
-if ac_fn_d_try_link "$LINENO"; then :
-  eval "$as_ac_Lib=yes"
-else
-  eval "$as_ac_Lib=no"
-fi
-rm -f core conftest.err conftest.$ac_objext \
-conftest$ac_exeext conftest.$ac_ext
-LIBS=$ac_check_lib_save_LIBS
-fi
-eval ac_res=\$$as_ac_Lib
-  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
-$as_echo "$ac_res" >&6; }
-if eval test \"x\$"$as_ac_Lib"\" = x"yes"; then :
-  cat >>confdefs.h <<_ACEOF
-#define `$as_echo "HAVE_LIB$enable_thread_lib" | $as_tr_cpp` 1
-_ACEOF
-
-  LIBS="-l$enable_thread_lib $LIBS"
-
-else
-
-as_fn_error $? "Thread library not found" "$LINENO" 5
-
-fi
-
-
-fi
-
 fi
 
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for library containing 
cosf" >&5
diff --git a/libphobos/configure.ac b/libphobos/configure.ac
index 594d2001b06..e6148f07519 100644
--- a/libphobos/configure.ac
+++ b/libphobos/configure.ac
@@ -133,7 +133,7 @@ DRUNTIME_LIBRARIES_CLIB
 WITH_LOCAL_DRUNTIME([
   AC_LANG_PUSH([D])
   AC_SEARCH_LIBS([malloc], [c])
-  DRUNTIME_LIBRARIES_THREAD
+  AC_SEARCH_LIBS([pthread_create], [pthread])
   AC_SEARCH_LIBS([cosf], [m])
   AC_SEARCH_LIBS([clock_gettime], [rt])
   DRUNTIME_ENABLE_ATOMIC_BUILTINS
diff --git a/libphobos/m4/druntime/libraries.m4 

[PATCH] c++: Fix wrong paren-init of aggregates interference [PR93790]

[Marek Polacek via Gcc-patches]

This PR points out that we are rejecting valid code in C++20.  The
problem is that we were surreptitiously transforming

  T& t(e)

into

  T& t{e}

which is wrong, because the type of e had a conversion function to T,
while aggregate initialization of t from e doesn't work.  Therefore, I
was violating a design principle of P0960, which says that any existing
meaning of A(b) should not change.  So I think we should only attempt to
aggregate-initialize if the original expression was ill-formed.

Another design principle is that () should work where {} works, so this:

  struct S { int i; };
  const S& s(1);

has to keep working.  Thus the special handling for paren-lists with one
element.  (A paren-list with more than one element would give you "error:
expression list treated as compound expression in initializer" C++17.)

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?

PR c++/93790
* call.c (initialize_reference): If the reference binding failed, maybe
try initializing from { }.
* decl.c (grok_reference_init): For T& t(e), set
LOOKUP_AGGREGATE_PAREN_INIT but don't build up a constructor yet.

* g++.dg/cpp2a/paren-init23.C: New test.
* g++.dg/init/aggr14.C: New test.
---
 gcc/cp/call.c | 14 ++
 gcc/cp/decl.c | 19 ---
 gcc/testsuite/g++.dg/cpp2a/paren-init23.C | 19 +++
 gcc/testsuite/g++.dg/init/aggr14.C| 14 ++
 4 files changed, 63 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/paren-init23.C
 create mode 100644 gcc/testsuite/g++.dg/init/aggr14.C

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 02220ffb3a1..1f3d9d23b5b 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -12196,6 +12196,20 @@ initialize_reference (tree type, tree expr,
 
   conv = reference_binding (type, TREE_TYPE (expr), expr, /*c_cast_p=*/false,
flags, complain);
+  /* If this conversion failed, we're in C++20, and we have something like
+ A& a(b) where A is an aggregate, try again, this time as A& a{b}.  */
+  if ((!conv || conv->bad_p)
+  && (flags & LOOKUP_AGGREGATE_PAREN_INIT))
+{
+  tree e = build_constructor_single (init_list_type_node, NULL_TREE, expr);
+  CONSTRUCTOR_IS_DIRECT_INIT (e) = true;
+  CONSTRUCTOR_IS_PAREN_INIT (e) = true;
+  conversion *c = reference_binding (type, TREE_TYPE (e), e,
+/*c_cast_p=*/false, flags, complain);
+  /* If this worked, use it.  */
+  if (c && !c->bad_p)
+   expr = e, conv = c;
+}
   if (!conv || conv->bad_p)
 {
   if (complain & tf_error)
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index a6a1340e631..1447b89e692 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -5568,9 +5568,22 @@ grok_reference_init (tree decl, tree type, tree init, 
int flags)
  && !DECL_DECOMPOSITION_P (decl)
  && (cxx_dialect >= cxx2a))
{
- init = build_constructor_from_list (init_list_type_node, init);
- CONSTRUCTOR_IS_DIRECT_INIT (init) = true;
- CONSTRUCTOR_IS_PAREN_INIT (init) = true;
+ /* We don't know yet if we should treat const A& r(1) as
+const A& r{1}.  */
+ if (list_length (init) == 1)
+   {
+ flags |= LOOKUP_AGGREGATE_PAREN_INIT;
+ init = build_x_compound_expr_from_list (init, ELK_INIT,
+ tf_warning_or_error);
+   }
+ /* If the list had more than one element, the code is ill-formed
+pre-C++20, so we can build a constructor right away.  */
+ else
+   {
+ init = build_constructor_from_list (init_list_type_node, init);
+ CONSTRUCTOR_IS_DIRECT_INIT (init) = true;
+ CONSTRUCTOR_IS_PAREN_INIT (init) = true;
+   }
}
   else
init = build_x_compound_expr_from_list (init, ELK_INIT,
diff --git a/gcc/testsuite/g++.dg/cpp2a/paren-init23.C 
b/gcc/testsuite/g++.dg/cpp2a/paren-init23.C
new file mode 100644
index 000..6038f63be5a
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/paren-init23.C
@@ -0,0 +1,19 @@
+// PR c++/93790 - wrong paren-init of aggregates interference.
+// { dg-do compile { target c++2a } }
+
+struct S {
+  int i;
+};
+const S& s(1);
+
+struct A {
+  int i;
+  A(int);
+};
+const A& a(1);
+
+struct B {
+  int i;
+  B(int) = delete;
+};
+const B& b(1); // { dg-error "use of deleted function" }
diff --git a/gcc/testsuite/g++.dg/init/aggr14.C 
b/gcc/testsuite/g++.dg/init/aggr14.C
new file mode 100644
index 000..538b467d467
--- /dev/null
+++ b/gcc/testsuite/g++.dg/init/aggr14.C
@@ -0,0 +1,14 @@
+// PR c++/93790 - wrong paren-init of aggregates interference.
+// { dg-do compile }
+
+struct S {};
+class S_refwrap {
+S& Sref_;
+public:
+S_refwrap(S& Sref) : Sref_(Sref) {}
+operator S&() { return 

Re: [PATCH] aarch64: Add TX3 machine model

[Andrew Pinski via Gcc-patches]

On Wed, Apr 8, 2020 at 11:06 AM Anton Youdkevitch
 wrote:
>
> Here is the patch introducing thunderxt311 maching model
> for the scheduler.  A name for the new chip was added to the
> list of the names to be recognized as a valid parameter for mcpu
> and mtune flags. The TX2 cost model was reused for TX3.

It might make sense to use thunderx3 instead of thunderx3t11 now.
The main reason why I had used thunderx2t99 was because there was
going to be 2 Thunderx2 with two different costs but the second one
turned into OcteonTX2 instead.

Thanks,
Andrew

>
> Bootstrapped on AArch64.
>
> 2020-04-08  Anton Youdkevitch 
>
> * config/aarch64/aarch64-cores.def: Add the chip name.
> * config/aarch64/aarch64-tune.md: Regenerated.
> * gcc/config/aarch64/aarch64.c: Add the cost tables for the chip.
> * gcc/config/aarch64/thunderx3t11.md: New file: add the new
> machine model for the scheduler
> * gcc/config/aarch64/aarch64.md: Include the new model.
>
> ---
>  gcc/config/aarch64/aarch64-cores.def |   3 +
>  gcc/config/aarch64/aarch64-tune.md   |   2 +-
>  gcc/config/aarch64/aarch64.c |  27 +
>  gcc/config/aarch64/aarch64.md|   1 +
>  gcc/config/aarch64/thunderx3t11.md   | 686 +++
>  5 files changed, 718 insertions(+), 1 deletion(-)
>

[committed] libphobos: Remove --enable-unix configure option.

[Iain Buclaw via Gcc-patches]

Hi,

This patch removes --enable-unix, an old option that predates the D2
library, and now is not useful on its own as all posix modules require
the compiler to predefine version(Posix) anyway.  So the option has been
removed, and the logic moved into DRUNTIME_OS_SOURCES, where the
conditional DRUNTIME_OS_POSIX is set instead.

Bootstrapped and regression tested on x86_64-linux-gnu, and committed to
mainline.

Regards
Iain.

---
libphobos/ChangeLog:

* configure: Regenerate.
* configure.ac: Remove DRUNTIME_OS_UNIX.
* libdruntime/Makefile.am: Add DRUNTIME_DSOURCES_POSIX if
DRUNTIME_OS_POSIX is true.
* libdruntime/Makefile.in: Regenerate.
* m4/druntime/os.m4 (DRUNTIME_OS_UNIX): Remove, move AM_CONDITIONAL
logic to...
(DRUNTIME_OS_SOURCES): ...here.  Rename conditional to
DRUNTIME_OS_POSIX.
---
 libphobos/configure   | 59 ---
 libphobos/configure.ac|  1 -
 libphobos/libdruntime/Makefile.am |  2 +-
 libphobos/libdruntime/Makefile.in |  4 +--
 libphobos/m4/druntime/os.m4   | 31 +---
 5 files changed, 35 insertions(+), 62 deletions(-)

diff --git a/libphobos/configure b/libphobos/configure
index 65e32d88f45..108518d86aa 100755
--- a/libphobos/configure
+++ b/libphobos/configure
@@ -662,6 +662,8 @@ DRUNTIME_OS_ARM_EABI_UNWINDER_FALSE
 DRUNTIME_OS_ARM_EABI_UNWINDER_TRUE
 DCFG_ARM_EABI_UNWINDER
 DCFG_THREAD_MODEL
+DRUNTIME_OS_POSIX_FALSE
+DRUNTIME_OS_POSIX_TRUE
 DRUNTIME_OS_SOLARIS_FALSE
 DRUNTIME_OS_SOLARIS_TRUE
 DRUNTIME_OS_MINGW_FALSE
@@ -682,8 +684,6 @@ DRUNTIME_OS_ANDROID_FALSE
 DRUNTIME_OS_ANDROID_TRUE
 DRUNTIME_OS_AIX_FALSE
 DRUNTIME_OS_AIX_TRUE
-DRUNTIME_OS_UNIX_FALSE
-DRUNTIME_OS_UNIX_TRUE
 DRUNTIME_CPU_S390_FALSE
 DRUNTIME_CPU_S390_TRUE
 DRUNTIME_CPU_SYSTEMZ_FALSE
@@ -835,7 +835,6 @@ enable_libtool_lock
 with_gcc_major_version_only
 enable_werror
 enable_druntime_gc
-enable_unix
 enable_thread_lib
 with_libatomic
 with_libbacktrace
@@ -1486,8 +1485,6 @@ Optional Features:
   --disable-libtool-lock  avoid locking (might break parallel builds)
   --enable-werror turns on -Werror [default=no]
   --enable-druntime-gcenable D runtime garbage collector (default: yes)
-  --enable-unix   enables Unix runtime (default: yes, for Unix
-  targets)
   --enable-thread-lib=
   specify linker option for the system thread library
   (default: autodetect)
@@ -11649,7 +11646,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 11652 "configure"
+#line 11649 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -11755,7 +11752,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 11758 "configure"
+#line 11755 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -14105,31 +14102,6 @@ fi
 
 
 
-  # Check whether --enable-unix was given.
-if test "${enable_unix+set}" = set; then :
-  enableval=$enable_unix; :
-else
-  enable_unix=auto
-fi
-
-
-  case "$druntime_cv_target_os" in
-aix*|*bsd*|cygwin*|darwin*|gnu*|linux*|skyos*|*solaris*|sysv*) 
d_have_unix=1 ;;
-  esac
-  if test -n "$d_have_unix" && test "$enable_unix" = auto ; then
-enable_unix=yes
-  fi
-   if test "$enable_unix" = "yes"; then
-  DRUNTIME_OS_UNIX_TRUE=
-  DRUNTIME_OS_UNIX_FALSE='#'
-else
-  DRUNTIME_OS_UNIX_TRUE='#'
-  DRUNTIME_OS_UNIX_FALSE=
-fi
-
-
-
-
 
   druntime_target_os_parsed=""
   case "$druntime_cv_target_os" in
@@ -14239,6 +14211,21 @@ else
 fi
 
 
+  druntime_target_posix="no"
+  case "$druntime_cv_target_os" in
+aix*|*bsd*|cygwin*|darwin*|gnu*|linux*|skyos*|*solaris*|sysv*)
+  druntime_target_posix="yes"
+  ;;
+  esac
+   if test "$druntime_target_posix" = "yes"; then
+  DRUNTIME_OS_POSIX_TRUE=
+  DRUNTIME_OS_POSIX_FALSE='#'
+else
+  DRUNTIME_OS_POSIX_TRUE='#'
+  DRUNTIME_OS_POSIX_FALSE=
+fi
+
+
 
 
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for thread model used by 
GDC" >&5
@@ -15599,10 +15586,6 @@ if test -z "${DRUNTIME_CPU_S390_TRUE}" && test -z 
"${DRUNTIME_CPU_S390_FALSE}";
   as_fn_error $? "conditional \"DRUNTIME_CPU_S390\" was never defined.
 Usually this means the macro was only invoked conditionally." "$LINENO" 5
 fi
-if test -z "${DRUNTIME_OS_UNIX_TRUE}" && test -z "${DRUNTIME_OS_UNIX_FALSE}"; 
then
-  as_fn_error $? "conditional \"DRUNTIME_OS_UNIX\" was never defined.
-Usually this means the macro was only invoked conditionally." "$LINENO" 5
-fi
 if test -z "${DRUNTIME_OS_AIX_TRUE}" && test -z "${DRUNTIME_OS_AIX_FALSE}"; 
then
   as_fn_error $? "conditional \"DRUNTIME_OS_AIX\" was never defined.
 Usually this means the macro was only invoked conditionally." "$LINENO" 5
@@ -15643,6 +15626,10 @@ if test -z "${DRUNTIME_OS_SOLARIS_TRUE}" && test -z 
"${DRUNTIME_OS_SOLARIS_FALSE
   as_fn_error $? "conditional 

Re: [PATCH v2 00/11] aarch64: Implement TImode comparisons

[Segher Boessenkool]

On Tue, Apr 07, 2020 at 05:50:38PM -0700, Richard Henderson wrote:
> On 4/7/20 4:58 PM, Segher Boessenkool wrote:
> >> I wonder if it would be helpful to have
> >>
> >>   (uoverflow_plus x y carry)
> >>   (soverflow_plus x y carry)
> >>
> >> etc.
> > 
> > Those have three operands, which is nasty to express.
> 
> How so?  It's a perfectly natural operation.

If you make a new code for it, sure.

You can also do

  C = ((unsigned tworeg)x + y + carry != (unsigned onereg)x + y + carry);

etc., but then in RTL of course; and then you find out that GCC can
simplify some but not all of those expressions, and it uses different
forms everywhere.

The trick is to find an expression that GCC can handle better.

> > On rs6000 we have the carry bit as a separate register (it really is
> > only one bit, XER[CA], but in GCC we model it as a separate register).
> > We handle it as a fixed register (there is only one, and saving and
> > restoring it is relatively expensive, so this worked out the best).
> 
> As for most platforms, more or less.

It's roughly equal how many have it in a separate reg vs. have it in the
condition reg, sure.  Somewhat fewer archs use GPRs for the carries.

> > Still, in the patterns (for insns like "adde") that take both a carry
> > input and have it as output, the expression for the carry output but
> > already the one for the GPR output become so unwieldy that nothing
> > can properly work with it.  So, in the end, I have all such insns that
> > take a carry input just clobber their carry output.  This works great!
> 
> Sure, right up until the point when you want to actually *use* that carry
> output.  Which is exactly what we're talking about here.

We only had two such cases:

a) Code like
  unsigned long f(unsigned long a, long b) { return a + (b > 0); }
we can do with only three insns (which GCC of course cannot derive by
itself, it needs extra patterns).  It now needs four insns (but GCC knows
to do that without using the carry at all).

b) It is useful for carry chains.  Which are very hard to express in C
and have GCC optimise it to what you want at all *anyway*.

> > Expressing the carry setting for insns that do not take a carry in is
> > much easier.  You get somewhat different patterns for various
> > immediate inputs, but that is all.
> 
> It's not horrible, but it's certainly verbose.  If we add a shorthand for that
> common operation, so much the better.

If GCC knows how to properly optimise with these new operators, you will
find you need (at least some of) those special cases again.

> I don't see why this new rtx code is any more difficult than ones that we have
> already.

It needs to be handled separately everywhere again.


Segher

Re: [PATCH] reject scalar array initialization with nullptr [PR94510]

[Martin Sebor via Gcc-patches]

On 4/8/20 12:43 PM, Jason Merrill wrote:

On 4/7/20 2:50 PM, Martin Sebor wrote:

Among the numerous regressions introduced by the change committed
to GCC 9 to allow string literals as template arguments is a failure
to recognize the C++ nullptr and GCC's __null constants as pointers.
For one, I didn't realize that nullptr, being a null pointer constant,
doesn't have a pointer type, and two, I didn't think of __null (which
is a special integer constant that NULL sometimes expands to).

The attached patch adjusts the special handling of trailing zero
initializers in reshape_init_array_1 to recognize both kinds of
constants and avoid treating them as zeros of the array integer
element type.  This restores the expected diagnostics when either
constant is used in the initializer list.


This is another problem due to doing this checking too early, as with 
90938.  Let's look at your other patch from the 90938 discussion to move 
the zero pruning to process_init_constructor_array.


The patch for pr90938 handles this correctly, and I'm planning to 
resubmit it in stage 1 (as I thought ultimately ended up being your

expectation as well).  A I mentioned in the review at the end of
February I had reservations about making those changes then because
it seemed late to me.  I'm that much less comfortable with them now,
barely a month away from the anticipated release date.

For reference, the last revision of the patch is here:
https://gcc.gnu.org/pipermail/gcc-patches/2020-February/540792.html

Martin

PS As a reminder, all these bugs (94510, 94124, 90947, and 90938)
were introduced by making a similar change to code I wasn't familiar
with at the very end of GCC 9.

Re: [PATCH] Some top-level configury syncing with gdb

[Jeff Law via Gcc-patches]

On Wed, 2020-04-08 at 12:09 -0600, Tom Tromey wrote:
> Merge top-level configury changes from gdb
> 
> We recently rearranged the gdb source tree to move a common library
> and gdbserver to the top-level.  This made the build more uniform and
> also a bit faster (due to sharing of built objects).
> 
> This patch re-syncs these changes the top-level configury back to gcc.
> 
> In the appended patch, I've omitted the generated parts.
> 
> ChangeLog:
> * configure: Rebuild.
> * Makefile.in: Rebuild.
> * Makefile.def (gdbsupport, gdbserver): New host modules.
> (configure-gdb): Depend on all-gdbsupport.
> (all-gdb): Depend on all-gdbsupport, all-libctf.
> * configure.ac (host_tools): Add gdbserver.
> Conditionally build gdbserver and gdbsupport.
OK
jeff
> 

Re: [PATCH] RTEMS: Improve GCC specification

[Jeff Law via Gcc-patches]

On Wed, 2020-04-08 at 19:47 +0200, Sebastian Huber wrote:
> Add a start/end file specification if the -qrtems option is present.
> Allow targets to customize it.
> 
> Support the standard -nodefaultlibs option.
> 
> gcc/
> 
>   * config/rtems.h (RTEMS_STARTFILE_SPEC): Define if undefined.
>   (RTEMS_ENDFILE_SPEC): Likewise.
>   (STARTFILE_SPEC): Update comment.  Add RTEMS_STARTFILE_SPEC.
>   (ENDFILE_SPEC): Add RTEMS_ENDFILE_SPEC.
>   (LIB_SPECS): Support -nodefaultlibs option.
>   * config/or1k/rtems.h (RTEMS_STARTFILE_SPEC): Define.
>   (RTEMS_ENDFILE_SPEC): Likewise.
>   * config/rs6000/rtems.h (RTEMS_STARTFILE_SPEC): Likewise.
>   (RTEMS_ENDFILE_SPEC): Likewise.
>   * config/v850/rtems.h (RTEMS_STARTFILE_SPEC): Likewise.
>   (RTEMS_ENDFILE_SPEC): Likewise.
How important is it to get this into gcc-10?  We're well into stage4 at this
point and while we do have leeway with a patch like this we do want to be
selective about what we accept.

If it's important, then OK, otherwise please defer it to gcc-11, where it's pre-
approved.

Jeff

PING [PATCH][gcc][PR94230]provide an option to change the size limitation for -Wmisleading-indent

[Qing Zhao via Gcc-patches]

Hi,

Please take a look at the attached patch and let me know your comments.

Thanks.

Qing

gcc/ChangeLog:

2020-04-03  qing zhao  

* common.opt: Add -flocation-ranges.
* doc/invoke.texi: Document it.
* toplev.c (process_options): set line_table->default_range_bits
to 0 when flag_location_ranges is false. 



PR94230.patch
Description: Binary data


> Begin forwarded message:
> 
> From: Qing Zhao via Gcc-patches 
> Subject: [PATCH][gcc][PR94230]provide an option to change the size limitation 
> for -Wmisleading-indent 
> Date: April 3, 2020 at 2:55:53 PM CDT
> To: dmalc...@redhat.com, ja...@redhat.com
> Cc: gcc-patches@gcc.gnu.org
> Reply-To: Qing Zhao 
> 
> Hi, David and Jakub,
> 
> Per the discussion we had for PR94230: provide an option to change the size 
> limitation for -Wmisleading-indent
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94230 
> 
> 
> I come up with the following simple patch per David’s suggestion:
> 
> Provide a new first class option -flocation-ranges to control 
> enabling/disablng range tracking when recording source locations.
> The default value for this option is enabling the range tracking.
> 
> When specify -fno-location-ranges, disable the range tracking to save space 
> for column tracking. 
> 
> I have tested this GCC to build our huge application by adding 
> -fno-location-ranges, the whole build completed without any issue. and
> -Wmisleading-indent also emitted several helpful warning message during 
> building.
> 
> I am running bootstrap right now.
> 
> Could you please take a look at the attached patch?
> 
> thanks.
> 
> Qing
> 
> 
> 
> 

Re: [PING PATCH coroutines] Do not strip cleanup_point when promote temporaries out of current stmt

[Nathan Sidwell]

On 4/7/20 11:44 AM, Iain Sandoe wrote:

Bin.Cheng  wrote:


On Mon, Mar 16, 2020 at 5:34 PM Bin.Cheng  wrote:

On Wed, Mar 11, 2020 at 5:07 PM Iain Sandoe  wrote:

Bin.Cheng  wrote:


On Thu, Mar 5, 2020 at 10:18 PM Iain Sandoe  wrote:



If it helps, I could push a branch to users/iains/ on the FSF git server with 
this sequence.

Sorry for being slow replying.  This is weird, were you testing against trunk?


1/ @Jun Ma

   - I think your observation is correct, we should enusre that cleanups are 
applied where needed
to any temps that remain after we’ve those captured by reference.

   However, I would prefer that we do this as required, rather than assuming it 
will be needed so
   I have an updated patch below.

2/ @ Bin / Jun Ma

   - The problem is that the testcase seems to be fragile, perhaps it was a 
c-reduced one?

So… I do not propose to add this test-case at this point (perhaps we could 
construct one that actually
tests the required behaviour - that cleanups are still  run correctly for temps 
that are not promoted by
capture)?

Anyway to avoid further delay, I think we should apply the patch below (I have 
other fixes on top of this
for open PRs)

OK for master?
thanks
Iain

 coroutines: Add cleanups, where required, to statements with captured 
references.
 
 When we promote captured temporaries to local variables, we also

 remove their initializers from the relevant call expression.  This
 means that we should recompute the need for a cleanup expression
 once the set of temporaries that remains becomes known.
 
 gcc/cp/ChangeLog:
 
 2020-04-07  Iain Sandoe  

 Jun Ma  
 
 * coroutines.cc (maybe_promote_captured_temps): Add a

 cleanup expression, if needed, to any call from which
 we promoted temporaries captured by reference.

diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
index 983fa650b55..936be06c336 100644
--- a/gcc/cp/coroutines.cc
+++ b/gcc/cp/coroutines.cc
@@ -2798,11 +2798,13 @@ maybe_promote_captured_temps (tree *stmt, void *d)
location_t sloc = EXPR_LOCATION (*stmt);
tree aw_bind
= build3_loc (sloc, BIND_EXPR, void_type_node, NULL, NULL, NULL);
-  tree aw_statement_current;
-  if (TREE_CODE (*stmt) == CLEANUP_POINT_EXPR)
-   aw_statement_current = TREE_OPERAND (*stmt, 0);
-  else
-   aw_statement_current = *stmt;
+
+  /* Any cleanup point expression might no longer be necessary, since we
+are removing one or more temporaries.  */
+  tree aw_statement_current = *stmt;
+  if (TREE_CODE (aw_statement_current) == CLEANUP_POINT_EXPR)
+   aw_statement_current = TREE_OPERAND (aw_statement_current, 0);
+
/* Collected the scope vars we need move the temps to regular. */
tree aw_bind_body = push_stmt_list ();
tree varlist = NULL_TREE;
@@ -2843,8 +2845,12 @@ maybe_promote_captured_temps (tree *stmt, void *d)
  /* Replace all instances of that temp in the original expr.  */
  cp_walk_tree (_statement_current, replace_proxy, , NULL);
}
-  /* What's left should be the original statement with any temporaries
-broken out.  */
+
+  /* What's left should be the original statement with any co_await
+captured temporaries broken out.  Other temporaries might remain
+so see if we need to wrap the revised statement in a cleanup.  */
+  aw_statement_current =
+   maybe_cleanup_point_expr_void (aw_statement_current);
add_stmt (aw_statement_current);
BIND_EXPR_BODY (aw_bind) = pop_stmt_list (aw_bind_body);
awpts->captured_temps.empty ();



ok

--
Nathan Sidwell

Re: [PATCH] cselib, reload: Fix cselib ICE on m68k/microblaze [PR94526]

[Jeff Law via Gcc-patches]

On Wed, 2020-04-08 at 20:23 +0200, Jakub Jelinek wrote:
> Hi!
> 
> The following testcase ICEs on m68k (and another one Jeff mailed me
> privately on microblaze).
> The problem is that reload creates two DEBUG_INSNs with the same
> value of (plus:P (reg:P sp) (const_int 0)), we compute correctly the
> same hash value for them, but then don't find them in the cselib hash table,
> as rtx_equal_for_cselib_1 thinks it is different from (reg:P sp),
> and trigger an assertion failure that requires that from two different debug
> insns one doesn't add locations to VALUEs.
> 
> The patch has two fixes for this, each fixes the ICE on both targets
> separately, but I think we want both.
> 
> The cselib.c change ensures that rtx_equal_for_cselib_1 considers
> (value:P sp_derived_value) and (plus:P (reg:P sp) (const_int 0)) equivalent.
> 
> The reload1.c change makes sure we don't create those bogus plus 0
> expressions.  I understand the reasons for creating them, but they don't
> really apply to DEBUG_INSNs; we don't have validity matching there, all we
> care is that the expressions aren't arbitrarily deep, but it is just fine
> to fold x + 0 into just x in there.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, tested on the
> testcases with crosses to m86k-linux and microblaze-linux, ok for trunk?
> 
> 2020-04-08  Jakub Jelinek  
> 
>   PR middle-end/94526
>   * cselib.c (autoinc_split): Handle e->val_rtx being SP_DERIVED_VALUE_P
>   with zero offset.
>   * reload1.c (eliminate_regs_1): Avoid creating
>   (plus (reg) (const_int 0)) in DEBUG_INSNs.
> 
>   * gcc.dg/pr94526.c: New test.
OK
jeff
> 

Re: [PATCH] sra: Fix sra_modify_expr handling of partial writes (PR 94482)

[Richard Biener]

On April 8, 2020 8:34:08 PM GMT+02:00, Martin Jambor  wrote:
>Hi,
>
>On Wed, Apr 08 2020, Richard Biener wrote:
>> On Tue, 7 Apr 2020, Richard Biener wrote:
>>
>>> On April 7, 2020 6:25:26 PM GMT+02:00, Martin Jambor
> wrote:
>>> >Hi,
>>> >
>>> >On Tue, Apr 07 2020, Richard Biener wrote:
>>> >> On Tue, 7 Apr 2020, Martin Jambor wrote:
>>> >>
>>> >>> Hi,
>>> >>> 
>>> >>> when sra_modify_expr is invoked on an expression that modifies
>only
>>> >>> part of the underlying replacement, such as a BIT_FIELD_REF on a
>LHS
>>> >>> of an assignment and the SRA replacement's type is not
>compatible
>>> >with
>>> >>> what is being replaced (0th operand of the B_F_R in the above
>>> >>> example), it does not work properly, basically throwing away the
>>> >partd
>>> >>> of the expr that should have stayed intact.
>>> >>> 
>>> >>> This is fixed in two ways.  For BIT_FIELD_REFs, which operate on
>the
>>> >>> binary image of the replacement (and so in a way serve as a
>>> >>> VIEW_CONVERT_EXPR) we just do not bother with convertsing.  For
>>> >>> REALPART_EXPRs and IMAGPART_EXPRs, we insert a VIEW_CONVERT_EXPR
>>> >under
>>> >>> the complex partial access expression, which is OK even in a LHS
>of
>>> >an
>>> >>> assignment (and other write contexts) because in those cases the
>>> >>> replacement is not going to be a giple register anyway.
>>> >>> 
>>> >>> The testcase for handling REALPART_EXPR and IMAGPART_EXPR is a
>bit
>>> >>> fragile because SRA prefers complex and vector types over
>anything
>>> >else
>>> >>> (and in between the two it decides based on TYPE_UID which in my
>>> >testing
>>> >>> today always preferred complex types) and even when GIMPLE is
>wrong
>>> >I
>>> >>> often still did not get failing runs, so I only run it at -O1
>(which
>>> >is
>>> >>> the only level where the the test fails for me).
>>> >>> 
>>> >>> Bootstrapped and tested on x86_64-linux, bootstrap and testing
>on
>>> >>> i686-linux and aarch64-linux underway.
>>> >>> 
>>> >>> OK for trunk (and subsequently for release branches) if it
>passes?
>>> >>
>>> >> OK.
>>> >
>>> >I must have been already half asleep when writing that it passed
>>> >testing.  It did not, testsuite/gcc.c-torture/compile/pr42196-3.c
>fails
>>> >even on x86_64, because fwprop happily combines
>>> >
>>> >  u$ci_10 = MEM[(union U *)];
>>> >
>>> >and
>>> >
>>> >  f1_6 = IMAGPART_EXPR (u$ci_10)>;
>>> >
>>> >into
>>> >
>>> >  f1_6 = IMAGPART_EXPR ;
>>> >
>>> >and the gimple verifier of course does not like that.  I'll have a
>look
>>> >at that tomorrow.
>>> 
>>> Ah, that might be a genuine fwprop bug. 
>>
>> On a second thought
>>
>>   f1_6 = IMAGPART_EXPR (u$ci_10)>;
>>
>> shouldn't be valid GIMPLE since 'complex float' is a register type
>> and thus it should have been
>>
>>   _11 = VIEW_CONVERT_EXPR(u$ci_10);
>>   f1_6 = IMAGPART_EXPR <_11>;
>>
>
>OK, the newest version of the patch below is careful to do that if the
>replacement is going to be a gimple_register,
>
>> now it's a bit of a grey area since a load like
>>
>>   f1_6 = IMAGPART_EXPR (u);
>>
>> is valid (we don't want to force a whole _Complex load here).
>
>and the above for non-gimple-registers.
>
>>
>> For example in VN
>>
>>   f1_6 = IMAGPART_EXPR (u$ci_10)>;
>>
>> goes through the load machinery.
>>
>> So let's say the IL is undesirable at least.
>>
>> The following fixes the forwprop laziness, please include it in the
>> patch so it gets cherry-picked for backports.
>
>I added it to the modified patch, it was still necessary.  The version
>below has passed bootstrap and testing on x86-64-linux and
>aarch64-linux
>(and I have double checked!) and bootstrap on i686-linux, testing on
>the
>32-bit platform is still ongoing.  OK if it passes there too?

OK. 

Richard. 

>Thanks,
>
>Martin
>
>
>sra: Fix sra_modify_expr handling of partial writes (PR 94482)
>
>when sra_modify_expr is invoked on an expression that modifies only
>part of the underlying replacement, such as a BIT_FIELD_REF on a LHS
>of an assignment and the SRA replacement's type is not compatible with
>what is being replaced (0th operand of the B_F_R in the above
>example), it does not work properly, basically throwing away the partd
>of the expr that should have stayed intact.
>
>This is fixed in two ways.  For BIT_FIELD_REFs, which operate on the
>binary image of the replacement (and so in a way serve as a
>VIEW_CONVERT_EXPR) we just do not bother with convertsing.  For
>REALPART_EXPRs and IMAGPART_EXPRs, if the replacement is not a
>register, we insert a VIEW_CONVERT_EXPR under
>the complex partial access expression, which is always OK, for loads
>from registers we take the extra step of converting it to a temporary.
>
>This revealed a bug in fwprop which is fixed with the hunk from Richi.
>
>The testcase for handling REALPART_EXPR and IMAGPART_EXPR is a bit
>fragile because SRA prefers complex and vector types over anything
>else (and in between the two it decides based on TYPE_UID which in my
>testing today always preferred complex types) and 

Re: [PATCH] vect: Fix up lowering of TRUNC_MOD_EXPR by negative constant [PR94524]

[Richard Biener]

On April 8, 2020 8:14:56 PM GMT+02:00, Jakub Jelinek  wrote:
>Hi!
>
>The first testcase below is miscompiled, because for the division part
>of the lowering we canonicalize negative divisors to their absolute
>value
>(similarly how expmed.c canonicalizes it), but when multiplying the
>division
>result back by the VECTOR_CST, we use the original constant, which can
>contain negative divisors.
>
>Fixed by computing ABS_EXPR of the VECTOR_CST.  Unfortunately,
>fold-const.c
>doesn't support const_unop (ABS_EXPR, VECTOR_CST) and I think it is too
>late
>in GCC 10 cycle to add it now.
>
>Furthermore, while modulo by most negative constant happens to return
>the
>right value, it does that only by invoking UB in the IL, because
>we then expand division by that 1U+INT_MAX and say for INT_MIN %
>INT_MIN
>compute the division as -1, and then multiply by INT_MIN, which is
>signed
>integer overflow.  We in theory could do the computation in unsigned
>vector
>types instead, but is it worth bothering.  People that are doing %
>INT_MIN
>are either testing for standard conformance, or doing something wrong.
>So, I've also added punting on % INT_MIN, both in vect lowering and
>vect
>pattern recognition (we punt already for / INT_MIN).
>
>Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

OK. 

Richard 

>2020-04-08  Jakub Jelinek  
>
>   PR tree-optimization/94524
>   * tree-vect-generic.c (expand_vector_divmod): If any elt of op1 is
>   negative for signed TRUNC_MOD_EXPR, multiply with absolute value of
>   op1 rather than op1 itself at the end.  Punt for signed modulo by
>   most negative constant.
>   * tree-vect-patterns.c (vect_recog_divmod_pattern): Punt for signed
>   modulo by most negative constant.
>
>   * gcc.c-torture/execute/pr94524-1.c: New test.
>   * gcc.c-torture/execute/pr94524-2.c: New test.
>
>--- gcc/tree-vect-generic.c.jj 2020-01-12 11:54:38.518381650 +0100
>+++ gcc/tree-vect-generic.c2020-04-08 11:46:34.41192 +0200
>@@ -478,6 +478,7 @@ expand_vector_divmod (gimple_stmt_iterat
> {
>   bool use_pow2 = true;
>   bool has_vector_shift = true;
>+  bool use_abs_op1 = false;
>   int mode = -1, this_mode;
>   int pre_shift = -1, post_shift;
>   unsigned int nunits = nunits_for_known_piecewise_op (type);
>@@ -618,8 +619,11 @@ expand_vector_divmod (gimple_stmt_iterat
> 
> /* n rem d = n rem -d */
> if (code == TRUNC_MOD_EXPR && d < 0)
>-  d = abs_d;
>-else if (abs_d == HOST_WIDE_INT_1U << (prec - 1))
>+  {
>+d = abs_d;
>+use_abs_op1 = true;
>+  }
>+if (abs_d == HOST_WIDE_INT_1U << (prec - 1))
>   {
> /* This case is not handled correctly below.  */
> mode = -2;
>@@ -899,6 +903,23 @@ expand_vector_divmod (gimple_stmt_iterat
>   if (op == unknown_optab
>   || optab_handler (op, TYPE_MODE (type)) == CODE_FOR_nothing)
> return NULL_TREE;
>+  if (use_abs_op1)
>+{
>+  tree_vector_builder elts;
>+  if (!elts.new_unary_operation (type, op1, false))
>+  return NULL_TREE;
>+  unsigned int count = elts.encoded_nelts ();
>+  for (unsigned int i = 0; i < count; ++i)
>+  {
>+tree elem1 = VECTOR_CST_ELT (op1, i);
>+
>+tree elt = const_unop (ABS_EXPR, TREE_TYPE (elem1), elem1);
>+if (elt == NULL_TREE)
>+  return NULL_TREE;
>+elts.quick_push (elt);
>+  }
>+  op1 = elts.build ();
>+}
>   tem = gimplify_build2 (gsi, MULT_EXPR, type, cur_op, op1);
>   op = optab_for_tree_code (MINUS_EXPR, type, optab_default);
>   if (op == unknown_optab
>--- gcc/tree-vect-patterns.c.jj2020-01-12 11:54:38.520381620 +0100
>+++ gcc/tree-vect-patterns.c   2020-04-08 11:47:05.540523021 +0200
>@@ -3365,8 +3365,8 @@ vect_recog_divmod_pattern (stmt_vec_info
> d = abs_d;
> oprnd1 = build_int_cst (itype, abs_d);
>   }
>-  else if (HOST_BITS_PER_WIDE_INT >= prec
>- && abs_d == HOST_WIDE_INT_1U << (prec - 1))
>+  if (HOST_BITS_PER_WIDE_INT >= prec
>+&& abs_d == HOST_WIDE_INT_1U << (prec - 1))
>   /* This case is not handled correctly below.  */
>   return NULL;
> 
>--- gcc/testsuite/gcc.c-torture/execute/pr94524-1.c.jj 2020-04-08
>11:48:37.357148916 +0200
>+++ gcc/testsuite/gcc.c-torture/execute/pr94524-1.c2020-04-08
>11:50:01.152894857 +0200
>@@ -0,0 +1,19 @@
>+/* PR tree-optimization/94524 */
>+
>+typedef signed char __attribute__ ((__vector_size__ (16))) V;
>+
>+static __attribute__ ((__noinline__, __noclone__)) V
>+foo (V c)
>+{
>+  c %= (signed char) -19;
>+  return (V) c;
>+}
>+
>+int
>+main ()
>+{
>+  V x = foo ((V) { 31 });
>+  if (x[0] != 12)
>+__builtin_abort ();
>+  return 0;
>+}
>--- gcc/testsuite/gcc.c-torture/execute/pr94524-2.c.jj 2020-04-08
>11:48:40.694098980 +0200
>+++ gcc/testsuite/gcc.c-torture/execute/pr94524-2.c2020-04-08
>11:50:13.049716806 +0200
>@@ -0,0 +1,25 @@
>+/* PR tree-optimization/94524 */
>+

Re: [PATCH] reject scalar array initialization with nullptr [PR94510]

[Jason Merrill via Gcc-patches]

On 4/7/20 2:50 PM, Martin Sebor wrote:

Among the numerous regressions introduced by the change committed
to GCC 9 to allow string literals as template arguments is a failure
to recognize the C++ nullptr and GCC's __null constants as pointers.
For one, I didn't realize that nullptr, being a null pointer constant,
doesn't have a pointer type, and two, I didn't think of __null (which
is a special integer constant that NULL sometimes expands to).

The attached patch adjusts the special handling of trailing zero
initializers in reshape_init_array_1 to recognize both kinds of
constants and avoid treating them as zeros of the array integer
element type.  This restores the expected diagnostics when either
constant is used in the initializer list.


This is another problem due to doing this checking too early, as with 
90938.  Let's look at your other patch from the 90938 discussion to move 
the zero pruning to process_init_constructor_array.


Jason

Re: [PATCH] sra: Fix sra_modify_expr handling of partial writes (PR 94482)

[Martin Jambor]

Hi,

On Wed, Apr 08 2020, Richard Biener wrote:
> On Tue, 7 Apr 2020, Richard Biener wrote:
>
>> On April 7, 2020 6:25:26 PM GMT+02:00, Martin Jambor  wrote:
>> >Hi,
>> >
>> >On Tue, Apr 07 2020, Richard Biener wrote:
>> >> On Tue, 7 Apr 2020, Martin Jambor wrote:
>> >>
>> >>> Hi,
>> >>> 
>> >>> when sra_modify_expr is invoked on an expression that modifies only
>> >>> part of the underlying replacement, such as a BIT_FIELD_REF on a LHS
>> >>> of an assignment and the SRA replacement's type is not compatible
>> >with
>> >>> what is being replaced (0th operand of the B_F_R in the above
>> >>> example), it does not work properly, basically throwing away the
>> >partd
>> >>> of the expr that should have stayed intact.
>> >>> 
>> >>> This is fixed in two ways.  For BIT_FIELD_REFs, which operate on the
>> >>> binary image of the replacement (and so in a way serve as a
>> >>> VIEW_CONVERT_EXPR) we just do not bother with convertsing.  For
>> >>> REALPART_EXPRs and IMAGPART_EXPRs, we insert a VIEW_CONVERT_EXPR
>> >under
>> >>> the complex partial access expression, which is OK even in a LHS of
>> >an
>> >>> assignment (and other write contexts) because in those cases the
>> >>> replacement is not going to be a giple register anyway.
>> >>> 
>> >>> The testcase for handling REALPART_EXPR and IMAGPART_EXPR is a bit
>> >>> fragile because SRA prefers complex and vector types over anything
>> >else
>> >>> (and in between the two it decides based on TYPE_UID which in my
>> >testing
>> >>> today always preferred complex types) and even when GIMPLE is wrong
>> >I
>> >>> often still did not get failing runs, so I only run it at -O1 (which
>> >is
>> >>> the only level where the the test fails for me).
>> >>> 
>> >>> Bootstrapped and tested on x86_64-linux, bootstrap and testing on
>> >>> i686-linux and aarch64-linux underway.
>> >>> 
>> >>> OK for trunk (and subsequently for release branches) if it passes?
>> >>
>> >> OK.
>> >
>> >I must have been already half asleep when writing that it passed
>> >testing.  It did not, testsuite/gcc.c-torture/compile/pr42196-3.c fails
>> >even on x86_64, because fwprop happily combines
>> >
>> >  u$ci_10 = MEM[(union U *)];
>> >
>> >and
>> >
>> >  f1_6 = IMAGPART_EXPR (u$ci_10)>;
>> >
>> >into
>> >
>> >  f1_6 = IMAGPART_EXPR ;
>> >
>> >and the gimple verifier of course does not like that.  I'll have a look
>> >at that tomorrow.
>> 
>> Ah, that might be a genuine fwprop bug. 
>
> On a second thought
>
>   f1_6 = IMAGPART_EXPR (u$ci_10)>;
>
> shouldn't be valid GIMPLE since 'complex float' is a register type
> and thus it should have been
>
>   _11 = VIEW_CONVERT_EXPR(u$ci_10);
>   f1_6 = IMAGPART_EXPR <_11>;
>

OK, the newest version of the patch below is careful to do that if the
replacement is going to be a gimple_register,

> now it's a bit of a grey area since a load like
>
>   f1_6 = IMAGPART_EXPR (u);
>
> is valid (we don't want to force a whole _Complex load here).

and the above for non-gimple-registers.

>
> For example in VN
>
>   f1_6 = IMAGPART_EXPR (u$ci_10)>;
>
> goes through the load machinery.
>
> So let's say the IL is undesirable at least.
>
> The following fixes the forwprop laziness, please include it in the
> patch so it gets cherry-picked for backports.

I added it to the modified patch, it was still necessary.  The version
below has passed bootstrap and testing on x86-64-linux and aarch64-linux
(and I have double checked!) and bootstrap on i686-linux, testing on the
32-bit platform is still ongoing.  OK if it passes there too?

Thanks,

Martin


sra: Fix sra_modify_expr handling of partial writes (PR 94482)

when sra_modify_expr is invoked on an expression that modifies only
part of the underlying replacement, such as a BIT_FIELD_REF on a LHS
of an assignment and the SRA replacement's type is not compatible with
what is being replaced (0th operand of the B_F_R in the above
example), it does not work properly, basically throwing away the partd
of the expr that should have stayed intact.

This is fixed in two ways.  For BIT_FIELD_REFs, which operate on the
binary image of the replacement (and so in a way serve as a
VIEW_CONVERT_EXPR) we just do not bother with convertsing.  For
REALPART_EXPRs and IMAGPART_EXPRs, if the replacement is not a
register, we insert a VIEW_CONVERT_EXPR under
the complex partial access expression, which is always OK, for loads
from registers we take the extra step of converting it to a temporary.

This revealed a bug in fwprop which is fixed with the hunk from Richi.

The testcase for handling REALPART_EXPR and IMAGPART_EXPR is a bit
fragile because SRA prefers complex and vector types over anything
else (and in between the two it decides based on TYPE_UID which in my
testing today always preferred complex types) and so I only run it at
-O1 (which is the only level where the the test fails for me).


2020-04-08  Martin Jambor  
Richard Biener  

PR tree-optimization/94482
* tree-sra.c (create_access_replacement): 

Re: [testsuite][arm] Fix cmse-15.c expected output

[Christophe Lyon via Gcc-patches]

On Wed, 8 Apr 2020 at 11:48, Richard Sandiford
 wrote:
>
> Christophe Lyon via Gcc-patches  writes:
> > Hi,
> >
> > While checking Martin's fix for PR ipa/94445, he made me realize that
> > the cmse-15.c testcase still fails at -Os because ICF means that we
> > generate
> > nonsecure2:
> > b   nonsecure0
> >
> > which is OK, but does not match the currently expected
> > nonsecure2:
> > ...
> > bl  __gnu_cmse_nonsecure_call
> >
> > (see https://gcc.gnu.org/pipermail/gcc-patches/2020-April/543190.html)
> >
> > The test has already different expectations for v8-M and v8.1-M.
> >
> > I've decided to try to use check-function-bodies to account for the
> > different possibilities:
> > - v8-M vs v8.1-M via two different prefixes
> > - code generation variants (-0?) via multiple regexps
> >
> > I've tested that the test now passes with --target-board=-march=armv8-m.main
> > and --target-board=-march=armv8.1-m.main.
> >
> > I feel this a bit too much of a burden for the purpose, maybe there's
> > a better way of handling all these alternatives (in particular,
> > there's a lot of duplication since the expected code for the secure*
> > functions is the same for v8-M and v8.1-M).
>
> FWIW, an alternative is to give multiple versions with the same prefix
> and use { target ... } to select between them.  E.g.:
>
> /*
> ** foo:   { target a }
> **  ...
> */
> /*
> ** foo:   { target { ! a } }
> **  ...
> */
>

Ha indeed, that makes it simpler. Thanks for the example, I hadn't
fully understand how to use that scheme: I tried to add a third
alternative (different prefix) with no selector for cases where no
distinction was needed, but I realized that all alternatives need
their full matching description.

However, {target { ! a } } does not work as is, so the attached patch
uses a non-greedy regexp to avoid trying "! a }" instead of "target {
! a }"

If OK, maybe I should commit that as two separate patches?

Thanks

Christophe


> Thanks,
> Richard
diff --git a/gcc/testsuite/gcc.target/arm/cmse/cmse-15.c 
b/gcc/testsuite/gcc.target/arm/cmse/cmse-15.c
index 0e37b50..b0fefe5 100644
--- a/gcc/testsuite/gcc.target/arm/cmse/cmse-15.c
+++ b/gcc/testsuite/gcc.target/arm/cmse/cmse-15.c
@@ -1,5 +1,8 @@
 /* { dg-do compile } */
 /* { dg-options "-mcmse" } */
+/* ARMv8-M expectation with target { ! arm_cmse_clear_ok }.  */
+/* ARMv8.1-M expectation with target arm_cmse_clear_ok.  */
+/* { dg-final { check-function-bodies "**" "" "" } } */
 
 int __attribute__ ((cmse_nonsecure_call)) (*ns_foo) (void);
 int (*s_bar) (void);
@@ -11,67 +14,204 @@ typedef int s_bar_t (void);
 typedef int __attribute__ ((cmse_nonsecure_call)) (* ns_foo_ptr) (void);
 typedef int (*s_bar_ptr) (void);
 
+/*
+** nonsecure0:  { target arm_cmse_clear_ok }
+** ...
+** blxns   r[0-3]
+** ...
+*/
+/*
+** nonsecure0: { target { ! arm_cmse_clear_ok } }
+** ...
+** bl  __gnu_cmse_nonsecure_call
+** ...
+*/
 int nonsecure0 (ns_foo_t * ns_foo_p)
 {
   return ns_foo_p ();
 }
 
+/*
+** nonsecure1:  { target arm_cmse_clear_ok }
+** ...
+** blxns   r[0-3]
+** ...
+*/
+/*
+** nonsecure1: { target { ! arm_cmse_clear_ok } }
+** ...
+** bl  __gnu_cmse_nonsecure_call
+** ...
+*/
 int nonsecure1 (ns_foo_t ** ns_foo_p)
 {
   return (*ns_foo_p) ();
 }
 
+/*
+** nonsecure2:  { target arm_cmse_clear_ok }
+** ...
+** (
+** blxns   r[0-3]
+** |
+** b   nonsecure0
+** )
+** ...
+*/
+/*
+** nonsecure2: { target { ! arm_cmse_clear_ok } }
+** ...
+** (
+** bl  __gnu_cmse_nonsecure_call
+** |
+** b   nonsecure0
+** )
+** ...
+*/
 int nonsecure2 (ns_foo_ptr ns_foo_p)
 {
   return ns_foo_p ();
 }
+
+/*
+** nonsecure3:  { target arm_cmse_clear_ok }
+** ...
+** blxns   r[0-3]
+** ...
+*/
+/*
+** nonsecure3: { target { ! arm_cmse_clear_ok } }
+** ...
+** bl  __gnu_cmse_nonsecure_call
+** ...
+*/
 int nonsecure3 (ns_foo_ptr * ns_foo_p)
 {
   return (*ns_foo_p) ();
 }
 
+/*
+** secure0:
+** ...
+** (
+** bx  r[0-3]
+** |
+** blx r[0-3]
+** )
+** ...
+*/
 int secure0 (s_bar_t * s_bar_p)
 {
   return s_bar_p ();
 }
 
+/*
+** secure1:
+** ...
+** (
+** bx  r[0-3]
+** |
+** blx r[0-3]
+** )
+** ...
+*/
 int secure1 (s_bar_t ** s_bar_p)
 {
   return (*s_bar_p) ();
 }
 
+/*
+** secure2:
+** ...
+** (
+** bx  r[0-3]
+** |
+** blx r[0-3]
+** |
+** b   secure0
+** )
+** ...
+*/
 int secure2 (s_bar_ptr s_bar_p)
 {
   return s_bar_p ();
 }
 
+/*
+** secure3:
+** ...
+** (
+** bx  r[0-3]
+** |
+** blx r[0-3]
+** )
+** ...
+*/
 int secure3 (s_bar_ptr * s_bar_p)
 {
   return (*s_bar_p) ();
 }
 
+/*
+** nonsecure4:  { target arm_cmse_clear_ok }
+** ...
+** blxns   r[0-3]
+** ...
+*/
+/*
+** nonsecure4: { target { ! arm_cmse_clear_ok } }
+** ...
+** bl  __gnu_cmse_nonsecure_call
+** ...
+*/
 int nonsecure4 (void)
 {
   

[PATCH] cselib, reload: Fix cselib ICE on m68k/microblaze [PR94526]

[Jakub Jelinek via Gcc-patches]

Hi!

The following testcase ICEs on m68k (and another one Jeff mailed me
privately on microblaze).
The problem is that reload creates two DEBUG_INSNs with the same
value of (plus:P (reg:P sp) (const_int 0)), we compute correctly the
same hash value for them, but then don't find them in the cselib hash table,
as rtx_equal_for_cselib_1 thinks it is different from (reg:P sp),
and trigger an assertion failure that requires that from two different debug
insns one doesn't add locations to VALUEs.

The patch has two fixes for this, each fixes the ICE on both targets
separately, but I think we want both.

The cselib.c change ensures that rtx_equal_for_cselib_1 considers
(value:P sp_derived_value) and (plus:P (reg:P sp) (const_int 0)) equivalent.

The reload1.c change makes sure we don't create those bogus plus 0
expressions.  I understand the reasons for creating them, but they don't
really apply to DEBUG_INSNs; we don't have validity matching there, all we
care is that the expressions aren't arbitrarily deep, but it is just fine
to fold x + 0 into just x in there.

Bootstrapped/regtested on x86_64-linux and i686-linux, tested on the
testcases with crosses to m86k-linux and microblaze-linux, ok for trunk?

2020-04-08  Jakub Jelinek  

PR middle-end/94526
* cselib.c (autoinc_split): Handle e->val_rtx being SP_DERIVED_VALUE_P
with zero offset.
* reload1.c (eliminate_regs_1): Avoid creating
(plus (reg) (const_int 0)) in DEBUG_INSNs.

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

--- gcc/cselib.c.jj 2020-04-07 13:18:00.935059416 +0200
+++ gcc/cselib.c2020-04-08 13:03:15.105090429 +0200
@@ -884,21 +884,29 @@ autoinc_split (rtx x, rtx *off, machine_
   else
e = cselib_lookup (x, GET_MODE (x), 0, memmode);
   if (e)
-   for (struct elt_loc_list *l = e->locs; l; l = l->next)
- if (GET_CODE (l->loc) == PLUS
- && GET_CODE (XEXP (l->loc, 0)) == VALUE
- && SP_DERIVED_VALUE_P (XEXP (l->loc, 0))
- && CONST_INT_P (XEXP (l->loc, 1)))
+   {
+ if (SP_DERIVED_VALUE_P (e->val_rtx)
+ && (*off == NULL_RTX || *off == const0_rtx))
{
- if (*off == NULL_RTX)
-   *off = XEXP (l->loc, 1);
- else
-   *off = plus_constant (Pmode, *off,
- INTVAL (XEXP (l->loc, 1)));
- if (*off == const0_rtx)
-   *off = NULL_RTX;
- return XEXP (l->loc, 0);
+ *off = NULL_RTX;
+ return e->val_rtx;
}
+ for (struct elt_loc_list *l = e->locs; l; l = l->next)
+   if (GET_CODE (l->loc) == PLUS
+   && GET_CODE (XEXP (l->loc, 0)) == VALUE
+   && SP_DERIVED_VALUE_P (XEXP (l->loc, 0))
+   && CONST_INT_P (XEXP (l->loc, 1)))
+ {
+   if (*off == NULL_RTX)
+ *off = XEXP (l->loc, 1);
+   else
+ *off = plus_constant (Pmode, *off,
+   INTVAL (XEXP (l->loc, 1)));
+   if (*off == const0_rtx)
+ *off = NULL_RTX;
+   return XEXP (l->loc, 0);
+ }
+   }
 }
   return x;
 }
--- gcc/reload1.c.jj2020-01-12 11:54:36.923405714 +0100
+++ gcc/reload1.c   2020-04-08 12:41:38.508513800 +0200
@@ -2607,8 +2607,9 @@ eliminate_regs_1 (rtx x, machine_mode me
   structure of the insn in a way that reload can't handle.
   We special-case the commonest situation in
   eliminate_regs_in_insn, so just replace a PLUS with a
-  PLUS here, unless inside a MEM.  */
-   if (mem_mode != 0
+  PLUS here, unless inside a MEM.  In DEBUG_INSNs, it is
+  always ok to replace a PLUS with just a REG.  */
+   if ((mem_mode != 0 || (insn && DEBUG_INSN_P (insn)))
&& CONST_INT_P (XEXP (x, 1))
&& known_eq (INTVAL (XEXP (x, 1)), -ep->previous_offset))
  return ep->to_rtx;
--- gcc/testsuite/gcc.dg/pr94526.c.jj   2020-04-08 12:42:01.423170364 +0200
+++ gcc/testsuite/gcc.dg/pr94526.c  2020-04-08 12:41:09.664946098 +0200
@@ -0,0 +1,21 @@
+/* PR middle-end/94526 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -g" } */
+
+struct S { int val[8 * sizeof (int)]; };
+
+void
+foo (struct S *x)
+{
+  struct S *a = x;
+}
+
+void baz (struct S);
+
+void
+bar (void)
+{
+  struct S b;
+  foo ();
+  baz (b);
+}

Jakub

Re: [C/C++, OpenACC] Reject vars of different scope in acc declare (PR94120)

[Tobias Burnus]

There was a glitch in the test case (location + dg-error),
already fixed by Jakub (thanks!)
in commit r10-7637-g08d1e7a5aabcf7eeac48bfd99deb80451b8f9974

Sorry,

Tobias

On 4/8/20 7:13 PM, H.J. Lu wrote:


On Wed, Apr 8, 2020 at 12:55 AM Tobias Burnus  wrote:

I have now committed this patch
as r10-7614-g13e41d8b9d3d7598c72c38acc86a3d97046c8373,

On Linux/x86, I got

FAIL: g++.dg/declare-pr94120.C  -std=c++14 (test for excess errors)
FAIL: g++.dg/declare-pr94120.C  -std=c++17 (test for excess errors)
FAIL: g++.dg/declare-pr94120.C  -std=c++2a (test for excess errors)
FAIL: g++.dg/declare-pr94120.C  -std=c++98 (test for excess errors)


reading "so we shall accept it" as approval …

On 4/1/20 9:07 AM, Thomas Schwinge wrote:


Even if the ICE is then fixed, should we still keep
 open (with a note) until
 is
resolved/published?

I decided to close it and mention the namelist issue and
the now-fixed PR in PR84140 (which is about (non)static
class member variables, which is also covered in Issue 288).


Regarding the C/C++ patch you posted: I'm not at all familiar with the
front ends' scoping implementation.  But, given that your patch really
only touches the OpenACC 'declare' code paths, it can't cause any harm
otherwise, so we shall accept it.  Maybe Jakub has any comments, though?

+c_check_oacc_same_scope (tree decl)

Is the function really specific to OpenACC? If not, then "_oacc"
could be dropped from its name. How about "c_check_current_scope"?

Yeah, that may be a good idea.  Similar constructs seem to be used in a
few other places, though without the 'DECL_NAME' indirection.

I now use c_check_in_current_scope.

Tobias
-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter




-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter

[PATCH] vect: Fix up lowering of TRUNC_MOD_EXPR by negative constant [PR94524]

[Jakub Jelinek via Gcc-patches]

Hi!

The first testcase below is miscompiled, because for the division part
of the lowering we canonicalize negative divisors to their absolute value
(similarly how expmed.c canonicalizes it), but when multiplying the division
result back by the VECTOR_CST, we use the original constant, which can
contain negative divisors.

Fixed by computing ABS_EXPR of the VECTOR_CST.  Unfortunately, fold-const.c
doesn't support const_unop (ABS_EXPR, VECTOR_CST) and I think it is too late
in GCC 10 cycle to add it now.

Furthermore, while modulo by most negative constant happens to return the
right value, it does that only by invoking UB in the IL, because
we then expand division by that 1U+INT_MAX and say for INT_MIN % INT_MIN
compute the division as -1, and then multiply by INT_MIN, which is signed
integer overflow.  We in theory could do the computation in unsigned vector
types instead, but is it worth bothering.  People that are doing % INT_MIN
are either testing for standard conformance, or doing something wrong.
So, I've also added punting on % INT_MIN, both in vect lowering and vect
pattern recognition (we punt already for / INT_MIN).

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

2020-04-08  Jakub Jelinek  

PR tree-optimization/94524
* tree-vect-generic.c (expand_vector_divmod): If any elt of op1 is
negative for signed TRUNC_MOD_EXPR, multiply with absolute value of
op1 rather than op1 itself at the end.  Punt for signed modulo by
most negative constant.
* tree-vect-patterns.c (vect_recog_divmod_pattern): Punt for signed
modulo by most negative constant.

* gcc.c-torture/execute/pr94524-1.c: New test.
* gcc.c-torture/execute/pr94524-2.c: New test.

--- gcc/tree-vect-generic.c.jj  2020-01-12 11:54:38.518381650 +0100
+++ gcc/tree-vect-generic.c 2020-04-08 11:46:34.41192 +0200
@@ -478,6 +478,7 @@ expand_vector_divmod (gimple_stmt_iterat
 {
   bool use_pow2 = true;
   bool has_vector_shift = true;
+  bool use_abs_op1 = false;
   int mode = -1, this_mode;
   int pre_shift = -1, post_shift;
   unsigned int nunits = nunits_for_known_piecewise_op (type);
@@ -618,8 +619,11 @@ expand_vector_divmod (gimple_stmt_iterat
 
  /* n rem d = n rem -d */
  if (code == TRUNC_MOD_EXPR && d < 0)
-   d = abs_d;
- else if (abs_d == HOST_WIDE_INT_1U << (prec - 1))
+   {
+ d = abs_d;
+ use_abs_op1 = true;
+   }
+ if (abs_d == HOST_WIDE_INT_1U << (prec - 1))
{
  /* This case is not handled correctly below.  */
  mode = -2;
@@ -899,6 +903,23 @@ expand_vector_divmod (gimple_stmt_iterat
   if (op == unknown_optab
   || optab_handler (op, TYPE_MODE (type)) == CODE_FOR_nothing)
 return NULL_TREE;
+  if (use_abs_op1)
+{
+  tree_vector_builder elts;
+  if (!elts.new_unary_operation (type, op1, false))
+   return NULL_TREE;
+  unsigned int count = elts.encoded_nelts ();
+  for (unsigned int i = 0; i < count; ++i)
+   {
+ tree elem1 = VECTOR_CST_ELT (op1, i);
+
+ tree elt = const_unop (ABS_EXPR, TREE_TYPE (elem1), elem1);
+ if (elt == NULL_TREE)
+   return NULL_TREE;
+ elts.quick_push (elt);
+   }
+  op1 = elts.build ();
+}
   tem = gimplify_build2 (gsi, MULT_EXPR, type, cur_op, op1);
   op = optab_for_tree_code (MINUS_EXPR, type, optab_default);
   if (op == unknown_optab
--- gcc/tree-vect-patterns.c.jj 2020-01-12 11:54:38.520381620 +0100
+++ gcc/tree-vect-patterns.c2020-04-08 11:47:05.540523021 +0200
@@ -3365,8 +3365,8 @@ vect_recog_divmod_pattern (stmt_vec_info
  d = abs_d;
  oprnd1 = build_int_cst (itype, abs_d);
}
-  else if (HOST_BITS_PER_WIDE_INT >= prec
-  && abs_d == HOST_WIDE_INT_1U << (prec - 1))
+  if (HOST_BITS_PER_WIDE_INT >= prec
+ && abs_d == HOST_WIDE_INT_1U << (prec - 1))
/* This case is not handled correctly below.  */
return NULL;
 
--- gcc/testsuite/gcc.c-torture/execute/pr94524-1.c.jj  2020-04-08 
11:48:37.357148916 +0200
+++ gcc/testsuite/gcc.c-torture/execute/pr94524-1.c 2020-04-08 
11:50:01.152894857 +0200
@@ -0,0 +1,19 @@
+/* PR tree-optimization/94524 */
+
+typedef signed char __attribute__ ((__vector_size__ (16))) V;
+
+static __attribute__ ((__noinline__, __noclone__)) V
+foo (V c)
+{
+  c %= (signed char) -19;
+  return (V) c;
+}
+
+int
+main ()
+{
+  V x = foo ((V) { 31 });
+  if (x[0] != 12)
+__builtin_abort ();
+  return 0;
+}
--- gcc/testsuite/gcc.c-torture/execute/pr94524-2.c.jj  2020-04-08 
11:48:40.694098980 +0200
+++ gcc/testsuite/gcc.c-torture/execute/pr94524-2.c 2020-04-08 
11:50:13.049716806 +0200
@@ -0,0 +1,25 @@
+/* PR tree-optimization/94524 */
+
+typedef signed char __attribute__ ((__vector_size__ (16))) V;
+
+static __attribute__ ((__noinline__, __noclone__)) V
+foo (V c)
+{
+  c %= (signed char) -128;
+  return (V) 

[PATCH] Some top-level configury syncing with gdb

[Tom Tromey]

Merge top-level configury changes from gdb

We recently rearranged the gdb source tree to move a common library
and gdbserver to the top-level.  This made the build more uniform and
also a bit faster (due to sharing of built objects).

This patch re-syncs these changes the top-level configury back to gcc.

In the appended patch, I've omitted the generated parts.

ChangeLog:
* configure: Rebuild.
* Makefile.in: Rebuild.
* Makefile.def (gdbsupport, gdbserver): New host modules.
(configure-gdb): Depend on all-gdbsupport.
(all-gdb): Depend on all-gdbsupport, all-libctf.
* configure.ac (host_tools): Add gdbserver.
Conditionally build gdbserver and gdbsupport.

Tom

diff --git a/Makefile.def b/Makefile.def
index 493a31e0359..36fd26b0367 100644
--- a/Makefile.def
+++ b/Makefile.def
@@ -113,6 +113,8 @@ host_modules= { module= zlib; no_install=true; 
no_check=true;
bootstrap=true;
extra_configure_flags='@extra_host_zlib_configure_flags@';};
 host_modules= { module= gnulib; };
+host_modules= { module= gdbsupport; };
+host_modules= { module= gdbserver; };
 host_modules= { module= gdb; };
 host_modules= { module= expect; };
 host_modules= { module= guile; };
@@ -394,18 +396,27 @@ dependencies = { module=configure-gdb; on=all-intl; };
 dependencies = { module=configure-gdb; on=configure-sim; };
 dependencies = { module=configure-gdb; on=all-bfd; };
 dependencies = { module=configure-gdb; on=all-gnulib; };
+dependencies = { module=configure-gdb; on=all-gdbsupport; };
 // Depend on all-libiconv so that configure checks for iconv
 // functions will work.
 dependencies = { module=configure-gdb; on=all-libiconv; };
 dependencies = { module=all-gdb; on=all-libiberty; };
 dependencies = { module=all-gdb; on=all-libiconv; };
 dependencies = { module=all-gdb; on=all-gnulib; };
+dependencies = { module=all-gdb; on=all-gdbsupport; };
 dependencies = { module=all-gdb; on=all-opcodes; };
 dependencies = { module=all-gdb; on=all-readline; };
 dependencies = { module=all-gdb; on=all-build-bison; };
 dependencies = { module=all-gdb; on=all-sim; };
 dependencies = { module=all-gdb; on=all-libdecnumber; };
 dependencies = { module=all-gdb; on=all-libtermcap; };
+dependencies = { module=all-gdb; on=all-libctf; };
+
+// Host modules specific to gdbserver.
+dependencies = { module=configure-gdbserver; on=all-gnulib; };
+dependencies = { module=all-gdbserver; on=all-gdbsupport; };
+dependencies = { module=all-gdbserver; on=all-gnulib; };
+dependencies = { module=all-gdbserver; on=all-libiberty; };
 
 dependencies = { module=configure-libgui; on=configure-tcl; };
 dependencies = { module=configure-libgui; on=configure-tk; };
@@ -413,6 +424,11 @@ dependencies = { module=all-libgui; on=all-tcl; };
 dependencies = { module=all-libgui; on=all-tk; };
 dependencies = { module=all-libgui; on=all-itcl; };
 
+dependencies = { module=configure-gdbsupport; on=configure-gnulib; };
+dependencies = { module=configure-gdbsupport; on=configure-intl; };
+dependencies = { module=all-gdbsupport; on=all-gnulib; };
+dependencies = { module=all-gdbsupport; on=all-intl; };
+
 // Host modules specific to binutils.
 dependencies = { module=configure-bfd; on=configure-libiberty; hard=true; };
 dependencies = { module=configure-bfd; on=configure-intl; };
diff --git a/configure.ac b/configure.ac
index d06c72c877e..8d2b3d31ae0 100644
--- a/configure.ac
+++ b/configure.ac
@@ -139,7 +139,7 @@ host_libs="intl libiberty opcodes bfd readline tcl tk itcl 
libgui zlib libbacktr
 # binutils, gas and ld appear in that order because it makes sense to run
 # "make check" in that particular order.
 # If --enable-gold is used, "gold" may replace "ld".
-host_tools="texinfo flex bison binutils gas ld fixincludes gcc cgen sid sim 
gdb gprof etc expect dejagnu m4 utils guile fastjar gnattools libcc1 gotools"
+host_tools="texinfo flex bison binutils gas ld fixincludes gcc cgen sid sim 
gdb gdbserver gprof etc expect dejagnu m4 utils guile fastjar gnattools libcc1 
gotools"
 
 # these libraries are built for the target environment, and are built after
 # the host libraries and the host tools (which may be a cross compiler)
@@ -855,6 +855,22 @@ case "${target}" in
 ;;
 esac
 
+# Only allow gdbserver on some systems.
+if test -d ${srcdir}/gdbserver; then
+if test x$enable_gdbserver = x; then
+   AC_MSG_CHECKING([for gdbserver support])
+   if (srcdir=${srcdir}/gdbserver; \
+   . ${srcdir}/configure.srv; \
+   test -n "$UNSUPPORTED")
+   then
+   AC_MSG_RESULT([no])
+   noconfigdirs="$noconfigdirs gdbserver"
+   else
+   AC_MSG_RESULT([yes])
+   fi
+fi
+fi
+
 # Disable libgo for some systems where it is known to not work.
 # For testing, you can easily override this with --enable-libgo.
 if test x$enable_libgo = x; then
@@ -2816,13 +2832,17 @@ esac
 CONFIGURE_GDB_TK=`echo ${GDB_TK} | sed s/-all-/-configure-/g`
 

[PATCH] aarch64: Add TX3 machine model

[Anton Youdkevitch]

Here is the patch introducing thunderxt311 maching model
for the scheduler.  A name for the new chip was added to the
list of the names to be recognized as a valid parameter for mcpu
and mtune flags. The TX2 cost model was reused for TX3.

Bootstrapped on AArch64.

2020-04-08  Anton Youdkevitch 

* config/aarch64/aarch64-cores.def: Add the chip name.
* config/aarch64/aarch64-tune.md: Regenerated.
* gcc/config/aarch64/aarch64.c: Add the cost tables for the chip.
* gcc/config/aarch64/thunderx3t11.md: New file: add the new
machine model for the scheduler
* gcc/config/aarch64/aarch64.md: Include the new model.

---
 gcc/config/aarch64/aarch64-cores.def |   3 +
 gcc/config/aarch64/aarch64-tune.md   |   2 +-
 gcc/config/aarch64/aarch64.c |  27 +
 gcc/config/aarch64/aarch64.md|   1 +
 gcc/config/aarch64/thunderx3t11.md   | 686 +++
 5 files changed, 718 insertions(+), 1 deletion(-)

diff --git a/gcc/config/aarch64/aarch64-cores.def b/gcc/config/aarch64/aarch64-cores.def
index ea9b98b..0e5586e 100644
--- a/gcc/config/aarch64/aarch64-cores.def
+++ b/gcc/config/aarch64/aarch64-cores.def
@@ -95,6 +95,9 @@ AARCH64_CORE("vulcan",  vulcan, thunderx2t99, 8_1A,  AARCH64_FL_FOR_ARCH8_1 | AA
 /* Cavium ('C') cores. */
 AARCH64_CORE("thunderx2t99",  thunderx2t99,  thunderx2t99, 8_1A,  AARCH64_FL_FOR_ARCH8_1 | AARCH64_FL_CRYPTO, thunderx2t99, 0x43, 0x0af, -1)
 
+/* Cavium ('??') cores (TX3). */
+AARCH64_CORE("cn110xxx",  thunderx3t11,  thunderx3t11, 8_1A,  AARCH64_FL_FOR_ARCH8_1 | AARCH64_FL_CRYPTO, thunderx3t11, 0x43, 0x0b8, 0x0a)
+
 /* ARMv8.2-A Architecture Processors.  */
 
 /* ARM ('A') cores. */
diff --git a/gcc/config/aarch64/aarch64-tune.md b/gcc/config/aarch64/aarch64-tune.md
index 3cc1c4d..573a4a9 100644
--- a/gcc/config/aarch64/aarch64-tune.md
+++ b/gcc/config/aarch64/aarch64-tune.md
@@ -1,5 +1,5 @@
 ;; -*- buffer-read-only: t -*-
 ;; Generated automatically by gentune.sh from aarch64-cores.def
 (define_attr "tune"
-	"cortexa34,cortexa35,cortexa53,cortexa57,cortexa72,cortexa73,thunderx,thunderxt88p1,thunderxt88,octeontx,octeontxt81,octeontxt83,thunderxt81,thunderxt83,emag,xgene1,falkor,qdf24xx,exynosm1,phecda,thunderx2t99p1,vulcan,thunderx2t99,cortexa55,cortexa75,cortexa76,cortexa76ae,cortexa77,cortexa65,cortexa65ae,ares,neoversen1,neoversee1,octeontx2,octeontx2t98,octeontx2t96,octeontx2t93,octeontx2f95,octeontx2f95n,octeontx2f95mm,tsv110,saphira,cortexa57cortexa53,cortexa72cortexa53,cortexa73cortexa35,cortexa73cortexa53,cortexa75cortexa55,cortexa76cortexa55"
+	"cortexa34,cortexa35,cortexa53,cortexa57,cortexa72,cortexa73,thunderx,thunderxt88p1,thunderxt88,octeontx,octeontxt81,octeontxt83,thunderxt81,thunderxt83,emag,xgene1,falkor,qdf24xx,exynosm1,phecda,thunderx2t99p1,vulcan,thunderx2t99,thunderx3t11,cortexa55,cortexa75,cortexa76,cortexa76ae,cortexa77,cortexa65,cortexa65ae,ares,neoversen1,neoversee1,octeontx2,octeontx2t98,octeontx2t96,octeontx2t93,octeontx2f95,octeontx2f95n,octeontx2f95mm,tsv110,saphira,cortexa57cortexa53,cortexa72cortexa53,cortexa73cortexa35,cortexa73cortexa53,cortexa75cortexa55,cortexa76cortexa55"
 	(const (symbol_ref "((enum attr_tune) aarch64_tune)")))
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 25eccc7..c7685bc 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -1119,6 +1119,33 @@ static const struct tune_params thunderx2t99_tunings =
   _prefetch_tune
 };
 
+static const struct tune_params thunderx3t11_tunings =
+{
+  _extra_costs,
+  _addrcost_table,
+  _regmove_cost,
+  _vector_cost,
+  _branch_cost,
+  _approx_modes,
+  SVE_NOT_IMPLEMENTED, /* sve_width  */
+  4, /* memmov_cost.  */
+  4, /* issue_rate.  */
+  (AARCH64_FUSE_ALU_BRANCH | AARCH64_FUSE_AES_AESMC
+   | AARCH64_FUSE_ALU_CBZ), /* fusible_ops  */
+  "16",	/* function_align.  */
+  "8",	/* jump_align.  */
+  "16",	/* loop_align.  */
+  3,	/* int_reassoc_width.  */
+  2,	/* fp_reassoc_width.  */
+  2,	/* vec_reassoc_width.  */
+  2,	/* min_div_recip_mul_sf.  */
+  2,	/* min_div_recip_mul_df.  */
+  0,	/* max_case_values.  */
+  tune_params::AUTOPREFETCHER_WEAK,	/* autoprefetcher_model.  */
+  (AARCH64_EXTRA_TUNE_NONE),	/* tune_flags.  */
+  _prefetch_tune
+};
+
 static const struct tune_params neoversen1_tunings =
 {
   _extra_costs,
diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index c7c4d1d..d2123f8 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -438,6 +438,7 @@
 (include "../arm/xgene1.md")
 (include "thunderx2t99.md")
 (include "tsv110.md")
+(include "thunderx3t11.md")
 
 ;; ---
 ;; Jumps and other miscellaneous insns
diff --git a/gcc/config/aarch64/thunderx3t11.md b/gcc/config/aarch64/thunderx3t11.md
new file mode 100644
index 000..8a4b824
--- /dev/null
+++ b/gcc/config/aarch64/thunderx3t11.md
@@ -0,0 +1,686 @@
+;; Cavium ThunderX 3 CN11xx pipeline description

[committed] openacc: Fix up declare-pr94120.C testcase [PR94533]

[Jakub Jelinek via Gcc-patches]

Hi!

On Wed, Mar 11, 2020 at 02:28:44PM +0100, Tobias Burnus wrote:
>   gcc/testsuite/
>   PR middle-end/94120
>   * c-c++-common/goacc/declare-pr94120.c: New.
>   * g++.dg/declare-pr94120.C: New.

This test has been put in a wrong directory, where OpenACC tests aren't
tested with -fopenacc, and also contained trailing semicolons.
I've moved it where it belongs, added dg-error directives and removed
the extra semicolons.

Tested on x86_64-linux, committed to trunk as obvious.

2020-04-08  Jakub Jelinek  

PR middle-end/94120
PR testsuite/94533
* g++.dg/declare-pr94120.C: Move test to ...
* g++.dg/goacc/declare-pr94120.C: ... here.  Add dg-error directives.
Remove semicolons after } at the end of namespaces.

diff --git a/gcc/testsuite/g++.dg/declare-pr94120.C 
b/gcc/testsuite/g++.dg/goacc/declare-pr94120.C
similarity index 60%
rename from gcc/testsuite/g++.dg/declare-pr94120.C
rename to gcc/testsuite/g++.dg/goacc/declare-pr94120.C
index 8515c4ff875..7aa56121e38 100644
--- a/gcc/testsuite/g++.dg/declare-pr94120.C
+++ b/gcc/testsuite/g++.dg/goacc/declare-pr94120.C
@@ -8,23 +8,23 @@ int b[8];
 namespace my {
  int d[8] = { 1, 2, 3, 4, 5, 6, 7, 8 };
  #pragma acc declare copyin (d)
-};
+}
 
 namespace outer {
   namespace inner {
 int e[8] = { 1, 2, 3, 4, 5, 6, 7, 8 };
 #pragma acc declare copyin (e)
-  };
-};
+  }
+}
 
 int f[8] = { 1, 2, 3, 4, 5, 6, 7, 8 };
 namespace my {
- #pragma acc declare copyin (f)
-};
+ #pragma acc declare copyin (f)/* { dg-error "'f' must be a 
variable declared in the same scope as '#pragma acc declare'" }  */
+}
 
 namespace outer {
   int g[8] = { 1, 2, 3, 4, 5, 6, 7, 8 };
   namespace inner {
-#pragma acc declare copyin (g)
-  };
-};
+#pragma acc declare copyin (g) /* { dg-error "'outer::g' must be a 
variable declared in the same scope as '#pragma acc declare'" }  */
+  }
+}


Jakub

[PATCH] RTEMS: Improve GCC specification

[Sebastian Huber]

Add a start/end file specification if the -qrtems option is present.
Allow targets to customize it.

Support the standard -nodefaultlibs option.

gcc/

* config/rtems.h (RTEMS_STARTFILE_SPEC): Define if undefined.
(RTEMS_ENDFILE_SPEC): Likewise.
(STARTFILE_SPEC): Update comment.  Add RTEMS_STARTFILE_SPEC.
(ENDFILE_SPEC): Add RTEMS_ENDFILE_SPEC.
(LIB_SPECS): Support -nodefaultlibs option.
* config/or1k/rtems.h (RTEMS_STARTFILE_SPEC): Define.
(RTEMS_ENDFILE_SPEC): Likewise.
* config/rs6000/rtems.h (RTEMS_STARTFILE_SPEC): Likewise.
(RTEMS_ENDFILE_SPEC): Likewise.
* config/v850/rtems.h (RTEMS_STARTFILE_SPEC): Likewise.
(RTEMS_ENDFILE_SPEC): Likewise.
---
 gcc/config/or1k/rtems.h   |  3 +++
 gcc/config/rs6000/rtems.h |  3 +++
 gcc/config/rtems.h| 26 ++
 gcc/config/v850/rtems.h   |  3 +++
 4 files changed, 27 insertions(+), 8 deletions(-)

diff --git a/gcc/config/or1k/rtems.h b/gcc/config/or1k/rtems.h
index 94731435f44..d4b8fef3dc7 100644
--- a/gcc/config/or1k/rtems.h
+++ b/gcc/config/or1k/rtems.h
@@ -28,3 +28,6 @@
builtin_assert ("system=rtems");\
 }  \
   while (0)
+
+#define RTEMS_STARTFILE_SPEC "crtbegin%O%s"
+#define RTEMS_ENDFILE_SPEC "crtend%O%s"
diff --git a/gcc/config/rs6000/rtems.h b/gcc/config/rs6000/rtems.h
index 6ce05bfc6d6..40db6606f17 100644
--- a/gcc/config/rs6000/rtems.h
+++ b/gcc/config/rs6000/rtems.h
@@ -292,3 +292,6 @@
   "%{mads|myellowknife|mmvme|msim:%G %L %G;" \
   "!mcall-*|mcall-linux:" GNU_USER_TARGET_LINK_GCC_C_SEQUENCE_SPEC ";" \
   ":%G %L %G}"
+
+#define RTEMS_STARTFILE_SPEC "ecrti%O%s rtems_crti%O%s crtbegin%O%s"
+#define RTEMS_ENDFILE_SPEC "crtend%O%s rtems_crtn%O%s ecrtn%O%s"
diff --git a/gcc/config/rtems.h b/gcc/config/rtems.h
index 55d568f83b5..30ad6258949 100644
--- a/gcc/config/rtems.h
+++ b/gcc/config/rtems.h
@@ -22,15 +22,25 @@
see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
.  */
 
+#ifndef RTEMS_STARTFILE_SPEC
+#define RTEMS_STARTFILE_SPEC "crti%O%s crtbegin%O%s"
+#endif
+
+#ifndef RTEMS_ENDFILE_SPEC
+#define RTEMS_ENDFILE_SPEC "crtend%O%s crtn%O%s"
+#endif
+
 /*
- * Dummy start/end specification to let linker work as
- * needed by autoconf scripts using this compiler.
+ * The crt0.o is a dummy start file to let the linker work as needed by
+ * autoconf scripts using this compiler.
  */
 #undef STARTFILE_SPEC
-#define STARTFILE_SPEC "crt0.o%s"
+#define STARTFILE_SPEC "%{!qrtems:crt0%O%s} " \
+"%{qrtems:%{!nostdlib:%{!nostartfiles:" RTEMS_STARTFILE_SPEC "}}}"
 
 #undef ENDFILE_SPEC
-#define ENDFILE_SPEC   ""
+#define ENDFILE_SPEC \
+"%{qrtems:%{!nostdlib:%{!nostartfiles:" RTEMS_ENDFILE_SPEC "}}}"
 
 /*
  * Some targets do not set up LIB_SPECS, override it, here.
@@ -38,10 +48,10 @@
 #define STD_LIB_SPEC "%{!shared:%{g*:-lg} 
%{!p:%{!pg:-lc}}%{p:-lc_p}%{pg:-lc_p}}"
 
 #undef LIB_SPEC
-#define LIB_SPEC "%{!qrtems: " STD_LIB_SPEC "} " \
-"%{!nostdlib: %{qrtems: --start-group \
- -lrtemsbsp -lrtemscpu \
- -latomic -lc -lgcc --end-group %{!qnolinkcmds: -T linkcmds%s}}}"
+#define LIB_SPEC "%{!qrtems:" STD_LIB_SPEC "} " \
+"%{qrtems:%{!nostdlib:%{!nodefaultlibs:" \
+"--start-group -lrtemsbsp -lrtemscpu -latomic -lc -lgcc --end-group} " \
+"%{!qnolinkcmds:-T linkcmds%s}}}"
 
 #define TARGET_POSIX_IO
 
diff --git a/gcc/config/v850/rtems.h b/gcc/config/v850/rtems.h
index 3f7d39a2cd1..e261ea3b417 100644
--- a/gcc/config/v850/rtems.h
+++ b/gcc/config/v850/rtems.h
@@ -39,3 +39,6 @@
 %{!mv850es:%{!mv850e1:%{mv*:-mv%*}} \
 %{m8byte-align:-m8byte-align} \
 %{mgcc-abi:-mgcc-abi}}"
+
+#define RTEMS_STARTFILE_SPEC ""
+#define RTEMS_ENDFILE_SPEC ""
-- 
2.16.4

Re: [PATCH v2] c++: Fix ICE-on-invalid with lambda template [PR94507]

[Jason Merrill via Gcc-patches]

On 4/8/20 9:44 AM, Marek Polacek wrote:

On Wed, Apr 08, 2020 at 08:55:08AM -0400, Jason Merrill via Gcc-patches wrote:

On 4/6/20 9:05 PM, Marek Polacek wrote:

While reducing something else I noticed that we ICE on the following
invalid code.  In tsubst_lambda_expr, tsubst_template_decl has already
reported an error and returned the error_mark_node, so make sure we
don't ICE on that.  I'm using a goto here because we still have to
do finish_struct because it does popclass ().

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?

PR c++/94507 - ICE-on-invalid with lambda template.
* pt.c (tsubst_lambda_expr): Cope when tsubst_template_decl returns
error_mark_node.


OK.


* g++.dg/cpp2a/lambda-generic7.C: New test.
---
   gcc/cp/pt.c  |  6 ++
   gcc/testsuite/g++.dg/cpp2a/lambda-generic7.C | 10 ++
   2 files changed, 16 insertions(+)
   create mode 100644 gcc/testsuite/g++.dg/cpp2a/lambda-generic7.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 617c22f..f804ba18692 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -18876,6 +18876,11 @@ tsubst_lambda_expr (tree t, tree args, tsubst_flags_t 
complain, tree in_decl)
 if (oldtmpl)
{
  tmpl = tsubst_template_decl (oldtmpl, args, complain, fntype);
+ if (tmpl == error_mark_node)
+   {
+ r = error_mark_node;
+ goto out;
+   }
  fn = DECL_TEMPLATE_RESULT (tmpl);
  finish_member_declaration (tmpl);
}


Perhaps we also want an early exit if the tsubst_function_decl in the else
clause returns error_mark_node?


Can't hurt (but don't have a testcase for it).

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?

-- >8 --
While reducing something else I noticed that we ICE on the following
invalid code.  In tsubst_lambda_expr, tsubst_template_decl has already
reported an error and returned the error_mark_node, so make sure we
don't ICE on that.  I'm using a goto here because we still have to
do finish_struct because it does popclass ().

PR c++/94507 - ICE-on-invalid with lambda template.
* pt.c (tsubst_lambda_expr): Cope when tsubst_template_decl or
tsubst_function_decl returns error_mark_node.

* g++.dg/cpp2a/lambda-generic7.C: New test.
---
  gcc/cp/pt.c  | 11 +++
  gcc/testsuite/g++.dg/cpp2a/lambda-generic7.C | 10 ++
  2 files changed, 21 insertions(+)
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/lambda-generic7.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 617c22f..b9cbdb36de7 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -18876,6 +18876,11 @@ tsubst_lambda_expr (tree t, tree args, tsubst_flags_t 
complain, tree in_decl)
if (oldtmpl)
{
  tmpl = tsubst_template_decl (oldtmpl, args, complain, fntype);
+ if (tmpl == error_mark_node)
+   {
+ r = error_mark_node;
+ goto out;
+   }
  fn = DECL_TEMPLATE_RESULT (tmpl);
  finish_member_declaration (tmpl);
}
@@ -18883,6 +1,11 @@ tsubst_lambda_expr (tree t, tree args, tsubst_flags_t 
complain, tree in_decl)
{
  tmpl = NULL_TREE;
  fn = tsubst_function_decl (oldfn, args, complain, fntype);
+ if (fn == error_mark_node)
+   {
+ r = error_mark_node;
+ goto out;
+   }
  finish_member_declaration (fn);
}
  
@@ -18948,6 +18958,7 @@ tsubst_lambda_expr (tree t, tree args, tsubst_flags_t complain, tree in_decl)

maybe_add_lambda_conv_op (type);
  }
  
+out:

finish_struct (type, /*attr*/NULL_TREE);
  
insert_pending_capture_proxies ();

diff --git a/gcc/testsuite/g++.dg/cpp2a/lambda-generic7.C 
b/gcc/testsuite/g++.dg/cpp2a/lambda-generic7.C
new file mode 100644
index 000..bedba683671
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/lambda-generic7.C
@@ -0,0 +1,10 @@
+// PR c++/94507 - ICE-on-invalid with lambda template.
+// { dg-do compile { target c++2a } }
+
+struct S { };
+
+template
+auto foo(T, U)
+{
+  [] <> () { foo (S{}, S{}); }; // { dg-error "expected" }
+}

base-commit: 130f703da0c0d7b785d394b17df884379b4aadd9

Re: [PATCH] reject scalar array initialization with nullptr [PR94510]

[Martin Sebor via Gcc-patches]

On 4/7/20 3:36 PM, Marek Polacek wrote:

On Tue, Apr 07, 2020 at 02:46:52PM -0600, Martin Sebor wrote:

On 4/7/20 1:50 PM, Marek Polacek wrote:

On Tue, Apr 07, 2020 at 12:50:48PM -0600, Martin Sebor via Gcc-patches wrote:

Among the numerous regressions introduced by the change committed
to GCC 9 to allow string literals as template arguments is a failure
to recognize the C++ nullptr and GCC's __null constants as pointers.
For one, I didn't realize that nullptr, being a null pointer constant,
doesn't have a pointer type, and two, I didn't think of __null (which
is a special integer constant that NULL sometimes expands to).

The attached patch adjusts the special handling of trailing zero
initializers in reshape_init_array_1 to recognize both kinds of
constants and avoid treating them as zeros of the array integer
element type.  This restores the expected diagnostics when either
constant is used in the initializer list.

Martin



PR c++/94510 - nullptr_t implicitly cast to zero twice in std::array

gcc/cp/ChangeLog:

PR c++/94510
* decl.c (reshape_init_array_1): Exclude mismatches with all kinds
of pointers.

gcc/testsuite/ChangeLog:

PR c++/94510
* g++.dg/init/array57.C: New test.
* g++.dg/init/array58.C: New test.

diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index a127734af69..692c8ed73f4 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -6041,9 +6041,14 @@ reshape_init_array_1 (tree elt_type, tree max_index, 
reshape_iter *d,
TREE_CONSTANT (new_init) = false;
 /* Pointers initialized to strings must be treated as non-zero
-even if the string is empty.  */
+even if the string is empty.  Handle all kinds of pointers,
+including std::nullptr and GCC's __nullptr, neither of which
+has a pointer type.  */
 tree init_type = TREE_TYPE (elt_init);
-  if (POINTER_TYPE_P (elt_type) != POINTER_TYPE_P (init_type)
+  bool init_is_ptr = (POINTER_TYPE_P (init_type)
+ || NULLPTR_TYPE_P (init_type)
+ || null_node_p (elt_init));
+  if (POINTER_TYPE_P (elt_type) != init_is_ptr
  || !type_initializer_zero_p (elt_type, elt_init))
last_nonzero = index;


It looks like this still won't handle e.g. pointers to member functions,
e.g.

struct S { };
int arr[3] = { (void (S::*) ()) 0, 0, 0 };

would still be accepted.  You could use TYPE_PTR_OR_PTRMEM_P instead of
POINTER_TYPE_P to catch this case.


Good catch!  That doesn't fail because unlike null data member pointers
which are represented as -1, member function pointers are represented
as a zero.

I had looked for an API that would answer the question: "is this
expression a pointer?" without having to think of all the different
kinds of them but all I could find was null_node_p().  Is this a rare,
isolated case that having an API like that wouldn't be worth having
or should I add one like in the attached update?

Martin



PR c++/94510 - nullptr_t implicitly cast to zero twice in std::array

gcc/cp/ChangeLog:

PR c++/94510
* decl.c (reshape_init_array_1): Exclude mismatches with all kinds
of pointers.
* gcc/cp/cp-tree.h (null_pointer_constant_p): New function.


(Drop the gcc/cp/.)


+/* Returns true if EXPR is a null pointer constant of any type.  */
+
+inline bool
+null_pointer_constant_p (tree expr)
+{
+  STRIP_ANY_LOCATION_WRAPPER (expr);
+  if (expr == null_node)
+return true;
+  tree type = TREE_TYPE (expr);
+  if (NULLPTR_TYPE_P (type))
+return true;
+  if (POINTER_TYPE_P (type))
+return integer_zerop (expr);
+  return null_member_pointer_value_p (expr);
+}
+


We already have a null_ptr_cst_p so it would be sort of confusing to have
this as well.  But are you really interested in whether it's a null pointer,
not just a pointer?


The goal of the code is to detect a mismatch in "pointerness" between
an initializer expression and the type of the initialized element, so
it needs to know if the expression is a pointer (non-nulls pointers
are detected in type_initializer_zero_p).  That means testing a number
of IMO unintuitive conditions:

  TYPE_PTR_OR_PTRMEM_P (TREE_TYPE (expr))
  || NULLPTR_TYPE_P (TREE_TYPE (expr))
  || null_node_p (expr)

I don't know if this type of a query is common in the C++ FE but unless
this is an isolated use case then besides fixing the bug I thought it
would be nice to make it easier to get the test above right, or at least
come close to it.

Since null_pointer_constant_p already exists (but isn't suitable here
because it returns true for plain literal zeros) would a function like

  /* Returns true if EXPR is a pointer of any type, including nullptr
 and __null.  */

  inline bool
  pointer_p (tree expr)
  {
STRIP_ANY_LOCATION_WRAPPER (expr);
if (expr == null_node)
  return true;
tree type = TREE_TYPE (expr);
if (NULLPTR_TYPE_P (type))
  return true;
return TYPE_PTR_OR_PTRMEM_P (type);
  

Re: [C/C++, OpenACC] Reject vars of different scope in acc declare (PR94120)

[H.J. Lu via Gcc-patches]

On Wed, Apr 8, 2020 at 12:55 AM Tobias Burnus  wrote:
>
> I have now committed this patch
> as r10-7614-g13e41d8b9d3d7598c72c38acc86a3d97046c8373,

On Linux/x86, I got

FAIL: g++.dg/declare-pr94120.C  -std=c++14 (test for excess errors)
FAIL: g++.dg/declare-pr94120.C  -std=c++17 (test for excess errors)
FAIL: g++.dg/declare-pr94120.C  -std=c++2a (test for excess errors)
FAIL: g++.dg/declare-pr94120.C  -std=c++98 (test for excess errors)

> reading "so we shall accept it" as approval …
>
> On 4/1/20 9:07 AM, Thomas Schwinge wrote:
>
> > Even if the ICE is then fixed, should we still keep
> >  open (with a note) until
> >  is
> > resolved/published?
>
> I decided to close it and mention the namelist issue and
> the now-fixed PR in PR84140 (which is about (non)static
> class member variables, which is also covered in Issue 288).
>
> > Regarding the C/C++ patch you posted: I'm not at all familiar with the
> > front ends' scoping implementation.  But, given that your patch really
> > only touches the OpenACC 'declare' code paths, it can't cause any harm
> > otherwise, so we shall accept it.  Maybe Jakub has any comments, though?
>
> >>> +c_check_oacc_same_scope (tree decl)
> >> Is the function really specific to OpenACC? If not, then "_oacc"
> >> could be dropped from its name. How about "c_check_current_scope"?
> > Yeah, that may be a good idea.  Similar constructs seem to be used in a
> > few other places, though without the 'DECL_NAME' indirection.
>
> I now use c_check_in_current_scope.
>
> Tobias
> -
> Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
> Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, 
> Alexander Walter



-- 
H.J.

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

[Kito Cheng]

ping

On Tue, Mar 31, 2020 at 4:33 PM Kito Cheng  wrote:
>
>  - 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
> @@ 

Re: [patch,committed] Move gfortran.dg/dec_math_5.f90 to ./ieee/ (was: Re: PATCH -- Fix degree trignometric functions)

[Fritz Reese via Gcc-patches]

Andreas, thank you for the report.

Tobias, thank you for the fix.

---
Fritz Reese

On Wed, Apr 8, 2020 at 12:02 PM Tobias Burnus  wrote:
>
> Hi Andreas,
>
> thanks for the report. In principle, it would be helpful to know on
> which target you are running the test case.
>
> However, I assume that either of the following went wrong:
> * Target does not support IEEE
> * It supports it, but gfortran's intrinsic search path does
>not point to directory in which the ieee modules are
>
> That's solved by moving the test case to the ieee/ subdirectory
> which has a check whether IEEE works and also sets the intrinsic
> module include path (-fintrinsic-modules-path $specpath/libgfortran/).
>
> I have now committed it as obvious – but I would be good when you
> can confirm that it works (PASS if it should support IEEE or, if not,
> UNSUPPORTED).
>
> See r10-7631-gfaa0817311f43e0d4d223d53c816b0c74ec35c4e
> or attachment.
>
> Cheers,
>
> Tobias
>
> On 4/8/20 5:04 PM, Andreas Schwab wrote:
>
> > FAIL: gfortran.dg/dec_math_5.f90   -O0  (test for excess errors)
> > Excess errors:
> > /opt/gcc/gcc-20200408/gcc/testsuite/gfortran.dg/dec_math_5.f90:132:9: Fatal 
> > Error: Cannot open module file 'ieee_arithmetic.mod' for reading at (1): No 
> > such file or directory
> > compilation terminated.
> >
> > Andreas.
> >
> -
> Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
> Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, 
> Alexander Walter

Re: [RFC, Instruction Scheduler, Stage1] New hook/code to perform fusion of dependent instructions

[Pat Haugen via Gcc-patches]

On 4/8/20 2:46 AM, Richard Biener wrote:
>> I have coded up a proof of concept that implements our needs via a new
>> target hook. The hook is passed a pair of dependent insns and returns if
>> they are a fusion candidate. It is called while removing the forward
>> dependencies of the just scheduled insn. If a dependent insn becomes
>> available to schedule and it's a fusion candidate with the just
>> scheduled insn, then the new code moves it to the ready list (if
>> necessary) and marks it as SCHED_GROUP (piggy-backing on the existing
>> code used by TARGET_SCHED_MACRO_FUSION) to make sure the fusion
>> candidate will be scheduled next. Following is the scheduling part of
>> the diff. Does this sound like a feasible approach? I welcome any
>> comments/discussion.
> It would be nice test if the i386 use of TARGET_SCHED_MACRO_FUSION hooks
> for compare + branch fusion can be transitioned to that scheme.  I think your
> proposal doesn't improve things there since we can never schedule
> branches earlier
> but we could schedule the compare later.  But your proposal only
> affects scheduling
> of later insns, not the order of insns getting onto the ready list?

Yes, your understanding is correct, my approach only affects later
dependent insns. The first insn of the fusion pair will be scheduled
according to existing priority based scheduling.

-Pat

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

[Jeff Law via Gcc-patches]

On Wed, 2020-04-08 at 09:23 -0700, H.J. Lu wrote:
> On Wed, Apr 8, 2020 at 9:16 AM Jeff Law  wrote:
> > On Tue, 2020-03-31 at 08:11 -0700, H.J. Lu via Gcc-patches wrote:
> > > 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.
> > Can you just call constant_call_address_operand rather than copying its
> > contents?
> 
> I wish I could.  constant_call_address_operand uses SYMBOL_REF_DLLIMPORT_P 
> (op)
> But I need to use DECL_DLLIMPORT_P (cfun->decl)).
Sigh.  In that case I guess the patch is OK as-is.  

jeff
> 

RE: [PATCH] PR target/48240

[Kyrylo Tkachov]

Hi Andrea

> -Original Message-
> From: Gcc-patches  On Behalf Of Andrea
> Corallo
> Sent: 08 April 2020 15:19
> To: gcc-patches@gcc.gnu.org
> Cc: nd 
> Subject: [PATCH] PR target/48240
> 
> Hi all,
> 
> I'd like to submit this for PR48240.
> 
> Bootstrapped on aarch64-unknown-linux-gnu.
> Okay for trunk when finished with regression?
> 
> Andrea
> 
> gcc/ChangeLog
> 
> 2020-??-??  Andrea Corallo  
> 
>   PR target/48240
>   * gcc/config/aarch64/falkor-tag-collision-avoidance.c
>   (valid_src_p): Fix missing rtx type check.
> 
> gcc/testsuite/ChangeLog
> 
> 2020-??-??  Andrea Corallo  
> 
>   * gcc.target/aarch64/pr48240.c: New test.

>From 246337341a8b58c61dc29d2198b244da737b3ef0 Mon Sep 17 00:00:00 2001
From: Andrea Corallo 
Date: Wed, 8 Apr 2020 13:38:28 +0100
Subject: [PATCH] pr48240

---
 gcc/config/aarch64/falkor-tag-collision-avoidance.c | 9 ++---
 gcc/testsuite/gcc.target/aarch64/pr48240.c  | 9 +
 2 files changed, 15 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/aarch64/pr48240.c

diff --git a/gcc/config/aarch64/falkor-tag-collision-avoidance.c 
b/gcc/config/aarch64/falkor-tag-collision-avoidance.c
index 719df484ee61..4e07a43282f7 100644
--- a/gcc/config/aarch64/falkor-tag-collision-avoidance.c
+++ b/gcc/config/aarch64/falkor-tag-collision-avoidance.c
@@ -538,9 +538,12 @@ valid_src_p (rtx src, rtx_insn *insn, struct loop *loop, 
bool *pre_post,
   if (!aarch64_classify_address (, XEXP (x, 0), mode, true))
 return false;
 
-  unsigned regno = REGNO (addr.base);
-  if (global_regs[regno] || fixed_regs[regno])
-return false;
+  if (REG_P (addr.base))
+{
+  unsigned regno = REGNO (addr.base);
+  if (global_regs[regno] || fixed_regs[regno])
+   return false;
+}

I think we want to just return false here if !REG_P (addr.base) rather than 
fall through?

 
   if (addr.type == ADDRESS_REG_WB)
 {
diff --git a/gcc/testsuite/gcc.target/aarch64/pr48240.c 
b/gcc/testsuite/gcc.target/aarch64/pr48240.c
new file mode 100644
index ..012af6afeca7
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/pr48240.c
@@ -0,0 +1,9 @@
+/* { dg-do compile } */
+/* { dg-options "-v -Os -mcpu=falkor -mpc-relative-literal-loads 
-mcmodel=large" } */

We shouldn't need the "-v" here...

Ok with those changes.
Thanks,
Kyrill

+
+extern void bar(const char *);
+
+void foo(void) {
+  for (;;)
+bar("");
+}
-- 
2.17.1

Re: [PATCH] PR target/48240

[Richard Sandiford]

Andrea Corallo  writes:
> Hi all,
>
> I'd like to submit this for PR48240.
>
> Bootstrapped on aarch64-unknown-linux-gnu.
> Okay for trunk when finished with regression?

OK, but the PR number looks like a typo.  Also:

> Andrea
>
> gcc/ChangeLog
>
> 2020-??-??  Andrea Corallo  
>
>   PR target/48240
>   * gcc/config/aarch64/falkor-tag-collision-avoidance.c
>   (valid_src_p): Fix missing rtx type check.

no gcc/ prefix here.

Thanks,
Richard

>
> gcc/testsuite/ChangeLog
>
> 2020-??-??  Andrea Corallo  
>
>   * gcc.target/aarch64/pr48240.c: New test.
>
> From 246337341a8b58c61dc29d2198b244da737b3ef0 Mon Sep 17 00:00:00 2001
> From: Andrea Corallo 
> Date: Wed, 8 Apr 2020 13:38:28 +0100
> Subject: [PATCH] pr48240
>
> ---
>  gcc/config/aarch64/falkor-tag-collision-avoidance.c | 9 ++---
>  gcc/testsuite/gcc.target/aarch64/pr48240.c  | 9 +
>  2 files changed, 15 insertions(+), 3 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.target/aarch64/pr48240.c
>
> diff --git a/gcc/config/aarch64/falkor-tag-collision-avoidance.c 
> b/gcc/config/aarch64/falkor-tag-collision-avoidance.c
> index 719df484ee61..4e07a43282f7 100644
> --- a/gcc/config/aarch64/falkor-tag-collision-avoidance.c
> +++ b/gcc/config/aarch64/falkor-tag-collision-avoidance.c
> @@ -538,9 +538,12 @@ valid_src_p (rtx src, rtx_insn *insn, struct loop *loop, 
> bool *pre_post,
>if (!aarch64_classify_address (, XEXP (x, 0), mode, true))
>  return false;
>  
> -  unsigned regno = REGNO (addr.base);
> -  if (global_regs[regno] || fixed_regs[regno])
> -return false;
> +  if (REG_P (addr.base))
> +{
> +  unsigned regno = REGNO (addr.base);
> +  if (global_regs[regno] || fixed_regs[regno])
> + return false;
> +}
>  
>if (addr.type == ADDRESS_REG_WB)
>  {
> diff --git a/gcc/testsuite/gcc.target/aarch64/pr48240.c 
> b/gcc/testsuite/gcc.target/aarch64/pr48240.c
> new file mode 100644
> index ..012af6afeca7
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/aarch64/pr48240.c
> @@ -0,0 +1,9 @@
> +/* { dg-do compile } */
> +/* { dg-options "-v -Os -mcpu=falkor -mpc-relative-literal-loads 
> -mcmodel=large" } */
> +
> +extern void bar(const char *);
> +
> +void foo(void) {
> +  for (;;)
> +bar("");
> +}

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

[H.J. Lu via Gcc-patches]

On Wed, Apr 8, 2020 at 9:16 AM Jeff Law  wrote:
>
> On Tue, 2020-03-31 at 08:11 -0700, H.J. Lu via Gcc-patches wrote:
> > 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.
> Can you just call constant_call_address_operand rather than copying its 
> contents?

I wish I could.  constant_call_address_operand uses SYMBOL_REF_DLLIMPORT_P (op)
But I need to use DECL_DLLIMPORT_P (cfun->decl)).

-- 
H.J.

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

[Jeff Law via Gcc-patches]

On Tue, 2020-03-31 at 08:11 -0700, H.J. Lu via Gcc-patches wrote:
> 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.
Can you just call constant_call_address_operand rather than copying its 
contents?

jeff
> 

Re: [PATCH] i386: Don't use AVX512F integral masks for V*TImode [PR94438]

[Jeff Law via Gcc-patches]

On Fri, 2020-04-03 at 00:26 +0200, Jakub Jelinek wrote:
> Hi!
> 
> The ix86_get_mask_mode hook uses int mask for 512-bit vectors or 128/256-bit
> vectors with AVX512VL (that is correct), and only for V*[SD][IF]mode if not
> AVX512BW (also correct), but with AVX512BW it would stop checking the
> elem_size altogether and pretend the hw has masking support for V*TImode
> etc., which it doesn't.  That can lead to various ICEs later on.
> 
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
> trunk?
> 
> 2020-04-02  Jakub Jelinek  
> 
>   PR target/94438
>   * config/i386/i386.c (ix86_get_mask_mode): Only use int mask for
> elem_size
>   1, 2, 4 and 8.
> 
>   * gcc.target/i386/avx512bw-pr94438.c: New test.
>   * gcc.target/i386/avx512vlbw-pr94438.c: New test.
OK
jeff
> 

Re: Ping: [PATCH] testsuite: Tweak check-function-bodies interface

[Jeff Law via Gcc-patches]

On Fri, 2020-04-03 at 17:37 +0100, Richard Sandiford wrote:
> Ping for the doc/sourcebuild.texi and lib/scanasm.exp parts.
> 
> Richard Sandiford  writes:
> > In g:2171a9207f51bc486ed9c502cb4da706f594615e I'd tried to fix
> > various ILP32 testsuite failures by restricting some tests to LP64.
> > Unfortunately, I messed up the check-function-bodies syntax and passed
> > the target selector as the "option" parameter, which had the effect of
> > disabling the tests for both ILP32 and LP64.  "Oops."
> > 
> > The fix ought to have been to add "" as the option parameter.  However,
> > check-function-bodies wasn't treating "" in the same way as an omitted
> > argument.  The easiest fix seemed to be turn the argument into a list of
> > options, which also makes the interface a bit more general.
> > 
> > Having done that, it seemed a good idea to check for things that look
> > like target/xfail selectors, so that the mistake isn't silent next time.
> > 
> > Tested on aarch64-linux-gnu and aarch64_be-elf.  OK to install?
> > 
> > Richard
> 
> 2020-03-17  Richard Sandiford  
> 
> gcc/
>   * doc/sourcebuild.texi (check-function-bodies): Treat the third
>   parameter as a list of option regexps and require each regexp
>   to match.
> 
> gcc/testsuite/
>   * lib/scanasm.exp (check-function-bodies): Treat the third
>   parameter as a list of option regexps and require each regexp
>   to match.  Check for cases in which a target/xfail selector
>   was mistakenly passed to the options argument.
>   * gcc.target/aarch64/sve/pcs/args_1.c: Add an empty options list
>   to the invocation of check-function-bodies.
>   * gcc.target/aarch64/sve/pcs/args_2.c: Likewise.
>   * gcc.target/aarch64/sve/pcs/args_3.c: Likewise.
>   * gcc.target/aarch64/sve/pcs/args_4.c: Likewise.
>   * gcc.target/aarch64/sve/pcs/return_1.c: Likewise.
>   * gcc.target/aarch64/sve/pcs/return_1_1024.c: Likewise.
>   * gcc.target/aarch64/sve/pcs/return_1_128.c: Likewise.
>   * gcc.target/aarch64/sve/pcs/return_1_2048.c: Likewise.
>   * gcc.target/aarch64/sve/pcs/return_1_256.c: Likewise.
>   * gcc.target/aarch64/sve/pcs/return_1_512.c: Likewise.
>   * gcc.target/aarch64/sve/pcs/return_2.c: Likewise.
>   * gcc.target/aarch64/sve/pcs/return_3.c: Likewise.
>   * gcc.target/aarch64/sve/pcs/return_4.c: Likewise.
>   * gcc.target/aarch64/sve/pcs/return_4_1024.c: Likewise.
>   * gcc.target/aarch64/sve/pcs/return_4_128.c: Likewise.
>   * gcc.target/aarch64/sve/pcs/return_4_2048.c: Likewise.
>   * gcc.target/aarch64/sve/pcs/return_4_256.c: Likewise.
>   * gcc.target/aarch64/sve/pcs/return_4_512.c: Likewise.
>   * gcc.target/aarch64/sve/pcs/return_5.c: Likewise.
>   * gcc.target/aarch64/sve/pcs/return_5_1024.c: Likewise.
>   * gcc.target/aarch64/sve/pcs/return_5_128.c: Likewise.
>   * gcc.target/aarch64/sve/pcs/return_5_2048.c: Likewise.
>   * gcc.target/aarch64/sve/pcs/return_5_256.c: Likewise.
>   * gcc.target/aarch64/sve/pcs/return_5_512.c: Likewise.
>   * gcc.target/aarch64/sve/pcs/return_6.c: Likewise.
>   * gcc.target/aarch64/sve/pcs/return_6_1024.c: Likewise.
>   * gcc.target/aarch64/sve/pcs/return_6_128.c: Likewise.
>   * gcc.target/aarch64/sve/pcs/return_6_2048.c: Likewise.
>   * gcc.target/aarch64/sve/pcs/return_6_256.c: Likewise.
>   * gcc.target/aarch64/sve/pcs/return_6_512.c: Likewise.
>   * gcc.target/aarch64/sve/pcs/saves_2_be_nowrap.c: Likewise.
>   * gcc.target/aarch64/sve/pcs/saves_2_be_wrap.c: Likewise.
>   * gcc.target/aarch64/sve/pcs/saves_2_le_nowrap.c: Likewise.
>   * gcc.target/aarch64/sve/pcs/saves_2_le_wrap.c: Likewise.
>   * gcc.target/aarch64/sve/pcs/saves_3.c: Likewise.
>   * gcc.target/aarch64/sve/pcs/saves_4_be.c: Likewise.
>   * gcc.target/aarch64/sve/pcs/saves_4_le.c: Likewise.
>   * gcc.target/aarch64/sve/pcs/stack_clash_2_128.c: Likewise.
>   * gcc.target/aarch64/sve/pcs/varargs_1.c: Likewise.
>   * gcc.target/aarch64/sve/pcs/varargs_2_f16.c: Likewise.
>   * gcc.target/aarch64/sve/pcs/varargs_2_f32.c: Likewise.
>   * gcc.target/aarch64/sve/pcs/varargs_2_f64.c: Likewise.
>   * gcc.target/aarch64/sve/pcs/varargs_2_s16.c: Likewise.
>   * gcc.target/aarch64/sve/pcs/varargs_2_s32.c: Likewise.
>   * gcc.target/aarch64/sve/pcs/varargs_2_s64.c: Likewise.
>   * gcc.target/aarch64/sve/pcs/varargs_2_s8.c: Likewise.
>   * gcc.target/aarch64/sve/pcs/varargs_2_u16.c: Likewise.
>   * gcc.target/aarch64/sve/pcs/varargs_2_u32.c: Likewise.
>   * gcc.target/aarch64/sve/pcs/varargs_2_u64.c: Likewise.
>   * gcc.target/aarch64/sve/pcs/varargs_2_u8.c: Likewise.
OK
jeff
> 

Re: [PATCH] Allow new/delete operator deletion only for replaceable.

[Jakub Jelinek via Gcc-patches]

On Wed, Apr 08, 2020 at 05:46:52PM +0200, Jan Hubicka wrote:
> I am not quite sure about the offloading done by openMP - I think that
> one produces new decls.

Yes, it does.  It copies some FUNCTION_DECL flags over, but only selected
ones (and all attributes but removes a few afterwards).

Jakub

Re: [PATCH v2 1/2] RISC-V: Add shorten_memrefs pass

[Jim Wilson]

On Wed, Feb 19, 2020 at 3:40 AM Craig Blackmore
 wrote:
> On 10/12/2019 18:28, Craig Blackmore wrote:
> Thank you for your review. I have posted an updated patch below which I think
> addresses your comments.
>
> Ping
>
> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00712.html

This looks OK.  There are some minor issues.

(riscv_new_address_profitable_p): New function.
(TARGET_NEW_ADDRESS_PROFITABLE_P): Define.

These are actually in part2, and part2 already has changelog entries
for them, so these can just be dropped.

+  /* When optimizing for size, make uncompressible 32-bit addresses more
+   * expensive so that compressible 32-bit addresses are preferred.  */
+  if (!speed && riscv_mshorten_memrefs && mode == SImode
+  && !riscv_compressed_lw_address_p (addr))
+return riscv_address_insns (addr, mode, false) + 1;

I think that there should be a TARGET_RVC check here, just like in the gate
function for the new pass.  But I also suspect that this probably
doesn't matter much.

> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00713.html

This also looks OK to me, but adding a new target hook is something
that should really wait for stage1 which should only be a few weeks
away now.  That will also give us more time to test the patch before
it appears in a gcc release.  So this is OK once stage1 opens.

Jim

Re: unreliable/confusing dg-add-options arm_fp16_alternatives

[Jeff Law via Gcc-patches]

On Wed, 2020-04-08 at 12:27 -0300, Alexandre Oliva wrote:
> On Mar 27, 2020, Alexandre Oliva  wrote:
> 
> > So, here are some potential fixes:
> > - install the patchlet for fp16-aapcs-3.c above, and be done with it
> > - add an arm_fp16_hw requirement to this test
> > - add to check_effective_target_arm_fp16_alternative_ok_nocache above a
> >   check for arm_fp16, besides arm32.
> > Unrelated potential fix, assuming it's a cut rather than intended:
> > - drop the et_arm_neon_fp16_flags settings from the unrelated (?)
> >   check_effective_target_arm_fp16_alternative_ok_nocache
> 
> Here's the patchlet turned into a patch submission:
> 
> 
> add missing fp16 options
> 
> dg-require-effective-target arm_fp16_alternative_ok may pass even when
> arm_fp16_ok doesn't, and the latter's failure inhibits dg-add-options
> arm_fp16_alternative.  Requiring arm_fp16_ok would disable the test,
> but if we just pass it the -mfp16-format=alternative option, it passes
> even without arm_fp16_ok.  Sibling test fp16-aapcs-4.c underwent a
> similar change, so I'm proposing the explicit option to fp16-aapcs-3.c
> as well.
> 
> Tested with an arm-eabi cross compiler configured for a machine with
> -mfloat-abi=hard -mfpu=vfpv3-d16.  Ok to install?
> 
> 
> for  gcc/testsuite/ChangeLog
> 
>   * gcc.target/arm/fp16-aapcs-3.c: Explicitly use the
>   -mfp16-format=alternative option.
OK
jeff
> 

[patch,committed] Move gfortran.dg/dec_math_5.f90 to ./ieee/ (was: Re: PATCH -- Fix degree trignometric functions)

[Tobias Burnus]

Hi Andreas,

thanks for the report. In principle, it would be helpful to know on
which target you are running the test case.

However, I assume that either of the following went wrong:
* Target does not support IEEE
* It supports it, but gfortran's intrinsic search path does
  not point to directory in which the ieee modules are

That's solved by moving the test case to the ieee/ subdirectory
which has a check whether IEEE works and also sets the intrinsic
module include path (-fintrinsic-modules-path $specpath/libgfortran/).

I have now committed it as obvious – but I would be good when you
can confirm that it works (PASS if it should support IEEE or, if not,
UNSUPPORTED).

See r10-7631-gfaa0817311f43e0d4d223d53c816b0c74ec35c4e
or attachment.

Cheers,

Tobias

On 4/8/20 5:04 PM, Andreas Schwab wrote:


FAIL: gfortran.dg/dec_math_5.f90   -O0  (test for excess errors)
Excess errors:
/opt/gcc/gcc-20200408/gcc/testsuite/gfortran.dg/dec_math_5.f90:132:9: Fatal 
Error: Cannot open module file 'ieee_arithmetic.mod' for reading at (1): No 
such file or directory
compilation terminated.

Andreas.


-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter
commit faa0817311f43e0d4d223d53c816b0c74ec35c4e
Author: Tobias Burnus 
Date:   Wed Apr 8 17:54:04 2020 +0200

Move gfortran.dg/dec_math_5.f90 to ./ieee/

PR fortran/93871
* gfortran.dg/dec_math_5.f90: Move to ...
* gfortran.dg/ieee/dec_math_1.f90: ... here; change
dg-options to dg-additional-options.
---
 gcc/testsuite/ChangeLog   | 7 +++
 gcc/testsuite/gfortran.dg/{dec_math_5.f90 => ieee/dec_math_1.f90} | 5 -
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 557c81544e4..347181619a5 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,10 @@
+2020-04-08  Tobias Burnus  
+
+	PR fortran/93871
+	* gfortran.dg/dec_math_5.f90: Move to ...
+	* gfortran.dg/ieee/dec_math_1.f90: ... here; change
+	dg-options to dg-additional-options.
+
 2020-04-08  Alexandre Oliva 
 
 	* gcc.dg/tls/pr78796.c: Require tls_runtime.
diff --git a/gcc/testsuite/gfortran.dg/dec_math_5.f90 b/gcc/testsuite/gfortran.dg/ieee/dec_math_1.f90
similarity index 97%
rename from gcc/testsuite/gfortran.dg/dec_math_5.f90
rename to gcc/testsuite/gfortran.dg/ieee/dec_math_1.f90
index d761e039cc8..8587fd66eb1 100644
--- a/gcc/testsuite/gfortran.dg/dec_math_5.f90
+++ b/gcc/testsuite/gfortran.dg/ieee/dec_math_1.f90
@@ -1,8 +1,11 @@
-! { dg-options "-cpp -std=gnu" }
 ! { dg-do run }
+! { dg-additional-options "-cpp -std=gnu" }
 !
 ! Test values for degree-valued trigonometric intrinsics.
 !
+! Run under ieee/ as
+!   use ieee_arithmetic
+! (used for result checking) is not available on all platforms)
 
 module dec_math_5
 

Re: [PATCH][PPC64] [PR88877]

[Jeff Law via Gcc-patches]

On Mon, 2020-04-06 at 14:58 +0530, kamlesh kumar via Gcc-patches wrote:
> Hi Richard,
> Here is a discussion we did some time ago
> https://gcc.gnu.org/pipermail/gcc/2019-January/227834.html
> please see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88877 for more
> info regarding the bug.
> 
> We incorporated below Jakub's suggestion in this patch.
> 
> Jakub wrote:
> ""
> Yeah, all the callers of emit_library_call* would need to be changed to pass
> triplets rtx, machine_mode, int/bool /*unsignedp*/, instead of just
> rtx_mode_t pair.
> Jakub
> ""
I think you're generally on the right track here, but I'm deferring this to 
gcc11
(other maintainers are, of course, welcome to push it for gcc10 as it's a code
correctness issue).

Jeff
> 

[committed] libstdc++: Add comparison operators to types from Numerics clause

[Jonathan Wakely via Gcc-patches]

Some more C++20 changes from P1614R2, "The Mothership has Landed".

* include/bits/slice_array.h (operator==(const slice&, const slice&)):

Define for C++20.
* include/std/complex (operator==(const T&, const complex&))
(operator!=(const complex&, const complex&))
(operator!=(const complex&, const T&))
(operator!=(const T&, const complex&)): Do not declare for C++20.
* testsuite/26_numerics/slice/compare.cc: New test.

Tested powerpc64le-linux, committed to master.


commit ef389dadd4f082e13b076f14a123bf506e158da4
Author: Jonathan Wakely 
Date:   Wed Apr 8 16:51:59 2020 +0100

libstdc++: Add comparison operators to types from Numerics clause

Some more C++20 changes from P1614R2, "The Mothership has Landed".

* include/bits/slice_array.h (operator==(const slice&, const slice&)):
Define for C++20.
* include/std/complex (operator==(const T&, const complex&))
(operator!=(const complex&, const complex&))
(operator!=(const complex&, const T&))
(operator!=(const T&, const complex&)): Do not declare for C++20.
* testsuite/26_numerics/slice/compare.cc: New test.

diff --git a/libstdc++-v3/include/bits/slice_array.h b/libstdc++-v3/include/bits/slice_array.h
index 32ba802c007..de33342e252 100644
--- a/libstdc++-v3/include/bits/slice_array.h
+++ b/libstdc++-v3/include/bits/slice_array.h
@@ -78,6 +78,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 ///  Return array stride of slice.
 size_t stride() const;
 
+#if __cpp_impl_three_way_comparison >= 201907L
+/// Equality comparison
+friend bool operator==(const slice&, const slice&) = default;
+#endif
+
   private:
 size_t _M_off;  // offset
 size_t _M_sz;			// size
diff --git a/libstdc++-v3/include/std/complex b/libstdc++-v3/include/std/complex
index 4f170dc524a..f2917b8c368 100644
--- a/libstdc++-v3/include/std/complex
+++ b/libstdc++-v3/include/std/complex
@@ -468,6 +468,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 operator==(const complex<_Tp>& __x, const _Tp& __y)
 { return __x.real() == __y && __x.imag() == _Tp(); }
 
+#if !(__cpp_impl_three_way_comparison >= 201907L)
   template
 inline _GLIBCXX_CONSTEXPR bool
 operator==(const _Tp& __x, const complex<_Tp>& __y)
@@ -490,6 +491,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 inline _GLIBCXX_CONSTEXPR bool
 operator!=(const _Tp& __x, const complex<_Tp>& __y)
 { return __x != __y.real() || _Tp() != __y.imag(); }
+#endif
   //@}
 
   ///  Extraction operator for complex values.
diff --git a/libstdc++-v3/testsuite/26_numerics/slice/compare.cc b/libstdc++-v3/testsuite/26_numerics/slice/compare.cc
new file mode 100644
index 000..4459cf22eb6
--- /dev/null
+++ b/libstdc++-v3/testsuite/26_numerics/slice/compare.cc
@@ -0,0 +1,48 @@
+// Copyright (C) 2020 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+// { dg-options "-std=gnu++2a" }
+// { dg-do run { target c++2a } }
+
+#include 
+#include 
+
+void
+test01()
+{
+  std::slice s1(1, 2, 3);
+  VERIFY( s1 == s1 );
+  VERIFY( !(s1 != s1) );
+  std::slice s2(1, 2, 3);
+  VERIFY( s2 == s1 );
+  VERIFY( !(s2 != s1) );
+  std::slice s3(3, 2, 3);
+  VERIFY( s3 != s1 );
+  VERIFY( !(s3 == s1) );
+  std::slice s4(1, 3, 3);
+  VERIFY( s4 != s1 );
+  VERIFY( !(s4 == s1) );
+  std::slice s5(1, 2, 4);
+  VERIFY( s5 != s1 );
+  VERIFY( !(s5 == s1) );
+}
+
+int
+main()
+{
+  test01();
+}

Re: [PATCH] Allow new/delete operator deletion only for replaceable.

[Jan Hubicka]

> From 2f8ba3418f10b41bb839aadb292447bd757238d0 Mon Sep 17 00:00:00 2001
> From: Martin Liska 
> Date: Tue, 7 Apr 2020 16:23:27 +0200
> Subject: [PATCH] Allow new/delete operator deletion only for replaceable.
> 
> gcc/ChangeLog:
> 
> 2020-04-07  Martin Liska  
> 
>   PR c++/94314
>   * gimple.c (gimple_call_operator_delete_p): Rename to...
>   (gimple_call_replaceable_operator_delete_p): ... this.
>   Use DECL_IS_REPLACEABLE_OPERATOR_DELETE_P.
>   * gimple.h (gimple_call_operator_delete_p): Rename to ...
>   (gimple_call_replaceable_operator_delete_p): ... this.
>   * tree-core.h (tree_function_decl): Add replaceable_operator
>   flag.
>   * tree-ssa-dce.c (mark_all_reaching_defs_necessary_1):
>   Use DECL_IS_REPLACEABLE_OPERATOR_DELETE_P.
>   (propagate_necessity): Use gimple_call_replaceable_operator_delete_p.
>   (eliminate_unnecessary_stmts): Likewise.
>   * tree-streamer-in.c (unpack_ts_function_decl_value_fields):
>   Pack DECL_IS_REPLACEABLE_OPERATOR.
>   * tree-streamer-out.c (pack_ts_function_decl_value_fields):
>   Unpack the field here.
>   * tree.h (DECL_IS_REPLACEABLE_OPERATOR): New.
>   (DECL_IS_REPLACEABLE_OPERATOR_NEW_P): New.
>   (DECL_IS_REPLACEABLE_OPERATOR_DELETE_P): New.
>   * cgraph.c (cgraph_node::dump): Dump if an operator is replaceable.
>   * ipa-icf.c (sem_item::compare_referenced_symbol_properties): Compare
>   replaceable operator flags.
> 
> gcc/cp/ChangeLog:
> 
> 2020-04-07  Martin Liska  
> 
>   PR c++/94314
>   * decl.c (duplicate_decls): Duplicate also DECL_IS_REPLACEABLE_OPERATOR.
>   (cxx_init_decl_processing): Mark replaceable all implicitly defined
>   operators.
> 
> gcc/lto/ChangeLog:
> 
> 2020-04-07  Martin Liska  
> 
>   PR c++/94314
>   * lto-common.c (compare_tree_sccs_1): Compare also
>   DECL_IS_REPLACEABLE_OPERATOR.
> 
> gcc/testsuite/ChangeLog:
> 
> 2020-04-07  Martin Liska  
> 
>   PR c++/94314
>   * g++.dg/pr94314-2.C: New test.
>   * g++.dg/pr94314-3.C: New test.
>   * g++.dg/pr94314.C: New test.
> @@ -2368,6 +2368,8 @@ duplicate_decls (tree newdecl, tree olddecl, bool 
> newdecl_is_friend)
>   DECL_SET_IS_OPERATOR_NEW (newdecl, true);
> DECL_LOOPING_CONST_OR_PURE_P (newdecl)
>   |= DECL_LOOPING_CONST_OR_PURE_P (olddecl);
> +   DECL_IS_REPLACEABLE_OPERATOR (newdecl)
> + |= DECL_IS_REPLACEABLE_OPERATOR (olddecl);
>  
> if (merge_attr)
>   merge_attribute_bits (newdecl, olddecl);

I think you will also need to take care of decl copying tht happens in
the midle-end.  If we do ipa-cp clone of the replaceable operator I
guess we want to copy the flag since it is still new/delete
(removeing it in dce has still the same semantics)

However if we split the function, I think we want to remove the flag
from foo.part clone, or one would be able to again produce the examples
with broken reference counting by making ipa-split to separate the
refernece count and tail of the function.

I am not quite sure about the offloading done by openMP - I think that
one produces new decls.

Honza

Re: unreliable/confusing dg-add-options arm_fp16_alternatives

[Alexandre Oliva]

On Mar 27, 2020, Alexandre Oliva  wrote:

> So, here are some potential fixes:

> - install the patchlet for fp16-aapcs-3.c above, and be done with it

> - add an arm_fp16_hw requirement to this test

> - add to check_effective_target_arm_fp16_alternative_ok_nocache above a
>   check for arm_fp16, besides arm32.

> Unrelated potential fix, assuming it's a cut rather than intended:

> - drop the et_arm_neon_fp16_flags settings from the unrelated (?)
>   check_effective_target_arm_fp16_alternative_ok_nocache


Here's the patchlet turned into a patch submission:


add missing fp16 options

dg-require-effective-target arm_fp16_alternative_ok may pass even when
arm_fp16_ok doesn't, and the latter's failure inhibits dg-add-options
arm_fp16_alternative.  Requiring arm_fp16_ok would disable the test,
but if we just pass it the -mfp16-format=alternative option, it passes
even without arm_fp16_ok.  Sibling test fp16-aapcs-4.c underwent a
similar change, so I'm proposing the explicit option to fp16-aapcs-3.c
as well.

Tested with an arm-eabi cross compiler configured for a machine with
-mfloat-abi=hard -mfpu=vfpv3-d16.  Ok to install?


for  gcc/testsuite/ChangeLog

* gcc.target/arm/fp16-aapcs-3.c: Explicitly use the
-mfp16-format=alternative option.
---
 gcc/testsuite/gcc.target/arm/fp16-aapcs-3.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/gcc/testsuite/gcc.target/arm/fp16-aapcs-3.c 
b/gcc/testsuite/gcc.target/arm/fp16-aapcs-3.c
index 56a3ae2..858181c 100644
--- a/gcc/testsuite/gcc.target/arm/fp16-aapcs-3.c
+++ b/gcc/testsuite/gcc.target/arm/fp16-aapcs-3.c
@@ -1,8 +1,7 @@
 /* { dg-do compile }  */
 /* { dg-require-effective-target arm_hard_vfp_ok }  */
 /* { dg-require-effective-target arm_fp16_alternative_ok } */
-/* { dg-options "-O2" }  */
-/* { dg-add-options arm_fp16_alternative } */
+/* { dg-options "-O2 -mfp16-format=alternative" }  */
 
 /* Test __fp16 arguments and return value in registers (hard-float).  */
 


-- 
Alexandre Oliva, freedom fighterhe/himhttps://FSFLA.org/blogs/lxo/
Free Software Evangelist  Stallman was right, but he's left :(
GNU Toolchain Engineer   Live long and free, and prosper ethically

Re: [PATCH][Arm][2/4] Custom Datapath Extension intrinsics: instructions using FPU/MVE S/D registers

[Dennis Zhang]

Hi kyrylo,

> 
> From: Kyrylo Tkachov 
> Sent: Tuesday, April 7, 2020 3:07 PM
> To: Dennis Zhang; gcc-patches@gcc.gnu.org
> Cc: nd; Richard Earnshaw; Ramana Radhakrishnan
> Subject: RE: [PATCH][Arm][2/4]  Custom Datapath Extension intrinsics: 
> instructions using FPU/MVE S/D registers
>
> Hi Dennis,
>
> > -Original Message-
> > From: Dennis Zhang 
> > Sent: 07 April 2020 13:31
> > To: gcc-patches@gcc.gnu.org
> > Cc: nd ; Richard Earnshaw ;
> > Ramana Radhakrishnan ; Kyrylo
> > Tkachov 
> > Subject: Re: [PATCH][Arm][2/4] Custom Datapath Extension intrinsics:
> > instructions using FPU/MVE S/D registers
> >
> > Hi all,
> >
> > This patch is updated to support DImode for vfp target as required by CDE.
> > Changelog is updated as following.
> >
> > Is this ready for commit please?
>
> This is ok.
> Has the first patch been updated and committed yet?
> Thanks,
> Kyrill
>

This patch has been committed as 07b9bfd02b88cad2f6b3f50ad610dd75cb989ed3.

Many thanks
Dennis

> >
> > Cheers
> > Dennis
> >
> > gcc/ChangeLog:
> >
> > 2020-04-07  Dennis Zhang  
> > Matthew Malcomson 
> >
> > * config/arm/arm-builtins.c (CX_IMM_QUALIFIERS): New macro.
> > (CX_UNARY_QUALIFIERS, CX_BINARY_QUALIFIERS): Likewise.
> > (CX_TERNARY_QUALIFIERS): Likewise.
> > (ARM_BUILTIN_CDE_PATTERN_START): Likewise.
> > (ARM_BUILTIN_CDE_PATTERN_END): Likewise.
> > (arm_init_acle_builtins): Initialize CDE builtins.
> > (arm_expand_acle_builtin): Check CDE constant operands.
> > * config/arm/arm.h (ARM_CDE_CONST_COPROC): New macro to set the
> > range
> > of CDE constant operand.
> > * config/arm/arm.c (arm_hard_regno_mode_ok): Support DImode for
> > TARGET_VFP_BASE.
> > (ARM_VCDE_CONST_1, ARM_VCDE_CONST_2, ARM_VCDE_CONST_3):
> > Likewise.
> > * config/arm/arm_cde.h (__arm_vcx1_u32): New macro of ACLE interface.
> > (__arm_vcx1a_u32, __arm_vcx2_u32, __arm_vcx2a_u32): Likewise.
> > (__arm_vcx3_u32, __arm_vcx3a_u32, __arm_vcx1d_u64): Likewise.
> > (__arm_vcx1da_u64, __arm_vcx2d_u64, __arm_vcx2da_u64): Likewise.
> > (__arm_vcx3d_u64, __arm_vcx3da_u64): Likewise.
> > * config/arm/arm_cde_builtins.def: New file.
> > * config/arm/iterators.md (V_reg): New attribute of SI.
> > * config/arm/predicates.md (const_int_coproc_operand): New.
> > (const_int_vcde1_operand, const_int_vcde2_operand): New.
> > (const_int_vcde3_operand): New.
> > * config/arm/unspecs.md (UNSPEC_VCDE, UNSPEC_VCDEA): New.
> > * config/arm/vfp.md (arm_vcx1): New entry.
> > (arm_vcx1a, arm_vcx2, arm_vcx2a): Likewise.
> > (arm_vcx3, arm_vcx3a): Likewise.
> >
> > gcc/testsuite/ChangeLog:
> >
> > 2020-04-07  Dennis Zhang  
> >
> > * gcc.target/arm/acle/cde_v_1.c: New test.
> > * gcc.target/arm/acle/cde_v_1_err.c: New test.
> > * gcc.target/arm/acle/cde_v_1_mve.c: New test.
> >
> > > Hi all,
> > >
> > > This patch is updated as attached.
> > > It's rebased to the top. Is it ready for commit please?
> > >
> > > Cheers
> > > Dennis
> > >
> > > > Hi all,
> > > >
> > > > This patch is part of a series that adds support for the ARMv8.m Custom
> > Datapath Extension (CDE).
> > > > It enables the ACLE intrinsics calling VCX1, VCX2, and VCX3
> > instructions who work with FPU/MVE 32-bit/64-bit registers.
> > > >
> > > > This patch depends on the CDE feature patch:
> > https://gcc.gnu.org/pipermail/gcc-patches/2020-March/541921.html
> > > > It also depends on the MVE framework patch:
> > https://gcc.gnu.org/pipermail/gcc-patches/2020-February/540415.html
> > > > ISA has been announced at
> > https://developer.arm.com/architectures/instruction-sets/custom-
> > instructions
> > > >
> > > > Regtested and bootstrapped for arm-none-linux-gnueabi-armv8-m.main.
> > > >
> > > > Is it OK for commit please?
> > > >
> > > > Cheers
> > > > Dennis

Re: [PATCH][Arm][1/3] Support for Arm Custom Datapath Extension (CDE): enable the feature

[Dennis Zhang]

Hi Kyrylo,

> 
> From: Kyrylo Tkachov 
> Sent: Wednesday, April 8, 2020 1:34 PM
> To: Dennis Zhang; gcc-patches@gcc.gnu.org
> Cc: nd; Richard Earnshaw; Ramana Radhakrishnan
> Subject: RE: [PATCH][Arm][1/3] Support for Arm Custom Datapath Extension 
> (CDE): enable the feature
>
> > -Original Message-
> > From: Dennis Zhang 
> > Sent: 08 April 2020 12:34
> > To: Kyrylo Tkachov ; gcc-patches@gcc.gnu.org
> > Cc: nd ; Richard Earnshaw ;
> > Ramana Radhakrishnan 
> > Subject: Re: [PATCH][Arm][1/3] Support for Arm Custom Datapath Extension
> > (CDE): enable the feature
> >
> > Hi Kyrylo
> >
> > > Hi Dennis,
> > >
> > > > -Original Message-
> > > > From: Dennis Zhang 
> > > > Sent: 19 March 2020 14:03
> > > > To: Kyrylo Tkachov ; gcc-
> > patc...@gcc.gnu.org
> > > > Cc: nd ; Richard Earnshaw
> > ;
> > > > Ramana Radhakrishnan 
> > > > Subject: Re: [PATCH][Arm][1/3] Support for Arm Custom Datapath
> > Extension
> > > > (CDE): enable the feature
> > > >
> > > > Hi Kyrylo,
> > > >
> > > > >
> > > > >From: Kyrylo Tkachov 
> > > > >Sent: Wednesday, March 18, 2020 9:04 AM
> > > > >To: Dennis Zhang; gcc-patches@gcc.gnu.org
> > > > >Cc: nd; Richard Earnshaw; Ramana Radhakrishnan
> > > > >Subject: RE: [PATCH][Arm][1/3] Support for Arm Custom Datapath
> > > > >Extension (CDE): enable the feature
> > > > >
> > > > >Hi Dennis,
> > > > >
> > > > >> -Original Message-
> > > > >> From: Dennis Zhang 
> > > > >> Sent: 12 March 2020 12:06
> > > > >> To: gcc-patches@gcc.gnu.org
> > > > >> Cc: nd ; Richard Earnshaw
> > ;
> > > > >> Ramana Radhakrishnan ; Kyrylo
> > > > Tkachov
> > > > >> 
> > > > >> Subject: [PATCH][Arm][1/3] Support for Arm Custom Datapath
> > Extension
> > > > >> (CDE): enable the feature
> > > > >>
> > > > >> Hi all,
> > > > >>
> > > > >> This patch is part of a series that adds support for the ARMv8.m
> > > > >> Custom Datapath Extension.
> > > > >> This patch defines the options cdecp0-cdecp7 for CLI to enable the
> > > > >> CDE on corresponding coprocessor 0-7.
> > > > >> It also adds new check-effective for CDE feature.
> > > > >>
> > > > >> ISA has been announced at
> > > > >> https://developer.arm.com/architectures/instruction-sets/custom-
> > > > >> instructions
> > > > >>
> > > > >> Regtested and bootstrapped.
> > > > >>
> > > > >> Is it OK to commit please?
> > > > >
> > > > >Can you please rebase this patch on top of the recent MVE commits?
> > > > >It currently doesn't apply cleanly to trunk.
> > > > >Thanks,
> > > > >Kyrill
> > > >
> > > > The rebase patches is as attached.
> > > > Is it OK to commit?
> > >
> > > Ok, with a few fixes...
> > >
> > > diff --git a/gcc/testsuite/gcc.target/arm/pragma_cde.c
> > b/gcc/testsuite/gcc.target/arm/pragma_cde.c
> > > new file mode 100644
> > > index 000..97643a08405
> > > --- /dev/null
> > > +++ b/gcc/testsuite/gcc.target/arm/pragma_cde.c
> > > @@ -0,0 +1,98 @@
> > > +/* Test for CDE #prama target macros.  */
> > > +/* { dg-do compile } */
> > >
> > > Typo in "pragma" in the comment.
> > >
> > >
> > > +# A series of routines are created to 1) check if a given architecture is
> > > +# effective (check_effective_target_*_ok) and then 2) give the
> > corresponding
> > > +# flags that enable the architecture (add_options_for_*).
> > > +# The series includes:
> > > +#   arm_v8m_main_cde: Armv8-m CDE (Custom Datapath Extension).
> > > +#   arm_v8m_main_cde_fp: Armv8-m CDE with FP registers.
> > > +#   arm_v8_1m_main_cde_mve: Armv8.1-m CDE with MVE.
> > > +# Usage:
> > > +#   /* { dg-require-effective-target arm_v8m_main_cde_ok } */
> > > +#   /* { dg-add-options arm_v8m_main_cde } */
> > > +# The tests are valid for Arm.
> > > +
> > > +foreach { armfunc armflag armdef } {
> > >
> > >   New effective target checks need to be documented in doc/invoke.texi
> > >
> >
> > Thanks a lot for the review.
> > The document has been updated and the changelog, too.
> > Is it ready to commit please?
>
> Ok.
> Thanks,
> Kyrill

This patch has been committed as 975e6670c428b032aa6ec600f57082d3cfb57393.

Many thanks!
Dennis

>
> >
> > Cheers
> > Dennis
> >
> > gcc/ChangeLog:
> >
> > 2020-04-08  Dennis Zhang  
> >
> > * config.gcc: Add arm_cde.h.
> > * config/arm/arm-c.c (arm_cpu_builtins): Define or undefine
> > __ARM_FEATURE_CDE and __ARM_FEATURE_CDE_COPROC.
> > * config/arm/arm-cpus.in (cdecp0, cdecp1, ..., cdecp7): New options.
> > * config/arm/arm.c (arm_option_reconfigure_globals): Configure
> > arm_arch_cde and arm_arch_cde_coproc to store the feature bits.
> > * config/arm/arm.h (TARGET_CDE): New macro.
> > * config/arm/arm_cde.h: New file.
> > * doc/invoke.texi: Document CDE options +cdecp[0-7].
> > * doc/sourcebuild.texi (arm_v8m_main_cde_ok): Document new target
> > supports option.
> > (arm_v8m_main_cde_fp, arm_v8_1m_main_cde_mve): Likewise.
> >
> > gcc/testsuite/ChangeLog:
> >
> > 2020-04-08  Dennis Zhang  
> >
> > * gcc.target/arm/pragma_cde.c: New test.
> > * 

[committed] libstdc++: Add comparison operators to result types

[Jonathan Wakely via Gcc-patches]

Some more C++20 changes from P1614R2, "The Mothership has Landed".

* include/std/charconv (to_chars_result, from_chars_result): Add
defaulted equality comparisons for C++20.
* testsuite/20_util/from_chars/compare.cc: New test.
* testsuite/20_util/to_chars/compare.cc: New test.

Tested powerpc64le-linux, committed to master.

commit e18cd376e0d5ffc2a2b21eba0c396a771c30e1d4
Author: Jonathan Wakely 
Date:   Wed Apr 8 16:16:10 2020 +0100

libstdc++: Add comparison operators to  result types

Some more C++20 changes from P1614R2, "The Mothership has Landed".

* include/std/charconv (to_chars_result, from_chars_result): Add
defaulted equality comparisons for C++20.
* testsuite/20_util/from_chars/compare.cc: New test.
* testsuite/20_util/to_chars/compare.cc: New test.

diff --git a/libstdc++-v3/include/std/charconv 
b/libstdc++-v3/include/std/charconv
index 8c9ce9d280e..3caa0f8ac10 100644
--- a/libstdc++-v3/include/std/charconv
+++ b/libstdc++-v3/include/std/charconv
@@ -44,7 +44,8 @@
 #include  // for std::errc
 #include 
 
-// Define when floating point is supported: #define __cpp_lib_to_chars 201611L
+// FIXME: Define when floating point is supported:
+// #define __cpp_lib_to_chars 201611L
 
 namespace std _GLIBCXX_VISIBILITY(default)
 {
@@ -55,6 +56,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   {
 char* ptr;
 errc ec;
+
+#if __cplusplus > 201703L && __cpp_impl_three_way_comparison >= 201907L
+friend bool
+operator==(const to_chars_result&, const to_chars_result&) = default;
+#endif
   };
 
   /// Result type of std::from_chars
@@ -62,6 +68,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   {
 const char* ptr;
 errc ec;
+
+#if __cplusplus > 201703L && __cpp_impl_three_way_comparison >= 201907L
+friend bool
+operator==(const from_chars_result&, const from_chars_result&) = default;
+#endif
   };
 
 namespace __detail
diff --git a/libstdc++-v3/testsuite/20_util/from_chars/compare.cc 
b/libstdc++-v3/testsuite/20_util/from_chars/compare.cc
new file mode 100644
index 000..04d51afa4e3
--- /dev/null
+++ b/libstdc++-v3/testsuite/20_util/from_chars/compare.cc
@@ -0,0 +1,50 @@
+// Copyright (C) 2020 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+// { dg-options "-std=gnu++2a" }
+// { dg-do run { target c++2a } }
+
+#include 
+#include 
+
+void
+test01()
+{
+  std::from_chars_result r1{}, r2{};
+  VERIFY( r1 == r1 );
+  VERIFY( !(r1 != r1) );
+  VERIFY( r2 == r1 );
+  VERIFY( !(r2 != r1) );
+  r1.ptr = "";
+  VERIFY( r1 == r1 );
+  VERIFY( r1 != r2 );
+  r2.ptr = "a" + 1;
+  VERIFY( r1 != r2 );
+  r2.ptr = r1.ptr;
+  r2.ec = std::errc::invalid_argument;
+  VERIFY( r1 != r2 );
+  r1.ec = std::errc::no_such_file_or_directory;
+  VERIFY( r1 != r2 );
+  r1.ec = std::errc::invalid_argument;
+  VERIFY( r2 == r1 );
+}
+
+int
+main()
+{
+  test01();
+}
diff --git a/libstdc++-v3/testsuite/20_util/to_chars/compare.cc 
b/libstdc++-v3/testsuite/20_util/to_chars/compare.cc
new file mode 100644
index 000..64232955956
--- /dev/null
+++ b/libstdc++-v3/testsuite/20_util/to_chars/compare.cc
@@ -0,0 +1,51 @@
+// Copyright (C) 2020 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+// { dg-options "-std=gnu++2a" }
+// { dg-do run { target c++2a } }
+
+#include 
+#include 
+
+void
+test01()
+{
+  char str[2]{};
+  std::to_chars_result r1{}, r2{};
+  VERIFY( r1 == r1 );
+  VERIFY( !(r1 != r1) );
+  VERIFY( r2 == r1 );
+  VERIFY( !(r2 != r1) );
+  r1.ptr = str;
+  VERIFY( r1 == r1 );
+  VERIFY( r1 != r2 );
+  r2.ptr = str + 1;
+  

Re: [PATCH] Allow new/delete operator deletion only for replaceable.

[Martin Liška]

On 4/8/20 3:34 PM, Jason Merrill wrote:

On 4/8/20 9:32 AM, Jakub Jelinek wrote:

On Wed, Apr 08, 2020 at 09:20:07AM -0400, Jason Merrill via Gcc-patches wrote:

On 4/8/20 4:47 AM, Richard Biener wrote:

On Tue, Apr 7, 2020 at 5:01 PM Martin Liška  wrote:


Hi.

The patch allows DCE to remove only replaceable operators new and delete.
That's achieved by proper mark up of all these operators in C++ FE.
The patch also brings all tests we've collected so far for the PR.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?


Grepping for uses of DECL_IS_OPERATOR_* reveals you miss comparing
the new flag in ipa-icf.c and cgraph node dumping in cgraph.c might want
to dump it as well.

Otherwise it looks reasonable.

So the mid-end parts are OK in case FE people are happy with this solution
for GCC 10.


This seems fine for GCC 10, though I wonder about using an attribute for
DECL_REPLACEABLE_OPERATOR rather than taking a bit in all FUNCTION_DECLs
that will only ever be set on a small handful.


If it is just for GCC 10 and we'll return the bit back to unused in GCC 11,
I'd think it is acceptable.


Agreed.

Jason



All right, thanks for review. There's updated version of the patch that fullfils
Richi's comments.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
I'm going to install the patch.

Thanks,
Martin
>From 2f8ba3418f10b41bb839aadb292447bd757238d0 Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Tue, 7 Apr 2020 16:23:27 +0200
Subject: [PATCH] Allow new/delete operator deletion only for replaceable.

gcc/ChangeLog:

2020-04-07  Martin Liska  

	PR c++/94314
	* gimple.c (gimple_call_operator_delete_p): Rename to...
	(gimple_call_replaceable_operator_delete_p): ... this.
	Use DECL_IS_REPLACEABLE_OPERATOR_DELETE_P.
	* gimple.h (gimple_call_operator_delete_p): Rename to ...
	(gimple_call_replaceable_operator_delete_p): ... this.
	* tree-core.h (tree_function_decl): Add replaceable_operator
	flag.
	* tree-ssa-dce.c (mark_all_reaching_defs_necessary_1):
	Use DECL_IS_REPLACEABLE_OPERATOR_DELETE_P.
	(propagate_necessity): Use gimple_call_replaceable_operator_delete_p.
	(eliminate_unnecessary_stmts): Likewise.
	* tree-streamer-in.c (unpack_ts_function_decl_value_fields):
	Pack DECL_IS_REPLACEABLE_OPERATOR.
	* tree-streamer-out.c (pack_ts_function_decl_value_fields):
	Unpack the field here.
	* tree.h (DECL_IS_REPLACEABLE_OPERATOR): New.
	(DECL_IS_REPLACEABLE_OPERATOR_NEW_P): New.
	(DECL_IS_REPLACEABLE_OPERATOR_DELETE_P): New.
	* cgraph.c (cgraph_node::dump): Dump if an operator is replaceable.
	* ipa-icf.c (sem_item::compare_referenced_symbol_properties): Compare
	replaceable operator flags.

gcc/cp/ChangeLog:

2020-04-07  Martin Liska  

	PR c++/94314
	* decl.c (duplicate_decls): Duplicate also DECL_IS_REPLACEABLE_OPERATOR.
	(cxx_init_decl_processing): Mark replaceable all implicitly defined
	operators.

gcc/lto/ChangeLog:

2020-04-07  Martin Liska  

	PR c++/94314
	* lto-common.c (compare_tree_sccs_1): Compare also
	DECL_IS_REPLACEABLE_OPERATOR.

gcc/testsuite/ChangeLog:

2020-04-07  Martin Liska  

	PR c++/94314
	* g++.dg/pr94314-2.C: New test.
	* g++.dg/pr94314-3.C: New test.
	* g++.dg/pr94314.C: New test.
---
 gcc/cgraph.c |  7 +--
 gcc/cp/decl.c| 14 ++
 gcc/gimple.c |  6 +--
 gcc/gimple.h |  2 +-
 gcc/ipa-icf.c|  4 ++
 gcc/lto/lto-common.c |  1 +
 gcc/testsuite/g++.dg/pr94314-2.C | 26 ++
 gcc/testsuite/g++.dg/pr94314-3.C | 55 +
 gcc/testsuite/g++.dg/pr94314.C   | 85 
 gcc/tree-core.h  |  3 +-
 gcc/tree-ssa-dce.c   |  8 +--
 gcc/tree-streamer-in.c   |  1 +
 gcc/tree-streamer-out.c  |  1 +
 gcc/tree.h   | 10 +++-
 14 files changed, 210 insertions(+), 13 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/pr94314-2.C
 create mode 100644 gcc/testsuite/g++.dg/pr94314-3.C
 create mode 100644 gcc/testsuite/g++.dg/pr94314.C

diff --git a/gcc/cgraph.c b/gcc/cgraph.c
index 6b780f80eb3..ecb234d032f 100644
--- a/gcc/cgraph.c
+++ b/gcc/cgraph.c
@@ -2157,10 +2157,11 @@ cgraph_node::dump (FILE *f)
   if (parallelized_function)
 fprintf (f, " parallelized_function");
   if (DECL_IS_OPERATOR_NEW_P (decl))
-fprintf (f, " operator_new");
+fprintf (f, " %soperator_new",
+	 DECL_IS_REPLACEABLE_OPERATOR (decl) ? "replaceable_" : "");
   if (DECL_IS_OPERATOR_DELETE_P (decl))
-fprintf (f, " operator_delete");
-
+fprintf (f, " %soperator_delete",
+	 DECL_IS_REPLACEABLE_OPERATOR (decl) ? "replaceable_" : "");
 
   fprintf (f, "\n");
 
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index a127734af69..a731702bdd2 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -2368,6 +2368,8 @@ duplicate_decls (tree newdecl, tree olddecl, bool newdecl_is_friend)
 	DECL_SET_IS_OPERATOR_NEW (newdecl, true);
 	  

RE: [wwwdocs] [arm] Document CDE intrinsics from ACLE

[Kyrylo Tkachov]

> -Original Message-
> From: Matthew Malcomson 
> Sent: 08 April 2020 16:09
> To: gcc-patches@gcc.gnu.org
> Cc: ger...@pfeifer.com; Richard Earnshaw ;
> ni...@redhat.com; Kyrylo Tkachov ; nd
> ; Ramana Radhakrishnan
> 
> Subject: [wwwdocs] [arm] Document CDE intrinsics from ACLE
> 
> New in GCC 10.

Ok. Just pushing it to master in wwwdocs should work.
Thanks,
Kyrill

> 
> 
> ### Attachment also inlined for ease of reply
> ###
> 
> 
> diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
> index
> 3d8e0ba989e860d307310378a2be99b32a27261f..389561d13c69b650528e8e
> d8859ebbb5760438c6 100644
> --- a/htdocs/gcc-10/changes.html
> +++ b/htdocs/gcc-10/changes.html
> @@ -624,6 +624,9 @@ a work-in-progress.
>added: this M-profile feature is no longer restricted to targets
>with MOVT. For example, -mcpu=cortex-m0
>now supports this option.
> +  Support for the Custom Datapath Extension ACLE
> +  https://developer.arm.com/docs/101028/0010/custom-
> datapath-extension">
> +  intrinsics has been added.
>  
> 
>  AVR

Re: [PATCH] c++: Fix usage of CONSTRUCTOR_PLACEHOLDER_BOUNDARY inside array initializers [90996]

[Patrick Palka via Gcc-patches]

On Wed, 8 Apr 2020, Jason Merrill wrote:
> On 4/6/20 6:22 PM, Patrick Palka wrote:
> > On Mon, 6 Apr 2020, Jason Merrill wrote:
> > 
> > > On 4/6/20 3:07 PM, Patrick Palka wrote:
> > > > This PR reports that since the introduction of the
> > > > CONSTRUCTOR_PLACEHOLDER_BOUNDARY flag, we are sometimes failing to
> > > > resolve
> > > > PLACEHOLDER_EXPRs inside array initializers that refer to some inner
> > > > constructor.  In the testcase in the PR, we have as the initializer for
> > > > "S
> > > > c[];"
> > > > the following
> > > > 
> > > > {{.a=(int &) &_ZGR1c_, .b={*(&)->a}}}
> > > > 
> > > > where CONSTRUCTOR_PLACEHOLDER_BOUNDARY is set on the second outermost
> > > > constructor.  However, we pass the whole initializer to
> > > > replace_placeholders
> > > > in
> > > > store_init_value, and so due to the flag being set on the second
> > > > outermost
> > > > ctor
> > > > it avoids recursing into the innermost constructor and we fail to
> > > > resolve
> > > > the
> > > > PLACEHOLDER_EXPR within.
> > > > 
> > > > To fix this, we could perhaps either call replace_placeholders in more
> > > > places,
> > > > or we could change where we set CONSTRUCTOR_PLACEHOLDER_BOUNDARY.  This
> > > > patch
> > > > takes the latter approach -- when building up an array initializer, it
> > > > bubbles
> > > > any CONSTRUCTOR_PLACEHOLDER_BOUNDARY flag set on the element
> > > > initializers up
> > > > to
> > > > the array initializer.  Doing so shouldn't create any new
> > > > PLACEHOLDER_EXPR
> > > > resolution ambiguities because we don't deal with PLACEHOLDER_EXPRs of
> > > > array
> > > > type in the frontend, as far as I can tell.
> > > 
> > > Interesting.  Yes, that sounds like it should work.
> > > 
> > > > Does this look OK to comit after testing?
> > > 
> > > Yes.
> > > 
> > > Though I'm seeing "after testing" a lot; what testing are you doing before
> > > sending patches?
> > 
> > Sorry for the sloppiness -- I should be writing "after a full
> > bootstrap/regtest" instead of "after testing" because I do indeed do
> > some testing before sending a patch.  In particular, I usually run and
> > inspect the outputs of
> > 
> >  make check RUNTESTFLAGS="dg.exp=*.C"
> >  make check RUNTESTFLAGS="old-deja.exp=*.C"
> >  make check RUNTESTFLAGS="conformance.exp=*ranges*"
> > 
> > in a build tree that is configured with --disable-bootstrap, as a quick
> > smoke test for the patch.  Is this a sufficient amount of testing before
> > sending a patch for review, or would you prefer that I do a full
> > bootstrap/regtest beforehand?
> 
> You don't need to do a full bootstrap and run non-C++ testsuites, but please
> run the full libstdc++ testsuite.
> 
> Is there a reason you aren't using 'make check-c++'?

No good reason, I didn't know about "make check-c++" :) Good to know,
thanks!

> 
> > In any case, I'll make sure to clearly convey the amount of testing that
> > was done and is remaining in future patch submissions.
> 
> Thanks.
> 
> Jason
> 
> 

Re: Disable aggregate walking in ipa code for optimize_debug

[Martin Jambor]

Hi,

On Sat, Apr 04 2020, Jan Hubicka wrote:
> Martin,
> with optimize_debug or when FRE is disabled propagating aggregates is
> useless since we are not going to use them.  I think we should also
> avoid working hard on the jump functions.
> This patch disables it in ipa_load_from_param_agg, but I am not sure if
> there are other ways ipa-prop can do the memory walk?

if you want to bail out before mem-SSA is walked in order to construct
aggregate jump function, I'd do it in determine_known_aggregate_parts.
Doing it in ipa_load_from_parm_agg means that the code will still look
for stores of constants into aggregates and since this fall, we do not
just do it in the BB with the call.  Bailing out later in
ipa_load_from_parm_agg will however prevent inlining from ever
evaluating the predicate.

Which brings me to another thing.  Note that feeding the results into
FRE is not the only use of aggregate jump functions.  They can also be
used to evaluate inlining predicates and to make calls direct and
facilitate indirect inlining.  Perhaps we don't want to do neither of
those on aggregates at -Og but I do not see them as useless without FRE.

Martin

>
> Bootstrapped/regtested x86_64. Makes sense?
>
> Honza
>
>   * ipa-fnsummary.c (vrp_will_run_p): Export.
>   * ipa-fnsummary.h (vrp_will_run_p): Declare.
>   * ipa-prop.c (ipa_load_from_parm_agg): Use it.
> diff --git a/gcc/ipa-fnsummary.c b/gcc/ipa-fnsummary.c
> index d96c8e9b03c..e5f43078c27 100644
> --- a/gcc/ipa-fnsummary.c
> +++ b/gcc/ipa-fnsummary.c
> @@ -522,7 +522,7 @@ vrp_will_run_p (struct cgraph_node *node)
>  
>  /* Similarly about FRE.  */
>  
> -static bool
> +bool
>  fre_will_run_p (struct cgraph_node *node)
>  {
>return (opt_for_fn (node->decl, optimize)
> diff --git a/gcc/ipa-fnsummary.h b/gcc/ipa-fnsummary.h
> index c6ddc9f3199..f4e1fd0cc86 100644
> --- a/gcc/ipa-fnsummary.h
> +++ b/gcc/ipa-fnsummary.h
> @@ -371,6 +371,7 @@ void evaluate_properties_for_edge (struct cgraph_edge *e,
>  void ipa_fnsummary_c_finalize (void);
>  HOST_WIDE_INT ipa_get_stack_frame_offset (struct cgraph_node *node);
>  void ipa_remove_from_growth_caches (struct cgraph_edge *edge);
> +bool fre_will_run_p (struct cgraph_node *);
>  
>  /* Return true if EDGE is a cross module call.  */
>  
> diff --git a/gcc/ipa-prop.c b/gcc/ipa-prop.c
> index 71ac0e104d2..7f654f3aea3 100644
> --- a/gcc/ipa-prop.c
> +++ b/gcc/ipa-prop.c
> @@ -1091,6 +1091,12 @@ ipa_load_from_parm_agg (struct ipa_func_body_info *fbi,
>int index;
>HOST_WIDE_INT size;
>bool reverse;
> +
> +  /* Do not bother to do analysis when we are not doing propagation of
> + aggregates anyway.  */
> +  if (!fre_will_run_p (cgraph_node::get (current_function_decl)))
> +return false;
> +
>tree base = get_ref_base_and_extent_hwi (op, offset_p, , );
>  
>if (!base)

[wwwdocs] [arm] Document CDE intrinsics from ACLE

[Matthew Malcomson]

New in GCC 10.


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


diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
index 
3d8e0ba989e860d307310378a2be99b32a27261f..389561d13c69b650528e8ed8859ebbb5760438c6
 100644
--- a/htdocs/gcc-10/changes.html
+++ b/htdocs/gcc-10/changes.html
@@ -624,6 +624,9 @@ a work-in-progress.
   added: this M-profile feature is no longer restricted to targets
   with MOVT. For example, -mcpu=cortex-m0
   now supports this option.
+  Support for the Custom Datapath Extension ACLE
+  https://developer.arm.com/docs/101028/0010/custom-datapath-extension;>
+  intrinsics has been added.
 
 
 AVR

diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
index 
3d8e0ba989e860d307310378a2be99b32a27261f..389561d13c69b650528e8ed8859ebbb5760438c6
 100644
--- a/htdocs/gcc-10/changes.html
+++ b/htdocs/gcc-10/changes.html
@@ -624,6 +624,9 @@ a work-in-progress.
   added: this M-profile feature is no longer restricted to targets
   with MOVT. For example, -mcpu=cortex-m0
   now supports this option.
+  Support for the Custom Datapath Extension ACLE
+  https://developer.arm.com/docs/101028/0010/custom-datapath-extension;>
+  intrinsics has been added.
 
 
 AVR

Re: require tls_runtime for tls execution test

[Jakub Jelinek via Gcc-patches]

On Wed, Apr 08, 2020 at 12:04:16PM -0300, Alexandre Oliva wrote:
> 
> All TLS execution tests require tls_runtime, not just tls; pr78796.c
> is the only exception that is not otherwise limited to platforms known
> to support it.  I suppose that's an oversight.  On a platform whose
> linker is configured to disregard TLS relocations, this test compiles
> and assembles successfully, but execution fails.  The tls_runtime
> requirement target avoids the noise from the expected failure.
> 
> Tested on the affected platform, and on x86_64-linux-gnu.  Ok to install?
> 
> 
> for  gcc/testsuite/ChangeLog
> 
>   * gcc.dg/tls/pr78796.c: Require tls_runtime.

Ok.

> ---
>  gcc/testsuite/gcc.dg/tls/pr78796.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/gcc/testsuite/gcc.dg/tls/pr78796.c 
> b/gcc/testsuite/gcc.dg/tls/pr78796.c
> index a0b23d6..038e536 100644
> --- a/gcc/testsuite/gcc.dg/tls/pr78796.c
> +++ b/gcc/testsuite/gcc.dg/tls/pr78796.c
> @@ -2,7 +2,7 @@
>  /* { dg-do run } */
>  /* { dg-options "-O2" } */
>  /* { dg-additional-options "-mcmodel=large" { target aarch64-*-* } } */
> -/* { dg-require-effective-target tls } */
> +/* { dg-require-effective-target tls_runtime } */
>  /* { dg-add-options tls } */
>  
>  struct S { int a, b, c, d, e; };

Jakub

require tls_runtime for tls execution test

[Alexandre Oliva]

All TLS execution tests require tls_runtime, not just tls; pr78796.c
is the only exception that is not otherwise limited to platforms known
to support it.  I suppose that's an oversight.  On a platform whose
linker is configured to disregard TLS relocations, this test compiles
and assembles successfully, but execution fails.  The tls_runtime
requirement target avoids the noise from the expected failure.

Tested on the affected platform, and on x86_64-linux-gnu.  Ok to install?


for  gcc/testsuite/ChangeLog

* gcc.dg/tls/pr78796.c: Require tls_runtime.
---
 gcc/testsuite/gcc.dg/tls/pr78796.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.dg/tls/pr78796.c 
b/gcc/testsuite/gcc.dg/tls/pr78796.c
index a0b23d6..038e536 100644
--- a/gcc/testsuite/gcc.dg/tls/pr78796.c
+++ b/gcc/testsuite/gcc.dg/tls/pr78796.c
@@ -2,7 +2,7 @@
 /* { dg-do run } */
 /* { dg-options "-O2" } */
 /* { dg-additional-options "-mcmodel=large" { target aarch64-*-* } } */
-/* { dg-require-effective-target tls } */
+/* { dg-require-effective-target tls_runtime } */
 /* { dg-add-options tls } */
 
 struct S { int a, b, c, d, e; };

-- 
Alexandre Oliva, freedom fighterhe/himhttps://FSFLA.org/blogs/lxo/
Free Software Evangelist  Stallman was right, but he's left :(
GNU Toolchain Engineer   Live long and free, and prosper ethically

Re: PATCH -- Fix degree trignometric functions

[Andreas Schwab]

FAIL: gfortran.dg/dec_math_5.f90   -O0  (test for excess errors)
Excess errors:
/opt/gcc/gcc-20200408/gcc/testsuite/gfortran.dg/dec_math_5.f90:132:9: Fatal 
Error: Cannot open module file 'ieee_arithmetic.mod' for reading at (1): No 
such file or directory
compilation terminated.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

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

[Patrick Palka via Gcc-patches]

On Tue, 7 Apr 2020, Jason Merrill wrote:
> On 4/7/20 1:40 PM, Patrick Palka wrote:
> > On Mon, 6 Apr 2020, Jason Merrill wrote:
> > > On 4/6/20 11:45 AM, Patrick Palka wrote:
> > > > On Wed, 1 Apr 2020, Jason Merrill wrote:
> > > > 
> > > > > On 4/1/20 6:29 PM, Jason Merrill wrote:
> > > > > > On 3/31/20 3:50 PM, Patrick Palka wrote:
> > > > > > > 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  > > > > > > > > > > PARM_DECL>
> > > > > > > > > > > rather
> > > > > > > > > > > than in tsubst_function_decl for efficiency reasons, so
> > > > > > > > > > > that
> > > > > > > > > > > we
> > > > > > > > > > > don't
> > > > > > > > > > > have to perform another traversal over the DECL_ARGUMENTS
> > > 

[PATCH] PR target/48240

[Andrea Corallo]

Hi all,

I'd like to submit this for PR48240.

Bootstrapped on aarch64-unknown-linux-gnu.
Okay for trunk when finished with regression?

Andrea

gcc/ChangeLog

2020-??-??  Andrea Corallo  

PR target/48240
* gcc/config/aarch64/falkor-tag-collision-avoidance.c
(valid_src_p): Fix missing rtx type check.

gcc/testsuite/ChangeLog

2020-??-??  Andrea Corallo  

* gcc.target/aarch64/pr48240.c: New test.
>From 246337341a8b58c61dc29d2198b244da737b3ef0 Mon Sep 17 00:00:00 2001
From: Andrea Corallo 
Date: Wed, 8 Apr 2020 13:38:28 +0100
Subject: [PATCH] pr48240

---
 gcc/config/aarch64/falkor-tag-collision-avoidance.c | 9 ++---
 gcc/testsuite/gcc.target/aarch64/pr48240.c  | 9 +
 2 files changed, 15 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/aarch64/pr48240.c

diff --git a/gcc/config/aarch64/falkor-tag-collision-avoidance.c b/gcc/config/aarch64/falkor-tag-collision-avoidance.c
index 719df484ee61..4e07a43282f7 100644
--- a/gcc/config/aarch64/falkor-tag-collision-avoidance.c
+++ b/gcc/config/aarch64/falkor-tag-collision-avoidance.c
@@ -538,9 +538,12 @@ valid_src_p (rtx src, rtx_insn *insn, struct loop *loop, bool *pre_post,
   if (!aarch64_classify_address (, XEXP (x, 0), mode, true))
 return false;
 
-  unsigned regno = REGNO (addr.base);
-  if (global_regs[regno] || fixed_regs[regno])
-return false;
+  if (REG_P (addr.base))
+{
+  unsigned regno = REGNO (addr.base);
+  if (global_regs[regno] || fixed_regs[regno])
+	return false;
+}
 
   if (addr.type == ADDRESS_REG_WB)
 {
diff --git a/gcc/testsuite/gcc.target/aarch64/pr48240.c b/gcc/testsuite/gcc.target/aarch64/pr48240.c
new file mode 100644
index ..012af6afeca7
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/pr48240.c
@@ -0,0 +1,9 @@
+/* { dg-do compile } */
+/* { dg-options "-v -Os -mcpu=falkor -mpc-relative-literal-loads -mcmodel=large" } */
+
+extern void bar(const char *);
+
+void foo(void) {
+  for (;;)
+bar("");
+}
-- 
2.17.1

Re: [PATCH v2] c++: Fix ICE-on-invalid with lambda template [PR94507]

[Marek Polacek via Gcc-patches]

On Wed, Apr 08, 2020 at 08:55:08AM -0400, Jason Merrill via Gcc-patches wrote:
> On 4/6/20 9:05 PM, Marek Polacek wrote:
> > While reducing something else I noticed that we ICE on the following
> > invalid code.  In tsubst_lambda_expr, tsubst_template_decl has already
> > reported an error and returned the error_mark_node, so make sure we
> > don't ICE on that.  I'm using a goto here because we still have to
> > do finish_struct because it does popclass ().
> > 
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> > 
> > PR c++/94507 - ICE-on-invalid with lambda template.
> > * pt.c (tsubst_lambda_expr): Cope when tsubst_template_decl returns
> > error_mark_node.
> > 
> > * g++.dg/cpp2a/lambda-generic7.C: New test.
> > ---
> >   gcc/cp/pt.c  |  6 ++
> >   gcc/testsuite/g++.dg/cpp2a/lambda-generic7.C | 10 ++
> >   2 files changed, 16 insertions(+)
> >   create mode 100644 gcc/testsuite/g++.dg/cpp2a/lambda-generic7.C
> > 
> > diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
> > index 617c22f..f804ba18692 100644
> > --- a/gcc/cp/pt.c
> > +++ b/gcc/cp/pt.c
> > @@ -18876,6 +18876,11 @@ tsubst_lambda_expr (tree t, tree args, 
> > tsubst_flags_t complain, tree in_decl)
> > if (oldtmpl)
> > {
> >   tmpl = tsubst_template_decl (oldtmpl, args, complain, fntype);
> > + if (tmpl == error_mark_node)
> > +   {
> > + r = error_mark_node;
> > + goto out;
> > +   }
> >   fn = DECL_TEMPLATE_RESULT (tmpl);
> >   finish_member_declaration (tmpl);
> > }
> 
> Perhaps we also want an early exit if the tsubst_function_decl in the else
> clause returns error_mark_node?

Can't hurt (but don't have a testcase for it).

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?

-- >8 --
While reducing something else I noticed that we ICE on the following
invalid code.  In tsubst_lambda_expr, tsubst_template_decl has already
reported an error and returned the error_mark_node, so make sure we
don't ICE on that.  I'm using a goto here because we still have to
do finish_struct because it does popclass ().

PR c++/94507 - ICE-on-invalid with lambda template.
* pt.c (tsubst_lambda_expr): Cope when tsubst_template_decl or
tsubst_function_decl returns error_mark_node.

* g++.dg/cpp2a/lambda-generic7.C: New test.
---
 gcc/cp/pt.c  | 11 +++
 gcc/testsuite/g++.dg/cpp2a/lambda-generic7.C | 10 ++
 2 files changed, 21 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/lambda-generic7.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 617c22f..b9cbdb36de7 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -18876,6 +18876,11 @@ tsubst_lambda_expr (tree t, tree args, tsubst_flags_t 
complain, tree in_decl)
   if (oldtmpl)
{
  tmpl = tsubst_template_decl (oldtmpl, args, complain, fntype);
+ if (tmpl == error_mark_node)
+   {
+ r = error_mark_node;
+ goto out;
+   }
  fn = DECL_TEMPLATE_RESULT (tmpl);
  finish_member_declaration (tmpl);
}
@@ -18883,6 +1,11 @@ tsubst_lambda_expr (tree t, tree args, tsubst_flags_t 
complain, tree in_decl)
{
  tmpl = NULL_TREE;
  fn = tsubst_function_decl (oldfn, args, complain, fntype);
+ if (fn == error_mark_node)
+   {
+ r = error_mark_node;
+ goto out;
+   }
  finish_member_declaration (fn);
}
 
@@ -18948,6 +18958,7 @@ tsubst_lambda_expr (tree t, tree args, tsubst_flags_t 
complain, tree in_decl)
   maybe_add_lambda_conv_op (type);
 }
 
+out:
   finish_struct (type, /*attr*/NULL_TREE);
 
   insert_pending_capture_proxies ();
diff --git a/gcc/testsuite/g++.dg/cpp2a/lambda-generic7.C 
b/gcc/testsuite/g++.dg/cpp2a/lambda-generic7.C
new file mode 100644
index 000..bedba683671
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/lambda-generic7.C
@@ -0,0 +1,10 @@
+// PR c++/94507 - ICE-on-invalid with lambda template.
+// { dg-do compile { target c++2a } }
+
+struct S { };
+
+template
+auto foo(T, U)
+{
+  [] <> () { foo (S{}, S{}); }; // { dg-error "expected" }
+}

base-commit: 130f703da0c0d7b785d394b17df884379b4aadd9
-- 
Marek Polacek • Red Hat, Inc. • 300 A St, Boston, MA

Re: [PATCH] Allow new/delete operator deletion only for replaceable.

[Jason Merrill via Gcc-patches]

On 4/8/20 9:32 AM, Jakub Jelinek wrote:

On Wed, Apr 08, 2020 at 09:20:07AM -0400, Jason Merrill via Gcc-patches wrote:

On 4/8/20 4:47 AM, Richard Biener wrote:

On Tue, Apr 7, 2020 at 5:01 PM Martin Liška  wrote:


Hi.

The patch allows DCE to remove only replaceable operators new and delete.
That's achieved by proper mark up of all these operators in C++ FE.
The patch also brings all tests we've collected so far for the PR.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?


Grepping for uses of DECL_IS_OPERATOR_* reveals you miss comparing
the new flag in ipa-icf.c and cgraph node dumping in cgraph.c might want
to dump it as well.

Otherwise it looks reasonable.

So the mid-end parts are OK in case FE people are happy with this solution
for GCC 10.


This seems fine for GCC 10, though I wonder about using an attribute for
DECL_REPLACEABLE_OPERATOR rather than taking a bit in all FUNCTION_DECLs
that will only ever be set on a small handful.


If it is just for GCC 10 and we'll return the bit back to unused in GCC 11,
I'd think it is acceptable.


Agreed.

Jason

Re: [PATCH] Allow new/delete operator deletion only for replaceable.

[Jakub Jelinek via Gcc-patches]

On Wed, Apr 08, 2020 at 09:20:07AM -0400, Jason Merrill via Gcc-patches wrote:
> On 4/8/20 4:47 AM, Richard Biener wrote:
> > On Tue, Apr 7, 2020 at 5:01 PM Martin Liška  wrote:
> > > 
> > > Hi.
> > > 
> > > The patch allows DCE to remove only replaceable operators new and delete.
> > > That's achieved by proper mark up of all these operators in C++ FE.
> > > The patch also brings all tests we've collected so far for the PR.
> > > 
> > > Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> > > 
> > > Ready to be installed?
> > 
> > Grepping for uses of DECL_IS_OPERATOR_* reveals you miss comparing
> > the new flag in ipa-icf.c and cgraph node dumping in cgraph.c might want
> > to dump it as well.
> > 
> > Otherwise it looks reasonable.
> > 
> > So the mid-end parts are OK in case FE people are happy with this solution
> > for GCC 10.
> 
> This seems fine for GCC 10, though I wonder about using an attribute for
> DECL_REPLACEABLE_OPERATOR rather than taking a bit in all FUNCTION_DECLs
> that will only ever be set on a small handful.

If it is just for GCC 10 and we'll return the bit back to unused in GCC 11,
I'd think it is acceptable.

> For GCC 11 we probably want to make the distinction Jonathan mentions
> between new-expressions and direct calls to operator new.

Yeah.

Jakub

Re: [PATCH] Allow new/delete operator deletion only for replaceable.

[Jason Merrill via Gcc-patches]

On 4/8/20 4:47 AM, Richard Biener wrote:

On Tue, Apr 7, 2020 at 5:01 PM Martin Liška  wrote:


Hi.

The patch allows DCE to remove only replaceable operators new and delete.
That's achieved by proper mark up of all these operators in C++ FE.
The patch also brings all tests we've collected so far for the PR.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?


Grepping for uses of DECL_IS_OPERATOR_* reveals you miss comparing
the new flag in ipa-icf.c and cgraph node dumping in cgraph.c might want
to dump it as well.

Otherwise it looks reasonable.

So the mid-end parts are OK in case FE people are happy with this solution
for GCC 10.


This seems fine for GCC 10, though I wonder about using an attribute for 
DECL_REPLACEABLE_OPERATOR rather than taking a bit in all FUNCTION_DECLs 
that will only ever be set on a small handful.


For GCC 11 we probably want to make the distinction Jonathan mentions 
between new-expressions and direct calls to operator new.


Jason

Re: [PATCH] c++: Fix usage of CONSTRUCTOR_PLACEHOLDER_BOUNDARY inside array initializers [90996]

[Jason Merrill via Gcc-patches]

On 4/6/20 6:22 PM, Patrick Palka wrote:

On Mon, 6 Apr 2020, Jason Merrill wrote:


On 4/6/20 3:07 PM, Patrick Palka wrote:

This PR reports that since the introduction of the
CONSTRUCTOR_PLACEHOLDER_BOUNDARY flag, we are sometimes failing to resolve
PLACEHOLDER_EXPRs inside array initializers that refer to some inner
constructor.  In the testcase in the PR, we have as the initializer for "S
c[];"
the following

{{.a=(int &) &_ZGR1c_, .b={*(&)->a}}}

where CONSTRUCTOR_PLACEHOLDER_BOUNDARY is set on the second outermost
constructor.  However, we pass the whole initializer to replace_placeholders
in
store_init_value, and so due to the flag being set on the second outermost
ctor
it avoids recursing into the innermost constructor and we fail to resolve
the
PLACEHOLDER_EXPR within.

To fix this, we could perhaps either call replace_placeholders in more
places,
or we could change where we set CONSTRUCTOR_PLACEHOLDER_BOUNDARY.  This
patch
takes the latter approach -- when building up an array initializer, it
bubbles
any CONSTRUCTOR_PLACEHOLDER_BOUNDARY flag set on the element initializers up
to
the array initializer.  Doing so shouldn't create any new PLACEHOLDER_EXPR
resolution ambiguities because we don't deal with PLACEHOLDER_EXPRs of array
type in the frontend, as far as I can tell.


Interesting.  Yes, that sounds like it should work.


Does this look OK to comit after testing?


Yes.

Though I'm seeing "after testing" a lot; what testing are you doing before
sending patches?


Sorry for the sloppiness -- I should be writing "after a full
bootstrap/regtest" instead of "after testing" because I do indeed do
some testing before sending a patch.  In particular, I usually run and
inspect the outputs of

 make check RUNTESTFLAGS="dg.exp=*.C"
 make check RUNTESTFLAGS="old-deja.exp=*.C"
 make check RUNTESTFLAGS="conformance.exp=*ranges*"

in a build tree that is configured with --disable-bootstrap, as a quick
smoke test for the patch.  Is this a sufficient amount of testing before
sending a patch for review, or would you prefer that I do a full
bootstrap/regtest beforehand?


You don't need to do a full bootstrap and run non-C++ testsuites, but 
please run the full libstdc++ testsuite.


Is there a reason you aren't using 'make check-c++'?


In any case, I'll make sure to clearly convey the amount of testing that
was done and is remaining in future patch submissions.


Thanks.

Jason

Re: [PATCH] c++: Further fix for -fsanitize=vptr [PR94325]

[Jason Merrill via Gcc-patches]

On 4/6/20 6:43 PM, Jakub Jelinek wrote:

Hi!

For -fsanitize=vptr, we insert a NULL store into the vptr instead of just
adding a CLOBBER of this.  build_clobber_this makes the CLOBBER conditional
on in_charge (implicit) parameter whenever CLASSTYPE_VBASECLASSES, but when
adding this conditionalization to the -fsanitize=vptr code in PR87095,
I wanted it to catch some more cases when the class has CLASSTYPE_VBASECLASSES,
but the vptr is still not shared with something else, otherwise the
sanitization would be less effective.
The following testcase shows that the chosen test that CLASSTYPE_PRIMARY_BINFO
is non-NULL and has BINFO_VIRTUAL_P set wasn't sufficient,
the D class has still sizeof(D) == sizeof(void*) and thus contains just
a single vptr, but while in B::~B() this results in the vptr not being
cleared, in C::~C() this condition isn't true, as CLASSTYPE_PRIMARY_BINFO
in that case is B and is not BINFO_VIRTUAL_P, so it clears the vptr, but the
D::~D() dtor after invoking C::~C() invokes A::~A() with an already cleared
vptr, which is then reported.
The following patch is just a shot in the dark, keep looking through
CLASSTYPE_PRIMARY_BINFO until we find BINFO_VIRTUAL_P, but it works on the
existing testcase as well as this new one.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Or do we want some other test?


OK.


2020-04-06  Jakub Jelinek  

PR c++/94325
* decl.c (begin_destructor_body): For CLASSTYPE_VBASECLASSES class
dtors, if CLASSTYPE_PRIMARY_BINFO is non-NULL, but not BINFO_VIRTUAL_P,
look at CLASSTYPE_PRIMARY_BINFO of its BINFO_TYPE if it is not
BINFO_VIRTUAL_P, and so on.

* g++.dg/ubsan/vptr-15.C: New test.

--- gcc/cp/decl.c.jj2020-03-27 09:59:26.407083563 +0100
+++ gcc/cp/decl.c   2020-04-06 13:25:03.321511554 +0200
@@ -16662,14 +16662,20 @@ begin_destructor_body (void)
/* If the vptr is shared with some virtual nearly empty base,
   don't clear it if not in charge, the dtor of the virtual
   nearly empty base will do that later.  */
-   if (CLASSTYPE_VBASECLASSES (current_class_type)
-   && CLASSTYPE_PRIMARY_BINFO (current_class_type)
-   && BINFO_VIRTUAL_P
- (CLASSTYPE_PRIMARY_BINFO (current_class_type)))
+   if (CLASSTYPE_VBASECLASSES (current_class_type))
  {
-   stmt = convert_to_void (stmt, ICV_STATEMENT,
-   tf_warning_or_error);
-   stmt = build_if_in_charge (stmt);
+   tree c = current_class_type;
+   while (CLASSTYPE_PRIMARY_BINFO (c))
+ {
+   if (BINFO_VIRTUAL_P (CLASSTYPE_PRIMARY_BINFO (c)))
+ {
+   stmt = convert_to_void (stmt, ICV_STATEMENT,
+   tf_warning_or_error);
+   stmt = build_if_in_charge (stmt);
+   break;
+ }
+   c = BINFO_TYPE (CLASSTYPE_PRIMARY_BINFO (c));
+ }
  }
finish_decl_cleanup (NULL_TREE, stmt);
  }
--- gcc/testsuite/g++.dg/ubsan/vptr-15.C.jj 2020-04-06 13:32:43.501627756 
+0200
+++ gcc/testsuite/g++.dg/ubsan/vptr-15.C2020-04-06 13:37:52.642001353 
+0200
@@ -0,0 +1,14 @@
+// PR c++/94325
+// { dg-do run { target c++11 } }
+// { dg-options "-fsanitize=vptr -fno-sanitize-recover=vptr" }
+
+struct A { virtual ~A () = default; };
+struct B : public virtual A {};
+struct C : public B {};
+struct D : public C {};
+
+int
+main ()
+{
+  D a;
+}

Jakub

Re: [PATCH] c++: Fix ICE-on-invalid with lambda template [PR94507]

[Jason Merrill via Gcc-patches]

On 4/6/20 9:05 PM, Marek Polacek wrote:

While reducing something else I noticed that we ICE on the following
invalid code.  In tsubst_lambda_expr, tsubst_template_decl has already
reported an error and returned the error_mark_node, so make sure we
don't ICE on that.  I'm using a goto here because we still have to
do finish_struct because it does popclass ().

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?

PR c++/94507 - ICE-on-invalid with lambda template.
* pt.c (tsubst_lambda_expr): Cope when tsubst_template_decl returns
error_mark_node.

* g++.dg/cpp2a/lambda-generic7.C: New test.
---
  gcc/cp/pt.c  |  6 ++
  gcc/testsuite/g++.dg/cpp2a/lambda-generic7.C | 10 ++
  2 files changed, 16 insertions(+)
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/lambda-generic7.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 617c22f..f804ba18692 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -18876,6 +18876,11 @@ tsubst_lambda_expr (tree t, tree args, tsubst_flags_t 
complain, tree in_decl)
if (oldtmpl)
{
  tmpl = tsubst_template_decl (oldtmpl, args, complain, fntype);
+ if (tmpl == error_mark_node)
+   {
+ r = error_mark_node;
+ goto out;
+   }
  fn = DECL_TEMPLATE_RESULT (tmpl);
  finish_member_declaration (tmpl);
}


Perhaps we also want an early exit if the tsubst_function_decl in the 
else clause returns error_mark_node?



@@ -18948,6 +18953,7 @@ tsubst_lambda_expr (tree t, tree args, tsubst_flags_t 
complain, tree in_decl)
maybe_add_lambda_conv_op (type);
  }
  
+out:

finish_struct (type, /*attr*/NULL_TREE);
  
insert_pending_capture_proxies ();

diff --git a/gcc/testsuite/g++.dg/cpp2a/lambda-generic7.C 
b/gcc/testsuite/g++.dg/cpp2a/lambda-generic7.C
new file mode 100644
index 000..bedba683671
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/lambda-generic7.C
@@ -0,0 +1,10 @@
+// PR c++/94507 - ICE-on-invalid with lambda template.
+// { dg-do compile { target c++2a } }
+
+struct S { };
+
+template
+auto foo(T, U)
+{
+  [] <> () { foo (S{}, S{}); }; // { dg-error "expected" }
+}

base-commit: 130f703da0c0d7b785d394b17df884379b4aadd9

Re: [PATCH] c++: ICE with defaulted comparison operator [PR94478]

[Jason Merrill via Gcc-patches]

On 4/7/20 3:14 PM, Marek Polacek wrote:

Here we ICE because early_check_defaulted_comparison passed a null
ctx to same_type_p.  The attached test is ill-formed according to
[class.compare.default]/1, so fixed by detecting this case early.

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?


OK.


PR c++/94478 - ICE with defaulted comparison operator
* method.c (early_check_defaulted_comparison): Give an error when the
context is null.

* g++.dg/cpp2a/spaceship-err4.C: New test.
---
  gcc/cp/method.c | 11 +++
  gcc/testsuite/g++.dg/cpp2a/spaceship-err4.C |  7 +++
  2 files changed, 18 insertions(+)
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/spaceship-err4.C

diff --git a/gcc/cp/method.c b/gcc/cp/method.c
index 41b9ff86bdd..9a21bfc1f66 100644
--- a/gcc/cp/method.c
+++ b/gcc/cp/method.c
@@ -1102,6 +1102,17 @@ early_check_defaulted_comparison (tree fn)
return false;
  }
  
+  if (!ctx)

+{
+  if (DECL_OVERLOADED_OPERATOR_IS (fn, SPACESHIP_EXPR))
+   error_at (loc, "three-way comparison operator can only be defaulted "
+ "in a class definition");
+  else
+   error_at (loc, "equality comparison operator can only be defaulted "
+ "in a class definition");
+  return false;
+}
+
if (!DECL_OVERLOADED_OPERATOR_IS (fn, SPACESHIP_EXPR)
&& !same_type_p (TREE_TYPE (TREE_TYPE (fn)), boolean_type_node))
  {
diff --git a/gcc/testsuite/g++.dg/cpp2a/spaceship-err4.C 
b/gcc/testsuite/g++.dg/cpp2a/spaceship-err4.C
new file mode 100644
index 000..00f90ced255
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/spaceship-err4.C
@@ -0,0 +1,7 @@
+// PR c++/94478 - ICE with defaulted comparison operator.
+// { dg-do compile { target c++2a } }
+
+struct B {};
+bool operator!=(const B&, const B&) = default; // { dg-error "equality comparison 
operator can only be defaulted in a class definition" }
+bool operator==(const B&, const B&) = default; // { dg-error "equality comparison 
operator can only be defaulted in a class definition" }
+bool operator<=>(const B&, const B&) = default; // { dg-error "three-way comparison 
operator can only be defaulted in a class definition" }

base-commit: 3d947f1f27188e3a61ba7f42399b1c348469fe13

RE: [PATCH][Arm][1/3] Support for Arm Custom Datapath Extension (CDE): enable the feature

[Kyrylo Tkachov]

> -Original Message-
> From: Dennis Zhang 
> Sent: 08 April 2020 12:34
> To: Kyrylo Tkachov ; gcc-patches@gcc.gnu.org
> Cc: nd ; Richard Earnshaw ;
> Ramana Radhakrishnan 
> Subject: Re: [PATCH][Arm][1/3] Support for Arm Custom Datapath Extension
> (CDE): enable the feature
> 
> Hi Kyrylo
> 
> > Hi Dennis,
> >
> > > -Original Message-
> > > From: Dennis Zhang 
> > > Sent: 19 March 2020 14:03
> > > To: Kyrylo Tkachov ; gcc-
> patc...@gcc.gnu.org
> > > Cc: nd ; Richard Earnshaw
> ;
> > > Ramana Radhakrishnan 
> > > Subject: Re: [PATCH][Arm][1/3] Support for Arm Custom Datapath
> Extension
> > > (CDE): enable the feature
> > >
> > > Hi Kyrylo,
> > >
> > > >
> > > >From: Kyrylo Tkachov 
> > > >Sent: Wednesday, March 18, 2020 9:04 AM
> > > >To: Dennis Zhang; gcc-patches@gcc.gnu.org
> > > >Cc: nd; Richard Earnshaw; Ramana Radhakrishnan
> > > >Subject: RE: [PATCH][Arm][1/3] Support for Arm Custom Datapath
> > > >Extension (CDE): enable the feature
> > > >
> > > >Hi Dennis,
> > > >
> > > >> -Original Message-
> > > >> From: Dennis Zhang 
> > > >> Sent: 12 March 2020 12:06
> > > >> To: gcc-patches@gcc.gnu.org
> > > >> Cc: nd ; Richard Earnshaw
> ;
> > > >> Ramana Radhakrishnan ; Kyrylo
> > > Tkachov
> > > >> 
> > > >> Subject: [PATCH][Arm][1/3] Support for Arm Custom Datapath
> Extension
> > > >> (CDE): enable the feature
> > > >>
> > > >> Hi all,
> > > >>
> > > >> This patch is part of a series that adds support for the ARMv8.m
> > > >> Custom Datapath Extension.
> > > >> This patch defines the options cdecp0-cdecp7 for CLI to enable the
> > > >> CDE on corresponding coprocessor 0-7.
> > > >> It also adds new check-effective for CDE feature.
> > > >>
> > > >> ISA has been announced at
> > > >> https://developer.arm.com/architectures/instruction-sets/custom-
> > > >> instructions
> > > >>
> > > >> Regtested and bootstrapped.
> > > >>
> > > >> Is it OK to commit please?
> > > >
> > > >Can you please rebase this patch on top of the recent MVE commits?
> > > >It currently doesn't apply cleanly to trunk.
> > > >Thanks,
> > > >Kyrill
> > >
> > > The rebase patches is as attached.
> > > Is it OK to commit?
> >
> > Ok, with a few fixes...
> >
> > diff --git a/gcc/testsuite/gcc.target/arm/pragma_cde.c
> b/gcc/testsuite/gcc.target/arm/pragma_cde.c
> > new file mode 100644
> > index 000..97643a08405
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.target/arm/pragma_cde.c
> > @@ -0,0 +1,98 @@
> > +/* Test for CDE #prama target macros.  */
> > +/* { dg-do compile } */
> >
> > Typo in "pragma" in the comment.
> >
> >
> > +# A series of routines are created to 1) check if a given architecture is
> > +# effective (check_effective_target_*_ok) and then 2) give the
> corresponding
> > +# flags that enable the architecture (add_options_for_*).
> > +# The series includes:
> > +#   arm_v8m_main_cde: Armv8-m CDE (Custom Datapath Extension).
> > +#   arm_v8m_main_cde_fp: Armv8-m CDE with FP registers.
> > +#   arm_v8_1m_main_cde_mve: Armv8.1-m CDE with MVE.
> > +# Usage:
> > +#   /* { dg-require-effective-target arm_v8m_main_cde_ok } */
> > +#   /* { dg-add-options arm_v8m_main_cde } */
> > +# The tests are valid for Arm.
> > +
> > +foreach { armfunc armflag armdef } {
> >
> >   New effective target checks need to be documented in doc/invoke.texi
> >
> 
> Thanks a lot for the review.
> The document has been updated and the changelog, too.
> Is it ready to commit please?

Ok.
Thanks,
Kyrill

> 
> Cheers
> Dennis
> 
> gcc/ChangeLog:
> 
> 2020-04-08  Dennis Zhang  
> 
> * config.gcc: Add arm_cde.h.
> * config/arm/arm-c.c (arm_cpu_builtins): Define or undefine
> __ARM_FEATURE_CDE and __ARM_FEATURE_CDE_COPROC.
> * config/arm/arm-cpus.in (cdecp0, cdecp1, ..., cdecp7): New options.
> * config/arm/arm.c (arm_option_reconfigure_globals): Configure
> arm_arch_cde and arm_arch_cde_coproc to store the feature bits.
> * config/arm/arm.h (TARGET_CDE): New macro.
> * config/arm/arm_cde.h: New file.
> * doc/invoke.texi: Document CDE options +cdecp[0-7].
> * doc/sourcebuild.texi (arm_v8m_main_cde_ok): Document new target
> supports option.
> (arm_v8m_main_cde_fp, arm_v8_1m_main_cde_mve): Likewise.
> 
> gcc/testsuite/ChangeLog:
> 
> 2020-04-08  Dennis Zhang  
> 
> * gcc.target/arm/pragma_cde.c: New test.
> * lib/target-supports.exp (arm_v8m_main_cde_ok): New target support
> option.
> (arm_v8m_main_cde_fp, arm_v8_1m_main_cde_mve): Likewise.

update polytypes.c -flax-vector-conversions msg

[Alexandre Oliva]

Since commit 2f6d557ff82876432be76b1892c6c3783c0095f4 AKA SVN-r269586,
the inform() message suggesting the use of -flax-vector-conversions
has had quotes around the option name, but the testcase still expected
the message without the quotes.  This patch adds to the expected
compiler output the quotes that are now issues.

I'm installing this shortly, as obvious.  Tested on x86_64-linux-gnu
with a cross compiler to an arm target.


for  gcc/testsuite/ChangeLog

* gcc.target/arm/polytypes.c: Add quotes around
-flax-vector-conversions.
---
 gcc/testsuite/gcc.target/arm/polytypes.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.target/arm/polytypes.c 
b/gcc/testsuite/gcc.target/arm/polytypes.c
index 110d62a8..3753466 100644
--- a/gcc/testsuite/gcc.target/arm/polytypes.c
+++ b/gcc/testsuite/gcc.target/arm/polytypes.c
@@ -28,7 +28,7 @@ void foo ()
   poly8x16_t v128_8;
   poly16x8_t v128_16;
 
-  s64_8 (v64_8); /* { dg-message "use -flax-vector-conversions" } */
+  s64_8 (v64_8); /* { dg-message "use '-flax-vector-conversions'" } */
   /* { dg-error "incompatible type for argument 1 of 's64_8'" "" { target 
*-*-* } .-1 } */
   u64_8 (v64_8); /* { dg-error "incompatible type for argument 1 of 'u64_8'" } 
*/
   p64_8 (v64_8);


-- 
Alexandre Oliva, freedom fighterhe/himhttps://FSFLA.org/blogs/lxo/
Free Software Evangelist  Stallman was right, but he's left :(
GNU Toolchain Engineer   Live long and free, and prosper ethically

[PATCH] rtl-optimization/93946 - fix TBAA for redundant store removal in CSE

[Richard Biener]

It turns out RTL CSE tries to remove redundant stores but fails to
do the usual validity check what such a change is TBAA neutral to
later loads.

This now triggers with the PR93946 testcases on nios2.

Bootstrap & regtest running on x86_64-unknown-linux-gnu.

Richard.

2020-04-08  Richard Biener  

PR rtl-optimization/93946
* cse.c (cse_insn): Record the tabled expression in
src_related.  Verify a redundant store removal is valid.
---
 gcc/cse.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/gcc/cse.c b/gcc/cse.c
index 3e8724b3fed..f07bbdbebad 100644
--- a/gcc/cse.c
+++ b/gcc/cse.c
@@ -5074,7 +5074,7 @@ cse_insn (rtx_insn *insn)
 to prefer it.  Copy it to src_related.  The code below will
 then give it a negative cost.  */
  if (GET_CODE (dest) == code && rtx_equal_p (p->exp, dest))
-   src_related = dest;
+   src_related = p->exp;
}
 
   /* Find the cheapest valid equivalent, trying all the available
@@ -5332,7 +5332,16 @@ cse_insn (rtx_insn *insn)
   && rtx_equal_p (trial, dest)
   && !side_effects_p (dest)
   && (cfun->can_delete_dead_exceptions
-  || insn_nothrow_p (insn)))
+  || insn_nothrow_p (insn))
+  /* We can only remove the later store if the earlier aliases
+ at least all accesses the later one.  */
+  && (!MEM_P (trial)
+  || ((MEM_ALIAS_SET (dest) == MEM_ALIAS_SET (trial)
+   || alias_set_subset_of (MEM_ALIAS_SET (dest),
+   MEM_ALIAS_SET (trial)))
+   && (!MEM_EXPR (trial)
+   || refs_same_for_tbaa_p (MEM_EXPR (trial),
+MEM_EXPR (dest))
{
  SET_SRC (sets[i].rtl) = trial;
  noop_insn = true;
-- 
2.16.4

Re: [PATCH][Arm][1/3] Support for Arm Custom Datapath Extension (CDE): enable the feature

[Dennis Zhang]

Hi Kyrylo

> Hi Dennis,
>
> > -Original Message-
> > From: Dennis Zhang 
> > Sent: 19 March 2020 14:03
> > To: Kyrylo Tkachov ; gcc-patches@gcc.gnu.org
> > Cc: nd ; Richard Earnshaw ;
> > Ramana Radhakrishnan 
> > Subject: Re: [PATCH][Arm][1/3] Support for Arm Custom Datapath Extension
> > (CDE): enable the feature
> >
> > Hi Kyrylo,
> >
> > >
> > >From: Kyrylo Tkachov 
> > >Sent: Wednesday, March 18, 2020 9:04 AM
> > >To: Dennis Zhang; gcc-patches@gcc.gnu.org
> > >Cc: nd; Richard Earnshaw; Ramana Radhakrishnan
> > >Subject: RE: [PATCH][Arm][1/3] Support for Arm Custom Datapath
> > >Extension (CDE): enable the feature
> > >
> > >Hi Dennis,
> > >
> > >> -Original Message-
> > >> From: Dennis Zhang 
> > >> Sent: 12 March 2020 12:06
> > >> To: gcc-patches@gcc.gnu.org
> > >> Cc: nd ; Richard Earnshaw ;
> > >> Ramana Radhakrishnan ; Kyrylo
> > Tkachov
> > >> 
> > >> Subject: [PATCH][Arm][1/3] Support for Arm Custom Datapath Extension
> > >> (CDE): enable the feature
> > >>
> > >> Hi all,
> > >>
> > >> This patch is part of a series that adds support for the ARMv8.m
> > >> Custom Datapath Extension.
> > >> This patch defines the options cdecp0-cdecp7 for CLI to enable the
> > >> CDE on corresponding coprocessor 0-7.
> > >> It also adds new check-effective for CDE feature.
> > >>
> > >> ISA has been announced at
> > >> https://developer.arm.com/architectures/instruction-sets/custom-
> > >> instructions
> > >>
> > >> Regtested and bootstrapped.
> > >>
> > >> Is it OK to commit please?
> > >
> > >Can you please rebase this patch on top of the recent MVE commits?
> > >It currently doesn't apply cleanly to trunk.
> > >Thanks,
> > >Kyrill
> >
> > The rebase patches is as attached.
> > Is it OK to commit?
>
> Ok, with a few fixes...
>
> diff --git a/gcc/testsuite/gcc.target/arm/pragma_cde.c 
> b/gcc/testsuite/gcc.target/arm/pragma_cde.c
> new file mode 100644
> index 000..97643a08405
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/arm/pragma_cde.c
> @@ -0,0 +1,98 @@
> +/* Test for CDE #prama target macros.  */
> +/* { dg-do compile } */
>
> Typo in "pragma" in the comment.
>
>
> +# A series of routines are created to 1) check if a given architecture is
> +# effective (check_effective_target_*_ok) and then 2) give the corresponding
> +# flags that enable the architecture (add_options_for_*).
> +# The series includes:
> +#   arm_v8m_main_cde: Armv8-m CDE (Custom Datapath Extension).
> +#   arm_v8m_main_cde_fp: Armv8-m CDE with FP registers.
> +#   arm_v8_1m_main_cde_mve: Armv8.1-m CDE with MVE.
> +# Usage:
> +#   /* { dg-require-effective-target arm_v8m_main_cde_ok } */
> +#   /* { dg-add-options arm_v8m_main_cde } */
> +# The tests are valid for Arm.
> +
> +foreach { armfunc armflag armdef } {
>
>   New effective target checks need to be documented in doc/invoke.texi
>

Thanks a lot for the review.
The document has been updated and the changelog, too.
Is it ready to commit please?

Cheers
Dennis

gcc/ChangeLog:

2020-04-08  Dennis Zhang  

* config.gcc: Add arm_cde.h.
* config/arm/arm-c.c (arm_cpu_builtins): Define or undefine
__ARM_FEATURE_CDE and __ARM_FEATURE_CDE_COPROC.
* config/arm/arm-cpus.in (cdecp0, cdecp1, ..., cdecp7): New options.
* config/arm/arm.c (arm_option_reconfigure_globals): Configure
arm_arch_cde and arm_arch_cde_coproc to store the feature bits.
* config/arm/arm.h (TARGET_CDE): New macro.
* config/arm/arm_cde.h: New file.
* doc/invoke.texi: Document CDE options +cdecp[0-7].
* doc/sourcebuild.texi (arm_v8m_main_cde_ok): Document new target
supports option.
(arm_v8m_main_cde_fp, arm_v8_1m_main_cde_mve): Likewise.

gcc/testsuite/ChangeLog:

2020-04-08  Dennis Zhang  

* gcc.target/arm/pragma_cde.c: New test.
* lib/target-supports.exp (arm_v8m_main_cde_ok): New target support
option.
(arm_v8m_main_cde_fp, arm_v8_1m_main_cde_mve): Likewise.

arm-m-cde-cli-20200408.patch
Description: arm-m-cde-cli-20200408.patch

[Patch][Fortran] Fix name conflict check for use-assoc (PR 92736)

[Tobias Burnus]

Hi all,

this issue only occurs when use associating a symbol in a module
and then again use-associating the same symbol in its submodule.

If one simply uses
  use m, only: i
  use m, only: i
the issue does not occur as all symbols are only created after
parsing all use statements.

And for
  use m, only: i
contains
  subroutine sub()
use m, only: i
one has different gfc_namespaces such that they cannot conflict.

This is a GCC 9 + mainline/10 regression, hence:
OK for those two branches?

Tobias

-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter
[Fortran] Fix name conflict check for use-assoc (PR 92736)

	* module.c (gfc_match_use): Fix name-conflict check for use-associating
	the same symbol again in a submodule.

	* gfortran.dg/use_rename_10.f90: New.
	* gfortran.dg/use_rename_11.f90: New.

 gcc/fortran/module.c| 26 +-
 gcc/testsuite/gfortran.dg/use_rename_10.f90 | 28 ++
 gcc/testsuite/gfortran.dg/use_rename_11.f90 | 79 +
 3 files changed, 121 insertions(+), 12 deletions(-)

diff --git a/gcc/fortran/module.c b/gcc/fortran/module.c
index 73a3f202834..eccf92bf658 100644
--- a/gcc/fortran/module.c
+++ b/gcc/fortran/module.c
@@ -648,18 +648,6 @@ gfc_match_use (void)
 	  if (type == INTERFACE_USER_OP)
 	new_use->op = INTRINSIC_USER;
 
-	  st = gfc_find_symtree (gfc_current_ns->sym_root, name);
-	  if (st && type != INTERFACE_USER_OP)
-	{
-	  if (m == MATCH_YES)
-		gfc_error ("Symbol %qs at %L conflicts with the rename symbol "
-			   "at %L", name, >n.sym->declared_at, );
-	  else
-		gfc_error ("Symbol %qs at %L conflicts with the symbol "
-			   "at %L", name, >n.sym->declared_at, );
-	  goto cleanup;
-	}
-
 	  if (use_list->only_flag)
 	{
 	  if (m != MATCH_YES)
@@ -691,6 +679,20 @@ gfc_match_use (void)
 		goto cleanup;
 	}
 
+	  st = gfc_find_symtree (gfc_current_ns->sym_root, name);
+	  if (st && type != INTERFACE_USER_OP
+	  && (st->n.sym->module != use_list->module_name
+		  || strcmp (st->n.sym->name, new_use->use_name) != 0))
+	{
+	  if (m == MATCH_YES)
+		gfc_error ("Symbol %qs at %L conflicts with the rename symbol "
+			   "at %L", name, >n.sym->declared_at, );
+	  else
+		gfc_error ("Symbol %qs at %L conflicts with the symbol "
+			   "at %L", name, >n.sym->declared_at, );
+	  goto cleanup;
+	}
+
 	  if (strcmp (new_use->use_name, use_list->module_name) == 0
 	  || strcmp (new_use->local_name, use_list->module_name) == 0)
 	{
diff --git a/gcc/testsuite/gfortran.dg/use_rename_10.f90 b/gcc/testsuite/gfortran.dg/use_rename_10.f90
new file mode 100644
index 000..736d319c5a9
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/use_rename_10.f90
@@ -0,0 +1,28 @@
+! { dg-do compile }
+!
+! PR fortran/92736
+!
+! Contributed by Chinoune Mehdi
+!
+module m1
+  implicit none
+  integer, parameter :: i = 10
+end module m1
+
+module m2
+  use m1, only : i
+  implicit none
+  interface
+module subroutine sb1()
+end subroutine sb1
+  end interface
+end module m2
+
+submodule(m2) s1
+  use m1, only : i
+  implicit none
+contains
+  module subroutine sb1
+print *,"hello", i
+  end subroutine sb1
+end submodule s1
diff --git a/gcc/testsuite/gfortran.dg/use_rename_11.f90 b/gcc/testsuite/gfortran.dg/use_rename_11.f90
new file mode 100644
index 000..b713ae01d36
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/use_rename_11.f90
@@ -0,0 +1,79 @@
+! { dg-do compile }
+!
+! PR fortran/92736
+!
+module m
+  integer :: i, j
+end module m
+
+module m2
+  integer :: i, k
+end module m2
+
+module mod
+  use m, only: i
+  interface
+module subroutine sb1()
+end subroutine sb1
+  end interface
+end
+
+! Error: use 'i' both for m's 'i' and 'j'
+submodule(mod) sub ! { dg-error "Symbol 'i' at .1. conflicts with the rename symbol" }
+  use m1, only: i => j ! { dg-error "Symbol 'i' at .1. conflicts with the rename symbol" }
+end
+
+module mod2
+  use m, only: i
+  interface
+module subroutine sb1()
+end subroutine sb1
+  end interface
+end
+
+! Error: use 'i' both for m's 'i' and m2's 'k'
+submodule(mod2) sub2   ! { dg-error "Symbol 'i' at .1. conflicts with the rename symbol" }
+  use m2, only: i => k ! { dg-error "Symbol 'i' at .1. conflicts with the rename symbol" }
+end
+
+
+module mod3
+  use m, only: i
+  interface
+module subroutine sb1()
+end subroutine sb1
+  end interface
+end
+
+! Error: use 'i' both for m's 'i' and m2's 'i'
+submodule(mod3) sub3  ! { dg-error "Symbol 'i' at .1. conflicts with the symbol" }
+  use m2, only: i ! { dg-error "Symbol 'i' at .1. conflicts with the symbol" }
+end
+
+
+module mod4
+  use m, only: mm => i, i
+  interface
+module subroutine sb1()
+end subroutine sb1
+  end interface
+end
+
+! OK
+submodule(mod4) sub4
+  use m, only: i
+  use m, only: mm => i
+end
+

Re: [testsuite][arm] Fix cmse-15.c expected output

[Richard Sandiford]

Christophe Lyon via Gcc-patches  writes:
> Hi,
>
> While checking Martin's fix for PR ipa/94445, he made me realize that
> the cmse-15.c testcase still fails at -Os because ICF means that we
> generate
> nonsecure2:
> b   nonsecure0
>
> which is OK, but does not match the currently expected
> nonsecure2:
> ...
> bl  __gnu_cmse_nonsecure_call
>
> (see https://gcc.gnu.org/pipermail/gcc-patches/2020-April/543190.html)
>
> The test has already different expectations for v8-M and v8.1-M.
>
> I've decided to try to use check-function-bodies to account for the
> different possibilities:
> - v8-M vs v8.1-M via two different prefixes
> - code generation variants (-0?) via multiple regexps
>
> I've tested that the test now passes with --target-board=-march=armv8-m.main
> and --target-board=-march=armv8.1-m.main.
>
> I feel this a bit too much of a burden for the purpose, maybe there's
> a better way of handling all these alternatives (in particular,
> there's a lot of duplication since the expected code for the secure*
> functions is the same for v8-M and v8.1-M).

FWIW, an alternative is to give multiple versions with the same prefix
and use { target ... } to select between them.  E.g.:

/*
** foo:   { target a }
**  ...
*/
/*
** foo:   { target { ! a } }
**  ...
*/

Thanks,
Richard

RE: [Arm] Implement CDE intrinsics for MVE registers.

[Kyrylo Tkachov]

Hi Matthew,

> -Original Message-
> From: Matthew Malcomson 
> Sent: 08 April 2020 09:22
> To: gcc-patches@gcc.gnu.org
> Cc: nd ; Kyrylo Tkachov ;
> Ramana Radhakrishnan ; Richard
> Earnshaw ; ni...@redhat.com
> Subject: [Arm] Implement CDE intrinsics for MVE registers.
> 
> 
> This patch updates the previous one by rebasing onto the recent MVE
> patches on
> trunk.
> 
> Implement CDE intrinsics on MVE registers.
> 
> Other than the basics required for adding intrinsics this patch consists
> of three changes.
> 
> ** We separate out the MVE types and casts from the arm_mve.h header.
> 
> This is so that the types can be used in arm_cde.h without the need to
> include
> the entire arm_mve.h header.
> The only type that arm_cde.h needs is `uint8x16_t`, so this separation could
> be
> avoided by using a `typedef` in this file.
> Since the introduced intrinsics are all defined to act on the full range of 
> MVE
> types, declaring all such types seems intuitive since it will provide their
> declaration to the user too.
> 
> This arm_mve_types.h header not only includes the MVE types, but also
> the conversion intrinsics between them.
> Some of the conversion intrinsics are needed for arm_cde.h, but most are
> not.  We include all conversion intrinsics to keep the definition of
> such conversion functions all in one place, on the understanding that
> extra conversion functions being defined when including `arm_cde.h` is
> not a problem.
> 
> ** We define the TARGET_RESOLVE_OVERLOADED_BUILTIN hook for the
> Arm backend.
> 
> This is needed to implement the polymorphism for the required intrinsics.
> The intrinsics have no specialised version, and the resulting assembly
> instruction for all different types should be exactly the same.
> Due to this we have implemented these intrinsics via one builtin on one type.
> All other calls to the intrinsic with different types are implicitly cast to
> the one type that is defined, and hence are all expanded to the same RTL
> pattern that is only defined for one machine mode.
> 
> ** We seperate the initialisation of the CDE intrinsics from others.
> 
> This allows us to ensure that the CDE intrinsics acting on MVE registers
> are only created when both CDE and MVE are available.
> Only initialising these builtins when both features are available is
> especially important since they require a type that is only initialised
> when the target supports hard float.  Hence trying to initialise these
> builtins on a soft float target would cause an ICE.
> 
> Testing done:
>   Full bootstrap and regtest on arm-none-linux-gnueabihf
>   Regression test on arm-none-eabi
> 
> 
> NOTE: This patch depends on the CDE intrinsic framework patch by Dennis.
> https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542008.html
> 
> 
> Ok for trunk?

Ok.
Thanks,
Kyrill

> 
> gcc/ChangeLog:
> 
> 2020-04-08  Matthew Malcomson  
> 
>   * config.gcc (arm_mve_types.h): New extra_header for arm.
>   * config/arm/arm-builtins.c (arm_resolve_overloaded_builtin): New.
>   (arm_init_cde_builtins): New.
>   (arm_init_acle_builtins): Remove initialisation of CDE builtins.
>   (arm_init_builtins): Call arm_init_cde_builtins when target
>   supports CDE.
>   * config/arm/arm-c.c (arm_resolve_overloaded_builtin): New
> declaration.
>   (arm_register_target_pragmas): Initialise resolve_overloaded_builtin
>   hook to the implementation for the arm backend.
>   * config/arm/arm.h (ARM_MVE_CDE_CONST_1): New.
>   (ARM_MVE_CDE_CONST_2): New.
>   (ARM_MVE_CDE_CONST_3): New.
>   * config/arm/arm_cde.h (__arm_vcx1q_u8): New.
>   (__arm_vcx1qa): New.
>   (__arm_vcx2q): New.
>   (__arm_vcx2q_u8): New.
>   (__arm_vcx2qa): New.
>   (__arm_vcx3q): New.
>   (__arm_vcx3q_u8): New.
>   (__arm_vcx3qa): New.
>   * config/arm/arm_cde_builtins.def (vcx1q, vcx1qa, vcx2q, vcx2qa,
> vcx3q,
>   vcx3qa): New builtins defined.
>   * config/arm/arm_mve.h: Move typedefs and conversion intrinsics
>   to arm_mve_types.h header.
>   * config/arm/arm_mve_types.h: New file.
>   * config/arm/mve.md (arm_vcx1qv16qi, arm_vcx1qav16qi,
> arm_vcx2qv16qi,
>   arm_vcx2qav16qi, arm_vcx3qv16qi, arm_vcx3qav16qi): New patterns.
>   * config/arm/predicates.md (const_int_mve_cde1_operand,
>   const_int_mve_cde2_operand, const_int_mve_cde3_operand): New.
> 
> gcc/testsuite/ChangeLog:
> 
> 2020-04-08  Matthew Malcomson  
>   Dennis Zhang  
> 
>   * gcc.target/arm/acle/cde-mve-error-1.c: New test.
>   * gcc.target/arm/acle/cde-mve-error-2.c: New test.
>   * gcc.target/arm/acle/cde-mve-error-3.c: New test.
>   * gcc.target/arm/acle/cde-mve-full-assembly.c: New test.
>   * gcc.target/arm/acle/cde-mve-tests.c: New test.
>   * lib/target-supports.exp (arm_v8_1m_main_cde_mve_fp): New
> check
>   effective.

[PATCH] [Arm] Implement scalar Custom Datapath Extension intrinsics

[Matthew Malcomson]

Suggestions applied.  I didn't update the indentation since it seems good to me
(with the `(unspec:SIDI ...)` indented one more level than the SET as
suggested).  I'm guessing it looked strange since that line is indented with a
tab and that can look different in different text editors.


This patch introduces the scalar CDE (Custom Datapath Extension)
intrinsics for the arm backend.

There is nothing beyond the standard in this patch.  We simply build upon what
has been done by Dennis for the vector intrinsics.

We do add `+cdecp6` to the default arguments for `target-supports.exp`, this
allows for using coprocessor 6 in tests. This patch uses an alternate
coprocessor to ease assembler scanning by looking for a use of coprocessor 6.

We also ensure that any DImode registers are put in an even-odd register pair
when compiling for a target with CDE -- this avoids faulty code generation for
-Os when producing the cx*d instructions.

Testing done:
Bootstrapped and regtested for arm-none-linux-gnueabihf.

gcc/ChangeLog:

2020-04-08  Matthew Malcomson  

* config/arm/arm.c (arm_hard_regno_mode_ok): DImode registers forced
into even-odd register pairs for TARGET_CDE.
* config/arm/arm.h (ARM_CCDE_CONST_1): New.
(ARM_CCDE_CONST_2): New.
(ARM_CCDE_CONST_3): New.
* config/arm/arm.md (arm_cx1si, arm_cx1di arm_cx1asi, arm_cx1adi
arm_cx2si, arm_cx2di arm_cx2asi, arm_cx2adi arm_cx3si, arm_cx3di
arm_cx3asi, arm_cx3adi): New patterns.
* config/arm/arm_cde.h (__arm_cx1, __arm_cx1a, __arm_cx2, __arm_cx2a,
__arm_cx3, __arm_cx3a, __arm_cx1d, __arm_cx1da, __arm_cx2d, __arm_cx2da,
__arm_cx3d, __arm_cx3da): New ACLE function macros.
* config/arm/arm_cde_builtins.def (cx1, cx1a, cx2, cx2a, cx3, cx3a):
Define intrinsics.
* config/arm/iterators.md (cde_suffix, cde_dest): New mode attributes.
* config/arm/predicates.md (const_int_ccde1_operand,
const_int_ccde2_operand, const_int_ccde3_operand): New.
* config/arm/unspecs.md (UNSPEC_CDE, UNSPEC_CDEA): New.

gcc/testsuite/ChangeLog:

2020-04-08  Matthew Malcomson  

* gcc.target/arm/acle/cde-errors.c: New test.
* gcc.target/arm/acle/cde.c: New test.
* lib/target-supports.exp: Update CDE flags to enable coprocessor 6.



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


diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
index 
ca36a74cd1fa161c388961588fa0f96030b7888e..83886a2fcb3844f6a5060e451125a6cd2d505c5c
 100644
--- a/gcc/config/arm/arm.h
+++ b/gcc/config/arm/arm.h
@@ -576,6 +576,9 @@ extern int arm_arch_cde;
 extern int arm_arch_cde_coproc;
 extern const int arm_arch_cde_coproc_bits[];
 #define ARM_CDE_CONST_COPROC   7
+#define ARM_CCDE_CONST_1   ((1 << 13) - 1)
+#define ARM_CCDE_CONST_2   ((1 << 9 ) - 1)
+#define ARM_CCDE_CONST_3   ((1 << 6 ) - 1)
 #define ARM_VCDE_CONST_1   ((1 << 11) - 1)
 #define ARM_VCDE_CONST_2   ((1 << 6 ) - 1)
 #define ARM_VCDE_CONST_3   ((1 << 3 ) - 1)
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 
da0bfbc35501ba40324a38ee9ebc194f43196837..be076e4ac59be7f224b769bbca4013a554b50c07
 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -25057,10 +25057,11 @@ arm_hard_regno_mode_ok (unsigned int regno, 
machine_mode mode)
   if (ARM_NUM_REGS (mode) > 4)
return false;
 
-  if (TARGET_THUMB2 && !TARGET_HAVE_MVE)
+  if (TARGET_THUMB2 && !(TARGET_HAVE_MVE || TARGET_CDE))
return true;
 
-  return !(TARGET_LDRD && GET_MODE_SIZE (mode) > 4 && (regno & 1) != 0);
+  return !((TARGET_LDRD || TARGET_CDE)
+  && GET_MODE_SIZE (mode) > 4 && (regno & 1) != 0);
 }
 
   if (regno == FRAME_POINTER_REGNUM
diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md
index 
6d5560398dae3d0ace0342b4907542d2a6865f70..9c4d66f4efe70d9ab8896865cbf45285e5cfbaf9
 100644
--- a/gcc/config/arm/arm.md
+++ b/gcc/config/arm/arm.md
@@ -4408,6 +4408,70 @@
(set_attr "shift" "3")
(set_attr "type" "logic_shift_reg")])
 


+;; Custom Datapath Extension insns.
+(define_insn "arm_cx1"
+   [(set (match_operand:SIDI 0 "s_register_operand" "=r")
+(unspec:SIDI [(match_operand:SI 1 "const_int_coproc_operand" "i")
+  (match_operand:SI 2 "const_int_ccde1_operand" "i")]
+   UNSPEC_CDE))]
+   "TARGET_CDE"
+   "cx1\\tp%c1, , %2"
+)
+
+(define_insn "arm_cx1a"
+   [(set (match_operand:SIDI 0 "s_register_operand" "=r")
+(unspec:SIDI [(match_operand:SI 1 "const_int_coproc_operand" "i")
+  (match_operand:SIDI 2 "s_register_operand" "0")
+  (match_operand:SI 3 "const_int_ccde1_operand" "i")]
+   UNSPEC_CDEA))]
+   "TARGET_CDE"
+   "cx1a\\tp%c1, , %3"
+)
+
+(define_insn "arm_cx2"
+   [(set (match_operand:SIDI 0 "s_register_operand" "=r")
+(unspec:SIDI [(match_operand:SI 1 "const_int_coproc_operand" "i")
+   

Re: [PATCH v2 00/11] aarch64: Implement TImode comparisons

[Richard Sandiford]

Richard Biener  writes:
> On Mon, Apr 6, 2020 at 1:20 PM Richard Sandiford
>  wrote:
>>
>> "Richard Earnshaw (lists)"  writes:
>> > On 03/04/2020 16:03, Richard Sandiford wrote:
>> >> "Richard Earnshaw (lists)"  writes:
>> >>> On 03/04/2020 13:27, Richard Sandiford wrote:
>>  "Richard Earnshaw (lists)"  writes:
>> > On 02/04/2020 19:53, Richard Henderson via Gcc-patches wrote:
>> >> This is attacking case 3 of PR 94174.
>> >>
>> >> In v2, I unify the various subtract-with-borrow and add-with-carry
>> >> patterns that also output flags with unspecs.  As suggested by
>> >> Richard Sandiford during review of v1.  It does seem cleaner.
>> >>
>> >
>> > Really?  I didn't need to use any unspecs for the Arm version of this.
>> >
>> > R.
>> 
>>  See https://gcc.gnu.org/pipermail/gcc-patches/2020-April/543063.html
>>  (including quoted context) for how we got here.
>> 
>>  The same problem affects the existing aarch64 patterns like
>>  *usub3_carryinC.  Although that pattern avoids unspecs,
>>  the compare:CC doesn't seem to be correct.
>> 
>>  Richard
>> 
>> >>>
>> >>> But I don't think you can use ANY_EXTEND in these comparisons.  It
>> >>> doesn't describe what the instruction does, since the instruction does
>> >>> not really extend the values first.
>> >>
>> >> Yeah, that was the starting point in the thread above too.  And using
>> >> zero_extend in the existing *usub3_carryinC pattern:
>> >>
>> >> (define_insn "*usub3_carryinC"
>> >>   [(set (reg:CC CC_REGNUM)
>> >>  (compare:CC
>> >>(zero_extend:
>> >>  (match_operand:GPI 1 "register_operand" "r"))
>> >>(plus:
>> >>  (zero_extend:
>> >>(match_operand:GPI 2 "register_operand" "r"))
>> >>  (match_operand: 3 "aarch64_borrow_operation" ""
>> >>(set (match_operand:GPI 0 "register_operand" "=r")
>> >>  (minus:GPI
>> >>(minus:GPI (match_dup 1) (match_dup 2))
>> >>(match_operand:GPI 4 "aarch64_borrow_operation" "")))]
>> >>""
>> >>"sbcs\\t%0, %1, %2"
>> >>   [(set_attr "type" "adc_reg")]
>> >> )
>> >>
>> >> looks wrong for the same reason.  But the main problem IMO isn't how the
>> >> inputs to the compare:CC are represented, but that we're using compare:CC
>> >> at all.  Using compare doesn't accurately model the effect of SBCS on NZCV
>> >> for all inputs, so if we're going to use a compare here, it can't be :CC.
>> >>
>> >>> I would really expect this patch series to be pretty much a dual of this
>> >>> series that I posted last year for Arm.
>> >>>
>> >>> https://gcc.gnu.org/pipermail/gcc-patches/2019-October/532180.html
>> >>
>> >> That series uses compares with modes like CC_V and CC_B, so I think
>> >> you're saying that given the choice in the earlier thread between adding
>> >> a new CC mode or using unspecs, you would have preferred a new CC mode,
>> >> is that right?
>> >>
>> >
>> > Yes.  It surprised me, when doing the aarch32 version, just how often
>> > the mid-end parts of the compiler were able to reason about parts of the
>> > parallel insn and optimize things accordingly (eg propagating the truth
>> > of the comparison).  If you use an unspec that can never happen.
>>
>> That could be changed though.  E.g. we could add something like a
>> simplify_unspec target hook if this becomes a problem (either here
>> or for other unspecs).  A fancy implementation could even use
>> match.pd-style rules in the .md file.
>>
>> The reason I'm not keen on using special modes for this case is that
>> they'd describe one way in which the result can be used rather than
>> describing what the instruction actually does.  The instruction really
>> does set all four flags to useful values.  The "problem" is that they're
>> not the values associated with a compare between two values, so representing
>> them that way will always lose information.
>
> Can't you recover the pieces by using a parallel with multiple
> set:CC_X that tie together the pieces in the "correct" way?

That would mean splitting apart the flags register for the set but
(I guess) continuing to treat them as a single unit for uses.  That's
likely to make life harder for the optimisers.

Thanks,
Richard

RE: [Arm] Implement CDE predicated intrinsics for MVE registers

[Kyrylo Tkachov]

Hi Matthew,

> -Original Message-
> From: Matthew Malcomson 
> Sent: 08 April 2020 09:32
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov ; Richard Earnshaw
> ; Ramana Radhakrishnan
> ; ni...@redhat.com; nd 
> Subject: [Arm] Implement CDE predicated intrinsics for MVE registers
> 
> This is an update of the previous patch but rebased onto recent MVE patches.
> https://gcc.gnu.org/pipermail/gcc-patches/2020-April/543414.html
> 
> These intrinsics are the predicated version of the intrinsics inroduced
> in https://gcc.gnu.org/pipermail/gcc-patches/2020-April/543527.html.
> 
> These are not yet public on developer.arm.com but we have reached
> internal consensus on them.
> 
> The approach follows the same method as for the CDE intrinsics for MVE
> registers, most notably using the same arm_resolve_overloaded_builtin
> function with minor modifications.
> 
> The resolver hook has been moved from arm-builtins.c to arm-c.c so it
> can access the c-common function build_function_call_vec.  This function
> is needed to perform the same checks on arguments as a normal C or C++
> function would perform.
> It is fine to put this resolver in arm-c.c since it's only use is for
> the ACLE functions, and these are only available in C/C++.
> So that the resolver function has access to information it needs from
> the builtins, we put two query functions into arm-builtins.c and use
> them from arm-c.c.
> 
> We rely on the order that the builtins are defined in
> gcc/config/arm/arm_cde_builtins.def, knowing that the predicated
> versions come after the non-predicated versions.
> 
> The machine description patterns for these builtins are simpler than
> those for the non-predicated versions, since the accumulator versions
> *and* non-accumulator versions both need an input vector now.
> The input vector is needed for the non-accumulator version to describe
> the original values for those lanes that are not updated during the
> merge operation.
> 
> We additionally need to introduce qualifiers for these new builtins,
> which follow the same pattern as the non-predicated versions but with an
> extra argument to describe the predicate.
> 
> Error message changes:
> - We directly mention the builtin argument when complaining that an
>   argument is not in the correct range.
>   This more closely matches the C error messages.
> - We ensure the resolver complains about *all* invalid arguments to a
>   function instead of just the first one.
> - The resolver error messages index arguments from 1 instead of 0 to
>   match the arguments coming from the C/C++ frontend.
> 
> In order to allow the user to give an argument for the merging predicate
> when they don't care what data is stored in the 'false' lanes, we also
> move the __arm_vuninitializedq* intrinsics from arm_mve.h to
> arm_mve_types.h which is shared with arm_cde.h.
> 
> We only move the fully type-specified `__arm_vuninitializedq*`
> intrinsics and not the polymorphic versions, since moving the
> polymorphic versions requires moving the _Generic framework as well as
> just the intrinsics we're interested in.  This matches the approach taken
> for the `__arm_vreinterpret*` functions in this include file.
> 
> This patch also contains a slight change in spacing of an existing
> assembly instruction to be emitted.
> This is just to help writing tests -- vmsr usually has a tab and a space
> between the mnemonic and the first argument, but in one case it just has
> a tab -- making all the same helps make test regexps simpler.
> 
> Testing Done:
> Bootstrap and full regtest on arm-none-linux-gnueabihf
> Full regtest on arm-none-eabi

Ok once the prerequisites have gone in.
Thanks,
Kyrill

> 
> gcc/ChangeLog:
> 
> 2020-04-08  Matthew Malcomson  
> 
>   * config/arm/arm-builtins.c (CX_UNARY_UNONE_QUALIFIERS): New.
>   (CX_BINARY_UNONE_QUALIFIERS): New.
>   (CX_TERNARY_UNONE_QUALIFIERS): New.
>   (arm_resolve_overloaded_builtin): Move to arm-c.c.
>   (arm_expand_builtin_args): Update error message.
>   (enum resolver_ident): New.
>   (arm_describe_resolver): New.
>   (arm_cde_end_args): New.
>   * config/arm/arm-builtins.h: New file.
>   * config/arm/arm-c.c (arm_resolve_overloaded_builtin): New.
>   (arm_resolve_cde_builtin): Moved from arm-builtins.c.
>   * config/arm/arm_cde.h (__arm_vcx1q_m, __arm_vcx1qa_m,
>   __arm_vcx2q_m, __arm_vcx2qa_m, __arm_vcx3q_m,
> __arm_vcx3qa_m):
>   New.
>   * config/arm/arm_cde_builtins.def (vcx1q_p_, vcx1qa_p_,
>   vcx2q_p_, vcx2qa_p_, vcx3q_p_, vcx3qa_p_): New builtin defs.
>   * config/arm/iterators.md (CDE_VCX): New int iterator.
>   (a) New int attribute.
>   * config/arm/mve.md (arm_vcx1q_p_v16qi,
> arm_vcx2q_p_v16qi,
>   arm_vcx3q_p_v16qi): New patterns.
>   * config/arm/vfp.md (thumb2_movhi_fp16): Extra space in assembly.
> 
> gcc/testsuite/ChangeLog:
> 
> 2020-04-08  Matthew Malcomson  
> 
>   * gcc.target/arm/acle/cde-errors.c: Add 

Re: [PATCH v2 00/11] aarch64: Implement TImode comparisons

[Richard Sandiford]

Segher Boessenkool  writes:
> On Mon, Apr 06, 2020 at 12:19:42PM +0100, Richard Sandiford wrote:
>> The reason I'm not keen on using special modes for this case is that
>> they'd describe one way in which the result can be used rather than
>> describing what the instruction actually does.  The instruction really
>> does set all four flags to useful values.  The "problem" is that they're
>> not the values associated with a compare between two values, so representing
>> them that way will always lose information.
>
> CC modes describe how the flags are set, not how the flags are used.
> You cannot easily describe the V bit setting with a compare (it needs
> a mode bigger than the register), is that what you mean?

I meant more that, if you want to represent the result of SBCS using
a compare, you have to decide ahead of time which result you're
interested in, and pick the CC mode and compare representation
accordingly.  E.g. SBCS res, x, y sets the Z flag if res is zero.
This is potentially useful, and could be represented as a
compare:CC_Z (say) between values based on x, y and the C flag.
SBCS res, x, y also sets the C flag if the first multiword value
(x and less significant words) is GEU the second.  This too is
potentially useful and could be represented as a compare:CC_C (say)
between values based on x, y and the C flag.  But these two compares
can't be the *same* compares, because SBCS can create a Z-set, C-clear
result that is impossible for single compares.

This is a case that the existing aarch64 pattern I mentioned gets wrong:

(define_insn "*usub3_carryinC"
  [(set (reg:CC CC_REGNUM)
(compare:CC
  (zero_extend:
(match_operand:GPI 1 "register_operand" "r"))
  (plus:
(zero_extend:
  (match_operand:GPI 2 "register_operand" "r"))
(match_operand: 3 "aarch64_borrow_operation" ""
   (set (match_operand:GPI 0 "register_operand" "=r")
(minus:GPI
  (minus:GPI (match_dup 1) (match_dup 2))
  (match_operand:GPI 4 "aarch64_borrow_operation" "")))]
   ""
   "sbcs\\t%0, %1, %2"
  [(set_attr "type" "adc_reg")]
)

(op3 == inverse of the carry flag).  When op0 == 0, op2 == -1 and op3 == 1,
the compare folds to:

  (compare:CC 0 (1 << 32))

for SI.  This compare ought to give an NE result, but the SBCS instead
sets the Z flag, giving an EQ result.

That's what I meant by the CC mode describing how the result is used.
You have to pick from a choice of several mutually-exclusive compare
representations depending on which result you want.  Sure, each
representation has to describe how the flags are set in an accurate way
(like the compare:CC_Z and compare:CC_C above are individually accurate).
But the choice of CC mode does reflect how the result is used, and can't
be made independently of how the result is used.

For SUBS you can pick the mode of the compare and the compared values
independently of how the result is used.  This seems cleaner and leads
to be better CSE opportunities, etc.  I think it'd be good to be able
to do the same for SBCS, whether that's through an unspec or (better)
a new rtx_code.

Thanks,
Richard

RE: [PATCH] [Arm] Implement scalar Custom Datapath Extension intrinsics

[Kyrylo Tkachov]

Hi Matthew,

> -Original Message-
> From: Matthew Malcomson 
> Sent: 08 April 2020 09:46
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov ; Ramana Radhakrishnan
> ; nd ;
> ni...@redhat.com; Richard Earnshaw 
> Subject: [PATCH] [Arm] Implement scalar Custom Datapath Extension
> intrinsics
> 
> Patch rebased onto recent trunk.
> 
> 
> This patch introduces the scalar CDE (Custom Datapath Extension)
> intrinsics for the arm backend.
> 
> There is nothing beyond the standard in this patch.  We simply build upon
> what
> has been done by Dennis for the vector intrinsics.
> 
> We do add `+cdecp6` to the default arguments for `target-supports.exp`, this
> allows for using coprocessor 6 in tests. This patch uses an alternate
> coprocessor to ease assembler scanning by looking for a use of coprocessor 6.
> 
> We also ensure that any DImode registers are put in an even-odd register
> pair
> when compiling for a target with CDE -- this avoids faulty code generation for
> -Os
> when producing the cx*d instructions.
> 
> Testing done:
> Bootstrapped and regtested for arm-none-linux-gnueabihf.
> 
> gcc/ChangeLog:
> 
> 2020-04-08  Matthew Malcomson  
> 
>   * config/arm/arm.c (arm_hard_regno_mode_ok): DImode registers
> forced into
>   even-odd register pairs for TARGET_CDE.
>   * config/arm/arm.h (ARM_CCDE_CONST_1): New.
>   (ARM_CCDE_CONST_2): New.
>   (ARM_CCDE_CONST_3): New.
>   * config/arm/arm.md (arm_cx1si, arm_cx1di arm_cx1asi,
> arm_cx1adi arm_cx2si,
>   arm_cx2di arm_cx2asi, arm_cx2adi arm_cx3si, arm_cx3di arm_cx3asi,
>   arm_cx3adi): New patterns.
>   * config/arm/arm_cde.h (__arm_cx1, __arm_cx1a, __arm_cx2,
> __arm_cx2a,
>   __arm_cx3, __arm_cx3a, __arm_cx1d, __arm_cx1da, __arm_cx2d,
> __arm_cx2da,
>   __arm_cx3d, __arm_cx3da): New ACLE function macros.
>   * config/arm/arm_cde_builtins.def (cx1, cx1a, cx2, cx2a, cx3, cx3a):
> Define
>   intrinsics.
>   * config/arm/iterators.md (cde_suffix, cde_dest): New mode
> attributes.
>   * config/arm/predicates.md (const_int_ccde1_operand,
>   const_int_ccde2_operand, const_int_ccde3_operand): New.
>   * config/arm/unspecs.md (UNSPEC_CDE, UNSPEC_CDEA): New.
> 
> gcc/testsuite/ChangeLog:
> 
> 2020-04-08  Matthew Malcomson  
> 
>   * gcc.target/arm/acle/cde-errors.c: New test.
>   * gcc.target/arm/acle/cde.c: New test.
>   * lib/target-supports.exp: Update CDE flags to enable coprocessor 6.
> 
> 
> 
> ### Attachment also inlined for ease of reply
> ###
> 
> 
> diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
> index
> ca36a74cd1fa161c388961588fa0f96030b7888e..83886a2fcb3844f6a5060e451
> 125a6cd2d505c5c 100644
> --- a/gcc/config/arm/arm.h
> +++ b/gcc/config/arm/arm.h
> @@ -576,6 +576,9 @@ extern int arm_arch_cde;
>  extern int arm_arch_cde_coproc;
>  extern const int arm_arch_cde_coproc_bits[];
>  #define ARM_CDE_CONST_COPROC 7
> +#define ARM_CCDE_CONST_1 ((1 << 13) - 1)
> +#define ARM_CCDE_CONST_2 ((1 << 9 ) - 1)
> +#define ARM_CCDE_CONST_3 ((1 << 6 ) - 1)
>  #define ARM_VCDE_CONST_1 ((1 << 11) - 1)
>  #define ARM_VCDE_CONST_2 ((1 << 6 ) - 1)
>  #define ARM_VCDE_CONST_3 ((1 << 3 ) - 1)
> diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
> index
> da0bfbc35501ba40324a38ee9ebc194f43196837..be076e4ac59be7f224b769b
> bca4013a554b50c07 100644
> --- a/gcc/config/arm/arm.c
> +++ b/gcc/config/arm/arm.c
> @@ -25057,10 +25057,11 @@ arm_hard_regno_mode_ok (unsigned int
> regno, machine_mode mode)
>if (ARM_NUM_REGS (mode) > 4)
>   return false;
> 
> -  if (TARGET_THUMB2 && !TARGET_HAVE_MVE)
> +  if (TARGET_THUMB2 && !(TARGET_HAVE_MVE || TARGET_CDE))
>   return true;
> 
> -  return !(TARGET_LDRD && GET_MODE_SIZE (mode) > 4 && (regno &
> 1) != 0);
> +  return !((TARGET_LDRD || TARGET_CDE)
> +&& GET_MODE_SIZE (mode) > 4 && (regno & 1) != 0);
>  }
> 
>if (regno == FRAME_POINTER_REGNUM
> diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md
> index
> 6d5560398dae3d0ace0342b4907542d2a6865f70..9c4d66f4efe70d9ab889686
> 5cbf45285e5cfbaf9 100644
> --- a/gcc/config/arm/arm.md
> +++ b/gcc/config/arm/arm.md
> @@ -4408,6 +4408,70 @@
> (set_attr "shift" "3")
> (set_attr "type" "logic_shift_reg")])
> 
> 
> 
> 
> 
> +;; Custom Datapath Extension insns.
> +(define_insn "arm_cx1"
> +   [(set (match_operand:SIDI 0 "s_register_operand" "=r")
> +  (unspec:SIDI [(match_operand:SI 1 "const_int_coproc_operand" "i")
> +(match_operand:SI 2 "const_int_ccde1_operand" "i")]
> + UNSPEC_CDE))]
> +   "TARGET_CDE"
> +   "cx1\\tp%c1, , %2"
> +)

I wonder whether we want to use the "coproc" type here as we do for the 
MVE-based ones so that we get at least some attempt at scheduling.
I think it would be better to do that rather than leave it blank. We can always 
refine it later once we get more data on implementations.
Also please format the indentation of the RTL 

Re: [PATCH] Fix use of singleton in optinfo framework

[Piotr Kubaj via Gcc-patches]

Hi,

since there has been some misunderstanding, I will explain.

There are 4 possible options here:
1. FreeBSD 12.1-RELEASE, powerpc, GCC 4.2
2. FreeBSD 13.0-CURRENT (head branch), powerpc, LLVM 10.0.0
3. FreeBSD 12.1-RELEASE, powerpc64, GCC 4.2
4. FreeBSD 13.0-CURRENT (head branch), powerpc64, LLVM 10.0.0

The patch that Gustavo provided fixes completely build issue for 1.

For 2. and 4., there's another issue with namespace collision between
LLVM and GCC, we use our own non-upstreamable patch. The ICE reported
here doesn't happen.

For 3., we currently build GCC9 using GCC8 as a bootstrap compiler and
it works fine (ICE doesn't happen). However, I'd like to get rid of the
bootstrap compiler and just build with base GCC 4.2. That's when the ICE
happens. There are also other issues, all related to GCC persistently
setting -O2, with which GCC 4.2 and stage 1 binaries compiled with -O2
just segfault. They work fine with -O0, however.

So this patch helps with building on both 32 and 64 bits using old GCC
4.2.

On 20-04-08 00:00:37, Gustavo Romero wrote:

Hi David,

On 04/06/2020 10:42 PM, David Malcolm wrote:

On Mon, 2020-04-06 at 19:44 -0400, Gustavo Romero wrote:

Thanks for this patch.

The patch looks correct, but I'm not sure that the description of the
problem is exact in every detail.  I think you've run into a bug in
code I wrote; sorry.


Thanks a lot for your quick reply and review.



which calls the singleton
dtor when the class is destroyed, freeing memory that is referenced
after
free() is called, generating an ICE error.


I introduced dump_context when adding the opt_info machinery in order
to make it more amenable to unit-testing via the selftest framework.

If I'm reading the code correctly, dump_context has no ctor, but
instead relies on the fields being zero-initialized in the BSS segment.
It has a dtor, which deletes the m_pending field.

It looks like the initializer of m_context in temp_dump_context's ctor
uses the implicitly-defined default constructor for dump_context, and
this leaves the fields uninitialized; in particular m_pending.

I *think* what's going on is that the temporary dump_context that gets
created in the "m_saved" initializer is uninitialized, and when its
dtor runs it deletes the m_pending, thus calling delete on
uninitialized memory - whatever happens to be in the stack.  I don't
see a complaint about this under valgrind though.


Yeah I think that's correct. On my wording in the commit message it says
as if the dereference of corrupted data happens after the dtor finishes,
which is wrong. Ultimately iirc even optinfo dtor can be the culprit but
as you said it might depend upon what's in the uninitialized data.
I'll fix it in v2. I also said base gcc used was 4.7, but it's actually
4.2.1, so I'll fix it for the records too. Finally, it seems that
this patch also helps 64-bit builds, accordingly to Piotr (CC:ed).



Sorry about this.  IIRC I was trying to avoid having a ctor run before
main.  If I'm reading things right there's still a dormant bug here
even with your patch.


Got it. OK, I still need to spend some time on FreeBSD not building
GCC9 on 64-bit (due to other reasons), so I'll keep an eye on it and
report back if I find something worth.


Kind regards,
Gustavo


signature.asc
Description: PGP signature

Re: [PATCH] Allow new/delete operator deletion only for replaceable.

[Richard Biener via Gcc-patches]

On Tue, Apr 7, 2020 at 5:01 PM Martin Liška  wrote:
>
> Hi.
>
> The patch allows DCE to remove only replaceable operators new and delete.
> That's achieved by proper mark up of all these operators in C++ FE.
> The patch also brings all tests we've collected so far for the PR.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?

Grepping for uses of DECL_IS_OPERATOR_* reveals you miss comparing
the new flag in ipa-icf.c and cgraph node dumping in cgraph.c might want
to dump it as well.

Otherwise it looks reasonable.

So the mid-end parts are OK in case FE people are happy with this solution
for GCC 10.

Richard.

> Thanks,
> Martin

[PATCH] [Arm] Implement scalar Custom Datapath Extension intrinsics

[Matthew Malcomson]

Patch rebased onto recent trunk.


This patch introduces the scalar CDE (Custom Datapath Extension)
intrinsics for the arm backend.

There is nothing beyond the standard in this patch.  We simply build upon what
has been done by Dennis for the vector intrinsics.

We do add `+cdecp6` to the default arguments for `target-supports.exp`, this
allows for using coprocessor 6 in tests. This patch uses an alternate
coprocessor to ease assembler scanning by looking for a use of coprocessor 6.

We also ensure that any DImode registers are put in an even-odd register pair
when compiling for a target with CDE -- this avoids faulty code generation for 
-Os
when producing the cx*d instructions.

Testing done:
Bootstrapped and regtested for arm-none-linux-gnueabihf.

gcc/ChangeLog:

2020-04-08  Matthew Malcomson  

* config/arm/arm.c (arm_hard_regno_mode_ok): DImode registers forced 
into
even-odd register pairs for TARGET_CDE.
* config/arm/arm.h (ARM_CCDE_CONST_1): New.
(ARM_CCDE_CONST_2): New.
(ARM_CCDE_CONST_3): New.
* config/arm/arm.md (arm_cx1si, arm_cx1di arm_cx1asi, arm_cx1adi 
arm_cx2si,
arm_cx2di arm_cx2asi, arm_cx2adi arm_cx3si, arm_cx3di arm_cx3asi,
arm_cx3adi): New patterns.
* config/arm/arm_cde.h (__arm_cx1, __arm_cx1a, __arm_cx2, __arm_cx2a,
__arm_cx3, __arm_cx3a, __arm_cx1d, __arm_cx1da, __arm_cx2d, __arm_cx2da,
__arm_cx3d, __arm_cx3da): New ACLE function macros.
* config/arm/arm_cde_builtins.def (cx1, cx1a, cx2, cx2a, cx3, cx3a): 
Define
intrinsics.
* config/arm/iterators.md (cde_suffix, cde_dest): New mode attributes.
* config/arm/predicates.md (const_int_ccde1_operand,
const_int_ccde2_operand, const_int_ccde3_operand): New.
* config/arm/unspecs.md (UNSPEC_CDE, UNSPEC_CDEA): New.

gcc/testsuite/ChangeLog:

2020-04-08  Matthew Malcomson  

* gcc.target/arm/acle/cde-errors.c: New test.
* gcc.target/arm/acle/cde.c: New test.
* lib/target-supports.exp: Update CDE flags to enable coprocessor 6.



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


diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
index 
ca36a74cd1fa161c388961588fa0f96030b7888e..83886a2fcb3844f6a5060e451125a6cd2d505c5c
 100644
--- a/gcc/config/arm/arm.h
+++ b/gcc/config/arm/arm.h
@@ -576,6 +576,9 @@ extern int arm_arch_cde;
 extern int arm_arch_cde_coproc;
 extern const int arm_arch_cde_coproc_bits[];
 #define ARM_CDE_CONST_COPROC   7
+#define ARM_CCDE_CONST_1   ((1 << 13) - 1)
+#define ARM_CCDE_CONST_2   ((1 << 9 ) - 1)
+#define ARM_CCDE_CONST_3   ((1 << 6 ) - 1)
 #define ARM_VCDE_CONST_1   ((1 << 11) - 1)
 #define ARM_VCDE_CONST_2   ((1 << 6 ) - 1)
 #define ARM_VCDE_CONST_3   ((1 << 3 ) - 1)
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 
da0bfbc35501ba40324a38ee9ebc194f43196837..be076e4ac59be7f224b769bbca4013a554b50c07
 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -25057,10 +25057,11 @@ arm_hard_regno_mode_ok (unsigned int regno, 
machine_mode mode)
   if (ARM_NUM_REGS (mode) > 4)
return false;
 
-  if (TARGET_THUMB2 && !TARGET_HAVE_MVE)
+  if (TARGET_THUMB2 && !(TARGET_HAVE_MVE || TARGET_CDE))
return true;
 
-  return !(TARGET_LDRD && GET_MODE_SIZE (mode) > 4 && (regno & 1) != 0);
+  return !((TARGET_LDRD || TARGET_CDE)
+  && GET_MODE_SIZE (mode) > 4 && (regno & 1) != 0);
 }
 
   if (regno == FRAME_POINTER_REGNUM
diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md
index 
6d5560398dae3d0ace0342b4907542d2a6865f70..9c4d66f4efe70d9ab8896865cbf45285e5cfbaf9
 100644
--- a/gcc/config/arm/arm.md
+++ b/gcc/config/arm/arm.md
@@ -4408,6 +4408,70 @@
(set_attr "shift" "3")
(set_attr "type" "logic_shift_reg")])
 


+;; Custom Datapath Extension insns.
+(define_insn "arm_cx1"
+   [(set (match_operand:SIDI 0 "s_register_operand" "=r")
+(unspec:SIDI [(match_operand:SI 1 "const_int_coproc_operand" "i")
+  (match_operand:SI 2 "const_int_ccde1_operand" "i")]
+   UNSPEC_CDE))]
+   "TARGET_CDE"
+   "cx1\\tp%c1, , %2"
+)
+
+(define_insn "arm_cx1a"
+   [(set (match_operand:SIDI 0 "s_register_operand" "=r")
+(unspec:SIDI [(match_operand:SI 1 "const_int_coproc_operand" "i")
+  (match_operand:SIDI 2 "s_register_operand" "0")
+  (match_operand:SI 3 "const_int_ccde1_operand" "i")]
+   UNSPEC_CDEA))]
+   "TARGET_CDE"
+   "cx1a\\tp%c1, , %3"
+)
+
+(define_insn "arm_cx2"
+   [(set (match_operand:SIDI 0 "s_register_operand" "=r")
+(unspec:SIDI [(match_operand:SI 1 "const_int_coproc_operand" "i")
+  (match_operand:SI 2 "s_register_operand" "r")
+  (match_operand:SI 3 "const_int_ccde2_operand" "i")]
+   UNSPEC_CDE))]
+   "TARGET_CDE"
+   "cx2\\tp%c1, , %2, %3"
+)
+
+(define_insn "arm_cx2a"
+   [(set 

[Arm] Implement CDE predicated intrinsics for MVE registers

[Matthew Malcomson]

This is an update of the previous patch but rebased onto recent MVE patches.
https://gcc.gnu.org/pipermail/gcc-patches/2020-April/543414.html

These intrinsics are the predicated version of the intrinsics inroduced
in https://gcc.gnu.org/pipermail/gcc-patches/2020-April/543527.html.

These are not yet public on developer.arm.com but we have reached
internal consensus on them.

The approach follows the same method as for the CDE intrinsics for MVE
registers, most notably using the same arm_resolve_overloaded_builtin
function with minor modifications.

The resolver hook has been moved from arm-builtins.c to arm-c.c so it
can access the c-common function build_function_call_vec.  This function
is needed to perform the same checks on arguments as a normal C or C++
function would perform.
It is fine to put this resolver in arm-c.c since it's only use is for
the ACLE functions, and these are only available in C/C++.
So that the resolver function has access to information it needs from
the builtins, we put two query functions into arm-builtins.c and use
them from arm-c.c.

We rely on the order that the builtins are defined in
gcc/config/arm/arm_cde_builtins.def, knowing that the predicated
versions come after the non-predicated versions.

The machine description patterns for these builtins are simpler than
those for the non-predicated versions, since the accumulator versions
*and* non-accumulator versions both need an input vector now.
The input vector is needed for the non-accumulator version to describe
the original values for those lanes that are not updated during the
merge operation.

We additionally need to introduce qualifiers for these new builtins,
which follow the same pattern as the non-predicated versions but with an
extra argument to describe the predicate.

Error message changes:
- We directly mention the builtin argument when complaining that an
  argument is not in the correct range.
  This more closely matches the C error messages.
- We ensure the resolver complains about *all* invalid arguments to a
  function instead of just the first one.
- The resolver error messages index arguments from 1 instead of 0 to
  match the arguments coming from the C/C++ frontend.

In order to allow the user to give an argument for the merging predicate
when they don't care what data is stored in the 'false' lanes, we also
move the __arm_vuninitializedq* intrinsics from arm_mve.h to
arm_mve_types.h which is shared with arm_cde.h.

We only move the fully type-specified `__arm_vuninitializedq*`
intrinsics and not the polymorphic versions, since moving the
polymorphic versions requires moving the _Generic framework as well as
just the intrinsics we're interested in.  This matches the approach taken
for the `__arm_vreinterpret*` functions in this include file.

This patch also contains a slight change in spacing of an existing
assembly instruction to be emitted.
This is just to help writing tests -- vmsr usually has a tab and a space
between the mnemonic and the first argument, but in one case it just has
a tab -- making all the same helps make test regexps simpler.

Testing Done:
Bootstrap and full regtest on arm-none-linux-gnueabihf
Full regtest on arm-none-eabi

gcc/ChangeLog:

2020-04-08  Matthew Malcomson  

* config/arm/arm-builtins.c (CX_UNARY_UNONE_QUALIFIERS): New.
(CX_BINARY_UNONE_QUALIFIERS): New.
(CX_TERNARY_UNONE_QUALIFIERS): New.
(arm_resolve_overloaded_builtin): Move to arm-c.c.
(arm_expand_builtin_args): Update error message.
(enum resolver_ident): New.
(arm_describe_resolver): New.
(arm_cde_end_args): New.
* config/arm/arm-builtins.h: New file.
* config/arm/arm-c.c (arm_resolve_overloaded_builtin): New.
(arm_resolve_cde_builtin): Moved from arm-builtins.c.
* config/arm/arm_cde.h (__arm_vcx1q_m, __arm_vcx1qa_m,
__arm_vcx2q_m, __arm_vcx2qa_m, __arm_vcx3q_m, __arm_vcx3qa_m):
New.
* config/arm/arm_cde_builtins.def (vcx1q_p_, vcx1qa_p_,
vcx2q_p_, vcx2qa_p_, vcx3q_p_, vcx3qa_p_): New builtin defs.
* config/arm/iterators.md (CDE_VCX): New int iterator.
(a) New int attribute.
* config/arm/mve.md (arm_vcx1q_p_v16qi, arm_vcx2q_p_v16qi,
arm_vcx3q_p_v16qi): New patterns.
* config/arm/vfp.md (thumb2_movhi_fp16): Extra space in assembly.

gcc/testsuite/ChangeLog:

2020-04-08  Matthew Malcomson  

* gcc.target/arm/acle/cde-errors.c: Add predicated forms.
* gcc.target/arm/acle/cde-mve-error-1.c: Add predicated forms.
* gcc.target/arm/acle/cde-mve-error-2.c: Add predicated forms.
* gcc.target/arm/acle/cde-mve-error-3.c: Add predicated forms.
* gcc.target/arm/acle/cde-mve-full-assembly.c: Add predicated
forms.
* gcc.target/arm/acle/cde-mve-tests.c: Add predicated forms.
* gcc.target/arm/acle/cde_v_1_err.c (test_imm_range): Update for
error message format change.
* 

Re: [PATCH, testsuite] Fix PR94079 by respecting vect_hw_misalign

[Richard Biener via Gcc-patches]

On Wed, Apr 8, 2020 at 10:17 AM Kewen.Lin via Gcc-patches
 wrote:
>
> Hi,
>
> This is another vect case which requires special handling with
> vect_hw_misalign.  The alignment of the second part requires
> misaligned vector access supports.  This patch is to adjust
> the related guard condition and comments.
>
> Verified it on ppc64-redhat-linux (Power7 BE).
>
> Is it ok for trunk?

OK.

> BR,
> Kewen
> 
>
> gcc/testsuite/ChangeLog
>
> 2020-04-08  Kewen Lin  
>
> PR testsuite/94023
> * gfortran.dg/vect/pr83232.f90: Expect 2 rather than 3 times SLP on
> non-vect_hw_misalign targets.
>
> diff --git a/gcc/testsuite/gfortran.dg/vect/pr83232.f90 
> b/gcc/testsuite/gfortran.dg/vect/pr83232.f90
> index a353578..af88342 100644
> --- a/gcc/testsuite/gfortran.dg/vect/pr83232.f90
> +++ b/gcc/testsuite/gfortran.dg/vect/pr83232.f90
> @@ -27,5 +27,7 @@
>call foo (Einc)
>END SUBROUTINE
>
> -! We should vectorize (1), (2) and (3)
> -! { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 3 "slp1" } 
> }
> +! We should vectorize (1), (2) and (3) under vect_hw_misalign.
> +! { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 3 "slp1" { 
> target vect_hw_misalign } } }
> +! But only (1) and (3) under !vect_hw_misalign due to the alignment of (2).
> +! { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 2 "slp1" { 
> target { ! vect_hw_misalign } } } }
>

[Arm] Implement CDE intrinsics for MVE registers.

[Matthew Malcomson]

This patch updates the previous one by rebasing onto the recent MVE patches on
trunk.

Implement CDE intrinsics on MVE registers.

Other than the basics required for adding intrinsics this patch consists
of three changes.

** We separate out the MVE types and casts from the arm_mve.h header.

This is so that the types can be used in arm_cde.h without the need to include
the entire arm_mve.h header.
The only type that arm_cde.h needs is `uint8x16_t`, so this separation could be
avoided by using a `typedef` in this file.
Since the introduced intrinsics are all defined to act on the full range of MVE
types, declaring all such types seems intuitive since it will provide their
declaration to the user too.

This arm_mve_types.h header not only includes the MVE types, but also
the conversion intrinsics between them.
Some of the conversion intrinsics are needed for arm_cde.h, but most are
not.  We include all conversion intrinsics to keep the definition of
such conversion functions all in one place, on the understanding that
extra conversion functions being defined when including `arm_cde.h` is
not a problem.

** We define the TARGET_RESOLVE_OVERLOADED_BUILTIN hook for the Arm backend.

This is needed to implement the polymorphism for the required intrinsics.
The intrinsics have no specialised version, and the resulting assembly
instruction for all different types should be exactly the same.
Due to this we have implemented these intrinsics via one builtin on one type.
All other calls to the intrinsic with different types are implicitly cast to
the one type that is defined, and hence are all expanded to the same RTL
pattern that is only defined for one machine mode.

** We seperate the initialisation of the CDE intrinsics from others.

This allows us to ensure that the CDE intrinsics acting on MVE registers
are only created when both CDE and MVE are available.
Only initialising these builtins when both features are available is
especially important since they require a type that is only initialised
when the target supports hard float.  Hence trying to initialise these
builtins on a soft float target would cause an ICE.

Testing done:
  Full bootstrap and regtest on arm-none-linux-gnueabihf
  Regression test on arm-none-eabi


NOTE: This patch depends on the CDE intrinsic framework patch by Dennis.
https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542008.html


Ok for trunk?

gcc/ChangeLog:

2020-04-08  Matthew Malcomson  

* config.gcc (arm_mve_types.h): New extra_header for arm.
* config/arm/arm-builtins.c (arm_resolve_overloaded_builtin): New.
(arm_init_cde_builtins): New.
(arm_init_acle_builtins): Remove initialisation of CDE builtins.
(arm_init_builtins): Call arm_init_cde_builtins when target
supports CDE.
* config/arm/arm-c.c (arm_resolve_overloaded_builtin): New declaration.
(arm_register_target_pragmas): Initialise resolve_overloaded_builtin
hook to the implementation for the arm backend.
* config/arm/arm.h (ARM_MVE_CDE_CONST_1): New.
(ARM_MVE_CDE_CONST_2): New.
(ARM_MVE_CDE_CONST_3): New.
* config/arm/arm_cde.h (__arm_vcx1q_u8): New.
(__arm_vcx1qa): New.
(__arm_vcx2q): New.
(__arm_vcx2q_u8): New.
(__arm_vcx2qa): New.
(__arm_vcx3q): New.
(__arm_vcx3q_u8): New.
(__arm_vcx3qa): New.
* config/arm/arm_cde_builtins.def (vcx1q, vcx1qa, vcx2q, vcx2qa, vcx3q,
vcx3qa): New builtins defined.
* config/arm/arm_mve.h: Move typedefs and conversion intrinsics
to arm_mve_types.h header.
* config/arm/arm_mve_types.h: New file.
* config/arm/mve.md (arm_vcx1qv16qi, arm_vcx1qav16qi, arm_vcx2qv16qi,
arm_vcx2qav16qi, arm_vcx3qv16qi, arm_vcx3qav16qi): New patterns.
* config/arm/predicates.md (const_int_mve_cde1_operand,
const_int_mve_cde2_operand, const_int_mve_cde3_operand): New.

gcc/testsuite/ChangeLog:

2020-04-08  Matthew Malcomson  
Dennis Zhang  

* gcc.target/arm/acle/cde-mve-error-1.c: New test.
* gcc.target/arm/acle/cde-mve-error-2.c: New test.
* gcc.target/arm/acle/cde-mve-error-3.c: New test.
* gcc.target/arm/acle/cde-mve-full-assembly.c: New test.
* gcc.target/arm/acle/cde-mve-tests.c: New test.
* lib/target-supports.exp (arm_v8_1m_main_cde_mve_fp): New check
effective.


cde-mve-intrinsics.patch.gz
Description: application/gzip

Re: [PATCH] sra: Fix sra_modify_expr handling of partial writes (PR 94482)

[Richard Biener]

On Tue, 7 Apr 2020, Richard Biener wrote:

> On April 7, 2020 6:25:26 PM GMT+02:00, Martin Jambor  wrote:
> >Hi,
> >
> >On Tue, Apr 07 2020, Richard Biener wrote:
> >> On Tue, 7 Apr 2020, Martin Jambor wrote:
> >>
> >>> Hi,
> >>> 
> >>> when sra_modify_expr is invoked on an expression that modifies only
> >>> part of the underlying replacement, such as a BIT_FIELD_REF on a LHS
> >>> of an assignment and the SRA replacement's type is not compatible
> >with
> >>> what is being replaced (0th operand of the B_F_R in the above
> >>> example), it does not work properly, basically throwing away the
> >partd
> >>> of the expr that should have stayed intact.
> >>> 
> >>> This is fixed in two ways.  For BIT_FIELD_REFs, which operate on the
> >>> binary image of the replacement (and so in a way serve as a
> >>> VIEW_CONVERT_EXPR) we just do not bother with convertsing.  For
> >>> REALPART_EXPRs and IMAGPART_EXPRs, we insert a VIEW_CONVERT_EXPR
> >under
> >>> the complex partial access expression, which is OK even in a LHS of
> >an
> >>> assignment (and other write contexts) because in those cases the
> >>> replacement is not going to be a giple register anyway.
> >>> 
> >>> The testcase for handling REALPART_EXPR and IMAGPART_EXPR is a bit
> >>> fragile because SRA prefers complex and vector types over anything
> >else
> >>> (and in between the two it decides based on TYPE_UID which in my
> >testing
> >>> today always preferred complex types) and even when GIMPLE is wrong
> >I
> >>> often still did not get failing runs, so I only run it at -O1 (which
> >is
> >>> the only level where the the test fails for me).
> >>> 
> >>> Bootstrapped and tested on x86_64-linux, bootstrap and testing on
> >>> i686-linux and aarch64-linux underway.
> >>> 
> >>> OK for trunk (and subsequently for release branches) if it passes?
> >>
> >> OK.
> >
> >I must have been already half asleep when writing that it passed
> >testing.  It did not, testsuite/gcc.c-torture/compile/pr42196-3.c fails
> >even on x86_64, because fwprop happily combines
> >
> >  u$ci_10 = MEM[(union U *)];
> >
> >and
> >
> >  f1_6 = IMAGPART_EXPR (u$ci_10)>;
> >
> >into
> >
> >  f1_6 = IMAGPART_EXPR ;
> >
> >and the gimple verifier of course does not like that.  I'll have a look
> >at that tomorrow.
> 
> Ah, that might be a genuine fwprop bug. 

On a second thought

  f1_6 = IMAGPART_EXPR (u$ci_10)>;

shouldn't be valid GIMPLE since 'complex float' is a register type
and thus it should have been

  _11 = VIEW_CONVERT_EXPR(u$ci_10);
  f1_6 = IMAGPART_EXPR <_11>;

now it's a bit of a grey area since a load like

  f1_6 = IMAGPART_EXPR (u);

is valid (we don't want to force a whole _Complex load here).

For example in VN

  f1_6 = IMAGPART_EXPR (u$ci_10)>;

goes through the load machinery.

So let's say the IL is undesirable at least.

The following fixes the forwprop laziness, please include it in the
patch so it gets cherry-picked for backports.

Thanks,
Richard.

>From 29348ec5efbbc0430714a2929c6b44d174f78533 Mon Sep 17 00:00:00 2001
From: Richard Biener 
Date: Wed, 8 Apr 2020 10:23:35 +0200
Subject: [PATCH] Properly verify forwprop merging into REAL/IMAGPART and
 BIT_FIELD_REF
To: gcc-patches@gcc.gnu.org

2020-04-08  Richard Biener  

* tree-ssa-forwprop.c (pass_forwprop::execute): Properly
verify the first operand of combinations into REAL/IMAGPART_EXPR
and BIT_FIELD_REF.
---
 gcc/tree-ssa-forwprop.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/gcc/tree-ssa-forwprop.c b/gcc/tree-ssa-forwprop.c
index e7eaa18ccad..3d8acf7eb03 100644
--- a/gcc/tree-ssa-forwprop.c
+++ b/gcc/tree-ssa-forwprop.c
@@ -2815,7 +2815,8 @@ pass_forwprop::execute (function *fun)
continue;
  if (!is_gimple_assign (use_stmt)
  || (gimple_assign_rhs_code (use_stmt) != REALPART_EXPR
- && gimple_assign_rhs_code (use_stmt) != 
IMAGPART_EXPR))
+ && gimple_assign_rhs_code (use_stmt) != IMAGPART_EXPR)
+ || TREE_OPERAND (gimple_assign_rhs1 (use_stmt), 0) != lhs)
{
  rewrite = false;
  break;
@@ -2877,7 +2878,8 @@ pass_forwprop::execute (function *fun)
  if (is_gimple_debug (use_stmt))
continue;
  if (!is_gimple_assign (use_stmt)
- || gimple_assign_rhs_code (use_stmt) != BIT_FIELD_REF)
+ || gimple_assign_rhs_code (use_stmt) != BIT_FIELD_REF
+ || TREE_OPERAND (gimple_assign_rhs1 (use_stmt), 0) != lhs)
{
  rewrite = false;
  break;
-- 
2.16.4

[PATCH, testsuite] Fix PR94079 by respecting vect_hw_misalign

[Kewen.Lin via Gcc-patches]

Hi,

This is another vect case which requires special handling with
vect_hw_misalign.  The alignment of the second part requires
misaligned vector access supports.  This patch is to adjust
the related guard condition and comments.

Verified it on ppc64-redhat-linux (Power7 BE).

Is it ok for trunk?

BR,
Kewen


gcc/testsuite/ChangeLog

2020-04-08  Kewen Lin  

PR testsuite/94023
* gfortran.dg/vect/pr83232.f90: Expect 2 rather than 3 times SLP on
non-vect_hw_misalign targets.

diff --git a/gcc/testsuite/gfortran.dg/vect/pr83232.f90 
b/gcc/testsuite/gfortran.dg/vect/pr83232.f90
index a353578..af88342 100644
--- a/gcc/testsuite/gfortran.dg/vect/pr83232.f90
+++ b/gcc/testsuite/gfortran.dg/vect/pr83232.f90
@@ -27,5 +27,7 @@
   call foo (Einc)
   END SUBROUTINE

-! We should vectorize (1), (2) and (3)
-! { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 3 "slp1" } }
+! We should vectorize (1), (2) and (3) under vect_hw_misalign.
+! { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 3 "slp1" { 
target vect_hw_misalign } } }
+! But only (1) and (3) under !vect_hw_misalign due to the alignment of (2).
+! { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 2 "slp1" { 
target { ! vect_hw_misalign } } } }

Re: [PATCH, libphobos] Fix compilation dependencies on s390x-linux-musl

[Iain Buclaw via Gcc-patches]

On 28/01/2020 05:00, Mathias Lang wrote:
> Hi,
> 
> This patch fixes GDC on s390x-linux-musl targets. It was specifically
> tested under Alpine Linux (see
> https://gitlab.alpinelinux.org/alpine/aports/commit/c123e0f14ab73976a36c651d47d134f249413f29
> ).
> The patch fixes two issues: First, Musl always provide
> `__tls_get_addr`, so we can always use it to get the TLS range instead
> of the internal function (which is glibc-specific).
> Second, druntime provide an ASM implementation for
> `fiber_switchContext` for most platform under
> libphobos/libdruntime/config/$ARCH/switchcontext.S, and default to
> `swapcontext` when not available, which is the case on s390x.
> However, the configure script did not depend on `swapcontext` being
> present, as it's part of glibc, but not Musl (there is a libucontext
> available on Alpine for this), which is added here.
> 
> @Iain: Any chance those could be backported to v9 ?
> 

Thanks, I see no reason not to backport.


> ---
> Mathias Lang
> ---
> libphobos/ChangeLog:
> 
> * libdruntime/gcc/sections/elf_shared.d Always use
> __tls_get_addr on Musl.
> * configure.ac: Search librairies for swapcontext when
> LIBDRUNTIME_NEEDS_UCONTEXT is yes.
> * configure.tgt: Set LIBDRUNTIME_NEEDS_UCONTEXT on s390*-linux*.
> * configure: Regenerate.
> ---
> diff -Nurp a/libphobos/libdruntime/gcc/sections/elf_shared.d
> b/libphobos/libdruntime/gcc/sections/elf_shared.d
> --- a/libphobos/libdruntime/gcc/sections/elf_shared.d
> +++ b/libphobos/libdruntime/gcc/sections/elf_shared.d
> @@ -1084,7 +1084,9 @@ void[] getTLSRange(size_t mod, size_t sz) nothrow @nogc
> 
>  // base offset
>  auto ti = tls_index(mod, 0);
> -version (IBMZ_Any)
> +version (CRuntime_Musl)
> +return (__tls_get_addr()-TLS_DTV_OFFSET)[0 .. sz];
> +else version (IBMZ_Any)
>  {
>  auto idx = cast(void *)__tls_get_addr_internal()
>  + cast(ulong)__builtin_thread_pointer();

This is fine.

> diff -Nurp a/libphobos/configure.ac b/libphobos/configure.ac
> --- a/libphobos/configure.ac
> +++ b/libphobos/configure.ac
> @@ -140,6 +140,14 @@ case ${host} in
>  esac
>  AC_MSG_RESULT($LIBPHOBOS_SUPPORTED)
> 
> +AC_MSG_CHECKING([if target needs to link in swapcontext])
> +AC_MSG_RESULT($LIBDRUNTIME_NEEDS_UCONTEXT)
> +AS_IF([test "x$LIBDRUNTIME_NEEDS_UCONTEXT" = xyes], [
> +   AC_SEARCH_LIBS([swapcontext], [c ucontext], [], [
> +   AC_MSG_ERROR([[can't find library providing swapcontext]])
> +  ])
> +])
> +

Rather than adding LIBDRUNTIME_NEEDS_UCONTEXT, couldn't you just add a 
one-liner AC_SEARCH_LIBS to the WITH_LOCAL_DRUNTIME list?

Testing as I suggest locally, there is no problems on x86 and x86_64.

Iain.

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

[Jonathan Wakely via Gcc-patches]

On Wed, 8 Apr 2020 at 08:35, Richard Biener wrote:
> Ah, so __builtin_operator_new isn't a function but an alternate
> new expression syntax?

No, not a new-expression, because a new-expression calls operator new
to obtain storage *and* begins the lifetime of one or more objects in
that storage. __builtin_operator_new is just the first part, i.e. the
operator new(...) call. But because explicit calls to operator
new(...) are not supposed to be optimized, __builtin_operator_new is a
way of calling operator new(...) that tells the compiler "this isn't
an explicit call, you can optimise it". So a new-expression can use it
(because that needs to call operator new(...), but the call should be
optimisable) and std::allocator::allocate(n) can use it (because
that call is also optimisable).

Re: [C/C++, OpenACC] Reject vars of different scope in acc declare (PR94120)

[Tobias Burnus]

I have now committed this patch
as r10-7614-g13e41d8b9d3d7598c72c38acc86a3d97046c8373,
reading "so we shall accept it" as approval …

On 4/1/20 9:07 AM, Thomas Schwinge wrote:


Even if the ICE is then fixed, should we still keep
 open (with a note) until
 is
resolved/published?


I decided to close it and mention the namelist issue and
the now-fixed PR in PR84140 (which is about (non)static
class member variables, which is also covered in Issue 288).


Regarding the C/C++ patch you posted: I'm not at all familiar with the
front ends' scoping implementation.  But, given that your patch really
only touches the OpenACC 'declare' code paths, it can't cause any harm
otherwise, so we shall accept it.  Maybe Jakub has any comments, though?



+c_check_oacc_same_scope (tree decl)

Is the function really specific to OpenACC? If not, then "_oacc"
could be dropped from its name. How about "c_check_current_scope"?

Yeah, that may be a good idea.  Similar constructs seem to be used in a
few other places, though without the 'DECL_NAME' indirection.


I now use c_check_in_current_scope.

Tobias
-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter

Re: [RFC, Instruction Scheduler, Stage1] New hook/code to perform fusion of dependent instructions

[Richard Biener via Gcc-patches]

On Tue, Apr 7, 2020 at 10:45 PM Pat Haugen via Gcc-patches
 wrote:
>
> The Power processor has the ability to fuse certain pairs of dependent
> instructions to improve their performance if they appear back-to-back in
> the instruction stream. In looking at the current support for
> instruction fusion in GCC I saw the following 2 options.
>
> 1) TARGET_SCHED_MACRO_FUSION target hooks: Only looks at existing
> back-to-back instructions and will ensure the scheduler keeps them together.

The i386 backend uses this for compare + branch fusion.

> 2) -fsched-fusion/TARGET_SCHED_FUSION_PRIORITY: Runs as a separate
> scheduling pass before peephole2. Operates independently on a single
> insn. Used by ARM backend to assign higher priorities to base/disp loads
> and stores so that the scheduling pass will schedule loads/stores to
> adjacent memory back-to-back. Later these insns will be transformed into
> load/store pair insns.
>
> Neither of these work for Power's purpose because they don't deal with
> fusion of dependent insns that may not already be back-to-back. The
> TARGET_SCHED_REORDER[2] hooks also don't work since the dependent insn
> more than likely gets queued for N cycles so wouldn't be on the ready
> list for the reorder hooks to process. We want the ability for the
> scheduler to schedule dependent insn pairs back-to-back when possible
> (i.e. other dependencies of both insns have been satisfied).
>
> I have coded up a proof of concept that implements our needs via a new
> target hook. The hook is passed a pair of dependent insns and returns if
> they are a fusion candidate. It is called while removing the forward
> dependencies of the just scheduled insn. If a dependent insn becomes
> available to schedule and it's a fusion candidate with the just
> scheduled insn, then the new code moves it to the ready list (if
> necessary) and marks it as SCHED_GROUP (piggy-backing on the existing
> code used by TARGET_SCHED_MACRO_FUSION) to make sure the fusion
> candidate will be scheduled next. Following is the scheduling part of
> the diff. Does this sound like a feasible approach? I welcome any
> comments/discussion.

It would be nice test if the i386 use of TARGET_SCHED_MACRO_FUSION hooks
for compare + branch fusion can be transitioned to that scheme.  I think your
proposal doesn't improve things there since we can never schedule
branches earlier
but we could schedule the compare later.  But your proposal only
affects scheduling
of later insns, not the order of insns getting onto the ready list?

Richard.

> Thanks,
> Pat
>
>
> diff --git a/gcc/haifa-sched.c b/gcc/haifa-sched.c
> index 80687fb5359..7a62136d497 100644
> --- a/gcc/haifa-sched.c
> +++ b/gcc/haifa-sched.c
> @@ -4152,6 +4152,39 @@ schedule_insn (rtx_insn *insn)
>   && SCHED_GROUP_P (next)
>   && advance < effective_cost)
> advance = effective_cost;
> +
> + /* If all dependencies of this insn have now been resolved and the
> +just scheduled insn was not part of a SCHED_GROUP, check if
> +this dependent insn can be fused with the just scheduled insn.  
> */
> + else if (effective_cost >= 0 && !SCHED_GROUP_P (insn)
> +  && targetm.sched.dep_fusion
> +  && targetm.sched.dep_fusion (insn, next))
> +   {
> + /* Move to ready list if necessary.  */
> + if (effective_cost > 0)
> +   {
> + queue_remove (next);
> + ready_add (, next, true);
> +   }
> +
> + /* Mark as sched_group.  */
> + SCHED_GROUP_P (next) = 1;
> +
> + /* Fix insn_tick.  */
> + INSN_TICK (next) = INSN_TICK (insn);
> +
> + /* Dump some debug output for success.  */
> + if (sched_verbose >= 5)
> +   {
> + fprintf (sched_dump, ";;\t\tFusing dependent insns: ");
> + fprintf (sched_dump, "%4d %-30s --> ", INSN_UID (insn),
> +  str_pattern_slim (PATTERN (insn)));
> + fprintf (sched_dump, "%4d %-30s\n", INSN_UID (next),
> +  str_pattern_slim (PATTERN (next)));
> +   }
> +   }
> }
>else
> /* Check always has only one forward dependence (to the first insn in

Re: [PING PATCH coroutines] Do not strip cleanup_point when promote temporaries out of current stmt

[Bin.Cheng via Gcc-patches]

On Tue, Apr 7, 2020 at 11:45 PM Iain Sandoe  wrote:
>
> Bin.Cheng  wrote:
>
> > On Mon, Mar 16, 2020 at 5:34 PM Bin.Cheng  wrote:
> >> On Wed, Mar 11, 2020 at 5:07 PM Iain Sandoe  wrote:
> >>> Bin.Cheng  wrote:
> >>>
>  On Thu, Mar 5, 2020 at 10:18 PM Iain Sandoe  wrote:
>
> >>> If it helps, I could push a branch to users/iains/ on the FSF git server 
> >>> with this sequence.
> >> Sorry for being slow replying.  This is weird, were you testing against 
> >> trunk?
>
> 1/ @Jun Ma
>
>   - I think your observation is correct, we should enusre that cleanups are 
> applied where needed
>to any temps that remain after we’ve those captured by reference.
>
>   However, I would prefer that we do this as required, rather than assuming 
> it will be needed so
>   I have an updated patch below.
Sorry it's been quite long, I don't remember the detail of this
change.  Since this new version fixes the ICE too, please go ahead
commit it.
>
> 2/ @ Bin / Jun Ma
>
>   - The problem is that the testcase seems to be fragile, perhaps it was a 
> c-reduced one?
It's strange, however, I don't see being c-reduced has impact here in
this scenario.
>
> So… I do not propose to add this test-case at this point (perhaps we could 
> construct one that actually
> tests the required behaviour - that cleanups are still  run correctly for 
> temps that are not promoted by
> capture)?
>
> Anyway to avoid further delay, I think we should apply the patch below (I 
> have other fixes on top of this
> for open PRs)
>
> OK for master?
Yes, please.  Also one of approved patch is waiting for this one.

Thanks,
bin
> thanks
> Iain
>
> coroutines: Add cleanups, where required, to statements with captured 
> references.
>
> When we promote captured temporaries to local variables, we also
> remove their initializers from the relevant call expression.  This
> means that we should recompute the need for a cleanup expression
> once the set of temporaries that remains becomes known.
>
> gcc/cp/ChangeLog:
>
> 2020-04-07  Iain Sandoe  
> Jun Ma  
>
> * coroutines.cc (maybe_promote_captured_temps): Add a
> cleanup expression, if needed, to any call from which
> we promoted temporaries captured by reference.
>
> diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
> index 983fa650b55..936be06c336 100644
> --- a/gcc/cp/coroutines.cc
> +++ b/gcc/cp/coroutines.cc
> @@ -2798,11 +2798,13 @@ maybe_promote_captured_temps (tree *stmt, void *d)
>location_t sloc = EXPR_LOCATION (*stmt);
>tree aw_bind
> = build3_loc (sloc, BIND_EXPR, void_type_node, NULL, NULL, NULL);
> -  tree aw_statement_current;
> -  if (TREE_CODE (*stmt) == CLEANUP_POINT_EXPR)
> -   aw_statement_current = TREE_OPERAND (*stmt, 0);
> -  else
> -   aw_statement_current = *stmt;
> +
> +  /* Any cleanup point expression might no longer be necessary, since we
> +are removing one or more temporaries.  */
> +  tree aw_statement_current = *stmt;
> +  if (TREE_CODE (aw_statement_current) == CLEANUP_POINT_EXPR)
> +   aw_statement_current = TREE_OPERAND (aw_statement_current, 0);
> +
>/* Collected the scope vars we need move the temps to regular. */
>tree aw_bind_body = push_stmt_list ();
>tree varlist = NULL_TREE;
> @@ -2843,8 +2845,12 @@ maybe_promote_captured_temps (tree *stmt, void *d)
>   /* Replace all instances of that temp in the original expr.  */
>   cp_walk_tree (_statement_current, replace_proxy, , NULL);
> }
> -  /* What's left should be the original statement with any temporaries
> -broken out.  */
> +
> +  /* What's left should be the original statement with any co_await
> +captured temporaries broken out.  Other temporaries might remain
> +so see if we need to wrap the revised statement in a cleanup.  */
> +  aw_statement_current =
> +   maybe_cleanup_point_expr_void (aw_statement_current);
>add_stmt (aw_statement_current);
>BIND_EXPR_BODY (aw_bind) = pop_stmt_list (aw_bind_body);
>awpts->captured_temps.empty ();
>

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

[Richard Biener via Gcc-patches]

On Tue, Apr 7, 2020 at 5:17 PM Jonathan Wakely  wrote:
>
> On Tue, 7 Apr 2020 at 12:57, Richard Biener  
> wrote:
> >
> > On Tue, Apr 7, 2020 at 1:46 PM Jonathan Wakely  
> > wrote:
> > >
> > > On Tue, 7 Apr 2020 at 12:40, Richard Biener  
> > > wrote:
> > > >
> > > > On Tue, Apr 7, 2020 at 1:30 PM Jonathan Wakely  
> > > > wrote:
> > > > >
> > > > > On Mon, 6 Apr 2020 at 13:45, Nathan Sidwell wrote:
> > > > > > The both operator new and operator delete are looked up in the same
> > > > > > manner.  The std does not require a 'matching pair' be found.  but 
> > > > > > it is
> > > > > > extremely poor form for a class to declare exactly one of operator
> > > > > > {new,delete}.
> > > > >
> > > > > There are unfortunately several such example in the standard!
> > > > >
> > > > > I wonder how much benefit we will really get from trying to make this
> > > > > optimisation too general.
> > > > >
> > > > > Just eliding (or coalescing) implicit calls to ::operator new(size_t)
> > > > > and ::operator delete(void*, size_t) (and the [] and align_val_t forms
> > > > > of those) probably covers 99% of real cases.
> > > >
> > > > IIRC the only reason to have the optimization was to fully elide
> > > > STL containers when possible.  That brings in allocators and
> > > > thus non ::new/::delete allocations.
> > >
> > > But the vast majority of containers are used with std::allocator, and
> > > we control that.
> > >
> > > Wouldn't it be simpler to add __builtin_operator_new and
> > > __builtin_operator_delete like clang has, then make std::allocator use
> > > those, and limit the optimizations to uses of those built-ins?
> >
> > Sure, that's a viable implementation strathegy.  Another might be
> >
> > void delete (void *) __attribute__((matching_new(somewhere::new)));
> >
> > and thus allow the user to relate a new/delete pair (here the FE would
> > do lookup for 'new' and record for example the mangled assembler name).
>
> Does that attribute tell us anything useful?
>
> Given a pointer obtained from new and passed to delete, can't we
> assume they are a matching pair? If not, the behaviour would be
> undefined anyway.

Further matching of new/delete came up in the context of inlining where
we might not be able to elide side-effects of new/delete "appropriately".
That's actually the case in the referenced PR.

> > That is, we usually try to design a mechanism that's more broadly usable.
> > But yes, we match malloc/free so matching ::new/::delete by aliasing them
> > to __builtin_operator_new and __builtin_operator_delete is fair enough.
>
> Would it make sense to annotate the actual calls to the
> allocation/deallocation functions, instead of the declarations of
> those functions?

Sure - I think that's ultimatively the way to go.

> According to Richard Smith, we don't want to optimise away 'operator
> delete(operator new(1), 1)' because that's an explicit call, and the
> user might have replaced those functions and be relying on the side
> effects. But we can optimise away 'delete new char' and we can
> optimise away 
> std::allocator().deallocate(std::allocator().allocate(1),
> 1). So what matters is not whether the functions being called match up
> (they have to anyway) or which functions are being called. What
> matters is whether they are called implicitly (by a new-expression or
> by std::allocator).

OK, I see.  So for the inline case we'd for example have

operator new() { return ::new ...; }

and

 delete new T;

where the generated and marked operator new is inlined we'd no longer
elide the pair because the operator new implementation had an explicit
call to ::new and this is what the optimization sees now.  Only when
the operator new implementation uses a new expression again we'd
see it as candidate pair and then run into the inline issue again
(the issue of the new operator implementation incrementing some counter
and the delete one decrementing it, us inlining one of both and then
eliding the pair, only eliding either the increment or the decrement
and thus retaining half of the overall side-effect).

> So when the compiler expands 'new T' into a call to operator new
> followed by constructing a T (plus exception handling) the call to
> operator new would be marked as optimisable by the FE, and likewise
> when the compiler expands 'delete p' into a destructor followed by
> calling operator delete, the call to operator delete would be marked
> as optimisable. If a pointer is allocated by a call marked optimisable
> and deallocated by a call marked optimisable, it can be optimised away
> (or coalesced with another optimisation).
>
> Then for std::allocator we just want to be able to mark the explicit
> calls to operator new and operator delete as "optimisable", as the FE
> does for the implicit calls it generates. So if we want a general
> purpose utility, it would be an attribute to mark /calls/ as
> optimisable, not functions.
>
> Adding __builtin_operator_new would just be a different syntax for
> 

[committed] libphobos: Always build with warning flags enabled

[Iain Buclaw via Gcc-patches]

Hi,

This patch moves WARN_DFLAGS from GDCFLAGS to AM_DFLAGS so it is always
included in the build and testsuite of libphobos.  Currently, this
doesn't happen as GDCFLAGS is overriden by it being set at the
top-level.

Bootstrapped and regression tested on x86_64-linux-gnu, and committed to
mainline.

Regards
Iain.

---
libphobos/ChangeLog:

* Makefile.in: Regenerate.
* configure: Regenerate.
* configure.ac: Substite WARN_DFLAGS independently of GDCFLAGS.
* libdruntime/Makefile.am: Add WARN_DFLAGS to AM_DFLAGS.
* libdruntime/Makefile.in: Regenerate.
* src/Makefile.am: Add WARN_DFLAGS to AM_DFLAGS.
* src/Makefile.in: Regenerate.
* testsuite/Makefile.in: Regenerate.
* testsuite/testsuite_flags.in: Add WARN_DFLAGS to --gdcflags.
---
 libphobos/Makefile.in  |  1 +
 libphobos/configure| 12 
 libphobos/configure.ac |  7 +--
 libphobos/libdruntime/Makefile.am  |  4 +++-
 libphobos/libdruntime/Makefile.in  |  6 +-
 libphobos/src/Makefile.am  |  4 +++-
 libphobos/src/Makefile.in  |  6 +-
 libphobos/testsuite/Makefile.in|  1 +
 libphobos/testsuite/testsuite_flags.in |  2 +-
 9 files changed, 32 insertions(+), 11 deletions(-)

diff --git a/libphobos/Makefile.in b/libphobos/Makefile.in
index 6a774e96126..98d35641a95 100644
--- a/libphobos/Makefile.in
+++ b/libphobos/Makefile.in
@@ -272,6 +272,7 @@ SHELL = @SHELL@
 SPEC_PHOBOS_DEPS = @SPEC_PHOBOS_DEPS@
 STRIP = @STRIP@
 VERSION = @VERSION@
+WARN_DFLAGS = @WARN_DFLAGS@
 abs_builddir = @abs_builddir@
 abs_srcdir = @abs_srcdir@
 abs_top_builddir = @abs_top_builddir@
diff --git a/libphobos/configure b/libphobos/configure
index 04a6e6aeb0f..65e32d88f45 100755
--- a/libphobos/configure
+++ b/libphobos/configure
@@ -633,6 +633,7 @@ ac_subst_vars='am__EXEEXT_FALSE
 am__EXEEXT_TRUE
 LTLIBOBJS
 LIBOBJS
+WARN_DFLAGS
 GDCFLAGSX
 libtool_VERSION
 SPEC_PHOBOS_DEPS
@@ -11648,7 +11649,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 11651 "configure"
+#line 11652 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -11754,7 +11755,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 11757 "configure"
+#line 11758 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -15390,15 +15391,18 @@ libtool_VERSION=1:0:0
 
 # Set default flags (after DRUNTIME_WERROR!)
 if test -z "$GDCFLAGS"; then
-GDCFLAGS="-Wall $WERROR_FLAG -g -frelease -O2"
+GDCFLAGS="-g -frelease -O2"
 fi
 
 
 if test -z "$GDCFLAGSX"; then
-GDCFLAGSX="-Wall $WERROR_FLAG -g -fno-release -funittest"
+GDCFLAGSX="-g -fno-release -funittest"
 fi
 
 
+WARN_DFLAGS="-Wall $WERROR_FLAG"
+
+
 # Sanity check for the cross-compilation case:
 ac_fn_c_check_header_mongrel "$LINENO" "stdio.h" "ac_cv_header_stdio_h" 
"$ac_includes_default"
 if test "x$ac_cv_header_stdio_h" = xyes; then :
diff --git a/libphobos/configure.ac b/libphobos/configure.ac
index 69c635f405b..09e334d2045 100644
--- a/libphobos/configure.ac
+++ b/libphobos/configure.ac
@@ -206,15 +206,18 @@ AC_SUBST(libtool_VERSION)
 
 # Set default flags (after DRUNTIME_WERROR!)
 if test -z "$GDCFLAGS"; then
-GDCFLAGS="-Wall $WERROR_FLAG -g -frelease -O2"
+GDCFLAGS="-g -frelease -O2"
 fi
 AC_SUBST(GDCFLAGS)
 
 if test -z "$GDCFLAGSX"; then
-GDCFLAGSX="-Wall $WERROR_FLAG -g -fno-release -funittest"
+GDCFLAGSX="-g -fno-release -funittest"
 fi
 AC_SUBST(GDCFLAGSX)
 
+WARN_DFLAGS="-Wall $WERROR_FLAG"
+AC_SUBST(WARN_DFLAGS)
+
 # Sanity check for the cross-compilation case:
 AC_CHECK_HEADER(stdio.h,:,
   [AC_MSG_ERROR([cannot find stdio.h.])])
diff --git a/libphobos/libdruntime/Makefile.am 
b/libphobos/libdruntime/Makefile.am
index b6f43299064..b7e4575e0f1 100644
--- a/libphobos/libdruntime/Makefile.am
+++ b/libphobos/libdruntime/Makefile.am
@@ -22,7 +22,9 @@ include $(top_srcdir)/d_rules.am
 D_EXTRA_DFLAGS=-nostdinc -I $(srcdir) -I .
 
 # D flags for compilation
-AM_DFLAGS=$(phobos_compiler_pic_flag)
+AM_DFLAGS= \
+   $(phobos_compiler_pic_flag) \
+   $(WARN_DFLAGS)
 
 # Install all D and DI files
 ALL_DRUNTIME_INSTALL_DSOURCES = $(DRUNTIME_DSOURCES) \
diff --git a/libphobos/libdruntime/Makefile.in 
b/libphobos/libdruntime/Makefile.in
index cbbe6298537..61dd0d496e3 100644
--- a/libphobos/libdruntime/Makefile.in
+++ b/libphobos/libdruntime/Makefile.in
@@ -620,6 +620,7 @@ SHELL = @SHELL@
 SPEC_PHOBOS_DEPS = @SPEC_PHOBOS_DEPS@
 STRIP = @STRIP@
 VERSION = @VERSION@
+WARN_DFLAGS = @WARN_DFLAGS@
 abs_builddir = @abs_builddir@
 abs_srcdir = @abs_srcdir@
 abs_top_builddir = @abs_top_builddir@
@@ -712,7 +713,10 @@ libgphobos_la_LINK = $(LIBTOOL) --tag=D 
$(libgphobos_la_LIBTOOLFLAGS) \
 D_EXTRA_DFLAGS = -nostdinc -I $(srcdir) -I .
 
 # D flags for compilation
-AM_DFLAGS =