[PATCH] Prevent 'control reaches end of non-void function' warning for DO_WHILE
Jakub,
This patch fixes the problem reported in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25973#c4 .
The test-case listed there is:
...
struct Block
{
public:
Block();
~Block();
};
bool func( bool bar )
{
Block block;
bool foo = false;
if( !foo || bar )
do { return true; } while( 0 );
else
do { return false; } while( 0 );
}
...
For O0, a spurious warning is generated:
...
$ gcc -O0 -Wreturn-type block.C -S:
block.C: In function ‘bool func(bool)’:
block.C:17:1: warning: control reaches end of non-void function [-Wreturn-type]
...
Basically the patch tries to handle DO_STMT in block_may_fallthru, but since
it's a cp-tree.def tree, it's done via a language hook.
Improving block_may_fallthru helps code in gimplify.c:shortcut_cond_expr() to
prevent the superfluous warning:
...
/* We only emit the jump over the else clause if we have to--if the
then clause may fall through. Otherwise we can wind up with a
useless jump and a useless label at the end of gimplified code,
which will cause us to think that this conditional as a whole
falls through even if it doesn't. If we then inline a function
which ends with such a condition, that can cause us to issue an
inappropriate warning about control reaching the end of a
non-void function. */
jump_over_else = block_may_fallthru (then_);
...
Bootstrapped and reg-tested on x86_64.
OK for next stage1?
Thanks,
- Tom
Index: gcc/langhooks-def.h
===
--- gcc/langhooks-def.h (revision 181172)
+++ gcc/langhooks-def.h (working copy)
@@ -79,6 +79,8 @@ extern tree lhd_omp_assignment (tree, tr
struct gimplify_omp_ctx;
extern void lhd_omp_firstprivatize_type_sizes (struct gimplify_omp_ctx *,
tree);
+extern bool lhd_tree_may_fallthru (const_tree);
+
#define LANG_HOOKS_NAME "GNU unknown"
#define LANG_HOOKS_IDENTIFIER_SIZE sizeof (struct lang_identifier)
@@ -118,6 +120,7 @@ extern void lhd_omp_firstprivatize_type_
#define LANG_HOOKS_EH_PROTECT_CLEANUP_ACTIONS NULL
#define LANG_HOOKS_EH_USE_CXA_END_CLEANUP false
#define LANG_HOOKS_DEEP_UNSHARING false
+#define LANG_HOOKS_TREE_MAY_FALLTHRU lhd_tree_may_fallthru
/* Attribute hooks. */
#define LANG_HOOKS_ATTRIBUTE_TABLE NULL
@@ -309,7 +312,8 @@ extern void lhd_end_section (void);
LANG_HOOKS_EH_RUNTIME_TYPE, \
LANG_HOOKS_EH_PROTECT_CLEANUP_ACTIONS, \
LANG_HOOKS_EH_USE_CXA_END_CLEANUP, \
- LANG_HOOKS_DEEP_UNSHARING \
+ LANG_HOOKS_DEEP_UNSHARING, \
+ LANG_HOOKS_TREE_MAY_FALLTHRU \
}
#endif /* GCC_LANG_HOOKS_DEF_H */
Index: gcc/langhooks.h
===
--- gcc/langhooks.h (revision 181172)
+++ gcc/langhooks.h (working copy)
@@ -473,6 +473,10 @@ struct lang_hooks
gimplification. */
bool deep_unsharing;
+ /* Return false if we cannot continue executing the immediately
+ following tree. */
+ bool (*tree_may_fallthru) (const_tree);
+
/* Whenever you add entries here, make sure you adjust langhooks-def.h
and langhooks.c accordingly. */
};
Index: gcc/langhooks.c
===
--- gcc/langhooks.c (revision 181172)
+++ gcc/langhooks.c (working copy)
@@ -657,3 +657,12 @@ lhd_end_section (void)
saved_section = NULL;
}
}
+
+/* Return false if we cannot continue executing the tree immediately
+ following T. */
+
+bool
+lhd_tree_may_fallthru (const_tree t ATTRIBUTE_UNUSED)
+{
+ return true;
+}
Index: gcc/gimple-low.c
===
--- gcc/gimple-low.c (revision 181172)
+++ gcc/gimple-low.c (working copy)
@@ -32,6 +32,7 @@ along with GCC; see the file COPYING3.
#include "function.h"
#include "diagnostic-core.h"
#include "tree-pass.h"
+#include "langhooks.h"
/* The differences between High GIMPLE and Low GIMPLE are the
following:
@@ -680,8 +681,11 @@ block_may_fallthru (const_tree block)
case CLEANUP_POINT_EXPR:
return block_may_fallthru (TREE_OPERAND (stmt, 0));
-default:
+case ERROR_MARK:
return true;
+
+default:
+ return lang_hooks.tree_may_fallthru (stmt);
}
}
Index: gcc/cp/cp-objcp-common.c
===
--- gcc/cp/cp-objcp-common.c (revision 181172)
+++ gcc/cp/cp-objcp-common.c (working copy)
@@ -305,4 +305,21 @@ cp_common_init_ts (void)
MARK_TS_TYPED (CTOR_INITIALIZER);
}
+/* Return false if we cannot continue executing the tree immediately
+ following T. */
+
+bool
+cp_tree_may_fallthru (const_tree t)
+{
+ switch (TREE_CODE (t))
+{
+case DO_STMT:
+ /* If DO_BODY doesn't fall thru, then DO_STMT doesn't either. */
+ return block_may_fallthru (DO_BODY (t));
+default:
+ break;
+}
+ return true;
+}
+
#include "gt-cp-cp-objcp-common.h"
Index: gcc/cp/cp-objcp-common.h
==
{patch ira-color.c]: Fix printf-formatter use for long-long type for windows native targets.
Hi,
this patch fixes for windows native target print-formatter used about
long-long type.
ChangeLog
2011-12-09 Kai Tietz
* ira-color.c (print_hard_regs_subforest): Use
HOST_WIDEST_INT_PRINT_DEC instead of %lld.
Tested for i686-w64-mingw32, x86_64-w64-mingw32, and
x86_64-unknown-linux-gnu. Ok for apply?
Kai
Index: ira-color.c
===
--- ira-color.c (revision 182092)
+++ ira-color.c (working copy)
@@ -498,7 +498,8 @@
fprintf (f, " ");
fprintf (f, "%d:(", node->preorder_num);
print_hard_reg_set (f, node->hard_regs->set, false);
- fprintf (f, ")@%lld\n", node->hard_regs->cost);
+ fprintf (f, ")@" HOST_WIDEST_INT_PRINT_DEC "\n",
+ (HOST_WIDEST_INT) node->hard_regs->cost);
print_hard_regs_subforest (f, node->first, level + 1);
}
}
{patch implicit-zee.c]: Fix printf-formatter use for long-long type for windows native targets.
Hi, this patch fixes for windows native target print-formatter used about long-long type. ChangeLog 2011-12-09 Kai Tietz * implicit-zee.c (find_and_remove_ze): Use HOST_WIDEST_INT_PRINT_DEC instead of %lld. Tested for i686-w64-mingw32, x86_64-w64-mingw32, and x86_64-unknown-linux-gnu. Ok for apply? Kai Index: implicit-zee.c === --- implicit-zee.c (revision 182092) +++ implicit-zee.c (working copy) @@ -944,10 +944,12 @@ VEC_free (rtx, heap, zeinsn_del_list); if (dump_file && num_ze_opportunities > 0) -fprintf (dump_file, "\n %s : num_zee_opportunities = %lld " -"num_realized = %lld \n", +fprintf (dump_file, "\n %s : num_zee_opportunities = " + HOST_WIDEST_INT_PRINT_DEC +" num_realized = " HOST_WIDEST_INT_PRINT_DEC "\n", current_function_name (), -num_ze_opportunities, num_realized); +(HOST_WIDEST_INT) num_ze_opportunities, +(HOST_WIDEST_INT) num_realized); df_finish_pass (false); return 0;
Re: RFA: Avoid unnecessary clearing in union initialisers
Carrot Wei writes: > Since it also affects 4.6 branch, can this and r176270 also be ported > to gcc4.6? Always worth asking, but in this case, I'm not sure it's appropriate. The patch is pretty invasive, and I don't think the bug is a regression. Also, 4.6 generates really lousy code for these intrinsics, so I think anyone who's serious about using them would need 4.7 anyway. Richard
[PATCH][C++] Fix PR51262
The following fixes PR51262, the new type alias code does
else if (CLASS_TYPE_P (t) && !TYPE_DECL_ALIAS_P (TYPE_NAME (t)))
which ICEs when t is a type with an anonymous name with -flto
because we clear such TYPE_NAMEs during cp_free_lang_data.
It turns out that doing so is no longer necessary because we
now ignore names when merging canonical types (and thus C and
C++ interoperate just fine).
Bootstrapped and tested on x86_64-unknown-linux-gnu, ok for trunk?
Thanks,
Richard.
2011-12-09 Richard Guenther
PR lto/51262
* tree.c (cp_free_lang_data): No longer clear anonymous names.
* g++.dg/opt/pr51262.C: New testcase.
Index: gcc/cp/tree.c
===
--- gcc/cp/tree.c (revision 182117)
+++ gcc/cp/tree.c (working copy)
@@ -3479,17 +3479,6 @@ cp_free_lang_data (tree t)
DECL_EXTERNAL (t) = 1;
TREE_STATIC (t) = 0;
}
- if (CP_AGGREGATE_TYPE_P (t)
- && TYPE_NAME (t))
-{
- tree name = TYPE_NAME (t);
- if (TREE_CODE (name) == TYPE_DECL)
- name = DECL_NAME (name);
- /* Drop anonymous names. */
- if (name != NULL_TREE
- && ANON_AGGRNAME_P (name))
- TYPE_NAME (t) = NULL_TREE;
-}
if (TREE_CODE (t) == NAMESPACE_DECL)
{
/* The list of users of a namespace isn't useful for the middle-end
Index: gcc/testsuite/g++.dg/opt/pr51262.C
===
--- gcc/testsuite/g++.dg/opt/pr51262.C (revision 0)
+++ gcc/testsuite/g++.dg/opt/pr51262.C (revision 0)
@@ -0,0 +1,21 @@
+// { dg-do compile }
+// { dg-require-effective-target lto }
+// { dg-options "-flto -g" }
+
+template < typename > void *
+bar (int *p)
+{
+ union
+{
+ int *p;
+}
+ u;
+ u.p = p;
+ return u.p;
+}
+
+void
+foo (int *p)
+{
+ bar < void >(p);
+}
Re: [PATCH 1/6] Delete VEC_INTERLEAVE_*_EXPR.
On Thu, Dec 8, 2011 at 10:06 PM, Richard Henderson wrote: > Slightly modified version of a patch Jakub posted earlier. Ok (given the target specific patches are approved). Thanks for this cleanup, Richard. > > * tree.def (VEC_INTERLEAVE_HIGH_EXPR, VEC_INTERLEAVE_LOW_EXPR): Remove. > * gimple-pretty-print.c (dump_binary_rhs): Don't handle > VEC_INTERLEAVE_HIGH_EXPR and VEC_INTERLEAVE_LOW_EXPR. > * expr.c (expand_expr_real_2): Likewise. > * tree-cfg.c (verify_gimple_assign_binary): Likewise. > * cfgexpand.c (expand_debug_expr): Likewise. > * tree-inline.c (estimate_operator_cost): Likewise. > * tree-pretty-print.c (dump_generic_node): Likewise. > * tree-vect-generic.c (expand_vector_operations_1): Likewise. > * fold-const.c (fold_binary_loc): Likewise. > * doc/generic.texi (VEC_INTERLEAVE_HIGH_EXPR, > VEC_INTERLEAVE_LOW_EXPR): Remove documentation. > * optabs.c (optab_for_tree_code): Don't handle > VEC_INTERLEAVE_HIGH_EXPR and VEC_INTERLEAVE_LOW_EXPR. > (expand_binop, init_optabs): Remove vec_interleave_high_optab > and vec_interleave_low_optab. > * genopinit.c (optabs): Likewise. > * optabs.h (OTI_vec_interleave_high, OTI_vec_interleave_low): Remove. > (vec_interleave_high_optab, vec_interleave_low_optab): Remove. > * doc/md.texi (vec_interleave_high, vec_interleave_low): Remove > documentation. > * tree-vect-stmts.c (gen_perm_mask): Renamed to... > (vect_gen_perm_mask): ... this. No longer static. > (perm_mask_for_reverse, vectorizable_load): Adjust callers. > * tree-vectorizer.h (vect_gen_perm_mask): New prototype. > * tree-vect-data-refs.c (vect_strided_store_supported): Don't try > VEC_INTERLEAVE_*_EXPR, use can_vec_perm_p instead of > can_vec_perm_for_code_p. > (vect_permute_store_chain): Generate VEC_PERM_EXPR with interleaving > masks instead of VEC_INTERLEAVE_HIGH_EXPR and VEC_INTERLEAVE_LOW_EXPR. > * config/i386/i386.c (expand_vec_perm_interleave2): If > expand_vec_perm_interleave3 would handle it, return false. > (expand_vec_perm_broadcast_1): Don't use vec_interleave_*_optab. > --- > gcc/cfgexpand.c | 2 - > gcc/config/i386/i386.c | 26 +++-- > gcc/doc/generic.texi | 13 --- > gcc/doc/md.texi | 14 --- > gcc/expr.c | 2 - > gcc/fold-const.c | 10 - > gcc/genopinit.c | 4 +-- > gcc/gimple-pretty-print.c | 2 - > gcc/optabs.c | 28 +- > gcc/optabs.h | 5 --- > gcc/tree-cfg.c | 2 - > gcc/tree-inline.c | 2 - > gcc/tree-pretty-print.c | 16 > gcc/tree-vect-data-refs.c | 86 ++-- > gcc/tree-vect-generic.c | 4 +-- > gcc/tree-vect-stmts.c | 14 > gcc/tree-vectorizer.h | 1 + > gcc/tree.def | 4 -- > 18 files changed, 77 insertions(+), 158 deletions(-) > > diff --git a/gcc/cfgexpand.c b/gcc/cfgexpand.c > index 8684721..8d2d34d 100644 > --- a/gcc/cfgexpand.c > +++ b/gcc/cfgexpand.c > @@ -3449,8 +3449,6 @@ expand_debug_expr (tree exp) > case VEC_COND_EXPR: > case VEC_EXTRACT_EVEN_EXPR: > case VEC_EXTRACT_ODD_EXPR: > - case VEC_INTERLEAVE_HIGH_EXPR: > - case VEC_INTERLEAVE_LOW_EXPR: > case VEC_LSHIFT_EXPR: > case VEC_PACK_FIX_TRUNC_EXPR: > case VEC_PACK_SAT_EXPR: > diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c > index 1638799..439c55f 100644 > --- a/gcc/config/i386/i386.c > +++ b/gcc/config/i386/i386.c > @@ -36013,6 +36013,8 @@ expand_vec_perm_palignr (struct expand_vec_perm_d *d) > return ok; > } > > +static bool expand_vec_perm_interleave3 (struct expand_vec_perm_d *d); > + > /* A subroutine of ix86_expand_vec_perm_builtin_1. Try to simplify > a two vector permutation into a single vector permutation by using > an interleave operation to merge the vectors. */ > @@ -36039,6 +36041,17 @@ expand_vec_perm_interleave2 (struct > expand_vec_perm_d *d) > /* For 32-byte modes allow even d->op0 == d->op1. > The lack of cross-lane shuffling in some instructions > might prevent a single insn shuffle. */ > + dfinal = *d; > + dfinal.testing_p = true; > + /* If expand_vec_perm_interleave3 can expand this into > + a 3 insn sequence, give up and let it be expanded as > + 3 insn sequence. While that is one insn longer, > + it doesn't need a memory operand and in the common > + case that both interleave low and high permutations > + with the same operands are adjacent needs 4 insns > + for both after CSE. */ > + if (expand_vec_perm_interleave3 (&dfinal)) > + return false; > } > else > return false; > @@ -36878,18 +36891,23 @@ expand_vec_perm_broadcast_1 (struct > expa
Re: [PATCH] Optimize away unnecessary clobbers (PR tree-optimization/51117)
On Fri, Dec 9, 2011 at 1:24 AM, Richard Henderson wrote: > On 12/08/2011 04:00 PM, Jakub Jelinek wrote: >> On Thu, Dec 08, 2011 at 03:53:40PM -0800, Richard Henderson wrote: >>> On 12/08/2011 11:57 AM, Jakub Jelinek wrote: + else if (gimple_code (last) == GIMPLE_RETURN + || (gimple_code (last) == GIMPLE_RESX + && stmt_can_throw_external (last))) + optimize_clobbers (bb); >>> >>> If you need to do this for returns as well as resx, then >>> this is the wrong place, since we'll only get here if there >>> are exception regions in the current function. >> >> I don't need to do it for returns, on the other side those clobbers >> before return are useless and removing them perhaps might decrease >> memory consumptions (after collect). >> >> But if you prefer to keep it just for GIMPLE_RESX, fine with me. >> >> It can be done anywhere else after inlining and before ehcleanup2 >> too if you have suggestions where to do it instead. > > *shrug* Maybe just a new pass immediately before ehcleanup2? > It's just a quick pass over the basic blocks... I'd just not care for the ones preceeding a return. Not at this point at least. Richard. > > r~
Re: PATCH: PR bootstrap/51479: Missing dependency on errors.o causes bootstrap failure
On Fri, Dec 9, 2011 at 7:17 AM, H.J. Lu wrote: > gcc/Makefile.in has > > gengtype$(exeext) : gengtype.o gengtype-lex.o gengtype-parse.o \ > gengtype-state.o version.o errors.o $(LIBDEPS) > +$(LINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ \ > $(filter-out ($LIBDEPS), $^) $(LIBS) > > However, there is no errors.o dependency, which leads to random > parallel build failures. This patch adds errors.o dependency. OK > for trunk and release branches? Ok. (the 4.5 and 4.6 branches already have dependencies for error.o, did they get lost somehow? Consider placing the error.o dependency at the same old place to ease diffs) Thanks, Richard. > Thanks. > > H.J. > --- > 2011-12-08 H.J. Lu > > PR bootstrap/51479 > * Makefile.in (errors.o): New. > > diff --git a/gcc/Makefile.in b/gcc/Makefile.in > index ae4f4da..83f70fa 100644 > --- a/gcc/Makefile.in > +++ b/gcc/Makefile.in > @@ -3947,6 +3947,8 @@ build/genautomata$(build_exeext) : BUILD_LIBS += -lm > build/gengtype$(build_exeext) : build/gengtype-lex.o build/gengtype-parse.o \ > build/gengtype-state.o build/version.o build/errors.o > > +errors.o : errors.c $(CONFIG_H) $(SYSTEM_H) errors.h > + > gengtype$(exeext) : gengtype.o gengtype-lex.o gengtype-parse.o \ > gengtype-state.o version.o errors.o $(LIBDEPS) > +$(LINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ \
Re: [PATCH] Prevent 'control reaches end of non-void function' warning for DO_WHILE
On Fri, Dec 9, 2011 at 9:38 AM, Tom de Vries wrote:
> Jakub,
>
> This patch fixes the problem reported in
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25973#c4 .
>
> The test-case listed there is:
> ...
> struct Block
> {
> public:
> Block();
> ~Block();
> };
>
> bool func( bool bar )
> {
> Block block;
> bool foo = false;
>
> if( !foo || bar )
> do { return true; } while( 0 );
> else
> do { return false; } while( 0 );
> }
> ...
>
> For O0, a spurious warning is generated:
> ...
> $ gcc -O0 -Wreturn-type block.C -S:
> block.C: In function ‘bool func(bool)’:
> block.C:17:1: warning: control reaches end of non-void function
> [-Wreturn-type]
> ...
>
> Basically the patch tries to handle DO_STMT in block_may_fallthru, but since
> it's a cp-tree.def tree, it's done via a language hook.
>
> Improving block_may_fallthru helps code in gimplify.c:shortcut_cond_expr() to
> prevent the superfluous warning:
> ...
> /* We only emit the jump over the else clause if we have to--if the
> then clause may fall through. Otherwise we can wind up with a
> useless jump and a useless label at the end of gimplified code,
> which will cause us to think that this conditional as a whole
> falls through even if it doesn't. If we then inline a function
> which ends with such a condition, that can cause us to issue an
> inappropriate warning about control reaching the end of a
> non-void function. */
> jump_over_else = block_may_fallthru (then_);
> ...
>
> Bootstrapped and reg-tested on x86_64.
>
> OK for next stage1?
Hm. I would prefer if the gimplifier is fed GENERIC, not
GENERIC plus FE specific codes ... (both C and C++ do
"genericization" passes, but they actually do not transform
all code to GENERIC). Can you check if it's easy enough to
lower DO_STMT during cp_genericize?
Thanks,
Richard.
> Thanks,
> - Tom
>
Re: {patch ira-color.c]: Fix printf-formatter use for long-long type for windows native targets.
On Fri, Dec 9, 2011 at 9:51 AM, Kai Tietz wrote:
> Hi,
>
> this patch fixes for windows native target print-formatter used about
> long-long type.
>
> ChangeLog
>
> 2011-12-09 Kai Tietz
>
> * ira-color.c (print_hard_regs_subforest): Use
> HOST_WIDEST_INT_PRINT_DEC instead of %lld.
>
> Tested for i686-w64-mingw32, x86_64-w64-mingw32, and
> x86_64-unknown-linux-gnu. Ok for apply?
Hm? struct allocno_hard_regs uses a long long int cost member,
so why is %lld wrong? If it doesn't work then you should change
the cost member to use HOST_WIDEST_INT as well I guess
(and verify all (indirect) uses).
Richard.
> Kai
>
> Index: ira-color.c
> ===
> --- ira-color.c (revision 182092)
> +++ ira-color.c (working copy)
> @@ -498,7 +498,8 @@
> fprintf (f, " ");
> fprintf (f, "%d:(", node->preorder_num);
> print_hard_reg_set (f, node->hard_regs->set, false);
> - fprintf (f, ")@%lld\n", node->hard_regs->cost);
> + fprintf (f, ")@" HOST_WIDEST_INT_PRINT_DEC "\n",
> + (HOST_WIDEST_INT) node->hard_regs->cost);
> print_hard_regs_subforest (f, node->first, level + 1);
> }
> }
Re: {patch implicit-zee.c]: Fix printf-formatter use for long-long type for windows native targets.
On Fri, Dec 9, 2011 at 9:52 AM, Kai Tietz wrote: > Hi, > > this patch fixes for windows native target print-formatter used about > long-long type. > > ChangeLog > > 2011-12-09 Kai Tietz > > * implicit-zee.c (find_and_remove_ze): Use > HOST_WIDEST_INT_PRINT_DEC instead of %lld. > > Tested for i686-w64-mingw32, x86_64-w64-mingw32, and > x86_64-unknown-linux-gnu. Ok for apply? Just change num_realized and num_ze_opportunities to type long. Richard. > Kai > > Index: implicit-zee.c > === > --- implicit-zee.c (revision 182092) > +++ implicit-zee.c (working copy) > @@ -944,10 +944,12 @@ > VEC_free (rtx, heap, zeinsn_del_list); > > if (dump_file && num_ze_opportunities > 0) > - fprintf (dump_file, "\n %s : num_zee_opportunities = %lld " > - "num_realized = %lld \n", > + fprintf (dump_file, "\n %s : num_zee_opportunities = " > + HOST_WIDEST_INT_PRINT_DEC > + " num_realized = " HOST_WIDEST_INT_PRINT_DEC "\n", > current_function_name (), > - num_ze_opportunities, num_realized); > + (HOST_WIDEST_INT) num_ze_opportunities, > + (HOST_WIDEST_INT) num_realized); > > df_finish_pass (false); > return 0;
Re: {patch ira-color.c]: Fix printf-formatter use for long-long type for windows native targets.
2011/12/9 Richard Guenther : > On Fri, Dec 9, 2011 at 9:51 AM, Kai Tietz wrote: >> Hi, >> >> this patch fixes for windows native target print-formatter used about >> long-long type. >> >> ChangeLog >> >> 2011-12-09 Kai Tietz >> >> * ira-color.c (print_hard_regs_subforest): Use >> HOST_WIDEST_INT_PRINT_DEC instead of %lld. >> >> Tested for i686-w64-mingw32, x86_64-w64-mingw32, and >> x86_64-unknown-linux-gnu. Ok for apply? > > Hm? struct allocno_hard_regs uses a long long int cost member, > so why is %lld wrong? If it doesn't work then you should change > the cost member to use HOST_WIDEST_INT as well I guess > (and verify all (indirect) uses). > > Richard. Issue is that the printf-formatter %ll doesn't necessarily is present for windows native targets. For these targets the formatter is %I64 here instead. Kai
Re: {patch ira-color.c]: Fix printf-formatter use for long-long type for windows native targets.
On Fri, Dec 9, 2011 at 10:58 AM, Kai Tietz wrote: > 2011/12/9 Richard Guenther : >> On Fri, Dec 9, 2011 at 9:51 AM, Kai Tietz wrote: >>> Hi, >>> >>> this patch fixes for windows native target print-formatter used about >>> long-long type. >>> >>> ChangeLog >>> >>> 2011-12-09 Kai Tietz >>> >>> * ira-color.c (print_hard_regs_subforest): Use >>> HOST_WIDEST_INT_PRINT_DEC instead of %lld. >>> >>> Tested for i686-w64-mingw32, x86_64-w64-mingw32, and >>> x86_64-unknown-linux-gnu. Ok for apply? >> >> Hm? struct allocno_hard_regs uses a long long int cost member, >> so why is %lld wrong? If it doesn't work then you should change >> the cost member to use HOST_WIDEST_INT as well I guess >> (and verify all (indirect) uses). >> >> Richard. > > Issue is that the printf-formatter %ll doesn't necessarily is present > for windows native targets. For these targets the formatter is %I64 > here instead. We seem to have HOST_LONG_LONG_FORMAT, why not use that? > Kai
Re: {patch implicit-zee.c]: Fix printf-formatter use for long-long type for windows native targets.
Fine, here is updated patch for it. Index: implicit-zee.c === --- implicit-zee.c (revision 182092) +++ implicit-zee.c (working copy) @@ -889,8 +889,8 @@ rtx curr_insn = NULL_RTX; int i; int ix; - long long num_realized = 0; - long long num_ze_opportunities = 0; + long num_realized = 0; + long num_ze_opportunities = 0; VEC (rtx, heap) *zeinsn_list; VEC (rtx, heap) *zeinsn_del_list; @@ -944,10 +944,10 @@ VEC_free (rtx, heap, zeinsn_del_list); if (dump_file && num_ze_opportunities > 0) -fprintf (dump_file, "\n %s : num_zee_opportunities = %lld " -"num_realized = %lld \n", -current_function_name (), -num_ze_opportunities, num_realized); +fprintf (dump_file, "\n %s : num_zee_opportunities = %ld" + " num_realized = %ld\n", +current_function_name (), num_ze_opportunities, +num_realized); df_finish_pass (false); return 0;
Re: {patch ira-color.c]: Fix printf-formatter use for long-long type for windows native targets.
2011/12/9 Richard Guenther : > On Fri, Dec 9, 2011 at 10:58 AM, Kai Tietz wrote: >> 2011/12/9 Richard Guenther : >>> On Fri, Dec 9, 2011 at 9:51 AM, Kai Tietz wrote: Hi, this patch fixes for windows native target print-formatter used about long-long type. ChangeLog 2011-12-09 Kai Tietz * ira-color.c (print_hard_regs_subforest): Use HOST_WIDEST_INT_PRINT_DEC instead of %lld. Tested for i686-w64-mingw32, x86_64-w64-mingw32, and x86_64-unknown-linux-gnu. Ok for apply? >>> >>> Hm? struct allocno_hard_regs uses a long long int cost member, >>> so why is %lld wrong? If it doesn't work then you should change >>> the cost member to use HOST_WIDEST_INT as well I guess >>> (and verify all (indirect) uses). >>> >>> Richard. >> >> Issue is that the printf-formatter %ll doesn't necessarily is present >> for windows native targets. For these targets the formatter is %I64 >> here instead. > > We seem to have HOST_LONG_LONG_FORMAT, why not use that? Well, HOST_LONG_LONG_FORMAT just specifies here the "ll"/"I64". Sure, we can use it here, too. But as HOST_WIDEST_INT_PRINT_DEC is defined as '"%" HOST_LONG_LONG_FORMAT "d", and other places are using it for this purpose, too, it looks to me more sane to use here the HOST_WIDEST_INT_PRINT_DEC directly. Kai
Re: {patch implicit-zee.c]: Fix printf-formatter use for long-long type for windows native targets.
On Fri, Dec 9, 2011 at 11:05 AM, Kai Tietz wrote: > Fine, here is updated patch for it. Ok. Thanks, Richard. > Index: implicit-zee.c > === > --- implicit-zee.c (revision 182092) > +++ implicit-zee.c (working copy) > @@ -889,8 +889,8 @@ > rtx curr_insn = NULL_RTX; > int i; > int ix; > - long long num_realized = 0; > - long long num_ze_opportunities = 0; > + long num_realized = 0; > + long num_ze_opportunities = 0; > VEC (rtx, heap) *zeinsn_list; > VEC (rtx, heap) *zeinsn_del_list; > > @@ -944,10 +944,10 @@ > VEC_free (rtx, heap, zeinsn_del_list); > > if (dump_file && num_ze_opportunities > 0) > - fprintf (dump_file, "\n %s : num_zee_opportunities = %lld " > - "num_realized = %lld \n", > - current_function_name (), > - num_ze_opportunities, num_realized); > + fprintf (dump_file, "\n %s : num_zee_opportunities = %ld" > + " num_realized = %ld\n", > + current_function_name (), num_ze_opportunities, > + num_realized); > > df_finish_pass (false); > return 0;
Re: {patch ira-color.c]: Fix printf-formatter use for long-long type for windows native targets.
On Fri, Dec 9, 2011 at 11:10 AM, Kai Tietz wrote: > 2011/12/9 Richard Guenther : >> On Fri, Dec 9, 2011 at 10:58 AM, Kai Tietz wrote: >>> 2011/12/9 Richard Guenther : On Fri, Dec 9, 2011 at 9:51 AM, Kai Tietz wrote: > Hi, > > this patch fixes for windows native target print-formatter used about > long-long type. > > ChangeLog > > 2011-12-09 Kai Tietz > > * ira-color.c (print_hard_regs_subforest): Use > HOST_WIDEST_INT_PRINT_DEC instead of %lld. > > Tested for i686-w64-mingw32, x86_64-w64-mingw32, and > x86_64-unknown-linux-gnu. Ok for apply? Hm? struct allocno_hard_regs uses a long long int cost member, so why is %lld wrong? If it doesn't work then you should change the cost member to use HOST_WIDEST_INT as well I guess (and verify all (indirect) uses). Richard. >>> >>> Issue is that the printf-formatter %ll doesn't necessarily is present >>> for windows native targets. For these targets the formatter is %I64 >>> here instead. >> >> We seem to have HOST_LONG_LONG_FORMAT, why not use that? > > Well, HOST_LONG_LONG_FORMAT just specifies here the "ll"/"I64". Sure, > we can use it here, too. But as HOST_WIDEST_INT_PRINT_DEC is defined > as '"%" HOST_LONG_LONG_FORMAT "d", and other places are using it for > this purpose, too, it looks to me more sane to use here the > HOST_WIDEST_INT_PRINT_DEC directly. Not on a 'long long int' type though (the use of 'long long' is questionable anyway, given it's not in C89 nor C++98). Richard. > Kai
Re: {patch ira-color.c]: Fix printf-formatter use for long-long type for windows native targets.
2011/12/9 Richard Guenther : > On Fri, Dec 9, 2011 at 11:10 AM, Kai Tietz wrote: >> 2011/12/9 Richard Guenther : >>> On Fri, Dec 9, 2011 at 10:58 AM, Kai Tietz wrote: 2011/12/9 Richard Guenther : > On Fri, Dec 9, 2011 at 9:51 AM, Kai Tietz wrote: >> Hi, >> >> this patch fixes for windows native target print-formatter used about >> long-long type. >> >> ChangeLog >> >> 2011-12-09 Kai Tietz >> >> * ira-color.c (print_hard_regs_subforest): Use >> HOST_WIDEST_INT_PRINT_DEC instead of %lld. >> >> Tested for i686-w64-mingw32, x86_64-w64-mingw32, and >> x86_64-unknown-linux-gnu. Ok for apply? > > Hm? struct allocno_hard_regs uses a long long int cost member, > so why is %lld wrong? If it doesn't work then you should change > the cost member to use HOST_WIDEST_INT as well I guess > (and verify all (indirect) uses). > > Richard. Issue is that the printf-formatter %ll doesn't necessarily is present for windows native targets. For these targets the formatter is %I64 here instead. >>> >>> We seem to have HOST_LONG_LONG_FORMAT, why not use that? >> >> Well, HOST_LONG_LONG_FORMAT just specifies here the "ll"/"I64". Sure, >> we can use it here, too. But as HOST_WIDEST_INT_PRINT_DEC is defined >> as '"%" HOST_LONG_LONG_FORMAT "d", and other places are using it for >> this purpose, too, it looks to me more sane to use here the >> HOST_WIDEST_INT_PRINT_DEC directly. > > Not on a 'long long int' type though (the use of 'long long' is > questionable anyway, given it's not in C89 nor C++98). > > Richard. Yes, the use of long long might be an extension in specific C/C++ standards. But isn't that exactly a reason to use HOST_WIDEST_INT type? As it allows at least to mark that type (if required) as __extension__? Kai
Re: {patch ira-color.c]: Fix printf-formatter use for long-long type for windows native targets.
On Fri, Dec 9, 2011 at 11:32 AM, Kai Tietz wrote: > 2011/12/9 Richard Guenther : >> On Fri, Dec 9, 2011 at 11:10 AM, Kai Tietz wrote: >>> 2011/12/9 Richard Guenther : On Fri, Dec 9, 2011 at 10:58 AM, Kai Tietz wrote: > 2011/12/9 Richard Guenther : >> On Fri, Dec 9, 2011 at 9:51 AM, Kai Tietz >> wrote: >>> Hi, >>> >>> this patch fixes for windows native target print-formatter used about >>> long-long type. >>> >>> ChangeLog >>> >>> 2011-12-09 Kai Tietz >>> >>> * ira-color.c (print_hard_regs_subforest): Use >>> HOST_WIDEST_INT_PRINT_DEC instead of %lld. >>> >>> Tested for i686-w64-mingw32, x86_64-w64-mingw32, and >>> x86_64-unknown-linux-gnu. Ok for apply? >> >> Hm? struct allocno_hard_regs uses a long long int cost member, >> so why is %lld wrong? If it doesn't work then you should change >> the cost member to use HOST_WIDEST_INT as well I guess >> (and verify all (indirect) uses). >> >> Richard. > > Issue is that the printf-formatter %ll doesn't necessarily is present > for windows native targets. For these targets the formatter is %I64 > here instead. We seem to have HOST_LONG_LONG_FORMAT, why not use that? >>> >>> Well, HOST_LONG_LONG_FORMAT just specifies here the "ll"/"I64". Sure, >>> we can use it here, too. But as HOST_WIDEST_INT_PRINT_DEC is defined >>> as '"%" HOST_LONG_LONG_FORMAT "d", and other places are using it for >>> this purpose, too, it looks to me more sane to use here the >>> HOST_WIDEST_INT_PRINT_DEC directly. >> >> Not on a 'long long int' type though (the use of 'long long' is >> questionable anyway, given it's not in C89 nor C++98). >> >> Richard. > > Yes, the use of long long might be an extension in specific C/C++ > standards. But isn't that exactly a reason to use HOST_WIDEST_INT > type? As it allows at least to mark that type (if required) as > __extension__? Your patch doesn't change the type of allocno_hard_regs.cost > Kai
Re: {patch ira-color.c]: Fix printf-formatter use for long-long type for windows native targets.
So this patch replace use of 'long long' in ira-color.c and in
ira-conflict.c by HOST_WIDEST_INT.
Kai
ChangeLog
2011-12-09 Kai Tietz
* ira-color.c (print_hard_regs_subforest): Use
HOST_WIDEST_INT_PRINT_DEC instead of %lld.
(allocno_hard_regs): Change type of cost member
to HOST_WIDEST_INT.
(add_allocno_hard_regs): Change type of argument cost
to HOST_WIDEST_INT.
* ira-conflict.c (build_conflict_bit_table): Replace use
of long-long by HOST_WIDEST_INT.
Tested for i686-w64-mingw32, x86_64-w64-mingw32, and
x86_64-unknown-linux-gnu. Ok for apply?
Kai
Index: ira-color.c
===
--- ira-color.c (revision 182092)
+++ ira-color.c (working copy)
@@ -53,7 +53,7 @@
HARD_REG_SET set;
/* Overall (spilling) cost of all allocnos with given register
set. */
- long long int cost;
+ HOST_WIDEST_INT cost;
};
typedef struct allocno_hard_regs_node *allocno_hard_regs_node_t;
@@ -229,7 +229,7 @@
/* Add (or update info about) allocno hard registers with SET and
COST. */
static allocno_hard_regs_t
-add_allocno_hard_regs (HARD_REG_SET set, long long int cost)
+add_allocno_hard_regs (HARD_REG_SET set, HOST_WIDEST_INT cost)
{
struct allocno_hard_regs temp;
allocno_hard_regs_t hv;
@@ -498,7 +498,7 @@
fprintf (f, " ");
fprintf (f, "%d:(", node->preorder_num);
print_hard_reg_set (f, node->hard_regs->set, false);
- fprintf (f, ")@%lld\n", node->hard_regs->cost);
+ fprintf (f, ")@" HOST_WIDEST_INT_PRINT_DEC "\n", node->hard_regs->cost);
print_hard_regs_subforest (f, node->first, level + 1);
}
}
Index: ira-conflicts.c
===
--- ira-conflicts.c (revision 182092)
+++ ira-conflicts.c (working copy)
@@ -116,8 +116,8 @@
= ((OBJECT_MAX (obj) - OBJECT_MIN (obj) + IRA_INT_BITS)
/ IRA_INT_BITS);
allocated_words_num += conflict_bit_vec_words_num;
- if ((unsigned long long) allocated_words_num * sizeof (IRA_INT_TYPE)
- > (unsigned long long) IRA_MAX_CONFLICT_TABLE_SIZE * 1024 * 1024)
+ if ((unsigned HOST_WIDEST_INT) allocated_words_num * sizeof
(IRA_INT_TYPE)
+ > (unsigned HOST_WIDEST_INT) IRA_MAX_CONFLICT_TABLE_SIZE * 1024 *
1024)
{
if (internal_flag_ira_verbose > 0 && ira_dump_file != NULL)
fprintf
Re: [RFA/ARM][Patch 01/02]: Thumb2 epilogue in RTL
On Thu, Dec 01, 2011 at 11:49:55AM +, Sameera Deshpande wrote: > > -- > -;; Note: this is not predicable, to avoid issues with linker-generated > -;; interworking stubs. > -(define_insn "*thumb2_return" > +(define_insn "*thumb2_rtl_epilogue_return" Rename to *thumb2_return >[(return)] > - "TARGET_THUMB2 && USE_RETURN_INSN (FALSE)" > + "(TARGET_THUMB2)" No need for paranthesis here. Otherwise OK. cheers Ramana
[PATCH] Fix PR51482
This makes sure to not have ENUM/BOOL component type vectors.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2011-12-09 Richard Guenther
PR tree-optimization/51482
* tree-vect-stmts.c (get_vectype_for_scalar_type_and_size):
Make sure to only create REAL_TYPE and INTEGER_TYPE component
vectors.
* g++.dg/torture/pr51482.C: New testcase.
Index: gcc/tree-vect-stmts.c
===
--- gcc/tree-vect-stmts.c (revision 182154)
+++ gcc/tree-vect-stmts.c (working copy)
@@ -5705,6 +5705,10 @@ get_vectype_for_scalar_type_and_size (tr
if (nbytes == 0)
return NULL_TREE;
+ if (GET_MODE_CLASS (inner_mode) != MODE_INT
+ && GET_MODE_CLASS (inner_mode) != MODE_FLOAT)
+return NULL_TREE;
+
/* We can't build a vector type of elements with alignment bigger than
their size. */
if (nbytes < TYPE_ALIGN_UNIT (scalar_type))
@@ -5713,16 +5717,15 @@ get_vectype_for_scalar_type_and_size (tr
/* For vector types of elements whose mode precision doesn't
match their types precision we use a element type of mode
precision. The vectorization routines will have to make sure
- they support the proper result truncation/extension. */
+ they support the proper result truncation/extension.
+ We also make sure to build vector types with INTEGER_TYPE
+ component type only. */
if (INTEGRAL_TYPE_P (scalar_type)
- && GET_MODE_BITSIZE (inner_mode) != TYPE_PRECISION (scalar_type))
+ && (GET_MODE_BITSIZE (inner_mode) != TYPE_PRECISION (scalar_type)
+ || TREE_CODE (scalar_type) != INTEGER_TYPE))
scalar_type = build_nonstandard_integer_type (GET_MODE_BITSIZE
(inner_mode),
TYPE_UNSIGNED (scalar_type));
- if (GET_MODE_CLASS (inner_mode) != MODE_INT
- && GET_MODE_CLASS (inner_mode) != MODE_FLOAT)
-return NULL_TREE;
-
/* We shouldn't end up building VECTOR_TYPEs of non-scalar components.
When the component mode passes the above test simply use a type
corresponding to that mode. The theory is that any use that
Index: gcc/testsuite/g++.dg/torture/pr51482.C
===
--- gcc/testsuite/g++.dg/torture/pr51482.C (revision 0)
+++ gcc/testsuite/g++.dg/torture/pr51482.C (revision 0)
@@ -0,0 +1,30 @@
+// { dg-do compile }
+
+typedef enum { CLASS_IN = 1, CLASS_OUT = -1 } FERGUSON_KEY_CLASS,
BEZIER_KEY_CLASS;
+typedef class flag_interface { } VECT3DF_SIMPLE;
+typedef struct vect3df {
+float x,y,z;
+} VECT3DF, VECT;
+typedef struct vect4df : public vect3df {
+float w;
+} VECT4DF, WVECT;
+typedef class llist_item { } ANIM_KEY;
+typedef class anim_track : public flag_interface, public llist_item { }
ANIM_KEY_BEZ;
+typedef class anim_track_bezier : public anim_track { } ANIM_KEY_BEZ_WVECT;
+typedef class anim_track_bez_wvect : public anim_track_bezier {
+WVECT * tangent(int kn, BEZIER_KEY_CLASS key_class, WVECT *p_tn);
+} ANIM_TRACK_BEZ_WVECT;
+WVECT * anim_track_bez_wvect::tangent(int kn, BEZIER_KEY_CLASS key_class,
WVECT *p_tn)
+{
+ float bias,continuity,tension,tn1,bp1;
+ WVECT *p_p0,*p_p1,*p_p2, t1, g1,g2,g3;
+ g1.x = (p_p1->x - p_p0->x)*bp1;
+ g1.y = (p_p1->y - p_p0->y)*bp1;
+ g1.z = (p_p1->z - p_p0->z)*bp1;
+ g1.w = (p_p1->w - p_p0->w)*bp1;
+ bp1 = (0.5f + key_class*0.5f*continuity);
+ p_tn->x = (g1.x + g3.x*bp1)*tn1;
+ p_tn->y = (g1.y + g3.y*bp1)*tn1;
+ p_tn->z = (g1.z + g3.z*bp1)*tn1;
+ p_tn->w = (g1.w + g3.w*bp1)*tn1;
+}
Re: PATCH: PR bootstrap/51479: Missing dependency on errors.o causes bootstrap failure
On Fri, 9 Dec 2011, Richard Guenther wrote: > On Fri, Dec 9, 2011 at 7:17 AM, H.J. Lu wrote: > > gcc/Makefile.in has > > > > gengtype$(exeext) : gengtype.o gengtype-lex.o gengtype-parse.o \ > > gengtype-state.o version.o errors.o $(LIBDEPS) > > +$(LINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ \ > > $(filter-out ($LIBDEPS), $^) $(LIBS) > > > > However, there is no errors.o dependency, which leads to random > > parallel build failures. This patch adds errors.o dependency. OK > > for trunk and release branches? > > Ok. (the 4.5 and 4.6 branches already have dependencies for error.o, > did they get lost somehow? Consider placing the error.o dependency > at the same old place to ease diffs) errors.c ceased to be used for the host with my 2011-05-20 Joseph Myers * Makefile.in (LIBDEPS): Add libcommon.a. [...] patch that made installed host programs consistently use the common diagnostics infrastructure. So that patch removed the dependencies. It appears that 2011-08-04 Romain Geissler * gengtype-state.c: Include "bconfig.h" if [...] then reintroduced use of errors.o on the host by making gengtype an installed program. -- Joseph S. Myers jos...@codesourcery.com
Re: {patch ira-color.c]: Fix printf-formatter use for long-long type for windows native targets.
On Fri, Dec 9, 2011 at 12:00 PM, Kai Tietz wrote:
> So this patch replace use of 'long long' in ira-color.c and in
> ira-conflict.c by HOST_WIDEST_INT.
Ok.
Thanks,
Richard.
> Kai
>
> ChangeLog
>
> 2011-12-09 Kai Tietz
>
> * ira-color.c (print_hard_regs_subforest): Use
> HOST_WIDEST_INT_PRINT_DEC instead of %lld.
> (allocno_hard_regs): Change type of cost member
> to HOST_WIDEST_INT.
> (add_allocno_hard_regs): Change type of argument cost
> to HOST_WIDEST_INT.
> * ira-conflict.c (build_conflict_bit_table): Replace use
> of long-long by HOST_WIDEST_INT.
>
> Tested for i686-w64-mingw32, x86_64-w64-mingw32, and
> x86_64-unknown-linux-gnu. Ok for apply?
>
> Kai
>
> Index: ira-color.c
> ===
> --- ira-color.c (revision 182092)
> +++ ira-color.c (working copy)
> @@ -53,7 +53,7 @@
> HARD_REG_SET set;
> /* Overall (spilling) cost of all allocnos with given register
> set. */
> - long long int cost;
> + HOST_WIDEST_INT cost;
> };
>
> typedef struct allocno_hard_regs_node *allocno_hard_regs_node_t;
> @@ -229,7 +229,7 @@
> /* Add (or update info about) allocno hard registers with SET and
> COST. */
> static allocno_hard_regs_t
> -add_allocno_hard_regs (HARD_REG_SET set, long long int cost)
> +add_allocno_hard_regs (HARD_REG_SET set, HOST_WIDEST_INT cost)
> {
> struct allocno_hard_regs temp;
> allocno_hard_regs_t hv;
> @@ -498,7 +498,7 @@
> fprintf (f, " ");
> fprintf (f, "%d:(", node->preorder_num);
> print_hard_reg_set (f, node->hard_regs->set, false);
> - fprintf (f, ")@%lld\n", node->hard_regs->cost);
> + fprintf (f, ")@" HOST_WIDEST_INT_PRINT_DEC "\n",
> node->hard_regs->cost);
> print_hard_regs_subforest (f, node->first, level + 1);
> }
> }
> Index: ira-conflicts.c
> ===
> --- ira-conflicts.c (revision 182092)
> +++ ira-conflicts.c (working copy)
> @@ -116,8 +116,8 @@
> = ((OBJECT_MAX (obj) - OBJECT_MIN (obj) + IRA_INT_BITS)
> / IRA_INT_BITS);
> allocated_words_num += conflict_bit_vec_words_num;
> - if ((unsigned long long) allocated_words_num * sizeof (IRA_INT_TYPE)
> - > (unsigned long long) IRA_MAX_CONFLICT_TABLE_SIZE * 1024 * 1024)
> + if ((unsigned HOST_WIDEST_INT) allocated_words_num * sizeof
> (IRA_INT_TYPE)
> + > (unsigned HOST_WIDEST_INT) IRA_MAX_CONFLICT_TABLE_SIZE * 1024 *
> 1024)
> {
> if (internal_flag_ira_verbose > 0 && ira_dump_file != NULL)
> fprintf
[committed] Another 4.6 backport (PR tree-optimization/50078)
Hi!
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to 4.6
branch.
2011-12-09 Jakub Jelinek
Backport from mainline
2011-12-08 Jakub Jelinek
PR tree-optimization/51466
* tree-ssa-forwprop.c (forward_propagate_addr_expr_1): Also copy
TREE_SIDE_EFFECTS.
* gcc.c-torture/execute/pr51466.c: New test.
2011-11-28 Jakub Jelinek
PR tree-optimization/50078
* tree-ssa-forwprop.c (forward_propagate_addr_expr_1): Copy over
TREE_THIS_VOLATILE also from the old to new lhs resp. rhs.
* gcc.dg/pr50078.c: New test.
--- gcc/tree-ssa-forwprop.c (revision 181785)
+++ gcc/tree-ssa-forwprop.c (revision 181786)
@@ -872,7 +872,7 @@ forward_propagate_addr_expr_1 (tree name
TREE_TYPE (gimple_assign_rhs1 (use_stmt
{
tree *def_rhs_basep = &TREE_OPERAND (def_rhs, 0);
- tree new_offset, new_base, saved;
+ tree new_offset, new_base, saved, new_lhs;
while (handled_component_p (*def_rhs_basep))
def_rhs_basep = &TREE_OPERAND (*def_rhs_basep, 0);
saved = *def_rhs_basep;
@@ -892,8 +892,11 @@ forward_propagate_addr_expr_1 (tree name
new_base, new_offset);
TREE_THIS_VOLATILE (*def_rhs_basep) = TREE_THIS_VOLATILE (lhs);
+ TREE_SIDE_EFFECTS (*def_rhs_basep) = TREE_SIDE_EFFECTS (lhs);
TREE_THIS_NOTRAP (*def_rhs_basep) = TREE_THIS_NOTRAP (lhs);
- gimple_assign_set_lhs (use_stmt,
-unshare_expr (TREE_OPERAND (def_rhs, 0)));
+ new_lhs = unshare_expr (TREE_OPERAND (def_rhs, 0));
+ gimple_assign_set_lhs (use_stmt, new_lhs);
+ TREE_THIS_VOLATILE (new_lhs) = TREE_THIS_VOLATILE (lhs);
+ TREE_SIDE_EFFECTS (new_lhs) = TREE_SIDE_EFFECTS (lhs);
*def_rhs_basep = saved;
tidy_after_forward_propagate_addr (use_stmt);
/* Continue propagating into the RHS if this was not the
@@ -953,7 +954,7 @@ forward_propagate_addr_expr_1 (tree name
TREE_TYPE (TREE_OPERAND (def_rhs, 0
{
tree *def_rhs_basep = &TREE_OPERAND (def_rhs, 0);
- tree new_offset, new_base, saved;
+ tree new_offset, new_base, saved, new_rhs;
while (handled_component_p (*def_rhs_basep))
def_rhs_basep = &TREE_OPERAND (*def_rhs_basep, 0);
saved = *def_rhs_basep;
@@ -973,8 +974,11 @@ forward_propagate_addr_expr_1 (tree name
new_base, new_offset);
TREE_THIS_VOLATILE (*def_rhs_basep) = TREE_THIS_VOLATILE (rhs);
+ TREE_SIDE_EFFECTS (*def_rhs_basep) = TREE_SIDE_EFFECTS (rhs);
TREE_THIS_NOTRAP (*def_rhs_basep) = TREE_THIS_NOTRAP (rhs);
- gimple_assign_set_rhs1 (use_stmt,
- unshare_expr (TREE_OPERAND (def_rhs, 0)));
+ new_rhs = unshare_expr (TREE_OPERAND (def_rhs, 0));
+ gimple_assign_set_rhs1 (use_stmt, new_rhs);
+ TREE_THIS_VOLATILE (new_rhs) = TREE_THIS_VOLATILE (rhs);
+ TREE_SIDE_EFFECTS (new_rhs) = TREE_SIDE_EFFECTS (rhs);
*def_rhs_basep = saved;
fold_stmt_inplace (use_stmt);
tidy_after_forward_propagate_addr (use_stmt);
--- gcc/testsuite/gcc.dg/pr50078.c (revision 0)
+++ gcc/testsuite/gcc.dg/pr50078.c (revision 181786)
@@ -0,0 +1,14 @@
+/* PR tree-optimization/50078 */
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+unsigned nonvolvar[2];
+
+void
+test (int arg)
+{
+ unsigned v = *(volatile unsigned *) (&nonvolvar[arg]);
+ *(volatile unsigned *) (&nonvolvar[arg]) = v;
+}
+
+/* { dg-final { scan-assembler-times "movl\[^\n\r\]*nonvolvar" 2 { target { {
i?86-*-* x86_64-*-* } && nonpic } } } } */
--- gcc/testsuite/gcc.c-torture/execute/pr51466.c.jj2011-12-08
15:25:42.084966108 +0100
+++ gcc/testsuite/gcc.c-torture/execute/pr51466.c 2011-12-08
15:25:18.0 +0100
@@ -0,0 +1,43 @@
+/* PR tree-optimization/51466 */
+
+extern void abort (void);
+
+__attribute__((noinline, noclone)) int
+foo (int i)
+{
+ volatile int v[4];
+ int *p;
+ v[i] = 6;
+ p = (int *) &v[i];
+ return *p;
+}
+
+__attribute__((noinline, noclone)) int
+bar (int i)
+{
+ volatile int v[4];
+ int *p;
+ v[i] = 6;
+ p = (int *) &v[i];
+ *p = 8;
+ return v[i];
+}
+
+__attribute__((noinline, noclone)) int
+baz (int i)
+{
+ volatile int v[4];
+ int *p;
+ v[i] = 6;
+ p = (int *) &v[0];
+ *p = 8;
+ return v[i];
+}
+
+int
+main ()
+{
+ if (foo (3) != 6 || bar (2) != 8 || baz (0) != 8 || baz (1) != 6)
+abort ();
+ return 0;
+}
Jakub
Re: PATCH: PR bootstrap/51479: Missing dependency on errors.o causes bootstrap failure
On 9 Dec 2011, at 11:27, Joseph S. Myers wrote: On Fri, 9 Dec 2011, Richard Guenther wrote: On Fri, Dec 9, 2011 at 7:17 AM, H.J. Lu wrote: gcc/Makefile.in has gengtype$(exeext) : gengtype.o gengtype-lex.o gengtype-parse.o \ gengtype-state.o version.o errors.o $(LIBDEPS) +$(LINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ \ $(filter-out ($LIBDEPS), $^) $(LIBS) However, there is no errors.o dependency, which leads to random parallel build failures. This patch adds errors.o dependency. OK for trunk and release branches? Ok. (the 4.5 and 4.6 branches already have dependencies for error.o, did they get lost somehow? Consider placing the error.o dependency at the same old place to ease diffs) errors.c ceased to be used for the host with my 2011-05-20 Joseph Myers * Makefile.in (LIBDEPS): Add libcommon.a. [...] patch that made installed host programs consistently use the common diagnostics infrastructure. So that patch removed the dependencies. It appears that 2011-08-04 Romain Geissler * gengtype-state.c: Include "bconfig.h" if [...] then reintroduced use of errors.o on the host by making gengtype an installed program. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49992 comment #6 contains a proposed solution to make the interfaces look the same so that it is not necessary to do this.. (although that bug was resolved by a different means, I still think it would be tidier to make the interfaces match - such that the appropriate one can be used for host/build. Iain
Re: [Patch] Increase array sizes in vect-tests to enable 256-bit vectorization
Hi, Richard, Accidentally, the first version of the patch (which contained changes in the original files without duplicating them, and which was approved by Ira Rosen) has already been checked-in to trunk - could you also approve reverting the original tests back? With this revert I'll also commit the last version of the patch. Michael On 7 December 2011 16:08, Richard Guenther wrote: > On Wed, Dec 7, 2011 at 11:27 AM, Michael Zolotukhin > wrote: >> Thanks, Richard. >> Should somebody else approve the patch or is it ok for commit to trunk? > > It's ok to commit. > > Richard. > >> On 5 December 2011 18:04, Richard Guenther >> wrote: >>> On Mon, Dec 5, 2011 at 2:28 PM, Michael Zolotukhin >>> wrote: > I'd just duplicate the tests you want to change to a larger array > size and change those duplicates accordingly, leaving the original > tests alone. Richard, I made the tests this way - please check them in the attached patch (it happened to be quite big). >>> >>> Works for me. >>> >>> Thanks, >>> Richard. >>> > There is vect_multiple_sizes for such cases. Ira, thanks! This flag would be useful to avoid fails on the original tests when they are compiled with mavx/mavx2 - I'll prepare a patch for this soon. On 5 December 2011 13:10, Richard Guenther wrote: > On Mon, Dec 5, 2011 at 9:48 AM, Ira Rosen wrote: >> >> >> gcc-patches-ow...@gcc.gnu.org wrote on 05/12/2011 10:39:07 AM: >> >>> From: Michael Zolotukhin >>> To: Richard Guenther >>> Cc: gcc-patches@gcc.gnu.org, izamya...@gmail.com >>> Date: 05/12/2011 10:39 AM >>> Subject: Re: [Patch] Increase array sizes in vect-tests to enable >>> 256-bit vectorization >>> Sent by: gcc-patches-ow...@gcc.gnu.org >>> >>> On 5 December 2011 10:14, Michael Zolotukhin >>> wrote: >>> > Ok, will several tests with short arrays be enough for that or should >>> > we keep all the original tests plus new ones with longer arrays? >>> >>> BTW, there is another problem with current tests with short arrays - >>> scans are expecting specific number of some diagnostic messages like >>> "not vectorized: unsupported unaligned store", and that number would >>> be different if several vector-lengths are available - so we'll have >>> fails in those tests. >> >> There is vect_multiple_sizes for such cases. > > I'd just duplicate the tests you want to change to a larger array > size and change those duplicates accordingly, leaving the original > tests alone. > > Richard. -- --- Best regards, Michael V. Zolotukhin, Software Engineer Intel Corporation. >> >> >> >> -- >> --- >> Best regards, >> Michael V. Zolotukhin, >> Software Engineer >> Intel Corporation. -- --- Best regards, Michael V. Zolotukhin, Software Engineer Intel Corporation.
Re: [PATCH] Optimize away unnecessary clobbers (PR tree-optimization/51117)
On Fri, Dec 09, 2011 at 10:35:57AM +0100, Richard Guenther wrote:
> > *shrug* Maybe just a new pass immediately before ehcleanup2?
> > It's just a quick pass over the basic blocks...
>
> I'd just not care for the ones preceeding a return. Not at this point
> at least.
After IRC discussion with richi I've committed the following:
2011-12-09 Jakub Jelinek
Andrew Pinski
PR tree-optimization/51117
* tree-eh.c (optimize_clobbers): New function.
(execute_lower_eh_dispatch): Call it.
--- gcc/tree-eh.c.jj2011-12-01 11:45:06.0 +0100
+++ gcc/tree-eh.c 2011-12-08 17:48:58.009908793 +0100
@@ -3173,6 +3173,30 @@ struct gimple_opt_pass pass_lower_resx =
}
};
+/* Try to optimize var = {v} {CLOBBER} stmts followed just by
+ external throw. */
+
+static void
+optimize_clobbers (basic_block bb)
+{
+ gimple_stmt_iterator gsi = gsi_last_bb (bb);
+ for (gsi_prev (&gsi); !gsi_end_p (gsi);)
+{
+ gimple stmt = gsi_stmt (gsi);
+ if (is_gimple_debug (stmt))
+ {
+ gsi_prev (&gsi);
+ continue;
+ }
+ if (!gimple_assign_single_p (stmt)
+ || TREE_CODE (gimple_assign_lhs (stmt)) == SSA_NAME
+ || !TREE_CLOBBER_P (gimple_assign_rhs1 (stmt)))
+ return;
+ unlink_stmt_vdef (stmt);
+ gsi_remove (&gsi, true);
+ release_defs (stmt);
+}
+}
/* At the end of inlining, we can lower EH_DISPATCH. Return true when
we have found some duplicate labels and removed some edges. */
@@ -3337,11 +3361,16 @@ execute_lower_eh_dispatch (void)
FOR_EACH_BB (bb)
{
gimple last = last_stmt (bb);
- if (last && gimple_code (last) == GIMPLE_EH_DISPATCH)
+ if (last == NULL)
+ continue;
+ if (gimple_code (last) == GIMPLE_EH_DISPATCH)
{
redirected |= lower_eh_dispatch (bb, last);
any_rewritten = true;
}
+ else if (gimple_code (last) == GIMPLE_RESX
+ && stmt_can_throw_external (last))
+ optimize_clobbers (bb);
}
if (redirected)
Jakub
Re: [Patch] Increase array sizes in vect-tests to enable 256-bit vectorization
On Fri, Dec 9, 2011 at 12:44 PM, Michael Zolotukhin wrote: > Hi, Richard, > Accidentally, the first version of the patch (which contained changes > in the original files without duplicating them, and which was approved > by Ira Rosen) has already been checked-in to trunk - could you also > approve reverting the original tests back? With this revert I'll also > commit the last version of the patch. Yes, reverting that is ok. > Michael > > On 7 December 2011 16:08, Richard Guenther wrote: >> On Wed, Dec 7, 2011 at 11:27 AM, Michael Zolotukhin >> wrote: >>> Thanks, Richard. >>> Should somebody else approve the patch or is it ok for commit to trunk? >> >> It's ok to commit. >> >> Richard. >> >>> On 5 December 2011 18:04, Richard Guenther >>> wrote: On Mon, Dec 5, 2011 at 2:28 PM, Michael Zolotukhin wrote: >> I'd just duplicate the tests you want to change to a larger array >> size and change those duplicates accordingly, leaving the original >> tests alone. > Richard, I made the tests this way - please check them in the attached > patch (it happened to be quite big). Works for me. Thanks, Richard. >> There is vect_multiple_sizes for such cases. > Ira, thanks! This flag would be useful to avoid fails on the original > tests when they are compiled with mavx/mavx2 - I'll prepare a patch > for this soon. > > On 5 December 2011 13:10, Richard Guenther > wrote: >> On Mon, Dec 5, 2011 at 9:48 AM, Ira Rosen wrote: >>> >>> >>> gcc-patches-ow...@gcc.gnu.org wrote on 05/12/2011 10:39:07 AM: >>> From: Michael Zolotukhin To: Richard Guenther Cc: gcc-patches@gcc.gnu.org, izamya...@gmail.com Date: 05/12/2011 10:39 AM Subject: Re: [Patch] Increase array sizes in vect-tests to enable 256-bit vectorization Sent by: gcc-patches-ow...@gcc.gnu.org On 5 December 2011 10:14, Michael Zolotukhin wrote: > Ok, will several tests with short arrays be enough for that or should > we keep all the original tests plus new ones with longer arrays? BTW, there is another problem with current tests with short arrays - scans are expecting specific number of some diagnostic messages like "not vectorized: unsupported unaligned store", and that number would be different if several vector-lengths are available - so we'll have fails in those tests. >>> >>> There is vect_multiple_sizes for such cases. >> >> I'd just duplicate the tests you want to change to a larger array >> size and change those duplicates accordingly, leaving the original >> tests alone. >> >> Richard. > > > > -- > --- > Best regards, > Michael V. Zolotukhin, > Software Engineer > Intel Corporation. >>> >>> >>> >>> -- >>> --- >>> Best regards, >>> Michael V. Zolotukhin, >>> Software Engineer >>> Intel Corporation. > > -- > --- > Best regards, > Michael V. Zolotukhin, > Software Engineer > Intel Corporation.
Re: [RFA/ARM][Patch 02/02]: ARM epilogue in RTL
>
> Bootstrap and gcc-check are passing without regression.
Sorry, it's taken me a while to get to this but I looked at this for
sometime last night and think this needs a bit of work .
1. Can the code for TARGET_APCS_FRAME be factored out into a separate
function from arm_expand_epilogue ?
Essentially factor out from arm_expand_epilogue:
if (TARGET_APCS_FRAME && frame_pointer_needed && TARGET_ARM)
+{
...
+}
2. I'm not happy about the amount of very similar code between ARM and
Thumb2 state as far as arm_expand_return / thumb2_expand_return and
arm_expand_epilogue / thumb2_expand_epilogue go. Could you try to
merge the 2 together into the same functions.
3. The return sequence of loading into PC from the stack has
disappeared . A simple test appeared to generate :
@ sp needed for prologue
ldr lr, [sp], #4
bx lr
instead of ldmfd sp!, {pc} atleast in the single return cases.
Which is still correct but sub-optimal.
4. A number of cases around *cond_return and *cond_return_inverted are
removed - This removes the chance for getting conditional returns from
the compiler - marking the return pattern as predicable doesn't really
generate conditional returns you really need the (if_then_else form).
5. This hunk here :
@@ -22741,6 +22646,7 @@ thumb2_expand_epilogue (void)
return-address' instruction. Instead, pop LR in PC. */
if (ARM_FUNC_TYPE (func_type) == ARM_FT_NORMAL
&& !IS_STACKALIGN (func_type)
+ && !is_sibling
&& crtl->args.pretend_args_size == 0
&& saved_regs_mask & (1 << LR_REGNUM)
&& !crtl->calls_eh_return)
This would be better off in the original Thumb2 RTL epilogues patch ?
6. This has missed out the hunk that deals with a ARM10 VFPr1 bug --
- /* Workaround ARM10 VFPr1 bug. */
- if (count == 2 && !arm_arch6)
-{
- if (reg == 15)
- reg--;
- count++;
-}
I'm not sure how many cores had this issue in the wild, but the
compiler has never generated things that went across from d15-d16 - We
seem to have always ended up loading something more into one of the
registers.
Next time please also submit a changelog entry - it makes it easier
to check and review as well. Its largely similar to your original
changelog but it's easier to find that in the mail with the patch
rather than ferret around in older mails.
cheers
Ramana
[PATCH] Fix PR48042
I'm testing the following to avoid ICEing when using LTO and
mismatched -g vs. -g0 during compile/link phase by not conditionally
clearing things in free_lang_data_in_decl.
(Similar code is in free_lang_data_in_type, but without a testcase
I don't want to remove it)
LTO bootstrap and regtest running on x86_64-unknown-linux-gnu.
Richard.
2011-12-09 Richard Guenther
PR lto/48042
* tree.c (free_lang_data_in_decl): Remove freeing conditional
on debuginfo level.
* g++.dg/lto/pr48042_0.C: New testcase.
Index: gcc/tree.c
===
--- gcc/tree.c (revision 182154)
+++ gcc/tree.c (working copy)
@@ -4600,11 +4591,6 @@ free_lang_data_in_decl (tree decl)
if (TREE_CODE (decl) == FIELD_DECL)
free_lang_data_in_one_sizepos (&DECL_FIELD_OFFSET (decl));
- /* DECL_FCONTEXT is only used for debug info generation. */
- if (TREE_CODE (decl) == FIELD_DECL
- && debug_info_level < DINFO_LEVEL_TERSE)
- DECL_FCONTEXT (decl) = NULL_TREE;
-
if (TREE_CODE (decl) == FUNCTION_DECL)
{
if (gimple_has_body_p (decl))
Index: gcc/testsuite/g++.dg/lto/pr48042_0.C
===
--- gcc/testsuite/g++.dg/lto/pr48042_0.C(revision 0)
+++ gcc/testsuite/g++.dg/lto/pr48042_0.C(revision 0)
@@ -0,0 +1,14 @@
+// { dg-lto-do link }
+// { dg-extra-ld-options "-r -nostdlib -g" }
+
+class A {
+virtual int x() = 0;
+};
+
+class B:public A {
+int x();
+};
+
+int B::x() {
+}
+
[PATCH] Fix PR46796
This fixes PR46796 by making sure the types in the type variant chain
can be looked up again using get_qualified_type.
LTO bootstrap and regtest running on x86_64-unknown-linux-gnu.
Richard.
2011-12-09 Richard Guenther
PR lto/46796
* lto.c (uniquify_nodes): Merge TYPE_DECLs in the
type variant chain.
Index: gcc/lto/lto.c
===
--- gcc/lto/lto.c (revision 182154)
+++ gcc/lto/lto.c (working copy)
@@ -860,6 +860,34 @@ uniquify_nodes (struct data_in *data_in,
if (t == NULL_TREE)
continue;
+ /* Perform very simple TYPE_DECL merging on the type variant
+chain here. That catches the cases in PR46796, where
+get_qualified_type fails to lookup an existing qualified
+type because TYPE_NAME are not pointer-equal. */
+ if (TYPE_P (t)
+ && TYPE_NAME (t)
+ && TREE_CODE (TYPE_NAME (t)) == TYPE_DECL)
+ {
+ tree tn = TYPE_NAME (t);
+ tree t2;
+ for (t2 = TYPE_MAIN_VARIANT (t); t2; t2 = TYPE_NEXT_VARIANT (t2))
+ {
+ tree t2n = TYPE_NAME (t2);
+ if (t2 == t
+ || t2n == tn)
+ continue;
+ if (t2n
+ && TREE_CODE (t2n) == TYPE_DECL
+ && TREE_TYPE (t2n) == TREE_TYPE (tn)
+ && DECL_NAME (t2n) == DECL_NAME (tn)
+ && DECL_SOURCE_LOCATION (t2n) == DECL_SOURCE_LOCATION (tn))
+ {
+ TYPE_NAME (t) = t2n;
+ break;
+ }
+ }
+ }
+
if (TREE_CODE (t) == VAR_DECL)
lto_register_var_decl_in_symtab (data_in, t);
else if (TREE_CODE (t) == FUNCTION_DECL && !DECL_BUILT_IN (t))
Re: [Ping] RE: CR16 Port addition
PING: For reviewing the modified CR16 port. Hello, Can some one please review the updated patch and let me know if any more changes are required to be done in it? The modified patch was posted at following URL: http://gcc.gnu.org/ml/gcc-patches/2011-11/msg02625.html Thanks and Regards, Jayant Sonar [KPIT Cummins, Pune]
Re: [PATCH] Fix PR middle-end/45416, missing opt for (a&(1<
Andrew Pinski wrote: > Hi, > After SSA-expand, the code which did the optimization for > (a&(1<>C)&1 became not working because BIT_AND_EXPR > would no longer be in there. This patch fixes the problem by using > get_def_for_expr to get the BIT_AND_EXPR. > > OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions. No, not OK. This leads to unacceptable code for devices that cannot shift easily like, e.g. AVR. This target can only shift by 1 and shifts with big offsets have to be performed by means of a loop at runtime. Instead of a single bit-test instruction than can test for a bit in place, the patch leads to very expensive shift! Please try code examples compiled for that target against the code form 4.6! Such transformation must not be performed unconditionally and not without looking at costs. Johann > Thanks, > Andrew Pinski > > ChangeLog: > * expr.c (do_store_flag): Rewrite code that looks for BIT_AND_EXPR for > SSA-expand. > > testsuite/ChangeLog: > * gcc.dg/pr45416.c: New testcase.
Re: [PATCH] Fix PR middle-end/45416, missing opt for (a&(1<
On Fri, Dec 09, 2011 at 01:50:37PM +0100, Georg-Johann Lay wrote: > No, not OK. > > This leads to unacceptable code for devices that cannot shift easily like, > e.g. > AVR. This target can only shift by 1 and shifts with big offsets have to be > performed by means of a loop at runtime. Andrew's patch only restored what GCC has been doing before. If this is too expensive on AVR, you should just arrange in the backend to combine that ((x>>C)&1) != 0 into more efficient code sequence, otherwise people who write if ((x >> 18) & 1) bar (); in the source will get suboptimal code. Jakub
Re: [PATCH] Remove dead labels to increase superblock scope
> 2011-12-07 Tom de Vries > > * cfgcleanup.c (try_optimize_cfg): Replace call to delete_isns_chain by delete_insn_chain > call to delete_insn. Remove code to reorder BASIC_BLOCK note and > DELETED_LABEL note, and move it to ... > * cfg_rtl.c (delete_insn): Change return type to void. The file is cfgrtl.c without underscore. When you have a "to..." somewhere, you need to have a "...here" somewhere else: * cfgrtl.c (delete_insn): ...here. Change return type to void. The hunk for delete_insn contains a line with trailing TABs and spaces. > (delete_insn_and_edges): Likewise. > (delete_insn_chain): Handle new return type of delete_insn. Delete > chain backwards rather than forwards. > * rtl.h (delete_insn, delete_insn_and_edges): Change return type to > void. > * cfglayout.c (fixup_reorder_chain): Delete unused label. > > * gcc.dg/superblock.c: New test. OK for stage1 when it re-opens (modulo the above nits). Nice cleanup! -- Eric Botcazou
Re: [PATCH] Fix PR middle-end/45416, missing opt for (a&(1<
Jakub Jelinek wrote: > On Fri, Dec 09, 2011 at 01:50:37PM +0100, Georg-Johann Lay wrote: >> No, not OK. >> >> This leads to unacceptable code for devices that cannot shift easily like, >> e.g. >> AVR. This target can only shift by 1 and shifts with big offsets have to be >> performed by means of a loop at runtime. > > Andrew's patch only restored what GCC has been doing before. > If this is too expensive on AVR, you should just arrange in the backend to > combine that > ((x>>C)&1) != 0 > into more efficient code sequence, otherwise people who write > if ((x >> 18) & 1) > bar (); > in the source will get suboptimal code. > > Jakub Still don't agree. If the backend is the right place to do such optimizations, why don't other targets do it there. Instead, their maintainers make assumptions on costs or instructions available that don't apply for all targets supported by GCC. There are hundreds of ways C code can write down this code. * if (a & (1 << bit)) return 1; else return 0; * if (a & (1 << bit)) return 1; return 0; * return (a & (1 << bit)) ? 1 : 0; * return ((a >> bit) & 1) ? 1 : 0; * a >>= bit; return a & 1; * return bitfield.bit; I don't think cluttering up the backend with myriads of combine patterns is the right way to approach this. Notice that above are just simple examples; if there is more context or other operators like !, |, & things will get even worse. Just imagine the various ways in C you can write down extracting bitx from val1 and insert it as bit_y in val2: You can user ternary expression, shift-and-mask-and-not-or, if-else construct, bitfields, or combinatiopn of them. The right way to handle is: 1) Canonicalize such code like - testing a bit - moving a bit - ... and canonicalize it early so that tree optimizers know what to look for 2) Upon tree -> RTL lowering look at the target's prefered way to accomplish this. The preferred way can be deduced from RTX costs. This is pretty much straight forward, and I don't understand the problems with - canonicalize stuff - optimize on canonicalized representation - lower canonicalized representation to best RTL Johann
Re: [PATCH] use -fno-pie on darwin in boehm-gc.exp
On 8 Dec 2011, at 20:55, Iain Sandoe wrote: ... but, I'll bow out at this juncture - OK, I lied :-) The boehm-gc tests pass for m32 and m64 with "-fpie/-fPIE" on both x86 Darwin9 (XC3.1.4) and x86_64 Darwin10 (XC3.2.5); I'm building with XC3.2.6 to check that too. So I think you need to debug what is actually failing on Darwin11. Iain
Re: RFA: Fix PR middle-end/40154
Quoting Richard Henderson :
+GEN_INT
+ (trunc_int_for_mode
While you're at it, or as a followup, this is combination is gen_int_mode.
I mis-read the patch the first time and thought you'd done this, but it's
a pre-existing condition.
I've checked in the attached as a follow-up patch.
2011-12-09 Joern Rennecke
* dse.c (get_stored_val, get_call_args): Use gen_int_mode.
* expmed.c (expand_divmod): Likewise.
* combine.c (simplify_if_then_else): Likewise.
Index: dse.c
===
--- dse.c (revision 182075)
+++ dse.c (working copy)
@@ -1950,7 +1950,7 @@ get_stored_val (store_info_t store_info,
c |= (c << shift);
shift <<= 1;
}
- read_reg = GEN_INT (trunc_int_for_mode (c, store_mode));
+ read_reg = gen_int_mode (c, store_mode);
read_reg = extract_low_bits (read_mode, store_mode, read_reg);
}
}
@@ -2459,7 +2459,7 @@ get_call_args (rtx call_insn, tree fn, r
{
if (!tmp || !CONST_INT_P (tmp))
return false;
- tmp = GEN_INT (trunc_int_for_mode (INTVAL (tmp), mode));
+ tmp = gen_int_mode (INTVAL (tmp), mode);
}
if (tmp)
args[idx] = tmp;
Index: expmed.c
===
--- expmed.c(revision 182162)
+++ expmed.c(working copy)
@@ -4216,10 +4216,9 @@ expand_divmod (int rem_flag, enum tree_c
<< (HOST_BITS_PER_WIDE_INT - 1)))
set_dst_reg_note (insn, REG_EQUAL,
gen_rtx_DIV (compute_mode, op0,
-GEN_INT
- (trunc_int_for_mode
-(abs_d,
- compute_mode))),
+gen_int_mode
+ (abs_d,
+ compute_mode)),
quotient);
quotient = expand_unop (compute_mode, neg_optab,
Index: combine.c
===
--- combine.c (revision 182075)
+++ combine.c (working copy)
@@ -6010,7 +6010,7 @@ simplify_if_then_else (rtx x)
&& exact_log2 (nzb = nonzero_bits (from, GET_MODE (from))) >= 0)
{
false_code = EQ;
- false_val = GEN_INT (trunc_int_for_mode (nzb, GET_MODE (from)));
+ false_val = gen_int_mode (nzb, GET_MODE (from));
}
else if (true_code == EQ && true_val == const0_rtx
&& (num_sign_bit_copies (from, GET_MODE (from))
Fix ThreadSanitizer pass required properties (issue5477053)
This is for google-main branch. Fix ThreadSanitizer pass required properties. Turned out that PROP_gimple_lomp is not always present. Index: gcc/tree-tsan.c === --- gcc/tree-tsan.c (revision 182099) +++ gcc/tree-tsan.c (working copy) @@ -,7 +,7 @@ NULL, /* next */ 0,/* static_pass_number */ TV_NONE, /* tv_id */ - PROP_trees | PROP_cfg,/* properties_required */ + PROP_ssa | PROP_cfg, /* properties_required */ 0,/* properties_provided */ 0,/* properties_destroyed */ 0,/* todo_flags_start */ Index: gcc/ChangeLog.google-main === --- gcc/ChangeLog.google-main (revision 182099) +++ gcc/ChangeLog.google-main (working copy) @@ -1,3 +1,8 @@ +2011-12-09 Dmitriy Vyukov + + Fix ThreadSanitizer pass required properties. +* gcc/tree-tsan.c (pass_tsan): Replace PROP_trees with PROP_ssa. + 2011-12-05 Dmitriy Vyukov Fix taking address of SSA_NAME in ThreadSanitizer pass. -- This patch is available for review at http://codereview.appspot.com/5477053
Re: [PATCH] use -fno-pie on darwin in boehm-gc.exp
On Fri, Dec 09, 2011 at 02:09:54PM +, Iain Sandoe wrote: > > On 8 Dec 2011, at 20:55, Iain Sandoe wrote: >> ... but, I'll bow out at this juncture - > > OK, I lied :-) > > The boehm-gc tests pass for m32 and m64 with "-fpie/-fPIE" on both x86 > Darwin9 (XC3.1.4) and x86_64 Darwin10 (XC3.2.5); > I'm building with XC3.2.6 to check that too. > > So I think you need to debug what is actually failing on Darwin11. > > Iain Iain, I did a bit of experimentation with Xcode 4.2 on 10.6.8 and 10.7.2 with the failing gctest test case. 1) On 10.6.8 using Xcode 4.2 and a previous gcc trunk build, if I do a 'make clean' in /sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/x86_64-apple-darwin10.8.0/boehm-gc after editing the Makefile there to have... CFLAGS = -g -O2 -Wl,-pie and then manually rebuild the gctest case with the same flags, it runs fine on darwin10 but segfaults on darwin11. Interestingly, I can get it to run without crashing on darwin11 if I run it within gdb. 2) On 10.7.2 using Xcode 4.2 and a previous gcc trunk build, if I do a 'make clean' in /sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/x86_64-apple-darwin11.2.0/boehm-gc after editing the Makefile there to have... CFLAGS = -g -O2 -mmacosx-version-min=10.6 -Wl,-pie and then manually rebuild the gctest case with the same flags, the resulting binary still crashes on darwin11 but runs fine on darwin10. FYI, I also copied libgcjgc.1.dylib from the appropriate build and set DYLD_LIBRARY_PATH as required in each case. I am assuming these observations suggest that we are seeing a new bug in the darwin11 unwinder. I'll open a radar for this tonight with a standalone test case based on gctest that the darwin linker developer can walk through the darwin11 unwinder. Jack
Re: [PATCH] PR c++/51289 - ICE with alias template for bound template
OK. Jason
[PATCH][Cilkplus] 1D Array Notation Triplet Implementation
Hello Everyone,
This patch is for the Cilkplus branch affecting only the C compiler. This
patch will implement the 1D array notation triplets. Array notations are
indented to allow users directly express high-level parallel vector operations
in the code. More information about array notations can be obtained from the
Cilk Plus Language reference manual: http://software.intel.com/file/40278.
Thanks,
Balaji V. Iyer.diff --git a/gcc/ChangeLog.cilk b/gcc/ChangeLog.cilk
index d6e9cba..6d2b694 100644
--- a/gcc/ChangeLog.cilk
+++ b/gcc/ChangeLog.cilk
@@ -1,3 +1,23 @@
+2011-12-09 Balaji V. Iyer
+
+ * c-typeck.c (build_array_notation_expr): New function.
+ * c-parser.c (c_parser_array_notation): Likewise.
+ (c_parser_array_notation): Likewise.
+ (c_parser_expr_no_commas): Added if statement to handle ARRAY_NOTATION.
+ (c_parser_postfix_expression_after_primary): Added a check to see
+ if ARRAY NOTATION was used, and if so then added appropriate code to
+ handle it.
+ * gimplify.c (gimplify_expr): Added a case for ARRAY_NOTATION_REF.
+ * tree.def (ARRAY_NOTATION_REF): New tree-type for array_notation.
+ * tree.h (ARRAY_NOTATION_CHECK): New define for ARRAY_NOTATION TREE
+ (ARRAY_NOTATION_ARRAY): Likewise.
+ (ARRAY_NOTATION_START): Likewise.
+ (ARRAY_NOTATION_END): Likewise.
+ (ARRAY_NOTATION_STRIDE): Likewise.
+ (ARRAY_NOTATION_TYPE): Likewise.
+ * tree-vectorizer.c (vectorize_loops): Added the function call
+ optimize_loop_nest_for_speed_p () into the if-loop.
+
2011-12-02 Balaji V. Iyer
* cilk.c (create_metadata_label): Make notes instead of CODE_LABEL.
diff --git a/gcc/c-family/ChangeLog.cilk b/gcc/c-family/ChangeLog.cilk
index 720d552..5e57983 100644
--- a/gcc/c-family/ChangeLog.cilk
+++ b/gcc/c-family/ChangeLog.cilk
@@ -1,3 +1,7 @@
+2011-12-09 Balaji V. Iyer
+
+ * c-common.h: Added build_array_notation_expr prototype.
+
2011-08-08 Balaji V. Iyer
* c-common.c (c_common_reswords[]): Added "cilk_for", "cilk_spawn"
and "cilk_sync" keywords.]
diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h
index d7fb0a7..ef687fe 100644
--- a/gcc/c-family/c-common.h
+++ b/gcc/c-family/c-common.h
@@ -549,6 +549,8 @@ extern tree pushdecl_top_level (tree);
extern tree pushdecl (tree);
extern tree build_modify_expr (location_t, tree, tree, enum tree_code,
location_t, tree, tree);
+extern tree build_array_notation_expr (location_t, tree, tree, enum tree_code,
+ location_t, tree, tree);
extern tree build_indirect_ref (location_t, tree, ref_operator);
extern int c_expand_decl (tree);
diff --git a/gcc/c-parser.c b/gcc/c-parser.c
index 0ca816e..ec78eeb 100644
--- a/gcc/c-parser.c
+++ b/gcc/c-parser.c
@@ -1252,7 +1252,7 @@ void c_parser_simd_private(c_parser *);
void c_parser_simd_assert(c_parser *, bool);
void c_parser_simd_vectorlength (c_parser *);
void c_parser_simd_reduction (c_parser *);
-
+static tree c_parser_array_notation (c_parser *, tree, tree);
/* Parse a translation unit (C90 6.7, C99 6.9).
translation-unit:
@@ -5455,9 +5455,21 @@ c_parser_expr_no_commas (c_parser *parser, struct c_expr
*after)
exp_location = c_parser_peek_token (parser)->location;
rhs = c_parser_expr_no_commas (parser, NULL);
rhs = default_function_array_read_conversion (exp_location, rhs);
- ret.value = build_modify_expr (op_location, lhs.value, lhs.original_type,
-code, exp_location, rhs.value,
-rhs.original_type);
+
+ /* bviyer: The line below is where the parser has the form:
+ * A = B
+ * So this is where we must modify the Array Notation arrays */
+
+ if (TREE_CODE (lhs.value) == ARRAY_NOTATION_REF
+ || TREE_CODE (rhs.value) == ARRAY_NOTATION_REF)
+ret.value = build_array_notation_expr (op_location, lhs.value,
+ lhs.original_type, code,
+ exp_location, rhs.value,
+ rhs.original_type);
+ else
+ret.value = build_modify_expr (op_location, lhs.value, lhs.original_type,
+ code, exp_location, rhs.value,
+ rhs.original_type);
if (code == NOP_EXPR)
ret.original_code = MODIFY_EXPR;
else
@@ -6941,10 +6953,44 @@ c_parser_postfix_expression_after_primary (c_parser
*parser,
case CPP_OPEN_SQUARE:
/* Array reference. */
c_parser_consume_token (parser);
- idx = c_parser_expression (parser).value;
- c_parser_skip_until_found (parser, CPP_CLOSE_SQUARE,
-"expected %<]%>");
- expr.value = build_array_ref (op_loc, expr.value, idx);
+ if (c_parser_peek_token (parser)->type == CPP_COLON)
+ {
+ /* If we reach here, th
[RFC, PATCH] ARM related deprecations
I think we've reached the point where the following target
configurations should be End-of-Life'd. As such, I'd like to mark them
as deprecated in gcc-4.7, prior to removal after the branch.
I'd also like to remove at that time support for some now obsolete
co-processor units, namely the FPA and Maverick.
For the time being I've kept the ecos-elf and the legacy RTEMS targets,
but I'm hereby putting them on notice as candidates for deprecation in
the next cycle. RTEMS how has an EABI conformant port, and ecos-elf
really should be moved in that direction too, if it is not to end up
dead very quickly.
* config.gcc (arm*-*-elf, arm*-*-linux-gnu): Deprecate.
(--with-fpu={fpa,fpe*,maverick}): Likewise.
R.--- config.gcc (revision 182097)
+++ config.gcc (local)
@@ -242,7 +242,14 @@ md_file=
# Obsolete configurations.
case ${target} in
+ # Avoid special cases that are not obsolete
+ arm*-*-linux-gnueabi* \
+ | arm*-*-ecos-elf \
+ )
+ ;;
alpha*-dec-osf5.1* \
+ | arm*-*-elf \
+ | arm*-*-linux* \
| i[34567]86-*-interix3* \
| mips-sgi-irix6.5\
| mips*-*-openbsd*\
@@ -3021,12 +3028,20 @@ case "${target}" in
case "$with_fpu" in
"" \
- | fpa | fpe2 | fpe3 | maverick | vfp | vfp3 | vfpv3 \
+ | vfp | vfp3 | vfpv3 \
| vfpv3-fp16 | vfpv3-d16 | vfpv3-d16-fp16 | vfpv3xd \
| vfpv3xd-fp16 | neon | neon-fp16 | vfpv4 | vfpv4-d16 \
| fpv4-sp-d16 | neon-vfpv4)
# OK
;;
+ fpa | fpe2 | fpe3 | maverick)
+ if test "x$enable_obsolete" != xyes; then
+ echo "*** Configuration option
--with-fpu=${with_fpu} is obsolete." >&2
+ echo "*** Specify --enable-obsolete to build it
anyway." >&2
+ echo "*** Support will be REMOVED in the next major
release of GCC." >&2
+ exit 1
+ fi
+ ;;
*)
echo "Unknown fpu used in --with-fpu=$with_fpu" 2>&1
exit 1
Re: [PING][PR testsuite/47013] Fix SMS testsuite faliures
These fixes to individual sms testcases are OK. Thanks, Ayal. On Mon, Dec 5, 2011 at 3:07 PM, Revital Eres wrote: > Hello, > > Ping: http://gcc.gnu.org/ml/gcc-patches/2011-11/msg02444.html > > Thanks, > Revital
Re: [RFC, PATCH] ARM related deprecations
Richard Earnshaw writes:
> --- config.gcc(revision 182097)
> +++ config.gcc(local)
> @@ -242,7 +242,14 @@ md_file=
>
> # Obsolete configurations.
> case ${target} in
> + # Avoid special cases that are not obsolete
> + arm*-*-linux-gnueabi* \
> + | arm*-*-ecos-elf \
> + )
> + ;;
Please keep the cases sorted alphabetically.
Thanks.
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
Re: libgo patch committed: Update to weekly.2011-11-09
Ian Lance Taylor writes:
> Rémy Oudompheng contributed a patch to upgrade the gccgo version of Go
> library to the weekly.2011-11-09 release. This patch commits the change
> to mainline. As usual with Go library updates, the patch is too large
> to include here, and simply repeats changes made to the master library
> in any case. I have as usual included the changes to files outside of
> libgo/go. Bootstrapped and ran Go testsuite on
> x86_64-unknown-linux-gnu. Committed to mainline.
This patch led to many (all?) execution tests to fail on Solaris:
Undefined first referenced
symbol in file
libgo_log.syslog.syslog_c
/var/gcc/regression/trunk/11-gcc-gas/build/i386-pc-solaris2.11/./libgo/.libs/libgo.so
ld: fatal: symbol referencing errors. No output written to
/var/gcc/regression/trunk/11-gcc-gas/build/gcc/testsuite/go/array-1.x
collect2: error: ld returned 1 exit status
Fixed by the following patch. I've rebuilt libgo.so in mid-test and all
subsequent tests are now passing.
Rainer
diff --git a/libgo/go/log/syslog/syslog_c.c b/libgo/go/log/syslog/syslog_c.c
--- a/libgo/go/log/syslog/syslog_c.c
+++ b/libgo/go/log/syslog/syslog_c.c
@@ -10,7 +10,7 @@
can't represent a C varargs function in Go. */
void syslog_c(int, const char*)
- asm ("libgo_syslog.syslog.syslog_c");
+ asm ("libgo_log.syslog.syslog_c");
void
syslog_c (int priority, const char *msg)
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH] use -fno-pie on darwin in boehm-gc.exp
Hi Jack, > The same argument could be made for PIC itself regarding the testsuite. > Aren't we still the only target that defaults to PIC objects? I would think > that certainly not: e.g. both Tru64 UNIX and IRIX are PIC by default. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH 5/6] mips: Implement vec_perm_const.
On 12/08/2011 10:08 PM, Hans-Peter Nilsson wrote:
> On Thu, 8 Dec 2011, Richard Henderson wrote:
>> diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
>> index d3fd709..f1c3665 100644
>> --- a/gcc/config/mips/mips.c
>> +++ b/gcc/config/mips/mips.c
>
>> @@ -13021,8 +13015,8 @@ static const struct mips_builtin_description
>> mips_builtins[] = {
>>LOONGSON_BUILTIN (pasubub, MIPS_UV8QI_FTYPE_UV8QI_UV8QI),
>>LOONGSON_BUILTIN (biadd, MIPS_UV4HI_FTYPE_UV8QI),
>>LOONGSON_BUILTIN (psadbh, MIPS_UV4HI_FTYPE_UV8QI_UV8QI),
>> - LOONGSON_BUILTIN_SUFFIX (pshufh, u, MIPS_UV4HI_FTYPE_UV4HI_UV4HI_UQI),
>> - LOONGSON_BUILTIN_SUFFIX (pshufh, s, MIPS_V4HI_FTYPE_V4HI_V4HI_UQI),
>> + LOONGSON_BUILTIN_SUFFIX (pshufh, u, MIPS_UV4HI_FTYPE_UV4HI_UQI),
>> + LOONGSON_BUILTIN_SUFFIX (pshufh, s, MIPS_V4HI_FTYPE_V4HI_UQI),
>>LOONGSON_BUILTIN_SUFFIX (psllh, u, MIPS_UV4HI_FTYPE_UV4HI_UQI),
>
> Looks like a brute-force (ignoring backward compatibility) fix
> for PR48068 item 2. If going that route, I'd suggest at least
> increment the __mips_loongson_vector_rev. Also, loongson.h
> needs the corresponding adjustment.
Thanks for the pointer. I'll clean this up along the increment
revision line, unless Richard S has another suggestion.
r~
Re: Fix ThreadSanitizer pass required properties (issue5477053)
On 11-12-09 09:36 , Dmitriy Vyukov wrote: This is for google-main branch. Fix ThreadSanitizer pass required properties. Turned out that PROP_gimple_lomp is not always present. Index: gcc/tree-tsan.c === --- gcc/tree-tsan.c (revision 182099) +++ gcc/tree-tsan.c (working copy) @@ -,7 +,7 @@ NULL, /* next */ 0,/* static_pass_number */ TV_NONE, /* tv_id */ - PROP_trees | PROP_cfg,/* properties_required */ + PROP_ssa | PROP_cfg, /* properties_required */ 0,/* properties_provided */ 0,/* properties_destroyed */ 0,/* todo_flags_start */ Index: gcc/ChangeLog.google-main === --- gcc/ChangeLog.google-main (revision 182099) +++ gcc/ChangeLog.google-main (working copy) @@ -1,3 +1,8 @@ +2011-12-09 Dmitriy Vyukov + + Fix ThreadSanitizer pass required properties. +* gcc/tree-tsan.c (pass_tsan): Replace PROP_trees with PROP_ssa. No need to mention what you are fixing in a ChangeLog entry. These entries are merely describing what changed, with no other content (yes, they are pretty useless nowadays). Also, the filename must be relative to the directory where the ChangeLog file lives. So, you don't need 'gcc/' in this case. OK with that change. Diego.
[ARM] PR 48941: poor code generated for vzip*() and vunzp*()
The buit-in functions that underlie ARM's vzip*() and vunzp*() functions pass the result by reference rather than value. This leads to very poor output, as demonstrated in PR 48941. This patch makes them return the vectors by value instead, using the structure modes TImode and OImode. Tested on arm-linux-gnueabi. OK to install? Richard gcc/ PR target/48941 * config/arm/arm.c (arm_init_neon_builtins): Make RESULTPAIR intrinsics return by value rather than reference. (arm_expand_neon_builtin): Update accordingly. (neon_emit_pair_result_insn): Likewise. * config/arm/neon.md (neon_vtrn): Split into double and quad patterns. Make the former return TImode and the latter OImode. (neon_vzip, neon_vuzp): Likewise. * config/arm/neon.ml (features): Remove ReturnPtr. (ops): Remove ReturnPtr from Vtrn, Vzip and Vuzp feature lists. * config/arm/neon-gen.ml (return_by_ptr): Delete. (return, params, print_variant): Remove return-by-pointer handling. * config/arm/arm_neon.h: Regenerate. Index: gcc/config/arm/arm.c === --- gcc/config/arm/arm.c2011-12-07 11:43:27.359242997 + +++ gcc/config/arm/arm.c2011-12-08 10:18:02.636136134 + @@ -19386,26 +19386,16 @@ arm_init_neon_builtins (void) tree intCI_type_node; tree intXI_type_node; - tree V8QI_pointer_node; - tree V4HI_pointer_node; - tree V2SI_pointer_node; - tree V2SF_pointer_node; - tree V16QI_pointer_node; - tree V8HI_pointer_node; - tree V4SI_pointer_node; - tree V4SF_pointer_node; - tree V2DI_pointer_node; - - tree void_ftype_pv8qi_v8qi_v8qi; - tree void_ftype_pv4hi_v4hi_v4hi; - tree void_ftype_pv2si_v2si_v2si; - tree void_ftype_pv2sf_v2sf_v2sf; - tree void_ftype_pdi_di_di; - tree void_ftype_pv16qi_v16qi_v16qi; - tree void_ftype_pv8hi_v8hi_v8hi; - tree void_ftype_pv4si_v4si_v4si; - tree void_ftype_pv4sf_v4sf_v4sf; - tree void_ftype_pv2di_v2di_v2di; + tree ti_ftype_v8qi_v8qi; + tree ti_ftype_v4hi_v4hi; + tree ti_ftype_v2si_v2si; + tree ti_ftype_v2sf_v2sf; + tree ti_ftype_di_di; + tree oi_ftype_v16qi_v16qi; + tree oi_ftype_v8hi_v8hi; + tree oi_ftype_v4si_v4si; + tree oi_ftype_v4sf_v4sf; + tree oi_ftype_v2di_v2di; tree reinterp_ftype_dreg[5][5]; tree reinterp_ftype_qreg[5][5]; @@ -19519,47 +19509,36 @@ arm_init_neon_builtins (void) (*lang_hooks.types.register_builtin_type) (intXI_type_node, "__builtin_neon_xi"); - /* Pointers to vector types. */ - V8QI_pointer_node = build_pointer_type (V8QI_type_node); - V4HI_pointer_node = build_pointer_type (V4HI_type_node); - V2SI_pointer_node = build_pointer_type (V2SI_type_node); - V2SF_pointer_node = build_pointer_type (V2SF_type_node); - V16QI_pointer_node = build_pointer_type (V16QI_type_node); - V8HI_pointer_node = build_pointer_type (V8HI_type_node); - V4SI_pointer_node = build_pointer_type (V4SI_type_node); - V4SF_pointer_node = build_pointer_type (V4SF_type_node); - V2DI_pointer_node = build_pointer_type (V2DI_type_node); - /* Operations which return results as pairs. */ - void_ftype_pv8qi_v8qi_v8qi = -build_function_type_list (void_type_node, V8QI_pointer_node, V8QI_type_node, + ti_ftype_v8qi_v8qi = +build_function_type_list (intTI_type_node, V8QI_type_node, V8QI_type_node, NULL); - void_ftype_pv4hi_v4hi_v4hi = -build_function_type_list (void_type_node, V4HI_pointer_node, V4HI_type_node, + ti_ftype_v4hi_v4hi = +build_function_type_list (intTI_type_node, V4HI_type_node, V4HI_type_node, NULL); - void_ftype_pv2si_v2si_v2si = -build_function_type_list (void_type_node, V2SI_pointer_node, V2SI_type_node, + ti_ftype_v2si_v2si = +build_function_type_list (intTI_type_node, V2SI_type_node, V2SI_type_node, NULL); - void_ftype_pv2sf_v2sf_v2sf = -build_function_type_list (void_type_node, V2SF_pointer_node, V2SF_type_node, + ti_ftype_v2sf_v2sf = +build_function_type_list (intTI_type_node, V2SF_type_node, V2SF_type_node, NULL); - void_ftype_pdi_di_di = -build_function_type_list (void_type_node, intDI_pointer_node, - neon_intDI_type_node, neon_intDI_type_node, NULL); - void_ftype_pv16qi_v16qi_v16qi = -build_function_type_list (void_type_node, V16QI_pointer_node, - V16QI_type_node, V16QI_type_node, NULL); - void_ftype_pv8hi_v8hi_v8hi = -build_function_type_list (void_type_node, V8HI_pointer_node, V8HI_type_node, + ti_ftype_di_di = +build_function_type_list (intTI_type_node, neon_intDI_type_node, + neon_intDI_type_node, NULL); + oi_ftype_v16qi_v16qi = +build_function_type_list (intOI_type_node, V16QI_type_node, + V16QI_type_node, NULL); + oi_fty
libgo patch committed: Print to stderr
The predeclared print function in Go should print to stderr, not
stdout. This patch from Rémy Oudompheng fixes libgo to do that.
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline.
Ian
diff -r e73cfc80d5d7 libgo/runtime/go-print.c
--- a/libgo/runtime/go-print.c Thu Dec 08 21:02:49 2011 -0800
+++ b/libgo/runtime/go-print.c Fri Dec 09 08:40:35 2011 -0800
@@ -18,43 +18,43 @@
void
__go_print_space ()
{
- putchar (' ');
+ putc (' ', stderr);
}
void
__go_print_nl ()
{
- putchar ('\n');
+ putc ('\n', stderr);
}
void
__go_print_string (struct __go_string val)
{
- printf ("%.*s", (int) val.__length, (const char *) val.__data);
+ fprintf (stderr, "%.*s", (int) val.__length, (const char *) val.__data);
}
void
__go_print_uint64 (uint64_t val)
{
- printf ("%llu", (unsigned long long) val);
+ fprintf (stderr, "%llu", (unsigned long long) val);
}
void
__go_print_int64 (int64_t val)
{
- printf ("%lld", (long long) val);
+ fprintf (stderr, "%lld", (long long) val);
}
void
__go_print_double (double val)
{
- printf ("%.24g", val);
+ fprintf (stderr, "%.24g", val);
}
void
__go_print_complex (__complex double val)
{
- printf ("(%.24g%s%.24gi)",
+ fprintf (stderr, "(%.24g%s%.24gi)",
__builtin_creal (val),
(__builtin_cimag (val) >= 0 || __builtin_isnan (__builtin_cimag(val))
? "+"
@@ -65,29 +65,29 @@
void
__go_print_bool (_Bool val)
{
- fputs (val ? "true" : "false", stdout);
+ fputs (val ? "true" : "false", stderr);
}
void
__go_print_pointer (void *val)
{
- printf ("%p", val);
+ fprintf (stderr, "%p", val);
}
void
__go_print_empty_interface (struct __go_empty_interface e)
{
- printf ("(%p,%p)", e.__type_descriptor, e.__object);
+ fprintf (stderr, "(%p,%p)", e.__type_descriptor, e.__object);
}
void
__go_print_interface (struct __go_interface i)
{
- printf ("(%p,%p)", i.__methods, i.__object);
+ fprintf (stderr, "(%p,%p)", i.__methods, i.__object);
}
void
__go_print_slice (struct __go_open_array val)
{
- printf ("[%d/%d]%p", val.__count, val.__capacity, val.__values);
+ fprintf (stderr, "[%d/%d]%p", val.__count, val.__capacity, val.__values);
}
PR 50873: create_fixed_operand and virtual regs
ARM's neon_vector_mem_operand does not allow eliminable or virtual registers
to be used as addresses. create_*_operand was supposed to cope with that by
replacing the address with a (non-virtual) pseudo register. The problem is
that I used the wrong function: force_reg rather than copy_to_mode_reg.
I see I also rather lazily used Pmode instead of addr_space.address_mode.
This patch fixes both problems.
Tested on arm-linux-gnueabi, where it prevents an ICE in dilayout.c.
OK to install?
Richard
gcc/
PR middle-end/50873
* optabs.c (maybe_legitimize_operand_same_code): Use copy_to_mode_reg
instead of force_reg. Do nothing if the address is already a
non-virtual pseudo register.
Index: gcc/optabs.c
===
*** gcc/optabs.c2011-12-08 11:17:35.319229272 +
--- gcc/optabs.c2011-12-09 16:32:01.781886061 +
*** maybe_legitimize_operand_same_code (enum
*** 8241,8264
return true;
/* If the operand is a memory whose address has no side effects,
! try forcing the address into a register. The check for side
! effects is important because force_reg cannot handle things
! like auto-modified addresses. */
! if (insn_data[(int) icode].operand[opno].allows_mem
! && MEM_P (op->value)
! && !side_effects_p (XEXP (op->value, 0)))
{
! rtx addr, mem, last;
! last = get_last_insn ();
! addr = force_reg (Pmode, XEXP (op->value, 0));
! mem = replace_equiv_address (op->value, addr);
! if (insn_operand_matches (icode, opno, mem))
{
! op->value = mem;
! return true;
}
- delete_insns_since (last);
}
return false;
--- 8241,8271
return true;
/* If the operand is a memory whose address has no side effects,
! try forcing the address into a non-virtual pseudo register.
! The check for side effects is important because copy_to_mode_reg
! cannot handle things like auto-modified addresses. */
! if (insn_data[(int) icode].operand[opno].allows_mem && MEM_P (op->value))
{
! rtx addr, mem;
! mem = op->value;
! addr = XEXP (mem, 0);
! if (!(REG_P (addr) && REGNO (addr) > LAST_VIRTUAL_REGISTER)
! && !side_effects_p (addr))
{
! rtx last;
! enum machine_mode mode;
!
! last = get_last_insn ();
! mode = targetm.addr_space.address_mode (MEM_ADDR_SPACE (mem));
! mem = replace_equiv_address (mem, copy_to_mode_reg (mode, addr));
! if (insn_operand_matches (icode, opno, mem))
! {
! op->value = mem;
! return true;
! }
! delete_insns_since (last);
}
}
return false;
Re: libgo patch committed: Update to weekly.2011-11-09
Rainer Orth writes: > This patch led to many (all?) execution tests to fail on Solaris: > > Undefined first referenced > symbol in file > libgo_log.syslog.syslog_c > /var/gcc/regression/trunk/11-gcc-gas/build/i386-pc-solaris2.11/./libgo/.libs/libgo.so > ld: fatal: symbol referencing errors. No output written to > /var/gcc/regression/trunk/11-gcc-gas/build/gcc/testsuite/go/array-1.x > collect2: error: ld returned 1 exit status > > Fixed by the following patch. I've rebuilt libgo.so in mid-test and all > subsequent tests are now passing. Thanks for sorting this out. Committed to mainline. Ian
Re: [PATCH] use -fno-pie on darwin in boehm-gc.exp
On Fri, Dec 09, 2011 at 05:26:47PM +0100, Rainer Orth wrote: > Hi Jack, > > > The same argument could be made for PIC itself regarding the testsuite. > > Aren't we still the only target that defaults to PIC objects? I would think > > that > > certainly not: e.g. both Tru64 UNIX and IRIX are PIC by default. > > Rainer Rainer, So that is to say that there is no expectation for linux to eventually adopt a hardened form as the default (ie PIE)? Jack > > -- > - > Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH] use -fno-pie on darwin in boehm-gc.exp
On Fri, Dec 09, 2011 at 10:03:47AM -0500, Jack Howarth wrote: > On Fri, Dec 09, 2011 at 02:09:54PM +, Iain Sandoe wrote: > > > > On 8 Dec 2011, at 20:55, Iain Sandoe wrote: > >> ... but, I'll bow out at this juncture - > > > > OK, I lied :-) > > > > The boehm-gc tests pass for m32 and m64 with "-fpie/-fPIE" on both x86 > > Darwin9 (XC3.1.4) and x86_64 Darwin10 (XC3.2.5); > > I'm building with XC3.2.6 to check that too. > > > > So I think you need to debug what is actually failing on Darwin11. > > > > Iain > > Iain, >I did a bit of experimentation with Xcode 4.2 on 10.6.8 and 10.7.2 with the > failing gctest test case. > > 1) On 10.6.8 using Xcode 4.2 and a previous gcc trunk build, if I do a 'make > clean' > in > /sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/x86_64-apple-darwin10.8.0/boehm-gc > after editing the Makefile there to have... > > CFLAGS = -g -O2 -Wl,-pie > > and then manually rebuild the gctest case with the same flags, it runs fine > on darwin10 > but segfaults on darwin11. Interestingly, I can get it to run without > crashing on darwin11 > if I run it within gdb. > > 2) On 10.7.2 using Xcode 4.2 and a previous gcc trunk build, if I do a 'make > clean' in > /sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/x86_64-apple-darwin11.2.0/boehm-gc > after editing the Makefile there to have... > > CFLAGS = -g -O2 -mmacosx-version-min=10.6 -Wl,-pie > > and then manually rebuild the gctest case with the same flags, the resulting > binary still crashes > on darwin11 but runs fine on darwin10. FYI, I also copied libgcjgc.1.dylib > from the appropriate > build and set DYLD_LIBRARY_PATH as required in each case. > I am assuming these observations suggest that we are seeing a new bug in > the darwin11 unwinder. > I'll open a radar for this tonight with a standalone test case based on > gctest that the darwin > linker developer can walk through the darwin11 unwinder. > Jack Iain, FYI, I checked my radar reports and I had already opened Problem ID: 9603795, "Lion linker breaks boehm-gc", in July. The original report only compared the stock linkages on darwin10 and darwin11. I've updated the report with a stand-alone test case built using Xcode 4.2 under darwin11 with -mmacosx-version-min=10.6 -Wl,-pie that crashes on darwin11 but not darwin10. This with with the observation that -mmacosx-version-min=10.6 -Wl,-pie builds a copy under Xcode 4.2 on darwin10 that likewise fails on darwin11 but not darwin10 eliminates the linker as the cause of the issue. Jack
Re: [patch] Fix cygwin ada install [was Re: Yet another issue with gcc current trunk with ada on cygwin]
> Windows doesn't have any concept of an rpath in executables, nor of > LD_LIBRARY_PATH; all required DLLs must be found on the PATH when an exe is > invoked. The Ada shared libraries are currently installed into adaobj/ in > the gcc private dir, which is not (and should not be) on users' PATHs, so > the result is that executables compiled with the -shared binder option > don't work. You're right. > The attached patch fixes Windows DLLs to be installed into $bindir, and > while it does that it also generates import libraries, which live in the > private adaobj/ directory and serve for linking executables to the DLLs > (it's actually preferred to link against an import library than directly > against the DLL itself). Finally it adjusts the name of the DLLs on Cygwin > to match the cyg*.dll naming scheme used there to avoid clashes with MinGW > DLLs. Could you elaborate on why linking against an import library is preferred over liking against the DLL directly? -- Eric Botcazou
[PATCH] Fix vectorizer ICEs with calls with MEM_REF arguments (PR tree-optimization/51485)
Hi!
As mentioned in the PR, we ICE on the following testcase, because
there are DRs in a GIMPLE_CALL stmt and when there is just one, we
compute vectype for the call as if it were a load or store, but during
computation of vectorization factor we only consider the return value
of the call. As such calls are not vectorizable anyway, the following
patch just gives up on them.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk
(and with the if (bb_vinfo)/if (gather) parts removed for 4.6 too)?
2011-12-09 Jakub Jelinek
PR tree-optimization/51485
* tree-vect-data-refs.c (vect_analyze_data_refs): Give up on
DRs in call stmts.
* g++.dg/vect/pr51485.cc: New test.
--- gcc/tree-vect-data-refs.c.jj2011-12-02 01:52:26.325893329 +0100
+++ gcc/tree-vect-data-refs.c 2011-12-09 13:27:29.726668859 +0100
@@ -2896,6 +2896,26 @@ vect_analyze_data_refs (loop_vec_info lo
return false;
}
+ if (is_gimple_call (stmt))
+ {
+ if (vect_print_dump_info (REPORT_UNVECTORIZED_LOCATIONS))
+ {
+ fprintf (vect_dump, "not vectorized: dr in a call ");
+ print_gimple_stmt (vect_dump, stmt, 0, TDF_SLIM);
+ }
+
+ if (bb_vinfo)
+ {
+ STMT_VINFO_VECTORIZABLE (stmt_info) = false;
+ stop_bb_analysis = true;
+ continue;
+ }
+
+ if (gather)
+ free_data_ref (dr);
+ return false;
+ }
+
/* Update DR field in stmt_vec_info struct. */
/* If the dataref is in an inner-loop of the loop that is considered for
--- gcc/testsuite/g++.dg/vect/pr51485.cc.jj 2011-12-09 13:28:45.155281405
+0100
+++ gcc/testsuite/g++.dg/vect/pr51485.cc2011-12-09 13:28:57.692205773
+0100
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+
+struct A { A (); unsigned int a; };
+double bar (A a) throw () __attribute__((pure));
+
+void
+foo (unsigned int x, double *y, A *z)
+{
+ unsigned int i;
+ for (i = 0; i < x; i++)
+y[i] = bar (z[i]);
+}
+
+/* { dg-final { cleanup-tree-dump "vect" } } */
Jakub
[PATCH] Fix up optimize_clobbers (PR tree-optimization/51117)
Hi!
When working on clobber sinking, I've noticed that
optimize_clobbers would mistakenly remove just one clobber
instead of all consecutive ones, because gsi_remove moves
the iterator to the next rather than previous stmt (i.e.
GIMPLE_RESX if no debug stmts) and we return in the next iteration.
Fixed thusly, and with a small cleanup to use gimple_clobber_p
predicate too. Bootstrapped/regtested on x86_64-linux and i686-linux,
ok for trunk?
2011-12-09 Jakub Jelinek
PR tree-optimization/51117
* tree-eh.c (optimize_clobbers): Don't remove just one
clobber, but all consecutive clobbers before RESX.
Use gimple_clobber_p predicate.
--- gcc/tree-eh.c.jj2011-12-09 13:08:11.0 +0100
+++ gcc/tree-eh.c 2011-12-09 15:13:51.849968215 +0100
@@ -3180,17 +3180,13 @@ static void
optimize_clobbers (basic_block bb)
{
gimple_stmt_iterator gsi = gsi_last_bb (bb);
- for (gsi_prev (&gsi); !gsi_end_p (gsi);)
+ for (gsi_prev (&gsi); !gsi_end_p (gsi); gsi_prev (&gsi))
{
gimple stmt = gsi_stmt (gsi);
if (is_gimple_debug (stmt))
- {
- gsi_prev (&gsi);
- continue;
- }
- if (!gimple_assign_single_p (stmt)
- || TREE_CODE (gimple_assign_lhs (stmt)) == SSA_NAME
- || !TREE_CLOBBER_P (gimple_assign_rhs1 (stmt)))
+ continue;
+ if (!gimple_clobber_p (stmt)
+ || TREE_CODE (gimple_assign_lhs (stmt)) == SSA_NAME)
return;
unlink_stmt_vdef (stmt);
gsi_remove (&gsi, true);
Jakub
PR/50076 make c-c++-common/cxxbitfields-3.c work in Darwin
This test is somewhat problematic in that it's entirely dependent on the
assembler output. It's not reproducible on non-x86, so I couldn't make
it part of the simulate-thread framework.
What we're really testing is that the last move into "var" happens as a
32/64 bit quantity:
movlvar(%rip), %eax
andb$15, %al
orl $80, %eax
movl%eax, var(%rip) <-- good
Currently the regexp is testing a movl into "var", however on Darwin
there is an extra level of indirection through GOTPCREL, so we don't
explicitly store into "var". The result is correct, but doesn't match
the regexp:
movq_var@GOTPCREL(%rip), %rdx
movl(%rdx), %eax
andb$15, %al
orl$80, %eax
movl%eax, (%rdx)<-- bad, no "var"
The two simple solutions I can think of are (a) modifying the regexp as
below (b) XFAILing on Darwin. I would prefer (a), but I want to make
sure I'm not overlooking something.
Does this seem reasonable or is another approach preferable?
testsuite/
* c-c++-common/cxxbitfields-3.c: Adjust regexp.
Index: testsuite/c-c++-common/cxxbitfields-3.c
===
--- testsuite/c-c++-common/cxxbitfields-3.c (revision 182028)
+++ testsuite/c-c++-common/cxxbitfields-3.c (working copy)
@@ -18,4 +18,4 @@ void setit()
var.j = 5;
}
-/* { dg-final { scan-assembler "movl.*, var" } } */
+/* { dg-final { scan-assembler "movl.*, (var|\\(%)" } } */
Re: PR/50076 make c-c++-common/cxxbitfields-3.c work in Darwin
On 9 Dec 2011, at 17:35, Aldy Hernandez wrote:
This test is somewhat problematic in that it's entirely dependent on
the assembler output. It's not reproducible on non-x86, so I
couldn't make it part of the simulate-thread framework.
What we're really testing is that the last move into "var" happens
as a 32/64 bit quantity:
movlvar(%rip), %eax
andb$15, %al
orl $80, %eax
movl%eax, var(%rip) <-- good
Currently the regexp is testing a movl into "var", however on Darwin
there is an extra level of indirection through GOTPCREL, so we don't
explicitly store into "var". The result is correct, but doesn't
match the regexp:
movq_var@GOTPCREL(%rip), %rdx
movl(%rdx), %eax
andb$15, %al
orl$80, %eax
movl%eax, (%rdx) <-- bad, no "var"
The two simple solutions I can think of are (a) modifying the regexp
as below (b) XFAILing on Darwin. I would prefer (a), but I want to
make sure I'm not overlooking something.
Does this seem reasonable or is another approach preferable?
testsuite/
* c-c++-common/cxxbitfields-3.c: Adjust regexp.
Index: testsuite/c-c++-common/cxxbitfields-3.c
===
--- testsuite/c-c++-common/cxxbitfields-3.c (revision 182028)
+++ testsuite/c-c++-common/cxxbitfields-3.c (working copy)
@@ -18,4 +18,4 @@ void setit()
var.j = 5;
}
-/* { dg-final { scan-assembler "movl.*, var" } } */
+/* { dg-final { scan-assembler "movl.*, (var|\\(%)" } } */
scan-assembler can be target-dependent if that would (as I read the
above) help.
Iain
Re: -finstrument-functions leads to unsats to _mm instrinsic wrappers
Ping .. On Wed, Dec 7, 2011 at 4:01 PM, Xinliang David Li wrote: > Build the test case in the patch file with -finstrument-functions, the > link will fail with unsat. The problem is gcc instruments the > artificial wrappers that will won't be emitted. The patch fixes the > problem. Bootstrap and tested on x86-64/linux. > > Ok for mainline? > > thanks, > > David
Re: PR/50076 make c-c++-common/cxxbitfields-3.c work in Darwin
scan-assembler can be target-dependent if that would (as I read the
above) help.
Well, whadayaknow...
In that case we can have an x86 variant for Darwin, and one for
everything else x86.
OK?
testsuite/
* c-c++-common/cxxbitfields-3.c: Adjust regexp.
Index: testsuite/c-c++-common/cxxbitfields-3.c
===
--- testsuite/c-c++-common/cxxbitfields-3.c (revision 182028)
+++ testsuite/c-c++-common/cxxbitfields-3.c (working copy)
@@ -18,4 +18,5 @@ void setit()
var.j = 5;
}
-/* { dg-final { scan-assembler "movl.*, var" } } */
+/* { dg-final { scan-assembler "movl.*, \\(%" { target *-*-darwin } } } */
+/* { dg-final { scan-assembler "movl.*, var" { target { ! *-*-darwin } } } } */
Re: [PATCH 6/6] arm: Implement vec_perm and vec_perm_const for NEON.
On 8 December 2011 21:06, Richard Henderson wrote:
> ---
> gcc/config/arm/arm-protos.h | 3 +
> gcc/config/arm/arm.c | 527
> -
> gcc/config/arm/neon.md | 59
> gcc/config/arm/vec-common.md | 26 ++
> gcc/testsuite/lib/target-supports.exp | 9 +-
> 5 files changed, 620 insertions(+), 4 deletions(-)
I haven't been following the vector permute work in great detail and
I must say I haven't read this patch series in great detail yet.
For Neon a further optimization to consider might be to use the vext
instruction which could achieve permute masks that are monotonically
increasing constants ? While I expect the latency for a vext or vtbl
instruction to be about the same (your mileage might vary depending on
the core), using vext gives us the freedom of not needing a register
for the permute mask -
a = vec_shuffle (b, c, mask) where mask is { n + 7, n + 6, n + 5, n +
4, n + 3, n + 2, n + 1, n } could just be vext.8 A, B, C, #n
If the mask being provided is a reverse of the mask above, it's
probably not worth it.
Additionally , can we also detect rotate rights ? unless ofcourse
there's a different interface -
a = vec_shuffle (vec, {0, 7, 6, 5, 4, 3, 2, 1}) => vext.8 a, vec, vec, #1
Masks doing rotate lefts are probably not worth it in this
regards,
Ramana
>
> diff --git a/gcc/config/arm/arm-protos.h b/gcc/config/arm/arm-protos.h
> index 296550a..8c3e412 100644
> --- a/gcc/config/arm/arm-protos.h
> +++ b/gcc/config/arm/arm-protos.h
> @@ -244,4 +244,7 @@ extern const struct tune_params *current_tune;
> extern int vfp3_const_double_for_fract_bits (rtx);
> #endif /* RTX_CODE */
>
> +extern void arm_expand_vec_perm (rtx target, rtx op0, rtx op1, rtx sel);
> +extern bool arm_expand_vec_perm_const (rtx target, rtx op0, rtx op1, rtx
> sel);
> +
> #endif /* ! GCC_ARM_PROTOS_H */
> diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
> index 65b4e9d..0395a41 100644
> --- a/gcc/config/arm/arm.c
> +++ b/gcc/config/arm/arm.c
> @@ -267,6 +267,9 @@ static unsigned int arm_autovectorize_vector_sizes (void);
> static int arm_default_branch_cost (bool, bool);
> static int arm_cortex_a5_branch_cost (bool, bool);
>
> +static bool arm_vectorize_vec_perm_const_ok (enum machine_mode vmode,
> + const unsigned char *sel);
> +
>
> /* Table of machine attributes. */
> static const struct attribute_spec arm_attribute_table[] =
> @@ -604,6 +607,10 @@ static const struct attribute_spec arm_attribute_table[]
> =
> #define TARGET_PREFERRED_RENAME_CLASS \
> arm_preferred_rename_class
>
> +#undef TARGET_VECTORIZE_VEC_PERM_CONST_OK
> +#define TARGET_VECTORIZE_VEC_PERM_CONST_OK \
> + arm_vectorize_vec_perm_const_ok
> +
> struct gcc_target targetm = TARGET_INITIALIZER;
>
> /* Obstack for minipool constant handling. */
> @@ -25064,6 +25071,524 @@ vfp3_const_double_for_fract_bits (rtx operand)
> }
> return 0;
> }
> +
> +#define MAX_VECT_LEN 16
>
> -#include "gt-arm.h"
> +struct expand_vec_perm_d
> +{
> + rtx target, op0, op1;
> + unsigned char perm[MAX_VECT_LEN];
> + enum machine_mode vmode;
> + unsigned char nelt;
> + bool one_vector_p;
> + bool testing_p;
> +};
> +
> +/* Generate a variable permutation. */
> +
> +static void
> +arm_expand_vec_perm_1 (rtx target, rtx op0, rtx op1, rtx sel)
> +{
> + enum machine_mode vmode = GET_MODE (target);
> + bool one_vector_p = rtx_equal_p (op0, op1);
> +
> + gcc_checking_assert (vmode == V8QImode || vmode == V16QImode);
> + gcc_checking_assert (GET_MODE (op0) == vmode);
> + gcc_checking_assert (GET_MODE (op1) == vmode);
> + gcc_checking_assert (GET_MODE (sel) == vmode);
> + gcc_checking_assert (TARGET_NEON);
> +
> + if (one_vector_p)
> + {
> + if (vmode == V8QImode)
> + emit_insn (gen_neon_vtbl1v8qi (target, op0, sel));
> + else
> + emit_insn (gen_neon_vtbl1v16qi (target, op0, sel));
> + }
> + else
> + {
> + enum machine_mode mode1, mode2;
> + rtx pair, part;
> +
> + if (vmode == V8QImode)
> + mode1 = DImode, mode2 = TImode;
> + else
> + mode1 = TImode, mode2 = OImode;
> +
> + pair = gen_reg_rtx (mode2);
> + emit_insn (gen_rtx_CLOBBER (VOIDmode, pair));
> +
> + part = simplify_gen_subreg (mode1, pair, mode2,
> + subreg_lowpart_offset (mode1, mode2));
> + emit_move_insn (part, gen_lowpart (mode1, op0));
> +
> + part = simplify_gen_subreg (mode1, pair, mode2,
> + subreg_highpart_offset (mode1, mode2));
> + emit_move_insn (part, gen_lowpart (mode1, op1));
> +
> + if (vmode == V8QImode)
> + emit_insn (gen_neon_vtbl2v8qi (target, pair, sel));
> + else
> + emit_insn (gen_neon_vtbl2v16qi (target, pair, sel));
> + }
> +}
> +
> +void
> +arm_expand_vec_perm (rtx target, rtx op0, rtx op1, rtx sel)
> +{
> + enum machine_mode vmode
Re: [PATCH 6/6] arm: Implement vec_perm and vec_perm_const for NEON.
On Fri, Dec 09, 2011 at 06:02:21PM +, Ramana Radhakrishnan wrote:
> On 8 December 2011 21:06, Richard Henderson wrote:
> > ---
> > gcc/config/arm/arm-protos.h | 3 +
> > gcc/config/arm/arm.c | 527
> > -
> > gcc/config/arm/neon.md | 59
> > gcc/config/arm/vec-common.md | 26 ++
> > gcc/testsuite/lib/target-supports.exp | 9 +-
> > 5 files changed, 620 insertions(+), 4 deletions(-)
>
> I haven't been following the vector permute work in great detail and
> I must say I haven't read this patch series in great detail yet.
>
> For Neon a further optimization to consider might be to use the vext
> instruction which could achieve permute masks that are monotonically
> increasing constants ? While I expect the latency for a vext or vtbl
> instruction to be about the same (your mileage might vary depending on
> the core), using vext gives us the freedom of not needing a register
> for the permute mask -
>
> a = vec_shuffle (b, c, mask) where mask is { n + 7, n + 6, n + 5, n +
> 4, n + 3, n + 2, n + 1, n } could just be vext.8 A, B, C, #n
>
> If the mask being provided is a reverse of the mask above, it's
> probably not worth it.
>
>
> Additionally , can we also detect rotate rights ? unless ofcourse
> there's a different interface -
>
>a = vec_shuffle (vec, {0, 7, 6, 5, 4, 3, 2, 1}) => vext.8 a, vec, vec, #1
>
>
> Masks doing rotate lefts are probably not worth it in this
Richard and I were discussing this last night on IRC, and it is certainly
possible. Somebody would just have to write a predicate to recognize the
case. We do wonder how frequently it will occur, and whether people doing this
would just use the whole vector shift instead of shuffle.
--
Michael Meissner, IBM
5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA
meiss...@linux.vnet.ibm.com fax +1 (978) 399-6899
Re: PR/50076 make c-c++-common/cxxbitfields-3.c work in Darwin
On 9 Dec 2011, at 17:50, Aldy Hernandez wrote:
scan-assembler can be target-dependent if that would (as I read the
above) help.
Well, whadayaknow...
In that case we can have an x86 variant for Darwin, and one for
everything else x86.
in principle, it should be OK ... with *-*-darwin*
the problem is that c and c++ are generating different code sequences.
c does this (m64):
movq_var@GOTPCREL(%rip), %rdx
movl(%rdx), %eax
andb$15, %al
orl$80, %eax
movl%eax, (%rdx)
c++ does this (m64):
__Z5setitv:
LFB0:
movl_var(%rip), %eax
andb$15, %al
orl $80, %eax
movl%eax, _var(%rip)
ret
so .. m64 c++ is the same as 'other' cases (less the
__USER_LABEL_PREFIX__)
there are 4 cases: {c,c++} {m32,m64} with 4 different asm outputs
if that is a 'reasonable' situation - then might need to include ilp64/
ip32 in the target spec ...
otherwise - if it indicates a bug - then .. we need to deal with that.
Iain
Re: PR/50076 make c-c++-common/cxxbitfields-3.c work in Darwin
there are 4 cases: {c,c++} {m32,m64} with 4 different asm outputs
if that is a 'reasonable' situation - then might need to include
ilp64/ip32 in the target spec ...
Both the 32 and 64 bit versions of the Darwin output are correct, so
perhaps something like I had originally proposed, but taking into
account the __USER_LABEL_PREFIX__:
-/* { dg-final { scan-assembler "movl.*, var" } } */
+/* { dg-final { scan-assembler "movl.*, (_?var|\\(%)" } } */
Re: PR/50076 make c-c++-common/cxxbitfields-3.c work in Darwin
On 9 Dec 2011, at 18:52, Aldy Hernandez wrote:
there are 4 cases: {c,c++} {m32,m64} with 4 different asm outputs
if that is a 'reasonable' situation - then might need to include
ilp64/ip32 in the target spec ...
Both the 32 and 64 bit versions of the Darwin output are correct, so
perhaps something like I had originally proposed, but taking into
account the __USER_LABEL_PREFIX__:
-/* { dg-final { scan-assembler "movl.*, var" } } */
+/* { dg-final { scan-assembler "movl.*, (_?var|\\(%)" } } */
works for me .. but I can't approve it :-).
Iain
Re: PR/50076 make c-c++-common/cxxbitfields-3.c work in Darwin
> +/* { dg-final { scan-assembler "movl.*, (_?var|\\(%)" } } */
It works for me too.
Thanks,
Dominique
[pph] Tolerate missing and invalid PPH files (issue5475055)
We currently emit hard errors when a PPH image is missing or invalid.
This is not ideal, because in these cases, what the compiler could do
is to simply use the original text header file. After all, they are
interchangeable.
Additionally, this helps the current implementation into finding other
bugs, if a header failed to pre-parse, it can block many other
headers from pre-parsing.
I have created two warning flags: -Winvalid-pph and -Wmissing-pph.
This way, an implementation can choose to build with these warnings
and -Werror to stop the build, if needed.
Tested on x86_64. Committed to branch.
Diego.
c-family/ChangeLog.pph
* c.opt (Winvalid-pph, Wmissing-pph): New flags.
cp/ChangeLog.pph
* pph-core.c (pph_is_valid_here): Call warning_at instead of
error_at.
(pph_include_handler): If pph_read_file returns NULL, emit
warning and proceed with textual header parsing.
* pph-in.c (pph_read_file): Do not call fatal_error if
FILENAME is not found.
diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index e390479..c0095fc 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -448,6 +448,11 @@ Winvalid-pch
C ObjC C++ ObjC++ Warning
Warn about PCH files that are found but not used
+Winvalid-pph
+C++ Warning
+Warn about PPH files that are found but cannot used
+
+
Wjump-misses-init
C ObjC Var(warn_jump_misses_init) Init(-1) Warning
Warn when a jump misses a variable initialization
@@ -492,6 +497,10 @@ Wmissing-prototypes
C ObjC Var(warn_missing_prototypes) Warning
Warn about global functions without prototypes
+Wmissing-pph
+C++ Warning
+Warn about missing PPH files
+
Wmultichar
C ObjC C++ ObjC++ Warning
Warn about use of multi-character character constants
diff --git a/gcc/cp/pph-core.c b/gcc/cp/pph-core.c
index 76765d9..33ed64b 100644
--- a/gcc/cp/pph-core.c
+++ b/gcc/cp/pph-core.c
@@ -586,7 +586,8 @@ pph_is_valid_here (const char *name, location_t loc)
the original text file. */
if (scope_chain->x_brace_nesting > 0)
{
- error_at (loc, "PPH file %s not included at global scope", name);
+ warning_at (loc, OPT_Winvalid_pph,
+ "PPH file %s not included at global scope", name);
return false;
}
@@ -626,22 +627,22 @@ pph_include_handler (cpp_reader *reader,
&& pph_is_valid_here (name, loc)
&& !cpp_included_before (reader, name, input_location))
{
- pph_stream *include;
-
- /* Hack. We do this to mimic what the non-pph compiler does in
- _cpp_stack_include as our goal is to have identical line_tables. */
- line_table->highest_location--;
-
- include = pph_read_file (pph_file);
-
- /* If we are generating a new PPH image, add the stream we just
-read to the list of includes. This way, the parser will be
-able to resolve references to symbols in INCLUDE and its
-children. */
- if (pph_writer_enabled_p ())
- pph_writer_add_include (include);
-
- read_text_file_p = false;
+ pph_stream *include = pph_read_file (pph_file);
+ if (include)
+ {
+ /* If we are generating a new PPH image, add the stream we
+just read to the list of includes. This way, the parser
+will be able to resolve references to symbols in INCLUDE
+and its children. */
+ if (pph_writer_enabled_p ())
+ pph_writer_add_include (include);
+
+ read_text_file_p = false;
+ }
+ else
+ warning_at (input_location, OPT_Wmissing_pph,
+ "cannot open PPH file %s for reading: %m\n"
+ "using original header %s", pph_file, name);
}
return read_text_file_p;
diff --git a/gcc/cp/pph-in.c b/gcc/cp/pph-in.c
index 323516d..780d208 100644
--- a/gcc/cp/pph-in.c
+++ b/gcc/cp/pph-in.c
@@ -2900,10 +2900,15 @@ pph_stream *
pph_read_file (const char *filename)
{
pph_stream *stream = pph_stream_open (filename, "rb");
- if (stream == NULL)
-fatal_error ("cannot open PPH file %s for reading: %m", filename);
+ if (stream)
+{
+ /* FIXME pph. We do this to mimic what the non-pph compiler
+does in _cpp_stack_include as our goal is to have identical
+line_tables. */
+ line_table->highest_location--;
- pph_read_file_1 (stream);
+ pph_read_file_1 (stream);
+}
return stream;
}
--
This patch is available for review at http://codereview.appspot.com/5475055
Re: PR/50076 make c-c++-common/cxxbitfields-3.c work in Darwin
On Fri, Dec 09, 2011 at 08:17:04PM +0100, Dominique Dhumieres wrote:
> > +/* { dg-final { scan-assembler "movl.*, (_?var|\\(%)" } } */
>
> It works for me too.
Except that when matching just , (% it doesn't test almost anything.
IMNSHO you should instead just test it { target !fpic } or similar.
The _? in there is useful though.
Jakub
[pph] Fix test failure in my last patch (issue5476051)
Bah, I ran make check in a different build directory. This fixes the
two failures I introduced with my warning patch.
Now tested on the proper build dir.
Diego.
cp/ChangeLog.pph
* pph-core.c (pph_include_handler): Use LOC instead of
INPUT_LOCATION.
testsuite/ChangeLog.pph
* g++.dg/pph/d1symnotinc.cc: Expect warning.
* g++.dg/pph/y8inc-nmspc.cc: Likewise.
diff --git a/gcc/cp/pph-core.c b/gcc/cp/pph-core.c
index 33ed64b..a834f79 100644
--- a/gcc/cp/pph-core.c
+++ b/gcc/cp/pph-core.c
@@ -640,7 +640,7 @@ pph_include_handler (cpp_reader *reader,
read_text_file_p = false;
}
else
- warning_at (input_location, OPT_Wmissing_pph,
+ warning_at (loc, OPT_Wmissing_pph,
"cannot open PPH file %s for reading: %m\n"
"using original header %s", pph_file, name);
}
diff --git a/gcc/testsuite/g++.dg/pph/d1symnotinc.cc
b/gcc/testsuite/g++.dg/pph/d1symnotinc.cc
index dbdc2c0..a861e5f 100644
--- a/gcc/testsuite/g++.dg/pph/d1symnotinc.cc
+++ b/gcc/testsuite/g++.dg/pph/d1symnotinc.cc
@@ -1,4 +1,4 @@
-// { dg-message ".*fatal error: cannot open PPH file.*" }
+// { dg-options "-Wmissing-pph"
#define NAME v
#define VALUE 1
-#include "d0symnotinc.h"
+#include "d0symnotinc.h" // { dg-warning "cannot open PPH file .*" }
diff --git a/gcc/testsuite/g++.dg/pph/y8inc-nmspc.cc
b/gcc/testsuite/g++.dg/pph/y8inc-nmspc.cc
index 70b209a..be0520d 100644
--- a/gcc/testsuite/g++.dg/pph/y8inc-nmspc.cc
+++ b/gcc/testsuite/g++.dg/pph/y8inc-nmspc.cc
@@ -1,3 +1,4 @@
+// { dg-options "-Winvalid-pph" }
namespace smother {
-#include "x1struct1.h" // { dg-error "PPH file .* not included at global
scope" "" }
+#include "x1struct1.h" // { dg-warning "PPH file .* not included at global
scope" "" }
}
--
This patch is available for review at http://codereview.appspot.com/5476051
Re: [PATCH 0/6] Implement vec_perm_const consistently
On Thu, Dec 8, 2011 at 4:06 PM, Richard Henderson wrote: > rs6000: Implement vec_perm_constv16qi for altivec. > rs6000: Cleanup interleave/even_odd/vec_perm. The rs6000 patches are okay with the changes that you, Mike and I discussed on IRC. Thanks, David
Re: [PATCH 6/6] arm: Implement vec_perm and vec_perm_const for NEON.
On 12/09/2011 10:02 AM, Ramana Radhakrishnan wrote:
> For Neon a further optimization to consider might be to use the vext
> instruction which could achieve permute masks that are monotonically
> increasing constants ? While I expect the latency for a vext or vtbl
> instruction to be about the same (your mileage might vary depending on
> the core), using vext gives us the freedom of not needing a register
> for the permute mask -
>
> a = vec_shuffle (b, c, mask) where mask is { n + 7, n + 6, n + 5, n +
> 4, n + 3, n + 2, n + 1, n } could just be vext.8 A, B, C, #n
Good to know. I missed that one in my reading of the manual.
> Additionally , can we also detect rotate rights ? unless ofcourse
> there's a different interface -
>
>a = vec_shuffle (vec, {0, 7, 6, 5, 4, 3, 2, 1}) => vext.8 a, vec, vec, #1
Certainly we can.
r~
Re: PR/50076 make c-c++-common/cxxbitfields-3.c work in Darwin
On 12/09/11 13:19, Jakub Jelinek wrote:
On Fri, Dec 09, 2011 at 08:17:04PM +0100, Dominique Dhumieres wrote:
+/* { dg-final { scan-assembler "movl.*, (_?var|\\(%)" } } */
It works for me too.
Except that when matching just , (% it doesn't test almost anything.
IMNSHO you should instead just test it { target !fpic } or similar.
The _? in there is useful though.
Jakub
I assume you mean it tests almost anything, in which case I thought the
source tiny enough to not elicit any more loads that could be matched.
But the test is annoyingly system dependent.
How about the patch below?
I used nonpic instead of "!fpic", as check_effective_target_fpic tests
whether -fpic/-fPIC is supported in the driver, which will obviously
return true even if we're not generating PIC code. OTOH
check_effective_target_nonpic tests whether we are generating PIC code
by checking "#if __PIC__" which I believe is what we want.
Does this work for everyone?
* c-c++-common/cxxbitfields-3.c: Adjust regexp.
Index: c-c++-common/cxxbitfields-3.c
===
--- c-c++-common/cxxbitfields-3.c (revision 182028)
+++ c-c++-common/cxxbitfields-3.c (working copy)
@@ -18,4 +18,4 @@ void setit()
var.j = 5;
}
-/* { dg-final { scan-assembler "movl.*, var" } } */
+/* { dg-final { scan-assembler "movl.*, _?var" { target nonpic } } } */
[PATCH] Sink clobbers if EH block contains just clobbers (PR tree-optimization/51117)
Hi!
Even with the optimize_clobbers changes, for e.g.
struct A { char buf[64]; };
void bar (A *);
void
foo ()
{
A c;
bar (&c);
try
{
{
A a;
bar (&a);
if (a.buf[13])
throw 1;
else if (a.buf[52])
throw 3;
}
{
A b;
bar (&b);
if (b.buf[13])
throw 2;
}
}
catch ( ...)
{
throw;
}
}
we still generate much worse code since the introduction of
clobbers. This patch is an attempt to improve it, if we catch
an exception just to do a bunch of clobbers and then rethrow it
internally, the extra EH regions/rethrow can't be optimized away.
For that case this patch attempts to sink all the clobbers into the
single successor (through the EH edge) - if it wouldn't leave on that
edge the original scope, the clobbers wouldn't be there.
I had to tweak a little bit the expander conflict checking, because
if we have a BB with two incoming EH edges and clobber stmts from both
sunk into its beginning, then it would consider both variables (a and b
above) to be live at the same time, while there is no insn on which they
can actually live at the same time, the PHIs don't mention either of them
(and after all, PHIs aren't memory loads), and after the PHIs we have
immediately the clobbers.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2011-12-09 Jakub Jelinek
PR tree-optimization/51117
* tree-eh.c (sink_clobbers): New function.
(execute_lower_eh_dispatch): Call it for BBs ending with
internally throwing RESX.
* cfgexpand.c (add_scope_conflicts_1): Add SCRATCH argument.
If BB starts with clobbers of vars that aren't mentioned
in any of the PHIs, don't consider the clobbered vars live
on entry of the BB.
(add_scope_conflicts): Allocate and free SCRATCH bitmap
and pass it to add_scope_conflicts_1.
--- gcc/tree-eh.c.jj2011-12-09 15:13:51.849968215 +0100
+++ gcc/tree-eh.c 2011-12-09 15:07:46.608148450 +0100
@@ -3194,6 +3194,76 @@ optimize_clobbers (basic_block bb)
}
}
+/* Try to sink var = {v} {CLOBBER} stmts followed just by
+ internal throw to successor BB. */
+
+static int
+sink_clobbers (basic_block bb)
+{
+ edge e;
+ edge_iterator ei;
+ gimple_stmt_iterator gsi, dgsi;
+ basic_block succbb;
+ bool any_clobbers = false;
+
+ /* Only optimize if BB has a single EH successor and
+ all predecessor edges are EH too. */
+ if (!single_succ_p (bb)
+ || (single_succ_edge (bb)->flags & EDGE_EH) == 0)
+return 0;
+
+ FOR_EACH_EDGE (e, ei, bb->preds)
+{
+ if ((e->flags & EDGE_EH) == 0)
+ return 0;
+}
+
+ /* And BB contains only CLOBBER stmts before the final
+ RESX. */
+ gsi = gsi_last_bb (bb);
+ for (gsi_prev (&gsi); !gsi_end_p (gsi); gsi_prev (&gsi))
+{
+ gimple stmt = gsi_stmt (gsi);
+ if (is_gimple_debug (stmt))
+ continue;
+ if (gimple_code (stmt) == GIMPLE_LABEL)
+ break;
+ if (!gimple_clobber_p (stmt)
+ || TREE_CODE (gimple_assign_lhs (stmt)) == SSA_NAME)
+ return 0;
+ any_clobbers = true;
+}
+ if (!any_clobbers)
+return 0;
+
+ succbb = single_succ (bb);
+ dgsi = gsi_after_labels (succbb);
+ gsi = gsi_last_bb (bb);
+ for (gsi_prev (&gsi); !gsi_end_p (gsi); gsi_prev (&gsi))
+{
+ gimple stmt = gsi_stmt (gsi);
+ tree vdef;
+ if (is_gimple_debug (stmt))
+ continue;
+ if (gimple_code (stmt) == GIMPLE_LABEL)
+ break;
+ unlink_stmt_vdef (stmt);
+ gsi_remove (&gsi, false);
+ vdef = gimple_vdef (stmt);
+ if (vdef && TREE_CODE (vdef) == SSA_NAME)
+ {
+ vdef = SSA_NAME_VAR (vdef);
+ mark_sym_for_renaming (vdef);
+ gimple_set_vdef (stmt, vdef);
+ gimple_set_vuse (stmt, vdef);
+ }
+ release_defs (stmt);
+ gsi_insert_before (&dgsi, stmt, GSI_SAME_STMT);
+}
+
+ return TODO_update_ssa_only_virtuals;
+}
+
/* At the end of inlining, we can lower EH_DISPATCH. Return true when
we have found some duplicate labels and removed some edges. */
@@ -3349,7 +3419,7 @@ static unsigned
execute_lower_eh_dispatch (void)
{
basic_block bb;
- bool any_rewritten = false;
+ int flags = 0;
bool redirected = false;
assign_filter_values ();
@@ -3362,16 +3432,20 @@ execute_lower_eh_dispatch (void)
if (gimple_code (last) == GIMPLE_EH_DISPATCH)
{
redirected |= lower_eh_dispatch (bb, last);
- any_rewritten = true;
+ flags |= TODO_update_ssa_only_virtuals;
+ }
+ else if (gimple_code (last) == GIMPLE_RESX)
+ {
+ if (stmt_can_throw_external (last))
+ optimize_clobbers (bb);
+ else
+ flags |= sink_clobbers (bb);
}
- else if (gimple_code (last) == GIMPLE_RESX
- && stmt_can_throw_external (last))
- optimize_clobbers (bb);
}
if (redirected)
delete_unreachable_blocks ();
-
Re: [PATCH][C++] Fix PR51262
OK. Jason
C++ PATCH for c++/51151 (bogus -Woverflow)
This was caused by my earlier kludge to build normal conversions between
scalar types in templates; the instantiation code isn't prepared to deal
with all the various tree forms that can occur that way. So now I've
limited it to the identity conversion, which shouldn't require any added
trees at all.
The OMP change was necessary to avoid problems with some OMP tests
complaining about IMPLICIT_CONV_EXPR in increment expressions.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 03cb051073127d8189fb1800bb1e72d2907937ac
Author: Jason Merrill
Date: Thu Dec 8 15:22:53 2011 -0500
PR c++/51151
* call.c (perform_implicit_conversion_flags): Remove earlier kludge.
* parser.c (cp_parser_omp_for_loop): Use cp_parser_omp_for_incr
in templates even if decl isn't type-dependent.
diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index d8fc4f1..6528368 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -8437,10 +8437,7 @@ perform_implicit_conversion_flags (tree type, tree expr, tsubst_flags_t complain
}
expr = error_mark_node;
}
- else if (processing_template_decl
- /* As a kludge, we always perform conversions between scalar
- types, as IMPLICIT_CONV_EXPR confuses c_finish_omp_for. */
- && !(SCALAR_TYPE_P (type) && SCALAR_TYPE_P (TREE_TYPE (expr
+ else if (processing_template_decl && conv->kind != ck_identity)
{
/* In a template, we are only concerned about determining the
type of non-dependent expressions, so we do not have to
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 5952a0f..2985d76 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -26305,7 +26305,7 @@ cp_parser_omp_for_loop (cp_parser *parser, tree clauses, tree *par_clauses)
/* If decl is an iterator, preserve the operator on decl
until finish_omp_for. */
if (decl
- && ((type_dependent_expression_p (decl)
+ && ((processing_template_decl
&& !POINTER_TYPE_P (TREE_TYPE (decl)))
|| CLASS_TYPE_P (TREE_TYPE (decl
incr = cp_parser_omp_for_incr (parser, decl);
diff --git a/gcc/testsuite/g++.dg/warn/Woverflow-4.C b/gcc/testsuite/g++.dg/warn/Woverflow-4.C
new file mode 100644
index 000..1595bca
--- /dev/null
+++ b/gcc/testsuite/g++.dg/warn/Woverflow-4.C
@@ -0,0 +1,13 @@
+// PR c++/51151
+// { dg-options "-Wshadow" }
+
+template class C {
+public:
+ void f() {
+m = c2 + 1;
+ }
+ static const long unsigned int c1 = 7;
+ static const int c2 = c1 - 1;
+ int m;
+};
+template class C;
[PATCH 0/2] Better represent unbound template specializations (PR c++/51239, c++/51180)
Hello, The little patch set of this thread addresses PRs c++/51239 and PRs c++/51180 in a generic way, as you suggested. It replaces the BOUND_TEMPLATE_TEMPLATE_PARM tree with a TEMPLATE_ID_TYPE tree and makes bound template template parameters and typename types use that new tree. With this infrastructure in place, it was quite easy to represent unbound specializations of alias templates using the TEMPLATE_ID_TYPE tree. Thus, there are two patches in this set. The first, biggest one creates the TEMPLATE_ID_TYPE tree and makes typename types and bound template template parameters use it, and the second easily uses that to represent unbound specializations of alias templates to actually fix PRs c++/51239 and PRs c++/51180. Each patch has been bootstrapped and tested on x86_64-unknown-linux-gnu against trunk. -- Dodji
[PATCH 1/2] Use TEMPLATE_ID_TYPE in lieu of BOUND_TEMPLATE_TEMPLATE_PARM
As presented in the cover message, this patch replaces the BOUND_TEMPLATE_TEMPLATE_PARM tree with a TEMPLATE_ID_TYPE tree that represents a template-id whose arguments haven't yet been applied to its template. The template itself might have not been resolved to a TEMPLATE_DECL yet, in which case it's just an IDENTIFIER_NODE. The functionality of representing BOUND_TEMPLATE_TEMPLATE_PARM then gets expressed by using a TEMPLATE_ID_TYPE in which the template validates the DECL_TEMPLATE_TEMPLATE_PARAMETER_P predicate. Additionally, the TYPENAME_TYPE_FULLNAME of a TYPENAME_TYPE is also represented using a TEMPLATE_ID_TYPE, rather than a TEMPLATE_ID_EXPR - even when make_typename_type is passed a TEMPLATE_ID_EXPR. Note that the TEMPLATE_ID_TYPE yielded by TYPENAME_TYPE_FULLNAME can either have a TEMPLATE_DECL or just an IDENTIFIER_NODE, depending on if the template name of the template-id could be resolved to a template at the point where the typename was formed or not. Bootstrapped and tested on x86_64-unknown-linux-gnu against trunk. gcc/cp/ PR c++/51239 * cp_tree.def (TEMPLATE_TYPE_PARM): Rename BOUND_TEMPLATE_TEMPLATE_PARM into TEMPLATE_ID_TYPE in comments. (TEMPLATE_ID_TYPE): Renamed BOUND_TEMPLATE_TEMPLATE_PARM into this. Update comments. * cp-tree.h (build_template_id_type): (TEMPLATE_ID_TYPE_TYPE_CHECK): Turn BOUND_TEMPLATE_TEMPLATE_PARM_TYPE_CHECK into this. (BOUND_TEMPLATE_TEMPLATE_PARM_P): New predicate macro. (MAYBE_CLASS_TYPE_P): Rename BOUND_TEMPLATE_TEMPLATE_PARM into TEMPLATE_ID_TYPE. (TEMPLATE_ID_TYPE_TEMPLATE_INFO): Turn TEMPLATE_TEMPLATE_PARM_TEMPLATE_INFO into this. (TYPE_TEMPLATE_INFO): Support TEMPLATE_ID_TYPE. (SET_TYPE_TEMPLATE_INFO): Update to support TEMPLATE_ID_TYPE, and to better support type aliases. (TYPENAME_TYPE_FULLNAME): Replace TEMPLATE_ID_EXPR with TEMPLATE_ID_TYPE in comments. (TEMPLATE_TYPE_PARM_INDEX): Rename BOUND_TEMPLATE_TEMPLATE_PARM into TEMPLATE_ID_TYPE in the definition of this macro. (TEMPLATE_TEMPLATE_PARM_TEMPLATE_DECL): Use BOUND_TEMPLATE_TEMPLATE_PARM_P instead of BOUND_TEMPLATE_TEMPLATE_PARM. * cp-objcp-common.c (cp_common_init_ts): Rename BOUND_TEMPLATE_TEMPLATE_PARM into TEMPLATE_ID_TYPE. * cxx-pretty-print.c (pp_cxx_unqualified_id): Renamed BOUND_TEMPLATE_TEMPLATE_PARM into this. (pp_cxx_type_specifier_seq): Likewise. (pp_cxx_direct_abstract_declarator)>: Likewise. (pp_cxx_type_id): Likewise. (pp_cxx_canonical_template_parameter): Use BOUND_TEMPLATE_TEMPLATE_PARM_P instead of BOUND_TEMPLATE_TEMPLATE_PARM. * decl.c (make_typename_type): Store unbound template-id in a TEMPLATE_ID_TYPE instead of in a TEMPLATE_ID_EXPR. (check_elaborated_type_specifier): Use BOUND_TEMPLATE_TEMPLATE_PARM_P instead of BOUND_TEMPLATE_TEMPLATE_PARM. * decl2.c (is_late_template_attribute): Use BOUND_TEMPLATE_TEMPLATE_PARM_P instead of BOUND_TEMPLATE_TEMPLATE_PARM. * error.c (dump_type): Replace BOUND_TEMPLATE_TEMPLATE_PARM with this. (dump_typename): Use dump_type on TYPENAME_TYPE_FULLNAME rather than dump_decl. (dump_type_prefix, dump_type_suffix, dump_expr): Replace BOUND_TEMPLATE_TEMPLATE_PARM with this. * lex.c (cxx_make_type): Replace BOUND_TEMPLATE_TEMPLATE_PARM with TEMPLATE_ID_TYPE. * mangle.c (CLASSTYPE_TEMPLATE_ID_P): Replace use of BOUND_TEMPLATE_TEMPLATE_PARM with BOUND_TEMPLATE_TEMPLATE_PARM_P. (write_nested_name, write_prefix): Replace use of TEMPLATE_ID_EXPR with TEMPLATE_ID_TYPE. Use TYPE_TI_ARGS on the TYPENAME_TYPE_FULLNAME rather than TREE_OPERAND. (write_type): Replace BOUND_TEMPLATE_TEMPLATE_PARM with this. Use TYPE_TI_ARGS rather than TI_ARGS of TEMPLATE_TEMPLATE_PARM_TEMPLATE_INFO. (write_expression): USe BOUND_TEMPLATE_TEMPLATE_PARM_P instead of BOUND_TEMPLATE_TEMPLATE_PARM. (write_template_param): Replace BOUND_TEMPLATE_TEMPLATE_PARM with this. (write_template_template_param): Use BOUND_TEMPLATE_TEMPLATE_PARM_P instead of BOUND_TEMPLATE_TEMPLATE_PARM, TYPE_TEMPLATE_INFO instead of TEMPLATE_TEMPLATE_PARM_TEMPLATE_INFO. * name-lookup.c (arg_assoc_type): Rename BOUND_TEMPLATE_TEMPLATE_PARM into this. * parser.c (cp_parser_nested_name_specifier_opt): Replace TEMPLATE_ID_EXPR with TEMPLATE_ID_TYPE. * pt.c (get_template_info): Use TYPE_TEMPLATE_INFO to get TEMPLATE_INFO from types in general. (maybe_process_partial_specialization): Use BOUND_TEMPLATE_TEMPLATE_PARM_P instead of BOUND_TEMPLATE_TEMPLATE_PARM. (find_parameter_packs_r): Replaced case BOUND_TEMPLA
[PATCH 2/2] PR c++/51239, c++/51180 - Better support for unbound alias templates
With the infrastructure of the previous patch in place, this patch
easily uses TEMPLATE_ID_TYPE to represent unbound specializations of
alias templates, thus fixing PR c++/51239.
A new function introduced to fix that bug is also used to address PR
c++/51180 by fixing the representation of template specializations
where the arguments contain a pack expansion.
Bootstrapped and tested on x86_64-unknown-linux-gnu against trunk.
gcc/cp/
PR c++/51239
PR c++/51180
* cp-tree.h (any_pack_expansion_template_argument_p): Declare new
function.
* pt.c (any_pack_expansion_template_argument_p): Define it.
(coerce_template_parms, lookup_template_class_1): Use it.
gcc/testsuite/
PR c++/51239
PR c++/51180
* g++.dg/cpp0x/alias-decl-18.C: New test.
* g++.dg/cpp0x/alias-decl-19.C: Likewise.
* g++.dg/cpp0x/alias-decl-15.C: This was wrongly expected
to fail before. Adjust accordingly.
---
gcc/cp/cp-tree.h |1 +
gcc/cp/pt.c| 32 +++-
gcc/testsuite/g++.dg/cpp0x/alias-decl-15.C |8 +++---
gcc/testsuite/g++.dg/cpp0x/alias-decl-18.C | 29 +
gcc/testsuite/g++.dg/cpp0x/alias-decl-19.C | 19
5 files changed, 84 insertions(+), 5 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/cpp0x/alias-decl-18.C
create mode 100644 gcc/testsuite/g++.dg/cpp0x/alias-decl-19.C
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index fa5bf7f..ef0ef1b 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -5333,6 +5333,7 @@ extern int processing_template_parmlist;
extern bool dependent_type_p (tree);
extern bool dependent_scope_p (tree);
extern bool any_dependent_template_arguments_p (const_tree);
+extern bool any_pack_expansion_template_argument_p (tree);
extern bool dependent_template_p (tree);
extern bool dependent_template_id_p(tree, tree);
extern bool type_dependent_expression_p(tree);
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 7d00770..634e7e0 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -6787,7 +6787,8 @@ coerce_template_parms (tree parms,
&& require_all_args
&& (!use_default_args
|| (TREE_VEC_ELT (parms, nargs) != error_mark_node
- && !TREE_PURPOSE (TREE_VEC_ELT (parms, nargs))
+ && !TREE_PURPOSE (TREE_VEC_ELT (parms, nargs
+ && !any_pack_expansion_template_argument_p (inner_args)))
{
if (complain & tf_error)
{
@@ -7484,6 +7485,14 @@ lookup_template_class_1 (tree d1, tree arglist, tree
in_decl, tree context,
}
else if (DECL_ALIAS_TEMPLATE_P (gen_tmpl))
{
+ if (any_pack_expansion_template_argument_p (arglist))
+ /* So we don't yet know the number of arguments the
+ alias template specialization has. Let's build a
+ representation that keeps the arguments "unapplied"
+ to the alias template for now, so that we can apply
+ the them later when they are fully known. */
+ return build_template_id_type (gen_tmpl, arglist);
+
/* The user referred to a specialization of an alias
template represented by GEN_TMPL.
@@ -19894,6 +19903,27 @@ any_dependent_template_arguments_p (const_tree args)
return false;
}
+/* Return true if ARGS (a TREE_VEC of template arguments) contains
+ any pack expansion. */
+
+bool
+any_pack_expansion_template_argument_p (tree args)
+{
+ int i;
+
+ if (args == NULL_TREE || TREE_CODE (args) != TREE_VEC)
+return false;
+
+ for (i = 0; i < TREE_VEC_LENGTH (args); ++i)
+{
+ tree elt = TREE_VEC_ELT (args, i);
+ if (elt != NULL_TREE && PACK_EXPANSION_P (elt))
+ return true;
+}
+
+ return false;
+}
+
/* Returns TRUE if the template TMPL is dependent. */
bool
diff --git a/gcc/testsuite/g++.dg/cpp0x/alias-decl-15.C
b/gcc/testsuite/g++.dg/cpp0x/alias-decl-15.C
index 2bc9b11..19f1a8d 100644
--- a/gcc/testsuite/g++.dg/cpp0x/alias-decl-15.C
+++ b/gcc/testsuite/g++.dg/cpp0x/alias-decl-15.C
@@ -1,8 +1,8 @@
// Origin PR c++/51194
// { dg-options "-std=c++0x" }
-template //#1
-struct foo {}; // { dg-error "provided for|foo" }
+template
+struct foo {};
template
struct P {};
@@ -10,8 +10,8 @@ struct P {};
template class... TT>
struct bar {
template
-using mem = P...>;//#2 { dg-error "wrong number of|arguments" }
+using mem = P...>;
};
-bar::mem b;//#3 { dg-error "invalid type" }
+bar::mem b;
diff --git a/gcc/testsuite/g++.dg/cpp0x/alias-decl-18.C
b/gcc/testsuite/g++.dg/cpp0x/alias-decl-18.C
new file mode 100644
index 000..311ab58
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/alias-decl-18.C
@@ -0,0 +1,29 @@
+// Origin PR c++/51239
+// { dg-options "-std=c++11" }
+
+struct S {};
+
+template
+using head = T;
+
+template
Re: PR/50076 make c-c++-common/cxxbitfields-3.c work in Darwin
On Fri, Dec 09, 2011 at 01:45:48PM -0600, Aldy Hernandez wrote:
> On 12/09/11 13:19, Jakub Jelinek wrote:
>> On Fri, Dec 09, 2011 at 08:17:04PM +0100, Dominique Dhumieres wrote:
+/* { dg-final { scan-assembler "movl.*, (_?var|\\(%)" } } */
>>>
>>> It works for me too.
>>
>> Except that when matching just , (% it doesn't test almost anything.
>> IMNSHO you should instead just test it { target !fpic } or similar.
>> The _? in there is useful though.
>>
>> Jakub
>
> I assume you mean it tests almost anything, in which case I thought the
> source tiny enough to not elicit any more loads that could be matched.
> But the test is annoyingly system dependent.
>
> How about the patch below?
>
> I used nonpic instead of "!fpic", as check_effective_target_fpic tests
> whether -fpic/-fPIC is supported in the driver, which will obviously
> return true even if we're not generating PIC code. OTOH
> check_effective_target_nonpic tests whether we are generating PIC code
> by checking "#if __PIC__" which I believe is what we want.
>
> Does this work for everyone?
This works for x86_64-apple-darwin11 using...
make -k check RUNTESTFLAGS="dg.exp=cxxbitfields-3.c
--target_board=unix'{-m32,-m64}'"
> * c-c++-common/cxxbitfields-3.c: Adjust regexp.
>
> Index: c-c++-common/cxxbitfields-3.c
> ===
> --- c-c++-common/cxxbitfields-3.c (revision 182028)
> +++ c-c++-common/cxxbitfields-3.c (working copy)
> @@ -18,4 +18,4 @@ void setit()
>var.j = 5;
> }
>
> -/* { dg-final { scan-assembler "movl.*, var" } } */
> +/* { dg-final { scan-assembler "movl.*, _?var" { target nonpic } } } */
Re: [PATCH] Fix up optimize_clobbers (PR tree-optimization/51117)
On 12/09/2011 09:11 AM, Jakub Jelinek wrote: > PR tree-optimization/51117 > * tree-eh.c (optimize_clobbers): Don't remove just one > clobber, but all consecutive clobbers before RESX. > Use gimple_clobber_p predicate. Ok. r~
Re: PR/50076 make c-c++-common/cxxbitfields-3.c work in Darwin
On 9 Dec 2011, at 19:45, Aldy Hernandez wrote:
On 12/09/11 13:19, Jakub Jelinek wrote:
On Fri, Dec 09, 2011 at 08:17:04PM +0100, Dominique Dhumieres wrote:
+/* { dg-final { scan-assembler "movl.*, (_?var|\\(%)" } } */
It works for me too.
Except that when matching just , (% it doesn't test almost anything.
IMNSHO you should instead just test it { target !fpic } or similar.
Darwin is not the only target that defaults to PIC.
ISTM, in this particular instance, the check for
movl , (%
happens to be enough to detect the case Aldy is interested in (at
least for the code sequences Darwin generates).
Does this work for everyone?
... well that "works" for Darwin by not performing the test ..
.. might as well just skip the whole thing and save the cycles on the
compile ;-)
===
the problem in finding a match s that c and c++ generate different
sequences
- and the test is in the shared dir
... otherwise a target-dependent match would work ...
[[** I'm checking out whether it's feasible to switch off PIC for m64
Darwin .. so one could just do the test -fno-PIC ..
... works for m32 - but PIC is jammed on for x86/m64 ... ]]
Iain
it seems that each case is doing the correct thing ..
==
c / m32
L001$pb:
movlL_var$non_lazy_ptr-L001$pb(%ecx), %edx
movl(%edx), %eax
andb$15, %al
orl $80, %eax
movl%eax, (%edx)
ret
c / m64
_setit:
LFB0:
movq_var@GOTPCREL(%rip), %rdx
movl(%rdx), %eax
andb$15, %al
orl $80, %eax
movl%eax, (%rdx)
ret
===
c++ / m32
__Z5setitv:
LFB0:
call___x86.get_pc_thunk.cx
L001$pb:
movl_var-L001$pb(%ecx), %eax
andb$15, %al
orl $80, %eax
movl%eax, _var-L001$pb(%ecx)
ret
c++ / m64
__Z5setitv:
LFB0:
movl_var(%rip), %eax
andb$15, %al
orl $80, %eax
movl%eax, _var(%rip)
ret
Re: unordered containers emplace
Attached patch applied.
2011-12-09 François Dumont
* include/bits/hashtable.h (_Hashtable<>::emplace,
_Hashtable<>::emplace_hint): Add.
* include/debug/unordered_set (unordered_set<>::emplace,
unordered_set<>::emplace_hint, unordered_multiset<>::emplace,
unordered_multiset<>::emplace_hint): Add.
* include/profile/unordered_set: Likewise.
* include/debug/unordered_map (unordered_map<>::emplace,
unordered_map<>::emplace_hint, unordered_multimap<>::emplace,
unordered_multimap<>::emplace_hint): Add.
* include/profile/unordered_map: Likewise.
* testsuite/23_containers/unordered_map/modifiers/emplace.cc: New.
* testsuite/23_containers/unordered_multimap/modifiers/emplace.cc:
New.
* testsuite/23_containers/unordered_set/modifiers/emplace.cc: New.
* testsuite/23_containers/unordered_multiset/modifiers/emplace.cc:
New.
* testsuite/util/testsuite_container_traits.h
(traits_base::has_emplace): Add and defined as std::true_type for
unordered containers.
* testsuite/util/exception/safety.h (emplace, emplace_hint):
Add and
use them in basic_safety exception test case.
* doc/xml/manual/status_cxx2011.xml: Update unordered containers
status.
Regards
On 12/09/2011 11:17 AM, Paolo Carlini wrote:
Ok to commit ?
Sure, thanks!
Paolo.
Index: doc/xml/manual/status_cxx2011.xml
===
--- doc/xml/manual/status_cxx2011.xml (revision 182133)
+++ doc/xml/manual/status_cxx2011.xml (working copy)
@@ -1403,11 +1403,10 @@
Missing emplace members
-
23.2.5
Unordered associative containers
- Partial
- Missing emplace members
+ Y
+
23.3
Index: include/debug/unordered_map
===
--- include/debug/unordered_map (revision 182133)
+++ include/debug/unordered_map (working copy)
@@ -204,6 +204,29 @@
cend(size_type __b) const
{ return const_local_iterator(_Base::cend(__b), __b, this); }
+ template
+ std::pair
+ emplace(_Args&&... __args)
+ {
+ size_type __bucket_count = this->bucket_count();
+ std::pair<_Base_iterator, bool> __res
+ = _Base::emplace(std::forward<_Args>(__args)...);
+ _M_check_rehashed(__bucket_count);
+ return std::make_pair(iterator(__res.first, this), __res.second);
+ }
+
+ template
+ iterator
+ emplace_hint(const_iterator __hint, _Args&&... __args)
+ {
+ __glibcxx_check_insert(__hint);
+ size_type __bucket_count = this->bucket_count();
+ _Base_iterator __it = _Base::emplace_hint(__hint.base(),
+ std::forward<_Args>(__args)...);
+ _M_check_rehashed(__bucket_count);
+ return iterator(__it, this);
+ }
+
std::pair
insert(const value_type& __obj)
{
@@ -587,6 +610,29 @@
cend(size_type __b) const
{ return const_local_iterator(_Base::cend(__b), __b, this); }
+ template
+ iterator
+ emplace(_Args&&... __args)
+ {
+ size_type __bucket_count = this->bucket_count();
+ _Base_iterator __it
+ = _Base::emplace(std::forward<_Args>(__args)...);
+ _M_check_rehashed(__bucket_count);
+ return iterator(__it, this);
+ }
+
+ template
+ iterator
+ emplace_hint(const_iterator __hint, _Args&&... __args)
+ {
+ __glibcxx_check_insert(__hint);
+ size_type __bucket_count = this->bucket_count();
+ _Base_iterator __it = _Base::emplace_hint(__hint.base(),
+ std::forward<_Args>(__args)...);
+ _M_check_rehashed(__bucket_count);
+ return iterator(__it, this);
+ }
+
iterator
insert(const value_type& __obj)
{
Index: include/debug/unordered_set
===
--- include/debug/unordered_set (revision 182133)
+++ include/debug/unordered_set (working copy)
@@ -204,6 +204,29 @@
cend(size_type __b) const
{ return const_local_iterator(_Base::cend(__b), __b, this); }
+ template
+ std::pair
+ emplace(_Args&&... __args)
+ {
+ size_type __bucket_count = this->bucket_count();
+ std::pair<_Base_iterator, bool> __res
+ = _Base::emplace(std::forward<_Args>(__args)...);
+ _M_check_rehashed(__bucket_count);
+ return std::make_pair(iterator(__res.first, this), __res.second);
+ }
+
+ template
+ iterator
+ emplace_hint(const_iterator __hint, _Args&&... __args)
+ {
+ __glibcxx_check_insert(__hint);
+ size_type __bucket_count = this->bucket_count();
+ _Base_iterator __it = _Base::emplace_hint(__hint.base(),
+ std::forward<_Args>(__args)...);
+ _M_check_rehashed(__bucket_count);
+ return iterator(__it, this);
+ }
+
std::pair
insert(const value_type& __obj)
{
@@ -582,6 +605,29 @@
cend(size_type __b) const
{ return const_local_iterator(_Base::cend(__b), __b, this); }
+ template
+ iterator
+ emplace(_Args&&... _
Fix oversight in change to gimple_fold_stmt_to_constant_1
When the call to useless_type_conversion_p was removed for the pointer sub-case
in the GIMPLE_UNARY_RHS case, it was replaced with a check on TYPE_ADDR_SPACE.
This isn't sufficient to guarantee that the value is preserved when pointer can
have different modes like on s390x or VMS, and useless_type_conversion_p has a
check on TYPE_MODE so you'll get a verification failure at -O on the attached
testcase because FRE builds a VIEW_CONVERT_EXPR with different sizes.
Tested on i586-suse-linux, applied on the mainline as obvious.
2011-12-09 Eric Botcazou
* gimple-fold.c (gimple_fold_stmt_to_constant_1) :
Also check the TYPE_MODE to recognize useless pointer conversions.
2011-12-09 Eric Botcazou
* gcc.c-torture/compile/20111209-1.c: New test.
--
Eric Botcazou
Index: gimple-fold.c
===
--- gimple-fold.c (revision 182102)
+++ gimple-fold.c (working copy)
@@ -2517,8 +2517,10 @@ gimple_fold_stmt_to_constant_1 (gimple s
if (CONVERT_EXPR_CODE_P (subcode)
&& POINTER_TYPE_P (TREE_TYPE (lhs))
&& POINTER_TYPE_P (TREE_TYPE (op0))
- && (TYPE_ADDR_SPACE (TREE_TYPE (lhs))
- == TYPE_ADDR_SPACE (TREE_TYPE (op0
+ && TYPE_ADDR_SPACE (TREE_TYPE (lhs))
+ == TYPE_ADDR_SPACE (TREE_TYPE (op0))
+ && TYPE_MODE (TREE_TYPE (lhs))
+ == TYPE_MODE (TREE_TYPE (op0)))
return op0;
return
/* { dg-do compile { target s390x-*-* *-*-*vms* } } */
typedef char* char_ptr32 __attribute__ ((mode(SI)));
char_ptr32 getenv (const char *name);
unsigned long strlen (const char *str);
void
__gnat_getenv (char *name, int *len, char **value)
{
*value = getenv (name);
*len = strlen (*value);
}
[libgo] PATCH: Handle system call numbers "(0x40000000 | (234))"
Hi Ian,
Some my Linux system, system call numbers are defined as
#define __NR_x32_rt_sigaction __NR_X32_SYSCALL(0)
and
__NR_X32_SYSCALL(0) is expanded to (0x4000 | (512 + 0)). This patch
tries to deal with by checking '^// unknowndefine SYS_[a-z]' and uses
"${CC} -E" to extract the real number. Tested on Linux/x86-64. OK
to install?
Thanks.
H.J.
---
2011-12-09 H.J. Lu
* mksysinfo.sh: Handle system call numbers "(0x4000 | (234))".
diff --git a/libgo/mksysinfo.sh b/libgo/mksysinfo.sh
index e29febf..1766136 100755
--- a/libgo/mksysinfo.sh
+++ b/libgo/mksysinfo.sh
@@ -118,6 +118,22 @@ grep '^const _SYS_' gen-sysinfo.go | \
echo "const $sup = _$sys" >> ${OUT}
done
+# Handle system call numbers like "(0x4000 | (234))"
+if grep '^// unknowndefine SYS_[a-z]' gen-sysinfo.go >/dev/null 2>&1; then
+ rm -f unknown-syscalls.c
+ echo "#include \"sysinfo.c\"" > unknown-syscalls.c
+ grep '^// unknowndefine SYS_[a-z]' gen-sysinfo.go | \
+grep __NR_ | \
+awk '{ print $3 }' | \
+while read sys; do
+ sup=`echo $sys | tr abcdefghijklmnopqrstuvwxyz
ABCDEFGHIJKLMNOPQRSTUVWXYZ`
+ echo "const $sup = $sys"
+done >> unknown-syscalls.c
+${CC} -E unknown-syscalls.c | \
+ grep "^const SYS_.*=" | \
+ grep -v __NR_ >> ${OUT}
+fi
+
# Stat constants.
grep '^const _S_' gen-sysinfo.go | \
sed -e 's/^\(const \)_\(S_[^= ]*\)\(.*\)$/\1\2 = _\2/' >> ${OUT}
PR/51291: fix -fgnu-tm ICEs on fortran
Compiling any fortran program with -fgnu-tm currently ICEs because the
TM builtins are defined in gtm-builtins.def which are not included (via
builtins.def) in the Fotran front-end.
Presently, there are no TM extensions for the Fortran language, but it
shouldn't ICE. We could error out early during the compilation if
-fgnu-tm is passed to the fortran front-end, but I'd rather just ignore
the builtin TM initialization if the front-end doesn't define the builtins.
Also, __builtin_eh_pointer is currently ECF_TM_PURE which triggers
applying the transaction_pure attribute. In Fortran, we don't have the
attribute.
Either way (erroring out early or my current approach) is fine with me.
This is the approach I tested.
OK?
PR/51291
* tree.c (build_common_builtin_nodes): Do not use TM_PURE
attribute unless language has support for TM.
* config/i386/i386.c (ix86_init_tm_builtins): Exit gracefully in
the absence of TM builtins.
Index: tree.c
===
--- tree.c (revision 182028)
+++ tree.c (working copy)
@@ -9442,6 +9442,7 @@ void
build_common_builtin_nodes (void)
{
tree tmp, ftype;
+ int ecf_flags;
if (!builtin_decl_explicit_p (BUILT_IN_MEMCPY)
|| !builtin_decl_explicit_p (BUILT_IN_MEMMOVE))
@@ -9594,9 +9595,12 @@ build_common_builtin_nodes (void)
its value in the landing pad. */
ftype = build_function_type_list (ptr_type_node,
integer_type_node, NULL_TREE);
+ ecf_flags = ECF_PURE | ECF_NOTHROW | ECF_LEAF;
+ /* Only use TM_PURE if we we have TM language support. */
+ if (builtin_decl_explicit_p (BUILT_IN_TM_LOAD_1))
+ecf_flags |= ECF_TM_PURE;
local_define_builtin ("__builtin_eh_pointer", ftype, BUILT_IN_EH_POINTER,
- "__builtin_eh_pointer",
- ECF_PURE | ECF_NOTHROW | ECF_LEAF | ECF_TM_PURE);
+ "__builtin_eh_pointer", ecf_flags);
tmp = lang_hooks.types.type_for_mode (targetm.eh_return_filter_mode (), 0);
ftype = build_function_type_list (tmp, integer_type_node, NULL_TREE);
Index: testsuite/gfortran.dg/trans-mem-skel.f90
===
--- testsuite/gfortran.dg/trans-mem-skel.f90(revision 0)
+++ testsuite/gfortran.dg/trans-mem-skel.f90(revision 0)
@@ -0,0 +1,5 @@
+! { dg-do compile }
+! { dg-options "-fgnu-tm" }
+program foo
+ real x
+end program foo
Index: config/i386/i386.c
===
--- config/i386/i386.c (revision 182028)
+++ config/i386/i386.c (working copy)
@@ -27023,6 +27023,11 @@ ix86_init_tm_builtins (void)
if (!flag_tm)
return;
+ /* If there are no builtins defined, we must be compiling in a
+ language without trans-mem support. */
+ if (!builtin_decl_explicit_p (BUILT_IN_TM_LOAD_1))
+return;
+
/* Use whatever attributes a normal TM load has. */
decl = builtin_decl_explicit (BUILT_IN_TM_LOAD_1);
attrs_load = DECL_ATTRIBUTES (decl);
Re: PR/51291: fix -fgnu-tm ICEs on fortran
On 12/09/2011 01:44 PM, Aldy Hernandez wrote: > PR/51291 > * tree.c (build_common_builtin_nodes): Do not use TM_PURE > attribute unless language has support for TM. > * config/i386/i386.c (ix86_init_tm_builtins): Exit gracefully in > the absence of TM builtins. Ok. r~
Re: [libgo] PATCH: Handle system call numbers "(0x40000000 | (234))"
"H.J. Lu" writes:
> Some my Linux system, system call numbers are defined as
>
> #define __NR_x32_rt_sigaction __NR_X32_SYSCALL(0)
>
> and
>
> __NR_X32_SYSCALL(0) is expanded to (0x4000 | (512 + 0)). This patch
> tries to deal with by checking '^// unknowndefine SYS_[a-z]' and uses
> "${CC} -E" to extract the real number. Tested on Linux/x86-64. OK
> to install?
This patch might be a little simpler. Does it solve the problem?
Ian
diff -r 864416b061a9 libgo/mksysinfo.sh
--- a/libgo/mksysinfo.sh Fri Dec 09 08:46:12 2011 -0800
+++ b/libgo/mksysinfo.sh Fri Dec 09 14:45:52 2011 -0800
@@ -97,6 +97,13 @@
${CC} -fdump-go-spec=gen-sysinfo.go -std=gnu99 -S -o sysinfo.s sysinfo.c
+# Pick up some constants that may be defined using preprocessor
+# macros.
+grep '^// unknowndefine SYS_' gen-sysinfo.go | \
+ sed -e 's|^// unknowndefine \(SYS_[^ ]*\) \(.*\)$|enum { \1 = \2 };|' \
+>> sysinfo.c
+${CC} -fdump-go-spec=gen-sysinfo.go -std=gnu99 -S -o sysinfo.s sysinfo.c
+
echo 'package syscall' > ${OUT}
echo 'import "unsafe"' >> ${OUT}
echo 'type _ unsafe.Pointer' >> ${OUT}
Re: [Patch, i386] Limit unroll factor for certain loops on Corei7
The patch is good for google branches for now while waiting for upstream review.
David
On Sun, Dec 4, 2011 at 10:26 PM, Teresa Johnson wrote:
> Latest patch which improves the efficiency as described below is
> included here. Boostrapped and checked again with
> x86_64-unknown-linux-gnu. Could someone review?
>
> Thanks,
> Teresa
>
> 2011-12-04 Teresa Johnson
>
> * loop-unroll.c (decide_unroll_constant_iterations): Call loop
> unroll target hook.
> * config/i386/i386.c (ix86_loop_unroll_adjust): New function.
> (TARGET_LOOP_UNROLL_ADJUST): Define hook for x86.
>
> ===
> --- loop-unroll.c (revision 181902)
> +++ loop-unroll.c (working copy)
> @@ -547,6 +547,9 @@ decide_unroll_constant_iterations (struc
> if (nunroll > (unsigned) PARAM_VALUE (PARAM_MAX_UNROLL_TIMES))
> nunroll = PARAM_VALUE (PARAM_MAX_UNROLL_TIMES);
>
> + if (targetm.loop_unroll_adjust)
> + nunroll = targetm.loop_unroll_adjust (nunroll, loop);
> +
> /* Skip big loops. */
> if (nunroll <= 1)
> {
> Index: config/i386/i386.c
> ===
> --- config/i386/i386.c (revision 181902)
> +++ config/i386/i386.c (working copy)
> @@ -60,6 +60,7 @@ along with GCC; see the file COPYING3.
> #include "fibheap.h"
> #include "opts.h"
> #include "diagnostic.h"
> +#include "cfgloop.h"
>
> enum upper_128bits_state
> {
> @@ -38370,6 +38371,82 @@ ix86_autovectorize_vector_sizes (void)
> return (TARGET_AVX && !TARGET_PREFER_AVX128) ? 32 | 16 : 0;
> }
>
> +/* If LOOP contains a possible LCP stalling instruction on corei7,
> + calculate new number of times to unroll instead of NUNROLL so that
> + the unrolled loop will still likely fit into the loop stream detector. */
> +static unsigned
> +ix86_loop_unroll_adjust (unsigned nunroll, struct loop *loop)
> +{
> + basic_block *body, bb;
> + unsigned i;
> + rtx insn;
> + bool found = false;
> + unsigned newunroll;
> +
> + if (ix86_tune != PROCESSOR_COREI7_64 &&
> + ix86_tune != PROCESSOR_COREI7_32)
> + return nunroll;
> +
> + /* Look for instructions that store a constant into HImode (16-bit)
> + memory. These require a length-changing prefix and on corei7 are
> + prone to LCP stalls. These stalls can be avoided if the loop
> + is streamed from the loop stream detector. */
> + body = get_loop_body (loop);
> + for (i = 0; i < loop->num_nodes; i++)
> + {
> + bb = body[i];
> +
> + FOR_BB_INSNS (bb, insn)
> + {
> + rtx set_expr, dest;
> + set_expr = single_set (insn);
> + if (!set_expr)
> + continue;
> +
> + dest = SET_DEST (set_expr);
> +
> + /* Don't reduce unroll factor in loops with floating point
> + computation, which tend to benefit more heavily from
> + larger unroll factors and are less likely to bottleneck
> + at the decoder. */
> + if (FLOAT_MODE_P (GET_MODE (dest)))
> + {
> + free (body);
> + return nunroll;
> + }
> +
> + if (!found
> + && GET_MODE (dest) == HImode
> + && CONST_INT_P (SET_SRC (set_expr))
> + && MEM_P (dest))
> + {
> + found = true;
> + /* Keep walking loop body to look for FP computations above. */
> + }
> + }
> + }
> + free (body);
> +
> + if (!found)
> + return nunroll;
> +
> + if (dump_file)
> + {
> + fprintf (dump_file,
> + ";; Loop contains HImode store of const (possible LCP
> stalls),\n");
> + fprintf (dump_file,
> + " reduce unroll factor to fit into Loop Stream Detector\n");
> + }
> +
> + /* On corei7 the loop stream detector can hold 28 uops, so
> + don't allow unrolling to exceed that many instructions. */
> + newunroll = 28 / loop->av_ninsns;
> + if (newunroll < nunroll)
> + return newunroll;
> +
> + return nunroll;
> +}
> +
> /* Initialize the GCC target structure. */
> #undef TARGET_RETURN_IN_MEMORY
> #define TARGET_RETURN_IN_MEMORY ix86_return_in_memory
> @@ -38685,6 +38762,9 @@ ix86_autovectorize_vector_sizes (void)
> #define TARGET_INIT_LIBFUNCS darwin_rename_builtins
> #endif
>
> +#undef TARGET_LOOP_UNROLL_ADJUST
> +#define TARGET_LOOP_UNROLL_ADJUST ix86_loop_unroll_adjust
> +
> struct gcc_target targetm = TARGET_INITIALIZER;
>
>
> #include "gt-i386.h"
>
>
> On Fri, Dec 2, 2011 at 12:11 PM, Teresa Johnson wrote:
>> On Fri, Dec 2, 2011 at 11:36 AM, Andi Kleen wrote:
>>> Teresa Johnson writes:
>>>
>>> Interesting optimization. I would be concerned a little bit
>>> about compile time, does it make a measurable difference?
>>
>> I haven't measured compile time explicitly, but I don't it should,
>> especially after I address your efficiency suggestion (see below),
>> since it will just have one pass over the instructions in i
Re: [libgo] PATCH: Handle system call numbers "(0x40000000 | (234))"
On Fri, Dec 9, 2011 at 2:47 PM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> Some my Linux system, system call numbers are defined as
>>
>> #define __NR_x32_rt_sigaction __NR_X32_SYSCALL(0)
>>
>> and
>>
>> __NR_X32_SYSCALL(0) is expanded to (0x4000 | (512 + 0)). This patch
>> tries to deal with by checking '^// unknowndefine SYS_[a-z]' and uses
>> "${CC} -E" to extract the real number. Tested on Linux/x86-64. OK
>> to install?
>
> This patch might be a little simpler. Does it solve the problem?
>
It doesn't work. I didn't define all system call numbers which are mapped to
sys_ni_syscall in kernel. If you use them, you will get a compile
time error since those __NR_ aren't defined. I used
+${CC} -E unknown-syscalls.c | \
+ grep "^const SYS_.*=" | \
+ grep -v __NR_ >> ${OUT}
to filter them out.
--
H.J.
Re: [libgo] PATCH: Handle system call numbers "(0x40000000 | (234))"
"H.J. Lu" writes:
> On Fri, Dec 9, 2011 at 2:47 PM, Ian Lance Taylor wrote:
>> "H.J. Lu" writes:
>>
>>> Some my Linux system, system call numbers are defined as
>>>
>>> #define __NR_x32_rt_sigaction __NR_X32_SYSCALL(0)
>>>
>>> and
>>>
>>> __NR_X32_SYSCALL(0) is expanded to (0x4000 | (512 + 0)). This patch
>>> tries to deal with by checking '^// unknowndefine SYS_[a-z]' and uses
>>> "${CC} -E" to extract the real number. Tested on Linux/x86-64. OK
>>> to install?
>>
>> This patch might be a little simpler. Does it solve the problem?
>>
>
> It doesn't work. I didn't define all system call numbers which are mapped to
> sys_ni_syscall in kernel. If you use them, you will get a compile
> time error since those __NR_ aren't defined. I used
>
> +${CC} -E unknown-syscalls.c | \
> + grep "^const SYS_.*=" | \
> + grep -v __NR_ >> ${OUT}
>
> to filter them out.
Can you send me your relevant syscall.h files?
I'm hoping for something a little more generalizable than your patch,
because we have the same issue for on some systems. It
may not be solvable, but I'd like to try a little harder to see if it
is. Thanks.
Ian
Re: [libgo] PATCH: Handle system call numbers "(0x40000000 | (234))"
On Fri, Dec 9, 2011 at 3:02 PM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> On Fri, Dec 9, 2011 at 2:47 PM, Ian Lance Taylor wrote:
>>> "H.J. Lu" writes:
>>>
Some my Linux system, system call numbers are defined as
#define __NR_x32_rt_sigaction __NR_X32_SYSCALL(0)
and
__NR_X32_SYSCALL(0) is expanded to (0x4000 | (512 + 0)). This patch
tries to deal with by checking '^// unknowndefine SYS_[a-z]' and uses
"${CC} -E" to extract the real number. Tested on Linux/x86-64. OK
to install?
>>>
>>> This patch might be a little simpler. Does it solve the problem?
>>>
>>
>> It doesn't work. I didn't define all system call numbers which are mapped to
>> sys_ni_syscall in kernel. If you use them, you will get a compile
>> time error since those __NR_ aren't defined. I used
>>
>> + ${CC} -E unknown-syscalls.c | \
>> + grep "^const SYS_.*=" | \
>> + grep -v __NR_ >> ${OUT}
>>
>> to filter them out.
>
> Can you send me your relevant syscall.h files?
>
> I'm hoping for something a little more generalizable than your patch,
> because we have the same issue for on some systems. It
> may not be solvable, but I'd like to try a little harder to see if it
> is. Thanks.
>
> Ian
Here it is. For x32, where __x86_64__ is defined and __LP64__ isn't defined,
not all __NR_XXX are defined, like __NR_epoll_ctl_old.
--
H.J.
syscall.tar.bz2
Description: BZip2 compressed data
Re: [Patch] Remove flag_objc-sjlj_exceptions as a User control, move ObjC exception mechanism choices to gcc/objc/
On Wed, 30 Nov 2011, Iain Sandoe wrote: There is really no point in having a flag to control the Objective C (or Objective C++) exceptions [@throw, as opposed to throw] scheme, since we actually only support one scheme for each permutation of runtime and ABI. This removes the flag_objc_sjlj_exceptions (or, more correctly, localizes its effect to the ObjC FEs). Mind documenting this in the GCC 4.7 release notes (wwwdocs/htdocs/gcc-4.7/changes.html)? Gerald
Re: [RFC, PATCH] ARM related deprecations
In message <4ee2285b.3060...@arm.com> Richard Earnshaw wrote: > I think we've reached the point where the following target > configurations should be End-of-Life'd. As such, I'd like to mark them > as deprecated in gcc-4.7, prior to removal after the branch. > > I'd also like to remove at that time support for some now obsolete > co-processor units, namely the FPA and Maverick. Would it really be necessary to remove the FPA support ? Does it hinder any future ARM support in gcc ? The reason for thse questions is that for many years our RISC OS gcc port (currently following the gcc developments on the 4.6 branch and trunk) can make use of hard-float FPA output for one of its multilib flavours (see http://gccsdk.riscos.info/) and I would like to keep on supporting this in gcc 4.8. John. -- John Tytgat, in his comfy chair at home BASS john.tyt...@aaug.net ARM powered, RISC OS driven
Re: [PATCH] Sink clobbers if EH block contains just clobbers (PR tree-optimization/51117)
On 12/09/2011 11:49 AM, Jakub Jelinek wrote: > PR tree-optimization/51117 > * tree-eh.c (sink_clobbers): New function. > (execute_lower_eh_dispatch): Call it for BBs ending with > internally throwing RESX. > * cfgexpand.c (add_scope_conflicts_1): Add SCRATCH argument. > If BB starts with clobbers of vars that aren't mentioned > in any of the PHIs, don't consider the clobbered vars live > on entry of the BB. > (add_scope_conflicts): Allocate and free SCRATCH bitmap > and pass it to add_scope_conflicts_1. Ok by me, assuming Matz or Richi doesn't have a better idea for how to handle the add_scope_conflicts special-casing. r~
Re: [google] Backport r171347 and r181549 from trunk (strict volatile bitfield) (issue5434084)
On Dec 7, 2011, at 5:32 AM, Richard Earnshaw wrote: > So this, to some extent seems to conflict with your rules for only fixing > regressions. This code has always been broken in one way or another, > so technically this doesn't qualify for the 4.6 branch. My take, does this fix improve the quality enough to be work the risk the patch brings... Having bad quality because the quality has been bad in the past, is well, a bad idea.
