Re: [Patch, Fortran] PR57697 - Fix an issue with defined assignment
Hi Tobias, As testing showed, it didn't fix the real-world code: ForTrilinos's ForTrilinos_ADT_3D_Burgers_6th_Pade did still fail as it has: *_F.DA65 = matrix_diff_x (parm.621); _F.DA66 = ax-epetra_rowmatrix.universal; // Deref of ax! Build and regtested on x86-64-gnu-linux. OK? The patch is OK, also for 4.8. Please add a test case which also checks for the ForTrilinos failure. Thomas
Re: [RFC] Offloading Support in libgomp
On Sun, Sep 15, 2013 at 07:41:24PM +0400, Michael V. Zolotukhin wrote: Libgomp will start N-1 new threads, and all of them would want to look up mappings for i1,i2,...iK in the splay tree. The first one wouldn't find anything and would map and insert all the values to the tree. But the following ones would look-up these addresses in the exactly same order, which will lead to totally unbalanced tree. Am I missing anything or is it a real problem? On second thought, this access order doesn't necessarily mean accessing in ascending/descending keys order, so there is no problem here. 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? 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). Jakub
Re: [Patch, Fortran] PR57697 - Fix an issue with defined assignment
Thomas Koenig wrote: Build and regtested on x86-64-gnu-linux. OK? The patch is OK, also for 4.8. Please add a test case which also checks for the ForTrilinos failure. Thanks for the review. I have now committed the current patch as Rev. 202609. I will later try to create a test case, which fails before 202609 and works with it. Additionally, I will work on the 4.8 backport. (Unfortunately, it does not simply apply on gcc-4_8-branch has the gfc_build_intrinsic_call has slightly changed.) Tobias
Re: [RFC] Offloading Support in libgomp
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
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 ld -m flags): Remove non-canonical
ppc host match. Support little-endian powerpc linux hosts.
libjava/libltdl/
* acinclude.m4 (_LT_ENABLE_LOCK ld -m flags): 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.
---
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.
From: abutcher abutcher@138bc75d-0d04-0410-961f-82ee72b054a4
* 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;
- vectree, va_gc *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. */
+
+ vectree, va_gc *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
[PATCH, re-committed] Support using 'auto' in a function parameter list to introduce an implicit template parameter.
From: abutcher abutcher@138bc75d-0d04-0410-961f-82ee72b054a4 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 @@
Re: Using gen_int_mode instead of GEN_INT minot testsuite fallout on MIPS
Richard Biener richard.guent...@gmail.com writes: On Fri, Sep 13, 2013 at 10:33 AM, Richard Sandiford rdsandif...@googlemail.com wrote: Richard Biener richard.guent...@gmail.com 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)
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 [=] typename... T (T ... ts) // OK: ts is a function
parameter pack
{
printer(std::forwarddecltype(ts)(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
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
On Sun, Sep 15, 2013 at 09:08:00PM +0200, Jan Hubicka wrote: 2013-09-13 Jakub Jelinek ja...@redhat.com * 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.
---
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
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.
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
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 bernd.edlin...@hotmail.de 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
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 bas...@starynkevitch.net
* 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: basileatstarynkevitchdotnet 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
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 bas...@starynkevitch.net
* plugin.c (parse_plugin_arg_opt): Accept equal sign inside
plugin argument.
Regards
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet 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.
On 13/09/13 19:39, James Greenhalgh wrote: Hi, This patch adds intrinsics for vcopyq_laneq_pfsu8,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 vmulq_laneq_fsu16,32,64 intrinsics in C
On 13/09/13 19:28, James Greenhalgh wrote: Hi, This patch converts the vmulq_laneq_fsu16,32,64 intrinsics in arm_neon.h to a C implementation. OK /Marcus
Re: [AArch64] Improve arm_neon.h vmlas_lane handling.
On 13/09/13 19:31, James Greenhalgh wrote: Hi, This patch reimpliments the vmlas_lane and the fmas intrinsics in C, and adds new combiner patterns to support this. OK /Marcus
Re: [AArch64] Fix parameters to vcvtx_high
*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 james.greenha...@arm.com
* 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
On Fri, Sep 13, 2013 at 9:15 PM, Andrew MacLeod amacl...@redhat.com 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 amacl...@redhat.com
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
Adding Eric and Steven in the loop as it is RTL related. Thanks Yvan On 11 September 2013 21:08, Yvan Roux yvan.r...@linaro.org wrote: Here is the new patch discussed in the other thread. Thanks Yvan 2013-09-11 Yvan Roux yvan.r...@linaro.org Vladimir Makarov vmaka...@redhat.com * 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
On 06/09/13 16:06, James Greenhalgh wrote: gcc/ 2013-09-06 James Greenhalgh james.greenha...@arm.com * config/aarch64/arm_neon.h (vcvtx_high_f32_f64): Fix parameters. OK /Marcus
Re: tree if convert pass control
On Sat, Sep 14, 2013 at 8:10 AM, Xinliang David Li davi...@google.com 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
On Sat, Sep 14, 2013 at 12:41 PM, Jan-Benedict Glaw jbg...@lug-owl.de 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=11663mode=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 jbg...@lug-owl.de * 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
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=11663mode=view I suggest this patch, which fixes an alpha-linux build for me: 2013-09-13 Jan-Benedict Glaw jbg...@lug-owl.de * 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
On Fri, Sep 13, 2013 at 10:23 PM, Mike Stump mikest...@comcast.net wrote: On Sep 13, 2013, at 1:08 AM, Richard Sandiford rdsandif...@googlemail.com 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
Any comment/review on this patch ?
On Sep 3, 2013, at 4:08 PM, Tristan Gingold ging...@adacore.com 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 ging...@adacore.com
* 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 ging...@adacore.com
* 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_region prev_ehp_region = state-ehp_region;
+
+ state-ehp_region = tf-region;
finally = gimple_eh_else_e_body (eh_else);
Re: [PATCH, i386, MPX 1/X] Support of Intel MPX ISA
On Fri, Sep 13, 2013 at 4:36 PM, H.J. Lu hjl.to...@gmail.com 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 *mode_mk + [(set (match_operand:BND 0 register_operand =B) +(unspec:BND + [(match_operator:bnd_ptr 3 bnd_mem_operator +[(unspec:bnd_ptr + [(match_operand:bnd_ptr 1 register_operand r) +(match_operand:bnd_ptr 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
On Fri, Sep 13, 2013 at 12:18 PM, Ilya Enkovich enkovich@gmail.com wrote: 2013/9/11 Uros Bizjak ubiz...@gmail.com: On Tue, Sep 10, 2013 at 1:38 PM, Ilya Enkovich enkovich@gmail.com 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 enkovich@gmail.com: Ping^3 Attached is the same patch but against the current trunk. 2013/8/26 Ilya Enkovich enkovich@gmail.com: Ping 2013/8/19 Ilya Enkovich enkovich@gmail.com: Ping 2013/8/12 Ilya Enkovich enkovich@gmail.com: 2013/8/10 Joseph S. Myers jos...@codesourcery.com: 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 ilya.enkov...@intel.com * 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 bnd prefix. (BND): New. (bnd_ptr): New. (BNDCHECK): New. (bndcheck): New. (*jcc_1): Add MPX bnd prefix and fix length. (*jcc_2): Likewise. (jump): Likewise. (simple_return_internal): Likewise. (simple_return_pop_internal): Likewise. (*indirect_jump): Add MPX bnd prefix. (*tablejump_1): Likewise. (simple_return_internal_long): Likewise. (simple_return_indirect_internal): Likewise. (mode_mk): New. (*mode_mk): New. (movmode): New.
Re: [v3] More noexcept for vectors
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
On Fri, Sep 13, 2013 at 4:29 PM, Eric Botcazou ebotca...@adacore.com 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 ebotca...@adacore.com
* 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 ebotca...@adacore.com
* gnat.dg/opt27.adb: New test.
* gnat.dg/opt27_pkg.ad[sb]: New helper.
--
Eric Botcazou
Re: [AArch64] Implement vset_lane intrinsics in C
On Fri, Sep 13, 2013 at 10:47:01PM +0100, Andrew Pinski wrote:
On Fri, Sep 13, 2013 at 11:57 AM, James Greenhalgh
james.greenha...@arm.com 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
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)
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 pola...@redhat.com 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
On Fri, Sep 13, 2013 at 4:56 PM, Eric Botcazou ebotca...@adacore.com 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 ebotca...@adacore.com * tree-ssa-loop-ivopts.c (may_be_unaligned_p): Deal with BLKmode as the access mode. 2013-09-13 Eric Botcazou ebotca...@adacore.com * 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
On Fri, Sep 13, 2013 at 6:45 PM, Joseph S. Myers jos...@codesourcery.com 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
On Fri, Sep 13, 2013 at 6:56 PM, Xinliang David Li davi...@google.com 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 davi...@google.com 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
jos...@codesourcery.com 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
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 kyrylo.tkac...@arm.com
* 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
On Fri, Sep 13, 2013 at 5:16 PM, Xinliang David Li davi...@google.com wrote: On Fri, Sep 13, 2013 at 1:30 AM, Richard Biener richard.guent...@gmail.com wrote: On Thu, Sep 12, 2013 at 10:31 PM, Xinliang David Li davi...@google.com 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.
On Fri, Sep 13, 2013 at 8:06 PM, Cong Hou co...@google.com 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 (vecgimple
|| !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 co...@google.com
+
+ * 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 j...@suse.cz
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 stdarg.h
+#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 co...@google.com
+
+ * 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 kti...@redhat.com
gcc.target/i386/pr57848.c: New file.
On Wed, Sep 11, 2013 at 6:55 PM, Xinliang David Li davi...@google.com 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 co...@google.com 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 init, sum_1
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 reduction computation.
*/
This function should check if x_t and y_t have the same type (type)
which has the half size of
Re: New GCC options for loop vectorization
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 davi...@google.com 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
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
On Mon, Sep 16, 2013 at 11:06 AM, Uros Bizjak ubiz...@gmail.com 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=11663mode=view I suggest this patch, which fixes an alpha-linux build for me: 2013-09-13 Jan-Benedict Glaw jbg...@lug-owl.de * 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
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 kyrylo.tkac...@arm.com 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 kyrylo.tkac...@arm.com PR tree-optimization/58088 * gcc.c-torture/compile/pr58088.c: New test.
Re: [v3] More noexcept for vectors
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
On Mon, 2013-09-16 13:01:40 +0200, Uros Bizjak ubiz...@gmail.com wrote: On Mon, Sep 16, 2013 at 11:06 AM, Uros Bizjak ubiz...@gmail.com 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
On Mon, 16 Sep 2013, Uros Bizjak wrote: On Mon, Sep 16, 2013 at 11:06 AM, Uros Bizjak ubiz...@gmail.com 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=11663mode=view I suggest this patch, which fixes an alpha-linux build for me: 2013-09-13 Jan-Benedict Glaw jbg...@lug-owl.de * 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 rguent...@suse.de 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
On Mon, Sep 16, 2013 at 1:36 PM, Jan-Benedict Glaw jbg...@lug-owl.de wrote: On Mon, 2013-09-16 13:01:40 +0200, Uros Bizjak ubiz...@gmail.com wrote: On Mon, Sep 16, 2013 at 11:06 AM, Uros Bizjak ubiz...@gmail.com 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
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 cgraph_node (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
On Mon, 16 Sep 2013, Uros Bizjak wrote: On Mon, Sep 16, 2013 at 1:36 PM, Jan-Benedict Glaw jbg...@lug-owl.de wrote: On Mon, 2013-09-16 13:01:40 +0200, Uros Bizjak ubiz...@gmail.com wrote: On Mon, Sep 16, 2013 at 11:06 AM, Uros Bizjak ubiz...@gmail.com 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
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 ni...@redhat.com
* 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
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_descructibleallocator_type::value==false or is_nothrow_destructiblepointer::value==false, which would alter the type of is_nothrow_destructiblevectorT, A. 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
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
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.
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 ysrum...@gmail.com * 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
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
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 rguent...@suse.de
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
On Mon, Sep 16, 2013 at 1:57 PM, Richard Biener rguent...@suse.de 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
On Fri, Sep 13, 2013 at 11:25 AM, Diego Novillo dnovi...@google.com wrote:
On Fri, Sep 13, 2013 at 11:07 AM, Jakub Jelinek ja...@redhat.com 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 dnovi...@google.com
+
+ * tree-core.h: Add missing comment lines from refactoring
+ of tree.h.
+
2013-09-16 Jan Hubicka j...@suse.cz
* 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
On Mon, Sep 16, 2013 at 09:39:27AM -0400, Diego Novillo wrote: On Fri, Sep 13, 2013 at 11:25 AM, Diego Novillo dnovi...@google.com wrote: On Fri, Sep 13, 2013 at 11:07 AM, Jakub Jelinek ja...@redhat.com 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.
On Mon, Sep 16, 2013 at 2:50 PM, Yuri Rumyantsev ysrum...@gmail.com 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 ysrum...@gmail.com
* 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
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 kug...@linaro.org
+
+ * 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.
+ * tree-vrp.c (vrp_finalize): Call
Re: [buildrobot] [PATCH] r202527: ssa / ssanames restructure broke alpha-linux
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.
Uros,
Thanks for your review.
I attached modified patch - is it OK for you now?
2013/9/16 Uros Bizjak ubiz...@gmail.com:
On Mon, Sep 16, 2013 at 2:50 PM, Yuri Rumyantsev ysrum...@gmail.com 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 ysrum...@gmail.com
* 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
On 09/16/2013 05:05 AM, Richard Biener wrote: On Sat, Sep 14, 2013 at 12:41 PM, Jan-Benedict Glaw jbg...@lug-owl.de 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=11663mode=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
On Mon, Sep 16, 2013 at 4:20 PM, Michael Matz m...@suse.de 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.
On Mon, Sep 16, 2013 at 4:26 PM, Yuri Rumyantsev ysrum...@gmail.com 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
Richard Where's that automatic dependency patch blocked ... No build machinery maintainer has reviewed it. Tom
Re: [patch] Cleanup tree-ssa-ter.c exports
On 09/16/2013 04:55 AM, Richard Biener wrote:
On Fri, Sep 13, 2013 at 9:15 PM, Andrew MacLeod amacl...@redhat.com 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
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_COMPILERFLAGS) $(ALL_CPPFLAGS) $(DRIVER_DEFINES) \
- $(INCLUDES) $(srcdir)/java/jvspec.c $(OUTPUT_OPTION))
+ $(INCLUDES)
patch to fix PR58418
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 vmaka...@redhat.com
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 vmaka...@redhat.com
* 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, reg_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, reg_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
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
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
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 jbg...@lug-owl.de * 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
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' -- because `-MD' means `put the output
+ # in D'.
+ mkdir conftest.dir
+ # Copy depcomp to subdir because otherwise we won't find it if we're
+ # using a relative directory.
+ cp
Re: [PATCH v3 10/18] Fix up c-family targets
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-notation-common.c $(TREE_H) \ - $(SYSTEM_H) $(TREE_H) coretypes.h tree-iterator.h
Re: [PATCH v3 13/18] convert LTO to automatic dependencies
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
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
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) (postreload-gcse.o, caller-save.o, bt-load.o, reorg.o, alias.o)
Re: [PATCH v3 15/18] make out_object_file rule use automatic dependencies
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
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
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 # http://www.gnu.org/licenses/. -# 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
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-ir.h $(INSN_ATTR_H) $(BASIC_BLOCK_H) $(RTL_H) \
- $(GGC_H) $(BITMAP_H) $(SCHED_INT_H) $(CFGLOOP_H) $(REGSET_H)
Re: [PATCH v3 12/18] convert the Go front end to automatic dependencies
Il 26/08/2013 18:09, Tom Tromey ha scritto: Ian == Ian Lance Taylor i...@google.com 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
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
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)
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 pola...@redhat.com
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 = unknown;
+tname = unnamed;
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 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)
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 pola...@redhat.com 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
On Mon, Sep 16, 2013 at 8:12 AM, Vladimir Makarov vmaka...@redhat.com 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 vmaka...@redhat.com 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 vmaka...@redhat.com * gcc.target/i386/pr58418.c: New. -- H.J.
[PATCH] Handle bit-fields in ubsan.c (PR sanitizer/58413)
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 unnamed
(renamed, since I find it better than unknown).
Regtested/ran bootstrap-ubsan on x86_64-linux.
Ok for trunk?
2013-09-16 Marek Polacek pola...@redhat.com
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 = unknown;
+tname = unnamed;
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
Paolo == Paolo Bonzini bonz...@gnu.org 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)
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 pola...@redhat.com
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 = unknown;
+
if (TREE_CODE (type) == INTEGER_TYPE)
{
/* For INTEGER_TYPE, this is 0x. */
Marek
[PATCH, alpha]: Add alpha.o dependecies
Hello!
Attached patch decleres dependecies for config/alpha/alpha.o.
2013-09-16 Uros Bizjak ubiz...@gmail.com
* 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
+# http://www.gnu.org/licenses/.
+
+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)
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 pola...@redhat.com
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
On 13-09-16 11:39 AM, H.J. Lu wrote: On Mon, Sep 16, 2013 at 8:12 AM, Vladimir Makarov vmaka...@redhat.com 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
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
