New Swedish PO file for 'gcc' (version 7.1-b20170101)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

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

http://translationproject.org/latest/gcc/sv.po

(This file, 'gcc-7.1-b20170101.sv.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

http://translationproject.org/latest/gcc/

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

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

The following HTML page has been updated:

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

If any question arises, please contact the translation coordinator.

Thank you for all your work,

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

[SPARC] Fix PR target/79353

[Eric Botcazou]

This is a regression introduced on the mainline by the switch to LRA because 
of a couple of left-over U constraints in config/sparc/sync.md.

Bootstrapped/regtested on SPARC/Solaris, applied on the mainline.


2017-02-05  Eric Botcazou  

PR target/79353
* config/sparc/sync.md (atomic_loaddi_1): Replace 'U' constraint with
'r', 'm' constraint with 'T' and !TARGET_ARCH64 with TARGET_ARCH32.
(atomic_storedi_1): Likewise.


2017-02-05  Eric Botcazou  

* gcc.target/sparc/20170205-1.c: New test.

-- 
Eric Botcazou/* PR target/79363 */
/* Reported by John Paul Adrian Glaubitz  */

/* { dg-do compile } */
/* { dg-options "-O2 -fPIC -mcpu=v8" } */

struct d { long long h; };

struct c { struct d *e; };

int f, g;

extern void bar (long long *);
extern int baz (long long *, int);

void foo (struct c *desc)
{
  int begin, end, j;
  long long k, l, h;
  for (;;) {
for (;;)
  break;
for (;;) {
  j++;
  l = desc->e[j].h;
  for (;;) {
bar(&l);
end = h = begin / 2;
if (baz(&h, g))
  begin = f;
break;
  }
  if (end) {
__atomic_store_n(&k, end, 5);
break;
  }
}
  }
}
Index: config/sparc/sync.md
===
--- config/sparc/sync.md	(revision 245124)
+++ config/sparc/sync.md	(working copy)
@@ -133,10 +133,10 @@ (define_expand "atomic_load"
 })
 
 (define_insn "atomic_loaddi_1"
-  [(set (match_operand:DI 0 "register_operand" "=U,?*f")
-	(unspec:DI [(match_operand:DI 1 "memory_operand" "m,m")]
+  [(set (match_operand:DI 0 "register_operand" "=r,?*f")
+	(unspec:DI [(match_operand:DI 1 "memory_operand" "T,T")]
 		   UNSPEC_ATOMIC))]
-  "!TARGET_ARCH64"
+  "TARGET_ARCH32"
   "ldd\t%1, %0"
   [(set_attr "type" "load,fpload")])
 
@@ -160,11 +160,11 @@ (define_expand "atomic_store"
 })
 
 (define_insn "atomic_storedi_1"
-  [(set (match_operand:DI 0 "memory_operand" "=m,m,m")
+  [(set (match_operand:DI 0 "memory_operand" "=T,T,T")
 	(unspec:DI
-	  [(match_operand:DI 1 "register_or_v9_zero_operand" "J,U,?*f")]
+	  [(match_operand:DI 1 "register_or_v9_zero_operand" "J,r,?*f")]
 	  UNSPEC_ATOMIC))]
-  "!TARGET_ARCH64"
+  "TARGET_ARCH32"
   "@
stx\t%r1, %0
std\t%1, %0

Re: [doc] extend.texi - "lock critical sections"?

[Gerald Pfeifer]

On Thu, 2 Feb 2017, Andi Kleen wrote:
> The patch is ok.  Lock critical region isn't a special term.

Thanks, Andi!  Below the ChangeLog and patch I committed.

Gerald

2017-02-05  Gerald Pfeifer  

* doc/extend.texi (x86 specific memory model extensions for
transactional memory): Simplify a phrase.

Index: doc/extend.texi
===
--- doc/extend.texi (revision 245188)
+++ doc/extend.texi (working copy)
@@ -10103,7 +10103,7 @@
 @section x86-Specific Memory Model Extensions for Transactional Memory
 
 The x86 architecture supports additional memory ordering flags
-to mark lock critical sections for hardware lock elision. 
+to mark critical sections for hardware lock elision. 
 These must be specified in addition to an existing memory order to
 atomic intrinsics.
 

Re: [wwwdocs] Consistently use "testsuite"

[Gerald Pfeifer]

On Fri, 3 Feb 2017, Gerald Pfeifer wrote:
> And now a recursive grep.

And here the buildstat.html pages since GCC 3.0.  Copy&paste all
over the place. ;-)

Applied.

Gerald

Index: gcc-3.0/buildstat.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-3.0/buildstat.html,v
retrieving revision 1.155
diff -u -r1.155 buildstat.html
--- gcc-3.0/buildstat.html  28 Jun 2014 11:59:43 -  1.155
+++ gcc-3.0/buildstat.html  5 Feb 2017 11:11:01 -
@@ -11,7 +11,7 @@
 archived mail messages that reported the builds and to test result
 summaries.
 
-Instructions for running the test suite and for submitting test results
+Instructions for running the testsuite and for submitting test results
 are part of
 https://gcc.gnu.org/install/test.html";>
 Installing GCC: Testing.
Index: gcc-3.1/buildstat.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-3.1/buildstat.html,v
retrieving revision 1.44
diff -u -r1.44 buildstat.html
--- gcc-3.1/buildstat.html  28 Jun 2014 11:59:43 -  1.44
+++ gcc-3.1/buildstat.html  5 Feb 2017 11:11:01 -
@@ -11,7 +11,7 @@
 archived mail messages that reported the builds and to test result
 summaries.
 
-Instructions for running the test suite and for submitting test results
+Instructions for running the testsuite and for submitting test results
 are part of
 https://gcc.gnu.org/install/test.html";>
 Installing GCC: Testing.
Index: gcc-3.2/buildstat.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-3.2/buildstat.html,v
retrieving revision 1.79
diff -u -r1.79 buildstat.html
--- gcc-3.2/buildstat.html  28 Jun 2014 11:59:43 -  1.79
+++ gcc-3.2/buildstat.html  5 Feb 2017 11:11:01 -
@@ -11,7 +11,7 @@
 archived mail messages that reported the builds and to test result
 summaries.
 
-Instructions for running the test suite and for submitting test results
+Instructions for running the testsuite and for submitting test results
 are part of
 https://gcc.gnu.org/install/test.html";>
 Installing GCC: Testing.
Index: gcc-3.3/buildstat.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-3.3/buildstat.html,v
retrieving revision 1.56
diff -u -r1.56 buildstat.html
--- gcc-3.3/buildstat.html  28 Jun 2014 11:59:43 -  1.56
+++ gcc-3.3/buildstat.html  5 Feb 2017 11:11:02 -
@@ -11,7 +11,7 @@
 archived mail messages that reported the builds and to test result
 summaries.
 
-Instructions for running the test suite and for submitting test results
+Instructions for running the testsuite and for submitting test results
 are part of
 https://gcc.gnu.org/install/test.html";>
 Installing GCC: Testing.
Index: gcc-3.4/buildstat.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-3.4/buildstat.html,v
retrieving revision 1.35
diff -u -r1.35 buildstat.html
--- gcc-3.4/buildstat.html  28 Jun 2014 11:59:43 -  1.35
+++ gcc-3.4/buildstat.html  5 Feb 2017 11:11:02 -
@@ -11,7 +11,7 @@
 archived mail messages that reported the builds and to test result
 summaries.
 
-Instructions for running the test suite and for submitting test results
+Instructions for running the testsuite and for submitting test results
 are part of
 https://gcc.gnu.org/install/test.html";>
 Installing GCC: Testing.
Index: gcc-4.0/buildstat.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.0/buildstat.html,v
retrieving revision 1.31
diff -u -r1.31 buildstat.html
--- gcc-4.0/buildstat.html  28 Jun 2014 11:59:43 -  1.31
+++ gcc-4.0/buildstat.html  5 Feb 2017 11:11:02 -
@@ -11,7 +11,7 @@
 archived mail messages that reported the builds and to test result
 summaries.
 
-Instructions for running the test suite and for submitting test results
+Instructions for running the testsuite and for submitting test results
 are part of
 https://gcc.gnu.org/install/test.html";>
 Installing GCC: Testing.
Index: gcc-4.1/buildstat.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.1/buildstat.html,v
retrieving revision 1.18
diff -u -r1.18 buildstat.html
--- gcc-4.1/buildstat.html  28 Jun 2014 11:59:43 -  1.18
+++ gcc-4.1/buildstat.html  5 Feb 2017 11:11:02 -
@@ -11,7 +11,7 @@
 archived mail messages that reported the builds and to test result
 summaries.
 
-Instructions for running the test suite and for submitting test results
+Instructions for running the testsuite and for submitting test results
 are part of
 https://gcc.gnu.org/install/test.html";>
 Installing GCC: Testing.
Index: gcc-4.2/buildstat.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.2/buildstat.html,v
retrievin

MAINTAINERS: remove redundant entry

[Gerald Pfeifer]

2017-02-05  Gerald Pfeifer  

* MAINTAINERS (Write After Approval): Remove redundant entry
for Andrew Burgess.

Applied.  (Andrew is also listed as a reviewer.)

Gerald

Index: MAINTAINERS
===
--- MAINTAINERS (revision 245189)
+++ MAINTAINERS (working copy)
@@ -338,7 +338,6 @@
 Christian Bruel
 Iain Buclaw
 Kevin Buettner 
-Andrew Burgess 
 Adam Butcher   
 Andrew Cagney  
 Daniel Carrera 

Re: [PATCH, Fortran, pr79230, v1] [7 Regression] [OOP] Run time error: double free or corruption

[Andre Vehreschild]

Hi Paul,

thanks for the review. Committed as r245191.

Regards,
Andre

On Sat, 4 Feb 2017 17:03:25 +
Paul Richard Thomas  wrote:

> Hi Andre,
> 
> This looks fine to me - OK for trunk.
> 
> Thanks
> 
> Paul
> 
> On 4 February 2017 at 11:59, Andre Vehreschild  wrote:
> > Hi all,
> >
> > attached patch fixes a regression when a polymorphic pointer component was
> > present. The results was a double free. The attached patch fixes this, by
> > not caring about freeing pointer components as part of gfortran's memory
> > management, i.e., the programmer has to take care about
> > freeing/disassociating the pointer using a finalizer, as is IMO the
> > intention of the Fortran standard.
> >
> > Bootstrapped and regtested ok on x86_64-linux/f25. Ok for trunk (current or
> > next, haven't monitored whether commits are still allowed)?
> >
> > Regards,
> > Andre
> > --
> > Andre Vehreschild * Email: vehre ad gmx dot de  
> 
> 
> 


-- 
Andre Vehreschild * Email: vehre ad gmx dot de 
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog	(Revision 245190)
+++ gcc/fortran/ChangeLog	(Arbeitskopie)
@@ -1,3 +1,9 @@
+2017-02-05  Andre Vehreschild  
+
+	PR fortran/79230
+	* trans-array.c (structure_alloc_comps): Ignore pointer components when
+	freeing structures.
+
 2017-01-25  Maxim Ostapenko  
 
 	PR lto/79061
Index: gcc/fortran/trans-array.c
===
--- gcc/fortran/trans-array.c	(Revision 245190)
+++ gcc/fortran/trans-array.c	(Arbeitskopie)
@@ -8220,9 +8220,17 @@
 
 	  /* Shortcut to get the attributes of the component.  */
 	  if (c->ts.type == BT_CLASS)
-	attr = &CLASS_DATA (c)->attr;
+	{
+	  attr = &CLASS_DATA (c)->attr;
+	  if (attr->class_pointer)
+		continue;
+	}
 	  else
-	attr = &c->attr;
+	{
+	  attr = &c->attr;
+	  if (attr->pointer)
+		continue;
+	}
 
 	  if ((c->ts.type == BT_DERIVED && !c->attr.pointer)
 	 || (c->ts.type == BT_CLASS && !CLASS_DATA (c)->attr.class_pointer))
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog	(Revision 245190)
+++ gcc/testsuite/ChangeLog	(Arbeitskopie)
@@ -1,3 +1,8 @@
+2017-02-05  Andre Vehreschild  
+
+	PR fortran/79230
+	* gfortran.dg/der_ptr_component_2.f90: New test.
+
 2017-02-05  Eric Botcazou  
 
 	* gcc.target/sparc/20170205-1.c: New test.
Index: gcc/testsuite/gfortran.dg/der_ptr_component_2.f90
===
--- gcc/testsuite/gfortran.dg/der_ptr_component_2.f90	(nicht existent)
+++ gcc/testsuite/gfortran.dg/der_ptr_component_2.f90	(Arbeitskopie)
@@ -0,0 +1,30 @@
+! { dg-do run }
+!
+! Freeing the width_data lead to double free. This testcase tests that
+! pr79230 is fixed now.
+
+program main_ut
+  implicit none
+
+  type :: data_t
+ character, allocatable :: c1
+  end type
+
+  type :: t1_t
+ character, allocatable :: c2
+ class(data_t), pointer :: width_data
+  end type
+
+  call evaluator
+
+contains
+
+  subroutine evaluator
+type(data_t), target :: par_real
+type(t1_t) :: field
+field%width_data => par_real
+  end subroutine
+
+end
+
+

Re: [PATCH, Fortran, pr78958, v1] Unallocated memory access after SOURCE-ALLOCATEing unlimited polymorphic object

[Andre Vehreschild]

Hi Paul,

thanks for the review. Committed as r245192.

Regards,
Andre

On Sat, 4 Feb 2017 17:07:13 +
Paul Richard Thomas  wrote:

> Hi Andre,
> 
> This looks to be OK for trunk.
> 
> Thanks for the patch.
> 
> Paul
> 
> On 4 February 2017 at 13:11, Andre Vehreschild  wrote:
> > Hi all,
> >
> > attached patch takes the _len-component of unlimited polymorphic objects
> > into account, when source-ALLOCATEing an unlimited polymorphic object. The
> > testcase for this gcc/testsuite/gfortran.dg/alloc_comp_class_5.f03 with
> > valgrind/sanitizer. I therefore added no additional testcase.
> >
> > Bootstraps and regtests ok on x86_64-linux/f25 and as reported in the PR on
> > 32bit-hpux. Ok for trunk (when?)?
> >
> > Regards,
> > Andre
> > --
> > Andre Vehreschild * Email: vehre ad gmx dot de  
> 
> 
> 


-- 
Andre Vehreschild * Email: vehre ad gmx dot de 
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog	(Revision 245191)
+++ gcc/fortran/ChangeLog	(Arbeitskopie)
@@ -1,5 +1,11 @@
 2017-02-05  Andre Vehreschild  
 
+	PR fortran/78958
+	* trans-stmt.c (gfc_trans_allocate): Add the multiplying the _len
+	component of unlimited polymorphic objects when source-allocating.
+
+2017-02-05  Andre Vehreschild  
+
 	PR fortran/79230
 	* trans-array.c (structure_alloc_comps): Ignore pointer components when
 	freeing structures.
Index: gcc/fortran/trans-stmt.c
===
--- gcc/fortran/trans-stmt.c	(Revision 245191)
+++ gcc/fortran/trans-stmt.c	(Arbeitskopie)
@@ -6009,14 +6009,21 @@
 	 needs to be provided, which is done most of the time by the
 	 pre-evaluation step.  */
   nelems = NULL_TREE;
-  if (expr3_len && code->expr3->ts.type == BT_CHARACTER)
-	/* When al is an array, then the element size for each element
-	   in the array is needed, which is the product of the len and
-	   esize for char arrays.  */
-	tmp = fold_build2_loc (input_location, MULT_EXPR,
-			   TREE_TYPE (expr3_esize), expr3_esize,
-			   fold_convert (TREE_TYPE (expr3_esize),
-	 expr3_len));
+  if (expr3_len && (code->expr3->ts.type == BT_CHARACTER
+			|| code->expr3->ts.type == BT_CLASS))
+	{
+	  /* When al is an array, then the element size for each element
+	 in the array is needed, which is the product of the len and
+	 esize for char arrays.  For unlimited polymorphics len can be
+	 zero, therefore take the maximum of len and one.  */
+	  tmp = fold_build2_loc (input_location, MAX_EXPR,
+ TREE_TYPE (expr3_len),
+ expr3_len, fold_convert (TREE_TYPE (expr3_len),
+			  integer_one_node));
+	  tmp = fold_build2_loc (input_location, MULT_EXPR,
+ TREE_TYPE (expr3_esize), expr3_esize,
+ fold_convert (TREE_TYPE (expr3_esize), tmp));
+	}
   else
 	tmp = expr3_esize;
   if (!gfc_array_allocate (&se, expr, stat, errmsg, errlen,

Re: [PATCH, Fortran, pr79335, v1] [7 Regression] Conditional jump or move depends on uninitialised in value get_scalar_to_descriptor_type(tree_node*, symbol_attribute) (trans-expr.c:53)

[Andre Vehreschild]

Hi Paul,

and the last one committed as r245193. Thanks again for the reviews.

Regards,
Andre

On Sat, 4 Feb 2017 17:16:56 +
Paul Richard Thomas  wrote:

> Hi Andre,
> 
> This is getting to be a bit monotonous :-) OK for trunk.
> 
> Thanks for the three patches.
> 
> Paul
> 
> PS Are you in a position to have a stab at PR79344? This would go a
> long way to sorting out Juergen's test suite. Also, this must be the
> third time that I have been involved in breaking iso_varying_string
> and I think that others have too :-( We must start running the
> testsuite on a regular basis. Unfortunately, it lacks a harness to run
> all the tests automatically.
> 
> PPS I am some days away yet from recovering from my move from France
> to the UK and so would defer to you if you can come up with a fix.
> 
> On 4 February 2017 at 13:39, Andre Vehreschild  wrote:
> > Hi all,
> >
> > attached patch fixes the access of uninitialized data. Thanks Martin for
> > analyzing this so far. The symbol_attributes on the stack was used
> > without initializing it from the symbol's attributes.
> >
> > Bootstraps and regstests ok on x86_64-linux-gnu/f25. Ok for trunk?
> >
> > Regards,
> > Andre
> > --
> > Andre Vehreschild * Email: vehre ad gmx dot de  
> 
> 
> 


-- 
Andre Vehreschild * Email: vehre ad gmx dot de 
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog	(Revision 245192)
+++ gcc/fortran/ChangeLog	(Arbeitskopie)
@@ -1,5 +1,11 @@
 2017-02-05  Andre Vehreschild  
 
+	PR fortran/79335
+	* trans-decl.c (generate_coarray_sym_init): Retrieve the symbol's
+	attributes before using them.
+
+2017-02-05  Andre Vehreschild  
+
 	PR fortran/78958
 	* trans-stmt.c (gfc_trans_allocate): Add the multiplying the _len
 	component of unlimited polymorphic objects when source-allocating.
Index: gcc/fortran/trans-decl.c
===
--- gcc/fortran/trans-decl.c	(Revision 245191)
+++ gcc/fortran/trans-decl.c	(Arbeitskopie)
@@ -5128,6 +5128,16 @@
   else
 reg_type = GFC_CAF_COARRAY_STATIC;
 
+  /* Compile the symbol attribute.  */
+  if (sym->ts.type == BT_CLASS)
+{
+  attr = CLASS_DATA (sym)->attr;
+  /* The pointer attribute is always set on classes, overwrite it with the
+	 class_pointer attribute, which denotes the pointer for classes.  */
+  attr.pointer = attr.class_pointer;
+}
+  else
+attr = sym->attr;
   gfc_init_se (&se, NULL);
   desc = gfc_conv_scalar_to_descriptor (&se, decl, attr);
   gfc_add_block_to_block (&caf_init_block, &se.pre);

Re: [PATCH, Fortran, pr79344, v1] [7 Regression] segmentation faults and run-time errors

[Mikael Morin]

Le 04/02/2017 à 19:43, Andre Vehreschild a écrit :

Hi all,

attached patch fixes the issue of losing the data in the SOURCE= expression of
an ALLOCATE() when the source-expression is just a simple variable. The issue
was that internally a temporary variable was created, whose components were
freed afterwards. Now the components are only freed on temporary objects, i.e.,
when the source-expression is not an EXPR_VARIABLE, e.g. an EXPR_STRUCTURE or
EXPR_FUNCTION.

Bootstraps and regtests ok on x86_64-linux/f25. Ok for trunk?


Hello,

this looks good to me.
Thanks

Mikael

Re: [PATCH, Fortran, pr79344, v1] [7 Regression] segmentation faults and run-time errors

[Andre Vehreschild]

Hi Mikael,

thanks for the fast review. Committed as r245193.

Regards,
Andre

On Sun, 5 Feb 2017 15:32:25 +0100
Mikael Morin  wrote:

> Le 04/02/2017 à 19:43, Andre Vehreschild a écrit :
> > Hi all,
> >
> > attached patch fixes the issue of losing the data in the SOURCE= expression
> > of an ALLOCATE() when the source-expression is just a simple variable. The
> > issue was that internally a temporary variable was created, whose
> > components were freed afterwards. Now the components are only freed on
> > temporary objects, i.e., when the source-expression is not an
> > EXPR_VARIABLE, e.g. an EXPR_STRUCTURE or EXPR_FUNCTION.
> >
> > Bootstraps and regtests ok on x86_64-linux/f25. Ok for trunk?
> >  
> Hello,
> 
> this looks good to me.
> Thanks
> 
> Mikael
> 


-- 
Andre Vehreschild * Email: vehre ad gmx dot de 
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog	(Revision 245193)
+++ gcc/testsuite/ChangeLog	(Arbeitskopie)
@@ -1,5 +1,10 @@
 2017-02-05  Andre Vehreschild  
 
+	PR fortran/79344
+	* gfortran.dg/allocate_with_source_24.f90: New test.
+
+2017-02-05  Andre Vehreschild  
+
 	PR fortran/79230
 	* gfortran.dg/der_ptr_component_2.f90: New test.
 
Index: gcc/testsuite/gfortran.dg/allocate_with_source_24.f90
===
--- gcc/testsuite/gfortran.dg/allocate_with_source_24.f90	(nicht existent)
+++ gcc/testsuite/gfortran.dg/allocate_with_source_24.f90	(Revision 245194)
@@ -0,0 +1,134 @@
+! { dg-do run }
+!
+! Test that the temporary in a sourced-ALLOCATE is not freeed.
+! PR fortran/79344
+! Contributed by Juergen Reuter
+
+module iso_varying_string
+  implicit none
+
+  type, public :: varying_string
+ private
+ character(LEN=1), dimension(:), allocatable :: chars
+  end type varying_string
+
+  interface assignment(=)
+ module procedure op_assign_VS_CH
+  end interface assignment(=)
+
+  interface operator(/=)
+ module procedure op_not_equal_VS_CA
+  end interface operator(/=)
+
+  interface len
+ module procedure len_
+  end interface len
+
+  interface var_str
+ module procedure var_str_
+  end interface var_str
+
+  public :: assignment(=)
+  public :: operator(/=)
+  public :: len
+
+  private :: op_assign_VS_CH
+  private :: op_not_equal_VS_CA
+  private :: char_auto
+  private :: len_
+  private :: var_str_
+
+contains
+
+  elemental function len_ (string) result (length)
+type(varying_string), intent(in) :: string
+integer  :: length
+if(ALLOCATED(string%chars)) then
+   length = SIZE(string%chars)
+else
+   length = 0
+endif
+  end function len_
+
+  elemental subroutine op_assign_VS_CH (var, exp)
+type(varying_string), intent(out) :: var
+character(LEN=*), intent(in)  :: exp
+var = var_str(exp)
+  end subroutine op_assign_VS_CH
+
+  pure function op_not_equal_VS_CA (var, exp) result(res)
+type(varying_string), intent(in) :: var
+character(LEN=*), intent(in) :: exp
+logical :: res
+integer :: i
+res = .true.
+if (len(exp) /= size(var%chars)) return
+do i = 1, size(var%chars)
+  if (var%chars(i) /= exp(i:i)) return
+end do
+res = .false.
+  end function op_not_equal_VS_CA
+
+  pure function char_auto (string) result (char_string)
+type(varying_string), intent(in) :: string
+character(LEN=len(string))   :: char_string
+integer  :: i_char
+forall(i_char = 1:len(string))
+   char_string(i_char:i_char) = string%chars(i_char)
+end forall
+  end function char_auto
+
+  elemental function var_str_ (char) result (string)
+character(LEN=*), intent(in) :: char
+type(varying_string) :: string
+integer  :: length
+integer  :: i_char
+length = LEN(char)
+ALLOCATE(string%chars(length))
+forall(i_char = 1:length)
+   string%chars(i_char) = char(i_char:i_char)
+end forall
+  end function var_str_
+
+end module iso_varying_string
+
+!
+ 
+program test_pr79344
+
+  use iso_varying_string, string_t => varying_string
+
+  implicit none
+
+  type :: field_data_t
+ type(string_t), dimension(:), allocatable :: name
+  end type field_data_t
+
+  type(field_data_t) :: model, model2
+  allocate(model%name(2))
+  model%name(1) = "foo"
+  model%name(2) = "bar"
+  call copy(model, model2)
+contains
+
+  subroutine copy(prt, prt_src)
+implicit none
+type(field_data_t), intent(inout) :: prt
+type(field_data_t), intent(in) :: prt_src
+integer :: i
+if (allocated (prt_src%name)) then
+   if (prt_src%name(1) /= "foo") call abort()
+   if (prt_src%name(2) /= "bar") call abort()
+
+   if (allocated (prt%name))  deallocate (prt%name)
+   allocate (prt%name (size (prt_src%name)), source = prt_src%name)
+   ! The issue was, that prt_src was empty after sourced-allocate.
+   if

Re: [PATCH] Fix PGO bootstrap on x390x (PR bootstrap/78985).

[Jeff Law]

On 02/01/2017 04:55 AM, Jakub Jelinek wrote:

On Wed, Feb 01, 2017 at 12:52:16PM +0100, Martin Liška wrote:

On 02/01/2017 11:38 AM, Jakub Jelinek wrote:

On Wed, Feb 01, 2017 at 11:34:48AM +0100, Martin Liška wrote:

Presumably the issue with print_operand_address is that there are paths where 
s390_decompose_address can return without initializing AD/OUT. But AFAICT those 
are invalid addresses that presumably shouldn't be showing up in 
print_operand_address.

Can you add an assert in print_operand_address to ensure decomposition never 
returns false?


Can't it happen e.g. with inline asm and "X" constraint?
output_operand_lossage then would emit an error rather than ICE for
something that is a user code bug, not internal compiler error.


Ok, thus said I'll commit the original version.
Is it fine?


Fine with me, but let Jeff chime in if he disagrees.
Sorry, didn't realize this stalled on me.  Let's go with the original 
patch, which I just installed for Martin as penance for slowing this 
down :-)


jeff

Re: [PATCH/AARCH64] Fix ThunderX core definition

[James Greenhalgh]

On Fri, Feb 03, 2017 at 01:10:36PM -0800, Andrew Pinski wrote:
> Hi,
>   It turns out due to a hardware issue, LSE support is turned off.
> This patch updates the thunderx cores to disable LSE and 8.1 where as
> needed.

With this, do we want to back out the rest of the "variant" support that
you added to the -mcpu=native detection?

I'd expect this code to now be dead, and posisbly stay dead. As we only added
it for GCC 7 I don't think losing it again would be a big loss. I realise
that makes this patch a bit larger, but it seems like it would lead to a
more maintainable port. Outside of merge conflicts in aarch64-cores.def, I'd
guess a revert would be fairly painless.

What do you think?

Thanks,
James

> 
> OK?  Bootstrapped and tested on aarch64-linux-gnu with no regressions.
> 
> Thanks,
> Andrew Pinski
> 
> ChangeLog:
> * config/aarch64/aarch64-cores.def (thunderx): Disable LSE.
> (thunderxt88): Likewise.
> (thunderxt81): Disable LSE and change v8.1 to v8.
> (thunderxt83): Likewise.

> Index: config/aarch64/aarch64-cores.def
> ===
> --- config/aarch64/aarch64-cores.def  (revision 244077)
> +++ config/aarch64/aarch64-cores.def  (working copy)
> @@ -60,13 +60,13 @@ AARCH64_CORE("falkor",  falkor,c
>  AARCH64_CORE("qdf24xx", qdf24xx,   cortexa57, 8A,  AARCH64_FL_FOR_ARCH8 
> | AARCH64_FL_CRC | AARCH64_FL_CRYPTO, qdf24xx,   0x51, 0xC00, -1)
>  
>  /* Cavium ('C') cores. */
> -AARCH64_CORE("thunderx",  thunderx,  thunderx,  8A,
> AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC | AARCH64_FL_CRYPTO | AARCH64_FL_LSE, 
> thunderx,  0x43, 0x0a0, -1)
> +AARCH64_CORE("thunderx",  thunderx,  thunderx,  8A,  
> AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC | AARCH64_FL_CRYPTO, thunderx,  0x43, 
> 0x0a0, -1)
>  /* Do not swap around "thunderxt88p1" and "thunderxt88",
> this order is required to handle variant correctly. */
> -AARCH64_CORE("thunderxt88p1", thunderxt88p1, thunderx,  8A,
> AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC | AARCH64_FL_CRYPTO,   
> thunderx,  0x43, 0x0a1, 0)
> -AARCH64_CORE("thunderxt88",   thunderxt88,   thunderx,  8A,
> AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC | AARCH64_FL_CRYPTO | AARCH64_FL_LSE, 
> thunderx,  0x43, 0x0a1, -1)
> -AARCH64_CORE("thunderxt81",   thunderxt81,   thunderx,  8_1A,  
> AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC | AARCH64_FL_CRYPTO | AARCH64_FL_LSE, 
> thunderx,  0x43, 0x0a2, -1)
> -AARCH64_CORE("thunderxt83",   thunderxt83,   thunderx,  8_1A,  
> AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC | AARCH64_FL_CRYPTO | AARCH64_FL_LSE, 
> thunderx,  0x43, 0x0a3, -1)
> +AARCH64_CORE("thunderxt88p1", thunderxt88p1, thunderx,  8A,  
> AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC | AARCH64_FL_CRYPTO,  thunderx,  
> 0x43, 0x0a1, 0)
> +AARCH64_CORE("thunderxt88",   thunderxt88,   thunderx,  8A,  
> AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC | AARCH64_FL_CRYPTO, thunderx,  0x43, 
> 0x0a1, -1)
> +AARCH64_CORE("thunderxt81",   thunderxt81,   thunderx,  8A,  
> AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC | AARCH64_FL_CRYPTO, thunderx,  0x43, 
> 0x0a2, -1)
> +AARCH64_CORE("thunderxt83",   thunderxt83,   thunderx,  8A,  
> AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC | AARCH64_FL_CRYPTO, thunderx,  0x43, 
> 0x0a3, -1)
>  
>  /* APM ('P') cores. */
>  AARCH64_CORE("xgene1",  xgene1,xgene1,8A,  AARCH64_FL_FOR_ARCH8, 
> xgene1, 0x50, 0x000, -1)

Fix profile updating in tree-if-convert

[Jan Hubicka]

Hi,
while looking into profile mismatches caused by vectorizer I noticed that
sometimes we get mismatch even when no vectorizing is done.  This is because
tree-if-conv pass inserts

  if (LOOP_VECTORIZED (...))
perhaps_vectorizable_loop;
  else
original_loop.

After LOOP_VECTORIZED is optimized out by vetorizer, we may end up with edge
of probability 0 in falltrhough that does not play well if that is later used
as preheader edge and split and some hot code is inserted there.

This patch simply makes both edges to have 100% probability anticipating that
one of them will be optimized out at compile time.  This makes profile check to
compoain at the end of if-convert dump but things gets correct after
vectorizing. This is not perfect, but perhaps next stage1 we can add support
for verification of conditionals that does involve compile time constnat
builtins. Not sure how common this is - builtin_constant_p is probably another
common cause of mismatches in hot paths.

Patch is largely mechanical by adding extra parameter to loop_version.

Bootstrapped/regested x86_64-linux.  Comitted.

Honza

PR tree-ssa/79347
* cfgloopmanip.c (lv_adjust_loop_entry_edge, loop_version): Add
ELSE_PROB.
* cfgloopmanip.h (loop_version): Update prototype.
* modulo-sched.c (sms_schedule): Update call of loop_version.
* tree-if-conv.c(version_loop_for_if_conversion): Likewise.
* tree-parloops.c (gen_parallel_loop): Likewise.
* tree-ssa-loop-manip.c (tree_transform_and_unroll_loop): Likewise.
* tree-ssa-loop-split.c (split_loop): Likewise.
* tree-ssa-loop-unswitch.c (tree_unswitch_loop): Likewise.
* tree-vect-loop-manip.c (vect_loop_versioning): Likewise.

* gcc.dg/tree-ssa/ifc-10.c: Match for profile mismatches.
* gcc.dg/tree-ssa/ifc-11.c: Match for profile mismatches.
* gcc.dg/tree-ssa/ifc-12.c: Match for profile mismatches.
* gcc.dg/tree-ssa/ifc-20040816-1.c: Match for profile mismatches.
* gcc.dg/tree-ssa/ifc-20040816-2.c: Match for profile mismatches.
* gcc.dg/tree-ssa/ifc-5.c: Match for profile mismatches.
* gcc.dg/tree-ssa/ifc-8.c: Match for profile mismatches.
* gcc.dg/tree-ssa/ifc-9.c: Match for profile mismatches.
* gcc.dg/tree-ssa/ifc-cd.c: Match for profile mismatches.
* gcc.dg/tree-ssa/ifc-pr56541.c: Match for profile mismatches.
* gcc.dg/tree-ssa/ifc-pr68583.c: Match for profile mismatches.
* gcc.dg/tree-ssa/ifc-pr69489-1.c: Match for profile mismatches.
* gcc.dg/tree-ssa/ifc-pr69489-2.c: Match for profile mismatches.

Index: cfgloopmanip.c
===
--- cfgloopmanip.c  (revision 245184)
+++ cfgloopmanip.c  (working copy)
@@ -1645,11 +1645,14 @@ force_single_succ_latches (void)
|
+-> [second_head]
 
-  THEN_PROB is the probability of then branch of the condition.  */
+  THEN_PROB is the probability of then branch of the condition.
+  ELSE_PROB is the probability of else branch. Note that they may be both
+  REG_BR_PROB_BASE when condition is IFN_LOOP_VECTORIZED.  */
 
 static basic_block
 lv_adjust_loop_entry_edge (basic_block first_head, basic_block second_head,
-  edge e, void *cond_expr, unsigned then_prob)
+  edge e, void *cond_expr, unsigned then_prob,
+  unsigned else_prob)
 {
   basic_block new_head = NULL;
   edge e1;
@@ -1668,7 +1671,7 @@ lv_adjust_loop_entry_edge (basic_block f
   e1 = make_edge (new_head, first_head,
  current_ir_type () == IR_GIMPLE ? EDGE_TRUE_VALUE : 0);
   e1->probability = then_prob;
-  e->probability = REG_BR_PROB_BASE - then_prob;
+  e->probability = else_prob;
   e1->count = apply_probability (e->count, e1->probability);
   e->count = apply_probability (e->count, e->probability);
 
@@ -1701,7 +1704,8 @@ lv_adjust_loop_entry_edge (basic_block f
 struct loop *
 loop_version (struct loop *loop,
  void *cond_expr, basic_block *condition_bb,
- unsigned then_prob, unsigned then_scale, unsigned else_scale,
+ unsigned then_prob, unsigned else_prob,
+ unsigned then_scale, unsigned else_scale,
  bool place_after)
 {
   basic_block first_head, second_head;
@@ -1732,7 +1736,7 @@ loop_version (struct loop *loop,
 
   /* Split loop entry edge and insert new block with cond expr.  */
   cond_bb =  lv_adjust_loop_entry_edge (first_head, second_head,
-   entry, cond_expr, then_prob);
+   entry, cond_expr, then_prob, else_prob);
   if (condition_bb)
 *condition_bb = cond_bb;
 
Index: cfgloopmanip.h
===
--- cfgloopmanip.h  (revision 245184)
+++ cfgloopmanip.h  (working copy)
@@ -58,6 +58,7 @@ basi

Fix profile updating after outer loop unswitching

[Jan Hubicka]

Hi,
this patches updates profile after hoist_guard transformation that was added in
2015.  I wonder why this transofrm is bundled in tree-ssa-loop-unswitch and not
enabled at -O2/-Os.  It converts

 while (1)  
   {
 [header]]  
 loop_phi_nodes;
 something1;
 if (cond1) 
   body;
 nvar = phi(orig, bvar) ... for all variables changed in body;  
 [guard_end]
 something2;
 if (cond2) 
   break;   
 something3;
   }

to

   if (cond1)
 while (1)  
   {
 [header]]  
 loop_phi_nodes;
 something1;
 body;
 [guard_end]
 something2;
 if (cond2) 
   break;   
 something3;
   }

Which, unlike normal if conversion seems almost always win becuase it does not
duplicate any code. While path where loop executes 0 times has one extra
if (cond1) on it, this seems to be quite reasonable tradeoff.

Bootstrapped/regtested x86_64-linux, will commit it tomorrow unless there
are complains.

* gcc.dg/loop-unswitch-2.c: New testcase.
* gcc.dg/loop-unswitch-1.c: New testcase.

* tree-ssa-loop-unswitch.c (hoist_guard): Update profile.
Index: testsuite/gcc.dg/loop-unswitch-2.c
===
--- testsuite/gcc.dg/loop-unswitch-2.c  (revision 245196)
+++ testsuite/gcc.dg/loop-unswitch-2.c  (working copy)
@@ -12,4 +12,5 @@ void foo (float **a, float **b, float *c
 }
 
 /* { dg-final { scan-tree-dump-times "guard hoisted" 3 "unswitch" } } */
+/* { dg-final { scan-tree-dump-not "Invalid sum" "unswitch" } } */
 
Index: testsuite/gcc.dg/loop-unswitch-3.c
===
--- testsuite/gcc.dg/loop-unswitch-3.c  (revision 245196)
+++ testsuite/gcc.dg/loop-unswitch-3.c  (working copy)
@@ -22,5 +22,6 @@ float *foo(int ustride, int size, float
 }
 
 /* { dg-final { scan-tree-dump-times "guard hoisted" 1 "unswitch" } } */
+/* { dg-final { scan-tree-dump-not "Invalid sum" "unswitch" } } */
 
 
Index: tree-ssa-loop-unswitch.c
===
--- tree-ssa-loop-unswitch.c(revision 245196)
+++ tree-ssa-loop-unswitch.c(working copy)
@@ -787,6 +787,7 @@ hoist_guard (struct loop *loop, edge gua
   edge te, fe, e, new_edge;
   gimple *stmt;
   basic_block guard_bb = guard->src;
+  edge not_guard;
   gimple_stmt_iterator gsi;
   int flags = 0;
   bool fix_dom_of_exit;
@@ -818,18 +819,80 @@ hoist_guard (struct loop *loop, edge gua
   update_stmt (cond_stmt);
   /* Create new loop pre-header.  */
   e = split_block (pre_header, last_stmt (pre_header));
+  if (dump_file && (dump_flags & TDF_DETAILS))
+fprintf (dump_file, "  Moving guard %i->%i (prob %i) to bb %i, "   
+"new preheader is %i\n",
+guard->src->index, guard->dest->index, guard->probability,
+e->src->index, e->dest->index);
+
   gcc_assert (loop_preheader_edge (loop)->src == e->dest);
+
   if (guard == fe)
 {
   e->flags = EDGE_TRUE_VALUE;
   flags |= EDGE_FALSE_VALUE;
+  not_guard = te;
 }
   else
 {
   e->flags = EDGE_FALSE_VALUE;
   flags |= EDGE_TRUE_VALUE;
+  not_guard = fe;
 }
   new_edge = make_edge (pre_header, exit->dest, flags);
+
+  /* Determine the probability that we skip the loop.  Assume that loop has
+ s

[PATCH 4/6] RISC-V Port: libatomic

[Palmer Dabbelt]

---
 libatomic/configure.tgt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libatomic/configure.tgt b/libatomic/configure.tgt
index 6d77c94..b8af3ab 100644
--- a/libatomic/configure.tgt
+++ b/libatomic/configure.tgt
@@ -37,6 +37,7 @@ case "${target_cpu}" in
ARCH=alpha
;;
   rs6000 | powerpc*)   ARCH=powerpc ;;
+  riscv*)  ARCH=riscv ;;
   sh*) ARCH=sh ;;
 
   arm*)
-- 
2.10.2

[PATCH 5/6] RISC-V Port: gcc/testsuite

[Palmer Dabbelt]

From: Kito Cheng 

---
 gcc/testsuite/g++.dg/cpp0x/constexpr-rom.C| 2 +-
 gcc/testsuite/gcc.c-torture/execute/20101011-1.c  | 3 +++
 gcc/testsuite/gcc.dg/20020312-2.c | 2 ++
 gcc/testsuite/gcc.dg/builtin-apply2.c | 1 +
 gcc/testsuite/gcc.dg/ifcvt-4.c| 2 +-
 gcc/testsuite/gcc.dg/loop-8.c | 2 +-
 gcc/testsuite/gcc.dg/sibcall-10.c | 2 ++
 gcc/testsuite/gcc.dg/sibcall-9.c  | 2 ++
 gcc/testsuite/gcc.dg/stack-usage-1.c  | 2 ++
 gcc/testsuite/gcc.dg/torture/stackalign/builtin-apply-2.c | 2 +-
 gcc/testsuite/gcc.dg/tree-ssa/20040204-1.c| 2 +-
 gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-cse-2.c | 2 +-
 gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-3.c | 2 +-
 gcc/testsuite/lib/target-supports.exp | 1 +
 14 files changed, 20 insertions(+), 7 deletions(-)

diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-rom.C 
b/gcc/testsuite/g++.dg/cpp0x/constexpr-rom.C
index 80a571a..2e0ef68 100644
--- a/gcc/testsuite/g++.dg/cpp0x/constexpr-rom.C
+++ b/gcc/testsuite/g++.dg/cpp0x/constexpr-rom.C
@@ -2,7 +2,7 @@
 // { dg-do compile { target c++11 } }
 // { dg-additional-options -G0 { target { { alpha*-*-* frv*-*-* ia64-*-* 
lm32*-*-* m32r*-*-* microblaze*-*-* mips*-*-* nios2-*-* powerpc*-*-* 
rs6000*-*-* } && { ! { *-*-darwin* *-*-aix* alpha*-*-*vms* } } } } }
 // { dg-final { scan-assembler "\\.rdata" { target mips*-*-* } } }
-// { dg-final { scan-assembler "rodata" { target { { *-*-linux-gnu *-*-gnu* 
*-*-elf } && { ! mips*-*-* } } } } }
+// { dg-final { scan-assembler "rodata" { target { { *-*-linux-gnu *-*-gnu* 
*-*-elf } && { ! { mips*-*-* riscv*-*-* } } } } } }
 
 struct Data
 {
diff --git a/gcc/testsuite/gcc.c-torture/execute/20101011-1.c 
b/gcc/testsuite/gcc.c-torture/execute/20101011-1.c
index 744763f..899a401 100644
--- a/gcc/testsuite/gcc.c-torture/execute/20101011-1.c
+++ b/gcc/testsuite/gcc.c-torture/execute/20101011-1.c
@@ -6,6 +6,9 @@
 #elif defined (__powerpc__) || defined (__PPC__) || defined (__ppc__) || 
defined (__POWERPC__) || defined (__ppc)
   /* On PPC division by zero does not trap.  */
 # define DO_TEST 0
+#elif defined (__riscv)
+  /* On RISC-V division by zero does not trap.  */
+# define DO_TEST 0
 #elif defined (__SPU__)
   /* On SPU division by zero does not trap.  */
 # define DO_TEST 0
diff --git a/gcc/testsuite/gcc.dg/20020312-2.c 
b/gcc/testsuite/gcc.dg/20020312-2.c
index 5fce50d..f5929e0 100644
--- a/gcc/testsuite/gcc.dg/20020312-2.c
+++ b/gcc/testsuite/gcc.dg/20020312-2.c
@@ -67,6 +67,8 @@ extern void abort (void);
 # else
 #  define PIC_REG  "30"
 # endif
+#elif defined(__riscv)
+/* No pic register.  */
 #elif defined(__RX__)
 /* No pic register.  */
 #elif defined(__s390__)
diff --git a/gcc/testsuite/gcc.dg/builtin-apply2.c 
b/gcc/testsuite/gcc.dg/builtin-apply2.c
index b6cbe39..ad61d3b 100644
--- a/gcc/testsuite/gcc.dg/builtin-apply2.c
+++ b/gcc/testsuite/gcc.dg/builtin-apply2.c
@@ -1,6 +1,7 @@
 /* { dg-do run } */
 /* { dg-require-effective-target untyped_assembly } */
 /* { dg-skip-if "Variadic funcs have all args on stack. Normal funcs have args 
in registers." { "avr-*-* nds32*-*-*" } { "*" } { "" } } */
+/* { dg-skip-if "Variadic funcs use different argument passing from normal 
funcs." { "riscv*-*-*" } { "*" } { "" } } */
 /* { dg-skip-if "Variadic funcs use Base AAPCS.  Normal funcs use VFP 
variant." { arm*-*-* && arm_hf_eabi } { "*" } { "" } } */
 
 /* PR target/12503 */
diff --git a/gcc/testsuite/gcc.dg/ifcvt-4.c b/gcc/testsuite/gcc.dg/ifcvt-4.c
index 0d1671c..466ad15 100644
--- a/gcc/testsuite/gcc.dg/ifcvt-4.c
+++ b/gcc/testsuite/gcc.dg/ifcvt-4.c
@@ -1,6 +1,6 @@
 /* { dg-options "-fdump-rtl-ce1 -O2 --param max-rtl-if-conversion-insns=3 
--param max-rtl-if-conversion-unpredictable-cost=100" } */
 /* { dg-additional-options "-misel" { target { powerpc*-*-* } } } */
-/* { dg-skip-if "Multiple set if-conversion not guaranteed on all subtargets" 
{ "arm*-*-* hppa*64*-*-* visium-*-*" } }  */
+/* { dg-skip-if "Multiple set if-conversion not guaranteed on all subtargets" 
{ "arm*-*-* hppa*64*-*-* visium-*-*" riscv*-*-* } }  */
 
 typedef int word __attribute__((mode(word)));
 
diff --git a/gcc/testsuite/gcc.dg/loop-8.c b/gcc/testsuite/gcc.dg/loop-8.c
index de9ee89..5fcab7b 100644
--- a/gcc/testsuite/gcc.dg/loop-8.c
+++ b/gcc/testsuite/gcc.dg/loop-8.c
@@ -1,6 +1,6 @@
 /* { dg-do compile } */
 /* { dg-options "-O1 -fdump-rtl-loop2_invariant" } */
-/* { dg-skip-if "unexpected IV" { "hppa*-*-* mips*-*-* visium-*-* 
powerpc*-*-*" } { "*" } { "" } } */
+/* { dg-skip-if "unexpected IV" { "hppa*-*-* mips*-*-* visium-*-* powerpc*-*-* 
riscv*-*-*" } { "*" } { "" } } */
 
 void
 f (int *a, int *b)
diff --git a/gcc/testsuite/gcc.dg/sibcall-10.c 
b/gcc/testsuite/gcc.dg/sibcall-10.c
index d98b43a..d89909a 100644
--- a/gcc/testsuite/gcc.dg/sibcall-10.c
+++ b/gcc/tes

New Port for RISC-V v3

[Palmer Dabbelt]

There have been a handful of changes since we submitted our v2 port:

 * Some documentation formatting fixes.

 * A documentation typo fix.

 * Some changes to wwwdocs, which have been mailed to the list.

 * The port now builds via contrib/config-list.mk.  I worked around the
   warnings in other parts of the codebase with some "#pragma GCC diagnostic
   ignored" when I couldn't fix them properly, so the patches aren't useful,
   but I fixed the warnings in our port reasonably.  I can try to fix all these
   reasonably, but it might take a while.

As far as I know there are currently no outstanding problems with this port, so
I think it's at the point where we should talk about actually getting the code
in.  We have been accepted as maintainers of the port, and I have write access
to the repositories, so I think we're all good to go on that end.  Of course if
there's any remaining comments I'd love to fix them, but it seems the comments
on our v2 were somewhat minimal.

What's the procedure for moving forward with the port?

Thanks to everyone who helped with reviewing the port!

[PATCH 1/6] RISC-V Port: gcc/config/riscv/riscv.c
[PATCH 2/6] RISC-V Port: gcc
[PATCH 3/6] RISC-V Port: libgcc
[PATCH 4/6] RISC-V Port: libatomic
[PATCH 5/6] RISC-V Port: gcc/testsuite
[PATCH 6/6] RISC-V Port: contrib

[PATCH 3/6] RISC-V Port: libgcc

[Palmer Dabbelt]

---
 libgcc/config.host |  12 +
 libgcc/config/riscv/atomic.c   | 111 +
 libgcc/config/riscv/crti.S |   1 +
 libgcc/config/riscv/crtn.S |   1 +
 libgcc/config/riscv/div.S  | 146 
 libgcc/config/riscv/linux-unwind.h |  89 +++
 libgcc/config/riscv/muldi3.S   |  46 
 libgcc/config/riscv/multi3.S   |  81 +++
 libgcc/config/riscv/save-restore.S | 463 +
 libgcc/config/riscv/sfp-machine.h  | 137 +++
 libgcc/config/riscv/t-elf  |   6 +
 libgcc/config/riscv/t-elf32|   1 +
 libgcc/config/riscv/t-elf64|   1 +
 libgcc/config/riscv/t-softfp32 |  26 +++
 libgcc/config/riscv/t-softfp64 |   3 +
 15 files changed, 1124 insertions(+)
 create mode 100644 libgcc/config/riscv/atomic.c
 create mode 100644 libgcc/config/riscv/crti.S
 create mode 100644 libgcc/config/riscv/crtn.S
 create mode 100644 libgcc/config/riscv/div.S
 create mode 100644 libgcc/config/riscv/linux-unwind.h
 create mode 100644 libgcc/config/riscv/muldi3.S
 create mode 100644 libgcc/config/riscv/multi3.S
 create mode 100644 libgcc/config/riscv/save-restore.S
 create mode 100644 libgcc/config/riscv/sfp-machine.h
 create mode 100644 libgcc/config/riscv/t-elf
 create mode 100644 libgcc/config/riscv/t-elf32
 create mode 100644 libgcc/config/riscv/t-elf64
 create mode 100644 libgcc/config/riscv/t-softfp32
 create mode 100644 libgcc/config/riscv/t-softfp64

diff --git a/libgcc/config.host b/libgcc/config.host
index 540bfa9..9472a60 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -167,6 +167,9 @@ powerpc*-*-*)
;;
 rs6000*-*-*)
;;
+riscv*-*-*)
+   cpu_type=riscv
+   ;;
 sparc64*-*-*)
cpu_type=sparc
;;
@@ -1093,6 +1096,15 @@ powerpcle-*-eabi*)
tmake_file="${tmake_file} rs6000/t-ppccomm rs6000/t-crtstuff 
t-crtstuff-pic t-fdpbit"
extra_parts="$extra_parts crtbegin.o crtend.o crtbeginS.o crtendS.o 
crtbeginT.o ecrti.o ecrtn.o ncrti.o ncrtn.o"
;;
+riscv*-*-linux*)
+   tmake_file="${tmake_file} riscv/t-softfp${host_address} t-softfp 
riscv/t-elf riscv/t-elf${host_address}"
+   extra_parts="$extra_parts crtbegin.o crtend.o crti.o crtn.o crtendS.o 
crtbeginT.o"
+   md_unwind_header=riscv/linux-unwind.h
+   ;;
+riscv*-*-*)
+   tmake_file="${tmake_file} riscv/t-softfp${host_address} t-softfp 
riscv/t-elf riscv/t-elf${host_address}"
+   extra_parts="$extra_parts crtbegin.o crtend.o crti.o crtn.o"
+   ;;
 rs6000-ibm-aix4.[3456789]* | powerpc-ibm-aix4.[3456789]*)
md_unwind_header=rs6000/aix-unwind.h
tmake_file="t-fdpbit rs6000/t-ppc64-fp rs6000/t-slibgcc-aix 
rs6000/t-ibm-ldouble"
diff --git a/libgcc/config/riscv/atomic.c b/libgcc/config/riscv/atomic.c
new file mode 100644
index 000..448b0e5
--- /dev/null
+++ b/libgcc/config/riscv/atomic.c
@@ -0,0 +1,111 @@
+/* Legacy sub-word atomics for RISC-V.
+ 
+   Copyright (C) 2016-2017 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify it under
+the terms of the GNU General Public License as published by the Free
+Software Foundation; either version 3, or (at your option) any later
+version.
+
+GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+WARRANTY; without even the implied warranty of MERCHANTABILITY or
+FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+for more details.
+
+Under Section 7 of GPL version 3, you are granted additional
+permissions described in the GCC Runtime Library Exception, version
+3.1, as published by the Free Software Foundation.
+
+You should have received a copy of the GNU General Public License and
+a copy of the GCC Runtime Library Exception along with this program;
+see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+.  */
+
+#ifdef __riscv_atomic
+
+#include 
+
+#define INVERT "not %[tmp1], %[tmp1]\n\t"
+#define DONT_INVERT""
+
+#define GENERATE_FETCH_AND_OP(type, size, opname, insn, invert, cop)   \
+  type __sync_fetch_and_ ## opname ## _ ## size (type *p, type v)  \
+  {\
+unsigned long aligned_addr = ((unsigned long) p) & ~3UL;   \
+int shift = (((unsigned long) p) & 3) * 8; \
+unsigned mask = ((1U << ((sizeof v) * 8)) - 1) << shift;   \
+unsigned old, tmp1, tmp2;  \
+   \
+asm volatile ("1:\n\t" \
+ "lr.w.aq %[old], %[mem]\n\t"  \
+ #insn " %[tmp1], %[old], %[value]\n\t"\
+ invert\
+ "and %[tmp1], %[tmp1], %[mask]\n\t"  

[PATCH 6/6] RISC-V Port: contrib

[Palmer Dabbelt]

---
 contrib/config-list.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/contrib/config-list.mk b/contrib/config-list.mk
index 9833480..0edc8a4 100644
--- a/contrib/config-list.mk
+++ b/contrib/config-list.mk
@@ -79,6 +79,7 @@ LIST = aarch64-elf aarch64-linux-gnu aarch64-rtems \
   powerpc-wrs-vxworks powerpc-wrs-vxworksae powerpc-wrs-vxworksmils \
   powerpc-lynxos powerpcle-elf \
   powerpcle-eabisim powerpcle-eabi \
+  riscv32-unknown-linux-gnu riscv64-unknown-linux-gnu \
   rs6000-ibm-aix5.3.0 rs6000-ibm-aix6.1 rs6000-ibm-aix7.1 \
   rl78-elf rx-elf s390-linux-gnu s390x-linux-gnu s390x-ibm-tpf sh-elf \
   shle-linux sh-netbsdelf sh-superh-elf \
-- 
2.10.2

[PATCH 1/6] RISC-V Port: gcc/config/riscv/riscv.c

[Palmer Dabbelt]

---
 gcc/config/riscv/riscv.c | 4138 ++
 1 file changed, 4138 insertions(+)
 create mode 100644 gcc/config/riscv/riscv.c

diff --git a/gcc/config/riscv/riscv.c b/gcc/config/riscv/riscv.c
new file mode 100644
index 000..834651f
--- /dev/null
+++ b/gcc/config/riscv/riscv.c
@@ -0,0 +1,4138 @@
+/* Subroutines used for code generation for RISC-V.
+   Copyright (C) 2011-2017 Free Software Foundation, Inc.
+   Contributed by Andrew Waterman (and...@sifive.com).
+   Based on MIPS target for GNU compiler.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 3, or (at your option)
+any later version.
+
+GCC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3.  If not see
+.  */
+
+#include "config.h"
+#include "system.h"
+#include "coretypes.h"
+#include "tm.h"
+#include "rtl.h"
+#include "regs.h"
+#include "hard-reg-set.h"
+#include "insn-config.h"
+#include "conditions.h"
+#include "insn-attr.h"
+#include "recog.h"
+#include "output.h"
+#include "hash-set.h"
+#include "machmode.h"
+#include "vec.h"
+#include "double-int.h"
+#include "input.h"
+#include "alias.h"
+#include "symtab.h"
+#include "wide-int.h"
+#include "inchash.h"
+#include "tree.h"
+#include "fold-const.h"
+#include "varasm.h"
+#include "stringpool.h"
+#include "stor-layout.h"
+#include "calls.h"
+#include "function.h"
+#include "hashtab.h"
+#include "flags.h"
+#include "statistics.h"
+#include "real.h"
+#include "fixed-value.h"
+#include "expmed.h"
+#include "dojump.h"
+#include "explow.h"
+#include "memmodel.h"
+#include "emit-rtl.h"
+#include "stmt.h"
+#include "expr.h"
+#include "insn-codes.h"
+#include "optabs.h"
+#include "libfuncs.h"
+#include "reload.h"
+#include "tm_p.h"
+#include "ggc.h"
+#include "gstab.h"
+#include "hash-table.h"
+#include "debug.h"
+#include "target.h"
+#include "target-def.h"
+#include "common/common-target.h"
+#include "langhooks.h"
+#include "dominance.h"
+#include "cfg.h"
+#include "cfgrtl.h"
+#include "cfganal.h"
+#include "lcm.h"
+#include "cfgbuild.h"
+#include "cfgcleanup.h"
+#include "predict.h"
+#include "basic-block.h"
+#include "bitmap.h"
+#include "regset.h"
+#include "df.h"
+#include "sched-int.h"
+#include "tree-ssa-alias.h"
+#include "internal-fn.h"
+#include "gimple-fold.h"
+#include "tree-eh.h"
+#include "gimple-expr.h"
+#include "is-a.h"
+#include "gimple.h"
+#include "gimplify.h"
+#include "diagnostic.h"
+#include "target-globals.h"
+#include "opts.h"
+#include "tree-pass.h"
+#include "context.h"
+#include "hash-map.h"
+#include "plugin-api.h"
+#include "ipa-ref.h"
+#include "cgraph.h"
+#include "builtins.h"
+#include "rtl-iter.h"
+
+/* True if X is an UNSPEC wrapper around a SYMBOL_REF or LABEL_REF.  */
+#define UNSPEC_ADDRESS_P(X)\
+  (GET_CODE (X) == UNSPEC  \
+   && XINT (X, 1) >= UNSPEC_ADDRESS_FIRST  \
+   && XINT (X, 1) < UNSPEC_ADDRESS_FIRST + NUM_SYMBOL_TYPES)
+
+/* Extract the symbol or label from UNSPEC wrapper X.  */
+#define UNSPEC_ADDRESS(X) \
+  XVECEXP (X, 0, 0)
+
+/* Extract the symbol type from UNSPEC wrapper X.  */
+#define UNSPEC_ADDRESS_TYPE(X) \
+  ((enum riscv_symbol_type) (XINT (X, 1) - UNSPEC_ADDRESS_FIRST))
+
+/* True if bit BIT is set in VALUE.  */
+#define BITSET_P(VALUE, BIT) (((VALUE) & (1ULL << (BIT))) != 0)
+
+/* Classifies an address.
+
+   ADDRESS_REG
+   A natural register + offset address.  The register satisfies
+   riscv_valid_base_register_p and the offset is a const_arith_operand.
+
+   ADDRESS_LO_SUM
+   A LO_SUM rtx.  The first operand is a valid base register and
+   the second operand is a symbolic address.
+
+   ADDRESS_CONST_INT
+   A signed 16-bit constant address.
+
+   ADDRESS_SYMBOLIC:
+   A constant symbolic address.  */
+enum riscv_address_type {
+  ADDRESS_REG,
+  ADDRESS_LO_SUM,
+  ADDRESS_CONST_INT,
+  ADDRESS_SYMBOLIC
+};
+
+/* Information about a function's frame layout.  */
+struct GTY(())  riscv_frame_info {
+  /* The size of the frame in bytes.  */
+  HOST_WIDE_INT total_size;
+
+  /* Bit X is set if the function saves or restores GPR X.  */
+  unsigned int mask;
+
+  /* Likewise FPR X.  */
+  unsigned int fmask;
+
+  /* How much the GPR save/restore routines adjust sp (or 0 if unused).  */
+  unsigned save_libcall_adjustment;
+
+  /* Offsets of fixed-point and floating-point save areas from frame bottom */
+  HOST_WIDE_INT gp_sp_offset;
+  HOST_WIDE_INT fp_sp_offset;
+
+  /* Offset of virtual frame pointer from stack pointer

Re: [PATCH/AARCH64] Fix ThunderX core definition

[Andrew Pinski]

On Sun, Feb 5, 2017 at 8:50 AM, James Greenhalgh
 wrote:
> On Fri, Feb 03, 2017 at 01:10:36PM -0800, Andrew Pinski wrote:
>> Hi,
>>   It turns out due to a hardware issue, LSE support is turned off.
>> This patch updates the thunderx cores to disable LSE and 8.1 where as
>> needed.
>
> With this, do we want to back out the rest of the "variant" support that
> you added to the -mcpu=native detection?
>
> I'd expect this code to now be dead, and posisbly stay dead. As we only added
> it for GCC 7 I don't think losing it again would be a big loss. I realise
> that makes this patch a bit larger, but it seems like it would lead to a
> more maintainable port. Outside of merge conflicts in aarch64-cores.def, I'd
> guess a revert would be fairly painless.
>
> What do you think?

Well for gcc 8, I was going to propose some scheduling changes which
need this again.  So the question do we want to keep it around still
for GCC 7 or not?  IIRC the xgene folks was asking for the variant
patch too.

Thanks,
Andrew

>
> Thanks,
> James
>
>>
>> OK?  Bootstrapped and tested on aarch64-linux-gnu with no regressions.
>>
>> Thanks,
>> Andrew Pinski
>>
>> ChangeLog:
>> * config/aarch64/aarch64-cores.def (thunderx): Disable LSE.
>> (thunderxt88): Likewise.
>> (thunderxt81): Disable LSE and change v8.1 to v8.
>> (thunderxt83): Likewise.
>
>> Index: config/aarch64/aarch64-cores.def
>> ===
>> --- config/aarch64/aarch64-cores.def  (revision 244077)
>> +++ config/aarch64/aarch64-cores.def  (working copy)
>> @@ -60,13 +60,13 @@ AARCH64_CORE("falkor",  falkor,c
>>  AARCH64_CORE("qdf24xx", qdf24xx,   cortexa57, 8A,  AARCH64_FL_FOR_ARCH8 
>> | AARCH64_FL_CRC | AARCH64_FL_CRYPTO, qdf24xx,   0x51, 0xC00, -1)
>>
>>  /* Cavium ('C') cores. */
>> -AARCH64_CORE("thunderx",  thunderx,  thunderx,  8A,
>> AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC | AARCH64_FL_CRYPTO | AARCH64_FL_LSE, 
>> thunderx,  0x43, 0x0a0, -1)
>> +AARCH64_CORE("thunderx",  thunderx,  thunderx,  8A,  
>> AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC | AARCH64_FL_CRYPTO, thunderx,  0x43, 
>> 0x0a0, -1)
>>  /* Do not swap around "thunderxt88p1" and "thunderxt88",
>> this order is required to handle variant correctly. */
>> -AARCH64_CORE("thunderxt88p1", thunderxt88p1, thunderx,  8A,
>> AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC | AARCH64_FL_CRYPTO,   
>> thunderx,  0x43, 0x0a1, 0)
>> -AARCH64_CORE("thunderxt88",   thunderxt88,   thunderx,  8A,
>> AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC | AARCH64_FL_CRYPTO | AARCH64_FL_LSE, 
>> thunderx,  0x43, 0x0a1, -1)
>> -AARCH64_CORE("thunderxt81",   thunderxt81,   thunderx,  8_1A,  
>> AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC | AARCH64_FL_CRYPTO | AARCH64_FL_LSE, 
>> thunderx,  0x43, 0x0a2, -1)
>> -AARCH64_CORE("thunderxt83",   thunderxt83,   thunderx,  8_1A,  
>> AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC | AARCH64_FL_CRYPTO | AARCH64_FL_LSE, 
>> thunderx,  0x43, 0x0a3, -1)
>> +AARCH64_CORE("thunderxt88p1", thunderxt88p1, thunderx,  8A,  
>> AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC | AARCH64_FL_CRYPTO,  thunderx,  
>> 0x43, 0x0a1, 0)
>> +AARCH64_CORE("thunderxt88",   thunderxt88,   thunderx,  8A,  
>> AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC | AARCH64_FL_CRYPTO, thunderx,  0x43, 
>> 0x0a1, -1)
>> +AARCH64_CORE("thunderxt81",   thunderxt81,   thunderx,  8A,  
>> AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC | AARCH64_FL_CRYPTO, thunderx,  0x43, 
>> 0x0a2, -1)
>> +AARCH64_CORE("thunderxt83",   thunderxt83,   thunderx,  8A,  
>> AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC | AARCH64_FL_CRYPTO, thunderx,  0x43, 
>> 0x0a3, -1)
>>
>>  /* APM ('P') cores. */
>>  AARCH64_CORE("xgene1",  xgene1,xgene1,8A,  
>> AARCH64_FL_FOR_ARCH8, xgene1, 0x50, 0x000, -1)
>
>

Re: C++ Modules branch

[Gerald Pfeifer]

On Tue, 24 Jan 2017, Nathan Sidwell wrote:
> As some have already noticed, I created a c++-modules branch yesterday. 
> Don't get too excited, that doesn't mean I have an implementation to 
> commit there.

Are you planning to add this to svn.html (where we generally
describe all branches)?

Gerald

[wwwdocs] mirrors - remove FTP service of mirrors-usa.go-parts.com

[Gerald Pfeifer]

...which is now asking for username and password.

I verified that the HTTP mirror still seems to work just fine, and
applied the patch below for now.

Gerald

Index: mirrors.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/mirrors.html,v
retrieving revision 1.238
retrieving revision 1.239
diff -u -r1.238 -r1.239
--- mirrors.html28 Jan 2017 22:29:12 -  1.238
+++ mirrors.html5 Feb 2017 19:57:51 -   1.239
@@ -49,7 +49,6 @@
 US, San Jose: http://www.netgull.com/gcc/";>http://www.netgull.com, thanks to admin 
at netgull.com
 US:
   http://mirrors-usa.go-parts.com/gcc/";>http://mirrors-usa.go-parts.com/gcc
-| ftp://mirrors-usa.go-parts.com/gcc";>ftp://mirrors-usa.go-parts.com/gcc
 | rsync://mirrors-usa.go-parts.com/gcc
 US, Michigan: http://mirrors.concertpass.com/gcc/";>http://mirrors.concertpass.com/gcc/,
 thanks to ad...@mirrors.concertpass.com.
 

Re: [PATCH/AARCH64] Fix ThunderX core definition

[James Greenhalgh]

On Sun, Feb 05, 2017 at 11:43:59AM -0800, Andrew Pinski wrote:
> On Sun, Feb 5, 2017 at 8:50 AM, James Greenhalgh
>  wrote:
> > On Fri, Feb 03, 2017 at 01:10:36PM -0800, Andrew Pinski wrote:
> >> Hi,
> >>   It turns out due to a hardware issue, LSE support is turned off.
> >> This patch updates the thunderx cores to disable LSE and 8.1 where as
> >> needed.
> >
> > With this, do we want to back out the rest of the "variant" support that
> > you added to the -mcpu=native detection?
> >
> > I'd expect this code to now be dead, and posisbly stay dead. As we only 
> > added
> > it for GCC 7 I don't think losing it again would be a big loss. I realise
> > that makes this patch a bit larger, but it seems like it would lead to a
> > more maintainable port. Outside of merge conflicts in aarch64-cores.def, I'd
> > guess a revert would be fairly painless.
> >
> > What do you think?
> 
> Well for gcc 8, I was going to propose some scheduling changes which
> need this again.  So the question do we want to keep it around still
> for GCC 7 or not?  IIRC the xgene folks was asking for the variant
> patch too.

Ah, if you're planning to use it, then ignore my request. There's no sense
in having the churn.

The patch is OK as is. Though, as is customary at this time of year, give
Richard and Marcus some time to object.

Thanks,
James

> 
> Thanks,
> Andrew
> 
> >
> > Thanks,
> > James
> >
> >>
> >> OK?  Bootstrapped and tested on aarch64-linux-gnu with no regressions.
> >>
> >> Thanks,
> >> Andrew Pinski
> >>
> >> ChangeLog:
> >> * config/aarch64/aarch64-cores.def (thunderx): Disable LSE.
> >> (thunderxt88): Likewise.
> >> (thunderxt81): Disable LSE and change v8.1 to v8.
> >> (thunderxt83): Likewise.
> >
> >> Index: config/aarch64/aarch64-cores.def
> >> ===
> >> --- config/aarch64/aarch64-cores.def  (revision 244077)
> >> +++ config/aarch64/aarch64-cores.def  (working copy)
> >> @@ -60,13 +60,13 @@ AARCH64_CORE("falkor",  falkor,c
> >>  AARCH64_CORE("qdf24xx", qdf24xx,   cortexa57, 8A,  
> >> AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC | AARCH64_FL_CRYPTO, qdf24xx,   
> >> 0x51, 0xC00, -1)
> >>
> >>  /* Cavium ('C') cores. */
> >> -AARCH64_CORE("thunderx",  thunderx,  thunderx,  8A,
> >> AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC | AARCH64_FL_CRYPTO | 
> >> AARCH64_FL_LSE, thunderx,  0x43, 0x0a0, -1)
> >> +AARCH64_CORE("thunderx",  thunderx,  thunderx,  8A,  
> >> AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC | AARCH64_FL_CRYPTO, thunderx,  
> >> 0x43, 0x0a0, -1)
> >>  /* Do not swap around "thunderxt88p1" and "thunderxt88",
> >> this order is required to handle variant correctly. */
> >> -AARCH64_CORE("thunderxt88p1", thunderxt88p1, thunderx,  8A,
> >> AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC | AARCH64_FL_CRYPTO,   
> >> thunderx,  0x43, 0x0a1, 0)
> >> -AARCH64_CORE("thunderxt88",   thunderxt88,   thunderx,  8A,
> >> AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC | AARCH64_FL_CRYPTO | 
> >> AARCH64_FL_LSE, thunderx,  0x43, 0x0a1, -1)
> >> -AARCH64_CORE("thunderxt81",   thunderxt81,   thunderx,  8_1A,  
> >> AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC | AARCH64_FL_CRYPTO | 
> >> AARCH64_FL_LSE, thunderx,  0x43, 0x0a2, -1)
> >> -AARCH64_CORE("thunderxt83",   thunderxt83,   thunderx,  8_1A,  
> >> AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC | AARCH64_FL_CRYPTO | 
> >> AARCH64_FL_LSE, thunderx,  0x43, 0x0a3, -1)
> >> +AARCH64_CORE("thunderxt88p1", thunderxt88p1, thunderx,  8A,  
> >> AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC | AARCH64_FL_CRYPTO,  thunderx,  
> >> 0x43, 0x0a1, 0)
> >> +AARCH64_CORE("thunderxt88",   thunderxt88,   thunderx,  8A,  
> >> AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC | AARCH64_FL_CRYPTO, thunderx,  
> >> 0x43, 0x0a1, -1)
> >> +AARCH64_CORE("thunderxt81",   thunderxt81,   thunderx,  8A,  
> >> AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC | AARCH64_FL_CRYPTO, thunderx,  
> >> 0x43, 0x0a2, -1)
> >> +AARCH64_CORE("thunderxt83",   thunderxt83,   thunderx,  8A,  
> >> AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC | AARCH64_FL_CRYPTO, thunderx,  
> >> 0x43, 0x0a3, -1)
> >>
> >>  /* APM ('P') cores. */
> >>  AARCH64_CORE("xgene1",  xgene1,xgene1,8A,  
> >> AARCH64_FL_FOR_ARCH8, xgene1, 0x50, 0x000, -1)
> >
> >

[doc] contrib.texi - simpliy Hans Boehm's entry

[Gerald Pfeifer]

We generally do not have links to actual contributions in this section
(just references), and I know (since I've had to update them) that we
do have sufficiently many of these links anyway.

Applied.

2017-02-05  Gerald Pfeifer  

* doc/contrib.texi (Contributors): Refer to Hans Boehm's
garbage collector only in textual form.
 
Index: doc/contrib.texi
===
--- doc/contrib.texi(revision 245197)
+++ doc/contrib.texi(working copy)
@@ -85,8 +85,8 @@
 Segher Boessenkool for various fixes.
 
 @item
-Hans-J. Boehm for his 
@uref{http://www.hpl.hp.com/@/personal/@/Hans_Boehm/@/gc/,,
-garbage collector}, IA-64 libffi port, and other Java work.
+Hans-J. Boehm for his garbage collector, IA-64 libffi port, and other
+Java work.
 
 @item
 Neil Booth for work on cpplib, lang hooks, debug hooks and other

[doc] standards.texi (was: [wwwdocs] Update reference to Go 1)

[Gerald Pfeifer]

On Sun, 15 Nov 2015, Gerald Pfeifer wrote:
> weekly.golang.org/doc/go1 now redirects to golang.org/doc/go1
> and this uses https.

It turns out I missed the link in doc/standards.texi back in November.

Fixed thusly (revision 245199).

Gerald

2017-02-05  Gerald Pfeifer  

* doc/standards.texi (Go Language): Update link to language
standard.

Index: doc/standards.texi
===
--- doc/standards.texi  (revision 245197)
+++ doc/standards.texi  (working copy)
@@ -299,7 +299,7 @@
 @section Go Language
 
 As of the GCC 4.7.1 release, GCC supports the Go 1 language standard,
-described at @uref{http://golang.org/doc/go1.html}.
+described at @uref{https://golang.org/doc/go1}.
 
 @section HSA Intermediate Language (HSAIL)
 

[libstdc++,doc] Strip links to ANSI (web shop)

[Gerald Pfeifer]

First of all, I am not sure whether this is really a FAQ (and even
if so, why we duplicate text in the FAQ and the manual).

But referring to ANSI's webshop (and even ANSI) via a link feels a
little over the edge, doesn't it?

I have _not_ applied this yet.  What do you think?  Any objections?

Gerald

2017-02-05  Gerald Pfeifer  

* doc/xml/faq.xml: Remove links to ANSI and their webshop.
* doc/xml/manual/appendix_contributing.xml: Ditto.

Index: doc/xml/faq.xml
===
--- doc/xml/faq.xml (revision 245197)
+++ doc/xml/faq.xml (working copy)
@@ -1183,11 +1183,7 @@
 and sustained their two-meeting commitment for voting rights, may
 get a copy of the standard from their respective national
 standards organization.  In the USA, this national standards
-organization is ANSI and their website is
-right http://www.w3.org/1999/xlink"; 
xlink:href="http://www.ansi.org";>here.  (And if
-you've already registered with them, clicking this link will take
-you to directly to the place where you can
-http://www.w3.org/1999/xlink"; 
xlink:href="http://webstore.ansi.org/RecordDetail.aspx?sku=ISO%2FIEC+14882:2003";>buy
 the standard on-line.
+organization is ANSI.
 
 
 Who is your country's member body?  Visit the
Index: doc/xml/manual/appendix_contributing.xml
===
--- doc/xml/manual/appendix_contributing.xml(revision 245197)
+++ doc/xml/manual/appendix_contributing.xml(working copy)
@@ -44,10 +44,7 @@
  two meeting commitment for voting rights, may get a copy of
  the standard from their respective national standards
  organization. In the USA, this national standards
- organization is
- http://www.w3.org/1999/xlink"; 
xlink:href="http://www.ansi.org";>ANSI.
- (And if you've already registered with them you can
- http://www.w3.org/1999/xlink"; 
xlink:href="http://webstore.ansi.org/RecordDetail.aspx?sku=INCITS%2fISO%2fIEC+14882-2012";>buy
 the standard on-line.)
+ organization is ANSI.

   
 

[wwwdocs] Add a redirect to the libc (aka glibc/GNU libc) manual

[Gerald Pfeifer]

Some of our own online documentation has references to the glibc
online docs which, alas, are not present on gcc.gnu.org (nor even
sourceware.org from what I could find).

We can fix these links that are currently broken by redirecting to
the version on www.gnu.org.

Tested manually and applied; at least three broken links less on our 
side.

Committed.

Gerald

Index: .htaccess
===
RCS file: /cvs/gcc/wwwdocs/htdocs/.htaccess,v
retrieving revision 1.41
diff -u -r1.41 .htaccess
--- .htaccess   29 Dec 2016 23:21:54 -  1.41
+++ .htaccess   5 Feb 2017 21:33:33 -
@@ -70,4 +70,6 @@
 Redirect permanent /timeline.html  
https://gcc.gnu.org/releases.html#timeline
 Redirect permanent /web.html   https://gcc.gnu.org/about.html
 
+Redirect   /onlinedocs/libc
https://www.gnu.org/software/libc/manual/html_node/
+
 Redirect   /onlinedocs/ref 
https://gcc.gnu.org/onlinedocs/gcc-4.3.2/

New German PO file for 'gcc' (version 7.1-b20170101)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

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

http://translationproject.org/latest/gcc/de.po

(This file, 'gcc-7.1-b20170101.de.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

http://translationproject.org/latest/gcc/

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

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

The following HTML page has been updated:

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

If any question arises, please contact the translation coordinator.

Thank you for all your work,

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

[wwwdocs] gcc-5/changes.html - update link to OpenMP 4.0 Examples

[Gerald Pfeifer]

I am impressed how nicely the OpenMP have put in place a redirect.

Applied.

Gerald

Index: gcc-5/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/changes.html,v
retrieving revision 1.141
diff -u -r1.141 changes.html
--- gcc-5/changes.html  3 Feb 2017 15:48:53 -   1.141
+++ gcc-5/changes.html  5 Feb 2017 21:45:57 -
@@ -194,7 +194,7 @@

  Infrastructure (suitable for any vendor).
  Testsuite which covers offloading from the
- http://openmp.org/mp-documents/OpenMP4.0.0.Examples.pdf";>
+ http://www.openmp.org/wp-content/uploads/OpenMP4.0.0.Examples.pdf";>
  OpenMP 4.0 Examples document.

Specific for upcoming Intel Xeon Phi products:

Re: [libstdc++,doc] Strip links to ANSI (web shop)

[Jonathan Wakely]

On 05/02/17 22:22 +0100, Gerald Pfeifer wrote:

First of all, I am not sure whether this is really a FAQ (and even
if so, why we duplicate text in the FAQ and the manual).

But referring to ANSI's webshop (and even ANSI) via a link feels a
little over the edge, doesn't it?


ANSI sells the standard for a much more reasonable price than ISO or
any of the other national standards bodies. I think many people use
draft standards now, rather than buying it, but for those who do want
an official copy ANSI is the cheapest source.


I have _not_ applied this yet.  What do you think?  Any objections?


I don't see a need to remove the links, but no objections either.

Re: [RFA][PR tree-optimization/79095] [PATCH 1/4] Improve ranges for MINUS_EXPR and EXACT_DIV_EXPR

[kugan]

Hi Jeff,

On 05/02/17 01:52, Jeff Law wrote:

+  /* EXACT_DIV_EXPR is typically used for pointer subtraction;
+ as a result a ~[0,0] may be better than what has already
+ been computed.
+
+ In particular if numerator has the range ~[0,0], then the
+ result range is going to be something like
+ [MININT/DIVISOR,MAXINT/DIVISOR], which is rarely useful.
+
+ So instead make the result range ~[0,0].  */
+  if (code == EXACT_DIV_EXPR
+  && TREE_CODE (op0) == SSA_NAME
+  && vr0.type == VR_ANTI_RANGE
+  && vr0.min == vr0.max
+  && integer_zerop (vr0.min))
+set_value_range_to_nonnull (vr, TREE_TYPE (op0));


Just wondering if this has to be done only for POINTER_TYPE_P (TREE_TYPE 
(op))? Or is EXACT_DIV_EXPR always of POINTER_TYPE_P?


Thanks,
Kugan

Re: [RFA][PR tree-optimization/79095] [PATCH 1/4] Improve ranges for MINUS_EXPR and EXACT_DIV_EXPR

[Jeff Law]

On 02/05/2017 04:06 PM, kugan wrote:

Hi Jeff,

On 05/02/17 01:52, Jeff Law wrote:

+  /* EXACT_DIV_EXPR is typically used for pointer subtraction;
+ as a result a ~[0,0] may be better than what has already
+ been computed.
+
+ In particular if numerator has the range ~[0,0], then the
+ result range is going to be something like
+ [MININT/DIVISOR,MAXINT/DIVISOR], which is rarely useful.
+
+ So instead make the result range ~[0,0].  */
+  if (code == EXACT_DIV_EXPR
+  && TREE_CODE (op0) == SSA_NAME
+  && vr0.type == VR_ANTI_RANGE
+  && vr0.min == vr0.max
+  && integer_zerop (vr0.min))
+set_value_range_to_nonnull (vr, TREE_TYPE (op0));


Just wondering if this has to be done only for POINTER_TYPE_P (TREE_TYPE
(op))? Or is EXACT_DIV_EXPR always of POINTER_TYPE_P?
It can be done regardless of the type -- it just happens that 
EXACT_DIV_EXPR is primarily used on pointer types for pointer subtraction.



jeff

Fix PR c++/79360

[Patrick Palka]

This patch fixes PR c++/79360, a regression from PR c++/70347.

The TYPE_FIELDS of a type may contain TYPE_DECLs and CONST_DECLs as well
as FIELD_DECLs, but when looking for an NSDMI we are only interested in
the FIELD_DECLs.  Otherwise we may try to initialize the union with the
DECL_INITIAL of a nested CONST_DECL.  Does this look OK to commit after
bootstrap + regtest?

gcc/cp/ChangeLog:

PR c++/79360
* typeck2.c (process_init_constructor_union): Consider only
FIELD_DECLs when looking for an NSDMI.

gcc/testsuite/ChangeLog:

PR c++/79360
* g++.dg/cpp1y/nsdmi-union2.C: New test.
---
 gcc/cp/typeck2.c  |  3 ++-
 gcc/testsuite/g++.dg/cpp1y/nsdmi-union2.C | 12 
 2 files changed, 14 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp1y/nsdmi-union2.C

diff --git a/gcc/cp/typeck2.c b/gcc/cp/typeck2.c
index 014de5c..1e0354d 100644
--- a/gcc/cp/typeck2.c
+++ b/gcc/cp/typeck2.c
@@ -1510,7 +1510,8 @@ process_init_constructor_union (tree type, tree init,
 {
   for (tree field = TYPE_FIELDS (type); field; field = TREE_CHAIN (field))
 {
-  if (DECL_INITIAL (field))
+  if (TREE_CODE (field) == FIELD_DECL
+  && DECL_INITIAL (field) != NULL_TREE)
 {
   CONSTRUCTOR_APPEND_ELT (CONSTRUCTOR_ELTS (init),
   field,
diff --git a/gcc/testsuite/g++.dg/cpp1y/nsdmi-union2.C
b/gcc/testsuite/g++.dg/cpp1y/nsdmi-union2.C
new file mode 100644
index 000..08217d7
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/nsdmi-union2.C
@@ -0,0 +1,12 @@
+// PR c++/79360
+// { dg-do compile { target c++14 } }
+
+union U
+{
+  enum E { e };
+};
+
+struct A
+{
+  U u{};
+};
-- 
2.10.1.456.g9cf5127

Re: New Port for RISC-V v2

[Richard Henderson]

On 02/02/2017 01:05 AM, Palmer Dabbelt wrote:

Thanks to everyone who reviewed our original patch set.  I've tried to CC
everyone who provided a review, sorry if I missed anyone!

Andrew, Kito and I believe that we've addressed almost all of the feedback from
the reviews of our v1 patch set.  Since it's been a while we wanted to get a v2
patch set out, just to make sure we're all on the same page going forward.
As far as I know, there's just one thing that still needs to be taken care of:


I've had another look over the code and I'm happy with this version.

The timing for this is unfortunate -- it'll be up to the release managers 
whether or not it can be included during stage4.  The one good thing in its 
favor is that there are zero changes outside the port itself.



r~

Re: [PATCH 2/6] RISC-V Port: gcc

[Sandra Loosemore]

I didn't see a v3 with the documentation patches go by yet, and I had 
some nit-picky comments on v2 (in addition to the ones Joseph already 
asked for):


> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi

index 4b13aeb..581c4ef 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -1046,6 +1046,20 @@ See RS/6000 and PowerPC Options.
  -mstack-protector-guard-offset=@var{offset} @gol
  -mlra  -mno-lra}

+@emph{RISC-V Options}
+@gccoptlist{-mbranch-cost=@var{N-instruction} @gol
+-mmemcpy -mno-memcpy @gol
+-mplt -mno-plt @gol
+-mabi=@var{ABI-string} @gol
+-mfdiv -mno-fdiv @gol
+-mdiv -mno-div @gol
+-march=@var{ISA-string} @gol
+-mtune=@var{processor-string} @gol
+-msmall-data-limit=@var{N-bytes} @gol
+-msave-restore -mno-save-restore @gol
+-mcmodel=@var{code-model} @gol
+-mexplicit-relocs -mno-explicit-relocs @gol}


Please use 2 spaces to separate options on the same line in @gccoptlist 
instead of only 1.



@@ -13881,6 +13895,7 @@ platform.
  * PowerPC Options::
  * RL78 Options::
  * RS/6000 and PowerPC Options::
+* RISC-V Options::
  * RX Options::
  * S/390 and zSeries Options::
  * Score Options::


Can we please keep this properly alphabetized?  Likewise with the 
placement of the section itself.


-Sandra

Re: [PATCH][GIMPLEFE] Fix for ICE due to undeclared variable

[Prasad Ghangal]

On 4 January 2017 at 16:02, Richard Biener  wrote:
> On Wed, Dec 28, 2016 at 7:27 PM, Prasad Ghangal
>  wrote:
>> Hi,
>> The attached patch tries fix ICE due to undeclared variable(s) in the input.
>> Successfully bootstrapped on x86_64-pc-linux-gnu, testing is in progress
>
> Ok.
>
Can you please commit the patch? I don't have access for that.

Thanks,
Prasad

> Richard.
>
>>
>> Thanks,
>> Prasad

[PATCH/AARCH64] Change -mcpu=thunderx2t99 's -mcpu=native support

[Andrew Pinski]

Hi,
  When I implemented the -mcpu=thunderx2t99 I did not have the Cavium
partno for ThunderX CN99xx, only the original part no.  This patch
adds the new part no for the future versions of the chip.

OK?  Bootstrapped and tested on aarch64-linux-gnu with no regressions.

Thanks,
Andrew

ChangeLog:
* config/aarch64/aarch64-cores.def (thunderx2t99): Move to under 'C"
cores and change the partno/implementer to be correct.
(thunderx2t99p1): New core which replaces thunderx2t99 and still has
the 'B" as the implementer.
Index: config/aarch64/aarch64-cores.def
===
--- config/aarch64/aarch64-cores.def(revision 245203)
+++ config/aarch64/aarch64-cores.def(working copy)
@@ -67,6 +67,7 @@ AARCH64_CORE("thunderxt88p1", thunderxt8
 AARCH64_CORE("thunderxt88",   thunderxt88,   thunderx,  8A,
AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC | AARCH64_FL_CRYPTO | AARCH64_FL_LSE, 
thunderx,  0x43, 0x0a1, -1)
 AARCH64_CORE("thunderxt81",   thunderxt81,   thunderx,  8_1A,  
AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC | AARCH64_FL_CRYPTO | AARCH64_FL_LSE, 
thunderx,  0x43, 0x0a2, -1)
 AARCH64_CORE("thunderxt83",   thunderxt83,   thunderx,  8_1A,  
AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC | AARCH64_FL_CRYPTO | AARCH64_FL_LSE, 
thunderx,  0x43, 0x0a3, -1)
+AARCH64_CORE("thunderx2t99",  thunderx2t99,  thunderx2t99, 8_1A,  
AARCH64_FL_FOR_ARCH8_1 | AARCH64_FL_CRYPTO, thunderx2t99, 0x43, 0x0af, -1)
 
 /* APM ('P') cores. */
 AARCH64_CORE("xgene1",  xgene1,xgene1,8A,  AARCH64_FL_FOR_ARCH8, 
xgene1, 0x50, 0x000, -1)
@@ -74,7 +75,7 @@ AARCH64_CORE("xgene1",  xgene1,x
 /* V8.1 Architecture Processors.  */
 
 /* Broadcom ('B') cores. */
-AARCH64_CORE("thunderx2t99",  thunderx2t99, thunderx2t99, 8_1A,  
AARCH64_FL_FOR_ARCH8_1 | AARCH64_FL_CRYPTO, thunderx2t99, 0x42, 0x516, -1)
+AARCH64_CORE("thunderx2t99p1",  thunderx2t99p1, thunderx2t99, 8_1A,  
AARCH64_FL_FOR_ARCH8_1 | AARCH64_FL_CRYPTO, thunderx2t99, 0x42, 0x516, -1)
 AARCH64_CORE("vulcan",  vulcan, thunderx2t99, 8_1A,  AARCH64_FL_FOR_ARCH8_1 | 
AARCH64_FL_CRYPTO, thunderx2t99, 0x42, 0x516, -1)
 
 /* V8 big.LITTLE implementations.  */
Index: config/aarch64/aarch64-tune.md
===
--- config/aarch64/aarch64-tune.md  (revision 245203)
+++ config/aarch64/aarch64-tune.md  (working copy)
@@ -1,5 +1,5 @@
 ;; -*- buffer-read-only: t -*-
 ;; Generated automatically by gentune.sh from aarch64-cores.def
 (define_attr "tune"
-   
"cortexa35,cortexa53,cortexa57,cortexa72,cortexa73,exynosm1,falkor,qdf24xx,thunderx,thunderxt88p1,thunderxt88,thunderxt81,thunderxt83,xgene1,thunderx2t99,vulcan,cortexa57cortexa53,cortexa72cortexa53,cortexa73cortexa35,cortexa73cortexa53"
+   
"cortexa35,cortexa53,cortexa57,cortexa72,cortexa73,exynosm1,falkor,qdf24xx,thunderx,thunderxt88p1,thunderxt88,thunderxt81,thunderxt83,thunderx2t99,xgene1,thunderx2t99p1,vulcan,cortexa57cortexa53,cortexa72cortexa53,cortexa73cortexa35,cortexa73cortexa53"
(const (symbol_ref "((enum attr_tune) aarch64_tune)")))

Re: [PATCH] [AArch64] PR target/71663 Improve Vector Initializtion

[Hurugalawadi, Naveen]

Hi,

Please consider this as a personal reminder to review the patch
at following link and let me know your comments on the same.

https://gcc.gnu.org/ml/gcc-patches/2016-12/msg00718.html

Thanks,
Naveen

[unified-autovect: Patch 2/N] Implementation of k-arity promotion/reduction

[Sameera Deshpande]

Hi Richard,

Sorry for delayed patch submission. I was on maternity leave, so could not post 
earlier.
Here is the previous mail for your reference: 
https://gcc.gnu.org/ml/gcc/2016-06/msg00043.html

Please find attached the patch for stage 2: implementation of k-arity 
promotion/reduction in the series "Improving effectiveness and generality of 
autovectorization using unified representation".

The permute nodes within primitive reorder tree(PRT) generated from input 
program can have any arity depending upon stride of accesses. However, the 
target cannot have instructions to support all arities. Hence, we need to 
promote or reduce the arity of PRT to enable successful tree tiling.

In classic autovectorization, if vectorization stride > 2, arity reduction is 
performed by generating cascaded extract and interleave instructions as 
described by "Auto-vectorization of Interleaved Data for SIMD" by D. Nuzman, I. 
Rosen and A. Zaks.  

Moreover, to enable SLP across loop, "Loop-aware SLP in GCC" by D. Nuzman, I. 
Rosen and A. Zaks unrolls loop till stride = vector size.

k-arity reduction/promotion algorithm makes use of modulo arithmetic to 
generate PRT of desired arity for both above-mentioned cases.

Single ILV node of arity k can be reduced into cascaded ILV nodes with single 
node of arity m with children of arity k/m such that ith child of original ILV 
node becomes floor (i/m) th child of (i%m) th child of new parent.

Single EXTR node with k parts and i selector can be reduced into cascaded EXTR 
nodes such that parent EXTR node has m parts and i/(k/m) selection on child 
EXTR node with k/m parts and i % (k/m) selection.

Similarly, loop unrolling to get desired arity m can be represented as arity 
promotion from k to m.

Single ILV node of arity k can be promoted to single ILV node of arity m by 
adding extraction with m/k parts and selection i/k of i%k the child of original 
tree as ith child of new ILV node.

To enable loop-aware SLP, we first promote arity of input PRT to maximum vector 
size permissible on the architecture. This can have impact on vector code size, 
though performance will be the same. However, to allow variable vector size 
like SVE in NEON, it is necessary.

Later we apply arity promotion reduction algorithm on the output tree to get 
tree with desired arity. For now, we are supporting target arity = 2, as most 
of the architectures have support for that. However, the code can be extended 
for additional arity supports as well.

I have tested the code with handwritten testcases for correctness.
Do you spot any problem in the logic or arithmetic that I am performing for 
reduction/promotion? If not, will push this patch on the branch that we have 
created - unified-autovect.

- Thanks and regards,
  Sameera D.Index: gcc/Makefile.in
===
--- gcc/Makefile.in	(revision 243687)
+++ gcc/Makefile.in	(working copy)
@@ -1529,6 +1529,7 @@
 	tree-vect-slp.o \
 	tree-vectorizer.o \
 	tree-vect-unified.o \
+	tree-vect-unified-opts.o \
 	tree-vrp.o \
 	tree.o \
 	valtrack.o \
Index: gcc/tree-vect-data-refs.c
===
--- gcc/tree-vect-data-refs.c	(revision 238158)
+++ gcc/tree-vect-data-refs.c	(working copy)
@@ -136,16 +136,9 @@
   return scalar_type;
 }
 
-
-/* Insert DDR into LOOP_VINFO list of ddrs that may alias and need to be
-   tested at run-time.  Return TRUE if DDR was successfully inserted.
-   Return false if versioning is not supported.  */
-
-static bool
-vect_mark_for_runtime_alias_test (ddr_p ddr, loop_vec_info loop_vinfo)
+bool
+vect_mark_for_runtime_alias_test_1 (ddr_p ddr, loop *loop)
 {
-  struct loop *loop = LOOP_VINFO_LOOP (loop_vinfo);
-
   if ((unsigned) PARAM_VALUE (PARAM_VECT_MAX_VERSION_FOR_ALIAS_CHECKS) == 0)
 return false;
 
@@ -189,11 +182,28 @@
   return false;
 }
 
-  LOOP_VINFO_MAY_ALIAS_DDRS (loop_vinfo).safe_push (ddr);
   return true;
 }
 
 
+
+/* Insert DDR into LOOP_VINFO list of ddrs that may alias and need to be
+   tested at run-time.  Return TRUE if DDR was successfully inserted.
+   Return false if versioning is not supported.  */
+
+static bool
+vect_mark_for_runtime_alias_test (ddr_p ddr, loop_vec_info loop_vinfo)
+{
+  struct loop *loop = LOOP_VINFO_LOOP (loop_vinfo);
+  bool is_alias;
+
+  is_alias = vect_mark_for_runtime_alias_test_1 (ddr, loop);
+  if (is_alias)
+LOOP_VINFO_MAY_ALIAS_DDRS (loop_vinfo).safe_push (ddr);
+  return is_alias;
+}
+
+
 /* Function vect_analyze_data_ref_dependence.
 
Return TRUE if there (might) exist a dependence between a memory-reference
Index: gcc/tree-vect-unified-opts.c
===
--- gcc/tree-vect-unified-opts.c	(revision 0)
+++ gcc/tree-vect-unified-opts.c	(working copy)
@@ -0,0 +1,391 @@
+/* lOOP Vectorization using unified representation
+the terms of the GNU General Public License as published by the Free
+So

Re: [GIMPLE FE] Avoid ICE with __builtin_abs

[Richard Biener]

On Sat, 4 Feb 2017, Prathamesh Kulkarni wrote:

> Hi,
> The following test-case ICE's with -fgimple:
> 
> int __GIMPLE foo(int a)
> {
>   int t1;
>   t1_1 = __builtin_abs (a);
>   return t1_1;
> }
> 
> gimplefe-2.c:4:3: internal compiler error: in get_callee_fndecl, at 
> tree.c:9500
>t1_1 = __builtin_abs (a);
>^~~~
> 0xe96e8d get_callee_fndecl(tree_node const*)
> ../../gcc/gcc/tree.c:9500
> 0x924d75 gimple_build_call_from_tree(tree_node*)
> ../../gcc/gcc/gimple.c:351
> 0x6c86b3 c_parser_gimple_statement
> ../../gcc/gcc/c/gimple-parser.c:393
> 0x6c86b3 c_parser_gimple_compound_statement
> ../../gcc/gcc/c/gimple-parser.c:216
> 0x6c86b3 c_parser_parse_gimple_body(c_parser*)
> ../../gcc/gcc/c/gimple-parser.c:93
> 0x6b04f1 c_parser_declaration_or_fndef
> ../../gcc/gcc/c/c-parser.c:2081
> 0x6b883b c_parser_external_declaration
> ../../gcc/gcc/c/c-parser.c:1464
> 0x6b92a1 c_parser_translation_unit
> ../../gcc/gcc/c/c-parser.c:1344
> 0x6b92a1 c_parse_file()
> ../../gcc/gcc/c/c-parser.c:18141
> 0x717832 c_common_parse_file()
> ../../gcc/gcc/c-family/c-opts.c:1102
> 
> This happens because __builtin_abs(a) gets folded to >
> and get_callee_fndecl expects CALL_EXPR.
> 
> The attached patch tries to fix the issue by building gimple_assign
> with appropriate subcode
> for functions that get folded to expression instead of trying to build
> it as a function-call.
> Is it OK to commit after bootstrap+test ?

No.  The proper fix is to not use the C frontend call-expr parsing
and building -- it does have many more issues I think.

Richard.

> Thanks,
> Prathamesh
> 

-- 
Richard Biener 
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 
21284 (AG Nuernberg)