http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52212
--- Comment #3 from Daniel Krügler
2012-02-12 15:02:22 UTC ---
My quoted phrase doesn't actually say that (nominated refers to the befriended
name). But 11 p4 can be applied here:
"Access control is applied uniformly to all names, whether the na
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52212
--- Comment #7 from Daniel Krügler
2012-02-12 17:18:38 UTC ---
I'd say that comment 3 and comment 5 are equivalent. Jonathan additionally
provided a way to fix the code.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52216
--- Comment #1 from Daniel Krügler
2012-02-13 08:20:50 UTC ---
There seems to be evidence for a core issue, I therefore would recommend to
wait until a corresponding issue number is available.
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-02-13 09:18:40 UTC ---
I can confirm that for gcc 4.7.0 20120211 (experimental) as well. To ease
comparison with other compiler I rewrote it into fully C++03 compatible form,
also removing all library
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52224
--- Comment #2 from Daniel Krügler
2012-02-13 09:26:34 UTC ---
I condensed the test case further down to the following:
//---
template struct enable_if {};
template struct enable_if { typedef T type; };
template struct is_mine { enum { value =
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52257
Bug #: 52257
Summary: [C++11] switch cases accept floating point constants
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-02-16 19:24:10 UTC ---
(In reply to comment #0)
> Note that non-static member function pointers do not generate either issues,
> although it is necessary to add "const" to the pointer typ
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-02-20 13:27:46 UTC ---
The code looks ok to me: A::B is considered complete after the "};".
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-02-21 08:26:30 UTC ---
Confirmed for 4.7.0 20120218 (experimental).
Reduced example with added information:
//
#include
#define FUNCTION_NAME __PRETTY_FUNCTION__
#define TRACE_FUNCTION(I) { std::cout
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52320
--- Comment #3 from Daniel Krügler
2012-02-21 10:53:59 UTC ---
(In reply to comment #2)
Agreed. It seems that the fix did not solve some array-related corner cases
like this one.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52224
--- Comment #5 from Daniel Krügler
2012-02-21 21:17:41 UTC ---
I just found this closed CWG issue:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#487
It seems that the compiler behaviour is indeed intended by the core language.
Bas
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-02-22 22:31:40 UTC ---
Confirmed for 4.7.0 20120218 (experimental).
Reduced example:
//---
template
using A = int;
template class>
struct B {};
B b;
//---
||googlemail dot com
--- Comment #2 from Daniel Krügler
2012-02-25 13:06:47 UTC ---
The name 'A' within Two::B refers to the base class A (which is One::A), which
again has no what() function. This is essentially the injected-class-name of
the base class as de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52422
Bug #: 52422
Summary: [C++11][SFINAE] Hard errors with void or arithmetic
expressions
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
||googlemail dot com
--- Comment #7 from Daniel Krügler
2012-03-01 06:49:30 UTC ---
One could argue that this issue is due to
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1402
If the current P/R becomes accepted, the code would become accepted, too
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-03-03 14:01:02 UTC ---
An array of length 0 is not valid. [dcl.array] p1:
"If the constant-expression (5.19) is present, it shall be an integral constant
expression and its value shall be greater than
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52476
Bug #: 52476
Summary: [C++11] Unordered multimap reorders equivalent
elements
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
S
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52476
--- Comment #2 from Daniel Krügler
2012-03-04 16:10:19 UTC ---
(In reply to comment #1)
> (we should double check that by avoiding any use of
> fancy C++11 features like initializer lists in the testcase)
I rewrote the testcase in C++03 form and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52476
--- Comment #3 from Daniel Krügler
2012-03-04 16:28:02 UTC ---
(In reply to comment #2)
> This means, one could actually remove the [C++11] tag from the bug title.
I withdraw this suggestion: In TR1 (N1836) there did no exist the reordering
cons
||googlemail dot com
--- Comment #2 from Daniel Krügler
2012-03-07 18:41:21 UTC ---
The cause for this problem is the currently unconstrained constructor
template
vector(InputIter, InputIter);
but I need to investigate whether this is a language or compiler problem. In
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52529
--- Comment #3 from Daniel Krügler
2012-03-08 08:50:59 UTC ---
The compiler is correct to reject your example FIRST, SECOND, and THIRD.
In FIRST and THIRD you are effectively asking to deduce T from
template long foo(typename T::X *x);
which
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52522
--- Comment #5 from Daniel Krügler
2012-03-08 18:34:36 UTC ---
(In reply to comment #2)
> but I need to investigate whether this is a language or compiler problem.
It is a language problem. My initial thought that it could be a compiler
problem,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52562
Bug #: 52562
Summary: [C++11] Most type_info functions not noexcept
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Prio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52562
--- Comment #5 from Daniel Krügler
2012-03-12 14:06:51 UTC ---
(In reply to comment #3)
> Do I understand correctly that in N3291 the destructor lost the explicit
> noexcept simply because of core/1123?
I don't know for the reason in the stdlib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52562
--- Comment #8 from Daniel Krügler
2012-03-12 15:46:42 UTC ---
(In reply to comment #6)
There exists a compiler problem with noexcept and non-trivial destructor
declarations as described in bug 50043 and in bug 51295. This fix should
automagicall
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52625
Bug #: 52625
Summary: Incorrect specialization semantics of friend class
template declaration
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52625
--- Comment #2 from Daniel Krügler
2012-03-20 08:41:48 UTC ---
(In reply to comment #1)
If this is indeed related to the injected-class-name, this should have been
clarified by
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1004
t
||googlemail dot com
--- Comment #4 from Daniel Krügler
2012-03-23 18:44:47 UTC ---
(In reply to comment #3)
> I'm agree. But if you remove all tests with is_assignable2, still remains
> problem with int:
>
> ...
> str
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52683
--- Comment #6 from Daniel Krügler
2012-03-23 19:41:03 UTC ---
(In reply to comment #4)
> > static_assert( is_assignable::value, "not assignable" ); // pass
>
> This works because this corresponds to assigning an int rvalue to an int.
" This wo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52702
Bug #: 52702
Summary: [C++11] std::is_trivially_destructible is missing
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52706
Bug #: 52706
Summary: [C++11] Demangling of templates with std::nullptr_t as
non-type parameter
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCON
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52707
Bug #: 52707
Summary: [C++11] Deleted special member function prevent type
being an aggregate
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFI
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-04-04 11:31:45 UTC ---
The intention of bug 51213 was to cover this.
||googlemail dot com
--- Comment #2 from Daniel Krügler
2012-04-04 11:43:22 UTC ---
This example causes no error in gcc 4.8.0 20120311 (experimental)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52892
--- Comment #1 from Daniel Krügler
2012-04-07 13:15:13 UTC ---
(In reply to comment #0)
[..]
> Based on my reading of the standard, this should be allowed behavior, and
> works as expected with clang 3.1 (152539).
I agree that this should work,
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-04-08 13:48:57 UTC ---
I don't see what this example is supposed to demonstrate. the two lines
X&& x1 = f();
and
X&& y1 = f();
produce references to invalid memory, any access to that i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52915
Bug #: 52915
Summary: [C++11] Deleted default-constructor of anonymous
unions not honored
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52702
--- Comment #3 from Daniel Krügler
2012-04-15 14:05:43 UTC ---
(In reply to comment #2)
> Daniel I'm adding this.
>
> By the way, is "is_nothrow_destructible" doable just now or needs compiler
> support? Are you willing to give it a try, in case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53025
Bug #: 53025
Summary: [C++11] noexcept operator depends on copy-elision
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52363
--- Comment #8 from Daniel Krügler
2012-04-18 14:41:38 UTC ---
(In reply to comment #7)
> Daniel, can you have a look to snippet in Comment #5? Should it compile or
> not?
It needed a while until I recognized that the second operator= overload
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53036
--- Comment #3 from Daniel Krügler
2012-04-19 12:24:12 UTC ---
(In reply to comment #2)
> Sadly, on this case:
> struct A {
> A()=default;
> A(int=2);
> };
> it says A is trivial whereas I guess the ambiguity makes it non-trivial.
I agree. T
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53039
--- Comment #7 from Daniel Krügler
2012-04-20 06:48:39 UTC ---
I'm pretty sure that this is not related with , but instead with
some interaction between the header and std::is_convertible. The
following variant still demonstrates the problem (I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53052
Bug #: 53052
Summary: [C++11] is_explicitly_convertible still part of
header
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
S
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58536
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58548
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58549
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58561
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58569
--- Comment #3 from Daniel Krügler ---
(In reply to Paolo Carlini from comment #1)
[Somehow bugzilla lost my response]
Yes, foo is incomplete within a data member declaration of type foo and this
breaks std::is_convertible, because the arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58569
--- Comment #6 from Daniel Krügler ---
(In reply to Jonathan Wakely from comment #4)
Why would LWG 2132 require any such check during the instantiation of the class
template or during the instantiation of the default constructor? The
constraints
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58569
--- Comment #7 from Daniel Krügler ---
(In reply to Jonathan Wakely from comment #5)
> And it should only happen when instantiating the converting constructor
> template or converting assignment operator function, not when instantiating
> the clas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58569
--- Comment #12 from Daniel Krügler ---
(In reply to Jonathan Wakely from comment #11)
> Further reduced (clang gives the same error for this version):
>
> template struct enable_if { typedef void type; };
> template struct enable_if { };
Jonath
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58569
--- Comment #14 from Daniel Krügler ---
(In reply to Jonathan Wakely from comment #13)
> Argh, yes, I didn't read the diagnostic properly after that last change,
> sorry!
Thanks. I think the actual problem can be resolve by moving
template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58569
--- Comment #15 from Daniel Krügler ---
(In reply to Daniel Krügler from comment #14)
Furthermore the name hiding happening here
template>>
Function(F);
needs to be fixed (it was not in your previous example):
template>>
Function(F);
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.kruegler at googlemail dot com
gcc 4.9.0 20130922 (experimental) compiled with the flags
-std=c++11 -Wall -pedantic-errors
rejects the following code:
//-
struct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58590
--- Comment #2 from Daniel Krügler ---
(In reply to Paolo Carlini from comment #1)
> Not having investigated this issue at all, I doubt that it should be
> considered a SFINAE proper issue,
Well, the actual programmer problem occurred in this con
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58590
--- Comment #4 from Daniel Krügler ---
(In reply to Paolo Carlini from comment #3)
> I still believe this isn't a SFINAE proper issue.
Could you please elaborate why?
> Also note that in the original testcase main was *empty*.
Sure, because I d
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58590
--- Comment #9 from Daniel Krügler ---
(In reply to Paolo Carlini from comment #5)
> Because a SFINAE proper error is when you have an hard error, essentially by
> definition from the implementation point of view, not when a static_assert
> trigge
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58605
--- Comment #1 from Daniel Krügler ---
Re initialization: I would think that the usage of "uninitialized state" is a
wording issue that should better be clarified by a library issue. I don't think
that the reference to C compatibility can be appli
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58605
--- Comment #3 from Daniel Krügler ---
(In reply to Jeffrey Yasskin from comment #2)
It would still make sense to keep this issue open as "Deferred" waiting for the
corresponding library issue resolution. I'll attach the issue number here for
refe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58625
--- Comment #10 from Daniel Krügler ---
(In reply to Oleg Endo from comment #4)
> There's another place in file libstdc++-v3/include/c_std/cmath:
>
> template
> inline typename __gnu_cxx::__enable_if<__is_arithmetic<_Tp>::__value,
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58605
--- Comment #4 from Daniel Krügler ---
(In reply to Daniel Krügler from comment #3)
A new library has been opened:
http://cplusplus.github.io/LWG/lwg-active.html#2334
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58713
--- Comment #3 from Daniel Krügler ---
(In reply to Jonathan Wakely from comment #1)
> I've tried to improve it in the past, but I think there's no easy way to do
> it.
A possible fix might be to change the Standard ;-) Despite the smiley I
serio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58713
--- Comment #5 from Daniel Krügler ---
(In reply to Marc Glisse from comment #4)
> If I try to sfinae-out this function based on os< an error that "template instantiation depth exceeds maximum of 900" (even
> for a valid cout<<42), because even if
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58713
--- Comment #6 from Daniel Krügler ---
(In reply to Daniel Krügler from comment #5)
> Thanks for your test, Marc. I will reflect upon the problem in a bit more
> detail
My current guess is that my suggested approach should work, assuming a proper
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58815
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58820
--- Comment #1 from Daniel Krügler ---
This looks like a more fundamental name lookup problem of gcc to me. It can be
reproduced with function object types that are no lambda closures:
template
struct overload_set : Fs...
{
overload_set(Fs...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58815
--- Comment #8 from Daniel Krügler ---
(In reply to Paolo Carlini from comment #6)
I also would like to encourage using explicit conversion functions. This is
explicitly suggested in the updated C++11 integration document:
http://www.open-std.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58848
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58885
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58885
--- Comment #5 from Daniel Krügler ---
(In reply to Vehbi Esref Bayraktar from comment #4)
> So why doesn't it compile as is
> CGEnum::instances_list CGEnum::msInstances;
> and asks for a specialization notation (template<>)?
Well, because that w
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58894
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58923
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58924
--- Comment #3 from Daniel Krügler ---
(In reply to Fanael from comment #1)
I agree with Fanael: It is supposed to be that way in C++11 because of the
provided stream-rvalue support via
template
basic_ostream&
operator<<(basic_ostream&& os, cons
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58954
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58948
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58948
--- Comment #4 from Daniel Krügler ---
(In reply to sshannin from comment #2)
> I wonder if there's any way to declare it such that the namespaces/types are
> unambiguous that will parse correctly in both the c++11 and c++03 modes.
The following
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58972
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59004
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59005
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59027
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59033
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59027
--- Comment #4 from Daniel Krügler ---
(In reply to Marc Mutz from comment #3)
> See code posted in http://llvm.org/bugs/show_bug.cgi?id=17834
> is_unsigned fails, !is_signed succeeds. MouseButton is an enum.
The assertion of the following code i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58752
--- Comment #6 from Daniel Krügler ---
(In reply to Richard Smith from comment #4)
Richard, could you please explain what precisely you meant with:
"Deducing #1 from #2 gives T=const U, which results in a deduction failure
because enable_if<...co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59135
--- Comment #1 from Daniel Krügler ---
The problem seems to exist in gcc 4.7.3 and within the recent 4.9.0 trunk. The
following variant of the code removes unnecessary library dependencies and
constexpr (which is not needed to reproduce the proble
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59144
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59165
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59204
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59211
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59244
--- Comment #1 from Daniel Krügler ---
This seems to be fixed in gcc 4.8.2 and in gcc 4.9.0 HEAD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57645
--- Comment #6 from Daniel Krügler ---
(In reply to Dave Peterson from comment #5)
In C++11 terminate is expected for this code, because the implied exception
specification of any destructor is noexcept(true), so throwing an exception
here is a ba
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59329
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59508
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59508
--- Comment #3 from Daniel Krügler ---
(In reply to Oleg Endo from comment #2)
> Could you please elaborate?
My response was referring to the generic code that you provided, because that
would also be applied to user-provided specializations of l
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59404
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51143
Bug #: 51143
Summary: [C++11][DR1159] Alias template allows class definition
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51145
Bug #: 51145
Summary: [C++11][DR1131] Alias template in
elaborated-type-specifier accepted
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRME
||googlemail dot com
--- Comment #1 from Daniel Krügler
2011-11-16 08:36:52 UTC ---
(In reply to comment #0)
> 14.5.5.8 of n324 states:
>
> "A partially specialized non-type argument expression shall not involve a
> template parameter of the
> pa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51185
--- Comment #2 from Daniel Krügler
2011-11-17 10:58:09 UTC ---
(In reply to comment #1)
The root of the problem is that __is_base_to_derived_ref works on source
references solely. I need a bit time for a proper fix.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51199
Bug #: 51199
Summary: [C++11][DR 547] gcc forms impossible types derived
from function types with cv-qualifier-seq
Classification: Unclassified
Product: gcc
Version: 4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51210
Bug #: 51210
Summary: [C++11][DR 547] std::type_info works incorrectly with
function types with cv-qualifier-seq
Classification: Unclassified
Product: gcc
Version: 4.7.0
401 - 500 of 884 matches
Mail list logo
