https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114309
--- Comment #11 from M Welinder <terra at gnome dot org> ---
> Anyway, in GCC's testcase we have:
>
> 9 if (a == 123)
> 10 [[likely]] c = 5; // { dg-warning "both" }
> 11 else
> 12 [[likely]] b = 77;
> Here we have two possible paths, and the attributes tell the compiler that the
> first is more likely than the second, and the second is more likely than the
> first. Obviously that's suspicious.
That interpretation is contrary to the C++ standard.
Ok, so I don't actually have the final standard but here's the proposed
wording: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0479r5.html
"Note: The use of the likely attribute is intended to allow implementations to
optimize for the case where paths of execution including it are arbitrarily
more likely than any alternative path of execution that does not include such
an attribute on a statement or label."
The use of "[[likely]]" in the above example therefore does not say that either
branch is more likely than the other. Since both paths of execution include
"[[likely]]" the standard has no opinion on the matter.
"[[likely]]" and "[[unlikely]]" are not a perfect fit with the old
"builtin_expect". They are more expressive and not tied to "if":
{
[[likely]] foo();
[[unlikely]] bar();
}
No "if" in sight, yet this tells us that foo is likely to be called, but that
it is unlikely to return normally.
Unrelatedly, the do-while work-around is fine for the simplified case I posted.
It won't work in the much more complicated case where this comes from because
that hairy macro allows printing extra information:
barf("foo") << something << " and " << something_else;
