Go patch committed: Use backend interface for interface types
This patch to the Go frontend uses the backend interface for interface
types. Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline.
Ian
diff -r 37dae2a9c21b go/gogo-tree.cc
--- a/go/gogo-tree.cc Wed May 04 08:38:47 2011 -0700
+++ b/go/gogo-tree.cc Wed May 04 22:18:22 2011 -0700
@@ -1936,38 +1936,6 @@
return build_fold_addr_expr(decl);
}
-// Build the type of the struct that holds a slice for the given
-// element type.
-
-tree
-Gogo::slice_type_tree(tree element_type_tree)
-{
- // We use int for the count and capacity fields in a slice header.
- // This matches 6g. The language definition guarantees that we
- // can't allocate space of a size which does not fit in int
- // anyhow. FIXME: integer_type_node is the the C type "int" but is
- // not necessarily the Go type "int". They will differ when the C
- // type "int" has fewer than 32 bits.
- return Gogo::builtin_struct(NULL, "__go_slice", NULL_TREE, 3,
- "__values",
- build_pointer_type(element_type_tree),
- "__count",
- integer_type_node,
- "__capacity",
- integer_type_node);
-}
-
-// Given the tree for a slice type, return the tree for the type of
-// the elements of the slice.
-
-tree
-Gogo::slice_element_type_tree(tree slice_type_tree)
-{
- go_assert(TREE_CODE(slice_type_tree) == RECORD_TYPE
- && POINTER_TYPE_P(TREE_TYPE(TYPE_FIELDS(slice_type_tree;
- return TREE_TYPE(TREE_TYPE(TYPE_FIELDS(slice_type_tree)));
-}
-
// Build a constructor for a slice. SLICE_TYPE_TREE is the type of
// the slice. VALUES is the value pointer and COUNT is the number of
// entries. If CAPACITY is not NULL, it is the capacity; otherwise
@@ -2011,21 +1979,6 @@
return build_constructor(slice_type_tree, init);
}
-// Build a constructor for an empty slice.
-
-tree
-Gogo::empty_slice_constructor(tree slice_type_tree)
-{
- tree element_field = TYPE_FIELDS(slice_type_tree);
- tree ret = Gogo::slice_constructor(slice_type_tree,
- fold_convert(TREE_TYPE(element_field),
- null_pointer_node),
- size_zero_node,
- size_zero_node);
- TREE_CONSTANT(ret) = 1;
- return ret;
-}
-
// Build a map descriptor for a map of type MAPTYPE.
tree
diff -r 37dae2a9c21b go/gogo.h
--- a/go/gogo.h Wed May 04 08:38:47 2011 -0700
+++ b/go/gogo.h Wed May 04 22:18:22 2011 -0700
@@ -465,16 +465,6 @@
static void
mark_fndecl_as_builtin_library(tree fndecl);
- // Build the type of the struct that holds a slice for the given
- // element type.
- tree
- slice_type_tree(tree element_type_tree);
-
- // Given a tree for a slice type, return the tree for the element
- // type.
- static tree
- slice_element_type_tree(tree slice_type_tree);
-
// Build a constructor for a slice. SLICE_TYPE_TREE is the type of
// the slice. VALUES points to the values. COUNT is the size,
// CAPACITY is the capacity. If CAPACITY is NULL, it is set to
@@ -483,11 +473,6 @@
slice_constructor(tree slice_type_tree, tree values, tree count,
tree capacity);
- // Build a constructor for an empty slice. SLICE_TYPE_TREE is the
- // type of the slice.
- static tree
- empty_slice_constructor(tree slice_type_tree);
-
// Build a map descriptor.
tree
map_descriptor(Map_type*);
diff -r 37dae2a9c21b go/types.cc
--- a/go/types.cc Wed May 04 08:38:47 2011 -0700
+++ b/go/types.cc Wed May 04 22:18:22 2011 -0700
@@ -4399,6 +4399,41 @@
return this->length_tree_;
}
+// Get the backend representation of the fields of a slice. This is
+// not declared in types.h so that types.h doesn't have to #include
+// backend.h.
+//
+// We use int for the count and capacity fields. This matches 6g.
+// The language more or less assumes that we can't allocate space of a
+// size which does not fit in int.
+
+static void
+get_backend_slice_fields(Gogo* gogo, Array_type* type,
+ std::vector* bfields)
+{
+ bfields->resize(3);
+
+ Type* pet = Type::make_pointer_type(type->element_type());
+ Btype* pbet = tree_to_type(pet->get_tree(gogo));
+
+ Backend::Btyped_identifier* p = &(*bfields)[0];
+ p->name = "__values";
+ p->btype = pbet;
+ p->location = UNKNOWN_LOCATION;
+
+ Type* int_type = Type::lookup_integer_type("int");
+
+ p = &(*bfields)[1];
+ p->name = "__count";
+ p->btype = tree_to_type(int_type->get_tree(gogo));
+ p->location = UNKNOWN_LOCATION;
+
+ p = &(*bfields)[2];
+ p->name = "__capacity";
+ p->btype = tree_to_type(int_type->get_tree(gogo));
+ p->location = UNKNOWN_LOCATION;
+}
+
// Get a tree for the type of this array. A fixed array is simply
// represented as ARRAY_TYPE with the appropriate index--i.e., it is
// just like an array in C. An open array is a struct with three
@@ -4409,8 +,9 @@
{
if (this->length_ == NULL)
{
- tree struct_type = gogo->slice_type_tree(void_type_node);
- return this->fill_in_slice_tree(gogo, struct_type);
+ std::vector bfields;
+ get_backend_slice_fields(gogo, this, &b
Re: [patch] Fix DWARF so types with subprogram definitions don't get moved to type unit (issue4433068) (issue4433068)
OK. Jason
Re: [PATCH] Cleanup expand_shift
On Thu, 5 May 2011, Richard Guenther wrote: > On Wed, 4 May 2011, Richard Guenther wrote: > > On Wed, 4 May 2011, Eric Botcazou wrote: > > Hm. I guess people will scream if something breaks (I can't imagine > > what though). AAAaaarghh! Building cris-elf is now broken. > I have applied the following after re-bootstrapping and testing on > x86_64-unknown-linux-gnu and re-checking the mipsel cross testcase. > > Richard. > > 2011-05-05 Richard Guenther > > * expmed.c (expand_variable_shift): Rename to ... > (expand_shift_1): ... this. Take an expanded shift amount. > For rotates recurse directly not building trees for the shift amount. > (expand_variable_shift): Wrap around expand_shift_1. > (expand_shift): Adjust. PR 48908. brgds, H-P
Fix PR48900, powerpc duplicate __tls_get_addr calls
My fix for PR44266 using the libcall machinery to ensure we had a
proper stack frame allocated for __tls_get_addr calls sloppily used r3
as the arg to the dummy libcall. This made the call seem to depend on
whatever was in r3 previously, at least until we get to the first
split pass and the real arg is exposed. So DCE couldn't merge calls.
Even for a simple testcase like
extern __thread int i;
void foo (void) { i++; }
we get two __tls_get_addr calls if using global-dynamic tls model.
Easliy fixed by giving the dummy libcall an arg of zero. An
alternative giving slightly better -O0 code would be to say that the
libcall doesn't have any args. I chose to leave the libcall with one
arg since this is closest to the real __tls_get_addr call, and the
whole point of faking up a libcall here is to have the generic code do
whatever is necessary when making function calls. It's not totally
impossible to imagine some future ABI change that treats zero arg
calls differently from other calls.
Bootstrapped and regression tested powerpc64-linux. OK to apply
mainline, 4.6 and 4.5?
PR target/48900
* config/rs6000/rs6000.c (rs6000_legitimize_tls_address): Use
const0_rtx as the arg to the dummy __tls_get_addr libcall.
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c (revision 173464)
+++ gcc/config/rs6000/rs6000.c (working copy)
@@ -6412,10 +6412,11 @@ rs6000_legitimize_tls_address (rtx addr,
if (model == TLS_MODEL_GLOBAL_DYNAMIC)
{
- r3 = gen_rtx_REG (Pmode, 3);
tga = rs6000_tls_get_addr ();
- emit_library_call_value (tga, dest, LCT_CONST, Pmode, 1, r3, Pmode);
+ emit_library_call_value (tga, dest, LCT_CONST, Pmode,
+ 1, const0_rtx, Pmode);
+ r3 = gen_rtx_REG (Pmode, 3);
if (DEFAULT_ABI == ABI_AIX && TARGET_64BIT)
insn = gen_tls_gd_aix64 (r3, got, addr, tga, const0_rtx);
else if (DEFAULT_ABI == ABI_AIX && !TARGET_64BIT)
@@ -6432,11 +6433,12 @@ rs6000_legitimize_tls_address (rtx addr,
}
else if (model == TLS_MODEL_LOCAL_DYNAMIC)
{
- r3 = gen_rtx_REG (Pmode, 3);
tga = rs6000_tls_get_addr ();
tmp1 = gen_reg_rtx (Pmode);
- emit_library_call_value (tga, tmp1, LCT_CONST, Pmode, 1, r3, Pmode);
+ emit_library_call_value (tga, tmp1, LCT_CONST, Pmode,
+ 1, const0_rtx, Pmode);
+ r3 = gen_rtx_REG (Pmode, 3);
if (DEFAULT_ABI == ABI_AIX && TARGET_64BIT)
insn = gen_tls_ld_aix64 (r3, got, tga, const0_rtx);
else if (DEFAULT_ABI == ABI_AIX && !TARGET_64BIT)
--
Alan Modra
Australia Development Lab, IBM
[patch] Fix DWARF so types with subprogram definitions don't get moved to type unit (issue4433068) (issue4433068)
commit bf6ab23aad749d927108ace21ee01a94af31a38b
Author: Cary Coutant
Date: Mon Apr 25 13:54:19 2011 -0700
Check for classes that contain defining declarations of subprograms, and
do not move such classes into a comdat type unit.
I've updated the patch to assert that a type definition does not
contain a subprogram definition.
OK for trunk?
Tested:
Bootstrapped on x86_64, no new regressions.
gcc/ChangeLog:
2011-05-05 Cary Coutant
* dwarf2out.c (contains_subprogram_definition): New function.
(should_move_die_to_comdat): Call it.
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index fb1dd9c..a43f5f6 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -10018,6 +10018,20 @@ is_nested_in_subprogram (dw_die_ref die)
return local_scope_p (decl);
}
+/* Return non-zero if this DIE contains a defining declaration of a
+ subprogram. */
+
+static int
+contains_subprogram_definition (dw_die_ref die)
+{
+ dw_die_ref c;
+
+ if (die->die_tag == DW_TAG_subprogram && ! is_declaration_die (die))
+return 1;
+ FOR_EACH_CHILD (die, c, if (contains_subprogram_definition(c)) return 1);
+ return 0;
+}
+
/* Return non-zero if this is a type DIE that should be moved to a
COMDAT .debug_types section. */
@@ -10036,6 +10050,8 @@ should_move_die_to_comdat (dw_die_ref die)
|| get_AT (die, DW_AT_abstract_origin)
|| is_nested_in_subprogram (die))
return 0;
+ /* A type definition should never contain a subprogram definition. */
+ gcc_assert (!contains_subprogram_definition (die));
return 1;
case DW_TAG_array_type:
case DW_TAG_interface_type:
--
This patch is available for review at http://codereview.appspot.com/4433068
Re: [PATCH] Fix PR c++/48574
How about type_dependent_expression_p_push instead? Jason
Re: [PATCH, powerpc], Fix PR48857, pass/return V2DI as other vector types
On Tue, May 3, 2011 at 5:27 PM, Michael Meissner wrote: > When I added VSX support to the powerpc, I overlooked passing and return > V2DImode arguments, since the only machine operation that supports V2DI is > vector floating point conversion. Consequentally, V2DI types were passed and > returned in GPRs instead of the vector registers on power7. > > This patch fixes that so that V2DImode values are passed and returned like > other vector types. > > I did a bootstrap and make check with no regressions, comparing it to a build > without the patch. I also wrote a program that passed and returned every > single type, and I compared the assembly ouptut. With the exception of > functions that return or are passed V2DI arguments, the code is identical. I > tested: > > -m64 (implies -mabi=altivec) > -m32 -mabi=altivec > -m32 -mabi=no-altivec (no difference here) > > Is this patch ok to install? I will also want to install it in the 4.6 and > possibly 4.5 trees as well. > > [gcc] > 2011-05-03 Michael Meissner > > PR target/48857 > * config/rs6000/rs6000.h (VSX_SCALAR_MODE): Delete. > (VSX_MODE): Ditto. > (VSX_MOVE_MODE): Ditto. > (ALTIVEC_OR_VSX_VECTOR_MODE): New macro, combine all Altivec and > VSX vector types. Add V2DImode. > (HARD_REGNO_CALLER_SAVE_MODE): Use it instead of > ALTIVEC_VECTOR_MODE and VSX_VECTOR_MODE calls. > (MODES_TIEABLE_P): Ditto. > > * config/rs6000/rs6000.c (rs6000_emit_move): Use > ALTIVEC_OR_VSX_MODE instead of ALTIVEC_VECTOR_MODE and > VSX_VECTOR_MODE. > (init_cumulative_args): Ditto. > (rs6000_function_arg_boundary): Ditto. > (rs6000_function_arg_advance_1): Ditto. > (rs6000_function_arg): Ditto. > (rs6000_function_ok_for_sibcall): Ditto. > (emit_frame_save): Ditto. > (rs6000_function_value): Ditto. > (rs6000_libcall_value): Ditto. > > [gcc/testsuite] > 2011-05-03 Michael Meissner > > PR target/48857 > * gcc.target/powerpc/pr48857.c: New file, make sure V2DI arguments > are passed and returned in vector registers. The patch is okay, but please add a comment explaining why the function_value and libcall_value changes are correct. Thanks, David
Re: rs6000_handle_option global state avoidance, part 1
On Thu, May 5, 2011 at 3:34 PM, Joseph S. Myers wrote: > On Thu, 5 May 2011, Michael Eager wrote: > >> David Edelsohn wrote: >> > On Wed, May 4, 2011 at 7:54 AM, Joseph S. Myers >> > wrote: >> > >> > > Two options, -mcmodel= and -mfpu=, had cases that fell through to the >> > > next case without comments to indicate if this was intended. I added >> > > comments to make the semantics explicit. Given the documentation, it >> > > may well be intentional for -mcmodel= but is more doubtful for -mfpu=. >> > >> > I doubt that either of the fall through cases was intended. >> > >> > Alan, is mcmodel suppose to set m64? >> > >> > Michael, is mfpu suppose to set mrecip? >> >> No. There was a break statement at the end of case OPT_mfpu which >> disappeared when OPT_mrecip was added. > > Thanks. I'll apply this patch which removes the fall through, and adds > explicit Var and Init to the mfpu= entry in rs6000.opt to avoid problems > (when building as C++, as shown by a regression tester) with > 0-initialization of the field that gets automatically generated by the > .opt machinery for any Target option not using Var. > > 2011-05-05 Joseph Myers > > * config/rs6000/rs6000.c (rs6000_handle_option): Don't fall > through from -mfpu= handling. > * config/rs6000/rs6000.opt (mfpu=): Use Var and Init. Okay. The entire patch looks good with the two fall through cases corrected. Thanks, David
Re: [PATCH] Fix PR c++/48838
OK. Jason
[PATCH] Fix PR c++/48574
Hello,
This is a leftover of the fix for PR c++/48574. When
fold_non_dependent_expr sees the lvalue reference 'b' in the example
of the patch below (because in finish_call_expr,
make_args_non_dependent on 'b' calls build_non_dependent_expr which
calls null_ptr_cst_p which calls fold_non_dependent_expr), it
indirectly calls fixed_type_or_null.
The problem is that fold_non_dependent_expr unsets
processing_template_decl, so the type_dependent_expression_p test I
have added to fix PR c++/48574 returns immediately.
So this patch uses uses_template_parms instead of
type_dependent_expression_p.
Tested and bootstrapped on x86_64-unknown-linux-gnu against trunk and
4.6.
OK to commit to trunk and to 4.6?
gcc/cp/
PR c++/48574
* class.c (fixed_type_or_null): Use uses_template_parms to test if
the instance is dependent.
gcc/testsuite/
PR c++/48574
* g++.dg/template/dependent-expr8.C: New test case.
---
gcc/cp/class.c |2 +-
gcc/testsuite/g++.dg/template/dependent-expr8.C | 25 +++
2 files changed, 26 insertions(+), 1 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/template/dependent-expr8.C
diff --git a/gcc/cp/class.c b/gcc/cp/class.c
index 9af238b..6fcc3c5 100644
--- a/gcc/cp/class.c
+++ b/gcc/cp/class.c
@@ -5939,7 +5939,7 @@ fixed_type_or_null (tree instance, int *nonnull, int
*cdtorp)
itself. */
if (TREE_CODE (instance) == VAR_DECL
&& DECL_INITIAL (instance)
- && !type_dependent_expression_p (DECL_INITIAL (instance))
+ && !uses_template_parms (DECL_INITIAL (instance))
&& !htab_find (ht, instance))
{
tree type;
diff --git a/gcc/testsuite/g++.dg/template/dependent-expr8.C
b/gcc/testsuite/g++.dg/template/dependent-expr8.C
new file mode 100644
index 000..20014d6
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/dependent-expr8.C
@@ -0,0 +1,25 @@
+// Origin PR c++/48574
+// { dg-options "-std=c++0x" }
+// { dg-do compile }
+
+struct A
+{
+ virtual int foo();
+};
+
+void baz (int);
+
+template
+void
+bar(T x)
+{
+ A &b = *x;
+ baz (b.foo ());
+}
+
+void
+foo()
+{
+ A a;
+ bar(&a);
+}
--
Dodji
Re: rs6000_handle_option global state avoidance, part 1
On Thu, May 05, 2011 at 11:29:13AM -0400, David Edelsohn wrote: > Alan, is mcmodel suppose to set m64? No, that was an accident. -- Alan Modra Australia Development Lab, IBM
Re: [PATCH] Fix PR c++/48838
Jason Merrill writes:
> On 05/05/2011 03:52 PM, Dodji Seketeli wrote:
>> + if (is_overloaded_fn (fn))
>> +fn = get_first_fn (fn);
>> + else if (BASELINK_P (fn))
>
> is_overloaded_fn should be true for a BASELINK.
Correct. I should have seen that. I have bootstrapped the patch below
then.
Thanks.
gcc/cp
PR c++/48838
* cp-tree.h (non_static_member_function_p): Declare new function.
* tree.c (non_static_member_function_p): Define it.
* semantics.c (finish_call_expr): Use it.
gcc/testsuite
PR c++/48838
* g++.dg/template/member9.C: New test case.
---
gcc/cp/cp-tree.h|1 +
gcc/cp/semantics.c |3 +--
gcc/cp/tree.c | 16
gcc/testsuite/g++.dg/template/member9.C | 21 +
4 files changed, 39 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/template/member9.C
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index fcb715c..9d13393 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -5432,6 +5432,7 @@ extern tree get_fns (tree);
extern tree get_first_fn (tree);
extern tree ovl_cons (tree, tree);
extern tree build_overload (tree, tree);
+extern bool non_static_member_function_p(tree);
extern const char *cxx_printable_name (tree, int);
extern const char *cxx_printable_name_translate(tree, int);
extern tree build_exception_variant(tree, tree);
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 8bf5a52..a2b24d3 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -2039,8 +2039,7 @@ finish_call_expr (tree fn, VEC(tree,gc) **args, bool
disallow_virtual,
is not included in *ARGS even though it is considered to
be part of the list of arguments. Note that this is
related to CWG issues 515 and 1005. */
- || (((TREE_CODE (TREE_TYPE (fn)) == METHOD_TYPE)
- || BASELINK_P (fn))
+ || (non_static_member_function_p (fn)
&& current_class_ref
&& type_dependent_expression_p (current_class_ref)))
{
diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
index 3230393..d636548 100644
--- a/gcc/cp/tree.c
+++ b/gcc/cp/tree.c
@@ -1480,6 +1480,22 @@ build_overload (tree decl, tree chain)
return ovl_cons (decl, chain);
}
+/* Return TRUE if FN is a non-static member function, FALSE otherwise.
+ This function looks into BASELINK and OVERLOAD nodes. */
+
+bool
+non_static_member_function_p (tree fn)
+{
+ if (fn == NULL_TREE)
+return false;
+
+ if (is_overloaded_fn (fn))
+fn = get_first_fn (fn);
+
+ return (DECL_P (fn)
+ && DECL_NONSTATIC_MEMBER_FUNCTION_P (fn));
+}
+
#define PRINT_RING_SIZE 4
diff --git a/gcc/testsuite/g++.dg/template/member9.C
b/gcc/testsuite/g++.dg/template/member9.C
new file mode 100644
index 000..f15272d
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/member9.C
@@ -0,0 +1,21 @@
+// Origin PR c++/48838
+// { dg-do compile }
+
+class DUChainItemSystem
+{
+public:
+
+template
+void registerTypeClass();
+
+static DUChainItemSystem& self();
+};
+
+template
+struct DUChainItemRegistrator
+{
+DUChainItemRegistrator()
+{
+DUChainItemSystem::self().registerTypeClass();
+}
+};
--
Dodji
Re: [pph] Save keyed_classes, unemitted_tinfo_decls, TYPE_BINFO (issue4486042)
On 5/5/11, dnovi...@google.com wrote:
> http://codereview.appspot.com/4486042/diff/1/gcc/cp/pph-streamer.h
> File gcc/cp/pph-streamer.h (right):
>
> http://codereview.appspot.com/4486042/diff/1/gcc/cp/pph-streamer.h#newcode152
> gcc/cp/pph-streamer.h:152: for (i = 0; i < c; ++i)
> +#if 0
> +static inline void
> +pph_output_tree_array (pph_stream *stream, tree *a, size_t c, bool
> ref_p)
> +{
> + size_t i;
>
> Why are you adding this #if0 code? No apparent reason given that we
> have pph_stream_write_tree_vec.
>
> http://codereview.appspot.com/4486042/diff/1/gcc/cp/pph-streamer.h#newcode338
> gcc/cp/pph-streamer.h:338: size_t i;
> +static inline void
> +pph_input_tree_array (pph_stream *stream, tree *a, size_t c)
> +{
> + size_t i;
>
> Likewise.
The object I thought I needed was an array, not a vec. I decided
that writing that array was not helpful, and disabled the code.
I archived the tool here in case I need later.
> http://codereview.appspot.com/4486042/diff/1/gcc/cp/pph-streamer.h#newcode245
> gcc/cp/pph-streamer.h:245: tree t;
> #if 0
> +static inline void
> +pph_output_tree_VEC (pph_stream *stream, VEC(tree,gc) *v, bool ref_p)
> +{
> + tree t;
>
> Another one of the same?
>
> http://codereview.appspot.com/4486042/diff/1/gcc/cp/pph-streamer.h#newcode355
> gcc/cp/pph-streamer.h:355: size_t i;
> +#if 0
> +static inline void
> +pph_input_tree_VEC (pph_stream *stream, VEC(tree,gc) *v)
> +{
> + size_t i;
>
> Likewise.
The routines will eventually do different tasks. The writes
may be redundant but the reads are not. In particular, the use
of pph_stream_read_tree_vec overwrites the tree_vec variable.
We really want to do a merge. I can get away with the overwrite
only with the single-leading pph file. When we do more than one
PPH file, I will need something like these routines back, so these
have been archived for future code.
> http://codereview.appspot.com/4486042/
--
Lawrence Crowl
Re: rs6000_handle_option global state avoidance, part 1
On Thu, May 05, 2011 at 03:08:43PM -0400, Michael Meissner wrote: > Yes, it was an error on my part. Sorry. I will fix the GCC 4.6 branch. I > will hold off fixing the on trunk, on the assumption this patch will go in. I > can fix it if desired. I committed the following patch on the GCC 4.6 branch (GCC 4.5 and earlier is not affected): 2011-05-05 Michael Meissner * config/rs6000/rs6000.c (rs6000_handle_option): Add missing break for OPT_mfpu_ case. Index: gcc/config/rs6000/rs6000.c === --- gcc/config/rs6000/rs6000.c (revision 173455) +++ gcc/config/rs6000/rs6000.c (working copy) @@ -4630,6 +4630,7 @@ rs6000_handle_option (size_t code, const target_flags_explicit |= MASK_SOFT_FLOAT; rs6000_single_float = rs6000_double_float = 0; } + break; case OPT_mrecip: rs6000_recip_name = (value) ? "default" : "none"; -- Michael Meissner, IBM 5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA meiss...@linux.vnet.ibm.com fax +1 (978) 399-6899
Re: [pph] Save keyed_classes, unemitted_tinfo_decls, TYPE_BINFO (issue4486042)
http://codereview.appspot.com/4486042/diff/1/gcc/cp/pph-streamer.h
File gcc/cp/pph-streamer.h (right):
http://codereview.appspot.com/4486042/diff/1/gcc/cp/pph-streamer.h#newcode152
gcc/cp/pph-streamer.h:152: for (i = 0; i < c; ++i)
+#if 0
+static inline void
+pph_output_tree_array (pph_stream *stream, tree *a, size_t c, bool
ref_p)
+{
+ size_t i;
Why are you adding this #if0 code? No apparent reason given that we
have pph_stream_write_tree_vec.
http://codereview.appspot.com/4486042/diff/1/gcc/cp/pph-streamer.h#newcode245
gcc/cp/pph-streamer.h:245: tree t;
#if 0
+static inline void
+pph_output_tree_VEC (pph_stream *stream, VEC(tree,gc) *v, bool ref_p)
+{
+ tree t;
Another one of the same?
http://codereview.appspot.com/4486042/diff/1/gcc/cp/pph-streamer.h#newcode338
gcc/cp/pph-streamer.h:338: size_t i;
+static inline void
+pph_input_tree_array (pph_stream *stream, tree *a, size_t c)
+{
+ size_t i;
Likewise.
http://codereview.appspot.com/4486042/diff/1/gcc/cp/pph-streamer.h#newcode355
gcc/cp/pph-streamer.h:355: size_t i;
+#if 0
+static inline void
+pph_input_tree_VEC (pph_stream *stream, VEC(tree,gc) *v)
+{
+ size_t i;
Likewise.
http://codereview.appspot.com/4486042/
Re: [patch] Fix DWARF so types with subprogram definitions don't get moved to type unit (issue4433068)
On 05/05/2011 05:33 PM, ccout...@google.com wrote: I couldn't convince myself that a subprogram definition inside a type declaration would never happen, so I took the defensive approach. If you're confident that it can't (or shouldn't) ever happen, then what if I leave the predicate contains_subprogram_definition as is, remove the call from the condition, and instead assert that it returns false just before returning 1 from should_move_die_to_comdat? Sounds good. Jason
Re: [patch] Fix DWARF so types with subprogram definitions don't get moved to type unit (issue4433068)
It's a good check to add, but if it returns true we should abort rather than just returning 0. I couldn't convince myself that a subprogram definition inside a type declaration would never happen, so I took the defensive approach. If you're confident that it can't (or shouldn't) ever happen, then what if I leave the predicate contains_subprogram_definition as is, remove the call from the condition, and instead assert that it returns false just before returning 1 from should_move_die_to_comdat? (I have found a couple more cases where this happens in gcc 4.4.3, but they're fixed on trunk.) -cary http://codereview.appspot.com/4433068/
[pph] Save keyed_classes, unemitted_tinfo_decls, TYPE_BINFO (issue4486042)
Save and restored globals keyed_classes and unemitted_tinfo_decls.
Save and restore member TYPE_BINFO.
Index: gcc/cp/ChangeLog.pph
2011-05-05 Lawrence Crowl
* pph.c (pph_write_file_contents): Save keyed_classes and
unemitted_tinfo_decls.
(pph_read_file_contents): Restore keyed_classes and
unemitted_tinfo_decls.
* pph-streamer.h (pph_stream_write_tree_vec): Make extern.
(pph_stream_read_tree_vec): Make extern.
(pph_output_tree_array): Archive for future need.
(pph_output_tree_VEC): Archive for future need.
(pph_input_tree_array): Archive for future need.
(pph_input_tree_VEC): Archive for future need.
* pph-streamer-in.c (pph_stream_read_tree): Make extern.
(pph_stream_read_tree): Restore TYPE_BINFO.
* pph-streamer-out.c (pph_stream_write_tree_vec): Make extern.
(pph_stream_write_tree): Save TYPE_BINFO.
* name-lookup.c (pushdecl_into_namespace): Add leading comment.
Index: gcc/cp/pph.c
===
--- gcc/cp/pph.c(revision 173407)
+++ gcc/cp/pph.c(working copy)
@@ -1924,6 +1924,8 @@ pph_write_file_contents (pph_stream *str
if (flag_pph_dump_tree)
pph_dump_namespace (pph_logfile, global_namespace);
pph_output_tree (stream, global_namespace, false);
+ pph_output_tree (stream, keyed_classes, false);
+ pph_stream_write_tree_vec (stream, unemitted_tinfo_decls, false);
}
@@ -2048,6 +2050,10 @@ pph_read_file_contents (pph_stream *stre
if (flag_pph_dump_tree)
pph_dump_namespace (pph_logfile, file_ns);
pph_add_names_to_namespace (global_namespace, file_ns);
+ keyed_classes = pph_input_tree (stream);
+ unemitted_tinfo_decls = pph_stream_read_tree_vec (stream);
+ /* FIXME pph: This call replaces the tinfo, we should merge instead.
+ See pph_input_tree_VEC. */
}
Index: gcc/cp/pph-streamer-in.c
===
--- gcc/cp/pph-streamer-in.c(revision 173407)
+++ gcc/cp/pph-streamer-in.c(working copy)
@@ -226,7 +226,7 @@ pph_stream_read_ld_min (pph_stream *stre
/* Read and return a VEC of trees from STREAM. */
-static VEC(tree,gc) *
+VEC(tree,gc) *
pph_stream_read_tree_vec (pph_stream *stream)
{
unsigned i, num;
@@ -808,5 +808,13 @@ pph_stream_read_tree (struct lto_input_b
}
}
else if (TYPE_P (expr))
-pph_stream_read_lang_type (stream, expr);
+{
+ pph_stream_read_lang_type (stream, expr);
+ if (TREE_CODE (expr) == RECORD_TYPE
+ || TREE_CODE (expr) == UNION_TYPE
+ || TREE_CODE (expr) == QUAL_UNION_TYPE)
+{
+ TYPE_BINFO (expr) = pph_input_tree (stream);
+}
+}
}
Index: gcc/cp/pph-streamer-out.c
===
--- gcc/cp/pph-streamer-out.c (revision 173407)
+++ gcc/cp/pph-streamer-out.c (working copy)
@@ -265,7 +265,7 @@ pph_stream_write_ld_min (pph_stream *str
/* Write all the trees in VEC V to STREAM. REF_P is true if the trees should
be written as references. */
-static void
+void
pph_stream_write_tree_vec (pph_stream *stream, VEC(tree,gc) *v, bool ref_p)
{
unsigned i;
@@ -819,7 +819,15 @@ pph_stream_write_tree (struct output_blo
pph_output_tree_or_ref_1 (stream, tsi_stmt (i), ref_p, 3);
}
else if (TYPE_P (expr))
-pph_stream_write_lang_type (stream, expr, ref_p);
+{
+ pph_stream_write_lang_type (stream, expr, ref_p);
+ if (TREE_CODE (expr) == RECORD_TYPE
+ || TREE_CODE (expr) == UNION_TYPE
+ || TREE_CODE (expr) == QUAL_UNION_TYPE)
+{
+ pph_output_tree_or_ref_1 (stream, TYPE_BINFO (expr), ref_p, 3);
+}
+}
}
Index: gcc/cp/pph-streamer.h
===
--- gcc/cp/pph-streamer.h (revision 173407)
+++ gcc/cp/pph-streamer.h (working copy)
@@ -103,6 +103,8 @@ void pph_stream_trace_bitpack (pph_strea
/* In pph-streamer-out.c. */
void pph_stream_flush_buffers (pph_stream *);
+void pph_stream_write_tree_vec (pph_stream *stream, VEC(tree,gc) *v,
+bool ref_p);
void pph_stream_init_write (pph_stream *);
void pph_stream_write_tree (struct output_block *, tree, bool ref_p);
void pph_stream_pack_value_fields (struct bitpack_d *, tree);
@@ -117,6 +119,7 @@ struct binding_table_s *pph_stream_read_
/* In pph-streamer-in.c. */
void pph_stream_init_read (pph_stream *);
+VEC(tree,gc) *pph_stream_read_tree_vec (pph_stream *stream);
void pph_stream_read_tree (struct lto_input_block *, struct data_in *, tree);
void pph_stream_unpack_value_fields (struct bitpack_d *, tree);
tree pph_stream_alloc_tree (enum tree_code, struct lto_input_block *,
@@ -138,6 +141,23 @@ pph_output_tree (pph_stream *stream, tre
lto_output_tree (stream->ob, t, ref_p);
}
+/* Output array A of cardinality C of ASTs to STR
[graphite] Merge from trunk
Hi, I just merged the changes from trunk into the graphite branch: 2010-05-05 Sebastian Pop * Merge from mainline (170411:173446).
Re: rs6000_handle_option global state avoidance, part 1
Joseph S. Myers wrote: On Thu, 5 May 2011, Michael Eager wrote: David Edelsohn wrote: On Wed, May 4, 2011 at 7:54 AM, Joseph S. Myers wrote: Two options, -mcmodel= and -mfpu=, had cases that fell through to the next case without comments to indicate if this was intended. I added comments to make the semantics explicit. Given the documentation, it may well be intentional for -mcmodel= but is more doubtful for -mfpu=. I doubt that either of the fall through cases was intended. Alan, is mcmodel suppose to set m64? Michael, is mfpu suppose to set mrecip? No. There was a break statement at the end of case OPT_mfpu which disappeared when OPT_mrecip was added. Thanks. I'll apply this patch which removes the fall through, and adds explicit Var and Init to the mfpu= entry in rs6000.opt to avoid problems (when building as C++, as shown by a regression tester) with 0-initialization of the field that gets automatically generated by the .opt machinery for any Target option not using Var. Looks good. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [PATCH, powerpc], Fix PR48857, pass/return V2DI as other vector types
Hello!
> In this case, GCC wasn't following the ABI. My patch will have GCC follow the
> ABI. The XL compiler also follows the ABI. So we have to decide whether to
> keep the current calling sequence which violates the ABI, or change the
> compiler to follow the ABI, and break backwards compatiblity.
>
> Given the machine doesn't have native VD2Imode operations, except for
> conversion to/from floating point, and the bitwise operations, I suspect not
> to
> many people use the data type. Note, V2DImode was added in GCC 4.5 when the
> VSX support was added. It was not in the earlier Altivec support.
IMO, the compiler should emit a note in this case, something like
[unfortunately, many...] examples in i386.c:
static bool warned;
if (!warned && warn_psabi)
{
warned = true;
inform (input_location,
"the ABI of passing struct with"
" a flexible array member has"
" changed in GCC 4.4");
}
Uros.
Re: [PATCH] Fix PR c++/48838
On 05/05/2011 03:52 PM, Dodji Seketeli wrote: + if (is_overloaded_fn (fn)) +fn = get_first_fn (fn); + else if (BASELINK_P (fn)) is_overloaded_fn should be true for a BASELINK. Jason
Re: [Patch, Fortran] -std=f2008tr, TR 29113 and OPTIONAL arguments with BIND(C)
Build and regtested on x86-64-linux
OK for the trunk?
I forgot to include a run-time test case. Find one attached.
Tobias
! { dg-do run }
! { dg-additional-sources bind_c_usage_24_c.c }
!
! PR fortran/48858
! PR fortran/48820
!
! TR 29113: BIND(C) with OPTIONAL
!
module m
use iso_c_binding
interface
subroutine c_proc (is_present, var) bind(C)
import
logical(c_bool), value:: is_present
integer(c_int), optional :: var
end subroutine
end interface
contains
subroutine subtest (is_present, var) bind(C)
logical(c_bool), intent(in),value:: is_present
integer(c_int), intent(inout), optional :: var
if (is_present) then
if (.not. present (var)) call abort ()
if (var /= 43) call abort ()
var = -45
else
if (present (var)) call abort ()
end if
end subroutine subtest
end module m
program test
use m
implicit none
integer :: val
val = 4
call c_proc (.false._c_bool)
call c_proc (.true._c_bool, val)
if (val /= 7) call abort ()
end program test
! { dg-final { cleanup-modules "m" } }
/* Compiled and linked by bind_c.f90. */
#include
void subtest (_Bool, int *);
void
c_proc (_Bool present, int *val)
{
int val2;
if (!present && val)
abort ();
else if (present)
{
if (!val) abort ();
if (*val != 4) abort ();
*val = 7;
}
val2 = 43;
subtest (1, &val2);
subtest (0, NULL);
if (val2 != -45) abort ();
}
minor C++ PATCH to REFERENCE_REF_P
While working on something else I noticed that REFERENCE_REF_P was being
clobbered by stabilize_expr, so this patch changes it to just use the
type rather than a lang_flag.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit f24566a2f2594c7d4c7d7d3e26a4341d87deaec6
Author: Jason Merrill
Date: Thu May 5 13:14:47 2011 -0400
* cp-tree.h (REFERENCE_REF_P): Just check the type.
* cvt.c (convert_from_reference): Adjust.
* pt.c (build_non_dependent_expr): Adjust.
* semantics.c (finish_offsetof): Adjust.
* tree.c (lvalue_kind): Use it.
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 961581e..fcb715c 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -62,7 +62,6 @@ c-common.h, not after.
STMT_EXPR_NO_SCOPE (in STMT_EXPR)
BIND_EXPR_TRY_BLOCK (in BIND_EXPR)
TYPENAME_IS_ENUM_P (in TYPENAME_TYPE)
- REFERENCE_REF_P (in INDIRECT_EXPR)
QUALIFIED_NAME_IS_TEMPLATE (in SCOPE_REF)
OMP_FOR_GIMPLIFYING_P (in OMP_FOR)
BASELINK_QUALIFIED_P (in BASELINK)
@@ -2781,9 +2780,12 @@ extern void decl_shadowed_for_var_insert (tree, tree);
(LANG_DECL_FN_CHECK (FUNCTION_DECL_CHECK (NODE)) \
->u.saved_language_function)
-/* Indicates an indirect_expr is for converting a reference. */
-#define REFERENCE_REF_P(NODE) \
- TREE_LANG_FLAG_0 (INDIRECT_REF_CHECK (NODE))
+/* True if NODE is an implicit INDIRECT_EXPR from convert_from_reference. */
+#define REFERENCE_REF_P(NODE) \
+ (TREE_CODE (NODE) == INDIRECT_REF\
+ && TREE_TYPE (TREE_OPERAND (NODE, 0)) \
+ && (TREE_CODE (TREE_TYPE (TREE_OPERAND ((NODE), 0)))\
+ == REFERENCE_TYPE))
#define NEW_EXPR_USE_GLOBAL(NODE) \
TREE_LANG_FLAG_0 (NEW_EXPR_CHECK (NODE))
diff --git a/gcc/cp/cvt.c b/gcc/cp/cvt.c
index 64fe871..db4ea46 100644
--- a/gcc/cp/cvt.c
+++ b/gcc/cp/cvt.c
@@ -520,7 +520,6 @@ convert_from_reference (tree val)
TREE_THIS_VOLATILE (ref) = CP_TYPE_VOLATILE_P (t);
TREE_SIDE_EFFECTS (ref)
= (TREE_THIS_VOLATILE (ref) || TREE_SIDE_EFFECTS (val));
- REFERENCE_REF_P (ref) = 1;
val = ref;
}
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index b56ab1f..d109e1b 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -18918,7 +18918,7 @@ build_non_dependent_expr (tree expr)
/* Keep dereferences outside the NON_DEPENDENT_EXPR so lvalue_kind
doesn't need to look inside. */
- if (TREE_CODE (expr) == INDIRECT_REF && REFERENCE_REF_P (expr))
+ if (REFERENCE_REF_P (expr))
return convert_from_reference (build_non_dependent_expr
(TREE_OPERAND (expr, 0)));
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 815824a..8bf5a52 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -3428,7 +3428,7 @@ finish_offsetof (tree expr)
error ("cannot apply % to member function %qD", expr);
return error_mark_node;
}
- if (TREE_CODE (expr) == INDIRECT_REF && REFERENCE_REF_P (expr))
+ if (REFERENCE_REF_P (expr))
expr = TREE_OPERAND (expr, 0);
return fold_offsetof (expr, NULL_TREE);
}
diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
index 9a6e26d..3230393 100644
--- a/gcc/cp/tree.c
+++ b/gcc/cp/tree.c
@@ -61,9 +61,7 @@ lvalue_kind (const_tree ref)
INDIRECT_REFs. INDIRECT_REFs are just internal compiler
representation, not part of the language, so we have to look
through them. */
- if (TREE_CODE (ref) == INDIRECT_REF
- && TREE_CODE (TREE_TYPE (TREE_OPERAND (ref, 0)))
- == REFERENCE_TYPE)
+ if (REFERENCE_REF_P (ref))
return lvalue_kind (TREE_OPERAND (ref, 0));
if (TREE_TYPE (ref)
Re: [PATCH] Fix PR c++/48838
Jason Merrill writes:
> I think using get_first_fn could make non_static_member_function_p a
> lot shorter.
Like this?
Tested like the previous patch.
gcc/cp
PR c++/48838
* cp-tree.h (non_static_member_function_p): Declare new function.
* tree.c (non_static_member_function_p): Define it.
* semantics.c (finish_call_expr): Use it.
gcc/testsuite
PR c++/48838
* g++.dg/template/member9.C: New test case.
---
gcc/cp/cp-tree.h|1 +
gcc/cp/semantics.c |3 +--
gcc/cp/tree.c | 19 +++
gcc/testsuite/g++.dg/template/member9.C | 21 +
4 files changed, 42 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/template/member9.C
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 961581e..d694e25 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -5430,6 +5430,7 @@ extern tree get_fns (tree);
extern tree get_first_fn (tree);
extern tree ovl_cons (tree, tree);
extern tree build_overload (tree, tree);
+extern bool non_static_member_function_p(tree);
extern const char *cxx_printable_name (tree, int);
extern const char *cxx_printable_name_translate(tree, int);
extern tree build_exception_variant(tree, tree);
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 815824a..baa8fd4 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -2039,8 +2039,7 @@ finish_call_expr (tree fn, VEC(tree,gc) **args, bool
disallow_virtual,
is not included in *ARGS even though it is considered to
be part of the list of arguments. Note that this is
related to CWG issues 515 and 1005. */
- || (((TREE_CODE (TREE_TYPE (fn)) == METHOD_TYPE)
- || BASELINK_P (fn))
+ || (non_static_member_function_p (fn)
&& current_class_ref
&& type_dependent_expression_p (current_class_ref)))
{
diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
index 0f2f86c..6115951 100644
--- a/gcc/cp/tree.c
+++ b/gcc/cp/tree.c
@@ -1482,6 +1482,25 @@ build_overload (tree decl, tree chain)
return ovl_cons (decl, chain);
}
+/* Return TRUE if FN is a non-static member function, FALSE otherwise.
+ This function looks into BASELINK and OVERLOAD nodes. */
+
+bool
+non_static_member_function_p (tree fn)
+{
+ if (fn == NULL_TREE)
+return false;
+
+ if (is_overloaded_fn (fn))
+fn = get_first_fn (fn);
+ else if (BASELINK_P (fn))
+return (TREE_TYPE (fn)
+ && TREE_CODE (TREE_TYPE (fn)) == METHOD_TYPE);
+
+ return (DECL_P (fn)
+ && DECL_NONSTATIC_MEMBER_FUNCTION_P (fn));
+}
+
#define PRINT_RING_SIZE 4
diff --git a/gcc/testsuite/g++.dg/template/member9.C
b/gcc/testsuite/g++.dg/template/member9.C
new file mode 100644
index 000..f15272d
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/member9.C
@@ -0,0 +1,21 @@
+// Origin PR c++/48838
+// { dg-do compile }
+
+class DUChainItemSystem
+{
+public:
+
+template
+void registerTypeClass();
+
+static DUChainItemSystem& self();
+};
+
+template
+struct DUChainItemRegistrator
+{
+DUChainItemRegistrator()
+{
+DUChainItemSystem::self().registerTypeClass();
+}
+};
--
Dodji
[PATCH, Ada] PR ada/47818 - Pragma Assert rejected with No_Implementation_Pragmas restriction
Hello,
Compilation of code containing pragma Assert fails if restriction
No_Implementation_Pragmas is used, even with -gnat2005 or -gnat2012
flags:
% cat test.adb
pragma Restrictions(No_Implementation_Pragmas);
procedure test(I : Integer) is
begin
pragma Assert(I /= 1);
null;
end;
% gcc -c test.adb -gnat2005
test.adb:5:03: violation of restriction "no_implementation_pragmas" at line 1
Source file gcc/ada/sem_prag.adb contains correct check for Pragma_Assert
(Ada_2005_Pragma). But this pragma is then rewritten as pragma Check and
restrictions (GNAT_Pragma) are tested again. This test fails and causes
compilation error.
The patch was tested on x86_64, applied to trunk.
Regards,
Eugeniy Meshcheryakov
2011-05-05 Eugeniy Meshcheryakov
PR ada/47818
* sem_prag.adb (Pragma_Check): Don't check restrictions on rewritten
pragma Assert.
2011-05-05 Eugeniy Meshcheryakov
PR ada/47818
* gnat.dg/pragma_assert.adb: New.
diff --git a/gcc/ada/sem_prag.adb b/gcc/ada/sem_prag.adb
index fd509c4..b5bae50 100644
--- a/gcc/ada/sem_prag.adb
+++ b/gcc/ada/sem_prag.adb
@@ -6477,7 +6477,16 @@ package body Sem_Prag is
-- Set True if category of assertions referenced by Name enabled
begin
-GNAT_Pragma;
+-- This could be a rewritten pragma Assert. If it is the case
+-- then don't check restrictions, because they are different for
+-- pragma Assert and were already checked.
+
+if Nkind (Original_Node (N)) /= N_Pragma
+ or else Pragma_Name (Original_Node (N)) /= Name_Assert
+then
+ GNAT_Pragma;
+end if;
+
Check_At_Least_N_Arguments (2);
Check_At_Most_N_Arguments (3);
Check_Optional_Identifier (Arg1, Name_Name);
diff --git a/gcc/testsuite/gnat.dg/pragma_assert.adb
b/gcc/testsuite/gnat.dg/pragma_assert.adb
new file mode 100644
index 000..4bda0a0
--- /dev/null
+++ b/gcc/testsuite/gnat.dg/pragma_assert.adb
@@ -0,0 +1,10 @@
+-- {dg-do compile}
+-- {dg-options -gnat05}
+pragma Restrictions (No_Implementation_Pragmas);
+
+procedure Pragma_Assert is
+ X : Integer;
+begin
+ X := 1;
+ pragma Assert (X = 1);
+end Pragma_Assert;
signature.asc
Description: Digital signature
Re: [google] improves option mismatch handling for LIPO (issue4479045)
On Thu, May 5, 2011 at 01:36, David Li wrote:
> This patch improves cross module option mismatch handling in LIPO mode --
> will be commited to google/main.
>
> 1) Remove duplicates in the option list before comparison;
> 2) Force module incompatiblity when two modules disagree in -fexceptions
> setting. In LIPO mode, when option mismatch is discovered between the primary
> and aux module, a warning message is emitted, but the modules will be
> considered incompatible when -fripa-disallow-opt-mismatch is specified. With
> this change, exception option mismatch will force the primary module to
> reject the aux module.
>
> Tested: SPEC with LIPO.
>
>
> 2011-05-04 David Li
>
> * coverage.c (incompatible_cl_args): Better handling
> of option mismatch.
>
> Index: coverage.c
> ===
> --- coverage.c (revision 173353)
> +++ coverage.c (working copy)
> @@ -213,6 +213,27 @@ is_last_module (unsigned mod_id)
> return (mod_id == module_infos[num_in_fnames - 1]->ident);
> }
>
> +/* String hash function */
> +
> +static hashval_t
> +str_hash (const void *p)
> +{
> + const char *s = (const char *)p;
> + return htab_hash_string (s);
> +}
You can use htab_hash_string directly. No need to wrap it further.
OK with those changes.
Diego.
Re: rs6000_handle_option global state avoidance, part 1
On Thu, 5 May 2011, Michael Eager wrote: > David Edelsohn wrote: > > On Wed, May 4, 2011 at 7:54 AM, Joseph S. Myers > > wrote: > > > > > Two options, -mcmodel= and -mfpu=, had cases that fell through to the > > > next case without comments to indicate if this was intended. I added > > > comments to make the semantics explicit. Given the documentation, it > > > may well be intentional for -mcmodel= but is more doubtful for -mfpu=. > > > > I doubt that either of the fall through cases was intended. > > > > Alan, is mcmodel suppose to set m64? > > > > Michael, is mfpu suppose to set mrecip? > > No. There was a break statement at the end of case OPT_mfpu which > disappeared when OPT_mrecip was added. Thanks. I'll apply this patch which removes the fall through, and adds explicit Var and Init to the mfpu= entry in rs6000.opt to avoid problems (when building as C++, as shown by a regression tester) with 0-initialization of the field that gets automatically generated by the .opt machinery for any Target option not using Var. 2011-05-05 Joseph Myers * config/rs6000/rs6000.c (rs6000_handle_option): Don't fall through from -mfpu= handling. * config/rs6000/rs6000.opt (mfpu=): Use Var and Init. Index: gcc/config/rs6000/rs6000.opt === --- gcc/config/rs6000/rs6000.opt(revision 173434) +++ gcc/config/rs6000/rs6000.opt(working copy) @@ -492,7 +492,7 @@ Target RejectNegative Var(rs6000_simple_ Floating point unit does not support divide & sqrt mfpu= -Target RejectNegative Joined Enum(fpu_type_t) +Target RejectNegative Joined Enum(fpu_type_t) Var(rs6000_fpu_type) Init(FPU_NONE) -mfpu= Specify FP (sp, dp, sp-lite, dp-lite) (implies -mxilinx-fpu) Enum Index: gcc/config/rs6000/rs6000.c === --- gcc/config/rs6000/rs6000.c (revision 173434) +++ gcc/config/rs6000/rs6000.c (working copy) @@ -4480,7 +4480,7 @@ rs6000_handle_option (struct gcc_options opts_set->x_target_flags |= MASK_SOFT_FLOAT; opts->x_rs6000_single_float = opts->x_rs6000_double_float = 0; } - /* Fall through. */ + break; case OPT_mrecip: opts->x_rs6000_recip_name = (value) ? "default" : "none"; -- Joseph S. Myers jos...@codesourcery.com
Re: [PATCH, powerpc], Fix PR48857, pass/return V2DI as other vector types
On Wed, May 04, 2011 at 11:33:43AM +0200, Richard Guenther wrote: > On Wed, May 4, 2011 at 4:51 AM, David Edelsohn wrote: > > What does this do to the ABI? Haven't we now broken the ABI and > > broken backwards compatibility? > > It at least looks like so. You need to add appropriate changes.html > entries to all branches you apply this patch to. I suppose the new > version matches what XLC does? Yes. I will do that if the patch is approved. As I said in my other reply, the patch will make us compatible with XLC. -- Michael Meissner, IBM 5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA meiss...@linux.vnet.ibm.com fax +1 (978) 399-6899
Re: [PATCH, powerpc], Fix PR48857, pass/return V2DI as other vector types
On Tue, May 03, 2011 at 10:51:51PM -0400, David Edelsohn wrote: > What does this do to the ABI? Haven't we now broken the ABI and > broken backwards compatibility? In this case, GCC wasn't following the ABI. My patch will have GCC follow the ABI. The XL compiler also follows the ABI. So we have to decide whether to keep the current calling sequence which violates the ABI, or change the compiler to follow the ABI, and break backwards compatiblity. Given the machine doesn't have native VD2Imode operations, except for conversion to/from floating point, and the bitwise operations, I suspect not to many people use the data type. Note, V2DImode was added in GCC 4.5 when the VSX support was added. It was not in the earlier Altivec support. The MODES_TIEABLE_P part of the patch will need to go in to fix PR 48495 (it was in looking at the bug we discovered that the compiler was not following the ABI). -- Michael Meissner, IBM 5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA meiss...@linux.vnet.ibm.com fax +1 (978) 399-6899
rs6000_handle_option global state avoidance, part 2
This patch continues work on avoiding global state in
rs6000_handle_option by cleaning up the handling of -mabi= options.
The part using global state, a test for TARGET_SPE_ABI, is moved to
rs6000_option_override_internal (so now testing the state after all
options are applied). The -mabi= option is really several separate
options, setting different variables, and so is most naturally
represented as multiple options in the .opt file (instead of one
option using Enum). This patch represents it that way in the .opt
file; the only option handler code now needed for these options is to
make -mabi=altivec and -mabi=spe override each other, because all the
other semantics can be described directly in the .opt file.
Tested building cc1 and xgcc for cross to powerpc-eabi. Will commit
to trunk in the absence of target maintainer objections.
2011-05-05 Joseph Myers
* config/rs6000/rs6000.opt (rs6000_ieeequad, rs6000_altivec_abi,
rs6000_spe_abi, rs6000_darwin64_abi): Remove TargetVariable
entries.
(mabi=): Replace with separate entries for mabi=altivec,
mabi=no-altivec, mabi=spe, mabi=no-spe, mabi=d64, mabi=d32,
mabi=ieeelongdouble and mabi=ibmlongdouble.
* config/rs6000/rs6000.c (rs6000_option_override_internal): Move
check for -mabi=spe without SPE ABI support here.
(rs6000_handle_option): Replace OPT_mabi_ handling with
OPT_mabi_altivec and OPT_mabi_spe handling.
Index: gcc/config/rs6000/rs6000.opt
===
--- gcc/config/rs6000/rs6000.opt(revision 173434)
+++ gcc/config/rs6000/rs6000.opt(working copy)
@@ -47,22 +47,6 @@ enum rs6000_dependence_cost rs6000_sched
TargetVariable
enum rs6000_nop_insertion rs6000_sched_insert_nops = sched_finish_none
-;; IEEE quad extended precision long double.
-TargetVariable
-unsigned char rs6000_ieeequad
-
-;; Nonzero to use AltiVec ABI.
-TargetVariable
-unsigned char rs6000_altivec_abi
-
-;; Nonzero if we want SPE ABI extensions.
-TargetVariable
-unsigned char rs6000_spe_abi
-
-;; Nonzero if we want Darwin's struct-by-value-in-regs ABI.
-TargetVariable
-unsigned char rs6000_darwin64_abi
-
;; Non-zero to allow overriding loop alignment.
TargetVariable
unsigned char can_override_loop_align
@@ -385,9 +369,37 @@ mdebug=
Target RejectNegative Joined
-mdebug= Enable debug output
-mabi=
-Target RejectNegative Joined
--mabi= Specify ABI to use
+mabi=altivec
+Target RejectNegative Var(rs6000_altivec_abi) Save
+Use the AltiVec ABI extensions
+
+mabi=no-altivec
+Target RejectNegative Var(rs6000_altivec_abi, 0)
+Do not use the AltiVec ABI extensions
+
+mabi=spe
+Target RejectNegative Var(rs6000_spe_abi) Save
+Use the SPE ABI extensions
+
+mabi=no-spe
+Target RejectNegative Var(rs6000_spe_abi, 0)
+Do not use the SPE ABI extensions
+
+; These are here for testing during development only, do not document
+; in the manual please.
+
+; If we want Darwin's struct-by-value-in-regs ABI.
+mabi=d64
+Target RejectNegative Undocumented Warn(using darwin64 ABI)
Var(rs6000_darwin64_abi) Save
+
+mabi=d32
+Target RejectNegative Undocumented Warn(using old darwin ABI)
Var(rs6000_darwin64_abi, 0)
+
+mabi=ieeelongdouble
+Target RejectNegative Undocumented Warn(using IEEE extended precision long
double) Var(rs6000_ieeequad) Save
+
+mabi=ibmlongdouble
+Target RejectNegative Undocumented Warn(using IBM extended precision long
double) Var(rs6000_ieeequad, 0)
mcpu=
Target RejectNegative Joined
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c (revision 173434)
+++ gcc/config/rs6000/rs6000.c (working copy)
@@ -2665,6 +2665,11 @@ rs6000_option_override_internal (bool gl
warning (0, "-malign-power is not supported for 64-bit Darwin;"
" it is incompatible with the installed C and C++ libraries");
+ if (global_options_set.x_rs6000_spe_abi
+ && rs6000_spe_abi
+ && !TARGET_SPE_ABI)
+error ("not configured for SPE ABI");
+
/* Numerous experiment shows that IRA based loop pressure
calculation works better for RTL loop invariant motion on targets
with enough (>= 32) registers. It is an expensive optimization.
@@ -4340,65 +4345,13 @@ rs6000_handle_option (struct gcc_options
break;
#endif
-case OPT_mabi_:
- if (!strcmp (arg, "altivec"))
- {
- opts_set->x_rs6000_altivec_abi = true;
- opts->x_rs6000_altivec_abi = 1;
-
- /* Enabling the AltiVec ABI turns off the SPE ABI. */
- opts->x_rs6000_spe_abi = 0;
- }
- else if (! strcmp (arg, "no-altivec"))
- {
- opts_set->x_rs6000_altivec_abi = true;
- opts->x_rs6000_altivec_abi = 0;
- }
- else if (! strcmp (arg, "spe"))
- {
- opts_set->x_rs6000_spe_abi = true;
- opts->x_rs6000_spe_abi = 1;
- opts->x_rs6000_altivec_abi = 0;
- if (!
Re: [google][RFA] add extra text to stack frame warnings (issue4479046)
On Thu, May 5, 2011 at 11:47 AM, Diego Novillo wrote: >> OK for google/main? Is there a reason why this cannot be an option that someone passes on the command line of GCC instead of a configure option? Also can you show an example of why this message would be changed? Thanks, Andrew Pinski
[Patch,Fortran] Minor libcaf cleanup
Changes:
- Remove (not working) critical functions; a normal coarray of LOCK type
should be used instead. (Stub left in until it is removed the the front
end.)
- Added prototypes and stub implementations for
registering/deregistering coarray (currently unused).
- Small bug fixes.
OK for the trunk?
Tobias
2011-05-05 Tobias Burnus
PR fortran/18918
* caf/libcaf.h: Cleanup headers.
(_gfortran_caf_critical, _gfortran_caf_end_critical): Make stub.
(caf_register_t): New enum.
(_gfortran_caf_register, _gfortran_caf_deregister): New prototype.
* caf/single.c (_gfortran_caf_critical,
_gfortran_caf_end_critical): Remove.
(_gfortran_caf_register, _gfortran_caf_deregister): New functions.
* caf/mpi.c (_gfortran_caf_critical,
_gfortran_caf_end_critical): Remove.
(_gfortran_caf_register, _gfortran_caf_deregister): New functions.
(caf_world_window): Remove global variable.
(_gfortran_caf_init): Fix off-by-one error of this_image.
diff --git a/libgfortran/caf/libcaf.h b/libgfortran/caf/libcaf.h
index 8a66ef3..7b19f0d 100644
--- a/libgfortran/caf/libcaf.h
+++ b/libgfortran/caf/libcaf.h
@@ -27,8 +27,9 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
#ifndef LIBCAF_H
#define LIBCAF_H
-#include
-#include
+#include /* For int32_t. */
+#include /* For ptrdiff_t. */
+
/* Definitions of the Fortran 2008 standard; need to kept in sync with
ISO_FORTRAN_ENV, cf. libgfortran.h. */
@@ -38,16 +39,32 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
#define STAT_STOPPED_IMAGE 3
+typedef enum caf_register_t {
+ CAF_REGTYPE_COARRAY,
+ CAF_REGTYPE_LOCK,
+ CAF_REGTYPE_LOCK_COMP
+}
+caf_register_t;
+
+
void _gfortran_caf_init (int *, char ***, int *, int *);
void _gfortran_caf_finalize (void);
+void * _gfortran_caf_register (ptrdiff_t, caf_register_t, void **);
+int _gfortran_caf_deregister (void **);
+
+
int _gfortran_caf_sync_all (char *, int);
-int _gfortran_caf_sync_images (int count, int images[], char *, int);
+int _gfortran_caf_sync_images (int, int[], char *, int);
+
+/* FIXME: The CRITICAL functions should be removed;
+ the functionality is better represented using Coarray's lock feature. */
+void _gfortran_caf_critical (void) { }
+void _gfortran_caf_end_critical (void) { }
-void _gfortran_caf_critical (void);
-void _gfortran_caf_end_critical (void);
-void _gfortran_caf_error_stop_str (const char *, int32_t) __attribute__ ((noreturn));
+void _gfortran_caf_error_stop_str (const char *, int32_t)
+ __attribute__ ((noreturn));
void _gfortran_caf_error_stop (int32_t) __attribute__ ((noreturn));
#endif /* LIBCAF_H */
diff --git a/libgfortran/caf/mpi.c b/libgfortran/caf/mpi.c
index 9e4db91..9b7bb33 100644
--- a/libgfortran/caf/mpi.c
+++ b/libgfortran/caf/mpi.c
@@ -27,8 +27,10 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
#include "libcaf.h"
#include
#include
+#include /* For memcpy. */
#include
+
/* Define GFC_CAF_CHECK to enable run-time checking. */
/* #define GFC_CAF_CHECK 1 */
@@ -39,7 +41,6 @@ static void error_stop (int error) __attribute__ ((noreturn));
static int caf_mpi_initialized;
static int caf_this_image;
static int caf_num_images;
-static MPI_Win caf_world_window;
/* Initialize coarray program. This routine assumes that no other
@@ -58,13 +59,9 @@ _gfortran_caf_init (int *argc, char ***argv, int *this_image, int *num_images)
MPI_Init (argc, argv);
MPI_Comm_rank (MPI_COMM_WORLD, &caf_this_image);
- *this_image = caf_this_image + 1;
+ *this_image = ++caf_this_image;
MPI_Comm_size (MPI_COMM_WORLD, &caf_num_images);
*num_images = caf_num_images;
-
- /* Obtain window for CRITICAL section locking. */
- MPI_Win_create (NULL, 0, 1, MPI_INFO_NULL, MPI_COMM_WORLD,
- &caf_world_window);
}
@@ -73,13 +70,28 @@ _gfortran_caf_init (int *argc, char ***argv, int *this_image, int *num_images)
void
_gfortran_caf_finalize (void)
{
- MPI_Win_free (&caf_world_window);
-
if (!caf_mpi_initialized)
MPI_Finalize ();
}
+void *
+_gfortran_caf_register (ptrdiff_t size,
+caf_register_t type __attribute__ ((unused)),
+void **token)
+{
+ *token = NULL;
+ return malloc (size);
+}
+
+
+int
+_gfortran_caf_deregister (void **token __attribute__ ((unused)))
+{
+ return 0;
+}
+
+
/* SYNC ALL - the return value matches Fortran's STAT argument. */
int
@@ -156,22 +168,6 @@ _gfortran_caf_sync_images (int count, int images[], char *errmsg,
}
-/* CRITICAL BLOCK. */
-
-void
-_gfortran_caf_critical (void)
-{
- MPI_Win_lock (MPI_LOCK_SHARED, 0, 0, caf_world_window);
-}
-
-
-void
-_gfortran_caf_end_critical (void)
-{
- MPI_Win_unlock (0, caf_world_window);
-}
-
-
/* ERROR STOP the other images. */
static void
diff --git a/libgfortran/caf/single.c b/libgfortran/caf/single.c
index 7ee37b3..c5c66b4 100644
--- a/libgfortran/caf/single.c
+++ b/libgfortran/caf/single.c
@@ -26,16 +26,16 @@ s
Re: rs6000_handle_option global state avoidance, part 1
On Thu, May 05, 2011 at 10:08:24AM -0700, Michael Eager wrote: > David Edelsohn wrote: > >On Wed, May 4, 2011 at 7:54 AM, Joseph S. Myers > >wrote: > > > >>Two options, -mcmodel= and -mfpu=, had cases that fell through to the > >>next case without comments to indicate if this was intended. I added > >>comments to make the semantics explicit. Given the documentation, it > >>may well be intentional for -mcmodel= but is more doubtful for -mfpu=. > > > >I doubt that either of the fall through cases was intended. > > > >Alan, is mcmodel suppose to set m64? > > > >Michael, is mfpu suppose to set mrecip? > > No. There was a break statement at the end of case OPT_mfpu which > disappeared when OPT_mrecip was added. Yes, it was an error on my part. Sorry. I will fix the GCC 4.6 branch. I will hold off fixing the on trunk, on the assumption this patch will go in. I can fix it if desired. -- Michael Meissner, IBM 5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA meiss...@linux.vnet.ibm.com fax +1 (978) 399-6899
Re: [google][RFA] add extra text to stack frame warnings (issue4479046)
On Thu, May 5, 2011 at 14:27, Chris Demetriou wrote: > Diego, > > I know this is a truly horrible and broken way to do this, but alternatives > (e.g., NLS) don't really work for us. > > bootstrapped without new configuration (x86-64 ubuntu lucid, didn't bother > to run tests), bootstrapped with option (x86-64 ubuntu lucid, with full > tests, no regressions). Manually tested that the resulting warning > looks right, too. > > > OK for google/main? > > > chris > --- > [gcc/ChangeLog.google-main] > 2011-05-05 Chris Demetriou > > * doc/install.texi (--with-warn-frame-larger-than-extra-text): New. > * configure.ac (--with-warn-frame-larger-than-extra-text): New. > (WARN_FRAME_LARGER_THAN_EXTRA_TEXT): Define. > * final.c (final_start_function): Use > WARN_FRAME_LARGER_THAN_EXTRA_TEXT. > * configure: Regenerate. > * config.in: Regenerate. Do we want in google/integration maybe? Or do you see this going to trunk? OK for either, in any case. Just decide where you think it's best to have. Diego.
Re: Committed: fd_truncate test-cases updated for recent libgfortran changes
> Date: Thu, 5 May 2011 19:36:47 +0300 > From: Janne Blomqvist > On Thu, May 5, 2011 at 00:52, Hans-Peter Nilsson > wrote: > > This time, it happened in 173155:173168. > > > > Usually, there's also a brief question whether all changes were > > intended, or perhaps that some of the regressing tests (here: > > gfortran.dg/fmt_cache_1.f and gfortran.dg/ftell_3.f90) were not > > really supposed to have raw_truncate called. So, should they? > > I don't know; If you cared to bisect, that would help. There's nothing to bisect, there was just one big libgfortran change in the range I mentioned, one you should already know about. :) > These issues > tend to fly under the radar as most developers have ftruncate() > present. Maybe some script hack running the testsuite under strace() > and cross-checking for the presence of "target fd_truncate" might do > on "normal" targets, but I haven't looked into it. I wouldn't say that this needs any priority, but I like the idea of a portion of an I/O-library checking regression in the number of syscalls using strace (pruning the startup and finish for obvious reasons). > > Two of the test-cases, gfortran.dg/endfile_3.f90 and > > gfortran.dg/endfile_4.f90 actually pass, which seems wrong, as > > raw_truncate after emitting the error message returns an error > > indication (so, the test-program should abort or return an error > > AFAICT). Perhaps due to lack of error handling in the > > call-chain to raw_truncate? Ignore that, I missed the dg-shouldfail:s. Or at most note that dg-shouldfail should be improved to actually look for its argument in order to distinguish between the expected failure message and others. Right now it "accepts" any failure. brgds, H-P
[google][RFA] add extra text to stack frame warnings (issue4479046)
Diego,
I know this is a truly horrible and broken way to do this, but alternatives
(e.g., NLS) don't really work for us.
bootstrapped without new configuration (x86-64 ubuntu lucid, didn't bother
to run tests), bootstrapped with option (x86-64 ubuntu lucid, with full
tests, no regressions). Manually tested that the resulting warning
looks right, too.
OK for google/main?
chris
---
[gcc/ChangeLog.google-main]
2011-05-05 Chris Demetriou
* doc/install.texi (--with-warn-frame-larger-than-extra-text): New.
* configure.ac (--with-warn-frame-larger-than-extra-text): New.
(WARN_FRAME_LARGER_THAN_EXTRA_TEXT): Define.
* final.c (final_start_function): Use
WARN_FRAME_LARGER_THAN_EXTRA_TEXT.
* configure: Regenerate.
* config.in: Regenerate.
Index: gcc/doc/install.texi
===
--- gcc/doc/install.texi(revision 173353)
+++ gcc/doc/install.texi(working copy)
@@ -1707,6 +1707,10 @@
See @option{-canonical-prefixes} or @option{-no-canonical-prefixes} for
more details, including how to override this configuration option when
compiling.
+
+@item --with-warn-frame-larger-than-extra-text=@var{text}
+Append @samp{@var{text}} to frame size warnings generated by
+the @option{-Wframe-larger-than} warning flag.
@end table
@subheading Cross-Compiler-Specific Options
Index: gcc/final.c
===
--- gcc/final.c (revision 173353)
+++ gcc/final.c (working copy)
@@ -1576,9 +1576,13 @@
if (warn_frame_larger_than
&& get_frame_size () > frame_larger_than_size)
{
- /* Issue a warning */
+ /* Issue a warning. (WARN_FRAME_LARGER_THAN_EXTRA_TEXT is
+ provided by configuration. The way extra text is added
+ here may prevent localization from working properly.
+ It's totally broken.) */
warning (OPT_Wframe_larger_than_,
- "the frame size of %wd bytes is larger than %wd bytes",
+ "the frame size of %wd bytes is larger than %wd bytes"
+ WARN_FRAME_LARGER_THAN_EXTRA_TEXT,
get_frame_size (), frame_larger_than_size);
}
Index: gcc/configure.ac
===
--- gcc/configure.ac(revision 173353)
+++ gcc/configure.ac(working copy)
@@ -4951,6 +4951,20 @@
fi
+warn_frame_larger_than_extra_text=
+AC_ARG_WITH(warn-frame-larger-than-extra-text,
+[ --with-warn-frame-larger-than-extra-text=TEXT
+ specifies extra text for frame size warnings],
+[case "${withval}" in
+yes) AC_MSG_ERROR(bad value ${withval} given for frame size warning text) ;;
+no);;
+*) warn_frame_larger_than_extra_text="$withval" ;;
+esac])
+AC_DEFINE_UNQUOTED(WARN_FRAME_LARGER_THAN_EXTRA_TEXT,
+ "$warn_frame_larger_than_extra_text",
+ [Define to be extra text for frame size warnings.])
+
+
# Configure the subdirectories
# AC_CONFIG_SUBDIRS($subdirs)
--
This patch is available for review at http://codereview.appspot.com/4479046
Re: newlib vs. libiberty mismatch breaks build (Re: [PATCH] Export psignal on all platforms)
IIRC there's a compile-time way to test for prototypes at least.
Re: [PATCH 2/4] Docs: extend.texi: Remove trailing blanks from lines
On Thu, May 5, 2011 at 09:32, Richard Guenther wrote: > And yes, in "harm" I mostly refer to svn blame annoyances and to > patch/branch merge conflicts where context that causes the conflict > only changed in whitespace. Your tools are limiting the quality of your work. Are we not the toolmakers?
Re: Committed: fd_truncate test-cases updated for recent libgfortran changes
On May 5, 2011, at 9:36 AM, Janne Blomqvist wrote: > The testsuite uses the process return value to determine > success, right? But which values exactly constitute success > vs. failure? 0 is success, and != 0 is failure.
Re: newlib vs. libiberty mismatch breaks build (Re: [PATCH] Export psignal on all platforms)
DJ Delorie wrote: > No, we've always hard-coded what newlib does to avoid the link > problems. I think we should continue with that for now. > > I suspect we need to AC_DEFINE(HAVE_PSIGNAL) Corinna Vinschen had the same suggestion: > Sorry about that. I guess that should have been something along the > lines of > > AC_DEFINE(HAVE_PSIGNAL,1,[Define if you have psignal]) Just so I understand correctly: adding this AC_DEFINE would *always* define HAVE_PSIGNAL when configuring libiberty with --with-newlib, and thus libiberty would never export psignal. This would of course be fine when building against current newlib head, because that does provide psignal. However, when building against some older newlib version, we still wouldn't get psignal from libiberty, and therefore not have it available at all, right? [ Maybe this would be just fine. GCC for example never calls psignal anyway ... ] If we do add AC_DEFINE(psignal), shouldn't we then also add AC_DEFINE(strsignal), since this is also provided by newlib (and having strsignal from libiberty but psignal from newlib, using two potentially different lists of signal names, would seem to be just wierd ...)? Thanks, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE ulrich.weig...@de.ibm.com
Re: Libiberty: POSIXify psignal definition
On Thu, May 5, 2011 at 12:54 AM, Corinna Vinschen wrote: > On May 5 00:40, Andrew Pinski wrote: >> On Thu, May 5, 2011 at 12:30 AM, Corinna Vinschen >> wrote: >> > Thanks, >> > Corinna >> > >> > >> > * strsignal.c (psignal): Change second parameter to const char *. >> > Fix comment accordingly. >> >> >> I don't think this is needed. What goes wrong without it? > > It's not about need, it's about correctness. It collides with the new, > POSIXly correct declaration of psignal in newlib/libc/include/signal.h. But this could should not show up if psignal is declared. So it should not matter if it collides with that declaration. Thanks, Andrew Pinski
Re: rs6000_handle_option global state avoidance, part 1
David Edelsohn wrote:
On Wed, May 4, 2011 at 7:54 AM, Joseph S. Myers wrote:
Two options, -mcmodel= and -mfpu=, had cases that fell through to the
next case without comments to indicate if this was intended. I added
comments to make the semantics explicit. Given the documentation, it
may well be intentional for -mcmodel= but is more doubtful for -mfpu=.
I doubt that either of the fall through cases was intended.
Alan, is mcmodel suppose to set m64?
Michael, is mfpu suppose to set mrecip?
No. There was a break statement at the end of case OPT_mfpu which
disappeared when OPT_mrecip was added.
The rest of the patch looks like a faithful translation.
Thanks, David
#if defined (HAVE_LD_LARGE_TOC) && defined (TARGET_USES_LINUX64_OPT)
case OPT_mcmodel_:
- if (strcmp (arg, "small") == 0)
- rs6000_current_cmodel = CMODEL_SMALL;
- else if (strcmp (arg, "medium") == 0)
- rs6000_current_cmodel = CMODEL_MEDIUM;
- else if (strcmp (arg, "large") == 0)
- rs6000_current_cmodel = CMODEL_LARGE;
- else
- {
- error ("invalid option for -mcmodel: '%s'", arg);
- return false;
- }
- rs6000_explicit_options.cmodel = true;
+ /* Fall through. */
#endif
#ifdef TARGET_USES_AIX64_OPT
@@ -4261,9 +4224,9 @@ rs6000_handle_option (struct gcc_options
#else
case OPT_m64:
#endif
- target_flags |= MASK_POWERPC64 | MASK_POWERPC;
- target_flags |= ~target_flags_explicit & MASK_PPC_GFXOPT;
- target_flags_explicit |= MASK_POWERPC64 | MASK_POWERPC;
+ opts->x_target_flags |= MASK_POWERPC64 | MASK_POWERPC;
+ opts->x_target_flags |= ~opts_set->x_target_flags & MASK_PPC_GFXOPT;
+ opts_set->x_target_flags |= MASK_POWERPC64 | MASK_POWERPC;
break;
case OPT_mfpu_:
- fpu_type = rs6000_parse_fpu_option(arg);
- if (fpu_type != FPU_NONE)
- /* If -mfpu is not none, then turn off SOFT_FLOAT, turn on HARD_FLOAT. */
- {
-target_flags &= ~MASK_SOFT_FLOAT;
-target_flags_explicit |= MASK_SOFT_FLOAT;
-rs6000_xilinx_fpu = 1;
-if (fpu_type == FPU_SF_LITE || fpu_type == FPU_SF_FULL)
-rs6000_single_float = 1;
-if (fpu_type == FPU_DF_LITE || fpu_type == FPU_DF_FULL)
- rs6000_single_float = rs6000_double_float = 1;
-if (fpu_type == FPU_SF_LITE || fpu_type == FPU_DF_LITE)
- rs6000_simple_fpu = 1;
- }
+ fpu_type = (enum fpu_type_t) value;
+ if (fpu_type != FPU_NONE)
+ {
+ /* If -mfpu is not none, then turn off SOFT_FLOAT, turn on
+HARD_FLOAT. */
+ opts->x_target_flags &= ~MASK_SOFT_FLOAT;
+ opts_set->x_target_flags |= MASK_SOFT_FLOAT;
+ opts->x_rs6000_xilinx_fpu = 1;
+ if (fpu_type == FPU_SF_LITE || fpu_type == FPU_SF_FULL)
+ opts->x_rs6000_single_float = 1;
+ if (fpu_type == FPU_DF_LITE || fpu_type == FPU_DF_FULL)
+ opts->x_rs6000_single_float = opts->x_rs6000_double_float = 1;
+ if (fpu_type == FPU_SF_LITE || fpu_type == FPU_DF_LITE)
+ opts->x_rs6000_simple_fpu = 1;
+ }
else
- {
-/* -mfpu=none is equivalent to -msoft-float */
-target_flags |= MASK_SOFT_FLOAT;
-target_flags_explicit |= MASK_SOFT_FLOAT;
-rs6000_single_float = rs6000_double_float = 0;
- }
+ {
+ /* -mfpu=none is equivalent to -msoft-float. */
+ opts->x_target_flags |= MASK_SOFT_FLOAT;
+ opts_set->x_target_flags |= MASK_SOFT_FLOAT;
+ opts->x_rs6000_single_float = opts->x_rs6000_double_float = 0;
+ }
+ /* Fall through. */
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [google] Patch to support calling multi-versioned functions via new GCC builtin. (issue4440078)
On Thu, May 5, 2011 at 2:16 AM, Richard Guenther
wrote:
> On Thu, May 5, 2011 at 12:19 AM, Xinliang David Li wrote:
>>>
>>> I can think of some more-or-less obvious high-level forms, one would
>>> for example simply stick a new DISPATCH tree into gimple_call_fn
>>> (similar to how we can have OBJ_TYPE_REF there), the DISPATCH
>>> tree would be of variable length, first operand the selector function
>>> and further operands function addresses. That would keep the
>>> actual call visible (instead of a fake __builtin_dispatch call), something
>>> I'd really like to see.
>>
>> This sounds like a good long term solution.
>
> Thinking about it again maybe, similar to OBJ_TYPE_REF, have the
> selection itself lowered and only keep the set of functions as
> additional info. Thus instead of having the selector function as
> first operand have a pointer to the selected function there (that also
> avoids too much knowledge about the return value of the selector).
> Thus,
>
> sel = selector ();
> switch (sel)
> {
> case A: fn = &bar;
> case B: fn = &foo;
> }
> val = (*DISPATCH (fn, bar, foo)) (...);
>
> that way regular optimizations can apply to the selection, eventually
> discard the dispatch if fn becomes a known direct function (similar
> to devirtualization). At expansion time the call address is simply
> taken from the first operand and an indirect call is assembled.
>
> Does the above still provide enough knowledge for the IPA path isolation?
>
I like your original proposal (extending call) better because related
information are tied together and is easier to hoist and clean up.
I want propose a more general solution.
1) Generic Annotation Support for gcc IR -- it is used attach to
application/optimization specific annotation to gimple statements and
annotations can be passed around across passes. In gcc, I only see
HISTOGRAM annotation for value profiling, which is not general enough
2) Support of CallInfo for each callsite. This is an annotation, but
more standardized. The callinfo can be used to record information such
as call attributes, call side effects, mod-ref information etc ---
current gimple_call_flags can be folded into this Info structure.
Similarly (not related to this discussion), LoopInfo structure can be
introduced to annotate loop back edge jumps to allow FE to pass useful
information at loop level. For floating pointer operations, things
like the precision constraint, sensitivity to floating environment etc
can be recorded in FPInfo.
T
>>> Restricting ourselves to use the existing target attribute at the
>>> beginning (with a single, compiler-generated selector function)
>>> is probably good enough to get a prototype up and running.
>>> Extending it to arbitrary selector-function, value pairs using a
>>> new attribute is then probably easy (I don't see the exact use-case
>>> for that yet, but I suppose it exists if you say so).
>>
>> For the use cases, CPU model will be looked at instead of just the
>> core architecture -- this will give use more information about the
>> numbrer of cores, size of caches etc. Intel's runtime library does
>> this checkiing at start up time so that the multi-versioned code can
>> look at those and make the appropriate decisions.
>>
>> It will be even more complicated for arm processors -- which can have
>> the same processor cores but configured differently w.r.t VFP, NEON
>> etc.
>
> Ah, indeed. I hadn't thought about the tuning for different variants
> as opposed to enabling HW features. So the interface for overloading
> would be sth like
>
> enum X { Foo = 0, Bar = 5 };
>
> enum X select () { return Bar; }
>
> void foo (void) __attribute__((dispatch(select, Bar)));
>
Yes, for overloading -- something like this looks good.
Thanks,
David
Re: newlib vs. libiberty mismatch breaks build (Re: [PATCH] Export psignal on all platforms)
> You don't mean the prototype, do you? IMHO the char * should still be > changed to const char * to adhere to POSIX. So far, it's served as a good tool for detecting when libiberty's configure isn't doing its job :-) At this point, we should avoid "fixing" it until the newlib/configure issue is fixed, otherwise the problem will get hidden away again. If, after that, you want to posixify libiberty some more, we'll worry about it then.
Re: newlib vs. libiberty mismatch breaks build (Re: [PATCH] Export psignal on all platforms)
No, we've always hard-coded what newlib does to avoid the link problems. I think we should continue with that for now. I suspect we need to AC_DEFINE(HAVE_PSIGNAL)
Re: newlib vs. libiberty mismatch breaks build (Re: [PATCH] Export psignal on all platforms)
On May 5 18:44, Ulrich Weigand wrote: > DJ Delorie wrote: > > > I don't know how to avoid this problem in configure, other than by adding > > > AC_LIBOBJ([psignal]). > > > > Right, the correct solution is - libiberty shouldn't provide psignal > > if newlib does. Making it match newlib is the wrong solution. > > I guess I agree, but the problem is exactly how to implement "if newlib > does" ... Usually, this would be a link test, which libiberty configure > deliberately avoids for cross-builds, so it hardcodes "what newlib does". > Do you suggest we should do the link test after all, or make the hard- > coded newlib capability list somehow dynamic (depending on what)? > > Maybe I'm missing something, but I don't understand the AC_LIBOBJ suggestion. Sorry about that. I guess that should have been something along the lines of AC_DEFINE(HAVE_PSIGNAL,1,[Define if you have psignal]) Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat
Re: newlib vs. libiberty mismatch breaks build (Re: [PATCH] Export psignal on all platforms)
On May 5 11:29, DJ Delorie wrote: > > > I don't know how to avoid this problem in configure, other than by adding > > AC_LIBOBJ([psignal]). > > Right, the correct solution is - libiberty shouldn't provide psignal > if newlib does. Making it match newlib is the wrong solution. You don't mean the prototype, do you? IMHO the char * should still be changed to const char * to adhere to POSIX. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat
Re: newlib vs. libiberty mismatch breaks build (Re: [PATCH] Export psignal on all platforms)
DJ Delorie wrote: > > I don't know how to avoid this problem in configure, other than by adding > > AC_LIBOBJ([psignal]). > > Right, the correct solution is - libiberty shouldn't provide psignal > if newlib does. Making it match newlib is the wrong solution. I guess I agree, but the problem is exactly how to implement "if newlib does" ... Usually, this would be a link test, which libiberty configure deliberately avoids for cross-builds, so it hardcodes "what newlib does". Do you suggest we should do the link test after all, or make the hard- coded newlib capability list somehow dynamic (depending on what)? Maybe I'm missing something, but I don't understand the AC_LIBOBJ suggestion. This would add "psignal.o" to the list of object files to be linked into libiberty. But: 1.) there is no psignal.o / psignal.c in libiberty, but the symbol psignal is defined within strsignal.c; and 2.) strsignal.o is already added unconditionally to the list of libiberty objects ... [ But even if we *did* split psignal into its own object file, that would still not answer the question of when to link it in and when not. ] Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE ulrich.weig...@de.ibm.com
Re: Committed: fd_truncate test-cases updated for recent libgfortran changes
On Thu, May 5, 2011 at 00:52, Hans-Peter Nilsson wrote: > Once or twice a year some regression results from changed I/O > in libgfortran, such that some existing test-case starts > calling libgfortran/io/unix.c:raw_truncate, which on > limited-I/O-bare-iron targets will emit "required ftruncate or > chsize support not present" and fail. After a while, I get to > it and commit a patch such as the following, updating the > regressing tests and new ones I spot in gfortran.log with the > self-marked line above. This time, it happened in 173155:173168. > > Usually, there's also a brief question whether all changes were > intended, or perhaps that some of the regressing tests (here: > gfortran.dg/fmt_cache_1.f and gfortran.dg/ftell_3.f90) were not > really supposed to have raw_truncate called. So, should they? I don't know; If you cared to bisect, that would help. These issues tend to fly under the radar as most developers have ftruncate() present. Maybe some script hack running the testsuite under strace() and cross-checking for the presence of "target fd_truncate" might do on "normal" targets, but I haven't looked into it. > Two of the test-cases, gfortran.dg/endfile_3.f90 and > gfortran.dg/endfile_4.f90 actually pass, which seems wrong, as > raw_truncate after emitting the error message returns an error > indication (so, the test-program should abort or return an error > AFAICT). Perhaps due to lack of error handling in the > call-chain to raw_truncate? This seems strange. AFAICT raw_truncate returns -1 in that case only to shut the compiler up, because runtime_error() should never return. However, runtime_error() calls sys_exit() (both in runtime/error.c) which makes the process kill itself either via kill(getpid(), SIGQUIT); /* BTW, why not just raise(SIGQUIT)?? */ or exit(code); where in this case code==2. Perhaps this makes the testsuite believe that the testcase ran successfully? The testsuite uses the process return value to determine success, right? But which values exactly constitute success vs. failure? For comparison, normally testcases fail by calling the ABORT subroutine, which calls abort() => process return value 134. For kill/raise(SIGQUIT), return value is 131. and for exit(2), obviously, the return value is 2. Anything in the above that looks like a smoking gun? > Anyway, committed as obvious. Thanks. -- Janne Blomqvist
Re: copy_tree_r and STATEMENT_LIST (was Re: C++ PATCHes relating to c++/48834, c++/40975 (array new))
On 05/05/2011 07:09 AM, Jason Merrill wrote: > No, but the rationale isn't documented. It was added by the patch > that introduced STATEMENT_LIST, > > http://gcc.gnu.org/ml/gcc-patches/2003-11/msg00879.html > > but doesn't appear in the ChangeLog entry. I notice that in that > patch unsave_r copied STATEMENT_LIST, but now it doesn't. rth, do you > happen to remember why you put it there? No, I don't recall. I suspect that I put that in there while testing in order to determine if I needed to support copying statement lists, and it turned out that I didn't. r~
Re: [PATCH] don't use build_function_type in the ObjC/C++ frontends
On May 4, 2011, at 8:17 PM, Nathan Froyd wrote: > The last remaining uses of build_function_type in the ObjC/C++ frontends > comes from this pattern: > OK to commit? Ok. >
[Ada] Fix ICE on assignment of aggregate with discriminated record type
This is PR ada/48844, a regression present on the mainline and 4.6 branch.
The compiler aborts on an assignment of an aggregate to another object, if the
nominal subtype of the former is a discriminated record type with a variant
part for which the variants all have the same size and one of the variant
contains a component whose type is tagged or controlled. It is trying to
create a temporary for a VIEW_CONVERT_EXPR and the type doesn't allow it.
Fixed by not generating the VIEW_CONVERT_EXPR in the first place.
Tested on i586-suse-linux, applied on the mainline and 4.6 branch.
2011-05-05 Eric Botcazou
PR ada/48844
* gcc-interface/gigi.h (get_variant_part): Declare.
* gcc-interface/decl.c (get_variant_part): Make global.
* gcc-interface/utils2.c (find_common_type): Do not return T1 if the
types have the same constant size, are record types and T1 has a
variant part while T2 doesn't.
2011-05-05 Eric Botcazou
* gnat.dg/discr29.ad[sb]: New test.
* gnat.dg/discr30.adb: Likewise.
--
Eric Botcazou
Index: gcc-interface/decl.c
===
--- gcc-interface/decl.c (revision 173422)
+++ gcc-interface/decl.c (working copy)
@@ -177,7 +177,6 @@ static void check_ok_for_atomic (tree, E
static tree create_field_decl_from (tree, tree, tree, tree, tree,
VEC(subst_pair,heap) *);
static tree get_rep_part (tree);
-static tree get_variant_part (tree);
static tree create_variant_part_from (tree, VEC(variant_desc,heap) *, tree,
tree, VEC(subst_pair,heap) *);
static void copy_and_substitute_in_size (tree, tree, VEC(subst_pair,heap) *);
@@ -8509,7 +8508,7 @@ get_rep_part (tree record_type)
/* Return the variant part of RECORD_TYPE, if any. Otherwise return NULL. */
-static tree
+tree
get_variant_part (tree record_type)
{
tree field;
Index: gcc-interface/utils2.c
===
--- gcc-interface/utils2.c (revision 173422)
+++ gcc-interface/utils2.c (working copy)
@@ -193,15 +193,21 @@ find_common_type (tree t1, tree t2)
calling into build_binary_op), some others are really expected and we
have to be careful. */
- /* We must prevent writing more than what the target may hold if this is for
+ /* We must avoid writing more than what the target can hold if this is for
an assignment and the case of tagged types is handled in build_binary_op
- so use the lhs type if it is known to be smaller, or of constant size and
- the rhs type is not, whatever the modes. We also force t1 in case of
+ so we use the lhs type if it is known to be smaller or of constant size
+ and the rhs type is not, whatever the modes. We also force t1 in case of
constant size equality to minimize occurrences of view conversions on the
- lhs of assignments. */
+ lhs of an assignment, except for the case of record types with a variant
+ part on the lhs but not on the rhs to make the conversion simpler. */
if (TREE_CONSTANT (TYPE_SIZE (t1))
&& (!TREE_CONSTANT (TYPE_SIZE (t2))
- || !tree_int_cst_lt (TYPE_SIZE (t2), TYPE_SIZE (t1
+ || tree_int_cst_lt (TYPE_SIZE (t1), TYPE_SIZE (t2))
+ || (TYPE_SIZE (t1) == TYPE_SIZE (t2)
+ && !(TREE_CODE (t1) == RECORD_TYPE
+ && TREE_CODE (t2) == RECORD_TYPE
+ && get_variant_part (t1) != NULL_TREE
+ && get_variant_part (t2) == NULL_TREE
return t1;
/* Otherwise, if the lhs type is non-BLKmode, use it. Note that we know
Index: gcc-interface/gigi.h
===
--- gcc-interface/gigi.h (revision 173422)
+++ gcc-interface/gigi.h (working copy)
@@ -150,6 +150,9 @@ extern tree choices_to_gnu (tree operand
extern void annotate_object (Entity_Id gnat_entity, tree gnu_type, tree size,
bool by_ref, bool by_double_ref);
+/* Return the variant part of RECORD_TYPE, if any. Otherwise return NULL. */
+extern tree get_variant_part (tree record_type);
+
/* Given a type T, a FIELD_DECL F, and a replacement value R, return a new
type with all size expressions that contain F updated by replacing F
with R. If F is NULL_TREE, always make a new RECORD_TYPE, even if
package body Discr29 is
procedure Proc (R : out Rec3) is
begin
R := (False, Tmp);
end;
end Discr29;
-- { dg-do compile }
package Discr29 is
type Rec1 is record
I1 : Integer;
I2 : Integer;
I3 : Integer;
end record;
type Rec2 is tagged record
I1 : Integer;
I2 : Integer;
end record;
type Rec3 (D : Boolean) is record
case D is
when True => A : Rec1;
when False => B : Rec2;
end case;
end record;
procedure Proc (R : out Rec3);
Tmp : Rec2;
end Discr29;
-- PR ada/48844
-- Reported by Georg Bauhaus */
-- { dg-do compile }
procedure Discr30 is
generic
type Source is priva
RFA: Improve jump threading 5 of N
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I should have included these in the last patch of infrastructure changes.
The main change is create_block_for_threading no longer calls
remove_ctrl_stmt_and_useless_edges and instead its callers are expected
to handle that, when needed. This will allow me to use
create_block_for_threading to duplicate the join block in a future patch.
Additionally there was another place I should have been using a macro to
access the edges stored in the aux field.
Bootstrapped and regression tested on x86_64-unknown-linux-gnu. OK for
trunk?
Thanks,
Jeff
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJNwswlAAoJEBRtltQi2kC72U4H/Rup77S9Pi2bZgkT8k1wEY7x
+teD8FOKAW52dhfFrYmI8pmOBsmC8WTvn3WlOX+a0/+eB+j2aX3OITDYAzxinu45
6w+5jBHw96iJ3IvI1HIg6wsXo0HEJW40z6OeyPR06xz9AUh2xtJCh5Mh5WCC66Qf
SPisgr/w5wteuHpDT/URsW/cPfhTS26SeB5x61QAXM7wwXDETBnI5nX+kGtZ7zTG
x0qslTTePWvpYj4OqtlYzUSC/a0qKhc724ZRBsRlME+OQ/ClGh0ikAWD1kzjU899
AmtrUWYf/NpYRe1XKLmylcAhN5qwYJ7rGNL5AdgD0lCzkjic63axOb9t3z6d3aY=
=yU+L
-END PGP SIGNATURE-
* tree-ssa-threadupdate.c (create_block_for_threading): Do not call
remove_ctrl_stmt_and_useless_edges.
(create_duplicates): Call remove_ctrl_stmt_and_useless_edges.
(fixup_template_block, thread_single_edge): Likewise.
(mark_threaded_blocks): Use THREAD_TARGET.
Index: tree-ssa-threadupdate.c
===
*** tree-ssa-threadupdate.c (revision 173394)
--- tree-ssa-threadupdate.c (working copy)
*** remove_ctrl_stmt_and_useless_edges (basi
*** 198,205
}
}
! /* Create a duplicate of BB which only reaches the destination of the edge
!stored in RD. Record the duplicate block in RD. */
static void
create_block_for_threading (basic_block bb, struct redirection_data *rd)
--- 198,204
}
}
! /* Create a duplicate of BB. Record the duplicate block in RD. */
static void
create_block_for_threading (basic_block bb, struct redirection_data *rd)
*** create_block_for_threading (basic_block
*** 217,230
/* Zero out the profile, since the block is unreachable for now. */
rd->dup_block->frequency = 0;
rd->dup_block->count = 0;
-
- /* The call to duplicate_block will copy everything, including the
- useless COND_EXPR or SWITCH_EXPR at the end of BB. We just remove
- the useless COND_EXPR or SWITCH_EXPR here rather than having a
- specialized block copier. We also remove all outgoing edges
- from the duplicate block. The appropriate edge will be created
- later. */
- remove_ctrl_stmt_and_useless_edges (rd->dup_block, NULL);
}
/* Hashing and equality routines for our hash table. */
--- 216,221
*** create_duplicates (void **slot, void *da
*** 375,380
--- 366,372
/* Go ahead and wire up outgoing edges and update PHIs for the duplicate
block. */
+ remove_ctrl_stmt_and_useless_edges (rd->dup_block, NULL);
create_edge_and_update_destination_phis (rd, rd->dup_block);
}
*** fixup_template_block (void **slot, void
*** 396,401
--- 388,394
and halt the hash table traversal. */
if (rd->dup_block && rd->dup_block == local_info->template_block)
{
+ remove_ctrl_stmt_and_useless_edges (rd->dup_block, NULL);
create_edge_and_update_destination_phis (rd, rd->dup_block);
return 0;
}
*** thread_single_edge (edge e)
*** 646,651
--- 639,645
rd.outgoing_edge = eto;
create_block_for_threading (bb, &rd);
+ remove_ctrl_stmt_and_useless_edges (rd.dup_block, NULL);
create_edge_and_update_destination_phis (&rd, rd.dup_block);
if (dump_file && (dump_flags & TDF_DETAILS))
*** mark_threaded_blocks (bitmap threaded_bl
*** 978,985
edge e = VEC_index (edge, threaded_edges, i);
edge *x = (edge *) XNEWVEC (edge, 1);
- x[0] = VEC_index (edge, threaded_edges, i + 1);
e->aux = x;
bitmap_set_bit (tmp, e->dest->index);
}
--- 972,979
edge e = VEC_index (edge, threaded_edges, i);
edge *x = (edge *) XNEWVEC (edge, 1);
e->aux = x;
+ THREAD_TARGET (e) = VEC_index (edge, threaded_edges, i + 1);
bitmap_set_bit (tmp, e->dest->index);
}
Re: newlib vs. libiberty mismatch breaks build (Re: [PATCH] Export psignal on all platforms)
> I don't know how to avoid this problem in configure, other than by adding > AC_LIBOBJ([psignal]). Right, the correct solution is - libiberty shouldn't provide psignal if newlib does. Making it match newlib is the wrong solution.
Re: rs6000_handle_option global state avoidance, part 1
On Wed, May 4, 2011 at 7:54 AM, Joseph S. Myers wrote:
> Two options, -mcmodel= and -mfpu=, had cases that fell through to the
> next case without comments to indicate if this was intended. I added
> comments to make the semantics explicit. Given the documentation, it
> may well be intentional for -mcmodel= but is more doubtful for -mfpu=.
I doubt that either of the fall through cases was intended.
Alan, is mcmodel suppose to set m64?
Michael, is mfpu suppose to set mrecip?
The rest of the patch looks like a faithful translation.
Thanks, David
> #if defined (HAVE_LD_LARGE_TOC) && defined (TARGET_USES_LINUX64_OPT)
> case OPT_mcmodel_:
> - if (strcmp (arg, "small") == 0)
> - rs6000_current_cmodel = CMODEL_SMALL;
> - else if (strcmp (arg, "medium") == 0)
> - rs6000_current_cmodel = CMODEL_MEDIUM;
> - else if (strcmp (arg, "large") == 0)
> - rs6000_current_cmodel = CMODEL_LARGE;
> - else
> - {
> - error ("invalid option for -mcmodel: '%s'", arg);
> - return false;
> - }
> - rs6000_explicit_options.cmodel = true;
> + /* Fall through. */
> #endif
>
> #ifdef TARGET_USES_AIX64_OPT
> @@ -4261,9 +4224,9 @@ rs6000_handle_option (struct gcc_options
> #else
> case OPT_m64:
> #endif
> - target_flags |= MASK_POWERPC64 | MASK_POWERPC;
> - target_flags |= ~target_flags_explicit & MASK_PPC_GFXOPT;
> - target_flags_explicit |= MASK_POWERPC64 | MASK_POWERPC;
> + opts->x_target_flags |= MASK_POWERPC64 | MASK_POWERPC;
> + opts->x_target_flags |= ~opts_set->x_target_flags & MASK_PPC_GFXOPT;
> + opts_set->x_target_flags |= MASK_POWERPC64 | MASK_POWERPC;
> break;
> case OPT_mfpu_:
> - fpu_type = rs6000_parse_fpu_option(arg);
> - if (fpu_type != FPU_NONE)
> - /* If -mfpu is not none, then turn off SOFT_FLOAT, turn on HARD_FLOAT.
> */
> - {
> - target_flags &= ~MASK_SOFT_FLOAT;
> - target_flags_explicit |= MASK_SOFT_FLOAT;
> - rs6000_xilinx_fpu = 1;
> - if (fpu_type == FPU_SF_LITE || fpu_type == FPU_SF_FULL)
> - rs6000_single_float = 1;
> - if (fpu_type == FPU_DF_LITE || fpu_type == FPU_DF_FULL)
> - rs6000_single_float = rs6000_double_float = 1;
> - if (fpu_type == FPU_SF_LITE || fpu_type == FPU_DF_LITE)
> - rs6000_simple_fpu = 1;
> - }
> + fpu_type = (enum fpu_type_t) value;
> + if (fpu_type != FPU_NONE)
> + {
> + /* If -mfpu is not none, then turn off SOFT_FLOAT, turn on
> + HARD_FLOAT. */
> + opts->x_target_flags &= ~MASK_SOFT_FLOAT;
> + opts_set->x_target_flags |= MASK_SOFT_FLOAT;
> + opts->x_rs6000_xilinx_fpu = 1;
> + if (fpu_type == FPU_SF_LITE || fpu_type == FPU_SF_FULL)
> + opts->x_rs6000_single_float = 1;
> + if (fpu_type == FPU_DF_LITE || fpu_type == FPU_DF_FULL)
> + opts->x_rs6000_single_float = opts->x_rs6000_double_float = 1;
> + if (fpu_type == FPU_SF_LITE || fpu_type == FPU_DF_LITE)
> + opts->x_rs6000_simple_fpu = 1;
> + }
> else
> - {
> - /* -mfpu=none is equivalent to -msoft-float */
> - target_flags |= MASK_SOFT_FLOAT;
> - target_flags_explicit |= MASK_SOFT_FLOAT;
> - rs6000_single_float = rs6000_double_float = 0;
> - }
> + {
> + /* -mfpu=none is equivalent to -msoft-float. */
> + opts->x_target_flags |= MASK_SOFT_FLOAT;
> + opts_set->x_target_flags |= MASK_SOFT_FLOAT;
> + opts->x_rs6000_single_float = opts->x_rs6000_double_float = 0;
> + }
> + /* Fall through. */
Re: [PATCH] Fix up typed DWARF stack support for POINTERS_EXTEND_UNSIGNED targets (PR debug/48853)
On 05/05/2011 10:56 AM, Jakub Jelinek wrote: We can't handle Pmode void* like other pointers? mem_mode == VOIDmode doesn't mean a void* pointer, mem_mode != VOIDmode means mem_loc_descriptor is called on some MEM's address and gives the mode of the MEM, while VOIDmode mem_mode means it isn't a memory address, but just a random rtl that we wish to translate into DWARF location expression. Ah, OK. Jason
Re: [Patch ARM] PR47930 Fix documentation for marm / mthumb
On Thu, 2011-05-05 at 14:00 +0100, Ramana Radhakrishnan wrote: > > The arm.opt change is OK, but 'Report' should stay; and it should also > > be added to the -marm case. > > Ok with this change ? Rebuilt docs and built a cross with arm-linux-gnueabi ? > > 2011-05-05 Ramana Radhakrishnan > >PR target/47930 >* config/arm/arm.opt (marm): Document it. >(mthumb): Reject negative variant. OK. R.
Re: [PATCH] Fix up typed DWARF stack support for POINTERS_EXTEND_UNSIGNED targets (PR debug/48853)
On Thu, May 05, 2011 at 10:25:53AM -0400, Jason Merrill wrote: > >+ && (mode != Pmode > >+ || GET_MODE_SIZE (ptr_mode) != DWARF2_ADDR_SIZE > > This test seems overly cautious; it seems implausible to have > DWARF2_ADDR_SIZE smaller than GET_MODE_SIZE (ptr_mode), and having > it be larger doesn't seem like a problem. Ok, I guess I can leave those ptr_mode GET_MODE_SIZE tests out. > >+ || mem_mode == VOIDmode) > > We can't handle Pmode void* like other pointers? mem_mode == VOIDmode doesn't mean a void* pointer, mem_mode != VOIDmode means mem_loc_descriptor is called on some MEM's address and gives the mode of the MEM, while VOIDmode mem_mode means it isn't a memory address, but just a random rtl that we wish to translate into DWARF location expression. If it is not a MEM address (i.e. mem_mode is VOIDmode) and Pmode is wider than DWARF2_ADDR_SIZE, then how do you otherwise find out if it is a pointer and you leave it up to the debug info consumer to do some zero/sign/something else extension from DWARF2_ADDR_SIZE to Pmode size, or if it is any other DImode quantity, which needs to be represented using DW_OP_GNU_*_type? Say for i?86 -m32 unsigned long long x = (uintptr_t) &y + 0x123456789abcULL; (plus:DI (zero_extend:DI (symbol_ref:SI "y")) (const_double 0x123456789abc)) using untyped ops would be incorrect. We could have some flag/global var whether mem_loc_descriptor is called from unwind info code or not, and just assume untyped (ptr_mode) arithmetics is always fine in that case, and just use always DW_OP_GNU_*_type on POINTERS_EXTEND_UNSIGNED targets for Pmode elsewhere, the problem with that is that the generated debug info for -gdwarf-strict would be very bad and debug info would be unnecessarily large. And we'd still need to represent Pmode SYMBOL_REF/CONST/LABEL_REF somehow with the zero/sign extension being explicit (like DW_OP_addr DW_OP_GNU_convert DW_OP_GNU_convert for zero-extension, s/unsigned int/int/ for sign extension). Unfortunately POINTERS_EXTEND_UNSIGNED can be also -1 which means target has special instruction to do the extension, but nothing says what that insn actually performs. So I think it is better to use untyped ops for memory addresses and typed ops outside of memory addresses when the mode is larger than DWARF2_ADDR_SIZE. Jakub
C++ PATCH for c++/48873 (unnecessary dtor calls in new-expressions)
Here the issue was that build_new_1 wants to stabilize any constructor
arguments so that the EH region for deleting the allocated memory can be
as small as possible. But stabilize_expr was being over-eager, making a
copy of a class with trivial constructors, but a non-trivial (and indeed
non-callable) destructor. And even if it didn't have a problematic
destructor, there's no reason to introduce extra copies of trivially
copyable classes. So this patch changes stabilize_expr to only make
copies of scalar types and class prvalues.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 21a411247eb5e59895aa54ff9a85e3cf8795a81a
Author: Jason Merrill
Date: Wed May 4 11:15:30 2011 -0400
PR c++/48873
* tree.c (stabilize_expr): Don't make gratuitous copies of classes.
diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
index 0f2f86c..9a6e26d 100644
--- a/gcc/cp/tree.c
+++ b/gcc/cp/tree.c
@@ -3119,7 +3119,10 @@ stabilize_expr (tree exp, tree* initp)
if (!TREE_SIDE_EFFECTS (exp))
init_expr = NULL_TREE;
- else if (!TYPE_NEEDS_CONSTRUCTING (TREE_TYPE (exp))
+ /* There are no expressions with REFERENCE_TYPE, but there can be call
+ arguments with such a type; just treat it as a pointer. */
+ else if (TREE_CODE (TREE_TYPE (exp)) == REFERENCE_TYPE
+ || SCALAR_TYPE_P (exp)
|| !lvalue_or_rvalue_with_address_p (exp))
{
init_expr = get_target_expr (exp);
diff --git a/gcc/testsuite/g++.dg/init/new32.C
b/gcc/testsuite/g++.dg/init/new32.C
new file mode 100644
index 000..f827857
--- /dev/null
+++ b/gcc/testsuite/g++.dg/init/new32.C
@@ -0,0 +1,16 @@
+// PR c++/48873
+
+#include
+
+struct D {
+private:
+ ~D();
+};
+
+template
+T& create();
+
+void f()
+{
+ D* dp = new (((void*) 0)) D(create()); // #
+}
Re: [PATCH] Fix up typed DWARF stack support for POINTERS_EXTEND_UNSIGNED targets (PR debug/48853)
+ && (mode != Pmode + || GET_MODE_SIZE (ptr_mode) != DWARF2_ADDR_SIZE This test seems overly cautious; it seems implausible to have DWARF2_ADDR_SIZE smaller than GET_MODE_SIZE (ptr_mode), and having it be larger doesn't seem like a problem. + || mem_mode == VOIDmode) We can't handle Pmode void* like other pointers? Jason
[gomp3.1] Adjust omp_in_final
Hi!
According to a clarification on OpenMP forums, if(0) which creates
an undeferred task doesn't mean if the implementation chooses to schedule
it right away that it is included task. Included tasks are thus only
the children tasks of some final task.
Fixed thusly:
2011-05-05 Jakub Jelinek
* task.c (omp_in_final): Don't return true if not final_task.
* testsuite/libgomp.c/task-5.c: Adjust.
* testsuite/libgomp.c++/task-8.C: Likewise.
* testsuite/libgomp/fortran/task3.f90: Likewise.
--- libgomp/task.c.jj 2011-04-28 14:44:18.0 +0200
+++ libgomp/task.c 2011-05-05 16:02:05.0 +0200
@@ -378,8 +378,7 @@ int
omp_in_final (void)
{
struct gomp_thread *thr = gomp_thread ();
- return thr->task && (thr->task->kind == GOMP_TASK_IFFALSE
- || thr->task->final_task);
+ return thr->task && thr->task->final_task;
}
ialias (omp_in_final)
--- libgomp/testsuite/libgomp.c/task-5.c.jj 2011-04-28 17:04:24.0
+0200
+++ libgomp/testsuite/libgomp.c/task-5.c2011-05-05 16:03:44.0
+0200
@@ -16,11 +16,11 @@ main ()
err = 1;
#pragma omp task if (0) shared(err)
{
- if (!omp_in_final ())
+ if (omp_in_final ())
#pragma omp atomic write
err = 1;
#pragma omp task if (0) shared(err)
- if (!omp_in_final ())
+ if (omp_in_final ())
#pragma omp atomic write
err = 1;
}
--- libgomp/testsuite/libgomp.c++/task-8.C.jj 2011-04-28 17:04:37.0
+0200
+++ libgomp/testsuite/libgomp.c++/task-8.C 2011-05-05 16:04:08.0
+0200
@@ -16,11 +16,11 @@ main ()
err = 1;
#pragma omp task if (0) shared(err)
{
- if (!omp_in_final ())
+ if (omp_in_final ())
#pragma omp atomic write
err = 1;
#pragma omp task if (0) shared(err)
- if (!omp_in_final ())
+ if (omp_in_final ())
#pragma omp atomic write
err = 1;
}
--- libgomp/testsuite/libgomp.fortran/task3.f90.jj 2011-04-28
14:55:50.0 +0200
+++ libgomp/testsuite/libgomp.fortran/task3.f90 2011-05-05 16:04:29.0
+0200
@@ -9,12 +9,12 @@
err = 1
endif
!$omp task if (.false.) shared(err)
- if (.not.omp_in_final ()) then
+ if (omp_in_final ()) then
!$omp atomic write
err = 1
endif
!$omp task if (.false.) shared(err)
- if (.not.omp_in_final ()) then
+ if (omp_in_final ()) then
!$omp atomic write
err = 1
endif
Jakub
copy_tree_r and STATEMENT_LIST (was Re: C++ PATCHes relating to c++/48834, c++/40975 (array new))
On 05/04/2011 06:57 PM, Eric Botcazou wrote: But you're unilaterally choosing one special handling (copying) among several ones (copying, not copying, aborting) just because of one caller, for no good reason IMO. It seems pretty straightforward to me that a function named copy_tree_r should copy everything that isn't always shared (like decls). It already copies SAVE_EXPR, after all; how is copying STATEMENT_LIST going to cause trouble in a context where copying SAVE_EXPR isn't? This is how things used to work before, but it broke when the tree-ssa merge switched from using TREE_CHAIN on statements to a separate STATEMENT_LIST. Well, the assertion certainly wasn't put there by accident. No, but the rationale isn't documented. It was added by the patch that introduced STATEMENT_LIST, http://gcc.gnu.org/ml/gcc-patches/2003-11/msg00879.html but doesn't appear in the ChangeLog entry. I notice that in that patch unsave_r copied STATEMENT_LIST, but now it doesn't. rth, do you happen to remember why you put it there? Jason
Re: [PATCH][Revised] fix --enable-build-with-cxx on darwin
On Thu, May 5, 2011 at 2:58 PM, Jack Howarth wrote: > Currently the bootstrap with --enable-build-with-cxx is broken due to > compiler errors of the form > "error: converting 'false' to pointer type 'varpool_node*' > [-Werror=conversion-null]". The attached > patch changes the last remaing instance of false to NULL and restores the > --enable-build-with-cxx bootstrap. > Tested on x86_64-apple-darwin10. Okay for gcc trunk? Ok. Richard. > Jack > > 2011-05-05 Jack Howarth > > * gcc/varpool.c (varpool_extra_name_alias): Likewise. > > Index: gcc/varpool.c > === > --- gcc/varpool.c (revision 173423) > +++ gcc/varpool.c (working copy) > @@ -676,7 +676,7 @@ varpool_extra_name_alias (tree alias, tr > > #ifndef ASM_OUTPUT_DEF > /* If aliases aren't supported by the assembler, fail. */ > - return false; > + return NULL; > #endif > > gcc_assert (TREE_CODE (decl) == VAR_DECL); >
Re: [Testsuite Fortran, Patch] Add coarray/ directory for coarray compile and run-time tests
Tobias,
I know Mike already approved that patch. Just a few nits.
> # Test coarray support.
> #
> # For the compilation tests, all files are compiles with the
^ d
> # option -fcoarray=single and with -fcoarray=lib
^ .
> # Enable if you want to test several options:
> ## look if this is dg-do-run test, in which case
> ## we cycle through the option list, otherwise we don't
> #if [expr [search_for $test "dg-do run"]] {
> # set option_list $torture_with_loops
> #} else {
> # set option_list [list { -O } ]
> #}
I think we prefer not to have #if 0 (or equivalent) code in the tree.
Thanks.
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [testsuite] Compile gfortran.dg/fmt_g0_6.f08 with -ffloat-store [fwd: tobias.bur...@physik.fu-berlin.de]
Jerry, > My goal is to completely not use any floating point operations for that > section of code. We have a concept on how to do it. I am still working > out tweaks to 48787, then I will turn my attention to this. Feel free to > quiet that test case any way you wish in the meantime. ok, I've commited my original patch as a workaround. Thanks. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH, ARM] fix PR pch/45979 regression on ARM
> > OK for trunk? I have now committed this to trunk for you and will backport this to release branches at some point in the next few days. cheers Ramana > > -- Michael > > gcc/ > > 2011-05-02 Michael Hope > > PR pch/45979 > * config/host-linux.c (TRY_EMPTY_VM_SPACE): Define for > __ARM_EABI__ hosts. > > diff --git a/gcc/config/host-linux.c b/gcc/config/host-linux.c > index 47ce3ea..8b41685 100644 > --- a/gcc/config/host-linux.c > +++ b/gcc/config/host-linux.c > @@ -84,6 +84,8 @@ > # define TRY_EMPTY_VM_SPACE 0x6000 > #elif defined(__mc68000__) > # define TRY_EMPTY_VM_SPACE 0x4000 > +#elif defined(__ARM_EABI__) > +# define TRY_EMPTY_VM_SPACE 0x6000 > #else > # define TRY_EMPTY_VM_SPACE 0 > #endif >
Re: [PATCH} fix --enable-build-with-cxx
On Thu, May 5, 2011 at 8:02 AM, Jack Howarth wrote: > On Thu, May 05, 2011 at 07:56:20AM -0500, Gabriel Dos Reis wrote: >> On Thu, May 5, 2011 at 7:55 AM, Jack Howarth >> wrote: >> > On Thu, May 05, 2011 at 02:02:19PM +0200, Eric Botcazou wrote: >> >> > Currently the bootstrap with --enable-build-with-cxx is broken due to >> >> > compiler errors of the form "error: converting 'false' to pointer type >> >> > 'varpool_node*' [-Werror=conversion-null]". The attached patch changes >> >> > these instances of false to NULL and restores the >> >> > --enable-build-with-cxx >> >> > bootstrap. Tested on x86_64-apple-darwin10. Okay for gcc trunk? >> >> >> >> http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00045.html has the first >> >> hunk so >> >> you should credit Dmitry. >> >> >> >> -- >> >> Eric Botcazou >> > >> > Eric, >> > I didn't see that patch so just reduce mine down to the change for change >> > for gcc/varpool.c. Odd that the gcc/varpool.c issue isn't seen on other >> > targets >> > besides darwin apparently. >> >> the patch is OK as obvious. > > Gabriel, > Thanks. I recall during gcc 4.6's development that there was some > discussion of > defaulting on --enable-build-with-cxx for the stage2 compiler and later (such > that > only the bootstrapped g++ compiler would be used by --enable-build-with-cxx). > Is > that change likely to happen for gcc 4.7? > Jack I hope it does -- Ian may have more ideas about that. -- Gaby
Re: [PATCH} fix --enable-build-with-cxx
>I didn't see that patch so just reduce mine down to the change for > change for gcc/varpool.c. Odd that the gcc/varpool.c issue isn't seen on > other targets besides darwin apparently. No problem. Please install the entire patch (with Dmitry's name as second name) as Dmitry hasn't got commit rights. -- Eric Botcazou
Re: [PATCH} fix --enable-build-with-cxx
On Thu, May 05, 2011 at 07:56:20AM -0500, Gabriel Dos Reis wrote: > On Thu, May 5, 2011 at 7:55 AM, Jack Howarth wrote: > > On Thu, May 05, 2011 at 02:02:19PM +0200, Eric Botcazou wrote: > >> > Currently the bootstrap with --enable-build-with-cxx is broken due to > >> > compiler errors of the form "error: converting 'false' to pointer type > >> > 'varpool_node*' [-Werror=conversion-null]". The attached patch changes > >> > these instances of false to NULL and restores the --enable-build-with-cxx > >> > bootstrap. Tested on x86_64-apple-darwin10. Okay for gcc trunk? > >> > >> http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00045.html has the first hunk > >> so > >> you should credit Dmitry. > >> > >> -- > >> Eric Botcazou > > > > Eric, > > I didn't see that patch so just reduce mine down to the change for change > > for gcc/varpool.c. Odd that the gcc/varpool.c issue isn't seen on other > > targets > > besides darwin apparently. > > the patch is OK as obvious. Gabriel, Thanks. I recall during gcc 4.6's development that there was some discussion of defaulting on --enable-build-with-cxx for the stage2 compiler and later (such that only the bootstrapped g++ compiler would be used by --enable-build-with-cxx). Is that change likely to happen for gcc 4.7? Jack
Re: [Patch ARM] PR47930 Fix documentation for marm / mthumb
> The arm.opt change is OK, but 'Report' should stay; and it should also
> be added to the -marm case.
Ok with this change ? Rebuilt docs and built a cross with arm-linux-gnueabi ?
2011-05-05 Ramana Radhakrishnan
PR target/47930
* config/arm/arm.opt (marm): Document it.
(mthumb): Reject negative variant.
cheers
Ramana
>
> R.
>
>
>
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 173422)
+++ gcc/doc/invoke.texi (working copy)
@@ -10282,16 +10282,16 @@
and has length @code{((pc[-3]) & 0xff00)}.
@item -mthumb
+@itemx -marm
+@opindex marm
@opindex mthumb
-Generate code for the Thumb instruction set. The default is to
-use the 32-bit ARM instruction set.
-This option automatically enables either 16-bit Thumb-1 or
-mixed 16/32-bit Thumb-2 instructions based on the @option{-mcpu=@var{name}}
-and @option{-march=@var{name}} options. This option is not passed to the
-assembler. If you want to force assembler files to be interpreted as Thumb
code,
-either add a @samp{.thumb} directive to the source or pass the @option{-mthumb}
-option directly to the assembler by prefixing it with @option{-Wa}.
+Select between generating code that executes in ARM and Thumb
+states. The default for most configurations is to generate code
+that executes in ARM state, but the default can be changed by
+configuring GCC with the @option{--with-mode=}@var{state}
+configure option.
+
@item -mtpcs-frame
@opindex mtpcs-frame
Generate a stack frame that is compliant with the Thumb Procedure Call
Index: gcc/config/arm/arm.opt
===
--- gcc/config/arm/arm.opt (revision 173422)
+++ gcc/config/arm/arm.opt (working copy)
@@ -52,7 +52,8 @@
Specify the name of the target architecture
marm
-Target RejectNegative InverseMask(THUMB) Undocumented
+Target Report RejectNegative InverseMask(THUMB)
+Generate code in 32 bit ARM state.
mbig-endian
Target Report RejectNegative Mask(BIG_END)
@@ -131,8 +132,8 @@
Specify the minimum bit alignment of structures
mthumb
-Target Report Mask(THUMB)
-Compile for the Thumb not the ARM
+Target Report RejectNegative Mask(THUMB)
+Generate code for Thumb state
mthumb-interwork
Target Report Mask(INTERWORK)
[PATCH][Revised] fix --enable-build-with-cxx on darwin
Currently the bootstrap with --enable-build-with-cxx is broken due to compiler errors of the form "error: converting 'false' to pointer type 'varpool_node*' [-Werror=conversion-null]". The attached patch changes the last remaing instance of false to NULL and restores the --enable-build-with-cxx bootstrap. Tested on x86_64-apple-darwin10. Okay for gcc trunk? Jack 2011-05-05 Jack Howarth * gcc/varpool.c (varpool_extra_name_alias): Likewise. Index: gcc/varpool.c === --- gcc/varpool.c (revision 173423) +++ gcc/varpool.c (working copy) @@ -676,7 +676,7 @@ varpool_extra_name_alias (tree alias, tr #ifndef ASM_OUTPUT_DEF /* If aliases aren't supported by the assembler, fail. */ - return false; + return NULL; #endif gcc_assert (TREE_CODE (decl) == VAR_DECL);
Re: [PATCH} fix --enable-build-with-cxx
On Thu, May 5, 2011 at 7:55 AM, Jack Howarth wrote: > On Thu, May 05, 2011 at 02:02:19PM +0200, Eric Botcazou wrote: >> > Currently the bootstrap with --enable-build-with-cxx is broken due to >> > compiler errors of the form "error: converting 'false' to pointer type >> > 'varpool_node*' [-Werror=conversion-null]". The attached patch changes >> > these instances of false to NULL and restores the --enable-build-with-cxx >> > bootstrap. Tested on x86_64-apple-darwin10. Okay for gcc trunk? >> >> http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00045.html has the first hunk so >> you should credit Dmitry. >> >> -- >> Eric Botcazou > > Eric, > I didn't see that patch so just reduce mine down to the change for change > for gcc/varpool.c. Odd that the gcc/varpool.c issue isn't seen on other > targets > besides darwin apparently. the patch is OK as obvious.
Re: [PATCH} fix --enable-build-with-cxx
On Thu, May 05, 2011 at 02:02:19PM +0200, Eric Botcazou wrote: > > Currently the bootstrap with --enable-build-with-cxx is broken due to > > compiler errors of the form "error: converting 'false' to pointer type > > 'varpool_node*' [-Werror=conversion-null]". The attached patch changes > > these instances of false to NULL and restores the --enable-build-with-cxx > > bootstrap. Tested on x86_64-apple-darwin10. Okay for gcc trunk? > > http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00045.html has the first hunk so > you should credit Dmitry. > > -- > Eric Botcazou Eric, I didn't see that patch so just reduce mine down to the change for change for gcc/varpool.c. Odd that the gcc/varpool.c issue isn't seen on other targets besides darwin apparently. Jack
Re: [PATCH, ARM] Fix NEON vset_lane for D registers
On Thu, 2011-05-05 at 13:08 +0100, Julian Brown wrote: > On Tue, 03 May 2011 15:49:38 +0100 > Richard Earnshaw wrote: > > > > > On Tue, 2011-05-03 at 13:49 +0100, Julian Brown wrote: > > > Hi, > > > > > > This patch fixes vset_lane intrinsic variants for D-register sized > > > variables. A typo meant that the wrong lane would be set in many > > > circumstances. > > > > > > Tested manually only. OK to apply? > > > > > > Thanks, > > > > > > Julian > > > > > > ChangeLog > > > > > > gcc/ > > > * config/arm/neon.md (vec_set_internal): Fix misplaced > > > parenthesis in D-register case. > > > > Presumably this is a silent 'wrong-code' bug. If so, what about > > released compilers? > > Yes, this is a silent wrong-code bug. It affects branches back to at > gcc-4.4-branch at least: the patch will apply trivially to those, if > deemed appropriate (I think it's obvious enough to be risk-free). > > Joseph wrote: > > > And what about an execution testcase that fails before and passes > > after the patch? Is it hard to add one for some reason? > > I've added a testcase, and also done a regression run at Ramana's > request, which doesn't show up anything untoward. > > So: OK to apply to trunk? Other branches? (Which?) > Yes, and all open release branches. R. > Thanks, > > Julian > > ChangeLog > > gcc/ > * config/arm/neon.md (vec_set_internal): Fix misplaced > parenthesis in D-register case. > > gcc/testsuite/ > * gcc.target/arm/neon-vset_lanes8.c: New test.
Re: [PATCH] Cleanup expand_shift
On Wed, 4 May 2011, Richard Guenther wrote:
> On Wed, 4 May 2011, Eric Botcazou wrote:
>
> > > I think I did it that way because the old code tried to re-construct
> > > the type of the original amount. I can surely simply use op1 here
> > > if that is preferred.
> >
> > Right, but it used the value of OP1 so I think the new code should as well.
>
> Ok, I'll change it that way.
>
> > > Btw, do you happen to know any target that would excercise this code
> > > choosing from x86, ppc, s390 and ia64?
> >
> > All have rotate instructions so this seems to be a wash.
>
> Hm. I guess people will scream if something breaks (I can't imagine
> what though).
I have applied the following after re-bootstrapping and testing on
x86_64-unknown-linux-gnu and re-checking the mipsel cross testcase.
Richard.
2011-05-05 Richard Guenther
* expmed.c (expand_variable_shift): Rename to ...
(expand_shift_1): ... this. Take an expanded shift amount.
For rotates recurse directly not building trees for the shift amount.
(expand_variable_shift): Wrap around expand_shift_1.
(expand_shift): Adjust.
Index: gcc/expmed.c
===
*** gcc/expmed.c.orig 2011-05-04 11:07:08.0 +0200
--- gcc/expmed.c2011-05-04 17:54:27.0 +0200
*** expand_dec (rtx target, rtx dec)
*** 2032,2045
/* Output a shift instruction for expression code CODE,
with SHIFTED being the rtx for the value to shift,
!and AMOUNT the tree for the amount to shift by.
Store the result in the rtx TARGET, if that is convenient.
If UNSIGNEDP is nonzero, do a logical shift; otherwise, arithmetic.
Return the rtx for where the value is. */
! rtx
! expand_variable_shift (enum tree_code code, enum machine_mode mode, rtx
shifted,
! tree amount, rtx target, int unsignedp)
{
rtx op1, temp = 0;
int left = (code == LSHIFT_EXPR || code == LROTATE_EXPR);
--- 2032,2045
/* Output a shift instruction for expression code CODE,
with SHIFTED being the rtx for the value to shift,
!and AMOUNT the rtx for the amount to shift by.
Store the result in the rtx TARGET, if that is convenient.
If UNSIGNEDP is nonzero, do a logical shift; otherwise, arithmetic.
Return the rtx for where the value is. */
! static rtx
! expand_shift_1 (enum tree_code code, enum machine_mode mode, rtx shifted,
! rtx amount, rtx target, int unsignedp)
{
rtx op1, temp = 0;
int left = (code == LSHIFT_EXPR || code == LROTATE_EXPR);
*** expand_variable_shift (enum tree_code co
*** 2053,2059
int attempt;
bool speed = optimize_insn_for_speed_p ();
! op1 = expand_normal (amount);
op1_mode = GET_MODE (op1);
/* Determine whether the shift/rotate amount is a vector, or scalar. If the
--- 2053,2059
int attempt;
bool speed = optimize_insn_for_speed_p ();
! op1 = amount;
op1_mode = GET_MODE (op1);
/* Determine whether the shift/rotate amount is a vector, or scalar. If the
*** expand_variable_shift (enum tree_code co
*** 2138,2162
code below. */
rtx subtarget = target == shifted ? 0 : target;
! tree new_amount, other_amount;
rtx temp1;
! tree type = TREE_TYPE (amount);
! if (GET_MODE (op1) != TYPE_MODE (type)
! && GET_MODE (op1) != VOIDmode)
! op1 = convert_to_mode (TYPE_MODE (type), op1, 1);
! new_amount = make_tree (type, op1);
other_amount
! = fold_build2 (MINUS_EXPR, type,
! build_int_cst (type, GET_MODE_BITSIZE (mode)),
! new_amount);
shifted = force_reg (mode, shifted);
! temp = expand_variable_shift (left ? LSHIFT_EXPR : RSHIFT_EXPR,
! mode, shifted, new_amount, 0, 1);
! temp1 = expand_variable_shift (left ? RSHIFT_EXPR : LSHIFT_EXPR,
!mode, shifted, other_amount,
!subtarget, 1);
return expand_binop (mode, ior_optab, temp, temp1, target,
unsignedp, methods);
}
--- 2138,2159
code below. */
rtx subtarget = target == shifted ? 0 : target;
! rtx new_amount, other_amount;
rtx temp1;
!
! new_amount = op1;
other_amount
! = simplify_gen_binary (MINUS, GET_MODE (op1),
! GEN_INT (GET_MODE_BITSIZE (mode)),
! op1);
shifted = force_reg (mode, shifted);
! temp = expand_shift_1 (left ? LSHIFT_EXPR : RSHIFT_EXPR,
!
[PATCH, testsuite]: Fix gcc.target/i386/opt-[12].c on AVX target
Hello!
Add --param min-insn-to-prefetch-ratio=0 to avoid "Not prefetching --
instruction to prefetch ratio (6) too small" aprefetch pass rejection.
2011-05-05 Uros Bizjak
* gcc.target/i386/opt-1.c: Add --param min-insn-to-prefetch -ratio=0
to dg-options.
* gcc.target/i386/opt-1.c: Ditto.
Tested on x86_64-pc-linux-gnu {,-m32} AVX target, committed to mainline SVN.
Uros.
Index: gcc.target/i386/opt-2.c
===
--- gcc.target/i386/opt-2.c (revision 173416)
+++ gcc.target/i386/opt-2.c (working copy)
@@ -1,7 +1,7 @@
/* Test the attribute((optimize)) really works. Do this test by checking
whether we vectorize a simple loop. */
/* { dg-do compile } */
-/* { dg-options "-O1 -msse2 -mfpmath=sse -march=k8" } */
+/* { dg-options "-O1 -msse2 -mfpmath=sse -march=k8 --param
min-insn-to-prefetch-ratio=0" } */
/* { dg-final { scan-assembler "prefetcht0" } } */
/* { dg-final { scan-assembler "addps" } } */
/* { dg-final { scan-assembler "subss" } } */
Index: gcc.target/i386/opt-1.c
===
--- gcc.target/i386/opt-1.c (revision 173416)
+++ gcc.target/i386/opt-1.c (working copy)
@@ -1,7 +1,7 @@
/* Test the attribute((optimize)) really works. Do this test by checking
whether we vectorize a simple loop. */
/* { dg-do compile } */
-/* { dg-options "-O1 -msse2 -mfpmath=sse -march=k8" } */
+/* { dg-options "-O1 -msse2 -mfpmath=sse -march=k8 --param
min-insn-to-prefetch-ratio=0" } */
/* { dg-final { scan-assembler "prefetcht0" } } */
/* { dg-final { scan-assembler "addps" } } */
/* { dg-final { scan-assembler "subss" } } */
Re: [PATCH, ARM] Fix NEON vset_lane for D registers
On Tue, 03 May 2011 15:49:38 +0100
Richard Earnshaw wrote:
>
> On Tue, 2011-05-03 at 13:49 +0100, Julian Brown wrote:
> > Hi,
> >
> > This patch fixes vset_lane intrinsic variants for D-register sized
> > variables. A typo meant that the wrong lane would be set in many
> > circumstances.
> >
> > Tested manually only. OK to apply?
> >
> > Thanks,
> >
> > Julian
> >
> > ChangeLog
> >
> > gcc/
> > * config/arm/neon.md (vec_set_internal): Fix misplaced
> > parenthesis in D-register case.
>
> Presumably this is a silent 'wrong-code' bug. If so, what about
> released compilers?
Yes, this is a silent wrong-code bug. It affects branches back to at
gcc-4.4-branch at least: the patch will apply trivially to those, if
deemed appropriate (I think it's obvious enough to be risk-free).
Joseph wrote:
> And what about an execution testcase that fails before and passes
> after the patch? Is it hard to add one for some reason?
I've added a testcase, and also done a regression run at Ramana's
request, which doesn't show up anything untoward.
So: OK to apply to trunk? Other branches? (Which?)
Thanks,
Julian
ChangeLog
gcc/
* config/arm/neon.md (vec_set_internal): Fix misplaced
parenthesis in D-register case.
gcc/testsuite/
* gcc.target/arm/neon-vset_lanes8.c: New test.Index: gcc/testsuite/gcc.target/arm/neon-vset_lanes8.c
===
--- gcc/testsuite/gcc.target/arm/neon-vset_lanes8.c (revision 0)
+++ gcc/testsuite/gcc.target/arm/neon-vset_lanes8.c (revision 0)
@@ -0,0 +1,21 @@
+/* Test the `vset_lane_s8' ARM Neon intrinsic. */
+
+/* { dg-do run } */
+/* { dg-require-effective-target arm_neon_hw } */
+/* { dg-options "-O0" } */
+/* { dg-add-options arm_neon } */
+
+#include "arm_neon.h"
+#include
+#include
+
+int8x8_t x = { 1, 2, 3, 4, 5, 6, 7, 8 };
+int8x8_t y = { 1, 2, 3, 16, 5, 6, 7, 8 };
+
+int main (void)
+{
+ x = vset_lane_s8 (16, x, 3);
+ if (memcmp (&x, &y, sizeof (x)) != 0)
+abort();
+ return 0;
+}
Index: gcc/config/arm/neon.md
===
--- gcc/config/arm/neon.md (revision 173299)
+++ gcc/config/arm/neon.md (working copy)
@@ -426,7 +426,7 @@
(match_operand:SI 2 "immediate_operand" "i")))]
"TARGET_NEON"
{
- int elt = ffs ((int) INTVAL (operands[2]) - 1);
+ int elt = ffs ((int) INTVAL (operands[2])) - 1;
if (BYTES_BIG_ENDIAN)
elt = GET_MODE_NUNITS (mode) - 1 - elt;
operands[2] = GEN_INT (elt);
[committed] Add testcase for PR rtl-optimization/48381
Hi!
This PR has been fixed without testcase being added,
fixed thusly, regtested on x86_64-linux and i686-linux,
committed to trunk.
2011-05-05 Jakub Jelinek
PR rtl-optimization/48381
* gcc.c-torture/compile/pr48381.c: New test.
--- gcc/testsuite/gcc.c-torture/compile/pr48381.c.jj2011-05-05
12:16:29.0 +0200
+++ gcc/testsuite/gcc.c-torture/compile/pr48381.c 2011-05-05
12:15:37.0 +0200
@@ -0,0 +1,25 @@
+/* PR rtl-optimization/48381 */
+
+struct S { int s; } t;
+
+int baz (void);
+void fn (int, unsigned, int, unsigned, char);
+
+static char
+foo (signed x, unsigned y)
+{
+ return x < 0 || y >= 32 ? 1 : x >> y;
+}
+
+long long
+bar (long long x, long y)
+{
+ return y < 0 ? 1LL : x - y;
+}
+
+void
+test (int x, unsigned y, unsigned z, char w)
+{
+ unsigned v[2];
+ fn (w || baz (), y, t.s, y, foo (bar (z, w) <= v[0], x));
+}
Jakub
Re: [PATCH} fix --enable-build-with-cxx
> Currently the bootstrap with --enable-build-with-cxx is broken due to > compiler errors of the form "error: converting 'false' to pointer type > 'varpool_node*' [-Werror=conversion-null]". The attached patch changes > these instances of false to NULL and restores the --enable-build-with-cxx > bootstrap. Tested on x86_64-apple-darwin10. Okay for gcc trunk? http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00045.html has the first hunk so you should credit Dmitry. -- Eric Botcazou
[PATCH] Improve debug info for optimized away parameters passed in memory
Hi!
On the attached enhanced typeddwarf.c testcase there is no location
info for the 3 vars in f4 function with -O2 -m32 -g. The parameter
is unused during expansion except for debug stmts, but DECL_INCOMING_RTL
isn't a hard register or MEM with hard register as address that would be
represented as ENTRY_VALUE. But, if it is unused, then IMHO nothing should
modify the stack slot in which it has been passed to the function, thus
it should be fine to just use the DECL_INCOMING_RTL MEM.
Without this patch, we will use a pseudo that is loaded from the MEM,
but those pseudos will be quickly optimized away afterwards.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2011-05-05 Jakub Jelinek
* cfgexpand.c (expand_debug_expr): For unused non-addressable
parameters passed in memory prefer using DECL_INCOMING_RTL over
the pseudos it will be copied into.
--- gcc/cfgexpand.c.jj 2011-05-02 18:39:28.0 +0200
+++ gcc/cfgexpand.c 2011-05-05 09:29:50.0 +0200
@@ -3160,6 +3160,20 @@ expand_debug_expr (tree exp)
ENTRY_VALUE_EXP (op0) = incoming;
goto adjust_mode;
}
+ if (incoming
+ && MEM_P (incoming)
+ && !TREE_ADDRESSABLE (SSA_NAME_VAR (exp))
+ && GET_MODE (incoming) != BLKmode
+ && (XEXP (incoming, 0) == virtual_incoming_args_rtx
+ || (GET_CODE (XEXP (incoming, 0)) == PLUS
+ && XEXP (XEXP (incoming, 0), 0)
+ == virtual_incoming_args_rtx
+ && CONST_INT_P (XEXP (XEXP (incoming, 0),
+ 1)
+ {
+ op0 = incoming;
+ goto adjust_mode;
+ }
op0 = expand_debug_expr (SSA_NAME_VAR (exp));
if (!op0)
return NULL;
Jakub
/* { dg-do run { target { i?86-*-* x86_64-*-* } } } */
/* { dg-options "-g" } */
typedef __SIZE_TYPE__ size_t;
volatile int vv;
extern void *memcpy (void *, const void *, size_t);
__attribute__((noinline, noclone)) void
f1 (double a, double b, double c, float d, float e, int f, unsigned int g, long
long h, unsigned long long i)
{
double j = d; /* { dg-final { gdb-test 29 "j" "4" } } */
long long l; /* { dg-final { gdb-test 29 "l"
"4616189618054758400" } } */
memcpy (&l, &j, sizeof (l));
long long m; /* { dg-final { gdb-test 29 "m"
"4613937818241073152" } } */
memcpy (&m, &c, sizeof (l));
float n = i; /* { dg-final { gdb-test 29 "n" "9" } } */
double o = h; /* { dg-final { gdb-test 29 "o" "8" } } */
float p = g; /* { dg-final { gdb-test 29 "p" "7" } } */
double q = f; /* { dg-final { gdb-test 29 "q" "6" } } */
unsigned long long r = a; /* { dg-final { gdb-test 29 "r" "1" } } */
long long s = c; /* { dg-final { gdb-test 29 "s" "3" } } */
unsigned t = d; /* { dg-final { gdb-test 29 "t" "4" } } */
int u = b;/* { dg-final { gdb-test 29 "u" "2" } } */
float v = a; /* { dg-final { gdb-test 29 "v" "1" } } */
double w = d / 4.0; /* { dg-final { gdb-test 29 "w" "1" } } */
double x = a + b + 1.0; /* { dg-final { gdb-test 29 "x" "4" } } */
double y = b + c + 2.0; /* { dg-final { gdb-test 29 "y" "7" } } */
float z = d + e + 3.0f; /* { dg-final { gdb-test 29 "z" "12" } } */
vv++;
}
__attribute__((noinline, noclone)) void
f2 (double a, double b, double c, float d, float e, int f, unsigned int g, long
long h, unsigned long long i)
{
double j = d; /* { dg-final { gdb-test 53 "j" "4" } } */
long long l; /* { dg-final { gdb-test 53 "l"
"4616189618054758400" } } */
memcpy (&l, &j, sizeof (l));
long long m; /* { dg-final { gdb-test 53 "m"
"4613937818241073152" } } */
memcpy (&m, &c, sizeof (l));
float n = i; /* { dg-final { gdb-test 53 "n" "9" } } */
double o = h; /* { dg-final { gdb-test 53 "o" "8" } } */
float p = g; /* { dg-final { gdb-test 53 "p" "7" } } */
double q = f; /* { dg-final { gdb-test 53 "q" "6" } } */
unsigned long long r = a; /* { dg-final { gdb-test 53 "r" "1" } } */
long long s = c; /* { dg-final { gdb-test 53 "s" "3" } } */
unsigned t = d; /* { dg-final { gdb-test 53 "t" "4" } } */
int u = b;/* { dg-final { gdb-test 53 "u" "2" } } */
float v = a; /* { dg-final { gdb-test 53 "v" "1" } } */
double w = d / 4.0; /* { dg-final { gdb-test 53 "w" "1" } } */
double x = a + b - 3 + 1.0e20;
Re: [google]: initialize language field for clone function struct
> Hm, ok. I was more looking at removing the calls from fold-const.c where > it seems to protect things like folding x <= +Inf to x == x, stuff unlikely > to appear in type sizes. I can imagine the Ada FE wanting to do > things with type sizes and variable_size's wrapping looks like merely > an optimization to me (for re-using values in nested array types > for example(?)). I indeed can try to remove some/the calls present in fold-const.c as part as my upcoming patch to tidy up the hook, but the one present in variable_size needs to stay for the time being. -- Eric Botcazou
Re: Toplevel newlib/libgloss disabling cleanup
There is indeed more simplification possible (alpha-vms for example
caught my attention while reviewing), but proceeding incrementally
does not hurt.
This patch is okay, thanks.
Paolo
2011/5/4, Joseph S. Myers :
> This patch separates cases disabling newlib and libgloss for various
> target OSes from the main toplevel case statement over targets.
>
> By doing so, the logic is significantly simplified; there is now a
> single case for all *-*-linux* targets that disables newlib and
> libgloss for them, for example. (The only Linux port of newlib is for
> x86, so it's correct the disable newlib for all Linux targets except
> for x86 where the existing logic is retained.) Most empty cases in
> the main case statement can now be removed because once this disabling
> is done consistently on a per-OS basis there is no longer a
> possibility that an empty case has a use to stop falling through to
> later cases such as *-*-linux*. (A few empty cases need to be kept to
> stop falling through to cases such as mips*-*-*, however.)
>
> Where newlib and libgloss were disabled for an OS on multiple
> architectures I generally wrote a patter that matched all
> architectures for that OS. For sparc-*-sunos4* the logic disabled
> them only for cross compilers, but newlib and libgloss are disabled by
> default for native compilers anyway so I didn't keep any such
> conditional when moving that disabling up.
>
> While there's certainly scope for more splitting up of the big
> toplevel case statement (so each project sharing the toplevel has its
> own case statement, eventually coming from a subdirectory file), I
> think this patch may be the last piece involving substantial
> simplification through splitting up case statements.
>
> OK to commit?
>
> 2011-05-04 Joseph Myers
>
> * configure.ac (alpha*-dec-osf*, i[[3456789]]86-*-rdos*,
> sh*-*-pe|mips*-*-pe|arm-wince-pe, sparc-*-sunos4*, *-*-aix*,
> *-*-beos*, *-*-chorusos, *-*-dragonfly*, *-*-freebsd*, *-*-linux*
> | *-*-gnu* | *-*-k*bsd*-gnu | *-*-kopensolaris*-gnu, *-*-lynxos*,
> *-*-mingw*, *-*-netbsd*, *-*-netware*, *-*-tpf*, *-*-uclinux*,
> *-*-vxworks*): Disable newlib and libgloss in separate case
> statement.
> (i[[3456789]]86-*-linux*): Move logic allowing newlib to be built
> to separate case statement.
> (*-*-chorusos, *-*-dragonfly*, *-*-freebsd*, *-*-netbsd*,
> *-*-netware*, *-*-tpf*, *-*-uclinux*, *-*-vxworks*,
> alpha*-dec-osf*, alpha*-*-linux*, am33_2.0-*-linux*, sh-*-linux*,
> sh*-*-pe|mips*-*-pe|*arm-wince-pe, arm-*-coff, arm-*-elf* |
> arm*-*-eabi*, arm*-*-linux-gnueabi, arm*-*-symbianelf*, avr-*-*,
> bfin-*-*, cris-*-* | crisv32-*-*, frv-*-*, i[[3456789]]86-*-coff |
> i[[3456789]]86-*-elf, i[[3456789]]86-w64-mingw*,
> i[[3456789]]86-*-mingw*, x86_64-*-mingw*,
> i[[3456789]]86-*-interix*, i[[3456789]]86-*-beos*,
> i[[3456789]]86-*-rdos*, m32r-*-*,
> m68hc11-*-*|m6811-*-*|m68hc12-*-*|m6812-*-*, m68k-*-elf*, m68*-*-*
> | fido-*-*, powerpc-*-aix*, powerpc-*-beos*, powerpc-*-eabi,
> powerpc-*-eabi* | powerpcle-*-eabi* | powerpc-*-rtems*,
> rs6000-*-lynxos*, rs6000-*-aix*, mips*-*-linux*, sparclet-*-aout*
> | sparc86x-*-*, sparc-*-elf*, sparc64-*-elf*, sparclite-*-*,
> sparc-*-sunos4*, sparc-*-solaris* | sparc64-*-solaris* |
> sparcv9-*-solaris*, *-*-linux* | *-*-gnu* | *-*-k*bsd*-gnu |
> *-*-kopensolaris*-gnu, *-*-lynxos*, *-*-*): Don't disable newlib
> and libgloss in main case over targets. Remove most empty cases
> in main case over targets.
> * configure: Regenerate.
>
> Index: configure.ac
> ===
> --- configure.ac (revision 173360)
> +++ configure.ac (working copy)
> @@ -744,10 +744,76 @@
> ;;
> esac
>
> +# Disable newlib and libgloss for various target OSes.
> case "${target}" in
> + alpha*-dec-osf*)
> +noconfigdirs="$noconfigdirs target-newlib target-libgloss"
> +;;
> + i[[3456789]]86-*-linux*)
> +# This section makes it possible to build newlib natively on linux.
> +# If we are using a cross compiler then don't configure newlib.
> +if test x${is_cross_compiler} != xno ; then
> + noconfigdirs="$noconfigdirs target-newlib"
> +fi
> +noconfigdirs="$noconfigdirs target-libgloss"
> +# If we are not using a cross compiler, do configure newlib.
> +# Note however, that newlib will only be configured in this situation
> +# if the --with-newlib option has been given, because otherwise
> +# 'target-newlib' will appear in skipdirs.
> +;;
> + i[[3456789]]86-*-rdos*)
> +noconfigdirs="$noconfigdirs target-newlib target-libgloss"
> +;;
> + sh*-*-pe|mips*-*-pe|arm-wince-pe)
> +noconfigdirs="$noconfigdirs target-newlib target-libgloss"
> +;;
> + sparc-*-sunos4*)
> +noconfigdirs="$noconfigdirs target-newlib target-libgloss"
> +
[PATCH} fix --enable-build-with-cxx
Currently the bootstrap with --enable-build-with-cxx is broken due to compiler errors of the form "error: converting 'false' to pointer type 'varpool_node*' [-Werror=conversion-null]". The attached patch changes these instances of false to NULL and restores the --enable-build-with-cxx bootstrap. Tested on x86_64-apple-darwin10. Okay for gcc trunk? Jack 2011-05-05 Jack Howarth * gcc/tree-inline.c (maybe_inline_call_in_expr): Use NULL. * gcc/varpool.c (varpool_extra_name_alias): Likewise. Index: gcc/tree-inline.c === --- gcc/tree-inline.c (revision 173423) +++ gcc/tree-inline.c (working copy) @@ -5238,7 +5238,7 @@ maybe_inline_call_in_expr (tree exp) id.transform_call_graph_edges = CB_CGE_DUPLICATE; id.transform_new_cfg = false; id.transform_return_to_modify = true; - id.transform_lang_insert_block = false; + id.transform_lang_insert_block = NULL; /* Make sure not to unshare trees behind the front-end's back since front-end specific mechanisms may rely on sharing. */ Index: gcc/varpool.c === --- gcc/varpool.c (revision 173423) +++ gcc/varpool.c (working copy) @@ -676,7 +676,7 @@ varpool_extra_name_alias (tree alias, tr #ifndef ASM_OUTPUT_DEF /* If aliases aren't supported by the assembler, fail. */ - return false; + return NULL; #endif gcc_assert (TREE_CODE (decl) == VAR_DECL);
[PATCH, i386]: Simplify if conditions in i386.md
Hello!
No functional change.
2011-05-05 Uros Bizjak
* config/i386/i386.md (*movdf_internal_rex64): Simplify nested "if"
conditions.
(*movdf_internal): Ditto.
(*movdf_internal_nointeger): Ditto.
(*movsf_internal): Ditto.
Tested on x86_64-pc-linux-gnu {,-m32} AVX target, committed to mainline SVN.
Uros.
Index: i386.md
===
--- i386.md (revision 173395)
+++ i386.md (working copy)
@@ -1893,15 +1893,15 @@
{
if (get_attr_mode (insn) == MODE_V4SF)
return "%vmovups\t{%1, %0|%0, %1}";
-else
- return "%vmovdqu\t{%1, %0|%0, %1}";
+ else
+ return "%vmovdqu\t{%1, %0|%0, %1}";
}
else
{
if (get_attr_mode (insn) == MODE_V4SF)
return "%vmovaps\t{%1, %0|%0, %1}";
-else
- return "%vmovdqa\t{%1, %0|%0, %1}";
+ else
+ return "%vmovdqa\t{%1, %0|%0, %1}";
}
default:
gcc_unreachable ();
@@ -1956,15 +1956,15 @@
{
if (get_attr_mode (insn) == MODE_V4SF)
return "%vmovups\t{%1, %0|%0, %1}";
-else
- return "%vmovdqu\t{%1, %0|%0, %1}";
+ else
+ return "%vmovdqu\t{%1, %0|%0, %1}";
}
else
{
if (get_attr_mode (insn) == MODE_V4SF)
return "%vmovaps\t{%1, %0|%0, %1}";
-else
- return "%vmovdqa\t{%1, %0|%0, %1}";
+ else
+ return "%vmovdqa\t{%1, %0|%0, %1}";
}
default:
gcc_unreachable ();
@@ -2004,13 +2004,15 @@
/* Handle broken assemblers that require movd instead of movq. */
if (GENERAL_REG_P (operands[0]) || GENERAL_REG_P (operands[1]))
return "%vmovd\t{%1, %0|%0, %1}";
- return "%vmovq\t{%1, %0|%0, %1}";
+ else
+ return "%vmovq\t{%1, %0|%0, %1}";
case TYPE_MMXMOV:
/* Handle broken assemblers that require movd instead of movq. */
if (GENERAL_REG_P (operands[0]) || GENERAL_REG_P (operands[1]))
return "movd\t{%1, %0|%0, %1}";
- return "movq\t{%1, %0|%0, %1}";
+ else
+ return "movq\t{%1, %0|%0, %1}";
case TYPE_SSELOG1:
return "%vpxor\t%0, %d0";
@@ -3001,15 +3003,10 @@
case MODE_DI:
return "%vmovq\t{%1, %0|%0, %1}";
case MODE_DF:
- if (TARGET_AVX)
- {
- if (REG_P (operands[0]) && REG_P (operands[1]))
- return "vmovsd\t{%1, %0, %0|%0, %0, %1}";
- else
- return "vmovsd\t{%1, %0|%0, %1}";
- }
+ if (TARGET_AVX && REG_P (operands[0]) && REG_P (operands[1]))
+ return "vmovsd\t{%1, %0, %0|%0, %0, %1}";
else
- return "movsd\t{%1, %0|%0, %1}";
+ return "%vmovsd\t{%1, %0|%0, %1}";
case MODE_V1DF:
return "%vmovlpd\t{%1, %d0|%d0, %1}";
case MODE_V2SF:
@@ -3164,35 +3161,20 @@
case MODE_DI:
return "%vmovq\t{%1, %0|%0, %1}";
case MODE_DF:
- if (TARGET_AVX)
- {
- if (REG_P (operands[0]) && REG_P (operands[1]))
- return "vmovsd\t{%1, %0, %0|%0, %0, %1}";
- else
- return "vmovsd\t{%1, %0|%0, %1}";
- }
+ if (TARGET_AVX && REG_P (operands[0]) && REG_P (operands[1]))
+ return "vmovsd\t{%1, %0, %0|%0, %0, %1}";
else
- return "movsd\t{%1, %0|%0, %1}";
+ return "%vmovsd\t{%1, %0|%0, %1}";
case MODE_V1DF:
- if (TARGET_AVX)
- {
- if (REG_P (operands[0]))
- return "vmovlpd\t{%1, %0, %0|%0, %0, %1}";
- else
- return "vmovlpd\t{%1, %0|%0, %1}";
- }
+ if (TARGET_AVX && REG_P (operands[0]))
+ return "vmovlpd\t{%1, %0, %0|%0, %0, %1}";
else
- return "movlpd\t{%1, %0|%0, %1}";
+ return "%vmovlpd\t{%1, %0|%0, %1}";
case MODE_V2SF:
- if (TARGET_AVX)
- {
- if (REG_P (operands[0]))
- return "vmovlps\t{%1, %0, %0|%0, %0, %1}";
- else
- return "vmovlps\t{%1, %0|%0, %1}";
- }
+ if (TARGET_AVX && REG_P (operands[0]))
+ return "vmovlps\t{%1, %0, %0|%0, %0, %1}";
else
- return "movlps\t{%1, %0|%0, %1}";
+ return "%vmovlps\t{%1, %0|%0, %1}";
default:
gcc_unreachable ();
}
@@ -3336,35 +3318,20 @@
case MODE_DI:
return "%vmovq\t{%1, %0|%0, %1}";
case MODE_DF:
- if (TARGET_AVX)
- {
- if (REG_P (operands[0]) && REG_P (operands[1]))
- return "vmovsd\t{%1, %0, %0|%0, %0, %1}";
- else
- return "vmovsd\t{%1, %0|%0, %1}";
- }
+ if (TARGET_AVX && REG_P (operands[0]) && REG_P (operands[1]))
+ return "vmovsd\t{%1, %0, %0|%0
Re: [pph] Add streamer hook for preloading common nodes (issue4478043)
On Thu, May 5, 2011 at 07:07, Richard Guenther wrote: > For LTO we have type-merging for that, and we'd continue to pre-load > the type merger with the (LTO frontend specific) common tree nodes. OK. For LTO it may make sense to eventually make this hook a nop, then. > I suppose you are not doing any merging at all? If so pre-loading those > nodes makes indeed sense (given you have a way to reject PPH images > when flags such as -f[un]signed-char differ ...). There will be some amount of merging, but I'm anticipating using the same merging scheme used by the parser. As far as the parser is concerned, pph images are not much different than a regular header file. What changes is the way those declarations get loaded in memory. Diego.
Re: [pph] Add streamer hook for preloading common nodes (issue4478043)
On Thu, May 5, 2011 at 1:03 PM, Diego Novillo wrote: > On Thu, May 5, 2011 at 05:06, Richard Guenther > wrote: > >> I think we should move away from pre-loading the streamer cache, that >> has caused enough trouble when the common nodes are originating from >> different Frontends and when compiling units with different flags which >> happen to change those nodes (think of the hoops we jump through >> to support that for -f[un]signed-char). > > Sure, though that's not an issue for pph. PPH images are generated > and consumed by one front end. > > Pre-loading common nodes in C++ gives us: > > 1- Smaller pph images > 2- Ability to do pointer comparison against common nodes. > > #1 saves us from saving a few hundred nodes in each pph image. But #2 > is a stronger requirement. How do you think we could do #2 without > pre-loading? For LTO we have type-merging for that, and we'd continue to pre-load the type merger with the (LTO frontend specific) common tree nodes. I suppose you are not doing any merging at all? If so pre-loading those nodes makes indeed sense (given you have a way to reject PPH images when flags such as -f[un]signed-char differ ...). Richard. > > Diego. >
Re: [pph] Add streamer hook for preloading common nodes (issue4478043)
On Thu, May 5, 2011 at 05:06, Richard Guenther wrote: > I think we should move away from pre-loading the streamer cache, that > has caused enough trouble when the common nodes are originating from > different Frontends and when compiling units with different flags which > happen to change those nodes (think of the hoops we jump through > to support that for -f[un]signed-char). Sure, though that's not an issue for pph. PPH images are generated and consumed by one front end. Pre-loading common nodes in C++ gives us: 1- Smaller pph images 2- Ability to do pointer comparison against common nodes. #1 saves us from saving a few hundred nodes in each pph image. But #2 is a stronger requirement. How do you think we could do #2 without pre-loading? Diego.
Re: [google]: initialize language field for clone function struct
On Thu, May 5, 2011 at 12:07 PM, Eric Botcazou wrote: >> But where do you expand it without the SAVE_EXPR? The same >> restrictions apply there. So I suppose you expand it to a function >> in which case there is the context where the SAVE_EXPR can be >> expanded exactly once. > > You don't have SAVE_EXPRs so you're precisely controlling what you're doing. > Once a SAVE_EXPR is generated, things are pretty much out of control for the > front-end. > >> But maybe I'm confused and simply lack an actual testcase that >> shows the issue ;) > > Remove the call to global_bindings_p from variable_size and run gnat.dg. Hm, ok. I was more looking at removing the calls from fold-const.c where it seems to protect things like folding x <= +Inf to x == x, stuff unlikely to appear in type sizes. I can imagine the Ada FE wanting to do things with type sizes and variable_size's wrapping looks like merely an optimization to me (for re-using values in nested array types for example(?)). Richard. > -- > Eric Botcazou >
Re: [google]: initialize language field for clone function struct
> But where do you expand it without the SAVE_EXPR? The same > restrictions apply there. So I suppose you expand it to a function > in which case there is the context where the SAVE_EXPR can be > expanded exactly once. You don't have SAVE_EXPRs so you're precisely controlling what you're doing. Once a SAVE_EXPR is generated, things are pretty much out of control for the front-end. > But maybe I'm confused and simply lack an actual testcase that > shows the issue ;) Remove the call to global_bindings_p from variable_size and run gnat.dg. -- Eric Botcazou
Re: [PATCH] Remove useless build_variant_type call from create_tmp_var_raw
On Thu, May 5, 2011 at 11:25 AM, Jakub Jelinek wrote:
> Hi!
>
> create_tmp_var_raw calls build_type_variant, but doesn't actually use
> it in any way (other than set its TYPE_ATTRIBUTES, that's why
> -Wunused-but-set-variable hasn't reported it.
Ok.
Thanks,
Richard.
> 2011-05-05 Jakub Jelinek
>
> * gimplify.c (create_tmp_var_raw): Don't call build_type_variant.
>
> --- gcc/gimplify.c.jj 2011-04-22 16:09:46.0 +0200
> +++ gcc/gimplify.c 2011-05-05 09:09:00.714588835 +0200
> @@ -427,11 +427,6 @@ tree
> create_tmp_var_raw (tree type, const char *prefix)
> {
> tree tmp_var;
> - tree new_type;
> -
> - /* Make the type of the variable writable. */
> - new_type = build_type_variant (type, 0, 0);
> - TYPE_ATTRIBUTES (new_type) = TYPE_ATTRIBUTES (type);
>
> tmp_var = build_decl (input_location,
> VAR_DECL, prefix ? create_tmp_var_name (prefix) : NULL,
>
> Jakub
>
[commit, spu] Provide TARGET_ASM_OUTPUT_MI_THUNK implementation
Hello,
this patch fixes the long-standing failure:
FAIL: g++.old-deja/g++.jason/thunk3.C (test for excess errors)
by providing a TARGET_ASM_OUTPUT_MI_THUNK implementation for SPU.
Tested on spu-elf, committed to mainline.
Bye,
Ulrich
ChangeLog:
* config/spu/spu.c (TARGET_ASM_OUTPUT_MI_THUNK): Define.
(TARGET_ASM_CAN_OUTPUT_MI_THUNK): Likewise.
(spu_output_mi_thunk): New function.
Index: gcc/config/spu/spu.c
===
*** gcc/config/spu/spu.c(revision 169938)
--- gcc/config/spu/spu.c(working copy)
*** static rtx spu_expand_load (rtx, rtx, rt
*** 231,236
--- 231,238
static void spu_trampoline_init (rtx, tree, rtx);
static void spu_conditional_register_usage (void);
static bool spu_ref_may_alias_errno (ao_ref *);
+ static void spu_output_mi_thunk (FILE *, tree, HOST_WIDE_INT,
+HOST_WIDE_INT, tree);
/* Which instruction set architecture to use. */
int spu_arch;
*** static const struct attribute_spec spu_a
*** 495,500
--- 497,507
#undef TARGET_REF_MAY_ALIAS_ERRNO
#define TARGET_REF_MAY_ALIAS_ERRNO spu_ref_may_alias_errno
+ #undef TARGET_ASM_OUTPUT_MI_THUNK
+ #define TARGET_ASM_OUTPUT_MI_THUNK spu_output_mi_thunk
+ #undef TARGET_ASM_CAN_OUTPUT_MI_THUNK
+ #define TARGET_ASM_CAN_OUTPUT_MI_THUNK
hook_bool_const_tree_hwi_hwi_const_tree_true
+
struct gcc_target targetm = TARGET_INITIALIZER;
static void
*** spu_ref_may_alias_errno (ao_ref *ref)
*** 7191,7194
--- 7198,7287
return default_ref_may_alias_errno (ref);
}
+ /* Output thunk to FILE that implements a C++ virtual function call (with
+multiple inheritance) to FUNCTION. The thunk adjusts the this pointer
+by DELTA, and unless VCALL_OFFSET is zero, applies an additional adjustment
+stored at VCALL_OFFSET in the vtable whose address is located at offset 0
+relative to the resulting this pointer. */
+
+ static void
+ spu_output_mi_thunk (FILE *file, tree thunk ATTRIBUTE_UNUSED,
+HOST_WIDE_INT delta, HOST_WIDE_INT vcall_offset,
+tree function)
+ {
+ rtx op[8];
+
+ /* Make sure unwind info is emitted for the thunk if needed. */
+ final_start_function (emit_barrier (), file, 1);
+
+ /* Operand 0 is the target function. */
+ op[0] = XEXP (DECL_RTL (function), 0);
+
+ /* Operand 1 is the 'this' pointer. */
+ if (aggregate_value_p (TREE_TYPE (TREE_TYPE (function)), function))
+ op[1] = gen_rtx_REG (Pmode, FIRST_ARG_REGNUM + 1);
+ else
+ op[1] = gen_rtx_REG (Pmode, FIRST_ARG_REGNUM);
+
+ /* Operands 2/3 are the low/high halfwords of delta. */
+ op[2] = GEN_INT (trunc_int_for_mode (delta, HImode));
+ op[3] = GEN_INT (trunc_int_for_mode (delta >> 16, HImode));
+
+ /* Operands 4/5 are the low/high halfwords of vcall_offset. */
+ op[4] = GEN_INT (trunc_int_for_mode (vcall_offset, HImode));
+ op[5] = GEN_INT (trunc_int_for_mode (vcall_offset >> 16, HImode));
+
+ /* Operands 6/7 are temporary registers. */
+ op[6] = gen_rtx_REG (Pmode, 79);
+ op[7] = gen_rtx_REG (Pmode, 78);
+
+ /* Add DELTA to this pointer. */
+ if (delta)
+ {
+ if (delta >= -0x200 && delta < 0x200)
+ output_asm_insn ("ai\t%1,%1,%2", op);
+ else if (delta >= -0x8000 && delta < 0x8000)
+ {
+ output_asm_insn ("il\t%6,%2", op);
+ output_asm_insn ("a\t%1,%1,%6", op);
+ }
+ else
+ {
+ output_asm_insn ("ilhu\t%6,%3", op);
+ output_asm_insn ("iohl\t%6,%2", op);
+ output_asm_insn ("a\t%1,%1,%6", op);
+ }
+ }
+
+ /* Perform vcall adjustment. */
+ if (vcall_offset)
+ {
+ output_asm_insn ("lqd\t%7,0(%1)", op);
+ output_asm_insn ("rotqby\t%7,%7,%1", op);
+
+ if (vcall_offset >= -0x200 && vcall_offset < 0x200)
+ output_asm_insn ("ai\t%7,%7,%4", op);
+ else if (vcall_offset >= -0x8000 && vcall_offset < 0x8000)
+ {
+ output_asm_insn ("il\t%6,%4", op);
+ output_asm_insn ("a\t%7,%7,%6", op);
+ }
+ else
+ {
+ output_asm_insn ("ilhu\t%6,%5", op);
+ output_asm_insn ("iohl\t%6,%4", op);
+ output_asm_insn ("a\t%7,%7,%6", op);
+ }
+
+ output_asm_insn ("lqd\t%6,0(%7)", op);
+ output_asm_insn ("rotqby\t%6,%6,%7", op);
+ output_asm_insn ("a\t%1,%1,%6", op);
+ }
+
+ /* Jump to target. */
+ output_asm_insn ("br\t%0", op);
+
+ final_end_function ();
+ }
+
#include "gt-spu.h"
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
Re: [google]: initialize language field for clone function struct
On Thu, May 5, 2011 at 11:23 AM, Eric Botcazou wrote: >> Sure, but that's a limitation of out SAVE_EXPR handling (given that it >> would be ok to expand the SAVE_EXPR multiple times - once per >> "instantiation context"). > > You need to expand the initializer exactly once and you need to make sure that > this occurrence is invoked before all the others at run time. Not trivial. But where do you expand it without the SAVE_EXPR? The same restrictions apply there. So I suppose you expand it to a function in which case there is the context where the SAVE_EXPR can be expanded exactly once. If you expand it (the "global" expr without SAVE_EXPR) in multiple function contexts then I see no difference if you have a SAVE_EXPR and expand that once per such function context. Yes, this multiple-times expanding a SAVE_EXPR might not actually work right now, but it doesn't sound like this would be not fixable (mark the original SAVE_EXPR as global, during unsharing make them local and process as usual). But maybe I'm confused and simply lack an actual testcase that shows the issue ;) Richard.
Re: [PATCH, ARM] PR47855 Compute attr length for thumb2 insns, 3/3 (issue4475042)
On Thu, 2011-05-05 at 14:51 +0800, Guozhi Wei wrote:
> Hi
>
> This is the third part of the fixing for
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47855
>
> This patch contains the length computation/refinement for insn patterns
> "*thumb2_movsi_insn", "*thumb2_cbz" and "*thumb2_cbnz".
>
> At the same time this patch revealed two bugs. The first is the maximum offset
> of cbz/cbnz, it should be 126, but it is 128 in patterns "*thumb2_cbz" and
> "*thumb2_cbnz". The second is that only 2-register form of shift instructions
> can be 16 bit, but 3-register form is allowed in "*thumb2_shiftsi3_short" and
> related peephole2. The fix is also contained in this patch.
>
> The patch has been tested on arm qemu.
>
> thanks
> Carrot
>
>
> 2011-05-05 Guozhi Wei
>
> PR target/47855
> * config/arm/thumb2.md (thumb2_movsi_insn): Add length addtribute.
> (thumb2_shiftsi3_short and peephole2): Remove 3-register case.
> (thumb2_cbz): Refine length computation.
> (thumb2_cbnz): Likewise.
>
Hmm, although these changes are all related to length calculations, they
are really three patches that are unrelated to each other. It would be
easier to review this if they were kept separate.
1) thumb2_shiftsi3_short
This appears to be a straight bug. We are putting out a 32-bit
instruction when we are claiming it to be only 16 bits. This is OK.
2) thumb2_movsi_insn
There are two things here.
a) Thumb2 has a 16-bit move instruction for all core
register-to-register transfers, so the separation of alternatives 1 and
2 is unnecessary -- just code these as "rk".
b) The ldm form does not support unaligned memory accesses. I'm aware
that work is being done to add unaligned support to GCC for ARM, so I
need to find out whether this patch will interfere with those changes.
I'll try to find out what the situation is here and get back to you.
3) thumb2_cbz and thumb2_cbnz
The range calculations look wrong here. Remember that the 'pc' as far
as GCC is concerned is the address of the start of the insn. So for a
backwards branch you need to account for all the bytes in the insn
pattern that occur before the branch instruction itself, and secondly
you also have to remember that the 'pc' that the CPU uses is the address
of the branch instruction plus 4. All these conspire to reduce the
backwards range of a short branch to several bytes less than the 256
that you currently have coded.
R.
> Index: config/arm/thumb2.md
> ===
> --- config/arm/thumb2.md (revision 173350)
> +++ config/arm/thumb2.md (working copy)
> @@ -165,25 +165,49 @@
> ;; regs. The high register alternatives are not taken into account when
> ;; choosing register preferences in order to reflect their expense.
> (define_insn "*thumb2_movsi_insn"
> - [(set (match_operand:SI 0 "nonimmediate_operand" "=rk,r,r,r,l ,*hk,m,*m")
> - (match_operand:SI 1 "general_operand" "rk ,I,K,j,mi,*mi,l,*hk"))]
> + [(set (match_operand:SI 0 "nonimmediate_operand" "=l,rk,r,r,r,l
> ,*rk,Uu,*m")
> + (match_operand:SI 1 "general_operand" "l ,rk,I,K,j,Uu,*mi,l
> ,*rk"))]
>"TARGET_THUMB2 && ! TARGET_IWMMXT
> && !(TARGET_HARD_FLOAT && TARGET_VFP)
> && ( register_operand (operands[0], SImode)
> || register_operand (operands[1], SImode))"
> - "@
> - mov%?\\t%0, %1
> - mov%?\\t%0, %1
> - mvn%?\\t%0, #%B1
> - movw%?\\t%0, %1
> - ldr%?\\t%0, %1
> - ldr%?\\t%0, %1
> - str%?\\t%1, %0
> - str%?\\t%1, %0"
> - [(set_attr "type" "*,*,*,*,load1,load1,store1,store1")
> + "*
> + switch (which_alternative)
> +{
> +case 0: return \"mov%?\\t%0, %1\";
> +case 1: return \"mov%?\\t%0, %1\";
> +case 2: return \"mov%?\\t%0, %1\";
> +case 3: return \"mvn%?\\t%0, #%B1\";
> +case 4: return \"movw%?\\t%0, %1\";
> +
> +case 5:
> + if (GET_CODE (XEXP (operands[1], 0)) == POST_INC)
> + {
> + operands[1] = XEXP (XEXP (operands[1], 0), 0);
> + return \"ldm%(ia%)\t%1!, {%0}\";
> + }
> + else
> + return \"ldr%?\\t%0, %1\";
> +
> +case 6: return \"ldr%?\\t%0, %1\";
> +
> +case 7:
> + if (GET_CODE (XEXP (operands[0], 0)) == POST_INC)
> + {
> + operands[0] = XEXP (XEXP (operands[0], 0), 0);
> + return \"stm%(ia%)\t%0!, {%1}\";
> + }
> + else
> + return \"str%?\\t%1, %0\";
> +
> +case 8: return \"str%?\\t%1, %0\";
> +default: gcc_unreachable ();
> +}"
> + [(set_attr "type" "*,*,*,*,*,load1,load1,store1,store1")
> (set_attr "predicable" "yes")
> - (set_attr "pool_range" "*,*,*,*,1020,4096,*,*")
> - (set_attr "neg_pool_range" "*,*,*,*,0,0,*,*")]
> + (set_attr "length" "2,4,4,4,4,2,4,2,4")
> + (set_attr "pool_range" "*,*,*,*,*,1020,4096,*,*")
> + (set_attr "neg_pool_range" "*,*,*,*,*,0,0,*,*")]
> )
>
> (define_insn "tls_load_dot_plus_four"
> @@ -685,7 +709,8 @@
>"TARGET_THUMB2
> && peep2_regno_dead_p(0, CC_REGNUM)
Re: [PATCH 2/4] Docs: extend.texi: Remove trailing blanks from lines
On Thu, May 5, 2011 at 1:57 AM, Mike Stump wrote: > On May 4, 2011, at 11:40 AM, Gerald Pfeifer wrote: >> Documentation may be a bit more relaxed, and if you have one doc >> maintainer approve and the other abstain that may be more boring >> that you might hope for. :-) > > Actually, I was aiming for a global person to ack gcc/*... This could be > less boring that just gcc/doc. :-) I think I was the one complaining loudest when HJ checked in his patch. And I still think such patches are a) pointless b) cause harm to some subjective degree. Coding style rules are nice, but if they cause any degree of harm when enforcing them they are IMHO only guildelines, not hard rules (after all, if they were we'd have a commit hook that verifies new violations do not slip in). And yes, in "harm" I mostly refer to svn blame annoyances and to patch/branch merge conflicts where context that causes the conflict only changed in whitespace. Richard.
[PATCH] Remove useless build_variant_type call from create_tmp_var_raw
Hi!
create_tmp_var_raw calls build_type_variant, but doesn't actually use
it in any way (other than set its TYPE_ATTRIBUTES, that's why
-Wunused-but-set-variable hasn't reported it.
2011-05-05 Jakub Jelinek
* gimplify.c (create_tmp_var_raw): Don't call build_type_variant.
--- gcc/gimplify.c.jj 2011-04-22 16:09:46.0 +0200
+++ gcc/gimplify.c 2011-05-05 09:09:00.714588835 +0200
@@ -427,11 +427,6 @@ tree
create_tmp_var_raw (tree type, const char *prefix)
{
tree tmp_var;
- tree new_type;
-
- /* Make the type of the variable writable. */
- new_type = build_type_variant (type, 0, 0);
- TYPE_ATTRIBUTES (new_type) = TYPE_ATTRIBUTES (type);
tmp_var = build_decl (input_location,
VAR_DECL, prefix ? create_tmp_var_name (prefix) : NULL,
Jakub
Re: [google]: initialize language field for clone function struct
> Sure, but that's a limitation of out SAVE_EXPR handling (given that it > would be ok to expand the SAVE_EXPR multiple times - once per > "instantiation context"). You need to expand the initializer exactly once and you need to make sure that this occurrence is invoked before all the others at run time. Not trivial. -- Eric Botcazou
Re: newlib vs. libiberty mismatch breaks build (Re: [PATCH] Export psignal on all platforms)
On May 5 11:09, Ulrich Weigand wrote: > This list does not include psignal, which indeed newlib did not provide > -- until yesterday, when that patch was committed ... > > > I'm not quite sure how to fix this ... any suggestions? Did this problem > occur in the past when newlib was extended to provide some new function? > > I guess the immediate build problem will disappear once the libiberty > prototype is fixed to include const, but then we'll just have two copies > of psignal (one in newlib, one in libiberty), which may not be ideal > either. Developers using libiberty don't have to use newlib so the definition in libiberty still makes sense, right? I don't know how to avoid this problem in configure, other than by adding AC_LIBOBJ([psignal]). Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat
Re: [patch] Remove support for pending sizes
On 05/05/2011 09:38 AM, Eric Botcazou wrote: > Hi, > > this entirely removes the support for pending sizes from the compiler. The > prerequisite is Joseph's patch from yesterday. > > Bootstrapped/regtested on x86_64-suse-linux, OK for the mainline? OK. Bernd
[PATCH] Fix up typed DWARF stack support for POINTERS_EXTEND_UNSIGNED targets (PR debug/48853)
Hi!
My typed DWARF stack changes apparently broke ia64-hpux and H.J.'s out of
tree x32 target. There are several issues:
1) for SUBREG mem_loc_descriptor's 3rd argument was wrong, found by code
inspection
2) CONST/SYMBOL_REF/LABEL_REF when in MEM addresses on POINTERS_EXTEND_UNSIGNED
targets are often Pmode, which is unfortunately larger than DWARF2_ADDR_SIZE
and my conditional would just return NULL in that case instead of
emitting DW_OP_addr.
3) and, when mem_loc_descriptor is called from unwind code, Pmodes larger
than DWARF2_ADDR_SIZE would result in the new DW_OP_GNU_*_type etc. ops
which are not allowed in .eh_frame/.debug_frame
The following patch ought to fix that, bootstrapped/regtested on
x86_64-linux and i686-linux and Steve tested it on ia64-hpux and H.J. on his
port. Ok for trunk?
2011-05-05 Jakub Jelinek
PR debug/48853
* dwarf2out.c (mem_loc_descriptor) : Pass mem_mode
instead of mode as 3rd argument to recursive call.
(mem_loc_descriptor) : If POINTERS_EXTEND_UNSIGNED, don't
emit DW_OP_GNU_regval_type if mode is Pmode and mem_mode is not
VOIDmode.
(mem_loc_descriptor) : If POINTERS_EXTEND_UNSIGNED,
don't give up if mode is Pmode and mem_mode is not VOIDmode.
(mem_loc_descriptor) : If POINTERS_EXTEND_UNSIGNED,
use int_loc_descriptor if mode is Pmode and mem_mode is not VOIDmode.
--- gcc/dwarf2out.c.jj 2011-05-04 10:14:08.0 +0200
+++ gcc/dwarf2out.c 2011-05-04 19:08:22.0 +0200
@@ -13883,7 +13883,7 @@ mem_loc_descriptor (rtx rtl, enum machin
mem_loc_result = mem_loc_descriptor (SUBREG_REG (rtl),
GET_MODE (SUBREG_REG (rtl)),
- mode, initialized);
+ mem_mode, initialized);
if (mem_loc_result == NULL)
break;
type_die = base_type_for_mode (mode, 0);
@@ -13906,7 +13906,13 @@ mem_loc_descriptor (rtx rtl, enum machin
case REG:
if (GET_MODE_CLASS (mode) != MODE_INT
- || GET_MODE_SIZE (mode) > DWARF2_ADDR_SIZE)
+ || (GET_MODE_SIZE (mode) > DWARF2_ADDR_SIZE
+#ifdef POINTERS_EXTEND_UNSIGNED
+ && (mode != Pmode
+ || GET_MODE_SIZE (ptr_mode) != DWARF2_ADDR_SIZE
+ || mem_mode == VOIDmode)
+#endif
+ ))
{
dw_die_ref type_die;
@@ -14049,9 +14055,18 @@ mem_loc_descriptor (rtx rtl, enum machin
pool. */
case CONST:
case SYMBOL_REF:
+ if (GET_MODE_CLASS (mode) != MODE_INT)
+ break;
+#ifndef POINTERS_EXTEND_UNSIGNED
+ if (GET_MODE_SIZE (mode) > DWARF2_ADDR_SIZE)
+ break;
+#else
if (GET_MODE_SIZE (mode) > DWARF2_ADDR_SIZE
- || GET_MODE_CLASS (mode) != MODE_INT)
+ && (mode != Pmode
+ || GET_MODE_SIZE (ptr_mode) != DWARF2_ADDR_SIZE
+ || mem_mode == VOIDmode))
break;
+#endif
if (GET_CODE (rtl) == SYMBOL_REF
&& SYMBOL_REF_TLS_MODEL (rtl) != TLS_MODEL_NONE)
{
@@ -14288,7 +14303,14 @@ mem_loc_descriptor (rtx rtl, enum machin
break;
case CONST_INT:
- if (GET_MODE_SIZE (mode) <= DWARF2_ADDR_SIZE)
+ if (GET_MODE_SIZE (mode) <= DWARF2_ADDR_SIZE
+#ifdef POINTERS_EXTEND_UNSIGNED
+ || (mode == Pmode
+ && GET_MODE_SIZE (ptr_mode) == DWARF2_ADDR_SIZE
+ && mem_mode != VOIDmode
+ && trunc_int_for_mode (INTVAL (rtl), ptr_mode) == INTVAL (rtl))
+#endif
+ )
{
mem_loc_result = int_loc_descriptor (INTVAL (rtl));
break;
Jakub
