Re: [PATCH, i386, AVX-512] Split out mask version for vec_extract_hi_.

[Kirill Yukhin]

Hi Jakub,
On 28 Dec 14:52, Jakub Jelinek wrote:
> On Mon, Dec 28, 2015 at 04:17:02PM +0300, Kirill Yukhin wrote:
> > Hello,
> > On 02 Dec 20:00, Kirill Yukhin wrote:
> > > Hello,
> > > On 30 Nov 13:46, Kirill Yukhin wrote:
> > > > Hello,
> > > > Patch in the bottom splits masked version of vec_extract_hi_
> > > > to block AVX-1512VL insn generation for KNL and cures ICE on 
> > > > spec2k6/450.soplex.
> > > > 
> > > > Bootstrapped and regtesed.
> > > > 
> > > > If no objections - I'll commit on Wednesday.
> > > > 
> > > > gcc/
> > > > * config/i386/sse.md (define_insn 
> > > > "vec_extract_hi__maskm"):
> > > > Remove "prefix_extra".
> > > > (define_insn "vec_extract_hi__mask"): New.
> > > > (define_insn "vec_extract_hi_"): Remove masking.
> > > > gcc/testsuite/
> > > > * gcc.target/i386/avx512vl-vextractf32x4-1.c: Fix scan pattern.
> > Similar patch is needed to make spec2k6/465.tonto working for gcc-5.
> > Is patch in the bottom ok for  gcc-5-branch if bootstrapped and regtested?
> > It cures spec2k6/465.tonto illegal insn emit.
> 
> Can you add a runtime testcase that would fail without the patch and succeed
> with it?  Perhaps add some asms etc. to force the operands to look similarly
> for RA purposes.  The patch is ok with or without that testcase, though the
> testcase would be greatly appreciated.
I've prepared a testcase which fails to assemble w/o patch and passes when
it is applied.

If no more objections - I'll commit changes tomorrow.

gcc/testsuite/
* gcc.target/i386/avx-vextractf128-256-5.c: New test.

--
Thanks, K
> 
>   Jakub

commit 4bb1c06d563d995743b62a244511450cde93aa11
Author: Kirill Yukhin 
Date:   Tue Dec 29 11:42:55 2015 +0300

Fix 465.tonto. Add test.

diff --git a/gcc/testsuite/gcc.target/i386/avx-vextractf128-256-5.c 
b/gcc/testsuite/gcc.target/i386/avx-vextractf128-256-5.c
new file mode 100644
index 000..6001856
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/avx-vextractf128-256-5.c
@@ -0,0 +1,12 @@
+/* { dg-require-effective-target avx512f } */
+/* { dg-do assemble { target { ! { ia32 } } } } */
+/* { dg-options "-O2 -mavx512f" } */
+
+#include 
+
+register __m512d z asm ("zmm16"); /* { dg-warning "call-clobbered register 
used for global register variable" } */
+
+__m128d foo ()
+{
+  return _mm256_extractf128_pd (_mm512_extractf64x4_pd(z, 0), 1);
+}

Re: [PATCH] testsuite/lib/multline.exp: show test name and line numbers

[Uros Bizjak]

Hello!

> Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu;
> I compared the results against a control build (of r231445), and
> the results were unchanged, other than the expected changes from
> the above, leading to
> - 92 PASS results changing name within g++.sum
> - 7 PASS results changing name within each of obj-c++.sum
>   and objc.sum, and
> - 125 PASS results changing name within gcc.sum.
>
> OK for trunk for gcc 6?
>
> gcc/testsuite/ChangeLog:
> * lib/multiline.exp (_multiline_expected_outputs): Update comment.
> (dg-end-multiline-output): Capture line numbers within
> _multiline_expected_outputs.
> (handle-multiline-outputs): Access global $testname_with_flags
> and add it as a prefix to pass/fail results.  Extract line numbers
> from $_multiline_expected_outputs and print them within pass/fail
> results, replacing the printing of $index.  Consolidate the
> string prefix shared between pass/fail into a new local: $title.

It looks that this new functionality doesn't handle conditional
compilation, when

/* { dg-do compile { target { ! ia32 } } } */

is added to the testcase, such as in recently changed
gcc.target/i386/pr68473-1.c.

The directive is passed to the next testcase, leading to spurious
testsuite failures [1] in unrelated testcases.

[1] https://gcc.gnu.org/ml/gcc-testresults/2015-12/msg02761.html

Uros.

Re: [PATCH, middle-end]: Fix PR68999, gfortran.fortran-torture/execute/save_1.f90 execution failure on alpha

[Uros Bizjak]

On Wed, Dec 23, 2015 at 7:30 PM, Richard Biener
 wrote:
> On December 23, 2015 5:58:07 PM GMT+01:00, Uros Bizjak  
> wrote:
>>On Wed, Dec 23, 2015 at 2:39 PM, Richard Biener
>> wrote:
>>> On December 23, 2015 10:39:17 AM GMT+01:00, Uros Bizjak
>> wrote:
Hello!

There is a logic error in Honza's patch "Transparent alias suport
>>part
10" [1]. The part in memrefs_conflict_p should be changed to:

-  /* If decls are different or we know by offsets that there is
>>no
overlap,
- we win.  */
-  if (!cmp || !offset_overlap_p (c, xsize, ysize))
+  /* If decls are different and we know by offsets that
+ there is no overlap, we win.  */
+  if (!cmp && !offset_overlap_p (c, xsize, ysize))
  return 0;
-  /* Decls may or may not be different and offsets overlap*/
+  /* Decls are different and offsets overlap*/

Even if decls are different, their offsets shouldn't overlap!
>>>
>>> Comparing offsets of different decls does not make sense.
>>
>>Uh, yes, some more eyeballing was needed, but you are right.
>>
>>Is there a way to detect aliasing in case AND addresses are involved?
>>
>>Probably we need something like in base_alias_check, where:
>
> Yeah, and in that case just give up.

As mentioned in [1], in attached v2 patch, we return "unknown" from
memrefs_conflict_p when realigned decls are processed:

@@ -2339,6 +2337,12 @@ memrefs_conflict_p (int xsize, rtx x, int ysize, r
   /* If both decls are the same, decide by offsets.  */
   if (cmp == 1)
 return offset_overlap_p (c, xsize, ysize);
+  /* Assume a potential overlap for symbolic addresses that went
+through alignment adjustments (i.e., that have negative
+sizes), because we can't know how far they are from each
+other.  */
+  if (xsize < 0 || ysize < 0)
+   return -1;
   /* If decls are different or we know by offsets that there is no overlap,
 we win.  */
   if (!cmp || !offset_overlap_p (c, xsize, ysize))

This is the same approach as it is done at the end of memrefs_conflict_p.

We still need early return for AND addresses in base_alias_check, though.

2015-12-29  Uros Bizjak  

PR middle-end/68999
* symtab.c (symtab_node::equal_address_to): Return -1 instead of 2
if we can't determine address equivalence.
* alias.c (compare_base_decl): Update for changed return value of
symtab_node::equal_address_to.
(memrefs_conflict_p): Return -1 for different decls that went through
alignment adjustments.
(base_alias_check): Move check for addresses with alignment ANDs
before the call for compare_base_decls.

Patch was bootstrapped and regression tested on x86_64-linux-gnu
{,-m32} and alpha-linux-gnu native [2].

OK for mainline?

[1] https://gcc.gnu.org/ml/gcc-patches/2015-12/msg02174.html
[2] https://gcc.gnu.org/ml/gcc-testresults/2015-12/msg02766.html

Uros.
Index: alias.c
===
--- alias.c (revision 231971)
+++ alias.c (working copy)
@@ -2046,8 +2046,6 @@ compare_base_decls (tree base1, tree base2)
 
   ret = symtab_node::get_create (base1)->equal_address_to
 (symtab_node::get_create (base2), true);
-  if (ret == 2)
-return -1;
   return ret;
 }
 
@@ -2088,17 +2086,6 @@ base_alias_check (rtx x, rtx x_base, rtx y, rtx y_
   if (rtx_equal_p (x_base, y_base))
 return 1;
 
-  if (GET_CODE (x_base) == SYMBOL_REF && GET_CODE (y_base) == SYMBOL_REF)
-{
-  tree x_decl = SYMBOL_REF_DECL (x_base);
-  tree y_decl = SYMBOL_REF_DECL (y_base);
-
-  /* We can assume that no stores are made to labels.  */
-  if (!x_decl || !y_decl)
-   return 0;
-  return compare_base_decls (x_decl, y_decl) != 0;
-}
-
   /* The base addresses are different expressions.  If they are not accessed
  via AND, there is no conflict.  We can bring knowledge of object
  alignment into play here.  For example, on alpha, "char a, b;" can
@@ -2117,6 +2104,17 @@ base_alias_check (rtx x, rtx x_base, rtx y, rtx y_
  || (int) GET_MODE_UNIT_SIZE (x_mode) < -INTVAL (XEXP (y, 1
 return 1;
 
+  if (GET_CODE (x_base) == SYMBOL_REF && GET_CODE (y_base) == SYMBOL_REF)
+{
+  tree x_decl = SYMBOL_REF_DECL (x_base);
+  tree y_decl = SYMBOL_REF_DECL (y_base);
+
+  /* We can assume that no stores are made to labels.  */
+  if (!x_decl || !y_decl)
+   return 0;
+  return compare_base_decls (x_decl, y_decl) != 0;
+}
+
   /* Differing symbols not accessed via AND never alias.  */
   if (GET_CODE (x_base) != ADDRESS && GET_CODE (y_base) != ADDRESS)
 return 0;
@@ -2339,6 +2337,12 @@ memrefs_conflict_p (int xsize, rtx x, int ysize, r
   /* If both decls are the same, decide by offsets.  */
   if (cmp == 1)
 return offset_overlap_p (c, xsize, ysize);
+  /* Assume a potential overlap for symbolic addresses that went
+through 

Re: [PATCH, i386, AVX-512] Split out mask version for vec_extract_hi_.

[Uros Bizjak]

On Tue, Dec 29, 2015 at 9:43 AM, Kirill Yukhin  wrote:
> Hi Jakub,
> On 28 Dec 14:52, Jakub Jelinek wrote:
>> On Mon, Dec 28, 2015 at 04:17:02PM +0300, Kirill Yukhin wrote:
>> > Hello,
>> > On 02 Dec 20:00, Kirill Yukhin wrote:
>> > > Hello,
>> > > On 30 Nov 13:46, Kirill Yukhin wrote:
>> > > > Hello,
>> > > > Patch in the bottom splits masked version of vec_extract_hi_
>> > > > to block AVX-1512VL insn generation for KNL and cures ICE on 
>> > > > spec2k6/450.soplex.
>> > > >
>> > > > Bootstrapped and regtesed.
>> > > >
>> > > > If no objections - I'll commit on Wednesday.
>> > > >
>> > > > gcc/
>> > > > * config/i386/sse.md (define_insn 
>> > > > "vec_extract_hi__maskm"):
>> > > > Remove "prefix_extra".
>> > > > (define_insn "vec_extract_hi__mask"): New.
>> > > > (define_insn "vec_extract_hi_"): Remove masking.
>> > > > gcc/testsuite/
>> > > > * gcc.target/i386/avx512vl-vextractf32x4-1.c: Fix scan pattern.
>> > Similar patch is needed to make spec2k6/465.tonto working for gcc-5.
>> > Is patch in the bottom ok for  gcc-5-branch if bootstrapped and regtested?
>> > It cures spec2k6/465.tonto illegal insn emit.
>>
>> Can you add a runtime testcase that would fail without the patch and succeed
>> with it?  Perhaps add some asms etc. to force the operands to look similarly
>> for RA purposes.  The patch is ok with or without that testcase, though the
>> testcase would be greatly appreciated.
> I've prepared a testcase which fails to assemble w/o patch and passes when
> it is applied.
>
> If no more objections - I'll commit changes tomorrow.
>
> gcc/testsuite/
> * gcc.target/i386/avx-vextractf128-256-5.c: New test.
>
> --
> Thanks, K
>>
>>   Jakub
>
> commit 4bb1c06d563d995743b62a244511450cde93aa11
> Author: Kirill Yukhin 
> Date:   Tue Dec 29 11:42:55 2015 +0300
>
> Fix 465.tonto. Add test.
>
> diff --git a/gcc/testsuite/gcc.target/i386/avx-vextractf128-256-5.c 
> b/gcc/testsuite/gcc.target/i386/avx-vextractf128-256-5.c
> new file mode 100644
> index 000..6001856
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/i386/avx-vextractf128-256-5.c
> @@ -0,0 +1,12 @@
> +/* { dg-require-effective-target avx512f } */
> +/* { dg-do assemble { target { ! { ia32 } } } } */

Please use { target { ! ia32 } } here. I will remove these extra
braces from the i386 testcases soon.

Uros.

[PATCH, testsuite]: Remove extra braces from target selectors in gcc.target/i386

[Uros Bizjak]

Hello!

find . -type -f -exec sed -i 's/! { ia32 }/! ia32/g' {} \;

2015-12-28  Uros Bizjak  

* gcc.target/i386/*.c: Remove extra braces from target selectors.

Tested on x86_64-linux-gnu {,-m32}, committed to mainline SVN.

Uros.


t.diff.txt.gz
Description: GNU Zip compressed data

Re: [PATCH] Performance fix for libmpx memmove wrapper

[Ilya Enkovich]

This patch is OK.  I applied it to trunk.

Thanks,
Ilya

2015-12-24 14:24 GMT+03:00 Aleksandra Tsvetkova :
> Description:
> 2015-12-11  Tsvetkova Alexandra  
>
> * libmpxwrap/mpx_wrappers.c (__mpx_wrapper_memmove): separate
> case for size of pointer.
>
> On Thu, Dec 24, 2015 at 2:21 PM, Aleksandra Tsvetkova
>  wrote:
>> This patch was tested on spec2000, spec2006 and make check. It fixes
>> regression on vortex.
>>
>>
>> 2015-12-11  Tsvetkova Alexandra  
>>
>> * libmpxwrap/mpx_wrappers.c (mpx_pointer): New type.
>>
>>
>> diff --git a/libmpx/mpxwrap/mpx_wrappers.c b/libmpx/mpxwrap/mpx_wrappers.c
>> old mode 100644
>> new mode 100755
>> index ffa7e7e..679e546
>> --- a/libmpx/mpxwrap/mpx_wrappers.c
>> +++ b/libmpx/mpxwrap/mpx_wrappers.c
>> @@ -483,10 +483,20 @@ __mpx_wrapper_memmove (void *dst, const void
>> *src, size_t n)
>>__bnd_chk_ptr_bounds (dst, n);
>>__bnd_chk_ptr_bounds (src, n);
>>
>> +  /* This is an speedup for size of pointer.  */
>> +  if (n == sizeof (void *))
>> +  {
>> +const void **s = (const void**)src;
>> +void **d = (void**)dst;
>> +*d = *s;
>> + return dst;
>> +  }
>> +
>>memmove (dst, src, n);
>> +
>>/* Not necessary to copy bounds if size is less then size of pointer
>>   or SRC==DST.  */
>> -  if ((n >= sizeof (void *)) && (src != dst))
>> +  if ((n > sizeof (void *)) && (src != dst))
>>  move_bounds (dst, src, n);
>>
>>return dst;

Re: [Patch, pr69011, fortran, v1] [6 Regression] [OOP] ICE in gfc_advance_chain for ALLOCATE with SOURCE

[Andre Vehreschild]

Hi all, hi Thomas,

thanks for the fast review. Committed as r231992.

Regards,
Andre

On Mon, 28 Dec 2015 18:31:32 +0100
Thomas Koenig  wrote:

> Hi Andre,
> 
> > for bug pr69011 I like to propose the attached patch. The patch fixes
> > the ICE and furthermore makes sure, that for this case of referencing a
> > polymorphic object the correct vtype is selected. Previously the
> > declared vtype of the source=-expression was taken for the object(s) to
> > allocate. Now the actual vtype is taken, i.e., the vptr component of
> > source='s object is taken. This is important when source references a
> > subclass.
> >
> > Bootstrapped and regtested ok on x86_64-pc-linux-gnu/f23.
> >
> > Ok for trunk?
> 
> The patch also solves the original problem.
> 
> OK for trunk, and thanks a lot for the patch!
> 
> 
>   Thomas
> 


-- 
Andre Vehreschild * Email: vehre ad gmx dot de 
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog	(Revision 231990)
+++ gcc/fortran/ChangeLog	(Arbeitskopie)
@@ -1,3 +1,10 @@
+2015-12-29  Andre Vehreschild  
+
+	PR fortran/69011
+	* trans-stmt.c (gfc_trans_allocate): Unwrap a NOP_EXPR to make sure
+	the actual type of the source=-expr is used when it is of class type.
+	Furthermore prevent an ICE.
+
 2015-12-18  Paul Thomas  
 
 	PR fortran/68196
Index: gcc/fortran/trans-stmt.c
===
--- gcc/fortran/trans-stmt.c	(Revision 231990)
+++ gcc/fortran/trans-stmt.c	(Arbeitskopie)
@@ -5377,7 +5377,20 @@
 	  if (code->ext.alloc.arr_spec_from_expr3 || code->expr3->rank != 0)
 		gfc_conv_expr_descriptor (&se, code->expr3);
 	  else
-		gfc_conv_expr_reference (&se, code->expr3);
+		{
+		  gfc_conv_expr_reference (&se, code->expr3);
+
+		  /* gfc_conv_expr_reference wraps POINTER_PLUS_EXPR in a
+		 NOP_EXPR, which prevents gfortran from getting the vptr
+		 from the source=-expression.  Remove the NOP_EXPR and go
+		 with the POINTER_PLUS_EXPR in this case.  */
+		  if (code->expr3->ts.type == BT_CLASS
+		  && TREE_CODE (se.expr) == NOP_EXPR
+		  && TREE_CODE (TREE_OPERAND (se.expr, 0))
+			   == POINTER_PLUS_EXPR)
+		  //&& ! GFC_CLASS_TYPE_P (TREE_TYPE (se.expr)))
+		se.expr = TREE_OPERAND (se.expr, 0);
+		}
 	  /* Create a temp variable only for component refs to prevent
 		 having to go through the full deref-chain each time and to
 		 simplfy computation of array properties.  */
@@ -5494,7 +5507,6 @@
 	 expr3 may be a temporary array declaration, therefore check for
 	 GFC_CLASS_TYPE_P before trying to get the _vptr component.  */
 	  if (tmp != NULL_TREE
-	  && TREE_CODE (tmp) != POINTER_PLUS_EXPR
 	  && (e3_is == E3_DESC
 		  || (GFC_CLASS_TYPE_P (TREE_TYPE (tmp))
 		  && (VAR_P (tmp) || !code->expr3->ref))
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog	(Revision 231990)
+++ gcc/testsuite/ChangeLog	(Arbeitskopie)
@@ -1,3 +1,8 @@
+2015-12-29  Andre Vehreschild  
+
+	PR fortran/69011
+	* gfortran.dg/allocate_with_source_16.f90: New test.
+
 2015-12-28  Uros Bizjak  
 
 	* gcc.target/i386/*.c: Remove extra braces from target selectors.
Index: gcc/testsuite/gfortran.dg/allocate_with_source_16.f90
===
--- gcc/testsuite/gfortran.dg/allocate_with_source_16.f90	(nicht existent)
+++ gcc/testsuite/gfortran.dg/allocate_with_source_16.f90	(Arbeitskopie)
@@ -0,0 +1,76 @@
+! { dg-do run }
+! Test the fix for pr69011, preventing an ICE and making sure
+! that the correct dynamic type is used.
+!
+! Contributed by Thomas Koenig  
+!Andre Vehreschild  
+!
+ 
+module m1
+implicit none
+private
+public :: basetype
+
+type:: basetype
+  integer :: i
+  contains
+endtype basetype
+
+abstract interface
+endinterface
+
+endmodule m1
+
+module m2
+use m1, only : basetype
+implicit none
+integer, parameter :: I_P = 4
+
+private
+public :: factory, exttype
+
+type, extends(basetype) :: exttype
+  integer :: i2
+  contains
+endtype exttype
+
+type :: factory
+  integer(I_P) :: steps=-1 
+  contains
+procedure, pass(self), public :: construct
+endtype factory
+contains
+
+  function construct(self, previous)
+  class(basetype), intent(INOUT) :: previous(1:)
+  class(factory), intent(IN) :: self
+  class(basetype), pointer :: construct
+  allocate(construct, source=previous(self%steps))
+  endfunction construct
+endmodule m2
+
+  use m2
+  use m1
+  class(factory), allocatable :: c1
+  class(exttype), allocatable :: prev(:)
+  class(basetype), pointer :: d
+
+  allocate(c1)
+  allocate(prev(2))
+  prev(:)%i = [ 2, 3]
+  prev(:)%i2 = [ 5, 6]
+  c1%steps= 1
+  d=> c1%construct(prev)
+
+  if (.not. associated(d) ) call abort()
+  select type (d)
+class is (exttype)
+  if (d%i2 /= 5) call abort()
+class default
+  call abort()
+  end select 
+  if 

[gomp4] kernels offload fns

[Nathan Sidwell]

In developing a non-unity default partition mechanism I discovered there was no 
mechanism to reliably determine whether an offload was for a kernels region or 
not.  The tree-ssa pass uses a heuristic that is sufficient for its  needs, but 
not very clear.


This patch adjusts set_oacc_fn_attrib to accept a 'kernels' parameter, which it 
encodes on the TREE_PUBLIC flag of the  attribute values.  I add an 
oacc_fn_attrib_kernels_p predicate and use it where needed.


(The defaulting mechanism needs to reliably determine kernels from parallel 
offload regions).


nathnan
2015-12-29  Nathan Sidwell  

	* omp-low.c (set_oacc_fn_attrib): Add IS_KERNEL arg, encode on
	TREE_PUBLIC.
	(oacc_fn_attrib_kernels_p): New.
	(oacc_fn_attrib_level): New.
	(expand_omp_target): Pass kernels_p to set_oacc_fn_attrib.
	(oacc_validate_dims): Add LEVEL arg, don't return it.
	(new_oacc_loop_routine): Use oacc_fn_attrib_level, not
	oacc_validate_dims.
	(execute_oacc_device_lower): Use oacc_fn_attrib_level, validate
	dimensions after discovering loops.  Add more dump info.
	* omp-low.h (set_oacc_fn_attrib): Add IS_KERNEL arg.
	(oacc_fn_attrib_kernels_p): Declare.
	* tree-parloops.c (create_parallel_loop): Adjust
	set_oacc_fn_attrib call.
	* tree-ssa-loop.c (gate_oacc_kernels): Use oacc_fn_attrib_kernels_p.

Index: gcc/omp-low.c
===
--- gcc/omp-low.c	(revision 231992)
+++ gcc/omp-low.c	(working copy)
@@ -12625,10 +12625,11 @@ replace_oacc_fn_attrib (tree fn, tree di
 
 /* Scan CLAUSES for launch dimensions and attach them to the oacc
function attribute.  Push any that are non-constant onto the ARGS
-   list, along with an appropriate GOMP_LAUNCH_DIM tag.  */
+   list, along with an appropriate GOMP_LAUNCH_DIM tag.  IS_KERNEL is
+   true, if these are for a kernels region offload function.  */
 
 void
-set_oacc_fn_attrib (tree fn, tree clauses, vec *args)
+set_oacc_fn_attrib (tree fn, tree clauses, bool is_kernel, vec *args)
 {
   /* Must match GOMP_DIM ordering.  */
   static const omp_clause_code ids[]
@@ -12653,6 +12654,9 @@ set_oacc_fn_attrib (tree fn, tree clause
 	  non_const |= GOMP_DIM_MASK (ix);
 	}
   attr = tree_cons (NULL_TREE, dim, attr);
+  /* Note kernelness with TREE_PUBLIC.  */
+  if (is_kernel)
+	TREE_PUBLIC (attr) = 1;
 }
 
   replace_oacc_fn_attrib (fn, attr);
@@ -12721,6 +12725,36 @@ get_oacc_fn_attrib (tree fn)
   return lookup_attribute (OACC_FN_ATTRIB, DECL_ATTRIBUTES (fn));
 }
 
+/* Return true if this oacc fn attrib is for a kernels offload
+   region.  We use the TREE_PUBLIC flag of each dimension -- only
+   need to check the first one.  */
+
+bool
+oacc_fn_attrib_kernels_p (tree attr)
+{
+  return TREE_PUBLIC (TREE_VALUE (attr));
+}
+
+/* Return level at which oacc routine may spawn a partitioned loop, or
+   -1 if it is not a routine (i.e. is an offload fn).  */
+
+int
+oacc_fn_attrib_level (tree attr)
+{
+  tree pos = TREE_VALUE (attr);
+
+  if (!TREE_PURPOSE (pos))
+return -1;
+  
+  int ix = 0;
+  for (ix = 0; ix != GOMP_DIM_MAX;
+   ix++, pos = TREE_CHAIN (pos))
+if (!integer_zerop (TREE_PURPOSE (pos)))
+  break;
+
+  return ix;
+}
+
 /* Extract an oacc execution dimension from FN.  FN must be an
offloaded function or routine that has already had its execution
dimensions lowered to the target-specific values.  */
@@ -13045,6 +13079,7 @@ expand_omp_target (struct omp_region *re
   enum built_in_function start_ix;
   location_t clause_loc;
   unsigned int flags_i = 0;
+  bool oacc_kernels_p = false;
 
   switch (gimple_omp_target_kind (entry_stmt))
 {
@@ -13064,8 +13099,10 @@ expand_omp_target (struct omp_region *re
   start_ix = BUILT_IN_GOMP_TARGET_ENTER_EXIT_DATA;
   flags_i |= GOMP_TARGET_FLAG_EXIT_DATA;
   break;
-case GF_OMP_TARGET_KIND_OACC_PARALLEL:
 case GF_OMP_TARGET_KIND_OACC_KERNELS:
+  oacc_kernels_p = true;
+  /* FALLTHROUGH */
+case GF_OMP_TARGET_KIND_OACC_PARALLEL:
   start_ix = BUILT_IN_GOACC_PARALLEL;
   break;
 case GF_OMP_TARGET_KIND_OACC_DATA:
@@ -13247,7 +13284,7 @@ expand_omp_target (struct omp_region *re
   break;
 case BUILT_IN_GOACC_PARALLEL:
   {
-	set_oacc_fn_attrib (child_fn, clauses, &args);
+	set_oacc_fn_attrib (child_fn, clauses, oacc_kernels_p, &args);
 	tagging = true;
   }
   /* FALLTHRU */
@@ -19259,17 +19296,17 @@ oacc_xform_loop (gcall *call)
 }
 
 /* Validate and update the dimensions for offloaded FN.  ATTRS is the
-   raw attribute.  DIMS is an array of dimensions, which is returned.
-   Returns the function level dimensionality --  the level at which an
-   offload routine wishes to partition a loop.  */
+   raw attribute.  DIMS is an array of dimensions, which is filled in.
+   LEVEL is the partitioning level of a routine, or -1 for an offload
+   region itself.  */
 
-static int
-oacc_validate_dims (tree fn, tree attrs, int *dims)
+static void
+oacc_validate_dims (tree fn, tree attrs, i

[PATCH], PowerPC IEEE 128-bit fp, patch #10 (comparison, documentation, conversion, debug)

[Michael Meissner]

This is a clean-up patch for IEEE 128-bit floating point support on the
PowerPC.

The main change is to change the way comparisons are done when IEEE 128-bit
floating is emulated.  Previously, I had added special __cmpkf2 and __cmpukf2
functions that were modeled on the CR bits that the XSCMPUQP instruction sets.
I have changed this to use the standard EQ, GE, LE, and UNORD functions
provided by glibc/libgcc's software floating point emulation functions.

I've done some debugging on issues with _Complex __float128, and I think at the
moment it is just not feasible to support _Complex __float128 in GCC 6.x.  The
main problem is the way the IFmode/KFmode types are added as fractional floating
point types which prevents them from being default types for conversion.  I
think in order to support this, the machine independent type system is going to
have to be tinkered with.  However, since we are now coming to the end of
stage3 it is not the time to be making these changes.

I added documentation to state that right now -mfloat128 is only enabled on
64-bit PowerPC Linux systems.  There is some desire for this to be eventually
supported on other systems like FreeBSD, but I wanted to set expectations for
users interested in the this.  I also documented that complex __float128
currently does not work.

I added an undocumented debug switch (-mfloat128-convert) that enables default
conversions between IBM extended double and IEEE 128-bit floating point, to
enable further debugging of the complex __float128 support in the future.

Finally, I noticed if you use -mabi=ieeelongdouble, that it generated calls to
convert between long double and explicit __float128, even though they are the
same representation, and fixed that.

Going forward, patch #11 will enable the software emulation library.  At the
moment, there is no support for converting between decimal types and
__float128, nor for the complex __float128 support.  These are being worked on,
and should be done in the GCC 7.x time frame.  However, it is important to add
the software emulation support in GCC 6.x so that most users that want to use
IEEE 128-bit floating point can use it, and that we can work on the glibc
issues to fully support __float128 in the GCC 7.x time frame.

2015-12-29  Michael Meissner  

* config/rs6000/rs6000.c (init_float128_ieee): Remove IEEE 128-bit
comparison functions in cmp_optab and ucmp_optab.
(rs6000_generate_compare): Rewrite IEEE 128-bit floating point
software emulation comparisons to only use __eqkf2, __gekf2,
__lekf2, and __unordkf2 functions.
(rs6000_invalid_binary_op): Add support for -mfloat128-convert.

* config/rs6000/rs6000-c.c (rs6000_cpu_cpp_builtins): Define
__FLOAT128_HARDWARE__ if hardware IEEE 128-bit support is
available.

* config/rs6000/rs6000.opt (-mfloat128-convert): Add debug switch
to allow IBM extended double and IEEE 128-bit floating point to be
converted with default conversions.

* config/rs6000/rs6000.md (extendkftf2): Add converters between
KFmode and TFmode if -mabi=ieeelongdouble.
(trunctfkf2): Likewise.
(ieee128_mfvsrd): Split 64-bit integer conversions into 32-bit and
64-bit insns.
(ieee128_mfvsrd_64bit): Likewise.
(ieee128_mfvsrd_32bit): Likewise.
(ieee128_mtvsrd): Likewise.
(ieee128_mtvsrd_64bit): Likewise.
(ieee128_mtvsrd_32bit): Likewise.

* doc/extend.texi (Floating Types): Document that complex
__float128 does not work currently.

* doc/invoke.texi (RS/6000 and PowerPC Options): Document that
-mfloat128 is only supported on PowerPC 64-bit Linux systems.


-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  
(.../svn+ssh://meiss...@gcc.gnu.org/svn/gcc/trunk/gcc/config/rs6000)
(revision 231978)
+++ gcc/config/rs6000/rs6000.c  (.../gcc/config/rs6000) (working copy)
@@ -16501,8 +16501,6 @@ init_float128_ieee (machine_mode mode)
   set_optab_libfunc (lt_optab, mode, "__ltkf2");
   set_optab_libfunc (le_optab, mode, "__lekf2");
   set_optab_libfunc (unord_optab, mode, "__unordkf2");
-  set_optab_libfunc (cmp_optab, mode, "__cmpokf2");/* 
fcmpo */
-  set_optab_libfunc (ucmp_optab, mode, "__cmpukf2");   /* fcmpu */
 
   set_conv_libfunc (sext_optab, mode, SFmode, "__extendsfkf2");
   set_conv_libfunc (sext_optab, mode, DFmode, "__extenddfkf2");
@@ -20297,7 +20295,9 @@ rs6000_generate_compare (rtx cmp, machin
   rtx op0 = XEXP (cmp, 0);
   rtx op1 = XEXP (cmp, 1);
 
-  if (FLOAT_MODE_P (mode))
+  if (!TARGET_FLOAT128_HW && FLOAT128_VECTOR_P (mode))
+comp_mode = CCmode;
+  else if (FLOAT_MODE_P (mode))
 comp_mod

Re: [PATCH], PowerPC IEEE 128-bit fp, patch #10 (comparison, documentation, conversion, debug)

[David Edelsohn]

On Tue, Dec 29, 2015 at 10:43 AM, Michael Meissner
 wrote:
> This is a clean-up patch for IEEE 128-bit floating point support on the
> PowerPC.
>
> The main change is to change the way comparisons are done when IEEE 128-bit
> floating is emulated.  Previously, I had added special __cmpkf2 and __cmpukf2
> functions that were modeled on the CR bits that the XSCMPUQP instruction sets.
> I have changed this to use the standard EQ, GE, LE, and UNORD functions
> provided by glibc/libgcc's software floating point emulation functions.
>
> I've done some debugging on issues with _Complex __float128, and I think at 
> the
> moment it is just not feasible to support _Complex __float128 in GCC 6.x.  The
> main problem is the way the IFmode/KFmode types are added as fractional 
> floating
> point types which prevents them from being default types for conversion.  I
> think in order to support this, the machine independent type system is going 
> to
> have to be tinkered with.  However, since we are now coming to the end of
> stage3 it is not the time to be making these changes.
>
> I added documentation to state that right now -mfloat128 is only enabled on
> 64-bit PowerPC Linux systems.  There is some desire for this to be eventually
> supported on other systems like FreeBSD, but I wanted to set expectations for
> users interested in the this.  I also documented that complex __float128
> currently does not work.
>
> I added an undocumented debug switch (-mfloat128-convert) that enables default
> conversions between IBM extended double and IEEE 128-bit floating point, to
> enable further debugging of the complex __float128 support in the future.
>
> Finally, I noticed if you use -mabi=ieeelongdouble, that it generated calls to
> convert between long double and explicit __float128, even though they are the
> same representation, and fixed that.
>
> Going forward, patch #11 will enable the software emulation library.  At the
> moment, there is no support for converting between decimal types and
> __float128, nor for the complex __float128 support.  These are being worked 
> on,
> and should be done in the GCC 7.x time frame.  However, it is important to add
> the software emulation support in GCC 6.x so that most users that want to use
> IEEE 128-bit floating point can use it, and that we can work on the glibc
> issues to fully support __float128 in the GCC 7.x time frame.
>
> 2015-12-29  Michael Meissner  
>
> * config/rs6000/rs6000.c (init_float128_ieee): Remove IEEE 128-bit
> comparison functions in cmp_optab and ucmp_optab.
> (rs6000_generate_compare): Rewrite IEEE 128-bit floating point
> software emulation comparisons to only use __eqkf2, __gekf2,
> __lekf2, and __unordkf2 functions.
> (rs6000_invalid_binary_op): Add support for -mfloat128-convert.
>
> * config/rs6000/rs6000-c.c (rs6000_cpu_cpp_builtins): Define
> __FLOAT128_HARDWARE__ if hardware IEEE 128-bit support is
> available.
>
> * config/rs6000/rs6000.opt (-mfloat128-convert): Add debug switch
> to allow IBM extended double and IEEE 128-bit floating point to be
> converted with default conversions.
>
> * config/rs6000/rs6000.md (extendkftf2): Add converters between
> KFmode and TFmode if -mabi=ieeelongdouble.
> (trunctfkf2): Likewise.
> (ieee128_mfvsrd): Split 64-bit integer conversions into 32-bit and
> 64-bit insns.
> (ieee128_mfvsrd_64bit): Likewise.
> (ieee128_mfvsrd_32bit): Likewise.
> (ieee128_mtvsrd): Likewise.
> (ieee128_mtvsrd_64bit): Likewise.
> (ieee128_mtvsrd_32bit): Likewise.
>
> * doc/extend.texi (Floating Types): Document that complex
> __float128 does not work currently.
>
> * doc/invoke.texi (RS/6000 and PowerPC Options): Document that
> -mfloat128 is only supported on PowerPC 64-bit Linux systems.

Okay.

Thanks, David

[PATCH], PowerPC IEEE 128-bit fp, #11 (enable libgcc conversions)

[Michael Meissner]

This patch enables support of the __float128 software emulation functions in
libgcc.  The patch is reworked from previous versions of this patch (listed as
patch #8).

This patch adds support for declaring emulation functions that either use the
software emulation functions from the soft-fp subdirectory converted for
PowerPC __float128 via sed, or by using the hardware instructions that will be
present in ISA 3.0 (power9).  Thus if you compile code for power7/power8 and
run it on a power9 system, it use the hardware support when running on power9.

I removed the old comparison functions that was in previous versions of this
patch, and instead went with the standard EQ, GE, LE, and UNORD software
emulation support (patch #10 changes the compiler to use these functions).

This patch adds support to use the hardware rounding modes and exceptions for
software emulation that was done by Steven Munroe and Tulio Magno.

The __float128 support is only enabled on 64-bit PowerPC Linux systems, where
the base compler targets at least power7.  On big endian systems, you can use
__float128 in 32-bit mode, but the support functions are not built on a purely
32-bit system.

At the moment, there is no support for converting between decimal types and
__float128, nor for the complex __float128 support.  These are being worked on,
and should be done in the GCC 7.x time frame.  However, it is important to add
the software emulation support in GCC 6.x now so that most users that want to
use IEEE 128-bit floating point can use it, and that we can work on the glibc
issues to fully support __float128 in the GCC 7.x time frame.  There might be
problems that need to be fixed, but without the libgcc changes, nobody can use
__float128.

I have done bootstraps on a big-endian power7 system and little-endian power8
system with no regressions.  I have also built a compiler on a SLES 11.3 system
to make sure that it builds on systems without the ISA 3.0 instructions (in
this case, the ifunc resolver always returns the software emulation function).
Is this ok to install in the tree along with IEEE patch #10?

2015-12-29  Michael Meissner  
Steven Munroe (munro...@linux.vnet.ibm.com)
Tulio Magno Quites Machado Filho 

* config/rs6000/floattikf-sw.c: New file to convert signed 128-bit
integers to IEEE 128-bit floating point.

* config/rs6000/float128-hw.c: New file for ISA 3.0 IEEE 128-bit
floating point hardware support.

* config/rs6000/fixkfti-sw.c: New file to convert IEEE 128-bit
floating point to signed 128-bit integer.

* config/rs6000/float128-ifunc.c: New file to pick either IEEE
128-bit floating point software emulation or use ISA 3.0 hardware
support if it is available.

* config/rs6000/fixunskfti-sw.c: New file to convert IEEE 128-bit
floating point to unsigned 128-bit integer.

* config/rs6000/extendkftf2-sw.c: New file to convert IBM extended
double to IEEE 128-bit floating point.

* config/rs6000/floatuntikf-sw.c: New file to convert unsigned
128-bit integer to IEEE 128-bit floating point.

* config/rs6000/trunctfkf2-sw.c: New file to convert IEEE 128-bit
floating point to IBM extended double.

* config/rs6000/t-float128: New file to build IEEE 128-bit
floating point emulator functions.

* config/rs6000/t-float128-hw: New file to build IEEE 128-bit
floating point emulator functions using ISA 3.0 hardware
instructions.

* config/rs6000/sfp-exceptions.c: New file to provide exception
support for IEEE 128-bit floating point.

* config/rs6000/quad-float128.h: New file to support IEEE 128-bit
floating point.

* config/rs6000/float128-sed: New file to convert TF names to KF
names for PowerPC IEEE 128-bit floating point support.

* config/rs6000/sfp-machine.h (_FP_W_TYPE_SIZE): Use 64-bit types
when building on 64-bit systems, or when VSX is enabled.
(_FP_W_TYPE): Likewise.
(_FP_WS_TYPE): Likewise.
(_FP_I_TYPE): Likewise.
(TItype): Define on 64-bit systems.
(UTItype): Likewise.
(TI_BITS): Likewise.
(_FP_MUL_MEAT_D): Add support for using 64-bit types.
(_FP_MUL_MEAT_Q): Likewise.
(_FP_DIV_MEAT_D): Likewise.
(_FP_DIV_MEAT_Q): Likewise.
(_FP_NANFRAC_D): Likewise.
(_FP_NANFRAC_Q): Likewise.
(ISA_BIT): Add exception support.
(FP_EX_INVALID): Likewise.
(FP_EX_OVERFLOW): Likewise.
(FP_EX_UNDERFLOW): Likewise.
(FP_EX_DIVZERO): Likewise.
(FP_EX_INEXACT): Likewise.
(FP_EX_ALL): Likewise.
(__sfp_handle_exceptions): Likewise.
(FP_HANDLE_EXCEPTIONS): Likewise.
(FP_RND_NEAREST): Likewise.
(FP_RND_ZERO): Likewise.
(FP_RND_PINF): Likewise.
(FP_RND_MINF): Likewise.
(FP_RND_MASK): Likewi

Re: [PATCH], PowerPC IEEE 128-bit fp, #11 (enable libgcc conversions)

[Michael Meissner]

In my last patch (#11) on libgcc, I didn't submit the latest version of the
patch that allowed it to work on older systems that did not have the include
sys/auxv.h. This patch fixes that by moving the include of sys/auxv.h to within
the code protected by the define that says we have IEEE 128-bit floating point
hardware support and the include file sys/auxv.h.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Index: libgcc/config/rs6000/floattikf-sw.c
===
--- libgcc/config/rs6000/floattikf-sw.c 
(.../svn+ssh://meiss...@gcc.gnu.org/svn/gcc/trunk/libgcc)   (revision 0)
+++ libgcc/config/rs6000/floattikf-sw.c (.../libgcc)(revision 231985)
@@ -0,0 +1,51 @@
+/* Software floating-point emulation, convert a 128bit signed integer to IEEE
+   quad.
+
+   Copyright (C) 2015 Free Software Foundation, Inc.
+   This file is part of the GNU C Library.
+   Contributed by Steven Munroe (munro...@linux.vnet.ibm.com)
+   Code is based on the main soft-fp library written by:
+  Uros Bizjak (ubiz...@gmail.com).
+
+   The GNU C Library is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Lesser General Public
+   License as published by the Free Software Foundation; either
+   version 2.1 of the License, or (at your option) any later version.
+
+   In addition to the permissions in the GNU Lesser General Public
+   License, the Free Software Foundation gives you unlimited
+   permission to link the compiled version of this file into
+   combinations with other programs, and to distribute those
+   combinations without any restriction coming from the use of this
+   file.  (The Lesser General Public License restrictions do apply in
+   other respects; for example, they cover modification of the file,
+   and distribution when not linked into a combine executable.)
+
+   The GNU C Library is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   Lesser General Public License for more details.
+
+   You should have received a copy of the GNU Lesser General Public
+   License along with the GNU C Library; if not, see
+   .  */
+
+#ifdef _ARCH_PPC64
+#include "soft-fp.h"
+#include "quad-float128.h"
+
+TFtype
+__floattikf_sw (TItype i)
+{
+  FP_DECL_EX;
+  FP_DECL_Q (A);
+  TFtype a;
+
+  FP_INIT_ROUNDMODE;
+  FP_FROM_INT_Q (A, i, TI_BITS, UTItype);
+  FP_PACK_RAW_Q (a, A);
+  FP_HANDLE_EXCEPTIONS;
+
+  return a;
+}
+#endif
Index: libgcc/config/rs6000/float128-hw.c
===
--- libgcc/config/rs6000/float128-hw.c  
(.../svn+ssh://meiss...@gcc.gnu.org/svn/gcc/trunk/libgcc)   (revision 0)
+++ libgcc/config/rs6000/float128-hw.c  (.../libgcc)(revision 231985)
@@ -0,0 +1,188 @@
+/* Automatic switching between software and hardware IEEE 128-bit
+   floating-point emulation for PowerPC.
+
+   Copyright (C) 2015 Free Software Foundation, Inc.
+   This file is part of the GNU C Library.
+   Contributed by Michael Meissner (meiss...@linux.vnet.ibm.com)
+   Code is based on the main soft-fp library written by:
+   Richard Henderson (r...@cygnus.com) and
+   Jakub Jelinek (j...@ultra.linux.cz).
+
+   The GNU C Library is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Lesser General Public
+   License as published by the Free Software Foundation; either
+   version 2.1 of the License, or (at your option) any later version.
+
+   In addition to the permissions in the GNU Lesser General Public
+   License, the Free Software Foundation gives you unlimited
+   permission to link the compiled version of this file into
+   combinations with other programs, and to distribute those
+   combinations without any restriction coming from the use of this
+   file.  (The Lesser General Public License restrictions do apply in
+   other respects; for example, they cover modification of the file,
+   and distribution when not linked into a combine executable.)
+
+   The GNU C Library is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   Lesser General Public License for more details.
+
+   You should have received a copy of the GNU Lesser General Public
+   License along with the GNU C Library; if not, see
+   .  */
+
+#include 
+#include 
+
+#ifndef __FLOAT128_HARDWARE__
+#error "This module must be compiled with IEEE 128-bit hardware support"
+#endif
+
+TFtype
+__addkf3_hw (TFtype a, TFtype b)
+{
+  return a + b;
+}
+
+TFtype
+__subkf3_hw (TFtype a, TFtype b)
+{
+  return a - b;
+}
+
+TFtype
+__mulkf3_hw (TFty

Re: [PATCH][PING][PR 67425] Fix docs for -frandom-seed

[Sandra Loosemore]

On 12/29/2015 12:33 AM, Yury Gribov wrote:


Hi all,

this patch reverts invalid documentation change -frandom-seed which was
introduced by myself in r216773 a year ago.

I've checked the generated man and the only test for -frandom-seed
(gcc.dg/pr61868.c).

Ok for trunk?  I also want to backport to GCC5 branch.

[snip]

@@ -7464,7 +7464,7 @@ the first option takes effect and the subsequent options 
are
 ignored. Thus only @file{vec.miss} is produced which contains
 dumps from the vectorizer about missed opportunities.

-@item -frandom-seed=@var{number}
+@item -frandom-seed=@var{string}
 @opindex frandom-seed
 This option provides a seed that GCC uses in place of
 random numbers in generating certain symbol names


As a user reading this documentation, I wouldn't understand what kind of 
string to use as an argument here, or how GCC actually uses it. 
(Usually a "random seed" is something that is used to generate a 
reproductible sequence of "random" numbers, not something used in place 
of "random" numbers.)  Can you do something to clarify the usage, 
instead of just renaming the parameter?


-Sandra

[PATCHv2][PR 67425] Fix docs for -frandom-seed

[Yury Gribov]

On 12/29/2015 08:05 PM, Sandra Loosemore wrote:

On 12/29/2015 12:33 AM, Yury Gribov wrote:


Hi all,

this patch reverts invalid documentation change -frandom-seed which was
introduced by myself in r216773 a year ago.

I've checked the generated man and the only test for -frandom-seed
(gcc.dg/pr61868.c).

Ok for trunk?  I also want to backport to GCC5 branch.

[snip]

@@ -7464,7 +7464,7 @@ the first option takes effect and the subsequent
options are
 ignored. Thus only @file{vec.miss} is produced which contains
 dumps from the vectorizer about missed opportunities.

-@item -frandom-seed=@var{number}
+@item -frandom-seed=@var{string}
 @opindex frandom-seed
 This option provides a seed that GCC uses in place of
 random numbers in generating certain symbol names


As a user reading this documentation, I wouldn't understand what kind of
string to use as an argument here, or how GCC actually uses it. (Usually
a "random seed" is something that is used to generate a reproductible
sequence of "random" numbers, not something used in place of "random"
numbers.)  Can you do something to clarify the usage, instead of just
renaming the parameter?


Right, thanks.  I've only added description of input argument in this 
new patch.  I'll be able to submit a detailed description of 
functionality when I'm back from holidays in 2016)


-Y

>From 4f99bc09d1055e02df89c5fb1b4389d955ef78e5 Mon Sep 17 00:00:00 2001
From: Yury Gribov 
Date: Fri, 25 Dec 2015 13:57:28 +0300
Subject: [PATCH] Fix docs for -frandom-seed to allow string arguments.

2015-12-29  Yury Gribov  

	PR driver/67425
	* common.opt (frandom-seed): Fix parameter name.
	* doc/invoke.texi (frandom-seed): Ditto.  Describe parameter.
---
 gcc/common.opt  |  2 +-
 gcc/doc/invoke.texi | 10 +++---
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/gcc/common.opt b/gcc/common.opt
index 23f394d..1f0daf0 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -1909,7 +1909,7 @@ Common Var(common_deferred_options) Defer
 
 frandom-seed=
 Common Joined RejectNegative Var(common_deferred_options) Defer
--frandom-seed=	Make compile reproducible using .
+-frandom-seed=	Make compile reproducible using .
 
 ; This switch causes the command line that was used to create an
 ; object file to be recorded into the object file.  The exact format
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 4e2cf8f..112c461 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -364,7 +364,7 @@ Objective-C and Objective-C++ Dialects}.
 -fmem-report -fpre-ipa-mem-report -fpost-ipa-mem-report -fprofile-arcs @gol
 -fopt-info @gol
 -fopt-info-@var{options}@r{[}=@var{file}@r{]} @gol
--frandom-seed=@var{number} -fsched-verbose=@var{n} @gol
+-frandom-seed=@var{string} -fsched-verbose=@var{n} @gol
 -fsel-sched-verbose -fsel-sched-dump-cfg -fsel-sched-pipelining-verbose @gol
 -fstack-usage  -ftest-coverage  -ftime-report -fvar-tracking @gol
 -fvar-tracking-assignments  -fvar-tracking-assignments-toggle @gol
@@ -7464,7 +7464,7 @@ the first option takes effect and the subsequent options are
 ignored. Thus only @file{vec.miss} is produced which contains
 dumps from the vectorizer about missed opportunities.
 
-@item -frandom-seed=@var{number}
+@item -frandom-seed=@var{string}
 @opindex frandom-seed
 This option provides a seed that GCC uses in place of
 random numbers in generating certain symbol names
@@ -7473,7 +7473,11 @@ place unique stamps in coverage data files and the object files that
 produce them.  You can use the @option{-frandom-seed} option to produce
 reproducibly identical object files.
 
-The @var{number} should be different for every file you compile.
+The @var{string} can either be a number (decimal, octal or hex) or an
+arbitrary string (in which case it's converted to number by
+computing CRC32).
+
+The @var{string} should be different for every file you compile.
 
 @item -fsched-verbose=@var{n}
 @opindex fsched-verbose
-- 
1.9.1

Re: [PATCH], PowerPC IEEE 128-bit fp, #11 (enable libgcc conversions)

[David Edelsohn]

On Tue, Dec 29, 2015 at 11:38 AM, Michael Meissner
 wrote:
> This patch enables support of the __float128 software emulation functions in
> libgcc.  The patch is reworked from previous versions of this patch (listed as
> patch #8).
>
> This patch adds support for declaring emulation functions that either use the
> software emulation functions from the soft-fp subdirectory converted for
> PowerPC __float128 via sed, or by using the hardware instructions that will be
> present in ISA 3.0 (power9).  Thus if you compile code for power7/power8 and
> run it on a power9 system, it use the hardware support when running on power9.
>
> I removed the old comparison functions that was in previous versions of this
> patch, and instead went with the standard EQ, GE, LE, and UNORD software
> emulation support (patch #10 changes the compiler to use these functions).
>
> This patch adds support to use the hardware rounding modes and exceptions for
> software emulation that was done by Steven Munroe and Tulio Magno.
>
> The __float128 support is only enabled on 64-bit PowerPC Linux systems, where
> the base compler targets at least power7.  On big endian systems, you can use
> __float128 in 32-bit mode, but the support functions are not built on a purely
> 32-bit system.
>
> At the moment, there is no support for converting between decimal types and
> __float128, nor for the complex __float128 support.  These are being worked 
> on,
> and should be done in the GCC 7.x time frame.  However, it is important to add
> the software emulation support in GCC 6.x now so that most users that want to
> use IEEE 128-bit floating point can use it, and that we can work on the glibc
> issues to fully support __float128 in the GCC 7.x time frame.  There might be
> problems that need to be fixed, but without the libgcc changes, nobody can use
> __float128.
>
> I have done bootstraps on a big-endian power7 system and little-endian power8
> system with no regressions.  I have also built a compiler on a SLES 11.3 
> system
> to make sure that it builds on systems without the ISA 3.0 instructions (in
> this case, the ifunc resolver always returns the software emulation function).
> Is this ok to install in the tree along with IEEE patch #10?
>
> 2015-12-29  Michael Meissner  
> Steven Munroe (munro...@linux.vnet.ibm.com)
> Tulio Magno Quites Machado Filho 
>
> * config/rs6000/floattikf-sw.c: New file to convert signed 128-bit
> integers to IEEE 128-bit floating point.
>
> * config/rs6000/float128-hw.c: New file for ISA 3.0 IEEE 128-bit
> floating point hardware support.
>
> * config/rs6000/fixkfti-sw.c: New file to convert IEEE 128-bit
> floating point to signed 128-bit integer.
>
> * config/rs6000/float128-ifunc.c: New file to pick either IEEE
> 128-bit floating point software emulation or use ISA 3.0 hardware
> support if it is available.
>
> * config/rs6000/fixunskfti-sw.c: New file to convert IEEE 128-bit
> floating point to unsigned 128-bit integer.
>
> * config/rs6000/extendkftf2-sw.c: New file to convert IBM extended
> double to IEEE 128-bit floating point.
>
> * config/rs6000/floatuntikf-sw.c: New file to convert unsigned
> 128-bit integer to IEEE 128-bit floating point.
>
> * config/rs6000/trunctfkf2-sw.c: New file to convert IEEE 128-bit
> floating point to IBM extended double.
>
> * config/rs6000/t-float128: New file to build IEEE 128-bit
> floating point emulator functions.
>
> * config/rs6000/t-float128-hw: New file to build IEEE 128-bit
> floating point emulator functions using ISA 3.0 hardware
> instructions.
>
> * config/rs6000/sfp-exceptions.c: New file to provide exception
> support for IEEE 128-bit floating point.
>
> * config/rs6000/quad-float128.h: New file to support IEEE 128-bit
> floating point.
>
> * config/rs6000/float128-sed: New file to convert TF names to KF
> names for PowerPC IEEE 128-bit floating point support.
>
> * config/rs6000/sfp-machine.h (_FP_W_TYPE_SIZE): Use 64-bit types
> when building on 64-bit systems, or when VSX is enabled.
> (_FP_W_TYPE): Likewise.
> (_FP_WS_TYPE): Likewise.
> (_FP_I_TYPE): Likewise.
> (TItype): Define on 64-bit systems.
> (UTItype): Likewise.
> (TI_BITS): Likewise.
> (_FP_MUL_MEAT_D): Add support for using 64-bit types.
> (_FP_MUL_MEAT_Q): Likewise.
> (_FP_DIV_MEAT_D): Likewise.
> (_FP_DIV_MEAT_Q): Likewise.
> (_FP_NANFRAC_D): Likewise.
> (_FP_NANFRAC_Q): Likewise.
> (ISA_BIT): Add exception support.
> (FP_EX_INVALID): Likewise.
> (FP_EX_OVERFLOW): Likewise.
> (FP_EX_UNDERFLOW): Likewise.
> (FP_EX_DIVZERO): Likewise.
> (FP_EX_INEXACT): Likewise.
> (FP_EX_ALL): Likewise.
>

Re: [PATCH] v3 of diagnostic_show_locus and rich_location (was Re: [PATCH 2/5] Reimplement diagnostic_show_locus, introducing rich_location classes (v2))

[Mike Stump]

On Sep 25, 2015, at 1:11 PM, David Malcolm  wrote:
> +layout::layout (diagnostic_context * context,
>> +const diagnostic_info *diagnostic)
>> 
>> [...]
>> 
>> +  if (loc_range->m_finish.file != m_exploc.file)
>> +continue;
>> +  if (loc_range->m_show_caret_p)
>> +if (loc_range->m_finish.file != m_exploc.file)
>> +  continue;
>> 
>> I think the second if clause is redundant.
> 
> Good catch; thanks.

And one other nit.  You don’t validate that the range finishes on or after the 
start.  Later in the code, you require this to be the case:

bool
layout_range::contains_point (int row, int column) const
{
  gcc_assert (m_start.m_line <= m_finish.m_line);

this code cannot tolerate a range with that property.  So, either, such a range 
should never be generated, or, if it is to be generated, at least we should 
declare it awkward.  The below patch declares it to be awkward.  Without this, 
we ice on completely sane and normal code:

  #define max(i, j) sel((j), (i), (i) < (j))
  yu = max(a2, a3);

giving a valid warning.  In the code, we start on the last line, and finish on 
the first line.  The underlying problem is that we don’t track macro contexts 
properly.  sel is a compiler built-in, so, it might be funnier that just a 
normal function call.  This is from a trunk compiler from 20151201.

So, I was wondering if the problem has been fixed, or, if we should put the 
below in now, or, would you prefer to try and do up the changes to better track 
macro expansions?




diff --git a/gcc/diagnostic-show-locus.c b/gcc/diagnostic-show-locus.c
index 9e51b95..bea8423 100644
--- a/gcc/diagnostic-show-locus.c
+++ b/gcc/diagnostic-show-locus.c
@@ -455,6 +455,9 @@ layout::layout (diagnostic_context * context,
   if (loc_range->m_show_caret_p)
if (loc_range->m_caret.file != m_exploc.file)
  continue;
+  /* A range that finishes before it starts is awkward.  */
+  if (loc_range->m_start.line > loc_range->m_finish.line)
+   continue;
 
   /* Passed all the tests; add the range to m_layout_ranges so that
 it will be printed.  */

New French PO file for 'gcc' (version 5.2.0)

[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 French team of translators.  The file is available at:

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

(This file, 'gcc-5.2.0.fr.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.

Re: [PATCHv2][PR 67425] Fix docs for -frandom-seed

[Sandra Loosemore]

On 12/29/2015 10:38 AM, Yury Gribov wrote:

On 12/29/2015 08:05 PM, Sandra Loosemore wrote:

[snip]

As a user reading this documentation, I wouldn't understand what kind of
string to use as an argument here, or how GCC actually uses it. (Usually
a "random seed" is something that is used to generate a reproductible
sequence of "random" numbers, not something used in place of "random"
numbers.)  Can you do something to clarify the usage, instead of just
renaming the parameter?


Right, thanks.  I've only added description of input argument in this
new patch.  I'll be able to submit a detailed description of
functionality when I'm back from holidays in 2016)


Actually, I think your revised patch is fine for user documention.  It 
just needs one little grammar tweak:



@@ -7473,7 +7473,11 @@ place unique stamps in coverage data files and the 
object files that
 produce them.  You can use the @option{-frandom-seed} option to produce
 reproducibly identical object files.

-The @var{number} should be different for every file you compile.
+The @var{string} can either be a number (decimal, octal or hex) or an
+arbitrary string (in which case it's converted to number by


s/number/a number/


+computing CRC32).
+
+The @var{string} should be different for every file you compile.

 @item -fsched-verbose=@var{n}
 @opindex fsched-verbose


OK with that change.

-Sandra