On Wed, Jun 23, 2021 at 9:25 PM Andrew MacLeod <[email protected]> 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
> > <[email protected]> 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?)
So yes, you could argue that
if (type == NULL_TREE)
{
gcc_assert (gimple_call_internal_p (gs));
tree lhs = gimple_call_lhs (gs);
return lhs ? TREE_TYPE (lhs) : void_type_node;
}
would make gimple_call_return_type more robust. But then I wonder
why the function exists in the first place ;) I suppose like gimple_expr_type
it's one of those I'd eventually see to go away.
Richard.
> Andrew
>
>
