Re: [PATCH] Fix PR77407

[Richard Biener]

On Sat, 1 Oct 2016, Marc Glisse wrote:

> On Wed, 28 Sep 2016, Richard Biener wrote:
> 
> > --- gcc/match.pd(revision 240565)
> > +++ gcc/match.pd(working copy)
> > @@ -147,12 +147,25 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
> > (op @0 integer_onep)
> > (non_lvalue @0)))
> > 
> > -/* X / -1 is -X.  */
> > (for div (trunc_div ceil_div floor_div round_div exact_div)
> > +  /* X / -1 is -X.  */
> >  (simplify
> >(div @0 integer_minus_onep@1)
> >(if (!TYPE_UNSIGNED (type))
> > -(negate @0
> > +(negate @0)))
> > + /* X / abs (X) is X < 0 ? -1 : 1.  */
> > + (simplify
> > +   (div @0 (abs @0))
> 
> Should this be div:C ?

Yes.

> > +   (if ((INTEGRAL_TYPE_P (type) || VECTOR_INTEGER_TYPE_P (type))
> > +   && TYPE_OVERFLOW_UNDEFINED (type))
> > +(cond (lt @0 { build_zero_cst (type); })
> > +  { build_minus_one_cst (type); } { build_one_cst (type); })))
> 
> How does that work for vectors? It ICEs for me at revision 240696
> 
> typedef int vec __attribute__((vector_size(16)));
> vec f(vec x){
>   vec y=(x<0)?-x:x;
>   return x/y;
> }
> 
> (I wasn't sure if you had added a feature to turn cond into vec_cond
> automatically in some cases)

Whoops, indeed.

Testing the following.

Richard.

2016-10-04  Richard Biener  

PR middle-end/77407
* match.pd (X / abs (X) -> X < 0 ? -1 : 1): Drop vector
type support, mark with :C.
(X / -X -> -1): Mark with :C.

Index: gcc/match.pd
===
--- gcc/match.pd(revision 240738)
+++ gcc/match.pd(working copy)
@@ -155,14 +155,14 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
 (negate @0)))
  /* X / abs (X) is X < 0 ? -1 : 1.  */ 
  (simplify
-   (div @0 (abs @0))
-   (if ((INTEGRAL_TYPE_P (type) || VECTOR_INTEGER_TYPE_P (type))
+   (div:C @0 (abs @0))
+   (if (INTEGRAL_TYPE_P (type)
&& TYPE_OVERFLOW_UNDEFINED (type))
 (cond (lt @0 { build_zero_cst (type); })
   { build_minus_one_cst (type); } { build_one_cst (type); })))
  /* X / -X is -1.  */
  (simplify
-   (div @0 (negate @0))
+   (div:C @0 (negate @0))
(if ((INTEGRAL_TYPE_P (type) || VECTOR_INTEGER_TYPE_P (type))
&& TYPE_OVERFLOW_UNDEFINED (type))
 { build_minus_one_cst (type); })))

Re: [PATCH] Fix PR55152

[Richard Biener]

On Fri, 30 Sep 2016, Andrew Pinski wrote:

> On Thu, Sep 29, 2016 at 8:23 PM, Richard Biener  wrote:
> > On Thu, 29 Sep 2016, Richard Biener wrote:
> >
> >> On Wed, 28 Sep 2016, Joseph Myers wrote:
> >>
> >> > On Wed, 28 Sep 2016, Richard Biener wrote:
> >> >
> >> > > Index: gcc/testsuite/gcc.dg/pr55152.c
> >> > > ===
> >> > > --- gcc/testsuite/gcc.dg/pr55152.c(revision 0)
> >> > > +++ gcc/testsuite/gcc.dg/pr55152.c(working copy)
> >> > > @@ -0,0 +1,13 @@
> >> > > +/* { dg-do compile } */
> >> > > +/* { dg-options "-O -ffinite-math-only -fstrict-overflow 
> >> > > -fdump-tree-optimized" } */
> >> > > +
> >> > > +double g (double a)
> >> > > +{
> >> > > +  return (a>=-a)?a:-a;
> >> >
> >> > You should need -fno-signed-zeros for this (that is, for the
> >> > transformation to MAX_EXPR), not -ffinite-math-only.  For a == -0, that
> >> > function should return -0, but abs would produce +0.
> >>
> >> This means that tree-ssa-phiopt.c has a bug:
> >>
> >> static bool
> >> minmax_replacement (basic_block cond_bb, basic_block middle_bb,
> >> edge e0, edge e1, gimple *phi,
> >> tree arg0, tree arg1)
> >> {
> >> ...
> >>   /* The optimization may be unsafe due to NaNs.  */
> >>   if (HONOR_NANS (type))
> >> return false;
> >>
> >> and it should check HONOR_SIGNED_ZEROS as well.
> >>
> >> I'll fix that as a followup.
> >
> > Committed as follows.
> >
> > Bootstrapped / tested on x86_64-unknown-linux-gnu.
> >
> > Richard.
> >
> > 2016-09-29  Richard Biener  
> >
> > PR middle-end/55152
> > * match.pd: Add max(a,-a) -> abs(a) pattern.
> 
> 
> Hmm, shouldn't we also do "min(a, -a) -> - abs(a)" ?

Possibly.  Though then for FP we also want - abs (a) -> copysign (a, -1).

Testing the following.

Richard.

2016-10-04  Richard Biener  

PR middle-end/55152
* match.pd (- abs (x) -> copysign (x, -1)): New pattern.
(min(a,-a) -> -abs(a)): Likewise.

* gcc.dg/pr55152-2.c: New testcase.

Index: gcc/match.pd
===
--- gcc/match.pd(revision 240738)
+++ gcc/match.pd(working copy)
@@ -782,6 +782,17 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
 (simplify
  (abs tree_expr_nonnegative_p@0)
  @0)
+/* - abs (x) -> copysign (x, -1).  */
+(simplify
+ (negate (abs @0))
+ (if (SCALAR_FLOAT_TYPE_P (type))
+  (switch
+   (if (types_match (type, float_type_node))
+(BUILT_IN_COPYSIGNF @0 { build_minus_one_cst (type); }))
+   (if (types_match (type, double_type_node))
+(BUILT_IN_COPYSIGN @0 { build_minus_one_cst (type); }))
+   (if (types_match (type, long_double_type_node))
+(BUILT_IN_COPYSIGNL @0 { build_minus_one_cst (type); })
 
 /* A few cases of fold-const.c negate_expr_p predicate.  */
 (match negate_expr_p
@@ -1291,6 +1302,13 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
   && (! ANY_INTEGRAL_TYPE_P (type)
  || TYPE_OVERFLOW_UNDEFINED (type)))
   (abs @0)))
+/* min(a,-a) -> -abs(a).  */
+(simplify
+ (min:c @0 (negate @0))
+ (if (TREE_CODE (type) != COMPLEX_TYPE
+  && (! ANY_INTEGRAL_TYPE_P (type)
+ || TYPE_OVERFLOW_UNDEFINED (type)))
+  (negate (abs @0
 (simplify
  (min @0 @1)
  (switch
Index: gcc/testsuite/gcc.dg/pr55152-2.c
===
--- gcc/testsuite/gcc.dg/pr55152-2.c(revision 0)
+++ gcc/testsuite/gcc.dg/pr55152-2.c(working copy)
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-options "-O -ffinite-math-only -fno-signed-zeros -fstrict-overflow 
-fdump-tree-optimized" } */
+
+double g (double a)
+{
+  return (a<-a)?a:-a;
+}
+int f(int a)
+{
+  return (a<-a)?a:-a;
+}
+
+/* { dg-final { scan-tree-dump-times "ABS_EXPR" 1 "optimized" } } */
+/* { dg-final { scan-tree-dump-times "copysign" 1 "optimized" } } */

Re: [PATCH] Remove .jcr registry from the crtfiles

[Richard Biener]

On Mon, 3 Oct 2016, Jakub Jelinek wrote:

> On Mon, Oct 03, 2016 at 03:26:10PM +, Joseph Myers wrote:
> > As usual when removing target macros they should be poisoned in system.h.
> 
> Here is the patch with that poisoning.  Bootstrapped/regtested on
> x86_64-linux and i686-linux again, ok for trunk?

Ok.

Thanks,
Richard.

> 2016-10-03  Jakub Jelinek  
> 
> gcc/
>   * defaults.h (JCR_SECTION_NAME, TARGET_USE_JCR_SECTION): Remove.
>   * system.h (JCR_SECTION_NAME, TARGET_USE_JCR_SECTION): Poison.
>   * doc/tm.texi.in (TARGET_USE_JCR_SECTION): Remove.
>   * doc/tm.texi: Regenerated.
>   * config/i386/mingw32.h (TARGET_USE_JCR_SECTION): Remove.
>   * config/i386/cygming.h (TARGET_USE_JCR_SECTION): Remove.
>   * config/darwin.h (JCR_SECTION_NAME): Remove.
>   * config/pa/pa64-hpux.h (JCR_SECTION_NAME): Remove.
>   * config/rs6000/aix71.h (TARGET_USE_JCR_SECTION): Remove.
>   * config/rs6000/aix51.h (TARGET_USE_JCR_SECTION): Remove.
>   * config/rs6000/aix52.h (TARGET_USE_JCR_SECTION): Remove.
>   * config/rs6000/aix53.h (TARGET_USE_JCR_SECTION): Remove.
>   * config/rs6000/aix61.h (TARGET_USE_JCR_SECTION): Remove.
> gcc/c-family/
>   * c-cppbuiltin.c (c_cpp_builtins): Don't define
>   __LIBGCC_JCR_SECTION_NAME__.
> libgcc/
>   * config/i386/cygming-crtbegin.c (_Jv_RegisterClasses): Remove.
>   (__JCR_LIST__): Remove.
>   (__gcc_register_frame): Don't attempt to _Jv_RegisterClasses.
>   * config/i386/cygming-crtend.c (__JCR_END__): Remove.
>   * config/ia64/crtbegin.S (__JCR_LIST__): Remove.
>   * config/ia64/crtend.S (__JCR_END__): Remove.
>   * crtstuff.c: Remove __LIBGCC_JCR_SECTION_NAME__ from preprocessor
>   conditionals.
>   (__JCR_LIST__, __JCR_END__): Remove.
>   (frame_dummy): Don't attempt to _Jv_RegisterClasses.
>   (__do_global_ctors_1): Likewise.
> 
> --- gcc/config/i386/mingw32.h.jj  2016-05-20 09:05:08.836063467 +0200
> +++ gcc/config/i386/mingw32.h 2016-10-01 18:55:14.646199686 +0200
> @@ -239,9 +239,6 @@ do {  
>  \
>  #undef TARGET_N_FORMAT_TYPES
>  #define TARGET_N_FORMAT_TYPES 3
>  
> -/* Let defaults.h definition of TARGET_USE_JCR_SECTION apply. */
> -#undef TARGET_USE_JCR_SECTION
> -
>  #define HAVE_ENABLE_EXECUTE_STACK
>  #undef  CHECK_EXECUTE_STACK_ENABLED
>  #define CHECK_EXECUTE_STACK_ENABLED flag_setstackexecutable
> --- gcc/config/i386/cygming.h.jj  2016-09-27 09:46:13.0 +0200
> +++ gcc/config/i386/cygming.h 2016-10-01 18:56:16.133441952 +0200
> @@ -443,11 +443,6 @@ do { \
>  
>  #endif /* HAVE_GAS_WEAK */
>  
> -/* FIXME: SUPPORTS_WEAK && TARGET_HAVE_NAMED_SECTIONS is true,
> -   but for .jcr section to work we also need crtbegin and crtend
> -   objects.  */
> -#define TARGET_USE_JCR_SECTION 1
> -
>  /* Decide whether it is safe to use a local alias for a virtual function
> when constructing thunks.  */
>  #undef TARGET_USE_LOCAL_THUNK_ALIAS_P
> --- gcc/config/darwin.h.jj2016-09-15 13:39:14.518013115 +0200
> +++ gcc/config/darwin.h   2016-10-01 18:55:40.056886539 +0200
> @@ -825,9 +825,6 @@ enum machopic_addr_class {
>  #define EH_FRAME_SECTION_NAME   "__TEXT"
>  #define EH_FRAME_SECTION_ATTR 
> ",coalesced,no_toc+strip_static_syms+live_support"
>  
> -/* Java runtime class list.  */
> -#define JCR_SECTION_NAME "__DATA,jcr,regular,no_dead_strip"
> -
>  #undef ASM_PREFERRED_EH_DATA_FORMAT
>  #define ASM_PREFERRED_EH_DATA_FORMAT(CODE,GLOBAL)  \
>(((CODE) == 2 && (GLOBAL) == 1) \
> --- gcc/config/pa/pa64-hpux.h.jj  2016-04-08 19:19:23.894042211 +0200
> +++ gcc/config/pa/pa64-hpux.h 2016-10-01 18:55:35.171946738 +0200
> @@ -170,8 +170,6 @@ along with GCC; see the file COPYING3.
>  #define DATA_SECTION_ASM_OP  "\t.data"
>  #define BSS_SECTION_ASM_OP   "\t.section\t.bss"
>  
> -#define JCR_SECTION_NAME ".jcr"
> -
>  #define HP_INIT_ARRAY_SECTION_ASM_OP "\t.section\t.init"
>  #define GNU_INIT_ARRAY_SECTION_ASM_OP"\t.section\t.init_array"
>  #define HP_FINI_ARRAY_SECTION_ASM_OP "\t.section\t.fini"
> @@ -382,8 +380,8 @@ do {  
> \
> initializers specified here.  */
>  
>  /* We need to add frame_dummy to the initializer list if 
> EH_FRAME_SECTION_NAME
> -   or JCR_SECTION_NAME is defined.  */
> -#if defined(EH_FRAME_SECTION_NAME) || defined(JCR_SECTION_NAME)
> +   is defined.  */
> +#if defined(EH_FRAME_SECTION_NAME)
>  #define PA_INIT_FRAME_DUMMY_ASM_OP ".dword P%frame_dummy"
>  #else
>  #define PA_INIT_FRAME_DUMMY_ASM_OP ""
> --- gcc/config/rs6000/aix71.h.jj  2016-01-21 21:28:01.218834652 +0100
> +++ gcc/config/rs6000/aix71.h 2016-10-01 18:55:49.667768100 +0200
> @@ -210,8 +210,6 @@ extern long long intatoll(const char
>  /* This target defines SUPPORTS_WEAK and TARGET_ASM_NAMED_SECTION,
> but does not have crtbegin/end.  */
>  
> -#define TARGET_USE_JCR_SECTION 0

Re: Fix PR tree-optimization/77808, ICE in duplicate_ssa_name_ptr_info, at tree-ssanames.c:630 starting with r240439

[Richard Biener]

On Sat, Oct 1, 2016 at 6:55 AM, Doug Gilmore  wrote:
> It looks like my email being sent from my company is being dropped, re sending
> via my gmail account.
>
> Doug
> 
> From: Doug Gilmore
> Sent: Friday, September 30, 2016 6:35 PM
> To: gcc-patches@gcc.gnu.org; Christophe Lyon
> Subject: Fix PR tree-optimization/77808, ICE in
> duplicate_ssa_name_ptr_info, at tree-ssanames.c:630 starting with
> r240439
>
> My commit r240439 didn't handle the situation where setting
> --param prefetch-latency=0 can cause the prefetch address to
> be the same as the original address.  In this case, no
> copying of points-to information should be done.
>
> Bootstrapped and regression tested on x86_64-linux, ok for
> trunk?

Ok.

THanks,
Richard.

> Doug

Re: [PATCH][v4] GIMPLE store merging pass

[Richard Biener]

On Fri, Sep 30, 2016 at 6:57 PM, Kyrill Tkachov
 wrote:
> Hi Richard,
>
> On 29/09/16 11:45, Richard Biener wrote:
>>
>>
>> +  gimple_seq seq = NULL;
>> +  unsigned int num_stmts = 0;
>> +  tree offset_type = get_type_for_merged_store (group);
>> +  tree last_vdef, new_vuse;
>> +  last_vdef = gimple_vdef (group->last_stmt);
>> +  new_vuse = gimple_vuse (group->last_stmt);
>> +  location_t loc = get_merged_store_location (group);
>> If you end up splitting the store then please use a location appropriate
>> for the split part.  Likewise for the alias type.
>>
>
> How would I get the appropriate alias type?
> Is there some way to construct it from the alias type of the base
> object offset by some number of bytes?

You already have a function for this - it just looks at the whole group
instead of a subgroup.  As said, if you'd first split groups then then
do the emission this part would resolve itself.

Richard.

>
> Thanks,
> Kyrill

Re: Fix PR tree-optimization/77808, ICE in duplicate_ssa_name_ptr_info, at tree-ssanames.c:630 starting with r240439

[Richard Biener]

On Sat, Oct 1, 2016 at 3:35 AM, Doug Gilmore  wrote:
> My commit r240439 didn't handle the situation where setting
> --param prefetch-latency=0 can cause the prefetch address to
> be the same as the original address.  In this case, no
> copying of points-to information should be done.
>
> Bootstrapped and regression tested on x86_64-linux, ok for
> trunk?

Ok.

RIchard.

> Doug

Re: [PATCH] Delete GCJ

[Rainer Orth]

Hi Matthias,

> On 05.09.2016 17:13, Andrew Haley wrote:
>> As discussed.  I think I should ask a Global reviewer to approve this
>> one.  For obvious reasons I haven't included the diffs to the deleted
>> gcc/java and libjava directories.  The whole tree, post GCJ-deletion,
>> is at svn+ssh://gcc.gnu.org/svn/gcc/branches/gcj/gcj-deletion-branch
>> if anyone would like to try it.
>
> still breaks bootstraps when configured with --enable-objc-gc.
>
> the immediate step should be to fix the bootstrap failure, as an additional 
> step
> to remove boehm-gc from the gcc sources and be able to use an external 
> boehm-gc.

the first part is handled by my unreviewed patch

https://gcc.gnu.org/ml/gcc-patches/2016-09/msg02437.html

Rainer

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

Re: [PATCH] Delete GCJ

[Andrew Haley]

On 04/10/16 09:39, Rainer Orth wrote:
> Hi Matthias,
> 
>> On 05.09.2016 17:13, Andrew Haley wrote:
>>> As discussed.  I think I should ask a Global reviewer to approve this
>>> one.  For obvious reasons I haven't included the diffs to the deleted
>>> gcc/java and libjava directories.  The whole tree, post GCJ-deletion,
>>> is at svn+ssh://gcc.gnu.org/svn/gcc/branches/gcj/gcj-deletion-branch
>>> if anyone would like to try it.
>>
>> still breaks bootstraps when configured with --enable-objc-gc.
>>
>> the immediate step should be to fix the bootstrap failure, as an additional 
>> step
>> to remove boehm-gc from the gcc sources and be able to use an external 
>> boehm-gc.
> 
> the first part is handled by my unreviewed patch
> 
>   https://gcc.gnu.org/ml/gcc-patches/2016-09/msg02437.html

Looks obvious to me, fixes bootstrap.  I think no-one will complain
if you check it in.

Andrew.

Re: [PATCH] add uClibc target hook (PR bootstrap/77819)

[Bernd Schmidt]

On 10/03/2016 12:02 AM, Martin Sebor wrote:

I couldn't find a good uclibc-only file where to put the new
definition of the hook so I conditionally added it to
targethooks.c.



diff --git a/gcc/targhooks.c b/gcc/targhooks.c
index d75650f..77b4a18 100644
--- a/gcc/targhooks.c
+++ b/gcc/targhooks.c
@@ -1523,6 +1523,26 @@ default_printf_pointer_format (tree, const char **flags)
   return "%zx";
 }

+#if (DEFAULT_LIBC == LIBC_UCLIBC) && defined (SINGLE_LIBC) /* uClinux */


I think DEFAULT_LIBC is defined only for linux targets, so this won't 
do. Just define unconditionally, with a declaration in targhooks.h?



+const char*
+uclibc_printf_pointer_format (tree arg, const char **flags)
+{
+  *flags = " +";
+
+  return arg && integer_zerop (arg) ? "(nil)" : "%#zx";
+}


Then again, maybe also just move the hook from linux.c here, it appears 
identical.



Bernd

[PATCH] Fix fallout of PR77399 fix

[Richard Biener]

Andreas noticed I forgot to check if the target can fix/float a vector.

Bootstrap / regtest pending on x86_64-unknown-linux-gnu.  Verified
the fix with a cross to ia64-linux.

Richard.

2016-10-04  Richard Biener  

PR tree-optimization/77399
* tree-ssa-forwprop.c (simplify_vector_constructor): Properly
verify the target can convert.

* gcc.dg/tree-ssa/forwprop-35.c: Adjust.

Index: gcc/tree-ssa-forwprop.c
===
--- gcc/tree-ssa-forwprop.c (revision 240739)
+++ gcc/tree-ssa-forwprop.c (working copy)
@@ -45,6 +45,7 @@ along with GCC; see the file COPYING3.
 #include "builtins.h"
 #include "tree-cfgcleanup.h"
 #include "cfganal.h"
+#include "optabs-tree.h"
 
 /* This pass propagates the RHS of assignment statements into use
sites of the LHS of the assignment.  It's basically a specialized
@@ -2037,6 +2038,13 @@ simplify_vector_constructor (gimple_stmt
  != TYPE_VECTOR_SUBPARTS (TREE_TYPE (orig
 return false;
 
+  tree tem;
+  if (conv_code != ERROR_MARK
+  && (! supportable_convert_operation (conv_code, type, TREE_TYPE (orig),
+  &tem, &conv_code)
+ || conv_code == CALL_EXPR))
+return false;
+
   if (maybe_ident)
 {
   if (conv_code == ERROR_MARK)
Index: gcc/testsuite/gcc.dg/tree-ssa/forwprop-35.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/forwprop-35.c (revision 240739)
+++ gcc/testsuite/gcc.dg/tree-ssa/forwprop-35.c (working copy)
@@ -14,5 +14,5 @@ v4sf vec_cast_perm(v4si f)
   return (v4sf){f[1], f[1], f[2], f[3]};
 }
 
-/* { dg-final { scan-tree-dump-times "VEC_PERM_EXPR" 1 "cddce1" } } */
-/* { dg-final { scan-tree-dump-times "\\\(v4sf\\\) " 2 "cddce1" } } */
+/* { dg-final { scan-tree-dump-times "VEC_PERM_EXPR" 1 "cddce1" { target 
x86_64-*-* } } } */
+/* { dg-final { scan-tree-dump-times "\\\(v4sf\\\) " 2 "cddce1" { target 
x86_64-*-* } } } */

Re: [PATCH] Improve target pass registration

[Richard Biener]

On Fri, 30 Sep 2016, Jakub Jelinek wrote:

> Hi!
> 
> As discussed earlier on IRC, the current way of registering target specific
> passes has various issues:
> 1) for -da, the target specific dump files appear last, regardless on where
>exactly they appear in the pass queue, so one has to look up the sources
>or remember where the pass is invoked if e.g. looking for when certain
>change in the IL first appears
> 2) -fdump-rtl-stv-details and similar options don't work, the option
>processing happens before the passes are registered
> 
> This patch allows backends to provide their *-passes.def file with
> instructions how to ammend passes.def, which then can be inspected in
> pass-instances.def the script generates.
> 
> I've only converted the i386 backend so far, other maintainers can easily
> convert their backends later on.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

I'm fine with the approach but I can't really review the awk parts
so I'd appreciate a second eye on them.

Thus, ok from the overall view, leaving to Uros and maybe some awk
expert (if none appears within a reasonable amount of time consider
this as approval anyway).

Thanks,
Richard.

> 2016-09-30  Jakub Jelinek  
> 
>   * gen-pass-instances.awk: Rewritten.
>   * Makefile.in (pass-instances.def): Depend on $(PASSES_EXTRA), pass
>   $(PASSES_EXTRA) after passes.def to the script.
>   * config/i386/t-i386 (PASSES_EXTRA): Add i386-passes.def.
>   * config/i386/i386-passes.def: New file.
>   * config/i386/i386-protos.h (make_pass_insert_vzeroupper,
>   make_pass_stv): Declare.
>   * config/i386/i386.c (pass_stv::pass_stv): Initialize timode_p to
>   false.
>   (pass_stv::gate): Depending on timode_p member require TARGET_64BIT
>   or !TARGET_64BIT.
>   (pass_stv::clone, pass_stv::set_pass_param): New methods.
>   (pass_stv::timode_p): New non-static data member.
>   (ix86_option_override): Don't register passes here.
> 
> --- gcc/gen-pass-instances.awk.jj 2016-09-29 22:53:10.264776158 +0200
> +++ gcc/gen-pass-instances.awk2016-09-30 13:22:53.745373889 +0200
> @@ -17,6 +17,8 @@
>  # This Awk script takes passes.def and writes pass-instances.def,
>  # counting the instances of each kind of pass, adding an instance number
>  # to everywhere that NEXT_PASS is used.
> +# Also handle INSERT_PASS_AFTER, INSERT_PASS_BEFORE and REPLACE_PASS
> +# directives.
>  #
>  # For example, the single-instanced pass:
>  # NEXT_PASS (pass_warn_unused_result);
> @@ -30,81 +32,201 @@
>  # through:
>  #   NEXT_PASS (pass_copy_prop, 8);
>  # (currently there are 8 instances of that pass)
> +#
> +# INSERT_PASS_AFTER (pass_copy_prop, 1, pass_stv);
> +# will insert
> +# NEXT_PASS (pass_stv, 1);
> +# after immediately after the NEXT_PASS (pass_copy_prop, 1) line,
> +# similarly INSERT_PASS_BEFORE inserts immediately before that line.
> +# REPLACE_PASS (pass_copy_prop, 1, pass_stv, true);
> +# will replace NEXT_PASS (pass_copy_prop, 1) line with
> +# NEXT_PASS (pass_stv, 1, true);
> +# line and renumber all higher pass_copy_prop instances if any.
>  
>  # Usage: awk -f gen-pass-instances.awk passes.def
>  
>  BEGIN {
> - print "/* This file is auto-generated by gen-pass-instances.awk";
> - print "   from passes.def.  */";
> +  print "/* This file is auto-generated by gen-pass-instances.awk";
> +  print "   from passes.def.  */";
> +  lineno = 1;
>  }
>  
> -function handle_line()
> +function parse_line(line, fnname,len_of_call, len_of_start,
> + len_of_open, len_of_close,
> + len_of_args, args_start_at,
> + args_str, len_of_prefix,
> + call_starts_at,
> + postfix_starts_at)
>  {
> - line = $0;
> +  # Find call expression.
> +  call_starts_at = match(line, fnname " \\(.+\\)");
> +  if (call_starts_at == 0)
> +return 0;
> +
> +  # Length of the call expression.
> +  len_of_call = RLENGTH;
> +
> +  len_of_start = length(fnname " (");
> +  len_of_open = length("(");
> +  len_of_close = length(")");
> +
> +  # Find arguments
> +  len_of_args = len_of_call - (len_of_start + len_of_close);
> +  args_start_at = call_starts_at + len_of_start;
> +  args_str = substr(line, args_start_at, len_of_args);
> +  split(args_str, args, ",");
> +
> +  # Find call expression prefix
> +  len_of_prefix = call_starts_at - 1;
> +  prefix = substr(line, 1, len_of_prefix);
> +
> +  # Find call expression postfix
> +  postfix_starts_at = call_starts_at + len_of_call;
> +  postfix = substr(line, postfix_starts_at);
> +  return 1;
> +}
>  
> - # Find call expression.
> - call_starts_at = match(line, /NEXT_PASS \(.+\)/);
> - if (call_starts_at == 0)
> - {
> - print line;
> - return;
> - }
> +function adjust_linenos(above, increme

Re: [EVRP] Fold stmts with vrp_fold_stmt

[Richard Biener]

On Tue, 4 Oct 2016, kugan wrote:

> Hi,
> 
> This patch improves Early VRP by folding stmts using vrp_fold_stmt as it is
> done in ssa_propagate for VRP.

Why?  I'd like us to move away from the fold_stmt callback of
substitute-and-fold (I have actually started some work towards that).
 
> I have also changed EVRP to handle POINTER_TYPE_P. I will send follow up
> patches to use this in IPA-VRP.

For pointers all VRP does is track non-NULLness.  Can you split out this 
part?

I'm really worried about all the testsuite changes -- it means we are
losing test coverage for VRP :/

Richard.

> Bootstrapped and regression testd on x86_64-linux-gnu with no new regressions.
> Is this OK for trunk?
> 
> Thanks,
> Kugan
> 
> gcc/testsuite/ChangeLog:
> 
> 2016-10-03  Kugan Vivekanandarajah  
> 
>   * gcc.dg/pr68217.c: Adjust testcase as more cases are now handled in
> evrp.
>   * gcc.dg/predict-1.c: Likewise.
>   * gcc.dg/predict-9.c: Likewise.
>   * gcc.dg/tree-ssa/pr20318.c: Likewise.
>   * gcc.dg/tree-ssa/pr21001.c: Likewise.
>   * gcc.dg/tree-ssa/pr21090.c: Likewise.
>   * gcc.dg/tree-ssa/pr21294.c: Likewise.
>   * gcc.dg/tree-ssa/pr21559.c: Likewise.
>   * gcc.dg/tree-ssa/pr21563.c: Likewise.
>   * gcc.dg/tree-ssa/pr23744.c: Likewise.
>   * gcc.dg/tree-ssa/pr25382.c: Likewise.
>   * gcc.dg/tree-ssa/pr61839_1.c: Likewise.
>   * gcc.dg/tree-ssa/pr68431.c: Likewise.
>   * gcc.dg/tree-ssa/vrp03.c: Likewise.
>   * gcc.dg/tree-ssa/vrp07.c: Likewise.
>   * gcc.dg/tree-ssa/vrp09.c: Likewise.
>   * gcc.dg/tree-ssa/vrp17.c: Likewise.
>   * gcc.dg/tree-ssa/vrp18.c: Likewise.
>   * gcc.dg/tree-ssa/vrp19.c: Likewise.
>   * gcc.dg/tree-ssa/vrp20.c: Likewise.
>   * gcc.dg/tree-ssa/vrp23.c: Likewise.
>   * gcc.dg/tree-ssa/vrp24.c: Likewise.
>   * gcc.dg/tree-ssa/vrp58.c: Likewise.
>   * gcc.dg/tree-ssa/vrp92.c: Likewise.
>   * gcc.dg/tree-ssa/vrp98.c: Likewise.
>   * gcc.dg/vrp-min-max-1.c: Likewise.
> 
> gcc/ChangeLog:
> 
> 2016-10-03  Kugan Vivekanandarajah  
> 
>   * tree-vrp.c (evrp_dom_walker::before_dom_children): Handle
> POINTER_TYPE_P. Also fold stmts with vrp_fold_stmt.
> 

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

[PATCH] Fix warnings for profiledbootstrap (PR bootstrap/77788)

[Martin Liška]

Hello.

In the attached patch I resolve couple of warnings seen during make 
profiledbootstrap.
I can survive bootstrap on both ppc64le-redhat-linux and x86_64-linux-gnu 
targets.

Ready to be installed?
Martin
>From 510ac204f2e448d244c8eec5ab8aeab85f6041a9 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Mon, 3 Oct 2016 23:17:05 +0200
Subject: [PATCH] Fix warnings for make profiledbootstrap (PR bootstrap/77788)

gcc/ChangeLog:

2016-10-04  Martin Liska  

	PR bootstrap/77788
	* expmed.h (mul_highpart_cost_ptr): Add an gcc_assert.
	* gimple-ssa-strength-reduction.c (slsr_process_cast):
	Initialize a pointer to NULL.
	(slsr_process_copy): Likewise.
	* input.c (location_get_source_line): Likewise.
	* tree-ssa-ccp.c (optimize_atomic_bit_test_and): Likewise.
---
 gcc/expmed.h| 4 +++-
 gcc/gimple-ssa-strength-reduction.c | 4 ++--
 gcc/input.c | 2 +-
 gcc/tree-ssa-ccp.c  | 2 +-
 4 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/gcc/expmed.h b/gcc/expmed.h
index cbceaf1..8d0af3c 100644
--- a/gcc/expmed.h
+++ b/gcc/expmed.h
@@ -618,8 +618,10 @@ static inline int *
 mul_highpart_cost_ptr (bool speed, machine_mode mode)
 {
   gcc_assert (GET_MODE_CLASS (mode) == MODE_INT);
+  int m = mode - MIN_MODE_INT;
+  gcc_assert (m < NUM_MODE_INT);
 
-  return &this_target_expmed->x_mul_highpart_cost[speed][mode - MIN_MODE_INT];
+  return &this_target_expmed->x_mul_highpart_cost[speed][m];
 }
 
 /* Set the COST for computing the high part of a multiplication in MODE
diff --git a/gcc/gimple-ssa-strength-reduction.c b/gcc/gimple-ssa-strength-reduction.c
index b49637f..7b14b91 100644
--- a/gcc/gimple-ssa-strength-reduction.c
+++ b/gcc/gimple-ssa-strength-reduction.c
@@ -1529,7 +1529,7 @@ static void
 slsr_process_cast (gimple *gs, tree rhs1, bool speed)
 {
   tree lhs, ctype;
-  slsr_cand_t base_cand, c, c2;
+  slsr_cand_t base_cand, c = NULL, c2;
   unsigned savings = 0;
 
   if (!legal_cast_p (gs, rhs1))
@@ -1593,7 +1593,7 @@ slsr_process_cast (gimple *gs, tree rhs1, bool speed)
 static void
 slsr_process_copy (gimple *gs, tree rhs1, bool speed)
 {
-  slsr_cand_t base_cand, c, c2;
+  slsr_cand_t base_cand, c = NULL, c2;
   unsigned savings = 0;
 
   base_cand = base_cand_from_table (rhs1);
diff --git a/gcc/input.c b/gcc/input.c
index 67f727e..6131659 100644
--- a/gcc/input.c
+++ b/gcc/input.c
@@ -713,7 +713,7 @@ const char *
 location_get_source_line (const char *file_path, int line,
 			  int *line_len)
 {
-  char *buffer;
+  char *buffer = NULL;
   ssize_t len;
 
   if (line == 0)
diff --git a/gcc/tree-ssa-ccp.c b/gcc/tree-ssa-ccp.c
index b6ccb59..3dc9ffa 100644
--- a/gcc/tree-ssa-ccp.c
+++ b/gcc/tree-ssa-ccp.c
@@ -2817,7 +2817,7 @@ optimize_atomic_bit_test_and (gimple_stmt_iterator *gsip,
   FOR_EACH_IMM_USE_STMT (g, iter, use_lhs)
 {
   enum tree_code code = ERROR_MARK;
-  tree op0, op1;
+  tree op0 = NULL_TREE, op1 = NULL_TREE;
   if (is_gimple_debug (g))
 	{
 	  has_debug_uses = true;
-- 
2.9.2

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

[Jakub Jelinek]

On Sat, Oct 01, 2016 at 12:16:20AM +0200, Rainer Orth wrote:
> Hi Eric,
> 
> >> I haven't tried to readd the boehm-gc objc support that has also been
> >> disabled, don't know about anybody using that.
> >
> > I always configure with --enable-objc-gc. The only reason Apple
> > deprecated garbage collection for Objective C is because they replaced
> > it with Automated Reference Counting in clang, which GCC doesn't
> > support yet. So, until GCC supports Automated Reference Counting,
> > please keep boehm-gc support for objc.
> 
> me too, though mostly to have maximum test coverage (primarily on
> Solaris).  As expected, a x86_64-apple-darwin16 bootstrap with
> --enable-objc-gc just failed for me.  I'm testing the following patch
> (on top of Jakub's).
> 
>   Rainer
> 
> 
> 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).

Jakub

Re: [PATCH] Improve target pass registration

[Uros Bizjak]

On Tue, Oct 4, 2016 at 10:53 AM, Richard Biener  wrote:
> On Fri, 30 Sep 2016, Jakub Jelinek wrote:
>
>> Hi!
>>
>> As discussed earlier on IRC, the current way of registering target specific
>> passes has various issues:
>> 1) for -da, the target specific dump files appear last, regardless on where
>>exactly they appear in the pass queue, so one has to look up the sources
>>or remember where the pass is invoked if e.g. looking for when certain
>>change in the IL first appears
>> 2) -fdump-rtl-stv-details and similar options don't work, the option
>>processing happens before the passes are registered
>>
>> This patch allows backends to provide their *-passes.def file with
>> instructions how to ammend passes.def, which then can be inspected in
>> pass-instances.def the script generates.
>>
>> I've only converted the i386 backend so far, other maintainers can easily
>> convert their backends later on.
>>
>> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> I'm fine with the approach but I can't really review the awk parts
> so I'd appreciate a second eye on them.
>
> Thus, ok from the overall view, leaving to Uros and maybe some awk
> expert (if none appears within a reasonable amount of time consider
> this as approval anyway).

I thought I have already approved what little is of x86 changes. But
as you said, most of the changes are target-independent awk scripts.

That said, the change is surely beneficial, I've been annoyed by dump
file order for quite some time...

Thanks,
Uros.

>
> Thanks,
> Richard.
>
>> 2016-09-30  Jakub Jelinek  
>>
>>   * gen-pass-instances.awk: Rewritten.
>>   * Makefile.in (pass-instances.def): Depend on $(PASSES_EXTRA), pass
>>   $(PASSES_EXTRA) after passes.def to the script.
>>   * config/i386/t-i386 (PASSES_EXTRA): Add i386-passes.def.
>>   * config/i386/i386-passes.def: New file.
>>   * config/i386/i386-protos.h (make_pass_insert_vzeroupper,
>>   make_pass_stv): Declare.
>>   * config/i386/i386.c (pass_stv::pass_stv): Initialize timode_p to
>>   false.
>>   (pass_stv::gate): Depending on timode_p member require TARGET_64BIT
>>   or !TARGET_64BIT.
>>   (pass_stv::clone, pass_stv::set_pass_param): New methods.
>>   (pass_stv::timode_p): New non-static data member.
>>   (ix86_option_override): Don't register passes here.
>>
>> --- gcc/gen-pass-instances.awk.jj 2016-09-29 22:53:10.264776158 +0200
>> +++ gcc/gen-pass-instances.awk2016-09-30 13:22:53.745373889 +0200
>> @@ -17,6 +17,8 @@
>>  # This Awk script takes passes.def and writes pass-instances.def,
>>  # counting the instances of each kind of pass, adding an instance number
>>  # to everywhere that NEXT_PASS is used.
>> +# Also handle INSERT_PASS_AFTER, INSERT_PASS_BEFORE and REPLACE_PASS
>> +# directives.
>>  #
>>  # For example, the single-instanced pass:
>>  # NEXT_PASS (pass_warn_unused_result);
>> @@ -30,81 +32,201 @@
>>  # through:
>>  #   NEXT_PASS (pass_copy_prop, 8);
>>  # (currently there are 8 instances of that pass)
>> +#
>> +# INSERT_PASS_AFTER (pass_copy_prop, 1, pass_stv);
>> +# will insert
>> +# NEXT_PASS (pass_stv, 1);
>> +# after immediately after the NEXT_PASS (pass_copy_prop, 1) line,
>> +# similarly INSERT_PASS_BEFORE inserts immediately before that line.
>> +# REPLACE_PASS (pass_copy_prop, 1, pass_stv, true);
>> +# will replace NEXT_PASS (pass_copy_prop, 1) line with
>> +# NEXT_PASS (pass_stv, 1, true);
>> +# line and renumber all higher pass_copy_prop instances if any.
>>
>>  # Usage: awk -f gen-pass-instances.awk passes.def
>>
>>  BEGIN {
>> - print "/* This file is auto-generated by gen-pass-instances.awk";
>> - print "   from passes.def.  */";
>> +  print "/* This file is auto-generated by gen-pass-instances.awk";
>> +  print "   from passes.def.  */";
>> +  lineno = 1;
>>  }
>>
>> -function handle_line()
>> +function parse_line(line, fnname,len_of_call, len_of_start,
>> + len_of_open, len_of_close,
>> + len_of_args, args_start_at,
>> + args_str, len_of_prefix,
>> + call_starts_at,
>> + postfix_starts_at)
>>  {
>> - line = $0;
>> +  # Find call expression.
>> +  call_starts_at = match(line, fnname " \\(.+\\)");
>> +  if (call_starts_at == 0)
>> +return 0;
>> +
>> +  # Length of the call expression.
>> +  len_of_call = RLENGTH;
>> +
>> +  len_of_start = length(fnname " (");
>> +  len_of_open = length("(");
>> +  len_of_close = length(")");
>> +
>> +  # Find arguments
>> +  len_of_args = len_of_call - (len_of_start + len_of_close);
>> +  args_start_at = call_starts_at + len_of_start;
>> +  args_str = substr(line, args_start_at, len_of_args);
>> +  split(args_str, args, ",");
>> +
>> +  # Find call expression prefix
>> +  len_of_prefix = call_starts_at - 1;
>> +  prefix = substr(l

Re: [PATCH] - improve sprintf buffer overflow detection (middle-end/49905)

[Rainer Orth]

Hi Martin,

 +FAIL: gcc.dg/tree-ssa/builtin-sprintf.c execution test

 FAIL: test_a_double:364: "%a" expected result for "0x0.0p+0"
 doesn't match function call return value: 20 != 6
 FAIL: test_a_double:365: "%a" expected result for "0x1.0p+0"
 doesn't match function call return value: 20 != 6
 FAIL: test_a_double:366: "%a" expected result for "0x1.0p+1"
 doesn't match function call return value: 20 != 6

 FAIL: test_a_long_double:375: "%La" expected result for
 "0x0.p+0" doesn't match function call return
 value: 35 != 6
 FAIL: test_a_long_double:376: "%La" expected result for
 "0x1.p+0" doesn't match function call return
 value: 35 != 6
 FAIL: test_a_long_double:377: "%La" expected result for
 "0x1.p+1" doesn't match function call return
 value: 35 != 6
>>>
>>> I don't know about these.  It looks like the Solaris printf doesn't
>>> handle the %a directive correctly and the tests (and the related
>>> checks/optimization) might need to be disabled, which in turn might
>>> involve extending the existing printf hook or adding a new one.
>>
>> I've found the following in Solaris 10 (and up) printf(3C):
>>
>>  a, AA  double  argument  representing  a  floating-point
>>  number  is  converted in the style "[-]0xh.p+d",
>>  where the single  hexadecimal  digit  preceding  the
>>  radix  point is 0 if the value converted is zero and
>>  1 otherwise and the  number  of  hexadecimal  digits
>>  after it is equal to the precision; if the precision
>>  is missing, the number of digits printed  after  the
>>  radix  point  is  13  for the conversion of a double
>>  value, 16 for the conversion of a long double  value
>>  on  x86,  and 28 for the conversion of a long double
>>  value on SPARC; if the precision is zero and the '#'
>>  flag  is  not  specified, no decimal-point character
>>  will appear. The letters "abcdef"  are  used  for  a
>>  conversion  and  the  letters "ABCDEF" for A conver-
>>  sion. The A conversion specifier produces  a  number
>>  with  'X'  and  'P'  instead  of  'x'  and  'p'. The
>>  exponent will always contain at least one digit, and
>>  only  as  many more digits as necessary to represent
>>  the decimal exponent of 2. If the value is zero, the
>>  exponent is zero.
>>
>>  The converted value is rounded to fit the  specified
>>  output  format  according to the prevailing floating
>>  point rounding direction mode. If the conversion  is
>>  not exact, an inexact exception is raised.
>>
>>  A double argument representing an infinity or NaN is
>>  converted in the SUSv3 style of an e or E conversion
>>  specifier.
>>
>> I tried to check the relevant sections of the latest C99 and C11 drafts
>> to check if this handling of missing precision is allowed by the
>> standard, but I couldn't even fully parse the language there.
>>
>>> I don't have access to Solaris to fully debug and test this there.
>>> Would you mind helping with it?
>>
>> Not at all: if it turns out that Solaris has bugs in this area, I can
>> easily file them, too.
>
> I think it's actually a defect in the C standard.  It doesn't
> specify how many decimal digits an implementation must produce
> on output for a plain %a directive (i.e., when precision isn't
> explicitly specified).  With Glibc, for instance, printf("%a",
> 1.0) prints 0x8p-3 while on Solaris it prints  0x8.00p-3.
> Both seem reasonable but neither is actually specified.  In
> theory, an implementation is allowed print any number of zeros
> after the decimal point, which the standard should (IMO) not
> permit.  There should be a cap (e.g., of at most 6 decimal
> digits when precision is not specified with %a, just like
> there us with %e).  I'll propose to change the standard and
> forward it to the C committee.  Until then, I've worked
> around it in the patch for pr77735 (under review).  If you
> have a moment and could try it out on Solaris and let me
> know how it goes I'd be grateful.

as it happens, I'd already started bootstraps with your patch before
your mail arrived :-)

We're left with

FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c (test for excess errors)
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-4.c (test for excess errors)

for 32 bit and

FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-4.c (test for excess errors)

for 64 bit on both i386-pc-solaris2.12 and sparc-sun-solaris2.12.

In the 32-bit builtin-sprintf-warn-1.c case, there are many instances of

Excess errors:
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/tree-ssa/builtin-spr

[PATCH] Fix PR77833

[Richard Biener]

The following fixes PR77833.

Bootstrap / regtest pending on x86_64-unknown-linux-gnu.

Richard.

2016-10-04  Richard Biener  

PR middle-end/77833
* explow.c (plus_constant): Verify the mode of the constant
pool offset before calling plus_constant.

* gcc.target/i386/pr77833.c: New testcase.

Index: gcc/explow.c
===
--- gcc/explow.c(revision 240739)
+++ gcc/explow.c(working copy)
@@ -114,12 +114,15 @@ plus_constant (machine_mode mode, rtx x,
  cst = gen_lowpart (mode, cst);
  gcc_assert (cst);
}
- tem = plus_constant (mode, cst, c);
- tem = force_const_mem (GET_MODE (x), tem);
- /* Targets may disallow some constants in the constant pool, thus
-force_const_mem may return NULL_RTX.  */
- if (tem && memory_address_p (GET_MODE (tem), XEXP (tem, 0)))
-   return tem;
+ if (GET_MODE (cst) == VOIDmode || GET_MODE (cst) == mode)
+   {
+ tem = plus_constant (mode, cst, c);
+ tem = force_const_mem (GET_MODE (x), tem);
+ /* Targets may disallow some constants in the constant pool, thus
+force_const_mem may return NULL_RTX.  */
+ if (tem && memory_address_p (GET_MODE (tem), XEXP (tem, 0)))
+   return tem;
+   }
}
   break;
 
Index: gcc/testsuite/gcc.target/i386/pr77833.c
===
--- gcc/testsuite/gcc.target/i386/pr77833.c (revision 0)
+++ gcc/testsuite/gcc.target/i386/pr77833.c (working copy)
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-options "-O -mavx512f" } */
+
+typedef unsigned long V __attribute__((vector_size(64)));
+typedef unsigned __int128 W __attribute__((vector_size(64)));
+
+V
+foo(int i, V v)
+{
+  i *= ((W)(V){0, 0, 0, 0, 0, 1, v[0]})[2];
+  v[i] = 0;
+  i--;
+  return v + i;
+}

Re: [PATCH] Fix PR55152

[Marc Glisse]

On Tue, 4 Oct 2016, Richard Biener wrote:


Possibly.  Though then for FP we also want - abs (a) -> copysign (a, -1).


I thought this might fix PR 62055, but at least on x86_64, we generate 
much worse code for copysign(,-1) than for -abs :-(


--
Marc Glisse

Re: [RFC] Speed-up -fprofile-update=atomic

[Richard Biener]

On Thu, Sep 15, 2016 at 12:00 PM, Martin Liška  wrote:
> On 09/07/2016 02:09 PM, Richard Biener wrote:
>> On Wed, Sep 7, 2016 at 1:37 PM, Martin Liška  wrote:
>>> On 08/18/2016 06:06 PM, Richard Biener wrote:
 On August 18, 2016 5:54:49 PM GMT+02:00, Jakub Jelinek  
 wrote:
> On Thu, Aug 18, 2016 at 08:51:31AM -0700, Andi Kleen wrote:
>>> I'd prefer to make updates atomic in multi-threaded applications.
>>> The best proxy we have for that is -pthread.
>>>
>>> Is it slower, most definitely, but odds are we're giving folks
>>> garbage data otherwise, which in many ways is even worse.
>>
>> It will likely be catastrophically slower in some cases.
>>
>> Catastrophically as in too slow to be usable.
>>
>> An atomic instruction is a lot more expensive than a single
> increment. Also
>> they sometimes are really slow depending on the state of the machine.
>
> Can't we just have thread-local copies of all the counters (perhaps
> using
> __thread pointer as base) and just atomically merge at thread
> termination?

 I suggested that as well but of course it'll have its own class of issues 
 (short lived threads, so we need to somehow re-use counters from 
 terminated threads, large number of threads and thus using too much memory 
 for the counters)

 Richard.
>>>
>>> Hello.
>>>
>>> I've got written the approach on my TODO list, let's see whether it would 
>>> be doable in a reasonable amount of time.
>>>
>>> I've just finished some measurements to illustrate slow-down of 
>>> -fprofile-update=atomic approach.
>>> All numbers are: no profile, -fprofile-generate, -fprofile-generate 
>>> -fprofile-update=atomic
>>> c-ray benchmark (utilizing 8 threads, -O3): 1.7, 15.5., 38.1s
>>> unrar (utilizing 8 threads, -O3): 3.6, 11.6, 38s
>>> tramp3d (1 thread, -O3): 18.0, 46.6, 168s
>>>
>>> So the slow-down is roughly 300% compared to -fprofile-generate. I'm not 
>>> having much experience with default option
>>> selection, but these numbers can probably help.
>>>
>>> Thoughts?
>>
>> Look at the generated code for an instrumented simple loop and see that for
>> the non-atomic updates we happily apply store-motion to the counter update
>> and thus we only get one counter update per loop exit rather than one per
>> loop iteration.  Now see what happens for the atomic case (I suspect you
>> get one per iteration).
>>
>> I'll bet this accounts for most of the slowdown.
>>
>> Back in time ICC which had atomic counter updates (but using function
>> calls - ugh!) had a > 1000% overhead with FDO for tramp3d (they also
>> didn't have early inlining -- removing abstraction helps reducing the number
>> of counters significantly).
>>
>> Richard.
>
> Hi.
>
> During Cauldron I discussed with Richi approaches how to speed-up ARCS
> profile counter updates. My first attempt is to utilize TLS storage, where
> every function is accumulating arcs counters. These are eventually added
> (using atomic operations) to the global one at the very end of a function.
> Currently I rely on target support of TLS, which is questionable whether
> to have such a requirement for -fprofile-update=atomic, or to add a new 
> option value
> like -fprofile-update=atomic-tls?
>
> Running the patch on tramp3d, compared to previous numbers, it takes 88s to 
> finish.
> Time shrinks to 50%, compared to the current implementation.
>
> Thoughts?

Hmm, I thought I suggested that you can simply use automatic storage
(which effectively
is TLS...) for regions that are not forked or abnormally left (which
means SESE regions
that have no calls that eventually terminate or throw externally).

So why did you end up with TLS?

Richard.

> Martin
>
>>
>>> Martin
>>>

>  Jakub


>>>
>

Re: [PATCH] Fix PR55152

[Richard Biener]

On Tue, 4 Oct 2016, Marc Glisse wrote:

> On Tue, 4 Oct 2016, Richard Biener wrote:
> 
> > Possibly.  Though then for FP we also want - abs (a) -> copysign (a, -1).
> 
> I thought this might fix PR 62055, but at least on x86_64, we generate much
> worse code for copysign(,-1) than for -abs :-(

I would have expected copysign(,-1) to be a simple IOR ...

double foo (double x)
{
  return __builtin_copysign (x, -1.);
}

foo:
.LFB0:
.cfi_startproc
movsd   .LC0(%rip), %xmm1
movapd  %xmm1, %xmm2
andpd   .LC2(%rip), %xmm2
andpd   .LC1(%rip), %xmm0
orpd%xmm2, %xmm0
ret

ICK. -fabs (x) yields

foo:
.LFB0:
.cfi_startproc
andpd  .LC0(%rip), %xmm0
xorpd  .LC1(%rip), %xmm0
ret

I expected a simple orpd .LC0(%rip), %xmm0 ...

Richard.

Re: [PATCH] Fix fallout of PR77399 fix

[Uros Bizjak]

Hello!

> Andreas noticed I forgot to check if the target can fix/float a vector.
>
> Bootstrap / regtest pending on x86_64-unknown-linux-gnu.  Verified
> the fix with a cross to ia64-linux.
>
> Richard.
>
> 2016-10-04  Richard Biener  
>
> PR tree-optimization/77399
> * tree-ssa-forwprop.c (simplify_vector_constructor): Properly
> verify the target can convert.
>
> * gcc.dg/tree-ssa/forwprop-35.c: Adjust.

-/* { dg-final { scan-tree-dump-times "VEC_PERM_EXPR" 1 "cddce1" } } */
-/* { dg-final { scan-tree-dump-times "\\\(v4sf\\\) " 2 "cddce1" } } */
+/* { dg-final { scan-tree-dump-times "VEC_PERM_EXPR" 1 "cddce1" {
target x86_64-*-* } } } */
+/* { dg-final { scan-tree-dump-times "\\\(v4sf\\\) " 2 "cddce1" {
target x86_64-*-* } } } */

x86 targets should always be in pair, so "target i?86-*-* x86_64-*-*",
with an optional ia32 target addition when the test is valid for 32
bit targets only, or { ! ia32 } addition when test is valid for 64-bit
targets only.

Uros.

Re: [PATCH] Fix fallout of PR77399 fix

[Richard Biener]

On Tue, 4 Oct 2016, Uros Bizjak wrote:

> Hello!
> 
> > Andreas noticed I forgot to check if the target can fix/float a vector.
> >
> > Bootstrap / regtest pending on x86_64-unknown-linux-gnu.  Verified
> > the fix with a cross to ia64-linux.
> >
> > Richard.
> >
> > 2016-10-04  Richard Biener  
> >
> > PR tree-optimization/77399
> > * tree-ssa-forwprop.c (simplify_vector_constructor): Properly
> > verify the target can convert.
> >
> > * gcc.dg/tree-ssa/forwprop-35.c: Adjust.
> 
> -/* { dg-final { scan-tree-dump-times "VEC_PERM_EXPR" 1 "cddce1" } } */
> -/* { dg-final { scan-tree-dump-times "\\\(v4sf\\\) " 2 "cddce1" } } */
> +/* { dg-final { scan-tree-dump-times "VEC_PERM_EXPR" 1 "cddce1" {
> target x86_64-*-* } } } */
> +/* { dg-final { scan-tree-dump-times "\\\(v4sf\\\) " 2 "cddce1" {
> target x86_64-*-* } } } */
> 
> x86 targets should always be in pair, so "target i?86-*-* x86_64-*-*",
> with an optional ia32 target addition when the test is valid for 32
> bit targets only, or { ! ia32 } addition when test is valid for 64-bit
> targets only.

I need SSE2 support but didn't want to adjust dg-options with another
{ target } ... so with default ISA this is valid for x86_64 only
AFAIK?  It might be ok for i?86-*-* with -m64 thus that is your
{ i?86-*-* x86_64-*-* } && { ! ia32 } then?  But x86_64-*-* -m32
is ok ...

I'll try a

/* { dg-options "-O -fdump-tree-cddce1 -msse2" { target { i?86-*-* 
x86_64-*-* } } } */

then.

Richard.

Re: [PATCH] Fix fallout of PR77399 fix

[Uros Bizjak]

On Tue, Oct 4, 2016 at 12:00 PM, Richard Biener  wrote:

>> x86 targets should always be in pair, so "target i?86-*-* x86_64-*-*",
>> with an optional ia32 target addition when the test is valid for 32
>> bit targets only, or { ! ia32 } addition when test is valid for 64-bit
>> targets only.
>
> I need SSE2 support but didn't want to adjust dg-options with another
> { target } ... so with default ISA this is valid for x86_64 only
> AFAIK?  It might be ok for i?86-*-* with -m64 thus that is your
> { i?86-*-* x86_64-*-* } && { ! ia32 } then?  But x86_64-*-* -m32
> is ok ...
>
> I'll try a
>
> /* { dg-options "-O -fdump-tree-cddce1 -msse2" { target { i?86-*-*
> x86_64-*-* } } } */
>
> then.

You need sse2_runtime effective target. Please see e.g.
gcc.dg/pr37544.c (or gcc.dg/pr36584.c for 32-bit only target) on how
it should be used

Uros.

Re: [gomp4] map the '*' tile argument onto integer_zero_node in fortran

[Nathan Sidwell]

On 10/03/16 17:50, Cesar Philippidis wrote:

As the subject states, this patch maps the '*' tile clause arguments
onto integer_zero_node. Before the fortran FE was using mapping it onto
-1. This patch should make the clause parsing in fortran on par with the
C and C++ FEs.

This patch has been applied to gomp-4_0-branch.


thanks!


--
Nathan Sidwell

Re: [PATCH] read-md.c: track column numbers

[Bernd Schmidt]

On 09/30/2016 05:41 AM, David Malcolm wrote:

This patch adds rudimentary column-number tracking to read-md.c, to
give more precise locations for messages for problems in .md files
(and in the RTL frontend I'm working on):

../../src/gcc/config/i386/i386.md:1204:22: error: unknown rtx code 
`define_mood_iterator'
../../src/gcc/config/i386/i386.md:1204:25: note: following context is `PTR'


Hmm, ok I suppose.


+  info.loc = file_location ("", 0, 0);
+  idata->loc = file_location ("", 0, 0);
+  e->loc = file_location ("built-in", -1, -1);


Use zero consistently maybe as a dummy? Ok either way.


Bernd

Re: [PATCH] Fix fallout of PR77399 fix

[Richard Biener]

On Tue, 4 Oct 2016, Uros Bizjak wrote:

> On Tue, Oct 4, 2016 at 12:00 PM, Richard Biener  wrote:
> 
> >> x86 targets should always be in pair, so "target i?86-*-* x86_64-*-*",
> >> with an optional ia32 target addition when the test is valid for 32
> >> bit targets only, or { ! ia32 } addition when test is valid for 64-bit
> >> targets only.
> >
> > I need SSE2 support but didn't want to adjust dg-options with another
> > { target } ... so with default ISA this is valid for x86_64 only
> > AFAIK?  It might be ok for i?86-*-* with -m64 thus that is your
> > { i?86-*-* x86_64-*-* } && { ! ia32 } then?  But x86_64-*-* -m32
> > is ok ...
> >
> > I'll try a
> >
> > /* { dg-options "-O -fdump-tree-cddce1 -msse2" { target { i?86-*-*
> > x86_64-*-* } } } */
> >
> > then.
> 
> You need sse2_runtime effective target. Please see e.g.
> gcc.dg/pr37544.c (or gcc.dg/pr36584.c for 32-bit only target) on how
> it should be used

It's a dg-do compile testcase only so I think that's not needed.

Richard.

[PATCH] Fix PR77826

[Richard Biener]

The following will fix PR77826, the issue that in match.pd matching
up two things uses operand_equal_p which is too lax about the type
of the toplevel entity (at least for integer constants).

Bootstrap / regtest pending on x86_64-unknown-linux-gnu.

Richard.

2016-10-04  Richard Biener  

PR middle-end/77826
* genmatch.c (dt_operand::gen_match_op): Amend operand_equal_p
with types_match to handle type mismatched constants properly.

* gcc.dg/torture/pr77826.c: New testcase.

Index: gcc/genmatch.c
===
--- gcc/genmatch.c  (revision 240739)
+++ gcc/genmatch.c  (working copy)
@@ -2593,8 +2601,10 @@ dt_operand::gen_match_op (FILE *f, int i
 {
   char match_opname[20];
   match_dop->get_name (match_opname);
-  fprintf_indent (f, indent, "if (%s == %s || operand_equal_p (%s, %s, 0))\n",
- opname, match_opname, opname, match_opname);
+  fprintf_indent (f, indent, "if (%s == %s || (operand_equal_p (%s, %s, 0) "
+ "&& types_match (%s, %s)))\n",
+ opname, match_opname, opname, match_opname,
+ opname, match_opname);
   fprintf_indent (f, indent + 2, "{\n");
   return 1;
 }
Index: gcc/testsuite/gcc.dg/torture/pr77826.c
===
--- gcc/testsuite/gcc.dg/torture/pr77826.c  (revision 0)
+++ gcc/testsuite/gcc.dg/torture/pr77826.c  (working copy)
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+
+void
+fi(unsigned long int *v0, unsigned int ow, int q2)
+{
+  if (ow + q2 != 0)
+if (q2 == 1)
+  {
+   *v0 |= q2;
+   q2 ^= *v0;
+  }
+}

Re: [PATCH] Fix fallout of PR77399 fix

[Uros Bizjak]

On Tue, Oct 4, 2016 at 12:25 PM, Richard Biener  wrote:
> On Tue, 4 Oct 2016, Uros Bizjak wrote:
>
>> On Tue, Oct 4, 2016 at 12:00 PM, Richard Biener  wrote:
>>
>> >> x86 targets should always be in pair, so "target i?86-*-* x86_64-*-*",
>> >> with an optional ia32 target addition when the test is valid for 32
>> >> bit targets only, or { ! ia32 } addition when test is valid for 64-bit
>> >> targets only.
>> >
>> > I need SSE2 support but didn't want to adjust dg-options with another
>> > { target } ... so with default ISA this is valid for x86_64 only
>> > AFAIK?  It might be ok for i?86-*-* with -m64 thus that is your
>> > { i?86-*-* x86_64-*-* } && { ! ia32 } then?  But x86_64-*-* -m32
>> > is ok ...
>> >
>> > I'll try a
>> >
>> > /* { dg-options "-O -fdump-tree-cddce1 -msse2" { target { i?86-*-*
>> > x86_64-*-* } } } */
>> >
>> > then.
>>
>> You need sse2_runtime effective target. Please see e.g.
>> gcc.dg/pr37544.c (or gcc.dg/pr36584.c for 32-bit only target) on how
>> it should be used
>
> It's a dg-do compile testcase only so I think that's not needed.

In this case, you are right.

BTW: You can use dg-additional-options in your patch.

Uros.

Re: [PATCH] Set -fprofile-update=atomic when -pthread is present

[Martin Liška]

On 10/03/2016 02:26 PM, Nathan Sidwell wrote:
> On 10/03/16 08:13, Martin Liška wrote:
>> On 08/18/2016 05:53 PM, Jeff Law wrote:
>>> On 08/18/2016 09:51 AM, Andi Kleen wrote:
> I'd prefer to make updates atomic in multi-threaded applications.
> The best proxy we have for that is -pthread.
>
> Is it slower, most definitely, but odds are we're giving folks
> garbage data otherwise, which in many ways is even worse.

 It will likely be catastrophically slower in some cases.

 Catastrophically as in too slow to be usable.

 An atomic instruction is a lot more expensive than a single increment. Also
 they sometimes are really slow depending on the state of the machine.
>>> And for those cases there's a way to override.
>>>
>>> The default should be set for correctness.
>>>
>>> jeff
>>
>> I would to somehow resolve the discussion related to default value selection.
>> Is the prevailing consensus that we should set -fprofile-update=atomic when
>> -pthread is set? If so, I'll prepare a patch. I tend to do it this way.
> 
> This is my preference.
> 
> nathan

Ok, this is final version of patch which implements both the warning and 
appending -fprofile-update
to a command line options.

Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.

Ready to be installed?
Martin
>From 343d64a3c6b515053459a8ece6f9b0ad6ce86273 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Tue, 4 Oct 2016 10:46:48 +0200
Subject: [PATCH] Add -fprofile-update option juggling

gcc/ChangeLog:

2016-10-04  Martin Liska  

	* gcc.c: Set -fprofile-update=atomic when profiling is
	enabled and -pthread is set.  Warn when one combines
	-pthread and -fprofile-update=single for an app using
	profiling code.
---
 gcc/gcc.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/gcc/gcc.c b/gcc/gcc.c
index fd2b182..5213cb0 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -1141,7 +1141,14 @@ static const char *cc1_options =
  %{-help=*:--help=%*}\
  %{!fsyntax-only:%{S:%W{o*}%{!o*:-o %b.s}}}\
  %{fsyntax-only:-o %j} %{-param*}\
- %{coverage:-fprofile-arcs -ftest-coverage}";
+ %{coverage:-fprofile-arcs -ftest-coverage}\
+ %{fprofile-arcs|fprofile-generate*|coverage:\
+   %{!fprofile-update=single:\
+ %{pthread:-fprofile-update=atomic}}}\
+ %{fprofile-update=single:\
+   %{fprofile-arcs|fprofile-generate*|coverage:\
+ %{pthread:%n-fprofile-update=atomic should be used\
+ for a multithreaded application}}}";
 
 static const char *asm_options =
 "%{-target-help:%:print-asm-header()} "
-- 
2.9.2

Re: [PATCH] Fix PR55152

[Joseph Myers]

On Tue, 4 Oct 2016, Richard Biener wrote:

> Possibly.  Though then for FP we also want - abs (a) -> copysign (a, -1).

For architectures such as powerpc that have a negated-abs instruction, 
does it get properly generated from the copysign code?  (The relevant 
pattern in rs6000.md uses (neg (abs)) - is that the correct canonical RTL 
for this?)

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

[RFC][PATCH] Canonicalize address multiplies

[Wilco Dijkstra]

GCC currently doesn't canonicalize address expressions. As a result
inefficient code is generated even for trivial index address expressions,
blocking CSE and other optimizations:

int f(int *p, int i) { return p[i+2] + p[i+1]; }

sxtwx1, w1
add x1, x1, 2
add x2, x0, x1, lsl 2
ldr w0, [x0, x1, lsl 2]
ldr w1, [x2, -4]
add w0, w1, w0
ret

After this patch:

add x1, x0, x1, sxtw 2
ldp w0, w2, [x1, 4]
add w0, w2, w0
ret

The reason for this is that array index expressions are preferably kept in 
the *(p + (i + C0) * C1) form eventhough it is best on most targets to make
use of an offset in memory accesses - ie. *(p + i * C1 + (C0*C1)).

This patch disables the folding in fold_plusminus_mult_expr that changes
the latter form into the former.  Unfortunately it isn't possible to know
it is an address expression, and neither is there a way to decide when
C0*C1 is too complex. 

So is there a better way/place to do this, or do we need an address
canonicalization phase in the tree that ensures we expand addresses in an
efficient manner, taking into account target offsets?


ChangeLog:
2016-10-04  Wilco Dijkstra  

gcc/
* fold-const.c (fold_plusminus_mult_expr): Block folding of immediates
into multiply.
--

diff --git a/gcc/fold-const.c b/gcc/fold-const.c
index 
e71ce5e0f23adbb1d4a73506769f7243900cfd2d..bc9fb1e8ff3e33c94e66a2d1282235b71fac2730
 100644
--- a/gcc/fold-const.c
+++ b/gcc/fold-const.c
@@ -6912,7 +6912,9 @@ fold_plusminus_mult_expr (location_t loc, enum tree_code 
code, tree type,
  (A * C) +- A -> A * (C+-1).
  We are most concerned about the case where C is a constant,
  but other combinations show up during loop reduction.  Since
- it is not difficult, try all four possibilities.  */
+ it is not difficult, try all four possibilities.
+ However avoid moving integer constants into the multiply:
+ (A * C0) +- C1 is better than (A +- (C1/C0)) * C0.  */
 
   if (TREE_CODE (arg0) == MULT_EXPR)
 {
@@ -6920,10 +6922,7 @@ fold_plusminus_mult_expr (location_t loc, enum tree_code 
code, tree type,
   arg01 = TREE_OPERAND (arg0, 1);
 }
   else if (TREE_CODE (arg0) == INTEGER_CST)
-{
-  arg00 = build_one_cst (type);
-  arg01 = arg0;
-}
+return NULL_TREE;
   else
 {
   /* We cannot generate constant 1 for fract.  */
@@ -6938,20 +6937,7 @@ fold_plusminus_mult_expr (location_t loc, enum tree_code 
code, tree type,
   arg11 = TREE_OPERAND (arg1, 1);
 }
   else if (TREE_CODE (arg1) == INTEGER_CST)
-{
-  arg10 = build_one_cst (type);
-  /* As we canonicalize A - 2 to A + -2 get rid of that sign for
-the purpose of this canonicalization.  */
-  if (wi::neg_p (arg1, TYPE_SIGN (TREE_TYPE (arg1)))
- && negate_expr_p (arg1)
- && code == PLUS_EXPR)
-   {
- arg11 = negate_expr (arg1);
- code = MINUS_EXPR;
-   }
-  else
-   arg11 = arg1;
-}
+return NULL_TREE;
   else
 {
   /* We cannot generate constant 1 for fract.  */

[gomp4] auto partitioning tweak

[Nathan Sidwell]

We were determining in the host compiler as to whethe a particular loop had no 
explicit partitioning.  That'll break down if device_type comes into play.  My 
tiling patch exposed this difficulty, as tiling itself ends up essentially being 
two nested loops, one of which could be explicitly partitioned and the other 
not.  So addressing this problem now.


Hopefully this is the last tweak before the tile patch itself.

nathan
2016-10-04  Nathan Sidwell  

	* omp-low.c (lower_oacc_head_mark): Don't determine default auto
	here ...
	(oacc_loop_fixed_partitions): ... do it here instead.

Index: omp-low.c
===
--- omp-low.c	(revision 240731)
+++ omp-low.c	(working copy)
@@ -6394,14 +6394,13 @@ lower_oacc_head_mark (location_t loc, tr
   if (!tgt || is_oacc_parallel (tgt))
 tag |= OLF_INDEPENDENT;
 
-  /* A loop lacking SEQ, GANG, WORKER and/or VECTOR is implicitly AUTO.  */
-  if (!(tag & (((GOMP_DIM_MASK (GOMP_DIM_MAX) - 1) << OLF_DIM_BASE)
-	   | OLF_SEQ)))
-  tag |= OLF_AUTO;
-
-  /* Ensure at least one level, or 2 for AUTO partitioning  */
-  if (levels < 1 + ((tag & OLF_AUTO) != 0))
-levels = 1 + ((tag & OLF_AUTO) != 0);
+  /* A loop lacking SEQ, GANG, WORKER and/or VECTOR could be AUTO  */
+  bool maybe_auto = !(tag & (((GOMP_DIM_MASK (GOMP_DIM_MAX) - 1)
+			  << OLF_DIM_BASE) | OLF_SEQ));
+
+  /* Ensure at least one level, or 2 for possible auto partitioning  */
+  if (levels < 1u + maybe_auto)
+levels = 1u + maybe_auto;
 
   args.quick_push (build_int_cst (integer_type_node, levels));
   args.quick_push (build_int_cst (integer_type_node, tag));
@@ -19759,6 +19758,8 @@ oacc_loop_fixed_partitions (oacc_loop *l
   this_mask = ((loop->flags >> OLF_DIM_BASE)
 		   & (GOMP_DIM_MASK (GOMP_DIM_MAX) - 1));
 
+  bool maybe_auto = !seq_par && !this_mask;
+
   if ((this_mask != 0) + auto_par + seq_par > 1)
 	{
 	  if (noisy)
@@ -19766,7 +19767,7 @@ oacc_loop_fixed_partitions (oacc_loop *l
 		  seq_par
 		  ? "% overrides other OpenACC loop specifiers"
 		  : "% conflicts with other OpenACC loop specifiers");
-	  auto_par = false;
+	  maybe_auto = false;
 	  loop->flags &= ~OLF_AUTO;
 	  if (seq_par)
 	{
@@ -19775,8 +19776,11 @@ oacc_loop_fixed_partitions (oacc_loop *l
 	  this_mask = 0;
 	}
 	}
-  if (auto_par && (loop->flags & OLF_INDEPENDENT))
-	mask_all |= GOMP_DIM_MASK (GOMP_DIM_MAX);
+  if (maybe_auto && (loop->flags & OLF_INDEPENDENT))
+	{
+	  loop->flags |= OLF_AUTO;
+	  mask_all |= GOMP_DIM_MASK (GOMP_DIM_MAX);
+	}
 }
 
   if (this_mask & outer_mask)

Re: [PATCH] Fix PR55152

[Richard Biener]

On Tue, 4 Oct 2016, Joseph Myers wrote:

> On Tue, 4 Oct 2016, Richard Biener wrote:
> 
> > Possibly.  Though then for FP we also want - abs (a) -> copysign (a, -1).
> 
> For architectures such as powerpc that have a negated-abs instruction, 
> does it get properly generated from the copysign code?  (The relevant 
> pattern in rs6000.md uses (neg (abs)) - is that the correct canonical RTL 
> for this?)

I have no idea - given that there is no copysign RTL code I suppose
it is the only machine independent RTL that can do this?

The question would be whether the copysign optab of said targets would
special-case the -1 case appropriately.

Given your comment I'm putting the copysign part of the patch on the side 
for now.  And I have to re-do the other part then.

Richard.

Re: [PATCHv2][ARM] -mpure-code option for ARM

[mickael guene]

Hi Andre,

 I can't see new testsuite files in trunk :
gcc.target/arm/pure-code/ffunction-sections.c
gcc.target/arm/pure-code/no-literal-pool.c
gcc.target/arm/pure-code/pure-code.exp

 It seems you forgot to include them in your patch.
Can you post a new one with those files ?

Regards
Mickael

On 09/23/2016 05:04 PM, Sandra Loosemore wrote:

On 09/23/2016 04:39 AM, Andre Vieira (lists) wrote:

Hi Sandra,

Is this better?

Cheers,
Andre

gcc/ChangeLog
2016-09-23  Andre Vieira  

 * target.def(elf_flags_numeric): Change documentation to
 present tense.


And here is the patch with the tm.texi regeneration.

Cheers,
Andre

gcc/ChangeLog
2016-09-23  Andre Vieira  

 * target.def(elf_flags_numeric): Change documentation to
 present tense.
 * doc/tm.texi: Regenerate.



This looks good to me.  Thanks.

-Sandra the grammar geek

Re: [PATCH] Remove x86 pcommit instruction

[Uros Bizjak]

Hello!

> 2016-10-03  Andrew Senkevich  
>
>gcc/
>
>* common/config/i386/i386-common.c (OPTION_MASK_ISA_PCOMMIT_UNSET,
>OPTION_MASK_ISA_PCOMMIT_SET): Deleted definitions.
>(ix86_handle_option): Deleted handle of OPT_mpcommit.
>* config.gcc: Deleted pcommitintrin.h
>* config/i386/pcommitintrin.h: Deleted file.
>* config/i386/cpuid.h (bit_PCOMMIT): Deleted.
>* config/i386/driver-i386.c (host_detect_local_cpu): Deleted pcommit
>detection.
>* config/i386/i386-c.c (ix86_target_macros_internal): Deleted define
>__PCOMMIT__.
>* config/i386/i386.c (ix86_target_string): Deleted -mpcommit.
>(PTA_PCOMMIT): Deleted define.
>(ix86_option_override_internal): Deleted handle of option.
>(ix86_valid_target_attribute_inner_p): Deleted pcommit.
>* config/i386/i386-builtin.def (IX86_BUILTIN_PCOMMIT,
>__builtin_ia32_pcommit): Deleted.
>* config/i386/i386.h (TARGET_PCOMMIT, TARGET_PCOMMIT_P): Deleted.
>* config/i386/i386.md (unspecv): Deleted UNSPECV_PCOMMIT.
>(pcommit): Deleted instruction.
>* config/i386/i386.opt: Deleted mpcommit.
>* config/i386/x86intrin.h: Deleted inclusion of pcommitintrin.h.
>
>gcc/testsuite/
>
>* gcc.target/i386/pcommit-1.c: Deleted.
>* gcc.target/i386/sse-12.c: Deleted -mpcommit option.
>* gcc.target/i386/sse-13.c: Ditto.
>* gcc.target/i386/sse-14.c: Ditto.
>* gcc.target/i386/sse-22.c: Ditto.
>* gcc.target/i386/sse-23.c: Ditto.
>* g++.dg/other/i386-2.C: Ditto.
>* g++.dg/other/i386-3.C: Ditto.

-mpcommit
-Target Report Mask(ISA_PCOMMIT) Var(ix86_isa_flags) Save
-Support PCOMMIT instruction.
-

You should not simply delete a option that was in the released
compiler, but a warning should be emitted instead. Please see how
msse5 is handled in i386.opt.

Uros.

Re: [Patch 3/11] Implement TARGET_C_EXCESS_PRECISION for s390

[Andreas Krebbel]

On 09/30/2016 07:57 PM, Joseph Myers wrote:
> On Fri, 30 Sep 2016, Jeff Law wrote:
> 
>> On 09/30/2016 11:34 AM, Joseph Myers wrote:
>>> On Fri, 30 Sep 2016, James Greenhalgh wrote:
>>>
 +  case EXCESS_PRECISION_TYPE_STANDARD:
 +  case EXCESS_PRECISION_TYPE_IMPLICIT:
 +  /* Otherwise, the excess precision we want when we are
 + in a standards compliant mode, and the implicit precision we
 + provide can be identical.  */
 +  return FLT_EVAL_METHOD_PROMOTE_TO_DOUBLE;
>>>
>>> That's wrong for EXCESS_PRECISION_TYPE_IMPLICIT.  There is no implicit
>>> promotion in the back end (and really there shouldn't be any excess
>>> precision here at all, and double_t in glibc should be fixed along with a
>>> GCC change to remove this mistake).
>> Sorry, change to a NAK.
>>
>> Joseph, what's the right thing to do here?
> 
> (a) The present patch would keep the existing value of FLT_EVAL_METHOD.  
> But the existing value is inaccurate for the default compilation mode, 
> when there is no implicit promotion in the back end, and doing so means 
> suboptimal code in libgcc and glibc because it does things to handle 
> excess precision that isn't actually there (and quite possibly in code 
> elsewhere that looks at FLT_EVAL_METHOD).
> 
> (b) Handling EXCESS_PRECISION_TYPE_IMPLICIT like 
> EXCESS_PRECISION_TYPE_FAST would accurately describe what the back end 
> does.  It would mean that the default FLT_EVAL_METHOD is 0, which is a 
> more accurate description of how the compiler actually behaves, and would 
> avoid the suboptimal code in libgcc and glibc.  It would however mean that 
> unless -fexcess-precision=standard is used, FLT_EVAL_METHOD (accurate) is 
> out of synx with float_t in math.h (inaccurate).

With (b) we would violate the C standard which explicitly states that the 
definition of float_t
needs to be float if FLT_EVAL_METHOD is 0. I've no idea how much code really 
relies on that. So far
I only know about the Plum Hall testsuite ;) So this probably would still be a 
safe change. Actually
it was like that for many years without any problems ... until I've changed it 
due to the Plum Hall
finding :(  https://gcc.gnu.org/ml/gcc-patches/2013-03/msg01124.html

> (c) Removing all special excess precision for S/390 from GCC, and changing 
> float_t to float in glibc, is logically correct and produces optimal code.  
> float_t does not appear in the ABI of any glibc function; in principle it 
> could affect the ABIs of other libraries, but I don't think that's 
> particularly likely.

I really would like to do this.  The idea came up several times already but we 
always were concerned
about the potential ABI break.

> The only argument for (a) is that's it's semantics-preserving - it's just 
> that the preserved semantics are nonsensical and involve an inaccurate 
> value of FLT_EVAL_METHOD in the default compilation mode.

I'll try to set up some scans on src packages to get a better feel about where 
it would potentially
break. I'll come back with the results. I do not want to block the patchset 
with this though. So if
you would like to go on quickly feel free to commit (a).

-Andreas-

Re: [Patch 3/11] Implement TARGET_C_EXCESS_PRECISION for s390

[Joseph Myers]

On Tue, 4 Oct 2016, Andreas Krebbel wrote:

> > (b) Handling EXCESS_PRECISION_TYPE_IMPLICIT like 
> > EXCESS_PRECISION_TYPE_FAST would accurately describe what the back end 
> > does.  It would mean that the default FLT_EVAL_METHOD is 0, which is a 
> > more accurate description of how the compiler actually behaves, and would 
> > avoid the suboptimal code in libgcc and glibc.  It would however mean that 
> > unless -fexcess-precision=standard is used, FLT_EVAL_METHOD (accurate) is 
> > out of synx with float_t in math.h (inaccurate).
> 
> With (b) we would violate the C standard which explicitly states that 
> the definition of float_t needs to be float if FLT_EVAL_METHOD is 0. 
> I've no idea how much code really relies on that. So far I only know 
> about the Plum Hall testsuite ;) So this probably would still be a safe 
> change. Actually it was like that for many years without any problems 
> ... until I've changed it due to the Plum Hall finding :( 
> https://gcc.gnu.org/ml/gcc-patches/2013-03/msg01124.html

You'd only violate it outside standards conformance modes (which you 
should be using for running conformance testsuites); with -std=c11 etc. 
-fexcess-precision=standard would be implied, meaning FLT_EVAL_METHOD 
remains as 1 in that case.

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

Re: [PATCH] DWARF: remove pessimistic DWARF version checks for imported entities

[Pierre-Marie de Rodat]

Hello,

Thank you very much for you help, Dominique!

On 09/29/2016 03:16 PM, Dominique d'Humières wrote:

FAIL: gfortran.dg/binding_label_tests_16.f03  -g  (internal compiler error)
FAIL: gfortran.dg/module_commons_3.f90-g  (internal compiler error)
FAIL: gfortran.dg/module_equivalence_1.f90-g  (internal compiler error)
FAIL: gfortran.dg/use_11.f90  -g  (internal compiler error)
FAIL: gfortran.dg/use_only_1.f90  -g  (internal compiler error)
FAIL: gfortran.dg/widechar_5.f90  -g  (internal compiler error)

FAIL: libgomp.fortran/udr15.f90   -g  (internal compiler error)

are giving an ICE with -g of the kind

internal compiler error: in dwarf2out_imported_module_or_decl, at 
dwarf2out.c:24070

corresponding to

  gcc_assert (scope_die->die_child);


So this is an oversight I did: the check I removed was actually useful 
for one thing: not emitting DW_TAG_imported_module DIEs in strict 
DWARFv2. DW_TAG_imported_declaration ones are always fine, though, so 
what I should do is to move the check, not remove it.



The Ada test gnat.dg/debug7.adb is also failing with

FAIL: gnat.dg/debug7.adb (test for excess errors)
Excess errors:
gnat1: incorrect object file extension


It seems it’s a bad interaction between dg-options "-cargs […]" and the 
testsuite framework. Can be fixed adding “-margs” at the end.


Here is an updated patch, fixing all the issues Dominique reported. 
Bootstrapped and regtested on x86_64-linux. I also tested on 
x86_64-apple-darwin14.5.0 that the above errors are gone.


--
Pierre-Marie de Rodat
>From fbcac99dc769c2a2280bc816e67506b67124660c Mon Sep 17 00:00:00 2001
From: Pierre-Marie de Rodat 
Date: Thu, 18 Aug 2016 11:33:23 +0200
Subject: [PATCH] DWARF: move pessimistic DWARF version checks for imported
 entities

A check in dwarf2out_imported_module_or_decl prevents
DW_TAG_imported_module from being emitted as it was introduced in the
DWARFv3 standard. However, this also prevents valid strict DWARFv2
constructs such as DW_TAG_imported_declaration from being emitted in
dwarf2out_imported_module_or_decl_1.

The latter already protects the emission of newer DWARF tags with
appropriate checks, so the one in the former is redundant and
pessimistic.  This function is already called from places like
process_scope_var, which are not protected anyway.

This patch moves the check in dwarf2out_imported_module_or_decl so that
in strict DWARFv2 mode, tags like DW_TAG_imported_declaration are
emitted while DW_TAG_imported_module are not.

gcc/

	* dwarf2out.c (dwarf2out_imported_module_or_decl): Move DWARF
	version check to protect only DW_TAG_imported_module generation.

gcc/testsuite/

	* gnat.dg/debug7.adb, gnat.dg/debug7.ads: New testcase.
---
 gcc/dwarf2out.c  |  8 +---
 gcc/testsuite/gnat.dg/debug7.adb | 10 ++
 gcc/testsuite/gnat.dg/debug7.ads |  4 
 3 files changed, 19 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/gnat.dg/debug7.adb
 create mode 100644 gcc/testsuite/gnat.dg/debug7.ads

diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 972da16..c1a3ae8 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -24041,13 +24041,15 @@ dwarf2out_imported_module_or_decl (tree decl, tree name, tree context,
   && !should_emit_struct_debug (context, DINFO_USAGE_DIR_USE))
 return;
 
-  if (!(dwarf_version >= 3 || !dwarf_strict))
-return;
-
   scope_die = get_context_die (context);
 
   if (child)
 {
+  /* DW_TAG_imported_module was introduced in the DWARFv3 specification, so
+	 there is nothing we can do, here.  */
+  if (dwarf_version < 3 && dwarf_strict)
+	return;
+
   gcc_assert (scope_die->die_child);
   gcc_assert (scope_die->die_child->die_tag == DW_TAG_imported_module);
   gcc_assert (TREE_CODE (decl) != NAMESPACE_DECL);
diff --git a/gcc/testsuite/gnat.dg/debug7.adb b/gcc/testsuite/gnat.dg/debug7.adb
new file mode 100644
index 000..cdaf089
--- /dev/null
+++ b/gcc/testsuite/gnat.dg/debug7.adb
@@ -0,0 +1,10 @@
+-- { dg-do compile }
+-- { dg-options "-cargs -g -gdwarf-2 -gstrict-dwarf -dA -margs" }
+-- { dg-final { scan-assembler "DW_TAG_imported_decl" } }
+
+package body Debug7 is
+   function Next (I : Integer) return Integer is
+   begin
+  return I + 1;
+   end Next;
+end Debug7;
diff --git a/gcc/testsuite/gnat.dg/debug7.ads b/gcc/testsuite/gnat.dg/debug7.ads
new file mode 100644
index 000..047d4a6
--- /dev/null
+++ b/gcc/testsuite/gnat.dg/debug7.ads
@@ -0,0 +1,4 @@
+package Debug7 is
+   function Next (I : Integer) return Integer;
+   function Renamed_Next (I : Integer) return Integer renames Next;
+end Debug7;
-- 
2.10.0

Re: [PATCHv2][ARM] -mpure-code option for ARM

[Andre Vieira (lists)]

On 04/10/16 14:24, mickael guene wrote:
> Hi Andre,
> 
>  I can't see new testsuite files in trunk :
> gcc.target/arm/pure-code/ffunction-sections.c
> gcc.target/arm/pure-code/no-literal-pool.c
> gcc.target/arm/pure-code/pure-code.exp
> 
>  It seems you forgot to include them in your patch.
> Can you post a new one with those files ?
> 
> Regards
> Mickael
> 

Yeah ... forgot to svn add, committed in revision r240746. Thanks for
that catch!

Cheers,
Andre

Re: [RFC][PATCH] Canonicalize address multiplies

[Oleg Endo]

On Tue, 2016-10-04 at 12:53 +, Wilco Dijkstra wrote:
> GCC currently doesn't canonicalize address expressions. As a result
> inefficient code is generated even for trivial index address
> expressions,
> blocking CSE and other optimizations:
> 
> int f(int *p, int i) { return p[i+2] + p[i+1]; }
> 
>   sxtwx1, w1
>   add x1, x1, 2
>   add x2, x0, x1, lsl 2
>   ldr w0, [x0, x1, lsl 2]
>   ldr w1, [x2, -4]
>   add w0, w1, w0
>   ret
> 
> After this patch:
> 
>   add x1, x0, x1, sxtw 2
>   ldp w0, w2, [x1, 4]
>   add w0, w2, w0
>   ret
> 
> The reason for this is that array index expressions are preferably
> kept in the *(p + (i + C0) * C1) form eventhough it is best on most
> targets to make use of an offset in memory accesses - ie. *(p + i *
> C1 + (C0*C1)).
> 
> This patch disables the folding in fold_plusminus_mult_expr that
> changes the latter form into the former.  Unfortunately it isn't
> possible to know it is an address expression, and neither is there a
> way to decide when C0*C1 is too complex. 
> 
> So is there a better way/place to do this, or do we need an address
> canonicalization phase in the tree that ensures we expand addresses
> in an efficient manner, taking into account target offsets?

There's been an effort to implement address mode selection (AMS)
optimization in GCC as part of the GSoC program.  However, it hasn't
been mainlined yet and it's for SH only, but I'd like to move that
forward and make it available to other backends, too.

It's an RTL pass and works by analyzing memory accesses inside basic
blocks, figuring out the effective address expressions, querying the
backend for address mode alternatives for each memory access and the
associated costs.  With that information it tries to find a minimal
solution (minimizing address register calculations and minimizing
address mode alternative costs), which is currently implemented with
backtracking.

For SH, the AMS pass can convert your example above from this

_f:
mov r5,r0
add #2,r0
shll2   r0
mov r4,r1
add r0,r1
mov.l   @(r0,r4),r0
add #-4,r1
mov.l   @r1,r2
rts 
add r2,r0

into this:
_f:
shll2   r5
add r5,r4
mov.l   @(4,r4),r0
mov.l   @(8,r4),r1
rts 
add r1,r0

.. which is minimal on SH.


It also fixes several missed auto-inc opportunities and was meant to
allow further address mode related optimizations like displacement
range fitting or access reordering.

Although not yet ready for mainline, the current code can be found on
github:

https://github.com/erikvarga/gcc/commits/master

https://github.com/erikvarga/gcc/blob/master/gcc/ams.h
https://github.com/erikvarga/gcc/blob/master/gcc/ams.cc

The way AMS gets address mode information from the backend is different
to GCC's current approach:

https://github.com/erikvarga/gcc/blob/master/gcc/config/sh/sh.c#L11946

Since the SH ISA is a bit irregular, there are a bunch of exceptions
and special cases in the cost calculations which take surrounding insns
and mem accesses into account.  I guess a more regular or less
restrictive ISA wouldn't need too many special cases.


Cheers,
Oleg

Re: [PATCH] add uClibc target hook (PR bootstrap/77819)

[Martin Sebor]

On 10/04/2016 02:42 AM, Bernd Schmidt wrote:

On 10/03/2016 12:02 AM, Martin Sebor wrote:

I couldn't find a good uclibc-only file where to put the new
definition of the hook so I conditionally added it to
targethooks.c.



diff --git a/gcc/targhooks.c b/gcc/targhooks.c
index d75650f..77b4a18 100644
--- a/gcc/targhooks.c
+++ b/gcc/targhooks.c
@@ -1523,6 +1523,26 @@ default_printf_pointer_format (tree, const char
**flags)
   return "%zx";
 }

+#if (DEFAULT_LIBC == LIBC_UCLIBC) && defined (SINGLE_LIBC) /* uClinux */


I think DEFAULT_LIBC is defined only for linux targets, so this won't
do. Just define unconditionally, with a declaration in targhooks.h?


I copied the conditional from config/linux.h but I admit I don't
fully understand when the macro is defined.  Should I still remove
it from targhooks.c?




+const char*
+uclibc_printf_pointer_format (tree arg, const char **flags)
+{
+  *flags = " +";
+
+  return arg && integer_zerop (arg) ? "(nil)" : "%#zx";
+}


Then again, maybe also just move the hook from linux.c here, it appears
identical.


Yes, the glibc and uclibc hooks are the same.  I don't know what
the convention is for these target hooks (i.e., whether they are
expected to be duplicated across targets even if they are the
same to reduce the risk of breaking one target as a result of
changing another, or whether duplication should be avoided even
at this risk).  From your comment it sounds like it should be
the latter and I'm okay with that.

Thanks
Martin

Re: [ipa-prop] set m_vr and bits to NULL in ipcp_transform_function

[Jan Hubicka]

> Bootstrap+test in progress on x86_64-unknown-linux-gnu.
> OK to commit if passes ?
> 
> Thanks,
> Prathamesh

> diff --git a/gcc/ipa-prop.c b/gcc/ipa-prop.c
> index 5ed9bbf..d71ffcf 100644
> --- a/gcc/ipa-prop.c
> +++ b/gcc/ipa-prop.c
> @@ -5667,6 +5667,9 @@ ipcp_transform_function (struct cgraph_node *node)
>fbi.bb_infos.release ();
>free_dominance_info (CDI_DOMINATORS);
>(*ipcp_transformations)[node->uid].agg_values = NULL;
> +  (*ipcp_transformations)[node->uid].bits = NULL;
> +  (*ipcp_transformations)[node->uid].m_vr = NULL;
> +
OK (with changelog)

Honza
>descriptors.release ();
>  
>if (!something_changed)

Re: [PATCH] Improve target pass registration

[Alexander Monakov]

On Fri, 30 Sep 2016, Jakub Jelinek wrote:
> This patch allows backends to provide their *-passes.def file with
> instructions how to ammend passes.def, which then can be inspected in
> pass-instances.def the script generates.

A few minor comments:

> --- gcc/gen-pass-instances.awk.jj 2016-09-29 22:53:10.264776158 +0200
> +++ gcc/gen-pass-instances.awk2016-09-30 13:22:53.745373889 +0200
> @@ -30,81 +32,201 @@
>  # through:
>  #   NEXT_PASS (pass_copy_prop, 8);
>  # (currently there are 8 instances of that pass)
> +#
> +# INSERT_PASS_AFTER (pass_copy_prop, 1, pass_stv);

I think it would be nice to mention that a 4th argument can be supplied and if
so, it will be passed to the pass at run time (although I see the existing
comment doesn't mention that either).

> +# will insert
> +# NEXT_PASS (pass_stv, 1);
> +# after immediately after the NEXT_PASS (pass_copy_prop, 1) line,

Typo in the comment: duplicated 'after'.

> --- gcc/config/i386/i386-passes.def.jj2016-09-30 12:54:29.959793738 
> +0200
> +++ gcc/config/i386/i386-passes.def   2016-09-30 14:01:31.237200032 +0200
> @@ -0,0 +1,31 @@
[snip]
> +
> +/*
> + Macros that should be defined used in this file:
> +   INSERT_PASS_AFTER (PASS, INSTANCE, TGT_PASS)
> +   INSERT_PASS_BEFORE (PASS, INSTANCE, TGT_PASS)
> +   REPLACE_PASS (PASS, INSTANCE, TGT_PASS)
> + */

REPLACE_PASS isn't actually used in this file.

> --- gcc/config/i386/i386-protos.h.jj  2016-06-24 12:59:29.0 +0200
> +++ gcc/config/i386/i386-protos.h 2016-09-30 14:00:54.759659671 +0200

> @@ -4105,13 +4105,15 @@ class pass_stv : public rtl_opt_pass
[snip]
>  
>/* opt_pass methods: */
>virtual bool gate (function *)
>  {
> -  return TARGET_STV && TARGET_SSE2 && optimize > 1;
> +  return (timode_p ^ (TARGET_64BIT == 0))
> +  && TARGET_STV && TARGET_SSE2 && optimize > 1;

The first line could also be 'timode_p == !!TARGET_64BIT'.
Also I believe this needs parens around the whole expression.

Alexander

Re: [PATCH] add uClibc target hook (PR bootstrap/77819)

[Bernd Schmidt]

On 10/04/2016 04:34 PM, Martin Sebor wrote:


I copied the conditional from config/linux.h but I admit I don't
fully understand when the macro is defined.


AFAICT it's done in config.gcc, for a limited set of targets.


Should I still remove it from targhooks.c?


That is compiled for all targets, not just for those which define the 
macro, so yes.



Yes, the glibc and uclibc hooks are the same.  I don't know what
the convention is for these target hooks (i.e., whether they are
expected to be duplicated across targets even if they are the
same to reduce the risk of breaking one target as a result of
changing another, or whether duplication should be avoided even
at this risk).  From your comment it sounds like it should be
the latter and I'm okay with that.


There's arguments for both. In this particular case I don't see a strong 
reason not to have a general hook available.



Bernd

Re: [PATCH] Improve target pass registration

[Jakub Jelinek]

On Tue, Oct 04, 2016 at 05:48:15PM +0300, Alexander Monakov wrote:
> On Fri, 30 Sep 2016, Jakub Jelinek wrote:
> > This patch allows backends to provide their *-passes.def file with
> > instructions how to ammend passes.def, which then can be inspected in
> > pass-instances.def the script generates.
> 
> A few minor comments:
> 
> > --- gcc/gen-pass-instances.awk.jj   2016-09-29 22:53:10.264776158 +0200
> > +++ gcc/gen-pass-instances.awk  2016-09-30 13:22:53.745373889 +0200
> > @@ -30,81 +32,201 @@
> >  # through:
> >  #   NEXT_PASS (pass_copy_prop, 8);
> >  # (currently there are 8 instances of that pass)
> > +#
> > +# INSERT_PASS_AFTER (pass_copy_prop, 1, pass_stv);
> 
> I think it would be nice to mention that a 4th argument can be supplied and if
> so, it will be passed to the pass at run time (although I see the existing
> comment doesn't mention that either).

Yeah, I've followed the earlier comments.  The 4th argument is quite rare
thing.

> > +# will insert
> > +# NEXT_PASS (pass_stv, 1);
> > +# after immediately after the NEXT_PASS (pass_copy_prop, 1) line,
> 
> Typo in the comment: duplicated 'after'.

Will fix.

> > --- gcc/config/i386/i386-passes.def.jj  2016-09-30 12:54:29.959793738 
> > +0200
> > +++ gcc/config/i386/i386-passes.def 2016-09-30 14:01:31.237200032 +0200
> > @@ -0,0 +1,31 @@
> [snip]
> > +
> > +/*
> > + Macros that should be defined used in this file:
> > +   INSERT_PASS_AFTER (PASS, INSTANCE, TGT_PASS)
> > +   INSERT_PASS_BEFORE (PASS, INSTANCE, TGT_PASS)
> > +   REPLACE_PASS (PASS, INSTANCE, TGT_PASS)
> > + */
> 
> REPLACE_PASS isn't actually used in this file.

I guess it should be
  Macros that can be used in this file:

> > --- gcc/config/i386/i386-protos.h.jj2016-06-24 12:59:29.0 
> > +0200
> > +++ gcc/config/i386/i386-protos.h   2016-09-30 14:00:54.759659671 +0200
> 
> > @@ -4105,13 +4105,15 @@ class pass_stv : public rtl_opt_pass
> [snip]
> >  
> >/* opt_pass methods: */
> >virtual bool gate (function *)
> >  {
> > -  return TARGET_STV && TARGET_SSE2 && optimize > 1;
> > +  return (timode_p ^ (TARGET_64BIT == 0))
> > +&& TARGET_STV && TARGET_SSE2 && optimize > 1;
> 
> The first line could also be 'timode_p == !!TARGET_64BIT'.

Yeah, that is probably more readable.

> Also I believe this needs parens around the whole expression.

Ok, will do.

Jakub

Re: [RFC] Extend ipa-bitwise-cp with pointer alignment propagation

[Jan Hubicka]

> Hi,
> Sorry for late response, I was travelling.
> I tried to verify the alignments are monotonously worse with the
> attached patch (verify.diff),
> which asserts that alignment lattice is not better than bits lattice
> during each propagation
> step in propagate_constants_accross_call().
> Does that look OK ?

Yes, that looks fine to me.
> 
> ipa-cp-alignment has better alignments than ipa-bit-cp in following cases:
> 
> a) ipa_get_type() returns NULL: ipa-bits-cp sets lattice to bottom if
> ipa_get_type (param) returns NULL,
> for instance in case of K&R function, while ipa-cp-alignment doesn't
> look at param types,
> and can propagate alignments.
> The following assert:
> if (bits_lattice.bottom_p ())
>   gcc_assert (align_lattice.bottom_p())
> 
> triggered for 400.perlbench, 403.gcc, 456.hmmer and 481.wrf due to
> ipa_get_type()
> returning NULL. I am not really sure how to handle this case, since we
> need to know parameter's
> type during bits propagation for obtaining precision.

Indeed, it looks like a but in alignment propagation?
> 
> b) This happens for attached test-case (test.i),
> which is a reduced (and slightly modified) test-case from 458.sjeng.
> Bits propagation sets lattice to bottom, while alignment propagation
> propagates .
> 
> In bits_lattice::meet_with_1
> m_mask = other_mask = 0x0fff0
> m_value = 0x7
> other_value = 0x8
> 
> In this case meet operation sets m_mask to:
> (m_mask | mask) | (m_value ^ other_value) = 0x0fff0 |
> (0xf) == 0x0
> and hence the bits lattice is set to bottom.
> I suppose it doesn't matter for this case if bits propagation sets
> lattice to bottom,
> since propagating  isn't really useful ?

Hmm, Martin probably knows how the alignment is defined here.  If it is power 
of two,
then it would be alignment to even byte :)
> 
> The attached patch (alignprop-4.diff) removes ipa-cp-alignment, and
> checks for misalign against old_misalgin and prints message in the dump file
> if they mismatch. Testing in progress.

Looks OK to me (with Changelog please)
> diff --git a/gcc/common.opt b/gcc/common.opt
> index 0e01577..601a347 100644
> --- a/gcc/common.opt
> +++ b/gcc/common.opt
> @@ -1565,10 +1565,6 @@ fipa-cp-clone
>  Common Report Var(flag_ipa_cp_clone) Optimization
>  Perform cloning to make Interprocedural constant propagation stronger.
>  
> -fipa-cp-alignment
> -Common Report Var(flag_ipa_cp_alignment) Optimization
> -Perform alignment discovery and propagation to make Interprocedural constant 
> propagation stronger.

I wonder if we should mark option as obsoleted and point users to consider 
-fno-ipa-bit-cp
instead.

Honza

[PATCH, i386]: Remove TARGET_VECTORIZE_DOUBLE

[Uros Bizjak]

... and use TARGET_BONNELL in ix86_add_stmt_cost.

Now that TARGET_VECTORIZE_DOUBLE is used only as a cost option in
ix86_add_stmt_cost, there is no point to have a tuning option that
covers a single target in a single place.

2016-10-04  Uros Bizjak  

* config/i386/x86-tune.def (X86_TUNE_VECTORIZE_DOUBLE): Remove.
* config/i386/i386.h (TARGET_VECTORIZE_DOUBLE): Remove.
* config/i386/i386.c (ix86_add_stmt_cost): Use TARGET_BONNEL instead
of !TARGET_VECTORIZE_DOUBLE when penalizing DFmode vector ops.

Bootstrapped and regression tested on x86_64-linux-gnu {,-m32},
committed to mainline SVN.

Uros.
Index: i386.c
===
--- i386.c  (revision 240637)
+++ i386.c  (working copy)
@@ -49667,8 +49667,8 @@ ix86_add_stmt_cost (void *data, int count, enum ve
   tree vectype = stmt_info ? stmt_vectype (stmt_info) : NULL_TREE;
   int stmt_cost = ix86_builtin_vectorization_cost (kind, vectype, misalign);
 
-  /* Penalize DFmode vector operations for !TARGET_VECTORIZE_DOUBLE.  */
-  if (kind == vector_stmt && !TARGET_VECTORIZE_DOUBLE
+  /* Penalize DFmode vector operations for Bonnell.  */
+  if (TARGET_BONNELL && kind == vector_stmt
   && vectype && GET_MODE_INNER (TYPE_MODE (vectype)) == DFmode)
 stmt_cost *= 5;  /* FIXME: The value here is arbitrary.  */
 
Index: i386.h
===
--- i386.h  (revision 240637)
+++ i386.h  (working copy)
@@ -481,8 +481,6 @@ extern unsigned char ix86_tune_features[X86_TUNE_L
 #define TARGET_OPT_AGU ix86_tune_features[X86_TUNE_OPT_AGU]
 #define TARGET_AVOID_LEA_FOR_ADDR \
ix86_tune_features[X86_TUNE_AVOID_LEA_FOR_ADDR]
-#define TARGET_VECTORIZE_DOUBLE \
-   ix86_tune_features[X86_TUNE_VECTORIZE_DOUBLE]
 #define TARGET_SOFTWARE_PREFETCHING_BENEFICIAL \
ix86_tune_features[X86_TUNE_SOFTWARE_PREFETCHING_BENEFICIAL]
 #define TARGET_AVX128_OPTIMAL \
Index: x86-tune.def
===
--- x86-tune.def(revision 240637)
+++ x86-tune.def(working copy)
@@ -322,10 +322,6 @@ DEF_TUNE (X86_TUNE_EXT_80387_CONSTANTS, "ext_80387
 /* SSE instruction selection tuning  */
 /*/
 
-/* X86_TUNE_VECTORIZE_DOUBLE: Enable double precision vector
-   instructions.  */
-DEF_TUNE (X86_TUNE_VECTORIZE_DOUBLE, "vectorize_double", ~m_BONNELL)
-
 /* X86_TUNE_GENERAL_REGS_SSE_SPILL: Try to spill general regs to SSE
regs instead of memory.  */
 DEF_TUNE (X86_TUNE_GENERAL_REGS_SSE_SPILL, "general_regs_sse_spill",

Re: [C++ PATCH] Delete GCJ - C++ part

[Jason Merrill]

OK.

On Sun, Oct 2, 2016 at 3:58 PM, Jakub Jelinek  wrote:
> On Sun, Oct 02, 2016 at 03:27:09PM +0200, Andreas Schwab wrote:
>> Things we may want to remove:
>>
>> - references to java in contrib (download_ecj, gcc_update,
>>   patch_tester.sh, update-copyright.py)
>> - GCJ, GCJ_FOR_BUILD, GCJ_FOR_TARGET in Makefiles.tpl and configure.ac
>> - LIBGCJ_SONAME in config/i386/{cygwin.h,mingw32.h}
>> - references to java in install.texi
>
> There is another thing, the Java extensions in the C++ FE, which are IMNSHO
> no longer needed after GCJ removal.
>
> Here is a C++ patch that removes that part, bootstrapped/regtested on
> x86_64-linux and i686-linux, ok for trunk?
>
> 2016-10-02  Jakub Jelinek  
>
> * doc/extend.texi (Java Exceptions): Remove.
> (java_interface): Remove.
> cp/
> * cp-tree.h (enum cp_tree_index): Remove CPTI_JAVA_*,
> CPTI_LANG_NAME_JAVA and CPTI_JCLASS.
> (java_byte_type_node, java_short_type_node, java_int_type_node,
> java_long_type_node, java_float_type_node, java_double_type_node,
> java_char_type_node, java_boolean_type_node, lang_name_java,
> jclass_node): Remove.
> (enum languages): Remove lang_java.
> (TYPE_FOR_JAVA): Remove.
> (struct lang_type_class): Remove java_interface bit-field.
> (TYPE_JAVA_INTERFACE): Remove.
> (pragma_java_exceptions): Remove.
> (check_java_method, build_java_class_ref): Remove prototypes.
> * name-lookup.c (pushtag_1): Don't set TYPE_FOR_JAVA.
> * decl2.c (acceptable_java_type, check_java_method): Remove.
> (import_export_decl): Remove TYPE_FOR_JAVA handling.
> (build_java_method_aliases): Remove.
> (c_parse_final_cleanups): Don't call build_java_method_aliases.
> (possibly_inlined_p): Don't test pragma_java_exceptions.
> * init.c (build_new_1): Remove TYPE_FOR_JAVA handling.
> (build_java_class_ref): Remove.
> * pt.c (maybe_new_partial_specialization, lookup_template_class_1,
> instantiate_class_template_1): Don't copy TYPE_FOR_JAVA.
> * except.c (eh_type_info): Remove java type handling.
> (decl_is_java_type, choose_personality_routine): Remove.
> (initialize_handler_parm): Don't call choose_personality_routine.
> (expand_start_catch_block): Don't handle java types.
> (build_throw): Likewise.
> * cp-lang.c (cp_eh_personality): Don't handle pragma_java_exceptions.
> * typeck.c (structural_comptypes): Don't compare TYPE_FOR_JAVA.
> * call.c (build_over_call): Don't handle TYPE_JAVA_INTERFACE.
> (java_iface_lookup_fn): Remove.
> (build_java_interface_fn_ref): Remove.
> * tree.c (cxx_attribute_table): Remove java_interface.
> (handle_java_interface_attribute): Remove.
> * lex.c (pragma_java_exceptions): Remove.
> (init_cp_pragma): Don't register GCC java_exceptions pragma.
> (handle_pragma_java_exceptions): Remove.
> (retrofit_lang_decl): Don't handle lang_name_java.
> * method.c (implicitly_declare_fn): Don't handle TYPE_FOR_JAVA.
> * error.c (language_to_string): Don't handle lang_java.
> * decl.c (record_builtin_java_type): Remove.
> (initialize_predefined_identifiers): Remove Java.
> (cxx_init_decl_processing): Remove java_*_type_node.
> (cp_finish_decl): Don't handle TYPE_FOR_JAVA.
> (grokfndecl): Likewise.
> (check_special_function_return_type): Likewise.
> (grokdeclarator): Don't set TYPE_FOR_JAVA.
> (grokparms): Don't handle TYPE_FOR_JAVA.
> (xref_basetypes): Likewise.
> (check_function_type): Likewise.
> (finish_constructor_body): Likewise.
> * mangle.c (write_builtin_type): Don't handle TYPE_FOR_JAVA
> and java_*_type_node.
> (write_bare_function_type): Don't handle TYPE_FOR_JAVA.
> (write_java_integer_type_codes): Remove.
> * class.c (add_method): Don't handle TYPE_FOR_JAVA.
> (add_implicitly_declared_members, determine_key_method,
> finish_struct_1): Likewise.
> (push_lang_context): Don't handle lang_name_java.
> testsuite/
> * g++.dg/other/java3.C: Remove.
> * g++.dg/other/java1.C: Remove.
> * g++.dg/other/error12.C: Remove.
> * g++.dg/other/java2.C: Remove.
> * g++.dg/warn/Wnvdtor.C: Remove.
> * g++.dg/lookup/java1.C: Remove.
> * g++.dg/lookup/java2.C: Remove.
> * g++.dg/ext/pr34829.C: Remove.
> * g++.dg/ext/java-3.C: Remove.
> * g++.dg/ext/java-1.C: Remove.
> * g++.dg/ext/java-2.C: Remove.
> * g++.old-deja/g++.oliva/dwarf2.C: Remove.
>
> --- gcc/doc/extend.texi.jj  2016-09-29 22:53:11.0 +0200
> +++ gcc/doc/extend.texi 2016-10-02 19:27:25.315410894 +0200
> @@ -21392,7 +21392,6 @@ Predefined Macros,cpp,The GNU C Preproce
>  * Namespace Association:: Strong usi

Re: [PATCH] fix PR c++/77804 - ICE on placement VLA new

[Jason Merrill]

OK.

On Mon, Oct 3, 2016 at 4:53 PM, Martin Sebor  wrote:
> The attached patch removes an assumption from the implementation
> of the -Wplacement-new warning that the size of the array type
> enclosed in parentheses and accepted by G++ as an extension is
> constant.  The assumption causes an ICE in 6.2.0 and 7.0.
>
> Is the patch good to commit to both 7.0 and the 6 branch?
>
> Thanks
> Martin

Re: [C++ PATCH] Fix ICE during C++11 lambda error recovery (PR c++/77791)

[Jason Merrill]

OK.

On Mon, Oct 3, 2016 at 1:32 PM, Jakub Jelinek  wrote:
> Hi!
>
> In param_list some entries could be error_mark_node, we should just ignore
> those.  ALso, this patch optimizes by testing cxx_dialect < cxx14 just once.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2016-10-03  Jakub Jelinek  
>
> PR c++/77791
> * parser.c (cp_parser_lambda_declarator_opt): Only pedwarn
> for C++11 on decls in the param_list.  Test cxx_dialect < cxx14 before
> the loop just once.
>
> * g++.dg/cpp0x/lambda/lambda-77791.C: New test.
>
> --- gcc/cp/parser.c.jj  2016-09-27 21:09:59.0 +0200
> +++ gcc/cp/parser.c 2016-10-03 15:00:31.759317804 +0200
> @@ -10114,10 +10114,11 @@ cp_parser_lambda_declarator_opt (cp_pars
>
>/* Default arguments shall not be specified in the
>  parameter-declaration-clause of a lambda-declarator.  */
> -  for (tree t = param_list; t; t = TREE_CHAIN (t))
> -   if (TREE_PURPOSE (t) && cxx_dialect < cxx14)
> - pedwarn (DECL_SOURCE_LOCATION (TREE_VALUE (t)), OPT_Wpedantic,
> -  "default argument specified for lambda parameter");
> +  if (cxx_dialect < cxx14)
> +   for (tree t = param_list; t; t = TREE_CHAIN (t))
> + if (TREE_PURPOSE (t) && DECL_P (TREE_VALUE (t)))
> +   pedwarn (DECL_SOURCE_LOCATION (TREE_VALUE (t)), OPT_Wpedantic,
> +"default argument specified for lambda parameter");
>
>cp_parser_require (parser, CPP_CLOSE_PAREN, RT_CLOSE_PAREN);
>
> --- gcc/testsuite/g++.dg/cpp0x/lambda/lambda-77791.C.jj 2016-10-03 
> 15:01:21.831694292 +0200
> +++ gcc/testsuite/g++.dg/cpp0x/lambda/lambda-77791.C2016-10-03 
> 14:58:22.0 +0200
> @@ -0,0 +1,4 @@
> +// PR c++/77791
> +// { dg-do compile { target c++11 } }
> +
> +auto a = [] (int i, int i = 0) {}; // { dg-error "redefinition of" }
>
> Jakub

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

[Jeff Law]

On 10/03/2016 06:53 AM, Rainer Orth wrote:

Andrew Haley  writes:


On 30/09/16 23:16, Rainer Orth wrote:

me too, though mostly to have maximum test coverage (primarily on
Solaris).  As expected, a x86_64-apple-darwin16 bootstrap with
--enable-objc-gc just failed for me.  I'm testing the following patch
(on top of Jakub's).

Rainer


2016-10-01  Rainer Orth  

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


Thanks everybody.  My apologies.


The bootstrap completed successfully now.  Ok for mainline?

Yes.
jeff

RE: Fix PR tree-optimization/77808, ICE in duplicate_ssa_name_ptr_info, at tree-ssanames.c:630 starting with r240439

[Matthew Fortune]

Richard Biener  writes:
> On Sat, Oct 1, 2016 at 3:35 AM, Doug Gilmore 
> wrote:
> > My commit r240439 didn't handle the situation where setting --param
> > prefetch-latency=0 can cause the prefetch address to be the same as
> > the original address.  In this case, no copying of points-to
> > information should be done.
> >
> > Bootstrapped and regression tested on x86_64-linux, ok for trunk?
> 
> Ok.
> 
> RIchard.

Committed as r240749.

(I updated the changelog to say what changed)

gcc/
PR tree-optimization/77808
* tree-ssa-loop-prefetch.c (issue_prefetch_ref): Check base_addr
and addr are different before copying points-to information.

gcc/testsuite
PR tree-optimization/77808
* gcc.dg/tree-ssa/pr77808.c: New testcase.


Matthew

Re: [PATCH] Fix -Wimplicit-fallthrough -C, handle some more comment styles and comments in between FALLTHRU comment and label

[Michael Matz]

Hi,

On Sat, 1 Oct 2016, Jakub Jelinek wrote:

> > -  /* ... fall through for unsigned ints ...  */
> > +  /* fall through */
> > 
> > -/* For other instructions, fallthru.  */
> > +/* fallthru.  */
> > 
> > -  /* fall thru to manual case */
> > +  /* fall thru */
> > 
> > 
> > So, because of its excessive pickiness, the warning ends up making the user 
> > butcher informative comments.  How is that helpful?
> 
> Note, the wast majority of the fallthru comments are already recognized, it
> is only when people start to write those in free form.

Which is what happens often.  How can you not see that with patches 
transforming from free form to strict form fly by _on this very mailing 
list_ ?

> E.g. today I wanted to try Marek's testcase from some PR and have commented
> out [[fallthrough]]; attribute - // [[fallthrough]];
> if we are not picky enough, it will be handled as a valid fallthrough
> comment, which might not be the intent.

That quickly gets into absurd arguments for strictness.


Ciao,
Michael.

Re: [PATCH] Fix -Wimplicit-fallthrough -C, handle some more comment styles and comments in between FALLTHRU comment and label

[Marek Polacek]

On Tue, Oct 04, 2016 at 05:58:17PM +0200, Michael Matz wrote:
> Hi,
> 
> On Sat, 1 Oct 2016, Jakub Jelinek wrote:
> 
> > > -  /* ... fall through for unsigned ints ...  */
> > > +  /* fall through */
> > > 
> > > -/* For other instructions, fallthru.  */
> > > +/* fallthru.  */
> > > 
> > > -  /* fall thru to manual case */
> > > +  /* fall thru */
> > > 
> > > 
> > > So, because of its excessive pickiness, the warning ends up making the 
> > > user 
> > > butcher informative comments.  How is that helpful?
> > 
> > Note, the wast majority of the fallthru comments are already recognized, it
> > is only when people start to write those in free form.
> 
> Which is what happens often.  How can you not see that with patches 
> transforming from free form to strict form fly by _on this very mailing 
> list_ ?

I think the vast majority of the comments I changed (removing "...") wouldn't
have to be changed were this patch in.  But it didn't hurt, either.

Marek

Always support float128 on ia64 (PR target/77586)

[Joseph Myers]

Bug 77586, and previously
, reports
ia64-elf failing to build because of float128_type_node being NULL,
but being used by the back end for __float128.

The global float128_type_node is only available conditionally, if
target hooks indicate TFmode is not only available as a scalar mode
and of the right format, but also supported in libgcc.  The back-end
support, however, expects the type always to be available for
__float128 even if the libgcc support is missing.

Although a target-specific node could be restored in the case where
libgcc support is missing, it seems better to address the missing
libgcc support.  Thus, this patch enables TFmode soft-fp in libgcc
globally for all ia64 targets.  Support for XFmode in libgcc (that is,
for libgcc2.c XFmode functions, not soft-fp) is also enabled for all
ia64 targets so that ia64 no longer needs to define the
TARGET_LIBGCC_FLOATING_MODE_SUPPORTED_P hook.

I've confirmed that ia64-elf builds cc1 with this patch and it passes
-fself-test.  I have not otherwise tested the patch.  It's plausible
that ia64-elf and ia64-freebsd might work as-is, but ia64-vms probably
needs further changes, by someone familiar with VMS shared libraries,
to implement an equivalent of ia64/t-softfp-compat in that case
(avoiding conflicts between __divtf3 from soft-fp and the old alias
for __divxf3).

gcc:
2016-10-04  Joseph Myers  

PR target/77586
* config/ia64/ia64.c (ia64_libgcc_floating_mode_supported_p)
(TARGET_LIBGCC_FLOATING_MODE_SUPPORTED_P): Remove.
* config/ia64/elf.h (IA64_NO_LIBGCC_TFMODE): Likewise.
* config/ia64/freebsd.h (IA64_NO_LIBGCC_TFMODE): Likewise.
* config/ia64/vms.h (IA64_NO_LIBGCC_XFMODE)
(IA64_NO_LIBGCC_TFMODE): Likewise.

libgcc:
2016-10-04  Joseph Myers  

PR target/77586
* config.host (ia64*-*-elf*, ia64*-*-freebsd*, ia64-hp-*vms*): Use
soft-fp.

Index: gcc/config/ia64/elf.h
===
--- gcc/config/ia64/elf.h   (revision 240740)
+++ gcc/config/ia64/elf.h   (working copy)
@@ -65,6 +65,4 @@
  %{pg:gcrt0.o%s}%{!pg:%{p:mcrt0.o%s}%{!p:crt0.o%s\
crti.o%s crtbegin.o%s"
 
-#define IA64_NO_LIBGCC_TFMODE
-
 /* End of elf.h */
Index: gcc/config/ia64/freebsd.h
===
--- gcc/config/ia64/freebsd.h   (revision 240740)
+++ gcc/config/ia64/freebsd.h   (working copy)
@@ -50,5 +50,3 @@
 #define TARGET_ELF 1
 
 #define JMP_BUF_SIZE  76
-
-#define IA64_NO_LIBGCC_TFMODE
Index: gcc/config/ia64/ia64.c
===
--- gcc/config/ia64/ia64.c  (revision 240740)
+++ gcc/config/ia64/ia64.c  (working copy)
@@ -311,7 +311,6 @@
 static tree ia64_gimplify_va_arg (tree, tree, gimple_seq *, gimple_seq *);
 static bool ia64_scalar_mode_supported_p (machine_mode mode);
 static bool ia64_vector_mode_supported_p (machine_mode mode);
-static bool ia64_libgcc_floating_mode_supported_p (machine_mode mode);
 static bool ia64_legitimate_constant_p (machine_mode, rtx);
 static bool ia64_legitimate_address_p (machine_mode, rtx, bool);
 static bool ia64_cannot_force_const_mem (machine_mode, rtx);
@@ -595,10 +594,6 @@
 #undef TARGET_VECTOR_MODE_SUPPORTED_P
 #define TARGET_VECTOR_MODE_SUPPORTED_P ia64_vector_mode_supported_p
 
-#undef TARGET_LIBGCC_FLOATING_MODE_SUPPORTED_P
-#define TARGET_LIBGCC_FLOATING_MODE_SUPPORTED_P \
-  ia64_libgcc_floating_mode_supported_p
-
 #undef TARGET_LEGITIMATE_CONSTANT_P
 #define TARGET_LEGITIMATE_CONSTANT_P ia64_legitimate_constant_p
 #undef TARGET_LEGITIMATE_ADDRESS_P
@@ -11008,36 +11003,6 @@
 }
 }
 
-/* Implement TARGET_LIBGCC_FLOATING_MODE_SUPPORTED_P.  */
-
-static bool
-ia64_libgcc_floating_mode_supported_p (machine_mode mode)
-{
-  switch (mode)
-{
-case SFmode:
-case DFmode:
-  return true;
-
-case XFmode:
-#ifdef IA64_NO_LIBGCC_XFMODE
-  return false;
-#else
-  return true;
-#endif
-
-case TFmode:
-#ifdef IA64_NO_LIBGCC_TFMODE
-  return false;
-#else
-  return true;
-#endif
-
-default:
-  return false;
-}
-}
-
 /* Implement the FUNCTION_PROFILER macro.  */
 
 void
Index: gcc/config/ia64/vms.h
===
--- gcc/config/ia64/vms.h   (revision 240740)
+++ gcc/config/ia64/vms.h   (working copy)
@@ -154,6 +154,3 @@
 /* Default values for _CRTL_VER and _VMS_VER.  */
 #define VMS_DEFAULT_CRTL_VER 8030
 #define VMS_DEFAULT_VMS_VER 8030
-
-#define IA64_NO_LIBGCC_XFMODE
-#define IA64_NO_LIBGCC_TFMODE
Index: libgcc/config.host
===
--- libgcc/config.host  (revision 240740)
+++ libgcc/config.host  (working copy)
@@ -746,11 +746,11 @@
;;
 ia64*-*-elf*)
extra_parts="$extra_parts crtbeginS.o cr

Re: [PATCH] Fix -Wimplicit-fallthrough -C, handle some more comment styles and comments in between FALLTHRU comment and label

[Eric Botcazou]

> I think the vast majority of the comments I changed (removing "...")
> wouldn't have to be changed were this patch in.

So can we install it instead of arguing about hypothetical things?

-- 
Eric Botcazou

Re: [PATCH] Fix PR55152

[Joseph Myers]

On Tue, 4 Oct 2016, Richard Biener wrote:

> On Tue, 4 Oct 2016, Joseph Myers wrote:
> 
> > On Tue, 4 Oct 2016, Richard Biener wrote:
> > 
> > > Possibly.  Though then for FP we also want - abs (a) -> copysign (a, -1).
> > 
> > For architectures such as powerpc that have a negated-abs instruction, 
> > does it get properly generated from the copysign code?  (The relevant 
> > pattern in rs6000.md uses (neg (abs)) - is that the correct canonical RTL 
> > for this?)
> 
> I have no idea - given that there is no copysign RTL code I suppose
> it is the only machine independent RTL that can do this?
> 
> The question would be whether the copysign optab of said targets would
> special-case the -1 case appropriately.

Why -1?  Any constant in copysign should be handled appropriately.  I'd 
say that (neg (abs)) is probably better as a canonical representation, so 
map copysign from a constant to either (abs) or (neg (abs)) appropriately.

Then in the case where abs is expanded with bit manipulation, (neg (abs)) 
should be expanded to a single OR.  I don't know whether the RTL 
optimizers will map the AND / OR combination to a single OR, but if they 
do then there should be no need to special-case (neg (abs)) in expansion, 
and when (abs) RTL is generated a machine description's (neg (abs)) 
pattern should match automatically.

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

[PATCH] Move strchr folding to gimple-fold

[Wilco Dijkstra]

As suggested in https://gcc.gnu.org/ml/gcc-patches/2016-09/msg02216.html,
move all existing strchr and strrchr folding from builtins.c to gimple-fold.c.

Passes C/C++ regression & bootstrap.

2016-10-04  Wilco Dijkstra  

* builtins.c (fold_builtin_strchr): Remove function.
(fold_builtin_strrchr): Likewise.
(fold_builtin2): Remove strchr, index, strrchr, rindex cases.
* gimple-fold.c (target_char_cst_p): New function.
(gimple_fold_builtin_strchr) Add more foldings.
(gimple_fold_builtin): Add index, strrchr, rindex cases.

--

diff --git a/gcc/builtins.c b/gcc/builtins.c
index 
04dcf95acd21bf092c730d5fdd08b58c497c1ab5..6f034ad78fa157bbce65e954fd754347032ab20e
 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -148,7 +148,6 @@ static tree rewrite_call_expr (location_t, tree, int, tree, 
int, ...);
 static bool validate_arg (const_tree, enum tree_code code);
 static rtx expand_builtin_fabs (tree, rtx, rtx);
 static rtx expand_builtin_signbit (tree, rtx);
-static tree fold_builtin_strchr (location_t, tree, tree, tree);
 static tree fold_builtin_memchr (location_t, tree, tree, tree, tree);
 static tree fold_builtin_memcmp (location_t, tree, tree, tree);
 static tree fold_builtin_strcmp (location_t, tree, tree);
@@ -168,7 +167,6 @@ static tree fold_builtin_varargs (location_t, tree, tree*, 
int);
 
 static tree fold_builtin_strpbrk (location_t, tree, tree, tree);
 static tree fold_builtin_strstr (location_t, tree, tree, tree);
-static tree fold_builtin_strrchr (location_t, tree, tree, tree);
 static tree fold_builtin_strspn (location_t, tree, tree);
 static tree fold_builtin_strcspn (location_t, tree, tree);
 
@@ -8393,14 +8391,6 @@ fold_builtin_2 (location_t loc, tree fndecl, tree arg0, 
tree arg1)
 case BUILT_IN_STRCSPN:
   return fold_builtin_strcspn (loc, arg0, arg1);
 
-case BUILT_IN_STRCHR:
-case BUILT_IN_INDEX:
-  return fold_builtin_strchr (loc, arg0, arg1, type);
-
-case BUILT_IN_STRRCHR:
-case BUILT_IN_RINDEX:
-  return fold_builtin_strrchr (loc, arg0, arg1, type);
-
 case BUILT_IN_STRCMP:
   return fold_builtin_strcmp (loc, arg0, arg1);
 
@@ -8893,124 +8883,6 @@ fold_builtin_strstr (location_t loc, tree s1, tree s2, 
tree type)
 }
 }
 
-/* Simplify a call to the strchr builtin.  S1 and S2 are the arguments to
-   the call, and TYPE is its return type.
-
-   Return NULL_TREE if no simplification was possible, otherwise return the
-   simplified form of the call as a tree.
-
-   The simplified form may be a constant or other expression which
-   computes the same value, but in a more efficient manner (including
-   calls to other builtin functions).
-
-   The call may contain arguments which need to be evaluated, but
-   which are not useful to determine the result of the call.  In
-   this case we return a chain of COMPOUND_EXPRs.  The LHS of each
-   COMPOUND_EXPR will be an argument which must be evaluated.
-   COMPOUND_EXPRs are chained through their RHS.  The RHS of the last
-   COMPOUND_EXPR in the chain will contain the tree for the simplified
-   form of the builtin function call.  */
-
-static tree
-fold_builtin_strchr (location_t loc, tree s1, tree s2, tree type)
-{
-  if (!validate_arg (s1, POINTER_TYPE)
-  || !validate_arg (s2, INTEGER_TYPE))
-return NULL_TREE;
-  else
-{
-  const char *p1;
-
-  if (TREE_CODE (s2) != INTEGER_CST)
-   return NULL_TREE;
-
-  p1 = c_getstr (s1);
-  if (p1 != NULL)
-   {
- char c;
- const char *r;
- tree tem;
-
- if (target_char_cast (s2, &c))
-   return NULL_TREE;
-
- r = strchr (p1, c);
-
- if (r == NULL)
-   return build_int_cst (TREE_TYPE (s1), 0);
-
- /* Return an offset into the constant string argument.  */
- tem = fold_build_pointer_plus_hwi_loc (loc, s1, r - p1);
- return fold_convert_loc (loc, type, tem);
-   }
-  return NULL_TREE;
-}
-}
-
-/* Simplify a call to the strrchr builtin.  S1 and S2 are the arguments to
-   the call, and TYPE is its return type.
-
-   Return NULL_TREE if no simplification was possible, otherwise return the
-   simplified form of the call as a tree.
-
-   The simplified form may be a constant or other expression which
-   computes the same value, but in a more efficient manner (including
-   calls to other builtin functions).
-
-   The call may contain arguments which need to be evaluated, but
-   which are not useful to determine the result of the call.  In
-   this case we return a chain of COMPOUND_EXPRs.  The LHS of each
-   COMPOUND_EXPR will be an argument which must be evaluated.
-   COMPOUND_EXPRs are chained through their RHS.  The RHS of the last
-   COMPOUND_EXPR in the chain will contain the tree for the simplified
-   form of the builtin function call.  */
-
-static tree
-fold_builtin_strrchr (location_t loc, tree s1, tree s2, tree type)
-{
-  if (!validate_arg (s1, POINTER_TYPE)
-  

Re: [PATCH] Delete GCJ

[Mike Stump]

On Oct 4, 2016, at 1:41 AM, Andrew Haley  wrote:
> 
> On 04/10/16 09:39, Rainer Orth wrote:
>> Hi Matthias,
>> 
>>> On 05.09.2016 17:13, Andrew Haley wrote:
 As discussed.  I think I should ask a Global reviewer to approve this
 one.  For obvious reasons I haven't included the diffs to the deleted
 gcc/java and libjava directories.  The whole tree, post GCJ-deletion,
 is at svn+ssh://gcc.gnu.org/svn/gcc/branches/gcj/gcj-deletion-branch
 if anyone would like to try it.
>>> 
>>> still breaks bootstraps when configured with --enable-objc-gc.
>>> 
>>> the immediate step should be to fix the bootstrap failure, as an additional 
>>> step
>>> to remove boehm-gc from the gcc sources and be able to use an external 
>>> boehm-gc.
>> 
>> the first part is handled by my unreviewed patch
>> 
>>  https://gcc.gnu.org/ml/gcc-patches/2016-09/msg02437.html
> 
> Looks obvious to me, fixes bootstrap.  I think no-one will complain
> if you check it in.

I don't know who wants to review it, but if people want me to, Ok.  The idea is 
that if ObjC is the last remaining user in tree for boehm-gc, then reasonably 
I'm the last man standing.  Of course, if others want to review approve the 
patch, I'm fine with that.  

I'm fine with patches to externalize boehm-gc if people want to push that 
direction.

Re: [PATCH] Delete GCJ

[Andrew Pinski]

On Tue, Oct 4, 2016 at 10:23 AM, Mike Stump  wrote:
> On Oct 4, 2016, at 1:41 AM, Andrew Haley  wrote:
>>
>> On 04/10/16 09:39, Rainer Orth wrote:
>>> Hi Matthias,
>>>
 On 05.09.2016 17:13, Andrew Haley wrote:
> As discussed.  I think I should ask a Global reviewer to approve this
> one.  For obvious reasons I haven't included the diffs to the deleted
> gcc/java and libjava directories.  The whole tree, post GCJ-deletion,
> is at svn+ssh://gcc.gnu.org/svn/gcc/branches/gcj/gcj-deletion-branch
> if anyone would like to try it.

 still breaks bootstraps when configured with --enable-objc-gc.

 the immediate step should be to fix the bootstrap failure, as an 
 additional step
 to remove boehm-gc from the gcc sources and be able to use an external 
 boehm-gc.
>>>
>>> the first part is handled by my unreviewed patch
>>>
>>>  https://gcc.gnu.org/ml/gcc-patches/2016-09/msg02437.html
>>
>> Looks obvious to me, fixes bootstrap.  I think no-one will complain
>> if you check it in.
>
> I don't know who wants to review it, but if people want me to, Ok.  The idea 
> is that if ObjC is the last remaining user in tree for boehm-gc, then 
> reasonably I'm the last man standing.  Of course, if others want to review 
> approve the patch, I'm fine with that.

From a runtime maintainer position, I am also fine with this patch.

>
> I'm fine with patches to externalize boehm-gc if people want to push that 
> direction.

I am also ok with that too.

Thanks,
Andrew


>

[PATCH] backport dejagnu relative numbers to 6-branch?

[Martin Sebor]

While backporting a patch for 77804 to the gcc-6-branch I noticed
that the DejaGnu relative number patch below is not available
there (the new test failed).  Is it worth backporting it to it?

  https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01617.html

Martin

Re: [PATCH] backport dejagnu relative numbers to 6-branch?

[Jakub Jelinek]

On Tue, Oct 04, 2016 at 12:05:50PM -0600, Martin Sebor wrote:
> While backporting a patch for 77804 to the gcc-6-branch I noticed
> that the DejaGnu relative number patch below is not available
> there (the new test failed).  Is it worth backporting it to it?
> 
>   https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01617.html

Dunno, some people tend to backport testsuite infrastructure improvements,
but one still has to test stuff on the release branches anyway, so adjusting
to older infrastructure isn't that hard either.

So, I'd leave such a decision to the testsuite maintainers if somebody is
willing to test the backport of the patch.

Jakub

Re: [PATCH] Delete GCJ

[Iain Sandoe]

> On 4 Oct 2016, at 18:23, Mike Stump  wrote:
> 
> On Oct 4, 2016, at 1:41 AM, Andrew Haley  wrote:
>> 
>> On 04/10/16 09:39, Rainer Orth wrote:
>>> Hi Matthias,
>>> 
 On 05.09.2016 17:13, Andrew Haley wrote:
> As discussed.  I think I should ask a Global reviewer to approve this
> one.  For obvious reasons I haven't included the diffs to the deleted
> gcc/java and libjava directories.  The whole tree, post GCJ-deletion,
> is at svn+ssh://gcc.gnu.org/svn/gcc/branches/gcj/gcj-deletion-branch
> if anyone would like to try it.
 
 still breaks bootstraps when configured with --enable-objc-gc.
 
 the immediate step should be to fix the bootstrap failure, as an 
 additional step
 to remove boehm-gc from the gcc sources and be able to use an external 
 boehm-gc.
>>> 
>>> the first part is handled by my unreviewed patch
>>> 
>>> https://gcc.gnu.org/ml/gcc-patches/2016-09/msg02437.html
>> 
>> Looks obvious to me, fixes bootstrap.  I think no-one will complain
>> if you check it in.
> 
> I don't know who wants to review it, but if people want me to, Ok.  The idea 
> is that if ObjC is the last remaining user in tree for boehm-gc, then 
> reasonably I'm the last man standing.  Of course, if others want to review 
> approve the patch, I'm fine with that.  
> 
> I'm fine with patches to externalize boehm-gc if people want to push that 
> direction.

+1

Iain

Re: [PATCH] backport dejagnu relative numbers to 6-branch?

[Mike Stump]

On Oct 4, 2016, at 11:05 AM, Martin Sebor  wrote:
> 
> While backporting a patch for 77804 to the gcc-6-branch I noticed
> that the DejaGnu relative number patch below is not available
> there (the new test failed).  Is it worth backporting it to it?
> 
>  https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01617.html

Backport Ok.

Re: [PATCH] backport dejagnu relative numbers to 6-branch?

[Martin Sebor]

On 10/04/2016 12:35 PM, Jakub Jelinek wrote:

On Tue, Oct 04, 2016 at 12:05:50PM -0600, Martin Sebor wrote:

While backporting a patch for 77804 to the gcc-6-branch I noticed
that the DejaGnu relative number patch below is not available
there (the new test failed).  Is it worth backporting it to it?

  https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01617.html


Dunno, some people tend to backport testsuite infrastructure improvements,
but one still has to test stuff on the release branches anyway, so adjusting
to older infrastructure isn't that hard either.

So, I'd leave such a decision to the testsuite maintainers if somebody is
willing to test the backport of the patch.


I ran the C++ test suite with the patch with no unexpected failures
before proposing it.  I'm willing to run the rest of it if Mike and
Rainer (CC'd) think it's worth the effort.  I don't know how many
more 6.x releases to expect and don't have a sense of how many bug
fixes tend to get backported into each so I fully defer to others
on this decision.

Martin

Re: [PATCH] DWARF: remove pessimistic DWARF version checks for imported entities

[Jason Merrill]

OK.

On Tue, Oct 4, 2016 at 9:58 AM, Pierre-Marie de Rodat
 wrote:
> Hello,
>
> Thank you very much for you help, Dominique!
>
> On 09/29/2016 03:16 PM, Dominique d'Humières wrote:
>>
>> FAIL: gfortran.dg/binding_label_tests_16.f03  -g  (internal compiler
>> error)
>> FAIL: gfortran.dg/module_commons_3.f90-g  (internal compiler
>> error)
>> FAIL: gfortran.dg/module_equivalence_1.f90-g  (internal compiler
>> error)
>> FAIL: gfortran.dg/use_11.f90  -g  (internal compiler
>> error)
>> FAIL: gfortran.dg/use_only_1.f90  -g  (internal compiler
>> error)
>> FAIL: gfortran.dg/widechar_5.f90  -g  (internal compiler
>> error)
>>
>> FAIL: libgomp.fortran/udr15.f90   -g  (internal compiler
>> error)
>>
>> are giving an ICE with -g of the kind
>>
>> internal compiler error: in dwarf2out_imported_module_or_decl, at
>> dwarf2out.c:24070
>>
>> corresponding to
>>
>>   gcc_assert (scope_die->die_child);
>
>
> So this is an oversight I did: the check I removed was actually useful for
> one thing: not emitting DW_TAG_imported_module DIEs in strict DWARFv2.
> DW_TAG_imported_declaration ones are always fine, though, so what I should
> do is to move the check, not remove it.
>
>> The Ada test gnat.dg/debug7.adb is also failing with
>>
>> FAIL: gnat.dg/debug7.adb (test for excess errors)
>> Excess errors:
>> gnat1: incorrect object file extension
>
>
> It seems it’s a bad interaction between dg-options "-cargs […]" and the
> testsuite framework. Can be fixed adding “-margs” at the end.
>
> Here is an updated patch, fixing all the issues Dominique reported.
> Bootstrapped and regtested on x86_64-linux. I also tested on
> x86_64-apple-darwin14.5.0 that the above errors are gone.
>
> --
> Pierre-Marie de Rodat

PING Re: [PATCH] PR68212, Correct frequencies/counts when unrolling

[Pat Haugen]

Ping for the following patch 
https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01363.html

-Pat

Re: [PATCH] add uClibc target hook (PR bootstrap/77819)

[Martin Sebor]

On 10/04/2016 08:54 AM, Bernd Schmidt wrote:

On 10/04/2016 04:34 PM, Martin Sebor wrote:


I copied the conditional from config/linux.h but I admit I don't
fully understand when the macro is defined.


AFAICT it's done in config.gcc, for a limited set of targets.


Should I still remove it from targhooks.c?


That is compiled for all targets, not just for those which define the
macro, so yes.


Yes, the glibc and uclibc hooks are the same.  I don't know what
the convention is for these target hooks (i.e., whether they are
expected to be duplicated across targets even if they are the
same to reduce the risk of breaking one target as a result of
changing another, or whether duplication should be avoided even
at this risk).  From your comment it sounds like it should be
the latter and I'm okay with that.


There's arguments for both. In this particular case I don't see a strong
reason not to have a general hook available.


Sounds good.  Attached is an updated patch reflecting these changes.
Restested by building the powerpc64-linux and tic6x-uclinux cross
toolchains.  (Sharing the Glibc and uClibc implementation of the
target hook and defining it in targhooks.c also obviates the patch
I sent in for bug 77837 last night so it seems like a win-win.)

Martin
PR bootstrap/77819 - undefined reference to gnu_libc_printf_pointer_format with uClibc

gcc/ChangeLog:

	PR bootstrap/77819
	* config/linux.h (TARGET_PRINTF_POINTER_FORMAT): Define macro.
	* config/linux.c (gnu_libc_printf_pointer_format): Remove.
	* targhooks.c [DEFAULT_LIBC == LIBC_UCLIBC) && SINGLE_LIBC]
	(default_printf_pointer_format): Define function.
	* targhooks.c (linux_printf_pointer_format): Define new function.
	* targhooks.h (linux_printf_pointer_format): Declare.
	(gnu_libc_printf_pointer_format): Remove declaration.

diff --git a/gcc/config/linux.c b/gcc/config/linux.c
index 9aac38b..a393d3b 100644
--- a/gcc/config/linux.c
+++ b/gcc/config/linux.c
@@ -24,9 +24,6 @@ along with GCC; see the file COPYING3.  If not see
 #include "tree.h"
 #include "linux-protos.h"
 
-#undef TARGET_PRINTF_POINTER_FORMAT
-#define TARGET_PRINTF_POINTER_FORMAT gnu_libc_printf_pointer_format
-
 bool
 linux_libc_has_function (enum function_class fn_class)
 {
@@ -40,16 +37,3 @@ linux_libc_has_function (enum function_class fn_class)
 
   return false;
 }
-
-/* Glibc formats pointers as if by "%zx" except for the null pointer
-   which outputs "(nil)".  It ignores the pound ('#') format flag but
-   interprets the space and plus flags the same as in the integer
-   directive.  */
-
-const char*
-gnu_libc_printf_pointer_format (tree arg, const char **flags)
-{
-  *flags = " +";
-
-  return arg && integer_zerop (arg) ? "(nil)" : "%#zx";
-}
diff --git a/gcc/config/linux.h b/gcc/config/linux.h
index 3ff005b..7211da2 100644
--- a/gcc/config/linux.h
+++ b/gcc/config/linux.h
@@ -209,6 +209,7 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
 
 #endif
 
-/* The format string to which "%p" corresponds.  */
+/* The format string to which "%p" corresponds (same in Glibc and
+   uClibc.  */
 #undef TARGET_PRINTF_POINTER_FORMAT
-#define TARGET_PRINTF_POINTER_FORMAT gnu_libc_printf_pointer_format
+#define TARGET_PRINTF_POINTER_FORMAT linux_printf_pointer_format
diff --git a/gcc/targhooks.c b/gcc/targhooks.c
index d75650f..c7977be 100644
--- a/gcc/targhooks.c
+++ b/gcc/targhooks.c
@@ -1523,6 +1523,22 @@ default_printf_pointer_format (tree, const char **flags)
   return "%zx";
 }
 
+/* For Glibc and uClibc targets also define the hook here because
+   otherwise it would have to be duplicated in each target's .c file
+   (such as in bfin/bfin.c and c6x/c6x.c, etc.)
+   Glibc and uClibc format pointers as if by "%zx" except for the null
+   pointer which outputs "(nil)".  It ignores the pound ('#') format
+   flag but interprets the space and plus flags the same as in the integer
+   directive.  */
+
+const char*
+linux_printf_pointer_format (tree arg, const char **flags)
+{
+  *flags = " +";
+
+  return arg && integer_zerop (arg) ? "(nil)" : "%#zx";
+}
+
 tree
 default_builtin_tm_load_store (tree ARG_UNUSED (type))
 {
diff --git a/gcc/targhooks.h b/gcc/targhooks.h
index 3356f0a..afb1c00 100644
--- a/gcc/targhooks.h
+++ b/gcc/targhooks.h
@@ -192,7 +192,7 @@ extern bool no_c99_libc_has_function (enum function_class);
 extern bool gnu_libc_has_function (enum function_class);
 
 extern const char* default_printf_pointer_format (tree, const char **);
-extern const char* gnu_libc_printf_pointer_format (tree, const char **);
+extern const char* linux_printf_pointer_format (tree, const char **);
 extern const char* solaris_printf_pointer_format (tree, const char **);
 
 extern tree default_builtin_tm_load_store (tree);

PING Re: [PATCH] Don't peel extra copy of loop in unroller for loops with exit at end

[Pat Haugen]

Ping for the following patch 
https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01612.html

-Pat

C++ PATCH for C++17 class template placeholders

[Jason Merrill]

C++17 adds the ability to omit the template arguments for a class
template when declaring a variable with an initializer, much like auto
but supporting a wider variety of initialization.  This is intended to
replace functions like make_tuple.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit beb368fa92a6eb8b55809ab442f59e2fca071cb7
Author: Jason Merrill 
Date:   Tue Oct 4 16:03:17 2016 -0400

Implement P0091R2, Template argument deduction for class templates.

* parser.c (cp_parser_simple_type_specifier): Parse class placeholder.
Use the location of the beginning of the type-specifier.
(cp_parser_init_declarator): Parse deduction guide.
(cp_parser_diagnose_invalid_type_name): Mention class deduction.
(cp_parser_type_id_1): Don't accept class placeholder as template arg.
* cp-tree.h (CLASS_PLACEHOLDER_TEMPLATE): New.
* decl.c (grokdeclarator): Check for uninitialized auto here.
(start_decl_1): Not here.
(cp_finish_decl): Or here.  Don't collapse a list when doing
class deduction.
(grokfndecl): Check deduction guide scope and body.
* error.c (dump_decl, dump_function_decl, dump_function_name):
Handle deduction guides.
* pt.c (make_template_placeholder, do_class_deduction): New.
(build_deduction_guide, rewrite_template_parm): New.
(dguide_name, dguide_name_p, deduction_guide_p): New.
(do_auto_deduction): Call do_class_deduction.
(splice_late_return_type, is_auto): Handle class placeholders.
(template_parms_level_to_args): Split from template_parms_to_args.
(tsubst_template_parms_level): Split from tsubst_template_parms.
* typeck2.c (build_functional_cast): Handle class placeholder.

diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 85702c5..3fbe1d9 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -1199,6 +1199,7 @@ extern GTY(()) tree cp_global_trees[CPTI_MAX];
 #define vptr_identifier
cp_global_trees[CPTI_VPTR_IDENTIFIER]
 /* The name of the std namespace.  */
 #define std_identifier cp_global_trees[CPTI_STD_IDENTIFIER]
+/* The name of a C++17 deduction guide.  */
 #define lang_name_ccp_global_trees[CPTI_LANG_NAME_C]
 #define lang_name_cplusplus
cp_global_trees[CPTI_LANG_NAME_CPLUSPLUS]
 
@@ -5104,6 +5105,10 @@ enum overload_flags { NO_SPECIAL = 0, DTOR_FLAG, 
TYPENAME_FLAG };
 #define TEMPLATE_TYPE_PARAMETER_PACK(NODE) \
   (TEMPLATE_PARM_PARAMETER_PACK (TEMPLATE_TYPE_PARM_INDEX (NODE)))
 
+/* For a C++17 class deduction placeholder, the template it represents.  */
+#define CLASS_PLACEHOLDER_TEMPLATE(NODE) \
+  (DECL_INITIAL (TYPE_NAME (TEMPLATE_TYPE_PARM_CHECK (NODE
+
 /* Contexts in which auto deduction occurs. These flags are
used to control diagnostics in do_auto_deduction.  */
 
@@ -6027,6 +6032,7 @@ extern int num_template_headers_for_class (tree);
 extern void check_template_variable(tree);
 extern tree make_auto  (void);
 extern tree make_decltype_auto (void);
+extern tree make_template_placeholder  (tree);
 extern tree do_auto_deduction   (tree, tree, tree);
 extern tree do_auto_deduction   (tree, tree, tree,
  tsubst_flags_t,
@@ -6158,6 +6164,9 @@ extern void register_local_specialization   (tree, 
tree);
 extern tree retrieve_local_specialization   (tree);
 extern tree extract_fnparm_pack (tree, tree *);
 extern tree template_parm_to_arg(tree);
+extern tree dguide_name(tree);
+extern bool dguide_name_p  (tree);
+extern bool deduction_guide_p  (tree);
 
 /* in repo.c */
 extern void init_repo  (void);
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index c8f7666..6646062 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -5140,7 +5140,7 @@ start_decl_1 (tree decl, bool initialized)
   else if (aggregate_definition_p && !complete_p)
 {
   if (type_uses_auto (type))
-   error ("declaration of %q#D has no initializer", decl);
+   gcc_unreachable ();
   else
error ("aggregate %q#D has incomplete type and cannot be defined",
   decl);
@@ -6695,12 +6695,11 @@ cp_finish_decl (tree decl, tree init, bool 
init_const_expr_p,
  return;
}
 
- error ("declaration of %q#D has no initializer", decl);
- TREE_TYPE (decl) = error_mark_node;
- return;
+ gcc_unreachable ();
}
   d_init = init;
-  if (TREE_CODE (d_init) == TREE_LIST)
+  if (TREE_CODE (d_init) == TREE_LIST
+ && !CLASS_PLACEHOLDER_TEMPLATE (auto_node))
d_init = build_x_compound_expr_from_list (d_init, ELK_INIT,
  tf_warning_or_error);
   d_init = resolve_nondeduced_context (d_init, tf_warning_or_error);
@@ -8182,7 +8181,27 @@ 

C++ PATCH for c++/77775 (wrong folding of PMF comparison)

[Jason Merrill]

The RECORD_TYPE for a PMF does not have variants in the usual way;
rather, a variant PMF will have a distinct RECORD_TYPE where the pfn
field has a variant type.  As a result, if we cast a constant PMF to a
variant type, we will end up looking up a different field than we
initialized.  Deal with this by using field names for PMFs.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit f412d0f7919501f9cff962858975cfa48cd4d274
Author: Jason Merrill 
Date:   Fri Sep 30 17:00:11 2016 -0400

PR c++/5 - misoptimization of PMF comparison

* constexpr.c (cxx_eval_component_reference): Use name matching
for PMFs.

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index 2db13d2..4acbb26 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -2315,9 +2315,13 @@ cxx_eval_component_reference (const constexpr_ctx *ctx, 
tree t,
 }
   if (*non_constant_p)
 return t;
+  bool pmf = TYPE_PTRMEMFUNC_P (TREE_TYPE (whole));
   FOR_EACH_CONSTRUCTOR_ELT (CONSTRUCTOR_ELTS (whole), i, field, value)
 {
-  if (field == part)
+  /* Use name match for PMF fields, as a variant will have a
+different FIELD_DECL with a different type.  */
+  if (pmf ? DECL_NAME (field) == DECL_NAME (part)
+ : field == part)
{
  if (value)
return value;
@@ -2342,6 +2346,8 @@ cxx_eval_component_reference (const constexpr_ctx *ctx, 
tree t,
   if (is_really_empty_class (TREE_TYPE (t)))
 return build_constructor (TREE_TYPE (t), NULL);
 
+  gcc_assert (DECL_CONTEXT (part) == TYPE_MAIN_VARIANT (TREE_TYPE (whole)));
+
   if (CONSTRUCTOR_NO_IMPLICIT_ZERO (whole))
 {
   /* 'whole' is part of the aggregate initializer we're currently
diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-pmf1.C 
b/gcc/testsuite/g++.dg/cpp0x/constexpr-pmf1.C
new file mode 100644
index 000..b6a7935
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/constexpr-pmf1.C
@@ -0,0 +1,17 @@
+// PR c++/5
+// { dg-options -fdump-tree-gimple }
+// { dg-final { scan-tree-dump "== viewAdded" "gimple" { target c++11 } } }
+
+namespace Sublime {
+struct View;
+struct AreaIndex;
+struct Area {
+  void qt_static_metacall();
+  void viewAdded(AreaIndex *, View *);
+};
+}
+void Sublime::Area::qt_static_metacall() {
+  typedef void (Area::*_t)(AreaIndex *, View *);
+  if (*reinterpret_cast<_t *>(1) == _t(&Area::viewAdded))
+__builtin_abort();
+}

Patch, Split powerpc -mfloat128 into 2 parts

[Michael Meissner]

In working on the IEEE 128-bit floating point support, I've run into situations
where it would be to have the basic KFmode type available under Linux, but not
allow the __float128 and _Float128 keywords to be used until the library work
is done.  But the library functions might want to use some IEEE 128-bit support
in order to implement the support, but you might need to add -mfloat128 to the
builds.

Originally, I thought no problem, just use a target attribute to enable the
IEEE 128-bit floating point support, but it turns out if the -mfloat128 option
is not set at compilation type, the appropriate types are not created and the
target support won't work to set it later (PR 70589).

Another thing that I've seen occasionally is whether internally __ibm128 is the
same as long double or a sepate type.  Right now, __ibm128 is a separate type.
When we eventually switch to long double being IEEE 128, we might have the same
logical problem with __float128.

This patch attempts to fix both of these problems.  It splits -mfloat128 into
two switches, -mfloat128-type that does all of the underylying type stuff, and
the current -mfloat128 which enables the keywords.  On 64-bit powerpc Linux
systems, the compiler will enable -mfloat128-type by default for VSX targets
(both 32/64-bit on big endian, and 64-bit on little endian).  On other systems
like AIX, it will not enable -mfloat128-type by default.

It also changes __ibm128/__float128, and only registers the keywords if the
long double type is not IBM extended double or IEEE 128-bit floating point
respectively.  If the long double type matches one of those types, instead it
will issue a #define {__ibm128,__float128} long double, and the user will
always pick up the long double type.

I have built these patches on a little endian 64-bit power8 system and a big
endian power7 system that supports both 32-bit/64-bit targets.  Note, due to
bug 77847, I had to build the big endian compiler so that the default code
generation was power5 instead of power7.  There were no regressions, is it ok
to install this pach in the trunk?

[gcc]
2016-10-03  Michael Meissner  

* config/rs6000/rs6000-c.c (rs6000_cpu_cpp_builtins): Split
-mfloat128 into -mfloat128-type that enables the IEEE 128-bit
floating point type infrastructre, and -mfloat128 that enables the
keyword.  Define __FLOAT128__ if -mfloat128, and __FLOAT128_TYPE__
if -mfloat128-type.  Define __ibm128 or __float128 if that type is
available, and it matches the long double type.
* config/rs6000/rs6000.c (rs6000_debug_reg_global): Print whether
the IEEE 128-bit floating point type infrastructure should
automatically be enabled.
(rs6000_init_hard_regno_mode_ok): Switch to use -mfloat128-type
instead of -mfloat128 to enable KFmode.
(rs6000_option_override_internal): Split the option -mfloat128
into -mfloat128-type and -mfloat128.  On Linux PowerPC 64-bit
systems, automatically set -mfloat128-type, but don't enable it on
other operating systems.  Move setting the long double size and
IEEE quad support before the IEEE 128-bit floating point changes.
(rs6000_init_builtins): Do not create a unique type for __ibm128
if long double is IBM extended double, instead rely on __ibm128
being defined as 'long double'.  For IEEE 128-bit floating point,
if __float128/_Float128 are not enabled, create a unique type for
IEEE 128-bit floating point.
(rs6000_init_libfuncs): Use -mfloat128-type instead of
-mfloat128 for tests about the types, but keep tests for
-mfloat128 to enable the keyword support.
(rs6000_complex_function_value): Likewise.
(rs6000_scalar_mode_supported_p): Likewise.
(rs6000_floatn_mode): Likewise.
(rs6000_c_mode_for_suffix): Likewise.
(rs6000_opt_masks): Add -mfloat128-type.
* config/rs6000/rs6000-cpus.def (POWERPC_MASKS): Add support for
-mfloat128-type being split from -mfloat128.  Add
-mfloat128-hardware, which was missing.
* config/rs6000/rs6000.opt (-mfloat128): Split -mfloat128 into
-mfloat128 and -mfloat128-type:
(-mfloat128-type): Likewise.
* config/rs6000/linux64.h (TARGET_FLOAT128_ENABLE_TYPE): Define so
that 64-bit Linux systems with enable -mfloat128-type by default
on VSX systems.
* config/rs6000/rs6000.h (TARGET_FLOAT128_ENABLE_TYPE): Likewise.
(FLOAT128_VECTOR_P): Switch IEEE 128-bit floating points to use
-mfloat128-type instead of -mfloat128.
(FLOAT128_2REG_P): Likewise.
(MASK_FLOAT128_TYPE): Likewise.
(ALTIVEC_ARG_MAX_RETURN): Likewise.
(RS6000_BTM_FLOAT128): Likewise.
(TARGET_FLOAT128): Poison old identifiers.
(OPTION_MASK_FLOAT128): Likewise.
(MASK_FLOAT128): Likewise.
* config/rs6000/rs6000.md (FP): Likewise.
(F

Re: Patch, Split powerpc -mfloat128 into 2 parts

[Joseph Myers]

On Tue, 4 Oct 2016, Michael Meissner wrote:

> It also changes __ibm128/__float128, and only registers the keywords if the
> long double type is not IBM extended double or IEEE 128-bit floating point
> respectively.  If the long double type matches one of those types, instead it
> will issue a #define {__ibm128,__float128} long double, and the user will
> always pick up the long double type.

_Float128, when it exists, is always a distinct type from long double even 
if they are ABI-compatible.  So if they are ABI-compatible, you would have 
__float128 the same as long double but different from _Float128, which 
seems confusing - are you doing it that way because of the lack of 
_Float128 in C++ means a simple define to _Float128 could only be used for 
C?

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

Re: [PATCH v2] add -fprolog-pad=N option to c-family

[Maxim Kuvyrkov]

> On Sep 29, 2016, at 11:14 AM, Torsten Duwe  wrote:
> 
> In case anybody missed it, the Linux kernel side to make use
> of this has also been finished meanwhile. Of course it can not
> be accepted without compiler support; and this feature patch
> is much more versatile than just Linux kernel live patching
> on a single architecture.

Hi Torsten,

Good job moving -fprolog-pad= forward!  I've reviewed your patch, and it looks 
OK with the minor comments inline.  I've CC'ed Richard E. since you will need a 
global maintainer approval for this change.

Ideally, I want to improve support for -fprolog-pad=N and 
__attribute__((prolog_pad(N))) to provide functionality to also output pad 
before the function label to address use-cases for s390, sparc, etc (what Jose 
E. Marchesi was referring to).  I.e., -fprolog-pad= option would accept both 
-fprolog-pad=N and -fprolog-pad=M,N forms -- issue M nops before function label 
and N nops after function label.  Similarly for 
__attribute__((prolog_pad(N,M))).  I (or you :-) ) can attempt to implement 
this functionality before stage1 closes, but it should not block this initial 
patch.

Comments on the patch below.

> 
> Changes since the previous version
> (which in turn was based on Maxim's suggestion):
> 
> * Document the feature in *.texi
> 
> * Automatically disable IPA-RA, like normal profiling does.
>  You never know in advance what the code patched in at run time will do.
>  Any optimisation here is potentially wrong.
> 
> * record a prolog_nop_pad_size value specified on the command line
>  in each function's attributes, so that it survives an LTO pipe.
> 
> Signed-off-by: Torsten Duwe 
> 
> diff --git a/gcc/attribs.c b/gcc/attribs.c
> index 16996e9..a5cf2aa 100644
> --- a/gcc/attribs.c
> +++ b/gcc/attribs.c
> @@ -365,6 +365,21 @@ decl_attributes (tree *node, tree attributes, int flags)
>   if (!attributes_initialized)
> init_attributes ();
> 
> +  /* If we're building NOP pads because of a command line arg, note the size
> + for LTO builds, unless the attribute has already been overridden. */
> +  if (TREE_CODE (*node) == FUNCTION_DECL && prolog_nop_pad_size > 0)
> +{
> +  tree pp_attr = lookup_attribute ("prolog_pad", attributes);
> +  if (! pp_attr )

Coding style: should be "if (!pp_attr)"

Also, this clause implies that attribute takes precedence over command-line 
option, and the two are not attempted to be merged.  I agree that this is a 
reasonable approach, but consider adding a warning if prolog_nop_pad_size is 
bigger than the value of the existing attribute.  Something like ...

> + {
> +   tree pp_size = build_int_cstu (integer_type_node, 
> prolog_nop_pad_size);
> +
> +   attributes = tree_cons (get_identifier ("prolog_pad"),
> +   tree_cons ( NULL_TREE, pp_size, NULL_TREE),
> +   attributes);
> + }

... here:

else if (ATTRIBUTE_VALUE (pp_attr) > prolog_nop_pad_size)
  warning (OPT_Wattributes, "Prologue pad might be truncated: ", 
node);

Also, I suggest to issue a warning here if ipa-ra is not disabled, and adding a 
comment to the documentation about issues with interoperability of 
-fprolog-pad/__attribute__((prolog_pad)) and IPA RA..

> +}
> +
>   /* If this is a function and the user used #pragma GCC optimize, add the
>  options to the attribute((optimize(...))) list.  */
>   if (TREE_CODE (*node) == FUNCTION_DECL && current_optimize_pragma)
> diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
> index f2846bb..278a99e 100644
> --- a/gcc/c-family/c-common.c
> +++ b/gcc/c-family/c-common.c
> @@ -393,6 +393,7 @@ static tree handle_designated_init_attribute (tree *, 
> tree, tree, int, bool *);
> static tree handle_bnd_variable_size_attribute (tree *, tree, tree, int, bool 
> *);
> static tree handle_bnd_legacy (tree *, tree, tree, int, bool *);
> static tree handle_bnd_instrument (tree *, tree, tree, int, bool *);
> +static tree handle_prolog_pad_attribute (tree *, tree, tree, int, bool *);
> 
> static void check_nonnull_arg (void *, tree, unsigned HOST_WIDE_INT);
> static bool nonnull_check_p (tree, unsigned HOST_WIDE_INT);
> @@ -834,6 +835,8 @@ const struct attribute_spec c_common_attribute_table[] =
> handle_bnd_legacy, false },
>   { "bnd_instrument", 0, 0, true, false, false,
> handle_bnd_instrument, false },
> +  { "prolog_pad",  1, 1, false, true, true,
> +   handle_prolog_pad_attribute, false },

The patch also needs to document new attribute in doc/extend.texi

>   { NULL, 0, 0, false, false, false, NULL, false }
> };
> 
> @@ -9687,6 +9690,14 @@ handle_designated_init_attribute (tree *node, tree 
> name, tree, int,
>   return NULL_TREE;
> }
> 
> +static tree
> +handle_prolog_pad_attribute (tree *, tree, tree, int,
> +  bool *)
> +{
> +  /* Nothing to be done here. */
> +  return NULL_

Re: Patch, Split powerpc -mfloat128 into 2 parts

[Michael Meissner]

On Tue, Oct 04, 2016 at 09:42:21PM +, Joseph Myers wrote:
> On Tue, 4 Oct 2016, Michael Meissner wrote:
> 
> > It also changes __ibm128/__float128, and only registers the keywords if the
> > long double type is not IBM extended double or IEEE 128-bit floating point
> > respectively.  If the long double type matches one of those types, instead 
> > it
> > will issue a #define {__ibm128,__float128} long double, and the user will
> > always pick up the long double type.
> 
> _Float128, when it exists, is always a distinct type from long double even 
> if they are ABI-compatible.  So if they are ABI-compatible, you would have 
> __float128 the same as long double but different from _Float128, which 
> seems confusing - are you doing it that way because of the lack of 
> _Float128 in C++ means a simple define to _Float128 could only be used for 
> C?

Right now, if -mfloat128 is used, __float128 and _Float128 use the same type.
If -mfloat128 is not used (but -mfloat128-type is), it creates a unique type.
At this point, I was mainly worrying about __ibm128 being the same as long
double.  I am open to suggestions on what __float128 should be somewhere down
the road (gcc 8 or 9 time frame) when the switch becomes an option.

-- 
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

Re: [PATCH] - improve sprintf buffer overflow detection (middle-end/49905)

[Martin Sebor]

as it happens, I'd already started bootstraps with your patch before
your mail arrived :-)


Thanks for your help getting to the bottom of this!



We're left with

FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c (test for excess errors)
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-4.c (test for excess errors)

for 32 bit and

FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-4.c (test for excess errors)

for 64 bit on both i386-pc-solaris2.12 and sparc-sun-solaris2.12.

In the 32-bit builtin-sprintf-warn-1.c case, there are many instances of

Excess errors:
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c:224:3:
 warning: format '%lc' expects argument of type 'wint_t', but argument 5 has 
type 'int' [-Wformat=]


I've built the sparc-sun-solaris2.12 toolchain and reproduced these
warnings.  They are vestiges of those I saw and some of which I fixed
before.  The problem is that %lc expects a wint_t argument which on
this target is an alias for long in but the argument of 0 has type
int.  The warning is coming out of the -Wformat checker which doesn't
seem to care that int and long have the same size.  I've committed
r240758 that should fix the remaining warnings of this kind but long
term I think GCC should change to avoid warning in this case (Clang
doesn't).



while the second is

Excess errors:
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-4.c:15:23:
 warning: writing a terminating nul past the end of the destination 
[-Wformat-length=]/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-4.c:30:21:
 warning: writing format character '4' at offset 3 past the end of the 
destination [-Wformat-length=]
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-4.c:46:21:
 warning: writing format character '4' at offset 3 past the end of the 
destination [-Wformat-length=]
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-4.c:61:25:
 warning: writing a terminating nul past the end of the destination 
[-Wformat-length=]
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-4.c:74:22:
 warning: '%-s' directive writing 4 bytes into a region of size 1 
[-Wformat-length=]

I've no idea yet why in the first error message two different messages
are joined into one line.  Probably something with DejaGnu mangling the
output...


I've reproduced this as well and it took me a while to see the
problem.  It turns out that the target specifier I used in the
test (*-*-*-*) happened to match my native target
x86_64-pc-linux-gnu but not sparc-sun-solaris2.12.  Let me fix
that in the next patch.  Hopefully with that all the remaining
failures should clear up.

Thanks again for your help and patience!

Martin

Re: [PATCH] backport dejagnu relative numbers to 6-branch?

[Martin Sebor]

On 10/04/2016 01:01 PM, Mike Stump wrote:

On Oct 4, 2016, at 11:05 AM, Martin Sebor  wrote:


While backporting a patch for 77804 to the gcc-6-branch I noticed
that the DejaGnu relative number patch below is not available
there (the new test failed).  Is it worth backporting it to it?

 https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01617.html


Backport Ok.



Thank you.  I saw no unexpected failures in a full bootstrap and
regression test run on pwerpc64le so I committed Jakub's change
in r240762.

Martin

GCC patch committed: fix -fsplit-stack alloca with -mno-accumulate-outgoing-args

[Ian Lance Taylor]

Than McIntosh encountered a bug on 32-bit x86 with code that calls
alloca when using -fsplit-stack when -mno-accumulate-outgoing-args is
in effect.  When alloca is called after a function call, the arguments
are left on the stack, which can cause the stack to become misaligned.
The problem is simply that the stack-split alloca support is
implemented before calling do_pending_stack_adjust.  This patch fixes
the problem and adds a test case.  Bootstrapped and ran all tests on
x86_64-pc-linux-gnu.  Committed to mainline.

Ian

2016-10-04  Ian Lance Taylor  

* explow.c (allocate_dynamic_stack_space): Call
do_pending_stack_adjust before handling flag_split_stack.

2016-10-04  Ian Lance Taylor  

* gcc.dg/split-7.c: New test.
Index: gcc/explow.c
===
--- gcc/explow.c(revision 240755)
+++ gcc/explow.c(working copy)
@@ -1357,6 +1357,8 @@ allocate_dynamic_stack_space (rtx size,
current_function_has_unbounded_dynamic_stack_size = 1;
 }
 
+  do_pending_stack_adjust ();
+
   final_label = NULL;
   final_target = NULL_RTX;
 
@@ -1414,8 +1416,6 @@ allocate_dynamic_stack_space (rtx size,
   emit_label (available_label);
 }
 
-  do_pending_stack_adjust ();
-
  /* We ought to be called always on the toplevel and stack ought to be aligned
 properly.  */
   gcc_assert (!(stack_pointer_delta
Index: gcc/testsuite/gcc.dg/split-7.c
===
--- gcc/testsuite/gcc.dg/split-7.c  (revision 0)
+++ gcc/testsuite/gcc.dg/split-7.c  (working copy)
@@ -0,0 +1,55 @@
+/* { dg-do run } */
+/* { dg-require-effective-target split_stack } */
+/* { dg-options "-fsplit-stack -O2" } */
+/* { dg-options "-fsplit-stack -O2 -mno-accumulate-outgoing-args" { target { { 
i?86-*-* x86_64-*-* } && ia32 } } } */
+
+/* A case that used to fail on 32-bit x86 when optimizing and not
+   using -maccumulate-args.  The stack adjustment of the alloca got
+   mixed up with the arguments pushed on the stack to the function
+   before the call of alloca.  */
+
+#include 
+
+typedef struct { const char* s; int l; } s;
+
+typedef unsigned long long align16 __attribute__ ((aligned(16)));
+
+s gobats (const void *, int) __attribute__ ((noinline));
+
+s
+gobats (const void* p __attribute__ ((unused)),
+   int l __attribute__ ((unused)))
+{
+  s v;
+  v.s = 0;
+  v.l = 0;
+  return v;
+}
+
+void check_aligned (void *p) __attribute__ ((noinline));
+
+void
+check_aligned (void *p)
+{
+  if (((__SIZE_TYPE__) p & 0xf) != 0)
+abort ();
+}
+
+void gap (void *) __attribute__ ((noinline));
+
+void gap (void *p)
+{
+  align16 a;
+  check_aligned (&a);
+}
+
+int
+main (int argc, char **argv)
+{
+  s *space;
+  gobats(0, 16);
+  space = (s *) alloca(sizeof(s) + 1);
+  *space = (s){0, 16};
+  gap(space);
+  return 0;
+}

Re: [PATCH] - improve sprintf buffer overflow detection (middle-end/49905)

[Joseph Myers]

On Tue, 4 Oct 2016, Martin Sebor wrote:

> I've built the sparc-sun-solaris2.12 toolchain and reproduced these
> warnings.  They are vestiges of those I saw and some of which I fixed
> before.  The problem is that %lc expects a wint_t argument which on
> this target is an alias for long in but the argument of 0 has type
> int.  The warning is coming out of the -Wformat checker which doesn't
> seem to care that int and long have the same size.  I've committed
> r240758 that should fix the remaining warnings of this kind but long
> term I think GCC should change to avoid warning in this case (Clang
> doesn't).

Well, typically cases where one of long and int is passed and the other is 
expected, but they have the same size, are bugs waiting to happen when the 
code is built on a 64-bit system.  That is, they *should* warn.

There have been arguments that we should go further and warn for e.g. %zu 
with a type that happens to be the same as size_t but doesn't use the 
size_t typedef (or sizeof etc.), %td for something that happens to be the 
same as ptrdiff_t but doesn't use the typedef (or pointer difference 
etc.), etc. - which would get many similar cases of bugs waiting to happen 
on a different system, but is also tricker because you need to decide 
whether a given type is logically size_t etc. or not - code could validly 
use autoconf to identify the underlying type, or use __SIZE_TYPE__, or use 
an expression mixing size_t with other types, or in the case of %j* 
(intmax_t) use the INTMAX_C macro to construct constants.  That probably 
*would* need an option to disable just those format warnings (whereas I 
don't see the need for such an option for the case of mixing int and 
long).

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

Re: [PATCH] - improve sprintf buffer overflow detection (middle-end/49905)

[Martin Sebor]

On 10/04/2016 06:21 PM, Joseph Myers wrote:

On Tue, 4 Oct 2016, Martin Sebor wrote:


I've built the sparc-sun-solaris2.12 toolchain and reproduced these
warnings.  They are vestiges of those I saw and some of which I fixed
before.  The problem is that %lc expects a wint_t argument which on
this target is an alias for long in but the argument of 0 has type
int.  The warning is coming out of the -Wformat checker which doesn't
seem to care that int and long have the same size.  I've committed
r240758 that should fix the remaining warnings of this kind but long
term I think GCC should change to avoid warning in this case (Clang
doesn't).


Well, typically cases where one of long and int is passed and the other is
expected, but they have the same size, are bugs waiting to happen when the
code is built on a 64-bit system.  That is, they *should* warn.


Typically, yes.  In the case of wchar_t (or int) and wint_t I don't
think it's helpful.  Consider this case from my comment #5 on bug
72858.  I don't think there is any point in issuing a warning here.
On the majority of targets they either all are or promote to a type
of the same size, don't they?

$ cat t.c && gcc -S -Wall -m32 t.c
typedef __WCHAR_TYPE__ wchar_t;

void f (const wchar_t *ws)
{
  __builtin_printf ("%lc", *ws);
}
t.c: In function ‘f’:
t.c:5:24: warning: format ‘%lc’ expects argument of type ‘wint_t’, but 
argument 2 has type ‘wchar_t {aka const long int}’ [-Wformat=]

   __builtin_printf ("%lc", *ws);
  ~~^   ~~~
  %ld


There have been arguments that we should go further and warn for e.g. %zu
with a type that happens to be the same as size_t but doesn't use the
size_t typedef (or sizeof etc.), %td for something that happens to be the
same as ptrdiff_t but doesn't use the typedef (or pointer difference
etc.), etc. - which would get many similar cases of bugs waiting to happen
on a different system, but is also tricker because you need to decide
whether a given type is logically size_t etc. or not - code could validly
use autoconf to identify the underlying type, or use __SIZE_TYPE__, or use
an expression mixing size_t with other types, or in the case of %j*
(intmax_t) use the INTMAX_C macro to construct constants.  That probably
*would* need an option to disable just those format warnings (whereas I
don't see the need for such an option for the case of mixing int and
long).


I would view it useful if GCC warned on %zu with an argument that's
not size_t, and similarly for other directives and typedefs, for the
reason you mention.  But I don't think the same rationale applies
to warning on %lc with wchar_t or int arguments.

Martin

[gomp4] update tile clause lowering in fortran

[Cesar Philippidis]

Nathan noticed that the fortran FE wasn't lowering tiled loops in the
same format as the C/C++ FEs. The canonical format of tiled loops going
forward is that of omp/acc collapsed loops; tiled loops are lowered into
a collection of tightly nested for loops. While making this change, I
noticed that the fortran FE permitted acc loops to contain both tile and
collapse clauses. This patch also makes that an error like it is in C
and C++.

This patch has been applied to gomp-4_0-branch.

Cesar
2016-10-04  Cesar Philippidis  

	gcc/fortran/
	* openmp.c (resolve_omp_clauses): Error on directives
containing both tile and collapse clauses.
	* trans-openmp.c (gfc_trans_omp_do): Lower tiled loops like
collapsed loops.

	gcc/testsuite/
	* gfortran.dg/goacc/tile-1.f90: Update test coverage.
	* gfortran.dg/goacc/tile-lowering.f95: Likewise.

diff --git a/gcc/fortran/openmp.c b/gcc/fortran/openmp.c
index df489ba..e5eeb15 100644
--- a/gcc/fortran/openmp.c
+++ b/gcc/fortran/openmp.c
@@ -4092,6 +4092,8 @@ resolve_omp_clauses (gfc_code *code, gfc_omp_clauses *omp_clauses,
 if (omp_clauses->wait_list)
   for (el = omp_clauses->wait_list; el; el = el->next)
 	resolve_oacc_scalar_int_expr (el->expr, "WAIT");
+  if (omp_clauses->collapse && omp_clauses->tile_list)
+gfc_error ("Incompatible use of TILE and COLLAPSE at %L", &code->loc);
 }
 
 
diff --git a/gcc/fortran/trans-openmp.c b/gcc/fortran/trans-openmp.c
index 2c28a31..e0e1c8b 100644
--- a/gcc/fortran/trans-openmp.c
+++ b/gcc/fortran/trans-openmp.c
@@ -3354,6 +3354,16 @@ gfc_trans_omp_do (gfc_code *code, gfc_exec_op op, stmtblock_t *pblock,
   dovar_init *di;
   unsigned ix;
 
+  /* Both collapsed and tiled loops are lowered the same way.  In
+ OpenACC, those clauses are not compatible, so prioritize the tile
+ clause, if present.  */
+  if (clauses->tile_list)
+{
+  collapse = 0;
+  for (gfc_expr_list *el = clauses->tile_list; el; el = el->next)
+	collapse++;
+}
+
   if (collapse <= 0)
 collapse = 1;
 
diff --git a/gcc/testsuite/gfortran.dg/goacc/tile-1.f90 b/gcc/testsuite/gfortran.dg/goacc/tile-1.f90
index 967a7c3..17fd32c 100644
--- a/gcc/testsuite/gfortran.dg/goacc/tile-1.f90
+++ b/gcc/testsuite/gfortran.dg/goacc/tile-1.f90
@@ -79,6 +79,12 @@ subroutine parloop
  do j = 1, n
  end do
   end do
+
+  !$acc parallel loop tile(2, 3) collapse (2) ! { dg-error "Incompatible use" }
+  do i = 1, n
+ do j = 1, n
+ end do
+  end do
 end subroutine parloop
 
 subroutine par
@@ -153,6 +159,12 @@ subroutine par
   !$acc loop gang worker tile(*)
   do i = 1, n
   end do
+
+  !$acc loop tile(2, 3) collapse (2) ! { dg-error "Incompatible use" }
+  do i = 1, n
+ do j = 1, n
+ end do
+  end do
   !$acc end parallel
 end subroutine par
 
@@ -228,6 +240,12 @@ subroutine kern
   !$acc loop gang worker tile(*)
   do i = 1, n
   end do
+
+  !$acc loop tile(2, 3) collapse (2) ! { dg-error "Incompatible use" }
+  do i = 1, n
+ do j = 1, n
+ end do
+  end do
   !$acc end kernels
 end subroutine kern
 
@@ -312,4 +330,10 @@ subroutine kernsloop
  do j = 1, n
  end do
   end do
+
+  !$acc kernels loop tile(2, 3) collapse (2) ! { dg-error "Incompatible use" }
+  do i = 1, n
+ do j = 1, n
+ end do
+  end do
 end subroutine kernsloop
diff --git a/gcc/testsuite/gfortran.dg/goacc/tile-lowering.f95 b/gcc/testsuite/gfortran.dg/goacc/tile-lowering.f95
index b36cdc7..3774b38 100644
--- a/gcc/testsuite/gfortran.dg/goacc/tile-lowering.f95
+++ b/gcc/testsuite/gfortran.dg/goacc/tile-lowering.f95
@@ -82,4 +82,5 @@ end subroutine test
 ! { dg-final { scan-tree-dump-times "tile\\(0, 2, 3\\)" 1 "original" } }
 ! { dg-final { scan-tree-dump-times "tile\\(1, 0, 3\\)" 1 "original" } }
 ! { dg-final { scan-tree-dump-times "tile\\(1, 2, 0\\)" 1 "original" } }
+! { dg-final { scan-tree-dump-times "for \\(" 22 "original" } }
 

Re: C++ PATCH for C++17 class template placeholders

[Jason Merrill]

On Tue, Oct 4, 2016 at 4:42 PM, Jason Merrill  wrote:
> C++17 adds the ability to omit the template arguments for a class
> template when declaring a variable with an initializer, much like auto
> but supporting a wider variety of initialization.  This is intended to
> replace functions like make_tuple.
>
> Tested x86_64-pc-linux-gnu, applying to trunk.

A few tweaks...
commit 492ab670ad2c1ddc11c59bb77220c5a996b0f87a
Author: jason 
Date:   Wed Oct 5 01:24:38 2016 +

PR c++/77852 - class deduction from list-init

* pt.c (do_class_deduction): Handle list-initialization.
(do_auto_deduction): Call it sooner.
(build_deduction_guide): Use tsubst_arg_types.
(rewrite_template_parm): Don't copy_type.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@240765 
138bc75d-0d04-0410-961f-82ee72b054a4

diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
index 491c637..2fce793 100644
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -12612,6 +12612,18 @@ make_tree_vector_from_list (tree list)
   return ret;
 }
 
+/* Get a new tree vector of the values of a CONSTRUCTOR.  */
+
+vec *
+make_tree_vector_from_ctor (tree ctor)
+{
+  vec *ret = make_tree_vector ();
+  vec_safe_reserve (ret, CONSTRUCTOR_NELTS (ctor));
+  for (unsigned i = 0; i < CONSTRUCTOR_NELTS (ctor); ++i)
+ret->quick_push (CONSTRUCTOR_ELT (ctor, i)->value);
+  return ret;
+}
+
 /* Get a new tree vector which is a copy of an existing one.  */
 
 vec *
diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h
index c88619b..28aebec 100644
--- a/gcc/c-family/c-common.h
+++ b/gcc/c-family/c-common.h
@@ -,6 +,7 @@ extern vec *make_tree_vector (void);
 extern void release_tree_vector (vec *);
 extern vec *make_tree_vector_single (tree);
 extern vec *make_tree_vector_from_list (tree);
+extern vec *make_tree_vector_from_ctor (tree);
 extern vec *make_tree_vector_copy (const vec *);
 
 /* Used for communication between c_common_type_for_mode and
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index f923666..e6b1368 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -24178,7 +24178,7 @@ rewrite_template_parm (tree olddecl, unsigned index, 
unsigned level,
   if (TREE_CODE (olddecl) == TYPE_DECL
   || TREE_CODE (olddecl) == TEMPLATE_DECL)
 {
-  newtype = copy_type (TREE_TYPE (olddecl));
+  newtype = cxx_make_type (TREE_CODE (TREE_TYPE (olddecl)));
   TYPE_MAIN_VARIANT (newtype) = newtype;
 }
   else
@@ -24340,7 +24340,8 @@ build_deduction_guide (tree ctor, tree outer_args, 
tsubst_flags_t complain)
   /* Now we have a final set of template parms to substitute into the
 function signature.  */
   targs = template_parms_to_args (tparms);
-  fparms = tsubst (fparms, tsubst_args, complain, ctor);
+  fparms = tsubst_arg_types (fparms, tsubst_args, NULL_TREE,
+complain, ctor);
   fargs = tsubst (fargs, tsubst_args, complain, ctor);
   if (ci)
ci = tsubst_constraint_info (ci, tsubst_args, complain, ctor);
@@ -24376,6 +24377,8 @@ do_class_deduction (tree tmpl, tree init, 
tsubst_flags_t complain)
   vec *args;
   if (TREE_CODE (init) == TREE_LIST)
 args = make_tree_vector_from_list (init);
+  else if (BRACE_ENCLOSED_INITIALIZER_P (init))
+args = make_tree_vector_from_ctor (init);
   else
 args = make_tree_vector_single (init);
 
@@ -24465,6 +24468,10 @@ do_auto_deduction (tree type, tree init, tree 
auto_node,
from ahead of time isn't worth the trouble.  */
 return type;
 
+  if (tree tmpl = CLASS_PLACEHOLDER_TEMPLATE (auto_node))
+/* C++17 class template argument deduction.  */
+return do_class_deduction (tmpl, init, complain);
+
   /* [dcl.spec.auto]: Obtain P from T by replacing the occurrences of auto
  with either a new invented type template parameter U or, if the
  initializer is a braced-init-list (8.5.4), with
@@ -24510,9 +24517,6 @@ do_auto_deduction (tree type, tree init, tree auto_node,
  return error_mark_node;
}
 }
-  else if (tree tmpl = CLASS_PLACEHOLDER_TEMPLATE (auto_node))
-/* C++17 class template argument deduction.  */
-return do_class_deduction (tmpl, init, complain);
   else
 {
   tree parms = build_tree_list (NULL_TREE, type);
diff --git a/gcc/testsuite/g++.dg/cpp1z/class-deduction14.C 
b/gcc/testsuite/g++.dg/cpp1z/class-deduction14.C
new file mode 100644
index 000..1c7e34e
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1z/class-deduction14.C
@@ -0,0 +1,15 @@
+// { dg-options -std=c++1z }
+
+#include 
+
+template struct container {
+  container(T t) {}
+  template container(Iter beg, Iter end);
+};
+template
+container(Iter b, Iter e)  // { dg-message "iterator_traits.int" }
+  -> container::value_type>;
+std::vector v = { /* ... */ };
+container c(7);  // OK, deduces int for T
+auto d = container(v.begin(), v.end()); // OK, deduces double for T
+container e{5, 6};  

[Patch, libgfortran] Inquire internal unit within child dtio procedure

[JerryD]

Committed as trivial. Reported on c.l.f  Regression tested on x86-64.

Regards,

Jerry

2016-10-04  Jerry DeLisle  

io/inquire.c (inquire_via_unit): Add check for internal unit
passed into child IO procedure.

2016-10-04  Jerry DeLisle  

* gfortran.dg/dtio_15.f90: New test.

r240766 = d59520df9fe83f1a9aea7e766cef52bf6ec790df (refs/remotes/svn/trunk)
A   gcc/testsuite/gfortran.dg/dtio_15.f90
M   libgfortran/ChangeLog
M   libgfortran/io/inquire.c


diff --git a/libgfortran/io/inquire.c b/libgfortran/io/inquire.c
index 2bb518b6..7751b8df 100644
--- a/libgfortran/io/inquire.c
+++ b/libgfortran/io/inquire.c
@@ -41,7 +41,9 @@ inquire_via_unit (st_parameter_inquire *iqp, gfc_unit * u)
   const char *p;
   GFC_INTEGER_4 cf = iqp->common.flags;

-  if (iqp->common.unit == GFC_INTERNAL_UNIT || iqp->common.unit == 
GFC_INTERNAL_UNIT4)

+  if (iqp->common.unit == GFC_INTERNAL_UNIT ||
+   iqp->common.unit == GFC_INTERNAL_UNIT4 ||
+   u->internal_unit_kind != 0)
 generate_error (&iqp->common, LIBERROR_INQUIRE_INTERNAL_UNIT, NULL);

   if ((cf & IOPARM_INQUIRE_HAS_EXIST) != 0)

Re: [PATCH] DWARF: remove pessimistic DWARF version checks for imported entities

[Dominique d'Humières]

The new patch works on darwin without new regression.

Thanks,

Dominique

> Le 4 oct. 2016 à 15:58, Pierre-Marie de Rodat  a écrit :
> 
> Hello,
> 
> Thank you very much for you help, Dominique!
> 
> On 09/29/2016 03:16 PM, Dominique d'Humières wrote:
>> FAIL: gfortran.dg/binding_label_tests_16.f03  -g  (internal compiler error)
>> FAIL: gfortran.dg/module_commons_3.f90-g  (internal compiler error)
>> FAIL: gfortran.dg/module_equivalence_1.f90-g  (internal compiler error)
>> FAIL: gfortran.dg/use_11.f90  -g  (internal compiler error)
>> FAIL: gfortran.dg/use_only_1.f90  -g  (internal compiler error)
>> FAIL: gfortran.dg/widechar_5.f90  -g  (internal compiler error)
>> 
>> FAIL: libgomp.fortran/udr15.f90   -g  (internal compiler error)
>> 
>> are giving an ICE with -g of the kind
>> 
>> internal compiler error: in dwarf2out_imported_module_or_decl, at 
>> dwarf2out.c:24070
>> 
>> corresponding to
>> 
>>  gcc_assert (scope_die->die_child);
> 
> So this is an oversight I did: the check I removed was actually useful for 
> one thing: not emitting DW_TAG_imported_module DIEs in strict DWARFv2. 
> DW_TAG_imported_declaration ones are always fine, though, so what I should do 
> is to move the check, not remove it.
> 
>> The Ada test gnat.dg/debug7.adb is also failing with
>> 
>> FAIL: gnat.dg/debug7.adb (test for excess errors)
>> Excess errors:
>> gnat1: incorrect object file extension
> 
> It seems it’s a bad interaction between dg-options "-cargs […]" and the 
> testsuite framework. Can be fixed adding “-margs” at the end.
> 
> Here is an updated patch, fixing all the issues Dominique reported. 
> Bootstrapped and regtested on x86_64-linux. I also tested on 
> x86_64-apple-darwin14.5.0 that the above errors are gone.
> 
> -- 
> Pierre-Marie de Rodat
> <0001-DWARF-move-pessimistic-DWARF-version-checks-for-impo.patch>

Re: [EVRP] Fold stmts with vrp_fold_stmt

[kugan]

Hi Richard,
Thanks for the review.

On 04/10/16 19:56, Richard Biener wrote:

On Tue, 4 Oct 2016, kugan wrote:


Hi,

This patch improves Early VRP by folding stmts using vrp_fold_stmt as it is
done in ssa_propagate for VRP.


Why?


I thought it would be good for early vrp to simplify stmts using ranges. 
If we simplify obvious cases early, wouldn't it be better for IPA/LTO?


  I'd like us to move away from the fold_stmt callback of

substitute-and-fold (I have actually started some work towards that).


I must have missed it. But what is the general issue with 
substitute-and-fold.





I have also changed EVRP to handle POINTER_TYPE_P. I will send follow up
patches to use this in IPA-VRP.


For pointers all VRP does is track non-NULLness.  Can you split out this
part?

Attached patch does that.


I'm really worried about all the testsuite changes -- it means we are
losing test coverage for VRP :/


As you said earlier, unit testing with gimple FE should help. I am also 
wondering if we should organize these testcases such that it is run once 
without evrp and once with evrp to test both?


Thanks,
Kugan

gcc/ChangeLog:

2016-10-05  Kugan Vivekanandarajah  

* tree-vrp.c (evrp_dom_walker::before_dom_children): Handle
  POINTER_TYPE_P.


gcc/testsuite/ChangeLog:

2016-10-05  Kugan Vivekanandarajah  

* gcc.dg/tree-ssa/evrp4.c: New test.



Richard.


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

Thanks,
Kugan

gcc/testsuite/ChangeLog:

2016-10-03  Kugan Vivekanandarajah  

* gcc.dg/pr68217.c: Adjust testcase as more cases are now handled in
  evrp.
* gcc.dg/predict-1.c: Likewise.
* gcc.dg/predict-9.c: Likewise.
* gcc.dg/tree-ssa/pr20318.c: Likewise.
* gcc.dg/tree-ssa/pr21001.c: Likewise.
* gcc.dg/tree-ssa/pr21090.c: Likewise.
* gcc.dg/tree-ssa/pr21294.c: Likewise.
* gcc.dg/tree-ssa/pr21559.c: Likewise.
* gcc.dg/tree-ssa/pr21563.c: Likewise.
* gcc.dg/tree-ssa/pr23744.c: Likewise.
* gcc.dg/tree-ssa/pr25382.c: Likewise.
* gcc.dg/tree-ssa/pr61839_1.c: Likewise.
* gcc.dg/tree-ssa/pr68431.c: Likewise.
* gcc.dg/tree-ssa/vrp03.c: Likewise.
* gcc.dg/tree-ssa/vrp07.c: Likewise.
* gcc.dg/tree-ssa/vrp09.c: Likewise.
* gcc.dg/tree-ssa/vrp17.c: Likewise.
* gcc.dg/tree-ssa/vrp18.c: Likewise.
* gcc.dg/tree-ssa/vrp19.c: Likewise.
* gcc.dg/tree-ssa/vrp20.c: Likewise.
* gcc.dg/tree-ssa/vrp23.c: Likewise.
* gcc.dg/tree-ssa/vrp24.c: Likewise.
* gcc.dg/tree-ssa/vrp58.c: Likewise.
* gcc.dg/tree-ssa/vrp92.c: Likewise.
* gcc.dg/tree-ssa/vrp98.c: Likewise.
* gcc.dg/vrp-min-max-1.c: Likewise.

gcc/ChangeLog:

2016-10-03  Kugan Vivekanandarajah  

* tree-vrp.c (evrp_dom_walker::before_dom_children): Handle
  POINTER_TYPE_P. Also fold stmts with vrp_fold_stmt.



>From c9badd0cee1433af67ba5e1a45a90b4b659a244f Mon Sep 17 00:00:00 2001
From: Kugan Vivekanandarajah 
Date: Mon, 3 Oct 2016 06:12:05 +1100
Subject: [PATCH 1/5] Handle pointer type in evrp

---
 gcc/testsuite/gcc.dg/tree-ssa/evrp4.c | 20 
 gcc/tree-vrp.c|  3 ++-
 2 files changed, 22 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/evrp4.c

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/evrp4.c b/gcc/testsuite/gcc.dg/tree-ssa/evrp4.c
new file mode 100644
index 000..ebb87ed
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/evrp4.c
@@ -0,0 +1,20 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-evrp" } */
+
+int foo (int *p);
+
+struct st
+{
+  int a;
+  int b;
+};
+
+int bar (struct st *s)
+{
+
+  if (!s)
+return 0;
+  foo (&s->a);
+}
+
+/* { dg-final { scan-tree-dump "\~\\\[0B, 0B\\\]" "evrp" } } */
diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c
index 7a08be7..46bbd82 100644
--- a/gcc/tree-vrp.c
+++ b/gcc/tree-vrp.c
@@ -10666,7 +10666,8 @@ evrp_dom_walker::before_dom_children (basic_block bb)
 	  && gimple_code (stmt) == GIMPLE_COND
 	  && (op0 = gimple_cond_lhs (stmt))
 	  && TREE_CODE (op0) == SSA_NAME
-	  && INTEGRAL_TYPE_P (TREE_TYPE (gimple_cond_lhs (stmt
+	  && (INTEGRAL_TYPE_P (TREE_TYPE (gimple_cond_lhs (stmt)))
+	  || POINTER_TYPE_P (TREE_TYPE (gimple_cond_lhs (stmt)
 	{
 	  /* Entering a new scope.  Try to see if we can find a VR
 	 here.  */
-- 
2.7.4

Re: C++ PATCH for C++17 class template placeholders

[Marc Glisse]

On Tue, 4 Oct 2016, Jason Merrill wrote:


C++17 adds the ability to omit the template arguments for a class
template when declaring a variable with an initializer, much like auto
but supporting a wider variety of initialization.  This is intended to
replace functions like make_tuple.


Nice. Is there a macro to test for this feature? I couldn't find it in the 
latest sg10 list.


--
Marc Glisse