[Bug c++/48046] New: [4.5/4.6 Regression] Expected diagnostic "reference to 'type' is ambiguous" not given for function-local static declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48046
Summary: [4.5/4.6 Regression] Expected diagnostic "reference to
'type' is ambiguous" not given for function-local
static declaration
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dev.li...@jessamine.co.uk
In g++ 4.5 and 4.6, a function-local static declared with an ambiguous type
does not yield the expected diagnostic. It appropriately fails to compile due
to a type not being resolved but doesn't give the user the root cause of the
failure as it did in 4.4.
Given the following code:
namespace N1 { typedef int T; }
namespace N2 { typedef float T; }
int main()
{
using namespace N1;
using namespace N2;
static T t;
}
4.4.5 outputs:
: In function 'int main()':
:9: error: reference to 'T' is ambiguous
:2: error: candidates are: typedef float N2::T
:1: error: typedef int N1::T
:9: error: 'T' does not name a type
Both 4.5.0 (an old build I had lying around) and 4.6.0 (at rev 170646) output:
: In function ‘int main()’:
:9:14: error: ‘T’ does not name a type
If the static declaration and preceding using directives are moved to namespace
scope rather than being function-local, the expected diagnostic is output.
If the function-local declaration is made non-static, the expected diagnostic
is output.
[Bug c++/47950] [4.6 Regression] [C++0x] Internal compiler error: non-dependent declaration as condition causes tsubst_copy_and_build assertion failure.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47950 Adam Butcher changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Adam Butcher 2011-03-03 08:47:09 UTC --- Great. Full build of our tree works from clean with latest 4.6 HEAD now.
[Bug c++/47774] [C++0x] constexpr specifier on ctor not ignored when template instantiation causes ctor to not satify constexpr requirements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47774 --- Comment #9 from Adam Butcher 2011-03-03 08:40:28 UTC --- Great. That's got rid of the need for the preprocessor hacks to remove constexpr usage from libstdc++ in c++0x mode. A full build of our tree from GCC 4.6 HEAD (including unmodified libstdc++) works fine now.
[Bug c++/47950] [4.6 Regression] [C++0x] Internal compiler error: non-dependent declaration as condition causes tsubst_copy_and_build assertion failure.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47950 --- Comment #3 from Adam Butcher 2011-03-02 16:30:30 UTC --- (In reply to comment #1) > > Rolling back to my previous HEAD reveals that the reduced example above still > fails whereas the code I was originally trying to build worked. So obviously > my reduction has changed something. > Okay. My original reduction was okay but I also added additional examples that yielded the same assertion failure (obviously via different route!). The function-call case following is the one that causes the failure in non-dependent use of boost.foreach on the latest 4.6 HEAD. It compiles okay on my 4.6 build from last week (prior to 170488). if (from_int x = via_function(7)) ; The constructor cases below have failed for a much longer time (though are okay in 4.5). if (empty x = empty()) ; if (from_int x = from_int(7)) ; So the only recent regression is the function-call case. But all cases are all still legitimate 4.5 -> 4.6 regressions. Before rev 170488 (25th Feb) the function-call case compiled. I don't know when the constructor cases stopped working -- I went quite a way back and they still failed.
[Bug c++/47950] [C++0x] Internal compiler error: non-dependent declaration as condition causes tsubst_copy_and_build assertion failure.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47950
Adam Butcher changed:
What|Removed |Added
CC||dev.lists at jessamine dot
||co.uk, jason at gcc dot
||gnu.org
--- Comment #1 from Adam Butcher 2011-03-02
15:39:00 UTC ---
Added Jason to CC.
Rolling back to my previous HEAD reveals that the reduced example above still
fails whereas the code I was originally trying to build worked. So obviously
my reduction has changed something. It doesn't change the fact that there is
an internal compiler error with the example above but it does mean that maybe
it is less likely to be hit.
So I was wrong that the above code has regressed in the last few days. The
code that I was originally trying to build, which did work a few days ago and
now fails with the symptoms described above was using BOOST_FOREACH. Obviously
this is unnecessary in C++0x as there is for(:) but it was compiling fine
before (and does in an old GCC 4.5 I have in C++0x mode).
The boost example was a non-dependent boost.foreach in a function template:
#include
#include
template
void f()
{
std::vector v = { 1,2,3,4 };
BOOST_FOREACH(int x, v)
{
}
}
int main()
{
f();
}
Making the vector dependent on T rather than int makes the problem go away. I
arrived at the reduction stated previously by breaking down BOOST_FOREACH until
the failure occurred.
Clearly there is an issue here but I'll do a bit more investigation into why
the boost example worked a few builds ago and why my reduction doesn't.
[Bug c++/47950] New: [C++0x] Internal compiler error: non-dependent declaration as condition causes tsubst_copy_and_build assertion failure.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47950
Summary: [C++0x] Internal compiler error: non-dependent
declaration as condition causes tsubst_copy_and_build
assertion failure.
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dev.li...@jessamine.co.uk
The following program demonstrates an assertion failure in
tsubst_copy_and_build when compiling in C++0x mode.
It may be related to bug 47808 which fails the same assertion via a different
route (looks like it's using a non-dependent constexpr function to determine
the size of an array).
This issue demonstrated here appears to manifest only when a non-dependent
declaration is used as a condition within a selection statement inside a
template -- and only then if the standard initializer syntax is used with the
rhs being a constructor or function call.
This was done using 4.6.0 20110302 built this morning. Failures only occur in
C++0x mode.
This is a recent regression -- a build from a few days ago did not exhibit this
issue.
template struct empty
{
// allow success case to build (not relevant to bug)
operator bool() { return true; }
};
template struct from_int
{
from_int(int) {}
// allow success case to build (not relevant to bug)
operator bool() { return true; }
};
template
from_int via_function(T v)
{
return from_int(v);
}
template
void f()
{
// * this section compiles ***
// these plain initializers work fine
from_int a = 7;
from_int b = from_int(7);
emptyc = empty();
from_int ta = 7;
from_int tb = from_int(7);
emptytc = empty();
// these dependent condition decls work fine
if (empty x = empty())
;
if (from_int x = 7)
;
if (from_int x = from_int(7))
;
if (from_int x = via_function(T()))
;
// this non-dependent condition decl using conversion works fine
if (from_int x = 7)
;
// these non-dependent condition decls using conversion or braced-
// initialization work fine (in c++0x mode only course)
#if __GXX_EXPERIMENTAL_CXX0X__
if (empty x {})
;
if (from_int x {7})
;
#endif
// ** this section fails in C++0x ***
// the following non-dependent condition decls cause an assertion
// failure in
//
// tsubst_copy_and_build, at cp/pt.c:13370
//
// in C++0x mode
//
if (empty x = empty())
;
if (from_int x = from_int(7))
;
if (from_int x = via_function(7))
;
}
int main()
{
f();
}
[Bug c++/47774] [C++0x] constexpr specifier on ctor not ignored when template instantiation causes ctor to not satify constexpr requirements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47774
--- Comment #7 from Adam Butcher 2011-03-01
15:34:40 UTC ---
(In reply to comment #6)
> Yep, this is fixed too.
>
> *** This bug has been marked as a duplicate of bug 46472 ***
>
The attached program demonstrated instances of the bug with various member
types. It still fails on two cases when using array members. I don't think
they are errors. Running
sh constexpr-ctor-templ.cpp
with 4.6.0 20110301 now yields the following (output compressed for legibility
[snip] = -c constexpr-ctor-templ.cpp -std=c++0x).
+ g++ [snip] -DPLAIN_T -DUSE_SYNTHESIZED_X_CTOR
+ g++ [snip] -DPLAIN_T -DGIVE_X_EXPLICIT_CONSTEXPR_CTOR
+ g++ [snip] -DPLAIN_T -DGIVE_X_EXPLICIT_NONCONST_CTOR
+ g++ [snip] -DPLAIN_T_ARRAY -DUSE_SYNTHESIZED_X_CTOR
+ g++ [snip] -DPLAIN_T_ARRAY -DGIVE_X_EXPLICIT_CONSTEXPR_CTOR
constexpr-ctor-templ.cpp: In constructor ‘constexpr X::X() [with T =
ncbool]’:
constexpr-ctor-templ.cpp:148:14: instantiated from here
constexpr-ctor-templ.cpp:103:24: error: ‘ncbool::ncbool(bool)’ is not
‘constexpr’
+ g++ [snip] -DPLAIN_T_ARRAY -DGIVE_X_EXPLICIT_NONCONST_CTOR
+ g++ [snip] -DFLAG_T-DUSE_SYNTHESIZED_X_CTOR
+ g++ [snip] -DFLAG_T-DGIVE_X_EXPLICIT_CONSTEXPR_CTOR
+ g++ [snip] -DFLAG_T-DGIVE_X_EXPLICIT_NONCONST_CTOR
+ g++ [snip] -DFLAG_T_ARRAY -DUSE_SYNTHESIZED_X_CTOR
+ g++ [snip] -DFLAG_T_ARRAY -DGIVE_X_EXPLICIT_CONSTEXPR_CTOR
constexpr-ctor-templ.cpp: In constructor ‘constexpr X::X() [with T =
ncbool]’:
constexpr-ctor-templ.cpp:148:14: instantiated from here
constexpr-ctor-templ.cpp:103:24: error: ‘constexpr flag::flag(bool)
[with BoolType = ncbool]’ is not ‘constexpr’
+ g++ [snip] -DFLAG_T_ARRAY -DGIVE_X_EXPLICIT_NONCONST_CTOR
Failed 2
The failing invocations occur when an array of a type that cannot be used to
construct compile-time constants is used as a member of X when X is given a
constexpr constructor. With the new compiler, the result comments become:
--- constexpr-ctor-templ.cpp 2011-03-01 14:57:22.0 +
+++ constexpr-ctor-templ.cpp 2011-03-01 14:58:55.0 +
@@ -113,11 +113,11 @@
#if PLAIN_T
T mem;// doesn't fail in any mode
#elif FLAG_T
- flag mem; // fails only with synthesized ctor
+ flag mem; // doesn't fail in any mode now
#elif PLAIN_T_ARRAY
T mem[7]; // fails only with GIVE_X_EXPLICIT_CONSTEXPR_CTOR
#elif FLAG_T_ARRAY
- flag mem[7]; // fails unless GIVE_X_EXPLICIT_NONCONST_CTOR
+ flag mem[7]; // fails only with GIVE_X_EXPLICIT_CONSTEXPR_CTOR
#endif
};
I.e. The plain array member still fails as it did before and the flag array
member now fails in the same way as the plain array member (which is a change
from how it failed before).
Since the failures are now purely array related, a simplified program with no
macro configuration that reproduces the problem is:
struct ncbool
{
ncbool(bool b = false) : b(b) {}
bool b;
};
template
struct flag
{
constexpr flag(BoolType b = false) : b(b) {}
BoolType b;
};
template
struct array
{
constexpr array() : mem() {}
T mem[7];
};
int main(int argc, char**)
{
// The following are not declared constexpr
// so shouldn't result in constexpr errors.
array array_of_plain_ncbool;
array> array_of_flag_ncbool;
}
[Bug c++/47783] New: Warning 'set but not used' [-Wunused-but-set-parameter] incorrectly issued for update through reference wrapper
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47783
Summary: Warning 'set but not used'
[-Wunused-but-set-parameter] incorrectly issued for
update through reference wrapper
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dev.li...@jessamine.co.uk
Compiling the following program with warning options -W -Wall yields
: In function ‘void f(ref_wrapper)’:
:6:6: warning: parameter ‘ref’ set but not used
[-Wunused-but-set-parameter]
If the reference-to-int is replaced with a pointer-to-int and dereference and
address-of operators are used in the appropriate places the warning does not
occur.
In all cases and at all optimization levels the resulting program returns 7 as
expected.
struct ref_wrapper
{
int& i;
};
void f( ref_wrapper ref )
{
ref.i = 7;
}
int main()
{
int x = 1;
ref_wrapper xref = {x};
f(xref);
return x;
}
[Bug c++/47774] [C++0x] constexpr specifier on ctor not ignored when template instantiation causes ctor to not satify constexpr requirements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47774 Adam Butcher changed: What|Removed |Added CC||jason at gcc dot gnu.org See Also||http://gcc.gnu.org/bugzilla ||/show_bug.cgi?id=46472 --- Comment #3 from Adam Butcher 2011-02-17 11:00:01 UTC --- Added Jason to CC and referenced bug 46472. The code stated in 46472 works on current GCC though but the description is similar to this.
[Bug c++/47774] [C++0x] constexpr specifier on ctor not ignored when template instantiation causes ctor to not satify constexpr requirements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47774 Adam Butcher changed: What|Removed |Added Attachment #23369|0 |1 is obsolete|| --- Comment #2 from Adam Butcher 2011-02-17 08:34:18 UTC --- Created attachment 23373 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23373 Fix launch parameter bug with previous attachment (In reply to comment #1) Re: attachment 23369 Spotted a bug with options in test case. One class of ctor specification was used twice instead of selecting the third. -DUSE_SYNTHESIZED_X_CTOR \ -DGIVE_X_EXPLICIT_CONSTEXPR_CTOR \ - -DGIVE_X_EXPLICIT_CONSTEXPR_CTOR + -DGIVE_X_EXPLICIT_NONCONST_CTOR Updated attachment included revised output below. Compiling with gcc version 4.6.0 20110217 svn trunk@170240 built this morning yields: + g++ -c constexpr-ctor-templ.cpp -std=c++0x -DPLAIN_T -DUSE_SYNTHESIZED_X_CTOR + g++ -c constexpr-ctor-templ.cpp -std=c++0x -DPLAIN_T -DGIVE_X_EXPLICIT_CONSTEXPR_CTOR + g++ -c constexpr-ctor-templ.cpp -std=c++0x -DPLAIN_T -DGIVE_X_EXPLICIT_NONCONST_CTOR + g++ -c constexpr-ctor-templ.cpp -std=c++0x -DPLAIN_T_ARRAY -DUSE_SYNTHESIZED_X_CTOR + g++ -c constexpr-ctor-templ.cpp -std=c++0x -DPLAIN_T_ARRAY -DGIVE_X_EXPLICIT_CONSTEXPR_CTOR constexpr-ctor-templ.cpp: In constructor ‘constexpr X::X() [with T = ncbool]’: constexpr-ctor-templ.cpp:148:14: instantiated from here constexpr-ctor-templ.cpp:103:24: error: ‘ncbool::ncbool(bool)’ is not ‘constexpr’ + g++ -c constexpr-ctor-templ.cpp -std=c++0x -DPLAIN_T_ARRAY -DGIVE_X_EXPLICIT_NONCONST_CTOR + g++ -c constexpr-ctor-templ.cpp -std=c++0x -DFLAG_T -DUSE_SYNTHESIZED_X_CTOR constexpr-ctor-templ.cpp: In constructor ‘X::X()’: constexpr-ctor-templ.cpp:100:8: error: ‘constexpr flag::flag(bool) [with BoolType = ncbool]’ is not ‘constexpr’ constexpr-ctor-templ.cpp: In function ‘int main(int, char**)’: constexpr-ctor-templ.cpp:148:14: note: synthesized method ‘X::X()’ first required here + g++ -c constexpr-ctor-templ.cpp -std=c++0x -DFLAG_T -DGIVE_X_EXPLICIT_CONSTEXPR_CTOR + g++ -c constexpr-ctor-templ.cpp -std=c++0x -DFLAG_T -DGIVE_X_EXPLICIT_NONCONST_CTOR + g++ -c constexpr-ctor-templ.cpp -std=c++0x -DFLAG_T_ARRAY -DUSE_SYNTHESIZED_X_CTOR constexpr-ctor-templ.cpp: In constructor ‘constexpr X::X()’: constexpr-ctor-templ.cpp:100:8: error: ‘constexpr flag::flag(bool) [with BoolType = ncbool]’ is not ‘constexpr’ constexpr-ctor-templ.cpp:100:8: error: non-constant array initialization constexpr-ctor-templ.cpp: In function ‘int main(int, char**)’: constexpr-ctor-templ.cpp:148:14: note: synthesized method ‘X::X()’ first required here + g++ -c constexpr-ctor-templ.cpp -std=c++0x -DFLAG_T_ARRAY -DGIVE_X_EXPLICIT_CONSTEXPR_CTOR constexpr-ctor-templ.cpp: In constructor ‘constexpr X::X() [with T = ncbool]’: constexpr-ctor-templ.cpp:148:14: instantiated from here constexpr-ctor-templ.cpp:103:24: error: ‘constexpr flag::flag(bool) [with BoolType = ncbool]’ is not ‘constexpr’ + g++ -c constexpr-ctor-templ.cpp -std=c++0x -DFLAG_T_ARRAY -DGIVE_X_EXPLICIT_NONCONST_CTOR Failed 4
[Bug c++/47774] [C++0x] constexpr specifier on ctor not ignored when template instantiation causes ctor to not satify constexpr requirements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47774 --- Comment #1 from Adam Butcher 2011-02-16 23:03:22 UTC --- Created attachment 23369 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23369 Various declarations and constexpr specifications demonstrating problem -- runnable as sh script Added an additional test file, runnable as sh script, which tests various combinations of ctor specifications and member types. Compiling with gcc version 4.6.0 20110216 (experimental) (GCC) built tonight yields: $ sh constexpr-ctor-templ.cpp + g++ -c constexpr-ctor-templ.cpp -std=c++0x -DPLAIN_T -DUSE_SYNTHESIZED_X_CTOR + g++ -c constexpr-ctor-templ.cpp -std=c++0x -DPLAIN_T -DGIVE_X_EXPLICIT_CONSTEXPR_CTOR + g++ -c constexpr-ctor-templ.cpp -std=c++0x -DPLAIN_T -DGIVE_X_EXPLICIT_CONSTEXPR_CTOR + g++ -c constexpr-ctor-templ.cpp -std=c++0x -DPLAIN_T_ARRAY -DUSE_SYNTHESIZED_X_CTOR + g++ -c constexpr-ctor-templ.cpp -std=c++0x -DPLAIN_T_ARRAY -DGIVE_X_EXPLICIT_CONSTEXPR_CTOR constexpr-ctor-templ.cpp: In constructor ‘constexpr X::X() [with T = ncbool]’: constexpr-ctor-templ.cpp:148:14: instantiated from here constexpr-ctor-templ.cpp:103:24: error: ‘ncbool::ncbool(bool)’ is not ‘constexpr’ + g++ -c constexpr-ctor-templ.cpp -std=c++0x -DPLAIN_T_ARRAY -DGIVE_X_EXPLICIT_CONSTEXPR_CTOR constexpr-ctor-templ.cpp: In constructor ‘constexpr X::X() [with T = ncbool]’: constexpr-ctor-templ.cpp:148:14: instantiated from here constexpr-ctor-templ.cpp:103:24: error: ‘ncbool::ncbool(bool)’ is not ‘constexpr’ + g++ -c constexpr-ctor-templ.cpp -std=c++0x -DFLAG_T -DUSE_SYNTHESIZED_X_CTOR constexpr-ctor-templ.cpp: In constructor ‘X::X()’: constexpr-ctor-templ.cpp:100:8: error: ‘constexpr flag::flag(bool) [with BoolType = ncbool]’ is not ‘constexpr’ constexpr-ctor-templ.cpp: In function ‘int main(int, char**)’: constexpr-ctor-templ.cpp:148:14: note: synthesized method ‘X::X()’ first required here + g++ -c constexpr-ctor-templ.cpp -std=c++0x -DFLAG_T -DGIVE_X_EXPLICIT_CONSTEXPR_CTOR + g++ -c constexpr-ctor-templ.cpp -std=c++0x -DFLAG_T -DGIVE_X_EXPLICIT_CONSTEXPR_CTOR + g++ -c constexpr-ctor-templ.cpp -std=c++0x -DFLAG_T_ARRAY -DUSE_SYNTHESIZED_X_CTOR constexpr-ctor-templ.cpp: In constructor ‘constexpr X::X()’: constexpr-ctor-templ.cpp:100:8: error: ‘constexpr flag::flag(bool) [with BoolType = ncbool]’ is not ‘constexpr’ constexpr-ctor-templ.cpp:100:8: error: non-constant array initialization constexpr-ctor-templ.cpp: In function ‘int main(int, char**)’: constexpr-ctor-templ.cpp:148:14: note: synthesized method ‘X::X()’ first required here + g++ -c constexpr-ctor-templ.cpp -std=c++0x -DFLAG_T_ARRAY -DGIVE_X_EXPLICIT_CONSTEXPR_CTOR constexpr-ctor-templ.cpp: In constructor ‘constexpr X::X() [with T = ncbool]’: constexpr-ctor-templ.cpp:148:14: instantiated from here constexpr-ctor-templ.cpp:103:24: error: ‘constexpr flag::flag(bool) [with BoolType = ncbool]’ is not ‘constexpr’ + g++ -c constexpr-ctor-templ.cpp -std=c++0x -DFLAG_T_ARRAY -DGIVE_X_EXPLICIT_CONSTEXPR_CTOR constexpr-ctor-templ.cpp: In constructor ‘constexpr X::X() [with T = ncbool]’: constexpr-ctor-templ.cpp:148:14: instantiated from here constexpr-ctor-templ.cpp:103:24: error: ‘constexpr flag::flag(bool) [with BoolType = ncbool]’ is not ‘constexpr’ Failed 6
[Bug c++/47774] New: [C++0x] constexpr specifier on ctor not ignored when template instantiation causes ctor to not satify constexpr requirements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47774
Summary: [C++0x] constexpr specifier on ctor not ignored when
template instantiation causes ctor to not satify
constexpr requirements
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dev.li...@jessamine.co.uk
The definition of b in the program below fails to compile due to the default
constructor for its only member not being a valid constexpr. B itself does not
claim to be a literal type or that instances of it should be usable as
constants but g++ currently seems to enforce the constexpr nature of the ctor
of X even when T causes the definition to fail to meet the constexpr
constructor requirements.
7.1.5 para 4 states:
6 If the instantiated template specialization of a constexpr
function template or member function of a class template would
fail to satisfy the requirements for a constexpr function or
constexpr constructor, that specialization is not a constexpr
function or constexpr constructor. [Note: if the function is
a member function it will still be const as described below.
Implementations are encouraged to issue a warning if a
function is rendered not constexpr by a non-dependent
construct. --end note]
The program below demonstrates what I think to be non-compliance with this. It
is a reduced case (I originally came across this when attempting to instantiate
a std::array,N> where objects of either F or S were not usable
as constants; pair's default constructor is specified as constexpr yielding the
same problem).
template
struct X
{
constexpr X() : t() {}
T t;
};
struct CanBeCompileTimeConstant { constexpr CanBeCompileTimeConstant() {}
};
struct CannotBeCompileTimeConstant { CannotBeCompileTimeConstant() {} };
X nonconstexpr1;
X nonconstexpr2;
constexpr X constexpr1;
//constexpr X constexpr2; // fails as expected
struct A
{
X mem;
};
struct B
{
X mem;
};
A a;
B b; // fails unexpectedly: 'constexpr X::X() [with T =
CannotBeCompileTimeConstant]' is not 'constexpr'
[Bug c++/42603] [C++0x] decltype not supported for parent class specifier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42603 Adam Butcher changed: What|Removed |Added CC||dev.lists at jessamine dot ||co.uk --- Comment #3 from Adam Butcher 2011-01-20 22:07:31 UTC --- Fix proposed for this in http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01387.html
[Bug c++/6709] [DR743] decltype cannot be used with the :: operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6709
Adam Butcher changed:
What|Removed |Added
CC||dev.lists at jessamine dot
||co.uk
--- Comment #17 from Adam Butcher 2011-01-20
22:03:31 UTC ---
I have the beginnings of a fix for this (see the patch at
http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01392.html); currently there is a
bug with my impl where any name on the right of `decltype(x)::' at the front of
a nested-name-specifier is considered a non-type unless qualified with
typename.
I.e. given:
struct X { typedef int I; }
X x;
instead of:
decltype(x)::I i = 7;
the user must currently write:
typename decltype(x)::I i = 7;
as if decltype(x) was somehow dependent on a template parameter -- which it
obviously isn't as there is no template it sight.
Otherwise the patch seems close.
