Re: [PATCH] Handle GIMPLE_ASSIGNs with different vuse in gimple_equal_p
On Sat, Nov 09, 2013 at 05:30:00PM +0100, Tom de Vries wrote:
>Richard,
>
>Consider the test-case test.c:
>...
>int z;
>int x;
>
>void
>f (int c, int d)
>{
> if (c)
>z = 5;
> else
>{
> if (d)
> x = 4;
> z = 5;
>}
>}
>...
>
>Atm, we don't tail-merge the 'z = 5' blocks, because gimple_equal_p
>returns false for the 'z = 5' statements. The relevant code is this:
>...
> if (TREE_CODE (lhs1) != SSA_NAME
> && TREE_CODE (lhs2) != SSA_NAME)
>return (vn_valueize (gimple_vdef (s1))
>== vn_valueize (gimple_vdef (s2)));
>...
>The vdefs of the 'z = 5' statements are different, because the
>incoming vuses are different.
>
>This patch handles GIMPLE_ASSIGNs with different vuse in
>gimple_equal_p, by doing a structural comparison.
>
>Bootstrapped and regtested on x86_64.
>
>OK for trunk?
>
>Thanks,
>- Tom
>
>2013-11-06 Tom de Vries
>
> * tree-ssa-tail-merge.c (gimple_equal_p): Add test for structural
> equality for GIMPLE_ASSIGN.
>
> * gcc.dg/tail-merge-store.c: New test.
>diff --git a/gcc/testsuite/gcc.dg/tail-merge-store.c
>b/gcc/testsuite/gcc.dg/tail-merge-store.c
>new file mode 100644
>index 000..1aefbdc
>--- /dev/null
>+++ b/gcc/testsuite/gcc.dg/tail-merge-store.c
>@@ -0,0 +1,22 @@
>+/* { dg-do compile } */
>+/* { dg-options "-O2 -ftree-tail-merge -fdump-tree-pre" } */
>+
>+int z;
>+int x;
>+
>+void
>+f (int c, int d)
>+{
>+ if (c)
>+z = 5;
>+ else
>+{
>+ if (d)
>+ x = 4;
>+ z = 5;
>+}
>+}
>+
>+/* { dg-final { scan-tree-dump-times "duplicate of" 1 "pre"} } */
>+/* { dg-final { scan-tree-dump-times "z = 5" 1 "pre"} } */
>+/* { dg-final { cleanup-tree-dump "pre" } } */
>diff --git a/gcc/tree-ssa-tail-merge.c b/gcc/tree-ssa-tail-merge.c
>index 98b5882..43516a7 100644
>--- a/gcc/tree-ssa-tail-merge.c
>+++ b/gcc/tree-ssa-tail-merge.c
>@@ -1173,8 +1173,47 @@ gimple_equal_p (same_succ same_succ, gimple s1, gimple
>s2)
> lhs2 = gimple_get_lhs (s2);
> if (TREE_CODE (lhs1) != SSA_NAME
> && TREE_CODE (lhs2) != SSA_NAME)
>- return (vn_valueize (gimple_vdef (s1))
>- == vn_valueize (gimple_vdef (s2)));
>+ {
>+/* If the vdef is the same, it's the same statement. */
>+if (vn_valueize (gimple_vdef (s1))
>+== vn_valueize (gimple_vdef (s2)))
>+ return true;
>+
>+/* If the vdef is not the same but the vuse is the same, it's not the
>+ same stmt. */
>+if (vn_valueize (gimple_vuse (s1))
>+== vn_valueize (gimple_vuse (s2)))
>+ return false;
>+/* If the vdef is not the same and the vuse is not the same, it might
>be
>+ same stmt. */
>+
>+/* Test for structural equality. */
>+if (gimple_assign_rhs_code (s1) != gimple_assign_rhs_code (s1)
typo, second one should be s2.
thanks,
>+|| (gimple_assign_nontemporal_move_p (s1)
>+!= gimple_assign_nontemporal_move_p (s2)))
>+ return false;
>+
>+if (!operand_equal_p (lhs1, lhs2, 0))
>+ return false;
>+
>+t1 = gimple_assign_rhs1 (s1);
>+t2 = gimple_assign_rhs1 (s2);
>+if (!gimple_operand_equal_value_p (t1, t2))
>+ return false;
>+
>+t1 = gimple_assign_rhs2 (s1);
>+t2 = gimple_assign_rhs2 (s2);
>+if (!gimple_operand_equal_value_p (t1, t2))
>+ return false;
>+
>+t1 = gimple_assign_rhs3 (s1);
>+t2 = gimple_assign_rhs3 (s2);
>+if (!gimple_operand_equal_value_p (t1, t2))
>+ return false;
>+
>+/* Same structure. */
>+return true;
>+ }
> else if (TREE_CODE (lhs1) == SSA_NAME
> && TREE_CODE (lhs2) == SSA_NAME)
> return vn_valueize (lhs1) == vn_valueize (lhs2);
[C++ Patch] Fixes for duplicate warnings regressions [1/2]
Hi,
this is the issue with -Waddress caused by the fix for c++/56930. I'm
handling it as already described, that is by adding a bool parameter to
c_common_truthvalue_conversion.
Tested x86_64-linux.
Thanks!
Paolo.
//
/c-family
2013-11-11 Paolo Carlini
* c-common.c (c_common_truthvalue_conversion): Add bool parameter.
* c-common.h (c_common_truthvalue_conversion): Adjust declaration.
/cp
2013-11-11 Paolo Carlini
* typeck.c (cp_truthvalue_conversion): Add tsubst_flags_t
parameter.
* cp-tree.h (cp_truthvalue_conversion): Adjust declaration.
* cvt.c (cp_convert_and_check): The second time call cp_convert
with tf_none to avoid duplicate -Waddress warnings.
(ocp_convert): Adjust.
* init.c (expand_cleanup_for_base): Likewise.
* rtti.c (build_dynamic_cast_1): Likewise.
/c
2013-11-11 Paolo Carlini
* c-typeck.c (c_objc_common_truthvalue_conversion): Update
c_common_truthvalue_conversion call.
/objc
2013-11-11 Paolo Carlini
* objc-next-runtime-abi-01.c (next_sjlj_build_enter_and_setjmp):
Update c_common_truthvalue_conversion call.
(next_sjlj_build_catch_list): Likewise.
(next_sjlj_build_try_catch_finally): Likewise.
* objc-act.c (objc_finish_foreach_loop): Likewise.
(objc_finish_foreach_loop): Likewise.
Index: c/c-typeck.c
===
--- c/c-typeck.c(revision 204620)
+++ c/c-typeck.c(working copy)
@@ -11001,7 +11001,7 @@ c_objc_common_truthvalue_conversion (location_t lo
else
/* ??? Should we also give an error for vectors rather than leaving
those to give errors later? */
-expr = c_common_truthvalue_conversion (location, expr);
+expr = c_common_truthvalue_conversion (location, expr, /*complain=*/true);
if (TREE_CODE (expr) == INTEGER_CST && int_operands && !int_const)
{
Index: c-family/c-common.c
===
--- c-family/c-common.c (revision 204620)
+++ c-family/c-common.c (working copy)
@@ -4495,7 +4495,8 @@ decl_with_nonnull_addr_p (const_tree expr)
The resulting type should always be `truthvalue_type_node'. */
tree
-c_common_truthvalue_conversion (location_t location, tree expr)
+c_common_truthvalue_conversion (location_t location, tree expr,
+ bool complain)
{
switch (TREE_CODE (expr))
{
@@ -4518,9 +4519,11 @@ tree
return expr;
expr = build2 (TREE_CODE (expr), truthvalue_type_node,
c_common_truthvalue_conversion (location,
-TREE_OPERAND (expr, 0)),
+TREE_OPERAND (expr, 0),
+complain),
c_common_truthvalue_conversion (location,
-TREE_OPERAND (expr, 1)));
+TREE_OPERAND (expr, 1),
+complain));
goto ret;
case TRUTH_NOT_EXPR:
@@ -4528,7 +4531,8 @@ tree
return expr;
expr = build1 (TREE_CODE (expr), truthvalue_type_node,
c_common_truthvalue_conversion (location,
-TREE_OPERAND (expr, 0)));
+TREE_OPERAND (expr, 0),
+complain));
goto ret;
case ERROR_MARK:
@@ -4558,11 +4562,12 @@ tree
tree inner = TREE_OPERAND (expr, 0);
if (decl_with_nonnull_addr_p (inner))
{
- /* Common Ada/Pascal programmer's mistake. */
- warning_at (location,
- OPT_Waddress,
- "the address of %qD will always evaluate as %",
- inner);
+ if (complain)
+ /* Common Ada/Pascal programmer's mistake. */
+ warning_at (location,
+ OPT_Waddress,
+ "the address of %qD will always evaluate as %",
+ inner);
return truthvalue_true_node;
}
break;
@@ -4573,9 +4578,11 @@ tree
(TREE_SIDE_EFFECTS (TREE_OPERAND (expr, 1))
? TRUTH_OR_EXPR : TRUTH_ORIF_EXPR),
c_common_truthvalue_conversion (location,
- TREE_OPERAND (expr, 0)),
+ TREE_OPERAND (expr, 0),
+ complain),
c_common_truthvalue_conversion (location,
- TREE_OPERAND (expr, 1)),
+ TREE
[C++ Patch] Fixes for duplicate warnings regressions [2/2]
Hi,
this is another issue, with -Wzero-as-null-pointer-constant, caused (or,
better, exposed) by the fix for c++/54170: the problem is that
build_ptrmemfunc, called by cp_convert_to_pointer, itself eventually
calls cp_convert_to_pointer.
The build_ptrmemfunc bit isn't essential: using the cp_* variant of
build_c_cast, which takes a tsubst_flags_t, in a function taking a
tsubst_flags_t seems the right thing to do.
Tested x86_64-linux.
Thanks!
Paolo.
//
2013-11-11 Paolo Carlini
* cvt.c (cp_convert_to_pointer): Call build_ptrmemfunc before
maybe_warn_zero_as_null_pointer_constant to avoid duplicate
-Wzero-as-null-pointer-constant diagnostics.
* typeck.c (build_ptrmemfunc): Use cp_build_c_cast.
Index: cp/cvt.c
===
--- cp/cvt.c(revision 204620)
+++ cp/cvt.c(working copy)
@@ -203,13 +203,13 @@ cp_convert_to_pointer (tree type, tree expr, tsubs
if (null_ptr_cst_p (expr))
{
- if (complain & tf_warning)
- maybe_warn_zero_as_null_pointer_constant (expr, loc);
-
if (TYPE_PTRMEMFUNC_P (type))
return build_ptrmemfunc (TYPE_PTRMEMFUNC_FN_TYPE (type), expr, 0,
/*c_cast_p=*/false, complain);
+ if (complain & tf_warning)
+ maybe_warn_zero_as_null_pointer_constant (expr, loc);
+
/* A NULL pointer-to-data-member is represented by -1, not by
zero. */
tree val = (TYPE_PTRDATAMEM_P (type)
Index: cp/typeck.c
===
--- cp/typeck.c (revision 204620)
+++ cp/typeck.c (working copy)
@@ -7779,7 +7781,7 @@ build_ptrmemfunc (tree type, tree pfn, int force,
/* Handle null pointer to member function conversions. */
if (null_ptr_cst_p (pfn))
{
- pfn = build_c_cast (input_location, type, pfn);
+ pfn = cp_build_c_cast (type, pfn, complain);
return build_ptrmemfunc1 (to_type,
integer_zero_node,
pfn);
Re: [C++ PATCH] Refactor implicit function template implementation and fix 58534, 58536, 58548, 58549 and 58637.
On 2013-11-10 6:10, Jason Merrill wrote: Hmm, actually I think messing with the non-pack's decl is dangerous, and we should come up with a new decl for the pack instead. I think you can use reduce_template_parm_level with a "levels" argument of 0 to build a new decl and parm index. I actually did this in one of my experiments and it worked fine. Although I also had to update the template parm list with new decl: TREE_VALUE (TREE_VEC_ELT (current, i)) = TREE_CHAIN (t); At that point I had the convert function in pt.c an operating directly on current_template_parms (also having direct access to the two statics required; reduce_template_parm_level and canonical_type_parameter). I can't think of a case where we'd want to make this substitution in anything but the current_template_parms so maybe moving the convert function back into to pt.c and removing the 'current' parm from it might be best? And if we're doing that, setting TYPE_STUB_DECL and TYPE_NAME is indeed necessary. Only for the sake of not exposing this (currently static) function from pt.c (or moving the pack convert function into pt.c). My original impl did extern canonical_type_parameter and use that and I think it worked as expected. Would that be preferred? Yes. Please declare it in cp-tree.h rather than within the function. Will do. Unless, as suggested above, we go for moving convert_generic_types_to_packs into pt.c in which case exposing these internals won't be necessary. Cheers, Adam
Re: [PATCH 0/6] Conversion of gimple types to C++ inheritance (v3)
Andrew MacLeod writes: > 2 - I really believe gimple needs a type system different from front end > trees, that is my primary motivation. I'm tired of jumping through > hoops to do anything slightly different, and I got fed up with it. With > a separate type system for gimple, we can rid ourselves of all the stuff > that isn't related to optimization and codegen... Could we do this > with trees? possibly, but if I'm going to go to the effort of converting > the front end tree types into a new or reduced-type subset, I might as > well put that effort into something that is more appropriate right from > the start. But what types specifically are you hoping to drop? Would there still be enough information for proper TBAA, for instance? Having two different type representations just sounds like it's going to lead to code duplication for common operations. Plus I'd really not like to see targets have to deal with two different representations of types. Sometimes the things that the target has to do only make sense "at the tree level" (e.g. providing the definition of va_list). Some are on the boundary, such as lowering va_arg into gimple. Some could potentially be used in both places, e.g. the hook to determine the correct alignment for a vector. (I can imagine we'd want to be able to call that at the tree level for user-defined vectors passed to __alignof, say, but also at the gimple level when vectorising.) Others are called during expand, e.g. PROMOTE_MODE. Thanks, Richard
Re: [PATCH, libatomic]: Add config/x86/fenv.c
On Fri, Nov 8, 2013 at 10:32 PM, Joseph S. Myers
wrote:
>> >> Can we introduce a target-dependant source here, in the same way as
>> >
>> > Sure, that seems a reasonable thing to do. I think putting a file fenv.c
>> > in an appropriate subdirectory of libatomic/config will result in it being
>> > found automatically by the existing search path logic, but you'll need to
>> > test that.
>>
>> Attached is the x86 optimized implementation of fenv.c. The source
>> depends as little as possible on fenv.h definitions - these are
>> defined by hardware, and for sure won't change soon in
>> hardware-dependant file.
>
> This is fine with me.
>
>> Bootstrapped and regression tested on x86_64-pc-linux-gnu {,-m32}. The
>> testing of atomics currently fails on 32bit target due to missing
>> __atomic_{load,store}_16 functions, so the patch is not adequately
>> tested yet.
>
> (See for
> commentary on that issue and what might be the right approach for a fix.)
Thanks, this worked for me.
Attached is the x86 specific fenv.c. The source does not depend on
fenv.h anymore and also handles denormal exception.
2013-11-10 Uros Bizjak
* config/x86/fenv.c: New file.
The patch was tested on x86_64-linux-gnu {,-m32} and committed to mainline SVN.
Uros.
Index: ChangeLog
===
--- ChangeLog (revision 204623)
+++ ChangeLog (working copy)
@@ -1,3 +1,7 @@
+2013-11-08 Uros Bizjak
+
+ * config/x86/fenv.c: New file.
+
2013-11-07 Joseph Myers
* fenv.c: New file.
Index: config/x86/fenv.c
===
--- config/x86/fenv.c (revision 0)
+++ config/x86/fenv.c (working copy)
@@ -0,0 +1,116 @@
+/* Copyright (C) 2013 Free Software Foundation, Inc.
+
+ This file is part of the GNU Atomic Library (libatomic).
+
+ Libatomic is free software; you can redistribute it and/or modify it
+ under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 3 of the License, or
+ (at your option) any later version.
+
+ Libatomic is distributed in the hope that it will be useful, but WITHOUT ANY
+ WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
+ FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ more details.
+
+ Under Section 7 of GPL version 3, you are granted additional
+ permissions described in the GCC Runtime Library Exception, version
+ 3.1, as published by the Free Software Foundation.
+
+ You should have received a copy of the GNU General Public License and
+ a copy of the GCC Runtime Library Exception along with this program;
+ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
+
Re: [PATCH] decide edge's hotness when there is profile info
> > + > > + profile_status_for_function (fn) > > + = (flag_guess_branch_prob ? PROFILE_GUESSED : PROFILE_ABSENT); > > + node->frequency > > + = hot ? NODE_FREQUENCY_HOT : NODE_FREQUENCY_NORMAL; > > In GCC code style the = goes at the end of the line: > > profile_status_for_function (fn) > (flag_guess_branch_prob ? PROFILE_GUESSED : PROFILE_ABSENT); > node->frequency = > hot ? NODE_FREQUENCY_HOT : NODE_FREQUENCY_NORMAL; Absolutely not, Teresa's version is the correct one, see reload.c for example. -- Eric Botcazou
Re: [RFA][PATCH] Isolate erroneous paths optimization
> > But I think that you cannot transform
> >
> > foo ()
> > {
> >
> > *0 = 1;
> >
> > }
> >
> > to __builtin_trap as you can catch the trap via an exception handler
> > in a caller of foo, no?
>
> That is true. OK, I can see an argument that when using
> -fnon-call-exceptions that kind of code should not be changed to call
> __builtin_trap.
That's exactly the reason why gnat.dg/memtrap.adb started to fail after Jeff's
patch went it. So, if -fisolate-erroneous-paths isn't amended, we'll need to
disable it in Ada like in Go.
> In that case I think it would be fine to run the isolate paths
> optimization, but to not omit the actual dereference of the NULL
> pointer (possibly the dereference could be followed by a trap).
This would probably work for Ada as well.
--
Eric Botcazou
[patch gcc]: Add executable-extension for exported-symbol-test in configure.ac
Hi,
this patch adds exeext to -rdynamic and exported symbol-check within
configure.ac. By this this test will be preformed as intended on
targets with executable-extensions (nevertheless -rdynamics will still
fail for pe-coff targets).
ChangeLog
2013-11-10 Karlson2k
Kai Tietz
PR plugins/52872
* configure.ac: Adding for exported symbols check
and for rdynamic-check executable-extension.
* configure: Regenerated.
Tested for i686-w64-mingw32, x86_64-w64-mingw32, and i686-pc-cygwin.
I will apply this patch soon, if there are no objections.
Regards,
Kai
Index: configure.ac
===
--- configure.ac(Revision 204461)
+++ configure.ac(Arbeitskopie)
@@ -5334,15 +5334,15 @@
AC_MSG_CHECKING([for exported symbols])
if test "x$export_sym_check" != x; then
echo "int main() {return 0;} int foobar() {return 0;}" > conftest.c
-${CC} ${CFLAGS} ${LDFLAGS} conftest.c -o conftest > /dev/null 2>&1
-if $export_sym_check conftest | grep foobar > /dev/null; then
+${CC} ${CFLAGS} ${LDFLAGS} conftest.c -o conftest$ac_exeext >
/dev/null 2>&1
+if $export_sym_check conftest$ac_exeext | grep foobar > /dev/null; then
: # No need to use a flag
AC_MSG_RESULT([yes])
else
AC_MSG_RESULT([yes])
AC_MSG_CHECKING([for -rdynamic])
- ${CC} ${CFLAGS} ${LDFLAGS} -rdynamic conftest.c -o conftest >
/dev/null 2>&1
- if $export_sym_check conftest | grep foobar > /dev/null; then
+ ${CC} ${CFLAGS} ${LDFLAGS} -rdynamic conftest.c -o
conftest$ac_exeext > /dev/null 2>&1
+ if $export_sym_check conftest$ac_exeext | grep foobar > /dev/null; then
plugin_rdynamic=yes
pluginlibs="-rdynamic"
else
Re: Update soft-fp from glibc
On Fri, Nov 8, 2013 at 10:26 PM, Joseph S. Myers wrote: >> > I've applied this patch to update libgcc's copy of soft-fp from >> > glibc. There are lots of coding standards fixes, but also various bug >> > fixes; I've added testcases for various of the fixed bugs illustrating >> > them for __float128. >> >> Is there really no way to get those "missing prototypes" warning fixed? > > libgcc/config/t-softfp has a setting using -Wno-missing-prototypes - I > don't know offhand why it's not being used. Because this setting is written in the prerequisites section of the makefile rule. OTOH, multiple rules are not allowed, so this setting is totally wrong. Uros.
Re: [PATCH 0/6] Conversion of gimple types to C++ inheritance (v3)
Richard Sandiford wrote: >Andrew MacLeod writes: >> 2 - I really believe gimple needs a type system different from front >end >> trees, that is my primary motivation. I'm tired of jumping through >> hoops to do anything slightly different, and I got fed up with it. >With >> a separate type system for gimple, we can rid ourselves of all the >stuff >> that isn't related to optimization and codegen... Could we do this >> with trees? possibly, but if I'm going to go to the effort of >converting >> the front end tree types into a new or reduced-type subset, I might >as >> well put that effort into something that is more appropriate right >from >> the start. > >But what types specifically are you hoping to drop? Would there still >be enough information for proper TBAA, for instance? > >Having two different type representations just sounds like it's going >to lead to code duplication for common operations. > >Plus I'd really not like to see targets have to deal with two different >representations of types. Sometimes the things that the target >has to do only make sense "at the tree level" (e.g. providing the >definition of va_list). Some are on the boundary, such as lowering >va_arg into gimple. Some could potentially be used in both places, >e.g. the hook to determine the correct alignment for a vector. >(I can imagine we'd want to be able to call that at the tree level for >user-defined vectors passed to __alignof, say, but also at the gimple >level when vectorising.) Others are called during expand, e.g. >PROMOTE_MODE. I can see that a change of the representation of types makes sense to better isolate frontend dependent things. In theory we have lang_type for that but frontend specific things are unfortunately not limited to that. That said, the idea of doing it on our own in gimple isn't the best - rather the existing tree representation should be changed and with it all affected frontends. Even with trees not all things need to remain trees btw, types could get a non-tree structure. But then start at the root of the problem that trees are ubiquitous - remove the remaining tree container structures and its uses. In the past a lot of work has already been done here, but it's not yet complete. Richard. >Thanks, >Richard
Re: [C++ PATCH] Refactor implicit function template implementation and fix 58534, 58536, 58548, 58549 and 58637.
On 2013-11-10 10:38, Adam Butcher wrote:
On 2013-11-10 6:10, Jason Merrill wrote:
Hmm, actually I think messing with the non-pack's decl is dangerous,
and we should come up with a new decl for the pack instead. I think
you can use reduce_template_parm_level with a "levels" argument of 0
to build a new decl and parm index.
I actually did this in one of my experiments and it worked fine.
Although I also had to update the template parm list with new decl:
TREE_VALUE (TREE_VEC_ELT (current, i)) = TREE_CHAIN (t);
At that point I had the convert function in pt.c an operating
directly
on current_template_parms (also having direct access to the two
statics
required; reduce_template_parm_level and canonical_type_parameter).
I can't think of a case where we'd want to make this substitution in
anything but the current_template_parms so maybe moving the convert
function back into to pt.c and removing the 'current' parm from it
might be best?
And if we're doing that, setting TYPE_STUB_DECL and TYPE_NAME is
indeed necessary.
Only for the sake of not exposing this (currently static) function
from
pt.c (or moving the pack convert function into pt.c). My original
impl
did extern canonical_type_parameter and use that and I think it
worked
as expected. Would that be preferred?
Yes. Please declare it in cp-tree.h rather than within the
function.
Will do. Unless, as suggested above, we go for moving
convert_generic_types_to_packs into pt.c in which case exposing these
internals won't be necessary.
With the convert function in pt.c, PATCH 2/3 now looks as follows:
Support implicit parameter packs.
* pt.c (convert_generic_types_to_packs): New function to transform
a range of implicitly introduced non-pack template parms to be parameter
packs.
* cp-tree.h (convert_generic_types_to_packs): Declare.
* parser.c (cp_parser_parameter_declaration_list): If a function
parameter pack contains generic types, convert them to packs prior to
grokdeclarator.
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index fd79adb..e30922a 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -5469,6 +5469,7 @@ extern tree type_uses_auto (tree);
extern tree type_uses_auto_or_concept (tree);
extern void append_type_to_template_for_access_check (tree, tree, tree,
location_t);
+extern tree convert_generic_types_to_packs (tree, int, int);
extern tree splice_late_return_type (tree, tree);
extern bool is_auto(const_tree);
extern bool is_auto_or_concept (const_tree);
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index c48952a..eaad8e4 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -18131,6 +18131,10 @@ cp_parser_parameter_declaration_list (cp_parser* parser, bool *is_error)
cp_parameter_declarator *parameter;
tree decl = error_mark_node;
bool parenthesized_p = false;
+ int template_parm_idx = (parser->num_template_parameter_lists?
+ TREE_VEC_LENGTH (INNERMOST_TEMPLATE_PARMS
+ (current_template_parms)) : 0);
+
/* Parse the parameter. */
parameter
= cp_parser_parameter_declaration (parser,
@@ -18142,11 +18146,29 @@ cp_parser_parameter_declaration_list (cp_parser* parser, bool *is_error)
deprecated_state = DEPRECATED_SUPPRESS;
if (parameter)
+ {
+ /* If a function parameter pack was specified and an implicit template
+ parameter was introduced during cp_parser_parameter_declaration,
+ change any implicit parameters introduced into packs. */
+ if (parser->implicit_template_parms
+ && parameter->declarator
+ && parameter->declarator->parameter_pack_p)
+ {
+ int latest_template_parm_idx = TREE_VEC_LENGTH
+ (INNERMOST_TEMPLATE_PARMS (current_template_parms));
+
+ if (latest_template_parm_idx != template_parm_idx)
+ parameter->decl_specifiers.type = convert_generic_types_to_packs
+ (parameter->decl_specifiers.type,
+ template_parm_idx, latest_template_parm_idx);
+ }
+
decl = grokdeclarator (parameter->declarator,
¶meter->decl_specifiers,
PARM,
parameter->default_argument != NULL_TREE,
¶meter->decl_specifiers.attributes);
+ }
deprecated_state = DEPRECATED_NORMAL;
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 8c1553f..360d8a3 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -21629,6 +21629,56 @@ append_type_to_template_for_access_check (tree templ,
scope, location);
}
+/* Convert the generic type parameters in PARM that match the types given in the
+ range [START_IDX, END_IDX) from the current_template_parms into generic type
+ packs. */
+
+tree
+convert_generic_types_to_packs (tree parm, int start_idx, int end_idx)
+{
+ tree current = current_template_parms;
+ int depth = TMPL_PARMS_DEPTH (current);
+ current = INNERMOST_TEMPLATE_PARMS (current);
+ tree replacement = make_tree_vec (TREE_VEC_LENGTH (current));
+
+ for (int i = start_idx; i < end_idx; ++i)
+{
+
Re: [patch][RFC] make lra.c:check_rtl set maybe_hot_insn_p
Steven Bosscher wrote: >Hello, > >This patch is necessary to make ARM pass the test suite with LRA >enabled. The symptom is recog failing to recognize a store_minmaxsi >insn, see: > http://gcc.gnu.org/ml/gcc-patches/2013-11/msg00725.html > >But I am not sure if that's also the root cause of the problem, or >whether the ARM back end should not let recognition of insn patterns >be dependent on the state of the profile flags. > >The pattern for store_minmaxsi (in arm.md) is: > >(define_insn "*store_minmaxsi" > [(set (match_operand:SI 0 "memory_operand" "=m") >(match_operator:SI 3 "minmax_operator" > [(match_operand:SI 1 "s_register_operand" "r") > (match_operand:SI 2 "s_register_operand" "r")])) > (clobber (reg:CC CC_REGNUM))] > "TARGET_32BIT && optimize_insn_for_size_p()" > "* > operands[3] = gen_rtx_fmt_ee (minmax_code (operands[3]), SImode, >operands[1], operands[2]); > output_asm_insn (\"cmp\\t%1, %2\", operands); > if (TARGET_THUMB2) >output_asm_insn (\"ite\t%d3\", operands); > output_asm_insn (\"str%d3\\t%1, %0\", operands); > output_asm_insn (\"str%D3\\t%2, %0\", operands); > return \"\"; > " > [(set_attr "conds" "clob") > (set (attr "length") >(if_then_else (eq_attr "is_thumb" "yes") > (const_int 14) > (const_int 12))) > (set_attr "type" "store1")] >) > > >Note the insn condition uses optimize_insn_for_size_p(). This means >the pattern can be valid or invalid dependent on the context where the >insn appears: in hot or cold code. IMHO this behavior should not be >allowed. The back end cannot expect the middle end to know at all >times the context that the insn appears in, and more importantly >whether a pattern is valid or not is independent of where the insn >appears: That is a *cost* issue! > >It seems to me that the ARM back end should be fixed here, not LRA's >check_rtl. > >Comments&thoughts? The intent is to allow this also to control combine and split, but certainly making insns invalid after the fact is bad. think of sinking a previously hot insn into a cold path... Honza, how was this supposed to work? Richard. >Ciao! >Steven
[RFC] replace malloc with a decl on the stack
Hello,
I am posting this patch to get some feedback on the approach. The goal is
to replace malloc+free with a stack allocation (a decl actually) when the
size is a small constant.
For testing, I highjacked the "leaf" attribute, but it isn't right, I'll
remove it from the list (not sure what I'll do for the testcases then).
What I'd want instead is a "returns" attribute that means the function
will return (either by "return" or an exception), as opposed to having an
infinite loop, calling exit or longjmp, etc (sched-deps.c has a related
call_may_noreturn_p). The situation I am trying to avoid is:
p=malloc(12);
f(p)
free(p)
where f contains somewhere:
free(p); exit(42);
(or longjmp or something else that takes the regular call to free out of
the execution flow).
It passes most of the testsuite, but breaks a couple __builtin_object_size
tests:
struct A
{
char a[10];
int b;
char c[10];
};
int main(){
struct A *p = malloc (2 * sizeof (struct A));
assert (__builtin_object_size (&p->a, 1) == sizeof (p->a));
free (p);
}
__builtin_object_size now returns 56 instead of 10. I am not sure what to
do about that.
The size above which the malloc->stack transformation is not applied
should depend on a parameter, I don't know if it should get its own or
depend on an existing one. In any case, I'd like to avoid ending up with a
ridiculously low threshold (my programs use GMP, which internally uses
alloca up to 65536 bytes (even in recursive functions that have a dozen
allocations), so I don't want gcc to tell me that 50 bytes are too much).
A program with a double-free may, with this patch, end up crashing on the
first free instead of the second, but that's an invalid program anyway.
I don't know if tree-ssa-forwprop is a good place for it, but it was
convenient for a prototype. I like the idea of running it several times:
replacing malloc with a decl early can help other optimizations, and other
optimizations can make this one possible later.
The walk could be a bit expensive, but we only do it if we detected a
malloc of a small constant and at least one matching free. I guess I
should mark the malloc somehow to avoid performing the walk twice if there
are several (but not enough) matching free.
stack_vec is nice, it would be convenient if bitmaps also had a version
with a destructor so we don't need to explicitly deallocate them.
--
Marc GlisseIndex: gcc/testsuite/g++.dg/tree-ssa/heapstack-1.C
===
--- gcc/testsuite/g++.dg/tree-ssa/heapstack-1.C (revision 0)
+++ gcc/testsuite/g++.dg/tree-ssa/heapstack-1.C (working copy)
@@ -0,0 +1,24 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-optimized" } */
+
+struct A {
+ void*p;
+ A(void*q) : p(q) {}
+ ~A(){ __builtin_free(p); }
+};
+void f(void*)__attribute__((__leaf__));
+void h(void*)__attribute__((__leaf__,__nothrow__));
+void g(){
+ void*p=__builtin_malloc(12);
+ A a(p);
+ f(p);
+}
+
+void i(){
+ void*p=__builtin_malloc(12);
+ h(p);
+ __builtin_free(p);
+}
+
+/* { dg-final { scan-tree-dump-not "malloc" "optimized" } } */
+/* { dg-final { cleanup-tree-dump "optimized" } } */
Property changes on: gcc/testsuite/g++.dg/tree-ssa/heapstack-1.C
___
Added: svn:keywords
## -0,0 +1 ##
+Author Date Id Revision URL
\ No newline at end of property
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Index: gcc/testsuite/g++.dg/tree-ssa/heapstack-2.C
===
--- gcc/testsuite/g++.dg/tree-ssa/heapstack-2.C (revision 0)
+++ gcc/testsuite/g++.dg/tree-ssa/heapstack-2.C (working copy)
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-optimized" } */
+
+void f(void*)__attribute__((__leaf__));
+void g(){
+ void*p=__builtin_malloc(12);
+ f(p);
+ __builtin_free(p);
+}
+
+/* { dg-final { scan-tree-dump-times "malloc" 1 "optimized" } } */
+/* { dg-final { cleanup-tree-dump "optimized" } } */
Property changes on: gcc/testsuite/g++.dg/tree-ssa/heapstack-2.C
___
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Added: svn:keywords
## -0,0 +1 ##
+Author Date Id Revision URL
\ No newline at end of property
Index: gcc/testsuite/gcc.dg/tree-ssa/heapstack-1.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/heapstack-1.c (revision 0)
+++ gcc/testsuite/gcc.dg/tree-ssa/heapstack-1.c (working copy)
@@ -0,0 +1,22 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-optimized" } */
+
+void f(void*)__attribute__((__leaf__));
+void g(int m,int n){
+ int i;
+ void*p=__builtin_malloc(12);
+ switch(n){
+case 1:
+ for (i=0; i *list_of_frees)
+{
+ tree var = gimple_call_lhs (stmt);
+ basic_block bb = gimple_bb (stmt);
+ stack_vec bb_to_vi
[PATCH, i386] Fix -mpreferred-stack-boundary
Currently on trunk the option -mpreferred-stack-boundary does not work
together with #pragma GCC target("sse") or __attribute__((target("sse"))).
There is already a test case that detects this:
gcc.target/i386/fastcall-sseregparm.c
The attached patch fixes this test case under i686-pc-linux-gnu.
Boot-strapped and regression-tested under i686-pc-linux-gnu.
OK for trunk?
Regards
Bernd.2013-11-10 Bernd Edlinger
PR target/58964
* config/i386/i386.c (ix86_valid_target_attribute_p): Set
func_options.x_ix86_preferred_stack_boundary_arg.
patch-pr58964.diff
Description: Binary data
PATCH: other/59039: Undocumented __builtin_longjmp/__builtin_setjmp
Hi,
This patch documents __builtin_setjmp and __builtin_longjmp. OK to
install?
Thanks.
H.J.
---
2013-11-10 H.J. Lu
PR other/59039
* doc/extend.texi: Document __builtin_setjmp and
__builtin_longjmp.
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 0d72819..44b7c59 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -27,6 +27,7 @@ extensions, accepted by GCC in C90 mode and in C++.
* Local Labels::Labels local to a block.
* Labels as Values::Getting pointers to labels, and computed gotos.
* Nested Functions::As in Algol and Pascal, lexical scoping of functions.
+* Nonlocal Gotos:: Nonlocal gotos
* Constructing Calls:: Dispatching a call to another function.
* Typeof:: @code{typeof}: referring to the type of an expression.
* Conditionals::Omitting the middle operand of a @samp{?:} expression.
@@ -518,6 +519,36 @@ bar (int *array, int offset, int size)
@}
@end smallexample
+@node Nonlocal Gotos
+@section Nonlocal Gotos
+@cindex nonlocal gotos
+
+GCC provides builtin functions @code{__builtin_setjmp} and
+@code{__builtin_longjmp} which operate similarly to the C library
+functions of the same name, but are more efficient.
+
+@deftypefn {Built-in Function} {int} __builtin_setjmp (intptr_t *@var{buf})
+This function saves the current stack context in @code{setjmp} buffer,
+@var{buf}. @code{__builtin_setjmp} returns 0 when returning directly,
+and @var{1} when returning from @code{__builtin_longjmp} using the same
+@code{setjmp} buffer.
+@end deftypefn
+
+@deftypefn {Built-in Function} {void} __builtin_longjmp (intptr_t *@var{buf},
int @var{val})
+This function restores the stack context in @code{setjmp} buffer,
+@var{buf}, saved by the last call of @code{__builtin_setjmp}. After
+@code{__builtin_longjmp} is finished, program resumes execution as
+if the last @code{__builtin_setjmp} just returns the value @var{val},
+which must be @var{1}.
+@end deftypefn
+
+The @code{setjmp} buffer is an array of five @code{intptr_t}. The buffer
+will generally contain the frame address, the resume address and the stack
+address. The other elements may be used in a machine-specific way.
+
+@code{__builtin_setjmp} and @code{__builtin_longjmp} may not be used
+in the same function with the same @code{setjmp} buffer.
+
@node Constructing Calls
@section Constructing Function Calls
@cindex constructing calls
Re: [PATCH] decide edge's hotness when there is profile info
On Sun, Nov 10, 2013 at 1:08 PM, Eric Botcazou wrote:
>> > +
>> > + profile_status_for_function (fn)
>> > + = (flag_guess_branch_prob ? PROFILE_GUESSED : PROFILE_ABSENT);
>> > + node->frequency
>> > + = hot ? NODE_FREQUENCY_HOT : NODE_FREQUENCY_NORMAL;
>>
>> In GCC code style the = goes at the end of the line:
>>
>> profile_status_for_function (fn)
>> (flag_guess_branch_prob ? PROFILE_GUESSED : PROFILE_ABSENT);
>> node->frequency =
>> hot ? NODE_FREQUENCY_HOT : NODE_FREQUENCY_NORMAL;
>
> Absolutely not, Teresa's version is the correct one, see reload.c for example.
Hmm, "absolutely"?
[stevenb@gcc1-power7 trunk]$ egrep -ch "^\s+= " gcc/*.[ch] | awk
'{sum=sum+$1}END{print sum}'
1797
[stevenb@gcc1-power7 trunk]$ egrep -ch "\s=$" gcc/*.[ch] | awk
'{sum=sum+$1}END{print sum}'
685
I can't find a rule/guide in the GNU or GCC coding style documents.
Anyway, not important. The "=" starting a new line is the majority, so
Theresa please forget about my comment :-)
Ciao!
Steven
Re: [PATCH, rtl]: Mode-switching: Mark block as nontransparent if its exiting mode != no_mode
> Attached patch fixes an oversight in mode-switching. For blocks
> without ANY mode requirements, we have to consider instructions with
> MODE_AFTER mode changes. If the exiting mode from the block is
> different that no_mode (the mode we start), we have to mark the block
> as nontransparent.
>
> 2013-11-08 Uros Bizjak
>
> * mode-switching.c (optimize_mode_switching): Mark block as
> nontransparent, if last_mode at block exit is different from no_mode.
>
> Bootstrapped and regression tested on x86_64-pc-linux-gnu {,-m32}
> core-avx-i configured bootstrap.
>
> OK for mainline and branches?
OK for mainline and 4.8 branch, if you complete the comment just above, for
example "from no_mode, in which case we need to..."
--
Eric Botcazou
Re: some prep work to make JUMP_TABLE_DATA a non-active_insn_p object
> This is the first patch of what I think will be four to fix those few > places. > > Bootstrapped&tested on powerpc64-unknown-linux-gnu. Also built SH to be > sure. > > OK for trunk? The generic part is OK (modulo the additional space after ! in the 3rd hunk of the haifa-sched.c patch). -- Eric Botcazou
Re: [Patch, libgfortran] Set close-on-exec flag when opening files
Janne Blomqvist wrote: the attached patch sets the close-on-exec flag when opening files, as is usually considered good practice these days. See e.g. http://www.python.org/dev/peps/pep-0446/ and links therein for more information. + int flags = O_RDWR|O_CREAT|O_EXCL; I'd add spaces around "|". Otherwise, it looks good to me. Thanks for the patch and sorry for the slow review. Tobias
Improve diagnostics for invalid std::allocator specializations
For PR libstdc++/55963 I said I'd improve the diagnostics when you try
to use std::vector, which is invalid because the C++
Allocator requirements require the value_type to be a non-const object
type.
I tried adding static assertions to the primary std::allocator
template, but the diagnostics are still not very clear, because const
types cause ambiguous overloads and reference types cause invalid
pointer-to-reference types to be formed.
This patch adds std::allocator and std::allocator partial
specializations instead, which inherit from std::allocator so they
can be used in limited ways (most importantly, you can rebind them to
a valid specialization) but attempting to construct such an allocator
will fail with a helpful message in C++11 mode (and just fail due to
using a private constructor in C++03 mode.)
The change passes testing, but I haven't committed yet as I'd like to
hear other opinions on the approach, or if this is even worth doing at
all. I think the better diagnostics are helpful, e.g. with this patch
instantiating std::vector gives the following, rather than
33 far more cryptic lines:
In file included from /home/jwakely/gcc/4.x/include/c++/4.9.0/vector:61:0,
from a.cc:1:
/home/jwakely/gcc/4.x/include/c++/4.9.0/bits/allocator.h: In
instantiation of ‘std::allocator::allocator() [with _Tp =
int]’:
a.cc:5:26: required from here
/home/jwakely/gcc/4.x/include/c++/4.9.0/bits/allocator.h:134:2: error:
static assertion failed: allocator's value_type must be non-const
static_assert( !is_const::value,
^
commit b63fee8ad1f7ee67dd68954272f73e02d3fa6e70
Author: Jonathan Wakely
Date: Sat Nov 9 13:23:46 2013 +
PR libstdc++/55963
* include/bits/allocator.h (allocator, allocator<_Tp&>):
Add partial specializations to improve diagnostics for invalid uses.
* testsuite/20_util/allocator/55963.cc: New.
diff --git a/libstdc++-v3/include/bits/allocator.h
b/libstdc++-v3/include/bits/allocator.h
index c72859b..451c3be 100644
--- a/libstdc++-v3/include/bits/allocator.h
+++ b/libstdc++-v3/include/bits/allocator.h
@@ -123,6 +123,40 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
// Inherit everything else.
};
+ /// Partial specialization for const types
+ template
+class allocator : public allocator<_Tp>
+{
+#if __cplusplus >= 201103L
+public:
+ allocator()
+ {
+ static_assert( !is_const::value,
+ "allocator's value_type must be non-const" );
+ }
+#else
+private:
+ allocator();
+#endif
+};
+
+ /// Partial specialization for reference types
+ template
+class allocator<_Tp&> : public allocator<_Tp>
+{
+#if __cplusplus >= 201103L
+public:
+ allocator()
+ {
+ static_assert( is_object<_Tp&>::value,
+ "allocator's value_type must be an object type" );
+ }
+#else
+private:
+ allocator();
+#endif
+};
+
template
inline bool
operator==(const allocator<_T1>&, const allocator<_T2>&)
diff --git a/libstdc++-v3/testsuite/20_util/allocator/55963.cc
b/libstdc++-v3/testsuite/20_util/allocator/55963.cc
new file mode 100644
index 000..66f5472
--- /dev/null
+++ b/libstdc++-v3/testsuite/20_util/allocator/55963.cc
@@ -0,0 +1,27 @@
+// Copyright (C) 2013 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library. This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3. If not see
+//
Re: [PATCH, rtl]: Mode-switching: Mark block as nontransparent if its exiting mode != no_mode
On Sun, Nov 10, 2013 at 5:45 PM, Eric Botcazou wrote:
>> Attached patch fixes an oversight in mode-switching. For blocks
>> without ANY mode requirements, we have to consider instructions with
>> MODE_AFTER mode changes. If the exiting mode from the block is
>> different that no_mode (the mode we start), we have to mark the block
>> as nontransparent.
>>
>> 2013-11-08 Uros Bizjak
>>
>> * mode-switching.c (optimize_mode_switching): Mark block as
>> nontransparent, if last_mode at block exit is different from no_mode.
>>
>> Bootstrapped and regression tested on x86_64-pc-linux-gnu {,-m32}
>> core-avx-i configured bootstrap.
>>
>> OK for mainline and branches?
>
> OK for mainline and 4.8 branch, if you complete the comment just above, for
> example "from no_mode, in which case we need to..."
Thanks, I have committed attached patch. I will wait a couple of days
to see if the patch causes any problems with other mode-switching
targets before backporting it to 4.8.
Uros.
Re: [PATCH, rtl]: Mode-switching: Mark block as nontransparent if its exiting mode != no_mode
On Sun, Nov 10, 2013 at 7:40 PM, Uros Bizjak wrote:
> On Sun, Nov 10, 2013 at 5:45 PM, Eric Botcazou wrote:
>>> Attached patch fixes an oversight in mode-switching. For blocks
>>> without ANY mode requirements, we have to consider instructions with
>>> MODE_AFTER mode changes. If the exiting mode from the block is
>>> different that no_mode (the mode we start), we have to mark the block
>>> as nontransparent.
>>>
>>> 2013-11-08 Uros Bizjak
>>>
>>> * mode-switching.c (optimize_mode_switching): Mark block as
>>> nontransparent, if last_mode at block exit is different from no_mode.
>>>
>>> Bootstrapped and regression tested on x86_64-pc-linux-gnu {,-m32}
>>> core-avx-i configured bootstrap.
>>>
>>> OK for mainline and branches?
>>
>> OK for mainline and 4.8 branch, if you complete the comment just above, for
>> example "from no_mode, in which case we need to..."
>
> Thanks, I have committed attached patch. I will wait a couple of days
> to see if the patch causes any problems with other mode-switching
> targets before backporting it to 4.8.
Well, now with the patch.
Uros.
Index: ChangeLog
===
--- ChangeLog (revision 204648)
+++ ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2013-11-10 Uros Bizjak
+
+ * mode-switching.c (optimize_mode_switching): Mark block as
+ nontransparent, if last_mode at block exit is different from no_mode.
+
2013-11-09 Jan-Benedict Glaw
* function.c (NAME__MAIN): Move to...
@@ -90,8 +95,7 @@
2013-11-08 Richard Biener
PR tree-optimization/59047
- * tree-predcom.c (ref_at_iteration): Handle bitfield accesses
- properly.
+ * tree-predcom.c (ref_at_iteration): Handle bitfield accesses properly.
2013-11-08 Ilya Enkovich
@@ -124,8 +128,7 @@
(TYPE_QUALS, TYPE_QUALS_NO_ADDR_SPACE): Add TYPE_QUAL_ATOMIC.
(TYPE_QUALS_NO_ADDR_SPACE_NO_ATOMIC): New macro.
(atomicQI_type_node, atomicHI_type_node, atomicSI_type_node)
- (atomicDI_type_node, atomicTI_type_node): New macros for type
- nodes.
+ (atomicDI_type_node, atomicTI_type_node): New macros for type nodes.
* tree.c (set_type_quals): Set TYPE_ATOMIC.
(find_atomic_core_type): New function.
(build_qualified_type): Adjust alignment for qualified types.
@@ -134,23 +137,20 @@
atomicHI_type_node, atomicSI_type_node, atomicDI_type_node and
atomicTI_type_node.
* print-tree.c (print_node): Print atomic qualifier.
- * tree-pretty-print.c (dump_generic_node): Print atomic type
- attribute.
+ * tree-pretty-print.c (dump_generic_node): Print atomic type attribute.
* target.def (atomic_assign_expand_fenv): New hook.
* doc/tm.texi.in (TARGET_ATOMIC_ASSIGN_EXPAND_FENV): New @hook.
* doc/tm.texi: Regenerate.
* targhooks.c (default_atomic_assign_expand_fenv): New function.
* targhooks.h (default_atomic_assign_expand_fenv): Declare.
- * sync-builtins.def (__atomic_feraiseexcept): New built-in
- function.
+ * sync-builtins.def (__atomic_feraiseexcept): New built-in function.
* config/i386/i386-builtin-types.def (VOID_FTYPE_PUSHORT): New
function type.
* config/i386/i386.c (enum ix86_builtins): Add
IX86_BUILTIN_FNSTENV, IX86_BUILTIN_FLDENV, IX86_BUILTIN_FNSTSW and
IX86_BUILTIN_FNCLEX.
(bdesc_special_args): Add __builtin_ia32_fnstenv,
- __builtin_ia32_fldenv, __builtin_ia32_fnstsw and
- __builtin_ia32_fnclex.
+ __builtin_ia32_fldenv, __builtin_ia32_fnstsw and __builtin_ia32_fnclex.
(ix86_expand_builtin): Handle the new built-in functions.
(ix86_atomic_assign_expand_fenv): New function.
(TARGET_ATOMIC_ASSIGN_EXPAND_FENV): New macro.
@@ -183,8 +183,7 @@
* tree-ssa-loop-im.c
(move_computations_dom_walker::before_dom_children): Same.
* tree-ssa-loop-manip.c (rewrite_phi_with_iv): Same.
- * tree-ssa-pre.c (eliminate_dom_walker::before_dom_children):
- Same.
+ * tree-ssa-pre.c (eliminate_dom_walker::before_dom_children): Same.
* tree-ssa-propagate.c (substitute_and_fold): Same.
* tree-vect-loop.c (vect_finalize_reduction): Same.
* tree-vect-stmts.c (vectorizable_call): Same.
@@ -218,15 +217,13 @@
* doc/invoke.texi (-fisolate-erroneous-paths): Document.
* gimple-ssa-isolate-paths.c (gate_isolate_erroneous_paths):
- No longer check if we have __builtin_trap, assume it's
- available.
+ No longer check if we have __builtin_trap, assume it's available.
2013-11-07 Diego Novillo
* attribs.c (lookup_scoped_attribute_spec): Make static.
(get_attribute_namespace): Likewise.
- * builtins.c (more_const_call_expr_args_p): Move from
- tree.h.
+ * builtins.c (more_const_call_expr_args_p): Move from tree.h.
(validate_arglist): Move earlier in the
Re: [patch gcc]: Add executable-extension for exported-symbol-test in configure.ac
On 10 November 2013 13:49:37 Kai Tietz wrote:
Hi,
this patch adds exeext to -rdynamic and exported symbol-check within
configure.ac. By this this test will be preformed as intended on
targets with executable-extensions (nevertheless -rdynamics will still
fail for pe-coff targets).
ChangeLog
2013-11-10 Karlson2k
Kai Tietz
PR plugins/52872
* configure.ac: Adding for exported symbols check
and for rdynamic-check executable-extension.
* configure: Regenerated.
Tested for i686-w64-mingw32, x86_64-w64-mingw32, and i686-pc-cygwin.
I will apply this patch soon, if there are no objections.
Regards,
Kai
Index: configure.ac
===
--- configure.ac(Revision 204461)
+++ configure.ac(Arbeitskopie)
@@ -5334,15 +5334,15 @@
AC_MSG_CHECKING([for exported symbols])
if test "x$export_sym_check" != x; then
echo "int main() {return 0;} int foobar() {return 0;}" > conftest.c
-${CC} ${CFLAGS} ${LDFLAGS} conftest.c -o conftest > /dev/null 2>&1
-if $export_sym_check conftest | grep foobar > /dev/null; then
+${CC} ${CFLAGS} ${LDFLAGS} conftest.c -o conftest$ac_exeext >
/dev/null 2>&1
+if $export_sym_check conftest$ac_exeext | grep foobar > /dev/null; then
grep -q
: # No need to use a flag
AC_MSG_RESULT([yes])
else
AC_MSG_RESULT([yes])
AC_MSG_CHECKING([for -rdynamic])
- ${CC} ${CFLAGS} ${LDFLAGS} -rdynamic conftest.c -o conftest >
/dev/null 2>&1
- if $export_sym_check conftest | grep foobar > /dev/null; then
+ ${CC} ${CFLAGS} ${LDFLAGS} -rdynamic conftest.c -o
conftest$ac_exeext > /dev/null 2>&1
+ if $export_sym_check conftest$ac_exeext | grep foobar > /dev/null; then
Ditto.
Thanks,
plugin_rdynamic=yes
pluginlibs="-rdynamic"
else
Sent with AquaMail for Android
http://www.aqua-mail.com
Re: [C++ PATCH] Refactor implicit function template implementation and fix 58534, 58536, 58548, 58549 and 58637.
On 11/10/2013 08:10 AM, Adam Butcher wrote: With the convert function in pt.c, PATCH 2/3 now looks as follows: I like this direction. + /* Build up a tree vec of empty tree vecs up to the inner substitution +args built above. */ I think we want to copy the enclosing args; see existing uses of add_outermost_template_args. Jason
Re: [C++ Patch] Fixes for duplicate warnings regressions [2/2]
OK. Jason
Re: [C++ PATCH] Refactor implicit function template implementation and fix 58534, 58536, 58548, 58549 and 58637.
On 2013-11-10 18:49, Jason Merrill wrote: On 11/10/2013 08:10 AM, Adam Butcher wrote: + /* Build up a tree vec of empty tree vecs up to the inner substitution +args built above. */ I think we want to copy the enclosing args; see existing uses of add_outermost_template_args. OK. I had that originally but I was concerned that it was wasteful which is why I ended up using nullptrs for non-subst'd types in the inner level and empty tree vecs for the prior levels. It seemed to work as expected; I assumed that tsubst simply doesn't do anything with a null tree substitution (i.e. it is an identity op). There will be an additional, seemingly unnecessary, cost of copying these and the loop above will presumably be required to set the non-subst'd types rather than leave them as nullptr also. Since we are tsubsting the declaration here and we only want to adjust the template parameter types themselves at their declaration is this really necessary? I've no problem with implementing this if it truly is necessary but I don't want to add unnecessary cycles if not. One other thing, by 'copy' I take it you mean copy the tree vecs of the enclosing levels only, not also the types within them. And I also assume that I'll need to set the currently unset types in the inner level also? Cheers Adam
Re: OpenBSD cilkrts portability patch
John Carr writes: > I am trying to build the trunk version of gcc to have Cilk on OpenBSD. > > I attach three changes to libcilkrts. Two changes treat OpenBSD like > FreeBSD. One change is needed because OpenBSD defines PTHREAD_MUTEX_* as > enumerations rather than preprocessor constants. That doesn't seem to be the autoconf'esque way to do this: better would be to have a configure check for this somewhere and then test the results. -Andi -- a...@linux.intel.com -- Speaking for myself only
Re: [Patch, RTL] Eliminate redundant vec_select moves.
Tejas Belagod writes: >> The problem is that one reg rtx can span several hard registers. >> E.g. (reg:V4SI 32) might represent one 64-bit register (no. 32), >> but it might instead represent two 32-bit registers (nos. 32 and 33). >> Obviously the latter's not very likely for vectors this small, >> but more likely for larger ones (including on NEON IIRC). >> >> So if we had 2 32-bit registers being treated as a V4HI, it would be: >> >><--32--><--33--> >>msb lsb >> >> >> >>msb lsb >><--32--> >> >> for big endian and: >> >><--33--><--32--> >>msb lsb >> >> >> >>msb lsb >><--32--> >> >> for little endian. > > Ah, ok, that makes things clearer. Thanks for that. > > I can't find any helper function that figures out if we're writing partial or > full result regs. Would something like > > REGNO (src) == REGNO (dst) && > HARD_REGNO_NREGS (src) == HARD_REGNO_NREGS (dst) == 1 > > be a sane check for partial result regs? Yeah, that should work. I think a more general alternative would be: simplify_subreg_regno (REGNO (src), GET_MODE (src), offset, GET_MODE (dst)) == (int) REGNO (dst) where: offset = GET_MODE_UNIT_SIZE (GET_MODE (src)) * INTVAL (XVECEXP (sel, 0)) That offset is the byte offset of the first selected element from the start of a vector in memory, which is also the way that SUBREG_BYTEs are counted. For little-endian it gives the offset of the lsb of the slice, while for big-endian it gives the offset of the msb (which is also how SUBREG_BYTEs work). The simplify_subreg_regno should cope with both single-register vectors and multi-register vectors. Thanks, Richard
Re: [wwwdocs] [C++14] Library and front-end additions
On 11/10/2013 11:54 AM, Jonathan Wakely wrote: On 10 November 2013 16:52, Jonathan Wakely wrote: I thought I'd already made similar changes to gcc-4.9/changes.html for the C++14 changes but I never committed it. The only comment I have is that "chrono" isn't a type, but the change is fine as far as I'm concerned, thanks. Oh, and optional isn't part of C++14. Right. i guess there are interesting conversations to be had about how we document and flag all these TSs and constraints... Here's what I had, although it doesn't mention all the changes: Index: changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.9/changes.html,v retrieving revision 1.31 diff -u -r1.31 changes.html --- changes.html31 Oct 2013 18:03:28 - 1.31 +++ changes.html10 Nov 2013 16:53:19 - @@ -142,8 +142,20 @@ http://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2011";> - Improved support for C++11, including support for. + Improved support for C++11, including support for . +Experimental support for most C++1y library features, including: + +User-defined literals for strings, durations and complex numbers. +Additional overloads for std::equal, std::mismatch +and std::is_permutation. +std::make_unique +std::quoted +std::shared_lock +std::integer_sequence + + +An implementation of std::experimental::optional. The non-standard function std::copy_exception has been deprecated and will be removed in a future version. std::make_exception_ptr should be used instead. OK, I folded our versions together. Thank you. I also fixed up my code examples. OK? Ed Index: htdocs/projects/cxx1y.html === RCS file: /cvs/gcc/wwwdocs/htdocs/projects/cxx1y.html,v retrieving revision 1.8 diff -r1.8 cxx1y.html 113,114c113,115 < http://isocpp.org/files/papers/n3760.htm";>N3760 < No --- >href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3760.html";>N3760 > > 4.9 (N3797) 118,119c119,121 < http://isocpp.org/files/papers/N3781.pdf";>N3781 < No --- >href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3781.pdf";>N3781 > > 4.9 (N3797) Index: htdocs/gcc-4.9/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.9/changes.html,v retrieving revision 1.32 diff -r1.32 changes.html 150a151,183 > > G++ supports the C++1y [[deprecated]] > attribute modulo bugs in the underying [[gnu::deprecated]] attribute. > Classes > and functions can be marked deprecated and > > class A; > int bar(int n); > #if __cplusplus > 201103 > class [[deprecated("A is deprecated in C++14; Use B instead")]] A; > [[deprecated("bar is unsafe; use foo() instead")]] > int bar(int n); > > int foo(int n); > class B; > #endif > A aa; // warning: 'A' is deprecated : A is deprecated in C++14; Use B instead > int j = bar(2); // warning: 'int bar(int)' is deprecated : bar is unsafe; use > foo() instead > > > > G++ supports C++1y digit separators. > Long numeric literals can be subdivided with a single quote ' to enhance > readability: > > int i = 1048576; > int j = 1'048'576; > int k = 0x10'; > int m = 0'004'000'000; > int n = 0b0001'''''; > > double x = 1.602'176'565e-19; > double y = 1.602'176'565e-1'9; > > 157c190 . --- >Improved support for C++11, including support for > . 158a192,217 > href="http://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2014";> >Improved experimental support for the upcoming ISO C++ standard, > C++14, >including: > > fixing constexpr member functions without > const; > implementation of the std::exchange() utility > function; > addressing tuples by type; > implemention of std::make_unique; > implemention of std::shared_lock; > making std::result_of SFINAE-friendly; > adding operator() to > integral_constant; > adding user-defined literals for standard library types > std::basic_string, > std::chrono::duration, > and std::complex; > adding two range overloads to non-modifying sequence oprations > std::equal and std::mismatch; > adding IO manipulators for quoted strings; > adding constexpr members to > , > , , and > some containers; > adding compile-time std::integer_sequence; > adding cleaner transformation traits; > making s operator functors easier
Re: [Patch, libgfortran] Set close-on-exec flag when opening files
On Sun, Nov 10, 2013 at 7:16 PM, Tobias Burnus wrote:
> Janne Blomqvist wrote:
>>
>> the attached patch sets the close-on-exec flag when opening files, as
>> is usually considered good practice these days. See e.g.
>> http://www.python.org/dev/peps/pep-0446/ and links therein for more
>> information.
>
>
>> + int flags = O_RDWR|O_CREAT|O_EXCL;
>
> I'd add spaces around "|".
>
>
> Otherwise, it looks good to me. Thanks for the patch and sorry for the slow
> review.
Thanks for the review, committed as r204654. The committed patch
differs from the one sent for review in the following aspects:
- Fixed the issue you mentioned above
- Fixed another "spaces around |" issue
- In set_close_on_exec(), call fcntl only if fd >= 0; this prevents
clobbering errno if something went wrong earlier
- Add __attribute__((unused)) to set_close_on_exec, preventing a
warning on systems having both O_CLOEXEC and mkostemp() (such as
recent Linux)
Committed patch attached. I'll add a note to the wiki as well, to be
added to the release notes at some later point by someone.
--
Janne Blomqvist
diff --git a/libgfortran/configure.ac b/libgfortran/configure.ac
index 4609eba..6417373 100644
--- a/libgfortran/configure.ac
+++ b/libgfortran/configure.ac
@@ -280,7 +280,7 @@ else
strcasestr getrlimit gettimeofday stat fstat lstat getpwuid vsnprintf dup \
getcwd localtime_r gmtime_r getpwuid_r ttyname_r clock_gettime \
readlink getgid getpid getppid getuid geteuid umask getegid \
- secure_getenv __secure_getenv)
+ secure_getenv __secure_getenv mkostemp)
fi
# Check strerror_r, cannot be above as versions with two and three arguments
exist
diff --git a/libgfortran/io/unix.c b/libgfortran/io/unix.c
index dd2715b..8a84ae4 100644
--- a/libgfortran/io/unix.c
+++ b/libgfortran/io/unix.c
@@ -1070,6 +1070,20 @@ unpack_filename (char *cstring, const char *fstring, int
len)
}
+/* Set the close-on-exec flag for an existing fd, if the system
+ supports such. */
+
+static void __attribute__ ((unused))
+set_close_on_exec (int fd __attribute__ ((unused)))
+{
+ /* Mingw does not define F_SETFD. */
+#if defined(F_SETFD) && defined(FD_CLOEXEC)
+ if (fd >= 0)
+fcntl(fd, F_SETFD, FD_CLOEXEC);
+#endif
+}
+
+
/* Helper function for tempfile(). Tries to open a temporary file in
the directory specified by tempdir. If successful, the file name is
stored in fname and the descriptor returned. Returns -1 on
@@ -1109,7 +1123,12 @@ tempfile_open (const char *tempdir, char **fname)
mode_mask = umask (S_IXUSR | S_IRWXG | S_IRWXO);
#endif
+#if defined(HAVE_MKOSTEMP) && defined(O_CLOEXEC)
+ fd = mkostemp (template, O_RDWR | O_CREAT | O_EXCL | O_CLOEXEC);
+#else
fd = mkstemp (template);
+ set_close_on_exec (fd);
+#endif
#ifdef HAVE_UMASK
(void) umask (mode_mask);
@@ -1119,6 +1138,13 @@ tempfile_open (const char *tempdir, char **fname)
fd = -1;
int count = 0;
size_t slashlen = strlen (slash);
+ int flags = O_RDWR | O_CREAT | O_EXCL;
+#if defined(HAVE_CRLF) && defined(O_BINARY)
+ flags |= O_BINARY;
+#endif
+#ifdef O_CLOEXEC
+ flags |= O_CLOEXEC;
+#endif
do
{
snprintf (template, tempdirlen + 23, "%s%sgfortrantmpaaaXX",
@@ -1142,14 +1168,12 @@ tempfile_open (const char *tempdir, char **fname)
continue;
}
-#if defined(HAVE_CRLF) && defined(O_BINARY)
- fd = open (template, O_RDWR | O_CREAT | O_EXCL | O_BINARY,
-S_IRUSR | S_IWUSR);
-#else
- fd = open (template, O_RDWR | O_CREAT | O_EXCL, S_IRUSR | S_IWUSR);
-#endif
+ fd = open (template, flags, S_IRUSR | S_IWUSR);
}
while (fd == -1 && errno == EEXIST);
+#ifndef O_CLOEXEC
+ set_close_on_exec (fd);
+#endif
#endif /* HAVE_MKSTEMP */
*fname = template;
@@ -1323,6 +1347,10 @@ regular_file (st_parameter_open *opp, unit_flags *flags)
crflag |= O_BINARY;
#endif
+#ifdef O_CLOEXEC
+ crflag |= O_CLOEXEC;
+#endif
+
mode = S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IROTH | S_IWOTH;
fd = open (path, rwflag | crflag, mode);
if (flags->action != ACTION_UNSPECIFIED)
@@ -1386,6 +1414,9 @@ open_external (st_parameter_open *opp, unit_flags *flags)
/* regular_file resets flags->action if it is ACTION_UNSPECIFIED and
* if it succeeds */
fd = regular_file (opp, flags);
+#ifndef O_CLOEXEC
+ set_close_on_exec (fd);
+#endif
}
if (fd < 0)
Re: [wwwdocs] [C++14] Library and front-end additions
On 10 November 2013 20:28, Ed Smith-Rowland wrote: > > OK, I folded our versions together. Thank you. I also fixed up my code > examples. > > OK? That looks good, thanks very much for updating it.
Re: [RFC] replace malloc with a decl on the stack
On Sun, 10 Nov 2013, Marc Glisse wrote:
I am posting this patch to get some feedback on the approach. The goal is to
replace malloc+free with a stack allocation (a decl actually) when the size
is a small constant.
A slightly updated version that handles abort and if(VAR==0) where VAR is
the return value of malloc. I was confused because gimple.def doesn't warn
that the labels in a GIMPLE_COND are unused most of the time.
Joost, if you replace #if 0 with #if 1 in the patch, it handles your
testcase from PR 38318, though obviously I can't do that for C.
(warning: I didn't rerun the testsuite)
--
Marc GlisseIndex: testsuite/g++.dg/tree-ssa/heapstack-1.C
===
--- testsuite/g++.dg/tree-ssa/heapstack-1.C (revision 0)
+++ testsuite/g++.dg/tree-ssa/heapstack-1.C (working copy)
@@ -0,0 +1,24 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-optimized" } */
+
+struct A {
+ void*p;
+ A(void*q) : p(q) {}
+ ~A(){ __builtin_free(p); }
+};
+void f(void*)__attribute__((__leaf__));
+void h(void*)__attribute__((__leaf__,__nothrow__));
+void g(){
+ void*p=__builtin_malloc(12);
+ A a(p);
+ f(p);
+}
+
+void i(){
+ void*p=__builtin_malloc(12);
+ h(p);
+ __builtin_free(p);
+}
+
+/* { dg-final { scan-tree-dump-not "malloc" "optimized" } } */
+/* { dg-final { cleanup-tree-dump "optimized" } } */
Property changes on: testsuite/g++.dg/tree-ssa/heapstack-1.C
___
Added: svn:keywords
## -0,0 +1 ##
+Author Date Id Revision URL
\ No newline at end of property
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Index: testsuite/g++.dg/tree-ssa/heapstack-2.C
===
--- testsuite/g++.dg/tree-ssa/heapstack-2.C (revision 0)
+++ testsuite/g++.dg/tree-ssa/heapstack-2.C (working copy)
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-optimized" } */
+
+void f(void*)__attribute__((__leaf__));
+void g(){
+ void*p=__builtin_malloc(12);
+ f(p);
+ __builtin_free(p);
+}
+
+/* { dg-final { scan-tree-dump-times "malloc" 1 "optimized" } } */
+/* { dg-final { cleanup-tree-dump "optimized" } } */
Property changes on: testsuite/g++.dg/tree-ssa/heapstack-2.C
___
Added: svn:keywords
## -0,0 +1 ##
+Author Date Id Revision URL
\ No newline at end of property
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Index: testsuite/gcc.dg/tree-ssa/heapstack-1.c
===
--- testsuite/gcc.dg/tree-ssa/heapstack-1.c (revision 0)
+++ testsuite/gcc.dg/tree-ssa/heapstack-1.c (working copy)
@@ -0,0 +1,23 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-optimized" } */
+
+void* f(void*)__attribute__((__pure__));
+void *q;
+void g(int m,int n){
+ int i;
+ void*p=__builtin_malloc(12);
+ switch(n){
+case 1:
+ for (i=0; i *list_of_frees)
+{
+ tree var = gimple_call_lhs (stmt);
+ basic_block bb = gimple_bb (stmt);
+ stack_vec bb_to_visit;
+ bitmap bb_visited = BITMAP_ALLOC (NULL);
+ bitmap_set_bit (bb_visited, bb->index);
+ gimple_stmt_iterator gsi = gsi_for_stmt (stmt);
+ enum tree_code code;
+
+next_stmt:
+ gsi_next_nondebug (&gsi);
+
+handle_stmt:
+ if (gsi_end_p (gsi))
+{
+ edge e;
+ edge_iterator ei;
+ FOR_EACH_EDGE (e, ei, bb->succs)
+ bb_to_visit.safe_push (e->dest);
+ goto next_bb;
+}
+ stmt = gsi_stmt (gsi);
+ if (stmt_can_throw_external (stmt))
+/* We could give up only if VAR has escaped (same for return), but that
+ means there is a memory leak, so don't bother. */
+goto unsafe;
+
+ switch (gimple_code (stmt))
+ // TODO: GIMPLE_ASM, EH related gimples?
+{
+ /* We leave the function without calling free. */
+ case GIMPLE_RETURN:
+ goto unsafe;
+
+ case GIMPLE_COND:
+ code = gimple_cond_code (stmt);
+ /* If we replace malloc by an array on the stack, it can't be NULL. */
+ if ((code == EQ_EXPR || code == NE_EXPR)
+ && var == gimple_cond_lhs (stmt)
+ && integer_zerop (gimple_cond_rhs (stmt)))
+ {
+ edge e;
+ edge_iterator ei;
+ FOR_EACH_EDGE (e, ei, bb->succs)
+ if (e->flags
+ & ((code == NE_EXPR) ? EDGE_TRUE_VALUE : EDGE_FALSE_VALUE))
+ bb_to_visit.safe_push (e->dest);
+ goto next_bb;
+ }
+ /* Fallthrough. */
+
+ /* Last stmt of the bb, handled by looking at the outgoing edges. */
+ case GIMPLE_GOTO:
+ case GIMPLE_SWITCH:
+ /* Statements that are irrelevant. */
+ case GIMPLE_ASSIGN:
+ case GIMPLE_LABEL:
+ case GIMPLE_NOP:
+ goto next_stmt;
+
+ case GIMPLE_CALL:
+ {
+ tree callee = gimple_call_fndecl (stmt);
+
Re: [C++ PATCH] Refactor implicit function template implementation and fix 58534, 58536, 58548, 58549 and 58637.
On 11/10/2013 02:39 PM, Adam Butcher wrote: I assumed that tsubst simply doesn't do anything with a null tree substitution (i.e. it is an identity op). Substituting NULL_TREE for a template parameter gives a template parameter with a reduced level; this happens during partial instantiation. Since we are tsubsting the declaration here and we only want to adjust the template parameter types themselves at their declaration is this really necessary? I've no problem with implementing this if it truly is necessary but I don't want to add unnecessary cycles if not. The difference between setting copying a pointer to a vec versus setting it to null seems completely negligible to me. I think it is necessary in case the function parameter type involves template parameters from the enclosing context as well as implicit template parameters. One other thing, by 'copy' I take it you mean copy the tree vecs of the enclosing levels only, not also the types within them. Yes, using add_outermost_template_args. And I also assume that I'll need to set the currently unset types in the inner level also? Can you have explicit template parameters at the same level as the implicit ones? If so, then their places in the vec will need to be set appropriately in case they are used in the function parameter type. Jason
Re: [PATCH] make has_gate and has_execute useless
On Fri, Nov 08, 2013 at 10:37:00AM +0100, Richard Biener wrote: > On Thu, Nov 7, 2013 at 5:00 PM, wrote: > > From: Trevor Saunders > > > > Hi, > > > > This is the result of seeing what it would take to get rid of the has_gate > > and > > has_execute flags on pass_data. It turns out not much, but I wanted > > confirmation this part is ok before I go deal with all the places that > > initialize the fields. > > > > I bootstrapped this part on x86_64-unknown-linux-gnu and saw no new test > > suite > > regressions (ignoring the silk stuff because the full paths in its test > > names > > break my test script for now) Any reason this patch with the actual removal > > of the flags wouldn't be ok? > > The has_gate flag is easy to remove (without a TODO_ hack), right? > No gate simply means that the gate returns always true. The only > weird thing is > > /* If we have a gate, combine the properties that we could have with > and without the pass being examined. */ > if (pass->has_gate) > properties &= new_properties; > else > properties = new_properties; > > which I don't understand (and you just removed all properties handling there). > > So can you split out removing has_gate? This part is obviously ok. > > Then, for ->execute () I'd have refactored the code to make > ->sub passes explicitely executed by the default ->execute () > implementation only. That is, passes without overriding execute > are containers only. Can you quickly check whether that would > work out? Ok, I've now given this a shot and wasn't terribly successful, if I just change execute_pass_list and execute_ipa_pass_list to handle container passes executing their sub passes I get the following ICE ./gt-passes.h:77:2: internal compiler error: Segmentation fault }; ^ 0xd43d96 crash_signal /src/gcc/gcc/toplev.c:334 0xd901a9 ssa_default_def(function*, tree_node*) /src/gcc/gcc/tree-dfa.c:318 0xb56d77 ipa_analyze_params_uses /src/gcc/gcc/ipa-prop.c:2094 0xb57275 ipa_analyze_node(cgraph_node*) /src/gcc/gcc/ipa-prop.c:2179 0x13e2b6d ipcp_generate_summary /src/gcc/gcc/ipa-cp.c:3615 0xc55a2a execute_ipa_summary_passes(ipa_opt_pass_d*) /src/gcc/gcc/passes.c:1991 0x943341 ipa_passes /src/gcc/gcc/cgraphunit.c:2011 0x943675 compile() /src/gcc/gcc/cgraphunit.c:2118 now Which is because fn->gimple_df is null. I expect that's because pass ordering changed somehow, but I'm not sure off hand how or ifthat's something worth figuring out right now. Another issue I realized is that doing this will change the order of plugin events from start container pass a end container pass a start contained pass b end contained pass b ... to start container pass a start contained pass b end contained pass b end container pass a Arguably that's an improvement, but I'm not sure if changing that APi like that is acceptable. Trev > > Thanks, > Richard. > > > Trev > > > > 2013-11-06 Trevor Saunders > > > > * pass_manager.h (pass_manager): Adjust. > > * passes.c (opt_pass::execute): Tell the pass manager it doesn't > > need > > to do anything for this pass. > > (pass_manager::register_dump_files_1): Don't uselessly deal with > > properties of passes. > > (pass_manager::register_dump_files): Adjust. > > (dump_one_pass): Just call pass->gate (). > > (execute_ipa_summary_passes): Likewise. > > (execute_one_pass): Don't check pass->has_execute flag. > > (ipa_write_summaries_2): Don't check pass->has_gate flag. > > (ipa_write_optimization_summaries_1): Likewise. > > (ipa_read_summaries_1): Likewise. > > (ipa_read_optimization_summaries_1): Likewise. > > (execute_ipa_stmt_fixups): Likewise. > > * tree-pass.h (pass_data): Rename has_gate to useless_has_gate and > > has_execute to useless_has_execute to be sure they're unused. > > (TODO_absolutely_nothing): New constant. > > > > > > diff --git a/gcc/pass_manager.h b/gcc/pass_manager.h > > index 77d78eb..3bc0a99 100644 > > --- a/gcc/pass_manager.h > > +++ b/gcc/pass_manager.h > > @@ -93,7 +93,7 @@ public: > > > > private: > >void set_pass_for_id (int id, opt_pass *pass); > > - int register_
[PATCH, PING] -fstrict-volatile-bitfields followup
Can someone please review this patch? http://gcc.gnu.org/ml/gcc-patches/2013-10/msg02637.html I would like to commit the already-approved -fstrict-volatile-bitfields patch once we also have an approved fix for the infinite recursion problem I discovered while testing a backport of the patch series to a local copy of GCC 4.8. -Sandra
Re: [wwwdocs] [C++14] Library and front-end additions
On 11/10/2013 03:59 PM, Jonathan Wakely wrote: On 10 November 2013 20:28, Ed Smith-Rowland wrote: OK, I folded our versions together. Thank you. I also fixed up my code examples. OK? That looks good, thanks very much for updating it. OK, I got gcc-4.9/changes.html checked in (after some trouble). Apparently I can't get projects/cxx1y.html checked in now. Here is the patch. Could someone else please check it and check it in? Sorry. Ed Index: htdocs/projects/cxx1y.html === RCS file: /cvs/gcc/wwwdocs/htdocs/projects/cxx1y.html,v retrieving revision 1.8 diff -r1.8 cxx1y.html 113,114c113,115 < http://isocpp.org/files/papers/n3760.htm";>N3760 < No --- >href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3760.html";>N3760 > > 4.9 (N3797) 118,119c119,121 < http://isocpp.org/files/papers/N3781.pdf";>N3781 < No --- >href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3781.pdf";>N3781 > > 4.9 (N3797)
[PATCH] Fix code generation problem with jump threading
If we have a jump threading request through a joiner block which has two
successors S1 and S2. If the threading request goes through S1 and
ultimately reaches S2, then we have to ensure that any PHI nodes in S2
have the same arguments for edges J->S2 and J->S1...->S2.
The SSA/CFG updating code (of course) has code to detect this, however,
it runs *before* we prune the tail of jump threading paths to avoid
threading through multiple loop headers.
ie, we might have a jump threading request like
(224, 255) (225, 226)J (226, 227) (227, 229)
Where there also exists an edge (225, 227).
So if we have to truncate the last edge off the jump threading path we'd
be left with a thread path like:
(224,225) (225,226)(J) (226, 227)
And since there's already an edge (225, 227) we have to test the PHI
node arguments in 227 and reject the thread path if the test fails.
So the obvious fix is to first truncate the paths, *then* do the PHI
node check if its needed.
I don't have a testcase since I tripped this with other changes.
However, there is some chance this fixes a SH problem from Oleg. If so,
we may be able to extract a usable testcase from Oleg's code.
Bootstrapped and regression tested on x86_64-unknown-linux-gnu.
Installed on the trunk.
* tree-ssa-threadupdate.c (mark_threaded_blocks): Truncate jump
threading paths first, then perform PHI node checks if applicable.
diff --git a/gcc/tree-ssa-threadupdate.c b/gcc/tree-ssa-threadupdate.c
index 24e7767..346d532 100644
--- a/gcc/tree-ssa-threadupdate.c
+++ b/gcc/tree-ssa-threadupdate.c
@@ -1269,46 +1395,6 @@ mark_threaded_blocks (bitmap threaded_blocks)
bitmap_set_bit (tmp, e->dest->index);
}
- /* If we have a joiner block (J) which has two successors S1 and S2 and
- we are threading though S1 and the final destination of the thread
- is S2, then we must verify that any PHI nodes in S2 have the same
- PHI arguments for the edge J->S2 and J->S1->...->S2.
-
- We used to detect this prior to registering the jump thread, but
- that prohibits propagation of edge equivalences into non-dominated
- PHI nodes as the equivalency test might occur before propagation.
-
- This works for now, but will need improvement as part of the FSA
- optimization.
-
- Note since we've moved the thread request data to the edges,
- we have to iterate on those rather than the threaded_edges vector. */
- EXECUTE_IF_SET_IN_BITMAP (tmp, 0, i, bi)
-{
- bb = BASIC_BLOCK (i);
- FOR_EACH_EDGE (e, ei, bb->preds)
- {
- if (e->aux)
- {
- vec *path = THREAD_PATH (e);
- bool have_joiner = ((*path)[1]->type ==
EDGE_COPY_SRC_JOINER_BLOCK);
-
- if (have_joiner)
- {
- basic_block joiner = e->dest;
- edge final_edge = path->last ()->e;
- basic_block final_dest = final_edge->dest;
- edge e2 = find_edge (joiner, final_dest);
-
- if (e2 && !phi_args_equal_on_edges (e2, final_edge))
- {
- delete_jump_thread_path (path);
- e->aux = NULL;
- }
- }
- }
- }
-}
/* If optimizing for size, only thread through block if we don't have
@@ -1398,6 +1484,50 @@ mark_threaded_blocks (bitmap threaded_blocks)
}
}
+ /* If we have a joiner block (J) which has two successors S1 and S2 and
+ we are threading though S1 and the final destination of the thread
+ is S2, then we must verify that any PHI nodes in S2 have the same
+ PHI arguments for the edge J->S2 and J->S1->...->S2.
+
+ We used to detect this prior to registering the jump thread, but
+ that prohibits propagation of edge equivalences into non-dominated
+ PHI nodes as the equivalency test might occur before propagation.
+
+ This must also occur after we truncate any jump threading paths
+ as this scenario may only show up after truncation.
+
+ This works for now, but will need improvement as part of the FSA
+ optimization.
+
+ Note since we've moved the thread request data to the edges,
+ we have to iterate on those rather than the threaded_edges vector. */
+ EXECUTE_IF_SET_IN_BITMAP (tmp, 0, i, bi)
+{
+ bb = BASIC_BLOCK (i);
+ FOR_EACH_EDGE (e, ei, bb->preds)
+ {
+ if (e->aux)
+ {
+ vec *path = THREAD_PATH (e);
+ bool have_joiner = ((*path)[1]->type ==
EDGE_COPY_SRC_JOINER_BLOCK);
+
+ if (have_joiner)
+ {
+ basic_block joiner = e->dest;
+ edge final_edge = path->last ()->e;
+ basic_block final_dest = final_edge->dest;
+ edge e2 = find_edge (joiner, final_dest);
+
+ if (e2 && !phi_args_equal_on_edges (e2, final_edge))
+ {
+ de
Re: [RFA][PATCH] Isolate erroneous paths optimization
On 11/10/13 05:34, Eric Botcazou wrote:
But I think that you cannot transform
foo ()
{
*0 = 1;
}
to __builtin_trap as you can catch the trap via an exception handler
in a caller of foo, no?
That is true. OK, I can see an argument that when using
-fnon-call-exceptions that kind of code should not be changed to call
__builtin_trap.
That's exactly the reason why gnat.dg/memtrap.adb started to fail after Jeff's
patch went it. So, if -fisolate-erroneous-paths isn't amended, we'll need to
disable it in Ada like in Go.
In that case I think it would be fine to run the isolate paths
optimization, but to not omit the actual dereference of the NULL
pointer (possibly the dereference could be followed by a trap).
This would probably work for Ada as well.
OK. It sounds like there's a pretty general consensus that we ought ot
go ahead and leave in a load/store of a NULL pointer. I'll go ahead and
run with that. I'll probably just emit SSA_NAME = *0, unless someone
thinks we ought ot distinguish between loads and stores, emitting
SSA_NAME = *0 and *0 = 0 for the two cases respectively.
However, that brings up an couple interesting questions.
Let's say we find a NULL pointer which reaches a return statement in a
function which is marked as returns_nonnull. In that case there is no
dereference. Presumably for that kind of scenario we'll just keep the
builtin trap.
Similarly, assume we extend this pass to detect out-of-bounds array
indexing. It's fairly simple to do and has always been in my plan. In
that case leaving in the array indexing won't necessarily generate a
fault. For those presumably we'll just want the builtin_trap as well?
Again, I don't mind inserting a *0, I just want to have a plan for the
other undefined behaviours we currently detect and those which I plan on
catching soon.
Jeff
Re: [PATCH GCC]Refactor force_expr_to_var_cost and handle type conversion
On Fri, Nov 8, 2013 at 10:06 PM, Richard Biener
wrote:
> On Fri, Nov 8, 2013 at 2:41 PM, bin.cheng wrote:
>> Hi,
>> This patch refactors force_expr_to_var_cost and handles type conversion
>> along with other tree nodes. It is split from the patch posted at
>> http://gcc.gnu.org/ml/gcc-patches/2013-11/msg00546.html
>> Bootstrap and test with the patch lowering address expressions on
>> x86/x86_64/arm. Is it OK?
>
> ENOPATCH
>
Attached here.
I think it should be stated that this patch and the lowering one are
logically one because we rely on this patch to compute cost of lowered
address expression like "&arr + offset".
Moreover, address_cost on x86/x86_64 (is 1) are small, so this patch
has small impact on these two targets. While address_cost on arm (is
9) is non-trivial, it has greater impact on ARM. The statement is in
line with various benchmark data.
Thanks,
bin
--
Best Regards.
Index: gcc/tree-ssa-loop-ivopts.c
===
--- gcc/tree-ssa-loop-ivopts.c (revision 204498)
+++ gcc/tree-ssa-loop-ivopts.c (working copy)
@@ -3608,30 +3608,13 @@ force_expr_to_var_cost (tree expr, bool speed)
op1 = TREE_OPERAND (expr, 1);
STRIP_NOPS (op0);
STRIP_NOPS (op1);
-
- if (is_gimple_val (op0))
- cost0 = no_cost;
- else
- cost0 = force_expr_to_var_cost (op0, speed);
-
- if (is_gimple_val (op1))
- cost1 = no_cost;
- else
- cost1 = force_expr_to_var_cost (op1, speed);
-
break;
+CASE_CONVERT:
case NEGATE_EXPR:
op0 = TREE_OPERAND (expr, 0);
STRIP_NOPS (op0);
op1 = NULL_TREE;
-
- if (is_gimple_val (op0))
- cost0 = no_cost;
- else
- cost0 = force_expr_to_var_cost (op0, speed);
-
- cost1 = no_cost;
break;
default:
@@ -3639,6 +3622,18 @@ force_expr_to_var_cost (tree expr, bool speed)
return new_cost (target_spill_cost[speed], 0);
}
+ if (op0 == NULL_TREE
+ || TREE_CODE (op0) == SSA_NAME || CONSTANT_CLASS_P (op0))
+cost0 = no_cost;
+ else
+cost0 = force_expr_to_var_cost (op0, speed);
+
+ if (op1 == NULL_TREE
+ || TREE_CODE (op1) == SSA_NAME || CONSTANT_CLASS_P (op1))
+cost1 = no_cost;
+ else
+cost1 = force_expr_to_var_cost (op1, speed);
+
mode = TYPE_MODE (TREE_TYPE (expr));
switch (TREE_CODE (expr))
{
@@ -3662,8 +3657,19 @@ force_expr_to_var_cost (tree expr, bool speed)
speed, &sa_cost))
return sa_cost;
}
+
break;
+CASE_CONVERT:
+ {
+ tree inner_mode, outer_mode;
+ outer_mode = TREE_TYPE (expr);
+ inner_mode = TREE_TYPE (op0);
+ cost = new_cost (convert_cost (TYPE_MODE (outer_mode),
+ TYPE_MODE (inner_mode), speed), 0);
+ }
+ break;
+
case MULT_EXPR:
if (cst_and_fits_in_hwi (op0))
cost = new_cost (mult_by_coeff_cost (int_cst_value (op0),
