[corysama]

These annotations are really only of interest in performance-critical computations. It’s another knob for library writers to use to make the libraries you use magically faster for their users. And, should be quite rare outside of libraries.

[pjmlp]

And even then they should be handled with extreme care, as they can trigger UB if used incorrectly.

[uglycoyote]

Compilers have always been making guesses about what the most likely code path is behind the scenes, but it still needs to behave correctly in the case where it was wrong (that will just be the less-optimal code path). All these attributes are doing is helping the compiler know instead of guess what the hot path is. if there is any way to confuse the compiler into giving undefined behavior with hints like this, that's a compiler bug. (not saying compiler bugs don't exist, but are you aware of a specific bug like this)?

[Leherenn]

Do you have examples? It's not clear from the article how you could have a UB with them.

[pjmlp]

If I remember correctly, Timur Doumler does some remarks on that sense on his presentation:

"Standard Attributes in C and C++"

https://youtu.be/TDKqAWtvH9c?si=b5quQkMe7XUvBbG7

[fluoridation]

Could you least give some timestamps? It's nearly two hours.

Anyway, while it is possible that some attributes can cause UB if misused, I very much doubt that's possible with [[likely]] and [[unlikely]], as they are just hints for the optimizer, and the optimizer is supposed to preserve semantical guarantees.

[plorkyeran]

Some attributes can cause UB (most obviously [[unreachable]] in a spot that's reachable), but [[likely]] and [[unlikely]] can't.