[arm.c] Use VAR_P

[Prathamesh Kulkarni]

Hi,
This patch uses replaces TREE_CODE(x) == VAR_DECL by VAR_P(x) in arm.c.
Bootstrap+tested on arm-linux-gnueabihf.
OK to commit ?

Thanks,
Prathamesh
2016-10-28  Prathamesh Kulkarni  

* config/arm/arm.c (arm_const_not_ok_for_debug_p): Use VAR_P.

diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 3c4c704..a39e64f 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -30150,9 +30150,9 @@ arm_const_not_ok_for_debug_p (rtx p)
  && GET_CODE (XEXP (p, 0)) == SYMBOL_REF
  && (decl_op0 = SYMBOL_REF_DECL (XEXP (p, 0
{
- if ((TREE_CODE (decl_op1) == VAR_DECL
+ if ((VAR_P (decl_op1)
   || TREE_CODE (decl_op1) == CONST_DECL)
- && (TREE_CODE (decl_op0) == VAR_DECL
+ && (VAR_P (decl_op0)
  || TREE_CODE (decl_op0) == CONST_DECL))
return (get_variable_section (decl_op1, false)
!= get_variable_section (decl_op0, false));

Re: [RFC] Handle unary pass-through jump functions for ipa-vrp

[kugan]

Hi,

On 28/10/16 01:58, Jan Hubicka wrote:

gcc/testsuite/ChangeLog:

2016-10-25  Kugan Vivekanandarajah  

* gcc.dg/ipa/vrp7.c: New test.


gcc/ChangeLog:

2016-10-25  Kugan Vivekanandarajah  

* ipa-cp.c (ipa_get_jf_pass_through_result): Skip unary expressions.
(propagate_vr_accross_jump_function): Handle unary expressions.
(propagate_constants_accross_call): Pass param type to
propagate_vr_accross_jump_function.
* ipa-prop.c (load_from_param): Renamed from load_from_unmodified_param.
Also handles unary expr.
(ipa_set_jf_unary_pass_through): New.
(ipa_load_from_parm_agg): Renamed load_from_unmodified_param.
(compute_complex_assign_jump_func): Handle unary expressions.
(ipa_write_jump_function): Likewise.
(ipa_read_jump_function): Likewise.
* ipa-prop.h: export ipa_get_callee_param_type.



diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
index 1dc5cb6..d0dc3d7 100644
--- a/gcc/ipa-cp.c
+++ b/gcc/ipa-cp.c
@@ -122,6 +122,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "ipa-inline.h"
 #include "ipa-utils.h"
 #include "tree-ssa-ccp.h"
+#include "gimple.h"

 template  class ipcp_value;

@@ -1221,7 +1222,12 @@ ipa_get_jf_pass_through_result (struct ipa_jump_func 
*jfunc, tree input)

   if (ipa_get_jf_pass_through_operation (jfunc) == NOP_EXPR)
 return input;
-  if (!is_gimple_ip_invariant (input))
+
+  if (!is_gimple_ip_invariant (input)
+  /* TODO: Unary expressions are not handles in ipa constant
+propagation. */


handled.
I would expect them to be already folded here?  I would expect that hanlding
unary expressions in constant propagation is no harder than for VRP?


I have changed this now.




+ || (TREE_CODE_CLASS (ipa_get_jf_pass_through_operation (jfunc))
+ == tcc_unary))
 return NULL_TREE;

   if (TREE_CODE_CLASS (ipa_get_jf_pass_through_operation (jfunc))
@@ -1845,7 +1851,8 @@ propagate_bits_accross_jump_function (cgraph_edge *cs, 
int idx, ipa_jump_func *j
 static bool
 propagate_vr_accross_jump_function (cgraph_edge *cs,
ipa_jump_func *jfunc,
-   struct ipcp_param_lattices *dest_plats)
+   struct ipcp_param_lattices *dest_plats,
+   tree param_type)


New param needs comment.


Done.

Also addressed Martin's comments.

I have also separated the constant parameter conversion out and posted 
as https://gcc.gnu.org/ml/gcc-patches/2016-10/msg02309.html. This is now 
handling just unary pass-through jump functions.


Bootstrapped and regression tested on x86_64-linux-gnu with no new 
regressions.


Is this OK for trunk?

Thanks,
Kugan

gcc/testsuite/ChangeLog:

2016-10-28  Kugan Vivekanandarajah  

* gcc.dg/ipa/vrp7.c: New test.


gcc/ChangeLog:

2016-10-28  Kugan Vivekanandarajah  

* ipa-cp.c (ipa_get_jf_pass_through_result): Handle unary expressions.
(propagate_vr_accross_jump_function): Likewise.
* ipa-prop.c (ipa_set_jf_unary_pass_through): New.
(load_from_param_1): New.
(load_from_unmodified_param): Factor common part into load_from_param_1.
(load_from_param): New.
(compute_complex_assign_jump_func): Handle unary expressions.
(ipa_write_jump_function): Likewise.
(ipa_read_jump_function): Likewise.



Patch is OK with changes Martin suggested.

Honza

>From b7d9b413951ba20d156a7801640cc7d7bc57c062 Mon Sep 17 00:00:00 2001
From: Kugan Vivekanandarajah 
Date: Fri, 28 Oct 2016 10:16:38 +1100
Subject: [PATCH 2/2] add unary jump function

---
 gcc/ipa-cp.c| 39 +++---
 gcc/ipa-prop.c  | 89 +++--
 gcc/testsuite/gcc.dg/ipa/vrp7.c | 32 +++
 3 files changed, 142 insertions(+), 18 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/ipa/vrp7.c

diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
index 9f28557..8fc95dd 100644
--- a/gcc/ipa-cp.c
+++ b/gcc/ipa-cp.c
@@ -1225,13 +1225,21 @@ ipa_get_jf_pass_through_result (struct ipa_jump_func *jfunc, tree input)
 return NULL_TREE;
 
   if (TREE_CODE_CLASS (ipa_get_jf_pass_through_operation (jfunc))
-  == tcc_comparison)
-restype = boolean_type_node;
+  == tcc_unary)
+{
+  res = fold_unary (ipa_get_jf_pass_through_operation (jfunc),
+			TREE_TYPE (input), input);
+}
   else
-restype = TREE_TYPE (input);
-  res = fold_binary (ipa_get_jf_pass_through_operation (jfunc), restype,
-		 input, ipa_get_jf_pass_through_operand (jfunc));
-
+{
+  if (TREE_CODE_CLASS (ipa_get_jf_pass_through_operation (jfunc))
+	  == tcc_comparison)
+	restype = boolean_type_node;
+  else
+	restype = TREE_TYPE (input);
+  res = fold_binary (ipa_get_jf_pass_through_operation (jfunc), restype,
+			

[ipa-vrp] ice in set_value_range

[kugan]

Hi,


 {
   tree val = ipa_get_jf_constant (jfunc);
   if (TREE_CODE (val) == INTEGER_CST)
{
+ value_range vr;
  if (TREE_OVERFLOW_P (val))
val = drop_tree_overflow (val);
- jfunc->vr_known = true;
- jfunc->m_vr.type = VR_RANGE;
- jfunc->m_vr.min = val;
- jfunc->m_vr.max = val;
+
+ vr.type = VR_RANGE;
+ vr.min = val;
+ vr.max = val;
+ vr.equiv = NULL;
+ extract_range_from_unary_expr (>m_vr,
+NOP_EXPR,
+param_type,
+, TREE_TYPE (val));


Do I understand it correctly that extract_range_from_unary_expr deals
with any potential type conversions better (compared to what you did
before here)?


Yes, this can be wrong at times too as reported in 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78121. I have separated 
this part of the patch with a testcase.


Please note that I am using fold_convert in the attached patch.

Bootstrapped and regression tested on x86_64-linux-gnu with no new 
regressions. Is this OK for trunk?


Thanks,
Kugan


gcc/ChangeLog:

2016-10-28  Kugan Vivekanandarajah  

PR ipa/78121
* ipa-cp.c (propagate_vr_accross_jump_function): Pass param type.
Also fold constant passed as argument while computing value range.
(propagate_constants_accross_call): Pass param type.
* ipa-prop.c: export ipa_get_callee_param_type.
* ipa-prop.h: export ipa_get_callee_param_type.

gcc/testsuite/ChangeLog:

2016-10-28  Kugan Vivekanandarajah  

PR ipa/78121
* gcc.dg/ipa/pr78121.c: New test.
>From 64776c1b43c9fd68aee6c40624660d20e1c4e653 Mon Sep 17 00:00:00 2001
From: Kugan Vivekanandarajah 
Date: Fri, 28 Oct 2016 09:44:23 +1100
Subject: [PATCH 1/2] fix convertion

---
 gcc/ipa-cp.c   | 16 +---
 gcc/ipa-prop.c |  5 -
 gcc/ipa-prop.h |  1 +
 gcc/testsuite/gcc.dg/ipa/pr78121.c | 16 
 4 files changed, 34 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/ipa/pr78121.c

diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
index 1dc5cb6..9f28557 100644
--- a/gcc/ipa-cp.c
+++ b/gcc/ipa-cp.c
@@ -1840,12 +1840,14 @@ propagate_bits_accross_jump_function (cgraph_edge *cs, int idx, ipa_jump_func *j
 }
 
 /* Propagate value range across jump function JFUNC that is associated with
-   edge CS and update DEST_PLATS accordingly.  */
+   edge CS with param of callee of PARAM_TYPE and update DEST_PLATS
+   accordingly.  */
 
 static bool
 propagate_vr_accross_jump_function (cgraph_edge *cs,
 ipa_jump_func *jfunc,
-struct ipcp_param_lattices *dest_plats)
+struct ipcp_param_lattices *dest_plats,
+tree param_type)
 {
   struct ipcp_param_lattices *src_lats;
   ipcp_vr_lattice *dest_lat = _plats->m_value_range;
@@ -1853,6 +1855,11 @@ propagate_vr_accross_jump_function (cgraph_edge *cs,
   if (dest_lat->bottom_p ())
 return false;
 
+  if (!param_type
+  || (!INTEGRAL_TYPE_P (param_type)
+	  && !POINTER_TYPE_P (param_type)))
+return dest_lat->set_to_bottom ();
+
   if (jfunc->type == IPA_JF_PASS_THROUGH)
 {
   struct ipa_node_params *caller_info = IPA_NODE_REF (cs->caller);
@@ -1871,6 +1878,7 @@ propagate_vr_accross_jump_function (cgraph_edge *cs,
 	{
 	  if (TREE_OVERFLOW_P (val))
 	val = drop_tree_overflow (val);
+	  val = fold_convert (param_type, val);
 	  jfunc->vr_known = true;
 	  jfunc->m_vr.type = VR_RANGE;
 	  jfunc->m_vr.min = val;
@@ -2220,6 +2228,7 @@ propagate_constants_accross_call (struct cgraph_edge *cs)
 {
   struct ipa_jump_func *jump_func = ipa_get_ith_jump_func (args, i);
   struct ipcp_param_lattices *dest_plats;
+  tree param_type = ipa_get_callee_param_type (cs, i);
 
   dest_plats = ipa_get_parm_lattices (callee_info, i);
   if (availability == AVAIL_INTERPOSABLE)
@@ -2236,7 +2245,8 @@ propagate_constants_accross_call (struct cgraph_edge *cs)
 		   dest_plats);
 	  if (opt_for_fn (callee->decl, flag_ipa_vrp))
 	ret |= propagate_vr_accross_jump_function (cs,
-		   jump_func, dest_plats);
+		   jump_func, dest_plats,
+		   param_type);
 	  else
 	ret |= dest_plats->m_value_range.set_to_bottom ();
 	}
diff --git a/gcc/ipa-prop.c b/gcc/ipa-prop.c
index 1629870..74fe199 100644
--- a/gcc/ipa-prop.c
+++ b/gcc/ipa-prop.c
@@ -1595,7 +1595,10 @@ determine_locally_known_aggregate_parts (gcall *call, tree arg,
 }
 }
 
-static tree
+/* Return the Ith param type of callee associated with call graph
+   edge E.  */
+
+tree
 ipa_get_callee_param_type (struct cgraph_edge *e, int i)
 {
   int n;
diff --git a/gcc/ipa-prop.h b/gcc/ipa-prop.h
index 4eeae88..0e75cf4 100644
--- a/gcc/ipa-prop.h
+++ b/gcc/ipa-prop.h
@@ -818,6 +818,7 @@ 

[PATCH] enhance buffer overflow warnings (and c/53562)

[Martin Sebor]

The attached patch enhances the compile-time detection of buffer
overflow in functions like __builtin___memcpy_chk to consider
non-constant lengths known to be in a certain range and warn
when the lower bound of the range doesn't fit in the destination
object.

The patch does the same thing for the non-checking functions like
__builtin_memcpy and issues buffer overflow warnings for those.
For string functions like __builtin_strcpy, the patch also makes
use of ranges of lengths of non-constant strings.

To make reasoning about the warnings easier (and to help with
debugging the problems), the patch also extends the warnings to
print the ranges of lengths and sizes of the operands.  The text
and content of the warning messages is based on those issued by
the -Wformat-length warning pass.

Finally, as requested in bug 53562, the patch adds a new warning
option, -Wstringop-overflow, to control these warnings (the option
is on by default).  I chose a different name for the option than
suggested in the bug to avoid giving the impression that it
actually inserts the checking calls (all it does is warn on
buffer overflows detectable at compile-time).

I was originally going to submit a more modest version of this
patch as part of a bigger project I'm working on (bug 77608) but
then decided to submit this one first because it's independent of
the other.

Possible enhancements include letting the option accept a level
argument and at level 2 using the upper bound of the size or
string length ranges similarly to the -Wformat-length option.
With that, the following could be diagnosed as a potential
buffer overflow:

  char d[5];
  strcpy (d, x ? "123" : "123456");

Thanks
Martin
PR c/53562 - Add -Werror= support for -D_FORTIFY_SOURCE / __builtin___memcpy_chk

gcc/ChangeLog:
2016-10-27  Martin Sebor  

	PR c/53562
	* builtins.c (check_sizes): New function.
	(expand_builtin_memcpy): Call it.
	(expand_builtin_mempcpy): Same.
	(expand_builtin_strcpy): Same.
	(expand_builtin_memset): Same.
	(expand_builtin_bzero): Same.
	(expand_builtin_memory_chk): Same.
	(maybe_emit_sprintf_chk_warning): Same.
	* doc/invoke.texi (Warning Options): Document -Wstringop-overflow.

gcc/c-family/ChangeLog:
2016-10-27  Martin Sebor  

	PR c/53562
	* c.opt (-Wstringop-overflow): New option.

gcc/testsuite/ChangeLog:
2016-10-27  Martin Sebor  

	PR c/53562
	* gcc.dg/builtin-stringop-chk-4.c: New test.
	* c-c++-common/Wsizeof-pointer-memaccess2.c: Adjust.
	* g++.dg/ext/builtin-object-size3.C: Same.
	* g++.dg/ext/strncpy-chk1.C: Same.
	* g++.dg/torture/Wsizeof-pointer-memaccess1.C: Same.
	* gcc.c-torture/execute/builtins/lib/chk.c: Same.
	* gcc.c-torture/execute/builtins/mempcpy-chk.c: Same.
	* gcc.dg/Wobjsize-1.c: Same.
	* gcc.dg/attr-alloc_size.c (test): Same.
	* gcc.dg/builtin-object-size-1.c: Same.
	* gcc.dg/builtin-object-size-5.c: Same.
	* gcc.dg/builtin-stringop-chk-1.c: Same.
	* gcc.dg/builtin-stringop-chk-2.c: Same.
	* gcc.dg/builtin-strncat-chk-1.c: Same.
	* gcc.dg/memcpy-2.c: Same.
	* gcc.dg/pr40340-1.c: Same.
	* gcc.dg/pr40340-2.c: Same.
	* gcc.dg/pr40340-5.c: Same.
	* gcc.dg/torture/Wsizeof-pointer-memaccess1.c: Same.

diff --git a/gcc/builtins.c b/gcc/builtins.c
index facecd3..d1aef0a 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -67,7 +67,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "internal-fn.h"
 #include "case-cfn-macros.h"
 #include "gimple-fold.h"
-
+#include "intl.h"
 
 struct target_builtins default_target_builtins;
 #if SWITCHABLE_TARGET
@@ -2967,6 +2967,133 @@ expand_builtin_memcpy_args (tree dest, tree src, tree len, rtx target, tree exp)
   return dest_addr;
 }
 
+/* Try to verify that the sizes and lengths of the arguments to a string
+   manipulation function given by EXP are within valid bounds and that
+   the operation does not lead to buffer overflow.  Arguments other than
+   EXP may be null.  When non-null, the arguments have the following
+   meaning:
+   SIZE is the user-supplied size argument to the function (such as in
+   memcpy(d, s, SIZE).
+   N is the user-supplied length of the source sequence (such as in
+   strncpy(d, s, N).
+   LEN is the length of the source sequence (such as in strcpy(d, s),
+   LEN = strlen(s)).
+   OBJSIZE is the size of the destination object specified by the last
+   argument to the _chk builtins, typically resulting from the expansion
+   of __builtin_object_size (such as in __builtin___strcpy_chk(d, s,
+   OBJSIZE).
+
+   When SIZE is null LEN is checked to verify that it doesn't exceed
+   SIZE_MAX.
+
+   If the call is successfully verfified as safe from buffer overflow
+   the function returns EXP.  Otherwise, if the call is determined to
+   overflow the function returns error_mark_node.  Otherwise, if
+   the call cannot be verified, the function returns NULL.  */
+
+static tree
+check_sizes (tree exp, tree size, tree n, tree len, tree objsize)
+{
+  tree minlen = NULL_TREE;
+  tree 

Re: [PATCH], Allow SImode to go into VSX registers on PowerPC ISA 2.07 (power8) and above

[Michael Meissner]

On Thu, Oct 27, 2016 at 02:55:51PM -0500, Segher Boessenkool wrote:
> On Wed, Oct 26, 2016 at 06:51:54PM -0400, Michael Meissner wrote:
> > (zero_extendsi2): Reorder pattern, so RLDICL comes before
> > the FPR and VSX loads, but before MTVSRWZ.  Remove ??, ! from the
> > constraints.  Add MFVSRWZ and XXEXTRACTUW instructions to support
> > small integers in vector registers.
> 
> "but those before MTVSRWZ"?  Or don't mention rldicl at all?
> 
> > (extendsi2): Reorder pattern, so EXTSW comes before the FPR
> > and VSX loads, but before MTVSRWA.  Remove ??, ! from the
> > constraints.  Add VEXTSW2D support for small integers in vector
> > registers.
> 
> Similar here.

I reworded it to say RLDICL/EXTS came after the GPR load before before the
FPR/VSX loads.

> 
> > @@ -3112,7 +3133,10 @@ rs6000_init_hard_regno_mode_ok (bool glo
> > ww - Register class to do SF conversions in with VSX operations.
> > wx - Float register if we can do 32-bit int stores.
> > wy - Register class to do ISA 2.07 SF operations.
> > -   wz - Float register if we can do 32-bit unsigned int loads.  */
> > +   wz - Float register if we can do 32-bit unsigned int loads.
> > +   wI - VSX register if SImode is allowed in VSX registers.
> > +   wJ - VSX register if QImode/HImode are allowed in VSX registers.
> > +   wK - Altivec register if QImode/HImode are allowed in VSX registers.  */
> 
> You don't mention wH here, is that an oversight?

Yes, thanks for catching this.
 
> >/* Add support for various direct moves available.  In this function, we 
> > only
> >   look at cases where we don't need any extra registers, and one or more
> > - simple move insns are issued.  At present, 32-bit integers are not 
> > allowed
> > + simple move insns are issued. Originally small integers are not 
> > allowed
> 
> dot space space.

Thanks.

> > @@ -5019,7 +5023,10 @@ (define_insn_and_split "floatsi2_l
> >operands[1] = rs6000_address_for_fpconvert (operands[1]);
> >if (GET_CODE (operands[2]) == SCRATCH)
> >  operands[2] = gen_reg_rtx (DImode);
> > -  emit_insn (gen_lfiwax (operands[2], operands[1]));
> > +  if (TARGET_VSX_SMALL_INTEGER)
> > +emit_insn (gen_extendsidi2 (operands[2], operands[1]));
> > +  else
> 
> Trailing spaces here.

Fixed.

> > +   (match_operand:SI 1 "input_operand"
> > +   "r,  U,   m,   Z,   Z,
> > +r,  wI,  wH,  I,   L,
> > + n,  wIwH,O,   wM,  wB,
> 
> Indent with tabs instead of spaces, like the other lines.

Thanks.

> Everything looks fine except for those nits, and I'm really happy there
> is no benchmark degradation :-)
> 
> Please install to trunk (if the -m32 and power7 runs work out fine).

Submitted as subversion id 241631.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797

[PATCH, GCC] Fix conflicting posix_memalign declaration error

[Caroline Tice]

The posix_memalign declaration in gcc/i386/config/pmm_malloc.h is
decorated with 'throw ()', which occasionally causes declaration
conflict errors (some header files, not part of GCC, that declare
posix_memalign, do not have the throw decoration).  An example of this
can be seen at https://github.com/android-ndk/ndk/issues/91.  It
appears that the 'throw()' decoration comes from glibc header files.
Adding ifdefs to check for __GLIBC__ before adding the 'throw()' fixed
the github problem mentioned above.

I have tested this patch by bootstrapping and by running test
testsuite with no regressions.

Is this ok to commit?

-- Caroline Tice
ctic...@gmail.com


gcc/ChangeLog:

2016-10-27  Caroline Tice  

* config/i386/pmm_malloc.h (posix_memalign):  Add ifdefs to only
decorate the declaration with 'throw()' if __GLIBC__ is defined.
Index: gcc/config/i386/pmm_malloc.h
===
--- gcc/config/i386/pmm_malloc.h	(revision 241483)
+++ gcc/config/i386/pmm_malloc.h	(working copy)
@@ -31,8 +31,12 @@
 #ifndef __cplusplus
 extern int posix_memalign (void **, size_t, size_t);
 #else
+#ifdef __GLIBC__
 extern "C" int posix_memalign (void **, size_t, size_t) throw ();
+#else
+extern "C" int posix_memalign (void **, size_t, size_t);
 #endif
+#endif
 
 static __inline void *
 _mm_malloc (size_t __size, size_t __alignment)

[Aarch64][PATCH] Improve Logical And Immediate Expressions

[Michael Collison]

This patch is designed to improve code generation for "and" instructions with 
certain immediate operands.

For the following test case:

int f2(int x)
{
   x &= 0x0ff8;

   x &= 0xff001fff;

   return x;
}

the trunk aarch64 compiler generates:

mov w1, 8184
movkw1, 0xf00, lsl 16
and w0, w0, w1

We can generate one fewer instruction if we recognize certain constants. With 
the attached patch the current trunk compiler generates:

and w0, w0, 268435448
and w0, w0, -16769025

Bootstrapped and make check successfully completed with no regressions on 
aarch64-linux-gnu.

Okay for trunk?

Regards,

Michael Collison



ChangeLog entries are as follows:

*** gcc/ChangeLog ***

2016-10-27  Michael Collison  

* config/aarch64/aarch64-protos.h
(aarch64_and_split_imm1, aarch64_and_split_imm2)
(aarch64_and_bitmask_imm): New prototypes
* config/aarch64/aarch64.c (aarch64_and_split_imm1):
New overloaded function to create bit mask covering the
lowest to highest bits set.
(aarch64_and_split_imm2): New overloaded functions to create bit
mask of zeros between first and last bit set.
(aarch64_and_bitmask_imm): New function to determine if a integer
is a valid two instruction "and" operation.
* config/aarch64/aarch64.md:(and3): New define_insn and _split
allowing wider range of constants with "and" operations.
* (ior3, xor3): Use new LOGICAL2 iterator to prevent
"and" operator from matching restricted constant range used for
ior and xor operators.
* config/aarch64/constraints.md (UsO constraint): New SImode constraint
for constants in "and" operations.
(UsP constraint): New DImode constraint for constants in "and" 
operations.
* config/aarch64/iterators.md (lconst2): New mode iterator.
(LOGICAL2): New code iterator.
* config/aarch64/predicates.md (aarch64_logical_and_immediate): New
predicate
(aarch64_logical_and_operand): New predicate allowing extended constants
for "and" operations.

*** gcc/testsuite/ChangeLog ***

2016-10-27  Michael Collison  

testsuite/
* gcc.target/aarch64/and_const.c: New test to verify
additional constants are recognized and fewer instructions generated.



gnutools_5860_ipreview3.patch
Description: gnutools_5860_ipreview3.patch

Re: [PATCH, LIBGCC] Avoid count_leading_zeros with undefined result (PR 78067)

[Joseph Myers]

On Thu, 27 Oct 2016, Bernd Edlinger wrote:

> Hi,
> 
> by code reading I became aware that libgcc can call count_leading_zeros
> in certain cases which can give undefined results.  This happens on
> signed int128 -> float or double conversions, when the int128 is in the range
> INT64_MAX+1 to UINT64_MAX.

I'd expect testcases added to the testsuite that exercise this case at 
runtime, if not already present.

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

Re: [PATCH], Allow SImode to go into VSX registers on PowerPC ISA 2.07 (power8) and above

[Segher Boessenkool]

On Wed, Oct 26, 2016 at 06:51:54PM -0400, Michael Meissner wrote:
>   (zero_extendsi2): Reorder pattern, so RLDICL comes before
>   the FPR and VSX loads, but before MTVSRWZ.  Remove ??, ! from the
>   constraints.  Add MFVSRWZ and XXEXTRACTUW instructions to support
>   small integers in vector registers.

"but those before MTVSRWZ"?  Or don't mention rldicl at all?

>   (extendsi2): Reorder pattern, so EXTSW comes before the FPR
>   and VSX loads, but before MTVSRWA.  Remove ??, ! from the
>   constraints.  Add VEXTSW2D support for small integers in vector
>   registers.

Similar here.

> @@ -3112,7 +3133,10 @@ rs6000_init_hard_regno_mode_ok (bool glo
>   ww - Register class to do SF conversions in with VSX operations.
>   wx - Float register if we can do 32-bit int stores.
>   wy - Register class to do ISA 2.07 SF operations.
> - wz - Float register if we can do 32-bit unsigned int loads.  */
> + wz - Float register if we can do 32-bit unsigned int loads.
> + wI - VSX register if SImode is allowed in VSX registers.
> + wJ - VSX register if QImode/HImode are allowed in VSX registers.
> + wK - Altivec register if QImode/HImode are allowed in VSX registers.  */

You don't mention wH here, is that an oversight?

>/* Add support for various direct moves available.  In this function, we 
> only
>   look at cases where we don't need any extra registers, and one or more
> - simple move insns are issued.  At present, 32-bit integers are not 
> allowed
> + simple move insns are issued. Originally small integers are not allowed

dot space space.

> @@ -5019,7 +5023,10 @@ (define_insn_and_split "floatsi2_l
>operands[1] = rs6000_address_for_fpconvert (operands[1]);
>if (GET_CODE (operands[2]) == SCRATCH)
>  operands[2] = gen_reg_rtx (DImode);
> -  emit_insn (gen_lfiwax (operands[2], operands[1]));
> +  if (TARGET_VSX_SMALL_INTEGER)
> +emit_insn (gen_extendsidi2 (operands[2], operands[1]));
> +  else

Trailing spaces here.

> + (match_operand:SI 1 "input_operand"
> + "r,  U,   m,   Z,   Z,
> +  r,  wI,  wH,  I,   L,
> + n,  wIwH,O,   wM,  wB,

Indent with tabs instead of spaces, like the other lines.


Everything looks fine except for those nits, and I'm really happy there
is no benchmark degradation :-)

Please install to trunk (if the -m32 and power7 runs work out fine).

Thanks,


Segher

Re: [PATCH] Fix select type parsing (PR fortran/78026)

[Jakub Jelinek]

On Thu, Oct 27, 2016 at 12:45:25PM -0700, Steve Kargl wrote:
> Thanks for the detailed analysis.  The patch looks ok to me.
> I would prefer functional and cosmetic changes to be committed 
> separately, but in this case the cosmetic changes are small.
> 
> > +   {
> > + std::swap (ns, gfc_current_ns);
> > + gfc_free_namespace (ns);
> > + return m;
> > +   }
> 
> Not being C++ literate.  I assume that the above is essential
> 
> tmp_ns = ns
> ns = gfc_currrent_ns
> gfc_current_ns = tmp_ns
> free(ns)

Yeah.  I could have written
  ns = gfc_current_ns;
  gfc_current_ns = gfc_current_ns->parent;
  gfc_free_namespace (ns);
too, but that is longer.  I'm also not too much enthusiastic about
putting C++ constructs everywhere, but std::swap is actually one of the few
things I like about C++ in GCC sources, it is more readable.

Jakub

Re: [PATCH] Fix select type parsing (PR fortran/78026)

[Steve Kargl]

On Thu, Oct 27, 2016 at 09:07:49PM +0200, Jakub Jelinek wrote:
> 
> This PR has been reported as something related to OpenMP, but in the end
> I think it is unrelated, the bug I see is in the select type parsing.
> 
> The problem is that if select type is the very first stmt in the TU,
> we parse it and before actually accepting that ST_SELECT_TYPE, we perform
> various tasks needed for MAIN__ - e.g. assign gfc_current_ns proc_name.
> The problem is that when parsing select type, we create a nested
> gfc_namespace and so the name is assigned to this nested namespace rather
> than its parent (and various other operations done on this namespace).
> 
> Also, it seems decode_statement is grossly inefficient, for any of the
> statements handled in the /* General statement matching: ... */
> switch we allocate a new namespace:
>   gfc_current_ns = gfc_build_block_ns (gfc_current_ns);
>   match (NULL, gfc_match_select_type, ST_SELECT_TYPE);
>   ns = gfc_current_ns;
>   gfc_current_ns = gfc_current_ns->parent;
>   gfc_free_namespace (ns);
> only to free it a few lines later in the likely case that we aren't seeing
> select type.  And in select_type_38.f03 testcase below I've also tried
> to construct a testcase where it is invalid - because the gfc_match_label
> on the select_type already goes into the new namespace, no errors are
> diagnosed if the same label is used on multiple select type statements
> (but we diagnose same label on select case, if etc.).
> 
> So, the patch defers creating the new namespace until we really need it
> (thus, label is put still into the parent namespace, and only create
> the namespace after successfully parsing select type (, and then arrange
> either if we don't return MATCH_YES to free the namespace again in the
> gfc_match_select_type, or, when returning MATCH_YES, to keep the namespace
> only in new_st.ext.block.ns and not in gfc_current_ns.  Then, only in
> parse_select_type_block we switch back to that namespace.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 

Thanks for the detailed analysis.  The patch looks ok to me.
I would prefer functional and cosmetic changes to be committed 
separately, but in this case the cosmetic changes are small.

> + {
> +   std::swap (ns, gfc_current_ns);
> +   gfc_free_namespace (ns);
> +   return m;
> + }

Not being C++ literate.  I assume that the above is essential

tmp_ns = ns
ns = gfc_currrent_ns
gfc_current_ns = tmp_ns
free(ns)

-- 
Steve

[PATCH] Fix COMPONENT_REF expansion (PR rtl-optimization/77919)

[Jakub Jelinek]

Hi!

The following testcase ICEs on x86_64-linux with -O1, the problem is
that we expand assignment from COMPONENT_REF of MEM_REF into a V4SImode
SSA_NAME.  The MEM_REF has non-addressable DCmode var inside of it, and
type of a struct containing a single V4SImode element.

The bug seems to be that if the op0 (i.e. get_inner_reference expanded)
is a CONCAT and we want a reference that covers all bits of the CONCAT,
we just short path it and return it immediately, rather than trying
to convert it to the requested mode.

I've bootstrapped/regtested on x86_64-linux and i686-linux the following
patch, which takes the short path only if we want a complex mode.
The only place it makes a difference in both bootstraps/regtests was this
new testcase.

Though, perhaps COMPLEX_MODE_P (mode1) is also wrong, if mode1 isn't
GET_MODE (op0), then we still will return something with unexpected mode
(e.g. DCmode vs. CDImode); I wonder if for such mismatches we shouldn't
just force_reg (convert_modes ()) each CONCAT operand separately and
create a new CONCAT.  Do we have a guarantee that COMPLEX_MODE_P (GET_MODE 
(op0))
if op0 is CONCAT?

2016-10-27  Jakub Jelinek  

PR rtl-optimization/77919
* expr.c (expand_expr_real_1) : Force CONCAT into
MEM if mode1 is not a complex mode.

* g++.dg/torture/pr77919.C: New test.

--- gcc/expr.c.jj   2016-10-27 20:50:22.699586175 +0200
+++ gcc/expr.c  2016-10-27 21:15:30.146309091 +0200
@@ -10421,7 +10421,8 @@ expand_expr_real_1 (tree exp, rtx target
if (GET_CODE (op0) == CONCAT && !must_force_mem)
  {
if (bitpos == 0
-   && bitsize == GET_MODE_BITSIZE (GET_MODE (op0)))
+   && bitsize == GET_MODE_BITSIZE (GET_MODE (op0))
+   && COMPLEX_MODE_P (mode1))
  {
if (reversep)
  op0 = flip_storage_order (GET_MODE (op0), op0);
--- gcc/testsuite/g++.dg/torture/pr77919.C.jj   2016-10-27 21:15:19.883440139 
+0200
+++ gcc/testsuite/g++.dg/torture/pr77919.C  2016-10-27 21:16:01.694906242 
+0200
@@ -0,0 +1,11 @@
+// PR rtl-optimization/77919
+// { dg-do compile }
+// { dg-additional-options "-Wno-psabi" }
+
+struct A { A (double) {} _Complex double i; };
+typedef int __attribute__ ((vector_size (16))) B;
+typedef struct { B b; } C;
+struct D { D (const B ) : b (x) {} B b; };
+static inline B foo (const double *x) { C *a; a = (C *) x; return a->b; }
+static inline D baz (const A ) { return foo ((double *) ); }
+D b = baz (0);

Jakub

[PATCH] Fix a REE bug (PR rtl-optimization/78132)

[Jakub Jelinek]

Hi!

REE breaks the following testcase on KNL, where we only accept
QImode/HImode in k0-k7 registers (SImode/DImode is only supported
with -mavx512bw).  We have
(set (reg:HI k0) (mem:HI ...))
...
(set (reg:DI rax) (zero_extend:DI (reg:HI k0)))
and we optimize it into:
(set (reg:DI rax) (zero_extend:DI (mem:HI ...)))
(set (reg:DI k0) (reg:DI rax))
The first insn is fine, but the latter is not really valid, kmovq
is only avx512bw, only kmovw is avx512f.

Fixed by consulting HARD_REGNO_MODE_OK in addition to comparing
HARD_REGNO_NREGS.

This change affects just
gcc.target/i386/{avx512{f,dq}-pr77476.c,avx512f-klogic-2.c,pr78132.c}
testcases, in all cases it is about k0 or k1 register and SImode or DImode.

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

2016-10-27  Jakub Jelinek  

PR rtl-optimization/78132
* ree.c (combine_reaching_defs): Give up if copy_needed and
!HARD_REGNO_MODE_OK (REGNO (src_reg), dst_mode).

* gcc.target/i386/pr78132.c: New test.

--- gcc/ree.c.jj2016-10-21 11:36:33.0 +0200
+++ gcc/ree.c   2016-10-27 18:43:00.899215537 +0200
@@ -788,6 +788,11 @@ combine_reaching_defs (ext_cand *cand, c
   machine_mode dst_mode = GET_MODE (SET_DEST (PATTERN (cand->insn)));
   rtx src_reg = get_extended_src_reg (SET_SRC (PATTERN (cand->insn)));
 
+  /* Ensure we can use the src_reg in dst_mode (needed for
+the (set (reg1) (reg2)) insn mentioned above).  */
+  if (!HARD_REGNO_MODE_OK (REGNO (src_reg), dst_mode))
+   return false;
+
   /* Ensure the number of hard registers of the copy match.  */
   if (HARD_REGNO_NREGS (REGNO (src_reg), dst_mode)
  != HARD_REGNO_NREGS (REGNO (src_reg), GET_MODE (src_reg)))
--- gcc/testsuite/gcc.target/i386/pr78132.c.jj  2016-10-27 18:48:25.944128889 
+0200
+++ gcc/testsuite/gcc.target/i386/pr78132.c 2016-10-27 18:48:53.538781368 
+0200
@@ -0,0 +1,20 @@
+/* PR rtl-optimization/78132 */
+/* { dg-do compile } */
+/* { dg-options "-O3 -mavx512f -mno-avx512bw -mno-avx512dq -masm=att" } */
+/* { dg-final { scan-assembler-not "kmov\[dq]\t" } } */
+
+unsigned short c;
+char a, d, f, b;
+short e;
+long g;
+
+int
+main ()
+{
+  g = c;
+  f = c & e;
+  d = c & a | e;
+  if (a)
+b = c;
+  return 0;
+}

Jakub

[PATCH] Fix select type parsing (PR fortran/78026)

[Jakub Jelinek]

Hi!

This PR has been reported as something related to OpenMP, but in the end
I think it is unrelated, the bug I see is in the select type parsing.

The problem is that if select type is the very first stmt in the TU,
we parse it and before actually accepting that ST_SELECT_TYPE, we perform
various tasks needed for MAIN__ - e.g. assign gfc_current_ns proc_name.
The problem is that when parsing select type, we create a nested
gfc_namespace and so the name is assigned to this nested namespace rather
than its parent (and various other operations done on this namespace).

Also, it seems decode_statement is grossly inefficient, for any of the
statements handled in the /* General statement matching: ... */
switch we allocate a new namespace:
  gfc_current_ns = gfc_build_block_ns (gfc_current_ns);
  match (NULL, gfc_match_select_type, ST_SELECT_TYPE);
  ns = gfc_current_ns;
  gfc_current_ns = gfc_current_ns->parent;
  gfc_free_namespace (ns);
only to free it a few lines later in the likely case that we aren't seeing
select type.  And in select_type_38.f03 testcase below I've also tried
to construct a testcase where it is invalid - because the gfc_match_label
on the select_type already goes into the new namespace, no errors are
diagnosed if the same label is used on multiple select type statements
(but we diagnose same label on select case, if etc.).

So, the patch defers creating the new namespace until we really need it
(thus, label is put still into the parent namespace, and only create
the namespace after successfully parsing select type (, and then arrange
either if we don't return MATCH_YES to free the namespace again in the
gfc_match_select_type, or, when returning MATCH_YES, to keep the namespace
only in new_st.ext.block.ns and not in gfc_current_ns.  Then, only in
parse_select_type_block we switch back to that namespace.

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

2016-10-27  Jakub Jelinek  

PR fortran/78026
* parse.c (decode_statement): Don't create namespace for possible
select type here and destroy it afterwards.
(parse_select_type_block): Set gfc_current_ns to new_st.ext.block.ns.
(parse_executable, gfc_parse_file): Formatting fixes.
* match.c (gfc_match_select_type): Create namespace for select type
here, only after matching select type.  Formatting fixes.  Free that
namespace if not returning MATCH_YES, after gfc_undo_symbols,
otherwise remember it in new_st.ext.block.ns and switch to parent
namespace anyway.

* gfortran.dg/gomp/pr78026.f03: New test.
* gfortran.dg/select_type_38.f03: New test.

--- gcc/fortran/parse.c.jj  2016-10-25 18:23:27.0 +0200
+++ gcc/fortran/parse.c 2016-10-27 12:19:52.843900690 +0200
@@ -295,7 +295,6 @@ static bool in_specification_block;
 static gfc_statement
 decode_statement (void)
 {
-  gfc_namespace *ns;
   gfc_statement st;
   locus old_locus;
   match m = MATCH_NO;
@@ -424,12 +423,7 @@ decode_statement (void)
   match (NULL, gfc_match_associate, ST_ASSOCIATE);
   match (NULL, gfc_match_critical, ST_CRITICAL);
   match (NULL, gfc_match_select, ST_SELECT_CASE);
-
-  gfc_current_ns = gfc_build_block_ns (gfc_current_ns);
   match (NULL, gfc_match_select_type, ST_SELECT_TYPE);
-  ns = gfc_current_ns;
-  gfc_current_ns = gfc_current_ns->parent;
-  gfc_free_namespace (ns);
 
   /* General statement matching: Instead of testing every possible
  statement, we eliminate most possibilities by peeking at the
@@ -4103,6 +4097,7 @@ parse_select_type_block (void)
   gfc_code *cp;
   gfc_state_data s;
 
+  gfc_current_ns = new_st.ext.block.ns;
   accept_statement (ST_SELECT_TYPE);
 
   cp = gfc_state_stack->tail;
@@ -5188,7 +5183,7 @@ parse_executable (gfc_statement st)
  break;
 
case ST_SELECT_TYPE:
- parse_select_type_block();
+ parse_select_type_block ();
  break;
 
case ST_DO:
@@ -6027,12 +6022,11 @@ loop:
   prog_locus = gfc_current_locus;
 
   push_state (, COMP_PROGRAM, gfc_new_block);
-  main_program_symbol(gfc_current_ns, gfc_new_block->name);
+  main_program_symbol (gfc_current_ns, gfc_new_block->name);
   accept_statement (st);
   add_global_program ();
   parse_progunit (ST_NONE);
   goto prog_units;
-  break;
 
 case ST_SUBROUTINE:
   add_global_procedure (true);
@@ -6040,7 +6034,6 @@ loop:
   accept_statement (st);
   parse_progunit (ST_NONE);
   goto prog_units;
-  break;
 
 case ST_FUNCTION:
   add_global_procedure (false);
@@ -6048,7 +6041,6 @@ loop:
   accept_statement (st);
   parse_progunit (ST_NONE);
   goto prog_units;
-  break;
 
 case ST_BLOCK_DATA:
   push_state (, COMP_BLOCK_DATA, gfc_new_block);
@@ -6083,7 +6075,6 @@ loop:
   main_program_symbol (gfc_current_ns, "MAIN__");
   parse_progunit (st);
   goto prog_units;
-  break;
 }
 
   /* 

[committed] Fix simd clone creation for noreturn functions (PR middle-end/78025)

[Jakub Jelinek]

Hi!

In simd_clone_adjust we weren't taking into account the possibility of no
edges to the exit block.  If inbranch, we still want to create the loop over
the simd lanes, though of course don't have any edges from the body to the
increment bb - e.g. if one calls the function with all zeros mask, it will
still do nothing as it should; for notinbranch, there is no loop, we just
handle the first simd lane and not return to the following ones.

Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk.

2016-10-27  Jakub Jelinek  

PR middle-end/78025
* omp-simd-clone.c (simd_clone_adjust): Handle noreturn declare simd
functions.

* g++.dg/gomp/declare-simd-7.C: New test.

--- gcc/omp-simd-clone.c.jj 2016-10-26 18:14:26.869045304 +0200
+++ gcc/omp-simd-clone.c2016-10-27 10:51:55.292277315 +0200
@@ -1107,7 +1107,7 @@ simd_clone_adjust (struct cgraph_node *n
  return values accordingly.  */
   tree iter = create_tmp_var (unsigned_type_node, "iter");
   tree iter1 = make_ssa_name (iter);
-  tree iter2 = make_ssa_name (iter);
+  tree iter2 = NULL_TREE;
   ipa_simd_modify_function_body (node, adjustments, retval, iter1);
   adjustments.release ();
 
@@ -1121,39 +1121,57 @@ simd_clone_adjust (struct cgraph_node *n
 
   pop_gimplify_context (NULL);
 
+  gimple *g;
+  basic_block incr_bb = NULL;
+  struct loop *loop = NULL;
+
   /* Create a new BB right before the original exit BB, to hold the
  iteration increment and the condition/branch.  */
-  basic_block orig_exit = EDGE_PRED (EXIT_BLOCK_PTR_FOR_FN (cfun), 0)->src;
-  basic_block incr_bb = create_empty_bb (orig_exit);
-  add_bb_to_loop (incr_bb, body_bb->loop_father);
-  /* The succ of orig_exit was EXIT_BLOCK_PTR_FOR_FN (cfun), with an empty
- flag.  Set it now to be a FALLTHRU_EDGE.  */
-  gcc_assert (EDGE_COUNT (orig_exit->succs) == 1);
-  EDGE_SUCC (orig_exit, 0)->flags |= EDGE_FALLTHRU;
-  for (unsigned i = 0;
-   i < EDGE_COUNT (EXIT_BLOCK_PTR_FOR_FN (cfun)->preds); ++i)
+  if (EDGE_COUNT (EXIT_BLOCK_PTR_FOR_FN (cfun)->preds))
+{
+  basic_block orig_exit = EDGE_PRED (EXIT_BLOCK_PTR_FOR_FN (cfun), 0)->src;
+  incr_bb = create_empty_bb (orig_exit);
+  add_bb_to_loop (incr_bb, body_bb->loop_father);
+  /* The succ of orig_exit was EXIT_BLOCK_PTR_FOR_FN (cfun), with an empty
+flag.  Set it now to be a FALLTHRU_EDGE.  */
+  gcc_assert (EDGE_COUNT (orig_exit->succs) == 1);
+  EDGE_SUCC (orig_exit, 0)->flags |= EDGE_FALLTHRU;
+  for (unsigned i = 0;
+  i < EDGE_COUNT (EXIT_BLOCK_PTR_FOR_FN (cfun)->preds); ++i)
+   {
+ edge e = EDGE_PRED (EXIT_BLOCK_PTR_FOR_FN (cfun), i);
+ redirect_edge_succ (e, incr_bb);
+   }
+}
+  else if (node->simdclone->inbranch)
+{
+  incr_bb = create_empty_bb (entry_bb);
+  add_bb_to_loop (incr_bb, body_bb->loop_father);
+}
+
+  if (incr_bb)
 {
-  edge e = EDGE_PRED (EXIT_BLOCK_PTR_FOR_FN (cfun), i);
-  redirect_edge_succ (e, incr_bb);
+  edge e = make_edge (incr_bb, EXIT_BLOCK_PTR_FOR_FN (cfun), 0);
+  e->probability = REG_BR_PROB_BASE;
+  gsi = gsi_last_bb (incr_bb);
+  iter2 = make_ssa_name (iter);
+  g = gimple_build_assign (iter2, PLUS_EXPR, iter1,
+  build_int_cst (unsigned_type_node, 1));
+  gsi_insert_after (, g, GSI_CONTINUE_LINKING);
+
+  /* Mostly annotate the loop for the vectorizer (the rest is done
+below).  */
+  loop = alloc_loop ();
+  cfun->has_force_vectorize_loops = true;
+  loop->safelen = node->simdclone->simdlen;
+  loop->force_vectorize = true;
+  loop->header = body_bb;
 }
-  edge e = make_edge (incr_bb, EXIT_BLOCK_PTR_FOR_FN (cfun), 0);
-  e->probability = REG_BR_PROB_BASE;
-  gsi = gsi_last_bb (incr_bb);
-  gimple *g = gimple_build_assign (iter2, PLUS_EXPR, iter1,
-  build_int_cst (unsigned_type_node, 1));
-  gsi_insert_after (, g, GSI_CONTINUE_LINKING);
-
-  /* Mostly annotate the loop for the vectorizer (the rest is done below).  */
-  struct loop *loop = alloc_loop ();
-  cfun->has_force_vectorize_loops = true;
-  loop->safelen = node->simdclone->simdlen;
-  loop->force_vectorize = true;
-  loop->header = body_bb;
 
   /* Branch around the body if the mask applies.  */
   if (node->simdclone->inbranch)
 {
-  gimple_stmt_iterator gsi = gsi_last_bb (loop->header);
+  gsi = gsi_last_bb (loop->header);
   tree mask_array
= node->simdclone->args[node->simdclone->nargs - 1].simd_array;
   tree mask;
@@ -1227,50 +1245,59 @@ simd_clone_adjust (struct cgraph_node *n
   FALLTHRU_EDGE (loop->header)->flags = EDGE_FALSE_VALUE;
 }
 
+  basic_block latch_bb = NULL;
+  basic_block new_exit_bb = NULL;
+
   /* Generate the condition.  */
-  g = gimple_build_cond (LT_EXPR,
-iter2,
-build_int_cst (unsigned_type_node,
-   

Re: [PATCH, libstdc++]: Fix PR 70975, experimental/filesystem/operations/copy.cc FAILs on Solaris 12

[Uros Bizjak]

On Thu, Oct 27, 2016 at 8:43 PM, Jonathan Wakely  wrote:

>> Is there a good reason to call it "always_zero_offset" rather than
>> something that fits on one line, like "offset"?
>>
>> OK for trunk anyway, thanks.
>
>
>
> (I actually already sent a similar patch, see
> https://gcc.gnu.org/ml/gcc-patches/2016-10/msg02276.html but I didn't
> commit it yet due to some network issues I've been having today).

Oh, I just planned to re-test and submit exactly the version you sent.
I'll take care for commit to SVN.

Thanks,
Uros.

Re: [PATCH, libstdc++]: Fix PR 70975, experimental/filesystem/operations/copy.cc FAILs on Solaris 12

[Jonathan Wakely]

On 27/10/16 19:41 +0100, Jonathan Wakely wrote:

On 27/10/16 20:33 +0200, Uros Bizjak wrote:

Attached patch improves sendfile syscall compatibility with (older)
Solaris 12, where non-null third argument is required. It also paves
the way for compatibility with Solaris 10/11, where otherwise
additional -lsendfile is needed to link with libsendfile library. The
change has no effect on linux.


2016-10-27  Uros Bizjak  

  PR libstdc++/70975
  * src/filesystem/ops.cc (do_copy_file) [_GLIBCXX_USE_SENDFILE]:
  Use pointer to zero as non-null third argument of sendfile call.

Bootstrapped and regression tested on x86_64-linux-gnu {,-m32} CentOS
5 and Fedora 24. Also tested by Rainer on older Solaris 12, where the
patch fixes testsuite failure.

OK for mainline?

Uros.



diff --git a/libstdc++-v3/src/filesystem/ops.cc 
b/libstdc++-v3/src/filesystem/ops.cc
index 9abcee0..b709858 100644
--- a/libstdc++-v3/src/filesystem/ops.cc
+++ b/libstdc++-v3/src/filesystem/ops.cc
@@ -444,7 +444,9 @@ namespace
 }

#ifdef _GLIBCXX_USE_SENDFILE
-const auto n = ::sendfile(out.fd, in.fd, nullptr, from_st->st_size);
+off_t always_zero_offset = 0;
+const auto n = ::sendfile(out.fd, in.fd,
+ _zero_offset, from_st->st_size);
   if (n < 0 && (errno == ENOSYS || errno == EINVAL))
 {
#endif


Is there a good reason to call it "always_zero_offset" rather than
something that fits on one line, like "offset"?

OK for trunk anyway, thanks.



(I actually already sent a similar patch, see
https://gcc.gnu.org/ml/gcc-patches/2016-10/msg02276.html but I didn't
commit it yet due to some network issues I've been having today).

Re: [PATCH, libstdc++]: Fix PR 70975, experimental/filesystem/operations/copy.cc FAILs on Solaris 12

[Jonathan Wakely]

On 27/10/16 20:33 +0200, Uros Bizjak wrote:

Attached patch improves sendfile syscall compatibility with (older)
Solaris 12, where non-null third argument is required. It also paves
the way for compatibility with Solaris 10/11, where otherwise
additional -lsendfile is needed to link with libsendfile library. The
change has no effect on linux.


2016-10-27  Uros Bizjak  

   PR libstdc++/70975
   * src/filesystem/ops.cc (do_copy_file) [_GLIBCXX_USE_SENDFILE]:
   Use pointer to zero as non-null third argument of sendfile call.

Bootstrapped and regression tested on x86_64-linux-gnu {,-m32} CentOS
5 and Fedora 24. Also tested by Rainer on older Solaris 12, where the
patch fixes testsuite failure.

OK for mainline?

Uros.



diff --git a/libstdc++-v3/src/filesystem/ops.cc 
b/libstdc++-v3/src/filesystem/ops.cc
index 9abcee0..b709858 100644
--- a/libstdc++-v3/src/filesystem/ops.cc
+++ b/libstdc++-v3/src/filesystem/ops.cc
@@ -444,7 +444,9 @@ namespace
  }

#ifdef _GLIBCXX_USE_SENDFILE
-const auto n = ::sendfile(out.fd, in.fd, nullptr, from_st->st_size);
+off_t always_zero_offset = 0;
+const auto n = ::sendfile(out.fd, in.fd,
+ _zero_offset, from_st->st_size);
if (n < 0 && (errno == ENOSYS || errno == EINVAL))
  {
#endif


Is there a good reason to call it "always_zero_offset" rather than
something that fits on one line, like "offset"?

OK for trunk anyway, thanks.

Re: [PATCH, LIBGCC] Avoid count_leading_zeros with undefined result (PR 78067)

[Bernd Edlinger]

On 10/27/16 20:04, Bernd Schmidt wrote:
> On 10/27/2016 05:57 PM, Bernd Edlinger wrote:
>> In the function below we have if ((UWtype)u == u)
>> that actually ensures hi != 0.
>
> Ah, right. So maybe we ought to just add the same case here as well?
>
>   if ((UWtype)u == u)
> return (FSTYPE)(UWtype)u;
>
> That would also make the comment less misleading. The condition should
> ensure that u is positive and representable in UWtype, so this should be
> correct, right?
>

you mean:

   if ((Wtype)u == u)
 return (FSTYPE)(Wtype)u;
   if ((UWtype)u == u)
 return (FSTYPE)(UWtype)u;

I think, that should work as well, yes.

OTOH there is a possibility that COUNT_LEADING_ZEROS_0
indicates that we will not need any extra checks here.


Bernd.

[PATCH, libstdc++]: Fix PR 70975, experimental/filesystem/operations/copy.cc FAILs on Solaris 12

[Uros Bizjak]

Attached patch improves sendfile syscall compatibility with (older)
Solaris 12, where non-null third argument is required. It also paves
the way for compatibility with Solaris 10/11, where otherwise
additional -lsendfile is needed to link with libsendfile library. The
change has no effect on linux.


2016-10-27  Uros Bizjak  

PR libstdc++/70975
* src/filesystem/ops.cc (do_copy_file) [_GLIBCXX_USE_SENDFILE]:
Use pointer to zero as non-null third argument of sendfile call.

Bootstrapped and regression tested on x86_64-linux-gnu {,-m32} CentOS
5 and Fedora 24. Also tested by Rainer on older Solaris 12, where the
patch fixes testsuite failure.

OK for mainline?

Uros.
diff --git a/libstdc++-v3/src/filesystem/ops.cc 
b/libstdc++-v3/src/filesystem/ops.cc
index 9abcee0..b709858 100644
--- a/libstdc++-v3/src/filesystem/ops.cc
+++ b/libstdc++-v3/src/filesystem/ops.cc
@@ -444,7 +444,9 @@ namespace
   }
 
 #ifdef _GLIBCXX_USE_SENDFILE
-const auto n = ::sendfile(out.fd, in.fd, nullptr, from_st->st_size);
+off_t always_zero_offset = 0;
+const auto n = ::sendfile(out.fd, in.fd,
+ _zero_offset, from_st->st_size);
 if (n < 0 && (errno == ENOSYS || errno == EINVAL))
   {
 #endif

Re: [PATCH, LIBGCC] Avoid count_leading_zeros with undefined result (PR 78067)

[Bernd Schmidt]

On 10/27/2016 05:57 PM, Bernd Edlinger wrote:

In the function below we have if ((UWtype)u == u)
that actually ensures hi != 0.


Ah, right. So maybe we ought to just add the same case here as well?

  if ((UWtype)u == u)
return (FSTYPE)(UWtype)u;

That would also make the comment less misleading. The condition should 
ensure that u is positive and representable in UWtype, so this should be 
correct, right?



Bernd

[committed] libgomp: Use appropriate size for malloc in goacc_new_thread

[Aldy Hernandez]

Last year I had queued this up for the gomp4.1 merge to mainline, and 
Jakub said if no one complained it would be OK (or so I recall :-/).


Either way, I believe it's an obvious change.

This is working because sizeof(gomp_thread) is larger than 
sizeof(goacc_thread), but the extra memory is unnecessary.  It's not 
like goacc_thread has any variable length data at the end.


Committed to trunk.
commit 0c93cf2e4a8fe72b682ceceb344a3e59b9da0a9b
Author: Aldy Hernandez 
Date:   Thu Oct 27 10:27:59 2016 -0700

* oacc-init.c (goacc_new_thread): Use sizeof of the appropriate
size when allocating new thread.

diff --git a/libgomp/oacc-init.c b/libgomp/oacc-init.c
index f2325ad..83920b52 100644
--- a/libgomp/oacc-init.c
+++ b/libgomp/oacc-init.c
@@ -325,7 +325,7 @@ acc_shutdown_1 (acc_device_t d)
 static struct goacc_thread *
 goacc_new_thread (void)
 {
-  struct goacc_thread *thr = gomp_malloc (sizeof (struct gomp_thread));
+  struct goacc_thread *thr = gomp_malloc (sizeof (struct goacc_thread));
 
 #if defined HAVE_TLS || defined USE_EMUTLS
   goacc_tls_data = thr;

Re: [PATCH, RFC] Introduce -fsanitize=use-after-scope (v2)

[Jakub Jelinek]

On Thu, Oct 27, 2016 at 04:40:30PM +0200, Martin Liška wrote:
> On 10/21/2016 04:26 PM, Jakub Jelinek wrote:
> > On Wed, Oct 12, 2016 at 04:07:53PM +0200, Martin Liška wrote:
> >>> Ok, first let me list some needed follow-ups that don't need to be handled
> >>> right away:
> >>> - r237814-like changes for ASAN_MARK
> 
> I've spent quite some on that and that's what I begin 
> (use-after-scope-addressable.patch).
> Problem is that as I ignore all ASAN_MARK internal fns, the code does not 
> detect having address
> taken in:
> 
> _2 = MEM[(char *)_char + 8B];
> 
>   char *ptr;
>   {
> char my_char[9];
> ptr = _char[0];
>   }
> 
>   return *(ptr+8);
> 
> and thus the code in tree-ssa.c (maybe_optimize_var) sets TREE_ADDRESSABLE 
> (var) = 0.

Perhaps we should do that only if the var's type is_gimple_reg_type,
then we'd rewrite that into SSA at that time, right?  So, in theory if we
turned the ASAN_MARK poisoning call into another internal function
(var_5 = ASAN_POISON ()) and then after converting it into SSA looked at
all the uses of such an lhs and perhaps at sanopt part or when marked all
the use places with a library call that would complain at runtime?
Or turn those back at sanopt time into addressable memory loads which would
be poisoned or similar?  Or alternatively, immediately before turning
variables addressable just because of ASAN_MARK into non-addressable use
the same framework into-ssa uses to find out if there are any poisoned
accesses, and just not optimize it in that case.
Anyway, this can be done incrementally.

> Second question I have is whether we want to handle just TREE_ADDRESSABLE 
> stuff during gimplification?
> Basically in a way that the current patch is doing?

How could variables that aren't TREE_ADDRESSABLE during gimplification be
accessed out of scope?

> +/* Return true if DECL should be guarded on the stack.  */
> +
> +static inline bool
> +asan_protect_stack_decl (tree decl)
> +{
> +  return DECL_P (decl)
> +&& (!DECL_ARTIFICIAL (decl)
> + || (asan_sanitize_use_after_scope () && TREE_ADDRESSABLE (decl)));

Bad formatting.  Should be:

  return (DECL_P (decl)
  && (!DECL_ARTIFICIAL (decl)
  || (asan_sanitize_use_after_scope ()
  && TREE_ADDRESSABLE (decl;

Ok for trunk with that change.

Jakub

Re: [PATCH][AARCH64]Skip gcc.target/aarch64/pr66912.c in tiny or large memory model.

[Renlin Li]

On 27/10/16 16:28, Andrew Pinski wrote:

On Thu, Oct 27, 2016 at 4:24 AM, Renlin Li  wrote:

Hi,

On 27/10/16 11:48, Szabolcs Nagy wrote:


On 27/10/16 11:25, Renlin Li wrote:


Hi all,

This a simple patch to fix gcc.target/aarch64/pr66912.c.
It's a test case only applicable to small memory model which is the
default
one.



/* { dg-final { scan-assembler ":got(page_lo15)?:n_common" } } */

i think this is supposed to work on tiny and small model as well.
(:got:var vs :gotpage_lo15:var)


Sorry, I didn't aware it's a regex which will match both.


it will have to be updated for large model when we have support for that.



yes, large memory model will have different relocation for this case, which
will
not be caught by this pattern.



It also fails for ILP32.  I have not looked into the assembler output there yet.


Hi Andrew,

For ILP32, the relocation will be R_AARCH64_LD32_GOTPAGE_LO14 in small memory 
model.
So the string modifier would be "gotpage_lo14"

Regards,
Renlin


Thanks,
Andrew



Regards,
Renlin





It has been tested to run only when the memory model is small.
Okay to commit?

Regards,
Renlin Li

gcc/testsuite/ChangeLog:

2016-10-27  Renlin Li  

  * gcc.target/aarch64/pr66912.c: Skip tiny and large memory model.

Re: [PR debug/77773] segfault when compiling __simd64_float16_t with -g

[Aldy Hernandez]

On 10/27/2016 12:35 AM, Richard Biener wrote:

On Wed, Oct 26, 2016 at 9:17 PM, Aldy Hernandez  wrote:

The following one-liner segfaults on arm-eabi when compiled with
-mfloat-abi=hard -g:

__simd64_float16_t usingit;

The problem is that the pretty printer (in simple_type_specificer()) is
dereferencing a NULL result from c_common_type_for_mode:

  int prec = TYPE_PRECISION (t);
  if (ALL_FIXED_POINT_MODE_P (TYPE_MODE (t)))
t = c_common_type_for_mode (TYPE_MODE (t), TYPE_SATURATING (t));
  else
t = c_common_type_for_mode (TYPE_MODE (t), TYPE_UNSIGNED (t));
  if (TYPE_NAME (t))

The type in question is:



which corresponds to HFmode and which AFAICT, does not have a type by
design.

I see that other uses of *type_for_node() throughout the compiler check the
result for NULL, so perhaps we should do the same here.

The attached patch fixes the problem.

OK for trunk?


Your added assert shows another possible issue - can you fix this by assigning
the result of c_common_type_for_mode to a new variable, like common_t and
use that for the TYPE_NAME (...) case?  I think this was what was intended.


Certainly.

OK pending tests?

Aldy
commit 1b914820aca7fa82079622b7ba1f7b01b1e79344
Author: Aldy Hernandez 
Date:   Wed Oct 26 12:06:09 2016 -0700

PR debug/3
* c-pretty-print.c (simple_type_specifier): Do not dereference `t'
if NULL.

diff --git a/gcc/c-family/c-pretty-print.c b/gcc/c-family/c-pretty-print.c
index 90428ca..7ad5900 100644
--- a/gcc/c-family/c-pretty-print.c
+++ b/gcc/c-family/c-pretty-print.c
@@ -344,14 +344,17 @@ c_pretty_printer::simple_type_specifier (tree t)
   else
{
  int prec = TYPE_PRECISION (t);
+ tree common_t;
  if (ALL_FIXED_POINT_MODE_P (TYPE_MODE (t)))
-   t = c_common_type_for_mode (TYPE_MODE (t), TYPE_SATURATING (t));
+   common_t = c_common_type_for_mode (TYPE_MODE (t),
+  TYPE_SATURATING (t));
  else
-   t = c_common_type_for_mode (TYPE_MODE (t), TYPE_UNSIGNED (t));
- if (TYPE_NAME (t))
+   common_t = c_common_type_for_mode (TYPE_MODE (t),
+  TYPE_UNSIGNED (t));
+ if (common_t && TYPE_NAME (common_t))
{
- simple_type_specifier (t);
- if (TYPE_PRECISION (t) != prec)
+ simple_type_specifier (common_t);
+ if (TYPE_PRECISION (common_t) != prec)
{
  pp_colon (this);
  pp_decimal_int (this, prec);

[committed] avoid double evaluation of PIC_OFFSET_TABLE_REGNUM

[Aldy Hernandez]

This patch was approved for stage1 a few months back, and I've neglected 
to commit it.  There are no changes from the posted patch.


https://gcc.gnu.org/ml/gcc-patches/2016-03/msg01373.html

Committed to trunk.
commit 5321d430b8d2cf33ff2b5fd9d6cc3f8d1304b0a2
Author: Aldy Hernandez 
Date:   Thu Mar 24 22:44:59 2016 -0500

* builtins.c (expand_builtin_nonlocal_goto): Avoid evaluating
PIC_OFFSET_TABLE_REGNUM twice.

diff --git a/gcc/builtins.c b/gcc/builtins.c
index 997c0e8..cc711a0 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -1140,8 +1140,8 @@ expand_builtin_nonlocal_goto (tree exp)
 to targets with a nonlocal_goto pattern; they are free
 to implement it in their own way.  Note also that this is
 a no-op if the GP register is a global invariant.)  */
-  if ((unsigned) PIC_OFFSET_TABLE_REGNUM != INVALID_REGNUM
- && fixed_regs[PIC_OFFSET_TABLE_REGNUM])
+  unsigned regnum = PIC_OFFSET_TABLE_REGNUM;
+  if (regnum != INVALID_REGNUM && fixed_regs[regnum])
emit_use (pic_offset_table_rtx);
 
   emit_indirect_jump (r_label);

Re: [PATCH] Fix bootstrap with --enable-languages=all,go

[Jeff Law]

On 10/27/2016 05:00 AM, Rainer Orth wrote:

Hi Jeff,


On 10/19/2016 06:13 AM, Rainer Orth wrote:

Hi Jakub,


2016-10-01  Rainer Orth  

* configure.ac (target_libraries): Readd target-boehm-gc.
Restore --enable-objc-gc handling.
* configure: Regenerate.


This is incomplete.  I guess it can be committed as is, but should be
followed by re-addition of:
  bfin-*-*)
noconfigdirs="$noconfigdirs target-boehm-gc"
;;
  cris-*-* | crisv32-*-*)
case "${target}" in
  *-*-linux*)
;;
  *) # See PR46792 regarding target-libffi.
noconfigdirs="$noconfigdirs target-boehm-gc";;
esac
;;
  mmix-*-*)
noconfigdirs="$noconfigdirs target-boehm-gc"
;;
(perhaps in the same case as target-libffi handling).


sorry I missed this.  I can still re-add it if desired, but would rather
keep it in a separate case from the target-libffi handling: in-tree
boehm-gc may be replaced with an external version, while libffi is
likely to stay for libgo.

I think disabling of target-boehm-gc for these targets was because they
didn't support Java for various reasons.   However, ISTM that we'd need it


but wouldn't it have been sufficient to just disable libjava in this
case?  boehm-gc was only dragged in for libjava (or --enable-objc-gc), IIUC.
It would have been sufficient -- I think it was just overlooked as an 
option at the time.





In theory we could build those targets after configuring with
--eanble-objc-gc as a test.


True, but that would need complete cross-development environments for
those targets.  I'm certainly not up for that, especially not at this
point.
:-)   It was just an observation, certainly not going to require that of 
you.


jeff

Re: [PATCH, LIBGCC] Avoid count_leading_zeros with undefined result (PR 78067)

[Bernd Edlinger]

On 10/27/16 14:52, Bernd Schmidt wrote:
> On 10/27/2016 01:27 PM, Bernd Edlinger wrote:
>> Hi,
>>
>> by code reading I became aware that libgcc can call count_leading_zeros
>> in certain cases which can give undefined results.  This happens on
>> signed int128 -> float or double conversions, when the int128 is in
>> the range
>> INT64_MAX+1 to UINT64_MAX.
>
> Did you actually observe this? Because, prior to this code,
>
>> Index: libgcc2.c
>> ===
>> --- libgcc2.c(revision 241400)
>> +++ libgcc2.c(working copy)
>> @@ -1643,6 +1643,11 @@
>>  hi = -(UWtype) hi;
>>
>>UWtype count, shift;
>> +#if !defined (COUNT_LEADING_ZEROS_0) || COUNT_LEADING_ZEROS_0 !=
>> W_TYPE_SIZE
>> +  if (hi == 0)
>> +count = W_TYPE_SIZE;
>> +  else
>> +#endif
>>count_leading_zeros (count, hi);
>>
>>/* No leading bits means u == minimum.  */
>
> we have:
>
>   /* If there are no high bits set, fall back to one conversion.  */
>   if ((Wtype)u == u)
> return (FSTYPE)(Wtype)u;
>
>   /* Otherwise, find the power of two.  */
>   Wtype hi = u >> W_TYPE_SIZE;
>
> which looks to me like it ensures that hi is != 0.
>

No.  I have been there in the debugger.

But with Wtype = long long
and thus (long long)(2^64-1) = -1LL
and the if is not taken, as (__int128)-1LL != (__int128)(2^64-1).

but 2^64-1 >> 64  =  0.

Now it the BSR instruction is used, with in=out=si,
it is not specified, what will be the result in this case,
on my machine AMD64-someting, it left the si register untouched.
and the function continued, as if count was 63 in that case, but
to be correct, it should be 64.

In the function below we have if ((UWtype)u == u)
that actually ensures hi != 0.


Bernd.

[PATCH] Fix and testcases for pr72747

[Will Schmidt]

Hi,

Per PR72747, A statement such as "v = vec_splats (1);" correctly
initializes a vector.  However, a statement such as "v[1] = v[0] =
vec_splats (1);" initializes both v[1] and v[0] to random garbage.

It has been determined that this is occurring because we did not emit
the actual initialization statement before our final exit from
gimplify_init_constructor, at which time we lose the expression when we
assign *expr_p to either NULL or object.  This problem affected both constant
and non-constant initializers.  Corrected this by moving the logic to
emit the statement up earlier within the if/else logic.

Bootstrapped and make check ran without regressions on
powerpc64le-unknown-linux-gnu.

OK for trunk?

Thanks,
-Will

gcc:
2016-10-26  Will Schmidt 

PR middle-end/72747
* gimplify.c (gimplify_init_constructor): Move emit of constructor
assignment to earlier in the if/else logic.

testsuite:
2016-10-26  Will Schmidt 

PR middle-end/72747
* c-c++-common/pr72747-1.c: New test.
* c-c++-common/pr72747-2.c: Likewise.

Index: gcc/gimplify.c
===
--- gcc/gimplify.c  (revision 241600)
+++ gcc/gimplify.c  (working copy)
@@ -4730,24 +4730,23 @@
 
   if (ret == GS_ERROR)
 return GS_ERROR;
-  else if (want_value)
+  /* If we have gimplified both sides of the initializer but have
+ not emitted an assignment, do so now.  */
+  if (*expr_p)
 {
+  tree lhs = TREE_OPERAND (*expr_p, 0);
+  tree rhs = TREE_OPERAND (*expr_p, 1);
+  gassign *init = gimple_build_assign (lhs, rhs);
+  gimplify_seq_add_stmt (pre_p, init);
+}
+  if (want_value)
+{
   *expr_p = object;
   return GS_OK;
 }
   else
 {
-  /* If we have gimplified both sides of the initializer but have
-not emitted an assignment, do so now.  */
-  if (*expr_p)
-   {
- tree lhs = TREE_OPERAND (*expr_p, 0);
- tree rhs = TREE_OPERAND (*expr_p, 1);
- gassign *init = gimple_build_assign (lhs, rhs);
- gimplify_seq_add_stmt (pre_p, init);
- *expr_p = NULL;
-   }
-
+  *expr_p = NULL;
   return GS_ALL_DONE;
 }
 }
Index: gcc/testsuite/c-c++-common/pr72747-1.c
===
--- gcc/testsuite/c-c++-common/pr72747-1.c  (revision 0)
+++ gcc/testsuite/c-c++-common/pr72747-1.c  (working copy)
@@ -0,0 +1,16 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_altivec_ok } */
+/* { dg-options "-maltivec -fdump-tree-gimple" } */
+
+/* PR 72747: Test that cascaded definition is happening for constant vectors. 
*/
+
+#include 
+
+int main (int argc, char *argv[])
+{
+   __vector int v1,v2;
+   v1 = v2 = vec_splats ((int) 42);
+   return 0;
+}
+/* { dg-final { scan-tree-dump-times " v2 = { 42, 42, 42, 42 }" 1 "gimple" } } 
*/
+
Index: gcc/testsuite/c-c++-common/pr72747-2.c
===
--- gcc/testsuite/c-c++-common/pr72747-2.c  (revision 0)
+++ gcc/testsuite/c-c++-common/pr72747-2.c  (working copy)
@@ -0,0 +1,18 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_altivec_ok } */
+/* { dg-options "-c -maltivec -fdump-tree-gimple" } */
+
+/* PR 72747: test that cascaded definition is happening for non constants. */
+
+void foo ()
+{
+  extern int i;
+  __vector int v,w;
+v = w = (vector int) { i };
+}
+
+int main (int argc, char *argv[])
+{
+  return 0;
+}
+/* { dg-final { scan-tree-dump-times " w = {i.0_1}" 1 "gimple" } } */

Re: [PATCH][AARCH64]Skip gcc.target/aarch64/pr66912.c in tiny or large memory model.

[Andrew Pinski]

On Thu, Oct 27, 2016 at 4:24 AM, Renlin Li  wrote:
> Hi,
>
> On 27/10/16 11:48, Szabolcs Nagy wrote:
>>
>> On 27/10/16 11:25, Renlin Li wrote:
>>>
>>> Hi all,
>>>
>>> This a simple patch to fix gcc.target/aarch64/pr66912.c.
>>> It's a test case only applicable to small memory model which is the
>>> default
>>> one.
>>>
>>
>>/* { dg-final { scan-assembler ":got(page_lo15)?:n_common" } } */
>>
>> i think this is supposed to work on tiny and small model as well.
>> (:got:var vs :gotpage_lo15:var)
>>
> Sorry, I didn't aware it's a regex which will match both.
>
>> it will have to be updated for large model when we have support for that.
>
>
> yes, large memory model will have different relocation for this case, which
> will
> not be caught by this pattern.


It also fails for ILP32.  I have not looked into the assembler output there yet.

Thanks,
Andrew

>
> Regards,
> Renlin
>
>
>>
>>> It has been tested to run only when the memory model is small.
>>> Okay to commit?
>>>
>>> Regards,
>>> Renlin Li
>>>
>>> gcc/testsuite/ChangeLog:
>>>
>>> 2016-10-27  Renlin Li  
>>>
>>>  * gcc.target/aarch64/pr66912.c: Skip tiny and large memory model.
>>
>>
>

[patch] Use straight-line sequence for signed overflow additive operation

[Eric Botcazou]

Hi,

as suggested by Segher, this changes the generic signed-signed-signed case of 
expand_addsub_overflow to using a straight-line code sequence instead of a 
branchy one, the new sequence being also shorter.  On 32-bit PowerPC the code 
generated at -O2 for 32-bit addition and subtraction is:

add 10,3,4
eqv 3,3,4
xor 9,10,4
and. 8,9,3
blt- 0, 

subf 9,4,3
xor 3,3,4
eqv 4,9,4
and. 10,3,4
blt- 0, 

eqv is not(xor) so a typical RISC machine will have 1 more instruction (if it 
doesn't have and(not) like e.g. SPARC).  What's even more interesting is that 
the overflow overhead is constant, e.g. for 64-bit addition and subtraction:

addc 6,4,6
adde 10,3,5
eqv 3,3,5
xor 9,10,5
and. 9,9,3
blt- 0, 

subfc 6,6,4
subfe 10,5,3
xor 3,3,5
eqv 5,10,5
and. 9,3,5
blt- 0, 

so this will also help 32-bit x86, which doesn't implement 64-bit overflow 
operations in the MD file.  There is a fixlet for do_jump_by_parts_greater_rtx 
in the patch too, which forgets to invert the probability of the jump when it 
swaps the arms of the branch.

Tested on x86-64/Linux, PowerPC/Linux and PowerPC64/Linux, OK for mainline?


2016-10-27  Eric Botcazou  
Segher Boessenkool  

* dojump.c (do_jump_by_parts_greater_rtx): Invert probability when
swapping the arms of the branch.
* internal-fn.c (expand_addsub_overflow): Use a straight-line code
sequence for the generic signed-signed-signed case.

-- 
Eric BotcazouIndex: dojump.c
===
--- dojump.c	(revision 241611)
+++ dojump.c	(working copy)
@@ -703,6 +703,7 @@ do_jump_by_parts_greater_rtx (machine_mo
   if_false_label = drop_through_label;
   drop_through_if_true = false;
   drop_through_if_false = true;
+  prob = inv (prob);
 }
 
   /* Compare a word at a time, high order first.  */
Index: internal-fn.c
===
--- internal-fn.c	(revision 241611)
+++ internal-fn.c	(working copy)
@@ -847,56 +847,68 @@ expand_addsub_overflow (location_t loc,
 	delete_insns_since (last);
   }
 
-rtx_code_label *sub_check = gen_label_rtx ();
-int pos_neg = 3;
-
 /* Compute the operation.  On RTL level, the addition is always
unsigned.  */
 res = expand_binop (mode, code == PLUS_EXPR ? add_optab : sub_optab,
 			op0, op1, NULL_RTX, false, OPTAB_LIB_WIDEN);
 
-/* If we can prove one of the arguments (for MINUS_EXPR only
+/* If we can prove that one of the arguments (for MINUS_EXPR only
the second operand, as subtraction is not commutative) is always
non-negative or always negative, we can do just one comparison
-   and conditional jump instead of 2 at runtime, 3 present in the
-   emitted code.  If one of the arguments is CONST_INT, all we
-   need is to make sure it is op1, then the first
-   do_compare_rtx_and_jump will be just folded.  Otherwise try
-   to use range info if available.  */
-if (code == PLUS_EXPR && CONST_INT_P (op0))
-  std::swap (op0, op1);
-else if (CONST_INT_P (op1))
-  ;
-else if (code == PLUS_EXPR && TREE_CODE (arg0) == SSA_NAME)
+   and conditional jump.  */
+int pos_neg = get_range_pos_neg (arg1);
+if (code == PLUS_EXPR)
   {
-pos_neg = get_range_pos_neg (arg0);
-if (pos_neg != 3)
-	  std::swap (op0, op1);
+	int pos_neg0 = get_range_pos_neg (arg0);
+	if (pos_neg0 != 3 && pos_neg == 3)
+	  {
+	std::swap (op0, op1);
+	pos_neg = pos_neg0;
+	  }
   }
-if (pos_neg == 3 && !CONST_INT_P (op1) && TREE_CODE (arg1) == SSA_NAME)
-  pos_neg = get_range_pos_neg (arg1);
-
-/* If the op1 is negative, we have to use a different check.  */
-if (pos_neg == 3)
-  do_compare_rtx_and_jump (op1, const0_rtx, LT, false, mode, NULL_RTX,
-			   NULL, sub_check, PROB_EVEN);
-
-/* Compare the result of the operation with one of the operands.  */
-if (pos_neg & 1)
-  do_compare_rtx_and_jump (res, op0, code == PLUS_EXPR ? GE : LE,
-			   false, mode, NULL_RTX, NULL, done_label,
-			   PROB_VERY_LIKELY);
 
-/* If we get here, we have to print the error.  */
+/* Addition overflows if and only if the two operands have the same sign,
+   and the result has the opposite sign.  Subtraction overflows if and
+   only if the two operands have opposite sign, and the subtrahend has
+   the same sign as the result.  Here 0 is counted as positive.  */
 if (pos_neg == 3)
   {
-	emit_jump (do_error);
-	emit_label (sub_check);
+	/* Compute op0 ^ op1 (operands have opposite sign).  */
+rtx op_xor = expand_binop (mode, xor_optab, op0, op1, NULL_RTX, false,
+   OPTAB_LIB_WIDEN);
+
+	/* Compute res ^ op1 (result 

Re: [PATCH] Fix host_size_t_cst_p predicate

[Martin Liška]

On 10/27/2016 03:35 PM, Richard Biener wrote:
> On Thu, Oct 27, 2016 at 9:41 AM, Martin Liška  wrote:
>> Running simple test-case w/o the proper header file causes ICE:
>> strncmp ("a", "b", -1);
>>
>> 0xe74462 tree_to_uhwi(tree_node const*)
>> ../../gcc/tree.c:7324
>> 0x90a23f host_size_t_cst_p
>> ../../gcc/fold-const-call.c:63
>> 0x90a23f fold_const_call(combined_fn, tree_node*, tree_node*, tree_node*, 
>> tree_node*)
>> ../../gcc/fold-const-call.c:1512
>> 0x787b01 fold_builtin_3
>> ../../gcc/builtins.c:8385
>> 0x787b01 fold_builtin_n(unsigned int, tree_node*, tree_node**, int, bool)
>> ../../gcc/builtins.c:8465
>> 0x9052b1 fold(tree_node*)
>> ../../gcc/fold-const.c:11919
>> 0x6de2bb c_fully_fold_internal
>> ../../gcc/c/c-fold.c:185
>> 0x6e1f6b c_fully_fold(tree_node*, bool, bool*)
>> ../../gcc/c/c-fold.c:90
>> 0x67cbbf c_process_expr_stmt(unsigned int, tree_node*)
>> ../../gcc/c/c-typeck.c:10369
>> 0x67cfbd c_finish_expr_stmt(unsigned int, tree_node*)
>> ../../gcc/c/c-typeck.c:10414
>> 0x6cb578 c_parser_statement_after_labels
>> ../../gcc/c/c-parser.c:5430
>> 0x6cd333 c_parser_compound_statement_nostart
>> ../../gcc/c/c-parser.c:4944
>> 0x6cdbde c_parser_compound_statement
>> ../../gcc/c/c-parser.c:4777
>> 0x6c93ac c_parser_declaration_or_fndef
>> ../../gcc/c/c-parser.c:2176
>> 0x6d51ab c_parser_external_declaration
>> ../../gcc/c/c-parser.c:1574
>> 0x6d5c09 c_parser_translation_unit
>> ../../gcc/c/c-parser.c:1454
>> 0x6d5c09 c_parse_file()
>> ../../gcc/c/c-parser.c:18173
>> 0x72ffd2 c_common_parse_file()
>> ../../gcc/c-family/c-opts.c:1087
>>
>> Following patch improves the host_size_t_cst_p predicate.
>>
>> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
>>
>> Ready to be installed?
> 
> I believe the wi::min_precision (t, UNSIGNED) <= sizeof (size_t) *
> CHAR_BIT test is now redundant.
> 
> OTOH it was probably desired to allow -1 here?  A little looking back
> in time should tell.

Ok, it started with r229922, where it was changed from:

  if (tree_fits_uhwi_p (len) && p1 && p2)
{
  const int i = strncmp (p1, p2, tree_to_uhwi (len));
...

to current version:

case CFN_BUILT_IN_STRNCMP:
  {
bool const_size_p = host_size_t_cst_p (arg2, );

Thus I'm suggesting to change to back to it.

Ready to be installed?
Thanks,
Martin

> 
> Richard.
> 
>> Martin

>From 608ed3ac6b743846e9bce62cd0b0e83e2b018684 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Wed, 26 Oct 2016 13:48:39 +0200
Subject: [PATCH] Fix host_size_t_cst_p predicat

gcc/ChangeLog:

2016-10-26  Martin Liska  

	* fold-const-call.c (host_size_t_cst_p): Test whether
	it can fit to uhwi.

gcc/testsuite/ChangeLog:

2016-10-26  Martin Liska  

	* gcc.dg/tree-ssa/builtins-folding-gimple-ub.c (main): Add
	test case.
---
 gcc/fold-const-call.c  | 3 +--
 gcc/testsuite/gcc.dg/tree-ssa/builtins-folding-gimple-ub.c | 4 
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/gcc/fold-const-call.c b/gcc/fold-const-call.c
index 05a15f9..b8154c8 100644
--- a/gcc/fold-const-call.c
+++ b/gcc/fold-const-call.c
@@ -57,8 +57,7 @@ complex_cst_p (tree t)
 static inline bool
 host_size_t_cst_p (tree t, size_t *size_out)
 {
-  if (integer_cst_p (t)
-  && wi::min_precision (t, UNSIGNED) <= sizeof (size_t) * CHAR_BIT)
+  if (tree_fits_uhwi_p (t))
 {
   *size_out = tree_to_uhwi (t);
   return true;
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/builtins-folding-gimple-ub.c b/gcc/testsuite/gcc.dg/tree-ssa/builtins-folding-gimple-ub.c
index df0ede2..e1658d1 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/builtins-folding-gimple-ub.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/builtins-folding-gimple-ub.c
@@ -17,6 +17,10 @@ main (void)
   if (__builtin_memchr (foo1, 'x', 1000)) /* Not folded away.  */
 __builtin_abort ();
 
+  /* STRNCMP.  */
+  if (strncmp ("a", "b", -1)) /* { dg-warning "implicit declaration of function" } */
+__builtin_abort ();
+
   return 0;
 }
 
-- 
2.10.1

Re: [RFC] Handle unary pass-through jump functions for ipa-vrp

[Jan Hubicka]

> gcc/testsuite/ChangeLog:
> 
> 2016-10-25  Kugan Vivekanandarajah  
> 
>   * gcc.dg/ipa/vrp7.c: New test.
> 
> 
> gcc/ChangeLog:
> 
> 2016-10-25  Kugan Vivekanandarajah  
> 
>   * ipa-cp.c (ipa_get_jf_pass_through_result): Skip unary expressions.
>   (propagate_vr_accross_jump_function): Handle unary expressions.
>   (propagate_constants_accross_call): Pass param type to
>   propagate_vr_accross_jump_function.
>   * ipa-prop.c (load_from_param): Renamed from load_from_unmodified_param.
>   Also handles unary expr.
>   (ipa_set_jf_unary_pass_through): New.
>   (ipa_load_from_parm_agg): Renamed load_from_unmodified_param.
>   (compute_complex_assign_jump_func): Handle unary expressions.
>   (ipa_write_jump_function): Likewise.
>   (ipa_read_jump_function): Likewise.
>   * ipa-prop.h: export ipa_get_callee_param_type.

> diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
> index 1dc5cb6..d0dc3d7 100644
> --- a/gcc/ipa-cp.c
> +++ b/gcc/ipa-cp.c
> @@ -122,6 +122,7 @@ along with GCC; see the file COPYING3.  If not see
>  #include "ipa-inline.h"
>  #include "ipa-utils.h"
>  #include "tree-ssa-ccp.h"
> +#include "gimple.h"
>  
>  template  class ipcp_value;
>  
> @@ -1221,7 +1222,12 @@ ipa_get_jf_pass_through_result (struct ipa_jump_func 
> *jfunc, tree input)
>  
>if (ipa_get_jf_pass_through_operation (jfunc) == NOP_EXPR)
>  return input;
> -  if (!is_gimple_ip_invariant (input))
> +
> +  if (!is_gimple_ip_invariant (input)
> +  /* TODO: Unary expressions are not handles in ipa constant
> +  propagation. */

handled.
I would expect them to be already folded here?  I would expect that hanlding
unary expressions in constant propagation is no harder than for VRP?

> + || (TREE_CODE_CLASS (ipa_get_jf_pass_through_operation (jfunc))
> +   == tcc_unary))
>  return NULL_TREE;
>  
>if (TREE_CODE_CLASS (ipa_get_jf_pass_through_operation (jfunc))
> @@ -1845,7 +1851,8 @@ propagate_bits_accross_jump_function (cgraph_edge *cs, 
> int idx, ipa_jump_func *j
>  static bool
>  propagate_vr_accross_jump_function (cgraph_edge *cs,
>   ipa_jump_func *jfunc,
> - struct ipcp_param_lattices *dest_plats)
> + struct ipcp_param_lattices *dest_plats,
> + tree param_type)

New param needs comment.

Patch is OK with changes Martin suggested.

Honza

Re: [SPARC] Housekeeping work

[Eric Botcazou]

> it seems your patch introduced a considerable number of regressions
> (found on sparc-sun-solaris2.12 with /bin/as): the first mail-report.log
> is from r241560 with just your patch reverted, the second from that rev
> as is:

Ouch, it's a single '*' probably added very late in the game...  Testing in 
progress on SPARC/Solaris, will commit once done.  Thanks for the heads up.


* config/sparc/sparc.md (<*vlop:code>3): Remove leading '*'.

-- 
Eric BotcazouIndex: config/sparc/sparc.md
===
--- config/sparc/sparc.md	(revision 241611)
+++ config/sparc/sparc.md	(working copy)
@@ -8726,7 +8726,7 @@ (define_code_iterator vlop [ior and xor]
 (define_code_attr vlinsn [(ior "or") (and "and") (xor "xor")])
 (define_code_attr vlninsn [(ior "nor") (and "nand") (xor "xnor")])
 
-(define_insn "*3"
+(define_insn "3"
   [(set (match_operand:VL 0 "register_operand" "=")
 	(vlop:VL (match_operand:VL 1 "register_operand" "")
 		 (match_operand:VL 2 "register_operand" "")))]

Re: [PATCH, RFC] Introduce -fsanitize=use-after-scope (v2)

[Martin Liška]

On 10/21/2016 04:26 PM, Jakub Jelinek wrote:
> On Wed, Oct 12, 2016 at 04:07:53PM +0200, Martin Liška wrote:
>>> Ok, first let me list some needed follow-ups that don't need to be handled
>>> right away:
>>> - r237814-like changes for ASAN_MARK

I've spent quite some on that and that's what I begin 
(use-after-scope-addressable.patch).
Problem is that as I ignore all ASAN_MARK internal fns, the code does not 
detect having address
taken in:

_2 = MEM[(char *)_char + 8B];

  char *ptr;
  {
char my_char[9];
ptr = _char[0];
  }

  return *(ptr+8);

and thus the code in tree-ssa.c (maybe_optimize_var) sets TREE_ADDRESSABLE 
(var) = 0.

Second question I have is whether we want to handle just TREE_ADDRESSABLE stuff 
during gimplification?
Basically in a way that the current patch is doing?

>>
>> Yes, that's missing. I'm wondering whether the same approach would be viable 
>> as
>> the {un}poisoning happens during gimplification. Thus it generates  
>> expressions
>> which verifier won't be happy about?
> 
> Sure, it uses   The trick is that the addressable sub-pass then ignores
> the taking of the address just in ASAN_MARK, and if some var is determined
> to be addressable solely because of ASAN_MARK  uses and no other reason,
> the ASAN_MARK would be dropped and variable rewritten into SSA form.
> 
>>> - optimization to remove ASAN_MARK unpoisoning at the start of the function
>>
>> As current implementation does not poison variables at the very beginning of
>> a functions (RTL stack frame emission), it won't be needed.
> 
> But you still ASAN_MARK unpoison the vars when they get into scope, right?
> And those can be removed if the optimizers could prove that the area has not
> been poisoned yet since the beginning of the function.
> 
>>> - optimization to remove ASAN_MARK poisoning at the end of function (and
>>>   remove epilogue unpoisoning)
>>> - optimization to remove ASAN_MARK unpoisoning followed by ASAN_MARK 
>>> poisoning
>>>   or vice versa if there are no memory accesses in between
>>
>> Yep, both are not handled and are very similar from my perspective: pairing
>> poisoning and unpoisoning pair which are not interfered by a memory operation
>> in between (in dominator meaning of word).
>> I'm wondering whether can be done effectively as we would need to visit all 
>> BBs
>> in a dominance domain (get_all_dominated_blocks) and check for the memory 
>> operations.
>> One improvement can be set of BBs that do not have any memory operations 
>> (excluding
>> ASAN_CHECK, ASAN_MARK builtins), but it can be still expensive to simplify 
>> poisoning
>> for all local variables. Or am I wrong?
> 
> My memory is weak, but isn't this something the sanopt pass
> (sanopt_optimize) is already doing similarly for e.g. ASAN_CHECK, UBSAN_NULL
> and UBSAN_VPTR checks?  For ASAN_MARK, you actually don't care about any
> calls, those shouldn't unpoison or poison again the vars under compiler's
> back.
> 
>>> - try to improve the goto handling
>>
>> Works for me to be target for stage3.
> 
> Sure.
> 
>> 2016-09-27  Martin Liska  
> 
> Likely newer date :)
> 
>>  * c-common.c (warn_for_unused_label): Save all labels used
>>  in goto or in 
> 
> 
> instead?
> 
>> +  if (dump_file && (dump_flags & TDF_DETAILS))
>> +{
>> +  const char *n = DECL_NAME (decl)
>> +? IDENTIFIER_POINTER (DECL_NAME (decl)) : "";
> 
> Bad formatting.
> 
> const char *n = (DECL_NAME (decl)
>  ? IDENTIFIER_POINTER (DECL_NAME (decl))
>  : "");
> or
> const char *n
>   = (DECL_NAME (decl)
>  ? IDENTIFIER_POINTER (DECL_NAME (decl)) : "");
> 
>>  /* Return true if DECL should be guarded on the stack.  */
>>  
>>  static inline bool
>>  asan_protect_stack_decl (tree decl)
>>  {
>> -  return DECL_P (decl) && !DECL_ARTIFICIAL (decl);
>> +  return DECL_P (decl) && TREE_ADDRESSABLE (decl);
>>  }
> 
> Can you explain this change?  It won't affect just
> -fsanitize-use-after-scope, and goes in both directions, adds some
> decls that weren't previously protected and removes others that were
> previously protected.
> 
> Is the removal of !DECL_ARTIFICIAL so that you can use-after-scope
> verify the C++ TARGET_EXPR temporaries?  Do we need to stack protect
> those even for -fno-sanitize-use-after-scope?
> I'm not 100% sure if we keep TREE_ADDRESSABLE meaningful for variables that
> need to live in memory for other reasons until expansion.


Yes, it's connected to C++ temporaries that are DECL_ARTIFICIAL.

> 
> So, I wonder if we don't want && (TREE_ADDRESSABLE (decl) || !DECL_ARTIFICAL 
> (decl))
> or just DECL_P (decl); or conditionalize something on
> -fsanitize-use-after-scope.  Perhaps the change is good as is, just want to
> point out that it affects also other -fsanitize=address modes in both
> ways (instruments something that hasn't been before, 

[PATCH] PR70975 Pass valid offset argument to sendfile

[Jonathan Wakely]

This fixes a FAIL on Solaris, due to a difference between the GNU and
Solaris versions of sendfile(2).

2016-10-27  Uros Bizjak  

PR libstdc++/70975
* src/filesystem/ops.cc (do_copy_file): Pass non-null pointer to
sendfile for offset argument.

Tested powerpc64le-linux, committed to trunk.

commit 27d5ce18d1d752dafb757ba31948aa1bb32cf122
Author: Jonathan Wakely 
Date:   Thu Oct 27 15:23:10 2016 +0100

PR70975 Pass valid offset argument to sendfile

2016-10-27  Uros Bizjak  

PR libstdc++/70975
* src/filesystem/ops.cc (do_copy_file): Pass non-null pointer to
sendfile for offset argument.

diff --git a/libstdc++-v3/src/filesystem/ops.cc 
b/libstdc++-v3/src/filesystem/ops.cc
index 9abcee0..8ed0a10 100644
--- a/libstdc++-v3/src/filesystem/ops.cc
+++ b/libstdc++-v3/src/filesystem/ops.cc
@@ -444,7 +444,8 @@ namespace
   }
 
 #ifdef _GLIBCXX_USE_SENDFILE
-const auto n = ::sendfile(out.fd, in.fd, nullptr, from_st->st_size);
+off_t offset = 0;
+const auto n = ::sendfile(out.fd, in.fd, , from_st->st_size);
 if (n < 0 && (errno == ENOSYS || errno == EINVAL))
   {
 #endif

Re: [PATCH GCC][2/4]Simplify (cond (cmp (convert (x), c1), x, c2)) into (minmax (x, c))

[Bin.Cheng]

On Thu, Oct 27, 2016 at 2:58 PM, Richard Biener
 wrote:
> On Tue, Oct 25, 2016 at 1:21 PM, Bin Cheng  wrote:
>> Hi,
>> Second patch optimizing (cond (cmp (convert (x), c1), x, c2)) into (minmax 
>> (x, c)).  As commented in patch, this is done if:
>>
>> + 1) Comparison's operands are promoted from smaller type.
>> + 2) Const c1 equals to c2 after canonicalizing comparison.
>> + 3) Comparison has tree code LT, LE, GT or GE.
>> +This specific pattern is needed when (cmp (convert x) c) may not
>> +be simplified by comparison patterns because of multiple uses of
>> +x.  It also makes sense here because simplifying across multiple
>> +referred var is always benefitial for complicated cases.
>>
>> It also adds call to fold_stmt in tree-if-conv.c so that generated cond_expr 
>> statement has its chance to be simplified.
>
> So this sounds like the fold-const.c code.  Why only for GIMPLE btw?
> Thus, can you make sure you covered
> all cases fold-const.c did and remove the corresponding code there?
Hmm, no, this patch only adds simplification which is not done by GCC
at the moment.  I didn't look into existing simplification from
fold-const.c when writing this one, however, I will look into it see
if it can be moved to match.pd, either along with this pattern or as a
separated ones.

Thanks,
bin
>
> Thanks,
> Richard.
>
>> Bootstrap and test on x86_64 and AArch64.  It introduces below failure on 
>> both x86_64 and AArch64:
>> FAIL: gcc.dg/vect/slp-cond-3.c
>> I believe it reveals defect in vect-slp.  In call to fold_stmt in ifcvt, 
>> canonicalization transforms _145 = _95 <= _96 ? _149 : _147 into _145 = _95 
>> > _96 ? _147 : _149.  As a result, this stmt has different code to the first 
>> one of SLP instance.  IMO, SLP should be improved to handle operands 
>> swapping, apparently, current support is not OK.
>>
>> It also introduces more failures on AArch64(probably other targets) as below:
>> FAIL: gcc.dg/vect/pr65947-1.c -flto -ffat-lto-objects  scan-tree-dump-times 
>> vect "LOOP VECTORIZED" 2
>> FAIL: gcc.dg/vect/pr65947-1.c -flto -ffat-lto-objects  scan-tree-dump-times 
>> vect "condition expression based on integer induction." 4
>> FAIL: gcc.dg/vect/pr65947-1.c scan-tree-dump-times vect "LOOP VECTORIZED" 2
>> FAIL: gcc.dg/vect/pr65947-1.c scan-tree-dump-times vect "condition 
>> expression based on integer induction." 4
>> FAIL: gcc.dg/vect/pr65947-13.c -flto -ffat-lto-objects  scan-tree-dump-times 
>> vect "LOOP VECTORIZED" 2
>> FAIL: gcc.dg/vect/pr65947-13.c scan-tree-dump-times vect "LOOP VECTORIZED" 2
>> FAIL: gcc.dg/vect/pr65947-4.c -flto -ffat-lto-objects  scan-tree-dump-times 
>> vect "LOOP VECTORIZED" 2
>> FAIL: gcc.dg/vect/pr65947-4.c -flto -ffat-lto-objects  scan-tree-dump-times 
>> vect "condition expression based on integer induction." 4
>> FAIL: gcc.dg/vect/pr65947-4.c scan-tree-dump-times vect "LOOP VECTORIZED" 2
>> FAIL: gcc.dg/vect/pr65947-4.c scan-tree-dump-times vect "condition 
>> expression based on integer induction." 4
>> FAIL: gcc.dg/vect/pr77503.c -flto -ffat-lto-objects  scan-tree-dump vect 
>> "vectorized 1 loops"
>> FAIL: gcc.dg/vect/pr77503.c scan-tree-dump vect "vectorized 1 loops"
>> FAIL: gcc.dg/vect/vect-pr69848.c -flto -ffat-lto-objects  scan-tree-dump 
>> vect "vectorized 1 loops"
>> FAIL: gcc.dg/vect/vect-pr69848.c scan-tree-dump vect "vectorized 1 loops"
>> Again, these failures reveal a defect in vectorizer that operand swapping is 
>> not supported for COND_REDUCTION.
>>
>> I will send another two patches independent to this patch set resolving 
>> these failures.  Is this OK?
>>
>> Thanks,
>> bin
>>
>> 2016-10-21  Bin Cheng  
>>
>> * tree-if-conv.c (ifcvt_follow_ssa_use_edges): New func.
>> (predicate_scalar_phi): Call fold_stmt using the new valueize func.
>> * match.pd ((cond (cmp (convert (x), c1), x, c2)) -> (minmax (x, 
>> c))):
>> New pattern.
>>
>> gcc/testsuite/ChangeLog
>> 2016-10-21  Bin Cheng  
>>
>> * gcc.dg/fold-condcmpconv-1.c: New test.
>> * gcc.dg/fold-condcmpconv-2.c: New test.

Re: [PATCH, GCC/ARM 1/2, ping] Add multilib support for embedded bare-metal targets

[Thomas Preudhomme]

Hi Kyrill,

On 27/10/16 10:45, Kyrill Tkachov wrote:

Hi Thomas,

On 24/10/16 09:06, Thomas Preudhomme wrote:

Ping?

Best regards,

Thomas

On 13/10/16 16:35, Thomas Preudhomme wrote:

Hi ARM maintainers,

This patchset aims at adding multilib support for R and M profile ARM
architectures and allowing it to be built alongside multilib for A profile ARM
architectures. This specific patch adds the t-rmprofile multilib Makefile
fragment for the former objective. Multilib are built for all M profile
architecture involved: ARMv6S-M, ARMv7-M and ARMv7E-M as well as ARMv7. ARMv7
multilib is used for R profile architectures but also A profile architectures.

ChangeLog entry is as follows:


*** gcc/ChangeLog ***

2016-10-03  Thomas Preud'homme 

* config.gcc: Allow new rmprofile value for configure option
--with-multilib-list.
* config/arm/t-rmprofile: New file.
* doc/install.texi (--with-multilib-list): Document new rmprofile value
for ARM.


Testing:

== aprofile ==
* "tree install/lib/gcc/arm-none-eabi/7.0.0" is the same before and after the
patchset for both aprofile and rmprofile
* default spec (gcc -dumpspecs) is the same before and after the patchset for
aprofile
* No difference in --print-multi-directory between before and after the patchset
for aprofile for all combination of ISA (ARM/Thumb), architecture, CPU, FPU and
float ABI

== rmprofile ==
* aprofile and rmprofile use similar directory structure (ISA/arch/FPU/float
ABI) and directory naming
* Difference in --print-multi-directory between before [1] and after the
patchset for rmprofile for all combination of ISA (ARM/Thumb), architecture,
CPU, FPU and float ABI modulo the name and directory structure changes

[1] as per patch applied in ARM embedded branches
https://gcc.gnu.org/viewcvs/gcc/branches/ARM/embedded-5-branch/gcc/config/arm/t-baremetal?view=markup



== aprofile + rmprofile ==
* aprofile,rmprofile and rmprofile,aprofile builds give an error saying it is
not supported


Is this ok for master branch?

Best regards,

Thomas


+# Arch Matches
+MULTILIB_MATCHES   += march?armv6s-m=march?armv6-m
+MULTILIB_MATCHES   += march?armv8-m.main=march?armv8-m.main+dsp
+MULTILIB_MATCHES   += march?armv7=march?armv7-r
+ifeq (,$(HAS_APROFILE))
+MULTILIB_MATCHES   += march?armv7=march?armv7-a
+MULTILIB_MATCHES   += march?armv7=march?armv7ve
+MULTILIB_MATCHES   += march?armv7=march?armv8-a
+MULTILIB_MATCHES   += march?armv7=march?armv8-a+crc
+MULTILIB_MATCHES   += march?armv7=march?armv8.1-a
+MULTILIB_MATCHES   += march?armv7=march?armv8.1-a+crc
+endif

I think you want to update the patch to handle -march=armv8.2-a and 
armv8.2-a+fp16
Thanks,
Kyrill


Indeed. Please find updated ChangeLog and patch (attached):

*** gcc/ChangeLog ***

2016-10-03  Thomas Preud'homme  

* config.gcc: Allow new rmprofile value for configure option
--with-multilib-list.
* config/arm/t-rmprofile: New file.
* doc/install.texi (--with-multilib-list): Document new rmprofile value
for ARM.

Ok for trunk?

Best regards,

Thomas
diff --git a/gcc/config.gcc b/gcc/config.gcc
index d956da22ad60abfe9c6b4be0882f9e7dd64ac39f..15b662ad5449f8b91eb760b7fbe45f33d8cecb4b 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -3739,6 +3739,16 @@ case "${target}" in
 # pragmatic.
 tmake_profile_file="arm/t-aprofile"
 ;;
+			rmprofile)
+# Note that arm/t-rmprofile is a
+# stand-alone make file fragment to be
+# used only with itself.  We do not
+# specifically use the
+# TM_MULTILIB_OPTION framework because
+# this shorthand is more
+# pragmatic.
+tmake_profile_file="arm/t-rmprofile"
+;;
 			default)
 ;;
 			*)
@@ -3748,9 +3758,10 @@ case "${target}" in
 			esac
 
 			if test "x${tmake_profile_file}" != x ; then
-# arm/t-aprofile is only designed to work
-# without any with-cpu, with-arch, with-mode,
-# with-fpu or with-float options.
+# arm/t-aprofile and arm/t-rmprofile are only
+# designed to work without any with-cpu,
+# with-arch, with-mode, with-fpu or with-float
+# options.
 if test "x$with_arch" != x \
 || test "x$with_cpu" != x \
 || test "x$with_float" != x \
diff --git a/gcc/config/arm/t-rmprofile b/gcc/config/arm/t-rmprofile
new file mode 100644
index ..c8b5c9cbd03694eea69855e20372afa3e97d6b4c
--- /dev/null
+++ b/gcc/config/arm/t-rmprofile
@@ -0,0 +1,174 @@
+# Copyright (C) 2016 Free Software Foundation, Inc.
+#
+# This file is part of GCC.
+#
+# GCC is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3, or (at your option)
+# any later version.
+#
+# GCC is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied 

Re: [PATCH, Fortran] DEC Compatibility: New I/O Specifiers CARRIAGECONTROL, READONLY, SHARE with -fdec

[Jakub Jelinek]

On Thu, Oct 27, 2016 at 09:12:42AM -0400, Fritz Reese wrote:
> On Thu, Oct 27, 2016 at 8:52 AM, Jakub Jelinek  wrote:
> > On Thu, Oct 27, 2016 at 08:49:42AM -0400, Fritz Reese wrote:
> >>
> >> Do you know if there is there any way from DG to verify that a runtime
> >> warning is emitted?
> >
> > Use dg-output for that.  And, if the test is supposed to exit with non-zero
> > exit status because of the runtime error, then also dg-shouldfail.
> >
> > Jakub
> 
> Thanks. I could never find good documentation on the various dg-*
> testing options. I was browsing other test files to figure out how to
> express dec_io_5 and dec_io_6. I first saw "XFAIL", I assumed it meant
> "eXpected FAIL", and used it since I "expected" dec_io_5 to "fail" at
> runtime. I was only half-right...
> 
> The attached should be correct now
> 
> ---
> Fritz Reese.
> 
> From: Fritz Reese 
> Date: Thu, 27 Oct 2016 08:46:33 -0400
> Subject: [PATCH] Fix some DEC I/O testcases.
> 
> gcc/testsuite/gfortran.dg/
> * dec_io_5.f90, dec_io_6.f90: Don't use "test.txt", and use
> dg-shouldfail/dg-output instead of XFAIL.

LGTM.

Jakub

Re: [PATCH GCC][2/4]Simplify (cond (cmp (convert (x), c1), x, c2)) into (minmax (x, c))

[Richard Biener]

On Tue, Oct 25, 2016 at 1:21 PM, Bin Cheng  wrote:
> Hi,
> Second patch optimizing (cond (cmp (convert (x), c1), x, c2)) into (minmax 
> (x, c)).  As commented in patch, this is done if:
>
> + 1) Comparison's operands are promoted from smaller type.
> + 2) Const c1 equals to c2 after canonicalizing comparison.
> + 3) Comparison has tree code LT, LE, GT or GE.
> +This specific pattern is needed when (cmp (convert x) c) may not
> +be simplified by comparison patterns because of multiple uses of
> +x.  It also makes sense here because simplifying across multiple
> +referred var is always benefitial for complicated cases.
>
> It also adds call to fold_stmt in tree-if-conv.c so that generated cond_expr 
> statement has its chance to be simplified.

So this sounds like the fold-const.c code.  Why only for GIMPLE btw?
Thus, can you make sure you covered
all cases fold-const.c did and remove the corresponding code there?

Thanks,
Richard.

> Bootstrap and test on x86_64 and AArch64.  It introduces below failure on 
> both x86_64 and AArch64:
> FAIL: gcc.dg/vect/slp-cond-3.c
> I believe it reveals defect in vect-slp.  In call to fold_stmt in ifcvt, 
> canonicalization transforms _145 = _95 <= _96 ? _149 : _147 into _145 = _95 > 
> _96 ? _147 : _149.  As a result, this stmt has different code to the first 
> one of SLP instance.  IMO, SLP should be improved to handle operands 
> swapping, apparently, current support is not OK.
>
> It also introduces more failures on AArch64(probably other targets) as below:
> FAIL: gcc.dg/vect/pr65947-1.c -flto -ffat-lto-objects  scan-tree-dump-times 
> vect "LOOP VECTORIZED" 2
> FAIL: gcc.dg/vect/pr65947-1.c -flto -ffat-lto-objects  scan-tree-dump-times 
> vect "condition expression based on integer induction." 4
> FAIL: gcc.dg/vect/pr65947-1.c scan-tree-dump-times vect "LOOP VECTORIZED" 2
> FAIL: gcc.dg/vect/pr65947-1.c scan-tree-dump-times vect "condition expression 
> based on integer induction." 4
> FAIL: gcc.dg/vect/pr65947-13.c -flto -ffat-lto-objects  scan-tree-dump-times 
> vect "LOOP VECTORIZED" 2
> FAIL: gcc.dg/vect/pr65947-13.c scan-tree-dump-times vect "LOOP VECTORIZED" 2
> FAIL: gcc.dg/vect/pr65947-4.c -flto -ffat-lto-objects  scan-tree-dump-times 
> vect "LOOP VECTORIZED" 2
> FAIL: gcc.dg/vect/pr65947-4.c -flto -ffat-lto-objects  scan-tree-dump-times 
> vect "condition expression based on integer induction." 4
> FAIL: gcc.dg/vect/pr65947-4.c scan-tree-dump-times vect "LOOP VECTORIZED" 2
> FAIL: gcc.dg/vect/pr65947-4.c scan-tree-dump-times vect "condition expression 
> based on integer induction." 4
> FAIL: gcc.dg/vect/pr77503.c -flto -ffat-lto-objects  scan-tree-dump vect 
> "vectorized 1 loops"
> FAIL: gcc.dg/vect/pr77503.c scan-tree-dump vect "vectorized 1 loops"
> FAIL: gcc.dg/vect/vect-pr69848.c -flto -ffat-lto-objects  scan-tree-dump vect 
> "vectorized 1 loops"
> FAIL: gcc.dg/vect/vect-pr69848.c scan-tree-dump vect "vectorized 1 loops"
> Again, these failures reveal a defect in vectorizer that operand swapping is 
> not supported for COND_REDUCTION.
>
> I will send another two patches independent to this patch set resolving these 
> failures.  Is this OK?
>
> Thanks,
> bin
>
> 2016-10-21  Bin Cheng  
>
> * tree-if-conv.c (ifcvt_follow_ssa_use_edges): New func.
> (predicate_scalar_phi): Call fold_stmt using the new valueize func.
> * match.pd ((cond (cmp (convert (x), c1), x, c2)) -> (minmax (x, c))):
> New pattern.
>
> gcc/testsuite/ChangeLog
> 2016-10-21  Bin Cheng  
>
> * gcc.dg/fold-condcmpconv-1.c: New test.
> * gcc.dg/fold-condcmpconv-2.c: New test.

Re: [PATCH] Fix dwarf2out regression from C++17 inline variables changes

[Jason Merrill]

OK.

On Tue, Oct 25, 2016 at 3:56 PM, Jakub Jelinek  wrote:
> On Tue, Oct 25, 2016 at 08:06:12PM +0200, Jakub Jelinek wrote:
>> I think this patch should fix it, will bootstrap/regtest it now:
>>
>> 2016-10-25  Jakub Jelinek  
>>
>>   * dwarf2out.c (gen_member_die): Only reparent_child instead of
>>   splice_child_die if child doesn't have DW_AT_specification attribute.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux now, with this
> patch C++14 static data members are treated in debug info as they were in
> the past, just C++17 static constexpr data mambers or other static inline
> data members are treated the new way (definition in DW_TAG_member).
>
> Ok for trunk?
>
>> --- gcc/dwarf2out.c.jj2016-10-25 19:49:28.0 +0200
>> +++ gcc/dwarf2out.c   2016-10-25 20:02:33.264639847 +0200
>> @@ -22624,7 +22624,8 @@ gen_member_die (tree type, dw_die_ref co
>> /* Handle inline static data members, which only have in-class
>>declarations.  */
>> if (child->die_tag == DW_TAG_variable
>> -   && child->die_parent == comp_unit_die ())
>> +   && child->die_parent == comp_unit_die ()
>> +   && get_AT (child, DW_AT_specification) == NULL)
>>   {
>> reparent_child (child, context_die);
>> child->die_tag = DW_TAG_member;
>>
>
> Jakub

Re: Add uniform_inside_sphere_distribution

[Jonathan Wakely]

On 27/10/16 15:33 +0200, Andreas Schwab wrote:

On Okt 26 2016, Jonathan Wakely  wrote:


In all the new tests please replace this dg-options directive with:

 { dg-do run { target cxx11 } }


ERROR: ext/random/uniform_inside_sphere_distribution/cons/default.cc: syntax error in target 
selector "target cxx11" for " dg-do 1 run { target cxx11 } "


My fault, it should be { target c++11 } not { target cxx11 }.

Testing this, will commit shortly.


commit 9fdf7cdb6b00c6d962959c27a057beb91e23b219
Author: Jonathan Wakely 
Date:   Thu Oct 27 14:54:13 2016 +0100

Fix target selectors in uniform_inside_sphere_distribution tests

	* testsuite/ext/random/uniform_inside_sphere_distribution/cons/
	default.cc: Fix effective target selector.
	* testsuite/ext/random/uniform_inside_sphere_distribution/cons/
	parms.cc: Likewise.
	* testsuite/ext/random/uniform_inside_sphere_distribution/operators/
	equal.cc: Likewise.
	* testsuite/ext/random/uniform_inside_sphere_distribution/operators/
	generate.cc: Likewise.
	* testsuite/ext/random/uniform_inside_sphere_distribution/operators/
	inequal.cc: Likewise.
	* testsuite/ext/random/uniform_inside_sphere_distribution/operators/
	serialize.cc: Likewise.

diff --git a/libstdc++-v3/testsuite/ext/random/uniform_inside_sphere_distribution/cons/default.cc b/libstdc++-v3/testsuite/ext/random/uniform_inside_sphere_distribution/cons/default.cc
index 79ae488..ff5bcb3 100644
--- a/libstdc++-v3/testsuite/ext/random/uniform_inside_sphere_distribution/cons/default.cc
+++ b/libstdc++-v3/testsuite/ext/random/uniform_inside_sphere_distribution/cons/default.cc
@@ -1,4 +1,4 @@
-// { dg-do run { target cxx11 } }
+// { dg-do run { target c++11 } }
 // { dg-require-cstdint "" }
 //
 // Copyright (C) 2014-2016 Free Software Foundation, Inc.
diff --git a/libstdc++-v3/testsuite/ext/random/uniform_inside_sphere_distribution/cons/parms.cc b/libstdc++-v3/testsuite/ext/random/uniform_inside_sphere_distribution/cons/parms.cc
index 924b997..6a6ea2c 100644
--- a/libstdc++-v3/testsuite/ext/random/uniform_inside_sphere_distribution/cons/parms.cc
+++ b/libstdc++-v3/testsuite/ext/random/uniform_inside_sphere_distribution/cons/parms.cc
@@ -1,4 +1,4 @@
-// { dg-do run { target cxx11 } }
+// { dg-do run { target c++11 } }
 // { dg-require-cstdint "" }
 //
 // Copyright (C) 2014-2016 Free Software Foundation, Inc.
diff --git a/libstdc++-v3/testsuite/ext/random/uniform_inside_sphere_distribution/operators/equal.cc b/libstdc++-v3/testsuite/ext/random/uniform_inside_sphere_distribution/operators/equal.cc
index 370ee56..1210946 100644
--- a/libstdc++-v3/testsuite/ext/random/uniform_inside_sphere_distribution/operators/equal.cc
+++ b/libstdc++-v3/testsuite/ext/random/uniform_inside_sphere_distribution/operators/equal.cc
@@ -1,4 +1,4 @@
-// { dg-do run { target cxx11 } }
+// { dg-do run { target c++11 } }
 // { dg-require-cstdint "" }
 //
 // Copyright (C) 2014-2016 Free Software Foundation, Inc.
diff --git a/libstdc++-v3/testsuite/ext/random/uniform_inside_sphere_distribution/operators/generate.cc b/libstdc++-v3/testsuite/ext/random/uniform_inside_sphere_distribution/operators/generate.cc
index 60d76f3..e9a7ca7 100644
--- a/libstdc++-v3/testsuite/ext/random/uniform_inside_sphere_distribution/operators/generate.cc
+++ b/libstdc++-v3/testsuite/ext/random/uniform_inside_sphere_distribution/operators/generate.cc
@@ -1,4 +1,4 @@
-// { dg-do run { target cxx11 } }
+// { dg-do run { target c++11 } }
 // { dg-require-cstdint "" }
 //
 // Copyright (C) 2014-2016 Free Software Foundation, Inc.
diff --git a/libstdc++-v3/testsuite/ext/random/uniform_inside_sphere_distribution/operators/inequal.cc b/libstdc++-v3/testsuite/ext/random/uniform_inside_sphere_distribution/operators/inequal.cc
index 0256d47..ca0d380 100644
--- a/libstdc++-v3/testsuite/ext/random/uniform_inside_sphere_distribution/operators/inequal.cc
+++ b/libstdc++-v3/testsuite/ext/random/uniform_inside_sphere_distribution/operators/inequal.cc
@@ -1,4 +1,4 @@
-// { dg-do run { target cxx11 } }
+// { dg-do run { target c++11 } }
 // { dg-require-cstdint "" }
 //
 // Copyright (C) 2014-2016 Free Software Foundation, Inc.
diff --git a/libstdc++-v3/testsuite/ext/random/uniform_inside_sphere_distribution/operators/serialize.cc b/libstdc++-v3/testsuite/ext/random/uniform_inside_sphere_distribution/operators/serialize.cc
index d03ce35..89eb604 100644
--- a/libstdc++-v3/testsuite/ext/random/uniform_inside_sphere_distribution/operators/serialize.cc
+++ b/libstdc++-v3/testsuite/ext/random/uniform_inside_sphere_distribution/operators/serialize.cc
@@ -1,4 +1,4 @@
-// { dg-do run { target cxx11 } }
+// { dg-do run { target c++11 } }
 // { dg-require-cstdint "" }
 //
 // Copyright (C) 2014-2016 Free Software Foundation, Inc.

Re: [PATCH GCC][4/4]Simplify (cond (cmp x c1) (op x c2) c3) -> (op (minmax x c1) c2)

[Richard Biener]

On Tue, Oct 25, 2016 at 1:22 PM, Bin Cheng  wrote:
> Hi,
> As commented in patch, this one simplifies (cond (cmp x c1) (op x c2) c3) 
> into (op (minmax x c1) c2) if:
>
>  1) OP is PLUS or MINUS.
>  2) CMP is LT, LE, GT or GE.
>  3) C3 == (C1 op C2), and the experation isn't undefined behavior.
>
>This pattern also handles special cases like:
>
>  1) Comparison's operand x is a unsigned to signed type conversion
> and c1 is integer zero.  In this case,
>   (signed type)x  < 0  <=>  x  > MAX_VAL(signed type)
>   (signed type)x >= 0  <=>  x <= MAX_VAL(signed type)
>  2) Const c1 may not equal to (C3 op' C2).  In this case we also
> check equality for (c1+1) and (c1-1) by adjusting comparison
> code.
>
> Also note: Though signed type is handled by this pattern, it cannot be 
> simplified at the moment because C standard requires additional type 
> promotion.  In order to match signed type cases, the IR needs to be 
> cleaned up by other optimizers, i.e, VRP.
> For given loop:
> int foo1 (unsigned short a[], unsigned int x)
> {
>   unsigned int i;
>   for (i = 0; i < 1000; i++)
> {
>   x = a[i];
>   a[i] = (unsigned short)(x <= 32768 ? x + 32768 : 0);
> }
>   return x;
> }
>
> Generated assembly can be improved from:
> .L4:
> ldr q5, [x3, x1]
> add w2, w2, 1
> cmp w0, w2
> ushll   v1.4s, v5.4h, 0
> ushll2  v0.4s, v5.8h, 0
> add v4.4s, v1.4s, v2.4s
> add v3.4s, v0.4s, v2.4s
> cmhsv1.4s, v2.4s, v1.4s
> cmhsv0.4s, v2.4s, v0.4s
> and v1.16b, v4.16b, v1.16b
> and v0.16b, v3.16b, v0.16b
> xtn v3.4h, v1.4s
> xtn2v3.8h, v0.4s
> str q3, [x3, x1]
> add x1, x1, 16
> bhi .L4
>
> To:
> .L4:
> ldr q1, [x3, x1]
> add w2, w2, 1
> cmp w0, w2
> uminv0.8h, v1.8h, v2.8h
> add v0.8h, v0.8h, v2.8h
> str q0, [x3, x1]
> add x1, x1, 16
> bhi .L4
>
> Bootstrap and test on x86_64 and AArch64 for whole patch set.  Any comments?

I reminded myself that fold-const.c:fold_cond_expr_with_comparison is
still GENERIC only
(needs to be moved to match.pd).  In that light can we stage the new
transform in a way
to get

  (cond (cmp x c1) (op x c2) c3)

into the form handled by it?  Thus

  (cond (cmp x c1') x c2') + c2

?  Something like c1' = c1 - c2; c2' = c3 - c2 (when valid to do this)?
(I didn't think long enough about this yet).

That said, can you try moving (cond (cmp x c1) x c2) -> minmax (the bottom most
case in fold_cond_expr_with_comparison) to match.pd and see whether you can
get that extended for your case?

A few comments on the pattern in your patch:

+   (cond (cmp@0 (convert?@00 @10) INTEGER_CST@01)
+(op @10 INTEGER_CST@11)
+INTEGER_CST@2)

the @00 vs @10 vs @01 vs @11 vs @0 is visually hard to match.  match.pd
allows for any alphanumeric identifier after @ (yes, we mostly use the digit
variants because historically that was the only ones available and there 00
and 01 didn't work ;)).  May I suggest @X @C1, etc. and @cmpexp maybe
for @0?  For simple patterns it really doesn't matter but if you have to scroll
in a 80x24 terminal to see it it doesn't help if you can't see the matched
patterns with the captures when seeing @01 ...

Thanks,
Richard.

> Thanks,
> bin
>
> 2016-10-21  Bin Cheng  
>
> * match.pd ((cond (cmp x c1) (op x c2) c3) -> (op (minmax x c1) c2)):
> New pattern.
>
> gcc/testsuite/ChangeLog
> 2016-10-21  Bin Cheng  
>
> * gcc.dg/fold-bopcond-1.c: New test.
> * gcc.dg/fold-bopcond-2.c: New test.

C++ PATCH to class using-declaration ambiguity handling

[Jason Merrill]

While working on the inheriting constructors overhaul I noticed that
we were handling this wrong: we were allowing one using-declaration to
hide another, but they should both be added so that the ambiguity is
seen by overload resolution.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit cda993583ed7eb9270b8758c201894122997c516
Author: Jason Merrill 
Date:   Wed Oct 26 13:15:43 2016 -0400

* class.c (add_method): Allow using-declarations to coexist.

diff --git a/gcc/cp/class.c b/gcc/cp/class.c
index d334b7c..a2a9346 100644
--- a/gcc/cp/class.c
+++ b/gcc/cp/class.c
@@ -1094,6 +1094,11 @@ add_method (tree type, tree method, tree using_decl)
   if (TREE_CODE (fn) != TREE_CODE (method))
continue;
 
+  /* Two using-declarations can coexist, we'll complain about ambiguity in
+overload resolution.  */
+  if (using_decl && TREE_CODE (fns) == OVERLOAD && OVL_USED (fns))
+   continue;
+
   /* [over.load] Member function declarations with the
 same name and the same parameter types cannot be
 overloaded if any of them is a static member
diff --git a/gcc/testsuite/g++.dg/overload/using4.C 
b/gcc/testsuite/g++.dg/overload/using4.C
new file mode 100644
index 000..e4ee823
--- /dev/null
+++ b/gcc/testsuite/g++.dg/overload/using4.C
@@ -0,0 +1,19 @@
+struct A
+{
+  void f();
+};
+
+struct B
+{
+  void f();
+};
+
+struct C: A,B {
+  using A::f;
+  using B::f;
+};
+
+int main()
+{
+  C().f(); // { dg-error "ambiguous" }
+}

Re: RFC [3/3] divmod transform v2 - add test cases

[Richard Biener]

On Thu, 27 Oct 2016, Prathamesh Kulkarni wrote:

> On 27 October 2016 at 18:58, Richard Biener  wrote:
> > On Thu, 27 Oct 2016, Prathamesh Kulkarni wrote:
> >
> >> On 24 October 2016 at 21:09, Prathamesh Kulkarni
> >>  wrote:
> >> > On 16 October 2016 at 11:31, Prathamesh Kulkarni
> >> >  wrote:
> >> >> Hi,
> >> >> This patch adds test-cases for divmod transform.
> >> >> OK to commit ?
> >> > ping https://gcc.gnu.org/ml/gcc-patches/2016-10/msg01241.html
> >> Hi Richard,
> >> Could you please review this part:
> >> https://gcc.gnu.org/ml/gcc-patches/2016-10/msg01241.html
> >> It only adds test-cases for the divmod transform.
> >> Is it OK to commit ?
> >
> > Can't see where the divmod or divmod_simode effective targets are
> > defined.  If a patch adding those has been approved then the new
> > tests are fine.
> Sorry, I had put lib/target-supports.exp hunk in the 2nd part:
> https://gcc.gnu.org/ml/gcc-patches/2016-10/msg01240.html
> Does it look OK ?

Yes.

Richard.

[PATCH VECT]Support operand swapping for cond_expr in vect_slp

[Bin Cheng]

Hi,
During analysis, vect_slp checks if statements of a group are isomorphic to 
each other, specifically, all statements have to be isomorphic to the first 
one.  Apparently, operands of commutative operators (PLUS_EXPR/MINUS_EXPR etc.) 
could be swapped when checking isomorphic property.  Though vect_slp has basic 
support for such commutative operators, the related code is not properly 
implemented:
  1) vect_build_slp_tree mixes operand swapping in the current slp tree node 
and operand swapping in its child slp tree nodes.
  2) Operand swapping in the current slp tree is incorrect when 
vect_get_and_check_slp_defs has already committed to a fixed operand order.
In addition, operand swapping for COND_EXPR is implemented in a wrong way 
(place) because:
  3) vect_get_and_check_slp_defs swaps operands for COND_EXPR by changing 
comparison code after vect_build_slp_tree_1 checks the code consistency for the 
statement group.
  4) vect_build_slp_tree_1 should support operand swapping for COND_EXPR while 
it doesn't.

This patch addresses above issues.  It supports COND_EXPR by recording swapping 
information in vect_build_slp_tree_1 and applies the swap in 
vect_get_check_slp_defs.  It supports two types swapping: swapping and 
inverting.  The patch also does refactoring so that operand swapping in child 
slp tree node and the current slp tree node are differentiated.  With this 
patch, failures (gcc.dg/vect/slp-cond-3.c) revealed by previous COND_EXPR 
match.pd patches are resolved.
Bootstrap and test on x86_64 and AArch64.  Is it OK?

Thanks,
bin

2016-10-25  Bin Cheng  

* tree-vect-slp.c (vect_get_and_check_slp_defs): New parameter SWAP.
Check slp defs for COND_EXPR by swapping/inverting operands if
indicated by the new parameter SWAP.
(vect_build_slp_tree_1): New parameter SWAP.  Check COND_EXPR stmt
is isomorphic to the first stmt via swapping/inverting.  Store swap
information in the new parameter SWAP.
(vect_build_slp_tree): New local array SWAP and pass it to function
vect_build_slp_tree_1.  Cleanup result handlding code for function
call to vect_get_and_check_slp_defs.  Skip oeprand swapping if the
order of operands has been fixed as indicated by SWAP[i].diff --git a/gcc/tree-vect-slp.c b/gcc/tree-vect-slp.c
index 5a611e4..1f2551d 100644
--- a/gcc/tree-vect-slp.c
+++ b/gcc/tree-vect-slp.c
@@ -207,14 +207,20 @@ vect_get_place_in_interleaving_chain (gimple *stmt, 
gimple *first_stmt)
 
 /* Get the defs for the rhs of STMT (collect them in OPRNDS_INFO), check that
they are of a valid type and that they match the defs of the first stmt of
-   the SLP group (stored in OPRNDS_INFO).  If there was a fatal error
-   return -1, if the error could be corrected by swapping operands of the
-   operation return 1, if everything is ok return 0.  */
+   the SLP group (stored in OPRNDS_INFO).  This function tries to match stmts
+   by swapping operands of STMT when possible.  Non-zero *SWAP indicates swap
+   is required for cond_expr stmts.  Specifically, *SWAP is 1 if STMT is cond
+   and operands of comparison need to be swapped; *SWAP is 2 if STMT is cond
+   and code of comparison needs to be inverted.  If there is any operand swap
+   in this function, *SWAP is set to non-zero value.
+   If there was a fatal error return -1; if the error could be corrected by
+   swapping operands of father node of this one, return 1; if everything is
+   ok return 0.  */
 
-static int 
-vect_get_and_check_slp_defs (vec_info *vinfo,
+static int
+vect_get_and_check_slp_defs (vec_info *vinfo, unsigned char *swap,
 gimple *stmt, unsigned stmt_num,
- vec *oprnds_info)
+vec *oprnds_info)
 {
   tree oprnd;
   unsigned int i, number_of_oprnds;
@@ -237,11 +243,12 @@ vect_get_and_check_slp_defs (vec_info *vinfo,
 {
   enum tree_code code = gimple_assign_rhs_code (stmt);
   number_of_oprnds = gimple_num_ops (stmt) - 1;
+  /* Swap can only be done for cond_expr if asked to, otherwise we
+could result in different comparison code to the first stmt.  */
   if (gimple_assign_rhs_code (stmt) == COND_EXPR
  && COMPARISON_CLASS_P (gimple_assign_rhs1 (stmt)))
{
  first_op_cond = true;
- commutative = true;
  number_of_oprnds++;
}
   else
@@ -250,20 +257,24 @@ vect_get_and_check_slp_defs (vec_info *vinfo,
   else
 return -1;
 
-  bool swapped = false;
+  bool swapped = (*swap != 0);
+  gcc_assert (!swapped || first_op_cond);
   for (i = 0; i < number_of_oprnds; i++)
 {
 again:
   if (first_op_cond)
{
- if (i == 0 || i == 1)
-   oprnd = TREE_OPERAND (gimple_op (stmt, first_op_idx),
- swapped ? !i : i);
+ /* Map indicating how operands of cond_expr should be swapped.  */
+ int maps[3][4] = {{0, 1, 

RFA: PATCH to gengtype to avoid putting tree_node support in front end objects

[Jason Merrill]

Currently, the way gengtype works it scans the list of source files
with front end files at the end, and pushes data structures onto a
stack.  It then processes the stack in LIFO order, so that data
structures from front ends are handled first.  As a result, if a GTY
data structure in a front end depends on tree_node, gengtype happily
puts gt_ggc_mx(tree_node*&) in a front end file, leading to link
errors on all other front ends.

This patch avoids this problem by appending to the list of data
structures so that they are processed in FIFO order, and so tree_node
gets handled in gtype-desc.o.

Tested x86_64-pc-linux-gnu, OK for trunk?
commit 487a1c95c0d3169b2041942ff4f8d71c9ff689eb
Author: Jason Merrill 
Date:   Wed Oct 26 23:12:23 2016 -0400

* gengtype.c (new_structure): Append to structures list.

(find_structure): Likewise.

diff --git a/gcc/gengtype.c b/gcc/gengtype.c
index 760f985..a579547 100644
--- a/gcc/gengtype.c
+++ b/gcc/gengtype.c
@@ -744,10 +744,11 @@ new_structure (const char *name, enum typekind kind, 
struct fileloc *pos,
   type_p s = NULL;
   lang_bitmap bitmap = get_lang_bitmap (pos->file);
   bool isunion = (kind == TYPE_UNION);
+  type_p *p = 
 
   gcc_assert (union_or_struct_p (kind));
 
-  for (si = structures; si != NULL; si = si->next)
+  for (si = structures; si != NULL; p = >next, si = *p)
 if (strcmp (name, si->u.s.tag) == 0 && UNION_P (si) == isunion)
   {
type_p ls = NULL;
@@ -793,8 +794,7 @@ new_structure (const char *name, enum typekind kind, struct 
fileloc *pos,
   type_count++;
   s = XCNEW (struct type);
   s->state_number = -type_count;
-  s->next = structures;
-  structures = s;
+  *p = s;
 }
 
   if (s->u.s.lang_struct && (s->u.s.lang_struct->u.s.bitmap & bitmap))
@@ -829,21 +829,20 @@ find_structure (const char *name, enum typekind kind)
 {
   type_p s;
   bool isunion = (kind == TYPE_UNION);
+  type_p *p = 
 
   gcc_assert (kind == TYPE_UNDEFINED || union_or_struct_p (kind));
 
-  for (s = structures; s != NULL; s = s->next)
+  for (s = structures; s != NULL; p = >next, s = *p)
 if (strcmp (name, s->u.s.tag) == 0 && UNION_P (s) == isunion)
   return s;
 
   type_count++;
   s = XCNEW (struct type);
-  s->next = structures;
   s->state_number = -type_count;
-  structures = s;
   s->kind = kind;
   s->u.s.tag = name;
-  structures = s;
+  *p = s;
   return s;
 }
 

Re: [PATCH] Fix host_size_t_cst_p predicate

[Richard Biener]

On Thu, Oct 27, 2016 at 9:41 AM, Martin Liška  wrote:
> Running simple test-case w/o the proper header file causes ICE:
> strncmp ("a", "b", -1);
>
> 0xe74462 tree_to_uhwi(tree_node const*)
> ../../gcc/tree.c:7324
> 0x90a23f host_size_t_cst_p
> ../../gcc/fold-const-call.c:63
> 0x90a23f fold_const_call(combined_fn, tree_node*, tree_node*, tree_node*, 
> tree_node*)
> ../../gcc/fold-const-call.c:1512
> 0x787b01 fold_builtin_3
> ../../gcc/builtins.c:8385
> 0x787b01 fold_builtin_n(unsigned int, tree_node*, tree_node**, int, bool)
> ../../gcc/builtins.c:8465
> 0x9052b1 fold(tree_node*)
> ../../gcc/fold-const.c:11919
> 0x6de2bb c_fully_fold_internal
> ../../gcc/c/c-fold.c:185
> 0x6e1f6b c_fully_fold(tree_node*, bool, bool*)
> ../../gcc/c/c-fold.c:90
> 0x67cbbf c_process_expr_stmt(unsigned int, tree_node*)
> ../../gcc/c/c-typeck.c:10369
> 0x67cfbd c_finish_expr_stmt(unsigned int, tree_node*)
> ../../gcc/c/c-typeck.c:10414
> 0x6cb578 c_parser_statement_after_labels
> ../../gcc/c/c-parser.c:5430
> 0x6cd333 c_parser_compound_statement_nostart
> ../../gcc/c/c-parser.c:4944
> 0x6cdbde c_parser_compound_statement
> ../../gcc/c/c-parser.c:4777
> 0x6c93ac c_parser_declaration_or_fndef
> ../../gcc/c/c-parser.c:2176
> 0x6d51ab c_parser_external_declaration
> ../../gcc/c/c-parser.c:1574
> 0x6d5c09 c_parser_translation_unit
> ../../gcc/c/c-parser.c:1454
> 0x6d5c09 c_parse_file()
> ../../gcc/c/c-parser.c:18173
> 0x72ffd2 c_common_parse_file()
> ../../gcc/c-family/c-opts.c:1087
>
> Following patch improves the host_size_t_cst_p predicate.
>
> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
>
> Ready to be installed?

I believe the wi::min_precision (t, UNSIGNED) <= sizeof (size_t) *
CHAR_BIT test is now redundant.

OTOH it was probably desired to allow -1 here?  A little looking back
in time should tell.

Richard.

> Martin

Re: [PATCH] Five patches for std::experimental::filesystem

[Jonathan Wakely]

On 26/10/16 09:24 +0200, Christophe Lyon wrote:

Hi Jonathan,

On 25 October 2016 at 17:32, Jonathan Wakely  wrote:

Two more fixes for the filesystem TS, and improved tests.

  Handle negative times in filesystem::last_write_time
  * src/filesystem/ops.cc
   (last_write_time(const path&, file_time_type, error_code&)): Handle
   negative times correctly.
   * testsuite/experimental/filesystem/operations/last_write_time.cc:
   Test writing file times.

   Fix error handling in copy_file and equivalent
  * src/filesystem/ops.cc (do_copy_file): Report an error if source
or
   destination is not a regular file (LWG 2712).
   (equivalent): Fix error handling and result when only one file
exists.
   * testsuite/experimental/filesystem/operations/copy.cc: Remove files
   created by tests. Test copying directories.
   * testsuite/experimental/filesystem/operations/copy_file.cc: Remove
   files created by tests.
   * testsuite/experimental/filesystem/operations/equivalent.cc: New.
   * testsuite/experimental/filesystem/operations/is_empty.cc: New.
   * testsuite/experimental/filesystem/operations/read_symlink.cc:
Remove
   file created by test.
   * testsuite/experimental/filesystem/operations/remove_all.cc: New.
   * testsuite/util/testsuite_fs.h (~scoped_file): Only try to remove
   file if path is non-empty, to support removal by other means.

Tested x86_64-linux, committed to trunk.



I can see failures in
experimental/filesystem/operations/last_write_time.cc after your
committed this patch:
/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/testsuite/experimental/filesystem/operations/last_write_time.cc:127:
void test02(): Assertion 'last_write_time(f.path) == time' failed.
on arm*linux* and aarch64*linux* targets.


That test will fail for targets where _GLIBCXX_USE_UTIMENSAT is not
defined, as they use utime() instead which only supports second
granularity.

This should solve it, by only checking that the file times are within
one second of the expected value.

Tested x86_64-linux, committed to trunk.
commit 9b3f71e225ae45ccc1a5a78fee05d4ed9a969e8e
Author: Jonathan Wakely 
Date:   Thu Oct 27 11:48:00 2016 +0100

Adjust precision of filesystem::last_write_time tests

	* testsuite/experimental/filesystem/iterators/directory_iterator.cc:
	Use end() function to get end iterator.
	* testsuite/experimental/filesystem/iterators/pop.cc: Remove printf
	statements that were present for debugging.
	* testsuite/experimental/filesystem/iterators/
	recursive_directory_iterator.cc: Use end() function to get end
	iterator.
	* testsuite/experimental/filesystem/operations/last_write_time.cc:
	Only require file timestamps to be accurate to one second.

diff --git a/libstdc++-v3/testsuite/experimental/filesystem/iterators/directory_iterator.cc b/libstdc++-v3/testsuite/experimental/filesystem/iterators/directory_iterator.cc
index 5788700..d1f2c54 100644
--- a/libstdc++-v3/testsuite/experimental/filesystem/iterators/directory_iterator.cc
+++ b/libstdc++-v3/testsuite/experimental/filesystem/iterators/directory_iterator.cc
@@ -34,14 +34,14 @@ test01()
   const auto p = __gnu_test::nonexistent_path();
   fs::directory_iterator iter(p, ec);
   VERIFY( ec );
-  VERIFY( iter == fs::directory_iterator() );
+  VERIFY( iter == end(iter) );
 
   // Test empty directory.
   create_directory(p, fs::current_path(), ec);
   VERIFY( !ec );
   iter = fs::directory_iterator(p, ec);
   VERIFY( !ec );
-  VERIFY( iter == fs::directory_iterator() );
+  VERIFY( iter == end(iter) );
 
   // Test non-empty directory.
   create_directory_symlink(p, p / "l", ec);
@@ -51,20 +51,20 @@ test01()
   VERIFY( iter != fs::directory_iterator() );
   VERIFY( iter->path() == p/"l" );
   ++iter;
-  VERIFY( iter == fs::directory_iterator() );
+  VERIFY( iter == end(iter) );
 
   // Test inaccessible directory.
   permissions(p, fs::perms::none, ec);
   VERIFY( !ec );
   iter = fs::directory_iterator(p, ec);
   VERIFY( ec );
-  VERIFY( iter == fs::directory_iterator() );
+  VERIFY( iter == end(iter) );
 
   // Test inaccessible directory, skipping permission denied.
   const auto opts = fs::directory_options::skip_permission_denied;
   iter = fs::directory_iterator(p, opts, ec);
   VERIFY( !ec );
-  VERIFY( iter == fs::directory_iterator() );
+  VERIFY( iter == end(iter) );
 
   permissions(p, fs::perms::owner_all, ec);
   remove_all(p, ec);
@@ -82,12 +82,12 @@ test02()
   // Test post-increment (libstdc++/71005)
   auto iter = fs::directory_iterator(p, ec);
   VERIFY( !ec );
-  VERIFY( iter != fs::directory_iterator() );
+  VERIFY( iter != end(iter) );
   const auto entry1 = *iter;
   const auto entry2 = *iter++;
   VERIFY( entry1 == entry2 );
   VERIFY( entry1.path() == p/"l" );
-  VERIFY( iter == fs::directory_iterator() );
+  VERIFY( iter == end(iter) );
 
   remove_all(p, ec);
 }
diff --git 

Re: Add uniform_inside_sphere_distribution

[Andreas Schwab]

On Okt 26 2016, Jonathan Wakely  wrote:

> In all the new tests please replace this dg-options directive with:
>
>  { dg-do run { target cxx11 } }

ERROR: ext/random/uniform_inside_sphere_distribution/cons/default.cc: syntax 
error in target selector "target cxx11" for " dg-do 1 run { target cxx11 } "

Andreas.

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

Re: RFC [3/3] divmod transform v2 - add test cases

[Prathamesh Kulkarni]

On 27 October 2016 at 18:58, Richard Biener  wrote:
> On Thu, 27 Oct 2016, Prathamesh Kulkarni wrote:
>
>> On 24 October 2016 at 21:09, Prathamesh Kulkarni
>>  wrote:
>> > On 16 October 2016 at 11:31, Prathamesh Kulkarni
>> >  wrote:
>> >> Hi,
>> >> This patch adds test-cases for divmod transform.
>> >> OK to commit ?
>> > ping https://gcc.gnu.org/ml/gcc-patches/2016-10/msg01241.html
>> Hi Richard,
>> Could you please review this part:
>> https://gcc.gnu.org/ml/gcc-patches/2016-10/msg01241.html
>> It only adds test-cases for the divmod transform.
>> Is it OK to commit ?
>
> Can't see where the divmod or divmod_simode effective targets are
> defined.  If a patch adding those has been approved then the new
> tests are fine.
Sorry, I had put lib/target-supports.exp hunk in the 2nd part:
https://gcc.gnu.org/ml/gcc-patches/2016-10/msg01240.html
Does it look OK ?

Thanks,
Prathamesh
>
> Thanks,
> Richard.

Re: [PATCH GCC][3/4]Add support for constant operand in pattern (convert (op:s (convert@2 @0) (convert?@3 @1)))

[Richard Biener]

On Wed, Oct 26, 2016 at 4:01 PM, Bin.Cheng  wrote:
> On Tue, Oct 25, 2016 at 1:00 PM, Richard Biener
>  wrote:
>> On Tue, Oct 25, 2016 at 1:21 PM, Bin Cheng  wrote:
>>> Hi,
>>> This is an update patch for 
>>> https://gcc.gnu.org/ml/gcc-patches/2016-10/msg00738.html .  In this 
>>> version, existing pattern (convert (op:s (convert@2 @0) (convert?@3 @1))) 
>>> is extended.  It allows narrowing of arithmetic operation which has 
>>> constant integer as its second operand.  It also simplifies next patch 
>>> handling cond_expr.
>>> Bootstrap and test on x86_64 and AArch64 for whole patch set.  Is it OK?
>>
>> +&& types_match (@0, type)
>> +&& (types_match (@0, @1)
>> +/* Or the second operand must be constant integer.  */
>> +|| (@3 == @1
>> +&& types_match (@1, @2)
>> +&& TREE_CODE (@1) == INTEGER_CST)))
>>
>> So this fails to match the pattern if we get into it via valueization
>> and get, say,
>> (short)((int)a + (int)7).  I believe for plus and minus we're always safe so
>> I suggest to simply do
>>
>>   && (types_match (@0, @1)
>> || TREE_CODE (@1) == INTEGER_CST)
>>
>>(if (TYPE_OVERFLOW_WRAPS (TREE_TYPE (@0)))
>> -   (convert (op @0 @1))
>> +   (convert (op @0 (convert:type @1)))
>>
>> :type shouldn't be necessary -- it also shows the outer (convert ..)
>> is not required,
>> please remove it while you're here.
>>
>> (with { tree utype = unsigned_type_for (TREE_TYPE (@0)); }
>> -(convert (op (convert:utype @0) (convert:utype @1
>> +(convert (op (convert:utype @0)
>> + (convert:utype (convert:type @1)
>>
>> Why do you need the intermediate conversion?
>
> Thanks for reviewing, updated patch attached.  Is it OK?

Ok.

Thanks,
Richard.

> Thanks,
> bin

Re: RFC [2/3] divmod transform v2 - override expand_divmod_libfunc for ARM port

[Prathamesh Kulkarni]

On 26 October 2016 at 18:51, Kyrill Tkachov  wrote:
>
> On 16/10/16 07:00, Prathamesh Kulkarni wrote:
>>
>> Hi,
>> This patch overrides expand_divmod_libfunc hook for ARM port.
>> I separated the SImode tests into separate file from DImode tests
>> because certain arm configs (cortex-15) have hardware div insn for
>> SImode but not for DImode, and for that config we want SImode tests to
>> be disabled but not DImode tests. The patch therefore has two
>> target-effective checks: divmod and divmod_simode.
>> Cross-tested on arm*-*-*.
>> OK to commit ?
>
>
> Looks ok to me, the implementation of the hook is straightforward though
> I have a question.
> arm_expand_divmod_libfunc is not supposed to ever be called for SImode
> TARGET_IDIV.
> It asserts it rather than just failing the expansion in some way.
> How does the midend know not to call TARGET_EXPAND_DIVMOD_LIBFUNC in that
> case, does it
> just check if the relevant sdiv optab is not available?
Yes. The divmod transform isn't enabled if target supports hardware
div in the same
or wider mode even if divmod libfunc is available for the given mode.
>
> If so, this is ok for trunk assuming a bootstrap and test run on
> arm-none-linux-gnueabihf
> shows no issues. Would be good to try one for --with-cpu=cortex-a15 and one
> with a !TARGET_IDIV
> target, say --with-cpu=cortex-a9.
Bootstrap+tested on arm-linux-gnueabihf --with-cpu=cortex-a15 and
--with-cpu=cortex-a9.
Also cross-tested on arm*-*-*.
OK to commit ?

Thanks,
Prathamesh
>
> Sorry for the delay.
>
> Thanks,
> Kyrill
>
>
>> Thanks,
>> Prathamesh
>
>

Re: [PATCH] GIMPLE store merging pass

[Richard Biener]

On Mon, 24 Oct 2016, Kyrill Tkachov wrote:

> Hi all,
> 
> This is a slight update over [1] with Richard's feedback addressed.
> In terminate_all_aliasing_chains we now terminate the chain early if
> the destination is writing to a base offset by a variable amount.
> This avoids walking the store chain and performing more alias checks.
> 
> The param max-stores-to-merge is introduced to limit the number of statements
> we merge. Its default value is set to 64 which should be enough for now and
> avoids
> blowing up compile time in cases such as [2].
> 
> I've also introduced a timevar for the pass to allow us to track it in
> -ftime-report.
> 
> Bootstrapped and tested on aarch64, arm, x86_64.
> 
> Ok?

Ok if you add documentation for the two new --params.

Thanks,
Richard.

> Thanks,
> Kyrill
> 
> [1] https://gcc.gnu.org/ml/gcc-patches/2016-10/msg01459.html
> [2] https://gcc.gnu.org/ml/gcc-patches/2016-10/msg01880.html
> 
> 2016-10-24  Kyrylo Tkachov  
> 
> PR middle-end/22141
> * Makefile.in (OBJS): Add gimple-ssa-store-merging.o.
> * common.opt (fstore-merging): New Optimization option.
> * opts.c (default_options_table): Add entry for
> OPT_ftree_store_merging.
> * fold-const.h (can_native_encode_type_p): Declare prototype.
> * fold-const.c (can_native_encode_type_p): Define.
> * params.def (PARAM_STORE_MERGING_ALLOW_UNALIGNED): Define.
> (PARAM_MAX_STORES_TO_MERGE): Likewise.
> * timevar.def (TV_GIMPLE_STORE_MERGING): New timevar.
> * passes.def: Insert pass_tree_store_merging.
> * tree-pass.h (make_pass_store_merging): Declare extern
> prototype.
> * gimple-ssa-store-merging.c: New file.
> * doc/invoke.texi (Optimization Options): Document
> -fstore-merging.
> 
> 2016-10-24  Kyrylo Tkachov  
> Jakub Jelinek  
> Andrew Pinski  
> 
> PR middle-end/22141
> PR rtl-optimization/23684
> * gcc.c-torture/execute/pr22141-1.c: New test.
> * gcc.c-torture/execute/pr22141-2.c: Likewise.
> * gcc.target/aarch64/ldp_stp_1.c: Adjust for -fstore-merging.
> * gcc.target/aarch64/ldp_stp_4.c: Likewise.
> * gcc.dg/store_merging_1.c: New test.
> * gcc.dg/store_merging_2.c: Likewise.
> * gcc.dg/store_merging_3.c: Likewise.
> * gcc.dg/store_merging_4.c: Likewise.
> * gcc.dg/store_merging_5.c: Likewise.
> * gcc.dg/store_merging_6.c: Likewise.
> * gcc.dg/store_merging_7.c: Likewise.
> * gcc.target/i386/pr22141.c: Likewise.
> * gcc.target/i386/pr34012.c: Add -fno-store-merging to dg-options.
> * g++.dg/init/new17.C: Likewise.
> 

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

Re: RFC [3/3] divmod transform v2 - add test cases

[Richard Biener]

On Thu, 27 Oct 2016, Prathamesh Kulkarni wrote:

> On 24 October 2016 at 21:09, Prathamesh Kulkarni
>  wrote:
> > On 16 October 2016 at 11:31, Prathamesh Kulkarni
> >  wrote:
> >> Hi,
> >> This patch adds test-cases for divmod transform.
> >> OK to commit ?
> > ping https://gcc.gnu.org/ml/gcc-patches/2016-10/msg01241.html
> Hi Richard,
> Could you please review this part:
> https://gcc.gnu.org/ml/gcc-patches/2016-10/msg01241.html
> It only adds test-cases for the divmod transform.
> Is it OK to commit ?

Can't see where the divmod or divmod_simode effective targets are
defined.  If a patch adding those has been approved then the new
tests are fine.

Thanks,
Richard.

[COMMITTED] Add myself to MAINTAINERS file

[Andrew Burgess]

I committed the patch below.

Thanks,
Andrew

---

Index: ChangeLog
===
--- ChangeLog   (revision 241618)
+++ ChangeLog   (revision 241619)
@@ -1,3 +1,8 @@
+2016-10-27  Andrew Burgess  
+
+   * MAINTAINERS (Reviewers): Add myself.
+   (Write After Approval): Add myself.
+
 2016-10-21  Hartmut Penner  
Ulrich Weigand  
 
Index: MAINTAINERS
===
--- MAINTAINERS (revision 241618)
+++ MAINTAINERS (revision 241619)
@@ -252,6 +252,7 @@
Reviewers
 
 aarch64 port   James Greenhalgh
+arc port   Andrew Burgess  
 arc port   Claudiu Zissulescu  
 arm port   Kyrylo Tkachov  
 C front endMarek Polacek   
@@ -334,6 +335,7 @@
 Christian Bruel
 Iain Buclaw
 Kevin Buettner 
+Andrew Burgess 
 Adam Butcher   
 Andrew Cagney  
 Daniel Carrera 

Re: [PATCH, Fortran] DEC Compatibility: New I/O Specifiers CARRIAGECONTROL, READONLY, SHARE with -fdec

[Fritz Reese]

On Thu, Oct 27, 2016 at 8:52 AM, Jakub Jelinek  wrote:
> On Thu, Oct 27, 2016 at 08:49:42AM -0400, Fritz Reese wrote:
>>
>> Do you know if there is there any way from DG to verify that a runtime
>> warning is emitted?
>
> Use dg-output for that.  And, if the test is supposed to exit with non-zero
> exit status because of the runtime error, then also dg-shouldfail.
>
> Jakub

Thanks. I could never find good documentation on the various dg-*
testing options. I was browsing other test files to figure out how to
express dec_io_5 and dec_io_6. I first saw "XFAIL", I assumed it meant
"eXpected FAIL", and used it since I "expected" dec_io_5 to "fail" at
runtime. I was only half-right...

The attached should be correct now

---
Fritz Reese.

From: Fritz Reese 
Date: Thu, 27 Oct 2016 08:46:33 -0400
Subject: [PATCH] Fix some DEC I/O testcases.

gcc/testsuite/gfortran.dg/
* dec_io_5.f90, dec_io_6.f90: Don't use "test.txt", and use
dg-shouldfail/dg-output instead of XFAIL.
---
 gcc/testsuite/gfortran.dg/dec_io_5.f90 |8 +---
 gcc/testsuite/gfortran.dg/dec_io_6.f90 |   22 ++
 2 files changed, 23 insertions(+), 7 deletions(-)
diff --git a/gcc/testsuite/gfortran.dg/dec_io_5.f90 
b/gcc/testsuite/gfortran.dg/dec_io_5.f90
index 9d44c6e..c6633a5 100644
--- a/gcc/testsuite/gfortran.dg/dec_io_5.f90
+++ b/gcc/testsuite/gfortran.dg/dec_io_5.f90
@@ -1,5 +1,6 @@
-! { dg-do run "xfail *-*-*" }
+! { dg-do run }
 ! { dg-options "-fdec" }
+! { dg-shouldfail "ACTION conflicts with READONLY" }
 !
 ! Test that we get a run-time error for opening a READONLY file with
 ! ACTION='WRITE'.
@@ -8,10 +9,11 @@
 implicit none
 
 integer :: fd = 8
-character(*), parameter :: f = "test.txt"
+character(*), parameter :: f = "dec_io_5.txt"
 character(10), volatile :: c
 c = 'write'
 
-open(unit=fd,file=f,action=c,readonly) ! XFAIL "ACTION conflicts with READONLY"
+open(unit=fd,file=f,action=c,readonly)
 
 end
+! { dg-output "ACTION conflicts with READONLY" }
diff --git a/gcc/testsuite/gfortran.dg/dec_io_6.f90 
b/gcc/testsuite/gfortran.dg/dec_io_6.f90
index a0c0256..2dfaf9d 100644
--- a/gcc/testsuite/gfortran.dg/dec_io_6.f90
+++ b/gcc/testsuite/gfortran.dg/dec_io_6.f90
@@ -1,15 +1,29 @@
-! { dg-do run "xfail *-*-*" }
+! { dg-do run }
 ! { dg-options "-fdec" }
 !
-! Test that we get a run-time error for close-on-delete with READONLY.
+! Test that we get a run-time warning for close-on-delete with READONLY,
+! and that the file is protected from deletion.
 !
 
 implicit none
 
 integer :: fd = 8
-character(*), parameter :: f = "test.txt"
+character(*), parameter :: f = "dec_io_6.txt"
+logical :: exists
+
+open(unit=fd,file=f,action='write')
+close(unit=fd)
 
 open(unit=fd,file=f,action='read',readonly)
-close(unit=fd,status='delete') ! XFAIL "protected by READONLY"
+close(unit=fd,status='delete') ! { dg-output "file protected by READONLY" }
+
+inquire(file=f, EXIST=exists)
+if (.not. exists) then
+  print *, 'file was not protected by READONLY!'
+  call abort()
+endif
+
+open(unit=fd,file=f,action='write')
+close(unit=fd,status='delete') ! cleanup
 
 end

Re: [arm-embedded] [PATCH, ARM 7/7] Enable ARMv8-M atomic and synchronization support for ARMv8-M Baseline

[Thomas Preudhomme]

On 22/09/16 17:43, Thomas Preudhomme wrote:

Hi,

We've decided to apply the following patch to ARM/embedded-6-branch.


Sorry I meant ARM/embedded-5-branch. This has just been applied on 
ARM/embedded-6-branch as well today.


Best regards,

Thomas

Re: [arm-embedded] [PATCH, ARM/testsuite 6/7] Force soft float in ARMv6-M and ARMv8-M Baseline options

[Thomas Preudhomme]

On 22/09/16 17:42, Thomas Preudhomme wrote:

Hi,

We've decided to apply the following patch to ARM/embedded-6-branch.


Sorry, I meant ARM/embedded-5-branch.

Best regards,

Thomas

Re: [arm-embedded] [PATCH, ARM 5/7] Adapt other atomic operations to ARMv8-M Baseline

[Thomas Preudhomme]

On 22/09/16 17:42, Thomas Preudhomme wrote:

Hi,

We've decided to apply the following patch to ARM/embedded-6-branch.


Sorry I meant ARM/embedded-5-branch. This has just been applied on 
ARM/embedded-6-branch as well today.


Best regards,

Thomas

Re: [arm-embedded] [PATCH, ARM 4/7] Adapt atomic compare and swap to ARMv8-M Baseline

[Thomas Preudhomme]

On 22/09/16 17:42, Thomas Preudhomme wrote:

Hi,

We've decided to apply the following patch to ARM/embedded-6-branch.


Sorry I meant ARM/embedded-5-branch. This has just been applied on 
ARM/embedded-6-branch as well 1 day ago (2016-10-26).


Best regards,

Thomas

Re: [arm-embedded] [PATCH, ARM 3/7] Refactor atomic compare_and_swap to make it fit for ARMv8-M Baseline

[Thomas Preudhomme]

On 22/09/16 17:41, Thomas Preudhomme wrote:

Hi,

We've decided to apply the following patch to ARM/embedded-6-branch.


Sorry I meant ARM/embedded-5-branch. This has just been applied on 
ARM/embedded-6-branch as well 1 day ago (2016-10-26).


Best regards,

Thomas

Re: [arm-embedded] [PATCH, ARM 2/7] Adapt atomic and exclusive load and store to ARMv8-M Baseline

[Thomas Preudhomme]

On 22/09/16 17:41, Thomas Preudhomme wrote:

Hi,

We've decided to apply the following patch to ARM/embedded-6-branch.


Sorry I meant ARM/embedded-5-branch. This has just been applied on 
ARM/embedded-6-branch as well 1 day ago (2016-10-26).


Best regards,

Thomas

Re: [arm-embedded] [PATCH, 1/7] Move memory model declarations in memmodel.h

[Thomas Preudhomme]

On 22/09/16 17:41, Thomas Preudhomme wrote:

Hi,

We've decided to apply the following patch to ARM/embedded-6-branch.


Sorry I meant ARM/embedded-5-branch. This has just been applied on 
ARM/embedded-6-branch as well 2 days ago (2016-10-25).


Best regards,

Thomas

Re: [PATCH, Fortran] DEC Compatibility: New I/O Specifiers CARRIAGECONTROL, READONLY, SHARE with -fdec

[Jakub Jelinek]

On Thu, Oct 27, 2016 at 08:49:42AM -0400, Fritz Reese wrote:
> The presence of "test.txt" in dec_io_6.f90 was an artifact of me using
> the same "test.txt" file for all dec_io_1 through dec_io_5 in my own
> private tests. Thus since "test.txt" already existed from my own tests
> I didn't catch when I forgot to switch to "dec_io_6.txt" before
> submitting. I had the XFAIL in because I thought the DG failure was
> coming from the runtime warning. I guess the fail was actually
> happening because "test.txt" didn't exist - now that I correctly
> renamed it to "dec_io_6.txt" you are right and the XFAIL is erroneous.
> I should actually use INQUIRE to check whether the file was deleted on
> close (it should not be for READONLY).
> 
> Do you know if there is there any way from DG to verify that a runtime
> warning is emitted?

Use dg-output for that.  And, if the test is supposed to exit with non-zero
exit status because of the runtime error, then also dg-shouldfail.

Jakub

Re: [PATCH, LIBGCC] Avoid count_leading_zeros with undefined result (PR 78067)

[Bernd Schmidt]

On 10/27/2016 01:27 PM, Bernd Edlinger wrote:

Hi,

by code reading I became aware that libgcc can call count_leading_zeros
in certain cases which can give undefined results.  This happens on
signed int128 -> float or double conversions, when the int128 is in the range
INT64_MAX+1 to UINT64_MAX.


Did you actually observe this? Because, prior to this code,


Index: libgcc2.c
===
--- libgcc2.c   (revision 241400)
+++ libgcc2.c   (working copy)
@@ -1643,6 +1643,11 @@
 hi = -(UWtype) hi;

   UWtype count, shift;
+#if !defined (COUNT_LEADING_ZEROS_0) || COUNT_LEADING_ZEROS_0 != W_TYPE_SIZE
+  if (hi == 0)
+count = W_TYPE_SIZE;
+  else
+#endif
   count_leading_zeros (count, hi);

   /* No leading bits means u == minimum.  */


we have:

  /* If there are no high bits set, fall back to one conversion.  */
  if ((Wtype)u == u)
return (FSTYPE)(Wtype)u;

  /* Otherwise, find the power of two.  */
  Wtype hi = u >> W_TYPE_SIZE;

which looks to me like it ensures that hi is != 0.


Bernd

Re: [PATCH, Fortran] DEC Compatibility: New I/O Specifiers CARRIAGECONTROL, READONLY, SHARE with -fdec

[Fritz Reese]

On Thu, Oct 27, 2016 at 8:49 AM, Fritz Reese  wrote:
> From: Fritz Reese 
> Date: Thu, 27 Oct 2016 08:46:33 -0400
> Subject: [PATCH] Fix some DEC I/O testcases.
>
> gcc/testsuite/gfortran.dg/
> * dec_io_5.f90: Rename 'test.txt' to 'dec_io_5.txt'.
> * dec_io_6.f90: Use 'dec_io_6.txt' and INQUIRE instead of XFAIL.
> ---
>  gcc/testsuite/gfortran.dg/dec_io_5.f90 |2 +-
>  gcc/testsuite/gfortran.dg/dec_io_6.f90 |   19 ---
>  2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/gcc/testsuite/gfortran.dg/dec_io_5.f90 
b/gcc/testsuite/gfortran.dg/dec_io_5.f90
index 9d44c6e..a99aa76 100644
--- a/gcc/testsuite/gfortran.dg/dec_io_5.f90
+++ b/gcc/testsuite/gfortran.dg/dec_io_5.f90
@@ -8,7 +8,7 @@
 implicit none
 
 integer :: fd = 8
-character(*), parameter :: f = "test.txt"
+character(*), parameter :: f = "dec_io_5.txt"
 character(10), volatile :: c
 c = 'write'
 
diff --git a/gcc/testsuite/gfortran.dg/dec_io_6.f90 
b/gcc/testsuite/gfortran.dg/dec_io_6.f90
index a0c0256..c34879a 100644
--- a/gcc/testsuite/gfortran.dg/dec_io_6.f90
+++ b/gcc/testsuite/gfortran.dg/dec_io_6.f90
@@ -1,4 +1,4 @@
-! { dg-do run "xfail *-*-*" }
+! { dg-do run }
 ! { dg-options "-fdec" }
 !
 ! Test that we get a run-time error for close-on-delete with READONLY.
@@ -7,9 +7,22 @@
 implicit none
 
 integer :: fd = 8
-character(*), parameter :: f = "test.txt"
+character(*), parameter :: f = "dec_io_6.txt"
+logical :: exists
+
+open(unit=fd,file=f,action='write')
+close(unit=fd)
 
 open(unit=fd,file=f,action='read',readonly)
-close(unit=fd,status='delete') ! XFAIL "protected by READONLY"
+close(unit=fd,status='delete') ! WARN "protected by READONLY"
+
+inquire(file=f, EXIST=exists)
+if (.not. exists) then
+  print *, 'file was not protected by READONLY!'
+  call abort()
+endif
+
+open(unit=fd,file=f,action='write')
+close(unit=fd,status='delete') ! cleanup
 
 end

Re: [PATCH, Fortran] DEC Compatibility: New I/O Specifiers CARRIAGECONTROL, READONLY, SHARE with -fdec

[Fritz Reese]

On Thu, Oct 27, 2016 at 8:16 AM, Jakub Jelinek  wrote:
> On Thu, Oct 27, 2016 at 07:46:16AM -0400, Fritz Reese wrote:
>> > Shouldn't something also remove dec_io_5.txt file if it is created?
>> > Shall the (now xfailed, so not implemented yet?) runtime error terminate
>> > the program, or can it be also just deleted later on?  If not,
>> > we'll need some dg-final cleanup-target-file or something similar that will
>> > remote_file target delete the file (similarly to cleanup-modules etc.).
>> >
>> > Jakub
>>
>> For dec_io_5, the program (intentionally) crashes because "ACTION
>> conflicts with READONLY" so dec_io_5.txt is never created.
>
> So why dec_io_6.f90 worked at all (if it ever worked)?
> And why the xfail when it works as expected?
>>
>> For dec_io_6, the "protected by READONLY" message is (intentionally) a
>> runtime warning and does not terminate the program, so the following
>> lines safely delete dec_io_6.txt.

The presence of "test.txt" in dec_io_6.f90 was an artifact of me using
the same "test.txt" file for all dec_io_1 through dec_io_5 in my own
private tests. Thus since "test.txt" already existed from my own tests
I didn't catch when I forgot to switch to "dec_io_6.txt" before
submitting. I had the XFAIL in because I thought the DG failure was
coming from the runtime warning. I guess the fail was actually
happening because "test.txt" didn't exist - now that I correctly
renamed it to "dec_io_6.txt" you are right and the XFAIL is erroneous.
I should actually use INQUIRE to check whether the file was deleted on
close (it should not be for READONLY).

Do you know if there is there any way from DG to verify that a runtime
warning is emitted?

---
Fritz Reese

From: Fritz Reese 
Date: Thu, 27 Oct 2016 08:46:33 -0400
Subject: [PATCH] Fix some DEC I/O testcases.

gcc/testsuite/gfortran.dg/
* dec_io_5.f90: Rename 'test.txt' to 'dec_io_5.txt'.
* dec_io_6.f90: Use 'dec_io_6.txt' and INQUIRE instead of XFAIL.
---
 gcc/testsuite/gfortran.dg/dec_io_5.f90 |2 +-
 gcc/testsuite/gfortran.dg/dec_io_6.f90 |   19 ---
 2 files changed, 17 insertions(+), 4 deletions(-)

[PATCH][GIMPLE FE] Dump anon SSA names w/o identifier

[Richard Biener]

The parser only groks those in declarations so make it easy and
emit them that way with -gimple.

Tested on x86_64-unknown-linux-gnu.

Richard.

2016-10-27  Richard Biener  

* tree-pretty-print.c (dump_generic_node): For -gimple dump
anonymous SSA names without identifier.

diff --git a/gcc/tree-pretty-print.c b/gcc/tree-pretty-print.c
index 69c79d6..096eefd 100644
--- a/gcc/tree-pretty-print.c
+++ b/gcc/tree-pretty-print.c
@@ -2706,7 +2706,8 @@ dump_generic_node (pretty_printer *pp, tree node, int 
spc, int flags,
  && SSA_NAME_VAR (node)
  && DECL_NAMELESS (SSA_NAME_VAR (node)))
dump_fancy_name (pp, SSA_NAME_IDENTIFIER (node));
- else
+ else if (! (flags & TDF_GIMPLE)
+  || SSA_NAME_VAR (node))
dump_generic_node (pp, SSA_NAME_IDENTIFIER (node),
   spc, flags, false);
}

[PATCH][GIMPLE FE] Handle non-SSA PHI args

[Richard Biener]

Tested on x86_64-unknown-linux-gnu.

Richard.

2016-10-27  Richard Biener  

* tree-into-ssa.c (rewrite_add_phi_arguments): Handle non-SSA
PHI arguments from the GIMPLE FE.

* gcc.dg/gimplefe-18.c: New testcase.

diff --git a/gcc/testsuite/gcc.dg/gimplefe-18.c 
b/gcc/testsuite/gcc.dg/gimplefe-18.c
new file mode 100644
index 000..ba918b2
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/gimplefe-18.c
@@ -0,0 +1,24 @@
+/* { dg-do compile } */
+/* { dg-options "-fgimple" } */
+
+int
+__GIMPLE () *
+foo ()
+{
+  int _1;
+  int j;
+  int *b;
+  _1 = 1;
+bb1:
+  if (_1)
+goto bb3;
+  else
+goto bb2;
+
+bb2:
+  b_2 = (int *)0;
+
+bb3:
+  b_4 = __PHI (bb1: , bb2: b_2);
+  return b_4;
+}
diff --git a/gcc/tree-into-ssa.c b/gcc/tree-into-ssa.c
index 7eaf8ae..0e78845 100644
--- a/gcc/tree-into-ssa.c
+++ b/gcc/tree-into-ssa.c
@@ -1383,10 +1383,11 @@ rewrite_add_phi_arguments (basic_block bb)
 
  phi = gsi.phi ();
  res = gimple_phi_result (phi);
- /* If we have pre-existing PHI its args may be different
-vars than existing vars */
+ /* If we have pre-existing PHI (via the GIMPLE FE) its args may
+be different vars than existing vars and they may be constants
+as well.  Note the following supports partial SSA for PHI args.  */
  argvar = gimple_phi_arg_def (phi, e->dest_idx);
- if (argvar && TREE_CODE (argvar) == SSA_NAME)
+ if (argvar && ! DECL_P (argvar))
continue;
  if (!argvar)
argvar = SSA_NAME_VAR (res);

[PATCH][GIMPLE FE] Rewrite SSA name parsing

[Richard Biener]

This re-writes SSA name parsing to support declarations of anonymous
SSA names (I restricted that to plaine _N thus w/o name for the moment
to cater a bit for the ambiguity).  It also should support non-SSA name
PHI args now (esp. addresses), but no testcase yet as there seem to
be bugs downstream.

Tested on x86_64-unknown-linux-gnu.

Richard.

2016-10-27  Richard Biener  

c/
* c-parser.c (c_parser_peek_nth_token): Export.
* c-parser.h (c_parser_peek_nth_token): Declare.
* gimple-parser.c (c_parser_parse_ssa_names): Remove.
(c_parser_parse_ssa_name_id): New function parsing a SSA name
identifier.
(c_parser_parse_ssa_name): New function parsing a SSA name.
(c_parser_gimple_postfix_expression): Make SSA name parsing
stricter, move default-def handling here.
(c_parser_gimple_declaration): Handle SSA name declarations.
(c_parser_gimple_expression): Use c_parser_gimple_unary_expression
for parsing PHI args.

* gcc.dg/gimplefe-17.c: New testcase.

diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
index f69121b..63385fc 100644
--- a/gcc/c/c-parser.c
+++ b/gcc/c/c-parser.c
@@ -453,7 +453,7 @@ c_parser_peek_2nd_token (c_parser *parser)
 /* Return a pointer to the Nth token from PARSER, reading it
in if necessary.  The N-1th token is already read in.  */
 
-static c_token *
+c_token *
 c_parser_peek_nth_token (c_parser *parser, unsigned int n)
 {
   /* N is 1-based, not zero-based.  */
diff --git a/gcc/c/c-parser.h b/gcc/c/c-parser.h
index f36e738..04fa681 100644
--- a/gcc/c/c-parser.h
+++ b/gcc/c/c-parser.h
@@ -133,6 +133,8 @@ enum c_lookahead_kind {
 
 
 extern c_token * c_parser_peek_token (c_parser *parser);
+extern c_token * c_parser_peek_2nd_token (c_parser *parser);
+extern c_token * c_parser_peek_nth_token (c_parser *parser, unsigned int n);
 extern bool c_parser_require (c_parser *parser, enum cpp_ttype type,
  const char *msgid);
 extern void c_parser_error (c_parser *parser, const char *gmsgid);
@@ -140,7 +142,6 @@ extern void c_parser_consume_token (c_parser *parser);
 extern void c_parser_skip_until_found (c_parser *parser, enum cpp_ttype type,
   const char *msgid);
 extern bool c_parser_next_token_starts_declspecs (c_parser *parser);
-extern c_token * c_parser_peek_2nd_token (c_parser *parser);
 bool c_parser_next_tokens_start_declaration (c_parser *parser);
 bool c_token_starts_typename (c_token *token);
 
diff --git a/gcc/c/gimple-parser.c b/gcc/c/gimple-parser.c
index 931a61f..7040071 100644
--- a/gcc/c/gimple-parser.c
+++ b/gcc/c/gimple-parser.c
@@ -72,7 +72,6 @@ static void c_parser_gimple_if_stmt (c_parser *, gimple_seq 
*);
 static void c_parser_gimple_switch_stmt (c_parser *, gimple_seq *);
 static void c_parser_gimple_return_stmt (c_parser *, gimple_seq *);
 static void c_finish_gimple_return (location_t, tree);
-static c_expr c_parser_parse_ssa_names (c_parser *);
 static tree c_parser_gimple_paren_condition (c_parser *);
 static vec *c_parser_gimple_expr_list (c_parser *,
vec **, vec *);
@@ -343,7 +342,7 @@ c_parser_gimple_expression (c_parser *parser, gimple_seq 
*seq)
c_parser_consume_token (parser);
  else
{
- arg = c_parser_parse_ssa_names (parser).value;
+ arg = c_parser_gimple_unary_expression (parser).value;
  vargs.safe_push (arg);
}
}
@@ -633,69 +632,76 @@ c_parser_gimple_unary_expression (c_parser *parser)
 }
 }
 
-/* Parse gimple ssa names.  */
+/* Decompose ID into base name (ID until ver_offset) and VERSION.  Return
+   true if ID matches a SSA name.  */
 
-static c_expr
-c_parser_parse_ssa_names (c_parser *parser)
+static bool
+c_parser_parse_ssa_name_id (tree id, unsigned *version, unsigned *ver_offset)
 {
-  tree id = NULL_TREE;
-  c_expr ret;
-  char *var_name = NULL, *var_version = NULL, *token = NULL;
-  ret.original_code = ERROR_MARK;
-  ret.original_type = NULL;
+  const char *token = IDENTIFIER_POINTER (id);
+  const char *var_version = strrchr (token, '_');
+  if (! var_version)
+return false;
 
-  /* SSA token string.  */
-  const char *ssa_token
-= IDENTIFIER_POINTER (c_parser_peek_token (parser)->value);
-  token = new char [strlen (ssa_token) + 1];
-  strcpy (token, ssa_token);
+  *ver_offset = var_version - token;
+  for (const char *p = var_version + 1; *p; ++p)
+if (! ISDIGIT (*p))
+  return false;
+  *version = atoi (var_version + 1);
+  return *version > 0;
+}
 
-  /* Separate var name and version.  */
-  var_version = strrchr (token, '_');
-  if (var_version)
-{
-  var_name = new char[var_version - token + 1];
-  memcpy (var_name, token, var_version - token);
-  var_name[var_version - token] = '\0';
-  id = get_identifier (var_name);
+/* Get at the actual SSA name ID with VERSION starting at 

Re: [PATCH, Fortran] DEC Compatibility: New I/O Specifiers CARRIAGECONTROL, READONLY, SHARE with -fdec

[Jakub Jelinek]

On Thu, Oct 27, 2016 at 07:46:16AM -0400, Fritz Reese wrote:
> > Shouldn't something also remove dec_io_5.txt file if it is created?
> > Shall the (now xfailed, so not implemented yet?) runtime error terminate
> > the program, or can it be also just deleted later on?  If not,
> > we'll need some dg-final cleanup-target-file or something similar that will
> > remote_file target delete the file (similarly to cleanup-modules etc.).
> >
> > Jakub
> 
> For dec_io_5, the program (intentionally) crashes because "ACTION
> conflicts with READONLY" so dec_io_5.txt is never created.

So why dec_io_6.f90 worked at all (if it ever worked)?
And why the xfail when it works as expected?
> 
> For dec_io_6, the "protected by READONLY" message is (intentionally) a
> runtime warning and does not terminate the program, so the following
> lines safely delete dec_io_6.txt.
> 
> I am not familiar enough with DG to know whether there is a better way
> to express the intended behavior of the test programs. XFAIL is the
> closest thing I could determine.

Jakub

Re: [RFC] Handle unary pass-through jump functions for ipa-vrp

[Martin Jambor]

Hi,

On Tue, Oct 25, 2016 at 10:18:25AM +1100, kugan wrote:
> Hi,
> 
> Attached RFC patch handles unary pass-through jump functions for ipa-vrp
> such that in the following case:
> 
> int bar (int j)
> {
>   foo (~j);
>   foo (abs (j));
>   foo (j);
>   return 0;
> }

Thanks for working on this.  Although I cannot approve your patches, I
do have a few comments inline:


> diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
> index 1dc5cb6..d0dc3d7 100644
> --- a/gcc/ipa-cp.c
> +++ b/gcc/ipa-cp.c
> @@ -122,6 +122,7 @@ along with GCC; see the file COPYING3.  If not see
>  #include "ipa-inline.h"
>  #include "ipa-utils.h"
>  #include "tree-ssa-ccp.h"
> +#include "gimple.h"
>  
>  template  class ipcp_value;
>  
> @@ -1221,7 +1222,12 @@ ipa_get_jf_pass_through_result (struct ipa_jump_func 
> *jfunc, tree input)
>  
>if (ipa_get_jf_pass_through_operation (jfunc) == NOP_EXPR)
>  return input;
> -  if (!is_gimple_ip_invariant (input))
> +
> +  if (!is_gimple_ip_invariant (input)
> +  /* TODO: Unary expressions are not handles in ipa constant
> +  propagation. */
> + || (TREE_CODE_CLASS (ipa_get_jf_pass_through_operation (jfunc))
> +   == tcc_unary))
>  return NULL_TREE;
>  
>if (TREE_CODE_CLASS (ipa_get_jf_pass_through_operation (jfunc))
> @@ -1845,7 +1851,8 @@ propagate_bits_accross_jump_function (cgraph_edge *cs, 
> int idx, ipa_jump_func *j
>  static bool
>  propagate_vr_accross_jump_function (cgraph_edge *cs,
>   ipa_jump_func *jfunc,
> - struct ipcp_param_lattices *dest_plats)
> + struct ipcp_param_lattices *dest_plats,
> + tree param_type)

Please also add a brief description of the new parameter to the
function comment.

>  {
>struct ipcp_param_lattices *src_lats;
>ipcp_vr_lattice *dest_lat = _plats->m_value_range;
> @@ -1863,18 +1870,43 @@ propagate_vr_accross_jump_function (cgraph_edge *cs,
>  
>if (ipa_get_jf_pass_through_operation (jfunc) == NOP_EXPR)
>   return dest_lat->meet_with (src_lats->m_value_range);
> +  else if (param_type
> +&& (TREE_CODE_CLASS (ipa_get_jf_pass_through_operation (jfunc))
> +== tcc_unary))
> + {
> +   value_range vr;
> +   memset (, 0, sizeof (vr));
> +   tree operand_type = ipa_get_type (caller_info, src_idx);
> +
> +   if (src_lats->m_value_range.bottom_p ())
> + return false;
> +
> +   extract_range_from_unary_expr (,
> +  ipa_get_jf_pass_through_operation 
> (jfunc),

Here you get over 80 characters of text width.  Tough to deal with, I
know, but please fix :-)

> +  param_type,
> +  _lats->m_value_range.m_vr,
> +  operand_type);
> +   return dest_lat->meet_with ();
> + }
>  }
> -  else if (jfunc->type == IPA_JF_CONST)
> +  else if (param_type
> +&& jfunc->type == IPA_JF_CONST)
>  {
>tree val = ipa_get_jf_constant (jfunc);
>if (TREE_CODE (val) == INTEGER_CST)
>   {
> +   value_range vr;
> if (TREE_OVERFLOW_P (val))
>   val = drop_tree_overflow (val);
> -   jfunc->vr_known = true;
> -   jfunc->m_vr.type = VR_RANGE;
> -   jfunc->m_vr.min = val;
> -   jfunc->m_vr.max = val;
> +
> +   vr.type = VR_RANGE;
> +   vr.min = val;
> +   vr.max = val;
> +   vr.equiv = NULL;
> +   extract_range_from_unary_expr (>m_vr,
> +  NOP_EXPR,
> +  param_type,
> +  , TREE_TYPE (val));

Do I understand it correctly that extract_range_from_unary_expr deals
with any potential type conversions better (compared to what you did
before here)?

Side note: I wonder whether it is a good idea to store the
intermediary result to the jump function.  I'd prefer if we did that
only after actually making transformation decisions, if at all.  But
that is only a minor nit and not something that needs to be addressed
as a part of this change.

> return dest_lat->meet_with (>m_vr);
>   }
>  }
> @@ -2220,6 +2252,7 @@ propagate_constants_accross_call (struct cgraph_edge 
> *cs)
>  {
>struct ipa_jump_func *jump_func = ipa_get_ith_jump_func (args, i);
>struct ipcp_param_lattices *dest_plats;
> +  tree param_type = ipa_get_callee_param_type (cs, i);
>  
>dest_plats = ipa_get_parm_lattices (callee_info, i);
>if (availability == AVAIL_INTERPOSABLE)
> @@ -2236,7 +2269,8 @@ propagate_constants_accross_call (struct cgraph_edge 
> *cs)
>  dest_plats);
> if (opt_for_fn (callee->decl, flag_ipa_vrp))
>   ret |= propagate_vr_accross_jump_function (cs,
> -jump_func, dest_plats);
> +  

Re: [PATCH] Fix bootstrap with --enable-languages=all,go

[Rainer Orth]

Hi Jeff,

> On 10/19/2016 06:13 AM, Rainer Orth wrote:
>> Hi Jakub,
>>
 2016-10-01  Rainer Orth  

* configure.ac (target_libraries): Readd target-boehm-gc.
Restore --enable-objc-gc handling.
* configure: Regenerate.
>>>
>>> This is incomplete.  I guess it can be committed as is, but should be
>>> followed by re-addition of:
>>>   bfin-*-*)
>>> noconfigdirs="$noconfigdirs target-boehm-gc"
>>> ;;
>>>   cris-*-* | crisv32-*-*)
>>> case "${target}" in
>>>   *-*-linux*)
>>> ;;
>>>   *) # See PR46792 regarding target-libffi.
>>> noconfigdirs="$noconfigdirs target-boehm-gc";;
>>> esac
>>> ;;
>>>   mmix-*-*)
>>> noconfigdirs="$noconfigdirs target-boehm-gc"
>>> ;;
>>> (perhaps in the same case as target-libffi handling).
>>
>> sorry I missed this.  I can still re-add it if desired, but would rather
>> keep it in a separate case from the target-libffi handling: in-tree
>> boehm-gc may be replaced with an external version, while libffi is
>> likely to stay for libgo.
> I think disabling of target-boehm-gc for these targets was because they
> didn't support Java for various reasons.   However, ISTM that we'd need it

but wouldn't it have been sufficient to just disable libjava in this
case?  boehm-gc was only dragged in for libjava (or --enable-objc-gc), IIUC.

> for objc-gc.  So I think we shouldn't be adding these hunks at this point.

Fine with me ;-)

> In theory we could build those targets after configuring with
> --eanble-objc-gc as a test.

True, but that would need complete cross-development environments for
those targets.  I'm certainly not up for that, especially not at this
point.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [PATCH] Fix bootstrap with --enable-languages=all,go

[Rainer Orth]

Hi Jeff,

> On 10/19/2016 06:13 AM, Rainer Orth wrote:
>> Hi Jakub,
>>
 2016-10-01  Rainer Orth  

* configure.ac (target_libraries): Readd target-boehm-gc.
Restore --enable-objc-gc handling.
* configure: Regenerate.
>>>
>>> This is incomplete.  I guess it can be committed as is, but should be
>>> followed by re-addition of:
>>>   bfin-*-*)
>>> noconfigdirs="$noconfigdirs target-boehm-gc"
>>> ;;
>>>   cris-*-* | crisv32-*-*)
>>> case "${target}" in
>>>   *-*-linux*)
>>> ;;
>>>   *) # See PR46792 regarding target-libffi.
>>> noconfigdirs="$noconfigdirs target-boehm-gc";;
>>> esac
>>> ;;
>>>   mmix-*-*)
>>> noconfigdirs="$noconfigdirs target-boehm-gc"
>>> ;;
>>> (perhaps in the same case as target-libffi handling).
>>
>> sorry I missed this.  I can still re-add it if desired, but would rather
>> keep it in a separate case from the target-libffi handling: in-tree
>> boehm-gc may be replaced with an external version, while libffi is
>> likely to stay for libgo.
> I think disabling of target-boehm-gc for these targets was because they
> didn't support Java for various reasons.   However, ISTM that we'd need it

but wouldn't it have been sufficient to just disable libjava in this
case?  boehm-gc was only dragged in for libjava (or --enable-objc-gc), IIUC.

> for objc-gc.  So I think we shouldn't be adding these hunks at this point.

Fine with me ;-)

> In theory we could build those targets after configuring with
> --eanble-objc-gc as a test.

True, but that would need complete cross-development environments for
those targets.  I'm certainly not up for that, especially not at this
point.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [PATCH] Fix bootstrap with --enable-languages=all,go

[Rainer Orth]

Hi Jeff,

> On 10/19/2016 06:13 AM, Rainer Orth wrote:
>> Hi Jakub,
>>
 2016-10-01  Rainer Orth  

* configure.ac (target_libraries): Readd target-boehm-gc.
Restore --enable-objc-gc handling.
* configure: Regenerate.
>>>
>>> This is incomplete.  I guess it can be committed as is, but should be
>>> followed by re-addition of:
>>>   bfin-*-*)
>>> noconfigdirs="$noconfigdirs target-boehm-gc"
>>> ;;
>>>   cris-*-* | crisv32-*-*)
>>> case "${target}" in
>>>   *-*-linux*)
>>> ;;
>>>   *) # See PR46792 regarding target-libffi.
>>> noconfigdirs="$noconfigdirs target-boehm-gc";;
>>> esac
>>> ;;
>>>   mmix-*-*)
>>> noconfigdirs="$noconfigdirs target-boehm-gc"
>>> ;;
>>> (perhaps in the same case as target-libffi handling).
>>
>> sorry I missed this.  I can still re-add it if desired, but would rather
>> keep it in a separate case from the target-libffi handling: in-tree
>> boehm-gc may be replaced with an external version, while libffi is
>> likely to stay for libgo.
> I think disabling of target-boehm-gc for these targets was because they
> didn't support Java for various reasons.   However, ISTM that we'd need it

but wouldn't it have been sufficient to just disable libjava in this
case?  boehm-gc was only dragged in for libjava (or --enable-objc-gc), IIUC.

> for objc-gc.  So I think we shouldn't be adding these hunks at this point.

Fine with me ;-)

> In theory we could build those targets after configuring with
> --eanble-objc-gc as a test.

True, but that would need complete cross-development environments for
those targets.  I'm certainly not up for that, especially not at this
point.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [PATCH] Fix bootstrap with --enable-languages=all,go

[Rainer Orth]

Hi Jeff,

> On 10/19/2016 06:13 AM, Rainer Orth wrote:
>> Hi Jakub,
>>
 2016-10-01  Rainer Orth  

* configure.ac (target_libraries): Readd target-boehm-gc.
Restore --enable-objc-gc handling.
* configure: Regenerate.
>>>
>>> This is incomplete.  I guess it can be committed as is, but should be
>>> followed by re-addition of:
>>>   bfin-*-*)
>>> noconfigdirs="$noconfigdirs target-boehm-gc"
>>> ;;
>>>   cris-*-* | crisv32-*-*)
>>> case "${target}" in
>>>   *-*-linux*)
>>> ;;
>>>   *) # See PR46792 regarding target-libffi.
>>> noconfigdirs="$noconfigdirs target-boehm-gc";;
>>> esac
>>> ;;
>>>   mmix-*-*)
>>> noconfigdirs="$noconfigdirs target-boehm-gc"
>>> ;;
>>> (perhaps in the same case as target-libffi handling).
>>
>> sorry I missed this.  I can still re-add it if desired, but would rather
>> keep it in a separate case from the target-libffi handling: in-tree
>> boehm-gc may be replaced with an external version, while libffi is
>> likely to stay for libgo.
> I think disabling of target-boehm-gc for these targets was because they
> didn't support Java for various reasons.   However, ISTM that we'd need it

but wouldn't it have been sufficient to just disable libjava in this
case?  boehm-gc was only dragged in for libjava (or --enable-objc-gc), IIUC.

> for objc-gc.  So I think we shouldn't be adding these hunks at this point.

Fine with me ;-)

> In theory we could build those targets after configuring with
> --eanble-objc-gc as a test.

True, but that would need complete cross-development environments for
those targets.  I'm certainly not up for that, especially not at this
point.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [PATCH, Fortran] DEC Compatibility: Logical operations on integers become bitwise ops with -fdec

[Fritz Reese]

How odd. Good catch.
---
Fritz Reese


On Thu, Oct 27, 2016 at 4:41 AM, Andreas Schwab  wrote:
> I have filed PR78128, this may be a target bug.
>
> Andreas.
>
> --
> Andreas Schwab, SUSE Labs, sch...@suse.de
> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
> "And now for something completely different."

Re: RFC [3/3] divmod transform v2 - add test cases

[Prathamesh Kulkarni]

On 24 October 2016 at 21:09, Prathamesh Kulkarni
 wrote:
> On 16 October 2016 at 11:31, Prathamesh Kulkarni
>  wrote:
>> Hi,
>> This patch adds test-cases for divmod transform.
>> OK to commit ?
> ping https://gcc.gnu.org/ml/gcc-patches/2016-10/msg01241.html
Hi Richard,
Could you please review this part:
https://gcc.gnu.org/ml/gcc-patches/2016-10/msg01241.html
It only adds test-cases for the divmod transform.
Is it OK to commit ?

Thanks,
Prathamesh
>
> Thanks,
> Prathamesh
>>
>> Thanks,
>> Prathamesh

Re: [PATCH, Fortran] DEC Compatibility: New I/O Specifiers CARRIAGECONTROL, READONLY, SHARE with -fdec

[Fritz Reese]

On Thu, Oct 27, 2016 at 7:32 AM, Jakub Jelinek <ja...@redhat.com> wrote:
> On Thu, Oct 27, 2016 at 07:25:24AM -0400, Fritz Reese wrote:
>> On Thu, Oct 27, 2016 at 7:02 AM Andreas Schwab <sch...@suse.de> wrote:
>> ...
>> > At line 12 of file 
>> > /usr/local/gcc/gcc-20161027/gcc/testsuite/gfortran.dg/dec_io_6.f90 (unit = 
>> > 8)
>> > Fortran runtime error: Cannot open file 'test.txt': No such file or 
>> > directory
>> >
>>
>> Indeed.
>
> Shouldn't something also remove dec_io_5.txt file if it is created?
> Shall the (now xfailed, so not implemented yet?) runtime error terminate
> the program, or can it be also just deleted later on?  If not,
> we'll need some dg-final cleanup-target-file or something similar that will
> remote_file target delete the file (similarly to cleanup-modules etc.).
>
> Jakub

For dec_io_5, the program (intentionally) crashes because "ACTION
conflicts with READONLY" so dec_io_5.txt is never created.

For dec_io_6, the "protected by READONLY" message is (intentionally) a
runtime warning and does not terminate the program, so the following
lines safely delete dec_io_6.txt.

I am not familiar enough with DG to know whether there is a better way
to express the intended behavior of the test programs. XFAIL is the
closest thing I could determine.

---
Fritz Reese

Re: [PATCH, Fortran] DEC Compatibility: New I/O Specifiers CARRIAGECONTROL, READONLY, SHARE with -fdec

[Jakub Jelinek]

On Thu, Oct 27, 2016 at 07:25:24AM -0400, Fritz Reese wrote:
> On Thu, Oct 27, 2016 at 7:02 AM Andreas Schwab <sch...@suse.de> wrote:
> ...
> > At line 12 of file 
> > /usr/local/gcc/gcc-20161027/gcc/testsuite/gfortran.dg/dec_io_6.f90 (unit = 
> > 8)
> > Fortran runtime error: Cannot open file 'test.txt': No such file or 
> > directory
> >
> 
> Indeed.

Shouldn't something also remove dec_io_5.txt file if it is created?
Shall the (now xfailed, so not implemented yet?) runtime error terminate
the program, or can it be also just deleted later on?  If not,
we'll need some dg-final cleanup-target-file or something similar that will
remote_file target delete the file (similarly to cleanup-modules etc.).

Jakub

[PATCH, LIBGCC] Avoid count_leading_zeros with undefined result (PR 78067)

[Bernd Edlinger]

Hi,

by code reading I became aware that libgcc can call count_leading_zeros
in certain cases which can give undefined results.  This happens on
signed int128 -> float or double conversions, when the int128 is in the range
INT64_MAX+1 to UINT64_MAX.

On x86_64, there is (more or less by chance) no visible effect, because a
"BSR esi, esi" instruction is used, which leaves the esi register unchanged,
thus the result is only off by one, but that may change at any time.

This precautionary patch uses COUNT_LEADING_ZEROS_0 to check
what the result of count_leading_zeros(0) will be, and avoids that call
if the result is not W_TYPE_SIZE.

Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?


Thanks
Bernd.2016-10-27  Bernd Edlinger  

	PR libgcc/78067
	* libgcc2.c (__floatdisf, __floatdidf): Avoid undefined results from
	count_leading_zeros.

Index: libgcc2.c
===
--- libgcc2.c	(revision 241400)
+++ libgcc2.c	(working copy)
@@ -1643,6 +1643,11 @@
 hi = -(UWtype) hi;
 
   UWtype count, shift;
+#if !defined (COUNT_LEADING_ZEROS_0) || COUNT_LEADING_ZEROS_0 != W_TYPE_SIZE
+  if (hi == 0)
+count = W_TYPE_SIZE;
+  else
+#endif
   count_leading_zeros (count, hi);
 
   /* No leading bits means u == minimum.  */

Re: [PATCH][AARCH64]Skip gcc.target/aarch64/pr66912.c in tiny or large memory model.

[Renlin Li]

Hi,

On 27/10/16 11:48, Szabolcs Nagy wrote:

On 27/10/16 11:25, Renlin Li wrote:

Hi all,

This a simple patch to fix gcc.target/aarch64/pr66912.c.
It's a test case only applicable to small memory model which is the default
one.



   /* { dg-final { scan-assembler ":got(page_lo15)?:n_common" } } */

i think this is supposed to work on tiny and small model as well.
(:got:var vs :gotpage_lo15:var)


Sorry, I didn't aware it's a regex which will match both.


it will have to be updated for large model when we have support for that.


yes, large memory model will have different relocation for this case, which will
not be caught by this pattern.

Regards,
Renlin




It has been tested to run only when the memory model is small.
Okay to commit?

Regards,
Renlin Li

gcc/testsuite/ChangeLog:

2016-10-27  Renlin Li  

 * gcc.target/aarch64/pr66912.c: Skip tiny and large memory model.

Re: [PATCH, Fortran] DEC Compatibility: New I/O Specifiers CARRIAGECONTROL, READONLY, SHARE with -fdec

[Fritz Reese]

On Thu, Oct 27, 2016 at 7:02 AM Andreas Schwab <sch...@suse.de> wrote:
...
> At line 12 of file 
> /usr/local/gcc/gcc-20161027/gcc/testsuite/gfortran.dg/dec_io_6.f90 (unit = 8)
> Fortran runtime error: Cannot open file 'test.txt': No such file or directory
>

Indeed.

From: Fritz Reese <fritzore...@gmail.com>
Date: Thu, 27 Oct 2016 07:07:43 -0400
Subject: [PATCH] Fix open of nonexistant file in DEC I/O testcase.

gcc/testsuite/gfortran.dg/
* dec_io_5.f90: Rename 'test.txt' to 'dec_io_5.txt'
* dec_io_6.f90: Create 'dec_io_6.txt' before reading it
---
 gcc/testsuite/gfortran.dg/dec_io_5.f90 |2 +-
 gcc/testsuite/gfortran.dg/dec_io_6.f90 |8 +++-
 2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/gcc/testsuite/gfortran.dg/dec_io_5.f90 
b/gcc/testsuite/gfortran.dg/dec_io_5.f90
index 9d44c6e..a99aa76 100644
--- a/gcc/testsuite/gfortran.dg/dec_io_5.f90
+++ b/gcc/testsuite/gfortran.dg/dec_io_5.f90
@@ -8,7 +8,7 @@
 implicit none
 
 integer :: fd = 8
-character(*), parameter :: f = "test.txt"
+character(*), parameter :: f = "dec_io_5.txt"
 character(10), volatile :: c
 c = 'write'
 
diff --git a/gcc/testsuite/gfortran.dg/dec_io_6.f90 
b/gcc/testsuite/gfortran.dg/dec_io_6.f90
index a0c0256..3c9ae5d 100644
--- a/gcc/testsuite/gfortran.dg/dec_io_6.f90
+++ b/gcc/testsuite/gfortran.dg/dec_io_6.f90
@@ -7,9 +7,15 @@
 implicit none
 
 integer :: fd = 8
-character(*), parameter :: f = "test.txt"
+character(*), parameter :: f = "dec_io_6.txt"
+
+open(unit=fd,file=f,action='write')
+close(unit=fd)
 
 open(unit=fd,file=f,action='read',readonly)
 close(unit=fd,status='delete') ! XFAIL "protected by READONLY"
 
+open(unit=fd,file=f,action='write')
+close(unit=fd,status='delete')
+
 end

Re: [PATCH, Fortran] DEC Compatibility: New I/O Specifiers CARRIAGECONTROL, READONLY, SHARE with -fdec

[Jakub Jelinek]

On Thu, Oct 27, 2016 at 01:02:31PM +0200, Andreas Schwab wrote:
> On Okt 25 2016, Fritz Reese <fritzore...@gmail.com> wrote:
> 
> > diff --git a/gcc/testsuite/gfortran.dg/dec_io_6.f90 
> > b/gcc/testsuite/gfortran.dg/dec_io_6.f90
> > new file mode 100644
> > index 000..a0c0256
> > --- /dev/null
> > +++ b/gcc/testsuite/gfortran.dg/dec_io_6.f90
> > @@ -0,0 +1,15 @@
> > +! { dg-do run "xfail *-*-*" }
> > +! { dg-options "-fdec" }
> > +!
> > +! Test that we get a run-time error for close-on-delete with READONLY.
> > +!
> > +
> > +implicit none
> > +
> > +integer :: fd = 8
> > +character(*), parameter :: f = "test.txt"
> > +
> > +open(unit=fd,file=f,action='read',readonly)
> > +close(unit=fd,status='delete') ! XFAIL "protected by READONLY"
> > +
> > +end
> 
> At line 12 of file 
> /usr/local/gcc/gcc-20161027/gcc/testsuite/gfortran.dg/dec_io_6.f90 (unit = 8)
> Fortran runtime error: Cannot open file 'test.txt': No such file or directory

Seems dec_io_6.f90 assumes that dec_io_5.f90 creates test.txt and
dec_io_6.f90 will then read it and remove.
But that is just wrong assumption when using make -jN check-gfortran,
each test could be run in a different directory.

Jakub

Re: [PATCH, Fortran] DEC Compatibility: New I/O Specifiers CARRIAGECONTROL, READONLY, SHARE with -fdec

[Andreas Schwab]

On Okt 25 2016, Fritz Reese <fritzore...@gmail.com> wrote:

> diff --git a/gcc/testsuite/gfortran.dg/dec_io_6.f90 
> b/gcc/testsuite/gfortran.dg/dec_io_6.f90
> new file mode 100644
> index 000..a0c0256
> --- /dev/null
> +++ b/gcc/testsuite/gfortran.dg/dec_io_6.f90
> @@ -0,0 +1,15 @@
> +! { dg-do run "xfail *-*-*" }
> +! { dg-options "-fdec" }
> +!
> +! Test that we get a run-time error for close-on-delete with READONLY.
> +!
> +
> +implicit none
> +
> +integer :: fd = 8
> +character(*), parameter :: f = "test.txt"
> +
> +open(unit=fd,file=f,action='read',readonly)
> +close(unit=fd,status='delete') ! XFAIL "protected by READONLY"
> +
> +end

At line 12 of file 
/usr/local/gcc/gcc-20161027/gcc/testsuite/gfortran.dg/dec_io_6.f90 (unit = 8)
Fortran runtime error: Cannot open file 'test.txt': No such file or directory

Andreas.

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

Re: [patch,testsuite] Support dg-require-effective-target label_offsets.

[Bernd Schmidt]

On 10/27/2016 12:16 PM, Georg-Johann Lay wrote:

Now imagine some arithmetic like & - &  This might result in
one or two stub addresses, and difference between such addresses is a
complete different thing than the difference between the original
labels:  The result might differ in absolute value and in sign, i.e. you
can't even determine whether LAB1 or LAB2 comes first in the generated
code as the order of stubs might differ from the order of respective
labels.


Ok, so you can't expect to use the value directly, but I think this is 
not too different from other targets. You still should be able to add 
the difference back to & and expect to get & or gs(&). 
That's what the execution test does - why isn't this working?



Bernd

Re: [PATCH][AARCH64]Skip gcc.target/aarch64/pr66912.c in tiny or large memory model.

[Szabolcs Nagy]

On 27/10/16 11:25, Renlin Li wrote:
> Hi all,
> 
> This a simple patch to fix gcc.target/aarch64/pr66912.c.
> It's a test case only applicable to small memory model which is the default
> one.
> 

  /* { dg-final { scan-assembler ":got(page_lo15)?:n_common" } } */

i think this is supposed to work on tiny and small model as well.
(:got:var vs :gotpage_lo15:var)

it will have to be updated for large model when we have support for that.

> It has been tested to run only when the memory model is small.
> Okay to commit?
> 
> Regards,
> Renlin Li
> 
> gcc/testsuite/ChangeLog:
> 
> 2016-10-27  Renlin Li  
> 
> * gcc.target/aarch64/pr66912.c: Skip tiny and large memory model.

Re: [PATCHv2 4/7, GCC, ARM, V8M] ARMv8-M Security Extension's cmse_nonsecure_entry: clear registers

[Kyrill Tkachov]

On 27/10/16 11:00, Andre Vieira (lists) wrote:

On 26/10/16 17:30, Kyrill Tkachov wrote:

On 26/10/16 17:26, Andre Vieira (lists) wrote:

On 26/10/16 13:51, Kyrill Tkachov wrote:

Hi Andre,

On 25/10/16 17:29, Andre Vieira (lists) wrote:

On 24/08/16 12:01, Andre Vieira (lists) wrote:

On 25/07/16 14:23, Andre Vieira (lists) wrote:

This patch extends support for the ARMv8-M Security Extensions
'cmse_nonsecure_entry' attribute to safeguard against leak of
information through unbanked registers.

When returning from a nonsecure entry function we clear all
caller-saved
registers that are not used to pass return values, by writing either
the
LR, in case of general purpose registers, or the value 0, in case
of FP
registers. We use the LR to write to APSR and FPSCR too. We
currently do
not support entry functions that pass arguments or return
variables on
the stack and we diagnose this. This patch relies on the existing
code
to make sure callee-saved registers used in cmse_nonsecure_entry
functions are saved and restored thus retaining their nonsecure mode
value, this should be happening already as it is required by AAPCS.

This patch also clears padding bits for cmse_nonsecure_entry
functions
with struct and union return types. For unions a bit is only
considered
a padding bit if it is an unused bit in every field of that union.
The
function that calculates these is used in a later patch to do the
same
for arguments of cmse_nonsecure_call's.

*** gcc/ChangeLog ***
2016-07-25  Andre Vieira
   Thomas Preud'homme  

   * config/arm/arm.c (output_return_instruction): Clear
   registers.
   (thumb2_expand_return): Likewise.
   (thumb1_expand_epilogue): Likewise.
   (thumb_exit): Likewise.
   (arm_expand_epilogue): Likewise.
   (cmse_nonsecure_entry_clear_before_return): New.
   (comp_not_to_clear_mask_str_un): New.
   (compute_not_to_clear_mask): New.
   * config/arm/thumb1.md (*epilogue_insns): Change length
attribute.
   * config/arm/thumb2.md (*thumb2_return): Likewise.

*** gcc/testsuite/ChangeLog ***
2016-07-25  Andre Vieira
   Thomas Preud'homme  

   * gcc.target/arm/cmse/cmse.exp: Test different multilibs
separate.
   * gcc.target/arm/cmse/struct-1.c: New.
   * gcc.target/arm/cmse/bitfield-1.c: New.
   * gcc.target/arm/cmse/bitfield-2.c: New.
   * gcc.target/arm/cmse/bitfield-3.c: New.
   * gcc.target/arm/cmse/baseline/cmse-2.c: Test that
registers are
cleared.
   * gcc.target/arm/cmse/mainline/soft/cmse-5.c: New.
   * gcc.target/arm/cmse/mainline/hard/cmse-5.c: New.
   * gcc.target/arm/cmse/mainline/hard-sp/cmse-5.c: New.
   * gcc.target/arm/cmse/mainline/softfp/cmse-5.c: New.
   * gcc.target/arm/cmse/mainline/softfp-sp/cmse-5.c: New.


Updated this patch to correctly clear only the cumulative
exception-status (0-4,7) and the condition code bits (28-31) of the
FPSCR. I also adapted the code to be handle the bigger floating point
register files.



This patch extends support for the ARMv8-M Security Extensions
'cmse_nonsecure_entry' attribute to safeguard against leak of
information through unbanked registers.

When returning from a nonsecure entry function we clear all
caller-saved
registers that are not used to pass return values, by writing
either the
LR, in case of general purpose registers, or the value 0, in case
of FP
registers. We use the LR to write to APSR. For FPSCR we clear only the
cumulative exception-status (0-4, 7) and the condition code bits
(28-31). We currently do not support entry functions that pass
arguments
or return variables on the stack and we diagnose this. This patch
relies
on the existing code to make sure callee-saved registers used in
cmse_nonsecure_entry functions are saved and restored thus retaining
their nonsecure mode value, this should be happening already as it is
required by AAPCS.

This patch also clears padding bits for cmse_nonsecure_entry functions
with struct and union return types. For unions a bit is only
considered
a padding bit if it is an unused bit in every field of that union. The
function that calculates these is used in a later patch to do the same
for arguments of cmse_nonsecure_call's.

*** gcc/ChangeLog ***
2016-07-xx  Andre Vieira
   Thomas Preud'homme  

   * config/arm/arm.c (output_return_instruction): Clear
   registers.
   (thumb2_expand_return): Likewise.
   (thumb1_expand_epilogue): Likewise.
   (thumb_exit): Likewise.
   (arm_expand_epilogue): Likewise.
   (cmse_nonsecure_entry_clear_before_return): New.
   (comp_not_to_clear_mask_str_un): New.
   

Re: [PATCH][GIMPLE FE] Split out parser into separate file

[Richard Biener]

On Thu, 27 Oct 2016, Trevor Saunders wrote:

> On Thu, Oct 27, 2016 at 09:28:31AM +0200, Richard Biener wrote:
> > On Thu, 27 Oct 2016, Trevor Saunders wrote:
> > 
> > > On Tue, Oct 25, 2016 at 03:33:36PM +0200, Richard Biener wrote:
> > > > 
> > > > Hi,
> > > > 
> > > > so I did the massaging to split out the GIMPLE parsing routines out
> > > > to a separate file (quite tricky to get the gengtype issues correctly
> > > > so I thought to help out here and get things started).
> > > 
> > > actually it looks like you didn't get the gengtype issues quiet right :(
> > > stage 1 is fine, but when doing a bootstrap stage 2 dies trying to build
> > > cc1obj.  That's because objc pulls in c-parser.o, but not c-lang.o which
> > > means that the gengtype routines for c_parser which are in
> > > gt-c-c-parser.h (included by c-parser.c) are included in cc1obj, but the
> > > routines for vec are not because they get put in
> > > gengtype-c.h which is included in c-lang.c.  Unfortunately I'm not sure
> > > how to fix that off hand.
> > 
> > Hohumm.  I've only bootstrapped with --enable-languages=c but indeed
> > I can reproduce this...
> > 
> > Indeed this was also the reason I had to add c-parser.h as #include
> > to c-lang.c ...
> > 
> > > Killing pch and moving c_parser out of gc memory would of course be one
> > > answer, but that's a rather massive hammer to use.
> > 
> > Yeah...
> 
> The more I think about it the more I think gc causes so much trouble pch
> has to go and we can try replace it with something better when possible,
> but gcc 8 at this point.

Yeah, well ...

> > So the only thing I came up with was to privatize c_parser again
> > and provide some extra abstraction for accessing ->error and ->tokens_buf.
> 
> yuk, but I don't have anything better still.

The other idea was to simply force the equivalent into gtype-objc.h but
I failed to do that by simply including c-parser.h from objc.

Or hack gengtype (or in the first place try to understand why it does
it the way it does...)

Richard.

[libgcc] Protect __TMC_END__ - __TMC_LIST__ == 0

[Marc Glisse]

Hello,

some optimization patch I was working on simplified __TMC_END__ - 
__TMC_LIST__ == 0 to false, which is not wanted (I assume that's why it 
wasn't written __TMC_END__ == __TMC_LIST__ in the first place).


Bootstrap+regtest on powerpc64le-unknown-linux-gnu.

2016-10-27  Marc Glisse  

PR libgcc/77813
* crtstuff.c (deregister_tm_clones, register_tm_clones): Hide
__TMC_END__ behind a passthrough asm.

--
Marc GlisseIndex: libgcc/crtstuff.c
===
--- libgcc/crtstuff.c	(revision 241611)
+++ libgcc/crtstuff.c	(working copy)
@@ -273,41 +273,47 @@ STATIC func_ptr __TMC_LIST__[]
 # ifdef HAVE_GAS_HIDDEN
 extern func_ptr __TMC_END__[] __attribute__((__visibility__ ("hidden")));
 # endif
 
 static inline void
 deregister_tm_clones (void)
 {
   void (*fn) (void *);
 
 #ifdef HAVE_GAS_HIDDEN
-  if (__TMC_END__ - __TMC_LIST__ == 0)
+  func_ptr *end = __TMC_END__;
+  // Do not optimize the comparison to false.
+  __asm ("" : "+g" (end));
+  if (__TMC_LIST__ == end)
 return;
 #else
   if (__TMC_LIST__[0] == NULL)
 return;
 #endif
 
   fn = _ITM_deregisterTMCloneTable;
   __asm ("" : "+r" (fn));
   if (fn)
 fn (__TMC_LIST__);
 }
 
 static inline void
 register_tm_clones (void)
 {
   void (*fn) (void *, size_t);
   size_t size;
 
 #ifdef HAVE_GAS_HIDDEN
-  size = (__TMC_END__ - __TMC_LIST__) / 2;
+  func_ptr *end = __TMC_END__;
+  // Do not optimize the comparison to false.
+  __asm ("" : "+g" (end));
+  size = (end - __TMC_LIST__) / 2;
 #else
   for (size = 0; __TMC_LIST__[size * 2] != NULL; size++)
 continue;
 #endif
   if (size == 0)
 return;
 
   fn = _ITM_registerTMCloneTable;
   __asm ("" : "+r" (fn));
   if (fn)

[PATCH][AARCH64]Skip gcc.target/aarch64/pr66912.c in tiny or large memory model.

[Renlin Li]

Hi all,

This a simple patch to fix gcc.target/aarch64/pr66912.c.
It's a test case only applicable to small memory model which is the default
one.

It has been tested to run only when the memory model is small.
Okay to commit?

Regards,
Renlin Li

gcc/testsuite/ChangeLog:

2016-10-27  Renlin Li  

* gcc.target/aarch64/pr66912.c: Skip tiny and large memory model.
commit 364538b449d62c9a411b31021bdd9f355d36edf1
Author: Renlin Li 
Date:   Wed Jan 6 14:00:16 2016 +

fix pr66912.c

diff --git a/gcc/testsuite/gcc.target/aarch64/pr66912.c b/gcc/testsuite/gcc.target/aarch64/pr66912.c
index b8aabcd..be07641 100644
--- a/gcc/testsuite/gcc.target/aarch64/pr66912.c
+++ b/gcc/testsuite/gcc.target/aarch64/pr66912.c
@@ -1,5 +1,7 @@
 /* { dg-do compile { target *-*-linux* } } */
+/* { dg-require-effective-target aarch64_small_fpic } */
 /* { dg-options "-O2 -fpic" } */
+/* { dg-skip-if "small memory model" { aarch64*-*-* }  { "-mcmodel=tiny" "-mcmodel=large" } { "" } } */
 
 __attribute__((visibility("protected")))
 int n_common;

Re: [PATCH, ARM 5/7, ping3] Adapt other atomic operations to ARMv8-M Baseline

[Thomas Preudhomme]

On 27/10/16 09:50, Kyrill Tkachov wrote:

Hi Thomas,

On 24/10/16 09:05, Thomas Preudhomme wrote:

Ping?

Best regards,

Thomas

On 14/10/16 14:51, Thomas Preudhomme wrote:

Ping?

Best regards,

Thomas

On 03/10/16 17:45, Thomas Preudhomme wrote:

Ping?

Best regards,

Thomas

On 22/09/16 14:47, Thomas Preudhomme wrote:

Hi,

This patch is part of a patch series to add support for atomic operations on
ARMv8-M Baseline targets in GCC. This specific patch adds support for
remaining
atomic operations (exchange, addition, substraction, bitwise AND, OR, XOR and
NAND to ARMv8-M Baseline, doubleword integers excepted. As with the previous
patch in the patch series, this mostly consists adding Thumb-1 specific
constraints to atomic_* patterns to match those in thumb1.md for the non
atomic
operation.

ChangeLog entry is as follows:

*** gcc/ChangeLog ***

2016-09-02  Thomas Preud'homme 

* config/arm/arm.c (arm_split_atomic_op): Add function comment.  Add
logic to to decide whether to copy over old value to register for new
value.
* config/arm/sync.md: Add comments explaning why mode and code
attribute are not defined in iterators.md
(thumb1_atomic_op_str): New code attribute.
(thumb1_atomic_newop_str): Likewise.
(thumb1_atomic_fetch_op_str): Likewise.
(thumb1_atomic_fetch_newop_str): Likewise.
(thumb1_atomic_fetch_oldop_str): Likewise.
(atomic_exchange): Add new ARMv8-M Baseline only alternatives to
mirror the more restrictive constraints of the Thumb-1 insns after
split compared to Thumb-2 counterpart insns.
(atomic_): Likewise. Add comment to keep constraints
in sync with non atomic version.
(atomic_nand): Likewise.
(atomic_fetch_): Likewise.
(atomic_fetch_nand): Likewise.
(atomic__fetch): Likewise.
(atomic_nand_fetch): Likewise.
* config/arm/thumb1.md (thumb1_addsi3): Add comment to keep contraint
in sync with atomic version.
(thumb1_subsi3_insn): Likewise.
(thumb1_andsi3_insn): Likewise.
(thumb1_iorsi3_insn): Likewise.
(thumb1_xorsi3_insn): Likewise.


Testing: No code generation difference for ARMv7-A, ARMv7VE and ARMv8-A on all
atomic and synchronization testcases in the testsuite [2]. Patchset was also
bootstrapped with --enable-itm --enable-gomp on ARMv8-A in ARM and Thumb
mode at
optimization level -O1 and above [1] without any regression in the
testsuite and
no code generation difference in libitm and libgomp.

Code generation for ARMv8-M Baseline has been manually examined and compared
against ARMv8-A Thumb-2 for the following configuration without finding any
issue:

gcc.dg/atomic-op-2.c at -Os
gcc.dg/atomic-compare-exchange-2.c at -Os
gcc.dg/atomic-compare-exchange-3.c at -O3


Is this ok for trunk?

Best regards,

Thomas

[1] CFLAGS_FOR_TARGET and CXXFLAGS_FOR_TARGET were set to "-O1 -g", "-O3
-g" and
undefined ("-O2 -g")
[2] The exact list is:

gcc/testsuite/gcc.dg/atomic-compare-exchange-1.c
gcc/testsuite/gcc.dg/atomic-compare-exchange-2.c
gcc/testsuite/gcc.dg/atomic-compare-exchange-3.c
gcc/testsuite/gcc.dg/atomic-exchange-1.c
gcc/testsuite/gcc.dg/atomic-exchange-2.c
gcc/testsuite/gcc.dg/atomic-exchange-3.c
gcc/testsuite/gcc.dg/atomic-fence.c
gcc/testsuite/gcc.dg/atomic-flag.c
gcc/testsuite/gcc.dg/atomic-generic.c
gcc/testsuite/gcc.dg/atomic-generic-aux.c
gcc/testsuite/gcc.dg/atomic-invalid-2.c
gcc/testsuite/gcc.dg/atomic-load-1.c
gcc/testsuite/gcc.dg/atomic-load-2.c
gcc/testsuite/gcc.dg/atomic-load-3.c
gcc/testsuite/gcc.dg/atomic-lockfree.c
gcc/testsuite/gcc.dg/atomic-lockfree-aux.c
gcc/testsuite/gcc.dg/atomic-noinline.c
gcc/testsuite/gcc.dg/atomic-noinline-aux.c
gcc/testsuite/gcc.dg/atomic-op-1.c
gcc/testsuite/gcc.dg/atomic-op-2.c
gcc/testsuite/gcc.dg/atomic-op-3.c
gcc/testsuite/gcc.dg/atomic-op-6.c
gcc/testsuite/gcc.dg/atomic-store-1.c
gcc/testsuite/gcc.dg/atomic-store-2.c
gcc/testsuite/gcc.dg/atomic-store-3.c
gcc/testsuite/g++.dg/ext/atomic-1.C
gcc/testsuite/g++.dg/ext/atomic-2.C
gcc/testsuite/gcc.target/arm/atomic-comp-swap-release-acquire.c
gcc/testsuite/gcc.target/arm/atomic-op-acq_rel.c
gcc/testsuite/gcc.target/arm/atomic-op-acquire.c
gcc/testsuite/gcc.target/arm/atomic-op-char.c
gcc/testsuite/gcc.target/arm/atomic-op-consume.c
gcc/testsuite/gcc.target/arm/atomic-op-int.c
gcc/testsuite/gcc.target/arm/atomic-op-relaxed.c
gcc/testsuite/gcc.target/arm/atomic-op-release.c
gcc/testsuite/gcc.target/arm/atomic-op-seq_cst.c
gcc/testsuite/gcc.target/arm/atomic-op-short.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_1.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_2.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_3.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_4.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_5.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_6.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_7.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_8.c

Re: [PATCHv2 2/7, GCC, ARM, V8M] Handling ARMv8-M Security Extension's cmse_nonsecure_entry attribute

[Kyrill Tkachov]

On 27/10/16 10:54, Andre Vieira (lists) wrote:

On 26/10/16 17:28, Kyrill Tkachov wrote:

On 26/10/16 17:28, Andre Vieira (lists) wrote:

On 26/10/16 10:33, Kyrill Tkachov wrote:

+static tree
+arm_handle_cmse_nonsecure_entry (tree *node, tree name,
+ tree /* args */,
+ int /* flags */,
+ bool *no_add_attrs)
+{
+  tree fndecl;
+
+  if (!use_cmse)
+{
+  *no_add_attrs = true;
+  return NULL_TREE;
+}

Do you also want to warn the user here that the attribute will be
ignored?
This looks ok to me otherwise.


Can easily do and might be more user friendly. How about
" attribute ignored without -mcmse option."

Yes, that's fine (without the full stop at the end)
Kyrill


Cheers,
Andre


Hi,

Reworked comments. No change to ChangeLogs.


Ok.
Thanks,
Kyrill


Cheers,
Andre

Re: [PATCH][GIMPLE FE] Split out parser into separate file

[Trevor Saunders]

On Thu, Oct 27, 2016 at 09:28:31AM +0200, Richard Biener wrote:
> On Thu, 27 Oct 2016, Trevor Saunders wrote:
> 
> > On Tue, Oct 25, 2016 at 03:33:36PM +0200, Richard Biener wrote:
> > > 
> > > Hi,
> > > 
> > > so I did the massaging to split out the GIMPLE parsing routines out
> > > to a separate file (quite tricky to get the gengtype issues correctly
> > > so I thought to help out here and get things started).
> > 
> > actually it looks like you didn't get the gengtype issues quiet right :(
> > stage 1 is fine, but when doing a bootstrap stage 2 dies trying to build
> > cc1obj.  That's because objc pulls in c-parser.o, but not c-lang.o which
> > means that the gengtype routines for c_parser which are in
> > gt-c-c-parser.h (included by c-parser.c) are included in cc1obj, but the
> > routines for vec are not because they get put in
> > gengtype-c.h which is included in c-lang.c.  Unfortunately I'm not sure
> > how to fix that off hand.
> 
> Hohumm.  I've only bootstrapped with --enable-languages=c but indeed
> I can reproduce this...
> 
> Indeed this was also the reason I had to add c-parser.h as #include
> to c-lang.c ...
> 
> > Killing pch and moving c_parser out of gc memory would of course be one
> > answer, but that's a rather massive hammer to use.
> 
> Yeah...

The more I think about it the more I think gc causes so much trouble pch
has to go and we can try replace it with something better when possible,
but gcc 8 at this point.

> So the only thing I came up with was to privatize c_parser again
> and provide some extra abstraction for accessing ->error and ->tokens_buf.

yuk, but I don't have anything better still.

Trev

Re: [patch,testsuite] Support dg-require-effective-target label_offsets.

[Georg-Johann Lay]

On 26.10.2016 18:51, Bernd Schmidt wrote:

On 10/26/2016 04:46 PM, Georg-Johann Lay wrote:

+if { [istarget avr-*-*] } {
+# If the value of a label does not fit into 16 bits, the linker
+# will generate a stub (containing a direct jump) and we end up
+# with the address of the stub instead of the address of the very
+# label.  Whereas it is legitimate to use such addresses for
+# indirect jumps, it makes no sense to perform any arithmetic
+# on such addresses.
+return [check_no_compiler_messages label_offsets assembly {
+#ifdef __AVR_3_BYTE_PC__
+#error NO
+#endif
+}]
+}
+return 1;


I'm not sure I understand the failure mode. Sure, you're not getting the
address of the actual label, but the address of one that's equivalent - so why
can't you do arithmetic on it? Where does it go wrong?


There are devices where the address of a label does not fit into 16 bits, which 
is a problem for indirect calls because not all of the program memory can be 
targeted by 16 bits.  The solution was to emit taking address of label LAB as 
gs(LAB) and let the linker resolve this ("gs" stands for "generate stub").


If LAB actually fits in 16 bits nothing special happens and we have LAB = 
gs(LAB).

If LAB doesn't fit then the linker generates a stub like:

gs_LAB:
   jump LAB

and resolves gs_LAB = gs(LAB).  gs_LAB must be located in the lower part of the 
program memory so that gs_LAB will fit into 16 bits.


An indirect call / jump then is 1) take address of LAB which returns gs_LAB and 
2) jump or call that address which jumps or calls gs_LAB which then jumps to LAB.


This works because absolute jumps and calls can target all of the program 
memory.  Moreover comparing gs() labels against each other or against 0 for 
(un)equality will also work as expected.


Now imagine some arithmetic like & - &  This might result in one or 
two stub addresses, and difference between such addresses is a complete 
different thing than the difference between the original labels:  The result 
might differ in absolute value and in sign, i.e. you can't even determine 
whether LAB1 or LAB2 comes first in the generated code as the order of stubs 
might differ from the order of respective labels.



Am I right in thinking that only the execution test actually fails?

Bernd


Some of the run tests are failing, but not all of them.  This is because gs() 
depends on code size and location.  But there are also some compile tests that 
fail as avr_print_operand_address tries to warn about such code with "pointer 
offset from symbol maybe incorrect".


Johann

[PATCH][GIMPLE FE] Fix SSA name parsing

[Richard Biener]

The following handles parsing SSA names where it belongs so that
p_1(D)->a also works.

Tested on x86_64-unknown-linux-gnu, applied.

Richard.

2016-10-27  Richard Biener  

c/
* gimple-parser.c (c_parser_gimple_unary_expression): Move
SSA name handling ...
(c_parser_gimple_postfix_expression): ... here.

* gcc.dg/gimplefe-16.c: New testcase.

diff --git a/gcc/c/gimple-parser.c b/gcc/c/gimple-parser.c
index bcfb677..931a61f 100644
--- a/gcc/c/gimple-parser.c
+++ b/gcc/c/gimple-parser.c
@@ -575,11 +575,6 @@ static c_expr
 c_parser_gimple_unary_expression (c_parser *parser)
 {
   struct c_expr ret, op;
-  if (c_parser_peek_token (parser)->type == CPP_NAME
-  && TREE_CODE (c_parser_peek_token (parser)->value) == IDENTIFIER_NODE
-  && ! lookup_name (c_parser_peek_token (parser)->value))
-return c_parser_parse_ssa_names (parser);
-
   location_t op_loc = c_parser_peek_token (parser)->location;
   location_t finish;
   ret.original_code = ERROR_MARK;
@@ -761,12 +756,17 @@ c_parser_gimple_postfix_expression (c_parser *parser)
   if (c_parser_peek_token (parser)->id_kind == C_ID_ID)
{
  tree id = c_parser_peek_token (parser)->value;
- c_parser_consume_token (parser);
- expr.value = build_external_ref (loc, id,
-  (c_parser_peek_token (parser)->type
-   == CPP_OPEN_PAREN),
-  _type);
- set_c_expr_source_range (, tok_range);
+ if (! lookup_name (id))
+   expr = c_parser_parse_ssa_names (parser);
+ else
+   {
+ c_parser_consume_token (parser);
+ expr.value
+   = build_external_ref (loc, id,
+ (c_parser_peek_token (parser)->type
+  == CPP_OPEN_PAREN), _type);
+ set_c_expr_source_range (, tok_range);
+   }
  break;
}
   else
diff --git a/gcc/testsuite/gcc.dg/gimplefe-16.c 
b/gcc/testsuite/gcc.dg/gimplefe-16.c
new file mode 100644
index 000..2949249
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/gimplefe-16.c
@@ -0,0 +1,18 @@
+/* { dg-do compile } */
+/* { dg-options "-O -fgimple" } */
+
+struct Y { int b[2]; };
+struct X { int a; struct Y y; };
+struct X x;
+
+int __GIMPLE ()
+foo (struct X *p, _Complex int q)
+{
+  int b;
+  b_1 = __real q;
+  p_4(D)->a = b_1;
+  x.y.b[b_1] = b_1;
+  b_2 = p->y.b[1];
+  b_3 = x.a;
+  return b_3;
+}

Re: [PATCHv2 1/7, GCC, ARM, V8M] Add support for ARMv8-M's Secure Extensions flag and intrinsics

[Kyrill Tkachov]

On 27/10/16 10:53, Andre Vieira (lists) wrote:

On 26/10/16 14:00, Kyrill Tkachov wrote:

On 26/10/16 10:12, Kyrill Tkachov wrote:

Hi Andre, thanks for resending them.

On 25/10/16 17:26, Andre Vieira (lists) wrote:

On 24/08/16 12:00, Andre Vieira (lists) wrote:

On 25/07/16 14:19, Andre Vieira (lists) wrote:

This patch adds the support of the '-mcmse' option to enable ARMv8-M's
Security Extensions and supports the following intrinsics:
cmse_TT
cmse_TT_fptr
cmse_TTT
cmse_TTT_fptr
cmse_TTA
cmse_TTA_fptr
cmse_TTAT
cmse_TTAT_fptr
cmse_check_address_range
cmse_check_pointed_object
cmse_is_nsfptr
cmse_nsfptr_create

It also defines the mandatory cmse_address_info struct and the
__ARM_FEATURE_CMSE macro.
See Chapter 4, Sections 5.2, 5.3 and 5.6 of ARM®v8-M Security
Extensions: Requirements on Development Tools
(http://infocenter.arm.com/help/topic/com.arm.doc.ecm0359818/index.html).


*** gcc/ChangeLog ***
2016-07-25  Andre Vieira 
  Thomas Preud'homme 

  * config.gcc (extra_headers): Added arm_cmse.h.
  * config/arm/arm-arches.def (ARM_ARCH):
  (armv8-m): Add FL2_CMSE.
  (armv8-m.main): Likewise.
  (armv8-m.main+dsp): Likewise.
  * config/arm/arm-c.c
  (arm_cpu_builtins): Added __ARM_FEATURE_CMSE macro.
  * config/arm/arm-protos.h
  (arm_is_constant_pool_ref): Define FL2_CMSE.
  * config/arm.c (arm_arch_cmse): New.
  (arm_option_override): New error for unsupported cmse target.
  * config/arm/arm.h (arm_arch_cmse): New.
  * config/arm/arm.opt (mcmse): New.
  * doc/invoke.texi (ARM Options): Add -mcmse.
  * config/arm/arm_cmse.h: New file.

*** libgcc/ChangeLog ***
2016-07-25  Andre Vieira 
  Thomas Preud'homme 

  * config/arm/cmse.c: Likewise.
  * config/arm/t-arm (HAVE_CMSE): New.

*** gcc/testsuite/ChangeLog ***
2016-07-25  Andre Vieira 
  Thomas Preud'homme 

  * gcc.target/arm/cmse/cmse.exp: New.
  * gcc.target/arm/cmse/cmse-1.c: New.
  * gcc.target/arm/cmse/cmse-12.c: New.
  * lib/target-supports.exp
  (check_effective_target_arm_cmse_ok): New.


Just remembered, new effective target checks should be documented in
sourcebuild.texi
Kyrill


Added more documentation as requested.

This patch adds the support of the '-mcmse' option to enable ARMv8-M's
Security Extensions and supports the following intrinsics:
cmse_TT
cmse_TT_fptr
cmse_TTT
cmse_TTT_fptr
cmse_TTA
cmse_TTA_fptr
cmse_TTAT
cmse_TTAT_fptr
cmse_check_address_range
cmse_check_pointed_object
cmse_is_nsfptr
cmse_nsfptr_create

It also defines the mandatory cmse_address_info struct and the
__ARM_FEATURE_CMSE macro.
See Chapter 4, Sections 5.2, 5.3 and 5.6 of ARM®v8-M Security
Extensions: Requirements on Development Tools
(http://infocenter.arm.com/help/topic/com.arm.doc.ecm0359818/index.html).


*** gcc/ChangeLog ***
2016-07-xx  Andre Vieira 
  Thomas Preud'homme 

  * config.gcc (extra_headers): Added arm_cmse.h.
  * config/arm/arm-arches.def (ARM_ARCH):
  (armv8-m): Add FL2_CMSE.
  (armv8-m.main): Likewise.
  (armv8-m.main+dsp): Likewise.
  * config/arm/arm-c.c
  (arm_cpu_builtins): Added __ARM_FEATURE_CMSE macro.
  * config/arm/arm-protos.h
  (arm_is_constant_pool_ref): Define FL2_CMSE.
  * config/arm.c (arm_arch_cmse): New.
  (arm_option_override): New error for unsupported cmse target.
  * config/arm/arm.h (arm_arch_cmse): New.
  * config/arm/arm.opt (mcmse): New.
  * doc/invoke.texi (ARM Options): Add -mcmse.
  * doc/extend.texi (ARM ARMv8-M Security Extensions): Add
section.
  * config/arm/arm_cmse.h: New file.

*** libgcc/ChangeLog ***
2016-07-xx  Andre Vieira 
  Thomas Preud'homme 
  * config/arm/cmse.c: Likewise.
  * config/arm/t-arm (HAVE_CMSE): New.


*** gcc/testsuite/ChangeLog ***
2016-07-xx  Andre Vieira 
  Thomas Preud'homme 

  * gcc.target/arm/cmse/cmse.exp: New.
  * gcc.target/arm/cmse/cmse-1.c: New.
  * gcc.target/arm/cmse/cmse-12.c: New.
  * lib/target-supports.exp
  (check_effective_target_arm_cmse_ok): New.


Hi,

Rebased previous patch on top of trunk as requested. No changes to
ChangeLog.

Cheers,
Andre

diff --git a/gcc/config/arm/arm_cmse.h b/gcc/config/arm/arm_cmse.h
new file mode 100644
index
..b4232937c6ae04754a6bbc513b143672a4be5530

--- /dev/null
+++ b/gcc/config/arm/arm_cmse.h



+
+#if 

Re: [PATCHv2 6/7, GCC, ARM, V8M] ARMv8-M Security Extension's cmse_nonsecure_call: use __gnu_cmse_nonsecure_call

[Andre Vieira (lists)]

On 25/10/16 17:30, Andre Vieira (lists) wrote:
> On 24/08/16 12:01, Andre Vieira (lists) wrote:
>> On 25/07/16 14:26, Andre Vieira (lists) wrote:
>>> This patch extends support for the ARMv8-M Security Extensions
>>> 'cmse_nonsecure_call' to use a new library function
>>> '__gnu_cmse_nonsecure_call'. This library function is responsible for
>>> (without using r0-r3 or d0-d7):
>>> 1) saving and clearing all callee-saved registers using the secure stack
>>> 2) clearing the LSB of the address passed in r4 and using blxns to
>>> 'jump' to it
>>> 3) clearing ASPR, including the 'ge bits' if DSP is enabled
>>> 4) clearing FPSCR if using non-soft float-abi
>>> 5) restoring callee-saved registers.
>>>
>>> The decisions whether to include DSP 'ge bits' clearing and floating
>>> point registers (single/double precision) all depends on the multilib used.
>>>
>>> See Section 5.5 of ARM®v8-M Security Extensions
>>> (http://infocenter.arm.com/help/topic/com.arm.doc.ecm0359818/index.html).
>>>
>>> *** gcc/ChangeLog ***
>>> 2016-07-25  Andre Vieira
>>> Thomas Preud'homme  
>>>
>>> * config/arm/arm.c (detect_cmse_nonsecure_call): New.
>>> (cmse_nonsecure_call_clear_caller_saved): New.
>>> (arm_reorg): Use cmse_nonsecure_call_clear_caller_saved.
>>> * config/arm/arm-protos.h (detect_cmse_nonsecure_call): New.
>>> * config/arm/arm.md (call): Handle cmse_nonsecure_entry.
>>> (call_value): Likewise.
>>> (nonsecure_call_internal): New.
>>> (nonsecure_call_value_internal): New.
>>> * config/arm/thumb1.md (*nonsecure_call_reg_thumb1_v5): New.
>>> (*nonsecure_call_value_reg_thumb1_v5): New.
>>> * config/arm/thumb2.md (*nonsecure_call_reg_thumb2): New.
>>> (*nonsecure_call_value_reg_thumb2): New.
>>> * config/arm/unspecs.md (UNSPEC_NONSECURE_MEM): New.
>>>
>>> *** libgcc/ChangeLog ***
>>> 2016-07-25  Andre Vieira
>>> Thomas Preud'homme  
>>>
>>> * config/arm/cmse_nonsecure_call.S: New.
>>> * config/arm/t-arm: Compile cmse_nonsecure_call.S
>>>
>>>
>>> *** gcc/testsuite/ChangeLog ***
>>> 2016-07-25  Andre Vieira
>>> Thomas Preud'homme  
>>>
>>> * gcc.target/arm/cmse/cmse.exp: Run tests in mainline dir.
>>> * gcc.target/arm/cmse/cmse-9.c: Added some extra tests.
>>> * gcc.target/arm/cmse/baseline/bitfield-4.c: New.
>>> * gcc.target/arm/cmse/baseline/bitfield-5.c: New.
>>> * gcc.target/arm/cmse/baseline/bitfield-6.c: New.
>>> * gcc.target/arm/cmse/baseline/bitfield-7.c: New.
>>> * gcc.target/arm/cmse/baseline/bitfield-8.c: New.
>>> * gcc.target/arm/cmse/baseline/bitfield-9.c: New.
>>> * gcc.target/arm/cmse/baseline/bitfield-and-union-1.c: New.
>>> * gcc.target/arm/cmse/baseline/cmse-11.c: New.
>>> * gcc.target/arm/cmse/baseline/cmse-13.c: New.
>>> * gcc.target/arm/cmse/baseline/cmse-6.c: New.
>>> * gcc/testsuite/gcc.target/arm/cmse/baseline/union-1.c: New.
>>> * gcc/testsuite/gcc.target/arm/cmse/baseline/union-2.c: New.
>>> * gcc.target/arm/cmse/mainline/hard-sp/cmse-13.c: New.
>>> * gcc.target/arm/cmse/mainline/hard-sp/cmse-7.c: New.
>>> * gcc.target/arm/cmse/mainline/hard-sp/cmse-8.c: New.
>>> * gcc.target/arm/cmse/mainline/hard/cmse-13.c: New.
>>> * gcc.target/arm/cmse/mainline/hard/cmse-7.c: New.
>>> * gcc.target/arm/cmse/mainline/hard/cmse-8.c: New.
>>> * gcc.target/arm/cmse/mainline/soft/cmse-13.c: New.
>>> * gcc.target/arm/cmse/mainline/soft/cmse-7.c: New.
>>> * gcc.target/arm/cmse/mainline/soft/cmse-8.c: New.
>>> * gcc.target/arm/cmse/mainline/softfp-sp/cmse-7.c: New.
>>> * gcc.target/arm/cmse/mainline/softfp-sp/cmse-8.c: New.
>>> * gcc.target/arm/cmse/mainline/softfp/cmse-13.c: New.
>>> * gcc.target/arm/cmse/mainline/softfp/cmse-7.c: New.
>>> * gcc.target/arm/cmse/mainline/softfp/cmse-8.c: New.
>>>
>>
>> Updated this patch to correctly clear only the cumulative
>> exception-status (0-4,7) and the condition code bits (28-31) of the FPSCR.
>>
>> 
>>
>> This patch extends support for the ARMv8-M Security Extensions
>> 'cmse_nonsecure_call' to use a new library function
>> '__gnu_cmse_nonsecure_call'. This library function is responsible for
>> (without using r0-r3 or d0-d7):
>> 1) saving and clearing all callee-saved registers using the secure stack
>> 2) clearing the LSB of the address passed in r4 and using blxns to
>> 'jump' to it
>> 3) clearing ASPR, including the 'ge bits' if DSP is enabled
>> 4) clearing the cumulative exception-status (0-4, 7) and the condition
>> bits (28-31) of the FPSCR if using non-soft float-abi
>> 5) restoring callee-saved registers.
>>
>> The decisions whether to include DSP 'ge bits' 

Re: [PATCHv2 5/7, GCC, ARM, V8M] Handling ARMv8-M Security Extension's cmse_nonsecure_call attribute

[Andre Vieira (lists)]

On 25/10/16 17:29, Andre Vieira (lists) wrote:
> On 24/08/16 12:01, Andre Vieira (lists) wrote:
>> On 25/07/16 14:25, Andre Vieira (lists) wrote:
>>> This patch adds support for the ARMv8-M Security Extensions
>>> 'cmse_nonsecure_call' attribute. This attribute may only be used for
>>> function types and when used in combination with the '-mcmse'
>>> compilation flag. See Section 5.5 of ARM®v8-M Security Extensions
>>> (http://infocenter.arm.com/help/topic/com.arm.doc.ecm0359818/index.html).
>>>
>>> We currently do not support cmse_nonsecure_call functions that pass
>>> arguments or return variables on the stack and we diagnose this.
>>>
>>> *** gcc/ChangeLog ***
>>> 2016-07-25  Andre Vieira
>>> Thomas Preud'homme  
>>>
>>> * config/arm/arm.c (gimplify.h): New include.
>>> (arm_handle_cmse_nonsecure_call): New.
>>> (arm_attribute_table): Added cmse_nonsecure_call.
>>>
>>> *** gcc/testsuite/ChangeLog ***
>>> 2016-07-25  Andre Vieira
>>> Thomas Preud'homme  
>>>
>>> * gcc.target/arm/cmse/cmse-3.c: Add tests.
>>> * gcc.target/arm/cmse/cmse-4.c: Add tests.
>>>
>>
>> Added more documentation as requested.
>>
>> ---
>>
>> This patch adds support for the ARMv8-M Security Extensions
>> 'cmse_nonsecure_call' attribute. This attribute may only be used for
>> function types and when used in combination with the '-mcmse'
>> compilation flag. See Section 5.5 of ARM®v8-M Security Extensions
>> (http://infocenter.arm.com/help/topic/com.arm.doc.ecm0359818/index.html).
>>
>> We currently do not support cmse_nonsecure_call functions that pass
>> arguments or return variables on the stack and we diagnose this.
>>
>> *** gcc/ChangeLog ***
>> 2016-07-xx  Andre Vieira
>> Thomas Preud'homme  
>>
>> * config/arm/arm.c (gimplify.h): New include.
>> (arm_handle_cmse_nonsecure_call): New.
>> (arm_attribute_table): Added cmse_nonsecure_call.
>> * doc/extend.texi (ARM ARMv8-M Security Extensions): New attribute.
>>
>> *** gcc/testsuite/ChangeLog ***
>> 2016-07-xx  Andre Vieira
>> Thomas Preud'homme  
>>
>> * gcc.target/arm/cmse/cmse-3.c: Add tests.
>> * gcc.target/arm/cmse/cmse-4.c: Add tests.
>>
> Hi,
> 
> Rebased previous patch on top of trunk as requested. No changes to
> ChangeLog.
> 
> Cheers,
> Andre
> 
Hi,

Added the same warning for cmse_nonsecure_call attribute as a result of
the comments for 2/7 of this series. No change to ChangeLogs.

Cheers,
Andre
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 
9fa216c3a5a3a466448b45a3038d87aecd883433..cc458108f1371b31ea5a10aa8e226ae1bbc7e058
 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -62,6 +62,7 @@
 #include "builtins.h"
 #include "tm-constrs.h"
 #include "rtl-iter.h"
+#include "gimplify.h"
 
 /* This file should be included last.  */
 #include "target-def.h"
@@ -136,6 +137,7 @@ static tree arm_handle_isr_attribute (tree *, tree, tree, 
int, bool *);
 static tree arm_handle_notshared_attribute (tree *, tree, tree, int, bool *);
 #endif
 static tree arm_handle_cmse_nonsecure_entry (tree *, tree, tree, int, bool *);
+static tree arm_handle_cmse_nonsecure_call (tree *, tree, tree, int, bool *);
 static void arm_output_function_epilogue (FILE *, HOST_WIDE_INT);
 static void arm_output_function_prologue (FILE *, HOST_WIDE_INT);
 static int arm_comp_type_attributes (const_tree, const_tree);
@@ -351,6 +353,8 @@ static const struct attribute_spec arm_attribute_table[] =
   /* ARMv8-M Security Extensions support.  */
   { "cmse_nonsecure_entry", 0, 0, true, false, false,
 arm_handle_cmse_nonsecure_entry, false },
+  { "cmse_nonsecure_call", 0, 0, true, false, false,
+arm_handle_cmse_nonsecure_call, false },
   { NULL,   0, 0, false, false, false, NULL, false }
 };
 
@@ -6780,6 +6784,80 @@ arm_handle_cmse_nonsecure_entry (tree *node, tree name,
   return NULL_TREE;
 }
 
+
+/* Called upon detection of the use of the cmse_nonsecure_call attribute, this
+   function will check whether the attribute is allowed here and will add the
+   attribute to the function type tree or otherwise issue a diagnostic.  The
+   reason we check this at declaration time is to only allow the use of the
+   attribute with declarations of function pointers and not function
+   declarations.  This function checks NODE is of the expected type and issues
+   diagnostics otherwise using NAME.  If it is not of the expected type
+   *NO_ADD_ATTRS will be set to true.  */
+
+static tree
+arm_handle_cmse_nonsecure_call (tree *node, tree name,
+tree /* args */,
+int /* flags */,
+bool