Symbol table 7/many: debug output facilities
Hi,
this patch adds dump_symtab and dump_symtab_node for debugging symbol tables.
It also reorganized existing varpool and cgraph dumping code to use the same
format.
I decided to switch from identifier name to assembler names. It is useless to
see
all those ctor/dtor functions wihtout knowing what they are and it also makes
things
look more like real symbol table.
I left mangled dumping as some places where testsuite require it and will work
on
this incrementally.
Regtested/bootstrapped x86_64-linux, will commit it shortly.
Honza
* cgraph.c (cgraph_node_name): Remove.
(dump_cgraph_node): Use dump_symtab_base; reformat.
* cgraph.h (symtab_node_asm_name, symtab_node_name, dump_symtab,
debug_symtab, dump_symtab_node, debug_symtab_node, dump_symtab_base):
Declare.
(cgraph_node_name, varpool_node_name): Remove.
(cgraph_node_asm_name, varpool_node_asm_name,
cgraph_node_name, varpool_node_name): New.
* tree-pass.h (TODO_dump_cgraph): Rename to ...
(TODO_dump_symtab): ... this one.
* ipa-cp (pass_ipa_cp): Update.
* ia-reference.c (generate_summary, read_write_all_from_decl,
propagate, ipa_reference_read_optimization_summary): Update.
* cgraphunit.c (cgraph_analyze_functions): Update.
(cgraph_optimize): Update.
* ipa-ref.c (ipa_dump_references): Update.
(ipa_dump_refering): Update.
* ipa-inline.c (pass_ipa_inline): Update.
* matrix-reorg.c (pass_ipa_matrix_reorg): Update.
* ipa.c (pass_ipa_function_visibility,
pass_ipa_whole_program_visibility): Update.
* tree-sra.c (pass_early_ipa_sra): Update.
* symtab.c: Include langhooks.h
(symtab_node_asm_name): New.
(symtab_node_name): New.
(symtab_type_names): New static var.
(dump_symtab_base): New.
(dump_symtab_node, dump_symtab): New.
(debug_symtab_node, debug_symtab): New.
* tree-ssa-structalias.c: Dump symbol table.
* pases.c (execute_todo): Handle TODO_dump_symtab instead
of TODO_dump_cgraph.
* varpoo.c (varpool_node_name): Remove.
(dump_varpool_node): Use dump_symtab_base; reformat.
Index: cgraph.c
===
*** cgraph.c(revision 186525)
--- cgraph.c(working copy)
*** cgraph_inline_failed_string (cgraph_inli
*** 1605,1617
return cif_string_table[reason];
}
- /* Return name of the node used in debug output. */
- const char *
- cgraph_node_name (struct cgraph_node *node)
- {
- return lang_hooks.decl_printable_name (node-symbol.decl, 2);
- }
-
/* Names used to print out the availability enum. */
const char * const cgraph_availability_names[] =
{unset, not_available, overwritable, available, local};
--- 1605,1610
*** dump_cgraph_node (FILE *f, struct cgraph
*** 1625,1684
struct cgraph_edge *edge;
int indirect_calls_count = 0;
! fprintf (f, %s/%i, cgraph_node_name (node), node-uid);
! dump_addr (f, @, (void *)node);
! if (DECL_ASSEMBLER_NAME_SET_P (node-symbol.decl))
! fprintf (f, (asm: %s),
!IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (node-symbol.decl)));
if (node-global.inlined_to)
! fprintf (f, (inline copy in %s/%i),
cgraph_node_name (node-global.inlined_to),
!node-global.inlined_to-uid);
! if (node-symbol.same_comdat_group)
! fprintf (f, (same comdat group as %s/%i),
!cgraph_node_name (cgraph (node-symbol.same_comdat_group)),
!cgraph (node-symbol.same_comdat_group)-uid);
if (node-clone_of)
! fprintf (f, (clone of %s/%i),
!cgraph_node_name (node-clone_of),
!node-clone_of-uid);
if (cgraph_function_flags_ready)
! fprintf (f, availability:%s,
cgraph_availability_names [cgraph_function_body_availability
(node)]);
if (node-analyzed)
fprintf (f, analyzed);
- if (node-symbol.in_other_partition)
- fprintf (f, in_other_partition);
if (node-count)
fprintf (f, executed HOST_WIDEST_INT_PRINT_DECx,
(HOST_WIDEST_INT)node-count);
if (node-origin)
! fprintf (f, nested in: %s, cgraph_node_name (node-origin));
if (node-needed)
fprintf (f, needed);
- if (node-symbol.address_taken)
- fprintf (f, address_taken);
else if (node-reachable)
fprintf (f, reachable);
- else if (node-symbol.used_from_other_partition)
- fprintf (f, used_from_other_partition);
if (gimple_has_body_p (node-symbol.decl))
fprintf (f, body);
if (node-process)
fprintf (f, process);
if (node-local.local)
fprintf (f, local);
- if (node-symbol.externally_visible)
- fprintf (f, externally_visible);
- if (node-symbol.resolution != LDPR_UNKNOWN)
- fprintf (f, %s,
-ld_plugin_symbol_resolution_names[(int)node-symbol.resolution]);
Re: [i386, patch, RFC] HLE support in GCC
On Tue, Apr 17, 2012 at 6:41 PM, Andi Kleen a...@firstfloor.org wrote: I also have a question regarding AS compatibility. In case one built GCC using AS with support of HLE then using this GCC on a machine with old AS will cause fail because of usupported prefix. Can we support it I don't think that's a supported use case for gcc. It also doesn't work with .cfi* intrinsics and some other things. Well, it's hard to speculate here. What I rely upon is the fact that GCC I have on my Fedora is from gcc-4.6.0-10.fc15.x86_64.rpm and the latter contains no AS within. There should be dependencies so that AS will be updated alongside with GCC? Otherwise upon update to new GCC I can see fails in my project build. compile time rather configure time? The only way to do that would be to always generate .byte, but the people who read the assembler output would hate you for it. Totally agree, it's the best way to hurt your karma. :) Although detection of AS capabilities is available at compile time and can be used to evade compfail - at least in case assembler is involved (no -S provided) Sergos
PING: [PATCH] Fix PRs c/52283/37985
http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00191.html
and discussed in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52283
I would like to close the associated PRs to fix a few discrepancies with
the folding of constant expressions warnings.
Original patch from Manu was slightly modified to reflect the new
warn_if_unused_value location (moved from stmt.c to c-familly/c-common.c).
Is it OK for trunk, bootstrapped and regtested on x86
Many Thanks
Christian
gcc/testsuite/ChangeLog
2010-02-15 Christian Bruel christian.br...@st.com
* gcc.dg/case-const-1.c: Test constant expression.
* gcc.dg/case-const-2.c: Likewise.
* gcc.dg/case-const-3.c: Likewise.
gcc/ChangeLog
2012-03-29 Manuel López-Ibáñez m...@gcc.gnu.org
PR c/52283
* c-familly/c-common.c (warn_if_unused_value): Skip NOP_EXPR.
* convert.c (convert_to_integer): Don't set TREE_NO_WARNING.
Index: gcc/c-family/c-common.c
===
--- gcc/c-family/c-common.c (revision 186524)
+++ gcc/c-family/c-common.c (working copy)
@@ -1692,6 +1692,7 @@
case SAVE_EXPR:
case NON_LVALUE_EXPR:
+case NOP_EXPR:
exp = TREE_OPERAND (exp, 0);
goto restart;
Index: gcc/convert.c
===
--- gcc/convert.c (revision 186524)
+++ gcc/convert.c (working copy)
@@ -537,7 +537,6 @@
else if (outprec = inprec)
{
enum tree_code code;
- tree tem;
/* If the precision of the EXPR's type is K bits and the
destination mode has more bits, and the sign is changing,
@@ -555,13 +554,7 @@
else
code = NOP_EXPR;
- tem = fold_unary (code, type, expr);
- if (tem)
- return tem;
-
- tem = build1 (code, type, expr);
- TREE_NO_WARNING (tem) = 1;
- return tem;
+ return fold_build1 (code, type, expr);
}
/* If TYPE is an enumeral type or a type with a precision less
Index: gcc/testsuite/gcc.dg/pr37985.c
===
--- gcc/testsuite/gcc.dg/pr37985.c (revision 0)
+++ gcc/testsuite/gcc.dg/pr37985.c (revision 0)
@@ -0,0 +1,8 @@
+/* PR c37985 */
+/* { dg-do compile } */
+/* { dg-options -Wall -Wextra } */
+unsigned char foo(unsigned char a)
+{
+ a 2; /* { dg-warning no effect } */
+ return a;
+}
Index: gcc/testsuite/gcc.dg/case-const-1.c
===
--- gcc/testsuite/gcc.dg/case-const-1.c (revision 186524)
+++ gcc/testsuite/gcc.dg/case-const-1.c (working copy)
@@ -1,9 +1,11 @@
/* Test for case labels not integer constant expressions but folding
- to integer constants (used in Linux kernel, PR 39613). */
+ to integer constants (used in Linux kernel, PR 39613, 52283). */
/* { dg-do compile } */
/* { dg-options } */
extern int i;
+extern unsigned int u;
+
void
f (int c)
{
@@ -13,3 +15,13 @@
;
}
}
+
+void
+b (int c)
+{
+ switch (c)
+{
+case (int) (2 | ((4 8) ? 8 : u)):
+ ;
+}
+}
Index: gcc/testsuite/gcc.dg/case-const-2.c
===
--- gcc/testsuite/gcc.dg/case-const-2.c (revision 186524)
+++ gcc/testsuite/gcc.dg/case-const-2.c (working copy)
@@ -1,9 +1,11 @@
/* Test for case labels not integer constant expressions but folding
- to integer constants (used in Linux kernel, PR 39613). */
+ to integer constants (used in Linux kernel, PR 39613, 52283). */
/* { dg-do compile } */
/* { dg-options -pedantic } */
extern int i;
+extern unsigned int u;
+
void
f (int c)
{
@@ -13,3 +15,14 @@
;
}
}
+
+void
+b (int c)
+{
+ switch (c)
+{
+case (int) (2 | ((4 8) ? 8 : u)): /* { dg-warning case label is not an integer constant expression } */
+ ;
+}
+}
+
Index: gcc/testsuite/gcc.dg/case-const-3.c
===
--- gcc/testsuite/gcc.dg/case-const-3.c (revision 186524)
+++ gcc/testsuite/gcc.dg/case-const-3.c (working copy)
@@ -1,9 +1,11 @@
/* Test for case labels not integer constant expressions but folding
- to integer constants (used in Linux kernel, PR 39613). */
+ to integer constants (used in Linux kernel, PR 39613, 52283, ). */
/* { dg-do compile } */
/* { dg-options -pedantic-errors } */
extern int i;
+extern unsigned int u;
+
void
f (int c)
{
@@ -13,3 +15,16 @@
;
}
}
+
+void
+b (int c)
+{
+ switch (c)
+{
+case (int) (2 | ((4 8) ? 8 : u)): /* { dg-error case label is not an integer constant expression } */
+ ;
+}
+}
+
+
+
[PATCH] Fix out-of-bound array accesses in testcases
So, a patch of mine runs into the following testsuite issues. Fixed
with the following patch, tested on x86_64-unknown-linux-gnu and
committed.
Richard.
2012-04-18 Richard Guenther rguent...@suse.de
* gcc.target/x86_64/abi/test_passing_unions.c: Avoid undefined
array access.
* gcc.target/x86_64/abi/test_passing_structs.c: Likewise.
* gcc.target/i386/avx256-unaligned-load-4.c: Fix array sizes.
Index: gcc/testsuite/gcc.target/x86_64/abi/test_passing_unions.c
===
*** gcc/testsuite/gcc.target/x86_64/abi/test_passing_unions.c (revision
186528)
--- gcc/testsuite/gcc.target/x86_64/abi/test_passing_unions.c (working copy)
*** main (void)
*** 206,212
for (i = 0; i 8; i++)
{
u4[i].x = (__m128){32+i, 0, i, 0};
! fregs.xmm0._m128[i] = u4[i].x;
}
num_fregs = 8;
clear_float_hardware_registers;
--- 206,212
for (i = 0; i 8; i++)
{
u4[i].x = (__m128){32+i, 0, i, 0};
! (fregs.xmm0)[i]._m128[0] = u4[i].x;
}
num_fregs = 8;
clear_float_hardware_registers;
Index: gcc/testsuite/gcc.target/x86_64/abi/test_passing_structs.c
===
*** gcc/testsuite/gcc.target/x86_64/abi/test_passing_structs.c (revision
186528)
--- gcc/testsuite/gcc.target/x86_64/abi/test_passing_structs.c (working copy)
*** main (void)
*** 216,222
for (i = 0; i 8; i++)
{
m128s[i].x = (__m128){32+i, 0, i, 0};
! fregs.xmm0._m128[i] = m128s[i].x;
}
num_fregs = 8;
clear_float_hardware_registers;
--- 216,222
for (i = 0; i 8; i++)
{
m128s[i].x = (__m128){32+i, 0, i, 0};
! (fregs.xmm0)[i]._m128[0] = m128s[i].x;
}
num_fregs = 8;
clear_float_hardware_registers;
Index: gcc/testsuite/gcc.target/i386/avx256-unaligned-load-4.c
===
*** gcc/testsuite/gcc.target/i386/avx256-unaligned-load-4.c (revision
186528)
--- gcc/testsuite/gcc.target/i386/avx256-unaligned-load-4.c (working copy)
***
*** 3,9
#define N 1024
! float a[N], b[N+3];
void
avx_test (void)
--- 3,9
#define N 1024
! float a[N+3], b[N];
void
avx_test (void)
Re: [PATCH, i386, Android] Add Android support for i386 target
http://gcc.gnu.org/ml/gcc-cvs/2012-04/msg00511.html
Re: [Fixinclude]: Fix typo and default to twoprocess on VMS
On Apr 17, 2012, at 4:21 PM, Bruce Korb wrote: Hi Tristan, On Tue, Apr 17, 2012 at 5:57 AM, Tristan Gingold ging...@adacore.com wrote: Hi, one-process methodology cannot be used on VMS[...] But, when twoprocess is selected, gcc emits a warning[...] Ok for trunk ? diff --git a/fixincludes/configure.ac b/fixincludes/configure.ac index e7de791..f1fb2ff 100644 --- a/fixincludes/configure.ac +++ b/fixincludes/configure.ac @@ -53,7 +53,8 @@ fi], i?86-*-msdosdjgpp* | \ i?86-*-mingw32* | \ x86_64-*-mingw32* | \ - *-*-beos* ) + *-*-beos* | \ +*-*-*vms*) TARGET=twoprocess ;; This, definitely. diff --git a/fixincludes/fixincl.c b/fixincludes/fixincl.c index 9f399ab..1133534 100644 --- a/fixincludes/fixincl.c +++ b/fixincludes/fixincl.c @@ -829,7 +829,7 @@ fix_with_system (tFixDesc* p_fixd, /* * Now add the fix number and file names that may be needed */ - sprintf (pz_scan, %ld '%s' '%s', (long) (p_fixd - fixDescList), + sprintf (pz_scan, %ld '%s' '%s' '%s', (long) (p_fixd - fixDescList), pz_fix_file, pz_file_source, pz_temp_file); } else /* NOT an internal fix: */ This, almost certainly. I'll take a peek at the source and convince myself of this decade old mistake tomorrow send my grateful thanks and approval then. (No access to source today.) Fine, I stay tuned. Tristan.
Re: [PATCH] Allow un-distribution with repeated factors (PR52976 follow-up)
On Tue, 17 Apr 2012, William J. Schmidt wrote:
The emergency reassociation patch for PR52976 disabled un-distribution
in the presence of repeated factors to avoid ICEs in zero_one_operation.
This patch fixes such cases properly by teaching zero_one_operation
about __builtin_pow* calls.
Bootstrapped with no new regressions on powerpc64-linux. Also built
SPEC cpu2000 and cpu2006 successfully. Ok for trunk?
Ok.
Thanks,
Richard
Thanks,
Bill
gcc:
2012-04-17 Bill Schmidt wschm...@linux.vnet.ibm.com
* tree-ssa-reassoc.c (stmt_is_power_of_op): New function.
(decrement_power): Likewise.
(propagate_op_to_single_use): Likewise.
(zero_one_operation): Handle __builtin_pow* calls in linearized
expression trees; factor logic into propagate_op_to_single_use.
(undistribute_ops_list): Allow operands with repeat counts 1.
gcc/testsuite:
2012-04-17 Bill Schmidt wschm...@linux.vnet.ibm.com
gfortran.dg/reassoc_7.f: New test.
gfortran.dg/reassoc_8.f: Likewise.
gfortran.dg/reassoc_9.f: Likewise.
gfortran.dg/reassoc_10.f: Likewise.
Index: gcc/testsuite/gfortran.dg/reassoc_10.f
===
--- gcc/testsuite/gfortran.dg/reassoc_10.f(revision 0)
+++ gcc/testsuite/gfortran.dg/reassoc_10.f(revision 0)
@@ -0,0 +1,17 @@
+! { dg-do compile }
+! { dg-options -O3 -ffast-math -fdump-tree-optimized }
+
+ SUBROUTINE S55199(P,Q,Dvdph)
+ implicit none
+ real(8) :: c1,c2,c3,P,Q,Dvdph
+ c1=0.1d0
+ c2=0.2d0
+ c3=0.3d0
+ Dvdph = c1 + 2.*P*c2 + 3.*P**2*Q**3*c3
+ END
+
+! There should be five multiplies following un-distribution
+! and power expansion.
+
+! { dg-final { scan-tree-dump-times \\\* 5 optimized } }
+! { dg-final { cleanup-tree-dump optimized } }
Index: gcc/testsuite/gfortran.dg/reassoc_7.f
===
--- gcc/testsuite/gfortran.dg/reassoc_7.f (revision 0)
+++ gcc/testsuite/gfortran.dg/reassoc_7.f (revision 0)
@@ -0,0 +1,16 @@
+! { dg-do compile }
+! { dg-options -O3 -ffast-math -fdump-tree-optimized }
+
+ SUBROUTINE S55199(P,Dvdph)
+ implicit none
+ real(8) :: c1,c2,c3,P,Dvdph
+ c1=0.1d0
+ c2=0.2d0
+ c3=0.3d0
+ Dvdph = c1 + 2.*P*c2 + 3.*P**2*c3
+ END
+
+! There should be two multiplies following un-distribution.
+
+! { dg-final { scan-tree-dump-times \\\* 2 optimized } }
+! { dg-final { cleanup-tree-dump optimized } }
Index: gcc/testsuite/gfortran.dg/reassoc_8.f
===
--- gcc/testsuite/gfortran.dg/reassoc_8.f (revision 0)
+++ gcc/testsuite/gfortran.dg/reassoc_8.f (revision 0)
@@ -0,0 +1,17 @@
+! { dg-do compile }
+! { dg-options -O3 -ffast-math -fdump-tree-optimized }
+
+ SUBROUTINE S55199(P,Dvdph)
+ implicit none
+ real(8) :: c1,c2,c3,P,Dvdph
+ c1=0.1d0
+ c2=0.2d0
+ c3=0.3d0
+ Dvdph = c1 + 2.*P**2*c2 + 3.*P**3*c3
+ END
+
+! There should be three multiplies following un-distribution
+! and power expansion.
+
+! { dg-final { scan-tree-dump-times \\\* 3 optimized } }
+! { dg-final { cleanup-tree-dump optimized } }
Index: gcc/testsuite/gfortran.dg/reassoc_9.f
===
--- gcc/testsuite/gfortran.dg/reassoc_9.f (revision 0)
+++ gcc/testsuite/gfortran.dg/reassoc_9.f (revision 0)
@@ -0,0 +1,17 @@
+! { dg-do compile }
+! { dg-options -O3 -ffast-math -fdump-tree-optimized }
+
+ SUBROUTINE S55199(P,Dvdph)
+ implicit none
+ real(8) :: c1,c2,c3,P,Dvdph
+ c1=0.1d0
+ c2=0.2d0
+ c3=0.3d0
+ Dvdph = c1 + 2.*P**2*c2 + 3.*P**4*c3
+ END
+
+! There should be three multiplies following un-distribution
+! and power expansion.
+
+! { dg-final { scan-tree-dump-times \\\* 3 optimized } }
+! { dg-final { cleanup-tree-dump optimized } }
Index: gcc/tree-ssa-reassoc.c
===
--- gcc/tree-ssa-reassoc.c(revision 186495)
+++ gcc/tree-ssa-reassoc.c(working copy)
@@ -1020,6 +1020,98 @@ oecount_cmp (const void *p1, const void *p2)
return c1-id - c2-id;
}
+/* Return TRUE iff STMT represents a builtin call that raises OP
+ to some exponent. */
+
+static bool
+stmt_is_power_of_op (gimple stmt, tree op)
+{
+ tree fndecl;
+
+ if (!is_gimple_call (stmt))
+return false;
+
+ fndecl = gimple_call_fndecl (stmt);
+
+ if (!fndecl
+ || DECL_BUILT_IN_CLASS (fndecl) != BUILT_IN_NORMAL)
+return false;
+
+ switch (DECL_FUNCTION_CODE (gimple_call_fndecl (stmt)))
+{
+CASE_FLT_FN (BUILT_IN_POW):
+CASE_FLT_FN (BUILT_IN_POWI):
+ return (operand_equal_p (gimple_call_arg (stmt, 0), op, 0));
+
+default:
+ return
Re: [PATCH] Fix __builtin_powi placement (PR52976 follow-up)
On Tue, 17 Apr 2012, William J. Schmidt wrote:
The emergency patch for PR52976 manipulated the operand rank system to
force inserted __builtin_powi calls to occur before uses of the call
results. However, this is generally the wrong approach, as it forces
other computations to move unnecessarily, and extends the lifetimes of
other operands.
This patch fixes the problem in the proper way, by letting the rank
system determine where the __builtin_powi call belongs, and moving the
call to that location during the expression rewrite.
Bootstrapped with no new regressions on powerpc64-linux. SPEC cpu2000
and cpu2006 also build cleanly. Ok for trunk?
Ok.
Thanks,
Richard.
Thanks,
Bill
gcc:
2012-04-17 Bill Schmidt wschm...@linux.vnet.ibm.com
* tree-ssa-reassoc.c (add_to_ops_vec_max_rank): Delete.
(possibly_move_powi): New function.
(rewrite_expr_tree): Call possibly_move_powi.
(rewrite_expr_tree_parallel): Likewise.
(attempt_builtin_powi): Change call of add_to_ops_vec_max_rank to
call add_to_ops_vec instead.
gcc/testsuite:
2012-04-17 Bill Schmidt wschm...@linux.vnet.ibm.com
gfortran.dg/reassoc_11.f: New test.
Index: gcc/testsuite/gfortran.dg/reassoc_11.f
===
--- gcc/testsuite/gfortran.dg/reassoc_11.f(revision 0)
+++ gcc/testsuite/gfortran.dg/reassoc_11.f(revision 0)
@@ -0,0 +1,17 @@
+! { dg-do compile }
+! { dg-options -O3 -ffast-math }
+
+! This tests only for compile-time failure, which formerly occurred
+! when a __builtin_powi was introduced by reassociation in a bad place.
+
+ SUBROUTINE GRDURBAN(URBWSTR, ZIURB, GRIDHT)
+
+ IMPLICIT NONE
+ INTEGER :: I
+ REAL :: SW2, URBWSTR, ZIURB, GRIDHT(87)
+
+ SAVE
+
+ SW2 = 1.6*(GRIDHT(I)/ZIURB)**0.667*URBWSTR**2
+
+ END
Index: gcc/tree-ssa-reassoc.c
===
--- gcc/tree-ssa-reassoc.c(revision 186495)
+++ gcc/tree-ssa-reassoc.c(working copy)
@@ -544,28 +544,6 @@ add_repeat_to_ops_vec (VEC(operand_entry_t, heap)
reassociate_stats.pows_encountered++;
}
-/* Add an operand entry to *OPS for the tree operand OP, giving the
- new entry a larger rank than any other operand already in *OPS. */
-
-static void
-add_to_ops_vec_max_rank (VEC(operand_entry_t, heap) **ops, tree op)
-{
- operand_entry_t oe = (operand_entry_t) pool_alloc (operand_entry_pool);
- operand_entry_t oe1;
- unsigned i;
- unsigned max_rank = 0;
-
- FOR_EACH_VEC_ELT (operand_entry_t, *ops, i, oe1)
-if (oe1-rank max_rank)
- max_rank = oe1-rank;
-
- oe-op = op;
- oe-rank = max_rank + 1;
- oe-id = next_operand_entry_id++;
- oe-count = 1;
- VEC_safe_push (operand_entry_t, heap, *ops, oe);
-}
-
/* Return true if STMT is reassociable operation containing a binary
operation with tree code CODE, and is inside LOOP. */
@@ -2162,6 +2242,47 @@ remove_visited_stmt_chain (tree var)
}
}
+/* If OP is an SSA name, find its definition and determine whether it
+ is a call to __builtin_powi. If so, move the definition prior to
+ STMT. Only do this during early reassociation. */
+
+static void
+possibly_move_powi (gimple stmt, tree op)
+{
+ gimple stmt2;
+ tree fndecl;
+ gimple_stmt_iterator gsi1, gsi2;
+
+ if (!first_pass_instance
+ || !flag_unsafe_math_optimizations
+ || TREE_CODE (op) != SSA_NAME)
+return;
+
+ stmt2 = SSA_NAME_DEF_STMT (op);
+
+ if (!is_gimple_call (stmt2)
+ || !has_single_use (gimple_call_lhs (stmt2)))
+return;
+
+ fndecl = gimple_call_fndecl (stmt2);
+
+ if (!fndecl
+ || DECL_BUILT_IN_CLASS (fndecl) != BUILT_IN_NORMAL)
+return;
+
+ switch (DECL_FUNCTION_CODE (fndecl))
+{
+CASE_FLT_FN (BUILT_IN_POWI):
+ break;
+default:
+ return;
+}
+
+ gsi1 = gsi_for_stmt (stmt);
+ gsi2 = gsi_for_stmt (stmt2);
+ gsi_move_before (gsi2, gsi1);
+}
+
/* This function checks three consequtive operands in
passed operands vector OPS starting from OPINDEX and
swaps two operands if it is profitable for binary operation
@@ -2267,6 +2388,8 @@ rewrite_expr_tree (gimple stmt, unsigned int opind
print_gimple_stmt (dump_file, stmt, 0, 0);
}
+ possibly_move_powi (stmt, oe1-op);
+ possibly_move_powi (stmt, oe2-op);
}
return;
}
@@ -2312,6 +2435,8 @@ rewrite_expr_tree (gimple stmt, unsigned int opind
fprintf (dump_file, into );
print_gimple_stmt (dump_file, stmt, 0, 0);
}
+
+ possibly_move_powi (stmt, oe-op);
}
/* Recurse on the LHS of the binary operator, which is guaranteed to
be the non-leaf side. */
@@ -2485,6 +2610,9 @@ rewrite_expr_tree_parallel (gimple stmt, int width
fprintf (dump_file, into );
Re: [PATCH][ARM][Testsute] Skip thumb1 test in non-thumb1 target
On 18 April 2012 04:02, Joey Ye joey...@arm.com wrote:
Fix the test case failed in ARM state.
* gcc.target/arm/thumb1-imm.c: Skip it in non-thumb1 target
Index: gcc/testsuite/gcc.target/arm/thumb1-imm.c
===
--- gcc/testsuite/gcc.target/arm/thumb1-imm.c (revision 186517)
+++ gcc/testsuite/gcc.target/arm/thumb1-imm.c (working copy)
@@ -1,5 +1,7 @@
/* Check for thumb1 imm [255-510] moves. */
/* { dg-require-effective-target arm_thumb1_ok } */
+/* { dg-options -Os } */
+/* { dg-skip-if { ! { arm_thumb1 } } } */
int f()
{
OK
ramana
Re: [patch] Cleanup tree-switch-conversion a bit
On Tue, Apr 17, 2012 at 6:15 PM, Steven Bosscher stevenb@gmail.com wrote: My goal for GCC 4.8 is to do just that: Move switch expansion to GIMPLE and add value profiling for switch expressions. And the idea is to put all that code in tree-switch-conversion.c. But there are a few clean-ups I wish to do on that code before that. First, there is a global pass info structure that contains useful data for all forms of GIMPLE_SWITCH lowering. I've un-globalized that data with the attached patch. While there, I made the dump messages uniform. Bootstrapped and tested on powerpc-unknown-linux-gnu. OK? Ok. Thanks, Richard. Ciao! Steven
Re: [Fortran] Patch ping
On Mon, Apr 16, 2012 at 11:03, Tobias Burnus
tobias.bur...@physik.fu-berlin.de wrote:
Other patches with pending review:
- [Patch, libfortran] Combine get_mem and internal_malloc_size
http://gcc.gnu.org/ml/fortran/2012-03/msg00127.html
As I said in the original submission, While the patch is large, it's
also mechanical, hence committed as obvious.
Approved but not yet committed:
Janne:
- [Patch, fortran] PR 49010/24518 MOD/MODULO fixes
http://gcc.gnu.org/ml/fortran/2012-04/msg00012.html
Okayed but haven't found best wording.
I have an IMHO better wording, namely for MOD(A,P) the returned value
has the same sign as A and a magnitude less than the magnitude of P.
and for MODULO(A,P) the returned value has the same sign as P and a
magnitude less than the magnitude of P.. This wording implies what
the sign of the result must be when A is (+-) 0.0 like it does for any
other finite A, which I think is nice.
However, in order to implement this wording, MODULO needs to be
implemented a bit differently than now, namely now we have
res = fmod(a, p);
if (res ((a 0) != (p 0))
res += p;
but in order to ensure the behavior above for signed zero we need to do
res = fmod(a, p);
if (res)
{
if ((a 0) != (p 0))
res += p;
}
else
res = copysign (0.0, p);
I have implemented the compile-time part of this, but I haven't yet
had the time to do the runtime code generation (which should be
conditional on -fsigned-zeros). I'll resubmit when done.
--
Janne Blomqvist
Re: PING: [PATCH] Fix PRs c/52283/37985
On 18 April 2012 10:29, Christian Bruel christian.br...@st.com wrote: Is it OK for trunk, bootstrapped and regtested on x86 I think Joseph Myers is on vacation, and there are no other C FE reviewers, but since this is c-common and convert.c, perhaps Jason and/or Richard can review it? Thanks, Manuel.
Re: [patch] Cleanup tree-switch-conversion a bit
On Wed, 18 Apr 2012, Steven Bosscher wrote: Hello, This is another step towards moving GIMPLE_SWITCH expansion to an earlier point in the pipeline. With the attached patch, some of the logic from stmt.c:add_case_node() is moved to gimplify.c:gimplify_switch_expr(). This includes: * Code to drop case labels that are out of range for the switch index expression. (Actually, I suspect this code hasn't worked properly since gimplification was introduced, because the switch index expression can be promoted by language specific gimplification, so expand_case never actually sees the proper type with the current implementation in stmt.c.) * Code to fold_convert case label values to the right type. I've opted to go for folding to the original type of the SWITCH_EXPR, rather than to the post-gimplification switch index type. * Code to canonicalize CASE_LABEL's subnodes, CASE_LOW and CASE_HIGH. I've chosen to impose strict requirements that CASE_HIGH CASE_LOW if CASE_HIGH is non-zero. This is different from what add_case_node does, but I think it makes sense to go for the minimal representation here: The case labels in stmt.c never lived very long (only during expand) but GIMPLE_SWITCH statements stay around for much of the compilation process and can also be streamed out, etc. Bootstrapped and tested on powerpc-unknown-linux-gnu. OK for trunk? I wonder about @@ -1575,6 +1575,9 @@ gimplify_switch_expr (tree *expr_p, gimple_seq *pr tree switch_expr = *expr_p; gimple_seq switch_body_seq = NULL; enum gimplify_status ret; + tree index_type = TREE_TYPE (switch_expr); + if (index_type == void_type_node) +index_type = TREE_TYPE (SWITCH_COND (switch_expr)); what frontends use void_type_node here contrary to the docs in tree.def: TREE_TYPE is the original type of the condition, before any language required type conversions. It may be NULL, in which case the original type and final types are assumed to be the same. which says you'd need to handle NULL instead? Thus, can you either adjust the docs in tree.def or the frontends? Ok with either change. Thanks, Richard.
Re: [PATCH, PR38785] Throttle PRE at -O3
On Wed, Apr 18, 2012 at 4:15 AM, Maxim Kuvyrkov ma...@codesourcery.com wrote: Steven, Jorn, I am looking into fixing performance regression on EEMBC's bitmnp01, and a version of your combined patch attached to PR38785 still works very well. Would you mind me getting it through upstream review, or are there any issues with contributing this patch to GCC mainline? We (CodeSourcery/Mentor) were carrying this patch in our toolchains since GCC 4.4, and it didn't show any performance or correctness problems on x86, ARM, MIPS, and other architectures. It also reliably fixes bitmnp01 regression, which is still present in current mainline. I have tested this patch on recent mainline on i686-linux-gnu with no regressions. Unless I hear from you to the contrary, I will push this patch for upstream review and, hopefully, get it checked in. Previous discussion of this patch is at http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00250.html The addition of -ftree-pre-partial-partial is ok if you change its name to -ftree-partial-pre and add documentation to invoke.texi. + /* Assuming the expression is 50% anticipatable, we have +to multiply the number of insertions needed by two for a cost +comparison. */ why assume 50% anticipatibility if you can compute the exact anticipatibility? + if (!optimize_function_for_speed_p (cfun) please look at how I changed regular PRE to look at whether we want to optimize the path which has the redundancy for speed via optimize_edge_for_speed_p. The same surgerly should be applied to PPRE. Thanks, Richard. Thank you, -- Maxim Kuvyrkov CodeSourcery / Mentor Graphics
Re: [PATCH, PR38785] Throttle PRE at -O3
On Wed, Apr 18, 2012 at 4:15 AM, Maxim Kuvyrkov ma...@codesourcery.com wrote: I am looking into fixing performance regression on EEMBC's bitmnp01, and a version of your combined patch attached to PR38785 still works very well. Would you mind me getting it through upstream review, or are there any issues with contributing this patch to GCC mainline? Not at all, please go ahead! :-)
[PATCH, i386, middle-end, tessuite] Intel TSX's HLE.
Hello guys, Since there is no more objections to my RFC, started here [1], I've implemented rest __atomic builtins in the same way. It corresponds to Spec, which can be found here [2]. Patch attached. ChangeLog entry: 2012-04-18 Kirill Yukhin kirill.yuk...@intel.com * builtins.c (get_memmodel): Remove check of upper bound. (expand_builtin_atomic_compare_exchange): Mask memmodel values. * config/i386/cpuid.h (bit_HLE): New. * config/i386/driver-i386.c (host_detect_local_cpu): Detect HLE support. * config/i386/i386-protos.h (ix86_generate_hle_prefix): New. * config/i386/i386-c.c (ix86_target_macros_internal): Set HLE defines. (ix86_target_string)-mhle: New. (ix86_option_override_internal)PTA_HLE: Ditto. (ix86_valid_target_attribute_inner_p)OPT_mhle: Ditto. * config/i386/i386.c (ix86_target_string)OPTION_MASK_ISA_HLE: New. (ix86_valid_target_attribute_inner_p)OPT_mhle: Ditto. (ix86_generate_hle_prefix): Ditto. * config/i386/i386.h (OPTION_ISA_HLE): Ditto. (IX86_HLE_ACQUIRE): Ditto. (IX86_HLE_RELEASE): Ditto. * config/i386/i386.h (ix86_generate_hle_prefix): Ditto. * config/i386/i386.opt (mhle): Ditto. * config/i386/sync.md(atomic_compare_and_swapmode): Pass success model to instruction emitter. (atomic_fetch_addmode): Ditto. (atomic_exchangemode): Ditto. (atomic_addmode): Ditto. (atomic_submode): Ditto. (atomic_codemode): Ditto. (atomic_compare_and_swap_singlemode): Define and use argument for success model. (atomic_compare_and_swap_doublemode): Ditto. * configure.ac: Check if assembler support HLE prefixies. * configure: Regenerate. * config.in: Ditto. testsuite/ChangeLog entry: 2012-04-18 Kirill Yukhin kirill.yuk...@intel.com * gcc.target/i386/hle-cmpxchg-acq-1.c: New. * gcc.target/i386/hle-cmpxchg-rel-1.c: Ditto. * gcc.target/i386/hle-add-acq-1.c: Ditto. * gcc.target/i386/hle-add-rel-1.c: Ditto. * gcc.target/i386/hle-and-acq-1.c: Ditto. * gcc.target/i386/hle-and-rel-1.c: Ditto. * gcc.target/i386/hle-or-acq-1.c: Ditto. * gcc.target/i386/hle-or-rel-1.c: Ditto. * gcc.target/i386/hle-sub-acq-1.c: Ditto. * gcc.target/i386/hle-sub-rel-1.c: Ditto. * gcc.target/i386/hle-xadd-acq-1.c: Ditto. * gcc.target/i386/hle-xadd-rel-1.c: Ditto. * gcc.target/i386/hle-xchg-acq-1.c: Ditto. * gcc.target/i386/hle-xchg-rel-1.c: Ditto. * gcc.target/i386/hle-xor-acq-1.c: Ditto. * gcc.target/i386/hle-xor-rel-1.c: Ditto. Bootstrap in prgress Is it OK if bootstrap pass? [1] - http://gcc.gnu.org/ml/gcc-patches/2012-03/msg00486.html [2] - http://software.intel.com/en-us/blogs/2012/02/07/transactional-synchronization-in-haswell/ Thanks, K
Re: [PATCH, i386, middle-end, tessuite] Intel TSX's HLE.
Forgot to attach the patch :) On Wed, Apr 18, 2012 at 1:34 PM, Kirill Yukhin kirill.yuk...@gmail.com wrote: Hello guys, Since there is no more objections to my RFC, started here [1], I've implemented rest __atomic builtins in the same way. It corresponds to Spec, which can be found here [2]. Patch attached. ChangeLog entry: 2012-04-18 Kirill Yukhin kirill.yuk...@intel.com * builtins.c (get_memmodel): Remove check of upper bound. (expand_builtin_atomic_compare_exchange): Mask memmodel values. * config/i386/cpuid.h (bit_HLE): New. * config/i386/driver-i386.c (host_detect_local_cpu): Detect HLE support. * config/i386/i386-protos.h (ix86_generate_hle_prefix): New. * config/i386/i386-c.c (ix86_target_macros_internal): Set HLE defines. (ix86_target_string)-mhle: New. (ix86_option_override_internal)PTA_HLE: Ditto. (ix86_valid_target_attribute_inner_p)OPT_mhle: Ditto. * config/i386/i386.c (ix86_target_string)OPTION_MASK_ISA_HLE: New. (ix86_valid_target_attribute_inner_p)OPT_mhle: Ditto. (ix86_generate_hle_prefix): Ditto. * config/i386/i386.h (OPTION_ISA_HLE): Ditto. (IX86_HLE_ACQUIRE): Ditto. (IX86_HLE_RELEASE): Ditto. * config/i386/i386.h (ix86_generate_hle_prefix): Ditto. * config/i386/i386.opt (mhle): Ditto. * config/i386/sync.md(atomic_compare_and_swapmode): Pass success model to instruction emitter. (atomic_fetch_addmode): Ditto. (atomic_exchangemode): Ditto. (atomic_addmode): Ditto. (atomic_submode): Ditto. (atomic_codemode): Ditto. (atomic_compare_and_swap_singlemode): Define and use argument for success model. (atomic_compare_and_swap_doublemode): Ditto. * configure.ac: Check if assembler support HLE prefixies. * configure: Regenerate. * config.in: Ditto. testsuite/ChangeLog entry: 2012-04-18 Kirill Yukhin kirill.yuk...@intel.com * gcc.target/i386/hle-cmpxchg-acq-1.c: New. * gcc.target/i386/hle-cmpxchg-rel-1.c: Ditto. * gcc.target/i386/hle-add-acq-1.c: Ditto. * gcc.target/i386/hle-add-rel-1.c: Ditto. * gcc.target/i386/hle-and-acq-1.c: Ditto. * gcc.target/i386/hle-and-rel-1.c: Ditto. * gcc.target/i386/hle-or-acq-1.c: Ditto. * gcc.target/i386/hle-or-rel-1.c: Ditto. * gcc.target/i386/hle-sub-acq-1.c: Ditto. * gcc.target/i386/hle-sub-rel-1.c: Ditto. * gcc.target/i386/hle-xadd-acq-1.c: Ditto. * gcc.target/i386/hle-xadd-rel-1.c: Ditto. * gcc.target/i386/hle-xchg-acq-1.c: Ditto. * gcc.target/i386/hle-xchg-rel-1.c: Ditto. * gcc.target/i386/hle-xor-acq-1.c: Ditto. * gcc.target/i386/hle-xor-rel-1.c: Ditto. Bootstrap in prgress Is it OK if bootstrap pass? [1] - http://gcc.gnu.org/ml/gcc-patches/2012-03/msg00486.html [2] - http://software.intel.com/en-us/blogs/2012/02/07/transactional-synchronization-in-haswell/ Thanks, K hle-1.gcc.patch Description: Binary data
Re: [PATCH, i386, middle-end, tessuite] Intel TSX's HLE.
Kirill Yukhin kirill.yuk...@gmail.com writes: Forgot to attach the patch :) Just a nit: you're using `prefixies' throughout the patch. I guess this should be `prefixes' instead. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH, i386, middle-end, tessuite] Intel TSX's HLE.
Whoops, thank you. I'll fix it K On Wed, Apr 18, 2012 at 1:44 PM, Rainer Orth r...@cebitec.uni-bielefeld.de wrote: Kirill Yukhin kirill.yuk...@gmail.com writes: Forgot to attach the patch :) Just a nit: you're using `prefixies' throughout the patch. I guess this should be `prefixes' instead. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: PING: [PATCH] Fix PRs c/52283/37985
On Wed, Apr 18, 2012 at 11:06 AM, Manuel López-Ibáñez lopeziba...@gmail.com wrote: On 18 April 2012 10:29, Christian Bruel christian.br...@st.com wrote: Is it OK for trunk, bootstrapped and regtested on x86 I think Joseph Myers is on vacation, and there are no other C FE reviewers, but since this is c-common and convert.c, perhaps Jason and/or Richard can review it? The patch is ok if you put the PR52283 properly into a separate testcase, not by amending gcc.dg/case-const-2.c. Thanks, Richard. Thanks, Manuel.
Re: [PATCH, i386, middle-end, tessuite] Intel TSX's HLE.
On Wed, Apr 18, 2012 at 11:34 AM, Kirill Yukhin kirill.yuk...@gmail.com wrote:
Hello guys,
Since there is no more objections to my RFC, started here [1],
I've implemented rest __atomic builtins in the same way.
It corresponds to Spec, which can be found here [2].
Can you please implement printing of HLE prefix with %K operand
modifier, like sync.md example in attached (untested) patch?
Uros.
Index: i386/i386.md
===
--- i386/i386.md(revision 186558)
+++ i386/i386.md(working copy)
@@ -58,6 +58,7 @@
;; X -- don't print any sort of PIC '@' suffix for a symbol.
;; -- print some in-use local-dynamic symbol name.
;; H -- print a memory address offset by 8; used for sse high-parts
+;; K -- print HLE lock prefix
;; Y -- print condition for XOP pcom* instruction.
;; + -- print a branch hint as 'cs' or 'ds' prefix
;; ; -- print a semicolon (after prefixes due to bug in older gas).
Index: i386/sync.md
===
--- i386/sync.md(revision 186558)
+++ i386/sync.md(working copy)
@@ -455,7 +455,7 @@
(match_operand:SWI 2 nonmemory_operand 0)))
(clobber (reg:CC FLAGS_REG))]
TARGET_XADD
- lock{%;} xadd{imodesuffix}\t{%0, %1|%1, %0})
+ lock{%;} %K3xadd{imodesuffix}\t{%0, %1|%1, %0})
;; This peephole2 and following insn optimize
;; __sync_fetch_and_add (x, -N) == N into just lock {add,sub,inc,dec}
Index: i386/i386.c
===
@@ -13938,6 +13944,7 @@ get_some_local_dynamic_name (void)
X -- don't print any sort of PIC '@' suffix for a symbol.
-- print some in-use local-dynamic symbol name.
H -- print a memory address offset by 8; used for sse high-parts
+ K -- print HLE lock prefix
Y -- print condition for XOP pcom* instruction.
+ -- print a branch hint as 'cs' or 'ds' prefix
; -- print a semicolon (after prefixes due to bug in older gas).
@@ -14340,6 +14347,22 @@ ix86_print_operand (FILE *file, rtx x, int code)
x = adjust_address_nv (x, DImode, 8);
break;
+ case 'K':
+ gcc_assert (CONST_INT_P (x));
+
+ if (INTVAL (x) IX86_HLE_ACQUIRE)
+#ifdef HAVE_AS_IX86_HLE
+ fputs (xacquire , file);
+#else
+ fputs (\n ASM_BYTE 0xf2\n\t, file);
+ else if (INTVAL (x) IX86_HLE_RELEASE)
+#ifdef HAVE_AS_IX86_HLE
+ fputs (xrelease , file);
+#else
+ fputs (\n ASM_BYTE 0xf3\n\t);
+#endif
+ break;
+
case '+':
{
rtx x;
Re: [C++ Patch] PR 52422 (new patch)
Hi again,
Hi Jason,
I have a new patch for this issue, another SFINAE issue noticed by
Daniel. Compared to the last version, I extended the complain-ization
;) to a few more functions in typeck.c (I think the set is more
consistent now) and thoroughly double checked that the return values
of all the functions which now get a tsubst_flags_t argument are
checked for error_mark_node and in case early return back
error_mark_node itself, as you requested last time.
As usual, tested x86_64-linux.
The below is what I'm going to actually commit, as approved by Jason
off-list with a change to the convert_member_func_to_ptr bits.
Tested x86_64-linux.
Thanks,
Paolo.
/
/cp
2012-04-18 Paolo Carlini paolo.carl...@oracle.com
PR c++/52422
* cp-tree.h (build_addr_func, decay_conversion,
get_member_function_from_ptrfunc,
build_m_component_ref, convert_member_func_to_ptr):
Add tsubst_flags_t parameter.
* typeck.c (cp_default_conversion): Add.
(decay_conversion, default_conversion,
get_member_function_from_ptrfunc, convert_member_func_to_ptr):
Add tsubst_flags_t parameter and use it throughout.
(cp_build_indirect_ref, cp_build_array_ref,
cp_build_function_call_vec, convert_arguments, build_x_binary_op,
cp_build_binary_op, cp_build_unary_op, build_reinterpret_cast_1,
build_const_cast_1, expand_ptrmemfunc_cst,
convert_for_initialization): Adjust.
* init.c (build_vec_init): Adjust.
* decl.c (grok_reference_init, get_atexit_node): Likewise.
* rtti.c (build_dynamic_cast_1, tinfo_base_init): Likewise.
* except.c (build_throw): Likewise.
* typeck2.c (build_x_arrow): Likewise.
(build_m_component_ref): Add tsubst_flags_t parameter and
use it throughout.
* pt.c (convert_nontype_argument): Adjust.
* semantics.c (finish_asm_stmt, maybe_add_lambda_conv_op): Likewise.
* decl2.c (build_offset_ref_call_from_tree): Likewise.
* call.c (build_addr_func): Add tsubst_flags_t parameter and
use it throughout.
(build_call_a, build_conditional_expr_1, build_new_op_1,
convert_like_real, convert_arg_to_ellipsis, build_over_call,
build_special_member_call): Adjust.
* cvt.c (cp_convert_to_pointer, force_rvalue,
build_expr_type_conversion): Likewise.
/testsuite
2012-04-18 Paolo Carlini paolo.carl...@oracle.com
PR c++/52422
* g++.dg/cpp0x/sfinae33.C: New.
* g++.dg/cpp0x/sfinae34.C: Likewise.
Index: testsuite/g++.dg/cpp0x/sfinae33.C
===
--- testsuite/g++.dg/cpp0x/sfinae33.C (revision 0)
+++ testsuite/g++.dg/cpp0x/sfinae33.C (revision 0)
@@ -0,0 +1,27 @@
+// PR c++/52422
+// { dg-options -std=c++11 }
+
+templateclass T
+struct add_rval_ref
+{
+ typedef T type;
+};
+
+template
+struct add_rval_refvoid
+{
+ typedef void type;
+};
+
+templateclass T
+typename add_rval_refT::type create();
+
+templateclass T,
+ class = decltype(createT()())
+
+auto f(int) - char()[1];
+
+templateclass
+auto f(...) - char()[2];
+
+static_assert(sizeof(fvoid(0)) != 1, );
Index: testsuite/g++.dg/cpp0x/sfinae34.C
===
--- testsuite/g++.dg/cpp0x/sfinae34.C (revision 0)
+++ testsuite/g++.dg/cpp0x/sfinae34.C (revision 0)
@@ -0,0 +1,27 @@
+// PR c++/52422
+// { dg-options -std=c++11 }
+
+templateclass T
+struct add_rval_ref
+{
+ typedef T type;
+};
+
+template
+struct add_rval_refvoid
+{
+ typedef void type;
+};
+
+templateclass T
+typename add_rval_refT::type create();
+
+templateclass T, class U,
+ class = decltype( (createT().*createU())() )
+
+auto f(int) - char()[1];
+
+templateclass, class
+auto f(...) - char()[2];
+
+static_assert(sizeof(fvoid, void(0)) != 1, );
Index: cp/typeck.c
===
--- cp/typeck.c (revision 186563)
+++ cp/typeck.c (working copy)
@@ -1818,7 +1818,7 @@ unlowered_expr_type (const_tree exp)
that the return value is no longer an lvalue. */
tree
-decay_conversion (tree exp)
+decay_conversion (tree exp, tsubst_flags_t complain)
{
tree type;
enum tree_code code;
@@ -1832,7 +1832,8 @@ tree
exp = resolve_nondeduced_context (exp);
if (type_unknown_p (exp))
{
- cxx_incomplete_type_error (exp, TREE_TYPE (exp));
+ if (complain tf_error)
+ cxx_incomplete_type_error (exp, TREE_TYPE (exp));
return error_mark_node;
}
@@ -1851,13 +1852,14 @@ tree
code = TREE_CODE (type);
if (code == VOID_TYPE)
{
- error (void value not ignored as it ought to be);
+ if (complain tf_error)
+ error (void value not ignored as it ought to be);
return error_mark_node;
}
- if (invalid_nonstatic_memfn_p (exp, tf_warning_or_error))
+ if (invalid_nonstatic_memfn_p (exp, complain))
return
Re: [patch] Cleanup tree-switch-conversion a bit
On Wed, Apr 18, 2012 at 11:10 AM, Richard Guenther rguent...@suse.de wrote: I wonder about @@ -1575,6 +1575,9 @@ gimplify_switch_expr (tree *expr_p, gimple_seq *pr tree switch_expr = *expr_p; gimple_seq switch_body_seq = NULL; enum gimplify_status ret; + tree index_type = TREE_TYPE (switch_expr); + if (index_type == void_type_node) + index_type = TREE_TYPE (SWITCH_COND (switch_expr)); what frontends use void_type_node here contrary to the docs in tree.def: TREE_TYPE is the original type of the condition, before any language required type conversions. It may be NULL, in which case the original type and final types are assumed to be the same. which says you'd need to handle NULL instead? Thus, can you either adjust the docs in tree.def or the frontends? That code was copied from stmt.c, and I was surprised by it, too. The Fortran frond end builds SWITCH_EXPRs with build3_v, i.e. void_type_node-typed. The Go front ends also build SWITCH_EXPRs with void_type_node. The C-family and Java front ends build SWITCH_EXPRs with a non-void type. But from gimplify.c:is_gimple_stmt(): case SWITCH_EXPR: (...) /* These are always void. */ return true; See these files for all the locations I could find where a SWITCH_EXPR is built: java/expr.c: switch_expr = build3 (SWITCH_EXPR, TREE_TYPE (selector), selector, go/go-gcc.cc: tree t = build3_loc(switch_location.gcc_location(), SWITCH_EXPR, cp/cp-gimplify.c: t = build3 (SWITCH_EXPR, SWITCH_STMT_TYPE (stmt), c-typeck.c: cs-switch_expr = build3 (SWITCH_EXPR, orig_type, exp, NULL_TREE, NULL_TREE); fortran/trans-stmt.c: tmp = build3_v (SWITCH_EXPR, se.expr, tmp, NULL_TREE); fortran/trans-stmt.c: tmp = build3_v (SWITCH_EXPR, case_num, tmp, NULL_TREE); fortran/trans-stmt.c: tmp = build3_v (SWITCH_EXPR, case_num, tmp, NULL_TREE); fortran/trans-io.c: tmp = build3_v (SWITCH_EXPR, rc, tmp, NULL_TREE); fortran/trans-decl.c: tmp = build3_v (SWITCH_EXPR, val, tmp, NULL_TREE); ada/gcc-interface/trans.c: gnu_result = build3 (SWITCH_EXPR, TREE_TYPE (gnu_expr), gnu_expr, Perhaps the Fortran and Go front ends should build SWITCH_EXPRs with a NULL type, and gimplify_switch_expr() should assert that the SWITCH_EXPR type is never void_type node. That would make things match the documentation in tree.def again. I'll test a patch with these changes and commit it if it works. Ciao! Steven
Re: [patch] Cleanup tree-switch-conversion a bit
On Wed, 18 Apr 2012, Steven Bosscher wrote: On Wed, Apr 18, 2012 at 11:10 AM, Richard Guenther rguent...@suse.de wrote: I wonder about @@ -1575,6 +1575,9 @@ gimplify_switch_expr (tree *expr_p, gimple_seq *pr tree switch_expr = *expr_p; gimple_seq switch_body_seq = NULL; enum gimplify_status ret; + tree index_type = TREE_TYPE (switch_expr); + if (index_type == void_type_node) + index_type = TREE_TYPE (SWITCH_COND (switch_expr)); what frontends use void_type_node here contrary to the docs in tree.def: TREE_TYPE is the original type of the condition, before any language required type conversions. It may be NULL, in which case the original type and final types are assumed to be the same. which says you'd need to handle NULL instead? Thus, can you either adjust the docs in tree.def or the frontends? That code was copied from stmt.c, and I was surprised by it, too. The Fortran frond end builds SWITCH_EXPRs with build3_v, i.e. void_type_node-typed. The Go front ends also build SWITCH_EXPRs with void_type_node. The C-family and Java front ends build SWITCH_EXPRs with a non-void type. But from gimplify.c:is_gimple_stmt(): case SWITCH_EXPR: (...) /* These are always void. */ return true; See these files for all the locations I could find where a SWITCH_EXPR is built: java/expr.c: switch_expr = build3 (SWITCH_EXPR, TREE_TYPE (selector), selector, go/go-gcc.cc: tree t = build3_loc(switch_location.gcc_location(), SWITCH_EXPR, cp/cp-gimplify.c: t = build3 (SWITCH_EXPR, SWITCH_STMT_TYPE (stmt), c-typeck.c: cs-switch_expr = build3 (SWITCH_EXPR, orig_type, exp, NULL_TREE, NULL_TREE); fortran/trans-stmt.c: tmp = build3_v (SWITCH_EXPR, se.expr, tmp, NULL_TREE); fortran/trans-stmt.c: tmp = build3_v (SWITCH_EXPR, case_num, tmp, NULL_TREE); fortran/trans-stmt.c: tmp = build3_v (SWITCH_EXPR, case_num, tmp, NULL_TREE); fortran/trans-io.c: tmp = build3_v (SWITCH_EXPR, rc, tmp, NULL_TREE); fortran/trans-decl.c: tmp = build3_v (SWITCH_EXPR, val, tmp, NULL_TREE); ada/gcc-interface/trans.c: gnu_result = build3 (SWITCH_EXPR, TREE_TYPE (gnu_expr), gnu_expr, Perhaps the Fortran and Go front ends should build SWITCH_EXPRs with a NULL type, and gimplify_switch_expr() should assert that the SWITCH_EXPR type is never void_type node. That would make things match the documentation in tree.def again. I'll test a patch with these changes and commit it if it works. I suppose generic tree handling routines are confused by NULL TREE_TYPE and thus changing the docs to void_type_node would be more appropriate. Richard.
[PATCH][1/2] Fix PR44688, set and preserve the maximum iterations of vectorizer prologue loops
Finally.
Boostrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2012-04-18 Richard Guenther rguent...@suse.de
PR tree-optimization/44688
* cfgloop.h (record_niter_bound): Declare.
* tree-ssa-loop-niter.c (record_niter_bound): Export.
Update the estimation with the upper bound here...
(estimate_numbers_of_iterations_loop): ... instead of here.
Do not forcefully reset a recorded upper bound.
* tree-vect-loop-manip.c (vect_do_peeling_for_alignment):
Record the maximum number of loop iterations of the
prologue loop.
Index: gcc/tree-ssa-loop-niter.c
===
*** gcc/tree-ssa-loop-niter.c.orig 2012-04-18 10:55:55.0 +0200
--- gcc/tree-ssa-loop-niter.c 2012-04-18 11:39:25.368167852 +0200
*** derive_constant_upper_bound_ops (tree ty
*** 2494,2505
of iterations. UPPER is true if we are sure the loop iterates at most
I_BOUND times. */
! static void
record_niter_bound (struct loop *loop, double_int i_bound, bool realistic,
bool upper)
{
! /* Update the bounds only when there is no previous estimation, or when the
current
! estimation is smaller. */
if (upper
(!loop-any_upper_bound
|| double_int_ucmp (i_bound, loop-nb_iterations_upper_bound) 0))
--- 2494,2505
of iterations. UPPER is true if we are sure the loop iterates at most
I_BOUND times. */
! void
record_niter_bound (struct loop *loop, double_int i_bound, bool realistic,
bool upper)
{
! /* Update the bounds only when there is no previous estimation, or when the
! current estimation is smaller. */
if (upper
(!loop-any_upper_bound
|| double_int_ucmp (i_bound, loop-nb_iterations_upper_bound) 0))
*** record_niter_bound (struct loop *loop, d
*** 2514,2519
--- 2514,2527
loop-any_estimate = true;
loop-nb_iterations_estimate = i_bound;
}
+
+ /* If an upper bound is smaller than the realistic estimate of the
+ number of iterations, use the upper bound instead. */
+ if (loop-any_upper_bound
+loop-any_estimate
+double_int_ucmp (loop-nb_iterations_upper_bound,
+ loop-nb_iterations_estimate) 0)
+ loop-nb_iterations_estimate = loop-nb_iterations_upper_bound;
}
/* Records that AT_STMT is executed at most BOUND + 1 times in LOOP. IS_EXIT
*** estimate_numbers_of_iterations_loop (str
*** 2962,2969
/* Give up if we already have tried to compute an estimation. */
if (loop-estimate_state != EST_NOT_COMPUTED)
return;
loop-estimate_state = EST_AVAILABLE;
! loop-any_upper_bound = false;
loop-any_estimate = false;
exits = get_loop_exit_edges (loop);
--- 2970,2978
/* Give up if we already have tried to compute an estimation. */
if (loop-estimate_state != EST_NOT_COMPUTED)
return;
+
loop-estimate_state = EST_AVAILABLE;
! /* Force estimate compuation but leave any existing upper bound in place.
*/
loop-any_estimate = false;
exits = get_loop_exit_edges (loop);
*** estimate_numbers_of_iterations_loop (str
*** 2994,3007
bound = gcov_type_to_double_int (nit);
record_niter_bound (loop, bound, true, false);
}
-
- /* If an upper bound is smaller than the realistic estimate of the
- number of iterations, use the upper bound instead. */
- if (loop-any_upper_bound
-loop-any_estimate
-double_int_ucmp (loop-nb_iterations_upper_bound,
- loop-nb_iterations_estimate) 0)
- loop-nb_iterations_estimate = loop-nb_iterations_upper_bound;
}
/* Sets NIT to the estimated number of executions of the latch of the
--- 3003,3008
Index: gcc/tree-vect-loop-manip.c
===
*** gcc/tree-vect-loop-manip.c.orig 2012-04-17 12:59:22.0 +0200
--- gcc/tree-vect-loop-manip.c 2012-04-18 11:39:25.368167852 +0200
*** vect_do_peeling_for_alignment (loop_vec_
*** 2167,2172
--- 2167,2173
struct loop *new_loop;
unsigned int th = 0;
int min_profitable_iters;
+ int max_iter;
if (vect_print_dump_info (REPORT_DETAILS))
fprintf (vect_dump, === vect_do_peeling_for_alignment ===);
*** vect_do_peeling_for_alignment (loop_vec_
*** 2192,2197
--- 2193,2203
#ifdef ENABLE_CHECKING
slpeel_verify_cfg_after_peeling (new_loop, loop);
#endif
+ max_iter = MAX (LOOP_VINFO_VECT_FACTOR (loop_vinfo) - 1, (int) th);
+ record_niter_bound (new_loop, shwi_to_double_int (max_iter), false, true);
+ if (dump_file (dump_flags TDF_DETAILS))
+ fprintf (dump_file, Setting upper bound of nb iterations for prologue
+loop to %d\n, max_iter);
/* Update
Re: [google/integration] Add -Xclang-only option (issue6047048)
On Tue, Apr 17, 2012 at 23:38, Ollie Wild a...@google.com wrote: 2012-04-17 Ollie Wild a...@google.com * gcc/common.opt (Xclang-only): New option. * gcc/doc/invoke.texi (Xclang-only): Document new option. * gcc/gcc.c (display_help): Print new option. (driver_handle_option): Support new option (ignoring args). OK. Diego.
Re: [PATCH, i386, middle-end, tessuite] Intel TSX's HLE.
Stupid mailer.. sigh. trying again:
On 04/18/2012 05:36 AM, Kirill Yukhin wrote:
op = expand_normal (exp);
- if (INTVAL (op) 0 || INTVAL (op) = MEMMODEL_LAST)
+ if (INTVAL (op) 0)
{
warning (OPT_Winvalid_memory_model,
invalid memory model argument to builtin);
return MEMMODEL_SEQ_CST;
}
+
return (enum memmodel) INTVAL (op);
}
I think this could do better.
It suppose to check that the memory model is one of MEMMODEL_ enum's,
and if it isnt' report the error and change it to SEQ_CST. This is to
prevent people from accidentally passing invalid numbers in, like say '23'
I think this ought to check that
(INTVAL(op) memmodel_mask) is within the proper range.
It would be better if we could check that only other valid recognized
bits are set in the other word, but Im guessing thats not really
possible since thats really target specific at the moment.
In any case, I think it ought to check that the 16 reserved bits for
memory model is correct (like it use to for the whole enum), and if it
isn't, issue the warning and mask in SEQ_CST for the memory model portion.
I also think that it should no longer return an 'enum memmodel' since
the value can now be out of range. Maybe thats more a nit... how much
do we care if we use an enum value as an int? ie, do we need to worry
about passing this value around as an 'enum memodel' when we know its
more than 16 bits sometimes now?
Andrew
Re: [PATCH, i386, middle-end, tessuite] Intel TSX's HLE.
Sure, thanks for prompt! On Wed, Apr 18, 2012 at 2:12 PM, Uros Bizjak ubiz...@gmail.com wrote: On Wed, Apr 18, 2012 at 11:34 AM, Kirill Yukhin kirill.yuk...@gmail.com wrote: Hello guys, Since there is no more objections to my RFC, started here [1], I've implemented rest __atomic builtins in the same way. It corresponds to Spec, which can be found here [2]. Can you please implement printing of HLE prefix with %K operand modifier, like sync.md example in attached (untested) patch? Uros.
[PATCH][2/2] Fix PR44688, use the recorded maximum iterations in the unroller
This teaches loop-iv (RTL IV analysis) about loop-nb_iterations_upper_bound.
It avoids poinless unrolling of vectorizer prologue loops for now.
Bootstrap and regtest pending on x86_64-unknown-linux-gnu.
Richard.
2012-04-18 Richard Guenther rguent...@suse.de
PR rtl-optimization/44688
* loop-iv.c (determine_max_iter): Only return max_iter.
(iv_number_of_iterations): Also use the recorded loop bound
on the maximum number of iterations.
* loop-unroll.c (decide_unroll_runtime_iterations): Use
max_iter to avoid unrolling loops that do not roll.
(decide_unroll_stupid): Likewise.
Index: gcc/loop-iv.c
===
*** gcc/loop-iv.c.orig 2012-04-18 15:29:39.0 +0200
--- gcc/loop-iv.c 2012-04-18 16:03:21.91147 +0200
*** canonicalize_iv_subregs (struct rtx_iv *
*** 2190,2197
return true;
}
! /* Tries to estimate the maximum number of iterations in LOOP, and store the
!result in DESC. This function is called from iv_number_of_iterations with
a number of fields in DESC already filled in. OLD_NITER is the original
expression for the number of iterations, before we tried to simplify it.
*/
--- 2190,2197
return true;
}
! /* Tries to estimate the maximum number of iterations in LOOP, and return the
!result. This function is called from iv_number_of_iterations with
a number of fields in DESC already filled in. OLD_NITER is the original
expression for the number of iterations, before we tried to simplify it.
*/
*** determine_max_iter (struct loop *loop, s
*** 2207,2216
{
nmax = INTVAL (XEXP (niter, 0));
if (!(nmax (nmax + 1)))
! {
! desc-niter_max = nmax;
! return nmax;
! }
}
get_mode_bounds (desc-mode, desc-signed_p, desc-mode, mmin, mmax);
--- 2207,2213
{
nmax = INTVAL (XEXP (niter, 0));
if (!(nmax (nmax + 1)))
! return nmax;
}
get_mode_bounds (desc-mode, desc-signed_p, desc-mode, mmin, mmax);
*** determine_max_iter (struct loop *loop, s
*** 2219,2228
if (GET_CODE (niter) == UDIV)
{
if (!CONST_INT_P (XEXP (niter, 1)))
! {
! desc-niter_max = nmax;
! return nmax;
! }
inc = INTVAL (XEXP (niter, 1));
niter = XEXP (niter, 0);
}
--- 2216,
if (GET_CODE (niter) == UDIV)
{
if (!CONST_INT_P (XEXP (niter, 1)))
! return nmax;
inc = INTVAL (XEXP (niter, 1));
niter = XEXP (niter, 0);
}
*** determine_max_iter (struct loop *loop, s
*** 2241,2247
if (dump_file)
fprintf (dump_file, ;; improved upper bound by one.\n);
}
- desc-niter_max = nmax / inc;
return nmax / inc;
}
--- 2235,2240
*** iv_number_of_iterations (struct loop *lo
*** 2259,2265
enum rtx_code cond;
enum machine_mode mode, comp_mode;
rtx mmin, mmax, mode_mmin, mode_mmax;
! unsigned HOST_WIDEST_INT s, size, d, inv;
HOST_WIDEST_INT up, down, inc, step_val;
int was_sharp = false;
rtx old_niter;
--- 2252,2258
enum rtx_code cond;
enum machine_mode mode, comp_mode;
rtx mmin, mmax, mode_mmin, mode_mmax;
! unsigned HOST_WIDEST_INT s, size, d, inv, max;
HOST_WIDEST_INT up, down, inc, step_val;
int was_sharp = false;
rtx old_niter;
*** iv_number_of_iterations (struct loop *lo
*** 2279,2284
--- 2272,2280
desc-const_iter = false;
desc-niter_expr = NULL_RTX;
desc-niter_max = 0;
+ if (loop-any_upper_bound
+double_int_fits_in_uhwi_p (loop-nb_iterations_upper_bound))
+ desc-niter_max = loop-nb_iterations_upper_bound.low;
cond = GET_CODE (condition);
gcc_assert (COMPARISON_P (condition));
*** iv_number_of_iterations (struct loop *lo
*** 2547,2553
down = INTVAL (CONST_INT_P (iv0.base)
? iv0.base
: mode_mmin);
! desc-niter_max = (up - down) / inc + 1;
if (iv0.step == const0_rtx)
{
--- 2543,2552
down = INTVAL (CONST_INT_P (iv0.base)
? iv0.base
: mode_mmin);
! max = (up - down) / inc + 1;
! if (!desc-niter_max
! || max desc-niter_max)
! desc-niter_max = max;
if (iv0.step == const0_rtx)
{
*** iv_number_of_iterations (struct loop *lo
*** 2762,2769
}
else
{
! if (!desc-niter_max)
! desc-niter_max = determine_max_iter (loop, desc, old_niter);
/* simplify_using_initial_values does a copy propagation on the
registers
in the expression for the number of iterations. This prolongs life
--- 2761,2770
}
else
{
! max =
Re: [PATCH, i386, middle-end, tessuite] Intel TSX's HLE.
On Wed, Apr 18, 2012 at 06:16:02PM +0400, Kirill Yukhin wrote: In any case, I think it ought to check that the 16 reserved bits for memory model is correct (like it use to for the whole enum), and if it isn't, issue the warning and mask in SEQ_CST for the memory model portion. Good point. I'll check for overflow masked value there. And for the 16 bits reserved for target we should IMHO also warn or error on any unknown bits, otherwise we can't add later on meaning to the further bits. So, you could e.g. stick a mask of target bits to warn on into targetm, default to 0x and for i?86/x86_64 clear the two bits in it. Jakub
[PATCH, alpha]: Fix atomic_ior_* pattern name
Hello! This patch fixes alpha atomic_or vs atomic_ior confusion. 2012-04-18 Uros Bizjak ubiz...@gmail.com * config/alpha/sync.md (fetchop_name): Change ior attribute to or. Tested on alphaev68-pc-linux-gnu, committed to mainline and 4.7 branch. Uros. Index: config/alpha/sync.md === --- config/alpha/sync.md(revision 186571) +++ config/alpha/sync.md(working copy) @@ -19,7 +19,7 @@ (define_code_iterator FETCHOP [plus minus ior xor and]) (define_code_attr fetchop_name - [(plus add) (minus sub) (ior ior) (xor xor) (and and)]) + [(plus add) (minus sub) (ior or) (xor xor) (and and)]) (define_code_attr fetchop_pred [(plus add_operand) (minus reg_or_8bit_operand) (ior or_operand) (xor or_operand) (and and_operand)])
Re: [patch] Cleanup tree-switch-conversion a bit
On Wed, Apr 18, 2012 at 1:23 PM, Richard Guenther rguent...@suse.de wrote: I suppose generic tree handling routines are confused by NULL TREE_TYPE and thus changing the docs to void_type_node would be more appropriate. I don't agree with that. The documented behavior is much older than either the Fortran or the go front end, so the safest way is to fix those front ends to match the documentation. With my patch modified as attached, bootstraptest still passes. OK? Ciao! Steven fix_SWITCH_EXPR_builders.diff Description: Binary data
[patch] Fix CASE_LABEL_EXPR documentation in tree.def and tree-cfg.c
Subject says all. Will commit as obvious. * tree.def (CASE_LABEL_EXPR): Fix documentation, mention all operands. * tree-cfg.c (edge_to_cases): Fix documentation. Index: tree.def === --- tree.def(revision 186526) +++ tree.def(working copy) @@ -876,10 +876,16 @@ DEFTREECODE (LOOP_EXPR, loop_expr, tcc_statement of all the cases. */ DEFTREECODE (SWITCH_EXPR, switch_expr, tcc_statement, 3) -/* Used to represent a case label. The operands are CASE_LOW and - CASE_HIGH, respectively. If CASE_LOW is NULL_TREE, the label is a - 'default' label. If CASE_HIGH is NULL_TREE, the label is a normal case - label. CASE_LABEL is the corresponding LABEL_DECL. */ +/* Used to represent a case label. + + Operand 0 is CASE_LOW. It may be NULL_TREE, in which case the label + is a 'default' label. + Operand 1 is CASE_HIGH. If it is NULL_TREE, the label is a simple + (one-value) case label. If it is non-NULL_TREE, the case is a range. + Operand 2 is CASE_LABEL, which is is the corresponding LABEL_DECL. + Operand 4 is CASE_CHAIN. This operand is only used in tree-cfg.c to + speed up the lookup of case labels which use a particular edge in + the control flow graph. */ DEFTREECODE (CASE_LABEL_EXPR, case_label_expr, tcc_statement, 4) /* Used to represent an inline assembly statement. ASM_STRING returns a Index: tree-cfg.c === --- tree-cfg.c (revision 186526) +++ tree-cfg.c (working copy) @@ -56,7 +56,7 @@ static const int initial_cfg_capacity = 20; /* This hash table allows us to efficiently lookup all CASE_LABEL_EXPRs which use a particular edge. The CASE_LABEL_EXPRs are chained together - via their TREE_CHAIN field, which we clear after we're done with the + via their CASE_CHAIN field, which we clear after we're done with the hash table to prevent problems with duplication of GIMPLE_SWITCHes. Access to this list of CASE_LABEL_EXPRs allows us to efficiently
Re: Continue strict-volatile-bitfields fixes
Hi!
As it's been some time: this was the discussion about
-fstrict-volatile-bitfields (as enabled by default on SH, for example)
breaking some testsuite bits due to missed optimizations (even for
bitfields that are not volatile).
On Tue, 21 Feb 2012 09:40:07 +, Richard Earnshaw rearn...@arm.com wrote:
On 20/02/12 17:51, Bernd Schmidt wrote:
On 02/20/2012 06:39 PM, Richard Earnshaw wrote:
I'm not sure why it should be. Can't a user write
#ifdef __cplusplus
#define BOOL bool
#else
#define bool _Bool
#endif
struct x {
volatile BOOL a : 1;
volatile BOOL b : 1;
volatile unsigned char c : 6;
volatile BOOL d : 1;
} y;
?
If you've got strict volatile bitfields, then the concept here is that
the access uses the declared type for accessing the member. Since in
the ABI bool has a defined size, then it should access the member using
that size.
On ARM, sizeof bool is 1, so I'd take the above to mean that accessing
y.a to mean a read of a, b and c, but not d.
What are your thoughts on the argument about enums?
Similar. A particular enumeration type has a defined size, so accesses
should use that size.
In that case, would it be appropriate to apply the following?
gcc/testsuite/
* gcc.dg/tree-ssa/20030922-1.c: Compile with
-fno-strict-volatile-bitfields.
* gcc.dg/tree-ssa/foldconst-3.c: Likewise.
* gcc.dg/tree-ssa/vrp15.c: Likewise.
Index: gcc/testsuite/gcc.dg/tree-ssa/20030922-1.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/20030922-1.c (revision 355696)
+++ gcc/testsuite/gcc.dg/tree-ssa/20030922-1.c (working copy)
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-options -O1 -fdump-tree-dom2 } */
+/* { dg-options -O1 -fno-strict-volatile-bitfields -fdump-tree-dom2 } */
extern void abort (void);
Index: gcc/testsuite/gcc.dg/tree-ssa/foldconst-3.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/foldconst-3.c (revision 355696)
+++ gcc/testsuite/gcc.dg/tree-ssa/foldconst-3.c (working copy)
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-options -O2 -fdump-tree-optimized -fno-short-enums } */
+/* { dg-options -O2 -fno-strict-volatile-bitfields -fdump-tree-optimized
-fno-short-enums } */
typedef const union tree_node *const_tree;
typedef struct
{
Index: gcc/testsuite/gcc.dg/tree-ssa/vrp15.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/vrp15.c (revision 355696)
+++ gcc/testsuite/gcc.dg/tree-ssa/vrp15.c (working copy)
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-options -O2 -fdump-tree-vrp1 } */
+/* { dg-options -O2 -fno-strict-volatile-bitfields -fdump-tree-vrp1 } */
extern void abort (void) __attribute__ ((__noreturn__));
Grüße,
Thomas
pgpNAcGjy3Tcn.pgp
Description: PGP signature
Re: Continue strict-volatile-bitfields fixes
On 18/04/12 16:37, Thomas Schwinge wrote:
Hi!
As it's been some time: this was the discussion about
-fstrict-volatile-bitfields (as enabled by default on SH, for example)
breaking some testsuite bits due to missed optimizations (even for
bitfields that are not volatile).
On Tue, 21 Feb 2012 09:40:07 +, Richard Earnshaw rearn...@arm.com wrote:
On 20/02/12 17:51, Bernd Schmidt wrote:
On 02/20/2012 06:39 PM, Richard Earnshaw wrote:
I'm not sure why it should be. Can't a user write
#ifdef __cplusplus
#define BOOL bool
#else
#define bool _Bool
#endif
struct x {
volatile BOOL a : 1;
volatile BOOL b : 1;
volatile unsigned char c : 6;
volatile BOOL d : 1;
} y;
?
If you've got strict volatile bitfields, then the concept here is that
the access uses the declared type for accessing the member. Since in
the ABI bool has a defined size, then it should access the member using
that size.
On ARM, sizeof bool is 1, so I'd take the above to mean that accessing
y.a to mean a read of a, b and c, but not d.
What are your thoughts on the argument about enums?
Similar. A particular enumeration type has a defined size, so accesses
should use that size.
In that case, would it be appropriate to apply the following?
gcc/testsuite/
* gcc.dg/tree-ssa/20030922-1.c: Compile with
-fno-strict-volatile-bitfields.
* gcc.dg/tree-ssa/foldconst-3.c: Likewise.
* gcc.dg/tree-ssa/vrp15.c: Likewise.
None of these have any volatile bitfields, so the option should be a no-op.
Re: Continue strict-volatile-bitfields fixes
On 04/18/2012 06:14 PM, Richard Earnshaw wrote: On 18/04/12 16:37, Thomas Schwinge wrote: gcc/testsuite/ * gcc.dg/tree-ssa/20030922-1.c: Compile with -fno-strict-volatile-bitfields. * gcc.dg/tree-ssa/foldconst-3.c: Likewise. * gcc.dg/tree-ssa/vrp15.c: Likewise. None of these have any volatile bitfields, so the option should be a no-op. The problem is that we have to treat normal bitfields differently as well, since a variable may later be declared as volatile. Bernd
[PATCH] Add -fdump-rtl-pass-quiet
This patch scratches an itch I've had for a while.
Basically it just reduces all tree and RTL dumps to just the function
dump. This means that the files are easier to diff.
This can still be combined with the other options of course:
e.g. -fdump-rtl-all-quiet-slim is quite nice.
Obviously, most of the passes do dumps by calling fprintf directly, and
I don't want to edit each and every case, so I've implemented this by
setting dump_file=NULL in execute_one_pass.
OK to commit?
Andrew
2012-04-18 Andrew Stubbs a...@codesourcery.com
gcc/
* tree-pass.h (TDF_QUIET): New define.
* tree-dump.c (dump_options): Add quiet.
* passes.c (execute_one_pass): Handle TDF_QUIET.
* doc/invoke.texi: Document -fdump-tree-quiet.
Mention -fdump-rtl-pass-options form.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index a13ddfa..1082b13 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -5229,6 +5229,7 @@ of option arguments.
@item -d@var{letters}
@itemx -fdump-rtl-@var{pass}
+@itemx -fdump-rtl-@var{pass}-@var{options}
@opindex d
Says to make debugging dumps during compilation at times specified by
@var{letters}. This is used for debugging the RTL-based passes of the
@@ -5244,6 +5245,9 @@ explicitly specified and it is not an executable, otherwise it is the
basename of the source file. These switches may have different effects
when @option{-E} is used for preprocessing.
+The @option{-fdump-rtl-@var{pass}-@var{options}} form uses the same
+@var{options} as @option{-fdump-tree-@var{pass}-@var{options}}.
+
Debug dumps can be enabled with a @option{-fdump-rtl} switch or some
@option{-d} option @var{letters}. Here are the possible
letters for use in @var{pass} and @var{letters}, and their meanings:
@@ -5672,9 +5676,11 @@ Enable showing the tree dump for each statement.
Enable showing the EH region number holding each statement.
@item scev
Enable showing scalar evolution analysis details.
+@item quiet
+Disable all but the function dump.
@item all
-Turn on all options, except @option{raw}, @option{slim}, @option{verbose}
-and @option{lineno}.
+Turn on all options, except @option{raw}, @option{slim}, @option{verbose},
+@option{lineno} and @option{quiet}.
@end table
The following tree dumps are possible:
diff --git a/gcc/passes.c b/gcc/passes.c
index a786881..e946c63 100644
--- a/gcc/passes.c
+++ b/gcc/passes.c
@@ -2078,8 +2078,16 @@ execute_one_pass (struct opt_pass *pass)
/* Do it! */
if (pass-execute)
{
+ FILE *tmp = dump_file;
+
+ if (dump_flags TDF_QUIET)
+ dump_file = NULL;
+
todo_after = pass-execute ();
do_per_function (clear_last_verified, NULL);
+
+ if (dump_flags TDF_QUIET)
+ dump_file = tmp;
}
/* Stop timevar. */
diff --git a/gcc/tree-dump.c b/gcc/tree-dump.c
index 3e89cdf..81f3262 100644
--- a/gcc/tree-dump.c
+++ b/gcc/tree-dump.c
@@ -824,9 +824,11 @@ static const struct dump_option_value_info dump_options[] =
{nouid, TDF_NOUID},
{enumerate_locals, TDF_ENUMERATE_LOCALS},
{scev, TDF_SCEV},
+ {quiet, TDF_QUIET},
{all, ~(TDF_RAW | TDF_SLIM | TDF_LINENO | TDF_TREE | TDF_RTL | TDF_IPA
| TDF_STMTADDR | TDF_GRAPH | TDF_DIAGNOSTIC | TDF_VERBOSE
- | TDF_RHS_ONLY | TDF_NOUID | TDF_ENUMERATE_LOCALS | TDF_SCEV)},
+ | TDF_RHS_ONLY | TDF_NOUID | TDF_ENUMERATE_LOCALS | TDF_SCEV
+ | TDF_QUIET)},
{NULL, 0}
};
diff --git a/gcc/tree-pass.h b/gcc/tree-pass.h
index 6f1fd6a..ed47dd1 100644
--- a/gcc/tree-pass.h
+++ b/gcc/tree-pass.h
@@ -84,6 +84,7 @@ enum tree_dump_index
#define TDF_ENUMERATE_LOCALS (1 22) /* Enumerate locals by uid. */
#define TDF_CSELIB (1 23) /* Dump cselib details. */
#define TDF_SCEV (1 24) /* Dump SCEV details. */
+#define TDF_QUIET (1 25) /* Dump only function content. */
/* In tree-dump.c */
Re: Wider modes for partial int modes
On 04/17/2012 04:08 PM, Bernd Schmidt wrote: * machmode.h (CLASS_HAS_WIDER_MODES_P): True for MODE_PARTIAL_INT. * expr.c (convert_move): Honor unsignedp when extending partial int modes. * genmodes.c (power_of_two_p, regular_mode, make_complex_modes, emit_mode_wider): Revert Spider hacks. (complete_mode): Don't clear component field of partial int modes. (emit_mode_inner): Don't emit it however. (calc_wider_mode): Partial int modes widen to their component. Ok. r~
Re: [Fortran] Patch ping
On Tue, Apr 17, 2012 at 12:47:48AM +0200, Tobias Burnus wrote: Approved but not yet committed: Bernhard: - [PATCH] gfortran testsuite: implicitly cleanup-modules, part 2 http://gcc.gnu.org/ml/fortran/2012-04/msg00065.html Before actually pushing this, I ment to ask if we *want* to make sure that we do not add superfluous cleanup-module calls in the future (which would slow down testing needlessly)? If so we would either have to manually reject occurances of those during patch-review or install a warning or the like if there is an explicit cleanup-modules call yielding the same set as the now automatically determined set. Since i have not yet looked into the automatic warning myself i would have hoped that you would not add more explicit cleanup-module calls but i guess this will not really work out, long-term :) Thoughts?
Symbol table 9/many: symtab verifier
Hi,
this patch introduce symbol table verificatoin facility. In addition to what
can be broken out of cgraph verifier, the assembler hash consistency is
checked. The patch also fixes one latent LTO bug caught by the verifier where
we did not dissolve varpool same comdat group lists when bringing variables
static.
Bootstrapped/regtested x86_64-linux. Will commit it shortly.
Honza
* cgraph.h (verify_symtab, verify_symtab_node, verify_symtab_base):
Declare.
* cgraphunit.c (verify_cgraph_node): Verify symtab base; do not verify
cgraph hash and same comdat groups.
(cgraph_optimize); Verify symbol table.
* ipa.c (cgraph_remove_unreachable_nodes): Verify symbol table.
(dissolve_same_comdat_group_list): Work on symtab nodes.
(function_and_variable_visibility): Dissolve variable same comdat group
lists, too.
* symtab.c: Include timevar.h
(verify_symtab_base, verify_symtab_node, verify_symtab): New functions.
Index: cgraph.h
===
--- cgraph.h(revision 186564)
+++ cgraph.h(working copy)
@@ -512,6 +512,9 @@ void debug_symtab (void);
void dump_symtab_node (FILE *, symtab_node);
void debug_symtab_node (symtab_node);
void dump_symtab_base (FILE *, symtab_node);
+void verify_symtab (void);
+void verify_symtab_node (symtab_node);
+bool verify_symtab_base (symtab_node);
/* In cgraph.c */
void dump_cgraph (FILE *);
Index: cgraphunit.c
===
--- cgraphunit.c(revision 186564)
+++ cgraphunit.c(working copy)
@@ -577,6 +577,7 @@ verify_cgraph_node (struct cgraph_node *
return;
timevar_push (TV_CGRAPH_VERIFY);
+ error_found |= verify_symtab_base ((symtab_node) node);
for (e = node-callees; e; e = e-next_callee)
if (e-aux)
{
@@ -663,12 +664,6 @@ verify_cgraph_node (struct cgraph_node *
error_found = true;
}
- if (!cgraph_get_node (node-symbol.decl))
-{
- error (node not found in cgraph_hash);
- error_found = true;
-}
-
if (node-clone_of)
{
struct cgraph_node *n;
@@ -708,32 +703,6 @@ verify_cgraph_node (struct cgraph_node *
error (double linked list of clones corrupted);
error_found = true;
}
- if (node-symbol.same_comdat_group)
-{
- symtab_node n = node-symbol.same_comdat_group;
-
- if (!DECL_ONE_ONLY (n-symbol.decl))
- {
- error (non-DECL_ONE_ONLY node in a same_comdat_group list);
- error_found = true;
- }
- if (n == (symtab_node)node)
- {
- error (node is alone in a comdat group);
- error_found = true;
- }
- do
- {
- if (!n-symbol.same_comdat_group)
- {
- error (same_comdat_group is not a circular list);
- error_found = true;
- break;
- }
- n = n-symbol.same_comdat_group;
- }
- while (n != (symtab_node)node);
-}
if (node-analyzed node-alias)
{
@@ -2654,7 +2623,7 @@ cgraph_optimize (void)
return;
#ifdef ENABLE_CHECKING
- verify_cgraph ();
+ verify_symtab ();
#endif
/* Frontend may output common variables after the unit has been finalized.
@@ -2704,7 +2673,7 @@ cgraph_optimize (void)
if (!quiet_flag)
fprintf (stderr, Assembling functions:\n);
#ifdef ENABLE_CHECKING
- verify_cgraph ();
+ verify_symtab ();
#endif
cgraph_materialize_all_clones ();
@@ -2712,7 +2681,7 @@ cgraph_optimize (void)
execute_ipa_pass_list (all_late_ipa_passes);
cgraph_remove_unreachable_nodes (true, dump_file);
#ifdef ENABLE_CHECKING
- verify_cgraph ();
+ verify_symtab ();
#endif
bitmap_obstack_release (NULL);
cgraph_mark_functions_to_output ();
@@ -2740,7 +2709,7 @@ cgraph_optimize (void)
dump_symtab (cgraph_dump_file);
}
#ifdef ENABLE_CHECKING
- verify_cgraph ();
+ verify_symtab ();
/* Double check that all inline clones are gone and that all
function bodies have been released from memory. */
if (!seen_error ())
Index: ipa.c
===
--- ipa.c (revision 186564)
+++ ipa.c (working copy)
@@ -176,7 +176,7 @@ cgraph_remove_unreachable_nodes (bool be
bool changed = false;
#ifdef ENABLE_CHECKING
- verify_cgraph ();
+ verify_symtab ();
#endif
if (file)
fprintf (file, \nReclaiming functions:);
@@ -467,7 +467,7 @@ cgraph_remove_unreachable_nodes (bool be
return changed;
#ifdef ENABLE_CHECKING
- verify_cgraph ();
+ verify_symtab ();
#endif
/* Reclaim alias pairs for functions that have disappeared from the
@@ -730,12 +730,12 @@ varpool_externally_visible_p (struct var
/* Dissolve the same_comdat_group list in which NODE resides. */
static void
-dissolve_same_comdat_group_list (struct cgraph_node *node)
+dissolve_same_comdat_group_list (symtab_node node)
{
- struct
[C++ Patch] PR 52363
Hi,
thus I'm handling this issue per the discussion in the audit trail: by
adding a tsubst_flags_t parameter to 'joust' and 'tourney' and adjusting
the callers. Then 'joust' deals with SFINAE as-if pedantic mode were
unconditionally active.
Tested x86_64-linux.
Thanks,
Paolo.
/cp
2012-04-18 Paolo Carlini paolo.carl...@oracle.com
PR c++/52363
* call.c (tourney): Add tsubst_flags_t parameter.
(joust): Likewise, use it to handle SFINAE as if pedantic.
(build_user_type_conversion_1, perform_overload_resolution,
build_op_call_1, build_conditional_expr_1, build_new_op_1,
build_over_call, build_new_method_call_1): Adjust.
/testsuite
2012-04-18 Paolo Carlini paolo.carl...@oracle.com
PR c++/52363
* testsuite/g++.dg/cpp0x/sfinae35.C: New.
* testsuite/g++.dg/cpp0x/sfinae36.C: Likewise.
Index: testsuite/g++.dg/cpp0x/sfinae35.C
===
--- testsuite/g++.dg/cpp0x/sfinae35.C (revision 0)
+++ testsuite/g++.dg/cpp0x/sfinae35.C (revision 0)
@@ -0,0 +1,13 @@
+// PR c++/52363
+// { dg-options -std=c++11 }
+
+#include type_traits
+
+struct proxy
+{
+ void operator=(int const);
+ void operator=(int) const;
+};
+
+static_assert( !std::is_assignableproxy, int::value, );
+static_assert( std::is_assignableconst proxy, int::value, );
Index: testsuite/g++.dg/cpp0x/sfinae36.C
===
--- testsuite/g++.dg/cpp0x/sfinae36.C (revision 0)
+++ testsuite/g++.dg/cpp0x/sfinae36.C (revision 0)
@@ -0,0 +1,13 @@
+// PR c++/52363
+// { dg-options -std=c++11 -pedantic }
+
+#include type_traits
+
+struct proxy
+{
+ void operator=(int const);
+ void operator=(int) const;
+};
+
+static_assert( !std::is_assignableproxy, int::value, );
+static_assert( std::is_assignableconst proxy, int::value, );
Index: cp/call.c
===
--- cp/call.c (revision 186573)
+++ cp/call.c (working copy)
@@ -142,9 +142,10 @@ static struct obstack conversion_obstack;
static bool conversion_obstack_initialized;
struct rejection_reason;
-static struct z_candidate * tourney (struct z_candidate *);
+static struct z_candidate * tourney (struct z_candidate *, tsubst_flags_t);
static int equal_functions (tree, tree);
-static int joust (struct z_candidate *, struct z_candidate *, bool);
+static int joust (struct z_candidate *, struct z_candidate *, bool,
+ tsubst_flags_t);
static int compare_ics (conversion *, conversion *);
static tree build_over_call (struct z_candidate *, int, tsubst_flags_t);
static tree build_java_interface_fn_ref (tree, tree);
@@ -3582,7 +3583,7 @@ build_user_type_conversion_1 (tree totype, tree ex
return NULL;
}
- cand = tourney (candidates);
+ cand = tourney (candidates, tf_warning_or_error);
if (cand == 0)
{
if (flags LOOKUP_COMPLAIN)
@@ -3800,7 +3801,7 @@ perform_overload_resolution (tree fn,
*candidates = splice_viable (*candidates, pedantic, any_viable_p);
if (*any_viable_p)
-cand = tourney (*candidates);
+cand = tourney (*candidates, tf_warning_or_error);
else
cand = NULL;
@@ -4106,7 +4107,7 @@ build_op_call_1 (tree obj, VEC(tree,gc) **args, ts
}
else
{
- cand = tourney (candidates);
+ cand = tourney (candidates, complain);
if (cand == 0)
{
if (complain tf_error)
@@ -4584,7 +4585,7 @@ build_conditional_expr_1 (tree arg1, tree arg2, tr
}
return error_mark_node;
}
- cand = tourney (candidates);
+ cand = tourney (candidates, complain);
if (!cand)
{
if (complain tf_error)
@@ -5113,7 +5114,7 @@ build_new_op_1 (enum tree_code code, int flags, tr
}
else
{
- cand = tourney (candidates);
+ cand = tourney (candidates, complain);
if (cand == 0)
{
if ((flags LOOKUP_COMPLAIN) (complain tf_error))
@@ -5140,7 +5141,7 @@ build_new_op_1 (enum tree_code code, int flags, tr
{
struct candidate_warning *w;
for (w = cand-warnings; w; w = w-next)
- joust (cand, w-loser, 1);
+ joust (cand, w-loser, 1, complain);
}
/* Check for comparison of different enum types. */
@@ -6383,7 +6384,7 @@ build_over_call (struct z_candidate *cand, int fla
{
struct candidate_warning *w;
for (w = cand-warnings; w; w = w-next)
- joust (cand, w-loser, 1);
+ joust (cand, w-loser, 1, complain);
}
/* Make =delete work with SFINAE. */
@@ -7318,7 +7319,7 @@ build_new_method_call_1 (tree instance, tree fns,
}
else
{
- cand = tourney (candidates);
+ cand = tourney (candidates, complain);
if (cand == 0)
{
char *pretty_name;
@@ -8013,7 +8014,8 @@ add_warning (struct z_candidate
Re: [PATCH] Add -fdump-rtl-pass-quiet
Why only rtl? Minor suggestion: use ir or il may be more intuitive: -fdump-rtl-all-ir thanks, David On Wed, Apr 18, 2012 at 9:35 AM, Andrew Stubbs a...@codesourcery.com wrote: This patch scratches an itch I've had for a while. Basically it just reduces all tree and RTL dumps to just the function dump. This means that the files are easier to diff. This can still be combined with the other options of course: e.g. -fdump-rtl-all-quiet-slim is quite nice. Obviously, most of the passes do dumps by calling fprintf directly, and I don't want to edit each and every case, so I've implemented this by setting dump_file=NULL in execute_one_pass. OK to commit? Andrew
[PATCH][Cilkplus] Fixing function param of is_elem_fn
Hello Everyone,
This patch is for the Cilkplus branch affecting both C and C++ compilers.
This patch will change the parameter from cgraph_node * to tree of type
function declaration.
Thanks,
Balaji V. Iyer.
diff --git a/gcc/ChangeLog.cilk b/gcc/ChangeLog.cilk
index 6078abf..8627920 100644
--- a/gcc/ChangeLog.cilk
+++ b/gcc/ChangeLog.cilk
@@ -1,3 +1,9 @@
+2012-04-16 Balaji V. Iyer balaji.v.i...@intel.com
+
+ * elem-function.c (is_elem_fn): Changed the parameter type from a
+ cgraph_node to tree of type function decl.
+ (create_elem_vec_fn): Likewise.
+
2012-04-14 Balaji V. Iyer balaji.v.i...@intel.com
* cgraphunit.c (cgraph_add_new_function): Replaced cgraph_create_node
diff --git a/gcc/elem-function.c b/gcc/elem-function.c
index 328e05e..4cc9035 100644
--- a/gcc/elem-function.c
+++ b/gcc/elem-function.c
@@ -109,13 +109,10 @@ rename_elem_fn (tree decl, const char *suffix)
/* this function will check to see if the node is part of an function that
* needs to be converted to its vector equivalent. */
static bool
-is_elem_fn (struct cgraph_node *node)
+is_elem_fn (tree fndecl)
{
- tree fndecl, ii_tree;
- if (!node)
-return false;
+ tree ii_tree;
- fndecl = node-symbol.decl;
for (ii_tree = DECL_ATTRIBUTES (fndecl); ii_tree;
ii_tree = TREE_CHAIN (ii_tree))
{
@@ -562,7 +559,7 @@ create_elem_vec_fn (void)
for (ii_node = cgraph_nodes; ii_node != NULL; ii_node = ii_node-next)
{
tree node_decl = ii_node-symbol.decl;
- if (is_elem_fn (ii_node)
+ if (is_elem_fn (node_decl)
DECL_STRUCT_FUNCTION (node_decl)
!DECL_STRUCT_FUNCTION (node_decl)-elem_fn_already_cloned)
{
Re: [Fixinclude]: Fix typo and default to twoprocess on VMS
Hi, When I approved a patch in 2008, there was a typo. I didn't notice and it was fixed by removing a formatting element. Your patch corrects the error. Please apply your changes to active branches. Thank you! Regards, Bruce
Re: [patch] Cleanup tree-switch-conversion a bit
On Wed, Apr 18, 2012 at 8:30 PM, Steven Bosscher stevenb@gmail.com wrote: The Go bits approved on IRC by Iant, the Fortran bits are obvious, and the rest was already approved. This is r186579 now. And because I managed to commit from the wrong tree, the fixed commit is r186580. Index: gimplify.c === --- gimplify.c (revision 186579) +++ gimplify.c (working copy) @@ -1578,7 +1578,6 @@ gimplify_switch_expr (tree *expr_p, gimple_seq *pr tree index_type = TREE_TYPE (switch_expr); if (index_type == NULL_TREE) index_type = TREE_TYPE (SWITCH_COND (switch_expr)); - gcc_assert (INTEGRAL_TYPE_P (index_type)); ret = gimplify_expr (SWITCH_COND (switch_expr), pre_p, NULL, is_gimple_val, fb_rvalue);
Re: [C++ Patch] PR 52363
On 04/18/2012 01:44 PM, Paolo Carlini wrote: + cand = tourney (candidates, tf_warning_or_error); This seems unlikely to do the right thing; we can get here in both SFINAE and non-SFINAE situations. In build_user_type_conversion_1 I think we can get away with checking LOOKUP_COMPLAIN; for perform_overload_conversion we need to pass in complain. Jason
[RFA] dwarf2.h (dwarf_location_atom): Add DW_OP_GNU_addr_index.
Hi. This patch adds DW_OP_GNU_addr_index to dwarf2.h. Ok to commit? 2012-04-18 Doug Evans d...@google.com * dwarf2.h (dwarf_location_atom): Add DW_OP_GNU_addr_index. Index: include/dwarf2.h === RCS file: /cvs/src/src/include/dwarf2.h,v retrieving revision 1.28 diff -u -p -r1.28 dwarf2.h --- include/dwarf2.h26 Jan 2012 22:57:17 - 1.28 +++ include/dwarf2.h18 Apr 2012 17:37:23 - @@ -578,6 +578,8 @@ enum dwarf_location_atom DW_OP_GNU_reinterpret = 0xf9, /* The GNU parameter ref extension. */ DW_OP_GNU_parameter_ref = 0xfa, +/* Extension for Fission. See http://gcc.gnu.org/wiki/DebugFission. */ +DW_OP_GNU_addr_index = 0xfb, /* HP extensions. */ DW_OP_HP_unknown = 0xe0, /* Ouch, the same as GNU_push_tls_address. */ DW_OP_HP_is_value= 0xe1,
Re: Remove SETJMP_VIA_SAVE_AREA support
On Jun 2, 2011, at 3:41 AM, Eric Botcazou wrote: This removes the (undocumented) support for SETJMP_VIA_SAVE_AREA from the compiler. 2011-06-02 Eric Botcazou ebotca...@adacore.com * builtins.c (expand_builtin_setjmp_setup): Do not set calls_setjmp. --- builtins.c(revision 174559) +++ builtins.c(working copy) @@ -806,10 +806,6 @@ expand_builtin_setjmp_setup (rtx buf_add emit_insn (gen_builtin_setjmp_setup (buf_addr)); #endif - /* Tell optimize_save_area_alloca that extra work is going to - need to go on during alloca. */ - cfun-calls_setjmp = 1; - /* We have a nonlocal label. */ cfun-has_nonlocal_label = 1; } You do know that at least rtl hoisting is dependent upon calls_setjmp being set, right? :-( This part breaks my port. I think you read the comment and thought it was exhaustive, I don't believe it is. Any objection to putting it back, or, would you like me to drill down on rtl hoisting?
Re: [PATCH] Add -fdump-rtl-pass-quiet
On 18/04/12 19:00, Xinliang David Li wrote: Why only rtl? Minor suggestion: use ir or il may be more intuitive: -fdump-rtl-all-ir It isn't only RTL. It also applies to the tree dumps. I did say so in my message, although all the examples were RTL. Also, ir and il are not more intuitive to me. You're going to have to explain what those mean. Intermediate Representation? Andrew
Re: [C++ Patch] PR 52363
Hi On 04/18/2012 01:44 PM, Paolo Carlini wrote: + cand = tourney (candidates, tf_warning_or_error); This seems unlikely to do the right thing; we can get here in both SFINAE and non-SFINAE situations. In build_user_type_conversion_1 I think we can get away with checking LOOKUP_COMPLAIN; for perform_overload_conversion we need to pass in complain. Ok. perform_overload_conversion can get a complain very smoothly, too bad I didn't try it to earlier today. build_user_type_conversion_1 seems more tricky: I understood your suggestion as something like: - cand = tourney (candidates); + cand = tourney (candidates, (flags LOOKUP_COMPLAIN) + ? tf_warning_or_error : tf_none); and didn't work well enough, I got these fails: FAIL: g++.old-deja/g++.benjamin/16077.C -std=gnu++98 nic (test for warnings, line 24) FAIL: g++.old-deja/g++.benjamin/16077.C -std=gnu++98 conv (test for warnings, line 24) FAIL: g++.old-deja/g++.benjamin/16077.C -std=gnu++98 note (test for warnings, line 24) FAIL: g++.old-deja/g++.benjamin/16077.C -std=gnu++11 nic (test for warnings, line 24) FAIL: g++.old-deja/g++.benjamin/16077.C -std=gnu++11 conv (test for warnings, line 24) FAIL: g++.old-deja/g++.benjamin/16077.C -std=gnu++11 note (test for warnings, line 24) FAIL: g++.old-deja/g++.other/overcnv2.C -std=gnu++98 B (test for warnings, line 19) FAIL: g++.old-deja/g++.other/overcnv2.C -std=gnu++98 conv (test for warnings, line 19) FAIL: g++.old-deja/g++.other/overcnv2.C -std=gnu++98 note (test for warnings, line 19) FAIL: g++.old-deja/g++.other/overcnv2.C -std=gnu++11 B (test for warnings, line 19) FAIL: g++.old-deja/g++.other/overcnv2.C -std=gnu++11 conv (test for warnings, line 19) FAIL: g++.old-deja/g++.other/overcnv2.C -std=gnu++11 note (test for warnings, line 19) Thus, if I don't ear from you, I'm probably going to add complain to build_user_type_conversion_1, hopefully I can manage, I remember that earlier today I tried and was dragging in a lot of changes... Thanks, Paolo.
Re: [Fortran] Patch ping
On Apr 18, 2012, at 9:57 AM, Bernhard Reutner-Fischer wrote: Before actually pushing this, I ment to ask if we *want* to make sure that we do not add superfluous cleanup-module calls in the future (which would slow down testing needlessly)? I'd run you script again in another 6 months, and once again in a year, that'd probably catch 99% of what a check would catch, and runs faster for 99% of the people. Since i have not yet looked into the automatic warning myself i would have hoped that you would not add more explicit cleanup-module calls but i guess this will not really work out, long-term :) Sure it will, you remove the documentation for it (or make it clear when it isn't necessary), and beat everyone on the head that does it. Usually, you'd only have to bonk each person twice, then, you're done. I can't imagine more than 30 bonks would be necessary to train them up. :-)
New Swedish PO file for 'gcc' (version 4.7.0)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the Swedish team of translators. The file is available at: http://translationproject.org/latest/gcc/sv.po (This file, 'gcc-4.7.0.sv.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/gcc/ 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/gcc.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
Re: [patch] Fix CASE_LABEL_EXPR documentation in tree.def and tree-cfg.c
Steven == Steven Bosscher stevenb@gmail.com writes: Steven Subject says all. Will commit as obvious. Steven * tree.def (CASE_LABEL_EXPR): Fix documentation, mention all operands. Thank you. Tom
Re: [PATCH] Add -fdump-rtl-pass-quiet
On Wed, Apr 18, 2012 at 12:42 PM, Andrew Stubbs a...@codesourcery.com wrote: On 18/04/12 19:00, Xinliang David Li wrote: Why only rtl? Minor suggestion: use ir or il may be more intuitive: -fdump-rtl-all-ir It isn't only RTL. It also applies to the tree dumps. I did say so in my message, although all the examples were RTL. Also, ir and il are not more intuitive to me. You're going to have to explain what those mean. Intermediate Representation? yes, it means intermediate representation. The dump flags can be roughly categorized like this: 1) first level flags to control what to dump 2) second level flags to control how the dump is done 3) first level flags to control where to dump (to be added) 4) first level flags to control when to dump (to be added) Flags in category 1) -- There are four types of information that can be dumped (should be controlled by flag set 1) ): 1.a) transformation decisions -- such as -fdump-tree-vectorize-transformations (to be added) 1.b) Intermediate representations -- related to what you propose 1.c) debug traces (flag to be added) 1.d) stats (memory usage, etc). The default should be dumping all 4 types, but can be individually controlled, e.g, dump transformation + IR: -fdump-tree-all-transformations-ir 1.a) can be used to implement -fopt-info option (to dump optimization info notes to stderr) -- there is a separate discussion thread on this Category 2) --- Most of the existing flags are here. For instance, the following second level flags are used to control IR dump: vops, slim, verbose (may need to be renamed), raw, blocks, address, etc. The flag 'details' is used to control the debug trace level. Category 3) The new proposed flag is to allow the dump to be emitted to stderr: -fdump-tree-all-transformations-stderr Category 4) --- These are new proposed flags: To control IR dump before the pass or after the pass. Sharad will be working on cleaning up the dump infrastructure, so that work will cover what you need. thanks, David Andrew
Re: [C++ Patch] PR 52363
Hi again,
Thus, if I don't ear from you, I'm probably going to add complain to
build_user_type_conversion_1, hopefully I can manage, I remember that
earlier today I tried and was dragging in a lot of changes...
The below adds complain to build_user_type_conversion_1 and
build_user_type_conversion too (besides perform_overload_resolution,
etc) thus convert_like_real can propagate complain down to the former.
This version too passes testing.
Thanks!
Paolo.
///
/cp
2012-04-18 Paolo Carlini paolo.carl...@oracle.com
PR c++/52363
* call.c (tourney, perform_overload_resolution,
build_operator_new_call, build_user_type_conversion_1,
build_user_type_conversion, perform_overload_resolution):
Add tsubst_flags_t parameter.
(joust): Likewise, use it to handle SFINAE as if pedantic.
(reference_binding, implicit_conversion,
build_new_function_call, build_new_function_call,
build_op_call_1, build_conditional_expr_1,
build_new_op_1, convert_like_real, build_over_call,
build_new_method_call_1): Adjust.
* init.c (build_new_1): Likewise.
* cvt.c (ocp_convert, build_type_conversion,
build_expr_type_conversion): Likewise.
* cp-tree.h (build_user_type_conversion,
build_operator_new_call): Adjust declaration.
/testsuite
2012-04-18 Paolo Carlini paolo.carl...@oracle.com
PR c++/52363
* testsuite/g++.dg/cpp0x/sfinae35.C: New.
* testsuite/g++.dg/cpp0x/sfinae36.C: Likewise.
Index: testsuite/g++.dg/cpp0x/sfinae35.C
===
--- testsuite/g++.dg/cpp0x/sfinae35.C (revision 0)
+++ testsuite/g++.dg/cpp0x/sfinae35.C (revision 0)
@@ -0,0 +1,13 @@
+// PR c++/52363
+// { dg-options -std=c++11 }
+
+#include type_traits
+
+struct proxy
+{
+ void operator=(int const);
+ void operator=(int) const;
+};
+
+static_assert( !std::is_assignableproxy, int::value, );
+static_assert( std::is_assignableconst proxy, int::value, );
Index: testsuite/g++.dg/cpp0x/sfinae36.C
===
--- testsuite/g++.dg/cpp0x/sfinae36.C (revision 0)
+++ testsuite/g++.dg/cpp0x/sfinae36.C (revision 0)
@@ -0,0 +1,13 @@
+// PR c++/52363
+// { dg-options -std=c++11 -pedantic }
+
+#include type_traits
+
+struct proxy
+{
+ void operator=(int const);
+ void operator=(int) const;
+};
+
+static_assert( !std::is_assignableproxy, int::value, );
+static_assert( std::is_assignableconst proxy, int::value, );
Index: cp/init.c
===
--- cp/init.c (revision 186573)
+++ cp/init.c (working copy)
@@ -2381,7 +2381,7 @@ build_new_1 (VEC(tree,gc) **placement, tree type,
alloc_call = build_operator_new_call (fnname, placement,
size, cookie_size,
- alloc_fn);
+ alloc_fn, complain);
}
}
Index: cp/call.c
===
--- cp/call.c (revision 186573)
+++ cp/call.c (working copy)
@@ -142,9 +142,10 @@ static struct obstack conversion_obstack;
static bool conversion_obstack_initialized;
struct rejection_reason;
-static struct z_candidate * tourney (struct z_candidate *);
+static struct z_candidate * tourney (struct z_candidate *, tsubst_flags_t);
static int equal_functions (tree, tree);
-static int joust (struct z_candidate *, struct z_candidate *, bool);
+static int joust (struct z_candidate *, struct z_candidate *, bool,
+ tsubst_flags_t);
static int compare_ics (conversion *, conversion *);
static tree build_over_call (struct z_candidate *, int, tsubst_flags_t);
static tree build_java_interface_fn_ref (tree, tree);
@@ -160,7 +161,8 @@ static tree convert_like_real (conversion *, tree,
bool, tsubst_flags_t);
static void op_error (enum tree_code, enum tree_code, tree, tree,
tree, bool);
-static struct z_candidate *build_user_type_conversion_1 (tree, tree, int);
+static struct z_candidate *build_user_type_conversion_1 (tree, tree, int,
+tsubst_flags_t);
static void print_z_candidate (const char *, struct z_candidate *);
static void print_z_candidates (location_t, struct z_candidate *);
static tree build_this (tree);
@@ -1597,7 +1599,8 @@ reference_binding (tree rto, tree rfrom, tree expr
the reference is bound to the lvalue result of the conversion
in the second case. */
- z_candidate *cand = build_user_type_conversion_1 (rto, expr, flags);
+ z_candidate *cand = build_user_type_conversion_1 (rto, expr, flags,
+ tf_warning_or_error);
if (cand)
return cand-second_conv;
}
@@
[Patch, fortran] PR 49010/24518 MOD/MODULO fixes, take 2
Hi, the attached patch implements a few fixes and cleanups for the MOD and MODULO intrinsics. - When the arguments are constant, use mpfr_fmod instead of the naive algorithms which are numerically unstable for large arguments. This extends the PR 24518 fix to constant arguments as well, and makes the compile-time evaluation match the runtime implementation which also uses fmod in the same manner. - Remove the old fallback path for the case builtin_fmod is not available, as the builtin is AFAICS always available. - Specify the behavior wrt. the sign and magnitude of the result, mention this in the documentation. This includes signed zeros which now behave similar to other finite values. I.e. for MOD(A, P) the result has the sign of A and a magnitude less than that of P, and for MODULO(A, P) the result has the sign of P and a magnitude less than that of P. As a (minor?) caveat, at runtime this depends on the implementation of the fmod function in the target C library. But, a fmod that follows C99 Annex F implements this behavior. Regtested on x86_64-unknown-linux-gnu, Ok for trunk? 2012-04-19 Janne Blomqvist j...@gcc.gnu.org PR fortran/49010 PR fortran/24518 * intrinsic.texi (MOD, MODULO): Mention sign and magnitude of result. * simplify.c (gfc_simplify_mod): Use mpfr_fmod. (gfc_simplify_modulo): Likewise, use copysign to fix the result if zero. * trans-intrinsic.c (gfc_conv_intrinsic_mod): Remove fallback as builtin_fmod is always available. For modulo, call copysign to fix the result when signed zeros are enabled. -- Janne Blomqvist mod2.diff Description: Binary data
[Patch, libfortran] Fix handling of temporary files
Hi, the attached patch implements some fixes for handling STATUS=SCRATCH files. - Currently, we check GFORTRAN_TMPDIR, TMP, and TEMP environment variables, but not the POSIX and GNU standard TMPDIR. As specifying a temporary directory depending on the compiler used to create an application doesn't make much sense, the patch just uses the standard TMPDIR (on Windows TMP and TEMP are used, and on MingW/Cygwin those variables are still checked) - The patch tries to create a temporary file in the first possible directory, and tries the next directory in the list if the current one fails, and so on. Document this search logic. - Use the macro P_tmpdir which is available on many systems. - If the program is privileged, we shouldn't trust path style environment variables. The patch fixes this for TMPDIR and also for the logic figuring out where addr2line is. Regtested on x86_64-unknown-linux-gnu, Ok for trunk? gcc/fortran ChangeLog: 2012-04-19 Janne Blomqvist j...@gcc.gnu.org * gfortran.texi (GFORTRAN_TMPDIR): Rename to TMPDIR, explain algorithm for choosing temp directory. libgfortran ChangeLog: 2012-04-19 Janne Blomqvist j...@gcc.gnu.org * config.h.in: Regenerated. * configure: Regenerated. * configure.ac: Add checks for getegid and __secure_getenv. * io/unix.c (P_tmpdir): Fallback definition for macro. (tempfile_open): New function. (tempfile): Use secure_getenv, call tempfile_open to try each directory in turn. * libgfortran.h (DEFAULT_TMPDIR): Remove macro. (secure_getenv): New macro/prototype. * runtime/environ.c (secure_getenv): New function. (variable_table): Rename GFORTRAN_TMPDIR to TMPDIR. * runtime/main.c (find_addr2line): Use secure_getenv. -- Janne Blomqvist tmpdir.diff Description: Binary data
Re: [Patch, libfortran] Fix handling of temporary files
Hi Janne, - If the program is privileged, we shouldn't trust path style environment variables. The patch fixes this for TMPDIR and also for the logic figuring out where addr2line is. I did not test it, but if I remember right, the use of geteuid() and friends does prevent static compilation, resp. static compilation does seem to work, but it needs a matched dynamic library nonetheless, which means if you relocate your statically linked program to another box with differing glibc, you get runtime errors? Or is the use of static programs already broken so it does not matter? If this security feature would prevent use of static programs, it would not be worth it, I think. Cheers, Manfred Regtested on x86_64-unknown-linux-gnu, Ok for trunk? gcc/fortran ChangeLog: 2012-04-19 Janne Blomqvistj...@gcc.gnu.org * gfortran.texi (GFORTRAN_TMPDIR): Rename to TMPDIR, explain algorithm for choosing temp directory. libgfortran ChangeLog: 2012-04-19 Janne Blomqvistj...@gcc.gnu.org * config.h.in: Regenerated. * configure: Regenerated. * configure.ac: Add checks for getegid and __secure_getenv. * io/unix.c (P_tmpdir): Fallback definition for macro. (tempfile_open): New function. (tempfile): Use secure_getenv, call tempfile_open to try each directory in turn. * libgfortran.h (DEFAULT_TMPDIR): Remove macro. (secure_getenv): New macro/prototype. * runtime/environ.c (secure_getenv): New function. (variable_table): Rename GFORTRAN_TMPDIR to TMPDIR. * runtime/main.c (find_addr2line): Use secure_getenv.
Re: Support for Runtime CPU type detection via builtins (issue5754058)
Ping.
On Thu, Apr 12, 2012 at 4:14 PM, Sriraman Tallam tmsri...@google.com wrote:
Ping.
On Tue, Apr 3, 2012 at 12:47 PM, Sriraman Tallam tmsri...@google.com wrote:
Hi,
i386 maintainers - Is this patch ok?
Thanks,
-Sri.
On Mon, Apr 2, 2012 at 5:48 PM, Sriraman Tallam tmsri...@google.com wrote:
On Mon, Apr 2, 2012 at 5:38 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Sat, Mar 31, 2012 at 1:03 AM, Sriraman Tallam tmsri...@google.com
wrote:
On Fri, Mar 30, 2012 at 5:47 AM, Michael Matz m...@suse.de wrote:
Hi,
On Thu, 29 Mar 2012, Sriraman Tallam wrote:
+struct __processor_model
+{
+ /* Vendor. */
+ unsigned int __cpu_is_amd : 1;
+ unsigned int __cpu_is_intel : 1;
+ /* CPU type. */
+ unsigned int __cpu_is_intel_atom : 1;
+ unsigned int __cpu_is_intel_core2 : 1;
+ unsigned int __cpu_is_intel_corei7 : 1;
+ unsigned int __cpu_is_intel_corei7_nehalem : 1;
+ unsigned int __cpu_is_intel_corei7_westmere : 1;
+ unsigned int __cpu_is_intel_corei7_sandybridge : 1;
+ unsigned int __cpu_is_amdfam10h : 1;
+ unsigned int __cpu_is_amdfam10h_barcelona : 1;
+ unsigned int __cpu_is_amdfam10h_shanghai : 1;
+ unsigned int __cpu_is_amdfam10h_istanbul : 1;
+ unsigned int __cpu_is_amdfam15h_bdver1 : 1;
+ unsigned int __cpu_is_amdfam15h_bdver2 : 1;
+} __cpu_model;
It doesn't make sense for the model to be a bitfield, a processor will
have only ever exactly one model. Just make it an enum or even just an
int.
Not entirely true, nehalem and corei7 can be both set. However, I
modified this by dividing it into types and sub types and then did
what you said.
Uh... then I suppose you need to document somewhere what names
match to what cpuid family/model (supposedly thats where your two-layer
hierarchy comes from, which incidentially misses one layer, the vendor?)
Added documentation to extend.texi
Patch available for review here:
http://codereview.appspot.com/5754058
Thanks,
-Sri.
Richard.
* config/i386/i386.c (build_processor_features_struct): New
function.
(build_processor_model_struct): New function.
(make_var_decl): New function.
(get_field_from_struct): New function.
(fold_builtin_target): New function.
(ix86_fold_builtin): New function.
(ix86_expand_builtin): Expand new builtins by folding them.
(make_cpu_type_builtin): New functions.
(ix86_init_platform_type_builtins): Make the new builtins.
(ix86_init_builtins): Make new builtins to detect CPU type.
(TARGET_FOLD_BUILTIN): New macro.
(IX86_BUILTIN_CPU_INIT): New enum value.
(IX86_BUILTIN_CPU_IS): New enum value.
(IX86_BUILTIN_CPU_SUPPORTS): New enum value.
* config/i386/i386-builtin-types.def: New function type.
* testsuite/gcc.target/builtin_target.c: New testcase.
* libgcc/config/i386/i386-cpuinfo.c: New file.
* libgcc/config/i386/t-cpuinfo: New file.
* libgcc/config.host: Include t-cpuinfo.
* libgcc/config/i386/libgcc-glibc.ver: Version symbols __cpu_model
and __cpu_features.
Patch available for review here:
http://codereview.appspot.com/5754058
Thanks,
-Sri.
Ciao,
Michael.
Re: [C++ Patch] PR 52363
On 04/18/2012 09:00 PM, Jason Merrill wrote: On 04/18/2012 01:44 PM, Paolo Carlini wrote: + cand = tourney (candidates, tf_warning_or_error); This seems unlikely to do the right thing; we can get here in both SFINAE and non-SFINAE situations. In build_user_type_conversion_1 I think we can get away with checking LOOKUP_COMPLAIN; ... however, I must admit that I'm not sure to understand what exactly we are risking here, in terms of regressions: I mean, *currently*, if build_user_type_conversion_1 is called in a SFINAE situation, it seems indeed in principle possible that the above call leads to hard errors. With my change, tourney keeps on behaving exactly in the same way, that is - if I didn't make some stupid material mistake somewhere: tourney (candidates) == tourney (candidates, tf_warning_or_error) Thus, it seems to me that with above change it's just that we don't have any hope of fixing latent SFINAE bugs in turney called by build_user_type_conversion_1 per the above. And, at this time, we don't have any evidence of such bugs. That said, if we want to pursue the approach you suggested above (instead of going for adding complain to build_user_type_conversion_1, as I did in my second proposal), we could for example add more to LOOKUP_COMPLAIN, eg. adding LOOKUP_NO_CONVERSION is enough for the testsuite: cand = tourney (candidates, (flags (LOOKUP_COMPLAIN | LOOKUP_NO_CONVERSION)) ? tf_warning_or_error : tf_none); but then, this is something I would personally consider a bit risky, because we could definitely stop producing errors and warnings which we do produce now. Unless we are able to audit all the callers of build_user_type_conversion_1 and make sure we got the latter check right (not so many, just a few in call.c and cvt.c) What do you think? Thanks, Paolo.
Re: [C++ Patch] PR 52363
On 04/18/2012 08:30 PM, Paolo Carlini wrote: Thus, it seems to me that with above change it's just that we don't have any hope of fixing latent SFINAE bugs in turney called by build_user_type_conversion_1 per the above. And, at this time, we don't have any evidence of such bugs. We've just been dealing with SFINAE bugs in tourney; I would expect that they can also occur for conversions using a single-argument constructor. I think you're right that we should just pass complain through build_user_type_conversion_1. Looking at the patch, I think we need to pass it through implicit_conversion and reference_binding as well. Jason
