Re: [PATCH] Fix PR 51389
On 25.01.2012 18:21, Richard Guenther wrote:
2012/1/25 Andrey Belevantsev:
...
Sure, I've just had the impression that the datarefs vector is no use
without the dependencies themselves. The possibility of making
find_data_references_in_loop static also kind of hints in this direction.
Anyways, I don't have any problem with fixing compute_all_dependences
instead.
I'd prefer that.
The below tests fine and passes the test case. compute_all_dependences now
returns bool and has the hunk from compute_data_dependences_for_loop for
creating a single dont-know datadep. The only caller that needs to be
fixed is compute_data_dependences_for_bb, others look fine.
Tree prefetching has its own knob for the same goal,
PREFETCH_MAX_MEM_REFS_PER_LOOP, which is 200. Do we want to remove it, to
change it to the new parameter (might be too big), or to leave it as is?
(Interesting enough, with data deps fixed the most time on the test case is
taken by RTL PRE, 27%.)
Andrey
2012-01-27 Andrey Belevantsev
PR middle-end/51389
* Makefile.in (tree-data-ref.o): Depend on $(PARAMS_H).
* tree-data-ref.h (find_data_references_in_loop): Remove declaration.
* tree-data-ref.c (find_data_references_in_loop): Make static.
(compute_all_dependences): Change return type to bool. Bail out
for too many datarefs in a loop. Move the hunk resetting the data
dependences vector from ...
(compute_data_dependences_for_loop): ... here. Account for
compute_all_dependences returning false.
(compute_data_dependences_for_bb): Likewise.
* params.def (PARAM_LOOP_MAX_DATAREFS_FOR_DATADEPS): New param.
* doc/invoke.texi (loop-max-datarefs-for-datadeps): Document it.
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index f450d3e..43295aa 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -2598,7 +2598,7 @@ tree-scalar-evolution.o : tree-scalar-evolution.c $(CONFIG_H) $(SYSTEM_H) \
$(TREE_PASS_H) $(PARAMS_H) gt-tree-scalar-evolution.h
tree-data-ref.o : tree-data-ref.c $(CONFIG_H) $(SYSTEM_H) coretypes.h \
gimple-pretty-print.h $(TREE_FLOW_H) $(CFGLOOP_H) $(TREE_DATA_REF_H) \
- $(TREE_PASS_H) langhooks.h tree-affine.h
+ $(TREE_PASS_H) langhooks.h tree-affine.h $(PARAMS_H)
sese.o : sese.c sese.h $(CONFIG_H) $(SYSTEM_H) coretypes.h tree-pretty-print.h \
$(TREE_FLOW_H) $(CFGLOOP_H) $(TREE_DATA_REF_H) tree-pass.h value-prof.h
graphite.o : graphite.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(DIAGNOSTIC_CORE_H) \
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index e3d3789..8a916ef 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -9115,6 +9115,13 @@ with more basic blocks than this parameter won't have loop invariant
motion optimization performed on them. The default value of the
parameter is 1000 for -O1 and 1 for -O2 and above.
+@item loop-max-datarefs-for-datadeps
+Building data dapendencies is expensive for very large loops. This
+parameter limits the number of data references in loops that are
+considered for data dependence analysis. These large loops will not
+be handled then by the optimizations using loop data dependencies.
+The default value is 1000.
+
@item max-vartrack-size
Sets a maximum number of hash table slots to use during variable
tracking dataflow analysis of any function. If this limit is exceeded
diff --git a/gcc/params.def b/gcc/params.def
index 239b684..d7cdd7b 100644
--- a/gcc/params.def
+++ b/gcc/params.def
@@ -820,6 +820,12 @@ DEFPARAM (PARAM_GRAPHITE_MAX_BBS_PER_FUNCTION,
"maximum number of basic blocks per function to be analyzed by Graphite",
100, 0, 0)
+/* Avoid data dependence analysis on very large loops. */
+DEFPARAM (PARAM_LOOP_MAX_DATAREFS_FOR_DATADEPS,
+ "loop-max-datarefs-for-datadeps",
+ "Maximum number of datarefs in loop for building loop data dependencies",
+ 1000, 0, 0)
+
/* Avoid doing loop invariant motion on very large loops. */
DEFPARAM (PARAM_LOOP_INVARIANT_MAX_BBS_IN_LOOP,
diff --git a/gcc/tree-data-ref.c b/gcc/tree-data-ref.c
index 09929c7..b8dfa31 100644
--- a/gcc/tree-data-ref.c
+++ b/gcc/tree-data-ref.c
@@ -85,6 +85,7 @@ along with GCC; see the file COPYING3. If not see
#include "tree-pass.h"
#include "langhooks.h"
#include "tree-affine.h"
+#include "params.h"
static struct datadep_stats
{
@@ -4134,9 +4135,10 @@ compute_affine_dependence (struct data_dependence_relation *ddr,
/* Compute in DEPENDENCE_RELATIONS the data dependence graph for all
the data references in DATAREFS, in the LOOP_NEST. When
COMPUTE_SELF_AND_RR is FALSE, don't compute read-read and self
- relations. */
+ relations. Return true when successful, i.e. data references number
+ is small enough to be handled. */
-void
+bool
compute_all_dependences (VEC (data_reference_p, heap) *datarefs,
VEC (ddr_p, heap) **dependence_relations,
VEC (loop_p, heap) *loop_nest,
@@ -4146,6 +4148,18 @@ compute_all_dependence
Re: Fix regression on PR46590 (slow compile with -O0)
> PR tree-optimization/46590 > * cfgexpand.c: Revert last change (r183305). > * gimplify.c (gimplify_bind_expr): Add clobbers for all non-gimple > regs. > * tree-eh.c (cleanup_empty_eh): Try to optimize clobbers before > checking for emptiness. I have installed the Ada stack usage testcase since it passes again (thanks!). But it is only enabled on x86 and x86-64 so, please, consider switching your development platform to these exotic architectures. ;-) -- Eric Botcazou
Re: [PATCH] FIx for PR51990 - ICE in copy_reference_ops_from_ref
On 26/01/12 12:08, Richard Guenther wrote:
> On Thu, Jan 26, 2012 at 10:35 AM, Tom de Vries wrote:
>> Richard,
>>
>> This patch fixes PR51990.
>>
>> The patch adds handling of WITH_SIZE_EXPR in copy_reference_ops_from_ref and
>> create_component_ref_by_pieces_1, preventing ICEs on the test-cases.
>
> The create_component_ref_by_pieces_1 handling is incorrect - you fail
> to properly re-instantiate operand 1 (currop->op0). You should add
> a new case for WITH_SIZE_EXPR and properly handle it via
>
> op0expr = get_or_alloc_expr_for (currop->op0);
> genop0 = find_or_generate_expression (block, op0expr,
> stmts, domstmt);
> if (!genop0)
> return NULL_TREE;
>
I see.
Updated patch, bootstrapped and reg-tested on x86_64.
Ok for stage4 or stage1?
Thanks,
- Tom
> Richard.
>
2012-01-27 Tom de Vries
PR tree-optimization/51990
* tree-ssa-sccvn.c (copy_reference_ops_from_ref): Handle WITH_SIZE_EXPR.
* tree-ssa-pre.c (create_component_ref_by_pieces_1): Same.
* gcc.dg/pr51990.c: New test.
* gcc.dg/pr51990-2.c: Same.
Index: gcc/tree-ssa-sccvn.c
===
--- gcc/tree-ssa-sccvn.c (revision 183325)
+++ gcc/tree-ssa-sccvn.c (working copy)
@@ -624,6 +624,10 @@ copy_reference_ops_from_ref (tree ref, V
switch (temp.opcode)
{
+ case WITH_SIZE_EXPR:
+ temp.op0 = TREE_OPERAND (ref, 1);
+ temp.off = 0;
+ break;
case MEM_REF:
/* The base address gets its own vn_reference_op_s structure. */
temp.op0 = TREE_OPERAND (ref, 1);
@@ -740,6 +744,7 @@ copy_reference_ops_from_ref (tree ref, V
VEC_safe_push (vn_reference_op_s, heap, *result, &temp);
if (REFERENCE_CLASS_P (ref)
+ || TREE_CODE (ref) == WITH_SIZE_EXPR
|| (TREE_CODE (ref) == ADDR_EXPR
&& !is_gimple_min_invariant (ref)))
ref = TREE_OPERAND (ref, 0);
Index: gcc/tree-ssa-pre.c
===
--- gcc/tree-ssa-pre.c (revision 183325)
+++ gcc/tree-ssa-pre.c (working copy)
@@ -2792,6 +2792,23 @@ create_component_ref_by_pieces_1 (basic_
return folded;
}
break;
+case WITH_SIZE_EXPR:
+ {
+ tree genop0 = create_component_ref_by_pieces_1 (block, ref, operand,
+ stmts, domstmt);
+ pre_expr op1expr = get_or_alloc_expr_for (currop->op0);
+ tree genop1;
+
+ if (!genop0)
+ return NULL_TREE;
+
+ genop1 = find_or_generate_expression (block, op1expr, stmts, domstmt);
+ if (!genop1)
+ return NULL_TREE;
+
+ return fold_build2 (currop->opcode, currop->type, genop0, genop1);
+ }
+ break;
case BIT_FIELD_REF:
{
tree folded;
Index: gcc/testsuite/gcc.dg/pr51990.c
===
--- /dev/null (new file)
+++ gcc/testsuite/gcc.dg/pr51990.c (revision 0)
@@ -0,0 +1,23 @@
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+int
+zzz (char *s1, char *s2, int len, int *q)
+{
+ int z = 5;
+ unsigned int i, b;
+ struct s { char a[z]; };
+ struct s x;
+
+ extern int foo (int, ...) __attribute__((pure));
+
+ for (i = 0; i < len; i++)
+s1[i] = s2[i];
+
+ b = z & 0x3;
+
+ len += (b == 0 ? 0 : 1) + z;
+
+ *q = len;
+ return foo (z, x, x);
+}
Index: gcc/testsuite/gcc.dg/pr51990-2.c
===
--- /dev/null (new file)
+++ gcc/testsuite/gcc.dg/pr51990-2.c (revision 0)
@@ -0,0 +1,32 @@
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+int y;
+extern int foo (int, ...) __attribute__((pure));
+
+int
+zzz (char *s1, char *s2, int len, int *q, int c)
+{
+ int z = 5;
+ unsigned int i, b;
+ struct s { char a[z]; };
+ struct s x;
+ int y_tmp = 5;
+
+ for (i = 0; i < len; i++)
+s1[i] = s2[i];
+
+ b = z & 0x3;
+
+ len += (b == 0 ? 0 : 1) + z;
+
+ *q = len;
+
+ if (c)
+ y_tmp = foo (z, x, x) + 4;
+
+ z = foo (z, x, x) + 4;
+ y = y_tmp;
+
+ return z;
+}
[Ada] Small tweak to help GDB to display aliased dynamic array
This isn't a regression, but the patch doesn't change the generated code, just
creates a VAR_DECL for debugging purposes.
Tested on i586-suse-linux, applied on the mainline.
2012-01-27 Eric Botcazou
* gcc-interface/decl.c (gnat_to_gnu_entity) : For an aliased
object with an unconstrained nominal subtype and if optimization isn't
enabled, create a special VAR_DECL for debugging purposes.
--
Eric Botcazou
Index: gcc-interface/decl.c
===
--- gcc-interface/decl.c (revision 183604)
+++ gcc-interface/decl.c (working copy)
@@ -6,7 +6,7 @@
* *
* C Implementation File *
* *
- * Copyright (C) 1992-2011, Free Software Foundation, Inc. *
+ * Copyright (C) 1992-2012, Free Software Foundation, Inc. *
* *
* GNAT is free software; you can redistribute it and/or modify it under *
* terms of the GNU General Public License as published by the Free Soft- *
@@ -889,10 +889,11 @@ gnat_to_gnu_entity (Entity_Id gnat_entit
&& Is_Array_Type (Etype (gnat_entity))
&& !type_annotate_only)
{
- tree gnu_fat
- = TREE_TYPE (gnat_to_gnu_type (Base_Type (Etype (gnat_entity;
+ tree gnu_array
+ = gnat_to_gnu_type (Base_Type (Etype (gnat_entity)));
gnu_type
- = build_unc_object_type_from_ptr (gnu_fat, gnu_type,
+ = build_unc_object_type_from_ptr (TREE_TYPE (gnu_array),
+ gnu_type,
concat_name (gnu_entity_name,
"UNC"),
debug_info_p);
@@ -1468,6 +1469,41 @@ gnat_to_gnu_entity (Entity_Id gnat_entit
}
}
+ /* If this is an aliased object with an unconstrained nominal subtype
+ and optimization isn't enabled, create a VAR_DECL for debugging
+ purposes whose type is a thin reference (the reference counterpart
+ of a thin pointer), so that it will be directly initialized to the
+ address of the array part. */
+ else if (Is_Constr_Subt_For_UN_Aliased (Etype (gnat_entity))
+ && Is_Array_Type (Etype (gnat_entity))
+ && !type_annotate_only
+ && !optimize
+ && debug_info_p)
+ {
+ tree gnu_array
+ = gnat_to_gnu_type (Base_Type (Etype (gnat_entity)));
+ tree gnu_thin_type
+ = build_reference_type (TYPE_OBJECT_RECORD_TYPE (gnu_array));
+ tree gnu_ref, gnu_debug_decl;
+
+ /* In case the object with the template has already been indirectly
+ allocated, we have nothing to do here. */
+ if (TYPE_IS_THIN_POINTER_P (gnu_type))
+ gnu_ref = gnu_decl;
+ else
+ gnu_ref = build_unary_op (ADDR_EXPR, NULL_TREE, gnu_decl);
+ gnu_ref = convert (gnu_thin_type, gnu_ref);
+
+ gnu_debug_decl
+ = create_var_decl (gnu_entity_name, gnu_ext_name,
+ gnu_thin_type, NULL_TREE, const_flag,
+ Is_Public (gnat_entity), !definition,
+ static_p, attr_list, gnat_entity);
+ SET_DECL_VALUE_EXPR (gnu_debug_decl, gnu_ref);
+ DECL_HAS_VALUE_EXPR_P (gnu_debug_decl) = 1;
+ DECL_IGNORED_P (gnu_decl) = 1;
+ }
+
/* If this is a constant and we are defining it or it generates a real
symbol at the object level and we are referencing it, we may want
or need to have a true variable to represent it:
Re: [PATCH] Don't add useless reverse_op vta equivalences (PR debug/52001)
On Thu, Jan 26, 2012 at 10:03 PM, Jakub Jelinek wrote:
> Hi!
>
> When a VALUE contains already some constant location, it will be always
> preferable to expressing it by some other expression - const (or some
> similar reverse operation), so we just should point at adding the
> reverse_op.
>
> This fixes the testcase from the PR on mips64-linux, bootstrapped/regtested
> on x86_64-linux and i686-linux, ok for trunk?
Ok.
Thanks,
Richard.
> 2012-01-26 Jakub Jelinek
>
> PR debug/52001
> * var-tracking.c (reverse_op): Don't add any reverse operation
> if V already has any constant locations.
>
> --- gcc/var-tracking.c.jj 2012-01-23 18:23:45.0 +0100
> +++ gcc/var-tracking.c 2012-01-26 16:37:20.110049563 +0100
> @@ -5298,6 +5298,7 @@ reverse_op (rtx val, const_rtx expr, rtx
> {
> rtx src, arg, ret;
> cselib_val *v;
> + struct elt_loc_list *l;
> enum rtx_code code;
>
> if (GET_CODE (expr) != SET)
> @@ -5333,6 +5334,14 @@ reverse_op (rtx val, const_rtx expr, rtx
> if (!v || !cselib_preserved_value_p (v))
> return;
>
> + /* Adding a reverse op isn't useful if V already has an always valid
> + location. Ignore ENTRY_VALUE, while it is always constant, we should
> + prefer non-ENTRY_VALUE locations whenever possible. */
> + for (l = v->locs; l; l = l->next)
> + if (CONSTANT_P (l->loc)
> + && (GET_CODE (l->loc) != CONST || !references_value_p (l->loc, 0)))
> + return;
> +
> switch (GET_CODE (src))
> {
> case NOT:
>
> Jakub
[PATCH] 2 more testcase fixes for S/390
Hi,
the attached patch fixes 2 more testcases for s390x.
gcc.dg/dfp/fe-convert-2.c: This one is supposed to test libdecnumber
functions. On s390 we have an instruction which does the
conversion performed here what makes the testcase fail with
-march=z9-ec or higher. Fixed by forcing use of software dfp.
testsuite/libgomp.c/atomic-2.c: A long double data type is used here
to test atomic access on 16 byte values. However, long double
on s390x is not necessarily 16 byte aligned but this is an
requirement for the 128 bit compare and swap instruction.
Fixed by forcing the alignment of the variable to 16 byte.
Ok for mainline?
Bye,
-Andreas-
2012-01-27 Andreas Krebbel
* gcc.dg/dfp/fe-convert-2.c: Force use of soft dfp on s390 and
s390x.
* testsuite/libgomp.c/atomic-2.c: Force alignment of the long
double variable.
---
gcc/testsuite/gcc.dg/dfp/fe-convert-2.c |2 ++
libgomp/testsuite/libgomp.c/atomic-2.c |2 !!
2 files changed, 2 insertions(+), 2 modifications(!)
Index: gcc/testsuite/gcc.dg/dfp/fe-convert-2.c
===
*** gcc/testsuite/gcc.dg/dfp/fe-convert-2.c.orig
--- gcc/testsuite/gcc.dg/dfp/fe-convert-2.c
***
*** 1,3
--- 1,5
+ /* { dg-options "-mno-hard-dfp" { target { s390*-*-* } } } */
+
/* Check that appropriate exceptions are raised for BFP to DFP conversions.
The test only uses double and _Decimal32; tests for conversions to
_Decimal64 would need 128-bit long double. */
Index: libgomp/testsuite/libgomp.c/atomic-2.c
===
*** libgomp/testsuite/libgomp.c/atomic-2.c.orig
--- libgomp/testsuite/libgomp.c/atomic-2.c
***
*** 6,12
#endif
double d = 1.5;
! long double ld = 3;
extern void abort (void);
void
--- 6,12
#endif
double d = 1.5;
! long double ld __attribute__ ((aligned (16))) = 3;
extern void abort (void);
void
[Ada] Small tweak to help GDB to display labels
In the same basket as the previous one.
Tested on i586-suse-linux, applied on the mainline.
2012-01-27 Eric Botcazou
* gcc-interface/gigi.h (create_label_decl): Adjust.
* gcc-interface/utils.c (create_label_decl): Add GNAT_NODE parameter
and invoke gnat_pushdecl on it. Remove obsolete settings.
* gcc-interface/decl.c (gnat_to_gnu_entity) : Adjust call to
create_label_decl.
* gcc-interface/trans.c (gnat_to_gnu) Index: gcc-interface/utils.c
===
--- gcc-interface/utils.c (revision 183604)
+++ gcc-interface/utils.c (working copy)
@@ -6,7 +6,7 @@
* *
* C Implementation File *
* *
- * Copyright (C) 1992-2011, Free Software Foundation, Inc. *
+ * Copyright (C) 1992-2012, Free Software Foundation, Inc. *
* *
* GNAT is free software; you can redistribute it and/or modify it under *
* terms of the GNU General Public License as published by the Free Soft- *
@@ -1849,17 +1849,19 @@ potential_alignment_gap (tree prev_field
return true;
}
-/* Return a LABEL_DECL node for LABEL_NAME. */
+/* Return a LABEL_DECL with LABEL_NAME. GNAT_NODE is used for the position
+ of the decl. */
tree
-create_label_decl (tree label_name)
+create_label_decl (tree label_name, Node_Id gnat_node)
{
- tree label_decl = build_decl (input_location,
-LABEL_DECL, label_name, void_type_node);
+ tree label_decl
+= build_decl (input_location, LABEL_DECL, label_name, void_type_node);
- DECL_CONTEXT (label_decl) = current_function_decl;
- DECL_MODE (label_decl)= VOIDmode;
- DECL_SOURCE_LOCATION (label_decl) = input_location;
+ DECL_MODE (label_decl) = VOIDmode;
+
+ /* Add this decl to the current binding level. */
+ gnat_pushdecl (label_decl, gnat_node);
return label_decl;
}
Index: gcc-interface/decl.c
===
--- gcc-interface/decl.c (revision 183605)
+++ gcc-interface/decl.c (working copy)
@@ -4619,7 +4619,7 @@ gnat_to_gnu_entity (Entity_Id gnat_entit
break;
case E_Label:
- gnu_decl = create_label_decl (gnu_entity_name);
+ gnu_decl = create_label_decl (gnu_entity_name, gnat_entity);
break;
case E_Block:
Index: gcc-interface/gigi.h
===
--- gcc-interface/gigi.h (revision 183604)
+++ gcc-interface/gigi.h (working copy)
@@ -672,8 +672,9 @@ extern tree create_field_decl (tree fiel
extern tree create_param_decl (tree param_name, tree param_type,
bool readonly);
-/* Return a LABEL_DECL node for LABEL_NAME. */
-extern tree create_label_decl (tree label_name);
+/* Return a LABEL_DECL with LABEL_NAME. GNAT_NODE is used for the position
+ of the decl. */
+extern tree create_label_decl (tree, Node_Id);
/* Return a FUNCTION_DECL node. SUBPROG_NAME is the name of the subprogram,
ASM_NAME is its assembler name, SUBPROG_TYPE is its type (a FUNCTION_TYPE
Index: gcc-interface/trans.c
===
--- gcc-interface/trans.c (revision 183604)
+++ gcc-interface/trans.c (working copy)
@@ -5881,7 +5881,8 @@ gnat_to_gnu (Node_Id gnat_node)
the next statement that the middle-end knows how to preserve. */
if (!optimize && Comes_From_Source (gnat_node))
{
- tree stmt, label = create_label_decl (NULL_TREE);
+ tree stmt, label = create_label_decl (NULL_TREE, gnat_node);
+ DECL_IGNORED_P (label) = 1;
start_stmt_group ();
stmt = build1 (GOTO_EXPR, void_type_node, label);
set_expr_location_from_node (stmt, gnat_node);
Re: [PATCH] Fix PR 51389
2012/1/27 Andrey Belevantsev : > On 25.01.2012 18:21, Richard Guenther wrote: >> >> 2012/1/25 Andrey Belevantsev: > > ... > >>> Sure, I've just had the impression that the datarefs vector is no use >>> without the dependencies themselves. The possibility of making >>> find_data_references_in_loop static also kind of hints in this direction. >>> Anyways, I don't have any problem with fixing compute_all_dependences >>> instead. >> >> >> I'd prefer that. > > > The below tests fine and passes the test case. compute_all_dependences now > returns bool and has the hunk from compute_data_dependences_for_loop for > creating a single dont-know datadep. The only caller that needs to be fixed > is compute_data_dependences_for_bb, others look fine. > > Tree prefetching has its own knob for the same goal, > PREFETCH_MAX_MEM_REFS_PER_LOOP, which is 200. Do we want to remove it, to > change it to the new parameter (might be too big), or to leave it as is? Just keep it for now as is. Btw, did you check all callers to compute_all_dependences check its return value? At least the array-prefetch and phiopt ones don't AFAICS. Ok for trunk. Thanks, Richard. > (Interesting enough, with data deps fixed the most time on the test case is > taken by RTL PRE, 27%.) > > Andrey > > > 2012-01-27 Andrey Belevantsev > > > PR middle-end/51389 > * Makefile.in (tree-data-ref.o): Depend on $(PARAMS_H). > * tree-data-ref.h (find_data_references_in_loop): Remove declaration. > * tree-data-ref.c (find_data_references_in_loop): Make static. > (compute_all_dependences): Change return type to bool. Bail out > for too many datarefs in a loop. Move the hunk resetting the data > dependences vector from ... > (compute_data_dependences_for_loop): ... here. Account for > compute_all_dependences returning false. > (compute_data_dependences_for_bb): Likewise. > > * params.def (PARAM_LOOP_MAX_DATAREFS_FOR_DATADEPS): New param. > * doc/invoke.texi (loop-max-datarefs-for-datadeps): Document it.
Re: [PATCH] FIx for PR51990 - ICE in copy_reference_ops_from_ref
On Fri, Jan 27, 2012 at 9:44 AM, Tom de Vries wrote: > On 26/01/12 12:08, Richard Guenther wrote: >> On Thu, Jan 26, 2012 at 10:35 AM, Tom de Vries >> wrote: >>> Richard, >>> >>> This patch fixes PR51990. >>> >>> The patch adds handling of WITH_SIZE_EXPR in copy_reference_ops_from_ref and >>> create_component_ref_by_pieces_1, preventing ICEs on the test-cases. >> >> The create_component_ref_by_pieces_1 handling is incorrect - you fail >> to properly re-instantiate operand 1 (currop->op0). You should add >> a new case for WITH_SIZE_EXPR and properly handle it via >> >> op0expr = get_or_alloc_expr_for (currop->op0); >> genop0 = find_or_generate_expression (block, op0expr, >> stmts, domstmt); >> if (!genop0) >> return NULL_TREE; >> > > I see. > > Updated patch, bootstrapped and reg-tested on x86_64. > Ok for stage4 or stage1? Ok for stage4. Thanks, Richard. > Thanks, > - Tom > >> Richard. >> > > > 2012-01-27 Tom de Vries > > PR tree-optimization/51990 > * tree-ssa-sccvn.c (copy_reference_ops_from_ref): Handle > WITH_SIZE_EXPR. > * tree-ssa-pre.c (create_component_ref_by_pieces_1): Same. > > * gcc.dg/pr51990.c: New test. > * gcc.dg/pr51990-2.c: Same.
[Ada] Fix crash on complicated mix of limited with and generics
This isn't a regression either, but the fix shouldn't change the generated
code. It's a crash on code involving a complicated mix of limited with and
generics. As usual with limited with, we have an underlying circularity and
we should break it on the pointer whose designated type is a limited view.
Except that, in this case, this goes through a static dispatch table: the
pointer is a function pointer so the existing mechanism doesn't apply.
As devising a more general mechanism seems overkill to me at this point, I came
up with the attached patch which deals with dispatch tables specially.
Tested on i586-suse-linux, applied on the mainline.
2012-01-27 Eric Botcazou
* gcc-interface/gigi.h (get_minimal_subprog_decl): Declare.
* gcc-interface/decl.c (get_minimal_subprog_decl): New function.
* gcc-interface/trans.c (Attribute_to_gnu): Use it for the prefix of an
Access-like attribute in a dispatch table if the subprogram is public.
2012-01-27 Eric Botcazou
* gnat.dg/limited_with3.ad[sb): New test.
* gnat.dg/limited_with3_pkg1.ad[sb]: New helper.
* gnat.dg/limited_with3_pkg2.ads: Likewise.
* gnat.dg/limited_with3_pkg3.ads: Likewise.
--
Eric Botcazou
Index: gcc-interface/decl.c
===
--- gcc-interface/decl.c (revision 183606)
+++ gcc-interface/decl.c (working copy)
@@ -3769,7 +3769,7 @@ gnat_to_gnu_entity (Entity_Id gnat_entit
break;
}
- /* If we have not done it yet, build the pointer type the usual way. */
+ /* If we haven't done it yet, build the pointer type the usual way. */
if (!gnu_type)
{
/* Modify the designated type if we are pointing only to constant
@@ -5229,6 +5229,42 @@ get_unpadded_type (Entity_Id gnat_entity
return type;
}
+
+/* Return the DECL associated with the public subprogram GNAT_ENTITY but whose
+ type has been changed to that of the parameterless procedure, except if an
+ alias is already present, in which case it is returned instead. */
+
+tree
+get_minimal_subprog_decl (Entity_Id gnat_entity)
+{
+ tree gnu_entity_name, gnu_ext_name;
+ struct attrib *attr_list = NULL;
+
+ /* See the E_Function/E_Procedure case of gnat_to_gnu_entity for the model
+ of the handling applied here. */
+
+ while (Present (Alias (gnat_entity)))
+{
+ gnat_entity = Alias (gnat_entity);
+ if (present_gnu_tree (gnat_entity))
+ return get_gnu_tree (gnat_entity);
+}
+
+ gnu_entity_name = get_entity_name (gnat_entity);
+ gnu_ext_name = create_concat_name (gnat_entity, NULL);
+
+ if (Has_Stdcall_Convention (gnat_entity))
+prepend_one_attribute_to (&attr_list, ATTR_MACHINE_ATTRIBUTE,
+ get_identifier ("stdcall"), NULL_TREE,
+ gnat_entity);
+
+ if (No (Interface_Name (gnat_entity)) && gnu_ext_name == gnu_entity_name)
+gnu_ext_name = NULL_TREE;
+
+ return
+create_subprog_decl (gnu_entity_name, gnu_ext_name, void_ftype, NULL_TREE,
+ false, true, true, true, attr_list, gnat_entity);
+}
/* Wrap up compilation of DECL, a TYPE_DECL, possibly deferring it.
Every TYPE_DECL generated for a type definition must be passed
@@ -5333,6 +5369,7 @@ Gigi_Equivalent_Type (Entity_Id gnat_ent
}
gcc_assert (Present (gnat_equiv) || type_annotate_only);
+
return gnat_equiv;
}
Index: gcc-interface/gigi.h
===
--- gcc-interface/gigi.h (revision 183606)
+++ gcc-interface/gigi.h (working copy)
@@ -6,7 +6,7 @@
* *
* C Header File *
* *
- * Copyright (C) 1992-2011, Free Software Foundation, Inc. *
+ * Copyright (C) 1992-2012, Free Software Foundation, Inc. *
* *
* GNAT is free software; you can redistribute it and/or modify it under *
* terms of the GNU General Public License as published by the Free Soft- *
@@ -118,6 +118,11 @@ extern void mark_out_of_scope (Entity_Id
/* Get the unpadded version of a GNAT type. */
extern tree get_unpadded_type (Entity_Id gnat_entity);
+/* Return the DECL associated with the public subprogram GNAT_ENTITY but whose
+ type has been changed to that of the parameterless procedure, except if an
+ alias is already present, in which case it is returned instead. */
+extern tree get_minimal_subprog_decl (Entity_Id gnat_entity);
+
/* Create a record type that contains a SIZE bytes long field of TYPE with a
starting bit position so that it is aligned to ALIGN bits, and leaving at
least ROOM bytes free before the field. BASE_ALIGN is the alignment the
Index: gcc-interface/trans.c
===
--
Re: [PATCH] Fix PR 51389
On 27.01.2012 13:19, Richard Guenther wrote: 2012/1/27 Andrey Belevantsev: On 25.01.2012 18:21, Richard Guenther wrote: 2012/1/25 Andrey Belevantsev: ... Sure, I've just had the impression that the datarefs vector is no use without the dependencies themselves. The possibility of making find_data_references_in_loop static also kind of hints in this direction. Anyways, I don't have any problem with fixing compute_all_dependences instead. I'd prefer that. The below tests fine and passes the test case. compute_all_dependences now returns bool and has the hunk from compute_data_dependences_for_loop for creating a single dont-know datadep. The only caller that needs to be fixed is compute_data_dependences_for_bb, others look fine. Tree prefetching has its own knob for the same goal, PREFETCH_MAX_MEM_REFS_PER_LOOP, which is 200. Do we want to remove it, to change it to the new parameter (might be too big), or to leave it as is? Just keep it for now as is. Btw, did you check all callers to compute_all_dependences check its return value? At least the array-prefetch and phiopt ones don't AFAICS. These two don't but the following loops handle the situations of chrec_dont_know deps and bail out in this case, so I decided that should be fine. AFAICS, too. Andrey Ok for trunk. Thanks, Richard.
Re: [PATCH] Fix expansion of BLKmode MEM_REF with non-addressable non-BLKmode base decl (PR middle-end/51895)
On Thu, 26 Jan 2012, Richard Guenther wrote:
> On Thu, 26 Jan 2012, Eric Botcazou wrote:
>
> > > Of course get_inner_reference looks through these kind of
> > > conversions when returning the ultimate decl in MEM [&foo],
> > > see the jumps in tree-ssa-alias.c we perform to re-discover
> > > the view-converting cases ... (at some point I realized that
> > > this probably wasn't the best design decision). So maybe
> > > if the passed type isn't used in any other way we can
> > > get around and discover the view-convert and use the alias-type
> > > of the MEM_REF ...
> >
> > But I presume that the regular MEM_REF expander can cope with this case?
>
> Sure.
>
> Btw, we seem to use the TYPE argument solely for the purpose of
> the assign_temp call - and in the forwarding to store_field
> we pass down the very same alias_set which isn't needed,
> we can just use MEM_ALIAS_SET (blk_object) here it seems,
> it's different memory after all, no need to conflict with TARGET
> (or set MEM_KEEP_ALIAS_SET_P - what's that ..., ah, DECL_NONADDRESSABLE
> ...).
>
> Of course if you can simplify the code by using the regular
> expander all the better (and eliminate the TYPE argument?).
>
> @@ -6299,7 +6302,7 @@ store_field (rtx target, HOST_WIDE_INT b
>
>store_field (blk_object, bitsize, bitpos,
>bitregion_start, bitregion_end,
> - mode, exp, type, alias_set, nontemporal);
> + mode, exp, type, MEM_ALIAS_SET (blk_object),
> nontemporal);
>
>emit_move_insn (target, object);
>
>
> works for me.
So I am testing the following - please tell me whether you are working
on a different fix.
Thanks,
Richard.
2012-01-27 Richard Guenther
PR middle-end/51959
* expr.c (store_field): Use the alias-set of the scratch memory
for storing to it.
* g++.dg/torture/pr51959.C: New testcase.
Index: gcc/expr.c
===
--- gcc/expr.c (revision 183606)
+++ gcc/expr.c (working copy)
@@ -6299,7 +6302,7 @@ store_field (rtx target, HOST_WIDE_INT b
store_field (blk_object, bitsize, bitpos,
bitregion_start, bitregion_end,
- mode, exp, type, alias_set, nontemporal);
+ mode, exp, type, MEM_ALIAS_SET (blk_object), nontemporal);
emit_move_insn (target, object);
Index: gcc/testsuite/g++.dg/torture/pr51959.C
===
--- gcc/testsuite/g++.dg/torture/pr51959.C (revision 0)
+++ gcc/testsuite/g++.dg/torture/pr51959.C (revision 0)
@@ -0,0 +1,80 @@
+// { dg-do compile }
+
+namespace std {
+typedef __SIZE_TYPE__ size_t;
+}
+inline void* operator new(std::size_t, void* __p) throw() {
+return __p;
+}
+template class QTypeInfo {
+};
+enum { Q_COMPLEX_TYPE = 0, Q_PRIMITIVE_TYPE = 0x1, Q_STATIC_TYPE = 0,
Q_MOVABLE_TYPE = 0x2, Q_DUMMY_TYPE = 0x4 };
+template class QFlags {
+int i;
+inline QFlags(Enum f) : i(f) { }
+};
+class __attribute__((visibility("default"))) QSize {
+public:
+bool isEmpty() const;
+friend inline bool operator==(const QSize &, const QSize &);
+int wd;
+int ht;
+};
+template<> class QTypeInfo {
+public:
+enum {
+ isComplex = (((Q_MOVABLE_TYPE) & Q_PRIMITIVE_TYPE) == 0), isStatic =
(((Q_MOVABLE_TYPE) & (Q_MOVABLE_TYPE | Q_PRIMITIVE_TYPE)) == 0), isLarge =
(sizeof(QSize)>sizeof(void*)), isPointer = false, isDummy = (((Q_MOVABLE_TYPE)
& Q_DUMMY_TYPE) != 0) };
+};
+class __attribute__((visibility("default"))) QBasicAtomicInt {
+public:
+inline bool operator!=(int value) const { }
+};
+struct __attribute__((visibility("default"))) QListData {
+struct Data {
+ QBasicAtomicInt ref;
+};
+void **append();
+};
+template class QList {
+struct Node {
+ void *v;
+};
+union {
+ QListData p;
+ QListData::Data *d;
+};
+public:
+void append(const T &t);
+inline void push_back(const T &t) {
+ append(t);
+}
+void node_construct(Node *n, const T &t);
+void node_destruct(Node *n);
+};
+template inline void QList::node_construct(Node *n, const T
&t) {
+if (QTypeInfo::isLarge || QTypeInfo::isStatic) n->v = new T(t);
+else if (QTypeInfo::isComplex) new (n) T(t);
+}
+template inline void QList::node_destruct(Node *n) {
+}
+template void QList::append(const T &t) {
+if (d->ref != 1) {
+ try {
+ }
+ catch (...) {
+ }
+ if (QTypeInfo::isLarge || QTypeInfo::isStatic) {
+ }
+ else {
+ Node *n, copy;
+ node_construct(©, t);
+ try { n = reinterpret_cast(p.append());;
}
+ catch (...) { node_destruct(©);
throw; }
+ *n = copy;
+ }
+}
+};
+void virtual_hook(QSize sz, QList &arg)
+{
+ arg.push_back(sz);
+}
[Ada] Fix bug in layout of aliased components
This one has probably been there since day #1: the layout of aliased components
of record types with default discriminants and variant part can be incorrect
in some cases. The aliased components must be placed before the variant part,
otherwise you risk having a dangling pointer. But it is a little special: the
AARM (Annotated Ada Reference Manual) specifically mentions it, so deviating
from it is bit annoying. Moreover the fix is straightforward now.
Tested on i586-suse-linux, applied on the mainline.
2012-01-27 Eric Botcazou
* gcc-interface/ada-tree.h (DECL_ALIASED_P): New flag.
* gcc-interface/decl.c (is_variable_size): Rename to...
(type_has_variable_size): ...this.
(adjust_packed): Adjust to above renaming.
(gnat_to_gnu_field): Set DECL_ALIASED_P on the field.
(field_is_artificial): New predicate.
(field_is_aliased): Likewise.
(field_has_self_size): Likewise.
(field_has_variable_size): Likewise.
(components_to_record): Record information for the final layout during
the first pass on fields.
If there is an aliased field placed after a field whose length depends
on discriminants, put all the fields of the latter sort, last.
2012-01-27 Eric Botcazou
* gnat.dg/discr33.adb: New test.
--
Eric Botcazou
-- { dg-do run }
procedure Discr33 is
subtype Int is Integer range 1..100;
type T (D : Int := 1) is
record
A : Integer;
B : String (1..D);
C : aliased Integer;
end record;
Var : T := (D => 1, A => 1234, B => "x", C => 4567);
type Int_Ref is access all Integer;
Pointer_To_C : Int_Ref := Var.C'Access;
begin
if Pointer_To_C.all /= 4567 then
raise Program_Error;
end if;
Var := (D => 26, A => 1234, B => "abcdefghijklmnopqrstuvwxyz", C => 2345);
if Pointer_To_C.all /= 2345 then
raise Program_Error;
end if;
end Discr33;
Index: gcc-interface/decl.c
===
--- gcc-interface/decl.c (revision 183607)
+++ gcc-interface/decl.c (working copy)
@@ -145,7 +145,7 @@ static void prepend_one_attribute_to (st
enum attr_type, tree, tree, Node_Id);
static void prepend_attributes (Entity_Id, struct attrib **);
static tree elaborate_expression (Node_Id, Entity_Id, tree, bool, bool, bool);
-static bool is_variable_size (tree);
+static bool type_has_variable_size (tree);
static tree elaborate_expression_1 (tree, Entity_Id, tree, bool, bool);
static tree elaborate_expression_2 (tree, Entity_Id, tree, bool, bool,
unsigned int);
@@ -6848,7 +6848,7 @@ adjust_packed (tree field_type, tree rec
because we cannot create temporaries of non-fixed size in case
we need to take the address of the field. See addressable_p and
the notes on the addressability issues for further details. */
- if (is_variable_size (field_type))
+ if (type_has_variable_size (field_type))
return 0;
/* If the alignment of the record is specified and the field type
@@ -7123,6 +7123,7 @@ gnat_to_gnu_field (Entity_Id gnat_field,
= create_field_decl (gnu_field_id, gnu_field_type, gnu_record_type,
gnu_size, gnu_pos, packed, Is_Aliased (gnat_field));
Sloc_to_locus (Sloc (gnat_field), &DECL_SOURCE_LOCATION (gnu_field));
+ DECL_ALIASED_P (gnu_field) = Is_Aliased (gnat_field);
TREE_THIS_VOLATILE (gnu_field) = TREE_SIDE_EFFECTS (gnu_field) = is_volatile;
if (Ekind (gnat_field) == E_Discriminant)
@@ -7136,7 +7137,7 @@ gnat_to_gnu_field (Entity_Id gnat_field,
field of variable size or is a record that has a field such a field. */
static bool
-is_variable_size (tree type)
+type_has_variable_size (tree type)
{
tree field;
@@ -7151,12 +7152,68 @@ is_variable_size (tree type)
return false;
for (field = TYPE_FIELDS (type); field; field = DECL_CHAIN (field))
-if (is_variable_size (TREE_TYPE (field)))
+if (type_has_variable_size (TREE_TYPE (field)))
return true;
return false;
}
+/* Return true if FIELD is an artificial field. */
+
+static bool
+field_is_artificial (tree field)
+{
+ /* These fields are generated by the front-end proper. */
+ if (IDENTIFIER_POINTER (DECL_NAME (field)) [0] == '_')
+return true;
+
+ /* These fields are generated by gigi. */
+ if (DECL_INTERNAL_P (field))
+return true;
+
+ return false;
+}
+
+/* Return true if FIELD is a non-artificial aliased field. */
+
+static bool
+field_is_aliased (tree field)
+{
+ if (field_is_artificial (field))
+return false;
+
+ return DECL_ALIASED_P (field);
+}
+
+/* Return true if FIELD is a non-artificial field with self-referential
+ size. */
+
+static bool
+field_has_self_size (tree field)
+{
+ if (field_is_artificial (field))
+return false;
+
+ if (DECL_SIZE (field) && TREE_CODE (DECL_SIZE (field)) == INTEGER_CST)
+return false;
+
+ return CONTAINS_PLACEHOLDER_P (TYPE_SIZE (TREE_TYPE (field
[Ada] Fix internal error on initialization of object with variant part
This is a regression present on the mainline. The compiler aborts when trying
to generate code to initialize an object with a variant part whose size cannot
be computed statically.
Tested on i586-suse-linux, applied on the mainline.
2012-01-27 Eric Botcazou
* gcc-interface/trans.c (gnat_to_gnu): Avoid making a SAVE_EXPR for
a call to a function that returns an unconstrained type with default
discriminant. Similarly, avoid doing the conversion to the nominal
result type in this case.
2012-01-27 Eric Botcazou
* gnat.dg/discr34.adb: New test.
* gnat.dg/discr34_pkg.ads: New helper.
--
Eric Botcazou
Index: gcc-interface/trans.c
===
--- gcc-interface/trans.c (revision 183607)
+++ gcc-interface/trans.c (working copy)
@@ -6869,10 +6869,14 @@ gnat_to_gnu (Node_Id gnat_node)
N_Raise_Constraint_Error));
}
- /* If our result has side-effects and is of an unconstrained type,
- make a SAVE_EXPR so that we can be sure it will only be referenced
- once. Note we must do this before any conversions. */
+ /* If the result has side-effects and is of an unconstrained type, make a
+ SAVE_EXPR so that we can be sure it will only be referenced once. But
+ this is useless for a call to a function that returns an unconstrained
+ type with default discriminant, as we cannot compute the size of the
+ actual returned object. We must do this before any conversions. */
if (TREE_SIDE_EFFECTS (gnu_result)
+ && !(TREE_CODE (gnu_result) == CALL_EXPR
+ && TYPE_IS_PADDING_P (TREE_TYPE (gnu_result)))
&& (TREE_CODE (gnu_result_type) == UNCONSTRAINED_ARRAY_TYPE
|| CONTAINS_PLACEHOLDER_P (TYPE_SIZE (gnu_result_type
gnu_result = gnat_stabilize_reference (gnu_result, false, NULL);
@@ -6898,7 +6902,11 @@ gnat_to_gnu (Node_Id gnat_node)
3. If the type is void or if we have no result, return error_mark_node
to show we have no result.
- 4. Finally, if the type of the result is already correct. */
+ 4. If this a call to a function that returns an unconstrained type with
+ default discriminant, return the call expression unmodified since we
+ cannot compute the size of the actual returned object.
+
+ 5. Finally, if the type of the result is already correct. */
if (Present (Parent (gnat_node))
&& (lhs_or_actual_p (gnat_node)
@@ -6949,7 +6957,19 @@ gnat_to_gnu (Node_Id gnat_node)
else if (gnu_result == error_mark_node || gnu_result_type == void_type_node)
gnu_result = error_mark_node;
- else if (gnu_result_type != TREE_TYPE (gnu_result))
+ else if (TREE_CODE (gnu_result) == CALL_EXPR
+ && TYPE_IS_PADDING_P (TREE_TYPE (gnu_result))
+ && CONTAINS_PLACEHOLDER_P (TYPE_SIZE (gnu_result_type)))
+{
+ /* ??? We need to convert if the padded type has fixed size because
+ gnat_types_compatible_p will say that padded types are compatible
+ but the gimplifier will not and, therefore, will ultimately choke
+ if there isn't a conversion added early. */
+ if (TREE_CODE (TYPE_SIZE (TREE_TYPE (gnu_result))) == INTEGER_CST)
+ gnu_result = convert (gnu_result_type, gnu_result);
+}
+
+ else if (TREE_TYPE (gnu_result) != gnu_result_type)
gnu_result = convert (gnu_result_type, gnu_result);
/* We don't need any NOP_EXPR or NON_LVALUE_EXPR on the result. */
-- { dg-do compile }
with Discr34_Pkg; use Discr34_Pkg;
procedure Discr34 is
Object : Rec := F;
begin
null;
end;
package Discr34_Pkg is
function N return Natural;
type Enum is (One, Two);
type Rec (D : Enum := One) is record
case D is
when One => S : String (1 .. N);
when Two => null;
end case;
end record;
function F return Rec;
end Discr34_Pkg;
Re: [Ada] improve layout of RETURN type made for CICO mechanism
> 2011-04-08 Eric Botcazou
>
> * gcc-interface/decl.c (gnat_to_gnu_entity) : Set minimum
> alignment on fields of the RETURN type built for the Copy-In Copy-Out
> mechanism.
This can be counter-productive, as the RETURN type is bigger and might not fit
in registers anymore. This is visible on both x86-64 and PowerPC.
Tested on i586-suse-linux, applied on the mainline.
2012-01-27 Eric Botcazou
* gcc-interface/decl.c (gnat_to_gnu_entity) : Do not set
an alignment on fields of the RETURN type built for the CICO mechanism.
--
Eric Botcazou
Index: gcc-interface/decl.c
===
--- gcc-interface/decl.c (revision 183609)
+++ gcc-interface/decl.c (working copy)
@@ -4305,7 +4305,9 @@ gnat_to_gnu_entity (Entity_Id gnat_entit
gnu_return_type = gnu_new_ret_type;
TYPE_NAME (gnu_return_type) = get_identifier ("RETURN");
- /* Set a default alignment to speed up accesses. */
+ /* Set a default alignment to speed up accesses. But we
+ shouldn't increase the size of the structure too much,
+ lest it doesn't fit in return registers anymore. */
TYPE_ALIGN (gnu_return_type)
= get_mode_alignment (ptr_mode);
}
@@ -4314,9 +4316,6 @@ gnat_to_gnu_entity (Entity_Id gnat_entit
= create_field_decl (gnu_param_name, gnu_param_type,
gnu_return_type, NULL_TREE, NULL_TREE,
0, 0);
- /* Set a minimum alignment to speed up accesses. */
- if (DECL_ALIGN (gnu_field) < TYPE_ALIGN (gnu_return_type))
- DECL_ALIGN (gnu_field) = TYPE_ALIGN (gnu_return_type);
Sloc_to_locus (Sloc (gnat_param),
&DECL_SOURCE_LOCATION (gnu_field));
DECL_CHAIN (gnu_field) = gnu_field_list;
Re: [Patch, fortran] PR51870 - [OOP] ICE with ALLOCATE and SOURCE-expr function returning BT_CLASS
Dear All, After discussion off line with Tobias and a bit of tweaking, the patch was committed as revision 183613. 2012-01-27 Paul Thomas Tobias Burnus PR fortran/48705 PR fortran/51870 PR fortran/51943 PR fortran/51946 * trans-array.c (gfc_array_init_size): Add two extra arguments to convey the dynamic element size of a calls object and to return the number of elements that have been allocated. (gfc_array_allocate): Add the same arguments and use them to call gfc_array_init_size. Before the allocation dereference the data pointer, if necessary. Set the allocated array to zero if the class element size or expr3 are non-null. * trans-expr.c (gfc_conv_class_to_class): Give this function global scope. (get_class_array_ref): New function. (gfc_copy_class_to_class): New function. * trans-array.h : Update prototype for gfc_array_allocate. * trans-stmt.c (gfc_trans_allocate): For non-variable class STATUS expressions extract the class object and the dynamic element size. Use the latter to call gfc_array_allocate and the former for setting the vptr and, via gfc_copy_class_to_clasfc_cs, to copy to the allocated data. * trans.h : Prototypes for gfc_get_class_array_ref, gfc_copy_class_to_class and gfc_conv_class_to_class. 2012-01-27 Paul Thomas Tobias Burnus PR fortran/48705 * gfortran.dg/class_allocate_11.f03: New. PR fortran/51870 PR fortran/51943 PR fortran/51946 * gfortran.dg/class_allocate_7.f03: New. * gfortran.dg/class_allocate_8.f03: New. * gfortran.dg/class_allocate_9.f03: New. * gfortran.dg/class_allocate_10.f03: New. Cheers Paul
Re: [PATCH] Fix expansion of BLKmode MEM_REF with non-addressable non-BLKmode base decl (PR middle-end/51895)
> So I am testing the following - please tell me whether you are working > on a different fix. I was, but I realized that this would somewhat conflict with your latest patch to expand_assignment, where all MEM_REFs will go through get_inner_reference instead of the regular expander. Can't we avoid doing this if they have BLKmode? Because you cannot get a BLKmode RTX out of this if the base hasn't BLKmode. We would need to spill, like in the regular expander, so we might as well use it. Otherwise, you're the resident expert in aliasing so, if you think that your patchlet is sufficient, fine with me. -- Eric Botcazou
Re: [PATCH] Fix expansion of BLKmode MEM_REF with non-addressable non-BLKmode base decl (PR middle-end/51895)
On Fri, 27 Jan 2012, Eric Botcazou wrote: > > So I am testing the following - please tell me whether you are working > > on a different fix. > > I was, but I realized that this would somewhat conflict with your latest > patch > to expand_assignment, where all MEM_REFs will go through get_inner_reference > instead of the regular expander. > > Can't we avoid doing this if they have BLKmode? Because you cannot get a > BLKmode RTX out of this if the base hasn't BLKmode. We would need to spill, > like in the regular expander, so we might as well use it. I was simply trying to save some code-duplication here. I will re-work the patch to avoid this as you suggest. Btw, the original reason why we handle MEM_REF at all via the get_inner_reference path is that if we have MEM_REF[&decl, CST] and decl was not committed to memory then the MEM_REF really acts like a bitfield insert to a non-MEM (similar to the rvalue case we handle in expand_expr_real_1). I suppose I should split out some predicates that can be shared amongst the various TARGET_[MEM_REF] handlers during expansion and tighten this one up as well. > Otherwise, you're the resident expert in aliasing so, if you think that your > patchlet is sufficient, fine with me. Yes, I think it is sufficient for this case. Now, let me rework that expand_assignment patch a bit. Richard.
Re: libgo patch committed: Update to weekly.2012-01-20
Ian Lance Taylor writes:
> I have committed a patch to libgo to update to the weekly.2012-01-20
> release. As usual this e-mail message only includes changes to files
> specific to gccgo. Bootstrapped and ran Go testsuite on
> x86_64-unknown-linux-gnu. Committed to mainline.
This patch (or the previous one, I haven't checked in detail) caused a
couple of problems on Solaris:
/vol/gcc/src/hg/trunk/local/libgo/go/syscall/exec_bsd.go:10:9: error: imported
and not used: runtime
Even after fixing all subsequent errors, runtime isn't used.
/vol/gcc/src/hg/trunk/local/libgo/go/syscall/exec_bsd.go:61:10: error:
reference to undefined name 'raw_trace'
// Enable tracing if requested.
if sys.Ptrace {
err1 = raw_trace(_PTRACE_TRACEME, 0, nil, nil)
This needs to be raw_ptrace instead, it seems.
/vol/gcc/src/hg/trunk/local/libgo/go/syscall/exec_bsd.go:156:31: error:
reference to undefined name 'F_CLOEXEC'
raw_fcntl(nextfd, F_SETFD, F_CLOEXEC)
This is rather spelled FD_CLOEXEC.
/vol/gcc/src/hg/trunk/local/libgo/go/syscall/exec_bsd.go:199:26: error:
reference to undefined name 'IOTCNOTTY'
_, err1 = raw_ioctl(0, IOTCNOTTY, 0)
Doesn't exist either, typo for TIOCNOTTY, it seems.
/vol/gcc/src/hg/trunk/local/libgo/go/syscall/exec_bsd.go:207:13: error: not
enough arguments
_, err1 = raw_ioctl(TIOCSCTTY, 0)
Missing 0 arg.
/vol/gcc/src/hg/trunk/local/libgo/go/os/sys_uname.go:11:1: error: redefinition
of 'Hostname'
Need hostname() here
/vol/gcc/src/hg/trunk/local/libgo/go/os/doc.go:15:1: note: previous definition
of 'Hostname' was here
/vol/gcc/src/hg/trunk/local/libgo/go/os/doc.go:16:9: error: reference to
undefined name 'hostname'
After those fixes, libgo builds again on Solaris 10/x86 and 11/SPARC.
On Solaris 8/x86, there's more:
/vol/gcc/src/hg/trunk/local/libgo/runtime/go-print.c: In function '__go_print_do
uble':
/vol/gcc/src/hg/trunk/local/libgo/runtime/go-print.c:61:3: error: implicit decla
ration of function 'isinf' [-Werror=implicit-function-declaration]
cc1: all warnings being treated as errors
There's no isinf in system headers, I've chosen to use __builtin_isinf
instead.
Undefined first referenced
symbol in file
runtime_goenvs
/var/gcc/regression/trunk/10-gcc/build/i386-pc-solaris2.10/libgo/.libs/libgo.so
Currently defined in runtime/thread-linux.c only, need to add to
thread-sema.c, too.
/vol/gcc/src/hg/trunk/local/libgo/go/net/sockoptip_linux.go:95:69: error: refere
nce to undefined identifier 'syscall.IP_PKTINFO'
make[4]: *** [net/net.lo] Error 1
Provide fallback definition via mksysinfo.sh.
With those changes, libgo also builds on Solaris 8/x86 again, but lots
of undefined references to C99 math functions remain, so the result is
pretty useless.
I'm also checking IRIX 6.5 right now.
This patch is what I'm using for Solaris.
Rainer
diff --git a/libgo/go/os/sys_uname.go b/libgo/go/os/sys_uname.go
--- a/libgo/go/os/sys_uname.go
+++ b/libgo/go/os/sys_uname.go
@@ -8,7 +8,7 @@ package os
import "syscall"
-func Hostname() (name string, err error) {
+func hostname() (name string, err error) {
var u syscall.Utsname
if errno := syscall.Uname(&u); errno != nil {
return "", NewSyscallError("uname", errno)
diff --git a/libgo/go/syscall/exec_bsd.go b/libgo/go/syscall/exec_bsd.go
--- a/libgo/go/syscall/exec_bsd.go
+++ b/libgo/go/syscall/exec_bsd.go
@@ -7,7 +7,6 @@
package syscall
import (
- "runtime"
"unsafe"
)
@@ -58,7 +57,7 @@ func forkAndExecInChild(argv0 *byte, arg
// Enable tracing if requested.
if sys.Ptrace {
- err1 = raw_trace(_PTRACE_TRACEME, 0, nil, nil)
+ err1 = raw_ptrace(_PTRACE_TRACEME, 0, nil, nil)
if err1 != 0 {
goto childerror
}
@@ -153,7 +152,7 @@ func forkAndExecInChild(argv0 *byte, arg
err1 = err2.(Errno)
goto childerror
}
- raw_fcntl(nextfd, F_SETFD, F_CLOEXEC)
+ raw_fcntl(nextfd, F_SETFD, FD_CLOEXEC)
fd[i] = nextfd
nextfd++
if nextfd == pipe { // don't stomp on pipe
@@ -196,7 +195,7 @@ func forkAndExecInChild(argv0 *byte, arg
// Detach fd 0 from tty
if sys.Noctty {
- _, err1 = raw_ioctl(0, IOTCNOTTY, 0)
+ _, err1 = raw_ioctl(0, TIOCNOTTY, 0)
if err1 != 0 {
goto childerror
}
@@ -204,7 +203,7 @@ func forkAndExecInChild(argv0 *byte, arg
// Make fd 0 the tty
if sys.Setctty {
- _, err1 = raw_ioctl(TIOCSCTTY, 0)
+ _, err1 = raw_ioctl(0, TIOCSCTTY, 0)
if err1 != 0 {
goto childerror
}
diff --git a/libgo/mksysinfo.sh b/libgo/mksysinfo.sh
--- a/libgo/mksysinfo.sh
+++ b/libgo/mksysinfo.sh
@@ -192,7 +192,7 @@ grep '^const _SHUT_' gen-sysinfo.go |
sed -e 's/^\(const \)_\(SHUT[^= ]*\)\(.*\)$/\1\2 = _\2/' >> ${OUT}
# The net package requires some const definitions.
-for m in IPV6_V6ONLY IPPROTO_IPV6 IPV6_JOIN_GROUP IPV6_LEAVE_GROUP IPV6_TCLASS; do
+for m in IP_PKTINFO IPV6_V6ONLY I
Re: [Patch, Fortran] PR51953 - allow multiple alloc obj. with SOURCE= in allocate
Dear Tobias, This is 'obvious', barring the issue that I mentioned about multiple evaluation of expressions that are not variabbles. That said, I think that this could and should be committed now. OK for trunk. Cheers Paul On Fri, Jan 27, 2012 at 7:57 AM, Tobias Burnus wrote: > That's a Fortran 2008 feature. > > Build and regtested on x86-64-linux. > OK for the trunk? > > Tobias -- The knack of flying is learning how to throw yourself at the ground and miss. --Hitchhikers Guide to the Galaxy
Re: [Patch, Fortran] PR51970/51977 MOVE_ALLOC fixes
OK for trunk. Thanks for the patch Paul On Thu, Jan 26, 2012 at 9:28 PM, Tobias Burnus wrote: > This patch fixes expressions involving polymorphic arrays and, thus, > MOVE_ALLOC. > > I have also two minor fixes (cf. trans-decl.c). > > Build and regtested on x86-64-linux. > OK for the trunk? > > Tobias -- The knack of flying is learning how to throw yourself at the ground and miss. --Hitchhikers Guide to the Galaxy
Re: [Patch, Fortran] Fix elemental diagnostic for polymorphic dummies
This is 'obvious' - OK for trunk. Thanks Paul On Fri, Jan 27, 2012 at 12:52 AM, Tobias Burnus wrote: > Dominique found out that there is no diagnostic for polymorphic arrays. This > patch adds it. > > From the F2008 standard: > > "C1289 All dummy arguments of an elemental procedure shall be scalar > noncoarray dummy data objects and shall not have the POINTER or ALLOCATABLE > attribute." > > "An elemental subroutine has only scalar dummy arguments, but may have array > actual arguments. In a reference to an elemental subroutine, either all > actual arguments shall be scalar, or all actual arguments corresponding to > INTENT (OUT) and INTENT (INOUT) dummy arguments shall be arrays of the same > shape and the remaining actual arguments shall be conformable with them." > > > Build and currently regtesting on x86-64-linux. > OK for the trunk? > > Tobias -- The knack of flying is learning how to throw yourself at the ground and miss. --Hitchhikers Guide to the Galaxy
Re: [PATCH] Fix expansion of BLKmode MEM_REF with non-addressable non-BLKmode base decl (PR middle-end/51895)
On Fri, 27 Jan 2012, Richard Guenther wrote:
> On Fri, 27 Jan 2012, Eric Botcazou wrote:
>
> > > So I am testing the following - please tell me whether you are working
> > > on a different fix.
> >
> > I was, but I realized that this would somewhat conflict with your latest
> > patch
> > to expand_assignment, where all MEM_REFs will go through
> > get_inner_reference
> > instead of the regular expander.
> >
> > Can't we avoid doing this if they have BLKmode? Because you cannot get a
> > BLKmode RTX out of this if the base hasn't BLKmode. We would need to
> > spill,
> > like in the regular expander, so we might as well use it.
>
> I was simply trying to save some code-duplication here. I will
> re-work the patch to avoid this as you suggest. Btw, the original
> reason why we handle MEM_REF at all via the get_inner_reference
> path is that if we have MEM_REF[&decl, CST] and decl was not
> committed to memory then the MEM_REF really acts like a
> bitfield insert to a non-MEM (similar to the rvalue case we
> handle in expand_expr_real_1).
>
> I suppose I should split out some predicates that can be shared
> amongst the various TARGET_[MEM_REF] handlers during expansion
> and tighten this one up as well.
>
> > Otherwise, you're the resident expert in aliasing so, if you think that
> > your
> > patchlet is sufficient, fine with me.
>
> Yes, I think it is sufficient for this case.
>
> Now, let me rework that expand_assignment patch a bit.
Like the following, bootstrapped and tested on x86_64-unknown-linux-gnu.
I'll apply it later unless I hear some objections.
Thanks,
Richard.
2012-01-27 Richard Guenther
PR tree-optimization/50444
* expr.c (mem_ref_refers_to_non_mem_p): New function.
(expand_assignment): Use it. Properly handle misaligned
bases when expanding stores to component references.
(expand_expr_real_1): Use mem_ref_refers_to_non_mem_p and
refactor that case.
Index: gcc/expr.c
===
--- gcc/expr.c (revision 183616)
+++ gcc/expr.c (working copy)
@@ -4548,6 +4548,23 @@ get_bit_range (unsigned HOST_WIDE_INT *b
}
}
+/* Returns true if the MEM_REF REF refers to an object that does not
+ reside in memory and has non-BLKmode. */
+
+static bool
+mem_ref_refers_to_non_mem_p (tree ref)
+{
+ tree base = TREE_OPERAND (ref, 0);
+ if (TREE_CODE (base) != ADDR_EXPR)
+return false;
+ base = TREE_OPERAND (base, 0);
+ return (DECL_P (base)
+ && !TREE_ADDRESSABLE (base)
+ && DECL_MODE (base) != BLKmode
+ && DECL_RTL_SET_P (base)
+ && !MEM_P (DECL_RTL (base)));
+}
+
/* Expand an assignment that stores the value of FROM into TO. If NONTEMPORAL
is true, try generating a nontemporal store. */
@@ -4571,6 +4588,7 @@ expand_assignment (tree to, tree from, b
if (operand_equal_p (to, from, 0))
return;
+ /* Handle misaligned stores. */
mode = TYPE_MODE (TREE_TYPE (to));
if ((TREE_CODE (to) == MEM_REF
|| TREE_CODE (to) == TARGET_MEM_REF)
@@ -4580,6 +4598,8 @@ expand_assignment (tree to, tree from, b
&& ((icode = optab_handler (movmisalign_optab, mode))
!= CODE_FOR_nothing))
{
+ addr_space_t as
+ = TYPE_ADDR_SPACE (TREE_TYPE (TREE_TYPE (TREE_OPERAND (to, 0;
struct expand_operand ops[2];
enum machine_mode address_mode;
rtx reg, op0, mem;
@@ -4589,8 +4609,6 @@ expand_assignment (tree to, tree from, b
if (TREE_CODE (to) == MEM_REF)
{
- addr_space_t as
- = TYPE_ADDR_SPACE (TREE_TYPE (TREE_TYPE (TREE_OPERAND (to, 0;
tree base = TREE_OPERAND (to, 0);
address_mode = targetm.addr_space.address_mode (as);
op0 = expand_expr (base, NULL_RTX, VOIDmode, EXPAND_NORMAL);
@@ -4598,7 +4616,7 @@ expand_assignment (tree to, tree from, b
if (!integer_zerop (TREE_OPERAND (to, 1)))
{
rtx off
- = immed_double_int_const (mem_ref_offset (to), address_mode);
+ = immed_double_int_const (mem_ref_offset (to), address_mode);
op0 = simplify_gen_binary (PLUS, address_mode, op0, off);
}
op0 = memory_address_addr_space (mode, op0, as);
@@ -4608,10 +4626,7 @@ expand_assignment (tree to, tree from, b
}
else if (TREE_CODE (to) == TARGET_MEM_REF)
{
- addr_space_t as
- = TYPE_ADDR_SPACE (TREE_TYPE (TREE_TYPE (TREE_OPERAND (to, 0;
struct mem_address addr;
-
get_address_description (to, &addr);
op0 = addr_for_mem_ref (&addr, as, true);
op0 = memory_address_addr_space (mode, op0, as);
@@ -4627,7 +4642,7 @@ expand_assignment (tree to, tree from, b
create_fixed_operand (&ops[0], mem);
create_input_operand (&ops[1], reg, mode);
/* The movmisalign pattern cannot fail, else the assignment would
- silently be omitted. */
Re: libgo patch committed: Update to weekly.2012-01-20
Rainer Orth writes:
> I'm also checking IRIX 6.5 right now.
IRIX does need one additional change indeed. Without it, I get
/vol/gcc/src/hg/trunk/local/libgo/go/net/sockoptip.go:79:74: error: reference
to undefined identifier 'syscall.IPV6_UNICAST_HOPS'
/vol/gcc/src/hg/trunk/local/libgo/go/net/sockoptip.go:99:74: error: reference
to undefined identifier 'syscall.IPV6_MULTICAST_IF'
/vol/gcc/src/hg/trunk/local/libgo/go/net/sockoptip.go:130:74: error: reference
to undefined identifier 'syscall.IPV6_MULTICAST_HOPS'
/vol/gcc/src/hg/trunk/local/libgo/go/net/sockoptip.go:150:74: error: reference
to undefined identifier 'syscall.IPV6_MULTICAST_LOOP'
Fixed as follows (the comment explains why done this way).
With that patch, I can at least link libgo.so and link a trivial Go
program. Full bootstrap with run over the weekend.
Rainer
diff --git a/libgo/go/syscall/socket_irix.go b/libgo/go/syscall/socket_irix.go
--- a/libgo/go/syscall/socket_irix.go
+++ b/libgo/go/syscall/socket_irix.go
@@ -119,3 +119,12 @@ const (
func anyToSockaddrOS(rsa *RawSockaddrAny) (Sockaddr, error) {
return nil, EAFNOSUPPORT
}
+
+// only provides IPV6_* etc. if _NO_XOPEN4 && _NO_XOPEN5,
+// so as above simply provide them here.
+const (
+ IPV6_UNICAST_HOPS = 48
+ IPV6_MULTICAST_IF = IP_MULTICAST_IF
+ IPV6_MULTICAST_HOPS = IP_MULTICAST_TTL
+ IPV6_MULTICAST_LOOP = IP_MULTICAST_LOOP
+)
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
[C++ PATCH] Destroy/clear local_specializations properly in tsubst_pack_expansion (PR c++/51852)
Hi!
My understanding is that we want to clear local_specializations even when
saved_local_specializations is NULL, if the current function created
the local_specializations htab (otherwise it isn't local, but global).
The problem with that is that it isn't GTY marked and contains TREE_LIST
nodes not references from elsewhere, so the next time we look at the
hashtable we can ICE if they have been GC collected and reused for something
else.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
In the PR there is also a patch to switch local_specializations into
a pointer_map, I think that would be more efficient, but probably 4.8
material, right?
2012-01-27 Jakub Jelinek
PR c++/51852
* pt.c (tsubst_pack_expansion): Delete and restore
local_specialization whenever need_local_specialization, not just
when saved_local_specializations is non-NULL.
* g++.dg/other/gc5.C: New test.
--- gcc/cp/pt.c.jj 2012-01-26 09:22:19.0 +0100
+++ gcc/cp/pt.c 2012-01-27 10:10:38.566458106 +0100
@@ -9582,7 +9582,7 @@ tsubst_pack_expansion (tree t, tree args
}
}
- if (saved_local_specializations)
+ if (need_local_specializations)
{
htab_delete (local_specializations);
local_specializations = saved_local_specializations;
--- gcc/testsuite/g++.dg/other/gc5.C.jj 2012-01-27 11:34:51.722005604 +0100
+++ gcc/testsuite/g++.dg/other/gc5.C2012-01-27 11:33:24.0 +0100
@@ -0,0 +1,27 @@
+// PR c++/51852
+// { dg-do compile }
+// { dg-options "-std=gnu++11 --param ggc-min-heapsize=0 --param
ggc-min-expand=0" }
+
+template
+class transformed {};
+
+template
+transformed transform (R r, F f);
+
+template
+class joined {};
+
+template
+joined join (T t, U u);
+
+template
+auto join (T t, U u, V v, Rest... rest) -> decltype (join (join (t, u), v,
rest...));
+
+template
+auto polymorphic_transform (F f, Rs... rs) -> decltype (join (transform(rs,
f)...));
+
+int
+main ()
+{
+ polymorphic_transform (0, 0, 0);
+}
Jakub
[PATCH] Fix PR51528
This fixes PR51528 by hiding the issue that SRA generates
copy in/out with a type not suitable for preserving the data
(any non-mode-precision thing). It fixes it by instead of
emitting
x$i_8 = x.i;
D.1720 = x;
D.1720.i = x$i_8;
for an assign to an unscalarized D.1720 from a partly scalarized x
(so the aggregate assignment prevails) emit
x.i = x$i_8;
D.1720 = x;
instead. This allows the unfortunate copy in/out to be optimized
away (and thus its undefined behavior).
Basically whenever the aggregate copy will prevail prefer to
restore the RHS and reload the LHS components - just like we
do for aggregate uses/destinations of call statements.
I think we can still clean up the aggregate copy path a lot,
but that's for 4.8 (unless new bugs pop up).
Bootstrap and regtest pending on x86_64-unknown-linux-gnu.
Richard.
2012-01-27 Richard Guenther
PR tree-optimization/51528
* tree-sra.c (sra_modify_assign): Handle the default fallback
for aggregate assigns better.
* gcc.dg/torture/pr51528.c: New testcase.
Index: gcc/tree-sra.c
===
*** gcc/tree-sra.c (revision 183616)
--- gcc/tree-sra.c (working copy)
*** sra_modify_assign (gimple *stmt, gimple_
*** 3060,3104
}
else
{
! if (racc)
{
! if (!racc->grp_to_be_replaced && !racc->grp_unscalarized_data)
{
! if (dump_file)
! {
! fprintf (dump_file, "Removing load: ");
! print_gimple_stmt (dump_file, *stmt, 0, 0);
! }
!
! if (TREE_CODE (lhs) == SSA_NAME)
! {
! rhs = get_repl_default_def_ssa_name (racc);
! if (!useless_type_conversion_p (TREE_TYPE (lhs),
! TREE_TYPE (rhs)))
! rhs = fold_build1_loc (loc, VIEW_CONVERT_EXPR,
! TREE_TYPE (lhs), rhs);
! }
! else
! {
! if (racc->first_child)
! generate_subtree_copies (racc->first_child, lhs,
!racc->offset, 0, 0, gsi,
!false, false, loc);
!
! gcc_assert (*stmt == gsi_stmt (*gsi));
! unlink_stmt_vdef (*stmt);
! gsi_remove (gsi, true);
! sra_stats.deleted++;
! return SRA_AM_REMOVED;
! }
}
- else if (racc->first_child)
- generate_subtree_copies (racc->first_child, lhs, racc->offset,
-0, 0, gsi, false, true, loc);
}
if (access_has_children_p (lacc))
! generate_subtree_copies (lacc->first_child, rhs, lacc->offset,
!0, 0, gsi, true, true, loc);
}
}
--- 3061,3124
}
else
{
! if (racc
! && !racc->grp_to_be_replaced && !racc->grp_unscalarized_data)
{
! if (dump_file)
! {
! fprintf (dump_file, "Removing load: ");
! print_gimple_stmt (dump_file, *stmt, 0, 0);
! }
!
! if (TREE_CODE (lhs) == SSA_NAME)
! {
! rhs = get_repl_default_def_ssa_name (racc);
! if (!useless_type_conversion_p (TREE_TYPE (lhs),
! TREE_TYPE (rhs)))
! rhs = fold_build1_loc (loc, VIEW_CONVERT_EXPR,
! TREE_TYPE (lhs), rhs);
! }
! else
{
! if (racc->first_child)
! generate_subtree_copies (racc->first_child, lhs,
!racc->offset, 0, 0, gsi,
!false, false, loc);
!
! gcc_assert (*stmt == gsi_stmt (*gsi));
! unlink_stmt_vdef (*stmt);
! gsi_remove (gsi, true);
! sra_stats.deleted++;
! return SRA_AM_REMOVED;
}
}
+
+ /* If there is no unscalarized data on the RHS replace
+the aggregate copy by piecewise storing into the LHS. */
+ if (access_has_children_p (racc) && racc->grp_covered)
+ {
+ generate_subtree_copies (racc->first_child, lhs, racc->offset,
+ 0, 0, gsi, false, false, loc);
+ gcc_assert (!access_has_children_p (lacc));
+ gcc_assert (*stmt == gsi_stmt (*gsi));
+ unlink_stmt_vdef (*stmt);
+ gsi_remove (gsi, true);
+
[PATCH] Do not "transform" clobbers in SRA
Quite obvious (just generates dead code) and quite annoys reading SRA dumps. Bootstrapped on x86_64-unknown-linux-gnu, testing in progress. Richard. 2012-01-27 Richard Guenther * tree-sra.c (sra_modify_assign): Do not transform clobbers. Index: gcc/tree-sra.c === --- gcc/tree-sra.c (revision 183616) +++ gcc/tree-sra.c (working copy) @@ -2915,11 +2915,12 @@ sra_modify_assign (gimple *stmt, gimple_ location_t loc; gimple_stmt_iterator orig_gsi = *gsi; - if (!gimple_assign_single_p (*stmt)) + if (!gimple_assign_single_p (*stmt) + || gimple_clobber_p (*stmt)) return SRA_AM_NONE; + lhs = gimple_assign_lhs (*stmt); rhs = gimple_assign_rhs1 (*stmt); - if (TREE_CODE (rhs) == CONSTRUCTOR) return sra_modify_constructor_assign (stmt, gsi);
Re: [Patch, Fortran] Fix elemental diagnostic for polymorphic dummies
On 01/27/2012 01:24 PM, Paul Richard Thomas wrote:
This is 'obvious' - OK for trunk.
Thanks for the review.
I realized that the following chunk was not in the submitted patch. I
have no idea why it got lost, but after committal of the original patch
and update of by devel tree it showed up with "svn diff". That case is
already tested for in the previously committed patch.
Follow up committed as Rev. 183625.
Tobias
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog (revision 183624)
+++ gcc/fortran/ChangeLog (working copy)
@@ -1,5 +1,12 @@
2012-01-27 Tobias Burnus
+ PR fortran/52016
+ * resolve.c (resolve_formal_arglist): Fix elemental
+ constraint checks for polymorphic dummies also for
+ pointers.
+
+2012-01-27 Tobias Burnus
+
PR fortran/51970
PR fortran/51977
* primary.c (gfc_match_varspec. gfc_match_rvalue): Set
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 183624)
+++ gcc/fortran/resolve.c (working copy)
@@ -401,7 +401,9 @@
continue;
}
- if (sym->attr.pointer)
+ if (sym->attr.pointer
+ || (sym->ts.type == BT_CLASS && CLASS_DATA (sym)
+ && CLASS_DATA (sym)->attr.class_pointer))
{
gfc_error ("Argument '%s' of elemental procedure at %L cannot "
"have the POINTER attribute", sym->name,
[PATCH] Fix ipa-pure-const wrt clobbers
Just noticed the following - oddly no testsuite regressions because
of this ...
Richard.
2012-01-27 Richard Guenther
* ipa-pure-const.c (check_stmt): Clobbers do not make a
function non-const/pure.
Index: gcc/ipa-pure-const.c
===
*** gcc/ipa-pure-const.c(revision 183616)
--- gcc/ipa-pure-const.c(working copy)
*** check_stmt (gimple_stmt_iterator *gsip,
*** 652,658
print_gimple_stmt (dump_file, stmt, 0, 0);
}
! if (gimple_has_volatile_ops (stmt))
{
local->pure_const_state = IPA_NEITHER;
if (dump_file)
--- 652,659
print_gimple_stmt (dump_file, stmt, 0, 0);
}
! if (gimple_has_volatile_ops (stmt)
! && !gimple_clobber_p (stmt))
{
local->pure_const_state = IPA_NEITHER;
if (dump_file)
Re: empty directories in go/libgo
Matthias Klose writes:
> two more empty directories:
>
> find gcc-4.7-4.7-20120127/gcc-20120127 -depth -type d -empty -printf
> rmdir %P\n -exec rmdir {} ;
> rmdir libgo/go/exp/template
> rmdir gcc/testsuite/go.test/test/bench/go1/_test
Thanks. Removed from svn.
Ian
Re: [PATCH] Do not "transform" clobbers in SRA
On Fri, 27 Jan 2012, Richard Guenther wrote:
>
> Quite obvious (just generates dead code) and quite annoys reading
> SRA dumps.
>
> Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
This regresses gcc.dg/tree-ssa/ipa-split-5.c, ipa-split is confused
about clobbers on paths where the variable is unused. The following
alternative patch makes SRA remove fully scalarized variables (but
it still won't remove such dead clobbers if there are no other
uses at the time of SRA).
Richard.
2012-01-27 Richard Guenther
* tree-sra.c (sra_modify_assign): Do not transform clobbers.
Index: gcc/tree-sra.c
===
*** gcc/tree-sra.c (revision 183616)
--- gcc/tree-sra.c (working copy)
*** sra_modify_constructor_assign (gimple *s
*** 2817,2822
--- 2817,2836
if (!acc)
return SRA_AM_NONE;
+ if (gimple_clobber_p (*stmt))
+ {
+ /* Remove clobbers of fully scalarized variables, otherwise
+do nothing. */
+ if (acc->grp_covered)
+ {
+ unlink_stmt_vdef (*stmt);
+ gsi_remove (gsi, true);
+ return SRA_AM_REMOVED;
+ }
+ else
+ return SRA_AM_NONE;
+ }
+
loc = gimple_location (*stmt);
if (VEC_length (constructor_elt,
CONSTRUCTOR_ELTS (gimple_assign_rhs1 (*stmt))) > 0)
Re: [PATCH] Fix expansion of BLKmode MEM_REF with non-addressable non-BLKmode base decl (PR middle-end/51895)
On Fri, 27 Jan 2012, Richard Guenther wrote: > On Fri, 27 Jan 2012, Richard Guenther wrote: > > > On Fri, 27 Jan 2012, Eric Botcazou wrote: > > > > > > So I am testing the following - please tell me whether you are working > > > > on a different fix. > > > > > > I was, but I realized that this would somewhat conflict with your latest > > > patch > > > to expand_assignment, where all MEM_REFs will go through > > > get_inner_reference > > > instead of the regular expander. > > > > > > Can't we avoid doing this if they have BLKmode? Because you cannot get a > > > BLKmode RTX out of this if the base hasn't BLKmode. We would need to > > > spill, > > > like in the regular expander, so we might as well use it. > > > > I was simply trying to save some code-duplication here. I will > > re-work the patch to avoid this as you suggest. Btw, the original > > reason why we handle MEM_REF at all via the get_inner_reference > > path is that if we have MEM_REF[&decl, CST] and decl was not > > committed to memory then the MEM_REF really acts like a > > bitfield insert to a non-MEM (similar to the rvalue case we > > handle in expand_expr_real_1). > > > > I suppose I should split out some predicates that can be shared > > amongst the various TARGET_[MEM_REF] handlers during expansion > > and tighten this one up as well. > > > > > Otherwise, you're the resident expert in aliasing so, if you think that > > > your > > > patchlet is sufficient, fine with me. > > > > Yes, I think it is sufficient for this case. > > > > Now, let me rework that expand_assignment patch a bit. > > Like the following, bootstrapped and tested on x86_64-unknown-linux-gnu. > I'll apply it later unless I hear some objections. I have applied this now and the SRA side of the fix for PR50444. As far as I know x86 should be ok with alignment-related issues and SRA now - is there still a bug on strict-alignment platforms we know of (thus, with a testcase)? Otherwise I'd rather delay trying to properly expand misaligned MEM_REFs on non-movmisalign STRICT_ALIGNMENT targets to 4.8. I still want to deal with 51528 though. Thanks, Richard.
PR testsuite/52011: add regparm to LTO/TM tests
The LTO/TM tests are failing with a type mismatch on x86-32 because of
the missing regparm on the prototype.
I have added the regparm, and abstracted things a bit so we don't have
to keep multiple copies. It's bad enough that we have to reproduce this
once...
OK?
testsuite/
PR testsuite/52011
* gcc.dg/lto/trans-mem.h: New file.
* gcc.dg/lto/trans-mem-2_0.c: Include it.
* gcc.dg/lto/trans-mem-1_1.c: Same.
* gcc.dg/lto/trans-mem-4_1.c: Same.
* gcc.dg/lto/trans-mem-3_1.c: Same.
Index: testsuite/gcc.dg/lto/trans-mem-2_0.c
===
--- testsuite/gcc.dg/lto/trans-mem-2_0.c(revision 183537)
+++ testsuite/gcc.dg/lto/trans-mem-2_0.c(working copy)
@@ -2,19 +2,10 @@
/* { dg-lto-do link } */
/* { dg-require-effective-target stdint_types } */
-#include
+#include "trans-mem.h"
extern void foobar() __attribute__((transaction_callable));
-#define noinline __attribute__((noinline,noclone,used))
-
-noinline uint32_t _ITM_beginTransaction(uint32_t a, ...) { asm(""); }
-noinline void _ITM_commitTransaction (void) { asm(""); }
-noinline void _ITM_WU4 (void *a, uint32_t b) { asm(""); }
-noinline void _ITM_WU8 (void *a, uint64_t b) { asm(""); }
-noinline void _ITM_registerTMCloneTable (void) { asm(""); }
-noinline void _ITM_deregisterTMCloneTable (void) { asm(""); }
-
main()
{
__transaction_relaxed
Index: testsuite/gcc.dg/lto/trans-mem-4_1.c
===
--- testsuite/gcc.dg/lto/trans-mem-4_1.c(revision 183537)
+++ testsuite/gcc.dg/lto/trans-mem-4_1.c(working copy)
@@ -1,14 +1,6 @@
-#include
+#include "trans-mem.h"
__attribute__((transaction_safe))
void foo()
{
}
-
-uint32_t _ITM_beginTransaction(uint32_t prop, ...)
-{
-}
-
-void __builtin__ITM_commitTransaction (void)
-{
-}
Index: testsuite/gcc.dg/lto/trans-mem.h
===
--- testsuite/gcc.dg/lto/trans-mem.h(revision 0)
+++ testsuite/gcc.dg/lto/trans-mem.h(revision 0)
@@ -0,0 +1,22 @@
+#include
+
+/* Dummy declarations for common TM supporting functions. */
+
+/* These must be in sync with both libitm/libitm.h and the TM builtin
+ definitions in gcc/gtm-builtins.def. */
+
+#define noinline __attribute__((noinline,noclone,used))
+
+#ifdef __i386__
+/* Only for 32-bit x86. */
+# define ITM_REGPARM __attribute__((regparm(2)))
+#else
+# define ITM_REGPARM
+#endif
+
+ITM_REGPARM noinline uint32_t _ITM_beginTransaction(uint32_t a, ...) {
asm(""); }
+ITM_REGPARM noinline void _ITM_commitTransaction (void) { asm(""); }
+ITM_REGPARM noinline void _ITM_WU4 (void *a, uint32_t b) { asm(""); }
+ITM_REGPARM noinline void _ITM_WU8 (void *a, uint64_t b) { asm(""); }
+noinline void _ITM_registerTMCloneTable (void) { asm(""); }
+noinline void _ITM_deregisterTMCloneTable (void) { asm(""); }
Index: testsuite/gcc.dg/lto/trans-mem-1_1.c
===
--- testsuite/gcc.dg/lto/trans-mem-1_1.c(revision 183537)
+++ testsuite/gcc.dg/lto/trans-mem-1_1.c(working copy)
@@ -1,10 +1 @@
-#include
-
-#define noinline __attribute__((noinline,noclone,used))
-
-noinline uint32_t _ITM_beginTransaction(uint32_t a, ...) { asm(""); }
-noinline void _ITM_commitTransaction (void) { asm(""); }
-noinline void _ITM_WU4 (void *a, uint32_t b) { asm(""); }
-noinline void _ITM_WU8 (void *a, uint64_t b) { asm(""); }
-noinline void _ITM_registerTMCloneTable (void) { asm(""); }
-noinline void _ITM_deregisterTMCloneTable (void) { asm(""); }
+#include "trans-mem.h"
Index: testsuite/gcc.dg/lto/trans-mem-3_1.c
===
--- testsuite/gcc.dg/lto/trans-mem-3_1.c(revision 183537)
+++ testsuite/gcc.dg/lto/trans-mem-3_1.c(working copy)
@@ -1,6 +1,6 @@
/* { dg-options "-fgnu-tm" } */
-#include
+#include "trans-mem.h"
extern int i;
@@ -8,12 +8,3 @@ main()
{
__transaction_atomic { i = 0; }
}
-
-#define noinline __attribute__((noinline,noclone,used))
-
-noinline uint32_t _ITM_beginTransaction(uint32_t a, ...) { asm(""); }
-noinline void _ITM_commitTransaction (void) { asm(""); }
-noinline void _ITM_WU4 (void *a, uint32_t b) { asm(""); }
-noinline void _ITM_WU8 (void *a, uint64_t b) { asm(""); }
-noinline void _ITM_registerTMCloneTable (void) { asm(""); }
-noinline void _ITM_deregisterTMCloneTable (void) { asm(""); }
Re: [v3] Update Solaris baselines for GCC 4.7
Rainer Orth writes: > Just as for the GCC 4.6 release, I plan to update the Solaris baselines > before 4.7.0 ships. The following untested patch (simply created with > make new-abi-baseline) would do so, but I don't propose installing it > yet for several reasons: > > * I'd like the baselines to be identical to the release, and there may > well be more changes between now and then. > > * I already noticed several errors that need to be fixed for the > release. > > * For the first time, there are differences between the baselines with > Sun as (which doesn't support TLS before Solaris 10) and GNU as (which > does), so we get different libstdc++.so interfaces depending on the > toolset used. Unfortunately, I haven't seen any response to this patch and the issues raised in a week. Anyone? Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: PR testsuite/52011: add regparm to LTO/TM tests
On 01/27/2012 10:14 AM, Aldy Hernandez wrote:
+ITM_REGPARM noinline uint32_t _ITM_beginTransaction(uint32_t a, ...) {
asm(""); }
No ITM_REGPARM here. It should be also removed from libitm.h.
--
Patrick.
Re: PR testsuite/52011: add regparm to LTO/TM tests
On 01/27/12 10:00, Patrick Marlier wrote:
On 01/27/2012 10:14 AM, Aldy Hernandez wrote:
+ITM_REGPARM noinline uint32_t _ITM_beginTransaction(uint32_t a, ...)
{ asm(""); }
No ITM_REGPARM here. It should be also removed from libitm.h.
--
Patrick.
I'm ok either way. I'm just trying to get 32-bits to pass the tests.
If you all agree to remove ITM_REGPARM from libitm.h, then the tests on
x86-32 will work. What is the status of this-- was there agreement on
removing regparm?
Re: [v3] Update Solaris baselines for GCC 4.7
On 01/23/2012 07:31 PM, Rainer Orth wrote: * I noticed several new symbols being placed into GLIBCXX_3.4.5, which also happens with gld and thus isn't an issue with Sun ld versioning support. Adding to an old version is not supposed to happen and must be fixed. +FUNC:_ZNSt19istreambuf_iteratorIcSt11char_traitsIcEEppEv@@GLIBCXX_3.4.5 +FUNC:_ZNSt19istreambuf_iteratorIwSt11char_traitsIwEEppEv@@GLIBCXX_3.4.5 I don't think this is a new issue, I see it in 4.6 branch and even in 4.5 branch. At some point we had a problem which Jakub patched (thus the *XX variants), the actual story is longish but is not new, I'm not sure you are interested in thegory details. * There's quite a number of additions to 3.4.11: +FUNC:_ZNKSt10lock_error4whatEv@@GLIBCXX_3.4.11 +FUNC:_ZNSt18condition_variable10notify_allEv@@GLIBCXX_3.4.11 +FUNC:_ZNSt18condition_variable10notify_oneEv@@GLIBCXX_3.4.11 +FUNC:_ZNSt18condition_variable4waitERSt11unique_lockISt5mutexE@@GLIBCXX_3.4.11 +FUNC:_ZNSt18condition_variableC1Ev@@GLIBCXX_3.4.11 +FUNC:_ZNSt18condition_variableC2Ev@@GLIBCXX_3.4.11 +FUNC:_ZNSt18condition_variableD1Ev@@GLIBCXX_3.4.11 +FUNC:_ZNSt18condition_variableD2Ev@@GLIBCXX_3.4.11 +FUNC:_ZNSt22condition_variable_anyC1Ev@@GLIBCXX_3.4.11 +FUNC:_ZNSt22condition_variable_anyC2Ev@@GLIBCXX_3.4.11 +FUNC:_ZNSt22condition_variable_anyD1Ev@@GLIBCXX_3.4.11 +FUNC:_ZNSt22condition_variable_anyD2Ev@@GLIBCXX_3.4.11 +FUNC:_ZNSt6thread15_M_start_threadESt10shared_ptrINS_10_Impl_baseEE@@GLIBCXX_3.4.11 +FUNC:_ZNSt6thread4joinEv@@GLIBCXX_3.4.11 +FUNC:_ZNSt6thread6detachEv@@GLIBCXX_3.4.11 +FUNC:__once_proxy@@GLIBCXX_3.4.11 +OBJECT:12:_ZTISt10lock_error@@GLIBCXX_3.4.11 +OBJECT:15:_ZTSSt10lock_error@@GLIBCXX_3.4.11 +OBJECT:20:_ZTVSt10lock_error@@GLIBCXX_3.4.11 +OBJECT:24:_ZTISt10lock_error@@GLIBCXX_3.4.11 +OBJECT:40:_ZTVSt10lock_error@@GLIBCXX_3.4.11 This, I don't see why you considered it some sort of "problem"?!? Yes we started exporting some additional symbols, in 3.4.11, I can confirm that. Paolo.
[PATCH][ARM] Improve 64-bit shifts (non-NEON)
Hi all,
This patch introduces a new, more efficient set of DImode shift
sequences for values stored in core-registers (as opposed to VFP/NEON
registers).
The new sequences take advantage of knowledge of what the ARM
instructions do with out-of-range shift amounts.
The following are examples or a simple test case, like this one:
long long
f (long long *a, int b)
{
return *a << b;
}
In ARM mode, old left-shift vs. the new one:
stmfd sp!, {r4, r5}| ldrdr2, [r0]
rsb r4, r1, #32 | mov ip, r1
ldr r5, [r0, #4] | stmfd sp!, {r4, r5}
subsip, r1, #32 | sub r5, ip, #32
ldr r0, [r0, #0] | rsb r4, ip, #32
mov r3, r5, asl r1 | mov r1, r3, asl ip
orr r3, r3, r0, lsr r4 | mov r0, r2, asl ip
mov r2, r0, asl r1 | orr r1, r1, r2, asl r5
movpl r3, r0, asl ip | orr r1, r1, r2, lsr r4
mov r0, r2 | ldmfd sp!, {r4, r5}
mov r1, r3 | bx lr
ldmfd sp!, {r4, r5}|
bx lr |
In Thumb mode, old left-shift vs. new:
ldr r2, [r0, #0] | ldrdr2, [r0]
ldr r3, [r0, #4] | push{r4, r5, r6}
push{r4, r5, r6} | sub r6, r1, #32
rsb r6, r1, #32 | mov r4, r1
sub r4, r1, #32 | rsb r5, r1, #32
lslsr3, r3, r1 | lslsr6, r2, r6
lsrsr6, r2, r6 | lslsr1, r3, r1
lslsr5, r2, r4 | lsrsr5, r2, r5
orrsr3, r3, r6 | lslsr0, r2, r4
lslsr0, r2, r1 | orrsr1, r1, r6
bicsr1, r5, r4, asr #32 | orrsr1, r1, r5
it cs | pop {r4, r5, r6}
movcs r1, r3 | bx lr
pop {r4, r5, r6} |
bx lr |
Logical right shift is essentially the same sequence as the left shift
above. However, arithmetic right shift requires something slightly
different. Here it is in ARM mode, old vs. new:
stmfd sp!, {r4, r5}| ldrdr2, [r0]
rsb r4, r1, #32 | mov ip, r1
ldr r5, [r0, #0] | stmfd sp!, {r4, r5}
subsip, r1, #32 | rsb r5, ip, #32
ldr r0, [r0, #4] | subsr4, ip, #32
mov r2, r5, lsr r1 | mov r0, r2, lsr ip
orr r2, r2, r0, asl r4 | mov r1, r3, asr ip
mov r3, r0, asr r1 | orr r0, r0, r3, asl r5
movpl r2, r0, asr ip | orrge r0, r0, r3, asr r4
mov r1, r3 | ldmfd sp!, {r4, r5}
mov r0, r2 | bx lr
ldmfd sp!, {r4, r5}|
bx lr |
I won't bore you with the Thumb mode comparison.
The shift-by-constant cases have also been reimplemented, although the
resultant sequences are much the same as before. (Doing this isn't
strictly necessary just yet, but when I post my next patch to do 64-bit
shifts in NEON, this feature will be required by the fall-back
alternatives.)
I've run a regression test on a cross-compiler, and I should have native
test results next week sometime. Also some benchmark results.
Is this OK for stage 1?
Andrew
2012-01-27 Andrew Stubbs
* config/arm/arm-protos.h (arm_emit_coreregs_64bit_shift): New
prototype.
* config/arm/arm.c (arm_emit_coreregs_64bit_shift): New function.
* config/arm/arm.md (ashldi3): Use arm_emit_coreregs_64bit_shift.
(ashrdi3,lshrdi3): Likewise.
---
gcc/config/arm/arm-protos.h |3 +
gcc/config/arm/arm.c| 198 +++
gcc/config/arm/arm.md | 90 ++--
3 files changed, 264 insertions(+), 27 deletions(-)
diff --git a/gcc/config/arm/arm-protos.h b/gcc/config/arm/arm-protos.h
index 296550a..df8d7a9 100644
--- a/gcc/config/arm/arm-protos.h
+++ b/gcc/config/arm/arm-protos.h
@@ -242,6 +242,9 @@ struct tune_params
extern const struct tune_params *current_tune;
extern int vfp3_const_double_for_fract_bits (rtx);
+
+extern void arm_emit_coreregs_64bit_shift (enum rtx_code, rtx, rtx, rtx, rtx,
+ rtx);
#endif /* RTX_CODE */
#endif /* ! GCC_ARM_PROTOS_H */
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 0bded8d..eefc45c 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -25139,5 +25139,203 @@ vfp3_const_double_for_fract_bits (rtx operand)
return 0;
}
+/* The default expansion of general 64-bit shifts in core-regs is suboptimal
+ on ARM, since we know that shifts by negative amounts are no-ops.
+
+ It's safe for the input and output to be the same register, but
+ early-clobber rules apply for the shift amount and scratch registers.
+
+ Shift by register requires both scratch registers. Shift by a constant
+ less than 32 in Thumb2 mode requires SCRATCH1 only. In all other cases
+ the scratch registers may be NU
Re: PR testsuite/52011: add regparm to LTO/TM tests
On 01/27/2012 11:02 AM, Aldy Hernandez wrote: If you all agree to remove ITM_REGPARM from libitm.h, then the tests on x86-32 will work. What is the status of this-- was there agreement on removing regparm? Note that I meant only for _ITM_beginTransaction. Indeed, regparm is ignored with variadic functions. See discussion here: http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00933.html http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00924.html Patrick.
Re: [v3] Update Solaris baselines for GCC 4.7
Paolo Carlini writes: > On 01/23/2012 07:31 PM, Rainer Orth wrote: >> * I noticed several new symbols being placed into GLIBCXX_3.4.5, which >>also happens with gld and thus isn't an issue with Sun ld versioning >>support. Adding to an old version is not supposed to happen and must >>be fixed. >> >> +FUNC:_ZNSt19istreambuf_iteratorIcSt11char_traitsIcEEppEv@@GLIBCXX_3.4.5 >> +FUNC:_ZNSt19istreambuf_iteratorIwSt11char_traitsIwEEppEv@@GLIBCXX_3.4.5 > I don't think this is a new issue, I see it in 4.6 branch and even in 4.5 > branch. At some point we had a problem which Jakub patched (thus the *XX > variants), the actual story is longish but is not new, I'm not sure you are > interested in thegory details. Perhaps you have a pointer? >> * There's quite a number of additions to 3.4.11: >> >> +FUNC:_ZNKSt10lock_error4whatEv@@GLIBCXX_3.4.11 >> +FUNC:_ZNSt18condition_variable10notify_allEv@@GLIBCXX_3.4.11 >> +FUNC:_ZNSt18condition_variable10notify_oneEv@@GLIBCXX_3.4.11 >> +FUNC:_ZNSt18condition_variable4waitERSt11unique_lockISt5mutexE@@GLIBCXX_3.4.11 >> +FUNC:_ZNSt18condition_variableC1Ev@@GLIBCXX_3.4.11 >> +FUNC:_ZNSt18condition_variableC2Ev@@GLIBCXX_3.4.11 >> +FUNC:_ZNSt18condition_variableD1Ev@@GLIBCXX_3.4.11 >> +FUNC:_ZNSt18condition_variableD2Ev@@GLIBCXX_3.4.11 >> +FUNC:_ZNSt22condition_variable_anyC1Ev@@GLIBCXX_3.4.11 >> +FUNC:_ZNSt22condition_variable_anyC2Ev@@GLIBCXX_3.4.11 >> +FUNC:_ZNSt22condition_variable_anyD1Ev@@GLIBCXX_3.4.11 >> +FUNC:_ZNSt22condition_variable_anyD2Ev@@GLIBCXX_3.4.11 >> +FUNC:_ZNSt6thread15_M_start_threadESt10shared_ptrINS_10_Impl_baseEE@@GLIBCXX_3.4.11 >> +FUNC:_ZNSt6thread4joinEv@@GLIBCXX_3.4.11 >> +FUNC:_ZNSt6thread6detachEv@@GLIBCXX_3.4.11 >> +FUNC:__once_proxy@@GLIBCXX_3.4.11 >> +OBJECT:12:_ZTISt10lock_error@@GLIBCXX_3.4.11 >> +OBJECT:15:_ZTSSt10lock_error@@GLIBCXX_3.4.11 >> +OBJECT:20:_ZTVSt10lock_error@@GLIBCXX_3.4.11 >> +OBJECT:24:_ZTISt10lock_error@@GLIBCXX_3.4.11 >> +OBJECT:40:_ZTVSt10lock_error@@GLIBCXX_3.4.11 > This, I don't see why you considered it some sort of "problem"?!? Yes we > started exporting some additional symbols, in 3.4.11, I can confirm that. Adding new symbols to an old version is fundamentally wrong IMO: consider you have some libstdc++.so from some older gcc release that includes anything up to GLIBCXX_3.4.11. Now you compile and link some new executable with g++ 4.7.0 and the new libstdc++.so which contains those new symbols in GLIBCXX_3.4.11. That executable only uses symbols from that version, including some of those added after GLIBCXX_3.4.11 originally shipped, nothing newer. When you try to run it on the older system, ld.so.1 detects that the libstdc++.so there provides all versions required by the executable, concludes that it is safe to run it, starts it, and later there's a reference to those new symbols which of course aren't present: crash/bang! This is exactly what symbol versioning is supposed to avoid. It is intended to allow the runtime linker to detect up front if it is safe to run an executable because its dependencies are present. Old versions *must* be frozen once they have been released, otherwise this whole symbol versioning stuff is moot. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [v3] Update Solaris baselines for GCC 4.7
On 01/27/2012 05:18 PM, Rainer Orth wrote: Paolo Carlini writes: On 01/23/2012 07:31 PM, Rainer Orth wrote: * I noticed several new symbols being placed into GLIBCXX_3.4.5, which also happens with gld and thus isn't an issue with Sun ld versioning support. Adding to an old version is not supposed to happen and must be fixed. +FUNC:_ZNSt19istreambuf_iteratorIcSt11char_traitsIcEEppEv@@GLIBCXX_3.4.5 +FUNC:_ZNSt19istreambuf_iteratorIwSt11char_traitsIwEEppEv@@GLIBCXX_3.4.5 I don't think this is a new issue, I see it in 4.6 branch and even in 4.5 branch. At some point we had a problem which Jakub patched (thus the *XX variants), the actual story is longish but is not new, I'm not sure you are interested in thegory details. Perhaps you have a pointer? I can search, but really the issue is very, very old and we already released *many* GCCs "affected". * There's quite a number of additions to 3.4.11: +FUNC:_ZNKSt10lock_error4whatEv@@GLIBCXX_3.4.11 +FUNC:_ZNSt18condition_variable10notify_allEv@@GLIBCXX_3.4.11 +FUNC:_ZNSt18condition_variable10notify_oneEv@@GLIBCXX_3.4.11 +FUNC:_ZNSt18condition_variable4waitERSt11unique_lockISt5mutexE@@GLIBCXX_3.4.11 +FUNC:_ZNSt18condition_variableC1Ev@@GLIBCXX_3.4.11 +FUNC:_ZNSt18condition_variableC2Ev@@GLIBCXX_3.4.11 +FUNC:_ZNSt18condition_variableD1Ev@@GLIBCXX_3.4.11 +FUNC:_ZNSt18condition_variableD2Ev@@GLIBCXX_3.4.11 +FUNC:_ZNSt22condition_variable_anyC1Ev@@GLIBCXX_3.4.11 +FUNC:_ZNSt22condition_variable_anyC2Ev@@GLIBCXX_3.4.11 +FUNC:_ZNSt22condition_variable_anyD1Ev@@GLIBCXX_3.4.11 +FUNC:_ZNSt22condition_variable_anyD2Ev@@GLIBCXX_3.4.11 +FUNC:_ZNSt6thread15_M_start_threadESt10shared_ptrINS_10_Impl_baseEE@@GLIBCXX_3.4.11 +FUNC:_ZNSt6thread4joinEv@@GLIBCXX_3.4.11 +FUNC:_ZNSt6thread6detachEv@@GLIBCXX_3.4.11 +FUNC:__once_proxy@@GLIBCXX_3.4.11 +OBJECT:12:_ZTISt10lock_error@@GLIBCXX_3.4.11 +OBJECT:15:_ZTSSt10lock_error@@GLIBCXX_3.4.11 +OBJECT:20:_ZTVSt10lock_error@@GLIBCXX_3.4.11 +OBJECT:24:_ZTISt10lock_error@@GLIBCXX_3.4.11 +OBJECT:40:_ZTVSt10lock_error@@GLIBCXX_3.4.11 This, I don't see why you considered it some sort of "problem"?!? Yes we started exporting some additional symbols, in 3.4.11, I can confirm that. Adding new symbols to an old version is fundamentally wrong IMO: Totally agreed, but who did that? Those symbols are exported @3.4.11. I still don't understand. Paolo.
Re: [v3] Update Solaris baselines for GCC 4.7
Paolo Carlini writes: +FUNC:_ZNSt19istreambuf_iteratorIcSt11char_traitsIcEEppEv@@GLIBCXX_3.4.5 +FUNC:_ZNSt19istreambuf_iteratorIwSt11char_traitsIwEEppEv@@GLIBCXX_3.4.5 >>> I don't think this is a new issue, I see it in 4.6 branch and even in 4.5 >>> branch. At some point we had a problem which Jakub patched (thus the *XX >>> variants), the actual story is longish but is not new, I'm not sure you are >>> interested in thegory details. >> Perhaps you have a pointer? > I can search, but really the issue is very, very old and we already > released *many* GCCs "affected". For the case at hand, I doubt that: those are additions between the gcc 4.6.0 and 4.7.0 Solaris baselines. They have not been present in Solaris libstdc++.so on 4.6. * There's quite a number of additions to 3.4.11: +FUNC:_ZNKSt10lock_error4whatEv@@GLIBCXX_3.4.11 +FUNC:_ZNSt18condition_variable10notify_allEv@@GLIBCXX_3.4.11 +FUNC:_ZNSt18condition_variable10notify_oneEv@@GLIBCXX_3.4.11 +FUNC:_ZNSt18condition_variable4waitERSt11unique_lockISt5mutexE@@GLIBCXX_3.4.11 +FUNC:_ZNSt18condition_variableC1Ev@@GLIBCXX_3.4.11 +FUNC:_ZNSt18condition_variableC2Ev@@GLIBCXX_3.4.11 +FUNC:_ZNSt18condition_variableD1Ev@@GLIBCXX_3.4.11 +FUNC:_ZNSt18condition_variableD2Ev@@GLIBCXX_3.4.11 +FUNC:_ZNSt22condition_variable_anyC1Ev@@GLIBCXX_3.4.11 +FUNC:_ZNSt22condition_variable_anyC2Ev@@GLIBCXX_3.4.11 +FUNC:_ZNSt22condition_variable_anyD1Ev@@GLIBCXX_3.4.11 +FUNC:_ZNSt22condition_variable_anyD2Ev@@GLIBCXX_3.4.11 +FUNC:_ZNSt6thread15_M_start_threadESt10shared_ptrINS_10_Impl_baseEE@@GLIBCXX_3.4.11 +FUNC:_ZNSt6thread4joinEv@@GLIBCXX_3.4.11 +FUNC:_ZNSt6thread6detachEv@@GLIBCXX_3.4.11 +FUNC:__once_proxy@@GLIBCXX_3.4.11 +OBJECT:12:_ZTISt10lock_error@@GLIBCXX_3.4.11 +OBJECT:15:_ZTSSt10lock_error@@GLIBCXX_3.4.11 +OBJECT:20:_ZTVSt10lock_error@@GLIBCXX_3.4.11 +OBJECT:24:_ZTISt10lock_error@@GLIBCXX_3.4.11 +OBJECT:40:_ZTVSt10lock_error@@GLIBCXX_3.4.11 >>> This, I don't see why you considered it some sort of "problem"?!? Yes we >>> started exporting some additional symbols, in 3.4.11, I can confirm that. >> Adding new symbols to an old version is fundamentally wrong IMO: > Totally agreed, but who did that? Those symbols are exported @3.4.11. I > still don't understand. They would be exported @3.4.11 if they had been present before. On Solaris before 4.7, there were not. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [v3] Update Solaris baselines for GCC 4.7
On 01/27/2012 05:27 PM, Rainer Orth wrote: They would be exported @3.4.11 if they had been present before. On Solaris before 4.7, there were not. Rainer Ah, Ok, now I see, you are talking about *Solaris-specific* issues. Because Linux is fine (or that old small glitch with istreambuf_iterator is very well known). I don't think I can help clarifying these matters, sorry. Paolo.
[PATCH, MicroBlaze] Fix test after pcmp instruction
The branch test after a pattern compare instruction was backwards.
2012-01-27 Michael Eager
* config/microblaze.c (microblaze_emit_compare): Correct
test after pcmp instruction.
Index: config/microblaze/microblaze.c
===
--- config/microblaze/microblaze.c (revision 183633)
+++ config/microblaze/microblaze.c (working copy)
@@ -2811,11 +2811,13 @@ microblaze_emit_compare (enum machine_mode mode, r
if (TARGET_PATTERN_COMPARE && GET_CODE(cmp_op1) == REG)
{
if (code == EQ)
- emit_insn (gen_seq_internal_pat (comp_reg, cmp_op0, cmp_op1));
+ {
+ emit_insn (gen_seq_internal_pat (comp_reg, cmp_op0, cmp_op1));
+ *cmp_code = NE;
+ }
else
{
emit_insn (gen_sne_internal_pat (comp_reg, cmp_op0, cmp_op1));
- *cmp_code = EQ;
}
}
else
Committed revision 183635.
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
[Patch,AVR]: Better support CPSE (a bit)
This patch aims at better support of CPSE instruction in cases where otherwise
code like
TST Rn ; *cmpqi
BREQ .+2; branch
RJMP .Lm
would be produced. As branch is not a single instruction, it cannot be skipped.
peephole seems to be the only feature that can do this optimization. I tried a
combine pattern and it works will and is straight forward, but then it's hard
to detect the situations where TST is superfluous because some arithmetic
instruct already set cc0.
I also tried movqicc to emit code and to prefer jumps that please CPSE, but the
middle end has it's own understanding of what the code should look like and
it's merely impossible to work against that in the backend. Moreover there was
changes (like for PR45416 to feature specific target) that turned out to give
worse code for AVR. But as so often the "what the hell is AVR?" target is left
behind.
So here is the patch even though I really don't like peephole[2]. It passes
without regressions and has a bit of code cleanup, too.
Ok to apply?
Johann
* config/avr/avr-protos.h (lpm_reg_rtx, lpm_addr_reg_rtx,
tmp_reg_rtx, zero_reg_rtx, all_regs_rtx, rampz_rtx): Make global.
* config/avr/avr.c: Ditto.
(avr_regnames): Remove because unused.
* config/avr/avr.md (*cpse.ne): New peephole.
(*cpse.eq): New peephole from former cpse peepholes.
Index: config/avr/avr.md
===
--- config/avr/avr.md (revision 183529)
+++ config/avr/avr.md (working copy)
@@ -5010,27 +5010,61 @@ (define_peephole
AS1 (jmp,%1));
}")
-(define_peephole
+
+(define_peephole ; "*cpse.eq"
[(set (cc0)
- (compare (match_operand:QI 0 "register_operand" "")
- (const_int 0)))
+(compare (match_operand:QI 1 "register_operand" "r,r")
+ (match_operand:QI 2 "reg_or_0_operand" "r,L")))
(set (pc)
- (if_then_else (eq (cc0) (const_int 0))
- (label_ref (match_operand 1 "" ""))
- (pc)))]
- "jump_over_one_insn_p (insn, operands[1])"
- "cpse %0,__zero_reg__")
+(if_then_else (eq (cc0)
+ (const_int 0))
+ (label_ref (match_operand 0 "" ""))
+ (pc)))]
+ "jump_over_one_insn_p (insn, operands[0])"
+ "@
+ cpse %1,%2
+ cpse %1,__zero_reg__")
-(define_peephole
+;; This peephole avoids code like
+;;
+;; TST Rn ; *cmpqi
+;; BREQ .+2; branch
+;; RJMP .Lm
+;;
+;; Notice that the peephole is always shorter than cmpqi + branch.
+;; The reason to write it as peephole is that sequences like
+;;
+;; AND Rm, Rn
+;; BRNE .La
+;;
+;; shall not be superseeded. With a respective combine pattern
+;; the latter sequence would be
+;;
+;; AND Rm, Rn
+;; CPSE Rm, __zero_reg__
+;; RJMP .La
+;;
+;; and thus longer and slower and not easy to be rolled back.
+
+(define_peephole ; "*cpse.ne"
[(set (cc0)
-(compare (match_operand:QI 0 "register_operand" "")
- (match_operand:QI 1 "register_operand" "")))
+(compare (match_operand:QI 1 "register_operand" "")
+ (match_operand:QI 2 "reg_or_0_operand" "")))
(set (pc)
- (if_then_else (eq (cc0) (const_int 0))
- (label_ref (match_operand 2 "" ""))
+(if_then_else (ne (cc0)
+ (const_int 0))
+ (label_ref (match_operand 0 "" ""))
(pc)))]
- "jump_over_one_insn_p (insn, operands[2])"
- "cpse %0,%1")
+ "!AVR_HAVE_JMP_CALL
+ || !avr_current_device->errata_skip"
+ {
+if (operands[2] == const0_rtx)
+ operands[2] = zero_reg_rtx;
+
+return 3 == avr_jump_mode (operands[0], insn)
+ ? "cpse %1,%2\;jmp %0"
+ : "cpse %1,%2\;rjmp %0";
+ })
;;
;;prologue/epilogue support instructions
Index: config/avr/avr-protos.h
===
--- config/avr/avr-protos.h (revision 183529)
+++ config/avr/avr-protos.h (working copy)
@@ -124,6 +124,14 @@ extern bool avr_mem_flash_p (rtx);
extern bool avr_mem_memx_p (rtx);
extern bool avr_load_libgcc_p (rtx);
extern bool avr_xload_libgcc_p (enum machine_mode);
+
+extern rtx lpm_reg_rtx;
+extern rtx lpm_addr_reg_rtx;
+extern rtx tmp_reg_rtx;
+extern rtx zero_reg_rtx;
+extern rtx all_regs_rtx[32];
+extern rtx rampz_rtx;
+
#endif /* RTX_CODE */
#ifdef REAL_VALUE_TYPE
Index: config/avr/avr.c
===
--- config/avr/avr.c (revision 183529)
+++ config/avr/avr.c (working copy)
@@ -140,30 +140,33 @@ static bool avr_rtx_costs (rtx, int, int
#define FIRST_CUM_REG 26
/* Implicit target register of LPM instruction (R0) */
-static GTY(()) rtx lpm_reg_rtx;
+extern GTY(()) rtx lpm_reg_rtx;
+rtx lpm_reg_rtx;
/* (Implicit) address register of LPM instruction (R31:R30 = Z) */
-static GTY(()) rtx lpm_addr_reg_rtx;
+extern GTY(()) rtx lpm_addr_reg_rtx;
+rtx lpm_a
Re: [v3] Update Solaris baselines for GCC 4.7
On 01/27/2012 05:22 PM, Paolo Carlini wrote: Perhaps you have a pointer? . I can search, but really the issue is very, very old and we already released *many* GCCs "affected". This one: 2005-06-23 Jakub Jelinek PR libstdc++/22109 * src/compatibility.cc (_GLIBCXX_SYMVER_COMPATIBILITY): Remove. ... Paolo.
Re: [v3] Update Solaris baselines for GCC 4.7
Paolo Carlini writes: > On 01/27/2012 05:27 PM, Rainer Orth wrote: >> They would be exported @3.4.11 if they had been present before. On >> Solaris before 4.7, there were not. Rainer > Ah, Ok, now I see, you are talking about *Solaris-specific* issues. Because Perhaps partially, but ... > Linux is fine (or that old small glitch with istreambuf_iterator is very > well known). I don't think I can help clarifying these matters, sorry. ... even on x86_64-unknown-linux-gnu (CentOS 5.6), I see additions to 3.4.11 (at least beyond the current baselines). I cannot tell when those were updated, but the problem goes beyond Solaris. I'd even argue that abi_check should flag all additions to released versions as a hard error. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [v3] Update Solaris baselines for GCC 4.7
On 01/27/2012 05:46 PM, Rainer Orth wrote: ... even on x86_64-unknown-linux-gnu (CentOS 5.6), I see additions to 3.4.11 (at least beyond the current baselines). Sure there are additions at 3.4.11, regularly explicitly exported @3.4.11 in the linker script. Everything went as planned, I repeat. The baselines are old, are always old, didn't we discuss that already? Normally, Jakub from time to time takes care of moving forward the baselines, if you are interested in the baselines specifically, you should ask him. Paolo.
Re: [v3] Update Solaris baselines for GCC 4.7
On 01/27/2012 05:46 PM, Rainer Orth wrote: I'd even argue that abi_check should flag all additions to released versions as a hard error. Again, agreed. As a matter of fact, I'm pretty sure we do that already, I'm pretty sure Benjamin tightened abi_check in the light of that problem we had in 2005. Paolo.
Re: [v3] Update Solaris baselines for GCC 4.7
Paolo Carlini writes: > On 01/27/2012 05:46 PM, Rainer Orth wrote: >> ... even on x86_64-unknown-linux-gnu (CentOS 5.6), I see additions to >> 3.4.11 (at least beyond the current baselines). > Sure there are additions at 3.4.11, regularly explicitly exported > @3.4.11 in the linker script. Everything went as planned, I repeat. The > baselines are old, are always old, didn't we discuss that already? That's not the issue here: those additions are symbols that were added recently, it seems, way after 3.4.11 was released. If this is `as planned', I give up on libstdc++.so symbol versioning since it servers no useful purpose. I fear this is another case of the version maps using wildcards that are way too permissive. > Normally, Jakub from time to time takes care of moving forward the > baselines, if you are interested in the baselines specifically, you > should ask him. Hopefully he can clarify. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [v3] Update Solaris baselines for GCC 4.7
Paolo Carlini writes: > On 01/27/2012 05:46 PM, Rainer Orth wrote: >> I'd even argue that abi_check should flag all additions to released >> versions as a hard error. > Again, agreed. As a matter of fact, I'm pretty sure we do that already, I'm > pretty sure Benjamin tightened abi_check in the light of that problem we > had in 2005. I doubt that, otherwise the additions to versions already released should have been flagged as such on Solaris, but abi_check suggests they are benign. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
[PATCH, rs6000] Fix PR16458, eliminate redudant compares
This patch fixes PR16458 by using the type expression attached to a reg
rtx to detect its signedness and generating unsigned compares when
appropriate. However, we continue to use signed compares for the
special case of when we compare an unsigned reg against the constant 0.
This is because signed and unsigned compares give the same results
for equality and "(unsigned)x > 0)" is equivalent to "x != 0".
Using a signed compare in this special case allows us to continue to
generate record form instructions (ie, instructions that implicitly
set cr0).
I'll note that for the moment, I have XFAILed pr16458-4.c, since this
test case isn't working yet, but it is due to a problem in expand not
attaching any type expression information on *index's reg rtx like it
does for *a and *b in pr16458-2.c. We're tracking that down for 4.8.
This has passed bootstrap and regtesting with no regressions.
Ok for mainline?
Peter
gcc/
PR target/16458
* config/rs6000/rs6000.c (rs6000_unsigned_reg_p): New function.
(rs6000_generate_compare): Use it.
gcc/testsuite/
PR target/16458
* gcc.target/powerpc/pr16458-1.c: New test.
* gcc.target/powerpc/pr16458-2.c: Likewise.
* gcc.target/powerpc/pr16458-3.c: Likewise.
* gcc.target/powerpc/pr16458-4.c: Likewise.
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c (revision 183628)
+++ gcc/config/rs6000/rs6000.c (working copy)
@@ -15588,6 +15588,22 @@ rs6000_reverse_condition (enum machine_m
return reverse_condition (code);
}
+static bool
+rs6000_unsigned_reg_p (rtx op)
+{
+ enum rtx_code code = GET_CODE (op);
+
+ if (code == REG
+ && REG_EXPR (op)
+ && TYPE_UNSIGNED (TREE_TYPE (REG_EXPR (op
+return true;
+
+ if (code == SUBREG && SUBREG_PROMOTED_UNSIGNED_P (op))
+return true;
+
+ return false;
+}
+
/* Generate a compare for CODE. Return a brand-new rtx that
represents the result of the compare. */
@@ -15606,14 +15622,11 @@ rs6000_generate_compare (rtx cmp, enum m
|| code == GEU || code == LEU)
comp_mode = CCUNSmode;
else if ((code == EQ || code == NE)
- && GET_CODE (op0) == SUBREG
- && GET_CODE (op1) == SUBREG
- && SUBREG_PROMOTED_UNSIGNED_P (op0)
- && SUBREG_PROMOTED_UNSIGNED_P (op1))
+ && rs6000_unsigned_reg_p (op0)
+ && (rs6000_unsigned_reg_p (op1)
+ || (CONST_INT_P (op1) && INTVAL (op1) != 0)))
/* These are unsigned values, perhaps there will be a later
- ordering compare that can be shared with this one.
- Unfortunately we cannot detect the signedness of the operands
- for non-subregs. */
+ ordering compare that can be shared with this one. */
comp_mode = CCUNSmode;
else
comp_mode = CCmode;
Index: gcc/testsuite/gcc.target/powerpc/pr16458-1.c
===
--- gcc/testsuite/gcc.target/powerpc/pr16458-1.c(revision 0)
+++ gcc/testsuite/gcc.target/powerpc/pr16458-1.c(revision 0)
@@ -0,0 +1,18 @@
+/* Test cse'ing of unsigned compares. */
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+/* { dg-final { scan-assembler-not "cmpw" } } */
+/* { dg-final { scan-assembler-times "cmplw" 1 } } */
+
+unsigned int a, b;
+
+int
+foo (void)
+{
+ if (a == b) return 1;
+ if (a > b) return 2;
+ if (a < b) return 3;
+ if (a != b) return 4;
+ return 0;
+}
Index: gcc/testsuite/gcc.target/powerpc/pr16458-2.c
===
--- gcc/testsuite/gcc.target/powerpc/pr16458-2.c(revision 0)
+++ gcc/testsuite/gcc.target/powerpc/pr16458-2.c(revision 0)
@@ -0,0 +1,18 @@
+/* Test cse'ing of unsigned compares. */
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+/* { dg-final { scan-assembler-not "cmpw" } } */
+/* { dg-final { scan-assembler-times "cmplw" 1 } } */
+
+unsigned int *a, *b;
+
+int
+foo (void)
+{
+ if (*a == *b) return 1;
+ if (*a > *b) return 2;
+ if (*a < *b) return 3;
+ if (*a != *b) return 4;
+ return 0;
+}
Index: gcc/testsuite/gcc.target/powerpc/pr16458-3.c
===
--- gcc/testsuite/gcc.target/powerpc/pr16458-3.c(revision 0)
+++ gcc/testsuite/gcc.target/powerpc/pr16458-3.c(revision 0)
@@ -0,0 +1,41 @@
+/* Test cse'ing of unsigned compares. */
+/* { dg-do compile } */
+/* { dg-options "-O2 -fno-jump-tables" } */
+
+/* { dg-final { scan-assembler-not "cmpwi" } } */
+/* { dg-final { scan-assembler-times "cmplwi" 5 } } */
+
+extern int case0 (void);
+extern int case1 (void);
+extern int case2 (void);
+extern int case3 (void);
+extern int case4 (void);
+
+enum CASE_VALUES
+{
+ CASE0 = 0,
+ CASE1,
+ CASE2,
+ CASE3,
+ CASE4
+};
+
+int
+foo (enum CASE_VALUES index)
+{
+ switch (index)
+{
+case CASE0:
+ return case0 ();
+case CASE1:
Re: [v3] Update Solaris baselines for GCC 4.7
Hi, On Fri, 27 Jan 2012, Rainer Orth wrote: > Paolo Carlini writes: > > > On 01/27/2012 05:27 PM, Rainer Orth wrote: > >> They would be exported @3.4.11 if they had been present before. On > >> Solaris before 4.7, there were not. Rainer > > Ah, Ok, now I see, you are talking about *Solaris-specific* issues. Because > > Perhaps partially, but ... > > > Linux is fine (or that old small glitch with istreambuf_iterator is very > > well known). I don't think I can help clarifying these matters, sorry. > > ... even on x86_64-unknown-linux-gnu (CentOS 5.6), I see additions to > 3.4.11 (at least beyond the current baselines). Which ones for instance? I have checked a couple of symbols of your 3.4.11 list and found them all also in my system (4.6 based) libstdc++. I've also checked some history of config/abi/pre/gnu.ver, and the only meddling with 3.4.11 symbols after version 3.4.12 was added (at r147137) is r157067 in 2010, that tightened some exports for numeric_limits:: . Ciao, Michael.
Re: [v3] Update Solaris baselines for GCC 4.7
On Fri, Jan 27, 2012 at 05:54:56PM +0100, Rainer Orth wrote: > Paolo Carlini writes: > > > On 01/27/2012 05:46 PM, Rainer Orth wrote: > >> I'd even argue that abi_check should flag all additions to released > >> versions as a hard error. > > Again, agreed. As a matter of fact, I'm pretty sure we do that already, I'm > > pretty sure Benjamin tightened abi_check in the light of that problem we > > had in 2005. > > I doubt that, otherwise the additions to versions already released > should have been flagged as such on Solaris, but abi_check suggests they > are benign. If you mean TLS:8:_ZSt11__once_call@@GLIBCXX_3.4.11 TLS:8:_ZSt15__once_callable@@GLIBCXX_3.4.11 then those symbols were really added in 3.4.11, but I haven't added them (intentionally) to the baseline symbols, since then anybody configuring without working TLS would get hard make check failures. Jakub
Re: [v3] Update Solaris baselines for GCC 4.7
On 01/27/2012 05:53 PM, Rainer Orth wrote: Paolo Carlini writes: On 01/27/2012 05:46 PM, Rainer Orth wrote: ... even on x86_64-unknown-linux-gnu (CentOS 5.6), I see additions to 3.4.11 (at least beyond the current baselines). Sure there are additions at 3.4.11, regularly explicitly exported @3.4.11 in the linker script. Everything went as planned, I repeat. The baselines are old, are always old, didn't we discuss that already? That's not the issue here: those additions are symbols that were added recently, it seems, way after 3.4.11 was released. I fiddled a bit with svn blame and I have been able to find only two changes to those lines, svn versions 135007 and 139943. At that time for sure the linker script did *not* have a 3.4.12 open, thus in any case can't possibly be *way after*. If you can find evidence that we did that when a 3.4.11 was already out, then we (me; Chris Fairles via Benjamin) did something badly wrong. But I seriously doubt that, because 3.4.11 appeared for the first time in gcc4.4.0 which was released 2009-04-21, thus many months after those commits. Paolo.
Re: [v3] Update Solaris baselines for GCC 4.7
Jakub Jelinek writes: > On Fri, Jan 27, 2012 at 05:54:56PM +0100, Rainer Orth wrote: >> Paolo Carlini writes: >> >> > On 01/27/2012 05:46 PM, Rainer Orth wrote: >> >> I'd even argue that abi_check should flag all additions to released >> >> versions as a hard error. >> > Again, agreed. As a matter of fact, I'm pretty sure we do that already, I'm >> > pretty sure Benjamin tightened abi_check in the light of that problem we >> > had in 2005. >> >> I doubt that, otherwise the additions to versions already released >> should have been flagged as such on Solaris, but abi_check suggests they >> are benign. > > If you mean > TLS:8:_ZSt11__once_call@@GLIBCXX_3.4.11 > > TLS:8:_ZSt15__once_callable@@GLIBCXX_3.4.11 > > then those symbols were really added in 3.4.11, but I haven't added them > (intentionally) to the baseline symbols, since then anybody configuring > without working TLS would get hard make check failures. Those were among them, but I can't currently check the full list since a build is just running. I have a similar issue on Solaris 8 and 9, already mentioned in my (tentative) patch submission: http://gcc.gnu.org/ml/gcc-patches/2012-01/msg01163.html Depending on the toolchain used (Sun as which doesn't support TLS, or GNU as which does), you get either emutls or native TLS related symbol. Omitting either from the baselines is certainly an option, as would be having separate baselines, though certainly ugly. Could you please also have a look at the questions raised in the patch submission? I think we should avoid adding to GLIBCXX_3.4.5, 3.4.11, and 3.4.15 on Solaris, avoiding the old mistake on the Linux side, even if that means having a separate (or preprocessed) gnu.ver for that purpose. Thanks. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Fix genautomata option parsing
I noticed that genautomata does not accept any of the options it is
trying to handle, since init_rtx_reader_args already errors out for all
of them. This was probably broken by some gensupport reorganization way
back.
Fixed with this patch; I also removed the zero initializations for the
flags which ought to be unnecessary.
Bootstrapped on i686-linux. Ok?
Bernd
* genautomata.c (parse_automata_opt): New static function.
(initiate_automaton_gen): Remove all option handling code. Remove
argc argument. All callers changed.
(main): Call init_rtx_reader_args_cb with the new function as
argument.
Index: gcc/genautomata.c
===
--- gcc/genautomata.c (revision 182544)
+++ gcc/genautomata.c (working copy)
@@ -9285,46 +9285,45 @@ base_file_name (const char *file_name)
return file_name + directory_name_length + 1;
}
+/* A function passed as argument to init_rtx_reader_args_cb. It parses the
+ options available for genautomata. Returns true if the option was
+ recognized. */
+static bool
+parse_automata_opt (const char *str)
+{
+ if (strcmp (str, NO_MINIMIZATION_OPTION) == 0)
+no_minimization_flag = 1;
+ else if (strcmp (str, TIME_OPTION) == 0)
+time_flag = 1;
+ else if (strcmp (str, STATS_OPTION) == 0)
+stats_flag = 1;
+ else if (strcmp (str, V_OPTION) == 0)
+v_flag = 1;
+ else if (strcmp (str, W_OPTION) == 0)
+w_flag = 1;
+ else if (strcmp (str, NDFA_OPTION) == 0)
+ndfa_flag = 1;
+ else if (strcmp (str, COLLAPSE_OPTION) == 0)
+collapse_flag = 1;
+ else if (strcmp (str, PROGRESS_OPTION) == 0)
+progress_flag = 1;
+ else if (strcmp (str, "-split") == 0)
+{
+ fatal ("option `-split' has not been implemented yet\n");
+ /* split_argument = atoi (argument_vect [i + 1]); */
+}
+ else
+return false;
+
+ return true;
+}
+
/* The following is top level function to initialize the work of
pipeline hazards description translator. */
static void
-initiate_automaton_gen (int argc, char **argv)
+initiate_automaton_gen (char **argv)
{
const char *base_name;
- int i;
-
- ndfa_flag = 0;
- split_argument = 0; /* default value */
- no_minimization_flag = 0;
- time_flag = 0;
- stats_flag = 0;
- v_flag = 0;
- w_flag = 0;
- progress_flag = 0;
- for (i = 2; i < argc; i++)
-if (strcmp (argv [i], NO_MINIMIZATION_OPTION) == 0)
- no_minimization_flag = 1;
-else if (strcmp (argv [i], TIME_OPTION) == 0)
- time_flag = 1;
-else if (strcmp (argv [i], STATS_OPTION) == 0)
- stats_flag = 1;
-else if (strcmp (argv [i], V_OPTION) == 0)
- v_flag = 1;
-else if (strcmp (argv [i], W_OPTION) == 0)
- w_flag = 1;
-else if (strcmp (argv [i], NDFA_OPTION) == 0)
- ndfa_flag = 1;
-else if (strcmp (argv [i], COLLAPSE_OPTION) == 0)
- collapse_flag = 1;
-else if (strcmp (argv [i], PROGRESS_OPTION) == 0)
- progress_flag = 1;
-else if (strcmp (argv [i], "-split") == 0)
- {
- if (i + 1 >= argc)
- fatal ("-split has no argument.");
- fatal ("option `-split' has not been implemented yet\n");
- /* split_argument = atoi (argument_vect [i + 1]); */
- }
/* Initialize IR storage. */
obstack_init (&irp);
@@ -9620,10 +9619,10 @@ main (int argc, char **argv)
progname = "genautomata";
- if (!init_rtx_reader_args (argc, argv))
+ if (!init_rtx_reader_args_cb (argc, argv, parse_automata_opt))
return (FATAL_EXIT_CODE);
- initiate_automaton_gen (argc, argv);
+ initiate_automaton_gen (argv);
while (1)
{
int lineno;
Re: [v3] Update Solaris baselines for GCC 4.7
Jakub Jelinek writes: >> I doubt that, otherwise the additions to versions already released >> should have been flagged as such on Solaris, but abi_check suggests they >> are benign. > > If you mean > TLS:8:_ZSt11__once_call@@GLIBCXX_3.4.11 > > TLS:8:_ZSt15__once_callable@@GLIBCXX_3.4.11 > > then those symbols were really added in 3.4.11, but I haven't added them > (intentionally) to the baseline symbols, since then anybody configuring > without working TLS would get hard make check failures. Yep, those to are the only ones, everything else is in GLIBCXX_3.4.1[67], CXXABI_1.3.6, or CXXABI_TM_1. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
[PING] New port resubmission for TILEPro and TILE-Gx
Ping? It's been a month. Seeing more feedback or status update.
Thanks,
Walter Lee
On 12/30/2011 7:30 PM, Walter Lee wrote:
I'm resubmitting the gcc ports to TILE-Gx and TILEPro as replies to
this email. The resubmission addresses the feedback made by Richard
Henderson in:
http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01232.html, and
http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01247.html
Feedback by Joseph Myers made in:
http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01385.html
http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01387.html
was addressed in a previous submission.
Here is a summary of the issues addressed:
Changes made to both ports:
- added vector patterns for suitable vector ops.
- cleaned up various move pattens, deleting dead alternatives,
deleting redundant immediate insn_and_split patterns, and delete
unnecessary movdi multi-word move pattern (tilepro only).
- added extra insv patterns.
- combined all the conditional moves into one pattern.
- combined "*lh" and "*extendhisi2" pattern, and "*lb" and
"*extendqihi2".
- partially remove the divsi stubs that were there to work around an
old gcc bug that has been partially fixed. Previously gcc would not
turn divide by constant into multiply by constant unless there is a
pattern for the divide of the given mode. It now seems to do
better, but we still need the stub on tilegx, else it turns 32-bit
divide by constant into 64-bit multiply by constant.
- wrap the GOT and TLS unspec addresses in const, and handle them with
a single pattern.
- add support for post_{inc,dec,modify} addressing modes.
- fixed invalid rtl sharing in alloca handling routines.
- use REG_CFA_* notes in prologue and epilogue.
- Use post-inc load in TARGET_ASM_TRAMPOLINE_TEMPLATE.
- converted the following to target hooks: LIBCALL_VALUE,
FUNCTION_VALUE_REGNO_P, GO_IF_LEGITIMATE_ADDRESS. Delete
GO_IF_MODE_DEPENDENT_ADDRESS and use the default.
- use the new atomics_ names and patterns.
Changes made to tilegx port:
- merged the AND patterns.
- add patterns that sign extends an SI result to DI for all the 32-bit
insns.
Here are replies to a few feedback items:
optabs.c will do exactly this if the pattern is not present. Similarly
for the DImode logicals (popcount, parity, etc).
I tried taking out the patterns for ctzdi2, clzdi2, ffsdi2, paritydi2,
and popcountdi2, and I found that the compiler generates libgcc
function calls for all of them except clzdi2. For clzdi2 the tilepro
pattern is better than the default because it uses mvnz to get rid of
a branch.
This is all true for gcc 4.4.6... gcc 4.7 does not use my patterns at
all, which seems like a bug.
I need the paritysi2 as well; without it the compiler does not
generate code for paritydi2 properly.
Post merge, consider changing this to simple_return to enable shrink
wrapping. This may also involve epilogue unwind fixups though.
I have not enabled the "simple_return" pattern. On the tile ports,
the prologue defines a register not accounted for in the shrink
wrapping code (the PIC_TEXT_LABEL_REGNUM register). Is there a plan
to provide a target hook to support this? I did verify that shrink
wrapping work properly when I account for this register.
I also don't see support for AND addresses, as for lw_na. And yet you
seem to be using those addressing modes in tilepro_expand_unaligned_load.
I can only assume these are failing validate_mem, and forcing the
address into a register first?
Yeah there is no AND addressing mode; the addresses are being put into
registers.
Why not use gp-relative references? A small matter of extending the
assembler with new relocations, perhaps.
We don't have that support in the tool chain currently. I can look
into it, but I haven't done it.
/* We represent all SI values as sign-extended DI values in
registers. */
#define TRULY_NOOP_TRUNCATION(OUTPREC, INPREC) \
((INPREC)<= 32 || (OUTPREC)> 32)
I think you should be *very* careful before you insist on this. Do
you not have a memory mode that ignores the high bits for 32-bit
pointers? From the description of "memoryReadWord", it does seem like
you've got modes that pre-process input addresses.
Unfortunately all the address bits are read; we do not ignore the high
bits of 32-bit pointers.
MIPS uses this because, technically, the 32-bit operation insns
produce undefined results when given inputs that are not
sign-extended. I see no such restriction in the TileGx manual.
I think the issue is that we do not have 32-bit compares; we just
reuse the 64-bit ones. This requires that the inputs be sign
extended.
At least in 64-bit pointer mode, I think you should drop this and make
sure that you've got appropriate sign_extend patterns for all of the
"x" insns. Similar to how x86_64 does for the zero_extend patterns.
I've added the sign_extend patterns for the 32-bit insns.
Please let me know if there is anything I need to address.
Thanks,
Wa
Re: [Patch,AVR]: Better support CPSE (a bit)
2012/1/27 Georg-Johann Lay : > This patch aims at better support of CPSE instruction in cases where otherwise > code like > > TST Rn ; *cmpqi > BREQ .+2 ; branch > RJMP .Lm > > would be produced. As branch is not a single instruction, it cannot be > skipped. > > peephole seems to be the only feature that can do this optimization. I tried a > combine pattern and it works will and is straight forward, but then it's hard > to detect the situations where TST is superfluous because some arithmetic > instruct already set cc0. > > I also tried movqicc to emit code and to prefer jumps that please CPSE, but > the > middle end has it's own understanding of what the code should look like and > it's merely impossible to work against that in the backend. Moreover there was > changes (like for PR45416 to feature specific target) that turned out to give > worse code for AVR. But as so often the "what the hell is AVR?" target is left > behind. > > So here is the patch even though I really don't like peephole[2]. It passes > without regressions and has a bit of code cleanup, too. > > Ok to apply? > > Johann > > * config/avr/avr-protos.h (lpm_reg_rtx, lpm_addr_reg_rtx, > tmp_reg_rtx, zero_reg_rtx, all_regs_rtx, rampz_rtx): Make global. > * config/avr/avr.c: Ditto. > (avr_regnames): Remove because unused. > * config/avr/avr.md (*cpse.ne): New peephole. > (*cpse.eq): New peephole from former cpse peepholes. Approved. Denis.
Re: [C++ PATCH] Destroy/clear local_specializations properly in tsubst_pack_expansion (PR c++/51852)
OK. Jason
Re: [v3] Update Solaris baselines for GCC 4.7
On Mon, Jan 23, 2012 at 07:31:55PM +0100, Rainer Orth wrote: > * There's quite a number of additions to 3.4.11: Probably Solaris didn't have _GLIBCXX_HAS_GTHREADS support before and now does? config/abi/pre/*.ver isn't currently conditionalized in any way, so I don't see an easy way to move these to GLIBCXX_3.4.17 just for Solaris and not for others. > +FUNC:_ZNKSt10lock_error4whatEv@@GLIBCXX_3.4.11 > +FUNC:_ZNSt18condition_variable10notify_allEv@@GLIBCXX_3.4.11 > +FUNC:_ZNSt18condition_variable10notify_oneEv@@GLIBCXX_3.4.11 > +FUNC:_ZNSt18condition_variable4waitERSt11unique_lockISt5mutexE@@GLIBCXX_3.4.11 > +FUNC:_ZNSt18condition_variableC1Ev@@GLIBCXX_3.4.11 > +FUNC:_ZNSt18condition_variableC2Ev@@GLIBCXX_3.4.11 > +FUNC:_ZNSt18condition_variableD1Ev@@GLIBCXX_3.4.11 > +FUNC:_ZNSt18condition_variableD2Ev@@GLIBCXX_3.4.11 > +FUNC:_ZNSt22condition_variable_anyC1Ev@@GLIBCXX_3.4.11 > +FUNC:_ZNSt22condition_variable_anyC2Ev@@GLIBCXX_3.4.11 > +FUNC:_ZNSt22condition_variable_anyD1Ev@@GLIBCXX_3.4.11 > +FUNC:_ZNSt22condition_variable_anyD2Ev@@GLIBCXX_3.4.11 > +FUNC:_ZNSt6thread15_M_start_threadESt10shared_ptrINS_10_Impl_baseEE@@GLIBCXX_3.4.11 > +FUNC:_ZNSt6thread4joinEv@@GLIBCXX_3.4.11 > +FUNC:_ZNSt6thread6detachEv@@GLIBCXX_3.4.11 > +FUNC:__once_proxy@@GLIBCXX_3.4.11 > +OBJECT:12:_ZTISt10lock_error@@GLIBCXX_3.4.11 > +OBJECT:15:_ZTSSt10lock_error@@GLIBCXX_3.4.11 > +OBJECT:20:_ZTVSt10lock_error@@GLIBCXX_3.4.11 > +OBJECT:24:_ZTISt10lock_error@@GLIBCXX_3.4.11 > +OBJECT:40:_ZTVSt10lock_error@@GLIBCXX_3.4.11 > > Apart from that, baselines with Sun as (emutls) and GNU as (native TLS) > differ on Solaris 8: > > --- baseline_symbols.txt2012-01-23 19:01:03.590486000 +0100 > +++ baseline_symbols.txt.s8g2012-01-23 19:03:38.063402000 +0100 > @@ -2176,0 +2177 @@ > +FUNC:_ZSt16__get_once_mutexv@@GLIBCXX_3.4.12 > @@ -2209,0 +2211 @@ > +FUNC:_ZSt23__get_once_functor_lockv@@GLIBCXX_3.4.11 > @@ -2212,0 +2215 @@ > +FUNC:_ZSt27__set_once_functor_lock_ptrPSt11unique_lockISt5mutexE@@GLIBCXX_3.4.12 > @@ -2649,0 +2653 @@ > +OBJECT:16:_ZSt14__once_functor@@GLIBCXX_3.4.11 > @@ -2715,2 +2718,0 @@ > -OBJECT:16:__emutls_v._ZSt11__once_call@@GLIBCXX_3.4.15 > -OBJECT:16:__emutls_v._ZSt15__once_callable@@GLIBCXX_3.4.15 > > This hasn't happened before. While the additions with gas are ok, the > removals are not. libstdc++ with and without TLS support are simply not ABI compatible. Jakub
Re: [C++ PATCH] Destroy/clear local_specializations properly in tsubst_pack_expansion (PR c++/51852)
On 01/27/2012 08:01 AM, Jakub Jelinek wrote: In the PR there is also a patch to switch local_specializations into a pointer_map, I think that would be more efficient, but probably 4.8 material, right? Yes, that change is OK for 4.8. Jason
Re: [PATCH] libgcc: refer to pthread_create, not pthread_cancel
I see. There certainly should have been a comment in the code about why pthread_cancel was chosen. I still think it's a particularly poor choice. For glibc, I think pthread_getspecific or pthread_key_create are better choices. Those are much smaller functions that don't bring very much dead code into the link, and they are things actually used by libstdc++ et al. For supporting the interception cases, it's really not entirely safe to use any of the public API functions. Someone might have intercepted any of them in the same way as was cited for pthread_create. In glibc, we have exported __ names for various things, including __pthread_getspecific and __pthread_key_create. IMHO one of those is the best choice. They are part of the permanent public ABI and so won't ever go away, but they are not part of the public API that anyone writing an interceptor library would ever want to touch. Thanks, Roland
Re: [v3] Update Solaris baselines for GCC 4.7
Jakub Jelinek writes: > On Mon, Jan 23, 2012 at 07:31:55PM +0100, Rainer Orth wrote: >> * There's quite a number of additions to 3.4.11: > > Probably Solaris didn't have _GLIBCXX_HAS_GTHREADS support > before and now does? Right, it didn't on Solaris 8 and 9 in 4.6, but does now. It seems the test has changed, but I didn't yet investigate in detail. > config/abi/pre/*.ver isn't currently conditionalized in any way, > so I don't see an easy way to move these to GLIBCXX_3.4.17 just > for Solaris and not for others. It could be done along the same line as #ifdef HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT is used. gnu.ver is already preprocessed for Solaris, so one could add to that. Ugly but certainly better than breaking versioning. OTOH, that would mean that the symbols are in 3.4.11 in a Solaris 10+-built libstdc++, but in 3.4.17 on a Solaris 8-built one... >> Apart from that, baselines with Sun as (emutls) and GNU as (native TLS) >> differ on Solaris 8: >> >> --- baseline_symbols.txt2012-01-23 19:01:03.590486000 +0100 >> +++ baseline_symbols.txt.s8g2012-01-23 19:03:38.063402000 +0100 >> @@ -2176,0 +2177 @@ >> +FUNC:_ZSt16__get_once_mutexv@@GLIBCXX_3.4.12 >> @@ -2209,0 +2211 @@ >> +FUNC:_ZSt23__get_once_functor_lockv@@GLIBCXX_3.4.11 >> @@ -2212,0 +2215 @@ >> +FUNC:_ZSt27__set_once_functor_lock_ptrPSt11unique_lockISt5mutexE@@GLIBCXX_3.4.12 >> @@ -2649,0 +2653 @@ >> +OBJECT:16:_ZSt14__once_functor@@GLIBCXX_3.4.11 >> @@ -2715,2 +2718,0 @@ >> -OBJECT:16:__emutls_v._ZSt11__once_call@@GLIBCXX_3.4.15 >> -OBJECT:16:__emutls_v._ZSt15__once_callable@@GLIBCXX_3.4.15 >> >> This hasn't happened before. While the additions with gas are ok, the >> removals are not. > > libstdc++ with and without TLS support are simply not ABI compatible. Obviously. Given that the only Solaris configurations lacking native TLS support are old Solaris 8 and 9 toolchains with Sun as, one could omit the TLS related in those baselines, just as you did for Linux. Adding a second set of baselines (and the infrastructure to deal with them) is probably not worth the effort. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [Patch,testsuite]: Fix testcase that bangs long and int against void*
Jakub Jelinek wrote:
> On Fri, Jan 13, 2012 at 07:40:59PM +0100, Georg-Johann Lay wrote:
>> The ilp32 is the closes match:
>>
>> The source casts pointer to int, int to pointer, long to int, uses 32-bit
>> initializers for int, assumes size_t is unsigned long any maybe others.
>
> No. The source is just fine for any target where sizeof (long) == sizeof
> (void *).
> So both ilp32 and lp64.
Now just factored out avr. There is no dg-requite to filter out long!=void*, or
did I miss something?
Ok to apply?
Johann
* gcc.dg/lto/20091013-1_1.c: xfail for avr.
* gcc.dg/lto/20091013-1_2.c: xfail for avr.
Index: gcc.dg/lto/20091013-1_1.c
===
--- gcc.dg/lto/20091013-1_1.c (revision 183472)
+++ gcc.dg/lto/20091013-1_1.c (working copy)
@@ -1,3 +1,4 @@
+/* { dg-xfail-if "cast to pointer of different size" { "avr-*-*" } { "*" } {
"" } } */
typedef struct HDC__ { int unused; } *HDC;
typedef struct HFONT__ { int unused; } *HFONT;
Index: gcc.dg/lto/20091013-1_2.c
===
--- gcc.dg/lto/20091013-1_2.c (revision 183472)
+++ gcc.dg/lto/20091013-1_2.c (working copy)
@@ -1,3 +1,4 @@
+/* { dg-xfail-if "cast to pointer of different size" { "avr-*-*" } { "*" } {
"" } } */
typedef struct HDC__ { int unused; } *HDC;
typedef struct HFONT__ { int unused; } *HFONT;
Re: libgo patch committed: Update to weekly.2011-12-22
Ian Lance Taylor writes: > Fixed with the appended patch, which also gathers up all the possibly > missing functions that I noticed. Bootstrapped and ran Go testsuite on > x86_64-unknown-linux-gnu, which proves little as the system I tested on > has all these functions anyhow. Committed to mainline. Results are way better now, but still a couple of libgo FAILs: Running target unix FAIL: net FAIL: websocket FAIL: compress/flate FAIL: exp/ssh FAIL: image/jpeg FAIL: log/syslog FAIL: net/http FAIL: net/http/httputil FAIL: net/rpc FAIL: os/exec Most of them are like Start pollServer: epoll_ctl: Bad file descriptor panic: runtime error: invalid memory address or nil pointer dereference FAIL: net Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH] Fix expansion of BLKmode MEM_REF with non-addressable non-BLKmode base decl (PR middle-end/51895)
> I have applied this now and the SRA side of the fix for PR50444. > As far as I know x86 should be ok with alignment-related issues > and SRA now - is there still a bug on strict-alignment platforms > we know of (thus, with a testcase)? Not that I know of, but let me do some testing on the SPARC this week-end. > Otherwise I'd rather delay trying to properly expand misaligned MEM_REFs on > non-movmisalign STRICT_ALIGNMENT targets to 4.8. That sounds sensible to me. -- Eric Botcazou
[pph] Fix ICE with circular #includes (issue5588046)
When generating PPH images, circular #includes cannot be handled using
the usual double-guard inclusion in the pre-processor. This happens
because we generate PPH images in separate compilations. So, even
with properly double-guarded headers, each header will include the
other in its image:
1.h
#ifndef _1_H
#define _1_H
#include "2.h"
#endif
2.h
#ifndef _2_H
#define _2_H
#include "1.h"
#endif
When compiling 1.h, we will try open 2.pph, which in turn includes
1.h, which is being generated. To avoid this situation, we simply
force the inclusion of 1.h to proceed as a text inclusion.
When adding a test for this, I ran into trouble with the testing
harness. The test would fail depending on which PPH images were
already present in the build directory. So, I modified pph.exp to
remove all the PPH images before starting the main test loop. I think
this will not work in a remote test setting, but I will deal with that
later.
2012-01-27 Diego Novillo
cp/ChangeLog.pph
* pph-core.c (pph_stream_open): If STREAM exists and its mode
is different than the mode in which it was originally opened,
return NULL.
testsuite/ChangeLog.pph
* g++.dg/pph/pph.exp: Remove PPH images before running the tests.
* g++.dg/pph/x1circular.h: New.
* g++.dg/pph/x2circular.h: New.
* g++.dg/pph/x3circular.cc: New.
diff --git a/gcc/cp/pph-core.c b/gcc/cp/pph-core.c
index f252720..5f6c27f 100644
--- a/gcc/cp/pph-core.c
+++ b/gcc/cp/pph-core.c
@@ -1117,7 +1117,9 @@ pph_stream_unregister (pph_stream *stream)
/* Create a new PPH stream to be stored on the file called NAME.
- MODE is passed to fopen directly. */
+ MODE is passed to fopen directly. If NAME could not be opened,
+ return NULL to indicate to the caller that it should process NAME
+ as a regular text header. */
pph_stream *
pph_stream_open (const char *name, const char *mode)
@@ -1130,6 +1132,15 @@ pph_stream_open (const char *name, const char *mode)
stream = pph_stream_registry_lookup (name);
if (stream)
{
+ /* In a circular #include scenario, we will eventually try to
+read from the same PPH image that we are generating. To
+avoid that problem, detect circularity and return NULL to
+force the caller to process NAME as a regular text header. */
+ if (stream->write_p && strchr (mode, 'r') != NULL)
+ return NULL;
+
+ /* Otherwise, assert that we have read (or are reading) STREAM
+and return it. */
gcc_assert (stream->in_memory_p);
return stream;
}
diff --git a/gcc/testsuite/g++.dg/pph/pph.exp b/gcc/testsuite/g++.dg/pph/pph.exp
index a632365..7df3596 100644
--- a/gcc/testsuite/g++.dg/pph/pph.exp
+++ b/gcc/testsuite/g++.dg/pph/pph.exp
@@ -41,6 +41,14 @@ exec echo "string.h string.pph" >> pph.map
set mapflag -fpph-map=pph.map
+# Remove all existing PPH images to prevent stale state issues.
+verbose "Removing existing PPH images" 0
+set pph_file_list "[glob -nocomplain *.pph]"
+foreach pph_file $pph_file_list {
+ remote_file build delete $pph_file
+}
+
+verbose "Running PPH tests" 0
foreach scenario $scenarios {
set old_dg_do_what_default "${dg-do-what-default}"
diff --git a/gcc/testsuite/g++.dg/pph/x1circular.h
b/gcc/testsuite/g++.dg/pph/x1circular.h
new file mode 100644
index 000..5b9f744
--- /dev/null
+++ b/gcc/testsuite/g++.dg/pph/x1circular.h
@@ -0,0 +1,8 @@
+#ifndef X1_CIRCULAR_H
+#define X1_CIRCULAR_H
+/* We are purposely generating a circular #include chain. Neither
+ header will be able to open the other one as their images are
+ being generated. */
+#include "x2circular.h" // { dg-warning "cannot open PPH file
x2circular.pph.*" }
+int foo(int, int);
+#endif
diff --git a/gcc/testsuite/g++.dg/pph/x2circular.h
b/gcc/testsuite/g++.dg/pph/x2circular.h
new file mode 100644
index 000..d276f28
--- /dev/null
+++ b/gcc/testsuite/g++.dg/pph/x2circular.h
@@ -0,0 +1,7 @@
+#ifndef X2_CIRCULAR_H
+#define X2_CIRCULAR_H
+int bar(int, int);
+
+#include "x1circular.h"
+
+#endif
diff --git a/gcc/testsuite/g++.dg/pph/x3circular.cc
b/gcc/testsuite/g++.dg/pph/x3circular.cc
new file mode 100644
index 000..410cba5
--- /dev/null
+++ b/gcc/testsuite/g++.dg/pph/x3circular.cc
@@ -0,0 +1,21 @@
+// { dg-do run }
+#include "x2circular.h"
+
+extern "C" { void abort(void); }
+
+int bar(int x, int y)
+{
+ return x - y;
+}
+
+int foo(int x, int y)
+{
+ return bar (x, y) + x + y;
+}
+
+int main(void)
+{
+ if (foo (0, 0) != 0)
+abort ();
+ return 0;
+}
--
This patch is available for review at http://codereview.appspot.com/5588046
Re: Fix genautomata option parsing
On 01/27/2012 12:20 PM, Bernd Schmidt wrote: I noticed that genautomata does not accept any of the options it is trying to handle, since init_rtx_reader_args already errors out for all of them. This was probably broken by some gensupport reorganization way back. Fixed with this patch; I also removed the zero initializations for the flags which ought to be unnecessary. Bootstrapped on i686-linux. Ok? Ok. Thanks, Bernd.
[lra] patch to fix some bugs in LRA for arm
The following patch fixes some bugs in caller-saves pseudo splitting
found on ARM toolchain. But ARM bootstrap failure is not fixed yet.
The patch was successfully bootstrapped on x86/x86-64. Committed as
rev. 183639.
2012-01-27 Vladimir Makarov
* lra-int.h (lra_risky_equiv_subst_p): Rename to
lra_risky_transformations_p.
* lra-constraints.c: Ditto.
(inherit_in_ebb): When splitting pseudo subreg, set up
lra_risky_transformations_p. Process subreg of multi-register
pseudo as input too.
* lra-assigns.c (setup_live_pseudos_and_spill_after_equiv_moves):
Rename to setup_live_pseudos_and_spill_after_risky_transforms.
Index: lra-assigns.c
===
--- lra-assigns.c (revision 183637)
+++ lra-assigns.c (working copy)
@@ -829,13 +829,17 @@ static int *sorted_pseudos;
contains pseudos assigned to hard registers. Such equivalence
usage might create new conflicts of pseudos with hard registers
(like ones used for parameter passing or call clobbered ones) or
- other pseudos assigned to the same hard registers. Process pseudos
- assigned to hard registers (most frequently used first), spill if a
- conflict is found, and mark the spilled pseudos in
- SPILLED_PSEUDO_BITMAP. Set up LIVE_HARD_REG_PSEUDOS from pseudos,
- assigned to hard registers. */
+ other pseudos assigned to the same hard registers. Another very
+ rare risky transformation is restoring whole multi-register pseudo
+ when only one subreg lives and unused hard register is used already
+ for something else.
+
+ Process pseudos assigned to hard registers (most frequently used
+ first), spill if a conflict is found, and mark the spilled pseudos
+ in SPILLED_PSEUDO_BITMAP. Set up LIVE_HARD_REG_PSEUDOS from
+ pseudos, assigned to hard registers. */
static void
-setup_live_pseudos_and_spill_after_equiv_moves (bitmap spilled_pseudo_bitmap)
+setup_live_pseudos_and_spill_after_risky_transforms (bitmap spilled_pseudo_bitmap)
{
int p, i, j, n, regno, hard_regno;
unsigned int k, conflict_regno;
@@ -848,12 +852,12 @@ setup_live_pseudos_and_spill_after_equiv
for (n = 0, i = FIRST_PSEUDO_REGISTER; i < max_reg_num (); i++)
if (reg_renumber[i] >= 0 && lra_reg_info[i].nrefs > 0)
{
- if (lra_risky_equiv_subst_p)
+ if (lra_risky_transformations_p)
sorted_pseudos[n++] = i;
else
update_lives (i, false);
}
- if (! lra_risky_equiv_subst_p)
+ if (! lra_risky_transformations_p)
return;
qsort (sorted_pseudos, n, sizeof (int), pseudo_compare_func);
for (i = 0; i < n; i++)
@@ -896,7 +900,7 @@ setup_live_pseudos_and_spill_after_equiv
lra_hard_reg_usage[hard_regno + j] -= lra_reg_info[regno].freq;
reg_renumber[regno] = -1;
if (lra_dump_file != NULL)
- fprintf (lra_dump_file, "Spill r%d after reg equiv. moves\n",
+ fprintf (lra_dump_file, "Spill r%d after risky transformations\n",
regno);
}
}
@@ -1149,7 +1153,7 @@ lra_assign (void)
regno_allocno_class_array[i] = lra_get_allocno_class (i);
init_regno_assign_info ();
bitmap_initialize (&all_spilled_pseudos, ®_obstack);
- setup_live_pseudos_and_spill_after_equiv_moves (&all_spilled_pseudos);
+ setup_live_pseudos_and_spill_after_risky_transforms (&all_spilled_pseudos);
/* Setup insns to process. */
bitmap_initialize (&changed_pseudo_bitmap, ®_obstack);
init_live_reload_and_inheritance_pseudos ();
Index: lra-constraints.c
===
--- lra-constraints.c (revision 183637)
+++ lra-constraints.c (working copy)
@@ -254,10 +254,6 @@ get_reload_reg (enum op_type type, enum
if (type == OP_OUT)
{
- /* Unique value is needed when we need reloads for pseudo which
- occurs as earlier clobber output and input operands to
- guarantee that the both reload pseudos have unique value and
- can not be assigned to the same hard register. */
*result_reg
= lra_create_new_reg_with_unique_value (mode, original, rclass, title);
return true;
@@ -3315,8 +3311,9 @@ int lra_constraint_iter;
/* True if we substituted equiv which needs checking register
allocation correctness because the equivalent value contains
- allocatiable hard registers. */
-bool lra_risky_equiv_subst_p;
+ allocatiable hard registers or when we restore multi-register
+ pseudo. */
+bool lra_risky_transformations_p;
/* Entry function of LRA constraint pass. Return true if the
constraint pass did change the code. */
@@ -3338,7 +3335,7 @@ lra_constraints (bool first_p)
("Maximum number of LRA constraint passes is achieved (%d)\n",
MAX_CONSTRAINT_ITERATION_NUMBER);
changed_p = false;
- lra_risky_equiv_subst_p = false;
+ lra_risky_transformations_p = false;
new_insn_uid_start = get_max_uid ();
new_regno_start = first_p ? lra_constraint_new_regno_start : max_reg_num ();
for (i
Re: PR testsuite/52011: add regparm to LTO/TM tests
On 01/28/2012 03:11 AM, Patrick Marlier wrote: > On 01/27/2012 11:02 AM, Aldy Hernandez wrote: >> If you all agree to remove ITM_REGPARM from libitm.h, then the tests on >> x86-32 will work. What is the status of this-- was there agreement on >> removing regparm? > > Note that I meant only for _ITM_beginTransaction. Indeed, regparm is ignored > with variadic functions. > See discussion here: > http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00933.html > http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00924.html It's ignored. It's not actively wrong. I'm for leaving it alone, actually. r~
Re: PR testsuite/52011: add regparm to LTO/TM tests
On 01/28/2012 02:14 AM, Aldy Hernandez wrote: > testsuite/ > PR testsuite/52011 > * gcc.dg/lto/trans-mem.h: New file. > * gcc.dg/lto/trans-mem-2_0.c: Include it. > * gcc.dg/lto/trans-mem-1_1.c: Same. > * gcc.dg/lto/trans-mem-4_1.c: Same. > * gcc.dg/lto/trans-mem-3_1.c: Same. Ok. r~
Re: [PATCH] Fix g++.dg/cpp0x/constexpr-rom.C failure
Ok, the option is only recognized when it is mentioned in the specs, and
neither darwin nor aix configurations have %{G*} in their CC1_SPEC, same
for osf or vms on alpha. Checked in the following as obvious.
Andreas.
2012-01-27 Andreas Schwab
* g++.dg/cpp0x/constexpr-rom.C: Don't add -G0 on *-*-darwin*
*-*-aix* alpha*-*-osf* alpha*-*-*vms*.
diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-rom.C
b/gcc/testsuite/g++.dg/cpp0x/constexpr-rom.C
index 636f0e7..5213d59 100644
--- a/gcc/testsuite/g++.dg/cpp0x/constexpr-rom.C
+++ b/gcc/testsuite/g++.dg/cpp0x/constexpr-rom.C
@@ -1,6 +1,6 @@
// PR c++/49673: check that test_data goes into .rodata
// { dg-options -std=c++0x }
-// { dg-additional-options -G0 { target alpha*-*-* frv*-*-* ia64-*-* lm32*-*-*
m32r*-*-* microblaze*-*-* mips*-*-* powerpc*-*-* rs6000*-*-* score*-*-* } }
+// { dg-additional-options -G0 { target { { alpha*-*-* frv*-*-* ia64-*-*
lm32*-*-* m32r*-*-* microblaze*-*-* mips*-*-* powerpc*-*-* rs6000*-*-*
score*-*-* } && { ! { *-*-darwin* *-*-aix* alpha*-*-osf* alpha*-*-*vms* } } } }
}
// { dg-final { scan-assembler "\\.rdata" { target mips*-*-* } } }
// { dg-final { scan-assembler "rodata" { target { { *-*-linux-gnu || *-*-elf
} && { ! mips*-*-* } } } } }
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
[pph] Add support for disabling PPH input (issue5593043)
This patch adds support for disabling PPH reads. It uses the new
support to disable PPH reading when we disable PPH writing. This is
to avoid confusion in the PPH registration code that will have some
stale content after the output file has been removed.
Lawrence suggests that we should just fail hard when we cannot
generate a PPH image. We are currently only emitting a warning. I
think I will just rip out this support in the near future. For now,
it was easier to just disable the reader. For now, I'm leaving it in
just in case we have another need for this.
2012-01-27 Diego Novillo
c-family/ChangeLog.pph
* c-common.h (pph_disable_reader): Declare.
* c-opts.c (pph_disable_reader): New.
cp/ChangeLog.pph
* pph-core.c (pph_include_handler): If PPH has been disabled,
process the file as a regular text include.
* pph-out.c (pph_disable_output): Also disable the reader.
diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h
index f8813c1..315e99e 100644
--- a/gcc/c-family/c-common.h
+++ b/gcc/c-family/c-common.h
@@ -590,6 +590,11 @@ extern const char *pph_out_file;
extern bool
pph_reader_enabled_p (void);
+/* Disable the PPH reader. */
+
+extern void
+pph_disable_reader (void);
+
/* Query for a mapping from an INCLUDE to a PPH file.
Return the filename, without ownership.
If there is no mapping, return null. */
diff --git a/gcc/c-family/c-opts.c b/gcc/c-family/c-opts.c
index 0ad27e2..ab71678 100644
--- a/gcc/c-family/c-opts.c
+++ b/gcc/c-family/c-opts.c
@@ -140,6 +140,18 @@ pph_reader_enabled_p (void)
return include_pph_mapping != NULL;
}
+
+/* Disable PPH reading. After this function is called, all subsequent
+ #include commands will be processed as textual includes. */
+
+void
+pph_disable_reader (void)
+{
+ strstrmap_destroy (include_pph_mapping);
+ include_pph_mapping = NULL;
+}
+
+
/* Add mappings from include directive to PPH files found within file FILENAME.
The file is a sequence of lines.
Each line contains the directive, followed by a tab,
diff --git a/gcc/cp/pph-core.c b/gcc/cp/pph-core.c
index 5f6c27f..760d065 100644
--- a/gcc/cp/pph-core.c
+++ b/gcc/cp/pph-core.c
@@ -784,6 +784,11 @@ pph_include_handler (cpp_reader *reader,
fprintf (pph_logfile, "%c\n", angle_brackets ? '>' : '"');
}
+ /* If PPH has been disabled, process the #include as a regular
+ text include. */
+ if (!pph_enabled_p ())
+return true;
+
/* If we find a #include_next directive in the primary file,
refuse to generate a PPH image for it. #include_next cannot
be resolved from the primary source file, so generating an
diff --git a/gcc/cp/pph-out.c b/gcc/cp/pph-out.c
index 31620e3..a1ce886 100644
--- a/gcc/cp/pph-out.c
+++ b/gcc/cp/pph-out.c
@@ -2854,6 +2854,11 @@ pph_disable_output (void)
pph_stream_close_no_flush (pph_out_stream);
pph_out_file = NULL;
pph_out_stream = NULL;
+
+ /* Also disable the reader. We are not generating a PPH image anymore,
+ so it makes no sense to keep reading images. FIXME pph, instead
+ of disabling PPH generation we may want to simply abort compilation. */
+ pph_disable_reader ();
}
#include "gt-cp-pph-out.h"
--
This patch is available for review at http://codereview.appspot.com/5593043
[committed] Use ACQ_REL __atomic_fetch_add in atomicity.h (PR libstdc++/51798)
Hi!
As reported by David, PowerPC* has been using (contrary to documentation)
__ATOMIC_ACQ_REL semantics (i.e. lwsync insn before and isync after)
__sync_fetch_and_add intrinsics, which is heavily used in libstdc++.
As this worked before, and there is no need for the strong consistency
among the __exchange_and_add and __atomic_add users, this patch
changes those to use __atomic_fetch_add with __ATOMIC_ACQ_REL, which
generates on powerpc* the same insn sequence as before, while
__sync_fetch_and_add now generates the more expensive sync insn before and
isync after.
Bootstrapped/regtested on x86_64-linux, i686-linux, s390-linux, s390x-linux,
powerpc64-linux 32-bit and 64-bit, approved in the PR by Benjamin, committed
to trunk.
2012-01-27 Jakub Jelinek
PR libstdc++/51798
* config/cpu/generic/atomicity_builtins/atomicity.h
(__exchange_and_add, __atomic_add): Use __atomic_fetch_add
with __ATOMIC_ACQ_REL semantics instead of __sync_fetch_and_add.
* include/ext/atomicity.h (__exchange_and_add, __atomic_add):
Likewise.
--- libstdc++-v3/config/cpu/generic/atomicity_builtins/atomicity.h.jj
2011-01-31 14:11:47.0 +0100
+++ libstdc++-v3/config/cpu/generic/atomicity_builtins/atomicity.h
2012-01-27 12:10:10.395649890 +0100
@@ -1,7 +1,7 @@
// Low-level functions for atomic operations: version for CPUs providing
// atomic builtins -*- C++ -*-
-// Copyright (C) 2006, 2009, 2010 Free Software Foundation, Inc.
+// Copyright (C) 2006, 2009, 2010, 2012 Free Software Foundation, Inc.
//
// This file is part of the GNU ISO C++ Library. This library is free
// software; you can redistribute it and/or modify it under the
@@ -33,12 +33,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
_Atomic_word
__attribute__ ((__unused__))
__exchange_and_add(volatile _Atomic_word* __mem, int __val) throw ()
- { return __sync_fetch_and_add(__mem, __val); }
+ { return __atomic_fetch_add(__mem, __val, __ATOMIC_ACQ_REL); }
void
__attribute__ ((__unused__))
__atomic_add(volatile _Atomic_word* __mem, int __val) throw ()
- { __sync_fetch_and_add(__mem, __val); }
+ { __atomic_fetch_add(__mem, __val, __ATOMIC_ACQ_REL); }
_GLIBCXX_END_NAMESPACE_VERSION
} // namespace
--- libstdc++-v3/include/ext/atomicity.h.jj 2011-12-01 11:45:00.0
+0100
+++ libstdc++-v3/include/ext/atomicity.h2012-01-27 12:11:09.286306232
+0100
@@ -1,6 +1,6 @@
// Support for atomic operations -*- C++ -*-
-// Copyright (C) 2004, 2005, 2006, 2008, 2009, 2010, 2011
+// Copyright (C) 2004, 2005, 2006, 2008, 2009, 2010, 2011, 2012
// Free Software Foundation, Inc.
//
// This file is part of the GNU ISO C++ Library. This library is free
@@ -45,11 +45,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
#ifdef _GLIBCXX_ATOMIC_BUILTINS
static inline _Atomic_word
__exchange_and_add(volatile _Atomic_word* __mem, int __val)
- { return __sync_fetch_and_add(__mem, __val); }
+ { return __atomic_fetch_add(__mem, __val, __ATOMIC_ACQ_REL); }
static inline void
__atomic_add(volatile _Atomic_word* __mem, int __val)
- { __sync_fetch_and_add(__mem, __val); }
+ { __atomic_fetch_add(__mem, __val, __ATOMIC_ACQ_REL); }
#else
_Atomic_word
__attribute__ ((__unused__))
Jakub
Re: [PATCH] Fix for PR51879 - Missed tail merging with non-const/pure calls
On 24/01/12 11:40, Richard Guenther wrote:
> On Mon, Jan 23, 2012 at 10:27 PM, Tom de Vries wrote:
>> Richard,
>> Jakub,
>>
>> the following patch fixes PR51879.
>>
>> Consider the following test-case:
>> ...
>> int bar (int);
>> void baz (int);
>>
>> void
>> foo (int y)
>> {
>> int a;
>> if (y == 6)
>>a = bar (7);
>> else
>>a = bar (7);
>> baz (a);
>> }
>> ...
>>
>> after compiling at -02, the representation looks like this before
>> tail-merging:
>> ...
>> # BLOCK 3 freq:1991
>> # PRED: 2 [19.9%] (true,exec)
>> # .MEMD.1714_7 = VDEF <.MEMD.1714_6(D)>
>> # USE = nonlocal
>> # CLB = nonlocal
>> aD.1709_3 = barD.1703 (7);
>> goto ;
>> # SUCC: 5 [100.0%] (fallthru,exec)
>>
>> # BLOCK 4 freq:8009
>> # PRED: 2 [80.1%] (false,exec)
>> # .MEMD.1714_8 = VDEF <.MEMD.1714_6(D)>
>> # USE = nonlocal
>> # CLB = nonlocal
>> aD.1709_4 = barD.1703 (7);
>> # SUCC: 5 [100.0%] (fallthru,exec)
>>
>> # BLOCK 5 freq:1
>> # PRED: 3 [100.0%] (fallthru,exec) 4 [100.0%] (fallthru,exec)
>> # aD.1709_1 = PHI
>> # .MEMD.1714_5 = PHI <.MEMD.1714_7(3), .MEMD.1714_8(4)>
>> # .MEMD.1714_9 = VDEF <.MEMD.1714_5>
>> # USE = nonlocal
>> # CLB = nonlocal
>> bazD.1705 (aD.1709_1);
>> # VUSE <.MEMD.1714_9>
>> return;
>> ...
>>
>> the patch allows aD.1709_4 to be value numbered to aD.1709_3, and
>> .MEMD.1714_8
>> to .MEMD.1714_7, which enables tail-merging of blocks 4 and 5.
>>
>> The patch makes sure non-const/pure call results (gimple_vdef and
>> gimple_call_lhs) are properly value numbered.
>>
>> Bootstrapped and reg-tested on x86_64.
>>
>> ok for stage1?
>
> The following cannot really work:
>
> @@ -2600,7 +2601,11 @@ visit_reference_op_call (tree lhs, gimpl
>result = vn_reference_lookup_1 (&vr1, NULL);
>if (result)
> {
> - changed = set_ssa_val_to (lhs, result);
> + tree result_vdef = gimple_vdef (SSA_NAME_DEF_STMT (result));
> + if (vdef)
> + changed |= set_ssa_val_to (vdef, result_vdef);
> + changed |= set_ssa_val_to (lhs, result);
>
> because 'result' may be not an SSA name. It might also not have
> a proper definition statement (if VN_INFO (result)->needs_insertion
> is true). So you at least need to guard things properly.
>
Right. And that also doesn't work if the function is without lhs, such as in the
new test-case pr51879-6.c.
I fixed this by storing both lhs and vdef, such that I don't have to derive
the vdef from the lhs.
> (On a side-note - I _did_ want to remove value-numbering virtual operands
> at some point ...)
>
Doing so willl hurt performance of tail-merging in its current form.
OTOH, http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51964#c0 shows that
value numbering as used in tail-merging has its limitations too.
Do you have any ideas how to address that one?
> @@ -3359,8 +3366,10 @@ visit_use (tree use)
> /* ??? We should handle stores from calls. */
> else if (TREE_CODE (lhs) == SSA_NAME)
> {
> + tree vuse = gimple_vuse (stmt);
> if (!gimple_call_internal_p (stmt)
> - && gimple_call_flags (stmt) & (ECF_PURE | ECF_CONST))
> + && (gimple_call_flags (stmt) & (ECF_PURE | ECF_CONST)
> + || (vuse && SSA_VAL (vuse) != VN_TOP)))
> changed = visit_reference_op_call (lhs, stmt);
> else
> changed = defs_to_varying (stmt);
>
> ... exactly because of the issue that a stmt has multiple defs. Btw,
> vuse should have been visited here or be part of our SCC, so, why do
> you need this check?
>
Removed now, that was a workaround for a bug in an earlier version of the patch,
that I didn't need anymore.
Bootstrapped and reg-tested on x86_64.
OK for stage1?
Thanks,
- Tom
> Thanks,
> Richard.
>
2012-01-27 Tom de Vries
PR tree-optimization/51879
* tree-ssa-sccvn.h (struct vn_reference_s): Add vdef field.
* tree-ssa-sccvn.c (visit_reference_op_call): Handle gimple_vdef.
Handle case that lhs is NULL_TREE.
(visit_use): Handle non-pure/const calls and calls without result using
visit_reference_op_call.
gcc.dg/pr51879.c: New test.
gcc.dg/pr51879-2.c: Same.
gcc.dg/pr51879-3.c: Same.
gcc.dg/pr51879-4.c: Same.
gcc.dg/pr51879-6.c: Same.
Index: gcc/tree-ssa-sccvn.c
===
--- gcc/tree-ssa-sccvn.c (revision 183325)
+++ gcc/tree-ssa-sccvn.c (working copy)
@@ -2589,27 +2589,44 @@ visit_reference_op_call (tree lhs, gimpl
{
bool changed = false;
struct vn_reference_s vr1;
- tree result;
+ vn_reference_t vnresult = NULL;
tree vuse = gimple_vuse (stmt);
+ tree vdef = gimple_vdef (stmt);
+
+ if (vdef)
+VN_INFO (vdef)->use_processed = true;
vr1.vuse = vuse ? SSA_VAL (vuse) : NULL_TREE;
vr1.operands = valueize_shared_reference_ops_from_call (stmt);
vr1.type = gimple_expr_type (stmt);
vr1.set = 0;
vr1.hashcode = v
[Patch, Fortran] PR 52022 Fix function passing for funcs returning allocatable
Dear all,
I have committed the attached patch as obvious (Rev. 183643) after
building and regtesting. I intent to backport it to 4.5 and 4.6.
Tobias
2012-01-27 Tobias Burnus
PR fortran/52022
* trans-expr.c (gfc_conv_procedure_call): Fix passing
of functions, which return allocatables.
2012-01-27 Tobias Burnus
PR fortran/52022
* gfortran.dg/dummy_procedure_7.f90: New.
Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c (Revision 183640)
+++ gcc/fortran/trans-expr.c (Arbeitskopie)
@@ -3662,7 +3662,8 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol *
|| (fsym->attr.proc_pointer
&& e->expr_type == EXPR_VARIABLE
&& gfc_is_proc_ptr_comp (e, NULL))
- || fsym->attr.allocatable))
+ || (fsym->attr.allocatable
+ && fsym->attr.flavor != FL_PROCEDURE)))
{
/* Scalar pointer dummy args require an extra level of
indirection. The null pointer already contains
Index: gcc/testsuite/gfortran.dg/dummy_procedure_7.f90
===
--- gcc/testsuite/gfortran.dg/dummy_procedure_7.f90 (Revision 0)
+++ gcc/testsuite/gfortran.dg/dummy_procedure_7.f90 (Arbeitskopie)
@@ -0,0 +1,65 @@
+! { dg-do run }
+!
+! PR fortran/52022
+!
+
+module check
+ integer, save :: icheck = 0
+end module check
+
+module t
+implicit none
+ contains
+subroutine sol(cost)
+ use check
+ interface
+function cost(p) result(y)
+double precision,dimension(:) :: p
+double precision,dimension(:),allocatable :: y
+end function cost
+ end interface
+
+ if (any (cost([1d0,2d0]) /= [2.d0, 4.d0])) call abort ()
+ icheck = icheck + 1
+end subroutine
+
+end module t
+
+module tt
+ procedure(cost1),pointer :: pcost
+contains
+ subroutine init()
+pcost=>cost1
+ end subroutine
+
+ function cost1(x) result(y)
+double precision,dimension(:) :: x
+double precision,dimension(:),allocatable :: y
+allocate(y(2))
+y=2d0*x
+ end function cost1
+
+
+
+ function cost(x) result(y)
+double precision,dimension(:) :: x
+double precision,dimension(:),allocatable :: y
+allocate(y(2))
+y=pcost(x)
+ end function cost
+end module
+
+program test
+use tt
+use t
+use check
+implicit none
+
+call init()
+if (any (cost([3.d0,7.d0]) /= [6.d0, 14.d0])) call abort ()
+if (icheck /= 0) call abort ()
+call sol(cost)
+if (icheck /= 1) call abort ()
+end program test
+
+! { dg-final { cleanup-modules "t tt check" } }
Re: adjust installation docs to discourage installing GMP, MPFR and MPC separately
On Fri, Jan 20, 2012 at 6:10 PM, Jonathan Wakely wrote: > On 20 January 2012 23:08, Quentin Neill wrote: >> >> My 2c - I heartily recommend this patch. > > Thanks. I'm a bit surprised noone else has commented - I hoped this > would be a no-brainer, or at least get some constructive feedback for > further improvement. Another +1 for this patch. Who can approve? Seems like this would be okay for stage4 too. >> May I suggest updating >> /cvs/gcc/wwwdocs/htdocs/install/prerequisites.html > That's exactly the page I'm trying to change, it's generated from the > texi file my patch changes. Didn't know that, makes sense. >> And perhaps add a page to the twiki >> http://gcc.gnu.org/wiki/BuildingGCC to catch google searches for >> "building gcc"? > > I recently added http://gcc.gnu.org/wiki/InstallingGCC > I chose "installing" not "building" because I believe that of the > people who fail to build GCC and look for support, most of them > probably should have installed a pre-built package supplied by their > OS or another third-party packager. Maybe it could be changed to > attract more search hits. Yes I saw your InstallingGCC and I like it. I was thinking a BuildingGCC would catch searches and could direct to InstallingGCC. Does MoinMoin have a way to attach keyword data to a page? Consider where InstallingGCC appears in these different results from google: ? https://www.google.com/search?q=installing+gcc <-surprised me ? http://www.google.com/search?q=building+gcc ? http://www.google.com/search?q=building+gcc+wiki #2 http://www.google.com/search?q=installing+gcc+wiki #4 http://www.google.com/search?q=building+installing+gcc Another suggestion would be to link from one or both of these: http://gcc.gnu.org/install/index.html http://gcc.gnu.org/install/build.html -- Quentin
[wwwdocs] deprecation of access declarations
Hi Gerald, 2012/1/13 Fabien Chêne : [...] >> Mind suggesting a snippet for our release notes at >> http://gcc.gnu.org/gcc-4.7/changes.html ? > > Yes, sure, thanks for suggestion. Unfortunately, my machine is > currently down, I'll get back to you when it is repaired. I get back to you for the snippet about deprecated access declarations. I would also find it sensible to advertise about the fix of c++/14258, a popular bug I have hit myself many times. OK to commit the below ? Index: gcc-4.7/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/changes.html,v retrieving revision 1.74 diff -r1.74 changes.html 396a397,405 > > As per C++98, access-declarations are now deprecated by > G++. Using-declarations are to be used instead. Furthermore, > some efforts have been made to improve the support of class > scope using declarations. In particular, using-declarations > referring to a dependent type now work as expected > ( href="http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14258";>c++/14258). > > -- Fabien
Go patch RFC: Don't mark Go executables as requiring writable stack
PR 47656 points out that Go programs are often marked as having an
executable stack. This is incorrect. Go does use trampolines, but they
are never built on the stack. They are built on the heap, using
mprotect. This is necessary because Go closures may be returned from
functions and as such must be heap allocated, not stack allocated.
Currently gcc decides that a program requires an executable stack if it
calls __builtin_init_trampoline. This turns out to be non-trivial to
change, because that function serves as a marked for LTO as well. That
is, there is currently no way for the frontend to signal that is
creating a trampoline but that it does not need an executable stack.
This patch fixes the problem by introducing a new builtin function
__builtin_init_heap_trampoline. This is a middle-end change so it is
covered under my maintainership. I also believe it is quite safe.
However, given that we are in stage 4 I would like to ask the release
managers if this is OK to put in. It fixes a user-reported bug, but the
bug is technically not a regression because it has never actually worked
correctly.
Bootstrapped and ran full testsuite on x86_64-unknown-linux-gnu. OK to
commit?
Ian
2012-01-27 Ian Lance Taylor
PR go/47656
* builtins.def (BUILT_IN_INIT_HEAP_TRAMPOLINE): Define.
* builtins.c (expand_builtin_init_trampoline): Add onstack
parameter. Change caller.
(expand_builtin): Handle BUILT_IN_INIT_HEAP_TRAMPOLINE.
* tree.c (build_common_builtin_nodes): Declare
__builtin_init_heap_trampoline.
Index: tree.c
===
--- tree.c (revision 183603)
+++ tree.c (working copy)
@@ -1,7 +1,7 @@
/* Language-independent node constructors for parse phase of GNU compiler.
Copyright (C) 1987, 1988, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010,
- 2011 Free Software Foundation, Inc.
+ 2011, 2012 Free Software Foundation, Inc.
This file is part of GCC.
@@ -9527,6 +9527,10 @@ build_common_builtin_nodes (void)
local_define_builtin ("__builtin_init_trampoline", ftype,
BUILT_IN_INIT_TRAMPOLINE,
"__builtin_init_trampoline", ECF_NOTHROW | ECF_LEAF);
+ local_define_builtin ("__builtin_init_heap_trampoline", ftype,
+ BUILT_IN_INIT_HEAP_TRAMPOLINE,
+ "__builtin_init_heap_trampoline",
+ ECF_NOTHROW | ECF_LEAF);
ftype = build_function_type_list (ptr_type_node, ptr_type_node, NULL_TREE);
local_define_builtin ("__builtin_adjust_trampoline", ftype,
Index: builtins.c
===
--- builtins.c (revision 183603)
+++ builtins.c (working copy)
@@ -1,7 +1,7 @@
/* Expand builtin functions.
Copyright (C) 1988, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
- 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011
- Free Software Foundation, Inc.
+ 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011,
+ 2012 Free Software Foundation, Inc.
This file is part of GCC.
@@ -4854,7 +4854,7 @@ round_trampoline_addr (rtx tramp)
}
static rtx
-expand_builtin_init_trampoline (tree exp)
+expand_builtin_init_trampoline (tree exp, bool onstack)
{
tree t_tramp, t_func, t_chain;
rtx m_tramp, r_tramp, r_chain, tmp;
@@ -4871,13 +4871,16 @@ expand_builtin_init_trampoline (tree exp
m_tramp = gen_rtx_MEM (BLKmode, r_tramp);
MEM_NOTRAP_P (m_tramp) = 1;
- /* The TRAMP argument should be the address of a field within the
- local function's FRAME decl. Let's see if we can fill in the
- to fill in the MEM_ATTRs for this memory. */
+ /* If ONSTACK, the TRAMP argument should be the address of a field
+ within the local function's FRAME decl. Either way, let's see if
+ we can fill in the MEM_ATTRs for this memory. */
if (TREE_CODE (t_tramp) == ADDR_EXPR)
set_mem_attributes_minus_bitpos (m_tramp, TREE_OPERAND (t_tramp, 0),
true, 0);
+ /* Creator of a heap trampoline is responsible for making sure the
+ address is aligned to at least STACK_BOUNDARY. Normally malloc
+ will ensure this anyhow. */
tmp = round_trampoline_addr (r_tramp);
if (tmp != r_tramp)
{
@@ -4897,10 +4900,13 @@ expand_builtin_init_trampoline (tree exp
/* Generate insns to initialize the trampoline. */
targetm.calls.trampoline_init (m_tramp, t_func, r_chain);
- trampolines_created = 1;
+ if (onstack)
+{
+ trampolines_created = 1;
- warning_at (DECL_SOURCE_LOCATION (t_func), OPT_Wtrampolines,
- "trampoline generated for nested function %qD", t_func);
+ warning_at (DECL_SOURCE_LOCATION (t_func), OPT_Wtrampolines,
+ "trampoline generated for nested function %qD", t_func);
+}
return const0_rtx;
}
@@ -6325,7 +6331,9 @@ expand_builtin (tree exp, rtx target, rt
return const0_rtx;
case BUILT_IN_INIT_TRAMPOLINE:
- return e
Re: Go patch RFC: Don't mark Go executables as requiring writable stack
On Fri, Jan 27, 2012 at 01:04:41PM -0800, Ian Lance Taylor wrote: > This patch fixes the problem by introducing a new builtin function > __builtin_init_heap_trampoline. This is a middle-end change so it is > covered under my maintainership. I also believe it is quite safe. > However, given that we are in stage 4 I would like to ask the release > managers if this is OK to put in. It fixes a user-reported bug, but the > bug is technically not a regression because it has never actually worked > correctly. > > Bootstrapped and ran full testsuite on x86_64-unknown-linux-gnu. OK to > commit? Looks good to me, except I wonder whether the builtin needs to be user accessible. If not, can't you throw some * or space into the name, so that the builtin is really internal to gcc? Jakub
Re: Go patch RFC: Don't mark Go executables as requiring writable stack
On 01/28/2012 08:17 AM, Jakub Jelinek wrote: > On Fri, Jan 27, 2012 at 01:04:41PM -0800, Ian Lance Taylor wrote: >> This patch fixes the problem by introducing a new builtin function >> __builtin_init_heap_trampoline. This is a middle-end change so it is >> covered under my maintainership. I also believe it is quite safe. >> However, given that we are in stage 4 I would like to ask the release >> managers if this is OK to put in. It fixes a user-reported bug, but the >> bug is technically not a regression because it has never actually worked >> correctly. >> >> Bootstrapped and ran full testsuite on x86_64-unknown-linux-gnu. OK to >> commit? > > Looks good to me, except I wonder whether the builtin needs to be user > accessible. If not, can't you throw some * or space into the name, so that > the builtin is really internal to gcc? Eh. The same could be said for the main __builtin_init_trampoline, except that realistically this new one could actually be usable. Let's not start throwing around * unless it's likely to lead to an ICE if misused. r~
Re: Go patch RFC: Don't mark Go executables as requiring writable stack
Richard Henderson writes: > On 01/28/2012 08:17 AM, Jakub Jelinek wrote: >> On Fri, Jan 27, 2012 at 01:04:41PM -0800, Ian Lance Taylor wrote: >>> This patch fixes the problem by introducing a new builtin function >>> __builtin_init_heap_trampoline. This is a middle-end change so it is >>> covered under my maintainership. I also believe it is quite safe. >>> However, given that we are in stage 4 I would like to ask the release >>> managers if this is OK to put in. It fixes a user-reported bug, but the >>> bug is technically not a regression because it has never actually worked >>> correctly. >>> >>> Bootstrapped and ran full testsuite on x86_64-unknown-linux-gnu. OK to >>> commit? >> >> Looks good to me, except I wonder whether the builtin needs to be user >> accessible. If not, can't you throw some * or space into the name, so that >> the builtin is really internal to gcc? > > Eh. The same could be said for the main __builtin_init_trampoline, > except that realistically this new one could actually be usable. > > Let's not start throwing around * unless it's likely to lead to an > ICE if misused. I started testing the version with '*', but actually I agree with RTH. There are a number of __builtin functions which are basically unusable from user code. Let's handle them coherently. I will go ahead and submit as-is unless somebody objects shortly. Ian
Re: Go patch RFC: Don't mark Go executables as requiring writable stack
On Fri, Jan 27, 2012 at 02:08:54PM -0800, Ian Lance Taylor wrote: > Richard Henderson writes: > >> Looks good to me, except I wonder whether the builtin needs to be user > >> accessible. If not, can't you throw some * or space into the name, so that > >> the builtin is really internal to gcc? > > > > Eh. The same could be said for the main __builtin_init_trampoline, > > except that realistically this new one could actually be usable. > > > > Let's not start throwing around * unless it's likely to lead to an > > ICE if misused. > > I started testing the version with '*', but actually I agree with RTH. > There are a number of __builtin functions which are basically unusable > from user code. Let's handle them coherently. > > I will go ahead and submit as-is unless somebody objects shortly. You mean commit, right? Ok then. Jakub
Re: libgo patch committed: Update to weekly.2012-01-20
Rainer Orth writes: > This patch is what I'm using for Solaris. Thanks. Committed. Ian
Re: libgo patch committed: Update to weekly.2012-01-20
Rainer Orth writes: > Fixed as follows (the comment explains why done this way). > > With that patch, I can at least link libgo.so and link a trivial Go > program. Full bootstrap with run over the weekend. Thanks. Committed. Ian
Re: [PATCH] PR c++/51641 - Lookup finds enclosing class member instead of template parameter
Jason Merrill writes:
> Comparing by same_type_p means that we treat any template parameter of
> the appropriate level and index as equivalent. But that should be OK,
> since we only have one set of level N template parameters in scope.
> So I think we should be able to just compare the level of the template
> parameter to the level of the parameters of the template. Right?
OK. I understand that just comparing levels like that is not a good
enough implementation for parameter_of_template_p in the general case.
So I removed that function and did the test inline in
binding_to_template_parms_of_scope_p instead.
Bootstrapped and tested on x86_64-unknown-linux-gnu against trunk.
gcc/cp/
PR c++/51641
* cp-tree.h (template_type_parameter_p): Declare new function.
(parameter_of_template_p): Remove
* pt.c (template_type_parameter_p): Define new function.
(parameter_of_template_p): Remove.
* name-lookup.c (binding_to_template_parms_of_scope_p): Don't rely
on parameter_of_template_p anymore. Compare the level of the
template parameter to the depth of the template.
gcc/testsuite/
PR c++/51641
* g++.dg/lookup/hidden-class17.C: New test.
---
gcc/cp/cp-tree.h |2 +-
gcc/cp/name-lookup.c | 36 -
gcc/cp/pt.c | 44 +++---
gcc/testsuite/g++.dg/lookup/hidden-class17.C | 22 +
4 files changed, 62 insertions(+), 42 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/lookup/hidden-class17.C
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index f27755e..71bca53 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -5357,10 +5357,10 @@ extern bool explicit_class_specialization_p (tree);
extern int push_tinst_level (tree);
extern void pop_tinst_level (void);
extern struct tinst_level *outermost_tinst_level(void);
-extern bool parameter_of_template_p(tree, tree);
extern void init_template_processing (void);
extern void print_template_statistics (void);
bool template_template_parameter_p (const_tree);
+bool template_type_parameter_p (const_tree);
extern bool primary_template_instantiation_p(const_tree);
extern tree get_primary_template_innermost_parameters (const_tree);
extern tree get_template_parms_at_level (tree, int);
diff --git a/gcc/cp/name-lookup.c b/gcc/cp/name-lookup.c
index 2351342..3330138 100644
--- a/gcc/cp/name-lookup.c
+++ b/gcc/cp/name-lookup.c
@@ -4466,21 +4466,39 @@ static bool
binding_to_template_parms_of_scope_p (cxx_binding *binding,
cp_binding_level *scope)
{
- tree binding_value;
+ tree binding_value, tmpl;
+ int level;
if (!binding || !scope)
return false;
binding_value = binding->value ? binding->value : binding->type;
+ /* BINDING_VALUE must be a template parm. */
+ if (binding_value == NULL_TREE
+ && (!DECL_P (binding_value)
+ || !DECL_TEMPLATE_PARM_P (binding_value)))
+return false;
- return (scope
- && scope->this_entity
- && get_template_info (scope->this_entity)
- && PRIMARY_TEMPLATE_P (TI_TEMPLATE
-(get_template_info (scope->this_entity)))
- && parameter_of_template_p (binding_value,
- TI_TEMPLATE (get_template_info \
- (scope->this_entity;
+ /* The level of BINDING_VALUE. */
+ level =
+template_type_parameter_p (binding_value)
+? TEMPLATE_PARM_LEVEL (TEMPLATE_TYPE_PARM_INDEX
+(TREE_TYPE (binding_value)))
+: TEMPLATE_PARM_LEVEL (DECL_INITIAL (binding_value));
+
+ /* The template of the current scope, iff said scope is a primary
+ template. */
+ tmpl =
+(scope
+ && scope->this_entity
+ && get_template_info (scope->this_entity)
+ && PRIMARY_TEMPLATE_P (TI_TEMPLATE (get_template_info
(scope->this_entity
+? TI_TEMPLATE (get_template_info (scope->this_entity))
+: NULL_TREE;
+
+ /* If the level of the parm BINDING_VALUE equals the depth of TMPL,
+ then BINDING_VALUE is a parameter of TMPL. */
+ return (tmpl && level == TMPL_PARMS_DEPTH (DECL_TEMPLATE_PARMS (tmpl)));
}
/* Return the innermost non-namespace binding for NAME from a scope
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index e440be7..76d09aa 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -2890,6 +2890,18 @@ template_template_parameter_p (const_tree parm)
return DECL_TEMPLATE_TEMPLATE_PARM_P (parm);
}
+/* Return true iff PARM is a DECL representing a type template
+ parameter. */
+
+bool
+template_type_parameter_p (const_tree parm)
+{
+ return (parm
+ && (TREE_CODE (parm) == TYPE_DECL
+ || TREE_CODE (parm) == TEMPLATE_DECL)
+ && DECL_TEMPLATE_P
Another merge from trunk to gccgo branch
I've merged trunk revision 183655 to the gccgo branch. Ian
[committed] invoke.texi: fix hyphenation of "floating point" and related terms
This patch addresses a similar issue to the "command line" (noun) vs
"command-line" (adjective) cleanups I dealt with in my previous patch.
In English, compound adjectives are normally hyphenated when they appear
as part of the noun phrase in a sentence as an aid to parsing. The
"command line" example given in the GCC Coding Conventions is one
specific example of this. This patch applies the same rule to "floating
point" (noun) vs "floating-point" (adjective), and likewise to some
related terms like "double precision" that showed up in many of the same
sentences/paragraphs.
I've checked in this patch as obvious. (Again, if anyone thinks these
kinds of edits are not obvious, let me know, and I'll start posting them
for review first instead.)
-Sandra
2012-01-28 Sandra Loosemore
gcc/
* doc/invoke.texi: Correct hyphenation of "floating point",
"double precision", and related terminology throughout the file.
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 183662)
+++ gcc/doc/invoke.texi (working copy)
@@ -3835,7 +3835,7 @@ that are always out of bounds. This warn
@item -Wno-div-by-zero
@opindex Wno-div-by-zero
@opindex Wdiv-by-zero
-Do not warn about compile-time integer division by zero. Floating point
+Do not warn about compile-time integer division by zero. Floating-point
division by zero is not warned about, as it can be a legitimate way of
obtaining infinities and NaNs.
@@ -3868,7 +3868,7 @@ headers---for that, @option{-Wunknown-pr
@item -Wfloat-equal
@opindex Wfloat-equal
@opindex Wno-float-equal
-Warn if floating point values are used in equality comparisons.
+Warn if floating-point values are used in equality comparisons.
The idea behind this is that sometimes it is convenient (for the
programmer) to consider floating-point values as approximations to
@@ -3912,7 +3912,7 @@ A function-like macro that appears witho
The unary plus operator.
@item
-The @samp{U} integer constant suffix, or the @samp{F} or @samp{L} floating point
+The @samp{U} integer constant suffix, or the @samp{F} or @samp{L} floating-point
constant suffixes. (Traditional C does support the @samp{L} suffix on integer
constants.) Note, these suffixes appear in macros defined in the system
headers of most modern systems, e.g.@: the @samp{_MIN}/@samp{_MAX} macros in @code{}.
@@ -3955,7 +3955,7 @@ initializer warnings and relies on defau
traditional C case.
@item
-Conversions by prototypes between fixed/floating point values and vice
+Conversions by prototypes between fixed/floating-point values and vice
versa. The absence of these prototypes when compiling with traditional
C would cause serious problems. This is a subset of the possible
conversion warnings, for the full set use @option{-Wtraditional-conversion}.
@@ -3976,7 +3976,7 @@ traditional C compatibility.
Warn if a prototype causes a type conversion that is different from what
would happen to the same argument in the absence of a prototype. This
includes conversions of fixed point to floating and vice versa, and
-conversions changing the width or signedness of a fixed point argument
+conversions changing the width or signedness of a fixed-point argument
except when the same as the default promotion.
@item -Wdeclaration-after-statement @r{(C and Objective-C only)}
@@ -6451,7 +6451,7 @@ optimization is turned on, use the @opti
@item -fmerge-constants
@opindex fmerge-constants
-Attempt to merge identical constants (string constants and floating point
+Attempt to merge identical constants (string constants and floating-point
constants) across compilation units.
This option is the default for optimized compilation if the assembler and
@@ -6466,7 +6466,7 @@ Attempt to merge identical constants and
This option implies @option{-fmerge-constants}. In addition to
@option{-fmerge-constants} this considers e.g.@: even constant initialized
-arrays or initialized constant variables with integral or floating point
+arrays or initialized constant variables with integral or floating-point
types. Languages like C or C++ require each variable, including multiple
instances of the same variable in recursive calls, to have distinct locations,
so using this option will result in non-conforming
@@ -6808,7 +6808,7 @@ If supported for the target machine, att
eliminate execution stalls due to required data being unavailable. This
helps machines that have slow floating point or memory load instructions
by allowing other instructions to be issued until the result of the load
-or floating point instruction is required.
+or floating-point instruction is required.
Enabled at levels @option{-O2}, @option{-O3}.
@@ -8066,18 +8066,18 @@ If @var{path} is specified, GCC will loo
the profile feedback data files. See @option{-fprofile-dir}.
@end table
-The following options control compiler behavior regarding floating
-point
