*ping* [patch, fortran] PR 30146, errors for INTENT(OUT) and INTENT(INOUT) for DO loop variables
I wrote: Attached is the new version of the patch, regression-tested. http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00836.html Thanks for the review! OK for trunk? Ping?
Re: [PATCH, generic] New RTL primitive: `define_subst'
On Wed, 14 Nov 2012, Jakub Jelinek wrote: > > Which brings us to the question of what to do with the patch for 4.8. > > It's true that you made the deadline for stage1 closure. But there will > > be no users of this feature, so it begs the question of why we should > > apply it now. Have you a convincing reason? > > > > RM's do you have an opinion here? > > I'm not against it going in now, it shouldn't be too risky and will > allow people to start experimenting with it sooner. Another point in favor of applying it within 4.8 is that it makes for easier backport of those bug fixes that are simplified by use of define_subst. brgds, H-P
[PATCH, PR55315] Don't assume a nonzero address plus a const is a nonzero address
Richard,
This patch fixes PR 55315.
When compiling for the mips target with -O2, function f is folded to 0, while
the address of data is not known compile-time:
...
int data[4096];
int
f (void)
{
return (((unsigned int) &data[0]) == 0xdeadbea0U);
}
What happens is that expand turns the comparison into the equivalent of:
...
(((unsigned int) &data[0]) + (~0xdeadbea0U + 1)) == 0
...
and then nonzero_address_p triggers here during cse:
...
case PLUS:
if (CONST_INT_P (XEXP (x, 1)))
return nonzero_address_p (XEXP (x, 0));
...
and '(((unsigned int) &data[0]) + (~0xdeadbea0U + 1))' is considered a nonzero
address, and the comparison evaluates to 0.
This example is related to PR 29519, in fact you mention the code pattern expand
generates in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29519#c5.
But the patch for that PR does not address this example.
This patch prevents nonzero_address_p from assuming that a nonzero address plus
a const is a nonzero address.
Build and reg-tested on mips.
OK for trunk?
Thanks,
- Tom
2012-11-17 Tom de Vries
PR rtl-optimization/55315
* rtlanal.c (nonzero_address_p): Don't assume a nonzero address plus a
const is a nonzero address.
* gcc.target/mips/pr55315.c: New test.
Index: gcc/rtlanal.c
===
--- gcc/rtlanal.c (revision 193478)
+++ gcc/rtlanal.c (working copy)
@@ -392,10 +392,8 @@ nonzero_address_p (const_rtx x)
return nonzero_address_p (XEXP (x, 0));
case PLUS:
- if (CONST_INT_P (XEXP (x, 1)))
-return nonzero_address_p (XEXP (x, 0));
/* Handle PIC references. */
- else if (XEXP (x, 0) == pic_offset_table_rtx
+ if (XEXP (x, 0) == pic_offset_table_rtx
&& CONSTANT_P (XEXP (x, 1)))
return true;
return false;
Index: gcc/testsuite/gcc.target/mips/pr55315.c
===
--- /dev/null (new file)
+++ gcc/testsuite/gcc.target/mips/pr55315.c (revision 0)
@@ -0,0 +1,11 @@
+/* { dg-do compile } */
+
+int data[4096];
+
+int
+f (void)
+{
+ return (((unsigned int) &data[0]) == 0xdeadbea0U);
+}
+
+/* { dg-final { scan-assembler-not "\tmove\t\\\$2,\\\$0" } } */
[v3] libstdc++/55363
Hi,
a thinko in my work to add debug-mode std::array. Committed to mainline.
Thanks,
Paolo.
//
2012-11-17 Paolo Carlini
PR libstdc++/55363
* include/std/array (tuple_size, tuple_element): Move out
NAMESPACE_CONTAINER.
* testsuite/23_containers/array/tuple_interface/get_neg.cc: Adjust
dg-error line numbers.
* testsuite/23_containers/array/tuple_interface/tuple_element_neg.cc:
Likewise.
Index: include/std/array
===
--- include/std/array (revision 193569)
+++ include/std/array (working copy)
@@ -263,28 +263,7 @@
noexcept(noexcept(__one.swap(__two)))
{ __one.swap(__two); }
- // Tuple interface to class template array.
-
- /// tuple_size
- template
-class tuple_size;
-
- template
-struct tuple_size>
-: public integral_constant { };
-
- /// tuple_element
- template
-class tuple_element;
-
template
-struct tuple_element<_Int, array<_Tp, _Nm>>
-{
- static_assert(_Int < _Nm, "index is out of bounds");
- typedef _Tp type;
-};
-
- template
constexpr _Tp&
get(array<_Tp, _Nm>& __arr) noexcept
{
@@ -313,6 +292,34 @@
_GLIBCXX_END_NAMESPACE_CONTAINER
} // namespace std
+namespace std _GLIBCXX_VISIBILITY(default)
+{
+_GLIBCXX_BEGIN_NAMESPACE_VERSION
+
+ // Tuple interface to class template array.
+
+ /// tuple_size
+ template
+class tuple_size;
+
+ template
+struct tuple_size<_GLIBCXX_STD_C::array<_Tp, _Nm>>
+: public integral_constant { };
+
+ /// tuple_element
+ template
+class tuple_element;
+
+ template
+struct tuple_element<_Int, _GLIBCXX_STD_C::array<_Tp, _Nm>>
+{
+ static_assert(_Int < _Nm, "index is out of bounds");
+ typedef _Tp type;
+};
+
+_GLIBCXX_END_NAMESPACE_VERSION
+} // namespace std
+
#ifdef _GLIBCXX_DEBUG
# include
#endif
Index: testsuite/23_containers/array/tuple_interface/get_neg.cc
===
--- testsuite/23_containers/array/tuple_interface/get_neg.cc(revision
193569)
+++ testsuite/23_containers/array/tuple_interface/get_neg.cc(working copy)
@@ -28,6 +28,6 @@
int n2 = std::get<1>(std::move(a));
int n3 = std::get<1>(ca);
-// { dg-error "static assertion failed" "" { target *-*-* } 291 }
-// { dg-error "static assertion failed" "" { target *-*-* } 300 }
-// { dg-error "static assertion failed" "" { target *-*-* } 308 }
+// { dg-error "static assertion failed" "" { target *-*-* } 270 }
+// { dg-error "static assertion failed" "" { target *-*-* } 279 }
+// { dg-error "static assertion failed" "" { target *-*-* } 287 }
Index: testsuite/23_containers/array/tuple_interface/tuple_element_neg.cc
===
--- testsuite/23_containers/array/tuple_interface/tuple_element_neg.cc
(revision 193569)
+++ testsuite/23_containers/array/tuple_interface/tuple_element_neg.cc
(working copy)
@@ -23,4 +23,4 @@
typedef std::tuple_element<1, std::array>::type type;
-// { dg-error "static assertion failed" "" { target *-*-* } 283 }
+// { dg-error "static assertion failed" "" { target *-*-* } 316 }
[PATCH] Fix up builtin memcpy calls generated by Fortran FE (PR fortran/55341)
Hi!
This PR is about ASAN failing with checking failures. The problem is
on the Fortran FE side, which calls BUILT_IN_MEMCPY sometimes with wrong
type of the last argument (which is not type compatible with the
size_type_node type).
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?
2012-11-17 Jakub Jelinek
PR fortran/55341
* trans-intrinsic.c (gfc_conv_intrinsic_transfer): Convert last
argument to memcpy to size_type_node type.
* trans-stmt.c (gfc_conv_elemental_dependencies): Likewise.
* trasn-array.c (duplicate_allocatable): Likewise.
--- gcc/fortran/trans-intrinsic.c.jj2012-11-06 12:21:17.0 +0100
+++ gcc/fortran/trans-intrinsic.c 2012-11-16 11:48:14.111974090 +0100
@@ -5600,14 +5600,16 @@ gfc_conv_intrinsic_transfer (gfc_se * se
tmp = fold_convert (pvoid_type_node, tmp);
/* Use memcpy to do the transfer. */
- tmp = build_call_expr_loc (input_location,
-builtin_decl_explicit (BUILT_IN_MEMCPY),
-3,
-tmp,
-fold_convert (pvoid_type_node, source),
-fold_build2_loc (input_location, MIN_EXPR,
- gfc_array_index_type,
- size_bytes, source_bytes));
+ tmp
+= build_call_expr_loc (input_location,
+ builtin_decl_explicit (BUILT_IN_MEMCPY), 3, tmp,
+ fold_convert (pvoid_type_node, source),
+ fold_convert (size_type_node,
+fold_build2_loc (input_location,
+ MIN_EXPR,
+ gfc_array_index_type,
+ size_bytes,
+ source_bytes)));
gfc_add_expr_to_block (&se->pre, tmp);
se->expr = info->descriptor;
@@ -5649,7 +5651,7 @@ scalar_transfer:
builtin_decl_explicit (BUILT_IN_MEMCPY), 3,
fold_convert (pvoid_type_node, tmpdecl),
fold_convert (pvoid_type_node, ptr),
-extent);
+fold_convert (size_type_node, extent));
gfc_add_expr_to_block (&block, tmp);
indirect = gfc_finish_block (&block);
@@ -5687,7 +5689,7 @@ scalar_transfer:
builtin_decl_explicit (BUILT_IN_MEMCPY), 3,
fold_convert (pvoid_type_node, tmp),
fold_convert (pvoid_type_node, ptr),
-extent);
+fold_convert (size_type_node, extent));
gfc_add_expr_to_block (&se->pre, tmp);
/* For CLASS results, set the _vptr. */
--- gcc/fortran/trans-stmt.c.jj 2012-10-17 17:18:21.0 +0200
+++ gcc/fortran/trans-stmt.c2012-11-16 11:45:26.608192584 +0100
@@ -337,7 +337,8 @@ gfc_conv_elemental_dependencies (gfc_se
tmp = gfc_conv_descriptor_data_get (tmp);
tmp = build_call_expr_loc (input_location,
builtin_decl_explicit
(BUILT_IN_MEMCPY),
-3, tmp, data, size);
+3, tmp, data,
+fold_convert (size_type_node, size));
}
gfc_add_expr_to_block (&se->post, tmp);
--- gcc/fortran/trans-array.c.jj2012-11-01 09:33:28.0 +0100
+++ gcc/fortran/trans-array.c 2012-11-16 11:49:46.875541899 +0100
@@ -7341,8 +7341,8 @@ duplicate_allocatable (tree dest, tree s
}
tmp = builtin_decl_explicit (BUILT_IN_MEMCPY);
- tmp = build_call_expr_loc (input_location, tmp, 3,
-dest, src, size);
+ tmp = build_call_expr_loc (input_location, tmp, 3, dest, src,
+fold_convert (size_type_node, size));
}
else
{
@@ -7367,7 +7367,8 @@ duplicate_allocatable (tree dest, tree s
tmp = builtin_decl_explicit (BUILT_IN_MEMCPY);
tmp = build_call_expr_loc (input_location,
tmp, 3, gfc_conv_descriptor_data_get (dest),
- gfc_conv_descriptor_data_get (src), size);
+ gfc_conv_descriptor_data_get (src),
+ fold_convert (size_type_node, size));
}
gfc_add_expr_to_block (&block, tmp);
Jakub
Re: [PATCH] Fix up builtin memcpy calls generated by Fortran FE (PR fortran/55341)
Hi Jakub, Hi! This PR is about ASAN failing with checking failures. The problem is on the Fortran FE side, which calls BUILT_IN_MEMCPY sometimes with wrong type of the last argument (which is not type compatible with the size_type_node type). Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? OK. Thanks a lot for the patch! Thomas
[PATCH] Avoid unnecessary __cxa_quard_{acquire,release} (PR middle-end/54630)
Hi!
This PR points out that unnecessarily in two gcc spots we now use
__cxa_guard_acquire/release. In the first case, there is no point to
make the var static, it is always created and disposed in the same function,
so making it an automatic variable is certainly cheaper, there is no need
to initialize anything in global ctors, the local initialization is just
= NULL overridden almost immediately by assignment in create anyway.
The other change is perhaps more controversial, it is tiny bit nicer to
have the variable local static, but it is more costly.
In any case, both changes passed bootstrap/regtest on x86_64-linux
and i686-linux, ok?
2012-11-16 Jakub Jelinek
PR middle-end/54630
* tree-ssa-coalesce.c (coalesce_ssa_name): Remove static
keyword from ssa_name_hash var.
* class.c (fixed_type_or_null_ref_ht): New variable.
(fixed_type_or_null): Use it instead of local static ht.
--- gcc/tree-ssa-coalesce.c.jj 2012-10-26 18:05:03.0 +0200
+++ gcc/tree-ssa-coalesce.c 2012-11-16 16:09:47.302657256 +0100
@@ -1,5 +1,5 @@
/* Coalesce SSA_NAMES together for the out-of-ssa pass.
- Copyright (C) 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011
+ Copyright (C) 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012
Free Software Foundation, Inc.
Contributed by Andrew MacLeod
@@ -1292,7 +1292,6 @@ coalesce_ssa_name (void)
bitmap used_in_copies = BITMAP_ALLOC (NULL);
var_map map;
unsigned int i;
- static hash_table ssa_name_hash;
cl = create_coalesce_list ();
map = create_outofssa_var_map (cl, used_in_copies);
@@ -1301,6 +1300,8 @@ coalesce_ssa_name (void)
so debug info remains undisturbed. */
if (!optimize)
{
+ hash_table ssa_name_hash;
+
ssa_name_hash.create (10);
for (i = 1; i < num_ssa_names; i++)
{
--- gcc/cp/class.c.jj 2012-11-16 12:39:15.0 +0100
+++ gcc/cp/class.c 2012-11-16 16:13:32.963262681 +0100
@@ -6567,6 +6567,9 @@ finish_struct (tree t, tree attributes)
return t;
}
+/* Hash table to avoid endless recursion when handling references. */
+static hash_table > fixed_type_or_null_ref_ht;
+
/* Return the dynamic type of INSTANCE, if known.
Used to determine whether the virtual function table is needed
or not.
@@ -6682,9 +6685,8 @@ fixed_type_or_null (tree instance, int *
else if (TREE_CODE (TREE_TYPE (instance)) == REFERENCE_TYPE)
{
/* We only need one hash table because it is always left empty. */
- static hash_table > ht;
- if (!ht.is_created ())
- ht.create (37);
+ if (!fixed_type_or_null_ref_ht.is_created ())
+ fixed_type_or_null_ref_ht.create (37);
/* Reference variables should be references to objects. */
if (nonnull)
@@ -6696,15 +6698,15 @@ fixed_type_or_null (tree instance, int *
if (TREE_CODE (instance) == VAR_DECL
&& DECL_INITIAL (instance)
&& !type_dependent_expression_p_push (DECL_INITIAL (instance))
- && !ht.find (instance))
+ && !fixed_type_or_null_ref_ht.find (instance))
{
tree type;
tree_node **slot;
- slot = ht.find_slot (instance, INSERT);
+ slot = fixed_type_or_null_ref_ht.find_slot (instance, INSERT);
*slot = instance;
type = RECUR (DECL_INITIAL (instance));
- ht.remove_elt (instance);
+ fixed_type_or_null_ref_ht.remove_elt (instance);
return type;
}
Jakub
[PATCH, PR 55260] Use info of the correct node in find_aggregate_values_for_callers_subset
Hi,
PR 55260 contains two testcases which trigger two different bugs in
ipa-cp.c. The first problem is that at one place in
find_aggregate_values_for_callers_subset we use variable info instead
of caller_info when determining whether a callee is a clone which then
leads to an ICE. Fixed thusly and I also renamed info to dest_info to
make similar mistakes harder to make in future.
Fix of the second PR 55260 bug will probably involve some fiddling
with vectors so I'll submit it next week when the new interface is in
place.
Bootstrapped and tested on x86_64-linux, OK for trunk?
Thanks,
Martin
2012-11-16 Martin Jambor
PR tree-optimization/55260
* ipa-cp.c (find_aggregate_values_for_callers_subset): Rename info to
dest_info, use caller_info instead of info when determining whether
callee is a clone.
* testsuite/g++.dg/torture/pr55260-1.C: New test.
Index: src/gcc/testsuite/g++.dg/torture/pr55260-1.C
===
--- /dev/null
+++ src/gcc/testsuite/g++.dg/torture/pr55260-1.C
@@ -0,0 +1,24 @@
+/* { dg-do compile } */
+/* { dg-options "-std=gnu++0x -fno-inline" } */
+/* { dg-add-options bind_pic_locally } */
+
+ struct B
+ {
+ constexpr B ():
+bp ()
+{}
+~B ()
+{
+ if (bp)
+ bp->f ();
+}
+void f ();
+B *bp;
+ };
+struct A {B b;
+};
+
+void foo ()
+{
+ A a;
+}
Index: src/gcc/ipa-cp.c
===
--- src.orig/gcc/ipa-cp.c
+++ src/gcc/ipa-cp.c
@@ -2870,10 +2870,10 @@ static struct ipa_agg_replacement_value
find_aggregate_values_for_callers_subset (struct cgraph_node *node,
VEC (cgraph_edge_p,heap) *callers)
{
- struct ipa_node_params *info = IPA_NODE_REF (node);
+ struct ipa_node_params *dest_info = IPA_NODE_REF (node);
struct ipa_agg_replacement_value *res = NULL;
struct cgraph_edge *cs;
- int i, j, count = ipa_get_param_count (info);
+ int i, j, count = ipa_get_param_count (dest_info);
FOR_EACH_VEC_ELT (cgraph_edge_p, callers, j, cs)
{
@@ -2891,7 +2891,7 @@ find_aggregate_values_for_callers_subset
/* Among other things, the following check should deal with all by_ref
mismatches. */
- if (ipa_get_parm_lattices (info, i)->aggs_bottom)
+ if (ipa_get_parm_lattices (dest_info, i)->aggs_bottom)
continue;
FOR_EACH_VEC_ELT (cgraph_edge_p, callers, j, cs)
@@ -2943,7 +2943,7 @@ find_aggregate_values_for_callers_subset
struct ipcp_param_lattices *src_plats;
HOST_WIDE_INT delta = ipa_get_jf_ancestor_offset (jfunc);
- if (info->ipcp_orig_node)
+ if (caller_info->ipcp_orig_node)
{
if (!inter)
inter = agg_replacements_to_vector (cs->caller, delta);
Re: [PING] [PATCH] PR c++/54401 - Confusing diagnostics about type-alias at class scope
Gabriel Dos Reis a écrit:
> On Fri, Nov 16, 2012 at 8:51 AM, Jason Merrill wrote:
>> Would it work to just do a cp_parser_commit_to_tentative_parse after we see
>> the '='?
I guess you mean in cp_parser_alias_declaration like in the updated
patch below?
> I like that solution better.
Ok, thanks.
I just had to adjust the call to cp_parser_alias_declaration when called
in the context of a tentative parse, to handle the case where an error
occurs before we reach the '=' token; which means that the tentative
parse can still be cancelled.
Bootstrapped and tested on x86_64-unknown-linux-gnu against trunk.
gcc/cp/
* parser.c (cp_parser_alias_declaration): Commit to tentative
parse when see the '=' token. Get out if the type-id is invalid.
Update function comment.
(cp_parser_member_declaration): Don't try to parse a using
declaration if we know that we expected an alias declaration; that
is, if we see the '=' token after the identifier.
gcc/testsuite/
* g++.dg/cpp0x/alias-decl-28.C: New test.
* g++.dg/cpp0x/alias-decl-16.C: Update.
---
gcc/cp/parser.c| 23 +--
gcc/testsuite/g++.dg/cpp0x/alias-decl-16.C | 2 +-
gcc/testsuite/g++.dg/cpp0x/alias-decl-28.C | 7 +++
3 files changed, 29 insertions(+), 3 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/cpp0x/alias-decl-28.C
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 7107134..2b76670 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -15260,7 +15260,11 @@ cp_parser_using_declaration (cp_parser* parser,
/* Parse an alias-declaration.
alias-declaration:
- using identifier attribute-specifier-seq [opt] = type-id */
+ using identifier attribute-specifier-seq [opt] = type-id
+
+ Note that if this function is used in the context of a tentative
+ parse, it commits the currently active tentative parse after it
+ sees the '=' token. */
static tree
cp_parser_alias_declaration (cp_parser* parser)
@@ -15293,6 +15297,8 @@ cp_parser_alias_declaration (cp_parser* parser)
if (cp_parser_error_occurred (parser))
return error_mark_node;
+ cp_parser_commit_to_tentative_parse (parser);
+
/* Now we are going to parse the type-id of the declaration. */
/*
@@ -15322,6 +15328,9 @@ cp_parser_alias_declaration (cp_parser* parser)
if (parser->num_template_parameter_lists)
parser->type_definition_forbidden_message = saved_message;
+ if (type == error_mark_node)
+return error_mark_node;
+
cp_parser_require (parser, CPP_SEMICOLON, RT_SEMICOLON);
if (cp_parser_error_occurred (parser))
@@ -19058,9 +19067,19 @@ cp_parser_member_declaration (cp_parser* parser)
else
{
tree decl;
+ bool alias_decl_expected;
cp_parser_parse_tentatively (parser);
decl = cp_parser_alias_declaration (parser);
- if (cp_parser_parse_definitely (parser))
+ /* Note that if we actually see the '=' token after the
+identifier, cp_parser_alias_declaration commits the
+tentative parse. In that case, we really expects an
+alias-declaration. Otherwise, we expect a using
+declaration. */
+ alias_decl_expected =
+ !cp_parser_uncommitted_to_tentative_parse_p (parser);
+ cp_parser_parse_definitely (parser);
+
+ if (alias_decl_expected)
finish_member_declaration (decl);
else
cp_parser_using_declaration (parser,
diff --git a/gcc/testsuite/g++.dg/cpp0x/alias-decl-16.C
b/gcc/testsuite/g++.dg/cpp0x/alias-decl-16.C
index d0a..ce6ad0a 100644
--- a/gcc/testsuite/g++.dg/cpp0x/alias-decl-16.C
+++ b/gcc/testsuite/g++.dg/cpp0x/alias-decl-16.C
@@ -23,6 +23,6 @@ template
using A3 =
enum B3 {b = 0;}; //{ dg-error "types may not be defined in alias
template" }
-A3 a3;
+A3 a3; // { dg-error "'A3' does not name a type" }
int main() { }
diff --git a/gcc/testsuite/g++.dg/cpp0x/alias-decl-28.C
b/gcc/testsuite/g++.dg/cpp0x/alias-decl-28.C
new file mode 100644
index 000..086b5e5
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/alias-decl-28.C
@@ -0,0 +1,7 @@
+// Origin: PR c++/54401
+// { dg-do compile { target c++11 } }
+
+template
+struct X {
+using type = T; // { dg-error "expected type-specifier|does not name a
type" }
+};
--
Dodji
Re: VEC re-write [patch 20/25]
On Thu, Nov 15, 2012 at 4:54 PM, Diego Novillo wrote: > 2012-11-15 Diego Novillo > > Adjust for new vec API > (http://gcc.gnu.org/wiki/cxx-conversion/cxx-vec) > > * config/rs6000/rs6000-c.c: Use new vec API in vec.h. > * config/rs6000/rs6000.c: Likewise. Okay. Thanks, David
Re: VEC re-write [patch 22/25]
On Thu, Nov 15, 2012 at 4:54 PM, Diego Novillo wrote: > 2012-11-15 Diego Novillo > > Adjust for new vec API > (http://gcc.gnu.org/wiki/cxx-conversion/cxx-vec) > > * config/spu/spu-c.c: Use new vec API in vec.h. Okay. Thanks, David
C++ PATCH: tidy diagnostic about invalid of use of automatic variable
Now that we can actually declare a variable as `auto', it becomes
important to be precise in our terminology when diagnosing invalid
uses of variables with automatic storage -- especially if the variable
isn't declared 'auto'.
Applied to trunk.
-- Gaby
2012-11-17 Gabriel Dos Reis
* semantics.c (finish_id_expression): Tidy diagnostic message.
Index: semantics.c
===
--- semantics.c (revision 193586)
+++ semantics.c (working copy)
@@ -3041,7 +3041,7 @@
else
{
error (TREE_CODE (decl) == VAR_DECL
-? G_("use of % variable from containing function")
+? G_("use of local variable with automatic storage from
containing function")
: G_("use of parameter from containing function"));
error (" %q+#D declared here", decl);
return error_mark_node;
Re: [PATCH] Avoid unnecessary __cxa_quard_{acquire,release} (PR middle-end/54630)
I suppose these changes are fine, but it might be more future-proof to compile with -fno-threadsafe-statics...or fix the build system so that the C++ library is available when linking the compiler. Jason
patch to fix PR55342
The following patch solves
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55342
LRA after spilling a pseudo tries to assign freed hard regno to other
reload pseudos and chooses the best. The more reload pseudos got the
freed hard regno, the less cost of spilling. But the reload pseudos
could get another hard regno without spilling. So LRA code before the
patch incorrectly evaluated the cost of spilling. The patch tries to
allocate a hard reg to the other reload pseudos before and after
spilling in order to correctly evaluate spilling cost.
The patch was successfully bootstrapped on x86/x86-64.
Committed as rev. 193588.
2012-11-17 Vladimir Makarov
PR rtl-optimization/55342
* lra-assigns.c (spill_for): Try to allocate other reload pseudos
before and after spilling.
Index: lra-assigns.c
===
--- lra-assigns.c (revision 193557)
+++ lra-assigns.c (working copy)
@@ -795,9 +795,8 @@ spill_for (int regno, bitmap spilled_pse
{
int i, j, n, p, hard_regno, best_hard_regno, cost, best_cost, rclass_size;
int reload_hard_regno, reload_cost;
- enum machine_mode mode, mode2;
+ enum machine_mode mode;
enum reg_class rclass;
- HARD_REG_SET spilled_hard_regs;
unsigned int spill_regno, reload_regno, uid;
int insn_pseudos_num, best_insn_pseudos_num;
lra_live_range_t r;
@@ -838,7 +837,6 @@ spill_for (int regno, bitmap spilled_pse
&try_hard_reg_pseudos[hard_regno + j]);
}
/* Spill pseudos. */
- CLEAR_HARD_REG_SET (spilled_hard_regs);
EXECUTE_IF_SET_IN_BITMAP (&spill_pseudos_bitmap, 0, spill_regno, bi)
if ((int) spill_regno >= lra_constraint_new_regno_start
&& ! bitmap_bit_p (&lra_inheritance_pseudos, spill_regno)
@@ -853,13 +851,6 @@ spill_for (int regno, bitmap spilled_pse
{
if (bitmap_bit_p (&insn_conflict_pseudos, spill_regno))
insn_pseudos_num++;
- mode2 = PSEUDO_REGNO_MODE (spill_regno);
- update_lives (spill_regno, true);
- if (lra_dump_file != NULL)
- fprintf (lra_dump_file, " spill %d(freq=%d)",
-spill_regno, lra_reg_info[spill_regno].freq);
- add_to_hard_reg_set (&spilled_hard_regs,
- mode2, reg_renumber[spill_regno]);
for (r = lra_reg_info[spill_regno].live_ranges;
r != NULL;
r = r->next)
@@ -877,19 +868,26 @@ spill_for (int regno, bitmap spilled_pse
}
}
}
+ n = 0;
+ EXECUTE_IF_SET_IN_SPARSESET (live_range_reload_inheritance_pseudos,
+ reload_regno)
+ if ((int) reload_regno != regno
+ && (ira_reg_classes_intersect_p
+ [rclass][regno_allocno_class_array[reload_regno]])
+ && live_pseudos_reg_renumber[reload_regno] < 0
+ && find_hard_regno_for (reload_regno, &cost, -1) < 0)
+ sorted_reload_pseudos[n++] = reload_regno;
+ EXECUTE_IF_SET_IN_BITMAP (&spill_pseudos_bitmap, 0, spill_regno, bi)
+ {
+ update_lives (spill_regno, true);
+ if (lra_dump_file != NULL)
+ fprintf (lra_dump_file, " spill %d(freq=%d)",
+spill_regno, lra_reg_info[spill_regno].freq);
+ }
hard_regno = find_hard_regno_for (regno, &cost, -1);
if (hard_regno >= 0)
{
assign_temporarily (regno, hard_regno);
- n = 0;
- EXECUTE_IF_SET_IN_SPARSESET (live_range_reload_inheritance_pseudos,
- reload_regno)
- if (live_pseudos_reg_renumber[reload_regno] < 0
- && (hard_reg_set_intersect_p
- (reg_class_contents
-[regno_allocno_class_array[reload_regno]],
-spilled_hard_regs)))
- sorted_reload_pseudos[n++] = reload_regno;
qsort (sorted_reload_pseudos, n, sizeof (int),
reload_pseudo_compare_func);
for (j = 0; j < n; j++)
@@ -898,10 +896,7 @@ spill_for (int regno, bitmap spilled_pse
lra_assert (live_pseudos_reg_renumber[reload_regno] < 0);
if ((reload_hard_regno
= find_hard_regno_for (reload_regno,
- &reload_cost, -1)) >= 0
- && (overlaps_hard_reg_set_p
- (spilled_hard_regs,
- PSEUDO_REGNO_MODE (reload_regno), reload_hard_regno)))
+ &reload_cost, -1)) >= 0)
{
if (lra_dump_file != NULL)
fprintf (lra_dump_file, " assign %d(cost=%d)",
Re: [PATCH, generic] New RTL primitive: `define_subst'
On 11/15/2012 05:50 AM, Kirill Yukhin wrote: > Hi guys, > thanks for review. Comments along with updated patch are below. Version 6 is now ok. Please apply. r~
Re: [COMMITTED] Move libsanitizer configure logic to subdirectory
On 11/16/2012 11:55 PM, Hans-Peter Nilsson wrote: >> > +# the Free Software Foundation; either version 2 of the License, or >> > +# (at your option) any later version. > Heh, "version 2"... > But licensing changes are never obvious, right? Heh. I noticed and fixed the use of the old Boston street address in the place I copied it from, but failed to notice the version number. r~
Re: [patch] instrument clones
On 11/16/2012 01:28 PM, Aldy Hernandez wrote: > * trans-mem (collect_bb2reg): Stop scanning at irrevocable > * blocks. > (get_bb_regions_instrumented): Add new traverse_clone argument and > use it. > (expand_regions_1): Same. > (expand_region): Same. > (execute_tm_mark): Pass new argument to expand_regions. > (expand_block_edges): Pass new argument to > get_bb_regions_instrumented. > testsuite/ > * g++.dg/tm/pr51516.C: Adjust for uninstrumented code path. > * gcc.dg/tm/clone-1.c: New test. Ok. r~
Re: Patch ping
On 11/16/2012 01:10 AM, Jakub Jelinek wrote: > - PR55188 testcase fix for targets with different branch cost > http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00361.html Ok. r~
Re: Patch ping
On 11/16/2012 01:10 AM, Jakub Jelinek wrote: > - PR55236 range test optimization fix with -fwrapv > http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00707.html > (perhaps PLUS_EXPR can be handled similarly instead of bailing out) > Ok. r~
Re: ASAN merge...
On 11/16/2012 04:35 PM, Ian Lance Taylor wrote: I expect it's pronounced with a sort of throat-clearing noise that is hard to write. Sort of like the gargling sound represented by "argh." argh32 and argh64. I thought it was a nice way to enshrine a Monty Python joke into silicon. -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
PATCH: Add -static-libasan to the GCC driver
Hi,
This patch adds -static-libasan. OK to install?
Thanks.
H.J.
---
2012-11-17 H.J. Lu
* common.opt (static-libasan): New option.
* gcc.c (LIBASAN_SPEC): New macro.
(LINK_COMMAND_SPEC): Replace -lasan with LIBASAN_SPEC.
* doc/invoke.texi: Document -static-libasan.
diff --git a/gcc/common.opt b/gcc/common.opt
index 0a7c953..be6fe4f 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -2516,6 +2516,9 @@ static-libgo
Driver
; Documented for Go, but always accepted by driver.
+static-libasan
+Driver
+
symbolic
Driver
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index b3abc09..885bf66 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -452,8 +452,8 @@ Objective-C and Objective-C++ Dialects}.
@xref{Link Options,,Options for Linking}.
@gccoptlist{@var{object-file-name} -l@var{library} @gol
-nostartfiles -nodefaultlibs -nostdlib -pie -rdynamic @gol
--s -static -static-libgcc -static-libstdc++ -shared @gol
--shared-libgcc -symbolic @gol
+-s -static -static-libgcc -static-libasan -static-libstdc++ @gol
+-shared -shared-libgcc -symbolic @gol
-T @var{script} -Wl,@var{option} -Xlinker @var{option} @gol
-u @var{symbol}}
@@ -9937,6 +9937,15 @@ for the languages used in the program, or using the
option
@option{-shared-libgcc}, such that it is linked with the shared
@file{libgcc}.
+@item -static-libasan
+When the @option{-faddress-sanitizer} option is used to link a program,
+the GCC driver automatically links against @option{libasan}. If
+@file{libasan} is available as a shared library, and the @option{-static}
+option is not used, then this links against the shared version of
+@file{libasan}. The @option{-static-libasan} option directs the GCC
+driver to link @file{libasan} statically, without necessarily linking
+other libraries statically.
+
@item -static-libstdc++
When the @command{g++} program is used to link a C++ program, it
normally automatically links against @option{libstdc++}. If
diff --git a/gcc/gcc.c b/gcc/gcc.c
index e584319..7a275e1 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -544,6 +544,15 @@ proper position among the other output files. */
wrapping. */
#define STACK_SPLIT_SPEC " %{fsplit-stack: --wrap=pthread_create}"
+#ifndef LIBASAN_SPEC
+#ifdef HAVE_LD_STATIC_DYNAMIC
+#define LIBASAN_SPEC "%{static-libasan:" LD_STATIC_OPTION \
+"} -lasan %{static-libasan:" LD_DYNAMIC_OPTION "}"
+#else
+#define LIBASAN_SPEC "-lasan"
+#endif
+#endif
+
/* config.h can define LIBGCC_SPEC to override how and when libgcc.a is
included. */
#ifndef LIBGCC_SPEC
@@ -687,7 +696,7 @@ proper position among the other output files. */
%{fgnu-tm:%:include(libitm.spec)%(link_itm)}\
%(mflib) " STACK_SPLIT_SPEC "\
%{fprofile-arcs|fprofile-generate*|coverage:-lgcov}\
-%{faddress-sanitizer:-lasan}\
+%{faddress-sanitizer:" LIBASAN_SPEC "}\
%{!nostdlib:%{!nodefaultlibs:%(link_ssp) %(link_gcc_c_sequence)}}\
%{!nostdlib:%{!nostartfiles:%E}} %{T*} }}"
#endif
Re: Patch ping
On 11/16/2012 01:10 AM, Jakub Jelinek wrote: > Hi! > > - PR54921 invalidate sp in cselib on fp setter insn > http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02035.html > (perhaps in light of PR54402 the single_succ (ENTRY_BLOCK_PTR) > from the patch should be nuked) > + rtx expr = find_reg_note (insn, REG_FRAME_RELATED_EXPR, NULL_RTX); > + if (expr) > + pat = XEXP (expr, 0); > + if (GET_CODE (pat) == SET > + && SET_DEST (pat) == hard_frame_pointer_rtx) > + cselib_invalidate_rtx (stack_pointer_rtx); > + else if (GET_CODE (pat) == PARALLEL) This is only one possible way that FP can be set. The others are with CFA_DEF_CFA or CFA_ADJUST_CFA. Given + && frame_pointer_needed + && RTX_FRAME_RELATED_P (insn) is there any reason to do more than && modified_in_p (hard_frame_pointer_rtx, insn) ? r~
Re: PATCH: Add -static-libasan to the GCC driver
On Sat, Nov 17, 2012 at 12:00:00PM -0800, H.J. Lu wrote: > This patch adds -static-libasan. OK to install? Okay, thanks. > 2012-11-17 H.J. Lu > > * common.opt (static-libasan): New option. > * gcc.c (LIBASAN_SPEC): New macro. > (LINK_COMMAND_SPEC): Replace -lasan with LIBASAN_SPEC. > * doc/invoke.texi: Document -static-libasan. Jakub
Re: User directed Function Multiversioning via Function Overloading (issue5752064)
On Tue, Nov 13, 2012 at 1:57 PM, Sriraman Tallam wrote: > Patch committed now after making the changes. > Your libgcc change caused: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55370 -- H.J.
Re: [PATCH] Enable building of libsanitizer on sparc linux again.
> So, here is the (IMO obvious) patch to enable libsanitizer's build on > sparc linux, even if asan is not supported on that platform yet. > > OK for trunk? > > libsanitizer/ChangeLog: > > * configure.tgt: Enable sparc linux. libtool: compile: /home/ebotcazou/build/./gcc/g++ - B/home/ebotcazou/build/./gcc/ -nostdinc++ -nostdinc++ - I/home/ebotcazou/build/sparc64-linux-gnu/64/libstdc++-v3/include/sparc64- linux-gnu -I/home/ebotcazou/build/sparc64-linux-gnu/64/libstdc++-v3/include - I/home/ebotcazou/src/libstdc++-v3/libsupc++ -I/home/ebotcazou/src/libstdc++- v3/include/backward -I/home/ebotcazou/src/libstdc++-v3/testsuite/util - L/home/ebotcazou/build/sparc64-linux-gnu/64/libstdc++-v3/src - L/home/ebotcazou/build/sparc64-linux-gnu/64/libstdc++-v3/src/.libs - B/home/ebotcazou/install/sparc64-linux-gnu/bin/ - B/home/ebotcazou/install/sparc64-linux-gnu/lib/ -isystem /home/ebotcazou/install/sparc64-linux-gnu/include -isystem /home/ebotcazou/install/sparc64-linux-gnu/sys-include -m64 -D_GNU_SOURCE - D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I. -I/home/ebotcazou/src/libsanitizer/sanitizer_common -I /home/ebotcazou/src/libsanitizer/include -Wall -W -Wno-unused-parameter - Wwrite-strings -pedantic -Wno-long-long -fPIC -fno-builtin -fno-exceptions - fomit-frame-pointer -funwind-tables -fvisibility=hidden -Wno-variadic-macros - Wno-c99-extensions -g -O2 -D_GNU_SOURCE -m64 -MT sanitizer_linux.lo -MD -MP - MF .deps/sanitizer_linux.Tpo -c /home/ebotcazou/src/libsanitizer/sanitizer_common/sanitizer_linux.cc -fPIC - DPIC -o .libs/sanitizer_linux.o /home/ebotcazou/src/libsanitizer/sanitizer_common/sanitizer_linux.cc: In function 'void* __sanitizer::internal_mmap(void*, __sanitizer::uptr, int, int, int, __sanitizer::u64)': /home/ebotcazou/src/libsanitizer/sanitizer_common/sanitizer_linux.cc:40:26: error: '__NR_mmap2' was not declared in this scope return (void *)syscall(__NR_mmap2, addr, length, prot, flags, fd, offset); ^ /home/ebotcazou/src/libsanitizer/sanitizer_common/sanitizer_linux.cc:42:1: warning: control reaches end of non-void function [-Wreturn-type] } ^ At global scope: cc1plus: warning: unrecognized command line option "-Wno-c99-extensions" [enabled by default] make[5]: *** [sanitizer_linux.lo] Error 1 -- Eric Botcazou
Re: PATCH: Add -static-libasan to the GCC driver
On Sat, Nov 17, 2012 at 12:22 PM, Jakub Jelinek wrote:
> On Sat, Nov 17, 2012 at 12:00:00PM -0800, H.J. Lu wrote:
>> This patch adds -static-libasan. OK to install?
>
> Okay, thanks.
>
>> 2012-11-17 H.J. Lu
>>
>> * common.opt (static-libasan): New option.
>> * gcc.c (LIBASAN_SPEC): New macro.
>> (LINK_COMMAND_SPEC): Replace -lasan with LIBASAN_SPEC.
>> * doc/invoke.texi: Document -static-libasan.
>
> Jakub
This patch adds STATIC_LIBASAN_LIBS so that user doesn't
need to add -ldl -lpthread by hand. OK to install?
Thanks.
--
H.J.
---
2012-11-17 H.J. Lu
* gcc.c (STATIC_LIBASAN_LIBS): New macro.
(LIBASAN_SPEC): Add STATIC_LIBASAN_LIBS.
* config/gnu-user.h (STATIC_LIBASAN_LIBS): New macro.
diff --git a/gcc/config/gnu-user.h b/gcc/config/gnu-user.h
index cb45749..8c4bbc6 100644
--- a/gcc/config/gnu-user.h
+++ b/gcc/config/gnu-user.h
@@ -98,3 +98,7 @@ see the files COPYING3 and COPYING.RUNTIME
respectively. If not, see
#define TARGET_C99_FUNCTIONS 1
#define TARGET_HAS_SINCOS 1
+
+/* Additional libraries needed by -static-libasan. */
+#undef STATIC_LIBASAN_LIBS
+#define STATIC_LIBASAN_LIBS "-ldl -lpthread"
diff --git a/gcc/gcc.c b/gcc/gcc.c
index 7a275e1..ef8a485 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -546,8 +546,12 @@ proper position among the other output files. */
#ifndef LIBASAN_SPEC
#ifdef HAVE_LD_STATIC_DYNAMIC
+#ifndef STATIC_LIBASAN_LIBS
+#define STATIC_LIBASAN_LIBS
+#endif
#define LIBASAN_SPEC "%{static-libasan:" LD_STATIC_OPTION \
-"} -lasan %{static-libasan:" LD_DYNAMIC_OPTION "}"
+"} -lasan %{static-libasan:" LD_DYNAMIC_OPTION \
+" " STATIC_LIBASAN_LIBS "}"
#else
#define LIBASAN_SPEC "-lasan"
#endif
PATCH: Add --with-build-config=bootstrap-asan support
Hi,
This patch adds --with-build-config=bootstrap-asan support. OK to
install?
Thanks.
H.J.
---
2012-11-17 H.J. Lu
* Makefile.def (target_modules): Add bootstrap=true for
libsanitizer.
* Makefile.tpl (LIBASAN_LIBS): New for gcc-bootstrap. Defined
if $(BUILD_CONFIG) contains bootstrap-asan.
(POSTSTAGE1_CXX_EXPORT): Add $(LIBASAN_LIBS) to CXX.
(POSTSTAGE1_HOST_EXPORTS): Add $(LIBASAN_LIBS) to CC.
* configure.ac (bootstrap_target_libs): Add libsanitizer.
* Makefile.in: Regenerated.
* configure: Likewise.
config/
2012-11-17 H.J. Lu
* bootstrap-asan.mk: New file.
diff --git a/Makefile.def b/Makefile.def
index 1ea63ac..8d54ad2 100644
--- a/Makefile.def
+++ b/Makefile.def
@@ -119,7 +119,7 @@ target_modules = { module= libstdc++-v3;
lib_path=src/.libs;
raw_cxx=true; };
target_modules = { module= libmudflap; lib_path=.libs; };
-target_modules = { module= libsanitizer; lib_path=.libs; };
+target_modules = { module= libsanitizer; bootstrap=true; lib_path=.libs; };
target_modules = { module= libssp; lib_path=.libs; };
target_modules = { module= newlib; };
target_modules = { module= libgcc; bootstrap=true; no_check=true; };
diff --git a/Makefile.tpl b/Makefile.tpl
index 14a..e40e92b 100644
--- a/Makefile.tpl
+++ b/Makefile.tpl
@@ -131,6 +131,12 @@ POSTSTAGE1_LDFLAGS = @poststage1_ldflags@
# Libraries to use for stage2 and later.
POSTSTAGE1_LIBS = @poststage1_libs@
+@if gcc-bootstrap
+ifneq ($(filter bootstrap-asan,$(BUILD_CONFIG)),)
+LIBASAN_LIBS=-B$$r/prev-$(TARGET_SUBDIR)/libsanitizer/asan/.libs
+endif
+@endif gcc-bootstrap
+
# This is the list of variables to export in the environment when
# configuring any subdirectory. It must also be exported whenever
# recursing into a build directory in case that directory's Makefile
@@ -242,6 +248,7 @@ POSTSTAGE1_CXX_EXPORT = \
-B$$r/$(HOST_SUBDIR)/prev-gcc/ -B$(build_tooldir)/bin/ -nostdinc++ \
-B$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/src/.libs \
-B$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/libsupc++/.libs \
+ $(LIBASAN_LIBS) \
-I$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/include/$(TARGET_SUBDIR) \
-I$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/include \
-I$$s/libstdc++-v3/libsupc++ \
@@ -256,6 +263,7 @@ POSTSTAGE1_HOST_EXPORTS = \
$(HOST_EXPORTS) \
CC="$(STAGE_CC_WRAPPER) $$r/$(HOST_SUBDIR)/prev-gcc/xgcc$(exeext) \
-B$$r/$(HOST_SUBDIR)/prev-gcc/ -B$(build_tooldir)/bin/ \
+ $(LIBASAN_LIBS) \
$(XGCC_FLAGS_FOR_TARGET) $$TFLAGS"; export CC; \
CC_FOR_BUILD="$$CC"; export CC_FOR_BUILD; \
$(POSTSTAGE1_CXX_EXPORT) \
diff --git a/config/bootstrap-asan.mk b/config/bootstrap-asan.mk
new file mode 100644
index 000..cae203b
--- /dev/null
+++ b/config/bootstrap-asan.mk
@@ -0,0 +1,5 @@
+# This option enables -faddress-sanitizer for stage2 and stage3.
+
+STAGE2_CFLAGS += -faddress-sanitizer
+STAGE3_CFLAGS += -faddress-sanitizer
+POSTSTAGE1_LDFLAGS += -faddress-sanitizer -static-libasan
diff --git a/configure.ac b/configure.ac
index 24ea7e5..64e0387 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2433,6 +2433,11 @@ if echo " ${target_configdirs} " | grep " libgomp " >
/dev/null 2>&1 ; then
bootstrap_target_libs=${bootstrap_target_libs}target-libgomp,
fi
+# If we are building libsanitizer, bootstrap it.
+if echo " ${target_configdirs} " | grep " libsanitizer " > /dev/null 2>&1 ;
then
+ bootstrap_target_libs=${bootstrap_target_libs}target-libsanitizer,
+fi
+
# Determine whether gdb needs tk/tcl or not.
# Use 'maybe' since enable_gdbtk might be true even if tk isn't available
# and in that case we want gdb to be built without tk. Ugh!
Re: [PATCH] Enable building of libsanitizer on sparc linux again.
From: Eric Botcazou Date: Sun, 18 Nov 2012 00:18:15 +0100 > error: '__NR_mmap2' was not declared in this scope >return (void *)syscall(__NR_mmap2, addr, length, prot, flags, fd, offset); The people making libsanitizer changes are really going to have to stop making i386 specific changes to these generic files. Specifically, in this case, they are checking for whether mmap2 is available using __x86_64__ cpp tests. A more appropriate test is necessary. Oh nevermind, H.J. Liu added this build regression, I should have known. H.J., either fix or revert this code back to using __WORDSIZE if you cannot come up with an appropriate test.
Re: [PATCH] Enable building of libsanitizer on sparc linux again.
On Sat, Nov 17, 2012 at 4:04 PM, David Miller wrote: > From: Eric Botcazou > Date: Sun, 18 Nov 2012 00:18:15 +0100 > >> error: '__NR_mmap2' was not declared in this scope >>return (void *)syscall(__NR_mmap2, addr, length, prot, flags, fd, offset); > > The people making libsanitizer changes are really going to have to > stop making i386 specific changes to these generic files. > > Specifically, in this case, they are checking for whether mmap2 is > available using __x86_64__ cpp tests. A more appropriate test is > necessary. > > Oh nevermind, H.J. Liu added this build regression, I should have > known. > > H.J., either fix or revert this code back to using __WORDSIZE if you > cannot come up with an appropriate test. Please follow: http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00951.html -- H.J.
Re: [PATCH] Enable building of libsanitizer on sparc linux again.
From: "H.J. Lu" Date: Sat, 17 Nov 2012 16:06:23 -0800 > On Sat, Nov 17, 2012 at 4:04 PM, David Miller wrote: >> From: Eric Botcazou >> Date: Sun, 18 Nov 2012 00:18:15 +0100 >> >>> error: '__NR_mmap2' was not declared in this scope >>>return (void *)syscall(__NR_mmap2, addr, length, prot, flags, fd, >>> offset); >> >> The people making libsanitizer changes are really going to have to >> stop making i386 specific changes to these generic files. >> >> Specifically, in this case, they are checking for whether mmap2 is >> available using __x86_64__ cpp tests. A more appropriate test is >> necessary. >> >> Oh nevermind, H.J. Liu added this build regression, I should have >> known. >> >> H.J., either fix or revert this code back to using __WORDSIZE if you >> cannot come up with an appropriate test. > > Please follow: > > http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00951.html The whole way this libsanitizer merge is being handled is beyond unreasonable. A build fix being held up for 4 days just proves that requiring things get merged into LLVM first is completely the wrong way for this stuff to work. The people who merged in this library should be responsible for keeping changes in sync, not the individual developers who fix bugs and make improvements to this code on the gcc side. It's lunacy that this build problem is in the tree for 4 days because of this.
Re: VEC re-write [patch 01/25]
On Thu, Nov 15, 2012 at 4:53 PM, Diego Novillo wrote: > I have tested the patch pretty extensively: > > - Regular bootstraps on x86_64, ppc, ia64, sparc and hppa. > - Bootstraps with --enable-checking=release > - Bootstraps with --enable-checking=gc,gcac > - Basic builds on all targets (using contrib/config-list.mk). I have now committed all 25 parts of this patch as rev 193595. Please CC me on any problems that you think may be related to this rewrite. Thanks. Diego.
Re: [PATCH] Enable building of libsanitizer on sparc linux again.
On Sat, Nov 17, 2012 at 4:14 PM, David Miller wrote: > From: "H.J. Lu" > Date: Sat, 17 Nov 2012 16:06:23 -0800 > >> On Sat, Nov 17, 2012 at 4:04 PM, David Miller wrote: >>> From: Eric Botcazou >>> Date: Sun, 18 Nov 2012 00:18:15 +0100 >>> error: '__NR_mmap2' was not declared in this scope return (void *)syscall(__NR_mmap2, addr, length, prot, flags, fd, offset); >>> >>> The people making libsanitizer changes are really going to have to >>> stop making i386 specific changes to these generic files. >>> >>> Specifically, in this case, they are checking for whether mmap2 is >>> available using __x86_64__ cpp tests. A more appropriate test is >>> necessary. >>> >>> Oh nevermind, H.J. Liu added this build regression, I should have >>> known. >>> >>> H.J., either fix or revert this code back to using __WORDSIZE if you >>> cannot come up with an appropriate test. >> >> Please follow: >> >> http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00951.html > > The whole way this libsanitizer merge is being handled is > beyond unreasonable. > > A build fix being held up for 4 days just proves that requiring things > get merged into LLVM first is completely the wrong way for this stuff > to work. I am open to suggestions on how to avoid forking the two versions. If we fork, the original asan team will not be able to cope with two repositories. --kcc > > The people who merged in this library should be responsible for > keeping changes in sync, not the individual developers who fix bugs > and make improvements to this code on the gcc side. > > It's lunacy that this build problem is in the tree for 4 days because > of this.
Re: [PATCH] Enable building of libsanitizer on sparc linux again.
From: Konstantin Serebryany Date: Sat, 17 Nov 2012 19:01:56 -0800 > I am open to suggestions on how to avoid forking the two versions. > If we fork, the original asan team will not be able to cope with two > repositories. The maintainer of the sanitizer's job is to do the merging and resolve the conflicts between the two trees. This is how every other similar situation is handled. What's happening here, frankly, is garbage. The current situation is unacceptable and HJ's fix should go into the GCC tree right now. The current situation is preventing people from getting work done, and unnecessarily consuming developer resources.
Re: [PATCH] Enable building of libsanitizer on sparc linux again.
On Sat, Nov 17, 2012 at 7:10 PM, David Miller wrote: > From: Konstantin Serebryany > Date: Sat, 17 Nov 2012 19:01:56 -0800 > >> I am open to suggestions on how to avoid forking the two versions. >> If we fork, the original asan team will not be able to cope with two >> repositories. > > The maintainer of the sanitizer's job is to do the merging and resolve > the conflicts between the two trees. This is how every other similar > situation is handled. I am new to the gcc community and may not know all the rules. But your nice words (lunacy, garbage, etc) are not helping us. As for the particular problem, I did not even see a patch (did I miss it? Sorry, I am just back from a long trip) I'd prefer to mention the ARCHs explicitly where possible, i.e. #if defined(__x86_64__) || definde (__sparc64__) instead of #if __WORDSIZE == 64 || ... --kcc > > What's happening here, frankly, is garbage. > > The current situation is unacceptable and HJ's fix should go into the > GCC tree right now. > > The current situation is preventing people from getting work done, and > unnecessarily consuming developer resources.
Re: [PATCH] Enable building of libsanitizer on sparc linux again.
On Sat, Nov 17, 2012 at 10:10 PM, David Miller wrote: > From: Konstantin Serebryany > Date: Sat, 17 Nov 2012 19:01:56 -0800 > >> I am open to suggestions on how to avoid forking the two versions. >> If we fork, the original asan team will not be able to cope with two >> repositories. > > The maintainer of the sanitizer's job is to do the merging and resolve > the conflicts between the two trees. This is how every other similar > situation is handled. > > What's happening here, frankly, is garbage. Calm down, David. I understand this is frustrating, but reacting in this manner is not helpful to anyone. We have some new maintainers that are trying to understand how the system works. Insulting and berating them will only encourage them to pack up and leave. There is no need to do any forking. Kostya, would it be acceptable if fixes that go in the gcc tree get then propagated to the LLVM tree? The two trees don't need to be kept in sync at every commit. Patches to the GCC tree will be in your inbox or submitted to gcc-patches. Diego.
Re: [PATCH] Enable building of libsanitizer on sparc linux again.
From: Konstantin Serebryany Date: Sat, 17 Nov 2012 19:17:17 -0800 > I'd prefer to mention the ARCHs explicitly where possible, i.e. > #if defined(__x86_64__) || definde (__sparc64__) > instead of >#if __WORDSIZE == 64 || ... You really do need to check __x86_64__ as well the word size, in order to distinguish x32 from traditional x86-64. So no, it is not possible to just use an ARCH check all by itself to handle this case. Therefore, HJ's check is the correct check, and mirrors similar existing checks elsewhere in the tree (f.e. libffi).
Re: [PATCH] Enable building of libsanitizer on sparc linux again.
From: Diego Novillo Date: Sat, 17 Nov 2012 22:26:24 -0500 > We have some new maintainers that are trying to understand how the > system works. Wouldn't we have someone become at least roughly familiar with these kinds of things before we allow them to commit such an invasive set of changes which have a non-trivial effect on pretty much everyone? You cannot get around the fact that this was all handled poorly.
Re: [PATCH] Enable building of libsanitizer on sparc linux again.
On Sat, Nov 17, 2012 at 7:26 PM, Diego Novillo wrote: > On Sat, Nov 17, 2012 at 10:10 PM, David Miller wrote: >> From: Konstantin Serebryany >> Date: Sat, 17 Nov 2012 19:01:56 -0800 >> >>> I am open to suggestions on how to avoid forking the two versions. >>> If we fork, the original asan team will not be able to cope with two >>> repositories. >> >> The maintainer of the sanitizer's job is to do the merging and resolve >> the conflicts between the two trees. This is how every other similar >> situation is handled. >> >> What's happening here, frankly, is garbage. > > Calm down, David. I understand this is frustrating, but reacting in > this manner is not helpful to anyone. We have some new maintainers > that are trying to understand how the system works. Insulting and > berating them will only encourage them to pack up and leave. > > There is no need to do any forking. > > Kostya, would it be acceptable if fixes that go in the gcc tree get > then propagated to the LLVM tree? It may be acceptable for trivial patches, but we still want to review them. Once we review patch, it is easier for us to put it into LLVM first and then to gcc. Which reminds me, that libsanitizer/README.gcc is not helping in this process yet... > The two trees don't need to be kept > in sync at every commit. Patches to the GCC tree will be in your > inbox or submitted to gcc-patches. > > > Diego.
Re: [PATCH] Enable building of libsanitizer on sparc linux again.
On Sat, Nov 17, 2012 at 7:17 PM, Konstantin Serebryany wrote: > On Sat, Nov 17, 2012 at 7:10 PM, David Miller wrote: >> From: Konstantin Serebryany >> Date: Sat, 17 Nov 2012 19:01:56 -0800 >> >>> I am open to suggestions on how to avoid forking the two versions. >>> If we fork, the original asan team will not be able to cope with two >>> repositories. >> >> The maintainer of the sanitizer's job is to do the merging and resolve >> the conflicts between the two trees. This is how every other similar >> situation is handled. > > I am new to the gcc community and may not know all the rules. > But your nice words (lunacy, garbage, etc) are not helping us. > > As for the particular problem, I did not even see a patch (did I miss > it? Sorry, I am just back from a long trip) > I'd prefer to mention the ARCHs explicitly where possible, i.e. > #if defined(__x86_64__) || definde (__sparc64__) > instead of >#if __WORDSIZE == 64 || ... How about splitting this into a different config directory right now. Maybe I will do this later today. This is what was needed when it was merged into GCC rather than all of these #ifdef all over the code. Look at how either libgomp or even glibc handles cases like this. They have include directories which is based on the target and maybe even a common directory which each target can over ride it (glibc is the best at doing this). The whole double review process is hard for the target maintainers of GCC to work really. Target maintainers in GCC is not normally like an extra review step as it does slow down the whole process of getting a target patch reviewed. Thanks, Andrew Pinski > > --kcc > >> >> What's happening here, frankly, is garbage. >> >> The current situation is unacceptable and HJ's fix should go into the >> GCC tree right now. >> >> The current situation is preventing people from getting work done, and >> unnecessarily consuming developer resources.
Re: [PATCH] Enable building of libsanitizer on sparc linux again.
From: Andrew Pinski Date: Sat, 17 Nov 2012 19:34:34 -0800 > (glibc is the best at doing this). It also uses "make" in pretty much the most inefficient way possible, by causing it to consider 10s of thousands of prefix rules for every rule target. GLIBC has the same ifdef check that is being suggested here in various places.
Re: [PATCH] Enable building of libsanitizer on sparc linux again.
On Sun, Nov 18, 2012 at 7:34 AM, Andrew Pinski wrote:
> On Sat, Nov 17, 2012 at 7:17 PM, Konstantin Serebryany
> wrote:
>> On Sat, Nov 17, 2012 at 7:10 PM, David Miller wrote:
>>> From: Konstantin Serebryany
>>> Date: Sat, 17 Nov 2012 19:01:56 -0800
>>>
I am open to suggestions on how to avoid forking the two versions.
If we fork, the original asan team will not be able to cope with two
repositories.
>>>
>>> The maintainer of the sanitizer's job is to do the merging and resolve
>>> the conflicts between the two trees. This is how every other similar
>>> situation is handled.
>>
>> I am new to the gcc community and may not know all the rules.
>> But your nice words (lunacy, garbage, etc) are not helping us.
>>
>> As for the particular problem, I did not even see a patch (did I miss
>> it? Sorry, I am just back from a long trip)
>> I'd prefer to mention the ARCHs explicitly where possible, i.e.
>> #if defined(__x86_64__) || definde (__sparc64__)
>> instead of
>>#if __WORDSIZE == 64 || ...
>
> How about splitting this into a different config directory right now.
Hm?
I don't think this is worth it, also we want the code to work for all
supported platforms in the LLVM tree too.
My proposed patch is this:
Index: sanitizer_linux.cc
===
--- sanitizer_linux.cc (revision 168278)
+++ sanitizer_linux.cc (working copy)
@@ -31,12 +31,22 @@
#include
#include
+// Are we using 32-bit or 64-bit syscalls?
+// We need to list the 64-bit architecures explicitly because for x32
+// (which defines __x86_64__) we have __WORDSIZE == 32,
+// but we still need to use 64-bit syscalls.
+#if defined(__x86_64__) || defined(__powerpc64__) || defined(__sparc64__)
+# define SANITIZER_LINUX_USES_64BIT_SYSCALLS 1
+#else
+# define SANITIZER_LINUX_USES_64BIT_SYSCALLS 1
+#endif
+
namespace __sanitizer {
// --- sanitizer_libc.h
void *internal_mmap(void *addr, uptr length, int prot, int flags,
int fd, u64 offset) {
-#if defined __x86_64__
+#if SANITIZER_LINUX_USES_64BIT_SYSCALLS
return (void *)syscall(__NR_mmap, addr, length, prot, flags, fd, offset);
#else
return (void *)syscall(__NR_mmap2, addr, length, prot, flags, fd, offset);
@@ -69,7 +79,7 @@
}
uptr internal_filesize(fd_t fd) {
-#if defined __x86_64__
+#if SANITIZER_LINUX_USES_64BIT_SYSCALLS
struct stat st;
if (syscall(__NR_fstat, fd, &st))
return -1;
@@ -95,7 +105,7 @@
// - sanitizer_common.h
bool FileExists(const char *filename) {
-#if defined __x86_64__
+#if SANITIZER_LINUX_USES_64BIT_SYSCALLS
struct stat st;
if (syscall(__NR_stat, filename, &st))
return false;
> Maybe I will do this later today. This is what was needed when it was
> merged into GCC rather than all of these #ifdef all over the code.
>
> Look at how either libgomp or even glibc handles cases like this.
> They have include directories which is based on the target and maybe
> even a common directory which each target can over ride it (glibc is
> the best at doing this).
>
> The whole double review process is hard for the target maintainers of
> GCC to work really. Target maintainers in GCC is not normally like an
> extra review step as it does slow down the whole process of getting a
> target patch reviewed.
>
>
> Thanks,
> Andrew Pinski
>
>>
>> --kcc
>>
>>>
>>> What's happening here, frankly, is garbage.
>>>
>>> The current situation is unacceptable and HJ's fix should go into the
>>> GCC tree right now.
>>>
>>> The current situation is preventing people from getting work done, and
>>> unnecessarily consuming developer resources.
Re: PATCH: Add --with-build-config=bootstrap-asan support
On 2012.11.17 at 15:54 -0800, H.J. Lu wrote: > Hi, > > This patch adds --with-build-config=bootstrap-asan support. OK to > install? Wouldn't it make more sense to add an "--enable-checking=asan" option instead? -- Markus
Re: [PATCH] Enable building of libsanitizer on sparc linux again.
As for the libsanitizer update process, I suggest to move the
discussion to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55376
On Sun, Nov 18, 2012 at 7:42 AM, Konstantin Serebryany
wrote:
> On Sun, Nov 18, 2012 at 7:34 AM, Andrew Pinski wrote:
>> On Sat, Nov 17, 2012 at 7:17 PM, Konstantin Serebryany
>> wrote:
>>> On Sat, Nov 17, 2012 at 7:10 PM, David Miller wrote:
From: Konstantin Serebryany
Date: Sat, 17 Nov 2012 19:01:56 -0800
> I am open to suggestions on how to avoid forking the two versions.
> If we fork, the original asan team will not be able to cope with two
> repositories.
The maintainer of the sanitizer's job is to do the merging and resolve
the conflicts between the two trees. This is how every other similar
situation is handled.
>>>
>>> I am new to the gcc community and may not know all the rules.
>>> But your nice words (lunacy, garbage, etc) are not helping us.
>>>
>>> As for the particular problem, I did not even see a patch (did I miss
>>> it? Sorry, I am just back from a long trip)
>>> I'd prefer to mention the ARCHs explicitly where possible, i.e.
>>> #if defined(__x86_64__) || definde (__sparc64__)
>>> instead of
>>>#if __WORDSIZE == 64 || ...
>>
>> How about splitting this into a different config directory right now.
>
> Hm?
> I don't think this is worth it, also we want the code to work for all
> supported platforms in the LLVM tree too.
>
> My proposed patch is this:
>
> Index: sanitizer_linux.cc
> ===
> --- sanitizer_linux.cc (revision 168278)
> +++ sanitizer_linux.cc (working copy)
> @@ -31,12 +31,22 @@
> #include
> #include
>
> +// Are we using 32-bit or 64-bit syscalls?
> +// We need to list the 64-bit architecures explicitly because for x32
> +// (which defines __x86_64__) we have __WORDSIZE == 32,
> +// but we still need to use 64-bit syscalls.
> +#if defined(__x86_64__) || defined(__powerpc64__) || defined(__sparc64__)
> +# define SANITIZER_LINUX_USES_64BIT_SYSCALLS 1
> +#else
> +# define SANITIZER_LINUX_USES_64BIT_SYSCALLS 1
> +#endif
> +
> namespace __sanitizer {
>
> // --- sanitizer_libc.h
> void *internal_mmap(void *addr, uptr length, int prot, int flags,
> int fd, u64 offset) {
> -#if defined __x86_64__
> +#if SANITIZER_LINUX_USES_64BIT_SYSCALLS
>return (void *)syscall(__NR_mmap, addr, length, prot, flags, fd, offset);
> #else
>return (void *)syscall(__NR_mmap2, addr, length, prot, flags, fd, offset);
> @@ -69,7 +79,7 @@
> }
>
> uptr internal_filesize(fd_t fd) {
> -#if defined __x86_64__
> +#if SANITIZER_LINUX_USES_64BIT_SYSCALLS
>struct stat st;
>if (syscall(__NR_fstat, fd, &st))
> return -1;
> @@ -95,7 +105,7 @@
>
> // - sanitizer_common.h
> bool FileExists(const char *filename) {
> -#if defined __x86_64__
> +#if SANITIZER_LINUX_USES_64BIT_SYSCALLS
>struct stat st;
>if (syscall(__NR_stat, filename, &st))
> return false;
>
>
>
>
>
>
>
>
>
>
>
>
>> Maybe I will do this later today. This is what was needed when it was
>> merged into GCC rather than all of these #ifdef all over the code.
>>
>> Look at how either libgomp or even glibc handles cases like this.
>> They have include directories which is based on the target and maybe
>> even a common directory which each target can over ride it (glibc is
>> the best at doing this).
>>
>> The whole double review process is hard for the target maintainers of
>> GCC to work really. Target maintainers in GCC is not normally like an
>> extra review step as it does slow down the whole process of getting a
>> target patch reviewed.
>>
>>
>> Thanks,
>> Andrew Pinski
>>
>>>
>>> --kcc
>>>
What's happening here, frankly, is garbage.
The current situation is unacceptable and HJ's fix should go into the
GCC tree right now.
The current situation is preventing people from getting work done, and
unnecessarily consuming developer resources.
Re: [PATCH] Fix up var-tracking notes emitted in between bbs (PR middle-end/43631)
On Nov 14, 2012, Jakub Jelinek wrote:
> Steven has been complaining for some years that var-tracking inserts
> NOTE_INSN_VAR_LOCATION (and NOTE_INSN_CALL_ARG_LOCATION) notes sometimes
> in between basic blocks, but with BLOCK_FOR_INSN set (or sometimes extends
> a bb ending originally with a noreturn or throwing call by a note or more
> after it). Fixed thusly, bootstrapped/regtested on x86_64-linux and
> i686-linux, ok for trunk?
This is ok with me, although I'm thinking it might make more sense to
consolidate the rules to decide whether or not to add basic block info
to a note in add_insn_{before,after}, where this added in the first
place. Ideally we'd use the same rules used by cfg to determine where
the block boundaries are, i.e., what kinds of notes can be at BB
boundaries and which are outside BBs. (Incidentally, it looks like
add_insn_after, unlike add_insn_before, completely ignores and
overwrites the bb it is passed as an argument; this seems wrong)
--
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: The vec changes needed in gcc/go/gofrontend
On Sat, Nov 17, 2012 at 6:55 PM, Diego Novillo wrote: > Attached. The vec rewrite patch is in as of rev 193595. [ This patch updates the Go frontend for the new vector code in GCC ]. Thanks. Committed to mainline. Ian foo.patch Description: Binary data
