Re: [PATCH v4] c++: DR1710, template keyword in a typename-specifier [PR94057]

[Jason Merrill via Gcc-patches]

On 3/24/20 11:45 AM, Marek Polacek wrote:

On Mon, Mar 23, 2020 at 10:41:28AM -0400, Jason Merrill wrote:

On 3/20/20 7:02 PM, Marek Polacek wrote:

On Fri, Mar 20, 2020 at 02:12:49PM -0400, Jason Merrill wrote:

On 3/20/20 1:06 PM, Marek Polacek wrote:

Wonderful.  I've added a bunch of tests, and some from the related DRs too.
But I had a problem with the class-or-decltype case: if we have

template struct D : T::template B::template C {};

then we still require all the 'template' keywords here (as does clang).  So I'm
kind of confused, but I don't think it's a big deal right now.


This seems related enough that I'd like to fix it at the same time; why
doesn't your patch fix it?  Is it because typename_p is false?


Ah, I was mistaken.  Of course we need the template keyword here: it's a member 
of an
unknown specialization!


That's why it's needed in contexts where we don't know whether or not we're
naming a type.  But where we do know that, as in a base-specifier, it isn't
necessary.  This is exactly DR 1710: "The keyword template is optional in a
... class-or-decltype (Clause 11.7 [class.derived])"


Duh, not sure what I was thinking.

I've implemented that in cp_parser_nested_name_specifier_opt: assume 'template'
if we've seen 'typename'.  If it turns out that this is wrong because it
triggers in contexts where it shouldn't, we'll have to introduce something like
CP_PARSER_FLAGS_TEMPLATE_OPTIONAL.

With this another problem revealed: we weren't accepting an alias template
after 'template' which DR1710 says is valid.  Fixed by the TYPE_ALIAS_P hunk
in the new check_template_keyword_in_nested_name_spec. (alias-decl1.C)

But this is still not over: I noticed that

template  struct S {
   template 
   using U = TT;
};
template  typename S::template U::type foo;

is still rejected and shouldn't be.  Here 
check_template_keyword_in_nested_name_spec
gets

  >

Any suggestions how to handle this?


It should work to check for an alias whether or not the target is a 
TYPENAME_TYPE.



FWIW, bootstrapped/regtested on x86_64-linux.

-- >8 --
Consider

   template  class A {
 template  class B {
   void fn(typename A::B);
 };
   };

which is rejected with
error: 'typename A::B' names 'template template class 
A::B', which is not a type
whereas clang/icc/msvc accept it.

"typename A::B" is a typename-specifier.  Sadly, our comments
don't mention it anywhere, because the typename-specifier wasn't in C++11;
it was only added to the language in N1376.  Instead, we handle it as
an elaborated-type-specifier (not a problem thus far).   So we get to
cp_parser_nested_name_specifier_opt which has a loop that breaks if we
don't see a < or ::, but that means we can -- tentatively -- parse even
B which is not a nested-name-specifier (it doesn't end with a ::).

Even though we're parsing B tentatively, we issue an error in
cp_parser_class_name -> make_typename_type, but here we should not.  In
fact, we probably shouldn't have parsed "B" at all.  Fixed by the
cp_parser_class_name hunk.

I think this should compile because [temp.names]/4 says: "In a qualified-id
used as the name in a typename-specifier, elaborated-type-specifier,
using-declaration, or class-or-decltype, an optional keyword template
appearing at the top level is ignored.", added in DR 1710.  Also see
DR 1812.

This issue on its own is not a significant problem or a regression.
However, in C++20, the typename here becomes optional, and so this test
is rejected in C++20, but accepted in C++17:

   template  class A {
 template  class B {
   void fn(A::B);
 };
   };

Here we morph A::B into a typename-specifier, but that happens
in cp_parser_simple_type_specifier and we never handle it as above.
To fake the template keyword I'm afraid we need to use cp_parser_template_id
with template_keyword_p=true as in the patch below.  The tricky thing
is to avoid breaking concepts.

To handle DR 1710, I made cp_parser_nested_name_specifier_opt assume that
when we're naming a type, the template keyword is present, too.  That
revealed a bug: DR 1710 also says that the template keyword can be followed
by an alias template, but we weren't prepared to handle that.  alias-decl1.C
exercise this.

DR 1710
PR c++/94057 - template keyword in a typename-specifier.
* parser.c (check_template_keyword_in_nested_name_spec): New.
(cp_parser_nested_name_specifier_opt): Implement DR1710, optional
'template'.  Call check_template_keyword_in_nested_name_spec.
(cp_parser_simple_type_specifier): Assume that a <
following a qualified-id in a typename-specifier begins
a template argument list.
(cp_parser_class_name): Complain only if not parsing tentatively.

* g++.dg/cpp1y/alias-decl1.C: New test.
* g++.dg/parse/missing-template1.C: Update dg-error.
* g++.dg/parse/template3.C: Likewise.
* g++.dg/template/error4.C: Likewise.
* g++.dg/template/meminit2.C: 

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

[Pop, Sebastian via Gcc-patches]

Hi Kyrill,

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

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

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

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

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

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

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

From-SVN: r266346

That is fixing code modified in this cleanup patch:

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

aarch64: Improve cas generation


Thanks,
Sebastian


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

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



Hi Sebastian,

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

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

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

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

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

and

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

come to mind.

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


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

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

Did these patches have any bug reports against them?

Thanks,

Kyrill


> Here is the list of the extra patches:
>
>  From 77f33f44baf24c22848197aa80962c003dd7b3e2 Mon Sep 17 00:00:00 2001
> From: Richard Henderson 
> Date: Wed, 31 Oct 2018 09:29:29 +
> Subject: [PATCH] aarch64: Simplify LSE cas generation
>
> The cas insn is a single insn, and if expanded properly need not
> be split after reload.  Use the proper inputs for the insn.
>
>  * config/aarch64/aarch64.c (aarch64_expand_compare_and_swap):
>  Force oldval into the rval register for TARGET_LSE; emit the 
compare
>  during initial expansion so that it may be deleted if unused.
>  (aarch64_gen_atomic_cas): Remove.
>  * config/aarch64/atomics.md 
(@aarch64_compare_and_swap_lse):
>  Change = to +r for operand 0; use match_dup for operand 2;
>  remove is_weak and mod_f operands as unused.  Drop the split
>  and merge with...
>  (@aarch64_atomic_cas): ... this pattern's output; remove.
>  (@aarch64_compare_and_swap_lse): Similarly.
>  (@aarch64_atomic_cas): Similarly.
>
> From-SVN: r265656
>
>  From d400fda3a8c3330f77eb9d51874f5482d3819a9f Mon Sep 17 00:00:00 2001
> From: Richard Henderson 
> Date: Wed, 31 Oct 2018 09:42:39 +
> Subject: [PATCH] aarch64: Improve cas generation
>
> Do not zero-extend the input to the cas for subword operations;
> instead, use the appropriate zero-extending compare insns.
> Correct the predicates and 

Bountysource campaign for converting AVR to MODE_CC

[John Paul Adrian Glaubitz]

Hi!

Just as a reminder, we still have a Bountysource campaign for the AVR backend
running in case someone is looking for an opportunity to make a little money
while working on GCC [1].

The campaign has not been as successful as the campaign for m68k [2] but there
is still a chance that we might get some more donations if we spread the word.

But maybe someone is interested nonetheless to work on the AVR backend as a
little sideline.

Thanks,
Adrian

> [1] 
> https://www.bountysource.com/issues/84630749-avr-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases
> [2] 
> https://www.bountysource.com/issues/80706251-m68k-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [PATCH v2] c++: Fix wrong no post-decrement operator error in template [PR94190]

[Jason Merrill via Gcc-patches]

On 3/23/20 11:06 AM, Marek Polacek wrote:

On Tue, Mar 17, 2020 at 04:05:31PM -0400, Jason Merrill wrote:

On 3/16/20 10:01 PM, Marek Polacek wrote:

On Mon, Mar 16, 2020 at 05:12:15PM -0400, Jason Merrill wrote:

On 3/16/20 10:57 AM, Marek Polacek wrote:

Now that convert_like creates an IMPLICIT_CONV_EXPR when it converts
something that involves a class in a template, we must be prepared to
handle it.  In this test, we have a class S and we're converting it
to long int& using a user-defined conversion since we're performing
-- on it.  So cp_build_unary_op/POSTDECREMENT_EXPR calls
build_expr_type_conversion which gets the IMPLICIT_CONV_EXPR.  Before
the convert_like change it got *S::operator long int &() whose type
is long int but now it gets IMPLICIT_CONV_EXPR(b) whose type
is a reference type.


So you need to make sure that your IMPLICIT_CONV_EXPR gets
convert_from_reference'd at some point.


Perhaps like the following?

Bootstrapped/regtested on x86_64-linux, built Boost/cmcstl2.

-- >8 --
Now that convert_like creates an IMPLICIT_CONV_EXPR when it converts
something that involves a class in a template, we must be prepared to
handle it.  In this test, we have a class S and we're converting it
to long int& using a user-defined conversion since we're performing
-- on it.  So cp_build_unary_op/POSTDECREMENT_EXPR calls
build_expr_type_conversion which gets the IMPLICIT_CONV_EXPR.  Before
the convert_like change it got *S::operator long int &() whose type
is long int but now it gets IMPLICIT_CONV_EXPR(b) whose type
is a reference type.  But the !MAYBE_CLASS_TYPE_P switch doesn't handle
reference types and so we complain.

Fixed by calling convert_from_reference on the result of convert_like.

PR c++/94190 - wrong no post-decrement operator error in template.
* call.c (build_new_op_1): Use convert_from_reference on the result
of convert_like.


The result of convert_like should already be dereferenced in this case. I
think convert_like should only return a bare reference for ck_ref_bind,
where we're explicitly requesting one.


I tried to adjust all the appropriate return ...; in convert_like to return
convert_from_reference (...); and then remove unnecessary calls to
convert_from_reference after a call to convert_like elsewhere in the codebase,
but that fails very badly.

But it seems we can use convert_from_reference in convert_like when returning
the new IMPLICIT_CONV_EXPR, like this:

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


OK.


-- >8 --
Now that convert_like creates an IMPLICIT_CONV_EXPR when it converts
something that involves a class in a template, we must be prepared to
handle it.  In this test, we have a class S and we're converting it
to long int& using a user-defined conversion since we're performing
-- on it.  So cp_build_unary_op/POSTDECREMENT_EXPR calls
build_expr_type_conversion which gets the IMPLICIT_CONV_EXPR.  Before
the convert_like change it got *S::operator long int &() whose type
is long int but now it gets IMPLICIT_CONV_EXPR(b) whose type
is a reference type.  But the !MAYBE_CLASS_TYPE_P switch doesn't handle
reference types and so we complain.

Fixed by calling convert_from_reference on the result of convert_like.

PR c++/94190 - wrong no post-decrement operator error in template.
* call.c (convert_like_real): Use convert_from_reference on the result.

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

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 65a3ea35dee..bae4b2c0f52 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -7389,7 +7389,10 @@ convert_like_real (conversion *convs, tree expr, tree 
fn, int argnum,
if (processing_template_decl
&& convs->kind != ck_identity
&& (CLASS_TYPE_P (totype) || CLASS_TYPE_P (TREE_TYPE (expr
-return build1 (IMPLICIT_CONV_EXPR, totype, expr);
+{
+  expr = build1 (IMPLICIT_CONV_EXPR, totype, expr);
+  return convs->kind == ck_ref_bind ? expr : convert_from_reference (expr);
+}
  
switch (convs->kind)

  {
diff --git a/gcc/testsuite/g++.dg/conversion/op7.C 
b/gcc/testsuite/g++.dg/conversion/op7.C
new file mode 100644
index 000..c6401d109b4
--- /dev/null
+++ b/gcc/testsuite/g++.dg/conversion/op7.C
@@ -0,0 +1,22 @@
+// PR c++/94190 - wrong no post-decrement operator error in template.
+
+struct S { operator long & (); } b;
+
+template void
+foo ()
+{
+  b--;
+  ++b;
+  --b;
+  b++;
+  !b;
+  ~b;
+  +b;
+  -b;
+}
+
+void
+bar ()
+{
+  foo<0> ();
+}

base-commit: a3586eeb88414e77c7cccb69362b8d04562536b6

[pushed] c++: Fix template parm with dependent type in concepts.

[Jason Merrill via Gcc-patches]

While looking at PR94186 I also noticed this regression; if a non-type
template parameter uses a type parameter in its type, we need to map both
template parameters.

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

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

* pt.c (any_template_parm_r): Look into the type of a non-type
template parm.
---
 gcc/cp/pt.c|  1 +
 gcc/testsuite/g++.dg/cpp2a/concepts-nonbool2.C | 11 +++
 2 files changed, 12 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-nonbool2.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 03a8dfbd37c..3c96eeca191 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -10431,6 +10431,7 @@ any_template_parm_r (tree t, void *data)
   WALK_SUBTREE (TREE_OPERAND (t, 1));
   break;
 
+case TEMPLATE_PARM_INDEX:
 case PARM_DECL:
   /* A parameter or constraint variable may also depend on a template
 parameter without explicitly naming it.  */
diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-nonbool2.C 
b/gcc/testsuite/g++.dg/cpp2a/concepts-nonbool2.C
new file mode 100644
index 000..ebede46b368
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-nonbool2.C
@@ -0,0 +1,11 @@
+// { dg-do compile { target concepts } }
+
+template
+concept C = requires {
+requires x;// { dg-error "bool" }
+  };
+
+int main() {
+  C;
+  return 0;
+}

base-commit: 07f8bcc6ea9f3c0850a56a7431d866178d5cee92
-- 
2.18.1

[pushed] c++: Improve handling of ill-formed constraints [PR94186].

[Jason Merrill via Gcc-patches]

It would have been trivial to make the error for non-bool constraint in
satisfy_atom unconditional, but that didn't give context for the error or
printing with the dependent form and template arguments.  So I changed a
couple of places so that, when a hard error is encountered during quiet
substitution/satisfaction, we go through again noisily; this builds up the
necessary context.

The similar change to tsubst_nested_requirement does not build up the
necessary context; rather than try to fix that now I changed
get_constraint_error_location to give up and use input_location if there's
no CONSTR_CONTEXT.  In the case of concepts-pr67697.C, we still have a good
source location because the NESTED_REQ has a correct EXPR_LOCATION, but this
patch doesn't improve context printing for this case as it does for the
above.

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

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

PR c++/94186
* constraint.cc (constraint_satisfaction_value): Repeat noisily on
error.
(tsubst_nested_requirement): Likewise.
(get_constraint_error_location): Allow missing context.
(diagnose_atomic_constraint): Diagnose non-bool constraint here.
(satisfy_atom): Not here.  Only diagnose non-constant when noisy.
---
 gcc/cp/constraint.cc  | 79 +--
 gcc/testsuite/g++.dg/concepts/pr84330.C   |  2 +-
 .../g++.dg/cpp2a/concepts-nonbool1.C  | 20 +
 .../g++.dg/cpp2a/concepts-requires1.C |  4 +-
 .../g++.dg/cpp2a/concepts-requires2.C | 12 +--
 5 files changed, 86 insertions(+), 31 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-nonbool1.C

diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index 5e434be815f..a86bcdf603a 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -2004,6 +2004,11 @@ 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 result = satisfy_constraint (norm, args, info);
+  if (result == error_mark_node && info.quiet ())
+{
+  subst_info noisy (tf_warning_or_error, info.in_decl);
+  satisfy_constraint (norm, args, noisy);
+}
   if (result != boolean_true_node)
 return error_mark_node;
   return result;
@@ -2489,7 +2494,7 @@ get_mapped_args (tree map)
   return args;
 }
 
-static void diagnose_atomic_constraint (tree, tree, subst_info);
+static void diagnose_atomic_constraint (tree, tree, tree, subst_info);
 
 /* Compute the satisfaction of an atomic constraint.  */
 
@@ -2534,8 +2539,6 @@ satisfy_atom (tree t, tree args, subst_info info)
   return cache.save (boolean_false_node);
 }
 
-  location_t loc = cp_expr_loc_or_input_loc (expr);
-
   /* [17.4.1.2] ... lvalue-to-rvalue conversion is performed as necessary,
  and EXPR shall be a constant expression of type bool.  */
   result = force_rvalue (result, info.complain);
@@ -2544,14 +2547,22 @@ satisfy_atom (tree t, tree args, subst_info info)
   if (!same_type_p (TREE_TYPE (result), boolean_type_node))
 {
   if (info.noisy ())
-   error_at (loc, "constraint does not have type %");
+   diagnose_atomic_constraint (t, map, result, info);
   return cache.save (error_mark_node);
 }
 
   /* Compute the value of the constraint.  */
-  result = satisfaction_value (cxx_constant_value (result));
+  if (info.noisy ())
+result = cxx_constant_value (result);
+  else
+{
+  result = maybe_constant_value (result);
+  if (!TREE_CONSTANT (result))
+   result = error_mark_node;
+}
+  result = satisfaction_value (result);
   if (result == boolean_false_node && info.noisy ())
-diagnose_atomic_constraint (t, map, info);
+diagnose_atomic_constraint (t, map, result, info);
 
   return cache.save (result);
 }
@@ -2733,20 +2744,34 @@ static tree
 constraint_satisfaction_value (tree t, tsubst_flags_t complain)
 {
   subst_info info (complain, NULL_TREE);
+  tree r;
   if (DECL_P (t))
-return satisfy_declaration_constraints (t, info);
+r = satisfy_declaration_constraints (t, info);
   else
-return satisfy_constraint_expression (t, NULL_TREE, info);
+r = satisfy_constraint_expression (t, NULL_TREE, info);
+  if (r == error_mark_node && info.quiet ()
+  && !(DECL_P (t) && TREE_NO_WARNING (t)))
+  {
+   constraint_satisfaction_value (t, tf_warning_or_error);
+   if (DECL_P (t))
+ /* Avoid giving these errors again.  */
+ TREE_NO_WARNING (t) = true;
+  }
+  return r;
 }
 
 static tree
 constraint_satisfaction_value (tree t, tree args, tsubst_flags_t complain)
 {
   subst_info info (complain, NULL_TREE);
+  tree r;
   if (DECL_P (t))
-return satisfy_declaration_constraints (t, args, info);
+r = satisfy_declaration_constraints (t, args, info);
   else
-return satisfy_constraint_expression (t, args, info);
+r = 

[pushed] c++: Give more expressions locations.

[Jason Merrill via Gcc-patches]

In the testcase for PR94186, we have a SCOPE_REF with no location even
though at one point it was in a cp_expr which had a location.  So let's make
the cp_expr constructor that takes a location apply it to the expression
when possible.

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

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

* cp-tree.h (cp_expr): When constructing from an expr and a
location, call protected_set_expr_location.
---
 gcc/cp/cp-tree.h   | 5 -
 gcc/testsuite/g++.dg/ext/stmtexpr15.C  | 2 +-
 gcc/testsuite/g++.dg/parse/error26.C   | 2 +-
 gcc/testsuite/g++.dg/warn/Wnoexcept1.C | 2 +-
 4 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 0783b3114f2..4e1d0f1d42e 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -59,7 +59,10 @@ public:
 m_value (value), m_loc (cp_expr_location (m_value)) {}
 
   cp_expr (tree value, location_t loc):
-m_value (value), m_loc (loc) {}
+m_value (value), m_loc (loc)
+  {
+protected_set_expr_location (value, loc);
+  }
 
   /* Implicit conversions to tree.  */
   operator tree () const { return m_value; }
diff --git a/gcc/testsuite/g++.dg/ext/stmtexpr15.C 
b/gcc/testsuite/g++.dg/ext/stmtexpr15.C
index 10c4886c10c..27406e1e37f 100644
--- a/gcc/testsuite/g++.dg/ext/stmtexpr15.C
+++ b/gcc/testsuite/g++.dg/ext/stmtexpr15.C
@@ -4,5 +4,5 @@
 void foo()
 {
   int x[({ return; })];// { dg-error "could not convert" }
-// { dg-error "12:size of array .x. has non-integral" "" { target *-*-* } .-1 
}  
+// { dg-error "9:size of array .x. has non-integral" "" { target *-*-* } .-1 } 
 
 }
diff --git a/gcc/testsuite/g++.dg/parse/error26.C 
b/gcc/testsuite/g++.dg/parse/error26.C
index 95f299163e9..4005fd5025f 100644
--- a/gcc/testsuite/g++.dg/parse/error26.C
+++ b/gcc/testsuite/g++.dg/parse/error26.C
@@ -4,7 +4,7 @@
 void foo()
 {
   if (({int c[2];})) ; // { dg-error "7:ISO C.. forbids" "7" }
-  // { dg-error "17:could not convert" "17" { target *-*-* } .-1 }
+  // { dg-error "7:could not convert" "17" { target *-*-* } .-1 }
 }
 
 void bar()
diff --git a/gcc/testsuite/g++.dg/warn/Wnoexcept1.C 
b/gcc/testsuite/g++.dg/warn/Wnoexcept1.C
index 93210dead04..4fac3675cf6 100644
--- a/gcc/testsuite/g++.dg/warn/Wnoexcept1.C
+++ b/gcc/testsuite/g++.dg/warn/Wnoexcept1.C
@@ -7,7 +7,7 @@
 // We expect a warning at the declaration of construct2, since Automatic2 is
 // defined below; we don't expect one for construct1, because Automatic1 is
 // defined in the fake system header.
-// { dg-warning "noexcept-expression" "" { target *-*-* } 15 }
+// { dg-warning "noexcept-expression" "" { target *-*-* } 16 }
 
 class Automatic2 {
 public:

base-commit: 07f8bcc6ea9f3c0850a56a7431d866178d5cee92
-- 
2.18.1

[committed] wwwdocs: Switch link to check_GNU_style.sh from ViewCVS to Git.

[Gerald Pfeifer]

Thanks to Frank Ch. Eigler for the updated link.

Pushed.

Gerald
---
 htdocs/contribute.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/htdocs/contribute.html b/htdocs/contribute.html
index 052f778e..3d03b9d1 100644
--- a/htdocs/contribute.html
+++ b/htdocs/contribute.html
@@ -70,7 +70,7 @@ requirements as well as requirements on code formatting.
 Submissions which do not conform to the standards will be returned
 with a request to address any such problems.  To help with the
 preparation of patches you can use the script https://gcc.gnu.org/viewcvs/gcc/trunk/contrib/check_GNU_style.sh?view=markup;>
+"https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=contrib/check_GNU_style.sh;>
 contrib/check_GNU_style.sh.
 
 
-- 
2.25.1

Re: [PATCH 24/25] Ignore LLVM's blank lines.

[Thomas Schwinge]

Hi!

On 2020-03-23T16:29:40+0100, I wrote:
> On 2018-09-14T10:18:12-0600, Jeff Law  wrote:
>> On 9/5/18 5:52 AM, a...@codesourcery.com wrote:
>>>
>>> The GCN toolchain must use the LLVM assembler and linker because there's no
>>> binutils port.  The LLVM tools do not have the same diagnostic style as
>>> binutils
>
> For reference:
> 'libgomp.c++/../libgomp.c-c++-common/function-not-offloaded.c', for
> example:
>
> ld: error: undefined symbol: foo()
> >>> referenced by /tmp/ccNzknBD.o:(main._omp_fn.0)
> >>> referenced by /tmp/ccNzknBD.o:(main._omp_fn.0)
>
> ld: error: undefined symbol: __gxx_personality_v0
> >>> referenced by /tmp/ccNzknBD.o:(.data+0x13)
> collect2: error: ld returned 1 exit status
> mkoffload: fatal error: 
> [...]/build-gcc/./gcc/x86_64-pc-linux-gnu-accel-amdgcn-amdhsa-gcc returned 1 
> exit status
>
> Note the blank line between the two "diagnostic blocks".
>
>>> so the "blank line(s) in output" tests are inappropriate (and very
>>> noisy).

> So here is a different proposal.  The problem we're having is that the
> AMD GCN 'as' (that is, 'llvm-mc') prints "unsuitable" diagnostics (as
> quoted at the top of my email).

(No idea where I got the idea from that 'as' prints 'ld' error messages,
as displayed above...)  ;-) (But supposedly that problem applies to both,
or even generally all LLVM tools?)

> How about having a simple wrapper around it, to post-process its 'stderr'
> to remove any blank linkes between "diagnostic blocks"?  Then we could
> remove this fragile 'check_effective_target_llvm_binutils' etc.?
>
> I shall offer to implement the simple shell script, and suppose this
> could live in 'gcc/config/gcn/'?

I have implemented that, and it appears to generally work, but of
course...

> ("Just" need to figure out how to
> integrate that into the GCC build process, top-level build system.)

... this was the non-trivial bit, and may need some further thought --
which I can't allocate time for right now, so I'll postpone this for
later.  I'm attaching my "[WIP] 'llvm-tools-wrapper' [PR88920]" patch, in
case somebody would like to have a first look.


Grüße
 Thomas


-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter
>From 31c8828d37bed37b4ee4eb3bbefb8eb1db46e0a1 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Tue, 24 Mar 2020 21:59:04 +0100
Subject: [PATCH] [WIP] 'llvm-tools-wrapper' [PR88920]

	PR testsuite/88920
---
 gcc/Makefile.in   |   9 ++
 gcc/config.in |   6 +
 gcc/configure |  17 +++
 gcc/configure.ac  |  12 ++
 gcc/doc/sourcebuild.texi  |   6 -
 gcc/gcc.c | 116 +++---
 gcc/llvm-tools-wrapper.in |  35 ++
 gcc/testsuite/lib/gcc-dg.exp  |   4 -
 gcc/testsuite/lib/target-supports.exp |  15 ---
 .../function-not-offloaded.c  |   1 -
 10 files changed, 175 insertions(+), 46 deletions(-)
 create mode 100755 gcc/llvm-tools-wrapper.in

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index fa9923bb2703..4d13707453b2 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1974,6 +1974,7 @@ start.encap: native xgcc$(exeext) cpp$(exeext) specs \
 rest.encap: lang.rest.encap
 # This is what is made with the host's compiler
 # whether making a cross compiler or not.
+#TODO Do we need 'llvm-tools-wrapper' here?
 native: config.status auto-host.h build-@POSUB@ $(LANGUAGES) \
 	$(EXTRA_PROGRAMS) $(COLLECT2) lto-wrapper$(exeext) \
 	gcc-ar$(exeext) gcc-nm$(exeext) gcc-ranlib$(exeext)
@@ -3525,6 +3526,10 @@ ifeq ($(enable_plugin),yes)
 install: install-plugin
 endif
 
+#TODO ifeq (TODO)
+install: install-llvm-tools-wrapper
+#TODO endif
+
 install-strip: override INSTALL_PROGRAM = $(INSTALL_STRIP_PROGRAM)
 ifneq ($(STRIP),)
 install-strip: STRIPPROG = $(STRIP)
@@ -3920,6 +3925,10 @@ install-gcc-ar: installdirs gcc-ar$(exeext) gcc-nm$(exeext) gcc-ranlib$(exeext)
 	  done; \
 	fi
 
+# Install llvm-tools-wrapper.
+install-llvm-tools-wrapper: llvm-tools-wrapper$(exeext)
+	$(INSTALL_PROGRAM) llvm-tools-wrapper$(exeext) $(DESTDIR)$(libexecsubdir)/llvm-tools-wrapper$(exeext)
+
 # Cancel installation by deleting the installed files.
 uninstall: lang.uninstall
 	-rm -rf $(DESTDIR)$(libsubdir)
diff --git a/gcc/config.in b/gcc/config.in
index 01fb18dbbb5a..ab51b9aef898 100644
--- a/gcc/config.in
+++ b/gcc/config.in
@@ -2042,6 +2042,12 @@
 #endif
 
 
+/* Define if using LLVM tools. */
+#ifndef USED_FOR_TARGET
+#undef LLVM_TOOLS_WRAPPER
+#endif
+
+
 /* Define to the name of the LTO plugin DSO that must be passed to the
linker's -plugin=LIB option. */
 #ifndef USED_FOR_TARGET
diff --git a/gcc/configure b/gcc/configure
index 5381e107bce7..06f46c4bd6b0 100755
--- a/gcc/configure
+++ 

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

[Mike Stump via Gcc-patches]

On Mar 17, 2020, at 2:52 PM, Maciej W. Rozycki  wrote:
> 
> On Fri, 28 Feb 2020, H.J. Lu wrote:
>> 
>> Libffi 3.4 ABI was changed to support CET.  But it isn't the first
>> time ABI change for libffi,
> 
> Have we made any conclusions WRT the way to move forward with this stuff?  
> Things remain broken and I'd prefer to get the issues off the plate while 
> the stuff is hot, or at least mildly warm.  I'm about to get distracted 
> with other work.

It's unfortunate that upstream has anything that prevents it from us just 
importing it all and calling it done.

Anyway, if you see a path forward for grabbing all the Makefile/config stuff 
and leaving the abi changing stuff out, and just important that, we can do a 
partial import.  I say this without reviewing the diffs from upstream and how 
many there are and what's in them.  I'm hoping things are nicely segregated and 
reasonably small otherwise.

That could unblock your concerns and you can leave the rest for some else that 
can play with the abi.

Re: [PATCH] coroutines: Implement n4849 recommended symmetric transfer.

[Iain Sandoe]

Nathan Sidwell  wrote:


On 3/24/20 2:08 PM, Iain Sandoe wrote:

Hi Nathan,
Thanks for the review,
comments embedded and a new version attached.
@David, you added the CALL_EXPR_MUST_TAIL_CALL which I’ve made use of
here (but with an observation).  Perhaps you would be able to comment on  
whether

I’ve (ab-)used it correctly?
OK for master now?
thanks
Iain
Nathan Sidwell  wrote:

On 3/20/20 11:40 AM, Iain Sandoe via Gcc-patches wrote:

   tree suspend = TREE_VEC_ELT (awaiter_calls, 1); /* await_suspend().  */
+  tree susp_type;
+  if (TREE_CODE (suspend) == CALL_EXPR)
+{
+  susp_type = CALL_EXPR_FN (suspend);
+  if (TREE_CODE (susp_type) == ADDR_EXPR)
+   susp_type = TREE_OPERAND (susp_type, 0);
+  susp_type = TREE_TYPE (TREE_TYPE (susp_type));
+}
+  else
+susp_type = TREE_TYPE (suspend);


I think:
if (tree fndec = get_callee_fndecl_nofold (suspend))
   susp_type = TREE_TYPE (TREE_TYPE (fndecl));
else
   susp_type = TREE_TYPE (suspend);
would do?  But how can TREE_TYPE (suspend) be different from the return  
type of the function decl?  It seems funky that the behaviour could  
depend on the form of the suspend. What am I missing?

Your proposed change is much neater, thanks.
The reason for the alternate is that the expression can also be a  
target_expr.


That's not clarifying it for me.  Why is a CALL_EXPR's type different to  
they return type of the function being called?  And why in that case do  
you want the former, not the latter?


it isn’t (and therefore I don’t), and the type of the call expr is fine viz:

tree susp_type = TREE_TYPE (suspend);

(changed locally)
Iain

rs6000: Update bswap64-4 test to reflect actual results

[will schmidt via Gcc-patches]

rs6000: Update bswap64-4 test to reflect actual results

Hi,
  Update existing testcase powerpc/bswap64-4.c to
reflect that we generate ldbrx and stdbrx instructions
for newer cpu targets.  This is in contrast to the 
pair of lwbrx and stwbrx instructions that are
generated with older cpu targets.

OK for mainline? 
Thanks,
-Will


2020-03-24  Will Schmidt  

testsuite/
* gcc.target/powerpc/bswap64-4.c: Update scan-assembler
expected results.


diff --git a/gcc/testsuite/gcc.target/powerpc/bswap64-4.c 
b/gcc/testsuite/gcc.target/powerpc/bswap64-4.c
index 1f5ac0e..a3c0553 100644
--- a/gcc/testsuite/gcc.target/powerpc/bswap64-4.c
+++ b/gcc/testsuite/gcc.target/powerpc/bswap64-4.c
@@ -1,10 +1,12 @@
 /* { dg-do compile { target { powerpc*-*-* } } } */
 /* { dg-skip-if "" { powerpc*-*-aix* } } */
 /* { dg-options "-O2 -mpowerpc64" } */
 /* { dg-require-effective-target ilp32 } */
-/* { dg-final { scan-assembler-times "lwbrx" 2 } } */
-/* { dg-final { scan-assembler-times "stwbrx" 2 } } */
+/* { dg-final { scan-assembler-times "lwbrx" 2 { target { ! has_arch_pwr7 } } 
} } */
+/* { dg-final { scan-assembler-times "stwbrx" 2 { target { ! has_arch_pwr7 } } 
} } */
+/* { dg-final { scan-assembler-times "ldbrx" 1 { target has_arch_pwr7 } } } */
+/* { dg-final { scan-assembler-times "stdbrx" 1 { target has_arch_pwr7 } } } */
 
 long long swap_load (long long *a) { return __builtin_bswap64 (*a); }
 long long swap_reg (long long a) { return __builtin_bswap64 (a); }
 void swap_store (long long *a, long long b) { *a = __builtin_bswap64 (b); }

Re: [PATCH] coroutines: Implement n4849 recommended symmetric transfer.

[Nathan Sidwell]

On 3/24/20 2:08 PM, Iain Sandoe wrote:

Hi Nathan,
Thanks for the review,
comments embedded and a new version attached.

@David, you added the CALL_EXPR_MUST_TAIL_CALL which I’ve made use of
here (but with an observation).  Perhaps you would be able to comment on whether
I’ve (ab-)used it correctly?

OK for master now?
thanks
Iain

Nathan Sidwell  wrote:


On 3/20/20 11:40 AM, Iain Sandoe via Gcc-patches wrote:




tree suspend = TREE_VEC_ELT (awaiter_calls, 1); /* await_suspend().  */
+  tree susp_type;
+  if (TREE_CODE (suspend) == CALL_EXPR)
+{
+  susp_type = CALL_EXPR_FN (suspend);
+  if (TREE_CODE (susp_type) == ADDR_EXPR)
+   susp_type = TREE_OPERAND (susp_type, 0);
+  susp_type = TREE_TYPE (TREE_TYPE (susp_type));
+}
+  else
+susp_type = TREE_TYPE (suspend);


I think:
if (tree fndec = get_callee_fndecl_nofold (suspend))
susp_type = TREE_TYPE (TREE_TYPE (fndecl));
else
susp_type = TREE_TYPE (suspend);
would do?  But how can TREE_TYPE (suspend) be different from the return type of 
the function decl?  It seems funky that the behaviour could depend on the form 
of the suspend.  What am I missing?


Your proposed change is much neater, thanks.
The reason for the alternate is that the expression can also be a target_expr.


That's not clarifying it for me.  Why is a CALL_EXPR's type different to 
they return type of the function being called?  And why in that case do 
you want the former, not the latter?


nathan

--
Nathan Sidwell

Re: [PATCH] coroutines: Implement n4849 recommended symmetric transfer.

[Iain Sandoe]

Hi Nathan,
Thanks for the review,
comments embedded and a new version attached.

@David, you added the CALL_EXPR_MUST_TAIL_CALL which I’ve made use of
here (but with an observation).  Perhaps you would be able to comment on whether
I’ve (ab-)used it correctly?

OK for master now?
thanks
Iain

Nathan Sidwell  wrote:

> On 3/20/20 11:40 AM, Iain Sandoe via Gcc-patches wrote:
> 

>>tree suspend = TREE_VEC_ELT (awaiter_calls, 1); /* await_suspend().  */
>> +  tree susp_type;
>> +  if (TREE_CODE (suspend) == CALL_EXPR)
>> +{
>> +  susp_type = CALL_EXPR_FN (suspend);
>> +  if (TREE_CODE (susp_type) == ADDR_EXPR)
>> +susp_type = TREE_OPERAND (susp_type, 0);
>> +  susp_type = TREE_TYPE (TREE_TYPE (susp_type));
>> +}
>> +  else
>> +susp_type = TREE_TYPE (suspend);
> 
> I think:
> if (tree fndec = get_callee_fndecl_nofold (suspend))
>susp_type = TREE_TYPE (TREE_TYPE (fndecl));
> else
>susp_type = TREE_TYPE (suspend);
> would do?  But how can TREE_TYPE (suspend) be different from the return type 
> of the function decl?  It seems funky that the behaviour could depend on the 
> form of the suspend.  What am I missing?

Your proposed change is much neater, thanks.
The reason for the alternate is that the expression can also be a target_expr.

>> @@ -1532,6 +1553,8 @@ co_await_expander (tree *stmt, int * /*do_subtree*/, 
>> void *d)
>>  = build1 (ADDR_EXPR, build_reference_type (void_type_node), 
>> resume_label);
>>tree susp
>>  = build1 (ADDR_EXPR, build_reference_type (void_type_node), 
>> data->cororet);
>> +  tree cont
>> += build1 (ADDR_EXPR, build_reference_type (void_type_node), 
>> data->corocont);
>>tree final_susp = build_int_cst (integer_type_node, is_final ? 1 : 0);
> 
> Wait, 'void &' is not a thing.  What's been happening here?  do you mean to 
> build pointer_types?  'build_address (data->$FIELD)’
yes, fixed.

>> @@ -2012,6 +2027,15 @@ build_actor_fn (location_t loc, tree coro_frame_type, 
>> tree actor, tree fnbody,
>>  = create_named_label_with_ctx (loc, "actor.begin", actor);
>>tree actor_frame = build1_loc (loc, INDIRECT_REF, coro_frame_type, 
>> actor_fp);
>>  +  /* Init the continuation with a NULL ptr.  */
>> +  tree zeroinit = build1 (CONVERT_EXPR, void_coro_handle_type,
>> +  integer_zero_node);
>> +  tree ci = build2 (INIT_EXPR, void_coro_handle_type, continuation, 
>> zeroinit);
>> +  ci = build_stmt (loc, DECL_EXPR, continuation);
> 
> This appears to be overwriting ci?

thanks, my carelessness :( .. I failed to delete all the code from an earlier 
version.
fixed.

>> +  /* Now we have the actual call, and we can mark it as a tail.  */
>> +  CALL_EXPR_TAILCALL (resume) = true;
>> +  /* ... and for optimisation levels 0..1, mark it as requiring a tail-call
>> + for correctness.  It seems that doing this for optimisation levels that
>> + normally perform tail-calling, confuses the ME (or it would be logical
>> + to put this on unilaterally).  */
> 
> Might be worth ping a ME expert about why that is?

David, any comments here?
(confuses == ICE in expand, with an unexpected dead edge, IIRC).

>> +  if (optimize < 2)
>> +CALL_EXPR_MUST_TAIL_CALL (resume) = true;
>> +  resume = coro_build_cvt_void_expr_stmt (resume, loc);
>> +  add_stmt (resume);
>> +
>> +  r = build_stmt (loc, RETURN_EXPR, NULL);
>> +  r = maybe_cleanup_point_expr_void (r);
> 
> Shouldn't there be no cleanups?  Perhaps assert it didn't add any?
no, you’re right, that call’s  a waste of time - hoist with the C petard 
again.
removed (and I’d like to do a trivial follow-up to remove two more instances).

==

amended patch:

coroutines: Implement n4849 recommended symmetric transfer.

Although the note in the text [expr.await] / 5.1.1 is not normative,
it is asserted by users that an implementation that is unable to
perform unlimited symmetric transfers is not terribly useful.

This relates to the following circumstance:

try {
 users-function-body:
 {

{ some suspend context
  continuation_handle = await_suspend (another handle);
  continuation_handle.resume ();
  'return' (actually a suspension operation).
}
  }
} catch (...) {}

The call to 'continuation_handle.resume ()' needs to be a tail-
call in order that an arbitrary number of coroutines can be handled
in this manner.  There are two issues with this:

1. That the user's function body is wrapped in a try/catch block and
one cannot tail-call from within those.

2. That GCC doesn't usually produce tail-calls when the optimisation
level is < O2.

After considerable discussion at WG21 meetings, it has been determined
that the intent is that the operation behaves as if the resume call is
executed in the context of the caller.

So, we can remap the fragment above like this:

{
  void_coroutine_handle continuation;

  try {
   users-function-body:
   {
  
  

Re: [PATCH][PPC64] [PR88877]

[kamlesh kumar via Gcc-patches]

Thanks Hans-Peter for reviewing.
Here is Formatted ChangeLog Entry.

2020-03-24  Kamlesh Kumar  

* rtl.h: Defined Tuple for bundling rtx, mode and unsignedness
(default as 0), Added Extra argument (unsignedp)
in emit_library_call and emit_library_call_value.
* except.c: Likewise.
* explow.c: Likewise.
* expmed.c: Likewise.
* expr.c: Likewise.
* optabs.c: Likewise.
* asan.c: Likewise.
* builtins.c: Likewise.
* calls.c: Likewise.
* cfgexpand.c: Likewise.
* config/aarch64/aarch64.c: Likewise.
* config/aarch64/aarch64.h: Likewise.
* config/aarch64/atomics.md: Likewise.
* config/alpha/alpha.c: Likewise.
* config/arc/arc.c: Likewise.
* config/arc/elf.h: Likewise.
* config/arc/linux.h: Likewise.
* config/arm/arm.c: Likewise.
* config/bfin/bfin.md: Likewise.
* config/c6x/c6x.c: Likewise.
* config/csky/csky.c: Likewise.
* config/frv/frv.c: Likewise.
* config/i386/i386-expand.c: Likewise.
* config/i386/i386.c: Likewise.
* config/ia64/ia64.c: Likewise.
* config/ia64/ia64.md: Likewise.
* config/m32r/m32r.c: Likewise.
* config/m68k/linux.h: Likewise.
* config/m68k/m68k.c: Likewise.
* config/microblaze/microblaze.c: Likewise.
* config/mips/mips.h: Likewise.
* config/mips/sdemtk.h: Likewise.
* config/nds32/nds32.h: Likewise.
* config/nios2/nios2.c: Likewise.
* config/or1k/or1k.c: Likewise.
* config/pa/pa.c: Likewise.
* config/pa/pa.md: Likewise.
* config/pru/pru.c: Likewise.
* config/riscv/riscv.h: Likewise.
* config/riscv/riscv.md: Likewise.
* config/rl78/rl78.c: Likewise.
* config/rs6000/rs6000-string.c: Likewise.
* config/rs6000/rs6000.c: Likewise.
* config/rs6000/rs6000.md: Likewise.
* config/rs6000/vsx.md: Likewise.
* config/sh/sh.c: Likewise.
* config/sparc/sparc.c: Likewise.
* config/tilegx/tilegx.c: Likewise.
* config/tilepro/tilepro.c: Likewise.
* config/visium/visium.c: Likewise.
* config/xtensa/xtensa.c: Likewise.
* testsuite/gcc.target/powerpc/pr88877.c: Newtest

./kamlesh


On Tue, Mar 24, 2020 at 10:54 PM Hans-Peter Nilsson  wrote:
>
>
> On Tue, 24 Mar 2020, Hans-Peter Nilsson wrote:
> > The new argument is default 0, so make use of that: do not patch
> > all those files where 0 is fine.
>
> Oops, I was tricked by the comment; it's not actually "default 0"
> in the C++ sense.  And you have an overloaded function with
> different numbers of parameters; I don't know if you can get
> away cheaper than all those files you patched.  Sorry for the
> noise in that part; the ChangeLog formatting comment still
> applies.
>
> brgds, H-P

Re: [PATCH v2] generate EH info for volatile asm statements (PR93981)

[J.W. Jagersma via Gcc-patches]

I was looking into this yesterday but I ran into some issues.
The first is that blindly converting each output to in+out breaks
cases where an input already overlaps with an output:

asm ("..." : "=r" (out) : "0" (in));

This could be worked around by scanning the input list and only
converting outputs which don't already have a matching input.  But then
you could run into cases like:

asm ("..." : "=r,m" (out) : "0,r" (in));

Which may be unlikely, but this is valid code.  Here you can never
determine during gimplification which alternative will eventually be
chosen.

The second problem is that it sets off -Wuninitialized warnings
everywhere.  Is there some way to determine in gimplify_asm_expr which
outputs have already been assigned to?


On 2020-03-19 18:06, Michael Matz wrote:
> Hello,
> 
> On Wed, 18 Mar 2020, J.W. Jagersma via Gcc-patches wrote:
> 
>>> Well, it's both: on the exception path the compiler has to assume that the 
>>> the value wasn't changed (so that former defines are regarded as dead) or 
>>> that it already has changed (so that the effects the throwing 
>>> "instruction" had on the result (if any) aren't lost).  The easiest for 
>>> this is to regard the result place as also being an input.
>>
>> The way I see it, there are two options: either you use the outputs
>> when an exception is thrown, or you don't.
> 
> Assuming by "use the outputs" you mean "transform them implicitely to 
> in-out operands", not "the source code uses the output operands after the 
> asm on except and no-except paths".
> 
>> The first option is more or less what my first patch did, but it was
>> incomplete.  Changing each output to in+out would make that work
>> correctly.
> 
> Right.
> 
>> The second is what I have implemented now, each output is assigned via
>> a temporary which is then assigned back to the variable bound to this
>> output.  On exception, this temporary is discarded.  However this is
>> not possible for asms that write directly to memory, so those cases are
>> treated like option #1.
> 
> Right again, somewhat.  Except that the determination of which outputs are 
> going into memory is a fuzzy notion until reload/LRA (which is very late 
> in the compile pipeline).  You can infer some things from the constraint 
> letters, but gimple might still put things into memory (e.g. when the 
> output place is address taken), even though the constraint only allows a 
> register (in which case reloads will be generated), or place something 
> into a register, even though the constraint only allows memory (again, 
> reloads will be generated).

Re-reading this and giving it some more thought, I must reconsider what
I previously said.
>From looking at the constraints you should be able to tell which
operands *must* be in memory, and which *may* reside in a register.
This is the only distinction that matters.  Only the must-be-memory
cases get special treatment.  Everything else can be discarded on the
exception path, this includes "=rm" and such.

> Some of these reloads will be done early in the gimple pipeline to help 
> optimizations (they basically look like the insns that you generate for 
> copy-out), some of them will be generated only very late.
> 
>> I think the second option is easier on optimization since any previous
>> assignments can be removed from the normal code path, and registers
>> don't need to be loaded with known-valid values before the asm.
> 
> True (easier to optimizations) but immaterial (see below).
> 
>> The first option is more consistent since all outputs are treated the 
>> same, but more dangerous, as the asm may write incomplete values before 
>> throwing.
> 
> You have to assume that the author of the asm and its surrounding code is 
> written by a knowledgable person, so if the asm possibly writes partially 
> to outputs and then throws, then the output must not be accessed on the 
> exception path.  If the asm does not write partially, then the author can 
> access it.  So, what can or cannot be accessed on the exception path 
> really is an inherent property of the contents of the asm.
> 
> Now, your second case tries to create additional guarantees: it makes it 
> so that for some operands the user can depend on certain behaviour, namely 
> that the old value before the asm was entered is available on the except 
> path.  As you can't ensure this for all operands (those in memory are the 
> problem) you want to tighten the definition to only include the operands 
> where you can guarantee it, but this is fairly brittle, as above, because 
> some decisions are taken very late.
> 
> There's another case to consider: assume I'm writing an asm that writes 
> meaningful values to an output before and after a potential exception is 
> thrown, ala this:
> 
> asm (" mov %2, %0
>xyz %2, %1
>mov $0, %0" : "=r" (status), "+r" (a) : "r" (b));
> 
> Assume 'xyz' can fault depending on input.  The intention above would be 
> that on the exception path 

Re: [PATCH] issue -Walloca even when alloca is a system header macro [PR94004]

[Jeff Law via Gcc-patches]

On Mon, 2020-03-16 at 18:00 -0600, Martin Sebor wrote:
> PR middle-end/94004 - missing -Walloca on calls to alloca due to -Wno-system-
> headers
> 
> gcc/testsuite/ChangeLog:
> 
>   PR middle-end/94004
>   * gcc.dg/Walloca-larger-than-3.c: New test.
>   * gcc.dg/Walloca-larger-than-3.h: New test header.
>   * gcc.dg/Wvla-larger-than-4.c: New test.
> 
> gcc/ChangeLog:
> 
>   PR middle-end/94004
>   * gimple-ssa-warn-alloca.c (pass_walloca::execute): Issue warnings
>   even for alloca calls resulting from system macro expansion.
>   Include inlining context in all warnings.
OK
jeff

Re: [PATCH][PPC64] [PR88877]

[Hans-Peter Nilsson]

On Tue, 24 Mar 2020, Hans-Peter Nilsson wrote:
> The new argument is default 0, so make use of that: do not patch
> all those files where 0 is fine.

Oops, I was tricked by the comment; it's not actually "default 0"
in the C++ sense.  And you have an overloaded function with
different numbers of parameters; I don't know if you can get
away cheaper than all those files you patched.  Sorry for the
noise in that part; the ChangeLog formatting comment still
applies.

brgds, H-P

Re: [stage1] [PATCH] Make target_clones resolver fn static if possible.

[Jeff Law via Gcc-patches]

On Mon, 2020-03-23 at 16:09 +0100, Martin Liška wrote:
> From 1431a34f70128bdce59c94dad1d10f91673f63eb Mon Sep 17 00:00:00 2001
> From: Martin Liska 
> Date: Thu, 16 Jan 2020 10:38:41 +0100
> Subject: [PATCH] Make target_clones resolver fn static if possible.
> 
> gcc/ChangeLog:
> 
> 2020-03-17  Martin Liska  
> 
>   PR target/93274
>   PR ipa/94271
>   * config/i386/i386-features.c (make_resolver_func): Drop
>   public flag for resolver.
>   * config/rs6000/rs6000.c (make_resolver_func): Add comdat
>   group for resolver and drop public flag if possible.
>   * multiple_target.c (create_dispatcher_calls): Drop unique_name
>   and resolution as we want to enable LTO privatization of the default
>   symbol.
OK
jeff

Re: [PATCH] Fix handling of --with{,out}-zstd option.

[Jeff Law via Gcc-patches]

On Tue, 2020-03-24 at 07:34 +0100, Martin Liška wrote:
> Hi.
> 
> The patch respects --without-zstd and reports
> an error when we can't find header file with --with-zstd.
> 
> Ready to be installed?
> Thanks,
> Martin
> 
> gcc/ChangeLog:
> 
> 2020-03-23  Martin Liska  
> 
>   PR lto/94259
>   * configure.ac: Respect --without-zstd and report
>   error when we can't find header file with --with-zstd.
>   * configure: Regenerate.
OK
jeff
> 

[committed][hppa] Define builtin __BIG_ENDIAN__

[John David Anglin]

Although Martin provided stronger fix, this fixes lto/94249 on hppa-linux.  It 
seems we
never defined __BIG_ENDIAN__.  Probably, a few packages test for it.

Tested on hppa-unknown-linux-gnu.  Committed to trunk, gcc-9 and gcc-8.

Dave

2020-03-24  John David Anglin  

PR lto/94249
* config/pa/pa.h (TARGET_CPU_CPP_BUILTINS): Define __BIG_ENDIAN__.

diff --git a/gcc/config/pa/pa.h b/gcc/config/pa/pa.h
index 8800191a9a8..b3eb81d7b37 100644
--- a/gcc/config/pa/pa.h
+++ b/gcc/config/pa/pa.h
@@ -171,6 +171,7 @@ do {
\
  builtin_assert("machine=hppa");   \
  builtin_define("__hppa"); \
  builtin_define("__hppa__");   \
+ builtin_define("__BIG_ENDIAN__"); \
  if (TARGET_PA_20) \
builtin_define("_PA_RISC2_0");  \
  else if (TARGET_PA_11)\

Re: [PATCH][PPC64] [PR88877]

[Hans-Peter Nilsson]

Please excuse some cheap points:

On Mon, 23 Mar 2020, kamlesh kumar via Gcc-patches wrote:

> Attached patch fixes.
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88877.
> ChangeLog Entry.
>
> 2020-03-23  Kamlesh Kumar  
>
> * rtl.h : Defined Tuple for bundling rtx, mode and
> unsignedness default as 0
> Added Extra argument (unsignedp) in emit_library_call and
> emit_library_call_value.

Formatting issue: "." ends sentences, but you should not
terminate the line.  No space before ":".  See other entries.

> * except.c : Likewise.
> * explow.c : Likewise.
> * expmed.c : Likewise.
> * expr.c : Likewise.
> * optabs.c : Likewise.
> * asan.c : Likewise.
> * builtins.c : Likewise.
> * calls.c : Likewise.
> * cfgexpand.c : Likewise.
> * config/aarch64/aarch64.c : Likewise.
> * config/aarch64/aarch64.h : Likewise.
> * config/aarch64/atomics.md : Likewise.
> * config/alpha/alpha.c : Likewise.
> * config/arc/arc.c : Likewise.

...

The new argument is default 0, so make use of that: do not patch
all those files where 0 is fine.

brgds, H-P

Re: [PATCH v4] c++: DR1710, template keyword in a typename-specifier [PR94057]

[Marek Polacek via Gcc-patches]

On Mon, Mar 23, 2020 at 10:41:28AM -0400, Jason Merrill wrote:
> On 3/20/20 7:02 PM, Marek Polacek wrote:
> > On Fri, Mar 20, 2020 at 02:12:49PM -0400, Jason Merrill wrote:
> > > On 3/20/20 1:06 PM, Marek Polacek wrote:
> > > > Wonderful.  I've added a bunch of tests, and some from the related DRs 
> > > > too.
> > > > But I had a problem with the class-or-decltype case: if we have
> > > > 
> > > > template struct D : T::template B::template C {};
> > > > 
> > > > then we still require all the 'template' keywords here (as does clang). 
> > > >  So I'm
> > > > kind of confused, but I don't think it's a big deal right now.
> > > 
> > > This seems related enough that I'd like to fix it at the same time; why
> > > doesn't your patch fix it?  Is it because typename_p is false?
> > 
> > Ah, I was mistaken.  Of course we need the template keyword here: it's a 
> > member of an
> > unknown specialization!
> 
> That's why it's needed in contexts where we don't know whether or not we're
> naming a type.  But where we do know that, as in a base-specifier, it isn't
> necessary.  This is exactly DR 1710: "The keyword template is optional in a
> ... class-or-decltype (Clause 11.7 [class.derived])"

Duh, not sure what I was thinking.

I've implemented that in cp_parser_nested_name_specifier_opt: assume 'template'
if we've seen 'typename'.  If it turns out that this is wrong because it
triggers in contexts where it shouldn't, we'll have to introduce something like
CP_PARSER_FLAGS_TEMPLATE_OPTIONAL.

With this another problem revealed: we weren't accepting an alias template
after 'template' which DR1710 says is valid.  Fixed by the TYPE_ALIAS_P hunk
in the new check_template_keyword_in_nested_name_spec. (alias-decl1.C)

But this is still not over: I noticed that 

template  struct S {
  template 
  using U = TT;
};
template  typename S::template U::type foo;

is still rejected and shouldn't be.  Here 
check_template_keyword_in_nested_name_spec
gets 

 >

Any suggestions how to handle this?

FWIW, bootstrapped/regtested on x86_64-linux.

-- >8 --
Consider

  template  class A {
template  class B {
  void fn(typename A::B);
};
  };

which is rejected with
error: 'typename A::B' names 'template template class 
A::B', which is not a type
whereas clang/icc/msvc accept it.

"typename A::B" is a typename-specifier.  Sadly, our comments
don't mention it anywhere, because the typename-specifier wasn't in C++11;
it was only added to the language in N1376.  Instead, we handle it as
an elaborated-type-specifier (not a problem thus far).   So we get to
cp_parser_nested_name_specifier_opt which has a loop that breaks if we
don't see a < or ::, but that means we can -- tentatively -- parse even
B which is not a nested-name-specifier (it doesn't end with a ::).

Even though we're parsing B tentatively, we issue an error in
cp_parser_class_name -> make_typename_type, but here we should not.  In
fact, we probably shouldn't have parsed "B" at all.  Fixed by the
cp_parser_class_name hunk.

I think this should compile because [temp.names]/4 says: "In a qualified-id
used as the name in a typename-specifier, elaborated-type-specifier,
using-declaration, or class-or-decltype, an optional keyword template
appearing at the top level is ignored.", added in DR 1710.  Also see
DR 1812.

This issue on its own is not a significant problem or a regression.
However, in C++20, the typename here becomes optional, and so this test
is rejected in C++20, but accepted in C++17:

  template  class A {
template  class B {
  void fn(A::B);
};
  };

Here we morph A::B into a typename-specifier, but that happens
in cp_parser_simple_type_specifier and we never handle it as above.
To fake the template keyword I'm afraid we need to use cp_parser_template_id
with template_keyword_p=true as in the patch below.  The tricky thing
is to avoid breaking concepts.

To handle DR 1710, I made cp_parser_nested_name_specifier_opt assume that
when we're naming a type, the template keyword is present, too.  That
revealed a bug: DR 1710 also says that the template keyword can be followed
by an alias template, but we weren't prepared to handle that.  alias-decl1.C
exercise this.

DR 1710
PR c++/94057 - template keyword in a typename-specifier.
* parser.c (check_template_keyword_in_nested_name_spec): New.
(cp_parser_nested_name_specifier_opt): Implement DR1710, optional
'template'.  Call check_template_keyword_in_nested_name_spec.
(cp_parser_simple_type_specifier): Assume that a <
following a qualified-id in a typename-specifier begins
a template argument list.
(cp_parser_class_name): Complain only if not parsing tentatively.

* g++.dg/cpp1y/alias-decl1.C: New test.
* g++.dg/parse/missing-template1.C: Update dg-error.
* g++.dg/parse/template3.C: Likewise.
* g++.dg/template/error4.C: Likewise.
* g++.dg/template/meminit2.C: Likewise.
* 

New Ukrainian PO file for 'gcc' (version 10.1-b20200322)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

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

https://translationproject.org/latest/gcc/uk.po

(This file, 'gcc-10.1-b20200322.uk.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

https://translationproject.org/latest/gcc/

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

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

The following HTML page has been updated:

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

If any question arises, please contact the translation coordinator.

Thank you for all your work,

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

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

[Segher Boessenkool]

On Tue, Mar 24, 2020 at 06:30:12AM +, Yangfei (Felix) wrote:
> I modified combine emitting a simple AND operation instead of making one 
> zero_extract for this scenario.  
> Attached please find the new patch.  Hope this solves both of our concerns.  

This looks promising.  I'll try it out, see what it does on other
targets.  (It will have to wait for GCC 11 stage 1, of course).

Thanks!


Segher


p.s.  Please use a correct mime type?  application/octet-stream isn't
something I can reply to.  Just text/plain is fine :-)

RE: [PATCH 1/3] [testsuite, arm] target-supports.exp: Add arm_fp_dp_ok effective-target

[Kyrylo Tkachov]

Hi Christophe,

> -Original Message-
> From: Gcc-patches  On Behalf Of
> Christophe Lyon via Gcc-patches
> Sent: 24 March 2020 14:27
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH 1/3] [testsuite, arm] target-supports.exp: Add
> arm_fp_dp_ok effective-target
> 
> Some tests require double-precision support, but the existing arm_fp_ok
> effective-target only checks if hardware floating-point is available, not what
> level. So this patch adds a new arm_fp_dp_ok effective-target to check that
> double-precision is supported.

The series looks good to me, and I trust that you test a wide a matrix of 
configurations.
So ok for all three.
Thanks,
Kyrill

> 
> 2020-03-24  Christophe Lyon  
> 
>   gcc/
>   * doc/sourcebuild.texi (ARM-specific attributes): Add
>   arm_fp_dp_ok.
>   (Features for dg-add-options): Add arm_fp_dp.
> 
>   gcc/testsuite/
>   * lib/target-supports.exp
>   (check_effective_target_arm_fp_dp_ok_nocache): New.
>   (check_effective_target_arm_fp_dp_ok): New.
>   (add_options_for_arm_fp_dp): New.
> ---
>  gcc/doc/sourcebuild.texi  | 11 +
>  gcc/testsuite/lib/target-supports.exp | 44
> +++
>  2 files changed, 55 insertions(+)
> 
> diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi index
> eef1432..91b46cc 100644
> --- a/gcc/doc/sourcebuild.texi
> +++ b/gcc/doc/sourcebuild.texi
> @@ -1733,6 +1733,12 @@ ARM target defines @code{__ARM_FP} using
> @code{-mfloat-abi=softfp} or  equivalent options.  Some multilibs may be
> incompatible with these  options.
> 
> +@item arm_fp_dp_ok
> +@anchor{arm_fp_dp_ok}
> +ARM target defines @code{__ARM_FP} with double-precision support using
> +@code{-mfloat-abi=softfp} or equivalent options.  Some multilibs may be
> +incompatible with these options.
> +
>  @item arm_hf_eabi
>  ARM target adheres to the VFP and Advanced SIMD Register Arguments
> variant of the ABI for the ARM Architecture (as selected with @@ -2504,6
> +2510,11 @@ are:
>  in certain modes; see the @ref{arm_fp_ok,,arm_fp_ok effective target
> keyword}.
> 
> +@item arm_fp_dp
> +@code{__ARM_FP} definition with double-precision support.  Only ARM
> +targets support this feature, and only then in certain modes; see the
> +@ref{arm_fp_dp_ok,,arm_fp_dp_ok effective target keyword}.
> +
>  @item arm_neon
>  NEON support.  Only ARM targets support this feature, and only then  in
> certain modes; see the @ref{arm_neon_ok,,arm_neon_ok effective target
> diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-
> supports.exp
> index 4413c26..332611c 100644
> --- a/gcc/testsuite/lib/target-supports.exp
> +++ b/gcc/testsuite/lib/target-supports.exp
> @@ -3679,6 +3679,50 @@ proc add_options_for_arm_fp { flags } {
>  return "$flags $et_arm_fp_flags"
>  }
> 
> +# Return 1 if this is an ARM target defining __ARM_FP with #
> +double-precision support. We may need -mfloat-abi=softfp or #
> +equivalent options.  Some multilibs may be incompatible with these #
> +options.  Also set et_arm_fp_dp_flags to the best options to add.
> +
> +proc check_effective_target_arm_fp_dp_ok_nocache { } {
> +global et_arm_fp_dp_flags
> +set et_arm_fp_dp_flags ""
> +if { [check_effective_target_arm32] } {
> + foreach flags {"" "-mfloat-abi=softfp" "-mfloat-abi=hard"} {
> + if { [check_no_compiler_messages_nocache arm_fp_dp_ok object {
> + #ifndef __ARM_FP
> + #error __ARM_FP not defined
> + #endif
> + #if ((__ARM_FP & 8) == 0)
> + #error __ARM_FP indicates that double-precision is not
> supported
> + #endif
> + } "$flags"] } {
> + set et_arm_fp_dp_flags $flags
> + return 1
> + }
> + }
> +}
> +
> +return 0
> +}
> +
> +proc check_effective_target_arm_fp_dp_ok { } {
> +return [check_cached_effective_target arm_fp_dp_ok \
> + check_effective_target_arm_fp_dp_ok_nocache]
> +}
> +
> +# Add the options needed to define __ARM_FP with double-precision #
> +support.  We need either -mfloat-abi=softfp or -mfloat-abi=hard, but #
> +if one is already specified by the multilib, use it.
> +
> +proc add_options_for_arm_fp_dp { flags } {
> +if { ! [check_effective_target_arm_fp_dp_ok] } {
> + return "$flags"
> +}
> +global et_arm_fp_dp_flags
> +return "$flags $et_arm_fp_dp_flags"
> +}
> +
>  # Return 1 if this is an ARM target that supports DSP multiply with  # 
> current
> multilib flags.
> 
> --
> 2.7.4

[PATCH 2/3] [testsuite, arm] cmp-2.c: Move double-precision tests to cmp-3.c

[Christophe Lyon via Gcc-patches]

Parts of the cmp-2.c test rely on double-precision support, making the
test fail on targets where the FPU supports single-precision only.

Split the test into single-precision (cmp-2.c) and double-precision
tests (cmp-3.c).

2020-03-24  Christophe Lyon  

gcc/testsuite/
* gcc.target/arm/cmp-2.c: Move double-precision tests to...
* gcc.target/arm/cmp-3.c: ...here (new file)
---
 gcc/testsuite/gcc.target/arm/cmp-2.c |  4 +--
 gcc/testsuite/gcc.target/arm/cmp-3.c | 49 
 2 files changed, 50 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/arm/cmp-3.c

diff --git a/gcc/testsuite/gcc.target/arm/cmp-2.c 
b/gcc/testsuite/gcc.target/arm/cmp-2.c
index 70e4509..c61487d 100644
--- a/gcc/testsuite/gcc.target/arm/cmp-2.c
+++ b/gcc/testsuite/gcc.target/arm/cmp-2.c
@@ -30,9 +30,7 @@ int x, y;
   TEST_EXPR (NAME##_cr, (TYPE a1), OPERATOR (100, a1))
 
 #define TEST_OP(NAME, OPERATOR) \
-  TEST (f_##NAME, float, OPERATOR) \
-  TEST (d_##NAME, double, OPERATOR)\
-  TEST (ld_##NAME, long double, OPERATOR)
+  TEST (f_##NAME, float, OPERATOR)
 
 TEST_OP (eq, EQ)
 TEST_OP (ne, NE)
diff --git a/gcc/testsuite/gcc.target/arm/cmp-3.c 
b/gcc/testsuite/gcc.target/arm/cmp-3.c
new file mode 100644
index 000..70a1168
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/cmp-3.c
@@ -0,0 +1,49 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target arm_fp_dp_ok } */
+/* { dg-skip-if "need fp instructions" { *-*-* } { "-mfloat-abi=soft" } { "" } 
} */
+/* { dg-options "-O" } */
+/* { dg-add-options arm_fp_dp } */
+/* { dg-final { scan-assembler-not "\tbl\t" } } */
+/* { dg-final { scan-assembler-not "__aeabi" } } */
+int x, y;
+
+#define EQ(X, Y) ((X) == (Y))
+#define NE(X, Y) ((X) != (Y))
+#define LT(X, Y) ((X) < (Y))
+#define GT(X, Y) ((X) > (Y))
+#define LE(X, Y) ((X) <= (Y))
+#define GE(X, Y) ((X) >= (Y))
+
+#define TEST_EXPR(NAME, ARGS, EXPR)\
+  int NAME##1 ARGS { return (EXPR); }  \
+  int NAME##2 ARGS { return !(EXPR); } \
+  int NAME##3 ARGS { return (EXPR) ? x : y; }  \
+  void NAME##4 ARGS { if (EXPR) x++; } \
+  void NAME##5 ARGS { if (!(EXPR)) x++; }
+
+#define TEST(NAME, TYPE, OPERATOR) \
+  TEST_EXPR (NAME##_rr, (TYPE a1, TYPE a2), OPERATOR (a1, a2)) \
+  TEST_EXPR (NAME##_rm, (TYPE a1, TYPE *a2), OPERATOR (a1, *a2))   \
+  TEST_EXPR (NAME##_mr, (TYPE *a1, TYPE a2), OPERATOR (*a1, a2))   \
+  TEST_EXPR (NAME##_mm, (TYPE *a1, TYPE *a2), OPERATOR (*a1, *a2)) \
+  TEST_EXPR (NAME##_rc, (TYPE a1), OPERATOR (a1, 100)) \
+  TEST_EXPR (NAME##_cr, (TYPE a1), OPERATOR (100, a1))
+
+#define TEST_OP(NAME, OPERATOR) \
+  TEST (d_##NAME, double, OPERATOR)\
+  TEST (ld_##NAME, long double, OPERATOR)
+
+TEST_OP (eq, EQ)
+TEST_OP (ne, NE)
+TEST_OP (lt, LT)
+TEST_OP (gt, GT)
+TEST_OP (le, LE)
+TEST_OP (ge, GE)
+TEST_OP (blt, __builtin_isless)
+TEST_OP (bgt, __builtin_isgreater)
+TEST_OP (ble, __builtin_islessequal)
+TEST_OP (bge, __builtin_isgreaterequal)
+/* This one should be expanded into separate ordered and equality
+   comparisons.  */
+TEST_OP (blg, __builtin_islessgreater)
+TEST_OP (bun, __builtin_isunordered)
-- 
2.7.4

[PATCH 1/3] [testsuite, arm] target-supports.exp: Add arm_fp_dp_ok effective-target

[Christophe Lyon via Gcc-patches]

Some tests require double-precision support, but the existing
arm_fp_ok effective-target only checks if hardware floating-point is
available, not what level. So this patch adds a new arm_fp_dp_ok
effective-target to check that double-precision is supported.

2020-03-24  Christophe Lyon  

gcc/
* doc/sourcebuild.texi (ARM-specific attributes): Add
arm_fp_dp_ok.
(Features for dg-add-options): Add arm_fp_dp.

gcc/testsuite/
* lib/target-supports.exp
(check_effective_target_arm_fp_dp_ok_nocache): New.
(check_effective_target_arm_fp_dp_ok): New.
(add_options_for_arm_fp_dp): New.
---
 gcc/doc/sourcebuild.texi  | 11 +
 gcc/testsuite/lib/target-supports.exp | 44 +++
 2 files changed, 55 insertions(+)

diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
index eef1432..91b46cc 100644
--- a/gcc/doc/sourcebuild.texi
+++ b/gcc/doc/sourcebuild.texi
@@ -1733,6 +1733,12 @@ ARM target defines @code{__ARM_FP} using 
@code{-mfloat-abi=softfp} or
 equivalent options.  Some multilibs may be incompatible with these
 options.
 
+@item arm_fp_dp_ok
+@anchor{arm_fp_dp_ok}
+ARM target defines @code{__ARM_FP} with double-precision support using
+@code{-mfloat-abi=softfp} or equivalent options.  Some multilibs may
+be incompatible with these options.
+
 @item arm_hf_eabi
 ARM target adheres to the VFP and Advanced SIMD Register Arguments
 variant of the ABI for the ARM Architecture (as selected with
@@ -2504,6 +2510,11 @@ are:
 in certain modes; see the @ref{arm_fp_ok,,arm_fp_ok effective target
 keyword}.
 
+@item arm_fp_dp
+@code{__ARM_FP} definition with double-precision support.  Only ARM
+targets support this feature, and only then in certain modes; see the
+@ref{arm_fp_dp_ok,,arm_fp_dp_ok effective target keyword}.
+
 @item arm_neon
 NEON support.  Only ARM targets support this feature, and only then
 in certain modes; see the @ref{arm_neon_ok,,arm_neon_ok effective target
diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index 4413c26..332611c 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -3679,6 +3679,50 @@ proc add_options_for_arm_fp { flags } {
 return "$flags $et_arm_fp_flags"
 }
 
+# Return 1 if this is an ARM target defining __ARM_FP with
+# double-precision support. We may need -mfloat-abi=softfp or
+# equivalent options.  Some multilibs may be incompatible with these
+# options.  Also set et_arm_fp_dp_flags to the best options to add.
+
+proc check_effective_target_arm_fp_dp_ok_nocache { } {
+global et_arm_fp_dp_flags
+set et_arm_fp_dp_flags ""
+if { [check_effective_target_arm32] } {
+   foreach flags {"" "-mfloat-abi=softfp" "-mfloat-abi=hard"} {
+   if { [check_no_compiler_messages_nocache arm_fp_dp_ok object {
+   #ifndef __ARM_FP
+   #error __ARM_FP not defined
+   #endif
+   #if ((__ARM_FP & 8) == 0)
+   #error __ARM_FP indicates that double-precision is not supported
+   #endif
+   } "$flags"] } {
+   set et_arm_fp_dp_flags $flags
+   return 1
+   }
+   }
+}
+
+return 0
+}
+
+proc check_effective_target_arm_fp_dp_ok { } {
+return [check_cached_effective_target arm_fp_dp_ok \
+   check_effective_target_arm_fp_dp_ok_nocache]
+}
+
+# Add the options needed to define __ARM_FP with double-precision
+# support.  We need either -mfloat-abi=softfp or -mfloat-abi=hard, but
+# if one is already specified by the multilib, use it.
+
+proc add_options_for_arm_fp_dp { flags } {
+if { ! [check_effective_target_arm_fp_dp_ok] } {
+   return "$flags"
+}
+global et_arm_fp_dp_flags
+return "$flags $et_arm_fp_dp_flags"
+}
+
 # Return 1 if this is an ARM target that supports DSP multiply with
 # current multilib flags.
 
-- 
2.7.4

[PATCH 3/3] [testsuite,arm] use arm_fp_dp_ok effective-target

[Christophe Lyon via Gcc-patches]

Switch to arm_fp_dp_ok effective-target in tests that require
double-precision support from the FPU.

2020-03-24  Christophe Lyon  

gcc/testsuite/
* gcc/arm/vfp-1.c: Use arm_fp__ok effective-target.
* gcc.target/arm/vfp-ldmdbd.c: Likewise.
* gcc.target/arm/vfp-ldmiad.c: Likewise.
* gcc.target/arm/vfp-stmdbd.c: Likewise.
* gcc.target/arm/vfp-stmiad.c: Likewise.
* gcc.target/arm/vnmul-1.c: Likewise.
* gcc.target/arm/vnmul-3.c: Likewise.
* gcc.target/arm/vnmul-4.c: Likewise.
---
 gcc/testsuite/gcc.target/arm/vfp-1.c  | 4 ++--
 gcc/testsuite/gcc.target/arm/vfp-ldmdbd.c | 4 ++--
 gcc/testsuite/gcc.target/arm/vfp-ldmiad.c | 4 ++--
 gcc/testsuite/gcc.target/arm/vfp-stmdbd.c | 4 ++--
 gcc/testsuite/gcc.target/arm/vfp-stmiad.c | 4 ++--
 gcc/testsuite/gcc.target/arm/vnmul-1.c| 4 ++--
 gcc/testsuite/gcc.target/arm/vnmul-3.c| 4 ++--
 gcc/testsuite/gcc.target/arm/vnmul-4.c| 4 ++--
 8 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/gcc/testsuite/gcc.target/arm/vfp-1.c 
b/gcc/testsuite/gcc.target/arm/vfp-1.c
index 7add1b8..b4694c7 100644
--- a/gcc/testsuite/gcc.target/arm/vfp-1.c
+++ b/gcc/testsuite/gcc.target/arm/vfp-1.c
@@ -1,7 +1,7 @@
 /* { dg-do compile } */
-/* { dg-require-effective-target arm_fp_ok } */
+/* { dg-require-effective-target arm_fp_dp_ok } */
 /* { dg-options "-O2 -ffp-contract=off" } */
-/* { dg-add-options arm_fp } */
+/* { dg-add-options arm_fp_dp } */
 /* { dg-skip-if "need fp instructions" { *-*-* } { "-mfloat-abi=soft" } { "" } 
} */
 
 extern float fabsf (float);
diff --git a/gcc/testsuite/gcc.target/arm/vfp-ldmdbd.c 
b/gcc/testsuite/gcc.target/arm/vfp-ldmdbd.c
index 3489a2a..f66ed0f 100644
--- a/gcc/testsuite/gcc.target/arm/vfp-ldmdbd.c
+++ b/gcc/testsuite/gcc.target/arm/vfp-ldmdbd.c
@@ -1,8 +1,8 @@
 /* { dg-do compile } */
-/* { dg-require-effective-target arm_fp_ok } */
+/* { dg-require-effective-target arm_fp_dp_ok } */
 /* { dg-skip-if "need fp instructions" { *-*-* } { "-mfloat-abi=soft" } { "" } 
} */
 /* { dg-options "-O2" } */
-/* { dg-add-options arm_fp } */
+/* { dg-add-options arm_fp_dp } */
 
 extern void bar (double);
 
diff --git a/gcc/testsuite/gcc.target/arm/vfp-ldmiad.c 
b/gcc/testsuite/gcc.target/arm/vfp-ldmiad.c
index 422e3ed..471ba63 100644
--- a/gcc/testsuite/gcc.target/arm/vfp-ldmiad.c
+++ b/gcc/testsuite/gcc.target/arm/vfp-ldmiad.c
@@ -1,8 +1,8 @@
 /* { dg-do compile } */
-/* { dg-require-effective-target arm_fp_ok } */
+/* { dg-require-effective-target arm_fp_dp_ok } */
 /* { dg-skip-if "need fp instructions" { *-*-* } { "-mfloat-abi=soft" } { "" } 
} */
 /* { dg-options "-O2" } */
-/* { dg-add-options arm_fp } */
+/* { dg-add-options arm_fp_dp } */
 
 extern void bar (double);
 
diff --git a/gcc/testsuite/gcc.target/arm/vfp-stmdbd.c 
b/gcc/testsuite/gcc.target/arm/vfp-stmdbd.c
index 686fe86..3892d76 100644
--- a/gcc/testsuite/gcc.target/arm/vfp-stmdbd.c
+++ b/gcc/testsuite/gcc.target/arm/vfp-stmdbd.c
@@ -1,8 +1,8 @@
 /* { dg-do compile } */
-/* { dg-require-effective-target arm_fp_ok } */
+/* { dg-require-effective-target arm_fp_dp_ok } */
 /* { dg-skip-if "need fp instructions" { *-*-* } { "-mfloat-abi=soft" } { "" } 
} */
 /* { dg-options "-O2" } */
-/* { dg-add-options arm_fp } */
+/* { dg-add-options arm_fp_dp } */
 
 void
 foo (double *p, double a, double b, int n)
diff --git a/gcc/testsuite/gcc.target/arm/vfp-stmiad.c 
b/gcc/testsuite/gcc.target/arm/vfp-stmiad.c
index 665fa7a..ff53adc 100644
--- a/gcc/testsuite/gcc.target/arm/vfp-stmiad.c
+++ b/gcc/testsuite/gcc.target/arm/vfp-stmiad.c
@@ -1,8 +1,8 @@
 /* { dg-do compile } */
-/* { dg-require-effective-target arm_fp_ok } */
+/* { dg-require-effective-target arm_fp_dp_ok } */
 /* { dg-skip-if "need fp instructions" { *-*-* } { "-mfloat-abi=soft" } { "" } 
} */
 /* { dg-options "-O2" } */
-/* { dg-add-options arm_fp } */
+/* { dg-add-options arm_fp_dp } */
 
 void
 foo (double *p, double a, double b, int n)
diff --git a/gcc/testsuite/gcc.target/arm/vnmul-1.c 
b/gcc/testsuite/gcc.target/arm/vnmul-1.c
index fd00388..fdac5f3 100644
--- a/gcc/testsuite/gcc.target/arm/vnmul-1.c
+++ b/gcc/testsuite/gcc.target/arm/vnmul-1.c
@@ -1,8 +1,8 @@
 /* { dg-do compile } */
-/* { dg-require-effective-target arm_fp_ok } */
+/* { dg-require-effective-target arm_fp_dp_ok } */
 /* { dg-skip-if "need fp instructions" { *-*-* } { "-mfloat-abi=soft" } { "" } 
} */
 /* { dg-options "-O2 -fno-rounding-math" } */
-/* { dg-add-options arm_fp } */
+/* { dg-add-options arm_fp_dp } */
 
 double
 foo_d (double a, double b)
diff --git a/gcc/testsuite/gcc.target/arm/vnmul-3.c 
b/gcc/testsuite/gcc.target/arm/vnmul-3.c
index 44c1967..be13bbb 100644
--- a/gcc/testsuite/gcc.target/arm/vnmul-3.c
+++ b/gcc/testsuite/gcc.target/arm/vnmul-3.c
@@ -1,8 +1,8 @@
 /* { dg-do compile } */
-/* { dg-require-effective-target arm_fp_ok } */
+/* { dg-require-effective-target arm_fp_dp_ok } */
 /* { dg-skip-if "need fp instructions" { *-*-* } { "-mfloat-abi=soft" } 

Re: [PATCH] implement pre-c++20 contracts

[Andrew Sutton via Gcc-patches]

Hi Jason,

Sorry I haven't been able to get back to this. I've been swamped with
other work, and we haven't had the resources to properly address this.
Jeff Chapman will be working on cleaning this up for when master/trunk
re-opens.


> I find the proposed always_continue semantics kind of nonsensical, as
> somewhat evidenced by the contortions the implementation gets into with
> marking the violation handler as pure.  The trick of assigning the
> result to a local variable won't work with optimization.

We tend to agree and think it's practically non-implementable. IIRC,
later contracts proposals steered away from adding this as a concrete
semantic. I suspect killing this would be fine.

> > +/* Definitions for C++ contract levels
> > +   Copyright (C) 1987-2018 Free Software Foundation, Inc.
>
> Should just be 2019 for a new file.

Probably 2020 now :)

> > +   Contributed by Michael Tiemann (tiem...@cygnus.com)
>
> This seems inaccurate.  :)

Indeed :)


> This change to member function redeclaration seems undesirable; your
> rationale in P1680 is "for generality", but member functions are already
> stricter about redeclaration than non-member functions; I don't see a
> reason to relax this rule just for contracts.  With member functions,
> there *is* always a canonical first declaration, and people expect the
> class definition to have its complete interface, of which contracts are
> a part.

There was a proposal that gave more motivation than just "for
generality". Apparently, I was a co-author -- I think I just helped
write the wording.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1320r2.html


> For non-member functions, we still need to complain if contracts are
> added after we've seen an ODR-use of the function, just like with
> explicit specializations.

We could do that, but it doesn't seem necessary with this model.
Whether the contracts have been seen or not doesn't affect which
function is called.


> > +  /* TODO is there any way to relax this requirement?  */
> > +  if (DECL_VIRTUAL_P (olddecl) && !TYPE_BEING_DEFINED (DECL_CONTEXT 
> > (olddecl)))
>
> Relatedly, I don't think we want to relax this requirement.

Probably. Virtual functions and contracts have complex interactions.
There are going to be more EWG papers about this, I'm sure.


> > +  /* FIXME Is this right for friends? Can a friend refer to a static 
> > member?
> > + Can a friend's contracts refer to our privates? Turning them into
> > + [[assert]]s inside the body of the friend itself certainly lets them 
> > do
> > + so. */
>
> P0542 says contracts are limited to the accessibility of the function
> itself, so a friend cannot refer to private members.

That will almost certainly be changed. This was the proposal:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1289r0.pdf

There was near-unanimous support for removing that (19 for, 1 against).

Andrew

Re: [RFC] Should widening_mul should consider block frequency?

[Richard Biener via Gcc-patches]

On Tue, Mar 24, 2020 at 12:37 PM Yangfei (Felix)  wrote:
>
> Hi!
>
> > -Original Message-
> > From: Richard Biener [mailto:richard.guent...@gmail.com]
> > Sent: Monday, March 23, 2020 11:25 PM
> > To: Yangfei (Felix) 
> > Cc: gcc-patches@gcc.gnu.org
> > Subject: Re: [RFC] Should widening_mul should consider block frequency?
> >
> > On Mon, Mar 23, 2020 at 10:53 AM Yangfei (Felix) 
> > wrote:
> > >
> > > Hi,
> > >
> > >   I created a bug for this issue:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94269
> > >   Looks like widening_mul phase may move multiply instruction from outside
> > the loop to inside the loop, merging with one add instruction inside the 
> > loop.
> > >   This will increase the cost of the loop at least on aarch64 (4 cycles 
> > > vs 1
> > cycle).  I think widening_mul should consider block frequency when doing 
> > such
> > a combination.
> > >   I mean something like:
> >
> > As written in the PR I'd follow fma generation and restrict defs to the 
> > same BB.
>
> Thanks for the suggestion.  That should be more consistent.
> Attached please find the adapted patch.
> Bootstrap and tested on both x86_64 and aarch64 Linux platform.

OK with moving the BB check before the is_widening_mult_p call
since it's way cheaper.

Thanks,
Richard.

> gcc:
> +2020-03-24  Felix Yang  
> +
> +   PR tree-optimization/94269
> +   * tree-ssa-math-opts.c (convert_plusminus_to_widen): Restrict this
> +   operation to single basic block.
>
> gcc/testsuite:
> +2020-03-24  Felix Yang  
> +
> +   PR tree-optimization/94269
> +   * gcc.dg/pr94269.c: New test.
> +
>
> Thanks,
> Felix

Re: [PATCH] match.pd: recognize a signed rotate

[Richard Biener via Gcc-patches]

On Tue, Mar 24, 2020 at 10:45 AM Stefan Schulze Frielinghaus
 wrote:
>
> On Mon, Mar 23, 2020 at 04:44:56PM +0100, Richard Biener wrote:
> > On Mon, Mar 23, 2020 at 4:34 PM Jakub Jelinek  wrote:
> > >
> > > On Mon, Mar 23, 2020 at 04:29:12PM +0100, Richard Biener wrote:
> > > > I wonder if we can leverage the bswap pass for rotate detection
> > > > (see find_bswap_or_nop which matches the symbolic number
> > > > against either 1:1 or byte-swapped variants, to be added would be
> > > > rotate and shift patterns).
> > >
> > > That pass can only handle cases where the shift counts are multiple of
> > > BITS_PER_UNIT, the whole infrastructure is based on being able to track
> > > movements of bytes.
> >
> > That's true, but also an artifact of the symbolic number encoding.
>
> I'm pretty new to match.pd and in general to GCC.  Is there something
> which speaks against solving this in match.pd?  If so and the bswap pass
> is also not the right place, do you have something else in mind?

For match.pd the patterns tend to be unwieldly so currently this is
pattern-matched in tree-ssa-forwprop.c:simplify_rotate which is the
place I'd see to extend.

Richard.

Re: [Patch] Fix OpenMP offload handling for target-link variables for nvptx (PR81689)

[Jakub Jelinek via Gcc-patches]

On Tue, Mar 24, 2020 at 02:16:40PM +0100, Tobias Burnus wrote:
> For nvptx, targetm_common.have_named_sections, hence one is

You mean targetm_common.have_named_sections is false, right?

> in the else branch of omp_finish_file – and the else branch
> did not handle target-link variables.
> 
> With this patch, the libgomp.c/target-link-1.c testcase now works.
> 
> When looking at the nvptx "assembler", I saw that TREE_PUBLIC was
> set for 'b' (the 'omp declare target to'-variable) but not the
> target-link variables. (Not relevant for the failing test case.)
> 
> OK for the trunk?

Ok, thanks.

> Fix OpenMP offload handling for target-link variables for nvptx (PR81689)
> 
>   PR libgomp/81689
>   * lto.c (offload_handle_link_vars): Propagate TREE_PUBLIC state.
> 
>   PR libgomp/81689
>   * omp-offload.c (omp_finish_file): Fix target-link handling if
>   targetm_common.have_named_sections is false.
> 
>   PR libgomp/81689
>   * testsuite/libgomp.c/target-link-1.c: Remove xfail.

Jakub

[Patch] Fix OpenMP offload handling for target-link variables for nvptx (PR81689)

[Tobias Burnus]

For nvptx, targetm_common.have_named_sections, hence one is
in the else branch of omp_finish_file – and the else branch
did not handle target-link variables.

With this patch, the libgomp.c/target-link-1.c testcase now works.

When looking at the nvptx "assembler", I saw that TREE_PUBLIC was
set for 'b' (the 'omp declare target to'-variable) but not the
target-link variables. (Not relevant for the failing test case.)

OK for the trunk?

Tobias

-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter
Fix OpenMP offload handling for target-link variables for nvptx (PR81689)

	PR libgomp/81689
	* lto.c (offload_handle_link_vars): Propagate TREE_PUBLIC state.

	PR libgomp/81689
	* omp-offload.c (omp_finish_file): Fix target-link handling if
	targetm_common.have_named_sections is false.

	PR libgomp/81689
	* testsuite/libgomp.c/target-link-1.c: Remove xfail.

diff --git a/gcc/lto/lto.c b/gcc/lto/lto.c
index cd34d6c9e7a..1c37814bde4 100644
--- a/gcc/lto/lto.c
+++ b/gcc/lto/lto.c
@@ -566,6 +566,7 @@ offload_handle_link_vars (void)
 			 "linkptr"), type);
 	TREE_USED (link_ptr_var) = 1;
 	TREE_STATIC (link_ptr_var) = 1;
+	TREE_PUBLIC (link_ptr_var) = TREE_PUBLIC (var->decl);
 	DECL_ARTIFICIAL (link_ptr_var) = 1;
 	SET_DECL_ASSEMBLER_NAME (link_ptr_var, DECL_NAME (link_ptr_var));
 	SET_DECL_VALUE_EXPR (var->decl, build_simple_mem_ref (link_ptr_var));
diff --git a/gcc/omp-offload.c b/gcc/omp-offload.c
index 11412e1059f..c66f38b6f0c 100644
--- a/gcc/omp-offload.c
+++ b/gcc/omp-offload.c
@@ -220,7 +220,19 @@ omp_finish_file (void)
   for (unsigned i = 0; i < num_vars; i++)
 	{
 	  tree it = (*offload_vars)[i];
-	  targetm.record_offload_symbol (it);
+#ifdef ACCEL_COMPILER
+	  if (DECL_HAS_VALUE_EXPR_P (it)
+	  && lookup_attribute ("omp declare target link",
+   DECL_ATTRIBUTES (it)))
+	{
+	  tree value_expr = DECL_VALUE_EXPR (it);
+	  tree link_ptr_decl = TREE_OPERAND (value_expr, 0);
+	  targetm.record_offload_symbol (link_ptr_decl);
+	  varpool_node::finalize_decl (link_ptr_decl);
+	}
+	  else
+#endif
+	targetm.record_offload_symbol (it);
 	}
 }
 }
diff --git a/libgomp/testsuite/libgomp.c/target-link-1.c b/libgomp/testsuite/libgomp.c/target-link-1.c
index 99ce33bc9b4..681677cc2aa 100644
--- a/libgomp/testsuite/libgomp.c/target-link-1.c
+++ b/libgomp/testsuite/libgomp.c/target-link-1.c
@@ -1,6 +1,3 @@
-/* { dg-xfail-if "#pragma omp target link not implemented" { offload_target_nvptx } }
-   Cf. https://gcc.gnu.org/PR81689.  */
-
 struct S { int s, t; };
 
 int a = 1, b = 1;

Re: [PATCH] coroutines: Implement n4849 recommended symmetric transfer.

[Nathan Sidwell]

On 3/20/20 11:40 AM, Iain Sandoe via Gcc-patches wrote:


2020-03-20  Iain Sandoe  

* coroutines.cc (coro_init_identifiers): Initialize an identifier
for the cororoutine handle 'address' method name.
(struct coro_aw_data): Add fields to cover the continuations.
(co_await_expander): Determine the kind of await_suspend in use.
If we have the case that returns a continuation handle, then save
this and make the target for 'scope exit without cleanup' be the
continuation resume label.
(expand_co_awaits): Handle the continuation case.
(struct suspend_point_info): Remove fields that kept the returned
await_suspend handle type.
(transform_await_expr): Remove code tracking continuation handles.
(build_actor_fn): Add the continuation handle as an actor-function
scope var.  Build the symmetric transfer continuation point.
(register_await_info): Remove fields tracking continuation handles.
(get_await_suspend_return_type): Remove.
(register_awaits): Remove code tracking continuation handles.
(morph_fn_to_coro): Remove code tracking continuation handles.

gcc/testsuite/ChangeLog:

2020-03-20  Iain Sandoe  

* g++.dg/coroutines/torture/co-ret-09-bool-await-susp.C: Amend
to n4849 behaviour.
* g++.dg/coroutines/torture/symmetric-transfer-00-basic.C: New
test.


diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
index abd4cac1c82..49e03f2ccea 100644
--- a/gcc/cp/coroutines.cc
+++ b/gcc/cp/coroutines.cc



tree suspend = TREE_VEC_ELT (awaiter_calls, 1); /* await_suspend().  */
+  tree susp_type;
+  if (TREE_CODE (suspend) == CALL_EXPR)
+{
+  susp_type = CALL_EXPR_FN (suspend);
+  if (TREE_CODE (susp_type) == ADDR_EXPR)
+   susp_type = TREE_OPERAND (susp_type, 0);
+  susp_type = TREE_TYPE (TREE_TYPE (susp_type));
+}
+  else
+susp_type = TREE_TYPE (suspend);


I think:
 if (tree fndec = get_callee_fndecl_nofold (suspend))
susp_type = TREE_TYPE (TREE_TYPE (fndecl));
 else
susp_type = TREE_TYPE (suspend);
would do?  But how can TREE_TYPE (suspend) be different from the return 
type of the function decl?  It seems funky that the behaviour could 
depend on the form of the suspend.  What am I missing?




@@ -1532,6 +1553,8 @@ co_await_expander (tree *stmt, int * /*do_subtree*/, void 
*d)
  = build1 (ADDR_EXPR, build_reference_type (void_type_node), resume_label);
tree susp
  = build1 (ADDR_EXPR, build_reference_type (void_type_node), 
data->cororet);
+  tree cont
+= build1 (ADDR_EXPR, build_reference_type (void_type_node), 
data->corocont);
tree final_susp = build_int_cst (integer_type_node, is_final ? 1 : 0);


Wait, 'void &' is not a thing.  What's been happening here?  do you mean 
to build pointer_types?  'build_address (data->$FIELD)'



@@ -2012,6 +2027,15 @@ build_actor_fn (location_t loc, tree coro_frame_type, 
tree actor, tree fnbody,
  = create_named_label_with_ctx (loc, "actor.begin", actor);
tree actor_frame = build1_loc (loc, INDIRECT_REF, coro_frame_type, 
actor_fp);
  
+  /* Init the continuation with a NULL ptr.  */

+  tree zeroinit = build1 (CONVERT_EXPR, void_coro_handle_type,
+ integer_zero_node);
+  tree ci = build2 (INIT_EXPR, void_coro_handle_type, continuation, zeroinit);
+  ci = build_stmt (loc, DECL_EXPR, continuation);


This appears to be overwriting ci?


+  ci = build1_loc (loc, CONVERT_EXPR, void_type_node, ci);

.. and still expecting it to be an EXPR node?

+  ci = maybe_cleanup_point_expr_void (ci);
+  add_stmt (ci);
+
/* Re-write param references in the body, no code should be generated
   here.  */
if (DECL_ARGUMENTS (orig))



+
+  /* Now we have the actual call, and we can mark it as a tail.  */
+  CALL_EXPR_TAILCALL (resume) = true;
+  /* ... and for optimisation levels 0..1, mark it as requiring a tail-call
+ for correctness.  It seems that doing this for optimisation levels that
+ normally perform tail-calling, confuses the ME (or it would be logical
+ to put this on unilaterally).  */


 Might be worth ping a ME expert about why that is?


+  if (optimize < 2)
+CALL_EXPR_MUST_TAIL_CALL (resume) = true;
+  resume = coro_build_cvt_void_expr_stmt (resume, loc);
+  add_stmt (resume);
+
+  r = build_stmt (loc, RETURN_EXPR, NULL);
+  r = maybe_cleanup_point_expr_void (r);


Shouldn't there be no cleanups?  Perhaps assert it didn't add any?


+  add_stmt (r);
+
/* We need the resume index to work with.  */
tree res_idx_m
  = lookup_member (coro_frame_type, resume_idx_name,


nathan


--
Nathan Sidwell

Re: [PATCH] if-conv: Delete dead stmts backwards in ifcvt_local_dce [PR94283]

[Richard Biener]

On Tue, 24 Mar 2020, Jakub Jelinek wrote:

> On Tue, Mar 24, 2020 at 10:59:19AM +0100, Richard Biener wrote:
> > Likely
> > 
> >   /* Delete dead statements.  */
> >   gsi = gsi_start_bb (bb);
> >   while (!gsi_end_p (gsi))
> > {
> > 
> > needs to instead work back-to-front for debug stmt adjustment to work
> 
> Indeed, that seems to work.  Ok for trunk if it passes bootstrap/regtest?

OK.

> 2020-03-24  Richard Biener  
>   Jakub Jelinek  
> 
>   PR debug/94283
>   * tree-if-conv.c (ifcvt_local_dce): Delete dead statements backwards.
> 
>   * gcc.dg/pr94283.c: New test.
> 
> --- gcc/tree-if-conv.c.jj 2020-03-24 09:34:35.152087914 +0100
> +++ gcc/tree-if-conv.c2020-03-24 11:13:41.179903247 +0100
> @@ -2973,9 +2973,11 @@ ifcvt_local_dce (class loop *loop)
>   }
>  }
>/* Delete dead statements.  */
> -  gsi = gsi_start_bb (bb);
> +  gsi = gsi_last_bb (bb);
>while (!gsi_end_p (gsi))
>  {
> +  gimple_stmt_iterator gsiprev = gsi;
> +  gsi_prev ();
>stmt = gsi_stmt (gsi);
>if (gimple_store_p (stmt))
>   {
> @@ -2986,14 +2988,13 @@ ifcvt_local_dce (class loop *loop)
> if (dse_classify_store (, stmt, false, NULL, NULL, latch_vdef)
> == DSE_STORE_DEAD)
>   delete_dead_or_redundant_assignment (, "dead");
> -   else
> - gsi_next ();
> +   gsi = gsiprev;
> continue;
>   }
>  
>if (gimple_plf (stmt, GF_PLF_2))
>   {
> -   gsi_next ();
> +   gsi = gsiprev;
> continue;
>   }
>if (dump_file && (dump_flags & TDF_DETAILS))
> @@ -3003,6 +3004,7 @@ ifcvt_local_dce (class loop *loop)
>   }
>gsi_remove (, true);
>release_defs (stmt);
> +  gsi = gsiprev;
>  }
>  }
>  
> --- gcc/testsuite/gcc.dg/pr94283.c.jj 2020-03-24 11:15:35.782163250 +0100
> +++ gcc/testsuite/gcc.dg/pr94283.c2020-03-24 11:16:37.909219978 +0100
> @@ -0,0 +1,16 @@
> +/* PR debug/94283 */
> +/* { dg-do compile } */
> +/* { dg-options "-O3 -fno-tree-dce -fcompare-debug" } */
> +
> +void
> +foo (int *n)
> +{
> +  for (int i = 0; i < 32; i++)
> +{
> +  int x = 0;
> +  x++;
> +  if (i & 4)
> + x++;
> +  x++;
> +}
> +}
> 
> 
>   Jakub
> 
> 

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

RE: [RFC] Should widening_mul should consider block frequency?

[Yangfei (Felix)]

Hi!

> -Original Message-
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: Monday, March 23, 2020 11:25 PM
> To: Yangfei (Felix) 
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [RFC] Should widening_mul should consider block frequency?
> 
> On Mon, Mar 23, 2020 at 10:53 AM Yangfei (Felix) 
> wrote:
> >
> > Hi,
> >
> >   I created a bug for this issue:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94269
> >   Looks like widening_mul phase may move multiply instruction from outside
> the loop to inside the loop, merging with one add instruction inside the loop.
> >   This will increase the cost of the loop at least on aarch64 (4 cycles vs 1
> cycle).  I think widening_mul should consider block frequency when doing such
> a combination.
> >   I mean something like:
> 
> As written in the PR I'd follow fma generation and restrict defs to the same 
> BB.

Thanks for the suggestion.  That should be more consistent.  
Attached please find the adapted patch.  
Bootstrap and tested on both x86_64 and aarch64 Linux platform.  

gcc:
+2020-03-24  Felix Yang  
+
+   PR tree-optimization/94269
+   * tree-ssa-math-opts.c (convert_plusminus_to_widen): Restrict this
+   operation to single basic block.

gcc/testsuite:
+2020-03-24  Felix Yang  
+
+   PR tree-optimization/94269
+   * gcc.dg/pr94269.c: New test.
+

Thanks,
Felix


pr94269-v1.patch
Description: pr94269-v1.patch

Re: [PATCH] Check endianess detection.

[Jakub Jelinek via Gcc-patches]

On Tue, Mar 24, 2020 at 11:32:32AM +0100, Martin Liška wrote:
> >From 82b8731f304c734353c34ddaf1b1265341a90882 Mon Sep 17 00:00:00 2001
> From: Martin Liska 
> Date: Tue, 24 Mar 2020 09:12:50 +0100
> Subject: [PATCH] Improve endianess detection.
> 
> include/ChangeLog:
> 
> 2020-03-24  Martin Liska  
> 
>   PR lto/94249
>   * plugin-api.h: Add more robust endianess detection.

Ok.

Jakub

Re: [PATCH] Check endianess detection.

[Martin Liška]

On 3/24/20 10:18 AM, Jakub Jelinek wrote:

Hi!

So, assuming I'm on glibc with GCC 4.5 on powerpc64-linux.

On Tue, Mar 24, 2020 at 09:49:42AM +0100, Martin Liška wrote:

+/* Detect endianess based on __BYTE_ORDER__ macro.  */
+#if defined(__BYTE_ORDER__) && defined(__ORDER_BIG_ENDIAN__) && \
+defined(__ORDER_LITTLE_ENDIAN__) && defined(__ORDER_PDP_ENDIAN__)
+#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
+#define PLUGIN_LITTLE_ENDIAN 1
+#elif __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
+#define PLUGIN_BIG_ENDIAN 1
+#elif __BYTE_ORDER__ == __ORDER_PDP_ENDIAN__
+#define PLUGIN_PDP_ENDIAN 1
+#endif
+#else
+/* Older GCC releases (<4.6.0) can make detection from glibc macros.  */
+#if defined(__GLIBC__) || defined(__GNU_LIBRARY__) || defined(__ANDROID__)
+#include 
+#if __BYTE_ORDER == __LITTLE_ENDIAN
+#define PLUGIN_LITTLE_ENDIAN 1
+#elif __BYTE_ORDER == __BIG_ENDIAN
+#define PLUGIN_BIG_ENDIAN 1
+#endif


This will definePLUGIN_BIG_ENDIAN.


+#endif
+/* Include all necessary header files based on target.  */
+#if defined(__SVR4) && defined(__sun)
+#include 
+#endif
+#if defined(__FreeBSD__) || defined(__NetBSD__) || \
+defined(__DragonFly__) || defined(__minix)
+#include 
+#endif
+#if defined(__OpenBSD__)
+#include 
+#endif


The above headers will not be included.


+/* Detect endianess based on _BYTE_ORDER.  */
+#if _BYTE_ORDER == _LITTLE_ENDIAN


So most likely _BYTE_ORDER and _LITTLE_ENDIAN macros will not be defined.
Which means this will be handled as #if 0 == 0 and override the

+#define PLUGIN_LITTLE_ENDIAN 1


will define also PLUGIN_LITTLE_ENDIAN.


Ok, for being sure, I've wrapped all equality comparison with corresponding
check of the LHS is defined.




+#elif _BYTE_ORDER == _BIG_ENDIAN
+#define PLUGIN_BIG_ENDIAN 1
+#endif
+/* Detect based on _WIN32.  */
+#if defined(_WIN32)
+#define PLUGIN_LITTLE_ENDIAN 1
+#endif
+/* Fallback to __BIG_ENDIAN__ and __LITTLE_ENDIAN__ */
+#ifdef __LITTLE_ENDIAN__
+#define PLUGIN_LITTLE_ENDIAN 1
+#endif
+#ifdef __BIG_ENDIAN__
+#define PLUGIN_BIG_ENDIAN 1
+#endif
+#endif


and the above isn't really a fallback, because it isn't guarded with
PLUGIN_*_ENDIAN not being defined yet.


This comment has been also updated.

Martin



Jakub



>From 82b8731f304c734353c34ddaf1b1265341a90882 Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Tue, 24 Mar 2020 09:12:50 +0100
Subject: [PATCH] Improve endianess detection.

include/ChangeLog:

2020-03-24  Martin Liska  

	PR lto/94249
	* plugin-api.h: Add more robust endianess detection.
---
 include/plugin-api.h | 65 ++--
 1 file changed, 63 insertions(+), 2 deletions(-)

diff --git a/include/plugin-api.h b/include/plugin-api.h
index 673f136ce68..864d2bf91ac 100644
--- a/include/plugin-api.h
+++ b/include/plugin-api.h
@@ -37,6 +37,60 @@
 #error cannot find uint64_t type
 #endif
 
+/* Detect endianess based on __BYTE_ORDER__ macro.  */
+#if defined(__BYTE_ORDER__) && defined(__ORDER_BIG_ENDIAN__) && \
+defined(__ORDER_LITTLE_ENDIAN__) && defined(__ORDER_PDP_ENDIAN__)
+#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
+#define PLUGIN_LITTLE_ENDIAN 1
+#elif __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
+#define PLUGIN_BIG_ENDIAN 1
+#elif __BYTE_ORDER__ == __ORDER_PDP_ENDIAN__
+#define PLUGIN_PDP_ENDIAN 1
+#endif
+#else
+/* Older GCC releases (<4.6.0) can make detection from glibc macros.  */
+#if defined(__GLIBC__) || defined(__GNU_LIBRARY__) || defined(__ANDROID__)
+#include 
+#ifdef _BYTE_ORDER
+#if __BYTE_ORDER == __LITTLE_ENDIAN
+#define PLUGIN_LITTLE_ENDIAN 1
+#elif __BYTE_ORDER == __BIG_ENDIAN
+#define PLUGIN_BIG_ENDIAN 1
+#endif
+#endif
+#endif
+/* Include all necessary header files based on target.  */
+#if defined(__SVR4) && defined(__sun)
+#include 
+#endif
+#if defined(__FreeBSD__) || defined(__NetBSD__) || \
+defined(__DragonFly__) || defined(__minix)
+#include 
+#endif
+#if defined(__OpenBSD__)
+#include 
+#endif
+/* Detect endianess based on _BYTE_ORDER.  */
+#ifdef _BYTE_ORDER
+#if _BYTE_ORDER == _LITTLE_ENDIAN
+#define PLUGIN_LITTLE_ENDIAN 1
+#elif _BYTE_ORDER == _BIG_ENDIAN
+#define PLUGIN_BIG_ENDIAN 1
+#endif
+#endif
+/* Detect based on _WIN32.  */
+#if defined(_WIN32)
+#define PLUGIN_LITTLE_ENDIAN 1
+#endif
+/* Detect based on __BIG_ENDIAN__ and __LITTLE_ENDIAN__ */
+#ifdef __LITTLE_ENDIAN__
+#define PLUGIN_LITTLE_ENDIAN 1
+#endif
+#ifdef __BIG_ENDIAN__
+#define PLUGIN_BIG_ENDIAN 1
+#endif
+#endif
+
 #ifdef __cplusplus
 extern "C"
 {
@@ -89,16 +143,23 @@ struct ld_plugin_symbol
   char *version;
   /* This is for compatibility with older ABIs.  The older ABI defined
  only 'def' field.  */
-#ifdef __BIG_ENDIAN__
+#if PLUGIN_BIG_ENDIAN == 1
   char unused;
   char section_kind;
   char symbol_type;
   char def;
-#else
+#elif PLUGIN_LITTLE_ENDIAN == 1
   char def;
   char symbol_type;
   char section_kind;
   char unused;
+#elif PLUGIN_PDP_ENDIAN == 1
+  char symbol_type;
+  char def;
+  char unused;
+  char section_kind;
+#else
+#error "Could not detect 

[PATCH] if-conv: Delete dead stmts backwards in ifcvt_local_dce [PR94283]

[Jakub Jelinek via Gcc-patches]

On Tue, Mar 24, 2020 at 10:59:19AM +0100, Richard Biener wrote:
> Likely
> 
>   /* Delete dead statements.  */
>   gsi = gsi_start_bb (bb);
>   while (!gsi_end_p (gsi))
> {
> 
> needs to instead work back-to-front for debug stmt adjustment to work

Indeed, that seems to work.  Ok for trunk if it passes bootstrap/regtest?

2020-03-24  Richard Biener  
Jakub Jelinek  

PR debug/94283
* tree-if-conv.c (ifcvt_local_dce): Delete dead statements backwards.

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

--- gcc/tree-if-conv.c.jj   2020-03-24 09:34:35.152087914 +0100
+++ gcc/tree-if-conv.c  2020-03-24 11:13:41.179903247 +0100
@@ -2973,9 +2973,11 @@ ifcvt_local_dce (class loop *loop)
}
 }
   /* Delete dead statements.  */
-  gsi = gsi_start_bb (bb);
+  gsi = gsi_last_bb (bb);
   while (!gsi_end_p (gsi))
 {
+  gimple_stmt_iterator gsiprev = gsi;
+  gsi_prev ();
   stmt = gsi_stmt (gsi);
   if (gimple_store_p (stmt))
{
@@ -2986,14 +2988,13 @@ ifcvt_local_dce (class loop *loop)
  if (dse_classify_store (, stmt, false, NULL, NULL, latch_vdef)
  == DSE_STORE_DEAD)
delete_dead_or_redundant_assignment (, "dead");
- else
-   gsi_next ();
+ gsi = gsiprev;
  continue;
}
 
   if (gimple_plf (stmt, GF_PLF_2))
{
- gsi_next ();
+ gsi = gsiprev;
  continue;
}
   if (dump_file && (dump_flags & TDF_DETAILS))
@@ -3003,6 +3004,7 @@ ifcvt_local_dce (class loop *loop)
}
   gsi_remove (, true);
   release_defs (stmt);
+  gsi = gsiprev;
 }
 }
 
--- gcc/testsuite/gcc.dg/pr94283.c.jj   2020-03-24 11:15:35.782163250 +0100
+++ gcc/testsuite/gcc.dg/pr94283.c  2020-03-24 11:16:37.909219978 +0100
@@ -0,0 +1,16 @@
+/* PR debug/94283 */
+/* { dg-do compile } */
+/* { dg-options "-O3 -fno-tree-dce -fcompare-debug" } */
+
+void
+foo (int *n)
+{
+  for (int i = 0; i < 32; i++)
+{
+  int x = 0;
+  x++;
+  if (i & 4)
+   x++;
+  x++;
+}
+}


Jakub

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

[Tobias Burnus]

On 3/11/20 2:28 PM, Tobias Burnus wrote:

Fortran patch:
https://gcc.gnu.org/pipermail/gcc-patches/current/541774.html

Like for Fortran, it also fixes some other issues – here for C++
related to namespaces. (For class, see PR c++/94140.)

Test case of the PR yields an ICE in the middle end and the
namespace tests an ICE in cc1plus. Additionally, invalid code
is not diagnosed.

The OpenACC spec has under "Declare Directive" has the following
restriction:

"A declare directive must be in the same scope
 as the declaration of any var that appears in
 the data clauses of the directive."

("A declare directive is used […] following a variable
  declaration in C or C++".)

NOTE for C++: This patch assumes that variables in a namespace
are handled in the same way as those which are at
global (namespace) scope; however, the OpenACC specification's
wording currently is "In C or C++ global scope, only …".
Hence, one can argue about this part of the patch; but as
it fixes an ICE and is a very sensible extension – the other
option is to reject it – I believe it is fine.
(On the OpenACC side, this is now Issue 288.)

OK for the trunk?

Tobias


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

New template for 'gcc' made available

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.  (If you have
any questions, send them to .)

A new POT file for textual domain 'gcc' has been made available
to the language teams for translation.  It is archived as:

https://translationproject.org/POT-files/gcc-10.1-b20200322.pot

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

Below is the URL which has been provided to the translators of your
package.  Please inform the translation coordinator, at the address
at the bottom, if this information is not current:

https://gcc.gnu.org/pub/gcc/snapshots/10-20200322/gcc-10-20200322.tar.xz

Translated PO files will later be automatically e-mailed to you.

Thank you for all your work,

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

Re: [PATCH] if-conv: Fix -fcompare-debug bugs in ifcvt_local_dce [PR94283]

[Richard Biener]

On Tue, 24 Mar 2020, Martin Liška wrote:

> Hi.
> 
> This patch caused:
> 
> gcc
> /home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/990625-2.c
> -O3 -g -fno-tree-dce -c
> during GIMPLE pass: ifcvt
> /home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/990625-2.c:
> In function ‘broken030599’:
> /home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/990625-2.c:2:1:
> internal compiler error: Segmentation fault
> 2 | broken030599(int *n)
>   | ^~~~
> 0xe32f1f crash_signal
>   ../../gcc/toplev.c:328
> 0x77999f1f ???
>   
> /usr/src/debug/glibc-2.31-3.1.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
> 0x104ffe5 verify_use
>   ../../gcc/tree-ssa.c:884
> 0x1054607 verify_ssa(bool, bool)
>   ../../gcc/tree-ssa.c:1161
> 0xd4fb05 execute_function_todo
>   ../../gcc/passes.c:1992
> 0xd507ae execute_todo
>   ../../gcc/passes.c:2039
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See  for instructions.

Likely

  /* Delete dead statements.  */
  gsi = gsi_start_bb (bb);
  while (!gsi_end_p (gsi))
{

needs to instead work back-to-front for debug stmt adjustment to work

Re: [committed] [P1][PR target/94238] Don't create invalid comparisons

[Jakub Jelinek via Gcc-patches]

On Mon, Mar 23, 2020 at 06:00:06PM -0600, Jeff Law via Gcc-patches wrote:
> +/* Return true if CODE is valid for comparisons of mode MODE, false
> +   otherwise.
> +
> +   It is always safe to return false, even if the code was valid for the
> +   given mode as that will merely suppress optimizations.  */
> +
> +static bool
> +comparison_code_valid_for_mode (enum rtx_code code, enum machine_mode mode)
> +{
> +  switch (code)
> +{
> +  /* These are valid for integral, floating and vector modes.  */
> +  case NE:
> +  case EQ:
> +  case GE:
> +  case GT:
> +  case LE:
> +  case LT:
> + return (INTEGRAL_MODE_P (mode)
> + || FLOAT_MODE_P (mode)
> + || VECTOR_MODE_P (mode));

I'm not sure I understand the VECTOR_MODE_P cases.
INTEGRAL_MODE_P or FLOAT_MODE_P already do include vector modes with the
corresponding element types.
And if you want the {,u}{fract,accum} modes for some of these, shouldn't
they apply to both scalar and vector modes thereof?
So, either drop the || VECTOR_MODE_P (mode), or use
|| ALL_FRACT_MODE_P (mode) || ALL_ACCUM_MODE_P (mode)
instead?

> +
> +  /* These are valid for floating point modes.  */
> +  case LTGT:
> +  case UNORDERED:
> +  case ORDERED:
> +  case UNEQ:
> +  case UNGE:
> +  case UNGT:
> +  case UNLE:
> +  case UNLT:
> + return FLOAT_MODE_P (mode);

This will do the right thing, i.e. allow it for both floating scalar and
vector modes.

> +  /* These are filtered out in simplify_logical_operation, but
> +  we check for them too as a matter of safety.   They are valid
> +  for integral and vector modes.  */
> +  case GEU:
> +  case GTU:
> +  case LEU:
> +  case LTU:
> + return INTEGRAL_MODE_P (mode) || VECTOR_MODE_P (mode);

This doesn't look right.  I don't know what the fract/accum modes want, but
you don't want to return true for GET_MODE_CLASS (mode) ==
MODE_VECTOR_FLOAT, do you?

Jakub

Re: [PATCH] match.pd: recognize a signed rotate

[Stefan Schulze Frielinghaus via Gcc-patches]

On Mon, Mar 23, 2020 at 04:44:56PM +0100, Richard Biener wrote:
> On Mon, Mar 23, 2020 at 4:34 PM Jakub Jelinek  wrote:
> >
> > On Mon, Mar 23, 2020 at 04:29:12PM +0100, Richard Biener wrote:
> > > I wonder if we can leverage the bswap pass for rotate detection
> > > (see find_bswap_or_nop which matches the symbolic number
> > > against either 1:1 or byte-swapped variants, to be added would be
> > > rotate and shift patterns).
> >
> > That pass can only handle cases where the shift counts are multiple of
> > BITS_PER_UNIT, the whole infrastructure is based on being able to track
> > movements of bytes.
> 
> That's true, but also an artifact of the symbolic number encoding.

I'm pretty new to match.pd and in general to GCC.  Is there something
which speaks against solving this in match.pd?  If so and the bswap pass
is also not the right place, do you have something else in mind?

Re: [PATCH] Check endianess detection.

[Jakub Jelinek via Gcc-patches]

Hi!

So, assuming I'm on glibc with GCC 4.5 on powerpc64-linux.

On Tue, Mar 24, 2020 at 09:49:42AM +0100, Martin Liška wrote:
> +/* Detect endianess based on __BYTE_ORDER__ macro.  */
> +#if defined(__BYTE_ORDER__) && defined(__ORDER_BIG_ENDIAN__) && \
> +defined(__ORDER_LITTLE_ENDIAN__) && defined(__ORDER_PDP_ENDIAN__)
> +#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
> +#define PLUGIN_LITTLE_ENDIAN 1
> +#elif __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
> +#define PLUGIN_BIG_ENDIAN 1
> +#elif __BYTE_ORDER__ == __ORDER_PDP_ENDIAN__
> +#define PLUGIN_PDP_ENDIAN 1
> +#endif
> +#else
> +/* Older GCC releases (<4.6.0) can make detection from glibc macros.  */
> +#if defined(__GLIBC__) || defined(__GNU_LIBRARY__) || defined(__ANDROID__)
> +#include 
> +#if __BYTE_ORDER == __LITTLE_ENDIAN
> +#define PLUGIN_LITTLE_ENDIAN 1
> +#elif __BYTE_ORDER == __BIG_ENDIAN
> +#define PLUGIN_BIG_ENDIAN 1
> +#endif

This will definePLUGIN_BIG_ENDIAN.

> +#endif
> +/* Include all necessary header files based on target.  */
> +#if defined(__SVR4) && defined(__sun)
> +#include 
> +#endif
> +#if defined(__FreeBSD__) || defined(__NetBSD__) || \
> +defined(__DragonFly__) || defined(__minix)
> +#include 
> +#endif
> +#if defined(__OpenBSD__)
> +#include 
> +#endif

The above headers will not be included.

> +/* Detect endianess based on _BYTE_ORDER.  */
> +#if _BYTE_ORDER == _LITTLE_ENDIAN

So most likely _BYTE_ORDER and _LITTLE_ENDIAN macros will not be defined.
Which means this will be handled as #if 0 == 0 and override the 
> +#define PLUGIN_LITTLE_ENDIAN 1

will define also PLUGIN_LITTLE_ENDIAN.

> +#elif _BYTE_ORDER == _BIG_ENDIAN
> +#define PLUGIN_BIG_ENDIAN 1
> +#endif
> +/* Detect based on _WIN32.  */
> +#if defined(_WIN32)
> +#define PLUGIN_LITTLE_ENDIAN 1
> +#endif
> +/* Fallback to __BIG_ENDIAN__ and __LITTLE_ENDIAN__ */
> +#ifdef __LITTLE_ENDIAN__
> +#define PLUGIN_LITTLE_ENDIAN 1
> +#endif
> +#ifdef __BIG_ENDIAN__
> +#define PLUGIN_BIG_ENDIAN 1
> +#endif
> +#endif

and the above isn't really a fallback, because it isn't guarded with
PLUGIN_*_ENDIAN not being defined yet.

Jakub

Re: [PATCH] if-conv: Fix -fcompare-debug bugs in ifcvt_local_dce [PR94283]

[Martin Liška]

Hi.

This patch caused:

gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/990625-2.c 
-O3 -g -fno-tree-dce -c
during GIMPLE pass: ifcvt
/home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/990625-2.c: In 
function ‘broken030599’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/990625-2.c:2:1:
 internal compiler error: Segmentation fault
2 | broken030599(int *n)
  | ^~~~
0xe32f1f crash_signal
../../gcc/toplev.c:328
0x77999f1f ???

/usr/src/debug/glibc-2.31-3.1.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x104ffe5 verify_use
../../gcc/tree-ssa.c:884
0x1054607 verify_ssa(bool, bool)
../../gcc/tree-ssa.c:1161
0xd4fb05 execute_function_todo
../../gcc/passes.c:1992
0xd507ae execute_todo
../../gcc/passes.c:2039
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Martin

RE: [PATCH] arm: Fix arm {, u}subvdi4 and usubvsi4 expanders [PR94286]

[Kyrylo Tkachov]

> -Original Message-
> From: Jakub Jelinek 
> Sent: 24 March 2020 08:20
> To: Richard Earnshaw ; Ramana
> Radhakrishnan ; Kyrylo Tkachov
> 
> Cc: gcc-patches@gcc.gnu.org
> Subject: [PATCH] arm: Fix arm {,u}subvdi4 and usubvsi4 expanders [PR94286]
> 
> Hi!
> 
> The following testcase ICEs, because these expanders will happily create a
> SImode 0x8000 CONST_INT, which is not valid RTL, as CONST_INTs need
> to be sign extended from the mode precision to full HWI.
> 
> Fixed thusly, bootstrapped/regtested on armv7hl-linux-gnueabi, ok for trunk?

Ok.
Thanks,
Kyrill

> 
> 2020-03-24  Jakub Jelinek  
> 
>   PR target/94286
>   * config/arm/arm.md (subvdi4, usubvsi4, usubvdi4): Use
> gen_int_mode
>   instead of GEN_INT.
> 
>   * gcc.dg/pr94286.c: New test.
> 
> --- gcc/config/arm/arm.md.jj  2020-03-20 09:32:48.094338574 +0100
> +++ gcc/config/arm/arm.md 2020-03-23 19:23:18.263211430 +0100
> @@ -1481,7 +1481,7 @@ (define_expand "subvdi4"
>  lo_op2 = force_reg (SImode, lo_op2);
>if (CONST_INT_P (lo_op2))
>  emit_insn (gen_cmpsi2_addneg (lo_result, lo_op1, lo_op2,
> -   GEN_INT (-INTVAL (lo_op2;
> +   gen_int_mode (-INTVAL (lo_op2), SImode)));
>else
>  emit_insn (gen_subsi3_compare1 (lo_result, lo_op1, lo_op2));
> 
> @@ -1525,7 +1525,8 @@ (define_expand "usubvsi4"
>  }
>else if (CONST_INT_P (operands[2]))
>  emit_insn (gen_cmpsi2_addneg (operands[0], operands[1], operands[2],
> -   GEN_INT (-INTVAL (operands[2];
> +   gen_int_mode (-INTVAL (operands[2]),
> + SImode)));
>else if (CONST_INT_P (operands[1]))
>  {
>mode = CC_RSBmode;
> @@ -1597,7 +1598,7 @@ (define_expand "usubvdi4"
>  lo_op2 = force_reg (SImode, lo_op2);
>if (CONST_INT_P (lo_op2))
>  emit_insn (gen_cmpsi2_addneg (lo_result, lo_op1, lo_op2,
> -   GEN_INT (-INTVAL (lo_op2;
> +   gen_int_mode (-INTVAL (lo_op2), SImode)));
>else
>  emit_insn (gen_subsi3_compare1 (lo_result, lo_op1, lo_op2));
> 
> --- gcc/testsuite/gcc.dg/pr94286.c.jj 2020-03-23 19:24:26.294207928
> +0100
> +++ gcc/testsuite/gcc.dg/pr94286.c2020-03-23 19:21:32.501771489
> +0100
> @@ -0,0 +1,11 @@
> +/* PR target/94286 */
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -g" } */
> +
> +unsigned a, b;
> +
> +int
> +foo (void)
> +{
> +  return __builtin_sub_overflow (a, 0x8000U, ); }
> 
>   Jakub

Re: [PATCH] Check endianess detection.

[Martin Liška]

On 3/24/20 9:31 AM, Jakub Jelinek wrote:

On Tue, Mar 24, 2020 at 09:19:12AM +0100, Martin Liška wrote:

2020-03-24  Martin Liska  

PR lto/94249
* plugin-api.h: Add more robust endianess detection.
---
  include/plugin-api.h | 43 +--
  1 file changed, 41 insertions(+), 2 deletions(-)

diff --git a/include/plugin-api.h b/include/plugin-api.h
index 673f136ce68..4a211d51f43 100644
--- a/include/plugin-api.h
+++ b/include/plugin-api.h
@@ -42,6 +42,43 @@ extern "C"
  {
  #endif


The location is incorrect, you don't want to include system headers
inside explicit extern "C", so please move it a few lines above it.

Furthermore, you don't have the glibc case with GCC < 4.6 handled, that
needs something like:
#if defined(__GLIBC__) || defined(__GNU_LIBRARY__) \
 || defined(__ANDROID__)
#include 
#if __BYTE_ORDER == __LITTLE_ENDIAN
#define PLUGIN_LITTLE_ENDIAN 1
#elif __BYTE_ORDER == __BIG_ENDIAN
#define PLUGIN_BIG_ENDIAN 1
...
(of course done only if __BYTE_ORDER__ and __ORDER_*_ENDIAN__ isn't
defined).

And, you don't handle PDP endian, while GCC does support pdp11-*,
so IMNSHO you also need to detect PDP endian and use:

#elif PLUGIN_PDP_ENDIAN == 1
   char symbol_type;
   char def;
   char unused;
   char section_kind;

Jakub



Thank you Jakub for the review!
There's updated patch that reflects that.

Martin
>From 05c219e70a6928ed3fbb087090594fe2a09234a9 Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Tue, 24 Mar 2020 09:12:50 +0100
Subject: [PATCH] Improve endianess detection.

include/ChangeLog:

2020-03-24  Martin Liska  

	PR lto/94249
	* plugin-api.h: Add more robust endianess detection.
---
 include/plugin-api.h | 61 ++--
 1 file changed, 59 insertions(+), 2 deletions(-)

diff --git a/include/plugin-api.h b/include/plugin-api.h
index 673f136ce68..e8ba6603977 100644
--- a/include/plugin-api.h
+++ b/include/plugin-api.h
@@ -37,6 +37,56 @@
 #error cannot find uint64_t type
 #endif
 
+/* Detect endianess based on __BYTE_ORDER__ macro.  */
+#if defined(__BYTE_ORDER__) && defined(__ORDER_BIG_ENDIAN__) && \
+defined(__ORDER_LITTLE_ENDIAN__) && defined(__ORDER_PDP_ENDIAN__)
+#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
+#define PLUGIN_LITTLE_ENDIAN 1
+#elif __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
+#define PLUGIN_BIG_ENDIAN 1
+#elif __BYTE_ORDER__ == __ORDER_PDP_ENDIAN__
+#define PLUGIN_PDP_ENDIAN 1
+#endif
+#else
+/* Older GCC releases (<4.6.0) can make detection from glibc macros.  */
+#if defined(__GLIBC__) || defined(__GNU_LIBRARY__) || defined(__ANDROID__)
+#include 
+#if __BYTE_ORDER == __LITTLE_ENDIAN
+#define PLUGIN_LITTLE_ENDIAN 1
+#elif __BYTE_ORDER == __BIG_ENDIAN
+#define PLUGIN_BIG_ENDIAN 1
+#endif
+#endif
+/* Include all necessary header files based on target.  */
+#if defined(__SVR4) && defined(__sun)
+#include 
+#endif
+#if defined(__FreeBSD__) || defined(__NetBSD__) || \
+defined(__DragonFly__) || defined(__minix)
+#include 
+#endif
+#if defined(__OpenBSD__)
+#include 
+#endif
+/* Detect endianess based on _BYTE_ORDER.  */
+#if _BYTE_ORDER == _LITTLE_ENDIAN
+#define PLUGIN_LITTLE_ENDIAN 1
+#elif _BYTE_ORDER == _BIG_ENDIAN
+#define PLUGIN_BIG_ENDIAN 1
+#endif
+/* Detect based on _WIN32.  */
+#if defined(_WIN32)
+#define PLUGIN_LITTLE_ENDIAN 1
+#endif
+/* Fallback to __BIG_ENDIAN__ and __LITTLE_ENDIAN__ */
+#ifdef __LITTLE_ENDIAN__
+#define PLUGIN_LITTLE_ENDIAN 1
+#endif
+#ifdef __BIG_ENDIAN__
+#define PLUGIN_BIG_ENDIAN 1
+#endif
+#endif
+
 #ifdef __cplusplus
 extern "C"
 {
@@ -89,16 +139,23 @@ struct ld_plugin_symbol
   char *version;
   /* This is for compatibility with older ABIs.  The older ABI defined
  only 'def' field.  */
-#ifdef __BIG_ENDIAN__
+#if PLUGIN_BIG_ENDIAN == 1
   char unused;
   char section_kind;
   char symbol_type;
   char def;
-#else
+#elif PLUGIN_LITTLE_ENDIAN == 1
   char def;
   char symbol_type;
   char section_kind;
   char unused;
+#elif PLUGIN_PDP_ENDIAN == 1
+  char symbol_type;
+  char def;
+  char unused;
+  char section_kind;
+#else
+#error "Could not detect architecture endianess"
 #endif
   int visibility;
   uint64_t size;
-- 
2.25.1

Re: [PATCH] Check endianess detection.

[Jakub Jelinek via Gcc-patches]

On Tue, Mar 24, 2020 at 09:19:12AM +0100, Martin Liška wrote:
> 2020-03-24  Martin Liska  
> 
>   PR lto/94249
>   * plugin-api.h: Add more robust endianess detection.
> ---
>  include/plugin-api.h | 43 +--
>  1 file changed, 41 insertions(+), 2 deletions(-)
> 
> diff --git a/include/plugin-api.h b/include/plugin-api.h
> index 673f136ce68..4a211d51f43 100644
> --- a/include/plugin-api.h
> +++ b/include/plugin-api.h
> @@ -42,6 +42,43 @@ extern "C"
>  {
>  #endif

The location is incorrect, you don't want to include system headers
inside explicit extern "C", so please move it a few lines above it.

Furthermore, you don't have the glibc case with GCC < 4.6 handled, that
needs something like:
#if defined(__GLIBC__) || defined(__GNU_LIBRARY__) \
|| defined(__ANDROID__)
#include 
#if __BYTE_ORDER == __LITTLE_ENDIAN
#define PLUGIN_LITTLE_ENDIAN 1
#elif __BYTE_ORDER == __BIG_ENDIAN
#define PLUGIN_BIG_ENDIAN 1
...
(of course done only if __BYTE_ORDER__ and __ORDER_*_ENDIAN__ isn't
defined).

And, you don't handle PDP endian, while GCC does support pdp11-*,
so IMNSHO you also need to detect PDP endian and use:

#elif PLUGIN_PDP_ENDIAN == 1
  char symbol_type;
  char def;
  char unused;
  char section_kind;

Jakub

[PATCH v2] Fix PR90332 by extending half size vector mode

[Kewen.Lin via Gcc-patches]

Hi,

on 2020/3/18 下午11:10, Richard Biener wrote:
> On Wed, Mar 18, 2020 at 2:56 PM Kewen.Lin  wrote:
>>
>> Hi Richi,
>>
>> Thanks for your comments.
>>
>> on 2020/3/18 下午6:39, Richard Biener wrote:
>>> On Wed, Mar 18, 2020 at 11:06 AM Kewen.Lin  wrote:

>> This path can define overrun_p to false, some case can fall into
>> "no peeling for gaps" hunk in vectorizable_load.  Since I used
>> DR_GROUP_HALF_MODE to save the half mode, if some case matches
>> this condition, vectorizable_load hunk can get unitialized
>> DR_GROUP_HALF_MODE.  But even with proposed recomputing way, I
>> think we still need to check the vec_init optab here if the
>> know_eq half size conditions hold?
> 
> Hmm, but for the above case it's fine to access the excess elements.
> 
> I guess the vectorizable_load code needs to be amended with
> the alignment check or we do need to store somewhere our
> decision to use smaller loads.
> 

OK, thanks.  I'll investigate it separately.

>>
>>> I don't like storing DR_GROUP_HALF_MODE very much, later
>>> you need a vector type and it looks cheap enough to recompute
>>> it where you need it?  Iff then it doesn't belong to DR_GROUP
>>> but to the stmt-info.
>>>
>>
>> OK, I was intended not to recompute it for time saving, will
>> throw it away.
>>
>>> I realize the original optimization was kind of a hack (and I was too
>>> lazy to implement the integer mode construction path ...).
>>>
>>> So, can you factor out the existing code into a function returning
>>> the vector type for construction for a vector type and a
>>> pieces size?  So for V16QI and a pieces-size of 4 we'd
>>> get either V16QI back (then construction from V4QI pieces
>>> should work) or V4SI (then construction from SImode pieces
>>> should work)?  Eventually as secondary output provide that
>>> piece type (SI / V4QI).
>>
>> Sure.  I'm very poor to get a function name, does function name
>> suitable_vector_and_pieces sound good?
>>   ie. tree suitable_vector_and_pieces (tree vtype, tree *ptype);
> 
> tree vector_vector_composition_type (tree vtype, poly_uint64 nelts,
> tree *ptype);
> 
> where nelts specifies the number of vtype elements in a piece.
> 

Thanks, yep, "nelts" I forgot to get it.

The new version with refactoring has been attached.
Bootstrapped/regtested on powerpc64le-linux-gnu (LE) P8 and P9.

Is it ok for trunk?

BR,
Kewen
-
gcc/ChangeLog

2020-MM-DD  Kewen Lin  

PR tree-optimization/90332
* gcc/tree-vect-stmts.c (vector_vector_composition_type): New function.
(get_group_load_store_type): Adjust to call 
vector_vector_composition_type,
extend it to construct with scalar types.
(vectorizable_load): Likewise.

-
diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c
index 2ca8e494680..9e00b6f24cd 100644
--- a/gcc/tree-vect-stmts.c
+++ b/gcc/tree-vect-stmts.c
@@ -2220,6 +2220,61 @@ vect_get_store_rhs (stmt_vec_info stmt_info)
   gcc_unreachable ();
 }
 
+/* Function VECTOR_VECTOR_COMPOSITION_TYPE
+
+   This function returns a vector type which can be composed with NETLS pieces,
+   whose type is recorded in PTYPE.  VTYPE should be a vector type, and has the
+   same vector size as the return vector.  It checks target whether supports
+   pieces-size vector mode for construction firstly, if target fails to, check
+   pieces-size scalar mode for construction further.  It returns NULL_TREE if
+   fails to find the available composition.
+
+   For example, for (vtype=V16QI, nelts=4), we can probably get:
+ - V16QI with PTYPE V4QI.
+ - V4SI with PTYPE SI.
+ - NULL_TREE.  */
+
+static tree
+vector_vector_composition_type (tree vtype, poly_uint64 nelts, tree *ptype)
+{
+  gcc_assert (VECTOR_TYPE_P (vtype));
+  gcc_assert (known_gt (nelts, 0U));
+
+  machine_mode vmode = TYPE_MODE (vtype);
+  if (!VECTOR_MODE_P (vmode))
+return NULL_TREE;
+
+  poly_uint64 vbsize = GET_MODE_BITSIZE (vmode);
+  unsigned int pbsize;
+  if (constant_multiple_p (vbsize, nelts, ))
+{
+  /* First check if vec_init optab supports construction from
+vector pieces directly.  */
+  scalar_mode elmode = SCALAR_TYPE_MODE (TREE_TYPE (vtype));
+  machine_mode rmode;
+  if (related_vector_mode (vmode, elmode, nelts).exists ()
+ && (convert_optab_handler (vec_init_optab, vmode, rmode)
+ != CODE_FOR_nothing))
+   {
+ *ptype = build_vector_type (TREE_TYPE (vtype), nelts);
+ return vtype;
+   }
+
+  /* Otherwise check if exists an integer type of the same piece size and
+if vec_init optab supports construction from it directly.  */
+  if (int_mode_for_size (pbsize, 0).exists ()
+ && related_vector_mode (vmode, elmode, nelts).exists ()
+ && (convert_optab_handler (vec_init_optab, rmode, elmode)
+ != CODE_FOR_nothing))
+   {
+ *ptype = build_nonstandard_integer_type (pbsize, 1);
+ return build_vector_type (*ptype, nelts);
+   }
+}
+
+  

[PATCH] arm: Fix arm {,u}subvdi4 and usubvsi4 expanders [PR94286]

[Jakub Jelinek via Gcc-patches]

Hi!

The following testcase ICEs, because these expanders will happily create
a SImode 0x8000 CONST_INT, which is not valid RTL, as CONST_INTs need to
be sign extended from the mode precision to full HWI.

Fixed thusly, bootstrapped/regtested on armv7hl-linux-gnueabi, ok for trunk?

2020-03-24  Jakub Jelinek  

PR target/94286
* config/arm/arm.md (subvdi4, usubvsi4, usubvdi4): Use gen_int_mode
instead of GEN_INT.

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

--- gcc/config/arm/arm.md.jj2020-03-20 09:32:48.094338574 +0100
+++ gcc/config/arm/arm.md   2020-03-23 19:23:18.263211430 +0100
@@ -1481,7 +1481,7 @@ (define_expand "subvdi4"
 lo_op2 = force_reg (SImode, lo_op2);
   if (CONST_INT_P (lo_op2))
 emit_insn (gen_cmpsi2_addneg (lo_result, lo_op1, lo_op2,
- GEN_INT (-INTVAL (lo_op2;
+ gen_int_mode (-INTVAL (lo_op2), SImode)));
   else
 emit_insn (gen_subsi3_compare1 (lo_result, lo_op1, lo_op2));
 
@@ -1525,7 +1525,8 @@ (define_expand "usubvsi4"
 }
   else if (CONST_INT_P (operands[2]))
 emit_insn (gen_cmpsi2_addneg (operands[0], operands[1], operands[2],
- GEN_INT (-INTVAL (operands[2];
+ gen_int_mode (-INTVAL (operands[2]),
+   SImode)));
   else if (CONST_INT_P (operands[1]))
 {
   mode = CC_RSBmode;
@@ -1597,7 +1598,7 @@ (define_expand "usubvdi4"
 lo_op2 = force_reg (SImode, lo_op2);
   if (CONST_INT_P (lo_op2))
 emit_insn (gen_cmpsi2_addneg (lo_result, lo_op1, lo_op2,
- GEN_INT (-INTVAL (lo_op2;
+ gen_int_mode (-INTVAL (lo_op2), SImode)));
   else
 emit_insn (gen_subsi3_compare1 (lo_result, lo_op1, lo_op2));
 
--- gcc/testsuite/gcc.dg/pr94286.c.jj   2020-03-23 19:24:26.294207928 +0100
+++ gcc/testsuite/gcc.dg/pr94286.c  2020-03-23 19:21:32.501771489 +0100
@@ -0,0 +1,11 @@
+/* PR target/94286 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -g" } */
+
+unsigned a, b;
+
+int
+foo (void)
+{
+  return __builtin_sub_overflow (a, 0x8000U, );
+}

Jakub

Re: [PATCH] Check endianess detection.

[Martin Liška]

All right, there's update endianess detection that should be robust
enough.

I've tested that on x86_64-linux-gnu and sparc64-linux.

Ready for master?
Thanks,
Martin
>From be4ce2c54672e7772586c13d6e37c63124624bbc Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Tue, 24 Mar 2020 09:12:50 +0100
Subject: [PATCH] Improve endianess detection.

include/ChangeLog:

2020-03-24  Martin Liska  

	PR lto/94249
	* plugin-api.h: Add more robust endianess detection.
---
 include/plugin-api.h | 43 +--
 1 file changed, 41 insertions(+), 2 deletions(-)

diff --git a/include/plugin-api.h b/include/plugin-api.h
index 673f136ce68..4a211d51f43 100644
--- a/include/plugin-api.h
+++ b/include/plugin-api.h
@@ -42,6 +42,43 @@ extern "C"
 {
 #endif
 
+/* Detect endianess based on __BYTE_ORDER__ macro.  */
+#if defined(__BYTE_ORDER__) && defined(__ORDER_BIG_ENDIAN__) && defined(__ORDER_LITTLE_ENDIAN__)
+#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
+#define PLUGIN_LITTLE_ENDIAN 1
+#elif __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
+#define PLUGIN_BIG_ENDIAN 1
+#endif
+#else
+/* Include all necessary header files based on target.  */
+#if defined(__SVR4) && defined(__sun)
+#include 
+#endif
+#if defined(__FreeBSD__) || defined(__NetBSD__) || defined(__DragonFly__) || defined(__minix)
+#include 
+#endif
+#if defined(__OpenBSD__)
+#include 
+#endif
+/* Detect endianess based on _BYTE_ORDER.  */
+#if _BYTE_ORDER == _LITTLE_ENDIAN
+#define PLUGIN_LITTLE_ENDIAN 1
+#elif _BYTE_ORDER == _BIG_ENDIAN
+#define PLUGIN_BIG_ENDIAN 1
+#endif
+/* Detect based on _WIN32.  */
+#if defined(_WIN32)
+#define PLUGIN_LITTLE_ENDIAN 1
+#endif
+/* Fallback to __BIG_ENDIAN__ and __LITTLE_ENDIAN__ */
+#ifdef __LITTLE_ENDIAN__
+#define PLUGIN_LITTLE_ENDIAN 1
+#endif
+#ifdef __BIG_ENDIAN__
+#define PLUGIN_BIG_ENDIAN 1
+#endif
+#endif
+
 /* Status code returned by most API routines.  */
 
 enum ld_plugin_status
@@ -89,16 +126,18 @@ struct ld_plugin_symbol
   char *version;
   /* This is for compatibility with older ABIs.  The older ABI defined
  only 'def' field.  */
-#ifdef __BIG_ENDIAN__
+#if PLUGIN_BIG_ENDIAN == 1
   char unused;
   char section_kind;
   char symbol_type;
   char def;
-#else
+#elif PLUGIN_LITTLE_ENDIAN == 1
   char def;
   char symbol_type;
   char section_kind;
   char unused;
+#else
+#error "Could not detect architecture endianess"
 #endif
   int visibility;
   uint64_t size;
-- 
2.25.1

Re: [PATCH] loop-manip: Avoid -fcompare-debug issues in create_iv [PR94285]

[Richard Biener]

On Tue, 24 Mar 2020, Jakub Jelinek wrote:

> Hi!
> 
> The following testcase FAILs with -fcompare-debug.  The problem is that
> create_iv behaves differently when inserting after into an empty bb (in that
> case sets location to goto_locus), or when inserting before gsi_end_p (i.e.
> at the end of bb; in that case it will not set location, otherwise it will
> set it to the location of next stmt).
> This isn't -fcompare-debug friendly, because if inserting after and the
> bb contains only debug stmts, then the location will not be set with -g
> and will be with -g0, or when inserting before, the location might either
> be set from the following debug stmt rather than some non-debug stmt after
> that, or might not be set with -g0 if it is to be inserted at the end of bb,
> while with -g would be set to location of debug stmt.
> 
> The following patch should fix that, bootstrapped/regtested on x86_64-linux
> and i686-linux, ok for trunk?

OK

> 2020-03-24  Jakub Jelinek  
> 
>   PR debug/94285
>   * tree-ssa-loop-manip.c (create_iv): If after, set stmt location to
>   e->goto_locus even if gsi_bb (*incr_pos) contains only debug stmts.
>   If not after and at *incr_pos is a debug stmt, set stmt location to
>   location of next non-debug stmt after it if any.
> 
>   * gfortran.dg/pr94285.f90: New test.
> 
> --- gcc/tree-ssa-loop-manip.c.jj  2020-01-12 11:54:38.506381831 +0100
> +++ gcc/tree-ssa-loop-manip.c 2020-03-23 23:57:41.395225047 +0100
> @@ -129,7 +129,10 @@ create_iv (tree base, tree step, tree va
>   immediately after a statement whose location is known.  */
>if (after)
>  {
> -  if (gsi_end_p (*incr_pos))
> +  if (gsi_end_p (*incr_pos)
> +   || (is_gimple_debug (gsi_stmt (*incr_pos))
> +   && gsi_bb (*incr_pos)
> +   && gsi_end_p (gsi_last_nondebug_bb (gsi_bb (*incr_pos)
>   {
> edge e = single_succ_edge (gsi_bb (*incr_pos));
> gimple_set_location (stmt, e->goto_locus);
> @@ -138,8 +141,11 @@ create_iv (tree base, tree step, tree va
>  }
>else
>  {
> -  if (!gsi_end_p (*incr_pos))
> - gimple_set_location (stmt, gimple_location (gsi_stmt (*incr_pos)));
> +  gimple_stmt_iterator gsi = *incr_pos;
> +  if (!gsi_end_p (gsi) && is_gimple_debug (gsi_stmt (gsi)))
> + gsi_next_nondebug ();
> +  if (!gsi_end_p (gsi))
> + gimple_set_location (stmt, gimple_location (gsi_stmt (gsi)));
>gsi_insert_before (incr_pos, stmt, GSI_NEW_STMT);
>  }
>  
> --- gcc/testsuite/gfortran.dg/pr94285.f90.jj  2020-03-23 18:55:19.677902869 
> +0100
> +++ gcc/testsuite/gfortran.dg/pr94285.f90 2020-03-23 18:55:01.300172491 
> +0100
> @@ -0,0 +1,5 @@
> +! PR debug/94285
> +! { dg-do compile }
> +! { dg-options "-Os -fno-tree-dominator-opts -fno-tree-vrp -fcompare-debug" }
> +
> +include 'array_constructor_40.f90'
> 
>   Jakub
> 
> 

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

Re: [PATCH] if-conv: Fix -fcompare-debug bugs in ifcvt_local_dce [PR94283]

[Richard Biener]

On Tue, 24 Mar 2020, Jakub Jelinek wrote:

> Hi!
> 
> The following testcase shows -fcompare-debug bugs in ifcvt_local_dce,
> where the decisions what statements are needed is based also on debug stmt
> operands, which is wrong.
> So, this patch makes sure to never add debug stmt to the worklist, or never
> add an assign to worklist just because it is used in a debug stmt in another
> bb.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

OK.

> 2020-03-24  Jakub Jelinek  
> 
>   PR debug/94283
>   * tree-if-conv.c (ifcvt_local_dce): For gimple debug stmts, just set
>   GF_PLF_2, but don't add them to worklist.  Don't add an assigment to
>   worklist or set GF_PLF_2 just because it is used in a debug stmt in
>   another bb.  Formatting improvements.
> 
>   * gcc.target/i386/pr94283.c: New test.
> 
> --- gcc/tree-if-conv.c.jj 2020-01-12 11:54:38.495381997 +0100
> +++ gcc/tree-if-conv.c2020-03-23 17:13:13.823724294 +0100
> @@ -2917,9 +2917,12 @@ ifcvt_local_dce (class loop *loop)
>for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next ())
>  {
>stmt = gsi_stmt (gsi);
> -  if (gimple_store_p (stmt)
> -   || gimple_assign_load_p (stmt)
> -   || is_gimple_debug (stmt))
> +  if (is_gimple_debug (stmt))
> + {
> +   gimple_set_plf (stmt, GF_PLF_2, true);
> +   continue;
> + }
> +  if (gimple_store_p (stmt) || gimple_assign_load_p (stmt))
>   {
> gimple_set_plf (stmt, GF_PLF_2, true);
> worklist.safe_push (stmt);
> @@ -2940,7 +2943,7 @@ ifcvt_local_dce (class loop *loop)
> FOR_EACH_IMM_USE_FAST (use_p, imm_iter, lhs)
>   {
> stmt1 = USE_STMT (use_p);
> -   if (gimple_bb (stmt1) != bb)
> +   if (!is_gimple_debug (stmt1) && gimple_bb (stmt1) != bb)
>   {
> gimple_set_plf (stmt, GF_PLF_2, true);
> worklist.safe_push (stmt);
> @@ -2963,8 +2966,7 @@ ifcvt_local_dce (class loop *loop)
> if (TREE_CODE (use) != SSA_NAME)
>   continue;
> stmt1 = SSA_NAME_DEF_STMT (use);
> -   if (gimple_bb (stmt1) != bb
> -   || gimple_plf (stmt1, GF_PLF_2))
> +   if (gimple_bb (stmt1) != bb || gimple_plf (stmt1, GF_PLF_2))
>   continue;
> gimple_set_plf (stmt1, GF_PLF_2, true);
> worklist.safe_push (stmt1);
> --- gcc/testsuite/gcc.target/i386/pr94283.c.jj2020-03-23 
> 17:16:50.324494226 +0100
> +++ gcc/testsuite/gcc.target/i386/pr94283.c   2020-03-23 17:16:42.238614863 
> +0100
> @@ -0,0 +1,5 @@
> +/* PR debug/94283 */
> +/* { dg-do compile } */
> +/* { dg-options "-O3 -fcompare-debug -mavx2" } */
> +
> +#include "../../gcc.dg/fold-bopcond-1.c"
> 
>   Jakub
> 
> 

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

[PATCH] loop-manip: Avoid -fcompare-debug issues in create_iv [PR94285]

[Jakub Jelinek via Gcc-patches]

Hi!

The following testcase FAILs with -fcompare-debug.  The problem is that
create_iv behaves differently when inserting after into an empty bb (in that
case sets location to goto_locus), or when inserting before gsi_end_p (i.e.
at the end of bb; in that case it will not set location, otherwise it will
set it to the location of next stmt).
This isn't -fcompare-debug friendly, because if inserting after and the
bb contains only debug stmts, then the location will not be set with -g
and will be with -g0, or when inserting before, the location might either
be set from the following debug stmt rather than some non-debug stmt after
that, or might not be set with -g0 if it is to be inserted at the end of bb,
while with -g would be set to location of debug stmt.

The following patch should fix that, bootstrapped/regtested on x86_64-linux
and i686-linux, ok for trunk?

2020-03-24  Jakub Jelinek  

PR debug/94285
* tree-ssa-loop-manip.c (create_iv): If after, set stmt location to
e->goto_locus even if gsi_bb (*incr_pos) contains only debug stmts.
If not after and at *incr_pos is a debug stmt, set stmt location to
location of next non-debug stmt after it if any.

* gfortran.dg/pr94285.f90: New test.

--- gcc/tree-ssa-loop-manip.c.jj2020-01-12 11:54:38.506381831 +0100
+++ gcc/tree-ssa-loop-manip.c   2020-03-23 23:57:41.395225047 +0100
@@ -129,7 +129,10 @@ create_iv (tree base, tree step, tree va
  immediately after a statement whose location is known.  */
   if (after)
 {
-  if (gsi_end_p (*incr_pos))
+  if (gsi_end_p (*incr_pos)
+ || (is_gimple_debug (gsi_stmt (*incr_pos))
+ && gsi_bb (*incr_pos)
+ && gsi_end_p (gsi_last_nondebug_bb (gsi_bb (*incr_pos)
{
  edge e = single_succ_edge (gsi_bb (*incr_pos));
  gimple_set_location (stmt, e->goto_locus);
@@ -138,8 +141,11 @@ create_iv (tree base, tree step, tree va
 }
   else
 {
-  if (!gsi_end_p (*incr_pos))
-   gimple_set_location (stmt, gimple_location (gsi_stmt (*incr_pos)));
+  gimple_stmt_iterator gsi = *incr_pos;
+  if (!gsi_end_p (gsi) && is_gimple_debug (gsi_stmt (gsi)))
+   gsi_next_nondebug ();
+  if (!gsi_end_p (gsi))
+   gimple_set_location (stmt, gimple_location (gsi_stmt (gsi)));
   gsi_insert_before (incr_pos, stmt, GSI_NEW_STMT);
 }
 
--- gcc/testsuite/gfortran.dg/pr94285.f90.jj2020-03-23 18:55:19.677902869 
+0100
+++ gcc/testsuite/gfortran.dg/pr94285.f90   2020-03-23 18:55:01.300172491 
+0100
@@ -0,0 +1,5 @@
+! PR debug/94285
+! { dg-do compile }
+! { dg-options "-Os -fno-tree-dominator-opts -fno-tree-vrp -fcompare-debug" }
+
+include 'array_constructor_40.f90'

Jakub

[PATCH] if-conv: Fix -fcompare-debug bugs in ifcvt_local_dce [PR94283]

[Jakub Jelinek via Gcc-patches]

Hi!

The following testcase shows -fcompare-debug bugs in ifcvt_local_dce,
where the decisions what statements are needed is based also on debug stmt
operands, which is wrong.
So, this patch makes sure to never add debug stmt to the worklist, or never
add an assign to worklist just because it is used in a debug stmt in another
bb.

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

2020-03-24  Jakub Jelinek  

PR debug/94283
* tree-if-conv.c (ifcvt_local_dce): For gimple debug stmts, just set
GF_PLF_2, but don't add them to worklist.  Don't add an assigment to
worklist or set GF_PLF_2 just because it is used in a debug stmt in
another bb.  Formatting improvements.

* gcc.target/i386/pr94283.c: New test.

--- gcc/tree-if-conv.c.jj   2020-01-12 11:54:38.495381997 +0100
+++ gcc/tree-if-conv.c  2020-03-23 17:13:13.823724294 +0100
@@ -2917,9 +2917,12 @@ ifcvt_local_dce (class loop *loop)
   for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next ())
 {
   stmt = gsi_stmt (gsi);
-  if (gimple_store_p (stmt)
- || gimple_assign_load_p (stmt)
- || is_gimple_debug (stmt))
+  if (is_gimple_debug (stmt))
+   {
+ gimple_set_plf (stmt, GF_PLF_2, true);
+ continue;
+   }
+  if (gimple_store_p (stmt) || gimple_assign_load_p (stmt))
{
  gimple_set_plf (stmt, GF_PLF_2, true);
  worklist.safe_push (stmt);
@@ -2940,7 +2943,7 @@ ifcvt_local_dce (class loop *loop)
  FOR_EACH_IMM_USE_FAST (use_p, imm_iter, lhs)
{
  stmt1 = USE_STMT (use_p);
- if (gimple_bb (stmt1) != bb)
+ if (!is_gimple_debug (stmt1) && gimple_bb (stmt1) != bb)
{
  gimple_set_plf (stmt, GF_PLF_2, true);
  worklist.safe_push (stmt);
@@ -2963,8 +2966,7 @@ ifcvt_local_dce (class loop *loop)
  if (TREE_CODE (use) != SSA_NAME)
continue;
  stmt1 = SSA_NAME_DEF_STMT (use);
- if (gimple_bb (stmt1) != bb
- || gimple_plf (stmt1, GF_PLF_2))
+ if (gimple_bb (stmt1) != bb || gimple_plf (stmt1, GF_PLF_2))
continue;
  gimple_set_plf (stmt1, GF_PLF_2, true);
  worklist.safe_push (stmt1);
--- gcc/testsuite/gcc.target/i386/pr94283.c.jj  2020-03-23 17:16:50.324494226 
+0100
+++ gcc/testsuite/gcc.target/i386/pr94283.c 2020-03-23 17:16:42.238614863 
+0100
@@ -0,0 +1,5 @@
+/* PR debug/94283 */
+/* { dg-do compile } */
+/* { dg-options "-O3 -fcompare-debug -mavx2" } */
+
+#include "../../gcc.dg/fold-bopcond-1.c"

Jakub

Re: [PATCH] cgraphunit: Avoid code generation differences based on -w/TREE_NO_WARNING [PR94277]

[Richard Biener]

On Tue, 24 Mar 2020, Jakub Jelinek wrote:

> Hi!
> 
> The following testcase FAILs with -fcompare-debug, but not because -g vs.
> -g0 would make a difference, but because the second compilation is done with
> -w in order not to emit warnings twice and -w seems to affect the *.gkd dump
> content.
> This is because TREE_NO_WARNING flag, or warn_unused_function does affect
> not just whether a warning/pedwarn is printed, but also whether we set
> TREE_PUBLIC on such decls.
> The following patch makes sure we set it regardless of anything warning
> related (TREE_NO_WARNING or warn_unused_function).
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

OK.

Thanks,
Richard.

> 2020-03-24  Jakub Jelinek  
> 
>   PR debug/94277
>   * cgraphunit.c (check_global_declaration): For DECL_EXTERNAL and
>   non-TREE_PUBLIC non-DECL_ARTIFICIAL FUNCTION_DECLs, set TREE_PUBLIC
>   regardless of whether TREE_NO_WARNING is set on it or whether
>   warn_unused_function is true or not.
> 
>   * gcc.dg/pr94277.c: New test.
> 
> --- gcc/cgraphunit.c.jj   2020-03-19 18:13:21.703789041 +0100
> +++ gcc/cgraphunit.c  2020-03-23 15:49:47.160449491 +0100
> @@ -1068,15 +1068,15 @@ check_global_declaration (symtab_node *s
>&& DECL_INITIAL (decl) == 0
>&& DECL_EXTERNAL (decl)
>&& ! DECL_ARTIFICIAL (decl)
> -  && ! TREE_NO_WARNING (decl)
> -  && ! TREE_PUBLIC (decl)
> -  && (warn_unused_function
> -   || snode->referred_to_p (/*include_self=*/false)))
> +  && ! TREE_PUBLIC (decl))
>  {
> -  if (snode->referred_to_p (/*include_self=*/false))
> +  if (TREE_NO_WARNING (decl))
> + ;
> +  else if (snode->referred_to_p (/*include_self=*/false))
>   pedwarn (input_location, 0, "%q+F used but never defined", decl);
>else
> - warning (OPT_Wunused_function, "%q+F declared % but never 
> defined", decl);
> + warning (OPT_Wunused_function, "%q+F declared % but never "
> +"defined", decl);
>/* This symbol is effectively an "extern" declaration now.  */
>TREE_PUBLIC (decl) = 1;
>  }
> --- gcc/testsuite/gcc.dg/pr94277.c.jj 2020-03-23 15:51:25.739980041 +0100
> +++ gcc/testsuite/gcc.dg/pr94277.c2020-03-23 15:51:09.616220387 +0100
> @@ -0,0 +1,11 @@
> +/* PR debug/94277 */
> +/* { dg-do compile } */
> +/* { dg-options "-fcompare-debug" } */
> +
> +static void foo (void);  /* { dg-warning "used but never defined" } */
> +
> +void
> +bar (void)
> +{
> +  foo ();
> +}
> 
>   Jakub
> 
> 

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

[PATCH] cgraphunit: Avoid code generation differences based on -w/TREE_NO_WARNING [PR94277]

[Jakub Jelinek via Gcc-patches]

Hi!

The following testcase FAILs with -fcompare-debug, but not because -g vs.
-g0 would make a difference, but because the second compilation is done with
-w in order not to emit warnings twice and -w seems to affect the *.gkd dump
content.
This is because TREE_NO_WARNING flag, or warn_unused_function does affect
not just whether a warning/pedwarn is printed, but also whether we set
TREE_PUBLIC on such decls.
The following patch makes sure we set it regardless of anything warning
related (TREE_NO_WARNING or warn_unused_function).

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

2020-03-24  Jakub Jelinek  

PR debug/94277
* cgraphunit.c (check_global_declaration): For DECL_EXTERNAL and
non-TREE_PUBLIC non-DECL_ARTIFICIAL FUNCTION_DECLs, set TREE_PUBLIC
regardless of whether TREE_NO_WARNING is set on it or whether
warn_unused_function is true or not.

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

--- gcc/cgraphunit.c.jj 2020-03-19 18:13:21.703789041 +0100
+++ gcc/cgraphunit.c2020-03-23 15:49:47.160449491 +0100
@@ -1068,15 +1068,15 @@ check_global_declaration (symtab_node *s
   && DECL_INITIAL (decl) == 0
   && DECL_EXTERNAL (decl)
   && ! DECL_ARTIFICIAL (decl)
-  && ! TREE_NO_WARNING (decl)
-  && ! TREE_PUBLIC (decl)
-  && (warn_unused_function
- || snode->referred_to_p (/*include_self=*/false)))
+  && ! TREE_PUBLIC (decl))
 {
-  if (snode->referred_to_p (/*include_self=*/false))
+  if (TREE_NO_WARNING (decl))
+   ;
+  else if (snode->referred_to_p (/*include_self=*/false))
pedwarn (input_location, 0, "%q+F used but never defined", decl);
   else
-   warning (OPT_Wunused_function, "%q+F declared % but never 
defined", decl);
+   warning (OPT_Wunused_function, "%q+F declared % but never "
+  "defined", decl);
   /* This symbol is effectively an "extern" declaration now.  */
   TREE_PUBLIC (decl) = 1;
 }
--- gcc/testsuite/gcc.dg/pr94277.c.jj   2020-03-23 15:51:25.739980041 +0100
+++ gcc/testsuite/gcc.dg/pr94277.c  2020-03-23 15:51:09.616220387 +0100
@@ -0,0 +1,11 @@
+/* PR debug/94277 */
+/* { dg-do compile } */
+/* { dg-options "-fcompare-debug" } */
+
+static void foo (void);/* { dg-warning "used but never defined" } */
+
+void
+bar (void)
+{
+  foo ();
+}

Jakub

[PATCH] c++: Fix a -fcompare-debug issue with DEBUG_BEGIN_STMT stmts in STATEMENT_LISTs [PR94272]

[Jakub Jelinek via Gcc-patches]

Hi!

The following testcase FAILs with -fcompare-debug.  The problem is that
the C++ FE initially uses IF_STMTs, tcc_statement which default to
TREE_SIDE_EFFECTS set, but later on is genericized into COND_EXPRs,
tcc_expression which default to TREE_SIDE_EFFECTS ored from all 3 operands.
Furthermore, with -g we emit by default DEBUG_BEGIN_STMTs (TREE_SIDE_EFFECTS
clear) and so end up with a STATEMENT_LIST containing DEBUG_BEGIN_STMT
+ e.g. the IF_STMT, while with -g0 we would end up with just the IF_STMT
alone and in that case there is no STATEMENT_LIST wrapping it.

Now, the STATEMENT_LIST has TREE_SIDE_EFFECTS set to match the IF_STMT,
but if none of the 3 operands (condition and both branches) have
TREE_SIDE_EFFECTS, genericize_if_stmt will replace the IF_STMT with
COND_EXPR without TREE_SIDE_EFFECTS, but with -g only STATEMENT_LIST
wrapping it will keep TREE_SIDE_EFFECTS.  Then during gimplification,
shortcut_cond_expr checks TREE_SIDE_EFFECTS of the operands and as it
is differennt between -g and -g0, will generate different code.

The following patch attempts to fix this by clearing TREE_SIDE_EFFECTS
on STATEMENT_LISTs that initially have it set and contain only
DEBUG_BEGIN_STMT or at most one other statement that lost TREE_SIDE_EFFECTS
during the genericization.

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

2020-03-24  Jakub Jelinek  

PR c++/94272
* cp-gimplify.c (cp_genericize_r): Handle STATEMENT_LIST.

* g++.dg/debug/pr94272.C: New test.

--- gcc/cp/cp-gimplify.c.jj 2020-03-20 09:11:36.276902935 +0100
+++ gcc/cp/cp-gimplify.c2020-03-23 14:50:08.354821919 +0100
@@ -1754,6 +1754,36 @@ cp_genericize_r (tree *stmt_p, int *walk
   walk_subtrees = 0;
   break;
 
+case STATEMENT_LIST:
+  if (TREE_SIDE_EFFECTS (stmt))
+   {
+ tree_stmt_iterator i;
+ int nondebug_stmts = 0;
+ bool clear_side_effects = true;
+ /* Genericization can clear TREE_SIDE_EFFECTS, e.g. when
+transforming an IF_STMT into COND_EXPR.  If such stmt
+appears in a STATEMENT_LIST that contains only that
+stmt and some DEBUG_BEGIN_STMTs, without -g where the
+STATEMENT_LIST wouldn't be present at all the resulting
+expression wouldn't have TREE_SIDE_EFFECTS set, so make sure
+to clear it even on the STATEMENT_LIST in such cases.  */
+ for (i = tsi_start (stmt); !tsi_end_p (i); tsi_next ())
+   {
+ tree t = tsi_stmt (i);
+ if (TREE_CODE (t) != DEBUG_BEGIN_STMT && nondebug_stmts < 2)
+   nondebug_stmts++;
+ cp_walk_tree (tsi_stmt_ptr (i), cp_genericize_r, data, NULL);
+ if (TREE_CODE (t) != DEBUG_BEGIN_STMT
+ && nondebug_stmts == 1
+ && TREE_SIDE_EFFECTS (tsi_stmt (i)))
+   clear_side_effects = false;
+   }
+ if (nondebug_stmts < 2 && clear_side_effects)
+   TREE_SIDE_EFFECTS (stmt) = 0;
+ *walk_subtrees = 0;
+   }
+  break;
+
 default:
   if (IS_TYPE_OR_DECL_P (stmt))
*walk_subtrees = 0;
--- gcc/testsuite/g++.dg/debug/pr94272.C.jj 2020-03-23 15:04:49.037693587 
+0100
+++ gcc/testsuite/g++.dg/debug/pr94272.C2020-03-23 15:04:04.109363546 
+0100
@@ -0,0 +1,14 @@
+// PR c++/94272
+// { dg-do compile }
+// { dg-options "-O2 -fnon-call-exceptions -fcompare-debug" }
+
+int *c, d, *e;
+
+void
+foo ()
+{
+  if (c && d)
+;
+  else if (*e)
+;
+}

Jakub

[PATCH] Fix handling of --with{,out}-zstd option.

[Martin Liška]

Hi.

The patch respects --without-zstd and reports
an error when we can't find header file with --with-zstd.

Ready to be installed?
Thanks,
Martin

gcc/ChangeLog:

2020-03-23  Martin Liska  

PR lto/94259
* configure.ac: Respect --without-zstd and report
error when we can't find header file with --with-zstd.
* configure: Regenerate.
---
 gcc/configure| 13 +
 gcc/configure.ac |  9 +++--
 2 files changed, 16 insertions(+), 6 deletions(-)


diff --git a/gcc/configure b/gcc/configure
index 5381e107bce..b4231fe7b7e 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -9962,13 +9962,15 @@ fi
 case "x$with_zstd" in
   x) ;;
   xno)
-ZSTD_INCLUDE=no
-ZSTD_LIB=no
+ZSTD_INCLUDE=
+ZSTD_LIB=
 ;;
   *) ZSTD_INCLUDE=$with_zstd/include
  ZSTD_LIB=$with_zstd/lib
  ;;
 esac
+
+if test "x$with_zstd" != xno; then
 if test "x$with_zstd_include" != x; then
   ZSTD_INCLUDE=$with_zstd_include
 fi
@@ -10017,6 +10019,8 @@ if test $gcc_cv_header_zstd_h = yes; then
 
 $as_echo "#define HAVE_ZSTD_H 1" >>confdefs.h
 
+else
+as_fn_error $? "Unable to find zstd.h.  See config.log for details." "$LINENO" 5
 fi
 
 # LTO can use zstd compression algorithm
@@ -10081,6 +10085,7 @@ fi
 ZSTD_LIB="$LIBS"
 LIBS="$save_LIBS"
 
+fi
 
 
 
@@ -18980,7 +18985,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 18983 "configure"
+#line 18988 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -19086,7 +19091,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 19089 "configure"
+#line 19094 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
diff --git a/gcc/configure.ac b/gcc/configure.ac
index 0d6230e0ca1..0051963c85d 100644
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -1334,13 +1334,15 @@ AC_ARG_WITH(zstd-lib,
 case "x$with_zstd" in
   x) ;;
   xno)
-ZSTD_INCLUDE=no
-ZSTD_LIB=no
+ZSTD_INCLUDE=
+ZSTD_LIB=
 ;;
   *) ZSTD_INCLUDE=$with_zstd/include
  ZSTD_LIB=$with_zstd/lib
  ;;
 esac
+
+if test "x$with_zstd" != xno; then
 if test "x$with_zstd_include" != x; then
   ZSTD_INCLUDE=$with_zstd_include
 fi
@@ -1369,6 +1371,8 @@ AC_MSG_RESULT($gcc_cv_header_zstd_h)
 if test $gcc_cv_header_zstd_h = yes; then
   AC_DEFINE(HAVE_ZSTD_H, 1,
 	[Define if you have a working  header file.])
+else
+as_fn_error $? "Unable to find zstd.h.  See config.log for details." "$LINENO" 5
 fi
 
 # LTO can use zstd compression algorithm
@@ -1378,6 +1382,7 @@ AC_SEARCH_LIBS(ZSTD_compress, zstd)
 ZSTD_LIB="$LIBS"
 LIBS="$save_LIBS"
 AC_SUBST(ZSTD_LIB)
+fi
 
 dnl Disabled until we have a complete test for buggy enum bitfields.
 dnl gcc_AC_C_ENUM_BF_UNSIGNED

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

[Yangfei (Felix)]

Hi!

> -Original Message-
> From: Segher Boessenkool [mailto:seg...@kernel.crashing.org]
> Sent: Monday, March 23, 2020 8:10 PM
> To: Yangfei (Felix) 
> Cc: gcc-patches@gcc.gnu.org; Zhanghaijian (A) 
> Subject: Re: [PATCH PR94026] combine missed opportunity to simplify
> comparisons with zero
> 
> Yeah, maybe not in simplify-rtx.c, hrm.  There is SELECT_CC_MODE for these
> things, and combine knows about that (not many passes do).

I modified combine emitting a simple AND operation instead of making one 
zero_extract for this scenario.  
Attached please find the new patch.  Hope this solves both of our concerns.  

gcc
+2020-03-24  Felix Yang   
+
+   PR rtl-optimization/94026
+   * combine.c (make_compound_operation_int): If we are have (and
+   (lshiftrt X C) M) and M is a constant that would select a field
+   of bits within an item, but not the entire word, fold this into
+   a simple AND if we are in an equality comparison.

gcc/testsuite
+2020-03-24  Felix Yang   
+
+   PR rtl-optimization/94026
+   * gcc.dg/pr94026.c: New test.


Thanks,
Felix


pr94026-v1.patch
Description: pr94026-v1.patch