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

Reply via email to