This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] Fix PR tree-optimization/47056
> On Tue, Jan 4, 2011 at 1:03 PM, Eric Botcazou <ebotcazou@adacore.com> wrote:
> > Hi,
> >
> > this is the link failure of 10 ACATS tests on IA64/Linux. ?The problem is that
> > reachability analysis fails to see that some functions are needed because
> > they are referenced in the code. ?More precisely, CCP turns:
> >
> > ?pr47056___alignment.46_308 = pr47056___alignment;
> > ?D.2264_309 = MEM[(struct ?*)pr47056___alignment.46_308].D.227;
> >
> > into
> >
> > ?D.2264_309 = MEM[(struct ?*)pr47056___alignment].D.227;
> >
> > (pr47056___alignment being a function) and while walk_stmt_load_store_addr_ops
> > recognizes the former as an address-of pattern (the & is implicit for
> > functions), it doesn't for the latter (unlike for TARGET_MEM_REF) so
>
> Yeah, the TARGET_MEM_REF thing looks from before the MEM_REF
> merge. It shouldn't recognize it as an address either.
>
> > build_cgraph_edges is fooled and missed the reference to pr47056___alignment.
> >
> > The attached patch adds a specific kludge to mark_load for this case. ?It also
> > removes bogus ATTRIBUTE_UNUSED markers and makes mark_store pass the STMT to
> > ipa_record_reference like the 2 other functions (mark_load and mark_address).
> >
> > It passed regression testing on x86. ?OK after a complete testing cycle?
>
> I don't know if manipulating the descriptor would count effectively as
> an address-taking of the function. Maybe Honza can comment. Otherwise
> the patch is ok.
Hi,
I am having problems to parse the gimple. pr47056___alignment is function
and MEM[(struct | *)pr47056___alignment].D.227 is read from the function's text
(i.e. something quite underfined?).
If it is so, then indeed this should count as address taken in cgraph sense.
Honza