Re: [PATCH 0/5 v3] Vect peeling cost model

[Robin Dapp]

> So what did actually change?  I'd rather not diff the diffs.  Can you
> provide an incremental change, aka p6 that would apply to the
> previous series instead?

-p6.diff attached which also addresses Richard's remark regarding vf/2.
Note that this applies to the old series but the old series itself (-p3)
doesn't apply to trunk anymore (because of the change in
vect_enhance_data_refs_alignment).

Regards
 Robin

--

gcc/ChangeLog:

2017-05-24  Robin Dapp  

* tree-vect-data-refs.c (vect_get_peeling_costs_all_drs):
Introduce unknown_misalignment parameter and remove vf.
(vect_peeling_hash_get_lowest_cost):
Pass unknown_misalignemtn parameter.
(vect_enhance_data_refs_alignment):
Fix unsupportable data ref treatment.

*** /tmp/qBXCWe_tree-vect-data-refs.c	2017-05-24 13:44:37.939055376 +0200
--- gcc/tree-vect-data-refs.c	2017-05-24 13:44:12.039055376 +0200
***
*** 1239,1252 
  }
  
  /* Get the costs of peeling NPEEL iterations checking data access costs
!for all data refs. */
  
  static void
  vect_get_peeling_costs_all_drs (struct data_reference *dr0,
  unsigned int *inside_cost,
  unsigned int *outside_cost,
  stmt_vector_for_cost *body_cost_vec,
! unsigned int npeel, unsigned int vf)
  {
gimple *stmt = DR_STMT (dr0);
stmt_vec_info stmt_info = vinfo_for_stmt (stmt);
--- 1239,1254 
  }
  
  /* Get the costs of peeling NPEEL iterations checking data access costs
!for all data refs.  If UNKNOWN_MISALIGNMENT is true, we assume DR0's
!misalignment will be zero after peeling.  */
  
  static void
  vect_get_peeling_costs_all_drs (struct data_reference *dr0,
  unsigned int *inside_cost,
  unsigned int *outside_cost,
  stmt_vector_for_cost *body_cost_vec,
! unsigned int npeel,
! bool unknown_misalignment)
  {
gimple *stmt = DR_STMT (dr0);
stmt_vec_info stmt_info = vinfo_for_stmt (stmt);
***
*** 1274,1280 
  
int save_misalignment;
save_misalignment = DR_MISALIGNMENT (dr);
!   if (dr == dr0 && npeel == vf / 2)
  	SET_DR_MISALIGNMENT (dr, 0);
else
  	vect_update_misalignment_for_peel (dr, dr0, npeel);
--- 1276,1282 
  
int save_misalignment;
save_misalignment = DR_MISALIGNMENT (dr);
!   if (unknown_misalignment && dr == dr0)
  	SET_DR_MISALIGNMENT (dr, 0);
else
  	vect_update_misalignment_for_peel (dr, dr0, npeel);
***
*** 1305,1311 
epilogue_cost_vec.create (2);
  
vect_get_peeling_costs_all_drs (elem->dr, _cost, _cost,
!   _cost_vec, elem->npeel, 0);
  
outside_cost += vect_get_known_peeling_cost
  (loop_vinfo, elem->npeel, ,
--- 1307,1313 
epilogue_cost_vec.create (2);
  
vect_get_peeling_costs_all_drs (elem->dr, _cost, _cost,
!   _cost_vec, elem->npeel, false);
  
outside_cost += vect_get_known_peeling_cost
  (loop_vinfo, elem->npeel, ,
***
*** 1517,1522 
--- 1519,1525 
  {
vec datarefs = LOOP_VINFO_DATAREFS (loop_vinfo);
struct loop *loop = LOOP_VINFO_LOOP (loop_vinfo);
+   enum dr_alignment_support supportable_dr_alignment;
struct data_reference *dr0 = NULL, *first_store = NULL;
struct data_reference *dr;
unsigned int i, j;
***
*** 1528,1533 
--- 1531,1538 
unsigned int npeel = 0;
bool one_misalignment_known = false;
bool one_misalignment_unknown = false;
+   bool one_dr_unsupportable = false;
+   struct data_reference *unsupportable_dr = NULL;
unsigned int vf = LOOP_VINFO_VECT_FACTOR (loop_vinfo);
unsigned possible_npeel_number = 1;
tree vectype;
***
*** 1599,1604 
--- 1604,1610 
  	  && !STMT_VINFO_GROUPED_ACCESS (stmt_info))
  	continue;
  
+   supportable_dr_alignment = vect_supportable_dr_alignment (dr, true);
do_peeling = vector_alignment_reachable_p (dr);
if (do_peeling)
  {
***
*** 1637,1644 
  		  else
  		possible_npeel_number = vf / nelements;
  
! 		  /* NPEEL_TMP is 0 when there is no misalignment, increment
! 		 the peeling amount by one in order to ...  */
  		  if (DR_MISALIGNMENT (dr) == 0)
  		possible_npeel_number++;
  		}
--- 1643,1650 
  		  else
  		possible_npeel_number = vf / nelements;
  
! 		  /* NPEEL_TMP is 0 when there is no misalignment, but also
! 		 allow peeling NELEMENTS.  */
  		  if (DR_MISALIGNMENT (dr) == 0)
  		possible_npeel_number++;
  		}
***
*** 1684,1693 
  		dr0 = dr;
  		}
  
  	  if (!first_store && DR_IS_WRITE (dr))
  		first_store = dr;
- 
- 	  one_misalignment_unknown = true;
  }
  }
else
--- 1690,1707 
  		dr0 = dr;
  		}
  
+ 	  one_misalignment_unknown = true;
+ 
+ 	  /* Check for data refs with unsupportable alignment that
+ 	 can be peeled.  */
+ 	  if (!supportable_dr_alignment)
+ 	  {
+ 		

Re: C/C++ OpenACC: acc_pcopyin, acc_pcreate

[Thomas Schwinge]

Hi Jakub!

On Tue, 23 May 2017 13:07:15 +0200, Jakub Jelinek  wrote:
> On Mon, May 22, 2017 at 04:26:48PM +0200, Thomas Schwinge wrote:
> > In , we currently describe acc_pcopyin, acc_pcreate as "old
> > names", but they're not "old" but really "alternative names", with the
> > intention to provide them at symbol level, not via "#define"s.

> > * libgomp.map (OACC_2.0): Add "acc_pcopyin", and "acc_pcreate".
> 
> > --- libgomp/libgomp.map
> > +++ libgomp/libgomp.map
> > @@ -335,6 +335,7 @@ OACC_2.0 {

> > acc_present_or_copyin;
> > +   acc_pcopyin;

> > acc_present_or_create;
> > +   acc_pcreate;

> This is just wrong, new symbols should never be added to an existing symbol
> version after a GCC version with that symbol version has been released.
> You can add it into OACC_2.0.1, or OACC_1.0, or whatever else, but certainly
> not into OACC_2.0.

I certainly have no problem using a new "OACC_2.0.1" symbol version
instead of "OACC_2.0", but would you please remind me where this
requirement is coming from?


> Another option is just to use something like glibc's sys/cdefs.h
> __REDIRECT_NTH macro (including the __USER_LABEL_PREFIX__ stuff)
> and just declare those functions as having the asm name of the corresponding
> alias.  The openacc.h header is for use with GCC only anyway, right?

But that will only redirect them at the user side.  The intention here is
to also care for users providing their own declarations instead of using
, or using "dlsym", and so on -- quite "pathological", I know,
but...

OK for trunk using "OACC_2.0.1" symbol version?

commit 30118ce81354e72e5f32f9ae0ee0f9ef4361747a
Author: Thomas Schwinge 
Date:   Wed May 24 12:49:04 2017 +0200

C/C++ OpenACC: acc_pcopyin, acc_pcreate

libgomp/
* openacc.h (acc_pcopyin, acc_pcreate): Provide prototypes instead
of preprocessor definitions.
* libgomp.h (strong_alias): Guard by "#ifdef
HAVE_ATTRIBUTE_ALIAS".
* oacc-mem.c: Provide "acc_pcreate" as alias for
"acc_present_or_create", and "acc_pcopyin" as alias for
"acc_present_or_copyin".
* libgomp.map: New version "OACC_2.0.1".
(OACC_2.0.1): Add "acc_pcopyin", and "acc_pcreate".
* testsuite/libgomp.oacc-c-c++-common/lib-38.c: Remove, merging
its content into...
* testsuite/libgomp.oacc-c-c++-common/lib-32.c: ... this file.
Extend testing.
---
 libgomp/libgomp.h  |   5 +-
 libgomp/libgomp.map|   6 +
 libgomp/oacc-mem.c |  22 ++
 libgomp/openacc.h  |   7 +-
 .../testsuite/libgomp.oacc-c-c++-common/lib-32.c   | 241 +++--
 .../testsuite/libgomp.oacc-c-c++-common/lib-38.c   |  64 --
 6 files changed, 258 insertions(+), 87 deletions(-)

diff --git libgomp/libgomp.h libgomp/libgomp.h
index 1769a48..940b5b8 100644
--- libgomp/libgomp.h
+++ libgomp/libgomp.h
@@ -1060,8 +1060,6 @@ extern void gomp_set_nest_lock_25 (omp_nest_lock_25_t *) 
__GOMP_NOTHROW;
 extern void gomp_unset_nest_lock_25 (omp_nest_lock_25_t *) __GOMP_NOTHROW;
 extern int gomp_test_nest_lock_25 (omp_nest_lock_25_t *) __GOMP_NOTHROW;
 
-# define strong_alias(fn, al) \
-  extern __typeof (fn) al __attribute__ ((alias (#fn)));
 # define omp_lock_symver(fn) \
   __asm (".symver g" #fn "_30, " #fn "@@OMP_3.0"); \
   __asm (".symver g" #fn "_25, " #fn "@OMP_1.0");
@@ -1085,6 +1083,9 @@ extern int gomp_test_nest_lock_25 (omp_nest_lock_25_t *) 
__GOMP_NOTHROW;
 #endif
 
 #ifdef HAVE_ATTRIBUTE_ALIAS
+# define strong_alias(fn, al) \
+  extern __typeof (fn) al __attribute__ ((alias (#fn)));
+
 # define ialias_ulpialias_str1(__USER_LABEL_PREFIX__)
 # define ialias_str1(x)ialias_str2(x)
 # define ialias_str2(x)#x
diff --git libgomp/libgomp.map libgomp/libgomp.map
index 4d42c42..b43c6de 100644
--- libgomp/libgomp.map
+++ libgomp/libgomp.map
@@ -378,6 +378,12 @@ OACC_2.0 {
acc_set_cuda_stream;
 };
 
+OACC_2.0.1 {
+  global:
+   acc_pcopyin;
+   acc_pcreate;
+} OACC_2.0;
+
 GOACC_2.0 {
   global:
GOACC_data_end;
diff --git libgomp/oacc-mem.c libgomp/oacc-mem.c
index 2df2202..ff3ed49 100644
--- libgomp/oacc-mem.c
+++ libgomp/oacc-mem.c
@@ -514,12 +514,34 @@ acc_present_or_create (void *h, size_t s)
   return present_create_copy (FLAG_PRESENT | FLAG_CREATE, h, s);
 }
 
+/* acc_pcreate is acc_present_or_create by a different name.  */
+#ifdef HAVE_ATTRIBUTE_ALIAS
+strong_alias (acc_present_or_create, acc_pcreate)
+#else
+void *
+acc_pcreate (void *h, size_t s)
+{
+  return acc_present_or_create (h, s);
+}
+#endif
+
 void *
 acc_present_or_copyin (void *h, size_t s)
 {
   return present_create_copy (FLAG_PRESENT | FLAG_CREATE | FLAG_COPY, h, s);
 }
 
+/* acc_pcopyin is acc_present_or_copyin by a different name.  */
+#ifdef 

Re: [Committed] S/390: Fix PR80725.

[Jakub Jelinek]

On Wed, May 24, 2017 at 01:38:01PM +0200, Andreas Krebbel wrote:
> No regressions on s390x. Applied to mainline.
> Ok for GCC 7 branch as well?

Ok, (though, you don't really need a permission for that, maintainers
can decide on backports to release branches themselves except when
the branches are frozen).

> 2017-05-24  Andreas Krebbel  
> 
>   PR target/80725
>   * config/s390/s390.c (s390_check_qrst_address): Check incoming
>   address against address_operand predicate.
>   * config/s390/s390.md ("*indirect_jump"): Swap alternatives.
> 
> gcc/testsuite/ChangeLog:
> 
> 2017-05-24  Andreas Krebbel  
> 
>   * gcc.target/s390/pr80725.c: New test.

Jakub

Re: [PATCH GCC][3/6]Fix PR80815 by handling negative DR_STEPs in runtime alias check

[Bin.Cheng]

On Tue, May 23, 2017 at 6:53 PM, Richard Sandiford
 wrote:
> AIUI, the reason the old code mishandled negative steps was that the
> associated segment lengths were stored as sizetype and so looked like
> big unsigned values.  Those values therefore satisfied tree_fits_uhwi_p
> even though they were semantically negative.  Is that right?
Yes, and the undesired wrapping behavior when such large unsigned hwi
is involved in computation.  But I think there are possible leaks in
the code even after this patch, as embedded below.
>
> Assuming yes, and quoting the change as a context diff...
>
>> diff --git a/gcc/tree-data-ref.c b/gcc/tree-data-ref.c
>> index a5f8c1c..f0799d9 100644
>> *** a/gcc/tree-data-ref.c
>> --- b/gcc/tree-data-ref.c
>> ***
>> *** 1259,1264 
>> --- 1259,1273 
>> != tree_int_cst_compare (DR_STEP (dr_a2->dr), size_zero_node))
>>   continue;
>>
>> +   bool neg_step
>> + = (tree_int_cst_compare (DR_STEP (dr_a1->dr), size_zero_node) < 0);
>> +
>> +   /* DR_A1 and DR_A2 must have the same step if it's negative.  */
>> +   if (neg_step
>> +   && tree_int_cst_compare (DR_STEP (dr_a1->dr),
>> +DR_STEP (dr_a2->dr)) != 0)
>> + continue;
>> +
>
> [Why do they need to be the same step?]
There are two reasons.  First is to simplify diff computation between
dr_a1 and dr_a2, otherwise we need to adjust diff for negative steps.
And wrapping behavior needs to be handled when adjusting diff with
steps.  The second reason is not fully handled in this patch.  We now
only set merged segment length to MAX only when both dr_a1->seg_len
and dr_a2->seg_len are constant, as below:
+  if (tree_fits_uhwi_p (dr_a1->seg_len)
+  && tree_fits_uhwi_p (dr_a2->seg_len))
+new_seg_len
+  = size_int (MAX (tree_to_uhwi (dr_a1->seg_len),
+   diff + tree_to_uhwi (dr_a2->seg_len)));
+  else
+new_seg_len
+  = size_binop (PLUS_EXPR, dr_a2->seg_len, size_int (diff));
In fact, we should do this for else branch too.  with different steps,
it is still possible that dr_a1-seg_len > dr_a2->seg_len + diff.  Here
I only restrict it to negative DR_STEP.  Patch updated with
explanation in comment.
>
>> /* Make sure dr_a1 starts left of dr_a2.  */
>> if (tree_int_cst_lt (DR_INIT (dr_a2->dr), DR_INIT (dr_a1->dr)))
>>   std::swap (*dr_a1, *dr_a2);
>> ***
>> *** 1266,1325 
>> bool do_remove = false;
>> unsigned HOST_WIDE_INT diff
>>   = (tree_to_shwi (DR_INIT (dr_a2->dr))
>> !- tree_to_shwi (DR_INIT (dr_a1->dr)));
>>
>> !   /* If the left segment does not extend beyond the start of the
>> !  right segment the new segment length is that of the right
>> !  plus the segment distance.  */
>> !   if (tree_fits_uhwi_p (dr_a1->seg_len)
>> !   && compare_tree_int (dr_a1->seg_len, diff) <= 0)
>>   {
>> !   dr_a1->seg_len = size_binop (PLUS_EXPR, dr_a2->seg_len,
>> !size_int (diff));
>> !   do_remove = true;
>>   }
>> !   /* Generally the new segment length is the maximum of the
>> !  left segment size and the right segment size plus the distance.
>> !  ???  We can also build tree MAX_EXPR here but it's not clear this
>> !  is profitable.  */
>> !   else if (tree_fits_uhwi_p (dr_a1->seg_len)
>> !&& tree_fits_uhwi_p (dr_a2->seg_len))
>> ! {
>> !   unsigned HOST_WIDE_INT seg_len_a1 = tree_to_uhwi 
>> (dr_a1->seg_len);
>> !   unsigned HOST_WIDE_INT seg_len_a2 = tree_to_uhwi 
>> (dr_a2->seg_len);
>> !   dr_a1->seg_len = size_int (MAX (seg_len_a1, diff + seg_len_a2));
>> !   do_remove = true;
>> ! }
>> !   /* Now we check if the following condition is satisfied:
>>
>> !  DIFF - SEGMENT_LENGTH_A < SEGMENT_LENGTH_B
>>
>> !  where DIFF = DR_A2_INIT - DR_A1_INIT.  However,
>> !  SEGMENT_LENGTH_A or SEGMENT_LENGTH_B may not be constant so we
>> !  have to make a best estimation.  We can get the minimum value
>> !  of SEGMENT_LENGTH_B as a constant, represented by MIN_SEG_LEN_B,
>> !  then either of the following two conditions can guarantee the
>> !  one above:
>>
>> !  1: DIFF <= MIN_SEG_LEN_B
>> !  2: DIFF - SEGMENT_LENGTH_A < MIN_SEG_LEN_B  */
>> !   else
>>   {
>> !   unsigned HOST_WIDE_INT min_seg_len_b
>> ! = (tree_fits_uhwi_p (dr_b1->seg_len)
>> !? tree_to_uhwi (dr_b1->seg_len)
>> !: factor);
>>
>> if (diff <= min_seg_len_b
>> || (tree_fits_uhwi_p (dr_a1->seg_len)
>> !   && diff - tree_to_uhwi (dr_a1->seg_len) < min_seg_len_b))
>>   {
>> !   

[PATCH] [ARC] Fix tst_movb pattern.

[Claudiu Zissulescu]

From: claziss 

The tst_movb pattern is missing guarding when spitting.

gcc/
2017-05-24  Claudiu Zissulescu  

* config/arc/arc.md (tst_movb): Add guard when splitting.

testsuite/
2017-05-24  Claudiu Zissulescu  

* gcc.target/arc/pr9001195952.c: New test.
---
 gcc/config/arc/arc.md   |  2 +-
 gcc/testsuite/gcc.target/arc/pr9001195952.c | 11 +++
 2 files changed, 12 insertions(+), 1 deletion(-)
 create mode 100755 gcc/testsuite/gcc.target/arc/pr9001195952.c

diff --git a/gcc/config/arc/arc.md b/gcc/config/arc/arc.md
index e78abaa..d5510ae 100644
--- a/gcc/config/arc/arc.md
+++ b/gcc/config/arc/arc.md
@@ -863,7 +863,7 @@ archs4xd, archs4xd_slow"
(clobber (match_scratch:SI 3 "=X,X,X,X,X,X,Rrq,Rrq,c"))]
   "TARGET_NPS_BITOPS"
   "movb.f.cl %3,%1,%p2,%p2,%s2"
-  "reload_completed
+  "TARGET_NPS_BITOPS && reload_completed
&& (extract_constrain_insn_cached (insn), (which_alternative & ~1) != 6)"
   [(set (match_dup 0) (match_dup 4))])
 
diff --git a/gcc/testsuite/gcc.target/arc/pr9001195952.c 
b/gcc/testsuite/gcc.target/arc/pr9001195952.c
new file mode 100755
index 000..252438d
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arc/pr9001195952.c
@@ -0,0 +1,11 @@
+/* { dg-do compile } */
+/* { dg-skip-if "" { ! { clmcpu } } } */
+/* { dg-options "-mcpu=archs -Os -w -fpic" } */
+
+/* tst_movb split pattern is wrong for anything else than NPS
+   chip.  */
+__bswap_32___bsx() {
+  int a = __builtin_bswap32(__bswap_32___bsx);
+  if (a & 1048575)
+zlog_warn();
+}
-- 
1.9.1

Re: [PATCH] gcc::context creation

[Jakub Jelinek]

On Thu, May 18, 2017 at 11:08:51AM -0400, Nathan Sidwell wrote:
> On 05/16/2017 11:26 AM, Nathan Sidwell wrote:
> > This patch breaks apart the creation of the pass manager from
> > gcc::context's ctor.  This will allow us to register additional dumps
> ... https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01295.html
> 
> This patch builds upon the context creation patch (this diff includes it),
> to implement a new LANG_HOOK_REGISTER_DUMPS language hook.  I call it
> between creating the dump manager and instantiating the optimization passes.
> 
> The patch then uses the hook to move the current -fdump-class-hierarchy
> option into the C++ FE entirely, removing TDI_class and associated handling
> from dumpfile and c-family/c-opts.c.  The option gets renamed to
> -fdump-lang-class in the process.
> 
> Obviously -fdump-translation-unit is the next candidate, and possibly
> -fdump-tree-original.

This breaks the dump numbering.
On some simple source file with some OpenMP pragmas in it, with C
and -fopenmp -fdump-tree-all I'm getting (so unless one knows the order
of passes, the indexes and file order no longer reveal the actual pass
sequence):
1.c.003t.omplower
1.c.003t.original
1.c.004t.gimple
1.c.004t.lower
1.c.007t.eh
1.c.008t.cfg
1.c.009t.ompexp
...
The right order is .original, .gimple, then (not included) .nested,
then .omplower, .lower, etc.
With C++ -fopenmp -fdump-tree-all I'm getting:
1.c.003t.original
1.c.004t.gimple
1.c.005t.omplower
1.c.006t.lower
1.c.008t.ehopt
1.c.009t.eh
...
which is slightly better, but there is no space for e.g. the .nested
dump.  With -fopenmp -fdump-tree-all -fdump-lang-all and C++ I'm getting
1.c.003t.original
1.c.004l.raw
1.c.004t.gimple
1.c.005t.omplower
1.c.006t.lower
1.c.008t.ehopt
1.c.009t.eh
...
so there is a number clash in between the raw and gimple dumps in addition
to the nested vs. omplower.

So, first question, where should we order the -fdump-lang-* dumps, shall
they go before .original/.gimple/.nested, or in between .original and
.gimple/.nested, or after those 3 (the last option looks just wrong to me)?
Shall the 3 standard dumps be registered like any others?
Shall the number of lang dumps affect the numbering, i.e. is it desirable
that with C and C++ you get different numbers for *t.cfg dump, or *t.gimple?
In many cases it would be better if the numbering was consistent between C
and C++.

Jakub

Re: [PATCH] gcc::context creation

[Nathan Sidwell]

On 05/24/2017 07:57 AM, Jakub Jelinek wrote:


The numbering is not to differentiate between dumps of the same name, that
is done through numbered suffixes of the dump names, but to make the order
of passes visible to the user and for sorted file listing to be provided in
that order.  So, rather than having lang files unnumbered, I think it is
better to number them and just have a maximum of lang dumps and if some FE
registers fewers, bump m_next_dump accordingly (create a hole).
That is pretty much the standard behavior, if some dump is registered, but
for whatever reason not dumped, you also get a hole.


oh, ok.  Seems fine to me.

nathan

--
Nathan Sidwell

Re: C/C++ OpenACC: acc_pcopyin, acc_pcreate

[Jakub Jelinek]

On Wed, May 24, 2017 at 12:55:27PM +0200, Thomas Schwinge wrote:
> Hi Jakub!
> 
> On Tue, 23 May 2017 13:07:15 +0200, Jakub Jelinek  wrote:
> > On Mon, May 22, 2017 at 04:26:48PM +0200, Thomas Schwinge wrote:
> > > In , we currently describe acc_pcopyin, acc_pcreate as "old
> > > names", but they're not "old" but really "alternative names", with the
> > > intention to provide them at symbol level, not via "#define"s.
> 
> > > * libgomp.map (OACC_2.0): Add "acc_pcopyin", and 
> > > "acc_pcreate".
> > 
> > > --- libgomp/libgomp.map
> > > +++ libgomp/libgomp.map
> > > @@ -335,6 +335,7 @@ OACC_2.0 {
> 
> > >   acc_present_or_copyin;
> > > + acc_pcopyin;
> 
> > >   acc_present_or_create;
> > > + acc_pcreate;
> 
> > This is just wrong, new symbols should never be added to an existing symbol
> > version after a GCC version with that symbol version has been released.
> > You can add it into OACC_2.0.1, or OACC_1.0, or whatever else, but certainly
> > not into OACC_2.0.
> 
> I certainly have no problem using a new "OACC_2.0.1" symbol version
> instead of "OACC_2.0", but would you please remind me where this
> requirement is coming from?

There are many reasons, one is e.g. that the dynamic linker uses the symbol
version names during library loading to verify the library satisfies the
needs of a binary or some other library; if you add further symbols into
existing symbol version, then it will be satisfied even by library that
doesn't provide the symbol (in the above case say acc_pcopyin), and you can
get a failure either much later (during relocation processing, with lazy
binding that can be much later), or not at all (with lazy binding and if
the function isn't called at all during the runtime of the program).
Another one is e.g. rpm uses symbol versions in dependencies, but only
those and not at the required/provided symbol granularity.  So, if you
have acc_pcopyin@@OACC_2.0.1 and use it in some program, the program
will have a dependency on libgomp.so.1()(OACC_2.0.1) and thus you
automatically get the right library that provides it.  If you add to an
existing symbol version, the dependency will be satisfied even for libraries
that don't provide it at all.
All in all, symbol versions aren't there just for documentation purposes,
but serve various other roles, including the possibility to change ABI
of existing symbols, but not limited to that.  The policy of not adding
new symbols into symbol versions that were already shipped in released
libraries is something that is strictly followed in glibc, gcc libraries
(I remember in libstdc++ a bug happened some years ago and some symbols
were unintentionally exported at an earlier version, which has been cured
by moving into a new symbol version and providing the old one just as an @
(vs. @@) symver for compatibility only; e.g. the current libstdc++ check-abi
stuff verifies this stuff).
For more info see e.g. https://www.akkadia.org/drepper/symbol-versioning

> But that will only redirect them at the user side.  The intention here is

The question is if the OpenACC standard allows that or not.

> to also care for users providing their own declarations instead of using
> , or using "dlsym", and so on -- quite "pathological", I know,
> but...
> 
> OK for trunk using "OACC_2.0.1" symbol version?

Ok.

> commit 30118ce81354e72e5f32f9ae0ee0f9ef4361747a
> Author: Thomas Schwinge 
> Date:   Wed May 24 12:49:04 2017 +0200
> 
> C/C++ OpenACC: acc_pcopyin, acc_pcreate
> 
> libgomp/
> * openacc.h (acc_pcopyin, acc_pcreate): Provide prototypes instead
> of preprocessor definitions.
> * libgomp.h (strong_alias): Guard by "#ifdef
> HAVE_ATTRIBUTE_ALIAS".
> * oacc-mem.c: Provide "acc_pcreate" as alias for
> "acc_present_or_create", and "acc_pcopyin" as alias for
> "acc_present_or_copyin".
> * libgomp.map: New version "OACC_2.0.1".
> (OACC_2.0.1): Add "acc_pcopyin", and "acc_pcreate".
> * testsuite/libgomp.oacc-c-c++-common/lib-38.c: Remove, merging
> its content into...
> * testsuite/libgomp.oacc-c-c++-common/lib-32.c: ... this file.
> Extend testing.

Jakub

Re: OpenACC 1.0 compatibility: acc_async_wait, acc_async_wait_all

[Thomas Schwinge]

Hi Jakub!

On Tue, 23 May 2017 13:17:26 +0200, Jakub Jelinek  wrote:
> On Mon, May 22, 2017 at 07:42:38PM +0200, Thomas Schwinge wrote:
> > For OpenACC 1.0 compatibility, we need to provide the aliases
> > acc_async_wait, and acc_async_wait_all for acc_wait, and acc_wait_all,
> > respectively.

> > OpenACC 1.0 compatibility: acc_async_wait, acc_async_wait_all

> All I've said about acc_pcopyin applies here too.

Obviously.  ;-)

> Except that OACC_1.0
> as symbol version might look like a good idea here.

GCC never implemented OpenACC 1.0 but directly started with 2.0a, so I
would find it confusing to now starting using 1.0 versions for these
symbols specifically.

OK for trunk using "OACC_2.0.1" symbol version?

commit 5c0da4609b29a406601c2dd92f8dbff2f448bc1d
Author: Thomas Schwinge 
Date:   Wed May 24 12:49:19 2017 +0200

OpenACC 1.0 compatibility: acc_async_wait, acc_async_wait_all

libgomp/
* openacc.h (acc_async_wait, acc_async_wait_all): New prototypes.
* libgomp.map (OACC_2.0.1): Add these.
* oacc-async.c (acc_async_wait, acc_async_wait_all): New aliases
for "acc_wait", and "acc_wait_all", respectively.
* openacc.f90 (acc_async_wait, acc_async_wait_all): New interfaces
for "acc_wait", and "acc_wait_all", respectively.
* openacc_lib.h (acc_async_wait, acc_async_wait_all): Likewise.
* libgomp.texi (acc_wait, acc_wait_all): Update.
* testsuite/libgomp.oacc-c-c++-common/par-reduction-2.c: Update.
* testsuite/libgomp.oacc-fortran/par-reduction-2-1.f: New file.
* testsuite/libgomp.oacc-fortran/par-reduction-2-2.f: Likewise.
---
 libgomp/libgomp.map|  2 +
 libgomp/libgomp.texi   |  7 ++-
 libgomp/oacc-async.c   | 22 +
 libgomp/openacc.f90| 16 +-
 libgomp/openacc.h  |  2 +
 libgomp/openacc_lib.h  | 11 +
 .../libgomp.oacc-c-c++-common/par-reduction-2.c|  9 ++--
 .../libgomp.oacc-fortran/par-reduction-2-1.f   | 57 ++
 .../libgomp.oacc-fortran/par-reduction-2-2.f   | 57 ++
 9 files changed, 176 insertions(+), 7 deletions(-)

diff --git libgomp/libgomp.map libgomp/libgomp.map
index b43c6de..f9044ae 100644
--- libgomp/libgomp.map
+++ libgomp/libgomp.map
@@ -380,6 +380,8 @@ OACC_2.0 {
 
 OACC_2.0.1 {
   global:
+   acc_async_wait;
+   acc_async_wait_all;
acc_pcopyin;
acc_pcreate;
 } OACC_2.0;
diff --git libgomp/libgomp.texi libgomp/libgomp.texi
index cc5ee1c..230720f 100644
--- libgomp/libgomp.texi
+++ libgomp/libgomp.texi
@@ -2095,12 +2095,15 @@ specified in @var{arg}.
 @item @emph{C/C++}:
 @multitable @columnfractions .20 .80
 @item @emph{Prototype}: @tab @code{acc_wait(arg);}
+@item @emph{Prototype (OpenACC 1.0 compatibility)}: @tab 
@code{acc_async_wait(arg);}
 @end multitable
 
 @item @emph{Fortran}:
 @multitable @columnfractions .20 .80
 @item @emph{Interface}: @tab @code{subroutine acc_wait(arg)}
 @item   @tab @code{integer(acc_handle_kind) arg}
+@item @emph{Interface (OpenACC 1.0 compatibility)}: @tab @code{subroutine 
acc_async_wait(arg)}
+@item   @tab 
@code{integer(acc_handle_kind) arg}
 @end multitable
 
 @item @emph{Reference}:
@@ -2119,11 +2122,13 @@ This function waits for the completion of all 
asynchronous operations.
 @item @emph{C/C++}:
 @multitable @columnfractions .20 .80
 @item @emph{Prototype}: @tab @code{acc_wait_all(void);}
+@item @emph{Prototype (OpenACC 1.0 compatibility)}: @tab 
@code{acc_async_wait_all(void);}
 @end multitable
 
 @item @emph{Fortran}:
 @multitable @columnfractions .20 .80
-@item @emph{Interface}: @tab @code{subroutine acc_wait_async()}
+@item @emph{Interface}: @tab @code{subroutine acc_wait_all()}
+@item @emph{Interface (OpenACC 1.0 compatibility)}: @tab @code{subroutine 
acc_async_wait_all()}
 @end multitable
 
 @item @emph{Reference}:
diff --git libgomp/oacc-async.c libgomp/oacc-async.c
index b68c84d..1334f99 100644
--- libgomp/oacc-async.c
+++ libgomp/oacc-async.c
@@ -70,6 +70,17 @@ acc_wait (int async)
   thr->dev->openacc.async_wait_func (async);
 }
 
+/* acc_async_wait is an OpenACC 1.0 compatibility name for acc_wait.  */
+#ifdef HAVE_ATTRIBUTE_ALIAS
+strong_alias (acc_wait, acc_async_wait)
+#else
+void
+acc_async_wait (int async)
+{
+  acc_wait (async);
+}
+#endif
+
 void
 acc_wait_async (int async1, int async2)
 {
@@ -92,6 +103,17 @@ acc_wait_all (void)
   thr->dev->openacc.async_wait_all_func ();
 }
 
+/* acc_async_wait_all is an OpenACC 1.0 compatibility name for acc_wait_all.  
*/
+#ifdef HAVE_ATTRIBUTE_ALIAS
+strong_alias (acc_wait_all, acc_async_wait_all)
+#else
+void
+acc_async_wait_all (void)
+{
+  acc_wait_all ();
+}
+#endif
+
 

[C++ PATCH] Hidden functions

[Nathan Sidwell]

We have functions that are invisible to (most) name lookups:
1) anticipated builtins -- these only become visible once declared, but 
we need to know they match a builtin.

2) friends injected into namespace scope from a class definition.

This patch teaches the overload object about them with a new 
OVL_HIDDEN_P marker (so we can just look at the overload node), and more 
importantly it keeps them at the start of the overload list.  That'll 
make removing them from lookup results much simpler (a future patch).


Because of the ordering constraint, revealing a node is no longer so 
simple.  We may have to delete and reinsert it.  Thus a check after 
duplicate_decls discovers we're (re-)declaring a previously hidden decl.


The new testcases are to do with such unhiding.  anticipated builtins 
are always "C" functions, we need to do the check about extern "C" 
declarations matching.


nathan
--
Nathan Sidwell
2017-05-24  Nathan Sidwell  

	gcc/cp/
	* cp-tree.h (OVL_HIDDEN_P): New.
	(ovl_iterator::hidden_p, ovl_iterator::reveal_node): New.
	(ovl_iterator::reveal_node): Declare.
	* tree.c (ovl_copy): Copy OVL_HIDDEN_P.
	(ovl_insert): Order on hiddenness.
	(ovl_iterator::reveal_node): New.
	* name-lookup.c (anticipated_builtin_p): New.
	(supplement_binding_1): Use it.
	(set_local_extern_decl_linkage): Use hidden_p.
	(do_pushdecl): Deal with unhiding a hidden decl, use
	anticipated_builtin_p.
	(do_nonmember_using_decl): Use anticipated_decl_p.
	(lookup_name_real_1): Use DECL_HIDDEN_P.

	gcc/testsuite/
	* g++.dg/lookup/extern-c-hidden.C: New.
	* g++.dg/lookup/extern-redecl1.C: New.

Index: cp/cp-tree.h
===
--- cp/cp-tree.h	(revision 248387)
+++ cp/cp-tree.h	(working copy)
@@ -378,6 +378,7 @@ extern GTY(()) tree cp_global_trees[CPTI
   REF_PARENTHESIZED_P (in COMPONENT_REF, INDIRECT_REF, SCOPE_REF)
   AGGR_INIT_ZERO_FIRST (in AGGR_INIT_EXPR)
   CONSTRUCTOR_MUTABLE_POISON (in CONSTRUCTOR)
+  OVL_HIDDEN_P (in OVERLOAD)
3: (TREE_REFERENCE_EXPR) (in NON_LVALUE_EXPR) (commented-out).
   ICS_BAD_FLAG (in _CONV)
   FN_TRY_BLOCK_P (in TRY_BLOCK)
@@ -659,6 +660,8 @@ typedef struct ptrmem_cst * ptrmem_cst_t
 
 /* If set, this was imported in a using declaration.   */
 #define OVL_USING_P(NODE)	TREE_LANG_FLAG_1 (OVERLOAD_CHECK (NODE))
+/* If set, this overload is a hidden decl.  */
+#define OVL_HIDDEN_P(NODE)	TREE_LANG_FLAG_2 (OVERLOAD_CHECK (NODE))
 /* If set, this overload contains a nested overload.  */
 #define OVL_NESTED_P(NODE)	TREE_LANG_FLAG_3 (OVERLOAD_CHECK (NODE))
 /* If set, this overload was constructed during lookup.  */
@@ -729,15 +732,26 @@ class ovl_iterator
   {
 return TREE_CODE (ovl) == OVERLOAD && OVL_USING_P (ovl);
   }
+  bool hidden_p () const
+  {
+return TREE_CODE (ovl) == OVERLOAD && OVL_HIDDEN_P (ovl);
+  }
+
+ public:
   tree remove_node (tree head)
   {
 return remove_node (head, ovl);
   }
+  tree reveal_node (tree head)
+  {
+return reveal_node (head, ovl);
+  }
 
  private:
-  /* We make this a static function to avoid the address of the
+  /* We make these static functions to avoid the address of the
  iterator escaping the local context.  */
   static tree remove_node (tree head, tree node);
+  static tree reveal_node (tree ovl, tree node);
 };
 
 /* Iterator over a (potentially) 2 dimensional overload, which is
Index: cp/name-lookup.c
===
--- cp/name-lookup.c	(revision 248387)
+++ cp/name-lookup.c	(working copy)
@@ -1077,6 +1077,26 @@ strip_using_decl (tree decl)
   return decl;
 }
 
+/* Return true if OVL is an overload for an anticipated builtin.  */
+
+static bool
+anticipated_builtin_p (tree ovl)
+{
+  if (TREE_CODE (ovl) != OVERLOAD)
+return false;
+
+  if (!OVL_HIDDEN_P (ovl))
+return false;
+
+  tree fn = OVL_FUNCTION (ovl);
+  gcc_checking_assert (DECL_ANTICIPATED (fn));
+
+  if (DECL_HIDDEN_FRIEND_P (fn))
+return false;
+
+  return true;
+}
+
 /* BINDING records an existing declaration for a name in the current scope.
But, DECL is another declaration for that same identifier in the
same scope.  This is the `struct stat' hack whereby a non-typedef
@@ -1131,9 +1151,7 @@ supplement_binding_1 (cxx_binding *bindi
 	   || target_bval == error_mark_node
 	   /* If TARGET_BVAL is anticipated but has not yet been
 	  declared, pretend it is not there at all.  */
-	   || (TREE_CODE (target_bval) == FUNCTION_DECL
-	   && DECL_ANTICIPATED (target_bval)
-	   && !DECL_HIDDEN_FRIEND_P (target_bval)))
+	   || anticipated_builtin_p (target_bval))
 binding->value = decl;
   else if (TREE_CODE (target_bval) == TYPE_DECL
 	   && DECL_ARTIFICIAL (target_bval)
@@ -1803,7 +1821,7 @@ set_local_extern_decl_linkage (tree decl
 	loc_value = NULL_TREE;
 
   for (ovl_iterator iter (loc_value); iter; ++iter)
-	if (!DECL_HIDDEN_P (*iter)
+	if (!iter.hidden_p ()
 	&& 

Re: Implementing OpenACC's Fortran module

[Thomas Schwinge]

Hi Jakub!

On Tue, 23 May 2017 13:12:00 +0200, Jakub Jelinek  wrote:
> On Mon, May 22, 2017 at 05:23:25PM +0200, Thomas Schwinge wrote:
> > --- libgomp/openacc_lib.h
> > +++ libgomp/openacc_lib.h
> > @@ -191,23 +191,9 @@
> >end interface
> >  
> >interface acc_pcopyin
> > -subroutine acc_pcopyin_32_h (a, len)
> > -  use iso_c_binding, only: c_int32_t
> > -  !GCC$ ATTRIBUTES NO_ARG_CHECK :: a
> > -  type (*), dimension (*) :: a
> > -  integer (c_int32_t) len
> > -end subroutine
> > -
> > -subroutine acc_pcopyin_64_h (a, len)
> > -  use iso_c_binding, only: c_int64_t
> > -  !GCC$ ATTRIBUTES NO_ARG_CHECK :: a
> > -  type (*), dimension (*) :: a
> > -  integer (c_int64_t) len
> > -end subroutine
> > -
> > -subroutine acc_pcopyin_array_h (a)
> > -  type (*), dimension (..), contiguous :: a
> > -  end subroutine
> > +procedure :: acc_present_or_copyin_32_h
> > +procedure :: acc_present_or_copyin_64_h
> > +procedure :: acc_present_or_copyin_array_h
> >end interface
> 
> My Fortran knowledge is limited

Same here.  ;-)

> does this actually provide
> the interfaces of those procedures (what arguments they have
> and other their properties)

This ("procedure" instead of "subroutine") is actually what "openacc.f90"
is using in the same context, and upon having inspected (already back in
April) the "-fdump-fortran-original" output for the new
"libgomp.oacc-fortran/lib-32-1.f" test case, this seemed to do the right
things.  And, comparing that to the "openacc.f90" case
("libgomp.oacc-fortran/lib-32-2.f" test case with "USE OPENACC"), the
only difference in "-fdump-fortran-original" output relevant to this
issue here are (expected) additional "USE-ASSOC(openacc)" attributes.

> or shall it instead use
> subroutine acc_present_or_copyin_32_h (a, len)
>   ...
> end subroutine
> etc. there?

Apparently not.  These "subroutine"s have already declared above (for
"acc_present_or_copyin" proper), and if declaring them again here, we
get:

Error: Symbol 'acc_present_or_copyin_32_h' at (1) already has an explicit 
interface
[...]


Thus OK for trunk, as posted?


Grüße
 Thomas

Re: [PATCH] gcc::context creation

[Nathan Sidwell]

On 05/24/2017 06:57 AM, Jakub Jelinek wrote:


So, first question, where should we order the -fdump-lang-* dumps, shall
they go before .original/.gimple/.nested, or in between .original and
.gimple/.nested, or after those 3 (the last option looks just wrong to me)?


I think the lang dumps should come first.


Shall the 3 standard dumps be registered like any others?


I think they should move to the new dynamic registration.
Should 'original' become a lang dump?


Shall the number of lang dumps affect the numbering, i.e. is it desirable
that with C and C++ you get different numbers for *t.cfg dump, or *t.gimple?
In many cases it would be better if the numbering was consistent between C
and C++.


I'm ambivalent on this.  I can see why consistency might be desirable 
though.  I'd be fine with making the lang dumps unnumbered to achieve 
that -- I don't see an obvious need for a language to have two dumps of 
the same name.


nathan

--
Nathan Sidwell

[PATCH v2 05/N] Add -fdump*-folding suboption.

[Martin Liška]

Hello.

After discussions with Richi, I decided to end up with the transformation and 
thus
I would like to apply the original patch on top of what was done. Probably last 
change
should be that we should renumber TDF_* values to start from 1 << 0 and holes 
in numbering
should be eliminated?

Thanks,
Martin
>From d0cab884035be37e5ceab54384611830661fdd9f Mon Sep 17 00:00:00 2001
From: marxin 
Date: Wed, 24 May 2017 10:32:42 +0200
Subject: [PATCH] Add -fdump*-folding suboption.

gcc/ChangeLog:

2017-05-24  Martin Liska  

	* dumpfile.c: Add TDF_FOLDING.
	* dumpfile.h (enum dump_kind): Likewise.
	* genmatch.c (dt_simplify::gen_1): Use it.
---
 gcc/dumpfile.c | 1 +
 gcc/dumpfile.h | 1 +
 gcc/genmatch.c | 2 +-
 3 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/gcc/dumpfile.c b/gcc/dumpfile.c
index 13a711345b4..903d879e784 100644
--- a/gcc/dumpfile.c
+++ b/gcc/dumpfile.c
@@ -118,6 +118,7 @@ static const struct dump_option_value_info dump_options[] =
   {"enumerate_locals", TDF_ENUMERATE_LOCALS},
   {"scev", TDF_SCEV},
   {"gimple", TDF_GIMPLE},
+  {"folding", TDF_FOLDING},
   {"optimized", MSG_OPTIMIZED_LOCATIONS},
   {"missed", MSG_MISSED_OPTIMIZATION},
   {"note", MSG_NOTE},
diff --git a/gcc/dumpfile.h b/gcc/dumpfile.h
index a1e4720156d..abb4d93a93b 100644
--- a/gcc/dumpfile.h
+++ b/gcc/dumpfile.h
@@ -92,6 +92,7 @@ enum dump_kind
 #define TDF_SCEV	(1 << 24)	/* Dump SCEV details.  */
 #define TDF_COMMENT	(1 << 25)	/* Dump lines with prefix ";;"  */
 #define TDF_GIMPLE	(1 << 26)	/* Dump in GIMPLE FE syntax  */
+#define TDF_FOLDING	(1 << 27)	/* Dump folding details.  */
 #define MSG_OPTIMIZED_LOCATIONS	 (1 << 27)  /* -fopt-info optimized sources */
 #define MSG_MISSED_OPTIMIZATION	 (1 << 28)  /* missed opportunities */
 #define MSG_NOTE		 (1 << 29)  /* general optimization info */
diff --git a/gcc/genmatch.c b/gcc/genmatch.c
index 2c3183b25af..f20e39f9158 100644
--- a/gcc/genmatch.c
+++ b/gcc/genmatch.c
@@ -3191,7 +3191,7 @@ dt_simplify::gen_1 (FILE *f, int indent, bool gimple, operand *result)
 	}
 }
 
-  fprintf_indent (f, indent, "if (dump_file && (dump_flags & TDF_DETAILS)) "
+  fprintf_indent (f, indent, "if (dump_file && (dump_flags & TDF_FOLDING)) "
 	   "fprintf (dump_file, \"Applying pattern ");
   output_line_directive (f,
 			 result ? result->location : s->match->location, true);
-- 
2.12.2

Re: [PATCH] gcc::context creation

[Jakub Jelinek]

On Wed, May 24, 2017 at 12:57:28PM +0200, Jakub Jelinek wrote:
> So, first question, where should we order the -fdump-lang-* dumps, shall
> they go before .original/.gimple/.nested, or in between .original and
> .gimple/.nested, or after those 3 (the last option looks just wrong to me)?
> Shall the 3 standard dumps be registered like any others?
> Shall the number of lang dumps affect the numbering, i.e. is it desirable
> that with C and C++ you get different numbers for *t.cfg dump, or *t.gimple?
> In many cases it would be better if the numbering was consistent between C
> and C++.

If we wanted to order the dumps .original, .gimple, .nested, then 0-n *l.*
dumps, then the rest, then something like the following would work.
But I don't think we want to order .gimple before the *l.* dumps, and I'd
appreciate stable dump offsets between languages, so one can
./cc1 -fdump-tree-all 1.c
./cc1plus -fdump-tree-all 2.c
and diff -up {1,2}.c.074t.whatever instead of figuring out what different
numbers they have.

2017-05-24  Jakub Jelinek  

* dumpfile.c (dump_files): Use num 1, 2, 3 instead of 3, 4, 5
for .original, .gimple and .nested.
(FIRST_AUTO_NUMBERED_DUMP): Increase to 4.

--- gcc/dumpfile.c.jj   2017-05-22 20:49:02.0 +0200
+++ gcc/dumpfile.c  2017-05-24 12:30:17.205182094 +0200
@@ -73,10 +73,10 @@ static struct dump_file_info dump_files[
   dump_file_info (".cgraph", "ipa-cgraph", DK_ipa, 0),
   dump_file_info (".type-inheritance", "ipa-type-inheritance", DK_ipa, 0),
   dump_file_info (".ipa-clones", "ipa-clones", DK_ipa, 0),
-  dump_file_info (".original", "tree-original", DK_tree, 3),
-  dump_file_info (".gimple", "tree-gimple", DK_tree, 4),
-  dump_file_info (".nested", "tree-nested", DK_tree, 5),
-#define FIRST_AUTO_NUMBERED_DUMP 3
+  dump_file_info (".original", "tree-original", DK_tree, 1),
+  dump_file_info (".gimple", "tree-gimple", DK_tree, 2),
+  dump_file_info (".nested", "tree-nested", DK_tree, 3),
+#define FIRST_AUTO_NUMBERED_DUMP 4
 
   dump_file_info (NULL, "lang-all", DK_lang, 0),
   dump_file_info (NULL, "tree-all", DK_tree, 0),


Jakub

[Committed] S/390: Fix PR80725.

[Andreas Krebbel]

No regressions on s390x. Applied to mainline.
Ok for GCC 7 branch as well?

Bye,

-Andreas-

gcc/ChangeLog:

2017-05-24  Andreas Krebbel  

PR target/80725
* config/s390/s390.c (s390_check_qrst_address): Check incoming
address against address_operand predicate.
* config/s390/s390.md ("*indirect_jump"): Swap alternatives.

gcc/testsuite/ChangeLog:

2017-05-24  Andreas Krebbel  

* gcc.target/s390/pr80725.c: New test.
---
 gcc/config/s390/s390.c  |  3 +++
 gcc/config/s390/s390.md | 10 ++
 gcc/testsuite/gcc.target/s390/pr80725.c | 26 ++
 3 files changed, 35 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/s390/pr80725.c

diff --git a/gcc/config/s390/s390.c b/gcc/config/s390/s390.c
index c16391a..7be22d9 100644
--- a/gcc/config/s390/s390.c
+++ b/gcc/config/s390/s390.c
@@ -3102,6 +3102,9 @@ s390_check_qrst_address (char c, rtx op, bool lit_pool_ok)
   struct s390_address addr;
   bool decomposed = false;
 
+  if (!address_operand (op, GET_MODE (op)))
+return 0;
+
   /* This check makes sure that no symbolic address (except literal
  pool references) are accepted by the R or T constraints.  */
   if (s390_loadrelative_operand_p (op, NULL, NULL))
diff --git a/gcc/config/s390/s390.md b/gcc/config/s390/s390.md
index c9fd19a..cfae171 100644
--- a/gcc/config/s390/s390.md
+++ b/gcc/config/s390/s390.md
@@ -9660,14 +9660,16 @@
 operands[0] = force_reg (Pmode, operands[0]);
 })
 
+; The first constraint must be an "extra address constraint" in order
+; to trigger address reloading in LRA/reload
 (define_insn "*indirect_jump"
   [(set (pc)
-   (match_operand 0 "address_operand" "a,ZR"))]
+   (match_operand 0 "address_operand" "ZR,a"))]
  ""
  "@
-  br\t%0
-  b\t%a0"
- [(set_attr "op_type" "RR,RX")
+  b\t%a0
+  br\t%0"
+ [(set_attr "op_type" "RX,RR")
   (set_attr "type"  "branch")
   (set_attr "atype" "agen")
   (set_attr "cpu_facility" "*")])
diff --git a/gcc/testsuite/gcc.target/s390/pr80725.c 
b/gcc/testsuite/gcc.target/s390/pr80725.c
new file mode 100644
index 000..4a402c4
--- /dev/null
+++ b/gcc/testsuite/gcc.target/s390/pr80725.c
@@ -0,0 +1,26 @@
+/* Regression test for PR/80725.  */
+
+/* { dg-do compile } */
+/* { dg-options "-O2 -march=zEC12" } */
+
+int a, e;
+const char b;
+char c;
+const int d;
+void bar (short);
+
+void
+foo (int x, int y)
+{
+  long f = d;
+  short g = 0;
+  while (e)
+while (a < x)
+  {
+   if (y)
+ goto *d;
+   g = b | b + g;
+   bar (g);
+   c = (char) (long) foo;
+  }
+}
-- 
2.9.1

Re: [PATCH] Fix PR middle-end/80823, ICE: verify_flow_info failed

[Peter Bergner]

On 5/24/17 2:15 AM, Richard Biener wrote:
> On May 23, 2017 7:46:59 PM GMT+02:00, Peter Bergner  
> wrote:
>> gcc/
>>  PR middle-end/80823
>>  * tree-cfg.c (group_case_labels_stmt): Delete increment of "i";
>>
>> gcc/testsuite/
>>  PR middle-end/80823
>>  * gcc.dg/pr80823.c: New test.
> 
> OK.
> 

Thanks, committed as revision 248408.

Peter

Re: [PATCH GCC][3/6]Fix PR80815 by handling negative DR_STEPs in runtime alias check

[Richard Sandiford]

"Bin.Cheng"  writes:
> On Tue, May 23, 2017 at 6:53 PM, Richard Sandiford
>  wrote:
>> AIUI, the reason the old code mishandled negative steps was that the
>> associated segment lengths were stored as sizetype and so looked like
>> big unsigned values.  Those values therefore satisfied tree_fits_uhwi_p
>> even though they were semantically negative.  Is that right?
> Yes, and the undesired wrapping behavior when such large unsigned hwi
> is involved in computation.  But I think there are possible leaks in
> the code even after this patch, as embedded below.
>>
>> Assuming yes, and quoting the change as a context diff...
>>
>>> diff --git a/gcc/tree-data-ref.c b/gcc/tree-data-ref.c
>>> index a5f8c1c..f0799d9 100644
>>> *** a/gcc/tree-data-ref.c
>>> --- b/gcc/tree-data-ref.c
>>> ***
>>> *** 1259,1264 
>>> --- 1259,1273 
>>> != tree_int_cst_compare (DR_STEP (dr_a2->dr), size_zero_node))
>>>   continue;
>>>
>>> +   bool neg_step
>>> + = (tree_int_cst_compare (DR_STEP (dr_a1->dr), size_zero_node) < 
>>> 0);
>>> +
>>> +   /* DR_A1 and DR_A2 must have the same step if it's negative.  */
>>> +   if (neg_step
>>> +   && tree_int_cst_compare (DR_STEP (dr_a1->dr),
>>> +DR_STEP (dr_a2->dr)) != 0)
>>> + continue;
>>> +
>>
>> [Why do they need to be the same step?]
> There are two reasons.  First is to simplify diff computation between
> dr_a1 and dr_a2, otherwise we need to adjust diff for negative steps.

What kind of adjustment would be needed?  Could you give an example?

> And wrapping behavior needs to be handled when adjusting diff with
> steps.  The second reason is not fully handled in this patch.  We now
> only set merged segment length to MAX only when both dr_a1->seg_len
> and dr_a2->seg_len are constant, as below:
> +  if (tree_fits_uhwi_p (dr_a1->seg_len)
> +  && tree_fits_uhwi_p (dr_a2->seg_len))
> +new_seg_len
> +  = size_int (MAX (tree_to_uhwi (dr_a1->seg_len),
> +   diff + tree_to_uhwi (dr_a2->seg_len)));
> +  else
> +new_seg_len
> +  = size_binop (PLUS_EXPR, dr_a2->seg_len, size_int (diff));
> In fact, we should do this for else branch too.  with different steps,
> it is still possible that dr_a1-seg_len > dr_a2->seg_len + diff.  Here
> I only restrict it to negative DR_STEP.  Patch updated with
> explanation in comment.
>>
>>> /* Make sure dr_a1 starts left of dr_a2.  */
>>> if (tree_int_cst_lt (DR_INIT (dr_a2->dr), DR_INIT (dr_a1->dr)))
>>>   std::swap (*dr_a1, *dr_a2);
>>> ***
>>> *** 1266,1325 
>>> bool do_remove = false;
>>> unsigned HOST_WIDE_INT diff
>>>   = (tree_to_shwi (DR_INIT (dr_a2->dr))
>>> !- tree_to_shwi (DR_INIT (dr_a1->dr)));
>>>
>>> !   /* If the left segment does not extend beyond the start of the
>>> !  right segment the new segment length is that of the right
>>> !  plus the segment distance.  */
>>> !   if (tree_fits_uhwi_p (dr_a1->seg_len)
>>> !   && compare_tree_int (dr_a1->seg_len, diff) <= 0)
>>>   {
>>> !   dr_a1->seg_len = size_binop (PLUS_EXPR, dr_a2->seg_len,
>>> !size_int (diff));
>>> !   do_remove = true;
>>>   }
>>> !   /* Generally the new segment length is the maximum of the
>>> !  left segment size and the right segment size plus the distance.
>>> !  ???  We can also build tree MAX_EXPR here but it's not clear this
>>> !  is profitable.  */
>>> !   else if (tree_fits_uhwi_p (dr_a1->seg_len)
>>> !&& tree_fits_uhwi_p (dr_a2->seg_len))
>>> ! {
>>> !   unsigned HOST_WIDE_INT seg_len_a1 = tree_to_uhwi 
>>> (dr_a1->seg_len);
>>> !   unsigned HOST_WIDE_INT seg_len_a2 = tree_to_uhwi 
>>> (dr_a2->seg_len);
>>> !   dr_a1->seg_len = size_int (MAX (seg_len_a1, diff + seg_len_a2));
>>> !   do_remove = true;
>>> ! }
>>> !   /* Now we check if the following condition is satisfied:
>>>
>>> !  DIFF - SEGMENT_LENGTH_A < SEGMENT_LENGTH_B
>>>
>>> !  where DIFF = DR_A2_INIT - DR_A1_INIT.  However,
>>> !  SEGMENT_LENGTH_A or SEGMENT_LENGTH_B may not be constant so we
>>> !  have to make a best estimation.  We can get the minimum value
>>> !  of SEGMENT_LENGTH_B as a constant, represented by MIN_SEG_LEN_B,
>>> !  then either of the following two conditions can guarantee the
>>> !  one above:
>>>
>>> !  1: DIFF <= MIN_SEG_LEN_B
>>> !  2: DIFF - SEGMENT_LENGTH_A < MIN_SEG_LEN_B  */
>>> !   else
>>>   {
>>> !   unsigned HOST_WIDE_INT min_seg_len_b
>>> ! = (tree_fits_uhwi_p (dr_b1->seg_len)
>>> !? tree_to_uhwi (dr_b1->seg_len)
>>> !   

Re: [PATCH] Try harder to fix recently introduced crashes in ggc_collect

[Trevor Saunders]

On Fri, May 19, 2017 at 10:10:23AM -0400, Nathan Sidwell wrote:
> On 05/19/2017 10:05 AM, Bernd Edlinger wrote:
> 
> > hwi cannot be the root cause of the problem,
> > because it can only be long_integer_type_node
> > or long_long_integer_type_node, otherwise
> > an error would be triggered.
> 
> that's the error I made with the static fns.  PCH moves things around, so
> anything that can be streamed via PCH must be GTY marked.  Also, I'm not
> sure if the current GC is a compacting GC (given PCH can compact things?)

other than pch which I'm not sure about I'm pretty sure its not, and is
just basic mark and sweep.

That said if modules can get merged for gcc 8 I'm very tempted to rm pch
now.

Trev

> 
> nathan
> -- 
> Nathan Sidwell

Re: [PATCH] gcc::context creation

[Jakub Jelinek]

On Wed, May 24, 2017 at 07:44:49AM -0400, Nathan Sidwell wrote:
> On 05/24/2017 06:57 AM, Jakub Jelinek wrote:
> 
> > So, first question, where should we order the -fdump-lang-* dumps, shall
> > they go before .original/.gimple/.nested, or in between .original and
> > .gimple/.nested, or after those 3 (the last option looks just wrong to me)?
> 
> I think the lang dumps should come first.
> 
> > Shall the 3 standard dumps be registered like any others?
> 
> I think they should move to the new dynamic registration.
> Should 'original' become a lang dump?

It would be great if the original dumping was able to use some FE specific
printing, right now the *.original dump is often full of
< > Shall the number of lang dumps affect the numbering, i.e. is it desirable
> > that with C and C++ you get different numbers for *t.cfg dump, or *t.gimple?
> > In many cases it would be better if the numbering was consistent between C
> > and C++.
> 
> I'm ambivalent on this.  I can see why consistency might be desirable
> though.  I'd be fine with making the lang dumps unnumbered to achieve that
> -- I don't see an obvious need for a language to have two dumps of the same
> name.

The numbering is not to differentiate between dumps of the same name, that
is done through numbered suffixes of the dump names, but to make the order
of passes visible to the user and for sorted file listing to be provided in
that order.  So, rather than having lang files unnumbered, I think it is
better to number them and just have a maximum of lang dumps and if some FE
registers fewers, bump m_next_dump accordingly (create a hole).
That is pretty much the standard behavior, if some dump is registered, but
for whatever reason not dumped, you also get a hole.

Jakub

Re: OpenACC 1.0 compatibility: acc_async_wait, acc_async_wait_all

[Jakub Jelinek]

On Wed, May 24, 2017 at 01:47:34PM +0200, Thomas Schwinge wrote:
> Hi Jakub!
> 
> On Tue, 23 May 2017 13:17:26 +0200, Jakub Jelinek  wrote:
> > On Mon, May 22, 2017 at 07:42:38PM +0200, Thomas Schwinge wrote:
> > > For OpenACC 1.0 compatibility, we need to provide the aliases
> > > acc_async_wait, and acc_async_wait_all for acc_wait, and acc_wait_all,
> > > respectively.
> 
> > > OpenACC 1.0 compatibility: acc_async_wait, acc_async_wait_all
> 
> > All I've said about acc_pcopyin applies here too.
> 
> Obviously.  ;-)
> 
> > Except that OACC_1.0
> > as symbol version might look like a good idea here.
> 
> GCC never implemented OpenACC 1.0 but directly started with 2.0a, so I
> would find it confusing to now starting using 1.0 versions for these
> symbols specifically.
> 
> OK for trunk using "OACC_2.0.1" symbol version?

Ok.

Jakub

Re: Implementing OpenACC's Fortran module

[Jakub Jelinek]

On Wed, May 24, 2017 at 01:34:50PM +0200, Thomas Schwinge wrote:
> Thus OK for trunk, as posted?

Ok.

Jakub

Re: [PATCH] Match x86 family machine constraints section with constarints.md

[Uros Bizjak]

On Tue, May 23, 2017 at 5:33 PM, Sandra Loosemore
 wrote:
> On 04/28/2017 03:30 AM, Peryt, Sebastian wrote:
>>
>> Hi,
>>
>> Thank you for your comments. I edited my patch accordingly. As for some of
>> your doubts:
>> - REX is  the opcode prefix to access 64-bit register extensions
>> introduced in IA-32e mode.
>> - EVEX is the encoding prefix which applies to SIMD operating instructions
>> operating on XMM, YMM and ZMM registers. It was introduced with AVX-512
>> instructions.
>> - "number factor of four" that means that sources start in a multiple of 4
>> boundary. This is used for some of instructions.
>>
>> Also I'd like to add that this whole patch is strictly based on docstring
>> parts of constraints that are present in config/i386/constraints.md but not
>> in documentation (md.texi file). There is no new (new as in nonexistent in
>> code) content.
>>
>> I'm also adding Kirill Yukhin to CC, because I believe he is the correct
>> person that can catch any technical errors if any has slipped-in.
>
>
> The grammar/markup/etc are OK now, but I can't comment on technical
> correctness of the information.

LGTM.

Thanks,
Uros.

Re: Implementing OpenACC's Fortran module

[Thomas Schwinge]

Hi!

On Wed, 24 May 2017 13:58:32 +0200, Jakub Jelinek  wrote:
> On Wed, May 24, 2017 at 01:34:50PM +0200, Thomas Schwinge wrote:
> > Thus OK for trunk, as posted?
> 
> Ok.

Thanks.  Committed to trunk in r248412:

commit b70df2112de1c8fb9b448dc24e3a58055e4bbbdc
Author: tschwinge 
Date:   Wed May 24 13:23:55 2017 +

Fortran OpenACC "openacc_lib.h": acc_pcopyin, acc_pcreate

libgomp/
* openacc_lib.h (acc_pcopyin, acc_pcreate): Route to
acc_present_or_copyin and acc_present_or_create procedures,
respectively.
* testsuite/libgomp.oacc-fortran/lib-32-1.f: Exercise these, and
generally different variants of OpenACC Runtime Library functions.
* testsuite/libgomp.oacc-fortran/lib-32-2.f: Likewise.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@248412 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 libgomp/ChangeLog |  7 
 libgomp/openacc_lib.h | 42 ---
 libgomp/testsuite/libgomp.oacc-fortran/lib-32-1.f | 36 ---
 libgomp/testsuite/libgomp.oacc-fortran/lib-32-2.f | 26 +++---
 4 files changed, 42 insertions(+), 69 deletions(-)

diff --git libgomp/ChangeLog libgomp/ChangeLog
index af8c5ca..55869d2 100644
--- libgomp/ChangeLog
+++ libgomp/ChangeLog
@@ -1,5 +1,12 @@
 2017-05-24  Thomas Schwinge  
 
+   * openacc_lib.h (acc_pcopyin, acc_pcreate): Route to
+   acc_present_or_copyin and acc_present_or_create procedures,
+   respectively.
+   * testsuite/libgomp.oacc-fortran/lib-32-1.f: Exercise these, and
+   generally different variants of OpenACC Runtime Library functions.
+   * testsuite/libgomp.oacc-fortran/lib-32-2.f: Likewise.
+
* testsuite/libgomp.oacc-fortran/lib-32-1.f: New file.
* testsuite/libgomp.oacc-fortran/lib-32-2.f: Likewise.
 
diff --git libgomp/openacc_lib.h libgomp/openacc_lib.h
index 65f47a8..7818bd7 100644
--- libgomp/openacc_lib.h
+++ libgomp/openacc_lib.h
@@ -191,23 +191,9 @@
   end interface
 
   interface acc_pcopyin
-subroutine acc_pcopyin_32_h (a, len)
-  use iso_c_binding, only: c_int32_t
-  !GCC$ ATTRIBUTES NO_ARG_CHECK :: a
-  type (*), dimension (*) :: a
-  integer (c_int32_t) len
-end subroutine
-
-subroutine acc_pcopyin_64_h (a, len)
-  use iso_c_binding, only: c_int64_t
-  !GCC$ ATTRIBUTES NO_ARG_CHECK :: a
-  type (*), dimension (*) :: a
-  integer (c_int64_t) len
-end subroutine
-
-subroutine acc_pcopyin_array_h (a)
-  type (*), dimension (..), contiguous :: a
-  end subroutine
+procedure :: acc_present_or_copyin_32_h
+procedure :: acc_present_or_copyin_64_h
+procedure :: acc_present_or_copyin_array_h
   end interface
 
   interface acc_create
@@ -251,23 +237,9 @@
   end interface
 
   interface acc_pcreate
-subroutine acc_pcreate_32_h (a, len)
-  use iso_c_binding, only: c_int32_t
-  !GCC$ ATTRIBUTES NO_ARG_CHECK :: a
-  type (*), dimension (*) :: a
-  integer (c_int32_t) len
-end subroutine
-
-subroutine acc_pcreate_64_h (a, len)
-  use iso_c_binding, only: c_int64_t
-  !GCC$ ATTRIBUTES NO_ARG_CHECK :: a
-  type (*), dimension (*) :: a
-  integer (c_int64_t) len
-end subroutine
-
-subroutine acc_pcreate_array_h (a)
-  type (*), dimension (..), contiguous :: a
-  end subroutine
+procedure :: acc_present_or_create_32_h
+procedure :: acc_present_or_create_64_h
+procedure :: acc_present_or_create_array_h
   end interface
 
   interface acc_copyout
@@ -353,7 +325,7 @@
   ! acc_map_data: Only available in C/C++
   ! acc_unmap_data: Only available in C/C++
   ! acc_deviceptr: Only available in C/C++
-  ! acc_ostptr: Only available in C/C++
+  ! acc_hostptr: Only available in C/C++
 
   interface acc_is_present
 function acc_is_present_32_h (a, len)
diff --git libgomp/testsuite/libgomp.oacc-fortran/lib-32-1.f 
libgomp/testsuite/libgomp.oacc-fortran/lib-32-1.f
index 4606d77..177e4fb 100644
--- libgomp/testsuite/libgomp.oacc-fortran/lib-32-1.f
+++ libgomp/testsuite/libgomp.oacc-fortran/lib-32-1.f
@@ -20,8 +20,8 @@
 
   SHARED_MEM = ACC_IS_PRESENT (H)
 
-  CALL ACC_PRESENT_OR_CREATE (H)
-  IF (.NOT. ACC_IS_PRESENT (H)) CALL ABORT
+  CALL ACC_PRESENT_OR_CREATE (H, INT (SIZEOF (H), 4))
+  IF (.NOT. ACC_IS_PRESENT (H, INT (SIZEOF (H), 8))) CALL ABORT
 
 !$ACC PARALLEL LOOP DEFAULT (PRESENT)
   DO I = 1, N
@@ -48,8 +48,7 @@
  H(I) = I + 4
   END DO
 
-!  CALL ACC_PCREATE (H)
-  CALL ACC_PRESENT_OR_CREATE (H)
+  CALL ACC_PCREATE (H, INT (SIZEOF (H), 4))
 
 !$ACC PARALLEL 

Re: [PATCH] Dump function on internal errors

[Richard Biener]

On Mon, May 22, 2017 at 4:19 PM, Andi Kleen  wrote:
> From: Andi Kleen 
>
> When a verification check fails it is useful to dump the current
> function to the dump file, so it's easier to figure out what
> actually went wrong.
>
> v2: Updated version now using a hook in internal_error, and
> also prints the pass name and the dump file name.
>
> gcc/:
>
> 2017-05-21  Andi Kleen  
>
> * diagnostic.c (internal_error): Call hook.
> (set_internal_error_hook): New function.
> * diagnostic.h: Add set_internal_error_hook.
> * passes.c: (pass_ice_hook): Add class to set
> internal_error_hook to dump functions.
> ---
>  gcc/diagnostic.c | 18 ++
>  gcc/diagnostic.h |  1 +
>  gcc/passes.c | 21 +
>  3 files changed, 40 insertions(+)
>
> diff --git a/gcc/diagnostic.c b/gcc/diagnostic.c
> index 158519606f8..8d9caade60b 100644
> --- a/gcc/diagnostic.c
> +++ b/gcc/diagnostic.c
> @@ -33,6 +33,9 @@ along with GCC; see the file COPYING3.  If not see
>  #include "diagnostic-color.h"
>  #include "edit-context.h"
>  #include "selftest.h"
> +#include "tree.h"
> +#include "tree-pass.h"
> +#include "tree-cfg.h"
>
>  #ifdef HAVE_TERMIOS_H
>  # include 
> @@ -1396,6 +1399,10 @@ fatal_error (location_t loc, const char *gmsgid, ...)
>gcc_unreachable ();
>  }
>
> +/* Hook to call on internal errors.  */
> +
> +static void (*internal_error_hook)();
> +
>  /* An internal consistency check has failed.  We make no attempt to
> continue.  Note that unless there is debugging value to be had from
> a more specific message, or some other good reason, you should use
> @@ -1403,6 +1410,9 @@ fatal_error (location_t loc, const char *gmsgid, ...)
>  void
>  internal_error (const char *gmsgid, ...)
>  {
> +  if (internal_error_hook)
> +internal_error_hook ();
> +
>va_list ap;
>va_start (ap, gmsgid);
>rich_location richloc (line_table, input_location);
> @@ -1412,6 +1422,14 @@ internal_error (const char *gmsgid, ...)
>gcc_unreachable ();
>  }
>
> +/* Call HOOK on internal errors.  */
> +
> +void
> +set_internal_error_hook (void (*hook)())
> +{
> +  internal_error_hook = hook;
> +}
> +
>  /* Like internal_error, but no backtrace will be printed.  Used when
> the internal error does not happen at the current location, but happened
> somewhere else.  */
> diff --git a/gcc/diagnostic.h b/gcc/diagnostic.h
> index dbd1703e0ef..3d26a84ab44 100644
> --- a/gcc/diagnostic.h
> +++ b/gcc/diagnostic.h
> @@ -369,5 +369,6 @@ extern char *file_name_as_prefix (diagnostic_context *, 
> const char *);
>
>  extern char *build_message_string (const char *, ...) ATTRIBUTE_PRINTF_1;
>
> +extern void set_internal_error_hook (void (*)());
>
>  #endif /* ! GCC_DIAGNOSTIC_H */
> diff --git a/gcc/passes.c b/gcc/passes.c
> index e7c5d194010..1bd92c8140a 100644
> --- a/gcc/passes.c
> +++ b/gcc/passes.c
> @@ -3040,4 +3040,25 @@ function_called_by_processed_nodes_p (void)
>return e != NULL;
>  }
>
> +class pass_ice_hook {
> +
> +  /* Print function to dump file on internal errors.  */
> +
> +  static void ice_hook() {
> +if (dump_file)
> +  {
> +   fprintf (stderr, "Dumping function to dump file %s for pass %s\n",
> +dump_file_name, current_pass->name);
> +   dump_function_to_file (current_function_decl, dump_file, dump_flags);
> +  }
> +  }
> +
> + public:
> +  pass_ice_hook() {
> +set_internal_error_hook (ice_hook);
> +  }
> +};
> +
> +static pass_ice_hook pass_ice_hook;

current_pass might be NULL so you better do set_internal_error_hook when
we start executing passes (I detest global singletons to do such stuff anyway).

Otherwise looks reasonable to me.

Richard.

> +
>  #include "gt-passes.h"
> --
> 2.12.2
>

Re: [PATCH v2 05/N] Add -fdump*-folding suboption.

[Richard Biener]

On Wed, May 24, 2017 at 12:54 PM, Martin Liška  wrote:
> Hello.
>
> After discussions with Richi, I decided to end up with the transformation
> and thus
> I would like to apply the original patch on top of what was done. Probably
> last change
> should be that we should renumber TDF_* values to start from 1 << 0 and
> holes in numbering
> should be eliminated?

Ok.

Richard.

> Thanks,
> Martin

Re: C++ PATCH to add __integer_pack built-in for std::make_integer_sequence (c++/80396)

[Andreas Schwab]

FAIL: g++.dg/ext/integer-pack2.C  -std=gnu++11 (test for excess errors)
Excess errors:
/daten/aranym/gcc/gcc-20170524/gcc/testsuite/g++.dg/ext/integer-pack2.C:10:48: 
error: overflow in constant expression [-fpermissive]
/daten/aranym/gcc/gcc-20170524/gcc/testsuite/g++.dg/ext/integer-pack2.C:10:48: 
error: overflow in constant expression [-fpermissive]

Andreas.

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

[testsuite, committed] Reinstate absolute line number in gcc.dg/cpp/19940712-1.c

[Tom de Vries]

Hi,

the line number refers to a line in a header file, so we want to keep 
that absolute.


[ The absolute line numbers that we want to replace are the ones that 
start failing once we add a line at the start of the file.


If an absolute line number refers to a header file, and we add a line at 
the start of the including file, the test won't start to fail. However, 
if we rewrite that line number to a relative one, and add a line at the 
start of the including file, the test will start to fail. ]


Committed.

Thanks,
- Tom

Reinstate absolute line number in gcc.dg/cpp/19940712-1.c

2017-05-24  Tom de Vries  

	* gcc.dg/cpp/19940712-1.c: Reinstate absolute line number.

---
 gcc/testsuite/gcc.dg/cpp/19940712-1.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.dg/cpp/19940712-1.c b/gcc/testsuite/gcc.dg/cpp/19940712-1.c
index 7fd9b15..a79b2f5 100644
--- a/gcc/testsuite/gcc.dg/cpp/19940712-1.c
+++ b/gcc/testsuite/gcc.dg/cpp/19940712-1.c
@@ -2,7 +2,7 @@
 /* PR 4713 */
 
 /* dg.exp doesn't read the header files for magic comments. */
-/* { dg-error "unterminated comment" "" { target *-*-* } .-1 } */
+/* { dg-error "unterminated comment" "" { target *-*-* } 4 } */
 /* { dg-error "unterminated comment" "header error" { target *-*-* } 8 } */
 
 #include "19940712-1.h"

Re: [PATCH] rs6000: Fix for separate shrink-wrapping for fp (PR80860, PR80843)

[Segher Boessenkool]

On Tue, May 23, 2017 at 11:07:07AM +, Segher Boessenkool wrote:
> After my r248256, rs6000_components_for_bb allocates an sbitmap of size
> only 32 while it can use up to 64.  This patch fixes it.  It moves the
> n_components variable into the machine_function struct so that other
> hooks can use it.
> 
> Tested on powerpc64-linux {-m32,-m64}.  Will also test on AIX before
> committing.

This fixed the AIX problem (PR80860).  I have committed this now.


Segher

Re: C/C++ OpenACC: acc_pcopyin, acc_pcreate

[Thomas Schwinge]

Hi!

On Wed, 24 May 2017 13:20:54 +0200, Jakub Jelinek  wrote:
> On Wed, May 24, 2017 at 12:55:27PM +0200, Thomas Schwinge wrote:
> > On Tue, 23 May 2017 13:07:15 +0200, Jakub Jelinek  wrote:
> > > new symbols should never be added to an existing symbol
> > > version after a GCC version with that symbol version has been released.

> > would you please remind me where this
> > requirement is coming from?
> 
> There are many reasons

Thanks for the explanation!

> one is e.g. that the dynamic linker uses the symbol
> version names during library loading to verify the library satisfies the
> needs of a binary or some other library; if you add further symbols into
> existing symbol version, then it will be satisfied even by library that
> doesn't provide the symbol (in the above case say acc_pcopyin), and you can
> get a failure either much later (during relocation processing, with lazy
> binding that can be much later), or not at all (with lazy binding and if
> the function isn't called at all during the runtime of the program).

Some might consider that a feature.  ;-)

> Another one is e.g. rpm uses symbol versions in dependencies, but only
> those and not at the required/provided symbol granularity.  So, if you
> have acc_pcopyin@@OACC_2.0.1 and use it in some program, the program
> will have a dependency on libgomp.so.1()(OACC_2.0.1) and thus you
> automatically get the right library that provides it.  If you add to an
> existing symbol version, the dependency will be satisfied even for libraries
> that don't provide it at all.

Ah, yes, I see -- a fine reason.

> All in all, symbol versions aren't there just for documentation purposes,
> but serve various other roles, including the possibility to change ABI
> of existing symbols, but not limited to that.

Sure, I was aware of that specific use -- but that's not relevant to the
case discussed here: a symbol's (non-)existence will always be detected
reliably, whether lazily (see above), or at load time.  That's where I
had gotten the idea from that it's fine to use existing versions for
these new symbols.  (But you reminded me why it's better to use a new
version here, too.)

> The policy of not adding
> new symbols into symbol versions that were already shipped in released
> libraries is something that is strictly followed in glibc, gcc libraries
> (I remember in libstdc++ a bug happened some years ago and some symbols
> were unintentionally exported at an earlier version, which has been cured
> by moving into a new symbol version and providing the old one just as an @
> (vs. @@) symver for compatibility only; e.g. the current libstdc++ check-abi
> stuff verifies this stuff).
> For more info see e.g. https://www.akkadia.org/drepper/symbol-versioning

Yeah, thanks, I had read that a few years ago.


> > But that will only redirect them at the user side.  The intention here is
> 
> The question is if the OpenACC standard allows that or not.

Let's put it this way: it doesn't explicitly disallow that.

> > to also care for users providing their own declarations instead of using
> > , or using "dlsym", and so on -- quite "pathological", I know,
> > but...


> > OK for trunk using "OACC_2.0.1" symbol version?
> 
> Ok.

Thanks.  As posted, committed to trunk in r248410:

commit e4d15e02dfbaf61fb5655595423baaff4a345a60
Author: tschwinge 
Date:   Wed May 24 13:23:34 2017 +

C/C++ OpenACC: acc_pcopyin, acc_pcreate

libgomp/
* openacc.h (acc_pcopyin, acc_pcreate): Provide prototypes instead
of preprocessor definitions.
* libgomp.h (strong_alias): Guard by "#ifdef
HAVE_ATTRIBUTE_ALIAS".
* oacc-mem.c: Provide "acc_pcreate" as alias for
"acc_present_or_create", and "acc_pcopyin" as alias for
"acc_present_or_copyin".
* libgomp.map: New version "OACC_2.0.1".
(OACC_2.0.1): Add "acc_pcopyin", and "acc_pcreate".
* testsuite/libgomp.oacc-c-c++-common/lib-38.c: Remove, merging
its content into...
* testsuite/libgomp.oacc-c-c++-common/lib-32.c: ... this file.
Extend testing.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@248410 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 libgomp/ChangeLog  |  14 ++
 libgomp/libgomp.h  |   5 +-
 libgomp/libgomp.map|   6 +
 libgomp/oacc-mem.c |  22 ++
 libgomp/openacc.h  |   7 +-
 .../testsuite/libgomp.oacc-c-c++-common/lib-32.c   | 241 +++--
 .../testsuite/libgomp.oacc-c-c++-common/lib-38.c   |  64 --
 7 files changed, 272 insertions(+), 87 deletions(-)

diff --git libgomp/ChangeLog libgomp/ChangeLog
index 14e95ef..4a95755 100644
--- libgomp/ChangeLog
+++ libgomp/ChangeLog
@@ -1,5 +1,19 @@
 

[PATCH, GCC/ARM] Fix typo in comment in arm_expand_prologue

[Thomas Preudhomme]

Committed this obvious typo fix for a comment in arm_expand_prologue.

ChangeLog entry is as follows:

*** gcc/ChangeLog ***

2017-05-24  Thomas Preud'homme  

* config/arm/arm.c (arm_expand_prologue): Fix typo in comment.

Best regards,

Thomas
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index a465fc2b29f8ca4b0e5689c0c32025a5aa063e3a..62e4e89ef470a9f3fb2f751bea25c6711c29d6c9 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -21609,7 +21609,7 @@ arm_expand_prologue (void)
 	{
 	  /* If no coprocessor registers are being pushed and we don't have
 	 to worry about a frame pointer then push extra registers to
-	 create the stack frame.  This is done is a way that does not
+	 create the stack frame.  This is done in a way that does not
 	 alter the frame layout, so is independent of the epilogue.  */
 	  int n;
 	  int frame;

Re: [PATCH] PR c++/80544 strip cv-quals from cast results

[Jonathan Wakely]

On 23/05/17 16:26 -0400, Jason Merrill wrote:

On Tue, May 23, 2017 at 2:00 PM, Jonathan Wakely  wrote:

On 19/05/17 15:14 -0400, Jason Merrill wrote:


On Thu, Apr 27, 2017 at 12:59 PM, Jonathan Wakely 
wrote:


I also tried to add a warning like EDG's (see the PR) but it gave a
false positive for direct-list-init of scoped enums (P0138R2, r240449)
because that code goes through build_c_cast to perform the conversion,
so looks like a cast to my new warning.



The enum init code could strip the cv-quals when calling build_c_cast
to avoid the warning.



Thanks, that works. I don't think this warning fits under any existing
option, so I'll add a new one. -Wuseless-cast-qual maybe? Or is that
too close to -Wuseless-cast and -Wcast-qual and would cause confusion?


-Wcast-rvalue-qual ?


I realised that -Wignored-qualifiers is a good fit. That warns about
ignored cv-qualifiers on return types, which is a very similar case.

This patch adds a new function to conditionally warn and calls that
from the build_*_cast functions after they produce a valid result. I
originally put the warnings next to the cv_unqualified calls that
strip the quals, but was getting duplicate warnings when build_cp_cast
calls more than one of the build_*_cast_1 functions.

This also removes the unnecessary check for reference types that
Nathan pointed out.

Tested x86_64-linux and powerpc64-linux. OK for trunk?


commit dddbdfbdc8de6565b45a6d794148dfe077d83d49
Author: Jonathan Wakely 
Date:   Wed May 24 14:09:36 2017 +0100

PR c++/80544 strip cv-quals from cast results

gcc/cp:

	PR c++/80544
	* tree.c (reshape_init): Use unqualified type for direct enum init.
	* typeck.c (maybe_warn_about_cast_ignoring_quals): New.
	(build_static_cast_1, build_reinterpret_cast_1): Strip cv-quals from
	non-class destination types.
	(build_const_cast_1): Strip cv-quals from destination types.
	(build_static_cast, build_reinterpret_cast, build_const_cast)
	(cp_build_c_cast): Add calls to maybe_warn_about_cast_ignoring_quals.

gcc/testsuite:

	PR c++/80544
	* g++.dg/expr/cast11.C: New test.

diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index afd47bb..3ff0130 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -6043,6 +6043,7 @@ reshape_init (tree type, tree init, tsubst_flags_t complain)
   if (is_direct_enum_init (type, init))
 {
   tree elt = CONSTRUCTOR_ELT (init, 0)->value;
+  type = cv_unqualified (type);
   if (check_narrowing (ENUM_UNDERLYING_TYPE (type), elt, complain))
 	return cp_build_c_cast (type, elt, tf_warning_or_error);
   else
diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c
index 13d90a6..ecc7190 100644
--- a/gcc/cp/typeck.c
+++ b/gcc/cp/typeck.c
@@ -6673,6 +6673,22 @@ maybe_warn_about_useless_cast (tree type, tree expr, tsubst_flags_t complain)
 }
 }
 
+/*
+  Warns if the cast ignores cv-qualifiers on TYPE.
+ */
+void
+maybe_warn_about_cast_ignoring_quals (tree type, tsubst_flags_t complain)
+{
+  if (warn_ignored_qualifiers
+  && complain & tf_warning
+  && !CLASS_TYPE_P (type)
+  && (cp_type_quals (type) & (TYPE_QUAL_CONST|TYPE_QUAL_VOLATILE)))
+{
+  warning (OPT_Wignored_qualifiers, "type qualifiers ignored on cast "
+	   "result type");
+}
+}
+
 /* Convert EXPR (an expression with pointer-to-member type) to TYPE
(another pointer-to-member type in the same hierarchy) and return
the converted expression.  If ALLOW_INVERSE_P is permitted, a
@@ -6746,6 +6762,10 @@ build_static_cast_1 (tree type, tree expr, bool c_cast_p,
   /* Save casted types in the function's used types hash table.  */
   used_types_insert (type);
 
+  /* A prvalue of non-class type is cv-unqualified.  */
+  if (!CLASS_TYPE_P (type))
+type = cv_unqualified (type);
+
   /* [expr.static.cast]
 
  An lvalue of type "cv1 B", where B is a class type, can be cast
@@ -7035,7 +7055,10 @@ build_static_cast (tree type, tree expr, tsubst_flags_t complain)
   if (valid_p)
 {
   if (result != error_mark_node)
-	maybe_warn_about_useless_cast (type, expr, complain);
+	{
+	  maybe_warn_about_useless_cast (type, expr, complain);
+	  maybe_warn_about_cast_ignoring_quals (type, complain);
+	}
   return result;
 }
 
@@ -7108,6 +7131,10 @@ build_reinterpret_cast_1 (tree type, tree expr, bool c_cast_p,
   /* Save casted types in the function's used types hash table.  */
   used_types_insert (type);
 
+  /* A prvalue of non-class type is cv-unqualified.  */
+  if (!CLASS_TYPE_P (type))
+type = cv_unqualified (type);
+
   /* [expr.reinterpret.cast]
  An lvalue expression of type T1 can be cast to the type
  "reference to T2" if an expression of type "pointer to T1" can be
@@ -7289,7 +7316,10 @@ build_reinterpret_cast (tree type, tree expr, tsubst_flags_t complain)
   r = build_reinterpret_cast_1 (type, expr, /*c_cast_p=*/false,
 /*valid_p=*/NULL, complain);
   if (r != 

Re: C++ PATCH to add __integer_pack built-in for std::make_integer_sequence (c++/80396)

[Jakub Jelinek]

On Wed, May 24, 2017 at 04:16:30PM +0200, Andreas Schwab wrote:
> FAIL: g++.dg/ext/integer-pack2.C  -std=gnu++11 (test for excess errors)
> Excess errors:
> /daten/aranym/gcc/gcc-20170524/gcc/testsuite/g++.dg/ext/integer-pack2.C:10:48:
>  error: overflow in constant expression [-fpermissive]
> /daten/aranym/gcc/gcc-20170524/gcc/testsuite/g++.dg/ext/integer-pack2.C:10:48:
>  error: overflow in constant expression [-fpermissive]

To be precise, it fails only on 32-bit targets.

If we at that point want some wider integer that when cast to int
is 0 (or small enough positive number?), shall we use something like
this, or say 1LL << (sizeof (int) * __CHAR_BIT__), or 2LL * INT_MIN,
something else?  Do we need to include ?  Or can we replace
INT_MAX with __INT_MAX__?
Not sure about that -2147483650 for 16-bit int targets (perhaps the test can
be guarded with int32 effective target).

2017-05-24  Jakub Jelinek  <ja...@redhat.com>

* g++.dg/ext/integer-pack2.C (w): Use -9223372036854775807LL - 1
instead of -9223372036854775808.

--- gcc/testsuite/g++.dg/ext/integer-pack2.C.jj 2017-05-24 11:59:01.0 
+0200
+++ gcc/testsuite/g++.dg/ext/integer-pack2.C2017-05-24 16:24:18.341421124 
+0200
@@ -7,6 +7,6 @@ template struct intege
 template
  using make_integer_sequence = integer_sequence<T, __integer_pack(num)...>; // 
{ dg-error "argument" }
 
-make_integer_sequence<int, -9223372036854775808> w;
+make_integer_sequence<int, -9223372036854775807LL - 1> w;
 make_integer_sequence<int, INT_MAX> x;// { dg-message "required" }
 make_integer_sequence<int, -2147483650> y; // { dg-message "required" }


Jakub

Re: [PATCH GCC8][31/33]Set range information for niter bound of vectorized loop

[Richard Biener]

On Mon, May 22, 2017 at 7:13 PM, Bin.Cheng  wrote:
> On Fri, May 19, 2017 at 1:51 PM, Richard Biener
>  wrote:
>> On Mon, May 15, 2017 at 5:58 PM, Bin.Cheng  wrote:
>>> On Thu, May 11, 2017 at 12:02 PM, Richard Biener
>>>  wrote:
 On Tue, Apr 18, 2017 at 12:54 PM, Bin Cheng  wrote
> Hi,
> Based on vect_peeling algorithm, we know for sure that vectorized loop 
> must iterates at least once.
> This patch sets range information for niter bounds of vectorized loop.  
> This helps niter analysis,
> so iv elimination too.
> Is it OK?

niters_vector = force_gimple_operand (niters_vector, , true, 
 var);
gsi_insert_seq_on_edge_immediate (pe, stmts);
 +  /* Peeling algorithm guarantees that vector loop bound is at least 
 ONE,
 +we set range information to make niters analyzer's life easier.  
 */
 +  if (TREE_CODE (niters_vector) == SSA_NAME)
 +   set_range_info (niters_vector, VR_RANGE, build_int_cst (type, 1),
 +   fold_build2 (RSHIFT_EXPR, type,
 +TYPE_MAX_VALUE (type), log_vf));

 if all of niters_vector folds to an original SSA name then
 niters_vector after gimplification
 is not a new SSA name and thus you can't set range-info on it.

 Likewise for the other case where LOOP_VINFO_NITERS is just an SSA name.
>>> Hi,
>>> This is updated patch.  It checks whether the result ssa name is newly
>>> created tmp and only sets range information if so.
>>>
>>> Is it OK?
>>
>> A better way to check whether the SSA name is new is to see if 'stmts'
>> filled by force_gimple_operand is non-empty.
> Hi,
> Here is updated patch checking empty gimple_seq.  Is it OK?

Ok.  As a bonus you could have used wide-ints to feed set_range_info
(not sure if wide_int_ref & allows you to pass '1' literally...)

Richard.

> Thanks,
> bin
>>
>> Richard.
>>
>>> Thanks,
>>> bin
>>>
>>> 2017-04-11  Bin Cheng  
>>>
>>> * tree-vectorizer.h (vect_build_loop_niters): New parameter.
>>> * tree-vect-loop-manip.c (vect_build_loop_niters): New parameter.
>>> Set true to new parameter if new ssa variable is defined.
>>> (vect_gen_vector_loop_niters): Refactor.  Set range information
>>> for the new vector loop bound variable.
>>> (vect_do_peeling): Ditto.
>>>

 Richard.

> Thanks,
> bin
> 2017-04-11  Bin Cheng  
>
> * tree-vect-loop-manip.c (vect_gen_vector_loop_niters): Refactor.
> Set range information for vector loop bound variable.
> (vect_do_peeling): Ditto.

Re: OpenACC 1.0 compatibility: acc_async_wait, acc_async_wait_all

[Thomas Schwinge]

Hi!

On Wed, 24 May 2017 13:58:12 +0200, Jakub Jelinek  wrote:
> On Wed, May 24, 2017 at 01:47:34PM +0200, Thomas Schwinge wrote:
> > On Tue, 23 May 2017 13:17:26 +0200, Jakub Jelinek  wrote:
> > > On Mon, May 22, 2017 at 07:42:38PM +0200, Thomas Schwinge wrote:
> > > > For OpenACC 1.0 compatibility, we need to provide the aliases
> > > > acc_async_wait, and acc_async_wait_all for acc_wait, and acc_wait_all,
> > > > respectively.
> > 
> > > > OpenACC 1.0 compatibility: acc_async_wait, acc_async_wait_all

> > OK for trunk using "OACC_2.0.1" symbol version?
> 
> Ok.

Thanks.  Committed to trunk in r248413:

commit 0e1c776433f71834e5af2c9778a4f20bfb04f7f3
Author: tschwinge 
Date:   Wed May 24 13:25:01 2017 +

OpenACC 1.0 compatibility: acc_async_wait, acc_async_wait_all

libgomp/
* openacc.h (acc_async_wait, acc_async_wait_all): New prototypes.
* libgomp.map (OACC_2.0.1): Add these.
* oacc-async.c (acc_async_wait, acc_async_wait_all): New aliases
for "acc_wait", and "acc_wait_all", respectively.
* openacc.f90 (acc_async_wait, acc_async_wait_all): New interfaces
for "acc_wait", and "acc_wait_all", respectively.
* openacc_lib.h (acc_async_wait, acc_async_wait_all): Likewise.
* libgomp.texi (acc_wait, acc_wait_all): Update.
* testsuite/libgomp.oacc-c-c++-common/par-reduction-2.c: Update.
* testsuite/libgomp.oacc-fortran/par-reduction-2-1.f: New file.
* testsuite/libgomp.oacc-fortran/par-reduction-2-2.f: Likewise.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@248413 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 libgomp/ChangeLog  | 12 +
 libgomp/libgomp.map|  2 +
 libgomp/libgomp.texi   |  7 ++-
 libgomp/oacc-async.c   | 22 +
 libgomp/openacc.f90| 16 +-
 libgomp/openacc.h  |  2 +
 libgomp/openacc_lib.h  | 11 +
 .../libgomp.oacc-c-c++-common/par-reduction-2.c|  9 ++--
 .../libgomp.oacc-fortran/par-reduction-2-1.f   | 57 ++
 .../libgomp.oacc-fortran/par-reduction-2-2.f   | 57 ++
 10 files changed, 188 insertions(+), 7 deletions(-)

diff --git libgomp/ChangeLog libgomp/ChangeLog
index 55869d2..8adc10b 100644
--- libgomp/ChangeLog
+++ libgomp/ChangeLog
@@ -1,5 +1,17 @@
 2017-05-24  Thomas Schwinge  
 
+   * openacc.h (acc_async_wait, acc_async_wait_all): New prototypes.
+   * libgomp.map (OACC_2.0.1): Add these.
+   * oacc-async.c (acc_async_wait, acc_async_wait_all): New aliases
+   for "acc_wait", and "acc_wait_all", respectively.
+   * openacc.f90 (acc_async_wait, acc_async_wait_all): New interfaces
+   for "acc_wait", and "acc_wait_all", respectively.
+   * openacc_lib.h (acc_async_wait, acc_async_wait_all): Likewise.
+   * libgomp.texi (acc_wait, acc_wait_all): Update.
+   * testsuite/libgomp.oacc-c-c++-common/par-reduction-2.c: Update.
+   * testsuite/libgomp.oacc-fortran/par-reduction-2-1.f: New file.
+   * testsuite/libgomp.oacc-fortran/par-reduction-2-2.f: Likewise.
+
* openacc_lib.h (acc_pcopyin, acc_pcreate): Route to
acc_present_or_copyin and acc_present_or_create procedures,
respectively.
diff --git libgomp/libgomp.map libgomp/libgomp.map
index b43c6de..f9044ae 100644
--- libgomp/libgomp.map
+++ libgomp/libgomp.map
@@ -380,6 +380,8 @@ OACC_2.0 {
 
 OACC_2.0.1 {
   global:
+   acc_async_wait;
+   acc_async_wait_all;
acc_pcopyin;
acc_pcreate;
 } OACC_2.0;
diff --git libgomp/libgomp.texi libgomp/libgomp.texi
index cc5ee1c..230720f 100644
--- libgomp/libgomp.texi
+++ libgomp/libgomp.texi
@@ -2095,12 +2095,15 @@ specified in @var{arg}.
 @item @emph{C/C++}:
 @multitable @columnfractions .20 .80
 @item @emph{Prototype}: @tab @code{acc_wait(arg);}
+@item @emph{Prototype (OpenACC 1.0 compatibility)}: @tab 
@code{acc_async_wait(arg);}
 @end multitable
 
 @item @emph{Fortran}:
 @multitable @columnfractions .20 .80
 @item @emph{Interface}: @tab @code{subroutine acc_wait(arg)}
 @item   @tab @code{integer(acc_handle_kind) arg}
+@item @emph{Interface (OpenACC 1.0 compatibility)}: @tab @code{subroutine 
acc_async_wait(arg)}
+@item   @tab 
@code{integer(acc_handle_kind) arg}
 @end multitable
 
 @item @emph{Reference}:
@@ -2119,11 +2122,13 @@ This function waits for the completion of all 
asynchronous operations.
 @item @emph{C/C++}:
 @multitable @columnfractions .20 .80
 @item @emph{Prototype}: @tab @code{acc_wait_all(void);}
+@item @emph{Prototype (OpenACC 1.0 compatibility)}: @tab 
@code{acc_async_wait_all(void);}
 

Re: [PATCH, ARM/AArch64] drop aarch32 support for falkor/qdf24xx

[Richard Earnshaw (lists)]

On 12/05/17 03:43, Jim Wilson wrote:
> Early steppings had aarch32 support, current steppings don't, so the
> aarch32 support for falkor/qdf24xx needs to be dropped.  This mostly
> involves removing falkor/qdf24xx references from the arm port.  The
> qdf24xx_extra_costs structure moves from the arm port to the aarch64
> port.
> 
> This was tested with aarch64-linux and armv8-linux bootstraps and make
> checks.  There were no regressions.  Also verified by hand that the
> -mcpu=falkor and -mqdf24xx options no longer work in the arm port but
> still work in the aarch64 port.
> 
> Jim
> 

OK.  does this need to go in the gcc-8 changes file?

R.

Re: [config PATCH] --enable-languages

[Richard Biener]

On Fri, May 19, 2017 at 6:59 PM, Nathan Sidwell  wrote:
> --enable-languages=all confused me, because as RichardB said, 'it really
> means default'.  So this patch does 2 things
> 1) allow --enable-languages=default to mean what =all does now.
> 2) change =all to mean all available languages.
> 2.1) jit is included in =all if -enable-host-shared is given.  If you don't
> you get a warning that JIT's not included.
>
> If you're used to saying =all, then you'll get more languages with this
> patch than you used to.
>
> ok?

Ok.  Did you check =all works with/without a host Ada compiler installed?
(warning but not including ada in the without case?)

Richard.

> nathan
> --
> Nathan Sidwell

Re: [PATCH, ARM/AArch64] drop aarch32 support for falkor/qdf24xx

[Jim Wilson]

On Wed, May 24, 2017 at 6:56 AM, Richard Earnshaw (lists)
 wrote:
> OK.  does this need to go in the gcc-8 changes file?

Falkor hasn't shipped yet.  I'm dropping features that only existed in
preproduction NDA hardware, so there isn't anything end user visible,
and hence I don't think that it needs to be in the release notes.

Jim

Re: [PATCH, ARM/AArch64] drop aarch32 support for falkor/qdf24xx

[Richard Earnshaw (lists)]

On 24/05/17 15:18, Jim Wilson wrote:
> On Wed, May 24, 2017 at 6:56 AM, Richard Earnshaw (lists)
>  wrote:
>> OK.  does this need to go in the gcc-8 changes file?
> 
> Falkor hasn't shipped yet.  I'm dropping features that only existed in
> preproduction NDA hardware, so there isn't anything end user visible,
> and hence I don't think that it needs to be in the release notes.
> 
> Jim
> 

Fair enough, so what about a minimal back-port to GCC-7 that just
disables the CPU name for aarch32?

R.

Re: [PATCH] Fix PR80754

[Vladimir Makarov]

On 05/17/2017 07:32 AM, Wilco Dijkstra wrote:

When lra-remat rematerializes an instruction with a clobber, it checks
that the clobber does not kill live registers.  However it fails to check
that the clobber also doesn't overlap with the destination register of the
final rematerialized instruction.  As a result it is possible to generate
illegal instructions with the same hard register as the destination and a
clobber.  Fix this by also checking for overlaps with the destination
register.

Bootstrap OK on arm-linux-gnueabihf for ARM and Thumb-2, OK for commit?



Wilco, thank you for working on the PR.

The patch looks OK for me.  You can commit it into the trunk and gcc7 
branch.

Re: Translate libgomp.oacc-c-c++-common/lib-32.c into Fortran

[Thomas Schwinge]

Hi!

On Tue, 23 May 2017 13:08:22 +0200, Jakub Jelinek  wrote:
> On Mon, May 22, 2017 at 04:29:51PM +0200, Thomas Schwinge wrote:
> > On Mon, 22 May 2017 16:26:48 +0200, I wrote:
> > > C/C++ OpenACC: acc_pcopyin, acc_pcreate
> > 
> > > libgomp/
> > > [...]
> > > * testsuite/libgomp.oacc-c-c++-common/lib-38.c: Remove, 
> > > merging
> > > its content into...
> > > * testsuite/libgomp.oacc-c-c++-common/lib-32.c: ... this file.
> > > Extend testing.
> > 
> > ... which I then translated into two Fortran variants; OK for trunk?

> Ok.

Thanks.  As posted, committed to trunk in r248411:

commit 4a5596a04ac52ae4df1347e7980e0d60fcd1e84b
Author: tschwinge 
Date:   Wed May 24 13:23:45 2017 +

Translate libgomp.oacc-c-c++-common/lib-32.c into Fortran

libgomp/
* testsuite/libgomp.oacc-fortran/lib-32-1.f: New file.
* testsuite/libgomp.oacc-fortran/lib-32-2.f: Likewise.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@248411 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 libgomp/ChangeLog  |   3 +
 .../testsuite/libgomp.oacc-c-c++-common/lib-32.c   |   1 +
 libgomp/testsuite/libgomp.oacc-fortran/lib-32-1.f  | 179 +
 libgomp/testsuite/libgomp.oacc-fortran/lib-32-2.f  | 173 
 4 files changed, 356 insertions(+)

diff --git libgomp/ChangeLog libgomp/ChangeLog
index 4a95755..af8c5ca 100644
--- libgomp/ChangeLog
+++ libgomp/ChangeLog
@@ -1,5 +1,8 @@
 2017-05-24  Thomas Schwinge  
 
+   * testsuite/libgomp.oacc-fortran/lib-32-1.f: New file.
+   * testsuite/libgomp.oacc-fortran/lib-32-2.f: Likewise.
+
* openacc.h (acc_pcopyin, acc_pcreate): Provide prototypes instead
of preprocessor definitions.
* libgomp.h (strong_alias): Guard by "#ifdef
diff --git libgomp/testsuite/libgomp.oacc-c-c++-common/lib-32.c 
libgomp/testsuite/libgomp.oacc-c-c++-common/lib-32.c
index 6a9e995..1696fb6 100644
--- libgomp/testsuite/libgomp.oacc-c-c++-common/lib-32.c
+++ libgomp/testsuite/libgomp.oacc-c-c++-common/lib-32.c
@@ -1,4 +1,5 @@
 /* acc_present_or_create, acc_present_or_copyin, etc.  */
+/* See also Fortran variants in "../libgomp.oacc-fortran/lib-32*".  */
 
 #include 
 #include 
diff --git libgomp/testsuite/libgomp.oacc-fortran/lib-32-1.f 
libgomp/testsuite/libgomp.oacc-fortran/lib-32-1.f
new file mode 100644
index 000..4606d77
--- /dev/null
+++ libgomp/testsuite/libgomp.oacc-fortran/lib-32-1.f
@@ -0,0 +1,179 @@
+! ACC_PRESENT_OR_CREATE, ACC_PRESENT_OR_COPYIN, etc.
+! Variant of "../libgomp.oacc-c-c++-common/lib-32.c".
+! Variant using "openacc_lib.h".
+
+! { dg-do run }
+
+  PROGRAM MAIN
+  IMPLICIT NONE
+  INCLUDE "openacc_lib.h"
+
+  INTEGER, PARAMETER :: N = 1
+  INTEGER, ALLOCATABLE :: H(:)
+  INTEGER :: I
+  LOGICAL :: SHARED_MEM
+
+  ALLOCATE (H(N))
+  DO I = 1, N
+ H(I) = I + 0
+  END DO
+
+  SHARED_MEM = ACC_IS_PRESENT (H)
+
+  CALL ACC_PRESENT_OR_CREATE (H)
+  IF (.NOT. ACC_IS_PRESENT (H)) CALL ABORT
+
+!$ACC PARALLEL LOOP DEFAULT (PRESENT)
+  DO I = 1, N
+ H(I) = I + 1
+  END DO
+!$ACC END PARALLEL LOOP
+
+  DO I = 1, N
+ IF (H(I) .NE. I + MERGE (1, 0, SHARED_MEM)) CALL ABORT
+ H(I) = I + 2
+  END DO
+
+  CALL ACC_PRESENT_OR_CREATE (H)
+
+!$ACC PARALLEL LOOP DEFAULT (PRESENT)
+  DO I = 1, N
+ IF (H(I) .NE. I + MERGE (2, 1, SHARED_MEM)) CALL ABORT
+ H(I) = I + 3
+  END DO
+!$ACC END PARALLEL LOOP
+
+  DO I = 1, N
+ IF (H(I) .NE. I + MERGE (3, 2, SHARED_MEM)) CALL ABORT
+ H(I) = I + 4
+  END DO
+
+!  CALL ACC_PCREATE (H)
+  CALL ACC_PRESENT_OR_CREATE (H)
+
+!$ACC PARALLEL LOOP DEFAULT (PRESENT)
+  DO I = 1, N
+ IF (H(I) .NE. I + MERGE (4, 3, SHARED_MEM)) CALL ABORT
+ H(I) = I + 5
+  END DO
+!$ACC END PARALLEL LOOP
+
+  DO I = 1, N
+ IF (H(I) .NE. I + MERGE (5, 4, SHARED_MEM)) CALL ABORT
+ H(I) = I + 6
+  END DO
+
+  CALL ACC_PRESENT_OR_COPYIN (H)
+
+!$ACC PARALLEL LOOP DEFAULT (PRESENT)
+  DO I = 1, N
+ IF (H(I) .NE. I + MERGE (6, 5, SHARED_MEM)) CALL ABORT
+ H(I) = I + 7
+  END DO
+!$ACC END PARALLEL LOOP
+
+  DO I = 1, N
+ IF (H(I) .NE. I + MERGE (7, 6, SHARED_MEM)) CALL ABORT
+ H(I) = I + 8
+  END DO
+
+!  CALL ACC_PCOPYIN (H)
+  CALL ACC_PRESENT_OR_COPYIN (H)
+
+!$ACC PARALLEL LOOP DEFAULT (PRESENT)
+  DO I = 1, N
+ IF (H(I) .NE. I + MERGE (8, 7, SHARED_MEM)) CALL ABORT
+ H(I) = I + 9
+  END DO
+!$ACC END PARALLEL LOOP
+
+  DO I = 1, N
+ IF (H(I) .NE. I + MERGE (9, 8, SHARED_MEM)) CALL ABORT
+ H(I) = I + 10
+  END DO
+
+  CALL ACC_COPYOUT (H)
+  IF (.NOT. SHARED_MEM) 

Re: [PATCH 0/5 v3] Vect peeling cost model

[Richard Biener]

On Wed, May 24, 2017 at 1:54 PM, Robin Dapp  wrote:
>> So what did actually change?  I'd rather not diff the diffs.  Can you
>> provide an incremental change, aka p6 that would apply to the
>> previous series instead?
>
> -p6.diff attached which also addresses Richard's remark regarding vf/2.
> Note that this applies to the old series but the old series itself (-p3)
> doesn't apply to trunk anymore (because of the change in
> vect_enhance_data_refs_alignment).

The series is ok.

Thanks,
Richard.

> Regards
>  Robin
>
> --
>
> gcc/ChangeLog:
>
> 2017-05-24  Robin Dapp  
>
> * tree-vect-data-refs.c (vect_get_peeling_costs_all_drs):
> Introduce unknown_misalignment parameter and remove vf.
> (vect_peeling_hash_get_lowest_cost):
> Pass unknown_misalignemtn parameter.
> (vect_enhance_data_refs_alignment):
> Fix unsupportable data ref treatment.
>

Re: [0/67] Add wrapper classes for machine_modes

[Richard Sandiford]

Jeff Law  writes:
> On 12/09/2016 05:48 AM, Richard Sandiford wrote:
>> This series includes most of the changes in group C from:
>> 
>>  https://gcc.gnu.org/ml/gcc/2016-11/msg00033.html
>> 
>> The idea is to add wrapper classes around machine_mode_enum
>> for specific groups of modes, such as scalar integers, scalar floats,
>> complex values, etc.  This has two main benefits: one specific to SVE
>> and one not.
>> 
>> The SVE-specific benefit is that it helps to introduce the concept
>> of variable-length vectors.  To do that we need to change the size
>> of a vector mode from being a known compile-time constant to being
>> (possibly) a run-time invariant.  We then need to do the same for
>> unconstrained machine_modes, which might or might not be vectors.
>> Introducing these new constrained types means that we can continue
>> to treat them as having a constant size.
>> 
>> The other benefit is that it uses static type checking to enforce
>> conditions that are easily forgotten otherwise.  The most common
>> sources of problems seem to be:
>> 
>> (a) using VOIDmode or BLKmode where a scalar integer was expected
>>  (e.g. when getting the number of bits in the value).
>> 
>> (b) simplifying vector operations in ways that only make sense for
>>  scalars.
>> 
>> The series helps with both of these, although we don't get the full
>> benefit of (b) until variable-sized modes are introduced.
>> 
>> I know of three specific cases in which the static type checking
>> forced fixes for things that turned out to be real bugs (although
>> we didn't know that at the time, otherwise we'd have posted patches).
>> They were later fixed for trunk by:
>> 
>>https://gcc.gnu.org/ml/gcc-patches/2016-07/msg01783.html
>>https://gcc.gnu.org/ml/gcc-patches/2016-11/msg02983.html
>>https://gcc.gnu.org/ml/gcc-patches/2016-11/msg02896.html
>> 
>> The group C patches in ARM/sve-branch did slow compile time down a little.
>> I've since taken steps to avoid that:
>> 
>> - Make the tailcall pass handle aggregate parameters and return values
>>(already in trunk).
>> 
>> - Turn some of the new wrapper functions into inline functions.
>> 
>> - Make all the machmode.h macros that used:
>> 
>>  __builtin_constant_p (M) ? foo_inline (M) : foo_array[M[
>> 
>>forward to an ALWAYS_INLINE function, so that (a) M is only evaluated
>>once and (b) __builtin_constant_p is applied to a variable, and so is
>>deferred until later passes.  This helped the optimisation to fire in
>>more cases and to continue firing when M is a class rather than a
>>raw enum.
>> 
>> - In a similar vein, make sure that conditions like:
>> 
>>   SImode == DImode
>> 
>>are treated as builtin_constant_p by gencondmd, so that .md patterns
>>with those conditions are dropped.
>> 
>> With these changes the series is actually a very slight compile-time win.
>> That might seem unlikely, but there are several possible reasons:
>> 
>> 1. The machmode.h macro change above might allow more constant folding.
>> 
>> 2. The series has a tendency to evaluate modes once, rather than
>> continually fetching them from (sometimes quite deep) rtx nests.
>> Refetching a mode is a particular problem if call comes between
>> two uses, since the compiler then has to re-evaluate the whole thing.
>> 
>> 3. The series introduces many uses of new SCALAR_*TYPE_MODE macros,
>> as alternatives to TYPE_MODE.  The new macros avoid the usual:
>> 
>>   (VECTOR_TYPE_P (TYPE_CHECK (NODE)) \
>>? vector_type_mode (NODE) : (NODE)->type_common.mode)
>> 
>> and become direct field accesses in release builds.
>> 
>> VECTOR_TYPE_P would be consistently false for these uses,
>> but call-clobbered registers would usually be treated as clobbered
>> by the condition as a whole.
>> 
>> Maybe (3) is the most likely reason.
>> 
>> I tested this by compiling the testsuite for:
>> 
>>  aarch64-linux-gnu alpha-linux-gnu arc-elf arm-linux-gnueabi
>>  arm-linux-gnueabihf avr-elf bfin-elf c6x-elf cr16-elf cris-elf
>>  epiphany-elf fr30-elf frv-linux-gnu ft32-elf h8300-elf
>>  hppa64-hp-hpux11.23 ia64-linux-gnu i686-pc-linux-gnu
>>  i686-apple-darwin iq2000-elf lm32-elf m32c-elf m32r-elf
>>  m68k-linux-gnu mcore-elf microblaze-elf mips-linux-gnu
>>  mipsisa64-linux-gnu mmix mn10300-elf moxie-rtems msp430-elf
>>  nds32le-elf nios2-linux-gnu nvptx-none pdp11 powerpc-linux-gnuspe
>>  powerpc-eabispe powerpc64-linux-gnu powerpc-ibm-aix7.0 rl78-elf
>>  rx-elf s390-linux-gnu s390x-linux-gnu sh-linux-gnu sparc-linux-gnu
>>  sparc64-linux-gnu sparc-wrs-vxworks spu-elf tilegx-elf tilepro-elf
>>  xstormy16-elf v850-elf vax-netbsdelf visium-elf x86_64-darwin
>>  x86_64-linux-gnu xtensa-elf
>> 
>> and checking that there were no changes in assembly.  Also tested
>> in the normal way on aarch64-linux-gnu and x86_64-linux-gnu.
>> 
>> The series depends on the 

Re: Reorganise machmode.h headers

[Richard Sandiford]

Jeff Law  writes:
> On 11/16/2016 09:32 AM, Richard Sandiford wrote:
>> Later patches will make machmode.h rely on wide-int.h and the
>> new poly-int.h, so it needs to appear later in the coretypes.h
>> include list.
>>
>> Previously machmode.h included insn-modes.h, which as well as
>> the main mode enum contains configuration information like
>> MAX_BITSIZE_MODE_ANY_INT.  This still needs to come first,
>> since files like wide-int.h depend on the configuration
>> information.
>>
>> Similarly, later patches will make the auto-generated inline
>> mode size functions use poly-int.h, so the patch splits them
>> out into their own header file and includes it after the
>> integer utilities.
>>
>> The patch also makes the generator files include machmode.h
>> via coretypes.h.  Previously they did it by more indirect means.
>>
>> Finally, the patch makes wide-int-print.h available via coretypes.h
>> too.  There didn't seem to be any reason to force only the print
>> routines to be included directly, and it would be painful to extend
>> that approach to the new polynomial integer classes.
>>
>> Tested on aarch64-linux-gnu and x86_64-linux-gnu.  OK to install?
>>
>> Thanks,
>> Richard
>>
>>
>> [ This patch is part of the SVE series posted here:
>>   https://gcc.gnu.org/ml/gcc/2016-11/msg00030.html ]
>>
>> gcc/
>> 2016-11-16  Richard Sandiford  
>>  Alan Hayward  
>>  David Sherwood  
>>
>>  * Makefile.in (MACHMODE_H): Remove insn-modes.h
>>  (CORETYPES_H): New define.
>>  (MOSTLYCLEANFILES): Add insn-modes-inline.h.
>>  (insn-modes-inline.h, s-modes-inline-h): New rules.
>>  (generated_files): Add insn-modes-inline.h.
>>  (RTL_BASE_H, TREE_CORE_H): Use CORETYPES_H instead of coretypes.h.
>>  (build/gensupport.o, build/print-rtl.o, build/read-md.o): Likewise.
>>  (build/read-rtl.o, build/rtl.o, build/vec.o, build/hash-table.o)
>>  (build/inchash.o, build/gencondmd.o, build/genattr.o): Likewise.
>>  (build/genattr-common.o, build/genattrtab.o, build/genautomata.o)
>>  (build/gencheck.o, build/gencodes.o, build/genconditions.o): Likewise.
>>  (build/genconfig.o, build/genconstants.o, build/genemit.o): Likewise.
>>  (build/genenums.o, build/genextract.o, build/genflags.o): Likewise.
>>  (build/gentarget-def.o, build/genmddeps.o, build/genopinit.o)
>>  (build/genoutput.o, build/genpeep.o, build/genpreds.o): Likewise.
>>  (build/genrecog.o, build/genmddump.o, build/genmatch.o): Likewise.
>>  (build/gencfn-macros.o, build/gcov-iov.o): Likewise.
>>  * coretypes.h: Include everything up to real.h for generators.
>>  Include insn-modes.h first.  Include wide-int-print.h after
>>  wide-int.h.  Include insn-modes-inline.h and then machmode.h.
>>  * machmode.h: Don't include insn-modes.h here.
>>  * function-tests.c: Remove includes of signop.h, machmode.h,
>>  double-int.h and wide-int.h.
>>  * rtl.h: Likewise.
>>  * gcc-rich-location.c: Remove includes of machmode.h, double-int.h
>>  and wide-int.h.
>>  * optc-save-gen.awk: Likewise.
>>  * gencheck.c (BITS_PER_UNIT): Delete dummy definition.
>>  * godump.c: Remove include of wide-int-print.h.
>>  * pretty-print.h: Likewise.
>>  * wide-int-print.cc: Likewise.
>>  * wide-int.cc: Likewise.
>>  * hash-map-tests.c: Remove include of signop.h.
>>  * hash-set-tests.c: Likewise.
>>  * rtl-tests.c: Likewise.
>>  * mkconfig.sh: Remove include of machmode.h.
>>  * genmodes.c (emit_insn_modes_h): Split emission of inline functions
>>  into...
>>  (emit_insn_modes_inline_h): ...this new function.  Emit the code
>>  into an insn-modes-inline.h header file, adding appropriate
>>  include guards and end comments.
>>  (emit_insn_modes_c_header): Remove include of machmode.h.
>>  (emit_min_insn_modes_c_header): Include coretypes.h rather than
>>  machmode.h.
>>  (main): Handle -i flag and call emit_insn_modes_inline_h when
>>  it is passed.
> So I don't see anything here particularly problematical.  My question is 
> whether or not there's anything significant to be gained to moving 
> forward with this kit, assuming the 67 piece kit is not likely to move 
> forward.
>
> I do think you'll need some tweaks to the contrib/header-tools which 
> know about the core headers and dependencies.  Hopefully what's in there 
> is easy enough to figure out how to twiddle appropriately.

OK, thanks for the pointer.  I think this patch should do that.

gcc-order-headers seems to have bitrotted a bit, since it gives:

Traceback (most recent call last):
  File "../contrib/header-tools/gcc-order-headers", line 267, in 
process_known_dups ()
  File "../contrib/header-tools/gcc-order-headers", line 101, in 
process_known_dups
if dups[i] and "rtl.h" in dups[i]:
KeyError: 'dumpfile.h'

But the change itself looks 

Re: [PATCH] Fix a SPARC -mcbcond compare-and-branch out of range failure.

[Sheldon Lobo]

Thanks for the review.

On 05/24/2017 02:52 AM, Eric Botcazou wrote:


OK for all active branches, but the ChangeLog entry should be something like:

* config/sparc/sparc.md (length): Return the correct value for -mflat
sibcalls to match output_sibcall.


Will do.



Note that we *never* use a pair of parentheses after function names.



Noted for future reference.

Thanks again,
Sheldon

Update libstdc++ baseline symbols (ia64, m68k)

[Andreas Schwab]

Committed.

Andreas.

* config/abi/post/ia64-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/m68k-linux-gnu/baseline_symbols.txt: Likewise.

diff --git a/libstdc++-v3/config/abi/post/ia64-linux-gnu/baseline_symbols.txt 
b/libstdc++-v3/config/abi/post/ia64-linux-gnu/baseline_symbols.txt
index 3b8dc79d98..0b166d5e2a 100644
--- a/libstdc++-v3/config/abi/post/ia64-linux-gnu/baseline_symbols.txt
+++ b/libstdc++-v3/config/abi/post/ia64-linux-gnu/baseline_symbols.txt
@@ -444,6 +444,7 @@ 
FUNC:_ZNKSt13basic_fstreamIwSt11char_traitsIwEE7is_openEv@GLIBCXX_3.4
 FUNC:_ZNKSt13basic_istreamIwSt11char_traitsIwEE6gcountEv@@GLIBCXX_3.4
 FUNC:_ZNKSt13basic_istreamIwSt11char_traitsIwEE6sentrycvbEv@@GLIBCXX_3.4
 FUNC:_ZNKSt13basic_ostreamIwSt11char_traitsIwEE6sentrycvbEv@@GLIBCXX_3.4
+FUNC:_ZNKSt13random_device13_M_getentropyEv@@GLIBCXX_3.4.24
 FUNC:_ZNKSt13runtime_error4whatEv@@GLIBCXX_3.4
 FUNC:_ZNKSt14basic_ifstreamIcSt11char_traitsIcEE5rdbufEv@@GLIBCXX_3.4
 FUNC:_ZNKSt14basic_ifstreamIcSt11char_traitsIcEE7is_openEv@@GLIBCXX_3.4.5
@@ -1329,6 +1330,7 @@ 
FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC1EPKwRKS1_@@GLIBCXX_3.4
 FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC1EPKwmRKS1_@@GLIBCXX_3.4
 FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC1ERKS1_@@GLIBCXX_3.4
 FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC1ERKS2_@@GLIBCXX_3.4
+FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC1ERKS2_mRKS1_@@GLIBCXX_3.4.23
 FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC1ERKS2_mm@@GLIBCXX_3.4
 FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC1ERKS2_mmRKS1_@@GLIBCXX_3.4
 
FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC1ESt16initializer_listIwERKS1_@@GLIBCXX_3.4.11
@@ -1342,6 +1344,7 @@ 
FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC2EPKwRKS1_@@GLIBCXX_3.4
 FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC2EPKwmRKS1_@@GLIBCXX_3.4
 FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC2ERKS1_@@GLIBCXX_3.4
 FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC2ERKS2_@@GLIBCXX_3.4
+FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC2ERKS2_mRKS1_@@GLIBCXX_3.4.23
 FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC2ERKS2_mm@@GLIBCXX_3.4
 FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC2ERKS2_mmRKS1_@@GLIBCXX_3.4
 
FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC2ESt16initializer_listIwERKS1_@@GLIBCXX_3.4.11
@@ -1580,6 +1583,7 @@ FUNC:_ZNSsC1EPKcRKSaIcE@@GLIBCXX_3.4
 FUNC:_ZNSsC1EPKcmRKSaIcE@@GLIBCXX_3.4
 FUNC:_ZNSsC1ERKSaIcE@@GLIBCXX_3.4
 FUNC:_ZNSsC1ERKSs@@GLIBCXX_3.4
+FUNC:_ZNSsC1ERKSsmRKSaIcE@@GLIBCXX_3.4.23
 FUNC:_ZNSsC1ERKSsmm@@GLIBCXX_3.4
 FUNC:_ZNSsC1ERKSsmmRKSaIcE@@GLIBCXX_3.4
 FUNC:_ZNSsC1ESt16initializer_listIcERKSaIcE@@GLIBCXX_3.4.11
@@ -1593,6 +1597,7 @@ FUNC:_ZNSsC2EPKcRKSaIcE@@GLIBCXX_3.4
 FUNC:_ZNSsC2EPKcmRKSaIcE@@GLIBCXX_3.4
 FUNC:_ZNSsC2ERKSaIcE@@GLIBCXX_3.4
 FUNC:_ZNSsC2ERKSs@@GLIBCXX_3.4
+FUNC:_ZNSsC2ERKSsmRKSaIcE@@GLIBCXX_3.4.23
 FUNC:_ZNSsC2ERKSsmm@@GLIBCXX_3.4
 FUNC:_ZNSsC2ERKSsmmRKSaIcE@@GLIBCXX_3.4
 FUNC:_ZNSsC2ESt16initializer_listIcERKSaIcE@@GLIBCXX_3.4.11
@@ -2232,6 +2237,7 @@ FUNC:_ZNSt15_List_node_base8transferEPS_S0_@@GLIBCXX_3.4
 FUNC:_ZNSt15_List_node_base9_M_unhookEv@@GLIBCXX_3.4.14
 FUNC:_ZNSt15__exception_ptr13exception_ptr4swapERS0_@@CXXABI_1.3.3
 FUNC:_ZNSt15__exception_ptr13exception_ptrC1EMS0_FvvE@@CXXABI_1.3.3
+FUNC:_ZNSt15__exception_ptr13exception_ptrC1EPv@@CXXABI_1.3.11
 FUNC:_ZNSt15__exception_ptr13exception_ptrC1ERKS0_@@CXXABI_1.3.3
 FUNC:_ZNSt15__exception_ptr13exception_ptrC1Ev@@CXXABI_1.3.3
 FUNC:_ZNSt15__exception_ptr13exception_ptrC2EMS0_FvvE@@CXXABI_1.3.3
@@ -2777,9 +2783,9 @@ 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_disposeEv@@GLIBCX
 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_replaceEmmPKcm@@GLIBCXX_3.4.21
 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_S_compareEmm@@GLIBCXX_3.4.21
 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE11_M_capacityEm@@GLIBCXX_3.4.21
-FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC1EPcOS3_@@GLIBCXX_3.4.21
+FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC1EPcOS3_@@GLIBCXX_3.4.23
 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC1EPcRKS3_@@GLIBCXX_3.4.21
-FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC2EPcOS3_@@GLIBCXX_3.4.21
+FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC2EPcOS3_@@GLIBCXX_3.4.23
 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC2EPcRKS3_@@GLIBCXX_3.4.21
 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructEmc@@GLIBCXX_3.4.21
 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructIN9__gnu_cxx17__normal_iteratorIPKcS4_vT_SB_St20forward_iterator_tag@@GLIBCXX_3.4.21
@@ -2878,6 +2884,7 @@ 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEC1EPKcmRKS3_@@GLIBCXX_
 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEC1ERKS3_@@GLIBCXX_3.4.21
 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEC1ERKS4_@@GLIBCXX_3.4.21
 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEC1ERKS4_RKS3_@@GLIBCXX_3.4.21

[C++ PATCH] Hidden name removal

[Nathan Sidwell]

Now that overloads are kept ordered, I can replace the existing 
remove_hidden_names fn with ovl_skip_hidden.


The former works by scanning the overloads, then if it discovers a 
hidden one, copying the list (from the beginning) omitting the hidden 
ones.  Now, overloads aren't usually huge, but this forces scanning on 
every lookup, and is O(N^2), so bad.  ovl_skip_hidden simply drops the 
OVL_HIDDEN_P nodes at the start of an overload.  Often doing nothing.


For extra badness, lookup_name_real was applying remove_hidden_names to 
a result that had already had it run!


Applied to trunk.

nathan
--
Nathan Sidwell
2017-05-24  Nathan Sidwell  

	* cp-tree.h (ovl_skip_hidden): Declare.
	* tree.c (ovl_skip_hidden): New.
	* name-lookup.c (arg_assoc_namespace): Call ovl_skip_hidden.
	(lookup_arg_dependent_1): Likewise.
	(ambiguous_decl): Use DECL_HIDDEN_P, ovl_skip_hidden.
	(hidden_name_p, remove_hidden_names): Delete.
	(lookup_name_real_1): Do not strip hidden names.
	* name-lookup.h (hidden_name_p, remove_hidden_names): Delete.

Index: cp/cp-tree.h
===
--- cp/cp-tree.h	(revision 248422)
+++ cp/cp-tree.h	(working copy)
@@ -6852,6 +6852,7 @@ extern tree ovl_make(tree fn,
 		 tree next = NULL_TREE);
 extern tree ovl_insert(tree fn, tree maybe_ovl,
 		 bool using_p = false);
+extern tree ovl_skip_hidden			(tree);
 extern tree lookup_add(tree fns, tree lookup);
 extern void lookup_keep(tree lookup, bool keep);
 extern int is_overloaded_fn			(tree);
Index: cp/name-lookup.c
===
--- cp/name-lookup.c	(revision 248422)
+++ cp/name-lookup.c	(working copy)
@@ -275,14 +275,10 @@ arg_assoc_namespace (struct arg_lookup *
   if (!value)
 return false;
 
+  value = ovl_skip_hidden (value);
+  
   for (; value; value = OVL_NEXT (value))
 {
-  /* We don't want to find arbitrary hidden functions via argument
-	 dependent lookup.  We only want to find friends of associated
-	 classes, which we'll do via arg_assoc_class.  */
-  if (hidden_name_p (OVL_CURRENT (value)))
-	continue;
-
   if (add_function (k, OVL_CURRENT (value)))
 	return true;
 }
@@ -630,7 +626,7 @@ lookup_arg_dependent_1 (tree name, tree
   /* Remove any hidden friend functions from the list of functions
  found so far.  They will be added back by arg_assoc_class as
  appropriate.  */
-  fns = remove_hidden_names (fns);
+  fns = ovl_skip_hidden (fns);
 
   k.name = name;
   k.args = args;
@@ -4347,7 +4343,7 @@ ambiguous_decl (struct scope_binding *ol
   /* Copy the type.  */
   type = new_binding->type;
   if (LOOKUP_NAMESPACES_ONLY (flags)
-  || (type && hidden_name_p (type) && !(flags & LOOKUP_HIDDEN)))
+  || (type && !(flags & LOOKUP_HIDDEN) && DECL_HIDDEN_P (type)))
 type = NULL_TREE;
 
   /* Copy the value.  */
@@ -4355,7 +4351,7 @@ ambiguous_decl (struct scope_binding *ol
   if (val)
 {
   if (!(flags & LOOKUP_HIDDEN))
-	val = remove_hidden_names (val);
+	val = ovl_skip_hidden (val);
   if (val)
 	switch (TREE_CODE (val))
 	  {
@@ -4465,59 +4461,6 @@ qualify_lookup (tree val, int flags)
   return true;
 }
 
-/* Given a lookup that returned VAL, decide if we want to ignore it or
-   not based on DECL_ANTICIPATED.  */
-
-bool
-hidden_name_p (tree val)
-{
-  if (DECL_P (val)
-  && DECL_LANG_SPECIFIC (val)
-  && TYPE_FUNCTION_OR_TEMPLATE_DECL_P (val)
-  && DECL_ANTICIPATED (val))
-return true;
-  if (TREE_CODE (val) == OVERLOAD)
-{
-  for (tree o = val; o; o = OVL_CHAIN (o))
-	if (!hidden_name_p (OVL_FUNCTION (o)))
-	  return false;
-  return true;
-}
-  return false;
-}
-
-/* Remove any hidden declarations from a possibly overloaded set
-   of functions.  */
-
-tree
-remove_hidden_names (tree fns)
-{
-  if (!fns)
-return fns;
-
-  if (DECL_P (fns) && hidden_name_p (fns))
-fns = NULL_TREE;
-  else if (TREE_CODE (fns) == OVERLOAD)
-{
-  tree o;
-
-  for (o = fns; o; o = OVL_NEXT (o))
-	if (hidden_name_p (OVL_CURRENT (o)))
-	  break;
-  if (o)
-	{
-	  tree n = NULL_TREE;
-
-	  for (o = fns; o; o = OVL_NEXT (o))
-	if (!hidden_name_p (OVL_CURRENT (o)))
-	  n = lookup_add (OVL_CURRENT (o), n);
-	  fns = n;
-	}
-}
-
-  return fns;
-}
-
 /* Suggest alternatives for NAME, an IDENTIFIER_NODE for which name
lookup failed.  Search through all available namespaces and print out
possible candidates.  If no exact matches are found, and
@@ -5337,10 +5280,6 @@ lookup_name_real_1 (tree name, int prefe
   if (!val)
 val = unqualified_namespace_lookup (name, flags);
 
-  /* Anticipated built-ins and friends aren't found by normal lookup.  */
-  if (val && !(flags & LOOKUP_HIDDEN))
-val = remove_hidden_names (val);
-
   /* If we have a single function from a using decl, pull it out.  */
   if (val && TREE_CODE (val) == OVERLOAD && !really_overloaded_fn (val))
 val = 

Re: SSA range class and removal of VR_ANTI_RANGEs

[Richard Biener]

On May 24, 2017 5:38:53 PM GMT+02:00, Andrew MacLeod  
wrote:
>On 05/24/2017 04:25 AM, Richard Biener wrote:
>> > What's this overflow flag for anyway?
>
>The new on-demand range calculators do operations on ranges, and that 
>flag is set when a range calculation may have overflowed... which is of
>
>use when issuing warnings or deciding to not use a range.
>ie given a made up example:
>
>signed char a,b;
>a_1 = b_3 +10;
>if (b_3 > 100)  foo (a_1)
>
>on the true side we know b_3 has the range [101,127].  It also 
>calculates the range of a_1 as [111, 127][-128,-119]  and sets the 
>overflow bit since the calculation of a_1 can overflow for some
>elements 
>of the range of b_3.Anyone wanting to use the range can check the 
>overflow if its something they care about.  The overflow stuff has not 
>been completely flushed out yet, but it is in place for the moment.  we
>
>can decide down the road if it serves enough purpose to stick around,
>or 
>needs expansion, or whatever.
>> > > That said, I think it's the wrong approach to start mucking with 
>SSA > name associated ranges given they are supposed to be a cheap 
>storage > variant of what VRP computes.  Start by making the VRP 
>machinery work > from on-demand-ranges.  I do have some prototypes from
>
>last year or > the year before to do this -- the helpers VRP machinery 
>is already > generic enough if you make use of VRPs range type.
>
>well its also no longer just contained to VRP. This work is all driven 
>by the desire of other optimizations to access range information.  Some
>
>have hacked their required bits into vrp, making vrp a sort of  mini 
>optimization phase, others have attempted to leverage assert_exprs at 
>their point in time (not too successfully I think?) , others just live 
>with the lack of contextual range info after VRP... after looking at
>it, 
>i decided trying to teach other optimizations about assert_expr in
>order 
>to make their info available later was not something that seemed like a
>
>good long term solution.
>
>The most pressing matter was the desire for CFG sensitive range 
>information outside of VRP.  Since assert_exprs are gone after VRP, we 
>loose the information on the branches of a diamond without a lot of 
>hackery.  

That's what my prototype does.  I'll dig it out and will send it after public 
holidays tomorrow.  I do not believe in duplicating all the range operations we 
have in VRP.

Richard.

The on-demand system is positioned to leave VRP as is for the
>
>moment, and allow passes outside of VRP to pick up the range info VRP 
>generated and refine that range based on branches.   Once this is 
>working well, I'd have the confidence to then maybe go into VRP and try
>
>to replace the assert_exprs with the on demand system. This allows the 
>proving ground to be outside of VRP for just the passes which are 
>desperate for better ranges.   This allows the on-demand system to be 
>tested, utilized, and various efficiencies explored without impacting 
>any optimizations negatively by trying to replace VRP up front and not 
>getting everything it does or consuming too much compilation time or 
>memory..
>
>I'll shortly prepare the writeup for the on demand mechanism.. I'm
>still 
>getting it working :-P
>> > >>>  More importantly, when the on-demand range work comes
>online 
>it  will end the proliferation of SSA_NAMES which carry ASSERT_EXPR
>
>  information.  We won't see the trail of new  ssa_names the  
>ASSET_EXPR chains create. I suspect that will eliminate storing  
>global ranges and bits for most SSA names, which is likely to  make
>
>this class a win regardless. >>> >>> Are you sure it is desirable to 
>recompute it in all cases, rather >>> than just use what you have 
>recorded and recompute what you don't >>> have computed yet? E.g. 
>various ranges come from if (cond) >>> __builtin_unreachable (); style 
>asserts, we do want to drop them >>> at some point and the only spot to
>
>keep that info afterwards is >>> SSA_NAME range info. >> >> >> I think 
>it will be desirable in most cases.  The on-demand system >> does *not*
>
>use assert_exprs.   It will make them mostly obsolete, >> and the goal 
>is to eventually eliminate them from the IL >> completely. > > They are
>
>not in the IL.  They are only temporarily there during VRP > (not early
>
>VRP for example) to make VRP work as a SSA propagation > pass.
>
>right but a number of other optimization want the contextual
>information 
>assert_expr's provide.. outside of VRP.  so either we have to keep the 
>multitude of ssa_names that asset_exprs create in order to maintain the
>
>range info, either via copies or maintaining the assert_expr, or we do 
>something else.
>
>>> Most assert_exprs exist to provide ranges on sub-branches of the  >>
>CFG.  These we are likely to be able to simply replace with the >> 
>on-demand mechanism.  I suspect we'll find some cases where we find >> 
>its more useful to have 

Re: C++ PATCH to -Wunused with C++17 structured bindings

[Jason Merrill]

On Wed, May 24, 2017 at 2:48 AM, Jakub Jelinek  wrote:
> On Tue, May 23, 2017 at 09:45:10PM -0400, Jason Merrill wrote:
>> Someone on IRC complained that there was no way to suppress -Wunused
>> on structured bindings.  It seemed to me that the way the feature
>> works, we shouldn't warn about the bindings individually; users need
>> to give each of the subobjects a name even if they're only interested
>> in using one of them.
>>
>> So this patch switches to tracking whether the underlying aggregate
>> object as a whole is used; using one of the bindings will avoid any
>> warning.
>>
>> This doesn't apply to tuple structured bindings, since in that case
>> the bindings are actual variables rather than aliases to subobjects.
>
> So, shall we have even for the tuple structured bindings somewhere (in
> lang_decl, such as adding struct lang_decl_decomp that would include
> lang_decl_min?) the tree for the underlying artificial var decl?

That would make sense.

Jason

Re: SSA range class and removal of VR_ANTI_RANGEs

[Andrew MacLeod]

stlll bounced.. html must have snuck in somewhere, and the mailer sent 
it anyway -P


trying again...

On 05/24/2017 11:38 AM, Andrew MacLeod wrote:

On 05/24/2017 04:25 AM, Richard Biener wrote:
>> What's this overflow flag for anyway?

The new on-demand range calculators do operations on ranges, and that 
flag is set when a range calculation may have overflowed... which is 
of use when issuing warnings or deciding to not use a range.

ie given a made up example:

signed char a,b;
a_1 = b_3 +10;
if (b_3 > 100)  foo (a_1)

on the true side we know b_3 has the range [101,127].  It also 
calculates the range of a_1 as [111, 127][-128,-119]  and sets the 
overflow bit since the calculation of a_1 can overflow for some 
elements of the range of b_3.Anyone wanting to use the range can 
check the overflow if its something they care about.  The overflow 
stuff has not been completely flushed out yet, but it is in place for 
the moment.  we can decide down the road if it serves enough purpose 
to stick around, or needs expansion, or whatever.
>> > That said, I think it's the wrong approach to start mucking with 
SSA > name associated ranges given they are supposed to be a cheap 
storage > variant of what VRP computes.  Start by making the VRP 
machinery work > from on-demand-ranges.  I do have some prototypes 
from last year or > the year before to do this -- the helpers VRP 
machinery is already > generic enough if you make use of VRPs range type.


well its also no longer just contained to VRP. This work is all driven 
by the desire of other optimizations to access range information.  
Some have hacked their required bits into vrp, making vrp a sort of  
mini optimization phase, others have attempted to leverage 
assert_exprs at their point in time (not too successfully I think?) , 
others just live with the lack of contextual range info after VRP... 
after looking at it, i decided trying to teach other optimizations 
about assert_expr in order to make their info available later was not 
something that seemed like a good long term solution.


The most pressing matter was the desire for CFG sensitive range 
information outside of VRP.  Since assert_exprs are gone after VRP, we 
loose the information on the branches of a diamond without a lot of 
hackery.  The on-demand system is positioned to leave VRP as is for 
the moment, and allow passes outside of VRP to pick up the range info 
VRP generated and refine that range based on branches.   Once this is 
working well, I'd have the confidence to then maybe go into VRP and 
try to replace the assert_exprs with the on demand system.  This 
allows the proving ground to be outside of VRP for just the passes 
which are desperate for better ranges.   This allows the on-demand 
system to be tested, utilized, and various efficiencies explored 
without impacting any optimizations negatively by trying to replace 
VRP up front and not getting everything it does or consuming too much 
compilation time or memory..


I'll shortly prepare the writeup for the on demand mechanism.. I'm 
still getting it working :-P
>> >>>  More importantly, when the on-demand range work comes 
online it  will end the proliferation of SSA_NAMES which carry 
ASSERT_EXPR  information.  We won't see the trail of new  
ssa_names the  ASSET_EXPR chains create. I suspect that will 
eliminate storing  global ranges and bits for most SSA names, 
which is likely to  make this class a win regardless. >>> >>> Are 
you sure it is desirable to recompute it in all cases, rather >>> than 
just use what you have recorded and recompute what you don't >>> have 
computed yet? E.g. various ranges come from if (cond) >>> 
__builtin_unreachable (); style asserts, we do want to drop them >>> 
at some point and the only spot to keep that info afterwards is >>> 
SSA_NAME range info. >> >> >> I think it will be desirable in most 
cases.  The on-demand system >> does *not* use assert_exprs.   It will 
make them mostly obsolete, >> and the goal is to eventually eliminate 
them from the IL >> completely. > > They are not in the IL.  They are 
only temporarily there during VRP > (not early VRP for example) to 
make VRP work as a SSA propagation > pass.


right but a number of other optimization want the contextual 
information assert_expr's provide.. outside of VRP.  so either we have 
to keep the multitude of ssa_names that asset_exprs create in order to 
maintain the range info, either via copies or maintaining the 
assert_expr, or we do something else.


>> Most assert_exprs exist to provide ranges on sub-branches of the >> CFG.  These we are likely to be able to simply replace with the >> 
on-demand mechanism.  I suspect we'll find some cases where we find >> 
its more useful to have a new global ssa_name which carries >> 
information,  but I expect the situation which requires that to be >> 
fairly rare. >> >> There will be a cycle where I have to identify 
cases we missing and >> catch those... 

Re: [PATCH, ARM/AArch64] drop aarch32 support for falkor/qdf24xx

[Jim Wilson]

On Wed, May 24, 2017 at 8:17 AM, Richard Earnshaw (lists)
 wrote:
> On 24/05/17 15:18, Jim Wilson wrote:
>> On Wed, May 24, 2017 at 6:56 AM, Richard Earnshaw (lists)
>>  wrote:
>>> OK.  does this need to go in the gcc-8 changes file?
>>
>> Falkor hasn't shipped yet.  I'm dropping features that only existed in
>> preproduction NDA hardware, so there isn't anything end user visible,
>> and hence I don't think that it needs to be in the release notes.
>>
>> Jim
>>
>
> Fair enough, so what about a minimal back-port to GCC-7 that just
> disables the CPU name for aarch32?

Not sure how to do that.  If I remove the arm-cpus.in entry, then 5
files get automatically regenerated.  That leaves us with a few minor
inconsistencies in specs handling and multilibs which are harmless but
we may as well fix anyways.  The only part of the patch that is
optional if the part which moves the qdf24xx_extra_costs array from
the arm dir to the aarch64 dir.  So the minimal patch ends up being
half the size of the original patch, changing 9 of the original 11
files, which isn't very minimal.

Another option might be to just remove the documentation and leave the
code in, i.e. only apply the doc/invoke.texi patch.  That would be a
small and safe patch.

Jim

Re: [patch, fortran] Handle MATMUL(TRANSPOSE(A),B) in inline matmul

[Jerry DeLisle]

On 05/17/2017 02:41 PM, Thomas Koenig wrote:
> Hello world,
> 
> after receiving no negative feedback on my RFC patch, I have deciced
> to submit the patch.
> 
> The attached patch handles MATMUL(TRANSPOSE(A),B) in inlining matmul.
> Speed is a bit faster than the library version.
> 
> Regression-tested.  OK for trunk?
> 

OK and thanks for patch.

Jerry

Re: [PATCH, ARM/AArch64] drop aarch32 support for falkor/qdf24xx

[Richard Earnshaw (lists)]

On 24/05/17 17:03, Jim Wilson wrote:
> On Wed, May 24, 2017 at 8:17 AM, Richard Earnshaw (lists)
>  wrote:
>> On 24/05/17 15:18, Jim Wilson wrote:
>>> On Wed, May 24, 2017 at 6:56 AM, Richard Earnshaw (lists)
>>>  wrote:
 OK.  does this need to go in the gcc-8 changes file?
>>>
>>> Falkor hasn't shipped yet.  I'm dropping features that only existed in
>>> preproduction NDA hardware, so there isn't anything end user visible,
>>> and hence I don't think that it needs to be in the release notes.
>>>
>>> Jim
>>>
>>
>> Fair enough, so what about a minimal back-port to GCC-7 that just
>> disables the CPU name for aarch32?
> 
> Not sure how to do that.  If I remove the arm-cpus.in entry, then 5
> files get automatically regenerated.  That leaves us with a few minor
> inconsistencies in specs handling and multilibs which are harmless but
> we may as well fix anyways.  The only part of the patch that is
> optional if the part which moves the qdf24xx_extra_costs array from
> the arm dir to the aarch64 dir.  So the minimal patch ends up being
> half the size of the original patch, changing 9 of the original 11
> files, which isn't very minimal.
> 
> Another option might be to just remove the documentation and leave the
> code in, i.e. only apply the doc/invoke.texi patch.  That would be a
> small and safe patch.
> 
> Jim
> 

Certainly we should remove it from the documentation.  That might be the
best idea.

I don't really regard the size of the changes to the auto-generated code
as being relevant - if we put the generated code directly in the build
directory and treated it like we do the output from gen*.c, then those
changes would never be even noticed.

R.

Re: [PATCH] add more detail to -Wconversion and -Woverflow (PR 80731)

[Joseph Myers]

On Wed, 17 May 2017, Martin Sebor wrote:

> @@ -1036,31 +1079,76 @@ warnings_for_convert_and_check (location_t loc, tree 
> type, tree expr,
> /* This detects cases like converting -129 or 256 to
>unsigned char.  */
> if (!int_fits_type_p (expr, c_common_signed_type (type)))
> - warning_at (loc, OPT_Woverflow,
> - "large integer implicitly truncated to unsigned type");
> + {
> +   if (cst)
> + warning_at (loc, OPT_Woverflow,
> + (TYPE_UNSIGNED (exprtype)
> +  ? "conversion from %qT to %qT "
> +  "changes value from %qE to %qE"
> +  : "unsigned conversion from %qT to %qT "
> +  "changes value from %qE to %qE"),
> + exprtype, type, expr, result);
> +   else
> + warning_at (loc, OPT_Woverflow,
> + (TYPE_UNSIGNED (exprtype)
> +  ? "conversion from %qT to %qT "
> +  "changes the value of %qE"
> +  : "unsigned conversion from %qT to %qT "
> +  "changes the value of %qE"),
> + exprtype, type, expr);
> + }

You need to use G_() around both arguments to ?:, otherwise only one will 
get extracted for translation.

> diff --git a/gcc/testsuite/c-c++-common/pr68657-1.c 
> b/gcc/testsuite/c-c++-common/pr68657-1.c
> index 84f3e54..33fdf86 100644
> --- a/gcc/testsuite/c-c++-common/pr68657-1.c
> +++ b/gcc/testsuite/c-c++-common/pr68657-1.c
> @@ -5,14 +5,14 @@
>  void
>  f1 (void)
>  {
> -  unsigned int a = -5;   /* { dg-error "negative integer implicitly 
> converted to unsigned type" } */
> +  unsigned int a = -5;   /* { dg-error "unsigned conversion from .int. 
> to .unsigned int. changes value from .-5. to .4294967291." } */

The more specific match would fail for targets with 16-bit int.  You need 
to keep it less specific in this test (if you want to test the more 
specific text as well, another test could be added for that, restricted to 
the int32 effective-target).

(The changes to Wconversion-real-integer-3.C and 
Wconversion-real-integer2.C are OK in that those tests are restricted to 
int32plus, although in theory 64-bit int would be an issue there.)

> +  /* According to 6.3.1.3 of C11:
> + -3-  Otherwise, the new type is signed and the value cannot be
> +  represented in it; either the result is implementation-defined
> +   or an implementation-defined signal is raised.
> +
> + In GCC such conversios wrap and diagnosed by mentioning "overflow"
> + if the absolut value of the operand is in excess of the maximum of
> + the destination of type, and "conversion" otherwise, as follows:  */

s/conversios/conversions/; s/absolut/absolute/

OK with those changes.

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

Re: MinGW compilation warnings in libiberty's waitpid.c

[Eli Zaretskii]

> From: DJ Delorie 
> Cc: gcc-patches@gcc.gnu.org, gdb-patc...@sourceware.org
> Date: Tue, 23 May 2017 22:26:22 -0400
> 
> > Is there anything else I need to do about this part to get it solved
> > in the upstream repository?
> 
> A ChangeLog entry would be nice, so I don't have to write one ;-)

Sure:

2017-05-24  Eli Zaretskii  

* libiberty/waitpid.c (wait) [__MINGW32__]: Define as a macro
that calls _cwait, so that this function works on MinGW.

Re: C++ PATCH to add __integer_pack built-in for std::make_integer_sequence (c++/80396)

[Jason Merrill]

On Wed, May 24, 2017 at 11:08 AM, Jakub Jelinek <ja...@redhat.com> wrote:
> On Wed, May 24, 2017 at 04:16:30PM +0200, Andreas Schwab wrote:
>> FAIL: g++.dg/ext/integer-pack2.C  -std=gnu++11 (test for excess errors)
>> Excess errors:
>> /daten/aranym/gcc/gcc-20170524/gcc/testsuite/g++.dg/ext/integer-pack2.C:10:48:
>>  error: overflow in constant expression [-fpermissive]
>> /daten/aranym/gcc/gcc-20170524/gcc/testsuite/g++.dg/ext/integer-pack2.C:10:48:
>>  error: overflow in constant expression [-fpermissive]
>
> To be precise, it fails only on 32-bit targets.

> If we at that point want some wider integer that when cast to int
> is 0 (or small enough positive number?), shall we use something like
> this, or say 1LL << (sizeof (int) * __CHAR_BIT__), or 2LL * INT_MIN,
> something else?

This is fine.

> Do we need to include ?  Or can we replace
> INT_MAX with __INT_MAX__?

__INT_MAX__ sounds good.

> Not sure about that -2147483650 for 16-bit int targets (perhaps the test can
> be guarded with int32 effective target).

Yes, restricting the test to int32 seems like the easiest fix.

Jason

Re: [PATCH] PR c++/80544 strip cv-quals from cast results

[Jason Merrill]

On Wed, May 24, 2017 at 10:20 AM, Jonathan Wakely  wrote:
> On 23/05/17 16:26 -0400, Jason Merrill wrote:
>>
>> On Tue, May 23, 2017 at 2:00 PM, Jonathan Wakely 
>> wrote:
>>>
>>> On 19/05/17 15:14 -0400, Jason Merrill wrote:


 On Thu, Apr 27, 2017 at 12:59 PM, Jonathan Wakely 
 wrote:
>
>
> I also tried to add a warning like EDG's (see the PR) but it gave a
> false positive for direct-list-init of scoped enums (P0138R2, r240449)
> because that code goes through build_c_cast to perform the conversion,
> so looks like a cast to my new warning.



 The enum init code could strip the cv-quals when calling build_c_cast
 to avoid the warning.
>>>
>>>
>>>
>>> Thanks, that works. I don't think this warning fits under any existing
>>> option, so I'll add a new one. -Wuseless-cast-qual maybe? Or is that
>>> too close to -Wuseless-cast and -Wcast-qual and would cause confusion?
>>
>>
>> -Wcast-rvalue-qual ?
>
>
> I realised that -Wignored-qualifiers is a good fit. That warns about
> ignored cv-qualifiers on return types, which is a very similar case.
>
> This patch adds a new function to conditionally warn and calls that
> from the build_*_cast functions after they produce a valid result. I
> originally put the warnings next to the cv_unqualified calls that
> strip the quals, but was getting duplicate warnings when build_cp_cast
> calls more than one of the build_*_cast_1 functions.
>
> This also removes the unnecessary check for reference types that
> Nathan pointed out.
>
> Tested x86_64-linux and powerpc64-linux. OK for trunk?

> +/*
> +  Warns if the cast ignores cv-qualifiers on TYPE.
> + */

The GCC sources don't put /* and */ on their own line.  OK with that
change, thanks!

Jason

Re: [patch, fortran] Handle MATMUL(TRANSPOSE(A),B) in inline matmul

[Thomas Koenig]

Hi Jerry,

On 05/17/2017 02:41 PM, Thomas Koenig wrote:

Hello world,

after receiving no negative feedback on my RFC patch, I have deciced
to submit the patch.

The attached patch handles MATMUL(TRANSPOSE(A),B) in inlining matmul.
Speed is a bit faster than the library version.

Regression-tested.  OK for trunk?



OK and thanks for patch.


Committed as rev.  248425.

Thanks for the review!

I am going to close PR 66094 now.  Any other cases
would be silly.  With a vector v and a matrix a,

matmul(transpose(a),v) can be replaced by matmul(v,a)
matmul(v,transpose(a)) can be replaced by matmul(a,v)

And as for matmul(transpose(a), transpose(b)), well...

Regards

Thomas

Re: C++ PATCH to add __integer_pack built-in for std::make_integer_sequence (c++/80396)

[Jakub Jelinek]

On Wed, May 24, 2017 at 02:47:08PM -0400, Jason Merrill wrote:
> On Wed, May 24, 2017 at 11:08 AM, Jakub Jelinek <ja...@redhat.com> wrote:
> > On Wed, May 24, 2017 at 04:16:30PM +0200, Andreas Schwab wrote:
> >> FAIL: g++.dg/ext/integer-pack2.C  -std=gnu++11 (test for excess errors)
> >> Excess errors:
> >> /daten/aranym/gcc/gcc-20170524/gcc/testsuite/g++.dg/ext/integer-pack2.C:10:48:
> >>  error: overflow in constant expression [-fpermissive]
> >> /daten/aranym/gcc/gcc-20170524/gcc/testsuite/g++.dg/ext/integer-pack2.C:10:48:
> >>  error: overflow in constant expression [-fpermissive]
> >
> > To be precise, it fails only on 32-bit targets.
> 
> > If we at that point want some wider integer that when cast to int
> > is 0 (or small enough positive number?), shall we use something like
> > this, or say 1LL << (sizeof (int) * __CHAR_BIT__), or 2LL * INT_MIN,
> > something else?
> 
> This is fine.
> 
> > Do we need to include ?  Or can we replace
> > INT_MAX with __INT_MAX__?
> 
> __INT_MAX__ sounds good.
> 
> > Not sure about that -2147483650 for 16-bit int targets (perhaps the test can
> > be guarded with int32 effective target).
> 
> Yes, restricting the test to int32 seems like the easiest fix.

Ok, I've committed this (also add something to avoid failing on hypothetical
64-bit int 64-bit long long target).  Tested for both -m32 and -m64 on
x86_64-linux.

2017-05-24  Jakub Jelinek  <ja...@redhat.com>

* g++.dg/ext/integer-pack2.C: Require int32 effective target.
Don't include limits.h.
(w): Conditionalize on long long wider than int.  Use
1LL << (__SIZEOF_INT__ * __CHAR_BIT__) instead of
-9223372036854775808.
(x): Use __INT_MAX__ instead of INT_MAX.

--- gcc/testsuite/g++.dg/ext/integer-pack2.C.jj 2017-05-24 11:59:01.0 
+0200
+++ gcc/testsuite/g++.dg/ext/integer-pack2.C2017-05-24 21:07:02.0 
+0200
@@ -1,12 +1,12 @@
-// { dg-do compile { target c++11 } }
+// { dg-do compile { target { c++11 && int32 } } }
 // { dg-options -w }
 
-#include 
-
 template struct integer_sequence { };
 template
  using make_integer_sequence = integer_sequence<T, __integer_pack(num)...>; // 
{ dg-error "argument" }
 
-make_integer_sequence<int, -9223372036854775808> w;
-make_integer_sequence<int, INT_MAX> x;// { dg-message "required" }
+#if __SIZEOF_LONG_LONG__ > __SIZEOF_INT__
+make_integer_sequence<int, 1LL << (__SIZEOF_INT__ * __CHAR_BIT__)> w;
+#endif
+make_integer_sequence<int, __INT_MAX__> x; // { dg-message "required" }
 make_integer_sequence<int, -2147483650> y; // { dg-message "required" }


Jakub

Re: [PATCH] Try harder to fix recently introduced crashes in ggc_collect

[Nathan Sidwell]

On 05/24/2017 03:02 PM, Jason Merrill wrote:


I think it would be premature to remove PCH from GCC 8.  The Modules
specification is far from stable, and moving current PCH users to
Modules will take significant work (at least if we get something like
the current draft rather than the relatively transparent scheme that
clang uses).


I agree.  Although I now have function decls and inline function bodies 
working.  Everything else is missing, and I know I'm not handling some 
things 'correctly'.


nathan
--
Nathan Sidwell

Re: [PATCH 0/3] Split off powerpcspe from rs6000 port

[Segher Boessenkool]

On Thu, May 18, 2017 at 11:30:11AM -0500, Segher Boessenkool wrote:
> On Mon, May 15, 2017 at 08:51:49PM +, Segher Boessenkool wrote:
> > As discussed before, here is a series to split powerpcspe from the
> > rs6000 port.  This series does not yet make any real changes to either
> > port: it is a copy of rs6000/ to powerpcspe/, with some renames and
> > some necessary changes to the port file, and slightly more involved
> > changes to config.gcc .
> > 
> > This was tested on powerpc64-linux {-m32,-m64}, and it was build-tested
> > on powerpc-linux-gnuspe (and the resulting compiler was tested to be
> > functional: it can build various Linux defconfigs for SPE systems).
> 
> I am planning to commit this on monday, if I don't hear anything.

Done now, with the following changelog:


2017-05-24  Segher Boessenkool  

* config/powerpcspe: New port.  Files are copied from the rs6000
port, with "rs6000" in filenames replaced by "powerpcspe".

* config.gcc (powerpc*-*-*spe*): New.
(powerpc-*-eabispe*): Use ${cpu_type} instead of hardcoded pathnames.
(powerpc-*-rtems*spe*): New.
(powerpc*-*-linux*spe*): New.
(powerpc-wrs-vxworksspe): New.
(powerpc*-*-*, rs6000-*-*): Use ${cpu_type}.
(misc flags) [powerpc*-*-*, rs6000-*-*): Use ${cpu_type}.
* config.host (powerpc*-*-*spe*): New.

Re: [PATCH] Try harder to fix recently introduced crashes in ggc_collect

[Jason Merrill]

On Wed, May 24, 2017 at 7:04 AM, Trevor Saunders  wrote:
> On Fri, May 19, 2017 at 10:10:23AM -0400, Nathan Sidwell wrote:
>> On 05/19/2017 10:05 AM, Bernd Edlinger wrote:
>>
>> > hwi cannot be the root cause of the problem,
>> > because it can only be long_integer_type_node
>> > or long_long_integer_type_node, otherwise
>> > an error would be triggered.
>>
>> that's the error I made with the static fns.  PCH moves things around, so
>> anything that can be streamed via PCH must be GTY marked.  Also, I'm not
>> sure if the current GC is a compacting GC (given PCH can compact things?)
>
> other than pch which I'm not sure about I'm pretty sure its not, and is
> just basic mark and sweep.
>
> That said if modules can get merged for gcc 8 I'm very tempted to rm pch
> now.

I think it would be premature to remove PCH from GCC 8.  The Modules
specification is far from stable, and moving current PCH users to
Modules will take significant work (at least if we get something like
the current draft rather than the relatively transparent scheme that
clang uses).

Jason

Re: [PATCH] PR c++/80544 strip cv-quals from cast results

[Jonathan Wakely]

On 24/05/17 14:50 -0400, Jason Merrill wrote:

On Wed, May 24, 2017 at 10:20 AM, Jonathan Wakely  wrote:

On 23/05/17 16:26 -0400, Jason Merrill wrote:


On Tue, May 23, 2017 at 2:00 PM, Jonathan Wakely 
wrote:


On 19/05/17 15:14 -0400, Jason Merrill wrote:



On Thu, Apr 27, 2017 at 12:59 PM, Jonathan Wakely 
wrote:



I also tried to add a warning like EDG's (see the PR) but it gave a
false positive for direct-list-init of scoped enums (P0138R2, r240449)
because that code goes through build_c_cast to perform the conversion,
so looks like a cast to my new warning.




The enum init code could strip the cv-quals when calling build_c_cast
to avoid the warning.




Thanks, that works. I don't think this warning fits under any existing
option, so I'll add a new one. -Wuseless-cast-qual maybe? Or is that
too close to -Wuseless-cast and -Wcast-qual and would cause confusion?



-Wcast-rvalue-qual ?



I realised that -Wignored-qualifiers is a good fit. That warns about
ignored cv-qualifiers on return types, which is a very similar case.

This patch adds a new function to conditionally warn and calls that
from the build_*_cast functions after they produce a valid result. I
originally put the warnings next to the cv_unqualified calls that
strip the quals, but was getting duplicate warnings when build_cp_cast
calls more than one of the build_*_cast_1 functions.

This also removes the unnecessary check for reference types that
Nathan pointed out.

Tested x86_64-linux and powerpc64-linux. OK for trunk?



+/*
+  Warns if the cast ignores cv-qualifiers on TYPE.
+ */


The GCC sources don't put /* and */ on their own line.  OK with that
change, thanks!


OK, I'll also fix it on the maybe_warn_about_useless_cast function
just above, which I copied :-)


diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c
index ecc7190..b81d6c8 100644
--- a/gcc/cp/typeck.c
+++ b/gcc/cp/typeck.c
@@ -6655,9 +6655,7 @@ check_for_casting_away_constness (tree src_type, tree dest_type,
 }
 }
 
-/*
-  Warns if the cast from expression EXPR to type TYPE is useless.
- */
+/* Warns if the cast from expression EXPR to type TYPE is useless.  */
 void
 maybe_warn_about_useless_cast (tree type, tree expr, tsubst_flags_t complain)
 {
@@ -6673,9 +6671,7 @@ maybe_warn_about_useless_cast (tree type, tree expr, tsubst_flags_t complain)
 }
 }
 
-/*
-  Warns if the cast ignores cv-qualifiers on TYPE.
- */
+/* Warns if the cast ignores cv-qualifiers on TYPE.  */
 void
 maybe_warn_about_cast_ignoring_quals (tree type, tsubst_flags_t complain)
 {

Re: [config PATCH] --enable-languages

[Martin Sebor]

On 05/19/2017 10:59 AM, Nathan Sidwell wrote:

--enable-languages=all confused me, because as RichardB said, 'it really
means default'.  So this patch does 2 things
1) allow --enable-languages=default to mean what =all does now.
2) change =all to mean all available languages.
2.1) jit is included in =all if -enable-host-shared is given.  If you
don't you get a warning that JIT's not included.

If you're used to saying =all, then you'll get more languages with this
patch than you used to.

ok?


FWIW, it took me a few broken bootstraps before I remembered that
all didn't actually mean all but just some.  I've since trained
myself to spell out all the languages explicitly (in addition to
typing all just to be safe) but I'm happy to see that I wasn't
the only one shaking his head at the confusing misnomer.  Thanks
for fixing it!

Martin

[patch, fortran, committed] replace stdout with dumpfile in a few places

[Thomas Koenig]

Hello world,

I just committed the attached patch as obvious.

Regards

Thomas

2017-05-24  Thomas Koenig  

* dump-parse-tree.c (show_expr):  Replace stdout
with dumpfile for showing values.

Index: dump-parse-tree.c
===
--- dump-parse-tree.c	(Revision 247809)
+++ dump-parse-tree.c	(Arbeitskopie)
@@ -422,7 +422,7 @@ show_expr (gfc_expr *p)
   switch (p->ts.type)
 	{
 	case BT_INTEGER:
-	  mpz_out_str (stdout, 10, p->value.integer);
+	  mpz_out_str (dumpfile, 10, p->value.integer);
 
 	  if (p->ts.kind != gfc_default_integer_kind)
 	fprintf (dumpfile, "_%d", p->ts.kind);
@@ -436,7 +436,7 @@ show_expr (gfc_expr *p)
 	  break;
 
 	case BT_REAL:
-	  mpfr_out_str (stdout, 10, 0, p->value.real, GFC_RND_MODE);
+	  mpfr_out_str (dumpfile, 10, 0, p->value.real, GFC_RND_MODE);
 	  if (p->ts.kind != gfc_default_real_kind)
 	fprintf (dumpfile, "_%d", p->ts.kind);
 	  break;
@@ -449,7 +449,7 @@ show_expr (gfc_expr *p)
 	case BT_COMPLEX:
 	  fputs ("(complex ", dumpfile);
 
-	  mpfr_out_str (stdout, 10, 0, mpc_realref (p->value.complex),
+	  mpfr_out_str (dumpfile, 10, 0, mpc_realref (p->value.complex),
 			GFC_RND_MODE);
 	  if (p->ts.kind != gfc_default_complex_kind)
 	fprintf (dumpfile, "_%d", p->ts.kind);

Re: [patch] build xz (instead of bz2) compressed tarballs and diffs

[Gerald Pfeifer]

On Tue, 23 May 2017, Matthias Klose wrote:
> Looks like the copy of the script on gcc.gnu.org affects all active branches.

Yeah, I just run into this myself (and scratched my had until I
debugged this, admittedly quickly).

> the May 23 GCC 5 snapshot was created successfully.  Is this acceptable? 

Well, I guess it's a done deed.  Probably a good idea to send a note
to g...@gcc.gnu.org at least; I added the one below to our main page.

Gerald

Index: index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
retrieving revision 1.1053
diff -u -r1.1053 index.html
--- index.html  9 May 2017 07:20:38 -   1.1053
+++ index.html  24 May 2017 19:08:02 -
@@ -46,6 +46,10 @@
 News
 
 
+Weekly snapshots now use xz compression
+[2017-05-24]
+...instead of bzip2.
+
 GCC 7.1 released
 [2017-05-02]
 

Re: [PATCH] PR c++/77306 - Unable to specify visibility for explicit template instantiations

[Jason Merrill]

On Sat, Apr 22, 2017 at 4:46 PM, James Abbatiello  wrote:
> PR c++/77306
> * attribs.c (decl_attributes): Allow visibility attributes on explicit
> template instantiations.
> * gcc-family/c-attribs.c (handle_visibility_attribute): Likewise.

This doesn't seem sufficient; any members that have already been
instantiated will still have the default visibility.  If you want to
go this way, you'll need to call reset_type_linkage when changing the
visibility of a type that's already defined.

Is there a reason you can't declare the visibility before the first
use of A, e.g.

  extern template struct __attribute ((visibility("hidden"))) A;

followed later by

  template class A;

?

Jason

Re: [PATCH v2] Implement non-trivial std::random_device::entropy (PR libstdc++/67578)

[Jonathan Wakely]

On 23/05/17 17:15 +0100, Jonathan Wakely wrote:

On 22/05/17 22:28 +0800, Xi Ruoyao wrote:

The new patch is attached.  Just merged the patches you sent and fixed
the ChangeLog of gnu.ver and testsuite_abi.cc.

(For fun:  I had mistakenly attached the Vim .swp file of the patch
and almost sent it. :-p)


Ha, that *definitely* wouldnt' have applied, but I think I'd have
noticed the reason sooner ;-)

I've committed the patch now - thanks.



@@ -334,6 +335,7 @@ compatible.
   GCC 5.1.0: GLIBCXX_3.4.21, CXXABI_1.3.9
   GCC 6.1.0: GLIBCXX_3.4.22, CXXABI_1.3.10
   GCC 7.1.0: GLIBCXX_3.4.23, CXXABI_1.3.11
+GCC 8.0.0: GLIBCXX_3.4.24, CXXABI_1.3.10


Oops, this should have been CXXABI_1.3.11, I fixed that before
committing it.


+if (static_cast(ent) > sizeof(result_type) * 8)
+  return static_cast(sizeof(result_type) * 8);


After committing it I realised this should use __CHAR_BIT__ instead of
hardcoding 8, which I'll fix shortly.


Fixed with this patch. Tested powerpc64le-linux, committed to trunk.

commit 26e91f1858aa054c28b521d86065966df4ba7099
Author: Jonathan Wakely 
Date:   Wed May 24 17:41:34 2017 +0100

Use CHAR_BIT instead of assuming 8 bits

	* src/c++11/random.cc (random_device::_M_getentropy): Use __CHAR_BIT__
	instead of fixed number of bits.

diff --git a/libstdc++-v3/src/c++11/random.cc b/libstdc++-v3/src/c++11/random.cc
index 5011cf2..ef17223 100644
--- a/libstdc++-v3/src/c++11/random.cc
+++ b/libstdc++-v3/src/c++11/random.cc
@@ -187,8 +187,9 @@ namespace std _GLIBCXX_VISIBILITY(default)
 if (ent < 0)
   return 0.0;
 
-if (static_cast(ent) > sizeof(result_type) * 8)
-  return static_cast(sizeof(result_type) * 8);
+const int max = sizeof(result_type) * __CHAR_BIT__;
+if (ent > max)
+  ent = max;
 
 return static_cast(ent);
 #else

Re: [libibery PATCH] Fix bootstrap

[Nathan Sidwell]

On 05/24/2017 09:13 PM, Nathan Sidwell wrote:

On 05/24/2017 08:56 PM, Nathan Sidwell wrote:

On 05/24/2017 08:34 PM, Nathan Sidwell wrote:

We now warn on casts to T const.  Applied as obvious to fix bootstrap.


And this fixes c-common.c


And fix auto-profile.c


and lto-streamer-out.c, sigh

--
Nathan Sidwell
2017-05-24  Nathan Sidwell  

	* lto-streamer-in.c (lto_input_data_block): Adjust T const cast to
	avoid warning. 

Index: lto-streamer-in.c
===
--- lto-streamer-in.c	(revision 248441)
+++ lto-streamer-in.c	(working copy)
@@ -86,7 +86,7 @@ void
 lto_input_data_block (struct lto_input_block *ib, void *addr, size_t length)
 {
   size_t i;
-  unsigned char *const buffer = (unsigned char *const) addr;
+  unsigned char *const buffer = (unsigned char *) addr;
 
   for (i = 0; i < length; i++)
 buffer[i] = streamer_read_uchar (ib);

[PATCH rs6000] Addition fixes to BMI intrinsic test

[Steven Munroe]

Bill Seurer pointed out that building the BMI tests on a power8 but with
gcc built --with-cpu=power6 fails with link errors. The intrinsics
_pdep_u64/32 and _pext_u64/32 are guarded with #ifdef _ARCH_PWR7 as the
implementation uses bpermd and popcntd instructions introduced with
power7 (PowerISA-2.06).

But if the GCC is built --with-cpu=power6, the compiler is capable of
supporting -mcpu=power7 but will not generate bpermd/popcntd by default.
Then if some code them uses say _pext_u64 with -mcpu=power6 the
intrinsic is not not supported (needs power7) and so not defined. 

The dg tests are guarded with dg-require-effective-target
powerpc_vsx_ok, This only tests if GCC and Binutils are capable of
generating vsx (and by extension PowerISA-2.06 bpermd and popcntd)
instructions.

In this case the result is the intrinsic functions are implicitly
defined as extern and cause a link failure. The solution is to guard the
test code with #ifdef _ARCH_PWR7 so that it does not attempt to use
instructions that are not there.

However for dg-compile test bmi2-pext64-1a.c we have no alternative to
add -mcpu=power7 to dg-options.


[gcc/testsuite]

2017-05-24  Steven Munroe  

* gcc.target/powerpc/bmi2-pdep32-1.c [_ARCH_PWR7]: Prevent
implicit function for processors without bpermd instruction.
* gcc.target/powerpc/bmi2-pdep64-1.c: Likewise.
* gcc.target/powerpc/bmi2-pext32-1.c: Likewise.
* gcc.target/powerpc/bmi2-pext64-1.c: Likewise.
* gcc.target/powerpc/bmi2-pext64-1a.c: Add -mcpu=power7
to dg-option.

Index: gcc/testsuite/gcc.target/powerpc/bmi2-pdep64-1.c
===
--- gcc/testsuite/gcc.target/powerpc/bmi2-pdep64-1.c(revision 248381)
+++ gcc/testsuite/gcc.target/powerpc/bmi2-pdep64-1.c(working copy)
@@ -7,6 +7,7 @@
 #include 
 #include "bmi2-check.h"
 
+#ifdef  _ARCH_PWR7
 __attribute__((noinline))
 unsigned long long
 calc_pdep_u64 (unsigned long long a, unsigned long long mask)
@@ -21,11 +22,13 @@ calc_pdep_u64 (unsigned long long a, unsigned long
 }
   return res;
 }
+#endif /* _ARCH_PWR7 */
 
 static
 void
 bmi2_test ()
 {
+#ifdef  _ARCH_PWR7
   unsigned long long i;
   unsigned long long src = 0xce7acce7acce7ac;
   unsigned long long res, res_ref;
@@ -39,4 +42,5 @@ bmi2_test ()
 if (res != res_ref)
   abort ();
   }
+#endif /* _ARCH_PWR7 */
 }
Index: gcc/testsuite/gcc.target/powerpc/bmi2-pext64-1.c
===
--- gcc/testsuite/gcc.target/powerpc/bmi2-pext64-1.c(revision 248381)
+++ gcc/testsuite/gcc.target/powerpc/bmi2-pext64-1.c(working copy)
@@ -7,6 +7,7 @@
 #include 
 #include "bmi2-check.h"
 
+#ifdef  _ARCH_PWR7
 __attribute__((noinline))
 unsigned long long
 calc_pext_u64 (unsigned long long a, unsigned long long mask)
@@ -22,10 +23,12 @@ calc_pext_u64 (unsigned long long a, unsigned long
 
   return res;
 }
+#endif /* _ARCH_PWR7 */
 
 static void
 bmi2_test ()
 {
+#ifdef  _ARCH_PWR7
   unsigned long long i;
   unsigned long long src = 0xce7acce7acce7ac;
   unsigned long long res, res_ref;
@@ -39,4 +42,5 @@ bmi2_test ()
 if (res != res_ref)
   abort();
   }
+#endif /* _ARCH_PWR7 */
 }
Index: gcc/testsuite/gcc.target/powerpc/bmi2-pdep32-1.c
===
--- gcc/testsuite/gcc.target/powerpc/bmi2-pdep32-1.c(revision 248381)
+++ gcc/testsuite/gcc.target/powerpc/bmi2-pdep32-1.c(working copy)
@@ -7,6 +7,7 @@
 #include 
 #include "bmi2-check.h"
 
+#ifdef  _ARCH_PWR7
 __attribute__((noinline))
 unsigned
 calc_pdep_u32 (unsigned a, int mask)
@@ -22,10 +23,12 @@ calc_pdep_u32 (unsigned a, int mask)
 
   return res;
 }
+#endif /* _ARCH_PWR7 */
 
 static void
 bmi2_test ()
 {
+#ifdef  _ARCH_PWR7
   unsigned i;
   unsigned src = 0xce7acc;
   unsigned res, res_ref;
@@ -39,4 +42,5 @@ bmi2_test ()
 if (res != res_ref)
   abort();
   }
+#endif /* _ARCH_PWR7 */
 }
Index: gcc/testsuite/gcc.target/powerpc/bmi2-pext64-1a.c
===
--- gcc/testsuite/gcc.target/powerpc/bmi2-pext64-1a.c   (revision 248381)
+++ gcc/testsuite/gcc.target/powerpc/bmi2-pext64-1a.c   (working copy)
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O3" } */
+/* { dg-options "-O3 -mcpu=power7" } */
 /* { dg-require-effective-target lp64 } */
 /* { dg-require-effective-target powerpc_vsx_ok } */
 
Index: gcc/testsuite/gcc.target/powerpc/bmi2-pext32-1.c
===
--- gcc/testsuite/gcc.target/powerpc/bmi2-pext32-1.c(revision 248381)
+++ gcc/testsuite/gcc.target/powerpc/bmi2-pext32-1.c(working copy)
@@ -7,6 +7,7 @@
 #include 
 #include "bmi2-check.h"
 
+#ifdef  _ARCH_PWR7
 __attribute__((noinline))
 unsigned
 calc_pext_u32 (unsigned a, unsigned mask)
@@ -22,10 +23,12 @@ calc_pext_u32 (unsigned a, unsigned mask)
 
   return res;
 }

[C++ PATCH] Sort Make-lang.in

[Nathan Sidwell]

Make-lang.in has a list ripe for sorting.  So sorted.

nathan
--
Nathan Sidwell
2017-05-24  Nathan Sidwell  

	* Make-lang.in (CXX_AND_OBJCXX_OBJS): Alphabetize.

Index: Make-lang.in
===
--- Make-lang.in	(revision 248432)
+++ Make-lang.in	(working copy)
@@ -71,15 +71,22 @@ CXX_C_OBJS = attribs.o incpath.o \
 	$(C_COMMON_OBJS) $(CXX_TARGET_OBJS)
 
 # Language-specific object files for C++ and Objective C++.
-CXX_AND_OBJCXX_OBJS = cp/call.o cp/decl.o cp/expr.o cp/pt.o cp/typeck2.o \
- cp/class.o cp/decl2.o cp/error.o cp/lex.o cp/parser.o cp/ptree.o cp/rtti.o \
- cp/typeck.o cp/cvt.o cp/except.o cp/friend.o cp/init.o cp/method.o \
- cp/search.o cp/semantics.o cp/tree.o cp/repo.o cp/dump.o cp/optimize.o \
- cp/mangle.o cp/cp-objcp-common.o cp/name-lookup.o cp/cxx-pretty-print.o \
- cp/cp-cilkplus.o \
- cp/cp-gimplify.o cp/cp-array-notation.o cp/lambda.o \
- cp/vtable-class-hierarchy.o cp/constexpr.o cp/cp-ubsan.o \
- cp/constraint.o cp/logic.o $(CXX_C_OBJS)
+CXX_AND_OBJCXX_OBJS = \
+	cp/call.o cp/class.o cp/constexpr.o cp/constraint.o \
+	cp/cp-array-notation.o cp/cp-cilkplus.o cp/cp-gimplify.o \
+	cp/cp-objcp-common.o cp/cp-ubsan.o \
+	cp/cvt.o cp/cxx-pretty-print.o \
+	cp/decl.o cp/decl2.o cp/dump.o \
+	cp/error.o cp/except.o cp/expr.o \
+	cp/friend.o cp/init.o \
+	cp/lambda.o cp/lex.o cp/logic.o \
+	cp/mangle.o cp/method.o \
+	cp/name-lookup.o cp/optimize.o \
+	cp/parser.o cp/pt.o cp/ptree.o \
+	cp/repo.o cp/rtti.o \
+	cp/search.o cp/semantics.o \
+	cp/tree.o cp/typeck.o cp/typeck2.o \
+	cp/vtable-class-hierarchy.o $(CXX_C_OBJS)
 
 ifeq ($(if $(wildcard ../stage_current),$(shell cat \
   ../stage_current)),stageautofeedback)

Re: [PATCH] PR c++/80544 strip cv-quals from cast results

[Andrew Pinski]

On Wed, May 24, 2017 at 8:07 PM, Andrew Pinski  wrote:
> On Wed, May 24, 2017 at 12:29 PM, Jonathan Wakely  wrote:
>> On 24/05/17 14:50 -0400, Jason Merrill wrote:
>>>
>>> On Wed, May 24, 2017 at 10:20 AM, Jonathan Wakely 
>>> wrote:

 On 23/05/17 16:26 -0400, Jason Merrill wrote:
>
>
> On Tue, May 23, 2017 at 2:00 PM, Jonathan Wakely 
> wrote:
>>
>>
>> On 19/05/17 15:14 -0400, Jason Merrill wrote:
>>>
>>>
>>>
>>> On Thu, Apr 27, 2017 at 12:59 PM, Jonathan Wakely 
>>> wrote:



 I also tried to add a warning like EDG's (see the PR) but it gave a
 false positive for direct-list-init of scoped enums (P0138R2,
 r240449)
 because that code goes through build_c_cast to perform the
 conversion,
 so looks like a cast to my new warning.
>>>
>>>
>>>
>>>
>>> The enum init code could strip the cv-quals when calling build_c_cast
>>> to avoid the warning.
>>
>>
>>
>>
>> Thanks, that works. I don't think this warning fits under any existing
>> option, so I'll add a new one. -Wuseless-cast-qual maybe? Or is that
>> too close to -Wuseless-cast and -Wcast-qual and would cause confusion?
>
>
>
> -Wcast-rvalue-qual ?



 I realised that -Wignored-qualifiers is a good fit. That warns about
 ignored cv-qualifiers on return types, which is a very similar case.

 This patch adds a new function to conditionally warn and calls that
 from the build_*_cast functions after they produce a valid result. I
 originally put the warnings next to the cv_unqualified calls that
 strip the quals, but was getting duplicate warnings when build_cp_cast
 calls more than one of the build_*_cast_1 functions.

 This also removes the unnecessary check for reference types that
 Nathan pointed out.

 Tested x86_64-linux and powerpc64-linux. OK for trunk?
>>>
>>>
 +/*
 +  Warns if the cast ignores cv-qualifiers on TYPE.
 + */
>>>
>>>
>>> The GCC sources don't put /* and */ on their own line.  OK with that
>>> change, thanks!
>>
>>
>> OK, I'll also fix it on the maybe_warn_about_useless_cast function
>> just above, which I copied :-)
>
> This change caused a bootstrap failure on aarch64-linux-gnu and
> x86_64-linux-gnu:
> In file included from ../../gcc/gcc/system.h:691:0,
>  from ../../gcc/gcc/read-rtl.c:31:
> ../../gcc/gcc/read-rtl.c: In member function ‘const char*
> md_reader::apply_iterator_to_string(const char*)’:
> ../../gcc/gcc/../include/libiberty.h:722:38: error: type qualifiers
> ignored on cast result type [-Werror=ignored-qualifiers]
>  # define alloca(x) __builtin_alloca(x)
>   ^
> ../../gcc/gcc/../include/libiberty.h:727:47: note: in expansion of
> macro ‘alloca’
> char *const libiberty_nptr = (char *const) alloca (libiberty_len); \
>^~
> ../../gcc/gcc/read-rtl.c:380:21: note: in expansion of macro ‘ASTRDUP’
>base = p = copy = ASTRDUP (string);
>  ^~~
>
> I know you did not touch libiberty.h but that is emitting an error.
> Did you test your patch with a full bootstrap?  I thought that was
> recorded as being required now for C++ patches; I know a few years
> back when the GCC was not compiling as C++, it was not required.

Oh it looks like it was already fixed by revision 248442.  Just my
build automated build was not done for that timeframe.

Thanks,
Andrew

>
> Thanks,
> Andrew
>
>
>>
>>

Re: [libibery PATCH] Fix bootstrap

[Nathan Sidwell]

On 05/24/2017 08:56 PM, Nathan Sidwell wrote:

On 05/24/2017 08:34 PM, Nathan Sidwell wrote:

We now warn on casts to T const.  Applied as obvious to fix bootstrap.


And this fixes c-common.c


And fix auto-profile.c

nathan

--
Nathan Sidwell
2017-05-24  Nathan Sidwell  

	* auto-profile.c (afdo_propagate): Adjust T const cast to avoid
	warning.

Index: auto-profile.c
===
--- auto-profile.c	(revision 248441)
+++ auto-profile.c	(working copy)
@@ -1377,7 +1377,7 @@ afdo_propagate (bb_set *annotated_bb, ed
   FOR_ALL_BB_FN (bb, cfun)
   {
 bb->count = ((basic_block)bb->aux)->count;
-if (is_bb_annotated ((const basic_block)bb->aux, *annotated_bb))
+if (is_bb_annotated ((basic_block)bb->aux, *annotated_bb))
   set_bb_annotated (bb, annotated_bb);
   }
 

Re: Ipa function summary pass

[Paul Hua]

Hi,
On mips64el target:
New Fail:
FAIL: gfortran.dg/pr48636.f90   -O   scan-ipa-dump fnsummary "inline
hints: loop_iterations"

Paul

On Wed, May 24, 2017 at 4:47 PM, Christophe Lyon
 wrote:
> Hi,
>
> On 23 May 2017 at 18:23, Jan Hubicka  wrote:
>> Hi,
>> this patch finishes the breakup of ipa-inline and function analysis.
>> The analysis is now done by separate pass and I will work on cleaning
>> up the interfaces now.
>>
>> Honza
>>
>> * cgraphunit.c (symbol_table::process_new_functions): Update.
>> * ipa-fnsummary.c (pass_data_inline_parameters): Remove.
>> (inline_generate_summary): Rename to ...
>> (ipa_fn_summary_generate): ... this one.
>> (inline_read_summary): Rename to ...
>> (ipa_fn_summary_read): ... this one.
>> (inline_write_summary): Rename to ...
>> (ipa_fn_summary_write): ... this one.
>> (inline_free_summary): Rename to ...
>> (ipa_free_fn_summary): ... this one.
>> (pass_data_local_fn_summary, pass_local_fn_summary,
>> make_pass_local_fn_summary, pass_data_ipa_free_fn_summary,
>> pass_ipa_free_fn_summary, make_pass_ipa_free_fn_summary,
>> pass_data_ipa_fn_summary, pass_ipa_fn_summary,
>> make_pass_ipa_fn_summary): New.
>> * ipa-fnsummary.h (inline_generate_summary, inline_read_summary,
>> inline_write_summary, inline_free_summary): Remove.
>> (ipa_free_fn_summary) : New.
>> * ipa-inline.c (ipa_inline): Update.
>> (pass_ipa_inline): Do not generate summaries.
>> * ipa.c (pass_data_ipa_free_fn_summary, pass_ipa_free_fn_summary):
>> Remove.
>> * passes.def: Replace pass_inline_parameters by pass_local_fn_summary
>> and add pass_ipa_fn_summary.
>> * tree-pass.h (make_pass_ipa_fn_summary, make_pass_local_fn_summary):
>> New.
>> (make_pass_inline_parameters): Remove.
>>
>> * lto.c (do_whole_program_analysis): Replace inline_free_summary
>> by ipa_free_fn_summary.
>>
>> * gcc.dg/ipa/ctor-empty-1.c: Update template.
>> * gcc.dg/ipa/inline-5.c: Likewise.
>> * gfortran.dg/pr48636.f90: Likewise.
>> Index: cgraphunit.c
>> ===
>> --- cgraphunit.c(revision 248365)
>> +++ cgraphunit.c(working copy)
>> @@ -339,7 +339,7 @@ symbol_table::process_new_functions (voi
>>  and splitting.  This is redundant for functions added late.
>>  Just throw away whatever it did.  */
>>   if (!summaried_computed)
>> -   inline_free_summary ();
>> +   ipa_free_fn_summary ();
>> }
>>   else if (ipa_fn_summaries != NULL)
>> compute_fn_summary (node, true);
>> Index: ipa-fnsummary.c
>> ===
>> --- ipa-fnsummary.c (revision 248366)
>> +++ ipa-fnsummary.c (working copy)
>> @@ -2504,46 +2504,6 @@ compute_fn_summary_for_current (void)
>>return 0;
>>  }
>>
>> -namespace {
>> -
>> -const pass_data pass_data_inline_parameters =
>> -{
>> -  GIMPLE_PASS, /* type */
>> -  "inline_param", /* name */
>> -  OPTGROUP_INLINE, /* optinfo_flags */
>> -  TV_INLINE_PARAMETERS, /* tv_id */
>> -  0, /* properties_required */
>> -  0, /* properties_provided */
>> -  0, /* properties_destroyed */
>> -  0, /* todo_flags_start */
>> -  0, /* todo_flags_finish */
>> -};
>> -
>> -class pass_inline_parameters : public gimple_opt_pass
>> -{
>> -public:
>> -  pass_inline_parameters (gcc::context *ctxt)
>> -: gimple_opt_pass (pass_data_inline_parameters, ctxt)
>> -  {}
>> -
>> -  /* opt_pass methods: */
>> -  opt_pass * clone () { return new pass_inline_parameters (m_ctxt); }
>> -  virtual unsigned int execute (function *)
>> -{
>> -  return compute_fn_summary_for_current ();
>> -}
>> -
>> -}; // class pass_inline_parameters
>> -
>> -} // anon namespace
>> -
>> -gimple_opt_pass *
>> -make_pass_inline_parameters (gcc::context *ctxt)
>> -{
>> -  return new pass_inline_parameters (ctxt);
>> -}
>> -
>> -
>>  /* Estimate benefit devirtualizing indirect edge IE, provided KNOWN_VALS,
>> KNOWN_CONTEXTS and KNOWN_AGGS.  */
>>
>> @@ -3207,8 +3167,8 @@ ipa_fn_summary_t::insert (struct cgraph_
>>
>>  /* Note function body size.  */
>>
>> -void
>> -inline_generate_summary (void)
>> +static void
>> +ipa_fn_summary_generate (void)
>>  {
>>struct cgraph_node *node;
>>
>> @@ -3226,7 +3186,7 @@ inline_generate_summary (void)
>>ipa_fn_summaries->enable_insertion_hook ();
>>
>>ipa_register_cgraph_hooks ();
>> -  inline_free_summary ();
>> +  ipa_free_fn_summary ();
>>
>>FOR_EACH_DEFINED_FUNCTION (node)
>>  if (!node->alias)
>> @@ -3358,8 +3318,8 @@ inline_read_section (struct lto_file_dec
>> and inliner, so when ipa-cp is active, we don't need to write them
>> twice.  */
>>
>> -void

Re: [PATCH] PR c++/80544 strip cv-quals from cast results

[Andrew Pinski]

On Wed, May 24, 2017 at 12:29 PM, Jonathan Wakely  wrote:
> On 24/05/17 14:50 -0400, Jason Merrill wrote:
>>
>> On Wed, May 24, 2017 at 10:20 AM, Jonathan Wakely 
>> wrote:
>>>
>>> On 23/05/17 16:26 -0400, Jason Merrill wrote:


 On Tue, May 23, 2017 at 2:00 PM, Jonathan Wakely 
 wrote:
>
>
> On 19/05/17 15:14 -0400, Jason Merrill wrote:
>>
>>
>>
>> On Thu, Apr 27, 2017 at 12:59 PM, Jonathan Wakely 
>> wrote:
>>>
>>>
>>>
>>> I also tried to add a warning like EDG's (see the PR) but it gave a
>>> false positive for direct-list-init of scoped enums (P0138R2,
>>> r240449)
>>> because that code goes through build_c_cast to perform the
>>> conversion,
>>> so looks like a cast to my new warning.
>>
>>
>>
>>
>> The enum init code could strip the cv-quals when calling build_c_cast
>> to avoid the warning.
>
>
>
>
> Thanks, that works. I don't think this warning fits under any existing
> option, so I'll add a new one. -Wuseless-cast-qual maybe? Or is that
> too close to -Wuseless-cast and -Wcast-qual and would cause confusion?



 -Wcast-rvalue-qual ?
>>>
>>>
>>>
>>> I realised that -Wignored-qualifiers is a good fit. That warns about
>>> ignored cv-qualifiers on return types, which is a very similar case.
>>>
>>> This patch adds a new function to conditionally warn and calls that
>>> from the build_*_cast functions after they produce a valid result. I
>>> originally put the warnings next to the cv_unqualified calls that
>>> strip the quals, but was getting duplicate warnings when build_cp_cast
>>> calls more than one of the build_*_cast_1 functions.
>>>
>>> This also removes the unnecessary check for reference types that
>>> Nathan pointed out.
>>>
>>> Tested x86_64-linux and powerpc64-linux. OK for trunk?
>>
>>
>>> +/*
>>> +  Warns if the cast ignores cv-qualifiers on TYPE.
>>> + */
>>
>>
>> The GCC sources don't put /* and */ on their own line.  OK with that
>> change, thanks!
>
>
> OK, I'll also fix it on the maybe_warn_about_useless_cast function
> just above, which I copied :-)

This change caused a bootstrap failure on aarch64-linux-gnu and
x86_64-linux-gnu:
In file included from ../../gcc/gcc/system.h:691:0,
 from ../../gcc/gcc/read-rtl.c:31:
../../gcc/gcc/read-rtl.c: In member function ‘const char*
md_reader::apply_iterator_to_string(const char*)’:
../../gcc/gcc/../include/libiberty.h:722:38: error: type qualifiers
ignored on cast result type [-Werror=ignored-qualifiers]
 # define alloca(x) __builtin_alloca(x)
  ^
../../gcc/gcc/../include/libiberty.h:727:47: note: in expansion of
macro ‘alloca’
char *const libiberty_nptr = (char *const) alloca (libiberty_len); \
   ^~
../../gcc/gcc/read-rtl.c:380:21: note: in expansion of macro ‘ASTRDUP’
   base = p = copy = ASTRDUP (string);
 ^~~

I know you did not touch libiberty.h but that is emitting an error.
Did you test your patch with a full bootstrap?  I thought that was
recorded as being required now for C++ patches; I know a few years
back when the GCC was not compiling as C++, it was not required.

Thanks,
Andrew


>
>

Re: [PATCH v2 3/N] Transform TDF_{lang,tree,ipa,rtl} to dump_kind enum.

[Martin Sebor]

On 05/12/2017 07:04 AM, Martin Liška wrote:

Third part removes TDF_* flags mentioned in the subject. These flags are used
to enable all passes of specific type and Nathan has recently separated these
by a new pair of macros. I hope moving these to a separate enum will help even 
more.


Just as an FYI, the addition of the user-defined constructor makes
the class non-trivial and so unsafe to initialize by calling memset
in C++ 11 and later.  In C++ 98 that GCC is compiled with, the class
is not a POD and so not safe to realloc (i.e., new objects must be
brought to life by calling a constructor).  I noticed this by testing
my latest patch for the new -Wclass-memassign warning but I thought
it might be worth noting here as well.

+  /* Constructor.  */
+  dump_file_info ();
+
+  /* Constructor.  */
+  dump_file_info (const char *_suffix, const char *_swtch, dump_kind 
_dkind,

+ int _num);
+

Also, making the ctor constexpr and defining it in the .c file will
trigger Clang -Wundefined-inline and makes the ctor unusable in other
sources.  AFAICS, there is no constexpr context where the constexpr
ctor would be needed so I'm not sure I understand its purpose.  Is
it constexpr to allow the static initialization of dump_files[0]?
(All the other elements of the array are dynamically initialized
by calling the other, non-constexpr ctor so that doesn't seem like
the answer.)

Martin

Re: [libibery PATCH] Fix bootstrap

[Nathan Sidwell]

On 05/24/2017 08:34 PM, Nathan Sidwell wrote:

We now warn on casts to T const.  Applied as obvious to fix bootstrap.


And this fixes c-common.c

nathan

--
Nathan Sidwell
2017-05-24  Nathan Sidwell  

	* c=common.c (field_decl_cmp, resort_field_decl_cmp): Adjust T
	const casts to avoid warning.

Index: c-common.c
===
--- c-common.c	(revision 248441)
+++ c-common.c	(working copy)
@@ -5866,8 +5866,8 @@ check_builtin_function_arguments (locati
 int
 field_decl_cmp (const void *x_p, const void *y_p)
 {
-  const tree *const x = (const tree *const) x_p;
-  const tree *const y = (const tree *const) y_p;
+  const tree *const x = (const tree *) x_p;
+  const tree *const y = (const tree *) y_p;
 
   if (DECL_NAME (*x) == DECL_NAME (*y))
 /* A nontype is "greater" than a type.  */
@@ -5892,8 +5892,8 @@ pointer operator in resort_data.  */
 static int
 resort_field_decl_cmp (const void *x_p, const void *y_p)
 {
-  const tree *const x = (const tree *const) x_p;
-  const tree *const y = (const tree *const) y_p;
+  const tree *const x = (const tree *) x_p;
+  const tree *const y = (const tree *) y_p;
 
   if (DECL_NAME (*x) == DECL_NAME (*y))
 /* A nontype is "greater" than a type.  */

[C++ PATCH] Overload cleanups

[Nathan Sidwell]

here are a few more cleanups from the modules branch.

firstl type_unknown_p had some historical baggage from when overloads 
were tree lists.  No need for that, and then why not make it inline?


is_overloaded_fn and friends are ripe for cleanup, and this does a 
little of that.  Remove some use of OVL_CURRENT, which I will be killing 
soon.


Fixed up some formatting and inconsistency in cp-tree.h whilst there.

committed to trunk.

nathan
--
Nathan Sidwell
2017-05-24  Nathan Sidwell  

	* cp-tree.h (cp_free_lang_data): Add extern.
	(ovl_skip_hidden, is_overloaded_fn, really_overloaded_fn): Add
	ATTRIBUTE_PURE.
	(type_unknown_p): Return bool, make inline, lose TREE_LIST check.
	* typeck.c (type_unknown_p): Delete.
	* tree.c (is_overloaded_fn): Use MAYBE_BASELINE_FUNCTIONS, adjust
	overload management.
	(dependent_name): Likewise.
	(decl_anon_ns_mem_p): Simplify.

Index: cp/cp-tree.h
===
--- cp/cp-tree.h	(revision 248423)
+++ cp/cp-tree.h	(working copy)
@@ -6789,7 +6789,7 @@ extern tree finish_builtin_launder		(loc
 /* in tree.c */
 extern int cp_tree_operand_length		(const_tree);
 extern int cp_tree_code_length			(enum tree_code);
-void cp_free_lang_data (tree t);
+extern void cp_free_lang_data 			(tree t);
 extern tree force_target_expr			(tree, tree, tsubst_flags_t);
 extern tree build_target_expr_with_type		(tree, tree, tsubst_flags_t);
 extern void lang_check_failed			(const char *, int,
@@ -6811,7 +6811,8 @@ extern bool type_has_nontrivial_copy_ini
 extern void maybe_warn_parm_abi			(tree, location_t);
 extern bool class_tmpl_impl_spec_p		(const_tree);
 extern int zero_init_p(const_tree);
-extern bool check_abi_tag_redeclaration		(const_tree, const_tree, const_tree);
+extern bool check_abi_tag_redeclaration		(const_tree, const_tree,
+		 const_tree);
 extern bool check_abi_tag_args			(tree, tree);
 extern tree strip_typedefs			(tree, bool * = NULL);
 extern tree strip_typedefs_expr			(tree, bool * = NULL);
@@ -6852,10 +6853,11 @@ extern tree ovl_make(tree fn,
 		 tree next = NULL_TREE);
 extern tree ovl_insert(tree fn, tree maybe_ovl,
 		 bool using_p = false);
-extern tree ovl_skip_hidden			(tree);
+extern tree ovl_skip_hidden			(tree) ATTRIBUTE_PURE;
 extern tree lookup_add(tree fns, tree lookup);
 extern void lookup_keep(tree lookup, bool keep);
-extern int is_overloaded_fn			(tree);
+extern int is_overloaded_fn			(tree) ATTRIBUTE_PURE;
+extern bool really_overloaded_fn		(tree) ATTRIBUTE_PURE;
 extern tree dependent_name			(tree);
 extern tree get_fns(tree) ATTRIBUTE_PURE;
 extern tree get_first_fn			(tree) ATTRIBUTE_PURE;
@@ -6876,7 +6878,6 @@ extern bool decl_anon_ns_mem_p			(const_
 extern tree lvalue_type(tree);
 extern tree error_type(tree);
 extern int varargs_function_p			(const_tree);
-extern bool really_overloaded_fn		(tree);
 extern bool cp_tree_equal			(tree, tree);
 extern tree no_linkage_check			(tree, bool);
 extern void debug_binfo(tree);
@@ -6933,7 +6934,7 @@ extern tree require_complete_type_sfinae
 extern tree complete_type			(tree);
 extern tree complete_type_or_else		(tree, tree);
 extern tree complete_type_or_maybe_complain	(tree, tree, tsubst_flags_t);
-extern int type_unknown_p			(const_tree);
+inline bool type_unknown_p			(const_tree);
 enum { ce_derived, ce_type, ce_normal, ce_exact };
 extern bool comp_except_specs			(const_tree, const_tree, int);
 extern bool comptypes(tree, tree, int);
@@ -7311,6 +7312,12 @@ ovl_first (tree node)
   return node;
 }
 
+inline bool
+type_unknown_p (const_tree expr)
+{
+  return TREE_TYPE (expr) == unknown_type_node;
+}
+
 /* -- end of C++ */
 
 #endif /* ! GCC_CP_TREE_H */
Index: cp/typeck.c
===
--- cp/typeck.c	(revision 248422)
+++ cp/typeck.c	(working copy)
@@ -162,15 +162,6 @@ complete_type_or_else (tree type, tree v
   return complete_type_or_maybe_complain (type, value, tf_warning_or_error);
 }
 
-/* Return truthvalue of whether type of EXP is instantiated.  */
-
-int
-type_unknown_p (const_tree exp)
-{
-  return (TREE_CODE (exp) == TREE_LIST
-	  || TREE_TYPE (exp) == unknown_type_node);
-}
-
 
 /* Return the common type of two parameter lists.
We assume that comptypes has already been done and returned 1;
Index: cp/tree.c
===
--- cp/tree.c	(revision 248423)
+++ cp/tree.c	(working copy)
@@ -2337,15 +2337,16 @@ is_overloaded_fn (tree x)
   if (TREE_CODE (x) == OFFSET_REF
   || TREE_CODE (x) == COMPONENT_REF)
 x = TREE_OPERAND (x, 1);
-  if (BASELINK_P (x))
-x = BASELINK_FUNCTIONS (x);
+  x = MAYBE_BASELINK_FUNCTIONS (x);
   if (TREE_CODE (x) == TEMPLATE_ID_EXPR)
 x = TREE_OPERAND (x, 0);
-  if (DECL_FUNCTION_TEMPLATE_P (OVL_CURRENT (x))
-  || (TREE_CODE (x) == OVERLOAD && OVL_CHAIN (x)))
+
+  if (DECL_FUNCTION_TEMPLATE_P (OVL_FIRST (x))
+  || 

[C++ PATCH] Friend decls

[Nathan Sidwell]

With pushdecl revamped, there's no need for do_friend to do some 
checking with a local class friend.  And therefore no need for the very 
specialized lookup_name_innermost_nonclass_level.


push_local_binding will get some more cleanup soon.

Committed to trunk.

nathan
--
Nathan Sidwell
2017-05-24  Nathan Sidwell  

	cp/
	* friend.c (do_friend): Remove check for existing decl.
	* name-lookup.h (lookup_name_innermost_nonclass_level): Delete.
	* name-lookup.c (push_local_binding): Directly look for binding.
	(lookup_name_innermost_nonclass_level_1): Delete.
	(lookup_name_innermost_nonclass_level): Delete.

	testsuite/
	* g++.dg/lookup/friend12.C: Adjust diagnostics.
	* g++.dg/lookup/friend19.C: New.
	* g++.dg/lookup/friend20.C: New.

Index: cp/friend.c
===
--- cp/friend.c	(revision 248432)
+++ cp/friend.c	(working copy)
@@ -608,25 +608,8 @@ do_friend (tree ctype, tree declarator,
 	   is instantiated.  */
 	decl = push_template_decl_real (decl, /*is_friend=*/true);
 	  else if (current_function_decl)
-	{
-	  /* This must be a local class.  11.5p11:
-
-		 If a friend declaration appears in a local class (9.8) and
-		 the name specified is an unqualified name, a prior
-		 declaration is looked up without considering scopes that
-		 are outside the innermost enclosing non-class scope. For a
-		 friend function declaration, if there is no prior
-		 declaration, the program is ill-formed.  */
-	  tree t = lookup_name_innermost_nonclass_level (DECL_NAME (decl));
-	  if (t)
-		decl = pushdecl (decl, /*is_friend=*/true);
-	  else
-		{
-		  error ("friend declaration %qD in local class without "
-			 "prior declaration", decl);
-		  return error_mark_node;
-		}
-	}
+	/* pushdecl will check there's a local decl already.  */
+	decl = pushdecl (decl, /*is_friend=*/true);
 	  else
 	{
 	  /* We can't use pushdecl, as we might be in a template
Index: cp/name-lookup.c
===
--- cp/name-lookup.c	(revision 248432)
+++ cp/name-lookup.c	(working copy)
@@ -2103,7 +2103,13 @@ push_local_binding (tree id, tree decl,
  push_local_binding with a friend decl of a local class.  */
   b = innermost_nonclass_level ();
 
-  if (lookup_name_innermost_nonclass_level (id))
+  cxx_binding *binding = NULL;
+  if (b->kind == sk_namespace)
+binding = find_namespace_binding (current_namespace, id);
+  else
+binding = find_local_binding (b, id);
+
+  if (binding)
 {
   /* Supplement the existing binding.  */
   if (!supplement_binding (IDENTIFIER_BINDING (id), decl))
@@ -5430,37 +5436,6 @@ lookup_type_scope (tree name, tag_scope
   return ret;
 }
 
-
-/* Similar to `lookup_name' but look only in the innermost non-class
-   binding level.  */
-
-static tree
-lookup_name_innermost_nonclass_level_1 (tree name)
-{
-  cp_binding_level *b = innermost_nonclass_level ();
-  cxx_binding *binding = NULL;
-
-  if (b->kind == sk_namespace)
-binding = find_namespace_binding (current_namespace, name);
-  else
-binding = find_local_binding (b, name);
-
-  return binding ? binding->value : NULL_TREE;
-}
-
-/* Wrapper for lookup_name_innermost_nonclass_level_1.  */
-
-tree
-lookup_name_innermost_nonclass_level (tree name)
-{
-  tree ret;
-  bool subtime = timevar_cond_start (TV_NAME_LOOKUP);
-  ret = lookup_name_innermost_nonclass_level_1 (name);
-  timevar_cond_stop (TV_NAME_LOOKUP, subtime);
-  return ret;
-}
-
-
 /* Returns true iff DECL is a block-scope extern declaration of a function
or variable.  */
 
Index: cp/name-lookup.h
===
--- cp/name-lookup.h	(revision 248432)
+++ cp/name-lookup.h	(working copy)
@@ -310,7 +310,6 @@ extern tree get_namespace_binding (tree
 extern void set_global_binding (tree id, tree val);
 extern tree lookup_qualified_name (tree, tree, int, bool, /*hidden*/bool = false);
 extern tree lookup_name_nonclass (tree);
-extern tree lookup_name_innermost_nonclass_level (tree);
 extern bool is_local_extern (tree);
 extern tree lookup_function_nonclass (tree, vec *, bool);
 extern bool pushdecl_class_level (tree);
Index: testsuite/g++.dg/lookup/friend12.C
===
--- testsuite/g++.dg/lookup/friend12.C	(revision 248422)
+++ testsuite/g++.dg/lookup/friend12.C	(working copy)
@@ -2,9 +2,9 @@
 
 void foo()
 {
+  extern void bar (int); // not the bar we are looking for
   struct A
   {
-friend void bar();		// { dg-error "without prior declaration" }
+friend void bar();	// { dg-error "without prior local declaration" }
   };
-  bar();			// { dg-error "3:'bar' was not declared" }
 }
Index: testsuite/g++.dg/lookup/friend19.C
===
--- testsuite/g++.dg/lookup/friend19.C	(revision 0)
+++ testsuite/g++.dg/lookup/friend19.C	

Re: [libibery PATCH] Fix bootstrap

[Richard Biener]

On May 25, 2017 3:22:18 AM GMT+02:00, Nathan Sidwell  wrote:
>On 05/24/2017 09:13 PM, Nathan Sidwell wrote:
>> On 05/24/2017 08:56 PM, Nathan Sidwell wrote:
>>> On 05/24/2017 08:34 PM, Nathan Sidwell wrote:
 We now warn on casts to T const.  Applied as obvious to fix
>bootstrap.
>>>
>>> And this fixes c-common.c
>> 
>> And fix auto-profile.c
>
>and lto-streamer-out.c, sigh

What's the reason to warn here?!

Richard.

[libibery PATCH] Fix bootstrap

[Nathan Sidwell]

We now warn on casts to T const.  Applied as obvious to fix bootstrap.

nathan
--
Nathan Sidwell
Index: ChangeLog
===
--- ChangeLog	(revision 248441)
+++ ChangeLog	(working copy)
@@ -1,3 +1,7 @@
+2017-05-24  Nathan Sidwell  
+
+	* libiberty.h (ASTRDUP): Adjust cast to avoid warning.
+
 2017-05-19  Eli Zaretskii 
 
 	* environ.h: Add #ifndef guard.
Index: libiberty.h
===
--- libiberty.h	(revision 248441)
+++ libiberty.h	(working copy)
@@ -724,7 +724,7 @@ extern void *C_alloca (size_t) ATTRIBUTE
 # define ASTRDUP(X) \
   (__extension__ ({ const char *const libiberty_optr = (X); \
const unsigned long libiberty_len = strlen (libiberty_optr) + 1; \
-   char *const libiberty_nptr = (char *const) alloca (libiberty_len); \
+   char *const libiberty_nptr = (char *) alloca (libiberty_len); \
(char *) memcpy (libiberty_nptr, libiberty_optr, libiberty_len); }))
 #else
 # define alloca(x) C_alloca(x)

Re: [PATCH] add more detail to -Wconversion and -Woverflow (PR 80731)

[Martin Sebor]

On 05/24/2017 11:08 AM, Joseph Myers wrote:

On Wed, 17 May 2017, Martin Sebor wrote:


@@ -1036,31 +1079,76 @@ warnings_for_convert_and_check (location_t loc, tree 
type, tree expr,
  /* This detects cases like converting -129 or 256 to
 unsigned char.  */
  if (!int_fits_type_p (expr, c_common_signed_type (type)))
-   warning_at (loc, OPT_Woverflow,
-   "large integer implicitly truncated to unsigned type");
+   {
+ if (cst)
+   warning_at (loc, OPT_Woverflow,
+   (TYPE_UNSIGNED (exprtype)
+? "conversion from %qT to %qT "
+"changes value from %qE to %qE"
+: "unsigned conversion from %qT to %qT "
+"changes value from %qE to %qE"),
+   exprtype, type, expr, result);
+ else
+   warning_at (loc, OPT_Woverflow,
+   (TYPE_UNSIGNED (exprtype)
+? "conversion from %qT to %qT "
+"changes the value of %qE"
+: "unsigned conversion from %qT to %qT "
+"changes the value of %qE"),
+   exprtype, type, expr);
+   }


You need to use G_() around both arguments to ?:, otherwise only one will
get extracted for translation.


diff --git a/gcc/testsuite/c-c++-common/pr68657-1.c 
b/gcc/testsuite/c-c++-common/pr68657-1.c
index 84f3e54..33fdf86 100644
--- a/gcc/testsuite/c-c++-common/pr68657-1.c
+++ b/gcc/testsuite/c-c++-common/pr68657-1.c
@@ -5,14 +5,14 @@
 void
 f1 (void)
 {
-  unsigned int a = -5; /* { dg-error "negative integer implicitly converted to 
unsigned type" } */
+  unsigned int a = -5; /* { dg-error "unsigned conversion from .int. to .unsigned 
int. changes value from .-5. to .4294967291." } */


The more specific match would fail for targets with 16-bit int.  You need
to keep it less specific in this test (if you want to test the more
specific text as well, another test could be added for that, restricted to
the int32 effective-target).

(The changes to Wconversion-real-integer-3.C and
Wconversion-real-integer2.C are OK in that those tests are restricted to
int32plus, although in theory 64-bit int would be an issue there.)


+  /* According to 6.3.1.3 of C11:
+ -3-  Otherwise, the new type is signed and the value cannot be
+  represented in it; either the result is implementation-defined
+ or an implementation-defined signal is raised.
+
+ In GCC such conversios wrap and diagnosed by mentioning "overflow"
+ if the absolut value of the operand is in excess of the maximum of
+ the destination of type, and "conversion" otherwise, as follows:  */


s/conversios/conversions/; s/absolut/absolute/

OK with those changes.


Thanks for the careful review!  Done and committed in r248431.

Martin

Re: C++ PATCH to -Wunused with C++17 structured bindings

[Jakub Jelinek]

On Tue, May 23, 2017 at 09:45:10PM -0400, Jason Merrill wrote:
> Someone on IRC complained that there was no way to suppress -Wunused
> on structured bindings.  It seemed to me that the way the feature
> works, we shouldn't warn about the bindings individually; users need
> to give each of the subobjects a name even if they're only interested
> in using one of them.
> 
> So this patch switches to tracking whether the underlying aggregate
> object as a whole is used; using one of the bindings will avoid any
> warning.
> 
> This doesn't apply to tuple structured bindings, since in that case
> the bindings are actual variables rather than aliases to subobjects.
> 
> Tested x86_64-pc-linux-gnu, applying to trunk.

So, shall we have even for the tuple structured bindings somewhere (in
lang_decl, such as adding struct lang_decl_decomp that would include
lang_decl_min?) the tree for the underlying artificial var decl?

Jakub

Re: [PATCH] Fix a SPARC -mcbcond compare-and-branch out of range failure.

[Eric Botcazou]

> The compare-and-branch distance was calculated incorrectly. This occurred
> because a -mflat sibcall returned an instruction count of 2 instead of 3.
> Fix sparc.md to match the output_sibcall() code in sparc.c.
> 
>   * config/sparc/sparc.md: Set the number of instructions correctly
>   for -mflat sibcalls, to match output_sibcall().

OK for all active branches, but the ChangeLog entry should be something like:

* config/sparc/sparc.md (length): Return the correct value for -mflat
sibcalls to match output_sibcall.

Note that we *never* use a pair of parentheses after function names.

-- 
Eric Botcazou

Re: [PATCH 2/5 v3] Vect peeling cost model

[Richard Sandiford]

Robin Dapp  writes:
>> Not sure I've understood the series TBH, but is the npeel == vf / 2
>> there specifically for the "unknown number of peels" case?  How do
>> we distinguish that from the case in which the number of peels is
>> known to be vf / 2 at compile time?  Or have I missed the point
>> completely? (probably yes, sorry!)
>
> Good point, that's not totally waterproof for future uses of
> vect_get_peeling_costs_all_drs ().  Currently, however, only when
> peeling for unknown alignment vf != 0 will be passed to it (and vf == 0
> for the known alignment case), so we can distinguish the cases.

Ah, makes sense now, thanks.  Would you mind putting something like
that last sentence in a comment?

> In future, the whole vf/2 handling should be improved anyway since e.g.
> it is hardcoded here as well as in tree-vect-loop.c.  npeel = 0 also has
> a double meaning, namely not peeling when peeling for known alignment
> and peeling vf/2 iters when peeling for unknown alignment.  Room for
> improvement I guess :)

Yeah :-)  But thanks for the series, looks like a nice improvement.

Richard

Re: [PATCH][www] Deprecate MPX for GCC 7

[Richard Biener]

On Tue, 23 May 2017, Jeff Law wrote:

> On 05/23/2017 06:50 AM, Richard Biener wrote:
> > 
> > Appearantly we forgot to officially deprecate MPX in GCC 7 changes.html.
> > 
> > The following adds the missing note.
> > 
> > Ok?
> > 
> > Thanks,
> > Richard.
> > 
> > 2017-05-23  Richard Biener  
> > 
> > * gcc-7/changes.html: Deprecate MPX.
> I don't recall deprecating MPX.  I do recall deprecating Cilk+.

Ok, maybe I misremember.

> There's certainly folks at Intel fixing MPX related issues for GCC.

Sure.  But bootstrap with MPX is broken since forever and I don't see
anybody using the feature -- plus it's maintainance burden is quite
higher than Cilk+.

Well.  Let's keep it in mind then for GCC 8 deprecation.

Disclaimer: I was asked if we can remove it right now because of its
impact on cgraph code.

Richard.

Re: [PATCH] Prevent extract_muldiv from introducing an overflow (PR sanitizer/80800)

[Richard Biener]

On Fri, 19 May 2017, Alexander Monakov wrote:

> On Fri, 19 May 2017, Joseph Myers wrote:
> > On Fri, 19 May 2017, Alexander Monakov wrote:
> > > (to be precise, if the multiplication is done in a signed type and the 
> > > middle
> > > constant factor was a negated power of two, the sign change needs to 
> > > remain:
> > > 
> > > a * -4 * b * 2
> > > 
> > > needs to be transformed to
> > > 
> > > a * -1 * b * 8 )
> > 
> > Shouldn't that only be the case if the middle constant was -1 and the 
> > outer constant was 1?  If a * -4 * b is INT_MIN, a * b won't overflow and 
> > so a * b * -8 should be a safe transformation.
> 
> Indeed, I should have considered the situation more carefully.  Thank you for
> the correction.

Feel free to sumbit a patch improving the situation (as said, preferably
not in extract_muldiv).  Or open an enhancement bugreport refering to the
above constraints.

Richard.

Re: SSA range class and removal of VR_ANTI_RANGEs

[Richard Biener]

On Tue, May 23, 2017 at 12:48 PM, Aldy Hernandez  wrote:
> Howdy!
>
> For Andrew's upcoming on-demand range work I have created a range class for
> use in his engine.  Currently, the range class is only for SSA integers, but
> there is no reason why we couldn't adapt this for RTL or non-integer types
> at a later time.
>
> The class can live outside of his work, as can be demonstrated by the
> attached patch.  With it, I was able to rewrite the post-VRP range
> information to use this class and get rid of VR_ANTI_RANGE throughout the
> compiler.  A VR_ANTI_RANGE of ~[5,10] becomes [-MIN,4][11,+MAX].
>
> The internal structure of VRP is unchanged.  I have only changed the outward
> facing structures.
>
> A good example of how much cleaner using an actual range rather than
> VR_ANTI_RANGEs is the change to get_size_range() in the attached patch. We
> remove an assortment of contortions into:
>
> +  /* Remove negative numbers from the range.  */
> +  irange positives;
> +  range_positives (, exptype, allow_zero ? 0 : 1);
> +  if (positives.Intersect (*ir))
> +{
> +  /* Remove the unknown parts of a multi-range.
> +This will transform [5,10][20,MAX] into [5,10].  */
> +  if (positives.num_ranges () > 1
> + && positives.upper_bound () == wide_int (TYPE_MAX_VALUE
> (exptype)))
> +   positives.remove_range (positives.num_ranges () - 1);
> +
> +  range[0] = wide_int_to_tree (exptype, positives.lower_bound ());
> +  range[1] = wide_int_to_tree (exptype, positives.upper_bound ());
> +}
> +  else
> +{
> +  /* If removing the negative numbers didn't give us anything
> +back, the entire range was negative. Leave things as they
> +were, and let the caller sort it out.  */
> +  range[0] = wide_int_to_tree (exptype, min);
> +  range[1] = wide_int_to_tree (exptype, max);
>  }
>
> A few notes:
>
> 1. There are still two uses of VR_ANTI_RANGEs left after this patch: ip-cp.c
> and ipa-prop.c.  I didn't look too hard at these two passes, as they are
> using `struct value_range' which should only have been used *before* VRP
> finishes.  I can work on this as a follow-up.

So my ultimate goal was to somehow make the range operations in VRP
(union, intersect, unary and binary ops) have an API that can be easily
used with both the internal VRP lattice ranges and the SSA name associated
ranges.  Now that we have C++ we could either use some kind of adaptors
or make them templates -- or something else.

> 2. I have not included ChangeLog entries, as I would hate to write them, and
> have the API or significant things change from under me as part of the
> review.  I can certainly cobble the ChangeLog entries as soon as/if we agree
> that this is an acceptable approach.
>
> 3. There are lots of unit tests to maintain sanity.  The cast ones in
> particular will definitely need refinement as Andrew's work stresses the
> class.
>
> The attached patch passes bootstrap and tests.
>
> I have also benchmarked an assortment of .ii files (from a previous
> bootstrap) with no noticeable difference in -O2 compilation time.  So, I
> would prefer to tackle any micro-optimizations either as a follow-up or if
> it actually becomes noticeable--. Yeah, yeah, I know.  Wishful thinking ;-).

+  // If we will overflow, don't bother.  This will handle unsigned
+  // underflow which doesn't set the overflow bit.
+  //
+  // Note: Perhaps all these  checks are unecessary since we
+  // are manually checking for overflow with the if() below.

no multi-line // comments please.  What's wrong with /* ... */?

+// Convert the current range in place into a range of type NEW_TYPE.
+// The type of the original range is changed to the new type.
+
+void
+irange::cast (tree new_type)
+{
+  if (!n)

so this duplicates VRP unary op with NOP/CONVERT_EXPR.

+void
+irange::Union (wide_int x, wide_int y)
+{

why capital U?




>
> Fire away!
> Aldy
>
> p.s. Please refer any comments as to why we need the class, or why we need
> on-demand range information to Andrew :-P.

Fix var-tracking for special record parameters passed indirectly

[Eric Botcazou]

var-tracking doesn't track structures and arrays as a whole because it cannot 
track values for multiple-part variables, but it has a special provision for 
Ada fat pointer types, which are structures with integral mode containing a 
pair of pointers and are pervasive in the language (see param-[123].c in the 
guality testsuite).  This works fine e.g. on x86 or x86-64, but not on SPARC 
or Visium which pass these structures indirectly as per their ABI.

Tested on x86_64-suse-linux and visium-elf, applied on mainline as obvious.


2017-05-24  Eric Botcazou  

* var-tracking.c (track_expr_p): Do not return 0 for tracked record
parameters passed indirectly.

-- 
Eric BotcazouIndex: var-tracking.c
===
--- var-tracking.c	(revision 248140)
+++ var-tracking.c	(working copy)
@@ -5220,8 +5220,9 @@ track_expr_p (tree expr, bool need_rtl)
   if (decl_rtl && MEM_P (decl_rtl))
 {
   /* Do not track structures and arrays.  */
-  if (GET_MODE (decl_rtl) == BLKmode
-	  || AGGREGATE_TYPE_P (TREE_TYPE (realdecl)))
+  if ((GET_MODE (decl_rtl) == BLKmode
+	   || AGGREGATE_TYPE_P (TREE_TYPE (realdecl)))
+	  && !tracked_record_parameter_p (realdecl))
 	return 0;
   if (MEM_SIZE_KNOWN_P (decl_rtl)
 	  && MEM_SIZE (decl_rtl) > MAX_VAR_PARTS)

Re: SSA range class and removal of VR_ANTI_RANGEs

[Richard Biener]

..On Tue, May 23, 2017 at 5:24 PM, Andrew MacLeod  wrot
> On 05/23/2017 10:54 AM, Jakub Jelinek wrote:
>>
>> On Tue, May 23, 2017 at 10:38:44AM -0400, Andrew MacLeod wrote:
>>>
>>> As follow on work we have discussed an interface which would be able to
>>> calculate a bitmask (for either zeros or ones) from a range and vice
>>> versa..
>>
>> Sometimes the range vs. nonzero_bits info is redundant, you can compute
>> one from the other or vice versa without any information loss, but in many
>> cases it is not redundant, you can have e.g. known zero least significant
>> or
>> some middle bits, or the range boundaries are not powers of two or powers
>> of
>> two - 1.  The point is that with the coexistence of both it can be
>> gradually
>> improved, first you e.g. find some range, then CCP can use the
>> corresponding
>> nonzero_bits knowledge from that range in bitwise mask propagation, then
>> you
>> notice some other bits are known to be zero, perhaps from that adjust the
>> value range again if possible, ...
>
>
> Right, but we do only need to store both for those cases which we are
> actually refining the info.  and via a central manager of the information it
> can know when that is a thing to do and do it.  I also hope to ad some of
> the bit inormation ot the on demand system.. tat'll come later tho.I
> simply maintain that the vast majority of ssa_names are unlikely to need
> both, not that we never need both.   This seems like statistics that
> shouldn't be too hard to find with some simple looking at the data at the
> end of compilation or various passes.
>
>>
>>> why don't we actually try measuring it and see if it is noticeable? and
>>> if
>>> it is, where the issues really are. You really think we have relevant
>>> range
>>> info  for 50% of the ssa_names in a program?  Id be surprised.  Again,
>>> thats
>>> something we should probably measure and see whats typical.  the range
>>> table
>>> should only be used when we can refine the global range to something
>>> other
>>> than range_for_type().
>>
>> I'm not used to build firefox and various other large C++ projects with
>> LTO
>> regularly, so it would be harder for me to get that stuff working and
>> measure it, but I think e.g. Honza or Martin L. do that often and could
>> provide hints on what is needed to test that, then we can have exact
>> numbers.
>
> that seems reasonable.  I think we ought to look at the low hanging fruit
> for making it more efficient to start with before hassling them or that..
> unless it is trivial.   It would be useful t have input from "heavy"
> application users if there is any/much impact.
>>>
>>> We can also change the representation of the range to be 2 ranges like it
>>> is
>>
>> Well, the current representation is just 1 range (2 numbers) + 1 extra
>> number for the nonzero_bits bitmask.
>
>
> oh yeah,right but anti range is evil. Its worth losing a little bit of
> memory to get rid of that, imo  :-)

Well, anti-ranges are "evil" for actual working with ranges.  They are nice
for optimizing the storage requirements though.

As I'm replying late I'll add that yes, it does make a difference in memory
use.  We've seen this with IPA VRP info eating up 1 GB extra memory
for firefox so we optimized it to use trailing wide-ints.  So ..

+#define MAX_RANGES 6
...
+class GTY(()) irange
+{
...
+ public:
+  tree type;
+  wide_int bounds[MAX_RANGES];

is definitely a no-go.  type is also redundant.  Making 'n' a size_t is stupid.

Please apply some more common sense here...

We need to really think about making this a bit more flexible than just handling
integer ranges, eventually tracking non-zero bits as well.

So first of all I'd suggest to make MAX_RANGES a template parameter
so we can eventually use the same representation in both the VRP lattice,
the SSA name info and the basic range ops (I see you re-implemented all
of those rather than refactoring the VRP ones which would have benefited
most from "getting rid of anti-ranges").

What's this overflow flag for anyway?

That said, I think it's the wrong approach to start mucking with SSA name
associated ranges given they are supposed to be a cheap storage variant
of what VRP computes.  Start by making the VRP machinery work from
on-demand-ranges.  I do have some prototypes from last year or the year
before to do this -- the helpers VRP machinery is already generic enough
if you make use of VRPs range type.

>>
>>> More importantly, when the on-demand range work comes online it will end
>>> the
>>> proliferation of SSA_NAMES which carry ASSERT_EXPR information.  We won't
>>> see the trail of new  ssa_names the ASSET_EXPR chains create. I suspect
>>> that
>>> will eliminate storing global ranges and bits for most SSA names, which
>>> is
>>> likely to make this class a win regardless.
>>
>> Are you sure it is desirable to recompute it in all cases, rather than
>> just
>> use what you have recorded and recompute what you don't have 

Fix pessimistic DImode handling in combine.c:make_field_assignment

[Richard Sandiford]

The make_field_assignment code:

  src = force_to_mode (src, mode,
   GET_MODE_PRECISION (mode) >= HOST_BITS_PER_WIDE_INT
   ? HOST_WIDE_INT_M1U
   : (HOST_WIDE_INT_1U << len) - 1,
   0);

would ignore the field length len for DImode, even though DImode can be
handled using HWIs.  I think the code should be testing len instead.

The patch was originally part of the SVE machine_mode series.
Retesting showed that it changed the asm output on powerpc for a few
tests, so I thought it should go in separately.  Each test change
seemed to be an improvement.

Tested on aarch64-linux-gnu and x86_64-linux-gnu.  I no longer have
access to the compile farm to test on the powerpc boxes there.

Thanks,
Richard


2017-05-24  Richard Sandiford  

gcc/
* combine.c (make_field_assignment): Check len rather than the mode
precision when calling force_to_mode.

Index: gcc/combine.c
===
--- gcc/combine.c   2017-05-03 08:46:32.777861592 +0100
+++ gcc/combine.c   2017-05-24 09:25:25.170351268 +0100
@@ -9634,7 +9634,7 @@ make_field_assignment (rtx x)
 other, pos),
   dest);
   src = force_to_mode (src, mode,
-  GET_MODE_PRECISION (mode) >= HOST_BITS_PER_WIDE_INT
+  len >= HOST_BITS_PER_WIDE_INT
   ? HOST_WIDE_INT_M1U
   : (HOST_WIDE_INT_1U << len) - 1,
   0);

Re: [patch] build xz (instead of bz2) compressed tarballs and diffs

[Richard Biener]

On May 24, 2017 1:22:42 AM GMT+02:00, Matthias Klose  wrote:
>On 18.05.2017 03:34, Richard Biener wrote:
>> On Mon, May 15, 2017 at 3:11 AM, Matthias Klose 
>wrote:
>>> As discussed on IRC with Jakub and Richard here are is a small patch
>which
>>> builds xz compressed tarballs and diff files.
>>>
>>> Tested with
>>>
>>>   maintainer-scripts/gcc_release \
>>> -s snap:trunk -p  diffs sources tarfiles
>>>   maintainer-scripts/gcc_release \
>>> -s snap:trunk -p  diffs sources tarfiles
>>>
>>> and checked that the new tarball and diff files are compressed using
>xz.
>>>
>>> Ok for the trunk and the gcc-7-branch?
>> 
>> Ok.  The version on trunk can get the bz2 old-tar support removed
>after the next
>> snapshot generation I  think.  Likewise the branch version after 7.2
>> was released.
>
>Looks like the copy of the script on gcc.gnu.org affects all active
>branches.

Yes.  Only the trunk script is actually used, so ...

>the May 23 GCC 5 snapshot was created successfully.  Is this
>acceptable? If yes,
>then the patch should probably go to the 5 and 6 branches as well.

... This isn't really necessary.

>Please copy the script again to enable the xz --best compression.
>
>Matthias

Re: [PATCH 2/5 v3] Vect peeling cost model

[Robin Dapp]

> Not sure I've understood the series TBH, but is the npeel == vf / 2
> there specifically for the "unknown number of peels" case?  How do
> we distinguish that from the case in which the number of peels is
> known to be vf / 2 at compile time?  Or have I missed the point
> completely? (probably yes, sorry!)

Good point, that's not totally waterproof for future uses of
vect_get_peeling_costs_all_drs ().  Currently, however, only when
peeling for unknown alignment vf != 0 will be passed to it (and vf == 0
for the known alignment case), so we can distinguish the cases.

In future, the whole vf/2 handling should be improved anyway since e.g.
it is hardcoded here as well as in tree-vect-loop.c.  npeel = 0 also has
a double meaning, namely not peeling when peeling for known alignment
and peeling vf/2 iters when peeling for unknown alignment.  Room for
improvement I guess :)

Regards
 Robin

Re: [PATCH 0/5 v3] Vect peeling cost model

[Richard Biener]

On Tue, May 23, 2017 at 5:57 PM, Robin Dapp  wrote:
> The last version of the patch series caused some regressions for ppc64.
> This was largely due to incorrect handling of unsupportable alignment
> and should be fixed with the new version.
>
> p2 and p5 have not changed but I'm posting the whole series again for
> reference.  p1 only changed comment wording, p3 was adapted to apply on
> the trunk.
>
> No regressions on s390x, x86-64 and ppc64.  Bootstrapped.

So what did actually change?  I'd rather not diff the diffs.  Can you provide
an incremental change, aka p6 that would apply to the previous series instead?

Thanks,
Richard.

> Regards
>  Robin
>

Re: libgomp nvptx plugin: Debugging output for cuInit failure

[Thomas Schwinge]

Hi!

On Tue, 23 May 2017 12:41:05 +0200, Jakub Jelinek  wrote:
> On Mon, May 22, 2017 at 02:57:24PM +0200, Thomas Schwinge wrote:
> > libgomp nvptx plugin: Debugging output for cuInit failure

> Ok.

Thanks.  As posted, just with better ChangeLog committed to trunk in
r248400:

commit d5f081f8cfa23d74aec1cea4dd4ae3061c4498c8
Author: tschwinge 
Date:   Wed May 24 06:59:05 2017 +

libgomp nvptx plugin: Debugging output when disabling nvptx offloading

libgomp/
* plugin/plugin-nvptx.c (nvptx_get_num_devices): Debugging output
when disabling nvptx offloading.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@248400 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 libgomp/ChangeLog |  5 +
 libgomp/plugin/plugin-nvptx.c | 12 ++--
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git libgomp/ChangeLog libgomp/ChangeLog
index 32f8bf1..14e95ef 100644
--- libgomp/ChangeLog
+++ libgomp/ChangeLog
@@ -1,3 +1,8 @@
+2017-05-24  Thomas Schwinge  
+
+   * plugin/plugin-nvptx.c (nvptx_get_num_devices): Debugging output
+   when disabling nvptx offloading.
+
 2017-05-23  Thomas Schwinge  
 
* testsuite/libgomp.oacc-c-c++-common/kernels-loop-2.c: Update.
diff --git libgomp/plugin/plugin-nvptx.c libgomp/plugin/plugin-nvptx.c
index 3ef48dd..0e1b3e2 100644
--- libgomp/plugin/plugin-nvptx.c
+++ libgomp/plugin/plugin-nvptx.c
@@ -838,7 +838,11 @@ nvptx_get_num_devices (void)
   /* PR libgomp/65099: Currently, we only support offloading in 64-bit
  configurations.  */
   if (sizeof (void *) != 8)
-return 0;
+{
+  GOMP_PLUGIN_debug (0, "Disabling nvptx offloading;"
+" only 64-bit configurations are supported\n");
+  return 0;
+}
 
   /* This function will be called before the plugin has been initialized in
  order to enumerate available devices, but CUDA API routines can't be used
@@ -852,7 +856,11 @@ nvptx_get_num_devices (void)
   /* This is not an error: e.g. we may have CUDA libraries installed but
  no devices available.  */
   if (r != CUDA_SUCCESS)
-return 0;
+   {
+ GOMP_PLUGIN_debug (0, "Disabling nvptx offloading; cuInit: %s\n",
+cuda_error (r));
+ return 0;
+   }
 }
 
   CUDA_CALL_ERET (-1, cuDeviceGetCount, );

Committed to gomp-4_0-branch in r248401:

commit e526e3776c9995e60927d8d75e9a2b2120702f57
Author: tschwinge 
Date:   Wed May 24 07:00:04 2017 +

libgomp nvptx plugin: Debugging output when disabling nvptx offloading

libgomp/
* plugin/plugin-nvptx.c (nvptx_get_num_devices): Debugging output
when disabling nvptx offloading.

trunk r248400

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gomp-4_0-branch@248401 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 libgomp/ChangeLog.gomp|  5 +
 libgomp/plugin/plugin-nvptx.c | 12 ++--
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git libgomp/ChangeLog.gomp libgomp/ChangeLog.gomp
index 996c1f9..15e0c58 100644
--- libgomp/ChangeLog.gomp
+++ libgomp/ChangeLog.gomp
@@ -1,3 +1,8 @@
+2017-05-24  Thomas Schwinge  
+
+   * plugin/plugin-nvptx.c (nvptx_get_num_devices): Debugging output
+   when disabling nvptx offloading.
+
 2017-05-17  Thomas Schwinge  
 
* libgomp.texi (OpenACC Profiling Interface): Update.
diff --git libgomp/plugin/plugin-nvptx.c libgomp/plugin/plugin-nvptx.c
index a9d1f16..7bbaca5 100644
--- libgomp/plugin/plugin-nvptx.c
+++ libgomp/plugin/plugin-nvptx.c
@@ -807,7 +807,11 @@ nvptx_get_num_devices (void)
   /* PR libgomp/65099: Currently, we only support offloading in 64-bit
  configurations.  */
   if (sizeof (void *) != 8)
-return 0;
+{
+  GOMP_PLUGIN_debug (0, "Disabling nvptx offloading;"
+" only 64-bit configurations are supported\n");
+  return 0;
+}
 
   /* This function will be called before the plugin has been initialized in
  order to enumerate available devices, but CUDA API routines can't be used
@@ -819,7 +823,11 @@ nvptx_get_num_devices (void)
   /* This is not an error: e.g. we may have CUDA libraries installed but
  no devices available.  */
   if (r != CUDA_SUCCESS)
-return 0;
+   {
+ GOMP_PLUGIN_debug (0, "Disabling nvptx offloading; cuInit: %s\n",
+cuda_error (r));
+ return 0;
+   }
 }
 
   CUDA_CALL_ERET (-1, cuDeviceGetCount, );


Grüße
 Thomas

Re: [PATCH] Fix PR middle-end/80823, ICE: verify_flow_info failed

[Richard Biener]

On May 23, 2017 7:46:59 PM GMT+02:00, Peter Bergner  
wrote:
>The fix for PR80775 included a thinko bug that caused us to skip some
>case label statements.  This leads to problems for test cases where we
>have multiple case labels that point to the same unreachable block, but
>are not mergeable since they don't have consecutive case values.
>This leads to a problem, because we remove the unreachable block when
>handling this first case label, but then we have a dangling reference
>to that block with the skipped case label.  The fix is to remove the
>unwanted increment, so that we handle the next case label and end up
>removing it too.
>
>This passed bootstrap and regtesting on powerpc64le-linux with no
>regressions.  Is this ok for trunk?

OK.

Richard.

>Peter
>
>gcc/
>   PR middle-end/80823
>   * tree-cfg.c (group_case_labels_stmt): Delete increment of "i";
>
>gcc/testsuite/
>   PR middle-end/80823
>   * gcc.dg/pr80823.c: New test.
>
>Index: gcc/tree-cfg.c
>===
>--- gcc/tree-cfg.c (revision 248375)
>+++ gcc/tree-cfg.c (working copy)
>@@ -1726,7 +1726,6 @@ group_case_labels_stmt (gswitch *stmt)
>   remove_edge_and_dominated_blocks (base_edge);
> gimple_switch_set_label (stmt, base_index, NULL_TREE);
> new_size--;
>-i++;
>   }
> }
> 
>Index: gcc/testsuite/gcc.dg/pr80823.c
>===
>--- gcc/testsuite/gcc.dg/pr80823.c (nonexistent)
>+++ gcc/testsuite/gcc.dg/pr80823.c (working copy)
>@@ -0,0 +1,23 @@
>+/* PR middle-end/80823 ICE: verify_flow_info failed  */
>+/* { dg-do compile }  */
>+/* { dg-options "-O3" }  */
>+
>+int a, c;
>+int b[1];
>+static inline int
>+fn1() {
>+  switch (a)
>+  case 0:
>+  case 2:
>+return 1;
>+  return 0;
>+}
>+void fn2() {
>+  int i;
>+  for (;; ++i) {
>+c = b[i];
>+int d = !fn1();
>+if (d)
>+  __asm__("");
>+  }
>+}

[patch] Fix libstdc++-v3 build for Android

[Eric Botcazou]

Hi,

libstdc++-v3 already contains support but doesn't build for Android.  Now GDB 
has switched to C++, which means that you need a C++ cross-build for GDBserver 
in order to debug a program on the target.

Tested on x86_64-suse-linux and arm-linux-androideab, OK for mainline?


2017-05-24  Eric Botcazou  

* configure.ac (*-*-linux-android*): Set target_makefile_frag.
* configure: Regenerate.
config/
* mt-android: New file.
libstdc++-v3/
* src/filesystem/dir.cc (fs::_Dir::advance): Use std::exchange.

-- 
Eric BotcazouIndex: config/mt-android
===
--- config/mt-android	(revision 0)
+++ config/mt-android	(working copy)
@@ -0,0 +1 @@
+CXXFLAGS_FOR_TARGET += -D_GNU_SOURCE -fexceptions -frtti
Index: configure.ac
===
--- configure.ac	(revision 248140)
+++ configure.ac	(working copy)
@@ -2474,6 +2474,9 @@ case "${target}" in
   nios2-*-elf*)
 target_makefile_frag="config/mt-nios2-elf"
 ;;
+  *-*-linux-android*)
+target_makefile_frag="config/mt-android"
+;;
   *-*-linux* | *-*-gnu* | *-*-k*bsd*-gnu | *-*-kopensolaris*-gnu)
 target_makefile_frag="config/mt-gnu"
 ;;
Index: libstdc++-v3/src/filesystem/dir.cc
===
--- libstdc++-v3/src/filesystem/dir.cc	(revision 248140)
+++ libstdc++-v3/src/filesystem/dir.cc	(working copy)
@@ -146,7 +146,8 @@ fs::_Dir::advance(error_code* ec, direct
 
   int err = std::exchange(errno, 0);
   const auto entp = readdir(dirp);
-  std::swap(errno, err);
+  // std::swap cannot be used with Bionic's errno
+  err = std::exchange(errno, err);
 
   if (entp)
 {

[rs6000] Fix ICE with -fstack-limit-register and large frames

[Eric Botcazou]

Hi,

this fixes an internal error with -fstack-limit-register and large frames:

eric@polaris:~/build/gcc/powerpc-linux> gcc/xgcc -Bgcc -S stack-limit-1.c -
fstack-limit-register=r2
stack-limit-1.c: In function 'foo':
stack-limit-1.c:9:1: error: insn does not satisfy its constraints:
 }
 ^
(insn 21 20 22 (set (reg:SI 0 0)
(plus:SI (reg:SI 0 0)
(const_int 3968 [0xf80]))) "stack-limit-1.c":5 70 {*addsi3}
 (nil))
stack-limit-1.c:9:1: internal compiler error: in final_scan_insn, at 
final.c:2964
0xb40335 _fatal_insn(char const*, rtx_def const*, char const*, int, char 
const*)
/home/eric/svn/gcc/gcc/rtl-error.c:108
0xb4037a _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/eric/svn/gcc/gcc/rtl-error.c:119
0x83f757 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
/home/eric/svn/gcc/gcc/final.c:2964
0x83feb2 final(rtx_insn*, _IO_FILE*, int)
/home/eric/svn/gcc/gcc/final.c:2051
0x84076d rest_of_handle_final
/home/eric/svn/gcc/gcc/final.c:4489
0x84076d execute
/home/eric/svn/gcc/gcc/final.c:4562
Please submit a full bug report,

Tested on PowerPC/Linux, OK for mainline?


2017-05-24  Eric Botcazou  

* config/rs6000/rs6000.c (rs6000_emit_allocate_stack): Deal properly
with large frames if a stack limit is used.


2017-05-24  Eric Botcazou  

* gcc.target/powerpc/stack-limit-1.c: New test.

-- 
Eric BotcazouIndex: config/rs6000/rs6000.c
===
--- config/rs6000/rs6000.c	(revision 248140)
+++ config/rs6000/rs6000.c	(working copy)
@@ -28372,7 +28372,21 @@ rs6000_emit_allocate_stack (HOST_WIDE_IN
 	  && REGNO (stack_limit_rtx) > 1
 	  && REGNO (stack_limit_rtx) <= 31)
 	{
-	  emit_insn (gen_add3_insn (tmp_reg, stack_limit_rtx, GEN_INT (size)));
+	  rtx cst = GEN_INT (size);
+
+	  /* The add expander doesn't correctly handle r0.  */
+	  if (satisfies_constraint_I (cst))
+	emit_insn (gen_rtx_SET (tmp_reg,
+gen_rtx_PLUS (Pmode, stack_limit_rtx,
+		  cst)));
+	  else
+	{
+	  emit_move_insn (tmp_reg, cst);
+	  emit_insn (gen_rtx_SET (tmp_reg,
+  gen_rtx_PLUS (Pmode, stack_limit_rtx,
+		tmp_reg)));
+	}
+
 	  emit_insn (gen_cond_trap (LTU, stack_reg, tmp_reg,
 const0_rtx));
 	}
/* { dg-do compile } */
/* { dg-options "-fstack-limit-register=r2" } */

int foo (int i)
{
  char arr[135000];

  arr[i] = 0;
}

Re: Allow some NOP conversions in (X+CST1)+CST2 in match.pd

[Richard Biener]

On Sun, May 21, 2017 at 9:22 PM, Marc Glisse  wrote:
> Hello,
>
> generalizing a bit one transformation, to avoid a regression with another
> patch I am working on. Handling conversions always gets messy :-( It would
> have been easier to stick to scalars and wide_int, but since the existing
> transformation handles vectors, I didn't want to regress.

The pattern looks a bit unwieldly now ;)  I pondered a bit but
couldn't really find
a better way to handle things.

Thus, ok.

Richard.


> Bootstrap+testsuite on powerpc64le-unknown-linux-gnu.
>
> 2017-05-22  Marc Glisse  
>
> gcc/
> * match.pd ((A +- CST1) +- CST2): Allow some conversions.
> * tree.c (drop_tree_overflow): Handle COMPLEX_CST and VECTOR_CST.
>
> gcc/testsuite/
> * gcc.dg/tree-ssa/addadd.c: New file.
>
> --
> Marc Glisse

Re: Ipa function summary pass

[Christophe Lyon]

Hi,

On 23 May 2017 at 18:23, Jan Hubicka  wrote:
> Hi,
> this patch finishes the breakup of ipa-inline and function analysis.
> The analysis is now done by separate pass and I will work on cleaning
> up the interfaces now.
>
> Honza
>
> * cgraphunit.c (symbol_table::process_new_functions): Update.
> * ipa-fnsummary.c (pass_data_inline_parameters): Remove.
> (inline_generate_summary): Rename to ...
> (ipa_fn_summary_generate): ... this one.
> (inline_read_summary): Rename to ...
> (ipa_fn_summary_read): ... this one.
> (inline_write_summary): Rename to ...
> (ipa_fn_summary_write): ... this one.
> (inline_free_summary): Rename to ...
> (ipa_free_fn_summary): ... this one.
> (pass_data_local_fn_summary, pass_local_fn_summary,
> make_pass_local_fn_summary, pass_data_ipa_free_fn_summary,
> pass_ipa_free_fn_summary, make_pass_ipa_free_fn_summary,
> pass_data_ipa_fn_summary, pass_ipa_fn_summary,
> make_pass_ipa_fn_summary): New.
> * ipa-fnsummary.h (inline_generate_summary, inline_read_summary,
> inline_write_summary, inline_free_summary): Remove.
> (ipa_free_fn_summary) : New.
> * ipa-inline.c (ipa_inline): Update.
> (pass_ipa_inline): Do not generate summaries.
> * ipa.c (pass_data_ipa_free_fn_summary, pass_ipa_free_fn_summary):
> Remove.
> * passes.def: Replace pass_inline_parameters by pass_local_fn_summary
> and add pass_ipa_fn_summary.
> * tree-pass.h (make_pass_ipa_fn_summary, make_pass_local_fn_summary):
> New.
> (make_pass_inline_parameters): Remove.
>
> * lto.c (do_whole_program_analysis): Replace inline_free_summary
> by ipa_free_fn_summary.
>
> * gcc.dg/ipa/ctor-empty-1.c: Update template.
> * gcc.dg/ipa/inline-5.c: Likewise.
> * gfortran.dg/pr48636.f90: Likewise.
> Index: cgraphunit.c
> ===
> --- cgraphunit.c(revision 248365)
> +++ cgraphunit.c(working copy)
> @@ -339,7 +339,7 @@ symbol_table::process_new_functions (voi
>  and splitting.  This is redundant for functions added late.
>  Just throw away whatever it did.  */
>   if (!summaried_computed)
> -   inline_free_summary ();
> +   ipa_free_fn_summary ();
> }
>   else if (ipa_fn_summaries != NULL)
> compute_fn_summary (node, true);
> Index: ipa-fnsummary.c
> ===
> --- ipa-fnsummary.c (revision 248366)
> +++ ipa-fnsummary.c (working copy)
> @@ -2504,46 +2504,6 @@ compute_fn_summary_for_current (void)
>return 0;
>  }
>
> -namespace {
> -
> -const pass_data pass_data_inline_parameters =
> -{
> -  GIMPLE_PASS, /* type */
> -  "inline_param", /* name */
> -  OPTGROUP_INLINE, /* optinfo_flags */
> -  TV_INLINE_PARAMETERS, /* tv_id */
> -  0, /* properties_required */
> -  0, /* properties_provided */
> -  0, /* properties_destroyed */
> -  0, /* todo_flags_start */
> -  0, /* todo_flags_finish */
> -};
> -
> -class pass_inline_parameters : public gimple_opt_pass
> -{
> -public:
> -  pass_inline_parameters (gcc::context *ctxt)
> -: gimple_opt_pass (pass_data_inline_parameters, ctxt)
> -  {}
> -
> -  /* opt_pass methods: */
> -  opt_pass * clone () { return new pass_inline_parameters (m_ctxt); }
> -  virtual unsigned int execute (function *)
> -{
> -  return compute_fn_summary_for_current ();
> -}
> -
> -}; // class pass_inline_parameters
> -
> -} // anon namespace
> -
> -gimple_opt_pass *
> -make_pass_inline_parameters (gcc::context *ctxt)
> -{
> -  return new pass_inline_parameters (ctxt);
> -}
> -
> -
>  /* Estimate benefit devirtualizing indirect edge IE, provided KNOWN_VALS,
> KNOWN_CONTEXTS and KNOWN_AGGS.  */
>
> @@ -3207,8 +3167,8 @@ ipa_fn_summary_t::insert (struct cgraph_
>
>  /* Note function body size.  */
>
> -void
> -inline_generate_summary (void)
> +static void
> +ipa_fn_summary_generate (void)
>  {
>struct cgraph_node *node;
>
> @@ -3226,7 +3186,7 @@ inline_generate_summary (void)
>ipa_fn_summaries->enable_insertion_hook ();
>
>ipa_register_cgraph_hooks ();
> -  inline_free_summary ();
> +  ipa_free_fn_summary ();
>
>FOR_EACH_DEFINED_FUNCTION (node)
>  if (!node->alias)
> @@ -3358,8 +3318,8 @@ inline_read_section (struct lto_file_dec
> and inliner, so when ipa-cp is active, we don't need to write them
> twice.  */
>
> -void
> -inline_read_summary (void)
> +static void
> +ipa_fn_summary_read (void)
>  {
>struct lto_file_decl_data **file_data_vec = lto_get_file_decl_data ();
>struct lto_file_decl_data *file_data;
> @@ -3419,8 +3379,8 @@ write_ipa_call_summary (struct output_bl
> Jump functions are shared among ipa-cp and inliner, so when ipa-cp is
> active, 

Re: signed multiplication for pointer offsets

[Richard Biener]

On Sun, May 21, 2017 at 9:45 PM, Marc Glisse  wrote:
> Hello,
>
> when we have a double*p, computing p+n, we multiply n by 8 (size of double)
> then add it to p. According to the comment just below the modified lines in
> the attached patch, the multiplication is supposed to happen in a signed
> type. However, that does not match the current code which uses sizetype.
> This is causing missed optimizations, for instance, when comparing p+m and
> p+n, we might end up comparing 8*m to 8*n, which is not the same as
> comparing m and n if overflow can happen.
>
> I tried this patch to see how much breaks. And actually, not that much does.
> There are a few fragile testcases that want to match "q_. " but it is now
> "q_10 ", or they expect 3 simplifications and get 5 (same final code). One
> was confused by a cast in the middle of x+cst1+cst2. A couple were hit by
> the lack of CSE between (x+1)*8, x*8+8, and some variants with casts in the
> middle, but that's already an issue without the patch. A few vectorization
> testcases failed because SCEV did not recognize a simple increment of a
> variable with NOP casts in the middle, that would be worth fixing. The patch
> actually fixed another vectorization testcase.
>
> I guess it would help if pointer_plus switched to a signed second argument,
> to be consistent with this and reduce the number of casts.

Yes.  In fact the pointer-plus offset is to be interpreted as signed anyway
so that it uses unsigned sizetype was a bad decision back in time.  Bin
tried to fix this last year but I'm not sure what came of his experiments.

> I am not proposing the patch as is, but is this the direction we want to
> follow, or should I just fix the comment to match what the code does?

I think I tried this at some point and I don't remember the result.  I did that
in the context of the even more ambitious attempt to make pointer-plus
take either sizetype or ssizetype typed offsets...

The standard doesn't actually talk about what type to perform the multiplication
in but given we effectively restrict objects to the size of half of
the address space
due to ptrdiff_t limitations using either a signed or unsigned type should work.

Richard.

> --
> Marc Glisse