On Fri, Jun 12, 2020 at 2:31 AM Segher Boessenkool <seg...@kernel.crashing.org> wrote: > > 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?
It "worked" before because GIMPLE IL checking is not strict here because of too many existing "bugs" like this. Well, quite a few years ago at least. Richard. > Thanks, > > > Segher
