Re: [PATCH, combine] Fix host-specific behavior in simplify_compare_const()
2013/3/7 Chung-Ju Wu jasonw...@gmail.com: 2013/3/5 Eric Botcazou ebotca...@adacore.com: In other words, any 32-bit target with 'need_64bit_hwint=yes' in config.gcc is not able to have benefit from this optimization because it never passes the condition test. My solution is to use GET_MODE_MASK(mode) to filter out all bits not in target mode. The following is my patch: The patch is OK for 4.9 once stage #1 is open if it passes bootstrap/regtest. Thanks for the approval. I will wait for 4.9 stage1 opening. The following is the new patch according to your suggestions: Hi, Eric, Since now it is on 4.9 stage1, I would like to contribute this patch. The followings are previous discussion: http://gcc.gnu.org/ml/gcc-patches/2013-02/msg01247.html http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00169.html http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00280.html The attached patch has passed bootstrap/regression test on x86_64-unknown-linux-gnu with current main trunk. A plaintext gcc/ChangeLog is as below: 2013-04-06 Chung-Ju Wu jasonw...@gmail.com * combine.c (simplify_compare_const): Use GET_MODE_MASK to filter out unnecessary bits in the constant power of two case. On behalf of Andes Technology Co., we have signed FSF agreement. However, so far I don't have svn write access yet. Would you please help to commit this patch? Thanks again for the approval and I really appreciate your help. :) Best regards, jasonwucj gcc490-combine.svn.patch Description: Binary data
[RFA] [PATCH] Minor improvement to canonicalization of COND_EXPR for gimple
The tree combiner/forward propagator is missing opportunities to
collapse sequences like this:
_15 = _12 ^ _14;
if (_15 != 0)
Into:
if (_12 != _14)
The tree combiner/forward propagator builds this tree:
x ^ y
Then passes it to canonicalize_cond_expr_cond That is not suitable for
the condition in a gimple COND_EXPR. So canonicalize_cond_expr_cond
returns NULL. Thus combine_cond_expr_cond decides the tree it created
isn't useful and throws it away.
This patch changes canonicalize_cond_expr to rewrite x ^ y into x != y.
The net result being the tree combiner/forward propagator is able to
perform the desired simplification, eliminating the BIT_XOR_EXPR.
Bootstrapped and regression tested on x86_64-unknown-linux-gnu. As you
can see from the testcase, these kinds of sequences show up when
compiling gcc itself.
OK for the trunk?
commit 809408a4bde6dfbaf62c5bda9ab7ae6c4447d984
Author: Jeff Law l...@redhat.com
Date: Sat Apr 6 05:11:17 2013 -0600
* gimple.c (canonicalize_cond_expr_cond): Rewrite x ^ y into
x != y.
* gcc.dg/tree-ssa/forwprop-25.c: New test
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index b8a6900..44797cc 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+2013-04-06 Jeff Law l...@redhat.com
+
+ * gimple.c (canonicalize_cond_expr_cond): Rewrite x ^ y into
+ x != y.
+
2013-04-03 Jeff Law l...@redhat.com
* Makefile.in (lra-constraints.o): Depend on $(OPTABS_H).
diff --git a/gcc/gimple.c b/gcc/gimple.c
index 785c2f0..cdb6f24 100644
--- a/gcc/gimple.c
+++ b/gcc/gimple.c
@@ -2958,7 +2958,11 @@ canonicalize_cond_expr_cond (tree t)
t = build2 (TREE_CODE (top0), TREE_TYPE (t),
TREE_OPERAND (top0, 0), TREE_OPERAND (top0, 1));
}
-
+ /* For x ^ y use x != y. */
+ else if (TREE_CODE (t) == BIT_XOR_EXPR)
+t = build2 (NE_EXPR, TREE_TYPE (t),
+ TREE_OPERAND (t, 0), TREE_OPERAND (t, 1));
+
if (is_gimple_condexpr (t))
return t;
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index dc0b745..601ca66 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,7 @@
+2013-04-06 Jeff Law l...@redhat.com
+
+ * gcc.dg/tree-ssa/forwprop-25.c: New test
+
2013-04-03 Jeff Law l...@redhat.com
PR tree-optimization/56799
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/forwprop-25.c
b/gcc/testsuite/gcc.dg/tree-ssa/forwprop-25.c
new file mode 100644
index 000..cf0c504
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/forwprop-25.c
@@ -0,0 +1,43 @@
+/* { dg-do compile } */
+/* { dg-options -O1 -fdump-tree-forwprop1 } */
+
+struct rtx_def;
+typedef struct rtx_def *rtx;
+typedef const struct rtx_def *const_rtx;
+enum machine_mode
+{
+ MAX_MACHINE_MODE,
+ NUM_MACHINE_MODES = MAX_MACHINE_MODE
+};
+extern const char *const mode_name[NUM_MACHINE_MODES];
+enum mode_class
+{ MODE_RANDOM, MODE_CC, MODE_INT, MODE_PARTIAL_INT, MODE_FRACT, MODE_UFRACT,
+MODE_ACCUM, MODE_UACCUM, MODE_FLOAT, MODE_DECIMAL_FLOAT, MODE_COMPLEX_INT,
+MODE_COMPLEX_FLOAT, MODE_VECTOR_INT, MODE_VECTOR_FRACT,
+MODE_VECTOR_UFRACT, MODE_VECTOR_ACCUM, MODE_VECTOR_UACCUM,
+MODE_VECTOR_FLOAT, MAX_MODE_CLASS };
+extern const unsigned char mode_class[NUM_MACHINE_MODES];
+extern const unsigned short mode_precision[NUM_MACHINE_MODES];
+struct rtx_def
+{
+ __extension__ enum machine_mode mode:8;
+};
+void
+convert_move (rtx to, rtx from, int unsignedp)
+{
+ enum machine_mode to_mode = ((enum machine_mode) (to)-mode);
+ enum machine_mode from_mode = ((enum machine_mode) (from)-mode);
+ ((void)
+ (!((mode_precision[from_mode] != mode_precision[to_mode])
+ || enum mode_class) mode_class[from_mode]) == MODE_DECIMAL_FLOAT) !=
+ (((enum mode_class) mode_class[to_mode]) ==
+ MODE_DECIMAL_FLOAT))) ?
+fancy_abort (/home/gcc/virgin-gcc/gcc/expr.c, 380, __FUNCTION__),
+0 : 0));
+}
+
+/* { dg-final { scan-tree-dump Replaced.*!=.*with.*!=.* forwprop1} } */
+/* { dg-final { cleanup-tree-dump forwprop1 } } */
+
+
+
[RFA][PATCH] Improve VRP of COND_EXPR_CONDs
Given something like this:
bb 6:
_23 = changed_17 ^ 1;
_12 = (_Bool) _23;
if (_12 != 0)
goto bb 10;
else
goto bb 7;
Assume _23 and changed_17 have integer types wider than a boolean, but
VRP has determined they have a range [0..1].
We should be turning that into:
bb 6:
_23 = changed_17 ^ 1;
_12 = (_Bool) _23;
if (_23 != 0)
goto bb 10;
else
goto bb 7;
Note the change in the conditional. This also makes the statement
_12 = (_Bool) _23 dead which should be eliminated by DCE.
This kind of thing happens regularly in GCC itself and is fixed by the
attached patch.
Bootstrapped and regression tested on x86_64-unknown-linux-gnu.
OK for the trunk?
commit fd82eea6f208bb12646e0e0e307fb86f043c1649
Author: Jeff Law l...@redhat.com
Date: Sat Apr 6 06:46:58 2013 -0600
* tree-vrp.c (simplify_cond_using_ranges): Simplify test of boolean
when the boolean was created by converting a wider object which
had a boolean range.
* gcc.dg/tree-ssa/vrp87.c: New test
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 44797cc..d34ecde 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,5 +1,9 @@
2013-04-06 Jeff Law l...@redhat.com
+ * tree-vrp.c (simplify_cond_using_ranges): Simplify test of boolean
+ when the boolean was created by converting a wider object which
+ had a boolean range.
+
* gimple.c (canonicalize_cond_expr_cond): Rewrite x ^ y into
x != y.
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 601ca66..6ed8af2 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,5 +1,7 @@
2013-04-06 Jeff Law l...@redhat.com
+ * gcc.dg/tree-ssa/vrp87.c: New test
+
* gcc.dg/tree-ssa/forwprop-25.c: New test
2013-04-03 Jeff Law l...@redhat.com
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/vrp87.c
b/gcc/testsuite/gcc.dg/tree-ssa/vrp87.c
new file mode 100644
index 000..7feff81
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/vrp87.c
@@ -0,0 +1,81 @@
+/* { dg-do compile } */
+/* { dg-options -O2 -fdump-tree-vrp2-details -fdump-tree-cddce2-details } */
+
+struct bitmap_head_def;
+typedef struct bitmap_head_def *bitmap;
+typedef const struct bitmap_head_def *const_bitmap;
+
+
+typedef unsigned long BITMAP_WORD;
+typedef struct bitmap_element_def
+{
+ struct bitmap_element_def *next;
+ unsigned int indx;
+ BITMAP_WORD bits[((128 + (8 * 8 * 1u) - 1) / (8 * 8 * 1u))];
+} bitmap_element;
+
+
+
+
+
+
+typedef struct bitmap_head_def
+{
+ bitmap_element *first;
+
+} bitmap_head;
+
+
+
+static __inline__ unsigned char
+bitmap_elt_ior (bitmap dst, bitmap_element * dst_elt,
+ bitmap_element * dst_prev, const bitmap_element * a_elt,
+ const bitmap_element * b_elt, unsigned char changed)
+{
+
+ if (a_elt)
+{
+
+ if (!changed dst_elt)
+ {
+ changed = 1;
+ }
+}
+ else
+{
+ changed = 1;
+}
+ return changed;
+}
+
+unsigned char
+bitmap_ior_into (bitmap a, const_bitmap b)
+{
+ bitmap_element *a_elt = a-first;
+ const bitmap_element *b_elt = b-first;
+ bitmap_element *a_prev = ((void *) 0);
+ unsigned char changed = 0;
+
+ while (b_elt)
+{
+
+ if (!a_elt || a_elt-indx == b_elt-indx)
+ changed = bitmap_elt_ior (a, a_elt, a_prev, a_elt, b_elt, changed);
+ else if (a_elt-indx b_elt-indx)
+ changed = 1;
+ b_elt = b_elt-next;
+
+
+}
+
+ return changed;
+}
+
+/* Verify that VRP simplified an if statement. */
+/* { dg-final { scan-tree-dump Folded into: if.* vrp2} } */
+/* Verify that DCE after VRP2 eliminates a dead conversion
+ to a (Bool). */
+/* { dg-final { scan-tree-dump Deleting.*_Bool.*; cddce2} } */
+/* { dg-final { cleanup-tree-dump vrp2 } } */
+/* { dg-final { cleanup-tree-dump cddce2 } } */
+
diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c
index 250a506..d76cead 100644
--- a/gcc/tree-vrp.c
+++ b/gcc/tree-vrp.c
@@ -8584,6 +8584,43 @@ simplify_cond_using_ranges (gimple stmt)
}
}
+ /* If we have a comparison of a SSA_NAME boolean against
+ a constant (which obviously must be [0..1]). See if the
+ SSA_NAME was set by a type conversion where the source
+ of the conversion is another SSA_NAME with a range [0..1].
+
+ If so, we can replace the SSA_NAME in the comparison with
+ the RHS of the conversion. This will often make the type
+ conversion dead code which DCE will clean up. */
+ if (TREE_CODE (op0) == SSA_NAME
+ TREE_CODE (TREE_TYPE (op0)) == BOOLEAN_TYPE
+ is_gimple_min_invariant (op1))
+{
+ gimple def_stmt = SSA_NAME_DEF_STMT (op0);
+ tree innerop;
+
+ if (!is_gimple_assign (def_stmt)
+ || !CONVERT_EXPR_CODE_P (gimple_assign_rhs_code (def_stmt)))
+ return false;
+
+ innerop = gimple_assign_rhs1 (def_stmt);
+
+ if (!SSA_NAME_OCCURS_IN_ABNORMAL_PHI (innerop))
+ {
+ value_range_t *vr = get_value_range (innerop);
+
+
Re: [RFA][PATCH] Improve VRP of COND_EXPR_CONDs
On Sat, Apr 6, 2013 at 2:48 PM, Jeff Law wrote:
Given something like this:
...and the other one from earlier today. Nice finds! :-)
+ /* If we have a comparison of a SSA_NAME boolean against
+ a constant (which obviously must be [0..1]). See if the
...be [0..1]), see if ...
+ if (!SSA_NAME_OCCURS_IN_ABNORMAL_PHI (innerop))
+ {
+ value_range_t *vr = get_value_range (innerop);
+
I don't think the SSA_NAME_OCCURS_IN_ABNORMAL_PHI test is necessary,
get_value_range() will simply return a !VR_RANGE.
+ if (vr-type == VR_RANGE
+ operand_equal_p (vr-min, integer_zero_node, 0)
+ operand_equal_p (vr-max, integer_one_node, 0))
+ {
Better use range_int_cst_p(vr) followed by compare_tree_int instead of
operand_equal_p IMHO.
Print something to dump_file?
Ciao!
Steven
Re: functional and type_traits cleanup
On 5 April 2013 21:12, François Dumont wrote:
In fact my first attempt was a very simple one:
templatetypename _From, typename _To
class __is_convertible_helper_From, _To, false
{
templatetypename _To1
static true_type
__test(_To1);
templatetypename
static false_type
__test(...);
public:
typedef decltype(__test_To(std::declval_From())) type;
};
But some tests failed like:
In file included from
/home/fdt/dev/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/move.h:57:0,
from
/home/fdt/dev/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/stl_pair.h:59,
from
/home/fdt/dev/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/utility:70,
from
/home/fdt/dev/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/tuple:38,
from
/home/fdt/dev/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/functional:55,
from
/home/fdt/dev/gcc/src/libstdc++-v3/testsuite/20_util/bind/38889.cc:23:
/home/fdt/dev/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/type_traits:
In instantiation of 'struct std::__is_convertible_helperconst
std::tuplestd::_Placeholder1 , std::_Placeholder1, false':
/home/fdt/dev/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/type_traits:1321:12:
required from 'struct std::is_convertibleconst
std::tuplestd::_Placeholder1 , std::_Placeholder1 '
/home/fdt/dev/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/type_traits:111:12:
required from 'struct std::__and_std::is_convertibleconst
std::tuplestd::_Placeholder1 , std::_Placeholder1 '
/home/fdt/dev/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/tuple:400:40:
required from 'struct std::_Bindvoid (*(std::_Placeholder1))(int)'
/home/fdt/dev/gcc/src/libstdc++-v3/testsuite/20_util/bind/38889.cc:28:41:
required from here
/home/fdt/dev/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/type_traits:1316:30:
error: 'std::_Placeholder1' is an inaccessible base of
'std::tuplestd::_Placeholder1 '
typedef decltype(__test_To(std::declval_From())) type;
^
/home/fdt/dev/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/type_traits:1309:2:
error: initializing argument 1 of 'static std::true_type
std::__is_convertible_helper_From, _To, false::__test(_To1) [with _To1 =
std::_Placeholder1; _From = const std::tuplestd::_Placeholder1 ; _To
= std::_Placeholder1; std::true_type = std::integral_constantbool,
true]'
__test(_To1);
^
From my point of view this is an other example of use case for which gcc is
not SFINAE friendly enough, no ?
No, I don't think this is a GCC problem. In this code the
derived-to-base conversion does not happen in the context of the
function template argument deduction but happens afterwards, so the
access failure is not part of argument deduction and so is a hard
error not a substitution failure.
But the version with the default template parameter is fine and more
consistent with the other helpers implementation so, adopted! Here is an
other version of the patch for validation.
Daniel, I agree that inheritance with integral_constant is not as
obvious as before but it is still there and it is just what the compiler
need.
I assume Daniel's reply was an HTML mail and didn't make it to the
list, was there an objection to the change or a general comment?
I even hope that it also simplified a (very) little bit the job for
the compiler.
I don't know if the compiler's job is easier or not, but I think with
your change the template instantiation depth is increased by one, with
your change we get false_type instantiated by the instantiation of
is_convertible, rather than being done after it using its value
member.
Ok to commit ?
I'd like to hear Daniel's comment first, but if we don't hear from him
please commit it in 24 hours. Thanks.
[committed] Fix PR target/55487: Don't increment label nuses on NOTE_INSN_DELETED_LABEL notes
The fix is obvious. Tested on hppa64-hp-hpux11.11 and hppa-unknown- linux-gnu with no observed regressions. Committed to 4.8 and trunk. Dave -- John David Anglin dave.ang...@bell.net 2013-04-06 John David Anglin dave.ang...@nrc-cnrc.gc.ca PR target/55487 * config/pa/pa.c (legitimize_pic_address): Before incrementing label nuses, make sure we have a label. Index: config/pa/pa.c === --- config/pa/pa.c (revision 197452) +++ config/pa/pa.c (working copy) @@ -792,7 +792,9 @@ /* Extract CODE_LABEL. */ orig = XEXP (orig, 0); add_reg_note (insn, REG_LABEL_OPERAND, orig); - LABEL_NUSES (orig)++; + /* Make sure we have label and not a note. */ + if (LABEL_P (orig)) + LABEL_NUSES (orig)++; } crtl-uses_pic_offset_table = 1; return reg;
[committed] Fix GCC bootstrap on hppa*-*-hpux* using HP cat
The patch fixes PR other/55274 and we now generate a non empty map file. As noted in the PR, this problem causes a hang when bootstrap is done using HP cat. Tested on hppa64-hp-hpux11.11 and hppa2.0w-hp-hpux11.11. Committed to trunk and 4.8. Richard, would it be ok to apply to the 4.7 branch? This is a 4.7 regression. Dave -- John David Anglin dave.ang...@bell.net 2013-04-06 John David Anglin dave.ang...@nrc-cnrc.gc.ca PR other/55274 * config/t-slibgcc-hpux (SHLIB_MAPFILES): Define. Index: config/t-slibgcc-hpux === --- config/t-slibgcc-hpux (revision 197540) +++ config/t-slibgcc-hpux (working copy) @@ -5,3 +5,4 @@ INSTALL_SHLIB = $(INSTALL_DATA) -m 555 SHLIB_MKMAP = $(srcdir)/mkmap-flat.awk +SHLIB_MAPFILES = libgcc-std.ver
Re: functional and type_traits cleanup
2013/4/6 Jonathan Wakely jwakely@gmail.com But the version with the default template parameter is fine and more consistent with the other helpers implementation so, adopted! Here is an other version of the patch for validation. Daniel, I agree that inheritance with integral_constant is not as obvious as before but it is still there and it is just what the compiler need. I assume Daniel's reply was an HTML mail and didn't make it to the list, was there an objection to the change or a general comment? Yes, I got a reply that my response was not accepted due to html content. I hope this one gets into it. My response was more like a general comment: My apprehension is that I after these changes not all predicate type traits do satisfy the Library requirement anymore that they still derive from std::integral_constant. But I have not checked that individually. I even hope that it also simplified a (very) little bit the job for the compiler. I don't know if the compiler's job is easier or not, but I think with your change the template instantiation depth is increased by one, with your change we get false_type instantiated by the instantiation of is_convertible, rather than being done after it using its value member. Ok to commit ? I'd like to hear Daniel's comment first, but if we don't hear from him please commit it in 24 hours. Thanks. Thanks Jonathan. The text above more or less reflects the content of my previous comment. I think I have no formal objection to the changes, but after they have been applied I would like to do a more rigorous test of the inheritance requirement. - Daniel
Re: functional and type_traits cleanup
On 6 April 2013 21:03, Daniel Krügler wrote: 2013/4/6 Jonathan Wakely jwakely@gmail.com But the version with the default template parameter is fine and more consistent with the other helpers implementation so, adopted! Here is an other version of the patch for validation. Daniel, I agree that inheritance with integral_constant is not as obvious as before but it is still there and it is just what the compiler need. I assume Daniel's reply was an HTML mail and didn't make it to the list, was there an objection to the change or a general comment? Yes, I got a reply that my response was not accepted due to html content. I hope this one gets into it. It did: http://gcc.gnu.org/ml/libstdc++/2013-04/msg00031.html My response was more like a general comment: My apprehension is that I after these changes not all predicate type traits do satisfy the Library requirement anymore that they still derive from std::integral_constant. But I have not checked that individually. They should all do, because the types that used to define a 'value' member all now define a 'type' as a typedef for either true_type or false_type. Thanks Jonathan. The text above more or less reflects the content of my previous comment. I think I have no formal objection to the changes, but after they have been applied I would like to do a more rigorous test of the inheritance requirement. That wouldn't hurt, but I agree it shouldn't prevent the patch going in. François, please go ahead and commit it, thanks.
C: Add new warning -Wunprototyped-calls
This patch comes from Richard's SUSE GCC patch. There,
-Wunprototyped-calls is enabled for all RPM builds.
-Wunprototyped-calls prints a warning if one calls a function with an
argument with is declared without prototype. For instance:
gcc.dg/Wunprototyped-calls.c: In function ‘main’:
gcc.dg/Wunprototyped-calls.c:13:3: warning: call to function ‘g’ without
a real prototype [-Wunprototyped-calls]
g(1); /* { dg-warning call to function 'g' without a real prototype } */
^
gcc.dg/Wunprototyped-calls.c:7:6: note: ‘g’ was declared here
void g() { } /* { dg-message note: 'g' was declared here } */
To avoid too many warning, no warning is shows for KR procedures or if
no argument is passed to the function. (i.e. for those where the
programmer just forgot the (void).)
The warning can help finding argument-passing bugs and it is less
intrusive than -Wstrict-prototypes.
The patch activates the warning with -Wall, but one could also argue
that it should only be activated with -Wextra or only with
-Wunprototyped-calls.
Bootstrapped (C,ObjC,C++,ObjC++ only) and regtested on x86-64-gnu-linux.
OK for the trunk?
Tobias
gcc/c-family/
2013-04-07 Richard Biener rguent...@suse.de
Tobias Burnus bur...@net-b.de
* c.opt (Wunprototyped-calls): New C/ObjC warning.
* c-opts.c (c_common_handle_option): Handle it.
gcc/c/
2013-04-07 Richard Biener rguent...@suse.de
* c-typeck.c (build_function_call_vec): Handle warning
warn_unprototyped_calls.
gcc/
2013-04-07 Tobias Burnus bur...@net-b.de
* doc/invoke.texi (-Wunprototyped-calls): Document it.
(-Wall): Add -Wunprototyped-calls to the list.
gcc/testsuite/
2013-04-07 Richard Biener rguent...@suse.de
Tobias Burnus bur...@net-b.de
* gcc.dg/cleanup-1.c: Update dg-warning.
* gcc.dg/Wunprototyped-calls.c: New.
diff --git a/gcc/c-family/c-opts.c b/gcc/c-family/c-opts.c
index 4b6990a..a66e2a6 100644
--- a/gcc/c-family/c-opts.c
+++ b/gcc/c-family/c-opts.c
@@ -444,6 +444,10 @@ c_common_handle_option (size_t scode, const char *arg, int value,
warn_unknown_pragmas = value * 2;
break;
+case OPT_Wunprototyped_calls:
+ warn_unprototyped_calls = value;
+ break;
+
case OPT_ansi:
if (!c_dialect_cxx ())
set_std_c89 (false, true);
diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index 10ae84d..9c2de33 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -757,6 +757,10 @@ Wunused-local-typedefs
C ObjC C++ ObjC++ Var(warn_unused_local_typedefs) Warning EnabledBy(Wunused)
Warn when typedefs locally defined in a function are not used
+Wunprototyped-calls
+C ObjC Var(warn_unprototyped_calls) Warning LangEnabledBy(C ObjC,Wall)
+Warn about calls to unprototyped functions with at least one argument
+
Wunused-macros
C ObjC C++ ObjC++ Var(cpp_warn_unused_macros) Warning
Warn about macros defined in the main file that are not used
diff --git a/gcc/c/c-typeck.c b/gcc/c/c-typeck.c
index ddb6d39..26336b3 100644
--- a/gcc/c/c-typeck.c
+++ b/gcc/c/c-typeck.c
@@ -2833,6 +2833,19 @@ build_function_call_vec (location_t loc, tree function,
!check_builtin_function_arguments (fundecl, nargs, argarray))
return error_mark_node;
+ /* If we cannot check function arguments because a prototype is
+ missing for the callee, warn here. */
+ if (warn_unprototyped_calls
+ nargs 0 !TYPE_ARG_TYPES (fntype)
+ fundecl !DECL_BUILT_IN (fundecl) !C_DECL_IMPLICIT (fundecl)
+ !DECL_ARGUMENTS (fundecl))
+{
+ if (warning (OPT_Wunprototyped_calls,
+ call to function %qD without a real prototype, fundecl))
+ inform (DECL_SOURCE_LOCATION (fundecl), %qD was declared here,
+ fundecl);
+}
+
/* Check that the arguments to the function are valid. */
check_function_arguments (fntype, nargs, argarray);
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 1652ebc..ee1a351 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -279,8 +279,8 @@ Objective-C and Objective-C++ Dialects}.
@gccoptlist{-Wbad-function-cast -Wmissing-declarations @gol
-Wmissing-parameter-type -Wmissing-prototypes -Wnested-externs @gol
-Wold-style-declaration -Wold-style-definition @gol
--Wstrict-prototypes -Wtraditional -Wtraditional-conversion @gol
--Wdeclaration-after-statement -Wpointer-sign}
+-Wstrict-prototypes -Wunprototyped-calls -Wtraditional @gol
+-Wtraditional-conversion -Wdeclaration-after-statement -Wpointer-sign}
@item Debugging Options
@xref{Debugging Options,,Options for Debugging Your Program or GCC}.
@@ -3144,6 +3144,7 @@ Options} and @ref{Objective-C and Objective-C++ Dialect Options}.
-Wtrigraphs @gol
-Wuninitialized @gol
-Wunknown-pragmas @gol
+-Wunprototyped-calls @r{(only for C/ObjC)} @gol
-Wunused-function @gol
-Wunused-label @gol
-Wunused-value @gol
@@ -4455,6 +4456,15 @@ argument types. (An old-style function definition is permitted without
a warning if preceded by a declaration that specifies the argument
types.)
+@item
Re: C: Add new warning -Wunprototyped-calls
Tobias Burnus bur...@net-b.de writes: gcc.dg/Wunprototyped-calls.c:13:3: warning: call to function ‘g’ without a real prototype [-Wunprototyped-calls] What is a real prototype? Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different.
[patch] update documentation for SEQUENCE
Hello,
The existing documentation for SEQUENCE still states it is used for
DEFINE_EXPAND sequences. I think I wasn't even hacking GCC when that
practice was abandoned, and in the mean time some other uses of
SEQUENCE have appeared in the compiler. So, a long-overdue
documentation update.
OK for trunk?
Ciao!
Steven
* doc/rtl.texi (sequence): Rewrite documentation to match the
current use of SEQUENCE rtl objects.
* rtl.def (SEQUENCE): Likewise.
Index: doc/rtl.texi
===
--- doc/rtl.texi(revision 197532)
+++ doc/rtl.texi(working copy)
@@ -3099,18 +3099,11 @@ side-effects.
@findex sequence
@item (sequence [@var{insns} @dots{}])
-Represents a sequence of insns. Each of the @var{insns} that appears
-in the vector is suitable for appearing in the chain of insns, so it
-must be an @code{insn}, @code{jump_insn}, @code{call_insn},
-@code{code_label}, @code{barrier} or @code{note}.
+Represents a sequence of insns. If a @code{sequence} appears in the
+chain of insns, then each of the @var{insns} that appears in the sequence
+must be suitable for appearing in the chain of insns, i.e. must satisfy
+the @code{INSN_P} predicate.
-A @code{sequence} RTX is never placed in an actual insn during RTL
-generation. It represents the sequence of insns that result from a
-@code{define_expand} @emph{before} those insns are passed to
-@code{emit_insn} to insert them in the chain of insns. When actually
-inserted, the individual sub-insns are separated out and the
-@code{sequence} is forgotten.
-
After delay-slot scheduling is completed, an insn and all the insns that
reside in its delay slots are grouped together into a @code{sequence}.
The insn requiring the delay slot is the first insn in the vector;
@@ -3123,6 +3116,19 @@ the effect of the insns in the delay slots. In su
the branch and should be executed only if the branch is taken; otherwise
the insn should be executed only if the branch is not taken.
@xref{Delay Slots}.
+
+Some back ends also use @code{sequence} objects for purposes other than
+delay-slot groups. This is not supported in the common parts of the
+compiler, which treat such sequences as delay-slot groups.
+
+DWARF2 Call Frame Address (CFA) adjustments are sometimes also expressed
+using @code{sequence} objects as the value of a @code{RTX_FRAME_RELATED_P}
+note. This only happens if the CFA adjustments cannot be easily derived
+from the pattern of the instruction to which the note is attached. In
+such cases, the value of the note is used instead of best-guesing the
+semantics of the instruction. The back end can attach notes containing
+a @code{sequence} of @code{set} patterns that express the effect of the
+parent instruction.
@end table
These expression codes appear in place of a side effect, as the body of
Index: rtl.def
===
--- rtl.def (revision 197533)
+++ rtl.def (working copy)
@@ -102,10 +102,24 @@ DEF_RTL_EXPR(EXPR_LIST, expr_list, ee, RTX_EXT
The insns are represented in print by their uids. */
DEF_RTL_EXPR(INSN_LIST, insn_list, ue, RTX_EXTRA)
-/* SEQUENCE appears in the result of a `gen_...' function
- for a DEFINE_EXPAND that wants to make several insns.
- Its elements are the bodies of the insns that should be made.
- `emit_insn' takes the SEQUENCE apart and makes separate insns. */
+/* SEQUENCE is used in late passes of the compiler to group insns for
+ one reason or another.
+
+ For example, after delay slot filling, branch instructions with filled
+ delay slots are represented as a SEQUENCE of length 1 + n_delay_slots,
+ with the branch instruction in XEXPVEC(seq, 0, 0) and the instructions
+ occupying the delay slots in the remaining XEXPVEC slots.
+
+ Another place where a SEQUENCE may appear, is in REG_FRAME_RELATED_EXPR
+ notes, to express complex operations that are not obvious from the insn
+ to which the REG_FRAME_RELATED_EXPR note is attached. In this usage of
+ SEQUENCE, the sequence vector slots do not hold real instructions but
+ only pseudo-instructions that can be translated to DWARF CFA expressions.
+
+ Some back ends also use SEQUENCE to group insns in bundles.
+
+ Much of the compiler infrastructure is not prepared to handle SEQUENCE
+ objects. Only passes after pass_free_cfg are expected to handle them. */
DEF_RTL_EXPR(SEQUENCE, sequence, E, RTX_EXTRA)
/* Represents a non-global base address. This is only used in alias.c. */
Re: functional and type_traits cleanup
Hi, On 04/06/2013 10:43 PM, Jonathan Wakely wrote: My response was more like a general comment: My apprehension is that I after these changes not all predicate type traits do satisfy the Library requirement anymore that they still derive from std::integral_constant. But I have not checked that individually. They should all do, because the types that used to define a 'value' member all now define a 'type' as a typedef for either true_type or false_type. When I saw the patch I had the same concern, but indeed the nice simplification seems worth the less transparent conformance. Personally, I would be much less nervous if for type_traits too we could have typedef checks for each and every trait (like we do for the tr1/type_traits). By the way, we should also check that the value_type operator is there... Thanks! Paolo.
[patch] PR middle-end/43631
Hello,
In this PR43631, var-tracking notes are inserted on basic block
boundaries and BB_HEAD/BB_END end up pointing to these notes. This
breaks verify_flow_info.
The problem is actually bigger than just the var-tracking notes. The
general problem is that there are no rules for whether or not notes
are part of a basic block or not. Some notes never appear inside a
basic block, some notes always must appear inside a basic block, and
some can appear virtually anywhere.
With this patch I've chosen to maintain the invariant that BB_END must
be an INSN, and never be a NOTE or BARRIER. The result is that
NOTE_INSN_EH_REGION_BEG notes can be inside a basic block while the
pairing NOTE_INSN_EH_REGION_END is outside the basic block. I don't
think this is a problem: The same thing already happens with jump
table data, barriers, etc.
The nice thing is that with this patch, *finally* I have
verify_flow_info pass after var-tracking. That's important because
officially the CFG is freed after this pass (pass_free_cfg runs after
pass_variable_tracking) but because verify_flow_info didn't pass after
var-tracking the CFG was already invalidated before it was freed
(BB_HEAD and BB_END would be incorrect). That has the effect that some
of the machine-reorg passes that use the CFG never really had a
correct CFG at all!
With this patch and a hack to call compute_bb_for_insn, I now can call
verify_flow_info in every pass up to final for the i386 port :-)
Bootstrappedtested on x86_64-unknown-linux-gnu and powerpc64-unknown-linux-gnu.
OK for trunk?
Ciao!
Steven
PR middle-end/43631
* emit-rtl.c (link_insn_into_chain): New static inline function.
(add_insn): Use it.
(add_insn_before, add_insn_after): Factor insn chain linking code...
(add_insn_before_nobb, add_insn_after_nobb): ...here, new functions
using link_insn_into_chain.
(emit_note_after): Use nobb variant of add_insn_after if the note
should not be contained in a basic block.
(emit_note_before): Use nobb variant of add_insn_before if the note
should not be contained in a basic block.
* bb-reorder.c (insert_section_boundary_note): Remove hack to set
BLOCK_FOR_INSN to NULL manually for NOTE_INSN_SWITCH_TEXT_SECTIONS.
* jump.c (cleanup_barriers): Use reorder_insns_nobb to avoid making
the moved barrier the tail of the basic block it follows.
* var-tracking.c (pass_variable_tracking): Add TODO_verify_flow.
Index: emit-rtl.c
===
--- emit-rtl.c (revision 197536)
+++ emit-rtl.c (working copy)
@@ -3752,61 +3752,122 @@ make_call_insn_raw (rtx pattern)
return insn;
}
+/* Add INSN to the end of the doubly-linked list, between PREV and NEXT.
+ INSN may be any object that can appear in the chain: INSN_P and NOTE_P
objects,
+ but also BARRIERs and JUMP_TABLE_DATAs. PREV and NEXT may be NULL. */
+
+static inline void
+link_insn_into_chain (rtx insn, rtx prev, rtx next)
+{
+ PREV_INSN (insn) = prev;
+ NEXT_INSN (insn) = next;
+ if (prev != NULL)
+{
+ NEXT_INSN (prev) = insn;
+ if (NONJUMP_INSN_P (prev) GET_CODE (PATTERN (prev)) == SEQUENCE)
+ {
+ rtx sequence = PATTERN (prev);
+ NEXT_INSN (XVECEXP (sequence, 0, XVECLEN (sequence, 0) - 1)) = insn;
+ }
+}
+ if (next != NULL)
+{
+ PREV_INSN (next) = insn;
+ if (NONJUMP_INSN_P (next) GET_CODE (PATTERN (next)) == SEQUENCE)
+ PREV_INSN (XVECEXP (PATTERN (next), 0, 0)) = insn;
+}
+}
+
/* Add INSN to the end of the doubly-linked list.
INSN may be an INSN, JUMP_INSN, CALL_INSN, CODE_LABEL, BARRIER or NOTE. */
void
add_insn (rtx insn)
{
- PREV_INSN (insn) = get_last_insn();
- NEXT_INSN (insn) = 0;
-
- if (NULL != get_last_insn())
-NEXT_INSN (get_last_insn ()) = insn;
-
+ rtx prev = get_last_insn ();
+ link_insn_into_chain (insn, prev, NULL);
if (NULL == get_insns ())
set_first_insn (insn);
-
set_last_insn (insn);
}
/* Add INSN into the doubly-linked list after insn AFTER. This and
the next should be the only functions called to insert an insn once
delay slots have been filled since only they know how to update a
- SEQUENCE. */
+ SEQUENCE.
+ This function is internal to emit-rtl.c. Use add_insn_after outside
+ this file. */
-void
-add_insn_after (rtx insn, rtx after, basic_block bb)
+static void
+add_insn_after_nobb (rtx insn, rtx after)
{
rtx next = NEXT_INSN (after);
gcc_assert (!optimize || !INSN_DELETED_P (after));
- NEXT_INSN (insn) = next;
- PREV_INSN (insn) = after;
+ link_insn_into_chain (insn, after, next);
- if (next)
+ if (next == NULL)
{
- PREV_INSN (next) = insn;
- if (NONJUMP_INSN_P (next) GET_CODE (PATTERN (next)) == SEQUENCE)
- PREV_INSN (XVECEXP (PATTERN (next), 0, 0)) = insn;
+ if (get_last_insn () == after)
+ set_last_insn (insn);
+ else
+
Re: [PATCH, combine] Fix host-specific behavior in simplify_compare_const()
On 04/06/2013 01:42 AM, Chung-Ju Wu wrote: The attached patch has passed bootstrap/regression test on x86_64-unknown-linux-gnu with current main trunk. A plaintext gcc/ChangeLog is as below: 2013-04-06 Chung-Ju Wu jasonw...@gmail.com * combine.c (simplify_compare_const): Use GET_MODE_MASK to filter out unnecessary bits in the constant power of two case. On behalf of Andes Technology Co., we have signed FSF agreement. However, so far I don't have svn write access yet. Would you please help to commit this patch? Thanks again for the approval and I really appreciate your help. :) I'd suggest getting write access to the repository. See Authenticated access on this page: http://gcc.gnu.org/svnwrite.html List me as your sponsor. jeff
Re: [RFA][PATCH] Improve VRP of COND_EXPR_CONDs
On 04/06/2013 07:08 AM, Steven Bosscher wrote:
+ if (!SSA_NAME_OCCURS_IN_ABNORMAL_PHI (innerop))
+ {
+ value_range_t *vr = get_value_range (innerop);
+
I don't think the SSA_NAME_OCCURS_IN_ABNORMAL_PHI test is necessary,
get_value_range() will simply return a !VR_RANGE.
It's not necessary -- the code was templated from an unsubmitted related
change to tree-ssa-forwprop where that test is needed. I'll remove it
from this change to tree-vrp.c
+ if (vr-type == VR_RANGE
+ operand_equal_p (vr-min, integer_zero_node, 0)
+ operand_equal_p (vr-max, integer_one_node, 0))
+ {
Better use range_int_cst_p(vr) followed by compare_tree_int instead of
operand_equal_p IMHO.
Seems reasonable.
Print something to dump_file?
Happens via existing machinery. You'll get a Folded into ... message in
the detail dumps. The testcase actually checks for this and also
verifies the following DCE pass kills the dead code.
jeff
RE: [PATCH GCC]Relax the probability condition in CE pass when optimizing for code size
-Original Message- From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] On Behalf Of Bin Cheng Sent: Tuesday, March 26, 2013 4:33 PM To: 'Joern Rennecke' Cc: gcc-patches@gcc.gnu.org; 'Jeff Law' Subject: RE: [PATCH GCC]Relax the probability condition in CE pass when optimizing for code size -Original Message- From: Joern Rennecke [mailto:joern.renne...@embecosm.com] Sent: Monday, March 25, 2013 8:53 PM To: Bin Cheng Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH GCC]Relax the probability condition in CE pass when optimizing for code size Quoting Bin Cheng bin.ch...@arm.com: During the work I observed passes before combine might interfere with CE pass, so this patch is enabled for ce2/ce3 after combination pass. It is tested on x86/thumb2 for both normal and Os. Is it ok for trunk? There are bound to be target and application specific variations on which scaling factors work best. 2013-03-25 Bin Cheng bin.ch...@arm.com * ifcvt.c (ifcvt_after_combine): New static variable. It would make more sense to pass in the scale factor as a an argument to if_convert. And get the respective values from a set of gcc parameters, so they can be tweaked by ports and/or by a user/ML learning framework (e.g. Milepost) supplying the appropriate --param option. I agree it would be more flexible to pass the factor as parameter, but not sure how useful to users it will be because: firstly it has already been target specific by the BRANCH_COST heuristic; for code size, the heuristic should be tuned to achieve an overall good results, I doubt to which extend it depends on specific target/application. Hi Jeff, This is based on your heuristic tuning in ifcvt, would you help us on this issue with some suggestions? Ping.
RE: [PATCH GCC/pr56124] Don't prefer memory if the source of load operation has side effect
-Original Message- From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] On Behalf Of Bin Cheng Sent: Monday, March 25, 2013 3:15 PM To: gcc-patches@gcc.gnu.org Subject: FW: [PATCH GCC/pr56124] Don't prefer memory if the source of load operation has side effect Sorry for the wrong list. -Original Message- From: Bin Cheng [mailto:bin.ch...@arm.com] Sent: Monday, March 25, 2013 3:00 PM To: g...@gcc.gnu.org Subject: [PATCH GCC/pr56124] Don't prefer memory if the source of load operation has side effect Hi, As reported in PR56124, IRA causes redundant reload by preferring to put pseudo which is target of loading in memory. Generally this is good but the case in which the src of loading has side effect. This patch fixes this issue by checking whether source of loading has side effect. I tested the patch on x86/thumb2. Is it OK? Thanks. 2013-03-25 Bin Cheng bin.ch...@arm.com PR target/56124 * ira-costs.c (scan_one_insn): Check whether the source rtx of loading has side effect. Ping.
