> On Wed, Apr 30, 2025 at 08:56:57AM +0200, Jakub Jelinek wrote: > > On Mon, Apr 28, 2025 at 07:27:31PM +0200, Josef Melcr wrote: > > > As for the attribute, I am honestly not too sure about what to do, as > > > clang > > > is > > > not consistent in with its own indexing, be it with the unknown values, or > > > with > > > 'this'. I've tried to remain consistent with GCC's indexing style. I guess > > > I'll > > > leave up to you and the other maintainers to decide. I can implement > > > clangs > > > version 1:1, put the attribute in our namespace or rename it. I don't mind > > > either way. Another option would be to patch clang to get in line with the > > > rest > > > of its attributes. It seems like the best option to me, as it would make > > > being > > > consistent way easier, but it would be problematic, as all code using this > > > attribute would need to be updated. > > > > I'll talk to C/C++ FE maintainers what they think. > > No progress there so far. > > Could you perhaps split the attribute side of the patch off and submit > something that only handles a few OpenMP/OpenACC builtins for now without > that attribute, instead of testing for the attribute test for specific > builtins? We can go similar direction as with fnspec. Calling it " callback" with the extra space so it is not user visible but can be used to annotate builtins and once we agree on user facing interface make it public.
Most of the infrastructure is not going to change no matter what variant we opt for. Concering the bigger picture. Josef wrote very nice bachelor thesis which is will have defense this Thursday. I think after that it will be available on dspace.cvut.cz. Overall callback attribute seems to be a natural solution for the problem at hand. Josef introduced it without knowing bout the clang equivalent and I can hardly imagine solving the problem at hand differently. There is plan to work more on this infrastructure - I think being able to understnad side-effects of openMP kernels may be quite important for optimizing openMP heavy high-level code. In longer turn, It would be also nice to handle C++ member points and std::function in similar fashion, but the second is much harder, since std::function internals are quite complex. The situation that clang already has attribute with somewhat broken interface which is does not seem to use for optimization is unfortunate. I think having gnu::callback with (subtly) different semantcs than clang::callback may get bit confusing and is not friendly to __attribute__ syntax. So perhaps coming with altenrative name is a good idea. All I can come with is gnu::callback_only. The attribute also promises that the function pointer passed is not used in an other way (such as address compasion) so this may be just bit more spefic name of what it means... We can then point out the difference in documentation and perhaps also implement clang::callback that honors clang's broken interface. I guess it is simlar to GNU versus CUDA like vectors clang already has wehre similarly named attributes have a different semantics. Honza
