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 PR ipa/64813


On Wed, Feb 11, 2015 at 1:46 PM, Martin LiÅka <mliska@suse.cz> wrote:
> On 02/10/2015 05:00 PM, Jakub Jelinek wrote:
>>
>> On Tue, Feb 10, 2015 at 04:56:40PM +0100, Martin LiÅka wrote:
>>>
>>> On 02/10/2015 01:50 PM, Richard Biener wrote:
>>>>
>>>> On Tue, Feb 10, 2015 at 12:07 PM, Martin LiÅka <mliska@suse.cz> wrote:
>>>>>
>>>>> Hello.
>>>>>
>>>>> Following patch is fix for PR ipa/64813. The patch was tested on a
>>>>> darwin
>>>>> target
>>>>> by Dominique.
>>>>>
>>>>> Ready for trunk?
>>>>
>>>>
>>>> -      if (!(gimple_call_flags (call) & ECF_NORETURN))
>>>> +      if (!alias_is_noreturn)
>>>>
>>>> that was technically unnecessary, right?  The call flags properly
>>>> return ECF_NORETURN already?
>>>>
>>>> Ok if that is the case.
>>>
>>>
>>> Hi.
>>>
>>> You are right, !(gimple_call_flags (call) & ECF_NORETURN) returns a
>>> correct value.
>>> Motivation for replacement is not to repeat the same condition, I hope
>>> the value
>>> of alias_is_noreturn is correct in all uses.
>>
>>
>> And gimple_call_flags (call) & ECF_NORETURN doesn't?  I mean, if you could
>> initialize alias_is_noreturn to that, it would be nicer.
>>
>>         Jakub
>>
>
> Hello.
>
> There are actually 3 places I need to guard if a function non-return.
> First place is responsible for result type creation:
>
>       /* Build call to the function being thunked.  */
>       if (!VOID_TYPE_P (restype) && !alias_is_noreturn)
>
> Where I can create guard just based on TREE_THIS_VOLATILE of the called
> function.
> Once the new gimple call is created I can use:
>
> (gimple_call_flags (call) & ECF_NORETURN
>
> So that's the reason I create one bool value (alias_is_noreturn) and the
> very
> beginning of expand_thunk method. Dost it make sense?

Yes, and I think your patch is ok.

Thanks,
Richard.

> Thanks,
> Martin


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