On Mon, Nov 19, 2012 at 10:44 PM, Tobias Burnus wrote:
> Dear all,
>
> attached is a first draft for -faddress-sanitizer in the release notes.
>
> I am aware that some changes are imminent,* but I want make a start.
> Comments?
stack overflow is something different, I guess we want to say "stack
On Mon, Nov 19, 2012 at 10:31 PM, Xinliang David Li wrote:
> Questions: are -fsanitize=thread -fsanitize=address mutually exclusive
> here? If yes, that will be wrong.
>
> How about -fsanitize=all option?
asan and tsan can not coexist in the same process.
Until recently, using both flags with cla
On Mon, Nov 19, 2012 at 11:21 PM, Wei Mi wrote:
> I cannot remove RejectNegative and use -fno-sanitize=address, or else
> I will break an assertion (opts-common.c:614). The assertion requires
> -fxxx=var options set RejectNegative if var is of enumerater type. I
> see that all the other -fxxx=xx
I don't think it's reasonable that the sparc bootstrap is still broken
in the tree, even though a fix has existed for nearly a week.
It is not acceptable to say "everyone has to apply a special patch
until some external dependency that will take an unknown, variable,
length of time to resolve is
If that is a limitation, the compiler should give a warning about it
instead of making them silently suppress each other. Think about some
other sanitizer options that can co-exist with asan or tsan in the
future.
David
On Mon, Nov 19, 2012 at 9:07 PM, Konstantin Serebryany
wrote:
> On Mon, Nov
> -Original Message-
> From: Matthew Gretton-Dann [mailto:matthew.gretton-d...@linaro.org]
> Sent: Monday, November 19, 2012 8:20 PM
> To: Bin Cheng
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH ARM]Define LOGICAL_OP_NON_SHORT_CIRCUIT for ARM target
>
> On 16 November 2012 12:22, B
On Tue, Nov 20, 2012 at 9:16 AM, David Miller wrote:
>
> I don't think it's reasonable that the sparc bootstrap is still broken
> in the tree, even though a fix has existed for nearly a week.
>
> It is not acceptable to say "everyone has to apply a special patch
> until some external dependency th
On Tue, Nov 20, 2012 at 9:16 AM, Xinliang David Li wrote:
> If that is a limitation, the compiler should give a warning about it
> instead of making them silently suppress each other. Think about some
> other sanitizer options that can co-exist with asan or tsan in the
> future.
Yes, that's what
From: Konstantin Serebryany
Date: Tue, 20 Nov 2012 09:20:29 +0400
> Please do (the same that was applied upstream).
Which one was that?
> Please also note:
> - I am on vacation with random access to PC, that's why I did not
> want to rush with my first commits to gcc trunk.
This is actually
On Tue, Nov 20, 2012 at 9:26 AM, David Miller wrote:
> From: Konstantin Serebryany
> Date: Tue, 20 Nov 2012 09:20:29 +0400
>
>> Please do (the same that was applied upstream).
>
> Which one was that?
http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/sanitizer_common/sanitizer_linux.cc?r1=
From: Konstantin Serebryany
Date: Tue, 20 Nov 2012 09:34:14 +0400
> On Tue, Nov 20, 2012 at 9:26 AM, David Miller wrote:
>> From: Konstantin Serebryany
>> Date: Tue, 20 Nov 2012 09:20:29 +0400
>>
>>> Please do (the same that was applied upstream).
>>
>> Which one was that?
> http://llvm.org/vie
On Tue, Nov 20, 2012 at 12:04 AM, Peter Bergner wrote:
> On Fri, 2012-11-16 at 15:47 -0800, Konstantin Serebryany wrote:
>> On Fri, Nov 16, 2012 at 3:08 PM, Peter Bergner wrote:
>> > The lone ASAN
>> > test case does fail, but it seems to be related to us using
>> > _Unwind_Backtrace() and we end
On Tue, Nov 20, 2012 at 10:20 AM, David Miller wrote:
> From: Konstantin Serebryany
> Date: Tue, 20 Nov 2012 09:34:14 +0400
>
>> On Tue, Nov 20, 2012 at 9:26 AM, David Miller wrote:
>>> From: Konstantin Serebryany
>>> Date: Tue, 20 Nov 2012 09:20:29 +0400
>>>
Please do (the same that was a
101 - 113 of 113 matches
Mail list logo
