Improve std::rotate usages

[François Dumont]

Hi

    std::rotate already returns the expected iterator so there is no 
need for calls to std::advance/std::distance.


Tested under Linux x86_64, ok to commit ?

François

diff --git a/libstdc++-v3/include/bits/stl_algo.h b/libstdc++-v3/include/bits/stl_algo.h
index e10a692..9c1b2d4 100644
--- a/libstdc++-v3/include/bits/stl_algo.h
+++ b/libstdc++-v3/include/bits/stl_algo.h
@@ -1245,11 +1245,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 	 _ForwardIterator __last,
 	 forward_iterator_tag)
 {
-  if (__first == __middle)
-	return __last;
-  else if (__last  == __middle)
-	return __first;
-
   _ForwardIterator __first2 = __middle;
   do
 	{
@@ -1290,11 +1285,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   __glibcxx_function_requires(_Mutable_BidirectionalIteratorConcept<
   _BidirectionalIterator>)
 
-  if (__first == __middle)
-	return __last;
-  else if (__last  == __middle)
-	return __first;
-
   std::__reverse(__first,  __middle, bidirectional_iterator_tag());
   std::__reverse(__middle, __last,   bidirectional_iterator_tag());
 
@@ -1328,11 +1318,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   __glibcxx_function_requires(_Mutable_RandomAccessIteratorConcept<
   _RandomAccessIterator>)
 
-  if (__first == __middle)
-	return __last;
-  else if (__last  == __middle)
-	return __first;
-
   typedef typename iterator_traits<_RandomAccessIterator>::difference_type
 	_Distance;
   typedef typename iterator_traits<_RandomAccessIterator>::value_type
@@ -1434,6 +1419,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   __glibcxx_requires_valid_range(__first, __middle);
   __glibcxx_requires_valid_range(__middle, __last);
 
+  if (__first == __middle)
+	return __last;
+  else if (__last  == __middle)
+	return __first;
+
   return std::__rotate(__first, __middle, __last,
 			   std::__iterator_category(__first));
 }
@@ -1595,9 +1585,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 	   __right_len,
 	   __buffer, __buffer_size);
 
-  std::rotate(__left_split, __middle, __right_split);
-  std::advance(__left_split, std::distance(__middle, __right_split));
-  return __left_split;
+  return std::rotate(__left_split, __middle, __right_split);
 }
 
   template
@@ -2396,11 +2384,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 	return __last;
 	}
   else
-	{
-	  std::rotate(__first, __middle, __last);
-	  std::advance(__first, std::distance(__middle, __last));
-	  return __first;
-	}
+	return std::rotate(__first, __middle, __last);
 }
 
   /// This is a helper function for the merge routines.
@@ -2507,9 +2491,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 	  __len11 = std::distance(__first, __first_cut);
 	}
 
-  std::rotate(__first_cut, __middle, __second_cut);
-  _BidirectionalIterator __new_middle = __first_cut;
-  std::advance(__new_middle, std::distance(__middle, __second_cut));
+  _BidirectionalIterator __new_middle
+	= std::rotate(__first_cut, __middle, __second_cut);
   std::__merge_without_buffer(__first, __first_cut, __new_middle,
   __len11, __len22, __comp);
   std::__merge_without_buffer(__new_middle, __second_cut, __last,

Re: Protect from comma operator overload

[François Dumont]

Hi

    Here is the patch I eventually would like to commit.

    Tested under Linux x86_64, ok for trunk ?

François


On 17/04/2018 22:34, François Dumont wrote:

Yes, I also think there is no rush to fix this issue.

I had already written a test for a different purpose using the 
input_iterator_wrapper. This is why I detected this std::deque issue.


On 16/04/2018 22:16, Jonathan Wakely wrote:

On 16 April 2018 at 21:08, Jonathan Wakely wrote:

On 16 April 2018 at 20:52, François Dumont wrote:

Hi

 While working on something else on libstdc++ I started having 
a test
failing because of the missing comma overload protection in 
deque.tcc. So I
looked for other similar places in the code and here is a patch to 
fix the

places I found.

 Let me know if it is still time to commit.

The changes look right, but please add new tests to demonstrate the
code that used to fail.

You can use  because the iterator types defined
in there have deleted comma operators that should cause errors in
these places.

Something like this (but in four separate tests):

#include 
#include 
#include 
#include 

int main()
{
   using namespace __gnu_test;
   int a[1] = {};
   test_container t(a, a+1);

   std::deque d;
   d.assign(t.begin(), t.end());

   std::list l;
   l.assign(t.begin(), t.end());

   std::vector v;
   v.assign(t.begin(), t.end());

   std::vector b;
   b.assign(t.begin(), t.end());
}


Given how rare it is for real code to overload the comma operator, and
that nobody has reported these bugs, I think this can wait for after
GCC 8.





diff --git a/libstdc++-v3/include/bits/deque.tcc b/libstdc++-v3/include/bits/deque.tcc
index fe96330..1337394 100644
--- a/libstdc++-v3/include/bits/deque.tcc
+++ b/libstdc++-v3/include/bits/deque.tcc
@@ -297,7 +297,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
 		std::input_iterator_tag)
   {
 iterator __cur = begin();
-for (; __first != __last && __cur != end(); ++__cur, ++__first)
+for (; __first != __last && __cur != end(); ++__cur, (void)++__first)
   *__cur = *__first;
 if (__first == __last)
   _M_erase_at_end(__cur);
diff --git a/libstdc++-v3/include/bits/list.tcc b/libstdc++-v3/include/bits/list.tcc
index 22538c9..e90d957 100644
--- a/libstdc++-v3/include/bits/list.tcc
+++ b/libstdc++-v3/include/bits/list.tcc
@@ -312,7 +312,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
 iterator __first1 = begin();
 iterator __last1 = end();
 for (; __first1 != __last1 && __first2 != __last2;
-	 ++__first1, ++__first2)
+	 ++__first1, (void)++__first2)
   *__first1 = *__first2;
 if (__first2 == __last2)
   erase(__first1, __last1);
diff --git a/libstdc++-v3/include/bits/stl_bvector.h b/libstdc++-v3/include/bits/stl_bvector.h
index 05e9ff2..4b52c17 100644
--- a/libstdc++-v3/include/bits/stl_bvector.h
+++ b/libstdc++-v3/include/bits/stl_bvector.h
@@ -1229,7 +1229,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
 		  std::input_iterator_tag)
 	{
 	  iterator __cur = begin();
-	  for (; __first != __last && __cur != end(); ++__cur, ++__first)
+	  for (; __first != __last && __cur != end(); ++__cur, (void)++__first)
 	*__cur = *__first;
 	  if (__first == __last)
 	_M_erase_at_end(__cur);
diff --git a/libstdc++-v3/include/bits/vector.tcc b/libstdc++-v3/include/bits/vector.tcc
index 2516e35..f33da03 100644
--- a/libstdc++-v3/include/bits/vector.tcc
+++ b/libstdc++-v3/include/bits/vector.tcc
@@ -273,7 +273,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
   {
 	pointer __cur(this->_M_impl._M_start);
 	for (; __first != __last && __cur != this->_M_impl._M_finish;
-	 ++__cur, ++__first)
+	 ++__cur, (void)++__first)
 	  *__cur = *__first;
 	if (__first == __last)
 	  _M_erase_at_end(__cur);
diff --git a/libstdc++-v3/testsuite/23_containers/deque/modifiers/assign/1.cc b/libstdc++-v3/testsuite/23_containers/deque/modifiers/assign/1.cc
new file mode 100644
index 000..fbab09b
--- /dev/null
+++ b/libstdc++-v3/testsuite/23_containers/deque/modifiers/assign/1.cc
@@ -0,0 +1,36 @@
+// Copyright (C) 2018 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+#include 
+
+#include 
+#include 
+
+typedef __gnu_test::test_container
+  

Re: [wwwdocs] Add notes on common C++ problems with GCC 8

[Gerald Pfeifer]

On Wed, 25 Apr 2018, Jonathan Wakely wrote:
Ville is going to prepare something for the new -Wclass-memacess and 
-Wcatch-value warnings.  Suggestions for other gotchas to document are 
welcome.


Committed to CVS.


Great, thank you!

Gerald

Re: [PATCH] Re: Broken links in INSTALL/specific.html (PR web/85578)

[Gerald Pfeifer]

On Tue, 1 May 2018, Jakub Jelinek wrote:
> Now in patch form, briefly tested with a hacked gcc_release script (so that
> it works even with uncommitted install.texi2html).  Ok for trunk/8.1?
> 
> 2018-05-01  Jakub Jelinek  
> 
>   PR web/85578
>   * doc/install.texi2html: Replace _002d with - and _002a with * in
>   generated html files using sed.

Looks great, thank you, Jakub!

Gerald

Re: [RFC] Improve tree DSE

[Kugan Vivekanandarajah]

Hi Jeff,

Thanks for the review.

On 2 May 2018 at 01:43, Jeff Law  wrote:
> On 04/09/2018 06:52 PM, Kugan Vivekanandarajah wrote:
>> I would like to queue this patch for stage1 review.
>>
>> In DSE, while in dse_classify_store, as soon as we see a PHI use
>> statement that is part of the loop, we are immediately giving up.
>>
>> As far as I understand, this can be improved. Attached patch is trying
>> to walk the uses of the PHI statement (by recursively calling
>> dse_classify_store) and then making sure the obtained store is indeed
>> redundant.
>>
>> This is partly as reported in one of the testcase from PR44612. But
>> this PR is about other issues that is not handled in this patch.
>>
>> Bootstrapped and regression tested on aarch64-linux-gnu with no new 
>> regressions.
>>
>> Is this OK for next stage1?
>>
>> Thanks,
>> Kugan
>>
>>
>> gcc/ChangeLog:
>>
>> 2018-04-10  Kugan Vivekanandarajah  
>>
>> * tree-ssa-dse.c (dse_classify_store): Handle recursive PHI.
>> (dse_dom_walker::dse_optimize_stmt): Update call dse_classify_store.
>>
>> gcc/testsuite/ChangeLog:
>>
>> 2018-04-10  Kugan Vivekanandarajah  
>>
>> * gcc.dg/tree-ssa/ssa-dse-31.c: New test.
>> * gcc.dg/tree-ssa/ssa-dse-32.c: New test.
>>
>>
>> 0001-improve-dse.patch
>>
>>
>> From 5751eaff3d1c263e8631d5a07e43fecaaa0e9d26 Mon Sep 17 00:00:00 2001
>> From: Kugan Vivekanandarajah 
>> Date: Tue, 10 Apr 2018 09:49:10 +1000
>> Subject: [PATCH] improve dse
>>
>> ---
>>  gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-31.c | 16 ++
>>  gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-32.c | 23 ++
>>  gcc/tree-ssa-dse.c | 51 
>> --
>>  3 files changed, 81 insertions(+), 9 deletions(-)
>>  create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-31.c
>>  create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-32.c
>>
>
>> diff --git a/gcc/tree-ssa-dse.c b/gcc/tree-ssa-dse.c
>> index 9220fea..3513fda 100644
>> --- a/gcc/tree-ssa-dse.c
>> +++ b/gcc/tree-ssa-dse.c
>> @@ -521,11 +521,11 @@ live_bytes_read (ao_ref use_ref, ao_ref *ref, sbitmap 
>> live)
>> Return TRUE if the above conditions are met, otherwise FALSE.  */
>>
>>  static dse_store_status
>> -dse_classify_store (ao_ref *ref, gimple *stmt, gimple **use_stmt,
>> - bool byte_tracking_enabled, sbitmap live_bytes)
>> +dse_classify_store (ao_ref *ref, gimple *stmt_outer, gimple *stmt,
>> + gimple **use_stmt, bool byte_tracking_enabled,
>> + sbitmap live_bytes, unsigned cnt = 0)
>>  {
>>gimple *temp;
>> -  unsigned cnt = 0;
>>
>>*use_stmt = NULL;
>>
>> @@ -556,9 +556,11 @@ dse_classify_store (ao_ref *ref, gimple *stmt, gimple 
>> **use_stmt,
>>   {
>> cnt++;
>>
>> +   if (use_stmt == stmt_outer)
>> + continue;
> So is this really safe?  This seems to catch the case where the
> recursive call stumbles onto the same statement we're already
> processing.  ie, we've followed a loop backedge.
>
> ISTM that further analysis here  is needed -- don't you have to make
> sure that USE_STMT does not read from REF?  It could be a memmove call
> for example.
I think you are right. This has to be handled.

>
> I'm also struggling a little bit to see much value in handling this
> case.  In the included testcases we've got a memset in a loop where the
> args do not vary across the loop iterations and there are no reads from
> the memory location within the loop. How realistic is that?

I was looking into another case from an application but that was not
handled partly due to limitations of alias analysis and thought that
this could be handled. If you think that this is not going to happen
often in practice, I agree that this is not worth the trouble.

>
>
> If you're looking to improve DSE, the cases in 63185, 64380 and 79958
> may be interesting.

Thanks for the pointers. I will have a look at them.

Thanks,
Kugan

>

[RFA][PATCH] Optimize PHIs with constant arguments better

[Jeff Law]

Time to come back to this now that the trunk is open again...


 Forwarded Message 
Subject: [GCC 9][RFC][PATCH] Optimize PHIs with constant arguments better
Date: Thu, 30 Nov 2017 16:24:33 -0700
From: Jeff Law 
To: gcc-patches 



This addresses some code quality regressions with some work scheduled
for gcc-9.  However, if anyone is aware of BZs that could be helped with
this patch, don't hesitate to pass them along.  Depending on their
severity we could always re-evaluate the plan for this patch.

The patch optimizes sequences like this:


 # iftmp.4_16 = PHI <0(7), 1(8), 0(9)>
 _30 = (unsigned char) iftmp.4_16;

ie, we have a PHI where all its arguments are known (differing)
constants.  The PHI feeds an operation which can be compile-time
evaluated for all the PHI's arguments.

This arises most often where the result of the PHI is type converted via
 NOP_EXPR.  But it also happens for a boolean comparisons, arithmetic
and logicals and other type conversions.

We can optimize away the statement by creating a new PHI node holding
the result of the statement applied to each of the original PHI's
constant operands.  So for the fragment above we'd generate:

 # iftmp.4_16 = PHI <0(7), 1(8), 0(9)>
 # _30 = PHI <0(7), 1(8), 0(9)>

These kind of backward propagations can cascade.  Here's an example I
saw during analysis of test results:

 # m_5 = PHI <10(5), 12(6), 14(7)>
:
  _2 = (long unsigned int) m_5;
  _3 = _2 * 32;
  goto ; [100.00%]

After this patch the two statements have been eliminated in favor of
generating PHIs with constant arguments:

And after PHI propagation we have:
  # m_5 = PHI <10(5), 12(6), 14(7)>
  # _2 = PHI <10(5), 12(6), 14(7)>
  # _3 = PHI <320(5), 384(6), 448(7)>
:
  goto ; [100.00%]

DCE will come along and wipe out m_5 and _2 if they are unused.

I initially covered just NOP_EXPR in the proof of concept.   But it's
trivial to extend to cover other unaries, and binary/comparisons where
one operand was already a constant, so I did that.  This applies
surprisingly often during a bootstrap.  An earlier version (which didn't
handle multiple uses of the result of the PHI) triggered over 6000 times
during a bootstrap:

NOP_EXPR5161
LT_EXPR  658
GE_EXPR  504
NE_EXPR  310
BIT_NOT_EXPR 295
BIT_AND_EXPR  94
PLUS_EXPR 77
NEGATE_EXPR   48
LSHIFT_EXPR   40
EQ_EXPR   34
GT_EXPR   16
BIT_IOR_EXPR  10
MINUS_EXPR 8

There's actually other cases we could handle were

x = PHI (a, 0);
y = a & x;

Turns into

x = PHI (a, 0);
y = PHI (a, 0);


I'm not sure how often these non-constant cases happen -- I haven't
tried to support this or gain any data on how often this kind of case
might happen.

FWIW, there are cases were the PHI arguments are constant, but we still
can't simplify.  For example:


x = PHI (0, 1, 2)

y = 1234 / x;


When we process this we'll try to simplify 1234 / 0 to a constant which
fails.  We have to gracefully remove the partially initialized PHI node
in that case.  This is tested by existing tests in the suite.

You'll also see that certain tests in the suite such as pr61839_3,
ssa-pre-4.c are twiddled.  I've suppressed phi backwards propagation in
the original test so that it's not compromised.  THere's also a variant
of each test which verifies that the transformation is handled by phi
back propagation.

Bootstrapped and regression tested on x86, both in isolation and in a
larger patch series.

I see there's a couple whitespace issues in the patch.  I'll fix those.
I'd like to get comments/review on the meat of the patch though.



Jeff


* tree-ssa-phiprop.c (propagate_with_phi_1): Renamed from
propagate_with_phi.
(stmt_likely_produces_constant_result): New function.
(fold_use_into_phi, propagate_with_phi_2):  Likewise.
(pass_phiprop::execute): Corresponding changes.  Call
propagate_with_phi_2.

* gcc.dg/tree-ssa/pr61743-1.c: Use -fno-tree-phiprop.
* gcc.dg/tree-ssa/pr61839_1.c: Likewise.
* gcc.dg/tree-ssa/pr61839_3.c: Likewise.
* gcc.dg/tree-ssa/ssa-pre-4.c: Likewise.

* gcc.dg/tree-ssa/pr61743-1a.c: New test.
* gcc.dg/tree-ssa/pr61839_1a.c: Likewise.
* gcc.dg/tree-ssa/pr61839_3a.c: Likewise.
* gcc.dg/tree-ssa/ssa-pre-4a.c: New test.

diff --git a/gcc/tree-ssa-phiprop.c b/gcc/tree-ssa-phiprop.c
index 494158b..f2ec2b3 100644
--- a/gcc/tree-ssa-phiprop.c
+++ b/gcc/tree-ssa-phiprop.c
@@ -259,8 +259,8 @@ chk_uses (tree, tree *idx, void *data)
with aliasing issues as we are moving memory reads.  */
 
 static bool
-propagate_with_phi (basic_block bb, gphi *phi, struct phiprop_d *phivn,
-   size_t n)
+propagate_with_phi_1 (basic_block bb, gphi *phi, struct phiprop_d *phivn,
+ size_t n)
 {
   tree ptr = PHI_RESULT (phi);
   gimple *use_stmt;
@@ -440,6 +440,207 @@ next:;
   return phi_inserted;
 }
 
+/* Return TRUE if USE_STMT, which uses PHI_RESULT 

Re: Rb_tree constructor optimization

[Jonathan Wakely]

On 02/05/18 00:47 +0300, Ville Voutilainen wrote:

On 2 May 2018 at 00:28, Jakub Jelinek  wrote:

On Wed, May 02, 2018 at 12:23:27AM +0300, Ville Voutilainen wrote:

On 1 May 2018 at 22:56, François Dumont  wrote:
> Hi
>
> If not told otherwise I'll commit attached patch tomorrow.


Commit it where? The 8.1 release is not out yet, so we shouldn't be
pushing new stuff onto trunk yet.
Nor should we push such stuff into the release branch.


It is ok to commit stuff to trunk now, just not 8 branch.



All right; given that, the patch still needs maintainer approval,
which it doesn't have yet.


Oh, good point - I assumed from François's mail it was something we'd
agreed to commit but not until stage 1.

So it still needs a review then.

Re: [PATCH] Add support for gcc as git submodule of another repository.

[Jeff Law]

On 04/30/2018 05:20 PM, Jim Wilson wrote:
> We have some github repos that use git submodule to include other repos,
> including gcc.  When git submodule is used, .git is actually a file not a dir,
> and contains the path to the modules file in the parent repo's .git dir.  This
> patch allows contrib/gcc_update to work in this situation.
> 
> OK?
> 
> Jim
> 
>   contrib/
>   * gcc_update: Check for .git as a file.
OK.
jeff

Re: [PATCH 0/2] Require that constraints are used to reference global regs

[Jeff Law]

On 04/24/2018 07:21 AM, Michael Matz wrote:
> Hi,
> 
> On Tue, 24 Apr 2018, Alexander Monakov wrote:
> 
>>> Sure but even for that we need to decide if we want to go that or the 
>>> opposite way, and that's not easy when a deadline is lurking behind 
>>> you.
>>
>> I am surprised there is any question. Even gcc-3.4 optimizes reg vars 
>> over asms, on a testcase not unlike the very one you've used I see:
> 
> Thanks for checking.  Seems all the code that was supposed to care for 
> enabling this was always incomplete since a long time, which certainly 
> speaks for going the explicit dependency way.
The very nature of a traditional asm implies that it can read or write
anything visible to compiler.  We can't realistically peek inside to see
what's happening and the user hasn't provided appropriate dataflow
information.  One could make the argument that traditional asms should
go the way of the dodo bird.  I think we looked at that not terribly
long ago, but didn't really get anywhere.

Unfortunately doing the conservative thing and exposing the full set of
dependency edges to give the natural semantics of a traditional asm has
badly broken stuff in the past.  I doubt the change to IRA/LRA has
really changed this situation.

So what we've done is paper over these issues time and again to try and
preserve the expected semantics of a traditional asm.

I wonder if we should bite the bullet and try again to deprecate
traditional asms.



Jeff

Re: Rb_tree constructor optimization

[Ville Voutilainen]

On 2 May 2018 at 00:28, Jakub Jelinek  wrote:
> On Wed, May 02, 2018 at 12:23:27AM +0300, Ville Voutilainen wrote:
>> On 1 May 2018 at 22:56, François Dumont  wrote:
>> > Hi
>> >
>> > If not told otherwise I'll commit attached patch tomorrow.
>>
>>
>> Commit it where? The 8.1 release is not out yet, so we shouldn't be
>> pushing new stuff onto trunk yet.
>> Nor should we push such stuff into the release branch.
>
> It is ok to commit stuff to trunk now, just not 8 branch.


All right; given that, the patch still needs maintainer approval,
which it doesn't have yet.

Re: [PATCH] Improve boostrap-ubsan config (PR bootstrap/64914).

[Jeff Law]

On 03/01/2018 04:53 AM, Martin Liška wrote:
> On 03/01/2018 12:45 PM, Jakub Jelinek wrote:
>> On Thu, Mar 01, 2018 at 12:41:37PM +0100, Martin Liška wrote:
>>> I've been running periodically UBSAN bootstrap and as the runtime errors are
>>> not causing failure of compiler I haven't noticed the errors.
>>> Thus I would like to disable UBSAN recovery. Apart from that I'm handling
>>> issue in md5.c where in UBSAN bootstrap we want to do proper pointer 
>>> alignment.
>>> Doing that 2 will be remaining issues that will block the bootstrap:
>>>
>>> PR84634 and PR84635
>>>
>>> May I then install the patch? Jakub what do you think about it?
>> I actually prefer recovery where possible, that way we can get more runtime
>> errors at once, rather than stopping at the first one.
>> You always can and should grep the build logs.
> Ok, you convinced me with Marek :)
> 
>> As for md5.c, you only posted ChangeLog for it, not the actual patch.
> Sorry, I'm attaching updated patch.
> 
> Martin
> 
>>  Jakub
>>
> 
> 0001-Improve-boostrap-ubsan-config-PR-bootstrap-64914.patch
> 
> 
> From ccf9285022df7a2c11c14e5dc388d668d18243eb Mon Sep 17 00:00:00 2001
> From: marxin 
> Date: Thu, 1 Mar 2018 12:13:34 +0100
> Subject: [PATCH] Improve boostrap-ubsan config (PR bootstrap/64914).
> 
> config/ChangeLog:
> 
> 2018-03-01  Martin Liska  
> 
>   PR bootstrap/64914
>   * bootstrap-ubsan.mk: Define UBSAN_BOOTSTRAP.
> 
> libiberty/ChangeLog:
> 
> 2018-03-01  Martin Liska  
> 
>   PR bootstrap/64914
>   * md5.c: Use strict alignment with UBSAN_BOOTSTRAP.
OK
jeff

Re: Rb_tree constructor optimization

[Jakub Jelinek]

On Wed, May 02, 2018 at 12:23:27AM +0300, Ville Voutilainen wrote:
> On 1 May 2018 at 22:56, François Dumont  wrote:
> > Hi
> >
> > If not told otherwise I'll commit attached patch tomorrow.
> 
> 
> Commit it where? The 8.1 release is not out yet, so we shouldn't be
> pushing new stuff onto trunk yet.
> Nor should we push such stuff into the release branch.

It is ok to commit stuff to trunk now, just not 8 branch.

Jakub

Re: Rb_tree constructor optimization

[Ville Voutilainen]

On 1 May 2018 at 22:56, François Dumont  wrote:
> Hi
>
> If not told otherwise I'll commit attached patch tomorrow.


Commit it where? The 8.1 release is not out yet, so we shouldn't be
pushing new stuff onto trunk yet.
Nor should we push such stuff into the release branch.

[PING] [PATCH, libgomp, openacc] Factor out async argument utility functions

[Tom de Vries]

On 11/17/2017 02:18 PM, Tom de Vries wrote:

Hi,

I've factored out 3 new functions to test properties of enum acc_async_t:
...
typedef enum acc_async_t {
   /* Keep in sync with include/gomp-constants.h.  */
   acc_async_noval = -1,
   acc_async_sync  = -2
} acc_async_t;
...


In order to understand what this means:
...
   if (async < acc_async_noval)
...
you need to know the names and values of the enum.

Using the factored out functions, we get something that is easier to 
understand:

...
   if (async_synchronous_p (async))
...

Also I've changed the bodies of the functions to be robust against 
changes in values of acc_async_noval and acc_async_sync. No functional 
changes.


Build and tested on x86_64 with nvptx accelerator.

OK for trunk if bootstrap and reg-test on x86_64 succeeds?



Stage1 ping.

Thanks,- Tom



0001-Factor-out-async-argument-utility-functions.patch


Factor out async argument utility functions

2017-11-17  Tom de Vries  

* oacc-int.h (async_valid_stream_id_p, async_valid_p)
(async_synchronous_p): New function.
* oacc-async.c (acc_async_test, acc_wait, acc_wait_all_async): Use
async_valid_p.
* oacc-cuda.c (acc_get_cuda_stream, acc_set_cuda_stream): Use
async_valid_stream_id_p.
* oacc-mem.c (gomp_acc_remove_pointer): Use async_synchronous_p.
* oacc-parallel.c (GOACC_parallel_keyed): Same.

---
  libgomp/oacc-async.c|  6 +++---
  libgomp/oacc-cuda.c |  4 ++--
  libgomp/oacc-int.h  | 22 ++
  libgomp/oacc-mem.c  |  2 +-
  libgomp/oacc-parallel.c |  2 +-
  5 files changed, 29 insertions(+), 7 deletions(-)

diff --git a/libgomp/oacc-async.c b/libgomp/oacc-async.c
index 1334f99..f541b44 100644
--- a/libgomp/oacc-async.c
+++ b/libgomp/oacc-async.c
@@ -34,7 +34,7 @@
  int
  acc_async_test (int async)
  {
-  if (async < acc_async_sync)
+  if (!async_valid_p (async))
  gomp_fatal ("invalid async argument: %d", async);
  
struct goacc_thread *thr = goacc_thread ();

@@ -59,7 +59,7 @@ acc_async_test_all (void)
  void
  acc_wait (int async)
  {
-  if (async < acc_async_sync)
+  if (!async_valid_p (async))
  gomp_fatal ("invalid async argument: %d", async);
  
struct goacc_thread *thr = goacc_thread ();

@@ -117,7 +117,7 @@ acc_async_wait_all (void)
  void
  acc_wait_all_async (int async)
  {
-  if (async < acc_async_sync)
+  if (!async_valid_p (async))
  gomp_fatal ("invalid async argument: %d", async);
  
struct goacc_thread *thr = goacc_thread ();

diff --git a/libgomp/oacc-cuda.c b/libgomp/oacc-cuda.c
index ac9285f..97bc961 100644
--- a/libgomp/oacc-cuda.c
+++ b/libgomp/oacc-cuda.c
@@ -58,7 +58,7 @@ acc_get_cuda_stream (int async)
  {
struct goacc_thread *thr = goacc_thread ();
  
-  if (async < 0)

+  if (!async_valid_stream_id_p (async))
  return NULL;
  
if (thr && thr->dev && thr->dev->openacc.cuda.get_stream_func)

@@ -72,7 +72,7 @@ acc_set_cuda_stream (int async, void *stream)
  {
struct goacc_thread *thr;
  
-  if (async < 0 || stream == NULL)

+  if (!async_valid_stream_id_p (async) || stream == NULL)
  return 0;
  
goacc_lazy_initialize ();

diff --git a/libgomp/oacc-int.h b/libgomp/oacc-int.h
index cb14f09..f553267 100644
--- a/libgomp/oacc-int.h
+++ b/libgomp/oacc-int.h
@@ -99,6 +99,28 @@ void goacc_restore_bind (void);
  void goacc_lazy_initialize (void);
  void goacc_host_init (void);
  
+static inline bool

+async_valid_stream_id_p (int async)
+{
+  return async >= 0;
+}
+
+static inline bool
+async_valid_p (int async)
+{
+  return (async == acc_async_noval || async == acc_async_sync
+ || async_valid_stream_id_p (async));
+}
+
+static inline bool
+async_synchronous_p (int async)
+{
+  if (!async_valid_p (async))
+return true;
+
+  return async == acc_async_sync;
+}
+
  #ifdef HAVE_ATTRIBUTE_VISIBILITY
  # pragma GCC visibility pop
  #endif
diff --git a/libgomp/oacc-mem.c b/libgomp/oacc-mem.c
index ff3ed49..12558b8 100644
--- a/libgomp/oacc-mem.c
+++ b/libgomp/oacc-mem.c
@@ -723,7 +723,7 @@ gomp_acc_remove_pointer (void *h, bool force_copyfrom, int 
async, int mapnum)
gomp_mutex_unlock (_dev->lock);
  
/* If running synchronously, unmap immediately.  */

-  if (async < acc_async_noval)
+  if (async_synchronous_p (async))
  gomp_unmap_vars (t, true);
else
  t->device_descr->openacc.register_async_cleanup_func (t, async);
diff --git a/libgomp/oacc-parallel.c b/libgomp/oacc-parallel.c
index a8cff9e..baf44ec 100644
--- a/libgomp/oacc-parallel.c
+++ b/libgomp/oacc-parallel.c
@@ -183,7 +183,7 @@ GOACC_parallel_keyed (int device, void (*fn) (void *),
  async, dims, tgt);
  
/* If running synchronously, unmap immediately.  */

-  if (async < acc_async_noval)
+  if (async_synchronous_p (async))
  gomp_unmap_vars (tgt, true);
else
  tgt->device_descr->openacc.register_async_cleanup_func (tgt, async);

Fwd: [patch, fortran] Implement BACK for minloc and maxloc

[Thomas Koenig]

Hi,

the stup^H^H^H^Hhighly benevolent mailing list filter rejected
my patch because it was too large...



Hello world,

now that the release of gcc 8 is really around the corner, it's time
to add some new features :-) I had mostly completed this a few
months ago, but by then we were too deep into regression fixes
only mode.

The attached patch implements the BACK argument for minloc and maxloc,
in all three parts - simplification, inline and library.

I didn't actually go backwards though the array with BACK set to
true. Instead, I used comparisons which included equality.

At first, I was a bit concerned that adding the argument would lead
to inefficient code. Here, it seems that adding gfc_unlikely to
the condition really helped.  It would probably make sense to add
this to minval and maxval as well, but that is for another time.

With the short benchmark program

program main
   call x()
contains
   subroutine x()
 integer, dimension(5000,5000) :: a
 integer, dimension(5000*5000) :: b
 real, dimension(5000*5000) :: r
 character(len=100) :: line
 call random_number(r)
 b = r * 10
 a = reshape(b,shape(a))
 call cpu_time (t1)
 write (unit=line,fmt=*) maxloc(a)
 call cpu_time (t2)
 print '(A25, F10.6)',"maxloc rank 2:", t2-t1
 call cpu_time (t1)
 write (unit=line,fmt=*) maxloc(b,dim=1)
 call cpu_time (t2)
 print '(A25,F10.6)',"maxloc inline:", t2-t1
 call cpu_time (t1)
 write (unit=line,fmt=*) sum(maxloc(a,dim=1))
 call cpu_time (t2)
 print '(A25, F10.6)',"maxloc rank 2, dim=1:", t2-t1
 call cpu_time (t1)
 write (unit=line,fmt=*) sum(maxloc(a,dim=2))
 call cpu_time (t2)
 print '(A25, F10.6)',"maxloc rank 2, dim=2:", t2-t1
   end subroutine x
end program main

I got with the patch on current trunk

$ gfortran -Ofast -march=native ibench.f90 && ./a.out
maxloc rank 2:  0.009175
maxloc inline:  0.007585
 maxloc rank 2, dim=1:  0.014779
 maxloc rank 2, dim=2:  0.038609

and with gfortran-7 (haven't build a gcc 8 yet)

$ /usr/bin/gfortran-7 -Ofast -march=native ibench.f90 && ./a.out
maxloc rank 2:  0.011980
maxloc inline:  0.013796
 maxloc rank 2, dim=1:  0.021252
 maxloc rank 2, dim=2:  0.037773

Regression-tested. OK for trunk? I'll hold off committing until
gcc 8 is actually released, just in case.

Regards

Thomas

2018-05-01  Thomas Koenig  

PR fortran/54613
* check.c (gfc_check_minmaxloc): Remove error for BACK not being
implemented.  Use gfc_logical_4_kind for BACK.
* simplify.c (min_max_choose): Add optional argument back_val.
Handle it.
(simplify_minmaxloc_to_scalar): Add argument back_val. Pass
back_val to min_max_choose.
(simplify_minmaxloc_to_nodim): Likewise.
(simplify_minmaxloc_to_array): Likewise.
(gfc_simplify_minmaxloc): Add argument back, handle it.
Pass back_val to specific simplification functions.
(gfc_simplify_minloc): Remove ATTRIBUTE_UNUSED from argument back,
pass it on to gfc_simplify_minmaxloc.
(gfc_simplify_maxloc): Likewise.
* trans-intrinsic.c (gfc_conv_intrinsic_minmaxloc): Adjust
comment. If BACK is true, use greater or equal (or lesser or
equal) insteal of greater (or lesser). Mark the condition of
having found a value which exceeds the limit as unlikely.

2018-05-01  Thomas Koenig  

PR fortran/54613
* m4/iforeach-s.m4: Remove assertion that back is zero.
* m4/iforeach.m4: Likewise.  Remove leading 'do'
before implementation start.
* m4/ifunction-s.m4: Remove assertion that back is zero.
* m4/ifunction.m4: Likewise.  Remove for loop if HAVE_BACK_ARG
is defined.
* m4/maxloc0.m4: Reorganize loops. Split loops between >= and =,
depending if back is true.  Mark the condition of having
found a value which exceeds the limit as unlikely.
* m4/minloc0.m4: Likewise.
* m4/maxloc1.m4: Likewise.
* m4/minloc1.m4: Likewise.
* m4/maxloc1s.m4: Handle back argument.
* m4/minloc1s.m4: Likewise.
* m4/maxloc2s.m4: Remove assertion that back is zero.
Remove special handling of loop start. Handle back argument.
* m4/minloc2s.m4: Likewise.
* generated/iall_i1.c: Regenerated.
* generated/iall_i16.c: Regenerated.
* generated/iall_i2.c: Regenerated.
* generated/iall_i4.c: Regenerated.
* generated/iall_i8.c: Regenerated.
* generated/iany_i1.c: Regenerated.
* generated/iany_i16.c: Regenerated.
* generated/iany_i2.c: Regenerated.
* generated/iany_i4.c: Regenerated.
* generated/iany_i8.c: Regenerated.
* generated/iparity_i1.c: Regenerated.
* generated/iparity_i16.c: Regenerated.
* generated/iparity_i2.c: 

[PATCH, lto, PR85451] Add "could not find mkoffload" error message to lto-wrapper

[Tom de Vries]

Hi,

if lto-wrapper can't find mkoffload for an acceleration target it shows 
this error:

...
$ gcc -fopenacc test.c
lto-wrapper: fatal error: problem with building target image for nvptx-none

compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
...

This error message does not say what is really going wrong, nor suggest 
how to fix.


This patch adds a more precise error message, with a suggestion on how 
to fix the error:

...
$ gcc -fopenacc test.c
lto-wrapper: fatal error: could not find accel/nvptx-none/mkoffload in 
install/bin/../libexec/gcc/x86_64-pc-linux-gnu/8.0.1/:install/bin/../libexec/gcc/ 
(consider using '-B')


compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
...

OK for trunk?

Thanks,
- Tom
[lto] Add "could not find mkoffload" error message to lto-wrapper

2018-05-01  Tom de Vries  

	PR lto/85451
	* lto-wrapper.c (compile_offload_image): Add "could not find mkoffload"
	error message.

---
 gcc/lto-wrapper.c | 66 ---
 1 file changed, 34 insertions(+), 32 deletions(-)

diff --git a/gcc/lto-wrapper.c b/gcc/lto-wrapper.c
index a61d5dd..7de58d4 100644
--- a/gcc/lto-wrapper.c
+++ b/gcc/lto-wrapper.c
@@ -749,42 +749,44 @@ compile_offload_image (const char *target, const char *compiler_path,
 	break;
   }
 
-  if (compiler)
-{
-  /* Generate temporary output file name.  */
-  filename = make_temp_file (".target.o");
-
-  struct obstack argv_obstack;
-  obstack_init (_obstack);
-  obstack_ptr_grow (_obstack, compiler);
-  if (save_temps)
-	obstack_ptr_grow (_obstack, "-save-temps");
-  if (verbose)
-	obstack_ptr_grow (_obstack, "-v");
-  obstack_ptr_grow (_obstack, "-o");
-  obstack_ptr_grow (_obstack, filename);
+  if (!compiler)
+fatal_error (input_location,
+		 "could not find %s in %s (consider using '-B')\n", suffix + 1,
+		 compiler_path);
 
-  /* Append names of input object files.  */
-  for (unsigned i = 0; i < in_argc; i++)
-	obstack_ptr_grow (_obstack, in_argv[i]);
+  /* Generate temporary output file name.  */
+  filename = make_temp_file (".target.o");
 
-  /* Append options from offload_lto sections.  */
-  append_compiler_options (_obstack, compiler_opts,
-			   compiler_opt_count);
-  append_diag_options (_obstack, linker_opts, linker_opt_count);
+  struct obstack argv_obstack;
+  obstack_init (_obstack);
+  obstack_ptr_grow (_obstack, compiler);
+  if (save_temps)
+obstack_ptr_grow (_obstack, "-save-temps");
+  if (verbose)
+obstack_ptr_grow (_obstack, "-v");
+  obstack_ptr_grow (_obstack, "-o");
+  obstack_ptr_grow (_obstack, filename);
 
-  /* Append options specified by -foffload last.  In case of conflicting
-	 options we expect offload compiler to choose the latest.  */
-  append_offload_options (_obstack, target, compiler_opts,
-			  compiler_opt_count);
-  append_offload_options (_obstack, target, linker_opts,
-			  linker_opt_count);
+  /* Append names of input object files.  */
+  for (unsigned i = 0; i < in_argc; i++)
+obstack_ptr_grow (_obstack, in_argv[i]);
 
-  obstack_ptr_grow (_obstack, NULL);
-  argv = XOBFINISH (_obstack, char **);
-  fork_execute (argv[0], argv, true);
-  obstack_free (_obstack, NULL);
-}
+  /* Append options from offload_lto sections.  */
+  append_compiler_options (_obstack, compiler_opts,
+			   compiler_opt_count);
+  append_diag_options (_obstack, linker_opts, linker_opt_count);
+
+  /* Append options specified by -foffload last.  In case of conflicting
+ options we expect offload compiler to choose the latest.  */
+  append_offload_options (_obstack, target, compiler_opts,
+			  compiler_opt_count);
+  append_offload_options (_obstack, target, linker_opts,
+			  linker_opt_count);
+
+  obstack_ptr_grow (_obstack, NULL);
+  argv = XOBFINISH (_obstack, char **);
+  fork_execute (argv[0], argv, true);
+  obstack_free (_obstack, NULL);
 
   free_array_of_ptrs ((void **) paths, n_paths);
   return filename;

[nvptx, PR85451, committed] Improve "offload compiler not found" message in mkoffload

[Tom de Vries]

Hi,

this patch improves the "offload compiler not found" error message in 
nvptx's mkoffload, by suggesting to use '-B' to fix the error.


Committed to trunk.

Thanks,
- Tom
[nvptx] Improve "offload compiler not found" message in mkoffload

2018-05-01  Tom de Vries  

	PR lto/85451
	* config/nvptx/mkoffload.c (main): Suggest using -B in "offload compiler
	not found" error message.

---
 gcc/config/nvptx/mkoffload.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gcc/config/nvptx/mkoffload.c b/gcc/config/nvptx/mkoffload.c
index c009390..c002d12 100644
--- a/gcc/config/nvptx/mkoffload.c
+++ b/gcc/config/nvptx/mkoffload.c
@@ -454,7 +454,8 @@ main (int argc, char **argv)
 
   if (!found)
 fatal_error (input_location,
-		 "offload compiler %s not found", GCC_INSTALL_NAME);
+		 "offload compiler %s not found (consider using '-B')",
+		 GCC_INSTALL_NAME);
 
   /* We may be called with all the arguments stored in some file and
  passed with @file.  Expand them into argv before processing.  */

Rb_tree constructor optimization

[François Dumont]

Hi

If not told otherwise I'll commit attached patch tomorrow.

Already discussed here:

https://gcc.gnu.org/ml/libstdc++/2017-10/msg00053.html

François

diff --git a/libstdc++-v3/include/bits/stl_map.h b/libstdc++-v3/include/bits/stl_map.h
index a4a026e..2b8fd27 100644
--- a/libstdc++-v3/include/bits/stl_map.h
+++ b/libstdc++-v3/include/bits/stl_map.h
@@ -240,8 +240,8 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
 
   /// Allocator-extended move constructor.
   map(map&& __m, const allocator_type& __a)
-  noexcept(is_nothrow_copy_constructible<_Compare>::value
-	   && _Alloc_traits::_S_always_equal())
+  noexcept( noexcept(
+	_Rep_type(std::move(__m._M_t), declval<_Pair_alloc_type>())) )
   : _M_t(std::move(__m._M_t), _Pair_alloc_type(__a)) { }
 
   /// Allocator-extended initialier-list constructor.
diff --git a/libstdc++-v3/include/bits/stl_multimap.h b/libstdc++-v3/include/bits/stl_multimap.h
index fc8f454..b9289ab 100644
--- a/libstdc++-v3/include/bits/stl_multimap.h
+++ b/libstdc++-v3/include/bits/stl_multimap.h
@@ -237,8 +237,8 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
 
   /// Allocator-extended move constructor.
   multimap(multimap&& __m, const allocator_type& __a)
-  noexcept(is_nothrow_copy_constructible<_Compare>::value
-	   && _Alloc_traits::_S_always_equal())
+  noexcept( noexcept(
+	_Rep_type(std::move(__m._M_t), declval<_Pair_alloc_type>())) )
   : _M_t(std::move(__m._M_t), _Pair_alloc_type(__a)) { }
 
   /// Allocator-extended initialier-list constructor.
diff --git a/libstdc++-v3/include/bits/stl_multiset.h b/libstdc++-v3/include/bits/stl_multiset.h
index f41f56c..afaf3b6 100644
--- a/libstdc++-v3/include/bits/stl_multiset.h
+++ b/libstdc++-v3/include/bits/stl_multiset.h
@@ -253,8 +253,8 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
 
   /// Allocator-extended move constructor.
   multiset(multiset&& __m, const allocator_type& __a)
-  noexcept(is_nothrow_copy_constructible<_Compare>::value
-	   && _Alloc_traits::_S_always_equal())
+  noexcept( noexcept(
+	_Rep_type(std::move(__m._M_t), declval<_Key_alloc_type>())) )
   : _M_t(std::move(__m._M_t), _Key_alloc_type(__a)) { }
 
   /// Allocator-extended initialier-list constructor.
diff --git a/libstdc++-v3/include/bits/stl_set.h b/libstdc++-v3/include/bits/stl_set.h
index 2e332ef..fc6d1f7 100644
--- a/libstdc++-v3/include/bits/stl_set.h
+++ b/libstdc++-v3/include/bits/stl_set.h
@@ -257,8 +257,8 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
 
   /// Allocator-extended move constructor.
   set(set&& __x, const allocator_type& __a)
-  noexcept(is_nothrow_copy_constructible<_Compare>::value
-	   && _Alloc_traits::_S_always_equal())
+  noexcept( noexcept(
+	_Rep_type(std::move(__x._M_t), declval<_Key_alloc_type>())) )
   : _M_t(std::move(__x._M_t), _Key_alloc_type(__a)) { }
 
   /// Allocator-extended initialier-list constructor.
diff --git a/libstdc++-v3/include/bits/stl_tree.h b/libstdc++-v3/include/bits/stl_tree.h
index d0a8448..732ac55 100644
--- a/libstdc++-v3/include/bits/stl_tree.h
+++ b/libstdc++-v3/include/bits/stl_tree.h
@@ -715,6 +715,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 #else
 	  _Rb_tree_impl(_Rb_tree_impl&&) = default;
 
+	  _Rb_tree_impl(_Rb_tree_impl&& __x, _Node_allocator&& __a)
+	  : _Node_allocator(std::move(__a)),
+	_Base_key_compare(std::move(__x)),
+	_Rb_tree_header(std::move(__x))
+	  { }
+
 	  _Rb_tree_impl(const _Key_compare& __comp, _Node_allocator&& __a)
 	  : _Node_allocator(std::move(__a)), _Base_key_compare(__comp)
 	  { }
@@ -955,10 +961,32 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   _Rb_tree(_Rb_tree&&) = default;
 
   _Rb_tree(_Rb_tree&& __x, const allocator_type& __a)
+  noexcept( noexcept(
+	_Rb_tree(std::move(__x), declval<_Node_allocator>())) )
   : _Rb_tree(std::move(__x), _Node_allocator(__a))
   { }
 
-  _Rb_tree(_Rb_tree&& __x, _Node_allocator&& __a);
+private:
+  _Rb_tree(_Rb_tree&& __x, _Node_allocator&& __a, true_type)
+  noexcept(is_nothrow_move_constructible<_Rb_tree_impl<_Compare>>::value)
+  : _M_impl(std::move(__x._M_impl), std::move(__a))
+  { }
+
+  _Rb_tree(_Rb_tree&& __x, _Node_allocator&& __a, false_type)
+  : _M_impl(__x._M_impl._M_key_compare, std::move(__a))
+  {
+	if (__x._M_root() != nullptr)
+	  _M_move_data(__x, false_type{});
+  }
+
+public:
+  _Rb_tree(_Rb_tree&& __x, _Node_allocator&& __a)
+  noexcept( noexcept(
+	_Rb_tree(std::move(__x), std::move(__a),
+		 declval()) ) )
+  : _Rb_tree(std::move(__x), std::move(__a),
+		 typename _Alloc_traits::is_always_equal{})
+  { }
 #endif
 
   ~_Rb_tree() _GLIBCXX_NOEXCEPT
@@ -1358,22 +1386,22 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 private:
   // Move elements from container with equal allocator.
   void
-  _M_move_data(_Rb_tree& __x, std::true_type)
+  _M_move_data(_Rb_tree& __x, true_type)
   { _M_impl._M_move_data(__x._M_impl); }
 
   // 

[PATCH] RISC-V: Add with-multilib-list support.

[Jim Wilson]

This is an attempt to solve a packaging problem for linux distros.  If the
RISC-V port is built with --disable-multilib, libraries get installed into /lib
which violates the ABI.  If it is built with --enable-multilib, 32 versions
of libraries are built which is useful for embedded linux cross compiler
testing, but not useful for a native linux compiler.  This adds support for
the --with-multilib-list configure option to bridge the gap, to allow one
to build a compiler with multilibs enabled, but without building all 32
default multilibs.

Unfortunately, the RISC-V port is complicated in that ABI selection depends on
two options, -march and -mabi, instead of one as usual.  We also have a lot of
different arch and abi options, some of which are aliases of others.  This
complicates the implementation, so for the moment, I'm only allowing one ABI
in the list, and a few arch choices.  This can be expanded later as necessary.

I posting this before committing it in case anyone wants to comment on it.
I've tested it with cross compiler build and make check, and a native build,
and it appears to work correctly for me.  But I'm not a distro person, so I
can't easily verify that it fixes the problem that the distro people are
having.

Jim

gcc/
PR target/84797
* config.gcc (riscv*-*-*): Handle --with-multilib-list.
* config/riscv/t-withmultilib: New.
* config/riscv/withmultilib.h: New.
* doc/install.texi: Document RISC-V --with-multilib-list support.
---
 gcc/config.gcc  | 52 +
 gcc/config/riscv/t-withmultilib |  6 +
 gcc/config/riscv/withmultilib.h | 51 
 gcc/doc/install.texi| 11 +++--
 4 files changed, 118 insertions(+), 2 deletions(-)
 create mode 100644 gcc/config/riscv/t-withmultilib
 create mode 100644 gcc/config/riscv/withmultilib.h

diff --git a/gcc/config.gcc b/gcc/config.gcc
index a5defb0f005..1700ef002a5 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -4129,6 +4129,58 @@ case "${target}" in
exit 1
;;
esac
+
+   # Handle --with-multilib-list.
+   if test "x${with_multilib_list}" != xdefault; then
+   tm_file="${tm_file} riscv/withmultilib.h"
+   tmake_file="${tmake_file} riscv/t-withmultilib"
+
+   case ${with_multilib_list} in
+   ilp32 | ilp32f | ilp32d \
+   | lp64 | lp64f | lp64d )
+   
TM_MULTILIB_CONFIG="${with_arch},${with_multilib_list}"
+   ;;
+   *)
+   echo 
"--with-multilib-list=${with_multilib_list} not supported."
+   exit 1
+   esac
+
+   # Define macros to select the default multilib.
+   case ${with_arch} in
+   rv32gc)
+   tm_defines="${tm_defines} TARGET_MLIB_ARCH=1"
+   ;;
+   rv64gc)
+   tm_defines="${tm_defines} TARGET_MLIB_ARCH=2"
+   ;;
+   *)
+   echo "unsupported --with-arch for 
--with-multilib-list"
+   exit 1
+   esac
+   case ${with_abi} in
+   ilp32)
+   tm_defines="${tm_defines} TARGET_MLIB_ABI=1"
+   ;;
+   ilp32f)
+   tm_defines="${tm_defines} TARGET_MLIB_ABI=2"
+   ;;
+   ilp32d)
+   tm_defines="${tm_defines} TARGET_MLIB_ABI=3"
+   ;;
+   lp64)
+   tm_defines="${tm_defines} TARGET_MLIB_ABI=4"
+   ;;
+   lp64f)
+   tm_defines="${tm_defines} TARGET_MLIB_ABI=5"
+   ;;
+   lp64d)
+   tm_defines="${tm_defines} TARGET_MLIB_ABI=6"
+   ;;
+   *)
+   echo "unsupported --with-abi for 
--with-multilib"
+   exit 1
+   esac
+   fi
;;
 
mips*-*-*)
diff --git a/gcc/config/riscv/t-withmultilib b/gcc/config/riscv/t-withmultilib
new file mode 100644
index 000..bcd0845b448
--- /dev/null
+++ b/gcc/config/riscv/t-withmultilib
@@ -0,0 +1,6 @@
+comma=,
+MULTILIB_OPTIONS = $(subst lp64,mabi=lp64,$(subst ilp32,mabi=ilp32,$(subst 
rv,march=rv,$(subst $(comma), ,$(TM_MULTILIB_CONFIG)
+MULTILIB_DIRNAMES = 

Re: [og7, c, openacc, PR85465, committed] Handle non-var-decl in mark_vars_oacc_gangprivate

[Marek Polacek]

On Tue, May 01, 2018 at 08:40:59PM +0200, Tom de Vries wrote:
> @@ -14210,7 +14210,8 @@ mark_vars_oacc_gangprivate (tree *tp,
>tree block = BIND_EXPR_BLOCK (*tp);
>for (tree var = BLOCK_VARS (block); var; var = DECL_CHAIN (var))
>   {
> -   gcc_assert (TREE_CODE (var) == VAR_DECL);
> +   if (TREE_CODE (var) != VAR_DECL)
> + continue;

Just FYI, we have VAR_P for this.

Marek

[og7, c, openacc, PR85465, committed] Handle non-var-decl in mark_vars_oacc_gangprivate

[Tom de Vries]

Hi,

atm we run into an assert when compiling the test-case from the patch, 
because we encounter a non VAR_DECL (for foo) in this loop in 
mark_vars_oacc_gangprivate:

...
  if (TREE_CODE (*tp) == BIND_EXPR)
{
  tree block = BIND_EXPR_BLOCK (*tp);
  for (tree var = BLOCK_VARS (block); var; var = DECL_CHAIN (var))
{
  gcc_assert (TREE_CODE (var) == VAR_DECL);
  DECL_ATTRIBUTES (var)
= tree_cons (get_identifier ("oacc gangprivate"),
 NULL, DECL_ATTRIBUTES (var));
  c_mark_addressable (var);
}
}
...

Fixed by skipping over the non VAR_DECLs in the loop.

Build x86_64 with nvptx accelerator, ran libgomp testsuite.

Committed to og7 branch.

Thanks,
- Tom
[c, openacc] Handle non-var-decl in mark_vars_oacc_gangprivate

2018-05-01  Tom de Vries  

	PR target/85465
	* c-parser.c (mark_vars_oacc_gangprivate): Skip BLOCK_VARS that are not
	VAR_DECL.

	* testsuite/libgomp.oacc-c/pr85465.c: New test.

---
 gcc/c/c-parser.c   |  3 ++-
 libgomp/testsuite/libgomp.oacc-c/pr85465.c | 11 +++
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
index 069d219..99e9c8b 100644
--- a/gcc/c/c-parser.c
+++ b/gcc/c/c-parser.c
@@ -14210,7 +14210,8 @@ mark_vars_oacc_gangprivate (tree *tp,
   tree block = BIND_EXPR_BLOCK (*tp);
   for (tree var = BLOCK_VARS (block); var; var = DECL_CHAIN (var))
 	{
-	  gcc_assert (TREE_CODE (var) == VAR_DECL);
+	  if (TREE_CODE (var) != VAR_DECL)
+	continue;
 	  DECL_ATTRIBUTES (var)
 	= tree_cons (get_identifier ("oacc gangprivate"),
 			 NULL, DECL_ATTRIBUTES (var));
diff --git a/libgomp/testsuite/libgomp.oacc-c/pr85465.c b/libgomp/testsuite/libgomp.oacc-c/pr85465.c
new file mode 100644
index 000..329e8a0
--- /dev/null
+++ b/libgomp/testsuite/libgomp.oacc-c/pr85465.c
@@ -0,0 +1,11 @@
+/* { dg-do compile } */
+/* { dg-additional-options "-w" } */
+
+int
+main (void)
+{
+#pragma acc parallel
+  foo ();
+
+  return 0;
+}

Re: plugin-api.h patch to add a new interface for linker plugins

[Jeff Law]

On 02/20/2018 10:35 AM, Sriraman Tallam via binutils wrote:
> Ping.  Is this alright to apply now or should I wait for Stage 1?
> 
> * plugin-api.h (ld_plugin_get_wrap_symbols): New
>   plugin interface.
> 
> Thanks
> Sri
> 
> On Thu, Feb 15, 2018 at 1:52 PM, Sriraman Tallam  wrote:
>> Ping,  this patch was approved for binutils by Cary:
>> https://sourceware.org/ml/binutils/2017-12/msg00023.html
>>
>> Is it ok to apply this to GCC include/plugin-api.h now?  It is a
>> pretty small change. Patch attached.
>>
>> * plugin-api.h (ld_plugin_get_wrap_symbols): New
>>   plugin interface.
>>
>>
>> Thanks
>> Sri
>>
>> On Fri, Dec 8, 2017 at 11:02 AM, Sriraman Tallam  wrote:
>>> Patch attached.
>>>
>>> * plugin-api.h (ld_plugin_get_wrap_symbols): New
>>>   plugin interface.
>>>
>>> On Fri, Dec 8, 2017 at 11:01 AM, Sriraman Tallam  
>>> wrote:
 Hi,

This patch was approved for binutils by Cary:
 https://sourceware.org/ml/binutils/2017-12/msg00023.html

Is it ok to apply this to GCC include/plugin-api.h ?
OK for the trunk.

jeff

Re: [PATCH] -Wformat: fix nonsensical "wide character" message (PR c/84258)

[Jeff Law]

On 02/07/2018 06:53 PM, David Malcolm wrote:
> PR c/84258 reports that we issue this:
> 
>  warning: format is a wide character string [-Wformat=]
> 
> on this code:
> 
>   const unsigned char cuc[] = "%i";
>   sprintf(buf, (char *)cuc, 1);
> 
> despite the absence of wide characters.
> 
> This wording dates back 17.5 years to r36586:
> 
>  2000-09-24  Joseph S. Myers  
> 
>   * c-common.c (check_format_info): Warn for a wide character string
>used as a non-wide format argument.
> 
>* gcc.dg/c90-printf-1.c: Add test for wide string format.
> 
> which handled this case:
> 
>   printf ((const char *)L"foo"); /* { dg-warning "wide" "wide string" } */
> 
> The code in question is currently just checking for something that isn't
> char_type_node.
> 
> digest_init converts the string literal to the type of the array, converting
> it from array of char to array of unsigned char, leading to the condition
> failing.
> 
> This patch fixes the nonsensical message by checking for the other string
> types that lex_string can emit - char16_array_type_node,
> char32_array_type_node, and wchar_array_type_node - and only referring
> to "wide character string" if it's one of them.  Otherwise it uses a new,
> more generic wording.
> 
> Successfully bootstrapped on x86_64-pc-linux-gnu.
> 
> This isn't a regression, but is fairly low risk.
> 
> OK for trunk, either now, or for next stage 1?
> 
> gcc/c-family/ChangeLog:
>   PR c/84258
>   * c-format.c (struct format_check_results): Add field
>   "number_non_char".
>   (check_format_info): Initialize it, and warn if encountered.
>   (check_format_arg): Distinguish between wide char and
>   everything else when detecting arrays of non-char.
> 
> gcc/testsuite/ChangeLog:
>   PR c/84258
>   * c-c++-common/Wformat-pr84258.c: New test.
OK for the trunk.

Jeff

Tighten early exit in vect_analyze_data_ref_dependence (PR85586)

[Richard Sandiford]

The problem in this PR was that we didn't consider aliases between
writes in the same strided group.  After tightening the early exit
we get the expected abs(step) >= 2 versioning check.

Tested on aarch64-linux-gnu and x86_64-linux-gnu.  OK for trunk
and GCC 8?

Thanks,
Richard


2018-05-01  Richard Sandiford  

gcc/
PR tree-optimization/85586
* tree-vect-data-refs.c (vect_analyze_data_ref_dependence): Only
exit early for statements in the same group if the accesses are
not strided.

gcc/testsuite/
PR tree-optimization/85586
* gcc.dg/vect/pr85586.c: New test.

Index: gcc/tree-vect-data-refs.c
===
--- gcc/tree-vect-data-refs.c   2018-05-01 19:30:22.344979421 +0100
+++ gcc/tree-vect-data-refs.c   2018-05-01 19:32:10.404466158 +0100
@@ -305,9 +305,11 @@ vect_analyze_data_ref_dependence (struct
 return false;
 
   /* We do not have to consider dependences between accesses that belong
- to the same group.  */
+ to the same group, unless the stride could be smaller than the
+ group size.  */
   if (GROUP_FIRST_ELEMENT (stmtinfo_a)
-  && GROUP_FIRST_ELEMENT (stmtinfo_a) == GROUP_FIRST_ELEMENT (stmtinfo_b))
+  && GROUP_FIRST_ELEMENT (stmtinfo_a) == GROUP_FIRST_ELEMENT (stmtinfo_b)
+  && !STMT_VINFO_STRIDED_P (stmtinfo_a))
 return false;
 
   /* Even if we have an anti-dependence then, as the vectorized loop covers at
Index: gcc/testsuite/gcc.dg/vect/pr85586.c
===
--- /dev/null   2018-04-20 16:19:46.369131350 +0100
+++ gcc/testsuite/gcc.dg/vect/pr85586.c 2018-05-01 19:32:10.403466206 +0100
@@ -0,0 +1,43 @@
+#define N 100
+
+void __attribute__ ((noipa))
+foo (int *out, int *in, int step)
+{
+  for (int i = 0; i < N; ++i)
+{
+  out[0] = in[i];
+  out[1] = 2;
+  out += step;
+}
+}
+
+int in[N];
+int out[N * 2];
+
+int
+main (void)
+{
+  for (int i = 0; i < N; ++i)
+{
+  in[i] = i * (i + 1);
+  asm volatile ("" ::: "memory");
+}
+
+  foo (out, in, 1);
+  for (int i = 0; i < N; ++i)
+if (out[i] != in[i])
+  __builtin_abort ();
+  if (out[N] != 2)
+__builtin_abort ();
+
+  foo (out + N - 1, in, -1);
+  if (out[0] != in[N - 1])
+__builtin_abort ();
+  for (int i = 1; i <= N; ++i)
+if (out[i] != 2)
+  __builtin_abort ();
+
+  return 0;
+}
+
+/* { dg-final { scan-tree-dump-times "LOOP VECTORIZED" 1 "vect" { target 
vect_int } } } */

Re: [PATCH 2/2] Introduce prefetch-dynamic-strides option.

[Jeff Law]

On 01/22/2018 06:46 AM, Luis Machado wrote:
> The following patch adds an option to control software prefetching of memory
> references with non-constant/unknown strides.
> 
> Currently we prefetch these references if the pass thinks there is benefit to
> doing so. But, since this is all based on heuristics, it's not always the case
> that we end up with better performance.
> 
> For Falkor there is also the problem of conflicts with the hardware 
> prefetcher,
> so we need to be more conservative in terms of what we issue software prefetch
> hints for.
> 
> This also aligns GCC with what LLVM does for Falkor.
> 
> Similarly to the previous patch, the defaults guarantee no change in behavior
> for other targets and architectures.
> 
> I've regression-tested and bootstrapped it on aarch64-linux. No problems 
> found.
> 
> Ok?
> 
> 2018-01-22  Luis Machado  
> 
>   Introduce option to control whether the software prefetch pass should
>   issue prefetch hints for non-constant strides.
> 
>   gcc/
>   * config/aarch64/aarch64-protos.h (cpu_prefetch_tune)
>   : New const unsigned int field.
>   * config/aarch64/aarch64.c (generic_prefetch_tune): Update to include
>   prefetch_dynamic_strides.
>   (exynosm1_prefetch_tune): Likewise.
>   (thunderxt88_prefetch_tune): Likewise.
>   (thunderx_prefetch_tune): Likewise.
>   (thunderx2t99_prefetch_tune): Likewise.
>   (qdf24xx_prefetch_tune): Likewise. Set prefetch_dynamic_strides to 0.
>   (aarch64_override_options_internal): Update to set
>   PARAM_PREFETCH_DYNAMIC_STRIDES.
>   * doc/invoke.texi (prefetch-dynamic-strides): Document new option.
>   * params.def (PARAM_PREFETCH_DYNAMIC_STRIDES): New.
>   * params.h (PARAM_PREFETCH_DYNAMIC_STRIDES): Define.
>   * tree-ssa-loop-prefetch.c (should_issue_prefetch_p): Account for
>   prefetch-dynamic-strides setting.
OK for the trunk.
jeff

Re: [PATCH 1/2] Introduce prefetch-minimum stride option

[Jeff Law]

On 01/22/2018 06:46 AM, Luis Machado wrote:
> This patch adds a new option to control the minimum stride, for a memory
> reference, after which the loop prefetch pass may issue software prefetch
> hints for. There are two motivations:
> 
> * Make the pass less aggressive, only issuing prefetch hints for bigger 
> strides
> that are more likely to benefit from prefetching. I've noticed a case in 
> cpu2017
> where we were issuing thousands of hints, for example.
> 
> * For processors that have a hardware prefetcher, like Falkor, it allows the
> loop prefetch pass to defer prefetching of smaller (less than the threshold)
> strides to the hardware prefetcher instead. This prevents conflicts between
> the software prefetcher and the hardware prefetcher.
> 
> I've noticed considerable reduction in the number of prefetch hints and
> slightly positive performance numbers. This aligns GCC and LLVM in terms of
> prefetch behavior for Falkor.
> 
> The default settings should guarantee no changes for existing targets. Those
> are free to tweak the settings as necessary.
> 
> No regressions in the testsuite and bootstrapped ok on aarch64-linux.
> 
> Ok?
> 
> 2018-01-22  Luis Machado  
> 
>   Introduce option to limit software prefetching to known constant
>   strides above a specific threshold with the goal of preventing
>   conflicts with a hardware prefetcher.
> 
>   gcc/
>   * config/aarch64/aarch64-protos.h (cpu_prefetch_tune)
>   : New const int field.
>   * config/aarch64/aarch64.c (generic_prefetch_tune): Update to include
>   minimum_stride field.
>   (exynosm1_prefetch_tune): Likewise.
>   (thunderxt88_prefetch_tune): Likewise.
>   (thunderx_prefetch_tune): Likewise.
>   (thunderx2t99_prefetch_tune): Likewise.
>   (qdf24xx_prefetch_tune): Likewise. Set minimum_stride to 2048.
>   (aarch64_override_options_internal): Update to set
>   PARAM_PREFETCH_MINIMUM_STRIDE.
>   * doc/invoke.texi (prefetch-minimum-stride): Document new option.
>   * params.def (PARAM_PREFETCH_MINIMUM_STRIDE): New.
>   * params.h (PARAM_PREFETCH_MINIMUM_STRIDE): Define.
>   * tree-ssa-loop-prefetch.c (should_issue_prefetch_p): Return false if
>   stride is constant and is below the minimum stride threshold.
OK for the trunk.
jeff

Re: [PATCH] Add VEC_ORDERED_REMOVE_IF

[Jeff Law]

On 01/11/2018 06:03 AM, Tom de Vries wrote:
> On 01/10/2018 07:03 PM, Bernhard Reutner-Fischer wrote:
>> On 5 January 2018 22:06:10 CET, Tom de Vries  wrote:
>>
>>> [ was: Re: [RFC] Add vec::ordered_remove_if ]
>>
>> Tom,
>>
>> s/an an/an/g
>>
> 
> Fixed.
> 
> Also:
> - added '()' around more macro args in VEC_ORDERED_REMOVE_IF
> - added PR number ( https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83786 )
> 
> OK for trunk?
> 
> Thanks,
> - Tom
> 
> 0001-Add-VEC_ORDERED_REMOVE_IF.patch
> 
> 
> Add VEC_ORDERED_REMOVE_IF
> 
> 2018-01-03  Tom de Vries  
> 
>   PR other/83786
>   * vec.h (VEC_ORDERED_REMOVE_IF, VEC_ORDERED_REMOVE_IF_FROM_TO): Define.
>   * vec.c (test_ordered_remove_if): New function.
>   (vec_c_tests): Call test_ordered_remove_if.
>   * dwarf2cfi.c (connect_traces): Use VEC_ORDERED_REMOVE_IF_FROM_TO.
>   * lto-streamer-out.c (prune_offload_funcs): Use VEC_ORDERED_REMOVE_IF.
>   * tree-vect-patterns.c (vect_pattern_recog_1): Use
>   VEC_ORDERED_REMOVE_IF.
OK.
jeff

Re: PR82665 - missing value range optimization for memchr

[Jeff Law]

On 01/06/2018 11:58 PM, Prathamesh Kulkarni wrote:
> On 5 January 2018 at 00:20, Jeff Law  wrote:
>> On 01/03/2018 12:08 AM, Prathamesh Kulkarni wrote:
>>> On 3 January 2018 at 12:33, Prathamesh Kulkarni
>>>  wrote:
 On 2 January 2018 at 17:49, Jakub Jelinek  wrote:
> On Tue, Jan 02, 2018 at 05:39:17PM +0530, Prathamesh Kulkarni wrote:
>> --- /dev/null
>> +++ b/gcc/testsuite/gcc.dg/tree-ssa/pr82665.c
>> @@ -0,0 +1,22 @@
>> +/* { dg-do compile } */
>> +/* { dg-options "-O2 -fdump-tree-optimized" } */
>> +
>> +void f1 (char *p, __SIZE_TYPE__ sz)
>> +{
>> +  char *q = __builtin_memchr (p, 0, sz);
>> +  long n = q - p;
> Please use __PTRDIFF_TYPE__ instead of long, here and in other spots.
>
>> --- a/gcc/vr-values.c
>> +++ b/gcc/vr-values.c
>> @@ -793,6 +793,42 @@ vr_values::extract_range_from_binary_expr 
>> (value_range *vr,
>>
>>extract_range_from_binary_expr_1 (vr, code, expr_type, , );
>>
>> +  /* Set value_range for n in following sequence:
>> + def = __builtin_memchr (arg, 0, sz)
>> + n = def - arg
>> + Here the range for n can be set to [0, PTRDIFF_MAX - 1]. */
>> +
>> +  if (vr->type == VR_VARYING
>> +  && (code == POINTER_DIFF_EXPR)
>> +  && (TREE_CODE (op0) == SSA_NAME)
>> +  && (TREE_CODE (op1) == SSA_NAME))
> Please drop the useless ()s around the comparisons.  They are needed
> only if the condition is multi-line and needed for emacs indentation,
> or around assignments tested as conditions.
>
>> +  gcall *call_stmt = NULL;
>> +  if (def && arg
>> +   && (TREE_CODE (def) == SSA_NAME)
> Likewise (many times).
>
>> +   && ((TREE_CODE (TREE_TYPE (def)) == POINTER_TYPE)
>> +   && (TREE_TYPE (TREE_TYPE (def)) == char_type_node))
>> +   && (TREE_CODE (arg) == SSA_NAME)
>> +   && ((TREE_CODE (TREE_TYPE (arg)) == POINTER_TYPE)
>> +   && (TREE_TYPE (TREE_TYPE (arg)) == char_type_node))
> What is so special about char_type_node?  Why e.g. unsigned char or signed
> char pointer shouldn't be handled the same?
>
>> +   && (call_stmt = dyn_cast(SSA_NAME_DEF_STMT (def)))
>> +   && (gimple_call_combined_fn (call_stmt) == CFN_BUILT_IN_MEMCHR)
> We don't have an ifn for memchr, so why this?  On the other side, it 
> should
> be making sure one doesn't use unprototyped memchr with weirdo argument
> types, so you need gimple_call_builtin_p.
 Hi Jakub,
 Thanks for the review. I have tried to address your suggestions in the
 attached patch.
 Does it look OK ?
 Validation in progress.
>>> Oops, I mistakenly made argument sz in the tests of type
>>> __PTRDIFF_TYPE__ in the previous patch.
>>> The attached patch restores it's type to __SIZE_TYPE__.
>>>
>>> Thanks,
>>> Prathamesh
 Thanks,
 Prathamesh
>> +   && operand_equal_p (def, gimple_call_lhs (call_stmt), 0)
>> +   && operand_equal_p (arg, gimple_call_arg (call_stmt, 0), 0)
>> +   && integer_zerop (gimple_call_arg (call_stmt, 1)))
>> + {
>> +   tree max = vrp_val_max (ptrdiff_type_node);
>> +   wide_int wmax = wi::to_wide (max, TYPE_PRECISION (TREE_TYPE 
>> (max)));
>> +   tree range_min = build_zero_cst (expr_type);
>> +   tree range_max = wide_int_to_tree (expr_type, wmax - 1);
>> +   set_value_range (vr, VR_RANGE, range_min, range_max, NULL);
>> +   return;
>> + }
>> + }
>> +
>>/* Try harder for PLUS and MINUS if the range of one operand is 
>> symbolic
>>   and based on the other operand, for example if it was deduced from 
>> a
>>   symbolic comparison.  When a bound of the range of the first 
>> operand
>
> Jakub
>>>
>>> pr82665-8.diff
>>>
>>>
>>> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr82665.c 
>>> b/gcc/testsuite/gcc.dg/tree-ssa/pr82665.c
>>> new file mode 100644
>>> index 000..b37c3d1d7ce
>>> --- /dev/null
>>> +++ b/gcc/testsuite/gcc.dg/tree-ssa/pr82665.c
>>> @@ -0,0 +1,32 @@
>>> +/* { dg-do compile } */
>>> +/* { dg-options "-O2 -fdump-tree-optimized" } */
>>> +
>>> +void f1 (char *p, __SIZE_TYPE__ sz)
>>> +{
>>> +  char *q = __builtin_memchr (p, 0, sz);
>>> +  __PTRDIFF_TYPE__ n = q - p;
>>> +
>>> +  if (n >= __PTRDIFF_MAX__)
>>> +__builtin_abort ();
>>> +}
>>> +
>>> +void f2 (unsigned char *p, __SIZE_TYPE__ sz)
>>> +{
>>> +  unsigned char *q = __builtin_memchr (p, 0, sz);
>>> +  __PTRDIFF_TYPE__ n = q - p;
>>> +
>>> +  if (n >= __PTRDIFF_MAX__)
>>> +__builtin_abort ();
>>> +}
>>> +
>>> +void f3 (signed char *p, __SIZE_TYPE__ sz)
>>> +{
>>> +  signed char *q = __builtin_memchr (p, 0, sz);
>>> +  __PTRDIFF_TYPE__ n = q - p;
>>> +
>>> +  if (n >= __PTRDIFF_MAX__)
>>> +

Re: C++ PATCH for c++/85587, wrong error with scoped enum and template

[Jakub Jelinek]

On Tue, May 01, 2018 at 02:10:51PM -0400, Jason Merrill wrote:
> Now that we're doing normal handling of qualified names in a template,
> we need to handle the case of an unresolved enumerator name.
> 
> Jakub, should this also go into 8.1?

It is certainly ok for 8.2, for 8.1 I'll discuss tomorrow with Richard.

Jakub

C++ PATCH for c++/85587, wrong error with scoped enum and template

[Jason Merrill]

Now that we're doing normal handling of qualified names in a template,
we need to handle the case of an unresolved enumerator name.

Jakub, should this also go into 8.1?

Tested x86_64-pc-linux-gnu, applying to trunk.
commit f7dae5dc1933f836e47cafeab2ff2bd5d80e4eeb
Author: Jason Merrill 
Date:   Tue May 1 13:41:21 2018 -0400

PR c++/85587 - error with scoped enum in template.

* semantics.c (finish_qualified_id_expr): Don't return an
unqualified IDENTIFIER_NODE.

diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 8c893ed64b0..4568bb96f3b 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -2061,7 +2061,8 @@ finish_qualified_id_expr (tree qualifying_class,
 }
 
   /* No need to check access within an enum.  */
-  if (TREE_CODE (qualifying_class) == ENUMERAL_TYPE)
+  if (TREE_CODE (qualifying_class) == ENUMERAL_TYPE
+  && TREE_CODE (expr) != IDENTIFIER_NODE)
 return expr;
 
   /* Within the scope of a class, turn references to non-static
diff --git a/gcc/testsuite/g++.dg/cpp0x/scoped_enum8.C b/gcc/testsuite/g++.dg/cpp0x/scoped_enum8.C
new file mode 100644
index 000..3bd66395787
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/scoped_enum8.C
@@ -0,0 +1,25 @@
+// PR c++/85587
+// { dg-do compile { target c++11 } }
+
+template 
+struct S
+{
+  enum class T
+  {
+E, F
+  };
+  void foo ();
+};
+
+template 
+void S::foo ()
+{
+  decltype (T::F) t;
+}
+
+void
+bar ()
+{
+  S<0> s;
+  s.foo ();
+}

Re: [PATCH] PR52665 do not let .ident confuse assembler scan tests

[Jeff Law]

On 02/02/2018 06:25 AM, Bernhard Reutner-Fischer wrote:
> On 19 June 2016 at 22:21, Mike Stump  wrote:
>> On Jun 18, 2016, at 12:31 PM, Bernhard Reutner-Fischer 
>>  wrote:
>>>
>>> A branch with a name matching scan-assembler pattern triggers
>>> inappropriate FAIL.
>>
>>> The patch below adds -fno-ident if a testcase contains one of
>>> scan-assembler, scan-assembler-not or scan-assembler-times.
>>
>> Kinda gross.  I'd like to consensus build a little, as I don't know that I 
>> have a better solution than the solution you propose to fix the issue.  I'd 
>> love it if one or more of Jacob, Law and Richard can chime in on direction 
>> here.  I'll have to think about this some more and see if I can come up with 
>> something that I like better.
>>
>> If no one has a better solution, I'll approve the proposed solution.  Let's 
>> give people a little time to chime in.
> 
> Given the overwhelming silence this proposal has received, i take it
> for granted that folks are thrilled and even up until now speechless
> :)
> 
> So how should we proceed with -fno-ident.
> And, btw, -fno-file to inhibit .file directives for the same reason,
> https://gcc.gnu.org/ml/gcc-patches/2017-09/msg01785.html and all our
> ugly filenames like gcc.target/powerpc/swps-p8-36.c which strive to
> workaround the assembler-scans.
> 
> All those non-automatic hacks like naming swap() tests swps-,
> uglifying scan-patterns (which are not terribly straight forward to
> read anyway even without uglifying them) are error prone and costly.
> IMHO we should make sure time is spent for useful stuff and not be
> wasted to fight our very own testsuite.
> 
> -fno-ident ok for stage1?
> What about -fno-file? Clever alternative suggestions? Don't care?
I thought I ack'd this back in 2016? :-)

jeff

Re: ATTRIBUTE_NONSTRING

[Jeff Law]

On 04/28/2018 12:25 AM, Alan Modra wrote:
> On Fri, Apr 27, 2018 at 06:24:28PM -0400, Hans-Peter Nilsson wrote:
>> On Fri, 27 Apr 2018, Alan Modra wrote:
>>
>>> This patch adds ATTRIBUTE_NONSTRING, which will be used to curb
>>> -Wstringop-truncation warnings in binutils.  OK to apply?
>>>
>>> * ansidecl.h (ATTRIBUTE_NONSTRING): Define.
>>>
>>> diff --git a/include/ansidecl.h b/include/ansidecl.h
>>> index c11daff..ec5f34d 100644
>>> --- a/include/ansidecl.h
>>> +++ b/include/ansidecl.h
>>> @@ -283,6 +283,15 @@ So instead we use the macro below and test it against 
>>> specific values.  */
>>>  # endif /* GNUC >= 4.9 */
>>>  #endif /* ATTRIBUTE_NO_SANITIZE_UNDEFINED */
>>>
>>> +/* Attribute 'nonstring' was valid as of gcc 8.  */
>>> +#ifndef ATTRIBUTE_NONSTRING
>>> +# if GCC_VERSION >= 8000
>>> +#  define ATTRIBUTE_NONSTRING __attribute__ ((nonstring))
>>
>> Uglify nonstring (as __nonstring__)?
> 
> Yes, that would be better.  I copied the immediately preceding
> ATTRIBUTE_NO_SANITIZE_UNDEFINED without thinking.
OK with uglification.

jeff

Re: [PATCH] Remove MPX support

[Jeff Law]

On 04/27/2018 05:00 AM, Martin Liška wrote:
> Hi.
> 
> I'm sending patch that removes MPX. It preserves all options 
> -fcheck-pointer-bounds, -fchkp-* and -mmpx
> target option. These options are now NOP. On the contrary following options 
> were removed:
> --static-libmpx  -static-libmpxwrappers. Is it fine to remove them?
> 
> Patch can bootstrap on x86_64-linux-gnu, ppc64le-linux-gnu and survives 
> regression tests.
> And the patch bootstraps also on aarch64-linux-gnu.
> 
> Note that the patch is trim for files (some) that are removed. Doing that was 
> necessary to
> fit in 100K with bzip2 patch file.
> 
> Ready to be installed after some time?
Yes.  Please coordinate with Jakub & Richi since this touches a fair
amount of code and might interfere with attempts to backport changes
from the trunk into the gcc-8 release branch.

I wouldn't be surprised if we find bits of MPX code after the patch is
installed.  Changes to remove any stragglers are pre-approved as well.

Jeff

Re: [PATCH] Use --push-state --as-needed and --pop-state instead of --as-needed and --no-as-needed for libgcc

[Jeff Law]

On 04/11/2018 04:31 AM, Jakub Jelinek wrote:
> Hi!
> 
> As discussed, using --as-needed and --no-as-needed is dangerous, because
> it results in --no-as-needed even for libraries after -lgcc_s, even when the
> default is --as-needed or --as-needed has been specified earlier on the
> command line.
> 
> If the linker supports --push-state/--pop-state, we should IMHO use it.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for stage1?
> 
> Or is this something we want in GCC8 too?
> 
> 2018-04-11  Jakub Jelinek  
> 
>   * configure.ac (LD_AS_NEEDED_OPTION, LD_NO_AS_NEEDED_OPTION): Use
>   --push-state --as-needed and --pop-state instead of --as-needed and
>   --no-as-needed if ld supports it.
>   * configure: Regenerated.
OK for the trunk.
jeff

LTO incremental linking and early debug

[Jan Hubicka]

Richard,
I have updated my patch for incremental linking into LTO bytecode, but it now 
breaks in
dwarf2out:
lto1: internal compiler error: in dwarf2out_die_ref_for_decl, at 
dwarf2out.c:5859
0x5d8a37 dwarf2out_die_ref_for_decl
../../gcc/dwarf2out.c:5858
0xa8c311 lto_write_tree_1
../../gcc/lto-streamer-out.c:423
0xa9539c lto_write_tree
../../gcc/lto-streamer-out.c:449
0xa9539c lto_output_tree_1
../../gcc/lto-streamer-out.c:483
0xa9539c DFS::DFS(output_block*, tree_node*, bool, bool, bool)
../../gcc/lto-streamer-out.c:670
0xa9656d lto_output_tree(output_block*, tree_node*, bool, bool)
../../gcc/lto-streamer-out.c:1642
0xa8c128 write_global_stream
../../gcc/lto-streamer-out.c:2496
0xa946be lto_output_decl_state_streams(output_block*, lto_out_decl_state*)
../../gcc/lto-streamer-out.c:2543
0xa946be produce_asm_for_decls()
../../gcc/lto-streamer-out.c:2870
0xaf1d3f write_lto
../../gcc/passes.c:2613
0xaf52fe ipa_write_summaries_1
../../gcc/passes.c:2674
0xaf52fe ipa_write_summaries()
../../gcc/passes.c:2734
0x8052e2 ipa_passes
../../gcc/cgraphunit.c:2470
0x8052e2 symbol_table::compile()
../../gcc/cgraphunit.c:2562
0x7701e7 lto_main()
../../gcc/lto/lto.c:3388

I guess that is early debug info. This happens in quite few testcases with the 
patch
attached.  I wonder how we should proceed with this one?


* lto-plugin.c: Document options; add -linker-output-known;
determine when to use rel and when nolto-rel output.

* lto-wrapper.c (run_gcc): Look for -flinker-output=rel also in the
list of options passed from the driver.
* passes.c (ipa_write_summaries): Only modify statements if body
is in memory.
* cgrpahunit.c (ipa_passes): Also produce intermeidate code when
incrementally linking.
(ipa_passes): LIkewise.
* lto-cgraph.c (lto_output_node): When incrementally linking do not
pass down resolution info.
* common.opt (flag_incremental_link): Update info.
* gcc.c (plugin specs): Turn flinker-output=* to
-plugin-opt=-linker-output-known
* toplev.c (compile_file): Also cut compilation when doing incremental
link.
* flag-types. (enum lto_partition_model): Add
LTO_LINKER_OUTPUT_NOLTOREL.
(invoke.texi): Add -flinker-output docs.

* lang.opt (lto_linker_output): Add nolto-rel.
* lto-lang.c (lto_post_options): Handle LTO_LINKER_OUTPUT_REL
and LTO_LINKER_OUTPUT_NOLTOREL:.
(lto_init): Generate lto when doing incremental link.

* gcc.dg/lto/20081120-2_0.c: Add -flinker-output=nolto-rel
* gcc.dg/lto/20090126-1_0.c: Likewise.
* gcc.dg/lto/20091020-2_0.c: Likewise.
* gcc.dg/lto/20081204-2_0.c: Likewise.
* gcc.dg/lto/20091015-1_0.c: Likewise.
* gcc.dg/lto/20090126-2_0.c: Likewiwe.
* gcc.dg/lto/20090116_0.c: Likewise.
* gcc.dg/lto/20081224_0.c: Likewise.
* gcc.dg/lto/20091027-1_0.c: Likewise.
* gcc.dg/lto/20090219_0.c: Likewise.
* gcc.dg/lto/20081212-1_0.c: Likewise.
* gcc.dg/lto/20091013-1_0.c: Likewise.
* gcc.dg/lto/20081126_0.c: Likewise.
* gcc.dg/lto/20090206-1_0.c: Likewise.
* gcc.dg/lto/20091016-1_0.c: Likewise.
* gcc.dg/lto/20081120-1_0.c: Likewise.
* gcc.dg/lto/20091020-1_0.c: Likewise.
* gcc.dg/lto/20100426_0.c: Likewise.
* gcc.dg/lto/20081204-1_0.c: Likewise.
* gcc.dg/lto/20091014-1_0.c: Likewise.
* g++.dg/lto/20081109-1_0.C: Likewise.
* g++.dg/lto/20100724-1_0.C: Likewise.
* g++.dg/lto/20081204-1_0.C: Likewise.
* g++.dg/lto/pr45679-2_0.C: Likewise.
* g++.dg/lto/20110311-1_0.C: Likewise.
* g++.dg/lto/20090302_0.C: Likewise.
* g++.dg/lto/20081118_0.C: Likewise.
* g++.dg/lto/20091002-2_0.C: Likewise.
* g++.dg/lto/20081120-2_0.C: Likewise.
* g++.dg/lto/20081123_0.C: Likewise.
* g++.dg/lto/20090313_0.C: Likewise.
* g++.dg/lto/pr54625-1_0.c: Likewise.
* g++.dg/lto/pr48354-1_0.C: Likewise.
* g++.dg/lto/20081219_0.C: Likewise.
* g++.dg/lto/pr48042_0.C: Likewise.
* g++.dg/lto/20101015-2_0.C: Likewise.
* g++.dg/lto/pr45679-1_0.C: Likewise.
* g++.dg/lto/20091026-1_0.C: Likewise.
* g++.dg/lto/pr45621_0.C: Likewise.
* g++.dg/lto/20081119-1_0.C: Likewise.
* g++.dg/lto/20101010-4_0.C: Likewise.
* g++.dg/lto/20081120-1_0.C: Likewise.
* g++.dg/lto/20091002-1_0.C: Likewise.
* g++.dg/lto/20091002-3_0.C: Likewise.
* gfortran.dg/lto/20091016-1_0.f90: Likewise.
* gfortran.dg/lto/pr47839_0.f90: Likewise.
* gfortran.dg/lto/pr46911_0.f: Likewise.
* gfortran.dg/lto/20091028-1_0.f90: Likewise.
* gfortran.dg/lto/20091028-2_0.f90: Likewise.
Index: gcc/cgraphunit.c

Re: [RFC] Improve tree DSE

[Jeff Law]

On 04/09/2018 06:52 PM, Kugan Vivekanandarajah wrote:
> I would like to queue this patch for stage1 review.
> 
> In DSE, while in dse_classify_store, as soon as we see a PHI use
> statement that is part of the loop, we are immediately giving up.
> 
> As far as I understand, this can be improved. Attached patch is trying
> to walk the uses of the PHI statement (by recursively calling
> dse_classify_store) and then making sure the obtained store is indeed
> redundant.
> 
> This is partly as reported in one of the testcase from PR44612. But
> this PR is about other issues that is not handled in this patch.
> 
> Bootstrapped and regression tested on aarch64-linux-gnu with no new 
> regressions.
> 
> Is this OK for next stage1?
> 
> Thanks,
> Kugan
> 
> 
> gcc/ChangeLog:
> 
> 2018-04-10  Kugan Vivekanandarajah  
> 
> * tree-ssa-dse.c (dse_classify_store): Handle recursive PHI.
> (dse_dom_walker::dse_optimize_stmt): Update call dse_classify_store.
> 
> gcc/testsuite/ChangeLog:
> 
> 2018-04-10  Kugan Vivekanandarajah  
> 
> * gcc.dg/tree-ssa/ssa-dse-31.c: New test.
> * gcc.dg/tree-ssa/ssa-dse-32.c: New test.
> 
> 
> 0001-improve-dse.patch
> 
> 
> From 5751eaff3d1c263e8631d5a07e43fecaaa0e9d26 Mon Sep 17 00:00:00 2001
> From: Kugan Vivekanandarajah 
> Date: Tue, 10 Apr 2018 09:49:10 +1000
> Subject: [PATCH] improve dse
> 
> ---
>  gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-31.c | 16 ++
>  gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-32.c | 23 ++
>  gcc/tree-ssa-dse.c | 51 
> --
>  3 files changed, 81 insertions(+), 9 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-31.c
>  create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-32.c
> 

> diff --git a/gcc/tree-ssa-dse.c b/gcc/tree-ssa-dse.c
> index 9220fea..3513fda 100644
> --- a/gcc/tree-ssa-dse.c
> +++ b/gcc/tree-ssa-dse.c
> @@ -521,11 +521,11 @@ live_bytes_read (ao_ref use_ref, ao_ref *ref, sbitmap 
> live)
> Return TRUE if the above conditions are met, otherwise FALSE.  */
>  
>  static dse_store_status
> -dse_classify_store (ao_ref *ref, gimple *stmt, gimple **use_stmt,
> - bool byte_tracking_enabled, sbitmap live_bytes)
> +dse_classify_store (ao_ref *ref, gimple *stmt_outer, gimple *stmt,
> + gimple **use_stmt, bool byte_tracking_enabled,
> + sbitmap live_bytes, unsigned cnt = 0)
>  {
>gimple *temp;
> -  unsigned cnt = 0;
>  
>*use_stmt = NULL;
>  
> @@ -556,9 +556,11 @@ dse_classify_store (ao_ref *ref, gimple *stmt, gimple 
> **use_stmt,
>   {
> cnt++;
>  
> +   if (use_stmt == stmt_outer)
> + continue;
So is this really safe?  This seems to catch the case where the
recursive call stumbles onto the same statement we're already
processing.  ie, we've followed a loop backedge.

ISTM that further analysis here  is needed -- don't you have to make
sure that USE_STMT does not read from REF?  It could be a memmove call
for example.

I'm also struggling a little bit to see much value in handling this
case.  In the included testcases we've got a memset in a loop where the
args do not vary across the loop iterations and there are no reads from
the memory location within the loop. How realistic is that?


If you're looking to improve DSE, the cases in 63185, 64380 and 79958
may be interesting.

Re: [PATCH] [configure] Added "nfp" to the build for binutils.

[Francois H. Theron]

Hi

Thank you. The last thing would be config.sub, do I submit the
accepted patch for it here as well or will it propagate from
config.git?

Francois

Re: [PATCH] [configure] Added "nfp" to the build for binutils.

[Nick Clifton]

Hi Francois,

> 2018-05-01  Francois H. Theron  
> 
>   * configure.ac: Added "nfp" target.
>   * configure: Regenerate.

I have applied this change patch to both the gcc and binutils mainline sources.

Cheers
  Nick

Re: [PATCH] Re: Broken links in INSTALL/specific.html (PR web/85578)

[Joseph Myers]

On Tue, 1 May 2018, Jakub Jelinek wrote:

> On Tue, May 01, 2018 at 09:27:01AM +0200, Jakub Jelinek wrote:
> > PR web/85578 complains about broken links in INSTALL/specific.html inside of
> > the rc tarballs, I've looked at past releases and at least the releases I've
> > checked (4.7.0, 6.1, 7.1, 7.3, 8.1rc2) all have the broken links,
> > e.g.
> > aarch64*-*-*
> > and
> >  > name="aarch64_002a_002d_002a_002d_002a">
> > aarch64*-*-*
> > Looking at online docs, they are ok.
> 
> Now in patch form, briefly tested with a hacked gcc_release script (so that
> it works even with uncommitted install.texi2html).  Ok for trunk/8.1?

OK.

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

Re: [PATCH] POPCOUNT folding optimizations

[Jeff Law]

On 05/01/2018 02:48 AM, Marc Glisse wrote:
> On Mon, 30 Apr 2018, Jeff Law wrote:
> 
>> On 02/09/2018 05:42 AM, Roger Sayle wrote:
>>> The following patch implements a number of __builtin_popcount related
>>> optimizations.
>>> (i) popcount(x) == 0 can be simplified to x==0, and popcount(x) != 0 to
>>> x!=0.
>>> (ii) popcount(x&1) can be simplified to x&1, and for unsigned x,
>>> popcount(x>>31) to x>>31.
>>> (iii) popcount (x&6) + popcount(y&16) can be simplified to
>>> popcount((x&6)|(y&16))
>>>
>>> These may seem obscure transformations, but performing these types of
>>> POPCOUNT
>>> operations are often the performance critical steps in some
>>> cheminformatics
>>> applications.
>>>
>>> To implement the above transformations I've introduced the
>>> tree_nonzero_bits
>>> function,
>>> which is a tree-level version of rtlanal's nonzero_bits used by the RTL
>>> optimizers.
>>>
>>> The following patch has been tested on x86_64-pc-linux-gnu with a "make
>>> bootstrap"
>>> and "make check" with no regressions, and passes for the four new gcc.dg
>>> test cases.
>>>
>>> Many thanks In advance.  Best regards,
>>>
>>> Roger
>>> -- 
>>> Roger Sayle, PhD.
>>> NextMove Software Limited
>>> Innovation Centre (Unit 23), Cambridge Science Park, Cambridge, CB4 0EY
>>>
>>> 2018-02-09  Roger Sayle  
>>>
>>>     * fold-const.c (tree_nonzero_bits): New function.
>>>     * fold-const.h (tree_nonzero_bits): Likewise.
>>>     * match.pd (POPCOUNT): New patterns to fold BUILTIN_POPCOUNT and
>>>     friends.  POPCOUNT(x&1) => x&1, POPCOUNT(x)==0 => x==0, etc.
>>>
>>> 2018-02-09  Roger Sayle  
>>>
>>>     * gcc.dg/fold-popcount-1.c: New testcase.
>>>     * gcc.dg/fold-popcount-2.c: New testcase.
>>>     * gcc.dg/fold-popcount-3.c: New testcase.
>>>     * gcc.dg/fold-popcount-4.c: New testcase.
>>>
>>>
>>>
>>>
>>> Index: gcc/fold-const.c
>>> ===
>>> --- gcc/fold-const.c    (revision 257227)
>>> +++ gcc/fold-const.c    (working copy)
>>> @@ -14580,6 +14580,75 @@
>>>    return string + offset;
>>>  }
>>>
>>> +/* Given a tree T, compute which bits in T may be nonzero.  */
>>> +
>>> +wide_int
>>> +tree_nonzero_bits (const_tree t)
>>> +{
>>> +  switch (TREE_CODE (t))
>>> +    {
>>> +    case BIT_IOR_EXPR:
>>> +    case BIT_XOR_EXPR:
>>> +  return wi::bit_or (tree_nonzero_bits (TREE_OPERAND (t, 0)),
>>> + tree_nonzero_bits (TREE_OPERAND (t, 1)));
>> Hmm.   I think this will potentially have too many bits set in the
>> BIT_XOR case.  Is there some reason you didn't use wi::bit_xor for that
>> case?
> 
> You cannot use bit_xor because the bits are only *possibly* set (same as
> you can't say anything about BIT_NOT_EXPR). We would need to also track
> the bits *certainly* set to start doing clever stuff, and for
> BIT_XOR_EXPR that would still be inconvenient.
Yea, I realized it was a may vs must issue after I signed off for the night.

jeff

Re: [PATCHv2] PR libstdc++/84654 Do not use __float128 if it is disabled by the compiler

[Jonathan Wakely]

On 12/03/18 16:02 -0300, Tulio Magno Quites Machado Filho wrote:

Changes since v1:
- Completely rewrite of the patch to set ENABLE_FLOAT128 at libstdc++
  build time and undef _GLIBCXX_USE_FLOAT128 when building user code.

--- 8< ---

In order to use __float128 in C++ it's necessary to check if the
compiler enabled its support too when building user code.
This patch changes the behavior at libstdc++ build by setting
ENABLE_FLOAT128, which is used to set the value of the exported macro
_GLIBCXX_USE_FLOAT128.


Now that we're in stage 1 we can make this change. The patch looks
right so I'll go ahead and commit it to trunk (it shouldn't interfere
with testing any last-minute fixes needed for gcc-8).

Thanks for fixing this, Tulio.

libgo patch committed (GCC 8 RFA): more fixes for Solaris assembler

[Ian Lance Taylor]

There are even more varieties of the Solaris assembler syntax on
different platforms, as discussed on PR 85429.  This patch by Rainer
Orth should address them all, I hope.  Committed to mainline.

OK for GCC 8 branch?

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 259719)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-32861fd0acb0f3232f66be4791388b27e71c9990
+380527c032f02446438c71b0ac0026bcab416be5
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: libgo/go/cmd/go/internal/work/buildid.go
===
--- libgo/go/cmd/go/internal/work/buildid.go(revision 259719)
+++ libgo/go/cmd/go/internal/work/buildid.go(working copy)
@@ -303,16 +303,35 @@ func (b *Builder) gccgoToolID(name, lang
return id, nil
 }
 
+// Check if assembler used by gccgo is GNU as.
+func assemblerIsGas() bool {
+   cmd := exec.Command(BuildToolchain.compiler(), "-print-prog-name=as")
+   assembler, err := cmd.Output()
+   if err == nil {
+   cmd := exec.Command(strings.TrimSpace(string(assembler)), 
"--version")
+   out, err := cmd.Output()
+   if err == nil && strings.Contains(string(out), "GNU") {
+   return true
+   } else {
+   return false
+   }
+   } else {
+   return false
+   }
+}
+
 // gccgoBuildIDELFFile creates an assembler file that records the
 // action's build ID in an SHF_EXCLUDE section.
 func (b *Builder) gccgoBuildIDELFFile(a *Action) (string, error) {
sfile := a.Objdir + "_buildid.s"
 
var buf bytes.Buffer
-   if cfg.Goos != "solaris" {
+   if cfg.Goos != "solaris" || assemblerIsGas() {
fmt.Fprintf(, "\t"+`.section .go.buildid,"e"`+"\n")
-   } else {
+   } else if cfg.Goarch == "sparc" || cfg.Goarch == "sparc64" {
fmt.Fprintf(, "\t"+`.section ".go.buildid",#exclude`+"\n")
+   } else { // cfg.Goarch == "386" || cfg.Goarch == "amd64"
+   fmt.Fprintf(, "\t"+`.section .go.buildid,#exclude`+"\n")
}
fmt.Fprintf(, "\t.byte ")
for i := 0; i < len(a.buildID); i++ {

Re: C++ PATCH for c++/85580, wrong name class error with extern "C" locals

[Jason Merrill]

On Tue, May 1, 2018 at 9:18 AM, Jakub Jelinek  wrote:
> On Tue, May 01, 2018 at 08:52:42AM -0400, Jason Merrill wrote:
>> It wasn't a problem before that we didn't check for namespace scope,
>> because we were only looking at functions.  Now that we look at
>> variables as well, we need to consider their scope.
>>
>> Tested x86_64-pc-linux-gnu, applying to trunk.  Jakub, this looks like
>> a P1, should it go into 8.1 as well?
>
> I think this should be safe even without another rc, please check it into
> 8.1.

Done.

Jason

Re: gcc 8 trunk broken O3 on x86_64

[Jeff Law]

On 04/30/2018 06:37 AM, Richard Biener wrote:
> On Fri, Apr 27, 2018 at 9:21 AM, graham stott via gcc-patches
>  wrote:
>> All
>> Just a heads the trunk has been broken since about Weds most files fail 
>> compare during bootstrap at O3 but pass at O2
>> My last succesful boostrap at O3 was Tuesday
>> I no idea which commit caused it
> 
> Should be fixed now.
As is the hppa comparison failure.  It bisected down to the checking
change as well.

jeff

Re: [PATCH] Handle empty infinite loops in OpenACC for PR84955

[Tom de Vries]

On 04/16/2018 08:13 PM, Tom de Vries wrote:

On 04/12/2018 08:58 PM, Jakub Jelinek wrote:

On Thu, Apr 12, 2018 at 11:39:43AM -0700, Cesar Philippidis wrote:

Strange. I didn't observe any regressions when I tested it. But, then
again, I was testing against revision

r259092 | jason | 2018-04-04 09:42:55 -0700 (Wed, 04 Apr 2018) | 4 lines

which is over a week old. I'll revert that patch for now, and revisit
this issue in stage1.


You should have kept the omp-expand.c chunk, that is correct and 
shouldn't

cause issues.


Committed as attached (with correct changelog entry, the previously 
committed patch had an incorrect one).




Backported to gcc-7-branch as attached.

Thanks,
- Tom


diff --git a/gcc/omp-expand.c b/gcc/omp-expand.c
index bb20490..c7d30ea 100644
--- a/gcc/omp-expand.c
+++ b/gcc/omp-expand.c
@@ -5439,6 +5439,14 @@ expand_oacc_for (struct omp_region *region, struct 
omp_for_data *fd)
  
  	  split->flags ^= EDGE_FALLTHRU | EDGE_TRUE_VALUE;
  
+	  /* Add a dummy exit for the tiled block when cont_bb is missing.  */

+ if (cont_bb == NULL)
+   {
+ edge e = make_edge (body_bb, exit_bb, EDGE_FALSE_VALUE);
+ e->probability = profile_probability::even ();
+ split->probability = profile_probability::even ();
+   }
+
  /* Initialize the user's loop vars.  */
  gsi = gsi_start_bb (elem_body_bb);
  expand_oacc_collapse_vars (fd, true, , counts, e_offset);


backport "[openacc] Fix ICE when compiling tile loop containing infinite loop"

2018-04-16  Tom de Vries  

	backport from trunk:
	2018-04-16  Cesar Philippidis  
		Tom de Vries  

	PR middle-end/84955
	* omp-expand.c (expand_oacc_for): Add dummy false branch for
	tiled basic blocks without omp continue statements.

	* testsuite/libgomp.oacc-c-c++-common/pr84955.c: New test.
	* testsuite/libgomp.oacc-fortran/pr84955.f90: New test.

---
 gcc/omp-expand.c  |  8 
 libgomp/testsuite/libgomp.oacc-c-c++-common/pr84955.c | 15 +++
 libgomp/testsuite/libgomp.oacc-fortran/pr84955.f90| 13 +
 3 files changed, 36 insertions(+)

diff --git a/gcc/omp-expand.c b/gcc/omp-expand.c
index a1e668d..549a5db 100644
--- a/gcc/omp-expand.c
+++ b/gcc/omp-expand.c
@@ -5628,6 +5628,14 @@ expand_oacc_for (struct omp_region *region, struct omp_for_data *fd)
 
 	  split->flags ^= EDGE_FALLTHRU | EDGE_TRUE_VALUE;
 
+	  /* Add a dummy exit for the tiled block when cont_bb is missing.  */
+	  if (cont_bb == NULL)
+	{
+	  edge e = make_edge (body_bb, exit_bb, EDGE_FALSE_VALUE);
+	  e->probability = PROB_EVEN;
+	  split->probability = PROB_EVEN;
+	}
+
 	  /* Initialize the user's loop vars.  */
 	  gsi = gsi_start_bb (elem_body_bb);
 	  expand_oacc_collapse_vars (fd, true, , counts, e_offset);
diff --git a/libgomp/testsuite/libgomp.oacc-c-c++-common/pr84955.c b/libgomp/testsuite/libgomp.oacc-c-c++-common/pr84955.c
new file mode 100644
index 000..e528faa
--- /dev/null
+++ b/libgomp/testsuite/libgomp.oacc-c-c++-common/pr84955.c
@@ -0,0 +1,15 @@
+/* { dg-do compile }  */
+
+int
+main (void)
+{
+  int i, j;
+
+#pragma acc parallel loop tile(2,3)
+  for (i = 1; i < 10; i++)
+for (j = 1; j < 10; j++)
+  for (;;)
+	;
+
+  return i + j;
+}
diff --git a/libgomp/testsuite/libgomp.oacc-fortran/pr84955.f90 b/libgomp/testsuite/libgomp.oacc-fortran/pr84955.f90
new file mode 100644
index 000..dc85865
--- /dev/null
+++ b/libgomp/testsuite/libgomp.oacc-fortran/pr84955.f90
@@ -0,0 +1,13 @@
+! { dg-do compile }
+
+subroutine s
+   integer :: i, j
+   !$acc parallel loop tile(2,3)
+   do i = 1, 10
+  do j = 1, 10
+ do
+ end do
+  end do
+   end do
+  !$acc end parallel loop
+end subroutine s

Re: C++ PATCH for c++/85580, wrong name class error with extern "C" locals

[Jakub Jelinek]

On Tue, May 01, 2018 at 08:52:42AM -0400, Jason Merrill wrote:
> It wasn't a problem before that we didn't check for namespace scope,
> because we were only looking at functions.  Now that we look at
> variables as well, we need to consider their scope.
> 
> Tested x86_64-pc-linux-gnu, applying to trunk.  Jakub, this looks like
> a P1, should it go into 8.1 as well?

I think this should be safe even without another rc, please check it into
8.1.

Thanks.

> commit a97af841718779b615bd0a599cac956396c8c85a
> Author: Jason Merrill 
> Date:   Mon Apr 30 17:37:20 2018 -0400
> 
> PR c++/85580 - extern "C" and local variables
> 
> * name-lookup.c (check_extern_c_conflict): Ignore local decls.
> 
> diff --git a/gcc/cp/name-lookup.c b/gcc/cp/name-lookup.c
> index 2af2462825c..64c7b6f006e 100644
> --- a/gcc/cp/name-lookup.c
> +++ b/gcc/cp/name-lookup.c
> @@ -2527,6 +2527,10 @@ check_extern_c_conflict (tree decl)
>if (DECL_ARTIFICIAL (decl) || DECL_IN_SYSTEM_HEADER (decl))
>  return;
>  
> +  /* This only applies to decls at namespace scope.  */
> +  if (!DECL_NAMESPACE_SCOPE_P (decl))
> +return;
> +
>if (!extern_c_decls)
>  extern_c_decls = hash_table::create_ggc (127);
>  
> diff --git a/gcc/testsuite/g++.dg/parse/extern-C-2.C 
> b/gcc/testsuite/g++.dg/parse/extern-C-2.C
> new file mode 100644
> index 000..d8a4e14b4b7
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/parse/extern-C-2.C
> @@ -0,0 +1,22 @@
> +// PR c++/85580
> +
> +extern "C"
> +{
> +
> +  void f1()
> +  {
> +union some_type{
> +  char a[2];
> +  int b;
> +} variable;
> +  }
> +
> +  void f2()
> +  {
> +union some_type{
> +  char a[2];
> +  int b;
> +} variable;
> +  }
> +
> +}

Jakub

C++ PATCH for c++/85580, wrong name class error with extern "C" locals

[Jason Merrill]

It wasn't a problem before that we didn't check for namespace scope,
because we were only looking at functions.  Now that we look at
variables as well, we need to consider their scope.

Tested x86_64-pc-linux-gnu, applying to trunk.  Jakub, this looks like
a P1, should it go into 8.1 as well?
commit a97af841718779b615bd0a599cac956396c8c85a
Author: Jason Merrill 
Date:   Mon Apr 30 17:37:20 2018 -0400

PR c++/85580 - extern "C" and local variables

* name-lookup.c (check_extern_c_conflict): Ignore local decls.

diff --git a/gcc/cp/name-lookup.c b/gcc/cp/name-lookup.c
index 2af2462825c..64c7b6f006e 100644
--- a/gcc/cp/name-lookup.c
+++ b/gcc/cp/name-lookup.c
@@ -2527,6 +2527,10 @@ check_extern_c_conflict (tree decl)
   if (DECL_ARTIFICIAL (decl) || DECL_IN_SYSTEM_HEADER (decl))
 return;
 
+  /* This only applies to decls at namespace scope.  */
+  if (!DECL_NAMESPACE_SCOPE_P (decl))
+return;
+
   if (!extern_c_decls)
 extern_c_decls = hash_table::create_ggc (127);
 
diff --git a/gcc/testsuite/g++.dg/parse/extern-C-2.C b/gcc/testsuite/g++.dg/parse/extern-C-2.C
new file mode 100644
index 000..d8a4e14b4b7
--- /dev/null
+++ b/gcc/testsuite/g++.dg/parse/extern-C-2.C
@@ -0,0 +1,22 @@
+// PR c++/85580
+
+extern "C"
+{
+
+  void f1()
+  {
+union some_type{
+  char a[2];
+  int b;
+} variable;
+  }
+
+  void f2()
+  {
+union some_type{
+  char a[2];
+  int b;
+} variable;
+  }
+
+}

Re: [PATCH] [configure] Added "nfp" to the build for binutils.

[Francois H. Theron]

On 30 April 2018 at 21:52, Joel Brobecker  wrote:
>> +2018-04-30  Francois H. Theron 
>> +
>> + * config.sub: Added "nfp" to basic_machine list.
>> + * configure.ac: Added "nfp" target.
>> + * configure: Regenerate.
>
> I am not a maintainer, but I noticed that config.sub is not being
> modified by this commit -- a small discrepancy between the patch
> and the propose ChangeLog entry.

That was a mistake when splitting the diff to have config.sub
separate. For the record, it has been accepted here after the
maintainer graciously added a ChangeLog entry and a test-case:
http://git.savannah.gnu.org/cgit/config.git/commit/?id=d23f148145b62e7dea44581097f60358118f87f8

For this patch, I can resubmit a new patch with the config.sub line
removed from ChangeLog or ask that the maintainer removes this one
line when committing. Or if I misunderstood the contribution process I
can add the now accepted config.sub to the patch and not change the
ChangeLog.

Francois

Re: [PATCH] Fix the GNU Stack markings on libgcc.a

[Magnus Granberg]

tisdag 1 maj 2018 kl. 12:33:33 CEST skrev  Jakub Jelinek:
> On Tue, May 01, 2018 at 12:24:44PM +0200, Magnus Granberg wrote:
> > Hi
> > 
> > The *_resms64*.S files in libgcc don't have section to remove the
> > executable stack marking. Can this be added to Gcc 8.0 Rc?
> > 
> > gcc/ChangeLog:
> > 
> > 2018-05-01  Magnus Granberg  
> > 
> > * config/i386/cet.h: Add section to remove executable stack marking.
> 
> This is incorrect, the cet.h header is an installed header that has nothing
> to do with whether executable stack is needed or not.
> 
> The right spot is either the libgcc/config/i386/i386-asm.h header, or
> the libgcc/config/i386/*ms64*.h headers.
> 
> And I don't see anything release critical on this, these files are only in
> libgcc.a and only linked in if somebody uses the ms ABI stuff.  I think it
> can be fixed in 9.0/8.2+ only.
> 
> > --- a/gcc/config/i386/cet.h 2018-04-20 15:30:13.0 +0200
> > +++ b/gcc/config/i386/cet.h 2018-05-01 11:45:53.762906162 +0200
> > @@ -87,6 +87,9 @@
> > 
> >  4:
> > .popsection
> >  
> >  #  endif /* __CET__ */
> > 
> > +#  ifdef __linux__
> > +.section .note.GNU-stack,"",%progbits
> > +#  endif
> > 
> >  # endif /* __ELF__ */
> >  #endif /* __ASSEMBLER__ */
> 
>   Jakub
New patch

libgcc/ChangeLog:

2018-05-01  Magnus Granberg  

* config/i386/resms64.h: Add .note.GNU-stack section
* config/i386/resms64f.h: Likewise.
* config/i386/resms64fx.h: Likewise.
* config/i386/resms64x.h: Likewise.
* config/i386/savms64.h: Likewise.
* config/i386/savms64f.h: Likewise.

---
--- a/libgcc/config/i386/resms64.h	2018-01-03 11:03:58.0 +0100
+++ b/libgcc/config/i386/resms64.h	2018-05-01 12:59:48.942833419 +0200
@@ -57,3 +57,6 @@ MS2SYSV_STUB_END(resms64_17)
 MS2SYSV_STUB_END(resms64_18)
 
 #endif /* __x86_64__ */
+#if defined(__linux__) && defined(__ELF__)
+.section .note.GNU-stack,"",%progbits
+#endif
--- a/libgcc/config/i386/resms64f.h	2018-01-03 11:03:58.0 +0100
+++ b/libgcc/config/i386/resms64f.h	2018-05-01 13:00:23.422832853 +0200
@@ -55,3 +55,6 @@ MS2SYSV_STUB_END(resms64f_16)
 MS2SYSV_STUB_END(resms64f_17)
 
 #endif /* __x86_64__ */
+#if defined(__linux__) && defined(__ELF__)
+.section .note.GNU-stack,"",%progbits
+#endif
--- a/libgcc/config/i386/resms64fx.h	2018-02-26 20:46:34.0 +0100
+++ b/libgcc/config/i386/resms64fx.h	2018-05-01 13:06:49.682826518 +0200
@@ -62,3 +62,6 @@ MS2SYSV_STUB_END(resms64fx_16)
 MS2SYSV_STUB_END(resms64fx_17)
 
 #endif /* __x86_64__ */
+#if defined(__linux__) && defined(__ELF__)
+.section .note.GNU-stack,"",%progbits
+#endif
--- a/libgcc/config/i386/resms64x.h	2018-02-26 20:46:34.0 +0100
+++ b/libgcc/config/i386/resms64x.h	2018-05-01 13:07:21.702825993 +0200
@@ -63,3 +63,6 @@ MS2SYSV_STUB_END(resms64x_17)
 MS2SYSV_STUB_END(resms64x_18)
 
 #endif /* __x86_64__ */
+#if defined(__linux__) && defined(__ELF__)
+.section .note.GNU-stack,"",%progbits
+#endif
--- a/libgcc/config/i386/savms64.h	2018-01-03 11:03:58.0 +0100
+++ b/libgcc/config/i386/savms64.h	2018-05-01 13:07:48.952825546 +0200
@@ -57,3 +57,6 @@ MS2SYSV_STUB_END(savms64_17)
 MS2SYSV_STUB_END(savms64_18)
 
 #endif /* __x86_64__ */
+#if defined(__linux__) && defined(__ELF__)
+.section .note.GNU-stack,"",%progbits
+#endif
--- a/libgcc/config/i386/savms64f.h	2018-01-03 11:03:58.0 +0100
+++ b/libgcc/config/i386/savms64f.h	2018-05-01 13:08:30.082824871 +0200
@@ -55,3 +55,6 @@ MS2SYSV_STUB_END(savms64f_16)
 MS2SYSV_STUB_END(savms64f_17)
 
 #endif /* __x86_64__ */
+#if defined(__linux__) && defined(__ELF__)
+.section .note.GNU-stack,"",%progbits
+#endif

Re: [PATCH] Add fix-it hint for missing return statement in assignment operators (PR c++/85523)

[Nathan Sidwell]

On 04/30/2018 08:29 PM, David Malcolm wrote:

Following on from the thread on the "gcc" list here:

   https://gcc.gnu.org/ml/gcc/2018-04/msg00172.html

here's an updated version of Jonathan's patch, which:



+   {
+ tree valtype = TREE_TYPE (DECL_RESULT (fndecl));
+ if (TREE_CODE (valtype) == REFERENCE_TYPE
+ && same_type_ignoring_top_level_qualifiers_p
+ (TREE_TYPE (valtype), TREE_TYPE (current_class_ref)))


While this is probably close enough, you could
*) use convert_to_base to include cases where the return type's a base 
of the current object.
*) convert_to_base would also allow dropping the REFERENCE_TYPE check 
here, so icky code returning by-value could also be caught.


Up to you.  But otherwise ok.

nathan

--
Nathan Sidwell

Re: [PATCH] Fix the GNU Stack markings on libgcc.a

[Jakub Jelinek]

On Tue, May 01, 2018 at 12:24:44PM +0200, Magnus Granberg wrote:
> Hi
> 
> The *_resms64*.S files in libgcc don't have section to remove the
> executable stack marking. Can this be added to Gcc 8.0 Rc?
> 
> gcc/ChangeLog:
> 
> 2018-05-01  Magnus Granberg  
> 
>   * config/i386/cet.h: Add section to remove executable stack marking.

This is incorrect, the cet.h header is an installed header that has nothing
to do with whether executable stack is needed or not.

The right spot is either the libgcc/config/i386/i386-asm.h header, or
the libgcc/config/i386/*ms64*.h headers.

And I don't see anything release critical on this, these files are only in
libgcc.a and only linked in if somebody uses the ms ABI stuff.  I think it
can be fixed in 9.0/8.2+ only.

> --- a/gcc/config/i386/cet.h   2018-04-20 15:30:13.0 +0200
> +++ b/gcc/config/i386/cet.h   2018-05-01 11:45:53.762906162 +0200
> @@ -87,6 +87,9 @@
>  4:
>   .popsection
>  #  endif /* __CET__ */
> +#  ifdef __linux__
> +.section .note.GNU-stack,"",%progbits
> +#  endif
>  # endif /* __ELF__ */
>  #endif /* __ASSEMBLER__ */
>  


Jakub

[PATCH] Fix the GNU Stack markings on libgcc.a

[Magnus Granberg]

Hi

The *_resms64*.S files in libgcc don't have section to remove the
executable stack marking. Can this be added to Gcc 8.0 Rc?

gcc/ChangeLog:

2018-05-01  Magnus Granberg  

* config/i386/cet.h: Add section to remove executable stack marking.

---
--- a/gcc/config/i386/cet.h	2018-04-20 15:30:13.0 +0200
+++ b/gcc/config/i386/cet.h	2018-05-01 11:45:53.762906162 +0200
@@ -87,6 +87,9 @@
 4:
 	.popsection
 #  endif /* __CET__ */
+#  ifdef __linux__
+.section .note.GNU-stack,"",%progbits
+#  endif
 # endif /* __ELF__ */
 #endif /* __ASSEMBLER__ */
 

[PATCH] Build i386's crti.o and crtn.o for x86_64-*-rtems*

[Amaan Cheval]

Hi!

The x86_64 RTEMS target doesn't currently have gcc build crti.o and crtn.o. This
surfaces as undefined references to "_fini", which RTEMS references in its
kernel:
https://git.rtems.org/rtems/tree/cpukit/libcsupport/src/newlibc_exit.c#n39

Most other architectures deal with this by adding crti.o to the startfile in
bsp_specs:
https://git.rtems.org/rtems/tree/bsps/i386/pc386/start/bsp_specs#n6

This patch uses GCC's i386's crti.S and crtn.S (since x86_64-*-* targets use
"cpu_type=i386") as the source for the object files:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libgcc/config/i386/crti.S;h=c25e8f9e3ab45e935f6287d5ed3a8437a289e059;hb=HEAD

The patch is as follows:

libgcc/ChangeLog:

2018-05-01  Amaan Cheval  

* config.host: Build i386's crti.o and crtn.o for x86_64-*-rtems*

Index: libgcc/config.host
===
--- libgcc/config.host  (revision 259789)
+++ libgcc/config.host  (working copy)
@@ -611,6 +611,11 @@ i[34567]86-*-elf*)
;;
 x86_64-*-elf* | x86_64-*-rtems*)
tmake_file="$tmake_file i386/t-crtstuff t-crtstuff-pic t-libgcc-pic"
+   case ${host} in
+   x86_64-*-rtems*)
+ extra_parts="$extra_parts crti.o crtn.o"
+ ;;
+   esac
;;
 x86_64-*-fuchsia*)
tmake_file="$tmake_file t-libgcc-pic"

Re: [PATCH] POPCOUNT folding optimizations

[Marc Glisse]

On Mon, 30 Apr 2018, Jeff Law wrote:


On 02/09/2018 05:42 AM, Roger Sayle wrote:

The following patch implements a number of __builtin_popcount related
optimizations.
(i) popcount(x) == 0 can be simplified to x==0, and popcount(x) != 0 to
x!=0.
(ii) popcount(x&1) can be simplified to x&1, and for unsigned x,
popcount(x>>31) to x>>31.
(iii) popcount (x&6) + popcount(y&16) can be simplified to
popcount((x&6)|(y&16))

These may seem obscure transformations, but performing these types of
POPCOUNT
operations are often the performance critical steps in some cheminformatics
applications.

To implement the above transformations I've introduced the tree_nonzero_bits
function,
which is a tree-level version of rtlanal's nonzero_bits used by the RTL
optimizers.

The following patch has been tested on x86_64-pc-linux-gnu with a "make
bootstrap"
and "make check" with no regressions, and passes for the four new gcc.dg
test cases.

Many thanks In advance.  Best regards,

Roger
--
Roger Sayle, PhD.
NextMove Software Limited
Innovation Centre (Unit 23), Cambridge Science Park, Cambridge, CB4 0EY

2018-02-09  Roger Sayle  

* fold-const.c (tree_nonzero_bits): New function.
* fold-const.h (tree_nonzero_bits): Likewise.
* match.pd (POPCOUNT): New patterns to fold BUILTIN_POPCOUNT and
friends.  POPCOUNT(x&1) => x&1, POPCOUNT(x)==0 => x==0, etc.

2018-02-09  Roger Sayle  

* gcc.dg/fold-popcount-1.c: New testcase.
* gcc.dg/fold-popcount-2.c: New testcase.
* gcc.dg/fold-popcount-3.c: New testcase.
* gcc.dg/fold-popcount-4.c: New testcase.




Index: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 257227)
+++ gcc/fold-const.c(working copy)
@@ -14580,6 +14580,75 @@
   return string + offset;
 }

+/* Given a tree T, compute which bits in T may be nonzero.  */
+
+wide_int
+tree_nonzero_bits (const_tree t)
+{
+  switch (TREE_CODE (t))
+{
+case BIT_IOR_EXPR:
+case BIT_XOR_EXPR:
+  return wi::bit_or (tree_nonzero_bits (TREE_OPERAND (t, 0)),
+tree_nonzero_bits (TREE_OPERAND (t, 1)));

Hmm.   I think this will potentially have too many bits set in the
BIT_XOR case.  Is there some reason you didn't use wi::bit_xor for that
case?


You cannot use bit_xor because the bits are only *possibly* set (same as 
you can't say anything about BIT_NOT_EXPR). We would need to also track 
the bits *certainly* set to start doing clever stuff, and for BIT_XOR_EXPR 
that would still be inconvenient.


--
Marc Glisse

Re: [PATCH] POPCOUNT folding optimizations

[Marc Glisse]

(I am not a reviewer, just commenting)

On Fri, 9 Feb 2018, Roger Sayle wrote:


The following patch implements a number of __builtin_popcount related
optimizations.
(i) popcount(x) == 0 can be simplified to x==0, and popcount(x) != 0 to
x!=0.
(ii) popcount(x&1) can be simplified to x&1, and for unsigned x,
popcount(x>>31) to x>>31.
(iii) popcount (x&6) + popcount(y&16) can be simplified to
popcount((x&6)|(y&16))

These may seem obscure transformations, but performing these types of 
POPCOUNT operations are often the performance critical steps in some 
cheminformatics applications.


To implement the above transformations I've introduced the 
tree_nonzero_bits function, which is a tree-level version of rtlanal's 
nonzero_bits used by the RTL optimizers.


I am wondering if this brings much, compared to just using 
get_nonzero_bits (works on INTEGER_CST / SSA_NAME, matched by 
with_possible_nonzero_bits). If we do decide to introduce this function, 
we probably want to use it in other places that currently use 
get_nonzero_bits as well...



+case NOP_EXPR:
+case CONVERT_EXPR:


We have CASE_CONVERT: for this pair.


+case LSHIFT_EXPR:
+  if (TREE_CODE (TREE_OPERAND (t, 1)) == INTEGER_CST)


Maybe check INTEGRAL_TYPE_P as well, like you did for PLUS_EXPR? Or was 
that also unnecessary for PLUS_EXPR?



+ return wi::neg_p (arg1)
+? wi::rshift (nzbits, -arg1, TYPE_SIGN (type))
+: wi::lshift (nzbits, arg1);


I can see that fold-const.c already does something like that. I am 
surprised the sanitizer guys haven't asked that we just punt on 
negative values instead.



--- gcc/match.pd(revision 257227)
+++ gcc/match.pd(working copy)
@@ -4648,3 +4648,24 @@
|| wi::geu_p (wi::to_wide (@rpos),
  wi::to_wide (@ipos) + isize))
 (BIT_FIELD_REF @0 @rsize @rpos)
+
+/* POPCOUNT simplifications.  */
+(for popcount (BUILT_IN_POPCOUNT BUILT_IN_POPCOUNTL BUILT_IN_POPCOUNTLL
+   BUILT_IN_POPCOUNTIMAX)
+  /* popcount(X&1) is nop_expr(X&1).  */
+  (simplify
+(popcount @0)
+(if (tree_nonzero_bits (@0) == 1)
+  (convert @0)))


Good thing we can't call popcount on signed 1-bit types ;-)


+  /* popcount(X) + popcount(Y) is popcount(X|Y) when X must be zero.  */
+  (simplify
+(plus (popcount @0) (popcount @1))


We probably want :s on both popcount: if they are used in other places 
than just this addition, it is likely cheaper not to introduce a new call 
to popcount.



+(if (wi::bit_and (tree_nonzero_bits (@0), tree_nonzero_bits (@1)) == 0)
+  (popcount (bit_ior @0 @1


We'll have to be careful if we ever turn popcount into something generic, 
but the current situation indeed should safely guarantee that @0 and @1 
have the same type.



+  /* pocount(X) == 0 is X == 0, and related (in)equalities.  */


po+p+count


+  (for cmp (le eq ne gt)
+   rep (eq eq ne ne)
+(simplify
+  (cmp (popcount @0) zerop)


Might as well use integer_zerop when we know we are dealing with integers.


+  (rep @0 { build_zero_cst (TREE_TYPE (@0)); }



Nice patch :-)

--
Marc Glisse

[PATCH] Re: Broken links in INSTALL/specific.html (PR web/85578)

[Jakub Jelinek]

On Tue, May 01, 2018 at 09:27:01AM +0200, Jakub Jelinek wrote:
> PR web/85578 complains about broken links in INSTALL/specific.html inside of
> the rc tarballs, I've looked at past releases and at least the releases I've
> checked (4.7.0, 6.1, 7.1, 7.3, 8.1rc2) all have the broken links,
> e.g.
> aarch64*-*-*
> and
>  name="aarch64_002a_002d_002a_002d_002a">
> aarch64*-*-*
> Looking at online docs, they are ok.

Now in patch form, briefly tested with a hacked gcc_release script (so that
it works even with uncommitted install.texi2html).  Ok for trunk/8.1?

2018-05-01  Jakub Jelinek  

PR web/85578
* doc/install.texi2html: Replace _002d with - and _002a with * in
generated html files using sed.

--- gcc/doc/install.texi2html   (revision 259728)
+++ gcc/doc/install.texi2html   (working copy)
@@ -52,7 +52,10 @@ for x in index.html specific.html prereq
 do
 define=`echo $x | sed -e 's/\.//g'`
 echo "define = $define"
-$MAKEINFO --no-number-sections -I $SOURCEDIR -I $SOURCEDIR/include -I 
$DESTDIR $SOURCEDIR/install.texi --html --no-split -D$define -o$DESTDIR/$x
+$MAKEINFO --no-number-sections -I $SOURCEDIR -I $SOURCEDIR/include -I 
$DESTDIR $SOURCEDIR/install.texi --html --no-split -D$define 
-o$DESTDIR/temp.html
+# Use sed to work around makeinfo 4.7 brokenness.
+sed -e 's/_002d/-/g' -e 's/_002a/*/g' $DESTDIR/temp.html > $DESTDIR/$x
+rm $DESTDIR/temp.html
 done
 
 rm $DESTDIR/gcc-vers.texi


Jakub