On Wed, Aug 27, 2014 at 05:59:17PM +0000, Joseph S. Myers wrote:
> 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?
Yes. This NOP_EXPR can naturally also carry a location.
> 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.
Exactly. In this particular patch I've tried to limit this to
_Static_assert only.
Thanks,
Marek
