In which cases does __sync_synchronize receive any arguments?

Question

TheGCC documentation about __sync builtins lists __sync_synchronize as:

__sync_synchronize (...)

This built-in function issues a full memory barrier.

Which is meant to signify a variadic function (taking any number of arguments), but without a mandatory first argument, which is not even syntactically allowed in the C standard; in any case, assuming it can run away with it because it's a compiler builtin, I'd like to know: is there any case at all in which this function receives arguments ?

The GCC documentation above explains why the ... are present:

All of the routines are described in the Intel documentation to take “an optional list of variables protected by the memory barrier”. It's not clear what is meant by that; it could mean that only the listed variables are protected, or it could mean a list of additional variables to be protected. The list is ignored by GCC which treats it as empty. GCC interprets an empty list as meaning that all globally accessible variables should be protected.

For a full memory barrier, it makes sense to write nothing inside.

I tried googling for it (eg this website contains 30 usage examples ), looking at the Stack Overflow questions containing the builtin, and using Github's code search, and I couldn't find a single call of __sync_synchronize with arguments passed to it.

So, if I want to support the builtin in a tool, it seems I could simply treat it as if it were declared as __sync_synchronize(void) , and it would always work.

Is there a legitimate case where one might want to pass an argument to that builtin?

Answer 1

You have in a way self-answered. I think the bit of information you are missing is that builtins are not real functions and their arguments may not be passed anywhere or even evaluated. The compiler will generate some code when you use it, but the builtin may not be a proper callable function.

Those are not arbitrary arguments, that was really supposed to be a list of variables (not, eg expressions). Which may have had some mysterious function in an Intel compiler, but gcc will happily ignore. gcc probably kept the same signature to maintain compatibility with some existing code.

Builtins may do strange stuff to their apparent arguments, like "Neither argument is evaluated." or "the built-in function does not evaluate the expression that is not chosen".