Re: [PATCH 0/4] rs6000: setbnc and friends [pu]

2020-05-06 Thread Bill Schmidt via Gcc-patches

On 5/6/20 6:48 PM, Segher Boessenkool wrote:

On Wed, May 06, 2020 at 03:41:35PM -0500, Bill Schmidt wrote:

For all of these, I forgot to mention that they have been bootstrapped
and tested on powerpc64le-unknown-linux-gnu with no regressions.  Are
these okay for trunk, after GCC 10 is fully released?

These all look fine to me.  But maybe David can find something?  :-)

Thank you for handling this!


Segher



Bill Schmidt (4):
   Add insns for setbc and setbcr
   Add tests for setbc and setbcr
   Add insns for setnbc and setnbcr
   Add tests for setnbc and setnbcr

(I assume you will get the author info correct -- git log --format=fuller
to check, git commit --amend --author= (or similar) to fix things).
Yes, I forgot to set the author on these; will fix them when applying to 
master.


Re: [PATCH] False-positive -Warray-bounds for char[1] on a non-zero offset in a referenced buffer

2020-05-06 Thread Martin Sebor via Gcc-patches

On 5/6/20 4:35 PM, Joey Liu via Gcc-patches wrote:

Hi all,

I think the assumption in builtin_memref::set_base_and_offset
(gimple-ssa-warn-restrict.c) is not correct. It seems multiple levels of
indirection may confuse gcc. When it loses the reference to the original
buffer (e.g.the buffer is allocated by one of the parent class but it's
used by a different parent class), the subsequent tree::component_ref_size
will just return NULL_TREE.


It's best to open a bug in Bugzilla first and only submit a patch if
the bug is acknowledged (or at least not disputed).



In that case, the refsize will remain as 0 incorrectly set by the code
below (set_base_and_offset). The problem is unique for char[1]. For the
char array with more than 1 elements, the size of the domain is always
returned.

In builtin_memref::set_base_and_offset (gimple-ssa-warn-restrict.c)
-
-  if (!integer_zerop (memrefoff))
-   /* A non-zero offset into an array of struct with flexible array
-  members implies that the array is empty because there is no
-  way to initialize such a member when it belongs to an array.
-  This must be some sort of a bug.  */
-   refsize = 0;

I've attached the patch with the test case and I'd suggest removal of the
code block here. It seems to me it's ok for non-zero offset here.


The code above is tested by gcc.dg/Warray-bounds-46.c which fails
a number of cases when the patch is applied.

I tend to agree the warning for the test case is a false positive:
the strncpy call writes 1 byte to a 1-character buffer which is
safe.  The comment also talks about flexible arrays but there is
none in the test case).

But I'm not convinced that removing the hunk is the right way to
fix the bug: it just trades false negatives for false positives.
I suggest you open a bug for this in Bugzilla and take it from
there.

Martin


Re: [PATCH 0/4] rs6000: setbnc and friends [pu]

2020-05-06 Thread Segher Boessenkool
On Wed, May 06, 2020 at 03:41:35PM -0500, Bill Schmidt wrote:
> For all of these, I forgot to mention that they have been bootstrapped 
> and tested on powerpc64le-unknown-linux-gnu with no regressions.  Are 
> these okay for trunk, after GCC 10 is fully released?

These all look fine to me.  But maybe David can find something?  :-)

Thank you for handling this!


Segher


> >Bill Schmidt (4):
> >   Add insns for setbc and setbcr
> >   Add tests for setbc and setbcr
> >   Add insns for setnbc and setnbcr
> >   Add tests for setnbc and setnbcr

(I assume you will get the author info correct -- git log --format=fuller
to check, git commit --amend --author= (or similar) to fix things).


Re: [PATCH 1/4] rs6000: New insns setbc and setbcr

2020-05-06 Thread Segher Boessenkool
Hi!

On Wed, May 06, 2020 at 03:31:08PM -0500, Bill Schmidt wrote:
>   (ne3): Replace :P with :GPR; use setbc for TARGET_FUTURE;
>   else for non-Pmode, use gen_eq and gen_xor.

Before this patch, there was only ne:P, which results in the same thing
(done by generic code).  I should have done this part as a separate
patch, it looks much more involved than it actually is now.


Segher


[PATCH] False-positive -Warray-bounds for char[1] on a non-zero offset in a referenced buffer

2020-05-06 Thread Joey Liu via Gcc-patches
Hi all,

I think the assumption in builtin_memref::set_base_and_offset
(gimple-ssa-warn-restrict.c) is not correct. It seems multiple levels of
indirection may confuse gcc. When it loses the reference to the original
buffer (e.g.the buffer is allocated by one of the parent class but it's
used by a different parent class), the subsequent tree::component_ref_size
will just return NULL_TREE.

In that case, the refsize will remain as 0 incorrectly set by the code
below (set_base_and_offset). The problem is unique for char[1]. For the
char array with more than 1 elements, the size of the domain is always
returned.

In builtin_memref::set_base_and_offset (gimple-ssa-warn-restrict.c)
-
-  if (!integer_zerop (memrefoff))
-   /* A non-zero offset into an array of struct with flexible array
-  members implies that the array is empty because there is no
-  way to initialize such a member when it belongs to an array.
-  This must be some sort of a bug.  */
-   refsize = 0;

I've attached the patch with the test case and I'd suggest removal of the
code block here. It seems to me it's ok for non-zero offset here.

$ g++ -v
Using built-in specs.
COLLECT_GCC=/local/usr/bin/g++
COLLECT_LTO_WRAPPER=/local/usr/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/local/usr --disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.0.0 20200505 (experimental) (GCC)

Thanks,
Joey
From f9fecbdf485e3cbc29d4aeab3e31c5217e5f2050 Mon Sep 17 00:00:00 2001
From: Joey Liu 
Date: Wed, 6 May 2020 17:51:57 -0400
Subject: [PATCH] False-positive -Warray-bounds for char[1] on a non-zero offset in a referenced buffer

---
 gcc/gimple-ssa-warn-restrict.c   |  7 
 gcc/testsuite/g++.dg/Warray-bounds.C | 62 
 2 files changed, 62 insertions(+), 7 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/Warray-bounds.C

diff --git a/gcc/gimple-ssa-warn-restrict.c b/gcc/gimple-ssa-warn-restrict.c
index 19d2ec09aa5..65bee84cad2 100644
--- a/gcc/gimple-ssa-warn-restrict.c
+++ b/gcc/gimple-ssa-warn-restrict.c
@@ -519,13 +519,6 @@ builtin_memref::set_base_and_offset (tree expr)
 	  offset_int off = tree_to_shwi (memrefoff);
 	  refoff += off;
   	}
-
-  if (!integer_zerop (memrefoff))
-	/* A non-zero offset into an array of struct with flexible array
-	   members implies that the array is empty because there is no
-	   way to initialize such a member when it belongs to an array.
-	   This must be some sort of a bug.  */
-	refsize = 0;
 }

   if (TREE_CODE (ref) == COMPONENT_REF)
diff --git a/gcc/testsuite/g++.dg/Warray-bounds.C b/gcc/testsuite/g++.dg/Warray-bounds.C
new file mode 100644
index 000..9aaf40c5f64
--- /dev/null
+++ b/gcc/testsuite/g++.dg/Warray-bounds.C
@@ -0,0 +1,62 @@
+/* PR c/??? - false positive in -Warray-bounds
+{ dg-do compile }
+{ dg-options "-O2 -Wall -Werror" } */
+
+#include 
+
+template  struct cstr
+{
+  void strncpy (char *src, size_t n)
+  {
+::strncpy (data (), src, n);
+
+if (n < N)
+  data ()[n] = '\0';
+  }
+
+  char get () { return data ()[0]; }
+
+  char *data () { return m_data; }
+
+  char m_data[N];
+};
+
+struct Msg
+{
+  char dummy;
+  cstr<1> m_field;
+};
+
+struct Storage
+{
+  char *data () { return m_data; }
+
+  char m_data[1024];
+};
+
+struct MsgBase
+{
+  Msg *body () { return m_data; }
+
+  MsgBase (char *data) : m_data (reinterpret_cast (data)) {}
+
+  Msg *m_data;
+};
+
+struct ExtMsg : private Storage, public MsgBase
+{
+  ExtMsg () : MsgBase (Storage::data ()) {}
+};
+
+ExtMsg global_m;
+
+// it should not raise any -Warray-bounds warnings
+char
+test_non_zero_offset_into_memarray (char c)
+{
+  ExtMsg  = global_m;
+
+  m.body ()->m_field.strncpy (, sizeof (char));
+
+  return m.body ()->m_field.get ();
+}
--
2.17.1


Re: [PATCH] libstdc++: Update {x86_64, i?86, powerpc64, s390x, aarch64}-linux baselines for GCC 10.1

2020-05-06 Thread Eric Botcazou
> Oops, here are the updates from Fedora packages built during the weekend.

The SPARC64/Linux bits are attached.  OK for trunk and gcc-10?


2020-05-06  Eric Botcazou  

* config/abi/post/sparc64-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/sparc64-linux-gnu/32/baseline_symbols.txt: Likewise.

-- 
Eric Botcazoudiff --git a/libstdc++-v3/config/abi/post/sparc64-linux-gnu/32/baseline_symbols.txt b/libstdc++-v3/config/abi/post/sparc64-linux-gnu/32/baseline_symbols.txt
index 31c73b03659..94f5f5efaa5 100644
--- a/libstdc++-v3/config/abi/post/sparc64-linux-gnu/32/baseline_symbols.txt
+++ b/libstdc++-v3/config/abi/post/sparc64-linux-gnu/32/baseline_symbols.txt
@@ -338,7 +338,9 @@ FUNC:_ZNKSt10filesystem16filesystem_error4whatEv@@GLIBCXX_3.4.26
 FUNC:_ZNKSt10filesystem16filesystem_error5path1Ev@@GLIBCXX_3.4.26
 FUNC:_ZNKSt10filesystem16filesystem_error5path2Ev@@GLIBCXX_3.4.26
 FUNC:_ZNKSt10filesystem18directory_iteratordeEv@@GLIBCXX_3.4.26
+FUNC:_ZNKSt10filesystem28recursive_directory_iterator17recursion_pendingEv@@GLIBCXX_3.4.26
 FUNC:_ZNKSt10filesystem28recursive_directory_iterator5depthEv@@GLIBCXX_3.4.26
+FUNC:_ZNKSt10filesystem28recursive_directory_iterator7optionsEv@@GLIBCXX_3.4.26
 FUNC:_ZNKSt10filesystem28recursive_directory_iteratordeEv@@GLIBCXX_3.4.26
 FUNC:_ZNKSt10filesystem4path11parent_pathEv@@GLIBCXX_3.4.26
 FUNC:_ZNKSt10filesystem4path12has_filenameEv@@GLIBCXX_3.4.26
@@ -364,7 +366,9 @@ FUNC:_ZNKSt10filesystem7__cxx1116filesystem_error4whatEv@@GLIBCXX_3.4.26
 FUNC:_ZNKSt10filesystem7__cxx1116filesystem_error5path1Ev@@GLIBCXX_3.4.26
 FUNC:_ZNKSt10filesystem7__cxx1116filesystem_error5path2Ev@@GLIBCXX_3.4.26
 FUNC:_ZNKSt10filesystem7__cxx1118directory_iteratordeEv@@GLIBCXX_3.4.26
+FUNC:_ZNKSt10filesystem7__cxx1128recursive_directory_iterator17recursion_pendingEv@@GLIBCXX_3.4.26
 FUNC:_ZNKSt10filesystem7__cxx1128recursive_directory_iterator5depthEv@@GLIBCXX_3.4.26
+FUNC:_ZNKSt10filesystem7__cxx1128recursive_directory_iterator7optionsEv@@GLIBCXX_3.4.26
 FUNC:_ZNKSt10filesystem7__cxx1128recursive_directory_iteratordeEv@@GLIBCXX_3.4.26
 FUNC:_ZNKSt10filesystem7__cxx114path11parent_pathEv@@GLIBCXX_3.4.26
 FUNC:_ZNKSt10filesystem7__cxx114path12has_filenameEv@@GLIBCXX_3.4.26
@@ -982,6 +986,13 @@ FUNC:_ZNKSt7__cxx119money_putIwSt19ostreambuf_iteratorIwSt11char_traitsIwEEE6do_
 FUNC:_ZNKSt7__cxx119money_putIwSt19ostreambuf_iteratorIwSt11char_traitsIwEEE6do_putES4_bRSt8ios_basewe@@GLIBCXX_3.4.21
 FUNC:_ZNKSt7__cxx119money_putIwSt19ostreambuf_iteratorIwSt11char_traitsIwEEE9_M_insertILb0EEES4_S4_RSt8ios_basewRKNS_12basic_stringIwS3_SaIwEEE@@GLIBCXX_3.4.21
 FUNC:_ZNKSt7__cxx119money_putIwSt19ostreambuf_iteratorIwSt11char_traitsIwEEE9_M_insertILb1EEES4_S4_RSt8ios_basewRKNS_12basic_stringIwS3_SaIwEEE@@GLIBCXX_3.4.21
+FUNC:_ZNKSt7codecvtIDiDu11__mbstate_tE10do_unshiftERS0_PDuS3_RS3_@@GLIBCXX_3.4.26
+FUNC:_ZNKSt7codecvtIDiDu11__mbstate_tE11do_encodingEv@@GLIBCXX_3.4.26
+FUNC:_ZNKSt7codecvtIDiDu11__mbstate_tE13do_max_lengthEv@@GLIBCXX_3.4.26
+FUNC:_ZNKSt7codecvtIDiDu11__mbstate_tE16do_always_noconvEv@@GLIBCXX_3.4.26
+FUNC:_ZNKSt7codecvtIDiDu11__mbstate_tE5do_inERS0_PKDuS4_RS4_PDiS6_RS6_@@GLIBCXX_3.4.26
+FUNC:_ZNKSt7codecvtIDiDu11__mbstate_tE6do_outERS0_PKDiS4_RS4_PDuS6_RS6_@@GLIBCXX_3.4.26
+FUNC:_ZNKSt7codecvtIDiDu11__mbstate_tE9do_lengthERS0_PKDuS4_j@@GLIBCXX_3.4.26
 FUNC:_ZNKSt7codecvtIDic11__mbstate_tE10do_unshiftERS0_PcS3_RS3_@@GLIBCXX_3.4.21
 FUNC:_ZNKSt7codecvtIDic11__mbstate_tE11do_encodingEv@@GLIBCXX_3.4.21
 FUNC:_ZNKSt7codecvtIDic11__mbstate_tE13do_max_lengthEv@@GLIBCXX_3.4.21
@@ -989,6 +1000,13 @@ FUNC:_ZNKSt7codecvtIDic11__mbstate_tE16do_always_noconvEv@@GLIBCXX_3.4.21
 FUNC:_ZNKSt7codecvtIDic11__mbstate_tE5do_inERS0_PKcS4_RS4_PDiS6_RS6_@@GLIBCXX_3.4.21
 FUNC:_ZNKSt7codecvtIDic11__mbstate_tE6do_outERS0_PKDiS4_RS4_PcS6_RS6_@@GLIBCXX_3.4.21
 FUNC:_ZNKSt7codecvtIDic11__mbstate_tE9do_lengthERS0_PKcS4_j@@GLIBCXX_3.4.21
+FUNC:_ZNKSt7codecvtIDsDu11__mbstate_tE10do_unshiftERS0_PDuS3_RS3_@@GLIBCXX_3.4.26
+FUNC:_ZNKSt7codecvtIDsDu11__mbstate_tE11do_encodingEv@@GLIBCXX_3.4.26
+FUNC:_ZNKSt7codecvtIDsDu11__mbstate_tE13do_max_lengthEv@@GLIBCXX_3.4.26
+FUNC:_ZNKSt7codecvtIDsDu11__mbstate_tE16do_always_noconvEv@@GLIBCXX_3.4.26
+FUNC:_ZNKSt7codecvtIDsDu11__mbstate_tE5do_inERS0_PKDuS4_RS4_PDsS6_RS6_@@GLIBCXX_3.4.26
+FUNC:_ZNKSt7codecvtIDsDu11__mbstate_tE6do_outERS0_PKDsS4_RS4_PDuS6_RS6_@@GLIBCXX_3.4.26
+FUNC:_ZNKSt7codecvtIDsDu11__mbstate_tE9do_lengthERS0_PKDuS4_j@@GLIBCXX_3.4.26
 FUNC:_ZNKSt7codecvtIDsc11__mbstate_tE10do_unshiftERS0_PcS3_RS3_@@GLIBCXX_3.4.21
 FUNC:_ZNKSt7codecvtIDsc11__mbstate_tE11do_encodingEv@@GLIBCXX_3.4.21
 FUNC:_ZNKSt7codecvtIDsc11__mbstate_tE13do_max_lengthEv@@GLIBCXX_3.4.21
@@ -1790,6 +1808,7 @@ FUNC:_ZNSt10filesystem18create_directoriesERKNS_4pathE@@GLIBCXX_3.4.26
 FUNC:_ZNSt10filesystem18create_directoriesERKNS_4pathERSt10error_code@@GLIBCXX_3.4.26
 FUNC:_ZNSt10filesystem18create_directoriesERKNS_7__cxx114pathE@@GLIBCXX_3.4.26
 

[committed] d: Fix ICE in verify_gimple_stmt, at tree-cfg.c:4959

2020-05-06 Thread Iain Buclaw via Gcc-patches
Hi,


This patch removes all related helper functions around BIND_EXPR
generation in the D front-end, which were the cause of an ICE.

Both array concat and array new expressions wrapped any temporaries
created into a BIND_EXPR.  This does not work if an expression used to
construct the result requires scope destruction, which is represented by
a TARGET_EXPR with a clean-up, and a CLEANUP_POINT_EXPR at the
location where the temporaries logically go out of scope.  The reason
for this not working is because the lowering of cleanup point
expressions does not traverse inside BIND_EXPRs to expand any gimple
cleanup expressions within.

The use of creating BIND_EXPR has been removed at both locations, and
replaced with a normal temporary variable that has initialization
delayed until its address is taken.

Bootstrapped and regression tested on x86_64-linux-gnu with
-m64,-m32,-mx32 target configurations.  Comitted to mainline.

Regards
Iain

---
gcc/d/ChangeLog:

PR d/94970
* d-codegen.cc (force_target_expr): Move create_temporary_var
implementation inline here.
(create_temporary_var): Remove.
(maybe_temporary_var): Remove.
(bind_expr): Remove.
* d-convert.cc (d_array_convert): Use build_local_temp to generate
temporaries, and generate its assignment.
* d-tree.h (create_temporary_var): Remove.
(maybe_temporary_var): Remove.
(d_array_convert): Remove vars argument.
* expr.cc (ExprVisitor::visit (CatExp *)): Use build_local_temp to
generate temporaries, don't wrap them in a BIND_EXPR.
(ExprVisitor::visit (NewExp *)): Likewise.

gcc/testsuite/ChangeLog:

PR d/94970
* gdc.dg/pr94970.d: New test.
---
 gcc/d/d-codegen.cc | 67 +++---
 gcc/d/d-convert.cc | 14 ---
 gcc/d/d-tree.h |  4 +-
 gcc/d/expr.cc  | 33 +++--
 gcc/testsuite/gdc.dg/pr94970.d | 20 ++
 5 files changed, 49 insertions(+), 89 deletions(-)
 create mode 100644 gcc/testsuite/gdc.dg/pr94970.d

diff --git a/gcc/d/d-codegen.cc b/gcc/d/d-codegen.cc
index b4927a2de10..5efd4b9c43c 100644
--- a/gcc/d/d-codegen.cc
+++ b/gcc/d/d-codegen.cc
@@ -619,7 +619,12 @@ build_target_expr (tree decl, tree exp)
 tree
 force_target_expr (tree exp)
 {
-  tree decl = create_temporary_var (TREE_TYPE (exp));
+  tree decl = build_decl (input_location, VAR_DECL, NULL_TREE,
+ TREE_TYPE (exp));
+  DECL_CONTEXT (decl) = current_function_decl;
+  DECL_ARTIFICIAL (decl) = 1;
+  DECL_IGNORED_P (decl) = 1;
+  layout_decl (decl, 0);
 
   return build_target_expr (decl, exp);
 }
@@ -1766,66 +1771,6 @@ array_bounds_check (void)
 }
 }
 
-/* Return an undeclared local temporary of type TYPE
-   for use with BIND_EXPR.  */
-
-tree
-create_temporary_var (tree type)
-{
-  tree decl = build_decl (input_location, VAR_DECL, NULL_TREE, type);
-
-  DECL_CONTEXT (decl) = current_function_decl;
-  DECL_ARTIFICIAL (decl) = 1;
-  DECL_IGNORED_P (decl) = 1;
-  layout_decl (decl, 0);
-
-  return decl;
-}
-
-/* Return an undeclared local temporary OUT_VAR initialized
-   with result of expression EXP.  */
-
-tree
-maybe_temporary_var (tree exp, tree *out_var)
-{
-  tree t = exp;
-
-  /* Get the base component.  */
-  while (TREE_CODE (t) == COMPONENT_REF)
-t = TREE_OPERAND (t, 0);
-
-  if (!DECL_P (t) && !REFERENCE_CLASS_P (t))
-{
-  *out_var = create_temporary_var (TREE_TYPE (exp));
-  DECL_INITIAL (*out_var) = exp;
-  return *out_var;
-}
-  else
-{
-  *out_var = NULL_TREE;
-  return exp;
-}
-}
-
-/* Builds a BIND_EXPR around BODY for the variables VAR_CHAIN.  */
-
-tree
-bind_expr (tree var_chain, tree body)
-{
-  /* Only handles one var.  */
-  gcc_assert (TREE_CHAIN (var_chain) == NULL_TREE);
-
-  if (DECL_INITIAL (var_chain))
-{
-  tree ini = build_assign (INIT_EXPR, var_chain, DECL_INITIAL (var_chain));
-  DECL_INITIAL (var_chain) = NULL_TREE;
-  body = compound_expr (ini, body);
-}
-
-  return d_save_expr (build3 (BIND_EXPR, TREE_TYPE (body),
- var_chain, body, NULL_TREE));
-}
-
 /* Returns the TypeFunction class for Type T.
Assumes T is already ->toBasetype().  */
 
diff --git a/gcc/d/d-convert.cc b/gcc/d/d-convert.cc
index e2921ec33f0..f93405ed956 100644
--- a/gcc/d/d-convert.cc
+++ b/gcc/d/d-convert.cc
@@ -774,21 +774,23 @@ d_array_convert (Expression *exp)
 
 /* Convert EXP to a dynamic array, where ETYPE is the element type.
Similar to above, except that EXP is allowed to be an element of an array.
-   Temporary variables that need some kind of BIND_EXPR are pushed to VARS.  */
+   Temporary variables are created inline if EXP is not an lvalue.  */
 
 tree
-d_array_convert (Type *etype, Expression *exp, vec **vars)
+d_array_convert (Type *etype, Expression *exp)
 {
   Type *tb = exp->type->toBasetype ();
 
   if ((tb->ty != Tarray && tb->ty != 

[PATCH] c++: Missing SFINAE with lookup_fnfields [PR78446]

2020-05-06 Thread Patrick Palka via Gcc-patches
Here we're failing to do SFINAE in build_op_call when looking up the
class's operator() via lookup_fnfields, which calls lookup_member always
with complain=tf_warning_or_error.  And from there we complain about an
ambiguous lookup for operator().

This patch fixes this by adding a tsubst_flags_t parameter to
lookup_fnfields and adjusting all its callers appropriately.

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK to
commit?

gcc/cp/ChangeLog:

PR c++/78446
* call.c (build_op_call): Pass complain to lookup_fnfields.
(build_special_member_call): Likewise.
* class.c (type_requires_array_cookie): Pass tf_warning_or_error
to lookup_fnfields.
* cp-tree.h (lookup_fnfields): Add tsubst_flags_t parameter.
* except.c (build_throw): Pass tf_warning_or_error to
lookup_fnfields.
* init.c (build_new_1): Pass complain to lookup_fnfields.
* method.c (locate_fn_flags): Likewise.
* name-lookup.c (lookup_name_real_1): Pass tf_warning_or_error
to lookup_fnfields.
* pt.c (tsubst_baselink): Pass complain to lookup_fnfields.
* search.c (lookup_fnfields): New 'complain' parameter.  Pass it
to lookup_member.

gcc/testsuite/ChangeLog:

PR c++/78446
* g++.dg/template/sfinae30.C: New test.
---
 gcc/cp/call.c|  8 
 gcc/cp/class.c   |  2 +-
 gcc/cp/cp-tree.h |  2 +-
 gcc/cp/except.c  |  3 ++-
 gcc/cp/init.c|  2 +-
 gcc/cp/method.c  |  2 +-
 gcc/cp/name-lookup.c |  3 ++-
 gcc/cp/pt.c  |  3 ++-
 gcc/cp/search.c  |  5 +++--
 gcc/testsuite/g++.dg/template/sfinae30.C | 14 ++
 10 files changed, 31 insertions(+), 13 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/template/sfinae30.C

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 1182d3ae642..a7c7f471b60 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -4779,7 +4779,7 @@ build_op_call_1 (tree obj, vec **args, 
tsubst_flags_t complain)
 
   if (TYPE_BINFO (type))
 {
-  fns = lookup_fnfields (TYPE_BINFO (type), call_op_identifier, 1);
+  fns = lookup_fnfields (TYPE_BINFO (type), call_op_identifier, 1, 
complain);
   if (fns == error_mark_node)
return error_mark_node;
 }
@@ -5965,7 +5965,7 @@ add_operator_candidates (z_candidate **candidates,
   tree arg2_type = nargs > 1 ? TREE_TYPE ((*arglist)[1]) : NULL_TREE;
   if (CLASS_TYPE_P (arg1_type))
 {
-  tree fns = lookup_fnfields (arg1_type, fnname, 1);
+  tree fns = lookup_fnfields (arg1_type, fnname, 1, complain);
   if (fns == error_mark_node)
return error_mark_node;
   if (fns)
@@ -6772,7 +6772,7 @@ build_op_delete_call (enum tree_code code, tree addr, 
tree size,
 
Therefore, we ask lookup_fnfields to complain about ambiguity.  */
 {
-  fns = lookup_fnfields (TYPE_BINFO (type), fnname, 1);
+  fns = lookup_fnfields (TYPE_BINFO (type), fnname, 1, complain);
   if (fns == error_mark_node)
return error_mark_node;
 }
@@ -9793,7 +9793,7 @@ build_special_member_call (tree instance, tree name, 
vec **args,
}
 }
 
-  fns = lookup_fnfields (binfo, name, 1);
+  fns = lookup_fnfields (binfo, name, 1, complain);
 
   /* When making a call to a constructor or destructor for a subobject
  that uses virtual base classes, pass down a pointer to a VTT for
diff --git a/gcc/cp/class.c b/gcc/cp/class.c
index 1f524a31917..16bfa313ed2 100644
--- a/gcc/cp/class.c
+++ b/gcc/cp/class.c
@@ -5644,7 +5644,7 @@ type_requires_array_cookie (tree type)
  a cookie.  */
   fns = lookup_fnfields (TYPE_BINFO (type),
 ovl_op_identifier (false, VEC_DELETE_EXPR),
-/*protect=*/0);
+/*protect=*/0, tf_warning_or_error);
   /* If there are no `operator []' members, or the lookup is
  ambiguous, then we don't need a cookie.  */
   if (!fns || fns == error_mark_node)
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 39c7ddb697a..a29102b1ab5 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -7058,7 +7058,7 @@ extern tree dcast_base_hint   (tree, 
tree);
 extern int accessible_p(tree, tree, bool);
 extern int accessible_in_template_p(tree, tree);
 extern tree lookup_field   (tree, tree, int, bool);
-extern tree lookup_fnfields(tree, tree, int);
+extern tree lookup_fnfields(tree, tree, int, 
tsubst_flags_t);
 extern tree lookup_member  (tree, tree, int, bool,
 tsubst_flags_t,
 access_failure_info *afi = 
NULL);
diff --git a/gcc/cp/except.c 

Re: [PATCH] c++: Avoid strict_aliasing_warning on dependent types or expressions [PR94951]

2020-05-06 Thread Jason Merrill via Gcc-patches

On 5/5/20 6:28 PM, Jakub Jelinek wrote:

Hi!

The following testcase gets a bogus warning during build_base_path,
when cp_build_indirect_ref* calls strict_aliasing_warning with a dependent
expression.  IMHO calling get_alias_set etc. on dependent types feels wrong
to me, we should just defer the warnings in those cases until instantiation
and only handle the cases where neither type nor expr are dependent.

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


OK.


2020-05-05  Jakub Jelinek  

PR c++/94951
* typeck.c (cp_strict_aliasing_warning): New function.
(cp_build_indirect_ref_1, build_reinterpret_cast_1): Use
it instead of strict_aliasing_warning.

* g++.dg/warn/Wstrict-aliasing-bogus-tmpl.C: New test.

--- gcc/cp/typeck.c.jj  2020-03-19 22:54:38.393744684 +0100
+++ gcc/cp/typeck.c 2020-05-05 18:12:21.964090624 +0200
@@ -3318,6 +3318,22 @@ build_x_indirect_ref (location_t loc, tr
  return rval;
  }
  
+/* Like c-family strict_aliasing_warning, but don't warn for dependent

+   types or expressions.  */
+
+static bool
+cp_strict_aliasing_warning (location_t loc, tree type, tree expr)
+{
+  if (processing_template_decl)
+{
+  tree e = expr;
+  STRIP_NOPS (e);
+  if (dependent_type_p (type) || type_dependent_expression_p (e))
+   return false;
+}
+  return strict_aliasing_warning (loc, type, expr);
+}
+
  /* The implementation of the above, and of indirection implied by other
 constructs.  If DO_FOLD is true, fold away INDIRECT_REF of ADDR_EXPR.  */
  
@@ -3360,10 +3376,10 @@ cp_build_indirect_ref_1 (location_t loc,

  /* If a warning is issued, mark it to avoid duplicates from
 the backend.  This only needs to be done at
 warn_strict_aliasing > 2.  */
- if (warn_strict_aliasing > 2)
-   if (strict_aliasing_warning (EXPR_LOCATION (ptr),
-type, TREE_OPERAND (ptr, 0)))
- TREE_NO_WARNING (ptr) = 1;
+ if (warn_strict_aliasing > 2
+ && cp_strict_aliasing_warning (EXPR_LOCATION (ptr),
+type, TREE_OPERAND (ptr, 0)))
+   TREE_NO_WARNING (ptr) = 1;
}
  
if (VOID_TYPE_P (t))

@@ -,7 +7793,7 @@ build_reinterpret_cast_1 (location_t loc
expr = cp_build_addr_expr (expr, complain);
  
if (warn_strict_aliasing > 2)

-   strict_aliasing_warning (EXPR_LOCATION (expr), type, expr);
+   cp_strict_aliasing_warning (EXPR_LOCATION (expr), type, expr);
  
if (expr != error_mark_node)

expr = build_reinterpret_cast_1
@@ -7891,7 +7907,7 @@ build_reinterpret_cast_1 (location_t loc
  
if (warn_strict_aliasing <= 2)

/* strict_aliasing_warning STRIP_NOPs its expr.  */
-   strict_aliasing_warning (EXPR_LOCATION (expr), type, expr);
+   cp_strict_aliasing_warning (EXPR_LOCATION (expr), type, expr);
  
return build_nop_reinterpret (type, expr);

  }
--- gcc/testsuite/g++.dg/warn/Wstrict-aliasing-bogus-tmpl.C.jj  2020-05-05 
18:18:43.40832 +0200
+++ gcc/testsuite/g++.dg/warn/Wstrict-aliasing-bogus-tmpl.C 2020-05-05 
18:17:35.178352212 +0200
@@ -0,0 +1,12 @@
+// PR c++/94951
+// { dg-do compile }
+// { dg-options "-O2 -Wall" }
+
+struct A { int a; };
+template 
+struct B : public A
+{
+  static B foo () { B t; t.a = 4; return t; }// { dg-bogus 
"dereferencing type-punned pointer will break strict-aliasing rules" }
+};
+
+B<0> b = B<0>::foo ();

Jakub





Re: [PATCH] libgcc: aarch64: Get hwcap for FreeBSD

2020-05-06 Thread Gerald Pfeifer
On Wed, 6 May 2020, Andreas Tobler wrote:
> +#ifndef __FreeBSD__
>unsigned long hwcap = __getauxval (AT_HWCAP);
> +#else
> +  unsigned long hwcap;

Would it make sense to change the logic to

  #ifdef __FreeBSD__
  ..
  #else
  ..
  #endif

?  I believe that makes it easier to potentially extend this for 
other platforms in the future.

Gerald


Re: [PATCH v2] c++: ICE in value_dependent_expression_p in C++98 mode [PR94938]

2020-05-06 Thread Jason Merrill via Gcc-patches

On 5/5/20 5:35 PM, Marek Polacek wrote:

On Mon, May 04, 2020 at 09:18:57PM -0400, Jason Merrill wrote:

On 5/4/20 7:32 PM, Marek Polacek wrote:

Here we ICE with -std=c++98 since the newly added call to uses_template_parms
(r10-6357): we hit
26530 gcc_assert (cxx_dialect >= cxx11
26531 || INTEGRAL_OR_ENUMERATION_TYPE_P (type));
and TYPE is a record type.  The problem is that the argument to
value_dependent_expression_p does not satisfy potential_constant_expression
which it must, as the comment explains.  I thought about fixing this in
uses_template_parms -- only call v_d_e_p if p_c_e is true, but in this
case we want to also suppress the warnings if we don't have a constant
expression.  I couldn't simply check TREE_CONSTANT as in
compute_array_index_type_loc, because then we'd stop warning in the new
Wtype-limits3.C test.

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

PR c++/94938
* pt.c (tsubst_copy_and_build): Don't call value_dependent_expression_p
if the expression is not potential_constant_expression.

* g++.dg/warn/template-2.C: New test.
---
   gcc/cp/pt.c|  5 -
   gcc/testsuite/g++.dg/warn/template-2.C | 22 ++
   2 files changed, 26 insertions(+), 1 deletion(-)
   create mode 100644 gcc/testsuite/g++.dg/warn/template-2.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 61cb75bf801..691f6e4df36 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -19423,7 +19423,10 @@ tsubst_copy_and_build (tree t,
 {
/* If T was type-dependent, suppress warnings that depend on the range
   of the types involved.  */
-   bool was_dep = uses_template_parms (t);
+   ++processing_template_decl;
+   bool was_dep = (!potential_constant_expression (t)
+   || value_dependent_expression_p (t));
+   --processing_template_decl;


Hmm, it seems weird to condition the warning on whether or not the
expression is constant.

Do we want type_dependent_expression_p or
instantiation_dependent_expression_p here?


So the question is essentially do we want to suppress the warnings for
value-dependent but not type-dependent expressions, like sizeof (T)?  I think
we don't need to, the second paragraph in my commit message explains why.
clang++ also warns for the new Wdiv-by-zero-3.C test.  Further, we already have
a _push variant of type_dependent_expression_p which is convenient.


I also wonder if we want to move the warning_sentinels after the RECURs.


...because we only mean to use them for build_x_binary_op purposes, not various
tsubst_* in the RECURs?  Makes sense, done.

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


OK.


-- >8 --
Here we ICE with -std=c++98 since the newly added call to uses_template_parms
(r10-6357): we hit
26530 gcc_assert (cxx_dialect >= cxx11
26531 || INTEGRAL_OR_ENUMERATION_TYPE_P (type));
and TYPE is a record type.  The problem is that the argument to
value_dependent_expression_p does not satisfy potential_constant_expression
which it must, as the comment explains.  I thought about fixing this in
uses_template_parms -- only call v_d_e_p if p_c_e is true, but in this
case we want to also suppress the warnings if we don't have a constant
expression.  I couldn't simply check TREE_CONSTANT as in
compute_array_index_type_loc, because then we'd stop warning in the new
Wtype-limits3.C test.

Fixed by using type_dependent_expression_p_push instead.  This means
that we won't suppress the warnings for value-dependent expressions that
aren't type-dependent, e.g. sizeof (T).  This only seems to make a
difference for -Wdiv-by-zero, now tested in Wdiv-by-zero-3.C, where I
think it's reasonable to warn.  It could make -Wtautological-compare
warn more, but that warning doesn't trigger when it gets constant arguments.
Wtype-limits4.C is a test reduced from poly-int.h and it tests a scenario
that was missing in our testsuite.

This patch also moves the warning_sentinels after the RECURs -- we mean
to use them for build_x_binary_op purposes only.

PR c++/94938
* pt.c (tsubst_copy_and_build): Call type_dependent_expression_p_push
instead of uses_template_parms.  Move the warning_sentinels after the
RECURs.

* g++.dg/warn/Wdiv-by-zero-3.C: New test.
* g++.dg/warn/Wtype-limits4.C: New test.
* g++.dg/warn/template-2.C: New test.
* g++.old-deja/g++.pt/crash10.C: Add dg-warning.
---
  gcc/cp/pt.c |  8 ---
  gcc/testsuite/g++.dg/warn/Wdiv-by-zero-3.C  | 17 +++
  gcc/testsuite/g++.dg/warn/Wtype-limits4.C   | 23 +
  gcc/testsuite/g++.dg/warn/template-2.C  | 22 
  gcc/testsuite/g++.old-deja/g++.pt/crash10.C |  1 +
  5 files changed, 68 insertions(+), 3 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/warn/Wdiv-by-zero-3.C
  

Re: [PATCH] c++: ICE with -Wall and constexpr if [PR94937]

2020-05-06 Thread Jason Merrill via Gcc-patches

On 5/5/20 6:17 PM, Marek Polacek wrote:

An ICE arises here because we call cp_get_callee_fndecl_nofold in a
template, and we've got a CALL_EXPR whose CALL_EXPR_FN is a BASELINK.
This tickles the INDIRECT_TYPE_P assert in cp_get_fndecl_from_callee.

Jakub said in the PR that he'd hit a similar problem too and dealt
with it in omp_declare_variant_finalize_one.  I considered tweaking
is_std_constant_evaluated_p to return false for a BASELINK, since the
std::is_constant_evaluated call we're looking for can't be a member
function, but perhaps we could get another unexpected CALL_EXPR and
crash the same.  In which case it might be better to make out the
omp_* code into a new routine and use that, as below.


Why not adjust cp_get_fndecl_from_callee to, say, return null instead of 
aborting when !INDIRECT_TYPE_P?



As a drive-by, I'm adding a test that tests the "is_constant_evaluated
in constexpr if" warning in a template too.

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

PR c++/94937
* cp-tree.h (cp_get_callee_fndecl_template): Declare.
* cvt.c (cp_get_callee_fndecl_template): New.
* decl.c (omp_declare_variant_finalize_one): Use
cp_get_callee_fndecl_template.
* semantics.c (is_std_constant_evaluated_p): Call
cp_get_callee_fndecl_template instead of cp_get_callee_fndecl_nofold.

* g++.dg/cpp1z/constexpr-if34.C: New test.
* g++.dg/cpp2a/is-constant-evaluated10.C: New test.
---
  gcc/cp/cp-tree.h  |  1 +
  gcc/cp/cvt.c  | 17 +++
  gcc/cp/decl.c | 12 +---
  gcc/cp/semantics.c|  2 +-
  gcc/testsuite/g++.dg/cpp1z/constexpr-if34.C   | 15 ++
  .../g++.dg/cpp2a/is-constant-evaluated10.C| 30 +++
  6 files changed, 65 insertions(+), 12 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp1z/constexpr-if34.C
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/is-constant-evaluated10.C

diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index c4b81428e14..ecee0f479b0 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -6477,6 +6477,7 @@ extern tree cp_fold_convert   (tree, 
tree);
  extern tree cp_get_callee (tree);
  extern tree cp_get_callee_fndecl  (tree);
  extern tree cp_get_callee_fndecl_nofold   (tree);
+extern tree cp_get_callee_fndecl_template  (tree);
  extern tree cp_get_fndecl_from_callee (tree, bool fold = true);
  extern tree convert_to_void   (tree, impl_conv_void,
 tsubst_flags_t);
diff --git a/gcc/cp/cvt.c b/gcc/cp/cvt.c
index 656e7fd3ec0..5d3fba76bb9 100644
--- a/gcc/cp/cvt.c
+++ b/gcc/cp/cvt.c
@@ -1027,6 +1027,23 @@ cp_get_callee_fndecl_nofold (tree call)
return cp_get_fndecl_from_callee (cp_get_callee (call), false);
  }
  
+/* As above, but is safe to call in a template too where we might get

+   unexpected trees.  Returns the FUNCTION_DECL or NULL_TREE.  */
+
+tree
+cp_get_callee_fndecl_template (tree call)
+{
+  call = cp_get_callee (call);
+  if (call == NULL_TREE)
+return NULL_TREE;
+  else if (TREE_CODE (call) == FUNCTION_DECL)
+return call;
+  else if (TREE_TYPE (call) && INDIRECT_TYPE_P (TREE_TYPE (call)))
+return cp_get_fndecl_from_callee (call, /*fold=*/false);
+  else
+return NULL_TREE;
+}
+
  /* Subroutine of convert_to_void.  Warn if we're discarding something with
 attribute [[nodiscard]].  */
  
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c

index 3e7ed98fed3..7b63304ebf3 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -7297,17 +7297,7 @@ omp_declare_variant_finalize_one (tree decl, tree attr)
if (variant == error_mark_node && !processing_template_decl)
  return true;
  
-  variant = cp_get_callee (variant);

-  if (variant)
-{
-  if (TREE_CODE (variant) == FUNCTION_DECL)
-   ;
-  else if (TREE_TYPE (variant) && INDIRECT_TYPE_P (TREE_TYPE (variant)))
-   variant = cp_get_fndecl_from_callee (variant, false);
-  else
-   variant = NULL_TREE;
-}
-
+  variant = cp_get_callee_fndecl_template (variant);
input_location = save_loc;
  
if (variant)

diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 4d1592ab0d2..716ee48446d 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -734,7 +734,7 @@ is_std_constant_evaluated_p (tree fn)
if (call_expr_nargs (fn) != 0)
  return false;
  
-  tree fndecl = cp_get_callee_fndecl_nofold (fn);

+  tree fndecl = cp_get_callee_fndecl_template (fn);
if (fndecl == NULL_TREE)
  return false;
  
diff --git a/gcc/testsuite/g++.dg/cpp1z/constexpr-if34.C b/gcc/testsuite/g++.dg/cpp1z/constexpr-if34.C

new file mode 100644
index 000..6e0b2597a53
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1z/constexpr-if34.C
@@ -0,0 +1,15 @@
+// PR c++/94937 - ICE with -Wall and 

Re: [PATCH] c++: Don't synthesize sfk_comparison method multiple times [PR94907]

2020-05-06 Thread Jason Merrill via Gcc-patches

On 5/5/20 3:15 AM, Jakub Jelinek wrote:

Hi!

On the following testcase we ICE, because synthesize_method is called twice
on the same sfk_comparison method fndecl, the first time it works fine
because start_preparsed_function in that case sets both
current_function_decl and cfun, but second time it is called it only sets
the former and keeps cfun NULL, so we ICE when trying to store
current_function_returns_value.
I think it is just wrong to call synthesize_method multiple times, and most
synthesize_method callers avoid that by not calling it if DECL_INITIAL is
already set, so this patch does that too.

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


OK for trunk and 10.x.


2020-05-05  Jakub Jelinek  

PR c++/94907
* method.c (defaulted_late_check): Don't call synthesize_method
on constexpr sfk_comparison if it has been called on it already.

* g++.dg/cpp2a/spaceship-synth8.C: New test.

--- gcc/cp/method.c.jj  2020-04-29 09:00:24.525851362 +0200
+++ gcc/cp/method.c 2020-05-04 15:41:14.016544034 +0200
@@ -2939,7 +2939,7 @@ defaulted_late_check (tree fn)
  {
/* If the function was declared constexpr, check that the definition
 qualifies.  Otherwise we can define the function lazily.  */
-  if (DECL_DECLARED_CONSTEXPR_P (fn))
+  if (DECL_DECLARED_CONSTEXPR_P (fn) && !DECL_INITIAL (fn))
synthesize_method (fn);
return;
  }
--- gcc/testsuite/g++.dg/cpp2a/spaceship-synth8.C.jj2020-05-04 
15:34:02.106002574 +0200
+++ gcc/testsuite/g++.dg/cpp2a/spaceship-synth8.C   2020-05-04 
15:33:51.654158860 +0200
@@ -0,0 +1,12 @@
+// PR c++/94907
+// { dg-do compile { target c++2a } }
+
+namespace std { struct strong_ordering { }; }
+
+struct E;
+struct D {
+  virtual std::strong_ordering operator<=>(const struct E&) const = 0;
+};
+struct E : D {
+  std::strong_ordering operator<=>(const E&) const override = default;
+};

Jakub





[committed] i386: Use generic division to generate INEXACT exception

2020-05-06 Thread Uros Bizjak via Gcc-patches
Introduce math_force_eval_div to use generic division to generate
INEXACT as well as INVALID and DIVZERO exceptions.

libgcc/ChangeLog:

2020-05-06  Uroš Bizjak  

* config/i386/sfp-exceptions.c (__math_force_eval): Remove.
(__math_force_eval_div): New define.
(__sfp_handle_exceptions): Use __math_force_eval_div to use
generic division to generate INVALID, DIVZERO and INEXACT
exceptions.

libatomic/ChangeLog:

2020-05-06  Uroš Bizjak  

* config/x86/fenv.c (__math_force_eval): Remove.
(__math_force_eval_div): New define.
(__atomic_deraiseexcept): Use __math_force_eval_div to use
generic division to generate INVALID, DIVZERO and INEXACT
exceptions.

libgfortran/ChangeLog:

2020-05-06  Uroš Bizjak  

* config/fpu-387.h (__math_force_eval): Remove.
(__math_force_eval_div): New define.
(local_feraiseexcept): Use __math_force_eval_div to use
generic division to generate INVALID, DIVZERO and INEXACT
exceptions.
(struct fenv): Define named struct instead of typedef.

Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.

Committed to mainline.

Uros.
diff --git a/libatomic/config/x86/fenv.c b/libatomic/config/x86/fenv.c
index d972a99f594..88622c613f3 100644
--- a/libatomic/config/x86/fenv.c
+++ b/libatomic/config/x86/fenv.c
@@ -48,9 +48,11 @@ struct fenv
 };
 
 #ifdef __SSE_MATH__
-# define __math_force_eval(x) asm volatile ("" : : "x" (x));
+# define __math_force_eval_div(x, y) \
+  do { asm ("" : "+x" (x)); asm volatile ("" : : "x" (x / y)); } while (0)
 #else
-# define __math_force_eval(x) asm volatile ("" : : "f" (x));
+# define __math_force_eval_div(x, y) \
+  do { asm ("" : "+t" (x)); asm volatile ("" : : "f" (x / y)); } while (0)
 #endif
 
 /* Raise the supported floating-point exceptions from EXCEPTS.  Other
@@ -59,14 +61,15 @@ struct fenv
 void
 __atomic_feraiseexcept (int excepts)
 {
+  struct fenv temp;
+
   if (excepts & FE_INVALID)
 {
   float f = 0.0f;
-  __math_force_eval (f / f);
+  __math_force_eval_div (f, f);
 }
   if (excepts & FE_DENORM)
 {
-  struct fenv temp;
   asm volatile ("fnstenv\t%0" : "=m" (temp));
   temp.__status_word |= FE_DENORM;
   asm volatile ("fldenv\t%0" : : "m" (temp));
@@ -75,11 +78,10 @@ __atomic_feraiseexcept (int excepts)
   if (excepts & FE_DIVBYZERO)
 {
   float f = 1.0f, g = 0.0f;
-  __math_force_eval (f / g);
+  __math_force_eval_div (f, g);
 }
   if (excepts & FE_OVERFLOW)
 {
-  struct fenv temp;
   asm volatile ("fnstenv\t%0" : "=m" (temp));
   temp.__status_word |= FE_OVERFLOW;
   asm volatile ("fldenv\t%0" : : "m" (temp));
@@ -87,7 +89,6 @@ __atomic_feraiseexcept (int excepts)
 }
   if (excepts & FE_UNDERFLOW)
 {
-  struct fenv temp;
   asm volatile ("fnstenv\t%0" : "=m" (temp));
   temp.__status_word |= FE_UNDERFLOW;
   asm volatile ("fldenv\t%0" : : "m" (temp));
@@ -96,11 +97,6 @@ __atomic_feraiseexcept (int excepts)
   if (excepts & FE_INEXACT)
 {
   float f = 1.0f, g = 3.0f;
-#ifdef __SSE_MATH__
-  asm volatile ("%vdivss\t{%1, %d0|%d0, %1}" : "+x" (f) : "xm" (g));
-#else
-  asm volatile ("fdivs\t%1" : "+t" (f) : "m" (g));
-  /* No need for fwait, exception is triggered by emitted fstp.  */
-#endif
+  __math_force_eval_div (f, g);
 }
 }
diff --git a/libgcc/config/i386/sfp-exceptions.c 
b/libgcc/config/i386/sfp-exceptions.c
index 4b3a7a08da1..72cb0f4d3bb 100644
--- a/libgcc/config/i386/sfp-exceptions.c
+++ b/libgcc/config/i386/sfp-exceptions.c
@@ -42,22 +42,25 @@ struct fenv
 };
 
 #ifdef __SSE_MATH__
-# define __math_force_eval(x) asm volatile ("" : : "x" (x));
+# define __math_force_eval_div(x, y) \
+  do { asm ("" : "+x" (x)); asm volatile ("" : : "x" (x / y)); } while (0)
 #else
-# define __math_force_eval(x) asm volatile ("" : : "f" (x));
+# define __math_force_eval_div(x, y) \
+  do { asm ("" : "+t" (x)); asm volatile ("" : : "f" (x / y)); } while (0)
 #endif
 
 void
 __sfp_handle_exceptions (int _fex)
 {
+  struct fenv temp;
+
   if (_fex & FP_EX_INVALID)
 {
   float f = 0.0f;
-  __math_force_eval (f / f);
+  __math_force_eval_div (f, f);
 }
   if (_fex & FP_EX_DENORM)
 {
-  struct fenv temp;
   asm volatile ("fnstenv\t%0" : "=m" (temp));
   temp.__status_word |= FP_EX_DENORM;
   asm volatile ("fldenv\t%0" : : "m" (temp));
@@ -66,11 +69,10 @@ __sfp_handle_exceptions (int _fex)
   if (_fex & FP_EX_DIVZERO)
 {
   float f = 1.0f, g = 0.0f;
-  __math_force_eval (f / g);
+  __math_force_eval_div (f, g);
 }
   if (_fex & FP_EX_OVERFLOW)
 {
-  struct fenv temp;
   asm volatile ("fnstenv\t%0" : "=m" (temp));
   temp.__status_word |= FP_EX_OVERFLOW;
   asm volatile ("fldenv\t%0" : : "m" (temp));
@@ -78,7 +80,6 @@ __sfp_handle_exceptions (int _fex)
 }
   if (_fex & FP_EX_UNDERFLOW)
 {
-  struct fenv temp;
   asm volatile ("fnstenv\t%0" : "=m" (temp));
   

Re: [PATCH 0/4] rs6000: setbnc and friends [pu]

2020-05-06 Thread Bill Schmidt via Gcc-patches
For all of these, I forgot to mention that they have been bootstrapped 
and tested on powerpc64le-unknown-linux-gnu with no regressions.  Are 
these okay for trunk, after GCC 10 is fully released?


Thanks,
Bill

On 5/6/20 3:31 PM, Bill Schmidt via Gcc-patches wrote:

*** BLURB HERE ***

Bill Schmidt (4):
   Add insns for setbc and setbcr
   Add tests for setbc and setbcr
   Add insns for setnbc and setnbcr
   Add tests for setnbc and setnbcr

  gcc/config/rs6000/rs6000.md | 100 +---
  gcc/testsuite/gcc.target/powerpc/setbc.h|  27 ++
  gcc/testsuite/gcc.target/powerpc/setbceq.c  |   9 ++
  gcc/testsuite/gcc.target/powerpc/setbcge.c  |  12 +++
  gcc/testsuite/gcc.target/powerpc/setbcgt.c  |  10 ++
  gcc/testsuite/gcc.target/powerpc/setbcle.c  |  10 ++
  gcc/testsuite/gcc.target/powerpc/setbclt.c  |  12 +++
  gcc/testsuite/gcc.target/powerpc/setbcne.c  |   9 ++
  gcc/testsuite/gcc.target/powerpc/setnbc.h   |  27 ++
  gcc/testsuite/gcc.target/powerpc/setnbceq.c |   9 ++
  gcc/testsuite/gcc.target/powerpc/setnbcge.c |  12 +++
  gcc/testsuite/gcc.target/powerpc/setnbcgt.c |  10 ++
  gcc/testsuite/gcc.target/powerpc/setnbcle.c |  10 ++
  gcc/testsuite/gcc.target/powerpc/setnbclt.c |  12 +++
  gcc/testsuite/gcc.target/powerpc/setnbcne.c |   9 ++
  15 files changed, 263 insertions(+), 15 deletions(-)
  create mode 100644 gcc/testsuite/gcc.target/powerpc/setbc.h
  create mode 100644 gcc/testsuite/gcc.target/powerpc/setbceq.c
  create mode 100644 gcc/testsuite/gcc.target/powerpc/setbcge.c
  create mode 100644 gcc/testsuite/gcc.target/powerpc/setbcgt.c
  create mode 100644 gcc/testsuite/gcc.target/powerpc/setbcle.c
  create mode 100644 gcc/testsuite/gcc.target/powerpc/setbclt.c
  create mode 100644 gcc/testsuite/gcc.target/powerpc/setbcne.c
  create mode 100644 gcc/testsuite/gcc.target/powerpc/setnbc.h
  create mode 100644 gcc/testsuite/gcc.target/powerpc/setnbceq.c
  create mode 100644 gcc/testsuite/gcc.target/powerpc/setnbcge.c
  create mode 100644 gcc/testsuite/gcc.target/powerpc/setnbcgt.c
  create mode 100644 gcc/testsuite/gcc.target/powerpc/setnbcle.c
  create mode 100644 gcc/testsuite/gcc.target/powerpc/setnbclt.c
  create mode 100644 gcc/testsuite/gcc.target/powerpc/setnbcne.c



Re: [PATCH] testsuite:analyzer: Fix header include for FreeBSD

2020-05-06 Thread Andreas Tobler

On 06.05.20 22:27, Kamil Rytarowski wrote:

On 06.05.2020 22:25, Andreas Tobler wrote:

On 06.05.20 22:12, Jakub Jelinek wrote:

On Wed, May 06, 2020 at 09:54:47PM +0200, Andreas Tobler wrote:

--- a/gcc/testsuite/gcc.dg/analyzer/alloca-leak.c
+++ b/gcc/testsuite/gcc.dg/analyzer/alloca-leak.c
@@ -1,5 +1,6 @@
-#include 
-
+#include 


It needs to be:

+#if __has_include()


+#include 


+#endif


Doh :(

Fixed, thanks.


__has_include doesn't include anything, just checks if the header is
available.


Then I just wonder why the tests passed on Linux (ubuntu-20.04)



alloca.h is only needed on solaris. Other system can use stdlib.h.


Ok, I see. and alloca-leak.c succeed because I included unconditionally 
the stdlib.h. Sigh, foot shot.


Thanks,
Andreas




[PATCH 0/4] rs6000: setbnc and friends [pu]

2020-05-06 Thread Bill Schmidt via Gcc-patches
*** BLURB HERE ***

Bill Schmidt (4):
  Add insns for setbc and setbcr
  Add tests for setbc and setbcr
  Add insns for setnbc and setnbcr
  Add tests for setnbc and setnbcr

 gcc/config/rs6000/rs6000.md | 100 +---
 gcc/testsuite/gcc.target/powerpc/setbc.h|  27 ++
 gcc/testsuite/gcc.target/powerpc/setbceq.c  |   9 ++
 gcc/testsuite/gcc.target/powerpc/setbcge.c  |  12 +++
 gcc/testsuite/gcc.target/powerpc/setbcgt.c  |  10 ++
 gcc/testsuite/gcc.target/powerpc/setbcle.c  |  10 ++
 gcc/testsuite/gcc.target/powerpc/setbclt.c  |  12 +++
 gcc/testsuite/gcc.target/powerpc/setbcne.c  |   9 ++
 gcc/testsuite/gcc.target/powerpc/setnbc.h   |  27 ++
 gcc/testsuite/gcc.target/powerpc/setnbceq.c |   9 ++
 gcc/testsuite/gcc.target/powerpc/setnbcge.c |  12 +++
 gcc/testsuite/gcc.target/powerpc/setnbcgt.c |  10 ++
 gcc/testsuite/gcc.target/powerpc/setnbcle.c |  10 ++
 gcc/testsuite/gcc.target/powerpc/setnbclt.c |  12 +++
 gcc/testsuite/gcc.target/powerpc/setnbcne.c |   9 ++
 15 files changed, 263 insertions(+), 15 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/powerpc/setbc.h
 create mode 100644 gcc/testsuite/gcc.target/powerpc/setbceq.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/setbcge.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/setbcgt.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/setbcle.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/setbclt.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/setbcne.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/setnbc.h
 create mode 100644 gcc/testsuite/gcc.target/powerpc/setnbceq.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/setnbcge.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/setnbcgt.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/setnbcle.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/setnbclt.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/setnbcne.c

-- 
2.17.1



Re: [committed] combine: Don't replace SET_SRC with REG_EQUAL note content if SET_SRC has side-effects [PR94873]

2020-05-06 Thread Segher Boessenkool
On Wed, May 06, 2020 at 09:36:55AM +0200, Jakub Jelinek wrote:
> There were some discussions about whether REG_EQUAL notes are valid on insns 
> with a single
> set which contains auto-inc-dec side-effects in the SET_SRC and the majority 
> thinks that
> it should be valid.  So, this patch fixes the combiner to punt in that case, 
> because otherwise
> the auto-inc-dec side-effects from the SET_SRC are lost.
> 
> Bootstrapped/regtested on {x86_64,i686,aarch64,powerpc64{,le}}-linux,
> preapproved in the PR by Segher, committed to trunk so far.

Thanks!  It would be nice if we could handle this more centrally, make
sure we never lose (significant) side effects.  Maybe that cannot be
done with current RTL :-/


Segher


[PATCH 4/4] rs6000: Tests for setnbc

2020-05-06 Thread Bill Schmidt via Gcc-patches
2020-05-06  Segher Boessenkool  

* gcc.target/powerpc/setnbc.h: New.
* gcc.target/powerpc/setnbceq.c: New.
* gcc.target/powerpc/setnbcge.c: New.
* gcc.target/powerpc/setnbcgt.c: New.
* gcc.target/powerpc/setnbcle.c: New.
* gcc.target/powerpc/setnbclt.c: New.
* gcc.target/powerpc/setnbcne.c: New.
---
 gcc/testsuite/gcc.target/powerpc/setnbc.h   | 27 +
 gcc/testsuite/gcc.target/powerpc/setnbceq.c |  9 +++
 gcc/testsuite/gcc.target/powerpc/setnbcge.c | 12 +
 gcc/testsuite/gcc.target/powerpc/setnbcgt.c | 10 
 gcc/testsuite/gcc.target/powerpc/setnbcle.c | 10 
 gcc/testsuite/gcc.target/powerpc/setnbclt.c | 12 +
 gcc/testsuite/gcc.target/powerpc/setnbcne.c |  9 +++
 7 files changed, 89 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/powerpc/setnbc.h
 create mode 100644 gcc/testsuite/gcc.target/powerpc/setnbceq.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/setnbcge.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/setnbcgt.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/setnbcle.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/setnbclt.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/setnbcne.c

diff --git a/gcc/testsuite/gcc.target/powerpc/setnbc.h 
b/gcc/testsuite/gcc.target/powerpc/setnbc.h
new file mode 100644
index 000..d278d4a687f
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/setnbc.h
@@ -0,0 +1,27 @@
+#define XSTR(a,b) a ## b
+#define T(a,b) XSTR(a,b)
+
+int  T(NAME,ii)(int a, int b)   { return -(a CODE b); }
+int  T(NAME,il)(long a, long b) { return -(a CODE b); }
+long T(NAME,li)(int a, int b)   { return -(a CODE b); }
+long T(NAME,ll)(long a, long b) { return -(a CODE b); }
+
+int  T(NAME,iin0)(int a)  { return -(a CODE 0); }
+int  T(NAME,iln0)(long a) { return -(a CODE 0); }
+long T(NAME,lin0)(int a)  { return -(a CODE 0); }
+long T(NAME,lln0)(long a) { return -(a CODE 0); }
+
+int  T(NAME,iin1)(int a)  { return -(a CODE 1); }
+int  T(NAME,iln1)(long a) { return -(a CODE 1); }
+long T(NAME,lin1)(int a)  { return -(a CODE 1); }
+long T(NAME,lln1)(long a) { return -(a CODE 1); }
+
+int  T(NAME,iinm1)(int a)  { return -(a CODE -1); }
+int  T(NAME,ilnm1)(long a) { return -(a CODE -1); }
+long T(NAME,linm1)(int a)  { return -(a CODE -1); }
+long T(NAME,llnm1)(long a) { return -(a CODE -1); }
+
+int  T(NAME,iin42)(int a)  { return -(a CODE 42); }
+int  T(NAME,iln42)(long a) { return -(a CODE 42); }
+long T(NAME,lin42)(int a)  { return -(a CODE 42); }
+long T(NAME,lln42)(long a) { return -(a CODE 42); }
diff --git a/gcc/testsuite/gcc.target/powerpc/setnbceq.c 
b/gcc/testsuite/gcc.target/powerpc/setnbceq.c
new file mode 100644
index 000..ff4af8f71fa
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/setnbceq.c
@@ -0,0 +1,9 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -mcpu=future" } */
+
+#define NAME eq
+#define CODE ==
+
+#include "setnbc.h"
+
+/* { dg-final { scan-assembler-times {\msetnbc\M} 20 } } */
diff --git a/gcc/testsuite/gcc.target/powerpc/setnbcge.c 
b/gcc/testsuite/gcc.target/powerpc/setnbcge.c
new file mode 100644
index 000..68ee6bda0d0
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/setnbcge.c
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -mcpu=future" } */
+
+#define NAME ge
+#define CODE >=
+
+#include "setnbc.h"
+
+/* "x >= 0" is done without setnbc.
+   The generic code sometimes transforms "x >= A" to "x > A-1"; we allow
+   either here.  */
+/* { dg-final { scan-assembler-times {\msetnbcr?\M} 16 } } */
diff --git a/gcc/testsuite/gcc.target/powerpc/setnbcgt.c 
b/gcc/testsuite/gcc.target/powerpc/setnbcgt.c
new file mode 100644
index 000..e0f51d49bd1
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/setnbcgt.c
@@ -0,0 +1,10 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -mcpu=future" } */
+
+#define NAME gt
+#define CODE >
+
+#include "setnbc.h"
+
+/* "x > -1" is done without setnbc.  */
+/* { dg-final { scan-assembler-times {\msetnbc\M} 16 } } */
diff --git a/gcc/testsuite/gcc.target/powerpc/setnbcle.c 
b/gcc/testsuite/gcc.target/powerpc/setnbcle.c
new file mode 100644
index 000..33a5da96964
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/setnbcle.c
@@ -0,0 +1,10 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -mcpu=future" } */
+
+#define NAME le
+#define CODE <=
+
+#include "setnbc.h"
+
+/* "x <= -1" is done without setnbc.  */
+/* { dg-final { scan-assembler-times {\msetnbcr\M} 16 } } */
diff --git a/gcc/testsuite/gcc.target/powerpc/setnbclt.c 
b/gcc/testsuite/gcc.target/powerpc/setnbclt.c
new file mode 100644
index 000..127d7bfece4
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/setnbclt.c
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -mcpu=future" } */
+
+#define NAME lt
+#define CODE <
+
+#include "setnbc.h"
+
+/* "x < 0" is done without setnbc.
+   The generic code sometimes transforms "x < A" to "x <= A-1"; 

[PATCH] c++: ICE when shortening right shift [PR94955]

2020-05-06 Thread Marek Polacek via Gcc-patches
Since r10-6527 fold_for_warn calls maybe_constant_value, which means it
can fold more than it previously could.  In this testcase it means that
cp_build_binary_op/RSHIFT_EXPR set short_shift because now we were able
to fold op1 to an INTEGER_CST.  But then when actually performing the
shortening we crashed because cp_fold_rvalue wasn't able to fold as much
as f_f_w and so tree_int_cst_sgn crashed on a NOP_EXPR.  Therefore the
calls should probably match.

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

PR c++/94955
* typeck.c (cp_build_binary_op): Use fold_for_warn instead of
cp_fold_rvalue.

* g++.dg/cpp0x/constexpr-shift2.C: New test.
---
 gcc/cp/typeck.c   |  4 +++-
 gcc/testsuite/g++.dg/cpp0x/constexpr-shift2.C | 12 
 2 files changed, 15 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/constexpr-shift2.C

diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c
index 8e3188a415d..b468e92896a 100644
--- a/gcc/cp/typeck.c
+++ b/gcc/cp/typeck.c
@@ -5606,7 +5606,9 @@ cp_build_binary_op (const op_location_t ,
{
  int unsigned_arg;
  tree arg0 = get_narrower (op0, _arg);
- tree const_op1 = cp_fold_rvalue (op1);
+ /* We're not really warning here but when we set short_shift we
+used fold_for_warn to fold the operand.  */
+ tree const_op1 = fold_for_warn (op1);
 
  final_type = result_type;
 
diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-shift2.C 
b/gcc/testsuite/g++.dg/cpp0x/constexpr-shift2.C
new file mode 100644
index 000..9b3490a66a7
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/constexpr-shift2.C
@@ -0,0 +1,12 @@
+// PR c++/94955
+// { dg-do compile { target c++11 } }
+
+struct S {
+  static constexpr char foo() { return 10; }
+};
+
+short int
+fn (short int e)
+{
+  return e >> S::foo();
+}

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



[PATCH 2/4] rs6000: Tests for setbc

2020-05-06 Thread Bill Schmidt via Gcc-patches
2020-05-06  Segher Boessenkool  

* gcc.target/powerpc/setbc.h: New.
* gcc.target/powerpc/setbceq.c: New.
* gcc.target/powerpc/setbcge.c: New.
* gcc.target/powerpc/setbcgt.c: New.
* gcc.target/powerpc/setbcle.c: New.
* gcc.target/powerpc/setbclt.c: New.
* gcc.target/powerpc/setbcne.c: New.
---
 gcc/testsuite/gcc.target/powerpc/setbc.h   | 27 ++
 gcc/testsuite/gcc.target/powerpc/setbceq.c |  9 
 gcc/testsuite/gcc.target/powerpc/setbcge.c | 12 ++
 gcc/testsuite/gcc.target/powerpc/setbcgt.c | 10 
 gcc/testsuite/gcc.target/powerpc/setbcle.c | 10 
 gcc/testsuite/gcc.target/powerpc/setbclt.c | 12 ++
 gcc/testsuite/gcc.target/powerpc/setbcne.c |  9 
 7 files changed, 89 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/powerpc/setbc.h
 create mode 100644 gcc/testsuite/gcc.target/powerpc/setbceq.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/setbcge.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/setbcgt.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/setbcle.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/setbclt.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/setbcne.c

diff --git a/gcc/testsuite/gcc.target/powerpc/setbc.h 
b/gcc/testsuite/gcc.target/powerpc/setbc.h
new file mode 100644
index 000..51334246eca
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/setbc.h
@@ -0,0 +1,27 @@
+#define XSTR(a,b) a ## b
+#define T(a,b) XSTR(a,b)
+
+int  T(NAME,ii)(int a, int b)   { return a CODE b; }
+int  T(NAME,il)(long a, long b) { return a CODE b; }
+long T(NAME,li)(int a, int b)   { return a CODE b; }
+long T(NAME,ll)(long a, long b) { return a CODE b; }
+
+int  T(NAME,iin0)(int a)  { return a CODE 0; }
+int  T(NAME,iln0)(long a) { return a CODE 0; }
+long T(NAME,lin0)(int a)  { return a CODE 0; }
+long T(NAME,lln0)(long a) { return a CODE 0; }
+
+int  T(NAME,iin1)(int a)  { return a CODE 1; }
+int  T(NAME,iln1)(long a) { return a CODE 1; }
+long T(NAME,lin1)(int a)  { return a CODE 1; }
+long T(NAME,lln1)(long a) { return a CODE 1; }
+
+int  T(NAME,iinm1)(int a)  { return a CODE -1; }
+int  T(NAME,ilnm1)(long a) { return a CODE -1; }
+long T(NAME,linm1)(int a)  { return a CODE -1; }
+long T(NAME,llnm1)(long a) { return a CODE -1; }
+
+int  T(NAME,iin42)(int a)  { return a CODE 42; }
+int  T(NAME,iln42)(long a) { return a CODE 42; }
+long T(NAME,lin42)(int a)  { return a CODE 42; }
+long T(NAME,lln42)(long a) { return a CODE 42; }
diff --git a/gcc/testsuite/gcc.target/powerpc/setbceq.c 
b/gcc/testsuite/gcc.target/powerpc/setbceq.c
new file mode 100644
index 000..ee3cbffa6f5
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/setbceq.c
@@ -0,0 +1,9 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -mcpu=future" } */
+
+#define NAME eq
+#define CODE ==
+
+#include "setbc.h"
+
+/* { dg-final { scan-assembler-times {\msetbc\M} 20 } } */
diff --git a/gcc/testsuite/gcc.target/powerpc/setbcge.c 
b/gcc/testsuite/gcc.target/powerpc/setbcge.c
new file mode 100644
index 000..06d58159768
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/setbcge.c
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -mcpu=future" } */
+
+#define NAME ge
+#define CODE >=
+
+#include "setbc.h"
+
+/* "x >= 0" is done without setbc.
+   The generic code sometimes transforms "x >= A" to "x > A-1"; we allow
+   either here.  */
+/* { dg-final { scan-assembler-times {\msetbcr?\M} 16 } } */
diff --git a/gcc/testsuite/gcc.target/powerpc/setbcgt.c 
b/gcc/testsuite/gcc.target/powerpc/setbcgt.c
new file mode 100644
index 000..864ae3a7e44
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/setbcgt.c
@@ -0,0 +1,10 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -mcpu=future" } */
+
+#define NAME gt
+#define CODE >
+
+#include "setbc.h"
+
+/* "x > -1" is done without setbc.  */
+/* { dg-final { scan-assembler-times {\msetbc\M} 16 } } */
diff --git a/gcc/testsuite/gcc.target/powerpc/setbcle.c 
b/gcc/testsuite/gcc.target/powerpc/setbcle.c
new file mode 100644
index 000..05df4075b1c
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/setbcle.c
@@ -0,0 +1,10 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -mcpu=future" } */
+
+#define NAME le
+#define CODE <=
+
+#include "setbc.h"
+
+/* "x <= -1" is done without setbc.  */
+/* { dg-final { scan-assembler-times {\msetbcr\M} 16 } } */
diff --git a/gcc/testsuite/gcc.target/powerpc/setbclt.c 
b/gcc/testsuite/gcc.target/powerpc/setbclt.c
new file mode 100644
index 000..52ffb1fd7e1
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/setbclt.c
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -mcpu=future" } */
+
+#define NAME lt
+#define CODE <
+
+#include "setbc.h"
+
+/* "x < 0" is done without setbc.
+   The generic code sometimes transforms "x < A" to "x <= A-1"; we allow
+   either here.  */
+/* { dg-final { scan-assembler-times {\msetbcr?\M} 16 } } */
diff --git 

[PATCH 1/4] rs6000: New insns setbc and setbcr

2020-05-06 Thread Bill Schmidt via Gcc-patches
New instructions setbc and setbcr.  setbc sets a GPR to 1 if some
condition register bit is set, and 0 otherwise; setbcr does it the
other way around.

2020-05-06  Segher Boessenkool  

* config/rs6000/rs6000.md (setbc_signed_): New
define_insn.
(*setbcr_signed_): Likewise.
(cstore4): Use setbc[r] if available.
(2_isel): Avoid for TARGET_FUTURE.
(eq3): Use setbc for TARGET_FUTURE.
(*eq3): Avoid for TARGET_FUTURE.
(ne3): Replace :P with :GPR; use setbc for TARGET_FUTURE;
else for non-Pmode, use gen_eq and gen_xor.
(*ne3): Avoid for TARGET_FUTURE.
(*eqsi3_ext): Avoid for TARGET_FUTURE; fix missing && 1.
---
 gcc/config/rs6000/rs6000.md | 73 +++--
 1 file changed, 62 insertions(+), 11 deletions(-)

diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index 6173994797c..e8dc576779a 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -5138,6 +5138,25 @@ (define_insn "*isel_reversed_signed_"
 }
   [(set_attr "type" "isel")])
 
+; Set Boolean Condition (Reverse)
+(define_insn "setbc_signed_"
+  [(set (match_operand:GPR 0 "gpc_reg_operand" "=r")
+   (match_operator:GPR 1 "scc_comparison_operator"
+   [(match_operand:CCEITHER 2 "cc_reg_operand" "y")
+(const_int 0)]))]
+  "TARGET_FUTURE"
+  "setbc %0,%j1"
+  [(set_attr "type" "isel")])
+
+(define_insn "*setbcr_signed_"
+  [(set (match_operand:GPR 0 "gpc_reg_operand" "=r")
+   (match_operator:GPR 1 "scc_rev_comparison_operator"
+   [(match_operand:CCEITHER 2 "cc_reg_operand" "y")
+(const_int 0)]))]
+  "TARGET_FUTURE"
+  "setbcr %0,%j1"
+  [(set_attr "type" "isel")])
+
 ;; Floating point conditional move
 (define_expand "movcc"
[(set (match_operand:SFDF 0 "gpc_reg_operand")
@@ -11425,6 +11444,10 @@ (define_expand "cstore4"
(clobber (match_operand:GPR 0 "gpc_reg_operand"))]
   ""
 {
+  /* Everything is best done with setbc[r] if available.  */
+  if (TARGET_FUTURE)
+rs6000_emit_int_cmove (operands[0], operands[1], const1_rtx, const0_rtx);
+
   /* Expanding EQ and NE directly to some machine instructions does not help
  but does hurt combine.  So don't.  */
   if (GET_CODE (operands[1]) == EQ)
@@ -11837,7 +11860,7 @@ (define_insn_and_split 
"2_isel"
(clobber (match_scratch:GPR 3 "=r"))
(clobber (match_scratch:GPR 4 "=r"))
(clobber (match_scratch: 5 "=y"))]
-  "TARGET_ISEL
+  "!TARGET_FUTURE && TARGET_ISEL
&& !( == EQ && operands[2] == const0_rtx)
&& !( == NE && operands[2] == const0_rtx
&& mode == Pmode && mode == Pmode)"
@@ -11917,6 +11940,16 @@ (define_expand "eq3"
  (clobber (match_scratch:GPR 4 "=r"))])]
   ""
 {
+  if (TARGET_FUTURE)
+{
+  rtx cc = gen_reg_rtx (CCmode);
+  rtx compare = gen_rtx_COMPARE (CCmode, operands[1], operands[2]);
+  emit_insn (gen_rtx_SET (cc, compare));
+  rtx eq = gen_rtx_fmt_ee (EQ, mode, cc, const0_rtx);
+  emit_insn (gen_setbc_signed_ (operands[0], eq, cc));
+  DONE;
+}
+
   if (TARGET_ISEL && operands[2] != const0_rtx)
 {
   emit_insn (gen_eq2_isel (operands[0], operands[1],
@@ -11931,7 +11964,7 @@ (define_insn_and_split "*eq3"
(match_operand:GPR 2 "scc_eq_operand" "")))
(clobber (match_scratch:GPR 3 "=r"))
(clobber (match_scratch:GPR 4 "=r"))]
-  "!(TARGET_ISEL && operands[2] != const0_rtx)"
+  "!TARGET_FUTURE && !(TARGET_ISEL && operands[2] != const0_rtx)"
   "#"
   "&& 1"
   [(set (match_dup 4)
@@ -11955,14 +11988,32 @@ (define_insn_and_split "*eq3"
 
 (define_expand "ne3"
   [(parallel [
- (set (match_operand:P 0 "gpc_reg_operand" "=r")
- (ne:P (match_operand:P 1 "gpc_reg_operand" "r")
-   (match_operand:P 2 "scc_eq_operand" "")))
- (clobber (match_scratch:P 3 "=r"))
- (clobber (match_scratch:P 4 "=r"))
- (clobber (reg:P CA_REGNO))])]
+ (set (match_operand:GPR 0 "gpc_reg_operand" "=r")
+ (ne:GPR (match_operand:GPR 1 "gpc_reg_operand" "r")
+   (match_operand:GPR 2 "scc_eq_operand" "")))
+ (clobber (match_scratch:GPR 3 "=r"))
+ (clobber (match_scratch:GPR 4 "=r"))
+ (clobber (reg:GPR CA_REGNO))])]
   ""
 {
+  if (TARGET_FUTURE)
+{
+  rtx cc = gen_reg_rtx (CCmode);
+  rtx compare = gen_rtx_COMPARE (CCmode, operands[1], operands[2]);
+  emit_insn (gen_rtx_SET (cc, compare));
+  rtx ne = gen_rtx_fmt_ee (NE, mode, cc, const0_rtx);
+  emit_insn (gen_setbc_signed_ (operands[0], ne, cc));
+  DONE;
+}
+
+  if (mode != Pmode)
+{
+  rtx x = gen_reg_rtx (mode);
+  emit_insn (gen_eq3 (x, operands[1], operands[2]));
+  emit_insn (gen_xor3 (operands[0], x, const1_rtx));
+  DONE;
+}
+
   if (TARGET_ISEL && operands[2] != const0_rtx)
 {
   emit_insn (gen_ne2_isel (operands[0], operands[1],
@@ -11978,7 +12029,7 @@ (define_insn_and_split "*ne3"

[PATCH 3/4] rs6000: New insns setnbc and setnbcr

2020-05-06 Thread Bill Schmidt via Gcc-patches
setnbc[r] is like setbc[r], but it writes -1 instead of 1 to the GPR.

2020-05-06  Segher Boessenkool  

* config/rs6000/rs6000.md (*setnbc_signed_): New
define_insn.
(*setnbcr_signed_): New define_insn.
(*neg_eq_): Avoid for TARGET_FUTURE; add missing && 1.
(*neg_ne_): Likewise.
---
 gcc/config/rs6000/rs6000.md | 27 +++
 1 file changed, 23 insertions(+), 4 deletions(-)

diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index e8dc576779a..c02c2e1de72 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -5157,6 +5157,25 @@ (define_insn "*setbcr_signed_"
   "setbcr %0,%j1"
   [(set_attr "type" "isel")])
 
+; Set Negative Boolean Condition (Reverse)
+(define_insn "*setnbc_signed_"
+  [(set (match_operand:GPR 0 "gpc_reg_operand" "=r")
+   (neg:GPR (match_operator:GPR 1 "scc_comparison_operator"
+   [(match_operand:CCEITHER 2 "cc_reg_operand" "y")
+(const_int 0)])))]
+  "TARGET_FUTURE"
+  "setnbc %0,%j1"
+  [(set_attr "type" "isel")])
+
+(define_insn "*setnbcr_signed_"
+  [(set (match_operand:GPR 0 "gpc_reg_operand" "=r")
+   (neg:GPR (match_operator:GPR 1 "scc_rev_comparison_operator"
+   [(match_operand:CCEITHER 2 "cc_reg_operand" "y")
+(const_int 0)])))]
+  "TARGET_FUTURE"
+  "setnbcr %0,%j1"
+  [(set_attr "type" "isel")])
+
 ;; Floating point conditional move
 (define_expand "movcc"
[(set (match_operand:SFDF 0 "gpc_reg_operand")
@@ -12062,9 +12081,9 @@ (define_insn_and_split "*neg_eq_"
(clobber (match_scratch:P 3 "=r"))
(clobber (match_scratch:P 4 "=r"))
(clobber (reg:P CA_REGNO))]
-  ""
+  "!TARGET_FUTURE"
   "#"
-  ""
+  "&& 1"
   [(parallel [(set (match_dup 4)
   (plus:P (match_dup 3)
   (const_int -1)))
@@ -12094,9 +12113,9 @@ (define_insn_and_split "*neg_ne_"
(clobber (match_scratch:P 3 "=r"))
(clobber (match_scratch:P 4 "=r"))
(clobber (reg:P CA_REGNO))]
-  ""
+  "!TARGET_FUTURE"
   "#"
-  ""
+  "&& 1"
   [(parallel [(set (match_dup 4)
   (neg:P (match_dup 3)))
  (set (reg:P CA_REGNO)
-- 
2.17.1



Re: [PATCH] testsuite:analyzer: Fix header include for FreeBSD

2020-05-06 Thread Kamil Rytarowski
On 06.05.2020 22:25, Andreas Tobler wrote:
> On 06.05.20 22:12, Jakub Jelinek wrote:
>> On Wed, May 06, 2020 at 09:54:47PM +0200, Andreas Tobler wrote:
>>> --- a/gcc/testsuite/gcc.dg/analyzer/alloca-leak.c
>>> +++ b/gcc/testsuite/gcc.dg/analyzer/alloca-leak.c
>>> @@ -1,5 +1,6 @@
>>> -#include 
>>> -
>>> +#include 
>>
>> It needs to be:
>>> +#if __has_include()
>>
>> +#include 
>>
>>> +#endif
> 
> Doh :(
> 
> Fixed, thanks.
> 
>> __has_include doesn't include anything, just checks if the header is
>> available.
> 
> Then I just wonder why the tests passed on Linux (ubuntu-20.04)
> 

alloca.h is only needed on solaris. Other system can use stdlib.h.

> Andreas




signature.asc
Description: OpenPGP digital signature


Re: [PATCH] testsuite:analyzer: Fix header include for FreeBSD

2020-05-06 Thread Andreas Tobler

On 06.05.20 22:12, Jakub Jelinek wrote:

On Wed, May 06, 2020 at 09:54:47PM +0200, Andreas Tobler wrote:

--- a/gcc/testsuite/gcc.dg/analyzer/alloca-leak.c
+++ b/gcc/testsuite/gcc.dg/analyzer/alloca-leak.c
@@ -1,5 +1,6 @@
-#include 
-
+#include 


It needs to be:

+#if __has_include()


+#include 


+#endif


Doh :(

Fixed, thanks.


__has_include doesn't include anything, just checks if the header is
available.


Then I just wonder why the tests passed on Linux (ubuntu-20.04)

Andreas


[PATCH] libgcc: aarch64: Get hwcap for FreeBSD

2020-05-06 Thread Andreas Tobler

Hi all,

Since FreeBSD 12, FreeBSD has a sys/auxv.h header too but it doesn't
provide the getauxval function. Instead it offers the elf_aux_info
function which provides a similar functionality.
This patch gets the hwcap for FreeBSD.

Is this ok for trunk?

TIA,
Andreas

+2020-05-05  Andreas Tobler  
+
+   * config/aarch64/lse-init.c: Get hwcap for FreeBSD.
+

diff --git a/libgcc/config/aarch64/lse-init.c 
b/libgcc/config/aarch64/lse-init.c

index 00e9ab8cd1c..ab0d6b2f754 100644
--- a/libgcc/config/aarch64/lse-init.c
+++ b/libgcc/config/aarch64/lse-init.c
@@ -41,7 +41,16 @@ unsigned long int __getauxval (unsigned long int);
 static void __attribute__((constructor))
 init_have_lse_atomics (void)
 {
+#ifndef __FreeBSD__
   unsigned long hwcap = __getauxval (AT_HWCAP);
+#else
+  unsigned long hwcap;
+  int err;
+
+  err = elf_aux_info(AT_HWCAP, , sizeof(hwcap));
+  if (err)
+hwcap = 0;
+#endif
   __aarch64_have_lse_atomics = (hwcap & HWCAP_ATOMICS) != 0;
 }



Re: [PATCH] testsuite:analyzer: Fix header include for FreeBSD

2020-05-06 Thread Jakub Jelinek via Gcc-patches
On Wed, May 06, 2020 at 09:54:47PM +0200, Andreas Tobler wrote:
> --- a/gcc/testsuite/gcc.dg/analyzer/alloca-leak.c
> +++ b/gcc/testsuite/gcc.dg/analyzer/alloca-leak.c
> @@ -1,5 +1,6 @@
> -#include 
> -
> +#include 

It needs to be:
> +#if __has_include()

+#include 

> +#endif

__has_include doesn't include anything, just checks if the header is
available.

Jakub



Re: [PATCH] testsuite:analyzer: Fix header include for FreeBSD

2020-05-06 Thread Andreas Tobler

On 04.05.20 12:10, Kamil Rytarowski wrote:

On 04.05.2020 12:04, Jakub Jelinek wrote:

On Mon, May 04, 2020 at 11:49:27AM +0200, Kamil Rytarowski wrote:

Please include in your patch "|| defined(__NetBSD__)".


is this ok for you?

This is one reason why I'd prefer #define alloca __builtin_alloca and
leave the include away.

Andreas


It looks fine to me now.

Personally, I would include stdlib.h unconditionally and alloca.h on
!FreeBSD && !NetBSD.


It just just a test.
Perhaps it could
#include 
#if __has_include()
#include 
#endif
?

Jakub



This looks fine too.



K, fine with me. I'll commit this solution once I finished testing. Thanks,
Andreas

+2020-05-07  Andreas Tobler  
+
+   * gcc.dg/analyzer/alloca-leak.c: Include alloca.h only if
+ available.
+   * gcc.dg/analyzer/data-model-1.c: Likewise
+   * gcc.dg/analyzer/malloc-1.c: Likewise.
+   * gcc.dg/analyzer/malloc-paths-8.c: Likewise.

diff --git a/gcc/testsuite/gcc.dg/analyzer/alloca-leak.c 
b/gcc/testsuite/gcc.dg/analyzer/alloca-leak.c

index 6d9fe3431ce..e4717a1bbb3 100644
--- a/gcc/testsuite/gcc.dg/analyzer/alloca-leak.c
+++ b/gcc/testsuite/gcc.dg/analyzer/alloca-leak.c
@@ -1,5 +1,6 @@
-#include 
-
+#include 
+#if __has_include()
+#endif
 void *test (void)
 {
   void *ptr = alloca (64);
diff --git a/gcc/testsuite/gcc.dg/analyzer/data-model-1.c 
b/gcc/testsuite/gcc.dg/analyzer/data-model-1.c

index 1db99133d50..32559952e34 100644
--- a/gcc/testsuite/gcc.dg/analyzer/data-model-1.c
+++ b/gcc/testsuite/gcc.dg/analyzer/data-model-1.c
@@ -1,7 +1,8 @@
 #include 
 #include 
 #include 
-#include 
+#if __has_include()
+#endif
 #include "analyzer-decls.h"

 struct foo
diff --git a/gcc/testsuite/gcc.dg/analyzer/malloc-1.c 
b/gcc/testsuite/gcc.dg/analyzer/malloc-1.c

index 3024e546137..0f3f1fc760a 100644
--- a/gcc/testsuite/gcc.dg/analyzer/malloc-1.c
+++ b/gcc/testsuite/gcc.dg/analyzer/malloc-1.c
@@ -1,4 +1,5 @@
-#include 
+#if __has_include()
+#endif
 #include 

 extern int foo (void);
diff --git a/gcc/testsuite/gcc.dg/analyzer/malloc-paths-8.c 
b/gcc/testsuite/gcc.dg/analyzer/malloc-paths-8.c

index 10b97a05402..35035d27ff7 100644
--- a/gcc/testsuite/gcc.dg/analyzer/malloc-paths-8.c
+++ b/gcc/testsuite/gcc.dg/analyzer/malloc-paths-8.c
@@ -1,7 +1,8 @@
 /* { dg-additional-options "-fanalyzer-transitivity" } */

 #include 
-#include 
+#if __has_include()
+#endif
 #include 

 extern void do_stuff (const void *);


Re: [PATCH] coroutines: Improve error recovery [PR94817, PR94829].

2020-05-06 Thread Nathan Sidwell

On 4/29/20 6:50 AM, Iain Sandoe wrote:

Hi,

When we have completely missing key information (e.g. the
coroutine_traits) or a partially transformed function body, we
need to try and balance returning useful information about
failures with the possibility that some part of the diagnostics
machinery or following code will not be able to handle the
state.

The PRs (and revised testcase) point to cases where that processing
has failed.

This revises the process to avoid special handling for the
ramp, and falls back on the same code used for regular function
fails.

There are test-cases (in addition to the ones for the PRs) that now
cover all early exit points [where the transforms are considered
to have failed in a manner that does not allow compilation to
continue].

tested on x86_64-darwin
OK for master after testing on x86-64-linux?
thanks
Iain

gcc/cp/ChangeLog:

2020-04-29  Iain Sandoe  

PR c++/94817
PR c++/94829
* coroutines.cc (morph_fn_to_coro): Set unformed outline
functions to error_mark_node.  For early error returns suppress
warnings about missing ramp return values.  Fix reinstatement
of the function body on pre-existing initial error.
* decl.c (finish_function): Use the normal error path for fails
in the ramp function, do not try to compile the helpers if the
transform fails.



ok


--
Nathan Sidwell


Re: [PATCH] Improve std::fill for vector

2020-05-06 Thread Jonathan Wakely via Gcc-patches

On 06/05/20 20:46 +0200, François Dumont via Libstdc++ wrote:

Hi

I am not clear about current stage so I am proposing this trivial 
patch to find out if we are back in stage 1.


The current status is always shown on the front page of gcc.gnu.org
(although currently the link to the GCC 11 status is broken, because
the list archives got renumbered for some reason, it should be
https://gcc.gnu.org/pipermail/gcc/2020-April/000505.html for GCC 11).

This patch extend the overload so that it is used even when 
_GLIBCXX_DEBUG mode is activated.


    * include/bits/stl_algobase.h (struct _Bit_iterator): New 
declaration.
    (std::__fill_a1(_Bit_iterator, _Bit_iterator, const 
bool&)): Likewise.

    * include/bits/stl_bvector.h (__fill_bvector): Move outside
    _GLIBCXX_STD_C namespace.
    (fill(_Bit_iterator, _Bit_iterator, const bool&)): 
Likewise and rename

    into...
    (__fill_a1): ...this.
    * testsuite/25_algorithms/fill/bvector/1.cc: New.

Tested under Linux x86_64 normal and debug modes.

Ok to commit ?


OK, thanks.



Re: [PATCH] libstdc++: Update Solaris baselines for GCC 9.4

2020-05-06 Thread Jonathan Wakely via Gcc-patches

On 06/05/20 20:33 +0200, Rainer Orth wrote:

Hi Jonathan,


On 06/05/20 14:12 +0200, Rainer Orth wrote:

Hi Jonathan,


On 06/05/20 10:49 +0200, Rainer Orth wrote:

I just remembered that the libstdc++ ABI baselines haven't been updated
for the GCC 10 release yet.  This patch corrects this for Solaris/SPARC
and x86.


I think we also need to update them on the gcc-9 branch, all the
3.4.28 symbols are on that branch too (added in 9.3.0).


indeed.  I hadn't even thought to look there.  Will post a patch once
testing has finished.


Thanks! Obviously less urgent than gcc-10.


true.  However, the necessary machines were idle, so here's what passed
testing on i386-pc-solaris2.1[01] and sparc-sun-solaris2.1[01].

Ok for the gcc-9 branch?


Yes, thanks.




[pushed] coroutines: Remove references to n4849 (NFC).

2020-05-06 Thread Iain Sandoe
Hi,

Another minor cleanup.

This just strips out references to the draft standard numbered n4849. 
The implementation is now intended to be applicable to the expected
final version.

tested on x86_64-darwin16,
applied to master as obvious
thanks
Iain

gcc/cp/ChangeLog:

2020-05-05  Iain Sandoe  

* coroutines.cc: Remove references to n4849 throughout.
---
 gcc/cp/ChangeLog |  4 
 gcc/cp/coroutines.cc | 28 ++--
 2 files changed, 18 insertions(+), 14 deletions(-)

diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
index ed871e1bab1..fc319a58cc2 100644
--- a/gcc/cp/coroutines.cc
+++ b/gcc/cp/coroutines.cc
@@ -2184,11 +2184,11 @@ build_actor_fn (location_t loc, tree coro_frame_type, 
tree actor, tree fnbody,
   /* Expand co_returns in the saved function body  */
   fnbody = expand_co_returns (, promise_proxy, ap, fs_label);
 
-  /* n4849 adds specific behaviour to treat exceptions thrown by the
- await_resume () of the initial suspend expression.  In order to
- implement this, we need to treat the initial_suspend expression
- as if it were part of the user-authored function body.  This
- only applies if exceptions are enabled.  */
+  /* Specific behaviour to treat exceptions thrown by the await_resume ()
+ of the initial suspend expression.  In order to implement this, we
+ need to treat the initial_suspend expression as if it were part of the
+ user-authored function body.  This only applies if exceptions are
+ enabled.  */
   if (flag_exceptions)
 {
   tree outer = fnbody;
@@ -2290,7 +2290,7 @@ build_actor_fn (location_t loc, tree coro_frame_type, 
tree actor, tree fnbody,
}
 }
 
-  /* n4849 [dcl.fct.def.coroutine] / 12
+  /* [dcl.fct.def.coroutine] / 12
  The deallocation function’s name is looked up in the scope of the promise
  type.  If this lookup fails, the deallocation function’s name is looked up
  in the global scope.  If deallocation function lookup finds both a usual
@@ -3845,7 +3845,7 @@ morph_fn_to_coro (tree orig, tree *resumer, tree 
*destroyer)
 = build_call_expr_internal_loc (fn_start, IFN_CO_FRAME, size_type_node, 2,
frame_size, coro_fp);
 
-  /* n4849 [dcl.fct.def.coroutine] / 10 (part1)
+  /* [dcl.fct.def.coroutine] / 10 (part1)
 The unqualified-id get_return_object_on_allocation_failure is looked up
 in the scope of the promise type by class member access lookup.  */
 
@@ -3871,7 +3871,7 @@ morph_fn_to_coro (tree orig, tree *resumer, tree 
*destroyer)
 }
 
   /* Allocate the frame, this has several possibilities:
- n4849 [dcl.fct.def.coroutine] / 9 (part 1)
+ [dcl.fct.def.coroutine] / 9 (part 1)
  The allocation function’s name is looked up in the scope of the promise
  type.  It's not a failure for it to be absent see part 4, below.  */
   tree nwname = ovl_op_identifier (false, NEW_EXPR);
@@ -3880,7 +3880,7 @@ morph_fn_to_coro (tree orig, tree *resumer, tree 
*destroyer)
   tree new_fn = NULL_TREE;
   if (fns && BASELINK_P (fns))
 {
-  /* n4849 [dcl.fct.def.coroutine] / 9 (part 2)
+  /* [dcl.fct.def.coroutine] / 9 (part 2)
If the lookup finds an allocation function in the scope of the promise
type, overload resolution is performed on a function call created by
assembling an argument list.  The first argument is the amount of space
@@ -3920,7 +3920,7 @@ morph_fn_to_coro (tree orig, tree *resumer, tree 
*destroyer)
 
   if (!new_fn || new_fn == error_mark_node)
{
- /* n4849 [dcl.fct.def.coroutine] / 9 (part 3)
+ /* [dcl.fct.def.coroutine] / 9 (part 3)
If no viable function is found, overload resolution is performed
again on a function call created by passing just the amount of
space required as an argument of type std::size_t.  */
@@ -3946,7 +3946,7 @@ morph_fn_to_coro (tree orig, tree *resumer, tree 
*destroyer)
 }
   else
 {
-  /* n4849 [dcl.fct.def.coroutine] / 9 (part 4)
+  /* [dcl.fct.def.coroutine] / 9 (part 4)
 If this lookup fails, the allocation function’s name is looked up in
 the global scope.  */
 
@@ -3957,7 +3957,7 @@ morph_fn_to_coro (tree orig, tree *resumer, tree 
*destroyer)
 
   if (grooaf)
{
- /* n4849 [dcl.fct.def.coroutine] / 10 (part 2)
+ /* [dcl.fct.def.coroutine] / 10 (part 2)
   If any declarations (of the get return on allocation fail) are
   found, then the result of a call to an allocation function used
   to obtain storage for the coroutine state is assumed to return
@@ -3998,7 +3998,7 @@ morph_fn_to_coro (tree orig, tree *resumer, tree 
*destroyer)
 
   if (grooaf)
 {
-  /* n4849 [dcl.fct.def.coroutine] / 10 (part 3)
+  /* [dcl.fct.def.coroutine] / 10 (part 3)
 If the allocation function returns nullptr,the coroutine returns
 control to the caller of the coroutine and the 

Re: PING[STAGE 1][PATCH][x86][1/3]: Add -mzero-caller-saved-regs=[skip|used-gpr|all-gpr|used|all]

2020-05-06 Thread Qing Zhao via Gcc-patches
Hi, Kees,


> On May 4, 2020, at 1:21 PM, Kees Cook  wrote:
> 
> On Mon, May 04, 2020 at 11:51:49AM -0500, Qing Zhao wrote:
>> Hi,
>> 
>> This is a PING for this patch for gcc11 stage 1. 
>> 
>> https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544058.html 
>> 
>> 
>> Please take a look on it.
> 
> Hi!
> 
> I think the best course of action here would be the rebase these patches
> and resend them against the current GCC code base as inline patches
> (not attachments as you sent earlier),

Actually, the patches sent on April 17, 2020 were the rebased patches against 
the current GCC code. 

In addition to this patch, there are two more patches that fix the new 
regressions exposed by this patch on the current GCC code base. (Those two 
patches have been
sent for review with this one at the same time as):
https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544056.html 

https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544057.html 



thanks.

Qing
> following the details here:
> https://gcc.gnu.org/contribute.html
> 
>>> https://outflux.net/slides/2019/lpc/gcc-and-clang.pdf 
>>> 
>>> Tested on  x86-64 with bootstrapping GCC trunk, regression tests exposed 
>>> several new regressions, these new regressions are
>>> fixed by 2 following patches I will send in next two emails.
> 
> I look forward to seeing these! I'd really like to have the feature
> available as another defense in depth for the Linux kernel.
> 
> -Kees
> 
> -- 
> Kees Cook



[PATCH] Improve std::fill for vector

2020-05-06 Thread François Dumont via Gcc-patches

Hi

I am not clear about current stage so I am proposing this trivial patch 
to find out if we are back in stage 1.


This patch extend the overload so that it is used even when 
_GLIBCXX_DEBUG mode is activated.


    * include/bits/stl_algobase.h (struct _Bit_iterator): New 
declaration.
    (std::__fill_a1(_Bit_iterator, _Bit_iterator, const 
bool&)): Likewise.

    * include/bits/stl_bvector.h (__fill_bvector): Move outside
    _GLIBCXX_STD_C namespace.
    (fill(_Bit_iterator, _Bit_iterator, const bool&)): Likewise 
and rename

    into...
    (__fill_a1): ...this.
    * testsuite/25_algorithms/fill/bvector/1.cc: New.

Tested under Linux x86_64 normal and debug modes.

Ok to commit ?

François

diff --git a/libstdc++-v3/include/bits/stl_algobase.h b/libstdc++-v3/include/bits/stl_algobase.h
index aca70bc1239..133507483a6 100644
--- a/libstdc++-v3/include/bits/stl_algobase.h
+++ b/libstdc++-v3/include/bits/stl_algobase.h
@@ -438,6 +438,8 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
   template
 struct _Deque_iterator;
 
+  struct _Bit_iterator;
+
 _GLIBCXX_END_NAMESPACE_CONTAINER
 
   // Helpers for streambuf iterators (either istream or ostream).
@@ -957,6 +959,10 @@ _GLIBCXX_END_NAMESPACE_CONTAINER
 	  const _GLIBCXX_STD_C::_Deque_iterator<_Tp, _Tp&, _Tp*>&,
 	  const _VTp&);
 
+  void
+  __fill_a1(_GLIBCXX_STD_C::_Bit_iterator, _GLIBCXX_STD_C::_Bit_iterator,
+	const bool&);
+
   template
 _GLIBCXX20_CONSTEXPR
 inline void
diff --git a/libstdc++-v3/include/bits/stl_bvector.h b/libstdc++-v3/include/bits/stl_bvector.h
index f245e52b25d..a365e7182eb 100644
--- a/libstdc++-v3/include/bits/stl_bvector.h
+++ b/libstdc++-v3/include/bits/stl_bvector.h
@@ -416,39 +416,6 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
 { return __x + __n; }
   };
 
-  inline void
-  __fill_bvector(_Bit_type * __v,
-		 unsigned int __first, unsigned int __last, bool __x)
-  {
-const _Bit_type __fmask = ~0ul << __first;
-const _Bit_type __lmask = ~0ul >> (_S_word_bit - __last);
-const _Bit_type __mask = __fmask & __lmask;
-
-if (__x)
-  *__v |= __mask;
-else
-  *__v &= ~__mask;
-  }
-
-  inline void
-  fill(_Bit_iterator __first, _Bit_iterator __last, const bool& __x)
-  {
-if (__first._M_p != __last._M_p)
-  {
-	_Bit_type* __first_p = __first._M_p;
-	if (__first._M_offset != 0)
-	  __fill_bvector(__first_p++, __first._M_offset, _S_word_bit, __x);
-
-	__builtin_memset(__first_p, __x ? ~0 : 0,
-			 (__last._M_p - __first_p) * sizeof(_Bit_type));
-
-	if (__last._M_offset != 0)
-	  __fill_bvector(__last._M_p, 0, __last._M_offset, __x);
-  }
-else if (__first._M_offset != __last._M_offset)
-  __fill_bvector(__first._M_p, __first._M_offset, __last._M_offset, __x);
-  }
-
   template
 struct _Bvector_base
 {
@@ -1336,15 +1303,46 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
   };
 
 _GLIBCXX_END_NAMESPACE_CONTAINER
-_GLIBCXX_END_NAMESPACE_VERSION
-} // namespace std
 
-#if __cplusplus >= 201103L
+  inline void
+  __fill_bvector(_GLIBCXX_STD_C::_Bit_type * __v,
+		 unsigned int __first, unsigned int __last, bool __x)
+  {
+using _GLIBCXX_STD_C::_Bit_type;
+using _GLIBCXX_STD_C::_S_word_bit;
+const _Bit_type __fmask = ~0ul << __first;
+const _Bit_type __lmask = ~0ul >> (_S_word_bit - __last);
+const _Bit_type __mask = __fmask & __lmask;
 
-namespace std _GLIBCXX_VISIBILITY(default)
-{
-_GLIBCXX_BEGIN_NAMESPACE_VERSION
+if (__x)
+  *__v |= __mask;
+else
+  *__v &= ~__mask;
+  }
 
+  inline void
+  __fill_a1(_GLIBCXX_STD_C::_Bit_iterator __first,
+	_GLIBCXX_STD_C::_Bit_iterator __last, const bool& __x)
+  {
+using _GLIBCXX_STD_C::_Bit_type;
+using _GLIBCXX_STD_C::_S_word_bit;
+if (__first._M_p != __last._M_p)
+  {
+	_Bit_type* __first_p = __first._M_p;
+	if (__first._M_offset != 0)
+	  __fill_bvector(__first_p++, __first._M_offset, _S_word_bit, __x);
+
+	__builtin_memset(__first_p, __x ? ~0 : 0,
+			 (__last._M_p - __first_p) * sizeof(_Bit_type));
+
+	if (__last._M_offset != 0)
+	  __fill_bvector(__last._M_p, 0, __last._M_offset, __x);
+  }
+else if (__first._M_offset != __last._M_offset)
+  __fill_bvector(__first._M_p, __first._M_offset, __last._M_offset, __x);
+  }
+
+#if __cplusplus >= 201103L
   // DR 1182.
   /// std::hash specialization for vector.
   template
@@ -1354,10 +1352,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   size_t
   operator()(const _GLIBCXX_STD_C::vector&) const noexcept;
 };
+#endif // C++11
 
 _GLIBCXX_END_NAMESPACE_VERSION
-}// namespace std
-
-#endif // C++11
+} // namespace std
 
 #endif
diff --git a/libstdc++-v3/testsuite/25_algorithms/fill/bvector/1.cc b/libstdc++-v3/testsuite/25_algorithms/fill/bvector/1.cc
new file mode 100644
index 000..22e4fca73b8
--- /dev/null
+++ b/libstdc++-v3/testsuite/25_algorithms/fill/bvector/1.cc
@@ -0,0 +1,39 @@
+// Copyright (C) 2020 Free Software Foundation, Inc.
+//
+// 

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

2020-05-06 Thread Qing Zhao via Gcc-patches
FYI.

> On Apr 23, 2020, at 5:13 PM, David Malcolm  wrote:
> 
> May need updating to match the hint message.
> 
> [...]
> 
> This is OK for stage 1 with those nits fixed.

I committed the updated patch with all the suggestions today to gcc11 stage1 as:

https://gcc.gnu.org/g:530b44094354758d0dea5374188caa6863647114 


Thanks.

Qing

> 
> There was talk earlier in the thread about fixing this in GCC 10.
> 
> Richi/Jakub: is this OK for stage 4?   Although it adds a new command-
> line option, it's a workaround for a regression introduced in GCC 6 and
> should be low risk.
> 
> Thanks
> Dave
> 



[PATCH] libstdc++: Update Solaris baselines for GCC 9.4

2020-05-06 Thread Rainer Orth
Hi Jonathan,

> On 06/05/20 14:12 +0200, Rainer Orth wrote:
>>Hi Jonathan,
>>
>>> On 06/05/20 10:49 +0200, Rainer Orth wrote:
I just remembered that the libstdc++ ABI baselines haven't been updated
for the GCC 10 release yet.  This patch corrects this for Solaris/SPARC
and x86.
>>>
>>> I think we also need to update them on the gcc-9 branch, all the
>>> 3.4.28 symbols are on that branch too (added in 9.3.0).
>>
>>indeed.  I hadn't even thought to look there.  Will post a patch once
>>testing has finished.
>
> Thanks! Obviously less urgent than gcc-10.

true.  However, the necessary machines were idle, so here's what passed
testing on i386-pc-solaris2.1[01] and sparc-sun-solaris2.1[01].

Ok for the gcc-9 branch?

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University


2020-05-06  Rainer Orth  

* config/abi/post/i386-solaris2.10/baseline_symbols.txt: Regenerate.
* config/abi/post/i386-solaris2.10/amd64/baseline_symbols.txt:
Likewise.
* config/abi/post/i386-solaris2.11/baseline_symbols.txt: Likewise.
* config/abi/post/i386-solaris2.11/amd64/baseline_symbols.txt:
Likewise.
* config/abi/post/sparc-solaris2.10/baseline_symbols.txt: Likewise.
* config/abi/post/sparc-solaris2.10/sparcv9/baseline_symbols.txt:
Likewise.
* config/abi/post/sparc-solaris2.11/baseline_symbols.txt: Likewise.
* config/abi/post/sparc-solaris2.11/sparcv9/baseline_symbols.txt:
Likewise.

# HG changeset patch
# Parent  dcef1b5ccb13b73eb86aa0860b4e657d3079c5be
libstdc++: Update Solaris baselines for GCC 9.4

diff --git a/libstdc++-v3/config/abi/post/i386-solaris2.10/amd64/baseline_symbols.txt b/libstdc++-v3/config/abi/post/i386-solaris2.10/amd64/baseline_symbols.txt
--- a/libstdc++-v3/config/abi/post/i386-solaris2.10/amd64/baseline_symbols.txt
+++ b/libstdc++-v3/config/abi/post/i386-solaris2.10/amd64/baseline_symbols.txt
@@ -2968,12 +2968,18 @@ FUNC:_ZNSt3_V214error_categoryD1Ev@@GLIB
 FUNC:_ZNSt3_V214error_categoryD2Ev@@GLIBCXX_3.4.21
 FUNC:_ZNSt3_V215system_categoryEv@@GLIBCXX_3.4.21
 FUNC:_ZNSt3_V216generic_categoryEv@@GLIBCXX_3.4.21
+FUNC:_ZNSt3pmr15memory_resourceD0Ev@@GLIBCXX_3.4.28
+FUNC:_ZNSt3pmr15memory_resourceD1Ev@@GLIBCXX_3.4.28
+FUNC:_ZNSt3pmr15memory_resourceD2Ev@@GLIBCXX_3.4.28
 FUNC:_ZNSt3pmr19new_delete_resourceEv@@GLIBCXX_3.4.26
 FUNC:_ZNSt3pmr20get_default_resourceEv@@GLIBCXX_3.4.26
 FUNC:_ZNSt3pmr20null_memory_resourceEv@@GLIBCXX_3.4.26
 FUNC:_ZNSt3pmr20set_default_resourceEPNS_15memory_resourceE@@GLIBCXX_3.4.26
 FUNC:_ZNSt3pmr25monotonic_buffer_resource13_M_new_bufferEmm@@GLIBCXX_3.4.26
 FUNC:_ZNSt3pmr25monotonic_buffer_resource18_M_release_buffersEv@@GLIBCXX_3.4.26
+FUNC:_ZNSt3pmr25monotonic_buffer_resourceD0Ev@@GLIBCXX_3.4.28
+FUNC:_ZNSt3pmr25monotonic_buffer_resourceD1Ev@@GLIBCXX_3.4.28
+FUNC:_ZNSt3pmr25monotonic_buffer_resourceD2Ev@@GLIBCXX_3.4.28
 FUNC:_ZNSt3pmr26synchronized_pool_resource11do_allocateEmm@@GLIBCXX_3.4.26
 FUNC:_ZNSt3pmr26synchronized_pool_resource13do_deallocateEPvmm@@GLIBCXX_3.4.26
 FUNC:_ZNSt3pmr26synchronized_pool_resource7releaseEv@@GLIBCXX_3.4.26
@@ -4457,6 +4463,7 @@ OBJECT:16:_ZTIN10__cxxabiv119__foreign_e
 OBJECT:16:_ZTINSt13__future_base11_State_baseE@@GLIBCXX_3.4.15
 OBJECT:16:_ZTINSt13__future_base12_Result_baseE@@GLIBCXX_3.4.15
 OBJECT:16:_ZTINSt3_V214error_categoryE@@GLIBCXX_3.4.21
+OBJECT:16:_ZTINSt3pmr15memory_resourceE@@GLIBCXX_3.4.28
 OBJECT:16:_ZTINSt6locale5facetE@@GLIBCXX_3.4
 OBJECT:16:_ZTINSt6thread6_StateE@@GLIBCXX_3.4.22
 OBJECT:16:_ZTISt10ctype_base@@GLIBCXX_3.4
@@ -4884,6 +4891,7 @@ OBJECT:24:_ZTIN9__gnu_cxx18stdio_sync_fi
 OBJECT:24:_ZTINSt10filesystem16filesystem_errorE@@GLIBCXX_3.4.26
 OBJECT:24:_ZTINSt10filesystem7__cxx1116filesystem_errorE@@GLIBCXX_3.4.26
 OBJECT:24:_ZTINSt13__future_base19_Async_state_commonE@@GLIBCXX_3.4.17
+OBJECT:24:_ZTINSt3pmr25monotonic_buffer_resourceE@@GLIBCXX_3.4.28
 OBJECT:24:_ZTINSt3pmr26synchronized_pool_resourceE@@GLIBCXX_3.4.26
 OBJECT:24:_ZTINSt3pmr28unsynchronized_pool_resourceE@@GLIBCXX_3.4.26
 OBJECT:24:_ZTINSt7__cxx1114collate_bynameIcEE@@GLIBCXX_3.4.21
@@ -5016,6 +5024,7 @@ OBJECT:25:_ZTSNSt7__cxx118messagesIwEE@@
 OBJECT:25:_ZTSNSt7__cxx118numpunctIcEE@@GLIBCXX_3.4.21
 OBJECT:25:_ZTSNSt7__cxx118numpunctIwEE@@GLIBCXX_3.4.21
 OBJECT:25:_ZTSSt20bad_array_new_length@@CXXABI_1.3.8
+OBJECT:26:_ZTSNSt3pmr15memory_resourceE@@GLIBCXX_3.4.28
 OBJECT:272:_ZSt4cerr@@GLIBCXX_3.4
 OBJECT:272:_ZSt4clog@@GLIBCXX_3.4
 OBJECT:272:_ZSt4cout@@GLIBCXX_3.4
@@ -5160,6 +5169,7 @@ OBJECT:34:_ZTSSt25__codecvt_utf8_utf16_b
 OBJECT:34:_ZTSSt9basic_iosIcSt11char_traitsIcEE@@GLIBCXX_3.4
 OBJECT:34:_ZTSSt9basic_iosIwSt11char_traitsIwEE@@GLIBCXX_3.4
 OBJECT:36:_ZTSN10__cxxabiv119__pointer_type_infoE@@CXXABI_1.3
+OBJECT:36:_ZTSNSt3pmr25monotonic_buffer_resourceE@@GLIBCXX_3.4.28
 OBJECT:36:_ZTSSt14codecvt_bynameIcc11__mbstate_tE@@GLIBCXX_3.4
 

Re: [PR C++/94946] ambiguous overload regression

2020-05-06 Thread Marek Polacek via Gcc-patches
On Wed, May 06, 2020 at 02:14:03PM -0400, Nathan Sidwell wrote:
> @@ -0,0 +1,7 @@
> +// { dg-do compile { target { i?86-*-* x86_64-*-* } } }
> +// { dg-options -m32 }
> +// PR 94946
> +class a {
> +  template  a(b (*)());
> +  template  a(b(__attribute__((fastcall)) *c)());
> +};

I think instead of dg-options -m32 we are supposed to use:

// { dg-do compile { target { { i?86-*-* x86_64-*-* } && ia32 } } }



[PR C++/94946] ambiguous overload regression

2020-05-06 Thread Nathan Sidwell
This appears to fix 94946 -- regular testsuite passes, bootstrapping 
now.  I'll commit if the bootstrap is good.


Jakub, ok for gcc-10 too?

nathan

--
Nathan Sidwell
2020-05-06  Nathan Sidwell  

	PR c++/94946
	* decl.c (grokdeclarator): Don't splice template attributes in
	parm context -- they can apply to the parm.

diff --git c/gcc/cp/decl.c w/gcc/cp/decl.c
index 3e7ed98fed3..232d7ed4a14 100644
--- c/gcc/cp/decl.c
+++ w/gcc/cp/decl.c
@@ -11940,9 +11940,12 @@ grokdeclarator (const cp_declarator *declarator,
 	attr_flags |= (int) ATTR_FLAG_FUNCTION_NEXT;
 	  if (declarator->kind == cdk_array)
 	attr_flags |= (int) ATTR_FLAG_ARRAY_NEXT;
-	  /* Assume that any attributes that get applied late to templates will
-	 DTRT when applied to the declaration as a whole.  */
-	  tree late_attrs = splice_template_attributes (, type);
+	  tree late_attrs = NULL_TREE;
+	  if (decl_context != PARM)
+	/* Assume that any attributes that get applied late to
+	   templates will DTRT when applied to the declaration
+	   as a whole.  */
+	late_attrs = splice_template_attributes (, type);
 	  returned_attrs = decl_attributes (,
 	chainon (returned_attrs, attrs),
 	attr_flags);
diff --git c/gcc/testsuite/g++.dg/ext/attr-parm-1.C w/gcc/testsuite/g++.dg/ext/attr-parm-1.C
new file mode 100644
index 000..37214e63c01
--- /dev/null
+++ w/gcc/testsuite/g++.dg/ext/attr-parm-1.C
@@ -0,0 +1,7 @@
+// { dg-do compile { target { i?86-*-* x86_64-*-* } } }
+// { dg-options -m32 }
+// PR 94946
+class a {
+  template  a(b (*)());
+  template  a(b(__attribute__((fastcall)) *c)());
+};


Re: [PATCH] PowerPC -mcpu=future Patch 3 of 7, Add test for generating prefixed load/store

2020-05-06 Thread Segher Boessenkool
Hi!

On Tue, May 05, 2020 at 08:41:35PM -0400, Hans-Peter Nilsson wrote:
> On Fri, 1 May 2020, Segher Boessenkool wrote:
> > On Mon, Apr 27, 2020 at 05:01:34PM -0500, will schmidt wrote:
> > > On Mon, 2020-04-27 at 15:53 -0400, Michael Meissner via Gcc-patches wrote:
> > > > +unsigned long
> > > > +load_us_offset1 (unsigned char *p)
> > > > +{
> > > > +  return *(unsigned short *)(p + 1);   /* should generate LHZ.  */
> > > > +}
> >
> > This violates aliasing rules (without -fno-strict-aliasing), unless p
> > points to some "short" object -- in which case it has alignment 2
> > already!
> 
> Ackchyually... that'd be 'unless p+1 points to some "short" object'.

Erm yes.

> You're allowed to do weird things passing char pointers around
> (at least), as long as you point to the right-type object (the
> one used when it was assigned) when you dereference it.

And when you cast it to the "bigger" pointer type, already, in general.
Which isn't a problem for any of the powerpc targets at least, not sure
there is any GCC target where it matters currently?

> Though, I don't know if the same goes if p was something other
> than a "char *" or "unsigned char *".

Sure, it is true always: you can do whatever you want with the address,
cast it (validly) to other pointer types, to integer types, slice it,
dice it, whatever you want; but when you dereference it, *that* is where
the "aliasing rules" apply.

> > So this testcase needs -fno-strict-aliasing, but also, you need to make
> > sure GCC does not assume alignment 2 (after the cast) already.  There
> > are attributes for this.
> 
> FWIW, if it needs -fno-strict-aliasing it's for some other
> reason than the above (we don't see the assigner in the test).

Not to be valid code, no.  But for the testcase to test what it wants
to test, it would help.

The point is that you can do a misaligned "lhz" instruction just fine;
you do not need a prefixed form for it, as with say "ld", where the
offset addressing form always does a multiple of four ("DS-form"), while
"pld" (its prefixed version) can take any integer offset ("D-form").  If
GCC already would assume the memory access is naturally aligned the test
doesn't test anything.

But together with it choosing the prefixed forms for ld and lwa etc.,
it's probably good enough anyway.


Segher


Re: [PATCH] lto-wrapper: split arguments of getenv ("MAKE").

2020-05-06 Thread Richard Biener via Gcc-patches
On Wed, May 6, 2020 at 3:09 PM Martin Liška  wrote:
>
> On 5/6/20 2:52 PM, Richard Biener wrote:
> > On Wed, May 6, 2020 at 2:08 PM Martin Liška  wrote:
> >>
> >> Hi.
> >>
> >> The patch splits arguments in getenv ("MAKE") so that one can use:
> >>
> >> $ MAKE="make -s" gcc main.o -flto=16
> >>
> >> Right now it fails due to:
> >> [pid  6004] execve("/home/marxin/Programming/script-misc/make -s", ["make 
> >> -s", "-f", "/tmp/ccNpRBlZ.mk", "-j16", "all"], 0x4b69b0 /* 82 vars */) = 
> >> -1 ENOENT (No such file or directory)
> >>
> >> I've tested the patch for lto.exp and now I'm doing a proper bootstrap.
> >> Ready after tests?
> >
> > + const char *make = getenv ("MAKE");
> > + unsigned argc = 0;
> > + struct obstack make_argv_obstack;
> > + obstack_init (_argv_obstack);
> > +
> > + if (make)
> > +   {
> > + argv = buildargv (make);
> >
> > you are overwriting the argv parameter here, I suggest to use a new
> > local variable here.
>
> Oh.
>
> >
> > buildargv can fail in which case it returns NULL so I suggest
> > to fall back to "make" in that case.
> >
> > + for (; argv[argc]; argc++)
> > +   obstack_ptr_grow (_argv_obstack, argv[argc]);
> >
> > argc is only used in this scope so declare it in the for() loop?
> >
> > btw, I suggest to simply re-use argv_obstack here.
>
> Done.
>
> >
> > + const char **argv = XOBFINISH (_argv_obstack, const char **);
> >
> > you are shadowing argv here, what's wrong with using new_argv?
>
> The shadowing in the function is really bad, it's a long function.
>
> >
> > +
> > + pex = collect_execute (argv[0], CONST_CAST (char **, argv),
> >   NULL, NULL, PEX_SEARCH, false);
> > - do_wait (new_argv[0], pex);
> > + do_wait (argv[0], pex);
> > + obstack_free (_argv_obstack, NULL);
> >
> > after pex is finished the argv allocated via buildargv should be freed
> > with freeargv
>
> Done.
>
> I hope it's better now?

Perfect if you checked freeargv is happy with a NULL argument!

OK.

Thanks,
Richard.

> Martin
>
> >
> > Richard.
> >
> > +   }
> >
> >
> >> Thanks,
> >> Martin
> >>
> >> gcc/ChangeLog:
> >>
> >> 2020-05-06  Martin Liska  
> >>
> >>  * lto-wrapper.c: Split arguments of MAKE environment
> >>  variable.
> >> ---
> >>gcc/lto-wrapper.c | 35 ---
> >>1 file changed, 24 insertions(+), 11 deletions(-)
> >>
> >>
>


Re: PING[STAGE 1][PATCH][x86][1/3]: Add -mzero-caller-saved-regs=[skip|used-gpr|all-gpr|used|all]

2020-05-06 Thread Martin Sebor via Gcc-patches

On 5/4/20 10:51 AM, Qing Zhao via Gcc-patches wrote:

Hi,

This is a PING for this patch for gcc11 stage 1.

https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544058.html 


Please take a look on it.


Just a couple of minor points:

I noticed a recurring mistake in the spelling of the verb "zeroes"
in the text added to the manual where the added documentation uses
"zeros:" the latter is the plural of the noun zero.  "zeroes" is
the third person of the verb to zero.

Another minor (and common) mistake is using the word "which" where
"that" would be appropriate.  In the sentence below (and others like
it):

  +... @samp{skip}, which is the default, doesn't zero
  +caller-saved registers.  @samp{used-gpr} zeros caller-saved integer
  +registers which are used in function.

the first which is correct (it just adds more detail about skip) but
the second should be "that" because it identifies the specific subset
of registers to which the description applies.

As a matter of style of diagnostics, attribute arguments should be
quoted.  In the hunk below:

@@ -40787,6 +41064,29 @@ ix86_handle_fndecl_attribute (tree *node, tree 
name, tree args, int,

}
 }

+  if (is_attribute_p ("zero_caller_saved_regs", name))
+{
+  tree cst = TREE_VALUE (args);
+  if (TREE_CODE (cst) != STRING_CST)
+   {
+ warning (OPT_Wattributes,
+  "%qE attribute requires a string constant argument",
+  name);
+ *no_add_attrs = true;
+   }
+  else if (strcmp (TREE_STRING_POINTER (cst), "skip") != 0
+  && strcmp (TREE_STRING_POINTER (cst), "used-gpr") != 0
+  && strcmp (TREE_STRING_POINTER (cst), "all-gpr") != 0
+  && strcmp (TREE_STRING_POINTER (cst), "used") != 0
+  && strcmp (TREE_STRING_POINTER (cst), "all") != 0)
+   {
+ warning (OPT_Wattributes,
+  "argument to %qE attribute is not 
(skip|used-gpr|all-gpr|used|all)",
+  name);

I'd suggest to follow the style in gcc/opts.c rather than the existing
examples in the i386 back end.  Something like this would be better:

+ warning (OPT_Wattributes,
+  "argument to %qE attribute is not one of %qs",
+  "(skip|used-gpr|all-gpr|used|all)",
+  name);

(There are other examples as well that use different formats still;
it would be nice to pick one style and use it throughout.)

Also, the function issues -Wattributes for invalid forms of
the attribute.  While incorrect forms of known attributes aren't
handled completely consistently, -Wattributes is documented to be
issued either for unknown attributes or known attributes used in
unexpected contexts, and as distinct from the errors issued for
incorrect forms of known attributes.

Besides more closely matching the documentation, it seems to me
that either issuing an error or a distinct (yet to be invented)
warning would be preferable to lumping all these sorts of problems
in -Wattributes.  As above, choosing the most suitable response
and adopting it consistently throughout would be helpful.

Martin



Thanks.

Qing


Begin forwarded message:

From: Qing Zhao via Gcc-patches 
Subject: [PATCH][x86][1/3]: Add 
-mzero-caller-saved-regs=[skip|used-gpr|all-gpr|used|all]
Date: April 17, 2020 at 12:31:45 PM CDT
To: richard Biener , fwei...@redhat.com, 
dal...@libc.org
Cc: gcc-patches@gcc.gnu.org, keesc...@chromium.org
Reply-To: Qing Zhao 

Hi,

This is a PING for an old  patch proposed by  H. J. Lu on Oct, 2018:

https://gcc.gnu.org/legacy-ml/gcc-patches/2018-10/msg02079.html

This is the first patch of the total 3 patches set, which provides the 
following new feature:

-mzero-caller-saved-regs=[skip|used-gpr|all-gpr|used|all] command-line
option and zero_caller_saved_regs("skip|used|all") function attribue:

1. -mzero-caller-saved-regs=skip and zero_caller_saved_regs("skip")

Don't zero caller-saved registers upon function return.

2. -mzero-caller-saved-regs=used-gpr and zero_caller_saved_regs("used-gpr")

Zero used caller-saved integer registers upon function return.

3. -mzero-caller-saved-regs=all-gpr and zero_caller_saved_regs("all-gpr”)

Zero all caller-saved integer registers upon function return.

4. -mzero-caller-saved-regs=used and zero_caller_saved_regs("used")

Zero used caller-saved integer and vector registers upon function return.

5. -mzero-caller-saved-regs=all and zero_caller_saved_regs("all")

Zero all caller-saved integer and vector registers upon function return.

This feature is needed by Linux kernel security improvement. Please refer to 
Kees Cook’s talk on Linux Plumber Conference 2019:
https://outflux.net/slides/2019/lpc/gcc-and-clang.pdf 

Tested on  x86-64 with bootstrapping GCC trunk, regression tests exposed 
several new regressions, these new regressions are
fixed by 2 

[committed] i386: Use ADD to implement compares with negated operand [PR94913]

2020-05-06 Thread Uros Bizjak via Gcc-patches
Use carry flag from addition to implement GEU/LTU compares
with negated operand, so e.g.

~x < y

compiles to:

addq%rsi, %rdi
setc%al

instead of:

notq%rdi
cmpq%rsi, %rdi
setb%al

2020-05-06  Uroš Bizjak  

PR target/94913
* config/i386/predicates.md (add_comparison_operator): New predicate.
* config/i386/i386.md (compare->add splitter): New splitters.

testsuite/ChangeLog:

2020-05-06  Uroš Bizjak  

PR target/94913
* gcc.target/i386/pr94913-1.c: New test.
* gcc.target/i386/pr94913-2.c: Ditto.

Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.

Committed to mainline.

Uros.
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 911ef7a6c4c..5fe851e0312 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -12324,6 +12324,21 @@
 
 ;; Store-flag instructions.
 
+(define_split
+  [(set (match_operand:QI 0 "nonimmediate_operand")
+   (match_operator:QI 1 "add_comparison_operator"
+ [(not:SWI (match_operand:SWI 2 "register_operand"))
+  (match_operand:SWI 3 "nonimmediate_operand")]))]
+  ""
+  [(parallel
+ [(set (reg:CCC FLAGS_REG)
+  (compare:CCC
+(plus:SWI (match_dup 2) (match_dup 3))
+(match_dup 2)))
+  (clobber (scratch:SWI))])
+   (set (match_dup 0)
+   (match_op_dup 1 [(reg:CCC FLAGS_REG) (const_int 0)]))])
+
 (define_split
   [(set (match_operand:QI 0 "nonimmediate_operand")
(match_operator:QI 1 "shr_comparison_operator"
@@ -12518,6 +12533,26 @@
 
 ;; Basic conditional jump instructions.
 
+(define_split
+  [(set (pc)
+   (if_then_else
+ (match_operator 1 "add_comparison_operator"
+   [(not:SWI (match_operand:SWI 2 "register_operand"))
+(match_operand:SWI 3 "nonimmediate_operand")])
+ (label_ref (match_operand 0))
+ (pc)))]
+  ""
+  [(parallel
+ [(set (reg:CCC FLAGS_REG)
+  (compare:CCC
+(plus:SWI (match_dup 2) (match_dup 3))
+(match_dup 2)))
+  (clobber (scratch:SWI))])
+   (set (pc)
+   (if_then_else (match_op_dup 1 [(reg:CCC FLAGS_REG) (const_int 0)])
+ (label_ref (match_operand 0))
+ (pc)))])
+
 (define_split
   [(set (pc)
(if_then_else
diff --git a/gcc/config/i386/predicates.md b/gcc/config/i386/predicates.md
index 1a5e2210eca..8d8bcb1a765 100644
--- a/gcc/config/i386/predicates.md
+++ b/gcc/config/i386/predicates.md
@@ -1293,6 +1293,9 @@
 (define_predicate "shr_comparison_operator"
   (match_code "gtu,leu"))
 
+(define_predicate "add_comparison_operator"
+  (match_code "geu,ltu"))
+
 ;; Return true if OP is a valid comparison operator in valid mode.
 (define_predicate "ix86_comparison_operator"
   (match_operand 0 "comparison_operator")
diff --git a/gcc/testsuite/gcc.target/i386/pr94913-1.c 
b/gcc/testsuite/gcc.target/i386/pr94913-1.c
new file mode 100644
index 000..f21032d4522
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr94913-1.c
@@ -0,0 +1,21 @@
+/* PR target/94913 */
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+char fooc (unsigned char x, unsigned char y)
+{
+  return (unsigned char) ~x < y;
+}
+
+short foos (unsigned short x, unsigned short y)
+{
+  return (unsigned short) ~x < y;
+}
+
+long fooi (unsigned long x, unsigned long y)
+{
+  return (unsigned long) ~x < y;
+}
+
+/* { dg-final { scan-assembler-not "cmp" } } */
+/* { dg-final { scan-assembler-times "add" 3 } } */
diff --git a/gcc/testsuite/gcc.target/i386/pr94913-2.c 
b/gcc/testsuite/gcc.target/i386/pr94913-2.c
new file mode 100644
index 000..22bca2bf27b
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr94913-2.c
@@ -0,0 +1,24 @@
+/* PR target/94913 */
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+void f1 (void);
+void f2 (void);
+
+void fooc (unsigned char x, unsigned char y)
+{
+  if ((unsigned char) ~x < y) f1 (); else f2 ();
+}
+
+void foos (unsigned short x, unsigned short y)
+{
+  if ((unsigned short) ~x < y) f1 (); else f2 ();
+}
+
+void fooi (unsigned long x, unsigned long y)
+{
+  if ((unsigned long) ~x < y) f1 (); else f2 ();
+}
+
+/* { dg-final { scan-assembler-not "cmp" } } */
+/* { dg-final { scan-assembler-times "add" 3 } } */


RE: [PATCH][AArch64] Use __getauxval instead of getauxval in LSE detection code in libgcc

2020-05-06 Thread Kyrylo Tkachov



> -Original Message-
> From: Joseph Myers 
> Sent: 06 May 2020 15:46
> To: Richard Biener 
> Cc: Kyrylo Tkachov ; Florian Weimer
> ; Szabolcs Nagy ; gcc-
> patc...@gcc.gnu.org; Jakub Jelinek 
> Subject: Re: [PATCH][AArch64] Use __getauxval instead of getauxval in LSE
> detection code in libgcc
> 
> On Wed, 6 May 2020, Richard Biener wrote:
> 
> > > Here is the updated patch for the record.
> > > Jakub, richi, is this ok for the GCC 10 branch?
> >
> > I'll defer to Joseph who is release manager as well.
> 
> This version is OK with me.

Thank you Joseph,
I've committed this version to trunk and the gcc-10 branch.
Kyrill

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


Re: [PATCH][AArch64] Use __getauxval instead of getauxval in LSE detection code in libgcc

2020-05-06 Thread Joseph Myers
On Wed, 6 May 2020, Richard Biener wrote:

> > Here is the updated patch for the record.
> > Jakub, richi, is this ok for the GCC 10 branch?
> 
> I'll defer to Joseph who is release manager as well.

This version is OK with me.

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


Re: [PATCH] tsan: Add optional support for distinguishing volatiles

2020-05-06 Thread Marco Elver via Gcc-patches
Hello, Jakub,

On Tue, 28 Apr 2020 at 16:58, Dmitry Vyukov  wrote:
>
> On Tue, Apr 28, 2020 at 4:55 PM Jakub Jelinek  wrote:
> >
> > On Tue, Apr 28, 2020 at 04:48:31PM +0200, Dmitry Vyukov wrote:
> > > FWIW this is:
> > >
> > > Acked-by: Dmitry Vyukov 
> > >
> > > We just landed a similar change to llvm:
> > > https://github.com/llvm/llvm-project/commit/5a2c31116f412c3b6888be361137efd705e05814
> > >
> > > Do you have any objections?
> >
> > I don't have objections or anything right now, we are just trying to
> > finalize GCC 10 and once it branches, patches like this can be
> > reviewed/committed for GCC11.
>
> Thanks for clarification!
> Then we will just wait.

Just saw the announcement that GCC11 is in development stage 1 [1]. In
case it is still too early, do let us know what time window we shall
follow up.

Would it be useful to rebase and resend the patch?

Many thanks,
-- Marco

[1] https://gcc.gnu.org/pipermail/gcc/2020-April/000505.html


Re: [PATCH] c++: template instantiation during fold_for_warn [PR94038]

2020-05-06 Thread Patrick Palka via Gcc-patches
On Wed, 6 May 2020, Patrick Palka wrote:

> On Tue, 5 May 2020, Patrick Palka wrote:
> 
> > On Tue, 5 May 2020, Patrick Palka wrote:
> > 
> > > Unfortunately, the previous fix to PR94038 is fragile.  When the
> > > argument to fold_for_warn is a bare CALL_EXPR, then all is well: the
> > > result of maybe_constant_value from fold_for_warn (with
> > > uid_sensitive=true) is reused via the cv_cache in the subsequent call to
> > > maybe_constant_value from cp_fold (with uid_sensitive=false), so we
> > > avoid instantiating bar.
> > > 
> > > But when the argument to fold_for_warn is more complex, e.g. an
> > > INDIRECT_REF of a CALL_EXPR, as in the testcase below (due to bar()
> > > returning const int& which we need to decay to int) then from
> > > fold_for_warn we call maybe_constant_value on the INDIRECT_REF, and from
> > > cp_fold we call it on the CALL_EXPR, so there is no reuse via the
> > > cv_cache and we therefore end up instantiating bar.
> > > 
> > > So for a more robust solution to this general issue of warning flags
> > > affecting code generation, it seems that we need a way to globally avoid
> > > template instantiation during constexpr evaluation whenever we're
> > > performing warning-dependent folding.
> > > 
> > > To that end, this patch replaces the flag constexpr_ctx::uid_sensitive
> > > with a global flag uid_sensitive_constexpr_evaluation_p, and enables it
> > > during fold_for_warn using an RAII helper.
> > > 
> > > The patch also adds a counter that keeps track of the number of times
> > > uid_sensitive_constexpr_evaluation_p is called, and we use this to
> > > determine whether the result of constexpr evaluation depended on the
> > > flag's value.  This lets us safely update the cv_cache and fold_cache
> > > from fold_for_warn in the most common case where the flag's value was
> > > irrelevant during constexpr evaluation.
> > 
> > Whoops, shortly after I sent the patch it occurred to me that we only
> > want to keep track of the number of times
> > uid_sensitive_constexpr_evaluation_p was called _and returned true_.
> > If the predicate was called and it returned false, then constexpr
> > evaluation was not restricted, so we could safely cache the result.
> > 
> > Please consider this patch instead, which also defines the various
> > helper classse out-of-line in constexpr.c for improved encapsulation:
> 
> Here's another version of the patch which just polishes comments, marks
> the 'evaluation_restricted_p' method const, renames
> 'uid_sensitive_constexpr_evaluation' to
> 'uid_sensitive_constexpr_evaluation_sentinel', and renames
> 'uid_sensitive_constexpr_evaluation_marker' to
> 'uid_sensitive_constexpr_evaluation_checker' to better convey their
> purpose.
> 
> The previous version passed bootstrap/regtest on x86_64-pc-linux-gnu,
> and bootstrap/regtest for this version is in progress.
> 
> -- >8 --
> 
> gcc/cp/ChangeLog:
> 
>   PR c++/94038
>   * constexpr.c (constexpr_ctx::uid_sensitive): Remove field.
>   (uid_sensitive_constexpr_evaluation_value): Define.
>   (uid_sensitive_constexpr_evaluation_true_counter): Define.
>   (uid_sensitive_constexpr_evaluation_p): Define.
>   (uid_sensitive_constexpr_evaluation_sentinel): Define its
>   constructor and destructor.
>   (uid_sensitive_constexpr_evaluation_checker): Define its
>   constructor and its evaluation_restricted_p method.
>   (get_fundef_copy): Remove 'ctx' parameter.  Use u_s_c_e_p
>   instead of constexpr_ctx::uid_sensitive.
>   (cxx_eval_call_expression): Use u_s_c_e_p instead, and test it
>   last.  Adjust call to get_fundef_copy.
>   (instantiate_cx_fn_r): Test u_s_c_e_p so that we increment the
>   counter if necessary.
>   (cxx_eval_outermost_constant_expr): Remove 'uid_sensitive'
>   parameter.  Adjust function body accordingly.  Use
>   uid_sensitive_constexpr_evaluation_value.
>   (maybe_constant_value): Remove 'uid_sensitive' parameter and
>   adjust function body accordingly.  Set up a
>   uid_sensitive_constexpr_evaluation_checker, and use it to
>   conditionally update the cv_cache.
>   * cp-gimplify.h (cp_fold): Set up a
>   uid_sensitive_constexpr_evaluation_checker, and use it to
>   conditionally update the fold_cache.
>   * cp-tree.h (maybe_constant_value): Update declaration.
>   (struct uid_sensitive_constexpr_evaluation_sentinel): Define.
>   (struct sensitive_constexpr_evaluation_checker): Define.
>   * expr.c (fold_for_warn): Set up a
>   uid_sensitive_constexpr_evaluation_sentinel before calling
>   the folding subroutines.  Drop all but the first argument to
>   maybe_constant_value.
> 
> gcc/testsuite/ChangeLog:
> 
>   PR c++/94038
>   * g++.dg/warn/pr94038-2.C: New test.
> ---
>  gcc/cp/constexpr.c| 96 ---
>  gcc/cp/cp-gimplify.c  | 13 ++--
>  gcc/cp/cp-tree.h  | 24 ++-
>  

[PATCH] Prepare removal of SLP_INSTANCE_GROUP_SIZE

2020-05-06 Thread Richard Biener
This removes trivial instances of SLP_INSTANCE_GROUP_SIZE and refrains
from using a "SLP instance" which nowadays is just one of the possibly
many entries into the SLP graph.

Bootstrapped / tested on x86_64-unknown-linux-gnu, pushed.

Richard.

2020-05-06  Richard Biener  

* tree-vectorizer.h (vect_transform_slp_perm_load): Adjust.
* tree-vect-data-refs.c (vect_slp_analyze_node_dependences):
Remove slp_instance parameter, just iterate over all scalar stmts.
(vect_slp_analyze_instance_dependence): Adjust and likewise.
* tree-vect-slp.c (vect_bb_slp_scalar_cost): Remove unused BB
parameter.
(vect_schedule_slp): Just iterate over all scalar stmts.
(vect_supported_load_permutation_p): Adjust.
(vect_transform_slp_perm_load): Remove slp_instance parameter,
instead use the number of lanes in the node as group size.
* tree-vect-stmts.c (vect_model_load_cost): Get vectorization
factor instead of slp_instance as parameter.
(vectorizable_load): Adjust.
---
 gcc/tree-vect-data-refs.c | 14 ++
 gcc/tree-vect-slp.c   | 18 --
 gcc/tree-vect-stmts.c | 16 ++--
 gcc/tree-vectorizer.h |  2 +-
 4 files changed, 21 insertions(+), 29 deletions(-)

diff --git a/gcc/tree-vect-data-refs.c b/gcc/tree-vect-data-refs.c
index 7e9ab3ec333..d41ba49fabf 100644
--- a/gcc/tree-vect-data-refs.c
+++ b/gcc/tree-vect-data-refs.c
@@ -695,8 +695,7 @@ vect_slp_analyze_data_ref_dependence (vec_info *vinfo,
disambiguating the loads.  */
 
 static bool
-vect_slp_analyze_node_dependences (vec_info *vinfo,
-  slp_instance instance, slp_tree node,
+vect_slp_analyze_node_dependences (vec_info *vinfo, slp_tree node,
   vec stores,
   stmt_vec_info last_store_info)
 {
@@ -704,7 +703,7 @@ vect_slp_analyze_node_dependences (vec_info *vinfo,
  in NODE verifying we can sink them up to the last stmt in the
  group.  */
   stmt_vec_info last_access_info = vect_find_last_scalar_stmt_in_slp (node);
-  for (unsigned k = 0; k < SLP_INSTANCE_GROUP_SIZE (instance); ++k)
+  for (unsigned k = 0; k < SLP_TREE_SCALAR_STMTS (node).length (); ++k)
 {
   stmt_vec_info access_info = SLP_TREE_SCALAR_STMTS (node)[k];
   if (access_info == last_access_info)
@@ -794,13 +793,12 @@ vect_slp_analyze_instance_dependence (vec_info *vinfo, 
slp_instance instance)
   stmt_vec_info last_store_info = NULL;
   if (store)
 {
-  if (! vect_slp_analyze_node_dependences (vinfo, instance, store,
-  vNULL, NULL))
+  if (! vect_slp_analyze_node_dependences (vinfo, store, vNULL, NULL))
return false;
 
   /* Mark stores in this instance and remember the last one.  */
   last_store_info = vect_find_last_scalar_stmt_in_slp (store);
-  for (unsigned k = 0; k < SLP_INSTANCE_GROUP_SIZE (instance); ++k)
+  for (unsigned k = 0; k < SLP_TREE_SCALAR_STMTS (store).length (); ++k)
gimple_set_visited (SLP_TREE_SCALAR_STMTS (store)[k]->stmt, true);
 }
 
@@ -811,7 +809,7 @@ vect_slp_analyze_instance_dependence (vec_info *vinfo, 
slp_instance instance)
   slp_tree load;
   unsigned int i;
   FOR_EACH_VEC_ELT (SLP_INSTANCE_LOADS (instance), i, load)
-if (! vect_slp_analyze_node_dependences (vinfo, instance, load,
+if (! vect_slp_analyze_node_dependences (vinfo, load,
 store
 ? SLP_TREE_SCALAR_STMTS (store)
 : vNULL, last_store_info))
@@ -822,7 +820,7 @@ vect_slp_analyze_instance_dependence (vec_info *vinfo, 
slp_instance instance)
 
   /* Unset the visited flag.  */
   if (store)
-for (unsigned k = 0; k < SLP_INSTANCE_GROUP_SIZE (instance); ++k)
+for (unsigned k = 0; k < SLP_TREE_SCALAR_STMTS (store).length (); ++k)
   gimple_set_visited (SLP_TREE_SCALAR_STMTS (store)[k]->stmt, false);
 
   return res;
diff --git a/gcc/tree-vect-slp.c b/gcc/tree-vect-slp.c
index f83b568dcc1..c097840b09a 100644
--- a/gcc/tree-vect-slp.c
+++ b/gcc/tree-vect-slp.c
@@ -2018,7 +2018,7 @@ vect_supported_load_permutation_p (vec_info *vinfo, 
slp_instance slp_instn)
  vec tem;
  unsigned n_perms;
  if (!vect_transform_slp_perm_load (vinfo, node, tem, NULL,
-1, slp_instn, true, _perms))
+1, true, _perms))
{
  if (dump_enabled_p ())
dump_printf_loc (MSG_MISSED_OPTIMIZATION,
@@ -2044,7 +2044,7 @@ vect_supported_load_permutation_p (vec_info *vinfo, 
slp_instance slp_instn)
   FOR_EACH_VEC_ELT (SLP_INSTANCE_LOADS (slp_instn), i, node)
 if (node->load_permutation.exists ()
&& !vect_transform_slp_perm_load (vinfo, node, vNULL, NULL, 

Re: [PATCH][AArch64] Use __getauxval instead of getauxval in LSE detection code in libgcc

2020-05-06 Thread Szabolcs Nagy
The 05/06/2020 11:39, Kyrylo Tkachov wrote:
> > -Original Message-
> > From: Florian Weimer 
> > Sent: 06 May 2020 11:28
> >
> > Is __gnu_linux__ defined with musl?  It's not really GNU/Linux, after
> > all.  musl doesn't have __getauxval IIRC, so it would break the build
> > there.
> 
> I don't think it does (at least not with a git grep for it in the musl code).
> GCC doesn't define it for musl targets either. I see it defined for uclinux 
> for arm, not aarch64 though.

__gnu_linux__ is not defined on musl.

it would be better if there was a mechanism to
introduce namespace clean abi symbols across libc
implementations that a compiler can use, instead
of tying it to the glibc version, but currently
there is no such mechanism and only glibc has this
particular symbol, so the patch looks ok to me.


Re: [PATCH] x32: Update baseline_symbols.txt

2020-05-06 Thread Jonathan Wakely via Gcc-patches

On 06/05/20 05:37 -0700, H.J. Lu via Libstdc++ wrote:

On Wed, May 6, 2020 at 2:39 AM Jonathan Wakely via Gcc-patches
 wrote:


On 06/05/20 10:15 +0100, Jonathan Wakely wrote:
>On 06/05/20 11:09 +0200, Jakub Jelinek via Libstdc++ wrote:
>>On Wed, May 06, 2020 at 10:49:13AM +0200, Rainer Orth wrote:
>>>I just remembered that the libstdc++ ABI baselines haven't been updated
>>>for the GCC 10 release yet.  This patch corrects this for Solaris/SPARC
>>>and x86.
>>
>>Oops, here are the updates from Fedora packages built during the weekend.
>>Ok for trunk and gcc-10?
>
>Yes, these all look right. Thanks.

And this updates the manual on master. I'll backport this as well.



Here is the x32 part.  OK for master and GCC 10 branch?


OK, subject to RM approval for gcc-10 branch.

Thanks!




Re: [PATCH] tree-optimization/57359 - rewrite SM code

2020-05-06 Thread Richard Biener
On Tue, 5 May 2020, Richard Biener wrote:

> 
> This rewrites store-motion to process candidates where we can
> ensure order preserving separately and with no need to disambiguate
> against all stores.  Those candidates we cannot handle this way
> are validated to be independent on all stores (w/o TBAA) and then
> processed as "unordered" (all conditionally executed stores are so
> as well).
> 
> This will necessary cause
>   FAIL: gcc.dg/graphite/pr80906.c scan-tree-dump graphite "isl AST to Gimple 
> succeeded"
> because the SM previously performed is not valid for exactly the PR57359
> reason, we still perform SM of qc for the innermost loop but that's not 
> enough.
> 
> There is still room for improvements because we still check some constraints
> for the order preserving cases that are only necessary in the current
> strict way for the unordered ones.  Leaving that for the furture.
> 
> Bootstrapped and tested on x86_64-unknown-linux-gnu, a final
> SPEC 2006 evaluation is running.

A first complete 3-run looked too good so I repeated the off-noise
ones which eliminated most of them as noise ... there's two
consistent parts namely a ~1% regression on 401.bzip2 and a
~1% progression on 464.h264ref.  Given earlier much larger (~5-10%)
"consistent" noise on other tests I declare it a wash ...

Means, I'll push the patch to master once 10.1 is released (unless
there are comments on the patch itself).

Thanks,
Richard.

> Thanks,
> Richard.
> 
> 2020-05-05  Richard Biener  
> 
>   PR tree-optimization/57359
>   * tree-ssa-loop-im.c (im_mem_ref::indep_loop): Remove.
>   (in_mem_ref::dep_loop): Repurpose.
>   (LOOP_DEP_BIT): Remove.
>   (enum dep_kind): New.
>   (enum dep_state): Likewise.
>   (record_loop_dependence): New function to populate the
>   dependence cache.
>   (query_loop_dependence): New function to query the dependence
>   cache.
>   (memory_accesses::refs_in_loop): Rename to ...
>   (memory_accesses::refs_loaded_in_loop): ... this and change to
>   only record loads.
>   (outermost_indep_loop): Adjust.
>   (mem_ref_alloc): Likewise.
>   (gather_mem_refs_stmt): Likewise.
>   (mem_refs_may_alias_p): Add tbaa_p parameter and pass it down.
>   (struct sm_aux): New.
>   (execute_sm): Split code generation on exits, record state
>   into new hash-map.
>   (enum sm_kind): New.
>   (execute_sm_exit): Exit code generation part.
>   (sm_seq_push_down): Helper for sm_seq_valid_bb performing
>   dependence checking on stores reached from exits.
>   (sm_seq_valid_bb): New function gathering SM stores on exits.
>   (hoist_memory_references): Re-implement.
>   (refs_independent_p): Add tbaa_p parameter and pass it down.
>   (record_dep_loop): Remove.
>   (ref_indep_loop_p_1): Fold into ...
>   (ref_indep_loop_p): ... this and generalize for three kinds
>   of dependence queries.
>   (can_sm_ref_p): Adjust according to hoist_memory_references
>   changes.
>   (store_motion_loop): Don't do anything if the set of SM
>   candidates is empty.
>   (tree_ssa_lim_initialize): Adjust.
>   (tree_ssa_lim_finalize): Likewise.
> 
>   * gcc.dg/torture/pr57359-1.c: New testcase.
>   * gcc.dg/torture/pr57359-1.c: Likewise.
>   * gcc.dg/tree-ssa/ssa-lim-14.c: Likewise.
> ---
>  gcc/testsuite/gcc.dg/torture/pr57359-1.c   |  23 ++
>  gcc/testsuite/gcc.dg/torture/pr57359-2.c   |  30 ++
>  gcc/testsuite/gcc.dg/tree-ssa/ssa-lim-14.c |  33 ++
>  gcc/tree-ssa-loop-im.c | 576 
> +++--
>  4 files changed, 548 insertions(+), 114 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.dg/torture/pr57359-1.c
>  create mode 100644 gcc/testsuite/gcc.dg/torture/pr57359-2.c
>  create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/ssa-lim-14.c
> 
> diff --git a/gcc/testsuite/gcc.dg/torture/pr57359-1.c 
> b/gcc/testsuite/gcc.dg/torture/pr57359-1.c
> new file mode 100644
> index 000..f5a406a34d6
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/torture/pr57359-1.c
> @@ -0,0 +1,23 @@
> +/* { dg-do run } */
> +
> +extern void abort();
> +
> +typedef int A;
> +typedef float B;
> +
> +void __attribute__((noinline,noclone))
> +foo(A *p, B *q, long unk)
> +{
> +  for (long i = 0; i < unk; ++i) {
> +  *p = 1;
> +  q[i] = 42;
> +  }
> +}
> +
> +int main(void)
> +{
> +  union { A x; B f; } u;
> +  foo(, , 1);
> +  if (u.f != 42) abort();
> +  return 0;
> +}
> diff --git a/gcc/testsuite/gcc.dg/torture/pr57359-2.c 
> b/gcc/testsuite/gcc.dg/torture/pr57359-2.c
> new file mode 100644
> index 000..ce7d9890af4
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/torture/pr57359-2.c
> @@ -0,0 +1,30 @@
> +/* { dg-do run } */
> +/* { dg-additional-options "-fstrict-aliasing" } */
> +
> +extern void abort();
> +
> +typedef int A;
> +typedef float B;
> +
> +void __attribute__((noipa))
> +foo(A * p, B *r, long unk, long oh)
> +{
> +  for (long i = 0; i < unk; 

Re: [PATCH] x32: Update baseline_symbols.txt

2020-05-06 Thread Jakub Jelinek via Gcc-patches
On Wed, May 06, 2020 at 02:14:58PM +0100, Jonathan Wakely wrote:
> > Here is the x32 part.  OK for master and GCC 10 branch?
> 
> OK, subject to RM approval for gcc-10 branch.

Ok for 10.1.

Jakub



Re: [PATCH] libstdc++: Update Solaris baselines for GCC 10.1

2020-05-06 Thread Jonathan Wakely via Gcc-patches

On 06/05/20 14:12 +0200, Rainer Orth wrote:

Hi Jonathan,


On 06/05/20 10:49 +0200, Rainer Orth wrote:

I just remembered that the libstdc++ ABI baselines haven't been updated
for the GCC 10 release yet.  This patch corrects this for Solaris/SPARC
and x86.


I think we also need to update them on the gcc-9 branch, all the
3.4.28 symbols are on that branch too (added in 9.3.0).


indeed.  I hadn't even thought to look there.  Will post a patch once
testing has finished.


Thanks! Obviously less urgent than gcc-10.



Re: [PATCH] lto-wrapper: split arguments of getenv ("MAKE").

2020-05-06 Thread Martin Liška

On 5/6/20 2:52 PM, Richard Biener wrote:

On Wed, May 6, 2020 at 2:08 PM Martin Liška  wrote:


Hi.

The patch splits arguments in getenv ("MAKE") so that one can use:

$ MAKE="make -s" gcc main.o -flto=16

Right now it fails due to:
[pid  6004] execve("/home/marxin/Programming/script-misc/make -s", ["make -s", "-f", 
"/tmp/ccNpRBlZ.mk", "-j16", "all"], 0x4b69b0 /* 82 vars */) = -1 ENOENT (No such file or directory)

I've tested the patch for lto.exp and now I'm doing a proper bootstrap.
Ready after tests?


+ const char *make = getenv ("MAKE");
+ unsigned argc = 0;
+ struct obstack make_argv_obstack;
+ obstack_init (_argv_obstack);
+
+ if (make)
+   {
+ argv = buildargv (make);

you are overwriting the argv parameter here, I suggest to use a new
local variable here.


Oh.



buildargv can fail in which case it returns NULL so I suggest
to fall back to "make" in that case.

+ for (; argv[argc]; argc++)
+   obstack_ptr_grow (_argv_obstack, argv[argc]);

argc is only used in this scope so declare it in the for() loop?

btw, I suggest to simply re-use argv_obstack here.


Done.



+ const char **argv = XOBFINISH (_argv_obstack, const char **);

you are shadowing argv here, what's wrong with using new_argv?


The shadowing in the function is really bad, it's a long function.



+
+ pex = collect_execute (argv[0], CONST_CAST (char **, argv),
  NULL, NULL, PEX_SEARCH, false);
- do_wait (new_argv[0], pex);
+ do_wait (argv[0], pex);
+ obstack_free (_argv_obstack, NULL);

after pex is finished the argv allocated via buildargv should be freed
with freeargv


Done.

I hope it's better now?

Martin



Richard.

+   }



Thanks,
Martin

gcc/ChangeLog:

2020-05-06  Martin Liska  

 * lto-wrapper.c: Split arguments of MAKE environment
 variable.
---
   gcc/lto-wrapper.c | 35 ---
   1 file changed, 24 insertions(+), 11 deletions(-)




>From d2ded95342f543c800215e4e9e2d66332183bf8b Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Wed, 6 May 2020 13:59:23 +0200
Subject: [PATCH] lto-wrapper: split arguments of getenv ("MAKE").

gcc/ChangeLog:

2020-05-06  Martin Liska  

	* lto-wrapper.c: Split arguments of MAKE environment
	variable.
---
 gcc/lto-wrapper.c | 27 ++-
 1 file changed, 18 insertions(+), 9 deletions(-)

diff --git a/gcc/lto-wrapper.c b/gcc/lto-wrapper.c
index 19d0c224dad..e34b6979d1f 100644
--- a/gcc/lto-wrapper.c
+++ b/gcc/lto-wrapper.c
@@ -1894,23 +1894,32 @@ cont:
 	  putenv (xstrdup ("MAKEFLAGS="));
 	  putenv (xstrdup ("MFLAGS="));
 	}
-	  new_argv[0] = getenv ("MAKE");
-	  if (!new_argv[0])
-	new_argv[0] = "make";
-	  new_argv[1] = "-f";
-	  new_argv[2] = makefile;
-	  i = 3;
+
+	  char **make_argv = buildargv (getenv ("MAKE"));
+	  if (make_argv)
+	{
+	  for (unsigned argc = 0; make_argv[argc]; argc++)
+		obstack_ptr_grow (_obstack, make_argv[argc]);
+	}
+	  else
+	obstack_ptr_grow (_obstack, "make");
+
+	  obstack_ptr_grow (_obstack, "-f");
+	  obstack_ptr_grow (_obstack, makefile);
 	  if (!jobserver)
 	{
 	  snprintf (jobs, 31, "-j%ld",
 			auto_parallel ? nthreads_var : parallel);
-	  new_argv[i++] = jobs;
+	  obstack_ptr_grow (_obstack, jobs);
 	}
-	  new_argv[i++] = "all";
-	  new_argv[i++] = NULL;
+	  obstack_ptr_grow (_obstack, "all");
+	  obstack_ptr_grow (_obstack, NULL);
+	  new_argv = XOBFINISH (_obstack, const char **);
+
 	  pex = collect_execute (new_argv[0], CONST_CAST (char **, new_argv),
  NULL, NULL, PEX_SEARCH, false);
 	  do_wait (new_argv[0], pex);
+	  freeargv (make_argv);
 	  maybe_unlink (makefile);
 	  makefile = NULL;
 	  for (i = 0; i < nr; ++i)
-- 
2.26.2



Re: [PATCH] lto-wrapper: split arguments of getenv ("MAKE").

2020-05-06 Thread Richard Biener via Gcc-patches
On Wed, May 6, 2020 at 2:08 PM Martin Liška  wrote:
>
> Hi.
>
> The patch splits arguments in getenv ("MAKE") so that one can use:
>
> $ MAKE="make -s" gcc main.o -flto=16
>
> Right now it fails due to:
> [pid  6004] execve("/home/marxin/Programming/script-misc/make -s", ["make 
> -s", "-f", "/tmp/ccNpRBlZ.mk", "-j16", "all"], 0x4b69b0 /* 82 vars */) = -1 
> ENOENT (No such file or directory)
>
> I've tested the patch for lto.exp and now I'm doing a proper bootstrap.
> Ready after tests?

+ const char *make = getenv ("MAKE");
+ unsigned argc = 0;
+ struct obstack make_argv_obstack;
+ obstack_init (_argv_obstack);
+
+ if (make)
+   {
+ argv = buildargv (make);

you are overwriting the argv parameter here, I suggest to use a new
local variable here.

buildargv can fail in which case it returns NULL so I suggest
to fall back to "make" in that case.

+ for (; argv[argc]; argc++)
+   obstack_ptr_grow (_argv_obstack, argv[argc]);

argc is only used in this scope so declare it in the for() loop?

btw, I suggest to simply re-use argv_obstack here.

+ const char **argv = XOBFINISH (_argv_obstack, const char **);

you are shadowing argv here, what's wrong with using new_argv?

+
+ pex = collect_execute (argv[0], CONST_CAST (char **, argv),
 NULL, NULL, PEX_SEARCH, false);
- do_wait (new_argv[0], pex);
+ do_wait (argv[0], pex);
+ obstack_free (_argv_obstack, NULL);

after pex is finished the argv allocated via buildargv should be freed
with freeargv

Richard.

+   }


> Thanks,
> Martin
>
> gcc/ChangeLog:
>
> 2020-05-06  Martin Liska  
>
> * lto-wrapper.c: Split arguments of MAKE environment
> variable.
> ---
>   gcc/lto-wrapper.c | 35 ---
>   1 file changed, 24 insertions(+), 11 deletions(-)
>
>


[PATCH] x32: Update baseline_symbols.txt

2020-05-06 Thread H.J. Lu via Gcc-patches
On Wed, May 6, 2020 at 2:39 AM Jonathan Wakely via Gcc-patches
 wrote:
>
> On 06/05/20 10:15 +0100, Jonathan Wakely wrote:
> >On 06/05/20 11:09 +0200, Jakub Jelinek via Libstdc++ wrote:
> >>On Wed, May 06, 2020 at 10:49:13AM +0200, Rainer Orth wrote:
> >>>I just remembered that the libstdc++ ABI baselines haven't been updated
> >>>for the GCC 10 release yet.  This patch corrects this for Solaris/SPARC
> >>>and x86.
> >>
> >>Oops, here are the updates from Fedora packages built during the weekend.
> >>Ok for trunk and gcc-10?
> >
> >Yes, these all look right. Thanks.
>
> And this updates the manual on master. I'll backport this as well.
>

Here is the x32 part.  OK for master and GCC 10 branch?

Thanks.

-- 
H.J.
From 3c4a5a4a52648ec97a3a66e02df9e7899ab65168 Mon Sep 17 00:00:00 2001
From: "H.J. Lu" 
Date: Wed, 6 May 2020 05:35:02 -0700
Subject: [PATCH] x32: Update baseline_symbols.txt

	* config/abi/post/x86_64-linux-gnu/x32/baseline_symbols.txt: Updated.
---
 .../x86_64-linux-gnu/x32/baseline_symbols.txt   | 17 +
 1 file changed, 17 insertions(+)

diff --git a/libstdc++-v3/config/abi/post/x86_64-linux-gnu/x32/baseline_symbols.txt b/libstdc++-v3/config/abi/post/x86_64-linux-gnu/x32/baseline_symbols.txt
index 990abf00d70..5a7518fd2aa 100644
--- a/libstdc++-v3/config/abi/post/x86_64-linux-gnu/x32/baseline_symbols.txt
+++ b/libstdc++-v3/config/abi/post/x86_64-linux-gnu/x32/baseline_symbols.txt
@@ -2062,16 +2062,20 @@ FUNC:_ZNSt12__basic_fileIcED1Ev@@GLIBCXX_3.4
 FUNC:_ZNSt12__basic_fileIcED2Ev@@GLIBCXX_3.4
 FUNC:_ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1EOS5_@@GLIBCXX_3.4.26
 FUNC:_ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1Ev@@GLIBCXX_3.4.26
+FUNC:_ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC2EOS5_@@GLIBCXX_3.4.28
 FUNC:_ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC2Ev@@GLIBCXX_3.4.27
 FUNC:_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEC1EOS4_@@GLIBCXX_3.4.26
 FUNC:_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEC1Ev@@GLIBCXX_3.4.26
+FUNC:_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEC2EOS4_@@GLIBCXX_3.4.28
 FUNC:_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEC2Ev@@GLIBCXX_3.4.27
 FUNC:_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEaSEOS4_@@GLIBCXX_3.4.26
 FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1EOS6_@@GLIBCXX_3.4.26
 FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1Ev@@GLIBCXX_3.4.26
+FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC2EOS6_@@GLIBCXX_3.4.28
 FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC2Ev@@GLIBCXX_3.4.27
 FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC1EOS5_@@GLIBCXX_3.4.26
 FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC1Ev@@GLIBCXX_3.4.26
+FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC2EOS5_@@GLIBCXX_3.4.28
 FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC2Ev@@GLIBCXX_3.4.27
 FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEaSEOS5_@@GLIBCXX_3.4.26
 FUNC:_ZNSt12bad_weak_ptrD0Ev@@GLIBCXX_3.4.15
@@ -3001,12 +3005,18 @@ FUNC:_ZNSt3_V214error_categoryD1Ev@@GLIBCXX_3.4.21
 FUNC:_ZNSt3_V214error_categoryD2Ev@@GLIBCXX_3.4.21
 FUNC:_ZNSt3_V215system_categoryEv@@GLIBCXX_3.4.21
 FUNC:_ZNSt3_V216generic_categoryEv@@GLIBCXX_3.4.21
+FUNC:_ZNSt3pmr15memory_resourceD0Ev@@GLIBCXX_3.4.28
+FUNC:_ZNSt3pmr15memory_resourceD1Ev@@GLIBCXX_3.4.28
+FUNC:_ZNSt3pmr15memory_resourceD2Ev@@GLIBCXX_3.4.28
 FUNC:_ZNSt3pmr19new_delete_resourceEv@@GLIBCXX_3.4.26
 FUNC:_ZNSt3pmr20get_default_resourceEv@@GLIBCXX_3.4.26
 FUNC:_ZNSt3pmr20null_memory_resourceEv@@GLIBCXX_3.4.26
 FUNC:_ZNSt3pmr20set_default_resourceEPNS_15memory_resourceE@@GLIBCXX_3.4.26
 FUNC:_ZNSt3pmr25monotonic_buffer_resource13_M_new_bufferEjj@@GLIBCXX_3.4.26
 FUNC:_ZNSt3pmr25monotonic_buffer_resource18_M_release_buffersEv@@GLIBCXX_3.4.26
+FUNC:_ZNSt3pmr25monotonic_buffer_resourceD0Ev@@GLIBCXX_3.4.28
+FUNC:_ZNSt3pmr25monotonic_buffer_resourceD1Ev@@GLIBCXX_3.4.28
+FUNC:_ZNSt3pmr25monotonic_buffer_resourceD2Ev@@GLIBCXX_3.4.28
 FUNC:_ZNSt3pmr26synchronized_pool_resource11do_allocateEjj@@GLIBCXX_3.4.26
 FUNC:_ZNSt3pmr26synchronized_pool_resource13do_deallocateEPvjj@@GLIBCXX_3.4.26
 FUNC:_ZNSt3pmr26synchronized_pool_resource7releaseEv@@GLIBCXX_3.4.26
@@ -4409,6 +4419,7 @@ 

Re: [PATCH] libstdc++: Update Solaris baselines for GCC 10.1

2020-05-06 Thread Rainer Orth
Hi Jonathan,

> On 06/05/20 10:49 +0200, Rainer Orth wrote:
>>I just remembered that the libstdc++ ABI baselines haven't been updated
>>for the GCC 10 release yet.  This patch corrects this for Solaris/SPARC
>>and x86.
>
> I think we also need to update them on the gcc-9 branch, all the
> 3.4.28 symbols are on that branch too (added in 9.3.0).

indeed.  I hadn't even thought to look there.  Will post a patch once
testing has finished.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University


Re: [PATCH v2] Add handling of MULT_EXPR/PLUS_EXPR for wrapping overflow in affine combination(PR83403)

2020-05-06 Thread Richard Biener
On Thu, 30 Apr 2020, luoxhu wrote:

> Update the patch with overflow check.  Bootstrap and regression tested PASS 
> on Power8-LE.
> 
> 
> Use determine_value_range to get value range info for fold convert expressions
> with internal operation PLUS_EXPR/MINUS_EXPR/MULT_EXPR when not overflow on
> wrapping overflow inner type.  i.e.:
> 
> (long unsigned int)((unsigned  int)n * 10 + 1)
> =>
> (long unsigned int)n * (long unsigned int)10 + (long unsigned int)1
> 
> With this patch for affine combination, load/store motion could detect
> more address refs independency and promote some memory expressions to
> registers within loop.
> 
> PS: Replace the previous "(T1)(X + CST) as (T1)X - (T1)(-CST))"
> to "(T1)(X + CST) as (T1)X + (T1)(CST))" for wrapping overflow.

This is OK for trunk if bootstrapped / tested properl.

Thanks,
Richard.

> gcc/ChangeLog
> 
>   2020-04-30  Xiong Hu Luo  
> 
>   PR tree-optimization/83403
>   * tree-affine.c (expr_to_aff_combination): Replace SSA_NAME with
>   determine_value_range, Add fold conversion of MULT_EXPR, fix the
>   previous PLUS_EXPR.
> 
> gcc/testsuite/ChangeLog
> 
>   2020-04-30  Xiong Hu Luo  
> 
>   PR tree-optimization/83403
>   * gcc.dg/tree-ssa/pr83403-1.c: New test.
>   * gcc.dg/tree-ssa/pr83403-2.c: New test.
>   * gcc.dg/tree-ssa/pr83403.h: New header.
> ---
>  gcc/testsuite/gcc.dg/tree-ssa/pr83403-1.c |  8 ++
>  gcc/testsuite/gcc.dg/tree-ssa/pr83403-2.c |  8 ++
>  gcc/testsuite/gcc.dg/tree-ssa/pr83403.h   | 30 +++
>  gcc/tree-affine.c | 24 ++
>  4 files changed, 60 insertions(+), 10 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr83403-1.c
>  create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr83403-2.c
>  create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr83403.h
> 
> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr83403-1.c 
> b/gcc/testsuite/gcc.dg/tree-ssa/pr83403-1.c
> new file mode 100644
> index 000..748375b03af
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/pr83403-1.c
> @@ -0,0 +1,8 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O3 -funroll-loops -fdump-tree-lim2-details" } */
> +
> +#define TYPE unsigned int
> +
> +#include "pr83403.h"
> +
> +/* { dg-final { scan-tree-dump-times "Executing store motion of" 10 "lim2" } 
> } */
> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr83403-2.c 
> b/gcc/testsuite/gcc.dg/tree-ssa/pr83403-2.c
> new file mode 100644
> index 000..ca2e6bbd61c
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/pr83403-2.c
> @@ -0,0 +1,8 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O3 -funroll-loops -fdump-tree-lim2-details" } */
> +
> +#define TYPE int
> +
> +#include "pr83403.h"
> +
> +/* { dg-final { scan-tree-dump-times "Executing store motion of" 10 "lim2" } 
> } */
> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr83403.h 
> b/gcc/testsuite/gcc.dg/tree-ssa/pr83403.h
> new file mode 100644
> index 000..0da8a835b5f
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/pr83403.h
> @@ -0,0 +1,30 @@
> +__attribute__ ((noinline)) void
> +calculate (const double *__restrict__ A, const double *__restrict__ B,
> +double *__restrict__ C)
> +{
> +  TYPE m = 0;
> +  TYPE n = 0;
> +  TYPE k = 0;
> +
> +  A = (const double *) __builtin_assume_aligned (A, 16);
> +  B = (const double *) __builtin_assume_aligned (B, 16);
> +  C = (double *) __builtin_assume_aligned (C, 16);
> +
> +  for (n = 0; n < 9; n++)
> +{
> +  for (m = 0; m < 10; m++)
> + {
> +   C[(n * 10) + m] = 0.0;
> + }
> +
> +  for (k = 0; k < 17; k++)
> + {
> +#pragma simd
> +   for (m = 0; m < 10; m++)
> + {
> +   C[(n * 10) + m] += A[(k * 20) + m] * B[(n * 20) + k];
> + }
> + }
> +}
> +}
> +
> diff --git a/gcc/tree-affine.c b/gcc/tree-affine.c
> index 0eb8db1b086..5620e6bf28f 100644
> --- a/gcc/tree-affine.c
> +++ b/gcc/tree-affine.c
> @@ -343,24 +343,28 @@ expr_to_aff_combination (aff_tree *comb, tree_code 
> code, tree type,
>   wide_int minv, maxv;
>   /* If inner type has wrapping overflow behavior, fold conversion
>  for below case:
> -  (T1)(X - CST) -> (T1)X - (T1)CST
> -if X - CST doesn't overflow by range information.  Also handle
> -(T1)(X + CST) as (T1)(X - (-CST)).  */
> +  (T1)(X *+- CST) -> (T1)X *+- (T1)CST
> +if X *+- CST doesn't overflow by range information.  */
>   if (TYPE_UNSIGNED (itype)
>   && TYPE_OVERFLOW_WRAPS (itype)
> - && TREE_CODE (op0) == SSA_NAME
>   && TREE_CODE (op1) == INTEGER_CST
> - && icode != MULT_EXPR
> - && get_range_info (op0, , ) == VR_RANGE)
> + && determine_value_range (op0, , ) == VR_RANGE)
> {
> + wi::overflow_type overflow = wi::OVF_NONE;
> + signop sign = UNSIGNED;
>   if (icode == 

[PATCH] lto-wrapper: split arguments of getenv ("MAKE").

2020-05-06 Thread Martin Liška

Hi.

The patch splits arguments in getenv ("MAKE") so that one can use:

$ MAKE="make -s" gcc main.o -flto=16

Right now it fails due to:
[pid  6004] execve("/home/marxin/Programming/script-misc/make -s", ["make -s", "-f", 
"/tmp/ccNpRBlZ.mk", "-j16", "all"], 0x4b69b0 /* 82 vars */) = -1 ENOENT (No such file or directory)

I've tested the patch for lto.exp and now I'm doing a proper bootstrap.
Ready after tests?

Thanks,
Martin

gcc/ChangeLog:

2020-05-06  Martin Liska  

* lto-wrapper.c: Split arguments of MAKE environment
variable.
---
 gcc/lto-wrapper.c | 35 ---
 1 file changed, 24 insertions(+), 11 deletions(-)


diff --git a/gcc/lto-wrapper.c b/gcc/lto-wrapper.c
index 19d0c224dad..16d85625377 100644
--- a/gcc/lto-wrapper.c
+++ b/gcc/lto-wrapper.c
@@ -1894,23 +1894,36 @@ cont:
 	  putenv (xstrdup ("MAKEFLAGS="));
 	  putenv (xstrdup ("MFLAGS="));
 	}
-	  new_argv[0] = getenv ("MAKE");
-	  if (!new_argv[0])
-	new_argv[0] = "make";
-	  new_argv[1] = "-f";
-	  new_argv[2] = makefile;
-	  i = 3;
+	  const char *make = getenv ("MAKE");
+	  unsigned argc = 0;
+	  struct obstack make_argv_obstack;
+	  obstack_init (_argv_obstack);
+
+	  if (make)
+	{
+	  argv = buildargv (make);
+	  for (; argv[argc]; argc++)
+		obstack_ptr_grow (_argv_obstack, argv[argc]);
+	}
+	  else
+	obstack_ptr_grow (_argv_obstack, "make");
+
+	  obstack_ptr_grow (_argv_obstack, "-f");
+	  obstack_ptr_grow (_argv_obstack, makefile);
 	  if (!jobserver)
 	{
 	  snprintf (jobs, 31, "-j%ld",
 			auto_parallel ? nthreads_var : parallel);
-	  new_argv[i++] = jobs;
+	  obstack_ptr_grow (_argv_obstack, jobs);
 	}
-	  new_argv[i++] = "all";
-	  new_argv[i++] = NULL;
-	  pex = collect_execute (new_argv[0], CONST_CAST (char **, new_argv),
+	  obstack_ptr_grow (_argv_obstack, "all");
+	  obstack_ptr_grow (_argv_obstack, NULL);
+	  const char **argv = XOBFINISH (_argv_obstack, const char **);
+
+	  pex = collect_execute (argv[0], CONST_CAST (char **, argv),
  NULL, NULL, PEX_SEARCH, false);
-	  do_wait (new_argv[0], pex);
+	  do_wait (argv[0], pex);
+	  obstack_free (_argv_obstack, NULL);
 	  maybe_unlink (makefile);
 	  makefile = NULL;
 	  for (i = 0; i < nr; ++i)



Re: [patch] Fix a few DWARF bugs with -fgnat-encodings=minimal

2020-05-06 Thread Richard Biener via Gcc-patches
On Tue, May 5, 2020 at 10:43 AM Eric Botcazou  wrote:
>
> Hi,
>
> The -fgnat-encodings=minimal switch tells the compiler to generate motly pure
> DWARF for the GNAT compiler and it contains some bugs related to discriminated
> record types with variant part.
>
> Tested on x86-64/Linux, OK for the mainline?

OK.

Thanks,
Richard.

>
> 2020-05-05  Eric Botcazou  
> Pierre-Marie de Rodat  
>
> * dwarf2out.c (add_data_member_location_attribute): Take into account
> the variant part offset in the computation of the data bit offset.
> (add_bit_offset_attribute): Remove CTX parameter.  Pass a new context
> in the call to field_byte_offset.
> (gen_field_die): Adjust call to add_bit_offset_attribute and remove
> confusing assertion.
> (analyze_variant_discr): Deal with boolean subtypes.
>
>
> 2020-05-05  Eric Botcazou  
>
> * gnat.dg/debug16.adb: New test.
>
> --
> Eric Botcazou


Re: [PATCH] c-attribs.c: Fix use of uninitialized variable nunits

2020-05-06 Thread Richard Biener via Gcc-patches
On Tue, May 5, 2020 at 5:47 PM Stefan Schulze Frielinghaus
 wrote:
>
> On Tue, May 05, 2020 at 02:58:51PM +0200, Richard Biener wrote:
> > On Mon, May 4, 2020 at 4:07 PM Stefan Schulze Frielinghaus
> >  wrote:
> > >
> > > On Mon, May 04, 2020 at 03:19:02PM +0200, Richard Biener wrote:
> > > > On Mon, May 4, 2020 at 1:44 PM Stefan Schulze Frielinghaus
> > > >  wrote:
> > > > >
> > > > > On Tue, Apr 28, 2020 at 08:27:12PM +0200, Stefan Schulze Frielinghaus 
> > > > > wrote:
> > > > > > On Tue, Apr 28, 2020 at 11:33:31AM +0200, Richard Biener wrote:
> > > > > > > On Tue, Apr 28, 2020 at 10:03 AM Stefan Schulze Frielinghaus via
> > > > > > > Gcc-patches  wrote:
> > > > > > > >
> > > > > > > > In function handle_vector_size_attribute local variable nunits 
> > > > > > > > is
> > > > > > > > supposed to be initialized by function 
> > > > > > > > type_valid_for_vector_size.
> > > > > > > > However, in case ARGS is null the function may return with a 
> > > > > > > > non-null
> > > > > > > > value and leave nunits uninitialized.  This results in 
> > > > > > > > warning/error:
> > > > > > > >
> > > > > > > > gcc/poly-int.h: In function 'tree_node* 
> > > > > > > > handle_vector_size_attribute(tree_node**, tree, tree, int, 
> > > > > > > > bool*)':
> > > > > > > > gcc/poly-int.h:330:3: error: 'nunits' may be used uninitialized 
> > > > > > > > in this function [-Werror=maybe-uninitialized]
> > > > > > > >   330 |   ((void) (&(RES).coeffs[0] == (C *) 0), \
> > > > > > > >   |   ^
> > > > > > > > gcc/c-family/c-attribs.c:3695:26: note: 'nunits' was declared 
> > > > > > > > here
> > > > > > > >  3695 |   unsigned HOST_WIDE_INT nunits;
> > > > > > > >   |
> > > > > > > >
> > > > > > > > This is fixed by also checking whether ARGS is null or not.
> > > > > > > >
> > > > > > > > Bootstrapped and regtested on S/390. Ok for master?
> > > > > > >
> > > > > > > I think it's better to assert that it is not null for example by 
> > > > > > > adding a
> > > > > > > nonnull attribute?  Can you check if that works?  If it doesn't 
> > > > > > > the
> > > > > > > patch is OK.
> > > > > >
> > > > > > Yes, that works, too.  Please find an updated version attached.  If 
> > > > > > you
> > > > > > think it is useful I could also add a gcc_assert (!args) for minimal
> > > > > > testing.
> > > > >
> > > > > I guess initializing nunits to zero does not really solve the problem
> > > > > and while failing to identify all call sides (which isn't future-proof
> > > > > anyway), I went with adding a checking assert statement.  Bootstrapped
> > > > > and regtested on S/390.  Ok for master?
> > > >
> > > > You now have both, the atttribute and the assert.  The assert alone is 
> > > > OK.
> > >
> > > The assert alone is not enough.  For a release build we would again run
> > > into a warning.  Of course we could change gcc_checking_assert into
> > > gcc_assert.  However, then at least with no checking at all we would run
> > > again into the same warning.
> >
> > I see.
> >
> > > Using only the attribute in order to silence the warning, then we should
> > > be very clear that there exists no call side where ARGS equals NULL and
> > > where type_valid_for_vector_size returns a non-null value.  I was not
> > > able to show this.  Thus I went for both: attribute+assert.  Since the
> > > attribute is local to the compilation unit, the compiler has no chance
> > > to enforce this restriction at call sides.  If you think this will never
> > > happen, then we could just use patch from
> > > https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544774.html
> > > or the very initial patch which just checks for args being NULL
> > > https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544691.html
> > >
> > > What do you prefer?
> >
> > The last posted patch with the assert and the attribute is OK then.
>
> Pushed it to master.  Is this Ok for releases/gcc-10 branch, too?

Please wait until after the 10.1 release for these changes, they are
harmless since in release mode we do not use -Werror.

Richard.

> Thanks, Stefan


Re: [PATCH][AArch64] Use __getauxval instead of getauxval in LSE detection code in libgcc

2020-05-06 Thread Richard Biener via Gcc-patches
On Wed, May 6, 2020 at 1:56 PM Kyrylo Tkachov  wrote:
>
>
>
> > -Original Message-
> > From: Kyrylo Tkachov
> > Sent: 06 May 2020 11:40
> > To: Florian Weimer 
> > Cc: Joseph Myers ; Szabolcs Nagy
> > ; gcc-patches@gcc.gnu.org; Jakub Jelinek
> > ; Richard Biener 
> > Subject: RE: [PATCH][AArch64] Use __getauxval instead of getauxval in LSE
> > detection code in libgcc
> >
> >
> >
> > > -Original Message-
> > > From: Florian Weimer 
> > > Sent: 06 May 2020 11:28
> > > To: Kyrylo Tkachov 
> > > Cc: Joseph Myers ; Szabolcs Nagy
> > > ; gcc-patches@gcc.gnu.org; Jakub Jelinek
> > > ; Richard Biener 
> > > Subject: Re: [PATCH][AArch64] Use __getauxval instead of getauxval in LSE
> > > detection code in libgcc
> > >
> > > * Kyrylo Tkachov:
> > >
> > > > diff --git a/libgcc/config/aarch64/lse-init.c 
> > > > b/libgcc/config/aarch64/lse-
> > init.c
> > > > index 74acef25cce..57236610468 100644
> > > > --- a/libgcc/config/aarch64/lse-init.c
> > > > +++ b/libgcc/config/aarch64/lse-init.c
> > > > @@ -29,19 +29,20 @@ see the files COPYING3 and COPYING.RUNTIME
> > > respectively.  If not, see
> > > >  _Bool __aarch64_have_lse_atomics
> > > >__attribute__((visibility("hidden"), nocommon));
> > > >
> > > > -/* Disable initialization of __aarch64_have_lse_atomics during 
> > > > bootstrap.
> > > */
> > > > -#if !defined(inhibit_libc) && defined(HAVE_SYS_AUXV_H)
> > > > -# include 
> > > > +/* Gate availability of __getauxval on glibc.  All AArch64-supporting 
> > > > glibc
> > > > +   versions support it.  */
> > > > +#ifdef __gnu_linux__
> > > >
> > > > -/* Disable initialization if the system headers are too old.  */
> > > > -# if defined(AT_HWCAP) && defined(HWCAP_ATOMICS)
> > > > +# define AT_HWCAP16
> > > > +# define HWCAP_ATOMICS   (1 << 8)
> > > > +
> > > > +unsigned long __getauxval (unsigned long);
> > > >
> > > >  static void __attribute__((constructor))
> > > >  init_have_lse_atomics (void)
> > > >  {
> > > > -  unsigned long hwcap = getauxval (AT_HWCAP);
> > > > +  unsigned long hwcap = __getauxval (AT_HWCAP);
> > > >__aarch64_have_lse_atomics = (hwcap & HWCAP_ATOMICS) != 0;
> > > >  }
> > > >
> > > > -# endif /* HWCAP */
> > > > -#endif /* inhibit_libc */
> > > > +#endif /* __gnu_linux__  */
> > >
> > > GNU style is unsigned long int.
> >
> > Thanks, I'll fix that.
>
> Here is the updated patch for the record.
> Jakub, richi, is this ok for the GCC 10 branch?

I'll defer to Joseph who is release manager as well.

Thanks,
Richard.

> Thanks,
> Kyrill
>
> >
> > >
> > > Is __gnu_linux__ defined with musl?  It's not really GNU/Linux, after
> > > all.  musl doesn't have __getauxval IIRC, so it would break the build
> > > there.
> >
> > I don't think it does (at least not with a git grep for it in the musl 
> > code).
> > GCC doesn't define it for musl targets either. I see it defined for uclinux 
> > for
> > arm, not aarch64 though.
> >
> > Thanks,
> > Kyrill
> >
> > >
> > > (This is not a review of the patch. 8-)
> > >
> > > Thanks,
> > > Florian
>


Re: [PATCH] tree-ssa-structalias.c: Fix comments

2020-05-06 Thread Richard Biener via Gcc-patches
On Wed, May 6, 2020 at 1:07 PM Erick Ochoa
 wrote:
>
> This patch fixes some quotations inside comments. The change in syntax
> highlighting was bothering me. I also found a typo.

OK.

> ChangeLog:
>
> 2020-05-06  Erick Ochoa 
>
> * gcc/tree-ssa-struct-alias.c: Fix comments
>
>
> diff --git a/gcc/tree-ssa-structalias.c b/gcc/tree-ssa-structalias.c
> index 416a26c996c..37c9b8c26a1 100644
> --- a/gcc/tree-ssa-structalias.c
> +++ b/gcc/tree-ssa-structalias.c
> @@ -57,11 +57,11 @@
>  as a consequence.
>
>  See  "Efficient Field-sensitive pointer analysis for C" by "David
> -   J. Pearce and Paul H. J. Kelly and Chris Hankin, at
> +   J. Pearce and Paul H. J. Kelly and Chris Hankin", at
>  http://citeseer.ist.psu.edu/pearce04efficient.html
>
>  Also see "Ultra-fast Aliasing Analysis using CLA: A Million Lines
> -   of C Code in a Second" by ""Nevin Heintze and Olivier Tardieu" at
> +   of C Code in a Second" by "Nevin Heintze and Olivier Tardieu" at
>  http://citeseer.ist.psu.edu/heintze01ultrafast.html
>
>  There are three types of real constraint expressions, DEREF,
> @@ -84,7 +84,7 @@
>  Each variable for a structure field has
>
>  1. "size", that tells the size in bits of that field.
> -   2. "fullsize, that tells the size in bits of the entire structure.
> +   2. "fullsize", that tells the size in bits of the entire structure.
>  3. "offset", that tells the offset in bits from the beginning of the
>  structure to this field.
>
> @@ -188,7 +188,7 @@
>
>  We probably should compute a per-function unit-ESCAPE solution
>  propagating it simply like the clobber / uses solutions.  The
> -   solution can go alongside the non-IPA espaced solution and be
> +   solution can go alongside the non-IPA escaped solution and be
>  used to query which vars escape the unit through a function.
>  This is also required to make the escaped-HEAP trick work in IPA mode.
>


RE: [PATCH][AArch64] Use __getauxval instead of getauxval in LSE detection code in libgcc

2020-05-06 Thread Kyrylo Tkachov


> -Original Message-
> From: Kyrylo Tkachov
> Sent: 06 May 2020 11:40
> To: Florian Weimer 
> Cc: Joseph Myers ; Szabolcs Nagy
> ; gcc-patches@gcc.gnu.org; Jakub Jelinek
> ; Richard Biener 
> Subject: RE: [PATCH][AArch64] Use __getauxval instead of getauxval in LSE
> detection code in libgcc
> 
> 
> 
> > -Original Message-
> > From: Florian Weimer 
> > Sent: 06 May 2020 11:28
> > To: Kyrylo Tkachov 
> > Cc: Joseph Myers ; Szabolcs Nagy
> > ; gcc-patches@gcc.gnu.org; Jakub Jelinek
> > ; Richard Biener 
> > Subject: Re: [PATCH][AArch64] Use __getauxval instead of getauxval in LSE
> > detection code in libgcc
> >
> > * Kyrylo Tkachov:
> >
> > > diff --git a/libgcc/config/aarch64/lse-init.c b/libgcc/config/aarch64/lse-
> init.c
> > > index 74acef25cce..57236610468 100644
> > > --- a/libgcc/config/aarch64/lse-init.c
> > > +++ b/libgcc/config/aarch64/lse-init.c
> > > @@ -29,19 +29,20 @@ see the files COPYING3 and COPYING.RUNTIME
> > respectively.  If not, see
> > >  _Bool __aarch64_have_lse_atomics
> > >__attribute__((visibility("hidden"), nocommon));
> > >
> > > -/* Disable initialization of __aarch64_have_lse_atomics during bootstrap.
> > */
> > > -#if !defined(inhibit_libc) && defined(HAVE_SYS_AUXV_H)
> > > -# include 
> > > +/* Gate availability of __getauxval on glibc.  All AArch64-supporting 
> > > glibc
> > > +   versions support it.  */
> > > +#ifdef __gnu_linux__
> > >
> > > -/* Disable initialization if the system headers are too old.  */
> > > -# if defined(AT_HWCAP) && defined(HWCAP_ATOMICS)
> > > +# define AT_HWCAP16
> > > +# define HWCAP_ATOMICS   (1 << 8)
> > > +
> > > +unsigned long __getauxval (unsigned long);
> > >
> > >  static void __attribute__((constructor))
> > >  init_have_lse_atomics (void)
> > >  {
> > > -  unsigned long hwcap = getauxval (AT_HWCAP);
> > > +  unsigned long hwcap = __getauxval (AT_HWCAP);
> > >__aarch64_have_lse_atomics = (hwcap & HWCAP_ATOMICS) != 0;
> > >  }
> > >
> > > -# endif /* HWCAP */
> > > -#endif /* inhibit_libc */
> > > +#endif /* __gnu_linux__  */
> >
> > GNU style is unsigned long int.
> 
> Thanks, I'll fix that.

Here is the updated patch for the record.
Jakub, richi, is this ok for the GCC 10 branch? 
Thanks,
Kyrill

> 
> >
> > Is __gnu_linux__ defined with musl?  It's not really GNU/Linux, after
> > all.  musl doesn't have __getauxval IIRC, so it would break the build
> > there.
> 
> I don't think it does (at least not with a git grep for it in the musl code).
> GCC doesn't define it for musl targets either. I see it defined for uclinux 
> for
> arm, not aarch64 though.
> 
> Thanks,
> Kyrill
> 
> >
> > (This is not a review of the patch. 8-)
> >
> > Thanks,
> > Florian



ool-glibc.patch
Description: ool-glibc.patch


Re: [PATCH] aarch64: fix conflicting declarations

2020-05-06 Thread Richard Sandiford
Andreas Schwab  writes:
> aarch64_get_extension_string_for_isa_flags is declared in
> "aarch64-protos.h", use that instead of re-declaring it improperly.
>
>   * config/aarch64/driver-aarch64.c: Include "aarch64-protos.h".
>   (aarch64_get_extension_string_for_isa_flags): Don't declare.

OK, thanks.

Richard


[PATCH] tree-ssa-structalias.c: Fix comments

2020-05-06 Thread Erick Ochoa
This patch fixes some quotations inside comments. The change in syntax 
highlighting was bothering me. I also found a typo.


ChangeLog:

2020-05-06  Erick Ochoa 

* gcc/tree-ssa-struct-alias.c: Fix comments


diff --git a/gcc/tree-ssa-structalias.c b/gcc/tree-ssa-structalias.c
index 416a26c996c..37c9b8c26a1 100644
--- a/gcc/tree-ssa-structalias.c
+++ b/gcc/tree-ssa-structalias.c
@@ -57,11 +57,11 @@
as a consequence.

See  "Efficient Field-sensitive pointer analysis for C" by "David
-   J. Pearce and Paul H. J. Kelly and Chris Hankin, at
+   J. Pearce and Paul H. J. Kelly and Chris Hankin", at
http://citeseer.ist.psu.edu/pearce04efficient.html

Also see "Ultra-fast Aliasing Analysis using CLA: A Million Lines
-   of C Code in a Second" by ""Nevin Heintze and Olivier Tardieu" at
+   of C Code in a Second" by "Nevin Heintze and Olivier Tardieu" at
http://citeseer.ist.psu.edu/heintze01ultrafast.html

There are three types of real constraint expressions, DEREF,
@@ -84,7 +84,7 @@
Each variable for a structure field has

1. "size", that tells the size in bits of that field.
-   2. "fullsize, that tells the size in bits of the entire structure.
+   2. "fullsize", that tells the size in bits of the entire structure.
3. "offset", that tells the offset in bits from the beginning of the
structure to this field.

@@ -188,7 +188,7 @@

We probably should compute a per-function unit-ESCAPE solution
propagating it simply like the clobber / uses solutions.  The
-   solution can go alongside the non-IPA espaced solution and be
+   solution can go alongside the non-IPA escaped solution and be
used to query which vars escape the unit through a function.
This is also required to make the escaped-HEAP trick work in IPA mode.



RE: [PATCH][AArch64] Use __getauxval instead of getauxval in LSE detection code in libgcc

2020-05-06 Thread Kyrylo Tkachov



> -Original Message-
> From: Florian Weimer 
> Sent: 06 May 2020 11:28
> To: Kyrylo Tkachov 
> Cc: Joseph Myers ; Szabolcs Nagy
> ; gcc-patches@gcc.gnu.org; Jakub Jelinek
> ; Richard Biener 
> Subject: Re: [PATCH][AArch64] Use __getauxval instead of getauxval in LSE
> detection code in libgcc
> 
> * Kyrylo Tkachov:
> 
> > diff --git a/libgcc/config/aarch64/lse-init.c 
> > b/libgcc/config/aarch64/lse-init.c
> > index 74acef25cce..57236610468 100644
> > --- a/libgcc/config/aarch64/lse-init.c
> > +++ b/libgcc/config/aarch64/lse-init.c
> > @@ -29,19 +29,20 @@ see the files COPYING3 and COPYING.RUNTIME
> respectively.  If not, see
> >  _Bool __aarch64_have_lse_atomics
> >__attribute__((visibility("hidden"), nocommon));
> >
> > -/* Disable initialization of __aarch64_have_lse_atomics during bootstrap.
> */
> > -#if !defined(inhibit_libc) && defined(HAVE_SYS_AUXV_H)
> > -# include 
> > +/* Gate availability of __getauxval on glibc.  All AArch64-supporting glibc
> > +   versions support it.  */
> > +#ifdef __gnu_linux__
> >
> > -/* Disable initialization if the system headers are too old.  */
> > -# if defined(AT_HWCAP) && defined(HWCAP_ATOMICS)
> > +# define AT_HWCAP  16
> > +# define HWCAP_ATOMICS (1 << 8)
> > +
> > +unsigned long __getauxval (unsigned long);
> >
> >  static void __attribute__((constructor))
> >  init_have_lse_atomics (void)
> >  {
> > -  unsigned long hwcap = getauxval (AT_HWCAP);
> > +  unsigned long hwcap = __getauxval (AT_HWCAP);
> >__aarch64_have_lse_atomics = (hwcap & HWCAP_ATOMICS) != 0;
> >  }
> >
> > -# endif /* HWCAP */
> > -#endif /* inhibit_libc */
> > +#endif /* __gnu_linux__  */
> 
> GNU style is unsigned long int.

Thanks, I'll fix that.

> 
> Is __gnu_linux__ defined with musl?  It's not really GNU/Linux, after
> all.  musl doesn't have __getauxval IIRC, so it would break the build
> there.

I don't think it does (at least not with a git grep for it in the musl code).
GCC doesn't define it for musl targets either. I see it defined for uclinux for 
arm, not aarch64 though.

Thanks,
Kyrill

> 
> (This is not a review of the patch. 8-)
> 
> Thanks,
> Florian



[PATCH] middle-end/94964 - avoid EH loop entry with CP_SIMPLE_PREHEADERS

2020-05-06 Thread Richard Biener


Loop optimizers expect to be able to insert on the preheader
edge w/o splitting it thus avoid ending up with a preheader
that enters the loop via an EH edge (or an abnormal edge).

Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.

Richard.

2020-05-06  Richard Biener  

PR middle-end/94964
* cfgloopmanip.c (create_preheader): Require non-complex
preheader edge for CP_SIMPLE_PREHEADERS.
---
 gcc/cfgloopmanip.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/gcc/cfgloopmanip.c b/gcc/cfgloopmanip.c
index 50c7267ec49..73134a20e33 100644
--- a/gcc/cfgloopmanip.c
+++ b/gcc/cfgloopmanip.c
@@ -1506,9 +1506,10 @@ create_preheader (class loop *loop, int flags)
   else
 {
   /* If we want simple preheaders, also force the preheader to have
- just a single successor.  */
+just a single successor and a normal edge.  */
   if ((flags & CP_SIMPLE_PREHEADERS)
-  && !single_succ_p (single_entry->src))
+ && ((single_entry->flags & EDGE_COMPLEX)
+ || !single_succ_p (single_entry->src)))
 need_forwarder_block = true;
   /* If we want fallthru preheaders, also create forwarder block when
  preheader ends with a jump or has predecessors from loop.  */
-- 
2.25.1


[PATCH] tree-optimization/94963 - avoid bogus uninit warning with store-motion

2020-05-06 Thread Richard Biener


Eliding the load for store-motion causes an uninitialized variable
flowing into the loop, conditionally initialized and used.  The
uninit warning cannot relate the flag used to guard the initialization
and use with the actual initialization so the following robustifies
the previous approach of marking the conditional store as not to
be warned on by instead initializing the variable on loop entry
from an uninitialized variable we mark as not to be warned for.

Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.

Richard.

2020-05-06  Richard Biener  

PR tree-optimization/94963
* tree-ssa-loop-im.c (execute_sm_if_changed): Remove
no-warning marking of the conditional store.
(execute_sm): Instead mark the uninitialized state
on loop entry to be not warned about.

* gcc.dg/pr94963.c: New testcase.
---
 gcc/testsuite/gcc.dg/pr94963.c | 35 +++
 gcc/tree-ssa-loop-im.c | 18 +++---
 2 files changed, 46 insertions(+), 7 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/pr94963.c

diff --git a/gcc/testsuite/gcc.dg/pr94963.c b/gcc/testsuite/gcc.dg/pr94963.c
new file mode 100644
index 000..aca9e161301
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr94963.c
@@ -0,0 +1,35 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -Wall" } */
+
+typedef struct
+{
+  int p1;
+  int p2;
+  int p3;
+} P;
+struct S
+{
+  int field;
+};
+extern int v2;
+extern void foo (struct S *map);
+static struct S var;
+const P *pv;
+int ps;
+void
+f (void)
+{
+  if (pv != 0)
+for (const P *ph = pv; ph < [ps]; ++ph)
+  switch (ph->p1)
+   {
+   case 1:
+   v2 = ph->p2;
+   break;
+   case 2:
+   var.field = ph->p3;
+   break;
+   }
+  if (var.field != 0) /* { dg-bogus "uninitialized" } */
+foo ();
+}
diff --git a/gcc/tree-ssa-loop-im.c b/gcc/tree-ssa-loop-im.c
index 554dd4be5bb..3056b4bfed2 100644
--- a/gcc/tree-ssa-loop-im.c
+++ b/gcc/tree-ssa-loop-im.c
@@ -1994,8 +1994,6 @@ execute_sm_if_changed (edge ex, tree mem, tree tmp_var, 
tree flag,
   gsi = gsi_start_bb (then_bb);
   /* Insert actual store.  */
   stmt = gimple_build_assign (unshare_expr (mem), tmp_var);
-  /* Make sure to not warn about maybe-uninit uses of tmp_var here.  */
-  gimple_set_no_warning (stmt, true);
   gsi_insert_after (, stmt, GSI_CONTINUE_LINKING);
 
   edge e1 = single_succ_edge (new_bb);
@@ -2149,13 +2147,19 @@ execute_sm (class loop *loop, vec exits, 
im_mem_ref *ref)
  store then.  */
   if ((!always_stored && !multi_threaded_model_p)
   || (ref->loaded && bitmap_bit_p (ref->loaded, loop->num)))
+load = gimple_build_assign (tmp_var, unshare_expr (ref->mem.ref));
+  else
 {
-  load = gimple_build_assign (tmp_var, unshare_expr (ref->mem.ref));
-  lim_data = init_lim_data (load);
-  lim_data->max_loop = loop;
-  lim_data->tgt_loop = loop;
-  gsi_insert_before (, load, GSI_SAME_STMT);
+  /* If not emitting a load mark the uninitialized state on the
+loop entry as not to be warned for.  */
+  tree uninit = create_tmp_reg (TREE_TYPE (tmp_var));
+  TREE_NO_WARNING (uninit) = 1;
+  load = gimple_build_assign (tmp_var, uninit);
 }
+  lim_data = init_lim_data (load);
+  lim_data->max_loop = loop;
+  lim_data->tgt_loop = loop;
+  gsi_insert_before (, load, GSI_SAME_STMT);
 
   if (multi_threaded_model_p)
 {
-- 
2.12.3


Re: [PATCH] aarch64: prefer using csinv, csneg in zero extend contexts

2020-05-06 Thread Richard Sandiford
Alex Coplan  writes:
>> -Original Message-
>> From: Richard Sandiford 
>> Sent: 30 April 2020 15:13
>> To: Alex Coplan 
>> Cc: gcc-patches@gcc.gnu.org; Richard Earnshaw ;
>> Marcus Shawcroft ; Kyrylo Tkachov
>> ; nd 
>> Subject: Re: [PATCH] aarch64: prefer using csinv, csneg in zero extend 
>> contexts
>> 
>> Yeah, I was hoping for something like...
>> 
>> > Indeed, clang generates a MVN + CSEL sequence where the CSEL operates on 
>> > the
>> > 64-bit registers:
>> >
>> > f:
>> > mvn w8, w2
>> > cmp w0, #0
>> > cselx0, x8, x1, eq
>> > ret
>> 
>> ...this rather than the 4-insn (+ret) sequence that we currently
>> generate.  So it would have been a define_insn_and_split that handles
>> the zero case directly but splits into the "optimal" two-instruction
>> sequence for registers.
>> 
>> But I guess the underlying problem is instead that we don't have
>> a pattern for (zero_extend:DI (not:SI ...)).  Adding that would
>> definitely be a better fix.
>
> Yes. I sent a patch for this very fix which Kyrill is going to commit once 
> stage
> 1 opens: https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544365.html

Sorry, missed that.

It looks like that patch hinders this one though.  Trying it with
current master (where that patch is applied), I get:

FAIL: gcc.target/aarch64/csinv-neg.c check-function-bodies inv_zero1
FAIL: gcc.target/aarch64/csinv-neg.c check-function-bodies inv_zero2

It looks like a costs issue:

Trying 27 -> 18:
   27: r99:DI=zero_extend(~r101:SI)
  REG_DEAD r101:SI
   18: x0:DI={(cc:CC==0)?r99:DI:0}
  REG_DEAD cc:CC
  REG_DEAD r99:DI
Successfully matched this instruction:
(set (reg/i:DI 0 x0)
(if_then_else:DI (eq (reg:CC 66 cc)
(const_int 0 [0]))
(zero_extend:DI (not:SI (reg:SI 101)))
(const_int 0 [0])))
rejecting combination of insns 27 and 18
original costs 4 + 4 = 8
replacement cost 12

I guess we'll need to teach aarch64_if_then_else_costs about the costs
of the new insns.

Thanks,
Richard


Re: [PATCH][AArch64] Use __getauxval instead of getauxval in LSE detection code in libgcc

2020-05-06 Thread Florian Weimer via Gcc-patches
* Kyrylo Tkachov:

> diff --git a/libgcc/config/aarch64/lse-init.c 
> b/libgcc/config/aarch64/lse-init.c
> index 74acef25cce..57236610468 100644
> --- a/libgcc/config/aarch64/lse-init.c
> +++ b/libgcc/config/aarch64/lse-init.c
> @@ -29,19 +29,20 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  
> If not, see
>  _Bool __aarch64_have_lse_atomics
>__attribute__((visibility("hidden"), nocommon));
>  
> -/* Disable initialization of __aarch64_have_lse_atomics during bootstrap.  */
> -#if !defined(inhibit_libc) && defined(HAVE_SYS_AUXV_H)
> -# include 
> +/* Gate availability of __getauxval on glibc.  All AArch64-supporting glibc
> +   versions support it.  */
> +#ifdef __gnu_linux__
>  
> -/* Disable initialization if the system headers are too old.  */
> -# if defined(AT_HWCAP) && defined(HWCAP_ATOMICS)
> +# define AT_HWCAP16
> +# define HWCAP_ATOMICS   (1 << 8)
> +
> +unsigned long __getauxval (unsigned long);
>  
>  static void __attribute__((constructor))
>  init_have_lse_atomics (void)
>  {
> -  unsigned long hwcap = getauxval (AT_HWCAP);
> +  unsigned long hwcap = __getauxval (AT_HWCAP);
>__aarch64_have_lse_atomics = (hwcap & HWCAP_ATOMICS) != 0;
>  }
>  
> -# endif /* HWCAP */
> -#endif /* inhibit_libc */
> +#endif /* __gnu_linux__  */

GNU style is unsigned long int.

Is __gnu_linux__ defined with musl?  It's not really GNU/Linux, after
all.  musl doesn't have __getauxval IIRC, so it would break the build
there.

(This is not a review of the patch. 8-)

Thanks,
Florian



Re: [PATCH 4/4] Use const for template argument.

2020-05-06 Thread Jonathan Wakely via Gcc-patches

On 04/02/20 14:55 +0100, Martin Liska wrote:

diff --git a/libstdc++-v3/include/parallel/multiway_merge.h 
b/libstdc++-v3/include/parallel/multiway_merge.h
index 983c7b2bd9a..97a9ce0feb7 100644
--- a/libstdc++-v3/include/parallel/multiway_merge.h
+++ b/libstdc++-v3/include/parallel/multiway_merge.h
@@ -118,7 +118,7 @@ namespace __gnu_parallel
   *  @return @c true if less. */
  friend bool
  operator<(_GuardedIterator<_RAIter, _Compare>& __bi1,
-   _GuardedIterator<_RAIter, _Compare>& __bi2)
+   _GuardedIterator<_RAIter, const _Compare>& __bi2)
  {
   if (__bi1._M_current == __bi1._M_end)   // __bi1 is sup
 return __bi2._M_current == __bi2._M_end;  // __bi2 is not sup
@@ -188,7 +188,7 @@ namespace __gnu_parallel
   *  @return @c true if less. */
  friend bool
  operator<(_UnguardedIterator<_RAIter, _Compare>& __bi1,
-   _UnguardedIterator<_RAIter, _Compare>& __bi2)
+   _UnguardedIterator<_RAIter, const _Compare>& __bi2)
  {
   // Normal compare.
   return (__bi1.__comp)(*__bi1, *__bi2);



This is completely bogus, please revert.

The cppcheck warning is saying that it could be:

const _UnguardedIterator<_RAIter, _Compare>&

which is completely different from:

_UnguardedIterator<_RAIter, const _Compare>&

Also both parameters of operator< should have been changed, not just
one, and operator<= should have the same change.

But cppcheck is completely wrong anyway. The operator* member of
_GuardedIterator and _UnguardedIterator is not const, so trying to
dereference *__b1 and *__b2 would fail.

Nack nack nack.



RE: [PATCH][AArch64] Use __getauxval instead of getauxval in LSE detection code in libgcc

2020-05-06 Thread Kyrylo Tkachov


> -Original Message-
> From: Joseph Myers 
> Sent: 05 May 2020 22:30
> To: Kyrylo Tkachov 
> Cc: Szabolcs Nagy ; Florian Weimer
> ; gcc-patches@gcc.gnu.org
> Subject: RE: [PATCH][AArch64] Use __getauxval instead of getauxval in LSE
> detection code in libgcc
> 
> On Tue, 5 May 2020, Kyrylo Tkachov wrote:
> 
> > This version of the fix uses __getauxval instead of getauxval.
> > The whole thing is guarded simply on __GLIBC__ >= 2.
> > __getauxval was introduced in 2.16 but the aarch64 port was added in 2.17
> so in practice I expect all aarch64 glibcs to support __getauxval.
> 
> Testing __GLIBC__ doesn't work because that's only defined in headers and
> the point of duplicating definitions here is to avoid libgcc and thus libc
> contents depending on whether headers were available when libgcc was
> built.  However, given your point that the AArch64 glibc port postdates
> the addition of __getauxval to glibc, you can test __gnu_linux__ instead,
> as a macro GCC predefines only when configured to use glibc on the target,
> and don't need a version test after all.

Right, thanks for the pointer.
This version of the fix uses __getauxval instead of getauxval.
The whole thing is guarded simply on __gnu_linux__.
__getauxval was introduced in 2.16 but the aarch64 port was added in 2.17 so in 
practice I expect all aarch64 glibcs to support __getauxval.

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

Checked that the lse-init.o binary contains the __getauxval call for 
aarch64-none-linux-gnu and is empty for aarch64-none-elf (a newlib target).
Is this okay for trunk and the GCC 10 branch?

Thanks,
Kyrill

2020-05-06  Kyrylo Tkachov  

* config/aarch64/lse-init.c (init_have_lse_atomics): Use __getauxval
instead of getauxval.
(AT_HWCAP): Define.
(HWCAP_ATOMICS): Define.
Guard detection on __gnu_linux__.

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


ool-glibc.patch
Description: ool-glibc.patch


Re: [PATCH] Add enqcmd, avx512bf16, avx512vp2intersect to funcspec-56.inc

2020-05-06 Thread Uros Bizjak via Gcc-patches
On Wed, May 6, 2020 at 11:08 AM Hongtao Liu  wrote:
>
> Hi:
>   Test is ok for funcspec-5.c, funcspec-6.c.
>
> gcc/testuite/ChangeLog
> * gcc.target/i386/funcspec-56.inc: Add enqcmd, avx512bf16,
> avx512vp2intersect.

OK.

Thanks,
Uros.

>  gcc/testsuite/gcc.target/i386/funcspec-56.inc | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/gcc/testsuite/gcc.target/i386/funcspec-56.inc
> b/gcc/testsuite/gcc.target/i386/funcspec-56.inc
> index 0053b5386fc..9fe4a21984b 100644
> --- a/gcc/testsuite/gcc.target/i386/funcspec-56.inc
> +++ b/gcc/testsuite/gcc.target/i386/funcspec-56.inc
> @@ -68,6 +68,9 @@ extern void test_cld (void)
> __attribute__((__target__("cld")));
>  extern void test_recip (void) __attribute__((__target__("recip")));
>  extern void test_serialize (void) __attribute__((__target__("serialize")));
>  extern void test_tsxldtrk (void) __attribute__((__target__("tsxldtrk")));
> +extern void test_enqcmd (void) __attribute__((__target__("enqcmd")));
> +extern void test_avx512bf16 (void) __attribute__((__target__("avx512bf16")));
> +extern void test_avx512vp2intersect (void)
> __attribute__((__target__("avx512vp2intersect")));
>
>  extern void test_no_sgx (void) __attribute__((__target__("no-sgx")));
>  extern void test_no_avx5124fmaps(void)
> __attribute__((__target__("no-avx5124fmaps")));
> @@ -137,6 +140,9 @@ extern void test_no_cld (void)
> __attribute__((__target__("no-cld")));
>  extern void test_no_recip (void) __attribute__((__target__("no-recip")));
>  extern void test_no_serialize (void)
> __attribute__((__target__("no-serialize")));
>  extern void test_no_tsxldtrk (void) 
> __attribute__((__target__("no-tsxldtrk")));
> +extern void test_no_enqcmd (void) __attribute__((__target__("no-enqcmd")));
> +extern void test_no_avx512bf16 (void)
> __attribute__((__target__("no-avx512bf16")));
> +extern void test_no_avx512vp2intersect (void)
> __attribute__((__target__("no-avx512vp2intersect")));
>
>  extern void test_arch_nocona (void) 
> __attribute__((__target__("arch=nocona")));
>  extern void test_arch_core2 (void) __attribute__((__target__("arch=core2")));
>
>
> --
> BR,
> Hongtao


Re: [PATCH] libstdc++: Update {x86_64,i?86,powerpc64,s390x,aarch64}-linux baselines for GCC 10.1

2020-05-06 Thread Jonathan Wakely via Gcc-patches

On 06/05/20 10:15 +0100, Jonathan Wakely wrote:

On 06/05/20 11:09 +0200, Jakub Jelinek via Libstdc++ wrote:

On Wed, May 06, 2020 at 10:49:13AM +0200, Rainer Orth wrote:

I just remembered that the libstdc++ ABI baselines haven't been updated
for the GCC 10 release yet.  This patch corrects this for Solaris/SPARC
and x86.


Oops, here are the updates from Fedora packages built during the weekend.
Ok for trunk and gcc-10?


Yes, these all look right. Thanks.


And this updates the manual on master. I'll backport this as well.

commit 2b6f6aeea1846116d6f1f0c3d9ccdd9cc151b385
Author: Jonathan Wakely 
Date:   Wed May 6 10:30:15 2020 +0100

libstdc++: Document library versioning for 9.[123] and 10.1

* doc/xml/manual/abi.xml (abi.versioning.history): Document library
versions for GCC 9.[123] and 10.1 releases.
* doc/html/*: Regenerate.

diff --git a/libstdc++-v3/doc/xml/manual/abi.xml b/libstdc++-v3/doc/xml/manual/abi.xml
index 969edd7c834..7aec810d45f 100644
--- a/libstdc++-v3/doc/xml/manual/abi.xml
+++ b/libstdc++-v3/doc/xml/manual/abi.xml
@@ -267,10 +267,11 @@ compatible.
 GCC 6.1.0: libstdc++.so.6.0.22
 GCC 7.1.0: libstdc++.so.6.0.23
 GCC 7.2.0: libstdc++.so.6.0.24
-GCC 8.0.0: libstdc++.so.6.0.25
+GCC 8.1.0: libstdc++.so.6.0.25
 GCC 9.1.0: libstdc++.so.6.0.26
 GCC 9.2.0: libstdc++.so.6.0.27
 GCC 9.3.0: libstdc++.so.6.0.28
+GCC 10.1.0: libstdc++.so.6.0.28
 
 
   Note 1: Error should be libstdc++.so.3.0.3.
@@ -340,8 +341,12 @@ compatible.
 GCC 6.1.0: GLIBCXX_3.4.22, CXXABI_1.3.10
 GCC 7.1.0: GLIBCXX_3.4.23, CXXABI_1.3.11
 GCC 7.2.0: GLIBCXX_3.4.24, CXXABI_1.3.11
-GCC 8.0.0: GLIBCXX_3.4.25, CXXABI_1.3.11
-GCC 9.0.0: GLIBCXX_3.4.26, CXXABI_1.3.11
+GCC 8.1.0: GLIBCXX_3.4.25, CXXABI_1.3.11
+GCC 9.1.0: GLIBCXX_3.4.26, CXXABI_1.3.12
+GCC 9.2.0: GLIBCXX_3.4.27, CXXABI_1.3.12
+GCC 9.3.0: GLIBCXX_3.4.28, CXXABI_1.3.12
+GCC 10.1.0: GLIBCXX_3.4.28, CXXABI_1.3.12
+
 
 
 


Re: [PATCH] libstdc++: Update {x86_64,i?86,powerpc64,s390x,aarch64}-linux baselines for GCC 10.1

2020-05-06 Thread Jonathan Wakely via Gcc-patches

On 06/05/20 11:09 +0200, Jakub Jelinek via Libstdc++ wrote:

On Wed, May 06, 2020 at 10:49:13AM +0200, Rainer Orth wrote:

I just remembered that the libstdc++ ABI baselines haven't been updated
for the GCC 10 release yet.  This patch corrects this for Solaris/SPARC
and x86.


Oops, here are the updates from Fedora packages built during the weekend.
Ok for trunk and gcc-10?


Yes, these all look right. Thanks.



[PATCH] libstdc++: Update {x86_64,i?86,powerpc64,s390x,aarch64}-linux baselines for GCC 10.1

2020-05-06 Thread Jakub Jelinek via Gcc-patches
On Wed, May 06, 2020 at 10:49:13AM +0200, Rainer Orth wrote:
> I just remembered that the libstdc++ ABI baselines haven't been updated
> for the GCC 10 release yet.  This patch corrects this for Solaris/SPARC
> and x86.

Oops, here are the updates from Fedora packages built during the weekend.
Ok for trunk and gcc-10?

2020-05-06  Jakub Jelinek  

* config/abi/post/x86_64-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/x86_64-linux-gnu/32/baseline_symbols.txt: Update.
* config/abi/post/i386-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/i486-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/aarch64-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/s390x-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/powerpc64-linux-gnu/baseline_symbols.txt: Update.

--- libstdc++-v3/config/abi/post/x86_64-linux-gnu/baseline_symbols.txt.jj   
2020-01-12 11:54:39.860361404 +0100
+++ libstdc++-v3/config/abi/post/x86_64-linux-gnu/baseline_symbols.txt  
2020-05-06 10:54:52.811966688 +0200
@@ -2062,16 +2062,20 @@ FUNC:_ZNSt12__basic_fileIcED1Ev@@GLIBCXX
 FUNC:_ZNSt12__basic_fileIcED2Ev@@GLIBCXX_3.4
 
FUNC:_ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1EOS5_@@GLIBCXX_3.4.26
 
FUNC:_ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1Ev@@GLIBCXX_3.4.26
+FUNC:_ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC2EOS5_@@GLIBCXX_3.4.28
 
FUNC:_ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC2Ev@@GLIBCXX_3.4.27
 
FUNC:_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEC1EOS4_@@GLIBCXX_3.4.26
 
FUNC:_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEC1Ev@@GLIBCXX_3.4.26
+FUNC:_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEC2EOS4_@@GLIBCXX_3.4.28
 
FUNC:_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEC2Ev@@GLIBCXX_3.4.27
 
FUNC:_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEaSEOS4_@@GLIBCXX_3.4.26
 
FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1EOS6_@@GLIBCXX_3.4.26
 
FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1Ev@@GLIBCXX_3.4.26
+FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC2EOS6_@@GLIBCXX_3.4.28
 
FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC2Ev@@GLIBCXX_3.4.27
 
FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC1EOS5_@@GLIBCXX_3.4.26
 
FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC1Ev@@GLIBCXX_3.4.26
+FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC2EOS5_@@GLIBCXX_3.4.28
 
FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC2Ev@@GLIBCXX_3.4.27
 
FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEaSEOS5_@@GLIBCXX_3.4.26
 FUNC:_ZNSt12bad_weak_ptrD0Ev@@GLIBCXX_3.4.15
@@ -3001,12 +3005,18 @@ FUNC:_ZNSt3_V214error_categoryD1Ev@@GLIB
 FUNC:_ZNSt3_V214error_categoryD2Ev@@GLIBCXX_3.4.21
 FUNC:_ZNSt3_V215system_categoryEv@@GLIBCXX_3.4.21
 FUNC:_ZNSt3_V216generic_categoryEv@@GLIBCXX_3.4.21
+FUNC:_ZNSt3pmr15memory_resourceD0Ev@@GLIBCXX_3.4.28
+FUNC:_ZNSt3pmr15memory_resourceD1Ev@@GLIBCXX_3.4.28
+FUNC:_ZNSt3pmr15memory_resourceD2Ev@@GLIBCXX_3.4.28
 FUNC:_ZNSt3pmr19new_delete_resourceEv@@GLIBCXX_3.4.26
 FUNC:_ZNSt3pmr20get_default_resourceEv@@GLIBCXX_3.4.26
 FUNC:_ZNSt3pmr20null_memory_resourceEv@@GLIBCXX_3.4.26
 FUNC:_ZNSt3pmr20set_default_resourceEPNS_15memory_resourceE@@GLIBCXX_3.4.26
 FUNC:_ZNSt3pmr25monotonic_buffer_resource13_M_new_bufferEmm@@GLIBCXX_3.4.26
 FUNC:_ZNSt3pmr25monotonic_buffer_resource18_M_release_buffersEv@@GLIBCXX_3.4.26
+FUNC:_ZNSt3pmr25monotonic_buffer_resourceD0Ev@@GLIBCXX_3.4.28
+FUNC:_ZNSt3pmr25monotonic_buffer_resourceD1Ev@@GLIBCXX_3.4.28
+FUNC:_ZNSt3pmr25monotonic_buffer_resourceD2Ev@@GLIBCXX_3.4.28
 FUNC:_ZNSt3pmr26synchronized_pool_resource11do_allocateEmm@@GLIBCXX_3.4.26
 FUNC:_ZNSt3pmr26synchronized_pool_resource13do_deallocateEPvmm@@GLIBCXX_3.4.26
 FUNC:_ZNSt3pmr26synchronized_pool_resource7releaseEv@@GLIBCXX_3.4.26
@@ -4409,6 +4419,7 @@ OBJECT:0:GLIBCXX_3.4.24
 OBJECT:0:GLIBCXX_3.4.25
 OBJECT:0:GLIBCXX_3.4.26
 OBJECT:0:GLIBCXX_3.4.27
+OBJECT:0:GLIBCXX_3.4.28
 OBJECT:0:GLIBCXX_3.4.3
 OBJECT:0:GLIBCXX_3.4.4
 OBJECT:0:GLIBCXX_3.4.5
@@ -4493,6 +4504,7 @@ OBJECT:16:_ZTIN10__cxxabiv119__foreign_e
 OBJECT:16:_ZTINSt13__future_base11_State_baseE@@GLIBCXX_3.4.15
 

[PATCH] Add enqcmd,avx512bf16,avx512vp2intersect to funcspec-56.inc

2020-05-06 Thread Hongtao Liu via Gcc-patches
Hi:
  Test is ok for funcspec-5.c, funcspec-6.c.

gcc/testuite/ChangeLog
* gcc.target/i386/funcspec-56.inc: Add enqcmd, avx512bf16,
avx512vp2intersect.

 gcc/testsuite/gcc.target/i386/funcspec-56.inc | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/gcc/testsuite/gcc.target/i386/funcspec-56.inc
b/gcc/testsuite/gcc.target/i386/funcspec-56.inc
index 0053b5386fc..9fe4a21984b 100644
--- a/gcc/testsuite/gcc.target/i386/funcspec-56.inc
+++ b/gcc/testsuite/gcc.target/i386/funcspec-56.inc
@@ -68,6 +68,9 @@ extern void test_cld (void)
__attribute__((__target__("cld")));
 extern void test_recip (void) __attribute__((__target__("recip")));
 extern void test_serialize (void) __attribute__((__target__("serialize")));
 extern void test_tsxldtrk (void) __attribute__((__target__("tsxldtrk")));
+extern void test_enqcmd (void) __attribute__((__target__("enqcmd")));
+extern void test_avx512bf16 (void) __attribute__((__target__("avx512bf16")));
+extern void test_avx512vp2intersect (void)
__attribute__((__target__("avx512vp2intersect")));

 extern void test_no_sgx (void) __attribute__((__target__("no-sgx")));
 extern void test_no_avx5124fmaps(void)
__attribute__((__target__("no-avx5124fmaps")));
@@ -137,6 +140,9 @@ extern void test_no_cld (void)
__attribute__((__target__("no-cld")));
 extern void test_no_recip (void) __attribute__((__target__("no-recip")));
 extern void test_no_serialize (void)
__attribute__((__target__("no-serialize")));
 extern void test_no_tsxldtrk (void) __attribute__((__target__("no-tsxldtrk")));
+extern void test_no_enqcmd (void) __attribute__((__target__("no-enqcmd")));
+extern void test_no_avx512bf16 (void)
__attribute__((__target__("no-avx512bf16")));
+extern void test_no_avx512vp2intersect (void)
__attribute__((__target__("no-avx512vp2intersect")));

 extern void test_arch_nocona (void) __attribute__((__target__("arch=nocona")));
 extern void test_arch_core2 (void) __attribute__((__target__("arch=core2")));


-- 
BR,
Hongtao


Re: [PATCH] match.pd: Optimize ~(~X +- Y) into (X -+ Y) [PR94921]

2020-05-06 Thread Richard Biener
On Wed, 6 May 2020, Jakub Jelinek wrote:

> Hi!
> 
> According to my verification proglet, this transformation for signed types
> with undefined overflow doesn't introduce nor remove any UB cases, so should
> be valid even for signed integral types.
> Not using a for because of the :c on plus which can't be there on minus.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

OK.

Thanks,
Richard.

> 2020-05-06  Jakub Jelinek  
> 
>   PR tree-optimization/94921
>   * match.pd (~(~X - Y) -> X + Y, ~(~X + Y) -> X - Y): New
>   simplifications.
> 
>   * gcc.dg/tree-ssa/pr94921.c: New test.
> 
> --- gcc/match.pd.jj   2020-05-05 11:36:17.510911674 +0200
> +++ gcc/match.pd  2020-05-05 16:48:59.496883197 +0200
> @@ -1010,6 +1010,14 @@ (define_operator_list COND_TERNARY
>@0))
>  #endif
>  
> +/* ~(~X - Y) -> X + Y and ~(~X + Y) -> X - Y.  */
> +(simplify
> + (bit_not (minus (bit_not @0) @1))
> + (plus @0 @1))
> +(simplify
> + (bit_not (plus:c (bit_not @0) @1))
> + (minus @0 @1))
> +
>  /* x + (x & 1) -> (x + 1) & ~1 */
>  (simplify
>   (plus:c @0 (bit_and:s @0 integer_onep@1))
> --- gcc/testsuite/gcc.dg/tree-ssa/pr94921.c.jj2020-05-05 
> 16:58:32.913192128 +0200
> +++ gcc/testsuite/gcc.dg/tree-ssa/pr94921.c   2020-05-05 16:59:26.231384053 
> +0200
> @@ -0,0 +1,18 @@
> +/* PR tree-optimization/94921 */
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -fdump-tree-optimized" } */
> +/* { dg-final { scan-tree-dump " \[ab]_\[0-9]+\\\(D\\\) \\+ 
> \[ab]_\[0-9]+\\\(D\\\);" "optimized" } } */
> +/* { dg-final { scan-tree-dump " c_\[0-9]+\\\(D\\\) - d_\[0-9]+\\\(D\\\);" 
> "optimized" } } */
> +/* { dg-final { scan-tree-dump-not " ~\[abcd]\?_\[0-9]\+" "optimized" } } */
> +
> +int
> +foo (int a, int b)
> +{
> +  return ~(~a - b);
> +}
> +
> +int
> +bar (int c, int d)
> +{
> +  return ~(~c + d);
> +}
> 
>   Jakub
> 
> 

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


Re: [PATCH] libstdc++: Update Solaris baselines for GCC 10.1

2020-05-06 Thread Jakub Jelinek via Gcc-patches
On Wed, May 06, 2020 at 10:00:02AM +0100, Jonathan Wakely wrote:
> On 06/05/20 10:49 +0200, Rainer Orth wrote:
> > I just remembered that the libstdc++ ABI baselines haven't been updated
> > for the GCC 10 release yet.  This patch corrects this for Solaris/SPARC
> > and x86.
> 
> I think we also need to update them on the gcc-9 branch, all the
> 3.4.28 symbols are on that branch too (added in 9.3.0).
> 
> > Created on master with make new-abi-baseline on i386-pc-solaris2.11 and
> > sparc-sun-solaris2.11.  Compared so far with last Friday's gcc-10 branch
> > build; will fire off a full gcc-10 branch bootstrap for good measure
> > right now.
> > 
> > Ok for master and gcc-10 branch if that passes?
> 
> OK for master. OK for gcc-10 with RM approval.

Ok for 10.1 too.

Jakub



Re: [PATCH] libstdc++: Update Solaris baselines for GCC 10.1

2020-05-06 Thread Jonathan Wakely via Gcc-patches

On 06/05/20 10:49 +0200, Rainer Orth wrote:

I just remembered that the libstdc++ ABI baselines haven't been updated
for the GCC 10 release yet.  This patch corrects this for Solaris/SPARC
and x86.


I think we also need to update them on the gcc-9 branch, all the
3.4.28 symbols are on that branch too (added in 9.3.0).


Created on master with make new-abi-baseline on i386-pc-solaris2.11 and
sparc-sun-solaris2.11.  Compared so far with last Friday's gcc-10 branch
build; will fire off a full gcc-10 branch bootstrap for good measure
right now.

Ok for master and gcc-10 branch if that passes?


OK for master. OK for gcc-10 with RM approval.



RE: [PATCH PR94026] combine missed opportunity to simplify comparisons with zero

2020-05-06 Thread Yangfei (Felix)
Hi,

> -Original Message-
> From: Segher Boessenkool [mailto:seg...@kernel.crashing.org]
> Sent: Tuesday, March 24, 2020 10:58 PM
> To: Yangfei (Felix) 
> Cc: gcc-patches@gcc.gnu.org; Zhanghaijian (A) 
> Subject: Re: [PATCH PR94026] combine missed opportunity to simplify
> comparisons with zero
> 
> On Tue, Mar 24, 2020 at 06:30:12AM +, Yangfei (Felix) wrote:
> > I modified combine emitting a simple AND operation instead of making one
> zero_extract for this scenario.
> > Attached please find the new patch.  Hope this solves both of our concerns.
> 
> This looks promising.  I'll try it out, see what it does on other targets.  
> (It will
> have to wait for GCC 11 stage 1, of course).

I see GCC11 stage 1 opens for commits now.
I have rebased the patch on the latest repo.  Attached please find the v2 patch.
Bootstrapped and tested on x86-64-linux-gnu and aarch64-linux-gnu.
Is this good to go?
 
> 
> p.s.  Please use a correct mime type?  application/octet-stream isn't
> something I can reply to.  Just text/plain is fine :-)

I have using plain text now, hope that works for you.  :-)

Thanks,
Felix


pr94026-v2.diff
Description: pr94026-v2.diff


[PATCH] libstdc++: Update Solaris baselines for GCC 10.1

2020-05-06 Thread Rainer Orth
I just remembered that the libstdc++ ABI baselines haven't been updated
for the GCC 10 release yet.  This patch corrects this for Solaris/SPARC
and x86.

Created on master with make new-abi-baseline on i386-pc-solaris2.11 and
sparc-sun-solaris2.11.  Compared so far with last Friday's gcc-10 branch
build; will fire off a full gcc-10 branch bootstrap for good measure
right now.

Ok for master and gcc-10 branch if that passes?

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University


2020-05-06  Rainer Orth  

* config/abi/post/i386-solaris/baseline_symbols.txt: Regenerate.
* config/abi/post/i386-solaris/amd64/baseline_symbols.txt:
Likewise.
* config/abi/post/sparc-solaris/baseline_symbols.txt: Likewise.
* config/abi/post/sparc-solaris/sparcv9/baseline_symbols.txt:
Likewise.

# HG changeset patch
# Parent  dbd1cd64711e5aa415dc1fa97a946f0f8620233e
libstdc++: Update Solaris baselines for GCC 10.1

diff --git a/libstdc++-v3/config/abi/post/i386-solaris/amd64/baseline_symbols.txt b/libstdc++-v3/config/abi/post/i386-solaris/amd64/baseline_symbols.txt
--- a/libstdc++-v3/config/abi/post/i386-solaris/amd64/baseline_symbols.txt
+++ b/libstdc++-v3/config/abi/post/i386-solaris/amd64/baseline_symbols.txt
@@ -2968,12 +2968,18 @@ FUNC:_ZNSt3_V214error_categoryD1Ev@@GLIB
 FUNC:_ZNSt3_V214error_categoryD2Ev@@GLIBCXX_3.4.21
 FUNC:_ZNSt3_V215system_categoryEv@@GLIBCXX_3.4.21
 FUNC:_ZNSt3_V216generic_categoryEv@@GLIBCXX_3.4.21
+FUNC:_ZNSt3pmr15memory_resourceD0Ev@@GLIBCXX_3.4.28
+FUNC:_ZNSt3pmr15memory_resourceD1Ev@@GLIBCXX_3.4.28
+FUNC:_ZNSt3pmr15memory_resourceD2Ev@@GLIBCXX_3.4.28
 FUNC:_ZNSt3pmr19new_delete_resourceEv@@GLIBCXX_3.4.26
 FUNC:_ZNSt3pmr20get_default_resourceEv@@GLIBCXX_3.4.26
 FUNC:_ZNSt3pmr20null_memory_resourceEv@@GLIBCXX_3.4.26
 FUNC:_ZNSt3pmr20set_default_resourceEPNS_15memory_resourceE@@GLIBCXX_3.4.26
 FUNC:_ZNSt3pmr25monotonic_buffer_resource13_M_new_bufferEmm@@GLIBCXX_3.4.26
 FUNC:_ZNSt3pmr25monotonic_buffer_resource18_M_release_buffersEv@@GLIBCXX_3.4.26
+FUNC:_ZNSt3pmr25monotonic_buffer_resourceD0Ev@@GLIBCXX_3.4.28
+FUNC:_ZNSt3pmr25monotonic_buffer_resourceD1Ev@@GLIBCXX_3.4.28
+FUNC:_ZNSt3pmr25monotonic_buffer_resourceD2Ev@@GLIBCXX_3.4.28
 FUNC:_ZNSt3pmr26synchronized_pool_resource11do_allocateEmm@@GLIBCXX_3.4.26
 FUNC:_ZNSt3pmr26synchronized_pool_resource13do_deallocateEPvmm@@GLIBCXX_3.4.26
 FUNC:_ZNSt3pmr26synchronized_pool_resource7releaseEv@@GLIBCXX_3.4.26
@@ -4459,6 +4465,7 @@ OBJECT:16:_ZTIN10__cxxabiv119__foreign_e
 OBJECT:16:_ZTINSt13__future_base11_State_baseE@@GLIBCXX_3.4.15
 OBJECT:16:_ZTINSt13__future_base12_Result_baseE@@GLIBCXX_3.4.15
 OBJECT:16:_ZTINSt3_V214error_categoryE@@GLIBCXX_3.4.21
+OBJECT:16:_ZTINSt3pmr15memory_resourceE@@GLIBCXX_3.4.28
 OBJECT:16:_ZTINSt6locale5facetE@@GLIBCXX_3.4
 OBJECT:16:_ZTINSt6thread6_StateE@@GLIBCXX_3.4.22
 OBJECT:16:_ZTISt10ctype_base@@GLIBCXX_3.4
@@ -4886,6 +4893,7 @@ OBJECT:24:_ZTIN9__gnu_cxx18stdio_sync_fi
 OBJECT:24:_ZTINSt10filesystem16filesystem_errorE@@GLIBCXX_3.4.26
 OBJECT:24:_ZTINSt10filesystem7__cxx1116filesystem_errorE@@GLIBCXX_3.4.26
 OBJECT:24:_ZTINSt13__future_base19_Async_state_commonE@@GLIBCXX_3.4.17
+OBJECT:24:_ZTINSt3pmr25monotonic_buffer_resourceE@@GLIBCXX_3.4.28
 OBJECT:24:_ZTINSt3pmr26synchronized_pool_resourceE@@GLIBCXX_3.4.26
 OBJECT:24:_ZTINSt3pmr28unsynchronized_pool_resourceE@@GLIBCXX_3.4.26
 OBJECT:24:_ZTINSt7__cxx1114collate_bynameIcEE@@GLIBCXX_3.4.21
@@ -5018,6 +5026,7 @@ OBJECT:25:_ZTSNSt7__cxx118messagesIwEE@@
 OBJECT:25:_ZTSNSt7__cxx118numpunctIcEE@@GLIBCXX_3.4.21
 OBJECT:25:_ZTSNSt7__cxx118numpunctIwEE@@GLIBCXX_3.4.21
 OBJECT:25:_ZTSSt20bad_array_new_length@@CXXABI_1.3.8
+OBJECT:26:_ZTSNSt3pmr15memory_resourceE@@GLIBCXX_3.4.28
 OBJECT:272:_ZSt4cerr@@GLIBCXX_3.4
 OBJECT:272:_ZSt4clog@@GLIBCXX_3.4
 OBJECT:272:_ZSt4cout@@GLIBCXX_3.4
@@ -5162,6 +5171,7 @@ OBJECT:34:_ZTSSt25__codecvt_utf8_utf16_b
 OBJECT:34:_ZTSSt9basic_iosIcSt11char_traitsIcEE@@GLIBCXX_3.4
 OBJECT:34:_ZTSSt9basic_iosIwSt11char_traitsIwEE@@GLIBCXX_3.4
 OBJECT:36:_ZTSN10__cxxabiv119__pointer_type_infoE@@CXXABI_1.3
+OBJECT:36:_ZTSNSt3pmr25monotonic_buffer_resourceE@@GLIBCXX_3.4.28
 OBJECT:36:_ZTSSt14codecvt_bynameIcc11__mbstate_tE@@GLIBCXX_3.4
 OBJECT:36:_ZTSSt14codecvt_bynameIwc11__mbstate_tE@@GLIBCXX_3.4
 OBJECT:37:_ZTSN10__cxxabiv120__function_type_infoE@@CXXABI_1.3
@@ -5589,6 +5599,8 @@ OBJECT:56:_ZTSNSt7__cxx1115basic_stringb
 OBJECT:56:_ZTSNSt7__cxx1115basic_stringbufIwSt11char_traitsIwESaIwEEE@@GLIBCXX_3.4.21
 OBJECT:56:_ZTTSd@@GLIBCXX_3.4
 OBJECT:56:_ZTTSt14basic_iostreamIwSt11char_traitsIwEE@@GLIBCXX_3.4
+OBJECT:56:_ZTVNSt3pmr15memory_resourceE@@GLIBCXX_3.4.28
+OBJECT:56:_ZTVNSt3pmr25monotonic_buffer_resourceE@@GLIBCXX_3.4.28
 OBJECT:56:_ZTVNSt7__cxx1114collate_bynameIcEE@@GLIBCXX_3.4.21
 OBJECT:56:_ZTVNSt7__cxx1114collate_bynameIwEE@@GLIBCXX_3.4.21
 

[PATCH] tree-optimization/94965 - fix typo in vec_info * passing

2020-05-06 Thread Richard Biener


Should have passed vinfo, not loop_vinfo.

Pushed as obvious.

2020-05-06  Richard Biener  

PR tree-optimization/94965
* tree-vect-stmts.c (vectorizable_load): Fix typo.
---
 gcc/tree-vect-stmts.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c
index 33210e1485b..c41c7e3eb9b 100644
--- a/gcc/tree-vect-stmts.c
+++ b/gcc/tree-vect-stmts.c
@@ -9364,7 +9364,7 @@ vectorizable_load (vec_info *vinfo,
 initialized yet, use first_stmt_info_for_drptr DR by bumping the
 distance from first_stmt_info DR instead as below.  */
   if (!diff_first_stmt_info)
-   msq = vect_setup_realignment (loop_vinfo,
+   msq = vect_setup_realignment (vinfo,
  first_stmt_info, gsi, _token,
  alignment_support_scheme, NULL_TREE,
  _loop);
-- 
2.16.4


Re: [committed] riscv: Fix up riscv_atomic_assign_expand_fenv [PR94950]

2020-05-06 Thread Andrew Waterman
Thank you!


On Wed, May 6, 2020 at 12:43 AM Jakub Jelinek  wrote:
>
> Hi!
>
> Similarly to the fixes on many other targets, riscv needs to use TARGET_EXPR
> to avoid having the create_tmp_var_raw temporaries without proper DECL_CONTEXT
> and not mentioned in local decls.
>
> Committed as obvious to trunk.
>
> 2020-05-06  Jakub Jelinek  
>
> PR target/94950
> * config/riscv/riscv-builtins.c (riscv_atomic_assign_expand_fenv): Use
> TARGET_EXPR instead of MODIFY_EXPR for first assignment to old_flags.
>
> --- gcc/config/riscv/riscv-builtins.c.jj2020-01-12 11:54:36.384413846 
> +0100
> +++ gcc/config/riscv/riscv-builtins.c   2020-05-05 12:41:08.005288721 +0200
> @@ -283,8 +283,8 @@ riscv_atomic_assign_expand_fenv (tree *h
>tree fsflags = GET_BUILTIN_DECL (CODE_FOR_riscv_fsflags);
>tree old_flags = create_tmp_var_raw (RISCV_ATYPE_USI);
>
> -  *hold = build2 (MODIFY_EXPR, RISCV_ATYPE_USI, old_flags,
> - build_call_expr (frflags, 0));
> +  *hold = build4 (TARGET_EXPR, RISCV_ATYPE_USI, old_flags,
> + build_call_expr (frflags, 0), NULL_TREE, NULL_TREE);
>*clear = build_call_expr (fsflags, 1, old_flags);
>*update = NULL_TREE;
>  }
>
> Jakub
>


[PATCH] match.pd: Optimize ~(~X +- Y) into (X -+ Y) [PR94921]

2020-05-06 Thread Jakub Jelinek via Gcc-patches
Hi!

According to my verification proglet, this transformation for signed types
with undefined overflow doesn't introduce nor remove any UB cases, so should
be valid even for signed integral types.
Not using a for because of the :c on plus which can't be there on minus.

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

2020-05-06  Jakub Jelinek  

PR tree-optimization/94921
* match.pd (~(~X - Y) -> X + Y, ~(~X + Y) -> X - Y): New
simplifications.

* gcc.dg/tree-ssa/pr94921.c: New test.

--- gcc/match.pd.jj 2020-05-05 11:36:17.510911674 +0200
+++ gcc/match.pd2020-05-05 16:48:59.496883197 +0200
@@ -1010,6 +1010,14 @@ (define_operator_list COND_TERNARY
   @0))
 #endif
 
+/* ~(~X - Y) -> X + Y and ~(~X + Y) -> X - Y.  */
+(simplify
+ (bit_not (minus (bit_not @0) @1))
+ (plus @0 @1))
+(simplify
+ (bit_not (plus:c (bit_not @0) @1))
+ (minus @0 @1))
+
 /* x + (x & 1) -> (x + 1) & ~1 */
 (simplify
  (plus:c @0 (bit_and:s @0 integer_onep@1))
--- gcc/testsuite/gcc.dg/tree-ssa/pr94921.c.jj  2020-05-05 16:58:32.913192128 
+0200
+++ gcc/testsuite/gcc.dg/tree-ssa/pr94921.c 2020-05-05 16:59:26.231384053 
+0200
@@ -0,0 +1,18 @@
+/* PR tree-optimization/94921 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-optimized" } */
+/* { dg-final { scan-tree-dump " \[ab]_\[0-9]+\\\(D\\\) \\+ 
\[ab]_\[0-9]+\\\(D\\\);" "optimized" } } */
+/* { dg-final { scan-tree-dump " c_\[0-9]+\\\(D\\\) - d_\[0-9]+\\\(D\\\);" 
"optimized" } } */
+/* { dg-final { scan-tree-dump-not " ~\[abcd]\?_\[0-9]\+" "optimized" } } */
+
+int
+foo (int a, int b)
+{
+  return ~(~a - b);
+}
+
+int
+bar (int c, int d)
+{
+  return ~(~c + d);
+}

Jakub



[committed] riscv: Fix up riscv_atomic_assign_expand_fenv [PR94950]

2020-05-06 Thread Jakub Jelinek via Gcc-patches
Hi!

Similarly to the fixes on many other targets, riscv needs to use TARGET_EXPR
to avoid having the create_tmp_var_raw temporaries without proper DECL_CONTEXT
and not mentioned in local decls.

Committed as obvious to trunk.

2020-05-06  Jakub Jelinek  

PR target/94950
* config/riscv/riscv-builtins.c (riscv_atomic_assign_expand_fenv): Use
TARGET_EXPR instead of MODIFY_EXPR for first assignment to old_flags.

--- gcc/config/riscv/riscv-builtins.c.jj2020-01-12 11:54:36.384413846 
+0100
+++ gcc/config/riscv/riscv-builtins.c   2020-05-05 12:41:08.005288721 +0200
@@ -283,8 +283,8 @@ riscv_atomic_assign_expand_fenv (tree *h
   tree fsflags = GET_BUILTIN_DECL (CODE_FOR_riscv_fsflags);
   tree old_flags = create_tmp_var_raw (RISCV_ATYPE_USI);
 
-  *hold = build2 (MODIFY_EXPR, RISCV_ATYPE_USI, old_flags,
- build_call_expr (frflags, 0));
+  *hold = build4 (TARGET_EXPR, RISCV_ATYPE_USI, old_flags,
+ build_call_expr (frflags, 0), NULL_TREE, NULL_TREE);
   *clear = build_call_expr (fsflags, 1, old_flags);
   *update = NULL_TREE;
 }

Jakub



[committed] combine: Don't replace SET_SRC with REG_EQUAL note content if SET_SRC has side-effects [PR94873]

2020-05-06 Thread Jakub Jelinek via Gcc-patches
Hi!

There were some discussions about whether REG_EQUAL notes are valid on insns 
with a single
set which contains auto-inc-dec side-effects in the SET_SRC and the majority 
thinks that
it should be valid.  So, this patch fixes the combiner to punt in that case, 
because otherwise
the auto-inc-dec side-effects from the SET_SRC are lost.

Bootstrapped/regtested on {x86_64,i686,aarch64,powerpc64{,le}}-linux,
preapproved in the PR by Segher, committed to trunk so far.

2020-05-06  Jakub Jelinek  

PR rtl-optimization/94873
* combine.c (combine_instructions): Don't optimize using REG_EQUAL
note if SET_SRC (set) has side-effects.

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

--- gcc/combine.c.jj2020-04-24 14:40:21.087840193 +0200
+++ gcc/combine.c   2020-05-05 12:15:36.793466471 +0200
@@ -1485,6 +1485,7 @@ combine_instructions (rtx_insn *f, unsig
  if ((set = single_set (temp)) != 0
  && (note = find_reg_equal_equiv_note (temp)) != 0
  && (note = XEXP (note, 0), GET_CODE (note)) != EXPR_LIST
+ && ! side_effects_p (SET_SRC (set))
  /* Avoid using a register that may already been marked
 dead by an earlier instruction.  */
  && ! unmentioned_reg_p (note, SET_SRC (set))
--- gcc/testsuite/gcc.dg/pr94873.c.jj   2020-05-05 12:18:35.056778567 +0200
+++ gcc/testsuite/gcc.dg/pr94873.c  2020-05-05 12:14:27.437512245 +0200
@@ -0,0 +1,27 @@
+/* PR rtl-optimization/94873 */
+/* { dg-do run { target int128 } } */
+/* { dg-options "-O -fno-merge-constants -fno-split-wide-types -fno-tree-fre" 
} */
+
+__attribute__((noipa)) void
+foo (const char *p, int q)
+{
+  if (p[0] != '%' || p[1] != '0' || p[2] != '2' || p[3] != 'x' || p[4] != '\0')
+__builtin_abort ();
+#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
+  if ((unsigned char) q != 0x95)
+__builtin_abort ();
+#elif __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
+  if ((unsigned char) q != 0)
+__builtin_abort ();
+#endif
+}
+
+int
+main ()
+{
+  union U { __int128 a; char b[sizeof (__int128)]; };
+  char x = ((union U){ .a = 0xF4409395252B9560ULL}).b[1];
+  for (unsigned i = 0; i < sizeof (x); i++)
+foo ("%02x", i[(volatile unsigned char *) ]);
+  return 0;
+}


Jakub



Re: [PATCH] Enable GCC support for TSXLDTRK

2020-05-06 Thread Uros Bizjak via Gcc-patches
On Wed, May 6, 2020 at 4:48 AM Hongtao Liu  wrote:
>
> On Mon, May 4, 2020 at 12:58 AM Uros Bizjak  wrote:
> >
> > The part above is OK, but you are missing support for
> > __attribute__((__target__("..."))). Please see how for example -msgx
> > is handled in isa2_opts in i386-options.c and in
> > gcc.target/i386/funcspec-56.h test source.
> >
> > Please repost the patch with added missing part.
> >
> > Uros.
>
> Updated:
>
> gcc/Changelog
> * common/config/i386/i386-common.c (OPTION_MASK_ISA2_TSXLDTRK_SET,
> OPTION_MASK_ISA2_TSXLDTRK_UNSET): New macros.
> * config.gcc: Add tsxldtrkintrin.h to extra_headers.
> * config/i386/driver-i386.c (host_detect_local_cpu): Detect
> TSXLDTRK.
> * config/i386/i386-builtin.def: Add new builtins.
> * config/i386/i386-c.c (ix86_target_macros_internal): Define
> __TSXLDTRK__.
> * config/i386/i386-options.c (ix86_target_string): Add
> -mtsxldtrk.
> (ix86_valid_target_attribute_inner_p): Add attribute tsxldtrk.
> * config/i386/i386.h (TARGET_TSXLDTRK, TARGET_TSXLDTRK_P):
> New.
> * config/i386/i386.md (define_c_enum "unspec"): Add
> UNSPECV_SUSLDTRK, UNSPECV_RESLDTRK.
> (TSXLDTRK): New define_int_iterator.
> (""): New define_insn.
> * config/i386/i386.opt: Add -mtsxldtrk.
> * config/i386/immintrin.h: Include tsxldtrkintrin.h.
> * config/i386/tsxldtrkintrin.h: New.
> * doc/invoke.texi: Document -mtsxldtrk.
>
> gcc/testsuite/Changelog
> * g++.dg/other/i386-2.c: Add -mtsxldtrk.
> * g++.dg/other/i386-3.c: Likewise.
> * gcc.target/i386/sse-12.c: Likewise.
> * gcc.target/i386/sse-13.c: Likewise.
> * gcc.target/i386/sse-14.c: Likewise.
> * gcc.target/i386/sse-22.c: Likewsie.
> * gcc.target/i386/sse-23.c: Likewise.
> * gcc.target/i386/tsxldtrk-1.c: New test.
> * gcc.target/i386/funcspec-56.inc: Add target attribute tests
> for tsxldtrk.

OK.

Thanks,
Uros.


Re: [PATCH] Adjust integer <-> pointer conversion IL checking

2020-05-06 Thread Richard Biener
On Tue, 5 May 2020, Jeff Law wrote:

> On Mon, 2020-05-04 at 14:11 +0200, Richard Biener wrote:
> > This patch sits in my trees for quite some years and I always forget
> > to push it - it usually gets triggered by weird targets (PSImode
> > pointers/sizetype) which run into GIMPLE IL checking asserts for
> > pointer -> integer conversions and the "sizetype" special-case
> > not triggering.  That special-case should not exist but instead
> > it should be something like the patch below - the whole point
> > of the IL consistecy check is to ensure we know how to extend
> > from pointer to integer.
> > 
> > I've bootstrapped / tested the patch on x86_64 where it is a no-op.
> > 
> > But from the looks, can you punch any holes in it?  (it was able
> > to resolve reporters issues at least).
> > 
> > Thanks,
> > Richard.
> > 
> > -
> > 
> > The existing check doesn't reflect the actual reason why it exists,
> > the patch makes us to use POINTERS_EXTEND_UNSIGNED instead which
> > is specified for ptr_mode and word_mode/Pmode precision.
> > 
> > * tree-cfg.c (verify_gimple_assign_unary): Adjust integer
> > to/from pointer conversion checking.
> I'd say let's go for it.  The tester will pick it up and I'll complain if any 
> of
> the targets start failing.

Fair enough - I've pushed the patch.

Richard.


Re: [PATH] Enable GCC support for SERIALIZE

2020-05-06 Thread Uros Bizjak via Gcc-patches
On Wed, May 6, 2020 at 5:11 AM Hongtao Liu  wrote:
>
> On Mon, May 4, 2020 at 1:17 AM Uros Bizjak  wrote:
> >
> > On Wed, Apr 1, 2020 at 9:23 AM Hongtao Liu  wrote:
> > >
> > > Hi:
> > >   This patch is about to enable GCC support for SERIALIZE which would
> > > be in GLC. There's only 1 instruction: SERIALIZE, more details please
> > > refer to 
> > > https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruction-set-extensions-programming-reference.pdf
> > >   I know it's stage4 right now, and patches are approved only for bug
> > > fixed, but since many users prefer to use release version other than
> > > build from trunk, i'd like to see this patch landed on GCC10, after
> > > all it's only 1 instruction, without any significant changes.
> > >
> > >   Bootstrap ok, regression test on i386/x86 backend is ok.
> > >
> > > gcc/Changelog:
> > > * gcc/common/config/i386/i386-common.c 
> > > (OPTION_MASK_ISA2_SERIALIZE_SET,
> > > OPTION_MASK_ISA2_SERIALIZE_UNSET): New macros.
> > > (ix86_handle_option): Handle -mserialize.
> > > * gcc/config.gcc (serializeintrin.h): New header file.
> > > * gcc/config/i386/cpuid.h (bit_SERIALIZE): New bit.
> > > * gcc/config/i386/driver-i386.c (host_detect_local_cpu): Detect
> > > -mserialize.
> > > * gcc/config/i386/i386-builtin.def: Add new builtin.
> > > * gcc/config/i386/i386-c.c (__SERIALIZE__): New macro.
> > > * gcc/config/i386/i386-options.c (ix86_target_opts_isa2_opts):
> > >   Add -mserialize.
> > > * (ix86_valid_target_attribute_inner_p): Add target attribute
> > > * for serialize.
> > > * gcc/config/i386/i386.h (TARGET_SERIALIZE, TARGET_SERIALIZE_P):
> > >   New macros.
> > > * gcc/config/i386/i386.md (UNSPECV_SERIALIZE): New unspec.
> > >   (serialize): New define_insn.
> > > * gcc/config/i386/i386.opt (mserialize): New option
> > > * gcc/config/i386/immintrin.h: Include serailizeintrin.h.
> > > * gcc/config/i386/serializeintrin.h: New header file.
> > > * gcc/doc/invoke.texi: Add documents for -mserialize.
> > >
> > > gcc/testsuite/Changelog
> > > * gcc/testsuite/gcc.target/i386/serialize-1.c: New test.
> > > * gcc/testsuite/g++.dg/other/i386-2.C: Add -mserialize.
> > > * gcc/testsuite/g++.dg/other/i386-3.C: Ditto.
> > > * gcc/testsuite/gcc.target/i386/sse-12.c: Ditto.
> > > * gcc/testsuite/gcc.target/i386/sse-13.c: Ditto.
> > > * gcc/testsuite/gcc.target/i386/sse-14.c: Ditto.
> > > * gcc/testsuite/gcc.target/i386/sse-22.c: Ditto.
> > > * gcc/testsuite/gcc.target/i386/sse-23.c: Ditto.

OK.

Thanks,
Uros.