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
