[RFC] Return NULL from gimple_call_return_type if no return available.

Andrew MacLeod amacleod@redhat.com
Thu Jun 24 13:31:13 GMT 2021

On 6/24/21 5:07 AM, Richard Biener wrote:
> On Wed, Jun 23, 2021 at 9:25 PM Andrew MacLeod <amacleod@redhat.com> wrote:
>> On 6/23/21 2:37 PM, Richard Biener via Gcc-patches wrote:
>>> On June 23, 2021 5:03:05 PM GMT+02:00, Aldy Hernandez via Gcc-patches <gcc-patches@gcc.gnu.org> wrote:
>>>> The call to gimple_call_fntype() in gimple_call_return_type() may
>>>> return
>>>> NULL, which causes the TREE_TYPE(lhs) to ICE.  I think it would be best
>>>> to
>>>> return NULL (or void_type_node) rather than aborting.
>>>> I'm running into this because fold_using_range::range_of_call, calls
>>>> gimple_call_return_type which may ICE for builtins with no LHS.
>>>> Instead
>>>> of special casing things in range_of_call, perhaps it's best to plug
>>>> the
>>>> source.
>>>> Does this sound reasonable?
>>> No, you need to make sure to not call this on an internal function call instead.
>>> Otherwise it is never NULL.
>>> Richard.
>> Out of curiosity, why is it not OK to call this on an internal function
>> call?   Shouldn't all calls return something at least? like VOIDmode if
>> they don't return anything?  It just seems like it needs to be special
>> cased either at any possible call site, or simply in the routine.   we
>> stumbled across it and it wasn't obvious why.
> Well, gimple_call_fntype simply returns NULL because internal functions
> do not have any API/ABI.  So you either deal with a NULL return value
> but then explicitely checking for an internal function call is clearly better
> from a source documentation point of view.
> I think the existing type == NULL check was likely added to avoid touching
> too much code and we somehow didn't think of internal function calls
> w/o a LHS (but why are you asking for the return type for a call w/o LHS?)

We'll still compute values for statements that don't have a LHS.. 
there's nothing inherently wrong with that.  The primary example is

if (x_2 < y_3)

we will compute [0,0] [1,1] or [0,1] for that statement, without a LHS.  
It primarily becomes a generic way to ask for the range of each of the 
operands of the statement, and process it regardless of the presence of 
a LHS.  I don't know, maybe there is (or will be)  an internal function 
that doesn't have a LHS but which can be folded away/rewritten if the 
operands are certain values.


More information about the Gcc-patches mailing list