Bootstrapped successfully on x64 with proposed patch.
The original commit indeed failed to bootstrap
(https://gcc.gnu.org/ml/gcc-testresults/2014-06/msg01419.html).
Ok to commit fix?
Ok (with proper ChangeLog entry).
r211713.
-Y
On Mon, Jun 16, 2014 at 10:21:39PM +0400, Yury Gribov wrote:
> On 06/16/2014 04:47 PM, Yury Gribov wrote:
> >On 06/16/2014 02:34 PM, Dominique Dhumieres wrote:
> >>>Done in r211699.
> >>
> >>This breaks bootstrap on x86_64-apple-darwin13:
> >
> >Hm, perhaps I didn't run full bootstrap after last ro
On 06/16/2014 04:47 PM, Yury Gribov wrote:
On 06/16/2014 02:34 PM, Dominique Dhumieres wrote:
Done in r211699.
This breaks bootstrap on x86_64-apple-darwin13:
Hm, perhaps I didn't run full bootstrap after last round of review.
Does attached patch solve the problem for you? I've started boots
I have bootstrapped r211707 with the full patch (among others!).
> It does not. So the above is IMHO very likely completely unrelated,
> perhaps Darwin specific, issue.
More likely related to the fact that I only resumed bootstrap after the change
tree t = NULL_TREE; and an update from r211700 t
On Mon, Jun 16, 2014 at 04:57:54PM +0400, Yury Gribov wrote:
> On 06/16/2014 04:52 PM, Dominique Dhumieres wrote:
> >I have done the change to tree t = NULL_TREE; then bootstrap fails with
> >
> >Bootstrap comparison failure!
> >gcc/plugin.o differs
> >gcc/toplev.o differs
>
> Interesting, I didn'
On 06/16/2014 04:52 PM, Dominique Dhumieres wrote:
I have done the change to tree t = NULL_TREE; then bootstrap fails with
Bootstrap comparison failure!
gcc/plugin.o differs
gcc/toplev.o differs
Interesting, I didn't know that asan.c runs during normal bootstrap.
-Y
I have done the change to tree t = NULL_TREE; then bootstrap fails with
Bootstrap comparison failure!
gcc/plugin.o differs
gcc/toplev.o differs
I'll try your full patch later (currently bootstrapping r211698).
Thanks,
Dominique
On 06/16/2014 02:34 PM, Dominique Dhumieres wrote:
Done in r211699.
This breaks bootstrap on x86_64-apple-darwin13:
Hm, perhaps I didn't run full bootstrap after last round of review.
Does attached patch solve the problem for you? I've started bootstrap
but it'll take couple of hours to compl
> Done in r211699.
This breaks bootstrap on x86_64-apple-darwin13:
/opt/gcc/build_w/./prev-gcc/xg++ -B/opt/gcc/build_w/./prev-gcc/
-B/opt/gcc/gcc4.10w/x86_64-apple-darwin13.2.0/bin/ -nostdinc++
-B/opt/gcc/build_w/prev-x86_64-apple-darwin13.2.0/libstdc++-v3/src/.libs
-B/opt/gcc/build_w/prev-x86
On 06/16/2014 12:23 PM, Jakub Jelinek wrote:
2014-06-11 Yury Gribov
New asan-instrumentation-with-call-threshold parameter.
Ok, thanks.
Done in r211699.
On Wed, Jun 11, 2014 at 04:53:32PM +0400, Yury Gribov wrote:
> On 06/11/2014 01:31 PM, Jakub Jelinek wrote:
> >The plan (we had already for 4.9, but didn't get to that yet) is in the end
> >not to lower the checks in asan pass that much, and lower it in sanopt
> >pass later on after performing some
On 06/11/2014 01:31 PM, Jakub Jelinek wrote:
The plan (we had already for 4.9, but didn't get to that yet) is in the end
not to lower the checks in asan pass that much, and lower it in sanopt
pass later on after performing some inter-bb optimizations.
...
The reason for the plan is that it will b
On Mon, Jun 09, 2014 at 07:48:46PM +0400, Yury Gribov wrote:
> >>Build_check_stmt is now unified for const/variable lengths
> >>but I'd still prefer to treat the use_calls case specially
> >>because calling single __asan_loadN is more space-efficient
> >>than emitting two separate calls with a leng
Build_check_stmt is now unified for const/variable lengths
but I'd still prefer to treat the use_calls case specially
because calling single __asan_loadN is more space-efficient
than emitting two separate calls with a length check.
That is not what I meant.
1) instrument_mem_region_access/instru
> 1) instrument_mem_region_access/instrument_strlen should use a single
>build_check_stmt call instead of two that they do now,
I agree with instrument_mem_region_access but the strlen case is quite
different because checks are inserted at different sides of instrumented
insn. Adding yet mo
On Fri, Jun 06, 2014 at 09:08:17AM +0400, Yury Gribov wrote:
> Build_check_stmt is now unified for const/variable lengths
> but I'd still prefer to treat the use_calls case specially
> because calling single __asan_loadN is more space-efficient
> than emitting two separate calls with a length check
Jakub,
Here is an updated patch. I have not addressed some of the points:
> Also note (but, already preexisting issue) is that the
> __asan_report* and __asan_{load,store}* calls are declared in
> sanitizer.def as having 1st argument PTR type, while in the library
> it is uptr (aka PTRMODE). So
On Tue, Jun 3, 2014 at 1:33 PM, Yury Gribov wrote:
>> Any reason why the BUILT_IN_* names so differ from the actual function
>> names? I.e. why not use BUILT_IN_ASAN_{LOAD,STORE}{1,2,4,8,16,N}
>> (no underscore before N, no CHECK_)?
>
>
> Makes sense.
>
>> Wouldn't it be better to do
>> ...
>>
>>
On Tue, Jun 03, 2014 at 01:33:39PM +0400, Yury Gribov wrote:
> >Also note (but, already preexisting issue) is that the
> >__asan_report* and __asan_{load,store}* calls are declared in
> >sanitizer.def as having 1st argument PTR type, while in the library
> >it is uptr (aka PTRMODE). So, either we
Any reason why the BUILT_IN_* names so differ from the actual function
names? I.e. why not use BUILT_IN_ASAN_{LOAD,STORE}{1,2,4,8,16,N}
(no underscore before N, no CHECK_)?
Makes sense.
Wouldn't it be better to do
...
so that you don't risk signed overflow? Maybe also
Yeah, that looks clea
On Tue, Jun 03, 2014 at 12:03:02PM +0400, Yury Gribov wrote:
> --- a/gcc/asan.c
> +++ b/gcc/asan.c
> @@ -257,6 +257,8 @@ struct asan_mem_ref
>
> static alloc_pool asan_mem_ref_alloc_pool;
>
> +static int asan_num_accesses;
> +
> /* This creates the alloc pool used to store the instances of
>
Hi all,
This is a second try on outline Asan instrumentation (original patch:
https://gcc.gnu.org/ml/gcc-patches/2014-05/msg02194.html).
This patch adds support for replacing Asan inline checks with function
calls. This feature has been recently added to LLVM to
* reduce long compiler runtime
On Tue, May 27, 2014 at 9:39 PM, Yuri Gribov wrote:
>> Asan and kasan are very different, so it would be good to separate
>> them straight away.
>
> Do you mean separation of interfaces (i.e. have -fsanitize=address and
> -fsanitize=kernel-address but use same code in GCC to compile both
> maybe w
> Asan and kasan are very different, so it would be good to separate
> them straight away.
Do you mean separation of interfaces (i.e. have -fsanitize=address and
-fsanitize=kernel-address but use same code in GCC to compile both
maybe with different default options) or separation of
implementation
On Tue, May 27, 2014 at 9:43 AM, Konstantin Serebryany
wrote:
> On Tue, May 27, 2014 at 9:40 AM, Yury Gribov wrote:
>>> - using instrumentation via calls adds extra 1.5x-2.x slowdown
>>
>> On x64.
>
> Interesting. can you share your ARM numbers?
>
>>
>>
>>> - it would be nice to have the name pre
On 05/27/2014 09:43 AM, Konstantin Serebryany wrote:
- using instrumentation via calls adds extra 1.5x-2.x slowdown
On x64.
Interesting. can you share your ARM numbers?
That wasn't an objection - I just made sure to specify the platform (x64
ABI is somewhat special).
On Tue, May 27, 2014 at 9:40 AM, Yury Gribov wrote:
>> - using instrumentation via calls adds extra 1.5x-2.x slowdown
>
> On x64.
Interesting. can you share your ARM numbers?
>
>
>> - it would be nice to have the name prefix configurable from command
>> line (${PREFIX}_load1 instead of __asan_lo
> - using instrumentation via calls adds extra 1.5x-2.x slowdown
On x64.
> - it would be nice to have the name prefix configurable from command
> line (${PREFIX}_load1 instead of __asan_load1) because kasan uses
> different names already.
Yeah, I noticed corresponding option in LLVM. AFAIK stan
my 2c
- using instrumentation via calls adds extra 1.5x-2.x slowdown
- it indeed saves code size
- in LLVM this was done mostly to overcome the compile time problem on
huge functions
- in GCC we will indeed need this for kasan
(https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKe
On Mon, May 26, 2014 at 08:31:39PM +0400, Yury Gribov wrote:
> >>* asan_negative_params_1.diff - support for negative parameters
> >
> >I don't like this. Why do you need it?
>
> That's only for compatibility with LLVM. I know that's not usually
> considered an argument in gcc-patches but things
* asan_negative_params_1.diff - support for negative parameters
I don't like this. Why do you need it?
That's only for compatibility with LLVM. I know that's not usually
considered an argument in gcc-patches but things like this would surely
make developer's life harder.
* asan_calls_1.d
On Mon, May 26, 2014 at 07:58:17PM +0400, Yury Gribov wrote:
> This patch adds support for outline Asan instrumentation (i.e.
> function calls instead of inline checks). This has been recently
> added to LLVM to
> * reduce long compiler runtimes on large functions with huge (over
> 10K) number of m
> Making implementations more similar
> would require bigger rewrite of Asan
of GCC Asan
Hi all,
This patch adds support for outline Asan instrumentation (i.e. function
calls instead of inline checks). This has been recently added to LLVM to
* reduce long compiler runtimes on large functions with huge (over 10K)
number of memory accesses (http://llvm.org/bugs/show_bug.cgi?id=12653)
34 matches
Mail list logo
