On Fri, Nov 14, 2014 at 01:06:52PM +0100, Dodji Seketeli wrote:
> Jakub Jelinek writes:
>
> >> I am not sure, but I am wondering if we shouldn't save the previous uid
> >> of 'stmt' here before setting it, and then restore it before getting out
> >> of this function.
> >
> > No, gimple uids are A
On Fri, Nov 14, 2014 at 01:16:36PM +0100, Richard Biener wrote:
> > That would be indeed nice (similarly for other stuff that we expect to be
> > undefined on pass boundaries, or expect to be in certain state at pass
> > boundaries; in the former case set before uses, and don't care about what
> >
On Fri, 14 Nov 2014, Jakub Jelinek wrote:
> On Fri, Nov 14, 2014 at 01:06:52PM +0100, Dodji Seketeli wrote:
> > Jakub Jelinek writes:
> >
> > >> I am not sure, but I am wondering if we shouldn't save the previous uid
> > >> of 'stmt' here before setting it, and then restore it before getting out
On Fri, Nov 14, 2014 at 01:06:52PM +0100, Dodji Seketeli wrote:
> Jakub Jelinek writes:
>
> >> I am not sure, but I am wondering if we shouldn't save the previous uid
> >> of 'stmt' here before setting it, and then restore it before getting out
> >> of this function.
> >
> > No, gimple uids are A
Jakub Jelinek writes:
>> I am not sure, but I am wondering if we shouldn't save the previous uid
>> of 'stmt' here before setting it, and then restore it before getting out
>> of this function.
>
> No, gimple uids are AFAIK undefined at the start of passes, passes that use
> them are supposed to
On Fri, Nov 14, 2014 at 12:25:37PM +0100, Dodji Seketeli wrote:
> > + /* True if there is a block with HAS_FREEING_CALL_P flag set
> > + on any a path between imm(BB) and BB. */
>
> s/a//.
>
> Also, I'd rather say "on any path between an immediate dominator of
> BB, denoted imm(BB), and BB"
Jakub Jelinek writes:
> On Wed, Nov 12, 2014 at 02:09:59PM +0300, Yury Gribov wrote:
> > >For asan you're right, we can have addresses of decls there etc.
> > >If you have spare cycles, feel free to take over the patch and adjust it.
> >
> > I guess I'd wait when this gets to trunk?
>
> Ok, in
On Wed, Nov 12, 2014 at 02:09:59PM +0300, Yury Gribov wrote:
> >For asan you're right, we can have addresses of decls there etc.
> >If you have spare cycles, feel free to take over the patch and adjust it.
>
> I guess I'd wait when this gets to trunk?
Ok, in that case I've bootstrapped/regtested
On 11/12/2014 01:34 PM, Jakub Jelinek wrote:
On Wed, Nov 12, 2014 at 12:18:31PM +0300, Yury Gribov wrote:
--- gcc/sanopt.c.jj 2014-11-11 09:13:36.698280115 +0100
+++ gcc/sanopt.c2014-11-11 18:07:17.913539517 +0100
@@ -49,6 +49,7 @@ along with GCC; see the file COPYING3.
#include "l
On Wed, Nov 12, 2014 at 12:18:31PM +0300, Yury Gribov wrote:
> >--- gcc/sanopt.c.jj 2014-11-11 09:13:36.698280115 +0100
> >+++ gcc/sanopt.c 2014-11-11 18:07:17.913539517 +0100
> >@@ -49,6 +49,7 @@ along with GCC; see the file COPYING3.
> > #include "langhooks.h"
> > #include "ubsan.h"
> > #
On 11/11/2014 08:42 PM, Jakub Jelinek wrote:
On Wed, Nov 05, 2014 at 11:50:20AM +0100, Jakub Jelinek wrote:
On Wed, Nov 05, 2014 at 11:29:19AM +0100, Marek Polacek wrote:
On Wed, Nov 05, 2014 at 12:54:37PM +0300, Yury Gribov wrote:
Are you going to work on ASan soon? I could rebase my patches
On Wed, Nov 05, 2014 at 11:50:20AM +0100, Jakub Jelinek wrote:
> On Wed, Nov 05, 2014 at 11:29:19AM +0100, Marek Polacek wrote:
> > On Wed, Nov 05, 2014 at 12:54:37PM +0300, Yury Gribov wrote:
> > > Are you going to work on ASan soon? I could rebase my patches on top of
> > > Marek's infrastructur
12 matches
Mail list logo
