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
