RE: [PATCH] Fix Cilk+ ICEs in the alias oracle

[Richard Biener <rguenther@suse.de>]

On Fri, 14 Feb 2014, Iyer, Balaji V wrote:

> 
> 
> > -----Original Message-----
> > From: Jeff Law [mailto:law@redhat.com]
> > Sent: Friday, February 14, 2014 12:34 PM
> > To: Richard Biener; gcc-patches@gcc.gnu.org
> > Cc: Iyer, Balaji V
> > Subject: Re: [PATCH] Fix Cilk+ ICEs in the alias oracle
> > 
> > On 02/13/14 05:47, Richard Biener wrote:
> > > On Thu, 13 Feb 2014, Richard Biener wrote:
> > >
> > >>
> > >> Cilk+ builds INDIRECT_REFs when expanding builtins (oops) and thus
> > >> those can leak into MEM_EXRs which will lead to ICEs later.
> > >> The following patch properly builds a MEM_REF instead.  Grepping for
> > >> INDIRECT_REF I found another suspicious use (just removed, it cannot
> > >> have triggered and it looks bogus) and the use of a langhook instead
> > >> of proper GIMPLE interfaces (function also used during expansion).
> > >>
> > >> Bootstrap / testing in progress together with some other stuff.
> > >>
> > >> Ok?
> > >
> > > Btw, this exposes that Cilk+ is LTO-ignorant - it doesn't properly
> > > register its global trees (bah, more global trees...).  So the
> > > types_compatible_p call ICEs.  Trying to process them in
> > > lto/lto.c:read_cgraph_and_symbols doesn't seem to work though.
> > >
> > > So I'm opting to remove the assert and leave fixing LTO for somebody
> > > who cares about Cilk+.
> > >
> > > Simpifies the patch as follows, bootstrapped & tested on
> > > x86_64-unknown-linux-gnu.
> > >
> > > Richard.
> > >
> > > 2014-02-13  Richard Biener  <rguenther@suse.de>
> > >
> > > 	* cilk-common.c (cilk_arrow): Build a MEM_REF, not an
> > INDIRECT_REF.
> > > 	(get_frame_arg): Drop the assert with langhook
> > types_compatible_p.
> > > 	Do not strip INDIRECT_REFs.
> > FWIW, I see a recurring issue here.  Specifically I'm regularly seeing
> > cases where submissions are not playing well with LTO.   Speaking
> > strictly for myself, I'm not LTO-aware enough to spot them in patches as they
> > fly by.
> 
> I thought I had handled LTO correctly. I apologize if I made a mistake. 
> I assure you that it was not deliberate. I even had my tests use -flto 
> flags to make sure it is going through it correctly...

By using the langhook types_compatible_p you by-passed the failure
on LTO (because that langhook is not implemented there).

As it's only builtins expansion the mismatches don't really matter.

Richard.