Re: [patch] Add baseline for SPARC64/Linux

[Eric Botcazou]

> 2019-02-20  Eric Botcazou  
> 
> * configure.host (abi_baseline_pair): Adjust for SPARC64/Linux.
> * config/abi/post/sparc64-linux-gnu: New directory.
> * config/abi/post/sparc64-linux-gnu/baseline_symbols.txt: New file.
> * config/abi/post/sparc64-linux-gnu/32: New directory.
>   * config/abi/post/sparc64-linux-gnu/32/baseline_symbols.txt: New file.

I can probably self-approve it as SPARC maintainer so now installed.

-- 
Eric Botcazou

[C++ PATCH] PR c++/87685 - generic lambda 'this' capture error.

[Jason Merrill]

The standard says that in a generic lambda we should speculatively capture
'this' if we see a call to an overload set that contains a non-static member
function, but it seems wrong to reject the program if we can't capture,
since it might not actually be needed.

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

* lambda.c (lambda_expr_this_capture): Change add_capture_p to int.
(maybe_generic_this_capture): Pass -1.
---
 gcc/cp/cp-tree.h  |  2 +-
 gcc/cp/lambda.c   |  9 +
 gcc/testsuite/g++.dg/cpp1y/lambda-generic-this3.C | 13 +
 gcc/cp/ChangeLog  |  4 
 4 files changed, 23 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp1y/lambda-generic-this3.C

diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 879712f6dbc..91bc82b85e5 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -7151,7 +7151,7 @@ extern bool is_capture_proxy  (tree);
 extern bool is_normal_capture_proxy (tree);
 extern bool is_constant_capture_proxy   (tree);
 extern void register_capture_members   (tree);
-extern tree lambda_expr_this_capture(tree, bool);
+extern tree lambda_expr_this_capture(tree, int);
 extern void maybe_generic_this_capture (tree, tree);
 extern tree maybe_resolve_dummy(tree, bool);
 extern tree current_nonlambda_function (void);
diff --git a/gcc/cp/lambda.c b/gcc/cp/lambda.c
index 7032168fb7b..d178f15a4da 100644
--- a/gcc/cp/lambda.c
+++ b/gcc/cp/lambda.c
@@ -730,10 +730,11 @@ add_default_capture (tree lambda_stack, tree id, tree 
initializer)
 
 /* Return the capture pertaining to a use of 'this' in LAMBDA, in the
form of an INDIRECT_REF, possibly adding it through default
-   capturing, if ADD_CAPTURE_P is true.  */
+   capturing, if ADD_CAPTURE_P is nonzero.  If ADD_CAPTURE_P is negative,
+   try to capture but don't complain if we can't.  */
 
 tree
-lambda_expr_this_capture (tree lambda, bool add_capture_p)
+lambda_expr_this_capture (tree lambda, int add_capture_p)
 {
   tree result;
 
@@ -829,7 +830,7 @@ lambda_expr_this_capture (tree lambda, bool add_capture_p)
 result = this_capture;
   else if (!this_capture)
 {
-  if (add_capture_p)
+  if (add_capture_p == 1)
{
  error ("% was not captured for this lambda function");
  result = error_mark_node;
@@ -934,7 +935,7 @@ maybe_generic_this_capture (tree object, tree fns)
  && DECL_NONSTATIC_MEMBER_FUNCTION_P (*iter))
{
  /* Found a non-static member.  Capture this.  */
- lambda_expr_this_capture (lam, true);
+ lambda_expr_this_capture (lam, /*maybe*/-1);
  break;
}
   }
diff --git a/gcc/testsuite/g++.dg/cpp1y/lambda-generic-this3.C 
b/gcc/testsuite/g++.dg/cpp1y/lambda-generic-this3.C
new file mode 100644
index 000..2bd287cc368
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/lambda-generic-this3.C
@@ -0,0 +1,13 @@
+// PR c++/87685
+// { dg-do compile { target c++14 } }
+
+struct A
+{
+  template  static void f(T) {}
+  void f() {}
+
+  void foo()
+  {
+[] (auto&& v) { A::f(v); }; // OK if parameter type is specified
+  }
+};
diff --git a/gcc/cp/ChangeLog b/gcc/cp/ChangeLog
index a41044683fe..e7780e7eb12 100644
--- a/gcc/cp/ChangeLog
+++ b/gcc/cp/ChangeLog
@@ -1,5 +1,9 @@
 2019-02-21  Jason Merrill  
 
+   PR c++/87685 - generic lambda 'this' capture error.
+   * lambda.c (lambda_expr_this_capture): Change add_capture_p to int.
+   (maybe_generic_this_capture): Pass -1.
+
PR c++/88394 - ICE with VLA init-capture.
* lambda.c (is_normal_capture_proxy): Check DECL_CAPTURED_VARIABLE.
 

base-commit: a7ea8f9672905a517f73ea2764a4301ddc8e3184
-- 
2.20.1

Re: [PR fortran/83057, patch] - OPEN without a filename and without STATUS='SCRATCH' could produce a warning

[Jerry DeLisle]

On 2/20/19 2:34 PM, Harald Anlauf wrote:

There was a rather obvious bug in the logic for checking the arguments
to the OPEN statement when NEWUNIT= was specified, which prohibited
the generation of the appropriate error message.

Regtested successfully.

OK for trunk?


Yes and thanks for patch.

Jerry

Re: [Patch] [aarch64] PR target/89324 Handle stack pointer for SUBS/ADDS instructions

[Mike Stump]

On Feb 21, 2019, at 4:09 PM, James Greenhalgh  wrote:
> 
>> NOTE: I have included a bunch of RTL testcases that I used in development, 
>> these
>> don't exercise much of the compiler and are pretty specific to the backend 
>> as it
>> currently is, so I'm not sure they give much value. I'd appreciate feedback 
>> on
>> whether this is in general considered useful.
> 
> I would happily take the RTL test, do you want to check with a testsuite
> maintainer?

If someone asked me, I'd leave it up to the maintainer that is tasked with 
maintaining the test case.  If too much trouble and a ton of maintenance 
required for not much benefit, they might prefer not to have it.  Anyway, I'd 
defer to the port people to weigh in.  Doesn't look unreasonable at first blush.

[C++ PATCH] PR c++/88394 - ICE with VLA init-capture.

[Jason Merrill]

We mostly use is_normal_capture_proxy to decide whether or not to use
DECL_CAPTURED_VARIABLE; we could just check whether it's set.  VLA capture
is still mostly broken, but this fixes this ICE.

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

* lambda.c (is_normal_capture_proxy): Check DECL_CAPTURED_VARIABLE.
---
 gcc/cp/lambda.c   | 16 ++--
 gcc/testsuite/g++.dg/cpp1y/lambda-init-vla1.C | 12 
 gcc/cp/ChangeLog  |  3 +++
 3 files changed, 17 insertions(+), 14 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp1y/lambda-init-vla1.C

diff --git a/gcc/cp/lambda.c b/gcc/cp/lambda.c
index 3b803ad86a6..7032168fb7b 100644
--- a/gcc/cp/lambda.c
+++ b/gcc/cp/lambda.c
@@ -279,20 +279,8 @@ is_normal_capture_proxy (tree decl)
 /* It's not a capture proxy.  */
 return false;
 
-  if (variably_modified_type_p (TREE_TYPE (decl), NULL_TREE))
-/* VLA capture.  */
-return true;
-
-  /* It is a capture proxy, is it a normal capture?  */
-  tree val = DECL_VALUE_EXPR (decl);
-  if (val == error_mark_node)
-return true;
-
-  if (TREE_CODE (val) == ADDR_EXPR)
-val = TREE_OPERAND (val, 0);
-  gcc_assert (TREE_CODE (val) == COMPONENT_REF);
-  val = TREE_OPERAND (val, 1);
-  return DECL_NORMAL_CAPTURE_P (val);
+  return (DECL_LANG_SPECIFIC (decl)
+ && DECL_CAPTURED_VARIABLE (decl));
 }
 
 /* Returns true iff DECL is a capture proxy for a normal capture
diff --git a/gcc/testsuite/g++.dg/cpp1y/lambda-init-vla1.C 
b/gcc/testsuite/g++.dg/cpp1y/lambda-init-vla1.C
new file mode 100644
index 000..1fef7b4a7f9
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/lambda-init-vla1.C
@@ -0,0 +1,12 @@
+// PR c++/88394
+// { dg-do compile { target c++14 } }
+// { dg-options "" }
+
+void crash_me(unsigned short sz)
+{
+  if (sz == 0) return;
+
+  short iov[sz];
+  auto fce = [ = iov](short value) { iv[0] = 0; };
+  fce(1);
+}
diff --git a/gcc/cp/ChangeLog b/gcc/cp/ChangeLog
index 013bca59380..a41044683fe 100644
--- a/gcc/cp/ChangeLog
+++ b/gcc/cp/ChangeLog
@@ -1,5 +1,8 @@
 2019-02-21  Jason Merrill  
 
+   PR c++/88394 - ICE with VLA init-capture.
+   * lambda.c (is_normal_capture_proxy): Check DECL_CAPTURED_VARIABLE.
+
PR c++/88869 - C++17 ICE with CTAD and explicit specialization.
* pt.c (do_class_deduction): Don't include explicit specialization
args in outer_args.

base-commit: e2d4b8be24e405e8e789264c3c20767c2a7c7ab4
-- 
2.20.1

Re: [PATCH 11/25] Simplify vec_merge according to the mask.

[H.J. Lu]

On Fri, Sep 28, 2018 at 6:33 AM Andrew Stubbs  wrote:
>
> On 28/09/18 09:11, Richard Sandiford wrote:
> > Yes, thanks.
>
> Committed.
>
> Thanks for all the reviews. :-)
>

This caused:

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


-- 
H.J.

[C++ PATCH] PR c++/88869 - C++17 ICE with CTAD and explicit specialization.

[Jason Merrill]

The members of an explicit specialization of a class template don't have the
template parameters of that class template, so we shouldn't try to provide
arguments for them.  Only set outer_args when the class is an instantiation.

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

* pt.c (do_class_deduction): Don't include explicit specialization
args in outer_args.
---
 gcc/cp/pt.c|  2 +-
 gcc/testsuite/g++.dg/cpp1z/class-deduction63.C | 11 +++
 gcc/cp/ChangeLog   |  4 
 3 files changed, 16 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp1z/class-deduction63.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 76fb625a068..42dd095a6b0 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -27224,7 +27224,7 @@ do_class_deduction (tree ptype, tree tmpl, tree init, 
int flags,
 
   tree outer_args = NULL_TREE;
   if (DECL_CLASS_SCOPE_P (tmpl)
-  && CLASSTYPE_TEMPLATE_INFO (DECL_CONTEXT (tmpl)))
+  && CLASSTYPE_TEMPLATE_INSTANTIATION (DECL_CONTEXT (tmpl)))
 {
   outer_args = CLASSTYPE_TI_ARGS (DECL_CONTEXT (tmpl));
   type = TREE_TYPE (most_general_template (tmpl));
diff --git a/gcc/testsuite/g++.dg/cpp1z/class-deduction63.C 
b/gcc/testsuite/g++.dg/cpp1z/class-deduction63.C
new file mode 100644
index 000..4fc66fcbe15
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1z/class-deduction63.C
@@ -0,0 +1,11 @@
+// PR c++/88869
+// { dg-do compile { target c++17 } }
+
+template  struct B;
+template <> struct B {
+  template  struct C {
+T e;
+C (T f) : e(f) {}
+  };
+  void foo () { C c (42); }
+};
diff --git a/gcc/cp/ChangeLog b/gcc/cp/ChangeLog
index 2f99f2b95c8..013bca59380 100644
--- a/gcc/cp/ChangeLog
+++ b/gcc/cp/ChangeLog
@@ -1,5 +1,9 @@
 2019-02-21  Jason Merrill  
 
+   PR c++/88869 - C++17 ICE with CTAD and explicit specialization.
+   * pt.c (do_class_deduction): Don't include explicit specialization
+   args in outer_args.
+
PR c++/89422 - ICE with -g and lambda in default arg in template.
* pt.c (tsubst_function_decl): SET_DECL_FRIEND_CONTEXT sooner.
 

base-commit: b6700c1afdd5e39fe9e886578f8404dc53390f74
-- 
2.20.1

Re: [PATCH] avoid -Wabsolute-value in dead subexpressions (PR 89425)

[Joseph Myers]

On Thu, 21 Feb 2019, Martin Sebor wrote:

> Joseph noticed the -Wabsolute-value warning newly introduced in GCC
> 9 and included in -Wextra triggers on some unreachable subexpressions
> in Glibc code that the C front end otherwise makes an effort to avoid
> diagnosing.  The attached trivial patch guards the warning to avoid
> these spurious instances.
> 
> Tested on x86_64-linux.

OK.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: C++ PATCH for c++/89420 - ICE with CAST_EXPR in explicit-specifier

[Jason Merrill]

On 2/21/19 1:35 PM, Marek Polacek wrote:

We were ICEing because we called build_converted_constant_expr on an expression
that wasn't value-dependent, but it still contained template codes, and that
didn't work too well because check_narrowing calls maybe_constant_value.


Hmm, I'm concerned about convert_like_real from 
build_converted_constant_expr adding more template codes; you probably 
want a processing_template_decl_sentinel after the 
instantiate_non_dependent_expr.


Also, value_dependent_expression_p should probably be 
instantiation_dependent_expression_p.


Jason

Re: [committed] Fix -Wmissing-attributes warning in libstdc++ (PR libstdc++/89402)

[Jonathan Wakely]

On 22/02/19 02:23 +0100, Jakub Jelinek wrote:

On Fri, Feb 22, 2019 at 01:10:32AM +, Jonathan Wakely wrote:

On 20/02/19 09:07 +0100, Jakub Jelinek wrote:
> Hi!
>
> The following patch fixes a warning when building on targets where long
> double switched from being the same as double to something wider,
> like e.g. powerpc*-linux, alpha*-linux, s390*-linux etc.
>
> Fixed thusly, bootstrapped/regtested on {x86_64,i686,s390x}-linux and
> bootstrapped on powerpc64le-linux, on both s390x and powerpc64le it removed
> all
> ../../../../libstdc++-v3/src/c++98/compatibility-ldbl.cc:77:17: warning: 'void 
_ZNKSt4hashIeEclEe()' specifies less restrictive attribute than its target 'std::size_t 
std::tr1::hash<_Tp>::operator()(_Tp) const [with _Tp = long double]': 'pure' 
[-Wmissing-attributes]
> warnings from the build log.  Preapproved by Jonathan in the PR, committed
> to trunk.

Now I see:

/home/jwakely/src/gcc/libstdc++-v3/src/c++98/compatibility-ldbl.cc:78:65: 
warning: ‘pure’ attribute on function returning ‘void’ [-Wattributes]
  78 |   _GLIBCXX_PURE __attribute__((alias ("_ZNKSt3tr14hashIeEclEe")));
 | ^

We can disable that with a diagnostic pragma.


Oops, sorry, missed that.
Or make it extern "C" size_t _ZNKSt4hashIeEclEe (long double) or so, after all,
that is what it returns and what it takes as an argument.


Ah yes, even better.


> 2019-02-20  Jakub Jelinek  
>
>PR libstdc++/89402
>* src/c++98/compatibility-ldbl.cc (_ZNKSt4hashIeEclEe): Add
>_GLIBCXX_PURE to the alias declaration.
>
> --- libstdc++-v3/src/c++98/compatibility-ldbl.cc.jj2019-01-01 
12:39:41.530606161 +0100
> +++ libstdc++-v3/src/c++98/compatibility-ldbl.cc   2019-02-19 
16:12:52.402123217 +0100
> @@ -75,6 +75,6 @@ namespace std _GLIBCXX_VISIBILITY(defaul
> // and std::hash::operator()
> // are the same, no need to duplicate them.
> extern "C" void _ZNKSt4hashIeEclEe (void)
> -  __attribute__((alias ("_ZNKSt3tr14hashIeEclEe")));
> +  _GLIBCXX_PURE __attribute__((alias ("_ZNKSt3tr14hashIeEclEe")));
>
> #endif


Jakub

Re: [committed] Fix -Wmissing-attributes warning in libstdc++ (PR libstdc++/89402)

[Jakub Jelinek]

On Fri, Feb 22, 2019 at 01:10:32AM +, Jonathan Wakely wrote:
> On 20/02/19 09:07 +0100, Jakub Jelinek wrote:
> > Hi!
> > 
> > The following patch fixes a warning when building on targets where long
> > double switched from being the same as double to something wider,
> > like e.g. powerpc*-linux, alpha*-linux, s390*-linux etc.
> > 
> > Fixed thusly, bootstrapped/regtested on {x86_64,i686,s390x}-linux and
> > bootstrapped on powerpc64le-linux, on both s390x and powerpc64le it removed
> > all
> > ../../../../libstdc++-v3/src/c++98/compatibility-ldbl.cc:77:17: warning: 
> > 'void _ZNKSt4hashIeEclEe()' specifies less restrictive attribute than its 
> > target 'std::size_t std::tr1::hash<_Tp>::operator()(_Tp) const [with _Tp = 
> > long double]': 'pure' [-Wmissing-attributes]
> > warnings from the build log.  Preapproved by Jonathan in the PR, committed
> > to trunk.
> 
> Now I see:
> 
> /home/jwakely/src/gcc/libstdc++-v3/src/c++98/compatibility-ldbl.cc:78:65: 
> warning: ‘pure’ attribute on function returning ‘void’ [-Wattributes]
>   78 |   _GLIBCXX_PURE __attribute__((alias ("_ZNKSt3tr14hashIeEclEe")));
>  | ^
> 
> We can disable that with a diagnostic pragma.

Oops, sorry, missed that.
Or make it extern "C" size_t _ZNKSt4hashIeEclEe (long double) or so, after all,
that is what it returns and what it takes as an argument.

> > 2019-02-20  Jakub Jelinek  
> > 
> > PR libstdc++/89402
> > * src/c++98/compatibility-ldbl.cc (_ZNKSt4hashIeEclEe): Add
> > _GLIBCXX_PURE to the alias declaration.
> > 
> > --- libstdc++-v3/src/c++98/compatibility-ldbl.cc.jj 2019-01-01 
> > 12:39:41.530606161 +0100
> > +++ libstdc++-v3/src/c++98/compatibility-ldbl.cc2019-02-19 
> > 16:12:52.402123217 +0100
> > @@ -75,6 +75,6 @@ namespace std _GLIBCXX_VISIBILITY(defaul
> > // and std::hash::operator()
> > // are the same, no need to duplicate them.
> > extern "C" void _ZNKSt4hashIeEclEe (void)
> > -  __attribute__((alias ("_ZNKSt3tr14hashIeEclEe")));
> > +  _GLIBCXX_PURE __attribute__((alias ("_ZNKSt3tr14hashIeEclEe")));
> > 
> > #endif

Jakub

Re: [PATCH 9/9]: C++ P0482R5 char8_t: Updates to gdb pretty printing support

[Jonathan Wakely]

On 05/11/18 14:40 -0500, Tom Honermann wrote:
This patch adds recognition of the u8string and u8string_view type 
aliases to the gdb pretty printer extension.


libstdc++-v3/ChangeLog:

2018-11-04  Tom Honermann  

* python/libstdcxx/v6/printers.py (register_type_printers): Add
type printers for u8string and u8string_view.
* testsuite/libstdc++-prettyprinters/whatis.cc: Validate
recognition of u8string.

Tom.



diff --git a/libstdc++-v3/python/libstdcxx/v6/printers.py 
b/libstdc++-v3/python/libstdcxx/v6/printers.py
index 827c87b70ea..f9e638e210d 100644
--- a/libstdc++-v3/python/libstdcxx/v6/printers.py
+++ b/libstdc++-v3/python/libstdcxx/v6/printers.py
@@ -1554,7 +1554,7 @@ def register_type_printers(obj):
return

# Add type printers for typedefs std::string, std::wstring etc.
-for ch in ('', 'w', 'u16', 'u32'):
+for ch in ('', 'w', 'u8', 'u16', 'u32'):
add_one_type_printer(obj, 'basic_string', ch + 'string')
add_one_type_printer(obj, '__cxx11::basic_string', ch + 'string')
# Typedefs for __cxx11::basic_string used to be in namespace __cxx11:
@@ -1604,7 +1604,7 @@ def register_type_printers(obj):

# Add type printers for experimental::basic_string_view typedefs.
ns = 'experimental::fundamentals_v1::'
-for ch in ('', 'w', 'u16', 'u32'):
+for ch in ('', 'w', 'u8', 'u16', 'u32'):
add_one_type_printer(obj, ns + 'basic_string_view',
 ns + ch + 'string_view')



I've committed the above change, but not the part below (again, I
don't want to add -fchar8_t to the test, so I'll add a new whatis3.cc
test for C++2a).



diff --git a/libstdc++-v3/testsuite/libstdc++-prettyprinters/whatis.cc 
b/libstdc++-v3/testsuite/libstdc++-prettyprinters/whatis.cc
index 90f3994314b..d74bf7c5e9b 100644
--- a/libstdc++-v3/testsuite/libstdc++-prettyprinters/whatis.cc
+++ b/libstdc++-v3/testsuite/libstdc++-prettyprinters/whatis.cc
@@ -1,5 +1,5 @@
// { dg-do run { target c++11 } }
-// { dg-options "-g -O0" }
+// { dg-options "-g -O0 -fchar8_t" }
// { dg-skip-if "" { *-*-* } { "-D_GLIBCXX_PROFILE" } }

// Copyright (C) 2011-2018 Free Software Foundation, Inc.
@@ -130,6 +130,9 @@ holder 
cregex_token_iterator_holder;
std::sregex_token_iterator *sregex_token_iterator_ptr;
holder sregex_token_iterator_holder;
// { dg-final { whatis-test sregex_token_iterator_holder 
"holder" } }
+std::u8string *u8string_ptr;
+holder u8string_holder;
+// { dg-final { whatis-test u8string_holder "holder" } }
std::u16string *u16string_ptr;
holder u16string_holder;
// { dg-final { whatis-test u16string_holder "holder" } }
@@ -240,6 +243,8 @@ main()
  placeholder(_token_iterator_holder);
  placeholder(_token_iterator_ptr);
  placeholder(_token_iterator_holder);
+  placeholder(_ptr);
+  placeholder(_holder);
  placeholder(_ptr);
  placeholder(_holder);
  placeholder(_ptr);

Re: [PATCH 8/9]: C++ P0482R5 char8_t: Updates to existing standard library tests

[Jonathan Wakely]

On 22/02/19 01:19 +, Jonathan Wakely wrote:

On 05/11/18 14:40 -0500, Tom Honermann wrote:
This patch augments existing tests to validate behavior for char8_t.  
In all cases, added test cases are cloned from existing tests for 
wchar_t or char16_t.


A few tests required updates to line numbers for diagnostic messages.


I had to make a few changes to this patch. I don't like adding
-fchar8_t to lots of non-C++2a tests, so I removed all the lines
adding that to the dg-options. Instead I either ensured all the checks
for char8_t features are guarded by _GLIBCXX_USE_CHAR8_t, or are in
their own new test files that are compiled using -std=gnu++2a.

I also had to fix the changes to
testsuite/util/testsuite_common_types.h because the additions to the
integral types and the atomic integral types were not in the same
order, so testsuite/29_atomics/atomic/requirements/base_classes.cc
failed when using -std=gnu++2a.

I've committed the attached patch.


Here are some new tests built with -std=gnu++2a, committed to trunk.


commit 4f847a8e46036422867a8169d6bfbe45dc6d633d
Author: redi 
Date:   Fri Feb 22 01:16:15 2019 +

Add tests for C++2a content of  header

* testsuite/29_atomics/headers/atomic/types_std_c++20.cc: New test.
* testsuite/29_atomics/headers/atomic/types_std_c++20_neg.cc: New
test.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@269091 138bc75d-0d04-0410-961f-82ee72b054a4

diff --git a/libstdc++-v3/testsuite/29_atomics/headers/atomic/types_std_c++20.cc b/libstdc++-v3/testsuite/29_atomics/headers/atomic/types_std_c++20.cc
new file mode 100644
index 000..e8a76204f55
--- /dev/null
+++ b/libstdc++-v3/testsuite/29_atomics/headers/atomic/types_std_c++20.cc
@@ -0,0 +1,96 @@
+// { dg-options "-std=gnu++2a" }
+// { dg-do compile { target c++2a } }
+// { dg-require-cstdint "" }
+
+// Copyright (C) 2008-2019 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
+// .
+
+#include 
+
+void test01()
+{
+  using std::memory_order;
+  // TODO add checks for new enumerators memory_order::relaxed etc.
+  // using std::memory_order::relaxed;
+  // using std::memory_order::consume;
+  // using std::memory_order::acquire;
+  // using std::memory_order::release;
+  // using std::memory_order::acq_rel;
+  // using std::memory_order::seq_cst;
+  using std::memory_order_relaxed;
+  using std::memory_order_consume;
+  using std::memory_order_acquire;
+  using std::memory_order_release;
+  using std::memory_order_acq_rel;
+  using std::memory_order_seq_cst;
+
+  using std::atomic_flag;
+
+  // atomics for builtins types
+  using std::atomic_bool;
+  using std::atomic_char;
+  using std::atomic_schar;
+  using std::atomic_uchar;
+  using std::atomic_short;
+  using std::atomic_ushort;
+  using std::atomic_int;
+  using std::atomic_uint;
+  using std::atomic_long;
+  using std::atomic_ulong;
+  using std::atomic_llong;
+  using std::atomic_ullong;
+  using std::atomic_wchar_t;
+#ifdef _GLIBCXX_USE_CHAR8_T
+  using std::atomic_char8_t;
+#endif
+  using std::atomic_char16_t;
+  using std::atomic_char32_t;
+
+  // atomics for standard typedefs
+  using std::atomic_int_least8_t;
+  using std::atomic_uint_least8_t;
+  using std::atomic_int_least16_t;
+  using std::atomic_uint_least16_t;
+  using std::atomic_int_least32_t;
+  using std::atomic_uint_least32_t;
+  using std::atomic_int_least64_t;
+  using std::atomic_uint_least64_t;
+  using std::atomic_int_fast8_t;
+  using std::atomic_uint_fast8_t;
+  using std::atomic_int_fast16_t;
+  using std::atomic_uint_fast16_t;
+  using std::atomic_int_fast32_t;
+  using std::atomic_uint_fast32_t;
+  using std::atomic_int_fast64_t;
+  using std::atomic_uint_fast64_t;
+  using std::atomic_intptr_t;
+  using std::atomic_uintptr_t;
+  using std::atomic_size_t;
+  using std::atomic_ptrdiff_t;
+  using std::atomic_intmax_t;
+  using std::atomic_uintmax_t;
+
+  // DR 2441
+  using std::atomic_int8_t;
+  using std::atomic_uint8_t;
+  using std::atomic_int16_t;
+  using std::atomic_uint16_t;
+  using std::atomic_int32_t;
+  using std::atomic_uint32_t;
+  using std::atomic_int64_t;
+  using std::atomic_uint64_t;
+}
diff --git a/libstdc++-v3/testsuite/29_atomics/headers/atomic/types_std_c++20_neg.cc 

Re: [PATCH 8/9]: C++ P0482R5 char8_t: Updates to existing standard library tests

[Jonathan Wakely]

On 05/11/18 14:40 -0500, Tom Honermann wrote:
This patch augments existing tests to validate behavior for char8_t.  
In all cases, added test cases are cloned from existing tests for 
wchar_t or char16_t.


A few tests required updates to line numbers for diagnostic messages.


I had to make a few changes to this patch. I don't like adding
-fchar8_t to lots of non-C++2a tests, so I removed all the lines
adding that to the dg-options. Instead I either ensured all the checks
for char8_t features are guarded by _GLIBCXX_USE_CHAR8_t, or are in
their own new test files that are compiled using -std=gnu++2a.

I also had to fix the changes to
testsuite/util/testsuite_common_types.h because the additions to the
integral types and the atomic integral types were not in the same
order, so testsuite/29_atomics/atomic/requirements/base_classes.cc
failed when using -std=gnu++2a.

I've committed the attached patch.


commit 25c6cb27a521012dff06cb626cf7314767c38ae4
Author: Jonathan Wakely 
Date:   Thu Feb 21 23:27:22 2019 +

P0482R5 char8_t: Updates to existing standard library tests

This patch augments existing tests to validate behavior for char8_t.  In
all cases, added test cases are cloned from existing tests for wchar_t
or char16_t.

A few tests required updates to line numbers for diagnostic messages.

2019-02-22  Tom Honermann  

* testsuite/18_support/byte/ops.cc: Validate
std::to_integer, std::to_integer, and
std::to_integer.
* testsuite/18_support/numeric_limits/dr559.cc: Validate
std::numeric_limits.
* testsuite/18_support/numeric_limits/lowest.cc: Validate
std::numeric_limits::lowest().
* testsuite/18_support/numeric_limits/max_digits10.cc: Validate
std::numeric_limits::max_digits10.
* testsuite/18_support/type_info/fundamental.cc: Validate
typeinfo for char8_t.
* testsuite/20_util/from_chars/1_c++20_neg.cc: New test, validating
std::from_chars with char8_t.
* testsuite/20_util/hash/requirements/explicit_instantiation.cc:
Validate explicit instantiation of std::hash.
* testsuite/20_util/is_integral/value.cc: Validate
std::is_integral.
* testsuite/20_util/make_signed/requirements/typedefs-4.cc:
Validate std::make_signed.
* testsuite/21_strings/basic_string/cons/char/deduction.cc:
Validate u8string construction from char8_t sources.
* testsuite/21_strings/basic_string/types/pmr_typedefs.cc: Validate
std::pmr::u8string.
* testsuite/21_strings/basic_string_view/operations/compare/
char/70483.cc: Validate substr operations on u8string_view.
* testsuite/21_strings/basic_string_view/typedefs.cc: Validate that
the u8string_view typedef is defined.
* testsuite/21_strings/char_traits/requirements/
constexpr_functions.cc: Validate char_traits constexpr
member functions.
* testsuite/21_strings/char_traits/requirements/
constexpr_functions_c++17.cc: Validate char_traits C++17
constexpr member functions.
* testsuite/21_strings/headers/string/types_std_c++0x.cc: Validate
that the u8string typedef is defined.
* testsuite/22_locale/locale/cons/unicode.cc: Validate the presence
of the std::codecvt and
std::codecvt facets.
* testsuite/29_atomics/atomic/cons/assign_neg.cc: Update line
numbers.
* testsuite/29_atomics/atomic/cons/copy_neg.cc: Likewise.
* testsuite/29_atomics/atomic_integral/cons/assign_neg.cc:
Likewise.
* testsuite/29_atomics/atomic_integral/cons/copy_neg.cc: Likewise.
* testsuite/29_atomics/atomic_integral/is_always_lock_free.cc:
Validate std::atomic::is_always_lock_free
* testsuite/29_atomics/atomic_integral/operators/bitwise_neg.cc:
Update line numbers.
* testsuite/29_atomics/atomic_integral/operators/decrement_neg.cc:
Likewise.
* testsuite/29_atomics/atomic_integral/operators/increment_neg.cc:
Likewise.
* testsuite/experimental/polymorphic_allocator/pmr_typedefs_string.cc:
Validate std::experimental::pmr::u8string.
* testsuite/experimental/string_view/typedefs.cc: Validate that the
u8string_view typedef is defined.
* testsuite/util/testsuite_common_types.h: Add char8_t, char16_t and
char32_t to the typelists.

diff --git a/libstdc++-v3/testsuite/18_support/byte/ops.cc b/libstdc++-v3/testsuite/18_support/byte/ops.cc
index 37a75fa2a32..6b01c1c38f0 100644
--- a/libstdc++-v3/testsuite/18_support/byte/ops.cc
+++ b/libstdc++-v3/testsuite/18_support/byte/ops.cc
@@ -218,7 +218,15 @@ 

Re: [PATCH 6/9]: C++ P0482R5 char8_t: A small correction to a common testsuite header file

[Jonathan Wakely]

On 05/11/18 14:40 -0500, Tom Honermann wrote:
This patch corrects ambiguous partial specializations of 
typelist::detail::append_.  Previously, neither append_, 
Typelist_Chain> nor append_ was a better 
match for append_, null_type>.


libstdc++-v3/ChangeLog:

2018-11-04  Tom Honermann  

* include/ext/typelist.h: Constrained a partial specialization of
  typelist::detail::append_ to only match chain.

Tom.


Committed to trunk, thanks.



diff --git a/libstdc++-v3/include/ext/typelist.h 
b/libstdc++-v3/include/ext/typelist.h
index b21f01ffb43..2cdbc3efafa 100644
--- a/libstdc++-v3/include/ext/typelist.h
+++ b/libstdc++-v3/include/ext/typelist.h
@@ -215,10 +215,10 @@ namespace detail
  typedef Typelist_Chaintype;
};

-  template
-struct append_
+  template
+struct append_, null_type>
{
-  typedef Typelist_Chain   type;
+  typedef chain  type;
};

  template<>

Re: [committed] Fix -Wmissing-attributes warning in libstdc++ (PR libstdc++/89402)

[Jonathan Wakely]

On 20/02/19 09:07 +0100, Jakub Jelinek wrote:

Hi!

The following patch fixes a warning when building on targets where long
double switched from being the same as double to something wider,
like e.g. powerpc*-linux, alpha*-linux, s390*-linux etc.

Fixed thusly, bootstrapped/regtested on {x86_64,i686,s390x}-linux and
bootstrapped on powerpc64le-linux, on both s390x and powerpc64le it removed
all
../../../../libstdc++-v3/src/c++98/compatibility-ldbl.cc:77:17: warning: 'void 
_ZNKSt4hashIeEclEe()' specifies less restrictive attribute than its target 
'std::size_t std::tr1::hash<_Tp>::operator()(_Tp) const [with _Tp = long 
double]': 'pure' [-Wmissing-attributes]
warnings from the build log.  Preapproved by Jonathan in the PR, committed
to trunk.


Now I see:

/home/jwakely/src/gcc/libstdc++-v3/src/c++98/compatibility-ldbl.cc:78:65: 
warning: ‘pure’ attribute on function returning ‘void’ [-Wattributes]
  78 |   _GLIBCXX_PURE __attribute__((alias ("_ZNKSt3tr14hashIeEclEe")));
 | ^

We can disable that with a diagnostic pragma.




2019-02-20  Jakub Jelinek  

PR libstdc++/89402
* src/c++98/compatibility-ldbl.cc (_ZNKSt4hashIeEclEe): Add
_GLIBCXX_PURE to the alias declaration.

--- libstdc++-v3/src/c++98/compatibility-ldbl.cc.jj 2019-01-01 
12:39:41.530606161 +0100
+++ libstdc++-v3/src/c++98/compatibility-ldbl.cc2019-02-19 
16:12:52.402123217 +0100
@@ -75,6 +75,6 @@ namespace std _GLIBCXX_VISIBILITY(defaul
// and std::hash::operator()
// are the same, no need to duplicate them.
extern "C" void _ZNKSt4hashIeEclEe (void)
-  __attribute__((alias ("_ZNKSt3tr14hashIeEclEe")));
+  _GLIBCXX_PURE __attribute__((alias ("_ZNKSt3tr14hashIeEclEe")));

#endif


Jakub

Re: C++ PATCH for c++/88294 - ICE with non-constant noexcept-specifier

[Jason Merrill]

On 2/21/19 1:34 PM, Marek Polacek wrote:

On Thu, Feb 21, 2019 at 11:22:41AM -1000, Jason Merrill wrote:

On 2/21/19 10:56 AM, Marek Polacek wrote:

On Wed, Feb 20, 2019 at 01:53:18PM -1000, Jason Merrill wrote:

On 2/20/19 10:31 AM, Marek Polacek wrote:

Here we ICE when substituting a deferred noexcept-specifier, because it
contains 'this', a PARM_DECL, in an evaluated context.  This is different
from "noexcept(noexcept(this))" where the noexcept operator's operand is
an unevaluated operand.  We crash within tsubst_copy's PARM_DECL handling
of a 'this' PARM_DECL:
15488   gcc_assert (cp_unevaluated_operand != 0)
It'd be wrong to mess with cp_unevaluated_operand (or current_class_*), and
since we only check the expression's constness after substituting in
maybe_instantiate_noexcept, one fix would be the following.

This is not just about 'this', as the 87844 test shows: here we also have
a parameter whose value we're trying to determine -- it's a template arg
of a late-specified return type.  Returning the original value in tsubst_copy
and leaving the later code to complain seems to work here as well.  Just
removing the assert should work as well.


I'm reluctant to mess with this assert, as it catches a lot of lambda bugs.


Makes sense -- I wasn't aware of that.


I think we want to register_parameter_specializations when instantiating
deferred noexcept, so that tsubst_copy can find the right decls.


Thanks for the suggestion -- that works with one catch: we need to replace the
fake 'this' in the noexcept- specifier with a real 'this' (the template one),
one that has DECL_CONTEXT set.  The fake one comes from inject_this_parameter,
when we were parsing the noexcept-specifier.  The real one was set in 
grokfndecl.


If you set current_class_ptr appropriately tsubst_copy will use it, so you
shouldn't need to do a walk_tree.


Unfortunately that broke a lot of libstdc++ tests.  I can poke at it more if
you feel stronly about it.


Please do poke a bit more, that surprises me.

Jason

アラート：別のデバイスからログインしたApple IDログイン.

[Apple Support]

親愛なるCIient、gcc-patches@gcc.gnu.org  

セキュリティ上の理由から、Apple IDはロックされています。 誰かが新しいデバイスであなたのApple IDを悩ませました 


日付：2019年2月22日、 

ブラウザ：Chrome 

オペレーティングシステム：Windows

AppleのIDを引き続き使用するには、アカウントを確認する必要があります。  


確認するにはここをクリック   

心からあなたの,

サポート Apple  


ID Apple|サポート|プライバシーポリシー 著作権 (c) 2019Apple 流通国際,Hollyhill Industrial 
Estate, Hollyhill, Cork, Ireland.すべての権利を保有.  

libgo patch committed: Remove unixgram test sockets

[Ian Lance Taylor]

This libgo patch changes the net package tests to remove unixgram test
sockets after they are used.  This is for PR 89406.  Bootstrapped and
ran Go testsuite on x86_64-pc-linux-gnu.  Committed to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 269086)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-4fbd06dc7b1b8fb665293399a2b6d5326435512f
+45a2e231958854fd945961f0335ac0805d502510
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: libgo/go/net/listen_test.go
===
--- libgo/go/net/listen_test.go (revision 269079)
+++ libgo/go/net/listen_test.go (working copy)
@@ -780,6 +780,9 @@ func TestListenConfigControl(t *testing.
continue
}
c.Close()
+   if network == "unixgram" {
+   os.Remove(address)
+   }
}
})
 }
Index: libgo/go/net/mockserver_test.go
===
--- libgo/go/net/mockserver_test.go (revision 269079)
+++ libgo/go/net/mockserver_test.go (working copy)
@@ -17,8 +17,6 @@ import (
 )
 
 // testUnixAddr uses ioutil.TempFile to get a name that is unique.
-// It also uses /tmp directory in case it is prohibited to create UNIX
-// sockets in TMPDIR.
 func testUnixAddr() string {
f, err := ioutil.TempFile("", "go-nettest")
if err != nil {
Index: libgo/go/net/splice_test.go
===
--- libgo/go/net/splice_test.go (revision 269079)
+++ libgo/go/net/splice_test.go (working copy)
@@ -242,6 +242,7 @@ func testSpliceNoUnixgram(t *testing.T)
if err != nil {
t.Fatal(err)
}
+   defer os.Remove(addr.Name)
up, err := ListenUnixgram("unixgram", addr)
if err != nil {
t.Fatal(err)

libgo patch committed: remove work directory on usage error

[Ian Lance Taylor]

This libgo patch changes the go tool to remove the work directory on a
usage error.  We ensure that cmd/go consistently calls base.Exit
rather than os.Exit, so that we don't incorrectly leave the work
directory around on exit.  This is tested by modifying the testsuite
to run all the tests with TMPDIR set to a temporary directory, and
then check that no files are left behind in that temporary directory.
A couple of tests were adjusted to make this approach work.  This is
for GCC PR 89406.  Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu.  Committed to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 269079)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-43e458ab704e04cdf347f3e74e0b0eff3de00a3d
+4fbd06dc7b1b8fb665293399a2b6d5326435512f
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: libgo/go/cmd/go/go_test.go
===
--- libgo/go/cmd/go/go_test.go  (revision 269079)
+++ libgo/go/cmd/go/go_test.go  (working copy)
@@ -146,7 +146,18 @@ func TestMain(m *testing.M) {
select {}
}
 
-   dir, err := ioutil.TempDir(os.Getenv("GOTMPDIR"), "cmd-go-test-")
+   // Run with a temporary TMPDIR to check that the tests don't
+   // leave anything behind.
+   topTmpdir, err := ioutil.TempDir("", "cmd-go-test-")
+   if err != nil {
+   log.Fatal(err)
+   }
+   if !*testWork {
+   defer removeAll(topTmpdir)
+   }
+   os.Setenv(tempEnvName(), topTmpdir)
+
+   dir, err := ioutil.TempDir(topTmpdir, "tmpdir")
if err != nil {
log.Fatal(err)
}
@@ -258,6 +269,23 @@ func TestMain(m *testing.M) {
removeAll(testTmpDir) // os.Exit won't run defer
}
 
+   if !*testWork {
+   // There shouldn't be anything left in topTmpdir.
+   dirf, err := os.Open(topTmpdir)
+   if err != nil {
+   log.Fatal(err)
+   }
+   names, err := dirf.Readdirnames(0)
+   if err != nil {
+   log.Fatal(err)
+   }
+   if len(names) > 0 {
+   log.Fatalf("unexpected files left in tmpdir: %v", names)
+   }
+
+   removeAll(topTmpdir)
+   }
+
os.Exit(r)
 }
 
@@ -5020,7 +5048,8 @@ func TestExecBuildX(t *testing.T) {
obj := tg.path("main")
tg.run("build", "-x", "-o", obj, src)
sh := tg.path("test.sh")
-   err := ioutil.WriteFile(sh, []byte("set -e\n"+tg.getStderr()), 0666)
+   cmds := tg.getStderr()
+   err := ioutil.WriteFile(sh, []byte("set -e\n"+cmds), 0666)
if err != nil {
t.Fatal(err)
}
@@ -5051,6 +5080,12 @@ func TestExecBuildX(t *testing.T) {
if string(out) != "hello" {
t.Fatalf("got %q; want %q", out, "hello")
}
+
+   matches := regexp.MustCompile(`^WORK=(.*)\n`).FindStringSubmatch(cmds)
+   if len(matches) == 0 {
+   t.Fatal("no WORK directory")
+   }
+   tg.must(os.RemoveAll(matches[1]))
 }
 
 func TestParallelNumber(t *testing.T) {
Index: libgo/go/cmd/go/internal/base/base.go
===
--- libgo/go/cmd/go/internal/base/base.go   (revision 269079)
+++ libgo/go/cmd/go/internal/base/base.go   (working copy)
@@ -82,7 +82,8 @@ func (c *Command) Name() string {
 func (c *Command) Usage() {
fmt.Fprintf(os.Stderr, "usage: %s\n", c.UsageLine)
fmt.Fprintf(os.Stderr, "Run 'go help %s' for details.\n", c.LongName())
-   os.Exit(2)
+   SetExitStatus(2)
+   Exit()
 }
 
 // Runnable reports whether the command can be run; otherwise
Index: libgo/go/cmd/go/internal/cmdflag/flag.go
===
--- libgo/go/cmd/go/internal/cmdflag/flag.go(revision 269079)
+++ libgo/go/cmd/go/internal/cmdflag/flag.go(working copy)
@@ -66,7 +66,8 @@ func SyntaxError(cmd, msg string) {
} else {
fmt.Fprintf(os.Stderr, `run "go help %s" for more 
information`+"\n", cmd)
}
-   os.Exit(2)
+   base.SetExitStatus(2)
+   base.Exit()
 }
 
 // AddKnownFlags registers the flags in defns with base.AddKnownFlag.
Index: libgo/go/cmd/go/internal/help/help.go
===
--- libgo/go/cmd/go/internal/help/help.go   (revision 269079)
+++ libgo/go/cmd/go/internal/help/help.go   (working copy)
@@ -63,7 +63,8 @@ Args:
helpSuccess = " " + strings.Join(args[:i], " ")
}
fmt.Fprintf(os.Stderr, "go help %s: unknown help topic. Run 
'%s'.\n", strings.Join(args, " "), helpSuccess)
-   

Re: [Patch] [aarch64] PR target/89324 Handle stack pointer for SUBS/ADDS instructions

[James Greenhalgh]

On Mon, Feb 18, 2019 at 08:40:12AM -0600, Matthew Malcomson wrote:
> Handle stack pointer with SUBS/ADDS instructions.
> 
> In general the stack pointer was not handled for many SUBS/ADDS patterns in
> aarch64.md.
> Both the "extended register" and "immediate" forms allow the stack pointer to 
> be
> used as the source register, while no form allows the stack pointer for the
> destination register.
> 
> The define_insn patterns generating ADDS/SUBS did not allow the stack pointer
> for any operand, while the define_peephole2 patterns that generated RTX to be
> matched by these patterns allowed the stack pointer for any operand.
> 
> The patterns are fixed by adding the 'k' constraint for the first source 
> operand
> to all define_insns that generate the ADDS/SUBS "extended register" and
> "immediate" forms (but not the "shifted register" form).
> 
> In peephole optimizations, constraint strings are ignored (see "(gccint) C
> Constraint Interface" info node in the documentation), so the decision to act 
> or
> not is based solely on the predicate and condition.
> This patch introduces a new predicate "aarch64_general_reg" to be used in
> define_peephole2 patterns where only GENERAL_REGS registers are acceptable and
> uses that predicate in the peepholes that generate patterns for ADDS/SUBS.
> 
> Additionally, this patch contains two tidy-ups (happy to remove them or put in
> a separate patch if people want):

Generally, yes I prefer that.

> We change the condition of sub3_compare1_imm pattern from checking
> "UINTVAL (operands[2]) == -UINTVAL (operands[3])"
> to checking
> "INTVAL (operands[2]) == -INTVAL (operands[3])"
> for clarity, since the values checked are signed integers, there are negations
> involved in the check, and the condition used by the corresponding peepholes
> also uses INTVAL.
> 
> The superfluous  iterator in the assembly template for
> add3_compareV_imm is removed -- it was applied to an operand that is
> known to be a const_int.
> 
> Full bootstrap and regtest done on aarch64-none-linux-gnu.
> Regression tests done on aarch64-none-linux-gnu and aarch64-none-elf cross
> compiler.
> 
> OK for trunk?

This patch is fine for GCC 10, so not on trunk yet please unless there is
a corectness reason for the change.

> NOTE: I have included a bunch of RTL testcases that I used in development, 
> these
> don't exercise much of the compiler and are pretty specific to the backend as 
> it
> currently is, so I'm not sure they give much value. I'd appreciate feedback on
> whether this is in general considered useful.

I would happily take the RTL test, do you want to check with a testsuite
maintainer?

> gcc/ChangeLog:
> 
> 2019-02-18  Matthew Malcomson  
> 
>   PR target/89324
>   * config/aarch64/aarch64.md: Use aarch64_general_reg predicate on
>   destination register in peepholes generating patterns for ADDS/SUBS.
>   (add3_compare0,
>   *addsi3_compare0_uxtw, add3_compareC,
>   add3_compareV_imm, add3_compareV,
>   *adds__,
>   *subs__,
>   *adds__shift_,
>   *subs__shift_,
>   *adds__multp2, *subs__multp2,
>   *sub3_compare0, *subsi3_compare0_uxtw,
>   sub3_compare1): Allow stack pointer for source register.
>   * config/aarch64/predicates.md (aarch64_general_reg): New predicate.
> 
> 
> gcc/testsuite/ChangeLog:
> 
> 2019-02-18  Matthew Malcomson  
> 
>   PR target/89324
>   * gcc.dg/rtl/aarch64/subs_adds_sp.c: New test.
>   * gfortran.fortran-torture/compile/pr89324.f90: New test.
> 
> 
> 
> ### Attachment also inlined for ease of reply
> ###

I appreciate that.


Thanks,
James

C++ PATCH for c++/89420 - ICE with CAST_EXPR in explicit-specifier

[Marek Polacek]

We were ICEing because we called build_converted_constant_expr on an expression
that wasn't value-dependent, but it still contained template codes, and that
didn't work too well because check_narrowing calls maybe_constant_value.  The
fix is to instantiate the expression before converting it.  I guess let's also
use 'complain'.

Also, when calling value_dependent_expression_p, we don't have to check
processing_template_decl beforehand.

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

2019-02-21  Marek Polacek  

PR c++/89420 - ICE with CAST_EXPR in explicit-specifier.
* decl.c (build_explicit_specifier): Don't check
processing_template_decl.  Call instantiate_non_dependent_expr_sfinae
before build_converted_constant_expr instead of calling
instantiate_non_dependent_expr after it.

* g++.dg/cpp2a/explicit14.C: New test.

diff --git gcc/cp/decl.c gcc/cp/decl.c
index 612afbacd27..83e2b3efa44 100644
--- gcc/cp/decl.c
+++ gcc/cp/decl.c
@@ -16687,12 +16687,12 @@ require_deduced_type (tree decl, tsubst_flags_t 
complain)
 tree
 build_explicit_specifier (tree expr, tsubst_flags_t complain)
 {
-  if (processing_template_decl && value_dependent_expression_p (expr))
+  if (value_dependent_expression_p (expr))
 /* Wait for instantiation, tsubst_function_decl will handle it.  */
 return expr;
 
+  expr = instantiate_non_dependent_expr_sfinae (expr, complain);
   expr = build_converted_constant_expr (boolean_type_node, expr, complain);
-  expr = instantiate_non_dependent_expr (expr);
   expr = cxx_constant_value (expr);
   return expr;
 }
diff --git gcc/testsuite/g++.dg/cpp2a/explicit14.C 
gcc/testsuite/g++.dg/cpp2a/explicit14.C
new file mode 100644
index 000..9c3acc32ac4
--- /dev/null
+++ gcc/testsuite/g++.dg/cpp2a/explicit14.C
@@ -0,0 +1,11 @@
+// PR c++/89420
+// { dg-do compile { target c++2a } }
+
+template
+struct S {
+  explicit(int(1)) S(int);
+  explicit(int{1}) S(int, int);
+};
+
+S s(1);
+S s2(1, 2);

Re: C++ PATCH for c++/88294 - ICE with non-constant noexcept-specifier

[Marek Polacek]

On Thu, Feb 21, 2019 at 11:22:41AM -1000, Jason Merrill wrote:
> On 2/21/19 10:56 AM, Marek Polacek wrote:
> > On Wed, Feb 20, 2019 at 01:53:18PM -1000, Jason Merrill wrote:
> > > On 2/20/19 10:31 AM, Marek Polacek wrote:
> > > > Here we ICE when substituting a deferred noexcept-specifier, because it
> > > > contains 'this', a PARM_DECL, in an evaluated context.  This is 
> > > > different
> > > > from "noexcept(noexcept(this))" where the noexcept operator's operand is
> > > > an unevaluated operand.  We crash within tsubst_copy's PARM_DECL 
> > > > handling
> > > > of a 'this' PARM_DECL:
> > > > 15488   gcc_assert (cp_unevaluated_operand != 0)
> > > > It'd be wrong to mess with cp_unevaluated_operand (or current_class_*), 
> > > > and
> > > > since we only check the expression's constness after substituting in
> > > > maybe_instantiate_noexcept, one fix would be the following.
> > > > 
> > > > This is not just about 'this', as the 87844 test shows: here we also 
> > > > have
> > > > a parameter whose value we're trying to determine -- it's a template arg
> > > > of a late-specified return type.  Returning the original value in 
> > > > tsubst_copy
> > > > and leaving the later code to complain seems to work here as well.  Just
> > > > removing the assert should work as well.
> > > 
> > > I'm reluctant to mess with this assert, as it catches a lot of lambda 
> > > bugs.
> > 
> > Makes sense -- I wasn't aware of that.
> > 
> > > I think we want to register_parameter_specializations when instantiating
> > > deferred noexcept, so that tsubst_copy can find the right decls.
> > 
> > Thanks for the suggestion -- that works with one catch: we need to replace 
> > the
> > fake 'this' in the noexcept- specifier with a real 'this' (the template 
> > one),
> > one that has DECL_CONTEXT set.  The fake one comes from 
> > inject_this_parameter,
> > when we were parsing the noexcept-specifier.  The real one was set in 
> > grokfndecl.
> 
> If you set current_class_ptr appropriately tsubst_copy will use it, so you
> shouldn't need to do a walk_tree.

Unfortunately that broke a lot of libstdc++ tests.  I can poke at it more if
you feel stronly about it.

Marek

Re: [PATCH] x86: (Reapply) Move AESNI generation to Skylake and Goldmont

[H.J. Lu]

On Thu, Feb 21, 2019 at 3:10 PM Thiago Macieira
 wrote:
>
> This is a repeat of commit r263989, which commit r264052 accidentally
> reverted.
>
> Original commit message:
>
> The instruction set first appeared with Westmere, but not all processors
> in that and the next few generations have the instructions. According to
> Wikipedia[1], the first generation in which all SKUs have AES
> instructions are Skylake and Goldmont. I can't find any Skylake,
> Kabylake, Kabylake-R or Cannon Lake currently listed at
> https://ark.intel.com that says "Intel® AES New Instructions" "No".
>
> [1] https://en.wikipedia.org/wiki/AES_instruction_set
>
> 2018-08-30  Thiago Macieira  
>
> * config/i386/i386.c (PTA_WESTMERE): Remove PTA_AES.
> (PTA_SKYLAKE): Add PTA_AES.
> (PTA_GOLDMONT): Likewise.

I opened:

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

and I will check it in for Thiago tomorrow.

-- 
H.J.
From afd1b863fcc0d29c5ce6fa68db7680286f63e6b2 Mon Sep 17 00:00:00 2001
From: Thiago Macieira 
Date: Thu, 21 Feb 2019 15:10:18 -0800
Subject: [PATCH] x86: (Reapply) Move AESNI generation to Skylake and Goldmont

This is a repeat of commit r263989, which commit r264052 accidentally
reverted.

2019-02-21  Thiago Macieira  

	PR target/89444
	* config/i386/i386.h (PTA_WESTMERE): Remove PTA_AES.
	(PTA_SKYLAKE): Add PTA_AES.
	(PTA_GOLDMONT): Likewise.
---
 gcc/config/i386/i386.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
index 4fd8bc40a34..2cb16d9fbf6 100644
--- a/gcc/config/i386/i386.h
+++ b/gcc/config/i386/i386.h
@@ -2360,7 +2360,7 @@ const wide_int_bitmask PTA_CORE2 = PTA_64BIT | PTA_MMX | PTA_SSE | PTA_SSE2
   | PTA_SSE3 | PTA_SSSE3 | PTA_CX16 | PTA_FXSR;
 const wide_int_bitmask PTA_NEHALEM = PTA_CORE2 | PTA_SSE4_1 | PTA_SSE4_2
   | PTA_POPCNT;
-const wide_int_bitmask PTA_WESTMERE = PTA_NEHALEM | PTA_AES | PTA_PCLMUL;
+const wide_int_bitmask PTA_WESTMERE = PTA_NEHALEM | PTA_PCLMUL;
 const wide_int_bitmask PTA_SANDYBRIDGE = PTA_WESTMERE | PTA_AVX | PTA_XSAVE
   | PTA_XSAVEOPT;
 const wide_int_bitmask PTA_IVYBRIDGE = PTA_SANDYBRIDGE | PTA_FSGSBASE
@@ -2369,7 +2369,7 @@ const wide_int_bitmask PTA_HASWELL = PTA_IVYBRIDGE | PTA_AVX2 | PTA_BMI
   | PTA_BMI2 | PTA_LZCNT | PTA_FMA | PTA_MOVBE | PTA_HLE;
 const wide_int_bitmask PTA_BROADWELL = PTA_HASWELL | PTA_ADX | PTA_PRFCHW
   | PTA_RDSEED;
-const wide_int_bitmask PTA_SKYLAKE = PTA_BROADWELL | PTA_CLFLUSHOPT
+const wide_int_bitmask PTA_SKYLAKE = PTA_BROADWELL | PTA_AES | PTA_CLFLUSHOPT
   | PTA_XSAVEC | PTA_XSAVES | PTA_SGX;
 const wide_int_bitmask PTA_SKYLAKE_AVX512 = PTA_SKYLAKE | PTA_AVX512F
   | PTA_AVX512CD | PTA_AVX512VL | PTA_AVX512BW | PTA_AVX512DQ | PTA_PKU
@@ -2387,7 +2387,7 @@ const wide_int_bitmask PTA_KNL = PTA_BROADWELL | PTA_AVX512PF | PTA_AVX512ER
   | PTA_AVX512F | PTA_AVX512CD;
 const wide_int_bitmask PTA_BONNELL = PTA_CORE2 | PTA_MOVBE;
 const wide_int_bitmask PTA_SILVERMONT = PTA_WESTMERE | PTA_MOVBE | PTA_RDRND;
-const wide_int_bitmask PTA_GOLDMONT = PTA_SILVERMONT | PTA_SHA | PTA_XSAVE
+const wide_int_bitmask PTA_GOLDMONT = PTA_SILVERMONT | PTA_AES | PTA_SHA | PTA_XSAVE
   | PTA_RDSEED | PTA_XSAVEC | PTA_XSAVES | PTA_CLFLUSHOPT | PTA_XSAVEOPT
   | PTA_FSGSBASE;
 const wide_int_bitmask PTA_GOLDMONT_PLUS = PTA_GOLDMONT | PTA_RDPID
-- 
2.20.1

[PATCH] x86: (Reapply) Move AESNI generation to Skylake and Goldmont

[Thiago Macieira]

This is a repeat of commit r263989, which commit r264052 accidentally
reverted.

Original commit message:

The instruction set first appeared with Westmere, but not all processors
in that and the next few generations have the instructions. According to
Wikipedia[1], the first generation in which all SKUs have AES
instructions are Skylake and Goldmont. I can't find any Skylake,
Kabylake, Kabylake-R or Cannon Lake currently listed at
https://ark.intel.com that says "Intel® AES New Instructions" "No".

[1] https://en.wikipedia.org/wiki/AES_instruction_set

2018-08-30  Thiago Macieira  

* config/i386/i386.c (PTA_WESTMERE): Remove PTA_AES.
(PTA_SKYLAKE): Add PTA_AES.
(PTA_GOLDMONT): Likewise.
---
 gcc/config/i386/i386.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
index 4fd8bc40a34..2cb16d9fbf6 100644
--- a/gcc/config/i386/i386.h
+++ b/gcc/config/i386/i386.h
@@ -2360,7 +2360,7 @@ const wide_int_bitmask PTA_CORE2 = PTA_64BIT | PTA_MMX | 
PTA_SSE | PTA_SSE2
   | PTA_SSE3 | PTA_SSSE3 | PTA_CX16 | PTA_FXSR;
 const wide_int_bitmask PTA_NEHALEM = PTA_CORE2 | PTA_SSE4_1 | PTA_SSE4_2
   | PTA_POPCNT;
-const wide_int_bitmask PTA_WESTMERE = PTA_NEHALEM | PTA_AES | PTA_PCLMUL;
+const wide_int_bitmask PTA_WESTMERE = PTA_NEHALEM | PTA_PCLMUL;
 const wide_int_bitmask PTA_SANDYBRIDGE = PTA_WESTMERE | PTA_AVX | PTA_XSAVE
   | PTA_XSAVEOPT;
 const wide_int_bitmask PTA_IVYBRIDGE = PTA_SANDYBRIDGE | PTA_FSGSBASE
@@ -2369,7 +2369,7 @@ const wide_int_bitmask PTA_HASWELL = PTA_IVYBRIDGE | 
PTA_AVX2 | PTA_BMI
   | PTA_BMI2 | PTA_LZCNT | PTA_FMA | PTA_MOVBE | PTA_HLE;
 const wide_int_bitmask PTA_BROADWELL = PTA_HASWELL | PTA_ADX | PTA_PRFCHW
   | PTA_RDSEED;
-const wide_int_bitmask PTA_SKYLAKE = PTA_BROADWELL | PTA_CLFLUSHOPT
+const wide_int_bitmask PTA_SKYLAKE = PTA_BROADWELL | PTA_AES | PTA_CLFLUSHOPT
   | PTA_XSAVEC | PTA_XSAVES | PTA_SGX;
 const wide_int_bitmask PTA_SKYLAKE_AVX512 = PTA_SKYLAKE | PTA_AVX512F
   | PTA_AVX512CD | PTA_AVX512VL | PTA_AVX512BW | PTA_AVX512DQ | PTA_PKU
@@ -2387,7 +2387,7 @@ const wide_int_bitmask PTA_KNL = PTA_BROADWELL | 
PTA_AVX512PF | PTA_AVX512ER
   | PTA_AVX512F | PTA_AVX512CD;
 const wide_int_bitmask PTA_BONNELL = PTA_CORE2 | PTA_MOVBE;
 const wide_int_bitmask PTA_SILVERMONT = PTA_WESTMERE | PTA_MOVBE | PTA_RDRND;
-const wide_int_bitmask PTA_GOLDMONT = PTA_SILVERMONT | PTA_SHA | PTA_XSAVE
+const wide_int_bitmask PTA_GOLDMONT = PTA_SILVERMONT | PTA_AES | PTA_SHA | 
PTA_XSAVE
   | PTA_RDSEED | PTA_XSAVEC | PTA_XSAVES | PTA_CLFLUSHOPT | PTA_XSAVEOPT
   | PTA_FSGSBASE;
 const wide_int_bitmask PTA_GOLDMONT_PLUS = PTA_GOLDMONT | PTA_RDPID
-- 
2.20.1

[C++ PATCH] PR c++/89422 - ICE with -g and lambda in default arg in template.

[Jason Merrill]

Here, we were trying to instantiate the default argument before setting
DECL_FRIEND_CONTEXT, so that the instantiated lambda ended up being treated
as part of the S template, which confused dwarf2out.

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

* pt.c (tsubst_function_decl): SET_DECL_FRIEND_CONTEXT sooner.
---
 gcc/cp/pt.c| 10 +-
 gcc/testsuite/g++.dg/cpp0x/lambda/lambda-defarg9.C | 10 ++
 gcc/cp/ChangeLog   |  5 +
 3 files changed, 20 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/lambda/lambda-defarg9.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index bd0a3d13bbe..76fb625a068 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -13088,6 +13088,11 @@ tsubst_function_decl (tree t, tree args, 
tsubst_flags_t complain,
set_constraints (r, ci);
   }
 
+  if (DECL_FRIEND_P (t) && DECL_FRIEND_CONTEXT (t))
+SET_DECL_FRIEND_CONTEXT (r,
+tsubst (DECL_FRIEND_CONTEXT (t),
+args, complain, in_decl));
+
   /* Set up the DECL_TEMPLATE_INFO for R.  There's no need to do
  this in the special friend case mentioned above where
  GEN_TMPL is NULL.  */
@@ -13149,11 +13154,6 @@ tsubst_function_decl (tree t, tree args, 
tsubst_flags_t complain,
   && !grok_op_properties (r, /*complain=*/true))
 return error_mark_node;
 
-  if (DECL_FRIEND_P (t) && DECL_FRIEND_CONTEXT (t))
-SET_DECL_FRIEND_CONTEXT (r,
-tsubst (DECL_FRIEND_CONTEXT (t),
-args, complain, in_decl));
-
   /* Possibly limit visibility based on template args.  */
   DECL_VISIBILITY (r) = VISIBILITY_DEFAULT;
   if (DECL_VISIBILITY_SPECIFIED (t))
diff --git a/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-defarg9.C 
b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-defarg9.C
new file mode 100644
index 000..f0436adfe9a
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-defarg9.C
@@ -0,0 +1,10 @@
+// PR c++/89422
+// { dg-do compile { target c++11 } }
+// { dg-additional-options -g }
+
+template  struct S
+{
+  friend void foo (int a = []{ return 0; }()) {}
+  int b;
+};
+S<0> t;
diff --git a/gcc/cp/ChangeLog b/gcc/cp/ChangeLog
index 228100ab21f..2f99f2b95c8 100644
--- a/gcc/cp/ChangeLog
+++ b/gcc/cp/ChangeLog
@@ -1,3 +1,8 @@
+2019-02-21  Jason Merrill  
+
+   PR c++/89422 - ICE with -g and lambda in default arg in template.
+   * pt.c (tsubst_function_decl): SET_DECL_FRIEND_CONTEXT sooner.
+
 2019-02-21  Jason Merrill  
 
PR c++/88419 - C++17 ICE with class template arg deduction.

base-commit: 147a31b69541c769274d59b0b587063e576fb974
-- 
2.20.1

[C++ PATCH] PR c++/88419 - C++17 ICE with class template arg deduction.

[Jason Merrill]

Just like in make_constrained_auto, we need to defer setting TYPE_CANONICAL
until we've set fields that will affect structural_comptypes.

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

* pt.c (make_template_placeholder): Set TYPE_CANONICAL after
CLASS_PLACEHOLDER_TEMPLATE.
---
 gcc/cp/pt.c   |  4 +++-
 .../g++.dg/cpp1z/class-deduction62.C  | 22 +++
 gcc/cp/ChangeLog  |  6 +
 3 files changed, 31 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp1z/class-deduction62.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index a212be8c747..bd0a3d13bbe 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -26619,8 +26619,10 @@ make_auto (void)
 tree
 make_template_placeholder (tree tmpl)
 {
-  tree t = make_auto_1 (auto_identifier, true);
+  tree t = make_auto_1 (auto_identifier, false);
   CLASS_PLACEHOLDER_TEMPLATE (t) = tmpl;
+  /* Our canonical type depends on the placeholder.  */
+  TYPE_CANONICAL (t) = canonical_type_parameter (t);
   return t;
 }
 
diff --git a/gcc/testsuite/g++.dg/cpp1z/class-deduction62.C 
b/gcc/testsuite/g++.dg/cpp1z/class-deduction62.C
new file mode 100644
index 000..2baa3acb8c1
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1z/class-deduction62.C
@@ -0,0 +1,22 @@
+// PR c++/88419
+// { dg-do compile { target c++17 } }
+
+template struct ref_view {
+  template ref_view(T&&);
+};
+
+template ref_view(R&) -> ref_view;
+
+struct ref_fn {
+  template auto operator()(R r) const
+noexcept(noexcept(ref_view{r}));
+};
+
+template struct indirect_view {
+  indirect_view(R);
+};
+
+struct indirect_fn {
+  template auto operator()(R r) const
+noexcept(noexcept(indirect_view{r}));
+};
diff --git a/gcc/cp/ChangeLog b/gcc/cp/ChangeLog
index 824d007d36c..228100ab21f 100644
--- a/gcc/cp/ChangeLog
+++ b/gcc/cp/ChangeLog
@@ -1,3 +1,9 @@
+2019-02-21  Jason Merrill  
+
+   PR c++/88419 - C++17 ICE with class template arg deduction.
+   * pt.c (make_template_placeholder): Set TYPE_CANONICAL after
+   CLASS_PLACEHOLDER_TEMPLATE.
+
 2019-02-21  Jakub Jelinek  
 
PR c++/89285

base-commit: 7f5c3ac2885e80c108b8f1e022b0eefa394fab82
-- 
2.20.1

[PATCH] avoid -Wabsolute-value in dead subexpressions (PR 89425)

[Martin Sebor]

Joseph noticed the -Wabsolute-value warning newly introduced in GCC
9 and included in -Wextra triggers on some unreachable subexpressions
in Glibc code that the C front end otherwise makes an effort to avoid
diagnosing.  The attached trivial patch guards the warning to avoid
these spurious instances.

Tested on x86_64-linux.

Similarly to other warnings like it, -Wabsolute-value still triggers
in unreachable statements but the only way to deal with those instances
would be to move all such warnings into the middle-end.

Martin
PR c/89425 - -Wabsolute-value warns in dead subexpressions

gcc/c/ChangeLog:

	PR c/89425
	* c-parser.c (sizeof_ptr_memacc_comptypes): Avoid warning in
	unreachable subexpressions.

gcc/testsuite/ChangeLog:

	PR c/89425
	* gcc.dg/Wabsolute-value.c: New test. 

Index: gcc/c/c-parser.c
===
--- gcc/c/c-parser.c	(revision 269041)
+++ gcc/c/c-parser.c	(working copy)
@@ -9374,6 +9374,10 @@ sizeof_ptr_memacc_comptypes (tree type1, tree type
 static void
 warn_for_abs (location_t loc, tree fndecl, tree arg)
 {
+  /* Avoid warning in unreachable subexpressions.  */
+  if (c_inhibit_evaluation_warnings)
+return;
+
   tree atype = TREE_TYPE (arg);
 
   /* Casts from pointers (and thus arrays and fndecls) will generate
Index: gcc/testsuite/gcc.dg/Wabsolute-value.c
===
--- gcc/testsuite/gcc.dg/Wabsolute-value.c	(nonexistent)
+++ gcc/testsuite/gcc.dg/Wabsolute-value.c	(working copy)
@@ -0,0 +1,57 @@
+/* PR c/89425 - -Wabsolute-value warns in dead subexpressions
+   { dg-do compile }
+   { dg-options "-Wabsolute-value -ftrack-macro-expansion=0" } */
+
+struct Vals
+{
+  signed char sc;
+  signed short ss;
+  signed int si;
+  signed long sl;
+  signed long long sll;
+
+  unsigned char uc;
+  unsigned short us;
+  unsigned int ui;
+  unsigned long ul;
+  unsigned long long ull;
+
+  float f;
+  double d;
+  long double ld;
+};
+
+#define abs(x) __builtin_abs (x)
+#define labs(x)__builtin_labs (x)
+#define llabs(x)   __builtin_llabs (x)
+
+#define fabsf(x)   __builtin_fabsf (x)
+#define fabs(x)__builtin_fabs (x)
+
+
+void tst_warn (struct Vals *p)
+{
+  /* Verify that "-Wabsolute-value is issued for subexpressions
+ that are evaluated.  */
+
+  p->uc =  0 ? abs (p->sc) : abs (p->uc); /* { dg-warning "\\\[-Wabsolute-value]" } */
+  p->us =  0 ? abs (p->ss) : abs (p->us); /* { dg-warning "\\\[-Wabsolute-value]" } */
+  p->ui =  0 ? abs (p->si) : abs (p->ui); /* { dg-warning "\\\[-Wabsolute-value]" } */
+  p->ul =  0 ? labs (p->sl) : labs (p->ul);   /* { dg-warning "\\\[-Wabsolute-value]" } */
+  p->ull = 0 ? llabs (p->sll) : llabs (p->ull);   /* { dg-warning "\\\[-Wabsolute-value]" } */
+
+  p->d   = 0 ? fabs (p->d) : fabsf (p->d);/* { dg-warning "\\\[-Wabsolute-value]" } */
+}
+
+void tst_no_warn (struct Vals *p)
+{
+  /* Verify that "-Wabsolute-value is not issued for subexpressions
+ that are not evaluated.  */
+
+  p->uc =  0 ? abs (p->uc) : abs (p->sc);
+  p->us =  0 ? abs (p->us) : abs (p->ss);
+  p->ui =  0 ? abs (p->ui) : abs (p->si);
+  p->ul =  0 ? labs (p->ul) : labs (p->sl);
+  p->ull = 0 ? llabs (p->ull) : llabs (p->sll);
+  p->d   = 0 ? fabsf (p->d) : fabs (p->d);
+}

Re: PING [PATCH] fix ICE in __builtin_has_attribute (PR 88383 and 89288)

[Martin Sebor]

On 2/21/19 3:42 PM, Jeff Law wrote:

On 2/21/19 3:39 PM, Martin Sebor wrote:

On 2/21/19 1:27 PM, Jeff Law wrote:

On 2/21/19 1:12 PM, Martin Sebor wrote:

On 2/21/19 12:08 PM, Jeff Law wrote:

On 2/18/19 7:53 PM, Martin Sebor wrote:

Please let me know what it will take to get the fix for these two
issues approved.  I've answered the questions so I don't know what
else I'm expected to do here.

     https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00793.html

I think there is still a fundamental disagreement about whether or not
this should be handling expressions.  Without an agreement on that it's
hard to see how this could go forward.


I think it's wrong to hold up a fix for an ICE because you don't
like the current design.  The built-in successfully handles common
expressions (see c-c++-common/builtin-has-attribute-5.c).  It just
fails for some of the less common ones.  Not fixing those will only
penalize users who run into the ICE, and cast a bad light on
the quality of the release.   Any design questions should be
settled separately of these ICEs (should have been when
the feature was being reviewed).

That said, I have explained the rationale for the current design.
Neither you nor Jakub has explained what you find wrong with it or
why either of your alternatives is preferable.  You said it should
be an error to apply the built-in to expressions (why?).  Jakub
thought there perhaps should be two built-ins, one for expressions
and another for decls.  His rationale?  The current design is not
good.  Clearly,  the two of you don't agree on what you'd like to
see; the only thing you agree on is that you don't like what's
there now.  What do you expect me to do with that, now at the end
of stage 4?

Fix the ice in another way.  Handling expressions here seems
fundamentally wrong.  ISTM that making this query on an expression
should result in an immediate error.


Sorry but "it seems wrong" is not a compelling argument.  You need
to explain what you think is wrong with it.

Attributes on expressions seems fundamentally broken.  Jakub has raised
this issue as well.  If you want things to move forward you need to
address this fundamental issue.


I need to understand what this fundamental problem is.


The built-in is modeled on the sizeof, alignof, and typeof operators.
The manual documents like this:

Understood, but that makes it rather different from most (all?) other
attributes.  Attributes apply to decls and types, not expressions.



   bool __builtin_has_attribute (type-or-expression, attribute)

   ...The type-or-expression argument is subject to the same
   restrictions as the argument to typeof (see Typeof).

It was reviewed and approved with no objections to the API.


ANd I botched that.  Mistakes happen.


It was also reviewed by Joseph and Jason.

Can you show how one would query for attribute packed in the example
I gave if the built-in were to reject expressions:

  struct S {
int a[1] __attribute__ ((packed));
  };

  void f (struct S *p)
  {
_Static_assert (__builtin_has_attribute (p->a, packed));
  }

In any event, if there is a problem I will certainly fix it.  But
I need to know what the problem is first.

Martin

Re: Patch RFC: Avoid recursive insert into const_desc_htab

[Ian Lance Taylor]

On Thu, Feb 21, 2019 at 1:57 AM Richard Biener
 wrote:
>
> On Wed, Feb 20, 2019 at 6:53 PM Ian Lance Taylor  wrote:
> >
> > The underlying cause of PR 89170 is a bug that appears to have existed
> > since 2001, when the function decode_addr_const was changed to call
> > output_constant_def.  The problem is that output_constant_def calls
> > compare_constant, and when compare_constant sees an ADDR_EXPR, it
> > calls decode_addr_const.  So it is possible for output_constant_def to
> > call itself recursively while adding a value to the hash table.  This
> > only happens if there are already some constants in the hash table
> > with the same hash code, because that is the only case in which
> > compare_constant can call decode_addr_constant.  This works fine if
> > the value whose address is taken is already in the hash table.  And it
> > works fine if the address is not in the hash table, but adding the
> > address does not cause the hash table to grow.
> >
> > But if we call output_constant_def with a constant that includes an
> > ADDR_EXPR, and if there is already a constant in the hash table with
> > the same hash code, and if decode_addr_constant calls
> > output_constant_def recursively with a constant that is not already in
> > the hash table, and if adding that constant causes the hash table to
> > grow, then the outer call to output_constant_def will wind up looking
> > at the wrong hash bucket.  The effect is that output_constant_def will
> > return an rtx for a different constant.
> >
> > This unlikely sequence of events actually happened building libgo's
> > net/http test on PPC64, causing a miscompilation leading to a test
> > failure filed as PR 89170.
> >
> > I plan to commit this patch to fix the problem.  I didn't add a test
> > case since the sequence of events is so hard to recreate.  I added a
> > check that will detect any future recursive insertion into the hash
> > table.
> >
> > Bootstrapped and tested on x86_64-pc-linux-gnu.  Since I haven't
> > looked at this part of the code in many years, I'll wait a bit to see
> > if anybody has any comments on the patch.
>
> Looks reasonable.  Factoring the common code in
> output_constant_def and tree_output_constant_def might be
> worth it.

Makes sense.  Done.  Rebootstrapped, retested, and committed as follows.

Ian

2019-02-21  Ian Lance Taylor  

PR go/89170
* varasm.c (decode_addr_const): Call lookup_constant_def rather
than output_constant_def.
(add_constant_to_table): New static function.
(output_constant_def): Call add_constant_to_table.
(tree_output_constant_def): Likewise.
Index: gcc/varasm.c
===
--- gcc/varasm.c(revision 268949)
+++ gcc/varasm.c(working copy)
@@ -2961,7 +2961,9 @@ decode_addr_const (tree exp, struct addr
 case COMPLEX_CST:
 case CONSTRUCTOR:
 case INTEGER_CST:
-  x = output_constant_def (target, 1);
+  x = lookup_constant_def (target);
+  /* Should have been added by output_addressed_constants.  */
+  gcc_assert (x);
   break;
 
 case INDIRECT_REF:
@@ -3424,6 +3426,43 @@ build_constant_desc (tree exp)
   return desc;
 }
 
+/* Subroutine of output_constant_def and tree_output_constant_def:
+   Add a constant to the hash table that tracks which constants
+   already have labels.  */
+
+static constant_descriptor_tree *
+add_constant_to_table (tree exp)
+{
+  /* The hash table methods may call output_constant_def for addressed
+ constants, so handle them first.  */
+  output_addressed_constants (exp);
+
+  /* Sanity check to catch recursive insertion.  */
+  static bool inserting;
+  gcc_assert (!inserting);
+  inserting = true;
+
+  /* Look up EXP in the table of constant descriptors.  If we didn't
+ find it, create a new one.  */
+  struct constant_descriptor_tree key;
+  key.value = exp;
+  key.hash = const_hash_1 (exp);
+  constant_descriptor_tree **loc
+= const_desc_htab->find_slot_with_hash (, key.hash, INSERT);
+
+  inserting = false;
+
+  struct constant_descriptor_tree *desc = *loc;
+  if (!desc)
+{
+  desc = build_constant_desc (exp);
+  desc->hash = key.hash;
+  *loc = desc;
+}
+
+  return desc;
+}
+
 /* Return an rtx representing a reference to constant data in memory
for the constant expression EXP.
 
@@ -3440,24 +3479,7 @@ build_constant_desc (tree exp)
 rtx
 output_constant_def (tree exp, int defer)
 {
-  struct constant_descriptor_tree *desc;
-  struct constant_descriptor_tree key;
-
-  /* Look up EXP in the table of constant descriptors.  If we didn't find
- it, create a new one.  */
-  key.value = exp;
-  key.hash = const_hash_1 (exp);
-  constant_descriptor_tree **loc
-= const_desc_htab->find_slot_with_hash (, key.hash, INSERT);
-
-  desc = *loc;
-  if (desc == 0)
-{
-  desc = build_constant_desc (exp);
-  desc->hash = key.hash;
-  *loc = desc;
-}
-
+  struct constant_descriptor_tree *desc = add_constant_to_table (exp);
   

Re: [PATCH, GCC, AArch64] Fix a couple of bugs in BTI

[James Greenhalgh]

On Thu, Feb 21, 2019 at 06:19:10AM -0600, Sudakshina Das wrote:
> Hi
> 
> While doing more testing I found a couple of issues with my BTI patches. 
> This patch fixes them:
> 1) Remove a reference to return address key. The original patch was 
> written based on a different not yet committed patch ([PATCH 
> 3/3][GCC][AARCH64] Add support for pointer authentication B key) and I 
> missed out on cleaning this up. This is hidden behind the configuration 
> option and thus went unnoticed.
> 2) Add a missed case for adding the BTI instruction in thunk functions.
> 
> Bootstrapped on aarch64-none-linux-gnu and regression tested on 
> aarch64-none-elf with configuration turned on.

OK.

Thanks,
James

> 
> gcc/ChangeLog:
> 
> 2019-xx-xx  Sudakshina Das  
> 
>   * config/aarch64/aarch64.c (aarch64_output_mi_thunk): Add bti
>   instruction if enabled.
>   (aarch64_override_options): Remove reference to return address
>   key.
> 
> 
> Is this ok for trunk?
> Sudi

Re: [PATCH 1/2][GCC][AArch64] Update Armv8.4-a's FP16 FML intrinsics

[James Greenhalgh]

On Wed, Feb 20, 2019 at 08:00:13AM -0600, Tamar Christina wrote:
> Hi All,
> 
> This patch updates the Armv8.4-a FP16 FML intrinsics's suffixes from u32 to 
> f16
> to be more consistent with the naming convention for intrinsics.
> 
> The specifications for these intrinsics have not been published yet so we do
> not need to maintain the old names.
> 
> The patch was created with the following script:
> 
> grep -lIE "(vfml[as].+)_u32" -r gcc/ | grep -iEv ".+Changelog.*" \
>   | xargs sed -i -E -e "s/(vfml[as].+)_u32/\1_f16/g"

Big bonus points for including this!

> Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
> 
> Ok for trunk? and eventual backport to GCC 8?

Woops.

Yes, OK for trunk and backport it please.

Thanks,
James

> gcc/ChangeLog:
> 
> 2019-02-20  Tamar Christina  
> 
>   * config/aarch64/arm_neon.h (vfmlal_low_u32, vfmlsl_low_u32,
>   vfmlalq_low_u32, vfmlslq_low_u32, vfmlal_high_u32, vfmlsl_high_u32,
>   vfmlalq_high_u32, vfmlslq_high_u32, vfmlal_lane_low_u32,
>   vfmlsl_lane_low_u32, vfmlal_laneq_low_u32, vfmlsl_laneq_low_u32,
>   vfmlalq_lane_low_u32, vfmlslq_lane_low_u32, vfmlalq_laneq_low_u32,
>   vfmlslq_laneq_low_u32, vfmlal_lane_high_u32, vfmlsl_lane_high_u32,
>   vfmlal_laneq_high_u32, vfmlsl_laneq_high_u32, vfmlalq_lane_high_u32,
>   vfmlslq_lane_high_u32, vfmlalq_laneq_high_u32, vfmlslq_laneq_high_u32):
>   Rename ...
>   (vfmlal_low_f16, vfmlsl_low_f16, vfmlalq_low_f16, vfmlslq_low_f16,
>   vfmlal_high_f16, vfmlsl_high_f16, vfmlalq_high_f16, vfmlslq_high_f16,
>   vfmlal_lane_low_f16, vfmlsl_lane_low_f16, vfmlal_laneq_low_f16,
>   vfmlsl_laneq_low_f16, vfmlalq_lane_low_f16, vfmlslq_lane_low_f16,
>   vfmlalq_laneq_low_f16, vfmlslq_laneq_low_f16, vfmlal_lane_high_f16,
>   vfmlsl_lane_high_f16, vfmlal_laneq_high_f16, vfmlsl_laneq_high_f16,
>   vfmlalq_lane_high_f16, vfmlslq_lane_high_f16, vfmlalq_laneq_high_f16,
>   vfmlslq_laneq_high_f16): ... To this.
> 
> gcc/testsuite/ChangeLog:
> 
> 2019-02-20  Tamar Christina  
> 
>   * gcc.target/aarch64/fp16_fmul_high.h (test_vfmlal_high_u32,
>   test_vfmlalq_high_u32, test_vfmlsl_high_u32, test_vfmlslq_high_u32):
>   Rename ...
>   (test_vfmlal_high_f16, test_vfmlalq_high_f16, test_vfmlsl_high_f16,
>   test_vfmlslq_high_f16): ... To this.
>   * gcc.target/aarch64/fp16_fmul_lane_high.h (test_vfmlal_lane_high_u32,
>   tets_vfmlsl_lane_high_u32, test_vfmlal_laneq_high_u32,
>   test_vfmlsl_laneq_high_u32, test_vfmlalq_lane_high_u32,
>   test_vfmlslq_lane_high_u32, test_vfmlalq_laneq_high_u32,
>   test_vfmlslq_laneq_high_u32): Rename ...
>   (test_vfmlal_lane_high_f16, tets_vfmlsl_lane_high_f16,
>   test_vfmlal_laneq_high_f16, test_vfmlsl_laneq_high_f16,
>   test_vfmlalq_lane_high_f16, test_vfmlslq_lane_high_f16,
>   test_vfmlalq_laneq_high_f16, test_vfmlslq_laneq_high_f16): ... To this.
>   * gcc.target/aarch64/fp16_fmul_lane_low.h (test_vfmlal_lane_low_u32,
>   test_vfmlsl_lane_low_u32, test_vfmlal_laneq_low_u32,
>   test_vfmlsl_laneq_low_u32, test_vfmlalq_lane_low_u32,
>   test_vfmlslq_lane_low_u32, test_vfmlalq_laneq_low_u32,
>   test_vfmlslq_laneq_low_u32): Rename ...
>   (test_vfmlal_lane_low_f16, test_vfmlsl_lane_low_f16,
>   test_vfmlal_laneq_low_f16, test_vfmlsl_laneq_low_f16,
>   test_vfmlalq_lane_low_f16, test_vfmlslq_lane_low_f16,
>   test_vfmlalq_laneq_low_f16, test_vfmlslq_laneq_low_f16): ... To this.
>   * gcc.target/aarch64/fp16_fmul_low.h (test_vfmlal_low_u32,
>   test_vfmlalq_low_u32, test_vfmlsl_low_u32, test_vfmlslq_low_u32):
>   Rename ...
>   (test_vfmlal_low_f16, test_vfmlalq_low_f16, test_vfmlsl_low_f16,
>   test_vfmlslq_low_f16): ... To This.
>   * lib/target-supports.exp
>   (check_effective_target_arm_fp16fml_neon_ok_nocache): Update test.
> 
> -- 

> diff --git a/gcc/config/aarch64/arm_neon.h b/gcc/config/aarch64/arm_neon.h
> index 
> f405a325cf5f3f8970e5f4b78322335c280fa7a4..314ef30187d1ba1882eaf5c610770d380344e920
>  100644
> --- a/gcc/config/aarch64/arm_neon.h
> +++ b/gcc/config/aarch64/arm_neon.h
> @@ -33777,63 +33777,63 @@ vcmlaq_rot270_laneq_f32 (float32x4_t __r, 
> float32x4_t __a, float32x4_t __b,
>  
>  __extension__ extern __inline float32x2_t
>  __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
> -vfmlal_low_u32 (float32x2_t __r, float16x4_t __a, float16x4_t __b)
> +vfmlal_low_f16 (float32x2_t __r, float16x4_t __a, float16x4_t __b)
>  {
>return __builtin_aarch64_fmlal_lowv2sf (__r, __a, __b);
>  }
>  
>  __extension__ extern __inline float32x2_t
>  __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
> -vfmlsl_low_u32 (float32x2_t __r, float16x4_t __a, float16x4_t __b)
> +vfmlsl_low_f16 (float32x2_t __r, float16x4_t __a, float16x4_t __b)
>  {
>return __builtin_aarch64_fmlsl_lowv2sf (__r, __a, __b);
>  }
>  
>  __extension__ extern __inline float32x4_t
>  

Re: [PATCH][AArch64] Add support for Neoverse E1

[James Greenhalgh]

On Thu, Feb 21, 2019 at 11:43:08AM -0600, Kyrill Tkachov wrote:
> Hi all,
> 
> This patch adds -mcpu and -mtune support for the Neoverse E1 CPU [1].
> The new option is -mcpu=neoverse-e1.
> Bootstrapped and tested on aarch64-none-linux-gnu.

OK.

Thanks,
James

> [1] 
> https://community.arm.com/processors/b/blog/posts/arm-neoverse-e1-platform-empowering-the-infrastructure-to-meet-next-generation-throughput-demands
> 
> 2019-02-21  Kyrylo Tkachov  
> 
>      * config/aarch64/aarch64-cores.def (neoverse-e1): Define.
>      * config/aarch64/aarch64-tune.md: Regenerate.
>      * doc/invoke.texi (AArch64 Options): Document neoverse-e1 -mcpu option.

> diff --git a/gcc/config/aarch64/aarch64-cores.def 
> b/gcc/config/aarch64/aarch64-cores.def
> index 
> b0c7d2f23ace1e3c3a89f4e3ab10c9ad08f56b22..ed56e5eded13664597343659db859c5ed481627d
>  100644
> --- a/gcc/config/aarch64/aarch64-cores.def
> +++ b/gcc/config/aarch64/aarch64-cores.def
> @@ -102,6 +102,7 @@ AARCH64_CORE("cortex-a75",  cortexa75, cortexa57, 8_2A,  
> AARCH64_FL_FOR_ARCH8_2
>  AARCH64_CORE("cortex-a76",  cortexa76, cortexa57, 8_2A,  
> AARCH64_FL_FOR_ARCH8_2 | AARCH64_FL_F16 | AARCH64_FL_RCPC | 
> AARCH64_FL_DOTPROD, cortexa72, 0x41, 0xd0b, -1)
>  AARCH64_CORE("ares",  ares, cortexa57, 8_2A,  AARCH64_FL_FOR_ARCH8_2 | 
> AARCH64_FL_F16 | AARCH64_FL_RCPC | AARCH64_FL_DOTPROD | AARCH64_FL_PROFILE, 
> neoversen1, 0x41, 0xd0c, -1)
>  AARCH64_CORE("neoverse-n1",  neoversen1, cortexa57, 8_2A,  
> AARCH64_FL_FOR_ARCH8_2 | AARCH64_FL_F16 | AARCH64_FL_RCPC | 
> AARCH64_FL_DOTPROD | AARCH64_FL_PROFILE, neoversen1, 0x41, 0xd0c, -1)
> +AARCH64_CORE("neoverse-e1",  neoversee1, cortexa53, 8_2A,  
> AARCH64_FL_FOR_ARCH8_2 | AARCH64_FL_F16 | AARCH64_FL_RCPC | 
> AARCH64_FL_DOTPROD | AARCH64_FL_SSBS, cortexa53, 0x41, 0xd4a, -1)
>  
>  /* HiSilicon ('H') cores. */
>  AARCH64_CORE("tsv110",  tsv110, cortexa57, 8_2A,  AARCH64_FL_FOR_ARCH8_2 | 
> AARCH64_FL_CRYPTO | AARCH64_FL_F16 | AARCH64_FL_AES | AARCH64_FL_SHA2, 
> tsv110,   0x48, 0xd01, -1)
> diff --git a/gcc/config/aarch64/aarch64-tune.md 
> b/gcc/config/aarch64/aarch64-tune.md
> index 
> 5b1341525e9c2e3fe6306e7c9fef41f5d658420c..2b1ec85ae3190ec62f70d8abacd88e825244f2b1
>  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"
> - 
> "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,ares,neoversen1,tsv110,saphira,cortexa57cortexa53,cortexa72cortexa53,cortexa73cortexa35,cortexa73cortexa53,cortexa75cortexa55,cortexa76cortexa55"
> + 
> "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,ares,neoversen1,neoversee1,tsv110,saphira,cortexa57cortexa53,cortexa72cortexa53,cortexa73cortexa35,cortexa73cortexa53,cortexa75cortexa55,cortexa76cortexa55"
>   (const (symbol_ref "((enum attr_tune) aarch64_tune)")))
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index 
> 8ecc28c4acccd619ff9dcc25202fcf87582145a4..24513970e0508611c4810aabbb6089dca7d5501c
>  100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -15771,10 +15771,11 @@ performance of the code.  Permissible values for 
> this option are:
>  @samp{generic}, @samp{cortex-a35}, @samp{cortex-a53}, @samp{cortex-a55},
>  @samp{cortex-a57}, @samp{cortex-a72}, @samp{cortex-a73}, @samp{cortex-a75},
>  @samp{cortex-a76}, @samp{ares}, @samp{exynos-m1}, @samp{emag}, @samp{falkor},
> -@samp{neoverse-n1},@samp{qdf24xx}, @samp{saphira}, @samp{phecda}, 
> @samp{xgene1},
> -@samp{vulcan}, @samp{octeontx}, @samp{octeontx81},  @samp{octeontx83},
> -@samp{thunderx}, @samp{thunderxt88}, @samp{thunderxt88p1}, 
> @samp{thunderxt81},
> -@samp{tsv110}, @samp{thunderxt83}, @samp{thunderx2t99},
> +@samp{neoverse-e1},@samp{neoverse-n1},@samp{qdf24xx}, @samp{saphira},
> +@samp{phecda}, @samp{xgene1}, @samp{vulcan}, @samp{octeontx},
> +@samp{octeontx81},  @samp{octeontx83}, @samp{thunderx}, @samp{thunderxt88},
> +@samp{thunderxt88p1}, @samp{thunderxt81}, @samp{tsv110},
> +@samp{thunderxt83}, @samp{thunderx2t99},
>  @samp{cortex-a57.cortex-a53}, @samp{cortex-a72.cortex-a53},
>  @samp{cortex-a73.cortex-a35}, @samp{cortex-a73.cortex-a53},
>  @samp{cortex-a75.cortex-a55}, @samp{cortex-a76.cortex-a55}

Re: PING [PATCH] fix ICE in __builtin_has_attribute (PR 88383 and 89288)

[Jeff Law]

On 2/21/19 3:39 PM, Martin Sebor wrote:
> On 2/21/19 1:27 PM, Jeff Law wrote:
>> On 2/21/19 1:12 PM, Martin Sebor wrote:
>>> On 2/21/19 12:08 PM, Jeff Law wrote:
 On 2/18/19 7:53 PM, Martin Sebor wrote:
> Please let me know what it will take to get the fix for these two
> issues approved.  I've answered the questions so I don't know what
> else I'm expected to do here.
>
>     https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00793.html
 I think there is still a fundamental disagreement about whether or not
 this should be handling expressions.  Without an agreement on that it's
 hard to see how this could go forward.
>>>
>>> I think it's wrong to hold up a fix for an ICE because you don't
>>> like the current design.  The built-in successfully handles common
>>> expressions (see c-c++-common/builtin-has-attribute-5.c).  It just
>>> fails for some of the less common ones.  Not fixing those will only
>>> penalize users who run into the ICE, and cast a bad light on
>>> the quality of the release.   Any design questions should be
>>> settled separately of these ICEs (should have been when
>>> the feature was being reviewed).
>>>
>>> That said, I have explained the rationale for the current design.
>>> Neither you nor Jakub has explained what you find wrong with it or
>>> why either of your alternatives is preferable.  You said it should
>>> be an error to apply the built-in to expressions (why?).  Jakub
>>> thought there perhaps should be two built-ins, one for expressions
>>> and another for decls.  His rationale?  The current design is not
>>> good.  Clearly,  the two of you don't agree on what you'd like to
>>> see; the only thing you agree on is that you don't like what's
>>> there now.  What do you expect me to do with that, now at the end
>>> of stage 4?
>> Fix the ice in another way.  Handling expressions here seems
>> fundamentally wrong.  ISTM that making this query on an expression
>> should result in an immediate error.
> 
> Sorry but "it seems wrong" is not a compelling argument.  You need
> to explain what you think is wrong with it.
Attributes on expressions seems fundamentally broken.  Jakub has raised
this issue as well.  If you want things to move forward you need to
address this fundamental issue.

> 
> The built-in is modeled on the sizeof, alignof, and typeof operators.
> The manual documents like this:
Understood, but that makes it rather different from most (all?) other
attributes.  Attributes apply to decls and types, not expressions.

> 
>   bool __builtin_has_attribute (type-or-expression, attribute)
> 
>   ...The type-or-expression argument is subject to the same
>   restrictions as the argument to typeof (see Typeof).
> 
> It was reviewed and approved with no objections to the API. 

ANd I botched that.  Mistakes happen.


Jeff

Re: [PATCH][AArch64] Add support for Neoverse N1

[James Greenhalgh]

On Thu, Feb 21, 2019 at 11:42:56AM -0600, Kyrill Tkachov wrote:
> Hi all,
> 
> This patch adds support for the Neoverse N1 CPU [1]. This was supported 
> in GCC earlier through the codename Ares,
> which it now replaces. -mcpu=ares is still accepted as there's been a 
> binutils release supporting it,
> but the internal structures are renamed to use Neoverse N1-related 
> identifiers.
> 
> Bootstrapped and tested on aarch64-none-linux-gnu.
> 
> Ok for trunk?

OK.

Thanks,
James

> 
> [1] 
> https://community.arm.com/processors/b/blog/posts/arm-neoverse-n1-platform-accelerating-the-transformation-to-a-scalable-cloud-to-edge-infrastructure
> 
> 2019-02-21  Kyrylo Tkachov  
> 
>      * config/aarch64/aarch64.c (ares_tunings): Rename to...
>      (neoversen1_tunings): ... This.
>      * config/aarch64/aarch64-cores.def (ares): Change tuning to the above.
>      (neoverse-n1): New CPU.
>      * config/aarch64/aarch64-tune.md: Regenerate.
>      * doc/invoke.txt (AArch64 Options): Document neoverse-n1.
> 

Re: PING [PATCH] fix ICE in __builtin_has_attribute (PR 88383 and 89288)

[Martin Sebor]

On 2/21/19 1:27 PM, Jeff Law wrote:

On 2/21/19 1:12 PM, Martin Sebor wrote:

On 2/21/19 12:08 PM, Jeff Law wrote:

On 2/18/19 7:53 PM, Martin Sebor wrote:

Please let me know what it will take to get the fix for these two
issues approved.  I've answered the questions so I don't know what
else I'm expected to do here.

    https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00793.html

I think there is still a fundamental disagreement about whether or not
this should be handling expressions.  Without an agreement on that it's
hard to see how this could go forward.


I think it's wrong to hold up a fix for an ICE because you don't
like the current design.  The built-in successfully handles common
expressions (see c-c++-common/builtin-has-attribute-5.c).  It just
fails for some of the less common ones.  Not fixing those will only
penalize users who run into the ICE, and cast a bad light on
the quality of the release.   Any design questions should be
settled separately of these ICEs (should have been when
the feature was being reviewed).

That said, I have explained the rationale for the current design.
Neither you nor Jakub has explained what you find wrong with it or
why either of your alternatives is preferable.  You said it should
be an error to apply the built-in to expressions (why?).  Jakub
thought there perhaps should be two built-ins, one for expressions
and another for decls.  His rationale?  The current design is not
good.  Clearly,  the two of you don't agree on what you'd like to
see; the only thing you agree on is that you don't like what's
there now.  What do you expect me to do with that, now at the end
of stage 4?

Fix the ice in another way.  Handling expressions here seems
fundamentally wrong.  ISTM that making this query on an expression
should result in an immediate error.


Sorry but "it seems wrong" is not a compelling argument.  You need
to explain what you think is wrong with it.

The built-in is modeled on the sizeof, alignof, and typeof operators.
The manual documents like this:

  bool __builtin_has_attribute (type-or-expression, attribute)

  ...The type-or-expression argument is subject to the same
  restrictions as the argument to typeof (see Typeof).

It was reviewed and approved with no objections to the API.  So it
seems that it's up to you to provide a convincing argument that this
was the wrong choice.  What serious problems do you think it might
cause that justify rejecting expressions, and how will users overcome
this limitation?

I already explained the rationale behind the decision to have
the built-in accept expressions: to be able to easily query for
type attributes in expressions such as:

  typedef __attribute__ ((may_alias)) int* BadInt;

  void f (BadInt *p)
  {
_Static_assert (__builtin_has_attribute (*p, may_alias));
  }

or

  struct S {
int a[1] __attribute__ ((packed));
  };

  void f (struct S *p)
  {
_Static_assert (__builtin_has_attribute (p->a, packed));
  }

or even

_Static_assert (__builtin_has_attribute (p->a[0], packed));

If the built-in rejects expressions, I don't see how one would
query for these properties.

Martin

Re: [PATCH][GCC][AArch64] Fix command line options canonicalization version #2. (PR target/88530)

[James Greenhalgh]

On Wed, Feb 20, 2019 at 08:00:38AM -0600, Tamar Christina wrote:
> Hi All,
> 
> Commandline options on AArch64 don't get canonicalized into the smallest
> possible set before output to the assembler. This means that overlapping 
> feature
> sets are emitted with superfluous parts.
> 
> Normally this isn't an issue, but in the case of crypto we have retro-actively
> split it into aes and sha2. We need to emit only +crypto to the assembler
> so old assemblers continue to work.
> 
> Because of how -mcpu=native and -march=native work they end up enabling all
> feature bits. Instead we need to get the smallest possible set, which would 
> also
> fix the problem with older the assemblers and the retro-active split.
> 
> The function that handles this is called quite often.  It is called for any
> push/pop options or attribute that changes arch, cpu etc.  In order to not 
> make
> this search for the smallest set too expensive we sort the options based on 
> the
> number of features (bits) they enable.  This allows us to process the list
> linearly instead of quadratically (Once we have enabled a feature, we know 
> that
> anything else that enables it can be ignored.  By sorting we'll get the 
> biggest
> groups first and thus the smallest combination of commandline flags).
> 
> The Option handling structures have been extended to have a boolean to 
> indicate
> whether the option is synthetic, with that I mean if the option flag itself
> enables a new feature.
> 
> e.g. +crypto isn't an actual feature, it just enables other features, but 
> others
> like +rdma enable multiple dependent features but is itself also a feature.
> 
> There are two ways to solve this.
> 
> 1) Either have the options that are feature bits also turn themselves on, e.g.
>change rdma to turn on FP, SIMD and RDMA as dependency bits.
> 
> 2) Make a distinction between these two different type of features and have 
> the
>framework handle it correctly.
> 
> Even though it's more code I went for the second approach, as it's the one
> that'll be less fragile (people can't forget it) and gives the least 
> surprises.
> 
> Effectively this patch changes the following:
> 
> The values before the => are the old compiler and after the => the new code.
> 
> -march=armv8.2-a+crypto+sha2 => -march=armv8.2-a+crypto
> -march=armv8.2-a+sha2+aes => -march=armv8.2-a+crypto
> 
> The remaining behaviors stay the same.
> 
> Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
> 
> Ok for trunk?

OK, but I don't understand why the CRC special case is needed. My copy of
the Arm Architecture Reference Manual suggests that all versions of the
architceture from ARmv8.1-A are required to implement the CRC32 extension.
Is there some old assembler that doesn't honour that? Whatever is driving
that requirement could usefully be added to the comments.

I find it very hard to believe that this code is what we need for correct
behaviour on AArch64; this level of complexity implies we're doing something
very wrong with either the definition or the implementation of these features
bits which makes it hard for us to maintain, and hard for users and dependent
tools (e.g. assemblers) to know what to expect from the compiler.

I've seen a number of bugs in this code recently. While I appreciate your
patch for fixing one of them, I find the cases and expectations so hard
to reason about that I can't say I am sure we are now bug free.

OK for trunk as an improvement over today, and to help us get towards a
release; but I'm very unhappy with this corner of the compiler!

Thanks,
James

> gcc/ChangeLog:
> 
> 2019-02-20  Tamar Christina  
> 
>   PR target/88530
>   * common/config/aarch64/aarch64-common.c
>   (struct aarch64_option_extension): Add is_synthetic.
>   (all_extensions): Use it.
>   (TARGET_OPTION_INIT_STRUCT): Define hook.
>   (struct gcc_targetm_common): Moved to end.
>   (all_extensions_by_on): New.
>   (opt_ext_cmp, typedef opt_ext): New.
>   (aarch64_option_init_struct): New.
>   (aarch64_contains_opt): New.
>   (aarch64_get_extension_string_for_isa_flags): Output smallest set.
>   * config/aarch64/aarch64-option-extensions.def
>   (AARCH64_OPT_EXTENSION): Explicitly include AES and SHA2 in crypto.
>   (fp, simd, crc, lse, fp16, rcpc, rdma, dotprod, aes, sha2, sha3,
>   sm4, fp16fml, sve, profile, rng, memtag, sb, ssbs, predres):
>   Set is_synthetic to false.
>   (crypto): Set is_synthetic to true.
>   * config/aarch64/driver-aarch64.c (AARCH64_OPT_EXTENSION): Add
>   SYNTHETIC.
> 
> gcc/testsuite/ChangeLog:
> 
> 2019-02-20  Tamar Christina  
> 
>   PR target/88530
>   * gcc.target/aarch64/options_set_1.c: New test.
>   * gcc.target/aarch64/options_set_2.c: New test.
>   * gcc.target/aarch64/options_set_3.c: New test.
>   * gcc.target/aarch64/options_set_4.c: New test.
>   * gcc.target/aarch64/options_set_5.c: New test.
>   * 

Re: [PATCH, testsuite] Enable vect_usad_char effective target for PowerPC and fix up SAD_EXPR testcases

[Jeff Law]

On 2/19/19 2:07 PM, Pat Haugen wrote:
> Power9 added support for V16QImode SAD operations. While making the 
> check_effective_target change I noticed that the tests will also pass on 
> Power7/Power8 even though they don't have the optab support. The reason is 
> the tests are only checking that the source pattern is recognized, not that a 
> SAD_EXPR was actually generated. So I've updated the tests also.
> 
> Ok for trunk?
> 
> -Pat
> 
> 
> testsuite/ChangeLog:
> 2019-02-19  Pat Haugen  
> 
>   * lib/target-supports.exp (check_effective_target_vect_usad_char):
>   Add PowerPC support.
>   * gcc.dg/vect/slp-reduc-sad.c: Update scan string.
>   * gcc.dg/vect/vect-reduc-sad.c: Likewise.
OK
jeff

Re: [PATCH] Fix PR89437

[Jeff Law]

On 2/21/19 8:55 AM, Wilco Dijkstra wrote:
> Fix PR89437. Fix the sinatan-1.c testcase to not run without
> a C99 target system.  Use nextafterl for long double initialization.
> 
> Fix an issue with sinl (atanl (sqrtl (LDBL_MAX)) returning 0.0
> instead of 1.0 by using x < sqrtl (LDBL_MAX) in match.pd.
> 
> OK for commit?
> 
> ChangeLog:
> 2019-02-21  Wilco Dijkstra  
> 
> gcc/
>   * match.pd: Use lt in sin(atan(x)) and cos(atan(x)) simplifications.
> 
> testsuite/
>   * gcc.dg/sinatan-1.c: Fix testcase.
OK.
jeff

Re: [PATCH] Remove unused extern variables from debug (PR debug/86964)

[Jeff Law]

On 2/21/19 12:22 PM, Richard Biener wrote:
> On February 21, 2019 8:06:05 PM GMT+01:00, Jeff Law  wrote:
>> On 2/19/19 5:51 AM, Johan Carlsson wrote:
>>> Adding so that the DIEs of unused external variables can be removed
>>from the output when
>>> using -feliminate-unused-debug-symbols.
>>>
>>> Tested on x86_64-elf, aarch64-elf, powerpc-eabi, powerpc64-elf and
>> arm-eabi.
>>>
>>>
>>> 2019-02-18  Johan Karlsson 
>>>
>>> PR debug/86964
>>> * dwarf2out.c (premark_used_variables): New function.
>>> (prune_unused_types_walk): Do not mark not premarked external
>>> variables.
>>> (prune_unused_types): Call premark_used_variables.
>>>
>>> * gcc.dg/debug/dwarf2/pr86964.c: New testcase.
>> Just a note, we're addressing regression bugfixes only at this point in
>> GCC development.  I've queued this for gcc-10.
> 
> Note that technically this is a regression from pre-early-debug. 
ACK.  I've updated the BZ appropriately.
jeff

Re: C++ PATCH for c++/88294 - ICE with non-constant noexcept-specifier

[Jason Merrill]

On 2/21/19 10:56 AM, Marek Polacek wrote:

On Wed, Feb 20, 2019 at 01:53:18PM -1000, Jason Merrill wrote:

On 2/20/19 10:31 AM, Marek Polacek wrote:

Here we ICE when substituting a deferred noexcept-specifier, because it
contains 'this', a PARM_DECL, in an evaluated context.  This is different
from "noexcept(noexcept(this))" where the noexcept operator's operand is
an unevaluated operand.  We crash within tsubst_copy's PARM_DECL handling
of a 'this' PARM_DECL:
15488   gcc_assert (cp_unevaluated_operand != 0)
It'd be wrong to mess with cp_unevaluated_operand (or current_class_*), and
since we only check the expression's constness after substituting in
maybe_instantiate_noexcept, one fix would be the following.

This is not just about 'this', as the 87844 test shows: here we also have
a parameter whose value we're trying to determine -- it's a template arg
of a late-specified return type.  Returning the original value in tsubst_copy
and leaving the later code to complain seems to work here as well.  Just
removing the assert should work as well.


I'm reluctant to mess with this assert, as it catches a lot of lambda bugs.


Makes sense -- I wasn't aware of that.


I think we want to register_parameter_specializations when instantiating
deferred noexcept, so that tsubst_copy can find the right decls.


Thanks for the suggestion -- that works with one catch: we need to replace the
fake 'this' in the noexcept- specifier with a real 'this' (the template one),
one that has DECL_CONTEXT set.  The fake one comes from inject_this_parameter,
when we were parsing the noexcept-specifier.  The real one was set in 
grokfndecl.


If you set current_class_ptr appropriately tsubst_copy will use it, so 
you shouldn't need to do a walk_tree.


Jason

Re: [C++ PATCH] Ensure constexpr evaluation is done on pre-cp_fold_function bodies (PR c++/89285, take 4)

[Jason Merrill]

On 2/20/19 9:08 PM, Jakub Jelinek wrote:

On Wed, Feb 20, 2019 at 01:58:58PM -1000, Jason Merrill wrote:

On 2/20/19 11:52 AM, Jakub Jelinek wrote:

On Wed, Feb 20, 2019 at 11:12:07AM -1000, Jason Merrill wrote:

(z = REALPART_EXPR >;, (bool) IMAGPART_EXPR >;);
which is not potential_constant_expression, but nothing called it again
and cxx_eval_constant_expression can handle it.


Yeah, that seems like a bug; C++11 shouldn't allow modification of z this
way either.


Ack.  The following version stops accepting that for C++11, but keeps
accepting for C++14 and later (so for that still needs to test
potential_constant_expression instead of is_constant_expression, plus
added a new inline function so that the code is more readable).


Can we unconditionally change is_constant_expression to
potential_constant_expression there?


Yes, passed bootstrap/regtest on x86_64-linux and i686-linux that way
and when I've tried to construct some builtin where it could make a
difference (e.g. __builtin_memcpy (, "b", 1);) it still didn't make a
difference.  So is this version ok for trunk?


OK, thanks.

Jason

Re: [PATCH] Minimum version of mpfr? (was Re: [PATCH] Fix up norm2 simplification (PR middle-end/88074))

[Jakub Jelinek]

On Thu, Feb 21, 2019 at 04:50:27PM -0500, David Malcolm wrote:
>  gcc/fortran/simplify.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/gcc/fortran/simplify.c b/gcc/fortran/simplify.c
> index fa6396b..a1df735 100644
> --- a/gcc/fortran/simplify.c
> +++ b/gcc/fortran/simplify.c
> @@ -6061,7 +6061,7 @@ norm2_add_squared (gfc_expr *result, gfc_expr *e)
>  
>gfc_set_model_kind (result->ts.kind);
>int index = gfc_validate_kind (BT_REAL, result->ts.kind, false);
> -  mpfr_exp_t exp;
> +  mp_exp_t exp;
>if (mpfr_regular_p (result->value.real))
>  {
>exp = mpfr_get_exp (result->value.real);

Ah, sorry for that.
I guess either we can use something like:
#if MPFR_VERSION < MPFR_VERSION_NUM(3,0,0)
  mp_exp_t exp;
#else
  mpfr_exp_t exp;
#endif

or perhaps just
  long exp;
or
  int exp;
?  We don't have pointers to that passed somewhere, so all we care is that
we cover the range (but, because of the previous limiting of the exponents
in toplev.c, it must fit into integer, because that is the type of the
min_exp/max_exp passed to mpfr_set_e{min,max}.

Jakub

[PATCH] Minimum version of mpfr? (was Re: [PATCH] Fix up norm2 simplification (PR middle-end/88074))

[David Malcolm]

On Wed, 2019-02-13 at 00:09 +0100, Jakub Jelinek wrote:
> Hi!
>
> As discussed recently on the mailing list, the norm2 simplification
> doesn't
> work if we limit mpfr emin/emax to some values derived from maximum
> floating
> exponents (and precision for denormals).
>
> The following patch adjusts the computation, so that it is scaled
> down if
> needed.  In particular, if any value in the array is so large that
> **2 will
> overflow on it or will be very close to it, the scale down is set to
> 2**(max_exponent/2+4), and if the result during computation gets
> close to
> overflowing, it is scaled down a little bit too.  The scaling is
> always done
> using powers of two, operands by that and the sum by **2 of that, and
> at the
> end it multiplies the sqrt back.  I had to change
> simplify_transformation_to_array, so that post_op is done immediately
> after
> finishing ops corresponding to that, so that there can be just one
> global
> variable for the scale.  From my understanding of e.g. the
> libgfortran norm2
> code where sqrt is done basically in this spot I hope it isn't
> possible that
> the same *dest is updated multiple times with dest
> increments/decrements in
> between.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux (together with
> Richard's patch), ok for trunk?
>
> 2019-02-12  Jakub Jelinek  
>
>   PR middle-end/88074
>   * simplify.c (simplify_transformation_to_array): Run post_op
>   immediately after processing corresponding row, rather than at
> the
>   end.
>   (norm2_scale): New variable.
>   (add_squared): Rename to ...
>   (norm2_add_squared): ... this.  Scale down operand and/or
> result
>   if needed.
>   (do_sqrt): Rename to ...
>   (norm2_do_sqrt): ... this.  Handle the result == e case.  Scale
> up
>   result and clear norm2_scale.
>   (gfc_simplify_norm2): Clear norm2_scale.  Change add_squared to
>   norm2_add_squared and _sqrt to norm2_do_sqrt.  Scale up
> result
>   and clear norm2_scale again.
>

[...]

>  static gfc_expr *
> -add_squared (gfc_expr *result, gfc_expr *e)
> +norm2_add_squared (gfc_expr *result, gfc_expr *e)
>  {
>mpfr_t tmp;
>
> @@ -6059,8 +6060,45 @@ add_squared (gfc_expr *result, gfc_expr
> && result->expr_type == EXPR_CONSTANT);
>
>gfc_set_model_kind (result->ts.kind);
> +  int index = gfc_validate_kind (BT_REAL, result->ts.kind, false);
> +  mpfr_exp_t exp;
> +  if (mpfr_regular_p (result->value.real))
> +{

I've started seeing build failures in my testing setup here, apparently
introduced with this patch:

../../../src/gcc/fortran/simplify.c: In function ‘gfc_expr* 
norm2_add_squared(gfc_expr*, gfc_expr*)’:
../../../src/gcc/fortran/simplify.c:6064:3: error: ‘mpfr_exp_t’ was not 
declared in this scope; did you mean ‘mpfr_expm1’?
 6064 |   mpfr_exp_t exp;
  |   ^~
  |   mpfr_expm1

I'm using mpfr-2.4.2.tar.bz2, which is the minimum version stated at:
  https://gcc.gnu.org/install/prerequisites.html
which says "MPFR Library version 2.4.2 (or later)"; that
version doesn't seem to have that type.

However, I see on:
  https://www.mpfr.org/mpfr-3.0.1/mpfr.html#API-Compatibility
that "The official type for exponent values changed from mp_exp_t to
mpfr_exp_t in MPFR 3.0."

So should the patch be tweaked to use the old type name, like in the
following patch (caveat: not tested yet), or do we need to update
the minimum version of mpfr, and if so, to what version?

[...]

Dave

gcc/fortran/ChangeLog:
PR middle-end/88074
* simplify.c (norm2_add_squared): Use mp_exp_t rather than
mpfr_exp_t.
---
 gcc/fortran/simplify.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/fortran/simplify.c b/gcc/fortran/simplify.c
index fa6396b..a1df735 100644
--- a/gcc/fortran/simplify.c
+++ b/gcc/fortran/simplify.c
@@ -6061,7 +6061,7 @@ norm2_add_squared (gfc_expr *result, gfc_expr *e)
 
   gfc_set_model_kind (result->ts.kind);
   int index = gfc_validate_kind (BT_REAL, result->ts.kind, false);
-  mpfr_exp_t exp;
+  mp_exp_t exp;
   if (mpfr_regular_p (result->value.real))
 {
   exp = mpfr_get_exp (result->value.real);
-- 
1.8.5.3

Re: C++ PATCH for c++/88294 - ICE with non-constant noexcept-specifier

[Marek Polacek]

On Wed, Feb 20, 2019 at 01:53:18PM -1000, Jason Merrill wrote:
> On 2/20/19 10:31 AM, Marek Polacek wrote:
> > Here we ICE when substituting a deferred noexcept-specifier, because it
> > contains 'this', a PARM_DECL, in an evaluated context.  This is different
> > from "noexcept(noexcept(this))" where the noexcept operator's operand is
> > an unevaluated operand.  We crash within tsubst_copy's PARM_DECL handling
> > of a 'this' PARM_DECL:
> > 15488   gcc_assert (cp_unevaluated_operand != 0)
> > It'd be wrong to mess with cp_unevaluated_operand (or current_class_*), and
> > since we only check the expression's constness after substituting in
> > maybe_instantiate_noexcept, one fix would be the following.
> > 
> > This is not just about 'this', as the 87844 test shows: here we also have
> > a parameter whose value we're trying to determine -- it's a template arg
> > of a late-specified return type.  Returning the original value in 
> > tsubst_copy
> > and leaving the later code to complain seems to work here as well.  Just
> > removing the assert should work as well.
> 
> I'm reluctant to mess with this assert, as it catches a lot of lambda bugs.

Makes sense -- I wasn't aware of that.

> I think we want to register_parameter_specializations when instantiating
> deferred noexcept, so that tsubst_copy can find the right decls.

Thanks for the suggestion -- that works with one catch: we need to replace the
fake 'this' in the noexcept- specifier with a real 'this' (the template one),
one that has DECL_CONTEXT set.  The fake one comes from inject_this_parameter,
when we were parsing the noexcept-specifier.  The real one was set in 
grokfndecl.

Before calling register_parameter_specializations one apparently has to set up
a local specializations stack.

Does this look reasonable?  It no longer fixes the other PR; we'll likely have
to play some register_local_specialization games there, too.

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

2019-02-21  Marek Polacek  

PR c++/88294 - ICE with non-constant noexcept-specifier.
* pt.c (replace_this_r): New function.
(maybe_instantiate_noexcept): Set up the list of local
specializations.  Replace the fake 'this' with the real one.

* g++.dg/cpp0x/noexcept34.C: New test.

diff --git gcc/cp/pt.c gcc/cp/pt.c
index a212be8c747..abbec8f53b9 100644
--- gcc/cp/pt.c
+++ gcc/cp/pt.c
@@ -24158,6 +24158,20 @@ always_instantiate_p (tree decl)
  && decl_maybe_constant_var_p (decl)));
 }
 
+/* Replace all fake 'this' parameters (i.e. the ones created by
+   inject_this_parameter) with the real 'this'.  */
+
+static tree
+replace_this_r (tree *t, int *, void *data_)
+{
+  tree *d = static_cast(data_);
+  if (TREE_CODE (*t) == PARM_DECL
+  && DECL_NAME (*t) == this_identifier
+  && DECL_CONTEXT (*t) == NULL_TREE)
+*t = *d;
+  return NULL_TREE;
+}
+
 /* If FN has a noexcept-specifier that hasn't been instantiated yet,
instantiate it now, modifying TREE_TYPE (fn).  Returns false on
error, true otherwise.  */
@@ -24203,12 +24217,34 @@ maybe_instantiate_noexcept (tree fn, tsubst_flags_t 
complain)
  push_access_scope (fn);
  push_deferring_access_checks (dk_no_deferred);
  input_location = DECL_SOURCE_LOCATION (fn);
- noex = tsubst_copy_and_build (DEFERRED_NOEXCEPT_PATTERN (noex),
-   DEFERRED_NOEXCEPT_ARGS (noex),
-   tf_warning_or_error, fn,
-   /*function_p=*/false,
-   
/*integral_constant_expression_p=*/true);
- spec = build_noexcept_spec (noex, tf_warning_or_error);
+
+ /* A new stack interferes with pop_access_scope.  */
+ {
+   /* Set up the list of local specializations.  */
+   local_specialization_stack lss (lss_copy);
+
+   /* Replace the fake 'this' with the real 'this'.  */
+   tree tdecl = DECL_TEMPLATE_RESULT (DECL_TI_TEMPLATE (fn));
+   if (DECL_NONSTATIC_MEMBER_FUNCTION_P (tdecl))
+ {
+   tree real_this = DECL_ARGUMENTS (tdecl);
+   tree *p = _NOEXCEPT_PATTERN (noex);
+   cp_walk_tree_without_duplicates (p, replace_this_r,
+_this);
+ }
+
+   /* Create substitution entries for the parameters.  */
+   register_parameter_specializations (tdecl, fn);
+
+   /* Do deferred instantiation of the noexcept-specifier.  */
+   noex = tsubst_copy_and_build (DEFERRED_NOEXCEPT_PATTERN (noex),
+ DEFERRED_NOEXCEPT_ARGS (noex),
+ tf_warning_or_error, fn,
+ /*function_p=*/false,
+ /*i_c_e_p=*/true);
+   spec = build_noexcept_spec (noex, tf_warning_or_error);
+  

Re: [PATCH] libstdc++/89130 and libstdc++/89090 fixes for vector relocation

[Jonathan Wakely]

On 05/02/19 14:45 +, Jonathan Wakely wrote:

This fixes two PRs, one trivial (don't use C++17 features in C++11
mode) and one more serious (don't require MoveInsertable when we
should only need CopyInsertable).

It would be nice to rely on if-constexpr in C++11 mode, but it causes
clang warnings, complicates testcase bisection/reduction, and causes
users to file bogus bug reports. So let's just avoid it.

Tested powerpc64le-linux, committed to trunk.





commit 51908e56bd32b5f89bc909193c3da957de01c3e0
Author: Jonathan Wakely 
Date:   Tue Feb 5 11:50:18 2019 +

   PR libstdc++/89130 restore support for non-MoveConstructible types
   
   The changes to "relocate" std::vector elements can lead to new errors

   outside the immediate context, because moving the elements to new
   storage no longer makes use of the move-if-noexcept utilities. This
   means that types with deleted moves no longer degenerate to copies, but
   are just ill-formed. The errors happen while instantiating the
   noexcept-specifier for __relocate_object_a, when deciding whether to try
   to relocate.
   
   This patch introduces indirections to avoid the ill-formed

   instantiations of std::__relocate_object_a. In order to avoid using
   if-constexpr prior to C++17 this is done by tag dispatching. After this
   patch all uses of std::__relocate_a are guarded by checks that will
   support sensible code (i.e. code not using custom allocators that fool
   the new checks).
   
   PR libstdc++/89130

   * include/bits/alloc_traits.h (__is_copy_insertable_impl): Rename to
   __is_alloc_insertable_impl. Replace single type member with two
   members, one for each of copy and move insertable.
   (__is_move_insertable): New trait for internal use.
   * include/bits/stl_vector.h (vector::_S_nothrow_relocate(true_type))
   (vector::_S_nothrow_relocate(true_type)): New functions to
   conditionally check if __relocate_a can throw.
   (vector::_S_use_relocate()): Dispatch to _S_nothrow_relocate based
   on __is_move_insertable.
   (vector::_S_do_relocate): New overloaded functions to conditionally
   call __relocate_a.
   (vector::_S_relocate): New function that dispatches to _S_do_relocate
   based on _S_use_relocate.
   * include/bits/vector.tcc (vector::reserve, 
vector::_M_realloc_insert)
   (vector::_M_default_append): Call _S_relocate instead of 
__relocate_a.
   * testsuite/23_containers/vector/modifiers/push_back/89130.cc: New.

diff --git a/libstdc++-v3/include/bits/alloc_traits.h 
b/libstdc++-v3/include/bits/alloc_traits.h
index ed61ce845f8..3b0c16fbf64 100644
--- a/libstdc++-v3/include/bits/alloc_traits.h
+++ b/libstdc++-v3/include/bits/alloc_traits.h
@@ -577,14 +577,16 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
}

  template
-class __is_copy_insertable_impl
+class __is_alloc_insertable_impl
{
-  typedef allocator_traits<_Alloc> _Traits;
+  using _Traits = allocator_traits<_Alloc>;
+  using value_type = typename _Traits::value_type;

-  template,
+  typename
   = decltype(_Traits::construct(std::declval<_Alloc&>(),
-std::declval<_Up*>(),
-std::declval()))>
+std::declval<_Tp*>(),
+std::declval<_Up>()))>
static true_type
_M_select(int);

@@ -593,13 +595,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
_M_select(...);

public:
-  typedef decltype(_M_select(0)) type;
+  using copy = decltype(_M_select(0));
+  using move = decltype(_M_select(0));


This caused another regression, fixed by the attached patch.

Tested powerpc64le-linux, committed to trunk.

commit 802fc355d929152fb2c70e5fc1422d16143eeb10
Author: Jonathan Wakely 
Date:   Thu Feb 21 02:28:16 2019 +

PR libstdc++/89416 fix __is_move_insertable trait

The common base class for __is_move_insertable and __is_copy_insertable
instantiates both the copy and move tests, when only one is needed. The
unneeded one might cause errors outside the immediate context.

The solution used in this patch is to replace them with alias templates,
which will only be instantiated as needed.

PR libstdc++/89416
* include/bits/alloc_traits.h (__is_alloc_insertable_impl): Replace
class template with class. Replace move and copy member types with
member alias templates, so they are only instantiated when needed.
(__is_copy_insertable, __is_move_insertable): Adjust base class.
* testsuite/23_containers/vector/modifiers/push_back/89130.cc: Enable
test for C++11/14/17 as well.
* testsuite/23_containers/vector/modifiers/push_back/89416.cc: New
test.

diff --git 

Re: PING [PATCH] fix ICE in __builtin_has_attribute (PR 88383 and 89288)

[Jeff Law]

On 2/21/19 1:12 PM, Martin Sebor wrote:
> On 2/21/19 12:08 PM, Jeff Law wrote:
>> On 2/18/19 7:53 PM, Martin Sebor wrote:
>>> Please let me know what it will take to get the fix for these two
>>> issues approved.  I've answered the questions so I don't know what
>>> else I'm expected to do here.
>>>
>>>    https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00793.html
>> I think there is still a fundamental disagreement about whether or not
>> this should be handling expressions.  Without an agreement on that it's
>> hard to see how this could go forward.
> 
> I think it's wrong to hold up a fix for an ICE because you don't
> like the current design.  The built-in successfully handles common
> expressions (see c-c++-common/builtin-has-attribute-5.c).  It just
> fails for some of the less common ones.  Not fixing those will only
> penalize users who run into the ICE, and cast a bad light on
> the quality of the release.   Any design questions should be
> settled separately of these ICEs (should have been when
> the feature was being reviewed).
> 
> That said, I have explained the rationale for the current design.
> Neither you nor Jakub has explained what you find wrong with it or
> why either of your alternatives is preferable.  You said it should
> be an error to apply the built-in to expressions (why?).  Jakub
> thought there perhaps should be two built-ins, one for expressions
> and another for decls.  His rationale?  The current design is not
> good.  Clearly,  the two of you don't agree on what you'd like to
> see; the only thing you agree on is that you don't like what's
> there now.  What do you expect me to do with that, now at the end
> of stage 4?
Fix the ice in another way.  Handling expressions here seems
fundamentally wrong.  ISTM that making this query on an expression
should result in an immediate error.

jeff

Re: PING [PATCH] fix ICE in __builtin_has_attribute (PR 88383 and 89288)

[Martin Sebor]

On 2/21/19 12:08 PM, Jeff Law wrote:

On 2/18/19 7:53 PM, Martin Sebor wrote:

Please let me know what it will take to get the fix for these two
issues approved.  I've answered the questions so I don't know what
else I'm expected to do here.

   https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00793.html

I think there is still a fundamental disagreement about whether or not
this should be handling expressions.  Without an agreement on that it's
hard to see how this could go forward.


I think it's wrong to hold up a fix for an ICE because you don't
like the current design.  The built-in successfully handles common
expressions (see c-c++-common/builtin-has-attribute-5.c).  It just
fails for some of the less common ones.  Not fixing those will only
penalize users who run into the ICE, and cast a bad light on
the quality of the release.   Any design questions should be
settled separately of these ICEs (should have been when
the feature was being reviewed).

That said, I have explained the rationale for the current design.
Neither you nor Jakub has explained what you find wrong with it or
why either of your alternatives is preferable.  You said it should
be an error to apply the built-in to expressions (why?).  Jakub
thought there perhaps should be two built-ins, one for expressions
and another for decls.  His rationale?  The current design is not
good.  Clearly,  the two of you don't agree on what you'd like to
see; the only thing you agree on is that you don't like what's
there now.  What do you expect me to do with that, now at the end
of stage 4?

Martin

Re: [PATCH] sched-ebb.c: avoid moving table jumps (PR rtl-optimization/88423)

[Jeff Law]

On 1/24/19 3:10 PM, Eric Botcazou wrote:
>> md.texi says
>>
>> The @samp{tablejump} insn is always the last insn before the jump
>> table it uses.  Its assembler code normally has no need to use the
>> second operand, but you should incorporate it in the RTL pattern so
>> that the jump optimizer will not delete the table as unreachable code.
>>
>> but rtl.texi says
>>
>> A @code{jump_table_data} insn is a placeholder for the jump-table data
>> of a @code{casesi} or @code{tablejump} insn.  They are placed after
>> a @code{tablejump_p} insn.  A @code{jump_table_data} insn is not part o
>> a basic blockm but it is associated with the basic block that ends with
>> the @code{tablejump_p} insn.  The @code{PATTERN} of a @code{jump_table_data}
>> is always either an @code{addr_vec} or an @code{addr_diff_vec}, and a
>> @code{jump_table_data} insn is always preceded by a @code{code_label}. The
>> @code{tablejump_p} insn refers to that @code{code_label} via its
>> @code{JUMP_LABEL}.
>>
>> Which of these two is true?
> 
> The latter I'd say, see skip_insns_after_block.
Hmm, I forgot about the label.  Ugh.  That may muck up the whole
SCHED_GROUP_P thing.  But yes, I think it's supposed to be the
tablejump, label and jump table.   The question in my mind is barriers
and BLOCK_END notes -- where are those supposed to be?

Jeff

Re: [PATCH] sched-ebb.c: avoid moving table jumps (PR rtl-optimization/88423)

[Jeff Law]

On 1/23/19 6:52 AM, Alexander Monakov wrote:
> On Wed, 23 Jan 2019, Andrey Belevantsev wrote:
> 
>> For that, I'm not sure.  Your patch will leave the tablejump unscheduled at
>> all, i.e. any fields like INSN_TICK would be unfilled and thus the later
>> passes like bundling on ia64 will not work.  Maybe we can just stop
>> tablejumps from moving within its block, Alexander?
> 
> On the Bugzilla there's an alternative patch by Segher that adjusts the assert
> to accept this situation (there's still a barrier insn after the tablejump 
> insn,
> it's just after a jump_table_data insn rather than immediately following the
> jump).  That should be a better approach, and David said he was testing it.
> 
> That said, I'm really concerned that on this testcase we should not be moving
> the tablejump *at all*: we are moving it up past a 'use ax' insn (the use is
> for the function's return value). So after the move the use is in an 
> unreachable
> block, which makes no sense.
> 
> So my concern is that just fixing the assert changes the issue from the ICE 
> to a
> (latent) wrong-code issue.
> 
> There should have been an anti-dependence between the use and the jump. I'll 
> try
> to investigate.
The first thing I'd do is make sure the jump table has its SCHED_GROUP_P
marker which indicates it must stick with its associated jump.  Then I'd
make sure it's honored in the appropriate places.  It may be awkward
because the jump table data insn is going to have the SCHED_GROUP_P bit
set, but we're likely looking to muck with the actual jump.  That's
probably an artifact of the old backwards scheduling algorithm.

jeff

Re: [PATCH] sched-ebb.c: avoid moving table jumps (PR rtl-optimization/88423)

[Jeff Law]

On 1/23/19 12:29 PM, Segher Boessenkool wrote:
> On Wed, Jan 23, 2019 at 04:52:24PM +0300, Alexander Monakov wrote:
>> On Wed, 23 Jan 2019, Andrey Belevantsev wrote:
>>> For that, I'm not sure.  Your patch will leave the tablejump unscheduled at
>>> all, i.e. any fields like INSN_TICK would be unfilled and thus the later
>>> passes like bundling on ia64 will not work.  Maybe we can just stop
>>> tablejumps from moving within its block, Alexander?
>>
>> On the Bugzilla there's an alternative patch by Segher that adjusts the 
>> assert
>> to accept this situation (there's still a barrier insn after the tablejump 
>> insn,
>> it's just after a jump_table_data insn rather than immediately following the
>> jump).  That should be a better approach, and David said he was testing it.
>>
>> That said, I'm really concerned that on this testcase we should not be moving
>> the tablejump *at all*: we are moving it up past a 'use ax' insn (the use is
>> for the function's return value). So after the move the use is in an 
>> unreachable
>> block, which makes no sense.
> 
> Yes, that makes no sense indeed.  Is it acceptable (for performance) to
> simply bail out on table jumps here?
> 
>> So my concern is that just fixing the assert changes the issue from the ICE 
>> to a
>> (latent) wrong-code issue.
>>
>> There should have been an anti-dependence between the use and the jump. I'll 
>> try
>> to investigate.
> 
> Or that.  Thanks!
Or (as I've indicated to David) investigate if we're getting
SCHED_GROUP_P right -- that's the canonical way to keep two insns
together in the schedule.  It's definitely worth investigating.

Jeff

Re: PING^1: V2 [PATCH] driver: Also prune joined switches with negation

[Jakub Jelinek]

On Thu, Feb 21, 2019 at 10:40:09AM -0800, H.J. Lu wrote:
> > Prune joined switches with Negative and RejectNegative to allow
> > -march=skylake-avx512 to override previous -march=native on command-line.
> >
> > gcc/
> >
> > PR driver/69471
> > * opts-common.c (prune_options): Also prune joined switches
> > with Negative and RejectNegative.
> > * config/i386/i386.opt (march=): Add Negative(march=).
> > (mtune=): Add Negative(mtune=).
> > * doc/options.texi: Document Negative used together with Joined
> > and RejectNegative.
> >
> > gcc/testsuite/
> >
> > PR driver/69471
> > * gcc.dg/pr69471-1.c: New test.
> > * gcc.dg/pr69471-2.c: Likewise.
> > * gcc.target/i386/pr69471-3.c: Likewise.
> 
> PING:
> 
> https://gcc.gnu.org/ml/gcc-patches/2019-02/msg01071.html

The latest version looks good to me, so if Joseph won't object in next 48
hours, it is ok for trunk.  I guess we want to ask maintainers of other
backends who support -m*=native to decide what they want afterwards.

Jakub

Re: [PATCH] Remove unused extern variables from debug (PR debug/86964)

[Richard Biener]

On February 21, 2019 8:06:05 PM GMT+01:00, Jeff Law  wrote:
>On 2/19/19 5:51 AM, Johan Carlsson wrote:
>> Adding so that the DIEs of unused external variables can be removed
>from the output when
>> using -feliminate-unused-debug-symbols.
>> 
>> Tested on x86_64-elf, aarch64-elf, powerpc-eabi, powerpc64-elf and
>arm-eabi.
>> 
>> 
>> 2019-02-18  Johan Karlsson 
>> 
>>  PR debug/86964
>>  * dwarf2out.c (premark_used_variables): New function.
>>  (prune_unused_types_walk): Do not mark not premarked external
>>  variables.
>>  (prune_unused_types): Call premark_used_variables.
>> 
>>  * gcc.dg/debug/dwarf2/pr86964.c: New testcase.
>Just a note, we're addressing regression bugfixes only at this point in
>GCC development.  I've queued this for gcc-10.

Note that technically this is a regression from pre-early-debug. 

Richard. 

>jeff

Re: PING [PATCH] fix ICE in __builtin_has_attribute (PR 88383 and 89288)

[Jeff Law]

On 2/18/19 7:53 PM, Martin Sebor wrote:
> Please let me know what it will take to get the fix for these two
> issues approved.  I've answered the questions so I don't know what
> else I'm expected to do here.
> 
>   https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00793.html
I think there is still a fundamental disagreement about whether or not
this should be handling expressions.  Without an agreement on that it's
hard to see how this could go forward.

jeff

Re: [PATCH] Remove unused extern variables from debug (PR debug/86964)

[Jeff Law]

On 2/19/19 5:51 AM, Johan Carlsson wrote:
> Adding so that the DIEs of unused external variables can be removed from the 
> output when
> using -feliminate-unused-debug-symbols.
> 
> Tested on x86_64-elf, aarch64-elf, powerpc-eabi, powerpc64-elf and arm-eabi.
> 
> 
> 2019-02-18  Johan Karlsson 
> 
>   PR debug/86964
>   * dwarf2out.c (premark_used_variables): New function.
>   (prune_unused_types_walk): Do not mark not premarked external
>   variables.
>   (prune_unused_types): Call premark_used_variables.
> 
>   * gcc.dg/debug/dwarf2/pr86964.c: New testcase.
Just a note, we're addressing regression bugfixes only at this point in
GCC development.  I've queued this for gcc-10.

jeff

Re: PING [PATCH] avoid 4095/INT_MAX warning for fprintf (PR 88993)

[Jeff Law]

On 2/19/19 5:43 PM, Martin Sebor wrote:
> I received feedback on the first patch that it doesn't suppress all
> the instances of the warning so I've relaxed the checker even more
> to avoid the excess instances seen in Elfutils and beefed up
> the tests.  The top of trunk compiles cleanly now with just
> the three instances of -Wformat-truncation=2 that are not
> the subject of the two PRs.
> 
> Martin
> 
> On 2/11/19 11:24 AM, Martin Sebor wrote:
>> Ping: https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00224.html
>>
>> (This patch also handles bug 88835.)
>>
>> On 2/4/19 8:58 PM, Martin Sebor wrote:
>>> The attached patch relaxes -Wformat-overflow=2 to avoid warning about
>>> individual directives that might (but need not) exceed the 4095 byte
>>> limit, and about the total function output that likewise might (but
>>> need not) exceed the INT_MAX limit.
>>>
>>> The bug report actually requests that instead of the standard minimum
>>> of 4095 bytes, GCC consider real libc limits, but trying to figure
>>> out what these real limits might be (they're not documented anywhere,
>>> AFAIK) and hardcoding them into GCC doesn't seem like a good solution.
>>>
>>> Instead, the patch only does little more than the bare minimum to
>>> suppress these pedantic warnings, and it only does that for the "may
>>> exceed" cases and not for those where the size of output definitely
>>> exceeds either limit.  Using the formatted functions to write such
>>> large amounts of data seems more likely to be a bug than intentional,
>>> and at level 2 issuing the warning seems appropriate unless the return
>>> value of the function is tested.  When it is, even tough exceeding
>>> these limits is strictly undefined, it seems reasonable to assume that
>>> a quality libc implementation will detect it and return an error (as
>>> required by POSIX).
>>>
>>> So with the patch, the only way to get this warning is for calls to
>>> sprintf or to unchecked snprintf.
>>>
>>> Martin
>>
> 
> 
> gcc-88993.diff
> 
> PR tree-optimization/88993 - GCC 9 -Wformat-overflow=2 should reflect real 
> libc limits
> PR tree-optimization/88835 - overly aggressive -Werror=format-overflow for 
> printf
> 
> gcc/ChangeLog:
> 
>   PR tree-optimization/88993
>   PR tree-optimization/88835
>   * gimple-ssa-sprintf.c (sprintf_dom_walker::call_info::is_file_func):
>   New helper.
>   (sprintf_dom_walker::call_info::is_string_func): New helper.
>   (format_directive): Only issue "may exceed" 4095/INT_MAX warnings
>   for formatted string functions.
>   (sprintf_dom_walker::compute_format_length): Return HWI_MAX rather than 
> -1.
>   (sprintf_dom_walker::handle_gimple_call): Fix a typo in a comment.
> 
> gcc/testsuite/ChangeLog:
> 
>   PR tree-optimization/88993
>   PR tree-optimization/88835
>   * gcc.dg/tree-ssa/builtin-fprintf-warn-2.c: New test.
>   * gcc.dg/tree-ssa/builtin-printf-warn-2.c: New test.
>   * gcc.dg/tree-ssa/builtin-snprintf-warn-3.c: Adjust.
>   * gcc.dg/tree-ssa/builtin-sprintf-warn-18.c: Same.
> 
> Index: gcc/gimple-ssa-sprintf.c
> ===
> --- gcc/gimple-ssa-sprintf.c  (revision 269022)
> +++ gcc/gimple-ssa-sprintf.c  (working copy)
> @@ -943,6 +943,29 @@ struct sprintf_dom_walker::call_info
>{
>  return bounded ? OPT_Wformat_truncation_ : OPT_Wformat_overflow_;
>}
> +
> +  /* Return true for calls to file formatted functions.  */
> +  bool is_file_func () const
> +  {
> +return (fncode == BUILT_IN_FPRINTF
> + || fncode == BUILT_IN_FPRINTF_CHK
> + || fncode == BUILT_IN_FPRINTF_UNLOCKED
> + || fncode == BUILT_IN_VFPRINTF
> + || fncode == BUILT_IN_VFPRINTF_CHK);
> +  }
> +
> +  /* Return true for calls to string formatted fncodetions.  */
I believe fncodetions should be functions :-)

OK with the  nit fixed.  And yes, I think it would be exceedingly
difficult to determine with any reliability what the system limits
really are.

jeff

PING^1: V2 [PATCH] driver: Also prune joined switches with negation

[H.J. Lu]

On Thu, Feb 14, 2019 at 5:51 AM H.J. Lu  wrote:
>
> On Thu, Feb 14, 2019 at 12:03:30PM +0100, Jakub Jelinek wrote:
> > On Wed, Feb 13, 2019 at 06:27:51PM -0800, H.J. Lu wrote:
> > > --- a/gcc/doc/options.texi
> > > +++ b/gcc/doc/options.texi
> > > @@ -227,7 +227,10 @@ options, their @code{Negative} properties should 
> > > form a circular chain.
> > >  For example, if options @option{-@var{a}}, @option{-@var{b}} and
> > >  @option{-@var{c}} are mutually exclusive, their respective 
> > > @code{Negative}
> > >  properties should be @samp{Negative(@var{b})}, @samp{Negative(@var{c})}
> > > -and @samp{Negative(@var{a})}.
> > > +and @samp{Negative(@var{a})}.  @code{Negative} can be used together
> > > +with @code{Joined} if there is no @code{RejectNegative} property.
> > > +@code{Negative} is ignored if there is @code{Joined} without
> > > +@code{RejectNegative}.
> >
> > I think this doesn't describe what is implemented.
> >
> > Something like:
> >  the option name with the leading ``-'' removed.  This chain action will
> >  propagate through the @code{Negative} property of the option to be
> > -turned off.
> > +turned off.  The driver will prune options, removing those that are
> > +turned off by some later option.  This pruning is not done for options
> > +with @code{Joined} or @code{JoinedOrMissing} properties, unless the
> > +options have either @code{RejectNegative} property or the @code{Negative}
> > +property mentions an option other than itself.
> >
> >  As a consequence, if you have a group of mutually-exclusive
> >  options, their @code{Negative} properties should form a circular chain.
> >
> > ?
> >
> > Otherwise LGTM, but Joseph is the options machinery maintainer, so I'll
> > defer to him here.
> >
>
> Here is the updated patch with a "-march=native -march=knl" testcase.
>
> Thanks.
>
> H.J.
> ---
> When -march=native is passed to host_detect_local_cpu to the backend,
> it overrides all command lines after it.  That means
>
> $ gcc -march=native -march=skylake-avx512
>
> is the treated as
>
> $ gcc -march=skylake-avx512 -march=native
>
> Prune joined switches with Negative and RejectNegative to allow
> -march=skylake-avx512 to override previous -march=native on command-line.
>
> gcc/
>
> PR driver/69471
> * opts-common.c (prune_options): Also prune joined switches
> with Negative and RejectNegative.
> * config/i386/i386.opt (march=): Add Negative(march=).
> (mtune=): Add Negative(mtune=).
> * doc/options.texi: Document Negative used together with Joined
> and RejectNegative.
>
> gcc/testsuite/
>
> PR driver/69471
> * gcc.dg/pr69471-1.c: New test.
> * gcc.dg/pr69471-2.c: Likewise.
> * gcc.target/i386/pr69471-3.c: Likewise.

PING:

https://gcc.gnu.org/ml/gcc-patches/2019-02/msg01071.html


-- 
H.J.

Re: [PATCH 1/1] Move AESNI generation to Skylake and Goldmont

[H.J. Lu]

On Thu, Feb 21, 2019 at 10:31 AM Thiago Macieira
 wrote:
>
> On Thursday, 30 August 2018 09:00:10 PST H.J. Lu wrote:
> > On Wed, Aug 29, 2018 at 11:56 PM, Uros Bizjak  wrote:
> > >>  gcc/config/i386/i386.c | 6 +++---
> > >>  1 file changed, 3 insertions(+), 3 deletions(-)
> > >>
> > >> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> > >> index c437c18a29c..8672a666024 100644
> > >> --- a/gcc/config/i386/i386.c
> > >> +++ b/gcc/config/i386/i386.c
> > >> @@ -3479,7 +3479,7 @@ ix86_option_override_internal (bool main_args_p,
> > >>
> > >>  | PTA_SSE3 | PTA_SSSE3 | PTA_CX16 | PTA_FXSR;
> > >>
> > >>const wide_int_bitmask PTA_NEHALEM = PTA_CORE2 | PTA_SSE4_1 |
> > >>PTA_SSE4_2
> > >>
> > >>  | PTA_POPCNT;
> > >>
> > >> -  const wide_int_bitmask PTA_WESTMERE = PTA_NEHALEM | PTA_AES |
> > >> PTA_PCLMUL; +  const wide_int_bitmask PTA_WESTMERE = PTA_NEHALEM |
> > >> PTA_PCLMUL;>>
> > >>const wide_int_bitmask PTA_SANDYBRIDGE = PTA_WESTMERE | PTA_AVX |
> > >>PTA_XSAVE
> > >>
> > >>  | PTA_XSAVEOPT;
> > >>
> > >>const wide_int_bitmask PTA_IVYBRIDGE = PTA_SANDYBRIDGE | PTA_FSGSBASE
> > >>
> > >> @@ -3488,7 +3488,7 @@ ix86_option_override_internal (bool main_args_p,
> > >>
> > >>  | PTA_BMI2 | PTA_LZCNT | PTA_FMA | PTA_MOVBE | PTA_HLE;
> > >>
> > >>const wide_int_bitmask PTA_BROADWELL = PTA_HASWELL | PTA_ADX |
> > >>PTA_PRFCHW
> > >>
> > >>  | PTA_RDSEED;
> > >>
> > >> -  const wide_int_bitmask PTA_SKYLAKE = PTA_BROADWELL | PTA_CLFLUSHOPT
> > >> +  const wide_int_bitmask PTA_SKYLAKE = PTA_BROADWELL | PTA_AES |
> > >> PTA_CLFLUSHOPT>>
> > >>  | PTA_XSAVEC | PTA_XSAVES | PTA_SGX;
> > >>
> > >>const wide_int_bitmask PTA_SKYLAKE_AVX512 = PTA_SKYLAKE | PTA_AVX512F
> > >>
> > >>  | PTA_AVX512CD | PTA_AVX512VL | PTA_AVX512BW | PTA_AVX512DQ |
> > >>  | PTA_PKU
> > >>
> > >> @@ -3505,7 +3505,7 @@ ix86_option_override_internal (bool main_args_p,
> > >>
> > >>  | PTA_AVX512F | PTA_AVX512CD;
> > >>
> > >>const wide_int_bitmask PTA_BONNELL = PTA_CORE2 | PTA_MOVBE;
> > >>const wide_int_bitmask PTA_SILVERMONT = PTA_WESTMERE | PTA_MOVBE |
> > >>PTA_RDRND;>>
> > >> -  const wide_int_bitmask PTA_GOLDMONT = PTA_SILVERMONT | PTA_SHA |
> > >> PTA_XSAVE +  const wide_int_bitmask PTA_GOLDMONT = PTA_SILVERMONT |
> > >> PTA_AES | PTA_SHA | PTA_XSAVE>>
> > >>  | PTA_RDSEED | PTA_XSAVEC | PTA_XSAVES | PTA_CLFLUSHOPT |
> > >>  | PTA_XSAVEOPT
> > >>  | PTA_FSGSBASE;
> > >>
> > >>const wide_int_bitmask PTA_GOLDMONT_PLUS = PTA_GOLDMONT | PTA_RDPID
> > >>
> > >> --
> > >> 2.18.0
> >
> > This is what I checked in.
> >
> > Thanks.
>
> Hello H.J., Uros, Martin
>
> Looks like Martin's change in r264052, which moved the code from i386.c to
> i386.h ended up accidentally reverting my change.
>
> Do you want me to re-submit with an update or will one of you simply re-apply?
>
> For reference, this change was applied to Clang in https://reviews.llvm.org/
> rC341862 and LLVM in https://reviews.llvm.org/rL341862.
>

Please re-submit it.

Thanks.

-- 
H.J.

Re: [PATCH 1/1] Move AESNI generation to Skylake and Goldmont

[Thiago Macieira]

On Thursday, 30 August 2018 09:00:10 PST H.J. Lu wrote:
> On Wed, Aug 29, 2018 at 11:56 PM, Uros Bizjak  wrote:
> >>  gcc/config/i386/i386.c | 6 +++---
> >>  1 file changed, 3 insertions(+), 3 deletions(-)
> >> 
> >> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> >> index c437c18a29c..8672a666024 100644
> >> --- a/gcc/config/i386/i386.c
> >> +++ b/gcc/config/i386/i386.c
> >> @@ -3479,7 +3479,7 @@ ix86_option_override_internal (bool main_args_p,
> >> 
> >>  | PTA_SSE3 | PTA_SSSE3 | PTA_CX16 | PTA_FXSR;
> >>
> >>const wide_int_bitmask PTA_NEHALEM = PTA_CORE2 | PTA_SSE4_1 |
> >>PTA_SSE4_2
> >>
> >>  | PTA_POPCNT;
> >> 
> >> -  const wide_int_bitmask PTA_WESTMERE = PTA_NEHALEM | PTA_AES |
> >> PTA_PCLMUL; +  const wide_int_bitmask PTA_WESTMERE = PTA_NEHALEM |
> >> PTA_PCLMUL;>> 
> >>const wide_int_bitmask PTA_SANDYBRIDGE = PTA_WESTMERE | PTA_AVX |
> >>PTA_XSAVE
> >>
> >>  | PTA_XSAVEOPT;
> >>
> >>const wide_int_bitmask PTA_IVYBRIDGE = PTA_SANDYBRIDGE | PTA_FSGSBASE
> >> 
> >> @@ -3488,7 +3488,7 @@ ix86_option_override_internal (bool main_args_p,
> >> 
> >>  | PTA_BMI2 | PTA_LZCNT | PTA_FMA | PTA_MOVBE | PTA_HLE;
> >>
> >>const wide_int_bitmask PTA_BROADWELL = PTA_HASWELL | PTA_ADX |
> >>PTA_PRFCHW
> >>
> >>  | PTA_RDSEED;
> >> 
> >> -  const wide_int_bitmask PTA_SKYLAKE = PTA_BROADWELL | PTA_CLFLUSHOPT
> >> +  const wide_int_bitmask PTA_SKYLAKE = PTA_BROADWELL | PTA_AES |
> >> PTA_CLFLUSHOPT>> 
> >>  | PTA_XSAVEC | PTA_XSAVES | PTA_SGX;
> >>
> >>const wide_int_bitmask PTA_SKYLAKE_AVX512 = PTA_SKYLAKE | PTA_AVX512F
> >>
> >>  | PTA_AVX512CD | PTA_AVX512VL | PTA_AVX512BW | PTA_AVX512DQ |
> >>  | PTA_PKU
> >> 
> >> @@ -3505,7 +3505,7 @@ ix86_option_override_internal (bool main_args_p,
> >> 
> >>  | PTA_AVX512F | PTA_AVX512CD;
> >>
> >>const wide_int_bitmask PTA_BONNELL = PTA_CORE2 | PTA_MOVBE;
> >>const wide_int_bitmask PTA_SILVERMONT = PTA_WESTMERE | PTA_MOVBE |
> >>PTA_RDRND;>> 
> >> -  const wide_int_bitmask PTA_GOLDMONT = PTA_SILVERMONT | PTA_SHA |
> >> PTA_XSAVE +  const wide_int_bitmask PTA_GOLDMONT = PTA_SILVERMONT |
> >> PTA_AES | PTA_SHA | PTA_XSAVE>> 
> >>  | PTA_RDSEED | PTA_XSAVEC | PTA_XSAVES | PTA_CLFLUSHOPT |
> >>  | PTA_XSAVEOPT
> >>  | PTA_FSGSBASE;
> >>
> >>const wide_int_bitmask PTA_GOLDMONT_PLUS = PTA_GOLDMONT | PTA_RDPID
> >> 
> >> --
> >> 2.18.0
> 
> This is what I checked in.
> 
> Thanks.

Hello H.J., Uros, Martin

Looks like Martin's change in r264052, which moved the code from i386.c to 
i386.h ended up accidentally reverting my change.

Do you want me to re-submit with an update or will one of you simply re-apply?

For reference, this change was applied to Clang in https://reviews.llvm.org/
rC341862 and LLVM in https://reviews.llvm.org/rL341862.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products

[PATCH] PR c++/88690 - C++17 ICE with empty base in aggregate.

[Jason Merrill]

Base fields for empty bases appear in initialization order, which may not be
the same as layout order.  If they also show up in a CONSTRUCTOR in that
order, output_constructor_regular_field aborts because it understandably
doesn't want to go backwards.  I also considered making o_c_r_f more
tolerant of the case where the out-of-order field has fieldsize 0, and so no
actual data needs to be emitted, but we might as well avoid adding an
element to the CONSTRUCTOR in the first place.

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

* typeck2.c (process_init_constructor_record): Skip trivial
initialization of an empty base.
---
 gcc/cp/typeck2.c| 7 +++
 gcc/testsuite/g++.dg/cpp1z/aggr-base7.C | 8 
 gcc/cp/ChangeLog| 6 ++
 3 files changed, 21 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/cpp1z/aggr-base7.C

diff --git a/gcc/cp/typeck2.c b/gcc/cp/typeck2.c
index b265ea05741..456c4fcb748 100644
--- a/gcc/cp/typeck2.c
+++ b/gcc/cp/typeck2.c
@@ -1627,6 +1627,13 @@ process_init_constructor_record (tree type, tree init, 
int nested, int flags,
}
}
 
+  if (DECL_SIZE (field) && integer_zerop (DECL_SIZE (field))
+ && !TREE_SIDE_EFFECTS (next))
+   /* Don't add trivial initialization of an empty base/field to the
+  constructor, as they might not be ordered the way the back-end
+  expects.  */
+   continue;
+
   /* If this is a bitfield, now convert to the lowered type.  */
   if (type != TREE_TYPE (field))
next = cp_convert_and_check (TREE_TYPE (field), next, complain);
diff --git a/gcc/testsuite/g++.dg/cpp1z/aggr-base7.C 
b/gcc/testsuite/g++.dg/cpp1z/aggr-base7.C
new file mode 100644
index 000..bc1793e79ca
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1z/aggr-base7.C
@@ -0,0 +1,8 @@
+// PR c++/88690
+// { dg-do compile { target c++11 } }
+
+struct A { int a = 1; };
+struct B { int b = 0; };
+struct C { C() = default; C (const C&) = delete; };
+struct D : public B, public C {};
+struct E : A { D f; } g{};
diff --git a/gcc/cp/ChangeLog b/gcc/cp/ChangeLog
index 3009b58a3b4..89a1bcac80b 100644
--- a/gcc/cp/ChangeLog
+++ b/gcc/cp/ChangeLog
@@ -1,3 +1,9 @@
+2019-02-20  Jason Merrill  
+
+   PR c++/88690 - C++17 ICE with empty base in aggregate.
+   * typeck2.c (process_init_constructor_record): Skip trivial
+   initialization of an empty base.
+
 2019-02-21  Richard Biener  
 
PR middle-end/89392

base-commit: f867b437c79cf560a55b778b947983bb08df158b
-- 
2.20.1

Re: [COMMITTED] Fix pr88850 test

[Wilco Dijkstra]

Hi Christophe,

>> > But my question was more: why skip the test if one forces
>> > -mfloat-abi=softfp while you have this very same option in the
>> > dg-additional-options ?
>> > Isn't it a typo that -mfloat-abi=soft in the "exclude" should use floatfp?
>>
>> I don't know, I just copied the magic hack from other tests. Do you know
>
> Not quite, I think.
> All the other tests in gcc.target/arm that use dg-skip-if with
> -mfloat-abi have the
> "exclude" parameter matching the option in dg-options (when there is an 
> explicit
> "exclude" and dg-options is used).

OK thanks, I've updated the test as suggested and also fixed pr88850-2.c in the
same way:

Like the pr88850.c test, also fix the pr88850-2.c testcase which
was failing in hardfp environments.

Committed as obvious.

ChangeLog:
2019-02-21  Wilco Dijkstra  

* gcc.target/arm/pr88850-2.c: Block -mfloat-abi override.
* gcc.target/arm/pr88850.c: Use -mfloat-abi=softfp.
--
diff --git a/gcc/testsuite/gcc.target/arm/pr88850-2.c 
b/gcc/testsuite/gcc.target/arm/pr88850-2.c
index 
7a1aec55dc70625bd6306e8d6bf094e11afe81bc..f33361ca11d5120726bef2eb8accee8a8b0e2aed
 100644
--- a/gcc/testsuite/gcc.target/arm/pr88850-2.c
+++ b/gcc/testsuite/gcc.target/arm/pr88850-2.c
@@ -1,5 +1,6 @@
 /* PR target/88850.  */
 /* { dg-do compile } */
+/* { dg-skip-if "do not override -mfloat-abi" { *-*-* } { "-mfloat-abi=*" } 
{"-mfloat-abi=softfp" } } */
 /* { dg-additional-options "-O2 -march=armv7-a -fdump-rtl-final" } */
 /* { dg-add-options arm_neon_softfp_fp16 } */
 /* { dg-require-effective-target arm_neon_softfp_fp16_ok } */
diff --git a/gcc/testsuite/gcc.target/arm/pr88850.c 
b/gcc/testsuite/gcc.target/arm/pr88850.c
index 
67fe942a8b8755c18ce8971c3b48011613988a6a..365c9d73696b82653a9f86bf27431a73beee4df4
 100644
--- a/gcc/testsuite/gcc.target/arm/pr88850.c
+++ b/gcc/testsuite/gcc.target/arm/pr88850.c
@@ -1,6 +1,6 @@
 /* PR target/88850 */
 /* { dg-do compile } */
-/* { dg-skip-if "do not override -mfloat-abi" { *-*-* } { "-mfloat-abi=*" } 
{"-mfloat-abi=soft" } } */
+/* { dg-skip-if "do not override -mfloat-abi" { *-*-* } { "-mfloat-abi=*" } 
{"-mfloat-abi=softfp" } } */
 /* { dg-options "-O2 -march=armv7-a -mfloat-abi=softfp -mfpu=neon 
-fdump-rtl-final" } */
 /* { dg-require-effective-target arm_neon_ok } */
 

[PATCH][arm] Add support for Neoverse N1

[Kyrill Tkachov]

Hi all,

This patch adds support for the Neoverse N1 [1]. This CPU was previously 
supported through the Ares codename.

-mcpu=ares is retained as an alias of the new -mcpu=neoverse-n1.

Bootstrapped and tested on arm-none-linux-gnueabihf.

Will commit to trunk together with the aarch64 patch if that one's approved.
Thanks,
Kyrill

[1] 
https://community.arm.com/processors/b/blog/posts/arm-neoverse-n1-platform-accelerating-the-transformation-to-a-scalable-cloud-to-edge-infrastructure


2019-02-21  Kyrylo Tkachov  

    * config/arm/arm-cpus.in (ares): Rename to...
    (neoverse-n1): ... This.  Add ares as alias.
    * config/arm/arm-tables.opt: Regenerate.
    * config/arm/arm-tune.md: Likewise.
    * doc/invoke.txt (ARM Options): Document neoverse-n1.

diff --git a/gcc/config/arm/arm-cpus.in b/gcc/config/arm/arm-cpus.in
index f53bdab8ac9d4a7e2f1ccd9831e7ed13342185ba..3a55f6ac6d2b104400554a7b05cf8d7791341461 100644
--- a/gcc/config/arm/arm-cpus.in
+++ b/gcc/config/arm/arm-cpus.in
@@ -1331,8 +1331,9 @@ begin cpu cortex-a76
  part d0b
 end cpu cortex-a76
 
-begin cpu ares
- cname ares
+begin cpu neoverse-n1
+ cname neoversen1
+ alias !ares
  tune for cortex-a57
  tune flags LDSCHED
  architecture armv8.2-a+fp16+dotprod+simd
@@ -1340,7 +1341,7 @@ begin cpu ares
  costs cortex_a57
  vendor 41
  part d0c
-end cpu ares
+end cpu neoverse-n1
 
 # ARMv8.2 A-profile ARM DynamIQ big.LITTLE implementations
 begin cpu cortex-a75.cortex-a55
diff --git a/gcc/config/arm/arm-tables.opt b/gcc/config/arm/arm-tables.opt
index 99feaa59187ae41c5e218ec3c484d872da06b64f..bba54aea3d604be11f71cc0e2f81e3ee11e7a8e3 100644
--- a/gcc/config/arm/arm-tables.opt
+++ b/gcc/config/arm/arm-tables.opt
@@ -235,7 +235,7 @@ EnumValue
 Enum(processor_type) String(cortex-a76) Value( TARGET_CPU_cortexa76)
 
 EnumValue
-Enum(processor_type) String(ares) Value( TARGET_CPU_ares)
+Enum(processor_type) String(neoverse-n1) Value( TARGET_CPU_neoversen1)
 
 EnumValue
 Enum(processor_type) String(cortex-a75.cortex-a55) Value( TARGET_CPU_cortexa75cortexa55)
diff --git a/gcc/config/arm/arm-tune.md b/gcc/config/arm/arm-tune.md
index 46964376e0f8ef1e170d51752af796dec02d7d96..b9dfb66ec84219d862396c37dd6a587d4a955efe 100644
--- a/gcc/config/arm/arm-tune.md
+++ b/gcc/config/arm/arm-tune.md
@@ -44,7 +44,7 @@ (define_attr "tune"
 	cortexa73,exynosm1,xgene1,
 	cortexa57cortexa53,cortexa72cortexa53,cortexa73cortexa35,
 	cortexa73cortexa53,cortexa55,cortexa75,
-	cortexa76,ares,cortexa75cortexa55,
+	cortexa76,neoversen1,cortexa75cortexa55,
 	cortexa76cortexa55,cortexm23,cortexm33,
 	cortexr52"
 	(const (symbol_ref "((enum attr_tune) arm_tune)")))
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 9e3199f4f87647074482962dc57d1c0c47116fc7..fd367f35daf3db4f11cd40159351579d3f108b91 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -17466,9 +17466,9 @@ Permissible names are: @samp{arm7tdmi}, @samp{arm7tdmi-s}, @samp{arm710t},
 @samp{cortex-m4}, @samp{cortex-m7}, @samp{cortex-m23}, @samp{cortex-m33},
 @samp{cortex-m1.small-multiply}, @samp{cortex-m0.small-multiply},
 @samp{cortex-m0plus.small-multiply}, @samp{exynos-m1}, @samp{marvell-pj4},
-@samp{xscale}, @samp{iwmmxt}, @samp{iwmmxt2}, @samp{ep9312}, @samp{fa526},
-@samp{fa626}, @samp{fa606te}, @samp{fa626te}, @samp{fmp626}, @samp{fa726te},
-@samp{xgene1}.
+@samp{neoverse-n1}, @samp{xscale}, @samp{iwmmxt}, @samp{iwmmxt2},
+@samp{ep9312}, @samp{fa526}, @samp{fa626}, @samp{fa606te}, @samp{fa626te},
+@samp{fmp626}, @samp{fa726te}, @samp{xgene1}.
 
 Additionally, this option can specify that GCC should tune the performance
 of the code for a big.LITTLE system.  Permissible names are:

[PATCH][AArch64] Add support for Neoverse E1

[Kyrill Tkachov]

Hi all,

This patch adds -mcpu and -mtune support for the Neoverse E1 CPU [1].
The new option is -mcpu=neoverse-e1.
Bootstrapped and tested on aarch64-none-linux-gnu.

Ok for trunk?

Thanks,
Kyrill

[1] 
https://community.arm.com/processors/b/blog/posts/arm-neoverse-e1-platform-empowering-the-infrastructure-to-meet-next-generation-throughput-demands


2019-02-21  Kyrylo Tkachov  

    * config/aarch64/aarch64-cores.def (neoverse-e1): Define.
    * config/aarch64/aarch64-tune.md: Regenerate.
    * doc/invoke.texi (AArch64 Options): Document neoverse-e1 -mcpu option.
diff --git a/gcc/config/aarch64/aarch64-cores.def b/gcc/config/aarch64/aarch64-cores.def
index b0c7d2f23ace1e3c3a89f4e3ab10c9ad08f56b22..ed56e5eded13664597343659db859c5ed481627d 100644
--- a/gcc/config/aarch64/aarch64-cores.def
+++ b/gcc/config/aarch64/aarch64-cores.def
@@ -102,6 +102,7 @@ AARCH64_CORE("cortex-a75",  cortexa75, cortexa57, 8_2A,  AARCH64_FL_FOR_ARCH8_2
 AARCH64_CORE("cortex-a76",  cortexa76, cortexa57, 8_2A,  AARCH64_FL_FOR_ARCH8_2 | AARCH64_FL_F16 | AARCH64_FL_RCPC | AARCH64_FL_DOTPROD, cortexa72, 0x41, 0xd0b, -1)
 AARCH64_CORE("ares",  ares, cortexa57, 8_2A,  AARCH64_FL_FOR_ARCH8_2 | AARCH64_FL_F16 | AARCH64_FL_RCPC | AARCH64_FL_DOTPROD | AARCH64_FL_PROFILE, neoversen1, 0x41, 0xd0c, -1)
 AARCH64_CORE("neoverse-n1",  neoversen1, cortexa57, 8_2A,  AARCH64_FL_FOR_ARCH8_2 | AARCH64_FL_F16 | AARCH64_FL_RCPC | AARCH64_FL_DOTPROD | AARCH64_FL_PROFILE, neoversen1, 0x41, 0xd0c, -1)
+AARCH64_CORE("neoverse-e1",  neoversee1, cortexa53, 8_2A,  AARCH64_FL_FOR_ARCH8_2 | AARCH64_FL_F16 | AARCH64_FL_RCPC | AARCH64_FL_DOTPROD | AARCH64_FL_SSBS, cortexa53, 0x41, 0xd4a, -1)
 
 /* HiSilicon ('H') cores. */
 AARCH64_CORE("tsv110",  tsv110, cortexa57, 8_2A,  AARCH64_FL_FOR_ARCH8_2 | AARCH64_FL_CRYPTO | AARCH64_FL_F16 | AARCH64_FL_AES | AARCH64_FL_SHA2, tsv110,   0x48, 0xd01, -1)
diff --git a/gcc/config/aarch64/aarch64-tune.md b/gcc/config/aarch64/aarch64-tune.md
index 5b1341525e9c2e3fe6306e7c9fef41f5d658420c..2b1ec85ae3190ec62f70d8abacd88e825244f2b1 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"
-	"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,ares,neoversen1,tsv110,saphira,cortexa57cortexa53,cortexa72cortexa53,cortexa73cortexa35,cortexa73cortexa53,cortexa75cortexa55,cortexa76cortexa55"
+	"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,ares,neoversen1,neoversee1,tsv110,saphira,cortexa57cortexa53,cortexa72cortexa53,cortexa73cortexa35,cortexa73cortexa53,cortexa75cortexa55,cortexa76cortexa55"
 	(const (symbol_ref "((enum attr_tune) aarch64_tune)")))
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 8ecc28c4acccd619ff9dcc25202fcf87582145a4..24513970e0508611c4810aabbb6089dca7d5501c 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -15771,10 +15771,11 @@ performance of the code.  Permissible values for this option are:
 @samp{generic}, @samp{cortex-a35}, @samp{cortex-a53}, @samp{cortex-a55},
 @samp{cortex-a57}, @samp{cortex-a72}, @samp{cortex-a73}, @samp{cortex-a75},
 @samp{cortex-a76}, @samp{ares}, @samp{exynos-m1}, @samp{emag}, @samp{falkor},
-@samp{neoverse-n1},@samp{qdf24xx}, @samp{saphira}, @samp{phecda}, @samp{xgene1},
-@samp{vulcan}, @samp{octeontx}, @samp{octeontx81},  @samp{octeontx83},
-@samp{thunderx}, @samp{thunderxt88}, @samp{thunderxt88p1}, @samp{thunderxt81},
-@samp{tsv110}, @samp{thunderxt83}, @samp{thunderx2t99},
+@samp{neoverse-e1},@samp{neoverse-n1},@samp{qdf24xx}, @samp{saphira},
+@samp{phecda}, @samp{xgene1}, @samp{vulcan}, @samp{octeontx},
+@samp{octeontx81},  @samp{octeontx83}, @samp{thunderx}, @samp{thunderxt88},
+@samp{thunderxt88p1}, @samp{thunderxt81}, @samp{tsv110},
+@samp{thunderxt83}, @samp{thunderx2t99},
 @samp{cortex-a57.cortex-a53}, @samp{cortex-a72.cortex-a53},
 @samp{cortex-a73.cortex-a35}, @samp{cortex-a73.cortex-a53},
 @samp{cortex-a75.cortex-a55}, @samp{cortex-a76.cortex-a55}

[PATCH][AArch64] Add support for Neoverse N1

[Kyrill Tkachov]

Hi all,

This patch adds support for the Neoverse N1 CPU [1]. This was supported 
in GCC earlier through the codename Ares,
which it now replaces. -mcpu=ares is still accepted as there's been a 
binutils release supporting it,
but the internal structures are renamed to use Neoverse N1-related 
identifiers.


Bootstrapped and tested on aarch64-none-linux-gnu.

Ok for trunk?
Thanks,
Kyrill

[1] 
https://community.arm.com/processors/b/blog/posts/arm-neoverse-n1-platform-accelerating-the-transformation-to-a-scalable-cloud-to-edge-infrastructure


2019-02-21  Kyrylo Tkachov  

    * config/aarch64/aarch64.c (ares_tunings): Rename to...
    (neoversen1_tunings): ... This.
    * config/aarch64/aarch64-cores.def (ares): Change tuning to the above.
    (neoverse-n1): New CPU.
    * config/aarch64/aarch64-tune.md: Regenerate.
    * doc/invoke.txt (AArch64 Options): Document neoverse-n1.

diff --git a/gcc/config/aarch64/aarch64-cores.def b/gcc/config/aarch64/aarch64-cores.def
index 7c4bd52049e5ae33241acce37414da91abaa989c..b0c7d2f23ace1e3c3a89f4e3ab10c9ad08f56b22 100644
--- a/gcc/config/aarch64/aarch64-cores.def
+++ b/gcc/config/aarch64/aarch64-cores.def
@@ -100,7 +100,8 @@ AARCH64_CORE("thunderx2t99",  thunderx2t99,  thunderx2t99, 8_1A,  AARCH64_FL_FOR
 AARCH64_CORE("cortex-a55",  cortexa55, cortexa53, 8_2A,  AARCH64_FL_FOR_ARCH8_2 | AARCH64_FL_F16 | AARCH64_FL_RCPC | AARCH64_FL_DOTPROD, cortexa53, 0x41, 0xd05, -1)
 AARCH64_CORE("cortex-a75",  cortexa75, cortexa57, 8_2A,  AARCH64_FL_FOR_ARCH8_2 | AARCH64_FL_F16 | AARCH64_FL_RCPC | AARCH64_FL_DOTPROD, cortexa73, 0x41, 0xd0a, -1)
 AARCH64_CORE("cortex-a76",  cortexa76, cortexa57, 8_2A,  AARCH64_FL_FOR_ARCH8_2 | AARCH64_FL_F16 | AARCH64_FL_RCPC | AARCH64_FL_DOTPROD, cortexa72, 0x41, 0xd0b, -1)
-AARCH64_CORE("ares",  ares, cortexa57, 8_2A,  AARCH64_FL_FOR_ARCH8_2 | AARCH64_FL_F16 | AARCH64_FL_RCPC | AARCH64_FL_DOTPROD | AARCH64_FL_PROFILE, ares, 0x41, 0xd0c, -1)
+AARCH64_CORE("ares",  ares, cortexa57, 8_2A,  AARCH64_FL_FOR_ARCH8_2 | AARCH64_FL_F16 | AARCH64_FL_RCPC | AARCH64_FL_DOTPROD | AARCH64_FL_PROFILE, neoversen1, 0x41, 0xd0c, -1)
+AARCH64_CORE("neoverse-n1",  neoversen1, cortexa57, 8_2A,  AARCH64_FL_FOR_ARCH8_2 | AARCH64_FL_F16 | AARCH64_FL_RCPC | AARCH64_FL_DOTPROD | AARCH64_FL_PROFILE, neoversen1, 0x41, 0xd0c, -1)
 
 /* HiSilicon ('H') cores. */
 AARCH64_CORE("tsv110",  tsv110, cortexa57, 8_2A,  AARCH64_FL_FOR_ARCH8_2 | AARCH64_FL_CRYPTO | AARCH64_FL_F16 | AARCH64_FL_AES | AARCH64_FL_SHA2, tsv110,   0x48, 0xd01, -1)
diff --git a/gcc/config/aarch64/aarch64-tune.md b/gcc/config/aarch64/aarch64-tune.md
index 3273fa0ce7c87ff41d5f664cf9f47163725efa3e..5b1341525e9c2e3fe6306e7c9fef41f5d658420c 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"
-	"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,ares,tsv110,saphira,cortexa57cortexa53,cortexa72cortexa53,cortexa73cortexa35,cortexa73cortexa53,cortexa75cortexa55,cortexa76cortexa55"
+	"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,ares,neoversen1,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 687611d1069c3c77fdacafad681b3b12d47e6d74..796a33e0677b933b321d8d1a193125cb894efdef 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -1085,7 +1085,7 @@ static const struct tune_params thunderx2t99_tunings =
   _prefetch_tune
 };
 
-static const struct tune_params ares_tunings =
+static const struct tune_params neoversen1_tunings =
 {
   _extra_costs,
   _addrcost_table,
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 8656dfd24cc293e1f770cb3875bb6a8a99be6f54..9e3199f4f87647074482962dc57d1c0c47116fc7 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -15767,8 +15767,8 @@ performance of the code.  Permissible values for this option are:
 @samp{generic}, @samp{cortex-a35}, @samp{cortex-a53}, @samp{cortex-a55},
 @samp{cortex-a57}, @samp{cortex-a72}, @samp{cortex-a73}, @samp{cortex-a75},
 @samp{cortex-a76}, @samp{ares}, @samp{exynos-m1}, @samp{emag}, @samp{falkor},
-@samp{qdf24xx}, @samp{saphira}, @samp{phecda}, @samp{xgene1}, @samp{vulcan},
-@samp{octeontx}, @samp{octeontx81},  @samp{octeontx83},
+@samp{neoverse-n1},@samp{qdf24xx}, @samp{saphira}, @samp{phecda}, @samp{xgene1},
+@samp{vulcan}, 

Re: [PATCH] [8/9 Regression] i386: Add pass_remove_partial_avx_dependency

[H.J. Lu]

On Thu, Feb 21, 2019 at 5:58 AM Jan Hubicka  wrote:
>
> Hello,
>
> 2019-02-01  H.J. Lu  
> Hongtao Liu  
> Sunil K Pandey  
>
> PR target/87007
> * config/i386/i386-passes.def: Add
> pass_remove_partial_avx_dependency.
> * config/i386/i386-protos.h
> (make_pass_remove_partial_avx_dependency): New.
> * config/i386/i386.c (make_pass_remove_partial_avx_dependency):
> New function.
> (pass_data_remove_partial_avx_dependency): New.
> (pass_remove_partial_avx_dependency): Likewise.
> (make_pass_remove_partial_avx_dependency): Likewise.
> * config/i386/i386.md (partial_xmm_update): New attribute.
> (*extendsfdf2): Add partial_xmm_update.
> (truncdfsf2): Likewise.
> (*float2): Likewise.
> (SF/DF conversion splitters): Disabled for TARGET_AVX.
>
> gcc/testsuite/
>
> 2019-02-01  H.J. Lu  
> Hongtao Liu  
> Sunil K Pandey  
>
> PR target/87007
> * gcc.target/i386/pr87007-1.c: New test.
> * gcc.target/i386/pr87007-2.c: Likewise.
>
>
> It seems to me that more systematic way would be to use mode switching
> pass that uses the LCM framework and possibly tweak LCM to do the right
> thing with respect to loops (easy solution would be to lift insertion
> points to the dominators with smaller frequency even if there may be path
> that does not execute the instruction needing the pxor).
>
> Teaching LCM framework is however more intrusive than self contained
> minipass and Since the patch solves a regression and is self contained I
> guess we should go ahead with it for this release and look for more
> systematic solutions later.
>
> Patch is OK with the following change.
>
> +static unsigned int
> +remove_partial_avx_dependency (void)
> +{
> +  timevar_push (TV_MACH_DEP);
> +
> +  calculate_dominance_info (CDI_DOMINATORS);
> +  df_set_flags (DF_DEFER_INSN_RESCAN);
> +  df_chain_add_problem (DF_DU_CHAIN | DF_UD_CHAIN);
> +  df_md_add_problem ();
> +  df_analyze ();
>
> Please delay the initialization after you hit first instruction that

I changed it to:

  if (v4sf_const0)
{
  calculate_dominance_info (CDI_DOMINATORS);
  df_set_flags (DF_DEFER_INSN_RESCAN);
  df_chain_add_problem (DF_DU_CHAIN | DF_UD_CHAIN);
  df_md_add_problem ();
  df_analyze ();

  /* (Re-)discover loops so that bb->loop_father can be used in the
 analysis below.  */
  loop_optimizer_init (AVOID_CFG_MODIFICATIONS);

  /* Generate a vxorps at entry of the nearest dominator for basic
 blocks with conversions, which is in the the fake loop that
 contains the whole function, so that there is only a single
 vxorps in the whole function.   */
  bb = nearest_common_dominator_for_set (CDI_DOMINATORS,
 convert_bbs);
  while (bb->loop_father->latch
 != EXIT_BLOCK_PTR_FOR_FN (cfun))
bb = get_immediate_dominator (CDI_DOMINATORS,
  bb->loop_father->header);

  insn = BB_HEAD (bb);
  if (!NONDEBUG_INSN_P (insn))
insn = next_nonnote_nondebug_insn (insn);
  set = gen_rtx_SET (v4sf_const0, CONST0_RTX (V4SFmode));
  set_insn = emit_insn_before (set, insn);
  df_insn_rescan (set_insn);
  df_process_deferred_rescans ();
  loop_optimizer_finalize ();
}

> needs processing.  The pass is run unconditionally and in many functions
> it will do noting. Can you also gate the pass to run only of AVX is
> enabled?

There are

 virtual bool gate (function *)
{
  return (TARGET_AVX
  && TARGET_SSE_PARTIAL_REG_DEPENDENCY
  && TARGET_SSE_MATH
  && optimize
  && optimize_function_for_speed_p (cfun));
}

> Patch is OK with this change. Please way a day for possible Uros' or RM
> reactions.  Sorry for the delayed reaction.
> Honza

This is the updated patch I am going to check in tomorrow.

Thanks.

-- 
H.J.
From 0385aa137a1b553586cf786c331b0c167c5e2631 Mon Sep 17 00:00:00 2001
From: "H.J. Lu" 
Date: Mon, 7 Jan 2019 05:44:59 -0800
Subject: [PATCH] [8/9 Regression] i386: Add pass_remove_partial_avx_dependency

With -mavx, for

$ cat foo.i
extern float f;
extern double d;
extern int i;

void
foo (void)
{
  d = f;
  f = i;
}

we need to generate

	vxorp[ds]	%xmmN, %xmmN, %xmmN
	...
	vcvtss2sd	f(%rip), %xmmN, %xmmX
	...
	vcvtsi2ss	i(%rip), %xmmN, %xmmY

to avoid partial XMM register stall.  This patch adds a pass to generate
a single

	vxorps		%xmmN, %xmmN, %xmmN

at entry of the nearest dominator for basic blocks with SF/DF conversions,
which is in the fake loop that contains the whole function, instead of
generating one

	vxorp[ds]	%xmmN, %xmmN, %xmmN

for each SF/DF conversion.

NB: The LCM algorithm isn't appropriate here since it may place a vxorps
inside the loop.  Simple testcase show this:

$ cat badcase.c

extern float f;

Re: [PATCH] Fix PR89437

[Wilco Dijkstra]

Hi Richard,

>>Fix an issue with sinl (atanl (sqrtl (LDBL_MAX)) returning 0.0
>>instead of 1.0 by using x < sqrtl (LDBL_MAX) in match.pd.
>
> Wasn't that a intermediate problem with the mpfr exponent range limiting? 
> Please check whether that's still needed. 

I tested it with trunk about an hour ago, and it included Jacub's patch.
Are there other fixes outstanding which haven't been committed yet?

Latest trunk also still gives an assertion failure in mpc with the 
gcc.dg/torture/builtin-math-5.c
which started at the same time as the other mpc/mpfr releated issues:

build/src/mpc/src/pow.c:631: MPC assertion failed: z_imag || mpfr_number_p 
(MPC_RE(u))
build/src/gcc/gcc/testsuite/gcc.dg/torture/builtin-math-5.c:95:3: internal 
compiler error: Aborted
0x6725ab crash_signal
build/src/gcc/gcc/toplev.c:326

Wilco

Re: [PATCH] Fix PR89437

[Giuliano Belinassi]

I've just submitted a patch for this too :-P. Sorry about that.

What is your nick in IRC, Wilco?


On 02/21, Wilco Dijkstra wrote:
> Fix PR89437. Fix the sinatan-1.c testcase to not run without
> a C99 target system.  Use nextafterl for long double initialization.
> 
> Fix an issue with sinl (atanl (sqrtl (LDBL_MAX)) returning 0.0
> instead of 1.0 by using x < sqrtl (LDBL_MAX) in match.pd.
> 
> OK for commit?
> 
> ChangeLog:
> 2019-02-21  Wilco Dijkstra  
> 
> gcc/
>   * match.pd: Use lt in sin(atan(x)) and cos(atan(x)) simplifications.
> 
> testsuite/
>   * gcc.dg/sinatan-1.c: Fix testcase.
> --
> diff --git a/gcc/match.pd b/gcc/match.pd
> index 
> bccf4df05a2f94785446719b3097b3f912fafe96..c9af2e59441c4fe19e88d94c9d138ae35dfe673f
>  100644
> --- a/gcc/match.pd
> +++ b/gcc/match.pd
> @@ -4407,7 +4407,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
>tree t_one = build_one_cst (type);
>   }
>  (if (SCALAR_FLOAT_TYPE_P (type))
> - (cond (le (abs @0) { t_cst; })
> + (cond (lt (abs @0) { t_cst; })
>(rdiv @0 (sqrts (plus (mult @0 @0) { t_one; })))
>(copysigns { t_one; } @0))
>  
> @@ -4427,7 +4427,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
>tree t_zero = build_zero_cst (type);
>   }
>  (if (SCALAR_FLOAT_TYPE_P (type))
> - (cond (le (abs @0) { t_cst; })
> + (cond (lt (abs @0) { t_cst; })
>(rdiv { t_one; } (sqrts (plus (mult @0 @0) { t_one; })))
>(copysigns { t_zero; } @0))
>  
> diff --git a/gcc/testsuite/gcc.dg/sinatan-1.c 
> b/gcc/testsuite/gcc.dg/sinatan-1.c
> index 
> 6a3995ae07949a423e416592276171b6e6f8c816..cfbb771a018d3175c680dce88e0121e469716edc
>  100644
> --- a/gcc/testsuite/gcc.dg/sinatan-1.c
> +++ b/gcc/testsuite/gcc.dg/sinatan-1.c
> @@ -1,4 +1,4 @@
> -/* { dg-do run } */
> +/* { dg-do run { target c99_runtime } } */
>  /* { dg-options "-Ofast" } */
>  /* { dg-add-options ieee } */
>  
> @@ -62,7 +62,7 @@ main()
>  /* Get first x such that 1 + x*x will overflow */
>  float fc = nextafterf (sqrtf (__FLT_MAX__ - 1), __FLT_MAX__);
>  double c = nextafter (sqrt (__DBL_MAX__ - 1), __DBL_MAX__);
> -long double lc = nextafter (sqrtl (__LDBL_MAX__ - 1), __LDBL_MAX__);
> +long double lc = nextafterl (sqrtl (__LDBL_MAX__ - 1), __LDBL_MAX__);
>  
>  /*  Force move from FPU to memory, otherwise comparison may
>  fail due to possible more accurate registers (see 387)  */

[PATCH] Fix 89437, incorrect result for sinl ( atanl (x))

[Giuliano Belinassi]

A incorrect call to `nextafter` instead of `nextafterl` made the
test `sinatan-1.c` pass, when it should have failed. The cause of
the failure is pointed out in PR89437. This patch addresses
the cause of failure, as well the issue in the test.

gcc/ChangeLog:
2019-02-21  Giuliano Belinassi  

PR tree-optimization/89437
* match.pd (sin (atan (x))): Change 'le' to 'lt'.
(cos (atan (x))): Likewise.


gcc/testsuite/gcc.dg/ChangeLog:
2019-02-21  Giuliano Belinassi  

PR tree-optimization/89437
* sinatan-1.c: Addressed incorrect `nextafter` call.
Index: gcc/match.pd
===
--- gcc/match.pd	(revision 268655)
+++ gcc/match.pd	(working copy)
@@ -4407,7 +4407,7 @@
   tree t_one = build_one_cst (type);
  }
 (if (SCALAR_FLOAT_TYPE_P (type))
- (cond (le (abs @0) { t_cst; })
+ (cond (lt (abs @0) { t_cst; })
   (rdiv @0 (sqrts (plus (mult @0 @0) { t_one; })))
   (copysigns { t_one; } @0))
 
@@ -4427,7 +4427,7 @@
   tree t_zero = build_zero_cst (type);
  }
 (if (SCALAR_FLOAT_TYPE_P (type))
- (cond (le (abs @0) { t_cst; })
+ (cond (lt (abs @0) { t_cst; })
   (rdiv { t_one; } (sqrts (plus (mult @0 @0) { t_one; })))
   (copysigns { t_zero; } @0))
 
Index: gcc/testsuite/gcc.dg/sinatan-1.c
===
--- gcc/testsuite/gcc.dg/sinatan-1.c	(revision 268655)
+++ gcc/testsuite/gcc.dg/sinatan-1.c	(working copy)
@@ -62,7 +62,7 @@
 /* Get first x such that 1 + x*x will overflow */
 float fc = nextafterf (sqrtf (__FLT_MAX__ - 1), __FLT_MAX__);
 double c = nextafter (sqrt (__DBL_MAX__ - 1), __DBL_MAX__);
-long double lc = nextafter (sqrtl (__LDBL_MAX__ - 1), __LDBL_MAX__);
+long double lc = nextafterl (sqrtl (__LDBL_MAX__ - 1), __LDBL_MAX__);
 
 /*  Force move from FPU to memory, otherwise comparison may
 fail due to possible more accurate registers (see 387)  */
@@ -90,7 +90,7 @@
 
 if (fy != -1.f || y != -1. || ly != -1.L)
 abort ();
-
+
 fy = cosatanf (-fc);
 y = cosatan (-c);
 ly = cosatanl (-lc);

Re: [PATCH] Fix PR89437

[Richard Biener]

On February 21, 2019 4:55:57 PM GMT+01:00, Wilco Dijkstra 
 wrote:
>Fix PR89437. Fix the sinatan-1.c testcase to not run without
>a C99 target system.  Use nextafterl for long double initialization.

OK. 

>Fix an issue with sinl (atanl (sqrtl (LDBL_MAX)) returning 0.0
>instead of 1.0 by using x < sqrtl (LDBL_MAX) in match.pd.

Wasn't that a intermediate problem with the mpfr exponent range limiting? 
Please check whether that's still needed. 

Richard. 

>OK for commit?
>
>ChangeLog:
>2019-02-21  Wilco Dijkstra  
>
>gcc/
>   * match.pd: Use lt in sin(atan(x)) and cos(atan(x)) simplifications.
>
>testsuite/
>   * gcc.dg/sinatan-1.c: Fix testcase.
>--
>diff --git a/gcc/match.pd b/gcc/match.pd
>index
>bccf4df05a2f94785446719b3097b3f912fafe96..c9af2e59441c4fe19e88d94c9d138ae35dfe673f
>100644
>--- a/gcc/match.pd
>+++ b/gcc/match.pd
>@@ -4407,7 +4407,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
>   tree t_one = build_one_cst (type);
>  }
> (if (SCALAR_FLOAT_TYPE_P (type))
>- (cond (le (abs @0) { t_cst; })
>+ (cond (lt (abs @0) { t_cst; })
>   (rdiv @0 (sqrts (plus (mult @0 @0) { t_one; })))
>   (copysigns { t_one; } @0))
> 
>@@ -4427,7 +4427,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
>   tree t_zero = build_zero_cst (type);
>  }
> (if (SCALAR_FLOAT_TYPE_P (type))
>- (cond (le (abs @0) { t_cst; })
>+ (cond (lt (abs @0) { t_cst; })
>   (rdiv { t_one; } (sqrts (plus (mult @0 @0) { t_one; })))
>   (copysigns { t_zero; } @0))
> 
>diff --git a/gcc/testsuite/gcc.dg/sinatan-1.c
>b/gcc/testsuite/gcc.dg/sinatan-1.c
>index
>6a3995ae07949a423e416592276171b6e6f8c816..cfbb771a018d3175c680dce88e0121e469716edc
>100644
>--- a/gcc/testsuite/gcc.dg/sinatan-1.c
>+++ b/gcc/testsuite/gcc.dg/sinatan-1.c
>@@ -1,4 +1,4 @@
>-/* { dg-do run } */
>+/* { dg-do run { target c99_runtime } } */
> /* { dg-options "-Ofast" } */
> /* { dg-add-options ieee } */
> 
>@@ -62,7 +62,7 @@ main()
> /* Get first x such that 1 + x*x will overflow */
> float fc = nextafterf (sqrtf (__FLT_MAX__ - 1), __FLT_MAX__);
> double c = nextafter (sqrt (__DBL_MAX__ - 1), __DBL_MAX__);
>-long double lc = nextafter (sqrtl (__LDBL_MAX__ - 1),
>__LDBL_MAX__);
>+long double lc = nextafterl (sqrtl (__LDBL_MAX__ - 1),
>__LDBL_MAX__);
> 
> /*  Force move from FPU to memory, otherwise comparison may
> fail due to possible more accurate registers (see 387)  */

Re: [PATCH 2/2][GCC][Arm] Update Armv8.4-a's FP16 FML intrinsics

[Kyrill Tkachov]

Hi Tamar,

On 2/20/19 1:59 PM, Tamar Christina wrote:

Hi All,

This patch updates the Armv8.4-a FP16 FML intrinsics's suffixes from 
u32 to f16

to be more consistent with the naming convention for intrinsics.

The specifications for these intrinsics have not been published yet so 
we do

not need to maintain the old names.

The patch was created with the following script:

grep -lIE "(vfml[as].+)_u32" -r gcc/ | grep -iEv ".+Changelog.*" \
  | xargs sed -i -E -e "s/(vfml[as].+)_u32/\1_f16/g"

Bootstrapped Regtested on arm-none-gnueabihf and no issues.

Ok for trunk? and eventual backport to GCC 8?

Ok, but please only commit this together with the AArch64 patch if it's 
approved.


I'd rather we be consistent with aarch64 on this.

Thanks,

Kyrill



Thanks,
Tamar

gcc/ChangeLog:

2019-02-20  Tamar Christina  

    * config/arm/arm_neon.h (vfmlal_low_u32, vfmlsl_low_u32,
    vfmlal_high_u32, vfmlsl_high_u32, vfmlalq_low_u32, 
vfmlslq_low_u32,

    vfmlalq_high_u32, vfmlslq_high_u32, vfmlal_lane_low_u32,
    vfmlal_lane_high_u32, vfmlalq_laneq_low_u32, vfmlalq_lane_low_u32,
    vfmlal_laneq_low_u32, vfmlalq_laneq_high_u32, 
vfmlalq_lane_high_u32,

    vfmlal_laneq_high_u32, vfmlsl_lane_low_u32, vfmlsl_lane_high_u32,
    vfmlslq_laneq_low_u32, vfmlslq_lane_low_u32, vfmlsl_laneq_low_u32,
    vfmlslq_laneq_high_u32, vfmlslq_lane_high_u32, 
vfmlsl_laneq_high_u32):

    Rename ...
    (vfmlal_low_f16, vfmlsl_low_f16, vfmlal_high_f16, vfmlsl_high_f16,
    vfmlalq_low_f16, vfmlslq_low_f16, vfmlalq_high_f16, 
vfmlslq_high_f16,

    vfmlal_lane_low_f16, vfmlal_lane_high_f16, vfmlalq_laneq_low_f16,
    vfmlalq_lane_low_f16, vfmlal_laneq_low_f16, 
vfmlalq_laneq_high_f16,

    vfmlalq_lane_high_f16, vfmlal_laneq_high_f16, vfmlsl_lane_low_f16,
    vfmlsl_lane_high_f16, vfmlslq_laneq_low_f16, vfmlslq_lane_low_f16,
    vfmlsl_laneq_low_f16, vfmlslq_laneq_high_f16, 
vfmlslq_lane_high_f16,

    vfmlsl_laneq_high_f16): ... To this.
    * config/arm/neon.md: Update comments.

gcc/testsuite/ChangeLog:

2019-02-20  Tamar Christina  

    * gcc.target/arm/simd/fp16fml_high.c (test_vfmlal_high_u32,
    test_vfmlalq_high_u32, test_vfmlsl_high_u32, 
test_vfmlslq_high_u32):

    Rename 
    (test_vfmlal_high_f16, test_vfmlalq_high_f16, 
test_vfmlsl_high_f16,

    test_vfmlslq_high_f16): ... To this.
    * gcc.target/arm/simd/fp16fml_lane_high.c 
(test_vfmlal_lane_high_u32,

    tets_vfmlsl_lane_high_u32, test_vfmlal_laneq_high_u32,
    test_vfmlsl_laneq_high_u32, test_vfmlalq_lane_high_u32,
    test_vfmlslq_lane_high_u32, test_vfmlalq_laneq_high_u32,
    test_vfmlslq_laneq_high_u32): Rename ...
    (test_vfmlal_lane_high_f16, tets_vfmlsl_lane_high_f16,
    test_vfmlal_laneq_high_f16, test_vfmlsl_laneq_high_f16,
    test_vfmlalq_lane_high_f16, test_vfmlslq_lane_high_f16,
    test_vfmlalq_laneq_high_f16, test_vfmlslq_laneq_high_f16): ... 
To this.
    * gcc.target/arm/simd/fp16fml_lane_low.c 
(test_vfmlal_lane_low_u32,

    test_vfmlsl_lane_low_u32, test_vfmlal_laneq_low_u32,
    test_vfmlsl_laneq_low_u32, test_vfmlalq_lane_low_u32,
    test_vfmlslq_lane_low_u32, test_vfmlalq_laneq_low_u32,
    test_vfmlslq_laneq_low_u32): Rename ...
    (test_vfmlal_lane_low_f16, test_vfmlsl_lane_low_f16,
    test_vfmlal_laneq_low_f16, test_vfmlsl_laneq_low_f16,
    test_vfmlalq_lane_low_f16, test_vfmlslq_lane_low_f16,
    test_vfmlalq_laneq_low_f16, test_vfmlslq_laneq_low_f16): ... 
To this.

    * gcc.target/arm/simd/fp16fml_low.c (test_vfmlal_low_u32,
    test_vfmlalq_low_u32, test_vfmlsl_low_u32, test_vfmlslq_low_u32):
    Rename ...
    (test_vfmlal_low_f16, test_vfmlalq_low_f16, test_vfmlsl_low_f16,
    test_vfmlslq_low_f16): ... To this.

--

Re: PING^1: [PATCH] i386: Check -mindirect-branch/-mfunction-return with -fcf-protection

[H.J. Lu]

On Thu, Feb 21, 2019 at 5:34 AM Jan Hubicka  wrote:
>
> > On Tue, Sep 25, 2018 at 6:50 AM H.J. Lu  wrote:
> > >
> > > Issue an error when -mindirect-branch or -mfunction-return are used
> > > with incompatible -fcf-protection.
> > >
> > > gcc/
> > >
> > > PR target/87412
> > > * config/i386/i386.c (ix86_set_indirect_branch_type): Issue an
> > > error for -mindirect-branch/-mfunction-return with incompatible
> > > -fcf-protection.
> > >
> > > gcc/testsuite/
> > >
> > > PR target/87412
> > > * gcc.target/i386/pr87412-1.c: New file.
> > > * gcc.target/i386/pr87412-2.c: Likewise.
> > > * gcc.target/i386/pr87412-3.c: Likewise.
> > > * gcc.target/i386/pr87412-4.c: Likewise.
>
> OK,
> thanks!
> Honza

I am checking in this patch to replace -fcf-protection with
-fcf-protection=branch
in a couple -mindirect-branch tests.

-- 
H.J.
From fc3c8f2dfc3e544233ea92fb05e6bbe9eb496103 Mon Sep 17 00:00:00 2001
From: "H.J. Lu" 
Date: Thu, 21 Feb 2019 08:12:12 -0800
Subject: [PATCH] i386: Replace -fcf-protection with -fcf-protection=branch

Since -mindirect-branch is incompatible with -fcf-protection=return and
-fcf-protection, replace -fcf-protection with -fcf-protection=branch.

	PR target/87412
	* gcc.target/i386/indirect-thunk-attr-14.c: Replace
	-fcf-protection with -fcf-protection=branch.
	* gcc.target/i386/indirect-thunk-attr-15.c: Likewise.
	* gcc.target/i386/indirect-thunk-attr-16.c: Likewise.
	* gcc.target/i386/indirect-thunk-extern-8.c: Likewise.
	* gcc.target/i386/indirect-thunk-extern-9.c: Likewise.
	* gcc.target/i386/indirect-thunk-extern-10.c: Likewise.
---
 gcc/testsuite/gcc.target/i386/indirect-thunk-attr-14.c   | 2 +-
 gcc/testsuite/gcc.target/i386/indirect-thunk-attr-15.c   | 2 +-
 gcc/testsuite/gcc.target/i386/indirect-thunk-attr-16.c   | 2 +-
 gcc/testsuite/gcc.target/i386/indirect-thunk-extern-10.c | 2 +-
 gcc/testsuite/gcc.target/i386/indirect-thunk-extern-8.c  | 2 +-
 gcc/testsuite/gcc.target/i386/indirect-thunk-extern-9.c  | 2 +-
 6 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-14.c b/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-14.c
index eb25139da6d..8516be5c8a6 100644
--- a/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-14.c
+++ b/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-14.c
@@ -1,5 +1,5 @@
 /* { dg-do compile { target *-*-linux* } } */
-/* { dg-options "-O2 -mno-indirect-branch-register -mfunction-return=keep -fno-pic -fplt -mindirect-branch=keep -fcf-protection" } */
+/* { dg-options "-O2 -mno-indirect-branch-register -mfunction-return=keep -fno-pic -fplt -mindirect-branch=keep -fcf-protection=branch" } */
 
 extern void (*bar) (void);
 
diff --git a/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-15.c b/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-15.c
index 1ad459e3b19..28eafbafe39 100644
--- a/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-15.c
+++ b/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-15.c
@@ -1,5 +1,5 @@
 /* { dg-do compile { target *-*-linux* } } */
-/* { dg-options "-O2 -mindirect-branch-register -mfunction-return=keep -fno-pic -fplt -mindirect-branch=keep -fcf-protection" } */
+/* { dg-options "-O2 -mindirect-branch-register -mfunction-return=keep -fno-pic -fplt -mindirect-branch=keep -fcf-protection=branch" } */
 
 extern void (*bar) (void);
 
diff --git a/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-16.c b/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-16.c
index 86fe035bc9a..737d85d48e8 100644
--- a/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-16.c
+++ b/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-16.c
@@ -1,5 +1,5 @@
 /* { dg-do compile { target *-*-linux* } } */
-/* { dg-options "-O2 -mindirect-branch-register -mfunction-return=keep -fno-pic -fplt -mindirect-branch=keep -fcf-protection" } */
+/* { dg-options "-O2 -mindirect-branch-register -mfunction-return=keep -fno-pic -fplt -mindirect-branch=keep -fcf-protection=branch" } */
 
 extern void (*bar) (void) __attribute__((nocf_check));
 
diff --git a/gcc/testsuite/gcc.target/i386/indirect-thunk-extern-10.c b/gcc/testsuite/gcc.target/i386/indirect-thunk-extern-10.c
index 95731d6f365..539781c492a 100644
--- a/gcc/testsuite/gcc.target/i386/indirect-thunk-extern-10.c
+++ b/gcc/testsuite/gcc.target/i386/indirect-thunk-extern-10.c
@@ -1,5 +1,5 @@
 /* { dg-do compile { target *-*-linux* } } */
-/* { dg-options "-O2 -mindirect-branch-register -mfunction-return=keep -fno-pic -fplt -mindirect-branch=thunk-extern -fcf-protection" } */
+/* { dg-options "-O2 -mindirect-branch-register -mfunction-return=keep -fno-pic -fplt -mindirect-branch=thunk-extern -fcf-protection=branch" } */
 
 extern void (*bar) (void) __attribute__((nocf_check));
 
diff --git a/gcc/testsuite/gcc.target/i386/indirect-thunk-extern-8.c b/gcc/testsuite/gcc.target/i386/indirect-thunk-extern-8.c
index 0c61516732a..2cef59de5ab 100644
--- 

[PATCH] Fix PR89437

[Wilco Dijkstra]

Fix PR89437. Fix the sinatan-1.c testcase to not run without
a C99 target system.  Use nextafterl for long double initialization.

Fix an issue with sinl (atanl (sqrtl (LDBL_MAX)) returning 0.0
instead of 1.0 by using x < sqrtl (LDBL_MAX) in match.pd.

OK for commit?

ChangeLog:
2019-02-21  Wilco Dijkstra  

gcc/
* match.pd: Use lt in sin(atan(x)) and cos(atan(x)) simplifications.

testsuite/
* gcc.dg/sinatan-1.c: Fix testcase.
--
diff --git a/gcc/match.pd b/gcc/match.pd
index 
bccf4df05a2f94785446719b3097b3f912fafe96..c9af2e59441c4fe19e88d94c9d138ae35dfe673f
 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -4407,7 +4407,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
   tree t_one = build_one_cst (type);
  }
 (if (SCALAR_FLOAT_TYPE_P (type))
- (cond (le (abs @0) { t_cst; })
+ (cond (lt (abs @0) { t_cst; })
   (rdiv @0 (sqrts (plus (mult @0 @0) { t_one; })))
   (copysigns { t_one; } @0))
 
@@ -4427,7 +4427,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
   tree t_zero = build_zero_cst (type);
  }
 (if (SCALAR_FLOAT_TYPE_P (type))
- (cond (le (abs @0) { t_cst; })
+ (cond (lt (abs @0) { t_cst; })
   (rdiv { t_one; } (sqrts (plus (mult @0 @0) { t_one; })))
   (copysigns { t_zero; } @0))
 
diff --git a/gcc/testsuite/gcc.dg/sinatan-1.c b/gcc/testsuite/gcc.dg/sinatan-1.c
index 
6a3995ae07949a423e416592276171b6e6f8c816..cfbb771a018d3175c680dce88e0121e469716edc
 100644
--- a/gcc/testsuite/gcc.dg/sinatan-1.c
+++ b/gcc/testsuite/gcc.dg/sinatan-1.c
@@ -1,4 +1,4 @@
-/* { dg-do run } */
+/* { dg-do run { target c99_runtime } } */
 /* { dg-options "-Ofast" } */
 /* { dg-add-options ieee } */
 
@@ -62,7 +62,7 @@ main()
 /* Get first x such that 1 + x*x will overflow */
 float fc = nextafterf (sqrtf (__FLT_MAX__ - 1), __FLT_MAX__);
 double c = nextafter (sqrt (__DBL_MAX__ - 1), __DBL_MAX__);
-long double lc = nextafter (sqrtl (__LDBL_MAX__ - 1), __LDBL_MAX__);
+long double lc = nextafterl (sqrtl (__LDBL_MAX__ - 1), __LDBL_MAX__);
 
 /*  Force move from FPU to memory, otherwise comparison may
 fail due to possible more accurate registers (see 387)  */

Re: [PATCH] [8/9 Regression] i386: Add pass_remove_partial_avx_dependency

[Jan Hubicka]

Hello,

2019-02-01  H.J. Lu  
Hongtao Liu  
Sunil K Pandey  

PR target/87007
* config/i386/i386-passes.def: Add
pass_remove_partial_avx_dependency.
* config/i386/i386-protos.h
(make_pass_remove_partial_avx_dependency): New.
* config/i386/i386.c (make_pass_remove_partial_avx_dependency):
New function.
(pass_data_remove_partial_avx_dependency): New.
(pass_remove_partial_avx_dependency): Likewise.
(make_pass_remove_partial_avx_dependency): Likewise.
* config/i386/i386.md (partial_xmm_update): New attribute.
(*extendsfdf2): Add partial_xmm_update.
(truncdfsf2): Likewise.
(*float2): Likewise.
(SF/DF conversion splitters): Disabled for TARGET_AVX.

gcc/testsuite/

2019-02-01  H.J. Lu  
Hongtao Liu  
Sunil K Pandey  

PR target/87007
* gcc.target/i386/pr87007-1.c: New test.
* gcc.target/i386/pr87007-2.c: Likewise.


It seems to me that more systematic way would be to use mode switching
pass that uses the LCM framework and possibly tweak LCM to do the right
thing with respect to loops (easy solution would be to lift insertion
points to the dominators with smaller frequency even if there may be path
that does not execute the instruction needing the pxor).

Teaching LCM framework is however more intrusive than self contained
minipass and Since the patch solves a regression and is self contained I
guess we should go ahead with it for this release and look for more
systematic solutions later.

Patch is OK with the following change.

+static unsigned int
+remove_partial_avx_dependency (void)
+{
+  timevar_push (TV_MACH_DEP);
+
+  calculate_dominance_info (CDI_DOMINATORS);
+  df_set_flags (DF_DEFER_INSN_RESCAN);
+  df_chain_add_problem (DF_DU_CHAIN | DF_UD_CHAIN);
+  df_md_add_problem ();
+  df_analyze ();

Please delay the initialization after you hit first instruction that
needs processing.  The pass is run unconditionally and in many functions
it will do noting. Can you also gate the pass to run only of AVX is
enabled?

Patch is OK with this change. Please way a day for possible Uros' or RM
reactions.  Sorry for the delayed reaction.
Honza

Re: PING^1: [PATCH] i386: Check -mindirect-branch/-mfunction-return with -fcf-protection

[Jan Hubicka]

> On Tue, Sep 25, 2018 at 6:50 AM H.J. Lu  wrote:
> >
> > Issue an error when -mindirect-branch or -mfunction-return are used
> > with incompatible -fcf-protection.
> >
> > gcc/
> >
> > PR target/87412
> > * config/i386/i386.c (ix86_set_indirect_branch_type): Issue an
> > error for -mindirect-branch/-mfunction-return with incompatible
> > -fcf-protection.
> >
> > gcc/testsuite/
> >
> > PR target/87412
> > * gcc.target/i386/pr87412-1.c: New file.
> > * gcc.target/i386/pr87412-2.c: Likewise.
> > * gcc.target/i386/pr87412-3.c: Likewise.
> > * gcc.target/i386/pr87412-4.c: Likewise.

OK,
thanks!
Honza
> > ---
> >  gcc/config/i386/i386.c| 10 ++
> >  gcc/testsuite/gcc.target/i386/pr87412-1.c |  9 +
> >  gcc/testsuite/gcc.target/i386/pr87412-2.c | 10 ++
> >  gcc/testsuite/gcc.target/i386/pr87412-3.c |  9 +
> >  gcc/testsuite/gcc.target/i386/pr87412-4.c |  7 +++
> >  5 files changed, 45 insertions(+)
> >  create mode 100644 gcc/testsuite/gcc.target/i386/pr87412-1.c
> >  create mode 100644 gcc/testsuite/gcc.target/i386/pr87412-2.c
> >  create mode 100644 gcc/testsuite/gcc.target/i386/pr87412-3.c
> >  create mode 100644 gcc/testsuite/gcc.target/i386/pr87412-4.c
> >
> 
> PING:
> 
> https://gcc.gnu.org/ml/gcc-patches/2018-09/msg01436.html
> 
> -- 
> H.J.

PING^1: [PATCH] i386: Check -mindirect-branch/-mfunction-return with -fcf-protection

[H.J. Lu]

On Tue, Sep 25, 2018 at 6:50 AM H.J. Lu  wrote:
>
> Issue an error when -mindirect-branch or -mfunction-return are used
> with incompatible -fcf-protection.
>
> gcc/
>
> PR target/87412
> * config/i386/i386.c (ix86_set_indirect_branch_type): Issue an
> error for -mindirect-branch/-mfunction-return with incompatible
> -fcf-protection.
>
> gcc/testsuite/
>
> PR target/87412
> * gcc.target/i386/pr87412-1.c: New file.
> * gcc.target/i386/pr87412-2.c: Likewise.
> * gcc.target/i386/pr87412-3.c: Likewise.
> * gcc.target/i386/pr87412-4.c: Likewise.
> ---
>  gcc/config/i386/i386.c| 10 ++
>  gcc/testsuite/gcc.target/i386/pr87412-1.c |  9 +
>  gcc/testsuite/gcc.target/i386/pr87412-2.c | 10 ++
>  gcc/testsuite/gcc.target/i386/pr87412-3.c |  9 +
>  gcc/testsuite/gcc.target/i386/pr87412-4.c |  7 +++
>  5 files changed, 45 insertions(+)
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr87412-1.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr87412-2.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr87412-3.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr87412-4.c
>

PING:

https://gcc.gnu.org/ml/gcc-patches/2018-09/msg01436.html

-- 
H.J.

[PATCH, GCC, AArch64] Fix a couple of bugs in BTI

[Sudakshina Das]

Hi

While doing more testing I found a couple of issues with my BTI patches. 
This patch fixes them:
1) Remove a reference to return address key. The original patch was 
written based on a different not yet committed patch ([PATCH 
3/3][GCC][AARCH64] Add support for pointer authentication B key) and I 
missed out on cleaning this up. This is hidden behind the configuration 
option and thus went unnoticed.
2) Add a missed case for adding the BTI instruction in thunk functions.

Bootstrapped on aarch64-none-linux-gnu and regression tested on 
aarch64-none-elf with configuration turned on.

gcc/ChangeLog:

2019-xx-xx  Sudakshina Das  

* config/aarch64/aarch64.c (aarch64_output_mi_thunk): Add bti
instruction if enabled.
(aarch64_override_options): Remove reference to return address
key.


Is this ok for trunk?
Sudi
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 9f52cc9..7d9824a 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -5980,6 +5980,9 @@ aarch64_output_mi_thunk (FILE *file, tree thunk ATTRIBUTE_UNUSED,
   rtx this_rtx, temp0, temp1, addr, funexp;
   rtx_insn *insn;
 
+  if (aarch64_bti_enabled ())
+emit_insn (gen_bti_c());
+
   reload_completed = 1;
   emit_note (NOTE_INSN_PROLOGUE_END);
 
@@ -12032,7 +12035,6 @@ aarch64_override_options (void)
 {
 #ifdef TARGET_ENABLE_PAC_RET
   aarch64_ra_sign_scope = AARCH64_FUNCTION_NON_LEAF;
-  aarch64_ra_sign_key = AARCH64_KEY_A;
 #else
   aarch64_ra_sign_scope = AARCH64_FUNCTION_NONE;
 #endif

Re: [Patch] [arm] Fix 88714, Arm LDRD/STRD peepholes - remove q constraint

[Kyrill Tkachov]

On 2/20/19 9:12 PM, Jakub Jelinek wrote:

On Mon, Feb 18, 2019 at 12:47:04PM +, Kyrill Tkachov wrote:

Ok.

Thanks for working on this.

Sorry for the endless story here, but I've realized that the *arm_ldrd and
*arm_strd instructions are the only remaining uses of the undocumented
internal constraint q and that it isn't really needed even for these
instructions, we can just use rk instead of q.

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


Ok.

Thanks,

Kyrill



2019-02-20  Jakub Jelinek  

PR bootstrap/88714
* constraints.md (q): Remove.
* config/arm/ldrdstrd.md (*arm_ldrd, *arm_strd): Use rk constraint
instead of q.

--- gcc/config/arm/constraints.md.jj2019-01-01 12:37:27.032812929 +0100
+++ gcc/config/arm/constraints.md   2019-02-18 20:18:51.816941795 +0100
@@ -90,9 +90,6 @@ (define_constraint "PJ"
  (define_register_constraint "k" "STACK_REG"
   "@internal The stack register.")
  
-(define_register_constraint "q" "(TARGET_ARM && TARGET_LDRD) ? CORE_REGS : GENERAL_REGS"

-  "@internal In ARM state with LDRD support, core registers, otherwise general 
registers.")
-
  (define_register_constraint "b" "TARGET_THUMB ? BASE_REGS : NO_REGS"
   "@internal
Thumb only.  The union of the low registers and the stack register.")
--- gcc/config/arm/ldrdstrd.md.jj   2019-02-18 20:19:34.976233961 +0100
+++ gcc/config/arm/ldrdstrd.md  2019-02-18 20:19:54.555912842 +0100
@@ -159,7 +159,7 @@ (define_peephole2 ; swap the destination
  (define_insn "*arm_ldrd"
[(parallel [(set (match_operand:SI 0 "s_register_operand" "=r")
   (match_operand:SI 2 "memory_operand" "m"))
- (set (match_operand:SI 1 "s_register_operand" "=q")
+ (set (match_operand:SI 1 "s_register_operand" "=rk")
   (match_operand:SI 3 "memory_operand" "m"))])]
"TARGET_LDRD && TARGET_ARM && reload_completed
&& valid_operands_ldrd_strd (operands, true)"
@@ -180,7 +180,7 @@ (define_insn "*arm_strd"
[(parallel [(set (match_operand:SI 2 "memory_operand" "=m")
   (match_operand:SI 0 "s_register_operand" "r"))
  (set (match_operand:SI 3 "memory_operand" "=m")
-  (match_operand:SI 1 "s_register_operand" "q"))])]
+  (match_operand:SI 1 "s_register_operand" "rk"))])]
"TARGET_LDRD && TARGET_ARM && reload_completed
&& valid_operands_ldrd_strd (operands, false)"
{


Jakub

Re: Patch RFC: Avoid recursive insert into const_desc_htab

[Richard Biener]

On Wed, Feb 20, 2019 at 6:53 PM Ian Lance Taylor  wrote:
>
> The underlying cause of PR 89170 is a bug that appears to have existed
> since 2001, when the function decode_addr_const was changed to call
> output_constant_def.  The problem is that output_constant_def calls
> compare_constant, and when compare_constant sees an ADDR_EXPR, it
> calls decode_addr_const.  So it is possible for output_constant_def to
> call itself recursively while adding a value to the hash table.  This
> only happens if there are already some constants in the hash table
> with the same hash code, because that is the only case in which
> compare_constant can call decode_addr_constant.  This works fine if
> the value whose address is taken is already in the hash table.  And it
> works fine if the address is not in the hash table, but adding the
> address does not cause the hash table to grow.
>
> But if we call output_constant_def with a constant that includes an
> ADDR_EXPR, and if there is already a constant in the hash table with
> the same hash code, and if decode_addr_constant calls
> output_constant_def recursively with a constant that is not already in
> the hash table, and if adding that constant causes the hash table to
> grow, then the outer call to output_constant_def will wind up looking
> at the wrong hash bucket.  The effect is that output_constant_def will
> return an rtx for a different constant.
>
> This unlikely sequence of events actually happened building libgo's
> net/http test on PPC64, causing a miscompilation leading to a test
> failure filed as PR 89170.
>
> I plan to commit this patch to fix the problem.  I didn't add a test
> case since the sequence of events is so hard to recreate.  I added a
> check that will detect any future recursive insertion into the hash
> table.
>
> Bootstrapped and tested on x86_64-pc-linux-gnu.  Since I haven't
> looked at this part of the code in many years, I'll wait a bit to see
> if anybody has any comments on the patch.

Looks reasonable.  Factoring the common code in
output_constant_def and tree_output_constant_def might be
worth it.

Richard.

> Ian
>
>
> 2019-02-20  Ian Lance Taylor  
>
> PR go/89170
> * varasm.c (decode_addr_const): Call lookup_constant_def rather
> than output_constant_def.
> (const_desc_htab_inserting): New static variable.
> (output_constant_def): Call output_addressed_constants.  Check and
> set const_desc_htab_inserting.
> (tree_output_constant_def): Likewise.

Re: libgo patch committed: Run examples

[Andreas Schwab]

On Feb 20 2019, Ian Lance Taylor  wrote:

>   if test x$hasoutput = xtrue; then
> - echo '  {"'$n'", '$j', "'"$output"'", '$unordered'},'
> + echo '  {"'$n'", '$j', "'"$(cat example2.txt)"'", 
> '$unordered'},'

That still has a problematic echo with backslashes.

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [PATCH][C++] Fix ICE with VTV

[Richard Biener]

On Wed, 20 Feb 2019, Caroline Tice wrote:

> I have managed to reproduce the issue now,  and the patch does appear
> to fix the ICE.
> 
> There is a second issue, which will need more investigation:  When
> compiled with '-flto' the extra internal functions that VTV generates,
> and which are necessary for it to work correctly, do not get
> propagated into the final binary.  You can see this compiling the
> bb_tests.cc test case in the libvtv testsuite, and grepping for
> 'GLOBAL' in the final output:
> 
> $ /usr/local/google3/cmtice/gcc-fsf.root/usr/local/bin/g++ -o bb_tests
> bb_tests.cc -O1 -fvtable-verify=std  // Compile without flto
>  $ nm bb_tests | grep GLOBAL
> 00601000 d _GLOBAL_OFFSET_TABLE_
> 00400930 t _GLOBAL__sub_I.00099__Z14get_cond_value
> 
> $ /usr/local/google3/cmtice/gcc-fsf.root/usr/local/bin/g++ -o
> bb_tests_flto bb_tests.cc -O1 -flto -fvtable-verify=std   // Compile
> with flto
> $ nm bb_tests_flto | grep GLOBAL
> 00601000 d _GLOBAL_OFFSET_TABLE_
> 
> But as said, that's a separate issue, which I will need to investigate
> (if anyone has any suggestions as to the proper way to propagate the
> functions through -flto, I would love to hear them).
> 
> I approve Richard's patch for fixing the ICE.

I have applied the patch.  I do not see LTO reclaiming any symbol
when compiling bb_tests.cc but of course it might bring symbols
local and/or inline them.  Did you verify that there is a functional
deficiency rather than just the missing symbol table entry?

That is, the bb_tests.cc testcase executes just fine.

Richard.

> -- Caroline Tice
> cmt...@google.com
> 
> On Wed, Feb 20, 2019 at 6:30 AM Richard Biener  wrote:
> >
> > On Tue, 19 Feb 2019, Caroline Tice wrote:
> >
> > > On Tue, Feb 19, 2019 at 1:57 AM Richard Biener  wrote:
> > >
> > > >
> > > > Looks like vtv_generate_init_routine calls symtab->process_new_functions
> > > > () which has seriously bad effects on GCCs internal memory state.
> > > >
> > > > VTV has zero testsuite coverage it seems and besides its initial
> > > > commit didn't receive any love.
> > > >
> > >
> > > I am puzzled by these statements, as neither of them is true.  VTV does
> > > have a testsuite in the libvtv directory.  Naturally you can only run them
> > > when vtv is enabled and only from the libvtv build tree, as they will all
> > > fail if VTV is not enabled.  I have fixed various bugs in VTV since the
> > > initial commit, and I have also approved several patches, especially for
> > > people migrating it to other architectures, suggesting that interest in it
> > > is not zero.
> > >
> > >
> > >
> > > >
> > > > Can we rip it out please?
> > > >
> > > > Is the patch OK?  (Pointless) bootstrap and regtest running on
> > > > x86_64-unknown-linux-gnu.
> > > >
> > > > Has anybody "recently" tried to enable the feature and tested the
> > > > result?
> > > >
> > >
> > > I have not tried building it recently, but will do so.  I will review your
> > > patch to see if it makes sense.  I would prefer that VTV not be 'ripped
> > > out' of GCC, and will do whatever I can, within reason, to try to fix its
> > > issues.
> >
> > Meanwhile the patch passed bootstrap and testing with
> > --enable-vtable-verify.
> >
> > Richard.
> >
> > >
> > > >
> > > > Thanks,
> > > > Richard.
> > > >
> > > > 2019-02-19  Richard Biener  
> > > >
> > > > PR middle-end/89392
> > > > cp/
> > > > * vtable-class-hierarchy.c (vtv_generate_init_routine): Do not
> > > > make symtab process new functions here.
> > > >
> > > > Index: gcc/cp/vtable-class-hierarchy.c
> > > > ===
> > > > --- gcc/cp/vtable-class-hierarchy.c (revision 269009)
> > > > +++ gcc/cp/vtable-class-hierarchy.c (working copy)
> > > > @@ -1191,8 +1191,6 @@ vtv_generate_init_routine (void)
> > > >gimplify_function_tree (vtv_fndecl);
> > > >cgraph_node::add_new_function (vtv_fndecl, false);
> > > >
> > > > -  symtab->process_new_functions ();
> > > > -
> > > >if (flag_vtable_verify == VTV_PREINIT_PRIORITY && !TARGET_PECOFF)
> > > >  assemble_vtv_preinit_initializer (vtv_fndecl);
> > > >
> > > >
> > >
> >
> > --
> > Richard Biener 
> > SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 
> > 21284 (AG Nuernberg)
> 
> 

-- 
Richard Biener 
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 
21284 (AG Nuernberg)