This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.

It's not meant to be a criticism, just noting a recurring issue.

jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]