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/16/2014 12:23 PM, Jakub Jelinek wrote:
2014-06-11 Yury Gribov y.gri...@samsung.com
New asan-instrumentation-with-call-threshold parameter.
Ok, thanks.
Done in r211699.
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
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
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 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
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't know that
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 to
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
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 round of review.
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 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 length check.
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
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)
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
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,
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
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
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
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 should
On Tue, Jun 3, 2014 at 1:33 PM, Yury Gribov y.gri...@samsung.com 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
22 matches
Mail list logo
