On Mon, Jun 16, 2025 at 05:49:19PM +0200, Jan Hubicka wrote: > > 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.
Sure, that works too. I just wanted to unblock the patch progress. Jakub