Re: [PATCH] Introducing SAD (Sum of Absolute Differences) operation to GCC vectorizer.
On Fri, Nov 1, 2013 at 3:03 AM, Cong Hou co...@google.com wrote:
According to your comments, I made the following modifications to this patch:
1. Now SAD pattern does not require the first and second operands to
be unsigned. And two versions (signed/unsigned) of the SAD optabs are
defined: usad_optab and ssad_optab.
2. Use expand_simple_binop instead of gen_rtx_PLUS to generate the
plus expression in sse.md. Also change the type of the second/third
operands to be nonimmediate_operand.
3. Add the document for SAD_EXPR.
4. Verify the operands of SAD_EXPR.
5. Create a new target: vect_usad_char, and use it in the test case.
The updated patch is pasted below.
+(define_expand usadv16qi
+ [(match_operand:V4SI 0 register_operand)
+ (match_operand:V16QI 1 register_operand)
+ (match_operand:V16QI 2 nonimmediate_operand)
+ (match_operand:V4SI 3 nonimmediate_operand)]
+ TARGET_SSE2
+{
+ rtx t1 = gen_reg_rtx (V2DImode);
+ rtx t2 = gen_reg_rtx (V4SImode);
+ emit_insn (gen_sse2_psadbw (t1, operands[1], operands[2]));
+ convert_move (t2, t1, 0);
+ emit_insn (gen_rtx_SET (VOIDmode, operands[0],
+ expand_simple_binop (V4SImode, PLUS, t2, operands[3],
+ NULL, 0, OPTAB_DIRECT)));
It seems to me that generic expander won't bring any benefit there,
operands are already in correct form, so please change the last lines
simply to:
emit_insn (gen_addv4si3 (operands[0], t2, operands[3]));
+ DONE;
+})
+
+(define_expand usadv32qi
+ [(match_operand:V8SI 0 register_operand)
+ (match_operand:V32QI 1 register_operand)
+ (match_operand:V32QI 2 nonimmediate_operand)
+ (match_operand:V8SI 3 nonimmediate_operand)]
+ TARGET_AVX2
+{
+ rtx t1 = gen_reg_rtx (V4DImode);
+ rtx t2 = gen_reg_rtx (V8SImode);
+ emit_insn (gen_avx2_psadbw (t1, operands[1], operands[2]));
+ convert_move (t2, t1, 0);
+ emit_insn (gen_rtx_SET (VOIDmode, operands[0],
+ expand_simple_binop (V8SImode, PLUS, t2, operands[3],
+ NULL, 0, OPTAB_DIRECT)));
Same here, using gen_addv8si3.
No need to repost the patch with this trivial change.
Sorry for the confusion,
Uros.
[PATCH, i386]: Change HAVE_AS_IX86_INTERUNIT_MOVQ to runtime test ...
Hello!
... so it can be used in insn output templates.
2013-11-01 Uros Bizjak ubiz...@gmail.com
* configure.ac (HAVE_AS_IX86_INTERUNIT_MOVQ): Always define as 0/1.
* configure: Regenerate.
* config/i386/i386.md (*movdi_internal): Change
HAVE_AS_IX86_INTERUNIT_MOVQ to runtime check.
(*movdf_internal): Ditto.
* config/i386/mmx.md (*movmode_internal): Ditto.
* config/i386/sse.md (vec_concatv2di): Output interunit movq
for HAVE_AS_IX86_INTERUNIT_MOVQ targets.
Tested on x86_64-pc-linux-gnu {,-m32} and committed to mainline SVN.
Uros.
Index: config/i386/i386.md
===
--- config/i386/i386.md (revision 204286)
+++ config/i386/i386.md (working copy)
@@ -2007,11 +2007,10 @@
return pxor\t%0, %0;
case TYPE_MMXMOV:
-#ifndef HAVE_AS_IX86_INTERUNIT_MOVQ
/* Handle broken assemblers that require movd instead of movq. */
- if (GENERAL_REG_P (operands[0]) || GENERAL_REG_P (operands[1]))
+ if (!HAVE_AS_IX86_INTERUNIT_MOVQ
+ (GENERAL_REG_P (operands[0]) || GENERAL_REG_P (operands[1])))
return movd\t{%1, %0|%0, %1};
-#endif
return movq\t{%1, %0|%0, %1};
case TYPE_SSELOG1:
@@ -2024,11 +2023,10 @@
switch (get_attr_mode (insn))
{
case MODE_DI:
-#ifndef HAVE_AS_IX86_INTERUNIT_MOVQ
/* Handle broken assemblers that require movd instead of movq. */
- if (GENERAL_REG_P (operands[0]) || GENERAL_REG_P (operands[1]))
+ if (!HAVE_AS_IX86_INTERUNIT_MOVQ
+ (GENERAL_REG_P (operands[0]) || GENERAL_REG_P (operands[1])))
return %vmovd\t{%1, %0|%0, %1};
-#endif
return %vmovq\t{%1, %0|%0, %1};
case MODE_TI:
return %vmovdqa\t{%1, %0|%0, %1};
@@ -2944,12 +2942,11 @@
return movlpd\t{%1, %0|%0, %1};
case MODE_DI:
-#ifndef HAVE_AS_IX86_INTERUNIT_MOVQ
/* Handle broken assemblers that require movd instead of movq. */
- if (GENERAL_REG_P (operands[0]) || GENERAL_REG_P (operands[1]))
+ if (!HAVE_AS_IX86_INTERUNIT_MOVQ
+ (GENERAL_REG_P (operands[0]) || GENERAL_REG_P (operands[1])))
return %vmovd\t{%1, %0|%0, %1};
-#endif
- return %vmovq\t{%1, %0|%0, %1};
+ return %vmovq\t{%1, %0|%0, %1};
default:
gcc_unreachable ();
Index: config/i386/mmx.md
===
--- config/i386/mmx.md (revision 204286)
+++ config/i386/mmx.md (working copy)
@@ -99,11 +99,10 @@
return pxor\t%0, %0;
case TYPE_MMXMOV:
-#ifndef HAVE_AS_IX86_INTERUNIT_MOVQ
/* Handle broken assemblers that require movd instead of movq. */
- if (GENERAL_REG_P (operands[0]) || GENERAL_REG_P (operands[1]))
+ if (!HAVE_AS_IX86_INTERUNIT_MOVQ
+ (GENERAL_REG_P (operands[0]) || GENERAL_REG_P (operands[1])))
return movd\t{%1, %0|%0, %1};
-#endif
return movq\t{%1, %0|%0, %1};
case TYPE_SSECVT:
@@ -119,15 +118,13 @@
switch (get_attr_mode (insn))
{
case MODE_DI:
-#ifndef HAVE_AS_IX86_INTERUNIT_MOVQ
/* Handle broken assemblers that require movd instead of movq. */
- if (GENERAL_REG_P (operands[0]) || GENERAL_REG_P (operands[1]))
+ if (!HAVE_AS_IX86_INTERUNIT_MOVQ
+ (GENERAL_REG_P (operands[0]) || GENERAL_REG_P (operands[1])))
return %vmovd\t{%1, %0|%0, %1};
-#endif
return %vmovq\t{%1, %0|%0, %1};
case MODE_TI:
return %vmovdqa\t{%1, %0|%0, %1};
-
case MODE_XI:
return vmovdqa64\t{%g1, %g0|%g0, %g1};
Index: config/i386/sse.md
===
--- config/i386/sse.md (revision 204286)
+++ config/i386/sse.md (working copy)
@@ -9489,7 +9489,7 @@
@
pinsrq\t{$1, %2, %0|%0, %2, 1}
vpinsrq\t{$1, %2, %1, %0|%0, %1, %2, 1}
- %vmovd\t{%1, %0|%0, %1}
+ * return HAVE_AS_IX86_INTERUNIT_MOVQ ? \%vmovq\t{%1, %0|%0, %1}\ :
\%vmovd\t{%1, %0|%0, %1}\;
%vmovq\t{%1, %0|%0, %1}
movq2dq\t{%1, %0|%0, %1}
punpcklqdq\t{%2, %0|%0, %2}
Index: configure.ac
===
--- configure.ac(revision 204286)
+++ configure.ac(working copy)
@@ -3754,9 +3754,10 @@
gcc_cv_as_ix86_interunit_movq,,,
[.code64
movq %mm0, %rax
- movq %rax, %xmm0],,
- [AC_DEFINE(HAVE_AS_IX86_INTERUNIT_MOVQ, 1,
-[Define if your assembler supports interunit movq mnemonic.])])
+ movq %rax, %xmm0])
+AC_DEFINE_UNQUOTED(HAVE_AS_IX86_INTERUNIT_MOVQ,
+ [`if test $gcc_cv_as_ix86_interunit_movq = yes; then echo 1; else echo
0; fi`],
+ [Define if your assembler supports interunit movq mnemonic.])
gcc_GAS_CHECK_FEATURE([hle prefixes],
gcc_cv_as_ix86_hle,,,
[wide-int] Avoid some changes in output code
I'm building one target for each supported CPU and comparing the wide-int
assembly output of gcc.c-torture, gcc.dg and g++.dg with the corresponding
output from the merge point. This patch removes all the differences I saw
for alpha-linux-gnu in gcc.c-torture.
Hunk 1: Preserve the current trunk behaviour in which the shift count
is truncated if SHIFT_COUNT_TRUNCATED and not otherwise. This was by
inspection after hunk 5.
Hunks 2 and 3: Two cases where force_fit_to_type could extend to wider
types and where we weren't extending according to the sign of the source.
We should probably assert that the input is at least as wide as the type...
Hunk 4: The in:
if ((TREE_INT_CST_HIGH (arg1) mask_hi) == mask_hi
(TREE_INT_CST_LOW (arg1) mask_lo) == mask_lo)
had got dropped during the conversion.
Hunk 5: The old code was:
if (shift 0)
{
*mask = r1mask.llshift (shift, TYPE_PRECISION (type));
*val = r1val.llshift (shift, TYPE_PRECISION (type));
}
else if (shift 0)
{
shift = -shift;
*mask = r1mask.rshift (shift, TYPE_PRECISION (type), !uns);
*val = r1val.rshift (shift, TYPE_PRECISION (type), !uns);
}
and these precision arguments had two purposes: to control which
bits of the first argument were shifted, and to control the truncation
mask for SHIFT_TRUNCATED. We need to pass a width to the shift functions
for the second.
(BTW, I'm running the comparisons with CONST_WIDE_INT locally moved to the
end of the !GENERATOR_FILE list in rtl.def, since the current position caused
some spurious differences. The problem AFAICT is that hash_rtx hashes
on code, RTL PRE creates registers in the hash order of the associated
expressions, RA uses register numbers as a tie-breaker during ordering,
and so the order of rtx_code can indirectly influence register allocation.
First time I'd realised that could happen, so just thought I'd mention it.
I think we should keep rtl.def in the current (logical) order though.)
Tested on x86_64-linux-gnu and powerpc64-linux-gnu. OK for wide-int?
Thanks,
Richard
Index: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 204247)
+++ gcc/fold-const.c(working copy)
@@ -1008,9 +1008,12 @@
The following code ignores overflow; perhaps a C standard
interpretation ruling is needed. */
res = wi::rshift (arg1, arg2, sign,
- GET_MODE_BITSIZE (TYPE_MODE (type)));
+ SHIFT_COUNT_TRUNCATED
+ ? GET_MODE_BITSIZE (TYPE_MODE (type)) : 0);
else
- res = wi::lshift (arg1, arg2, GET_MODE_BITSIZE (TYPE_MODE (type)));
+ res = wi::lshift (arg1, arg2,
+ SHIFT_COUNT_TRUNCATED
+ ? GET_MODE_BITSIZE (TYPE_MODE (type)) : 0);
break;
case RROTATE_EXPR:
@@ -6870,7 +6873,8 @@
return NULL_TREE;
if (TREE_CODE (arg1) == INTEGER_CST)
-arg1 = force_fit_type (inner_type, arg1, 0, TREE_OVERFLOW (arg1));
+arg1 = force_fit_type (inner_type, wi::to_widest (arg1), 0,
+ TREE_OVERFLOW (arg1));
else
arg1 = fold_convert_loc (loc, inner_type, arg1);
@@ -8081,7 +8085,8 @@
}
if (change)
{
- tem = force_fit_type (type, and1, 0, TREE_OVERFLOW (and1));
+ tem = force_fit_type (type, wi::to_widest (and1), 0,
+ TREE_OVERFLOW (and1));
return fold_build2_loc (loc, BIT_AND_EXPR, type,
fold_convert_loc (loc, type, and0), tem);
}
@@ -14098,12 +14103,13 @@
(inner_width, outer_width - inner_width, false,
TYPE_PRECISION (TREE_TYPE (arg1)));
- if (mask == arg1)
+ wide_int common = mask arg1;
+ if (common == mask)
{
tem_type = signed_type_for (TREE_TYPE (tem));
tem = fold_convert_loc (loc, tem_type, tem);
}
- else if ((mask arg1) == 0)
+ else if (common == 0)
{
tem_type = unsigned_type_for (TREE_TYPE (tem));
tem = fold_convert_loc (loc, tem_type, tem);
Index: gcc/tree-ssa-ccp.c
===
--- gcc/tree-ssa-ccp.c (revision 204247)
+++ gcc/tree-ssa-ccp.c (working copy)
@@ -1238,15 +1238,20 @@
else
code = RSHIFT_EXPR;
}
+ int shift_precision = SHIFT_COUNT_TRUNCATED ? width : 0;
if (code == RSHIFT_EXPR)
{
- *mask = wi::rshift (wi::ext (r1mask, width, sgn), shift, sgn);
- *val = wi::rshift (wi::ext (r1val, width, sgn), shift,
Re: [PATCH] Introducing SAD (Sum of Absolute Differences) operation to GCC vectorizer.
On Fri, Nov 01, 2013 at 02:03:52AM +, Cong Hou wrote: 3. Add the document for SAD_EXPR. I think this patch should also document the new Standard Names usad and ssad in doc/md.texi? Your Changelog is missing the change to doc/generic.texi. Thanks, James
Re: RFC: simd enabled functions (omp declare simd / elementals)
Hi!
On Thu, Oct 31, 2013 at 10:04:45PM -0500, Aldy Hernandez wrote:
Hello gentlemen. I'm CCing all of you, because each of you can
provide valuable feedback to various parts of the compiler which I
touch. I have sprinkled love notes with your names throughout the
post :).
Thanks for working on this.
* Makefile.in (omp-low.o): Depend on PRETTY_PRINT_H and IPA_PROP_H.
You aren't changing Makefile.in anymore ;).
+/* Given a NODE, return a compatible SIMD clone returning `vectype'.
+ If none found, NULL is returned. */
+
+struct cgraph_node *
+get_simd_clone (struct cgraph_node *node, tree vectype)
+{
+ if (!node-has_simd_clones)
+return NULL;
+
+ /* FIXME: What to do with linear/uniform arguments. */
+
+ /* FIXME: Nasty kludge until we figure out where to put the clone
+ list-- perhaps, next_sibling_clone/prev_sibling_clone in
+ cgraph_node ??. */
+ struct cgraph_node *t;
+ FOR_EACH_FUNCTION (t)
+if (t-simdclone_of == node
+ /* No inbranch vectorization for now. */
+ !t-simdclone-inbranch
+ types_compatible_p (TREE_TYPE (TREE_TYPE (t-symbol.decl)),
+vectype))
+ break;
+ return t;
+}
You definitely need some quick way to find the simd clones, and you really
can't do this here anyway, because you have to check all arguments, return
type might be missing etc., so it needs to be done by vectorizable_call
itself.
+ /* If this is a SIMD clone, this points to the SIMD specific
+ information for it. */
+ struct simd_clone *simdclone;
+
+ /* If this is a SIMD clone, this points to the original scalar
+ function. */
+ struct cgraph_node *simdclone_of;
Can't you put this into the simd_clone structure, in order not to waste
memory for functions which don't have simd clones? So, you'd use
t-simdclone t-simdclone-clone_of == node or similar (if you need it at
all, I guess better is to add a struct cgraph_node *simd_clones;
and put the prev/next pointers in struct simd_clone).
Let me start with two testcases:
test1.c:
int array[1000];
#pragma omp declare simd simdlen(4) notinbranch
#pragma omp declare simd simdlen(4) notinbranch uniform(b)
#pragma omp declare simd simdlen(8) notinbranch
#pragma omp declare simd simdlen(8) notinbranch uniform(b)
__attribute__((noinline)) int
foo (int a, int b)
{
if (a == b)
return 5;
else
return 6;
}
void
bar ()
{
int i;
for (i = 0; i 1000; ++i)
array[i] = foo (i, 123);
for (i = 0; i 1000; ++i)
array[i] = foo (i, array[i]);
}
test2.c:
int array[1000];
#pragma omp declare simd simdlen(4) notinbranch aligned(a:16) uniform(a)
linear(b)
#pragma omp declare simd simdlen(4) notinbranch aligned(a:32) uniform(a)
linear(b)
#pragma omp declare simd simdlen(8) notinbranch aligned(a:16) uniform(a)
linear(b)
#pragma omp declare simd simdlen(8) notinbranch aligned(a:32) uniform(a)
linear(b)
__attribute__((noinline)) void
foo (int *a, int b, int c)
{
a[b] = c;
}
void
bar ()
{
int i;
for (i = 0; i 1000; ++i)
foo (array, i, i * array[i]);
}
On test1.c -O3 -fopenmp {,-mavx,-mavx2}, you can see:
test1.c: In function ‘foo.simdclone.0’:
test1.c:8:1: note: The ABI for passing parameters with 32-byte alignment has
changed in GCC 4.6
foo (int a, int b)
^
test1.c:8:1: warning: AVX vector argument without AVX enabled changes the ABI
[enabled by default]
and the manglings are without -mavx{,2}
_ZGVxN8vu_foo
_ZGVxN8vv_foo
_ZGVxN4vu_foo
_ZGVxN4vv_foo
while with it _ZGVy* (surprisingly not Y). As discussed earlier, we don't
want to decide which clones to create based on compiler options, we probably
want to create (unless told by Cilk+ processor clauses otherwise) entry
points for all the ABIs, just try to create the ones not matching compiler
options as small as possible, and use target attribute for those too
and say for _ZGVxN8v?_foo we need to pass the vector arguments in two
vector(4) int parameters rather than one vector(8) as it is done now (that
is why the above warnings and notes are printed). But you know this
already... ;).
The second testcase currently ICEs I guess during simd cloning, just wanted
to make it clear that while simd clones without any arguments probably don't
make any sense (other than const, but those really should be hoisted out of
the loop much earlier), simd clones with no return value make sense.
--- a/gcc/tree-vect-stmts.c
+++ b/gcc/tree-vect-stmts.c
@@ -1688,6 +1688,16 @@ tree
vectorizable_function (gimple call, tree vectype_out, tree vectype_in)
{
tree fndecl = gimple_call_fndecl (call);
+ struct cgraph_node *node = cgraph_get_node (fndecl);
+
+ if (node-has_simd_clones)
+{
+ struct cgraph_node *clone = get_simd_clone (node, vectype_out);
+ if (clone)
+ return clone-symbol.decl;
+ /* Fall through in case we ever add support for
+ non-built-ins. */
+}
I think it is a bad idea to do this in vectorizable_function, as I said
earlier
[PATCH] Fix up reassoc (PR tree-optimization/58946)
Hi!
My recent reassoc patch caused following regression (though, it only started
failing on this testcase with Andrew's ifcombine changes).
The issue is that update_ops relies on walking the same stmts as get_ops
did, and uses has_single_uses (either directly or indirectly through
is_reassociable_op). optimize_range_tests itself doesn't change the IL
except for inserting new stmts using values on which get_ops already didn't
recurse (either because they were multiple uses or non-reassociable).
The problem in the testcase is when optimizing a GIMPLE_COND directly, there
is no guarantee of single use, we treat the condition as the starting point
of init_range_info and thus SSA_NAME != 0 or SSA_NAME == 0 etc. and that
is just fine if SSA_NAME has multiple uses, so if we first change the
condition to something else (as instructed by the changed ops[i]-op value
from NULL to some SSA_NAME), we might turn something update_ops looks at
from multiple uses into single use.
This patch fixes it by doing all the update_ops calls before changing
GIMPLE_CONDs themselves. I believe it is safe, update_ops will walk only
single use SSA_NAMEs and thus they occur only in the single particular
update_ops call, and never removes anything, only adds new stmt (which
can make single use SSA_NAMEs into multiple use, but that happened after
we've walked that originally single use exactly ones from the single use),
and GIMPLE_COND adjustments never use has_single_use, thus they can be
safely done after all update_ops have been called.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2013-11-01 Jakub Jelinek ja...@redhat.com
PR tree-optimization/58946
* tree-ssa-reassoc.c (maybe_optimize_range_tests): Update all
bbs with bbinfo[idx].op != NULL before all blocks with
bbinfo[idx].op == NULL.
* gcc.c-torture/compile/pr58946.c: New test.
--- gcc/tree-ssa-reassoc.c.jj 2013-10-24 10:19:21.0 +0200
+++ gcc/tree-ssa-reassoc.c 2013-11-01 09:23:09.264615181 +0100
@@ -2657,6 +2657,7 @@ maybe_optimize_range_tests (gimple stmt)
edge e;
vecoperand_entry_t ops = vNULL;
vecinter_bb_range_test_entry bbinfo = vNULL;
+ bool any_changes = false;
/* Consider only basic blocks that end with GIMPLE_COND or
a cast statement satisfying final_range_test_p. All
@@ -2870,41 +2871,31 @@ maybe_optimize_range_tests (gimple stmt)
break;
}
if (ops.length () 1)
+any_changes = optimize_range_tests (ERROR_MARK, ops);
+ if (any_changes)
{
unsigned int idx;
- bool any_changes = optimize_range_tests (ERROR_MARK, ops);
- for (bb = last_bb, idx = 0; any_changes; bb = single_pred (bb), idx++)
+ /* update_ops relies on has_single_use predicates returning the
+same values as it did during get_ops earlier. Additionally it
+never removes statements, only adds new ones and it should walk
+from the single imm use and check the predicate already before
+making those changes.
+On the other side, the handling of GIMPLE_COND directly can turn
+previously multiply used SSA_NAMEs into single use SSA_NAMEs, so
+it needs to be done in a separate loop afterwards. */
+ for (bb = last_bb, idx = 0; ; bb = single_pred (bb), idx++)
{
- if (bbinfo[idx].first_idx bbinfo[idx].last_idx)
+ if (bbinfo[idx].first_idx bbinfo[idx].last_idx
+ bbinfo[idx].op != NULL_TREE)
{
- gimple stmt = last_stmt (bb);
tree new_op;
- if (bbinfo[idx].op == NULL_TREE)
- {
- if (ops[bbinfo[idx].first_idx]-op != NULL_TREE)
- {
- if (integer_zerop (ops[bbinfo[idx].first_idx]-op))
- gimple_cond_make_false (stmt);
- else if (integer_onep (ops[bbinfo[idx].first_idx]-op))
- gimple_cond_make_true (stmt);
- else
- {
- gimple_cond_set_code (stmt, NE_EXPR);
- gimple_cond_set_lhs (stmt,
- ops[bbinfo[idx].first_idx]-op);
- gimple_cond_set_rhs (stmt, boolean_false_node);
- }
- update_stmt (stmt);
- }
- bbinfo[idx].op = new_op = boolean_false_node;
- }
- else
- new_op = update_ops (bbinfo[idx].op,
-(enum tree_code)
-ops[bbinfo[idx].first_idx]-rank,
-ops, bbinfo[idx].first_idx,
-loop_containing_stmt (stmt));
+ stmt = last_stmt (bb);
+ new_op = update_ops (bbinfo[idx].op,
+ (enum tree_code)
+
[v3 patch] Implement N3421 - make functors greater
This implements another piece of the C++14 library, STL's transparent
functors proposal. I also added the is_transparent typedefs, which
come from another proposal but modify these diamond operators. I
hope to get round to using those typedefs to implement Joaquin's
heterogeneous lookup soon.
2013-11-01 Jonathan Wakely jwakely@gmail.com
N3421 C++1y Transparent functors
* include/bits/stl_function.h (plusvoid, minusvoid,
multipliesvoid, dividesvoid, modulusvoid, negatevoid,
equal_tovoid, not_equal_tovoid, greatervoid, lessvoid,
greater_equalvoid, less_equalvoid, logical_andvoid,
logical_orvoid, logical_notvoid, bit_andvoid, bit_orvoid,
bit_xorvoid, bit_notvoid): Define.
* doc/xml/manual/status_cxx2014.xml: Update.
* testsuite/20_util/function_objects/comparisons_void.cc: New.
Tested x86_64-linux, committed to trunk.
commit 8382a58b1ba77be9f575caad84506362b2c87ad1
Author: Jonathan Wakely jwakely@gmail.com
Date: Tue May 21 08:55:24 2013 +0100
N3421 C++1y Transparent functors
* include/bits/stl_function.h (plusvoid, minusvoid,
multipliesvoid, dividesvoid, modulusvoid, negatevoid,
equal_tovoid, not_equal_tovoid, greatervoid, lessvoid,
greater_equalvoid, less_equalvoid, logical_andvoid,
logical_orvoid, logical_notvoid, bit_andvoid, bit_orvoid,
bit_xorvoid, bit_notvoid): Define.
* doc/xml/manual/status_cxx2014.xml: Update.
* testsuite/20_util/function_objects/comparisons_void.cc: New.
* include/bits/stl_function.h: Implement N3421.
* testsuite/20_util/function_objects/comparisons_void.cc: New.
diff --git a/libstdc++-v3/doc/xml/manual/status_cxx2014.xml
b/libstdc++-v3/doc/xml/manual/status_cxx2014.xml
index 4ef4334..b368a81 100644
--- a/libstdc++-v3/doc/xml/manual/status_cxx2014.xml
+++ b/libstdc++-v3/doc/xml/manual/status_cxx2014.xml
@@ -209,7 +209,7 @@ particular release.
/link
/entry
entryMaking Operator Functors greaterlt;gt;/entry
- entryWIP/entry
+ entryY/entry
entry/
/row
diff --git a/libstdc++-v3/include/bits/stl_function.h
b/libstdc++-v3/include/bits/stl_function.h
index 23529df..d2e5d13 100644
--- a/libstdc++-v3/include/bits/stl_function.h
+++ b/libstdc++-v3/include/bits/stl_function.h
@@ -56,6 +56,10 @@
#ifndef _STL_FUNCTION_H
#define _STL_FUNCTION_H 1
+#if __cplusplus 201103L
+#include bits/move.h
+#endif
+
namespace std _GLIBCXX_VISIBILITY(default)
{
_GLIBCXX_BEGIN_NAMESPACE_VERSION
@@ -135,6 +139,29 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
*
* @{
*/
+
+#if __cplusplus 201103L
+ struct __is_transparent; // undefined
+
+ templatetypename _Tp = void
+struct plus;
+
+ templatetypename _Tp = void
+struct minus;
+
+ templatetypename _Tp = void
+struct multiplies;
+
+ templatetypename _Tp = void
+struct divides;
+
+ templatetypename _Tp = void
+struct modulus;
+
+ templatetypename _Tp = void
+struct negate;
+#endif
+
/// One of the @link arithmetic_functors math functors@endlink.
templatetypename _Tp
struct plus : public binary_function_Tp, _Tp, _Tp
@@ -188,6 +215,91 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
operator()(const _Tp __x) const
{ return -__x; }
};
+
+#if __cplusplus 201103L
+ template
+struct plusvoid
+{
+ template typename _Tp, typename _Up
+ auto
+ operator()(_Tp __t, _Up __u) const
+ noexcept(noexcept(std::forward_Tp(__t) + std::forward_Up(__u)))
+ - decltype(std::forward_Tp(__t) + std::forward_Up(__u))
+ { return std::forward_Tp(__t) + std::forward_Up(__u); }
+
+ typedef __is_transparent is_transparent;
+};
+
+ /// One of the @link arithmetic_functors math functors@endlink.
+ template
+struct minusvoid
+{
+ template typename _Tp, typename _Up
+ auto
+ operator()(_Tp __t, _Up __u) const
+ noexcept(noexcept(std::forward_Tp(__t) - std::forward_Up(__u)))
+ - decltype(std::forward_Tp(__t) - std::forward_Up(__u))
+ { return std::forward_Tp(__t) - std::forward_Up(__u); }
+
+ typedef __is_transparent is_transparent;
+};
+
+ /// One of the @link arithmetic_functors math functors@endlink.
+ template
+struct multipliesvoid
+{
+ template typename _Tp, typename _Up
+ auto
+ operator()(_Tp __t, _Up __u) const
+ noexcept(noexcept(std::forward_Tp(__t) * std::forward_Up(__u)))
+ - decltype(std::forward_Tp(__t) * std::forward_Up(__u))
+ { return std::forward_Tp(__t) * std::forward_Up(__u); }
+
+ typedef __is_transparent is_transparent;
+};
+
+ /// One of the @link arithmetic_functors math functors@endlink.
+ template
+struct dividesvoid
+{
+ template typename _Tp, typename _Up
+ auto
+ operator()(_Tp __t, _Up __u) const
+ noexcept(noexcept(std::forward_Tp(__t) / std::forward_Up(__u)))
+ -
[v3] libstdc++/58952
Hi, a simple, very old, oversight. Committed mainline and 4_8-branch. Thanks, Paolo. // 2013-11-01 Paolo Carlini paolo.carl...@oracle.com PR libstdc++/58952 * include/c_global/cstdio: Undef getchar. Index: include/c_global/cstdio === --- include/c_global/cstdio (revision 204289) +++ include/c_global/cstdio (working copy) @@ -69,6 +69,7 @@ #undef ftell #undef fwrite #undef getc +#undef getchar #if __cplusplus = 201103L # undef gets #endif
Re: [v3 patch] Implement N3421 - make functors greater
On Fri, 1 Nov 2013, Jonathan Wakely wrote:
2013-11-01 Jonathan Wakely jwakely@gmail.com
N3421 C++1y Transparent functors
* include/bits/stl_function.h (plusvoid, minusvoid,
multipliesvoid, dividesvoid, modulusvoid, negatevoid,
equal_tovoid, not_equal_tovoid, greatervoid, lessvoid,
greater_equalvoid, less_equalvoid, logical_andvoid,
logical_orvoid, logical_notvoid, bit_andvoid, bit_orvoid,
bit_xorvoid, bit_notvoid): Define.
Thanks. Why use noexcept for everything except logical_not?
I noticed recently that the following worked, it will be convenient now we
have those functors (for my own code, not the STL):
templatetypename RandomAccessIterator, typename Compare = std::lessvoid
void sort(RandomAccessIterator first, RandomAccessIterator last,
Compare comp = {});
--
Marc Glisse
Re: [v3 patch] Implement N3421 - make functors greater
On 1 November 2013 11:28, Marc Glisse wrote:
On Fri, 1 Nov 2013, Jonathan Wakely wrote:
2013-11-01 Jonathan Wakely jwakely@gmail.com
N3421 C++1y Transparent functors
* include/bits/stl_function.h (plusvoid, minusvoid,
multipliesvoid, dividesvoid, modulusvoid, negatevoid,
equal_tovoid, not_equal_tovoid, greatervoid, lessvoid,
greater_equalvoid, less_equalvoid, logical_andvoid,
logical_orvoid, logical_notvoid, bit_andvoid, bit_orvoid,
bit_xorvoid, bit_notvoid): Define.
Thanks. Why use noexcept for everything except logical_not?
Oops, because the regex I used to add noexcept only matched a
trailing-return-type on a line by itself, and I missed that one. I'll
fix it now, thanks!
I noticed recently that the following worked, it will be convenient now we
have those functors (for my own code, not the STL):
templatetypename RandomAccessIterator, typename Compare = std::lessvoid
void sort(RandomAccessIterator first, RandomAccessIterator last,
Compare comp = {});
Nice :)
Re: [v3 patch] Implement N3421 - make functors greater
On 1 November 2013 11:48, Jonathan Wakely wrote:
On 1 November 2013 11:28, Marc Glisse wrote:
On Fri, 1 Nov 2013, Jonathan Wakely wrote:
2013-11-01 Jonathan Wakely jwakely@gmail.com
N3421 C++1y Transparent functors
* include/bits/stl_function.h (plusvoid, minusvoid,
multipliesvoid, dividesvoid, modulusvoid, negatevoid,
equal_tovoid, not_equal_tovoid, greatervoid, lessvoid,
greater_equalvoid, less_equalvoid, logical_andvoid,
logical_orvoid, logical_notvoid, bit_andvoid, bit_orvoid,
bit_xorvoid, bit_notvoid): Define.
Thanks. Why use noexcept for everything except logical_not?
Oops, because the regex I used to add noexcept only matched a
trailing-return-type on a line by itself, and I missed that one. I'll
fix it now, thanks!
Like so:
2013-11-01 Jonathan Wakely jwakely@gmail.com
* include/bits/stl_function.h (logical_notvoid): Add noexcept.
Tested x86_64-linux, committed to trunk. Thanks to Marc for checking it.
commit a4d1b5296bb21fc8b522702c17c34098bfea36b7
Author: Jonathan Wakely jwakely@gmail.com
Date: Fri Nov 1 11:50:22 2013 +
* include/bits/stl_function.h (logical_notvoid): Add noexcept.
diff --git a/libstdc++-v3/include/bits/stl_function.h
b/libstdc++-v3/include/bits/stl_function.h
index d2e5d13..e5eed06 100644
--- a/libstdc++-v3/include/bits/stl_function.h
+++ b/libstdc++-v3/include/bits/stl_function.h
@@ -554,7 +554,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
{
template typename _Tp
auto
- operator()(_Tp __t) const - decltype(!std::forward_Tp(__t))
+ operator()(_Tp __t) const
+ noexcept(noexcept(!std::forward_Tp(__t)))
+ - decltype(!std::forward_Tp(__t))
{ return !std::forward_Tp(__t); }
typedef __is_transparent is_transparent;
Re: RFC: simd enabled functions (omp declare simd / elementals)
Hi!
One more thing:
On Thu, Oct 31, 2013 at 10:04:45PM -0500, Aldy Hernandez wrote:
+enum linear_stride_type {
+ LINEAR_STRIDE_NO,
+ LINEAR_STRIDE_YES_CONSTANT,
+ LINEAR_STRIDE_YES_VARIABLE
+};
...
+ /* If the linear stride is a constant, `linear_stride' is
+ LINEAR_STRIDE_YES_CONSTANT, and `linear_stride_num' holds
+ the numeric stride.
+
+ If the linear stride is variable, `linear_stride' is
+ LINEAR_STRIDE_YES_VARIABLE, and `linear_stride_num' contains
+ the function argument containing the stride (as an index into the
+ function arguments starting at 0).
+
+ Otherwise, `linear_stride' is LINEAR_STRIDE_NO and
+ `linear_stride_num' is unused. */
+ enum linear_stride_type linear_stride;
+ unsigned HOST_WIDE_INT linear_stride_num;
+
+ /* Variable alignment if available, otherwise 0. */
+ unsigned int alignment;
+
+ /* True if variable is uniform. */
+ unsigned int uniform : 1;
+};
At least the OpenMP standard disallows one argument to be both
uniform and linear (but, apparently I forgot to diagnose, fixed thusly,
committed to trunk), and even if Cilk+ didn't disallow it explicitly,
linear together with uniform doesn't make sense (unless we consider
uniform a special case of linear with step 0). The Intel mangling PDF
doesn't allow the same argument to be both uniform and linear either.
So, IMHO much better would be to have an enum simd_clone_arg_type which
would be
enum simd_clone_arg_type
{
SIMD_CLONE_ARG_TYPE_VECTOR,
SIMD_CLONE_ARG_TYPE_UNIFORM,
SIMD_CLONE_ARG_TYPE_LINEAR_CONSTANT_STEP,
SIMD_CLONE_ARG_TYPE_LINEAR_VARIABLE_STEP
};
drop uniform bitfield, change linear_stride_num to
say union { unsigned HOST_WIDE_INT linear_constant_step; int linear_step_argno;
};
or similar.
2013-11-01 Jakub Jelinek ja...@redhat.com
* c-typeck.c (c_finish_omp_clauses) case OMP_CLAUSE_UNIFORM: Go to
check_dup_generic at the end, unless remove is true.
(c_finish_omp_clauses) case OMP_CLAUSE_REDUCTION: Add break; after
remove = true;.
(c_finish_omp_clauses) case OMP_CLAUSE_COPYIN: Likewise.
* semantics.c (finish_omp_clauses) case OMP_CLAUSE_UNIFORM: Go to
check_dup_generic at the end, unless remove is true.
(finish_omp_clauses) case OMP_CLAUSE_LINEAR: Add break; after
remove = true;.
* gcc.dg/gomp/declare-simd-2.c (f12, f13, f14, f15, f16, f17): New
tests.
* g++.dg/gomp/declare-simd-2.C (f15, f16, f17, f18, f19, f20): New
tests.
--- gcc/c/c-typeck.c.jj 2013-10-31 20:05:44.0 +0100
+++ gcc/c/c-typeck.c2013-11-01 13:07:20.330051746 +0100
@@ -11316,6 +11316,7 @@ c_finish_omp_clauses (tree clauses)
%qE has invalid type for %reduction(%s)%,
t, r_name);
remove = true;
+ break;
}
}
else if (OMP_CLAUSE_REDUCTION_PLACEHOLDER (c) == error_mark_node)
@@ -11323,6 +11324,7 @@ c_finish_omp_clauses (tree clauses)
error_at (OMP_CLAUSE_LOCATION (c),
user defined reduction not found for %qD, t);
remove = true;
+ break;
}
else if (OMP_CLAUSE_REDUCTION_PLACEHOLDER (c))
{
@@ -11406,6 +11408,7 @@ c_finish_omp_clauses (tree clauses)
error_at (OMP_CLAUSE_LOCATION (c),
%qE must be %threadprivate% for %copyin%, t);
remove = true;
+ break;
}
goto check_dup_generic;
@@ -11615,8 +11618,9 @@ c_finish_omp_clauses (tree clauses)
error_at (OMP_CLAUSE_LOCATION (c),
%qE is not an argument in %uniform% clause, t);
remove = true;
+ break;
}
- break;
+ goto check_dup_generic;
case OMP_CLAUSE_NOWAIT:
if (copyprivate_seen)
--- gcc/cp/semantics.c.jj 2013-10-31 20:05:44.0 +0100
+++ gcc/cp/semantics.c 2013-11-01 13:10:29.006068213 +0100
@@ -5188,12 +5188,16 @@ finish_omp_clauses (tree clauses)
if (t == NULL_TREE)
t = integer_one_node;
if (t == error_mark_node)
- remove = true;
+ {
+ remove = true;
+ break;
+ }
else if (!type_dependent_expression_p (t)
!INTEGRAL_TYPE_P (TREE_TYPE (t)))
{
error (linear step expression must be integral);
remove = true;
+ break;
}
else
{
@@ -5210,7 +5214,10 @@ finish_omp_clauses (tree clauses)
MINUS_EXPR, sizetype, t,
OMP_CLAUSE_DECL (c));
if (t == error_mark_node)
- remove = true;
+ {
+ remove = true;
+
Re: [wide-int] Avoid some changes in output code
On 11/01/2013 04:46 AM, Richard Sandiford wrote:
I'm building one target for each supported CPU and comparing the wide-int
assembly output of gcc.c-torture, gcc.dg and g++.dg with the corresponding
output from the merge point. This patch removes all the differences I saw
for alpha-linux-gnu in gcc.c-torture.
Hunk 1: Preserve the current trunk behaviour in which the shift count
is truncated if SHIFT_COUNT_TRUNCATED and not otherwise. This was by
inspection after hunk 5.
i used to do this inside of wide-int so that i would get consistent
behavior for all clients, but i got beat up on it.
Hunks 2 and 3: Two cases where force_fit_to_type could extend to wider
types and where we weren't extending according to the sign of the source.
We should probably assert that the input is at least as wide as the type...
Hunk 4: The in:
if ((TREE_INT_CST_HIGH (arg1) mask_hi) == mask_hi
(TREE_INT_CST_LOW (arg1) mask_lo) == mask_lo)
had got dropped during the conversion.
Hunk 5: The old code was:
if (shift 0)
{
*mask = r1mask.llshift (shift, TYPE_PRECISION (type));
*val = r1val.llshift (shift, TYPE_PRECISION (type));
}
else if (shift 0)
{
shift = -shift;
*mask = r1mask.rshift (shift, TYPE_PRECISION (type), !uns);
*val = r1val.rshift (shift, TYPE_PRECISION (type), !uns);
}
and these precision arguments had two purposes: to control which
bits of the first argument were shifted, and to control the truncation
mask for SHIFT_TRUNCATED. We need to pass a width to the shift functions
for the second.
(BTW, I'm running the comparisons with CONST_WIDE_INT locally moved to the
end of the !GENERATOR_FILE list in rtl.def, since the current position caused
some spurious differences. The problem AFAICT is that hash_rtx hashes
on code, RTL PRE creates registers in the hash order of the associated
expressions, RA uses register numbers as a tie-breaker during ordering,
and so the order of rtx_code can indirectly influence register allocation.
First time I'd realised that could happen, so just thought I'd mention it.
I think we should keep rtl.def in the current (logical) order though.)
we noticed the difference and live with it, but i agree that for testing
it is useful until the branch goes in.
Tested on x86_64-linux-gnu and powerpc64-linux-gnu. OK for wide-int?
Thanks,
Richard
Index: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 204247)
+++ gcc/fold-const.c(working copy)
@@ -1008,9 +1008,12 @@
The following code ignores overflow; perhaps a C standard
interpretation ruling is needed. */
res = wi::rshift (arg1, arg2, sign,
- GET_MODE_BITSIZE (TYPE_MODE (type)));
+ SHIFT_COUNT_TRUNCATED
+ ? GET_MODE_BITSIZE (TYPE_MODE (type)) : 0);
else
- res = wi::lshift (arg1, arg2, GET_MODE_BITSIZE (TYPE_MODE (type)));
+ res = wi::lshift (arg1, arg2,
+ SHIFT_COUNT_TRUNCATED
+ ? GET_MODE_BITSIZE (TYPE_MODE (type)) : 0);
break;
case RROTATE_EXPR:
@@ -6870,7 +6873,8 @@
return NULL_TREE;
if (TREE_CODE (arg1) == INTEGER_CST)
-arg1 = force_fit_type (inner_type, arg1, 0, TREE_OVERFLOW (arg1));
+arg1 = force_fit_type (inner_type, wi::to_widest (arg1), 0,
+ TREE_OVERFLOW (arg1));
else
arg1 = fold_convert_loc (loc, inner_type, arg1);
@@ -8081,7 +8085,8 @@
}
if (change)
{
- tem = force_fit_type (type, and1, 0, TREE_OVERFLOW (and1));
+ tem = force_fit_type (type, wi::to_widest (and1), 0,
+ TREE_OVERFLOW (and1));
return fold_build2_loc (loc, BIT_AND_EXPR, type,
fold_convert_loc (loc, type, and0), tem);
}
@@ -14098,12 +14103,13 @@
(inner_width, outer_width - inner_width, false,
TYPE_PRECISION (TREE_TYPE (arg1)));
- if (mask == arg1)
+ wide_int common = mask arg1;
+ if (common == mask)
{
tem_type = signed_type_for (TREE_TYPE (tem));
tem = fold_convert_loc (loc, tem_type, tem);
}
- else if ((mask arg1) == 0)
+ else if (common == 0)
{
tem_type = unsigned_type_for (TREE_TYPE (tem));
tem = fold_convert_loc (loc, tem_type, tem);
Index: gcc/tree-ssa-ccp.c
===
--- gcc/tree-ssa-ccp.c (revision 204247)
+++ gcc/tree-ssa-ccp.c (working copy)
@@ -1238,15 +1238,20 @@
else
code = RSHIFT_EXPR;
Re: [wide-int] Avoid some changes in output code
Kenneth Zadeck zad...@naturalbridge.com writes: On 11/01/2013 04:46 AM, Richard Sandiford wrote: I'm building one target for each supported CPU and comparing the wide-int assembly output of gcc.c-torture, gcc.dg and g++.dg with the corresponding output from the merge point. This patch removes all the differences I saw for alpha-linux-gnu in gcc.c-torture. Hunk 1: Preserve the current trunk behaviour in which the shift count is truncated if SHIFT_COUNT_TRUNCATED and not otherwise. This was by inspection after hunk 5. i used to do this inside of wide-int so that i would get consistent behavior for all clients, but i got beat up on it. Right :-) SHIFT_COUNT_TRUNCATED is a bad enough interface as it is. Putting into a utility class like wide-int just makes it worse. This is something that clients _should_ think about if they want to emulate target behaviour (rather than doing natural maths). Not sure -- is the patch OK, or are you deferring judgement for now? Thanks, Richard
Re: [wide-int] Avoid some changes in output code
On 11/01/2013 09:31 AM, Richard Sandiford wrote: Kenneth Zadeck zad...@naturalbridge.com writes: On 11/01/2013 04:46 AM, Richard Sandiford wrote: I'm building one target for each supported CPU and comparing the wide-int assembly output of gcc.c-torture, gcc.dg and g++.dg with the corresponding output from the merge point. This patch removes all the differences I saw for alpha-linux-gnu in gcc.c-torture. Hunk 1: Preserve the current trunk behaviour in which the shift count is truncated if SHIFT_COUNT_TRUNCATED and not otherwise. This was by inspection after hunk 5. i used to do this inside of wide-int so that i would get consistent behavior for all clients, but i got beat up on it. Right :-) SHIFT_COUNT_TRUNCATED is a bad enough interface as it is. Putting into a utility class like wide-int just makes it worse. This is something that clients _should_ think about if they want to emulate target behaviour (rather than doing natural maths). Not sure -- is the patch OK, or are you deferring judgement for now? Thanks, Richard it is fine, sorry. kenny
Re: PR 58834: __builtin_shuffle in a template
On 10/31/2013 07:03 PM, Marc Glisse wrote: * pt.c (value_dependent_expression_p): Handle null argument. What is calling this with a null argument? The recursive call near the end of the function checks for null there. Jason
Re: PR 58834: __builtin_shuffle in a template
On Fri, 1 Nov 2013, Jason Merrill wrote: On 10/31/2013 07:03 PM, Marc Glisse wrote: * pt.c (value_dependent_expression_p): Handle null argument. What is calling this with a null argument? The recursive call near the end of the function checks for null there. See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58834 for details. It is build_x_vec_perm_expr that calls it with a null argument (when we call __builtin_shuffle with 2 arguments, it adds a NULL argument in second position). I can make it not call value_dependent_expression_p with a null argument, but it seems more general to let value_dependent_expression_p handle 0 like a number of other functions already do. -- Marc Glisse
Re: PR 58834: __builtin_shuffle in a template
On 11/01/2013 11:13 AM, Marc Glisse wrote: position). I can make it not call value_dependent_expression_p with a null argument, but it seems more general to let value_dependent_expression_p handle 0 like a number of other functions already do. OK. But the change is to type_..., not value_..., so please correct the ChangeLog entry. Jason
Re: [PATCH] Support multiline GTY markers in Doxygen filter; add unittests
On Thu, Oct 31, 2013 at 4:06 PM, David Malcolm dmalc...@redhat.com wrote:
It's possible to run GCC's sources through Doxygen by setting
INPUT_FILTER = contrib/filter_gcc_for_doxygen
within contrib/gcc.doxy and invoking doxygen on the latter file.
The script filters out various preprocessor constructs from GCC sources
before Doxygen tries to parse them.
However, as written, it works one line at-a-time, and thus can't cope
with GTY markers that span multiple lines. I added such a marker
in r204170 (symtab_node_base), and I'd like to add more such markers
(see http://gcc.gnu.org/ml/gcc-patches/2013-10/msg02703.html).
So the attached patch rewrites the filtering script to cope with multiline
GTY markers.
I'm not familiar with Perl, so I rewrote the script in Python.
I expanded the regexes for readability, and added a unit-testing suite.
I also tweaked how comments get layed with @verbatim
to avoid inconsistent indentation between the first line and subsequent
lines within a comment.
Tested with Python 2.7; you can see a sample of the output (from my
gimple-as-C++-inheritance working copy) at:
http://dmalcolm.fedorapeople.org/gcc/2013-10-31/doxygen/html/structgimple__statement__base.html
In particular, with this patch Doxygen is able to cope with the symtab
GTY marker, and thus parse the symtab class hierarchy, giving the output
viewable here:
http://dmalcolm.fedorapeople.org/gcc/2013-10-31/doxygen/html/classsymtab__node__base.html
OK for trunk?
contrib/
* filter_gcc_for_doxygen: Use filter_params.py rather than
filter_params.pl.
* filter_params.pl: Delete in favor of...
* filter_params.py: New, porting the perl script to python in
order to cope with GTY markers that span multiple lines,
tweaking the layout of comments, and adding a test suite.
---
contrib/filter_gcc_for_doxygen | 2 +-
contrib/filter_params.pl | 14 ---
contrib/filter_params.py | 191
+
3 files changed, 192 insertions(+), 15 deletions(-)
delete mode 100755 contrib/filter_params.pl
create mode 100644 contrib/filter_params.py
diff --git a/contrib/filter_gcc_for_doxygen b/contrib/filter_gcc_for_doxygen
index 3787eeb..ca1db31 100755
--- a/contrib/filter_gcc_for_doxygen
+++ b/contrib/filter_gcc_for_doxygen
@@ -8,5 +8,5 @@
# process is put on stdout.
dir=`dirname $0`
-perl $dir/filter_params.pl $1 | perl $dir/filter_knr2ansi.pl
+python $dir/filter_params.py $1 | perl $dir/filter_knr2ansi.pl
exit 0
diff --git a/contrib/filter_params.pl b/contrib/filter_params.pl
deleted file mode 100755
index 22dae6c..000
--- a/contrib/filter_params.pl
+++ /dev/null
@@ -1,14 +0,0 @@
-#!/usr/bin/perl
-
-# Filters out some of the #defines used throughout the GCC sources:
-# - GTY(()) marks declarations for gengtype.c
-# - PARAMS(()) is used for KR compatibility. See ansidecl.h.
-
-while () {
-s/^\/\* /\/\*\* \@verbatim /;
-s/\*\// \@endverbatim \*\//;
-s/GTY[ \t]*\(\(.*\)\)//g;
-s/[ \t]ATTRIBUTE_UNUSED//g;
-s/PARAMS[ \t]*\(\((.*?)\)\)/\($1\)/sg;
-print;
-}
diff --git a/contrib/filter_params.py b/contrib/filter_params.py
new file mode 100644
index 000..d5092f6
--- /dev/null
+++ b/contrib/filter_params.py
@@ -0,0 +1,191 @@
+#!/usr/bin/python
+
+Filters out some of the #defines used throughout the GCC sources:
+- GTY(()) marks declarations for gengtype.c
+- PARAMS(()) is used for KR compatibility. See ansidecl.h.
+
+When passed one or more filenames, acts on those files and prints the
+results to stdout.
+
+When run without a filename, runs a unit-testing suite.
+
+import re
+import sys
+import unittest
+
+# Optional whitespace
+opt_ws = '\s*'
+
+def filter_src(text):
+
+str - str. We operate on the whole of the source file at once
+(rather than individual lines) so that we can have multiline
+regexes.
+
+
+# First, convert tabs to spaces so that we can line things up
+# sanely.
+text = text.expandtabs(8)
Does it really matter? I thought doxygen reformatted output anyway.
+
+# Convert C comments from GNU coding convention of:
+#/* FIRST_LINE
+# NEXT_LINE
+# FINAL_LINE. */
+# to:
+#/** @verbatim
+# FIRST_LINE
+# NEXT_LINE
+# FINAL_LINE. @endverbatim */
+# so that doxygen will parse them, and so the first line
+# lines up correctly with subsequent lines.
+# Single-line comments turn from:
+#/* TEXT. */
+# into:
+#/** @verbatim
+#TEXT. @endverbatim */
Oh, for @verbatim. But, why @verbatim? One trick we could do here is
recognize ALL CAPS parameters and turn them into \p PARAM. Later on,
we just emit \param. Though I guess it would not be easy to pick up
the description. Anyway, we can think about this for later.
At the same
Re: PR 58834: __builtin_shuffle in a template
On Fri, 1 Nov 2013, Jason Merrill wrote: On 11/01/2013 11:13 AM, Marc Glisse wrote: position). I can make it not call value_dependent_expression_p with a null argument, but it seems more general to let value_dependent_expression_p handle 0 like a number of other functions already do. OK. But the change is to type_..., not value_..., so please correct the ChangeLog entry. Oops, I didn't check closely enough the output of diff -p. Thanks. -- Marc Glisse
[Patch, fortran] PR57445 - [4.8/4.9 Regression] ICE in gfc_conv_class_to_class - for OPTIONAL polymorphic array
Dear All,
This one is trivial. The ICE was caused by an assert that turns out
to be spurious and has been removed.
Bootstrapped and regtested on FC17/x86_64 - OK for trunk and 4.8?
Cheers
Paul
2013-11-01 Paul Thomas pa...@gcc.gnu.org
PR fortran/57445
* trans-expr.c (gfc_conv_class_to_class): Remove spurious
assert.
2013-11-01 Paul Thomas pa...@gcc.gnu.org
PR fortran/57445
* gfortran.dg/optional_class_1.f90 : New test
Index: gcc/fortran/trans-expr.c
===
*** gcc/fortran/trans-expr.c (revision 204285)
--- gcc/fortran/trans-expr.c (working copy)
*** gfc_conv_class_to_class (gfc_se *parmse,
*** 737,743
gfc_add_modify (parmse-post, vptr,
fold_convert (TREE_TYPE (vptr), ctree));
- gcc_assert (!optional || (optional !copyback));
if (optional)
{
tree tmp2;
--- 737,742
*** is_runtime_conformable (gfc_expr *expr1,
*** 7769,7775
e1 = a-expr;
if (e1-rank 0 !is_runtime_conformable (expr1, e1))
return false;
! }
return true;
}
else if (expr2-value.function.isym
--- 7768,7774
e1 = a-expr;
if (e1-rank 0 !is_runtime_conformable (expr1, e1))
return false;
! }
return true;
}
else if (expr2-value.function.isym
Index: gcc/testsuite/gfortran.dg/optional_class_1.f90
===
*** gcc/testsuite/gfortran.dg/optional_class_1.f90 (revision 0)
--- gcc/testsuite/gfortran.dg/optional_class_1.f90 (working copy)
***
*** 0
--- 1,45
+ ! { dg-do run }
+ !
+ ! PR fortran/57445
+ !
+ ! Contributed by Tobias Burnus bur...@gcc.gnu.org
+ !
+ ! Spurious assert was added at revision 192495
+ !
+ module m
+ implicit none
+ type t
+ integer :: i
+ end type t
+ contains
+ subroutine opt(xa, xc, xaa, xca)
+ type(t), allocatable, intent(out), optional :: xa
+ class(t), allocatable, intent(out), optional :: xc
+ type(t), allocatable, intent(out), optional :: xaa(:)
+ class(t), allocatable, intent(out), optional :: xca(:)
+ if (present (xca)) call foo_opt(xca=xca)
+ end subroutine opt
+ subroutine foo_opt(xa, xc, xaa, xca)
+ type(t), allocatable, intent(out), optional :: xa
+ class(t), allocatable, intent(out), optional :: xc
+ type(t), allocatable, intent(out), optional :: xaa(:)
+ class(t), allocatable, intent(out), optional :: xca(:)
+ if (present (xca)) then
+ if (allocated (xca)) deallocate (xca)
+ allocate (xca(3), source = [t(9),t(99),t(999)])
+ end if
+ end subroutine foo_opt
+ end module m
+ use m
+ class(t), allocatable :: xca(:)
+ allocate (xca(1), source = t(42))
+ select type (xca)
+ type is (t)
+ if (any (xca%i .ne. [42])) call abort
+ end select
+ call opt (xca = xca)
+ select type (xca)
+ type is (t)
+ if (any (xca%i .ne. [9,99,999])) call abort
+ end select
+ end
Re: [PATCH, PR 53001] Re: Patch to split out new warning flag for floating point conversion
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Since part of it was to go into c-family (as per Joseph S. Myers's email) and parts are not in c-family, I split the changelog into three parts. I also changed the formatting of the changelog and patch as per Dodji's comments. The attached patch is the same as before, but the diff for Wfloat-conversion.c is as a new file, not as a copy of Wconversion-real.c. Thanks for reviewing it. If there is anything else that needs changing, please tell me. For gcc/c-family/ChangeLog: PR c/53001 Splitting out a -Wfloat-conversion from -Wconversion for conversions that lower floating point number precision or conversion from floating point numbers to integers * c-common.c (unsafe_conversion_p): Make this function return an enumeration with more detail. (conversion_warning): Use the new return type of unsafe_conversion_p to separately warn either about conversions that lower floating point number precision or about the other kinds of conversions. * c-common.h: Adding conversion_safety enumeration. (unsafe_conversion_p): switching return type to conversion_safety enumeration. * c.opt: Adding new warning float-conversion and enabling it -Wconversion For gcc/ChangeLog: PR c/53001 Splitting out a -Wfloat-conversion from -Wconversion for conversions that lower floating point number precision or conversion from floating point numbers to integers * doc/invoke.texi: Adding documentation about -Wfloat-conversion For gcc/testsuite/ChangeLog PR c/53001 Splitting out a -Wfloat-conversion from -Wconversion for conversions that lower floating point number precision or conversion from floating point numbers to integers * c-c++-common/Wfloat-conversion.c: Copies relevant tests from c-c++-common/Wconversion-real.c, gcc.dg/Wconversion-real-integer.c and gcc.dg/pr35635.c into new testcase for conversions that are warned about by -Wfloat-conversion On 10/28/2013 02:50 AM, Dodji Seketeli wrote: Hello Joshua, Joshua J Cogliati jrinc...@yahoo.com writes: I am not certain that c.opt was modified correctly. I don't see any problem with the c.opt part. So unless another maintainer says otherwise, I'd say this is OK. 1. warn_float_patch_and_new_testcase.diff This adds a new testcase and checks for float-conversion in the warning. This will add somewhat more time for running the testcases compared to version 1 while still testing more or less the same code paths. This does however check that the warning occurs when -Wconversion is not used. As said earlier, I'd really prefer this approach because it leaves the existing tests alone and just adds new one. I guess we cannot do much at this point for the speed concern (okay, we could try and make the test harness run more tests in parallel but that is a separate discussion) and I think Joseph agrees too. So please let's stick to this approach. Changelog for warn_float_patch_and_new_testcase.diff and warn_float_patch_and_new_testcase2.diff: Splitting out a -Wfloat-conversion from -Wconversion for conversions that lower floating point number precision or conversion from floating point numbers to integers * c-family/c-common.c Switching unsafe_conversion_p to return an enumeration with more detail, and conversion_warning to use this information. Please, strictly follow the same format as the others entries in the ChangeLog file. That is, explicitly write the names of the functions you changed, in parenthesis, followed by a colon. That would make the entry look like: * c-family/c-common.c (unsafe_conversion_p): Make this function return an enumeration with more detail. (conversion_warning): Use the new return type of unsafe_conversion_p to separately warn either about conversions that lower floating point number precision or about the other kinds of conversions. Thanks, done. * c-family/c-common.h Adding conversion_safety enumeration and switching return type of unsafe_conversion_p Likewise. Changed. * c-family/c.opt Adding new warning float-conversion and enabling it -Wconversion * doc/invoke.texi Adding documentation about -Wfloat-conversion Likewise (colon missing at the end of the file name). * testsuite/c-c++-common/Wfloat-conversion.c Copies relevant tests from c-c++-common/Wconversion-real.c, gcc.dg/Wconversion-real-integer.c and gcc.dg/pr35635.c into new testcase for ones that are warned about by -Wfloat-conversion Changed. You need to add the above ChangeLog entry to the ChangeLog file in gcc/testsuite/ChangeLog. Thus, the entry would look like (note how the prefix testsuite/ is removed from the path name): * c-c++-common/Wfloat-conversion.c: New test file. Its content started as a copy of
Re: RFC: simd enabled functions (omp declare simd / elementals)
On Fri, Nov 01, 2013 at 01:35:35PM +0100, Jakub Jelinek wrote:
So, IMHO much better would be to have an enum simd_clone_arg_type which
would be
enum simd_clone_arg_type
{
SIMD_CLONE_ARG_TYPE_VECTOR,
SIMD_CLONE_ARG_TYPE_UNIFORM,
SIMD_CLONE_ARG_TYPE_LINEAR_CONSTANT_STEP,
SIMD_CLONE_ARG_TYPE_LINEAR_VARIABLE_STEP
};
drop uniform bitfield, change linear_stride_num to
say union { unsigned HOST_WIDE_INT linear_constant_step; int
linear_step_argno; };
or similar.
I've committed this to gomp-4_0-branch as follow-up to your patch:
2013-11-01 Jakub Jelinek ja...@redhat.com
* cgraph.h (enum linear_stride_type): Remove.
(enum simd_clone_arg_type): New.
(struct simd_clone_arg): Remove linear_stride, linear_stride_num
and uniform fields. Add arg_type and linear_step.
* omp-low.c (simd_clone_struct_copy): Formatting.
(simd_clone_struct_alloc): Likewise. Use size_t.
(simd_clone_clauses_extract, simd_clone_compute_base_data_type,
simd_clone_adjust_argument_types): Adjust for struct simd_clone_arg
changes.
(simd_clone_mangle): Likewise. Handle negative linear step.
--- gcc/cgraph.h.jj 2013-11-01 17:11:42.0 +0100
+++ gcc/cgraph.h2013-11-01 17:24:59.472995514 +0100
@@ -250,10 +250,12 @@ struct GTY(()) cgraph_clone_info
bitmap combined_args_to_skip;
};
-enum linear_stride_type {
- LINEAR_STRIDE_NO,
- LINEAR_STRIDE_YES_CONSTANT,
- LINEAR_STRIDE_YES_VARIABLE
+enum simd_clone_arg_type
+{
+ SIMD_CLONE_ARG_TYPE_VECTOR,
+ SIMD_CLONE_ARG_TYPE_UNIFORM,
+ SIMD_CLONE_ARG_TYPE_LINEAR_CONSTANT_STEP,
+ SIMD_CLONE_ARG_TYPE_LINEAR_VARIABLE_STEP
};
/* Function arguments in the original function of a SIMD clone.
@@ -282,28 +284,17 @@ struct GTY(()) simd_clone_arg {
tree simd_array;
/* A SIMD clone's argument can be either linear (constant or
- variable), uniform, or vector. If the argument is neither linear
- or uniform, the default is vector. */
+ variable), uniform, or vector. */
+ enum simd_clone_arg_type arg_type;
- /* If the linear stride is a constant, `linear_stride' is
- LINEAR_STRIDE_YES_CONSTANT, and `linear_stride_num' holds
- the numeric stride.
-
- If the linear stride is variable, `linear_stride' is
- LINEAR_STRIDE_YES_VARIABLE, and `linear_stride_num' contains
- the function argument containing the stride (as an index into the
- function arguments starting at 0).
-
- Otherwise, `linear_stride' is LINEAR_STRIDE_NO and
- `linear_stride_num' is unused. */
- enum linear_stride_type linear_stride;
- unsigned HOST_WIDE_INT linear_stride_num;
+ /* For arg_type SIMD_CLONE_ARG_TYPE_LINEAR_CONSTANT_STEP this is
+ the constant linear step, if arg_type is
+ SIMD_CLONE_ARG_TYPE_LINEAR_VARIABLE_STEP, this is index of
+ the uniform argument holding the step, otherwise 0. */
+ HOST_WIDE_INT linear_step;
/* Variable alignment if available, otherwise 0. */
unsigned int alignment;
-
- /* True if variable is uniform. */
- unsigned int uniform : 1;
};
/* Specific data for a SIMD function clone. */
--- gcc/omp-low.c.jj2013-11-01 17:11:42.0 +0100
+++ gcc/omp-low.c 2013-11-01 17:41:26.635904034 +0100
@@ -10561,8 +10561,8 @@ static struct simd_clone *
simd_clone_struct_alloc (int nargs)
{
struct simd_clone *clone_info;
- int len = sizeof (struct simd_clone)
-+ nargs * sizeof (struct simd_clone_arg);
+ size_t len = (sizeof (struct simd_clone)
+ + nargs * sizeof (struct simd_clone_arg));
clone_info = ggc_alloc_cleared_simd_clone_stat (len PASS_MEM_STAT);
return clone_info;
}
@@ -10572,8 +10572,8 @@ simd_clone_struct_alloc (int nargs)
static inline void
simd_clone_struct_copy (struct simd_clone *to, struct simd_clone *from)
{
- memcpy (to, from, sizeof (struct simd_clone)
- + from-nargs * sizeof (struct simd_clone_arg));
+ memcpy (to, from, (sizeof (struct simd_clone)
++ from-nargs * sizeof (struct simd_clone_arg)));
}
/* Given a simd clone in NEW_NODE, extract the simd specific
@@ -10637,31 +10637,27 @@ simd_clone_clauses_extract (struct cgrap
int argno = TREE_INT_CST_LOW (decl);
if (OMP_CLAUSE_LINEAR_VARIABLE_STRIDE (t))
{
- clone_info-args[argno].linear_stride
- = LINEAR_STRIDE_YES_VARIABLE;
- clone_info-args[argno].linear_stride_num
- = TREE_INT_CST_LOW (step);
- gcc_assert (!TREE_INT_CST_HIGH (step));
+ clone_info-args[argno].arg_type
+ = SIMD_CLONE_ARG_TYPE_LINEAR_VARIABLE_STEP;
+ clone_info-args[argno].linear_step
+ = tree_low_cst (step, 0);
+ gcc_assert (clone_info-args[argno].linear_step = 0
+clone_info-args[argno].linear_step n);
}
else
{
- if
Re: [PATCH][ubsan] Add VLA bound instrumentation
On 10/31/2013 02:28 PM, Marek Polacek wrote:
/* A variable sized array. */
itype = variable_size (itype);
+
+ /* We need to stabilize side-effects in VLA sizes for regular array
+declarations too, not just pointers to arrays. */
+ stabilize_vla_size (itype);
Let's put this after the later call to variable_size, too.
if (TREE_CODE (itype) != SAVE_EXPR)
{
/* Look for SIZEOF_EXPRs in itype and fold them, otherwise
@@ -8390,6 +8385,31 @@ compute_array_index_type (tree name, tre
if (found)
itype = variable_size (fold (newitype));
}
i.e. here.
+
+ if (cxx_dialect = cxx1y)
+ {
+ /* If the VLA bound is larger than half the address space,
+or less than zero, throw std::bad_array_length. */
+ tree comp = build2 (LT_EXPR, boolean_type_node, itype,
+ ssize_int (-1));
+ comp = build3 (COND_EXPR, void_type_node, comp,
+throw_bad_array_length (), void_zero_node);
+ finish_expr_stmt (comp);
+ }
+
+ if ((flag_sanitize SANITIZE_VLA)
+ /* From C++1y onwards, we throw an exception on a negative
+length size of an array; see above */
+ cxx_dialect cxx1y)
This could be
else if (flag_sanitize SANITIZE_VLA)
There's another use of stabilize_vla_size in grokdeclarator, that should
be able to go as well.
Jason
[Patch] Fix type of clock_t in timevar.c
While working on a canadian cross build I ran into a problem with the type of clock_t. If HAVE_CLOCK_T is not defined timevar.c defines it to be int. I think the type should be long. I am using the mingw compilers on linux in my canadian cross build and HAVE_CLOCK_T is not getting set but when building I get a conflict between the definition of clock_t in /usr/i586-mingw32msvc/include/time.h (long) and the definition in timevar.c. Since mingw and linux and glibc and newlib all seem to agree on long I would like to change timevar.c to agree with them. Tested with my canadian cross build and a native x86 linux build. OK to checkin? Steve Ellcey sell...@mips.com 2013-11-01 Steve Ellcey sell...@mips.com * timevar.c: Fix type of clock_t. diff --git a/gcc/timevar.c b/gcc/timevar.c index 23b7118..b66f94a 100644 --- a/gcc/timevar.c +++ b/gcc/timevar.c @@ -23,7 +23,7 @@ along with GCC; see the file COPYING3. If not see #include timevar.h #ifndef HAVE_CLOCK_T -typedef int clock_t; +typedef long clock_t; #endif #ifndef HAVE_STRUCT_TMS
[PATCH] Small fix: add { dg-require-effective-target vect_int } to testsuite/gcc.dg/vect/pr58508.c
It seems that on some platforms the loops in
testsuite/gcc.dg/vect/pr58508.c may be unable to be vectorized. This
small patch added { dg-require-effective-target vect_int } to make
sure all loops can be vectorized.
thanks,
Cong
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 9d0f4a5..3d9916d 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,7 @@
+2013-10-29 Cong Hou co...@google.com
+
+ * gcc.dg/vect/pr58508.c: Update.
+
2013-10-15 Cong Hou co...@google.com
* gcc.dg/vect/pr58508.c: New test.
diff --git a/gcc/testsuite/gcc.dg/vect/pr58508.c
b/gcc/testsuite/gcc.dg/vect/pr58508.c
index 6484a65..fff7a04 100644
--- a/gcc/testsuite/gcc.dg/vect/pr58508.c
+++ b/gcc/testsuite/gcc.dg/vect/pr58508.c
@@ -1,3 +1,4 @@
+/* { dg-require-effective-target vect_int } */
/* { dg-do compile } */
/* { dg-options -O2 -ftree-vectorize -fdump-tree-vect-details } */
Re: [C++ Patch / RFC] PR 29234
On 10/31/2013 03:07 PM, Paolo Carlini wrote: ... I understand that at this point likely this isn't 4.9 material anymore. I think it's fine for 4.9, we're still in stage 1. The revised patch is OK. Jason
[Patch] configure patch for caddr_t and ssize_t types
While doing a canadian cross build I ran into a problem with the caddr_t type. configure.ac is using an obsolete version of AC_CHECK_TYPE to create #define's of caddr_t and ssize_t if they are not defined by the system. In addition to using an obsolete version of AC_CHECK_TYPE this was causing a problem in my build because caddr_t was also getting set via a typedef by the mingw compilers. Here is my fix, tested with a canadian cross build and with a native x86 linux build. OK to checkin? 2013-11-01 Steve Ellcey sell...@mips.com * configure.ac: Add header checks for fenv.h and complex.h. * configure: Regenerate. * config.in: Regnerate. * system.h: Add default caddr_t and ssize_t typedefs. diff --git a/gcc/configure.ac b/gcc/configure.ac index 5e686db..bc87073 100644 --- a/gcc/configure.ac +++ b/gcc/configure.ac @@ -1075,8 +1075,8 @@ int main() fi fi -AC_CHECK_TYPE(ssize_t, int) -AC_CHECK_TYPE(caddr_t, char *) +AC_CHECK_TYPES([ssize_t]) +AC_CHECK_TYPES([caddr_t]) GCC_AC_FUNC_MMAP_BLACKLIST diff --git a/gcc/system.h b/gcc/system.h index a1fc6de..108ec0e 100644 --- a/gcc/system.h +++ b/gcc/system.h @@ -1060,6 +1060,14 @@ helper_const_non_const_cast (const char *p) #define DEBUG_VARIABLE #endif +#ifndef HAVE_CADDR_T +typedef char *caddr_t; +#endif + +#ifndef HAVE_SSIZE_T +typedef int ssize_t +#endif + /* Get definitions of HOST_WIDE_INT and HOST_WIDEST_INT. */ #include hwint.h
Re: [Patch] configure patch for caddr_t and ssize_t types
On Fri, Nov 01, 2013 at 11:15:02AM -0700, Steve Ellcey wrote: --- a/gcc/system.h +++ b/gcc/system.h @@ -1060,6 +1060,14 @@ helper_const_non_const_cast (const char *p) #define DEBUG_VARIABLE #endif +#ifndef HAVE_CADDR_T +typedef char *caddr_t; +#endif + +#ifndef HAVE_SSIZE_T +typedef int ssize_t +#endif Missing ';'? Marek
Re: [Patch] configure patch for caddr_t and ssize_t types
On Fri, 2013-11-01 at 19:22 +0100, Marek Polacek wrote: On Fri, Nov 01, 2013 at 11:15:02AM -0700, Steve Ellcey wrote: --- a/gcc/system.h +++ b/gcc/system.h @@ -1060,6 +1060,14 @@ helper_const_non_const_cast (const char *p) #define DEBUG_VARIABLE #endif +#ifndef HAVE_CADDR_T +typedef char *caddr_t; +#endif + +#ifndef HAVE_SSIZE_T +typedef int ssize_t +#endif Missing ';'? Marek Yes. Both my cross build and my native build set HAVE_SSIZE_T so I didn't see this. I really only changed ssize_t to make it consistent with caddr_t (which was causing me a problem) and to remove the use of the obsolete form of AC_CHECK_TYPE. Steve Ellcey sell...@mips.com
Re: [PATCH][ubsan] Add VLA bound instrumentation
On Fri, Nov 01, 2013 at 01:35:07PM -0400, Jason Merrill wrote:
On 10/31/2013 02:28 PM, Marek Polacek wrote:
/* A variable sized array. */
itype = variable_size (itype);
+
+ /* We need to stabilize side-effects in VLA sizes for regular array
+ declarations too, not just pointers to arrays. */
+ stabilize_vla_size (itype);
Let's put this after the later call to variable_size, too.
if (TREE_CODE (itype) != SAVE_EXPR)
{
/* Look for SIZEOF_EXPRs in itype and fold them, otherwise
@@ -8390,6 +8385,31 @@ compute_array_index_type (tree name, tre
if (found)
itype = variable_size (fold (newitype));
}
i.e. here.
Done.
+
+ if (cxx_dialect = cxx1y)
+{
+ /* If the VLA bound is larger than half the address space,
+ or less than zero, throw std::bad_array_length. */
+ tree comp = build2 (LT_EXPR, boolean_type_node, itype,
+ ssize_int (-1));
+ comp = build3 (COND_EXPR, void_type_node, comp,
+ throw_bad_array_length (), void_zero_node);
+ finish_expr_stmt (comp);
+ }
+
+ if ((flag_sanitize SANITIZE_VLA)
+ /* From C++1y onwards, we throw an exception on a negative
+length size of an array; see above */
+ cxx_dialect cxx1y)
This could be
else if (flag_sanitize SANITIZE_VLA)
Done (with some formatting nits fixed).
There's another use of stabilize_vla_size in grokdeclarator, that
should be able to go as well.
Yep, seems so.
Regtest/bootstrap on x86_64-linux running (so far lookin' good), ok if passes?
2013-11-01 Marek Polacek pola...@redhat.com
Implement -fsanitize=vla-bound.
* opts.c (common_handle_option): Handle vla-bound.
* sanitizer.def (BUILT_IN_UBSAN_HANDLE_VLA_BOUND_NOT_POSITIVE):
Define.
* flag-types.h (enum sanitize_code): Add SANITIZE_VLA.
* asan.c (initialize_sanitizer_builtins): Build BT_FN_VOID_PTR_PTR.
c-family/
* c-ubsan.c: Don't include hash-table.h.
(ubsan_instrument_vla): New function.
* c-ubsan.h: Declare it.
cp/
* decl.c (cp_finish_decl): Move C++1y bounds checking...
(compute_array_index_type): ...here. Add VLA instrumentation.
Call stabilize_vla_size.
(grokdeclarator): Don't call stabilize_vla_size here.
c/
* c-decl.c (grokdeclarator): Add VLA instrumentation.
testsuite/
* g++.dg/ubsan/cxx1y-vla.C: New test.
* c-c++-common/ubsan/vla-3.c: New test.
* c-c++-common/ubsan/vla-2.c: New test.
* c-c++-common/ubsan/vla-4.c: New test.
* c-c++-common/ubsan/vla-1.c: New test.
--- gcc/opts.c.mp 2013-11-01 18:53:17.372014692 +0100
+++ gcc/opts.c 2013-11-01 18:53:48.857130430 +0100
@@ -1444,6 +1444,7 @@ common_handle_option (struct gcc_options
{ undefined, SANITIZE_UNDEFINED, sizeof undefined - 1 },
{ unreachable, SANITIZE_UNREACHABLE,
sizeof unreachable - 1 },
+ { vla-bound, SANITIZE_VLA, sizeof vla-bound - 1 },
{ NULL, 0, 0 }
};
const char *comma;
--- gcc/c-family/c-ubsan.c.mp 2013-11-01 18:53:17.389014762 +0100
+++ gcc/c-family/c-ubsan.c 2013-11-01 18:53:48.858130434 +0100
@@ -25,7 +25,6 @@ along with GCC; see the file COPYING3.
#include alloc-pool.h
#include cgraph.h
#include gimple.h
-#include hash-table.h
#include output.h
#include toplev.h
#include ubsan.h
@@ -86,8 +85,7 @@ ubsan_instrument_division (location_t lo
return t;
}
-/* Instrument left and right shifts. If not instrumenting, return
- NULL_TREE. */
+/* Instrument left and right shifts. */
tree
ubsan_instrument_shift (location_t loc, enum tree_code code,
@@ -157,4 +155,23 @@ ubsan_instrument_shift (location_t loc,
t = fold_build3 (COND_EXPR, void_type_node, t, tt, void_zero_node);
return t;
+}
+
+/* Instrument variable length array bound. */
+
+tree
+ubsan_instrument_vla (location_t loc, tree size)
+{
+ tree type = TREE_TYPE (size);
+ tree t, tt;
+
+ t = fold_build2 (LE_EXPR, boolean_type_node, size, build_int_cst (type, 0));
+ tree data = ubsan_create_data (__ubsan_vla_data,
+loc, ubsan_type_descriptor (type), NULL_TREE);
+ data = build_fold_addr_expr_loc (loc, data);
+ tt = builtin_decl_explicit (BUILT_IN_UBSAN_HANDLE_VLA_BOUND_NOT_POSITIVE);
+ tt = build_call_expr_loc (loc, tt, 2, data, ubsan_encode_value (size));
+ t = fold_build3 (COND_EXPR, void_type_node, t, tt, void_zero_node);
+
+ return t;
}
--- gcc/c-family/c-ubsan.h.mp 2013-11-01 18:53:17.395014787 +0100
+++ gcc/c-family/c-ubsan.h 2013-11-01 18:53:48.864130461 +0100
@@ -23,5 +23,6 @@ along with GCC; see the file COPYING3.
extern tree ubsan_instrument_division (location_t, tree, tree);
extern tree ubsan_instrument_shift (location_t,
Re: [PATCH] use stack vectors more
On Thu, Oct 31, 2013 at 7:48 PM, tsaund...@mozilla.com wrote: From: Trevor Saunders tsaund...@mozilla.com Hi, This patch is pretty dull, it just replaces a bunch of things of the form vecT x; x.create (N); // N is a constant blah blah x.release (); by stack_vecT, N x; blah blah Of course its even nicer than that in some of the cases with many early returns. bootstrapped and same test results as r204192 on x86_64-unknown-linux-gnu, ok? Trev 2013-09-28 Trevor Saunders tsaund...@mozilla.com cp/ * semantics.c (build_anon_member_initialization): Convert fields to be a stack_vec. gcc/ * function.c (reorder_blocks): Convert block_stack to a stack_vec. * gimplify.c (gimplify_compound_lval): Likewise. * graphite-clast-to-gimple.c (gloog): Likewise. * graphite-dependences.c (loop_is_parallel_p): Likewise. * graphite-scop-detection.c (scopdet_basic_block_info): Likewise. (limit_scop); Likewise. (build_scops): Likewise. (dot_scop): Likewise. * graphite-sese-to-poly.c (sese_dom_walker): Likewise. (build_scop_drs): Likewise. (insert_stmts): Likewise. (insert_out_of_ssa_copy): Likewise. (remove_phi): Likewise. (rewrite_commutative_reductions_out_of_ssa_close_phi): Likewise. * hw-doloop.c (discover_loop): Likewise. * tree-call-cdce.c (shrink_wrap_one_built_in_call): Likewise. * tree-dfa.c (dump_enumerated_decls): Likewise. * tree-if-conv.c (if_convertable_loop_p): Likewise. * tree-inline.c (tree_function_versioning): Likewise. * tree-loop-distribution.c (build_rdg): Likewise. (rdg_flag_vertex_and_dependent): Likewise. (distribute_loop): Likewise. * tree-parloops.c (loop_parallel_p): Likewise. (eliminate_local_variables): Likewise. (separate_decls_in_region): Likewise. * tree-predcom.c (tree_predictive_commoning_loop): Likewise. * tree-ssa-phiopt.c (cond_if_else_store_replacement): Likewise. * tree-ssa-uncprop.c (uncprop_dom_walker): Likewise. * tree-vect-loop.c (vect_analyze_scaler_cycles_1): Likewise. * tree-vect-patterns.c (vect_pattern_recog): Likewise. * tree-vect-stmts.c (vect_mark_stmts_to_be_vectorized): Likewise. (vectorizable_condition): Likewise. The patch is OK, but it did not completely apply in my tree. Mind sending an updated version (or point me at a git repo I can pull it from). Thanks. Diego.
Re: [PATCH] use stack vectors more
The patch is OK, but it did not completely apply in my tree. Mind
sending an updated version (or point me at a git repo I can pull it
from).
interesting, I just pulled and rebased it onto r204296 without any manual
merging. Patch against r204296 attached (obviously haven't tested it
against that rev yet).
Trev
Thanks. Diego.
From 3e9b030811d3ff4f5605227171d33561ce59453e Mon Sep 17 00:00:00 2001
From: Trevor Saunders tsaund...@mozilla.com
Date: Wed, 9 Oct 2013 14:19:29 -0400
Subject: [PATCH] use stack vectors more
---
gcc/cp/semantics.c | 4 +---
gcc/function.c | 5 +
gcc/gimplify.c | 3 +--
gcc/graphite-clast-to-gimple.c | 4 +---
gcc/graphite-dependences.c | 4 +---
gcc/graphite-scop-detection.c | 20 ++--
gcc/graphite-sese-to-poly.c| 39 ---
gcc/hw-doloop.c| 5 +
gcc/tree-call-cdce.c | 14 +++---
gcc/tree-dfa.c | 4 +---
gcc/tree-if-conv.c | 3 +--
gcc/tree-inline.c | 4 +---
gcc/tree-loop-distribution.c | 18 --
gcc/tree-parloops.c| 15 ---
gcc/tree-predcom.c | 6 ++
gcc/tree-ssa-phiopt.c | 14 +-
gcc/tree-ssa-uncprop.c | 12 ++--
gcc/tree-vect-loop.c | 5 +
gcc/tree-vect-patterns.c | 5 +
gcc/tree-vect-stmts.c | 38 --
20 files changed, 49 insertions(+), 173 deletions(-)
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 6c560c6..366756f 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -7439,8 +7439,7 @@ build_anon_member_initialization (tree member, tree init,
to build up the initializer from the outside in so that we can reuse
previously built CONSTRUCTORs if this is, say, the second field in an
anonymous struct. So we use a vec as a stack. */
- vectree fields;
- fields.create (2);
+ stack_vectree, 2 fields;
do
{
fields.safe_push (TREE_OPERAND (member, 1));
@@ -7472,7 +7471,6 @@ build_anon_member_initialization (tree member, tree init,
/* Now we're at the innermost field, the one that isn't an anonymous
aggregate. Add its initializer to the CONSTRUCTOR and we're done. */
gcc_assert (fields.is_empty());
- fields.release ();
CONSTRUCTOR_APPEND_ELT (*vec, field, init);
return true;
diff --git a/gcc/function.c b/gcc/function.c
index eb8aca9..21ab691 100644
--- a/gcc/function.c
+++ b/gcc/function.c
@@ -4128,12 +4128,11 @@ void
reorder_blocks (void)
{
tree block = DECL_INITIAL (current_function_decl);
- vectree block_stack;
if (block == NULL_TREE)
return;
- block_stack.create (10);
+ stack_vectree, 10 block_stack;
/* Reset the TREE_ASM_WRITTEN bit for all blocks. */
clear_block_marks (block);
@@ -4145,8 +4144,6 @@ reorder_blocks (void)
/* Recreate the block tree from the note nesting. */
reorder_blocks_1 (get_insns (), block, block_stack);
BLOCK_SUBBLOCKS (block) = blocks_nreverse_all (BLOCK_SUBBLOCKS (block));
-
- block_stack.release ();
}
/* Helper function for reorder_blocks. Reset TREE_ASM_WRITTEN. */
diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index 1f18466..0723027 100644
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -2142,7 +2142,6 @@ gimplify_compound_lval (tree *expr_p, gimple_seq *pre_p, gimple_seq *post_p,
fallback_t fallback)
{
tree *p;
- vectree expr_stack;
enum gimplify_status ret = GS_ALL_DONE, tret;
int i;
location_t loc = EXPR_LOCATION (*expr_p);
@@ -2150,7 +2149,7 @@ gimplify_compound_lval (tree *expr_p, gimple_seq *pre_p, gimple_seq *post_p,
/* Create a stack of the subexpressions so later we can walk them in
order from inner to outer. */
- expr_stack.create (10);
+ stack_vectree, 10 expr_stack;
/* We can handle anything that get_inner_reference can deal with. */
for (p = expr_p; ; p = TREE_OPERAND (*p, 0))
diff --git a/gcc/graphite-clast-to-gimple.c b/gcc/graphite-clast-to-gimple.c
index 04c23c5..ec4c1d1 100644
--- a/gcc/graphite-clast-to-gimple.c
+++ b/gcc/graphite-clast-to-gimple.c
@@ -1652,8 +1652,7 @@ debug_generated_program (scop_p scop)
bool
gloog (scop_p scop, bb_pbb_htab_type bb_pbb_mapping)
{
- vectree newivs;
- newivs.create (10);
+ stack_vectree, 10 newivs;
loop_p context_loop;
sese region = SCOP_REGION (scop);
ifsese if_region = NULL;
@@ -1711,7 +1710,6 @@ gloog (scop_p scop, bb_pbb_htab_type bb_pbb_mapping)
newivs_index.dispose ();
params_index.dispose ();
- newivs.release ();
cloog_clast_free (clast);
timevar_pop (TV_GRAPHITE_CODE_GEN);
diff --git a/gcc/graphite-dependences.c b/gcc/graphite-dependences.c
index 545881b..417ea2c 100644
--- a/gcc/graphite-dependences.c
+++ b/gcc/graphite-dependences.c
@@ -585,13 +585,11 @@ loop_is_parallel_p (loop_p loop, bb_pbb_htab_type bb_pbb_mapping, int depth)
{
Re: [Fwd: Re: [PATCH, rs6000] Correct handling of multiply high-part for little endian]
After discussing this for Richard S at some length today, I want to
withdraw this for now and re-examine the issue. I don't feel I
understand this as well as I thought I did... ;)
Thanks,
Bill
On Thu, 2013-10-31 at 21:06 -0500, Bill Schmidt wrote:
Hi maintainers,
I agree with David that duplicating this code is a bad approach. What
he and I would both prefer is to add a target hook to account for an
anomaly in the PowerPC architecture.
Background: For historical reasons, our vperm instruction (which is
produced for gen_vec_perm) has some peculiar semantics in little endian
mode. The permute control vector is interpreted to contain elements
indexed in big-endian order no matter which endian mode the processor is
set to. We can work around this in little endian mode by inverting the
permute control vector and swapping the order of the other two input
vectors, thus obtaining the same semantics as we would get for big
endian.
This behavior works when the two vectors are being treated as a single
double-wide vector; the swapping is needed to make the long array appear
as [8, 7, 6, 5, 4, 3, 2, 1] instead of [4, 3, 2, 1, 8, 7, 6, 5].
In the specific case of expand_mult_highpart (), the two vectors are not
a single double-wide vector, but instead contain the odd and even
results of widening multiplies. In this case, we still need to invert
the permute control vector, but we don't want to swap the operands,
because that causes us to mix up the odd and even results. This is the
only such case we've run into where the swap is not what we need to
obtain the right semantics.
What we would like to do is swap the operands an extra time in
expand_mult_highpart (), so that our common code will then swap the
operands back to their original position. But since this is in
target-independent code, we would need a target hook to do this.
Something like:
if (targetm.swap_vperm_inputs ())
{
rtx tmp = m1;
m1 = m2;
m2 = tmp;
}
For PowerPC, the target hook would return !BYTES_BIG_ENDIAN. The
default implementation for all other targets would return false.
Would you find such an approach tolerable?
Thanks,
Bill
email message attachment (Re: [PATCH, rs6000] Correct handling of
multiply high-part for little endian), Forwarded message - Re:
[PATCH, rs6000] Correct handling of multiply high-part for little
endian
Forwarded Message
From: David Edelsohn dje@gmail.com
To: Bill Schmidt wschm...@linux.vnet.ibm.com
Cc: GCC Patches gcc-patches@gcc.gnu.org
Subject: Re: [PATCH, rs6000] Correct handling of multiply high-part
for little endian
Date: Wed, 30 Oct 2013 20:06:37 -0400
On Wed, Oct 30, 2013 at 6:55 PM, Bill Schmidt
wschm...@linux.vnet.ibm.com wrote:
Hi,
When working around the peculiar little-endian semantics of the vperm
instruction, our usual fix is to complement the permute control vector
and swap the order of the two vector input operands, so that we get a
double-wide vector in the proper order. We don't want to swap the
operands when we are expanding a mult_highpart operation, however, as
the two input operands are not to be interpreted as a double-wide
vector. Instead they represent odd and even elements, and swapping the
operands gets the odd and even elements reversed in the final result.
The permute for this case is generated by target-neutral code in
optabs.c: expand_mult_highpart (). We obviously can't change that code
directly. However, we can redirect the logic from the case 2 method
to target-specific code by implementing expansions for the
umulmode3_highpart and smulmode3_highpart operations. I've done
this, with the expansions acting exactly as expand_mult_highpart does
today, with the exception that it swaps the input operands to the call
to expand_vec_perm when we are generating little-endian code. We will
later swap them back to their original position in the code in rs6000.c:
altivec_expand_vec_perm_const_le ().
The change has no intended effect when generating big-endian code.
Bootstrapped and tested on powerpc64{,le}-unknown-linux-gnu with no new
regressions. This fixes the gcc.dg/vect/pr51581-4.c test failure for
little endian. Ok for trunk?
Thanks,
Bill
2013-10-30 Bill Schmidt wschm...@linux.vnet.ibm.com
* config/rs6000/rs6000-protos.h (altivec_expand_mul_highpart): New
prototype.
* config/rs6000/rs6000.c (altivec_expand_mul_highpart): New.
Re: [Patch] Fix type of clock_t in timevar.c
On Nov 1, 2013, at 10:47 AM, Steve Ellcey sell...@mips.com wrote: While working on a canadian cross build I ran into a problem with the type of clock_t. If HAVE_CLOCK_T is not defined timevar.c defines it to be int. I think the type should be long. I am using the mingw compilers on linux in my canadian cross build and HAVE_CLOCK_T is not getting set but when building I get a conflict between the definition of clock_t in /usr/i586-mingw32msvc/include/time.h (long) and the definition in timevar.c. You should report a bug to them and have them define clock_t. Since mingw and linux and glibc and newlib all seem to agree on long I would like to change timevar.c to agree with them. Seems reasonable to me, though newlib and macosx use unsigned long. glibc remains at long, due to binary compatibility.
Re: [PATCH] LRA: Fix incorrect register spill/reload
On 10/31/13 14:03, Robert Suchanek wrote: Hi David, No, I do not have read/write SVN access. I know a person who could commit the patch for me, however, if you can commit it, I'd be grateful. Note, I didn't see anywhere in this thread an indication this test had been through a bootstrap and regression testing. I was running those overnight on Robert's behalf and the bootstrap test failed with a comparison failure between stage2/toplev.o and stage3/toplev.o Vlad, when approving patches, please make sure they've been through the usual bootstrap and regression testing procedures. If the contributor hasn't done it themselves, you can either do it for them or ask them to do it. I trust y'all will address the problem appropriately. Jeff
Re: [PATCH] use stack vectors more
On Fri, Nov 1, 2013 at 3:33 PM, Trevor Saunders tsaund...@mozilla.com wrote: The patch is OK, but it did not completely apply in my tree. Mind sending an updated version (or point me at a git repo I can pull it from). interesting, I just pulled and rebased it onto r204296 without any manual merging. Patch against r204296 attached (obviously haven't tested it against that rev yet). It must've been whitespace then. Your new patch applied just fine. I'll be committing shortly. Diego.
Re: [Patch] Fix type of clock_t in timevar.c
On Fri, 2013-11-01 at 12:43 -0700, Mike Stump wrote: On Nov 1, 2013, at 10:47 AM, Steve Ellcey sell...@mips.com wrote: While working on a canadian cross build I ran into a problem with the type of clock_t. If HAVE_CLOCK_T is not defined timevar.c defines it to be int. I think the type should be long. I am using the mingw compilers on linux in my canadian cross build and HAVE_CLOCK_T is not getting set but when building I get a conflict between the definition of clock_t in /usr/i586-mingw32msvc/include/time.h (long) and the definition in timevar.c. You should report a bug to them and have them define clock_t. They are defining clock_t, but for some reason the GCC configure is not seeing it (perhaps because of what header files get included). Since mingw and linux and glibc and newlib all seem to agree on long I would like to change timevar.c to agree with them. Seems reasonable to me, though newlib and macosx use unsigned long. glibc remains at long, due to binary compatibility. Ah, I confused _CLOCK_T_ (unsigned long) with __CLOCK_T_TYPE (long) in newlib. clock_t is defined as _CLOCK_T_ in newlib, not __CLOCK_T_TYPE. Steve Ellcey sell...@mips.com
Re: [Patch] Implementation of n3793 experimental/optional
Doh, that had yesterday's date on the ChangeLog entry, I've just fixed it with the next commit. On 1 November 2013 20:09, Jonathan Wakely jwakely@gmail.com wrote: Here's the final version of Luc's optional implementation that I'm committing, tested on x86_64-linux. (It occurs to me that we might want to move the contents of include/tr2 to include/experimental and namespace experimental, since there isn't going to be a TR2 now.)
Re: PING: Fwd: Re: [patch] implement Cilk Plus simd loops on trunk
On 10/18/2013 02:48 PM, Aldy Hernandez wrote:
This has the potential of throwing my mind for a spin. Can I do this as
a followup, and keep it simple for now?
Sure.
+ else if (!TREE_TYPE (e) || !TREE_CONSTANT (e)
+ || !INTEGRAL_TYPE_P (TREE_TYPE (e)))
+cp_parser_error (parser,
+ step size must be an integer constant);
Can't the step size be a value-dependent expression like a template
non-type parameter?
Fixed. I also found some nuances in how we were (NOT) handling
variables as the standard mentioned, both for C and C++. Fixed as well,
and added testcases when appropriate.
+ else if (TREE_TYPE (e)
+ INTEGRAL_TYPE_P (TREE_TYPE (e))
+ (TREE_CONSTANT (e)
+ || DECL_P (e)))
+ step_size = e;
This still doesn't seem like it allows arbitrary dependent
constant-expressions. In a template, I'm pretty sure not everything
that will end up being a constant-expression is marked TREE_CONSTANT.
You want to check type_dependent_expression_p and
value_dependent_expression_p.
+ if (this_pre_body)
+{
+ this_pre_body = pop_stmt_list (this_pre_body);
+ if (*pre_body)
+ {
+ tree t = *pre_body;
+ *pre_body = push_stmt_list ();
+ add_stmt (t);
+ add_stmt (this_pre_body);
+ *pre_body = pop_stmt_list (*pre_body);
+ }
+ else
+ *pre_body = this_pre_body;
+}
I think you can just use
append_to_statement_list (this_pre_body, pre_body)
+ if (for_keyword == RID_FOR)
+decl = cp_parser_simd_for_init_statement (parser, init, pre_body);
+
+ if (decl == error_mark_node)
Don't you get a warning about decl possibly being used uninitialized
here? I think you want
else
/* FIXME when _Cilk_for is implemented. */
decl = NULL_TREE;
I guess the assert previously protected you from the uninitialized warning.
+ if (cp_lexer_next_token_is (parser-lexer, CPP_COMMA))
+{
+ error_at (loc, %s-loop initializer cannot have multiple variable
+ declarations, for_keyword == RID_FOR ? for : _Cilk_for);
+ cp_parser_skip_to_end_of_statement (parser);
+ valid = false;
+}
+
+ if (!valid)
+{
+ /* Skip to the semicolon ending the init. */
+ cp_parser_skip_to_end_of_statement (parser);
+}
+ if (!cp_parser_require (parser, CPP_SEMICOLON, RT_SEMICOLON))
+return error_mark_node;
I think this should move into cp_parser_simd_for_init_statement or
cp_parser_omp_for_loop_init.
Out of curiosity, how are OpenMP and Cilk+ for loops so different that
they can't share a parsing function?
+/* Adjust any clauses to match the requirements for OpenMP. */
I guess the idea here is that the clauses start out as Cilk+ clauses?
The comment should make that clearer.
- if (flag_openmp == 0)
+ if (!flag_openmp !flag_enable_cilkplus)
Seems like there should be an internal flag to enable the common internals.
+/* Cilk Plus - #pragma simd [clause1 ... clauseN]
+ Operands like for OMP_FOR. */
+DEFTREECODE (CILK_SIMD, cilk_simd, tcc_statement, 6)
Could this just be a flag on OMP_SIMD?
Jason
Re: [PATCH] use stack vectors more
On Fri, Nov 1, 2013 at 3:51 PM, Diego Novillo dnovi...@google.com wrote: It must've been whitespace then. Your new patch applied just fine. I'll be committing shortly. Committed at r204301. Diego.
Re: PR C++/58708 - string literal operator templates broken
OK. Jason
Re: [PATCH][ubsan] Add VLA bound instrumentation
On 11/01/2013 03:10 PM, Marek Polacek wrote: + /* We need to stabilize side-effects in VLA sizes for regular array +declarations too, not just pointers to arrays. */ This comment isn't really relevant to its new location. :) OK with that removed. Jason
Re: [PATCH] LRA: Fix incorrect register spill/reload
On Fri, Nov 1, 2013 at 3:45 PM, Jeff Law l...@redhat.com wrote: On 10/31/13 14:03, Robert Suchanek wrote: Hi David, No, I do not have read/write SVN access. I know a person who could commit the patch for me, however, if you can commit it, I'd be grateful. Note, I didn't see anywhere in this thread an indication this test had been through a bootstrap and regression testing. I was running those overnight on Robert's behalf and the bootstrap test failed with a comparison failure between stage2/toplev.o and stage3/toplev.o Vlad, when approving patches, please make sure they've been through the usual bootstrap and regression testing procedures. If the contributor hasn't done it themselves, you can either do it for them or ask them to do it. I trust y'all will address the problem appropriately. I bootstrapped on powerpc without problem, but Vlad earlier said that the code applies to an x86 case. I have not seen a deluge of complaints about bootstrap being broken. Do you want me or Vlad to revert the patch? Or you will revert the patch? Thanks, David
Re: [Patch] Fix type of clock_t in timevar.c
On Nov 1, 2013, at 12:56 PM, Steve Ellcey sell...@mips.com wrote: You should report a bug to them and have them define clock_t. They are defining clock_t, but for some reason the GCC configure is not seeing it (perhaps because of what header files get included). Curious, do you have sys/time.h? If so, that's likely the cause, as system.h does this: # if HAVE_SYS_TIME_H # include sys/time.h # else # ifdef HAVE_TIME_H # include time.h # endif # endif thus cleverly avoiding even including time.h when it exists. I suspect TIME_WITH_SYS_TIME failed for some silly reason, though, can't guess why. autoconf is fun when it fails.
Re: [Patch] Implementation of n3793 experimental/optional
Hi, Il giorno 01/nov/2013, alle ore 21:09, Jonathan Wakely jwakely@gmail.com ha scritto: Here's the final version of Luc's optional implementation that I'm committing, tested on x86_64-linux. Great. Just noticed a minor nit: the fallback __constexpr_addressof appears not to be inline. Paolo
Re: [Patch] Fix type of clock_t in timevar.c
On Fri, 2013-11-01 at 13:45 -0700, Mike Stump wrote: On Nov 1, 2013, at 12:56 PM, Steve Ellcey sell...@mips.com wrote: You should report a bug to them and have them define clock_t. They are defining clock_t, but for some reason the GCC configure is not seeing it (perhaps because of what header files get included). Curious, do you have sys/time.h? If so, that's likely the cause, as system.h does this: # if HAVE_SYS_TIME_H # include sys/time.h # else # ifdef HAVE_TIME_H # include time.h # endif # endif thus cleverly avoiding even including time.h when it exists. I suspect TIME_WITH_SYS_TIME failed for some silly reason, though, can't guess why. autoconf is fun when it fails. Yes, mingw does have sys/time.h, but their sys/time.h includes time.h so it should work. And now when I try to reproduce the problem it seems to work. I am getting HAVE_CLOCK_T defined in auto-build.h and auto-host.h. Steve Ellcey sell...@mips.com
[RFC] libgcov.c re-factoring and offline profile-tool
libgcov.c is the main file to generate libgcov.a. This single source generates 21 object files and then archives to a library. These objects are of very different purposes but they are in the same file guarded by various macros. The source file becomes quite large and its readability becomes very low. In its current state: 1) The code is very hard to understand by new developers; 2) It makes regressions more likely when making simple changes; More importantly, 3) it makes code reuse/sharing very difficult. For instance, Using libgcov to implement an offline profile tool (see below); kernel FDO support etc. We came to this issue when working on an offline tool to handle profile counters. Our plan is to have a profile-tool can merge, diff, collect statistics, and better dump raw profile counters. This is one of the most requested features from out internal users. This tool can also be very useful for any FDO/coverage users. In the first part of tool, we want to have the weight merge. Again, to reuse the code, we have to change libgcov.c. But we don't want to further diverge libgcov.a in our google branches from the trunk. Another issue in libgcov.c is function gcov_exit(). It is a huge function with about 467 lines of code. This function traverses gcov_list and dumps all the gcda files. The code for merging the gcda files also sits in the same function. The structure makes the code-reuse and extension really difficult (like in kernel FDO, we have to break this function to reuse some of the code). We propose to break gcov_exit into smaller functions and split libgcov.c into several files. Our plan for profile-tool is listed in (3). 1. break gcov_exit() into the following structure: gcov_exit() -- gcov_exit_compute_summary() -- allocate_filename_struct() for gi_ptr in gcov_list -- gcov_exit_dump_gcov() -- gcov_exit_open_gcda_file() -- gcov_exit_merge_gcda () -- gcov_exit_write_gcda () 2. split libgcov.c into the following files: libgcov-profiler.c libgcov-merge.c libgcov-interface.c libgcov-driver.c libgcov-driver-system.c (source included into libgcov-driver.c) The details of the splitting: libgcov-interface.c /* This file contains API functions to other programs and the supporting functions. */ __gcov_dump() __gcov_execl() __gcov_execle() __gcov_execlp() __gcov_execv() __gcov_execve() __gcov_execvp() __gcov_flush() __gcov_fork() __gcov_reset() init_mx() init_mx_once() libgcov-profiler.c /* This file contains runtime profile handlers. */ variables: __gcov_indirect_call_callee __gcov_indirect_call_counters functions: __gcov_average_profiler() __gcov_indirect_call_profiler() __gcov_indirect_call_profiler_v2() __gcov_interval_profiler() __gcov_ior_profiler() __gcov_one_value_profiler() __gcov_one_value_profiler_body() __gcov_pow2_profiler() libgcov-merge.c /* This file contains the merge functions for various counters. */ functions: __gcov_merge_add() __gcov_merge_delta() __gcov_merge_ior() __gcov_merge_single() libcov-driver.c /* This file contains the gcov dumping functions. We separate the system dependent part to libgcov-driver-system.c. */ variables: gcov_list gcov_max_filename gcov_dump_complete -- newly added file static variables -- this_prg all_prg crc32 gi_filename fn_buffer fn_tail sum_buffer next_sum_buffer sum_tail - end - functions: free_fn_data() buffer_fn_data() crc32_unsigned() gcov_version() gcov_histogram_insert() gcov_compute_histogram() gcov_clear() __gcov_init() gcov_exit() --- newly added static functions -- gcov_exit_compute_summary () gcov_exit_merge_gcda() gcov_exit_write_gcda() gcov_exit_dump_gcov() - end - libgcov-driver-system.c /* system dependent part of ligcov-driver.c. */ functions: create_file_directory() --- newly added static functions -- gcov_error() /* This replaces all fprintf(stderr, ...) */ allocate_filename_struct() gcov_exit_open_gcda_file() 3. add offline profile-tool support. We will change the interface of merge functions to make it take in-memory gcov_info list, and a weight as the arguments. We will add libgcov-tool.c. It has two APIs: (1) read_profile_dir(): read a profile directory and reconstruct the gcov_info link list in-memory. (2) merge_profiles(): merge two in-memory gcov_info link list. We also add profile-tool.c in gcc directory. It will source-include libgcov-tool.c and build a host binary. (We don't do library style because that will need a hard dependence from gcc to libgcc). profile-tool.c will mainly handle user options and the write-out of gcov-info link list. Some changes in gcov-io.[ch] will be also needed. Thanks,
Re: [PATCH 0/6] Conversion of gimple types to C++ inheritance (v3)
On 10/31/2013 12:26 PM, David Malcolm wrote:
[Shamelessly hijacking Andrew's thread about gimple.h refactoring,
since this seems on-topic for that, and I'm keen to hear from Andrew on
how the following would interact with his work - I *think* our two
cleanups are orthogonal.
Mostly orthogonal anyway... just stomping on the same bits :-).
Since you hijacked a planning thread, do you plan to take this any
further, or make this change and move on to something else?
It is a start, but it doesnt do the rest of the work that needs doing to
really take advantage of it... which will be extensive.
for instance, we should change:
static inline void
! gimple_call_set_lhs (gimple gs, tree lhs)
{
- GIMPLE_CHECK (gs, GIMPLE_CALL);
gimple_set_op (gs, 0, lhs);
to
static inline void
! gimple_call_set_lhs (gimple_statement_call *gs, tree lhs)
{
gimple_set_op (gs, 0, lhs);
but then every location that calls it needs an appropriate change:
! gimple call;
! call = gimple_build_call_vec (build_fold_addr_expr_loc (0,
alias), vargs);
gimple_call_set_lhs (call, atree);
--- 1518,1524
! gimple_statement_call *call;
! call = as_agimple_statement_call (gimple_build_call_vec
(build_fold_addr_expr_loc (0, alias), vargs));
gimple_call_set_lhs (call, atree);
And in fact there is a ripple effect to then change
gimple_build_call_vec to simply return a gimple_statement_call *... Then
this doesn't look as ugly either...
! gimple_statement_call *call;
! call = gimple_build_call_vec (build_fold_addr_expr_loc (0,
alias), vargs);
gimple_call_set_lhs (call, atree);
that is looking much better :-)
Leaving the names as they are should be ok, but the I'd also add a
typedef for the pointer without the 'statement' in the name.. ie
typedef gimple_statement_call *gimple_call;
That seems in line with what we do with 'gimple' right now and the short
form is the type we'd normally use.
That adds a touch of difficulty with as_a, since that requires the
type name, not the shorthand pointer so you have something like
gimple_call call = as_a gimple_statement_call blah().
I think as the changes to use the gimple_call type are pushed through
all the callers and callee's, the requirement of as_a and the long name
being ugly begins to rapidly disappear... it'll only exist in the core
creation routines and no one will usually see it. So I don't *think*
this is an issue... but it is an ugly transition if its only partially
done.
And eventually we can pull the accessor routines and others into the
class itself:
gimple_call call;
call = gimple_build_call_vec (build_fold_addr_expr_loc (0,
alias), vargs);
call-set_lhs (atree);
Which results in a similar feel to the new gimple_type, gimple_decl,
etc. classes with my upcoming tree wrappers. Changing gimple statements
to behave something like this is actually mentioned in the plan, but out
in the future once trees have been taken care of.
I would also plan to create instances for each of the gimple statements
that don't have them now, like gimple_statement_assign. Its lumped in as
a general GSS_WITH_MEM_OPS, so there is no gimple_statement_assign
class/struct to use.
It would really be nice to use the DEFGSCODE macro and gimple.def to
make this happen automagically somehow... Its tantalizingly close now I
think, especially combined with the info in gsstruct.def... Although if
we are moving to proper classes eventually its probably better to
explicitly write the required class for a statement kind.
That all said, this change enables that work to proceed if someone wants
to do it.
My question is: Is anyone going to do it, and if so, who and when? :-)
Again, as noted in the earlier patch series, the names of the structs
are rather verbose. I would prefer to also rename them all to eliminate
the _statement component:
gimple_statement_base - gimple_base
gimple_statement_phi - gimple_phi
gimple_statement_omp - gimple_omp
etc, but I didn't do this to mimimize the patch size. But if the core
maintainers are up for that, I can redo the patch series with that
change also, or do that as a followup.
As mentioned, I'd rather see the short names be typedefs for pointers to
the long names since we're typically using the pointers.
Other than stomping on the same bits at the moment (less so once
gimple-stmt.[ch] is split out), these changes are completely orthogonal,
but in line with with my direction. I think It should be done sooner or
later My preference is to also see the follow up work carried out
as well. Or at least a plan for it.
Andrew
New Turkish PO file for 'cpplib' (version 4.8.0)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'cpplib' has been submitted by the Turkish team of translators. The file is available at: http://translationproject.org/latest/cpplib/tr.po (This file, 'cpplib-4.8.0.tr.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: http://translationproject.org/latest/cpplib/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/cpplib.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator. coordina...@translationproject.org
Contents of PO file 'cpplib-4.8.0.tr.po'
cpplib-4.8.0.tr.po.gz Description: Binary data The Translation Project robot, in the name of your translation coordinator. coordina...@translationproject.org
Re: [PATCH 0/6] Conversion of gimple types to C++ inheritance (v3)
On Fri, Nov 01, 2013 at 05:36:34PM -0400, Andrew MacLeod wrote:
static inline void
! gimple_call_set_lhs (gimple gs, tree lhs)
{
- GIMPLE_CHECK (gs, GIMPLE_CALL);
gimple_set_op (gs, 0, lhs);
to
static inline void
! gimple_call_set_lhs (gimple_statement_call *gs, tree lhs)
{
gimple_set_op (gs, 0, lhs);
but then every location that calls it needs an appropriate change:
! gimple call;
! call = gimple_build_call_vec (build_fold_addr_expr_loc (0,
alias), vargs);
gimple_call_set_lhs (call, atree);
--- 1518,1524
! gimple_statement_call *call;
! call = as_agimple_statement_call (gimple_build_call_vec
(build_fold_addr_expr_loc (0, alias), vargs));
gimple_call_set_lhs (call, atree);
And in fact there is a ripple effect to then change
gimple_build_call_vec to simply return a gimple_statement_call *...
Then this doesn't look as ugly either...
! gimple_statement_call *call;
! call = gimple_build_call_vec (build_fold_addr_expr_loc (0,
alias), vargs);
gimple_call_set_lhs (call, atree);
that is looking much better :-)
Do you seriously think this is an improvement? The cost of changing
the --enable-checking=yes cost to compile time checking in either
cases sounds way too high to me. Please don't.
Jakub
Re: [Patch] Fix type of clock_t in timevar.c
On Nov 1, 2013, at 1:50 PM, Steve Ellcey sell...@mips.com wrote: Yes, mingw does have sys/time.h, but their sys/time.h includes time.h so it should work. And now when I try to reproduce the problem it seems to work. :-) Don't worry, when I was in getting my degree, I helped out in the lab, some bugs know it's me and run away; this is normal.
Re: [PATCH 0/6] Conversion of gimple types to C++ inheritance (v3)
On 11/01/2013 05:41 PM, Jakub Jelinek wrote:
On Fri, Nov 01, 2013 at 05:36:34PM -0400, Andrew MacLeod wrote:
static inline void
! gimple_call_set_lhs (gimple gs, tree lhs)
{
- GIMPLE_CHECK (gs, GIMPLE_CALL);
gimple_set_op (gs, 0, lhs);
to
static inline void
! gimple_call_set_lhs (gimple_statement_call *gs, tree lhs)
{
gimple_set_op (gs, 0, lhs);
but then every location that calls it needs an appropriate change:
! gimple call;
! call = gimple_build_call_vec (build_fold_addr_expr_loc (0,
alias), vargs);
gimple_call_set_lhs (call, atree);
--- 1518,1524
! gimple_statement_call *call;
! call = as_agimple_statement_call (gimple_build_call_vec
(build_fold_addr_expr_loc (0, alias), vargs));
gimple_call_set_lhs (call, atree);
And in fact there is a ripple effect to then change
gimple_build_call_vec to simply return a gimple_statement_call *...
Then this doesn't look as ugly either...
! gimple_statement_call *call;
! call = gimple_build_call_vec (build_fold_addr_expr_loc (0,
alias), vargs);
gimple_call_set_lhs (call, atree);
that is looking much better :-)
Do you seriously think this is an improvement? The cost of changing
the --enable-checking=yes cost to compile time checking in either
cases sounds way too high to me. Please don't.
What checking? There ought to be no checking at all in this example...
gimple_build_call_vec returns a gimple_call, and gimple_call_set_lhs()
doesn't have to check anything because it only accepts gimple_call's..
so there is no checking other than the usual does my parameter match
that the compiler has to do...
What extra are you expecting?
Andrew
Re: [PATCH 0/6] Conversion of gimple types to C++ inheritance (v3)
On Fri, Nov 01, 2013 at 05:47:14PM -0400, Andrew MacLeod wrote:
On 11/01/2013 05:41 PM, Jakub Jelinek wrote:
On Fri, Nov 01, 2013 at 05:36:34PM -0400, Andrew MacLeod wrote:
static inline void
! gimple_call_set_lhs (gimple gs, tree lhs)
{
- GIMPLE_CHECK (gs, GIMPLE_CALL);
The checking you are removing here.
What checking? There ought to be no checking at all in this
example... gimple_build_call_vec returns a gimple_call, and
gimple_call_set_lhs() doesn't have to check anything because it
only accepts gimple_call's.. so there is no checking other than the
usual does my parameter match that the compiler has to do...
and want to replace it by checking of the types at compile time.
The problem is that it uglifies the source too much, and, when you
actually don't have a gimple_call but supposedly a base class of it,
I expect you'd do as_a which is not only further uglification, but has
runtime cost also for --enable-checking=release.
Jakub
Re: [PATCH, MPX, 2/X] Pointers Checker [6/25] Instrumentation pass
On Thu, 31 Oct 2013, Ilya Enkovich wrote: * tree-chkp.c: New. This file includes tm.h. Inclusion of tm.h in front-end and GIMPLE files is discouraged (well, we'd like to convert all target macros to hooks, but the limited subset used in front-end and GIMPLE files are lower-hanging fruit than eliminating tm.h from the RTL parts of the compiler). If you need it, please put a comment on the #include saying exactly what target macros you need, so people know which macros' conversion to hooks would eliminate the need for the tm.h inclusion. * tree.h (DECL_BOUNDS_RTL): New. (SET_DECL_BOUNDS_RTL): New. (DECL_BOUNDS): New. (SET_DECL_BOUNDS): New. (chkp_get_rtl_bounds): New. A lot of work is in progress to split up catch-all headers such as tree.h and to get source files to include only those headers they need. I'm doubtful that all these chkp_* declarations really belong in such a widely-included header. I'd think it would be better to put them in a tree-chkp.h header and include that header only in those source files that need it. (Of course, if any function isn't needed outside tree-chkp.c, make it static. The header is only for those functions that are actually used in at least one other source file.) -- Joseph S. Myers jos...@codesourcery.com
Re: [PATCH] LRA: Fix incorrect register spill/reload
On 11/01/13 14:39, David Edelsohn wrote: On Fri, Nov 1, 2013 at 3:45 PM, Jeff Law l...@redhat.com wrote: On 10/31/13 14:03, Robert Suchanek wrote: Hi David, No, I do not have read/write SVN access. I know a person who could commit the patch for me, however, if you can commit it, I'd be grateful. Note, I didn't see anywhere in this thread an indication this test had been through a bootstrap and regression testing. I was running those overnight on Robert's behalf and the bootstrap test failed with a comparison failure between stage2/toplev.o and stage3/toplev.o Vlad, when approving patches, please make sure they've been through the usual bootstrap and regression testing procedures. If the contributor hasn't done it themselves, you can either do it for them or ask them to do it. I trust y'all will address the problem appropriately. I bootstrapped on powerpc without problem, but Vlad earlier said that the code applies to an x86 case. I have not seen a deluge of complaints about bootstrap being broken. Do you want me or Vlad to revert the patch? Or you will revert the patch? I'm not in a rush to revert... I don't plan on doing anything on the trunk over the weekend. I'm comfortable waiting until Monday, both to see if anyone else trips over whatever is going wrong and to give Robert or anyone else time to debug. Jeff
Re: [PATCH, MPX, 2/X] Pointers Checker [8/25] Languages support
On Thu, 31 Oct 2013, Ilya Enkovich wrote: This patch adds support Pointer Bounds Checker into c-family and LTO front-ends. The main purpose of changes in front-end is to register all statically initialized objects for checker. We also need to register such objects created by compiler. What happens with statically initialized TLS objects? It would seem that you need something like how the C++ front end handles static constructors for C++11 thread-local objects, but I don't see anything obvious for that here. -- Joseph S. Myers jos...@codesourcery.com
[PATCH] * MAINTAINERS (Write After Approval): Add myself.
From: tbsaunde tbsaunde@138bc75d-0d04-0410-961f-82ee72b054a4 diff --git a/ChangeLog b/ChangeLog index e925959..8c24d35 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,7 @@ +2013-11-01 Trevor Saunders tsaund...@mozilla.com + +* MAINTAINERS (Write After Approval): Add myself. + 2013-10-30 Jason Merrill ja...@redhat.com * Makefile.tpl (STAGE1_CONFIGURE_FLAGS): Pass diff --git a/MAINTAINERS b/MAINTAINERS index bf16972..25ae10e 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -514,6 +514,7 @@ Matthew Sachs msa...@apple.com Hariharan Sandanagobalane hariharan@gmail.com Iain Sandoei...@codesourcery.com Duncan Sands baldr...@gcc.gnu.org +Trevor Saunderstsaund...@mozilla.com William Schmidtwschm...@linux.vnet.ibm.com Tilo Schwarz t...@tilo-schwarz.de Dodji Seketeli do...@gcc.gnu.org -- 1.8.4.2
Re: [PATCH] LRA: Fix incorrect register spill/reload
On Nov 1, 2013, at 12:45 PM, Jeff Law l...@redhat.com wrote: Vlad, when approving patches, please make sure they've been through the usual bootstrap and regression testing procedures. I usually place the blame on the person committing it, as they broke it. :-)
PR 58958: wrong aliasing info
Hello,
the issue was described in the PR and the message linked from there.
ao_ref_init_from_ptr_and_size calls get_ref_base_and_extent, which may
detect an array_ref of variable index, but ao_ref_init_from_ptr_and_size
never learns of it and uses the offset+size as if they were meaningful.
Bootstrap+testsuite on x86_64-unknown-linux-gnu.
2013-11-04 Marc Glisse marc.gli...@inria.fr
PR tree-optimization/
gcc/
* tree-dfa.h (get_addr_base_and_unit_offset_1): Add error reporting.
* tree-ssa-alias.c (ao_ref_init_from_ptr_and_size): Use
get_addr_base_and_unit_offset_1 instead of get_ref_base_and_extent.
gcc/testsuite/
* gcc.dg/tree-ssa/pr58958.c: New file.
--
Marc GlisseIndex: gcc/testsuite/gcc.dg/tree-ssa/pr58958.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/pr58958.c (revision 0)
+++ gcc/testsuite/gcc.dg/tree-ssa/pr58958.c (working copy)
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options -O2 -fdump-tree-optimized } */
+
+double a[10];
+int f(int n){
+ a[3]=9;
+ __builtin_memset(a[n],3,sizeof(double));
+ return a[3]==9;
+}
+
+/* { dg-final { scan-tree-dump == 9 optimized } } */
+/* { dg-final { cleanup-tree-dump optimized } } */
Property changes on: gcc/testsuite/gcc.dg/tree-ssa/pr58958.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/tree-dfa.h
===
--- gcc/tree-dfa.h (revision 204302)
+++ gcc/tree-dfa.h (working copy)
@@ -30,65 +30,70 @@ extern tree ssa_default_def (struct func
extern void set_ssa_default_def (struct function *, tree, tree);
extern tree get_or_create_ssa_default_def (struct function *, tree);
extern tree get_ref_base_and_extent (tree, HOST_WIDE_INT *,
HOST_WIDE_INT *, HOST_WIDE_INT *);
extern tree get_addr_base_and_unit_offset (tree, HOST_WIDE_INT *);
extern bool stmt_references_abnormal_ssa_name (gimple);
extern void dump_enumerated_decls (FILE *, int);
/* Returns the base object and a constant BITS_PER_UNIT offset in *POFFSET that
denotes the starting address of the memory access EXP.
- Returns NULL_TREE if the offset is not constant or any component
- is not BITS_PER_UNIT-aligned.
+ If the offset is not constant or any component is not BITS_PER_UNIT-aligned,
+ sets *SAFE to false or returns NULL_TREE if SAFE is NULL.
VALUEIZE if non-NULL is used to valueize SSA names. It should return
its argument or a constant if the argument is known to be constant. */
/* ??? This is a static inline here to avoid the overhead of the indirect calls
to VALUEIZE. But is this overhead really that significant? And should we
perhaps just rely on WHOPR to specialize the function? */
static inline tree
get_addr_base_and_unit_offset_1 (tree exp, HOST_WIDE_INT *poffset,
-tree (*valueize) (tree))
+tree (*valueize) (tree), bool *safe = NULL)
{
HOST_WIDE_INT byte_offset = 0;
+ bool issafe = true;
/* Compute cumulative byte-offset for nested component-refs and array-refs,
and find the ultimate containing object. */
while (1)
{
switch (TREE_CODE (exp))
{
case BIT_FIELD_REF:
{
HOST_WIDE_INT this_off = TREE_INT_CST_LOW (TREE_OPERAND (exp, 2));
if (this_off % BITS_PER_UNIT)
- return NULL_TREE;
- byte_offset += this_off / BITS_PER_UNIT;
+ issafe = false;
+ else
+ byte_offset += this_off / BITS_PER_UNIT;
}
break;
case COMPONENT_REF:
{
tree field = TREE_OPERAND (exp, 1);
tree this_offset = component_ref_field_offset (exp);
HOST_WIDE_INT hthis_offset;
if (!this_offset
|| TREE_CODE (this_offset) != INTEGER_CST
|| (TREE_INT_CST_LOW (DECL_FIELD_BIT_OFFSET (field))
% BITS_PER_UNIT))
- return NULL_TREE;
-
- hthis_offset = TREE_INT_CST_LOW (this_offset);
- hthis_offset += (TREE_INT_CST_LOW (DECL_FIELD_BIT_OFFSET (field))
-/ BITS_PER_UNIT);
- byte_offset += hthis_offset;
+ issafe = false;
+ else
+ {
+ hthis_offset = TREE_INT_CST_LOW (this_offset);
+ hthis_offset +=
+ (TREE_INT_CST_LOW (DECL_FIELD_BIT_OFFSET (field))
+ / BITS_PER_UNIT);
+ byte_offset += hthis_offset;
+ }
}
break;
case ARRAY_REF:
case ARRAY_RANGE_REF:
{
tree index = TREE_OPERAND (exp, 1);
Re: [PATCH 0/6] Conversion of gimple types to C++ inheritance (v3)
On Fri, 2013-11-01 at 17:36 -0400, Andrew MacLeod wrote:
On 10/31/2013 12:26 PM, David Malcolm wrote:
[Shamelessly hijacking Andrew's thread about gimple.h refactoring,
since this seems on-topic for that, and I'm keen to hear from Andrew on
how the following would interact with his work - I *think* our two
cleanups are orthogonal.
Mostly orthogonal anyway... just stomping on the same bits :-).
Since you hijacked a planning thread, do you plan to take this any
further, or make this change and move on to something else?
I have various changes that are mostly done that I'm trying to get
finished and into trunk for stage1. These can be seen at:
https://github.com/davidmalcolm/gcc-refactoring-scripts/blob/master/README.rst
If you want me to do more follow cleanups to gimple, I can do those.
It is a start, but it doesnt do the rest of the work that needs doing to
really take advantage of it... which will be extensive.
for instance, we should change:
static inline void
! gimple_call_set_lhs (gimple gs, tree lhs)
{
- GIMPLE_CHECK (gs, GIMPLE_CALL);
gimple_set_op (gs, 0, lhs);
to
static inline void
! gimple_call_set_lhs (gimple_statement_call *gs, tree lhs)
{
gimple_set_op (gs, 0, lhs);
but then every location that calls it needs an appropriate change:
! gimple call;
! call = gimple_build_call_vec (build_fold_addr_expr_loc (0,
alias), vargs);
gimple_call_set_lhs (call, atree);
--- 1518,1524
! gimple_statement_call *call;
! call = as_agimple_statement_call (gimple_build_call_vec
(build_fold_addr_expr_loc (0, alias), vargs));
gimple_call_set_lhs (call, atree);
And in fact there is a ripple effect to then change
gimple_build_call_vec to simply return a gimple_statement_call *... Then
this doesn't look as ugly either...
! gimple_statement_call *call;
! call = gimple_build_call_vec (build_fold_addr_expr_loc (0,
alias), vargs);
gimple_call_set_lhs (call, atree);
that is looking much better :-)
I'd love to make use of compile-time type-safety like this, but does
this have to gate this initial step?
The transition to strongly-typed getters/setters could be done one
at-a-time, I guess.
Leaving the names as they are should be ok, but the I'd also add a
typedef for the pointer without the 'statement' in the name.. ie
typedef gimple_statement_call *gimple_call;
That seems in line with what we do with 'gimple' right now and the short
form is the type we'd normally use.
That adds a touch of difficulty with as_a, since that requires the
type name, not the shorthand pointer so you have something like
gimple_call call = as_a gimple_statement_call blah().
I think as the changes to use the gimple_call type are pushed through
all the callers and callee's, the requirement of as_a and the long name
being ugly begins to rapidly disappear... it'll only exist in the core
creation routines and no one will usually see it. So I don't *think*
this is an issue... but it is an ugly transition if its only partially
done.
(nods)
And eventually we can pull the accessor routines and others into the
class itself:
gimple_call call;
call = gimple_build_call_vec (build_fold_addr_expr_loc (0,
alias), vargs);
call-set_lhs (atree);
Nice. It's readable (IMHO), and the type-checking (that it's a call) is
enforced at compile-time, rather than at run-time (and only in
ENABLE_CHECKING builds).
Sadly, this may need some further gengtype work: the simple inheritance
support I'm using in this patch series will barf if it sees methods
within a class. So I can have a look at supporting methods in gengtype,
I guess. Though the change above of gimple_call_set_lhs to accepting a
subclass ptr gives a middle-ground.
Which results in a similar feel to the new gimple_type, gimple_decl,
etc. classes with my upcoming tree wrappers. Changing gimple statements
to behave something like this is actually mentioned in the plan, but out
in the future once trees have been taken care of.
I would also plan to create instances for each of the gimple statements
By instances presumably you meant subclasses?
that don't have them now, like gimple_statement_assign. Its lumped in as
a general GSS_WITH_MEM_OPS, so there is no gimple_statement_assign
class/struct to use.
It would really be nice to use the DEFGSCODE macro and gimple.def to
make this happen automagically somehow... Its tantalizingly close now I
think, especially combined with the info in gsstruct.def... Although if
we are moving to proper classes eventually its probably better to
explicitly write the required class for a statement kind.
I think writing them out explicitly is better than doing them with
preprocessor magic: if we go down the route described above of wanting
to add methods, the various subclasses will eventually gain their own
methods, so
Re: [PATCH 0/6] Conversion of gimple types to C++ inheritance (v3)
On Fri, 2013-11-01 at 22:57 +0100, Jakub Jelinek wrote:
On Fri, Nov 01, 2013 at 05:47:14PM -0400, Andrew MacLeod wrote:
On 11/01/2013 05:41 PM, Jakub Jelinek wrote:
On Fri, Nov 01, 2013 at 05:36:34PM -0400, Andrew MacLeod wrote:
static inline void
! gimple_call_set_lhs (gimple gs, tree lhs)
{
- GIMPLE_CHECK (gs, GIMPLE_CALL);
The checking you are removing here.
What checking? There ought to be no checking at all in this
example... gimple_build_call_vec returns a gimple_call, and
gimple_call_set_lhs() doesn't have to check anything because it
only accepts gimple_call's.. so there is no checking other than the
usual does my parameter match that the compiler has to do...
and want to replace it by checking of the types at compile time.
The problem is that it uglifies the source too much, and, when you
actually don't have a gimple_call but supposedly a base class of it,
I expect you'd do as_a which is not only further uglification, but has
runtime cost also for --enable-checking=release.
I can have a look next week at every call to gimple_call_set_lhs in the
tree, and see to what extent we know at compile-time that the initial
arg is indeed a call (of the ones I quickly grepped just now, most are
from gimple_build_call and friends, but one was from a gimple_copy).
FWIW I did some performance testing of the is_a/as_a code in the earlier
version of the patch, and it didn't have a noticable runtime cost
compared to the GIMPLE_CHECK in the existing code:
Size of compiler executable:
http://gcc.gnu.org/ml/gcc-patches/2013-08/msg01920.html
Compile times:
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00171.html
Dave
Re: libsanitizer merge from upstream r191666
On Fri, Nov 01, 2013 at 04:13:05PM -0700, Konstantin Serebryany wrote: 2013-10-XX Kostya Serebryany k...@google.com It is November now ;) Looks good to me, except for a few ChangeLog issues: Update to match the changed asan API. * asan.c: (asan_function_start): New function. Wrong ChangeLog formatting. The above should be: * asan.c (asan_function_start): New function. (asan_emit_stack_protection): Update the string stored in the stack red zone to match new API. Store the PC of the current function in the red zone. (asan_global_struct): Update the __asan_global definition to match the new API. (asan_add_global): Ditto. * asan.h: Declare asan_function_start. This should be: * asan.h (asan_function_start): New prototype. * final.c: (final_start_function): Call asan_function_start. Again, remove the first :, newline and whitespace (except for one space). * sanitizer.def: Rename __asan_init_v1 to __asan_init_v3. * sanitizer.def (BUILT_IN_ASAN_INIT): Rename from __asan_init_v1 to __asan_init_v3. === libsanitizer/ChangeLog 2013-10-XX Kostya Serebryany k...@google.com * All source files: Merge from upstream r191666. * merge.sh: Added lsan. * configure.ac: Added lsan. * configure.ac (AC_CONFIG_FILES): Added lsan. * Makefile.am: Added lsan. * Makefile.am (SUBDIRS): Add lsan. * sanitizer_common/Makefile.am: Added lsan. That is not what you've changed. You've changed * sanitizer_common/Makefile.am (sanitizer_common_files): and changed formatting and added a few files, but nothing related to lsan. * asan/Makefile.am: Added dependency on lsan. Again, list what you've changed there and describe the changes. * lsan/Makefile.am: New file. * asan/Makefile.in: Regenerate. * lsan/Makefile.in: Regenerate. * Makefile.in: Regenerate. * configure: Regenerate. * sanitizer_common/Makefile.in: Regenerate. Ok with those changes. Jakub
Re: [PATCH 0/6] Conversion of gimple types to C++ inheritance (v3)
It is a start, but it doesnt do the rest of the work that needs doing to
really take advantage of it... which will be extensive.
for instance, we should change:
static inline void
! gimple_call_set_lhs (gimple gs, tree lhs)
{
- GIMPLE_CHECK (gs, GIMPLE_CALL);
gimple_set_op (gs, 0, lhs);
to
static inline void
! gimple_call_set_lhs (gimple_statement_call *gs, tree lhs)
{
gimple_set_op (gs, 0, lhs);
but then every location that calls it needs an appropriate change:
! gimple call;
! call = gimple_build_call_vec (build_fold_addr_expr_loc (0,
alias), vargs);
gimple_call_set_lhs (call, atree);
--- 1518,1524
! gimple_statement_call *call;
! call = as_agimple_statement_call (gimple_build_call_vec
(build_fold_addr_expr_loc (0, alias), vargs));
gimple_call_set_lhs (call, atree);
And in fact there is a ripple effect to then change
gimple_build_call_vec to simply return a gimple_statement_call *... Then
this doesn't look as ugly either...
! gimple_statement_call *call;
! call = gimple_build_call_vec (build_fold_addr_expr_loc (0,
alias), vargs);
gimple_call_set_lhs (call, atree);
that is looking much better :-)
I'd love to make use of compile-time type-safety like this, but does
this have to gate this initial step?
I don't think Andrew was suggesting it should, but fwiw I agree with
you one step at a time.
The transition to strongly-typed getters/setters could be done one
at-a-time, I guess.
I actually have a slightly different suggestion, see below.
Leaving the names as they are should be ok, but the I'd also add a
typedef for the pointer without the 'statement' in the name.. ie
typedef gimple_statement_call *gimple_call;
That seems in line with what we do with 'gimple' right now and the short
form is the type we'd normally use.
That adds a touch of difficulty with as_a, since that requires the
type name, not the shorthand pointer so you have something like
gimple_call call = as_a gimple_statement_call blah().
I think as the changes to use the gimple_call type are pushed through
all the callers and callee's, the requirement of as_a and the long name
being ugly begins to rapidly disappear... it'll only exist in the core
creation routines and no one will usually see it. So I don't *think*
this is an issue... but it is an ugly transition if its only partially
done.
(nods)
And eventually we can pull the accessor routines and others into the
class itself:
gimple_call call;
call = gimple_build_call_vec (build_fold_addr_expr_loc (0,
alias), vargs);
call-set_lhs (atree);
Nice. It's readable (IMHO), and the type-checking (that it's a call) is
enforced at compile-time, rather than at run-time (and only in
ENABLE_CHECKING builds).
Well, if you never need to downcast its always enforced by the type
system.
Sadly, this may need some further gengtype work: the simple inheritance
support I'm using in this patch series will barf if it sees methods
within a class. So I can have a look at supporting methods in gengtype,
I guess. Though the change above of gimple_call_set_lhs to accepting a
subclass ptr gives a middle-ground.
hm, I have a patch around that adds member functions to symtab_node and
gentype doesn't fall over on it, is it just sub classes maybe?
Anyway to avoid churn multiple times / ugly intermediates what I think
we should do is:
1. add methods to the sub classes as appropriate (fixing gentype first
if needed).
2. change creator functions to return dirived types.
3. when we already have the sub type replace the function with the
method.
4. when all uses of the function are gone remove it.
that don't have them now, like gimple_statement_assign. Its lumped in as
a general GSS_WITH_MEM_OPS, so there is no gimple_statement_assign
class/struct to use.
It would really be nice to use the DEFGSCODE macro and gimple.def to
make this happen automagically somehow... Its tantalizingly close now I
think, especially combined with the info in gsstruct.def... Although if
we are moving to proper classes eventually its probably better to
explicitly write the required class for a statement kind.
I think writing them out explicitly is better than doing them with
preprocessor magic: if we go down the route described above of wanting
to add methods, the various subclasses will eventually gain their own
methods, so we'll want code rather than building it all from .def files.
agreed.
That all said, this change enables that work to proceed if someone wants
to do it.
My question is: Is anyone going to do it, and if so, who and when? :-)
I'd be up for working on a followup patch that adds such subclasses, and
I'd be up for changing the accessors to give up compile-time
type-safety.
Re: libsanitizer merge from upstream r191666
Fixed all. I'll commit on Monday so that I can respond to any failures if they appear quickly. Thanks! --kcc === gcc/testsuite/ChangeLog 2013-11-04 Kostya Serebryany k...@google.com * g++.dg/asan/asan_test.cc: Update the test to match the fresh asan run-time. * c-c++-common/asan/stack-overflow-1.c: Ditto. === gcc/ChangeLog 2013-11-04 Kostya Serebryany k...@google.com Update to match the changed asan API. * asan.c (asan_function_start): New function. (asan_emit_stack_protection): Update the string stored in the stack red zone to match new API. Store the PC of the current function in the red zone. (asan_global_struct): Update the __asan_global definition to match the new API. (asan_add_global): Ditto. * asan.h (asan_function_start): New prototype. * final.c (final_start_function): Call asan_function_start. * sanitizer.def (BUILT_IN_ASAN_INIT): Rename __asan_init_v1 to __asan_init_v3. === libsanitizer/ChangeLog 2013-11-04 Kostya Serebryany k...@google.com * All source files: Merge from upstream r191666. * merge.sh: Added lsan. * configure.ac (AC_CONFIG_FILES): Added lsan. * Makefile.am (SUBDIRS): Added lsan. * sanitizer_common/Makefile.am (sanitizer_common_files): Added new fles. * asan/Makefile.am (asan_files): Added new files. (libasan_la_LIBADD): Added a dependency on lsan. * lsan/Makefile.am: New file. * asan/Makefile.in: Regenerate. * lsan/Makefile.in: Regenerate. * Makefile.in: Regenerate. * configure: Regenerate. * sanitizer_common/Makefile.in: Regenerate. On Fri, Nov 1, 2013 at 4:34 PM, Jakub Jelinek ja...@redhat.com wrote: On Fri, Nov 01, 2013 at 04:13:05PM -0700, Konstantin Serebryany wrote: 2013-10-XX Kostya Serebryany k...@google.com It is November now ;) Looks good to me, except for a few ChangeLog issues: Update to match the changed asan API. * asan.c: (asan_function_start): New function. Wrong ChangeLog formatting. The above should be: * asan.c (asan_function_start): New function. (asan_emit_stack_protection): Update the string stored in the stack red zone to match new API. Store the PC of the current function in the red zone. (asan_global_struct): Update the __asan_global definition to match the new API. (asan_add_global): Ditto. * asan.h: Declare asan_function_start. This should be: * asan.h (asan_function_start): New prototype. * final.c: (final_start_function): Call asan_function_start. Again, remove the first :, newline and whitespace (except for one space). * sanitizer.def: Rename __asan_init_v1 to __asan_init_v3. * sanitizer.def (BUILT_IN_ASAN_INIT): Rename from __asan_init_v1 to __asan_init_v3. === libsanitizer/ChangeLog 2013-10-XX Kostya Serebryany k...@google.com * All source files: Merge from upstream r191666. * merge.sh: Added lsan. * configure.ac: Added lsan. * configure.ac (AC_CONFIG_FILES): Added lsan. * Makefile.am: Added lsan. * Makefile.am (SUBDIRS): Add lsan. * sanitizer_common/Makefile.am: Added lsan. That is not what you've changed. You've changed * sanitizer_common/Makefile.am (sanitizer_common_files): and changed formatting and added a few files, but nothing related to lsan. * asan/Makefile.am: Added dependency on lsan. Again, list what you've changed there and describe the changes. * lsan/Makefile.am: New file. * asan/Makefile.in: Regenerate. * lsan/Makefile.in: Regenerate. * Makefile.in: Regenerate. * configure: Regenerate. * sanitizer_common/Makefile.in: Regenerate. Ok with those changes. Jakub
Re: [PATCH] LRA: Fix incorrect register spill/reload
On Fri, Nov 1, 2013 at 6:00 PM, Jeff Law l...@redhat.com wrote: I'm not in a rush to revert... I don't plan on doing anything on the trunk over the weekend. I'm comfortable waiting until Monday, both to see if anyone else trips over whatever is going wrong and to give Robert or anyone else time to debug. What is the exact configuration command that you are using in the build that is failing? If the bootstrap failure is not widespread, then there must be something unique in your configuration. Thanks, David
Expect JUMP_TABLE_DATA in NEXT_INSN(label)
Hello,
As $SUBJECT. The assert for this has been in place for several months
now without triggering any issues, so I'd like to make this next step
before stage1 is over.
OK for trunk?
Ciao!
Steven
* rtlanal.c (tablejump_p): Expect a JUMP_TABLE_DATA to always follow
immediately after a label for a tablejump pattern.
* config/arm/arm.c (is_jump_table): Remove.
(create_fix_barrier): Use tablejump_p instead.
(arm_reorg): Likewise.
(thumb1_output_casesi): Expect JUMP_TABLE_DATA to always be NEXT_INSN.
(thumb2_output_casesi): Likewise.
* config/aarch64/aarch64.c (aarch64_output_casesi): Likewise.
* config/sh/sh.md (casesi_worker_1, casesi_worker_2,
casesi_shift_media, casesi_load_media): Likewise.
* config/iq2000/iq2000.md: Likewise (in anonymous define_insn).
* config/microblaze/microblaze.md: Likewise.
Index: rtlanal.c
===
--- rtlanal.c (revision 204308)
+++ rtlanal.c (working copy)
@@ -2742,10 +2742,9 @@ tablejump_p (const_rtx insn, rtx *labelp, rtx *tab
label = JUMP_LABEL (insn);
if (label != NULL_RTX !ANY_RETURN_P (label)
- (table = next_active_insn (label)) != NULL_RTX
+ (table = NEXT_INSN (label)) != NULL_RTX
JUMP_TABLE_DATA_P (table))
{
- gcc_assert (table == NEXT_INSN (label));
if (labelp)
*labelp = label;
if (tablep)
Index: config/arm/arm.c
===
--- config/arm/arm.c (revision 204308)
+++ config/arm/arm.c (working copy)
@@ -95,13 +95,11 @@ static bool arm_print_operand_punct_valid_p (unsig
static const char *fp_const_from_val (REAL_VALUE_TYPE *);
static arm_cc get_arm_condition_code (rtx);
static HOST_WIDE_INT int_log2 (HOST_WIDE_INT);
-static rtx is_jump_table (rtx);
static const char *output_multi_immediate (rtx *, const char *, const char *,
int, HOST_WIDE_INT);
static const char *shift_op (rtx, HOST_WIDE_INT *);
static struct machine_function *arm_init_machine_status (void);
static void thumb_exit (FILE *, int);
-static rtx is_jump_table (rtx);
static HOST_WIDE_INT get_jump_table_size (rtx);
static Mnode *move_minipool_fix_forward_ref (Mnode *, Mnode *, HOST_WIDE_INT);
static Mnode *add_minipool_forward_ref (Mfix *);
@@ -15468,23 +15466,6 @@ Mfix * minipool_fix_tail;
/* The fix entry for the current minipool, once it has been placed. */
Mfix * minipool_barrier;
-/* Determines if INSN is the start of a jump table. Returns the end
- of the TABLE or NULL_RTX. */
-static rtx
-is_jump_table (rtx insn)
-{
- rtx table;
-
- if (jump_to_label_p (insn)
- ((table = next_active_insn (JUMP_LABEL (insn)))
- == next_active_insn (insn))
- table != NULL
- JUMP_TABLE_DATA_P (table))
-return table;
-
- return NULL_RTX;
-}
-
#ifndef JUMP_TABLES_IN_TEXT_SECTION
#define JUMP_TABLES_IN_TEXT_SECTION 0
#endif
@@ -16093,8 +16074,7 @@ create_fix_barrier (Mfix *fix, HOST_WIDE_INT max_a
count += get_attr_length (from);
/* If there is a jump table, add its length. */
- tmp = is_jump_table (from);
- if (tmp != NULL)
+ if (tablejump_p (from, NULL, tmp))
{
count += get_jump_table_size (tmp);
@@ -16700,7 +16680,7 @@ arm_reorg (void)
/* If the insn is a vector jump, add the size of the table
and skip the table. */
- if ((table = is_jump_table (insn)) != NULL)
+ if (tablejump_p (insn, NULL, table))
{
address += get_jump_table_size (table);
insn = table;
@@ -28610,7 +28590,7 @@ arm_output_iwmmxt_tinsr (rtx *operands)
const char *
thumb1_output_casesi (rtx *operands)
{
- rtx diff_vec = PATTERN (next_active_insn (operands[0]));
+ rtx diff_vec = PATTERN (NEXT_INSN (operands[0]));
gcc_assert (GET_CODE (diff_vec) == ADDR_DIFF_VEC);
@@ -28633,7 +28613,7 @@ thumb1_output_casesi (rtx *operands)
const char *
thumb2_output_casesi (rtx *operands)
{
- rtx diff_vec = PATTERN (next_active_insn (operands[2]));
+ rtx diff_vec = PATTERN (NEXT_INSN (operands[2]));
gcc_assert (GET_CODE (diff_vec) == ADDR_DIFF_VEC);
Index: config/aarch64/aarch64.c
===
--- config/aarch64/aarch64.c (revision 204308)
+++ config/aarch64/aarch64.c (working copy)
@@ -4329,7 +4329,7 @@ aarch64_output_casesi (rtx *operands)
{
char buf[100];
char label[100];
- rtx diff_vec = PATTERN (next_active_insn (operands[2]));
+ rtx diff_vec = PATTERN (NEXT_INSN (operands[2]));
int index;
static const char *const patterns[4][2] =
{
Index: config/sh/sh.md
===
--- config/sh/sh.md (revision 204308)
+++ config/sh/sh.md (working copy)
@@ -10827,7 +10827,7 @@ label:
(clobber (match_scratch:SI 3 =X,1))]
TARGET_SH1
{
- rtx diff_vec = PATTERN (next_active_insn (operands[2]));
+ rtx diff_vec = PATTERN (NEXT_INSN (operands[2]));
gcc_assert (GET_CODE (diff_vec) == ADDR_DIFF_VEC);
@@
Re: Fwd: [PATCH] Scheduling result adjustment to enable macro-fusion
Ping. Is it ok for x86 maintainer?
Thanks,
Wei Mi.
On Wed, Oct 16, 2013 at 4:25 PM, Wei Mi w...@google.com wrote:
Go ahead and consider that pre-approved. Just send it to the list with a
note that I approved it in this thread.
Jeff
Thanks! The new patch addressed Jeff's comments.
Is it ok for x86 maintainer?
Thanks,
Wei Mi.
2013-10-16 Wei Mi w...@google.com
* gcc/config/i386/i386.c (memory_address_length): Extract a part
of code to rip_relative_addr_p.
(rip_relative_addr_p): New Function.
(ix86_macro_fusion_p): Ditto.
(ix86_macro_fusion_pair_p): Ditto.
* gcc/config/i386/i386.h: Add new tune features about macro-fusion.
* gcc/config/i386/x86-tune.def (DEF_TUNE): Ditto.
* gcc/doc/tm.texi: Generated.
* gcc/doc/tm.texi.in: Ditto.
* gcc/haifa-sched.c (try_group_insn): New Function.
(group_insns_for_macro_fusion): Ditto.
(sched_init): Call group_insns_for_macro_fusion.
* gcc/target.def: Add two hooks: macro_fusion_p and
macro_fusion_pair_p.
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 1fd3f60..59b0bcf 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -24204,6 +24204,42 @@ ix86_instantiate_decls (void)
instantiate_decl_rtl (s-rtl);
}
+/* Check whether x86 address PARTS is a pc-relative address. */
+
+static bool
+rip_relative_addr_p (struct ix86_address *parts)
+{
+ rtx base, index, disp;
+
+ base = parts-base;
+ index = parts-index;
+ disp = parts-disp;
+
+ if (disp !base !index)
+{
+ if (TARGET_64BIT)
+ {
+ rtx symbol = disp;
+
+ if (GET_CODE (disp) == CONST)
+ symbol = XEXP (disp, 0);
+ if (GET_CODE (symbol) == PLUS
+ CONST_INT_P (XEXP (symbol, 1)))
+ symbol = XEXP (symbol, 0);
+
+ if (GET_CODE (symbol) == LABEL_REF
+ || (GET_CODE (symbol) == SYMBOL_REF
+ SYMBOL_REF_TLS_MODEL (symbol) == 0)
+ || (GET_CODE (symbol) == UNSPEC
+ (XINT (symbol, 1) == UNSPEC_GOTPCREL
+ || XINT (symbol, 1) == UNSPEC_PCREL
+ || XINT (symbol, 1) == UNSPEC_GOTNTPOFF)))
+ return true;
+ }
+}
+ return false;
+}
+
/* Calculate the length of the memory address in the instruction encoding.
Includes addr32 prefix, does not include the one-byte modrm, opcode,
or other prefixes. We never generate addr32 prefix for LEA insn. */
@@ -24275,25 +24311,8 @@ memory_address_length (rtx addr, bool lea)
else if (disp !base !index)
{
len += 4;
- if (TARGET_64BIT)
- {
- rtx symbol = disp;
-
- if (GET_CODE (disp) == CONST)
- symbol = XEXP (disp, 0);
- if (GET_CODE (symbol) == PLUS
- CONST_INT_P (XEXP (symbol, 1)))
- symbol = XEXP (symbol, 0);
-
- if (GET_CODE (symbol) != LABEL_REF
- (GET_CODE (symbol) != SYMBOL_REF
- || SYMBOL_REF_TLS_MODEL (symbol) != 0)
- (GET_CODE (symbol) != UNSPEC
- || (XINT (symbol, 1) != UNSPEC_GOTPCREL
- XINT (symbol, 1) != UNSPEC_PCREL
- XINT (symbol, 1) != UNSPEC_GOTNTPOFF)))
- len++;
- }
+ if (rip_relative_addr_p (parts))
+ len++;
}
else
{
@@ -24856,6 +24875,122 @@ ia32_multipass_dfa_lookahead (void)
}
}
+/* Return true if target platform supports macro-fusion. */
+
+static bool
+ix86_macro_fusion_p ()
+{
+ if (TARGET_FUSE_CMP_AND_BRANCH)
+return true;
+ else
+return false;
+}
+
+/* Check whether current microarchitecture support macro fusion
+ for insn pair CONDGEN + CONDJMP. Refer to
+ Intel Architectures Optimization Reference Manual. */
+
+static bool
+ix86_macro_fusion_pair_p (rtx condgen, rtx condjmp)
+{
+ rtx src, dest;
+ rtx single_set = single_set (condgen);
+ enum rtx_code ccode;
+ rtx compare_set = NULL_RTX, test_if, cond;
+ rtx alu_set = NULL_RTX, addr = NULL_RTX;
+
+ if (get_attr_type (condgen) != TYPE_TEST
+ get_attr_type (condgen) != TYPE_ICMP
+ get_attr_type (condgen) != TYPE_INCDEC
+ get_attr_type (condgen) != TYPE_ALU)
+return false;
+
+ if (single_set == NULL_RTX
+ !TARGET_FUSE_ALU_AND_BRANCH)
+return false;
+
+ if (single_set != NULL_RTX)
+compare_set = single_set;
+ else
+{
+ int i;
+ rtx pat = PATTERN (condgen);
+ for (i = 0; i XVECLEN (pat, 0); i++)
+ if (GET_CODE (XVECEXP (pat, 0, i)) == SET)
+ {
+ rtx set_src = SET_SRC (XVECEXP (pat, 0, i));
+ if (GET_CODE (set_src) == COMPARE)
+ compare_set = XVECEXP (pat, 0, i);
+ else
+ alu_set = XVECEXP (pat, 0, i);
+ }
+}
+ if (compare_set
Re: [PATCH] LRA: Fix incorrect register spill/reload
On 11/1/2013, 3:45 PM, Jeff Law wrote: On 10/31/13 14:03, Robert Suchanek wrote: Hi David, No, I do not have read/write SVN access. I know a person who could commit the patch for me, however, if you can commit it, I'd be grateful. Note, I didn't see anywhere in this thread an indication this test had been through a bootstrap and regression testing. I was running those overnight on Robert's behalf and the bootstrap test failed with a comparison failure between stage2/toplev.o and stage3/toplev.o Vlad, when approving patches, please make sure they've been through the usual bootstrap and regression testing procedures. If the contributor hasn't done it themselves, you can either do it for them or ask them to do it. I trust y'all will address the problem appropriately. I've tried many bootstraps on the current trunk with this patch (x86_64, i686, x86_64 with arch corei7, with tune corei7). I have no problems. I did not expected from the patch any problems too. It is so obvious. This simple change should not affect x86 (or any other target currently using LRA). The code in question is used only for x86-64 and only for modern intel processing tuning. It is about accuracy of using SSE regs (regs_ever_live) which as I know affects only on saving/restoring regs in prologue/epilogue. As all SSE_REGS are only call-clobbered, the accuracy of this info does not affect code generation. I suspect, the reason for your bootstrap failure was in another patch or you use bootstrap specific options. Sorry.
[PATCH] Added the libcilkrts path to linker
Hello Everyone,
This patch will pass in -Llibcilkrts_path to all the Cilk keywords
testsuite files. This patch should Pass all the Cilk keywords tests failing in
http://gcc.gnu.org/ml/gcc-testresults/2013-11/msg00083.html. Tested no x86_64
SUSE machine (-m32 and -m64 mode) It is committed as obvious. If anyone has
objections (or modifications) please let me know and I am willing to fix them.
Thanks,
Balaji V. Iyer.
diff --git a/gcc/testsuite/gcc.dg/cilk-plus/cilk-plus.exp
b/gcc/testsuite/gcc.dg/cilk-plus/cilk-plus.exp
index a8f00d4..0267fe1 100644
--- a/gcc/testsuite/gcc.dg/cilk-plus/cilk-plus.exp
+++ b/gcc/testsuite/gcc.dg/cilk-plus/cilk-plus.exp
@@ -28,6 +28,9 @@ set library_var [get_multilibs]
# Pointing the ld_library_path to the Cilk Runtime library binaries.
set ld_library_path ${library_var}/libcilkrts/.libs
+set ALWAYS_CFLAGS
+lappend ALWAYS_CFLAGS -L${library_var}/libcilkrts/.libs
+
dg-init
dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/AN/*.c]]
-fcilkplus
dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/AN/*.c]]
-O0 -fcilkplus
@@ -53,29 +56,29 @@ dg-runtest [lsort [glob -nocomplain
$srcdir/c-c++-common/cilk-plus/AN/*.c]] -f
dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/AN/*.c]]
-O3 -ftree-vectorize -std=c99 -g -fcilkplus
-dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]]
-fcilkplus
-dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]]
-O0 -fcilkplus
-dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]]
-O1 -fcilkplus
-dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]]
-O2 -ftree-vectorize -fcilkplus
-dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]]
-O3 -fcilkplus
-dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]]
-g -fcilkplus
-dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]]
-g -O0 -fcilkplus
-dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]]
-g -O1 -fcilkplus
-dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]]
-g -O2 -ftree-vectorize -fcilkplus
-dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]]
-g -O3 -fcilkplus
-dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]]
-O3 -ftree-vectorize -fcilkplus -g
-dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]]
-fcilkplus -std=c99
-dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]]
-fcilkplus -O0 -std=c99
-dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]]
-fcilkplus -O1 -std=c99
-dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]]
-fcilkplus -O2 -ftree-vectorize -std=c99
-dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]]
-fcilkplus -O3 -std=c99
-dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]]
-fcilkplus -g -std=c99
-dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]]
-fcilkplus -g -O0 -std=c99
-dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]]
-fcilkplus -g -O1 -std=c99
-dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]]
-fcilkplus -g -O2 -ftree-vectorize -std=c99
-dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]]
-fcilkplus -g -O3 -std=c99
-dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]]
-O3 -ftree-vectorize -std=c99 -g -fcilkplus
-dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]]
-O0 -flto -g -fcilkplus
-dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]]
-O2 -flto -g -fcilkplus
-dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]]
-O3 -flto -g -fcilkplus
+dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]]
-fcilkplus $ALWAYS_CFLAGS
+dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]]
-O0 -fcilkplus $ALWAYS_CFLAGS
+dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]]
-O1 -fcilkplus $ALWAYS_CFLAGS
+dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]]
-O2 -ftree-vectorize -fcilkplus $ALWAYS_CFLAGS
+dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]]
-O3 -fcilkplus $ALWAYS_CFLAGS
+dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]]
-g -fcilkplus $ALWAYS_CFLAGS
+dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]]
-g -O0 -fcilkplus $ALWAYS_CFLAGS
+dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]]
-g -O1 -fcilkplus $ALWAYS_CFLAGS
+dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]]
-g -O2
