On Thu Jul 16, 2026 at 4:16 PM CEST, Jason Merrill wrote: > On 5/4/26 7:30 AM, Josef Melcr wrote: >> Hi, >> this is a v3 of this patch (v2: >> https://gcc.gnu.org/pipermail/gcc-patches/2026-May/715612.html) >> >> Sorry about the formatting issues, formatting is the bane of my >> existence for some reason. >> >> I did not retest the patch, as I only made formatting changes. >> >> Changes in v3: >> - Fixed formatting >> >> Changes in v2: >> - Documentation tweaks suggested by Andrew >> >> This patch allows the callback attribute to be used outside of GCC under >> the name 'gnu::callback_only'. It also fixes some missing bounds checks >> in the attribute handler. The attribute is not recognized outside of >> the gnu namespace, I did this so that there is no accidental mixup with >> the LLVM callback attribute, which has different syntax. I am not great >> at user-facing documentation, I hope the docs are clear about the >> attribute's usage. Suggestions are of course welcome. >> +The @code{callback_only} attribute specifies that the annotated function may >> +call the specified callback function. The first parameter identifies the >> index >> +of the callback function, the rest of the arguments specify the indices of >> the >> +arguments of the indirect call. All indices start from 1. If the function >> takes >> +the implicit @code{this} pointer, it is referred to by the index 1, with the >> +rest of the arguments starting at index 2. The index 0 marks an argument not >> +present in the arguments of the annotated function, an argument which is >> +modified before calling the callback function. The annotated function must >> pass >> +the specified arguments in the specified order to the callback function, >> which >> +must be callable with the number, order and type of the arguments. The >> +specified pointer to the callback may not escape the translation unit of the >> +annotated function and it may not be captured. The annotated function is >> +required to pass the arguments through, it may not change or dereference >> them. >> +The arguments also may not escape. The attribute may be used multiple times >> per >> +function, though only one @code{callback_only} attribute may be used per >> +function parameter. >> + >> +The attribute exposes the potentially hidden callsite in the annotated >> +function, enabling interprocedural optimizations which may not be possible >> +without the attribute. It is most useful for annotating functions from >> +dynamically linked libraries, as their bodies are not available during >> +compilation. >> + >> +This attribute is similar to the clang @code{callback} attribute but it is >> not >> +compatible with it. The clang implementation allows identifiers as >> arguments, >> +marks an unknown argument with -1 and the @code{this} pointer with the >> index 0. > > Hmm, why not support the clang interface instead of exposing our > internal one? We wouldn't need to change the internal handling of " > callback", we could translate the clang attribute to our internal > attribute in the handle_ function. > > The clang differences described here sound preferable to me from a user > perspective.
The interface wasn't supposed to be internal, but it was made that way due to disputes around the attribute's name. The main issue with supporting clang's interface is that it's inconsistent with other attributes, in both clang and gcc. Other attributes use 1 for the 'this' pointer if it's present (e.g. format), clang's callback is the only attribute that I am aware of to use 0. I don't want to introduce this inconsistency to gcc. Best regards, Josef > > Jason
