It would sometimes be useful to be able to assert that an expression does not have side effects. For example, this would be very nice to have for macros which expand their arguments more than once: #define multi_expand(x) __builtin_assert_no_side_effects(x) + (x) Specifically, this builtin would check its argument and give an error if the argument had an assignment or a call to a function which is neither "const" nor "pure". The builtin would evaluate to the value of its argument.
You can see the thread here: http://patchwork.ozlabs.org/patch/343858/ My proposed patch didn't handle C++, which seems like something it probably should do.
I would like to second this request, however, I would like to request that it issues a warning rather than an error. It can always be promoted to an error via -Werror= or the equivalent pragma.
Overlaps bug 6906. Under that ticket, I proposed adding a built-in that simply returns whether or not a given expression has side effects, simply by exposing TREE_SIDE_EFFECTS(). This more general built-in could also (partially) address bug 79469, by allowing to define __builtin_assume as #define __builtin_assume(cond) do { \ if (__builtin_pure_p(cond)) \ if (!(cond)) \ __builtin_unreachable(); \ } while (0) Partially, because e.g. if A has side effects, then with the definition above __builtin_assume(A && B) would consider the whole condition to have side effects as well, and therefore disregard it, even if B could potentially be mined for optimisation opportunities.
(In reply to H. Peter Anvin from comment #2) > I would like to second this request, however, I would like to request that > it issues a warning rather than an error. It can always be promoted to an > error via -Werror= or the equivalent pragma. What's the use case for this? It seems simpler to just not use this macro when you don't want the effect. (In reply to felix from comment #3) > Overlaps bug 6906. Under that ticket, I proposed adding a built-in that > simply returns whether or not a given expression has side effects, simply by > exposing TREE_SIDE_EFFECTS(). This seems the same to me, in that __builtin_assert_no_side_effects could, I think, just be a static_assert using your builtin.