[C/C++] Allow __atomic_always_lock_free in a static assert (PR c/62024)

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.

The tests require sync_char_short target in a hope they aren't run
on targets where the static assert would actually trigger.

Bootstrapped/regtested on x86_64-linux, ok for trunk?

2014-08-25  Marek Polacek  <polacek@redhat.com>

	PR c/62024
c/
	* c-parser.c (c_parser_static_assert_declaration_no_semi): Strip no-op
	conversions.
cp/
	* semantics.c (finish_static_assert): Strip no-op conversions.
testsuite/
	* g++.dg/cpp0x/pr62024.C: New test.
	* gcc.dg/pr62024.c: New test.


	Marek

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.

On 08/25/2014 07:43 AM, Marek Polacek wrote:
> 	* semantics.c (finish_static_assert): Strip no-op conversions.

I think I'd rather strip these in cxx_eval_builtin_function_call so that 
we don't have to deal with them in various consumers.

Jason

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