Hi On 10/14/25 22:55, Jakub Jelinek wrote:
I am not too sure honestly. I agree that aggregates would be weird and pointers/refs will be the most common use case anyway, but the restriction feels arbitrary. We can't give any optimization guarantees anyway, so we might as well allow aggregates, worst case scenario is that nothing happens. We could issue a note to the user that recommends passing a pointer to an aggregate rather than the aggregate itself, but that would probably get annoying pretty quickly.On Tue, Oct 14, 2025 at 10:46:19PM +0200, Josef Melcr wrote:Perhaps the GNU attribute could specify both? Arguments 2, 4 would mean fnptr is 2nd argument and its 1st argument is 4th, so foo (1, fn, 2, &s) calls fn (&s). And 2, 6, 5, 4 means foo (1, fn, 2, &s, &t, &u) calls fn (&u, &t, &s). 0 is not a valid argument index, so that could be used as a separator to where to map those arguments if not to 1-(nargs-1). So, 2, 6, 5, 4, 0, 2, 4, 3 would mean foo (1, fn, 2, &s, &t, &u) calls fn (?, &u, &s, &t). I.e. 2, 4 would be equivalent to 2, 4, 0, 1 and 2, 6, 5, 4 equivalent to 2, 6, 5, 4, 0, 1, 2, 3.Is that necessary? Currently, 0 serves as a marker for an unknown argument, the mapping is determined by the order. So fn (?, &u, &s, &t) is 2, 0, 6, 5, 4; the call in qsort_r would be 4, 0, 0, 5 and so on. I very well might be missing something, but I am not sure there is an advantage to stating the mapping explicitly, which makes it in my opinion less readable.Shall it require that the non-unknown arguments have pointer/reference types, or pointer/reference or scalar, or anything? I think it might be useful to propagate even scalars like int, but propagating aggregates (rather than pointers/references to aggregates) would be hard/weird.
Jakub
Best regards, Josef
