On Tue, Nov 13, 2012 at 3:23 PM, Andrey Turetskiy
wrote:
>> 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
>
>* config/i386/sse
On Tue, Nov 13, 2012 at 7:23 PM, H.J. Lu 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
>>
On 11/5/2012 12:57 PM, rbmj wrote:
This removes warnings about implicit declarations and fixes one of the
function calls in vxlib-tls.c for vxworks targets.
I got the old prototypes from
http://gcc.gnu.org/ml/gcc-patches/2005-08/msg01314.html
See bug for further details.
Someone please comment
> From: Richard Henderson
> Date: Wed, 14 Nov 2012 02:34:32 +0100
> On 11/13/2012 05:20 PM, Hans-Peter Nilsson wrote:
> > Right. And, I think it's worth to repeat ;) that IMHO best to
> > there simply check that -faddress-sanitizer can compile
> > error-free (i.e. that TARGET_ASAN_SHADOW_OFFSET
On 11/13/2012 05:20 PM, Hans-Peter Nilsson wrote:
> Right. And, I think it's worth to repeat ;) that IMHO best to
> there simply check that -faddress-sanitizer can compile
> error-free (i.e. that TARGET_ASAN_SHADOW_OFFSET is defined on
> the target). No target lists needed.
We can't do that, sin
> From: Richard Henderson
> 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 now, w
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
On Tue, Nov 13, 2012 at 10:41 PM, Andrew Pinski wrote:
> On Tue, Nov 13, 2012 at 2:31 PM, Ramana Radhakrishnan
> wrote:
>>
>>
>> On 13 Nov 2012, at 21:18, Konstantin Serebryany
>> wrote:
>>
>>> On Tue, Nov 13, 2012 at 8:21 AM, Diego Novillo wrote:
On Tue, Nov 13, 2012 at 12:07 AM, David M
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
On Nov 13, 2012, at 1:03 PM, Richard Henderson 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 original/tr
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 Tue, Nov 13, 2012 at 3:31 PM, Paolo Bonzini wrote:
> Il 14/11/2012 00:27, H.J. Lu ha scritto:
>> On Tue, Nov 13, 2012 at 3:19 PM, Paolo Bonzini 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?
>>
Il 14/11/2012 00:27, H.J. Lu ha scritto:
> On Tue, Nov 13, 2012 at 3:19 PM, Paolo Bonzini 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
On Tue, Nov 13, 2012 at 3:19 PM, Paolo Bonzini 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
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 --
+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 ac
On Tue, Nov 13, 2012 at 3:03 PM, Paolo Bonzini 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 autoconf
On Tue, Nov 13, 2012 at 2:40 PM, H.J. Lu wrote:
> On Tue, Nov 13, 2012 at 2:39 PM, H.J. Lu wrote:
>> On Tue, Nov 13, 2012 at 2:26 PM, Konstantin Serebryany
>> wrote:
>>> H.J.,
>>> Question about this patch.
>>> Will it work if we simply replace
>>>#if __WORDSIZE == 64
>>> with
>>> #ifdef x
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
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 rem
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 onl
On Tue, Nov 13, 2012 at 2:44 PM, Wei Mi 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 wrote:
>> On T
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 wrote:
> On Tue, Nov 13, 2012 at 1:49 PM, Wei Mi wrote:
>>> Will this run the test in all mode (O0 vs O2 and -m32 vs -m64)?
>>>
>>>
On Tue, Nov 13, 2012 at 2:31 PM, Ramana Radhakrishnan
wrote:
>
>
> On 13 Nov 2012, at 21:18, Konstantin Serebryany
> wrote:
>
>> On Tue, Nov 13, 2012 at 8:21 AM, Diego Novillo wrote:
>>> On Tue, Nov 13, 2012 at 12:07 AM, David Miller wrote:
This has broken the build on every Linux ta
On Tue, Nov 13, 2012 at 2:39 PM, H.J. Lu wrote:
> On Tue, Nov 13, 2012 at 2:26 PM, Konstantin Serebryany
> 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 architect
On Tue, Nov 13, 2012 at 2:26 PM, Konstantin Serebryany
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 linux anyway.
>
>
That wo
On Tue, Nov 13, 2012 at 2:29 PM, Andrew Pinski wrote:
> On Tue, Nov 13, 2012 at 2:26 PM, Konstantin Serebryany
> 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 arc
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 tho
I have merged trunk revision 193484 to the gccgo branch.
Ian
On 13 Nov 2012, at 21:18, Konstantin Serebryany
wrote:
> On Tue, Nov 13, 2012 at 8:21 AM, Diego Novillo wrote:
>> On Tue, Nov 13, 2012 at 12:07 AM, David Miller wrote:
>>>
>>> This has broken the build on every Linux target that hasn't added
>>> the necessary cpu specific code to asan_linux
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/.
On Tue, Nov 13, 2012 at 2:26 PM, Konstantin Serebryany
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 linux anyway.
Because x86
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 wrote:
> On Tue, Nov 13, 2012 at 1:40 PM, Konstant
On Tue, Nov 13, 2012 at 3:42 AM, Jakub Jelinek 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 wrote:
>> > Diego Novillo a écrit:
>> >
>> >> Patches to libsanitizer should be sent upstream. We should only
>> >> contain a copy
On Tue, Nov 13, 2012 at 1:55 PM, Andrew Pinski wrote:
> On Tue, Nov 13, 2012 at 1:24 PM, Konstantin Serebryany
> 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 for
On Tue, Nov 13, 2012 at 1:53 PM, H.J. Lu wrote:
> On Tue, Nov 13, 2012 at 1:40 PM, Konstantin Serebryany
> wrote:
>> On Tue, Nov 13, 2012 at 3:42 AM, Jakub Jelinek 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 wrote:
>>>
On Tue, Nov 13, 2012 at 1:46 PM, Andrew Pinski wrote:
> On Tue, Nov 13, 2012 at 1:40 PM, Konstantin Serebryany
> wrote:
>> On Tue, Nov 13, 2012 at 3:42 AM, Jakub Jelinek 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 wrot
On Tue, Nov 13, 2012 at 1:49 PM, Wei Mi 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 3:20 AM, Dodji Seketeli wrote:
> Diego Novillo 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?
> 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_m
From: Eric Botcazou
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 needed to go the A
Patch committed now after making the changes.
Thanks,
-Sri.
On Mon, Nov 12, 2012 at 6:39 PM, Jason Merrill wrote:
> On 11/12/2012 08:11 PM, Sriraman Tallam wrote:
>>
>> + && !targetm.target_option.function_versions (fn,
>> +TREE_PURPOSE (match)))
>
>
> The second argume
On Tue, Nov 13, 2012 at 1:24 PM, Konstantin Serebryany
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 because I use
>> an old reposito
On Tue, Nov 13, 2012 at 1:40 PM, Konstantin Serebryany
wrote:
> On Tue, Nov 13, 2012 at 3:42 AM, Jakub Jelinek 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 wrote:
>>> > Diego Novillo a écrit:
>>> >
>>> >> Patches to libsa
> 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/-
As discussed elsewhere. Tested on x86_64-linux.
r~
---
ChangeLog | 5 +
configure | 28 +++-
configure.ac| 25 -
libsanitizer/ChangeLog.asan | 4
libsanitizer/configure.tgt | 28 +
> 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.
On Tue, Nov 13, 2012 at 1:40 PM, Konstantin Serebryany
wrote:
> On Tue, Nov 13, 2012 at 3:42 AM, Jakub Jelinek 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 wrote:
>>> > Diego Novillo a écrit:
>>> >
>>> >> Patches to libsa
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,
> bitregion
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 invocations,
On Tue, Nov 13, 2012 at 3:42 AM, Jakub Jelinek 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 wrote:
>> > Diego Novillo a écrit:
>> >
>> >> Patches to libsanitizer should be sent upstream. We should only
>> >> contain a copy
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 lib
On Tue, Nov 13, 2012 at 8:21 AM, Diego Novillo wrote:
> On Tue, Nov 13, 2012 at 12:07 AM, David Miller 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
> 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 9:03 AM, Martin Jambor 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;
>if (sr
> + 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 b
On Tue, Nov 13, 2012 at 12:45 PM, 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 shou
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. Th
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 rep
Dodji Seketeli 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 8276 4ED5
"And now
From: Eric Botcazou
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 object file in both cas
> 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, sorr
>> > 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=165391&view=markup
>
From: Diego Novillo
Date: Tue, 13 Nov 2012 11:21:59 -0500
> On Tue, Nov 13, 2012 at 12:07 AM, David Miller 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 i
On Tue, Nov 13, 2012 at 10:03 AM, Uros Bizjak wrote:
> On Tue, Nov 13, 2012 at 3:30 PM, H.J. Lu 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 -0
On Tue, Nov 13, 2012 at 3:30 PM, H.J. Lu 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 9:36 AM, Jakub Jelinek 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 than a
On Mon, Nov 12, 2012 at 10:37 AM, Konstantin Serebryany
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 not as portable as the rest
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.
On Tue, Nov 13, 2012 at 8:40 AM, Jakub Jelinek 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 cleanly becau
On Tue, Nov 13, 2012 at 6:09 PM, Jakub Jelinek 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 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 Mon, Nov 12, 2012 at 9:40 AM, Eric Botcazou wrote:
>> It looks to me, that we in fact want:
>>
>> --cut here--
>> Index: mode-switching.c
>> ===
>> --- mode-switching.c(revision 193407)
>> +++ mode-switching.c(working copy)
> 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
On Nov 12, 2012, at 4:56 PM, "Joseph S. Myers" 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 infrastructures.
>
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
P
On Tue, Nov 13, 2012 at 8:56 AM, Jakub Jelinek 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. Otherwis
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
subdirector
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
On Tue, Nov 13, 2012 at 8:21 AM, Diego Novillo wrote:
> On Tue, Nov 13, 2012 at 12:07 AM, David Miller 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
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
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
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"; th
On Tue, Nov 13, 2012 at 12:07 AM, David Miller 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 x86/linux, so it shou
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 04:14:10PM +0100, Eric Botcazou wrote:
> > 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:
>
> libt
> 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
> From: Dodji Seketeli
> 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.
That's the dire
On Tue, Nov 13, 2012 at 10:01 AM, Dodji Seketeli 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 libsani
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 se
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.
---
con
On Tue, Nov 13, 2012 at 03:06:56PM +0100, Dodji Seketeli wrote:
> Jakub Jelinek 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 th
On Tue, Nov 13, 2012 at 08:28:04AM +0100, Uros Bizjak wrote:
> On Tue, Nov 13, 2012 at 8:15 AM, H.J. Lu 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
> 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
* config/i386/sse.md (*_pmulhrsw3): Merge
*avx2_pmulhrswv16hi3 and *ssse3_pmulhrsw
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(re
Jakub Jelinek 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 android) right n
On Tue, Nov 13, 2012 at 2:39 AM, Jakub Jelinek 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 to includ
> This patch makes bit_field_mode_iterator take -fstrict-volatile-bitfields
> into account, in cases where the size of the underlying object is known.
> This is used in the next patch.
Do we really need to add that to the iterator? The -fstrict-volatile-
bitfields implementation is still controve
> 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
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 t
1 - 100 of 112 matches
Mail list logo
