Re: [stage1] [PATCH] Merge dg-options and dg-additional-options if len <= 120 chars.

[Martin Liška]

On 4/28/20 6:13 PM, Christophe Lyon wrote:

Hi,


On Thu, 16 Apr 2020 at 09:50, Martin Liška  wrote:


On 4/14/20 1:43 PM, Jakub Jelinek wrote:

Roughly, yes.  A few extra in testcases don't hurt necessarily, but say 160
chars or more is clearly too much.


All right, I made a limit of 120 characters for the changes.

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

Ready to be installed in next stage1?


This will introduce a regression on arm:
gcc.target/arm/armv8_2-fp16-move-1.c

Because of:
-/* { dg-options "-O2" }  */
+/* { dg-options "-O2 -mfloat-abi=hard" }  */
  /* { dg-add-options arm_v8_2a_fp16_scalar }  */
-/* { dg-additional-options "-mfloat-abi=hard" } */

Indeed arm_v8_2a_fp16_scalar inserts -mfloat-abi=softfp in some cases,
so the original version overrides it with -mfloat-abi=hard.
With your patch, the order is reversed, hence the error.


Hello.

Thank you for heads up.



There may be similar problems on other targets?


I grepped for dg-add-options pattern and there are 3 such cases which I 
resolved.

I'm retesting the patch.
Martin



Thanks,

Christophe


Thanks,
Martin


>From b65965c810ba914c6f7e273de2fe62a49fb32568 Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Wed, 15 Apr 2020 08:49:45 +0200
Subject: [PATCH] Merge dg-options and dg-additional-options if len <= 120
 chars.

gcc/testsuite/ChangeLog:

2020-04-15  Martin Liska  

	* g++.dg/concepts/diagnostic1.C: Merge dg-options and
	dg-additional-options if len <= 120 chars.
	* g++.dg/cpp1y/new1.C: Likewise.
	* g++.dg/cpp1y/new2.C: Likewise.
	* g++.dg/debug/dwarf2/pr61433.C: Likewise.
	* g++.dg/init/new18.C: Likewise.
	* g++.dg/ipa/devirt-19.C: Likewise.
	* g++.dg/ipa/devirt-52.C: Likewise.
	* g++.dg/ipa/pr44372.C: Likewise.
	* g++.dg/ipa/pr58371.C: Likewise.
	* g++.dg/ipa/pr63587-2.C: Likewise.
	* g++.dg/ipa/pr78211.C: Likewise.
	* g++.dg/opt/dump1.C: Likewise.
	* g++.dg/opt/pr44919.C: Likewise.
	* g++.dg/opt/pr47615.C: Likewise.
	* g++.dg/opt/pr82159-2.C: Likewise.
	* g++.dg/other/pr52048.C: Likewise.
	* g++.dg/pr57662.C: Likewise.
	* g++.dg/pr59510.C: Likewise.
	* g++.dg/pr67989.C: Likewise.
	* g++.dg/pr81194.C: Likewise.
	* g++.dg/template/canon-type-8.C: Likewise.
	* g++.dg/template/crash107.C: Likewise.
	* g++.dg/template/show-template-tree-3.C: Likewise.
	* g++.dg/tm/cgraph_edge.C: Likewise.
	* g++.dg/torture/20141013.C: Likewise.
	* g++.dg/torture/pr34641.C: Likewise.
	* g++.dg/torture/pr34850.C: Likewise.
	* g++.dg/torture/pr36745.C: Likewise.
	* g++.dg/torture/pr40991.C: Likewise.
	* g++.dg/torture/pr48271.C: Likewise.
	* g++.dg/torture/pr53602.C: Likewise.
	* g++.dg/torture/pr53752.C: Likewise.
	* g++.dg/torture/pr54838.C: Likewise.
	* g++.dg/torture/pr58252.C: Likewise.
	* g++.dg/tree-ssa/pr22444.C: Likewise.
	* g++.dg/tree-ssa/pr24351-3.C: Likewise.
	* g++.dg/tree-ssa/pr27283.C: Likewise.
	* g++.dg/tree-ssa/pr27291.C: Likewise.
	* g++.dg/tree-ssa/pr27548.C: Likewise.
	* g++.dg/tree-ssa/pr42337.C: Likewise.
	* g++.dg/ubsan/pr65583.C: Likewise.
	* g++.old-deja/g++.robertl/eb27.C: Likewise.
	* gcc.dg/tree-ssa/dse-points-to.c: Likewise.
	* gcc.target/arm/simd/vmmla_1.c: Likewise.
	* gcc.target/i386/vect-pr67800.c: Likewise.
	* gcc.target/mips/cfgcleanup-jalr2.c: Likewise.
	* gcc.target/mips/cfgcleanup-jalr3.c: Likewise.
---
 gcc/testsuite/g++.dg/concepts/diagnostic1.C  | 3 +--
 gcc/testsuite/g++.dg/cpp1y/new1.C| 3 +--
 gcc/testsuite/g++.dg/cpp1y/new2.C| 3 +--
 gcc/testsuite/g++.dg/debug/dwarf2/pr61433.C  | 3 +--
 gcc/testsuite/g++.dg/init/new18.C| 3 +--
 gcc/testsuite/g++.dg/ipa/devirt-19.C | 3 +--
 gcc/testsuite/g++.dg/ipa/devirt-52.C | 3 +--
 gcc/testsuite/g++.dg/ipa/pr44372.C   | 3 +--
 gcc/testsuite/g++.dg/ipa/pr58371.C   | 3 +--
 gcc/testsuite/g++.dg/ipa/pr63587-2.C | 3 +--
 gcc/testsuite/g++.dg/ipa/pr78211.C   | 3 +--
 gcc/testsuite/g++.dg/opt/dump1.C | 3 +--
 gcc/testsuite/g++.dg/opt/pr44919.C   | 3 +--
 gcc/testsuite/g++.dg/opt/pr47615.C   | 3 +--
 gcc/testsuite/g++.dg/opt/pr82159-2.C | 3 +--
 gcc/testsuite/g++.dg/other/pr52048.C | 3 +--
 gcc/testsuite/g++.dg/pr57662.C   | 3 +--
 gcc/testsuite/g++.dg/pr59510.C   | 3 +--
 gcc/testsuite/g++.dg/pr67989.C   | 3 +--
 gcc/testsuite/g++.dg/pr81194.C   | 3 +--
 gcc/testsuite/g++.dg/template/canon-type-8.C | 3 +--
 gcc/testsuite/g++.dg/template/crash107.C | 3 +--
 gcc/testsuite/g++.dg/template/show-template-tree-3.C | 3 +--
 gcc/testsuite/g++.dg/tm/cgraph_edge.C| 3 +--
 gcc/testsuite/g++.dg/torture/20141013.C  | 3 +--
 gcc/testsuite/g++.dg/torture/pr34641.C   | 3 +--
 gcc/testsuite/g++.dg/torture/pr34850.C   | 3 +--
 

Re: [PATCH v4] c++: Member template function lookup failure [PR94799]

[Jason Merrill via Gcc-patches]

On 5/4/20 9:51 PM, Marek Polacek wrote:

On Mon, May 04, 2020 at 05:41:37PM -0400, Jason Merrill via Gcc-patches wrote:

On 5/4/20 4:37 PM, Marek Polacek wrote:

On Fri, May 01, 2020 at 04:12:35PM -0400, Jason Merrill wrote:

@@ -7754,9 +7755,22 @@ cp_parser_postfix_dot_deref_expression (cp_parser 
*parser,
}
  if (dependent_p)
-/* Tell cp_parser_lookup_name that there was an object, even though it's
-   type-dependent.  */
-parser->context->object_type = unknown_type_node;
+{
+  /* If we don't have a (type-dependent) object of class type, use
+decltype to signal that there was an object.  */
+  if (type == NULL_TREE)
+   {
+ type = finish_decltype_type (postfix_expression,
+  /*member_access_p=*/true,


This should be false, we don't want the special decltype semantics for a
member-access expression.


Fixed.


+  tf_warning_or_error);
+ /* For -> this decltype will produce T*, but we want T.  */
+ if (token_type == CPP_DEREF)
+   type = build_min_nt_loc (start_loc, INDIRECT_REF, type);


Don't we want the INDIRECT_REF inside the decltype?  How does it work like
this?


I'm now not quite sure what I perpetrated there; I must've messed it up when I 
was
looking at what we do with it in the debugger.  I assume it worked by accident.

I've moved the INDIRECT_REF inside the decltype, but I had to use the original
expression


Hmm, I would expect the type of the ARROW_EXPR to be what we want without
messing with INDIRECT_REF separately.


Weirdly decltype/typeof of the ARROW_EXPR for e.g. bar((T)1)->template M::fn 
()
from the lookup15.C test still gives me M *.


In general, if something seems weird, please investigate more before 
working around it.


In this case I can't reproduce the weirdness; your new tests all still 
pass for me with the patch below:


Jason
commit 042929a2220ff6e2f54c23cd27f360fc285363e3
Author: Jason Merrill 
Date:   Mon May 4 22:57:55 2020 -0400

simpler

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 90fc9304ef2..5832025443d 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -7694,7 +7694,6 @@ cp_parser_postfix_dot_deref_expression (cp_parser *parser,
   bool pseudo_destructor_p;
   tree scope = NULL_TREE;
   location_t start_loc = postfix_expression.get_start ();
-  tree orig_expr = postfix_expression;
 
   /* If this is a `->' operator, dereference the pointer.  */
   if (token_type == CPP_DEREF)
@@ -7756,20 +7755,11 @@ cp_parser_postfix_dot_deref_expression (cp_parser *parser,
 
   if (dependent_p)
 {
-  tree type = TREE_TYPE (orig_expr);
+  tree type = TREE_TYPE (postfix_expression);
   /* If we don't have a (type-dependent) object of class type, use
-	 typeof to figure out the type of the object.  Use the original
-	 expression -- typeof on an ARROW_EXPR may not give the desirable
-	 result.  */
+	 typeof to figure out the type of the object.  */
   if (type == NULL_TREE)
-	{
-	  /* For -> this typeof will produce T*, but we want T.  */
-	  if (token_type == CPP_DEREF)
-	orig_expr = build_min_nt_loc (start_loc, INDIRECT_REF, orig_expr);
-	  type = finish_typeof (orig_expr);
-	}
-  else if (token_type == CPP_DEREF && POINTER_TYPE_P (type))
-	type = TREE_TYPE (type);
+	type = finish_typeof (postfix_expression);
   parser->context->object_type = type;
 }
 

Re: [PATCH v4] c++: Member template function lookup failure [PR94799]

[Marek Polacek via Gcc-patches]

On Mon, May 04, 2020 at 05:41:37PM -0400, Jason Merrill via Gcc-patches wrote:
> On 5/4/20 4:37 PM, Marek Polacek wrote:
> > On Fri, May 01, 2020 at 04:12:35PM -0400, Jason Merrill wrote:
> > > > @@ -7754,9 +7755,22 @@ cp_parser_postfix_dot_deref_expression 
> > > > (cp_parser *parser,
> > > >}
> > > >  if (dependent_p)
> > > > -/* Tell cp_parser_lookup_name that there was an object, even 
> > > > though it's
> > > > -   type-dependent.  */
> > > > -parser->context->object_type = unknown_type_node;
> > > > +{
> > > > +  /* If we don't have a (type-dependent) object of class type, use
> > > > +decltype to signal that there was an object.  */
> > > > +  if (type == NULL_TREE)
> > > > +   {
> > > > + type = finish_decltype_type (postfix_expression,
> > > > +  /*member_access_p=*/true,
> > > 
> > > This should be false, we don't want the special decltype semantics for a
> > > member-access expression.
> > 
> > Fixed.
> > 
> > > > +  tf_warning_or_error);
> > > > + /* For -> this decltype will produce T*, but we want T.  */
> > > > + if (token_type == CPP_DEREF)
> > > > +   type = build_min_nt_loc (start_loc, INDIRECT_REF, type);
> > > 
> > > Don't we want the INDIRECT_REF inside the decltype?  How does it work like
> > > this?
> > 
> > I'm now not quite sure what I perpetrated there; I must've messed it up 
> > when I was
> > looking at what we do with it in the debugger.  I assume it worked by 
> > accident.
> > 
> > I've moved the INDIRECT_REF inside the decltype, but I had to use the 
> > original
> > expression
> 
> Hmm, I would expect the type of the ARROW_EXPR to be what we want without
> messing with INDIRECT_REF separately.

Weirdly decltype/typeof of the ARROW_EXPR for e.g. bar((T)1)->template M::fn 
()
from the lookup15.C test still gives me M *.

> > and also set DECLTYPE_FOR_LAMBDA_CAPTURE so that the result of the
> > decltype is e.g. M, not M &.  Not sure how hacky this is, but I've
> > verified that tsubst/TYPENAME_TYPE now gets what I would expect it to.
> 
> Hmm, does it work to use finish_typeof instead?  If not, using that flag is
> fine, but we should rename it.  :)

Ah, very cool, typeof works too, and doesn't need the reference stripping.

Thanks,

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

-- >8 --
Whew, this took a while.  We fail to parse "p->template A::a()"
(where p is of type A *) because since r249752 we treat the RHS of the ->
as dependent and avoid a lookup in the enclosing context: since that rev
cp_parser_template_name checks parser->context->object_type too, which
here is unknown_type_node, signalling a type-dependent object:

 7756   if (dependent_p)
 7757 /* Tell cp_parser_lookup_name that there was an object, even though 
it's
 7758type-dependent.  */
 7759 parser->context->object_type = unknown_type_node;

with which cp_parser_template_name returns identifier 'A', cp_parser_class_name
then creates a TEMPLATE_ID_EXPR A, but then

23735   decl = make_typename_type (scope, decl, tag_type, tf_error);

in cp_parser_class_name fails because scope is NULL.  Then we return
error_mark_node and parse errors ensue.

I've tried various approaches, e.g. keeping TEMPLATE_ID_EXPR around
instead of calling make_typename_type, which didn't work, whereupon I
realized that since we don't want to perform name lookup if we've seen
the template keyword and the scope is dependent, we can adjust
parser->context->object_type and use the type of the object expression
as the scope, even if it's type-dependent.  This should be in line with
[basic.lookup.classref]p4.  If the postfix expression doesn't have a type,
use typeof (possibly dereferenced) to carry its type.  This typeof
will be processed in tsubst/TYPENAME_TYPE.

PR c++/94799
* parser.c (cp_parser_postfix_dot_deref_expression): If we have
a type-dependent object of class type, stash it to
parser->context->object_type.  If the postfix expression doesn't have
a type, use typeof.
(cp_parser_class_name): Consider object scope too.
(cp_parser_lookup_name): Remove code dealing with the case when
object_type is unknown_type_node.

* g++.dg/lookup/this1.C: Adjust dg-error.
* g++.dg/template/lookup12.C: New test.
* g++.dg/template/lookup13.C: New test.
* g++.dg/template/lookup14.C: New test.
* g++.dg/template/lookup15.C: New test.
---
 gcc/cp/parser.c  | 36 ++--
 gcc/testsuite/g++.dg/lookup/this1.C  |  2 +-
 gcc/testsuite/g++.dg/template/lookup12.C | 26 +
 gcc/testsuite/g++.dg/template/lookup13.C | 28 ++
 gcc/testsuite/g++.dg/template/lookup14.C | 11 
 gcc/testsuite/g++.dg/template/lookup15.C | 24 
 6 files changed, 117 insertions(+), 10 deletions(-)
 

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

[Jason Merrill via Gcc-patches]

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?


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


warning_sentinel s1(warn_type_limits, was_dep);
warning_sentinel s2(warn_div_by_zero, was_dep);
warning_sentinel s3(warn_logical_op, was_dep);
diff --git a/gcc/testsuite/g++.dg/warn/template-2.C 
b/gcc/testsuite/g++.dg/warn/template-2.C
new file mode 100644
index 000..1d29528b2ac
--- /dev/null
+++ b/gcc/testsuite/g++.dg/warn/template-2.C
@@ -0,0 +1,22 @@
+// PR c++/94938 - ICE in value_dependent_expression_p in C++98 mode.
+// { dg-do compile }
+
+template  struct S { S(); S(bool); };
+
+struct C {
+  bool operator()(S);
+};
+
+S fn (bool);
+
+template void
+foo (T)
+{
+  S s;
+  S x = fn(false || C()(s));
+}
+
+int main ()
+{
+  foo(int());
+}

base-commit: 5e681acd3587285cc3c8c6d603e4ce93cf6dacf2

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

[Marek Polacek via Gcc-patches]

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;
warning_sentinel s1(warn_type_limits, was_dep);
warning_sentinel s2(warn_div_by_zero, was_dep);
warning_sentinel s3(warn_logical_op, was_dep);
diff --git a/gcc/testsuite/g++.dg/warn/template-2.C 
b/gcc/testsuite/g++.dg/warn/template-2.C
new file mode 100644
index 000..1d29528b2ac
--- /dev/null
+++ b/gcc/testsuite/g++.dg/warn/template-2.C
@@ -0,0 +1,22 @@
+// PR c++/94938 - ICE in value_dependent_expression_p in C++98 mode.
+// { dg-do compile }
+
+template  struct S { S(); S(bool); };
+
+struct C {
+  bool operator()(S);
+};
+
+S fn (bool);
+
+template void
+foo (T)
+{
+  S s;
+  S x = fn(false || C()(s));
+}
+
+int main ()
+{
+  foo(int());
+}

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

Re: [PATCH 2/4] x86: Add -mzero-caller-saved-regs=[skip|used-gpr|all-gpr|used|all]

[Rodriguez Bahena, Victor via Gcc-patches]

-Original Message-
From: "H.J. Lu" 
Date: Monday, May 4, 2020 at 2:02 PM
To: "gcc-patches@gcc.gnu.org" 
Cc: Uros Bizjak , Jeff Law , Richard Biener 
, Jakub Jelinek , Qing Zhao 
, "keesc...@chromium.org" , 
"Rodriguez Bahena, Victor" 
Subject: [PATCH 2/4] x86: Add 
-mzero-caller-saved-regs=[skip|used-gpr|all-gpr|used|all]

Add -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")

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

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

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

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

Tested on i686 and x86-64 with bootstrapping GCC trunk, making
-mzero-caller-saved-regs=used-gpr, -mzero-caller-saved-regs=all-gpr
-mzero-caller-saved-regs=used, and -mzero-caller-saved-regs=all enabled
by default.

Hi gcc team 

Clear Linux project has been using this patch since GCC 8
This is intended to make threats such as ROP, COP, and JOP attacks much harder.
It will be nice if we could have this patch in GCC 10 or master. 

Thanks

Victor Rodriguez

gcc/

* i386-expand.c (ix86_find_live_outgoing_regs): New function.
(ix86_split_simple_return_pop_internal): Removed.
(ix86_split_simple_return_internal): New function.
* config/i386/i386-options.c (ix86_set_zero_caller_saved_regs_type):
New function.
(ix86_set_current_function): Call ix86_set_zero_caller_saved_regs_type.
(ix86_handle_fndecl_attribute): Support zero_caller_saved_regs
attribute.
(ix86_attribute_table): Add zero_caller_saved_regs.
* config/i386/i386-opts.h (zero_caller_saved_regs): New enum.
* config/i386/i386-protos.h (ix86_split_simple_return_pop_internal):
Renamed to ...
(ix86_split_simple_return_internal): This.
* config/i386/i386.c (ix86_expand_prologue): Replace
gen_prologue_use with gen_pro_epilogue_use.
(ix86_expand_epilogue): Replace gen_simple_return_pop_internal
with ix86_split_simple_return_internal.  Replace
gen_simple_return_internal with ix86_split_simple_return_internal.
* config/i386/i386.h (machine_function): Add
zero_caller_saved_regs_type, live_outgoing_int_regs and
live_outgoing_vector_regs.
(TARGET_POP_SCRATCH_REGISTER): New.
* config/i386/i386.md (UNSPEC_SIMPLE_RETURN): New UNSPEC.
(UNSPECV_PROLOGUE_USE): Renamed to ...
(UNSPECV_PRO_EPILOGUE_USE): This.
(prologue_use): Renamed to ...
(pro_epilogue_use): This.
(simple_return_internal): Changed to define_insn_and_split.
(simple_return_internal_1): New pattern.
(simple_return_pop_internal): Replace
ix86_split_simple_return_pop_internal with
ix86_split_simple_return_internal.  Always call
ix86_split_simple_return_internal if epilogue_completed is
true.
(simple_return_pop_internal_1): New pattern.
(Epilogue deallocator to pop peepholes): Enabled only if
TARGET_POP_SCRATCH_REGISTER is true.
* config/i386/i386.opt (mzero-caller-saved-regs=): New option.
* doc/extend.texi: Document zero_caller_saved_regs attribute.
* doc/invoke.texi: Document -mzero-caller-saved-regs=.

gcc/testsuite/

* gcc.target/i386/zero-scratch-regs-1.c: New test.
* gcc.target/i386/zero-scratch-regs-2.c: Likewise.
* gcc.target/i386/zero-scratch-regs-3.c: Likewise.
* gcc.target/i386/zero-scratch-regs-4.c: Likewise.
* gcc.target/i386/zero-scratch-regs-5.c: Likewise.
* gcc.target/i386/zero-scratch-regs-6.c: Likewise.
* gcc.target/i386/zero-scratch-regs-7.c: Likewise.
* gcc.target/i386/zero-scratch-regs-8.c: Likewise.
* gcc.target/i386/zero-scratch-regs-9.c: Likewise.
* gcc.target/i386/zero-scratch-regs-10.c: Likewise.
* gcc.target/i386/zero-scratch-regs-11.c: Likewise.
* gcc.target/i386/zero-scratch-regs-12.c: Likewise.
* gcc.target/i386/zero-scratch-regs-13.c: Likewise.
* gcc.target/i386/zero-scratch-regs-14.c: Likewise.
* gcc.target/i386/zero-scratch-regs-15.c: Likewise.
* gcc.target/i386/zero-scratch-regs-16.c: Likewise.
* gcc.target/i386/zero-scratch-regs-17.c: Likewise.
* gcc.target/i386/zero-scratch-regs-18.c: Likewise.
* gcc.target/i386/zero-scratch-regs-19.c: Likewise.
* 

Re: [PATCH] libstdc++: Fix the return type of __cxa_finalize according to the Itanium C++ ABI

[Jonathan Wakely via Gcc-patches]

On 12/03/20 10:13 +, Jonathan Wakely via Libstdc++ wrote:

Please CC libstd...@gcc.gnu.org for all libstdc++ patches, as per
https://gcc.gnu.org/lists.html

On 11/03/20 21:24 -0700, Fangrui Song wrote:

Alternatively, we can delete it, because no user code should call it.
It may be weird that libc is expected to define this function.
This function is a language runtime interface that has nothing to do
with a libc.


It's coupled with __cxa_atexit, and the ABI says:

"It is expected that implementations supporting both C and C++ will
integrate this capability into the libc atexit implementation so that
C-only DSOs will nevertheless interact with C++ programs in a
C++-standard-conforming manner."


---
libstdc++-v3/libsupc++/cxxabi.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libstdc++-v3/libsupc++/cxxabi.h b/libstdc++-v3/libsupc++/cxxabi.h
index 50298205daa..000713ecdf8 100644
--- a/libstdc++-v3/libsupc++/cxxabi.h
+++ b/libstdc++-v3/libsupc++/cxxabi.h
@@ -127,7 +127,7 @@ namespace __cxxabiv1
 int
 __cxa_atexit(void (*)(void*), void*, void*) _GLIBCXX_NOTHROW;

-  int
+  void
 __cxa_finalize(void*);


The change is correct, but I think we should wait for stage 1 (after
the GCC 10 release) to apply it. If I forget, please remind us in a
couple of months.


I've pushed this change to the master branch now.

Thanks for the fix.

Re: [PATCH v3] [Stage1] Refactor tree-ssa-operands.c

[Giuliano Belinassi via Gcc-patches]

Hi,

This patch Refactors tree-ssa-operands.c by wrapping the global
variables into a class, and also removes unused code.

The difference between this version and v2 is:
  * Disable the copy of operands_scanner
  * remove void from empty arguments functions.


gcc/ChangeLog:
2020-05-04  Giuliano Belinassi  

* tree-ssa-operands.c (operands_scanner): New class.
(operands_bitmap_obstack): Remove.
(n_initialized): Remove.
(build_uses): Move to operands_scanner class.
(build_vuse): Same as above.
(build_vdef): Same as above.
(verify_ssa_operands): Same as above.
(finalize_ssa_uses): Same as above.
(cleanup_build_arrays): Same as above.
(finalize_ssa_stmt_operands): Same as above.
(start_ssa_stmt_operands): Same as above.
(append_use): Same as above.
(append_vdef): Same as above.
(add_virtual_operand): Same as above.
(add_stmt_operand): Same as above.
(get_mem_ref_operands): Same as above.
(get_tmr_operands): Same as above.
(maybe_add_call_vops): Same as above.
(get_asm_stmt_operands): Same as above.
(get_expr_operands): Same as above.
(parse_ssa_operands): Same as above.
(finalize_ssa_defs): Same as above.
(build_ssa_operands): Same as above, plus create a C-like wrapper.
(update_stmt_operands): Create an instance of operands_scanner.
>From d908e3184585cf0c1f7fcfb0490a3e51273559c6 Mon Sep 17 00:00:00 2001
From: Giuliano Belinassi 
Date: Mon, 4 May 2020 18:44:31 -0300
Subject: [PATCH v3] Refactor tree-ssa-operands.c

Refactor tree-ssa-operands.c by wrapping the global
variables into a class, and also removes unused code.

gcc/ChangeLog:
2020-05-04  Giuliano Belinassi  

	* tree-ssa-operands.c (operands_scanner): New class.
	(operands_bitmap_obstack): Remove.
	(n_initialized): Remove.
	(build_uses): Move to operands_scanner class.
	(build_vuse): Same as above.
	(build_vdef): Same as above.
	(verify_ssa_operands): Same as above.
	(finalize_ssa_uses): Same as above.
	(cleanup_build_arrays): Same as above.
	(finalize_ssa_stmt_operands): Same as above.
	(start_ssa_stmt_operands): Same as above.
	(append_use): Same as above.
	(append_vdef): Same as above.
	(add_virtual_operand): Same as above.
	(add_stmt_operand): Same as above.
	(get_mem_ref_operands): Same as above.
	(get_tmr_operands): Same as above.
	(maybe_add_call_vops): Same as above.
	(get_asm_stmt_operands): Same as above.
	(get_expr_operands): Same as above.
	(parse_ssa_operands): Same as above.
	(finalize_ssa_defs): Same as above.
	(build_ssa_operands): Same as above, plus create a C-like wrapper.
	(update_stmt_operands): Create an instance of operands_scanner.
---
 gcc/tree-ssa-operands.c | 306 +---
 1 file changed, 189 insertions(+), 117 deletions(-)

diff --git a/gcc/tree-ssa-operands.c b/gcc/tree-ssa-operands.c
index b525ee318a4..f4716d0e36f 100644
--- a/gcc/tree-ssa-operands.c
+++ b/gcc/tree-ssa-operands.c
@@ -99,23 +99,111 @@ along with GCC; see the file COPYING3.  If not see
 /* Operand is having its address taken.  */
 #define opf_address_taken (1 << 5)
 
-/* Array for building all the use operands.  */
-static vec build_uses;
+/* Class containing temporary per-stmt state.  */
 
-/* The built VDEF operand.  */
-static tree build_vdef;
+class operands_scanner
+{
+  public:
+operands_scanner (struct function *fun, gimple *statement)
+  {
+	build_vuse = NULL_TREE;
+	build_vdef = NULL_TREE;
+	fn = fun;
+	stmt = statement;
+  }
+
+/* Create an operands cache for STMT.  */
+void build_ssa_operands ();
+
+/* Verifies SSA statement operands.  */
+DEBUG_FUNCTION bool verify_ssa_operands ();
+
+  private:
+/* Disable copy and assign of this class, as it may have problems with
+   build_uses vec.  */
+DISABLE_COPY_AND_ASSIGN (operands_scanner);
+
+/* Array for building all the use operands.  */
+auto_vec build_uses;
+
+/* The built VDEF operand.  */
+tree build_vdef;
+
+/* The built VUSE operand.  */
+tree build_vuse;
+
+/* Function which STMT belongs to.  */
+struct function *fn;
+
+/* Statement to work on.  */
+gimple *stmt;
+
+/* Takes elements from build_uses and turns them into use operands of STMT.  */
+void finalize_ssa_uses ();
+
+/* Clear the in_list bits and empty the build array for VDEFs and
+   VUSEs.  */
+void cleanup_build_arrays ();
+
+/* Finalize all the build vectors, fill the new ones into INFO.  */
+void finalize_ssa_stmt_operands ();
+
+/* Start the process of building up operands vectors in INFO.  */
+void start_ssa_stmt_operands ();
+
+/* Add USE_P to the list of pointers to operands.  */
+void append_use (tree *use_p);
 
-/* The built VUSE operand.  */
-static tree build_vuse;
+/* Add VAR to the set of variables that require a VDEF operator.  */
+void append_vdef (tree var);
 
-/* 

[committed] libstdc++: Fix broken link to SGI STL FAQ

[Jonathan Wakely via Gcc-patches]

The previous URL to an entry in the wayback machine now redirects to a
page saying "SGI.com Tech Archive Resources now retired" so use an older
entry from the archive.

* doc/xml/faq.xml: Use working link for SGI STL FAQ.
* doc/html/*: Regenerate.

Committed to master, I'll backport it too.

commit ae8a08ff59d28b17489d5c454bc07bfb70f0dff9
Author: Jonathan Wakely 
Date:   Mon May 4 22:54:25 2020 +0100

libstdc++: Fix broken link to SGI STL FAQ

The previous URL to an entry in the wayback machine now redirects to a
page saying "SGI.com Tech Archive Resources now retired" so use an older
entry from the archive.

* doc/xml/faq.xml: Use working link for SGI STL FAQ.
* doc/html/*: Regenerate.

diff --git a/libstdc++-v3/doc/xml/faq.xml b/libstdc++-v3/doc/xml/faq.xml
index aff6c8d6004..cf8684e1cea 100644
--- a/libstdc++-v3/doc/xml/faq.xml
+++ b/libstdc++-v3/doc/xml/faq.xml
@@ -2,9 +2,9 @@
 
 
 
- 
+
 Frequently Asked Questions
-  
+
   
 
   2008-2018
@@ -36,7 +36,7 @@
  exactly how far the project has come, or just want the latest
  bleeding-edge code, the up-to-date source can be cloned via
  http://www.w3.org/1999/xlink; 
xlink:href="https://gcc.gnu.org/git.html;>Git.
- 
+
 
 
 N.B. The library is called libstdc++ not stdlibc++.
@@ -58,7 +58,7 @@
 (as the Draft Standard used to say) incomplet and
 incorrekt, and many suffered from limitations of the compilers
 that used them.
- 
+
 
 The GNU compiler collection
 (gcc, g++, etc) is widely
@@ -68,7 +68,7 @@
 the rapid development and near-legendary
 http://www.w3.org/1999/xlink; 
xlink:href="https://gcc.gnu.org/buildstat.html;>portability
 that are the hallmarks of an open-source project are applied to libstdc++.
- 
+
 
 All of the standard classes and functions from C++98/C++03, C++11 and C++14
 (such as string,
@@ -100,7 +100,7 @@
 archives, is open to everyone.  You can read instructions for
 doing so on the http://www.w3.org/1999/xlink; 
xlink:href="https://gcc.gnu.org/lists.html;>GCC mailing lists page.
 If you have questions, ideas, code, or are just curious, sign up!
- 
+
   
 
 
@@ -115,7 +115,7 @@
 Nathan Myers gave the best of all possible answers, responding to
 a Usenet article asking this question: Sooner, if you
 help.
- 
+
   
 
 
@@ -135,7 +135,7 @@
 anybody who is willing to help write documentation, for example,
 or has found a bug in code that we all thought was working and is
 willing to provide details, is more than welcome!
- 
+
   
 
 
@@ -152,7 +152,7 @@
 being developed.
 It should not be used for new projects, and won't even compile with
 recent releases of GCC (or most other C++ compilers).
- 
+
 
 More information can be found in the
 Backwards
@@ -175,13 +175,13 @@
 information is available on the homepage (including how to browse
 the list archives); to send a message to the list,
 use libstd...@gcc.gnu.org.
- 
+
 
- 
+
 If you have a question that you think should be included
 here, or if you have a question about a 
question/answer
 here, please send email to the libstdc++ mailing list, as above.
- 
+
   
 
 
@@ -201,7 +201,7 @@
 
 See our license 
description
 for these and related questions.
- 
+
   
 
 
@@ -215,7 +215,7 @@
 
  No. The special exception permits use of the library in
  proprietary applications.
- 
+
   
 
 
@@ -235,7 +235,7 @@
  are expanded inside the code that uses the library.  So to allow people
  to replace the library code, someone using the library would have to
  distribute their own source, rendering the LGPL equivalent to the GPL.
- 
+
   
 
 
@@ -249,7 +249,7 @@
 
   None.  We encourage such programs to be released as free software,
  but we won't punish you or sue you if you choose otherwise.
- 
+
   
 
 
@@ -271,14 +271,14 @@
 development tools. It may be necessary to install extra
 development packages to get the headers, or the documentation, or
 the source: please consult your vendor for details.
- 
- 
-To build and install from the GNU GCC sources, please consult the 
+
+
+To build and install from the GNU GCC sources, please consult the
 setup
 documentation for detailed
 instructions. You may wish to browse those files ahead
 of time to get a feel for what's required.
- 
+
   
 
 
@@ -313,12 +313,12 @@
 
 Libstdc++ comes with its own validation testsuite, which includes
 conformance testing, regression testing, ABI testing, and
-performance testing. Please consult the 
+performance testing. Please consult the
 http://www.w3.org/1999/xlink; 
xlink:href="http://gcc.gnu.org/install/test.html;>testing
 documentation for GCC and
 

[committed] libstdc++: Fix incorrect size calculation in PMR resource (PR 94906)

[Jonathan Wakely via Gcc-patches]

Calculating the size of a chunk being returned to the upstream allocator
was done with a 32-bit type, so it wrapped if the chunk was 4GB or
larger.

I don't know how to test this without allocating 4GB, so there's no test
in the testsuite. It has been tested manually with allocations sizes and
alignments exceeding 4GB.

PR libstdc++/94906
* src/c++17/memory_resource.cc
(monotonic_buffer_resource::_Chunk::release): Use size_t for shift
operands.

Tested powerpc64le-linux, committed to master.

Backports to follow after 10.1 is released.


commit bb27781b64162e1769df15e0c97e8d2145d2d10d
Author: Jonathan Wakely 
Date:   Mon May 4 21:13:28 2020 +0100

libstdc++: Fix incorrect size calculation in PMR resource  (PR 94906)

Calculating the size of a chunk being returned to the upstream allocator
was done with a 32-bit type, so it wrapped if the chunk was 4GB or
larger.

I don't know how to test this without allocating 4GB, so there's no test
in the testsuite. It has been tested manually with allocations sizes and
alignments exceeding 4GB.

PR libstdc++/94906
* src/c++17/memory_resource.cc
(monotonic_buffer_resource::_Chunk::release): Use size_t for shift
operands.

diff --git a/libstdc++-v3/src/c++17/memory_resource.cc 
b/libstdc++-v3/src/c++17/memory_resource.cc
index 1acab19e306..95352b23537 100644
--- a/libstdc++-v3/src/c++17/memory_resource.cc
+++ b/libstdc++-v3/src/c++17/memory_resource.cc
@@ -228,8 +228,8 @@ namespace pmr
  if (__ch->_M_canary != (__ch->_M_size | __ch->_M_align))
return; // buffer overflow detected!
 
- size_t __size = (1u << __ch->_M_size);
- size_t __align = (1u << __ch->_M_align);
+ size_t __size = (size_t)1 << __ch->_M_size;
+ size_t __align = (size_t)1 << __ch->_M_align;
  void* __start = (char*)(__ch + 1) - __size;
  __r->deallocate(__start, __size, __align);
}

Re: [PATCH v3] c++: Member template function lookup failure [PR94799]

[Jason Merrill via Gcc-patches]

On 5/4/20 4:37 PM, Marek Polacek wrote:

On Fri, May 01, 2020 at 04:12:35PM -0400, Jason Merrill wrote:

@@ -7754,9 +7755,22 @@ cp_parser_postfix_dot_deref_expression (cp_parser 
*parser,
   }
 if (dependent_p)
-/* Tell cp_parser_lookup_name that there was an object, even though it's
-   type-dependent.  */
-parser->context->object_type = unknown_type_node;
+{
+  /* If we don't have a (type-dependent) object of class type, use
+decltype to signal that there was an object.  */
+  if (type == NULL_TREE)
+   {
+ type = finish_decltype_type (postfix_expression,
+  /*member_access_p=*/true,


This should be false, we don't want the special decltype semantics for a
member-access expression.


Fixed.


+  tf_warning_or_error);
+ /* For -> this decltype will produce T*, but we want T.  */
+ if (token_type == CPP_DEREF)
+   type = build_min_nt_loc (start_loc, INDIRECT_REF, type);


Don't we want the INDIRECT_REF inside the decltype?  How does it work like
this?


I'm now not quite sure what I perpetrated there; I must've messed it up when I 
was
looking at what we do with it in the debugger.  I assume it worked by accident.

I've moved the INDIRECT_REF inside the decltype, but I had to use the original
expression


Hmm, I would expect the type of the ARROW_EXPR to be what we want 
without messing with INDIRECT_REF separately.



and also set DECLTYPE_FOR_LAMBDA_CAPTURE so that the result of the
decltype is e.g. M, not M &.  Not sure how hacky this is, but I've
verified that tsubst/TYPENAME_TYPE now gets what I would expect it to.


Hmm, does it work to use finish_typeof instead?  If not, using that flag 
is fine, but we should rename it.  :)



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

-- >8 --
Whew, this took a while.  We fail to parse "p->template A::a()"
(where p is of type A *) because since r249752 we treat the RHS of the ->
as dependent and avoid a lookup in the enclosing context: since that rev
cp_parser_template_name checks parser->context->object_type too, which
here is unknown_type_node, signalling a type-dependent object:

  7756   if (dependent_p)
  7757 /* Tell cp_parser_lookup_name that there was an object, even though 
it's
  7758type-dependent.  */
  7759 parser->context->object_type = unknown_type_node;

with which cp_parser_template_name returns identifier 'A', cp_parser_class_name
then creates a TEMPLATE_ID_EXPR A, but then

23735   decl = make_typename_type (scope, decl, tag_type, tf_error);

in cp_parser_class_name fails because scope is NULL.  Then we return
error_mark_node and parse errors ensue.

I've tried various approaches, e.g. keeping TEMPLATE_ID_EXPR around
instead of calling make_typename_type, which didn't work, whereupon I
realized that since we don't want to perform name lookup if we've seen
the template keyword and the scope is dependent, we can adjust
parser->context->object_type and use the type of the object expression
as the scope, even if it's type-dependent.  This should be in line with
[basic.lookup.classref]p4.  If the postfix expression doesn't have a type,
use decltype (possibly dereferenced) to carry its type.  This decltype
will be processed in tsubst/TYPENAME_TYPE.

PR c++/94799
* parser.c (cp_parser_postfix_dot_deref_expression): If we have
a type-dependent object of class type, stash it to
parser->context->object_type.  If the postfix expression doesn't have
a type, use decltype.
(cp_parser_class_name): Consider object scope too.
(cp_parser_lookup_name): Remove code dealing with the case when
object_type is unknown_type_node.

* g++.dg/lookup/this1.C: Adjust dg-error.
* g++.dg/template/lookup12.C: New test.
* g++.dg/template/lookup13.C: New test.
* g++.dg/template/lookup14.C: New test.
* g++.dg/template/lookup15.C: New test.
---
  gcc/cp/parser.c  | 39 ++--
  gcc/testsuite/g++.dg/lookup/this1.C  |  2 +-
  gcc/testsuite/g++.dg/template/lookup12.C | 26 
  gcc/testsuite/g++.dg/template/lookup13.C | 28 +
  gcc/testsuite/g++.dg/template/lookup14.C | 11 +++
  gcc/testsuite/g++.dg/template/lookup15.C | 24 +++
  6 files changed, 120 insertions(+), 10 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/template/lookup12.C
  create mode 100644 gcc/testsuite/g++.dg/template/lookup13.C
  create mode 100644 gcc/testsuite/g++.dg/template/lookup14.C
  create mode 100644 gcc/testsuite/g++.dg/template/lookup15.C

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 337f22d2784..673f3622125 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -7694,6 +7694,7 @@ cp_parser_postfix_dot_deref_expression (cp_parser *parser,
bool pseudo_destructor_p;
tree scope = NULL_TREE;
location_t 

Re: [PATCH] c++: Avoid unnecessary copying in cp_fold [PR94038]

[Jason Merrill via Gcc-patches]

On 5/4/20 3:44 PM, Patrick Palka wrote:

When folding a CALL_EXPR, we can avoid copying it until folding changes
one of its arguments.  And when folding a TREE_VEC, we can avoid using
an intermediate releasing_vec by working with a copy of the TREE_VEC as
soon as folding changes one of its arguments, like we do in the
CALL_EXPR case.

Incidentally, the CALL_EXPR change also fixes the testcase in PR94038.
The reason is that the call to maybe_constant_value from cp_fold on
bar() now reuses the result of the earlier call to
maybe_constant_value from fold_for_warn, via the cv_cache.  This earlier
call passes uid_sensitive=true, whereas the call from cp_fold passes
uid_sensitive=false, and so by reusing the earlier call we now avoid
instantiating bar at all.

Passes 'make check-c++', does this look OK to commit to master after a
full bootstrap and regtest?


OK.


gcc/cp/ChangeLog:

PR c++/94038
* cp-gimplify.c (cp_fold) : Move some variable
declarations closer to their uses.  Copy the CALL_EXPR only
when one of its arguments has changed.
(cp_fold) : Instead of first collecting the
folded arguments into a releasing_vec, just make a copy of the
TREE_VEC as soon as folding changes one of its arguments.

gcc/testsuite/ChangeLog:

PR c++/94038
* g++.dg/warn/pr94038.C: New test.
---
  gcc/cp/cp-gimplify.c| 39 -
  gcc/testsuite/g++.dg/warn/pr94038.C | 26 +++
  2 files changed, 42 insertions(+), 23 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/warn/pr94038.C

diff --git a/gcc/cp/cp-gimplify.c b/gcc/cp/cp-gimplify.c
index f326d71637b..fc26a85f43a 100644
--- a/gcc/cp/cp-gimplify.c
+++ b/gcc/cp/cp-gimplify.c
@@ -2744,7 +2744,7 @@ cp_fold (tree x)
  
  case CALL_EXPR:

{
-   int i, m, sv = optimize, nw = sv, changed = 0;
+   int sv = optimize, nw = sv;
tree callee = get_callee_fndecl (x);
  
  	/* Some built-in function calls will be evaluated at compile-time in

@@ -2770,10 +2770,9 @@ cp_fold (tree x)
break;
  }
  
-	x = copy_node (x);

-
-   m = call_expr_nargs (x);
-   for (i = 0; i < m; i++)
+   bool changed = false;
+   int m = call_expr_nargs (x);
+   for (int i = 0; i < m; i++)
  {
r = cp_fold (CALL_EXPR_ARG (x, i));
if (r != CALL_EXPR_ARG (x, i))
@@ -2783,9 +2782,11 @@ cp_fold (tree x)
x = error_mark_node;
break;
  }
-   changed = 1;
+   if (!changed)
+ x = copy_node (x);
+   CALL_EXPR_ARG (x, i) = r;
+   changed = true;
  }
-   CALL_EXPR_ARG (x, i) = r;
  }
if (x == error_mark_node)
  break;
@@ -2825,8 +2826,6 @@ cp_fold (tree x)
break;
  }
  
-	if (!changed)

- x = org_x;
break;
}
  
@@ -2865,24 +2864,18 @@ cp_fold (tree x)

  case TREE_VEC:
{
bool changed = false;
-   releasing_vec vec;
-   int i, n = TREE_VEC_LENGTH (x);
-   vec_safe_reserve (vec, n);
+   int n = TREE_VEC_LENGTH (x);
  
-	for (i = 0; i < n; i++)

+   for (int i = 0; i < n; i++)
  {
tree op = cp_fold (TREE_VEC_ELT (x, i));
-   vec->quick_push (op);
if (op != TREE_VEC_ELT (x, i))
- changed = true;
- }
-
-   if (changed)
- {
-   r = copy_node (x);
-   for (i = 0; i < n; i++)
- TREE_VEC_ELT (r, i) = (*vec)[i];
-   x = r;
+ {
+   if (!changed)
+ x = copy_node (x);
+   TREE_VEC_ELT (x, i) = op;
+   changed = true;
+ }
  }
}
  
diff --git a/gcc/testsuite/g++.dg/warn/pr94038.C b/gcc/testsuite/g++.dg/warn/pr94038.C

new file mode 100644
index 000..4edfae72d99
--- /dev/null
+++ b/gcc/testsuite/g++.dg/warn/pr94038.C
@@ -0,0 +1,26 @@
+// PR c++/94038
+// { dg-do compile { target c++11 } }
+// { dg-additional-options "-O -Wall" }
+
+template
+constexpr int
+foo()
+{
+  static_assert(T(1) == 0, "");
+  return 0;
+}
+
+template
+constexpr int
+bar()
+{
+  return foo();
+}
+
+constexpr int
+baz(int a)
+{
+  return a;
+}
+
+static_assert(decltype(baz(bar())){} == 0, "");

Re: [PATCH] PowerPC -mcpu=future Patch 4 of 7, Make sure an invalid instruction is not generated

[Segher Boessenkool]

Hi!

On Mon, Apr 27, 2020 at 03:57:59PM -0400, Michael Meissner wrote:
> +#ifndef SIZE
> +#define SIZE 5
> +#endif
> +
> +struct foo {
> +  unsigned int field;
> +  char pad[SIZE];
> +};
> +
> +struct foo *inc_load (struct foo *p, unsigned int *q)
> +{
> +  *q = (++p)->field; /* PLWZ, PADDI, STW.  */
> +  return p;
> +}

This makes me wonder what we do if the struct is a multiple of 65536
bytes big, do we still generate a paddi, or will we do the (smaller,
faster) addis?  Not that that matters so very much...

  ...

Yeah, we do do addis, neat!  :-)

Is it better to do paddi and then stw on the modified pointer, or to do
pstw on the original pointer (and the paddi independently)?  In this
testcase, and in general?  The second sequence is lower latency (via the
store), but takes more space.  We probably should do the same tradeoff
as we do with non-prefixed code (or is there any significant difference?)
but maybe that should be looked at again as well.  (Maybe it doesn't
happen often enough to matter either way?)


Segher

Re: [PATCH v3] c++: Member template function lookup failure [PR94799]

[Marek Polacek via Gcc-patches]

On Fri, May 01, 2020 at 04:12:35PM -0400, Jason Merrill wrote:
> > @@ -7754,9 +7755,22 @@ cp_parser_postfix_dot_deref_expression (cp_parser 
> > *parser,
> >   }
> > if (dependent_p)
> > -/* Tell cp_parser_lookup_name that there was an object, even though 
> > it's
> > -   type-dependent.  */
> > -parser->context->object_type = unknown_type_node;
> > +{
> > +  /* If we don't have a (type-dependent) object of class type, use
> > +decltype to signal that there was an object.  */
> > +  if (type == NULL_TREE)
> > +   {
> > + type = finish_decltype_type (postfix_expression,
> > +  /*member_access_p=*/true,
> 
> This should be false, we don't want the special decltype semantics for a
> member-access expression.

Fixed.

> > +  tf_warning_or_error);
> > + /* For -> this decltype will produce T*, but we want T.  */
> > + if (token_type == CPP_DEREF)
> > +   type = build_min_nt_loc (start_loc, INDIRECT_REF, type);
> 
> Don't we want the INDIRECT_REF inside the decltype?  How does it work like
> this?

I'm now not quite sure what I perpetrated there; I must've messed it up when I 
was
looking at what we do with it in the debugger.  I assume it worked by accident.

I've moved the INDIRECT_REF inside the decltype, but I had to use the original
expression, and also set DECLTYPE_FOR_LAMBDA_CAPTURE so that the result of the
decltype is e.g. M, not M &.  Not sure how hacky this is, but I've
verified that tsubst/TYPENAME_TYPE now gets what I would expect it to.

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

-- >8 --
Whew, this took a while.  We fail to parse "p->template A::a()"
(where p is of type A *) because since r249752 we treat the RHS of the ->
as dependent and avoid a lookup in the enclosing context: since that rev
cp_parser_template_name checks parser->context->object_type too, which
here is unknown_type_node, signalling a type-dependent object:

 7756   if (dependent_p)
 7757 /* Tell cp_parser_lookup_name that there was an object, even though 
it's
 7758type-dependent.  */
 7759 parser->context->object_type = unknown_type_node;

with which cp_parser_template_name returns identifier 'A', cp_parser_class_name
then creates a TEMPLATE_ID_EXPR A, but then

23735   decl = make_typename_type (scope, decl, tag_type, tf_error);

in cp_parser_class_name fails because scope is NULL.  Then we return
error_mark_node and parse errors ensue.

I've tried various approaches, e.g. keeping TEMPLATE_ID_EXPR around
instead of calling make_typename_type, which didn't work, whereupon I
realized that since we don't want to perform name lookup if we've seen
the template keyword and the scope is dependent, we can adjust
parser->context->object_type and use the type of the object expression
as the scope, even if it's type-dependent.  This should be in line with
[basic.lookup.classref]p4.  If the postfix expression doesn't have a type,
use decltype (possibly dereferenced) to carry its type.  This decltype
will be processed in tsubst/TYPENAME_TYPE.

PR c++/94799
* parser.c (cp_parser_postfix_dot_deref_expression): If we have
a type-dependent object of class type, stash it to
parser->context->object_type.  If the postfix expression doesn't have
a type, use decltype.
(cp_parser_class_name): Consider object scope too.
(cp_parser_lookup_name): Remove code dealing with the case when
object_type is unknown_type_node.

* g++.dg/lookup/this1.C: Adjust dg-error.
* g++.dg/template/lookup12.C: New test.
* g++.dg/template/lookup13.C: New test.
* g++.dg/template/lookup14.C: New test.
* g++.dg/template/lookup15.C: New test.
---
 gcc/cp/parser.c  | 39 ++--
 gcc/testsuite/g++.dg/lookup/this1.C  |  2 +-
 gcc/testsuite/g++.dg/template/lookup12.C | 26 
 gcc/testsuite/g++.dg/template/lookup13.C | 28 +
 gcc/testsuite/g++.dg/template/lookup14.C | 11 +++
 gcc/testsuite/g++.dg/template/lookup15.C | 24 +++
 6 files changed, 120 insertions(+), 10 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/template/lookup12.C
 create mode 100644 gcc/testsuite/g++.dg/template/lookup13.C
 create mode 100644 gcc/testsuite/g++.dg/template/lookup14.C
 create mode 100644 gcc/testsuite/g++.dg/template/lookup15.C

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 337f22d2784..673f3622125 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -7694,6 +7694,7 @@ cp_parser_postfix_dot_deref_expression (cp_parser *parser,
   bool pseudo_destructor_p;
   tree scope = NULL_TREE;
   location_t start_loc = postfix_expression.get_start ();
+  tree orig_expr = postfix_expression;
 
   /* If this is a `->' operator, dereference the pointer.  */
   if (token_type == CPP_DEREF)
@@ -7754,9 +7755,26 @@ cp_parser_postfix_dot_deref_expression 

Re: [PATCH] PowerPC -mcpu=future Patch 4 of 7, Make sure an invalid instruction is not generated

[Segher Boessenkool]

Hi!

On Mon, Apr 27, 2020 at 05:09:15PM -0500, will schmidt wrote:
> > * gcc.target/powerpc/prefix-no-premodify.c: Make sure we do not
> > generate the non-existent PLWZU instruction if -mcpu=future.
> 
> Should "premodify" instead be "no-update" or "no-update-forms" ?   I
> don't immediately see why "modify" is referenced.

The Power ISA calls it "update form", while GCC calls it "pre-modify"
("pre-increment", "pre-decrement"), or "address side effects", for how
it is put in RTL.

The ISA name makes more sense here I think, yes.


Segher

[Patch] PR fortran/93366 - ICE on invalid, reject invalid use of NULL() as argument

[Harald Anlauf]

The attached patch fixes a couple of cases where an invalid NULL() argument
provided to intrinsics produced either an ICE or was silently accepted.
We now reject them.

Steve Kargl provided an initial version, which I extended to catch a few
more cases.

Regtests with no new failures on x86_64-pc-linux-gnu.  OK for master?

Thanks,
Harald

2020-05-04  Steve Kargl  
Harald Anlauf  

PR fortran/93366
* check.c (gfc_check_associated, invalid_null_arg): Factorize
check for presence of invalid NULL() argument.
(gfc_check_kind, gfc_check_merge, gfc_check_shape)
(gfc_check_sizeof, gfc_check_spread, gfc_check_transfer): Use this
check for presence of invalid NULL() arguments.


2020-05-04  Harald Anlauf  

PR fortran/93366
* gfortran.dg/pr93366.f90: New test.



pr93366-patch
Description: Binary data


pr93366-testcase-patch
Description: Binary data

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

[Joseph Myers]

On Mon, 4 May 2020, Szabolcs Nagy wrote:

> i think __getauxval needs to be declared where it is used.

Yes.

> and libgcc should do a link test in configure becasuse a
> libc may provide sys/auxv.h but not have __getauxval e.g.
> musl libc does not export __getauxval, only getauxval.

libgcc can't do link tests, since it's built before libc.  It can use the 
glibc version number ($glibc_version_major and $glibc_version_minor) 
already computed in libgcc/configure.ac, which uses --with-glibc-version 
or target headers if available and otherwise defaults to 0.0.

A design principle is that glibc built with libgcc configured without 
glibc headers but with --with-glibc-version should produce an identical 
stripped binary to the glibc resulting from a longer alternating sequence 
of GCC and glibc builds.  So it is not correct for any libgcc 
functionality that would end up being linked into glibc binaries to depend 
on glibc headers or libraries being available when libgcc is configured.

Thus, this libgcc code should not actually be conditional on 
!inhibit_libc, without a fallback when configured using 
--with-glibc-version to specify a glibc version with __getauxval, because 
that would mean the modern process for bootstrapping a cross glibc build 
produces a glibc binary that quietly differs from one produced by a longer 
alternating sequence of builds (missing this constructor).

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

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

[H.J. Lu via Gcc-patches]

On Mon, May 4, 2020 at 12:48 PM Kees Cook  wrote:
>
> On Mon, May 04, 2020 at 12:02:45PM -0700, H.J. Lu wrote:
> > On Mon, May 4, 2020 at 11:21 AM 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), 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.
> > >
> >
> > https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545081.html
>
> Thanks!
>
> Would it be helpful for me to report a "Tested-by: Kees Cook..." or
> something similar on that thread? What's the best way to indicate that
> kind of review on gcc-patches?

Feedback of testing on Linux kernel is very useful.

-- 
H.J.

[pushed] coroutines: Mark the gro as artificial.

[Iain Sandoe]

Hi

This corrects an oversight; the coro.gro object is a a compiler-generated
entity and should be marked as artificial and ignored.

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

gcc/cp/ChangeLog:

2020-05-04  Iain Sandoe  

* coroutines.cc (morph_fn_to_coro): Mark the coro.gro variable
as artificial and ignored.
---
 gcc/cp/ChangeLog | 5 +
 gcc/cp/coroutines.cc | 2 ++
 2 files changed, 7 insertions(+)

diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
index e90d3d5a3b3..bc08b1de0ac 100644
--- a/gcc/cp/coroutines.cc
+++ b/gcc/cp/coroutines.cc
@@ -4234,6 +4234,8 @@ morph_fn_to_coro (tree orig, tree *resumer, tree 
*destroyer)
   gro = build_lang_decl (VAR_DECL, get_identifier ("coro.gro"),
  TREE_TYPE (get_ro));
   DECL_CONTEXT (gro) = current_scope ();
+  DECL_ARTIFICIAL (gro) = true;
+  DECL_IGNORED_P (gro) = true;
   add_decl_expr (gro);
   gro_bind_vars = gro;
 
-- 
2.24.1

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

[Kees Cook via Gcc-patches]

On Mon, May 04, 2020 at 12:02:45PM -0700, H.J. Lu wrote:
> On Mon, May 4, 2020 at 11:21 AM 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), 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.
> >
> 
> https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545081.html

Thanks!

Would it be helpful for me to report a "Tested-by: Kees Cook..." or
something similar on that thread? What's the best way to indicate that
kind of review on gcc-patches?

-- 
Kees Cook

[PATCH] c++: Avoid unnecessary copying in cp_fold [PR94038]

[Patrick Palka via Gcc-patches]

When folding a CALL_EXPR, we can avoid copying it until folding changes
one of its arguments.  And when folding a TREE_VEC, we can avoid using
an intermediate releasing_vec by working with a copy of the TREE_VEC as
soon as folding changes one of its arguments, like we do in the
CALL_EXPR case.

Incidentally, the CALL_EXPR change also fixes the testcase in PR94038.
The reason is that the call to maybe_constant_value from cp_fold on
bar() now reuses the result of the earlier call to
maybe_constant_value from fold_for_warn, via the cv_cache.  This earlier
call passes uid_sensitive=true, whereas the call from cp_fold passes
uid_sensitive=false, and so by reusing the earlier call we now avoid
instantiating bar at all.

Passes 'make check-c++', does this look OK to commit to master after a
full bootstrap and regtest?

gcc/cp/ChangeLog:

PR c++/94038
* cp-gimplify.c (cp_fold) : Move some variable
declarations closer to their uses.  Copy the CALL_EXPR only
when one of its arguments has changed.
(cp_fold) : Instead of first collecting the
folded arguments into a releasing_vec, just make a copy of the
TREE_VEC as soon as folding changes one of its arguments.

gcc/testsuite/ChangeLog:

PR c++/94038
* g++.dg/warn/pr94038.C: New test.
---
 gcc/cp/cp-gimplify.c| 39 -
 gcc/testsuite/g++.dg/warn/pr94038.C | 26 +++
 2 files changed, 42 insertions(+), 23 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/warn/pr94038.C

diff --git a/gcc/cp/cp-gimplify.c b/gcc/cp/cp-gimplify.c
index f326d71637b..fc26a85f43a 100644
--- a/gcc/cp/cp-gimplify.c
+++ b/gcc/cp/cp-gimplify.c
@@ -2744,7 +2744,7 @@ cp_fold (tree x)
 
 case CALL_EXPR:
   {
-   int i, m, sv = optimize, nw = sv, changed = 0;
+   int sv = optimize, nw = sv;
tree callee = get_callee_fndecl (x);
 
/* Some built-in function calls will be evaluated at compile-time in
@@ -2770,10 +2770,9 @@ cp_fold (tree x)
break;
  }
 
-   x = copy_node (x);
-
-   m = call_expr_nargs (x);
-   for (i = 0; i < m; i++)
+   bool changed = false;
+   int m = call_expr_nargs (x);
+   for (int i = 0; i < m; i++)
  {
r = cp_fold (CALL_EXPR_ARG (x, i));
if (r != CALL_EXPR_ARG (x, i))
@@ -2783,9 +2782,11 @@ cp_fold (tree x)
x = error_mark_node;
break;
  }
-   changed = 1;
+   if (!changed)
+ x = copy_node (x);
+   CALL_EXPR_ARG (x, i) = r;
+   changed = true;
  }
-   CALL_EXPR_ARG (x, i) = r;
  }
if (x == error_mark_node)
  break;
@@ -2825,8 +2826,6 @@ cp_fold (tree x)
break;
  }
 
-   if (!changed)
- x = org_x;
break;
   }
 
@@ -2865,24 +2864,18 @@ cp_fold (tree x)
 case TREE_VEC:
   {
bool changed = false;
-   releasing_vec vec;
-   int i, n = TREE_VEC_LENGTH (x);
-   vec_safe_reserve (vec, n);
+   int n = TREE_VEC_LENGTH (x);
 
-   for (i = 0; i < n; i++)
+   for (int i = 0; i < n; i++)
  {
tree op = cp_fold (TREE_VEC_ELT (x, i));
-   vec->quick_push (op);
if (op != TREE_VEC_ELT (x, i))
- changed = true;
- }
-
-   if (changed)
- {
-   r = copy_node (x);
-   for (i = 0; i < n; i++)
- TREE_VEC_ELT (r, i) = (*vec)[i];
-   x = r;
+ {
+   if (!changed)
+ x = copy_node (x);
+   TREE_VEC_ELT (x, i) = op;
+   changed = true;
+ }
  }
   }
 
diff --git a/gcc/testsuite/g++.dg/warn/pr94038.C 
b/gcc/testsuite/g++.dg/warn/pr94038.C
new file mode 100644
index 000..4edfae72d99
--- /dev/null
+++ b/gcc/testsuite/g++.dg/warn/pr94038.C
@@ -0,0 +1,26 @@
+// PR c++/94038
+// { dg-do compile { target c++11 } }
+// { dg-additional-options "-O -Wall" }
+
+template
+constexpr int
+foo()
+{
+  static_assert(T(1) == 0, "");
+  return 0;
+}
+
+template
+constexpr int
+bar()
+{
+  return foo();
+}
+
+constexpr int
+baz(int a)
+{
+  return a;
+}
+
+static_assert(decltype(baz(bar())){} == 0, "");
-- 
2.26.2.447.gd61d20c9b4

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

[H.J. Lu via Gcc-patches]

On Mon, May 4, 2020 at 11:21 AM 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), 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.
>

https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545081.html


-- 
H.J.

[PATCH 1/4] matcher-1.m: Change return type to int

[H.J. Lu via Gcc-patches]

my_exception_matcher must return int.  Otherwise, this test fails.

PR testsuite/84324
* objc/execute/exceptions/matcher-1.m (my_exception_matcher):
Change return type to int.
---
 gcc/testsuite/objc/execute/exceptions/matcher-1.m | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/objc/execute/exceptions/matcher-1.m 
b/gcc/testsuite/objc/execute/exceptions/matcher-1.m
index cbe4365da90..25d6759cc9c 100644
--- a/gcc/testsuite/objc/execute/exceptions/matcher-1.m
+++ b/gcc/testsuite/objc/execute/exceptions/matcher-1.m
@@ -20,7 +20,7 @@ int main(void)
 
 static unsigned int handlerExpected = 0;
 
-void
+int
 my_exception_matcher(Class match_class, id exception)
 {
   /* Always matches.  */
-- 
2.26.2

[PATCH 4/4] Update gcc.target/i386/ret-thunk-2[234].c

[H.J. Lu via Gcc-patches]

---
 gcc/testsuite/gcc.target/i386/ret-thunk-22.c | 2 +-
 gcc/testsuite/gcc.target/i386/ret-thunk-23.c | 2 +-
 gcc/testsuite/gcc.target/i386/ret-thunk-24.c | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/gcc/testsuite/gcc.target/i386/ret-thunk-22.c 
b/gcc/testsuite/gcc.target/i386/ret-thunk-22.c
index 9a9f42ea6a1..5796148c652 100644
--- a/gcc/testsuite/gcc.target/i386/ret-thunk-22.c
+++ b/gcc/testsuite/gcc.target/i386/ret-thunk-22.c
@@ -7,7 +7,7 @@ struct s gs = { 100 + 200i };
 struct s __attribute__((noinline)) foo (void) { return gs; }
 
 /* { dg-final { scan-assembler-times "popl\[\\t \]*%ecx" 1 { target { ! 
*-*-darwin* } } } } */
-/* { dg-final { scan-assembler "lea\[l\]?\[\\t \]*4\\(%esp\\), %esp" { target 
{ ! *-*-darwin* } } } } */
+/* { dg-final { scan-assembler-times "popl\[\\t \]*%edx" 1 { target { ! 
*-*-darwin* } } } } */
 /* { dg-final { scan-assembler "jmp\[ \t\]*_?__x86_return_thunk_ecx" { target 
{ ! *-*-darwin* } } } } */
 /* { dg-final { scan-assembler {call[ \t]*___x86.get_pc_thunk.cx} { target { 
*-*-darwin* } } } } */
 /* { dg-final { scan-assembler {jmp[ \t]*___x86_return_thunk} { target { 
*-*-darwin* } } } } */
diff --git a/gcc/testsuite/gcc.target/i386/ret-thunk-23.c 
b/gcc/testsuite/gcc.target/i386/ret-thunk-23.c
index 69469a43606..1739d8f8d53 100644
--- a/gcc/testsuite/gcc.target/i386/ret-thunk-23.c
+++ b/gcc/testsuite/gcc.target/i386/ret-thunk-23.c
@@ -7,7 +7,7 @@ struct s gs = { 100 + 200i };
 struct s __attribute__((noinline)) foo (void) { return gs; }
 
 /* { dg-final { scan-assembler-times "popl\[\\t \]*%ecx" 1 { target { ! 
*-*-darwin* } } } } */
-/* { dg-final { scan-assembler "lea\[l\]?\[\\t \]*4\\(%esp\\), %esp" { target 
{ ! *-*-darwin* } } } } */
+/* { dg-final { scan-assembler-times "popl\[\\t \]*%edx" 1 { target { ! 
*-*-darwin* } } } } */
 /* { dg-final { scan-assembler "jmp\[ \t\]*_?__x86_return_thunk_ecx" { target 
{ ! *-*-darwin* } } } } */
 /* { dg-final { scan-assembler {call[ \t]*___x86.get_pc_thunk.cx} { target { 
*-*-darwin* } } } } */
 /* { dg-final { scan-assembler {jmp[ \t]*___x86_return_thunk} { target { 
*-*-darwin* } } } } */
diff --git a/gcc/testsuite/gcc.target/i386/ret-thunk-24.c 
b/gcc/testsuite/gcc.target/i386/ret-thunk-24.c
index 0e7877970d7..4df5d9b8131 100644
--- a/gcc/testsuite/gcc.target/i386/ret-thunk-24.c
+++ b/gcc/testsuite/gcc.target/i386/ret-thunk-24.c
@@ -7,7 +7,7 @@ struct s gs = { 100 + 200i };
 struct s __attribute__((noinline)) foo (void) { return gs; }
 
 /* { dg-final { scan-assembler-times "popl\[\\t \]*%ecx" 1 { target { ! 
*-*-darwin* } } } } */
-/* { dg-final { scan-assembler "lea\[l\]?\[\\t \]*4\\(%esp\\), %esp" { target 
{ ! *-*-darwin* } } } } */
+/* { dg-final { scan-assembler-times "popl\[\\t \]*%edx" 1 { target { ! 
*-*-darwin* } } } } */
 /* { dg-final { scan-assembler-not "jmp\[ \t\]*_?__x86_return_thunk_ecx" { 
target { ! *-*-darwin* } } } } */
 /* { dg-final { scan-assembler {call[ \t]*___x86.get_pc_thunk.cx} { target { 
*-*-darwin* } } } } */
 /* { dg-final { scan-assembler-not {jmp[ \t]*___x86_return_thunk} { target { 
*-*-darwin* } } } } */
-- 
2.26.2

[PATCH 2/4] x86: Add -mzero-caller-saved-regs=[skip|used-gpr|all-gpr|used|all]

[H.J. Lu via Gcc-patches]

Add -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")

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

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

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

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

Tested on i686 and x86-64 with bootstrapping GCC trunk, making
-mzero-caller-saved-regs=used-gpr, -mzero-caller-saved-regs=all-gpr
-mzero-caller-saved-regs=used, and -mzero-caller-saved-regs=all enabled
by default.

gcc/

* i386-expand.c (ix86_find_live_outgoing_regs): New function.
(ix86_split_simple_return_pop_internal): Removed.
(ix86_split_simple_return_internal): New function.
* config/i386/i386-options.c (ix86_set_zero_caller_saved_regs_type):
New function.
(ix86_set_current_function): Call ix86_set_zero_caller_saved_regs_type.
(ix86_handle_fndecl_attribute): Support zero_caller_saved_regs
attribute.
(ix86_attribute_table): Add zero_caller_saved_regs.
* config/i386/i386-opts.h (zero_caller_saved_regs): New enum.
* config/i386/i386-protos.h (ix86_split_simple_return_pop_internal):
Renamed to ...
(ix86_split_simple_return_internal): This.
* config/i386/i386.c (ix86_expand_prologue): Replace
gen_prologue_use with gen_pro_epilogue_use.
(ix86_expand_epilogue): Replace gen_simple_return_pop_internal
with ix86_split_simple_return_internal.  Replace
gen_simple_return_internal with ix86_split_simple_return_internal.
* config/i386/i386.h (machine_function): Add
zero_caller_saved_regs_type, live_outgoing_int_regs and
live_outgoing_vector_regs.
(TARGET_POP_SCRATCH_REGISTER): New.
* config/i386/i386.md (UNSPEC_SIMPLE_RETURN): New UNSPEC.
(UNSPECV_PROLOGUE_USE): Renamed to ...
(UNSPECV_PRO_EPILOGUE_USE): This.
(prologue_use): Renamed to ...
(pro_epilogue_use): This.
(simple_return_internal): Changed to define_insn_and_split.
(simple_return_internal_1): New pattern.
(simple_return_pop_internal): Replace
ix86_split_simple_return_pop_internal with
ix86_split_simple_return_internal.  Always call
ix86_split_simple_return_internal if epilogue_completed is
true.
(simple_return_pop_internal_1): New pattern.
(Epilogue deallocator to pop peepholes): Enabled only if
TARGET_POP_SCRATCH_REGISTER is true.
* config/i386/i386.opt (mzero-caller-saved-regs=): New option.
* doc/extend.texi: Document zero_caller_saved_regs attribute.
* doc/invoke.texi: Document -mzero-caller-saved-regs=.

gcc/testsuite/

* gcc.target/i386/zero-scratch-regs-1.c: New test.
* gcc.target/i386/zero-scratch-regs-2.c: Likewise.
* gcc.target/i386/zero-scratch-regs-3.c: Likewise.
* gcc.target/i386/zero-scratch-regs-4.c: Likewise.
* gcc.target/i386/zero-scratch-regs-5.c: Likewise.
* gcc.target/i386/zero-scratch-regs-6.c: Likewise.
* gcc.target/i386/zero-scratch-regs-7.c: Likewise.
* gcc.target/i386/zero-scratch-regs-8.c: Likewise.
* gcc.target/i386/zero-scratch-regs-9.c: Likewise.
* gcc.target/i386/zero-scratch-regs-10.c: Likewise.
* gcc.target/i386/zero-scratch-regs-11.c: Likewise.
* gcc.target/i386/zero-scratch-regs-12.c: Likewise.
* gcc.target/i386/zero-scratch-regs-13.c: Likewise.
* gcc.target/i386/zero-scratch-regs-14.c: Likewise.
* gcc.target/i386/zero-scratch-regs-15.c: Likewise.
* gcc.target/i386/zero-scratch-regs-16.c: Likewise.
* gcc.target/i386/zero-scratch-regs-17.c: Likewise.
* gcc.target/i386/zero-scratch-regs-18.c: Likewise.
* gcc.target/i386/zero-scratch-regs-19.c: Likewise.
* gcc.target/i386/zero-scratch-regs-20.c: Likewise.
* gcc.target/i386/zero-scratch-regs-21.c: Likewise.
* gcc.target/i386/zero-scratch-regs-22.c: Likewise.
* gcc.target/i386/zero-scratch-regs-23.c: Likewise.
---
 gcc/config/i386/i386-expand.c | 281 --
 gcc/config/i386/i386-options.c|  67 +
 gcc/config/i386/i386-opts.h   |   9 +
 gcc/config/i386/i386-protos.h |   2 +-
 gcc/config/i386/i386.c|   8 +-
 gcc/config/i386/i386.h|  16 +
 gcc/config/i386/i386.md   |  54 +++-
 

[PATCH 3/4] x86: Add ix86_any_return_p

[H.J. Lu via Gcc-patches]

Add ix86_any_return_p to check simple_return in a PARALLEL to support:

(jump_insn 39 38 40 5 (parallel [
(simple_return)
(unspec [
(const_int 0 [0])
] UNSPEC_SIMPLE_RETURN)
]) "/tmp/x.c":105 -1
 (nil)
 -> simple_return)

* config/i386/i386-expand.c (ix86_notrack_prefixed_insn_p):
Replace ANY_RETURN_P with ix86_any_return_p.
* config/i386/i386-features.c (rest_of_insert_endbranch):
Likewise.
* onfig/i386/i386-protos.h (ix86_any_return_p): New.
* config/i386/i386.c (ix86_any_return_p): New function.
(ix86_pad_returns): Replace ANY_RETURN_P with ix86_any_return_p.
(ix86_count_insn_bb): Likewise.
(ix86_pad_short_function): Likewise.
---
 gcc/config/i386/i386-expand.c   |  2 +-
 gcc/config/i386/i386-features.c |  2 +-
 gcc/config/i386/i386-protos.h   |  2 ++
 gcc/config/i386/i386.c  | 17 ++---
 4 files changed, 18 insertions(+), 5 deletions(-)

diff --git a/gcc/config/i386/i386-expand.c b/gcc/config/i386/i386-expand.c
index 371bbedd9a7..6dcd4554424 100644
--- a/gcc/config/i386/i386-expand.c
+++ b/gcc/config/i386/i386-expand.c
@@ -20143,7 +20143,7 @@ ix86_notrack_prefixed_insn_p (rtx_insn *insn)
   if (JUMP_P (insn) && !flag_cet_switch)
 {
   rtx target = JUMP_LABEL (insn);
-  if (target == NULL_RTX || ANY_RETURN_P (target))
+  if (target == NULL_RTX || ix86_any_return_p (target))
return false;
 
   /* Check the jump is a switch table.  */
diff --git a/gcc/config/i386/i386-features.c b/gcc/config/i386/i386-features.c
index 78fb373db6e..a1dd5dee42f 100644
--- a/gcc/config/i386/i386-features.c
+++ b/gcc/config/i386/i386-features.c
@@ -2030,7 +2030,7 @@ rest_of_insert_endbranch (void)
  if (JUMP_P (insn) && flag_cet_switch)
{
  rtx target = JUMP_LABEL (insn);
- if (target == NULL_RTX || ANY_RETURN_P (target))
+ if (target == NULL_RTX || ix86_any_return_p (target))
continue;
 
  /* Check the jump is a switch table.  */
diff --git a/gcc/config/i386/i386-protos.h b/gcc/config/i386/i386-protos.h
index 01732a225f4..5e6a07a6b60 100644
--- a/gcc/config/i386/i386-protos.h
+++ b/gcc/config/i386/i386-protos.h
@@ -210,6 +210,8 @@ extern void ix86_move_vector_high_sse_to_mmx (rtx);
 extern void ix86_split_mmx_pack (rtx[], enum rtx_code);
 extern void ix86_split_mmx_punpck (rtx[], bool);
 
+extern bool ix86_any_return_p (rtx);
+
 #ifdef TREE_CODE
 extern void init_cumulative_args (CUMULATIVE_ARGS *, tree, rtx, tree, int);
 #endif /* TREE_CODE  */
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index d433c3d33f2..80d0cfe96d2 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -20632,6 +20632,17 @@ ix86_avoid_jump_mispredicts (void)
 }
 #endif
 
+/* Return true if RET is a return, simple_return or simple_return in
+   a PARALLEL.  */
+
+bool
+ix86_any_return_p (rtx ret)
+{
+  return (ANY_RETURN_P (ret)
+ || (GET_CODE (ret) == PARALLEL
+ && GET_CODE (XVECEXP (ret, 0, 0)) == SIMPLE_RETURN));
+}
+
 /* AMD Athlon works faster
when RET is not destination of conditional jump or directly preceded
by other jump instruction.  We avoid the penalty by inserting NOP just
@@ -20649,7 +20660,7 @@ ix86_pad_returns (void)
   rtx_insn *prev;
   bool replace = false;
 
-  if (!JUMP_P (ret) || !ANY_RETURN_P (PATTERN (ret))
+  if (!JUMP_P (ret) || !ix86_any_return_p (PATTERN (ret))
  || optimize_bb_for_size_p (bb))
continue;
   for (prev = PREV_INSN (ret); prev; prev = PREV_INSN (prev))
@@ -20703,7 +20714,7 @@ ix86_count_insn_bb (basic_block bb)
 {
   /* Only happen in exit blocks.  */
   if (JUMP_P (insn)
- && ANY_RETURN_P (PATTERN (insn)))
+ && ix86_any_return_p (PATTERN (insn)))
break;
 
   if (NONDEBUG_INSN_P (insn)
@@ -20776,7 +20787,7 @@ ix86_pad_short_function (void)
   FOR_EACH_EDGE (e, ei, EXIT_BLOCK_PTR_FOR_FN (cfun)->preds)
 {
   rtx_insn *ret = BB_END (e->src);
-  if (JUMP_P (ret) && ANY_RETURN_P (PATTERN (ret)))
+  if (JUMP_P (ret) && ix86_any_return_p (PATTERN (ret)))
{
  int insn_count = ix86_count_insn (e->src);
 
-- 
2.26.2

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

[Kees Cook via Gcc-patches]

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), 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

Re: [PATCH] contrib/vimrc: Reduce textwidth for commit messages

[Martin Liška]

On 4/29/20 7:14 PM, Jakub Jelinek via Gcc-patches wrote:

On Wed, Apr 29, 2020 at 11:06:27AM -0600, Jeff Law via Gcc-patches wrote:

On Tue, 2020-04-28 at 00:31 -0400, Patrick Palka via Gcc-patches wrote:

The bundled vimrc script, when enabled, currently sets the text width to
80 characters for all files within the source directory.  Unfortunately
this means the setting also applies when editing .git/COMMIT_EDITMSG,
overriding the default and standard text width of 72 for Git commit
messages.  (A text width of 80 is too much for commit messages because
Git indents commit messages by four spaces when displaying them via e.g.
git log, leading to a total displayed width of 84 characters.)

This patch explicitly sets the text width of Git commit messages to 72
characters in accordance with standard practice.  (Alternatively we
could avoid setting textwidth at all in this case and let the defaults
kick in, but maybe it's better to be explicit?)

Tested by writing up this commit message :)  Is this OK to commit?

contrib/ChangeLog:

* vimrc: Reduce textwidth to 72 for Git commit messages.

OK


Though, if we go for the ChangeLog entries in commit messages as the source
for auto-appended ChangeLog files during DATESTAMP update, as Martin Liska
is working on - see https://github.com/marxin/gcc-changelog/ -
won't this cause people to wrap ChangeLog entries too early in there?


Hi.

It seems that 'git 50/72' rule of thumb is well established term used in Git 
world:
https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
https://stackoverflow.com/questions/2290016/git-commit-messages-50-72-formatting

I would follow it as well. People normally use git log with no arguments and
the leading 4 spaces will be displayed.

I support the patch,
Martin


Because for the script what git log --format=%B is what really matters.

Jakub

[PR libstdc++/94747] negating a size_t does not show intent

[Nathan Sidwell]

Pushed this patch to dynamic_cast.  We negate an offsetof value, which 
although well formed, it doesn't show intent well.  The reason checkers 
trigger on this is that it is a cause of real bugs.  So, negate a 
ptrdiff_t instead.


nathan

--
Nathan Sidwell
2020-05-04  Nathan Sidwell  

	PR libstdc++/94747
	* libsupc++/dyncast.cc (__dynamic_cast): Cast offsetof to
	ptrdiff_t before negation, to show intent more clearly.

diff --git i/libstdc++-v3/libsupc++/dyncast.cc w/libstdc++-v3/libsupc++/dyncast.cc
index 1254471f6e8..7a5f483f9cf 100644
--- i/libstdc++-v3/libsupc++/dyncast.cc
+++ w/libstdc++-v3/libsupc++/dyncast.cc
@@ -49,8 +49,8 @@ __dynamic_cast (const void *src_ptr,// object started from
   {
   const void *vtable = *static_cast  (src_ptr);
   const vtable_prefix *prefix =
-  adjust_pointer  (vtable, 
-  -offsetof (vtable_prefix, origin));
+(adjust_pointer 
+ (vtable,  -ptrdiff_t (offsetof (vtable_prefix, origin;
   const void *whole_ptr =
   adjust_pointer  (src_ptr, prefix->whole_object);
   const __class_type_info *whole_type = prefix->whole_type;
@@ -63,8 +63,8 @@ __dynamic_cast (const void *src_ptr,// object started from
   // segfault later trying to use a vbase offset that doesn't exist.
   const void *whole_vtable = *static_cast  (whole_ptr);
   const vtable_prefix *whole_prefix =
-adjust_pointer  (whole_vtable,
--offsetof (vtable_prefix, origin));
+(adjust_pointer 
+ (whole_vtable, -ptrdiff_t (offsetof (vtable_prefix, origin;
   if (whole_prefix->whole_type != whole_type)
 return NULL;
   
@@ -75,7 +75,8 @@ __dynamic_cast (const void *src_ptr,// object started from
   if (contained_public_p (result.dst2src))
 // Src is known to be a public base of dst.
 return const_cast  (result.dst_ptr);
-  if (contained_public_p (__class_type_info::__sub_kind (result.whole2src & result.whole2dst)))
+  if (contained_public_p (__class_type_info::__sub_kind
+			  (result.whole2src & result.whole2dst)))
 // Both src and dst are known to be public bases of whole. Found a valid
 // cross cast.
 return const_cast  (result.dst_ptr);

[committed] i386: Use SBB more [PR94650]

[Uros Bizjak via Gcc-patches]

When returning 0 or -1, "SBB reg,reg" instruction that borrows carry
flag can be used.  Carry flag can be generated by converting compare
with zero to a LTU compare with one, so e.g.

return -(x == 0)

generates:

cmpq$1, %rdi
sbbq%rax, %rax

instead of:

xorl%eax, %eax
testq   %rdi, %rdi
sete%al
negq%rax

A similar conversion can be used for

return -(x != 0)

where NEG insn can be used instead of compare.  According to x86 ISA,
NEG insn sets carry flag when the source operand is != 0, resulting in:

negq%rdi
sbbq%rax, %rax

The conversion avoids partial register stall with SETcc instructions.

2020-05-04  Uroš Bizjak  

PR target/94795
* config/i386/i386.md (*neg_ccc): New insn pattern.
(EQ compare->LTU compare splitter): New splitter.
(NE compare->NEG splitter): Ditto.

testsuite/ChangeLog:

2020-05-04  Uroš Bizjak  

PR target/94795
* gcc.target/i386/pr94795-1.c: New test.
* gcc.target/i386/pr94795-2.c: Ditto.

Patch was bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.

Committed to mainine.

Uros.
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index bd144ab3d5e..76c00867231 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -9900,6 +9900,17 @@
   [(set_attr "type" "negnot")
(set_attr "mode" "SI")])
 
+(define_insn "*neg_ccc"
+  [(set (reg:CCC FLAGS_REG)
+   (ne:CCC
+ (match_operand:SWI 1 "nonimmediate_operand" "0")
+ (const_int 0)))
+   (clobber (match_scratch:SWI 0 "="))]
+  ""
+  "neg{}\t%0"
+  [(set_attr "type" "negnot")
+   (set_attr "mode" "")])
+
 ;; Negate with jump on overflow.
 (define_expand "negv3"
   [(parallel [(set (reg:CCO FLAGS_REG)
@@ -18015,9 +18026,9 @@
(set_attr "length_immediate" "0")])
 
 (define_insn "*x86_movcc_0_m1_neg"
-  [(set (match_operand:SWI48 0 "register_operand" "=r")
-   (neg:SWI48 (match_operator 1 "ix86_carry_flag_operator"
-   [(reg FLAGS_REG) (const_int 0)])))
+  [(set (match_operand:SWI 0 "register_operand" "=")
+   (neg:SWI (match_operator 1 "ix86_carry_flag_operator"
+ [(reg FLAGS_REG) (const_int 0)])))
(clobber (reg:CC FLAGS_REG))]
   ""
   "sbb{}\t%0, %0"
@@ -18045,6 +18056,33 @@
  (clobber (reg:CC FLAGS_REG))])]
   "operands[2] = GEN_INT (INTVAL (operands[2]) + 1);")
 
+(define_split
+  [(set (match_operand:SWI 0 "register_operand")
+   (neg:SWI
+ (eq:SWI
+   (match_operand 1 "int_nonimmediate_operand")
+   (const_int 0]
+  ""
+  [(set (reg:CC FLAGS_REG) (compare:CC (match_dup 1) (const_int 1)))
+   (parallel [(set (match_dup 0)
+  (neg:SWI (ltu:SWI (reg:CC FLAGS_REG) (const_int 0
+ (clobber (reg:CC FLAGS_REG))])])
+
+(define_split
+  [(set (match_operand:SWI 0 "register_operand")
+   (neg:SWI
+ (ne:SWI
+   (match_operand 1 "int_nonimmediate_operand")
+   (const_int 0]
+  ""
+  [(parallel [(set (reg:CCC FLAGS_REG)
+  (ne:CCC (match_dup 1) (const_int 0)))
+ (clobber (match_dup 2))])
+   (parallel [(set (match_dup 0)
+  (neg:SWI (ltu:SWI (reg:CCC FLAGS_REG) (const_int 0
+ (clobber (reg:CC FLAGS_REG))])]
+  "operands[2] = gen_rtx_SCRATCH (GET_MODE (operands[1]));")
+
 (define_insn "*movcc_noc"
   [(set (match_operand:SWI248 0 "register_operand" "=r,r")
(if_then_else:SWI248 (match_operator 1 "ix86_comparison_operator"
diff --git a/gcc/testsuite/gcc.target/i386/pr94795-1.c 
b/gcc/testsuite/gcc.target/i386/pr94795-1.c
new file mode 100644
index 000..c87a3dd4030
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr94795-1.c
@@ -0,0 +1,21 @@
+/* PR target/94795 */
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+char fooc (char x)
+{
+  return x ? -1 : 0;
+}
+
+short foos (short x)
+{
+  return x ? -1 : 0;
+}
+
+long fooi (long x)
+{
+  return x ? -1 : 0;
+}
+
+/* { dg-final { scan-assembler-not "test|cmp" } } */
+/* { dg-final { scan-assembler-times "sbb" 3 } } */
diff --git a/gcc/testsuite/gcc.target/i386/pr94795-2.c 
b/gcc/testsuite/gcc.target/i386/pr94795-2.c
new file mode 100644
index 000..87d76299a8a
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr94795-2.c
@@ -0,0 +1,20 @@
+/* PR target/94795 */
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+char fooc (char x)
+{
+  return -(x == 0);
+}
+
+short foos (short x)
+{
+  return -(x == 0);
+}
+
+long fooi (long x)
+{
+  return -(x == 0);
+}
+
+/* { dg-final { scan-assembler-times "sbb" 3 } } */

[C++] template parm cleanup

[Nathan Sidwell]

When working on 94827 I noticed that process_template_parm was doing 
more work than necessary -- using 'last_node' and later 'chainon'.  This 
fixes that up to just walk the list once.


Also, I didn't understand the reason why end_template_parms does a pop 
of the dummy header, and then a push of the real one -- why not just 
modify the dummy in place?  Added a comment about that.


pushed to trunk.

nathan
--
Nathan Sidwell
2020-05-04  Nathan Sidwell  

	pt.c (process_template_parm): Don't walk the template list twice,
	remember the final node instead.
	(end_template_parm_list): Refactor.  Comment on why we do a pop
	and a push.

diff --git i/gcc/cp/pt.c w/gcc/cp/pt.c
index 8106c25a2d9..61cb75bf801 100644
--- i/gcc/cp/pt.c
+++ w/gcc/cp/pt.c
@@ -4496,29 +4496,27 @@ tree
 process_template_parm (tree list, location_t parm_loc, tree parm,
 		   bool is_non_type, bool is_parameter_pack)
 {
-  tree decl = 0;
-  int idx = 0;
-
   gcc_assert (TREE_CODE (parm) == TREE_LIST);
-  tree defval = TREE_PURPOSE (parm);
-  tree constr = TREE_TYPE (parm);
+  tree prev = NULL_TREE;
+  int idx = 0;
 
   if (list)
 {
-  tree p = tree_last (list);
+  prev = tree_last (list);
 
-  if (p && TREE_VALUE (p) != error_mark_node)
-{
-  p = TREE_VALUE (p);
-  if (TREE_CODE (p) == TYPE_DECL || TREE_CODE (p) == TEMPLATE_DECL)
-idx = TEMPLATE_TYPE_IDX (TREE_TYPE (p));
-  else
-idx = TEMPLATE_PARM_IDX (DECL_INITIAL (p));
-}
+  tree p = TREE_VALUE (prev);
+  if (TREE_CODE (p) == TYPE_DECL || TREE_CODE (p) == TEMPLATE_DECL)
+	idx = TEMPLATE_TYPE_IDX (TREE_TYPE (p));
+  else if (TREE_CODE (p) == PARM_DECL)
+	idx = TEMPLATE_PARM_IDX (DECL_INITIAL (p));
 
   ++idx;
 }
 
+  tree decl = NULL_TREE;
+  tree defval = TREE_PURPOSE (parm);
+  tree constr = TREE_TYPE (parm);
+
   if (is_non_type)
 {
   parm = TREE_VALUE (parm);
@@ -4616,7 +4614,12 @@ process_template_parm (tree list, location_t parm_loc, tree parm,
   parm = build_tree_list (defval, parm);
   TEMPLATE_PARM_CONSTRAINTS (parm) = reqs;
 
-  return chainon (list, parm);
+  if (prev)
+TREE_CHAIN (prev) = parm;
+  else
+list = parm;
+
+  return list;
 }
 
 /* The end of a template parameter list has been reached.  Process the
@@ -4627,22 +4630,24 @@ process_template_parm (tree list, location_t parm_loc, tree parm,
 tree
 end_template_parm_list (tree parms)
 {
-  int nparms;
-  tree parm, next;
   tree saved_parmlist = make_tree_vec (list_length (parms));
 
-  /* Pop the dummy parameter level and add the real one.  */
+  /* Pop the dummy parameter level and add the real one.  We do not
+ morph the dummy parameter in place, as it might have been
+ captured by a (nested) template-template-parm.  */
   current_template_parms = TREE_CHAIN (current_template_parms);
 
   current_template_parms
 = tree_cons (size_int (processing_template_decl),
 		 saved_parmlist, current_template_parms);
 
-  for (parm = parms, nparms = 0; parm; parm = next, nparms++)
+  for (unsigned ix = 0; parms; ix++)
 {
-  next = TREE_CHAIN (parm);
-  TREE_VEC_ELT (saved_parmlist, nparms) = parm;
+  tree parm = parms;
+  parms = TREE_CHAIN (parms);
   TREE_CHAIN (parm) = NULL_TREE;
+
+  TREE_VEC_ELT (saved_parmlist, ix) = parm;
 }
 
   --processing_template_parmlist;

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

[Qing Zhao via Gcc-patches]

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.

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 following patches I will send in next two emails.
> 
> Any comment?
> 
> thanks.
> 
> Qing
> 
> 
> 
> 
> 
> 
> 
> 

[PR 94827] Don't save tmpl parms in nested requirement

[Nathan Sidwell]

This patch removes the stashing of template parms that Jason noticed was 
unused when we fixed the 94827 ICE.


pushed to trunk.

nathan
--
Nathan Sidwell
2020-05-04  Nathan Sidwell  

	PR c++/94827 -- don't save parms in nested requirement
	* constraint.cc (tsubst_nested_requirement): TYPE directly holds
	notmalized requirement.
	(finish_nested_requirement): Don't stash current tpl parms into
	the requirement.
	(diagnose_nested_requirement): TYPE directly holds notmalized
	requirement.

diff --git i/gcc/cp/constraint.cc w/gcc/cp/constraint.cc
index 85513fecf43..4ad17f3b7d8 100644
--- i/gcc/cp/constraint.cc
+++ w/gcc/cp/constraint.cc
@@ -2010,7 +2010,7 @@ static tree
 tsubst_nested_requirement (tree t, tree args, subst_info info)
 {
   /* Ensure that we're in an evaluation context prior to satisfaction.  */
-  tree norm = TREE_VALUE (TREE_TYPE (t));
+  tree norm = TREE_TYPE (t);
   tree result = satisfy_constraint (norm, args, info);
   if (result == error_mark_node && info.quiet ())
 {
@@ -2958,16 +2958,9 @@ finish_nested_requirement (location_t loc, tree expr)
   /* Currently open template headers have dummy arg vectors, so don't
  pass into normalization.  */
   tree norm = normalize_constraint_expression (expr, NULL_TREE, false);
-  tree args = current_template_parms
-? template_parms_to_args (current_template_parms) : NULL_TREE;
-
-  /* Save the normalized constraint and complete set of normalization
- arguments with the requirement.  We keep the complete set of arguments
- around for re-normalization during diagnostics.  */
-  tree info = build_tree_list (args, norm);
 
   /* Build the constraint, saving its normalization as its type.  */
-  tree r = build1 (NESTED_REQ, info, expr);
+  tree r = build1 (NESTED_REQ, norm, expr);
   SET_EXPR_LOCATION (r, loc);
   return r;
 }
@@ -3370,7 +3363,7 @@ diagnose_nested_requirement (tree req, tree args)
 {
   /* Quietly check for satisfaction first. We can elaborate details
  later if needed.  */
-  tree norm = TREE_VALUE (TREE_TYPE (req));
+  tree norm = TREE_TYPE (req);
   subst_info info (tf_none, NULL_TREE);
   tree result = satisfy_constraint (norm, args, info);
   if (result == boolean_true_node)

[PATCH] aarch64: fix conflicting declarations

[Andreas Schwab]

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.
---
 gcc/config/aarch64/driver-aarch64.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/gcc/config/aarch64/driver-aarch64.c 
b/gcc/config/aarch64/driver-aarch64.c
index 0ccd200e330..d1229e67680 100644
--- a/gcc/config/aarch64/driver-aarch64.c
+++ b/gcc/config/aarch64/driver-aarch64.c
@@ -24,10 +24,7 @@
 #include "system.h"
 #include "coretypes.h"
 #include "tm.h"
-
-/* Defined in common/config/aarch64/aarch64-common.c.  */
-std::string aarch64_get_extension_string_for_isa_flags (unsigned long,
-   unsigned long);
+#include "aarch64-protos.h"
 
 struct aarch64_arch_extension
 {
-- 
2.26.2


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

Re: [PATCH] Fix missed IPA-CP on by-ref argument directly passed through (PR ipa/93429)

[Martin Jambor]

Hi,

On Mon, Jan 27 2020, Feng Xue OS wrote:
> Current IPA does not propagate aggregate constant for by-ref argument
> if it is simple pass-through of caller parameter. Here is an example,
>
>f1 (int *p)
>{
>  ... = *p;
>  ...
>}
>
>f2 (int *p)
>{
>   *p = 2;
>   f1 (p);
>}
>
> It is easy to know that in f1(), *p should be 2 after a simple propagation
> from f2() to f1(). But this is missed due to some bug, which is targeted
> by this patch.
>
> Bootstrapped/regtested on x86_64-linux and aarch64-linux.

This is OK for trunk now that we are in stage1 again (but please retest
after rebasing).

Thanks,

Martin


>
> Feng
> ---
> 2020-01-27  Feng Xue  
>
> PR ipa/93429
> * ipa-cp.c (propagate_aggs_across_jump_function): Further
> check aggregate jump functions if by-ref argument is simple
> pass through.
> (intersect_aggregates_with_edge): Likewise.
> From dc488d2be10dacf70a40073fe5723c58db791b25 Mon Sep 17 00:00:00 2001
> From: Feng Xue 
> Date: Fri, 24 Jan 2020 23:09:28 +0800
> Subject: [PATCH] Fix missed IPA-CP on by-ref argument directly passed through
>

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

[Szabolcs Nagy]

The 05/04/2020 11:34, Kyrylo Tkachov wrote:
> > -Original Message-
> > From: Florian Weimer 
> > Sent: 04 May 2020 11:40
> > To: Kyrylo Tkachov 
> > Cc: gcc-patches@gcc.gnu.org; Joseph Myers 
> > Subject: Re: [PATCH][AArch64] Use __getauxval instead of getauxval in LSE
> > detection code in libgcc
> > 
> > * Kyrylo Tkachov:
> > 
> > > This patch fixes https://gcc.gnu.org/pipermail/gcc-patches/2020-
> > May/545004.html by using __getauxval in the libgcc code.
> > > Bootstrap and testing on aarch64-none-linux-gnu shows no problem.
> > > From what I could gather from my glibc testing the elf/check-localplt test
> > passes.
> > >
> > > Joseph, Florian, does this fix look like what you had in mind?
> > > If I commit it to trunk and the branches will glibc be fine with it?
> > 
> > Doesn't this cause an implicit function declaration warning?
> 
> I don't get such a warning during bootstrap.

i think __getauxval needs to be declared where it is used.

and libgcc should do a link test in configure becasuse a
libc may provide sys/auxv.h but not have __getauxval e.g.
musl libc does not export __getauxval, only getauxval.

[PATCH] gcc/config/rs6000: fix long double builtins for AIX

[CHIGOT, CLEMENT via Gcc-patches]

Descritpion:
 * This patch fixes the explicit call made by some C long double
   builtins when long doubles are on 64bit for AIX.

Tests:
 * AIX 7.2, 7.1, 6.1: Build/Tests: OK

Changelog:
2020-04-27 Clément Chigot 

gcc-10-gcc-config-rs6000-fix-long-double-builtins-for-AIX-V3.patch
Description: gcc-10-gcc-config-rs6000-fix-long-double-builtins-for-AIX-V3.patch

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

[Stefan Schulze Frielinghaus via Gcc-patches]

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.

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?

[committed] libstdc++: Make pmr::synchronized_pool_resource work without libpthread (PR 94936)

[Jonathan Wakely via Gcc-patches]

I implicitly assumed that programs using pmr::synchronized_pool_resource
would also be using multiple threads, and so the weak symbols in
gthr-posix.h would be resolved by linking to libpthread. If that isn't
true then it crashes when trying to use pthread_key_create.

This commit makes the pool resource check __gthread_active_p() before
using thread-specific data, and just use a single set of memory pools
when there's only a single thread.

PR libstdc++/94936
* src/c++17/memory_resource.cc (synchronized_pool_resource::_TPools):
Add comment about single-threaded behaviour.
(synchronized_pool_resource::_TPools::move_nonempty_chunks()): Hoist
class member access out of loop.
(synchronized_pool_resource::synchronized_pool_resource())
(synchronized_pool_resource::~synchronized_pool_resource())
(synchronized_pool_resource::release()): Check __gthread_active_p
before creating and/or deleting the thread-specific data key.
(synchronized_pool_resource::_M_thread_specific_pools()): Adjust
assertions.
(synchronized_pool_resource::do_allocate(size_t, size_t)): Add fast
path for single-threaded case.
(synchronized_pool_resource::do_deallocate(void*, size_t, size_t)):
Likewise. Return if unable to find a pool that owns the allocation.
* testsuite/20_util/synchronized_pool_resource/allocate_single.cc:
New test.
* testsuite/20_util/synchronized_pool_resource/cons_single.cc: New
test.
* testsuite/20_util/synchronized_pool_resource/release_single.cc: New
test.

Tested powerpc64le-linux, committed to master.

I'll backport this, but after 10.1 is released.

commit ec40967f1323069da3a5a45286f71fa4f80926df
Author: Jonathan Wakely 
Date:   Mon May 4 13:34:23 2020 +0100

libstdc++: Make pmr::synchronized_pool_resource work without libpthread (PR 
94936)

I implicitly assumed that programs using pmr::synchronized_pool_resource
would also be using multiple threads, and so the weak symbols in
gthr-posix.h would be resolved by linking to libpthread. If that isn't
true then it crashes when trying to use pthread_key_create.

This commit makes the pool resource check __gthread_active_p() before
using thread-specific data, and just use a single set of memory pools
when there's only a single thread.

PR libstdc++/94936
* src/c++17/memory_resource.cc 
(synchronized_pool_resource::_TPools):
Add comment about single-threaded behaviour.
(synchronized_pool_resource::_TPools::move_nonempty_chunks()): Hoist
class member access out of loop.
(synchronized_pool_resource::synchronized_pool_resource())
(synchronized_pool_resource::~synchronized_pool_resource())
(synchronized_pool_resource::release()): Check __gthread_active_p
before creating and/or deleting the thread-specific data key.
(synchronized_pool_resource::_M_thread_specific_pools()): Adjust
assertions.
(synchronized_pool_resource::do_allocate(size_t, size_t)): Add fast
path for single-threaded case.
(synchronized_pool_resource::do_deallocate(void*, size_t, size_t)):
Likewise. Return if unable to find a pool that owns the allocation.
* testsuite/20_util/synchronized_pool_resource/allocate_single.cc:
New test.
* testsuite/20_util/synchronized_pool_resource/cons_single.cc: New
test.
* testsuite/20_util/synchronized_pool_resource/release_single.cc: 
New
test.

diff --git a/libstdc++-v3/src/c++17/memory_resource.cc 
b/libstdc++-v3/src/c++17/memory_resource.cc
index 56a87844da0..1acab19e306 100644
--- a/libstdc++-v3/src/c++17/memory_resource.cc
+++ b/libstdc++-v3/src/c++17/memory_resource.cc
@@ -1043,7 +1043,8 @@ namespace pmr
* exposition as _M_tpools[_M_key]).
* The first element, _M_tpools[0], contains "orphaned chunks" which were
* allocated by a thread which has since exited, and so there is no
-   * _M_tpools[_M_key] for that thread.
+   * _M_tpools[_M_key] for that thread. Orphaned chunks are never reused,
+   * they're only held in _M_tpools[0] so they can be deallocated.
* A thread can access its own thread-specific set of pools via _M_key
* while holding a shared lock on _M_mx. Accessing _M_impl._M_unpooled
* or _M_tpools[0] or any other thread's _M_tpools[_M_key] requires an
@@ -1052,6 +1053,10 @@ namespace pmr
* any dereference of that pointer requires an exclusive lock.
* The _M_impl._M_opts and _M_impl._M_npools members are immutable,
* and can safely be accessed concurrently.
+   *
+   * In a single-threaded program (i.e. __gthread_active_p() == false)
+   * the pool resource only needs one set of pools and never has orphaned
+   * chunks, so just uses _M_tpools[0] directly, and 

Re: [PATCH] build: Fix 32-bit TLS detection with 64-bit-default gas on Solaris/x86

[Rainer Orth]

Hi Jakub,

> On Mon, May 04, 2020 at 03:19:30PM +0200, Rainer Orth wrote:
>> I'm going to commit this to master shortly.  Ok for the gcc-10 branch,
>> too, given that it fixes a bootstrap failure?
>
> Ok, but see below.

>> diff --git a/gcc/configure.ac b/gcc/configure.ac
>> --- a/gcc/configure.ac
>> +++ b/gcc/configure.ac
>> @@ -3562,6 +3562,11 @@ changequote(,)dnl
>>  fi
>>  case "$target" in
>>i[34567]86-*-*)
>> +if test x$on_solaris = xyes; then
>> +  case $gas_flag in
>> +yes) tls_as_opt="$tls_as_opt --32" ;;
>> +  esac
>> +fi
>
> Why not following instead?
>   if test x$on_solaris = xyes && test x$gas_flag = xyes; then
> tls_as_opt="$tls_as_opt --32"
>   fi

That would work, of course.  I simply meant to follow the style of the
64-bit test as closely as possible.

Rainer

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

Re: [PATCH] build: Fix 32-bit TLS detection with 64-bit-default gas on Solaris/x86

[Jakub Jelinek via Gcc-patches]

On Mon, May 04, 2020 at 03:19:30PM +0200, Rainer Orth wrote:
> I'm going to commit this to master shortly.  Ok for the gcc-10 branch,
> too, given that it fixes a bootstrap failure?

Ok, but see below.

> 2020-05-02  Rainer Orth  
> 
>   * configure.ac : Add --32 to tls_as_opt on Solaris.
>   * configure: Regenerate.
> 

> # HG changeset patch
> # Parent  536b6b3f48b6668fa1724b8675b1cceadaab5632
> build: Fix 32-bit TLS detection with 64-bit-default gas on Solaris/x86
> 
> diff --git a/gcc/configure.ac b/gcc/configure.ac
> --- a/gcc/configure.ac
> +++ b/gcc/configure.ac
> @@ -3562,6 +3562,11 @@ changequote(,)dnl
>  fi
>  case "$target" in
>i[34567]86-*-*)
> + if test x$on_solaris = xyes; then
> +   case $gas_flag in
> + yes) tls_as_opt="$tls_as_opt --32" ;;
> +   esac
> + fi

Why not following instead?
if test x$on_solaris = xyes && test x$gas_flag = xyes; then
  tls_as_opt="$tls_as_opt --32"
fi

Jakub

[PATCH] build: Fix 32-bit TLS detection with 64-bit-default gas on Solaris/x86

[Rainer Orth]

I've recently tested i386-pc-solaris2.11 bootstrap on Solaris 11/x86
with only the bundled tools (using /usr/gnu/bin/as from binutils 2.30 in
this case).  It failed compiling libgo/runtime/proc.c, creating invalid
assembly:

proc.s: Assembler messages:
proc.s:2092: Error: junk at end of line, first unrecognized character is `*'

.globl  __emutls_v.*runtime.g

and several more errors.  This is completely unexpected since Solaris
does support TLS.  It turned out that 32-bit TLS detection in
gcc/configure had failed:

configure:25145: checking assembler for thread-local storage support
configure:25158: /usr/gnu/bin/as   --fatal-warnings -o conftest.o conftest.s >&5
conftest.s: Assembler messages:
conftest.s:6: Error: relocated field and relocation type differ in signedness
conftest.s:7: Error: @TLSLDM reloc is not supported with 64-bit output format
conftest.s:7: Error: junk `@tlsldm' after expression

which isn't unexpected given that the bundled gas has been configured
for x86_64-pc-solaris2.11, i.e. 64-bit-default.

This is easily fixed by explicitly passing --32 for the 32-bit case,
matching what is done for the 64-bit test.

Tested on i386-pc-solaris2.11 with 32-bit-default and 64-bit-default gas
as well as with /usr/bin/as, always correctly detecting TLS support.

I'm going to commit this to master shortly.  Ok for the gcc-10 branch,
too, given that it fixes a bootstrap failure?

I wonder if it's worth pursuing or even properly reporting the libgo
failure with emutls, though.  Ian?

Thanks.
Rainer

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


2020-05-02  Rainer Orth  

* configure.ac : Add --32 to tls_as_opt on Solaris.
* configure: Regenerate.

# HG changeset patch
# Parent  536b6b3f48b6668fa1724b8675b1cceadaab5632
build: Fix 32-bit TLS detection with 64-bit-default gas on Solaris/x86

diff --git a/gcc/configure.ac b/gcc/configure.ac
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -3562,6 +3562,11 @@ changequote(,)dnl
 fi
 case "$target" in
   i[34567]86-*-*)
+	if test x$on_solaris = xyes; then
+	  case $gas_flag in
+	yes) tls_as_opt="$tls_as_opt --32" ;;
+	  esac
+	fi
 	conftest_s="$conftest_s
 foo:	.long	25
 	.text

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

[Richard Biener via Gcc-patches]

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.

Thanks,
Richard.

Re: [PATCH] internal-fn: Avoid dropping the lhs of some calls [PR94941]

[Jakub Jelinek via Gcc-patches]

On Mon, May 04, 2020 at 03:03:01PM +0200, Richard Biener wrote:
> We seem to have inconsistent use of rtx_equal_p vs. pointer comparison
> of target and ops[0].value - is that because some are eventually MEMs
> and some (targets?) are always registers?  Of course I prefer the
> cheaper != comparison.

We don't know what exactly the target will be, pseudo is most likely, but
could be something else too.
And, rtx_equal_p starts with == comparison, so it is just the call overhead.

> Otherwise looks obvious to me, thus OK for trunk and branch (I don't
> see what it could break so from my side it would be OK for 10.1
> but let's ask Jakub).

I'm fine with it for 10.1, if the target is right, it won't do anything,
otherwise fix a wrong-code, and is limited to arm/aarch64 too (no other
target AFAIK has such ifns).

Jakub

Re: [PATCH] internal-fn: Avoid dropping the lhs of some calls [PR94941]

[Richard Biener via Gcc-patches]

On Mon, May 4, 2020 at 2:55 PM Richard Sandiford
 wrote:
>
> create_output_operand coerces an output operand to the insn's
> predicates, using a suggested rtx location if convenient.
> But if that rtx location is actually required rather than
> optional, the builder of the insn has to emit a move afterwards.
>
> (We could instead add a new interface that does this automatically,
> but that's future work.)
>
> This PR shows that we were failing to emit the move for some of the
> vector load internal functions.  I think there are other routines in
> internal-fn.c that potentially have the same problem, but this patch is
> supposed to be a conservative subset suitable for backporting to GCC 10.
>
> Tested on aarch64-linux-gnu (with and without SVE), arm-linux-gnueabihf
> and x86_64-linux-gnu.  OK for trunk and GCC 10 branch?  It would be
> nice if we could have this for GCC 10.1, but I realise it wouldn't
> justify a new RC on its own, so I'll assume that "GCC 10 branch" is
> "GCC 10 branch after the release".

We seem to have inconsistent use of rtx_equal_p vs. pointer comparison
of target and ops[0].value - is that because some are eventually MEMs
and some (targets?) are always registers?  Of course I prefer the
cheaper != comparison.

Otherwise looks obvious to me, thus OK for trunk and branch (I don't
see what it could break so from my side it would be OK for 10.1
but let's ask Jakub).

Richard.

> Richard
>
>
> 2020-05-04  Richard Sandiford  
>
> gcc/
> PR middle-end/94941
> * internal-fn.c (expand_load_lanes_optab_fn): Emit a move if the
> chosen lhs is different from the gcall lhs.
> (expand_mask_load_optab_fn): Likewise.
> (expand_gather_load_optab_fn): Likewise.
>
> gcc/testsuite/
> PR middle-end/94941
> * gcc.target/aarch64/sve/acle/general/unoptimized_1.c: New test.
> ---
>  gcc/internal-fn.c |  6 ++
>  .../aarch64/sve/acle/general/unoptimized_1.c  | 21 +++
>  2 files changed, 27 insertions(+)
>  create mode 100644 
> gcc/testsuite/gcc.target/aarch64/sve/acle/general/unoptimized_1.c
>
> diff --git a/gcc/internal-fn.c b/gcc/internal-fn.c
> index 52d1638917a..5e9aa60721e 100644
> --- a/gcc/internal-fn.c
> +++ b/gcc/internal-fn.c
> @@ -167,6 +167,8 @@ expand_load_lanes_optab_fn (internal_fn, gcall *stmt, 
> convert_optab optab)
>create_output_operand ([0], target, TYPE_MODE (type));
>create_fixed_operand ([1], mem);
>expand_insn (get_multi_vector_move (type, optab), 2, ops);
> +  if (!rtx_equal_p (target, ops[0].value))
> +emit_move_insn (target, ops[0].value);
>  }
>
>  /* Expand STORE_LANES call STMT using optab OPTAB.  */
> @@ -2507,6 +2509,8 @@ expand_mask_load_optab_fn (internal_fn, gcall *stmt, 
> convert_optab optab)
>create_fixed_operand ([1], mem);
>create_input_operand ([2], mask, TYPE_MODE (TREE_TYPE (maskt)));
>expand_insn (icode, 3, ops);
> +  if (!rtx_equal_p (target, ops[0].value))
> +emit_move_insn (target, ops[0].value);
>  }
>
>  #define expand_mask_load_lanes_optab_fn expand_mask_load_optab_fn
> @@ -2827,6 +2831,8 @@ expand_gather_load_optab_fn (internal_fn, gcall *stmt, 
> direct_optab optab)
>insn_code icode = convert_optab_handler (optab, TYPE_MODE (TREE_TYPE 
> (lhs)),
>TYPE_MODE (TREE_TYPE (offset)));
>expand_insn (icode, i, ops);
> +  if (!rtx_equal_p (lhs_rtx, ops[0].value))
> +emit_move_insn (lhs_rtx, ops[0].value);
>  }
>
>  /* Expand DIVMOD() using:
> diff --git 
> a/gcc/testsuite/gcc.target/aarch64/sve/acle/general/unoptimized_1.c 
> b/gcc/testsuite/gcc.target/aarch64/sve/acle/general/unoptimized_1.c
> new file mode 100644
> index 000..18d73e21a83
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/aarch64/sve/acle/general/unoptimized_1.c
> @@ -0,0 +1,21 @@
> +/* { dg-do run { target aarch64_sve_hw } } */
> +
> +#include 
> +
> +svfloat32_t
> +foo (float *ptr)
> +{
> +  svbool_t pg = svptrue_pat_b32 (SV_VL1);
> +  svfloat32_t res = svld1 (pg, ptr);
> +  return res;
> +}
> +
> +int
> +main (void)
> +{
> +  svbool_t pg = svptrue_pat_b32 (SV_VL1);
> +  float x[1] = { 1 };
> +  if (svptest_any (pg, svcmpne (pg, foo (x), 1.0)))
> +__builtin_abort ();
> +  return 0;
> +}

[PATCH] internal-fn: Avoid dropping the lhs of some calls [PR94941]

[Richard Sandiford]

create_output_operand coerces an output operand to the insn's
predicates, using a suggested rtx location if convenient.
But if that rtx location is actually required rather than
optional, the builder of the insn has to emit a move afterwards.

(We could instead add a new interface that does this automatically,
but that's future work.)

This PR shows that we were failing to emit the move for some of the
vector load internal functions.  I think there are other routines in
internal-fn.c that potentially have the same problem, but this patch is
supposed to be a conservative subset suitable for backporting to GCC 10.

Tested on aarch64-linux-gnu (with and without SVE), arm-linux-gnueabihf
and x86_64-linux-gnu.  OK for trunk and GCC 10 branch?  It would be
nice if we could have this for GCC 10.1, but I realise it wouldn't
justify a new RC on its own, so I'll assume that "GCC 10 branch" is
"GCC 10 branch after the release".

Richard


2020-05-04  Richard Sandiford  

gcc/
PR middle-end/94941
* internal-fn.c (expand_load_lanes_optab_fn): Emit a move if the
chosen lhs is different from the gcall lhs.
(expand_mask_load_optab_fn): Likewise.
(expand_gather_load_optab_fn): Likewise.

gcc/testsuite/
PR middle-end/94941
* gcc.target/aarch64/sve/acle/general/unoptimized_1.c: New test.
---
 gcc/internal-fn.c |  6 ++
 .../aarch64/sve/acle/general/unoptimized_1.c  | 21 +++
 2 files changed, 27 insertions(+)
 create mode 100644 
gcc/testsuite/gcc.target/aarch64/sve/acle/general/unoptimized_1.c

diff --git a/gcc/internal-fn.c b/gcc/internal-fn.c
index 52d1638917a..5e9aa60721e 100644
--- a/gcc/internal-fn.c
+++ b/gcc/internal-fn.c
@@ -167,6 +167,8 @@ expand_load_lanes_optab_fn (internal_fn, gcall *stmt, 
convert_optab optab)
   create_output_operand ([0], target, TYPE_MODE (type));
   create_fixed_operand ([1], mem);
   expand_insn (get_multi_vector_move (type, optab), 2, ops);
+  if (!rtx_equal_p (target, ops[0].value))
+emit_move_insn (target, ops[0].value);
 }
 
 /* Expand STORE_LANES call STMT using optab OPTAB.  */
@@ -2507,6 +2509,8 @@ expand_mask_load_optab_fn (internal_fn, gcall *stmt, 
convert_optab optab)
   create_fixed_operand ([1], mem);
   create_input_operand ([2], mask, TYPE_MODE (TREE_TYPE (maskt)));
   expand_insn (icode, 3, ops);
+  if (!rtx_equal_p (target, ops[0].value))
+emit_move_insn (target, ops[0].value);
 }
 
 #define expand_mask_load_lanes_optab_fn expand_mask_load_optab_fn
@@ -2827,6 +2831,8 @@ expand_gather_load_optab_fn (internal_fn, gcall *stmt, 
direct_optab optab)
   insn_code icode = convert_optab_handler (optab, TYPE_MODE (TREE_TYPE (lhs)),
   TYPE_MODE (TREE_TYPE (offset)));
   expand_insn (icode, i, ops);
+  if (!rtx_equal_p (lhs_rtx, ops[0].value))
+emit_move_insn (lhs_rtx, ops[0].value);
 }
 
 /* Expand DIVMOD() using:
diff --git a/gcc/testsuite/gcc.target/aarch64/sve/acle/general/unoptimized_1.c 
b/gcc/testsuite/gcc.target/aarch64/sve/acle/general/unoptimized_1.c
new file mode 100644
index 000..18d73e21a83
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/sve/acle/general/unoptimized_1.c
@@ -0,0 +1,21 @@
+/* { dg-do run { target aarch64_sve_hw } } */
+
+#include 
+
+svfloat32_t
+foo (float *ptr)
+{
+  svbool_t pg = svptrue_pat_b32 (SV_VL1);
+  svfloat32_t res = svld1 (pg, ptr);
+  return res;
+}
+
+int
+main (void)
+{
+  svbool_t pg = svptrue_pat_b32 (SV_VL1);
+  float x[1] = { 1 };
+  if (svptest_any (pg, svcmpne (pg, foo (x), 1.0)))
+__builtin_abort ();
+  return 0;
+}

[PATCH] tree-optimization/93891 - improve same-store disambiguation

[Richard Biener]

This doesn't fix the testcase at hand but is a first step.

Bootstrap / regtest ongoing on x86_64-unknown-linux-gnu.

We need a reference to assess alignment, fall back to the original
reference tree if available.

2020-02-16  Richard Biener  

PR tree-optimization/93891
* tree-ssa-sccvn.c (vn_reference_lookup_3): Fall back to
the original reference tree for assessing access alignment.
---
 gcc/tree-ssa-sccvn.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/gcc/tree-ssa-sccvn.c b/gcc/tree-ssa-sccvn.c
index 238931d3f3e..8a4af91c54e 100644
--- a/gcc/tree-ssa-sccvn.c
+++ b/gcc/tree-ssa-sccvn.c
@@ -2527,7 +2527,7 @@ vn_reference_lookup_3 (ao_ref *ref, tree vuse, void 
*data_,
 and return the found value.  */
   if (is_gimple_reg_type (TREE_TYPE (lhs))
  && types_compatible_p (TREE_TYPE (lhs), vr->type)
- && ref->ref)
+ && (ref->ref || data->orig_ref.ref))
{
  tree *saved_last_vuse_ptr = data->last_vuse_ptr;
  /* Do not update last_vuse_ptr in vn_reference_lookup_2.  */
@@ -2552,7 +2552,9 @@ vn_reference_lookup_3 (ao_ref *ref, tree vuse, void 
*data_,
 -fno-strict-aliasing.  So simply resort to alignment to
 rule out overlaps.  Do this check last because it is
 quite expensive compared to the hash-lookup above.  */
- && multiple_p (get_object_alignment (ref->ref), ref->size)
+ && multiple_p (get_object_alignment
+  (ref->ref ? ref->ref : data->orig_ref.ref),
+ref->size)
  && multiple_p (get_object_alignment (lhs), ref->size))
return res;
}
-- 
2.16.4

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

[Richard Biener]

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.
---
 gcc/tree-cfg.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/gcc/tree-cfg.c b/gcc/tree-cfg.c
index e99fb9ff5d1..c6140af50e7 100644
--- a/gcc/tree-cfg.c
+++ b/gcc/tree-cfg.c
@@ -3591,13 +3591,21 @@ verify_gimple_assign_unary (gassign *stmt)
/* Allow conversions from pointer type to integral type only if
   there is no sign or zero extension involved.
   For targets were the precision of ptrofftype doesn't match that
-  of pointers we need to allow arbitrary conversions to ptrofftype.  */
+  of pointers we allow conversions to types where
+  POINTERS_EXTEND_UNSIGNED specifies how that works.  */
if ((POINTER_TYPE_P (lhs_type)
 && INTEGRAL_TYPE_P (rhs1_type))
|| (POINTER_TYPE_P (rhs1_type)
&& INTEGRAL_TYPE_P (lhs_type)
&& (TYPE_PRECISION (rhs1_type) >= TYPE_PRECISION (lhs_type)
-   || ptrofftype_p (lhs_type
+#if defined(POINTERS_EXTEND_UNSIGNED)
+   || (TYPE_MODE (rhs1_type) == ptr_mode
+   && (TYPE_PRECISION (lhs_type)
+ == BITS_PER_WORD /* word_mode */
+   || (TYPE_PRECISION (lhs_type)
+ == GET_MODE_PRECISION (Pmode
+#endif
+  )))
  return false;
 
/* Allow conversion from integral to offset type and vice versa.  */
-- 
2.16.4

[committed] i386: Use SHR to compare with large power-of-two constants [PR94650]

[Uros Bizjak via Gcc-patches]

Convert unsigned compares where

m >= LARGE_POWER_OF_TWO

and LARGE_POWER_OF_TWO represent an immediate where bit 33+ is set to use
a SHR instruction and compare the result to 0.  This avoids loading a
large immediate with MOVABS insn.

movabsq $1099511627775, %rax
cmpq%rax, %rdi
ja  .L5

gets converted to:

shrq$40, %rdi
jne.L5

2020-05-04  Uroš Bizjak  

PR target/94650
* config/i386/predicates.md (shr_comparison_operator): New predicate.
* config/i386/i386.md (compare->shr splitter): New splitters.

testsuite/ChangeLog:

2020-05-04  Uroš Bizjak  

PR target/94650
* gcc.targeti/i386/pr94650.c: New test.

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

Committed to mainline SVN.

Uros.
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 6f3ac3ad555..bd144ab3d5e 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -12310,6 +12310,36 @@
 
 ;; Store-flag instructions.
 
+(define_split
+  [(set (match_operand:QI 0 "nonimmediate_operand")
+   (match_operator:QI 1 "shr_comparison_operator"
+ [(match_operand:DI 2 "register_operand")
+  (match_operand 3 "const_int_operand")]))]
+  "TARGET_64BIT
+   && IN_RANGE (exact_log2 (UINTVAL (operands[3]) + 1), 32, 63)"
+  [(parallel
+ [(set (reg:CCZ FLAGS_REG)
+  (compare:CCZ
+(lshiftrt:DI (match_dup 2) (match_dup 4))
+(const_int 0)))
+  (clobber (scratch:DI))])
+   (set (match_dup 0)
+   (match_op_dup 1 [(reg:CCZ FLAGS_REG) (const_int 0)]))]
+{
+  enum rtx_code new_code;
+
+  operands[1] = shallow_copy_rtx (operands[1]);
+  switch (GET_CODE (operands[1]))
+{
+case GTU: new_code = NE; break;
+case LEU: new_code = EQ; break;
+default: gcc_unreachable ();
+}
+  PUT_CODE (operands[1], new_code);
+
+  operands[4] = GEN_INT (exact_log2 (UINTVAL (operands[3]) + 1));
+})
+
 ;; For all sCOND expanders, also expand the compare or test insn that
 ;; generates cc0.  Generate an equality comparison if `seq' or `sne'.
 
@@ -12473,6 +12503,42 @@
(set_attr "mode" "")])
 
 ;; Basic conditional jump instructions.
+
+(define_split
+  [(set (pc)
+   (if_then_else
+ (match_operator 1 "shr_comparison_operator"
+   [(match_operand:DI 2 "register_operand")
+(match_operand 3 "const_int_operand")])
+ (label_ref (match_operand 0))
+ (pc)))]
+  "TARGET_64BIT
+   && IN_RANGE (exact_log2 (UINTVAL (operands[3]) + 1), 32, 63)"
+  [(parallel
+ [(set (reg:CCZ FLAGS_REG)
+  (compare:CCZ
+(lshiftrt:DI (match_dup 2) (match_dup 4))
+(const_int 0)))
+  (clobber (scratch:DI))])
+   (set (pc)
+   (if_then_else (match_op_dup 1 [(reg:CCZ FLAGS_REG) (const_int 0)])
+ (label_ref (match_operand 0))
+ (pc)))]
+{
+  enum rtx_code new_code;
+
+  operands[1] = shallow_copy_rtx (operands[1]);
+  switch (GET_CODE (operands[1]))
+{
+case GTU: new_code = NE; break;
+case LEU: new_code = EQ; break;
+default: gcc_unreachable ();
+}
+  PUT_CODE (operands[1], new_code);
+
+  operands[4] = GEN_INT (exact_log2 (UINTVAL (operands[3]) + 1));
+})
+
 ;; We ignore the overflow flag for signed branch instructions.
 
 (define_insn "*jcc"
diff --git a/gcc/config/i386/predicates.md b/gcc/config/i386/predicates.md
index 71f4cb1193c..1a5e2210eca 100644
--- a/gcc/config/i386/predicates.md
+++ b/gcc/config/i386/predicates.md
@@ -1290,6 +1290,9 @@
 (define_predicate "bt_comparison_operator"
   (match_code "ne,eq"))
 
+(define_predicate "shr_comparison_operator"
+  (match_code "gtu,leu"))
+
 ;; 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/pr94650.c 
b/gcc/testsuite/gcc.target/i386/pr94650.c
new file mode 100644
index 000..49d8b6e7f8c
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr94650.c
@@ -0,0 +1,30 @@
+/* PR target/94650 */
+/* { dg-do compile { target { ! ia32 } } } */
+/* { dg-options "-O2" } */
+
+#define LARGE_POWER_OF_TWO (1ULL << 40)
+
+int
+check (unsigned long long m)
+{
+  return m >= LARGE_POWER_OF_TWO;
+}
+
+void g (int);
+
+void
+test0 (unsigned long long m)
+{
+  if (m >= LARGE_POWER_OF_TWO)
+g (0);
+}
+
+void
+test1 (unsigned long long m)
+{
+  if (m >= LARGE_POWER_OF_TWO)
+g (m);
+}
+
+/* { dg-final { scan-assembler-not "movabs" } } */
+/* { dg-final { scan-assembler-times "shr" 3 } } */

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

[Stefan Schulze Frielinghaus via Gcc-patches]

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?
>From e07fe025a710de80cade4ae5c6e4351fbd21b672 Mon Sep 17 00:00:00 2001
From: Stefan Schulze Frielinghaus 
Date: Sun, 26 Apr 2020 09:42:29 +0200
Subject: [PATCH] c-attribs.c: Fix warning about use of uninitialized variable
 nunits

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;
  |

Added attribute nonnull for argument args in order to silence warning
and added an assert statement in order to check the invariant candidate.

gcc/c-family/ChangeLog:

2020-05-04  Stefan Schulze Frielinghaus  

* c-attribs.c (handle_vector_size_attribute): Add attribute
nonnull for argument args in order to silence warning of
uninitialized variable usage and add assert statement in order
to check for invariant candidate.
---
 gcc/c-family/c-attribs.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/gcc/c-family/c-attribs.c b/gcc/c-family/c-attribs.c
index ac936d5..dafc77cbcb7 100644
--- a/gcc/c-family/c-attribs.c
+++ b/gcc/c-family/c-attribs.c
@@ -117,7 +117,7 @@ static tree handle_tm_attribute (tree *, tree, tree, int, 
bool *);
 static tree handle_tm_wrap_attribute (tree *, tree, tree, int, bool *);
 static tree handle_novops_attribute (tree *, tree, tree, int, bool *);
 static tree handle_vector_size_attribute (tree *, tree, tree, int,
- bool *);
+ bool *) ATTRIBUTE_NONNULL(3);
 static tree handle_nonnull_attribute (tree *, tree, tree, int, bool *);
 static tree handle_nonstring_attribute (tree *, tree, tree, int, bool *);
 static tree handle_nothrow_attribute (tree *, tree, tree, int, bool *);
@@ -3697,6 +3697,8 @@ handle_vector_size_attribute (tree *node, tree name, tree 
args,
   if (!type)
 return NULL_TREE;
 
+  gcc_checking_assert (args != NULL);
+
   tree new_type = build_vector_type (type, nunits);
 
   /* Build back pointers if needed.  */
-- 
2.25.3

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

[Kyrylo Tkachov]

> -Original Message-
> From: Florian Weimer 
> Sent: 04 May 2020 11:40
> To: Kyrylo Tkachov 
> Cc: gcc-patches@gcc.gnu.org; Joseph Myers 
> Subject: Re: [PATCH][AArch64] Use __getauxval instead of getauxval in LSE
> detection code in libgcc
> 
> * Kyrylo Tkachov:
> 
> > This patch fixes https://gcc.gnu.org/pipermail/gcc-patches/2020-
> May/545004.html by using __getauxval in the libgcc code.
> > Bootstrap and testing on aarch64-none-linux-gnu shows no problem.
> > From what I could gather from my glibc testing the elf/check-localplt test
> passes.
> >
> > Joseph, Florian, does this fix look like what you had in mind?
> > If I commit it to trunk and the branches will glibc be fine with it?
> 
> Doesn't this cause an implicit function declaration warning?

I don't get such a warning during bootstrap.
Thanks,
Kyrill

> 
> Thanks,
> Florian

Re: arm: Fix vfp_operand_register for VFP HI regs

[Christophe Lyon via Gcc-patches]

On Fri, 1 May 2020 at 12:57, Kyrylo Tkachov  wrote:
>
>
>
> > -Original Message-
> > From: Christophe Lyon 
> > Sent: 30 April 2020 09:51
> > To: Kyrylo Tkachov 
> > Cc: gcc-patches@gcc.gnu.org
> > Subject: Re: arm: Fix vfp_operand_register for VFP HI regs
> >
> > On Wed, 29 Apr 2020 at 18:40, Kyrylo Tkachov 
> > wrote:
> > >
> > > Hi Christophe,
> > >
> > > > -Original Message-
> > > > From: Gcc-patches  On Behalf Of
> > > > Christophe Lyon via Gcc-patches
> > > > Sent: 29 April 2020 16:53
> > > > To: gcc Patches 
> > > > Subject: arm: Fix vfp_operand_register for VFP HI regs
> > > >
> > > > Hi,
> > > >
> > > > While looking at PR target/94743 I noticed an ICE when I tried to save
> > > > all the FP registers: this was because all HI registers wouldn't match
> > > > vfp_register_operand.
> > >
> > > Hmm, I see that arm_regno_class indeed never returns VFP_REGS and
> > would return VFP_HI_REGS here.
> > > So the patch looks correct to me.
> > > Do you have a testcase for the ICE to add to the testsuite?
> > >
> >
> > No C source code: I found that while extending the list of registers
> > pushed in the prologue of an IRQ handler, more-or-less modifying
> > arm_save_coproc_regs so that more registers are handled by
> > vfp_emit_fstmd.
> > The problem occurs when trying to push d16-d31.
>
> I'd be comfortable taking this now for trunk (GCC 11) so it has time to bake.
> Once you're ready to post the IRQ handler work we can see about backporting 
> this fix it to the branch, if we deem it necessary.
> Thanks,
> Kyrill
>

OK, I hoped my simple-warning patch could be included in gcc-10 but I
think it's now too late.
(https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544872.html)

I'm not quite sure about the next steps, but let's continue the
discussion in bugzilla.

Thanks

> >
> >
> > > Thanks,
> > > Kyrill
> > >
> > > >
> > > > Regression-tested and bootstrapped OK.
> > > >
> > > > 2020-04-29  Christophe Lyon  
> > > >
> > > > gcc/
> > > > * config/arm/predicates.md (vfp_register_operand): Use
> > VFP_HI_REGS
> > > > instead of VFP_REGS.
> > > >
> > > > OK?
> > > >
> > > > Thanks,
> > > >
> > > > Christophe

[PATCH] tree-optimization/39612 - avoid issueing loads in SM when possible

[Richard Biener]

Currently store-motion emits a load of the value in the loop
preheader even when the original loop does not contain any read
of the reference.  This avoids doing this.  In the conditional
store-motion case we need to mark the sunk stores with no-warning
since the control dependence is too tricky to figure out for
the uninit warning.

Bootstrap & re-testing on x86_64-unknown-linux-gnu in progress.

Richard.

2020-04-04  Richard Biener  

PR tree-optimization/39612
* tree-ssa-loop-im.c (im_mem_ref::loaded): New member.
(set_ref_loaded_in_loop): New.
(mark_ref_loaded): Likewise.
(gather_mem_refs_stmt): Call mark_ref_loaded for loads.
(execute_sm): Avoid issueing a load when it was not there.
(execute_sm_if_changed): Avoid issueing warnings for the
conditional store.

* gcc.dg/tree-ssa/pr39612.c: New testcase.
---
 gcc/testsuite/gcc.dg/tree-ssa/pr39612.c | 21 +++
 gcc/tree-ssa-loop-im.c  | 47 -
 2 files changed, 60 insertions(+), 8 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr39612.c

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr39612.c 
b/gcc/testsuite/gcc.dg/tree-ssa/pr39612.c
new file mode 100644
index 000..884f905148f
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr39612.c
@@ -0,0 +1,21 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-lim2-details -Wuninitialized" } */
+
+void foo(int *);
+void f2(int dst[3], int R)
+{
+  int i, inter[2];
+
+  for (i = 1; i < R; i++) {
+if (i & 8)
+  {
+   inter[0] = 1;
+   inter[1] = 1;
+  }
+  }
+
+  foo(inter);
+}
+
+/* { dg-final { scan-tree-dump-times "Executing store motion" 2 "lim2" } } */
+/* { dg-final { scan-tree-dump-not " = inter\\\[\[0-1\]\\\];" "lim2" } } */
diff --git a/gcc/tree-ssa-loop-im.c b/gcc/tree-ssa-loop-im.c
index abd5f702b91..18e5c18c17e 100644
--- a/gcc/tree-ssa-loop-im.c
+++ b/gcc/tree-ssa-loop-im.c
@@ -127,6 +127,8 @@ public:
 
   bitmap stored;   /* The set of loops in that this memory location
   is stored to.  */
+  bitmap loaded;   /* The set of loops in that this memory location
+  is loaded from.  */
   vec accesses_in_loop;
/* The locations of the accesses.  Vector
   indexed by the loop number.  */
@@ -1395,6 +1397,7 @@ mem_ref_alloc (ao_ref *mem, unsigned hash, unsigned id)
   ref->ref_decomposed = false;
   ref->hash = hash;
   ref->stored = NULL;
+  ref->loaded = NULL;
   bitmap_initialize (>indep_loop, _bitmap_obstack);
   bitmap_initialize (>dep_loop, _bitmap_obstack);
   ref->accesses_in_loop.create (1);
@@ -1435,6 +1438,27 @@ mark_ref_stored (im_mem_ref *ref, class loop *loop)
 loop = loop_outer (loop);
 }
 
+/* Set the LOOP bit in REF loaded bitmap and allocate that if
+   necessary.  Return whether a bit was changed.  */
+
+static bool
+set_ref_loaded_in_loop (im_mem_ref *ref, class loop *loop)
+{
+  if (!ref->loaded)
+ref->loaded = BITMAP_ALLOC (_bitmap_obstack);
+  return bitmap_set_bit (ref->loaded, loop->num);
+}
+
+/* Marks reference REF as loaded in LOOP.  */
+
+static void
+mark_ref_loaded (im_mem_ref *ref, class loop *loop)
+{
+  while (loop != current_loops->tree_root
+&& set_ref_loaded_in_loop (ref, loop))
+loop = loop_outer (loop);
+}
+
 /* Gathers memory references in statement STMT in LOOP, storing the
information about them in the memory_accesses structure.  Marks
the vops accessed through unrecognized statements there as
@@ -1571,6 +1595,8 @@ gather_mem_refs_stmt (class loop *loop, gimple *stmt)
   bitmap_set_bit (_accesses.refs_stored_in_loop[loop->num], 
ref->id);
   mark_ref_stored (ref, loop);
 }
+  else
+mark_ref_loaded (ref, loop);
   init_lim_data (stmt)->ref = ref->id;
   return;
 }
@@ -1968,6 +1994,8 @@ 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);
@@ -2115,14 +2143,17 @@ execute_sm (class loop *loop, vec exits, 
im_mem_ref *ref)
  by move_computations after all dependencies.  */
   gsi = gsi_for_stmt (first_mem_ref_loc (loop, ref)->stmt);
 
-  /* FIXME/TODO: For the multi-threaded variant, we could avoid this
- load altogether, since the store is predicated by a flag.  We
- could, do the load only if it was originally in the loop.  */
-  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);
+  /* Avoid 

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

[Florian Weimer via Gcc-patches]

* Kyrylo Tkachov:

> This patch fixes 
> https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545004.html by using 
> __getauxval in the libgcc code.
> Bootstrap and testing on aarch64-none-linux-gnu shows no problem.
> From what I could gather from my glibc testing the elf/check-localplt test 
> passes.
>
> Joseph, Florian, does this fix look like what you had in mind?
> If I commit it to trunk and the branches will glibc be fine with it?

Doesn't this cause an implicit function declaration warning?

Thanks,
Florian

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

[Kyrylo Tkachov]

Hi all,

This patch fixes https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545004.html 
by using __getauxval in the libgcc code.
Bootstrap and testing on aarch64-none-linux-gnu shows no problem.
>From what I could gather from my glibc testing the elf/check-localplt test 
>passes.

Joseph, Florian, does this fix look like what you had in mind?
If I commit it to trunk and the branches will glibc be fine with it?

Thanks,
Kyrill

2020-05-04  Kyrylo Tkachov  

* config/aarch64/lse-init.c (init_have_lse_atomics): Use __getauxval
instead of getauxval.


ool-auxval.patch
Description: ool-auxval.patch

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

[Kamil Rytarowski]

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.



signature.asc
Description: OpenPGP digital signature

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

[Jakub Jelinek via Gcc-patches]

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

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

[Kamil Rytarowski]

On 03.05.2020 22:31, Andreas Tobler wrote:
> On 03.05.20 18:27, Kamil Rytarowski wrote:
>> On 01.05.2020 21:49, Andreas Tobler wrote:
>>> Hi all,
>>>
>>> FreeBSD does not have the alloca.h header. Do not include it in the test
>>> cases which do include alloca.h.
>>>
>>> There are two versions of this patch available, the one attached which
>>> uses ifdef or another one which defines alloca with __builtin_alloca.
>>>
>>> I tested both approaches and they work on FreeBSD. I do not know which
>>> one you prefer.
>>>
>>> Opinions welcome.
>>>
>>> Ok for trunk?
>>> TIA,
>>> Andreas
>>
>> 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.



signature.asc
Description: OpenPGP digital signature

RE: Should ARMv8-A generic tuning default to -moutline-atomics

[Kyrylo Tkachov]

Hi all,

> -Original Message-
> From: Florian Weimer 
> Sent: 04 May 2020 09:35
> To: Joseph Myers 
> Cc: Kyrylo Tkachov ; Andrew Pinski
> ; gcc-patches@gcc.gnu.org; nmeye...@amzn.com
> Subject: Re: Should ARMv8-A generic tuning default to -moutline-atomics
> 
> * Joseph Myers:
> 
> > I think this change is what introduced a glibc testsuite regression in the
> > localplt test.
> >
> > https://sourceware.org/pipermail/libc-testresults/2020q2/006097.html
> >
> > Contents of elf/check-localplt.out:
> >
> > Extra PLT reference: libc.so: getauxval
> >
> > A reference to getauxval from libgcc is also a namespace violation, since
> > that name is in the user's namespace and to users may define it with their
> > own semantics.  glibc deliberately provides __getauxval at a public symbol
> > version for use in libgcc.  (But once libgcc is using __getauxval, glibc
> > will probably still need updating to allow a local PLT reference to
> > __getauxval from libc.so, as libgcc code that gets statically linked into
> > libc.so can't use glibc's internal hidden symbol conventions because it
> > also gets used outside of libc.so.)
> 
> I think you are are right.  From libgcc/config/aarch64/lse-init.c:
> 
> static void __attribute__((constructor))
> init_have_lse_atomics (void)
> {
>   unsigned long hwcap = getauxval (AT_HWCAP);
>   __aarch64_have_lse_atomics = (hwcap & HWCAP_ATOMICS) != 0;
> }
> 
> I should have seen this as the original patches went in, sorry.
> 
> The question, of course, is if we expect people to call __getauxval, why
> do we not declare it in the header file?  And with sufficient compiler
> support, redirect callers to that alias?
> 
> The same question applies to __secure_getenv, where we actually moved in
> the other direction!
> 
> This never had made sense to me, and it still does not.

Thanks Joseph for reporting this, I'm testing a patch to replace getauxval with 
__getauxval.
So far it passed GCC bootstrap and testing (I haven't tried the glibc tests 
yet).
Is that the desirable fix at this point in GCC?
Thanks,
Kyrill

> 
> Thanks,
> Florian

Re: Should ARMv8-A generic tuning default to -moutline-atomics

[Florian Weimer via Gcc-patches]

* Joseph Myers:

> I think this change is what introduced a glibc testsuite regression in the 
> localplt test.
>
> https://sourceware.org/pipermail/libc-testresults/2020q2/006097.html
>
> Contents of elf/check-localplt.out:
>
> Extra PLT reference: libc.so: getauxval
>
> A reference to getauxval from libgcc is also a namespace violation, since 
> that name is in the user's namespace and to users may define it with their 
> own semantics.  glibc deliberately provides __getauxval at a public symbol 
> version for use in libgcc.  (But once libgcc is using __getauxval, glibc 
> will probably still need updating to allow a local PLT reference to 
> __getauxval from libc.so, as libgcc code that gets statically linked into 
> libc.so can't use glibc's internal hidden symbol conventions because it 
> also gets used outside of libc.so.)

I think you are are right.  From libgcc/config/aarch64/lse-init.c:

static void __attribute__((constructor))
init_have_lse_atomics (void)
{
  unsigned long hwcap = getauxval (AT_HWCAP);
  __aarch64_have_lse_atomics = (hwcap & HWCAP_ATOMICS) != 0;
}

I should have seen this as the original patches went in, sorry.

The question, of course, is if we expect people to call __getauxval, why
do we not declare it in the header file?  And with sufficient compiler
support, redirect callers to that alias?

The same question applies to __secure_getenv, where we actually moved in
the other direction!

This never had made sense to me, and it still does not.

Thanks,
Florian

Re: [PATCH] var-tracking.c: Fix possible use of uninitialized variable pre

[Andreas Krebbel via Gcc-patches]

On 04.05.20 09:27, Richard Biener wrote:
> On Mon, May 4, 2020 at 8:14 AM Andreas Krebbel  wrote:
>>
>> On 30.04.20 18:33, Richard Biener wrote:
>>> On Thu, Apr 30, 2020 at 5:14 PM Andreas Krebbel  
>>> wrote:

 On 30.04.20 08:25, Richard Biener via Gcc-patches wrote:
> On Wed, Apr 29, 2020 at 5:56 PM Jeff Law  wrote:
>>
>> On Tue, 2020-04-28 at 11:44 +0200, Richard Biener via Gcc-patches wrote:
>>>
>>> Btw, does s390 have different inlining parameters somehow?
>> I think so.  We saw a ton of backend warnings that were specific to the 
>> s390
>> builds in Fedora that appeared to be triggered by different inlining 
>> decisions.
>>
>> It happened enough that one of the ideas we're going to explore is 
>> seeing if we
>> can tune the x86_64 port to use the same heuristics.  That way we can 
>> try to find
>> more of these issues in our tester without having to dramatically 
>> increase s390x
>> resourcing.  This hasn't started, but I expect we'll be looking at it in 
>> the fall
>> (it's unclear if we can just use flags or will need hackery to the x86 
>> port, but
>> we're happy to share whatever we find with the wider community).
>
> Hmm, OK.  Guess if it becomes an issue for openSUSE I'll simply revert 
> those
> s390 backend changes.

 Too bad. I would prefer to fix the root cause of the warnings instead. 
 Isn't it a good thing that
 thanks to the more aggressive inlining actual bugs in the code get 
 revealed? Or do you see other
 issues with that?
>>>
>>> I'm obviously more concerned about latent GCC issues only popping up
>>> on s390.  Basically
>>> the s390 limits throw much of the QA done on x86_64 targets away when
>>> comparing to s390.
>> That's indeed a problem. It isn't only about GCC itself. We also see more 
>> bugs in distro packages
>> revealed on s390.  But in the end these often are actual bugs and should be 
>> fixed one way or the
>> other. Wouldn't it be better to find more of these bugs upfront?
>>
>> Would it perhaps make sense to introduce an optimization level which tries 
>> to maximize the number of
>> warnings produced? I know this might be tricky since some optimizations tend 
>> to produce a certain
>> set of warnings while reducing warnings in another area at the same time. 
>> But still I think there
>> would be some value in picking extreme params with that option and have it 
>> consistent across archs.
>>
>>> For example we do burn-in testing of a new GCC release (10.1 here) in
>>> openSUSE Factory
>>> by using it as system compiler.  Then with GCC 10.2 we ship it as
>>> compiler for their own use
>>> to SLES users and ISVs.  But obviously all the burn-in testing on
>>> openSUSE Factory
>>> is very x86_64 centric these days.
>> I think Matthias is doing this with Ubuntu also for other archs. Thanks to 
>> him we are usually able
>> to fix a bunch of problems beforehand. Kudos to him for doing that!
> 
> For build testing yes, but does it really receive much usage?
Right, it is mostly build testing plus package testsuites which are run as part 
of the package build.

> 
>
> As a general advice to backend developers I _strongly_ discourage to 
> adjust
> --param defaults that affect GIMPLE.

 We did tons of measurements to find these values recently and got a nice 
 speedup after increasing
 them. We also had a look at the size increase of binaries. It was 
 significant but we decided that
 the performance benefit is worth it. On IBM Z the function call overhead 
 is bigger than on other
 archs so inlining in general helps us.

 I'm not sure I understand your recommendation to leave these values as is. 
 I assumed that such
 parameters are supposed to be used to deal with the characteristics of a 
 platform. Are there better
 ways to achieve the same effect?
>>>
>>> Get more inlining than other archs?  No, I don't think so.  But if the
>>> call overhead is bigger then
>>> you should adjust the cost of calls instead?
>> Is there a dedicated knob for adjusting call costs? We played with 
>> branch-costs in the past but this
>> is not dedicated to just calls. Increasing it usually had negative effects 
>> for our target, although
>> we might need to re-iterate on that one as well.
> 
> There's no --param for call cost, there's some knobs for
> prologue/epilogue costs and also
> the magic early-inline-insns (which in early days was supposed to be
> the call overhead).
> There's
> 
> /* Initializes weights used by estimate_num_insns.  */
> 
> void
> init_inline_once (void)
> {
>   eni_size_weights.call_cost = 1;
>   eni_size_weights.indirect_call_cost = 3;
> ...
>   /* Estimating time for call is difficult, since we have no idea what the
>  called function does.  In the current uses of eni_time_weights,
>  underestimating the cost does less harm than overestimating 

Re: [PATCH] fix Ada bootstrap on Cygwin64 (PR bootstrap/94918)

[Arnaud Charlet]

> > If there is an issue, it would be in "s-oscons-tmplt.c" which is supposed
> > to define Serial_Port_Descriptor as:
> >
> >subtype Serial_Port_Descriptor is System.Win32.HANDLE;
> >
> > See:
> >
> > #if defined (__MINGW32__) || defined (__CYGWIN__)
> > # define TARGET_OS "Windows"
> > # define Serial_Port_Descriptor "System.Win32.HANDLE"
> > TXT("with System.Win32;")
> 
> Thanks, the "|| defined(__CYGWIN__)" is missing so
> Serial_Port_Descriptor becomes "int" on Cygwin, triggering the error.
> Revised patch below, re-tested on Cygwin64.

OK, this part (s-oscons-tmplt.c) is actually already pending on our side and
will be merged soon now that we're in stage 1, so we're good on that front.

For the rest of the patch (mingw32.h and unwind-generic.h), I'll let a cygwin
specialist comment/approve, it's OK with me on principle.

> This fixes three compilation errors preventing bootstrap of gcc-10/11
> with Ada on x86_64-pc-cygwin.  See PR bootstrap/94918 for details.
> 
> Tested by bootstrapping on x86_64-pc-cygwin, and since it touches code
> shared with mingw, also by building a cross to x86_64-w64-mingw32.
> 
> Ok for master and gcc-10 branch?
> 
> (I don't have commit rights, so I will need assistance with that.)
> 
> (The patch is also attached, since gmail _will_ corrupt this text.)
> 
> gcc/ada/
> 
> 2020-05-03  Mikael Pettersson  
> 
> PR bootstrap/94918
> 
> * mingw32.h: Prevent windows.h from including emmintrin.h on Cygwin64.
> * s-oscons-tmplt.c (Serial_Port_Descriptor): Define as
> System.Win32.HANDLE also on Cygwin.
> 
> libgcc/
> 
> 2020-05-03  Mikael Pettersson  
> 
> PR bootstrap/94918
> 
> * unwind-generic.h (__SEH__): Prevent windows.h from including
> x86intrin.h and emmintrin.h.

Re: [PATCH] var-tracking.c: Fix possible use of uninitialized variable pre

[Richard Biener via Gcc-patches]

On Mon, May 4, 2020 at 8:14 AM Andreas Krebbel  wrote:
>
> On 30.04.20 18:33, Richard Biener wrote:
> > On Thu, Apr 30, 2020 at 5:14 PM Andreas Krebbel  
> > wrote:
> >>
> >> On 30.04.20 08:25, Richard Biener via Gcc-patches wrote:
> >>> On Wed, Apr 29, 2020 at 5:56 PM Jeff Law  wrote:
> 
>  On Tue, 2020-04-28 at 11:44 +0200, Richard Biener via Gcc-patches wrote:
> >
> > Btw, does s390 have different inlining parameters somehow?
>  I think so.  We saw a ton of backend warnings that were specific to the 
>  s390
>  builds in Fedora that appeared to be triggered by different inlining 
>  decisions.
> 
>  It happened enough that one of the ideas we're going to explore is 
>  seeing if we
>  can tune the x86_64 port to use the same heuristics.  That way we can 
>  try to find
>  more of these issues in our tester without having to dramatically 
>  increase s390x
>  resourcing.  This hasn't started, but I expect we'll be looking at it in 
>  the fall
>  (it's unclear if we can just use flags or will need hackery to the x86 
>  port, but
>  we're happy to share whatever we find with the wider community).
> >>>
> >>> Hmm, OK.  Guess if it becomes an issue for openSUSE I'll simply revert 
> >>> those
> >>> s390 backend changes.
> >>
> >> Too bad. I would prefer to fix the root cause of the warnings instead. 
> >> Isn't it a good thing that
> >> thanks to the more aggressive inlining actual bugs in the code get 
> >> revealed? Or do you see other
> >> issues with that?
> >
> > I'm obviously more concerned about latent GCC issues only popping up
> > on s390.  Basically
> > the s390 limits throw much of the QA done on x86_64 targets away when
> > comparing to s390.
> That's indeed a problem. It isn't only about GCC itself. We also see more 
> bugs in distro packages
> revealed on s390.  But in the end these often are actual bugs and should be 
> fixed one way or the
> other. Wouldn't it be better to find more of these bugs upfront?
>
> Would it perhaps make sense to introduce an optimization level which tries to 
> maximize the number of
> warnings produced? I know this might be tricky since some optimizations tend 
> to produce a certain
> set of warnings while reducing warnings in another area at the same time. But 
> still I think there
> would be some value in picking extreme params with that option and have it 
> consistent across archs.
>
> > For example we do burn-in testing of a new GCC release (10.1 here) in
> > openSUSE Factory
> > by using it as system compiler.  Then with GCC 10.2 we ship it as
> > compiler for their own use
> > to SLES users and ISVs.  But obviously all the burn-in testing on
> > openSUSE Factory
> > is very x86_64 centric these days.
> I think Matthias is doing this with Ubuntu also for other archs. Thanks to 
> him we are usually able
> to fix a bunch of problems beforehand. Kudos to him for doing that!

For build testing yes, but does it really receive much usage?

> >>>
> >>> As a general advice to backend developers I _strongly_ discourage to 
> >>> adjust
> >>> --param defaults that affect GIMPLE.
> >>
> >> We did tons of measurements to find these values recently and got a nice 
> >> speedup after increasing
> >> them. We also had a look at the size increase of binaries. It was 
> >> significant but we decided that
> >> the performance benefit is worth it. On IBM Z the function call overhead 
> >> is bigger than on other
> >> archs so inlining in general helps us.
> >>
> >> I'm not sure I understand your recommendation to leave these values as is. 
> >> I assumed that such
> >> parameters are supposed to be used to deal with the characteristics of a 
> >> platform. Are there better
> >> ways to achieve the same effect?
> >
> > Get more inlining than other archs?  No, I don't think so.  But if the
> > call overhead is bigger then
> > you should adjust the cost of calls instead?
> Is there a dedicated knob for adjusting call costs? We played with 
> branch-costs in the past but this
> is not dedicated to just calls. Increasing it usually had negative effects 
> for our target, although
> we might need to re-iterate on that one as well.

There's no --param for call cost, there's some knobs for
prologue/epilogue costs and also
the magic early-inline-insns (which in early days was supposed to be
the call overhead).
There's

/* Initializes weights used by estimate_num_insns.  */

void
init_inline_once (void)
{
  eni_size_weights.call_cost = 1;
  eni_size_weights.indirect_call_cost = 3;
...
  /* Estimating time for call is difficult, since we have no idea what the
 called function does.  In the current uses of eni_time_weights,
 underestimating the cost does less harm than overestimating it, so
 we choose a rather small value here.  */
  eni_time_weights.call_cost = 10;
  eni_time_weights.indirect_call_cost = 15;

which would hint at a place to introduce target dependences.  Note there's
also 

Ping: [PATCH] wwwdocs: Add D front-end section for GCC 10 changes

[Iain Buclaw via Gcc-patches]

Ping

Another thing that forgot to mention was added __traits(getLinkage) support for 
class/struct types. Will include that too.

Iain

On 28 April 2020 01:12:19 CEST, Iain Buclaw  wrote:
>Hi,
>
>This patch adds a section on the D front-end about all changes that have
>gone into the GCC 10 release.  W3 validator reports there are no errors
>or warnings to show.
>
>Any comments or clarifications required on what's written up?  Or is it
>OK to commit to the website?
>
>Regards
>Iain.
>
>---
> htdocs/gcc-10/changes.html | 31 +++
> 1 file changed, 31 insertions(+)
>
>diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
>index 41c2dc0d..af8c72eb 100644
>--- a/htdocs/gcc-10/changes.html
>+++ b/htdocs/gcc-10/changes.html
>@@ -432,6 +432,37 @@ a work-in-progress.
>   
> 
> 
>+D
>+
>+  Support for static foreach has been implemented.
>+  Aliases can now be created directly from any __trait that
>+  return symbols or tuples.  Previously, an AliasSeq was
>+  necessary in order to alias their return.
>+  
>+  Optional parentheses in asm operands are now deprecated and
>+  will be removed in a future release.
>+  
>+  All content imported files are now included in the make dependency list
>+  when compiling with -M.
>+  
>+  User-defined attributes exposed by the gcc.attribute 
>module,
>+  to which are attached against prototypes of declarations are now also
>+  applied to other matching prototypes and definitions.
>+  
>+  Support for core.math.toPrec intrinsics has been added.
>+  These intrinsics guarantee the rounding to specific floating-point
>+  precisions at required points in the code.
>+  
>+  Support for pragma(inline) has been implemented.
>+  Added --enable-libphobos-checking configure option to
>+  control whether run-time checks are compiled into the D runtime library.
>+  
>+  Added --with-libphobos-druntime-only configure option to
>+  allow specifying whether to build only the core D runtime library, or
>+  both the core and standard libraries into libphobos.
>+  
>+
>+
> Fortran
> 
>   use_device_addr of version 5.0 of the
>-- 
>2.20.1
>

Re: [PATCH] var-tracking.c: Fix possible use of uninitialized variable pre

[Andreas Krebbel via Gcc-patches]

On 30.04.20 18:33, Richard Biener wrote:
> On Thu, Apr 30, 2020 at 5:14 PM Andreas Krebbel  wrote:
>>
>> On 30.04.20 08:25, Richard Biener via Gcc-patches wrote:
>>> On Wed, Apr 29, 2020 at 5:56 PM Jeff Law  wrote:

 On Tue, 2020-04-28 at 11:44 +0200, Richard Biener via Gcc-patches wrote:
>
> Btw, does s390 have different inlining parameters somehow?
 I think so.  We saw a ton of backend warnings that were specific to the 
 s390
 builds in Fedora that appeared to be triggered by different inlining 
 decisions.

 It happened enough that one of the ideas we're going to explore is seeing 
 if we
 can tune the x86_64 port to use the same heuristics.  That way we can try 
 to find
 more of these issues in our tester without having to dramatically increase 
 s390x
 resourcing.  This hasn't started, but I expect we'll be looking at it in 
 the fall
 (it's unclear if we can just use flags or will need hackery to the x86 
 port, but
 we're happy to share whatever we find with the wider community).
>>>
>>> Hmm, OK.  Guess if it becomes an issue for openSUSE I'll simply revert those
>>> s390 backend changes.
>>
>> Too bad. I would prefer to fix the root cause of the warnings instead. Isn't 
>> it a good thing that
>> thanks to the more aggressive inlining actual bugs in the code get revealed? 
>> Or do you see other
>> issues with that?
> 
> I'm obviously more concerned about latent GCC issues only popping up
> on s390.  Basically
> the s390 limits throw much of the QA done on x86_64 targets away when
> comparing to s390.
That's indeed a problem. It isn't only about GCC itself. We also see more bugs 
in distro packages
revealed on s390.  But in the end these often are actual bugs and should be 
fixed one way or the
other. Wouldn't it be better to find more of these bugs upfront?

Would it perhaps make sense to introduce an optimization level which tries to 
maximize the number of
warnings produced? I know this might be tricky since some optimizations tend to 
produce a certain
set of warnings while reducing warnings in another area at the same time. But 
still I think there
would be some value in picking extreme params with that option and have it 
consistent across archs.

> For example we do burn-in testing of a new GCC release (10.1 here) in
> openSUSE Factory
> by using it as system compiler.  Then with GCC 10.2 we ship it as
> compiler for their own use
> to SLES users and ISVs.  But obviously all the burn-in testing on
> openSUSE Factory
> is very x86_64 centric these days.
I think Matthias is doing this with Ubuntu also for other archs. Thanks to him 
we are usually able
to fix a bunch of problems beforehand. Kudos to him for doing that!

>>>
>>> As a general advice to backend developers I _strongly_ discourage to adjust
>>> --param defaults that affect GIMPLE.
>>
>> We did tons of measurements to find these values recently and got a nice 
>> speedup after increasing
>> them. We also had a look at the size increase of binaries. It was 
>> significant but we decided that
>> the performance benefit is worth it. On IBM Z the function call overhead is 
>> bigger than on other
>> archs so inlining in general helps us.
>>
>> I'm not sure I understand your recommendation to leave these values as is. I 
>> assumed that such
>> parameters are supposed to be used to deal with the characteristics of a 
>> platform. Are there better
>> ways to achieve the same effect?
> 
> Get more inlining than other archs?  No, I don't think so.  But if the
> call overhead is bigger then
> you should adjust the cost of calls instead?  
Is there a dedicated knob for adjusting call costs? We played with branch-costs 
in the past but this
is not dedicated to just calls. Increasing it usually had negative effects for 
our target, although
we might need to re-iterate on that one as well.

> Also the default limits
> are a delicate compromise
> between speed and size - of course if you disregard size you get more
> speed.  You also only
> adjusted two out of very many params which are not really as
> independent as one would think...
> (and you forgot to re-tune after last years big changes/parameter space 
> splits).
Oh, we set other inlining params as well. It is just that with z13 we tuned in 
particular also for
these two. Since we don't have measurements on other CPU levels we didn't want 
to risk producing
regressions and just have left the values as is for those.

> As said you should at least think of adjusting the adjustments to be
> relative to the default
> value rather than absolute.
Ok.

Andreas
> 
> Richard.
> 
>> Andreas
>>
>>>
>>> Richard.
>>>
 jeff



>>