On Fri, Aug 1, 2014 at 9:17 AM, Jakub Jelinek wrote:
> On Mon, Jul 28, 2014 at 06:14:08PM +0400, Yury Gribov wrote:
>> On 07/24/2014 11:48 AM, Jakub Jelinek wrote:
>> > So, either support for just EAF*, or perhaps support for DECL_ATTRIBUTES
>> > for internal-fns, say by having some tree array whe
On Mon, Jul 28, 2014 at 06:14:08PM +0400, Yury Gribov wrote:
> On 07/24/2014 11:48 AM, Jakub Jelinek wrote:
> > So, either support for just EAF*, or perhaps support for DECL_ATTRIBUTES
> > for internal-fns, say by having some tree array where you'd store what you
> > stick into DECL_ATTRIBUTES norm
On 07/24/2014 11:48 AM, Jakub Jelinek wrote:
> So, either support for just EAF*, or perhaps support for DECL_ATTRIBUTES
> for internal-fns, say by having some tree array where you'd store
what you
> stick into DECL_ATTRIBUTES normally.
I'd prefer to avoid attributes. Would something like this b
On Thu, Jul 24, 2014 at 10:21:14AM +0400, Yury Gribov wrote:
> On 07/24/2014 12:09 AM, Jakub Jelinek wrote:
> >>Ah internal fns. Those cannot have attributes indeed (technical
> >>limitation).
> >>Martin was working on putting those flags elsewhere (cgraph, though internal
> >>functions don't
On 07/24/2014 12:09 AM, Jakub Jelinek wrote:
Ah internal fns. Those cannot have attributes indeed (technical
limitation).
Martin was working on putting those flags elsewhere (cgraph, though internal
functions don't have cgraph nodes either ...). Maybe it was a bad idea to use
internal funct
On Tue, Jul 22, 2014 at 04:20:04PM +0200, Richard Biener wrote:
> On Tue, Jul 22, 2014 at 4:15 PM, Yury Gribov wrote:
> > On 07/22/2014 05:57 PM, Richard Biener wrote:
> >>>
> >>> I probably could
> >>> provide fnspec with (EAF_DIRECT | EAF_NOCLOBBER | EAF_NOESCAPE) or
> >>> even EAF_UNUSED for th
On 07/22/2014 12:27 PM, Yury Gribov wrote:
Attached patch delays generation of Asan memory checking
code until sanopt pass.
Here is an updated patch based on Jakub's review.
Bootstrapped and regtested on x64.
Yet another version with ASAN_CHECK changed to builtin function
(instead of internal
On 07/22/2014 05:57 PM, Richard Biener wrote:
I probably could
provide fnspec with (EAF_DIRECT | EAF_NOCLOBBER | EAF_NOESCAPE) or
even EAF_UNUSED for these functions but this does not seem
to be supported in current middle-end.
Simply add the "fn spec" attribute to the functions?
Problem is t
On Tue, Jul 22, 2014 at 4:15 PM, Yury Gribov wrote:
> On 07/22/2014 05:57 PM, Richard Biener wrote:
>>>
>>> I probably could
>>> provide fnspec with (EAF_DIRECT | EAF_NOCLOBBER | EAF_NOESCAPE) or
>>> even EAF_UNUSED for these functions but this does not seem
>>> to be supported in current middle-e
On Fri, Jul 18, 2014 at 3:36 PM, Yury Gribov wrote:
> Hi all,
>
> Attached patch delays generation of Asan memory checking code
> until sanopt pass. This is a first step towards global static analysis
> of Asan instrumentation which would allow to
> * remove redundant instrumentations
> * aggregat
> Attached patch delays generation of Asan memory checking
> code until sanopt pass.
Here is an updated patch based on Jakub's review. Bootstrapped and
regtested on x64.
-Y
commit 7c371a6f462e166d3f2ad89afbe2e61b1a0b799b
Author: Yury Gribov
Date: Thu Jul 17 09:45:26 2014 +0400
Move inl
On Sat, Jul 19, 2014 at 1:31 PM, Jakub Jelinek wrote:
> On Fri, Jul 18, 2014 at 10:21:16PM +0400, Yuri Gribov wrote:
> Sounds like a bug, most likely in the lim pass. If it for some reason
> decides to load from possibly uninitialized memory before the loop, it
> better should make sure TREE_NO_W
On Fri, Jul 18, 2014 at 10:21:16PM +0400, Yuri Gribov wrote:
> On Fri, Jul 18, 2014 at 9:23 PM, Jakub Jelinek wrote:
> > On Fri, Jul 18, 2014 at 08:42:35PM +0400, Yuri Gribov wrote:
> >> > Uh. Can you please explain this? That sounds weird.
> >>
> >> Sure, this caused maybe-uninitialized warning
On Fri, Jul 18, 2014 at 9:23 PM, Jakub Jelinek wrote:
> On Fri, Jul 18, 2014 at 08:42:35PM +0400, Yuri Gribov wrote:
>> > Uh. Can you please explain this? That sounds weird.
>>
>> Sure, this caused maybe-uninitialized warnings with iterator during
>> bootstrap. It turned out that *bb_seq_addr (b
> For formatting, can you please just replace 8 spaces with tabs
> in the ^+ lines in the patch?
Sorry, I thought I cleared all these out but looks like I indeed
missed some whites. I should probably take some time and finally setup
my editor to do this.
> Can you avoid using // comments in code
On Fri, Jul 18, 2014 at 05:36:30PM +0400, Yury Gribov wrote:
> The patch was bootstrapped, regtested and asan-bootstrapped on x64.
Thanks for working on this.
For formatting, can you please just replace 8 spaces with tabs
in the ^+ lines in the patch?
sed '/^+/s//\t/g' or so.
Can you avoi
Hi all,
Attached patch delays generation of Asan memory checking code
until sanopt pass. This is a first step towards global static analysis
of Asan instrumentation which would allow to
* remove redundant instrumentations
* aggregate adjacent Asan checks
* move invariant checks from loops
The pa
17 matches
Mail list logo