Hi!
On Thu, Mar 09, 2023 at 07:24:58PM -0600, Peter Bergner wrote:
> On 3/9/23 8:55 AM, Segher Boessenkool wrote:
> >> Nit: Maybe we can build them out of the loop once and then just use the
> >> built one in the loop.
> >
> > Or as globals even. Currently we have X and pointer to X, but no
> > pointer to const X (and no const X either, but that isn't so useful).
> >
> > The generic code doesn't have this either, hrm.
>
> I can have a look at that, but was trying to keep the change as small
> as possible.
Yup, just thinking out loud here, not asking for one way or the other.
> Especially since we're not trying to create code that
> will be "easier" to maintain in the future, because this is all changed
> in GCC12 with Bill's builtin re-write.
Yes :-)
> >> Simply testing __builtin_mma_xxmtacc and __builtin_mma_xxmfacc as below:
> >>
> >> $ cat test.C
> >> void foo0(const __vector_quad *acc) {
> >> __builtin_mma_xxmtacc(acc);
> >> __builtin_mma_xxmfacc(acc);
> >> }
> >>
> >> test.C:2:25: error: invalid conversion from ‘const __vector_quad*’ to
> >> ‘__vector_quad*’ [-fpermissive]
> >> 2 | __builtin_mma_xxmtacc(acc);
> >>
> >> test.C:3:25: error: invalid conversion from ‘const __vector_quad*’ to
> >> ‘__vector_quad*’ [-fpermissive]
> >> 3 | __builtin_mma_xxmfacc(acc);
> >>
> >> They also suffered the same error on gcc11 branch but not on trunk.
> >
> > Yeah, there is more to be done here.
>
> Well I'm sure there are non-MMA builtins that have the same issue.
Certainly. And if this is only for MMA and it is fixed in 12, then we
can just not deal with it and hope it will work out fine (there are few
users of MMA after all).
> I was just fixing the ones Chip ran into and similar builtins.
> I don't think we want to go and make everything work like it does
> on trunk, especially when no one has complained about hitting
> them.
Right, but we should always (not just here) consider if similar problems
will happen in similar cases. Deciding we don't want to fix this is
just fine, but it helps to have some reasoning behind that.
> I'm not a language lawyer and I don't play one on TV. What we're accepting
> here, is a pointer with a "const" value that points to non-const memory.
Which is perfectly fine. And having a non-const pointer to const data
is fine even (but may well warn)! Trying to actually modify const data
is not.
This is in C; things are different in C++ of course. Evereything is
different in C++.
> I'll double check the trunk code, but I don't think it allows (and we don't
> want it to) using a pointer (const or non-const) that points to a const memory
> ...at least for the stxvp builtin.
That is invalid, sure.
Segher
