[PATCH] guard against calls with fewer arguments than the function type implies (PR 95581)

[Segher Boessenkool]

On Tue, Jun 09, 2020 at 09:51:12AM -0600, Martin Sebor wrote:
> >I think the backend declaration is wrong, the function only takes
> >a void * argument and returns a long.
> 
> Thanks.  In his comment on the bug Segher (CC'd) points to
> the internals manual that documents the function:
> 
> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/target.def;h=07059a87caf7cc0237d583124b476ee45ea41ed5;hb=HEAD#l1744
> 
> (By the way, thanks for the pointer!)
> 
> If I read it right, ihe function f in
> the TARGET_VECTORIZE_BUILTIN_MASK_FOR_LOAD documentation is
> __builtin_altivec_mask_for_load.  Although the manual isn't
> unequivocal about this but it does suggest the address addr
> the function is given as an argument should be the first
> (and presumably only) argument.  This matches the call in
> the IL where the first argument is a pointer, but not
> the function's signature.
> 
> I think the middle end needs to be able to rely on built-in
> function types when processing calls: i.e., the types and
> numbers of actual arguments in the calls need to match those
> of the built-in function type.  Otherwise it would have to
> validate every call against the function signature and avoid
> treating it as a built-in if it doesn't match.  There are
> parts of the middle end that do that for library built-ins
> (because they can be declared in a program with mismatched
> signatures) but as we have seen it's error-prone.  I don't
> think it would be helpful to try to extend this approach to
> internal built-ins.
> 
> So I agree that the real problem is the declaration of
> the built-in.

The problem is that this altivec builtin cannot implement the generic
builtin directly.  It should *not* be changed, we *do* need to keep
this builtin as-is.  We just cannot forward the generic builtin to it
like this.

Why did this work before, and not anymore?  That sounds like a missing
or broken test?

Thanks,


Segher