[PATCH] Fix PR69466

[Richard Biener]

The following fixes PR69466 - we try to make our lives easier
in vectorization loop manip by duplicating PHIs to random BBs
but fail to realize we can't do that for PHIs with constant args.

The fix for this PR is to simply skip those we can't duplicate
when later lock-step iterating over the source and the dest of
such copy.

A real fix would be to clean up this whole mess ...

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

Richard.

2016-01-28  Richard Biener  

PR tree-optimization/69466
* tree-vect-loop-manip.c (slpeel_duplicate_current_defs_from_edges):
Account for PHIs we couldn't duplicate.

* gfortran.dg/vect/pr69466.f90: New testcase.

Index: gcc/tree-vect-loop-manip.c
===
--- gcc/tree-vect-loop-manip.c  (revision 232867)
+++ gcc/tree-vect-loop-manip.c  (working copy)
@@ -727,17 +727,26 @@ slpeel_duplicate_current_defs_from_edges
 
   for (gsi_from = gsi_start_phis (from->dest),
gsi_to = gsi_start_phis (to->dest);
-   !gsi_end_p (gsi_from) && !gsi_end_p (gsi_to);
-   gsi_next (&gsi_from), gsi_next (&gsi_to))
+   !gsi_end_p (gsi_from) && !gsi_end_p (gsi_to);)
 {
   gimple *from_phi = gsi_stmt (gsi_from);
   gimple *to_phi = gsi_stmt (gsi_to);
   tree from_arg = PHI_ARG_DEF_FROM_EDGE (from_phi, from);
+  if (TREE_CODE (from_arg) != SSA_NAME)
+   {   
+ gsi_next (&gsi_from);
+ continue;
+   }
   tree to_arg = PHI_ARG_DEF_FROM_EDGE (to_phi, to);
-  if (TREE_CODE (from_arg) == SSA_NAME
- && TREE_CODE (to_arg) == SSA_NAME
- && get_current_def (to_arg) == NULL_TREE)
+  if (TREE_CODE (to_arg) != SSA_NAME)
+   {   
+ gsi_next (&gsi_to);
+ continue;
+   }
+  if (get_current_def (to_arg) == NULL_TREE)
set_current_def (to_arg, get_current_def (from_arg));
+  gsi_next (&gsi_from);
+  gsi_next (&gsi_to);
 }
 }
 
Index: gcc/testsuite/gfortran.dg/vect/pr69466.f90
===
--- gcc/testsuite/gfortran.dg/vect/pr69466.f90  (revision 0)
+++ gcc/testsuite/gfortran.dg/vect/pr69466.f90  (working copy)
@@ -0,0 +1,42 @@
+! { dg-do compile }
+! { dg-additional-options "-march=core-avx2" { target x86_64-*-* i?86-*-* } }
+
+ subroutine foo
+
+  integer :: a, b, c, d, e
+
+  integer, dimension(:), allocatable :: f, g, h
+
+  call zoo (a)
+  call zoo (b)
+  call zoo (c)
+
+  if(a == b) then
+ allocate(g(0:d-1), h(0:d-1))
+  else
+ allocate(g(1), h(1))
+ if (b /= 0) then
+call zoo(b)
+ endif
+  endif
+
+  if(a == b) then
+ do d=0,c-1
+ e = e + g(d)
+ if(d == 0) then
+h(d) = 0
+ else
+h(d) = h(d-1) + g(d-1)
+ endif
+ end do
+  endif
+
+  if(a == b) then
+ allocate(f(e), g(e))
+  endif
+
+  if(a == 0) then
+ call boo(e)
+  endif
+
+ end subroutine foo

Re: [PATCH, gcc7, aarch64] Add arithmetic overflow patterns

[Michael Collison]

Hi Richard,

Note that this patch appears to depend on your previous patch:

https://gcc.gnu.org/ml/gcc-patches/2016-01/txtDPaXOBMuOB.txt

for the definition of define_mode_attr DWI. I was looking at this patch 
as I was working on Bugzilla 68543 which this will address.


Regards,

Michael Collison

Re: [PATCH, PR target/69454] Disable TARGET_STV when stack is not properly aligned

[Ilya Enkovich]

2016-01-28 9:00 GMT+03:00 H.J. Lu :
> On Wed, Jan 27, 2016 at 8:36 AM, H.J. Lu  wrote:
>> On Wed, Jan 27, 2016 at 8:29 AM, Ilya Enkovich  
>> wrote:
>>> 2016-01-27 19:18 GMT+03:00 H.J. Lu :
 On Wed, Jan 27, 2016 at 8:11 AM, Ilya Enkovich  
 wrote:
> On 27 Jan 16:44, Jakub Jelinek wrote:
>> On Wed, Jan 27, 2016 at 06:34:41PM +0300, Ilya Enkovich wrote:
>> > @@ -5453,6 +5443,11 @@ ix86_option_override_internal (bool main_args_p,
>> >  opts->x_target_flags |= MASK_VZEROUPPER;
>> >if (!(opts_set->x_target_flags & MASK_STV))
>> >  opts->x_target_flags |= MASK_STV;
>> > +  /* Disable STV if -mpreferred-stack-boundary={2,3} - the needed
>>
>> The comment doesn't match the code, you disable STV only for
>> -mpreferred-stack-boundary=2.
>
> Thanks, here is an updated version.
>
> Ilya
> --
> gcc/
>
> 2016-01-27  Jakub Jelinek  
> Ilya Enkovich  
>
> PR target/69454
> * config/i386/i386.c (convert_scalars_to_vector): Remove
> stack alignment fixes.
> (ix86_option_override_internal): Disable TARGET_STV if stack
> is not properly aligned.
>
> gcc/testsuite/
>
> 2016-01-27  Ilya Enkovich  
>
> PR target/69454
> * gcc.target/i386/pr69454-1.c: New test.
> * gcc.target/i386/pr69454-2.c: New test.
>
>
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index 34b57a4..9fb8db8 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -3588,16 +3588,6 @@ convert_scalars_to_vector ()
>bitmap_obstack_release (NULL);
>df_process_deferred_rescans ();
>
> -  /* Conversion means we may have 128bit register spills/fills
> - which require aligned stack.  */
> -  if (converted_insns)
> -{
> -  if (crtl->stack_alignment_needed < 128)
> -   crtl->stack_alignment_needed = 128;
> -  if (crtl->stack_alignment_estimated < 128)
> -   crtl->stack_alignment_estimated = 128;
> -}
> -
>return 0;
>  }
>
> @@ -5453,6 +5443,11 @@ ix86_option_override_internal (bool main_args_p,
>  opts->x_target_flags |= MASK_VZEROUPPER;
>if (!(opts_set->x_target_flags & MASK_STV))
>  opts->x_target_flags |= MASK_STV;
> +  /* Disable STV if -mpreferred-stack-boundary=2 - the needed
> + stack realignment will be extra cost the pass doesn't take into
> + account and the pass can't realign the stack.  */
> +  if (ix86_preferred_stack_boundary < 64)
> +opts->x_target_flags &= ~MASK_STV;
>
> This won't work for 32-bit incoming stack boundary and 64-bit preferred
> stack boundary.  In this case, STV won't be off.  When LRA needs 64-bit
> aligned stack slot, stack must be realigned.  But for leaf function, we may
> not realign stack if ix86_minimum_alignment returns 32 for DImode.   You
> must either add assert (!TARGET_STV) before returning 32 for DImode or
> return 64 for DImode if STV is on in ix86_minimum_alignment.

TARGET_STV doesn't mean STV pass will run. We can check alignment in STV
pass gate and this assert would be wrong. If we decide STV to be dependent on
stack alignment then we shouldn't make alignment be dependent on STV. I can add
assert into convert_scalars_to_vector to check
crtl->stack_alignment_estimated >= 64
by that moment.

Thanks,
Ilya

>
>if (!ix86_tune_features[X86_TUNE_AVX256_UNALIGNED_LOAD_OPTIMAL]
>&& !(opts_set->x_target_flags & MASK_AVX256_SPLIT_UNALIGNED_LOAD))
>  opts->x_target_flags |= MASK_AVX256_SPLIT_UNALIGNED_LOAD;

 MINIMUM_ALIGNMENT keeps track stack alignment.  It is OK
 to disable STV for -mpreferred-stack-boundary=2.  But you should
 also update ix86_minimum_alignment to make sure that STV is
 disabled before returning 32 for DImode.
>>>
>>> If -mpreferred-stack-boundary=2 then STV is disabled, if STV is enabled then
>>> -mpreferred-stack-boundary>=3 and this condition in
>>> ix86_minimum_alignment works:
>>>
>>>   if (TARGET_64BIT || align != 64 || ix86_preferred_stack_boundary >= 64)
>>> return align;
>>>
>>
>> No, you shouldn't make assumptions in ix86_minimum_alignment. You
>> should check explicitly that STV is disabled in ix86_minimum_alignment.
>>
>>
>> --
>> H.J.
>
>
>
> --
> H.J.

Re: [PATCH] Fix libstdc++-v3/include/math.h:66:1 2: error: 'constexpr bool std::isnan(double)' conflicts with a previous declaration

[Jonathan Wakely]

On 27/01/16 19:49 -0500, John David Anglin wrote:

The attached patch fixes a stage1 build error compiling genautomata.c on hpux.  
We need to test for obsolete
XOPEN declarations of isinf and isnan on hpux.  Further, we need to check 
individually for isinf and isnan on hpux11
since only isnan has an obsolete XOPEN declaration.

Tested on hppa2.0w-hp-hpux11.11.


Also tests OK on x86_64-linux (with glibc 2.22).


Okay for trunk?


Yes, OK, thanks.

Re: [Patch, fortran, GCC-5/6, PR62536, v1] ICE (segfault) for invalid END BLOCK statement

[Andre Vehreschild]

Hi Jerry, hi all,

thanks for the fast review. Committed as

r232918 for gcc-5-branch, and

r232919 for trunk.

Thanks again Jerry and regards,

Andre

On Wed, 27 Jan 2016 15:19:32 -0800
Jerry DeLisle  wrote:

> On 01/27/2016 08:25 AM, Andre Vehreschild wrote:
> > Hi all,
> > 
> > attached are two patches one for trunk and one for the gcc-5-branch,
> > which fix an ICE when BLOCK statements are not closed correctly (too
> > many END BLOCKs). Unfortunately did the patch I tailored for gcc-5 not
> > work on trunk.
> > 
> > GCC 5: The ICE is prevented by making sure that gfc_current_ns is not
> > set to NULL, when too many closing END BLOCK statements are found. This
> > may lead to gfortran be in the wrong namespace, but gfortran is already
> > in error. Therefore this does not matter any more. We just need to exit
> > cleanly.
> > 
> > GCC 6/trunk: Here the ICE is prevented by making sure, that unnesting
> > of BLOCK namespaces is only done, when the END encountered is not the
> > one of a BLOCK. This prevents gfortran from removing a correctly
> > initialized and for further analysis required namespace.
> > 
> > Bootstrapped and regtested ok on x86_64-linux-gnu/F23. 
> > 
> > Ok for trunk and gcc-5-branch, respectively?
> >   
> 
> OK and thanks for fixes. Much appreciated?
> 
> Jerry


-- 
Andre Vehreschild * Email: vehre ad gmx dot de 
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog	(Revision 232916)
+++ gcc/fortran/ChangeLog	(Arbeitskopie)
@@ -1,3 +1,11 @@
+2016-01-28  Andre Vehreschild  
+
+	PR fortran/62536
+	* decl.c: Prevent setting gfc_current_ns to NULL when block statement's
+	nesting is incomplete.  There is already an error conditon, so having
+	gfc_current_ns pointing to an eventually wrong namespace does not matter
+	that much.
+
 2016-01-27  Andre Vehreschild  
 
 	PR fortran/p69268
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c	(Revision 232916)
+++ gcc/fortran/decl.c	(Arbeitskopie)
@@ -6454,9 +6454,16 @@
 	  prev_ns = ns;
 	  ns = ns->sibling;
 	}
-  
-  gfc_free_namespace (gfc_current_ns);
-  gfc_current_ns = parent_ns;
+
+  if (parent_ns)
+	{
+	  /* Free the current namespace only when the parent one exists.  This
+	 prevents an ICE when more END BLOCK then BLOCK statements are
+	 present.  It does not mean any further harm, because we already
+	 have errored.  */
+	  gfc_free_namespace (gfc_current_ns);
+	  gfc_current_ns = parent_ns;
+	}
 }
 
   return MATCH_ERROR;
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog	(Revision 232916)
+++ gcc/testsuite/ChangeLog	(Arbeitskopie)
@@ -1,3 +1,8 @@
+2016-01-28  Andre Vehreschild  
+
+	PR fortran/62536
+	* gfortran.dg/block_14.f08: New test.
+
 2016-01-27  Marek Polacek  
 
 	Backport from mainline
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog	(Revision 232917)
+++ gcc/fortran/ChangeLog	(Arbeitskopie)
@@ -1,3 +1,9 @@
+2016-01-28  Andre Vehreschild  
+
+	PR fortran/62536
+	* decl.c (gfc_match_end): Only unnest and remove BLOCK namespaces
+	when the END encountered does not match a BLOCK's end.
+
 2016-01-27  Janus Weil  
 
 	PR fortran/69484
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c	(Revision 232917)
+++ gcc/fortran/decl.c	(Arbeitskopie)
@@ -6327,6 +6327,7 @@
   gfc_namespace *parent_ns, *ns, *prev_ns;
   gfc_namespace **nsp;
   bool abreviated_modproc_decl;
+  bool got_matching_end = false;
 
   old_loc = gfc_current_locus;
   if (gfc_match ("end") != MATCH_YES)
@@ -6510,6 +6511,8 @@
 		 ? "END PROCEDURE" : gfc_ascii_statement(*st), &old_loc);
   goto cleanup;
 }
+  else
+got_matching_end = true;
 
   old_loc = gfc_current_locus;
   /* If we're at the end, make sure a block name wasn't required.  */
@@ -6581,7 +6584,7 @@
   /* If we are missing an END BLOCK, we created a half-ready namespace.
  Remove it from the parent namespace's sibling list.  */
 
-  while (state == COMP_BLOCK)
+  while (state == COMP_BLOCK && !got_matching_end)
 {
   parent_ns = gfc_current_ns->parent;
 
@@ -6601,7 +6604,7 @@
 	  prev_ns = ns;
 	  ns = ns->sibling;
 	}
-  
+
   gfc_free_namespace (gfc_current_ns);
   gfc_current_ns = parent_ns;
   gfc_state_stack = gfc_state_stack->previous;
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog	(Revision 232917)
+++ gcc/testsuite/ChangeLog	(Arbeitskopie)
@@ -1,3 +1,10 @@
+2016-01-28  Andre Vehreschild  
+
+	PR fortran/62536
+	* gfortran.dg/block_15.f08: New test.
+	* gfortran.dg/block_end_error_1.f90: Need to catch additional error
+	on incorrectly closed BLOCK.
+
 2016-01-28  Ilya Enkovich  
 
 	* gcc.dg/declare-s

Partial Offloading (was: [hsa merge 07/10] IPA-HSA pass)

[Thomas Schwinge]

Hi!

> [...]

I made an attempt to capture the recent discussion (plus my own
ideas/understanding) in this new section:
.  Please
change/extend, as required.


Grüße
 Thomas


signature.asc
Description: PGP signature

[Ada] Rename enumeration type

[Eric Botcazou]

PR bootstrap/69513 incidentally reports a -Wodr warning during LTO bootstrap:

../../../../../../../opt/devel/gnu/src/gcc/gcc-6.0.0-test/gcc/ada/gcc-
interface/gigi.h:345:6: warning: type ‘attr_type’ violates the C++ One 
Definition Rule [-Wodr]
 enum attr_type
  ^
./insn-attr-common.h:8:0: note: an enum with different value name is defined 
in another translation unit

Fixed thusly, tested on x86_64-suse-linux, applied on the mainline.


2016-01-28  Eric Botcazou  

* gcc-interface/gigi.h (enum attr_type): Rename into...
(enum attrib_type): ...this.
(struct attrib): Adjust.
* gcc-interface/decl.c (prepend_one_attribute): Likewise.

-- 
Eric BotcazouIndex: gcc-interface/decl.c
===
--- gcc-interface/decl.c	(revision 232884)
+++ gcc-interface/decl.c	(working copy)
@@ -151,7 +151,7 @@ struct value_annotation_hasher : ggc_cac
 static GTY ((cache)) hash_table *annotate_value_cache;
 
 static void prepend_one_attribute (struct attrib **,
-   enum attr_type, tree, tree, Node_Id);
+   enum attrib_type, tree, tree, Node_Id);
 static void prepend_one_attribute_pragma (struct attrib **, Node_Id);
 static void prepend_attributes (struct attrib **, Entity_Id);
 static tree elaborate_expression (Node_Id, Entity_Id, const char *, bool, bool,
@@ -6258,14 +6258,14 @@ elaborate_entity (Entity_Id gnat_entity)
 
 static void
 prepend_one_attribute (struct attrib **attr_list,
-		   enum attr_type attr_type,
+		   enum attrib_type attrib_type,
 		   tree attr_name,
 		   tree attr_args,
 		   Node_Id attr_error_point)
 {
   struct attrib * attr = (struct attrib *) xmalloc (sizeof (struct attrib));
 
-  attr->type = attr_type;
+  attr->type = attrib_type;
   attr->name = attr_name;
   attr->args = attr_args;
   attr->error_point = attr_error_point;
@@ -6281,7 +6281,7 @@ prepend_one_attribute_pragma (struct att
 {
   const Node_Id gnat_arg = Pragma_Argument_Associations (gnat_pragma);
   tree gnu_arg0 = NULL_TREE, gnu_arg1 = NULL_TREE;
-  enum attr_type etype;
+  enum attrib_type etype;
 
   /* Map the pragma at hand.  Skip if this isn't one we know how to handle.  */
   switch (Get_Pragma_Id (Chars (Pragma_Identifier (gnat_pragma
Index: gcc-interface/gigi.h
===
--- gcc-interface/gigi.h	(revision 232884)
+++ gcc-interface/gigi.h	(working copy)
@@ -342,7 +342,7 @@ extern bool fp_arith_may_widen;
 
 /* Data structures used to represent attributes.  */
 
-enum attr_type
+enum attrib_type
 {
   ATTR_MACHINE_ATTRIBUTE,
   ATTR_LINK_ALIAS,
@@ -356,7 +356,7 @@ enum attr_type
 struct attrib
 {
   struct attrib *next;
-  enum attr_type type;
+  enum attrib_type type;
   tree name;
   tree args;
   Node_Id error_point;

[PATCH] PR c++/69462: Provide FLT_EVAL_METHOD and DECIMAL_DIG in float.h.

[Dominik Vogt]

The attached patch (written by Jonathan, not me) makes
FLT_EVAL_METHOD and DECIMAL_DIG available in C++-11 as they should
be.

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

Can this be committed (should it wait for stage1)?

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
IBM Germany
gcc/ChangeLog

PR c++/69462
* ginclude/float.h: Also provide FLT_EVAL_METHOD and DECIMAL_DIG for
C++-11.
>From 3b74be3a03105d608609f35b33bcf2ba43c0b5b9 Mon Sep 17 00:00:00 2001
From: Dominik Vogt 
Date: Mon, 25 Jan 2016 11:59:06 +0100
Subject: [PATCH] PR c++/69462: Provide FLT_EVAL_METHOD and
 DECIMAL_DIG in float.h.

---
 gcc/ginclude/float.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gcc/ginclude/float.h b/gcc/ginclude/float.h
index 18f5aac..100e88a 100644
--- a/gcc/ginclude/float.h
+++ b/gcc/ginclude/float.h
@@ -127,7 +127,8 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
 #undef FLT_ROUNDS
 #define FLT_ROUNDS 1
 
-#if defined (__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
+#if (defined (__STDC_VERSION__) && __STDC_VERSION__ >= 199901L) \
+	|| (defined (__cplusplus) && __cplusplus >= 201103L)
 /* The floating-point expression evaluation method.
 -1  indeterminate
  0  evaluate all operations and constants just to the range and
-- 
2.3.0

Re: [PATCH, PR target/69454] Disable TARGET_STV when stack is not properly aligned

[H.J. Lu]

On Thu, Jan 28, 2016 at 2:06 AM, Ilya Enkovich  wrote:
> 2016-01-28 9:00 GMT+03:00 H.J. Lu :
>> On Wed, Jan 27, 2016 at 8:36 AM, H.J. Lu  wrote:
>>> On Wed, Jan 27, 2016 at 8:29 AM, Ilya Enkovich  
>>> wrote:
 2016-01-27 19:18 GMT+03:00 H.J. Lu :
> On Wed, Jan 27, 2016 at 8:11 AM, Ilya Enkovich  
> wrote:
>> On 27 Jan 16:44, Jakub Jelinek wrote:
>>> On Wed, Jan 27, 2016 at 06:34:41PM +0300, Ilya Enkovich wrote:
>>> > @@ -5453,6 +5443,11 @@ ix86_option_override_internal (bool 
>>> > main_args_p,
>>> >  opts->x_target_flags |= MASK_VZEROUPPER;
>>> >if (!(opts_set->x_target_flags & MASK_STV))
>>> >  opts->x_target_flags |= MASK_STV;
>>> > +  /* Disable STV if -mpreferred-stack-boundary={2,3} - the needed
>>>
>>> The comment doesn't match the code, you disable STV only for
>>> -mpreferred-stack-boundary=2.
>>
>> Thanks, here is an updated version.
>>
>> Ilya
>> --
>> gcc/
>>
>> 2016-01-27  Jakub Jelinek  
>> Ilya Enkovich  
>>
>> PR target/69454
>> * config/i386/i386.c (convert_scalars_to_vector): Remove
>> stack alignment fixes.
>> (ix86_option_override_internal): Disable TARGET_STV if stack
>> is not properly aligned.
>>
>> gcc/testsuite/
>>
>> 2016-01-27  Ilya Enkovich  
>>
>> PR target/69454
>> * gcc.target/i386/pr69454-1.c: New test.
>> * gcc.target/i386/pr69454-2.c: New test.
>>
>>
>> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
>> index 34b57a4..9fb8db8 100644
>> --- a/gcc/config/i386/i386.c
>> +++ b/gcc/config/i386/i386.c
>> @@ -3588,16 +3588,6 @@ convert_scalars_to_vector ()
>>bitmap_obstack_release (NULL);
>>df_process_deferred_rescans ();
>>
>> -  /* Conversion means we may have 128bit register spills/fills
>> - which require aligned stack.  */
>> -  if (converted_insns)
>> -{
>> -  if (crtl->stack_alignment_needed < 128)
>> -   crtl->stack_alignment_needed = 128;
>> -  if (crtl->stack_alignment_estimated < 128)
>> -   crtl->stack_alignment_estimated = 128;
>> -}
>> -
>>return 0;
>>  }
>>
>> @@ -5453,6 +5443,11 @@ ix86_option_override_internal (bool main_args_p,
>>  opts->x_target_flags |= MASK_VZEROUPPER;
>>if (!(opts_set->x_target_flags & MASK_STV))
>>  opts->x_target_flags |= MASK_STV;
>> +  /* Disable STV if -mpreferred-stack-boundary=2 - the needed
>> + stack realignment will be extra cost the pass doesn't take into
>> + account and the pass can't realign the stack.  */
>> +  if (ix86_preferred_stack_boundary < 64)
>> +opts->x_target_flags &= ~MASK_STV;
>>
>> This won't work for 32-bit incoming stack boundary and 64-bit preferred
>> stack boundary.  In this case, STV won't be off.  When LRA needs 64-bit
>> aligned stack slot, stack must be realigned.  But for leaf function, we may
>> not realign stack if ix86_minimum_alignment returns 32 for DImode.   You
>> must either add assert (!TARGET_STV) before returning 32 for DImode or
>> return 64 for DImode if STV is on in ix86_minimum_alignment.
>
> TARGET_STV doesn't mean STV pass will run. We can check alignment in STV
> pass gate and this assert would be wrong. If we decide STV to be dependent on
> stack alignment then we shouldn't make alignment be dependent on STV. I can 
> add
> assert into convert_scalars_to_vector to check
> crtl->stack_alignment_estimated >= 64
> by that moment.
>

The bottom line is  ix86_minimum_alignment must return the correct
number for DImode or you can just turn off STV.   My suggestion is
to use my patch.


-- 
H.J.

Re: [C/C++ PATCH] Don't emit invalid VEC_COND_EXPR for vector comparisons (PR c/68062)

[H.J. Lu]

On Wed, Jan 27, 2016 at 9:45 AM, Marek Polacek  wrote:
> On Wed, Jan 27, 2016 at 10:02:36AM -0700, Jeff Law wrote:
>> On 01/27/2016 12:26 AM, Marek Polacek wrote:
>> >Ping.
>> >
>> >On Wed, Jan 20, 2016 at 12:31:51PM +0100, Marek Polacek wrote:
>> >>On Wed, Jan 13, 2016 at 11:11:52PM +, Joseph Myers wrote:
>> >>>The C front-end changes are OK.
>> >>
>> >>Jason, is the C++ part of this patch here
>> >>
>> >>(which is identical to the change in the C FE) ok?
>> >>
>> >>Also, not sure about backporting this, maybe just to 5?
>> I'll go ahead and ack the C++ bits.  This is fine for the trunk.
>
> Thanks.
>
>> WRT backporting, your call.
>
> I think I'll put it into GCC 5 (it's safe and should apply cleanly),
> but leave 4.9 alone.
>
> Marek

I got

FAIL: c-c++-common/vector-compare-4.c  -Wc++-compat   (test for
warnings, line 17)
FAIL: c-c++-common/vector-compare-4.c  -Wc++-compat   (test for
warnings, line 18)
FAIL: c-c++-common/vector-compare-4.c  -Wc++-compat   (test for
warnings, line 34)
FAIL: c-c++-common/vector-compare-4.c  -Wc++-compat   (test for
warnings, line 35)

on x86 on GCC 5 branch.

-- 
H.J.

Re: RFA: patch to fix PR69299

[Jakub Jelinek]

On Wed, Jan 27, 2016 at 04:01:23PM -0500, Vladimir Makarov wrote:
>   The following patch fixes PR69299.
> 
>   The details of the problem is described on
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69299
> 
>   The patch was successfully bootstrapped and tested on x86/x86-64.
> 
>   The patch introduces a new type of constraints
> define_special_memory_constraint for memory constraints whose address reload
> can not make memory to satisfy the constraint.  It is useful when
> specifically aligned memory is necessary or desirable. I don't know what is
> the best name for this constraint.  I use special_memory_constraint but it
> could be more specific, e.g. aligned_memory_constraint.  Please let me know
> what is the best name for you.
> 
>   Is the patch ok to commit?

I support the general idea and for naming will defer to Jeff, just have some
nits below.  But it is your code and area of expertise, so I don't claim to
be an expert here...

> --- ira-costs.c   (revision 232571)
> +++ ira-costs.c   (working copy)
> @@ -777,6 +777,7 @@ record_reg_classes (int n_alts, int n_op
> break;
>  
>   case CT_MEMORY:
> + case CT_SPECIAL_MEMORY:
> /* Every MEM can be reloaded to fit.  */
> insn_allows_mem[i] = allows_mem[i] = 1;
> if (MEM_P (op))

The comment is true only for CT_MEMORY.  Wonder if it wouldn't be better to
handle CT_SPECIAL_MEMORY separately, perhaps as:

  case CT_SPECIAL_MEMORY:
if (MEM_P (op) && constraint_satisfied_p (op, cn))
  {
insn_allows_mem[i] = allows_mem[i] = 1;
win = 1;
  }
break;

?  I.e. if the constraint is already satisfied, treat it like memory
constraint, otherwise treat like (unsatisfied) fixed form constraint.
Or, if you want to account for the possibility that it doesn't satisfy the
constraint yet due to address that if reloaded would make it satisfy,
consider !memory_operand (op, ...) case as unknown, with no need to
check the constraint.  Because if op satisfies already memory_operand,
but doesn't constraint_satisfied_p, it means it will never satisfy.

> --- ira.c (revision 232571)
> +++ ira.c (working copy)
> @@ -1868,6 +1868,7 @@ ira_setup_alts (rtx_insn *insn, HARD_REG
>  
>   case CT_ADDRESS:
>   case CT_MEMORY:
> + case CT_SPECIAL_MEMORY:
> goto op_success;

Perhaps treat it like CT_FIXED_FORM here instead?  I.e. op_success only
if the constraint is satisfied?  Or perhaps treat it as possible op_success
if !memory_operand, as mentioned above.

> --- recog.c   (revision 232571)
> +++ recog.c   (working copy)
> @@ -1791,6 +1791,7 @@ asm_operand_ok (rtx op, const char *cons
> break;
>  
>   case CT_MEMORY:
> + case CT_SPECIAL_MEMORY:
> /* Every memory operand can be reloaded to fit.  */
> result = result || memory_operand (op, VOIDmode);
> break;

Again, I'd treat it like CT_FIXED_FORM here, or at least if
memory_operand check also constraint_satisfied_p.

Jakub

Re: [wwwdocs] gcc-6/changes.html: diagnostics, Levenshtein, -Wmisleading-indentation, jit (v2)

[Markus Trippelsdorf]

On 2016.01.20 at 18:38 +0100, Gerald Pfeifer wrote:
> On Wed, 20 Jan 2016, Jakub Jelinek wrote:
> >>   Content-Security-Policy: default-src 'self' http: https:
> >> 
> >> So either we get the configuration of the web server changed, or
> >> indeed we need to touch all those existing pages.
> > At least the warning/error/note styles are something that multiple pages 
> > are using and going to use in the future, so if that could be defined in 
> > the main gcc.css, it would be enough.
> 
> Done thusly.  With this change, at least gcc-6/changes.html should
> be fine again.
> 
> And I can commit working my way backwards through all the other
> changes.html pages over the coming couple of days.
> 
> Gerald
> 
> 
> Move the boldred class from gcc-6/changes.html to gcc.css.
> Introduce boldcyan and boldmagenta classes and use them in
> gcc-6/changes.html.
> 
> Index: gcc.css
> ===
> RCS file: /cvs/gcc/wwwdocs/htdocs/gcc.css,v
> retrieving revision 1.25
> diff -u -r1.25 gcc.css
> --- gcc.css   12 Sep 2011 09:42:59 -  1.25
> +++ gcc.css   20 Jan 2016 17:26:10 -
> @@ -49,7 +49,11 @@
>border-width: thin;
>padding: 4px;
>  }
> -  
> +
> +.boldcyan{ font-weight:bold; color:cyan; }

This color is unreadable on white background. See the notes for
-Wmisleading-indentation on http://gcc.gnu.org/gcc-6/changes.html

Also the gcc homepage looks weird. The news column is much too wide and
the "Release Series and Status" to small.

-- 
Markus

Re: [wwwdocs] gcc-6/changes.html: diagnostics, Levenshtein, -Wmisleading-indentation, jit (v2)

[Jakub Jelinek]

On Thu, Jan 28, 2016 at 02:19:09PM +0100, Markus Trippelsdorf wrote:
> > Move the boldred class from gcc-6/changes.html to gcc.css.
> > Introduce boldcyan and boldmagenta classes and use them in
> > gcc-6/changes.html.
> > 
> > Index: gcc.css
> > ===
> > RCS file: /cvs/gcc/wwwdocs/htdocs/gcc.css,v
> > retrieving revision 1.25
> > diff -u -r1.25 gcc.css
> > --- gcc.css 12 Sep 2011 09:42:59 -  1.25
> > +++ gcc.css 20 Jan 2016 17:26:10 -
> > @@ -49,7 +49,11 @@
> >border-width: thin;
> >padding: 4px;
> >  }
> > -  
> > +
> > +.boldcyan{ font-weight:bold; color:cyan; }
> 
> This color is unreadable on white background. See the notes for
> -Wmisleading-indentation on http://gcc.gnu.org/gcc-6/changes.html

It is not so unreadable, and +/- matches the actual color used by gcc,
doesn't it?

> Also the gcc homepage looks weird. The news column is much too wide and
> the "Release Series and Status" to small.

Yeah, the home page needs changes, not sure if we want a separate *.css file
for it because it has lots of different inline styles and tweaks that need
replacement in *.css with the strict setting.

Jakub

Re: [PATCH PR68542]

[Richard Biener]

On Fri, Jan 22, 2016 at 3:29 PM, Yuri Rumyantsev  wrote:
> Richard,
>
> I fixed all remarks pointed by you in vectorizer part of patch. Could
> you take a look on modified patch.

+   if (is_gimple_call (stmt1))
+ lhs = gimple_call_lhs (stmt1);
+   else
+ if (gimple_code (stmt1) == GIMPLE_ASSIGN)
+   lhs = gimple_assign_lhs (stmt1);
+ else
+   break;

use

  lhs = gimple_get_lhs (stmt1);
  if (!lhs)
break;

you forget to free bbs, I suggest to do it after seeding the worklist.

Ok with those changes if the backend changes are approved.

Sorry for the delay in reviewing this.

Thanks,
Richard.

> Uros,
>
> Could you please review i386 part of patch related to support of
> conditional branches with vector comparison.
>
> Bootstrap and regression testing did not show any new failures.
> Is it OK for trunk?
>
> Thanks.
> Yuri.
>
> ChangeLog:
>
> 2016-01-22  Yuri Rumyantsev  
>
> PR middle-end/68542
> * config/i386/i386.c (ix86_expand_branch): Add support for conditional
> brnach with vector comparison.
> * config/i386/sse.md (define_expand "cbranch4): Add define-expand
> for vector comparion with eq/ne only.
> (optimize_mask_stores): New function.
> * tree-vect-stmts.c (vectorizable_mask_load_store): Initialize
> has_mask_store field of vect_info.
> * tree-vectorizer.c (vectorize_loops): Invoke optimaze_mask_stores for
> vectorized loops having masked stores after vec_info destroy.
> * tree-vectorizer.h (loop_vec_info): Add new has_mask_store field and
> correspondent macros.
> (optimize_mask_stores): Add prototype.
>
> gcc/testsuite/ChangeLog:
> * gcc.dg/vect/vect-mask-store-move-1.c: New test.
> * testsuite/gcc.target/i386/avx2-vect-mask-store-move1.c: New test.
>
> 2016-01-20 15:24 GMT+03:00 Richard Biener :
>> On Mon, Jan 18, 2016 at 3:50 PM, Yuri Rumyantsev  wrote:
>>> Richard,
>>>
>>> Here is the second part of patch which really preforms mask stores and
>>> all statements related to it to new basic block guarded by test on
>>> zero mask. Hew test is also added.
>>>
>>> Is it OK for trunk?
>>
>> +  /* Pick up all masked stores in loop if any.  */
>> +  for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next (&gsi))
>> +{
>> +  stmt = gsi_stmt (gsi);
>>
>> you fail to iterate over all BBs of the loop here.  Please follow
>> other uses in the
>> vectorizer.
>>
>> +  while (!worklist.is_empty ())
>> +{
>> +  gimple *last, *last_store;
>> +  edge e, efalse;
>> +  tree mask;
>> +  basic_block store_bb, join_bb;
>> +  gimple_stmt_iterator gsi_to;
>> +  /* tree arg3; */
>>
>> remove
>>
>> +  tree vdef, new_vdef;
>> +  gphi *phi;
>> +  bool first_dump;
>> +  tree vectype;
>> +  tree zero;
>> +
>> +  last = worklist.pop ();
>> +  mask = gimple_call_arg (last, 2);
>> +  /* Create new bb.  */
>>
>> bb should be initialized from gimple_bb (last), not loop->header
>>
>> +  e = split_block (bb, last);
>>
>> +   gsi_from = gsi_for_stmt (stmt1);
>> +   gsi_to = gsi_start_bb (store_bb);
>> +   gsi_move_before (&gsi_from, &gsi_to);
>> +   update_stmt (stmt1);
>>
>> I think the update_stmt is redundant and you should be able to
>> keep two gsis throughout the loop, from and to, no?
>>
>> +   /* Put other masked stores with the same mask to STORE_BB.  */
>> +   if (worklist.is_empty ()
>> +   || gimple_call_arg (worklist.last (), 2) != mask
>> +   || !is_valid_sink (worklist.last (), last_store))
>>
>> as I understand the code the last check is redundant with the invariant
>> you track if you verify the stmt you breaked from the inner loop is
>> actually equal to worklist.last () and you add a flag to track whether
>> you did visit a load (vuse) in the sinking loop you didn't end up sinking.
>>
>> + /* Issue different messages depending on FIRST_DUMP.  */
>> + if (first_dump)
>> +   {
>> + dump_printf_loc (MSG_NOTE, vect_location,
>> +  "Move MASK_STORE to new bb#%d\n",
>> +  store_bb->index);
>> + first_dump = false;
>> +   }
>> + else
>> +   dump_printf_loc (MSG_NOTE, vect_location,
>> +"Move MASK_STORE to created bb\n");
>>
>> just add a separate dump when you create the BB, "Created new bb#%d for ..."
>> to avoid this.
>>
>> Note that I can't comment on the x86 backend part so that will need to
>> be reviewed by somebody
>> else.
>>
>> Thanks,
>> Richard.
>>
>>> Thanks.
>>> Yuri.
>>>
>>> 2016-01-18  Yuri Rumyantsev  
>>>
>>> PR middle-end/68542
>>> * config/i386/i386.c (ix86_expand_branch): Implement integral vector
>>> comparison with boolean result.
>>> * config/i386/sse.md (define_expand "cbranch4): Add define-expand
>>> for vector comparion with eq/ne only.
>>

Re: [PATCH] PR c++/69462: Provide FLT_EVAL_METHOD and DECIMAL_DIG in float.h.

[Jonathan Wakely]

On 28/01/16 13:40 +0100, Dominik Vogt wrote:

The attached patch (written by Jonathan, not me) makes
FLT_EVAL_METHOD and DECIMAL_DIG available in C++-11 as they should
be.

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

Can this be committed (should it wait for stage1)?


I've just noticed we should also do the following, although this can
definitely wait for stage 1 as it works fine as is (unlike Dominik's
 case which is a conformance bug).

--- a/gcc/ginclude/stdarg.h
+++ b/gcc/ginclude/stdarg.h
@@ -47,7 +47,7 @@ typedef __builtin_va_list __gnuc_va_list;
#define va_start(v,l)  __builtin_va_start(v,l)
#define va_end(v)  __builtin_va_end(v)
#define va_arg(v,l)__builtin_va_arg(v,l)
-#if !defined(__STRICT_ANSI__) || __STDC_VERSION__ + 0 >= 199900L || 
defined(__GXX_EXPERIMENTAL_CXX0X__)
+#if !defined(__STRICT_ANSI__) || __STDC_VERSION__ + 0 >= 199900L || __cplusplus + 
0 >= 201103L
#define va_copy(d,s)   __builtin_va_copy(d,s)
#endif
#define __va_copy(d,s) __builtin_va_copy(d,s)

Re: [gomp4, PR68977, Committed] Don't gimplify in ssa mode if seen_error in oacc_xform_loop

[Richard Biener]

On Mon, Jan 25, 2016 at 12:00 PM, Tom de Vries  wrote:
> On 14/01/16 10:43, Richard Biener wrote:
>>
>> On Wed, Jan 13, 2016 at 9:04 PM, Tom de Vries 
>> wrote:
>>>
>>> Hi,
>>>
>>> At r231739, there was an ICE when checking code generated by
>>> oacc_xform_loop, in case the source contained an error.
>>>
>>> Due to seen_error (), gimplification during oacc_xform_loop bailed out,
>>> and
>>> an uninitialized var was introduced.  Because of gimplifying in ssa mode,
>>> that caused an ICE.
>>>
>>> I can't reproduce this any longer, but I think the fix still makes sense.
>>> The patch makes sure oacc_xform_loop gimplifies in non-ssa mode if
>>> seen_error ().
>>
>>
>> I don't think it makes "sense" in any way.  After seen_error () a
>> following ICE
>> will be "confused after earlier errors" in release mode and thus I think
>> that's
>> not an important problem to paper over with this kind of "hack".
>>
>> I'd rather avoid doing any of omp-low if seen_error ()?
>>
>
> The error triggered in oacc_device_lower, so there's nothing we can do
> before (in omp-low).
>
> How about this fix, which replaces the oacc ifn calls with zero-assignments
> if seen_error ()?

Again it looks like too much complexity for an ICE-after-error which will
be reported as "confused after errors" only.  I'd accept a patch that simply
stops processing the function before lowering which is what we usually
do with this kind of cases [yes, it might make sense to start tracking
seen-error per function].

So in this case add a seen_errors () guard to cgraph_node::expand ()
like the following:

Index: cgraphunit.c
===
--- cgraphunit.c(revision 232666)
+++ cgraphunit.c(working copy)
@@ -1967,15 +1967,18 @@ cgraph_node::expand (void)

   execute_all_ipa_transforms ();

-  /* Perform all tree transforms and optimizations.  */
-
-  /* Signal the start of passes.  */
-  invoke_plugin_callbacks (PLUGIN_ALL_PASSES_START, NULL);
-
-  execute_pass_list (cfun, g->get_passes ()->all_passes);
-
-  /* Signal the end of passes.  */
-  invoke_plugin_callbacks (PLUGIN_ALL_PASSES_END, NULL);
+  if (! seen_error ())
+{
+  /* Perform all tree transforms and optimizations.  */
+
+  /* Signal the start of passes.  */
+  invoke_plugin_callbacks (PLUGIN_ALL_PASSES_START, NULL);
+
+  execute_pass_list (cfun, g->get_passes ()->all_passes);
+
+  /* Signal the end of passes.  */
+  invoke_plugin_callbacks (PLUGIN_ALL_PASSES_END, NULL);
+}

   bitmap_obstack_release (®_obstack);

Richard.

> Thanks,
> - Tom

Re: [PATCH PR68542]

[Yuri Rumyantsev]

Thanks Richard.

Uros,

Could you please review back-end part of this patch?

Thanks.
Yuri.

2016-01-28 16:26 GMT+03:00 Richard Biener :
> On Fri, Jan 22, 2016 at 3:29 PM, Yuri Rumyantsev  wrote:
>> Richard,
>>
>> I fixed all remarks pointed by you in vectorizer part of patch. Could
>> you take a look on modified patch.
>
> +   if (is_gimple_call (stmt1))
> + lhs = gimple_call_lhs (stmt1);
> +   else
> + if (gimple_code (stmt1) == GIMPLE_ASSIGN)
> +   lhs = gimple_assign_lhs (stmt1);
> + else
> +   break;
>
> use
>
>   lhs = gimple_get_lhs (stmt1);
>   if (!lhs)
> break;
>
> you forget to free bbs, I suggest to do it after seeding the worklist.
>
> Ok with those changes if the backend changes are approved.
>
> Sorry for the delay in reviewing this.
>
> Thanks,
> Richard.
>
>> Uros,
>>
>> Could you please review i386 part of patch related to support of
>> conditional branches with vector comparison.
>>
>> Bootstrap and regression testing did not show any new failures.
>> Is it OK for trunk?
>>
>> Thanks.
>> Yuri.
>>
>> ChangeLog:
>>
>> 2016-01-22  Yuri Rumyantsev  
>>
>> PR middle-end/68542
>> * config/i386/i386.c (ix86_expand_branch): Add support for conditional
>> brnach with vector comparison.
>> * config/i386/sse.md (define_expand "cbranch4): Add define-expand
>> for vector comparion with eq/ne only.
>> (optimize_mask_stores): New function.
>> * tree-vect-stmts.c (vectorizable_mask_load_store): Initialize
>> has_mask_store field of vect_info.
>> * tree-vectorizer.c (vectorize_loops): Invoke optimaze_mask_stores for
>> vectorized loops having masked stores after vec_info destroy.
>> * tree-vectorizer.h (loop_vec_info): Add new has_mask_store field and
>> correspondent macros.
>> (optimize_mask_stores): Add prototype.
>>
>> gcc/testsuite/ChangeLog:
>> * gcc.dg/vect/vect-mask-store-move-1.c: New test.
>> * testsuite/gcc.target/i386/avx2-vect-mask-store-move1.c: New test.
>>
>> 2016-01-20 15:24 GMT+03:00 Richard Biener :
>>> On Mon, Jan 18, 2016 at 3:50 PM, Yuri Rumyantsev  wrote:
 Richard,

 Here is the second part of patch which really preforms mask stores and
 all statements related to it to new basic block guarded by test on
 zero mask. Hew test is also added.

 Is it OK for trunk?
>>>
>>> +  /* Pick up all masked stores in loop if any.  */
>>> +  for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next (&gsi))
>>> +{
>>> +  stmt = gsi_stmt (gsi);
>>>
>>> you fail to iterate over all BBs of the loop here.  Please follow
>>> other uses in the
>>> vectorizer.
>>>
>>> +  while (!worklist.is_empty ())
>>> +{
>>> +  gimple *last, *last_store;
>>> +  edge e, efalse;
>>> +  tree mask;
>>> +  basic_block store_bb, join_bb;
>>> +  gimple_stmt_iterator gsi_to;
>>> +  /* tree arg3; */
>>>
>>> remove
>>>
>>> +  tree vdef, new_vdef;
>>> +  gphi *phi;
>>> +  bool first_dump;
>>> +  tree vectype;
>>> +  tree zero;
>>> +
>>> +  last = worklist.pop ();
>>> +  mask = gimple_call_arg (last, 2);
>>> +  /* Create new bb.  */
>>>
>>> bb should be initialized from gimple_bb (last), not loop->header
>>>
>>> +  e = split_block (bb, last);
>>>
>>> +   gsi_from = gsi_for_stmt (stmt1);
>>> +   gsi_to = gsi_start_bb (store_bb);
>>> +   gsi_move_before (&gsi_from, &gsi_to);
>>> +   update_stmt (stmt1);
>>>
>>> I think the update_stmt is redundant and you should be able to
>>> keep two gsis throughout the loop, from and to, no?
>>>
>>> +   /* Put other masked stores with the same mask to STORE_BB.  */
>>> +   if (worklist.is_empty ()
>>> +   || gimple_call_arg (worklist.last (), 2) != mask
>>> +   || !is_valid_sink (worklist.last (), last_store))
>>>
>>> as I understand the code the last check is redundant with the invariant
>>> you track if you verify the stmt you breaked from the inner loop is
>>> actually equal to worklist.last () and you add a flag to track whether
>>> you did visit a load (vuse) in the sinking loop you didn't end up sinking.
>>>
>>> + /* Issue different messages depending on FIRST_DUMP.  */
>>> + if (first_dump)
>>> +   {
>>> + dump_printf_loc (MSG_NOTE, vect_location,
>>> +  "Move MASK_STORE to new bb#%d\n",
>>> +  store_bb->index);
>>> + first_dump = false;
>>> +   }
>>> + else
>>> +   dump_printf_loc (MSG_NOTE, vect_location,
>>> +"Move MASK_STORE to created bb\n");
>>>
>>> just add a separate dump when you create the BB, "Created new bb#%d for ..."
>>> to avoid this.
>>>
>>> Note that I can't comment on the x86 backend part so that will need to
>>> be reviewed by somebody
>>> else.
>>>
>>> Thanks,
>>> Richard.
>>>
 Thanks

[PATCH] Fix PR69537

[Richard Biener]

I am fixing the missed optimization / bogus warning with relaxing
the guard around "old" fold_{widened,sing_changing}_comparison
which is now in match.pd.

Bootstrap and regtest running on x86_64-unknown-linux-gnu.

I'm curious if any issues with casts-to-BOOLEAN_TYPE show up
in our testsuite (and wonder how we didn't bother to then test
also for casts-from-BOOLEAN_TYPE).

Richard.

2016-01-28  Richard Biener  

PR middle-end/69537
* match.pd: Allow all integral types when simplifying a
widening or sign-changing conversion.

* gcc.dg/uninit-21.c: New testcase.

Index: gcc/match.pd
===
--- gcc/match.pd(revision 232925)
+++ gcc/match.pd(working copy)
@@ -2121,7 +2121,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
 (for cmp (simple_comparison)
  (simplify
   (cmp (convert@0 @00) (convert?@1 @10))
-  (if (TREE_CODE (TREE_TYPE (@0)) == INTEGER_TYPE
+  (if (INTEGRAL_TYPE_P (TREE_TYPE (@0))
/* Disable this optimization if we're casting a function pointer
  type on targets that require function pointer canonicalization.  */
&& !(targetm.have_canonicalize_funcptr_for_compare ()
Index: gcc/testsuite/gcc.dg/uninit-21.c
===
--- gcc/testsuite/gcc.dg/uninit-21.c(revision 0)
+++ gcc/testsuite/gcc.dg/uninit-21.c(working copy)
@@ -0,0 +1,33 @@
+/* PR69537, spurious warning because of a missed optimization. */
+/* { dg-do compile } */
+/* { dg-options "-O2 -Wuninitialized" } */
+
+enum clnt_stat {
+ RPC_SUCCESS=0,
+ RPC_CANTENCODEARGS=1,
+};
+ 
+int do_ypcall_tr ();
+ 
+static int
+yp_master (char **outname)
+{
+  // Replacing enum clnt_stat with int avoids the warning.
+  enum clnt_stat result;
+  result = do_ypcall_tr ();
+  if (result != 0)
+return result;
+  *outname = __builtin_strdup ("foo");
+  return 0;
+}
+ 
+int
+yp_update (void)
+{
+  char *master;
+  int r;
+  if ((r = yp_master (&master)) != 0)
+return r;
+  __builtin_free (master); /* { dg-bogus "uninitialized" } */
+  return 0;
+}

Re: [PATCH PR68542]

[Uros Bizjak]

On Thu, Jan 28, 2016 at 2:37 PM, Yuri Rumyantsev  wrote:
> Thanks Richard.
>
> Uros,
>
> Could you please review back-end part of this patch?

No problem, but please in future CC me on the x86 patches, so I won't forgot.

+(define_expand "cbranch4"
+  [(set (reg:CC FLAGS_REG)
+(compare:CC (match_operand:V48_AVX2 1 "nonimmediate_operand")
+(match_operand:V48_AVX2 2 "register_operand")))
+

Please swap predicates, operand 1 should be register_operand and
operand 2 nonimmediate operand.

+   (set (pc) (if_then_else
+   (match_operator 0 "bt_comparison_operator"
+[(reg:CC FLAGS_REG) (const_int 0)])
+   (label_ref (match_operand 3))
+   (pc)))]
+  "TARGET_AVX2"

PTEST was introduced with SSE4_1, I see no reason to limit this
transformation to AVX2. However, since you check MODE_VECTOR_INT in
the expander, it looks that the pattern should only handle integer
modes.

+  /* Handle special case - vector comparsion with boolean result, transform
+ it using ptest instruction.  */
+  if (GET_MODE_CLASS (mode) == MODE_VECTOR_INT)
+{
+  rtx lhs;

No need for the above variable, we will use tmp here.

+  rtx flag;
+  machine_mode p_mode = GET_MODE_SIZE (mode) == 32 ? V4DImode : V2DImode;

space here.

+  gcc_assert (code == EQ || code == NE);

+  if (!REG_P (op0))
+op0 = force_reg (mode, op0);
+  if (!REG_P (op1))
+op1 = force_reg (mode, op1);

No need for the above fixups, predicates already did the job.

+  /* Generate subtraction since we can't check that one operand is
+ zero vector.  */
+  lhs = gen_reg_rtx (mode);

tmp = ...

+  emit_insn (gen_rtx_SET (lhs, gen_rtx_MINUS (mode, op0, op1)));

Since we are only interested in equality, should we rather use XOR,
since it is commutative operator.

+  lhs = gen_rtx_SUBREG (p_mode, lhs, 0);

tmp = gen_lowpart (p_mode, tmp);

+  tmp = gen_rtx_SET (gen_rtx_REG (CCmode, FLAGS_REG),
+ gen_rtx_UNSPEC (CCmode,
+ gen_rtvec (2, lhs, lhs),
+ UNSPEC_PTEST));
+  emit_insn (tmp);

There is no need for a temporary here, just use

emit_insn (gen_rtx_SET ( ... ) ...

+  tmp = gen_rtx_fmt_ee (code, VOIDmode, flag, const0_rtx);
+  if (code == EQ)
+tmp = gen_rtx_IF_THEN_ELSE (VOIDmode, tmp,
+gen_rtx_LABEL_REF (VOIDmode, label), pc_rtx);
+  else
+tmp = gen_rtx_IF_THEN_ELSE (VOIDmode, tmp,
+pc_rtx, gen_rtx_LABEL_REF (VOIDmode, label));
+  emit_jump_insn (gen_rtx_SET (pc_rtx, tmp));
+  return;

Oh please use something involving std::swap here.

Uros.

[PATCH] Fix PCH on systems where stdc-predef.h includes other headers (PR pch/68176)

[Jakub Jelinek]

Hi!

As mentioned in the PR, most of the pch tests fail if stdc-predef.h header
includes other headers.  I don't have such a system, but changed my
stdc-predef.h to include a dummy header bits/predef.h and this patch fixes
all the tests that failed because of that.
AFAIK file->implicit_preinclude flag is used solely for the PCH purposes,
and this patch makes sure that headers included from implicit_preinclude
headers are also implicit_preinclude.

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

2016-01-28  Jakub Jelinek  

PR pch/68176
* files.c (_cpp_find_file): Set file->implicit_preinclude even if
included from file->implicit_preinclude header.

--- libcpp/files.c.jj   2016-01-08 07:42:49.0 +0100
+++ libcpp/files.c  2016-01-28 09:53:06.569750380 +0100
@@ -522,7 +522,10 @@ _cpp_find_file (cpp_reader *pfile, const
 return entry->u.file;
 
   file = make_cpp_file (pfile, start_dir, fname);
-  file->implicit_preinclude = implicit_preinclude;
+  file->implicit_preinclude
+= (implicit_preinclude
+   || (pfile->buffer
+  && pfile->buffer->file->implicit_preinclude));
 
   /* Try each path in the include chain.  */
   for (; !fake ;)

Jakub

Re: [PATCH 4/4][AArch64] Cost CCMP instruction sequences to choose better expand order

[James Greenhalgh]

On Mon, Jan 25, 2016 at 08:09:39PM +, Wilco Dijkstra wrote:
> Andreas Schwab  wrote:
> 
> > FAIL: gcc.target/aarch64/ccmp_1.c scan-assembler-times \tcmp\tw[0-9]+, 0 4
> > FAIL: gcc.target/aarch64/ccmp_1.c scan-assembler adds\t
> > FAIL: gcc.target/aarch64/ccmp_1.c scan-assembler-times fccmpe\t.*0\\.0 1
> 
> Yes I noticed those too, and here is the fix. Richard's recent change added
> UNSPEC to the CCMP patterns to stop combine optimizing the CCMP CCmode
> immediate in a rare case. This requires a change to the CCMP cost calculation
> as the CCMP instruction with unspec is no longer recognized.
> 
> Fix the ccmp_1.c test to allow both '0' and 'wzr' on cmp - BTW is there a
> regular expression that correctly implements (0|xzr)? If I use that the test
> still fails somehow but \[0wzr\]+ works fine... Is the correct syntax
> documented somewhere?
> 
> Finally to ensure FCCMPE is emitted on relational compares, add
> -ffinite-math-only.

OK.

Thanks,
James

> 
> ChangeLog:
> 2016-01-25  Wilco Dijkstra  
> 
> gcc/
>   * config/aarch64/aarch64.c (aarch64_if_then_else_costs):
>   Remove CONST_INT_P check in CCMP cost calculation.
> 
> gcc/testsuite/
>   * gcc.target/aarch64/ccmp_1.c: Fix test issues.
> 

Re: [PATCH] libcpp: use better locations for _Pragma tokens (preprocessor/69126)

[Jakub Jelinek]

On Sun, Jan 17, 2016 at 09:09:53AM -0500, David Malcolm wrote:
> libcpp/ChangeLog:
>   PR preprocessor/69126
>   * directives.c (destringize_and_run): Add expansion_loc param; use
>   it when handling unexpanded pragmas to fixup the locations of the
>   synthesized tokens.

This change introduced a new -Wunused-function warning, because
there is a prototype for destringize_and_run that has not been adjusted.
I'm not removing all the unneeded prototypes right now, instead I've
just fixed that one up as obvious, after bootstrap/regtest on x86_64-linux.

2016-01-28  Jakub Jelinek  

* directives.c (destringize_and_run): Adjust prototype.

--- libcpp/directives.c.jj  2016-01-27 20:30:20.0 +0100
+++ libcpp/directives.c 2016-01-28 09:47:44.216143047 +0100
@@ -122,7 +122,8 @@ static void do_pragma_error (cpp_reader
 static void do_linemarker (cpp_reader *);
 static const cpp_token *get_token_no_padding (cpp_reader *);
 static const cpp_token *get__Pragma_string (cpp_reader *);
-static void destringize_and_run (cpp_reader *, const cpp_string *);
+static void destringize_and_run (cpp_reader *, const cpp_string *,
+source_location);
 static int parse_answer (cpp_reader *, struct answer **, int, source_location);
 static cpp_hashnode *parse_assertion (cpp_reader *, struct answer **, int);
 static struct answer ** find_answer (cpp_hashnode *, const struct answer *);


Jakub

Re: [PATCH] PR c++/69462: Provide FLT_EVAL_METHOD and DECIMAL_DIG in float.h.

[Jakub Jelinek]

On Thu, Jan 28, 2016 at 01:32:18PM +, Jonathan Wakely wrote:
> On 28/01/16 13:40 +0100, Dominik Vogt wrote:
> >The attached patch (written by Jonathan, not me) makes
> >FLT_EVAL_METHOD and DECIMAL_DIG available in C++-11 as they should
> >be.
> >
> >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69462
> >
> >Can this be committed (should it wait for stage1)?
> 
> I've just noticed we should also do the following, although this can
> definitely wait for stage 1 as it works fine as is (unlike Dominik's
>  case which is a conformance bug).
> 
> --- a/gcc/ginclude/stdarg.h
> +++ b/gcc/ginclude/stdarg.h
> @@ -47,7 +47,7 @@ typedef __builtin_va_list __gnuc_va_list;
> #define va_start(v,l)  __builtin_va_start(v,l)
> #define va_end(v)  __builtin_va_end(v)
> #define va_arg(v,l)__builtin_va_arg(v,l)
> -#if !defined(__STRICT_ANSI__) || __STDC_VERSION__ + 0 >= 199900L || 
> defined(__GXX_EXPERIMENTAL_CXX0X__)
> +#if !defined(__STRICT_ANSI__) || __STDC_VERSION__ + 0 >= 199900L || 
> __cplusplus + 0 >= 201103L
> #define va_copy(d,s)   __builtin_va_copy(d,s)
> #endif
> #define __va_copy(d,s) __builtin_va_copy(d,s)

This is ok, but please fix up the formatting (avoid too long line).

Jakub

Re: [PATCH] PR c++/69462: Provide FLT_EVAL_METHOD and DECIMAL_DIG in float.h.

[Jakub Jelinek]

On Thu, Jan 28, 2016 at 01:40:12PM +0100, Dominik Vogt wrote:
>   PR c++/69462
>   * ginclude/float.h: Also provide FLT_EVAL_METHOD and DECIMAL_DIG for
>   C++-11.

> >From 3b74be3a03105d608609f35b33bcf2ba43c0b5b9 Mon Sep 17 00:00:00 2001
> From: Dominik Vogt 
> Date: Mon, 25 Jan 2016 11:59:06 +0100
> Subject: [PATCH] PR c++/69462: Provide FLT_EVAL_METHOD and
>  DECIMAL_DIG in float.h.
> 
> ---
>  gcc/ginclude/float.h | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/gcc/ginclude/float.h b/gcc/ginclude/float.h
> index 18f5aac..100e88a 100644
> --- a/gcc/ginclude/float.h
> +++ b/gcc/ginclude/float.h
> @@ -127,7 +127,8 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  
> If not, see
>  #undef FLT_ROUNDS
>  #define FLT_ROUNDS 1
>  
> -#if defined (__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
> +#if (defined (__STDC_VERSION__) && __STDC_VERSION__ >= 199901L) \
> + || (defined (__cplusplus) && __cplusplus >= 201103L)

The formatting is wrong, there is a tab before || when it should be aligned
below defined on the previous line.
Ok for trunk with that change.

Jakub

Re: RFA (tree.h): C++ PATCH for c++/67407 (ICE with protected access)

[Jakub Jelinek]

On Thu, Jan 28, 2016 at 10:03:59AM -0500, Jason Merrill wrote:
> In this testcase, the problem was that we were checking DERIVED_FROM_P,
> which uses dfs_walk_once and thus BINFO_MARKED, in the middle of a
> dfs_walk_once_accessible, which also uses BINFO_MARKED, and the marks from
> one walk were confusing the other walk.  Fixed by moving these binfo walking
> functions to use a hash_set instead of BINFO_MARKED.
> 
> After this change, there are no uses of BINFO_MARKED left in the source
> tree, so I'm inclined to rename it to BINFO_LANG_FLAG_0.  OK?

LGTM.
Do you see any measurable compatile time differences with this patch
on some large C++ preprocessed source (say some boost one)?

Jakub

Re: [wwwdocs] Convert gcc-4.9/porting_to.html to using gcc.css (instead of individual style= clauses)

[Gerald Pfeifer]

On Sun, 24 Jan 2016, Gerald Pfeifer wrote:
> With this, like similar pages, we now have the colors back.

A friendly sole pointed out a mistake I had made in this conversation.

Fixed thusly.

Gerald

Index: gcc-4.9/porting_to.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.9/porting_to.html,v
retrieving revision 1.8
diff -u -r1.8 porting_to.html
--- gcc-4.9/porting_to.html 24 Jan 2016 23:13:07 -  1.8
+++ gcc-4.9/porting_to.html 28 Jan 2016 15:09:50 -
@@ -49,7 +49,7 @@
 
 t.c:6:19: error: expected 
‘declare’ before ‘critical’
#pragma omp end critical
-   ^
+   ^
 
 
 There is no #pragma omp end critical directive for C/C++

RFA (tree.h): C++ PATCH for c++/67407 (ICE with protected access)

[Jason Merrill]

In this testcase, the problem was that we were checking DERIVED_FROM_P, 
which uses dfs_walk_once and thus BINFO_MARKED, in the middle of a 
dfs_walk_once_accessible, which also uses BINFO_MARKED, and the marks 
from one walk were confusing the other walk.  Fixed by moving these 
binfo walking functions to use a hash_set instead of BINFO_MARKED.


After this change, there are no uses of BINFO_MARKED left in the source 
tree, so I'm inclined to rename it to BINFO_LANG_FLAG_0.  OK?


Tested x86_64-pc-linux-gnu.
commit 624557b32eadf69d58c712960b9f4c455ca344f5
Author: Jason Merrill 
Date:   Wed Jan 27 15:52:11 2016 -0500

	PR c++/67407

gcc/
	* tree.h (BINFO_FLAG_0): Rename from BINFO_MARKED.
gcc/cp/
	* search.c (dfs_walk_once, dfs_walk_once_r)
	(dfs_walk_once_accessible_r, dfs_walk_once_accessible): Use
	hash_set instead of BINFO_MARKED.
	(dfs_unmark_r): Remove.

diff --git a/gcc/cp/class.c b/gcc/cp/class.c
index fc47f91..45d8a24 100644
--- a/gcc/cp/class.c
+++ b/gcc/cp/class.c
@@ -2608,9 +2608,7 @@ update_vtable_entry_for_fn (tree t, tree binfo, tree fn, tree* virtuals,
 	  /* There was no existing virtual thunk (which takes
 	 precedence).  So find the binfo of the base function's
 	 return type within the overriding function's return type.
-	 We cannot call lookup base here, because we're inside a
-	 dfs_walk, and will therefore clobber the BINFO_MARKED
-	 flags.  Fortunately we know the covariancy is valid (it
+	 Fortunately we know the covariancy is valid (it
 	 has already been checked), so we can just iterate along
 	 the binfos, which have been chained in inheritance graph
 	 order.  Of course it is lame that we have to repeat the
diff --git a/gcc/cp/search.c b/gcc/cp/search.c
index 455073e..7924611 100644
--- a/gcc/cp/search.c
+++ b/gcc/cp/search.c
@@ -34,9 +34,6 @@ static tree dfs_lookup_base (tree, void *);
 static tree dfs_dcast_hint_pre (tree, void *);
 static tree dfs_dcast_hint_post (tree, void *);
 static tree dfs_debug_mark (tree, void *);
-static tree dfs_walk_once_r (tree, tree (*pre_fn) (tree, void *),
-			 tree (*post_fn) (tree, void *), void *data);
-static void dfs_unmark_r (tree);
 static int check_hidden_convs (tree, int, int, tree, tree, tree);
 static tree split_conversions (tree, tree, tree, tree);
 static int lookup_conversions_r (tree, int, int,
@@ -44,10 +41,6 @@ static int lookup_conversions_r (tree, int, int,
 static int look_for_overrides_r (tree, tree);
 static tree lookup_field_r (tree, void *);
 static tree dfs_accessible_post (tree, void *);
-static tree dfs_walk_once_accessible_r (tree, bool, bool,
-	tree (*pre_fn) (tree, void *),
-	tree (*post_fn) (tree, void *),
-	void *data);
 static tree dfs_walk_once_accessible (tree, bool,
   tree (*pre_fn) (tree, void *),
   tree (*post_fn) (tree, void *),
@@ -1826,7 +1819,8 @@ dfs_walk_all (tree binfo, tree (*pre_fn) (tree, void *),
 
 static tree
 dfs_walk_once_r (tree binfo, tree (*pre_fn) (tree, void *),
-		 tree (*post_fn) (tree, void *), void *data)
+		 tree (*post_fn) (tree, void *), hash_set *pset,
+		 void *data)
 {
   tree rval;
   unsigned ix;
@@ -1849,13 +1843,10 @@ dfs_walk_once_r (tree binfo, tree (*pre_fn) (tree, void *),
   for (ix = 0; BINFO_BASE_ITERATE (binfo, ix, base_binfo); ix++)
 {
   if (BINFO_VIRTUAL_P (base_binfo))
-	{
-	  if (BINFO_MARKED (base_binfo))
-	continue;
-	  BINFO_MARKED (base_binfo) = 1;
-	}
+	if (pset->add (base_binfo))
+	  continue;
 
-  rval = dfs_walk_once_r (base_binfo, pre_fn, post_fn, data);
+  rval = dfs_walk_once_r (base_binfo, pre_fn, post_fn, pset, data);
   if (rval)
 	return rval;
 }
@@ -1872,30 +1863,6 @@ dfs_walk_once_r (tree binfo, tree (*pre_fn) (tree, void *),
   return NULL_TREE;
 }
 
-/* Worker for dfs_walk_once. Recursively unmark the virtual base binfos of
-   BINFO.  */
-
-static void
-dfs_unmark_r (tree binfo)
-{
-  unsigned ix;
-  tree base_binfo;
-
-  /* Process the basetypes.  */
-  for (ix = 0; BINFO_BASE_ITERATE (binfo, ix, base_binfo); ix++)
-{
-  if (BINFO_VIRTUAL_P (base_binfo))
-	{
-	  if (!BINFO_MARKED (base_binfo))
-	continue;
-	  BINFO_MARKED (base_binfo) = 0;
-	}
-  /* Only walk, if it can contain more virtual bases.  */
-  if (CLASSTYPE_VBASECLASSES (BINFO_TYPE (base_binfo)))
-	dfs_unmark_r (base_binfo);
-}
-}
-
 /* Like dfs_walk_all, except that binfos are not multiply walked.  For
non-diamond shaped hierarchies this is the same as dfs_walk_all.
For diamond shaped hierarchies we must mark the virtual bases, to
@@ -1918,22 +1885,8 @@ dfs_walk_once (tree binfo, tree (*pre_fn) (tree, void *),
 rval = dfs_walk_all (binfo, pre_fn, post_fn, data);
   else
 {
-  rval = dfs_walk_once_r (binfo, pre_fn, post_fn, data);
-  if (!BINFO_INHERITANCE_CHAIN (binfo))
-	{
-	  /* We are at the top of the hierarchy, and can use the
-	 CLASSTYPE_VBASECLASSES list for unmarking the virtual
-	 

Re: [hsa merge 00/10] Merge of HSA branch

[Gerald Pfeifer]

Hi Martin,

On Wed, 27 Jan 2016, Martin Jambor wrote:
> So what would you think about the following?  Perhaps it is too
> verbose but I wanted to mention the few areas users should know 
> have changed, if they happen to try HSA out.  I can certainly 
> cut it down a bit.

I like this.  In fact, in one or two spots we even may want to
be a little bit longer on the changes.html page.  (Definitely a
good idea to split this into the shorter announcement and the
longer one for the release notes.)

> Index: changes.html
> ===
> + GCC can now generate HSAIL for simple OpenMP device constructs
> +   if configured with --enable-offload-targets=hsa.  A new
> +   libgomp plugin then run these HSAIL kernels implementing these
> +   constructs on HSA capable GPUs via standard HSA run-time.

"run" -> "runs"

"via a standard HSA"

"run-time" -> "run time" (since it's a noun)

Will everyone know what HSAIL is?  Should we expand the acronym
at first or note (in parenthesis what it is)?

> +   If the HSA compilation back-end determines it cannot output HSAIL
> +   for a particular input, it gives a warning by default.  These
> +   warnings can be suppressed with -Wno-hsa.  To give a
> +   few examples, the HSA back-end does not implement compilation of

"back end"

> +   code using function pointers and variable-sized variables and

"variable-sized variables" is a bit confusing. ;-)  Is there a
better term?  "variable-sized arrays" I know, for example.

> +   When compilation for HSA is enabled, the compiler attempts to
> +   compile composite OpenMP constructs
> +  
> +#pragma omp target teams distribute parallel for
> +  into parallel HSA GPU kernels.

Above we had "HSAIL kernels", here "HSA GPU kernels".  Should we
converge on one?

> Index: index.html
> ===
> + Heterogeneous Systems Architecture support in GCC

Here I would omit the "in GCC" since this is our main page.

> + [2016-01-27]
> + http://www.hsafoundation.com/";> Heterogeneous Systems
> + Architecture 1.0  href="https://gcc.gnu.org/gcc-6/changes.html#hsa";>
> + support was added to GCC.  Contributed by Martin Jambor, Martin 
> Liška
> + and Michael Matz from SUSE.

How about "to GCC, contributed by..."?

Not too long for the main page I'd say.


This is okay with the changes/considering the questions above.

Gerald

Default compute dimensions

[Nathan Sidwell]

This patch adds default compute dimension handling.  Users rarely specify 
compute dimensions, expecting the toolchain to DTRT.  More savvy users would 
like to specify global defaults.  This patch permits both.


While the vector and worker dimensions are constrained by the target CPU 
implementation, the number of gangs is arbitrary.  The number that can compute 
in parallel depends on the physical number on your accelerator board -- but 
that's hidden behind the runtime API, which will schedule logical instances onto 
 the physical devices an an arbitrary order.  Without this patch, one's reliant 
 on the user specifying 'num_gangs(G)' with a  suitable 'G' on each offload 
region.  General code tends not to do that.Further, if one's relying on 
automatic paritioning in a parallel region via

#pragma acc loop auto
(we default auto there, if nothing overrides it)

then the user has no way of knowing which set of partions were being used, so 
would be unwise to specify a particular axis with non-unity size.


Hence this patch.

We add a '-fopenacc-dim=G:W:V' option, where G, W, & V are integer constants.  A 
particular entry may be omitted to get the default value.  I envision extending 
this to device_type support with something like DEV_T:G:W:V as comma-separated 
tuples.


If the option is omitted -- or dimensions not completely specified -- the 
backend gets to pick defaults.  For PTX we already force V as 32, and bounded W 
at 32 (but permitted smaller values).  This patch sets W & G to 32.  Explicitly 
specified values go through backend range checking.


The backend validate_dims hook is extended to handle these cases (with a NULL 
fndecl arg), and it is also changed to not fill in defaults (except in the case 
of determining the global default).


The loop partitioning code in the oacc dev lower pass is rearranged to return 
the mask of partition axes used, and then that pass selects a suitable default 
value for axes that are unspecified -- either the default value, or the minimum 
permitted value.


The outcome is that the naive user will get multiple compute elements for 
'#pragma acc loop' use in a parallel region, whereas before they had to specify 
the number of elements to guarantee that (but as mentioned above would then want 
to specify which axis each loop should be partitioned over).


ok?

nathan
2016-01-28  Nathan Sidwell  

	gcc/
	* config/nvptx/nvptx.c (PTX_GANG_DEFAULT): New.
	(nvptx_goacc_validate_dims): Extend to handle global defaults.
	* target.def (OACC_VALIDATE_DIMS): Extend documentation.
	* doc/tm.texti: Rebuilt.
	* doc/invoke.texi (fopenacc-dim): Document.
	* lto-wrapper.c (merge_and_complain): Add OPT_fopenacc_dim_ case.
	(append_compiler_options): Likewise.
	* omp-low.c (oacc_default_dims, oacc_min_dims): New.
	(oacc_parse_default_dims): New.
	(oacc_validate_dims): Add USED arg.  Select non-unity default when
	possible.
	(oacc_loop_fixed_partitions): Return mask of used partitions.
	(oacc_loop_auto_partitions): Emit dump info.
	(oacc_loop_partition): Return mask of used partitions.
	(execute_oacc_device_lower): Parse default dimension arg.  Adjust
	loop partitioning and validation calls.

	gcc/c-family/
	* c.opt (fopenacc-dim=): New option.

	gcc/fortran/
	* lang.opt (fopenacc-dim=): New option.

	libgomp/
	* testsuite/libgomp.oacc-c-c++-common/loop-dim-default.c: New.
	* testsuite/libgomp.oacc-fortran/routine-7.f90: Serialize loop.

Index: gcc/config/nvptx/nvptx.c
===
--- gcc/config/nvptx/nvptx.c	(revision 232881)
+++ gcc/config/nvptx/nvptx.c	(working copy)
@@ -4122,10 +4122,12 @@ nvptx_expand_builtin (tree exp, rtx targ
 /* Define dimension sizes for known hardware.  */
 #define PTX_VECTOR_LENGTH 32
 #define PTX_WORKER_LENGTH 32
+#define PTX_GANG_DEFAULT  32
 
 /* Validate compute dimensions of an OpenACC offload or routine, fill
in non-unity defaults.  FN_LEVEL indicates the level at which a
-   routine might spawn a loop.  It is negative for non-routines.  */
+   routine might spawn a loop.  It is negative for non-routines.  If
+   DECL is null, we are validating the default dimensions.  */
 
 static bool
 nvptx_goacc_validate_dims (tree decl, int dims[], int fn_level)
@@ -4133,11 +4135,12 @@ nvptx_goacc_validate_dims (tree decl, in
   bool changed = false;
 
   /* The vector size must be 32, unless this is a SEQ routine.  */
-  if (fn_level <= GOMP_DIM_VECTOR
+  if (fn_level <= GOMP_DIM_VECTOR && fn_level >= -1
+  && dims[GOMP_DIM_VECTOR] >= 0
   && dims[GOMP_DIM_VECTOR] != PTX_VECTOR_LENGTH)
 {
-  if (dims[GOMP_DIM_VECTOR] >= 0 && fn_level < 0)
-	warning_at (DECL_SOURCE_LOCATION (decl), 0,
+  if (fn_level < 0 && dims[GOMP_DIM_VECTOR] >= 0)
+	warning_at (decl ? DECL_SOURCE_LOCATION (decl) : UNKNOWN_LOCATION, 0,
 		dims[GOMP_DIM_VECTOR]
 		? "using vector_length (%d), ignoring %d"
 		: "using vector_length (%d), ignoring runtime setting",
@@ -4149,13 +4152,23 @@ nvp

Re: [PATCH] Fix cp_binding_level reuse logic

[Jason Merrill]

On 01/27/2016 07:44 PM, Patrick Palka wrote:

In begin_scope(), we are accidentally clearing the entire
free_binding_level store whenever we reuse a single GC-alloced
cp_binding_level structure from it.  This happens because we erroneously
update free_binding_level _after_ the pointer pointing to the next
available structure has been cleared, rather than doing it the other way
around.  This patch reorders the two operations.

This bug was introduced in commit 43959b95a / r118903 back in 2006,
during a refactoring of XNEW/memset -> XCNEW etc.

Using a dummy test file of mine (which simply #includes almost all of
the C++ stdlib headers), according to -ftime-report and
/usr/bin/time -v, this patch reduces the amount of GGC memory
allocated from 150MB to 148MB and reduces the maximum RSS from 130MB to
128MB, in each case a reduction of 1.5% or so.  Of course, this is because we 
now
reuse more and allocate fewer cp_binding_level structures.

Bootstrapped + regtested on x86_64-pc-linux-gnu, OK to commit at this
stage?  Or for stage 1?


I suppose this qualifies as a regression fix.  OK.

Jason

Re: RFA (tree.h): C++ PATCH for c++/67407 (ICE with protected access)

[Jason Merrill]

On 01/28/2016 10:09 AM, Jakub Jelinek wrote:

On Thu, Jan 28, 2016 at 10:03:59AM -0500, Jason Merrill wrote:

In this testcase, the problem was that we were checking DERIVED_FROM_P,
which uses dfs_walk_once and thus BINFO_MARKED, in the middle of a
dfs_walk_once_accessible, which also uses BINFO_MARKED, and the marks from
one walk were confusing the other walk.  Fixed by moving these binfo walking
functions to use a hash_set instead of BINFO_MARKED.

After this change, there are no uses of BINFO_MARKED left in the source
tree, so I'm inclined to rename it to BINFO_LANG_FLAG_0.  OK?


LGTM.
Do you see any measurable compatile time differences with this patch
on some large C++ preprocessed source (say some boost one)?


Nope.

Jason

[PATCH 1/3] [graphite] assert instead of silently failing code gen

[Sebastian Pop]

* graphite-isl-ast-to-gimple.c (get_rename_from_scev): Assert instead of
setting codegen_error to fail codegen.
---
 gcc/graphite-isl-ast-to-gimple.c | 26 ++
 1 file changed, 6 insertions(+), 20 deletions(-)

diff --git a/gcc/graphite-isl-ast-to-gimple.c b/gcc/graphite-isl-ast-to-gimple.c
index 81ed304..47225ef 100644
--- a/gcc/graphite-isl-ast-to-gimple.c
+++ b/gcc/graphite-isl-ast-to-gimple.c
@@ -1833,31 +1833,18 @@ get_rename_from_scev (tree old_name, gimple_seq *stmts, 
loop_p loop,
   tree scev = scalar_evolution_in_region (region->region, loop, old_name);
 
   /* At this point we should know the exact scev for each
- scalar SSA_NAME used in the scop: all the other scalar
- SSA_NAMEs should have been translated out of SSA using
- arrays with one element.  */
-  tree new_expr;
-  if (chrec_contains_undetermined (scev))
-{
-  codegen_error = true;
-  return build_zero_cst (TREE_TYPE (old_name));
-}
+ scalar SSA_NAME used in the scop.  */
+  gcc_assert (!chrec_contains_undetermined (scev));
 
-  new_expr = chrec_apply_map (scev, iv_map);
+  tree new_expr = chrec_apply_map (scev, iv_map);
 
   /* The apply should produce an expression tree containing
  the uses of the new induction variables.  We should be
  able to use new_expr instead of the old_name in the newly
  generated loop nest.  */
-  if (chrec_contains_undetermined (new_expr)
-  || tree_contains_chrecs (new_expr, NULL))
-{
-  codegen_error = true;
-  return build_zero_cst (TREE_TYPE (old_name));
-}
+  gcc_assert (!chrec_contains_undetermined (new_expr)
+ && !tree_contains_chrecs (new_expr, NULL));
 
-  /* We should check all the operands and all of them should dominate the use 
at
- new_expr.  */
   if (TREE_CODE (new_expr) == SSA_NAME)
 {
   basic_block bb = gimple_bb (SSA_NAME_DEF_STMT (new_expr));
@@ -1898,8 +1885,7 @@ get_rename_from_scev (tree old_name, gimple_seq *stmts, 
loop_p loop,
substitution map RENAME_MAP, inserting the gimplification code at
GSI_TGT, for the translation REGION, with the original copied
statement in LOOP, and using the induction variable renaming map
-   IV_MAP.  Returns true when something has been renamed.  codegen_error
-   is set when the code generation cannot continue.  */
+   IV_MAP.  Returns true when something has been renamed.  */
 
 bool
 translate_isl_ast_to_gimple::rename_uses (gimple *copy,
-- 
2.5.0

[PATCH 3/3] [graphite] remove out of sync comments

[Sebastian Pop]

* graphite-isl-ast-to-gimple.c (class translate_isl_ast_to_gimple):
Remove comments from class declarations: they are already in the code
close by the defs.
---
 gcc/graphite-isl-ast-to-gimple.c | 437 ---
 1 file changed, 83 insertions(+), 354 deletions(-)

diff --git a/gcc/graphite-isl-ast-to-gimple.c b/gcc/graphite-isl-ast-to-gimple.c
index ded1f74..161b434 100644
--- a/gcc/graphite-isl-ast-to-gimple.c
+++ b/gcc/graphite-isl-ast-to-gimple.c
@@ -171,342 +171,117 @@ class translate_isl_ast_to_gimple
 {
  public:
   translate_isl_ast_to_gimple (sese_info_p r)
-: region (r), codegen_error (false)
-{ }
-
-  /* Translates an isl AST node NODE to GCC representation in the
- context of a SESE.  */
+: region (r), codegen_error (false) { }
   edge translate_isl_ast (loop_p context_loop, __isl_keep isl_ast_node *node,
  edge next_e, ivs_params &ip);
-
-  /* Translates an isl_ast_node_for to Gimple.  */
   edge translate_isl_ast_node_for (loop_p context_loop,
   __isl_keep isl_ast_node *node,
   edge next_e, ivs_params &ip);
-
-  /* Create the loop for a isl_ast_node_for.
-
- - NEXT_E is the edge where new generated code should be attached.  */
   edge translate_isl_ast_for_loop (loop_p context_loop,
   __isl_keep isl_ast_node *node_for,
   edge next_e,
   tree type, tree lb, tree ub,
   ivs_params &ip);
-
-  /* Translates an isl_ast_node_if to Gimple.  */
   edge translate_isl_ast_node_if (loop_p context_loop,
  __isl_keep isl_ast_node *node,
  edge next_e, ivs_params &ip);
-
-  /* Translates an isl_ast_node_user to Gimple.
-
- FIXME: We should remove iv_map.create (loop->num + 1), if it is
- possible.  */
   edge translate_isl_ast_node_user (__isl_keep isl_ast_node *node,
edge next_e, ivs_params &ip);
-
-  /* Translates an isl_ast_node_block to Gimple.  */
   edge translate_isl_ast_node_block (loop_p context_loop,
 __isl_keep isl_ast_node *node,
 edge next_e, ivs_params &ip);
-
-  /* Converts a unary isl_ast_expr_op expression E to a GCC expression tree of
- type TYPE.  */
   tree unary_op_to_tree (tree type, __isl_take isl_ast_expr *expr,
 ivs_params &ip);
-
-  /* Converts a binary isl_ast_expr_op expression E to a GCC expression tree of
- type TYPE.  */
   tree binary_op_to_tree (tree type, __isl_take isl_ast_expr *expr,
  ivs_params &ip);
-
-  /* Converts a ternary isl_ast_expr_op expression E to a GCC expression tree 
of
- type TYPE.  */
   tree ternary_op_to_tree (tree type, __isl_take isl_ast_expr *expr,
   ivs_params &ip);
-
-  /* Converts an isl_ast_expr_op expression E with unknown number of arguments
- to a GCC expression tree of type TYPE.  */
   tree nary_op_to_tree (tree type, __isl_take isl_ast_expr *expr,
ivs_params &ip);
-
-  /* Converts an isl AST expression E back to a GCC expression tree of
- type TYPE.  */
   tree gcc_expression_from_isl_expression (tree type,
   __isl_take isl_ast_expr *,
   ivs_params &ip);
-
-  /* Return the tree variable that corresponds to the given isl ast identifier
- expression (an isl_ast_expr of type isl_ast_expr_id).
-
- FIXME: We should replace blind conversation of id's type with derivation
- of the optimal type when we get the corresponding isl support.  Blindly
- converting type sizes may be problematic when we switch to smaller
- types.  */
   tree gcc_expression_from_isl_ast_expr_id (tree type,
__isl_keep isl_ast_expr *expr_id,
ivs_params &ip);
-
-  /* Converts an isl_ast_expr_int expression E to a GCC expression tree of
- type TYPE.  */
   tree gcc_expression_from_isl_expr_int (tree type,
 __isl_take isl_ast_expr *expr);
-
-  /* Converts an isl_ast_expr_op expression E to a GCC expression tree of
- type TYPE.  */
   tree gcc_expression_from_isl_expr_op (tree type,
__isl_take isl_ast_expr *expr,
ivs_params &ip);
-
-  /* Creates a new LOOP corresponding to isl_ast_node_for.  Inserts an
- induction variable for the new LOOP.  New LOOP is attached to CFG
- starting at ENTRY_EDGE.  LOOP is inserted into the loop tree and
- becomes the child loop of the OUTER_LOOP.  NEWIVS_INDEX binds
- isl's scattering name to the induction variable created for the
- loop

[PATCH 2/3] [graphite] use codegen_error_p

[Sebastian Pop]

* graphite-isl-ast-to-gimple.c (binary_op_to_tree): Call 
codegen_error_p.
(ternary_op_to_tree): Same.
(unary_op_to_tree): Same.
(nary_op_to_tree): Same.
(gcc_expression_from_isl_expr_op): Same.
(gcc_expression_from_isl_expression): Same.
(graphite_create_new_loop): Same.
(graphite_create_new_loop_guard): Same.
(build_iv_mapping): Same.
(graphite_create_new_guard): Same.
(translate_isl_ast_to_gimple::copy_loop_phi_nodes): Same.
(translate_isl_ast_to_gimple::translate_pending_phi_nodes): Same.
---
 gcc/graphite-isl-ast-to-gimple.c | 49 
 1 file changed, 25 insertions(+), 24 deletions(-)

diff --git a/gcc/graphite-isl-ast-to-gimple.c b/gcc/graphite-isl-ast-to-gimple.c
index 47225ef..ded1f74 100644
--- a/gcc/graphite-isl-ast-to-gimple.c
+++ b/gcc/graphite-isl-ast-to-gimple.c
@@ -438,16 +438,14 @@ class translate_isl_ast_to_gimple
vec iv_map);
 
   /* Duplicates the statements of basic block BB into basic block NEW_BB
- and compute the new induction variables according to the IV_MAP.
- CODEGEN_ERROR is set when the code generation cannot continue.  */
+ and compute the new induction variables according to the IV_MAP.  */
 
   bool graphite_copy_stmts_from_block (basic_block bb, basic_block new_bb,
   vec iv_map);
 
   /* Copies BB and includes in the copied BB all the statements that can
  be reached following the use-def chains from the memory accesses,
- and returns the next edge following this new block.  codegen_error is
- set when the code generation cannot continue.  */
+ and returns the next edge following this new block.  */
 
   edge copy_bb_and_scalar_dependences (basic_block bb, edge next_e,
   vec iv_map);
@@ -480,8 +478,7 @@ class translate_isl_ast_to_gimple
  RENAME_MAP, inserting the gimplification code at GSI_TGT, for the
  translation REGION, with the original copied statement in LOOP, and using
  the induction variable renaming map IV_MAP.  Returns true when something
- has been renamed.  codegen_error is set when the code generation cannot
- continue.  */
+ has been renamed.  */
 
   bool rename_uses (gimple *copy, gimple_stmt_iterator *gsi_tgt,
basic_block old_bb, loop_p loop, vec iv_map);
@@ -597,7 +594,7 @@ binary_op_to_tree (tree type, __isl_take isl_ast_expr 
*expr, ivs_params &ip)
   enum isl_ast_op_type expr_type = isl_ast_expr_get_op_type (expr);
   isl_ast_expr_free (expr);
 
-  if (codegen_error)
+  if (codegen_error_p ())
 return NULL_TREE;
 
   switch (expr_type)
@@ -699,7 +696,7 @@ ternary_op_to_tree (tree type, __isl_take isl_ast_expr 
*expr, ivs_params &ip)
   tree c = gcc_expression_from_isl_expression (type, arg_expr, ip);
   isl_ast_expr_free (expr);
 
-  if (codegen_error)
+  if (codegen_error_p ())
 return NULL_TREE;
 
   return fold_build3 (COND_EXPR, type, a, b, c);
@@ -716,7 +713,8 @@ unary_op_to_tree (tree type, __isl_take isl_ast_expr *expr, 
ivs_params &ip)
   isl_ast_expr *arg_expr = isl_ast_expr_get_op_arg (expr, 0);
   tree tree_expr = gcc_expression_from_isl_expression (type, arg_expr, ip);
   isl_ast_expr_free (expr);
-  return codegen_error ? NULL_TREE : fold_build1 (NEGATE_EXPR, type, 
tree_expr);
+  return codegen_error_p () ? NULL_TREE
+: fold_build1 (NEGATE_EXPR, type, tree_expr);
 }
 
 /* Converts an isl_ast_expr_op expression E with unknown number of arguments
@@ -743,7 +741,7 @@ nary_op_to_tree (tree type, __isl_take isl_ast_expr *expr, 
ivs_params &ip)
   isl_ast_expr *arg_expr = isl_ast_expr_get_op_arg (expr, 0);
   tree res = gcc_expression_from_isl_expression (type, arg_expr, ip);
 
-  if (codegen_error)
+  if (codegen_error_p ())
 {
   isl_ast_expr_free (expr);
   return NULL_TREE;
@@ -755,7 +753,7 @@ nary_op_to_tree (tree type, __isl_take isl_ast_expr *expr, 
ivs_params &ip)
   arg_expr = isl_ast_expr_get_op_arg (expr, i);
   tree t = gcc_expression_from_isl_expression (type, arg_expr, ip);
 
-  if (codegen_error)
+  if (codegen_error_p ())
{
  isl_ast_expr_free (expr);
  return NULL_TREE;
@@ -775,7 +773,7 @@ translate_isl_ast_to_gimple::
 gcc_expression_from_isl_expr_op (tree type, __isl_take isl_ast_expr *expr,
 ivs_params &ip)
 {
-  if (codegen_error)
+  if (codegen_error_p ())
 {
   isl_ast_expr_free (expr);
   return NULL_TREE;
@@ -837,7 +835,7 @@ translate_isl_ast_to_gimple::
 gcc_expression_from_isl_expression (tree type, __isl_take isl_ast_expr *expr,
ivs_params &ip)
 {
-  if (codegen_error)
+  if (codegen_error_p ())
 {
   isl_ast_expr_free (expr);
   return NULL_TREE;
@@ -879,7 +877,7 @@ graphite_create_new_loop (edge entry_edge, __isl_keep 
isl_ast_node *node_for,
   tree stride = 

RE: [Patch, MIPS] Patch for PR 68400, a mips16 bug

[Moore, Catherine]

> -Original Message-
> From: Steve Ellcey [mailto:sell...@imgtec.com]
> Sent: Tuesday, January 26, 2016 3:43 PM
> To: gcc-patches@gcc.gnu.org
> Cc: matthew.fort...@imgtec.com; Moore, Catherine
> Subject: [Patch, MIPS] Patch for PR 68400, a mips16 bug
> 
> Here is a patch for PR6400.  The problem is that and_operands_ok was
> checking one operand to see if it was a memory_operand but MIPS16
> addressing is more restrictive than what the general memory_operand
> allows.  The fix was to call mips_classify_address if TARGET_MIPS16 is set
> because it will do a more complete mips16 addressing check and reject
> operands that do not meet the more restrictive requirements.
> 
> I ran the GCC testsuite with no regressions and have included a test case as
> part of this patch.
> 
> OK to checkin?
> 
> Steve Ellcey
> sell...@imgtec.com
> 
> 
> 2016-01-26  Steve Ellcey  
> 
>   PR target/68400
>   * config/mips/mips.c (and_operands_ok): Add MIPS16 check.
> 
> 
> 
This is OK.
Thanks, Catherine

[PATCH] [graphite] make debug comment more explicit

[Sebastian Pop]

2016-01-28  Abderrazek Zaafrani  

* graphite-optimize-isl.c (optimize_isl): Print a different debug
message when isl does not return a valid schedule.
---
 gcc/graphite-optimize-isl.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/gcc/graphite-optimize-isl.c b/gcc/graphite-optimize-isl.c
index d1620d5..6b3108d 100644
--- a/gcc/graphite-optimize-isl.c
+++ b/gcc/graphite-optimize-isl.c
@@ -477,8 +477,15 @@ optimize_isl (scop_p scop)
   if (!schedule || isl_ctx_last_error (scop->isl_context) == isl_error_quota)
 {
   if (dump_file && dump_flags)
-   fprintf (dump_file, "isl timed out --param max-isl-operations=%d\n",
-max_operations);
+   {
+ if (!schedule)
+   fprintf (dump_file, "isl did not return any schedule.\n",
+max_operations);
+ else
+   fprintf (dump_file, "isl timed out --param max-isl-operations=%d\n",
+max_operations);
+   }
+
   if (schedule)
isl_schedule_free (schedule);
   return false;
-- 
2.5.0

Re: new port: vn8

[Joseph Myers]

On Wed, 27 Jan 2016, Sandra Loosemore wrote:

> On 01/27/2016 08:47 PM, Nguyễn Sinh Ngọc wrote:
> > > Where is the patch under discussion here?  I can't find it in the
> > > archives.
> > 
> > This is the source code of VN8 target:
> > https://drive.google.com/file/d/0B169XTHeyQCfb2ZVak5VRm4tcHc/view?usp=sharing
> 
> Thanks.  I skimmed it over quickly to see if the documentation changes were in
> order, but I can't find any.  :-(  When you revise the port against current
> trunk and resubmit it for review, please remember to add documentation for all
> the target-specific command-line options and built-in functions in the
> appropriate sections of the GCC manual.

Specifically, follow the checklist in sourcebuild.texi for everything that 
needs to be documented for a new port.  And if it's too big for 
gcc-patches, split it into as many messages as necessary for it to be 
accepted by the list, don't provide it only as a link to an external site.

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

Re: RFA: patch to fix PR69299

[Vladimir Makarov]

On 01/28/2016 08:05 AM, Jakub Jelinek wrote:

On Wed, Jan 27, 2016 at 04:01:23PM -0500, Vladimir Makarov wrote:

   The following patch fixes PR69299.

   The details of the problem is described on

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

   The patch was successfully bootstrapped and tested on x86/x86-64.

   The patch introduces a new type of constraints
define_special_memory_constraint for memory constraints whose address reload
can not make memory to satisfy the constraint.  It is useful when
specifically aligned memory is necessary or desirable. I don't know what is
the best name for this constraint.  I use special_memory_constraint but it
could be more specific, e.g. aligned_memory_constraint.  Please let me know
what is the best name for you.

   Is the patch ok to commit?

I support the general idea and for naming will defer to Jeff, just have some
nits below.  But it is your code and area of expertise, so I don't claim to
be an expert here...
Thanks for the comments, Jakub.  I am not sure about all these changes 
-- tt is hard to predict all possible consequences of the decisions 
because of the RA complexity.  But some comments made me rethink the patch.

--- ira-costs.c (revision 232571)
+++ ira-costs.c (working copy)
@@ -777,6 +777,7 @@ record_reg_classes (int n_alts, int n_op
  break;
  
  		case CT_MEMORY:

+   case CT_SPECIAL_MEMORY:
  /* Every MEM can be reloaded to fit.  */
  insn_allows_mem[i] = allows_mem[i] = 1;
  if (MEM_P (op))

The comment is true only for CT_MEMORY.  Wonder if it wouldn't be better to
handle CT_SPECIAL_MEMORY separately, perhaps as:

  case CT_SPECIAL_MEMORY:
if (MEM_P (op) && constraint_satisfied_p (op, cn))
  {
insn_allows_mem[i] = allows_mem[i] = 1;
win = 1;
  }
break;

?  I.e. if the constraint is already satisfied, treat it like memory
constraint, otherwise treat like (unsatisfied) fixed form constraint.
Or, if you want to account for the possibility that it doesn't satisfy the
constraint yet due to address that if reloaded would make it satisfy,
consider !memory_operand (op, ...) case as unknown, with no need to
check the constraint.  Because if op satisfies already memory_operand,
but doesn't constraint_satisfied_p, it means it will never satisfy.

The difference in code most probably does not affect generated code 
correctness but may change code quality.  After some thinking, I decided 
to change it to


  case CT_SPECIAL_MEMORY:
 if (MEM_P (op) && constraint_satisfied_p (op, cn))
win = 1;
 allows_mem[i] = insn_allows_mem[i] = 1;
 break;



--- ira.c   (revision 232571)
+++ ira.c   (working copy)
@@ -1868,6 +1868,7 @@ ira_setup_alts (rtx_insn *insn, HARD_REG
  
  			case CT_ADDRESS:

case CT_MEMORY:
+   case CT_SPECIAL_MEMORY:
  goto op_success;

Perhaps treat it like CT_FIXED_FORM here instead?  I.e. op_success only
if the constraint is satisfied?  Or perhaps treat it as possible op_success
if !memory_operand, as mentioned above.
This would exclude consideration of possible transformation: unaligned 
memory -> reg -> aligned memory.  LRA can figure out the profitability 
of this.  But taking complexity of RA we can do unaligned memory -> 
pseudo first assigning a hard reg to the pseudo and on later subpasses 
to spill the pseudo for some reasons.  Removing such RA freedom might 
result in having LRA stuck.

--- recog.c (revision 232571)
+++ recog.c (working copy)
@@ -1791,6 +1791,7 @@ asm_operand_ok (rtx op, const char *cons
  break;
  
  	case CT_MEMORY:

+   case CT_SPECIAL_MEMORY:
  /* Every memory operand can be reloaded to fit.  */
  result = result || memory_operand (op, VOIDmode);
  break;

Again, I'd treat it like CT_FIXED_FORM here, or at least if
memory_operand check also constraint_satisfied_p.


I would not change it.  The reasons are described in the previous comment.

I'll test the change for ira-costs.c.  If I find something wrong I'll 
wrote about it.

[PATCH, rs6000] Partial fix for PR65546 (GCC 6)

[Bill Schmidt]

Hi,

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65546 discusses the failure
of gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c.  The test fails
differently on GCC 4.9 and 5 than it does on GCC 6.  For GCC 6, the test
case is faulty, as we only expect to see the "vectorization not
profitable" statement when misaligned loads/stores are not efficient on
the target hardware.  This patch fixes the test for GCC 6.

Something else is going on in the earlier releases, which I plan to look
at separately.

Verified on powerpc64le-unknown-linux-gnu.  Is this okay for trunk?

Thanks,
Bill


2016-01-28  Bill Schmidt  

PR target/65546
* gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c: Disable check
for "vectorization not profitable" when the target supports
misaligned loads and stores.


Index: gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c
===
--- gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c
(revision 232890)
+++ gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c
(working copy)
@@ -46,5 +46,5 @@ int main (void)
   return main1 ();
 } 
 
-/* { dg-final { scan-tree-dump-times "vectorization not profitable" 1 "vect" } 
} */
+/* { dg-final { scan-tree-dump-times "vectorization not profitable" 1 "vect" { 
target { ! vect_hw_misalign } } } } */
 /* { dg-final { scan-tree-dump-times "vectorized 1 loops" 0 "vect" { target { 
! vect_hw_misalign } } } } */

Re: [gomp4, PR68977, Committed] Don't gimplify in ssa mode if seen_error in oacc_xform_loop

[Tom de Vries]

On 28/01/16 14:32, Richard Biener wrote:

On Mon, Jan 25, 2016 at 12:00 PM, Tom de Vries  wrote:

On 14/01/16 10:43, Richard Biener wrote:


On Wed, Jan 13, 2016 at 9:04 PM, Tom de Vries 
wrote:


Hi,

At r231739, there was an ICE when checking code generated by
oacc_xform_loop, in case the source contained an error.

Due to seen_error (), gimplification during oacc_xform_loop bailed out,
and
an uninitialized var was introduced.  Because of gimplifying in ssa mode,
that caused an ICE.

I can't reproduce this any longer, but I think the fix still makes sense.
The patch makes sure oacc_xform_loop gimplifies in non-ssa mode if
seen_error ().



I don't think it makes "sense" in any way.  After seen_error () a
following ICE
will be "confused after earlier errors" in release mode and thus I think
that's
not an important problem to paper over with this kind of "hack".

I'd rather avoid doing any of omp-low if seen_error ()?



The error triggered in oacc_device_lower, so there's nothing we can do
before (in omp-low).

How about this fix, which replaces the oacc ifn calls with zero-assignments
if seen_error ()?


Again it looks like too much complexity for an ICE-after-error which will
be reported as "confused after errors" only.


IMO it's not much different from what is done in lower_omp_1:
...
  /* If we have issued syntax errors, avoid doing any heavy lifting.
 Just replace the OMP directives with a NOP to avoid
 confusing RTL expansion.  */
  if (seen_error () && is_gimple_omp (stmt))
{
  gsi_replace (gsi_p, gimple_build_nop (), true);
  return;
}
...


I'd accept a patch that simply
stops processing the function before lowering which is what we usually
do with this kind of cases [yes, it might make sense to start tracking
seen-error per function].



[ AFAIU, the patch below stops after lowering. ]


So in this case add a seen_errors () guard to cgraph_node::expand ()
like the following:

Index: cgraphunit.c
===
--- cgraphunit.c(revision 232666)
+++ cgraphunit.c(working copy)
@@ -1967,15 +1967,18 @@ cgraph_node::expand (void)

execute_all_ipa_transforms ();

-  /* Perform all tree transforms and optimizations.  */
-
-  /* Signal the start of passes.  */
-  invoke_plugin_callbacks (PLUGIN_ALL_PASSES_START, NULL);
-
-  execute_pass_list (cfun, g->get_passes ()->all_passes);
-
-  /* Signal the end of passes.  */
-  invoke_plugin_callbacks (PLUGIN_ALL_PASSES_END, NULL);
+  if (! seen_error ())
+{
+  /* Perform all tree transforms and optimizations.  */
+
+  /* Signal the start of passes.  */
+  invoke_plugin_callbacks (PLUGIN_ALL_PASSES_START, NULL);
+
+  execute_pass_list (cfun, g->get_passes ()->all_passes);
+
+  /* Signal the end of passes.  */
+  invoke_plugin_callbacks (PLUGIN_ALL_PASSES_END, NULL);
+}

bitmap_obstack_release (®_obstack);


I suppose the patch makes sense in general.

But it doesn't address the scenario I'm trying to fix: 
pass_oacc_device_lower signals an error, and then may run into an ICE 
during gimplification in that same pass.


What would work (and is less fine-grained than the solutions I've 
proposed until now) is bailing out of pass_oacc_device_lower once 
seen_error, before doing any gimplification, and then not running any 
further passes, to prevent running into further ICEs.


Thanks,
- Tom

Re: [PATCH, aarch64] Fix pr69305 -- addti miscompilation

[Richard Henderson]

Here's the patch as committed.

It includes a few name changes from the addv patch I posted,
which correspond nicely with a name clarification that James
requested during feedback.


r~
PR target/69305
* config/aarch64/aarch64-modes.def (CC_Cmode): New
* config/aarch64/aarch64-protos.h: Update.
* config/aarch64/aarch64.c (aarch64_zero_extend_const_eq): New.
(aarch64_select_cc_mode): Add check for use of CC_Cmode.
(aarch64_get_condition_code_1): Handle CC_Cmode.
* config/aarch64/aarch64.md (addti3): Use adddi3_compareC.
(*add3_compareC_cconly_imm): New.
(*add3_compareC_cconly): New.
(*add3_compareC_imm): New.
(add3_compareC): New.
(add3_carryin, *addsi3_carryin_uxtw): Sort compare operand
to be first.  Use aarch64_carry_operation.
(*add3_carryin_alt1, *addsi3_carryin_alt1_uxtw): Remove.
(*add3_carryin_alt2, *addsi3_carryin_alt2_uxtw): Remove.
(*add3_carryin_alt3, *addsi3_carryin_alt3_uxtw): Remove.
(subti3): Use subdi3_compare1.
(*sub3_compare0): Rename from sub3_compare0.
(sub3_compare1): New.
(*sub3_carryin0, *subsi3_carryin_uxtw): New.
(*sub3_carryin): Use aarch64_borrow_operation.
(*subsi3_carryin_uxtw): Likewise.
(*ngc, *ngcsi_uxtw): Likewise.
(*sub3_carryin_alt, *subsi3_carryin_alt_uxtw): New.
* config/aarch64/iterators.md (DWI): New.
* config/aarch64/predicates.md (aarch64_carry_operation): New.
(aarch64_borrow_operation): New.


diff --git a/gcc/config/aarch64/aarch64-modes.def 
b/gcc/config/aarch64/aarch64-modes.def
index 3fab205..7de0b3f 100644
--- a/gcc/config/aarch64/aarch64-modes.def
+++ b/gcc/config/aarch64/aarch64-modes.def
@@ -25,6 +25,7 @@ CC_MODE (CC_ZESWP); /* zero-extend LHS (but swap to make it 
RHS).  */
 CC_MODE (CC_SESWP); /* sign-extend LHS (but swap to make it RHS).  */
 CC_MODE (CC_NZ);/* Only N and Z bits of condition flags are valid.  */
 CC_MODE (CC_Z); /* Only Z bit of condition flags is valid.  */
+CC_MODE (CC_C); /* Only C bit of condition flags is valid.  */
 
 /* Half-precision floating point for __fp16.  */
 FLOAT_MODE (HF, 2, 0);
diff --git a/gcc/config/aarch64/aarch64-protos.h 
b/gcc/config/aarch64/aarch64-protos.h
index bd900c6..78870e2 100644
--- a/gcc/config/aarch64/aarch64-protos.h
+++ b/gcc/config/aarch64/aarch64-protos.h
@@ -290,6 +290,7 @@ void aarch64_declare_function_name (FILE *, const char*, 
tree);
 bool aarch64_legitimate_pic_operand_p (rtx);
 bool aarch64_modes_tieable_p (machine_mode mode1,
  machine_mode mode2);
+bool aarch64_zero_extend_const_eq (machine_mode, rtx, machine_mode, rtx);
 bool aarch64_move_imm (HOST_WIDE_INT, machine_mode);
 bool aarch64_mov_operand_p (rtx, machine_mode);
 int aarch64_simd_attr_length_rglist (enum machine_mode);
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index bba7a9b..aee6685 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -1493,6 +1493,16 @@ aarch64_split_simd_move (rtx dst, rtx src)
 }
 }
 
+bool
+aarch64_zero_extend_const_eq (machine_mode xmode, rtx x,
+ machine_mode ymode, rtx y)
+{
+  rtx r = simplify_const_unary_operation (ZERO_EXTEND, xmode, y, ymode);
+  gcc_assert (r != NULL);
+  return rtx_equal_p (x, r);
+}
+ 
+
 static rtx
 aarch64_force_temporary (machine_mode mode, rtx x, rtx value)
 {
@@ -4189,6 +4199,13 @@ aarch64_select_cc_mode (RTX_CODE code, rtx x, rtx y)
 return ((code == GT || code == GE || code == LE || code == LT)
? CC_SESWPmode : CC_ZESWPmode);
 
+  /* A test for unsigned overflow.  */
+  if ((GET_MODE (x) == DImode || GET_MODE (x) == TImode)
+  && code == NE
+  && GET_CODE (x) == PLUS
+  && GET_CODE (y) == ZERO_EXTEND)
+return CC_Cmode;
+
   /* For everything else, return CCmode.  */
   return CCmode;
 }
@@ -4288,6 +4305,15 @@ aarch64_get_condition_code_1 (enum machine_mode mode, 
enum rtx_code comp_code)
}
   break;
 
+case CC_Cmode:
+  switch (comp_code)
+   {
+   case NE: return AARCH64_CS;
+   case EQ: return AARCH64_CC;
+   default: return -1;
+   }
+  break;
+
 default:
   return -1;
   break;
diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index 5d35261..b42f550 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -1710,7 +1710,7 @@
   ""
 {
   rtx low = gen_reg_rtx (DImode);
-  emit_insn (gen_adddi3_compare0 (low, gen_lowpart (DImode, operands[1]),
+  emit_insn (gen_adddi3_compareC (low, gen_lowpart (DImode, operands[1]),
  gen_lowpart (DImode, operands[2])));
 
   rtx high = gen_reg_rtx (DImode);
@@ -1755,6 +1755,71 @@
   [(set_attr "type" "alus_sreg,alus_imm,alus_imm")]
 )
 
+(define_insn "*add3_compareC_cconly_imm"
+  [(set (reg:CC_C CC_REGNUM

Re: [PATCH, gcc7, aarch64] Add arithmetic overflow patterns

[Richard Henderson]

On 01/28/2016 01:50 AM, Michael Collison wrote:
> Hi Richard,
> 
> Note that this patch appears to depend on your previous patch:
> 
> https://gcc.gnu.org/ml/gcc-patches/2016-01/txtDPaXOBMuOB.txt
> 
> for the definition of define_mode_attr DWI. I was looking at this patch as I
> was working on Bugzilla 68543 which this will address.

Yes, it did.  I've now committed a slightly modified patch for pr69305, which
includes some name changes that were present in this patch.  There may be minor
patch conflicts but nothing major.



r~

Re: [PATCH, rs6000] Partial fix for PR65546 (GCC 6)

[Bill Schmidt]

Actually, please hold off on this.  The test in general is just faulty.
I'll get something more complete later on.

Sorry for the noise,
Bill

On Thu, 2016-01-28 at 11:45 -0600, Bill Schmidt wrote:
> Hi,
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65546 discusses the failure
> of gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c.  The test fails
> differently on GCC 4.9 and 5 than it does on GCC 6.  For GCC 6, the test
> case is faulty, as we only expect to see the "vectorization not
> profitable" statement when misaligned loads/stores are not efficient on
> the target hardware.  This patch fixes the test for GCC 6.
> 
> Something else is going on in the earlier releases, which I plan to look
> at separately.
> 
> Verified on powerpc64le-unknown-linux-gnu.  Is this okay for trunk?
> 
> Thanks,
> Bill
> 
> 
> 2016-01-28  Bill Schmidt  
> 
>   PR target/65546
>   * gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c: Disable check
>   for "vectorization not profitable" when the target supports
>   misaligned loads and stores.
> 
> 
> Index: gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c
> ===
> --- gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c  
> (revision 232890)
> +++ gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c  
> (working copy)
> @@ -46,5 +46,5 @@ int main (void)
>return main1 ();
>  } 
> 
> -/* { dg-final { scan-tree-dump-times "vectorization not profitable" 1 "vect" 
> } } */
> +/* { dg-final { scan-tree-dump-times "vectorization not profitable" 1 "vect" 
> { target { ! vect_hw_misalign } } } } */
>  /* { dg-final { scan-tree-dump-times "vectorized 1 loops" 0 "vect" { target 
> { ! vect_hw_misalign } } } } */
> 
> 

Re: [PATCH] [graphite] make debug comment more explicit

[H.J. Lu]

On Thu, Jan 28, 2016 at 8:32 AM, Sebastian Pop  wrote:
> 2016-01-28  Abderrazek Zaafrani  
>
> * graphite-optimize-isl.c (optimize_isl): Print a different debug
> message when isl does not return a valid schedule.
> ---
>  gcc/graphite-optimize-isl.c | 11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/gcc/graphite-optimize-isl.c b/gcc/graphite-optimize-isl.c
> index d1620d5..6b3108d 100644
> --- a/gcc/graphite-optimize-isl.c
> +++ b/gcc/graphite-optimize-isl.c
> @@ -477,8 +477,15 @@ optimize_isl (scop_p scop)
>if (!schedule || isl_ctx_last_error (scop->isl_context) == isl_error_quota)
>  {
>if (dump_file && dump_flags)
> -   fprintf (dump_file, "isl timed out --param max-isl-operations=%d\n",
> -max_operations);
> +   {
> + if (!schedule)
> +   fprintf (dump_file, "isl did not return any schedule.\n",
> +max_operations);
> + else
> +   fprintf (dump_file, "isl timed out --param 
> max-isl-operations=%d\n",
> +max_operations);
> +   }
> +
>if (schedule)
> isl_schedule_free (schedule);
>return false;
> --
> 2.5.0
>

I checked in this to fix

/export/gnu/import/git/sources/gcc/gcc/graphite-optimize-isl.c:483:22:
error: too many arguments for format [-Werror=format-extra-args]
max_operations);
  ^
cc1plus: all warnings being treated as errors
Makefile:1085: recipe for target 'graphite-optimize-isl.o' failed
make[5]: *** [graphite-optimize-isl.o] Error 1
make[5]: *** Waiting for unfinished jobs


-- 
H.J.
--
Index: ChangeLog
===
--- ChangeLog (revision 232938)
+++ ChangeLog (working copy)
@@ -1,3 +1,7 @@
+2016-01-28  H.J. Lu  
+
+ * graphite-optimize-isl.c (optimize_isl): Fix dump.
+
 2016-01-28  Richard Henderson  

  PR target/69305
Index: graphite-optimize-isl.c
===
--- graphite-optimize-isl.c (revision 232938)
+++ graphite-optimize-isl.c (working copy)
@@ -479,8 +479,7 @@ optimize_isl (scop_p scop)
   if (dump_file && dump_flags)
  {
   if (!schedule)
-fprintf (dump_file, "isl did not return any schedule.\n",
- max_operations);
+fprintf (dump_file, "isl did not return any schedule.\n");
   else
 fprintf (dump_file, "isl timed out --param max-isl-operations=%d\n",
  max_operations);

Re: [PATCH] Fix use of declare'd vars by routine procedures.

[James Norris]

Jakub,

On 01/22/2016 04:39 AM, Jakub Jelinek wrote:


As for the extra error, I think it would be better to diagnose this during
gimplification, that way you do it for all FEs, plus you have the omp
context in there, etc.  The error wording is weird, the diagnostic
should make it clear use of what is invalid in what and why.

Jakub



I think the attached change is what you had in mind with
regard to doing the check at gimplification time.

OK?

Thanks for taking the time to review,
Jim


ChangeLog entries

gcc/
* gimplify.c (gimplify_var_or_parm_decl): Add variable usage check.
gcc/testsuite/
* c-c++-common/goacc/routine-5.c: Add tests.

Index: gcc/ChangeLog
===
diff --git a/trunk/gcc/ChangeLog b/trunk/gcc/ChangeLog
--- a/trunk/gcc/ChangeLog	(revision 232802)
+++ b/trunk/gcc/ChangeLog	(working copy)
@@ -1,3 +1,7 @@
+2016-01-XX  James Norris  
+
+	* gimplify.c (gimplify_var_or_parm_decl): Add usage check.
+
 2016-01-25  Jeff Law  
 
 	PR tree-optimization/69196
Index: gcc/gimplify.c
===
diff --git a/trunk/gcc/gimplify.c b/trunk/gcc/gimplify.c
--- a/trunk/gcc/gimplify.c	(revision 232802)
+++ b/trunk/gcc/gimplify.c	(working copy)
@@ -1841,6 +1841,33 @@
   return GS_ERROR;
 }
 
+  /* Validate variable for use within routine function.  */
+  if (gimplify_omp_ctxp && gimplify_omp_ctxp->region_type == ORT_TARGET
+  && get_oacc_fn_attrib (current_function_decl)
+  && TREE_CODE (decl) == VAR_DECL
+  && is_global_var (decl)
+  && ((TREE_STATIC (decl) && !DECL_EXTERNAL (decl))
+	  || (!TREE_STATIC (decl) && DECL_EXTERNAL (decl
+{
+  location_t loc = DECL_SOURCE_LOCATION (decl);
+
+  if (lookup_attribute ("omp declare target link", DECL_ATTRIBUTES (decl)))
+	{
+	  error_at (loc,
+		"%qE with % clause used in % function",
+		DECL_NAME (decl));
+	  return GS_ERROR;
+	}
+  else if (!lookup_attribute ("omp declare target", DECL_ATTRIBUTES (decl)))
+	{
+	  error_at (loc,
+		"storage class of %qE cannot be ", DECL_NAME (decl));
+	  error_at (gimplify_omp_ctxp->location,
+		"used in enclosing % function");
+	  return GS_ERROR;
+	}
+}
+
   /* When within an OMP context, notice uses of variables.  */
   if (gimplify_omp_ctxp && omp_notice_variable (gimplify_omp_ctxp, decl, true))
 return GS_ALL_DONE;
Index: gcc/testsuite/ChangeLog
===
diff --git a/trunk/gcc/testsuite/ChangeLog b/trunk/gcc/testsuite/ChangeLog
--- a/trunk/gcc/testsuite/ChangeLog	(revision 232802)
+++ b/trunk/gcc/testsuite/ChangeLog	(working copy)
@@ -1,3 +1,7 @@
+2016-01-XX  James Norris  
+
+	* c-c++-common/goacc/routine-5.c: Add tests.
+
 2016-01-25  Jeff Law  
 
 	PR tree-optimization/69196
Index: gcc/testsuite/c-c++-common/goacc/routine-5.c
===
diff --git a/trunk/gcc/testsuite/c-c++-common/goacc/routine-5.c b/trunk/gcc/testsuite/c-c++-common/goacc/routine-5.c
--- a/trunk/gcc/testsuite/c-c++-common/goacc/routine-5.c	(revision 232802)
+++ b/trunk/gcc/testsuite/c-c++-common/goacc/routine-5.c	(working copy)
@@ -45,3 +45,70 @@
 #pragma acc routine (a) /* { dg-error "does not refer to" } */
   
 #pragma acc routine (c) /* { dg-error "does not refer to" } */
+
+float vb1; /* { dg-error "storage class of" } */
+
+#pragma acc routine
+int
+func1 (int a)		/* { dg-error "used in enclosing" } */
+{
+  vb1 = a + 1;
+
+  return vb1;
+}
+
+#pragma acc routine
+int
+func2 (int a)		/* { dg-error "used in enclosing" } */
+{
+  static int vb2;	/* { dg-error "storage class of" } */
+
+  vb2 = a + 1;
+
+  return vb2;
+}
+
+float vb3;		/* { dg-error "'link' clause used" } */
+#pragma acc declare link (vb3)
+
+#pragma acc routine
+int
+func3 (int a)
+{
+  vb3 = a + 1;
+
+  return vb3;
+}
+
+float vb4;
+#pragma acc declare create (vb4)
+
+#pragma acc routine
+int
+func4 (int a)
+{
+  vb4 = a + 1;
+
+  return vb4;
+}
+
+extern float vb5;	/* { dg-error "storage class of" } */
+
+#pragma acc routine
+int
+func5 (int a)		/* { dg-error "used in enclosing" } */
+{
+  vb5 = a + 1;
+
+  return vb5;
+}
+
+#pragma acc routine
+int
+func6 (int a)		/* { dg-error "used in enclosing" } */
+{
+  extern float vb6;	/* { dg-error "storage class of" } */
+  vb6 = a + 1;
+
+  return vb6;
+}

Re: [PATCH] libcpp: use better locations for _Pragma tokens (preprocessor/69126)

[Steve Ellcey]

David,

This patch has broken the top-of-tree glibc build.  I get an error on an
undef that is supposed to be protected by Pragmas.  It happens when
compiling intl/plural.c in glibc.  I created a preprocessed source file
but when I compile it, the error doesn't happen.  I will try to create a
small unpreprocessed standalone test case but maybe this is enough for
you to know what is happening.

If I look at the preprocessed code, the statement in question is
under ingore warning pragmas.

#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wuninitialized"
#pragma GCC diagnostic ignored "-Wmaybe-uninitialized"
  *++yyvsp = __gettextlval;
#pragma GCC diagnostic pop


Steve Ellcey
sell...@imgtec.com

plural.c: In function '__gettextparse':
plural.c:1767:12: error: '__gettextlval.num' may be used uninitialized
in this function [-Werror=maybe-uninitialized]
   *++yyvsp = yylval;
 
plural.c:66:25: note: '__gettextlval.num' was declared here
 #define yylval  __gettextlval
 ^
plural.c:1265:9: note: in expansion of macro 'yylval'
 YYSTYPE yylval YY_INITIAL_VALUE(yyval_default);
 ^~
cc1: all warnings being treated as errors

Re: [C/C++ PATCH] Don't emit invalid VEC_COND_EXPR for vector comparisons (PR c/68062)

[Marek Polacek]

On Thu, Jan 28, 2016 at 04:47:04AM -0800, H.J. Lu wrote:
> I got
> 
> FAIL: c-c++-common/vector-compare-4.c  -Wc++-compat   (test for
> warnings, line 17)
> FAIL: c-c++-common/vector-compare-4.c  -Wc++-compat   (test for
> warnings, line 18)
> FAIL: c-c++-common/vector-compare-4.c  -Wc++-compat   (test for
> warnings, line 34)
> FAIL: c-c++-common/vector-compare-4.c  -Wc++-compat   (test for
> warnings, line 35)

Ah, patch(1) bogosity, fixed now.  Sorry about that.

Marek

[PATCH] target/68972 - g++.dg/cpp1y/vla-initlist1.C test case fails on powerpc64le

[Martin Sebor]

The g++.dg/cpp1y/vla-initlist1.C test relies on undefined behavior
(reading an uninitialized array element) to verify that two VLAs
are allocated in memory starting at the same address.  The test
has been seen to fail on powerpc64-*-linux-gnu and spu-*-elf.
The attached patch removes the undefined behavior while still
verifying the same thing.  It passes on powerpc64le.

Jason, based on your comment in the bug I've removed the part
of the test that verifies that the no-op initializer-list ctor
for the user-defined VLA leaves the array elements uninitialized.
If that's something that should be tested let me know and I'll
add another test or test case for that.

Martin
2016-01-28  Martin Sebor  

	target/68972
	* g++.dg/cpp1y/vla-initlist1.C: Prevent test failure on powepc64le
	by making the test less undefined.

diff --git a/gcc/testsuite/g++.dg/cpp1y/vla-initlist1.C b/gcc/testsuite/g++.dg/cpp1y/vla-initlist1.C
index 8f5709d..339aacc 100644
--- a/gcc/testsuite/g++.dg/cpp1y/vla-initlist1.C
+++ b/gcc/testsuite/g++.dg/cpp1y/vla-initlist1.C
@@ -12,12 +12,21 @@ struct A
 };
 
 int x = 4;
-int main(int argc, char **argv)
+int main(int argc, char **)
 {
-  { int i[x] = { 42, 42, 42, 42 }; }
+  typedef __UINTPTR_TYPE__ uintptr_t;
+  uintptr_t vla1_addr, vla2_addr;
+
+  // Verify that both arrays are allocated at the same address.
+  {
+int vla1[x] = { 42, 42, 42, 42 };
+vla1_addr = reinterpret_cast(vla1);
+  }
   {
-A a[x] = { argc };
-if (a[1].i != 42)
+A vla2[x] = { argc };
+vla2_addr = reinterpret_cast(vla2);
+
+if (vla1_addr != vla2_addr)
   __builtin_abort ();
   }
 }

Re: [PATCH] libcpp: use better locations for _Pragma tokens (preprocessor/69126)

[David Malcolm]

On Thu, 2016-01-28 at 11:12 -0800, Steve Ellcey wrote:
> David,
> 
> This patch has broken the top-of-tree glibc build

Bother; sorry.  FWIW, I'm about to get on a plane (for FOSDEM), so I'm
not in a great position to tackle this yet.

> I get an error on an
> undef that is supposed to be protected by Pragmas.  It happens when
> compiling intl/plural.c in glibc.  I created a preprocessed source
> file
> but when I compile it, the error doesn't happen.

PR preprocessor/69126 was all about the location of where _Pragma
macros expand to, so it would make sense that you might see different
behaviors with -save-temps.

> I will try to create a
> small unpreprocessed standalone test case but maybe this is enough
> for
> you to know what is happening.
> 
> If I look at the preprocessed code, the statement in question is
> under ingore warning pragmas.
> 
> #pragma GCC diagnostic push
> #pragma GCC diagnostic ignored "-Wuninitialized"
> #pragma GCC diagnostic ignored "-Wmaybe-uninitialized"
>   *++yyvsp = __gettextlval;
> #pragma GCC diagnostic pop
> 
> 
> Steve Ellcey
> sell...@imgtec.com
> 
> plural.c: In function '__gettextparse':
> plural.c:1767:12: error: '__gettextlval.num' may be used
> uninitialized
> in this function [-Werror=maybe-uninitialized]
>*++yyvsp = yylval;
>  
> plural.c:66:25: note: '__gettextlval.num' was declared here
>  #define yylval  __gettextlval
>  ^
> plural.c:1265:9: note: in expansion of macro 'yylval'
>  YYSTYPE yylval YY_INITIAL_VALUE(yyval_default);
>  ^~
> cc1: all warnings being treated as errors

Code in question appears to be here:
https://sourceware.org/git/?p=glibc.git;a=blob;f=intl/plural.c;h=a94af3
c542b1aeadebbe02d67dabd2d535f70726;hb=HEAD#l1767

1766   YY_IGNORE_MAYBE_UNINITIALIZED_BEGIN
1767   *++yyvsp = yylval;
1768   YY_IGNORE_MAYBE_UNINITIALIZED_END

Macro itself is defined at line 1244:

1244 # define YY_IGNORE_MAYBE_UNINITIALIZED_BEGIN \
1245 _Pragma ("GCC diagnostic push") \
1246 _Pragma ("GCC diagnostic ignored \"-Wuninitialized\"")\
1247 _Pragma ("GCC diagnostic ignored \"-Wmaybe-uninitialized\"")
1248 # define YY_IGNORE_MAYBE_UNINITIALIZED_END \
1249 _Pragma ("GCC diagnostic pop")

Maybe there's an issue with having a _Pragma inside another macro; my
hunch would be that my patch is making it use the location of the
_Pragma within the *definition* of the
YY_IGNORE_MAYBE_UNINITIALIZED_BEGIN/END macros, rather than their
expansion.  But that's just a hunch at this stage.

I think I have a minimal reproducer:

$ cat /tmp/test.c
# define YY_IGNORE_MAYBE_UNINITIALIZED_BEGIN \
_Pragma ("GCC diagnostic push") \
_Pragma ("GCC diagnostic ignored \"-Wuninitialized\"")\
_Pragma ("GCC diagnostic ignored \"-Wmaybe-uninitialized\"")
# define YY_IGNORE_MAYBE_UNINITIALIZED_END \
_Pragma ("GCC diagnostic pop")

void test (char yylval)
{
  char *yyvsp;
  YY_IGNORE_MAYBE_UNINITIALIZED_BEGIN
  *++yyvsp = yylval;
  YY_IGNORE_MAYBE_UNINITIALIZED_END
}

$ ./xgcc -B. -c /tmp/test.c -Wall
/tmp/test.c: In function ‘test’:
/tmp/test.c:12:12: warning: ‘yyvsp’ is used uninitialized in this
function [-Wuninitialized]
   *++yyvsp = yylval;
   ~^~~~

$ ./xgcc -B. -c /tmp/test.c -save-temps
$ ./xgcc -B. -c test.i -Wall
(compiles with no warnings)

[google gcc-4_9]: Backport trunk:r232727 fix for PR/69403.

[Han Shen]

Backport trunk:r232727 fix for PR/69403 - wrong
thumb2_ior_scc_strict_it insn pattern.

Note this only affect armv7-a tuned for armv8 arch, tested / booted
affected ChromeOS book.

Ok for google/gcc-4_9 branch?

-- 
Han Shen
Index: gcc/ChangeLog
===
--- gcc/ChangeLog	(revision 232940)
+++ gcc/ChangeLog	(working copy)
@@ -1,3 +1,10 @@
+2016-01-22  Kyrylo Tkachov  
+
+	PR target/69403
+	* config/arm/thumb2.md (*thumb2_ior_scc_strict_it): Convert to
+	define_insn_and_split.  Ensure operands[1] and operands[0] do not
+	get assigned the same register.
+
 2015-03-26  Bill Schmidt  
 
 	Backport of r214242, r214254, and bug fix patches from mainline
Index: gcc/config/arm/thumb2.md
===
--- gcc/config/arm/thumb2.md	(revision 232940)
+++ gcc/config/arm/thumb2.md	(working copy)
@@ -642,15 +642,27 @@
(set_attr "type" "multiple")]
 )
 
-(define_insn "*thumb2_ior_scc_strict_it"
-  [(set (match_operand:SI 0 "s_register_operand" "=l,l")
+(define_insn_and_split "*thumb2_ior_scc_strict_it"
+  [(set (match_operand:SI 0 "s_register_operand" "=&r")
 	(ior:SI (match_operator:SI 2 "arm_comparison_operator"
 		 [(match_operand 3 "cc_register" "") (const_int 0)])
-		(match_operand:SI 1 "s_register_operand" "0,?l")))]
+		(match_operand:SI 1 "s_register_operand" "r")))]
   "TARGET_THUMB2 && arm_restrict_it"
-  "@
-   it\\t%d2\;mov%d2\\t%0, #1\;it\\t%d2\;orr%d2\\t%0, %1
-   mov\\t%0, #1\;orr\\t%0, %1\;it\\t%D2\;mov%D2\\t%0, %1"
+  "#" ; orr\\t%0, %1, #1\;it\\t%D2\;mov%D2\\t%0, %1
+  "&& reload_completed"
+  [(set (match_dup 0) (ior:SI (match_dup 1) (const_int 1)))
+   (cond_exec (match_dup 4)
+ (set (match_dup 0) (match_dup 1)))]
+  {
+machine_mode mode = GET_MODE (operands[3]);
+rtx_code rc = GET_CODE (operands[2]);
+
+if (mode == CCFPmode || mode == CCFPEmode)
+  rc = reverse_condition_maybe_unordered (rc);
+else
+  rc = reverse_condition (rc);
+operands[4] = gen_rtx_fmt_ee (rc, VOIDmode, operands[3], const0_rtx);
+  }
   [(set_attr "conds" "use")
(set_attr "length" "8")
(set_attr "type" "multiple")]
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog	(revision 232940)
+++ gcc/testsuite/ChangeLog	(working copy)
@@ -1,3 +1,8 @@
+2016-01-22  Kyrylo Tkachov  
+
+	PR target/69403
+	* gcc.c-torture/execute/pr69403.c: New test.
+
 2015-03-26  Bill Schmidt  
 
 	Backport r214254 and related tests from mainline
Index: .
===
--- .	(revision 232940)
+++ .	(working copy)

Property changes on: .
___
Modified: svn:mergeinfo
   Merged /trunk:r232727

Re: [PATCH] libcpp: use better locations for _Pragma tokens (preprocessor/69126)

[David Malcolm]

On Thu, 2016-01-28 at 14:48 -0500, David Malcolm wrote:
> On Thu, 2016-01-28 at 11:12 -0800, Steve Ellcey wrote:
> > David,
> > 
> > This patch has broken the top-of-tree glibc build
> 
> Bother; sorry.  FWIW, I'm about to get on a plane (for FOSDEM), so
> I'm
> not in a great position to tackle this yet.

[...]

I've filed PR preprocessor/69543 to cover this regression:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69543

Should the patches be reverted in the meantime?(r232893 and r232928)

[C++ PATCH] Fix -Wunused-function (PR debug/66869)

[Jakub Jelinek]

On Wed, Jan 27, 2016 at 12:28:58PM -0700, Jeff Law wrote:
> On 01/27/2016 11:51 AM, Jakub Jelinek wrote:
> >2016-01-25  Jakub Jelinek  
> >
> > PR debug/66869
> > * c-decl.c (c_write_global_declarations_1): Warn with
> > warn_unused_function if static prototype without definition
> > is not C_DECL_USED.
> >
> > * gcc.dg/pr66869.c: New test.

And here is corresponding C++ FE patch.  Bootstrapped/regtested on
x86_64-linux and i686-linux, ok for trunk?

2016-01-28  Jakub Jelinek  

PR debug/66869
* decl.c (wrapup_globals_for_namespace): Warn about unused static
function declarations.

* g++.dg/warn/Wunused-function2.C: New test.

--- gcc/cp/decl.c.jj2016-01-25 09:31:01.0 +0100
+++ gcc/cp/decl.c   2016-01-28 13:14:10.783286136 +0100
@@ -879,6 +879,24 @@ wrapup_globals_for_namespace (tree name_
   tree *vec = statics->address ();
   int len = statics->length ();
 
+  if (warn_unused_function)
+{
+  tree decl;
+  unsigned int i;
+  FOR_EACH_VEC_SAFE_ELT (statics, i, decl)
+   if (TREE_CODE (decl) == FUNCTION_DECL
+   && DECL_INITIAL (decl) == 0
+   && DECL_EXTERNAL (decl)
+   && !TREE_PUBLIC (decl)
+   && !DECL_ARTIFICIAL (decl)
+   && !TREE_NO_WARNING (decl))
+ {
+   warning (OPT_Wunused_function,
+"%q+F declared % but never defined", decl);
+   TREE_NO_WARNING (decl) = 1;
+ }
+}
+
   /* Write out any globals that need to be output.  */
   return wrapup_global_declarations (vec, len);
 }
--- gcc/testsuite/g++.dg/warn/Wunused-function2.C.jj2016-01-28 
13:40:10.201053364 +0100
+++ gcc/testsuite/g++.dg/warn/Wunused-function2.C   2016-01-28 
13:41:43.006788487 +0100
@@ -0,0 +1,6 @@
+// PR debug/66869
+// { dg-do compile }
+// { dg-options "-Wunused-function" }
+
+static void test (void); // { dg-warning "'void test..' declared 'static' but 
never defined" }
+int i;


Jakub

[PATCH] Fix bootstrap on i686 (PR middle-end/69542)

[Jakub Jelinek]

Hi!

The recent lra-remat.c change broke bootstrap for me on i686,
with comparison failure on simplify-rtx.o.
Below is a reduced testcase.  debug insns really should not affect
remat decisions, before the recent changes set_bb_regs should be always a
nop on debug insns (they don't change any registers, and don't have REG_DEAD
notes).  But they could have subregs of multiword regs.

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

2016-01-28  Jakub Jelinek  

PR middle-end/69542
* lra-remat.c (calculate_local_reg_remat_bb_data): Only consider
non-debug insns.

* gcc.dg/torture/pr69542.c: New test.

--- gcc/lra-remat.c.jj  2016-01-28 15:07:24.0 +0100
+++ gcc/lra-remat.c 2016-01-28 18:24:43.778297120 +0100
@@ -694,7 +694,7 @@ calculate_local_reg_remat_bb_data (void)
 
   FOR_EACH_BB_FN (bb, cfun)
 FOR_BB_INSNS (bb, insn)
-  if (INSN_P (insn))
+  if (NONDEBUG_INSN_P (insn))
set_bb_regs (bb, insn);
 }
 
--- gcc/testsuite/gcc.dg/torture/pr69542.c.jj   2016-01-28 18:54:49.477968076 
+0100
+++ gcc/testsuite/gcc.dg/torture/pr69542.c  2016-01-28 18:55:16.786599654 
+0100
@@ -0,0 +1,37 @@
+/* PR middle-end/69542 */
+/* { dg-do compile } */
+/* { dg-additional-options "-fcompare-debug" } */
+
+typedef struct A *B;
+extern int *a[];
+struct C { B b; struct D *d; };
+struct A { struct { struct C e[1]; long long f[1]; } u; };
+struct D { int g; B h[100]; };
+int b, c, e, g;
+B d, f;
+void foo (void) __attribute__ ((__noreturn__));
+int bar (void)
+{
+  int i = 0;
+  do
+{
+  if ('E' && a[e][0] != 'V')
+foo ();
+  struct D *k = d->u.e[0].d;
+  B x = k->h[i], o = f->u.e[0].b;
+  if (b)
+return 0;
+  if (a[g][0] != 'E' && a[g][0] != 'V')
+foo ();
+  struct D *n = o->u.e[0].d;
+  int r = x->u.f[0];
+  (void) r;
+  if (c)
+foo ();
+  B y = n->h[x->u.f[0]];
+  if (i != y->u.f[0])
+return 0;
+  i++;
+}
+  while (1);
+}


Jakub

[PATCH] New flag for dumping information about constexpr function calls memoization (GCC 5.2.0)

[Andres Tiraboschi]

Hi,

This patch adds a flag (-fdump-memoization-hits) in order to dump
information about wich constexpr functions calls are memoized.
This is patch is for gcc-5.2.0.
If OK, please commit it for me since I don't have write access.

patch:

diff --git a/gcc/common.opt b/gcc/common.opt
index 1218a71..bf0c7df 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -1168,6 +1168,10 @@ fdump-passes
 Common Var(flag_dump_passes) Init(0)
 Dump optimization passes

+fdump-memoization-hits
+Common Var(flag_dump_memoization_hits) Init(0)
+Dump info about constexpr calls memoized.
+
 fdump-unnumbered
 Common Report Var(flag_dump_unnumbered)
 Suppress output of instruction numbers, line number notes and
addresses in debugging dumps
diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index e250726..41ae5b3 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -42,6 +42,8 @@ along with GCC; see the file COPYING3.  If not see
 #include "builtins.h"
 #include "tree-inline.h"
 #include "ubsan.h"
+#include "tree-pretty-print.h"
+#include "dumpfile.h"

 static bool verify_constant (tree, bool, bool *, bool *);
 #define VERIFY_CONSTANT(X)\
@@ -1173,6 +1175,14 @@ cx_error_context (void)
   return r;
 }

+static void
+dump_memoization_hit (FILE *file, tree call, int flags)
+{
+  fprintf(file, "Memoized call:\n");
+  print_generic_decl(file, call, flags);
+  fprintf(file, "\n");
+}
+
 /* Subroutine of cxx_eval_constant_expression.
Evaluate the call expression tree T in the context of OLD_CALL expression
evaluation.  */
@@ -1338,7 +1348,11 @@ cxx_eval_call_expression (const constexpr_ctx
*ctx, tree t,
   entry->result = result = error_mark_node;
 }
   else
-result = entry->result;
+{
+  if (flag_dump_memoization_hits)
+  dump_memoization_hit(stderr, t, 0);
+  result = entry->result;
+}
 }

   if (!depth_ok)

C++ PATCH for c++/69509 and c++/69516 (infinite recursion with invalid VLAs in constexpr functions)

[Marek Polacek]

This patch fixes some problems with VLAs and constexprs.  (The runtime aspect
of this matter is being tracked in PR69517.)  It does two things:

1) Changes build_vec_init slightly to prevent the compiler from getting into
   infinite recursion.  Currently, we emit the following sequence when we're
   initializing e.g. n = 1; int a[n] = { 1, 2 }; (cleanup_point junk omitted):

  int a[0:(sizetype) (SAVE_EXPR <(ssizetype) n + -1>)];
  (void) (int[0:(sizetype) (SAVE_EXPR <(ssizetype) n + -1>)] *)   int * D.2256;
  (void) (D.2256 = (int *) &a)
int * D.2257;
  (void) (D.2257 = D.2256)
long int D.2258;
  (void) (D.2258 = (long int) (SAVE_EXPR <(ssizetype) n + -1>)) // == 0
  (void) (*D.2257 = 1)
  (void)  ++D.2257 
  (void)  --D.2258  // == -1
  (void) (*D.2257 = 2)
  (void)  ++D.2257
  (void)  --D.2258  // == -2

  while (1) 
{   
  if (D.2258 == -1) // never triggers
goto ;
  (void) (*D.2257 = 0) 
  (void)  ++D.2257
  (void)  --D.2258;
}   
  :;
  ...

  So we first write the elements from the initializer and then we 
default-initialize
  any remaining elements.  But the iterator == -1 check is never true for 
invalid
  code, which means the compiler will get stuck in the while loop forever, 
leading
  to crash -- it tries to cxx_eval_* the body of the loop over and over again.

  Fixed by changing == -1 into <= -1; this should only ever happen for invalid 
code,
  but we don't want to ICE in any case.

  This also "fixes" the problem in PR69517 -- the program could get into 
infinite
  recursion as well, because it was evaluating the sequence above at runtime. 
But
  since it's invoking UB, it doesn't matter much.

2) Moves the check for "array subscript out of bound" a tad above, because for
   invalid VLAs we can't rely on the bool "found" -- e.g. for the example above
   it will find all indexes in the initializer, so "found" is true, which means
   we wouldn't get to the out-of-bounds check below.

Hopefully I'm making sense.  

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

2016-01-28  Marek Polacek  

PR c++/69509
PR c++/69516
* constexpr.c (cxx_eval_array_reference): Give the "array subscript
out of bound" error earlier.
* init.c (build_vec_init): Change NE_EXPR into GT_EXPR.  Update the
commentary.

* g++.dg/ext/constexpr-vla2.C: New test.
* g++.dg/ext/constexpr-vla3.C: New test.
* g++.dg/ubsan/vla-1.C: Remove dg-shouldfail.

diff --git gcc/cp/constexpr.c gcc/cp/constexpr.c
index 57595a4..b076991 100644
--- gcc/cp/constexpr.c
+++ gcc/cp/constexpr.c
@@ -1833,6 +1833,19 @@ cxx_eval_array_reference (const constexpr_ctx *ctx, tree 
t,
   return t;
 }
 
+  tree nelts = array_type_nelts_top (TREE_TYPE (ary));
+  /* For VLAs, the number of elements won't be an integer constant.  */
+  nelts = cxx_eval_constant_expression (ctx, nelts, false, non_constant_p,
+   overflow_p);
+  VERIFY_CONSTANT (nelts);
+  if (!tree_int_cst_lt (index, nelts))
+{
+  if (!ctx->quiet)
+   error ("array subscript out of bound");
+  *non_constant_p = true;
+  return t;
+}
+
   bool found;
   if (TREE_CODE (ary) == CONSTRUCTOR)
 {
@@ -1846,37 +1859,23 @@ cxx_eval_array_reference (const constexpr_ctx *ctx, 
tree t,
 
   if (!found)
 {
-  tree nelts = array_type_nelts_top (TREE_TYPE (ary));
-  /* For VLAs, the number of elements won't be an integer constant.  */
-  nelts = cxx_eval_constant_expression (ctx, nelts, false, non_constant_p,
-   overflow_p);
-  VERIFY_CONSTANT (nelts);
-  if (tree_int_cst_lt (index, nelts))
+  if (TREE_CODE (ary) == CONSTRUCTOR
+ && CONSTRUCTOR_NO_IMPLICIT_ZERO (ary))
{
- if (TREE_CODE (ary) == CONSTRUCTOR
- && CONSTRUCTOR_NO_IMPLICIT_ZERO (ary))
-   {
- /* 'ary' is part of the aggregate initializer we're currently
-building; if there's no initializer for this element yet,
-that's an error. */
- if (!ctx->quiet)
-   error ("accessing uninitialized array element");
- *non_constant_p = true;
- return t;
-   }
-
- /* If it's within the array bounds but doesn't have an explicit
-initializer, it's value-initialized.  */
- tree val = build_value_init (elem_type, tf_warning_or_error);
- return cxx_eval_constant_expression (ctx, val,
-  lval,
-  non_constant_p, overflow_p);
+ /* 'ary' is part of the aggregate initializer we're currently
+building; if there's no initializer for this element yet,
+that's an error.  */
+ if (!ctx->quiet)
+   error ("accessing uninitialized array element");
+ *non_constant_p = true;
+ return t;
  

Re: [PATCH] New flag for dumping information about constexpr function calls memoization (GCC 5.2.0)

[Joseph Myers]

Any patch adding a new option needs to add documentation for it to 
invoke.texi (both substantive documentation, and inclusion in the summary 
lists of options).

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

Re: [PATCH] Fix bootstrap on i686 (PR middle-end/69542)

[Richard Henderson]

On 01/28/2016 12:17 PM, Jakub Jelinek wrote:
> The recent lra-remat.c change broke bootstrap for me on i686,
> with comparison failure on simplify-rtx.o.
> Below is a reduced testcase.  debug insns really should not affect
> remat decisions, before the recent changes set_bb_regs should be always a
> nop on debug insns (they don't change any registers, and don't have REG_DEAD
> notes).  But they could have subregs of multiword regs.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 
> 2016-01-28  Jakub Jelinek  
> 
>   PR middle-end/69542
>   * lra-remat.c (calculate_local_reg_remat_bb_data): Only consider
>   non-debug insns.
> 
>   * gcc.dg/torture/pr69542.c: New test.

Looks good to me.  Thanks.

Can you please apply to gcc-5-branch too, since I've
already applied the 69449 patch there.


r~

Re: [PATCH 1/3] [graphite] assert instead of silently failing code gen

[H.J. Lu]

On Thu, Jan 28, 2016 at 8:24 AM, Sebastian Pop  wrote:
> * graphite-isl-ast-to-gimple.c (get_rename_from_scev): Assert instead 
> of
> setting codegen_error to fail codegen.

This may have caused:

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


-- 
H.J.

Re: [PATCH] libcpp: use better locations for _Pragma tokens (preprocessor/69126)

[Steve Ellcey]

On Thu, 2016-01-28 at 14:59 -0500, David Malcolm wrote:
> On Thu, 2016-01-28 at 14:48 -0500, David Malcolm wrote:
> > On Thu, 2016-01-28 at 11:12 -0800, Steve Ellcey wrote:
> > > David,
> > > 
> > > This patch has broken the top-of-tree glibc build
> > 
> > Bother; sorry.  FWIW, I'm about to get on a plane (for FOSDEM), so
> > I'm
> > not in a great position to tackle this yet.
> 
> [...]
> 
> I've filed PR preprocessor/69543 to cover this regression:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69543
> 
> Should the patches be reverted in the meantime?(r232893 and r232928)

I can live with the problem for a few days, so guess it depends on when
you think you will have time to look at it more.

Steve Ellcey

Re: [PATCH] Fix PCH on systems where stdc-predef.h includes other headers (PR pch/68176)

[Marek Polacek]

On Thu, Jan 28, 2016 at 03:32:39PM +0100, Jakub Jelinek wrote:
> Hi!
> 
> As mentioned in the PR, most of the pch tests fail if stdc-predef.h header
> includes other headers.  I don't have such a system, but changed my
> stdc-predef.h to include a dummy header bits/predef.h and this patch fixes
> all the tests that failed because of that.
> AFAIK file->implicit_preinclude flag is used solely for the PCH purposes,
> and this patch makes sure that headers included from implicit_preinclude
> headers are also implicit_preinclude.
> 
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
> 
> 2016-01-28  Jakub Jelinek  
> 
>   PR pch/68176
>   * files.c (_cpp_find_file): Set file->implicit_preinclude even if
>   included from file->implicit_preinclude header.

Ok.

Marek

Re: Is it OK for rtx_addr_can_trap_p_1 to attempt to compute the frame layout? (was Re: [PATCH] Skip re-computing the mips frame info after reload completed)

[Richard Sandiford]

Bernd Edlinger  writes:
> On 26.01.2016 22:18, Richard Sandiford wrote:
>> [cc-ing Eric as RTL maintainer]
>>
>> Matthew Fortune  writes:
>>> Bernd Edlinger  writes:
 Matthew Fortune  writes:
> Has the patch been tested beyond just building GCC? I can do a
> test run for you if you don't have things set up to do one yourself.

 I built a cross-gcc with all languages and a cross-glibc, but I have
 not set up an emulation environment, so if you could give it a test
 that would be highly welcome.
>>>
>>> mipsel-linux-gnu test results are the same before and after this patch.
>>>
>>> Please go ahead and commit.
>>
>> I still object to this.  And it feels like the patch was posted
>> as though it was a new one in order to avoid answering the objections
>> that were raised when it was last posted:
>>
>>https://gcc.gnu.org/ml/gcc-patches/2015-12/msg02218.html
>>
>
> Richard, I am really sorry when you feel now like I did not take your
> objections seriously.  Let me first explain what happened from my point
> of view:
>
> When I posted this response to your objections here:
>
>   https://gcc.gnu.org/ml/gcc-patches/2016-01/msg00235.html
>
> I was waiting for your response, but nothing happened, so I kind of
> forgot about the issue.  In the meantime Ubuntu and Debian began to
> roll out GCC-6 and they got stuck at the same issue, but instead of
> waiting for pr69012 to be eventually resolved they created a duplicate
> pr69129, and then last Thursday Nick applied my initial patch without
> my intervention, probably because of the pressure they put on us.

Ah, I'd missed that, sorry.  It's not obvious from the email thread
that the patch was actually approved.  I just see a message from Matthias
saying that it worked for him and then a message from Nick saying that
he'd applied it.

Ah well.  I guess at some point I have to get over the fact that I'm no
longer the MIPS maintainer :-)

> That changed significantly how I looked at the issue after that point,
> as there was no actual regression anymore, the revised patch still made
> sense, but for another reason.  When you look at the 20+ targets in the
> gcc tree you'll see that almost all of them have a frame-layout
> computation function and all except mips have a shortcut
> "if (reload_completed) return;" in that function.  And OTOH mips has
> one of the most complicated frame layout functions of all targets.
>
> For all of these reasons I posted a new patch which tries to resolve
> differences between mips and other targets inital_elimination_offset
> functions.

OK.  But the point still stands that the patch is only useful because
we're now calling mips_compute_frame_info in cases where we wouldn't
previously, because of the rtx_addr_can_trap_p changes.

> I still think that it is not OK for the mips target to do the frame
> layout already in mips_frame_pointer_required because the frame layout
> will change several times, until reload is completed, and that function
> is only called right in the beginning.

I don't think it's any better or worse than doing the frame layout in
INITIAL_ELIMINATION_OFFSET (which is common practice and pretty much
required).  They're both part of the initial setup phase --
targetm.frame_layout_required determines frame_pointer_needed, which is
a vital input to the code that decides which eliminations to make.

And this is an example of us doing the kind of caching that I was
suggesting.  Code that wants to know whether the frame pointer is needed
for the current function should use frame_pointer_needed.  Only the code
that sets up frame_pointer_needed should call frame_pointer_required
directly. 

> And I think that it is not really well-designed to have a frame layout
> function F(x,y)->z unless you assume F to be a trivial O(1) function
> that has no significant computation overhead.  When you assume F to be
> an expensive O(N) or higher complexity you would design the interface
> like compute_frame_layout_now() and
> get_cached_initial_elimination_offset(x,y)->z.
>
> Also note, that with the current design, of initial_elimination_offset
> the frame layout is already computed several times, because reload has
> to call the function with different parameters, and there is no way how
> to know when the cached value can be used and when not.

Agreed -- the current interface is pretty poor.  But that's even more
reason not to add uses of it after LRA/reload.  Caching would be both
simpler and more efficient.

> I do also think that having to cache the initial elimination offset
> values in the back-end that are already cached in the target does not
> improve anything.  Then I would prefer to have a set of new target
> callbacks that makes it easy to access the cached target values.

I don't agree.  Asking each backend to cache a particular value in
its frame_info structure and then providing a hook to query that
cached value means adding code to every target.  And calling an
indirect function is going 

Re: C++ PATCH for c++/69496 (ICE on VLA in constexpr function)

[Marek Polacek]

On Wed, Jan 27, 2016 at 09:52:13AM -0700, Martin Sebor wrote:
> This happens to work but I suspect it's only by accident.  When
> the number of elements in the initializer is increased to exceed
> the number of elements in the VLA GCC gets into infinite recursion.
> (I opened bug 69516 with a test case).  The same error in a non-
> constexpr function causes a SEGV at runtime (this is also
> a regression WRT 4.9.3 -- I opened bug 69517 for it).

FWIW, the patch I posted today should cure all those infinite recursions.

Marek

[PATCH, rs6000] Fix PR65546

[Bill Schmidt]

Hi,

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65546 identifies a failure
in gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c.  The test case hasn't
kept up with changes in the vectorizer, so it's looking for the wrong
error message.  Also, the error message should be conditioned by a check
for support of unaligned memory accesses.  This patch corrects these
problems.

For 4.9 and 5, the error message needs to be similarly changed.
However, for these earlier releases, the check for misalignment support
doesn't apply.

Verified on powerpc64le-unknown-linux-gnu for both -mcpu=power7 and
-mcpu=power8, which differ in their support for misalignment.  Is this
ok for trunk?  Provided verification succeeds on 4.9 and 5, is the
revised test ok for those releases?

Thanks,
Bill


2016-01-28  Bill Schmidt  

PR target/65546
* gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c: Correct
condition being checked, and disable it when the target supports
misaligned loads and stores.


Index: gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c
===
--- gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c
(revision 232890)
+++ gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c
(working copy)
@@ -46,5 +46,5 @@ int main (void)
   return main1 ();
 } 
 
-/* { dg-final { scan-tree-dump-times "vectorization not profitable" 1 "vect" } 
} */
+/* { dg-final { scan-tree-dump-times "not vectorized: unsupported unaligned 
store" 1 "vect" { target { ! vect_hw_misalign } } } } */
 /* { dg-final { scan-tree-dump-times "vectorized 1 loops" 0 "vect" { target { 
! vect_hw_misalign } } } } */

[PATCH, i386]: Fix PR69549, wrong code with -O2 and vector arithmetics @ x86_64

[Uros Bizjak]

Hello!

Attached patch corrects "C" constraint to accept only SSE constant
zero operand and introduces new "BC" constraint to accept all SSE
constant operands (all bits 0 and all bits 1).

As discussed in the PR, the compiler ICEs when "C" constraint is used
non-zero vector operands, so it is still possible to change the
constraint a bit. With fixed constraint, we get "impossible
constraint" error instead of ICEing when following testcase:

--cut here--
typedef int __v4si __attribute__ ((__vector_size__ (16)));

void test (void)
{
  asm volatile ("%0" : : "C" ( (__v4si) { -1, -1, -1, -1 } ));
}
--cut here--

is compiled with -O2 -msse2.

2016-01-28  Uros Bizjak  

PR target/69459
* config/i386/constraints.md (C): Only accept constant zero operand.
(BC): New constraint.
* config/i386/sse.md (*mov_internal): Use BC constraint
instead of C constraint.
* doc/md.texi (Machine Constraints): Update description
of C constraint.

testsuite/ChangeLog:

2016-01-28  Uros Bizjak  

PR target/69459
* gcc.target/i386/pr69459.c: New test.

Patch was bootstrapped and regression tested on x86_64-linux-gnu
{,-m32}. Patch was committed to mainline SVN and will be backported to
release branches.

Uros.
Index: config/i386/constraints.md
===
--- config/i386/constraints.md  (revision 232929)
+++ config/i386/constraints.md  (working copy)
@@ -152,6 +152,7 @@
 ;;  s  Sibcall memory operand, not valid for TARGET_X32
 ;;  w  Call memory operand, not valid for TARGET_X32
 ;;  z  Constant call address operand.
+;;  C  SSE constant operand.
 
 (define_constraint "Bf"
   "@internal Flags register operand."
@@ -183,6 +184,10 @@
   "@internal Constant call address operand."
   (match_operand 0 "constant_call_address_operand"))
 
+(define_constraint "BC"
+  "@internal SSE constant operand."
+  (match_test "standard_sse_constant_p (op)"))
+
 ;; Integer constant constraints.
 (define_constraint "I"
   "Integer constant in the range 0 @dots{} 31, for 32-bit shifts."
@@ -233,8 +238,8 @@
 
 ;; This can theoretically be any mode's CONST0_RTX.
 (define_constraint "C"
-  "Standard SSE floating point constant."
-  (match_test "standard_sse_constant_p (op)"))
+  "SSE constant zero operand."
+  (match_test "standard_sse_constant_p (op) == 1"))
 
 ;; Constant-or-symbol-reference constraints.
 
Index: config/i386/sse.md
===
--- config/i386/sse.md  (revision 232929)
+++ config/i386/sse.md  (working copy)
@@ -833,7 +833,7 @@
 
 (define_insn "*mov_internal"
   [(set (match_operand:VMOVE 0 "nonimmediate_operand"   "=v,v ,m")
-   (match_operand:VMOVE 1 "nonimmediate_or_sse_const_operand"  "C ,vm,v"))]
+   (match_operand:VMOVE 1 "nonimmediate_or_sse_const_operand"  "BC,vm,v"))]
   "TARGET_SSE
&& (register_operand (operands[0], mode)
|| register_operand (operands[1], mode))"
Index: doc/md.texi
===
--- doc/md.texi (revision 232929)
+++ doc/md.texi (working copy)
@@ -4100,7 +4100,7 @@ Integer constant in the range 0 @dots{} 127, for 1
 Standard 80387 floating point constant.
 
 @item C
-Standard SSE floating point constant.
+SSE constant zero operand.
 
 @item e
 32-bit signed integer constant, or a symbolic reference known
Index: testsuite/gcc.target/i386/pr69459.c
===
--- testsuite/gcc.target/i386/pr69459.c (nonexistent)
+++ testsuite/gcc.target/i386/pr69459.c (working copy)
@@ -0,0 +1,42 @@
+/* PR target/69549 */
+/* { dg-do run { target sse2_runtime } } */
+/* { dg-options "-O2 -msse2" } */
+
+typedef unsigned char u8;
+typedef unsigned short u16;
+typedef unsigned int u32;
+typedef unsigned long long u64;
+typedef unsigned char v16u8 __attribute__ ((vector_size (16)));
+typedef unsigned short v16u16 __attribute__ ((vector_size (16)));
+typedef unsigned int v16u32 __attribute__ ((vector_size (16)));
+typedef unsigned long long v16u64 __attribute__ ((vector_size (16)));
+
+u64 __attribute__((noinline, noclone))
+foo (u8 u8_0, u16 u16_3, v16u8 v16u8_0, v16u16 v16u16_0, v16u32 v16u32_0, 
v16u64 v16u64_0, v16u8 v16u8_1, v16u16 v16u16_1, v16u32 v16u32_1, v16u64 
v16u64_1, v16u8 v16u8_2, v16u16 v16u16_2, v16u32 v16u32_2, v16u64 v16u64_2, 
v16u8 v16u8_3, v16u16 v16u16_3, v16u32 v16u32_3, v16u64 v16u64_3)
+{
+  v16u64_0 /= (v16u64){u16_3, ((0))} | 1;
+  v16u64_1 += (v16u64)~v16u32_0;
+  v16u16_1 /= (v16u16){-v16u64_3[1]} | 1;
+  v16u64_3[1] -= 0x1fff;
+  v16u32_2 /= (v16u32)-v16u64_0 | 1;
+  v16u32_1 += ~v16u32_1;
+  v16u16_3 %= (v16u16){0xfff, v16u32_2[3], v16u8_0[14]} | 1;
+  v16u64_3 -= (v16u64)v16u32_2;
+  if (v16u64_1[1] >= 1) {
+v16u64_0 %= (v16u64){v16u32_0[1]} | 1;
+v16u32_1[1] %= 0x5fb856;
+v16u64_1 |= -v16u64_0;
+  }
+  v16u8_0 *= (v16u8)v16u32_1;
+  return u8_0 + v16u8_0 [12] + v16u8_0 [13] + v16u8_0 [14] + v16u8_0 [15] +

Re: C++ PATCH for c++/69509 and c++/69516 (infinite recursion with invalid VLAs in constexpr functions)

[Jason Merrill]

OK.  I suppose we should also catch the out-of-bounds store in 
cxx_eval_store_expression...


Jason

Re: [PATCH] target/68972 - g++.dg/cpp1y/vla-initlist1.C test case fails on powerpc64le

[Jason Merrill]

On 01/28/2016 02:48 PM, Martin Sebor wrote:

The g++.dg/cpp1y/vla-initlist1.C test relies on undefined behavior
(reading an uninitialized array element) to verify that two VLAs
are allocated in memory starting at the same address.  The test
has been seen to fail on powerpc64-*-linux-gnu and spu-*-elf.
The attached patch removes the undefined behavior while still
verifying the same thing.  It passes on powerpc64le.

Jason, based on your comment in the bug I've removed the part
of the test that verifies that the no-op initializer-list ctor
for the user-defined VLA leaves the array elements uninitialized.
If that's something that should be tested let me know and I'll
add another test or test case for that.


Actually, yes, the testcase is testing for that as well.  Is that the 
part that breaks on PPC64LE?


Jason

Re: [google gcc-4_9]: Backport trunk:r232727 fix for PR/69403.

[Carrot Wei]

LGTM

thanks
Carrot

On Thu, Jan 28, 2016 at 11:53 AM, Han Shen  wrote:
> Backport trunk:r232727 fix for PR/69403 - wrong
> thumb2_ior_scc_strict_it insn pattern.
>
> Note this only affect armv7-a tuned for armv8 arch, tested / booted
> affected ChromeOS book.
>
> Ok for google/gcc-4_9 branch?
>
> --
> Han Shen

Re: C++ PATCH for c++/69509 and c++/69516 (infinite recursion with invalid VLAs in constexpr functions)

[Marek Polacek]

On Thu, Jan 28, 2016 at 05:51:30PM -0500, Jason Merrill wrote:
> OK.  I suppose we should also catch the out-of-bounds store in
> cxx_eval_store_expression...

Thanks, I'll look into that as a follow-up.

Marek

[C++ patch] report better diagnostic for static following '[' in parameter declaration

[Prathamesh Kulkarni]

Hi,
For the test-case,
void f(int a[static 10]);

g++ gives following errors:
test-foo.cpp:1:14: error: expected primary-expression before ‘static’
 void f(int a[static 10]);
  ^
test-foo.cpp:1:14: error: expected ‘]’ before ‘static’
test-foo.cpp:1:14: error: expected ‘)’ before ‘static’
test-foo.cpp:1:14: error: expected initializer before ‘static’

and clang++ gives:
test-foo.cpp:1:13: error: static array size is a C99 feature, not
permitted in C++
void f(int a[static 10]);
^
I have attached patch that attempts to report the same diagnostic.
With patch, g++ reports:

test-foo.cpp:1:14: error: static array size is a C99 feature,not
permitted in C++
 void f(int a[static 10])
  ^~
test-foo.cpp:1:14: error: expected ‘]’ before ‘static’
test-foo.cpp:1:14: error: expected ‘)’ before ‘static’
test-foo.cpp:1:14: error: expected initializer before ‘static’

I tried to remove the 3 errors that follow it (expected X before static)
but without luck :/

Bootstrap and tested on x86_64-unknown-linux-gnu.
OK for trunk ?

Thanks,
Prathamesh
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index d03b0c9..4d3e38a 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -19016,10 +19017,22 @@ cp_parser_direct_declarator (cp_parser* parser,
  cp_lexer_consume_token (parser->lexer);
  /* Peek at the next token.  */
  token = cp_lexer_peek_token (parser->lexer);
+
+ /* If static keyword immediately follows [, report error.  */
+ if (cp_lexer_next_token_is_keyword (parser->lexer, RID_STATIC)
+ && current_binding_level->kind == sk_function_parms)
+   {
+ error_at (token->location,
+   "static array size is a C99 feature,"
+   "not permitted in C++");
+ bounds = error_mark_node;
+   }
+
  /* If the next token is `]', then there is no
 constant-expression.  */
- if (token->type != CPP_CLOSE_SQUARE)
+ else if (token->type != CPP_CLOSE_SQUARE)
{
+
  bool non_constant_p;
  bounds
= cp_parser_constant_expression (parser,
diff --git a/gcc/testsuite/g++.dg/parse/static-array-error.C 
b/gcc/testsuite/g++.dg/parse/static-array-error.C
new file mode 100644
index 000..8b58588
--- /dev/null
+++ b/gcc/testsuite/g++.dg/parse/static-array-error.C
@@ -0,0 +1,6 @@
+// { dg-do compile }
+
+void f(int a[static 10]);  /* { dg-error "static array size is a C99 feature" 
} */
+/* { dg-error "expected ']' before 'static'" "" { target *-*-* } 3 } */
+/* { dg-error "expected ')' before 'static'" "" { target *-*-* } 3 } */
+/* { dg-error "expected initializer before 'static'" "" { target *-*-* } 3 } */


ChangeLog
Description: Binary data

Re: [C++ patch] report better diagnostic for static following '[' in parameter declaration

[Marek Polacek]

On Fri, Jan 29, 2016 at 04:46:56AM +0530, Prathamesh Kulkarni wrote:
> @@ -19016,10 +19017,22 @@ cp_parser_direct_declarator (cp_parser* parser,
> cp_lexer_consume_token (parser->lexer);
> /* Peek at the next token.  */
> token = cp_lexer_peek_token (parser->lexer);
> +
> +   /* If static keyword immediately follows [, report error.  */
> +   if (cp_lexer_next_token_is_keyword (parser->lexer, RID_STATIC)
> +   && current_binding_level->kind == sk_function_parms)
> + {
> +   error_at (token->location,
> + "static array size is a C99 feature,"
> + "not permitted in C++");
> +   bounds = error_mark_node;
> + }
> +

I think this isn't sufficient as-is; if we're changing the diagnostics here,
we should also handle e.g. void f(int a[const 10]); where clang++ says
g.C:1:13: error: qualifier in array size is a C99 feature, not permitted in C++

And also e.g.
void f(int a[const static 10]);
void f(int a[static const 10]);
and similar.

Marek

Re: Is it OK for rtx_addr_can_trap_p_1 to attempt to compute the frame layout? (was Re: [PATCH] Skip re-computing the mips frame info after reload completed)

[Bernd Schmidt]

On 01/28/2016 12:36 AM, Eric Botcazou wrote:

[cc-ing Eric as RTL maintainer]


Sorry for the delay, the message apparently bounced]


IMO the problem is that rtx_addr_can_trap_p_1 duplicates a large
bit of LRA/reload logic:

[...]

Under the current interface macros like INITIAL_ELIMINATION_OFFSET
are expected to trigger the calculation of the target's frame layout
(since you need that information to answer the question).
To me it seems wrong that we're attempting to call that sort of
macro in a query routine like rtx_addr_can_trap_p_1.


I'm a little uncomfortable stepping in here because, while I essentially share
your objections and was opposed to the patch (I was almost sure that it would
introduce maintainance issues for no practical benefit), I didn't imagine that
such a failure mode would have been possible (computing an approximation of
the frame layout after reload being problematic) so I didn't really object to
being overruled after seeing Bernd's patch...


IMO we should cache the information we need@the start of each
LRA/reload cycle.  This will be more robust, because there will
be no accidental changes to global state either during or after
LRA/reload.  It will also be more efficient because
rtx_addr_can_trap_p_1 can read the cached variables rather
than calling back into the target.


That would be a better design for sure and would eliminate the maintainance
issues I was originally afraid of.

My recommendation would be to back out Bernd's patch for GCC 6.0 (again, it
doesn't fix any regression and, more importantly, any bug in real software,
but only corner case bugs in dumb computer-generated testcases) but with the
commitment to address the underlying issue for GCC 7.0 and backport the fix to
GCC 6.x unless really impracticable.  That being said, it's ultimately Jakub
and Richard's call.


I'm on the fence; I do think the original problem is an issue we should 
fix, but I'm also not terribly happy with the implementation we have 
right now. Besides the issues already mentioned, doesn't it kind of 
assume these offsets are constant (which they definitely aren't, 
consider arg pushes for example)?


I think a better approach might be to just mark accesses at known 
locations in the frame, or arg pushes, as MEM_NOTRAP_P, and consider 
accesses with non-constant or calculated offsets as potentially trapping.



Bernd

Re: [PATCH] target/68972 - g++.dg/cpp1y/vla-initlist1.C test case fails on powerpc64le

[Martin Sebor]

On 01/28/2016 03:53 PM, Jason Merrill wrote:

On 01/28/2016 02:48 PM, Martin Sebor wrote:

The g++.dg/cpp1y/vla-initlist1.C test relies on undefined behavior
(reading an uninitialized array element) to verify that two VLAs
are allocated in memory starting at the same address.  The test
has been seen to fail on powerpc64-*-linux-gnu and spu-*-elf.
The attached patch removes the undefined behavior while still
verifying the same thing.  It passes on powerpc64le.

Jason, based on your comment in the bug I've removed the part
of the test that verifies that the no-op initializer-list ctor
for the user-defined VLA leaves the array elements uninitialized.
If that's something that should be tested let me know and I'll
add another test or test case for that.


Actually, yes, the testcase is testing for that as well.  Is that the
part that breaks on PPC64LE?


Yes, that's the only thing the existing test exercises (i.e., that
the second element of the array is unchanged).

What seems to happen is that the call to __builtin_alloca_with_align
uses the stdu (store with update) instruction to store and bump down
the stack pointer (SP) at the same time (standard for powerpc63le)
to make room for the VLA.  The subsequent code then reads the saved
value of the SP and uses it as the address of the VLA. Since the SP
is 64 bits wide, it clobbers the first two words of the VLA.  The
test looks at the second element, expecting it to be unchanged, but
what it finds is the upper word of the saved SP. Since the saved SP
value doesn't get read I don't see anything wrong with this.

Other than that, I did notice one thing that doesn't look right.
There's an empty loop for the no-op initializer_list ctor to
initialize the rest of the array.  I should open a bug for that.
But that's not a unique to the powerpc64 back end. The x86_64
code has the same empty loop.

Martin

Re: [PATCH] target/68972 - g++.dg/cpp1y/vla-initlist1.C test case fails on powerpc64le

[Martin Sebor]

Other than that, I did notice one thing that doesn't look right.
There's an empty loop for the no-op initializer_list ctor to
initialize the rest of the array.  I should open a bug for that.
But that's not a unique to the powerpc64 back end. The x86_64
code has the same empty loop.


I raised bug 69547  - [6 regression] no-op array initializer emits
an empty loop, and bisected it to a constexpr change in r222135.

Martin

Re: C++ PATCH for c++/69496 (ICE on VLA in constexpr function)

[Martin Sebor]

On 01/28/2016 03:27 PM, Marek Polacek wrote:

On Wed, Jan 27, 2016 at 09:52:13AM -0700, Martin Sebor wrote:

This happens to work but I suspect it's only by accident.  When
the number of elements in the initializer is increased to exceed
the number of elements in the VLA GCC gets into infinite recursion.
(I opened bug 69516 with a test case).  The same error in a non-
constexpr function causes a SEGV at runtime (this is also
a regression WRT 4.9.3 -- I opened bug 69517 for it).


FWIW, the patch I posted today should cure all those infinite recursions.


Sounds good, and thanks for the heads up.  I volunteered to add
a louder warning for the VLA initialization and I hope to find
some time to work on it as early as next week.

Martin

Re: C++ PATCH for c++/69509 and c++/69516 (infinite recursion with invalid VLAs in constexpr functions)

[Martin Sebor]

On 01/28/2016 01:33 PM, Marek Polacek wrote:

This patch fixes some problems with VLAs and constexprs.  (The runtime aspect
of this matter is being tracked in PR69517.)  It does two things:

1) Changes build_vec_init slightly to prevent the compiler from getting into
infinite recursion.  Currently, we emit the following sequence when we're
initializing e.g. n = 1; int a[n] = { 1, 2 }; (cleanup_point junk omitted):

   int a[0:(sizetype) (SAVE_EXPR <(ssizetype) n + -1>)];
   (void) (int[0:(sizetype) (SAVE_EXPR <(ssizetype) n + -1>)] *)   int * D.2256;
   (void) (D.2256 = (int *) &a)
 int * D.2257;
   (void) (D.2257 = D.2256)
 long int D.2258;
   (void) (D.2258 = (long int) (SAVE_EXPR <(ssizetype) n + -1>)) // == 0
   (void) (*D.2257 = 1)
   (void)  ++D.2257
   (void)  --D.2258 // == -1
   (void) (*D.2257 = 2)
   (void)  ++D.2257
   (void)  --D.2258 // == -2

   while (1)
 {
   if (D.2258 == -1)// never triggers
goto ;
   (void) (*D.2257 = 0)
   (void)  ++D.2257
   (void)  --D.2258;
 }
   :;
   ...

   So we first write the elements from the initializer and then we 
default-initialize
   any remaining elements.  But the iterator == -1 check is never true for 
invalid
   code, which means the compiler will get stuck in the while loop forever, 
leading
   to crash -- it tries to cxx_eval_* the body of the loop over and over again.

   Fixed by changing == -1 into <= -1; this should only ever happen for invalid 
code,
   but we don't want to ICE in any case.

   This also "fixes" the problem in PR69517 -- the program could get into 
infinite
   recursion as well, because it was evaluating the sequence above at runtime. 
But
   since it's invoking UB, it doesn't matter much.

2) Moves the check for "array subscript out of bound" a tad above, because for
invalid VLAs we can't rely on the bool "found" -- e.g. for the example above
it will find all indexes in the initializer, so "found" is true, which means
we wouldn't get to the out-of-bounds check below.


I haven't had time to study the code but I did apply the patch
and play with it a bit.  It sure does fix the infinite loop/
recursion problem!

That said, while the test case below is rejected with the array
being of type int (as it should be), it's accepted as is, with
the struct.  I don't know enough to tell if it's because of
the change you mention or if it's a latent bug.

The test case is also accepted with an invalid argument to foo
(negative or excessive), both which should be rejected as well.

You're clearly good and efficient at fixing things.  I seem to
have a knack for breaking them.  Please let me know if I should
open a new bug for this.

  struct A {
constexpr A (int = 0) { }
constexpr operator int () const { return 0; }
  };

  constexpr int foo (int n) {
A a [n] = { 1, 2, 3, 4, 5, 6 };
return a [99];
  }

  struct B { unsigned b: foo (1) + 1; };

Martin

[PATCH] Use vm in sse2_cvtps2pd

[H.J. Lu]

sse2_cvtps2pd has

(define_insn "sse2_cvtps2pd"
  [(set (match_operand:V2DF 0 "register_operand" "=v") 
(float_extend:V2DF
  (vec_select:V2SF
(match_operand:V4SF 1 "vector_operand" "vBm") 
(parallel [(const_int 0) (const_int 1)]]

The memory operand size is 8 bytes (2 floats).  We should use vm instead
of vBm.  Tested on Linux/x86-64.  OK for trunk?


H.J.
diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index 84d2b7a..ac96bbf 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -5464,7 +5464,7 @@
   [(set (match_operand:V2DF 0 "register_operand" "=v")
(float_extend:V2DF
  (vec_select:V2SF
-   (match_operand:V4SF 1 "vector_operand" "vBm")
+   (match_operand:V4SF 1 "vector_operand" "vm")
(parallel [(const_int 0) (const_int 1)]]
   "TARGET_SSE2 && "
   "%vcvtps2pd\t{%1, %0|%0, %q1}"

[gomp4] Merge trunk r232931 (2016-01-28) into gomp-4_0-branch

[Thomas Schwinge]

Hi!

Committed to gomp-4_0-branch in r232967:

commit 5999e6842d3f9cecc5cb500ebf692f54158e8017
Merge: 9cfa5d5 b547a9b
Author: tschwinge 
Date:   Fri Jan 29 06:46:35 2016 +

svn merge -r 232548:232931 svn+ssh://gcc.gnu.org/svn/gcc/trunk


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gomp-4_0-branch@232967 
138bc75d-0d04-0410-961f-82ee72b054a4


Grüße
 Thomas

Re: [PATCH] Use vm in sse2_cvtps2pd

[Uros Bizjak]

On Fri, Jan 29, 2016 at 5:01 AM, H.J. Lu  wrote:
> sse2_cvtps2pd has
>
> (define_insn "sse2_cvtps2pd"
>   [(set (match_operand:V2DF 0 "register_operand" "=v")
> (float_extend:V2DF
>   (vec_select:V2SF
> (match_operand:V4SF 1 "vector_operand" "vBm")
> (parallel [(const_int 0) (const_int 1)]]
>
> The memory operand size is 8 bytes (2 floats).  We should use vm instead
> of vBm.  Tested on Linux/x86-64.  OK for trunk?

OK with a ChangeLog.

Thanks,
Uros.

>
> H.J.
> diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
> index 84d2b7a..ac96bbf 100644
> --- a/gcc/config/i386/sse.md
> +++ b/gcc/config/i386/sse.md
> @@ -5464,7 +5464,7 @@
>[(set (match_operand:V2DF 0 "register_operand" "=v")
> (float_extend:V2DF
>   (vec_select:V2SF
> -   (match_operand:V4SF 1 "vector_operand" "vBm")
> +   (match_operand:V4SF 1 "vector_operand" "vm")
> (parallel [(const_int 0) (const_int 1)]]
>"TARGET_SSE2 && "
>"%vcvtps2pd\t{%1, %0|%0, %q1}"

Re: [gomp4, PR68977, Committed] Don't gimplify in ssa mode if seen_error in oacc_xform_loop

[Richard Biener]

On Thu, Jan 28, 2016 at 6:49 PM, Tom de Vries  wrote:
> On 28/01/16 14:32, Richard Biener wrote:
>>
>> On Mon, Jan 25, 2016 at 12:00 PM, Tom de Vries 
>> wrote:
>>>
>>> On 14/01/16 10:43, Richard Biener wrote:


 On Wed, Jan 13, 2016 at 9:04 PM, Tom de Vries 
 wrote:
>
>
> Hi,
>
> At r231739, there was an ICE when checking code generated by
> oacc_xform_loop, in case the source contained an error.
>
> Due to seen_error (), gimplification during oacc_xform_loop bailed out,
> and
> an uninitialized var was introduced.  Because of gimplifying in ssa
> mode,
> that caused an ICE.
>
> I can't reproduce this any longer, but I think the fix still makes
> sense.
> The patch makes sure oacc_xform_loop gimplifies in non-ssa mode if
> seen_error ().



 I don't think it makes "sense" in any way.  After seen_error () a
 following ICE
 will be "confused after earlier errors" in release mode and thus I think
 that's
 not an important problem to paper over with this kind of "hack".

 I'd rather avoid doing any of omp-low if seen_error ()?

>>>
>>> The error triggered in oacc_device_lower, so there's nothing we can do
>>> before (in omp-low).
>>>
>>> How about this fix, which replaces the oacc ifn calls with
>>> zero-assignments
>>> if seen_error ()?
>>
>>
>> Again it looks like too much complexity for an ICE-after-error which will
>> be reported as "confused after errors" only.
>
>
> IMO it's not much different from what is done in lower_omp_1:
> ...
>   /* If we have issued syntax errors, avoid doing any heavy lifting.
>  Just replace the OMP directives with a NOP to avoid
>  confusing RTL expansion.  */
>   if (seen_error () && is_gimple_omp (stmt))
> {
>   gsi_replace (gsi_p, gimple_build_nop (), true);
>   return;
> }
> ...
>
>> I'd accept a patch that simply
>> stops processing the function before lowering which is what we usually
>> do with this kind of cases [yes, it might make sense to start tracking
>> seen-error per function].
>>
>
> [ AFAIU, the patch below stops after lowering. ]
>
>
>> So in this case add a seen_errors () guard to cgraph_node::expand ()
>> like the following:
>>
>> Index: cgraphunit.c
>> ===
>> --- cgraphunit.c(revision 232666)
>> +++ cgraphunit.c(working copy)
>> @@ -1967,15 +1967,18 @@ cgraph_node::expand (void)
>>
>> execute_all_ipa_transforms ();
>>
>> -  /* Perform all tree transforms and optimizations.  */
>> -
>> -  /* Signal the start of passes.  */
>> -  invoke_plugin_callbacks (PLUGIN_ALL_PASSES_START, NULL);
>> -
>> -  execute_pass_list (cfun, g->get_passes ()->all_passes);
>> -
>> -  /* Signal the end of passes.  */
>> -  invoke_plugin_callbacks (PLUGIN_ALL_PASSES_END, NULL);
>> +  if (! seen_error ())
>> +{
>> +  /* Perform all tree transforms and optimizations.  */
>> +
>> +  /* Signal the start of passes.  */
>> +  invoke_plugin_callbacks (PLUGIN_ALL_PASSES_START, NULL);
>> +
>> +  execute_pass_list (cfun, g->get_passes ()->all_passes);
>> +
>> +  /* Signal the end of passes.  */
>> +  invoke_plugin_callbacks (PLUGIN_ALL_PASSES_END, NULL);
>> +}
>>
>> bitmap_obstack_release (®_obstack);
>
>
> I suppose the patch makes sense in general.
>
> But it doesn't address the scenario I'm trying to fix:
> pass_oacc_device_lower signals an error, and then may run into an ICE during
> gimplification in that same pass.
>
> What would work (and is less fine-grained than the solutions I've proposed
> until now) is bailing out of pass_oacc_device_lower once seen_error, before
> doing any gimplification, and then not running any further passes, to
> prevent running into further ICEs.

I see.  Is it possible to simply scrub the whole OACC region in this
case instead?
Or even better, report those errors earlier?

Richard.

> Thanks,
> - Tom
>