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
22 matches
Mail list logo