In this commit http://gcc.gnu.org/viewcvs/gcc/trunk/gcc/cp/parser.c?r1=197248&r2=197247&pathrev=197248 the first diff (line 4109 of c/parser.c) fixed a problem where the return value from finish_parenthesized_expr() was discarded. As a side effect, this small program: #include <boost/regex.hpp> const boost::regex e("AB"); produces these diagnostics with gcc -std=c++1y and Boost 1.55: llc[45]$ /usr/local/gcc/bin/g++ --version g++ (GCC) 4.9.0 20140104 (experimental) Copyright (C) 2014 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. llc[46]$ /usr/local/gcc/bin/g++ -std=c++1y -c /tmp/bre.cc In file included from /usr/local/gcc-20140104/include/boost/regex/v4/regex.hpp:70:0, from /usr/local/gcc-20140104/include/boost/regex.hpp:31, from /tmp/bre.cc:1: /usr/local/gcc-20140104/include/boost/regex/v4/basic_regex_creator.hpp: In member function ‘boost::re_detail::re_literal* boost::re_detail::basic_regex_creator<charT, traits>::append_literal(charT)’: /usr/local/gcc-20140104/include/boost/regex/v4/basic_regex_creator.hpp:349:24: error: lvalue required as increment operand ++(result->length); ^ In file included from /usr/local/gcc-20140104/include/boost/regex/v4/regex.hpp:73:0, from /usr/local/gcc-20140104/include/boost/regex.hpp:31, from /tmp/bre.cc:1: /usr/local/gcc-20140104/include/boost/regex/v4/basic_regex_parser.hpp: In member function ‘bool boost::re_detail::basic_regex_parser<charT, traits>::parse_repeat(std::size_t, std::size_t)’: /usr/local/gcc-20140104/include/boost/regex/v4/basic_regex_parser.hpp:974:21: error: lvalue required as decrement operand --(lit->length); ^ llc[47]$ The problem goes away if that line of the patch is reverted, but since the change appears to be correct there's some other problem somewhere.
Is (a) an lvalue still? I don't remember the C++ rules to tell you the truth.
[expr.prim.general] p6 says: A parenthesized expression is a primary expression whose type and value are identical to those of the enclosed expression. The presence of parentheses does not affect whether the expression is an lvalue. The parenthesized expression can be used in exactly the same contexts as those where the enclosed expression can be used, and with the same meaning, except as otherwise indicated.
But also note [dcl.type.simple] p4: The type denoted by decltype(e) is defined as follows: — if e is an unparenthesized id-expression or an unparenthesized class member access (5.2.5), decltype(e) is the type of the entity named by e. If there is no such entity, or if e names a set of overloaded functions, the program is ill-formed; — otherwise, if e is an xvalue, decltype(e) is T&&, where T is the type of e; — otherwise, if e is an lvalue, decltype(e) is T&, where T is the type of e; — otherwise, decltype(e) is the type of e. The operand of the decltype specifier is an unevaluated operand (Clause 5). which means decltype((e)) is not necessarily the same as decltype(e). Perhaps the change was made to make this work, but it has side effects in some context that does not (explicitly) use decltype.
Let's add Jason in CC.
$ xg++ -c 59681.C -std=c++1y # nothing so assuming fixed.