Patches to libsanitizer should be sent upstream. We should only
contain a copy of the master in the LLVM repository. There should be
instructions in libsanitizer/README.gcc (Jakub, Dodji, are they there?
I can't check ATM).
I don't think that's acceptable. GCC supports far more
On 11/12/12 14:10, Ulrich Weigand wrote:
http://gcc.gnu.org/ml/gcc-patches/2012-10/msg01521.html
Ping.
This is OK.
Please apply.
regards,
Ramana
Diego Novillo dnovi...@google.com a écrit:
Patches to libsanitizer should be sent upstream. We should only
contain a copy of the master in the LLVM repository. There should be
instructions in libsanitizer/README.gcc (Jakub, Dodji, are they there?
I can't check ATM).
No there are not, for
On Tue, Nov 13, 2012 at 3:20 AM, Dodji Seketeli do...@redhat.com wrote:
Diego Novillo dnovi...@google.com a écrit:
Patches to libsanitizer should be sent upstream. We should only
contain a copy of the master in the LLVM repository. There should be
instructions in libsanitizer/README.gcc
On Tue, Nov 13, 2012 at 03:31:21AM -0800, H.J. Lu wrote:
On Tue, Nov 13, 2012 at 3:20 AM, Dodji Seketeli do...@redhat.com wrote:
Diego Novillo dnovi...@google.com a écrit:
Patches to libsanitizer should be sent upstream. We should only
contain a copy of the master in the LLVM repository.
Hi,
This patch enables x32 check on more i386 tests. Tested with
RUNTESTFLAGS=--target_board='unix{-mx32\ -maddress-mode=short,-mx32\
-maddress-mode=long,-m32,}'
on Linux/x86-64. OK to install?
Thanks.
H.J.
---
2012-11-13 H.J. Lu hongjiu...@intel.com
*
On Tue, Nov 13, 2012 at 12:56 PM, H.J. Lu hjl.to...@gmail.com wrote:
This patch enables x32 check on more i386 tests. Tested with
RUNTESTFLAGS=--target_board='unix{-mx32\ -maddress-mode=short,-mx32\
-maddress-mode=long,-m32,}'
on Linux/x86-64. OK to install?
OK.
Thanks,
Uros.
On Mon, Nov 12, 2012 at 9:59 PM, Andrew Pinski pins...@gmail.com wrote:
I rather hate having to submit changes like this in two different
places. Why can't the people who added the target library like this
take responsibility for doing the merges from the GCC source to the
upstream? Like
Yes. And it shouldn't be just based on target CPU, but also based
on target OS, I don't think libsanitizer supports anything but linux (glibc
+ maybe android) right now, with some smaller or bigger tweaks it could
support darwin (but see the reports that it doesn't build there right now)
...
Hello,
here's another of Andrew's patches to improve NEON usage. This one was
originally posted here:
http://gcc.gnu.org/ml/gcc-patches/2012-02/msg01213.html
The idea to improve SImode to DImode extends that also move from core
registers to NEON registers. In this situation, the compiler used
This patch replaces:
/* Stop if the mode is wider than the alignment of the containing
object.
It is tempting to omit the following line unless STRICT_ALIGNMENT
is true. But that is incorrect, since if the bitfield uses part
of 3 bytes and we use a
On Tue, Nov 13, 2012 at 2:39 AM, Jakub Jelinek ja...@redhat.com wrote:
On Mon, Nov 12, 2012 at 10:13:08PM -0500, David Edelsohn wrote:
gcc/asan.c probably should have been split into two files because it
works at multiple levels. But given that it invokes
ASM_GENERATE_INTERNAL_LABEL, it needs
Jakub Jelinek ja...@redhat.com writes:
On Tue, Nov 13, 2012 at 02:17:55PM +0100, Dodji Seketeli wrote:
What do the maintainers think?
Yes. And it shouldn't be just based on target CPU, but also based
on target OS, I don't think libsanitizer supports anything but linux (glibc
+ maybe
Libsanitizer is not supported on AIX. Disable in configure.
* configure.ac: Disable libsanitizer on AIX. Merge libquadmath
sections.
* configure: Regenerate.
Index: configure.ac
===
--- configure.ac
BTW: Probably, pmulhrsw insn patterns can be merged, too, but this can
be a follow-up patch.
Please, have a look at patch which merge pmulhrsw patterns.
Changelog:
2012-11-13 Andrey Turetskiy andrey.turets...@gmail.com
* config/i386/sse.md (*ssse3_avx2_pmulhrswmode3): Merge
On Tue, Nov 13, 2012 at 03:06:56PM +0100, Dodji Seketeli wrote:
Jakub Jelinek ja...@redhat.com writes:
On Tue, Nov 13, 2012 at 02:17:55PM +0100, Dodji Seketeli wrote:
What do the maintainers think?
Yes. And it shouldn't be just based on target CPU, but also based
on target OS, I
Hello,
This patch builds libsanitizer only on x86_64 and i?86 linux targets
for now. I guess The build can be enabled on other targets when they
are ready.
OK for trunk?
ChangeLog:
* configure.ac: Enable libsanitizer just on x86 linux for now.
* configure: Re-generate.
---
domi...@lps.ens.fr (Dominique Dhumieres) writes:
Yes. And it shouldn't be just based on target CPU, but also based
on target OS, I don't think libsanitizer supports anything but linux (glibc
+ maybe android) right now, with some smaller or bigger tweaks it could
support darwin (but see the
On Tue, Nov 13, 2012 at 10:01 AM, Dodji Seketeli do...@redhat.com wrote:
Hello,
This patch builds libsanitizer only on x86_64 and i?86 linux targets
for now. I guess The build can be enabled on other targets when they
are ready.
OK for trunk?
ChangeLog:
* configure.ac: Enable
From: Dodji Seketeli do...@redhat.com
Date: Tue, 13 Nov 2012 16:04:12 +0100
I guess when the issue of the missing files is resolved, we can enable
building libsanitizer on Darwin proper. Here is the patchlet I am
proposing so far http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00993.html.
This patch builds libsanitizer only on x86_64 and i?86 linux targets
for now. I guess The build can be enabled on other targets when they
are ready.
Note that, even on these platforms, it cannot be installed:
libtool: install: error: cannot install `libasan.la' to a directory not ending
in
On 11/13/2012 04:53 PM, Jack Howarth wrote:
I also noticed while trying to regenerate the libsanitizer Makefile.in
on darwin that libsanitizer/configure.ac has... AC_PREREQ([2.68])
instead of the expected... AC_PREREQ([2.64])
This is other/55304, isn't it?
Paolo.
On Tue, Nov 13, 2012 at 12:07 AM, David Miller da...@davemloft.net wrote:
This has broken the build on every Linux target that hasn't added
the necessary cpu specific code to asan_linux.cc
This should be fixed by Dodji's recent patch. ASAN is not currently
ported to any target other than
Hi,
This patch adds support for GCC multilib run-time libraries to
libsanitizer. I have to delete install-sh. Otherwise ac_aux_dir will
be wrong:
ac_aux_dir=
for ac_dir in $srcdir $srcdir/.. $srcdir/../..; do
for ac_t in install-sh install.sh shtool; do
if test -f $ac_dir/$ac_t; then
On Mon, Nov 05, 2012 at 04:37:41PM -0800, Wei Mi wrote:
Thanks for the comments. I fix most of them except the setting of
TODO_ The new patch.txt is attached.
Please update the patch against trunk, it doesn't apply cleanly because
of the asan commit. I took the liberty to do at least some
On Tue, Nov 13, 2012 at 08:34:56AM -0800, H.J. Lu wrote:
Hi,
This patch adds support for GCC multilib run-time libraries to
libsanitizer. I have to delete install-sh. Otherwise ac_aux_dir will
be wrong:
ac_aux_dir=
for ac_dir in $srcdir $srcdir/.. $srcdir/../..; do
for ac_t in
On Tue, Nov 13, 2012 at 8:21 AM, Diego Novillo dnovi...@google.com wrote:
On Tue, Nov 13, 2012 at 12:07 AM, David Miller da...@davemloft.net wrote:
This has broken the build on every Linux target that hasn't added
the necessary cpu specific code to asan_linux.cc
This should be fixed by
On Tue, Nov 13, 2012 at 08:46:55AM -0800, H.J. Lu wrote:
On Tue, Nov 13, 2012 at 08:34:56AM -0800, H.J. Lu wrote:
This patch adds support for GCC multilib run-time libraries to
libsanitizer. I have to delete install-sh. Otherwise ac_aux_dir will
be wrong:
ac_aux_dir=
for ac_dir in
On Tue, 13 Nov 2012, Dodji Seketeli wrote:
* configure.ac: Enable libsanitizer just on x86 linux for now.
* configure: Re-generate.
Note that the preferred approach is the approach used for libatomic and
libitm, of the toplevel script using a script fragment from the
subdirectory
On Tue, Nov 13, 2012 at 8:56 AM, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Nov 13, 2012 at 08:46:55AM -0800, H.J. Lu wrote:
On Tue, Nov 13, 2012 at 08:34:56AM -0800, H.J. Lu wrote:
This patch adds support for GCC multilib run-time libraries to
libsanitizer. I have to delete install-sh.
Hi,
somehow the propagation of aggs_contain_variable in
merge_aggregate_lattices got lost when I was shuffling the code
around, leading to miscompilations. This patch puts it back in.
Bootstrapped and tested on x86_64-linux, OK for trunk?
Thanks,
Martin
2012-11-13 Martin Jambor
On Nov 12, 2012, at 4:56 PM, Joseph S. Myers jos...@codesourcery.com wrote:
On Mon, 12 Nov 2012, Andrew Pinski wrote:
Also does gtest support cross testing; that is testing over rsh/ssh
and testing via a simulator? We should require that as a requirement
also when it comes to testing
Hi,
somehow the propagation of aggs_contain_variable in
merge_aggregate_lattices got lost when I was shuffling the code
around, leading to miscompilations. This patch puts it back in.
Bootstrapped and tested on x86_64-linux, OK for trunk?
Thanks,
Martin
2012-11-13 Martin
On Mon, Nov 12, 2012 at 9:40 AM, Eric Botcazou ebotca...@adacore.com wrote:
It looks to me, that we in fact want:
--cut here--
Index: mode-switching.c
===
--- mode-switching.c(revision 193407)
+++ mode-switching.c
On Tue, Nov 13, 2012 at 06:07:20PM +0100, Uros Bizjak wrote:
@@ -242,7 +242,8 @@ create_pre_exit (int n_entities, int *entity_map,
int copy_start, copy_num;
int j;
- if (INSN_P (return_copy))
+ if (INSN_P (return_copy)
+
On Tue, Nov 13, 2012 at 6:09 PM, Jakub Jelinek ja...@redhat.com wrote:
int copy_start, copy_num;
int j;
- if (INSN_P (return_copy))
+ if (INSN_P (return_copy)
+ !DEBUG_INSN_P (return_copy))
Please use if (NONDEBUG_INSN_P
On Tue, Nov 13, 2012 at 8:40 AM, Jakub Jelinek ja...@redhat.com wrote:
On Mon, Nov 05, 2012 at 04:37:41PM -0800, Wei Mi wrote:
Thanks for the comments. I fix most of them except the setting of
TODO_ The new patch.txt is attached.
Please update the patch against trunk, it doesn't apply
On Tue, Nov 13, 2012 at 09:25:36AM -0800, Xinliang David Li wrote:
That is complete misunderstanding of what update_address_taken does.
It removes TREE_ADDRESSABLE from addressables that are no longer
addressable, rather than adding TREE_ADDRESSABLE bits.
It will do the latter too. See
On Mon, Nov 12, 2012 at 10:37 AM, Konstantin Serebryany
konstantin.s.serebry...@gmail.com wrote:
Hi,
I don't insist that we use gtest for gcc-asan, I just say that this is
the simplest approach to get 2.5K test suite into gcc,
and the only approach my team will be able to maintain.
gtest is
On Tue, Nov 13, 2012 at 9:36 AM, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Nov 13, 2012 at 09:25:36AM -0800, Xinliang David Li wrote:
That is complete misunderstanding of what update_address_taken does.
It removes TREE_ADDRESSABLE from addressables that are no longer
addressable, rather
On Tue, Nov 13, 2012 at 3:30 PM, H.J. Lu hjl.to...@gmail.com wrote:
Since x32 runs in 64-bit mode, for address -0x4300(%rax), hardware
sign-extends displacement from 32-bits to 64-bits and adds it to %rax.
But x32 wants 32-bit -0x4300, not 64-bit -0x4300. This patch
uses
On Tue, Nov 13, 2012 at 10:03 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Tue, Nov 13, 2012 at 3:30 PM, H.J. Lu hjl.to...@gmail.com wrote:
Since x32 runs in 64-bit mode, for address -0x4300(%rax), hardware
sign-extends displacement from 32-bits to 64-bits and adds it to %rax.
But x32
From: Diego Novillo dnovi...@google.com
Date: Tue, 13 Nov 2012 11:21:59 -0500
On Tue, Nov 13, 2012 at 12:07 AM, David Miller da...@davemloft.net wrote:
This has broken the build on every Linux target that hasn't added
the necessary cpu specific code to asan_linux.cc
This should be fixed by
3. Full output tests (a .cc file should be build with asan switch,
executable should be run and the stderr is compared with the expected
output)
Example:
http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/asan/lit_tests/stack-overflow.cc?revision=165391view=markup
The can be
We really need to start using the newer names, as Sun is not going to
provide single letter indicators for sparc4 or future xarch values.
In fact, that's exactly what needed to be worked on from the beginning
for the solaris side of this cbcond patch. We're talking in circles.
OK, sorry
From: Eric Botcazou ebotca...@adacore.com
Date: Tue, 13 Nov 2012 20:32:40 +0100
Working on this, I discovered an oddity in GNU as: -xarch=sparc4 -64 yields a
64-bit object file whereas -64 -xarch=sparc4 yields a 32-bit object file. My
understanding is that Sun as will generate a 64-bit
Dodji Seketeli do...@redhat.com writes:
I guess The build can be enabled on other targets when they are ready.
How to test that? There doesn't seem to be a testsuite included.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B
On 11/13/2012 05:24 AM, Jakub Jelinek wrote:
Yes. And it shouldn't be just based on target CPU, but also based
on target OS, I don't think libsanitizer supports anything but linux (glibc
+ maybe android) right now, with some smaller or bigger tweaks it could
support darwin (but see the
Right now if you run gcc -fpie -fpic you get, in effect, gcc -fpie.
I think you should get gcc -fpic. In general I think that of the
options -fpic, -fPIC, -fpie, -fPIE, -fno-pic, -fno-PIC, -fno-pie,
-fno-PIE the compiler should act as though only the last of those
options were specified. That
On Tue, Nov 13, 2012 at 12:45 PM, Ian Lance Taylor i...@google.com wrote:
Right now if you run gcc -fpie -fpic you get, in effect, gcc -fpie.
I think you should get gcc -fpic. In general I think that of the
options -fpic, -fPIC, -fpie, -fPIE, -fno-pic, -fno-PIC, -fno-pie,
-fno-PIE the
+ for (elem = other_queue; elem ; elem = elem-next)
+ {
Note that your indentation is off in places.
+ /* We are parsing DEFINE_SUBST_ATTR, which could cause generation
+ of DEFINE_ATTR for introduced DEFINE_SUBST. It doesn't happen
+ if such DEFINE_ATTR has already been
On Tue, Nov 13, 2012 at 9:03 AM, Martin Jambor mjam...@suse.cz wrote:
Index: src/gcc/ipa-cp.c
===
--- src.orig/gcc/ipa-cp.c
+++ src/gcc/ipa-cp.c
@@ -1276,6 +1276,8 @@ merge_aggregate_lattices (struct cgraph_
return true;
I migrate a test in the third category. Please help to check whether
it is ok. Then I will migrate the left. The files added are as follows
and attached. (Please forgive I use -fasan in asan.exp because I use
an old repository to try the migration)
gcc/testsuite/lib/asan-dg.exp:
On Tue, Nov 13, 2012 at 8:21 AM, Diego Novillo dnovi...@google.com wrote:
On Tue, Nov 13, 2012 at 12:07 AM, David Miller da...@davemloft.net wrote:
This has broken the build on every Linux target that hasn't added
the necessary cpu specific code to asan_linux.cc
This should be fixed by
PR 55312 points out that libbacktrace is adding -Werror incorrectly. We
should not be adding it when built as a host library, because we don't
know the characteristics of the host compiler. We should only add it
when built as a target library. This patch implements that.
Bootstrapped and ran
On Tue, Nov 13, 2012 at 3:42 AM, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Nov 13, 2012 at 03:31:21AM -0800, H.J. Lu wrote:
On Tue, Nov 13, 2012 at 3:20 AM, Dodji Seketeli do...@redhat.com wrote:
Diego Novillo dnovi...@google.com a écrit:
Patches to libsanitizer should be sent
Here is the proposal to remove shrinking feature from hash policy.
I have also considered your remark regarding usage of lower_bound so
_M_bkt_for_elements doesn't call _M_next_bkt (calling lower_bound)
anymore. For 2 of the 3 calls it was only a source of redundant
lower_bound
On 11/13/2012 04:41 AM, Eric Botcazou wrote:
I find the interface a bit awkward though. Can't we model it on the existing
iterators in basic-block.h or tree-flow.h? get_best_mode would be written:
FOR_EACH_BITFIELD_MODE (mode, iter, bitsize, bitpos,
On Tue, Nov 13, 2012 at 1:40 PM, Konstantin Serebryany
konstantin.s.serebry...@gmail.com wrote:
On Tue, Nov 13, 2012 at 3:42 AM, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Nov 13, 2012 at 03:31:21AM -0800, H.J. Lu wrote:
On Tue, Nov 13, 2012 at 3:20 AM, Dodji Seketeli do...@redhat.com wrote:
Will this run the test in all mode (O0 vs O2 and -m32 vs -m64)?
--kcc
Yes, it runs in all modes. O0/O1/O2/O3 + -m32/-m64, which is specified
in asan.exp.
Thanks,
Wei.
As discussed elsewhere. Tested on x86_64-linux.
r~
---
ChangeLog | 5 +
configure | 28 +++-
configure.ac| 25 -
libsanitizer/ChangeLog.asan | 4
libsanitizer/configure.tgt | 28
Thanks for finding this, that's definitely incorrect behavior. I bet there
is some unintended override triggered by sparc4 selection, and I'll go and
fix that soon.
You're welcome. That's the reason why I needed to go the ASM_ARCH way, the
straightforward approach would have put the -32/-64
On Tue, Nov 13, 2012 at 1:40 PM, Konstantin Serebryany
konstantin.s.serebry...@gmail.com wrote:
On Tue, Nov 13, 2012 at 3:42 AM, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Nov 13, 2012 at 03:31:21AM -0800, H.J. Lu wrote:
On Tue, Nov 13, 2012 at 3:20 AM, Dodji Seketeli do...@redhat.com wrote:
On Tue, Nov 13, 2012 at 1:24 PM, Konstantin Serebryany
konstantin.s.serebry...@gmail.com wrote:
I migrate a test in the third category. Please help to check whether
it is ok. Then I will migrate the left. The files added are as follows
and attached. (Please forgive I use -fasan in asan.exp
Patch committed now after making the changes.
Thanks,
-Sri.
On Mon, Nov 12, 2012 at 6:39 PM, Jason Merrill ja...@redhat.com wrote:
On 11/12/2012 08:11 PM, Sriraman Tallam wrote:
+!targetm.target_option.function_versions (fn,
+TREE_PURPOSE (match)))
The second
From: Eric Botcazou ebotca...@adacore.com
Date: Tue, 13 Nov 2012 22:50:49 +0100
Thanks for finding this, that's definitely incorrect behavior. I bet there
is some unintended override triggered by sparc4 selection, and I'll go and
fix that soon.
You're welcome. That's the reason why I
Now that we're in C++, I think we should be using iterators that are much
more in the style of libstdc++. I agree that the .next interface used here
is a bit confusing.
I'd expect to see something like
for (bit_field_mode_iterator i(x,y,z); i ; ++i)
{
enum machine_mode mode
On Tue, Nov 13, 2012 at 3:20 AM, Dodji Seketeli do...@redhat.com wrote:
Diego Novillo dnovi...@google.com a écrit:
Patches to libsanitizer should be sent upstream. We should only
contain a copy of the master in the LLVM repository. There should be
instructions in libsanitizer/README.gcc
On Tue, Nov 13, 2012 at 1:49 PM, Wei Mi w...@google.com wrote:
Will this run the test in all mode (O0 vs O2 and -m32 vs -m64)?
--kcc
Yes, it runs in all modes. O0/O1/O2/O3 + -m32/-m64, which is specified
in asan.exp.
Does it support -mx32?
--
H.J.
On Tue, Nov 13, 2012 at 1:46 PM, Andrew Pinski pins...@gmail.com wrote:
On Tue, Nov 13, 2012 at 1:40 PM, Konstantin Serebryany
konstantin.s.serebry...@gmail.com wrote:
On Tue, Nov 13, 2012 at 3:42 AM, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Nov 13, 2012 at 03:31:21AM -0800, H.J. Lu
On Tue, Nov 13, 2012 at 1:53 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Tue, Nov 13, 2012 at 1:40 PM, Konstantin Serebryany
konstantin.s.serebry...@gmail.com wrote:
On Tue, Nov 13, 2012 at 3:42 AM, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Nov 13, 2012 at 03:31:21AM -0800, H.J. Lu wrote:
On Tue, Nov 13, 2012 at 1:55 PM, Andrew Pinski pins...@gmail.com wrote:
On Tue, Nov 13, 2012 at 1:24 PM, Konstantin Serebryany
konstantin.s.serebry...@gmail.com wrote:
I migrate a test in the third category. Please help to check whether
it is ok. Then I will migrate the left. The files added
On Tue, Nov 13, 2012 at 3:42 AM, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Nov 13, 2012 at 03:31:21AM -0800, H.J. Lu wrote:
On Tue, Nov 13, 2012 at 3:20 AM, Dodji Seketeli do...@redhat.com wrote:
Diego Novillo dnovi...@google.com a écrit:
Patches to libsanitizer should be sent
H.J.,
Question about this patch.
Will it work if we simply replace
#if __WORDSIZE == 64
with
#ifdef x86_64
?
Today, x86_64 is the only 64-bit architecture supported by asan
run-time on linux anyway.
On Tue, Nov 13, 2012 at 1:53 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Tue, Nov 13, 2012
On Tue, Nov 13, 2012 at 2:26 PM, Konstantin Serebryany
konstantin.s.serebry...@gmail.com wrote:
H.J.,
Question about this patch.
Will it work if we simply replace
#if __WORDSIZE == 64
with
#ifdef x86_64
?
Today, x86_64 is the only 64-bit architecture supported by asan
run-time on
Il 13/11/2012 18:03, H.J. Lu ha scritto:
libsanitizer/ChangeLog.asan should probably be just libsanitizer/ChangeLog.
In any case, I'd prefer if configury maintainers could review that.
Sure.
Let's first remove the files that are duplicated between the toplevel
and libsanitizer/. This is
On 13 Nov 2012, at 21:18, Konstantin Serebryany
konstantin.s.serebry...@gmail.com wrote:
On Tue, Nov 13, 2012 at 8:21 AM, Diego Novillo dnovi...@google.com wrote:
On Tue, Nov 13, 2012 at 12:07 AM, David Miller da...@davemloft.net wrote:
This has broken the build on every Linux target that
On Tue, 13 Nov 2012, Ian Lance Taylor wrote:
Right now if you run gcc -fpie -fpic you get, in effect, gcc -fpie.
I think you should get gcc -fpic. In general I think that of the
options -fpic, -fPIC, -fpie, -fPIE, -fno-pic, -fno-PIC, -fno-pie,
-fno-PIE the compiler should act as though only
On Tue, Nov 13, 2012 at 2:29 PM, Andrew Pinski pins...@gmail.com wrote:
On Tue, Nov 13, 2012 at 2:26 PM, Konstantin Serebryany
konstantin.s.serebry...@gmail.com wrote:
H.J.,
Question about this patch.
Will it work if we simply replace
#if __WORDSIZE == 64
with
#ifdef x86_64
?
On Tue, Nov 13, 2012 at 2:26 PM, Konstantin Serebryany
konstantin.s.serebry...@gmail.com wrote:
H.J.,
Question about this patch.
Will it work if we simply replace
#if __WORDSIZE == 64
with
#ifdef x86_64
?
Today, x86_64 is the only 64-bit architecture supported by asan
run-time on
On Tue, Nov 13, 2012 at 2:39 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Tue, Nov 13, 2012 at 2:26 PM, Konstantin Serebryany
konstantin.s.serebry...@gmail.com wrote:
H.J.,
Question about this patch.
Will it work if we simply replace
#if __WORDSIZE == 64
with
#ifdef x86_64
?
Today,
On Tue, Nov 13, 2012 at 2:31 PM, Ramana Radhakrishnan
ramana@googlemail.com wrote:
On 13 Nov 2012, at 21:18, Konstantin Serebryany
konstantin.s.serebry...@gmail.com wrote:
On Tue, Nov 13, 2012 at 8:21 AM, Diego Novillo dnovi...@google.com wrote:
On Tue, Nov 13, 2012 at 12:07 AM, David
Sure, I can add the support. To run -mx32 test, we need to add x32
multilib support for libasan first, right?
Thanks,
Wei.
On Tue, Nov 13, 2012 at 2:14 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Tue, Nov 13, 2012 at 1:49 PM, Wei Mi w...@google.com wrote:
Will this run the test in all mode (O0
On Tue, Nov 13, 2012 at 2:44 PM, Wei Mi w...@google.com wrote:
Sure, I can add the support. To run -mx32 test, we need to add x32
multilib support for libasan first, right?
Compiling with -mx32 is trivial. I am working on the small patch.
Wei.
On Tue, Nov 13, 2012 at 2:14 PM, H.J. Lu
Hi,
On 11/13/2012 10:40 PM, François Dumont wrote:
Here is the proposal to remove shrinking feature from hash policy. I
have also considered your remark regarding usage of lower_bound so
_M_bkt_for_elements doesn't call _M_next_bkt (calling lower_bound)
anymore. For 2 of the 3 calls it was
Il 13/11/2012 23:45, H.J. Lu ha scritto:
Let's first remove the files that are duplicated between the toplevel
and libsanitizer/. This is preapproved after a successful bootstrap,
but please remember to rerun autoconf/automake in the libsanitizer/
directory.
We can't remove duplicated
On 11/13/2012 11:53 PM, Paolo Carlini wrote:
To summarize my intuitions are (again, leaving out the final
technicalities)
a- std::hash specializations for scalar types - no cache
b- std::hash specialization for for std::string (or maybe
everything else, for simplicity) - cache
c-
On Tue, Nov 13, 2012 at 2:40 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Tue, Nov 13, 2012 at 2:39 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Tue, Nov 13, 2012 at 2:26 PM, Konstantin Serebryany
konstantin.s.serebry...@gmail.com wrote:
H.J.,
Question about this patch.
Will it work if we simply
On Tue, Nov 13, 2012 at 3:03 PM, Paolo Bonzini bonz...@gnu.org wrote:
Il 13/11/2012 23:45, H.J. Lu ha scritto:
Let's first remove the files that are duplicated between the toplevel
and libsanitizer/. This is preapproved after a successful bootstrap,
but please remember to rerun
+euge...@google.com
asan run-time (and the LLVM part) works on Mac and on ARM/Linux.
And when you say ARM / Linux, has this been tested on older versions of the
architecture or just v7-a ?
Evgeniy is better equipped to answer this.
At some point we've been testing asan on the actual
Il 14/11/2012 00:16, H.J. Lu ha scritto:
What has to be fixed about it? Anything except
AC_PREREQ/AC_CONFIG_AUX_DIR?
I really would prefer to do it in the order I mentioned above.
We also need
[hjl@gnu-tools-1 libsanitizer]$ cat acinclude.m4
dnl
On Tue, Nov 13, 2012 at 3:19 PM, Paolo Bonzini bonz...@gnu.org wrote:
Il 14/11/2012 00:16, H.J. Lu ha scritto:
What has to be fixed about it? Anything except
AC_PREREQ/AC_CONFIG_AUX_DIR?
I really would prefer to do it in the order I mentioned above.
We also need
[hjl@gnu-tools-1
Il 14/11/2012 00:27, H.J. Lu ha scritto:
On Tue, Nov 13, 2012 at 3:19 PM, Paolo Bonzini bonz...@gnu.org wrote:
Il 14/11/2012 00:16, H.J. Lu ha scritto:
What has to be fixed about it? Anything except
AC_PREREQ/AC_CONFIG_AUX_DIR?
I really would prefer to do it in the order I mentioned above.
On Tue, Nov 13, 2012 at 3:31 PM, Paolo Bonzini bonz...@gnu.org wrote:
Il 14/11/2012 00:27, H.J. Lu ha scritto:
On Tue, Nov 13, 2012 at 3:19 PM, Paolo Bonzini bonz...@gnu.org wrote:
Il 14/11/2012 00:16, H.J. Lu ha scritto:
What has to be fixed about it? Anything except
Il 14/11/2012 00:43, H.J. Lu ha scritto:
This works.
Ok, then please test remove install-sh and friends and do
autoconf/automake again. If it works, commit the result (I don't care
if you make it one or two commits).
Then, wait 24 hours for breakages and commit the multilib patch.
Paolo
On Nov 13, 2012, at 1:03 PM, Richard Henderson r...@redhat.com wrote:
Looking at all this, I'm wondering if we shouldn't split out all of this
macro/include processing to a separate pass. Perform the preprocessing
once, early, leaving the processed result in the build directory. Then
run the
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 dvyu...@google.com
Careful, you've got double applied
On Tue, Nov 13, 2012 at 10:41 PM, Andrew Pinski pins...@gmail.com wrote:
On Tue, Nov 13, 2012 at 2:31 PM, Ramana Radhakrishnan
ramana@googlemail.com wrote:
On 13 Nov 2012, at 21:18, Konstantin Serebryany
konstantin.s.serebry...@gmail.com wrote:
On Tue, Nov 13, 2012 at 8:21 AM, Diego
Thanks for catching this. I update the patch.
Regards,
Wei.
On Tue, Nov 13, 2012 at 4:54 PM, Richard Henderson r...@redhat.com 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.
+
From: Richard Henderson r...@redhat.com
Date: Tue, 13 Nov 2012 21:38:40 +0100
On 11/13/2012 05:24 AM, Jakub Jelinek wrote:
Yes. And it shouldn't be just based on target CPU, but also based
on target OS, I don't think libsanitizer supports anything but linux (glibc
+ maybe android) right
1 - 100 of 105 matches
Mail list logo
