Re: [patch] Fix PR tree-optimization/47056

[Richard Guenther <richard dot guenther at gmail dot com>]

2011/1/4 Jan Hubicka <hubicka@ucw.cz>:
>> 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.

We print &function-decl as just function-decl to confuse us ;)  (because
of calls I guess)

Richard.

>
> Honza
>