Re: [PATCH] include MEM_REF type in tree dumps (PR 90676)

2019-06-14 Thread Richard Biener
On Thu, Jun 13, 2019 at 5:54 PM Jakub Jelinek  wrote:
>
> On Thu, Jun 13, 2019 at 09:50:16AM -0600, Martin Sebor wrote:
> > On 6/13/19 9:34 AM, Jakub Jelinek wrote:
> > > On Thu, Jun 13, 2019 at 09:30:37AM -0600, Martin Sebor wrote:
> > > > The size of the access above doesn't look right.  The test is:
> > >
> > > It is correct.  You have MEM  [(int *)&i], which is
> > > the same thing as i itself, and on this you apply an ARRAY_REF,
> > > which is printed after it, with index j_1(D).  ARRAY_REF is applied on
> > > arrays and the result type is the array element type, so int in this case.
> >
> > Aah, it's two REFs in one.  I misread the array index as being
> > a part of the MEM_REF operand, like this:
> >
> >   MEM  [((int *)&i)[j_1(D)]] = 1;
> >
> > I guess I've never noticed this before.  Why is the whole thing
> > not simplified to an ARRAY_REF?
> >
> >   i[j_2(D)] = 1;
>
> No idea in this case, though of course there can be other cases e.g.
> where the MEM_REF has different number of elements, different element type
> etc. from the underlying variable or where the MEM_REF first operand is not
> address, but pointer.

We elide the MEM_REF only if the TBAA type exactly matches the value-type.
Since TBAA-wise an array is the same as the element type (unless the
language says otherwise - see get_alias_set) we could in some cases with
arrays elide it.  It didn't seem worth the extra complexity in the code doing
this, see maybe_canonicalize_mem_ref_addr.  Honza is at the moment
trying to improve access-path disambiguation which runs into related issues.

Richard.

> Jakub


Re: indirect_ref_may_alias_decl_p fix

2019-06-14 Thread Jan Hubicka
> Hi Jan,
> 
> > I am testing the following patch which solves the bogus warning in
> > tree-ssa-forwprop.c and -m32 and plan to commit it as obvoius to unbreak
> > bootstrap once testing converges. Previously we did not get here wince
> > we got mismatch between TMR type and decl type but same code is present
> > in indirect_ref_may_alias_p.
> >
> > Honza
> >
> > PR bootstrap/90873
> > * tree-ssa-alias.c (indirect_ref_may_alias_decl_p): Also check that
> > dbase is not TARGET_MEM_REF.
> 
> I've included the patch in nightly bootstraps on i386-pc-solaris2.11,
> sparc-sun-solaris2.11, and i686-pc-linux-gnu.  All completed without
> regressions, thanks.
> 
> One last issue, though.  The error messages totally feel like line noise
> to me:
> 
> /vol/gcc/src/hg/trunk/local/gcc/tree-ssa-forwprop.c: In function 'bool 
> simplify_rotate(gimple_stmt_iterator*)':
> /vol/gcc/src/hg/trunk/local/gcc/tree-ssa-forwprop.c:1650:40: error: 
> '#'target_mem_ref' not supported by dump_expr#' may be used 
> uninitialized in this function [-Werror=maybe-uninitialized]
>  1650 |  if (cdef_arg2[i] == def_arg2[1 - i]
>   |  ~~^
> 
> Is this really something we mean to expose to users?

No, I think we should have PR on this.  I am not sure why late
uninitialized warnings runs after ivopts which is the place we introduce
TMR.

Honza

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


Remove nonoverlapping_component_refs_of_decl_p

2019-06-14 Thread Jan Hubicka
Hi,
this patch removes nonoverlapping_component_refs_of_decl_p and replaces
it by nonoverlapping_component_refs_p. Those functions are basically
equivalent, however the first assumes that the outer type of memory access
is type of decl which is not true in the gimple memory model.

nonoverlapping_component_refs_p may wind up more expensive by doing
quick sort.  If the outer types match, we could use the same walk as in
nonoverlapping_component_refs_of_decl_p (and I can easilly implement it
in there saing some qsort for the indirect oracles too) but since
nonoverlapping_component_refs_p already handles common case of shallow
access paths and does not show in profiles I am not convinced it is
worth the code duplication.

I think the oracle is mostly redudnant with aliasing_component_refs - in fact I
have troubles constructing testcases it would catch that the second would not
except for expliting the -1 corner cases of same_types_for_tbaa, so I decided
to leave this for later.  The only case where this function is stronger is the
case of match of types in the middle of access path. This require some
non-const indexed array refs to exploit it.  Perhaps we could integrate both
tests and do nonoverlapping_component_refs_p only if one of many handled
components walks we do earlier concludes that it has chance to suceed.

Point of this patch is however to fix the code duplication and also add
missing checks for view converts - I don't see how it would be safe to use
the access paths here when it is not in the other two oracles.

I implemented assert checking that whenever 
nonoverlapping_component_refs_of_decl_p
so does nonoverlapping_component_refs_p and found two issues:
 1) the first does not give up seeing handled component that is not
COMPONENT_REF while other does.
This prevents it to disambiguate for example
foo.bar.array[1];
from
foo.baz.array[1];
where bar and baz are fields of structure foo. This is valid
 2) It gives up upon seeing bitfield while it may disambiguate later in the
patch like.
foo.bar.bitfield1;
from
foo.baz.bitfield2;

Here we can not tell that bitfield1 is different from bitfield2 (at least
we do not do so currently claiming that it is not different for RTL, but
I think in that case we should not see bitfield in the access path)
but we can still disambiguate based on bar/baz.

Patch changes
Alias oracle query stats:   

 refs_may_alias_p: 3021539 disambiguations, 3321136 queries 

ref_maybe_used_by_call_p: 7118 disambiguations, 
3047133 queries 
   call_may_clobber_ref_p: 817 
disambiguations, 817 queries
   
aliasing_component_ref_p: 2050 disambiguations, 19908 queries   

   TBAA oracle: 1419961 disambiguations 2916692 queries 

   555158 are in alias set 0

  575103 queries asked 
about the same object   
  0 
queries asked about the same alias set  

 0 access volatile  

252874 are dependent in the DAG 

   113596 are aritificially in conflict 
with void *

to

Alias oracle query stats:
  refs_may_alias_p: 3021521 disambiguations, 3321121 queries
  ref_maybe_used_by_call_p: 7118 disambiguations, 3047115 queries
  call_may_clobber_ref_p: 817 disambiguations, 817 queries
  nonoverlapping_component_refs_p: 25 disambiguations, 83528 queries
  aliasing_component_refs_p: 2050 disambiguations, 19908 queries
  TBAA oracle: 1419961 disambiguations 2916690 queries
   555158 are in alias set 0
   575103 queries asked about the same object
   0 queries asked about the same alias set
   0

Re: [PATCH] include MEM_REF type in tree dumps (PR 90676)

2019-06-14 Thread Jan Hubicka
> > > Aah, it's two REFs in one.  I misread the array index as being
> > > a part of the MEM_REF operand, like this:
> > >
> > >   MEM  [((int *)&i)[j_1(D)]] = 1;
> > >
> > > I guess I've never noticed this before.  Why is the whole thing
> > > not simplified to an ARRAY_REF?
> > >
> > >   i[j_2(D)] = 1;
> >
> > No idea in this case, though of course there can be other cases e.g.
> > where the MEM_REF has different number of elements, different element type
> > etc. from the underlying variable or where the MEM_REF first operand is not
> > address, but pointer.
> 
> We elide the MEM_REF only if the TBAA type exactly matches the value-type.
> Since TBAA-wise an array is the same as the element type (unless the
> language says otherwise - see get_alias_set) we could in some cases with
> arrays elide it.  It didn't seem worth the extra complexity in the code doing
> this, see maybe_canonicalize_mem_ref_addr.  Honza is at the moment
> trying to improve access-path disambiguation which runs into related issues.

I have just sent an email with some analysis running into it on vect
testcase.  I think we ought to solve this - it seems to be relatively
common case and my proposed patch makes it worse (and I think for valid
reasons)

Honza
> 
> Richard.
> 
> > Jakub


[PATCH][TESTSUITE] Add effective target keyword to check for 64-bit long long

2019-06-14 Thread Jozef Lawrynowicz
For tests that specifically require 64-bit long long, it would be useful to
check this is supported with an effective target keyword.
Currently it appears that either overly-restrictive effective target keywords
such as int32plus are used, or code is guarded at runtime by checking
sizeof(long long).
The attached patch adds the "longlong64" effective target keyword, which
only checks that sizeof(long long) == 8.

Ok for trunk?
>From b89d7957b2265b1f30166d35685236a3db8752eb Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz 
Date: Fri, 14 Jun 2019 09:54:00 +0100
Subject: [PATCH] Add DejaGNU effective target keyword to check for 64-bit long
 long

gcc/ChangeLog:

2019-06-14  Jozef Lawrynowicz  

	* doc/sourcebuild.texi: Document new effective target keyword
	longlong64.

gcc/testsuite/ChangeLog:

2019-06-14  Jozef Lawrynowicz  

	* lib/target-supports.exp: Add check_effective_target_longlong64. 
---
 gcc/doc/sourcebuild.texi  | 3 +++
 gcc/testsuite/lib/target-supports.exp | 9 +
 2 files changed, 12 insertions(+)

diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
index 546af7f7261..85efadb3ca1 100644
--- a/gcc/doc/sourcebuild.texi
+++ b/gcc/doc/sourcebuild.texi
@@ -1357,6 +1357,9 @@ Target has @code{int} that is at 32 bits or longer.
 @item int16
 Target has @code{int} that is 16 bits or shorter.
 
+@item longlong64
+Target has 64-bit @code{long long}.
+
 @item long_neq_int
 Target has @code{int} and @code{long} with different sizes.
 
diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index 01472879062..1d4aaa2a87e 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -2617,6 +2617,15 @@ proc check_effective_target_int32plus { } {
 }]
 }
 
+# Return 1 if we're generating 64-bit long long using default options,
+# 0 otherwise.
+
+proc check_effective_target_longlong64 { } {
+return [check_no_compiler_messages longlong64 object {
+	int dummy[sizeof (long long) == 8 ? 1 : -1];
+}]
+}
+
 # Return 1 if we're generating 32-bit or larger pointers using default
 # options, 0 otherwise.
 
-- 
2.17.1



Re: Use ODR for canonical types construction in LTO

2019-06-14 Thread Jan Hubicka
>   * alias.c (record_component_aliases): Honor odr_based_tbaa_p.
>   * ipa-devirt.c (odr_type_d): Add tbaa_enabled field.
>   (get_odr_type): Return NULL when odr_type_hash is NULL.
>   (enable_odr_based_tbaa): New function.
>   (odr_based_tbaa_p): New function.
>   (set_type_canonical_for_odr_type): New function.
>   * ipa-utils.h (enable_odr_based_tbaa, odr_based_tbaa_p,
>   set_type_canonical_for_odr_type): Declare.
>   * lto-common.c: Update copyright; include tree-pretty-print.h.
>   (types_to_register): New static var.
>   (iterative_hash_canonical_type): Add new parameter INSERT.
>   (hash_canonical_type): Likewise.
>   (lookup_canonical_type): New function.
>   (lto_register_canonical_types_for_odr_types): New.
>   (odr_or_derived_type_p): New function.
>   (lto_read_decls): Deffer ODR and ODR derived types
>   to later canonical type calculation.
>   * tree.c (gimple_canonical_types_compatible_p): Honnor
>   odr_based_tbaa_p.

Ping.  This patch improves TBAA for C++ code bases relatively
noticeably...

Honza


[PATCH] libgfortran: Use __builtin_mul_overflow in xmallocarray

2019-06-14 Thread Janne Blomqvist
As GCC now provides builtins for doing integer overflow checking, lets
use it when checking for overflow in xmallocarray.

Regtested on x86_64-pc-linux-gnu, Ok for trunk?

libgfortran/ChangeLog:

2019-06-14  Janne Blomqvist  

* runtime/memory.c (SIZE_MAX):Remove macro definition.
(xmallocarray): Use __builtin_mul_overflow.
---
 libgfortran/runtime/memory.c | 13 -
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/libgfortran/runtime/memory.c b/libgfortran/runtime/memory.c
index 1a3d33b59dd..09a4ff8733f 100644
--- a/libgfortran/runtime/memory.c
+++ b/libgfortran/runtime/memory.c
@@ -26,10 +26,6 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If 
not, see
 #include "libgfortran.h"
 #include 
 
-#ifndef SIZE_MAX
-#define SIZE_MAX ((size_t)-1)
-#endif
-
 
 void *
 xmalloc (size_t n)
@@ -52,18 +48,17 @@ void *
 xmallocarray (size_t nmemb, size_t size)
 {
   void *p;
+  size_t prod;
 
   if (!nmemb || !size)
-size = nmemb = 1;
-#define HALF_SIZE_T (((size_t) 1) << (__CHAR_BIT__ * sizeof (size_t) / 2))
-  else if (__builtin_expect ((nmemb | size) >= HALF_SIZE_T, 0)
-  && nmemb > SIZE_MAX / size)
+prod = 1;
+  else if (__builtin_mul_overflow (nmemb, size, &prod))
 {
   errno = ENOMEM;
   os_error ("Integer overflow in xmallocarray");
 }
 
-  p = malloc (nmemb * size);
+  p = malloc (prod);
 
   if (!p)
 os_error ("Memory allocation failed in xmallocarray");
-- 
2.17.1



Re: Remove nonoverlapping_component_refs_of_decl_p

2019-06-14 Thread Richard Biener
On Fri, 14 Jun 2019, Jan Hubicka wrote:

> Hi,
> this patch removes nonoverlapping_component_refs_of_decl_p and replaces
> it by nonoverlapping_component_refs_p. Those functions are basically
> equivalent, however the first assumes that the outer type of memory access
> is type of decl which is not true in the gimple memory model.
> 
> nonoverlapping_component_refs_p may wind up more expensive by doing
> quick sort.  If the outer types match, we could use the same walk as in
> nonoverlapping_component_refs_of_decl_p (and I can easilly implement it
> in there saing some qsort for the indirect oracles too) but since
> nonoverlapping_component_refs_p already handles common case of shallow
> access paths and does not show in profiles I am not convinced it is
> worth the code duplication.
> 
> I think the oracle is mostly redudnant with aliasing_component_refs - in fact 
> I
> have troubles constructing testcases it would catch that the second would not
> except for expliting the -1 corner cases of same_types_for_tbaa, so I decided
> to leave this for later.  The only case where this function is stronger is the
> case of match of types in the middle of access path. This require some
> non-const indexed array refs to exploit it.  Perhaps we could integrate both
> tests and do nonoverlapping_component_refs_p only if one of many handled
> components walks we do earlier concludes that it has chance to suceed.
> 
> Point of this patch is however to fix the code duplication and also add
> missing checks for view converts - I don't see how it would be safe to use
> the access paths here when it is not in the other two oracles.

nonoverlapping_component_refs_of_decl_p was added by Eric before
I moved nonoverlapping_component_refs_p from RTL to trees.  It's
nice to see them merged.

Still I'd like to see it done in two steps, first making them
more equivalent by adding missing checks, best with actually
failing testcases (as said, GIMPLE testcases with arbitrary
typed/TBAAed accesses are easy to write but even a C testcase
should eventually work here).

> I implemented assert checking that whenever 
> nonoverlapping_component_refs_of_decl_p
> so does nonoverlapping_component_refs_p and found two issues:
>  1) the first does not give up seeing handled component that is not
> COMPONENT_REF while other does.
> This prevents it to disambiguate for example
> foo.bar.array[1];
> from
> foo.baz.array[1];
> where bar and baz are fields of structure foo. This is valid

True.  Copied from the RTL routine ;)

>  2) It gives up upon seeing bitfield while it may disambiguate later in the
> patch like.
> foo.bar.bitfield1;
> from
> foo.baz.bitfield2;

Not sure, it should first see bar/baz and disambiguate on that.

> 
> Here we can not tell that bitfield1 is different from bitfield2 (at least
> we do not do so currently claiming that it is not different for RTL, but
> I think in that case we should not see bitfield in the access path)

We do - this was added for actual miscompiles.  We could of course make
sure to strip components from MEM_EXPRs.  This is all about RTL
memory accesses being byte-granular while the GIMPLE alias oracle
doing bit-granular disambiguations so the check is also on the
conservative side.

> but we can still disambiguate based on bar/baz.

And we already should?

Note nonoverlapping_component_refs_of_decl_p is quite cheap
compared to nonoverlapping_component_refs_p (which at least is
no longer quadratic as it was in the RTL implementation).
As you said it has several correctness issues (explicit
VIEW_CONVERT_EXPR also comes to my mind here).

> Patch changes
> Alias oracle query stats: 
>   
>  refs_may_alias_p: 3021539 disambiguations, 3321136 
> queries   
>   ref_maybe_used_by_call_p: 7118 
> disambiguations, 3047133 queries  
>   
> call_may_clobber_ref_p: 817 disambiguations, 817 queries  
>   
>aliasing_component_ref_p: 2050 disambiguations, 19908 
> queries   
>TBAA oracle: 1419961 
> disambiguations 2916692 queries   
> 
  555158 
are in alias set 0  

575103 queries asked about the sam

Re: Remove nonoverlapping_component_refs_of_decl_p

2019-06-14 Thread Jan Hubicka
> nonoverlapping_component_refs_of_decl_p was added by Eric before
> I moved nonoverlapping_component_refs_p from RTL to trees.  It's
> nice to see them merged.
> 
> Still I'd like to see it done in two steps, first making them
> more equivalent by adding missing checks, best with actually
> failing testcases (as said, GIMPLE testcases with arbitrary
> typed/TBAAed accesses are easy to write but even a C testcase
> should eventually work here).

This is good idea given that the extra view convert checks hit the
problem.  I am going to re-test the part of patch which adds strenghtens
nonoverlapping_component_refs_p.  With testcases I have problem that
those I can write are also handled by access path oracle.  I will try to
dig into this more :)
> 
> > I implemented assert checking that whenever 
> > nonoverlapping_component_refs_of_decl_p
> > so does nonoverlapping_component_refs_p and found two issues:
> >  1) the first does not give up seeing handled component that is not
> > COMPONENT_REF while other does.
> > This prevents it to disambiguate for example
> > foo.bar.array[1];
> > from
> > foo.baz.array[1];
> > where bar and baz are fields of structure foo. This is valid
> 
> True.  Copied from the RTL routine ;)
> 
> >  2) It gives up upon seeing bitfield while it may disambiguate later in the
> > patch like.
> > foo.bar.bitfield1;
> > from
> > foo.baz.bitfield2;
> 
> Not sure, it should first see bar/baz and disambiguate on that.

It qsort according to the TYPE_UIDs. Are those guaranteed to be in right
order?
> 
> > 
> > Here we can not tell that bitfield1 is different from bitfield2 (at 
> > least
> > we do not do so currently claiming that it is not different for RTL, but
> > I think in that case we should not see bitfield in the access path)
> 
> We do - this was added for actual miscompiles.  We could of course make
> sure to strip components from MEM_EXPRs.  This is all about RTL
> memory accesses being byte-granular while the GIMPLE alias oracle
> doing bit-granular disambiguations so the check is also on the
> conservative side.
> 
> > but we can still disambiguate based on bar/baz.
> 
> And we already should?
> 
> Note nonoverlapping_component_refs_of_decl_p is quite cheap
> compared to nonoverlapping_component_refs_p (which at least is
> no longer quadratic as it was in the RTL implementation).
> As you said it has several correctness issues (explicit
> VIEW_CONVERT_EXPR also comes to my mind here).

Yes, we could recover the cost by making nonoverlapping_component_refs_p
to do the parallel walk in case outer types are the same as I mentioned.
I can impement that.
> > However in general we could run into this scenario since the type
> > mismatch is a result of forwprop1 handling
> > 
> >   D.2200[_20].t.x = 1.0e+0;
> >   D.2200[_20].t.y = u_13;
> >   D.2200[_20].w.x = x_22;
> >   D.2200[_20].w.y = y_24;
> >   _29 = &D.2200[_20];
> >   _30 = MEM[(const struct B *)_29].t.x;
> >   _34 = MEM[(const struct B *)_29].t.y;
> >   _35 = MEM[(const struct B *)_29].w.x;
> >   _36 = _30 * _35;
> >   _37 = MEM[(const struct B *)_29].w.y;
> > 
> > So if there was outer struct, then the view convert would indeed happen.
> 
> No, a forward propagation should never result in a view-convert
> perceived MEM unless the MEM was already view-converting.  But the
> issue is that the special trick in forwprop that does
> 
>   /* If the RHS is a plain dereference and the value type is the same as
>  that of the pointed-to type of the address we can put the
>  dereferenced address on the RHS preserving the original alias-type.  
> */
> 
> perserves the original alias-type.  It's been too long that I remember
> all the details ;)

I think I understand the code.  Normally if you have

ptr = &foo.bar;
ptr->baz;
and we fold it together, we produce MEM_REF which is based on foo but
offets to bar and from that access path starts.
This is done by the code in forwardprop just preceeding this.

If
ptr = &foo.array[i];
the code fails and we end up constructing MEM_REF with the full access
path that in gimple memory model does not garantee that foo is actually
of type of foo and thus the ptrtype of memory access is just *ptr.

This makes alias oracles to give up.
Either we can delay this folding or we can invent way to represent
folded memory reference preserving the point of access path from which
it is reliable.

> 
> > Any ideas how to solve this? I guess one option would be to delay such lossy
> > forward subtitutions for one of later forwprops/PRE since for most of SSA
> > optimizers the earlier sequence should be transparent enough and there
> > is ahope that one can put constant in.
> 
> As said our notion what is a view-conversion and what not should
> probably allow simple component cases.

Can you be bit more specific? :)

I will break up the patch and start with adding the statistics to both variants
and not giving up on ARRAY_REFs.
Will look int

Re: Use ODR for canonical types construction in LTO

2019-06-14 Thread Richard Biener
On Mon, 3 Jun 2019, Jan Hubicka wrote:

> Hi,
> this patch makes LTO to use ODR names when building canonical types.
> Theoretically this is easy task because every ODR type is unique and
> it is enough to fill in the hash with the ODR names and compare them.
> 
> In reality we want to be more careful and detect situation when non-ODR
> type is structurally equivalent to ODR type so C++ code and non-C++ code
> can co-exist.
> 
> I have implemented it as follows
>  1) at stream in time populate canonical type hash by non-ODR types
> only.  Also register all ODR types into so we detect ODR violations.
>  2) once all streaming is done we process all ODR types, lookup each
> of them in the canonical type hash and if structurally compatible
> type is present default to normal canonical type calculation.
> Otherwise canonical type of ODR type is the prevailing ODR variant.

This sounds sensible, while ...

> Now the problem is that in C++ some structures can be non-ODR. For
> example
> 
> struct A {int a;} a;
> struct {int b;} b;
> 
> Here the second structure has no name and we have no way to tell if it
> is C++ or non-C++ code at LTO time.  I tought that perhaps such conflicts
> would be rare, but in reality most of types conflicts this way
> (C++ FE seems to generate non-ODR types of same strucutre as ODR
> types and they do get streamed, I am looking into this).
> So more careful approach is needed.
> 
> I extende extend step 1 to also postpone types that reffers to ODR types 
> (those
> are known to originate from C++ translation units and do not need to be 
> unified
> by structurally equivalent ODR types).
> 
> This is tested by odr_or_derived_type_p which is kind of hack and perhaps we
> should get around streaming this info somehow (but i would preffer to do that
> incrementally)
> 
> Step 2 remain same.
> Additional step 3 registers all odr derived types into canonical type hash.
> This requires canonical type hash to play well with ODR types (i.e. not
> consider them equivalent based on structural equivalety).
> 
> The decision on whether given type has ODR based canonical
> type is stored in odr_based_tbaa_p and is used
>  1) by gimple_canonical_types_compatible_p so the comparsion is
> behaving well after ODR types are inserted into the hash
>  2) by alias.c to be build more precise alias sets - for ODR types
> it is not necessary to glob pointers into void *.
> There is no need to update canonical type hash since I simply insert
> hash codes of ODR names into canonical type hash cache.

ICK.  Can you please solve the C++ issue differently?  The patch
also seems to do many other things ...

More comments inline.

> 
> LTO linking cc1plus there are 3317 ODR types that gets their own
> canonical type and 876 which have conflict.  For example:
> 
> ODR and non-ODR type conflict: union ssa_name_info_type and union 
> {
>   const void * cv;
>   void * v;
> }
> ODR and non-ODR type conflict: struct ht_identifier and struct 
> {
>   union byte_fail_stack_elt_t * stack;
>   unsigned int size;
>   unsigned int avail;
> }
> ODR and non-ODR type conflict: struct lang_hooks_for_tree_dump and struct 
> {
>   struct demangle_component * left;
>   struct demangle_component * right;
> }
> ODR and non-ODR type conflict: struct call_site_record_d and struct 
> {
>   struct demangle_component * sub;
>   int num;
> }
> 
> etc.
> 
> So mostly random conflict induced by the C compiled liberty and other bits.
> Clearly most common issue is globing of pointers and lack of field names
> which is needed primarily for Fortran and is easy to disable for translation 
> units
> not having Fortran modules in them.
> 
> Canonical type hash stats for cc1plus build:
> 
> [WPA] GIMPLE canonical type table: size 16381, 1590 elements, 6797 searches, 
> 88 collisions (ratio: 0.012947)
> [WPA] GIMPLE canonical type pointer-map: 1590 elements, 15494 searches
> 
> to:
> 
> [WPA] GIMPLE canonical type table: size 16381, 755 elements, 6311 searches, 
> 57 collisions (ratio: 0.009032)
> [WPA] GIMPLE canonical type pointer-map: 755 elements, 15553 searches
> 
> So without patch there are 1590 distinct canonical types, with the patch there
> are 755 non-ODR and 3317 odr types, about 2.5 times more.
> 
> And alias oracle stats for -flto-partition=none cc1plus build:
> 
> Alias oracle query stats:
>   refs_may_alias_p: 39227004 disambiguations, 47344870 queries
>   ref_maybe_used_by_call_p: 57815 disambiguations, 39808081 queries
>   call_may_clobber_ref_p: 5511 disambiguations, 8287 queries
>   aliasing_component_ref_p: 90654 disambiguations, 269895 queries
>   TBAA oracle: 11130153 disambiguations 34368560 queries
>14199938 are in alias set 0
>5193428 queries asked about the same object
>147 queries asked about the same alias set
>0 access volatile
>1665979 are dependent in the DAG
>2178915 are aritificially in conflict with v

Re: Remove nonoverlapping_component_refs_of_decl_p

2019-06-14 Thread Richard Biener
On Fri, 14 Jun 2019, Jan Hubicka wrote:

> > nonoverlapping_component_refs_of_decl_p was added by Eric before
> > I moved nonoverlapping_component_refs_p from RTL to trees.  It's
> > nice to see them merged.
> > 
> > Still I'd like to see it done in two steps, first making them
> > more equivalent by adding missing checks, best with actually
> > failing testcases (as said, GIMPLE testcases with arbitrary
> > typed/TBAAed accesses are easy to write but even a C testcase
> > should eventually work here).
> 
> This is good idea given that the extra view convert checks hit the
> problem.  I am going to re-test the part of patch which adds strenghtens
> nonoverlapping_component_refs_p.  With testcases I have problem that
> those I can write are also handled by access path oracle.  I will try to
> dig into this more :)
> > 
> > > I implemented assert checking that whenever 
> > > nonoverlapping_component_refs_of_decl_p
> > > so does nonoverlapping_component_refs_p and found two issues:
> > >  1) the first does not give up seeing handled component that is not
> > > COMPONENT_REF while other does.
> > > This prevents it to disambiguate for example
> > > foo.bar.array[1];
> > > from
> > > foo.baz.array[1];
> > > where bar and baz are fields of structure foo. This is valid
> > 
> > True.  Copied from the RTL routine ;)
> > 
> > >  2) It gives up upon seeing bitfield while it may disambiguate later in 
> > > the
> > > patch like.
> > > foo.bar.bitfield1;
> > > from
> > > foo.baz.bitfield2;
> > 
> > Not sure, it should first see bar/baz and disambiguate on that.
> 
> It qsort according to the TYPE_UIDs. Are those guaranteed to be in right
> order?

Ah, no, of course not.  I guess the early out here should be a
"ignore this match" instead.

> > 
> > > 
> > > Here we can not tell that bitfield1 is different from bitfield2 (at 
> > > least
> > > we do not do so currently claiming that it is not different for RTL, 
> > > but
> > > I think in that case we should not see bitfield in the access path)
> > 
> > We do - this was added for actual miscompiles.  We could of course make
> > sure to strip components from MEM_EXPRs.  This is all about RTL
> > memory accesses being byte-granular while the GIMPLE alias oracle
> > doing bit-granular disambiguations so the check is also on the
> > conservative side.
> > 
> > > but we can still disambiguate based on bar/baz.
> > 
> > And we already should?
> > 
> > Note nonoverlapping_component_refs_of_decl_p is quite cheap
> > compared to nonoverlapping_component_refs_p (which at least is
> > no longer quadratic as it was in the RTL implementation).
> > As you said it has several correctness issues (explicit
> > VIEW_CONVERT_EXPR also comes to my mind here).
> 
> Yes, we could recover the cost by making nonoverlapping_component_refs_p
> to do the parallel walk in case outer types are the same as I mentioned.
> I can impement that.

Not sure if worth the effort - add some statistics detecting this case
vs. the others.  Limiting the number of components to track would
be better I guess, we size the vec<>s to 16 components so simply
give up after pushing too many?  Again, statistics might be interesting.
But as you say I also never saw this high in the profile...

> > > However in general we could run into this scenario since the type
> > > mismatch is a result of forwprop1 handling
> > > 
> > >   D.2200[_20].t.x = 1.0e+0;
> > >   D.2200[_20].t.y = u_13;
> > >   D.2200[_20].w.x = x_22;
> > >   D.2200[_20].w.y = y_24;
> > >   _29 = &D.2200[_20];
> > >   _30 = MEM[(const struct B *)_29].t.x;
> > >   _34 = MEM[(const struct B *)_29].t.y;
> > >   _35 = MEM[(const struct B *)_29].w.x;
> > >   _36 = _30 * _35;
> > >   _37 = MEM[(const struct B *)_29].w.y;
> > > 
> > > So if there was outer struct, then the view convert would indeed happen.
> > 
> > No, a forward propagation should never result in a view-convert
> > perceived MEM unless the MEM was already view-converting.  But the
> > issue is that the special trick in forwprop that does
> > 
> >   /* If the RHS is a plain dereference and the value type is the same as
> >  that of the pointed-to type of the address we can put the
> >  dereferenced address on the RHS preserving the original 
> > alias-type.  */
> > 
> > perserves the original alias-type.  It's been too long that I remember
> > all the details ;)
> 
> I think I understand the code.  Normally if you have
> 
> ptr = &foo.bar;
> ptr->baz;
> and we fold it together, we produce MEM_REF which is based on foo but
> offets to bar and from that access path starts.
> This is done by the code in forwardprop just preceeding this.
> 
> If
> ptr = &foo.array[i];
> the code fails and we end up constructing MEM_REF with the full access
> path that in gimple memory model does not garantee that foo is actually
> of type of foo and thus the ptrtype of memory access is just *ptr.
> 
> This makes alias oracles to give up.

Yes.

Re: Use ODR for canonical types construction in LTO

2019-06-14 Thread Jan Hubicka
> > Step 2 remain same.
> > Additional step 3 registers all odr derived types into canonical type hash.
> > This requires canonical type hash to play well with ODR types (i.e. not
> > consider them equivalent based on structural equivalety).
> > 
> > The decision on whether given type has ODR based canonical
> > type is stored in odr_based_tbaa_p and is used
> >  1) by gimple_canonical_types_compatible_p so the comparsion is
> > behaving well after ODR types are inserted into the hash
> >  2) by alias.c to be build more precise alias sets - for ODR types
> > it is not necessary to glob pointers into void *.
> > There is no need to update canonical type hash since I simply insert
> > hash codes of ODR names into canonical type hash cache.
> 
> ICK.  Can you please solve the C++ issue differently?  The patch
> also seems to do many other things ...

What do you mean by C++ issue here?  I do not think it is a problem of
C++, but rather how type system work.  It has named
structures/enums/unions and unnamed.  The unnamed ones needs to be
handled same way as canonical type hasing.  For named ones we want to
use type names unless we decide to unify them with types from other
languages that does not do ODR.

So first we figure out what clashes we have and then we insert remaining
types.
> > +   /* LTO non-ODR type merging does not make any difference between 
> > +  component pointer types.  We may have
> > +
> > +  struct foo {int *a;};
> > +
> > +  as TYPE_CANONICAL of 
> > +
> > +  struct bar {float *a;};
> > +
> > +  Because accesses to int * and float * do not alias, we would get
> > +  false negative when accessing the same memory location by
> > +  float ** and bar *. We thus record the canonical type as:
> > +
> > +  struct {void *a;};
> > +
> > +  void * is special cased and works as a universal pointer type.
> > +  Accesses to it conflicts with accesses to any other pointer
> > +  type.  */
> > +   bool void_pointers = in_lto_p
> > +&& (!odr_type_p (type)
> > +|| !odr_based_tbaa_p (type));
> 
> This seems like an independent improvement to me.

Kind of - the way we glob pointers here must match way we glob them
while deciding on canonical types (or we may just do subtypes walk for
every type merged into canonical type to get better info).

So w/o the rest of patch this would be wrong.  But I can do this
incrementaly - first refine canonical types and then refine aliasing
DAG.
> > Index: ipa-devirt.c
> > ===
> > --- ipa-devirt.c(revision 271843)
> > +++ ipa-devirt.c(working copy)
> > @@ -213,6 +213,8 @@ struct GTY(()) odr_type_d
> >bool odr_violated;
> >/* Set when virtual table without RTTI previaled table with.  */
> >bool rtti_broken;
> > +  /* Set when we need to give up on ODR based TBAA info.  */
> > +  bool tbaa_enabled;
> 
> ?

I will fix the comment, used to have disabled flag.
This is about handling structurally equivalent ODR types.
> > @@ -332,10 +337,11 @@ hash_canonical_type (tree type)
> >return hstate.end();
> >  }
> >  
> > -/* Returning a hash value for gimple type TYPE combined with VAL.  */
> > +/* Returning a hash value for gimple type TYPE combined with VAL.
> > +   If INSERT is true possibly insert TYPE to canonical type hash.  */
> >  
> >  static void
> > -iterative_hash_canonical_type (tree type, inchash::hash &hstate)
> > +iterative_hash_canonical_type (tree type, inchash::hash &hstate, bool 
> > insert)
> >  {
> >hashval_t v;
> >  
> > @@ -343,7 +349,7 @@ iterative_hash_canonical_type (tree type
> >type = TYPE_MAIN_VARIANT (type);
> >  
> >if (!canonical_type_used_p (type))
> > -v = hash_canonical_type (type);
> > +v = hash_canonical_type (type, insert);
> >/* An already processed type.  */
> >else if (TYPE_CANONICAL (type))
> >  {
> > @@ -355,9 +361,11 @@ iterative_hash_canonical_type (tree type
> >/* Canonical types should not be able to form SCCs by design, this
> >  recursion is just because we do not register canonical types in
> >  optimal order.  To avoid quadratic behavior also register the
> > -type here.  */
> > -  v = hash_canonical_type (type);
> > -  gimple_register_canonical_type_1 (type, v);
> > +type here.  Do not assign canonical types to ODR types - this
> > +is done later using ODR name hash.  */
> > +  v = hash_canonical_type (type, insert);
> > +  if (insert)
> > +gimple_register_canonical_type_1 (type, v);
> 
> So the comment explains that gimple_register_canonical_type_1 is to
> avoid quadratic behavior for types referenced multiple times.
> You remove this and I see why but I fear this will cause issues.

I was benmarking this on firefox.  Thing is that the hash is not very
large and we do not have that many types even for large programs, so
walking it multiple times does not seem m

Re: Remove nonoverlapping_component_refs_of_decl_p

2019-06-14 Thread Jan Hubicka
Hi,
I am heading to lunch, thanks for all the reviews!
This is the cut down version of patch I am testing and will be back in
about an hour.

Honza

* tree-ssa-alias.c (alias_stats): Add
nonoverlapping_component_refs_p_may_alias,
nonoverlapping_component_refs_p_no_alias,
nonoverlapping_component_refs_of_decl_p_may_alias,
nonoverlapping_component_refs_of_decl_p_no_alias.
(dump_alias_stats): Dump them.
(nonoverlapping_component_refs_of_decl_p): Add stats.
(nonoverlapping_component_refs_p): Add stats; do not stop on first
ARRAY_REF.
Index: tree-ssa-alias.c
===
--- tree-ssa-alias.c(revision 272283)
+++ tree-ssa-alias.c(working copy)
@@ -100,6 +100,10 @@ static struct {
   unsigned HOST_WIDE_INT call_may_clobber_ref_p_no_alias;
   unsigned HOST_WIDE_INT aliasing_component_refs_p_may_alias;
   unsigned HOST_WIDE_INT aliasing_component_refs_p_no_alias;
+  unsigned HOST_WIDE_INT nonoverlapping_component_refs_p_may_alias;
+  unsigned HOST_WIDE_INT nonoverlapping_component_refs_p_no_alias;
+  unsigned HOST_WIDE_INT nonoverlapping_component_refs_of_decl_p_may_alias;
+  unsigned HOST_WIDE_INT nonoverlapping_component_refs_of_decl_p_no_alias;
 } alias_stats;
 
 void
@@ -124,7 +128,19 @@ dump_alias_stats (FILE *s)
   alias_stats.call_may_clobber_ref_p_no_alias,
   alias_stats.call_may_clobber_ref_p_no_alias
   + alias_stats.call_may_clobber_ref_p_may_alias);
-  fprintf (s, "  aliasing_component_ref_p: "
+  fprintf (s, "  nonoverlapping_component_refs_p: "
+  HOST_WIDE_INT_PRINT_DEC" disambiguations, "
+  HOST_WIDE_INT_PRINT_DEC" queries\n",
+  alias_stats.nonoverlapping_component_refs_p_no_alias,
+  alias_stats.nonoverlapping_component_refs_p_no_alias
+  + alias_stats.nonoverlapping_component_refs_p_may_alias);
+  fprintf (s, "  nonoverlapping_component_refs_of_decl_p: "
+  HOST_WIDE_INT_PRINT_DEC" disambiguations, "
+  HOST_WIDE_INT_PRINT_DEC" queries\n",
+  alias_stats.nonoverlapping_component_refs_of_decl_p_no_alias,
+  alias_stats.nonoverlapping_component_refs_of_decl_p_no_alias
+  + alias_stats.nonoverlapping_component_refs_of_decl_p_may_alias);
+  fprintf (s, "  aliasing_component_refs_p: "
   HOST_WIDE_INT_PRINT_DEC" disambiguations, "
   HOST_WIDE_INT_PRINT_DEC" queries\n",
   alias_stats.aliasing_component_refs_p_no_alias,
@@ -1047,7 +1063,10 @@ nonoverlapping_component_refs_of_decl_p
   if (TREE_CODE (ref1) == MEM_REF)
 {
   if (!integer_zerop (TREE_OPERAND (ref1, 1)))
-   return false;
+   {
+ ++alias_stats.nonoverlapping_component_refs_of_decl_p_may_alias;
+ return false;
+   }
   ref1 = TREE_OPERAND (TREE_OPERAND (ref1, 0), 0);
 }
 
@@ -1060,7 +1079,10 @@ nonoverlapping_component_refs_of_decl_p
   if (TREE_CODE (ref2) == MEM_REF)
 {
   if (!integer_zerop (TREE_OPERAND (ref2, 1)))
-   return false;
+   {
+ ++alias_stats.nonoverlapping_component_refs_of_decl_p_may_alias;
+ return false;
+   }
   ref2 = TREE_OPERAND (TREE_OPERAND (ref2, 0), 0);
 }
 
@@ -1080,7 +1102,10 @@ nonoverlapping_component_refs_of_decl_p
   do
{
  if (component_refs1.is_empty ())
-   return false;
+   {
+ ++alias_stats.nonoverlapping_component_refs_of_decl_p_may_alias;
+ return false;
+   }
  ref1 = component_refs1.pop ();
}
   while (!RECORD_OR_UNION_TYPE_P (TREE_TYPE (TREE_OPERAND (ref1, 0;
@@ -1088,7 +1113,10 @@ nonoverlapping_component_refs_of_decl_p
   do
{
  if (component_refs2.is_empty ())
-return false;
+   {
+ ++alias_stats.nonoverlapping_component_refs_of_decl_p_may_alias;
+ return false;
+   }
  ref2 = component_refs2.pop ();
}
   while (!RECORD_OR_UNION_TYPE_P (TREE_TYPE (TREE_OPERAND (ref2, 0;
@@ -1096,7 +1124,10 @@ nonoverlapping_component_refs_of_decl_p
   /* Beware of BIT_FIELD_REF.  */
   if (TREE_CODE (ref1) != COMPONENT_REF
  || TREE_CODE (ref2) != COMPONENT_REF)
-   return false;
+   {
+ ++alias_stats.nonoverlapping_component_refs_of_decl_p_may_alias;
+ return false;
+   }
 
   tree field1 = TREE_OPERAND (ref1, 1);
   tree field2 = TREE_OPERAND (ref2, 1);
@@ -1109,7 +1140,10 @@ nonoverlapping_component_refs_of_decl_p
 
   /* We cannot disambiguate fields in a union or qualified union.  */
   if (type1 != type2 || TREE_CODE (type1) != RECORD_TYPE)
-return false;
+   {
+ ++alias_stats.nonoverlapping_component_refs_of_decl_p_may_alias;
+ return false;
+   }
 
   if (field1 != field2)
{
@@ -1117,15 +1151,23 @@ nonoverlapping_component_refs_of_decl_p
 same.  */
 

[PATCH] Improve loop-distribution pattern detection with reductions in place

2019-06-14 Thread Richard Biener


This improves gcc.dg/tree-ssa/ldist-26.c so that both split loop
parts get the memset recognized.  The patch delays handling of
reductions appearing in all partitions so that builtins can be
properly detected and fixes up by trying to put a non-builtin
partition last and eventually force the last partition to be
not builtin.

Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.

Richard.

2019-06-14  Richard Biener  

* tree-loop-distribution.c (classify_partition): Return
whether a reduction appeared in all partitions and do not
stop builtin detection because of this.
(distribute_loop): Sort a non-builtin partition last if
there's a reduction in all partitions and make sure the
partition prevailing as last is not a builtin.

* gcc.dg/tree-ssa/ldist-26.c: Adjust.

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ldist-26.c 
b/gcc/testsuite/gcc.dg/tree-ssa/ldist-26.c
index 3a698846c89..98450cf8c2b 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/ldist-26.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/ldist-26.c
@@ -31,6 +31,8 @@ int main()
   return 0;
 }
 
-/* { dg-final { scan-tree-dump "distributed: split to 2 loops and 0 library 
calls" "ldist" } } */
-/* { dg-final { scan-tree-dump "distributed: split to 1 loops and 1 library 
calls" "ldist" } } */
-/* { dg-final { scan-tree-dump "generated memset zero" "ldist" } } */
+/* Loop splitting splits the iteration space so we end up with two
+   loops entering loop distribution.  Both should have the b[i] = 0
+   part split out as memset.  */
+/* { dg-final { scan-tree-dump-times "distributed: split to 1 loops and 1 
library calls" 2 "ldist" } } */
+/* { dg-final { scan-tree-dump-times "generated memset zero" 2 "ldist" } } */
diff --git a/gcc/tree-loop-distribution.c b/gcc/tree-loop-distribution.c
index 88f8e7a09d1..3881aaff9e5 100644
--- a/gcc/tree-loop-distribution.c
+++ b/gcc/tree-loop-distribution.c
@@ -1658,9 +1658,11 @@ classify_builtin_ldst (loop_p loop, struct graph *rdg, 
partition *partition,
 
 /* Classifies the builtin kind we can generate for PARTITION of RDG and LOOP.
For the moment we detect memset, memcpy and memmove patterns.  Bitmap
-   STMT_IN_ALL_PARTITIONS contains statements belonging to all partitions.  */
+   STMT_IN_ALL_PARTITIONS contains statements belonging to all partitions.
+   Returns true if there is a reduction in all partitions and we
+   possibly did not mark PARTITION as having one for this reason.  */
 
-static void
+static bool
 classify_partition (loop_p loop, struct graph *rdg, partition *partition,
bitmap stmt_in_all_partitions)
 {
@@ -1688,25 +1690,27 @@ classify_partition (loop_p loop, struct graph *rdg, 
partition *partition,
 to all partitions.  In such case, reduction will be computed
 correctly no matter how partitions are fused/distributed.  */
  if (!bitmap_bit_p (stmt_in_all_partitions, i))
-   {
- partition->reduction_p = true;
- return;
-   }
- has_reduction = true;
+   partition->reduction_p = true;
+ else
+   has_reduction = true;
}
 }
 
+  /* Simple workaround to prevent classifying the partition as builtin
+ if it contains any use outside of loop.  For the case where all
+ partitions have the reduction this simple workaround is delayed
+ to only affect the last partition.  */
+  if (partition->reduction_p)
+ return has_reduction;
+
   /* Perform general partition disqualification for builtins.  */
   if (volatiles_p
-  /* Simple workaround to prevent classifying the partition as builtin
-if it contains any use outside of loop.  */
-  || has_reduction
   || !flag_tree_loop_distribute_patterns)
-return;
+return has_reduction;
 
   /* Find single load/store data references for builtin partition.  */
   if (!find_single_drs (loop, rdg, partition, &single_st, &single_ld))
-return;
+return has_reduction;
 
   partition->loc = gimple_location (DR_STMT (single_st));
 
@@ -1715,6 +1719,7 @@ classify_partition (loop_p loop, struct graph *rdg, 
partition *partition,
 classify_builtin_st (loop, partition, single_st);
   else
 classify_builtin_ldst (loop, rdg, partition, single_st, single_ld);
+  return has_reduction;
 }
 
 /* Returns true when PARTITION1 and PARTITION2 access the same memory
@@ -2782,7 +2787,6 @@ distribute_loop (struct loop *loop, vec stmts,
   ddrs_table = new hash_table (389);
   struct graph *rdg;
   partition *partition;
-  bool any_builtin;
   int i, nbp;
 
   *destroy_p = false;
@@ -2842,10 +2846,12 @@ distribute_loop (struct loop *loop, vec stmts,
   for (i = 1; partitions.iterate (i, &partition); ++i)
 bitmap_and_into (stmt_in_all_partitions, partitions[i]->stmts);
 
-  any_builtin = false;
+  bool any_builtin = false;
+  bool reduction_in_all = false;
   FOR_EACH_VEC_ELT (partitions, i, partition)
 {
-  classify_partition (loop

C++ PATCH for c++/90884 - stray note with -Wctor-dtor-privacy

2019-06-14 Thread Marek Polacek
This patch fixes a naked inform call, resulting in bogus note in the
following testcase, if not compiled with -Wsystem-headers.

Bootstrap/regtest running on x86_64-linux, ok for trunk?

2019-06-14  Marek Polacek  

PR c++/90884 - stray note with -Wctor-dtor-privacy.
* class.c (maybe_warn_about_overly_private_class): Guard the call to
inform.

* g++.dg/warn/ctor-dtor-privacy-4.C: New.
* g++.dg/warn/ctor-dtor-privacy-4.h: New.

diff --git gcc/cp/class.c gcc/cp/class.c
index 4fdb0f328cc..de37e43d04c 100644
--- gcc/cp/class.c
+++ gcc/cp/class.c
@@ -2150,10 +2150,10 @@ maybe_warn_about_overly_private_class (tree t)
 
   if (!nonprivate_ctor)
{
- warning (OPT_Wctor_dtor_privacy,
-  "%q#T only defines private constructors and has no friends",
-  t);
- if (copy_or_move)
+ bool w = warning (OPT_Wctor_dtor_privacy,
+   "%q#T only defines private constructors and has "
+   "no friends", t);
+ if (w && copy_or_move)
inform (DECL_SOURCE_LOCATION (copy_or_move),
"%q#D is public, but requires an existing %q#T object",
copy_or_move, t);
diff --git gcc/testsuite/g++.dg/warn/ctor-dtor-privacy-4.C 
gcc/testsuite/g++.dg/warn/ctor-dtor-privacy-4.C
new file mode 100644
index 000..fcad34e000c
--- /dev/null
+++ gcc/testsuite/g++.dg/warn/ctor-dtor-privacy-4.C
@@ -0,0 +1,5 @@
+// PR c++/90884
+// { dg-options "-Wctor-dtor-privacy" }
+// { dg-prune-output "In file included from" }
+
+#include "ctor-dtor-privacy-4.h"  // { dg-bogus "is public" }
diff --git gcc/testsuite/g++.dg/warn/ctor-dtor-privacy-4.h 
gcc/testsuite/g++.dg/warn/ctor-dtor-privacy-4.h
new file mode 100644
index 000..d67fd26943e
--- /dev/null
+++ gcc/testsuite/g++.dg/warn/ctor-dtor-privacy-4.h
@@ -0,0 +1,7 @@
+#pragma GCC system_header
+
+namespace std {
+struct __nonesuch {
+  __nonesuch(__nonesuch const &);
+};
+} // namespace std


Re: Remove nonoverlapping_component_refs_of_decl_p

2019-06-14 Thread Richard Biener
On Fri, 14 Jun 2019, Jan Hubicka wrote:

> Hi,
> I am heading to lunch, thanks for all the reviews!
> This is the cut down version of patch I am testing and will be back in
> about an hour.
> 
> Honza
> 
>   * tree-ssa-alias.c (alias_stats): Add
>   nonoverlapping_component_refs_p_may_alias,
>   nonoverlapping_component_refs_p_no_alias,
>   nonoverlapping_component_refs_of_decl_p_may_alias,
>   nonoverlapping_component_refs_of_decl_p_no_alias.
>   (dump_alias_stats): Dump them.
>   (nonoverlapping_component_refs_of_decl_p): Add stats.
>   (nonoverlapping_component_refs_p): Add stats; do not stop on first
>   ARRAY_REF.
> Index: tree-ssa-alias.c
> ===
> --- tree-ssa-alias.c  (revision 272283)
> +++ tree-ssa-alias.c  (working copy)
> @@ -100,6 +100,10 @@ static struct {
>unsigned HOST_WIDE_INT call_may_clobber_ref_p_no_alias;
>unsigned HOST_WIDE_INT aliasing_component_refs_p_may_alias;
>unsigned HOST_WIDE_INT aliasing_component_refs_p_no_alias;
> +  unsigned HOST_WIDE_INT nonoverlapping_component_refs_p_may_alias;
> +  unsigned HOST_WIDE_INT nonoverlapping_component_refs_p_no_alias;
> +  unsigned HOST_WIDE_INT nonoverlapping_component_refs_of_decl_p_may_alias;
> +  unsigned HOST_WIDE_INT nonoverlapping_component_refs_of_decl_p_no_alias;
>  } alias_stats;
>  
>  void
> @@ -124,7 +128,19 @@ dump_alias_stats (FILE *s)
>  alias_stats.call_may_clobber_ref_p_no_alias,
>  alias_stats.call_may_clobber_ref_p_no_alias
>  + alias_stats.call_may_clobber_ref_p_may_alias);
> -  fprintf (s, "  aliasing_component_ref_p: "
> +  fprintf (s, "  nonoverlapping_component_refs_p: "
> +HOST_WIDE_INT_PRINT_DEC" disambiguations, "
> +HOST_WIDE_INT_PRINT_DEC" queries\n",
> +alias_stats.nonoverlapping_component_refs_p_no_alias,
> +alias_stats.nonoverlapping_component_refs_p_no_alias
> ++ alias_stats.nonoverlapping_component_refs_p_may_alias);
> +  fprintf (s, "  nonoverlapping_component_refs_of_decl_p: "
> +HOST_WIDE_INT_PRINT_DEC" disambiguations, "
> +HOST_WIDE_INT_PRINT_DEC" queries\n",
> +alias_stats.nonoverlapping_component_refs_of_decl_p_no_alias,
> +alias_stats.nonoverlapping_component_refs_of_decl_p_no_alias
> ++ alias_stats.nonoverlapping_component_refs_of_decl_p_may_alias);
> +  fprintf (s, "  aliasing_component_refs_p: "
>  HOST_WIDE_INT_PRINT_DEC" disambiguations, "
>  HOST_WIDE_INT_PRINT_DEC" queries\n",
>  alias_stats.aliasing_component_refs_p_no_alias,
> @@ -1047,7 +1063,10 @@ nonoverlapping_component_refs_of_decl_p
>if (TREE_CODE (ref1) == MEM_REF)
>  {
>if (!integer_zerop (TREE_OPERAND (ref1, 1)))
> - return false;
> + {
> +   ++alias_stats.nonoverlapping_component_refs_of_decl_p_may_alias;
> +   return false;
> + }
>ref1 = TREE_OPERAND (TREE_OPERAND (ref1, 0), 0);
>  }
>  
> @@ -1060,7 +1079,10 @@ nonoverlapping_component_refs_of_decl_p
>if (TREE_CODE (ref2) == MEM_REF)
>  {
>if (!integer_zerop (TREE_OPERAND (ref2, 1)))
> - return false;
> + {
> +   ++alias_stats.nonoverlapping_component_refs_of_decl_p_may_alias;
> +   return false;
> + }
>ref2 = TREE_OPERAND (TREE_OPERAND (ref2, 0), 0);
>  }
>  
> @@ -1080,7 +1102,10 @@ nonoverlapping_component_refs_of_decl_p
>do
>   {
> if (component_refs1.is_empty ())
> - return false;
> + {
> +   ++alias_stats.nonoverlapping_component_refs_of_decl_p_may_alias;
> +   return false;
> + }
> ref1 = component_refs1.pop ();
>   }
>while (!RECORD_OR_UNION_TYPE_P (TREE_TYPE (TREE_OPERAND (ref1, 0;
> @@ -1088,7 +1113,10 @@ nonoverlapping_component_refs_of_decl_p
>do
>   {
> if (component_refs2.is_empty ())
> -  return false;
> + {
> +   ++alias_stats.nonoverlapping_component_refs_of_decl_p_may_alias;
> +   return false;
> + }
> ref2 = component_refs2.pop ();
>   }
>while (!RECORD_OR_UNION_TYPE_P (TREE_TYPE (TREE_OPERAND (ref2, 0;
> @@ -1096,7 +1124,10 @@ nonoverlapping_component_refs_of_decl_p
>/* Beware of BIT_FIELD_REF.  */
>if (TREE_CODE (ref1) != COMPONENT_REF
> || TREE_CODE (ref2) != COMPONENT_REF)
> - return false;
> + {
> +   ++alias_stats.nonoverlapping_component_refs_of_decl_p_may_alias;
> +   return false;
> + }
>  
>tree field1 = TREE_OPERAND (ref1, 1);
>tree field2 = TREE_OPERAND (ref2, 1);
> @@ -1109,7 +1140,10 @@ nonoverlapping_component_refs_of_decl_p
>  
>/* We cannot disambiguate fields in a union or qualified union.  */
>if (type1 != type2 || TREE_CODE (type1) != RECORD_TYPE)
> -  return false;
> + {
> +   ++alias_stats.nonoverlapping_component_refs_of_decl_p_may_alias;
> +   return fal

Re: [RFC] ARM -mfpu=auto woes

2019-06-14 Thread Richard Earnshaw (lists)
On 13/06/2019 14:00, Alexandre Oliva wrote:
> On Jun 12, 2019, Alexandre Oliva  wrote:
> 
>> I'm looking into a regression between gcc-7 and gcc-8 that causes
>> compilation with -mfloat-abi=hard to fail on arm-eabi with:
> 
>> $ arm-eabi-gcc -c -mfloat-abi=hard t.c
>> cc1: error: -mfloat-abi=hard: selected processor lacks an FPU
> 
>> Per the documentation, -mfpu=auto was supposed to be the default, but
>> the implicit -mcpu=armv7tdmi option from configure_default_options, or
>> the -march=armv4t derived from it, seems to be taken as choosing to
>> disable the fpu.
> 
> Or rather they don't have any fpu-related options, so none of the fpu
> bits are set, and -mfpu=auto thus necessarily resolves to nofp.

Which is correct.  arm7tdmi implements architecture version armv4t, but
floating point wasn't added until armv5t, and in practice, we only
support it from armv5te when extra instructions were added to support
moving double precision values in and out of GP registers.  In practice,
not supporting FP on armv5t is not a real problem as I don't think any
v5t implementations with FP ever got into real products: availability of
FP in hardware did not really become widespread until we reached armv7.

The existing -mfpu support was a complete mess.  The compiler would
accept pretty much anything, even if it was completely meaningless.  You
could target combinations that simply did not exist, or you could
generate code that was sub-optimial simply because you had to specify it
all and specify it correctly in order to get the right output.

It gets worse, because the Arm architecture does not represent a linear
sequence of increasing capabilities.  The m-profile, which was created
around the time of armv7 introduced a new subsetting of the
architecture; and in particular the FP variants of that do not
necessarily support all the instructions that other, earlier FP releases
have.  In particular, it's not uncommon for m-profile cores to only
support single-precision floating-point operations.

When I added the new code I left the old way in, because I didn't want
to unduly break existing users; but neither did I want to leave in the
free-for all that we have today where we simply did things wrong
silently.  So -mfpu=auto uses the internal architectural tables to
validate the options against what is a permitted variant within the
architecture.  You can still generate sub-optimal code in some cases,
but you have to try harder and, most of the time, it will be less
sub-optimal than it was previously.

> 
> What's confusing to me is that specifying -mfpu=vfp is accepted, even
> though -mcpu=arm7tdmi+vfp isn't, and with that, -mfloat-abi=hard goes
> through as before.
> 
> Would it make sense, for backward-compatibility purposes, to implicitly
> enable vfpv2 for -mfpu=auto, even for CPUs not configured as having an
> FP option, when given -mfloat-abi=hard?

No.  If you want backwards compatibility, you can still force a specific
FPU via -mfpu=, but the new way deliberately does not
follow that nightmare.  Note that -mfpu is essentially deprecated now;
new FPU variants will no-longer use it and at some point we will likely
obsolete and then delete it entirely, making -mfpu=auto the one and only
way.

So what you were asking for on the command line was meaningless.  It
went through and generated code, but it targetted a non-existent
architecture and you were hamstringing your code by doing that.  The old
interface would allow you to do that, the new doesn't; but that's not a
bad thing.

> 
> Or is this error introduced in GCC 8.* actually desirable, and requiring
> an explicit override of -mfpu, say =vfpv2 along for -mfloat-abi=hard,
> when the default CPU, e.g. arv7tdmi, doesn't have an FP, something that
> users are expected to do?
> 

Exactly, it's a good thing and was certainly a deliberate part of the
new design.

R.

> Thanks in advance,
> 



Re: [PATCH V4] A jump threading opportunity for condition branch

2019-06-14 Thread Jiufu Guo
Jeff Law  writes:

> On 6/3/19 11:28 PM, Jiufu Guo wrote:
>> 
>> Hi,
>> 
>> This patch implements a new opportunity of jump threading for PR77820.
>> In this optimization, conditional jumps are merged with unconditional
>> jump. And then moving CMP result to GPR is eliminated.
>> 
>> This version is based on the proposal of Richard, Jeff and Andrew on
>> previous versions, and refined to incorporate comments, such as accept
>> the path with single_succ_p (e->src).
>> Thanks for the reviews!
>> 
>> Bootstrapped and tested on powerpc64le, powerpc64 and sh (with help
>> from Jeff) with no regressions (two cases are improved and updated
>> to keep original test coverage) and new testcases are added.
>> Is this ok for trunk?
>> 
>> Example of this opportunity looks like below:
>> 
>>   
>>   p0 = a CMP b
>>   goto ;
>> 
>>   
>>   p1 = c CMP d
>>   goto ;
>> 
>>   
>>   # phi = PHI 
>>   if (phi != 0) goto ; else goto ;
>> 
>> Could be transformed to:
>> 
>>   
>>   p0 = a CMP b
>>   if (p0 != 0) goto ; else goto ;
>> 
>>   
>>   p1 = c CMP d
>>   if (p1 != 0) goto ; else goto ;
>> 
>> 
>> This optimization eliminates:
>> 1. saving CMP result: p0 = a CMP b. 
>> 2. additional CMP on branch: if (phi != 0).
>> 3. converting CMP result if there is phi = (INT) p0 if there is.
>> 
>> Thanks!
>> Jiufu Guo
>> 
>> [gcc]
>> 2019-06-04  Jiufu Guo  
>>  Lijia He  
>> 
>>  PR tree-optimization/77820
>>  * tree-ssa-threadedge.c
>>  (edge_forwards_cmp_to_conditional_jump_through_empty_bb_p): New
>>  function.
>>  (thread_across_edge): Add call to
>>  edge_forwards_cmp_to_conditional_jump_through_empty_bb_p.
>> 
>> [gcc/testsuite]
>> 2019-06-04  Jiufu Guo  
>>  Lijia He  
>> 
>>  PR tree-optimization/77820
>>  * gcc.dg/tree-ssa/phi_on_compare-1.c: New testcase.
>>  * gcc.dg/tree-ssa/phi_on_compare-2.c: New testcase.
>>  * gcc.dg/tree-ssa/phi_on_compare-3.c: New testcase.
>>  * gcc.dg/tree-ssa/phi_on_compare-4.c: New testcase.
>>  * gcc.dg/tree-ssa/split-path-6.c: Update testcase.
>>  * gcc.target/sh/pr51244-20.c: Update testcase.
> Yes, this is OK for the trunk.  I'll commit it momentarily.
Thanks Jeff! I got svn access,  I could commit next time. 
>
> Jeff
>
>
>
>
>> 
>> 
>> ---
>>  gcc/testsuite/gcc.dg/tree-ssa/phi_on_compare-1.c | 30 ++
>>  gcc/testsuite/gcc.dg/tree-ssa/phi_on_compare-2.c | 23 
>>  gcc/testsuite/gcc.dg/tree-ssa/phi_on_compare-3.c | 25 +
>>  gcc/testsuite/gcc.dg/tree-ssa/phi_on_compare-4.c | 40 ++
>>  gcc/testsuite/gcc.dg/tree-ssa/split-path-6.c |  2 +-
>>  gcc/testsuite/gcc.target/sh/pr51244-20.c |  2 +-
>>  gcc/tree-ssa-threadedge.c| 70 
>> +++-
>>  7 files changed, 187 insertions(+), 5 deletions(-)
>>  create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/phi_on_compare-1.c
>>  create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/phi_on_compare-2.c
>>  create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/phi_on_compare-3.c
>>  create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/phi_on_compare-4.c
>> 
>> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/phi_on_compare-1.c 
>> b/gcc/testsuite/gcc.dg/tree-ssa/phi_on_compare-1.c
>> new file mode 100644
>> index 000..5227c87
>> --- /dev/null
>> +++ b/gcc/testsuite/gcc.dg/tree-ssa/phi_on_compare-1.c
>> @@ -0,0 +1,30 @@
>> +/* { dg-do compile } */
>> +/* { dg-options "-Ofast -fdump-tree-vrp1" } */
>> +
>> +void g (int);
>> +void g1 (int);
>> +
>> +void
>> +f (long a, long b, long c, long d, long x)
>> +{
>> +  _Bool t;
>> +  if (x)
>> +{
>> +  g (a + 1);
>> +  t = a < b;
>> +  c = d + x;
>> +}
>> +  else
>> +{
>> +  g (b + 1);
>> +  a = c + d;
>> +  t = c > d;
>> +}
>> +
>> +  if (t)
>> +g1 (c);
>> +
>> +  g (a);
>> +}
>> +
>> +/* { dg-final { scan-tree-dump-times "Removing basic block" 1 "vrp1" } } */
>> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/phi_on_compare-2.c 
>> b/gcc/testsuite/gcc.dg/tree-ssa/phi_on_compare-2.c
>> new file mode 100644
>> index 000..eaf89bb
>> --- /dev/null
>> +++ b/gcc/testsuite/gcc.dg/tree-ssa/phi_on_compare-2.c
>> @@ -0,0 +1,23 @@
>> +/* { dg-do compile } */
>> +/* { dg-options "-Ofast -fdump-tree-vrp1" } */
>> +
>> +void g (void);
>> +void g1 (void);
>> +
>> +void
>> +f (long a, long b, long c, long d, int x)
>> +{
>> +  _Bool t;
>> +  if (x)
>> +t = c < d;
>> +  else
>> +t = a < b;
>> +
>> +  if (t)
>> +{
>> +  g1 ();
>> +  g ();
>> +}
>> +}
>> +
>> +/* { dg-final { scan-tree-dump-times "Removing basic block" 1 "vrp1" } } */
>> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/phi_on_compare-3.c 
>> b/gcc/testsuite/gcc.dg/tree-ssa/phi_on_compare-3.c
>> new file mode 100644
>> index 000..d5a1e0b
>> --- /dev/null
>> +++ b/gcc/testsuite/gcc.dg/tree-ssa/phi_on_compare-3.c
>> @@ -0,0 +1,25 @@
>> +/* { dg-do compile } */
>> +/* { dg-options "-Ofast -fdump-tree-vrp1" } */
>> +
>> +void g (void);
>> +void g1 (void);
>> +
>> +void
>> +

[C++ PATCH] PR c++/85552 - wrong instantiation of dtor for DMI.

2019-06-14 Thread Jason Merrill
The problem here is that when processing direct-initialization of a data
member, we don't need to worry about destruction semantics; that will be
handled in the [cd]tor.  Conveniently, we already have tf_no_cleanup from a
similar fix to new-expressions.

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

* typeck2.c (digest_nsdmi_init): Set tf_no_cleanup for direct-init.
---
 gcc/cp/typeck2.c |  5 +++-
 gcc/testsuite/g++.dg/cpp0x/nsdmi-list5.C | 30 
 gcc/cp/ChangeLog |  5 
 3 files changed, 39 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/nsdmi-list5.C

diff --git a/gcc/cp/typeck2.c b/gcc/cp/typeck2.c
index 0109d6e52f5..e8627dd38c0 100644
--- a/gcc/cp/typeck2.c
+++ b/gcc/cp/typeck2.c
@@ -1309,7 +1309,10 @@ digest_nsdmi_init (tree decl, tree init, tsubst_flags_t 
complain)
   tree type = TREE_TYPE (decl);
   int flags = LOOKUP_IMPLICIT;
   if (DIRECT_LIST_INIT_P (init))
-flags = LOOKUP_NORMAL;
+{
+  flags = LOOKUP_NORMAL;
+  complain |= tf_no_cleanup;
+}
   if (BRACE_ENCLOSED_INITIALIZER_P (init)
   && CP_AGGREGATE_TYPE_P (type))
 init = reshape_init (type, init, complain);
diff --git a/gcc/testsuite/g++.dg/cpp0x/nsdmi-list5.C 
b/gcc/testsuite/g++.dg/cpp0x/nsdmi-list5.C
new file mode 100644
index 000..a12740b23b0
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/nsdmi-list5.C
@@ -0,0 +1,30 @@
+// PR c++/85552
+// { dg-do compile { target c++11 } }
+
+template
+struct uptr {
+  uptr() { }
+  uptr(void*) { }
+  ~uptr() { static_assert(sizeof(T), "complete type"); }
+};
+
+class S;
+
+class Compiles
+{
+  uptr s;
+};
+
+class DoesntCompile
+{
+  ~DoesntCompile();
+  DoesntCompile();
+
+  uptr s1 { };
+  uptr s2 { nullptr };
+};
+
+int main()
+{
+  return 0;
+}
diff --git a/gcc/cp/ChangeLog b/gcc/cp/ChangeLog
index c6823b57aa7..62e541736ec 100644
--- a/gcc/cp/ChangeLog
+++ b/gcc/cp/ChangeLog
@@ -1,3 +1,8 @@
+2019-06-12  Jason Merrill  
+
+   PR c++/85552 - wrong instantiation of dtor for DMI.
+   * typeck2.c (digest_nsdmi_init): Set tf_no_cleanup for direct-init.
+
 2019-06-13  Paolo Carlini  
 
* decl.c (grokdeclarator): Use id_loc in five additional places

base-commit: 2ab89918e26a3999ec1df110d45464cf7489fe88
-- 
2.20.1



[PATCH] Add __cpp_lib_bind_front macro to header

2019-06-14 Thread Jonathan Wakely

* include/std/version (__cpp_lib_bind_front): Add missing macro.

Tested x86_64-linux, committed to trunk. I'll backport t his to
gcc-9-branch too.


This missing macro was found by the following script I used for
testing an installed compiler:

#!/bin/sh

: ${CXX:=$HOME/gcc/latest/bin/g++}

for dialect in c++ gnu++
do
for i in 98 11 14 17 2a;
do
 echo ===$dialect$i===
 echo '#include ' | $CXX -D_GLIBCXX_VERSION_INCLUDED -E 
-std=$dialect$i -dD -xc++ - | grep '^[[:blank:]]*#[[:blank:]]*define[[:blank:]]*__cpp_' 
| sort -u > /tmp/perfilemacros
 echo '#include ' | $CXX -E -std=$dialect$i -dD -xc++ - | grep 
'^[[:blank:]]*#[[:blank:]]*define[[:blank:]]*__cpp_' | sort -u > /tmp/versionmacros
 diff -up /tmp/perfilemacros /tmp/versionmacros
done
done


commit e3cc480c4e4601ee97baa96d36952331ffc867d4
Author: redi 
Date:   Fri Jun 14 14:03:16 2019 +

Add __cpp_lib_bind_front macro to  header

* include/std/version (__cpp_lib_bind_front): Add missing macro.

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

diff --git a/libstdc++-v3/include/std/version b/libstdc++-v3/include/std/version
index cef4f1f8e9c..e300fc38bc7 100644
--- a/libstdc++-v3/include/std/version
+++ b/libstdc++-v3/include/std/version
@@ -150,6 +150,7 @@
 
 #if __cplusplus > 201703L
 // c++2a
+#define __cpp_lib_bind_front 201902L
 #define __cpp_lib_bounded_array_traits 201902L
 #if __cpp_impl_destroying_delete
 # define __cpp_lib_destroying_delete 201806L


[PATCH] Disable -Wctor-dtor-privacy warnings for some standard types

2019-06-14 Thread Jonathan Wakely

These types are not constructible by design, so we never want warnings
for them, even with -Wsystem-headers.

* include/experimental/type_traits (experimental::nonesuch): Use
pragma to disable -Wctor-dtor-privacy warnings.
* include/std/type_traits (__is_convertible_helper)
(__is_nt_convertible_helper, __nonesuch): Likewise.

Tested x86_64-linux, committed to trunk.


commit bde783a93449ed52ffa301c338b23cd57df0cc77
Author: redi 
Date:   Fri Jun 14 14:03:20 2019 +

Disable -Wctor-dtor-privacy warnings for some standard types

* include/experimental/type_traits (experimental::nonesuch): Use
pragma to disable -Wctor-dtor-privacy warnings.
* include/std/type_traits (__is_convertible_helper)
(__is_nt_convertible_helper, __nonesuch): Likewise.

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

diff --git a/libstdc++-v3/include/experimental/type_traits 
b/libstdc++-v3/include/experimental/type_traits
index 2403bd24223..464c8d2f4bf 100644
--- a/libstdc++-v3/include/experimental/type_traits
+++ b/libstdc++-v3/include/experimental/type_traits
@@ -227,6 +227,8 @@ inline namespace fundamentals_v2
 
 template using void_t = void;
 
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wctor-dtor-privacy"
 struct __nonesuchbase {};
 struct nonesuch : private __nonesuchbase
 {
@@ -234,6 +236,7 @@ struct nonesuch : private __nonesuchbase
   nonesuch(nonesuch const&) = delete;
   void operator=(nonesuch const&) = delete;
 };
+#pragma GCC diagnostic pop
 
 template class _Op, typename... _Args>
   using is_detected
diff --git a/libstdc++-v3/include/std/type_traits 
b/libstdc++-v3/include/std/type_traits
index e53d3c8d535..7d4deb156a1 100644
--- a/libstdc++-v3/include/std/type_traits
+++ b/libstdc++-v3/include/std/type_traits
@@ -1448,6 +1448,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   typedef typename is_void<_To>::type type;
 };
 
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wctor-dtor-privacy"
   template
 class __is_convertible_helper<_From, _To, false>
 {
@@ -1466,7 +1468,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 public:
   typedef decltype(__test<_From, _To>(0)) type;
 };
-
+#pragma GCC diagnostic pop
 
   /// is_convertible
   template
@@ -1481,6 +1483,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 : is_void<_To>
 { };
 
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wctor-dtor-privacy"
   template
 class __is_nt_convertible_helper<_From, _To, false>
 {
@@ -1499,6 +1503,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 public:
   using type = decltype(__test<_From, _To>(0));
 };
+#pragma GCC diagnostic pop
 
   // is_nothrow_convertible for C++11
   template
@@ -2894,12 +2899,15 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  __call_is_nothrow_<_Fn, _Args...>>::type
 { };
 
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wctor-dtor-privacy"
   struct __nonesuchbase {};
   struct __nonesuch : private __nonesuchbase {
 ~__nonesuch() = delete;
 __nonesuch(__nonesuch const&) = delete;
 void operator=(__nonesuch const&) = delete;
   };
+#pragma GCC diagnostic pop
 
 #if __cplusplus >= 201703L
 # define __cpp_lib_is_invocable 201703


Re: [PATCH] netbsd EABI support

2019-06-14 Thread Richard Earnshaw (lists)
On 12/06/2019 17:19, co...@sdf.org wrote:
> I think copyright assignment is done. Thanks for bearing with me.
> 
> I noticed the version I submitted in April is missing some changes we
> discussed on October 2018.
> 
> I took the patch from then and removed -matpcs too, the unnecessary
> change to libgcc t-netbsd (which is the OABI configuration anyway), and
> some whitespace git warned about.
> 
> Added the change to libatomic ifunc usage, since we recently claim ifunc
> support on netbsd.
> (Got lost in https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00290.html -
> that one is my fault for submitting patches badly)
> 
> 
> Matt Thomas 
> matthew green 
> Nick Hudson 
> Maya Rashish 
> 

Thanks.  I've made a couple of minor tweaks and committed the attached.
 Thanks for posting all this and thanks for bearing with us while we
sorted out the copyright issues.

R.

> gcc/ChangeLog:
> 
>   * config.gcc (arm*-*-netbsdelf*) Add support for EABI configuration
>   * config.host (arm*-*-netbsd*): Build driver-arm.o
>   * config/arm/netbsd-eabi.h: New file.
>   * config/arm/netbsd-elf.h: Don't pass -matpcs unconditionally.
>   * config/netbsd-elf.h: Define SUBTARGET_EXTRA_SPECS.
> 
> libgcc/ChangeLog:
> 
>   * config.host (arm*-*-netbsdelf*): Add support for EABI configuration
>   * config/arm/t-netbsd: LIB1ASMFUNCS: Append to existing set.
>HOST_LIBGCC2_CFLAGS: workaround possible bug
>   * config/arm/t-netbsd-eabi: New file.
> 
> libatomic/ChangeLog:
> * configure.tgt: Exclude arm*-*-netbsd* from try_ifunc.
> 
> 
> 
> ---
>  gcc/config.gcc  | 29 +-
>  gcc/config.host |  2 +-
>  gcc/config/arm/netbsd-eabi.h| 97 +
>  gcc/config/arm/netbsd-elf.h |  3 +-
>  gcc/config/netbsd-elf.h | 14 +
>  libatomic/configure.tgt |  2 +-
>  libgcc/config.host  | 11 +++-
>  libgcc/config/arm/t-netbsd  |  8 +++
>  libgcc/config/arm/t-netbsd-eabi | 18 ++
>  9 files changed, 177 insertions(+), 7 deletions(-)
>  create mode 100644 gcc/config/arm/netbsd-eabi.h
>  create mode 100644 libgcc/config/arm/t-netbsd-eabi
> 
> diff --git a/gcc/config.gcc b/gcc/config.gcc
> index 6b00c387247..9fe57f4c7de 100644
> --- a/gcc/config.gcc
> +++ b/gcc/config.gcc
> @@ -1159,10 +1159,33 @@ arm*-*-freebsd*)# ARM FreeBSD EABI
>   with_tls=${with_tls:-gnu}
>   ;;
>  arm*-*-netbsdelf*)
> - tm_file="dbxelf.h elfos.h ${nbsd_tm_file} arm/elf.h arm/aout.h 
> ${tm_file} arm/netbsd-elf.h"
> - extra_options="${extra_options} netbsd.opt netbsd-elf.opt"
> - tmake_file="${tmake_file} arm/t-arm"
>   target_cpu_cname="strongarm"
> + tmake_file="${tmake_file} arm/t-arm"
> + tm_file="dbxelf.h elfos.h ${nbsd_tm_file} arm/elf.h"
> + extra_options="${extra_options} netbsd.opt netbsd-elf.opt"
> + case ${target} in
> + arm*eb-*) tm_defines="${tm_defines} TARGET_BIG_ENDIAN_DEFAULT=1" ;;
> + esac
> + case ${target} in
> + arm*-*-netbsdelf-*eabi*)
> + tm_file="$tm_file arm/bpabi.h arm/netbsd-elf.h arm/netbsd-eabi.h"
> + tmake_file="$tmake_file arm/t-bpabi arm/t-netbsdeabi"
> + ;;
> + *)
> + tm_file="$tm_file arm/netbsd-elf.h"
> + tmake_file="$tmake_file arm/t-netbsd"
> + ;;
> + esac
> + tm_file="${tm_file} arm/aout.h arm/arm.h"
> + case ${target} in
> + arm*-*-netbsdelf-*eabihf*)
> + tm_defines="${tm_defines} 
> TARGET_DEFAULT_FLOAT_ABI=ARM_FLOAT_ABI_HARD"
> + ;;
> + esac
> + case ${target} in
> + armv6*) target_cpu_cname="arm1176jzf-s";;
> + armv7*) target_cpu_cname="generic-armv7-a";;
> + esac
>   ;;
>  arm*-*-linux-*)  # ARM GNU/Linux with ELF
>   tm_file="dbxelf.h elfos.h gnu-user.h linux.h linux-android.h 
> glibc-stdint.h arm/elf.h arm/linux-gas.h arm/linux-elf.h"
> diff --git a/gcc/config.host b/gcc/config.host
> index 2213404dd0e..82409e32f96 100644
> --- a/gcc/config.host
> +++ b/gcc/config.host
> @@ -107,7 +107,7 @@ case ${host} in
>   ;;
>  esac
>  ;;
> -  arm*-*-freebsd* | arm*-*-linux* | arm*-*-fuchsia*)
> +  arm*-*-freebsd* | arm*-*-netbsd* | arm*-*-linux* | arm*-*-fuchsia*)
>  case ${target} in
>arm*-*-*)
>   host_extra_gcc_objs="driver-arm.o"
> diff --git a/gcc/config/arm/netbsd-eabi.h b/gcc/config/arm/netbsd-eabi.h
> new file mode 100644
> index 000..5cbfcc92a59
> --- /dev/null
> +++ b/gcc/config/arm/netbsd-eabi.h
> @@ -0,0 +1,97 @@
> +/* Definitions of target machine for GNU compiler, NetBSD/arm ELF version.
> +   Copyright (C) 2002, 2003, 2004, 2005, 2007 Free Software Foundation, Inc.
> +   Contributed by Wasabi Systems, Inc.
> +
> +   This file is part of GCC.
> +
> +   GCC is free software; you can redistribute it and/or modify it
> +   under the terms of the GNU General Public License as published
> +   by the Free Software Foundation; eith

[PATCH, sanitizer] Wrap rethrow_primary_exception (PR 87880).

2019-06-14 Thread Iain Sandoe
For some Darwin versions the absence of the rethrow_primary_exception
symbol causes almost all sanitizer tests to fail.

The following patch wraps it as suggested by Jakub in the PR trail, such that
if the gate is not defined, it’s assumed to be available.

OK for trunk?
Iain

libsanitizer/

2019-06-14  Iain Sandoe  

PR libsanitizer/87880
* asan/asan_interceptors.h:
(ASAN_INTERCEPT___CXA_RETHROW_PRIMARY_EXCEPTION): New.
* asan/Makefile.am (DEFS): Add 
ASAN_HAS_CXA_RETHROW_PRIMARY_EXCEPTION, defined to 0.
* asan/Makefile.in: Regenerated.

diff --git a/libsanitizer/asan/Makefile.am b/libsanitizer/asan/Makefile.am
index 867240d..b18ab2a 100644
--- a/libsanitizer/asan/Makefile.am
+++ b/libsanitizer/asan/Makefile.am
@@ -3,7 +3,7 @@ AM_CPPFLAGS = -I $(top_srcdir)/include -I $(top_srcdir)
 # May be used by toolexeclibdir.
 gcc_version := $(shell @get_gcc_base_ver@ $(top_srcdir)/../gcc/BASE-VER)
 
-DEFS = -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS 
-D__STDC_LIMIT_MACROS -DASAN_HAS_EXCEPTIONS=1 -DASAN_NEEDS_SEGV=1 
-DCAN_SANITIZE_UB=0
+DEFS = -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS 
-D__STDC_LIMIT_MACROS -DASAN_HAS_EXCEPTIONS=1 -DASAN_NEEDS_SEGV=1 
-DCAN_SANITIZE_UB=0 -DASAN_HAS_CXA_RETHROW_PRIMARY_EXCEPTION=0
 if USING_MAC_INTERPOSE
 DEFS += -DMAC_INTERPOSE_FUNCTIONS -DMISSING_BLOCKS_SUPPORT
 endif
diff --git a/libsanitizer/asan/asan_interceptors.h 
b/libsanitizer/asan/asan_interceptors.h
index b599ebb..beb1dc9 100644
--- a/libsanitizer/asan/asan_interceptors.h
+++ b/libsanitizer/asan/asan_interceptors.h
@@ -79,7 +79,12 @@ void InitializePlatformInterceptors();
 #if ASAN_HAS_EXCEPTIONS && !SANITIZER_WINDOWS && !SANITIZER_SOLARIS && \
 !SANITIZER_NETBSD
 # define ASAN_INTERCEPT___CXA_THROW 1
-# define ASAN_INTERCEPT___CXA_RETHROW_PRIMARY_EXCEPTION 1
+# if ! defined(ASAN_HAS_CXA_RETHROW_PRIMARY_EXCEPTION) \
+ || ASAN_HAS_CXA_RETHROW_PRIMARY_EXCEPTION
+#   define ASAN_INTERCEPT___CXA_RETHROW_PRIMARY_EXCEPTION 1
+# else
+#   define ASAN_INTERCEPT___CXA_RETHROW_PRIMARY_EXCEPTION 0
+# endif
 # if defined(_GLIBCXX_SJLJ_EXCEPTIONS) || (SANITIZER_IOS && defined(__arm__))
 #  define ASAN_INTERCEPT__UNWIND_SJLJ_RAISEEXCEPTION 1
 # else



Re: C++ PATCH for c++/90884 - stray note with -Wctor-dtor-privacy

2019-06-14 Thread Jason Merrill
Ok.

On Fri, Jun 14, 2019, 8:10 AM Marek Polacek  wrote:

> This patch fixes a naked inform call, resulting in bogus note in the
> following testcase, if not compiled with -Wsystem-headers.
>
> Bootstrap/regtest running on x86_64-linux, ok for trunk?
>
> 2019-06-14  Marek Polacek  
>
> PR c++/90884 - stray note with -Wctor-dtor-privacy.
> * class.c (maybe_warn_about_overly_private_class): Guard the call
> to
> inform.
>
> * g++.dg/warn/ctor-dtor-privacy-4.C: New.
> * g++.dg/warn/ctor-dtor-privacy-4.h: New.
>
> diff --git gcc/cp/class.c gcc/cp/class.c
> index 4fdb0f328cc..de37e43d04c 100644
> --- gcc/cp/class.c
> +++ gcc/cp/class.c
> @@ -2150,10 +2150,10 @@ maybe_warn_about_overly_private_class (tree t)
>
>if (!nonprivate_ctor)
> {
> - warning (OPT_Wctor_dtor_privacy,
> -  "%q#T only defines private constructors and has no
> friends",
> -  t);
> - if (copy_or_move)
> + bool w = warning (OPT_Wctor_dtor_privacy,
> +   "%q#T only defines private constructors and
> has "
> +   "no friends", t);
> + if (w && copy_or_move)
> inform (DECL_SOURCE_LOCATION (copy_or_move),
> "%q#D is public, but requires an existing %q#T object",
> copy_or_move, t);
> diff --git gcc/testsuite/g++.dg/warn/ctor-dtor-privacy-4.C
> gcc/testsuite/g++.dg/warn/ctor-dtor-privacy-4.C
> new file mode 100644
> index 000..fcad34e000c
> --- /dev/null
> +++ gcc/testsuite/g++.dg/warn/ctor-dtor-privacy-4.C
> @@ -0,0 +1,5 @@
> +// PR c++/90884
> +// { dg-options "-Wctor-dtor-privacy" }
> +// { dg-prune-output "In file included from" }
> +
> +#include "ctor-dtor-privacy-4.h"  // { dg-bogus "is public" }
> diff --git gcc/testsuite/g++.dg/warn/ctor-dtor-privacy-4.h
> gcc/testsuite/g++.dg/warn/ctor-dtor-privacy-4.h
> new file mode 100644
> index 000..d67fd26943e
> --- /dev/null
> +++ gcc/testsuite/g++.dg/warn/ctor-dtor-privacy-4.h
> @@ -0,0 +1,7 @@
> +#pragma GCC system_header
> +
> +namespace std {
> +struct __nonesuch {
> +  __nonesuch(__nonesuch const &);
> +};
> +} // namespace std
>


Re: [PATCH, sanitizer] Wrap rethrow_primary_exception (PR 87880).

2019-06-14 Thread Jakub Jelinek
On Fri, Jun 14, 2019 at 03:38:05PM +0100, Iain Sandoe wrote:
> For some Darwin versions the absence of the rethrow_primary_exception
> symbol causes almost all sanitizer tests to fail.
> 
> The following patch wraps it as suggested by Jakub in the PR trail, such that
> if the gate is not defined, it’s assumed to be available.

I wonder if we shouldn't bump libasan soname because of this, as this change
is removing an exported symbol from it.

Otherwise LGTM (but bumping soname would mean it is not backportable).

> 2019-06-14  Iain Sandoe  
> 
>   PR libsanitizer/87880
>   * asan/asan_interceptors.h:
>   (ASAN_INTERCEPT___CXA_RETHROW_PRIMARY_EXCEPTION): New.
>   * asan/Makefile.am (DEFS): Add 
>   ASAN_HAS_CXA_RETHROW_PRIMARY_EXCEPTION, defined to 0.
>   * asan/Makefile.in: Regenerated.

Jakub


Re: RFA: Synchronize top level files with binutils

2019-06-14 Thread Richard Earnshaw (lists)
On 10/06/2019 10:47, Nick Clifton wrote:
> Hi Richard,
> 
>   OK, here is a resubmission of my patch with just the addition of the
>   libctf patches this time.  (Sorry about the previous bad patch).
>   Tested with a bootstrap and a normal build.  OK to apply ?
> 
> Cheers
>   Nick

Would it be feasible to backport this to the other maintained branches
so that the option of using them with current binutils would be available?

R.

> 
> 2019-06-07  Nick Clifton  
> 
>   Import these changes from the binutils/gdb repository:
> 
>   2019-05-28  Nick Alcock  
> 
>   * Makefile.def (dependencies): configure-libctf depends on all-bfd
>   and all its deps.
>   * Makefile.in: Regenerated.
> 
>   2019-05-28  Nick Alcock  
> 
>   * Makefile.def (host_modules): Add libctf.
>   * Makefile.def (dependencies): Likewise.
>   libctf depends on zlib, libiberty, and bfd.
>   * Makefile.in: Regenerated.
>   * configure.ac (host_libs): Add libctf.
>   * configure: Regenerated.
> 
> Index: Makefile.def
> ===
> --- Makefile.def  (revision 272111)
> +++ Makefile.def  (working copy)
> @@ -4,7 +4,7 @@
>  // Makefile.in is generated from Makefile.tpl by 'autogen Makefile.def'.
>  // This file was originally written by Nathanael Nerode.
>  //
> -//   Copyright 2002-2013 Free Software Foundation
> +//   Copyright 2002-2019 Free Software Foundation
>  //
>  // This file is free software; you can redistribute it and/or modify
>  // it under the terms of the GNU General Public License as published by
> @@ -128,6 +128,8 @@
>   extra_make_flags='@extra_linker_plugin_flags@'; };
>  host_modules= { module= libcc1; extra_configure_flags=--enable-shared; };
>  host_modules= { module= gotools; };
> +host_modules= { module= libctf; no_install=true; no_check=true;
> + bootstrap=true; };
>  
>  target_modules = { module= libstdc++-v3;
>  bootstrap=true;
> @@ -428,6 +430,7 @@
>  dependencies = { module=all-binutils; on=all-build-bison; };
>  dependencies = { module=all-binutils; on=all-intl; };
>  dependencies = { module=all-binutils; on=all-gas; };
> +dependencies = { module=all-binutils; on=all-libctf; };
>  
>  // We put install-opcodes before install-binutils because the installed
>  // binutils might be on PATH, and they might need the shared opcodes
> @@ -518,6 +521,14 @@
>  dependencies = { module=all-fastjar; on=all-zlib; };
>  dependencies = { module=all-fastjar; on=all-build-texinfo; };
>  dependencies = { module=all-fastjar; on=all-libiberty; };
> +dependencies = { module=all-libctf; on=all-libiberty; hard=true; };
> +dependencies = { module=all-libctf; on=all-bfd; };
> +dependencies = { module=all-libctf; on=all-zlib; };
> +// So that checking for ELF support in BFD from libctf configure is possible.
> +dependencies = { module=configure-libctf; on=all-bfd; };
> +dependencies = { module=configure-libctf; on=all-intl; };
> +dependencies = { module=configure-libctf; on=all-zlib; };
> +dependencies = { module=configure-libctf; on=all-libiconv; };
>  
>  // Warning, these are not well tested.
>  dependencies = { module=all-bison; on=all-intl; };
> Index: configure.ac
> ===
> --- configure.ac  (revision 272111)
> +++ configure.ac  (working copy)
> @@ -131,7 +131,7 @@
>  
>  # these libraries are used by various programs built for the host environment
>  #f
> -host_libs="intl libiberty opcodes bfd readline tcl tk itcl libgui zlib 
> libbacktrace libcpp libdecnumber gmp mpfr mpc isl libelf libiconv"
> +host_libs="intl libiberty opcodes bfd readline tcl tk itcl libgui zlib 
> libbacktrace libcpp libdecnumber gmp mpfr mpc isl libelf libiconv libctf"
>  
>  # these tools are built for the host environment
>  # Note, the powerpc-eabi build depends on sim occurring before gdb in order 
> to
> 



Re: [PATCH] libgfortran: Use __builtin_mul_overflow in xmallocarray

2019-06-14 Thread Steve Kargl
On Fri, Jun 14, 2019 at 01:08:48PM +0300, Janne Blomqvist wrote:
> As GCC now provides builtins for doing integer overflow checking, lets
> use it when checking for overflow in xmallocarray.
> 
> Regtested on x86_64-pc-linux-gnu, Ok for trunk?
> 

OK

-- 
Steve


[PATCH] i386: Update SSE <-> integer move costs

2019-06-14 Thread H.J. Lu
Since inline_secondary_memory_needed has

  /* ??? This is a lie.  We do have moves between mmx/general, and for
 mmx/sse2.  But by saying we need secondary memory we discourage the
 register allocator from using the mmx registers unless needed.  */
  if (MMX_CLASS_P (class1) != MMX_CLASS_P (class2))
return true;

moves between MMX and non-MMX units require secondary memory.   There
is no need to check moves between MMX and integer units.

struct processor_costs has:

  const int mmxsse_to_integer;  /* cost of moving mmxsse register to
   integer.  */
  const int ssemmx_to_integer;  /* cost of moving integer to mmxsse register. */

This patch also renames mmxsse_to_integer to sse_to_integer and
ssemmx_to_integer to integer_to_sse.

Tested on Linux/x86-64.

OK for trunk?

Thanks.

PR target/90877
* config/i386/i386-features.c
(dimode_scalar_chain::compute_convert_gain): Replace
mmxsse_to_integer with sse_to_integer.
* config/i386/i386.c (ix86_register_move_cost): Verify that
moves between MMX and non-MMX units require secondary memory.
Correct costs of moves between SSE and integer units.
* config/i386/i386.h (processor_costs): Rename cost of moving
SSE register to integer to sse_to_integer.  Rename cost of
moving integer register to SSE to integer_to_sse.


-- 
H.J.
From c29a79197696bcd95714e22954e00935b683c209 Mon Sep 17 00:00:00 2001
From: "H.J. Lu" 
Date: Thu, 13 Jun 2019 14:12:25 -0700
Subject: [PATCH] i386: Update SSE <-> integer move costs

Since inline_secondary_memory_needed has

  /* ??? This is a lie.  We do have moves between mmx/general, and for
 mmx/sse2.  But by saying we need secondary memory we discourage the
 register allocator from using the mmx registers unless needed.  */
  if (MMX_CLASS_P (class1) != MMX_CLASS_P (class2))
return true;

moves between MMX and non-MMX units require secondary memory.   There
is no need to check moves between MMX and integer units.

struct processor_costs has:

  const int mmxsse_to_integer;  /* cost of moving mmxsse register to
   integer.  */
  const int ssemmx_to_integer;  /* cost of moving integer to mmxsse register. */

This patch also renames mmxsse_to_integer to sse_to_integer and
ssemmx_to_integer to integer_to_sse.

Tested on Linux/x86-64.

	PR target/90877
	* config/i386/i386-features.c
	(dimode_scalar_chain::compute_convert_gain): Replace
	mmxsse_to_integer with sse_to_integer.
	* config/i386/i386.c (ix86_register_move_cost): Verify that
	moves between MMX and non-MMX units require secondary memory.
	Correct costs of moves between SSE and integer units.
	* config/i386/i386.h (processor_costs): Rename cost of moving
	SSE register to integer to sse_to_integer.  Rename cost of
	moving integer register to SSE to integer_to_sse.
---
 gcc/config/i386/i386-features.c |  2 +-
 gcc/config/i386/i386.c  | 17 ++---
 gcc/config/i386/i386.h  |  5 ++---
 3 files changed, 13 insertions(+), 11 deletions(-)

diff --git a/gcc/config/i386/i386-features.c b/gcc/config/i386/i386-features.c
index 51f88ae4d8a..2eac8f715bb 100644
--- a/gcc/config/i386/i386-features.c
+++ b/gcc/config/i386/i386-features.c
@@ -554,7 +554,7 @@ dimode_scalar_chain::compute_convert_gain ()
 fprintf (dump_file, "  Instruction conversion gain: %d\n", gain);
 
   EXECUTE_IF_SET_IN_BITMAP (defs_conv, 0, insn_uid, bi)
-cost += DF_REG_DEF_COUNT (insn_uid) * ix86_cost->mmxsse_to_integer;
+cost += DF_REG_DEF_COUNT (insn_uid) * ix86_cost->sse_to_integer;
 
   if (dump_file)
 fprintf (dump_file, "  Registers conversion cost: %d\n", cost);
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 2eddea56b2e..941e208bcf0 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -18633,18 +18633,21 @@ ix86_register_move_cost (machine_mode mode, reg_class_t class1_i,
   return cost;
 }
 
-  /* Moves between SSE/MMX and integer unit are expensive.  */
-  if (MMX_CLASS_P (class1) != MMX_CLASS_P (class2)
-  || SSE_CLASS_P (class1) != SSE_CLASS_P (class2))
+  /* Moves between MMX and non-MMX units require secondary memory.  */
+  if (MMX_CLASS_P (class1) != MMX_CLASS_P (class2))
+gcc_unreachable ();
+
+  /* Moves between SSE and integer units are expensive.  */
+  if (SSE_CLASS_P (class1) != SSE_CLASS_P (class2))
 
 /* ??? By keeping returned value relatively high, we limit the number
-   of moves between integer and MMX/SSE registers for all targets.
+   of moves between integer and SSE registers for all targets.
Additionally, high value prevents problem with x86_modes_tieable_p(),
-   where integer modes in MMX/SSE registers are not tieable
+   where integer modes in SSE registers are not tieable
because of missing QImode and HImode moves to, from or between
MMX/SSE registers.  */
-return MAX (8, MMX_CLASS_P (class1) || MMX_CLASS_P (class2)
-		? ix86_cost->mmxsse_to_integer : ix86_cost->ssemmx_to

Re: V3: [PATCH] Update preferred_stack_boundary only when expanding function call

2019-06-14 Thread Richard Sandiford
"H.J. Lu"  writes:
> diff --git a/gcc/calls.c b/gcc/calls.c
> index c8a42680041..6ab138e7bb0 100644
> --- a/gcc/calls.c
> +++ b/gcc/calls.c
> @@ -3226,6 +3226,19 @@ can_implement_as_sibling_call_p (tree exp,
>return true;
>  }
>  
> +/* Update stack alignment when the parameter is passed in the stack
> +   since the outgoing parameter requires extra alignment on the calling
> +   function side. */
> +
> +static void
> +update_stack_alignment_for_call (struct locate_and_pad_arg_data *locate)
> +{
> +  if (crtl->stack_alignment_needed < locate->boundary)
> +crtl->stack_alignment_needed = locate->boundary;
> +  if (crtl->preferred_stack_boundary < locate->boundary)
> +crtl->preferred_stack_boundary = locate->boundary;
> +}
> +
>  /* Generate all the code for a CALL_EXPR exp
> and return an rtx for its value.
> Store the value in TARGET (specified as an rtx) if convenient.
> @@ -3703,6 +3716,12 @@ expand_call (tree exp, rtx target, int ignore)
>/* Ensure current function's preferred stack boundary is at least
>   what we need.  Stack alignment may also increase preferred stack
>   boundary.  */
> +  for (i = 0; i < num_actuals; i++)
> +if (reg_parm_stack_space > 0
> + || args[i].reg == 0
> + || args[i].partial != 0
> + || args[i].pass_on_stack)
> +  update_stack_alignment_for_call (&args[i].locate);
>if (crtl->preferred_stack_boundary < preferred_stack_boundary)
>  crtl->preferred_stack_boundary = preferred_stack_boundary;
>else
> @@ -4961,6 +4980,12 @@ emit_library_call_value_1 (int retval, rtx orgfun, rtx 
> value,
>targetm.calls.function_arg_advance (args_so_far, mode, (tree) 0, true);
>  }
>  
> +  for (int i = 0; i < nargs; i++)
> +if (reg_parm_stack_space > 0
> + || argvec[i].reg == 0
> + || argvec[i].partial != 0)
> +  update_stack_alignment_for_call (&argvec[i].locate);
> +

It's safe to test argvec[i].pass_on_stack here too, since the vector
is initialised to zeros.  So I think we should move the "if"s into the
new function:

static void
update_stack_alignment_for_call (struct locate_and_pad_arg_data *locate)
{
  if (reg_parm_stack_space > 0
  || locate->reg == 0
  || locate->partial != 0
  || locate->pass_on_stack)
{
  if (crtl->stack_alignment_needed < locate->boundary)
crtl->stack_alignment_needed = locate->boundary;
  if (crtl->preferred_stack_boundary < locate->boundary)
crtl->preferred_stack_boundary = locate->boundary;
}
}

OK with that change, thanks.

Richard


Re: [PATCH] i386: Update SSE <-> integer move costs

2019-06-14 Thread Uros Bizjak
On Fri, Jun 14, 2019 at 5:19 PM H.J. Lu  wrote:
>
> Since inline_secondary_memory_needed has
>
>   /* ??? This is a lie.  We do have moves between mmx/general, and for
>  mmx/sse2.  But by saying we need secondary memory we discourage the
>  register allocator from using the mmx registers unless needed.  */
>   if (MMX_CLASS_P (class1) != MMX_CLASS_P (class2))
> return true;
>
> moves between MMX and non-MMX units require secondary memory.   There
> is no need to check moves between MMX and integer units.
>
> struct processor_costs has:
>
>   const int mmxsse_to_integer;  /* cost of moving mmxsse register to
>integer.  */
>   const int ssemmx_to_integer;  /* cost of moving integer to mmxsse register. 
> */
>
> This patch also renames mmxsse_to_integer to sse_to_integer and
> ssemmx_to_integer to integer_to_sse.
>
> Tested on Linux/x86-64.
>
> OK for trunk?
>
> Thanks.
>
> PR target/90877
> * config/i386/i386-features.c
> (dimode_scalar_chain::compute_convert_gain): Replace
> mmxsse_to_integer with sse_to_integer.
> * config/i386/i386.c (ix86_register_move_cost): Verify that
> moves between MMX and non-MMX units require secondary memory.
> Correct costs of moves between SSE and integer units.
> * config/i386/i386.h (processor_costs): Rename cost of moving
> SSE register to integer to sse_to_integer.  Rename cost of
> moving integer register to SSE to integer_to_sse.

OK.

Thanks,
Uros.


[patch][aarch64] add netbsd/aarch64 target

2019-06-14 Thread coypu
Hi folks,

This patch adds support for netbsd/aarch64.
It would be nice to have it committed, please tell me if anything is
wrong.

Thanks.

Matthew Green 
Maya Rashish 

gcc:
* config.gcc (aarch64*-*-netbsd*): New target.
* config/aarch64/aarch64-netbsd.h: New file.
* config/aarch64/t-aarch64-netbsd: Likewise.

libgcc:
* config.host (aarch64*-*-netbsd*): New case.



---
 gcc/config.gcc  |  6 +++
 gcc/config/aarch64/aarch64-netbsd.h | 80 +
 gcc/config/aarch64/t-aarch64-netbsd | 21 
 libgcc/config.host  |  6 +++
 4 files changed, 113 insertions(+)
 create mode 100644 gcc/config/aarch64/aarch64-netbsd.h
 create mode 100644 gcc/config/aarch64/t-aarch64-netbsd

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 0f80e836f4e..678c4ec51a3 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -1021,6 +1021,12 @@ aarch64*-*-freebsd*)
tmake_file="${tmake_file} aarch64/t-aarch64 aarch64/t-aarch64-freebsd"
tm_defines="${tm_defines}  TARGET_DEFAULT_ASYNC_UNWIND_TABLES=1"
;;
+aarch64*-*-netbsd*)
+   tm_file="${tm_file} dbxelf.h elfos.h ${nbsd_tm_file}"
+   tm_file="${tm_file} aarch64/aarch64-elf.h aarch64/aarch64-netbsd.h"
+   tmake_file="${tmake_file} aarch64/t-aarch64 aarch64/t-aarch64-netbsd"
+   extra_options="${extra_options} netbsd.opt netbsd-elf.opt"
+   ;;
 aarch64*-*-linux*)
tm_file="${tm_file} dbxelf.h elfos.h gnu-user.h linux.h glibc-stdint.h"
tm_file="${tm_file} aarch64/aarch64-elf.h aarch64/aarch64-linux.h"
diff --git a/gcc/config/aarch64/aarch64-netbsd.h 
b/gcc/config/aarch64/aarch64-netbsd.h
new file mode 100644
index 000..72fe6a2bdb5
--- /dev/null
+++ b/gcc/config/aarch64/aarch64-netbsd.h
@@ -0,0 +1,80 @@
+/* Definitions for AArch64 running NetBSD
+   Copyright (C) 2016-2019 Free Software Foundation, Inc.
+
+   This file is part of GCC.
+
+   GCC is free software; you can redistribute it and/or modify it
+   under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 3, or (at your option)
+   any later version.
+
+   GCC is distributed in the hope that it will be useful, but
+   WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with GCC; see the file COPYING3.  If not see
+   .  */
+
+#ifndef GCC_AARCH64_NETBSD_H
+#define GCC_AARCH64_NETBSD_H
+
+#define TARGET_LINKER_BIG_EMULATION "aarch64nbsdb"
+#define TARGET_LINKER_LITTLE_EMULATION "aarch64nbsd"
+
+#if TARGET_BIG_ENDIAN_DEFAULT
+#define TARGET_LINKER_EMULATION  TARGET_LINKER_BIG_EMULATION
+#else
+#define TARGET_LINKER_EMULATION  TARGET_LINKER_LITTLE_EMULATION
+#endif
+
+#undef  SUBTARGET_EXTRA_LINK_SPEC
+#define SUBTARGET_EXTRA_LINK_SPEC " -m" TARGET_LINKER_EMULATION
+
+#define NETBSD_ENTRY_POINT "__start"
+
+#define NETBSD_TARGET_LINK_SPEC  "%{h*}\
+   -X %{mbig-endian:-EB -m " TARGET_LINKER_BIG_EMULATION "} \
+   %{mlittle-endian:-EL -m " TARGET_LINKER_LITTLE_EMULATION "} \
+   %(netbsd_link_spec)"
+
+#if TARGET_FIX_ERR_A53_835769_DEFAULT
+#define CA53_ERR_835769_SPEC \
+  " %{!mno-fix-cortex-a53-835769:--fix-cortex-a53-835769}"
+#else
+#define CA53_ERR_835769_SPEC \
+  " %{mfix-cortex-a53-835769:--fix-cortex-a53-835769}"
+#endif
+
+#ifdef TARGET_FIX_ERR_A53_843419_DEFAULT
+#define CA53_ERR_843419_SPEC \
+  " %{!mno-fix-cortex-a53-843419:--fix-cortex-a53-843419}"
+#else
+#define CA53_ERR_843419_SPEC \
+  " %{mfix-cortex-a53-843419:--fix-cortex-a53-843419}"
+#endif
+
+#undef  LINK_SPEC
+#define LINK_SPEC NETBSD_LINK_SPEC_ELF \
+ NETBSD_TARGET_LINK_SPEC   \
+  CA53_ERR_835769_SPEC \
+  CA53_ERR_843419_SPEC
+
+#undef TARGET_OS_CPP_BUILTINS
+#define TARGET_OS_CPP_BUILTINS()   \
+  do   \
+{  \
+  NETBSD_OS_CPP_BUILTINS_ELF();\
+}  \
+  while (0)
+
+#undef SUBTARGET_CPP_SPEC
+#define SUBTARGET_CPP_SPEC NETBSD_CPP_SPEC
+
+#undef EXTRA_SPECS
+#define EXTRA_SPECS \
+  { "asm_cpu_spec", ASM_CPU_SPEC }, \
+  NETBSD_SUBTARGET_EXTRA_SPECS
+
+#endif  /* GCC_AARCH64_NETBSD_H */
diff --git a/gcc/config/aarch64/t-aarch64-netbsd 
b/gcc/config/aarch64/t-aarch64-netbsd
new file mode 100644
index 000..aa447d0f6d4
--- /dev/null
+++ b/gcc/config/aarch64/t-aarch64-netbsd
@@ -0,0 +1,21 @@
+# Machine description for AArch64 architecture.
+#  Copyright (C) 2016-2019 Free Software Foundation, Inc.
+#
+#  This file is part of GCC.
+#
+#  GCC is free software; you can redistribute it and/or modify it
+#  under the terms of the GNU General Public License

[patch] Add NetBSD/hppa target

2019-06-14 Thread coypu
This adds netbsd/hppa support. I tested it on the shiny new QEMU-git
which can now boot NetBSD too :-)

Files are very similar to the linux code.

Please let me know if any changes need to be made.

Matt Thomas 
Nick Hudson 
Matthew Green 
Maya Rashish 

gcc/ChangeLog:
config.gcc (hppa*-*-netbsd*): New target.
config/pa/pa-netbsd.h: New file.
config/pa/pa32-netbsd.h: New file.

libgcc/ChangeLog:
config.host (hppa*-*-netbsd*): New case.
config/pa/t-netbsd: New file.

---
 gcc/config.gcc  |   8 +++
 gcc/config/pa/pa-netbsd.h   | 137 
 gcc/config/pa/pa32-netbsd.h |  37 ++
 libgcc/config.host  |   3 +
 libgcc/config/pa/t-netbsd   |   9 +++
 5 files changed, 194 insertions(+)
 create mode 100644 gcc/config/pa/pa-netbsd.h
 create mode 100644 gcc/config/pa/pa32-netbsd.h
 create mode 100644 libgcc/config/pa/t-netbsd

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 76bb316942d..ba93bb41ec8 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -1481,6 +1481,14 @@ hppa*-*-openbsd*)
gas=yes
gnu_ld=yes
;;
+hppa*-*-netbsd*)
+   target_cpu_default="MASK_PA_11|MASK_NO_SPACE_REGS"
+   tm_file="${tm_file} dbxelf.h elfos.h ${nbsd_tm_file} \
+pa/pa-netbsd.h pa/pa32-regs.h pa/pa32-netbsd.h"
+   tmake_file="${tmake_file}"
+   tm_defines="${tm_defines} CHAR_FAST8=1 SHORT_FAST16=1"
+   extra_options="${extra_options} netbsd.opt netbsd-elf.opt"
+   ;;
 hppa[12]*-*-hpux10*)
case ${target} in
hppa1.1-*-* | hppa2*-*-*)
diff --git a/gcc/config/pa/pa-netbsd.h b/gcc/config/pa/pa-netbsd.h
new file mode 100644
index 000..88790987561
--- /dev/null
+++ b/gcc/config/pa/pa-netbsd.h
@@ -0,0 +1,137 @@
+/* Definitions for PA_RISC with ELF format
+   Copyright (C) 1999-2019 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 3, or (at your option)
+any later version.
+
+GCC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3.  If not see
+.  */
+
+
+#undef TARGET_OS_CPP_BUILTINS
+#define TARGET_OS_CPP_BUILTINS()   \
+  do   \
+{  \
+   NETBSD_OS_CPP_BUILTINS_ELF();   \
+   builtin_assert ("machine=bigendian");   \
+}  \
+  while (0)
+
+#undef CPP_SPEC
+#define CPP_SPEC NETBSD_CPP_SPEC
+
+#undef ASM_SPEC
+#define ASM_SPEC \
+  "%{v:-V} %{n} %{T} %{Ym,*} %{Yd,*} %{Wa,*:%*}"
+
+#undef EXTRA_SPECS
+#define EXTRA_SPECS NETBSD_SUBTARGET_EXTRA_SPECS
+#undef SUBTARGET_EXTRA_SPECS
+
+#define NETBSD_ENTRY_POINT "__start"
+
+#undef LINK_SPEC
+#define LINK_SPEC NETBSD_LINK_SPEC_ELF
+
+/* NetBSD profiling functions don't need gcc to allocate counters.  */
+#define NO_DEFERRED_PROFILE_COUNTERS 1
+
+/* Define the strings used for the special svr4 .type and .size directives.
+   These strings generally do not vary from one system running svr4 to
+   another, but if a given system (e.g. m88k running svr) needs to use
+   different pseudo-op names for these, they may be overridden in the
+   file which includes this one.  */
+
+#undef STRING_ASM_OP
+#define STRING_ASM_OP   "\t.stringz\t"
+
+#define TEXT_SECTION_ASM_OP "\t.text"
+#define DATA_SECTION_ASM_OP "\t.data"
+#define BSS_SECTION_ASM_OP "\t.section\t.bss"
+
+#define TARGET_ASM_FILE_START pa_linux_file_start
+
+/* We want local labels to start with period if made with asm_fprintf.  */
+#undef LOCAL_LABEL_PREFIX
+#define LOCAL_LABEL_PREFIX "."
+
+/* Define these to generate the Linux/ELF/SysV style of internal
+   labels all the time - i.e. to be compatible with
+   ASM_GENERATE_INTERNAL_LABEL in .  Compare these with the
+   ones in pa.h and note the lack of dollar signs in these.  FIXME:
+   shouldn't we fix pa.h to use ASM_GENERATE_INTERNAL_LABEL instead? */
+
+#undef ASM_OUTPUT_ADDR_VEC_ELT
+#define ASM_OUTPUT_ADDR_VEC_ELT(FILE, VALUE) \
+  fprintf (FILE, "\t.word .L%d\n", VALUE)
+
+#undef ASM_OUTPUT_ADDR_DIFF_ELT
+#define ASM_OUTPUT_ADDR_DIFF_ELT(FILE, BODY, VALUE, REL) \
+  fprintf (FILE, "\t.word .L%d-.L%d\n", VALUE, REL)
+
+/* Use the default.  */
+#undef ASM_OUTPUT_LABEL
+
+/* NOTE: (*targetm.asm_out.internal_label)() is defined for us by elfos.h, and
+   does what we want (i.e. uses colons).  It must be compatible with
+   ASM_GENERATE_INTERNAL_LABEL(), so do not define it here.  */
+
+/* Use the default.  */
+#undef ASM_OUTPUT_INTERNAL_LABEL
+
+/* Use the default.  */
+#undef 

Re: V3: [PATCH] Update preferred_stack_boundary only when expanding function call

2019-06-14 Thread H.J. Lu
On Fri, Jun 14, 2019 at 8:31 AM Richard Sandiford
 wrote:
>
> "H.J. Lu"  writes:
> > diff --git a/gcc/calls.c b/gcc/calls.c
> > index c8a42680041..6ab138e7bb0 100644
> > --- a/gcc/calls.c
> > +++ b/gcc/calls.c
> > @@ -3226,6 +3226,19 @@ can_implement_as_sibling_call_p (tree exp,
> >return true;
> >  }
> >
> > +/* Update stack alignment when the parameter is passed in the stack
> > +   since the outgoing parameter requires extra alignment on the calling
> > +   function side. */
> > +
> > +static void
> > +update_stack_alignment_for_call (struct locate_and_pad_arg_data *locate)
> > +{
> > +  if (crtl->stack_alignment_needed < locate->boundary)
> > +crtl->stack_alignment_needed = locate->boundary;
> > +  if (crtl->preferred_stack_boundary < locate->boundary)
> > +crtl->preferred_stack_boundary = locate->boundary;
> > +}
> > +
> >  /* Generate all the code for a CALL_EXPR exp
> > and return an rtx for its value.
> > Store the value in TARGET (specified as an rtx) if convenient.
> > @@ -3703,6 +3716,12 @@ expand_call (tree exp, rtx target, int ignore)
> >/* Ensure current function's preferred stack boundary is at least
> >   what we need.  Stack alignment may also increase preferred stack
> >   boundary.  */
> > +  for (i = 0; i < num_actuals; i++)
> > +if (reg_parm_stack_space > 0
> > + || args[i].reg == 0
> > + || args[i].partial != 0
> > + || args[i].pass_on_stack)
> > +  update_stack_alignment_for_call (&args[i].locate);
> >if (crtl->preferred_stack_boundary < preferred_stack_boundary)
> >  crtl->preferred_stack_boundary = preferred_stack_boundary;
> >else
> > @@ -4961,6 +4980,12 @@ emit_library_call_value_1 (int retval, rtx orgfun, 
> > rtx value,
> >targetm.calls.function_arg_advance (args_so_far, mode, (tree) 0, 
> > true);
> >  }
> >
> > +  for (int i = 0; i < nargs; i++)
> > +if (reg_parm_stack_space > 0
> > + || argvec[i].reg == 0
> > + || argvec[i].partial != 0)
> > +  update_stack_alignment_for_call (&argvec[i].locate);
> > +
>
> It's safe to test argvec[i].pass_on_stack here too, since the vector

There is no pass_on_stack in argvec:

  struct arg
  {
rtx value;
machine_mode mode;
rtx reg;
int partial;
struct locate_and_pad_arg_data locate;
rtx save_area;
  };
  struct arg *argvec;

> is initialised to zeros.  So I think we should move the "if"s into the
> new function:
>
> static void
> update_stack_alignment_for_call (struct locate_and_pad_arg_data *locate)
> {
>   if (reg_parm_stack_space > 0
>   || locate->reg == 0
>   || locate->partial != 0
>   || locate->pass_on_stack)

Since we have

struct locate_and_pad_arg_data
{
  /* Size of this argument on the stack, rounded up for any padding it
 gets.  If REG_PARM_STACK_SPACE is defined, then register parms are
 counted here, otherwise they aren't.  */
  struct args_size size;
  /* Offset of this argument from beginning of stack-args.  */
  struct args_size offset;
  /* Offset to the start of the stack slot.  Different from OFFSET
 if this arg pads downward.  */
  struct args_size slot_offset;
  /* The amount that the stack pointer needs to be adjusted to
 force alignment for the next argument.  */
  struct args_size alignment_pad;
  /* Which way we should pad this arg.  */
  pad_direction where_pad;
  /* slot_offset is at least this aligned.  */
  unsigned int boundary;
};

we can't check reg, partial nor pass_on_stack here.

> {
>   if (crtl->stack_alignment_needed < locate->boundary)
> crtl->stack_alignment_needed = locate->boundary;
>   if (crtl->preferred_stack_boundary < locate->boundary)
> crtl->preferred_stack_boundary = locate->boundary;
> }
> }
>
> OK with that change, thanks.
>

Is my original patch OK?

Thanks.

-- 
H.J.


Re: V3: [PATCH] Update preferred_stack_boundary only when expanding function call

2019-06-14 Thread Richard Sandiford
"H.J. Lu"  writes:
> On Fri, Jun 14, 2019 at 8:31 AM Richard Sandiford
>  wrote:
>>
>> "H.J. Lu"  writes:
>> > diff --git a/gcc/calls.c b/gcc/calls.c
>> > index c8a42680041..6ab138e7bb0 100644
>> > --- a/gcc/calls.c
>> > +++ b/gcc/calls.c
>> > @@ -3226,6 +3226,19 @@ can_implement_as_sibling_call_p (tree exp,
>> >return true;
>> >  }
>> >
>> > +/* Update stack alignment when the parameter is passed in the stack
>> > +   since the outgoing parameter requires extra alignment on the calling
>> > +   function side. */
>> > +
>> > +static void
>> > +update_stack_alignment_for_call (struct locate_and_pad_arg_data *locate)
>> > +{
>> > +  if (crtl->stack_alignment_needed < locate->boundary)
>> > +crtl->stack_alignment_needed = locate->boundary;
>> > +  if (crtl->preferred_stack_boundary < locate->boundary)
>> > +crtl->preferred_stack_boundary = locate->boundary;
>> > +}
>> > +
>> >  /* Generate all the code for a CALL_EXPR exp
>> > and return an rtx for its value.
>> > Store the value in TARGET (specified as an rtx) if convenient.
>> > @@ -3703,6 +3716,12 @@ expand_call (tree exp, rtx target, int ignore)
>> >/* Ensure current function's preferred stack boundary is at least
>> >   what we need.  Stack alignment may also increase preferred stack
>> >   boundary.  */
>> > +  for (i = 0; i < num_actuals; i++)
>> > +if (reg_parm_stack_space > 0
>> > + || args[i].reg == 0
>> > + || args[i].partial != 0
>> > + || args[i].pass_on_stack)
>> > +  update_stack_alignment_for_call (&args[i].locate);
>> >if (crtl->preferred_stack_boundary < preferred_stack_boundary)
>> >  crtl->preferred_stack_boundary = preferred_stack_boundary;
>> >else
>> > @@ -4961,6 +4980,12 @@ emit_library_call_value_1 (int retval, rtx orgfun, 
>> > rtx value,
>> >targetm.calls.function_arg_advance (args_so_far, mode, (tree) 0, 
>> > true);
>> >  }
>> >
>> > +  for (int i = 0; i < nargs; i++)
>> > +if (reg_parm_stack_space > 0
>> > + || argvec[i].reg == 0
>> > + || argvec[i].partial != 0)
>> > +  update_stack_alignment_for_call (&argvec[i].locate);
>> > +
>>
>> It's safe to test argvec[i].pass_on_stack here too, since the vector
>
> There is no pass_on_stack in argvec:
>
>   struct arg
>   {
> rtx value;
> machine_mode mode;
> rtx reg;
> int partial;
> struct locate_and_pad_arg_data locate;
> rtx save_area;
>   };
>   struct arg *argvec;
>
>> is initialised to zeros.  So I think we should move the "if"s into the
>> new function:
>>
>> static void
>> update_stack_alignment_for_call (struct locate_and_pad_arg_data *locate)
>> {
>>   if (reg_parm_stack_space > 0
>>   || locate->reg == 0
>>   || locate->partial != 0
>>   || locate->pass_on_stack)
>
> Since we have
>
> struct locate_and_pad_arg_data
> {
>   /* Size of this argument on the stack, rounded up for any padding it
>  gets.  If REG_PARM_STACK_SPACE is defined, then register parms are
>  counted here, otherwise they aren't.  */
>   struct args_size size;
>   /* Offset of this argument from beginning of stack-args.  */
>   struct args_size offset;
>   /* Offset to the start of the stack slot.  Different from OFFSET
>  if this arg pads downward.  */
>   struct args_size slot_offset;
>   /* The amount that the stack pointer needs to be adjusted to
>  force alignment for the next argument.  */
>   struct args_size alignment_pad;
>   /* Which way we should pad this arg.  */
>   pad_direction where_pad;
>   /* slot_offset is at least this aligned.  */
>   unsigned int boundary;
> };
>
> we can't check reg, partial nor pass_on_stack here.

Sorry, missed that they were different structures.

>> {
>>   if (crtl->stack_alignment_needed < locate->boundary)
>> crtl->stack_alignment_needed = locate->boundary;
>>   if (crtl->preferred_stack_boundary < locate->boundary)
>> crtl->preferred_stack_boundary = locate->boundary;
>> }
>> }
>>
>> OK with that change, thanks.
>>
>
> Is my original patch OK?

Yes, thanks.

Richard


Re: [patch] Add NetBSD/hppa target

2019-06-14 Thread Jeff Law
On 6/14/19 9:44 AM, co...@sdf.org wrote:
> This adds netbsd/hppa support. I tested it on the shiny new QEMU-git
> which can now boot NetBSD too :-)
> 
> Files are very similar to the linux code.
> 
> Please let me know if any changes need to be made.
> 
> Matt Thomas 
> Nick Hudson 
> Matthew Green 
> Maya Rashish 
> 
> gcc/ChangeLog:
>   config.gcc (hppa*-*-netbsd*): New target.
>   config/pa/pa-netbsd.h: New file.
>   config/pa/pa32-netbsd.h: New file.
> 
> libgcc/ChangeLog:
>   config.host (hppa*-*-netbsd*): New case.
>   config/pa/t-netbsd: New file.
> 
> ---
>  gcc/config.gcc  |   8 +++
>  gcc/config/pa/pa-netbsd.h   | 137 
>  gcc/config/pa/pa32-netbsd.h |  37 ++
>  libgcc/config.host  |   3 +
>  libgcc/config/pa/t-netbsd   |   9 +++
>  5 files changed, 194 insertions(+)
>  create mode 100644 gcc/config/pa/pa-netbsd.h
>  create mode 100644 gcc/config/pa/pa32-netbsd.h
>  create mode 100644 libgcc/config/pa/t-netbsd
> 
> diff --git a/gcc/config.gcc b/gcc/config.gcc
> index 76bb316942d..ba93bb41ec8 100644
> --- a/gcc/config.gcc
> +++ b/gcc/config.gcc
> @@ -1481,6 +1481,14 @@ hppa*-*-openbsd*)
>   gas=yes
>   gnu_ld=yes
>   ;;
> +hppa*-*-netbsd*)
> + target_cpu_default="MASK_PA_11|MASK_NO_SPACE_REGS"
Any reason to not use the PA 2.0 ISA?   I'm virtually certain we
supported the 32bit ABI running on PA 2.0 hardware in hpbsd (which is
where the netbsd PA code is ultimately derived from).   I'd be really
surprised if there's any PA1.1 hardware running anywhere, though there's
certainly some PA2.0 hardware out in the wild.




> + tm_file="${tm_file} dbxelf.h elfos.h ${nbsd_tm_file} \
You probably don't need dbxelf.h.  Embedded stabs should be avoided when
it can be.

Jeff


Re: [PATCH] PR fortran/89646 -- suppress spurious warnings

2019-06-14 Thread Janne Blomqvist
On Fri, Jun 14, 2019 at 1:16 AM Steve Kargl
 wrote:
>
> The attached patch suppresses the spurious warnings that
> would otherwise occur for the testcase.  Regression
> tested cleanly on x86_64-*-freebsd.  OK to commit?

Ok, thanks for the patch.

-- 
Janne Blomqvist


Re: [PATCH 3/3] Enable full libgfortran library for AMD GCN

2019-06-14 Thread Janne Blomqvist
On Fri, Jun 7, 2019 at 5:41 PM Andrew Stubbs  wrote:
>
> This patch basically reverts the previous patch to put AMD GCN in
> "minimal" mode.

This is Ok, provided the maintainers for the areas touched by the
other 2 patches in this series Ok those.

Thanks for improving Fortran offloading (given the recent Frontier
supercomputer announcement, I hope we will receive more work in this
area in the future).


-- 
Janne Blomqvist


Re: [PATCH V4] A jump threading opportunity for condition branch

2019-06-14 Thread Jeff Law
On 6/14/19 6:51 AM, Jiufu Guo wrote:
> Jeff Law  writes:
> 
>> On 6/3/19 11:28 PM, Jiufu Guo wrote:
>>>
>>> Hi,
>>>
>>> This patch implements a new opportunity of jump threading for PR77820.
>>> In this optimization, conditional jumps are merged with unconditional
>>> jump. And then moving CMP result to GPR is eliminated.
>>>
>>> This version is based on the proposal of Richard, Jeff and Andrew on
>>> previous versions, and refined to incorporate comments, such as accept
>>> the path with single_succ_p (e->src).
>>> Thanks for the reviews!
>>>
>>> Bootstrapped and tested on powerpc64le, powerpc64 and sh (with help
>>> from Jeff) with no regressions (two cases are improved and updated
>>> to keep original test coverage) and new testcases are added.
>>> Is this ok for trunk?
>>>
>>> Example of this opportunity looks like below:
>>>
>>>   
>>>   p0 = a CMP b
>>>   goto ;
>>>
>>>   
>>>   p1 = c CMP d
>>>   goto ;
>>>
>>>   
>>>   # phi = PHI 
>>>   if (phi != 0) goto ; else goto ;
>>>
>>> Could be transformed to:
>>>
>>>   
>>>   p0 = a CMP b
>>>   if (p0 != 0) goto ; else goto ;
>>>
>>>   
>>>   p1 = c CMP d
>>>   if (p1 != 0) goto ; else goto ;
>>>
>>>
>>> This optimization eliminates:
>>> 1. saving CMP result: p0 = a CMP b. 
>>> 2. additional CMP on branch: if (phi != 0).
>>> 3. converting CMP result if there is phi = (INT) p0 if there is.
>>>
>>> Thanks!
>>> Jiufu Guo
>>>
>>> [gcc]
>>> 2019-06-04  Jiufu Guo  
>>> Lijia He  
>>>
>>> PR tree-optimization/77820
>>> * tree-ssa-threadedge.c
>>> (edge_forwards_cmp_to_conditional_jump_through_empty_bb_p): New
>>> function.
>>> (thread_across_edge): Add call to
>>> edge_forwards_cmp_to_conditional_jump_through_empty_bb_p.
>>>
>>> [gcc/testsuite]
>>> 2019-06-04  Jiufu Guo  
>>> Lijia He  
>>>
>>> PR tree-optimization/77820
>>> * gcc.dg/tree-ssa/phi_on_compare-1.c: New testcase.
>>> * gcc.dg/tree-ssa/phi_on_compare-2.c: New testcase.
>>> * gcc.dg/tree-ssa/phi_on_compare-3.c: New testcase.
>>> * gcc.dg/tree-ssa/phi_on_compare-4.c: New testcase.
>>> * gcc.dg/tree-ssa/split-path-6.c: Update testcase.
>>> * gcc.target/sh/pr51244-20.c: Update testcase.
>> Yes, this is OK for the trunk.  I'll commit it momentarily.
> Thanks Jeff! I got svn access,  I could commit next time. 
Yea, Segher pointed that out to me in IRC.  Looking forward to your next
patchkit :-)

jeff


[RFC] #pragma omp scan inclusive vectorization

2019-06-14 Thread Jakub Jelinek
Hi!

OpenMP 5.0 introduced scan reductions, like:
  #pragma omp simd reduction (inscan, +:r)
  for (int i = 0; i < 1024; i++)
{
  r += a[i];
  #pragma omp scan inclusive(r)
  b[i] = r;
}
where there are 2 parts of code in each iteration, one which is supposed
to compute the value for the privatized reduction variable (the private
copy is initialized with a neutral element of the operation at the
start of that part), and then the #pragma omp scan is supposed to
change that private variable to include (in this case) inclusive partial
sums.  E.g. PSTL we now have in libstdc++-v3/include/pstl/ makes use of
these when available to implement std::*_scan.  It can be done also in
worksharing loops, but I'll get to that later.

Anyway, the problem is that e.g. with OpenMP user defined reductions,
the initializer and combiner of the reduction aren't simple operations
during OpenMP lowering, it can be a method call or constructor call etc.,
so we need something that preserves those initializer and combiner snippets
in the IL for the vectorizer to be able to optimize them if they are
simplified enough, on the other side it needs to be something that the
normal optimizers are able to optimize and that actually works even when
the vectorization isn't performed.

The following (incomplete, but far enough that for non-user defined
reductions it handles the inclusive scan) patch handles that by using
more magic, it adds variants to the .GOMP_SIMD_LANE builtin and uses those,
the old one (0) in the user code, another variant (1) in the initializer
and another variant (2) in the combiner pattern, which the vectorizer then
needs to pattern recognize and either vectorize, or punt on vectorization.
If it vectorizes it, it emits code like (optimized dump):
   [local count: 708669599]:
  # ivtmp.27_45 = PHI <0(4), ivtmp.27_12(5)>
  # D__lsm.39_80 = PHI 
  vect__4.15_49 = MEM[base: a_23(D), index: ivtmp.27_45, offset: 0B];
  _57 = VEC_PERM_EXPR <{ 0, 0, 0, 0, 0, 0, 0, 0 }, vect__4.15_49, { 0, 8, 9, 
10, 11, 12, 13, 14 }>;
  _58 = vect__4.15_49 + _57;
  _59 = VEC_PERM_EXPR <{ 0, 0, 0, 0, 0, 0, 0, 0 }, _58, { 0, 1, 8, 9, 10, 11, 
12, 13 }>;
  _60 = _58 + _59;
  _61 = VEC_PERM_EXPR <{ 0, 0, 0, 0, 0, 0, 0, 0 }, _60, { 0, 1, 2, 3, 8, 9, 10, 
11 }>;
  _62 = _60 + _61;
  _63 = _62 + D__lsm.39_80;
  _64 = VEC_PERM_EXPR <_63, _63, { 7, 7, 7, 7, 7, 7, 7, 7 }>;
  MEM[base: b_32(D), index: ivtmp.27_45, offset: 0B] = _63;
  ivtmp.27_12 = ivtmp.27_45 + 32;
  if (ivtmp.27_12 != 4096)
goto ; [83.33%]
  else
goto ; [16.67%]
where the _57 ... _64 sequence is the implementation of the scan directive.

Does this look reasonable?

BTW, unfortunately SSE2 can't handle these permutations, probably I'll need
optionally some other sequence if they aren't supported (only SSE4 does).
In particular, what could be done is use whole vector shifts and
VEC_COND_EXPR to blend the neutral element in.

--- gcc/tree-vect-stmts.c.jj2019-06-13 13:28:36.636155362 +0200
+++ gcc/tree-vect-stmts.c   2019-06-14 19:05:18.150502242 +0200
@@ -54,6 +54,7 @@ along with GCC; see the file COPYING3.
 #include "tree-ssa-loop-niter.h"
 #include "gimple-fold.h"
 #include "regs.h"
+#include "attribs.h"
 
 /* For lang_hooks.types.type_for_mode.  */
 #include "langhooks.h"
@@ -3257,7 +3258,7 @@ vectorizable_call (stmt_vec_info stmt_in
   if (nargs == 0 || nargs > 4)
 return false;
 
-  /* Ignore the argument of IFN_GOMP_SIMD_LANE, it is magic.  */
+  /* Ignore the arguments of IFN_GOMP_SIMD_LANE, they are magic.  */
   combined_fn cfn = gimple_call_combined_fn (stmt);
   if (cfn == CFN_GOMP_SIMD_LANE)
 {
@@ -6320,6 +6321,456 @@ get_group_alias_ptr_type (stmt_vec_info
 }
 
 
+/* Function check_scan_store.
+
+   Check magic stores for #pragma omp scan {in,ex}clusive reductions.  */
+
+static bool
+check_scan_store (stmt_vec_info stmt_info, tree vectype,
+ enum vect_def_type rhs_dt, bool slp, tree mask,
+ vect_memory_access_type memory_access_type)
+{
+  loop_vec_info loop_vinfo = STMT_VINFO_LOOP_VINFO (stmt_info);
+  dr_vec_info *dr_info = STMT_VINFO_DR_INFO (stmt_info);
+  tree ref_type;
+
+  gcc_assert (STMT_VINFO_SIMD_LANE_ACCESS_P (stmt_info) > 1);
+  if (slp
+  || mask
+  || memory_access_type != VMAT_CONTIGUOUS
+  || TREE_CODE (DR_BASE_ADDRESS (dr_info->dr)) != ADDR_EXPR
+  || !VAR_P (TREE_OPERAND (DR_BASE_ADDRESS (dr_info->dr), 0))
+  || loop_vinfo == NULL
+  || LOOP_VINFO_FULLY_MASKED_P (loop_vinfo)
+  || STMT_VINFO_GROUPED_ACCESS (stmt_info)
+  || !integer_zerop (DR_OFFSET (dr_info->dr))
+  || !integer_zerop (DR_INIT (dr_info->dr))
+  || !(ref_type = reference_alias_ptr_type (DR_REF (dr_info->dr)))
+  || !alias_sets_conflict_p (get_alias_set (vectype),
+get_alias_set (TREE_TYPE (ref_type
+{
+  if (dump_enabled_p ())
+   dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
+"unsupported O

Re: [patch] Add NetBSD/hppa target

2019-06-14 Thread John David Anglin
On 2019-06-14 12:02 p.m., Jeff Law wrote:
>> diff --git a/gcc/config.gcc b/gcc/config.gcc
>> index 76bb316942d..ba93bb41ec8 100644
>> --- a/gcc/config.gcc
>> +++ b/gcc/config.gcc
>> @@ -1481,6 +1481,14 @@ hppa*-*-openbsd*)
>>  gas=yes
>>  gnu_ld=yes
>>  ;;
>> +hppa*-*-netbsd*)
>> +target_cpu_default="MASK_PA_11|MASK_NO_SPACE_REGS"
> Any reason to not use the PA 2.0 ISA?   I'm virtually certain we
> supported the 32bit ABI running on PA 2.0 hardware in hpbsd (which is
> where the netbsd PA code is ultimately derived from).   I'd be really
> surprised if there's any PA1.1 hardware running anywhere, though there's
> certainly some PA2.0 hardware out in the wild.
You might also consider adding MASK_CALLER_COPIES as libgomp is broken for 
callee
copies.  This is an ABI choice so ideally you should do it now or not at all.

Dave

-- 
John David Anglin  dave.ang...@bell.net



Re: [Patch, fortran] PR90577, PR90578 - FAIL: gfortran.dg/lrshift_1.f90 & Wrong code with LSHIFT and optimization

2019-06-14 Thread Harald Anlauf
Committed as svn rev. 272309.

Thanks for the quick review!

Harald

On 06/14/19 00:18, Steve Kargl wrote:
> On Thu, Jun 13, 2019 at 11:50:23PM +0200, Harald Anlauf wrote:
>>
>> it was already discussed in the above PRs that the testcase
>> lrshift_1.f90 needs to be corrected because it invokes negative
>> values of the SHIFT argument.  This is fixed, as well as the
>> related documentation, which did not match e.g. the Fortran standard.
>>
>> Looking closer at the actual implementation, it also turned out that the
>> runtime implementation of SHIFTA/RSHIFT gave different (=wrong) results
>> when SHIFT==BIT_SIZE(arg1).  This is fixed and tested by the attached
>> patches.
>>
>> I did not implement any run-time checks for the SHIFT argument.
>> All previous undefined behavior stays the same.
>>
>> OK for trunk?
>>
>
> Looks good to me.
>



Re: [PATCH][TESTSUITE] Add effective target keyword to check for 64-bit long long

2019-06-14 Thread Jeff Law
On 6/14/19 3:45 AM, Jozef Lawrynowicz wrote:
> For tests that specifically require 64-bit long long, it would be useful to
> check this is supported with an effective target keyword.
> Currently it appears that either overly-restrictive effective target keywords
> such as int32plus are used, or code is guarded at runtime by checking
> sizeof(long long).
> The attached patch adds the "longlong64" effective target keyword, which
> only checks that sizeof(long long) == 8.
> 
> Ok for trunk?
> 
OK
jeff


Re: [PATCH] improve strcmp folding of unequal strings (PR 90626)

2019-06-14 Thread Jeff Law
On 6/13/19 5:50 PM, Martin Sebor wrote:
> While integrating the strlen and sprintf passes and investigating
> optimization opportunities that it opens up I noticed a few related
> to a strcmp optimization implemented in GCC 9.  One is to take
> advantage of the fact that a nul-terminated string of a known
> length cannot be equal to a string whose length is greater, even
> if it isn't known exactly.  For example, the equality below must
> be false:
> 
>   int f (char * restrict a, char * restrict b)
>   {
> memcpy (a, "1234", 4);   // length >= 4
> strcpy (b, "123");   // length == 3
> 
> return strcmp (a, b) == 0;   // must be false
>   }
> 
> The attached patch enhances the existing optimization to exploit
> this opportunity.
> 
> Tested on x86_64-linux.
> 
> Martin
> 
> PS There are several more improvements to be made here.  I've been
> raising bugs for them and I plan to submit patches for them in
> the near future.  (Incidentally, they are all in the spirit of
> the suggestion made back in 2012 in pr52171.)
> 
> gcc-90626.diff
> 
> PR tree-optimization/90626 - fold strcmp(a, b) == 0 to zero when one string 
> length is exact and the other is unequal
> 
> gcc/ChangeLog:
> 
>   PR tree-optimization/90626
>   * tree-ssa-strlen.c (strxcmp_unequal): New function.
>   (handle_builtin_string_cmp): Call it.
> 
> gcc/testsuite/ChangeLog:
> 
>   PR tree-optimization/90626
>   * gcc.dg/strlenopt-65.c: New test.
>   * gcc.dg/strlenopt-66.c: New test.
>   * gcc.dg/strlenopt.h (strcmp, strncmp): Declare.
OK.  Good to see we're able to extend Qing's work to handle more cases
without major surgery.

jeff


Re: [PATCH][openacc] Disable pass_thread_jumps for IFN_UNIQUE

2019-06-14 Thread Jeff Law
On 6/12/19 11:54 AM, Tom de Vries wrote:
> Hi,
> 
> If we compile the openacc testcase with -fopenacc -O2, we run into a SIGSEGV
> or assert.  The root cause for this is that pass_thread_jumps breaks the
> invariant that OACC_FORK and OACC_JOIN mark the start and end of a
> single-entry-single-exit region.
> 
> Fix this by bailing out when encountering an IFN_UNIQUE in
> thread_jumps::profitable_jump_thread_path.
> 
> Bootstrapped and reg-tested on x86_64.
> Build and reg-tested libgomp on x86_64 with nvptx accelerator.
> 
> OK for trunk?
> 
> Thanks,
> - Tom
> 
> [openacc] Disable pass_thread_jumps for IFN_UNIQUE
> 
> 2019-06-12  Tom de Vries  
> 
>   PR tree-optimization/90009
>   * tree-ssa-threadbackward.c (thread_jumps::profitable_jump_thread_path):
>   Return NULL if bb contains IFN_UNIQUE.
> 
>   * testsuite/libgomp.oacc-c-c++-common/pr90009.c: New test.
This really isn't a profitability test, but it's awkward to put the test
in the earlier statement scan.  So OK for the trunk.

jeff


Re: Remove nonoverlapping_component_refs_of_decl_p

2019-06-14 Thread Jan Hubicka
> 
> I think this is still error-prone since we look past
> VIEW_CONVERT_EXPRs in the path so we happily disambiguate,
> say,
> 
> struct X { int e; int d; };
> struct Y { int d; int e; };
> 
>   VIEW_CONVERT(p->b).d
>   VIEW_CONVERT(q->b).e
> 
> where in reality only the access paths from the base up to
> the first view-conversion are relevant for path-based
> analysis.
> 
> So upon seeing a VIEW_CONVERT (or BIT_FIELD_REF which
> has the same issue) simply truncate the vector.
> 
> As said, it's a pre-existing issue but you are extending
> things to possibly handle more stuff...
> 
> Otherwise looks good.
OK, i added the check and also managed to construct testcase that we do
not optimize otherwise.

I think same view convert bug ought to exist also in
aliasing_component_refs_p and IMO ao_ref_alias set should also look
for VCEs otherwise I can't make sense of

  /* First defer to TBAA if possible.  */
  if (tbaa_p
  && flag_strict_aliasing
  && !alias_sets_conflict_p (ao_ref_alias_set (ref1),
 ao_ref_alias_set (ref2)))
return false;

Honza

* gcc.dg/tree-ssa/alias-access-path-2.c: New testcase.

* tree-ssa-alias.c (alias_stats): Add
nonoverlapping_component_refs_p_may_alias,
nonoverlapping_component_refs_p_no_alias,
nonoverlapping_component_refs_of_decl_p_may_alias,
nonoverlapping_component_refs_of_decl_p_no_alias.
(dump_alias_stats): Dump them.
(nonoverlapping_component_refs_of_decl_p): Add stats.
(nonoverlapping_component_refs_p): Add stats; do not stop on first
ARRAY_REF.

Index: testsuite/gcc.dg/tree-ssa/alias-access-path-2.c
===
--- testsuite/gcc.dg/tree-ssa/alias-access-path-2.c (nonexistent)
+++ testsuite/gcc.dg/tree-ssa/alias-access-path-2.c (working copy)
@@ -0,0 +1,22 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-fre3" } */
+struct a {
+  int val;
+};
+struct b {
+  struct a a[10],a2[10];
+};
+struct c {
+  struct b b[10];
+} *cptr;
+
+struct d {struct c c;} *dptr;
+
+int
+test (int i, int j, int k, int l)
+{
+  cptr->b[i].a[j].val=123;
+  dptr->c.b[k].a2[l].val=2;
+  return cptr->b[i].a[j].val;
+}
+/* { dg-final { scan-tree-dump-times "return 123" 1 "fre3"} } */
Index: tree-ssa-alias.c
===
--- tree-ssa-alias.c(revision 272283)
+++ tree-ssa-alias.c(working copy)
@@ -100,6 +100,10 @@ static struct {
   unsigned HOST_WIDE_INT call_may_clobber_ref_p_no_alias;
   unsigned HOST_WIDE_INT aliasing_component_refs_p_may_alias;
   unsigned HOST_WIDE_INT aliasing_component_refs_p_no_alias;
+  unsigned HOST_WIDE_INT nonoverlapping_component_refs_p_may_alias;
+  unsigned HOST_WIDE_INT nonoverlapping_component_refs_p_no_alias;
+  unsigned HOST_WIDE_INT nonoverlapping_component_refs_of_decl_p_may_alias;
+  unsigned HOST_WIDE_INT nonoverlapping_component_refs_of_decl_p_no_alias;
 } alias_stats;
 
 void
@@ -124,7 +128,19 @@ dump_alias_stats (FILE *s)
   alias_stats.call_may_clobber_ref_p_no_alias,
   alias_stats.call_may_clobber_ref_p_no_alias
   + alias_stats.call_may_clobber_ref_p_may_alias);
-  fprintf (s, "  aliasing_component_ref_p: "
+  fprintf (s, "  nonoverlapping_component_refs_p: "
+  HOST_WIDE_INT_PRINT_DEC" disambiguations, "
+  HOST_WIDE_INT_PRINT_DEC" queries\n",
+  alias_stats.nonoverlapping_component_refs_p_no_alias,
+  alias_stats.nonoverlapping_component_refs_p_no_alias
+  + alias_stats.nonoverlapping_component_refs_p_may_alias);
+  fprintf (s, "  nonoverlapping_component_refs_of_decl_p: "
+  HOST_WIDE_INT_PRINT_DEC" disambiguations, "
+  HOST_WIDE_INT_PRINT_DEC" queries\n",
+  alias_stats.nonoverlapping_component_refs_of_decl_p_no_alias,
+  alias_stats.nonoverlapping_component_refs_of_decl_p_no_alias
+  + alias_stats.nonoverlapping_component_refs_of_decl_p_may_alias);
+  fprintf (s, "  aliasing_component_refs_p: "
   HOST_WIDE_INT_PRINT_DEC" disambiguations, "
   HOST_WIDE_INT_PRINT_DEC" queries\n",
   alias_stats.aliasing_component_refs_p_no_alias,
@@ -1047,7 +1063,10 @@ nonoverlapping_component_refs_of_decl_p
   if (TREE_CODE (ref1) == MEM_REF)
 {
   if (!integer_zerop (TREE_OPERAND (ref1, 1)))
-   return false;
+   {
+ ++alias_stats.nonoverlapping_component_refs_of_decl_p_may_alias;
+ return false;
+   }
   ref1 = TREE_OPERAND (TREE_OPERAND (ref1, 0), 0);
 }
 
@@ -1060,7 +1079,10 @@ nonoverlapping_component_refs_of_decl_p
   if (TREE_CODE (ref2) == MEM_REF)
 {
   if (!integer_zerop (TREE_OPERAND (ref2, 1)))
-   return false;
+   {
+ ++alias_stats.nonoverlapping_component_refs_of_decl_p_may_alias;
+ return false;
+   }
   ref2 = TREE_OPERAND (TREE_OPERAND (ref2, 0), 0);
 }
 
@@ -1080,7 +1102,10 @@ non

Re: Remove nonoverlapping_component_refs_of_decl_p

2019-06-14 Thread Jan Hubicka
... and forgot to add stats for tramp3d :)

Alias oracle query stats:
  refs_may_alias_p: 3021539 disambiguations, 3321136 queries
  ref_maybe_used_by_call_p: 7118 disambiguations, 3047133 queries
  call_may_clobber_ref_p: 817 disambiguations, 817 queries
  nonoverlapping_component_refs_p: 22 disambiguations, 61735 queries
  nonoverlapping_component_refs_of_decl_p: 19 disambiguations, 2192 queries
  aliasing_component_refs_p: 2050 disambiguations, 19908 queries
  TBAA oracle: 1419961 disambiguations 2916692 queries
   555158 are in alias set 0
   575103 queries asked about the same object
   0 queries asked about the same alias set
   0 access volatile
   252874 are dependent in the DAG
   113596 are aritificially in conflict with void *

PTA query stats:
  pt_solution_includes: 671982 disambiguations, 952513 queries
  pt_solutions_intersect: 97060 disambiguations, 437912 queries



Re: C++ PATCH to implement deferred parsing of noexcept-specifiers (c++/86476, c++/52869)

2019-06-14 Thread Marek Polacek
On Tue, Jun 11, 2019 at 11:46:05PM -0400, Jason Merrill wrote:
> On 6/3/19 9:01 PM, Marek Polacek wrote:
> 
> > I sort of ended up going down a rathole, but then I realized we don't need 
> > to
> > delay parsing of noexcept-specifiers of member friend function declarations,
> > because they aren't members of the class.
> 
> Where are you getting this from?  I'm definitely sympathetic to the idea
> that noexcept-specifiers of friend functions shouldn't need to be
> complete-class contexts, but 10.3 doesn't make that distinction that I can
> see.

When I tested my patch I noticed that none of the 3 compilers I tried handled
this scenario, so I thought I was missing something.  But if the standard
really doesn't say that noexcept-specifiers of friend functions don't have to
be complete-class contexts, then perhaps it needs to say so.  Should I raise
this on the reflector?

> > This was a huge relief because
> > member friend function declarations can be redeclared, so we'd have to make
> > sure to check if their noexcept-specifiers match.  But member function decls
> > can't be redeclared.  I updated the comment to better reflect why what I'm
> > doing there is correct, along with an assert.
> 
> But then why do you still need this:
> 
> > +  /* We can't compare unparsed noexcept-specifiers.  Save the decl
> > + and check this again after we've parsed the noexcept-specifiers
> > + for real.  */
> > +  if (UNPARSED_NOEXCEPT_SPEC_P (new_exceptions))
> > +{
> > +  DEFARG_DECL (TREE_PURPOSE (new_exceptions)) = copy_decl (old_decl);
> > +  return;
> > +}
> 
> ?

Eh... I don't.  The following version is with the DEFARG_DECL junk removed.

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

2019-06-14  Marek Polacek  

PR c++/86476 - noexcept-specifier is a complete-class context.
PR c++/52869
* cp-tree.def (DEFAULT_ARG): Update commentary.
* cp-tree.h (UNPARSED_NOEXCEPT_SPEC_P): New macro.
(tree_default_arg): Use tree_base instead of tree_common.
(do_push_parm_decls, maybe_check_overriding_exception_spec): Declare.
* decl.c (do_push_parm_decls): New function, broken out of...
(store_parm_decls): ...here.  Call it.
* except.c (nothrow_spec_p): Accept DEFAULT_ARG in the assert.
* parser.c (cp_parser_noexcept_specification_opt,
cp_parser_late_noexcept_specifier, noexcept_override_late_checks):
Forward-declare.
(unparsed_noexcepts): New macro.
(push_unparsed_function_queues): Update initializer.
(cp_parser_direct_declarator): Pass FRIEND_P to
cp_parser_exception_specification_opt.
(inject_parm_decls): New.
(pop_injected_parms): New.
(cp_parser_class_specifier_1): Implement delayed parsing of
noexcept-specifiers.
(cp_parser_save_noexcept): New.
(cp_parser_late_noexcept_specifier): New.
(noexcept_override_late_checks): New.
(cp_parser_noexcept_specification_opt): Add FRIEND_P parameter.  Call
cp_parser_save_noexcept instead of the normal processing if needed.
(cp_parser_exception_specification_opt): Add FRIEND_P parameter and
pass it to cp_parser_noexcept_specification_opt.
(cp_parser_save_member_function_body): Fix comment.
(cp_parser_save_default_args): Maybe save the noexcept-specifier to
post process.
(cp_parser_transaction): Update call to
cp_parser_noexcept_specification_opt.
(cp_parser_transaction_expression): Likewise.
* parser.h (cp_unparsed_functions_entry): Add new field to carry
a noexcept-specifier.
* pt.c (dependent_type_p_r): Handle unparsed noexcept expression.
* search.c (maybe_check_overriding_exception_spec): New function, broken
out of...
(check_final_overrider): ...here.  Call
maybe_check_overriding_exception_spec.
* tree.c (canonical_eh_spec): Handle UNPARSED_NOEXCEPT_SPEC_P.
(cp_tree_equal): Handle DEFAULT_ARG.

* g++.dg/cpp0x/noexcept42.C: New test.
* g++.dg/cpp0x/noexcept43.C: New test.
* g++.dg/cpp0x/noexcept44.C: New test.
* g++.dg/cpp0x/noexcept45.C: New test.
* g++.dg/cpp0x/noexcept46.C: New test.
* g++.dg/cpp0x/noexcept47.C: New test.
* g++.dg/cpp0x/noexcept48.C: New test.
* g++.dg/cpp0x/noexcept49.C: New test.
* g++.dg/cpp0x/noexcept50.C: New test.
* g++.dg/eh/shadow1.C: Adjust dg-error.

diff --git gcc/cp/cp-tree.def gcc/cp/cp-tree.def
index 03c105b5c4c..475c584fd4c 100644
--- gcc/cp/cp-tree.def
+++ gcc/cp/cp-tree.def
@@ -209,7 +209,8 @@ DEFTREECODE (USING_STMT, "using_stmt", tcc_statement, 1)
 
 /* An un-parsed default argument.  Holds a vector of input tokens and
a vector of places where the argument was instantiated before
-   parsing had occurred.  */
+   parsing had occurred.  This is also used for delayed NSDMIs and
+   noexcept-specifier parsi

Re: [PATCH v6 01/10] Initial TI PRU GCC port

2019-06-14 Thread Segher Boessenkool
On Wed, Jun 12, 2019 at 06:08:13AM +0300, Dimitar Dimitrov wrote:
> On неделя, 9 юни 2019 г. 17:38:58 EEST Segher Boessenkool wrote:
> > On Sun, Jun 09, 2019 at 11:01:38PM +0300, Dimitar Dimitrov wrote:
> > > +; An unfortunate side effect is that quite a few invalid RTL patterns are
> > > +; generated.  For example:
> > > +;  ... (zero_extend:SI (match_operand:SI ...)) ...
> > 
> > You could perhaps use a mode iterator like rs6000's EXTHI and friends.
> The machine description already extensively uses mode iterators.

I meant specifically type iterators like this.  We can write e.g.

  (zero_extend:EXTSI (match_operand:SI ...))

and it will only generate patterns for those modes that SI can be extended
to.  This might be hard to make work with more than one mode in your
pattern though :-(

> > > +(define_subst "alu2_zext_subst"
> > > +  [(set (match_operand:EQD 0 "" "")
> > > + (ALUOP2:EQD (zero_extend:EQD (match_operand:EQD 1 "" ""]
> > 
> > I don't know if this actually works for define_subst, but at least in many
> > other cases you can write this like
> > 
> > (define_subst "alu2_zext_subst"
> >   [(set (match_operand:EQD 0)
> > (ALUOP2:EQD (zero_extend:EQD (match_operand:EQD 1]
> > 
> > (you can omit trailing empty string arguments).
> Indeed, genmddump generates the same output with or without the empty 
> strings. 
> I was not sure which is the preferred form, though. I see lots of MD 
> definitions in the GCC tree with empty strings.

Yes, this is a pretty new feature :-)

Usually all those trailing "" are just noise.  Sometimes there *could*
be something non-empty there, and then you sometimes want to keep it,
as documentation or whatever.

> > > +; There is no pipeline, so our scheduling description is simple.
> > > +(define_automaton "pru")
> > > +(define_cpu_unit "cpu" "pru")
> > > +
> > > +(define_insn_reservation "everything" 1 (match_test "true") "cpu")
> > 
> > Because you have a scheduling description, INSN_SCHEDULING is defined,
> > and that makes combine not create SUBREGs of MEM.  Which is pretty
> > important :-)
> Would lack of INSN_SCHEDULING result in a more efficient target code?  Is it 
> recommended?  I added dummy scheduling as a precaution to avoid issues like 
> PR78883 for AVR.

SUBREGs of MEM are an obsolete feature.  Maybe we should decouple it from
INSN_SCHEDULING; as it is now this workaround is non-obvious and frankly
a bit silly.  I'll see what I can do.


Segher


Re: [PATCH v4 2/3] Add predict_doloop_p target hook

2019-06-14 Thread Segher Boessenkool
Hi Kewen,

On Thu, Jun 13, 2019 at 01:50:05PM +0800, Kewen.Lin wrote:
> Comparing with the previous version, I dropped the checks
> on costly niter and invalid stmt scanning.  As Richard's
> suggestion, keep this as simple as possible, refine it 
> if finding any cases which matter later.

I think we'll want the invalid statement thing back pretty soon, it just
happens too often (20% of the time), and it makes ivopts make bad decisions.
It does not matter (much) for the performance of the generated code, but
still :-)

> +/* Predict whether the given loop in gimple will be transformed in the RTL
> +   doloop_optimize pass.  This is for rs6000 target specific.  */

Everything in rs6000/ is target-specific ;-)  Remove that part?

> +  /* On rs6000, targetm.can_use_doloop_p is actually
> + can_use_doloop_if_innermost.  Just ensure it's innermost.  */

"the loop is innermost".

> + fprintf (dump_file, "Predict doloop failure due to"
> + " no innermost.\n");

"due to no innermost" isn't great, but I don't know how th phrase it
better, either :-/  It's just debug output of course, so not so very
important.

> +This target hook is required only when the target supports low-overhead
> +loops, and will help some earlier middle-end passes to make some decisions.

Maybe just say it is for ivopts?  Or say that targets that do support
low-overhead loops *should* implement it?

> +/* True if we can predict this loop is possible to be transformed to a
> +   low-overhead loop, otherwise returns false.

"Return true if we predict the loop LOOP will be transformed to a
low-overhead loop, otherwise return false"?  Or mention doloop_optimize
like below:

> +/* Predict whether the given loop will be transformed in the RTL
> +   doloop_optimize pass.  Attempt to duplicate some doloop_optimize checks.
> +   This is only for target independent checks, see targetm.predict_doloop_p
> +   for the target dependent ones.
> +
> +   Note that according to some initial investigation, some checks like costly
> +   niter check and invalid stmt scanning don't have much gains among general
> +   cases, so keep this as simple as possible first.
> +
> +   Some RTL specific checks seems unable to be checked in gimple, if any new
> +   checks or easy checks _are_ missing here, please add them.  */

Good useful note, thanks :-)

The rs6000 part is okay for trunk.  Thanks!


Segher


[PATCH,Fortran] -- Check for overflow integer exponentation

2019-06-14 Thread Steve Kargl
I have had this patch in my tree since the beginning of May.  
During constant folding, gfortran would not issue an error
for overflow for integer exponentation.  Bootstrapped 
and regression tested multiple times on x86_64-*-freebsd?
OK to commit?

2019-06-15  Steven G. Kargl  

* arith.c (arith_power): Rework overflow of an integer to an integer
exponent.

2019-06-15  Steven G. Kargl  

* gfortran.dg/integer_exponentiation_4.f90: Update test.
* gfortran.dg/integer_exponentiation_5.F90: Ditto.
* gfortran.dg/no_range_check_1.f90: Ditto.

-- 
Steve
Index: gcc/fortran/arith.c
===
--- gcc/fortran/arith.c	(revision 269260)
+++ gcc/fortran/arith.c	(working copy)
@@ -848,8 +848,6 @@ arith_power (gfc_expr *op1, gfc_expr *op2, gfc_expr **
 	{
 	case BT_INTEGER:
 	  {
-		int power;
-
 		/* First, we simplify the cases of op1 == 1, 0 or -1.  */
 		if (mpz_cmp_si (op1->value.integer, 1) == 0)
 		  {
@@ -884,29 +882,36 @@ arith_power (gfc_expr *op1, gfc_expr *op2, gfc_expr **
    "exponent of integer has zero "
    "result at %L", &result->where);
 		  }
-		else if (gfc_extract_int (op2, &power))
+		else
 		  {
-		/* If op2 doesn't fit in an int, the exponentiation will
-		   overflow, because op2 > 0 and abs(op1) > 1.  */
-		mpz_t max;
-		int i;
-		i = gfc_validate_kind (BT_INTEGER, result->ts.kind, false);
+		/* We have abs(op1) > 1 and op2 > 1.
+		   If op2 > bit_size(op1), we'll have an out-of-range
+		   result.  */
+		int k, power;
 
-		if (flag_range_check)
-		  rc = ARITH_OVERFLOW;
-
-		/* Still, we want to give the same value as the
-		   processor.  */
-		mpz_init (max);
-		mpz_add_ui (max, gfc_integer_kinds[i].huge, 1);
-		mpz_mul_ui (max, max, 2);
-		mpz_powm (result->value.integer, op1->value.integer,
-			  op2->value.integer, max);
-		mpz_clear (max);
+		k = gfc_validate_kind (BT_INTEGER, op1->ts.kind, false);
+		power = gfc_integer_kinds[k].bit_size;
+		if (mpz_cmp_si (op2->value.integer, power) < 0)
+		  {
+			gfc_extract_int (op2, &power);
+			mpz_pow_ui (result->value.integer, op1->value.integer,
+power);
+			rc = gfc_range_check (result);
+			if (rc == ARITH_OVERFLOW)
+			  gfc_error_now ("Result of exponentiation at %L "
+	 "exceeds the range of %s", &op1->where,
+	 gfc_typename (&(op1->ts)));
+		  }
+		else
+		  {
+			/* Provide a nonsense value to propagate up. */
+			mpz_set (result->value.integer,
+ gfc_integer_kinds[k].huge);
+			mpz_add_ui (result->value.integer,
+result->value.integer, 1);
+			rc = ARITH_OVERFLOW;
+		  }
 		  }
-		else
-		  mpz_pow_ui (result->value.integer, op1->value.integer,
-			  power);
 	  }
 	  break;
 
Index: gcc/testsuite/gfortran.dg/integer_exponentiation_4.f90
===
--- gcc/testsuite/gfortran.dg/integer_exponentiation_4.f90	(revision 269260)
+++ gcc/testsuite/gfortran.dg/integer_exponentiation_4.f90	(working copy)
@@ -21,10 +21,10 @@ program test
   print *, (-1)**huge(0_8)
   print *, (-1)**(-huge(0_8)-1_8)
 
-  print *, 2**huge(0) ! { dg-error "Arithmetic overflow" }
-  print *, 2**huge(0_8) ! { dg-error "Arithmetic overflow" }
-  print *, (-2)**huge(0) ! { dg-error "Arithmetic overflow" }
-  print *, (-2)**huge(0_8) ! { dg-error "Arithmetic overflow" }
+  print *, 2**huge(0) ! { dg-error "Arithmetic overflow|exceeds the range" }
+  print *, 2**huge(0_8) ! { dg-error "Arithmetic overflow|exceeds the range" }
+  print *, (-2)**huge(0) ! { dg-error "Arithmetic overflow|exceeds the range" }
+  print *, (-2)**huge(0_8) ! { dg-error "Arithmetic overflow|exceeds the range" }
 
   print *, 2**(-huge(0)-1)
   print *, 2**(-huge(0_8)-1_8)
Index: gcc/testsuite/gfortran.dg/integer_exponentiation_5.F90
===
--- gcc/testsuite/gfortran.dg/integer_exponentiation_5.F90	(revision 269260)
+++ gcc/testsuite/gfortran.dg/integer_exponentiation_5.F90	(working copy)
@@ -67,8 +67,6 @@ program test
   TEST(3_8,43_8,i8)
   TEST(-3_8,43_8,i8)
 
-  TEST(17_8,int(huge(0_4),kind=8)+1,i8)
-
 ! REAL BASE !
   TEST(0.0,-1,r4)
   TEST(0.0,-huge(0)-1,r4)
Index: gcc/testsuite/gfortran.dg/no_range_check_1.f90
===
--- gcc/testsuite/gfortran.dg/no_range_check_1.f90	(revision 269260)
+++ gcc/testsuite/gfortran.dg/no_range_check_1.f90	(working copy)
@@ -4,11 +4,8 @@
 ! This testcase arose from PR 31262
   integer :: a
   integer(kind=8) :: b
-  a = -3
   b = -huge(b) / 7
-  a = a ** 73
   b = 7894_8 * b - 78941_8
-  if ((-3)**73 /= a) STOP 1
   if (7894_8 * (-huge(b) / 7) - 78941_8 /= b) STOP 2
 
   a = 1234789786453123


Re: [PATCH] libgfortran: Use __builtin_mul_overflow in xmallocarray

2019-06-14 Thread Steve Kargl
On Fri, Jun 14, 2019 at 08:07:36AM -0700, Steve Kargl wrote:
> On Fri, Jun 14, 2019 at 01:08:48PM +0300, Janne Blomqvist wrote:
> > As GCC now provides builtins for doing integer overflow checking, lets
> > use it when checking for overflow in xmallocarray.
> > 
> > Regtested on x86_64-pc-linux-gnu, Ok for trunk?
> > 
> 
> OK
> 

Just found

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

I assume that you close the PR.

-- 
Steve


Re: [PATCH,Fortran] -- Check for overflow integer exponentation

2019-06-14 Thread Jerry DeLisle

On 6/14/19 3:56 PM, Steve Kargl wrote:

I have had this patch in my tree since the beginning of May.
During constant folding, gfortran would not issue an error
for overflow for integer exponentation.  Bootstrapped
and regression tested multiple times on x86_64-*-freebsd?
OK to commit?

2019-06-15  Steven G. Kargl  

* arith.c (arith_power): Rework overflow of an integer to an integer
exponent.

2019-06-15  Steven G. Kargl  

* gfortran.dg/integer_exponentiation_4.f90: Update test.
* gfortran.dg/integer_exponentiation_5.F90: Ditto.
* gfortran.dg/no_range_check_1.f90: Ditto.



OK, thanks Steve


[Darwin, committed] opts processing - Initial tidy

2019-06-14 Thread Iain Sandoe


This change adds RejectNegative in a number of places it was needed,
reorders the opts into two groups (one general and one driver-only).
We also add a minimal description to each opt, and note some that
are now obsolete.  The only functional change is to permit
-mtarget-linker= as an alias of -mtarget-linker.

Tested on darwin9, 16 and 18, applied to mainline.
thanks
Iain

gcc/

2019-06-14  Iain Sandoe  

* config/darwin.opt: Add RejectNegative where needed, reorder
and add minimal functional descriptions.

diff --git a/gcc/config/darwin.opt b/gcc/config/darwin.opt
index 22667de..0b16b03 100644
--- a/gcc/config/darwin.opt
+++ b/gcc/config/darwin.opt
@@ -18,240 +18,378 @@
 ; along with GCC; see the file COPYING3.  If not see
 ; .
 
-; Various linker options have a -Z added so that they can get to specs
-; processing without interference.  Note that an option name with a
-; prefix that matches another option name, that also takes an
-; argument, being mapped to a -Z linker option, needs to be modified
-; so the prefix is different, otherwise a '*' after the shorter option
-; will match with the longer one.
+; We have a lot of Driver options, many of which are obsolete or very very
+; rarely used so, to keep this file easier to manage:
+
+; Please place all Non-driver options first (in alphabetical order), followed
+; by Driver-only options.
+
+; Non-driver options.
+
+dependency-file
+C ObjC C++ ObjC++ Separate Alias(MF) MissingArgError(missing filename after 
%qs)
+
+fapple-kext
+Target Report C++ Var(flag_apple_kext)
+Generate code for darwin loadable kernel extensions.
+
+iframework
+Target RejectNegative C ObjC C++ ObjC++ Joined Separate
+-iframework   Add  to the end of the system framework include 
path.
+
+mconstant-cfstrings
+Target Report Var(darwin_constant_cfstrings) Init(1)
+Generate compile-time CFString objects.
+
+Wnonportable-cfstrings
+Target Report Var(darwin_warn_nonportable_cfstrings) Init(1) Warning
+Warn if constant CFString objects contain non-portable characters.
+
+; Use new-style pic stubs if this is true, x86 only so far.
+matt-stubs
+Target Report Var(darwin_macho_att_stub) Init(1)
+Generate AT&T-style stubs for Mach-O.
+
+mdynamic-no-pic
+Target Common Report Mask(MACHO_DYNAMIC_NO_PIC)
+Generate code suitable for executables (NOT shared libs).
+
+mfix-and-continue
+Target Report Var(darwin_fix_and_continue)
+Generate code suitable for fast turn around debugging.
+
+mkernel
+Target Report Var(flag_mkernel)
+Generate code for the kernel or loadable kernel extensions.
+
+; The Init here is for the convenience of GCC developers, so that cc1
+; and cc1plus don't crash if no -mmacosx-version-min is passed.  The
+; driver will always pass a -mmacosx-version-min, so in normal use the
+; Init is never used.
+mmacosx-version-min=
+Target RejectNegative Joined Report Var(darwin_macosx_version_min) 
Init(DEF_MIN_OSX_VERSION)
+The earliest MacOS X version on which this program will run.
+
+; Really, only relevant to PowerPC which has a 4 byte bool by default.
+mone-byte-bool
+Target RejectNegative Report Var(darwin_one_byte_bool)
+Set sizeof(bool) to 1.
+
+; Some code-gen may be improved / adjusted if the linker is sufficiently 
modern.
+mtarget-linker=
+Target RejectNegative Joined Report Alias(mtarget-linker)
+
+mtarget-linker
+Target RejectNegative Joined Separate Report Var(darwin_target_linker) 
Init(LD64_VERSION)
+The version of ld64 in use for this toolchain.
+
+; Driver options.
 
 all_load
-Driver Alias(Zall_load)
+Driver RejectNegative Alias(Zall_load)
+Loads all members of archive libraries
 
 allowable_client
-Driver Separate Alias(Zallowable_client)
+Driver RejectNegative Separate Alias(Zallowable_client)
+-allowable_clientThe output dylib is private to the client(s) 
named
 
 arch
 Driver RejectNegative Separate
+-archSpecify that the output file should be generated for 
architecture  \"name\"
 
 arch_errors_fatal
-Driver Alias(Zarch_errors_fatal)
+Driver RejectNegative Alias(Zarch_errors_fatal)
+Mismatches between file architecture and the \"-arch\" are errors instead of 
warnings
 
 asm_macosx_version_min=
 Driver RejectNegative Joined
+The earliest MacOS X version on which this program will run (formatted for the 
assembler)
 
 bind_at_load
-Driver Alias(Zbind_at_load)
+Driver RejectNegative Alias(Zbind_at_load)
+Produce an output file that will bind symbols on load, rather than lazily.
 
 bundle
-Driver Alias(Zbundle)
+Driver RejectNegative Alias(Zbundle)
+Produce a Mach-O bundle (file type MH_BUNDLE)
 
 bundle_loader
-Driver Separate Alias(Zbundle_loader)
+Driver RejectNegative Separate Alias(Zbundle_loader)
+-bundle_loader Treat \"executable\" (that will be loading this 
bundle) as if it was one of the dynamic libraries the bundle is linked against 
for symbol resolution
 
-dead_strip
-Driver Alias(Zdead_strip)
+client_name
+Driver RejectNegative Separate
+-client_name Enable the executable being buil

Re: [PATCH v4 2/3] Add predict_doloop_p target hook

2019-06-14 Thread Bill Schmidt



On 6/14/19 4:53 PM, Segher Boessenkool wrote:
> Hi Kewen,
>
> On Thu, Jun 13, 2019 at 01:50:05PM +0800, Kewen.Lin wrote:
>> Comparing with the previous version, I dropped the checks
>> on costly niter and invalid stmt scanning.  As Richard's
>> suggestion, keep this as simple as possible, refine it 
>> if finding any cases which matter later.
> I think we'll want the invalid statement thing back pretty soon, it just
> happens too often (20% of the time), and it makes ivopts make bad decisions.
> It does not matter (much) for the performance of the generated code, but
> still :-)
>
>> +/* Predict whether the given loop in gimple will be transformed in the RTL
>> +   doloop_optimize pass.  This is for rs6000 target specific.  */
> Everything in rs6000/ is target-specific ;-)  Remove that part?
>
>> +  /* On rs6000, targetm.can_use_doloop_p is actually
>> + can_use_doloop_if_innermost.  Just ensure it's innermost.  */
> "the loop is innermost".
>
>> +fprintf (dump_file, "Predict doloop failure due to"
>> +" no innermost.\n");
> "due to no innermost" isn't great, but I don't know how th phrase it
> better, either :-/  It's just debug output of course, so not so very
> important.

How about "due to loop nesting?"

Bill
>
>> +This target hook is required only when the target supports low-overhead
>> +loops, and will help some earlier middle-end passes to make some decisions.
> Maybe just say it is for ivopts?  Or say that targets that do support
> low-overhead loops *should* implement it?
>
>> +/* True if we can predict this loop is possible to be transformed to a
>> +   low-overhead loop, otherwise returns false.
> "Return true if we predict the loop LOOP will be transformed to a
> low-overhead loop, otherwise return false"?  Or mention doloop_optimize
> like below:
>
>> +/* Predict whether the given loop will be transformed in the RTL
>> +   doloop_optimize pass.  Attempt to duplicate some doloop_optimize checks.
>> +   This is only for target independent checks, see targetm.predict_doloop_p
>> +   for the target dependent ones.
>> +
>> +   Note that according to some initial investigation, some checks like 
>> costly
>> +   niter check and invalid stmt scanning don't have much gains among general
>> +   cases, so keep this as simple as possible first.
>> +
>> +   Some RTL specific checks seems unable to be checked in gimple, if any new
>> +   checks or easy checks _are_ missing here, please add them.  */
> Good useful note, thanks :-)
>
> The rs6000 part is okay for trunk.  Thanks!
>
>
> Segher
>



[PATCH] Sync top-level change from gdb

2019-06-14 Thread Tom Tromey
This patch syncs a change to the top-level configury from gdb.  It
should not affect the gcc build at all.  Tested by rebuilding.

ChangeLog
2019-06-14  Tom Tromey  

* configure.ac (host_libs): Add gnulib.
* configure: Rebuild.
* Makefile.def (host_modules, dependencies): Add gnulib.
* Makefile.in: Rebuild.
---
 ChangeLog|   7 +
 Makefile.def |   3 +
 Makefile.in  | 462 +++
 configure|   8 +
 configure.ac |  10 +-
 5 files changed, 489 insertions(+), 1 deletion(-)

diff --git a/Makefile.def b/Makefile.def
index 29dd6d39721..493a31e0359 100644
--- a/Makefile.def
+++ b/Makefile.def
@@ -112,6 +112,7 @@ host_modules= { module= texinfo; no_install= true; };
 host_modules= { module= zlib; no_install=true; no_check=true;
bootstrap=true;
extra_configure_flags='@extra_host_zlib_configure_flags@';};
+host_modules= { module= gnulib; };
 host_modules= { module= gdb; };
 host_modules= { module= expect; };
 host_modules= { module= guile; };
@@ -392,11 +393,13 @@ dependencies = { module=all-intl; on=all-libiconv; };
 dependencies = { module=configure-gdb; on=all-intl; };
 dependencies = { module=configure-gdb; on=configure-sim; };
 dependencies = { module=configure-gdb; on=all-bfd; };
+dependencies = { module=configure-gdb; on=all-gnulib; };
 // Depend on all-libiconv so that configure checks for iconv
 // functions will work.
 dependencies = { module=configure-gdb; on=all-libiconv; };
 dependencies = { module=all-gdb; on=all-libiberty; };
 dependencies = { module=all-gdb; on=all-libiconv; };
+dependencies = { module=all-gdb; on=all-gnulib; };
 dependencies = { module=all-gdb; on=all-opcodes; };
 dependencies = { module=all-gdb; on=all-readline; };
 dependencies = { module=all-gdb; on=all-build-bison; };
diff --git a/Makefile.in b/Makefile.in
index 8486cc32ce8..02cc7a39094 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -1027,6 +1027,7 @@ configure-host:  \
 maybe-configure-sim \
 maybe-configure-texinfo \
 maybe-configure-zlib \
+maybe-configure-gnulib \
 maybe-configure-gdb \
 maybe-configure-expect \
 maybe-configure-guile \
@@ -1180,6 +1181,7 @@ all-host: maybe-all-texinfo
 @if zlib-no-bootstrap
 all-host: maybe-all-zlib
 @endif zlib-no-bootstrap
+all-host: maybe-all-gnulib
 all-host: maybe-all-gdb
 all-host: maybe-all-expect
 all-host: maybe-all-guile
@@ -1285,6 +1287,7 @@ info-host: maybe-info-sid
 info-host: maybe-info-sim
 info-host: maybe-info-texinfo
 info-host: maybe-info-zlib
+info-host: maybe-info-gnulib
 info-host: maybe-info-gdb
 info-host: maybe-info-expect
 info-host: maybe-info-guile
@@ -1371,6 +1374,7 @@ dvi-host: maybe-dvi-sid
 dvi-host: maybe-dvi-sim
 dvi-host: maybe-dvi-texinfo
 dvi-host: maybe-dvi-zlib
+dvi-host: maybe-dvi-gnulib
 dvi-host: maybe-dvi-gdb
 dvi-host: maybe-dvi-expect
 dvi-host: maybe-dvi-guile
@@ -1457,6 +1461,7 @@ pdf-host: maybe-pdf-sid
 pdf-host: maybe-pdf-sim
 pdf-host: maybe-pdf-texinfo
 pdf-host: maybe-pdf-zlib
+pdf-host: maybe-pdf-gnulib
 pdf-host: maybe-pdf-gdb
 pdf-host: maybe-pdf-expect
 pdf-host: maybe-pdf-guile
@@ -1543,6 +1548,7 @@ html-host: maybe-html-sid
 html-host: maybe-html-sim
 html-host: maybe-html-texinfo
 html-host: maybe-html-zlib
+html-host: maybe-html-gnulib
 html-host: maybe-html-gdb
 html-host: maybe-html-expect
 html-host: maybe-html-guile
@@ -1629,6 +1635,7 @@ TAGS-host: maybe-TAGS-sid
 TAGS-host: maybe-TAGS-sim
 TAGS-host: maybe-TAGS-texinfo
 TAGS-host: maybe-TAGS-zlib
+TAGS-host: maybe-TAGS-gnulib
 TAGS-host: maybe-TAGS-gdb
 TAGS-host: maybe-TAGS-expect
 TAGS-host: maybe-TAGS-guile
@@ -1715,6 +1722,7 @@ install-info-host: maybe-install-info-sid
 install-info-host: maybe-install-info-sim
 install-info-host: maybe-install-info-texinfo
 install-info-host: maybe-install-info-zlib
+install-info-host: maybe-install-info-gnulib
 install-info-host: maybe-install-info-gdb
 install-info-host: maybe-install-info-expect
 install-info-host: maybe-install-info-guile
@@ -1801,6 +1809,7 @@ install-pdf-host: maybe-install-pdf-sid
 install-pdf-host: maybe-install-pdf-sim
 install-pdf-host: maybe-install-pdf-texinfo
 install-pdf-host: maybe-install-pdf-zlib
+install-pdf-host: maybe-install-pdf-gnulib
 install-pdf-host: maybe-install-pdf-gdb
 install-pdf-host: maybe-install-pdf-expect
 install-pdf-host: maybe-install-pdf-guile
@@ -1887,6 +1896,7 @@ install-html-host: maybe-install-html-sid
 install-html-host: maybe-install-html-sim
 install-html-host: maybe-install-html-texinfo
 install-html-host: maybe-install-html-zlib
+install-html-host: maybe-install-html-gnulib
 install-html-host: maybe-install-html-gdb
 install-html-host: maybe-install-html-expect
 install-html-host: maybe-install-html-guile
@@ -1973,6 +1983,7 @@ installcheck-host: maybe-installcheck-sid
 installcheck-host: maybe-installcheck-sim
 installcheck-host: maybe-installcheck-texinfo
 installcheck-host: maybe-installcheck-zlib
+installcheck-host: maybe-installche

[PATCH] rs6000: New iterator CCEITHER

2019-06-14 Thread Segher Boessenkool
This expands to both CC and CCUNS, it's useful for isel for example.

Tested on powerpc64le-linux; committing to trunk.


Segher


2019-06-15  Segher Boessenkool  

* config/rs6000/rs6000.md (CCEITHER): New define_mode_iterator.
(un): New define_mode_attr.
(isel_signed_, isel_unsigned_): Delete, merge into ...
(isel_signed_): ... this.  New define_insn.
(isel_reversed_signed_, isel_reversed_unsigned_): Delete,
merge into ...
(isel_reversed_signed_): ... this.  New define_insn.

---
 gcc/config/rs6000/rs6000.md | 37 ++---
 1 file changed, 6 insertions(+), 31 deletions(-)

diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index b1f3bc3..eb03e4d 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -5055,23 +5055,13 @@ (define_expand "movcc"
 ;; leave out the mode in operand 4 and use one pattern, but reload can
 ;; change the mode underneath our feet and then gets confused trying
 ;; to reload the value.
-(define_insn "isel_signed_"
+(define_mode_iterator CCEITHER [CC CCUNS])
+(define_mode_attr un [(CC "") (CCUNS "un")])
+(define_insn "isel_signed_"
   [(set (match_operand:GPR 0 "gpc_reg_operand" "=r,r")
(if_then_else:GPR
 (match_operator 1 "scc_comparison_operator"
-[(match_operand:CC 4 "cc_reg_operand" "y,y")
- (const_int 0)])
-(match_operand:GPR 2 "reg_or_zero_operand" "O,b")
-(match_operand:GPR 3 "gpc_reg_operand" "r,r")))]
-  "TARGET_ISEL"
-  "isel %0,%2,%3,%j1"
-  [(set_attr "type" "isel")])
-
-(define_insn "isel_unsigned_"
-  [(set (match_operand:GPR 0 "gpc_reg_operand" "=r,r")
-   (if_then_else:GPR
-(match_operator 1 "scc_comparison_operator"
-[(match_operand:CCUNS 4 "cc_reg_operand" "y,y")
+[(match_operand:CCEITHER 4 "cc_reg_operand" "y,y")
  (const_int 0)])
 (match_operand:GPR 2 "reg_or_zero_operand" "O,b")
 (match_operand:GPR 3 "gpc_reg_operand" "r,r")))]
@@ -5083,26 +5073,11 @@ (define_insn "isel_unsigned_"
 ;; isel can handle reversed comparisons so long as the operands are
 ;; registers.
 
-(define_insn "*isel_reversed_signed_"
+(define_insn "*isel_reversed_signed_"
   [(set (match_operand:GPR 0 "gpc_reg_operand" "=r,r")
(if_then_else:GPR
 (match_operator 1 "scc_rev_comparison_operator"
-[(match_operand:CC 4 "cc_reg_operand" "y,y")
- (const_int 0)])
-(match_operand:GPR 2 "gpc_reg_operand" "r,r")
-(match_operand:GPR 3 "reg_or_zero_operand" "O,b")))]
-  "TARGET_ISEL"
-{
-  PUT_CODE (operands[1], reverse_condition (GET_CODE (operands[1])));
-  return "isel %0,%3,%2,%j1";
-}
-  [(set_attr "type" "isel")])
-
-(define_insn "*isel_reversed_unsigned_"
-  [(set (match_operand:GPR 0 "gpc_reg_operand" "=r,r")
-   (if_then_else:GPR
-(match_operator 1 "scc_rev_comparison_operator"
-[(match_operand:CCUNS 4 "cc_reg_operand" "y,y")
+[(match_operand:CCEITHER 4 "cc_reg_operand" "y,y")
  (const_int 0)])
 (match_operand:GPR 2 "gpc_reg_operand" "r,r")
 (match_operand:GPR 3 "reg_or_zero_operand" "O,b")))]
-- 
1.8.3.1



Re: [PATCH] Sync top-level change from gdb

2019-06-14 Thread Jeff Law
On 6/14/19 6:15 PM, Tom Tromey wrote:
> This patch syncs a change to the top-level configury from gdb.  It
> should not affect the gcc build at all.  Tested by rebuilding.
> 
> ChangeLog
> 2019-06-14  Tom Tromey  
> 
>   * configure.ac (host_libs): Add gnulib.
>   * configure: Rebuild.
>   * Makefile.def (host_modules, dependencies): Add gnulib.
>   * Makefile.in: Rebuild.
OK.
jeff