Re: [tsan] ThreadSanitizer instrumentation part

2012-11-22 Thread Jakub Jelinek
On Thu, Nov 22, 2012 at 11:29:05AM +0400, Dmitry Vyukov wrote:
> +static bool
> +tsan_gate (void)
> +{
> +  return flag_tsan != 0
> +  && builtin_decl_implicit_p (BUILT_IN_TSAN_INIT);
> 
> 
> What does it mean? Why builtin_decl_implicit_p (BUILT_IN_TSAN_INIT)?

It is a temporary workaround, I'll handle it when the patch goes in.
The thing is that while the C/C++ family of FEs will create all the builtins
just because they are included in builtins.def, other FEs won't.
So we need some routine that will build the builtins if the FEs didn't
initialize them.

Jakub


Re: [PATCH, RFC] Enable libsanitizer on powerpc{,64}

2012-11-22 Thread Evgeniy Stepanov
Yes, it has 3 asan-rtl frames on top. I'm not sure why this does not
happen on ppc.

#0 0x40122cdb in __asan::GetStackTrace(__sanitizer::StackTrace*,
unsigned long, unsigned long, unsigned long)
#1 0x40125167 in __asan_report_error
#2 0x40125af3 in __asan_report_load1


On Thu, Nov 22, 2012 at 12:10 AM, Evgeniy Stepanov
 wrote:
> I'm looking into the empty stack issue, at this point it looks like a weird
> linker bug. But its completely orthogonal to this discussion.
>
> I recall that the stack trace of the offending memory access has in fact
> three extra frames on top. I'll verify tomorrow. If so, FP/SP matching
> solution is preferable.
>
> On Nov 21, 2012 9:08 PM, "Peter Bergner"  wrote:
>>
>> On Wed, 2012-11-21 at 20:22 +0400, Konstantin Serebryany wrote:
>> > On Wed, Nov 21, 2012 at 8:16 PM, Peter Bergner 
>> > wrote:
>> > > On Wed, 2012-11-21 at 13:46 +0400, Evgeniy Stepanov wrote:
>> > >> Matching FP or SP also sounds good, and perhaps more reliable than
>> > >> just popping 2 frames from the top of the stack.
>> > >
>> > > Agreed.  Can you try my second patch that searches for the frame
>> > > address we want our backtrace to start with and see if that works
>> > > for ARM?  The nice thing about that patch is that we won't have
>> > > to play any games with forcing or disabling inlining of any of
>> > > the ASAN functions which me might have to do if we always pop
>> > > 2 frames off the stack.  It would also be tolerant of adding
>> > > any number of new function calls in between the current two
>> > > ASAN function at the top of the backtrace.
>> > >
>> > > http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01711.html
>> > >
>> > > Bah, ignore that first diff of the LAST_UPDATED file. :(
>> >
>> > I'd actually prefer to keep the current code that pops two frames
>> > (if it works for you)
>>
>> Well it does work for me, since I wrote it. :)  That being said, the
>> change where I always pop two frames off of the backtrace was more of
>> a proof of concept that if I can remove those ASAN functions from the
>> backtrace, do we pass the test case in the testsuite.  It did, but I
>> have to admit that code is extremely fragile.  It is dependent not
>> only on the inlining heuristics of one compiler, but of two compilers!
>> Not to mention people building debugable compilers with -O0 -fno-inline,
>> etc. etc.  We'd also have to make sure no one in the future adds any
>> ASAN function calls in between the report function and the GetBackTrace
>> calls.  It just seems like there are so many things that could go wrong,
>> that something is bound to.
>>
>>
>> > Evgeniy seems to know how to fix the ARM case.
>>
>> His fix was to do:
>>
>>  void StackTrace::PopStackFrames(uptr count) {
>> -  CHECK(size > count);
>> +  CHECK(size >= count);
>>size -= count;
>>for (uptr i = 0; i < size; i++) {
>>  trace[i] = trace[i + count];
>>
>> Basically, that is allowing for us to pop off all of the frames from
>> the backtrace leaving an empty backtrace.  That can't be helpful in
>> tracking down the address violation, can it?  With my patch above,
>> either we find the frame we want to start our backtrace with, or
>> it returns the entire backtrace, ASAN functions and all.  Isn't that
>> better from a diagnostic point of view?
>>
>> That being said, I'd still like to hear from Evgeniy whether my
>> patch above helps ARM or not.
>>
>> Peter
>>
>>
>>
>


Re: [tsan] ThreadSanitizer instrumentation part

2012-11-22 Thread Jakub Jelinek
On Wed, Nov 21, 2012 at 11:22:51PM -0800, Wei Mi wrote:
> I update the tsan patch against trunk, and create libtsan patch.
> Please see if it is ok.
> 
> gcc/ChangeLog:
> 2012-11-22  Dmitry Vyukov  
> Wei Mi  
> 
> * builtins.def (DEF_SANITIZER_BUILTIN): Define tsan builtins.
> * sanitizer.def: Ditto.
> * Makefile.in (tsan.o): Add tsan.o target.
> (BUILTINS_DEF): Add sanitizer.def.
> * passes.c (init_optimization_passes): Add tsan passes.
> * tree-pass.h (register_pass_info): Ditto.
> * toplev.c (compile_file): Ditto.
> * doc/invoke.texi: Document tsan related options.
> * gcc.c (LINK_COMMAND_SPEC): Add LIBTSAN_SPEC in link command
> if -fsanitize=thread.
> * tsan.c: New file about tsan.
> * tsan.h: Ditto.
> * common.opt: Add -fsanitize=thread.
> 
> libsanitizer/ChangeLog:
> 2012-11-22  Wei Mi  
> 
> * tsan: New directory. Import tsan runtime from llvm.
> * configure.ac: Add 64 bits tsan build.
> * Makefile.am: Likewise.
> * configure: Regenerated.
> * Makefile.in: Likewise.

Ok, thanks.  The comments can be fixed up incrementally.

Jakub


Re: [PATCH] Use ATTRIBUTE_PACKED in ree.c

2012-11-22 Thread Eric Botcazou
> I'm not sure, but I hope it will.  ansidecl.h has
> #ifndef GCC_VERSION
> #define GCC_VERSION (__GNUC__ * 1000 + __GNUC_MINOR__)
> #endif /* GCC_VERSION */
> ...
> #if (GCC_VERSION < 2007)
> # define __attribute__(x)
> #endif
> ...
> #ifndef ATTRIBUTE_PACKED
> # define ATTRIBUTE_PACKED __attribute__ ((packed))
> #endif
> 
> So in theory it should expand to nothing for non-GCC compilers.
> I've tested (on a short testcase matching what the decl does)
> GCCs from 4.8 down back to 3.2 (we support 4.1+ only anyway now)
> and clang 3.0.

OK, some other attributes are defined in the same way, thanks.

-- 
Eric Botcazou


[C++ testcase] PR 55432

2012-11-22 Thread Paolo Carlini

Hi,

tested x86_64-linux, committed to mainline.

Thanks,
Paolo.

/
2012-11-22  Paolo Carlini  

PR c++/55432
* g++.dg/cpp0x/constexpr-55432.C: New.
Index: g++.dg/cpp0x/constexpr-55432.C
===
--- g++.dg/cpp0x/constexpr-55432.C  (revision 0)
+++ g++.dg/cpp0x/constexpr-55432.C  (working copy)
@@ -0,0 +1,22 @@
+// PR c++/55432
+// { dg-do compile { target c++11 } }
+
+struct tag_t{} tag{};
+
+constexpr tag_t const& pass(tag_t & t)
+{
+  return t;
+}
+
+struct S
+{
+  constexpr S(tag_t)  {};
+};
+
+struct T
+{
+  S mem;
+  T( tag_t & args ) : mem(pass(args)) {}
+};
+
+T t(tag);


Re: Tighten checking of vector comparisons

2012-11-22 Thread Marc Glisse

(I forgot to send this at the time)

On Sun, 4 Nov 2012, Richard Biener wrote:


- else if (!INTEGRAL_TYPE_P (type) && TREE_CODE (type) !=
VECTOR_TYPE)
+ else if (!INTEGRAL_TYPE_P (type) && !VOID_TYPE_P (type)
+  && TREE_CODE (type) != VECTOR_TYPE)

[...]

Ok for this part.


Applied, thanks.


Index: gcc/tree-cfg.c
===
--- gcc/tree-cfg.c  (revision 193060)
+++ gcc/tree-cfg.c  (working copy)
@@ -3263,21 +3263,30 @@ verify_gimple_comparison (tree type, tre
   error ("mismatching comparison operand types");
   debug_generic_expr (op0_type);
   debug_generic_expr (op1_type);
   return true;
 }

   /* The resulting type of a comparison may be an effective boolean type.
*/
   if (INTEGRAL_TYPE_P (type)
   && (TREE_CODE (type) == BOOLEAN_TYPE
  || TYPE_PRECISION (type) == 1))
-;
+{
+  if (TREE_CODE (op0_type) == VECTOR_TYPE
+ || TREE_CODE (op1_type) == VECTOR_TYPE)
+{
+  error ("vector comparison returning a boolean");
+  debug_generic_expr (op0_type);
+  debug_generic_expr (op1_type);
+  return true;
+}


verify_gimple_* should have "positive" checks, thus, check that
if there are vector operands the comparison result should be a
vector.  Not complaining about a vector comparison having a
boolean result.


I wasn't sure what that was supposed to look like, so I dropped it for 
now.


--
Marc Glisse


[PATCH] Add no_address_safety_analysis attribute (PR sanitizer/55435)

2012-11-22 Thread Jakub Jelinek
Hi!

This patch adds the no_address_safety_analysis attribute.  Tested on
x86_64-linux, ok for trunk?

2012-11-22  Jakub Jelinek  

PR sanitizer/55435
* c-common.c (handle_no_address_safety_analysis_attribute): New
function.
(c_common_attribute_table): Add no_address_safety_analysis.

* asan.c (gate_asan): Don't instrument functions with
no_address_safety_analysis attribute.
(gate_asan_O0): Use !optimize && gate_asan ().
* doc/extend.texi (no_address_safety_analysis): Document new
function attribute.

* c-c++-common/asan/attrib-1.c: New test.

--- gcc/c-family/c-common.c.jj  2012-11-19 14:41:10.0 +0100
+++ gcc/c-family/c-common.c 2012-11-22 11:51:48.053996443 +0100
@@ -309,6 +309,8 @@ static tree handle_common_attribute (tre
 static tree handle_noreturn_attribute (tree *, tree, tree, int, bool *);
 static tree handle_hot_attribute (tree *, tree, tree, int, bool *);
 static tree handle_cold_attribute (tree *, tree, tree, int, bool *);
+static tree handle_no_address_safety_analysis_attribute (tree *, tree, tree,
+int, bool *);
 static tree handle_noinline_attribute (tree *, tree, tree, int, bool *);
 static tree handle_noclone_attribute (tree *, tree, tree, int, bool *);
 static tree handle_leaf_attribute (tree *, tree, tree, int, bool *);
@@ -711,6 +713,10 @@ const struct attribute_spec c_common_att
  handle_cold_attribute, false },
   { "hot",0, 0, true,  false, false,
  handle_hot_attribute, false },
+  { "no_address_safety_analysis",
+ 0, 0, true, false, false,
+ handle_no_address_safety_analysis_attribute,
+ false },
   { "warning",   1, 1, true,  false, false,
  handle_error_attribute, false },
   { "error", 1, 1, true,  false, false,
@@ -6477,6 +6483,22 @@ handle_cold_attribute (tree *node, tree
 {
   warning (OPT_Wattributes, "%qE attribute ignored", name);
   *no_add_attrs = true;
+}
+
+  return NULL_TREE;
+}
+
+/* Handle a "no_address_safety_analysis" attribute; arguments as in
+   struct attribute_spec.handler.  */
+
+static tree
+handle_no_address_safety_analysis_attribute (tree *node, tree name, tree, int,
+bool *no_add_attrs)
+{
+  if (TREE_CODE (*node) != FUNCTION_DECL)
+{
+  warning (OPT_Wattributes, "%qE attribute ignored", name);
+  *no_add_attrs = true;
 }
 
   return NULL_TREE;
--- gcc/asan.c.jj   2012-11-19 14:41:20.0 +0100
+++ gcc/asan.c  2012-11-22 11:35:47.310489415 +0100
@@ -1587,7 +1587,9 @@ asan_instrument (void)
 static bool
 gate_asan (void)
 {
-  return flag_asan != 0;
+  return flag_asan != 0
+ && !lookup_attribute ("no_address_safety_analysis",
+   DECL_ATTRIBUTES (current_function_decl));
 }
 
 struct gimple_opt_pass pass_asan =
@@ -1614,7 +1616,7 @@ struct gimple_opt_pass pass_asan =
 static bool
 gate_asan_O0 (void)
 {
-  return flag_asan != 0 && !optimize;
+  return !optimize && gate_asan ();
 }
 
 struct gimple_opt_pass pass_asan_O0 =
--- gcc/doc/extend.texi.jj  2012-11-19 14:41:08.0 +0100
+++ gcc/doc/extend.texi 2012-11-22 11:52:20.913814831 +0100
@@ -2130,10 +2130,11 @@ attributes are currently defined for fun
 @code{weak}, @code{malloc}, @code{alias}, @code{ifunc},
 @code{warn_unused_result}, @code{nonnull}, @code{gnu_inline},
 @code{externally_visible}, @code{hot}, @code{cold}, @code{artificial},
-@code{error} and @code{warning}.  Several other attributes are defined
-for functions on particular target systems.  Other attributes,
-including @code{section} are supported for variables declarations
-(@pxref{Variable Attributes}) and for types (@pxref{Type Attributes}).
+@code{no_address_safety_analysis}, @code{error} and @code{warning}.
+Several other attributes are defined for functions on particular
+target systems.  Other attributes, including @code{section} are
+supported for variables declarations (@pxref{Variable Attributes})
+and for types (@pxref{Type Attributes}).
 
 GCC plugins may provide their own attributes.
 
@@ -3416,6 +3417,12 @@ with computed goto or @code{asm goto}.
 The @code{cold} attribute on labels is not implemented in GCC versions
 earlier than 4.8.
 
+@item no_address_safety_analysis
+@cindex @code{no_address_safety_analysis} function attribute
+The @code{no_address_safety_analysis} attribute on functions is used
+to inform the compiler that it should not instrument memory accesses
+in the function when compiling with the @option{-fsanitize=address} option.
+
 @item regparm (@var{number})
 @cindex @code{regparm} attribute
 @cindex functions that are passed arguments in registers on the 386
--- gcc/testsuite/c-c++-common/asan/attrib-1.c.jj   2012-11-22 

Re: [PATCH] Add STATIC_LIBASAN_LIBS for -static-libasan

2012-11-22 Thread Jakub Jelinek
On Sun, Nov 18, 2012 at 09:01:17PM -0800, H.J. Lu wrote:
> This patch adds STATIC_LIBASAN_LIBS so that one can simply use
> "gcc -faddress-sanitizer -static-libasan".  OK to install?

The usual way other libraries use is some special spec file generated
by configure in those libraries and then sourced in.  But I guess
even these STATIC_LIBASAN_LIBS is ok for now.

> 2012-11-18  H.J. Lu  
> 

>   * gcc.c (ADD_STATIC_LIBASAN_LIBS): New macro.  Defined
>   with STATIC_LIBASAN_LIBS.
>   (LIBASAN_SPEC): Add STATIC_LIBASAN_LIBS.
>   * config/gnu-user.h (STATIC_LIBASAN_LIBS): New macro.

So, ok for trunk.

For PR sanitizer/55379 we'll need to add
%{static:%e-fsanitize=address requires dynamic linking}
afterwards.

Jakub


RE: [PATCH][ARM] Define predicable attribute for arm_abssi2 and arm_neg_abssi2

2012-11-22 Thread Kyrylo Tkachov
Thanks for the review.
As I do not have write access, can someone please apply?

http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01655.html

Thanks,
Kyrill

-Original Message-
From: Richard Earnshaw 
Sent: 20 November 2012 10:32
To: Kyrylo Tkachov
Cc: gcc-patches@gcc.gnu.org; Ramana Radhakrishnan
Subject: Re: [PATCH][ARM] Define predicable attribute for arm_abssi2 and
arm_neg_abssi2

On 20/11/12 10:25, Kyrylo Tkachov wrote:
> Hi all,
> This is the updated version of the patch. It defines the predicable
> attribute for the equivalent abssi2 and neg_abssi2 patterns in thumb2.md.
> The previous version (with the changes only to arm.md) has been okayed but
> not applied and this patch supersedes it.
> The previous version is:
> http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01578.html
>
> No regressions for arm-none-eabi for qemu.
>
> Ok for trunk?
>
> Thanks,
> Kyrill
>
> gcc/ChangeLog
>
> 2012-11-20  Kyrylo Tkachov  
>
>   * config/arm/arm.md (*arm_abssi2): Define predicable attribute.
>   (*arm_neg_abssi2): Likewise.
>   * config/arm/thumb2.md (*thumb2_abssi2): Likewise.
>   (*thumb2_neg_abssi2): Likewise.
>
>
> -Original Message-
> From: Ramana Radhakrishnan
> Sent: 19 November 2012 18:05
> To: Kyrylo Tkachov
> Cc: gcc-patches@gcc.gnu.org; Richard Earnshaw
> Subject: Re: [PATCH][ARM] Define predicable attribute for arm_abssi2 and
> arm_neg_abssi2
>
> On 11/19/12 17:51, Kyrylo Tkachov wrote:
>> Hi all,
>> This patch updates the arm_abssi2 and arm_neg_abssi2 patterns in the ARM
>> machine description.
>> We define the predicable attribute based on the alternative. When the
>> patterns were introduced it was not possible to do that.
>> Now the second alternative in each of the patterns that supports
> predication
>> is defined as predicable.
>>
>> No regressions on arm-none-eabi with qemu.
>>
>> Ok for trunk?
>
> Ok, please apply.
>
> Ramana
>

OK.

Thanks.

R.






[C++ PATCH] Fix PR 55418

2012-11-22 Thread Markus Trippelsdorf
Hi,

Valgrind complains about an uninitialized variable in method.c
(implicitly_declare_fn):  

==19553== Conditional jump or move depends on uninitialised value(s)
==19553==at 0x63D248: implicitly_declare_fn(special_function_kind, 
tree_node*, bool, tree_node*, tree_node*) (method.c:1623)
==19553==by 0x63EA8F: lazily_declare_fn(special_function_kind, tree_node*) 
(method.c:1894)
==19553==by 0x6455EC: lookup_fnfields_1(tree_node*, tree_node*) 
(search.c:1441)
==19553==by 0x64577B: lookup_fnfields_slot(tree_node*, tree_node*) 
(search.c:1471)
==19553==by 0x64931B: lookup_field_r(tree_node*, void*) (search.c:1031)
==19553==by 0x645B08: dfs_walk_all(tree_node*, tree_node* (*)(tree_node*, 
void*), tree_node* (*)(tree_node*, void*), void*) (search.c:1572)
==19553==by 0x645D5D: lookup_member(tree_node*, tree_node*, int, bool, int) 
(search.c:1204)
==19553==by 0x646010: lookup_fnfields(tree_node*, tree_node*, int) 
(search.c:1295)
==19553==by 0x4E6E50: build_special_member_call(tree_node*, tree_node*, 
vec**, tree_node*, int, int) (call.c:7282)
==19553==by 0x4E0DEA: convert_like_real(conversion*, tree_node*, 
tree_node*, int, int, bool, bool, int) (call.c:5718)
==19553==by 0x4E28D0: build_over_call(z_candidate*, int, int) (call.c:6867)
==19553==by 0x4E5C28: build_new_method_call(tree_node*, tree_node*, 
vec**, tree_node*, int, tree_node**, int) 
(call.c:7668)
==19553==

The fix is trivial. I would appreciate if someone could commit this.
Thanks.

Bootstrapped and tested on x86_64-pc-linux-gnu.

2012-11-22  Markus Trippelsdorf  

PR c++/55418
* method.c (implicitly_declare_fn): Properly initialize trivial_p.

diff --git a/gcc/cp/method.c b/gcc/cp/method.c
index 6dcb63a..778daa8 100644
--- a/gcc/cp/method.c
+++ b/gcc/cp/method.c
@@ -1518,7 +1518,6 @@ implicitly_declare_fn (special_function_kind kind, tree 
type,
   tree name;
   HOST_WIDE_INT saved_processing_template_decl;
   bool deleted_p;
-  bool trivial_p;
   bool constexpr_p;
 
   /* Because we create declarations for implicitly declared functions
@@ -1597,12 +1596,13 @@ implicitly_declare_fn (special_function_kind kind, tree 
type,
   tree inherited_base = (inherited_ctor
 ? DECL_CONTEXT (inherited_ctor)
 : NULL_TREE);
+  bool trivial_p = false;
+
   if (inherited_ctor && TREE_CODE (inherited_ctor) == TEMPLATE_DECL)
 {
   /* For an inheriting constructor template, just copy these flags from
 the inherited constructor template for now.  */
   raises = TYPE_RAISES_EXCEPTIONS (TREE_TYPE (inherited_ctor));
-  trivial_p = false;
   deleted_p = DECL_DELETED_FN (DECL_TEMPLATE_RESULT (inherited_ctor));
   constexpr_p
= DECL_DECLARED_CONSTEXPR_P (DECL_TEMPLATE_RESULT (inherited_ctor));
-- 
Markus


Re: Sparc ASAN

2012-11-22 Thread Alexander Potapenko
>> While trying to add support for ARM (AArch32 GNU / Linux) implementation for
>> GCC after-hours but still keep seeing failures on my chromebook running an
>> ubuntu fs on a ChrOS kernel, because the shadow memory apparently overlaps
>> with normal memory. Has anyone else hit this while porting ?
>
> I've heard someone complain about this recently.
> glider?
>
> Running asan on *huge* binaries in 32-bit address space is a challenge indeed.
> My suggestion was to link with -pie.
>
> --kcc
Yes, there were complaints about that recently: http://crbug.com/159816
-pie MAY help, but not if the program occupies too much address space.


[tsan] libsanitizer tweaks

2012-11-22 Thread Jakub Jelinek
On Thu, Nov 22, 2012 at 10:54:00AM +0100, Jakub Jelinek wrote:
> Ok, thanks.  The comments can be fixed up incrementally.

I had closer look at the libsanitizer/tsan configury, and I think I'd prefer
the configure.tgt script to say if tsan should be built or not.
Furthermore, GCC doesn't support -Wno-c99-extensions flag for C++, that is a
clang-ism.
Ok for trunk (after the tsan patches are committed, on top of them)?

2012-11-22  Jakub Jelinek  

* tsan/Makefile.am (AM_CXXFLAGS): Remove -Wno-variadic-macros.
* Makefile.am (SUBDIRS): Guard tsan addition with TSAN_SUPPORTED
automake conditional instead of !MULTISUBDIR32.
* configure.tgt: Set TSAN_SUPPORTED=yes for x86_64/i686-linux
for 64-bit multilib.
* configure.ac: Check for void * size, source in configure.tgt,
define TSAN_SUPPORTED conditional instead of MULTILIBDIR32.
* configure: Regenerated.
* Makefile.in: Regenerated.
* tsan/Makefile.in: Regenerated.

--- libsanitizer/tsan/Makefile.am.jj2012-11-22 13:18:04.0 +0100
+++ libsanitizer/tsan/Makefile.am   2012-11-22 13:44:51.898192821 +0100
@@ -1,7 +1,7 @@
 AM_CPPFLAGS = -I $(top_srcdir) -I $(top_srcdir)/include
 
 DEFS = -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS 
-D__STDC_LIMIT_MACROS 
-AM_CXXFLAGS = -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 
+AM_CXXFLAGS = -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
 ACLOCAL_AMFLAGS = -I m4
 
 toolexeclib_LTLIBRARIES = libtsan.la
--- libsanitizer/Makefile.am.jj 2012-11-22 13:18:04.0 +0100
+++ libsanitizer/Makefile.am2012-11-22 14:03:36.947775816 +0100
@@ -1,9 +1,9 @@
 ACLOCAL_AMFLAGS = -I .. -I ../config
 
-if MULTISUBDIR32 
-SUBDIRS = interception sanitizer_common asan 
-else
+if TSAN_SUPPORTED
 SUBDIRS = interception sanitizer_common asan tsan 
+else
+SUBDIRS = interception sanitizer_common asan 
 endif
 
 # Work around what appears to be a GNU make bug handling MAKEFLAGS
--- libsanitizer/configure.tgt.jj   2012-11-16 12:39:18.0 +0100
+++ libsanitizer/configure.tgt  2012-11-22 14:11:31.233300510 +0100
@@ -20,7 +20,12 @@
 
 # Filter out unsupported systems.
 case "${target}" in
-  x86_64-*-linux* | i?86-*-linux* | sparc*-*-linux*)
+  x86_64-*-linux* | i?86-*-linux*)
+   if test x$ac_cv_sizeof_void_p = x8; then
+   TSAN_SUPPORTED=yes
+   fi
+   ;;
+  sparc*-*-linux*)
;;
   *)
UNSUPPORTED=1
--- libsanitizer/configure.ac.jj2012-11-22 13:18:04.0 +0100
+++ libsanitizer/configure.ac   2012-11-22 13:59:46.457084798 +0100
@@ -67,12 +67,18 @@ AM_PROG_LIBTOOL
 AC_SUBST(enable_shared)
 AC_SUBST(enable_static)
 
+AC_CHECK_SIZEOF([void *])
+
 if test "${multilib}" = "yes"; then
   multilib_arg="--enable-multilib"
 else
   multilib_arg=
 fi
-AM_CONDITIONAL(MULTISUBDIR32, [test "x$with_multisubdir" = "x32"])
+
+# Get target configury.
+unset TSAN_SUPPORTED
+. ${srcdir}/configure.tgt
+AM_CONDITIONAL(TSAN_SUPPORTED, [test "x$TSAN_SUPPORTED" = "xyes"])
 
 AC_CONFIG_FILES([Makefile])
 
@@ -89,7 +95,7 @@ _EOF
AS_UNSET([ml_norecursion])
 ])
 
-if test "x$with_multisubdir" != "x32"; then
+if test "x$TSAN_SUPPORTED" = "xyes"; then
   AC_CONFIG_FILES(AC_FOREACH([DIR], [tsan], [DIR/Makefile ]), 
 [cat > vpsed$$ << \_EOF
 s!`test -f '$<' || echo '$(srcdir)/'`!!
--- libsanitizer/configure.jj   2012-11-22 13:18:04.0 +0100
+++ libsanitizer/configure  2012-11-22 14:01:47.463398176 +0100
@@ -604,8 +604,8 @@ ac_subst_vars='am__EXEEXT_FALSE
 am__EXEEXT_TRUE
 LTLIBOBJS
 LIBOBJS
-MULTISUBDIR32_FALSE
-MULTISUBDIR32_TRUE
+TSAN_SUPPORTED_FALSE
+TSAN_SUPPORTED_TRUE
 enable_static
 enable_shared
 CXXCPP
@@ -1878,6 +1878,184 @@ fi
   return $ac_retval
 
 } # ac_fn_cxx_try_link
+
+# ac_fn_c_compute_int LINENO EXPR VAR INCLUDES
+# 
+# Tries to find the compile-time value of EXPR in a program that includes
+# INCLUDES, setting VAR accordingly. Returns whether the value could be
+# computed
+ac_fn_c_compute_int ()
+{
+  as_lineno=${as_lineno-"$1"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
+  if test "$cross_compiling" = yes; then
+# Depending upon the size, compute the lo and hi bounds.
+cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+$4
+int
+main ()
+{
+static int test_array [1 - 2 * !(($2) >= 0)];
+test_array [0] = 0
+
+  ;
+  return 0;
+}
+_ACEOF
+if ac_fn_c_try_compile "$LINENO"; then :
+  ac_lo=0 ac_mid=0
+  while :; do
+cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+$4
+int
+main ()
+{
+static int test_array [1 - 2 * !(($2) <= $ac_mid)];
+test_array [0] = 0
+
+  ;
+  return 0;
+}
+

Re: [C++ PATCH] Fix PR 55418

2012-11-22 Thread Paolo Carlini

Hi,

On 11/22/2012 01:06 PM, Markus Trippelsdorf wrote:

The fix is trivial. I would appreciate if someone could commit this.
I agree it qualifies as obvious and I mean to commit the patch on your 
behalf before the end of the day if nobody objects. To be super-safe, I 
guess I will also run the testsuite with the current code and trivial_p 
initialized to true at the beginning of the function.


Thanks!
Paolo.


Re: [AARCH64] Update maintainers file

2012-11-22 Thread Richard Earnshaw

On 20/11/12 16:44, Richard Earnshaw wrote:

On 28/10/12 21:45, Gerald Pfeifer wrote:

On Tue, 23 Oct 2012, Richard Earnshaw wrote:

On 23/10/12 23:36, Steven Bosscher wrote:

Will you also add an announcement of this to the news page (home page)
and to gcc-4.8/changes.html?

I'm sure we can... :-)


You have to. :-)  Please.

Gerald


Sorry for the delay, I've been swamped with internal issues.

How does this look?

R.


Haven't seen any follow-up on this.  Since it's fairly trivial, I've 
committed it as obvious; but I'm happy to change it if you feel it 
should be worded differently.


R.




wwwdocs.patch


Index: index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
retrieving revision 1.866
diff -u -r1.866 index.html
--- index.html  8 Nov 2012 07:26:59 -   1.866
+++ index.html  20 Nov 2012 16:43:58 -
@@ -53,6 +53,11 @@

  

+ARM AArch64 support
+[2012-10-24]
+A port for AArch64, the 64-bit execution state in the ARMv8 architecture,
+has been contributed by ARM Ltd.
+
  IBM zEnterprise EC12 support
  [2012-10-10]
  Support for the latest release of the System z mainframe zEC12 has






Re: RFC: Add --with-build-config=bootstrap-asan support

2012-11-22 Thread Markus Trippelsdorf
On 2012.11.21 at 15:54 -0800, H.J. Lu wrote:
> Hi,
> 
> I added --with-build-config=bootstrap-asan support on hjl/asan
> branch:
> 
> http://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/hjl/asan
> 
> Any comments?

It would be nice if one could run:

 % ~/gcc/configure --with-build-config=bootstrap-lto --enable-checking=yes,asan
 % make profiledbootstrap

But maybe you could add this later?

-- 
Markus


Re: RFC: Add --with-build-config=bootstrap-asan support

2012-11-22 Thread H.J. Lu
On Thu, Nov 22, 2012 at 5:55 AM, Markus Trippelsdorf
 wrote:
> On 2012.11.21 at 15:54 -0800, H.J. Lu wrote:
>> Hi,
>>
>> I added --with-build-config=bootstrap-asan support on hjl/asan
>> branch:
>>
>> http://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/hjl/asan
>>
>> Any comments?
>
> It would be nice if one could run:
>
>  % ~/gcc/configure --with-build-config=bootstrap-lto 
> --enable-checking=yes,asan
>  % make profiledbootstrap
>
> But maybe you could add this later?
>

No need.  You can do

# ~/gcc/configure --with-build-config="bootstrap-lto bootstrap-asan"


-- 
H.J.


[asan] PATCH: PR driver/55379: Issue an error for -static with fsanitize=address

2012-11-22 Thread H.J. Lu
Hi,

fsanitize=address doesn't work with static link.  This patch issues
an error when both are specified.  OK to install?

Thanks.


H.J.
---
2012-11-22  H.J. Lu  

PR driver/55379
* gcc.c (LINK_COMMAND_SPEC): Issue an error for -static with
-fsanitize=address.

diff --git a/gcc/gcc.c b/gcc/gcc.c
index 0f8bcea..41474aa 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -696,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}\
-%{fsanitize=address:" LIBASAN_SPEC "}\
+%{fsanitize=address:" LIBASAN_SPEC "%{static:%ecannot specify -static with 
-fsanitize=address}}\
 %{!nostdlib:%{!nodefaultlibs:%(link_ssp) %(link_gcc_c_sequence)}}\
 %{!nostdlib:%{!nostartfiles:%E}} %{T*} }}"
 #endif


PATCH: PR driver/55374: [asan] Wrong linking order of libasan and libstdc++

2012-11-22 Thread H.J. Lu
Hi,

libasan should come first before any language-specific
adjustment/addition.  Otherwise, we got

g++ -fsanitize=address -static-libasan ...

/usr/local/bin/ld: error:
/export/build/gnu/gcc-asan/build-x86_64-linux/prev-x86_64-unknown-linux-gnu/libsanitizer/asan/.libs/libasan.a(asan_new_delete.o):
multiple definition of 'operator delete(void*)'
/usr/local/bin/ld:
/export/build/gnu/gcc-asan/build-x86_64-linux/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.a(del_op.o):
previous definition here

This patch adds prepend_lang_specific_driver to prepend command line before
language-specific adjustment/addition of flags.  OK to install?

Thanks.


H.J.
---
2012-11-22  H.J. Lu  

PR driver/55374
* gcc.c (prepend_lang_specific_driver): New function.
(process_command): Use it.

diff --git a/gcc/gcc.c b/gcc/gcc.c
index 0f8bcea..41474aa 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -3604,6 +3604,80 @@ set_option_handlers (struct cl_option_handlers *handlers)
   handlers->handlers[2].mask = CL_TARGET;
 }
 
+/* Prepend command line before language-specific adjustment/addition of
+   flags.  */
+
+void
+prepend_lang_specific_driver (struct cl_decoded_option **in_decoded_options,
+ unsigned int *in_decoded_options_count,
+ int *in_added_libraries)
+{
+  unsigned int i, argc;
+
+  /* The new argument list will be contained in this.  */
+  struct cl_decoded_option *new_decoded_options;
+
+  /* The argument list.  */
+  struct cl_decoded_option *decoded_options;
+
+  bool add_libasan = false;
+  bool static_libasan = false;
+
+  argc = *in_decoded_options_count;
+  decoded_options = *in_decoded_options;
+
+  for (i = 1; i < argc; i++)
+switch (decoded_options[i].opt_index)
+  {
+  case OPT_fsanitize_address:
+   add_libasan = true;
+   break;
+  case OPT_static_libasan:
+   static_libasan = true;
+   break;
+  }
+
+  if (add_libasan)
+{
+  /* Add -lasan before language-specific adjustment/addition.  */
+  unsigned int added_argc;
+
+  added_argc = 1;
+#ifdef HAVE_LD_STATIC_DYNAMIC
+  if (static_libasan)
+   added_argc += 2;
+#endif
+
+  new_decoded_options = XNEWVEC (struct cl_decoded_option,
+argc + added_argc);
+
+  i = 0;
+  do
+   {
+ new_decoded_options[i] = decoded_options[i];
+ i++;
+   }
+  while (i < argc);
+
+#ifdef HAVE_LD_STATIC_DYNAMIC
+  if (static_libasan)
+   generate_option (OPT_Wl_, LD_STATIC_OPTION, 1, CL_DRIVER,
+&new_decoded_options[i++]);
+#endif
+  generate_option (OPT_l, "asan", 1, CL_DRIVER,
+  &new_decoded_options[i++]);
+#ifdef HAVE_LD_STATIC_DYNAMIC
+  if (static_libasan)
+   generate_option (OPT_Wl_, LD_DYNAMIC_OPTION, 1, CL_DRIVER,
+&new_decoded_options[i++]);
+#endif
+
+  *in_decoded_options_count = i;
+  *in_decoded_options = new_decoded_options;
+  *in_added_libraries = 1;
+}
+}
+
 /* Create the vector `switches' and its contents.
Store its length in `n_switches'.  */
 
@@ -3695,6 +3769,11 @@ process_command (unsigned int decoded_options_count,
  or an automatically created GCC_EXEC_PREFIX from
  decoded_options[0].arg.  */
 
+  /* Prepend command line before language-specific adjustment/addition of
+ flags.  */
+  prepend_lang_specific_driver (&decoded_options, &decoded_options_count,
+   &added_libraries);
+
   /* Do language-specific adjustment/addition of flags.  */
   lang_specific_driver (&decoded_options, &decoded_options_count,
&added_libraries);


Re: [C++ PATCH] Fix PR 55418

2012-11-22 Thread Jakub Jelinek
On Thu, Nov 22, 2012 at 02:28:18PM +0100, Paolo Carlini wrote:
> On 11/22/2012 01:06 PM, Markus Trippelsdorf wrote:
> >The fix is trivial. I would appreciate if someone could commit this.
> I agree it qualifies as obvious and I mean to commit the patch on
> your behalf before the end of the day if nobody objects. To be
> super-safe, I guess I will also run the testsuite with the current
> code and trivial_p initialized to true at the beginning of the
> function.

I think trivial_p used to be uninitialized only for deleted_p functions,
not sure if those are considered trivial or not (and whether it matters)...

Jakub


Re: [asan] PATCH: PR driver/55379: Issue an error for -static with fsanitize=address

2012-11-22 Thread Jakub Jelinek
On Thu, Nov 22, 2012 at 06:39:11AM -0800, H.J. Lu wrote:
> fsanitize=address doesn't work with static link.  This patch issues
> an error when both are specified.  OK to install?

> 2012-11-22  H.J. Lu  
> 
>   PR driver/55379

Replace driver/ with sanitizer/

>   * gcc.c (LINK_COMMAND_SPEC): Issue an error for -static with
>   -fsanitize=address.

Ok with that change.

> diff --git a/gcc/gcc.c b/gcc/gcc.c
> index 0f8bcea..41474aa 100644
> --- a/gcc/gcc.c
> +++ b/gcc/gcc.c
> @@ -696,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}\
> -%{fsanitize=address:" LIBASAN_SPEC "}\
> +%{fsanitize=address:" LIBASAN_SPEC "%{static:%ecannot specify -static 
> with -fsanitize=address}}\
>  %{!nostdlib:%{!nodefaultlibs:%(link_ssp) %(link_gcc_c_sequence)}}\
>  %{!nostdlib:%{!nostartfiles:%E}} %{T*} }}"
>  #endif

Jakub


[PATCH] Convert asan to use sanitizer.def builtins, initialize them if the FE didn't

2012-11-22 Thread Jakub Jelinek
On Thu, Nov 22, 2012 at 09:08:23AM +0100, Jakub Jelinek wrote:
> On Thu, Nov 22, 2012 at 11:29:05AM +0400, Dmitry Vyukov wrote:
> > +static bool
> > +tsan_gate (void)
> > +{
> > +  return flag_tsan != 0
> > +&& builtin_decl_implicit_p (BUILT_IN_TSAN_INIT);
> > 
> > 
> > What does it mean? Why builtin_decl_implicit_p (BUILT_IN_TSAN_INIT)?
> 
> It is a temporary workaround, I'll handle it when the patch goes in.
> The thing is that while the C/C++ family of FEs will create all the builtins
> just because they are included in builtins.def, other FEs won't.
> So we need some routine that will build the builtins if the FEs didn't
> initialize them.

Like so.  The c-family/ FEs (C/ObjC/C++/ObjC++) will initialize the builtins
themselves automatically, for other FEs that don't there is a new routine
that initializes them the first time they are needed.

Ok for trunk (the patch is on top of the tsan patch)?

2012-11-22  Jakub Jelinek  

* sanitizer.def: Add Address Sanitizer builtins.
Rename BUILT_IN_TSAN_READ_* to BUILT_IN_TSAN_READ* and
BUILT_IN_TSAN_WRITE_* to BUILT_IN_TSAN_WRITE*.
* Makefile.in (asan.o): Depend on langhooks.h.
(tsan.o): Depend on asan.h.
* asan.h (initialize_sanitizer_builtins): New prototype.
* asan.c: Include langhooks.h.
(report_error_func): Use builtin_decl_implicit of corresponding
BUILT_IN_ASAN_REPORT_{LOAD,STORE}*.
(asan_init_func): Removed.
(initialize_sanitizer_builtins): New function.
(asan_finish_file): Call it.  Use builtin_decl_implicit
on BUILT_IN_ASAN_{INIT,{,UN}REGISTER_GLOBALS}.
(asan_instrument): Call initialize_sanitizer_builtins.
* builtins.def (DEF_SANITIZER_BUILTIN): Change condition to
(flag_asan || flag_tsan).
* tsan.c: Include asan.h and tsan.h.
(get_memory_access_decl): Rename BUILT_IN_TSAN_{READ,WRITE}_*
to BUILT_IN_TSAN_{READ,WRITE}*.
(tsan_pass): Call initialize_sanitizer_builtins.
(tsan_gate, tsan_gate_O0): Don't check if
builtin_decl_implicit_p (BUILT_IN_TSAN_INIT) is true.
(tsan_finish_file): Call initialize_sanitizer_builtins.
* builtin-types.def (BT_FN_VOID_PTR_PTRMODE): New fn type.

--- gcc/sanitizer.def.jj2012-11-22 13:17:24.0 +0100
+++ gcc/sanitizer.def   2012-11-22 15:45:55.873655417 +0100
@@ -1,3 +1,34 @@
+/* Address Sanitizer */
+DEF_SANITIZER_BUILTIN(BUILT_IN_ASAN_INIT, "__asan_init",
+ BT_FN_VOID, ATTR_NOTHROW_LEAF_LIST)
+DEF_SANITIZER_BUILTIN(BUILT_IN_ASAN_REPORT_LOAD1, "__asan_report_load1",
+ BT_FN_VOID_PTR, ATTR_NORETURN_NOTHROW_LEAF_LIST)
+DEF_SANITIZER_BUILTIN(BUILT_IN_ASAN_REPORT_LOAD2, "__asan_report_load2",
+ BT_FN_VOID_PTR, ATTR_NORETURN_NOTHROW_LEAF_LIST)
+DEF_SANITIZER_BUILTIN(BUILT_IN_ASAN_REPORT_LOAD4, "__asan_report_load4",
+ BT_FN_VOID_PTR, ATTR_NORETURN_NOTHROW_LEAF_LIST)
+DEF_SANITIZER_BUILTIN(BUILT_IN_ASAN_REPORT_LOAD8, "__asan_report_load8",
+ BT_FN_VOID_PTR, ATTR_NORETURN_NOTHROW_LEAF_LIST)
+DEF_SANITIZER_BUILTIN(BUILT_IN_ASAN_REPORT_LOAD16, "__asan_report_load16",
+ BT_FN_VOID_PTR, ATTR_NORETURN_NOTHROW_LEAF_LIST)
+DEF_SANITIZER_BUILTIN(BUILT_IN_ASAN_REPORT_STORE1, "__asan_report_store1",
+ BT_FN_VOID_PTR, ATTR_NORETURN_NOTHROW_LEAF_LIST)
+DEF_SANITIZER_BUILTIN(BUILT_IN_ASAN_REPORT_STORE2, "__asan_report_store2",
+ BT_FN_VOID_PTR, ATTR_NORETURN_NOTHROW_LEAF_LIST)
+DEF_SANITIZER_BUILTIN(BUILT_IN_ASAN_REPORT_STORE4, "__asan_report_store4",
+ BT_FN_VOID_PTR, ATTR_NORETURN_NOTHROW_LEAF_LIST)
+DEF_SANITIZER_BUILTIN(BUILT_IN_ASAN_REPORT_STORE8, "__asan_report_store8",
+ BT_FN_VOID_PTR, ATTR_NORETURN_NOTHROW_LEAF_LIST)
+DEF_SANITIZER_BUILTIN(BUILT_IN_ASAN_REPORT_STORE16, "__asan_report_store16",
+ BT_FN_VOID_PTR, ATTR_NORETURN_NOTHROW_LEAF_LIST)
+DEF_SANITIZER_BUILTIN(BUILT_IN_ASAN_REGISTER_GLOBALS,
+ "__asan_register_globals",
+ BT_FN_VOID_PTR_PTRMODE, ATTR_NOTHROW_LEAF_LIST)
+DEF_SANITIZER_BUILTIN(BUILT_IN_ASAN_UNREGISTER_GLOBALS,
+ "__asan_unregister_globals",
+ BT_FN_VOID_PTR_PTRMODE, ATTR_NOTHROW_LEAF_LIST)
+
+/* Thread Sanitizer */
 DEF_SANITIZER_BUILTIN(BUILT_IN_TSAN_INIT, "__tsan_init", 
  BT_FN_VOID, ATTR_NOTHROW_LEAF_LIST)
 DEF_SANITIZER_BUILTIN(BUILT_IN_TSAN_FUNC_ENTRY, "__tsan_func_entry",
@@ -6,23 +37,23 @@ DEF_SANITIZER_BUILTIN(BUILT_IN_TSAN_FUNC
  BT_FN_VOID_PTR, ATTR_NOTHROW_LEAF_LIST)
 DEF_SANITIZER_BUILTIN(BUILT_IN_TSAN_VPTR_UPDATE, "__tsan_vptr_update",
  BT_FN_VOID_PTR, ATTR_NOTHROW_LEAF_LIST)
-DEF_SANITIZER_BUILTIN(BUILT_IN_TSAN_READ_1, "__tsan_read1",
+DEF_SANITIZER_BUILTIN(BUILT_IN_TSAN_READ1, "__tsan_read1",
  BT_FN_VOID_PTR, ATTR_N

C++ PATCH for c++/55137 (dynamic initialization with overflow)

2012-11-22 Thread Jason Merrill
In this PR, fold introduces TREE_OVERFLOW into an expression.  This 
seems wrong, and Jakub has a separate patch to address that issue, but 
it seemed to me that GCC should still do static initialization even if 
the initializer involves overflow.  So this patch adjusts the constexpr 
evaluation code to do normal folding of expressions that involve 
overflow, and just make sure that what we return doesn't have 
TREE_CONSTANT set by wrapping it in a nop.


The second patch fixes an issue revealed by the first patch: when we 
push a TARGET_EXPR into a static variable as part of extending the 
lifetime of reference temporaries, we need to recompute TREE_CONSTANT on 
the ADDR_EXPR around it.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit b2b79ef4bc5b9f1f100656f37cc03cddd527a883
Author: Jason Merrill 
Date:   Fri Nov 16 06:15:26 2012 -0500

	PR c++/55137
	* semantics.c (verify_constant): Track overflow separately.
	(reduced_constant_expression_p): Don't check it here.
	(cxx_eval_constant_expression): Check it on CSTs.
	(cxx_eval_outermost_constant_expr): Treat overflows as non-constant
	at this point, but still return the folded version.
	(potential_constant_expression_1): Don't check overflow.

diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 74b897c..eaf7069 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -6293,10 +6293,7 @@ typedef struct GTY(()) constexpr_call {
 static GTY ((param_is (constexpr_call))) htab_t constexpr_call_table;
 
 static tree cxx_eval_constant_expression (const constexpr_call *, tree,
-	  bool, bool, bool *);
-static tree cxx_eval_vec_perm_expr (const constexpr_call *, tree, bool, bool,
-bool *);
-
+	  bool, bool, bool *, bool *);
 
 /* Compute a hash value for a constexpr call representation.  */
 
@@ -6422,7 +6419,7 @@ lookup_parameter_binding (const constexpr_call *call, tree t)
 static tree
 cxx_eval_builtin_function_call (const constexpr_call *call, tree t,
 bool allow_non_constant, bool addr,
-bool *non_constant_p)
+bool *non_constant_p, bool *overflow_p)
 {
   const int nargs = call_expr_nargs (t);
   tree *args = (tree *) alloca (nargs * sizeof (tree));
@@ -6432,7 +6429,7 @@ cxx_eval_builtin_function_call (const constexpr_call *call, tree t,
 {
   args[i] = cxx_eval_constant_expression (call, CALL_EXPR_ARG (t, i),
 	  allow_non_constant, addr,
-	  non_constant_p);
+	  non_constant_p, overflow_p);
   if (allow_non_constant && *non_constant_p)
 	return t;
 }
@@ -6468,7 +6465,7 @@ static void
 cxx_bind_parameters_in_call (const constexpr_call *old_call, tree t,
  constexpr_call *new_call,
 			 bool allow_non_constant,
-			 bool *non_constant_p)
+			 bool *non_constant_p, bool *overflow_p)
 {
   const int nargs = call_expr_nargs (t);
   tree fun = new_call->fundef->decl;
@@ -6486,7 +6483,7 @@ cxx_bind_parameters_in_call (const constexpr_call *old_call, tree t,
   x = get_nth_callarg (t, i);
   arg = cxx_eval_constant_expression (old_call, x, allow_non_constant,
 	  TREE_CODE (type) == REFERENCE_TYPE,
-	  non_constant_p);
+	  non_constant_p, overflow_p);
   /* Don't VERIFY_CONSTANT here.  */
   if (*non_constant_p && allow_non_constant)
 	return;
@@ -6551,7 +6548,7 @@ cx_error_context (void)
 static tree
 cxx_eval_call_expression (const constexpr_call *old_call, tree t,
 			  bool allow_non_constant, bool addr,
-			  bool *non_constant_p)
+			  bool *non_constant_p, bool *overflow_p)
 {
   location_t loc = EXPR_LOC_OR_HERE (t);
   tree fun = get_function_named_in_call (t);
@@ -6565,7 +6562,7 @@ cxx_eval_call_expression (const constexpr_call *old_call, tree t,
 {
   /* Might be a constexpr function pointer.  */
   fun = cxx_eval_constant_expression (old_call, fun, allow_non_constant,
-	  /*addr*/false, non_constant_p);
+	  /*addr*/false, non_constant_p, overflow_p);
   if (TREE_CODE (fun) == ADDR_EXPR)
 	fun = TREE_OPERAND (fun, 0);
 }
@@ -6581,7 +6578,7 @@ cxx_eval_call_expression (const constexpr_call *old_call, tree t,
 fun = DECL_CLONED_FUNCTION (fun);
   if (is_builtin_fn (fun))
 return cxx_eval_builtin_function_call (old_call, t, allow_non_constant,
-	   addr, non_constant_p);
+	   addr, non_constant_p, overflow_p);
   if (!DECL_DECLARED_CONSTEXPR_P (fun))
 {
   if (!allow_non_constant)
@@ -6598,7 +6595,7 @@ cxx_eval_call_expression (const constexpr_call *old_call, tree t,
 {
   tree arg = convert_from_reference (get_nth_callarg (t, 1));
   return cxx_eval_constant_expression (old_call, arg, allow_non_constant,
-	   addr, non_constant_p);
+	   addr, non_constant_p, overflow_p);
 }
 
   /* If in direct recursive call, optimize definition search.  */
@@ -6625,7 +6622,7 @@ cxx_eval_call_expression (const constexpr_call *old_call, tree t,
 }
 }
   cxx_bind_parameters_in_call (old_call, t, &new_call,
-			 

Re: [AARCH64] Update maintainers file

2012-11-22 Thread Gerald Pfeifer
On Thu, 22 Nov 2012, Richard Earnshaw wrote:
> Haven't seen any follow-up on this.  Since it's fairly trivial, I've 
> committed it as obvious; but I'm happy to change it if you feel it 
> should be worded differently.

This looks just fine to me, thanks!  (I've been in those flying metal 
tubes much of the last two days, or you would have seen me respond so
right away.)

You can also mention the names of key contributors, by the way, which
may be nice.

Gerald


Re: [C++ PATCH] Fix PR 55418

2012-11-22 Thread Paolo Carlini

Hi,

On 11/22/2012 04:06 PM, Jakub Jelinek wrote:

On Thu, Nov 22, 2012 at 02:28:18PM +0100, Paolo Carlini wrote:

On 11/22/2012 01:06 PM, Markus Trippelsdorf wrote:

The fix is trivial. I would appreciate if someone could commit this.

I agree it qualifies as obvious and I mean to commit the patch on
your behalf before the end of the day if nobody objects. To be
super-safe, I guess I will also run the testsuite with the current
code and trivial_p initialized to true at the beginning of the
function.

I think trivial_p used to be uninitialized only for deleted_p functions,
not sure if those are considered trivial or not (and whether it matters)...
I think that the Valgrind complain is benign and, by the way, I just run 
the testsuite with current code + trivial_p initialized to true with no 
regressions. In detail what is happening is that, as you say, in the 
special case of deleted_p true and lambdas, we return from 
synthesized_method_walk and trivial_p is still uninitialized. Then we have:


  if (!trivial_p && type_has_trivial_fn (type, kind))
type_set_nontrivial_flag (type, kind);

which, if trivial_p is is still uninitialized may not do its job of 
forcing nontrivial set in type: I don't think this is a serious problem 
for lambdas (in any case, when code elsewhere detects deleted shouldn't 
bother anyway of checking triviality; testsuite passes with trivial_p 
initialized to true too), but Markus (and me ;) proposes anyway to 
initialize trivial_p to false, thus we should be fine (way below 
trivial_p is used again but only when deleted_p is false).


Paolo.


[PATCH, i386]: Modernize FP compares using mode attributes

2012-11-22 Thread Uros Bizjak
Hello!

No functional change.

2012-11-22  Uros Bizjak  

* config/i386/i386.md (FPCMP): New mode iterator.
(unord): New mode attribute.
(*cmp_0_i387): Macroize insn from *cmpfp_0
using X87MODEF mode iterator.
(*cmp_0_cc_i387): Macroize insn from *cmpfp_0_cc using
X87MODEF mode iterator.
(*cmpxf_i387): Rename from *cmpfp_xf.
(*cmpxf_cc_i387): Rename from *cmpfp_xf_cc.
(*cmp_i387): Rename from *cmpfp_.
(*cmp_cc_i387): Rename from *cmpfp__cc.
(*cmpu_i387): Macroize insn from *cmpfp_u using X87MODEF
mode iterator.
(*cmpu_cc_i387): Macroize insn from *cmpfp_u_cc using X87MODEF
mode iterator.
(*cmp__i387): Macroize_insn from
*cmpfp_ using X87MODEF mode iterator.
(*cmp__cc_i387): Macroize_insn from
*cmpfp__cc using X87MODEF mode iterator.
(*cmp_mixed): Macroize insn from
*cmpfp_i{,u}_mixed using FPCMP and MODEF mode iterators.
(*cmp_mixed): Macroize insn from
*cmpfp_i{,u}_sse using FPCMP and MODEF mode iterators.
(*cmp_i387): Macroize insn from
*cmpfp_i{,u}_387 using FPCMP and X87MODEF mode iterators.

Tested on x86_64-linux-gnu {,-m32}, committed to mainline SVN.

Uros.
Index: i386.md
===
--- i386.md (revision 193728)
+++ i386.md (working copy)
@@ -1237,35 +1237,26 @@
 ;; We may not use "#" to split and emit these, since the REG_DEAD notes
 ;; used to manage the reg stack popping would not be preserved.
 
-(define_insn "*cmpfp_0"
+(define_insn "*cmp_0_i387"
   [(set (match_operand:HI 0 "register_operand" "=a")
(unspec:HI
  [(compare:CCFP
-(match_operand 1 "register_operand" "f")
-(match_operand 2 "const0_operand"))]
+(match_operand:X87MODEF 1 "register_operand" "f")
+(match_operand:X87MODEF 2 "const0_operand"))]
UNSPEC_FNSTSW))]
-  "X87_FLOAT_MODE_P (GET_MODE (operands[1]))
-   && GET_MODE (operands[1]) == GET_MODE (operands[2])"
+  "TARGET_80387"
   "* return output_fp_compare (insn, operands, false, false);"
   [(set_attr "type" "multi")
(set_attr "unit" "i387")
-   (set (attr "mode")
- (cond [(match_operand:SF 1)
- (const_string "SF")
-   (match_operand:DF 1)
- (const_string "DF")
-  ]
-  (const_string "XF")))])
+   (set_attr "mode" "")])
 
-(define_insn_and_split "*cmpfp_0_cc"
+(define_insn_and_split "*cmp_0_cc_i387"
   [(set (reg:CCFP FLAGS_REG)
(compare:CCFP
- (match_operand 1 "register_operand" "f")
- (match_operand 2 "const0_operand")))
+ (match_operand:X87MODEF 1 "register_operand" "f")
+ (match_operand:X87MODEF 2 "const0_operand")))
(clobber (match_operand:HI 0 "register_operand" "=a"))]
-  "X87_FLOAT_MODE_P (GET_MODE (operands[1]))
-   && TARGET_SAHF && !TARGET_CMOVE
-   && GET_MODE (operands[1]) == GET_MODE (operands[2])"
+  "TARGET_80387 && TARGET_SAHF && !TARGET_CMOVE"
   "#"
   "&& reload_completed"
   [(set (match_dup 0)
@@ -1277,15 +1268,9 @@
   ""
   [(set_attr "type" "multi")
(set_attr "unit" "i387")
-   (set (attr "mode")
- (cond [(match_operand:SF 1)
- (const_string "SF")
-   (match_operand:DF 1)
- (const_string "DF")
-  ]
-  (const_string "XF")))])
+   (set_attr "mode" "")])
 
-(define_insn "*cmpfp_xf"
+(define_insn "*cmpxf_i387"
   [(set (match_operand:HI 0 "register_operand" "=a")
(unspec:HI
  [(compare:CCFP
@@ -1298,14 +1283,13 @@
(set_attr "unit" "i387")
(set_attr "mode" "XF")])
 
-(define_insn_and_split "*cmpfp_xf_cc"
+(define_insn_and_split "*cmpxf_cc_i387"
   [(set (reg:CCFP FLAGS_REG)
(compare:CCFP
  (match_operand:XF 1 "register_operand" "f")
  (match_operand:XF 2 "register_operand" "f")))
(clobber (match_operand:HI 0 "register_operand" "=a"))]
-  "TARGET_80387
-   && TARGET_SAHF && !TARGET_CMOVE"
+  "TARGET_80387 && TARGET_SAHF && !TARGET_CMOVE"
   "#"
   "&& reload_completed"
   [(set (match_dup 0)
@@ -1319,7 +1303,7 @@
(set_attr "unit" "i387")
(set_attr "mode" "XF")])
 
-(define_insn "*cmpfp_"
+(define_insn "*cmp_i387"
   [(set (match_operand:HI 0 "register_operand" "=a")
(unspec:HI
  [(compare:CCFP
@@ -1332,14 +1316,13 @@
(set_attr "unit" "i387")
(set_attr "mode" "")])
 
-(define_insn_and_split "*cmpfp__cc"
+(define_insn_and_split "*cmp_cc_i387"
   [(set (reg:CCFP FLAGS_REG)
(compare:CCFP
  (match_operand:MODEF 1 "register_operand" "f")
  (match_operand:MODEF 2 "nonimmediate_operand" "fm")))
(clobber (match_operand:HI 0 "register_operand" "=a"))]
-  "TARGET_80387
-   && TARGET_SAHF && !TARGET_CMOVE"
+  "TARGET_80387 && TARGET_SAHF && !TARGET_CMOVE"
   "#"
   "&& reload_completed"
   [(set (match_dup 0)
@@ -1353,35 +1336,26 @@
(set_attr "unit" "i387")
(set_attr "mode" "")])
 
-

[PATCH][AARCH64] Fix the name mangling of AdvSIMD vector types

2012-11-22 Thread Yufeng Zhang

Hi,

This patch implements the correct name mangling of AArch64 AdvSIMD 
vector types in conformance to the AAPCS64 doc (Procedure Call Standard 
for the ARM 64-bit Architecture, Appendix A).


OK for the trunk?

Thanks,
Yufeng

gcc/ChangeLog

2012-11-22  Yufeng Zhang  

* config/aarch64/aarch64.c (aarch64_simd_mangle_map_entry): New
typedef.
(aarch64_simd_mangle_map): New table.
(aarch64_mangle_type): Locate and return the mangled name for
a given AdvSIMD vector type.

gcc/testsuite/ChangeLog

2012-11-22  Yufeng Zhang  

* g++.dg/abi/mangle-neon-aarch64.C: New test.diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 42f3a40..ba84a39 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -5853,6 +5853,50 @@ aarch64_preferred_simd_mode (enum machine_mode mode)
   return word_mode;
 }
 
+/* A table to help perform AArch64-specific name mangling for AdvSIMD
+   vector types in order to conform to the AAPCS64 (see "Procedure
+   Call Standard for the ARM 64-bit Architecture", Appendix A).  To
+   qualify for emission with the mangled names defined in that document,
+   a vector type must not only be of the correct mode but also be
+   composed of AdvSIMD vector element types (e.g.
+   _builtin_aarch64_simd_qi); these types are registered by
+   aarch64_init_simd_builtins ().  In other words, vector types defined
+   in other ways e.g. via vector_size attribute will get default
+   mangled names.  */
+typedef struct
+{
+  enum machine_mode mode;
+  const char *element_type_name;
+  const char *mangled_name;
+} aarch64_simd_mangle_map_entry;
+
+static aarch64_simd_mangle_map_entry aarch64_simd_mangle_map[] = {
+  /* 64-bit containerized types.  */
+  { V8QImode,  "__builtin_aarch64_simd_qi", "10__Int8x8_t" },
+  { V8QImode,  "__builtin_aarch64_simd_uqi","11__Uint8x8_t" },
+  { V4HImode,  "__builtin_aarch64_simd_hi", "11__Int16x4_t" },
+  { V4HImode,  "__builtin_aarch64_simd_uhi","12__Uint16x4_t" },
+  { V2SImode,  "__builtin_aarch64_simd_si", "11__Int32x2_t" },
+  { V2SImode,  "__builtin_aarch64_simd_usi","12__Uint32x2_t" },
+  { V2SFmode,  "__builtin_aarch64_simd_sf", "13__Float32x2_t" },
+  { V8QImode,  "__builtin_aarch64_simd_poly8",  "11__Poly8x8_t" },
+  { V4HImode,  "__builtin_aarch64_simd_poly16", "12__Poly16x4_t" },
+  /* 128-bit containerized types.  */
+  { V16QImode, "__builtin_aarch64_simd_qi", "11__Int8x16_t" },
+  { V16QImode, "__builtin_aarch64_simd_uqi","12__Uint8x16_t" },
+  { V8HImode,  "__builtin_aarch64_simd_hi", "11__Int16x8_t" },
+  { V8HImode,  "__builtin_aarch64_simd_uhi","12__Uint16x8_t" },
+  { V4SImode,  "__builtin_aarch64_simd_si", "11__Int32x4_t" },
+  { V4SImode,  "__builtin_aarch64_simd_usi","12__Uint32x4_t" },
+  { V2DImode,  "__builtin_aarch64_simd_di", "11__Int64x2_t" },
+  { V2DImode,  "__builtin_aarch64_simd_udi","12__Uint64x2_t" },
+  { V4SFmode,  "__builtin_aarch64_simd_sf", "13__Float32x4_t" },
+  { V2DFmode,  "__builtin_aarch64_simd_df", "13__Float64x2_t" },
+  { V16QImode, "__builtin_aarch64_simd_poly8",  "12__Poly8x16_t" },
+  { V8HImode,  "__builtin_aarch64_simd_poly16", "12__Poly16x8_t" },
+  { VOIDmode, NULL, NULL }
+};
+
 /* Implement TARGET_MANGLE_TYPE.  */
 
 const char *
@@ -5863,6 +5907,26 @@ aarch64_mangle_type (const_tree type)
   if (lang_hooks.types_compatible_p (CONST_CAST_TREE (type), va_list_type))
 return "St9__va_list";
 
+  /* Check the mode of the vector type, and the name of the vector
+ element type, against the table.  */
+  if (TREE_CODE (type) == VECTOR_TYPE)
+{
+  aarch64_simd_mangle_map_entry *pos = aarch64_simd_mangle_map;
+
+  while (pos->mode != VOIDmode)
+	{
+	  tree elt_type = TREE_TYPE (type);
+
+	  if (pos->mode == TYPE_MODE (type)
+	  && TREE_CODE (TYPE_NAME (elt_type)) == TYPE_DECL
+	  && !strcmp (IDENTIFIER_POINTER (DECL_NAME (TYPE_NAME (elt_type))),
+			  pos->element_type_name))
+	return pos->mangled_name;
+
+	  pos++;
+	}
+}
+
   /* Use the default mangling.  */
   return NULL;
 }
diff --git a/gcc/testsuite/g++.dg/abi/mangle-neon-aarch64.C b/gcc/testsuite/g++.dg/abi/mangle-neon-aarch64.C
new file mode 100644
index 000..09540e8
--- /dev/null
+++ b/gcc/testsuite/g++.dg/abi/mangle-neon-aarch64.C
@@ -0,0 +1,55 @@
+// Test that AArch64 AdvSIMD (NEON) vector types have their names mangled
+// correctly.
+
+// { dg-do compile { target { aarch64*-*-* } } }
+
+#include 
+
+void f0 (int8x8_t a) {}
+void f1 (int16x4_t a) {}
+void f2 (int32x2_t a) {}
+void f3 (uint8x8_t a) {}
+void f4 (uint16x4_t a) {}
+void f5 (uint32x2_t a) {}
+void f6 (float32x2_t a) {}
+void f7 (poly8x8_t a) {}
+void f8 (poly16x4_t a) {}
+
+void f9 (int8x16_t a) {}
+void f10 (int16x8_t a) {}
+void f11 (int32x4_t a) {}
+void f12 (int64x2_t a) {}
+void f13 (uint8x16_t a) {}
+void f14 (uint16x8_t a) {}
+void f15 (uint32x4_t a) {}
+void f16 (uint64x2_t a) {}
+void f17 (flo

[Patch,testsuite] ad PR52641: Fix some more tests that fail for small targets

2012-11-22 Thread Georg-Johann Lay
Some more skips for tests that will fail with 16-bit int etc.

Ok for trunk?

Johann

PR testsuite/52641
* gcc.dg/unroll_5.c: Add dg-require-effective-target int32plus.
* gcc.dg/pr55150-1.c: Same.
* gcc.dg/torture/pr54894.c: Add size32plus.
Index: gcc.dg/unroll_5.c
===
--- gcc.dg/unroll_5.c	(revision 193721)
+++ gcc.dg/unroll_5.c	(working copy)
@@ -1,5 +1,7 @@
 /* { dg-do compile } */
 /* { dg-options "-O3 -fdump-rtl-loop2_unroll -funroll-loops" } */
+/* { dg-require-effective-target int32plus } */
+
 void abort (void);
 int *a;
 int t()
Index: gcc.dg/pr55150-1.c
===
--- gcc.dg/pr55150-1.c	(revision 193721)
+++ gcc.dg/pr55150-1.c	(working copy)
@@ -1,6 +1,7 @@
 /* PR middle-end/55150 */
 /* { dg-do compile } */
 /* { dg-options "-Os -g" } */
+/* { dg-require-effective-target int32plus } */
 
 typedef unsigned int KEY_TABLE_TYPE[(272 / 4)];
   typedef unsigned int u32;
Index: gcc.dg/torture/pr54894.c
===
--- gcc.dg/torture/pr54894.c	(revision 193721)
+++ gcc.dg/torture/pr54894.c	(working copy)
@@ -1,4 +1,5 @@
 /* { dg-do compile } */
+/* { dg-require-effective-target size32plus } */
 
 typedef unsigned long long uint64_t;
 


[PATCH, generic] Fix for define_subst

2012-11-22 Thread Kirill Yukhin
Hello,
Here is copy-and-paste from issue raised by Ian (in the bottom).

Fix is attached.
ChangeLog entry:
2012-11-22  Michael Zolotukhin  

* gensupport.c (add_c_test): Check if expr isn't NULL.

Is it ok for trunk?

=== CUT HERE ===
It looks like the recent VEC rewrite might have interacted badly with
this patch.

I am getting a segfault in genconditions.c when add_c_test is called
for "desc".

I think it is because the condition is not within a vector.


Example of "desc" for working pattern:

(define_insn ("*zero_extendqihi2_aarch64")
 [
(set (match_operand:HI 0 ("register_operand") ("=r,r"))
(zero_extend:HI (match_operand:QI 1 ("nonimmediate_operand")
("r,m"
] ("") ("@
   uxtb\t%w0, %w1
   ldrb\t%w0, %1")
 [
(set_attr ("v8type") ("extend,load1"))
(set_attr ("mode") ("HI"))
])


Example of "desc" for broken one that uses define_subst:

(define_insn ("*addsi3_aarch64_noextend")
 [
(set (match_operand:SI 0 ("register_operand") ("=rk,rk,rk"))
(plus:SI (match_operand:SI 1 ("register_operand") ("%rk,rk,rk"))
(match_operand:SI 2 ("aarch64_plus_operand") ("I,r,J"
] "" ("@
  add\t%w0, %w1, %2
  add\t%w0, %w1, %w2
  sub\t%w0, %w1, #%n2")
 [
(set_attr ("v8type") ("alu"))
(set_attr ("mode") ("SI"))
])


Note that there are no brackets around the "" condition.  That's the issue,
I
think.

=== CUT HERE ===

Thanks, K


add_c_test.patch
Description: Binary data


Re: [PATCH, RFC] Enable libsanitizer on powerpc{,64}

2012-11-22 Thread Konstantin Serebryany
On Thu, Nov 22, 2012 at 12:38 PM, Evgeniy Stepanov
 wrote:
> Yes, it has 3 asan-rtl frames on top. I'm not sure why this does not
> happen on ppc.

Different inlining inside run-time.
I still prefer a simple PopFrames to anything else, I am sure we can
make it reliable.
the asan run-time should always be build with optimizations on and we
can force or (better) forbid inlining for any function.

--kcc

>
> #0 0x40122cdb in __asan::GetStackTrace(__sanitizer::StackTrace*,
> unsigned long, unsigned long, unsigned long)
> #1 0x40125167 in __asan_report_error
> #2 0x40125af3 in __asan_report_load1
>
>
> On Thu, Nov 22, 2012 at 12:10 AM, Evgeniy Stepanov
>  wrote:
>> I'm looking into the empty stack issue, at this point it looks like a weird
>> linker bug. But its completely orthogonal to this discussion.
>>
>> I recall that the stack trace of the offending memory access has in fact
>> three extra frames on top. I'll verify tomorrow. If so, FP/SP matching
>> solution is preferable.
>>
>> On Nov 21, 2012 9:08 PM, "Peter Bergner"  wrote:
>>>
>>> On Wed, 2012-11-21 at 20:22 +0400, Konstantin Serebryany wrote:
>>> > On Wed, Nov 21, 2012 at 8:16 PM, Peter Bergner 
>>> > wrote:
>>> > > On Wed, 2012-11-21 at 13:46 +0400, Evgeniy Stepanov wrote:
>>> > >> Matching FP or SP also sounds good, and perhaps more reliable than
>>> > >> just popping 2 frames from the top of the stack.
>>> > >
>>> > > Agreed.  Can you try my second patch that searches for the frame
>>> > > address we want our backtrace to start with and see if that works
>>> > > for ARM?  The nice thing about that patch is that we won't have
>>> > > to play any games with forcing or disabling inlining of any of
>>> > > the ASAN functions which me might have to do if we always pop
>>> > > 2 frames off the stack.  It would also be tolerant of adding
>>> > > any number of new function calls in between the current two
>>> > > ASAN function at the top of the backtrace.
>>> > >
>>> > > http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01711.html
>>> > >
>>> > > Bah, ignore that first diff of the LAST_UPDATED file. :(
>>> >
>>> > I'd actually prefer to keep the current code that pops two frames
>>> > (if it works for you)
>>>
>>> Well it does work for me, since I wrote it. :)  That being said, the
>>> change where I always pop two frames off of the backtrace was more of
>>> a proof of concept that if I can remove those ASAN functions from the
>>> backtrace, do we pass the test case in the testsuite.  It did, but I
>>> have to admit that code is extremely fragile.  It is dependent not
>>> only on the inlining heuristics of one compiler, but of two compilers!
>>> Not to mention people building debugable compilers with -O0 -fno-inline,
>>> etc. etc.  We'd also have to make sure no one in the future adds any
>>> ASAN function calls in between the report function and the GetBackTrace
>>> calls.  It just seems like there are so many things that could go wrong,
>>> that something is bound to.
>>>
>>>
>>> > Evgeniy seems to know how to fix the ARM case.
>>>
>>> His fix was to do:
>>>
>>>  void StackTrace::PopStackFrames(uptr count) {
>>> -  CHECK(size > count);
>>> +  CHECK(size >= count);
>>>size -= count;
>>>for (uptr i = 0; i < size; i++) {
>>>  trace[i] = trace[i + count];
>>>
>>> Basically, that is allowing for us to pop off all of the frames from
>>> the backtrace leaving an empty backtrace.  That can't be helpful in
>>> tracking down the address violation, can it?  With my patch above,
>>> either we find the frame we want to start our backtrace with, or
>>> it returns the entire backtrace, ASAN functions and all.  Isn't that
>>> better from a diagnostic point of view?
>>>
>>> That being said, I'd still like to hear from Evgeniy whether my
>>> patch above helps ARM or not.
>>>
>>> Peter
>>>
>>>
>>>
>>


[PATCH, RFC] Dumping expanded MD files

2012-11-22 Thread Kirill Yukhin
Hi folks,

This patch adds an utility for dumping MD-files after iterators and
define_substs expanding. The new utility is named genmddump and is
built along with other gen* programs.

I also added new target to Makefile to invoke this utility. However,
I’m not sure it’s general enough to be added to the top-level
makefile, so your suggestions on where we should place it and how it
should be invoked are welcome.

ChangeLog

2012-11-22  Michael Zolotukhin  

* Makefile.in: Add targets mddump and mddump-gcc for dumping expanded
 MD-files.

gcc/ChangeLog

2012-11-22  Michael Zolotukhin  

* Makefile.in: Add targets s-mddump, build/genmddump.o.  Extend
genprogrtl with mddump.

* genmddump.c: New.
* gensupport.c (dump_rtl_queue): New.
(dump_expanded_md): New.
* gensupport.h: Declare dump_expanded_md.

What do you guys think?

Thanks, K


md_expanded_dumping-1.patch
Description: Binary data


[PATCH] Remove 'Utf' constraint documentation for AArch64.

2012-11-22 Thread Marcus Shawcroft
This patch removes the documentation for the AArch64 constraint 'Utf'. 
The implementation was removed before the port was merged to trunk, but 
the documentation was missed.


Committed as obvious.

/Marcus

2012-11-22  Marcus Shawcroft  

* doc/md.texi (AArch64 family): Remove Utf.diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
index 297058c..6a4e0be 100644
--- a/gcc/doc/md.texi
+++ b/gcc/doc/md.texi
@@ -1727,9 +1727,6 @@ A memory address which uses a single base register with no offset
 A memory address suitable for a load/store pair instruction in SI, DI, SF and
 DF modes
 
-@item Utf
-A memory address suitable for a load/store pair instruction in TF mode
-
 @end table
 
 

[AARCH64-47, PATCH] Remove 'Utf' constraint documentation for AArch64.

2012-11-22 Thread Marcus Shawcroft

I've also committed this to ARM/aarch64-4.7-branch.

/Marcus

2012-11-22  Marcus Shawcroft  

 * doc/md.texi (AArch64 family): Remove Utf.
diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
index 297058c..6a4e0be 100644
--- a/gcc/doc/md.texi
+++ b/gcc/doc/md.texi
@@ -1727,9 +1727,6 @@ A memory address which uses a single base register with no offset
 A memory address suitable for a load/store pair instruction in SI, DI, SF and
 DF modes
 
-@item Utf
-A memory address suitable for a load/store pair instruction in TF mode
-
 @end table
 
 


Re: [PATCH] Add no_address_safety_analysis attribute (PR sanitizer/55435)

2012-11-22 Thread Konstantin Serebryany
Looks good!
(not sure if I am a proper reviewer though)

--kcc

On Thu, Nov 22, 2012 at 3:07 PM, Jakub Jelinek  wrote:
> Hi!
>
> This patch adds the no_address_safety_analysis attribute.  Tested on
> x86_64-linux, ok for trunk?
>
> 2012-11-22  Jakub Jelinek  
>
> PR sanitizer/55435
> * c-common.c (handle_no_address_safety_analysis_attribute): New
> function.
> (c_common_attribute_table): Add no_address_safety_analysis.
>
> * asan.c (gate_asan): Don't instrument functions with
> no_address_safety_analysis attribute.
> (gate_asan_O0): Use !optimize && gate_asan ().
> * doc/extend.texi (no_address_safety_analysis): Document new
> function attribute.
>
> * c-c++-common/asan/attrib-1.c: New test.
>
> --- gcc/c-family/c-common.c.jj  2012-11-19 14:41:10.0 +0100
> +++ gcc/c-family/c-common.c 2012-11-22 11:51:48.053996443 +0100
> @@ -309,6 +309,8 @@ static tree handle_common_attribute (tre
>  static tree handle_noreturn_attribute (tree *, tree, tree, int, bool *);
>  static tree handle_hot_attribute (tree *, tree, tree, int, bool *);
>  static tree handle_cold_attribute (tree *, tree, tree, int, bool *);
> +static tree handle_no_address_safety_analysis_attribute (tree *, tree, tree,
> +int, bool *);
>  static tree handle_noinline_attribute (tree *, tree, tree, int, bool *);
>  static tree handle_noclone_attribute (tree *, tree, tree, int, bool *);
>  static tree handle_leaf_attribute (tree *, tree, tree, int, bool *);
> @@ -711,6 +713,10 @@ const struct attribute_spec c_common_att
>   handle_cold_attribute, false },
>{ "hot",0, 0, true,  false, false,
>   handle_hot_attribute, false },
> +  { "no_address_safety_analysis",
> + 0, 0, true, false, false,
> + handle_no_address_safety_analysis_attribute,
> + false },
>{ "warning",   1, 1, true,  false, false,
>   handle_error_attribute, false },
>{ "error", 1, 1, true,  false, false,
> @@ -6477,6 +6483,22 @@ handle_cold_attribute (tree *node, tree
>  {
>warning (OPT_Wattributes, "%qE attribute ignored", name);
>*no_add_attrs = true;
> +}
> +
> +  return NULL_TREE;
> +}
> +
> +/* Handle a "no_address_safety_analysis" attribute; arguments as in
> +   struct attribute_spec.handler.  */
> +
> +static tree
> +handle_no_address_safety_analysis_attribute (tree *node, tree name, tree, 
> int,
> +bool *no_add_attrs)
> +{
> +  if (TREE_CODE (*node) != FUNCTION_DECL)
> +{
> +  warning (OPT_Wattributes, "%qE attribute ignored", name);
> +  *no_add_attrs = true;
>  }
>
>return NULL_TREE;
> --- gcc/asan.c.jj   2012-11-19 14:41:20.0 +0100
> +++ gcc/asan.c  2012-11-22 11:35:47.310489415 +0100
> @@ -1587,7 +1587,9 @@ asan_instrument (void)
>  static bool
>  gate_asan (void)
>  {
> -  return flag_asan != 0;
> +  return flag_asan != 0
> + && !lookup_attribute ("no_address_safety_analysis",
> +   DECL_ATTRIBUTES (current_function_decl));
>  }
>
>  struct gimple_opt_pass pass_asan =
> @@ -1614,7 +1616,7 @@ struct gimple_opt_pass pass_asan =
>  static bool
>  gate_asan_O0 (void)
>  {
> -  return flag_asan != 0 && !optimize;
> +  return !optimize && gate_asan ();
>  }
>
>  struct gimple_opt_pass pass_asan_O0 =
> --- gcc/doc/extend.texi.jj  2012-11-19 14:41:08.0 +0100
> +++ gcc/doc/extend.texi 2012-11-22 11:52:20.913814831 +0100
> @@ -2130,10 +2130,11 @@ attributes are currently defined for fun
>  @code{weak}, @code{malloc}, @code{alias}, @code{ifunc},
>  @code{warn_unused_result}, @code{nonnull}, @code{gnu_inline},
>  @code{externally_visible}, @code{hot}, @code{cold}, @code{artificial},
> -@code{error} and @code{warning}.  Several other attributes are defined
> -for functions on particular target systems.  Other attributes,
> -including @code{section} are supported for variables declarations
> -(@pxref{Variable Attributes}) and for types (@pxref{Type Attributes}).
> +@code{no_address_safety_analysis}, @code{error} and @code{warning}.
> +Several other attributes are defined for functions on particular
> +target systems.  Other attributes, including @code{section} are
> +supported for variables declarations (@pxref{Variable Attributes})
> +and for types (@pxref{Type Attributes}).
>
>  GCC plugins may provide their own attributes.
>
> @@ -3416,6 +3417,12 @@ with computed goto or @code{asm goto}.
>  The @code{cold} attribute on labels is not implemented in GCC versions
>  earlier than 4.8.
>
> +@item no_address_safety_analysis
> +@cindex @code{no_address_safety_analysis} function attribute
> +The @code{no_address_safety_analysis} attribute on functions is used
> +to inform the comp

Re: [libsanitizer] a script to help merging asan from upstream

2012-11-22 Thread Konstantin Serebryany
Anything else?

On Thu, Nov 22, 2012 at 6:42 AM, Konstantin Serebryany
 wrote:
> Added to README.gcc:
> The merges from upstream should be done with the aid of the merge.sh script;
> it will also update the file MERGE to contain the upstream revision
> we merged with.
>
>
> On Wed, Nov 21, 2012 at 11:03 PM, Xinliang David Li  
> wrote:
>> How about also documenting this in README.gcc?
>>
>> David
>>
>> On Wed, Nov 21, 2012 at 10:56 AM, Kostya Serebryany  wrote:
>>> Done both.
>>>
>>>
>>> +fatal() {
>>> +  echo "$1"
>>> +  exit 1;
>>> +}
>>> +
>>> +pwd | grep 'libsanitizer$' || \
>>> +  fatal "Run this script from libsanitizer dir"
>>>
>>>
>>> +rm -rf upstream
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Nov 21, 2012 at 10:49 PM, Xinliang David Li  
>>> wrote:
 Suggestions:

 1) make sure current local dir is libsanitizer -- exit if it is not
 2) clean up the upstream directory after the merge is done.

 David


 On Wed, Nov 21, 2012 at 10:25 AM, Kostya Serebryany  
 wrote:
> Hi,
>
> A dummy script to help merging asan from upstream.
> Not 100% complete, but should be enough to complete the current merge.
>
> You suggestions on how to improve it (or how to do w/o it) are welcome,
> but I really wish to do the first merge tomorrow to unblock other folks.
>
> Thanks,
> --kcc


merge.patch
Description: Binary data


Re: [PATCH, i386]: Modernize FP compares using mode attributes

2012-11-22 Thread Steven Bosscher
On Thu, Nov 22, 2012 at 5:40 PM, Uros Bizjak wrote:
> Hello!
>
> No functional change.

These are all nice cleanups, but is this really stage3-material?

Ciao!
Steven


Re: [PATCH, i386]: Modernize FP compares using mode attributes

2012-11-22 Thread Uros Bizjak
On Thu, Nov 22, 2012 at 8:40 PM, Steven Bosscher  wrote:
> On Thu, Nov 22, 2012 at 5:40 PM, Uros Bizjak wrote:

>> No functional change.
>
> These are all nice cleanups, but is this really stage3-material?

Not realy, I agree, but I was fairly confident in the patch due to "no
functional change" claim. I have one similar patch in my queue and
then I will leave i386.md alone.

Uros.


[PATCH] Add --with-build-config=bootstrap-asan support

2012-11-22 Thread H.J. Lu
Hi,

This patch adds --with-build-config=bootstrap-asan support.  Tested on
Linux/x86-64.  OK to install?

Thanks.


H.J.
---
2012-11-21  H.J. Lu  

* Makefile.def (target_modules): Add bootstrap=true and
raw_cxx=true to libsanitizer.
* configure.ac (bootstrap_target_libs): Add libsanitizer.
* Makefile.in: Regenerated.
* configure: Likewise.

config/

2012-11-21  H.J. Lu  

* bootstrap-asan.mk: New file.

diff --git a/Makefile.def b/Makefile.def
index 1ea63ac..8d8af23 100644
--- a/Makefile.def
+++ b/Makefile.def
@@ -119,7 +119,10 @@ 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;
+  raw_cxx=true; };
 target_modules = { module= libssp; lib_path=.libs; };
 target_modules = { module= newlib; };
 target_modules = { module= libgcc; bootstrap=true; no_check=true; };
diff --git a/config/bootstrap-asan.mk b/config/bootstrap-asan.mk
new file mode 100644
index 000..d37a9da
--- /dev/null
+++ b/config/bootstrap-asan.mk
@@ -0,0 +1,6 @@
+# This option enables -fsanitize=address for stage2 and stage3.
+
+STAGE2_CFLAGS += -fsanitize=address
+STAGE3_CFLAGS += -fsanitize=address
+POSTSTAGE1_LDFLAGS += -fsanitize=address -static-libasan \
+ -B$$r/prev-$(TARGET_SUBDIR)/libsanitizer/asan/.libs
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!
-- 
1.7.11.7



[PATCH, i386]: Modernize FP compares using mode attributes, part 2

2012-11-22 Thread Uros Bizjak
Hello!

Attached patch converts FP compares inside FP jcc combine helpers.

2012-11-22  Uros Bizjak  

* config/i386/i386.md (*jcc_0_i387): Macroize insn
from *fp_jcc_3_387 using X87MODEF mode iterator.
(*jcc_0_r_i387): New.
(*jccxf_i387): Ditto.
(*jccxf_r_i387): Ditto.
(*jcc_i387): Macroize insn from *fp_jcc_1_387 using
MODEF mode iterator.
(*jcc_r_i387): Macroize insn from *fp_jcc_1r_387 using
MODEF mode iterator.
(*jccu_i387): Macroize insn from *fp_jcc_2_387 using
X87MODEF mode iterator.
(*jccu_r_i387): Macroize insn from *fp_jcc_2r_387 using
X87MODEF mode iterator.
(*jcc{,u}_i387 splitters): Macroize splitters using
X87MODEF mode iterator.
(*jcc__i387): Macroize insn
from *fp_jcc_4__387 using X87MODEF mode iterator.
(*jcc__r_i387): New.
(*jcc__i387 splitters): Macroize
splitters using X87MODEF and SWI24 mode iterators.

Tested on x86_64-linux-gnu {,-m32}, committed to mainline SVN.

This is the last patch of my i386.md cleanups.

Uros.
Index: config/i386/i386.md
===
--- config/i386/i386.md (revision 193731)
+++ config/i386/i386.md (working copy)
@@ -10948,89 +10948,110 @@
 ;; Define combination compare-and-branch fp compare instructions to help
 ;; combine.
 
-(define_insn "*fp_jcc_1_387"
+(define_insn "*jcc_0_i387"
   [(set (pc)
-   (if_then_else (match_operator 0 "ix86_fp_comparison_operator"
-   [(match_operand 1 "register_operand" "f")
-(match_operand 2 "nonimmediate_operand" "fm")])
+   (if_then_else (match_operator:CCFP 0 "ix86_fp_comparison_operator"
+   [(match_operand:X87MODEF 1 "register_operand" "f")
+(match_operand:X87MODEF 2 "const0_operand")])
  (label_ref (match_operand 3))
  (pc)))
(clobber (reg:CCFP FPSR_REG))
(clobber (reg:CCFP FLAGS_REG))
(clobber (match_scratch:HI 4 "=a"))]
-  "TARGET_80387
-   && (GET_MODE (operands[1]) == SFmode || GET_MODE (operands[1]) == DFmode)
-   && GET_MODE (operands[1]) == GET_MODE (operands[2])
-   && SELECT_CC_MODE (GET_CODE (operands[0]),
- operands[1], operands[2]) == CCFPmode
-   && !TARGET_CMOVE"
+  "TARGET_80387 && !TARGET_CMOVE"
   "#")
 
-(define_insn "*fp_jcc_1r_387"
+(define_insn "*jcc_0_r_i387"
   [(set (pc)
-   (if_then_else (match_operator 0 "ix86_fp_comparison_operator"
-   [(match_operand 1 "register_operand" "f")
-(match_operand 2 "nonimmediate_operand" "fm")])
+   (if_then_else (match_operator:CCFP 0 "ix86_fp_comparison_operator"
+   [(match_operand:X87MODEF 1 "register_operand" "f")
+(match_operand:X87MODEF 2 "const0_operand")])
  (pc)
  (label_ref (match_operand 3
(clobber (reg:CCFP FPSR_REG))
(clobber (reg:CCFP FLAGS_REG))
(clobber (match_scratch:HI 4 "=a"))]
-  "TARGET_80387
-   && (GET_MODE (operands[1]) == SFmode || GET_MODE (operands[1]) == DFmode)
-   && GET_MODE (operands[1]) == GET_MODE (operands[2])
-   && SELECT_CC_MODE (GET_CODE (operands[0]),
- operands[1], operands[2]) == CCFPmode
-   && !TARGET_CMOVE"
+  "TARGET_80387 && !TARGET_CMOVE"
   "#")
 
-(define_insn "*fp_jcc_2_387"
+(define_insn "*jccxf_i387"
   [(set (pc)
-   (if_then_else (match_operator 0 "ix86_fp_comparison_operator"
-   [(match_operand 1 "register_operand" "f")
-(match_operand 2 "register_operand" "f")])
+   (if_then_else (match_operator:CCFP 0 "ix86_fp_comparison_operator"
+   [(match_operand:XF 1 "register_operand" "f")
+(match_operand:XF 2 "register_operand" "f")])
  (label_ref (match_operand 3))
  (pc)))
(clobber (reg:CCFP FPSR_REG))
(clobber (reg:CCFP FLAGS_REG))
(clobber (match_scratch:HI 4 "=a"))]
-  "X87_FLOAT_MODE_P (GET_MODE (operands[1]))
-   && GET_MODE (operands[1]) == GET_MODE (operands[2])
-   && !TARGET_CMOVE"
+  "TARGET_80387 && !TARGET_CMOVE"
   "#")
 
-(define_insn "*fp_jcc_2r_387"
+(define_insn "*jccxf_r_i387"
   [(set (pc)
-   (if_then_else (match_operator 0 "ix86_fp_comparison_operator"
-   [(match_operand 1 "register_operand" "f")
-(match_operand 2 "register_operand" "f")])
+   (if_then_else (match_operator:CCFP 0 "ix86_fp_comparison_operator"
+   [(match_operand:XF 1 "register_operand" "f")
+(match_operand:XF 2 "register_operand" "f")])
  (pc)
  (label_ref (match_operand 3
(clobber (reg:CCFP FPSR_REG))
(clobber (reg:CCFP FLAGS_REG))
(clobber (match_scratch:HI 4 "=a"))]
-  "X87_FLOAT_MODE_P (GET_MODE (operands[1]))
-   && GET_MODE (operands[1]) == GET_MODE (operands[2])
-   && !TAR

[PATCH, doc]: Fix md.texi warning

2012-11-22 Thread Uros Bizjak
Hello!

Attached patch fixes following md.texi warning during build process:

../../gcc-svn/trunk/gcc/doc//md.texi:8931: warning: `.' or `,' must
follow @xref, not `)'.
../../gcc-svn/trunk/gcc/doc//md.texi:8931: warning: for
cross-references in parentheses, use @pxref.

2012-11-22  Uros Bizjak  

* doc/md.texi (RTL Templates Transformation): Use @pxref for
cross-reference in parentheses.

Bootstrapped on x86_64-linux-gnu, committed to mainline SVN as obvious.

Uros.

Index: doc/md.texi
===
--- doc/md.texi (revision 193728)
+++ doc/md.texi (working copy)
@@ -8931,7 +8931,7 @@ output-template.
 template.

 @code{define_subst} mechanism is tightly coupled with the notion of the
-subst attribute (@xref{Subst Iterators}).  The use of
+subst attribute (@pxref{Subst Iterators}).  The use of
 @code{define_subst} is triggered by a reference to a subst attribute in
 the transforming RTL template.  This reference initiates duplication of
 the source RTL template and substitution of the attributes with their


Re: [tsan] ThreadSanitizer instrumentation part

2012-11-22 Thread Wei Mi
Thanks, Fixed.

Wei.

On Wed, Nov 21, 2012 at 11:48 PM, Dmitry Vyukov  wrote:
> On Thu, Nov 22, 2012 at 11:45 AM, Xinliang David Li 
> wrote:
>>
>> On Wed, Nov 21, 2012 at 11:35 PM, Dmitry Vyukov 
>> wrote:
>> > What percent of the memory accesses the following can skip?
>> >
>> > I just don't know what exactly they mean. ADDR_EXPR/COMPONENT_REF look
>> > like
>> > it can skip a lot.
>> >
>>
>> It does not skip a lot.
>>
>> >
>> > +  /* TODO: handle other cases
>> > + (FIELD_DECL, ARRAY_RANGE_REF, TARGET_MEM_REF, ADDR_EXPR).  */
>>
>> The comment is not correct.  The analysis should not care about
>> FIELD_DECL (covered by COMPONENT_REF), nor ADDR_EXPR.  Due to the pass
>> ordering, target mem-ref is not seen either.
>
>
>
>
> Wei, please update the comment that only ARRAY_RANGE_REF is not handled.
>
>
>> > +  if (tcode != ARRAY_REF
>> > +  && tcode != VAR_DECL
>> > +  && tcode != COMPONENT_REF
>> > +  && tcode != INDIRECT_REF
>> > +  && tcode != MEM_REF)
>> > +return false;
>> >
>>
>> The listed cases are handled.
>>
>> David
>>
>> >
>> >
>> > On Thu, Nov 22, 2012 at 11:29 AM, Dmitry Vyukov 
>> > wrote:
>> >>
>> >> +static bool
>> >> +tsan_gate (void)
>> >> +{
>> >> +  return flag_tsan != 0
>> >> + && builtin_decl_implicit_p (BUILT_IN_TSAN_INIT);
>> >>
>> >>
>> >> What does it mean? Why builtin_decl_implicit_p (BUILT_IN_TSAN_INIT)?
>> >>
>> >> +}
>> >>
>> >>
>> >>
>> >> On Thu, Nov 22, 2012 at 11:22 AM, Wei Mi  wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>> I update the tsan patch against trunk, and create libtsan patch.
>> >>> Please see if it is ok.
>> >>>
>> >>> gcc/ChangeLog:
>> >>> 2012-11-22  Dmitry Vyukov  
>> >>> Wei Mi  
>> >>>
>> >>> * builtins.def (DEF_SANITIZER_BUILTIN): Define tsan builtins.
>> >>> * sanitizer.def: Ditto.
>> >>> * Makefile.in (tsan.o): Add tsan.o target.
>> >>> (BUILTINS_DEF): Add sanitizer.def.
>> >>> * passes.c (init_optimization_passes): Add tsan passes.
>> >>> * tree-pass.h (register_pass_info): Ditto.
>> >>> * toplev.c (compile_file): Ditto.
>> >>> * doc/invoke.texi: Document tsan related options.
>> >>> * gcc.c (LINK_COMMAND_SPEC): Add LIBTSAN_SPEC in link command
>> >>> if -fsanitize=thread.
>> >>> * tsan.c: New file about tsan.
>> >>> * tsan.h: Ditto.
>> >>> * common.opt: Add -fsanitize=thread.
>> >>>
>> >>> libsanitizer/ChangeLog:
>> >>> 2012-11-22  Wei Mi  
>> >>>
>> >>> * tsan: New directory. Import tsan runtime from llvm.
>> >>> * configure.ac: Add 64 bits tsan build.
>> >>> * Makefile.am: Likewise.
>> >>> * configure: Regenerated.
>> >>> * Makefile.in: Likewise.
>> >>>
>> >>> Thanks,
>> >>> Wei.
>> >>>
>> >>> On Sun, Nov 18, 2012 at 10:52 AM, Konstantin Serebryany
>> >>>  wrote:
>> >>> > Just a comment about tsan.
>> >>> > Today, tsan works *only* on x86_64 linux (no 32-bits, no non-linux).
>> >>> > Other 64-bit platforms may be doable, but not as easy as for asan.
>> >>> > Non-linux is harder than non-x86_64 (need to support tons of libc
>> >>> > interceptors).
>> >>> > 32-bit platforms are very hard to port to, I would not bother for
>> >>> > now.
>> >>> > (this probably includes x32, which has cheap atomic 64-bit
>> >>> > loads/stores, but has too small address space for tsan)
>> >>> >
>> >>> > Conclusion: when committing tsan code, please make sure it is enable
>> >>> > only on x86_64
>> >>> >
>> >>> > --kcc
>> >>> >
>> >>> > On Sat, Nov 17, 2012 at 3:13 AM, Wei Mi  wrote:
>> >>> >> Hi,
>> >>> >>
>> >>> >> Is it ok for the trunk?
>> >>> >>
>> >>> >> Thanks,
>> >>> >> Wei.
>> >>> >>
>> >>> >> On Tue, Nov 13, 2012 at 5:06 PM, Wei Mi  wrote:
>> >>> >>> Thanks for catching this. I update the patch.
>> >>> >>>
>> >>> >>> Regards,
>> >>> >>> Wei.
>> >>> >>>
>> >>> >>> On Tue, Nov 13, 2012 at 4:54 PM, Richard Henderson
>> >>> >>> 
>> >>> >>> wrote:
>> >>>  On 11/13/2012 04:08 PM, Wei Mi wrote:
>> >>> > +extern void tsan_finish_file (void);
>> >>> > +
>> >>> > +#endif /* TREE_TSAN */
>> >>> > +/* ThreadSanitizer, a data race detector.
>> >>> > +   Copyright (C) 2011 Free Software Foundation, Inc.
>> >>> > +   Contributed by Dmitry Vyukov 
>> >>> 
>> >>>  Careful, you've got double applied patches there.
>> >>> 
>> >>> 
>> >>>  r~
>> >>
>> >>
>> >
>
>


Re: [tsan] ThreadSanitizer instrumentation part

2012-11-22 Thread Wei Mi
Thanks. I checked in the code.
Committed revision 193736.
Committed revision 193737.

Wei.

On Thu, Nov 22, 2012 at 1:54 AM, Jakub Jelinek  wrote:
> On Wed, Nov 21, 2012 at 11:22:51PM -0800, Wei Mi wrote:
>> I update the tsan patch against trunk, and create libtsan patch.
>> Please see if it is ok.
>>
>> gcc/ChangeLog:
>> 2012-11-22  Dmitry Vyukov  
>> Wei Mi  
>>
>> * builtins.def (DEF_SANITIZER_BUILTIN): Define tsan builtins.
>> * sanitizer.def: Ditto.
>> * Makefile.in (tsan.o): Add tsan.o target.
>> (BUILTINS_DEF): Add sanitizer.def.
>> * passes.c (init_optimization_passes): Add tsan passes.
>> * tree-pass.h (register_pass_info): Ditto.
>> * toplev.c (compile_file): Ditto.
>> * doc/invoke.texi: Document tsan related options.
>> * gcc.c (LINK_COMMAND_SPEC): Add LIBTSAN_SPEC in link command
>> if -fsanitize=thread.
>> * tsan.c: New file about tsan.
>> * tsan.h: Ditto.
>> * common.opt: Add -fsanitize=thread.
>>
>> libsanitizer/ChangeLog:
>> 2012-11-22  Wei Mi  
>>
>> * tsan: New directory. Import tsan runtime from llvm.
>> * configure.ac: Add 64 bits tsan build.
>> * Makefile.am: Likewise.
>> * configure: Regenerated.
>> * Makefile.in: Likewise.
>
> Ok, thanks.  The comments can be fixed up incrementally.
>
> Jakub


Re: [libsanitizer] a script to help merging asan from upstream

2012-11-22 Thread Xinliang David Li
Looks fine to me.

David

On Thu, Nov 22, 2012 at 11:06 AM, Konstantin Serebryany
 wrote:
> Anything else?
>
> On Thu, Nov 22, 2012 at 6:42 AM, Konstantin Serebryany
>  wrote:
>> Added to README.gcc:
>> The merges from upstream should be done with the aid of the merge.sh script;
>> it will also update the file MERGE to contain the upstream revision
>> we merged with.
>>
>>
>> On Wed, Nov 21, 2012 at 11:03 PM, Xinliang David Li  
>> wrote:
>>> How about also documenting this in README.gcc?
>>>
>>> David
>>>
>>> On Wed, Nov 21, 2012 at 10:56 AM, Kostya Serebryany  wrote:
 Done both.


 +fatal() {
 +  echo "$1"
 +  exit 1;
 +}
 +
 +pwd | grep 'libsanitizer$' || \
 +  fatal "Run this script from libsanitizer dir"


 +rm -rf upstream





 On Wed, Nov 21, 2012 at 10:49 PM, Xinliang David Li  
 wrote:
> Suggestions:
>
> 1) make sure current local dir is libsanitizer -- exit if it is not
> 2) clean up the upstream directory after the merge is done.
>
> David
>
>
> On Wed, Nov 21, 2012 at 10:25 AM, Kostya Serebryany  
> wrote:
>> Hi,
>>
>> A dummy script to help merging asan from upstream.
>> Not 100% complete, but should be enough to complete the current merge.
>>
>> You suggestions on how to improve it (or how to do w/o it) are welcome,
>> but I really wish to do the first merge tomorrow to unblock other folks.
>>
>> Thanks,
>> --kcc


Ping / update: Re: RFA: hookize ADJUST_INSN_LENGTH

2012-11-22 Thread Joern Rennecke

This uses the same interface as my previous patch:
http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00473.html ,
but I refined the algorithm for the get_insn_variants
mechanism to work properly with the reworked ARC port -
http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01891.html -
the only user so far, and added some documentation.

Bootstrapped in r193731 on i686-pc-linux-gnu .

As mentioned before, I can adjust the config part of the previous
hookization approach to convert the existing ADJUST_INSN_LENGTH targets
to use TARGET_ADJUST_INSN_LNEGTH if that is desired.
2012-11-13  Joern Rennecke  

* doc/tm.texi.in (@hook TARGET_ADJUST_INSN_LENGTH): Add.
(@hook TARGET_INSN_LENGTH_PARAMETERS): Add.
* doc/tm.texi: Regenerate.
* final.c (get_attr_length_1): Assert HAVE_ATTR_length.
Use targetm.adjust_insn_length instead of ADJUST_INSN_LENGTH.
(shorten_branches_context_t): New typedef.
(adjust_length): New function.
(shorten_branches): Use adjust_length instead of ADJUST_INSN_LENGTH.
Try to satidfy alignment by using variable length instructions.
* target.def (adjust_insn_length, insn_length_parameters): New hooks.
* target.h (insn_length_variant_t, insn_length_parameters_t): New types.
* targhooks.c (default_adjust_insn_length): New function.
* targhooks.h (default_adjust_insn_length): Declare.
* genattrtab.c (make_length_attrs): Generate an insn_current_length
function that is also valid for prima facie invariant length
instructions.

Index: doc/tm.texi
===
--- doc/tm.texi (revision 2691)
+++ doc/tm.texi (working copy)
@@ -11365,3 +11365,15 @@ @deftypefn {Target Hook} {unsigned HOST_
 @deftypevr {Target Hook} {unsigned char} TARGET_ATOMIC_TEST_AND_SET_TRUEVAL
 This value should be set if the result written by @code{atomic_test_and_set} 
is not exactly 1, i.e. the @code{bool} @code{true}.
 @end deftypevr
+
+@deftypefn {Target Hook} int TARGET_ADJUST_INSN_LENGTH (rtx @var{insn}, int 
@var{length}, bool @var{in_delay_sequence})
+Return an adjusted length for @var{insn}.  @var{length} is the value that has 
been calculated using the @code{length} instruction attribute.  
@var{in_delay_sequence} if @var{insn} forms part of a delay sequence.  The 
default implementation uses @code{ADJUST_INSN_LENGTH}, if defined.
+@end deftypefn
+
+@deftypefn {Target Hook} void TARGET_INSN_LENGTH_PARAMETERS 
(insn_length_parameters_t *@var{insn_length_parameters})
+Fill in values used for branch shortening.  The type  
@code{insn_length_parameters_t} is defined in @file{target-def.h}.  The main 
feature is the @code{get_variants} function. @smallexample
+int (*get_variants) (rtx insn, int length, bool sequence_p, bool target_p,
+insn_length_variant_t *variants)
+@end smallexample
+ For instructions where the ordinary monotonic branch shortening is 
insufficeint to describe the alternatives, e.g. because there is alignemnt 
involved, get_variants can provide two or more variants for the instruction.  
The return value is the number of variants filled in, which must never exceed 
the number filled in by @code{insn_length_parameters} in the @var{max_variants} 
field.  The set of variants for any given instruction filled in should not vary 
during branch shortening, but rather unavailable variants should be flagged 
with a @samp{false} @var{enabled} field.  This allows @code{shorten_branches} 
to keep track of varaints that have been ever disabled in a previous iteration 
and keep them disabled, so as to avoid infinite looping inside 
@code{shorten_branches}.  The @var{length} parameter provides the length 
calculated previously from attributes.  @var{sequence_p} indicates if the 
instruction presented is inside a @code{SEQUENCE}.  Note, if you make 
@code{get_variants} provide variants for an entire @code{SEQUENCE}, the 
@code{SEQUENCE} will henceforth be handled as a single entity for branch 
shortening.  @var{target_p} indicates if the instruction is considered the 
target of  a branch, function call, or function return.
+@end deftypefn
Index: doc/tm.texi.in
===
--- doc/tm.texi.in  (revision 2691)
+++ doc/tm.texi.in  (working copy)
@@ -11205,3 +11205,7 @@ @hook TARGET_MEMMODEL_CHECK
 @end deftypefn
 
 @hook TARGET_ATOMIC_TEST_AND_SET_TRUEVAL
+
+@hook TARGET_ADJUST_INSN_LENGTH
+
+@hook TARGET_INSN_LENGTH_PARAMETERS
Index: final.c
===
--- final.c (revision 2691)
+++ final.c (working copy)
@@ -82,6 +82,7 @@ Software Foundation; either version 3, o
 #include "cfgloop.h"
 #include "params.h"
 #include "tree-pretty-print.h" /* for dump_function_header */
+#include "sbitmap.h"
 
 #ifdef XCOFF_DEBUGGING_INFO
 #include "xcoffout.h"  /* Needed for external data
@@ -377,8 +378,7 @@ get_attr_

Re: [tsan] ThreadSanitizer instrumentation part

2012-11-22 Thread H.J. Lu
On Thu, Nov 22, 2012 at 2:08 PM, Wei Mi  wrote:
> Thanks. I checked in the code.
> Committed revision 193736.
> Committed revision 193737.
>
> Wei.
>
> On Thu, Nov 22, 2012 at 1:54 AM, Jakub Jelinek  wrote:
>> On Wed, Nov 21, 2012 at 11:22:51PM -0800, Wei Mi wrote:
>>> I update the tsan patch against trunk, and create libtsan patch.
>>> Please see if it is ok.
>>>
>>> gcc/ChangeLog:
>>> 2012-11-22  Dmitry Vyukov  
>>> Wei Mi  
>>>
>>> * builtins.def (DEF_SANITIZER_BUILTIN): Define tsan builtins.
>>> * sanitizer.def: Ditto.
>>> * Makefile.in (tsan.o): Add tsan.o target.
>>> (BUILTINS_DEF): Add sanitizer.def.
>>> * passes.c (init_optimization_passes): Add tsan passes.
>>> * tree-pass.h (register_pass_info): Ditto.
>>> * toplev.c (compile_file): Ditto.
>>> * doc/invoke.texi: Document tsan related options.
>>> * gcc.c (LINK_COMMAND_SPEC): Add LIBTSAN_SPEC in link command
>>> if -fsanitize=thread.
>>> * tsan.c: New file about tsan.
>>> * tsan.h: Ditto.
>>> * common.opt: Add -fsanitize=thread.
>>>
>>> libsanitizer/ChangeLog:
>>> 2012-11-22  Wei Mi  
>>>
>>> * tsan: New directory. Import tsan runtime from llvm.
>>> * configure.ac: Add 64 bits tsan build.
>>> * Makefile.am: Likewise.
>>> * configure: Regenerated.
>>> * Makefile.in: Likewise.
>>
>> Ok, thanks.  The comments can be fixed up incrementally.
>>
>> Jakub

It failed to bootstrap on Linux/i686:

http://gcc.gnu.org/ml/gcc-regression/2012-11/msg00409.html

It tried to build tsan on Linux/i686.

-- 
H.J.


Re: [tsan] ThreadSanitizer instrumentation part

2012-11-22 Thread Jakub Jelinek
On Thu, Nov 22, 2012 at 03:04:23PM -0800, H.J. Lu wrote:
> It failed to bootstrap on Linux/i686:
> 
> http://gcc.gnu.org/ml/gcc-regression/2012-11/msg00409.html
> 
> It tried to build tsan on Linux/i686.

I'd hope http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01866.html ought to
fix that.

Jakub


[PATCH] PR testsuite/55440: Filter out -fsanitize=address from PLUGINCFLAGS

2012-11-22 Thread H.J. Lu
Hi,

When GCC is compiled with -fsanitize=address, we passs
-fsanitize=address to PLUGINCFLAGS.  We either can't find libasan at
build-time or run-time.  This patch filter-outs -fsanitize=address
from PLUGINCFLAGS.  OK to install?

Thanks.


H.J.
---
2012-11-22  H.J. Lu  
 
PR testsuite/55440
* Makefile.in (PLUGINCFLAGS): Filter out -fsanitize=address.

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 88b29ea..154a0fb 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -329,7 +329,8 @@ enable_lto = @enable_lto@
 
 # Compiler and flags needed for plugin support
 PLUGINCC = @CXX@
-PLUGINCFLAGS = @CXXFLAGS@
+# Filter out -fsanitize=address
+PLUGINCFLAGS = $(filter-out -fsanitize=address,@CXXFLAGS@)
 
 # Libs and linker options needed for plugin support
 PLUGINLIBS = @pluginlibs@
-- 
1.7.11.7



Re: [tsan] ThreadSanitizer instrumentation part

2012-11-22 Thread Jack Howarth
On Thu, Nov 22, 2012 at 02:08:07PM -0800, Wei Mi wrote:
> Thanks. I checked in the code.
> Committed revision 193736.
> Committed revision 193737.
> 
> Wei.

Wei,
   Unlike libasan, we seem to have issues building libtsan on darwin using the 
currently proposed
patch...

http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01817.html

The build fails at...

libtool: compile:  /sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/./gcc/g++ 
-B/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/./gcc/ -nostdinc++ 
-nostdinc++ 
-I/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/libstdc++-v3/include/x86_64-apple-darwin12.2.0
 
-I/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/libstdc++-v3/include
 -I/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121122/libstdc++-v3/libsupc++ 
-I/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121122/libstdc++-v3/include/backward
 
-I/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121122/libstdc++-v3/testsuite/util
 
-L/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/libstdc++-v3/src
 
-L/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/libstdc++-v3/src/.libs
 -B/sw/lib/gcc4.8/x86_64-apple-darwin12.2.0/bin/ 
-B/sw/lib/gcc4.8/x86_64-apple-darwin12.2.0/lib/ -isystem 
/sw/lib/gcc4.8/x86_64-apple-darwin12.2.0/include -isystem 
/sw/lib/gcc4.8/x86_64-apple-darwin12.2.0/sys-include -D_GNU_SOURCE -D_DEBUG 
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I. 
-I../../../../gcc-4.8-20121122/libsanitizer/tsan -I 
../../../../gcc-4.8-20121122/libsanitizer -I 
../../../../gcc-4.8-20121122/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 -MT 
tsan_interceptors.lo -MD -MP -MF .deps/tsan_interceptors.Tpo -c 
../../../../gcc-4.8-20121122/libsanitizer/tsan/tsan_interceptors.cc  
-fno-common -DPIC -o .libs/tsan_interceptors.o
../../../../gcc-4.8-20121122/libsanitizer/tsan/tsan_interceptors.cc: In 
function ‘unsigned int wrap_sleep(unsigned int)’:
../../../../gcc-4.8-20121122/libsanitizer/tsan/tsan_interceptors.cc:164:27: 
error: ‘sleep’ was not declared in this scope
   unsigned res = sleep(sec);
   ^
../../../../gcc-4.8-20121122/libsanitizer/tsan/tsan_interceptors.cc: In 
function ‘int wrap_usleep(long_t)’:
../../../../gcc-4.8-20121122/libsanitizer/tsan/tsan_interceptors.cc:171:24: 
error: ‘usleep’ was not declared in this scope
   int res = usleep(usec);
^
../../../../gcc-4.8-20121122/libsanitizer/tsan/tsan_interceptors.cc: In 
function ‘int wrap_nanosleep(void*, void*)’:
../../../../gcc-4.8-20121122/libsanitizer/tsan/tsan_interceptors.cc:178:31: 
error: ‘nanosleep’ was not declared in this scope
   int res = nanosleep(req, rem);
   ^
../../../../gcc-4.8-20121122/libsanitizer/tsan/tsan_interceptors.cc: In 
function ‘void (* wrap_signal(int, sighandler_t))(int)’:
../../../../gcc-4.8-20121122/libsanitizer/tsan/tsan_interceptors.cc:1270:38: 
error: ‘sigaction’ was not declared in this scope
   int res = sigaction(sig, &act, &old);
  ^
In file included from 
../../../../gcc-4.8-20121122/libsanitizer/interception/interception.h:184:0,
 from 
../../../../gcc-4.8-20121122/libsanitizer/tsan/tsan_interceptors.h:15,
 from 
../../../../gcc-4.8-20121122/libsanitizer/tsan/tsan_interceptors.cc:16:
../../../../gcc-4.8-20121122/libsanitizer/tsan/tsan_interceptors.cc: In 
function ‘void __tsan::InitializeInterceptors()’:
../../../../gcc-4.8-20121122/libsanitizer/tsan/tsan_interceptors.cc:1377:18: 
error: ‘longjmp’ was not declared in this scope
   TSAN_INTERCEPT(longjmp);
  ^
../../../../gcc-4.8-20121122/libsanitizer/interception/interception_mac.h:41:35:
 note: in definition of macro ‘OVERRIDE_FUNCTION_MAC’
   (::__interception::uptr)old_func, \
   ^
../../../../gcc-4.8-20121122/libsanitizer/interception/interception.h:187:35: 
note: in expansion of macro ‘INTERCEPT_FUNCTION_MAC’
 # define INTERCEPT_FUNCTION(func) INTERCEPT_FUNCTION_MAC(func)
   ^
../../../../gcc-4.8-20121122/libsanitizer/tsan/tsan_interceptors.h:48:30: note: 
in expansion of macro ‘INTERCEPT_FUNCTION’
 #define TSAN_INTERCEPT(func) INTERCEPT_FUNCTION(func)
  ^
etc. Current llvm svn seems to be broken elsewhere (in compiler-rt/lib/ubsan) 
so I can't test tsan support there as well.
  Jack

> 
> On Thu, Nov 22, 2012 at 1:54 AM, Jakub Jelinek  wrote:
> > On Wed, Nov 21, 2012 at 11:22:51PM -0800, Wei Mi wrote:
> >> I update the tsan patch against trunk, and create libtsan patch.
> >> Please see if it is ok.
> >>
> >

Re: [tsan] libsanitizer tweaks

2012-11-22 Thread Diego Novillo
On Thu, Nov 22, 2012 at 8:20 AM, Jakub Jelinek  wrote:
> On Thu, Nov 22, 2012 at 10:54:00AM +0100, Jakub Jelinek wrote:
>> Ok, thanks.  The comments can be fixed up incrementally.
>
> I had closer look at the libsanitizer/tsan configury, and I think I'd prefer
> the configure.tgt script to say if tsan should be built or not.
> Furthermore, GCC doesn't support -Wno-c99-extensions flag for C++, that is a
> clang-ism.
> Ok for trunk (after the tsan patches are committed, on top of them)?
>
> 2012-11-22  Jakub Jelinek  
>
> * tsan/Makefile.am (AM_CXXFLAGS): Remove -Wno-variadic-macros.
> * Makefile.am (SUBDIRS): Guard tsan addition with TSAN_SUPPORTED
> automake conditional instead of !MULTISUBDIR32.
> * configure.tgt: Set TSAN_SUPPORTED=yes for x86_64/i686-linux
> for 64-bit multilib.
> * configure.ac: Check for void * size, source in configure.tgt,
> define TSAN_SUPPORTED conditional instead of MULTILIBDIR32.
> * configure: Regenerated.
> * Makefile.in: Regenerated.
> * tsan/Makefile.in: Regenerated.

This is fine if bootstraps succeeds on i686.


Diego.


Re: [tsan] ThreadSanitizer instrumentation part

2012-11-22 Thread Wei Mi
Hi Jack,

Koysta mentioned in a previous mail that tsan is only supported on
x86_64 linux (no 32-bits, no non-linux) for now. tsan building should
be disabled on the platforms other than x86-64-linux. Thanks to Jakub
who will provide another patch including this fix soon.

Thanks,
Wei.

On Thu, Nov 22, 2012 at 3:18 PM, Jack Howarth  wrote:
> On Thu, Nov 22, 2012 at 02:08:07PM -0800, Wei Mi wrote:
>> Thanks. I checked in the code.
>> Committed revision 193736.
>> Committed revision 193737.
>>
>> Wei.
>
> Wei,
>Unlike libasan, we seem to have issues building libtsan on darwin using 
> the currently proposed
> patch...
>
> http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01817.html
>
> The build fails at...
>
> libtool: compile:  
> /sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/./gcc/g++ 
> -B/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/./gcc/ -nostdinc++ 
> -nostdinc++ 
> -I/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/libstdc++-v3/include/x86_64-apple-darwin12.2.0
>  
> -I/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/libstdc++-v3/include
>  
> -I/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121122/libstdc++-v3/libsupc++ 
> -I/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121122/libstdc++-v3/include/backward
>  
> -I/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121122/libstdc++-v3/testsuite/util
>  
> -L/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/libstdc++-v3/src
>  
> -L/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/libstdc++-v3/src/.libs
>  -B/sw/lib/gcc4.8/x86_64-apple-darwin12.2.0/bin/ 
> -B/sw/lib/gcc4.8/x86_64-apple-darwin12.2.0/lib/ -isystem 
> /sw/lib/gcc4.8/x86_64-apple-darwin12.2.0/include -isystem 
> /sw/lib/gcc4.8/x86_64-apple-darwin12.2.0/sys-include -D_GNU_SOURCE -D_DEBUG 
> -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I. 
> -I../../../../gcc-4.8-20121122/libsanitizer/tsan -I 
> ../../../../gcc-4.8-20121122/libsanitizer -I 
> ../../../../gcc-4.8-20121122/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 -MT 
> tsan_interceptors.lo -MD -MP -MF .deps/tsan_interceptors.Tpo -c 
> ../../../../gcc-4.8-20121122/libsanitizer/tsan/tsan_interceptors.cc  
> -fno-common -DPIC -o .libs/tsan_interceptors.o
> ../../../../gcc-4.8-20121122/libsanitizer/tsan/tsan_interceptors.cc: In 
> function ‘unsigned int wrap_sleep(unsigned int)’:
> ../../../../gcc-4.8-20121122/libsanitizer/tsan/tsan_interceptors.cc:164:27: 
> error: ‘sleep’ was not declared in this scope
>unsigned res = sleep(sec);
>    ^
> ../../../../gcc-4.8-20121122/libsanitizer/tsan/tsan_interceptors.cc: In 
> function ‘int wrap_usleep(long_t)’:
> ../../../../gcc-4.8-20121122/libsanitizer/tsan/tsan_interceptors.cc:171:24: 
> error: ‘usleep’ was not declared in this scope
>int res = usleep(usec);
> ^
> ../../../../gcc-4.8-20121122/libsanitizer/tsan/tsan_interceptors.cc: In 
> function ‘int wrap_nanosleep(void*, void*)’:
> ../../../../gcc-4.8-20121122/libsanitizer/tsan/tsan_interceptors.cc:178:31: 
> error: ‘nanosleep’ was not declared in this scope
>int res = nanosleep(req, rem);
>^
> ../../../../gcc-4.8-20121122/libsanitizer/tsan/tsan_interceptors.cc: In 
> function ‘void (* wrap_signal(int, sighandler_t))(int)’:
> ../../../../gcc-4.8-20121122/libsanitizer/tsan/tsan_interceptors.cc:1270:38: 
> error: ‘sigaction’ was not declared in this scope
>int res = sigaction(sig, &act, &old);
>   ^
> In file included from 
> ../../../../gcc-4.8-20121122/libsanitizer/interception/interception.h:184:0,
>  from 
> ../../../../gcc-4.8-20121122/libsanitizer/tsan/tsan_interceptors.h:15,
>      from 
> ../../../../gcc-4.8-20121122/libsanitizer/tsan/tsan_interceptors.cc:16:
> ../../../../gcc-4.8-20121122/libsanitizer/tsan/tsan_interceptors.cc: In 
> function ‘void __tsan::InitializeInterceptors()’:
> ../../../../gcc-4.8-20121122/libsanitizer/tsan/tsan_interceptors.cc:1377:18: 
> error: ‘longjmp’ was not declared in this scope
>TSAN_INTERCEPT(longjmp);
>   ^
> ../../../../gcc-4.8-20121122/libsanitizer/interception/interception_mac.h:41:35:
>  note: in definition of macro ‘OVERRIDE_FUNCTION_MAC’
>(::__interception::uptr)old_func, \
>^
> ../../../../gcc-4.8-20121122/libsanitizer/interception/interception.h:187:35: 
> note: in 

patch to fix PR55430

2012-11-22 Thread Vladimir Makarov

  The following patch fixes

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55430

  The patch was successfully bootstrapped and tested on x86/x86-64.

  Committed as rev. 193742.

2012-11-22  Vladimir Makarov  

PR middle-end/55430
* lra.c: Move #include "hard-reg-set.h" before #include "rtl.h".
(new_insn_reg): Update biggest_mode.
(collect_non_operand_hard_regs): Check eliminable regs too.
(initialize_lra_reg_info_element): Initialize biggest_mode.
(add_regs_to_insn_regno_info): Ignore non-allocatable
non-eliminable hard regs.
(lra.c): Move setting lra_no_alloc_regs before
init_insn_recog_data.
* lra-constraints.c (simplify_operand_subreg): Add a comment.
(lra_constraints): Ignore equivalent memory of
regs occuring in paradoxical subregs.
* lra-lives.c (lra_create_live_ranges): Add a comment.


Index: lra.c
===
--- lra.c   (revision 193702)
+++ lra.c   (working copy)
@@ -97,6 +97,7 @@ along with GCC; see the file COPYING3.I
 #include "system.h"
 #include "coretypes.h"
 #include "tm.h"
+#include "hard-reg-set.h"
 #include "rtl.h"
 #include "tm_p.h"
 #include "regs.h"
@@ -105,7 +106,6 @@ along with GCC; see the file COPYING3.  I
 #include "recog.h"
 #include "output.h"
 #include "addresses.h"
-#include "hard-reg-set.h"
 #include "flags.h"
 #include "function.h"
 #include "expr.h"
@@ -461,6 +461,8 @@ new_insn_reg (int regno, enum op_type ty
   ir = (struct lra_insn_reg *) pool_alloc (insn_reg_pool);
   ir->type = type;
   ir->biggest_mode = mode;
+  if (GET_MODE_SIZE (mode) > GET_MODE_SIZE (lra_reg_info[regno].biggest_mode))
+lra_reg_info[regno].biggest_mode = mode;
   ir->subreg_p = subreg_p;
   ir->early_clobber = early_clobber;
   ir->regno = regno;
@@ -916,7 +918,8 @@ collect_non_operand_hard_regs (rtx *x, l
   for (last = regno + hard_regno_nregs[regno][mode];
   regno < last;
   regno++)
-   if (! TEST_HARD_REG_BIT (lra_no_alloc_regs, regno))
+   if (! TEST_HARD_REG_BIT (lra_no_alloc_regs, regno)
+   || TEST_HARD_REG_BIT (eliminable_regset, regno))
  {
for (curr = list; curr != NULL; curr = curr->next)
  if (curr->regno == regno && curr->subreg_p == subreg_p
@@ -1384,6 +1387,7 @@ initialize_lra_reg_info_element (int i)
   lra_reg_info[i].preferred_hard_regno2 = -1;
   lra_reg_info[i].preferred_hard_regno_profit1 = 0;
   lra_reg_info[i].preferred_hard_regno_profit2 = 0;
+  lra_reg_info[i].biggest_mode = VOIDmode;
   lra_reg_info[i].live_ranges = NULL;
   lra_reg_info[i].nrefs = lra_reg_info[i].freq = 0;
   lra_reg_info[i].last_reload = 0;
@@ -1530,6 +1534,10 @@ add_regs_to_insn_regno_info (lra_insn_re
   if (REG_P (x))
 {
   regno = REGNO (x);
+  if (regno < FIRST_PSEUDO_REGISTER
+ && TEST_HARD_REG_BIT (lra_no_alloc_regs, regno)
+ && ! TEST_HARD_REG_BIT (eliminable_regset, regno))
+   return;
   expand_reg_info ();
   if (bitmap_set_bit (&lra_reg_info[regno].insn_bitmap, uid))
{
@@ -2202,14 +2210,14 @@ lra (FILE *f)
 
   timevar_push (TV_LRA);
 
+  COPY_HARD_REG_SET (lra_no_alloc_regs, ira_no_alloc_regs);
+
   init_insn_recog_data ();
 
 #ifdef ENABLE_CHECKING
   check_rtl (false);
 #endif
 
-  COPY_HARD_REG_SET (lra_no_alloc_regs, ira_no_alloc_regs);
-
   lra_live_range_iter = lra_coalesce_iter = 0;
   lra_constraint_iter = lra_constraint_iter_after_spill = 0;
   lra_inheritance_iter = lra_undo_inheritance_iter = 0;
Index: lra-constraints.c
===
--- lra-constraints.c   (revision 193712)
+++ lra-constraints.c   (working copy)
@@ -1146,7 +1146,12 @@ simplify_operand_subreg (int nop, enum m
   reg = SUBREG_REG (operand);
   /* If we change address for paradoxical subreg of memory, the
  address might violate the necessary alignment or the access might
- be slow.  So take this into consideration. */
+ be slow.  So take this into consideration.  We should not worry
+ about access beyond allocated memory for paradoxical memory
+ subregs as we don't substitute such equiv memory (see processing
+ equivalences in function lra_constraints) and because for spilled
+ pseudos we allocate stack memory enough for the biggest
+ corresponding paradoxical subreg.  */
   if ((MEM_P (reg)
&& (! SLOW_UNALIGNED_ACCESS (mode, MEM_ALIGN (reg))
   || MEM_ALIGN (reg) >= GET_MODE_ALIGNMENT (mode)))
@@ -3363,7 +3368,12 @@ lra_constraints (bool first_p)
   && (set = single_set (insn)) != NULL_RTX
   && REG_P (SET_DEST (set))
   && (int) REGNO (SET_DEST (set)) == i)
-   && init_insn_rhs_dead_pseudo_p (i)))
+   && init_insn_rhs_dead_pseudo_p (i))
+   /* Prevent access beyond equivalent memory for
+   

Re: [libsanitizer] a script to help merging asan from upstream

2012-11-22 Thread Konstantin Serebryany
Done, thanks!
r193743.

On Fri, Nov 23, 2012 at 2:50 AM, Xinliang David Li  wrote:
> Looks fine to me.
>
> David
>
> On Thu, Nov 22, 2012 at 11:06 AM, Konstantin Serebryany
>  wrote:
>> Anything else?
>>
>> On Thu, Nov 22, 2012 at 6:42 AM, Konstantin Serebryany
>>  wrote:
>>> Added to README.gcc:
>>> The merges from upstream should be done with the aid of the merge.sh script;
>>> it will also update the file MERGE to contain the upstream revision
>>> we merged with.
>>>
>>>
>>> On Wed, Nov 21, 2012 at 11:03 PM, Xinliang David Li  
>>> wrote:
 How about also documenting this in README.gcc?

 David

 On Wed, Nov 21, 2012 at 10:56 AM, Kostya Serebryany  
 wrote:
> Done both.
>
>
> +fatal() {
> +  echo "$1"
> +  exit 1;
> +}
> +
> +pwd | grep 'libsanitizer$' || \
> +  fatal "Run this script from libsanitizer dir"
>
>
> +rm -rf upstream
>
>
>
>
>
> On Wed, Nov 21, 2012 at 10:49 PM, Xinliang David Li  
> wrote:
>> Suggestions:
>>
>> 1) make sure current local dir is libsanitizer -- exit if it is not
>> 2) clean up the upstream directory after the merge is done.
>>
>> David
>>
>>
>> On Wed, Nov 21, 2012 at 10:25 AM, Kostya Serebryany  
>> wrote:
>>> Hi,
>>>
>>> A dummy script to help merging asan from upstream.
>>> Not 100% complete, but should be enough to complete the current merge.
>>>
>>> You suggestions on how to improve it (or how to do w/o it) are welcome,
>>> but I really wish to do the first merge tomorrow to unblock other folks.
>>>
>>> Thanks,
>>> --kcc


[GCC ARM-Embedded-4_7]Back port r191457/r193687(prefer short-circuit on ARMv6m) from TRUNK

2012-11-22 Thread Bin Cheng
Hi,
I back ported r193687/r191457 from TRUNK to GCC ARM-Embedded-4_7 branch as
r193744/r193745.

Thanks

ChangeLog/r193687
Backport from mainline r193687
2012-11-21  Bin Cheng  

* config/arm/arm-cores.def (cortex-m0plus): Use v6m.
* config/arm/arm-protos.h (tune_params): Add
logical_op_non_short_circuit.
* config/arm/arm.c (arm_slowmul_tune, arm_fastmul_tune)
(arm_strongarm_tune, arm_xscale_tune, arm_9e_tune, arm_v6t2_tune)
(arm_cortex_tune, arm_cortex_a5_tune, arm_cortex_a9_tune)
(arm_cortex_v7m_tune, arm_cortex_v6m_tune, arm_fa726te_tune): Set
logical_op_non_short_circuit field.
* config/arm/arm.h (LOGICAL_OP_NON_SHORT_CIRCUIT): Define.

Backport from mainline r193687
2012-11-21  Bin Cheng  

* gcc.dg/tree-ssa/ssa-dom-thread-4.c: Skip on ARM Cortex-M0.
* gcc.dg/tree-ssa/vrp47.c: Ditto.

ChangeLog/r191457
Backport from mainline r191457
2012-09-19  Bin Cheng  

* fold-const.c (fold_truth_andor): Remove duplicated check on
BRANCH_COST.






Re: patch to fix PR55430

2012-11-22 Thread H.J. Lu
On Thu, Nov 22, 2012 at 5:29 PM, Vladimir Makarov  wrote:
>   The following patch fixes
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55430
>
>   The patch was successfully bootstrapped and tested on x86/x86-64.
>
>   Committed as rev. 193742.
>
> 2012-11-22  Vladimir Makarov  
>
> PR middle-end/55430
> * lra.c: Move #include "hard-reg-set.h" before #include "rtl.h".
> (new_insn_reg): Update biggest_mode.
> (collect_non_operand_hard_regs): Check eliminable regs too.
> (initialize_lra_reg_info_element): Initialize biggest_mode.
> (add_regs_to_insn_regno_info): Ignore non-allocatable
> non-eliminable hard regs.
> (lra.c): Move setting lra_no_alloc_regs before
> init_insn_recog_data.
> * lra-constraints.c (simplify_operand_subreg): Add a comment.
> (lra_constraints): Ignore equivalent memory of
> regs occuring in paradoxical subregs.
> * lra-lives.c (lra_create_live_ranges): Add a comment.
>
>

On Linux/x86-64, this caused:

FAIL: gcc.target/i386/avx-vzeroupper-16.c (internal compiler error)
FAIL: gcc.target/i386/avx-vzeroupper-16.c (test for excess errors)
FAIL: gcc.target/i386/avx-vzeroupper-17.c (internal compiler error)
FAIL: gcc.target/i386/avx-vzeroupper-17.c (test for excess errors)
FAIL: gcc.target/i386/avx-vzeroupper-18.c (internal compiler error)
FAIL: gcc.target/i386/avx-vzeroupper-18.c (test for excess errors)
FAIL: gcc.target/i386/pr43869.c (internal compiler error)
FAIL: gcc.target/i386/pr43869.c (test for excess errors)
FAIL: gcc.target/x86_64/abi/callabi/vaarg-1.c (internal compiler error)
FAIL: gcc.target/x86_64/abi/callabi/vaarg-1.c (test for excess errors)
FAIL: gcc.target/x86_64/abi/callabi/vaarg-3.c (internal compiler error)
FAIL: gcc.target/x86_64/abi/callabi/vaarg-3.c (test for excess errors)
FAIL: gcc.target/x86_64/abi/callabi/vaarg-4a.c (internal compiler error)
FAIL: gcc.target/x86_64/abi/callabi/vaarg-4a.c (test for excess errors)
FAIL: gcc.target/x86_64/abi/callabi/vaarg-4b.c (internal compiler error)
FAIL: gcc.target/x86_64/abi/callabi/vaarg-4b.c (test for excess errors)
FAIL: gcc.target/x86_64/abi/callabi/vaarg-5a.c (internal compiler error)
FAIL: gcc.target/x86_64/abi/callabi/vaarg-5a.c (test for excess errors)
FAIL: gcc.target/x86_64/abi/callabi/vaarg-5b.c (internal compiler error)
FAIL: gcc.target/x86_64/abi/callabi/vaarg-5b.c (test for excess errors)


-- 
H.J.