On Mon, 25 Aug 2014, Marek Polacek wrote: > PR62024 reports that we can't use __atomic_always_lock_free in > a static assert, as the FEs say it's not a constant expression. Yet the > docs say that the result of __atomic_always_lock_free is a compile time > constant. > We can fix this pretty easily. While fold folds __atomic_always_lock_free > to a constant, that constant is wrapped in NOP_EXPR - and static assert > code is unhappy. > I think we can just STRIP_TYPE_NOPS - we don't expect an lvalue in the > static assert code. This is done in both C and C++ FEs. What do you think? > In C, we'd still pedwarn on such code, and in C++ we'd still reject > non-constexpr functions that are not builtin functions.
Is this NOP_EXPR (for C) the one left by c_fully_fold to carry TREE_NO_WARNING information? If so, the C front-end part of this patch is OK, but at least in principle this issue could affect various other places that give a pedwarn-if-pedantic for something that's not an integer constant expression but folds to one. -- Joseph S. Myers jos...@codesourcery.com