Re: [RFC] Offloading Support in libgomp

[Michael V. Zolotukhin]

> Yes, splay tree can get totally unbalanced and you can have a linear lookup
> time, the O(log n) lookup time is amortized.  But, if you e.g. really do
> lookup sorted keys (which is not given, the compiler puts vars into the
> clauses based on the user order or in the order references to those vars are
> discovered, plus for array sections pointer kinds which usually have
> different addresses go immediately after the data ones), you really can have
> one O(n) lookup if you've looked e.g. the highest address last time and now
> you're looking up the lowest and the tree is totally unbalanced, but then
> won't the following lookups be all O(1), because the keys you are looking up
> will be always immediately in the right child?
If the first time the lookup was in increasing keys order, and then we are
looking up in decreasing keys order, then yes, there is no problem and at the
beginning the element we are looking for would be very close to root, so it
would be fast (at the end I guess there would be still O(log N)).  The problem
would be if the order of the 2nd lookup is the same as the order of the 1st
lookup.

> Anyway, if the splay trees ever cause issues in real-world, it is not hard
> to just replace them by something else (R-B trees, AVL trees or similar).
Yes, agreed.

Michael
>   Jakub

Re: libtool update for powerpc64le-linux

[Alan Modra]

I guess I can't really expect to gain an approval to import the
upstream libtool into gcc.  Even *I* don't really trust me, although
having looked at it a little I think I could even update
libjava/libltdl.  So how about just continuing the status quo and
applying a libtool patch that is already upstream?  Bootstrapped
powerpc64le-linux and powerpc64-linux.  OK to apply?

* libtool.m4 (_LT_ENABLE_LOCK ): Remove non-canonical
ppc host match.  Support little-endian powerpc linux hosts.
libjava/libltdl/
* acinclude.m4 (_LT_ENABLE_LOCK ): Remove non-canonical
ppc host match.  Support little-endian powerpc linux hosts.
* configure: Regenerate.
boehm-gc/
* configure: Regenerate.
gcc/
* configure: Regenerate.
* aclocal.m4: Regenerate.
fixincludes/
* configure: Regenerate.
libatomic/
* configure: Regenerate.
libbacktrace/
* configure: Regenerate.
libffi/
* configure: Regenerate.
libgfortran/
* configure: Regenerate.
libgomp/
* configure: Regenerate.
libitm/
* configure: Regenerate.
libjava/
* configure: Regenerate.
libjava/classpath/
* configure: Regenerate.
libmudflap/
* configure: Regenerate.
libobjc/
* configure: Regenerate.
libquadmath/
* configure: Regenerate.
libsanitizer/
* configure: Regenerate.
libssp/
* configure: Regenerate.
libstdc++-v3/
* configure: Regenerate.
libvtv/
* configure: Regenerate.
lto-plugin/
* configure: Regenerate.
zlib/
* configure: Regenerate.

Index: libtool.m4
===
--- libtool.m4  (revision 202428)
+++ libtool.m4  (working copy)
@@ -1220,7 +1220,7 @@ ia64-*-hpux*)
   rm -rf conftest*
   ;;
 
-x86_64-*kfreebsd*-gnu|x86_64-*linux*|ppc*-*linux*|powerpc*-*linux*| \
+x86_64-*kfreebsd*-gnu|x86_64-*linux*|powerpc*-*linux*| \
 s390*-*linux*|s390*-*tpf*|sparc*-*linux*)
   # Find out which ABI we are using.
   echo 'int i;' > conftest.$ac_ext
@@ -1241,7 +1241,10 @@ s390*-*linux*|s390*-*tpf*|sparc*-*linux*)
;;
esac
;;
- ppc64-*linux*|powerpc64-*linux*)
+ powerpc64le-*linux*)
+   LD="${LD-ld} -m elf32lppclinux"
+   ;;
+ powerpc64-*linux*)
LD="${LD-ld} -m elf32ppclinux"
;;
  s390x-*linux*)
@@ -1260,7 +1263,10 @@ s390*-*linux*|s390*-*tpf*|sparc*-*linux*)
  x86_64-*linux*)
LD="${LD-ld} -m elf_x86_64"
;;
- ppc*-*linux*|powerpc*-*linux*)
+ powerpcle-*linux*)
+   LD="${LD-ld} -m elf64lppc"
+   ;;
+ powerpc-*linux*)
LD="${LD-ld} -m elf64ppc"
;;
  s390*-*linux*|s390*-*tpf*)
Index: libjava/libltdl/acinclude.m4
===
--- libjava/libltdl/acinclude.m4(revision 202428)
+++ libjava/libltdl/acinclude.m4(working copy)
@@ -519,7 +519,7 @@ ia64-*-hpux*)
   rm -rf conftest*
   ;;
 
-x86_64-*linux*|ppc*-*linux*|powerpc*-*linux*|s390*-*linux*|sparc*-*linux*)
+x86_64-*linux*|powerpc*-*linux*|s390*-*linux*|sparc*-*linux*)
   # Find out which ABI we are using.
   echo 'int i;' > conftest.$ac_ext
   if AC_TRY_EVAL(ac_compile); then
@@ -529,7 +529,10 @@ ia64-*-hpux*)
 x86_64-*linux*)
   LD="${LD-ld} -m elf_i386"
   ;;
-ppc64-*linux*|powerpc64-*linux*)
+powerpc64le-*linux*)
+  LD="${LD-ld} -m elf32lppclinux"
+  ;;
+powerpc64-*linux*)
   LD="${LD-ld} -m elf32ppclinux"
   ;;
 s390x-*linux*)
@@ -545,7 +548,10 @@ ia64-*-hpux*)
 x86_64-*linux*)
   LD="${LD-ld} -m elf_x86_64"
   ;;
-ppc*-*linux*|powerpc*-*linux*)
+powerpcle-*linux*)
+  LD="${LD-ld} -m elf64lppc"
+  ;;
+powerpc-*linux*)
   LD="${LD-ld} -m elf64ppc"
   ;;
 s390*-*linux*)
 
-- 
Alan Modra
Australia Development Lab, IBM

[PATCH, committed] * pt.c (make_auto_1): Use input_location rather than BUILTINS_LOCATION.

[Adam Butcher]

---
 gcc/cp/pt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 2ef160a..ed08dca 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -21041,7 +21041,7 @@ static tree
 make_auto_1 (tree name)
 {
   tree au = cxx_make_type (TEMPLATE_TYPE_PARM);
-  TYPE_NAME (au) = build_decl (BUILTINS_LOCATION,
+  TYPE_NAME (au) = build_decl (input_location,
   TYPE_DECL, name, au);
   TYPE_STUB_DECL (au) = TYPE_NAME (au);
   TEMPLATE_TYPE_PARM_INDEX (au) = build_template_parm_index
-- 
1.8.4

[PATCH, re-committed] Support lambda templates.

[Adam Butcher]

From: abutcher 

* parser.c (cp_parser_lambda_declarator_opt): Accept template parameter
list with std=c++1y or std=gnu++1y.
(cp_parser_lambda_body): Don't call 'expand_or_defer_fn' for lambda call
operator template to avoid adding template result to symbol table.
* lambda.c (lambda_function): Return template result if call operator is
a template.
(maybe_add_lambda_conv_op): Move declarations to point of use.  Refactor
operator call building in order to support conversion of a non-capturing
lambda template to a function pointer with help from ...
(prepare_op_call): ... this new function.
* decl2.c (check_member_template): Don't reject lambda call operator
template in local [lambda] class.
* pt.c (instantiate_class_template_1): Don't instantiate lambda call
operator template when instantiating lambda class.
---
 gcc/cp/decl2.c  |   5 +-
 gcc/cp/lambda.c | 188 +++-
 gcc/cp/parser.c |  40 +++-
 gcc/cp/pt.c |   4 +-
 4 files changed, 201 insertions(+), 36 deletions(-)

diff --git a/gcc/cp/decl2.c b/gcc/cp/decl2.c
index c518551..4ac9445 100644
--- a/gcc/cp/decl2.c
+++ b/gcc/cp/decl2.c
@@ -502,8 +502,9 @@ check_member_template (tree tmpl)
   || (TREE_CODE (decl) == TYPE_DECL
  && MAYBE_CLASS_TYPE_P (TREE_TYPE (decl
 {
-  /* The parser rejects template declarations in local classes.  */
-  gcc_assert (!current_function_decl);
+  /* The parser rejects template declarations in local classes
+(with the exception of generic lambdas).  */
+  gcc_assert (!current_function_decl || LAMBDA_FUNCTION_P (decl));
   /* The parser rejects any use of virtual in a function template.  */
   gcc_assert (!(TREE_CODE (decl) == FUNCTION_DECL
&& DECL_VIRTUAL_P (decl)));
diff --git a/gcc/cp/lambda.c b/gcc/cp/lambda.c
index 1af301d..b04448b 100644
--- a/gcc/cp/lambda.c
+++ b/gcc/cp/lambda.c
@@ -196,7 +196,7 @@ lambda_function (tree lambda)
  /*protect=*/0, /*want_type=*/false,
  tf_warning_or_error);
   if (lambda)
-lambda = BASELINK_FUNCTIONS (lambda);
+lambda = STRIP_TEMPLATE (get_first_fn (lambda));
   return lambda;
 }
 
@@ -775,6 +775,22 @@ nonlambda_method_basetype (void)
   return TYPE_METHOD_BASETYPE (TREE_TYPE (fn));
 }
 
+/* Helper function for maybe_add_lambda_conv_op; build a CALL_EXPR with
+   indicated FN and NARGS, but do not initialize the return type or any of the
+   argument slots.  */
+
+static tree
+prepare_op_call (tree fn, int nargs)
+{
+  tree t;
+
+  t = build_vl_exp (CALL_EXPR, nargs + 3);
+  CALL_EXPR_FN (t) = fn;
+  CALL_EXPR_STATIC_CHAIN (t) = NULL;
+
+  return t;
+}
+
 /* If the closure TYPE has a static op(), also add a conversion to function
pointer.  */
 
@@ -783,9 +799,6 @@ maybe_add_lambda_conv_op (tree type)
 {
   bool nested = (current_function_decl != NULL_TREE);
   tree callop = lambda_function (type);
-  tree rettype, name, fntype, fn, body, compound_stmt;
-  tree thistype, stattype, statfn, convfn, call, arg;
-  vec *argvec;
 
   if (LAMBDA_EXPR_CAPTURE_LIST (CLASSTYPE_LAMBDA_EXPR (type)) != NULL_TREE)
 return;
@@ -793,6 +806,10 @@ maybe_add_lambda_conv_op (tree type)
   if (processing_template_decl)
 return;
 
+  bool const generic_lambda_p
+= (DECL_TEMPLATE_INFO (callop)
+&& DECL_TEMPLATE_RESULT (DECL_TI_TEMPLATE (callop)) == callop);
+
   if (DECL_INITIAL (callop) == NULL_TREE)
 {
   /* If the op() wasn't instantiated due to errors, give up.  */
@@ -800,16 +817,124 @@ maybe_add_lambda_conv_op (tree type)
   return;
 }
 
-  stattype = build_function_type (TREE_TYPE (TREE_TYPE (callop)),
- FUNCTION_ARG_CHAIN (callop));
+  /* Non-template conversion operators are defined directly with build_call_a
+ and using DIRECT_ARGVEC for arguments (including 'this').  Templates are
+ deferred and the CALL is built in-place.  In the case of a deduced return
+ call op, the decltype expression, DECLTYPE_CALL, used as a substitute for
+ the return type is also built in-place.  The arguments of DECLTYPE_CALL in
+ the return expression may differ in flags from those in the body CALL.  In
+ particular, parameter pack expansions are marked PACK_EXPANSION_LOCAL_P in
+ the body CALL, but not in DECLTYPE_CALL.  */
+
+  vec *direct_argvec = 0;
+  tree decltype_call = 0, call = 0;
+  tree fn_result = TREE_TYPE (TREE_TYPE (callop));
+
+  if (generic_lambda_p)
+{
+  /* Prepare the dependent member call for the static member function
+'_FUN' and, potentially, prepare another call to be used in a decltype
+return expression for a deduced return call op to allow for simple
+implementation of the conversion operator.  */
+
+  tree instance = build_nop (type, null_pointer_node);
+  tree objfn = 

[PATCH, re-committed] Support using 'auto' in a function parameter list to introduce an implicit template parameter.

[Adam Butcher]

From: abutcher 

gcc/cp/
* cp-tree.h (type_uses_auto_or_concept): Declare.
(is_auto_or_concept): Declare.
* decl.c (grokdeclarator): Allow 'auto' parameters in lambdas with
-std=gnu++1y or -std=c++1y or, as a GNU extension, in plain functions.
* type-utils.h: New header defining ...
(find_type_usage): ... this new function based on pt.c (type_uses_auto)
for searching a type tree given a predicate.
* pt.c (type_uses_auto): Reimplement via type-utils.h (find_type_usage).
(is_auto_or_concept): New function.
(type_uses_auto_or_concept): New function.
* parser.h (struct cp_parser): Add fully_implicit_function_template_p.
* parser.c (cp_parser_new): Initialize 
fully_implicit_function_template_p.
(cp_parser_new): Initialize fully_implicit_function_template_p.
(cp_parser_lambda_expression): Copy and restore value of
fully_implicit_function_template_p as per other parser fields.
(cp_parser_parameter_declaration_list): Count generic
parameters and call ...
(add_implicit_template_parms): ... this new function to synthesize them
with help from type-utils.h (find_type_usage), ...
(tree_type_is_auto_or_concept): ... this new static function and ...
(make_generic_type_name): ... this new static function.
(cp_parser_direct_declarator): Account for implicit template parameters.
(cp_parser_lambda_declarator_opt): Finish fully implicit template if
necessary by calling ...
(finish_fully_implicit_template): ... this new function.
(cp_parser_init_declarator): Likewise.
(cp_parser_function_definition_after_declarator): Likewise.
(cp_parser_member_declaration): Likewise.
* Make-lang.in (cp/pt.o): Add dependency on type-utils.h.
(cp/parser.o): Likewise.

gcc/testsuite/
g++.dg/cpp0x/auto9.C: Downgrade two previously expected errors (now
interpreted as implicit templates) to be expected pedwarns instead.
---
 gcc/cp/Make-lang.in|   5 +-
 gcc/cp/cp-tree.h   |   2 +
 gcc/cp/decl.c  |  29 +++-
 gcc/cp/parser.c| 289 ++---
 gcc/cp/parser.h|   6 +
 gcc/cp/pt.c|  35 +++--
 gcc/cp/type-utils.h|  55 +++
 gcc/testsuite/g++.dg/cpp0x/auto9.C |   4 +-
 8 files changed, 353 insertions(+), 72 deletions(-)
 create mode 100644 gcc/cp/type-utils.h

diff --git a/gcc/cp/Make-lang.in b/gcc/cp/Make-lang.in
index 9a80434..985f22b 100644
--- a/gcc/cp/Make-lang.in
+++ b/gcc/cp/Make-lang.in
@@ -312,7 +312,7 @@ cp/except.o: cp/except.c $(CXX_TREE_H) $(TM_H) $(FLAGS_H) \
 cp/expr.o: cp/expr.c $(CXX_TREE_H) $(TM_H) $(FLAGS_H) $(TM_P_H)
 cp/pt.o: cp/pt.c $(CXX_TREE_H) $(TM_H) cp/decl.h cp/cp-objcp-common.h \
   toplev.h $(TREE_INLINE_H) pointer-set.h gt-cp-pt.h intl.h \
-  c-family/c-objc.h
+  c-family/c-objc.h cp/type-utils.h
 cp/error.o: cp/error.c $(CXX_TREE_H) $(TM_H) $(DIAGNOSTIC_H) \
   $(FLAGS_H) $(REAL_H) $(LANGHOOKS_DEF_H) $(CXX_PRETTY_PRINT_H) \
   tree-diagnostic.h tree-pretty-print.h pointer-set.h c-family/c-objc.h
@@ -331,7 +331,8 @@ cp/mangle.o: cp/mangle.c $(CXX_TREE_H) $(TM_H) $(REAL_H) \
   gt-cp-mangle.h $(TARGET_H) $(TM_P_H) $(CGRAPH_H)
 cp/parser.o: cp/parser.c $(CXX_TREE_H) $(TM_H) $(DIAGNOSTIC_CORE_H) \
   gt-cp-parser.h $(TARGET_H) $(PLUGIN_H) intl.h cp/decl.h \
-  c-family/c-objc.h tree-pretty-print.h $(CXX_PARSER_H) $(TIMEVAR_H)
+  c-family/c-objc.h tree-pretty-print.h $(CXX_PARSER_H) $(TIMEVAR_H) \
+  cp/type-utils.h
 cp/cp-gimplify.o: cp/cp-gimplify.c $(CXX_TREE_H) $(C_COMMON_H) \
$(TM_H) coretypes.h pointer-set.h tree-iterator.h $(SPLAY_TREE_H)
 cp/vtable-class-hierarchy.o: cp/vtable-class-hierarchy.c \
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 4680053..d7840af 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -5453,10 +5453,12 @@ extern tree make_auto   (void);
 extern tree make_decltype_auto (void);
 extern tree do_auto_deduction  (tree, tree, tree);
 extern tree type_uses_auto (tree);
+extern tree type_uses_auto_or_concept  (tree);
 extern void append_type_to_template_for_access_check (tree, tree, tree,
  location_t);
 extern tree splice_late_return_type(tree, tree);
 extern bool is_auto(const_tree);
+extern bool is_auto_or_concept (const_tree);
 extern tree process_template_parm  (tree, location_t, tree, 
 bool, bool);
 extern tree end_template_parm_list (tree);
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index f193676..80ceca1 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -10323,8 +10323,33 @@ grokdeclarator (const cp_declar

Re: Using gen_int_mode instead of GEN_INT minot testsuite fallout on MIPS

[Richard Sandiford]

Richard Biener  writes:
> On Fri, Sep 13, 2013 at 10:33 AM, Richard Sandiford
>  wrote:
>> Richard Biener  writes:
 Yeah.  I don't think it makes sense to canonise PSI to 32 bits when we
 know it has fewer than 32 bits.  It's still going to be wrong, and will
 still defeat one of the main purposes of canonical constants, which is
 to make equality obvious.  E.g. we'd still treat PSI constants

   (const_int 0x...ff8000)

 and

   (const_int 0x...ffc000)

 as different, even though they're both zero for a 24-bit PSI.

 This partial integer mode stuff is just a big hack.  Like you say,
 we can only really do something sensible if we know what the real
 precision is.

 So I'd rather leave things as they are for this series.  The precision
 effectively becomes 65535 thanks to the underlying unsigned short array,
 so like you say, trunc_int_for_mode is a no-op for partial modes.
 Changing GEN_INT to gen_int_mode shouldn't make any difference.

 What do you think about the patch for CC modes?
>>>
>>> I wonder if we can do without changing gen_int_mode by fixing the callers
>>> like you did for cse.c (that patch is ok).
>>
>> But the point of the gen_int_mode patch is that (for better or worse)
>> CONST_INT is the right choice of rtx for constant CC values.  I'd like
>> eventually to get rid of all GEN_INT callers, and some of those callers
>> will sometimes or always be handling CC modes.  This would then crop up
>> again in a legitimate context.
>>
>> IMO, cse.c was buggy not because it was trying to generate a CCmode
>> CONST_INT, but because anchor optimisations involve addition, which
>> isn't defined for CC modes.
>>
>> I think gen_int_mode should do the right thing for all CONST_INT modes.
>> gen_int_mode (X, MODE) should really be the moral equivalent of
>> gen_rtx_CONST_INT (MODE, X), despite the confusingly-swapped parameters.
>
> Yeah, ok.  But the GEN_INT changes have already uncovered quite some bugs
> so maybe let us discover a few more CCmode bugs first? ...

OK, sounds fair.  I'll hold off the gen_int_mode change until I have
legitimate use.  I went ahead and applied the cse.c change.

Thanks,
Richard

Re: C++ PATCH for c++/41933 (variadic lambda capture)

[Adam Butcher]

Excellent.  This now supports the variadic generic lambda from the spec 
(albeit without the auto parameter pack)


   auto vglambda = [](auto printer)
   {
 // TODO: return [=](auto&& ... ts)   // OK: ts is a function 
parameter pack
 return [=]  (T&& ... ts)   // OK: ts is a function 
parameter pack

 {
   printer(std::forward(ts)...);
   return [=]()
   {
 printer(ts ...);
   };
 };
   };
   auto p = vglambda( [](auto v1, auto v2, auto v3)
 {
   std::cout << v1 << v2 << v3;
 } );
   auto q = p(1, 'a', 3.14); // OK: outputs 1a3.14
   q(); // OK: outputs 1a3.14


Just need to get 'auto...' working now for C++14 generic lambda 
conformance.  (I'm still trying!)


Cheers,
Adam

Re: [RFC] Offloading Support in libgomp

[Jakub Jelinek]

On Mon, Sep 16, 2013 at 11:15:16AM +0400, Michael V. Zolotukhin wrote:
> > Yes, splay tree can get totally unbalanced and you can have a linear lookup
> > time, the O(log n) lookup time is amortized.  But, if you e.g. really do
> > lookup sorted keys (which is not given, the compiler puts vars into the
> > clauses based on the user order or in the order references to those vars are
> > discovered, plus for array sections pointer kinds which usually have
> > different addresses go immediately after the data ones), you really can have
> > one O(n) lookup if you've looked e.g. the highest address last time and now
> > you're looking up the lowest and the tree is totally unbalanced, but then
> > won't the following lookups be all O(1), because the keys you are looking up
> > will be always immediately in the right child?
> If the first time the lookup was in increasing keys order, and then we are
> looking up in decreasing keys order, then yes, there is no problem and at the
> beginning the element we are looking for would be very close to root, so it
> would be fast (at the end I guess there would be still O(log N)).  The problem
> would be if the order of the 2nd lookup is the same as the order of the 1st
> lookup.

No.  If you insert 1 to 100 into a splay tree in ascending order (that will
give you a totally unbalanced tree), and then lookup 1 to 100 in the
ascending order again, then the lookup of 1 will be expensive (100
comparisons), but then for each following lookup it
will cost just 2 comparisons, so for the 100 lookups you'll need 298
comparisons, i.e. ~ 3 comparisons per lookup on average (rather than the 6-7
lookups you'd get for balanced AVL tree or similar).  Splay trees
actually behave very nicely if the lookups are done in sorted orders or
if you usually look up similar addresses in sequence (which is quite likely,
usually the splay tree will contain addresses of #pragma omp declare target
vars (and selected functions) and typically lookups for #pragma omp target
will be usually for function local variables which will have similar
addresses), and if what you lookup is completely random, then you wouldn't
end up with an unbalanced tree.

Jakub

Re: Recent IPA regression with internal functions

[Jakub Jelinek]

On Sun, Sep 15, 2013 at 09:08:00PM +0200, Jan Hubicka wrote:
> > 2013-09-13  Jakub Jelinek  
> > 
> > * ipa-prop.c (ipa_compute_jump_functions_for_edge): Return early
> > for internal calls.
> 
> That seems resonable.  I wonder if we want to consider internal calls to form
> callgarph edges at all: perhaps we can just modify cgraph builder+verifier
> to skip them and consider them to be normal instruction

I'd wonder how many spots would need to be changed for that though, to check
for is_gimple_call && !gimple_call_internal_p instead of just
is_gimple_call.  In cgraph*, inliner, sra, IPA, whatever else assumes that a
GIMPLE_CALL should have a cgraph_edge associated with it.
The internal functions for the time being should be pretty rare,
right now they are used just for some ARM vectorization stuff (during/after
vectorizations only, so no IPA) and newly for the OpenMP/Cilk+ SIMD loops,
so if it is just about avoiding memory waste because of them, I think it
isn't a big deal.

Jakub

Re: [PATCH, committed] * pt.c (make_auto_1): Use input_location rather than BUILTINS_LOCATION.

[Eric Botcazou]

> ---
>  gcc/cp/pt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
> index 2ef160a..ed08dca 100644
> --- a/gcc/cp/pt.c
> +++ b/gcc/cp/pt.c
> @@ -21041,7 +21041,7 @@ static tree
>  make_auto_1 (tree name)
>  {
>tree au = cxx_make_type (TEMPLATE_TYPE_PARM);
> -  TYPE_NAME (au) = build_decl (BUILTINS_LOCATION,
> +  TYPE_NAME (au) = build_decl (input_location,
>  TYPE_DECL, name, au);
>TYPE_STUB_DECL (au) = TYPE_NAME (au);
>TEMPLATE_TYPE_PARM_INDEX (au) = build_template_parm_index

That's not a valid post to gcc-patches though.  You need to explain what the 
patch does in a few words, post a ChangeLog entry and say how you tested it.

See all the other messages on the list...

-- 
Eric Botcazou

Re: [RFC] Offloading Support in libgomp

[Michael V. Zolotukhin]

> No.  If you insert 1 to 100 into a splay tree in ascending order (that will
> give you a totally unbalanced tree), and then lookup 1 to 100 in the
> ascending order again, then the lookup of 1 will be expensive (100
> comparisons), but then for each following lookup it
> will cost just 2 comparisons, so for the 100 lookups you'll need 298
> comparisons, i.e. ~ 3 comparisons per lookup on average (rather than the 6-7
> lookups you'd get for balanced AVL tree or similar).  Splay trees
> actually behave very nicely if the lookups are done in sorted orders or
> if you usually look up similar addresses in sequence (which is quite likely,
> usually the splay tree will contain addresses of #pragma omp declare target
> vars (and selected functions) and typically lookups for #pragma omp target
> will be usually for function local variables which will have similar
> addresses), and if what you lookup is completely random, then you wouldn't
> end up with an unbalanced tree.
Maybe you are right, so splay trees might be the best choice here indeed.

Michael
>   Jakub

Re: [PATCH, committed] * pt.c (make_auto_1): Use input_location rather than BUILTINS_LOCATION.

[Adam Butcher]

On 16.09.2013 09:02, Eric Botcazou wrote:

---
 gcc/cp/pt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 2ef160a..ed08dca 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -21041,7 +21041,7 @@ static tree
 make_auto_1 (tree name)
 {
   tree au = cxx_make_type (TEMPLATE_TYPE_PARM);
-  TYPE_NAME (au) = build_decl (BUILTINS_LOCATION,
+  TYPE_NAME (au) = build_decl (input_location,
   TYPE_DECL, name, au);
   TYPE_STUB_DECL (au) = TYPE_NAME (au);
   TEMPLATE_TYPE_PARM_INDEX (au) = build_template_parm_index


That's not a valid post to gcc-patches though.  You need to explain 
what the
patch does in a few words, post a ChangeLog entry and say how you 
tested it.


See all the other messages on the list...

Apologies if this was out of context.  This was a change suggested and 
reviewed by Jason 
(http://gcc.gnu.org/ml/gcc-patches/2013-09/msg01114.html).


It has been commited.  The changelog happened to be a one liner which 
folded into the subject line.

[PING] [PATCH] PR58143/58227 wrong code at -O3

[Bernd Edlinger]

ping...

On Wed, 4 Sep 2013 18:45:39, Bernd Edlinger wrote:
>
> On Tue, 3 Sep 2013 12:31:50, Richard Biener wrote:
>> On Fri, Aug 30, 2013 at 6:43 PM, Bernd Edlinger
>>  wrote:
>>> Now I think this is good opportunity for a simple heuristic:
>>>
>>> If a statement is at loop level 1 we can move it out of the loop,
>>> regardless of the fact, that it may invoke undefined behavior, because if 
>>> it is
>>> moved then out of any loops, and thus it cannot be an induction variable and
>>> cause problems with aggressive loop optimizations later.
>>
>> VRP can still cause wrong-code issues (it's probably hard to generate a
>> testcase though). Also a less conservative check would be to see
>> whether we hoist _into_ loop level 0 (though we cannot check that at
>> the point where you placed the check).
>
> Well, then I should better revert this heuristic again.
>
>>> Only statements with possible undefined behavior in nested loops can become
>>> induction variable if lim moves them from one loop into an outer loop.
>>>
>>> Therefore with extremely much luck the test case will pass unmodified.
>>> I tried it, and the patch passes bootstrap and causes zero regressions
>>> with this heuristic.
>>>
>>> Ok for trunk now?
>>
>> Jakub mentioned another possibility - make sure the moved expression
>> does not invoke undefined behavior by computing in an unsigned type.
>
> That is a possibility, but on the other hand, that would obscure the undefined
> behavior and thus prevent other possible optimizations later.
>
> Another possibility would be to move the statement together with the
> enclosing if-statement, thus really preserving the execution.
>
>> That said, for the sake of backporting we need a patch as simple as
>> possible - so it would be interesting to see whether the patch without
>> the loop 1 heuristic has any effect on say SPEC CPU 2006 performance.
>
> I do not have access to that test, but on the dhrystone benchmark this patch
> has no influence whatsoever.
>
> Attached you'll find the latest version of my patch without the heuristic.
> Bootstrapped on i686-pc-linux-gnu and regression tested again.
>
> Ok for trunk and 4.8 branch?

Ping patch to enable *.cc files in gengtype

[Basile Starynkevitch]

Hello all,

I'm pinging the patch (of september 2nd) on 
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00036.html


 gcc/ChangeLog entry 

2013-09-16  Basile Starynkevitch  

* gengtype.c (file_rules): Added rule for *.cc files.
(get_output_file_with_visibility): Give fatal message when no
rules found.

###

Regards
-- 
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Ping^2: small patch to accept = inside GCC plugin arguments

[Basile Starynkevitch]

Hello All,

I'm pinging again my small patch to accept = inside plugin arguments
http://gcc.gnu.org/ml/gcc-patches/2013-08/msg00382.html
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00037.html


# gcc/ChangeLog entry
2013-09-16  Basile Starynkevitch  

* plugin.c (parse_plugin_arg_opt): Accept equal sign inside 
  plugin argument.


Regards

-- 
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Re: [AArch64] Implement vcopy intrinsics.

[Marcus Shawcroft]

On 13/09/13 19:39, James Greenhalgh wrote:


Hi,

This patch adds intrinsics for vcopy_lane_<8,16,32,64>.

These are implemented in an optimal way using the vget_lane and vset_lane
intrinsics and a combine pattern.

I've added a testcase and run a full regression run for aarch64-none-elf.

OK?

Thanks,
James


OK
/Marcus

Re: [AArch64] Implement vmul_lane_<16,32,64> intrinsics in C

[Marcus Shawcroft]

On 13/09/13 19:28, James Greenhalgh wrote:


Hi,

This patch converts the vmul_lane_<16,32,64> intrinsics
in arm_neon.h to a C implementation.

OK
/Marcus

Re: [AArch64] Improve arm_neon.h vml_lane handling.

[Marcus Shawcroft]

On 13/09/13 19:31, James Greenhalgh wrote:


Hi,

This patch reimpliments the vml_lane and the fm
intrinsics in C, and adds new combiner patterns to support
this.


OK
/Marcus

Re: [AArch64] Fix parameters to vcvtx_high

[James Greenhalgh]

*ping*

Cheers,
James

On Fri, Sep 06, 2013 at 04:06:08PM +0100, James Greenhalgh wrote:
> 
> Hi,
> 
> vcvtx_high_f32_f64 should have two parameters, a float32x2 which
> provides the lower half of the target vector, and a float64x2
> which will be converted to the higher half of the target vector.
> 
> Fix thusly.
> 
> Tested with aarch64.exp on aarch64-none-elf.
> 
> OK?
> 
> Thanks,
> James
> 
> ---
> gcc/
> 
> 2013-09-06  James Greenhalgh  
> 
>   * config/aarch64/arm_neon.h
>   (vcvtx_high_f32_f64): Fix parameters.
> 

> diff --git a/gcc/config/aarch64/arm_neon.h b/gcc/config/aarch64/arm_neon.h
> index 5864f2c..47b45f4 100644
> --- a/gcc/config/aarch64/arm_neon.h
> +++ b/gcc/config/aarch64/arm_neon.h
> @@ -5756,12 +5756,12 @@ vcvtx_f32_f64 (float64x2_t a)
>  }
>  
>  __extension__ static __inline float32x4_t __attribute__ ((__always_inline__))
> -vcvtx_high_f32_f64 (float64x2_t a)
> +vcvtx_high_f32_f64 (float32x2_t a, float64x2_t b)
>  {
>float32x4_t result;
>__asm__ ("fcvtxn2 %0.4s,%1.2d"
> : "=w"(result)
> -   : "w"(a)
> +   : "w" (b), "0"(a)
> : /* No clobbers */);
>return result;
>  }

Re: [patch] Cleanup tree-ssa-ter.c exports

[Richard Biener]

On Fri, Sep 13, 2013 at 9:15 PM, Andrew MacLeod  wrote:
> On 09/13/2013 11:11 AM, Andrew MacLeod wrote:
>>
>> On 09/13/2013 03:54 AM, Richard Biener wrote:
>>>
>>> On Thu, Sep 12, 2013 at 11:09 PM, Andrew MacLeod 
>>> wrote:

 There are 2 parts of tre-ssa-ter.c to address.

 is_replaceable_p() is also used in expr.c, It has a flag to indicate
 where
 its being called from, and we do different checks for each one.  There
 is a
 wrapper function stmt_is_replaceable_p() in tree-ssa-ter.c which hides
 the
 setting of the flag to expr.c. Most of the function is common, so I
 extracted out the common part, and put it in tree-ssa.c.
 I then moved stmt_is_replaceable() to expr.c, has it call the common
 routine
 and then added the extra bit it needs there.  Similarly tree-ssa-ter.c
 gets
 ter_is_replaceable_p() which calls the common part, and then does its
 own
 special checking.   This removes that general export and messiness from
 tree-ssa-ter.c

 I think I got the logic of the function right, but you might want to
 double
 check...  It was giving me a headache when I split it :-)

 Unfortunately,  tree-ssa-ter.c also has 2 functions
 (find_replaceable_exprs() and  dump_replaceable_exprs()) which are
 exported
 and utilized by tree-outof-ssa.c  (the file is a part of the out-of-ssa
 module).  So I moved the prototypes from tree-ssa-live.h into a newly
 created tree-ssa-ter.h file,  and included it directly from
 tree-outof-ssa.c, the only consumer.

 I also could have just left the is_replaceable_p() function as is, put
 the
 prototype and the 'stmt_is_replaceable_p()' wrapper function in
 tree-ssa-ter.h, and then included that from expr.c...  but it just seems
 like an odd thing to include directly there  but that is an
 option...

 eventually we mighty want to look at splitting expr.c.. it seems a bit
 multi-personality with some pure RTL, some tree/rtl and some ssa...
 even
 though they all serve the same ultimate function, it is 11,000+ lines
 long
 now :-) .  A task for another day.
>>>
>>> is_replaceable_p and friends is purely specific to the area of RTL
>>> expansion,
>>> so putting it in tree-ssa.[ch] is definitely wrong.  It doesn't make
>>> sense to
>>> use it anywhere else.
>>>
>>> The main driver of the RTL expansion process is in cfgexpand.c (the
>>> expand
>>> pass itself) in gimple_expand_cfg.  We have one header file related to
>>> the RTL expansion process and is_replaceable_p would simply fit in
>>> ssaexpand.h (which doesn't have a .c file, so leaving the stuff in the .c
>>> files
>>> where they are now is ok).
>>>
>>> So - I fear you have to re-do this patch (in a much simpler way).
>>>
>> I actually figured as much :-)  I had actually done that split before I
>> remembered there were other exports, and considered undoing that part, but
>> figured since I had done it I'd get opinion :-)
>>
>> Or are you suggesting we also bail on tree-ssa-ter.h and put those
>> prototypes in ssaexpand.h?
>>
>> If we want to make this fully consistent (.h's match .c exports) , I could
>> put is_replaceable_p() into a new ssaexpand.c, move the 3 tree-outof-ssa
>> prototypes in ssaexpand.h into tree-outof-ssa.h, and have ssaexpand.h
>> include tree-ssa-ter.h and tree-outof-ssa.h.   That would then be clean. and
>> consistent.
>>
>> actually, we could just make is_replaceable_p() static inline in
>> ssaexpand.h...  thats not unreasonable either, but we'll probably find
>> functions which belong in ssaexpand.c sooner or later.
>>
>> No worries, I figured these first few patches would be slower and more
>> painful until a reasonable formula was determined :-)
>>
>>
>> Andrew
>>
> OK, a slightly different take..
> I realized that I should be adding tree-outof-ssa.h to handle the 3 exports
> from tree-outof-ssa.c that are in ssaexpand.h...  In fact, by far the most
> sensible thing to do is to simply rename tree-outof-ssa.c to ssaexpand.c.
> This actually resolves a number of warts... And is_replaceable_p() very
> naturally fits in ssaexpand.c now...
>
> what do you think of this option? :-)  and svn rename preserves all the
> tree-outof-ssa.c history...

I don't like the new name for tree-outof-ssa.c, it matches less to its contents.

I'd say either keep ssaexpand.h and tree-outof-ssa.c as-is or rename
ssaexpand.h to tree-outof-ssa.h.  I prefer the latter.

The rest of the changes look ok to me, but watch out for odd whitespace
changes:

+static inline bool
+ter_is_replaceable_p (gimple stmt)
+{
+
+  if (ssa_is_replaceable_p (stmt))

spurious vertical space.

Thanks,
Richard.



> Andrew
>
>
>
>

Re: [PATCH, ARM, LRA] Prepare ARM build with LRA

[Yvan Roux]

Adding Eric and Steven in the loop as it is RTL related.

Thanks
Yvan

On 11 September 2013 21:08, Yvan Roux  wrote:
> Here is the new patch discussed in the other thread.
>
> Thanks
> Yvan
>
> 2013-09-11  Yvan Roux  
> Vladimir Makarov  
>
> * rtlanal.c (lsb_bitfield_op_p): New predicate for bitfield operations
> from the least significant bit.
> (strip_address_mutations): Add bitfield operations handling.
> (shift_code_p): New predicate for shifting operations.
> (must_be_index_p): Add shifting operations handling.
> (set_address_index): Likewise.

Re: [AArch64] Fix parameters to vcvtx_high

[Marcus Shawcroft]

On 06/09/13 16:06, James Greenhalgh wrote:


gcc/

2013-09-06  James Greenhalgh  

* config/aarch64/arm_neon.h
(vcvtx_high_f32_f64): Fix parameters.



OK
/Marcus

Re: tree if convert pass control

[Richard Biener]

On Sat, Sep 14, 2013 at 8:10 AM, Xinliang David Li  wrote:
> tree if conversion is an enabler pass for vectorization, so by
> default, it is only turned on when vectorization is on, but may also
> depend on the optimization level. Currently, the logic to handle this
> is in the gate function which become hard to understand and extend.
>
> The proposed patch move the logic from the gate function to
> 'finish_option' which is much clearer. The downside of this patch is
> that function specific optimization node needs to be created for some
> cases during omp-lowering.

Something I don't like.  What's the issue with checking the
has_force_vect_loops flag?

How's the argument that the gate is hard to extend?  Wouldn't
extending it complicate it again and thus make it hard to understand again?

That said, given that doing things in finish_options () is discouraged
the patch looks like a step backwards.

So, can you explain the underlying rationale?

Btw, if we think of if-conversion as tied to loop vectorization then we can
guard it by it and make a new container pass like

  NEXT_PASS (pass_loop_vectorizer);
  PUSH_INSERT_PASSES_WITHIN (pass_loop_vectorizer)
  NEXT_PASS (pass_if_conversion);
  NEXT_PASS (pass_vectorize);
  NEXT_PASS (pass_dce_loop);
  POP_INSERT_PASSES ()

and guard pass_loop_vectorizer by flag_tree_loop_vectorize, defaulting
if-conversion to be enabled (but allow disabling it manually).

Or take the step and move it under control of the vectorizer itself.

Richard.

> Comments?
>
>
> thanks,
>
> David

Re: [buildrobot] [PATCH] r202527: ssa / ssanames restructure broke alpha-linux

[Richard Biener]

On Sat, Sep 14, 2013 at 12:41 PM, Jan-Benedict Glaw  wrote:
> Hi!
>
> My Build Robot[1] found this recent commit to break Alpha:
>
> * tree-flow.h (FREE_SSANAMES): Move to tree-ssanames.c
> (SSANAMES, MODIFIED_NORETURN_CALLS, DEFAULT_DEFS, ptr_info_def,
> num_ssa_names, ssa_name): Move to tree-ssanames.h + prototypes.
> * tree-flow-inline.h (make_ssa_name, copy_ssa_name, 
> duplicate_ssa_name,
> make_temp_ssa_name): move to tree-ssanames.h
> * tree-ssa-alias.h: Move prototype.
> * tree-ssa.h: Include tree-ssanames.h.
> * tree-ssanames.c (FREE_SSANAMES): Move to here.
> * tree-ssanames.h: New.  Move items from tree-flow*.h
> * Makefile.in (tree-ssanames.h): Add to tree-ssanames.o and GTFILES.
>
> See for example this build log:
> http://toolchain.lug-owl.de/buildbot/showlog.php?id=11663&mode=view
>
> I suggest this patch, which fixes an alpha-linux build for me:

I think you can remove the tree-flow.h include and you need to update the
dependencies in gcc/Makefile.in.

Richard.

> 2013-09-13  Jan-Benedict Glaw  
>
> * config/alpha.c: Include tree-ssa.h.
>
> diff --git a/gcc/config/alpha/alpha.c b/gcc/config/alpha/alpha.c
> index a8fb929..3759205 100644
> --- a/gcc/config/alpha/alpha.c
> +++ b/gcc/config/alpha/alpha.c
> @@ -50,6 +50,7 @@ along with GCC; see the file COPYING3.  If not see
>  #include "splay-tree.h"
>  #include "gimple.h"
>  #include "tree-flow.h"
> +#include "tree-ssa.h"
>  #include "tree-stdarg.h"
>  #include "tm-constrs.h"
>  #include "df.h"
>
>
> Ok?
>
> MfG, JBG
>
> [1] http://toolchain.lug-owl.de/buildbot/
> http://toolchain.lug-owl.de/buildbot/timeline.php
> --
>   Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
>  Signature of:If it doesn't work, force it.
>  the second  :   If it breaks, it needed replacing anyway.

Re: [buildrobot] [PATCH] r202527: ssa / ssanames restructure broke alpha-linux

[Uros Bizjak]

Hello!

> My Build Robot[1] found this recent commit to break Alpha:
>
> * tree-flow.h (FREE_SSANAMES): Move to tree-ssanames.c
> (SSANAMES, MODIFIED_NORETURN_CALLS, DEFAULT_DEFS, ptr_info_def,
> num_ssa_names, ssa_name): Move to tree-ssanames.h + prototypes.
> * tree-flow-inline.h (make_ssa_name, copy_ssa_name, duplicate_ssa_name,
> make_temp_ssa_name): move to tree-ssanames.h
> * tree-ssa-alias.h: Move prototype.
> * tree-ssa.h: Include tree-ssanames.h.
> * tree-ssanames.c (FREE_SSANAMES): Move to here.
> * tree-ssanames.h: New.  Move items from tree-flow*.h
> * Makefile.in (tree-ssanames.h): Add to tree-ssanames.o and GTFILES.
>
> See for example this build log:
> http://toolchain.lug-owl.de/buildbot/showlog.php?id=11663&mode=view
>
> I suggest this patch, which fixes an alpha-linux build for me:
>
> 2013-09-13  Jan-Benedict Glaw  
>
> * config/alpha.c: Include tree-ssa.h.

Thanks, I have tested the patch and commit it to the mainline to
restore bootstrap.

Uros.

Re: Using gen_int_mode instead of GEN_INT minor testsuite fallout on MIPS

[Richard Biener]

On Fri, Sep 13, 2013 at 10:23 PM, Mike Stump  wrote:
> On Sep 13, 2013, at 1:08 AM, Richard Sandiford  
> wrote:
 We don't really model that properly yet.  Partial modes are just defined
 using something like:

 PARTIAL_INT_MODE (SI);
>
> True, but, all ports are trivial to fix so that the precision is included and 
> for the interface to change to include the precision.
>
>>> Well I was asking because if you change a GEN_INT (x) to
>>> gen_int_mode (PSImode, x) then you'll end up in trunc_int_for_mode with
>>> PSImode which looks at GET_MODE_PRECISION (PSImode is still
>>> a SCALAR_INT_MODE_P ...).  We set precision of PSImode to -1U
>
> Easy to fix.
>
>> Yeah.  I don't think it makes sense to canonise PSI to 32 bits when we
>> know it has fewer than 32 bits.
>
> Agreed.
>
>
> Here is the patch to add precision to partial int modes.  I included 
> switching over the rs6000 port to the new scheme so one can get a feel for 
> that it would look like.
>
> I could trivially convert the remaining ports:
>
> config/bfin/bfin-modes.def:PARTIAL_INT_MODE (DI);
> config/m32c/m32c-modes.def:PARTIAL_INT_MODE (SI);
> config/msp430/msp430-modes.def:PARTIAL_INT_MODE (SI);
> config/rs6000/rs6000-modes.def:PARTIAL_INT_MODE_N (TI, 128);
> config/sh/sh-modes.def:PARTIAL_INT_MODE (SI);
> config/sh/sh-modes.def:PARTIAL_INT_MODE (DI);
>
> to the new scheme so that _all_ ports would have a precision with all partial 
> int modes.  The newest port that I had not audited for how they use it 
> (msp430):
>
> /* 20-bit address */
> PARTIAL_INT_MODE (SI);
>
> So, this, trivially would be SI, 20…  I would define PARTIAL_INT_MODE with 
> two parameters and not define PARTIAL_INT_MODE_N, if we did it for real.  No 
> need for partial conversions here, too easy to convert things.
>
> Ok for the non-powerpc bits?

Can you instead of adding PARTIAL_INT_MODE_N change all existing
PARTIAL_INT_MODE ()s to PARTIAL_INT_MODE_LEGACY () and change
PARTIAL_INT_MODE behavior?

> Want me to convert all the ports and change the interface instead of merely 
> extending it and submit those?  I'd hate to do the work, if no one wants to 
> review/approve it.

I volunteer to approve it (after giving target maintainers time to do
so on their own).

So, if you send a whole conversion patch then we don't have to play games
with having both variants recognized.  (now it just occurs to me we can use
a variadic macro here ...?)

Richard.

> We've been using this scheme on our port for a while and it seems to work 
> nicely.
>
>

Ping: [PATCH]: Fix use of __builtin_eh_pointer in EH_ELSE

[Tristan Gingold]

Any comment/review on this patch ?

On Sep 3, 2013, at 4:08 PM, Tristan Gingold  wrote:

> Hi,
> 
> The field state->ehp_region wasn't updated before lowering constructs in the 
> eh
> path of EH_ELSE.  As a consequence, __builtin_eh_pointer is lowered to 0 (or
> possibly to a wrong region number) in this path.
> 
> The only user of EH_ELSE looks to be trans-mem.c:lower_transaction, and the
> consequence of that is a memory leak.
> 
> Furthermore, according to calls.c:flags_from_decl_or_type, the 
> "transaction_pure"
> attribute must be set on the function type, not on the function declaration.
> Hence the change to declare __builtin_eh_pointer.
> (I don't understand the guard condition to set the attribute for it in tree.c.
> Why is 'builtin_decl_explicit_p (BUILT_IN_TM_LOAD_1)' needed in addition to
> flag_tm ?)
> 
> No regressions (check-host) on x86-64 GNU/Linux.
> 
> Ok for trunk ?
> 
> Tristan.
> 
> 2013-09-03  Tristan Gingold  
> 
>   * tree.c (set_call_expr_flags): Reject ECF_TM_PURE.
>   (build_common_builtin_nodes): Set "transaction_pure"
>   attribute on __builtin_eh_pointer function type (and not on
>   its declaration).
>   * tree-eh.c (lower_try_finally_nofallthru): Set and revert
>   ehp_region before callinf lower_eh_constructs_1.
>   (lower_try_finally_onedest): Likewise.
>   (lower_try_finally_copy): Likewise.
>   (lower_try_finally_switch): Likewise.
> 
> testsuite/
> 2013-09-03  Tristan Gingold  
> 
>   * gcc.dg/tm/except.c: New testcase.
> 
> 
> diff --git a/gcc/testsuite/gcc.dg/tm/except.c 
> b/gcc/testsuite/gcc.dg/tm/except.c
> new file mode 100644
> index 000..ed84bb3
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/tm/except.c
> @@ -0,0 +1,36 @@
> +/* { dg-do compile } */
> +/* { dg-options "-fgnu-tm -O1 -fexceptions -fdump-tree-optimized" } */
> +
> +typedef struct node {
> +  int val;
> +  struct node *next;
> +} node_t;
> +
> +node_t *head;
> +
> +__attribute__((transaction_safe))
> +node_t *new_node(int val, node_t *next);
> +
> +int add(int val)
> +{
> +  int result;
> +  node_t *prev, *next;
> +
> +  __transaction_atomic {
> +prev = head;
> +next = prev->next;
> +while (next->val < val) {
> +  prev = next;
> +  next = prev->next;
> +}
> +result = (next->val != val);
> +if (result) {
> +  prev->next = new_node(val, next);
> +}
> +  }
> +  return result;
> +}
> +
> +/* { dg-final { scan-tree-dump-not "ITM_commitTransactionEH \\(0B\\)" 
> "optimized" } } */
> +
> +/* { dg-final { cleanup-tree-dump "optimized" } } */
> diff --git a/gcc/tree-eh.c b/gcc/tree-eh.c
> index 6ffbd26..86ee77e 100644
> --- a/gcc/tree-eh.c
> +++ b/gcc/tree-eh.c
> @@ -1093,8 +1093,12 @@ lower_try_finally_nofallthru (struct leh_state *state,
> 
>   if (tf->may_throw)
>   {
> +   eh_region prev_ehp_region = state->ehp_region;
> +
> finally = gimple_eh_else_e_body (eh_else);
> +   state->ehp_region = tf->region;
> lower_eh_constructs_1 (state, &finally);
> +   state->ehp_region = prev_ehp_region;
> 
> emit_post_landing_pad (&eh_seq, tf->region);
> gimple_seq_add_seq (&eh_seq, finally);
> @@ -1129,6 +1133,7 @@ lower_try_finally_onedest (struct leh_state *state, 
> struct leh_tf_state *tf)
>   gimple_stmt_iterator gsi;
>   tree finally_label;
>   location_t loc = gimple_location (tf->try_finally_expr);
> +  eh_region prev_ehp_region = state->ehp_region;
> 
>   finally = gimple_try_cleanup (tf->top_p);
>   tf->top_p_seq = gimple_try_eval (tf->top_p);
> @@ -1140,12 +1145,16 @@ lower_try_finally_onedest (struct leh_state *state, 
> struct leh_tf_state *tf)
>   if (x)
> {
>   if (tf->may_throw)
> - finally = gimple_eh_else_e_body (x);
> + {
> +   state->ehp_region = tf->region;
> +   finally = gimple_eh_else_e_body (x);
> + }
>   else
>   finally = gimple_eh_else_n_body (x);
> }
> 
>   lower_eh_constructs_1 (state, &finally);
> +  state->ehp_region = prev_ehp_region;
> 
>   for (gsi = gsi_start (finally); !gsi_end_p (gsi); gsi_next (&gsi))
> {
> @@ -1255,13 +1264,19 @@ lower_try_finally_copy (struct leh_state *state, 
> struct leh_tf_state *tf)
> 
>   if (tf->may_throw)
> {
> +  eh_region prev_ehp_region = state->ehp_region;
> +
>   /* We don't need to copy the EH path of EH_ELSE,
>since it is only emitted once.  */
>   if (eh_else)
> - seq = gimple_eh_else_e_body (eh_else);
> + {
> +   seq = gimple_eh_else_e_body (eh_else);
> +   state->ehp_region = tf->region;
> + }
>   else
>   seq = lower_try_finally_dup_block (finally, state, tf_loc);
>   lower_eh_constructs_1 (state, &seq);
> +  state->ehp_region = prev_ehp_region;
> 
>   emit_post_landing_pad (&eh_seq, tf->region);
>   gimple_seq_add_seq (&eh_seq, seq);
> @@ -1432,8 +1447,12 @@ lower_try_finally_switch (struct leh_state *state, 
> struct leh_tf_state *tf)
> {
>   if (tf->may_throw)
>   {
> +   eh_regio

Re: [PATCH, i386, MPX 1/X] Support of Intel MPX ISA

[Uros Bizjak]

On Fri, Sep 13, 2013 at 4:36 PM, H.J. Lu  wrote:

>>> Did you check the above with x32, where Pmode != word_mode on x86_64?
>>> The inner UNSPEC will be generated in SImode, but the matching pattern
>>>
>>> +(define_insn "*_mk"
>>> +  [(set (match_operand:BND 0 "register_operand" "=B")
>>> +(unspec:BND
>>> +  [(match_operator: 3 "bnd_mem_operator"
>>> +[(unspec:
>>> +   [(match_operand: 1 "register_operand" "r")
>>> +(match_operand: 2 "address_mpx_no_base_operand" "Tb")]
>>> +   UNSPEC_BNDMK_ADDR)])]
>>> +  UNSPEC_BNDMK))]
>>> +  "TARGET_MPX"
>>>
>>> will have inner UNSPEC in DImode, due to:
>>>
>>> +;; Bound modes.
>>> +(define_mode_iterator BND [(BND32 "!TARGET_64BIT") (BND64 "TARGET_64BIT")])
>>> +
>>> +;; Pointer mode corresponding to bound mode.
>>> +(define_mode_attr bnd_ptr [(BND32 "SI") (BND64 "DI")])
>>
>> Currently we do not support MPX instrumentation for x32 and therefore
>> I did not check these expands work correctly for x32. I believe the
>> only possible problem here is BND iterator definition which does not
>> care about x32. Following declaration should make everything work
>> fine:
>>
>
> Since MPX spec doesn't support x32, MPX should be disallowed
> with x32.

OK, please error out when this invalid combination is detected.

Uros.

Re: [PATCH, i386, MPX 1/X] Support of Intel MPX ISA

[Uros Bizjak]

On Fri, Sep 13, 2013 at 12:18 PM, Ilya Enkovich  wrote:
> 2013/9/11 Uros Bizjak :
>> On Tue, Sep 10, 2013 at 1:38 PM, Ilya Enkovich  
>> wrote:
>>> Ping^4
>>>
>>> Could please someone look at this patch? It is mostly i386 target
>>> specific and is basic for further MPX based features.
>>>
>>> Thanks,
>>> Ilya
>>>
>>> 2013/9/2 Ilya Enkovich :
 Ping^3

 Attached is the same patch but against the current trunk.

 2013/8/26 Ilya Enkovich :
> Ping
>
> 2013/8/19 Ilya Enkovich :
>> Ping
>>
>> 2013/8/12 Ilya Enkovich :
>>> 2013/8/10 Joseph S. Myers :
 On Mon, 29 Jul 2013, Ilya Enkovich wrote:

> Hi,
>
> Here is updated version of the patch. I removed redundant
> mode_for_bound, added comments to BOUND_TYPE and added -mmpx option.
> I also fixed bndmk/bndldx/bndstx constraints to avoid incorrect
> register allocation (created two new constraints for that).

 I think the -mmpx option should be documented in invoke.texi, and the 
 new
 machine modes / mode class should be documented in rtl.texi where other
 machine modes / mode classes are documented.  Beyond that, I have no
 comments on this patch revision.

 --
 Joseph S. Myers
 jos...@codesourcery.com
>>>
>>> Thanks! Here is a new revision with -mmpx and new machine modes /
>>> class documented.
>>> Is it good to install to trunk?
>>>
>>> Thanks,
>>> Ilya
>>> ---
>>> 2013-08-12  Ilya Enkovich  
>>>
>>> * mode-classes.def (MODE_BOUND): New.
>>> * tree.def (BOUND_TYPE): New.
>>> * genmodes.c (complete_mode): Support MODE_BOUND.
>>> (BOUND_MODE): New.
>>> (make_bound_mode): New.
>>> * machmode.h (BOUND_MODE_P): New.
>>> * stor-layout.c (int_mode_for_mode): Support MODE_BOUND.
>>> (layout_type): Support BOUND_TYPE.
>>> * tree-pretty-print.c (dump_generic_node): Support BOUND_TYPE.
>>> * tree.c (build_int_cst_wide): Support BOUND_TYPE.
>>> (type_contains_placeholder_1): Likewise.
>>> * tree.h (BOUND_TYPE_P): New.
>>> * varasm.c (output_constant): Support BOUND_TYPE.
>>> * config/i386/constraints.md (B): New.
>>> (Ti): New.
>>> (Tb): New.
>>> * config/i386/i386-modes.def (BND32): New.
>>> (BND64): New.
>>> * config/i386/i386-protos.h (ix86_bnd_prefixed_insn_p): New.
>>> * config/i386/i386.c (isa_opts): Add mmpx.
>>> (regclass_map): Add bound registers.
>>> (dbx_register_map): Likewise.
>>> (dbx64_register_map): Likewise.
>>> (svr4_dbx_register_map): Likewise.
>>> (PTA_MPX): New.
>>> (ix86_option_override_internal) Support MPX ISA.
>>> (ix86_code_end): Add MPX bnd prefix.
>>> (output_set_got): Likewise.
>>> (ix86_output_call_insn): Likewise.
>>> (get_some_local_dynamic_name): Add '!' (MPX bnd) print prefix 
>>> support.
>>> (ix86_print_operand_punct_valid_p): Likewise.
>>> (ix86_print_operand_address): Support UNSPEC_BNDMK_ADDR and
>>> UNSPEC_BNDMK_ADDR.
>>> (ix86_class_likely_spilled_p): Add bound regs support.
>>> (ix86_hard_regno_mode_ok): Likewise.
>>> (x86_order_regs_for_local_alloc): Likewise.
>>> (ix86_bnd_prefixed_insn_p): New.
>>> * config/i386/i386.h (FIRST_PSEUDO_REGISTER): Fix to new value.
>>> (FIXED_REGISTERS): Add bound registers.
>>> (CALL_USED_REGISTERS): Likewise.
>>> (REG_ALLOC_ORDER): Likewise.
>>> (HARD_REGNO_NREGS): Likewise.
>>> (TARGET_MPX): New.
>>> (VALID_BND_REG_MODE): New.
>>> (FIRST_BND_REG): New.
>>> (LAST_BND_REG): New.
>>> (reg_class): Add BND_REGS.
>>> (REG_CLASS_NAMES): Likewise.
>>> (REG_CLASS_CONTENTS): Likewise.
>>> (BND_REGNO_P): New.
>>> (ANY_BND_REG_P): New.
>>> (BNDmode): New.
>>> (HI_REGISTER_NAMES): Add bound registers.
>>> * config/i386/i386.md (UNSPEC_BNDMK): New.
>>> (UNSPEC_BNDMK_ADDR): New.
>>> (UNSPEC_BNDSTX): New.
>>> (UNSPEC_BNDLDX): New.
>>> (UNSPEC_BNDLDX_ADDR): New.
>>> (UNSPEC_BNDCL): New.
>>> (UNSPEC_BNDCU): New.
>>> (UNSPEC_BNDCN): New.
>>> (UNSPEC_MPX_FENCE): New.
>>> (BND0_REG): New.
>>> (BND1_REG): New.
>>> (type): Add mpxmov, mpxmk, mpxchk, mpxld, mpxst.
>>> (length_immediate): Likewise.
>>> (prefix_0f): Likewise.
>>> (memory): Likewise.
>>> (prefix_rep): Check for b

Re: [v3] More noexcept for vectors

[Paolo Carlini]

Hi Marc,

On 09/15/2013 11:12 AM, Marc Glisse wrote:
I had to separate the constructor that takes an allocator from the 
default constructor in debug/profile, since in release the noexcept 
only applies to one of them (and the testsuite asserts that release 
and debug agree on this). An alternative would be to make the release 
vector default constructor conditionally noexcept (depending on the 
allocator). Or to use explicit vector(const Allocator& = Allocator()); 
also in normal mode instead of splitting it in two.
Thanks a lot. Now I'm wondering if we shouldn't really do the latter: 
the issue is, if I remember correctly, in C++11, at variance with C++98, 
allocators aren't necessarily default constructible, thus by explicit 
instantiatiation the user can easily tell whether that constructor is 
split or not. What do you think?


Paolo.

Re: [PATCH] Fix segfault with inlining

[Richard Biener]

On Fri, Sep 13, 2013 at 4:29 PM, Eric Botcazou  wrote:
> Hi,
>
> in Ada parameters can be passed by reference: in this case, the address of the
> argument is directly passed to the callee, which dereferences it to access the
> argument; now Ada also enables -fexceptions -fnon-call-exceptions, which means
> that any pointer dereference is seen as the potential source of an exception,
> which can quickly block the optimizer.  That's why we put TREE_THIS_NOTRAP on
> the dereferences associated with a parameter.
>
> This works fine as long as the function isn't inlined, because it may happen
> that the argument is itself the dereference of a pointer, properly guarded by
> a null check on the pointer.  When the function is inlined, the dereference in
> the caller is replaced with that of the callee, which is TREE_THIS_NOTRAP and
> thus can be moved ahead of the null pointer check, for example by LIM.
>
> The patch ensures that this cannot happen by clearing TREE_THIS_NOTRAP in the
> inliner.  I think that this affects only the Ada compiler in practice.
>
> Tested on x86_64-suse-linux, OK for the mainline?

I've looked at the C++ testcase

int foo (int &x)
{
  try {
return x;
  }
  catch (...)
  {
return 0;
  }
}

which exhibits exactly the behavior you quote - return x is considered throwing
an exception.  The C++ FE doesn't arrange for TREE_THIS_NOTRAP to be
set here (maybe due to this issue you quote?).

Other than that the patch looks reasonable (I suppose you need
is_parameter_of only because as we recursively handle the trees
PARM_DECLs from the destination could already have leaked into
the tree we recurse into?)

Thanks,
Richard.

>
> 2013-09-13  Eric Botcazou  
>
> * tree-inline.h (struct copy_body_data): Add transform_parameter.
> * tree-inline.c (is_parameter_of): New predicate.
> (remap_gimple_op_r): Do not propagate TREE_THIS_NOTRAP on MEM_REF if
> a parameter has been remapped.
> (copy_tree_body_r): Likewise on INDIRECT_REF and MEM_REF.
> (optimize_inline_calls): Initialize transform_parameter.
> (unsave_expr_now): Likewise.
> (copy_gimple_seq_and_replace_locals): Likewise.
> (tree_function_versioning): Likewise.
> (maybe_inline_call_in_expr): Likewise.
>
>
> 2013-09-13  Eric Botcazou  
>
> * gnat.dg/opt27.adb: New test.
> * gnat.dg/opt27_pkg.ad[sb]: New helper.
>
>
> --
> Eric Botcazou

Re: [AArch64] Implement vset_lane intrinsics in C

[James Greenhalgh]

On Fri, Sep 13, 2013 at 10:47:01PM +0100, Andrew Pinski wrote:
> On Fri, Sep 13, 2013 at 11:57 AM, James Greenhalgh
>  wrote:
> > Should return '1' whatever your endianness. Throwing together a quick
> > test case, that is the case for current trunk. Do you have a testcase
> > where this goes wrong?
> 
> I was not thinking of that but rather the definition of lanes in ARM64
> is different than from element due to memory ordering of endian.
> That is lane 0 is element 3 in big-endian.  Or is this only for
> aarch32 where the issue is located?
> 
> Thanks,
> Andrew Pinski

Well, AArch64 has the AArch32 style memory ordering for vectors,
which I think is different from what other big-endian architectures
use, but gives consistent behaviour between vector and array indexing.

So, take the easy case of a byte array

  uint8_t foo [8] = {0, 1, 2, 3, 4, 5, 6, 7}

We would expect both the big and little endian toolchains to lay
this out in memory as:

   0x0 ... 0x8
  | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |

And element 0 would give us '0'. If we take the same array and load it
as a vector with ld1.b, both big and little-endian toolchains would load
it as:

   bit 128 ..   bit 64   bit 0
   lane 16   | lane 7 |   |  lane 0 |
  |. |7   | 6 | 5 | 4 | 3 | 2 | 1 |   0 |

So lane 0 is '0', we're OK so far!

For a short array:

  uint16_t foo [4] = {0x0a0b, 0x1a1b, 0x2a2b, 0x3a3b};

The little endian compiler would lay memory out as:

   0x0 ...0x8
  | 0b | 0a | 1b | 1a | 2b | 2a | 3b | 3a |

And the big endian compiler would lay out memory as:

   0x0 ...0x8
  | 0a | 0b | 1a | 1b | 2a | 2b | 3a | 3b |

In both cases, element 0 is '0x0a0b'. If we load this array as a
vector with ld1.h both big and little-endian compilers will load
the vector as:

   bit 128 ..  bit 64bit 0
   lane 16   | lane 3  |   | lane 0  |
  |. | 3b | 3a | 2b | 2a | 1b | 1a | 0b | 0a |

And lane 0 is '0x0a0b' So we are OK again!

Lanes and elements should match under our model. Which I don't think
is true of other architectures, where I think the whole vector object
is arranged big endian, such that we would need to lay our byte array
out as:

   0x0 ... 0x8
  | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |

For it to be correctly loaded, at which point there is a discrepancy
between element and lane.

But as I say, that is other architectures. AArch64 should be consistent.

Thanks,
James

Re: [AArch64] Implement vset_lane intrinsics in C

[James Greenhalgh]

On Mon, Sep 16, 2013 at 10:29:37AM +0100, James Greenhalgh wrote:
> The little endian compiler would lay memory out as:
> 
>0x0 ...0x8
>   | 0b | 0a | 1b | 1a | 2b | 2a | 3b | 3a |
> 
> And the big endian compiler would lay out memory as:
> 
>0x0 ...0x8
>   | 0a | 0b | 1a | 1b | 2a | 2b | 3a | 3b |
> 
> In both cases, element 0 is '0x0a0b'. If we load this array as a
> vector with ld1.h both big and little-endian compilers will load
> the vector as:
> 
>bit 128 ..  bit 64bit 0
>lane 16   | lane 3  |   | lane 0  |
>   |. | 3b | 3a | 2b | 2a | 1b | 1a | 0b | 0a |
> 

Ugh, I knew I would make a mistake somewhere!

This should, of course, be loaded as:

bit 128 ..  bit 64bit 0
lane 16   | lane 3  |   | lane 0  |
   |. | 3a | 3b | 2a | 2b | 1a | 1b | 0a | 0b |
 
James

Re: [PATCH] Don't always instrument shifts (PR sanitizer/58413)

[Marek Polacek]

On Fri, Sep 13, 2013 at 07:18:24PM +, Joseph S. Myers wrote:
> On Fri, 13 Sep 2013, Marek Polacek wrote:
> 
> > This is kind of fugly, but don't have anything better at the moment.
> > 2013-09-13  Marek Polacek  
> > 
> > PR sanitizer/58413
> > c-family/
> > * c-ubsan.c (ubsan_instrument_shift): Don't instrument
> > an expression if we can prove it is correct.
> 
> Shouldn't the conditions used here for an expression being proved correct 
> match those for instrumentation, i.e. depend on flag_isoc99 and on 
> (cxx_dialect == cxx11 || cxx_dialect == cxx1y)?

I don't think so: for the unsigned case we could restrict it to C
only, but it doesn't hurt doing it even for C++; in the signed case
we care only about C, but we can't restrict it to flag_isoc99 only,
since we need to prove the correctnes even for ANSI C.

Marek

Re: [PATCH] Fix unaligned access generated by IVOPTS

[Richard Biener]

On Fri, Sep 13, 2013 at 4:56 PM, Eric Botcazou  wrote:
> Hi,
>
> in Ada we can have misaligned array components in record types, that is to say
> object with BLKmode whose alignment is lower than that of their type.  In this
> case IVOPTS can generate misaligned TARGET_MEM_REFs, which will lead to an
> unaligned access on strict-alignment platforms.
>
> Tested on SPARC/Solaris, OK for the mainline?

I think that may_be_unaligned_p is just seriously out-dated ... shouldn't it be
sth like

  get_object_alignment_1 (ref, &align, &bitpos);
  if step * BITS_PER_UNIT + bitpos is misaligned
...

or rather all this may_be_unaligned_p stuff should be dropped and IVOPTs
should finally generate proper [TARGET_]MEM_REFs instead?  That is,
we already handle aliasing fine:

  ref = create_mem_ref (&bsi, TREE_TYPE (*use->op_p), &aff,
reference_alias_ptr_type (*use->op_p),
iv, base_hint, data->speed);

so just also handle alignment properly by passing down
get_object_alignment (*use->op_p) and in create_mem_ref_raw
do at the end do the

  if (TYPE_MODE (type) != BLKmode
  && GET_MODE_ALIGNMENT (TYPE_MODE (type)) > align)
type = build_aligned_type (type, align);

for BLKmode we already look at TYPE_ALIGN and as we do not change
the access type(?) either the previous code was already wrong or it was
fine, so there is nothing to do.

So - if you want to give it a try...?

Thanks,
Richard.

> 2013-09-13  Eric Botcazou  
>
> * tree-ssa-loop-ivopts.c (may_be_unaligned_p): Deal with BLKmode as
> the access mode.
>
>
> 2013-09-13  Eric Botcazou  
>
> * gnat.dg/loop_optimization17.adb: New test.
> * gnat.dg/loop_optimization17_pkg.ad[sb]: New helper.
>
>
> --
> Eric Botcazou

Re: New GCC options for loop vectorization

[Richard Biener]

On Fri, Sep 13, 2013 at 6:45 PM, Joseph S. Myers
 wrote:
> On Fri, 13 Sep 2013, Richard Biener wrote:
>
>> @@ -1691,6 +1695,12 @@ common_handle_option (struct gcc_options
>>  opts->x_flag_ipa_reference = false;
>>break;
>>
>> +case OPT_ftree_vectorize:
>> +  if (!opts_set->x_flag_tree_loop_vectorize)
>> + opts->x_flag_tree_loop_vectorize = value;
>> +  if (!opts_set->x_flag_tree_slp_vectorize)
>> + opts->x_flag_tree_slp_vectorize = value;
>> +  break;
>>
>> doesn't look obviously correct.  Does that handle
>
> It looks right to me.  The general principle is that the more specific
> option takes precedence over the less specific one, whatever the order on
> the command line.
>
>>   -ftree-vectorize -fno-tree-loop-vectorize -ftree-vectorize
>
> Should mean -ftree-slp-vectorize.
>
>>   -ftree-loop-vectorize -fno-tree-vectorize
>
> Should mean -ftree-loop-vectorize.
>
>>   -ftree-slp-vectorize -fno-tree-vectorize
>
> Should mean -ftree-slp-vectorize.

Thanks for clarifying.

Richard.

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

Re: New GCC options for loop vectorization

[Richard Biener]

On Fri, Sep 13, 2013 at 6:56 PM, Xinliang David Li  wrote:
> Updated patch implementing the logic that more specific option wins.
>
> Ok for trunk?

@@ -2305,8 +2305,8 @@ omp_max_vf (void)
 {
   if (!optimize
   || optimize_debug
-  || (!flag_tree_vectorize
-  && global_options_set.x_flag_tree_vectorize))
+  || (!flag_tree_loop_vectorize
+  && global_options_set.x_flag_tree_loop_vectorize))
 return 1;

Not sure what is the intent here, but it looks like
-fno-tree-vectorize will no longer disable this.  So it would
need to check (global_options_set.x_flag_tree_vectorize ||
global_options_set.x_flag_tree_loop_vectorize)?  Jakub?

   int vs = targetm.vectorize.autovectorize_vector_sizes ();
@@ -5684,10 +5684,10 @@ expand_omp_simd (struct omp_region *regi
   loop->simduid = OMP_CLAUSE__SIMDUID__DECL (simduid);
   cfun->has_simduid_loops = true;
  }
-  /* If not -fno-tree-vectorize, hint that we want to vectorize
+  /* If not -fno-tree-loop-vectorize, hint that we want to vectorize
  the loop.  */
-  if ((flag_tree_vectorize
-   || !global_options_set.x_flag_tree_vectorize)
+  if ((flag_tree_loop_vectorize
+   || !global_options_set.x_flag_tree_loop_vectorize)
   && loop->safelen > 1)
  {
   loop->force_vect = true;

similar.

-  if (!opts_set->x_flag_tree_vectorize)
- opts->x_flag_tree_vectorize = value;
+  if (!opts_set->x_flag_tree_loop_vectorize)
+ opts->x_flag_tree_loop_vectorize = value;
+  if (!opts_set->x_flag_tree_slp_vectorize)
+ opts->x_flag_tree_slp_vectorize = value;

similar - if I use -fprofile-use -fno-tree-vecotorize you override this choice.
This case should be wrapped in if (!opts_set->x_flag_tree_vectorize)

 @item -ftree-vectorize
 @opindex ftree-vectorize
+Perform vectorization on trees. This flag enables
@option{-ftree-loop-vectorize}
+and @option{-ftree-slp-vectorize} if neither option is explicitly specified.

"if neither option is explicitely specified" doesn't correctly document
-ftree-loop-vectorize -ftree-vectorize behavior, no? (-ftree-slp-vectorize
is still enabled here)

I'm not a native speaker so I cannot suggest a clearer wording here
but maybe just say "if not explicitely specified".

Ok with the -fprofile-use change I suggested and whatever resolution Jakub
suggests and the doc adjustment.

Thanks,
Richard.

> thanks,
>
> David
>
> On Fri, Sep 13, 2013 at 9:48 AM, Xinliang David Li  wrote:
>> Ok -- then my updated patch is wrong then. The implementation in the
>> first version matches the requirement.
>>
>> thanks,
>>
>> David
>>
>>
>> On Fri, Sep 13, 2013 at 9:45 AM, Joseph S. Myers
>>  wrote:
>>> On Fri, 13 Sep 2013, Richard Biener wrote:
>>>
 @@ -1691,6 +1695,12 @@ common_handle_option (struct gcc_options
  opts->x_flag_ipa_reference = false;
break;

 +case OPT_ftree_vectorize:
 +  if (!opts_set->x_flag_tree_loop_vectorize)
 + opts->x_flag_tree_loop_vectorize = value;
 +  if (!opts_set->x_flag_tree_slp_vectorize)
 + opts->x_flag_tree_slp_vectorize = value;
 +  break;

 doesn't look obviously correct.  Does that handle
>>>
>>> It looks right to me.  The general principle is that the more specific
>>> option takes precedence over the less specific one, whatever the order on
>>> the command line.
>>>
   -ftree-vectorize -fno-tree-loop-vectorize -ftree-vectorize
>>>
>>> Should mean -ftree-slp-vectorize.
>>>
   -ftree-loop-vectorize -fno-tree-vectorize
>>>
>>> Should mean -ftree-loop-vectorize.
>>>
   -ftree-slp-vectorize -fno-tree-vectorize
>>>
>>> Should mean -ftree-slp-vectorize.
>>>
>>> --
>>> Joseph S. Myers
>>> jos...@codesourcery.com

[PATCH] Fix FAIL: g++.dg/debug/ra1.C on arm

[Kyrill Tkachov]

Hi all,

The test g++.dg/debug/ra1.C now gives an extra warning on arm:
"warning: width of 'tree_base::code' exceeds its type [enabled by default]"
which causes the test to "fail".

This patch adds -fno-short-enums to it to fix the warning for targets 
with short enums (including arm)


Tested to make sure it now passes on arm-none-eabi.

Ok for trunk?

(CC'ing Richard because he added the test)

[gcc/testsuite/]
2013-09-16  Kyrylo Tkachov  

* g++.dg/debug/ra1.C: Add -fno-short-enums for short_enum targets.diff --git a/gcc/testsuite/g++.dg/debug/ra1.C b/gcc/testsuite/g++.dg/debug/ra1.C
index b6f7bfc..aae7311 100644
--- a/gcc/testsuite/g++.dg/debug/ra1.C
+++ b/gcc/testsuite/g++.dg/debug/ra1.C
@@ -1,4 +1,5 @@
 /* { dg-options "-fcompare-debug" } */
+/* { dg-additional-options "-fno-short-enums" { target { short_enums } } } */
 
 enum signop { SIGNED, UNSIGNED };
 enum tree_code { FOO, BAR };

Re: New GCC options for loop vectorization

[Richard Biener]

On Fri, Sep 13, 2013 at 5:16 PM, Xinliang David Li  wrote:
> On Fri, Sep 13, 2013 at 1:30 AM, Richard Biener
>  wrote:
>> On Thu, Sep 12, 2013 at 10:31 PM, Xinliang David Li  
>> wrote:
>>> Currently -ftree-vectorize turns on both loop and slp vectorizations,
>>> but there is no simple way to turn on loop vectorization alone. The
>>> logic for default O3 setting is also complicated.
>>>
>>> In this patch, two new options are introduced:
>>>
>>> 1) -ftree-loop-vectorize
>>>
>>> This option is used to turn on loop vectorization only. option
>>> -ftree-slp-vectorize also becomes a first class citizen, and no funny
>>> business of Init(2) is needed.  With this change, -ftree-vectorize
>>> becomes a simple alias to -ftree-loop-vectorize +
>>> -ftree-slp-vectorize.
>>>
>>> For instance, to turn on only slp vectorize at O3, the old way is:
>>>
>>>  -O3 -fno-tree-vectorize -ftree-slp-vectorize
>>>
>>> With the new change it becomes:
>>>
>>> -O3 -fno-loop-vectorize
>>>
>>>
>>> To turn on only loop vectorize at O2, the old way is
>>>
>>> -O2 -ftree-vectorize -fno-slp-vectorize
>>>
>>> The new way is
>>>
>>> -O2 -ftree-loop-vectorize
>>>
>>>
>>>
>>> 2) -ftree-vect-loop-peeling
>>>
>>> This option is used to turn on/off loop peeling for alignment.  In the
>>> long run, this should be folded into the cheap cost model proposed by
>>> Richard.  This option is also useful in scenarios where peeling can
>>> introduce runtime problems:
>>> http://gcc.gnu.org/ml/gcc/2005-12/msg00390.html  which happens to be
>>> common in practice.
>>>
>>>
>>>
>>> Patch attached. Compiler boostrapped. Ok after testing?
>>
>> I'd like you to split 1) and 2), mainly because I agree on 1) but not on 2).
>
> Ok. Can you also comment on 2) ?

I think we want to decide how granular we want to control the vectorizer
and using which mechanism.  My cost-model re-org makes
ftree-vect-loop-version a no-op (basically removes it), so 2) looks like
a step backwards in this context.

So, can you summarize what pieces (including versioning) of the vectorizer
you'd want to be able to disable separately?  Just disabling peeling for
alignment may get you into the versioning for alignment path (and thus
an unvectorized loop at runtime).  Also it's know that the alignment peeling
code needs some serious TLC (it's outcome depends on the order of DRs,
the cost model it uses leaves to be desired as we cannot distinguish
between unaligned load and store costs).

Richard.

>>
>> I've stopped a quick try doing 1) myself because
>>
>> @@ -1691,6 +1695,12 @@ common_handle_option (struct gcc_options
>>  opts->x_flag_ipa_reference = false;
>>break;
>>
>> +case OPT_ftree_vectorize:
>> +  if (!opts_set->x_flag_tree_loop_vectorize)
>> + opts->x_flag_tree_loop_vectorize = value;
>> +  if (!opts_set->x_flag_tree_slp_vectorize)
>> + opts->x_flag_tree_slp_vectorize = value;
>> +  break;
>>
>> doesn't look obviously correct.  Does that handle
>>
>>   -ftree-vectorize -fno-tree-loop-vectorize -ftree-vectorize
>>
>> or
>>
>>   -ftree-loop-vectorize -fno-tree-vectorize
>>
>> properly?  Currently at least
>>
>>   -ftree-slp-vectorize -fno-tree-vectorize
>>
>> doesn't "work".
>
>
> Right -- same is true for -fprofile-use option. FDO enables some
> passes, but can not re-enable them if they are flipped off before.
>
>>
>> That said, the option machinery doesn't handle an option being an alias
>> for two other options, so it's mechanism to contract positives/negatives
>> doesn't work here and the override hooks do not work reliably for
>> repeated options.
>>
>> Or am I wrong here?  Should we care at all?  Joseph?
>
> We should probably just document the behavior. Even better, we should
> deprecate the old option.
>
> thanks,
>
> David
>
>>
>> Thanks,
>> Richard.
>>
>>>
>>> thanks,
>>>
>>> David

Re: [PATCH] [vectorizer] Fixing a bug in tree-vect-patterns.c in GCC vectorizer.

[Richard Biener]

On Fri, Sep 13, 2013 at 8:06 PM, Cong Hou  wrote:
> A new test case is added to testsuite/gcc.dg/vect, which will fail
> without this patch and pass with it. Bootstrap also get passed. No
> additional test failure is introduced.
>
> The new test case includes a dot product on two arrays with short and
> int types. The loop will still be vectorized (using punpcklwd on array
> with short type), but should not be recognized as a dot-product
> pattern.

Ok if the patch bootstraps and passes regression tests.

Thanks,
Richard.

>
> thanks,
> Cong
>
>
>
>
>
> Index: gcc/tree-vect-patterns.c
> ===
> --- gcc/tree-vect-patterns.c (revision 202572)
> +++ gcc/tree-vect-patterns.c (working copy)
> @@ -397,7 +397,7 @@ vect_recog_dot_prod_pattern (vec
>|| !promotion)
>  return NULL;
>oprnd00 = gimple_assign_rhs1 (def_stmt);
> -  if (!type_conversion_p (oprnd0, stmt, true, &half_type1, &def_stmt,
> +  if (!type_conversion_p (oprnd1, stmt, true, &half_type1, &def_stmt,
>  &promotion)
>|| !promotion)
>  return NULL;
> Index: gcc/ChangeLog
> ===
> --- gcc/ChangeLog (revision 202572)
> +++ gcc/ChangeLog (working copy)
> @@ -1,3 +1,9 @@
> +2013-09-13  Cong Hou  
> +
> + * tree-vect-patterns.c (vect_recog_dot_prod_pattern): Fix a bug
> + when checking the dot production pattern. The type of rhs operand
> + of multiply is now checked correctly.
> +
>  2013-09-13  Jan Hubicka  
>
>   PR middle-end/58094
> Index: gcc/testsuite/gcc.dg/vect/vect-reduc-dot-s16c.c
> ===
> --- gcc/testsuite/gcc.dg/vect/vect-reduc-dot-s16c.c (revision 0)
> +++ gcc/testsuite/gcc.dg/vect/vect-reduc-dot-s16c.c (revision 0)
> @@ -0,0 +1,73 @@
> +/* { dg-require-effective-target vect_int } */
> +
> +#include 
> +#include "tree-vect.h"
> +
> +#define N 64
> +#define DOT 43680
> +
> +signed short X[N] __attribute__ ((__aligned__(__BIGGEST_ALIGNMENT__)));
> +signed int   Y[N] __attribute__ ((__aligned__(__BIGGEST_ALIGNMENT__)));
> +
> +/* (short, int)->int->int dot product.
> +   Not detected as a dot-product pattern.  */
> +
> +__attribute__ ((noinline)) int
> +foo (int len)
> +{
> +  int i;
> +  int result = 0;
> +
> +  for (i = 0; i < len; i++)
> +{
> +  result += (X[i] * Y[i]);
> +}
> +  return result;
> +}
> +
> +
> +/* (int, short)->int->int dot product.
> +   Not detected as a dot-product pattern.  */
> +
> +__attribute__ ((noinline)) int
> +bar (int len)
> +{
> +  int i;
> +  int result = 0;
> +
> +  for (i = 0; i < len; i++)
> +{
> +  result += (Y[i] * X[i]);
> +}
> +  return result;
> +}
> +
> +int
> +main (void)
> +{
> +  int i;
> +  int dot;
> +
> +  check_vect ();
> +
> +  for (i = 0; i < N; i++)
> +{
> +  X[i] = i;
> +  Y[i] = N - i;
> +  __asm__ volatile ("");
> +}
> +
> +  dot = foo (N);
> +  if (dot != DOT)
> +abort ();
> +
> +  dot = bar (N);
> +  if (dot != DOT)
> +abort ();
> +
> +  return 0;
> +}
> +
> +/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 2 "vect" {
> target vect_unpack } } } */
> +/* { dg-final { cleanup-tree-dump "vect" } } */
> +
> Index: gcc/testsuite/ChangeLog
> ===
> --- gcc/testsuite/ChangeLog (revision 202572)
> +++ gcc/testsuite/ChangeLog (working copy)
> @@ -1,3 +1,9 @@
> +2013-09-13  Cong Hou  
> +
> + * gcc.dg/vect/vect-reduc-dot-s16c.c: Add a test case with dot product
> + on two arrays with short and int types. This should not be recognized
> + as a dot product pattern.
> +
>  2013-09-13  Kai Tietz  
>
>   gcc.target/i386/pr57848.c: New file.
>
>
>
>
> On Wed, Sep 11, 2013 at 6:55 PM, Xinliang David Li  wrote:
>> Can you add a test case to the regression suite?
>>
>> When the type of arguments are unsigned short/unsigned int, GCC does
>> not vectorize the loop anymore -- this is worth a separate bug to
>> track. punpcklwd instruction can be used to do zero extension of the
>> short type.
>>
>> David
>>
>> On Wed, Sep 11, 2013 at 6:16 PM, Cong Hou  wrote:
>>> Hi
>>>
>>> There is a bug in the function vect_recog_dot_prod_pattern() in
>>> tree-vect-patterns.c. This function checks if a loop is of dot
>>> production pattern. Specifically, according to the comment of this
>>> function:
>>>
>>> /*
>>>  Try to find the following pattern:
>>>
>>>  type x_t, y_t;
>>>  TYPE1 prod;
>>>  TYPE2 sum = init;
>>>loop:
>>>  sum_0 = phi 
>>>  S1  x_t = ...
>>>  S2  y_t = ...
>>>  S3  x_T = (TYPE1) x_t;
>>>  S4  y_T = (TYPE1) y_t;
>>>  S5  prod = x_T * y_T;
>>>  [S6  prod = (TYPE2) prod;  #optional]
>>>  S7  sum_1 = prod + sum_0;
>>>
>>>where 'TYPE1' is exactly double the size of type 'type', and
>>> 'TYPE2' is the same size of 'TYPE1' or bigger. This is a special case
>>> of a reduc

Re: New GCC options for loop vectorization

[Jakub Jelinek]

On Mon, Sep 16, 2013 at 12:07:37PM +0200, Richard Biener wrote:
> On Fri, Sep 13, 2013 at 6:56 PM, Xinliang David Li  wrote:
> > Updated patch implementing the logic that more specific option wins.
> >
> > Ok for trunk?
> 
> @@ -2305,8 +2305,8 @@ omp_max_vf (void)
>  {
>if (!optimize
>|| optimize_debug
> -  || (!flag_tree_vectorize
> -  && global_options_set.x_flag_tree_vectorize))
> +  || (!flag_tree_loop_vectorize
> +  && global_options_set.x_flag_tree_loop_vectorize))
>  return 1;
> 
> Not sure what is the intent here, but it looks like
> -fno-tree-vectorize will no longer disable this.  So it would
> need to check (global_options_set.x_flag_tree_vectorize ||
> global_options_set.x_flag_tree_loop_vectorize)?  Jakub?

The point of omp_max_vf is to allow vectorization of simd routines
in the source even without -O3/-Ofast/-ftree-vectorize, as long
as user hasn't requested no vectorization (-fno-tree-vectorize, or
-O0, -Og).  So yes, you'd probably need to change this spot
to check for either global_options_set.x_flag_tree_vectorize
|| global_options_set.x_flag_tree_loop_vectorize, because either
of them meant explicit request to either vectorize or not vectorize loops.
If user has requested vectorization or non-vectorization of loops, then
simd loops just should follow those requests, it is only the default
if there was nothing explicit, which will for now be different between
normal and simd loops, normal loops won't be vectorized, simd loops will be,
because they were specially marked in the source and so it is probably
worthwhile to vectorize them.

Jakub

Re: [PATCH][ubsan] Add VLA bound instrumentation

[Marek Polacek]

On Thu, Sep 12, 2013 at 04:05:48PM +, Joseph S. Myers wrote:
> On Thu, 12 Sep 2013, Joseph S. Myers wrote:
> 
> > (Actually, I believe sizes (in bytes) greater than target PTRDIFF_MAX, not 
> > just SIZE_MAX, should be caught, because pointer subtraction cannot work 
> > reliably with larger objects.  So it's not just when the size or 
> > multiplication overflow size_t, but when they overflow ptrdiff_t.)
> 
> And, to add a bit more to the list of possible ubsan features (is this 
> todo list maintained anywhere?), even if the size is such that operations 
> on the array are in principle defined, it's possible that adjusting the 
> stack pointer by too much may take it into other areas of memory and so 
> cause stack overflow that doesn't get detected by the kernel.  So maybe 
> ubsan should imply -fstack-check or similar.
> 
> Everything about VLA checking - checks on the size being positive and on 
> it not being larger than PTRDIFF_MAX, and on avoiding stack overflow - 
> applies equally to alloca: calls to alloca should also be instrumented.  
> (But I think alloca (0) is valid.)

Problem here is that libubsan doesn't contain appropriate routines for
this VLA/alloca extended checking, it really can only issue "variable
length array bound evaluates to non-positive value", nothing else.

So perhaps reach out to some clang mailing list and try to implement
it first in the libubsan...

Marek

Re: [buildrobot] [PATCH] r202527: ssa / ssanames restructure broke alpha-linux

[Uros Bizjak]

On Mon, Sep 16, 2013 at 11:06 AM, Uros Bizjak  wrote:

>> My Build Robot[1] found this recent commit to break Alpha:
>>
>> * tree-flow.h (FREE_SSANAMES): Move to tree-ssanames.c
>> (SSANAMES, MODIFIED_NORETURN_CALLS, DEFAULT_DEFS, ptr_info_def,
>> num_ssa_names, ssa_name): Move to tree-ssanames.h + prototypes.
>> * tree-flow-inline.h (make_ssa_name, copy_ssa_name, duplicate_ssa_name,
>> make_temp_ssa_name): move to tree-ssanames.h
>> * tree-ssa-alias.h: Move prototype.
>> * tree-ssa.h: Include tree-ssanames.h.
>> * tree-ssanames.c (FREE_SSANAMES): Move to here.
>> * tree-ssanames.h: New.  Move items from tree-flow*.h
>> * Makefile.in (tree-ssanames.h): Add to tree-ssanames.o and GTFILES.
>>
>> See for example this build log:
>> http://toolchain.lug-owl.de/buildbot/showlog.php?id=11663&mode=view
>>
>> I suggest this patch, which fixes an alpha-linux build for me:
>>
>> 2013-09-13  Jan-Benedict Glaw  
>>
>> * config/alpha.c: Include tree-ssa.h.
>
> Thanks, I have tested the patch and commit it to the mainline to
> restore bootstrap.

Richi noted that:

I think you can remove the tree-flow.h include and you need to update the
dependencies in gcc/Makefile.in.

However, we still need tree-flow.h, but instead of tree-ssa.h, we can
include tree-ssanames.h:

I will commit attached  incremental patch, once bootstrap finish.

Uros.

Index: alpha.c
===
--- alpha.c (revision 202621)
+++ alpha.c (working copy)
@@ -50,7 +50,7 @@
 #include "splay-tree.h"
 #include "gimple.h"
 #include "tree-flow.h"
-#include "tree-ssa.h"
+#include "tree-ssanames.h"
 #include "tree-stdarg.h"
 #include "tm-constrs.h"
 #include "df.h"

Re: [PATCH][Resend][tree-optimization] Fix PR58088

[Kyrill Tkachov]

Ping.

On 09/09/13 10:56, Kyrylo Tkachov wrote:

[Resending, since I was away and not pinging it]


Hi all,

In PR58088 the constant folder goes into an infinite recursion and runs out of
stack space because of two conflicting optimisations:
(X * C1) & C2 plays dirty when nested inside an IOR expression like so: ((X *
C1) & C2) | C4. One can undo the other leading to an infinite recursion.

Thanks to Marek for finding the IOR case.

This patch fixes that by checking in the IOR case that the change to C2 will
not conflict with the AND case transformation. Example testcases in the PR on
bugzilla.

This affects both trunk and 4.8 and regresses and bootstraps cleanly on both.

Bootstrapped on x86_64-linux-gnu and tested arm-none-eabi on qemu.

Ok for trunk and 4.8?

Thanks,
Kyrill

2013-09-09  Kyrylo Tkachov  

PR tree-optimization/58088
* fold-const.c (mask_with_trailing_zeros): New function.
(fold_binary_loc): Make sure we don't recurse infinitely
when the X in (X & C1) | C2 is a tree of the form (Y * K1) & K2.
Use mask_with_trailing_zeros where appropriate.


2013-09-09  Kyrylo Tkachov  

PR tree-optimization/58088
* gcc.c-torture/compile/pr58088.c: New test.

Re: [v3] More noexcept for vectors

[Marc Glisse]

On Mon, 16 Sep 2013, Paolo Carlini wrote:


On 09/15/2013 11:12 AM, Marc Glisse wrote:
I had to separate the constructor that takes an allocator from the default 
constructor in debug/profile, since in release the noexcept only applies to 
one of them (and the testsuite asserts that release and debug agree on 
this). An alternative would be to make the release vector default 
constructor conditionally noexcept (depending on the allocator). Or to use 
explicit vector(const Allocator& = Allocator()); also in normal mode 
instead of splitting it in two.
Thanks a lot. Now I'm wondering if we shouldn't really do the latter: the 
issue is, if I remember correctly, in C++11, at variance with C++98, 
allocators aren't necessarily default constructible, thus by explicit 
instantiatiation the user can easily tell whether that constructor is split 
or not. What do you think?


Shouldn't it just be illegal to explicitly instantiate a full class like 
std::vector?


But ok, I'll post that version as soon as I can test it.

--
Marc Glisse

Re: [buildrobot] [PATCH] r202527: ssa / ssanames restructure broke alpha-linux

[Jan-Benedict Glaw]

On Mon, 2013-09-16 13:01:40 +0200, Uros Bizjak  wrote:
> On Mon, Sep 16, 2013 at 11:06 AM, Uros Bizjak  wrote:
> > > My Build Robot[1] found this recent commit to break Alpha:
> 
> I think you can remove the tree-flow.h include and you need to update the
> dependencies in gcc/Makefile.in.
> 
> However, we still need tree-flow.h, but instead of tree-ssa.h, we can
> include tree-ssanames.h:
> 
> I will commit attached  incremental patch, once bootstrap finish.

Please don't forget the dep's in gcc/Makefile.in as mentioned above.

MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
 Signature of:Don't believe in miracles: Rely on them!
 the second  :


signature.asc
Description: Digital signature

Re: [buildrobot] [PATCH] r202527: ssa / ssanames restructure broke alpha-linux

[Richard Biener]

On Mon, 16 Sep 2013, Uros Bizjak wrote:

> On Mon, Sep 16, 2013 at 11:06 AM, Uros Bizjak  wrote:
> 
> >> My Build Robot[1] found this recent commit to break Alpha:
> >>
> >> * tree-flow.h (FREE_SSANAMES): Move to tree-ssanames.c
> >> (SSANAMES, MODIFIED_NORETURN_CALLS, DEFAULT_DEFS, ptr_info_def,
> >> num_ssa_names, ssa_name): Move to tree-ssanames.h + prototypes.
> >> * tree-flow-inline.h (make_ssa_name, copy_ssa_name, duplicate_ssa_name,
> >> make_temp_ssa_name): move to tree-ssanames.h
> >> * tree-ssa-alias.h: Move prototype.
> >> * tree-ssa.h: Include tree-ssanames.h.
> >> * tree-ssanames.c (FREE_SSANAMES): Move to here.
> >> * tree-ssanames.h: New.  Move items from tree-flow*.h
> >> * Makefile.in (tree-ssanames.h): Add to tree-ssanames.o and GTFILES.
> >>
> >> See for example this build log:
> >> http://toolchain.lug-owl.de/buildbot/showlog.php?id=11663&mode=view
> >>
> >> I suggest this patch, which fixes an alpha-linux build for me:
> >>
> >> 2013-09-13  Jan-Benedict Glaw  
> >>
> >> * config/alpha.c: Include tree-ssa.h.
> >
> > Thanks, I have tested the patch and commit it to the mainline to
> > restore bootstrap.
> 
> Richi noted that:
> 
> I think you can remove the tree-flow.h include and you need to update the
> dependencies in gcc/Makefile.in.
> 
> However, we still need tree-flow.h, but instead of tree-ssa.h, we can
> include tree-ssanames.h:

My point was that tree-ssa.h now includes tree-flow.h.  But yes,
making it even more specific works for me as well.

Richard.

> I will commit attached  incremental patch, once bootstrap finish.
> 
> Uros.
> 
> Index: alpha.c
> ===
> --- alpha.c (revision 202621)
> +++ alpha.c (working copy)
> @@ -50,7 +50,7 @@
>  #include "splay-tree.h"
>  #include "gimple.h"
>  #include "tree-flow.h"
> -#include "tree-ssa.h"
> +#include "tree-ssanames.h"
>  #include "tree-stdarg.h"
>  #include "tm-constrs.h"
>  #include "df.h"
> 
> 

-- 
Richard Biener 
SUSE / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
GF: Jeff Hawn, Jennifer Guild, Felix Imend

Re: [buildrobot] [PATCH] r202527: ssa / ssanames restructure broke alpha-linux

[Uros Bizjak]

On Mon, Sep 16, 2013 at 1:36 PM, Jan-Benedict Glaw  wrote:
> On Mon, 2013-09-16 13:01:40 +0200, Uros Bizjak  wrote:
>> On Mon, Sep 16, 2013 at 11:06 AM, Uros Bizjak  wrote:
>> > > My Build Robot[1] found this recent commit to break Alpha:
>>
>> I think you can remove the tree-flow.h include and you need to update the
>> dependencies in gcc/Makefile.in.
>>
>> However, we still need tree-flow.h, but instead of tree-ssa.h, we can
>> include tree-ssanames.h:
>>
>> I will commit attached  incremental patch, once bootstrap finish.
>
> Please don't forget the dep's in gcc/Makefile.in as mentioned above.

Where? I don't see config/alpha.c listed anywhere.

Uros.

Fix can_refer_decl_in_current_unit_p wrt optimized out statics

[Jan Hubicka]

Hi,
this patch solves problem with can_refer_decl_in_current_unit_p always
returning true for static functions.  The devirtualization code can look
up a method in anonymous namespace that has been optimized out due to
lack of references to any of vtables mentioning it.  In this case we need
to make the methods as unreferable that I check by presence of cgraph node
in ipa-devirt.c.

It turns out that this is not enough - fold_ctor_reference constructs cgraph
nodes for functions not seen in symbol table and this may confuse LTO
stremaing.

This patch makes can_refer_decl_in_current_unit_p to do the right thing.
Incrementally I will check if I can now remove the construction of cgraph
nodes in fold_ctor_reference - I think virtual tables are the last case
where reference can come in a way not visible in symbol table and that
I am going to fix soon by making the vtables explicitely represented.
In any case we however should not try to invent refernece to already optimized
out static, so I am fixing it bellow.

I also added DECL_ABSTRACT check - abstrace methods may appear in external
vtables in case they has not been instantiated.  Trying to referr them is
going to fail.

Bootstrapped/regtested x86_64-linux, comitted.

* gimple-fold.c (can_refer_decl_in_current_unit_p): Do not accept
abstract functions; for static functions check the presence
of body.
Index: gimple-fold.c
===
--- gimple-fold.c   (revision 202625)
+++ gimple-fold.c   (working copy)
@@ -60,6 +60,24 @@ can_refer_decl_in_current_unit_p (tree d
   struct cgraph_node *node;
   symtab_node snode;
 
+  if (DECL_ABSTRACT (decl))
+return false;
+
+  /* We are concerned only about static/external vars and functions.  */
+  if ((!TREE_STATIC (decl) && !DECL_EXTERNAL (decl))
+  || (TREE_CODE (decl) != VAR_DECL && TREE_CODE (decl) != FUNCTION_DECL))
+return true;
+
+  /* Static objects can be referred only if they was not optimized out yet.  */
+  if (!TREE_PUBLIC (decl) && !DECL_EXTERNAL (decl))
+{
+  snode = symtab_get_node (decl);
+  if (!snode)
+   return false;
+  node = dyn_cast  (snode);
+  return !node || !node->global.inlined_to;
+}
+
   /* We will later output the initializer, so we can refer to it.
  So we are concerned only when DECL comes from initializer of
  external var.  */
@@ -69,10 +87,6 @@ can_refer_decl_in_current_unit_p (tree d
   || (flag_ltrans
  && symtab_get_node (from_decl)->symbol.in_other_partition))
 return true;
-  /* We are concerned only about static/external vars and functions.  */
-  if ((!TREE_STATIC (decl) && !DECL_EXTERNAL (decl))
-  || (TREE_CODE (decl) != VAR_DECL && TREE_CODE (decl) != FUNCTION_DECL))
-return true;
   /* We are folding reference from external vtable.  The vtable may reffer
  to a symbol keyed to other compilation unit.  The other compilation
  unit may be in separate DSO and the symbol may be hidden.  */

Re: [buildrobot] [PATCH] r202527: ssa / ssanames restructure broke alpha-linux

[Richard Biener]

On Mon, 16 Sep 2013, Uros Bizjak wrote:

> On Mon, Sep 16, 2013 at 1:36 PM, Jan-Benedict Glaw  wrote:
> > On Mon, 2013-09-16 13:01:40 +0200, Uros Bizjak  wrote:
> >> On Mon, Sep 16, 2013 at 11:06 AM, Uros Bizjak  wrote:
> >> > > My Build Robot[1] found this recent commit to break Alpha:
> >>
> >> I think you can remove the tree-flow.h include and you need to update the
> >> dependencies in gcc/Makefile.in.
> >>
> >> However, we still need tree-flow.h, but instead of tree-ssa.h, we can
> >> include tree-ssanames.h:
> >>
> >> I will commit attached  incremental patch, once bootstrap finish.
> >
> > Please don't forget the dep's in gcc/Makefile.in as mentioned above.
> 
> Where? I don't see config/alpha.c listed anywhere.

Must be in one of the fragments in config/ or config/alpha.  For
i386 it's config/i386/t-i386

Richard.

RFA: Testsuite: Add exceptions for MSP430

[Nick Clifton]

Hi Guys,

  The new MSP430 target has a few limitations which show up as
  unexpected failures in the GCC testsuite.  I would like to apply the
  patch below to update target-supports.exp with this information.
  Applying the patch results in a drop of 133 unexpected failures (per
  multilib).

  OK to apply ?

Cheers
  Nick

gcc/testsuite/ChangeLog
2013-09-16  Nick Clifton  

* lib/target-supports.exp (check_effective_target_trampolines):
Add MSP430 to the list of targets that do not support
trampolines.
(check_profiling_available): Add MSP430 to the list of targets
that do not support profiling.
(check_effective_target_tls_runtime): Add MSP430 to the list of
targets that do not support TLS.

Index: gcc/testsuite/lib/target-supports.exp
===
--- gcc/testsuite/lib/target-supports.exp   (revision 202612)
+++ gcc/testsuite/lib/target-supports.exp   (working copy)
@@ -435,9 +435,10 @@
   return 0
 }
 if { [istarget avr-*-*]
+|| [istarget msp430-*-*]
 || [istarget hppa2.0w-hp-hpux11.23]
-   || [istarget hppa64-hp-hpux11.23] } {
-   return 0;   
+|| [istarget hppa64-hp-hpux11.23] } {
+   return 0;
 }
 return 1
 }
@@ -535,6 +536,7 @@
 || [istarget mmix-*-*]
 || [istarget mn10300-*-elf*]
 || [istarget moxie-*-elf*]
+|| [istarget msp430-*-*]
 || [istarget picochip-*-*]
 || [istarget powerpc-*-eabi*]
 || [istarget powerpc-*-elf]
@@ -652,6 +654,11 @@
 # Return 1 if TLS executables can run correctly, 0 otherwise.
 
 proc check_effective_target_tls_runtime {} {
+# MSP430 runtime does not have TLS support, but just
+# running the test below is insufficient to show this.
+if { [istarget msp430-*-*] } {
+   return 0
+}
 return [check_runtime tls_runtime {
__thread int thr = 0;
int main (void) { return thr; }

Re: [v3] More noexcept for vectors

[Jonathan Wakely]

On 15 September 2013 10:12, Marc Glisse wrote:
>
> PR libstdc++/58338
> * include/bits/stl_vector.h
> (_Vector_impl::_Vector_impl(_Tp_alloc_type const&),
> _Vector_impl::_Vector_impl(_Tp_alloc_type&&),
> _Vector_impl::_M_swap_data,
> _Vector_base::_Vector_base(const allocator_type&),
> _Vector_base::_Vector_base(allocator_type&&),
> _Vector_base::_Vector_base(_Vector_base&&),
> vector::vector(const allocator_type&), vector::operator[],
> vector::operator[] const, vector::front, vector::front const,
> vector::back, vector::back const, vector::pop_back,
> vector::_M_erase_at_end): Mark as noexcept.
> (vector::~vector): Remove useless noexcept.

Are you sure the noexcept on the destructors is useless?

A user-defined allocator type could have
is_nothrow_descructible::value==false or
is_nothrow_destructible::value==false, which would alter the
type of is_nothrow_destructible>.

Although the user-defined allocator must not actually throw from its
destructor, it is not required to have a noexcept destructor.
However, since it must not actually throw (irrespective of its
exception spec) we can unconditionally give std::vector a noexcept
destructor.

Re: [v3] More noexcept for vectors

[Marc Glisse]

On Mon, 16 Sep 2013, Jonathan Wakely wrote:


Are you sure the noexcept on the destructors is useless?


Ok, I am putting it back in.

--
Marc Glisse

Re: [Patch, Fortran] PR58356 - fix ICE with finalizer in type extension

[Janus Weil]

> A rather obvious patch.
>
> Build and regtested on x86-64-gnu-linux.
> OK for the trunk?

Looks good to me!

Thanks,
Janus

[x86,PATCH] Simple fix for Atom LEA splitting.

[Yuri Rumyantsev]

Hi All,

Here is 1-line fix which improves Atom performance by better distance
estimation. We got ~20% speedup on one of bench from eembc2.0 with
this fix.

Bootstrapping and regression testing were successful for x86-64.

Is it OK for trunk?

ChangeLog:

2013-09-16  Yuri Rumyantsev  

* config/i386/i386.c (distance_agu_use_in_bb) : Proper initialization
of 'prev' var to get better distance estimation.


patch
Description: Binary data

Re: [PATCH][ubsan] Add VLA bound instrumentation

[Florian Weimer]

On 09/12/2013 06:05 PM, Joseph S. Myers wrote:

On Thu, 12 Sep 2013, Joseph S. Myers wrote:


(Actually, I believe sizes (in bytes) greater than target PTRDIFF_MAX, not
just SIZE_MAX, should be caught, because pointer subtraction cannot work
reliably with larger objects.  So it's not just when the size or
multiplication overflow size_t, but when they overflow ptrdiff_t.)


And, to add a bit more to the list of possible ubsan features (is this
todo list maintained anywhere?), even if the size is such that operations
on the array are in principle defined, it's possible that adjusting the
stack pointer by too much may take it into other areas of memory and so
cause stack overflow that doesn't get detected by the kernel.  So maybe
ubsan should imply -fstack-check or similar.


I have on my to-do list to make -fstack-check production-ready, by 
avoiding unnecessary instrumentation.  My initial experiments weren't 
too successful, but I think it should be possible to greatly reduce its 
overhead.  If everything else fails, the idea is to reuse the Go split 
stack limit and check against that.


The idea is that this would eventually be enabled in production code, 
much like -fstack-protector.


I'm quite busy with other work at the moment, and a patch from me is 
probably months away, though. :-(


--
Florian Weimer / Red Hat Product Security Team

[PATCH] Fix PR58432

[Richard Biener]

The following fixes PR58432 - I forgot to seed partitions from
PHI nodes that have uses on the exit edge.

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

Richard.

2013-09-16  Richard Biener  

PR tree-optimization/58432
* tree-loop-distribution.c (tree_loop_distribution): Also
scan PHIs for outside loop uses and seed a partition from them.

* gcc.dg/pr58432.c: New testcase.

Index: gcc/tree-loop-distribution.c
===
*** gcc/tree-loop-distribution.c(revision 202619)
--- gcc/tree-loop-distribution.c(working copy)
*** tree_loop_distribution (void)
*** 1676,1681 
--- 1676,1692 
for (i = 0; i < loop->num_nodes; ++i)
{
  gimple_stmt_iterator gsi;
+ for (gsi = gsi_start_phis (bbs[i]); !gsi_end_p (gsi); gsi_next (&gsi))
+   {
+ gimple phi = gsi_stmt (gsi);
+ if (virtual_operand_p (gimple_phi_result (phi)))
+   continue;
+ /* Distribute stmts which have defs that are used outside of
+the loop.  */
+ if (!stmt_has_scalar_dependences_outside_loop (loop, phi))
+   continue;
+ work_list.safe_push (phi);
+   }
  for (gsi = gsi_start_bb (bbs[i]); !gsi_end_p (gsi); gsi_next (&gsi))
{
  gimple stmt = gsi_stmt (gsi);
Index: gcc/testsuite/gcc.dg/pr58432.c
===
*** gcc/testsuite/gcc.dg/pr58432.c  (revision 0)
--- gcc/testsuite/gcc.dg/pr58432.c  (working copy)
***
*** 0 
--- 1,17 
+ /* { dg-do compile } */
+ /* { dg-require-profiling "-fprofile-generate" } */
+ /* { dg-options "-O3 -fprofile-generate" } */
+ 
+ struct {
+ int prefix;
+ int dir_idx;
+ } *a;
+ int b;
+ void fn1() {
+ int *c, *d;
+ for (; b; b++)
+   if (d[b]) {
+ c[b] = d[b];
+ a[0].dir_idx = 0;
+   }
+ }

Re: [buildrobot] [PATCH] r202527: ssa / ssanames restructure broke alpha-linux

[Uros Bizjak]

On Mon, Sep 16, 2013 at 1:57 PM, Richard Biener  wrote:

>> >> > > My Build Robot[1] found this recent commit to break Alpha:
>> >>
>> >> I think you can remove the tree-flow.h include and you need to update the
>> >> dependencies in gcc/Makefile.in.
>> >>
>> >> However, we still need tree-flow.h, but instead of tree-ssa.h, we can
>> >> include tree-ssanames.h:
>> >>
>> >> I will commit attached  incremental patch, once bootstrap finish.
>> >
>> > Please don't forget the dep's in gcc/Makefile.in as mentioned above.
>>
>> Where? I don't see config/alpha.c listed anywhere.
>
> Must be in one of the fragments in config/ or config/alpha.  For
> i386 it's config/i386/t-i386

Well, we have a problem here. The dependencies from t-* files are
ignored and the default from generic Makefile.in is used:

>From gcc/Makefile.in:

...
out_file=$(srcdir)/config/@out_file@
out_object_file=@out_object_file@
...
$(out_object_file): $(out_file) $(CONFIG_H) coretypes.h $(TM_H) $(TREE_H) \
   $(RTL_H) $(REGS_H) hard-reg-set.h insn-config.h conditions.h \
   output.h $(INSN_ATTR_H) $(SYSTEM_H) toplev.h $(DIAGNOSTIC_CORE_H) \
   $(TARGET_H) $(LIBFUNCS_H) $(TARGET_DEF_H) $(FUNCTION_H) $(SCHED_INT_H) \
   $(TM_P_H) $(EXPR_H) langhooks.h $(GGC_H) $(OPTABS_H) $(REAL_H) \
   tm-constrs.h $(GIMPLE_H) $(DF_H) cselib.h $(COMMON_TARGET_H) hw-doloop.h \
   regrename.h
$(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) \
$(out_file) $(OUTPUT_OPTION)

These are "universal" dependecies used to compile config/${cpu-type}.o
for any target, no matter what their t- fragment says.

Uros.

Re: RFC - Refactor tree.h

[Diego Novillo]

On Fri, Sep 13, 2013 at 11:25 AM, Diego Novillo  wrote:
> On Fri, Sep 13, 2013 at 11:07 AM, Jakub Jelinek  wrote:
>
>> E.g. today I've noticed you've lost OMP_CLAUSE_LINEAR_NO_COPYIN
>> comment that has been added to tree.h recently, but you haven't
>> actually moved it into tree-core.h.
>
> Sorry about that.  I remember an update conflict, but I thought I had
> incorporated it all.  I will double check and fix.


Done.

 gcc/ChangeLog   |  5 +
 gcc/tree-core.h | 19 +--
 2 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index b9a335a..906d01b 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+2013-09-16  Diego Novillo  
+
+   * tree-core.h: Add missing comment lines from refactoring
+   of tree.h.
+
 2013-09-16  Jan Hubicka  

* gimple-fold.c (can_refer_decl_in_current_unit_p): Do not accept
diff --git a/gcc/tree-core.h b/gcc/tree-core.h
index b1bc56a..69777dc 100644
--- a/gcc/tree-core.h
+++ b/gcc/tree-core.h
@@ -780,6 +780,9 @@ struct GTY(()) tree_base {
OMP_CLAUSE_PRIVATE_DEBUG in
OMP_CLAUSE_PRIVATE

+   OMP_CLAUSE_LINEAR_NO_COPYIN in
+  OMP_CLAUSE_LINEAR
+
TRANSACTION_EXPR_RELAXED in
   TRANSACTION_EXPR

@@ -800,6 +803,9 @@ struct GTY(()) tree_base {
OMP_CLAUSE_PRIVATE_OUTER_REF in
   OMP_CLAUSE_PRIVATE

+   OMP_CLAUSE_LINEAR_NO_COPYOUT in
+  OMP_CLAUSE_LINEAR
+
TYPE_REF_IS_RVALUE in
   REFERENCE_TYPE

@@ -935,6 +941,9 @@ struct GTY(()) tree_base {

DECL_NONLOCAL_FRAME in
   VAR_DECL
+
+   TYPE_FINAL_P in
+  RECORD_TYPE, UNION_TYPE and QUAL_UNION_TYPE
 */

 struct GTY(()) tree_typed {
@@ -1197,8 +1206,7 @@ struct GTY(()) tree_decl_common {
   unsigned lang_flag_7 : 1;
   unsigned lang_flag_8 : 1;

-  /* In LABEL_DECL, this is DECL_ERROR_ISSUED.
- In VAR_DECL and PARM_DECL, this is DECL_REGISTER.  */
+  /* In VAR_DECL and PARM_DECL, this is DECL_REGISTER.  */
   unsigned decl_flag_0 : 1;
   /* In FIELD_DECL, this is DECL_BIT_FIELD
  In VAR_DECL and FUNCTION_DECL, this is DECL_EXTERNAL.
@@ -1403,6 +1411,9 @@ struct GTY(()) tree_statement_list
   struct tree_statement_list_node *tail;
 };

+
+/* Optimization options used by a function.  */
+
 struct GTY(()) tree_optimization_option {
   struct tree_common common;

@@ -1418,6 +1429,8 @@ struct GTY(()) tree_optimization_option {
   struct target_optabs *GTY ((skip)) base_optabs;
 };

+/* Target options used by a function.  */
+
 struct GTY(()) tree_target_option {
   struct tree_common common;

@@ -1563,6 +1576,8 @@ struct GTY(()) tree_map_base {
   tree from;
 };

+/* Map from a tree to another tree.  */
+
 struct GTY(()) tree_map {
   struct tree_map_base base;
   unsigned int hash;
--
1.8.4

Re: RFC - Refactor tree.h

[Jakub Jelinek]

On Mon, Sep 16, 2013 at 09:39:27AM -0400, Diego Novillo wrote:
> On Fri, Sep 13, 2013 at 11:25 AM, Diego Novillo  wrote:
> > On Fri, Sep 13, 2013 at 11:07 AM, Jakub Jelinek  wrote:
> >
> >> E.g. today I've noticed you've lost OMP_CLAUSE_LINEAR_NO_COPYIN
> >> comment that has been added to tree.h recently, but you haven't
> >> actually moved it into tree-core.h.
> >
> > Sorry about that.  I remember an update conflict, but I thought I had
> > incorporated it all.  I will double check and fix.
> 
> 
> Done.

Thanks.

Jakub

Re: [x86,PATCH] Simple fix for Atom LEA splitting.

[Uros Bizjak]

On Mon, Sep 16, 2013 at 2:50 PM, Yuri Rumyantsev  wrote:
> Hi All,
>
> Here is 1-line fix which improves Atom performance by better distance
> estimation. We got ~20% speedup on one of bench from eembc2.0 with
> this fix.
>
> Bootstrapping and regression testing were successful for x86-64.
>
> Is it OK for trunk?
>
> ChangeLog:
>
> 2013-09-16  Yuri Rumyantsev  
>
> * config/i386/i386.c (distance_agu_use_in_bb) : Proper initialization
> of 'prev' var to get better distance estimation.

Please rewrite this part to:

  basic_block bb = NULL;
  rtx next = start;
  rtx prev = NULL;

  if (start != NULL_RTX)
{
  bb = BLOCK_FOR_INSN (start);
  if (start != BB_HEAD (bb))
prev = insn;
}

A comment would be also nice here. It took me quite some time to
decipher the code.

OK with these changes.

Thanks,
Uros.

Re: [ping][PATCH][1 of 2] Add value range info to SSA_NAME for zero sign extension elimination in RTL

[Richard Biener]

On Mon, 16 Sep 2013, Kugan wrote:

> Hi,
> 
> Updated the patch to the latest changes in trunk that splits tree.h. I also
> noticed an error in printing double_int and fixed it.
> 
> Is this OK?

   print_gimple_stmt (dump_file, stmt, 0,
-TDF_SLIM | (dump_flags & TDF_LINENO));
+TDF_SLIM | TDF_RANGE | (dump_flags & 
TDF_LINENO));

this should be (dump_flags & (TDF_LINENO|TDF_RANGE)) do not always
dump range info.  I'd have simply re-used TDF_ALIAS (and interpret
it as SSA annotation info), adding -range in dump file modifiers
is ok with me.

+static void
+print_double_int (pretty_printer *buffer, double_int cst)
+{
+  tree node = double_int_to_tree (integer_type_node, cst);
+  if (TREE_INT_CST_HIGH (node) == 0)
+pp_printf (buffer, HOST_WIDE_INT_PRINT_UNSIGNED, TREE_INT_CST_LOW 
(node));
+  else if (TREE_INT_CST_HIGH (node) == -1
+   && TREE_INT_CST_LOW (node) != 0)
+pp_printf (buffer, "-" HOST_WIDE_INT_PRINT_UNSIGNED,
+   -TREE_INT_CST_LOW (node));
+  else
+sprintf (pp_buffer (buffer)->digit_buffer,
+ HOST_WIDE_INT_PRINT_DOUBLE_HEX,
+ (unsigned HOST_WIDE_INT) TREE_INT_CST_HIGH (node),
+ (unsigned HOST_WIDE_INT) TREE_INT_CST_LOW (node));

using sprintf here looks like a layering violation to me.  You
probably want to factor out code from the INTEGER_CST handling
of tree-pretty-print.c:dump_generic_node into a pp_double_int
function in pretty-print.[ch] instead.

@@ -1628,6 +1647,27 @@ dump_gimple_phi (pretty_printer *buffer, gimple 
phi, int spc, int flags)
   pp_string (buffer, "# ");
 }

+  if ((flags & TDF_RANGE)
+  && !POINTER_TYPE_P (TREE_TYPE (lhs))
+  && SSA_NAME_RANGE_INFO (lhs))
+{
+  double_int min, max;
+  value_range_type range_type;

I realize the scheme is pre-existing but can you try factoring
out the dumping of SSA_NAME_PTR_INFO / SSA_NAME_RANGE_INFO into
a separate routine that can be shared by dump_gimple_phi and
pp_gimple_stmt_1?

+get_range_info (tree name, double_int &min, double_int &max,
+enum value_range_type &range_type)
+{
+  gcc_assert (!POINTER_TYPE_P (TREE_TYPE (name)));
+  gcc_assert (TREE_CODE (name) == SSA_NAME);
+  range_info_def *ri = SSA_NAME_RANGE_INFO (name);

the TREE_CODE (name) == SSA_NAME assert is redundant with the
tree-checking performed by SSA_NAME_RANGE_INFO.  Likewise in
the other functions.

+void
+get_range_info (tree name, double_int &min, double_int &max,
+enum value_range_type &range_type)

I'm not sure we want to use references.  Well - first time.

+  /* If min > max, it is  VR_ANTI_RANGE.  */
+  if (ri->min.scmp (ri->max) == 1)
+{

I think that's wrong and needs to be conditional on TYPE_UNSIGNED
of the SSA name.

+  else if (vr_value[i]->type == VR_ANTI_RANGE)
+{
+  /* VR_ANTI_RANGE ~[min, max] is encoded compactly as
+ [max + 1, min - 1] without additional attributes.
+ When min value > max value, we know that it is
+ VR_ANTI_RANGE; it is VR_RANGE othewise.  */
+  set_range_info (name,
+  tree_to_double_int (vr_value[i]->max)
+  + double_int_one,
+  tree_to_double_int (vr_value[i]->min)
+  - double_int_one);

there is a complication for when max + 1 or min - 1 overflow - those
should be non-canonical ranges I think, but double-check this
(check set_and_canonicalize_value_range).

+/* Type of value ranges.  See value_range_d In tree-vrp.c for a
+   description of these types.  */
+enum value_range_type { VR_UNDEFINED, VR_RANGE, VR_ANTI_RANGE, VR_VARYING 
};
+
+/* Sets the value range to SSA.  */
+void set_range_info (tree ssa, double_int min, double_int max);
+/* Gets the value range from SSA.  */
+void get_range_info (tree name, double_int &min, double_int &max,
+ enum value_range_type &range_type);

put these into tree-ssanames.h please, likewise struct GTY (()) 
range_info_def - this is where the ptr-info stuff went very recently.

Thanks,
Richard.



> Thanks,
> Kugan
> 
> 
> +2013-09-12  Kugan Vivekanandarajah  
> +
> + * cfgexpand.c (maybe_dump_rtl_for_gimple_stmt) : Add range to dump.
> + * gimple-pretty-print.c (print_double_int) : New function.
> + * gimple-pretty-print.c (dump_gimple_phi) : Dump range info.
> + * (pp_gimple_stmt_1) : Likewise.
> + * tree-ssa-alias.c (dump_alias_info) : Check pointer type.
> + * tree-ssa-copy.c (fini_copy_prop) : Check pointer type and copy
> + range info.
> + * tree-ssanames.c (make_ssa_name_fn) : Check pointer type in
> + initialize.
> + * (set_range_info) : New function.
> + * (get_range_info) : Likewise.
> + * (duplicate_ssa_name_range_info) : Likewise.
> + * (duplicate_ssa_name_fn) : Check pointer type and call correct
> + duplicate function.
> + 

Re: [buildrobot] [PATCH] r202527: ssa / ssanames restructure broke alpha-linux

[Michael Matz]

Hi,

On Mon, 16 Sep 2013, Uros Bizjak wrote:

> >> Where? I don't see config/alpha.c listed anywhere.
> >
> > Must be in one of the fragments in config/ or config/alpha.  For
> > i386 it's config/i386/t-i386
> 
> Well, we have a problem here. The dependencies from t-* files are
> ignored

Why do you think so?  The t-* frags are includes via
...
tmake_file=...$(srcdir)/config/i386/t-i386
...
ifneq ($(tmake_file),)
include $(tmake_file)
endif
...

It's just that there's no t-alpha frag yet.

> These are "universal" dependecies used to compile config/${cpu-type}.o 
> for any target, no matter what their t- fragment says.

The universal deps are amended by the t- frags, as above.


Ciao,
Michael.

Re: [x86,PATCH] Simple fix for Atom LEA splitting.

[Yuri Rumyantsev]

Uros,

Thanks for your review.

I attached modified patch - is it OK for you now?

2013/9/16 Uros Bizjak :
> On Mon, Sep 16, 2013 at 2:50 PM, Yuri Rumyantsev  wrote:
>> Hi All,
>>
>> Here is 1-line fix which improves Atom performance by better distance
>> estimation. We got ~20% speedup on one of bench from eembc2.0 with
>> this fix.
>>
>> Bootstrapping and regression testing were successful for x86-64.
>>
>> Is it OK for trunk?
>>
>> ChangeLog:
>>
>> 2013-09-16  Yuri Rumyantsev  
>>
>> * config/i386/i386.c (distance_agu_use_in_bb) : Proper initialization
>> of 'prev' var to get better distance estimation.
>
> Please rewrite this part to:
>
>   basic_block bb = NULL;
>   rtx next = start;
>   rtx prev = NULL;
>
>   if (start != NULL_RTX)
> {
>   bb = BLOCK_FOR_INSN (start);
>   if (start != BB_HEAD (bb))
> prev = insn;
> }
>
> A comment would be also nice here. It took me quite some time to
> decipher the code.
>
> OK with these changes.
>
> Thanks,
> Uros.


patch1
Description: Binary data

Re: [buildrobot] [PATCH] r202527: ssa / ssanames restructure broke alpha-linux

[Andrew MacLeod]

On 09/16/2013 05:05 AM, Richard Biener wrote:

On Sat, Sep 14, 2013 at 12:41 PM, Jan-Benedict Glaw  wrote:

Hi!

My Build Robot[1] found this recent commit to break Alpha:

 * tree-flow.h (FREE_SSANAMES): Move to tree-ssanames.c
 (SSANAMES, MODIFIED_NORETURN_CALLS, DEFAULT_DEFS, ptr_info_def,
 num_ssa_names, ssa_name): Move to tree-ssanames.h + prototypes.
 * tree-flow-inline.h (make_ssa_name, copy_ssa_name, duplicate_ssa_name,
 make_temp_ssa_name): move to tree-ssanames.h
 * tree-ssa-alias.h: Move prototype.
 * tree-ssa.h: Include tree-ssanames.h.
 * tree-ssanames.c (FREE_SSANAMES): Move to here.
 * tree-ssanames.h: New.  Move items from tree-flow*.h
 * Makefile.in (tree-ssanames.h): Add to tree-ssanames.o and GTFILES.

See for example this build log:
http://toolchain.lug-owl.de/buildbot/showlog.php?id=11663&mode=view

I suggest this patch, which fixes an alpha-linux build for me:

I think you can remove the tree-flow.h include and you need to update the
dependencies in gcc/Makefile.in.

Richard.


of course... :-P

I see rs6000.c and i386.c  both use tree-flow.h as well.  I will have to 
see what they are actually pulling in from that file so I don't break 
those eventually too.


Andrew

Andrew

Re: [buildrobot] [PATCH] r202527: ssa / ssanames restructure broke alpha-linux

[Uros Bizjak]

On Mon, Sep 16, 2013 at 4:20 PM, Michael Matz  wrote:

>> >> Where? I don't see config/alpha.c listed anywhere.
>> >
>> > Must be in one of the fragments in config/ or config/alpha.  For
>> > i386 it's config/i386/t-i386
>>
>> Well, we have a problem here. The dependencies from t-* files are
>> ignored
>
> Why do you think so?  The t-* frags are includes via
> ...
> tmake_file=...$(srcdir)/config/i386/t-i386
> ...
> ifneq ($(tmake_file),)
> include $(tmake_file)
> endif
> ...
>
> It's just that there's no t-alpha frag yet.

No, there is no problem with includes. The *dependencies* from t-*
files are missing.

Please compare i386.o dependencies from config/i386/t-i386 with
$(out_object_file) from the resulting Makefile in the build directory.
They are NOT the same, the dependencies in the Makefile from the build
directory for $(out_object_file) AKA i386.o are copied verbatim from
Makefile.in.

>> These are "universal" dependecies used to compile config/${cpu-type}.o
>> for any target, no matter what their t- fragment says.
>
> The universal deps are amended by the t- frags, as above.

No, they are copied directly from Makefile.in.

Uros.

Re: [x86,PATCH] Simple fix for Atom LEA splitting.

[Uros Bizjak]

On Mon, Sep 16, 2013 at 4:26 PM, Yuri Rumyantsev  wrote:

> Thanks for your review.
>
> I attached modified patch - is it OK for you now?

I can't understand the comment, so perhaps a native English speaking
person could help here.

The patch with a fixed comment is OK otherwise.

Thanks,
Uros.

Re: [patch 1/2] tree-flow.h restructuring

[Tom Tromey]

Richard> Where's that automatic dependency patch blocked ...

No build machinery maintainer has reviewed it.

Tom

Re: [patch] Cleanup tree-ssa-ter.c exports

[Andrew MacLeod]

On 09/16/2013 04:55 AM, Richard Biener wrote:

On Fri, Sep 13, 2013 at 9:15 PM, Andrew MacLeod  wrote:



OK, a slightly different take..
I realized that I should be adding tree-outof-ssa.h to handle the 3 exports
from tree-outof-ssa.c that are in ssaexpand.h...  In fact, by far the most
sensible thing to do is to simply rename tree-outof-ssa.c to ssaexpand.c.
This actually resolves a number of warts... And is_replaceable_p() very
naturally fits in ssaexpand.c now...

what do you think of this option? :-)  and svn rename preserves all the
tree-outof-ssa.c history...

I don't like the new name for tree-outof-ssa.c, it matches less to its contents.

I'd say either keep ssaexpand.h and tree-outof-ssa.c as-is or rename
ssaexpand.h to tree-outof-ssa.h.  I prefer the latter.


I as well.  ssaexpand.h ->tree-outof-ssa.h it is.



The rest of the changes look ok to me, but watch out for odd whitespace
changes:

+static inline bool
+ter_is_replaceable_p (gimple stmt)
+{
+
+  if (ssa_is_replaceable_p (stmt))

spurious vertical space.



bah, where'd that come from :-P.

I'll check this approach in  after  running it through the gauntlet again.

Andrew

Re: [PATCH v3 01/18] clean up SHLIB so subshells are not needed

[Paolo Bonzini]

Il 20/08/2013 15:58, Tom Tromey ha scritto:
> This changes the handling of SHLIB so that it is inlined into
> DRIVER_DEFINES.  This is ok because SHLIB is defined in a Makefile
> fragment that is included by the generated Makefile.
> 
> The rationale for this is that it simplifies some .o targets, so that
> we can share more code.
> 
>   * Makefile.in (DRIVER_DEFINES): Use $(and), not shell code,
>   to add -DENABLE_SHARED_LIBGCC.
>   (gcc.o): Don't use subshell.
> 
>   * Make-lang.in (c/gccspec.o): Don't use subshell.
> 
>   * Make-lang.in (g++spec.o): Don't use subshell.
> 
>   * Make-lang.in (gfortranspec.o): Don't use subshell.
> 
>   * Make-lang.in (gospec.o): Don't use subshell.
> 
>   * Make-lang.in (jvspec.o): Don't use subshell.
> ---
>  gcc/Makefile.in  | 5 ++---
>  gcc/c/Make-lang.in   | 3 +--
>  gcc/cp/Make-lang.in  | 3 +--
>  gcc/fortran/Make-lang.in | 3 +--
>  gcc/go/Make-lang.in  | 3 +--
>  gcc/java/Make-lang.in| 3 +--
>  6 files changed, 7 insertions(+), 13 deletions(-)
> 
> diff --git a/gcc/Makefile.in b/gcc/Makefile.in
> index 704ca10..8d2fd23 100644
> --- a/gcc/Makefile.in
> +++ b/gcc/Makefile.in
> @@ -2059,16 +2059,15 @@ DRIVER_DEFINES = \
>-DTOOLDIR_BASE_PREFIX=\"$(libsubdir_to_prefix)$(prefix_to_exec_prefix)\" \
>@TARGET_SYSTEM_ROOT_DEFINE@ \
>$(VALGRIND_DRIVER_DEFINES) \
> -  `test "X$${SHLIB}" = "X" || test "@enable_shared@" != "yes" || echo 
> "-DENABLE_SHARED_LIBGCC"` \
> +  $(and $(SHLIB),$(filter yes,@enable_shared@),-DENABLE_SHARED_LIBGCC) \
>-DCONFIGURE_SPECS="\"@CONFIGURE_SPECS@\""
>  
>  gcc.o: gcc.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) intl.h multilib.h \
>  Makefile $(lang_specs_files) specs.h prefix.h $(GCC_H) $(FLAGS_H) \
>  configargs.h $(OBSTACK_H) $(OPTS_H) $(DIAGNOSTIC_H) $(VEC_H) $(PARAMS_H)
> - (SHLIB='$(SHLIB)'; \
>   $(COMPILER) $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) \
>$(DRIVER_DEFINES) \
> -  -c $(srcdir)/gcc.c $(OUTPUT_OPTION))
> +  -c $(srcdir)/gcc.c $(OUTPUT_OPTION)
>  
>  specs.h : s-specs ; @true
>  s-specs : Makefile
> diff --git a/gcc/c/Make-lang.in b/gcc/c/Make-lang.in
> index 1161742..86deb1d 100644
> --- a/gcc/c/Make-lang.in
> +++ b/gcc/c/Make-lang.in
> @@ -46,10 +46,9 @@ c: cc1$(exeext)
>  # is to cc1 as e.g. g++ is to cc1plus, or gfortran is to f951).
>  c/gccspec.o: c/gccspec.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) 
> $(GCC_H) \
>  $(OPTS_H)
> - (SHLIB='$(SHLIB)'; \
>   $(COMPILER) $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) \
>$(DRIVER_DEFINES) \
> -  -c $(srcdir)/c/gccspec.c $(OUTPUT_OPTION))
> +  -c $(srcdir)/c/gccspec.c $(OUTPUT_OPTION)
>  
>  # The C compiler itself.
>  
> diff --git a/gcc/cp/Make-lang.in b/gcc/cp/Make-lang.in
> index 2c1774f..263daa5 100644
> --- a/gcc/cp/Make-lang.in
> +++ b/gcc/cp/Make-lang.in
> @@ -53,9 +53,8 @@ c++: cc1plus$(exeext)
>  
>  g++spec.o: $(srcdir)/cp/g++spec.c $(SYSTEM_H) coretypes.h $(TM_H) $(GCC_H) \
>  $(CONFIG_H) $(OPTS_H)
> - (SHLIB='$(SHLIB)'; \
>   $(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) $(DRIVER_DEFINES) \
> - $(INCLUDES) $(srcdir)/cp/g++spec.c)
> + $(INCLUDES) $(srcdir)/cp/g++spec.c
>  
>  # Create the compiler driver for g++.
>  GXX_OBJS = $(GCC_OBJS) g++spec.o
> diff --git a/gcc/fortran/Make-lang.in b/gcc/fortran/Make-lang.in
> index ee70423..035a1d5 100644
> --- a/gcc/fortran/Make-lang.in
> +++ b/gcc/fortran/Make-lang.in
> @@ -78,9 +78,8 @@ fortran: f951$(exeext)
>  
>  gfortranspec.o: $(srcdir)/fortran/gfortranspec.c $(SYSTEM_H) $(TM_H) 
> $(GCC_H) \
>   $(CONFIG_H) coretypes.h intl.h $(OPTS_H)
> - (SHLIB='$(SHLIB)'; \
>   $(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) $(DRIVER_DEFINES) \
> - $(INCLUDES) $(srcdir)/fortran/gfortranspec.c)
> + $(INCLUDES) $(srcdir)/fortran/gfortranspec.c
>  
>  # Create the compiler driver gfortran.
>  GFORTRAN_D_OBJS = $(GCC_OBJS) gfortranspec.o
> diff --git a/gcc/go/Make-lang.in b/gcc/go/Make-lang.in
> index 3cb18d6..015ed7a 100644
> --- a/gcc/go/Make-lang.in
> +++ b/gcc/go/Make-lang.in
> @@ -32,9 +32,8 @@ go: go1$(exeext)
>  
>  gospec.o: $(srcdir)/go/gospec.c $(SYSTEM_H) coretypes.h $(TM_H) $(GCC_H) \
>  $(CONFIG_H) opts.h
> - (SHLIB='$(SHLIB)'; \
>   $(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) $(DRIVER_DEFINES) \
> - $(INCLUDES) $(srcdir)/go/gospec.c)
> + $(INCLUDES) $(srcdir)/go/gospec.c
>  
>  GCCGO_OBJS = $(GCC_OBJS) gospec.o
>  gccgo$(exeext): $(GCCGO_OBJS) $(EXTRA_GCC_OBJS) libcommon-target.a $(LIBDEPS)
> diff --git a/gcc/java/Make-lang.in b/gcc/java/Make-lang.in
> index 8a6210f..078f6d4 100644
> --- a/gcc/java/Make-lang.in
> +++ b/gcc/java/Make-lang.in
> @@ -57,9 +57,8 @@ JAVA_TARGET_INDEPENDENT_BIN_TOOLS = jcf-dump
>  
>  jvspec.o: $(srcdir)/java/jvspec.c $(SYSTEM_H) coretypes.h $(TM_H) \
>$(GCC_H) $(CONFIG_H) java/jcf.h java/javaop.h $(OPTS_H)
> - (SHLIB='$(SHLIB)'; \
>   $(COMPILER) -c $(ALL_COMPILE

patch to fix PR58418

[Vladimir Makarov]

The following patch fixes

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58418

The patch also fixes a duplicated bug PR58419.

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

Committed as rev. 202630.

2013-09-16  Vladimir Makarov  

PR middle-end/58418
* lra-constraints.c (undo_optional_reloads): Consider all optional
reload even if it did not get a hard reg.

2013-09-16  Vladimir Makarov  

* gcc.target/i386/pr58418.c: New.

Index: lra-constraints.c
===
--- lra-constraints.c   (revision 202626)
+++ lra-constraints.c   (working copy)
@@ -5454,43 +5454,42 @@ undo_optional_reloads (void)
   bitmap_initialize (&removed_optional_reload_pseudos, ®_obstack);
   bitmap_copy (&removed_optional_reload_pseudos, &lra_optional_reload_pseudos);
   EXECUTE_IF_SET_IN_BITMAP (&lra_optional_reload_pseudos, 0, regno, bi)
-if (reg_renumber[regno] >= 0)
-  {
-   keep_p = false;
-   if (reg_renumber[lra_reg_info[regno].restore_regno] >= 0)
- /* If the original pseudo changed its allocation, just
-removing the optional pseudo is dangerous as the original
-pseudo will have longer live range.  */
- keep_p = true;
-   else
- EXECUTE_IF_SET_IN_BITMAP (&lra_reg_info[regno].insn_bitmap, 0, uid, 
bi2)
-   {
- insn = lra_insn_recog_data[uid]->insn;
- if ((set = single_set (insn)) == NULL_RTX)
-   continue;
- src = SET_SRC (set);
- dest = SET_DEST (set);
- if (! REG_P (src) || ! REG_P (dest))
-   continue;
- if (REGNO (dest) == regno
- /* Ignore insn for optional reloads itself.  */
- && lra_reg_info[regno].restore_regno != (int) REGNO (src)
- /* Check only inheritance on last inheritance pass.  */
- && (int) REGNO (src) >= new_regno_start
- /* Check that the optional reload was inherited.  */
- && bitmap_bit_p (&lra_inheritance_pseudos, REGNO (src)))
-   {
- keep_p = true;
- break;
-   }
-   }
-   if (keep_p)
+{
+  keep_p = false;
+  if (reg_renumber[lra_reg_info[regno].restore_regno] >= 0)
+   /* If the original pseudo changed its allocation, just
+  removing the optional pseudo is dangerous as the original
+  pseudo will have longer live range.  */
+   keep_p = true;
+  else if (reg_renumber[regno] >= 0)
+   EXECUTE_IF_SET_IN_BITMAP (&lra_reg_info[regno].insn_bitmap, 0, uid, bi2)
  {
-   bitmap_clear_bit (&removed_optional_reload_pseudos, regno);
-   if (lra_dump_file != NULL)
- fprintf (lra_dump_file, "Keep optional reload reg %d\n", regno);
+   insn = lra_insn_recog_data[uid]->insn;
+   if ((set = single_set (insn)) == NULL_RTX)
+ continue;
+   src = SET_SRC (set);
+   dest = SET_DEST (set);
+   if (! REG_P (src) || ! REG_P (dest))
+ continue;
+   if (REGNO (dest) == regno
+   /* Ignore insn for optional reloads itself.  */
+   && lra_reg_info[regno].restore_regno != (int) REGNO (src)
+   /* Check only inheritance on last inheritance pass.  */
+   && (int) REGNO (src) >= new_regno_start
+   /* Check that the optional reload was inherited.  */
+   && bitmap_bit_p (&lra_inheritance_pseudos, REGNO (src)))
+ {
+   keep_p = true;
+   break;
+ }
  }
-  }
+  if (keep_p)
+   {
+ bitmap_clear_bit (&removed_optional_reload_pseudos, regno);
+ if (lra_dump_file != NULL)
+   fprintf (lra_dump_file, "Keep optional reload reg %d\n", regno);
+   }
+}
   change_p = ! bitmap_empty_p (&removed_optional_reload_pseudos);
   bitmap_initialize (&insn_bitmap, ®_obstack);
   EXECUTE_IF_SET_IN_BITMAP (&removed_optional_reload_pseudos, 0, regno, bi)
Index: testsuite/gcc.target/i386/pr58418.c
===
--- testsuite/gcc.target/i386/pr58418.c (revision 0)
+++ testsuite/gcc.target/i386/pr58418.c (working copy)
@@ -0,0 +1,32 @@
+/* { dg-do run } */
+/* { dg-options "-O2" } */
+
+extern void abort (void);
+int a, b, *c = &b, d = -1, e, f, *g, *h = &f, **i = &g, j;
+
+unsigned int
+foo (unsigned int p)
+{
+  return p == 0 ? 0 : 1 / p;
+}
+
+static int *
+bar ()
+{
+  *c = *h = foo (d) & (-9 < d);
+  for (e = 0; e; e++)
+;
+  return 0;
+}
+
+int
+main ()
+{
+  for (; j; j++)
+for (;; a--)
+  ;
+  *i = bar ();
+  if (f != 0)
+abort ();
+  return 0;
+}

Re: [patch 1/2] tree-flow.h restructuring

[Paolo Bonzini]

Il 16/09/2013 16:39, Tom Tromey ha scritto:
> Richard> Where's that automatic dependency patch blocked ...
> 
> No build machinery maintainer has reviewed it.

/me gets out of coma...

Someone said "automatic dependency" and "build machinery maintainer" in
the same sentence???

Paolo

Re: [PATCH v3 03/18] move generated_files order-only dependency later

[Paolo Bonzini]

Il 20/08/2013 15:59, Tom Tromey ha scritto:
> There is an order-only dependency in gcc/Makefile.in that tries to
> build the generated files before compiling regular objects.  However,
> this appears too early, and so at the time it is seen by make,
> GCOV_OBJS and GCOV_DUMP_OBJS have not yet been set.
> 
> This patch fixes the problem and prevents any future problems of this
> nature by moving the order-only dependency to the end of Makefile.in.
> 
> This also adds lto-wrapper.o to ALL_HOST_BACKEND_OBJS.
> 
>   * Makefile.in (ALL_HOST_BACKEND_OBJS): Add lto-wrapper.o.
>   ($(ALL_HOST_OBJS)): Move order-only dependency to end
>   of file.
> ---
>  gcc/Makefile.in | 13 +++--
>  1 file changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/gcc/Makefile.in b/gcc/Makefile.in
> index 415f085..172ab4d 100644
> --- a/gcc/Makefile.in
> +++ b/gcc/Makefile.in
> @@ -1496,7 +1496,8 @@ ALL_HOST_FRONTEND_OBJS = $(foreach 
> v,$(CONFIG_LANGUAGES),$($(v)_OBJS))
>  
>  ALL_HOST_BACKEND_OBJS = $(GCC_OBJS) $(OBJS) $(OBJS-libcommon) \
>$(OBJS-libcommon-target) @TREEBROWSER@ main.o c-family/cppspec.o \
> -  $(COLLECT2_OBJS) $(EXTRA_GCC_OBJS) $(GCOV_OBJS) $(GCOV_DUMP_OBJS)
> +  $(COLLECT2_OBJS) $(EXTRA_GCC_OBJS) $(GCOV_OBJS) $(GCOV_DUMP_OBJS) \
> +  lto-wrapper.o
>  
>  # This lists all host object files, whether they are included in this
>  # compilation or not.
> @@ -3884,11 +3885,6 @@ generated_files = config.h tm.h $(TM_P_H) $(TM_H) 
> multilib.h \
> options.h target-hooks-def.h insn-opinit.h \
> common/common-target-hooks-def.h pass-instances.def
>  
> -# In order for parallel make to really start compiling the expensive
> -# objects from $(OBJS) as early as possible, build all their
> -# prerequisites strictly before all objects.
> -$(ALL_HOST_OBJS) : | $(generated_files)
> -
>  #
>  # How to compile object files to run on the build machine.
>  
> @@ -5381,3 +5377,8 @@ po/gcc.pot: force
>   $(MAKE) srcextra
>   AWK=$(AWK) $(SHELL) $(srcdir)/po/exgettext \
>   $(XGETTEXT) gcc $(srcdir)
> +
> +# In order for parallel make to really start compiling the expensive
> +# objects from $(OBJS) as early as possible, build all their
> +# prerequisites strictly before all objects.
> +$(ALL_HOST_OBJS) : | $(generated_files)
> 

Ok.

Paolo

Re: [buildrobot] [PATCH] r202527: ssa / ssanames restructure broke alpha-linux

[Andrew MacLeod]

On 09/14/2013 06:41 AM, Jan-Benedict Glaw wrote:

Hi!


I suggest this patch, which fixes an alpha-linux build for me:

2013-09-13  Jan-Benedict Glaw  

* config/alpha.c: Include tree-ssa.h.

diff --git a/gcc/config/alpha/alpha.c b/gcc/config/alpha/alpha.c
index a8fb929..3759205 100644
--- a/gcc/config/alpha/alpha.c
+++ b/gcc/config/alpha/alpha.c
@@ -50,6 +50,7 @@ along with GCC; see the file COPYING3.  If not see
  #include "splay-tree.h"
  #include "gimple.h"
  #include "tree-flow.h"
+#include "tree-ssa.h"
  #include "tree-stdarg.h"
  #include "tm-constrs.h"
  #include "df.h"


Ok?


It seems a little odd that a target requires the ssa stuff, but I'm fine 
with this to fix the compile error.

Sorry about that.

Andrew

Re: [PATCH v3 04/18] add configury

[Paolo Bonzini]

Il 20/08/2013 15:59, Tom Tromey ha scritto:
> This adds the configury needed for automatic dependency tracking.  It
> also adds some bits to the Makefile so we can begin converting
> (removing) explicit dependencies.
> 
>   * Makefile.in (CCDEPMODE, DEPDIR, depcomp, COMPILE.base)
>   (COMPILE, POSTCOMPILE): New variables.
>   (.cc.o .c.o): Use COMPILE, POSTCOMPILE.
>   (DEPFILES): New variable.
>   Include ".Po" files.
>   * configure.ac: Add checks for dependency checking.
>   * configure, aclocal.m4: Regenerate.
> ---
>  gcc/Makefile.in  |  28 ++-
>  gcc/aclocal.m4   |   2 +
>  gcc/configure| 148 
> ++-
>  gcc/configure.ac |  16 ++
>  4 files changed, 191 insertions(+), 3 deletions(-)
> 
> diff --git a/gcc/Makefile.in b/gcc/Makefile.in
> index 172ab4d..e1de7ba 100644
> --- a/gcc/Makefile.in
> +++ b/gcc/Makefile.in
> @@ -308,6 +308,11 @@ write_entries_to_file = $(shell rm -f $(2) || :) $(shell 
> touch $(2)) \
>  # UNSORTED
>  # 
>  
> +# Dependency tracking stuff.
> +CCDEPMODE = @CCDEPMODE@
> +DEPDIR = @DEPDIR@
> +depcomp = $(SHELL) $(srcdir)/../depcomp
> +
>  # Some compilers can't handle cc -c blah.c -o foo/blah.o.
>  # In stage2 and beyond, we force this to "-o $@" since we know we're using 
> gcc.
>  OUTPUT_OPTION = @OUTPUT_OPTION@
> @@ -1068,8 +1073,19 @@ INCLUDES = -I. -I$(@D) -I$(srcdir) -I$(srcdir)/$(@D) \
>  $(CPPINC) $(GMPINC) $(DECNUMINC) $(BACKTRACEINC) \
>  $(CLOOGINC) $(ISLINC)
>  
> +COMPILE.base = $(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) -o $@
> +ifeq ($(CCDEPMODE),depmode=gcc3)
> +COMPILE = $(COMPILE.base) -MT $@ -MMD -MP -MF $(*D)/$(DEPDIR)/$(*F).TPo
> +POSTCOMPILE = @mv $(*D)/$(DEPDIR)/$(*F).TPo $(*D)/$(DEPDIR)/$(*F).Po
> +else
> +COMPILE = source='$<' object='$@' libtool=no \
> +DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) $(COMPILE.base)
> +POSTCOMPILE =
> +endif
> +
>  .cc.o .c.o:
> - $(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) $< $(OUTPUT_OPTION)
> + $(COMPILE) $<
> + $(POSTCOMPILE)
>  
>  #
>  # Support for additional languages (other than C).
> @@ -5378,7 +5394,17 @@ po/gcc.pot: force
>   AWK=$(AWK) $(SHELL) $(srcdir)/po/exgettext \
>   $(XGETTEXT) gcc $(srcdir)
>  
> +#
> +
> +# Dependency information.
> +
>  # In order for parallel make to really start compiling the expensive
>  # objects from $(OBJS) as early as possible, build all their
>  # prerequisites strictly before all objects.
>  $(ALL_HOST_OBJS) : | $(generated_files)
> +
> +# Include the auto-generated dependencies for all host objects.
> +DEPFILES = \
> +  $(foreach obj,$(ALL_HOST_OBJS),\
> +$(dir $(obj))$(DEPDIR)/$(patsubst %.o,%.Po,$(notdir $(obj
> +-include $(DEPFILES)
> diff --git a/gcc/aclocal.m4 b/gcc/aclocal.m4
> index 1f3ce9d..e7cfd7d 100644
> --- a/gcc/aclocal.m4
> +++ b/gcc/aclocal.m4
> @@ -101,10 +101,12 @@ m4_define([AC_PROG_CC],
>  
>  m4_include([../config/acx.m4])
>  m4_include([../config/codeset.m4])
> +m4_include([../config/depstand.m4])
>  m4_include([../config/dfp.m4])
>  m4_include([../config/gettext-sister.m4])
>  m4_include([../config/iconv.m4])
>  m4_include([../config/lcmessage.m4])
> +m4_include([../config/lead-dot.m4])
>  m4_include([../config/lib-ld.m4])
>  m4_include([../config/lib-link.m4])
>  m4_include([../config/lib-prefix.m4])
> diff --git a/gcc/configure b/gcc/configure
> index 1e9be8e..c53a930 100755
> --- a/gcc/configure
> +++ b/gcc/configure
> @@ -735,6 +735,9 @@ LDEXP_LIB
>  EXTRA_GCC_LIBS
>  GNAT_LIBEXC
>  COLLECT2_LIBS
> +CCDEPMODE
> +DEPDIR
> +am__leading_dot
>  CXXCPP
>  AR
>  NM
> @@ -8873,6 +8876,136 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu
>  
>  
>  # 
> +# Dependency checking.
> +# 
> +
> +ac_ext=cpp
> +ac_cpp='$CXXCPP $CPPFLAGS'
> +ac_compile='$CXX -c $CXXFLAGS $CPPFLAGS conftest.$ac_ext >&5'
> +ac_link='$CXX -o conftest$ac_exeext $CXXFLAGS $CPPFLAGS $LDFLAGS 
> conftest.$ac_ext $LIBS >&5'
> +ac_compiler_gnu=$ac_cv_cxx_compiler_gnu
> +
> +rm -rf .tst 2>/dev/null
> +mkdir .tst 2>/dev/null
> +if test -d .tst; then
> +  am__leading_dot=.
> +else
> +  am__leading_dot=_
> +fi
> +rmdir .tst 2>/dev/null
> +
> +DEPDIR="${am__leading_dot}deps"
> +
> +ac_config_commands="$ac_config_commands depdir"
> +
> +
> +ac_config_commands="$ac_config_commands gccdepdir"
> +
> +
> +depcc="$CC"   am_compiler_list=
> +
> +am_depcomp=$ac_aux_dir/depcomp
> +{ $as_echo "$as_me:${as_lineno-$LINENO}: checking dependency style of 
> $depcc" >&5
> +$as_echo_n "checking dependency style of $depcc... " >&6; }
> +if test "${am_cv_CC_dependencies_compiler_type+set}" = set; then :
> +  $as_echo_n "(cached) " >&6
> +else
> +  if test -f "$am_depcomp"; then
> +  # We make a subdir and do the tests there.  Otherwise we can end up
> +  # making bogus files that we don't know about and never remove.  For
> +  # instance it was reported that on HP-UX the gcc test will end up
> +  # making a dummy file named `D' -- becaus

Re: [PATCH v3 10/18] Fix up c-family targets

[Paolo Bonzini]

Il 20/08/2013 15:59, Tom Tromey ha scritto:
> This removes manual dependencies for the c-family .o files.
> 
>   * Makefile.in (c-family/cppspec.o, c-family/c-common.o)
>   (c-family/c-cppbuiltin.o, c-family/c-dump.o, c-family/c-format.o)
>   (c-family/c-gimplify.o, c-family/c-lex.o, c-family/c-omp.o)
>   (c-family/c-opts.o, c-family/c-pch.o, c-family/c-ppoutput.o)
>   (c-family/c-pragma.o, c-family/c-pretty-print.o)
>   (c-family/c-semantics.o, c-family/c-ada-spec.o)
>   (c-family/array-notation-common.o, c-family/stub-objc.o): Remove.
> ---
>  gcc/Makefile.in | 76 
> -
>  1 file changed, 76 deletions(-)
> 
> diff --git a/gcc/Makefile.in b/gcc/Makefile.in
> index 79eb9f1..6edaa00 100644
> --- a/gcc/Makefile.in
> +++ b/gcc/Makefile.in
> @@ -1963,87 +1963,11 @@ lto-wrapper.o: lto-wrapper.c $(CONFIG_H) $(SYSTEM_H) 
> coretypes.h intl.h \
>   $(OBSTACK_H) $(DIAGNOSTIC_H) $(OPTS_H) $(OPTIONS_H)
>  
>  # Files used by all variants of C or by the stand-alone pre-processor.
> -c-family/cppspec.o: c-family/cppspec.c $(CONFIG_H) $(SYSTEM_H) coretypes.h \
> -$(TM_H) $(GCC_H) $(OPTS_H)
> -
> -c-family/c-common.o : c-family/c-common.c $(CONFIG_H) $(SYSTEM_H) 
> coretypes.h \
> - $(TM_H) $(TREE_H) \
> - $(OBSTACK_H) $(C_COMMON_H) $(FLAGS_H) toplev.h output.h $(C_PRAGMA_H) \
> - $(GGC_H) builtin-types.def builtin-attrs.def \
> - $(DIAGNOSTIC_H) langhooks.h c-family/c-objc.h \
> - $(TARGET_H) tree-iterator.h langhooks.h tree-mudflap.h \
> - intl.h $(OPTS_H) $(CPPLIB_H) $(TREE_INLINE_H) $(HASHTAB_H) \
> - $(BUILTINS_DEF) $(CGRAPH_H) $(TARGET_DEF_H) \
> - gt-c-family-c-common.h $(COMMON_TARGET_H)
> -
> -c-family/c-cppbuiltin.o : c-family/c-cppbuiltin.c $(CONFIG_H) $(SYSTEM_H) \
> - coretypes.h $(TM_H) $(TREE_H) version.h $(C_COMMON_H) $(C_PRAGMA_H) \
> - $(FLAGS_H) output.h $(TREE_H) $(TARGET_H) $(COMMON_TARGET_H) \
> - $(TM_P_H) debug.h $(CPP_ID_DATA_H) cppbuiltin.h
> -
> -c-family/c-dump.o : c-family/c-dump.c $(CONFIG_H) $(SYSTEM_H) coretypes.h \
> - $(TM_H) $(TREE_H) $(TREE_DUMP_H)
> -
> -c-family/c-format.o : c-family/c-format.c c-family/c-format.h \
> - $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) $(TREE_H) langhooks.h \
> - $(C_COMMON_H) $(FLAGS_H) intl.h $(C_TARGET_H) \
> - $(DIAGNOSTIC_CORE_H) alloc-pool.h c-family/c-objc.h
> -
> -c-family/c-gimplify.o : c-family/c-gimplify.c $(CONFIG_H) $(SYSTEM_H) 
> $(TREE_H) \
> - $(C_COMMON_H) $(DIAGNOSTIC_CORE_H) $(GIMPLE_H) \
> - $(FLAGS_H) langhooks.h $(LANGHOOKS_DEF_H) \
> - $(TM_H) coretypes.h $(C_PRETTY_PRINT_H) $(CGRAPH_H) \
> - $(DUMPFILE_H) $(TREE_INLINE_H)
> -
> -c-family/c-lex.o : c-family/c-lex.c $(CONFIG_H) $(SYSTEM_H) coretypes.h \
> - $(TM_H) $(TREE_H) $(FIXED_VALUE_H) debug.h $(C_COMMON_H) 
> $(SPLAY_TREE_H) \
> - $(C_PRAGMA_H) $(INPUT_H) intl.h $(FLAGS_H) \
> - $(CPPLIB_H) $(TARGET_H) $(TIMEVAR_H)
> -
> -c-family/c-omp.o : c-family/c-omp.c $(CONFIG_H) $(SYSTEM_H) coretypes.h \
> - $(TREE_H) $(C_COMMON_H) $(GIMPLE_H) langhooks.h
>  
>  CFLAGS-c-family/c-opts.o += @TARGET_SYSTEM_ROOT_DEFINE@
> -c-family/c-opts.o : c-family/c-opts.c $(CONFIG_H) $(SYSTEM_H) coretypes.h \
> -$(TREE_H) $(C_PRAGMA_H) $(FLAGS_H) toplev.h langhooks.h \
> -$(DIAGNOSTIC_H) intl.h debug.h $(C_COMMON_H) $(C_TARGET_H) \
> -$(OPTS_H) $(OPTIONS_H) $(MKDEPS_H) incpath.h cppdefault.h
>  
>  CFLAGS-c-family/c-pch.o += -DHOST_MACHINE=\"$(host)\" \
>   -DTARGET_MACHINE=\"$(target)\"
> -c-family/c-pch.o : c-family/c-pch.c $(CONFIG_H) $(SYSTEM_H) coretypes.h \
> - $(CPPLIB_H) $(TREE_H) $(C_COMMON_H) output.h $(C_PRAGMA_H) \
> - $(GGC_H) debug.h langhooks.h $(FLAGS_H) hosthooks.h version.h \
> - $(TARGET_H) $(OPTS_H) $(TIMEVAR_H)
> -
> -c-family/c-ppoutput.o : c-family/c-ppoutput.c $(CONFIG_H) $(SYSTEM_H) \
> - coretypes.h $(C_COMMON_H) $(TREE_H) $(CPPLIB_H) $(CPP_INTERNAL_H) \
> - $(C_PRAGMA_H)
> -
> -c-family/c-pragma.o: c-family/c-pragma.c $(CONFIG_H) $(SYSTEM_H) coretypes.h 
> \
> - $(TM_H) $(TREE_H) $(FUNCTION_H) $(C_PRAGMA_H) output.h \
> - $(TM_P_H) $(C_COMMON_H) $(TARGET_H) $(CPPLIB_H) $(FLAGS_H) \
> - $(DIAGNOSTIC_H) $(OPTS_H) $(PLUGINS_H) \
> - gt-c-family-c-pragma.h
> -
> -c-family/c-pretty-print.o : c-family/c-pretty-print.c $(C_PRETTY_PRINT_H) \
> - $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) \
> - $(DIAGNOSTIC_H) tree-iterator.h intl.h $(TREE_PRETTY_PRINT_H)
> -
> -c-family/c-semantics.o : c-family/c-semantics.c $(CONFIG_H) $(SYSTEM_H) \
> - coretypes.h $(TM_H) $(TREE_H) $(FLAGS_H) \
> - $(C_COMMON_H) $(FUNCTION_H) langhooks.h $(SPLAY_TREE_H) $(TIMEVAR_H) \
> - tree-iterator.h
> -
> -c-family/c-ada-spec.o : c-family/c-ada-spec.c c-family/c-ada-spec.h \
> - $(CONFIG_H) $(SYSTEM_H) $(TREE_H) $(CPP_ID_DATA_H) $(TM_H) \
> - coretypes.h tree-iterator.h $(DUMPFILE_H)
> -
> -c-family/array-notation-common.o : c-family/array

Re: [PATCH v3 13/18] convert LTO to automatic dependencies

[Paolo Bonzini]

Il 20/08/2013 15:59, Tom Tromey ha scritto:
> This converts LTO.
> 
> This also fixes a latent buglet in lto/Make-lang.in.  lto_OBJS should
> hold all the objects for a language, but LTO never defined this.
> 
>   * Make-lang.in (LTO_H, LINKER_PLUGIN_API_H, LTO_TREE_H)
>   (lto/lto-lang.o, lto/lto.o, lto/lto-partition.o)
>   (lto/lto-object.o): Remove.
> ---
>  gcc/lto/Make-lang.in | 27 +--
>  1 file changed, 1 insertion(+), 26 deletions(-)
> 
> diff --git a/gcc/lto/Make-lang.in b/gcc/lto/Make-lang.in
> index 1acd176..ddef3bf 100644
> --- a/gcc/lto/Make-lang.in
> +++ b/gcc/lto/Make-lang.in
> @@ -23,10 +23,7 @@
>  LTO_EXE = lto1$(exeext)
>  # The LTO-specific object files inclued in $(LTO_EXE).
>  LTO_OBJS = lto/lto-lang.o lto/lto.o lto/lto-object.o attribs.o 
> lto/lto-partition.o
> -LTO_H = lto/lto.h $(HASHTAB_H)
> -LINKER_PLUGIN_API_H = $(srcdir)/../include/plugin-api.h
> -LTO_TREE_H = lto/lto-tree.h $(LINKER_PLUGIN_API_H)
> -
> +lto_OBJS = $(LTO_OBJS)
>  
>  # Rules
>  
> @@ -74,27 +71,5 @@ $(LTO_EXE): $(LTO_OBJS) $(BACKEND) $(LIBDEPS)
>   +$(LLINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ \
>   $(LTO_OBJS) $(BACKEND) $(BACKENDLIBS) $(LIBS)
>  
> -# Dependencies
> -lto/lto-lang.o: lto/lto-lang.c $(CONFIG_H) coretypes.h debug.h \
> - flags.h $(GGC_H) langhooks.h $(LANGHOOKS_DEF_H) $(SYSTEM_H) \
> - $(TARGET_H) $(LTO_H) $(GIMPLE_H) gtype-lto.h gt-lto-lto-lang.h \
> - $(EXPR_H) $(LTO_STREAMER_H)
> -lto/lto.o: lto/lto.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(OPTS_H) \
> - toplev.h $(TREE_H) $(TREE_FLOW_H) $(DIAGNOSTIC_CORE_H) $(TM_H) \
> - $(CGRAPH_H) $(GGC_H) tree-ssa-operands.h $(TREE_PASS_H) \
> - langhooks.h $(VEC_H) $(BITMAP_H) pointer-set.h $(IPA_PROP_H) \
> - $(COMMON_H) debug.h $(GIMPLE_H) $(LTO_H) $(LTO_TREE_H) \
> - $(LTO_TAGS_H) $(LTO_STREAMER_H) $(SPLAY_TREE_H) gt-lto-lto.h \
> - $(TREE_STREAMER_H) $(DATA_STREAMER_H) lto/lto-partition.h \
> - $(CONTEXT_H) $(PIPELINE_H)
> -lto/lto-partition.o: lto/lto-partition.c $(CONFIG_H) $(SYSTEM_H) coretypes.h 
> \
> - toplev.h $(TREE_H) $(TM_H) \
> - $(CGRAPH_H) $(TIMEVAR_H) \
> - $(LTO_STREAMER_H) $(SPLAY_TREE_H) gt-lto-lto.h $(PARAMS_H) \
> - ipa-inline.h $(IPA_UTILS_H) lto/lto-partition.h
> -lto/lto-object.o: lto/lto-object.c $(CONFIG_H) $(SYSTEM_H) coretypes.h \
> - $(DIAGNOSTIC_CORE_H) $(LTO_H) $(TM_H) $(LTO_STREAMER_H) \
> - ../include/simple-object.h
> -
>  # LTO testing is done as part of C/C++/Fortran etc. testing.
>  check-lto:
> 

Ok.

Paolo

Re: [buildrobot] [PATCH] r202527: ssa / ssanames restructure broke alpha-linux

[Michael Matz]

Hi,

On Mon, 16 Sep 2013, Uros Bizjak wrote:

> > Why do you think so?  The t-* frags are includes via
> > ...
> > tmake_file=...$(srcdir)/config/i386/t-i386
> > ...
> > ifneq ($(tmake_file),)
> > include $(tmake_file)
> > endif
> > ...
> >
> > It's just that there's no t-alpha frag yet.
> 
> No, there is no problem with includes. The *dependencies* from t-*
> files are missing.

No, because the t- frags contain the dependencies and the t- frags are 
included by make verbatim, hence they're there when building target.o.

> Please compare i386.o dependencies from config/i386/t-i386 with
> $(out_object_file) from the resulting Makefile in the build directory.
> They are NOT the same,

Of course not.  But as $(out_object_file) is 'i386.o' they will be 
dependencies for the same target.

> the dependencies in the Makefile from the build
> directory for $(out_object_file) AKA i386.o are copied verbatim from
> Makefile.in.

Sure.  And the Makefile _includes_ the t- frags, which means for i386, 
that there are two dependency sets, once from Makefile.in copied into 
Makefile, for $(out_object_file), and once explicitely for i386.o from the 
t-i386 frag included by Makefile.

> >> These are "universal" dependecies used to compile config/${cpu-type}.o
> >> for any target, no matter what their t- fragment says.
> >
> > The universal deps are amended by the t- frags, as above.
> 
> No, they are copied directly from Makefile.in.

Sure they are amended.  I'm unsure what thing you're missing, but you do 
miss something.  Maybe that the 'include' directives in the Makefile are 
not autoconf directives by real make directives?  IOW, the generated 
Makefile is not all that's interpreted by make; it's amended with all the 
included frags when reading the Makefile.  If you don't believe me: make 
an experiment, on a i386 devel tree:

% cd gcc; make i386.o
% vi /config/i386/t-i386
... add something like "nonexisting" to the deps of i386.o ...
# make i386.o
make: *** No rule to make target `nonexisting', needed by `i386.o'.  Stop.

So, clearly, the deps from t-i386 _are_ used.


Ciao,
Michael.

Re: [PATCH v3 14/18] remove explicit dependencies

[Paolo Bonzini]

Il 20/08/2013 15:59, Tom Tromey ha scritto:
> This removes most of the explicit dependencies for host objects.
> It also fixes a few rules to use $(COMPILE) in the process.
> 
> build objects are not affected, and are one reason that the various _H
> macros are not yet removed.
> 
>   * Makefile.in (graph.o, sbitmap.o, sparseset.o, gcc-ar.o)
>   (gcc-ranlib.o, gcc-nm.o, collect2.o, collect2-aix.o, tlink.o)
>   (lto-wrapper.o, attribs.o, incpath.o)
>   (prefix.o, gcc.o, options.o, options-save.o, version.o)
>   (gtype-desc.o, trans-mem.o, ggc-common.o, ggc-page.o, ggc-none.o)
>   (stringpool.o, convert.o, double-int.o, lto-compress.o)
>   (data-streamer-in.o, data-streamer-out.o, data-streamer.o)
>   (gimple-streamer-in.o, gimple-streamer-out.o, tree-streamer.o)
>   (tree-streamer-in.o, tree-streamer-out.o, streamer-hooks.o)
>   (lto-cgraph.o, lto-streamer-in.o, lto-streamer-out.o)
>   (lto-section-in.o, lto-section-out.o, lto-symtab.o, lto-opts.o)
>   (lto-streamer.o, langhooks.o, test-dump.o, tree.o, tree-dump.o)
>   (tree-inline.o, print-tree.o, stor-layout.o, asan.o, tsan.o)
>   (tree-ssa-tail-merge.o, tree-ssa-structalias.o, tree-ssa-uninit.o)
>   (tree-ssa.o, tree-into-ssa.o, tree-ssa-ter.o, tree-ssa-coalesce.o)
>   (tree-outof-ssa.o, tree-ssa-dse.o, tree-ssa-forwprop.o)
>   (tree-ssa-phiprop.o, tree-ssa-ifcombine.o, tree-ssa-phiopt.o)
>   (tree-nrv.o, tree-ssa-copy.o, tree-ssa-propagate.o)
>   (tree-ssa-dom.o, tree-ssa-uncprop.o, tree-ssa-threadedge.o)
>   (tree-ssa-threadupdate.o, tree-ssanames.o, tree-phinodes.o)
>   (domwalk.o, tree-ssa-live.o, tree-ssa-copyrename.o)
>   (tree-ssa-pre.o, tree-ssa-sccvn.o)
>   (gimple-ssa-strength-reduction.o, tree-vrp.o, tree-cfg.o)
>   (tree-cfgcleanup.o, tree-tailcall.o, tree-ssa-sink.o)
>   (tree-nested.o, tree-if-conv.o, tree-iterator.o, tree-dfa.o)
>   (tree-ssa-operands.o, tree-eh.o, tree-ssa-loop.o)
>   (tree-ssa-loop-unswitch.o, tree-ssa-address.o)
>   (tree-ssa-loop-niter.o, tree-ssa-loop-ivcanon.o)
>   (tree-ssa-loop-ch.o, tree-ssa-loop-prefetch.o, tree-predcom.o)
>   (tree-ssa-loop-ivopts.o, tree-affine.o, tree-ssa-loop-manip.o)
>   (tree-ssa-loop-im.o, tree-ssa-math-opts.o, tree-ssa-alias.o)
>   (tree-ssa-reassoc.o, tree-optimize.o, gimplify.o)
>   (gimple-iterator.o, gimple-fold.o, gimple-low.o, omp-low.o)
>   (tree-browser.o, omega.o, tree-chrec.o, tree-scalar-evolution.o)
>   (tree-data-ref.o, sese.o, graphite.o, graphite-blocking.o)
>   (graphite-clast-to-gimple.o, graphite-dependences.o)
>   (graphite-interchange.o, graphite-poly.o)
>   (graphite-scop-detection.o, graphite-sese-to-poly.o)
>   (graphite-optimize-isl.o, tree-vect-loop.o)
>   (tree-vect-loop-manip.o, tree-vect-patterns.o, tree-vect-slp.o)
>   (tree-vect-stmts.o, tree-vect-data-refs.o, tree-vectorizer.o)
>   (tree-loop-distribution.o, tree-parloops.o, tree-stdarg.o)
>   (tree-object-size.o, internal-fn.o, gimple.o)
>   (gimple-pretty-print.o, tree-mudflap.o, tree-nomudflap.o)
>   (tree-pretty-print.o, tree-diagnostic.o, fold-const.o)
>   (diagnostic.o, diagnostic-color.o, opts.o, opts-global.o)
>   (opts-common.o, targhooks.o, common/common-targhooks.o, input.o)
>   (toplev.o, hwint.o, plugin.o, main.o, host-default.o)
>   (rtl-error.o, rtl.o, print-rtl.o, rtlanal.o, varasm.o, function.o)
>   (statistics.o, stmt.o, except.o, expr.o, dojump.o, builtins.o)
>   (calls.o, expmed.o, explow.o, optabs.o, dbxout.o, debug.o)
>   (sdbout.o, dwarf2out.o, dwarf2cfi.o, dwarf2asm.o, vmsdbgout.o)
>   (xcoffout.o, godump.o, emit-rtl.o, real.o, realmpfr.o, dfp.o)
>   (fixed-value.o, jump.o, simplify-rtx.o, symtab.o, cgraph.o)
>   (cgraphunit.o, cgraphclones.o, cgraphbuild.o, varpool.o, ipa.o)
>   (ipa-prop.o, ipa-ref.o, ipa-cp.o, ipa-split.o, ipa-inline.o)
>   (ipa-inline-analysis.o, ipa-inline-transform.o, ipa-utils.o)
>   (ipa-reference.o, ipa-pure-const.o, coverage.o, cselib.o, cse.o)
>   (dce.o, dumpfile.o, dse.o, fwprop.o, web.o, ree.o, cprop.o)
>   (gcse.o, store-motion.o, resource.o, lcm.o, mode-switching.o)
>   (tree-ssa-dce.o, tree-call-cdce.o, tree-ssa-ccp.o)
>   (tree-ssa-strlen.o, tree-sra.o, tree-switch-conversion.o)
>   (tree-complex.o, tree-emutls.o, tree-vect-generic.o, df-core.o)
>   (df-problems.o, df-scan.o, regstat.o, valtrack.o, var-tracking.o)
>   (profile.o, mcf.o, tree-profile.o, value-prof.o, loop-doloop.o)
>   (alloc-pool.o, auto-inc-dec.o, cfg.o, cfghooks.o, cfgexpand.o)
>   (cfgrtl.o, cfganal.o, cfgbuild.o, cfgcleanup.o, cfgloop.o)
>   (cfgloopanal.o, graphds.o, loop-iv.o, loop-invariant.o)
>   (cfgloopmanip.o, loop-init.o, loop-unswitch.o, loop-unroll.o)
>   (dominance.o, et-forest.o, combine.o, reginfo.o, bitmap.o, vec.o)
>   (hash-table.o, reload.o, reload1.o, rtlhooks.o, postreload.o)
> 

Re: [PATCH v3 15/18] make out_object_file rule use automatic dependencies

[Paolo Bonzini]

Il 20/08/2013 15:59, Tom Tromey ha scritto:
> This is a small change to make out_object_file use automatic
> dependencies.
> 
>   * Makefile.in ($(out_object_file)): Use COMPILE and POSTCOMPILE.
> ---
>  gcc/Makefile.in | 12 +++-
>  1 file changed, 3 insertions(+), 9 deletions(-)
> 
> diff --git a/gcc/Makefile.in b/gcc/Makefile.in
> index b22e8a8..c8b7b65 100644
> --- a/gcc/Makefile.in
> +++ b/gcc/Makefile.in
> @@ -2028,15 +2028,9 @@ pass-instances.def: $(srcdir)/passes.def 
> $(srcdir)/gen-pass-instances.awk
>   $(AWK) -f $(srcdir)/gen-pass-instances.awk \
> $(srcdir)/passes.def > pass-instances.def
>  
> -$(out_object_file): $(out_file) $(CONFIG_H) coretypes.h $(TM_H) $(TREE_H) \
> -   $(RTL_H) $(REGS_H) hard-reg-set.h insn-config.h conditions.h \
> -   output.h $(INSN_ATTR_H) $(SYSTEM_H) toplev.h $(DIAGNOSTIC_CORE_H) \
> -   $(TARGET_H) $(LIBFUNCS_H) $(TARGET_DEF_H) $(FUNCTION_H) $(SCHED_INT_H) \
> -   $(TM_P_H) $(EXPR_H) langhooks.h $(GGC_H) $(OPTABS_H) $(REAL_H) \
> -   tm-constrs.h $(GIMPLE_H) $(DF_H) cselib.h $(COMMON_TARGET_H) hw-doloop.h \
> -   regrename.h
> - $(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) \
> - $(out_file) $(OUTPUT_OPTION)
> +$(out_object_file): $(out_file)
> + $(COMPILE) $<
> + $(POSTCOMPILE)
>  
>  $(common_out_object_file): $(common_out_file)
>   $(COMPILE) $<
> 

Ok.

Paolo

Re: [PATCH v3 16/18] remove last reference to TREE_GIMPLE_H

[Paolo Bonzini]

Il 20/08/2013 15:59, Tom Tromey ha scritto:
> There is a single reference to TREE_GIMPLE_H in the source tree.
> Since it is not defined anywhere, we might as well remove the use.
> 
>   * config/i386/t-i386 (i386.o): Don't use TREE_GIMPLE_H.
> ---
>  gcc/config/i386/t-i386 | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/gcc/config/i386/t-i386 b/gcc/config/i386/t-i386
> index 07624cc..a26edda 100644
> --- a/gcc/config/i386/t-i386
> +++ b/gcc/config/i386/t-i386
> @@ -22,7 +22,7 @@ i386.o: $(CONFIG_H) $(SYSTEM_H) coretypes.h dumpfile.h 
> $(TM_H) \
>$(INSN_ATTR_H) $(FLAGS_H) $(C_COMMON_H) except.h $(FUNCTION_H) \
>$(RECOG_H) $(EXPR_H) $(OPTABS_H) toplev.h $(BASIC_BLOCK_H) \
>$(GGC_H) $(TARGET_H) $(TARGET_DEF_H) langhooks.h $(CGRAPH_H) \
> -  $(TREE_GIMPLE_H) $(DWARF2_H) $(DF_H) tm-constrs.h $(PARAMS_H) \
> +  $(DWARF2_H) $(DF_H) tm-constrs.h $(PARAMS_H) \
>i386-builtin-types.inc debug.h dwarf2out.h sbitmap.h $(FIBHEAP_H) \
>$(OPTS_H) $(DIAGNOSTIC_H) $(COMMON_TARGET_H) $(CONTEXT_H) $(PASS_MANAGER_H)
>  
> 

Could it be for gimple.h?

Paolo

Re: [PATCH v3 17/18] remove last definition of CROSS_FLOAT_H

[Paolo Bonzini]

Il 20/08/2013 15:59, Tom Tromey ha scritto:
> There is a single definition of CROSS_FLOAT_H in the source.
> As far as I can tell, this is never used anywhere.
> So, this patch removes it.
> 
>   * config/mcore/t-mcore (CROSS_FLOAT_H): Remove.
> ---
>  gcc/config/mcore/t-mcore | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/gcc/config/mcore/t-mcore b/gcc/config/mcore/t-mcore
> index 92fefb1..e5f37ee 100644
> --- a/gcc/config/mcore/t-mcore
> +++ b/gcc/config/mcore/t-mcore
> @@ -16,9 +16,6 @@
>  # along with GCC; see the file COPYING3.  If not see
>  # .
>  
> -# We have values for float.h.
> -CROSS_FLOAT_H = $(srcdir)/config/mcore/gfloat.h
> -
>  # If support for -m4align is ever re-enabled then comment out the
>  # following line and uncomment the multilib lines below.
>  
> 

Ok.

Paolo

Re: [PATCH v3 18/18] remove unused macros

[Paolo Bonzini]

Il 20/08/2013 15:59, Tom Tromey ha scritto:
> I used this perl script to find unused _H macros in the Makefile.  I
> deleted the definitions it reported and re-ran the script, until there
> was no more output.
> 
> The script also makes note of _H variables which are used but never
> defined.  That is how I found the TREE_GIMPLE_H use, fixed earlier in
> the series.
> 
> Once Ada and the various config files are migrated to automatic
> dependencies, we can run this script again and remove more things.
> 
> If you find yourself needing to add a new _H variable -- don't!
> Instead, take the few seconds to verify that automatic dependencies
> work in this case, and remove the manual dependencies for whatever
> object you are dealing with.
> 
> 
> 
> while (<>) {
> chomp;
> if (m/^(([A-Z0-9_]+)_H)\s*:?=\s/) {
>   $saw_def{$1} = $ARGV . ":" . $.;
> }
> 
> while (m/\$[({](([A-Z0-9_]+)_H)[)}](.*)/) {
>   $saw_use{$1} = 1;
>   $_ = $3;
> }
> } continue {
> close ARGV if eof;
> }
> 
> foreach $key (sort keys %saw_use) {
> if (! defined $saw_def{$key}) {
>   print "use without a def of ", $key, "\n";
> }
> }
> 
> foreach $key (sort keys %saw_def) {
> if (! defined $saw_use{$key}) {
>   print $saw_def{$key}, ": no use of ", $key, "\n";
> }
> }
> 
> 
>   * Makefile.in (PARTITION_H, LTO_SYMTAB_H, COMMON_TARGET_DEF_H)
>   (RTL_ERROR_H, TRANS_MEM_H, COVERAGE_H, DEMANGLE_H, ALIAS_H)
>   (SCHED_INT_H, SEL_SCHED_IR_H, SEL_SCHED_DUMP_H, VALTRACK_H, DDG_H)
>   (GGC_INTERNAL_H, DECNUM_H, BACKTRACE_H, MKDEPS_H, TREE_HASHER_H)
>   (TREE_SSA_LIVE_H, SSAEXPAND_H, DWARF2OUT_H, SCEV_H, OMEGA_H)
>   (TREE_DATA_REF_H, IRA_INT_H, LRA_INT_H, DBGCNT_H, DATA_STREAMER_H)
>   (GIMPLE_STREAMER_H, TREE_STREAMER_H, STREAMER_HOOKS_H)
>   (TREE_VECTORIZER_H, IPA_INLINE_H, GSTAB_H, LIBFUNCS_H)
>   (GRAPHITE_HTAB_H): Remove.
> ---
>  gcc/Makefile.in | 46 --
>  1 file changed, 46 deletions(-)
> 
> diff --git a/gcc/Makefile.in b/gcc/Makefile.in
> index c8b7b65..b645dc6 100644
> --- a/gcc/Makefile.in
> +++ b/gcc/Makefile.in
> @@ -446,7 +446,6 @@ HASHTAB_H   = $(srcdir)/../include/hashtab.h
>  OBSTACK_H   = $(srcdir)/../include/obstack.h
>  SPLAY_TREE_H= $(srcdir)/../include/splay-tree.h
>  FIBHEAP_H   = $(srcdir)/../include/fibheap.h
> -PARTITION_H = $(srcdir)/../include/partition.h
>  MD5_H= $(srcdir)/../include/md5.h
>  DWARF2_H= $(srcdir)/../include/dwarf2.h $(srcdir)/../include/dwarf2.def
>  XREGEX_H= $(srcdir)/../include/xregex.h
> @@ -454,7 +453,6 @@ FNMATCH_H   = $(srcdir)/../include/fnmatch.h
>  
>  # Linker plugin API headers
>  LINKER_PLUGIN_API_H = $(srcdir)/../include/plugin-api.h
> -LTO_SYMTAB_H = $(srcdir)/../include/lto-symtab.h
>  
>  # Default native SYSTEM_HEADER_DIR, to be overridden by targets.
>  NATIVE_SYSTEM_HEADER_DIR = @NATIVE_SYSTEM_HEADER_DIR@
> @@ -863,14 +861,11 @@ LANGHOOKS_DEF_H = langhooks-def.h $(HOOKS_H)
>  TARGET_DEF_H = target-def.h target-hooks-def.h $(HOOKS_H) targhooks.h
>  C_TARGET_DEF_H = c-family/c-target-def.h c-family/c-target-hooks-def.h \
>$(TREE_H) $(C_COMMON_H) $(HOOKS_H) common/common-targhooks.h
> -COMMON_TARGET_DEF_H = common/common-target-def.h \
> -  common/common-target-hooks-def.h $(HOOKS_H)
>  RTL_BASE_H = coretypes.h rtl.h rtl.def $(MACHMODE_H) reg-notes.def \
>insn-notes.def $(INPUT_H) $(REAL_H) statistics.h $(VEC_H) \
>$(FIXED_VALUE_H) alias.h $(HASHTAB_H)
>  FIXED_VALUE_H = fixed-value.h $(MACHMODE_H) double-int.h
>  RTL_H = $(RTL_BASE_H) $(FLAGS_H) genrtl.h
> -RTL_ERROR_H = rtl-error.h $(RTL_H) $(DIAGNOSTIC_CORE_H)
>  READ_MD_H = $(OBSTACK_H) $(HASHTAB_H) read-md.h
>  PARAMS_H = params.h params.def
>  BUILTINS_DEF = builtins.def sync-builtins.def omp-builtins.def \
> @@ -888,12 +883,8 @@ BASIC_BLOCK_H = basic-block.h $(PREDICT_H) $(VEC_H) 
> $(FUNCTION_H) \
>  GIMPLE_H = gimple.h gimple.def gsstruct.def pointer-set.h $(VEC_H) \
>   $(GGC_H) $(BASIC_BLOCK_H) $(TREE_H) tree-ssa-operands.h \
>   tree-ssa-alias.h $(INTERNAL_FN_H) $(HASH_TABLE_H)
> -TRANS_MEM_H = trans-mem.h
>  GCOV_IO_H = gcov-io.h gcov-iov.h auto-host.h
> -COVERAGE_H = coverage.h $(GCOV_IO_H)
> -DEMANGLE_H = $(srcdir)/../include/demangle.h
>  RECOG_H = recog.h
> -ALIAS_H = alias.h
>  EMIT_RTL_H = emit-rtl.h
>  FLAGS_H = flags.h flag-types.h $(OPTIONS_H)
>  OPTIONS_H = options.h flag-types.h $(OPTIONS_H_EXTRA)
> @@ -902,11 +893,6 @@ FUNCTION_H = function.h $(HASHTAB_H) $(TM_H) 
> hard-reg-set.h \
>  EXPR_H = expr.h insn-config.h $(FUNCTION_H) $(RTL_H) $(FLAGS_H) $(TREE_H) 
> $(MACHMODE_H) $(EMIT_RTL_H)
>  OPTABS_H = optabs.h insn-codes.h insn-opinit.h
>  REGS_H = regs.h $(MACHMODE_H) hard-reg-set.h
> -SCHED_INT_H = sched-int.h $(INSN_ATTR_H) $(BASIC_BLOCK_H) $(RTL_H) $(DF_H) \
> - $(REGSET_H)
> -SEL_SCHED_IR_H = sel-sched

Re: [PATCH v3 12/18] convert the Go front end to automatic dependencies

[Paolo Bonzini]

Il 26/08/2013 18:09, Tom Tromey ha scritto:
>> "Ian" == Ian Lance Taylor  writes:
> 
> Ian> I assume that dropping $(OUTPUT_OPTION) is correct--I haven't looked
> Ian> at the new definition of $(COMPILE).
> 
> I believe the depcomp script takes care of this.

I think that would be the "compile" script, not depcomp.  But I suspect
that this has been broken for a while, since the C front-end require
$(OUTPUT_OPTION).

You are listed as the author of the "compile" script in Automake, do you
remember which compilers need it?  I'm too young for that (that's
something I can say less and less :))...

Paolo

Re: [PATCH v3 02/18] update generated_files

[Paolo Bonzini]

Il 20/08/2013 15:59, Tom Tromey ha scritto:
> A few generated files were not mentioned in the generated_files
> variable.  This fixes the problem.
> 
>   * Makefile.in (generated_files): Add options.h,
>   target-hooks-def.h, insn-opinit.h,
>   common/common-target-hooks-def.h, pass-instances.def.
> ---
>  gcc/Makefile.in | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/gcc/Makefile.in b/gcc/Makefile.in
> index 8d2fd23..415f085 100644
> --- a/gcc/Makefile.in
> +++ b/gcc/Makefile.in
> @@ -3880,7 +3880,9 @@ s-gtype: build/gengtype$(build_exeext) $(filter-out 
> [%], $(GTFILES)) \
>  generated_files = config.h tm.h $(TM_P_H) $(TM_H) multilib.h \
> $(simple_generated_h) specs.h \
> tree-check.h genrtl.h insn-modes.h tm-preds.h tm-constrs.h \
> -   $(ALL_GTFILES_H) gtype-desc.c gtype-desc.h gcov-iov.h
> +   $(ALL_GTFILES_H) gtype-desc.c gtype-desc.h gcov-iov.h \
> +   options.h target-hooks-def.h insn-opinit.h \
> +   common/common-target-hooks-def.h pass-instances.def
>  
>  # In order for parallel make to really start compiling the expensive
>  # objects from $(OBJS) as early as possible, build all their
> 

Ok.

Paolo

Re: [PATCH v3 12/18] convert the Go front end to automatic dependencies

[Tom Tromey]

Paolo> You are listed as the author of the "compile" script in Automake, do you
Paolo> remember which compilers need it?  I'm too young for that (that's
Paolo> something I can say less and less :))...

I have no idea any more.

I can try a test build using a setting for CC that rejects -c -o.

Tom

Re: [PATCH] Handle bit-fields in ubsan.c (PR sanitizer/58413)

[Jakub Jelinek]

On Mon, Sep 16, 2013 at 05:59:28PM +0200, Marek Polacek wrote:
> Regtested/ran bootstrap-ubsan on x86_64-linux.

That looks wrong.  ubsan_type_descriptor shouldn't change TYPE_PRECISION of
the type it has been called with, whether type is a bitfield or not can
change what typedescriptor is generated, but not unrelated code.

> 2013-09-16  Marek Polacek  
> 
>   PR sanitizer/58413
>   * ubsan.c (ubsan_type_descriptor): Change TYPE_PRECISION of
>   a bit-field type to its TYPE_SIZE.  Tweak type name.
> 
>   * c-c++-common/ubsan/shift-4.c: New test.
> 
> --- gcc/ubsan.c.mp2   2013-09-16 16:55:26.653579402 +0200
> +++ gcc/ubsan.c   2013-09-16 16:57:29.192016988 +0200
> @@ -251,6 +251,10 @@ ubsan_type_descriptor (tree type)
>/* See through any typedefs.  */
>type = TYPE_MAIN_VARIANT (type);
>  
> +  /* Handle bit-fields.  */
> +  if (compare_tree_int (TYPE_SIZE (type), TYPE_PRECISION (type) == 1))
> +TYPE_PRECISION (type) = tree_low_cst (TYPE_SIZE (type), 1);
> +
>tree decl = decl_for_type_lookup (type);
>if (decl != NULL_TREE)
>  return decl;
> @@ -270,7 +274,7 @@ ubsan_type_descriptor (tree type)
>   tname = IDENTIFIER_POINTER (DECL_NAME (TYPE_NAME (type)));
>  }
>else
> -tname = "";
> +tname = "";
>  
>if (TREE_CODE (type) == INTEGER_TYPE)
>  {
> --- gcc/testsuite/c-c++-common/ubsan/shift-4.c.mp22013-09-16 
> 17:01:55.852982631 +0200
> +++ gcc/testsuite/c-c++-common/ubsan/shift-4.c2013-09-16 
> 17:32:32.114891611 +0200
> @@ -0,0 +1,14 @@
> +/* { dg-do run } */
> +/* { dg-options "-fsanitize=shift -w" } */
> +
> +struct S { unsigned long long int b:40; } s;
> +
> +int
> +main ()
> +{
> +  s.b = 2;
> +  s.b <<= 120;
> +  return 0;
> +}
> +
> +/* { dg-output "shift exponent 120 is too large\[^\n\r]*(\n|\r\n|\r)" } */
> 
>   Marek

Jakub

Re: [PATCH v3 16/18] remove last reference to TREE_GIMPLE_H

[Tom Tromey]

Tom> There is a single reference to TREE_GIMPLE_H in the source tree.
Tom> Since it is not defined anywhere, we might as well remove the use.

Paolo> Could it be for gimple.h?

Good catch, it seems to be.
Rather than fix that, it is simple to just drop all these dependencies
from t-i386.  I'll do that in the next round.

Tom

Re: [PATCH] Don't always instrument shifts (PR sanitizer/58413)

[Joseph S. Myers]

On Mon, 16 Sep 2013, Marek Polacek wrote:

> On Fri, Sep 13, 2013 at 07:18:24PM +, Joseph S. Myers wrote:
> > On Fri, 13 Sep 2013, Marek Polacek wrote:
> > 
> > > This is kind of fugly, but don't have anything better at the moment.
> > > 2013-09-13  Marek Polacek  
> > > 
> > >   PR sanitizer/58413
> > > c-family/
> > >   * c-ubsan.c (ubsan_instrument_shift): Don't instrument
> > >   an expression if we can prove it is correct.
> > 
> > Shouldn't the conditions used here for an expression being proved correct 
> > match those for instrumentation, i.e. depend on flag_isoc99 and on 
> > (cxx_dialect == cxx11 || cxx_dialect == cxx1y)?
> 
> I don't think so: for the unsigned case we could restrict it to C
> only, but it doesn't hurt doing it even for C++; in the signed case
> we care only about C, but we can't restrict it to flag_isoc99 only,
> since we need to prove the correctnes even for ANSI C.

I don't understand how this answers my question.

* The following principle applies: for any command-line options, with 
ubsan enabled, if an integer operation with particular (non-constant) 
operands is accepted by the sanitization code at runtime, the same 
operation with the same operand values (and types) as constants should be 
accepted at compile time (and at runtime) in contexts where an integer 
constant expression is required.  Does this patch make the compiler meet 
this principle, for all the different command-line options that vary what 
is accepted at runtime?

* The following principle also applies: for any command-line options, with 
ubsan enabled, if an integer operation with particular (non-constant) 
operands is rejected by the sanitization code at runtime, the same 
operation with the same operand values (and types) as constants should be 
rejected at compile time (or at runtime) in contexts where an integer 
constant expression is required.  Does this patch make the compiler meet 
this principle, for all the different command-line options that vary what 
is accepted at runtime?

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

Re: patch to fix PR58418

[H.J. Lu]

On Mon, Sep 16, 2013 at 8:12 AM, Vladimir Makarov  wrote:
> The following patch fixes
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58418
>
> The patch also fixes a duplicated bug PR58419.

Shouldn't we also add a testcase from PR58419?

> The patch was successfully tested and bootstrapped on x86/x86-64.
>
> Committed as rev. 202630.
>
> 2013-09-16  Vladimir Makarov  
>
> PR middle-end/58418
> * lra-constraints.c (undo_optional_reloads): Consider all optional
> reload even if it did not get a hard reg.
>
> 2013-09-16  Vladimir Makarov  
>
> * gcc.target/i386/pr58418.c: New.
>



-- 
H.J.

[PATCH] Handle bit-fields in ubsan.c (PR sanitizer/58413)

[Marek Polacek]

This patch ought to fix the unexpected size of type 'long long unsigned int:40'
issue in PR58413.  Since libubsan will fail when the precision of a type
is not 32/64/128, we can't pass the width of a bitfield, instead we should pass
the TYPE_SIZE of the base type, I guess.

What is not very nice is that the type we get in the bit-field case
doesn't have the TYPE_NAME set, so we'll have to live with ""
(renamed, since I find it better than "").

Regtested/ran bootstrap-ubsan on x86_64-linux.

Ok for trunk?

2013-09-16  Marek Polacek  

PR sanitizer/58413
* ubsan.c (ubsan_type_descriptor): Change TYPE_PRECISION of
a bit-field type to its TYPE_SIZE.  Tweak type name.

* c-c++-common/ubsan/shift-4.c: New test.

--- gcc/ubsan.c.mp2 2013-09-16 16:55:26.653579402 +0200
+++ gcc/ubsan.c 2013-09-16 16:57:29.192016988 +0200
@@ -251,6 +251,10 @@ ubsan_type_descriptor (tree type)
   /* See through any typedefs.  */
   type = TYPE_MAIN_VARIANT (type);
 
+  /* Handle bit-fields.  */
+  if (compare_tree_int (TYPE_SIZE (type), TYPE_PRECISION (type) == 1))
+TYPE_PRECISION (type) = tree_low_cst (TYPE_SIZE (type), 1);
+
   tree decl = decl_for_type_lookup (type);
   if (decl != NULL_TREE)
 return decl;
@@ -270,7 +274,7 @@ ubsan_type_descriptor (tree type)
tname = IDENTIFIER_POINTER (DECL_NAME (TYPE_NAME (type)));
 }
   else
-tname = "";
+tname = "";
 
   if (TREE_CODE (type) == INTEGER_TYPE)
 {
--- gcc/testsuite/c-c++-common/ubsan/shift-4.c.mp2  2013-09-16 
17:01:55.852982631 +0200
+++ gcc/testsuite/c-c++-common/ubsan/shift-4.c  2013-09-16 17:32:32.114891611 
+0200
@@ -0,0 +1,14 @@
+/* { dg-do run } */
+/* { dg-options "-fsanitize=shift -w" } */
+
+struct S { unsigned long long int b:40; } s;
+
+int
+main ()
+{
+  s.b = 2;
+  s.b <<= 120;
+  return 0;
+}
+
+/* { dg-output "shift exponent 120 is too large\[^\n\r]*(\n|\r\n|\r)" } */

Marek

Re: [PATCH v3 05/18] convert the C front end to automatic dependencies

[Tom Tromey]

> "Paolo" == Paolo Bonzini  writes:

Paolo> Can you put before patch 4 another that defines OUTPUT_OPTION to "-o $@"
Paolo> unconditionally and removes all traces of NO_MINUS_C_MINUS_O?

Sure thing.

Paolo> The series looks okay to me with that change.

Thanks very much for your reviews.
I'll send an updated series for a last look-over soon.
A few of the patches needed minor tweaks when rebasing today (mostly
just differences in the dependencies causing conflicts).  I'll spend
more time rewriting the ChangeLog entries...

Tom

[PATCH] Handle IDENTIFIER_NODEs in ubsan.c (PR sanitizer/58420)

[Marek Polacek]

This patch amends the chunk of code where we are determining the
type name; I haven't consider that IDENTIFIER_NODEs require special
handling, since we need to omit the DECL_NAME.  I had something similar
in http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00917.html patch, but
there I had a thinko: I need to check that TYPE_NAME is non-NULL first.

Regtested/ran bootstrap-ubsan on x86_64-linux.

Ok for trunk?

2013-09-16  Marek Polacek  

PR sanitizer/58420
* ubsan.c (ubsan_type_descriptor): Handle IDENTIFIER_NODEs
when determining the type name.

--- gcc/ubsan.c.mp  2013-09-16 14:22:07.195918175 +0200
+++ gcc/ubsan.c 2013-09-16 14:22:10.503929477 +0200
@@ -260,11 +260,18 @@ ubsan_type_descriptor (tree type)
   unsigned short tkind, tinfo;
 
   /* At least for INTEGER_TYPE/REAL_TYPE/COMPLEX_TYPE, this should work.
- ??? For e.g. type_unsigned_for (type), the TYPE_NAME would be NULL.  */
+ For e.g. type_unsigned_for (type) or bit-fields, the TYPE_NAME
+ would be NULL.  */
   if (TYPE_NAME (type) != NULL)
-tname = IDENTIFIER_POINTER (DECL_NAME (TYPE_NAME (type)));
+{
+  if (TREE_CODE (TYPE_NAME (type)) == IDENTIFIER_NODE)
+   tname = IDENTIFIER_POINTER (TYPE_NAME (type));
+  else
+   tname = IDENTIFIER_POINTER (DECL_NAME (TYPE_NAME (type)));
+}
   else
 tname = "";
+
   if (TREE_CODE (type) == INTEGER_TYPE)
 {
   /* For INTEGER_TYPE, this is 0x.  */

Marek

[PATCH, alpha]: Add alpha.o dependecies

[Uros Bizjak]

Hello!

Attached patch decleres dependecies for config/alpha/alpha.o.

2013-09-16  Uros Bizjak  

* config/alpha/t-alpha: New.
* config.gcc (alpha*-*-linux*): Add alpha/t-alpha to tmake_file.
(alpha*-*-freebsd*): Ditto.
(alpha*-*-netbsd*): Ditto.
(alpha*-*-openbsd*): Ditto.
(alpha64-dec-*vms*): Ditto.
(alpha*-dec-*vms*): Ditto.


Bootstrap on alpha-pc-linux-gnu is in progress.

OK for mainline if bootstrap passes?

Uros.
Index: config/alpha/t-alpha
===
--- config/alpha/t-alpha(revision 0)
+++ config/alpha/t-alpha(working copy)
@@ -0,0 +1,25 @@
+# Copyright (C) 2013 Free Software Foundation, Inc.
+#
+# This file is part of GCC.
+#
+# GCC is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3, or (at your option)
+# any later version.
+#
+# GCC is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GCC; see the file COPYING3.  If not see
+# .
+
+alpha.o: $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) $(RTL_H) $(TREE_H) \
+  $(REGS_H) hard-reg-set.h insn-config.h conditions.h output.h \
+  $(INSN_ATTR_H) $(FLAGS_H) $(RECOG_H) $(EXPR_H) $(OPTABS_H) reload.h \
+  $(OBSTACK_H) $(EXCEPT_H) $(FUNCTION_H) $(DIAGNOSTIC_CORE_H) $(GGC_H) \
+  $(TM_P_H) $(TARGET_H) $(TARGET_DEF_H) $(COMMON_TARGET_H) debug.h \
+  langhooks.h $(SPLAY_TREE_H) $(GIMPLE_H) $(TREE_FLOW_H) tree-ssanames.h \
+  tree-stdarg.h tm-constrs.h $(DF_H) $(LIBFUNCS_H) $(OPTS_H) $(PARAMS_H)
Index: config.gcc
===
--- config.gcc  (revision 202630)
+++ config.gcc  (working copy)
@@ -903,27 +903,30 @@
;;
 alpha*-*-linux*)
tm_file="elfos.h ${tm_file} alpha/elf.h alpha/linux.h alpha/linux-elf.h 
glibc-stdint.h"
-   tmake_file="${tmake_file} alpha/t-linux"
+   tmake_file="${tmake_file} alpha/t-alpha alpha/t-linux"
extra_options="${extra_options} alpha/elf.opt"
;;
 alpha*-*-freebsd*)
tm_file="elfos.h ${tm_file} ${fbsd_tm_file} alpha/elf.h alpha/freebsd.h"
+   tmake_file="${tmake_file} alpha/t-alpha"
extra_options="${extra_options} alpha/elf.opt"
;;
 alpha*-*-netbsd*)
tm_file="elfos.h ${tm_file} netbsd.h alpha/elf.h netbsd-elf.h 
alpha/netbsd.h"
+   tmake_file="${tmake_file} alpha/t-alpha"
extra_options="${extra_options} netbsd.opt netbsd-elf.opt \
   alpha/elf.opt"
;;
 alpha*-*-openbsd*)
tm_defines="${tm_defines} OBSD_HAS_DECLARE_FUNCTION_NAME 
OBSD_HAS_DECLARE_FUNCTION_SIZE OBSD_HAS_DECLARE_OBJECT"
tm_file="elfos.h alpha/alpha.h alpha/elf.h openbsd.h openbsd-stdint.h 
alpha/openbsd.h openbsd-libpthread.h"
+   tmake_file="${tmake_file} alpha/t-alpha"
extra_options="${extra_options} openbsd.opt alpha/elf.opt"
# default x-alpha is only appropriate for dec-osf.
;;
 alpha*-dec-*vms*)
tm_file="${tm_file} vms/vms.h alpha/vms.h"
-   tmake_file="${tmake_file} alpha/t-vms"
+   tmake_file="${tmake_file} alpha/t-alpha alpha/t-vms"
;;
 arm-wrs-vxworks)
tm_file="elfos.h arm/elf.h arm/aout.h ${tm_file} vx-common.h vxworks.h 
arm/vxworks.h"

Re: [PATCH] Handle bit-fields in ubsan.c (PR sanitizer/58413)

[Marek Polacek]

On Mon, Sep 16, 2013 at 06:04:23PM +0200, Jakub Jelinek wrote:
> On Mon, Sep 16, 2013 at 05:59:28PM +0200, Marek Polacek wrote:
> > Regtested/ran bootstrap-ubsan on x86_64-linux.
> 
> That looks wrong.  ubsan_type_descriptor shouldn't change TYPE_PRECISION of
> the type it has been called with, whether type is a bitfield or not can
> change what typedescriptor is generated, but not unrelated code.

Ok, that was weird.  What about this one?  We use the TYPE_SIZE precision
if we're dealing with bit-fields, but don't change the type in any
way.

Ubsan testsuite passes...

2013-09-16  Marek Polacek  

PR sanitizer/58413
* ubsan.c (get_ubsan_type_info_for_type): For bit-fields, use the
precision of its TYPE_SIZE.

--- gcc/ubsan.c.mp  2013-09-16 18:13:01.075903156 +0200
+++ gcc/ubsan.c 2013-09-16 18:13:20.514974154 +0200
@@ -233,7 +233,13 @@ ubsan_source_location (location_t loc)
 static unsigned short
 get_ubsan_type_info_for_type (tree type)
 {
-  int prec = exact_log2 (TYPE_PRECISION (type));
+  int prec = TYPE_PRECISION (type);
+
+  /* Handle bit-fields.  */
+  if (compare_tree_int (TYPE_SIZE (type), prec) == 1)
+prec = tree_low_cst (TYPE_SIZE (type), 1);
+
+  prec = exact_log2 (prec);
   if (prec == -1)
 error ("unexpected size of type %qT", type);
 

Marek

Re: patch to fix PR58418

[Vladimir Makarov]

On 13-09-16 11:39 AM, H.J. Lu wrote:

On Mon, Sep 16, 2013 at 8:12 AM, Vladimir Makarov  wrote:

The following patch fixes

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58418

The patch also fixes a duplicated bug PR58419.

Shouldn't we also add a testcase from PR58419?


I've checked the test and found this is the same bug.  I don't think we 
need one more testsuite for this.

Re: [PATCH v3 05/18] convert the C front end to automatic dependencies

[Paolo Bonzini]

Il 20/08/2013 15:59, Tom Tromey ha scritto:
> This converts the C front end.
> 
> Note that this fixes a latent bug in gcc/Makefile.in's definition of
> C_TREE_H.  This is needed to avoid breaking this build with this
> patch.
> 
>   * Makefile.in (C_TREE_H): Reference c/c-tree.h.
> 
>   * Make-lang.in (c/gccspec.o): Remove.
>   (CFLAGS-c/gccspec.o): New variable.
>   (cc1-checksum.o, C_TREE_H, c/c-aux-info.o, c/c-convert.o)
>   (c/c-decl.o, c/c-errors.o, c/c-lang.o, c/c-objc-common.o)
>   (c/c-parser.o, c/c-typeck.o, c/c-array-notation.o): Remove.

As I wrote in another reply, I suspect this breaks bootstrap with
compilers that do not support "-c -o", if it is not broken yet.

Can you put before patch 4 another that defines OUTPUT_OPTION to "-o $@"
unconditionally and removes all traces of NO_MINUS_C_MINUS_O?

The series looks okay to me with that change.

Paolo

Re: [PATCH, committed] SH: Fix PR58314 (unsatisfied constraints)

[Richard Sandiford]

Hi Christian,

Christian Bruel  writes:
> @@ -6893,11 +6894,14 @@ label:
>  ;; reloading MAC subregs otherwise.  For that probably special patterns
>  ;; would be required.
>  (define_insn "*mov_reg_reg"
> -  [(set (match_operand:QIHI 0 "arith_reg_dest" "=r")
> - (match_operand:QIHI 1 "register_operand" "r"))]
> +  [(set (match_operand:QIHI 0 "arith_reg_dest" "=r,m,*z")
> + (match_operand:QIHI 1 "register_operand" "r,*z,m"))]

If the constraints allow "m", the predicates need to accept memories too.
(It'd be worth having an insn condition that rejects both operands
being memories though.)

Thanks,
Richard

Re: [PATCH, committed] * pt.c (make_auto_1): Use input_location rather than BUILTINS_LOCATION.

[Eric Botcazou]

> Apologies if this was out of context.  This was a change suggested and
> reviewed by Jason
> (http://gcc.gnu.org/ml/gcc-patches/2013-09/msg01114.html).

Then don't repost it on gcc-patches, it is already available on gcc-cvs:
  http://gcc.gnu.org/ml/gcc-cvs/2013-09/msg00473.html

-- 
Eric Botcazou

Re: [PATCH v3 12/18] convert the Go front end to automatic dependencies

[Tom Tromey]

Tom> I can try a test build using a setting for CC that rejects -c -o.

I did this and the build died pretty early on:

  /home/tromey/Space/Trunk/Git/bin/my-cc -c -DHAVE_CONFIG_H -g -g -I. 
-I../../gcc/libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat 
-Wstrict-prototypes -pedantic  -fpic ../../gcc/libiberty/regex.c -o 
pic/regex.o; \
else true; fi
no -c -o support
make[3]: *** [regex.o] Error 1
make[3]: Leaving directory `/home/tromey/Space/Trunk/Git/build/libiberty'
make[2]: *** [all-stage1-libiberty] Error 2


In this case the --enable-shared for libiberty was added automatically
because LTO defaults to enabled.  Adding --disable-lto lets it get
further:

/home/tromey/Space/Trunk/Git/bin/my-cc -DPACKAGE_NAME=\"\" 
-DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" 
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"zlib\" 
-DVERSION=\"1.1.4\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 
-DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 
-DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 
-DLT_OBJDIR=\".libs/\" -DHAVE_STDLIB_H=1 -DHAVE_UNISTD_H=1 -DHAVE_GETPAGESIZE=1 
-DHAVE_MMAP=1 -DHAVE_MEMCPY=1 -DHAVE_STRERROR=1 -DHAVE_UNISTD_H=1 -I. 
-I../../gcc/zlib   -g  -g -c -o libz_a-adler32.o `test -f 'adler32.c' || echo 
'../../gcc/zlib/'`adler32.c
no -c -o support
make[3]: *** [libz_a-adler32.o] Error 1
make[3]: Leaving directory `/home/tromey/Space/Trunk/Git/build/zlib'
make[2]: *** [all-stage1-zlib] Error 2


And indeed, zlib's configure.ac does not invoke AC_PROG_CC_C_O.

So, maybe this has been broken a long time.

Tom