||googlemail dot com
--- Comment #1 from Daniel Krügler
2011-10-31 07:15:48 UTC ---
Your expectations are in violation to the standard ;-). The constructor is
selected by overload resolution. The non-template constructor A(const A& a)
would be preferred, if there w
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50930
Bug #: 50930
Summary: [C++0x] Valid brace-or-equal-initializer of non-static
data member rejected
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50930
Daniel Krügler changed:
What|Removed |Added
Keywords||rejects-valid
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50929
--- Comment #3 from Daniel Krügler
2011-10-31 08:24:58 UTC ---
(In reply to comment #2)
> That's a shame, and rather annoying. I read pages and pages of the standard to
> try to understand this one. Do you know where this is explained?
Actually
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50929
--- Comment #5 from Daniel Krügler
2011-10-31 10:18:04 UTC ---
(In reply to comment #4)
> I didn't realise that A(A&) was a better match. I was thinking of C++ code
> where you might write:
>
> template
> A(const T& t);
>
> A(const A& rh
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50941
Bug #: 50941
Summary: [C++0x] user-defined string literals provide incorrect
length for wchar_t, char16_t, and char32_t
Classification: Unclassified
Product: gcc
Version: 4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50941
--- Comment #1 from Daniel Krügler
2011-11-01 10:24:59 UTC ---
I need to make a correction in regard to the actually provided length values:
a) The following assertions incorrectly hold:
static_assert( L""_len == 1, "Ouch");
static_assert( u""_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50958
Bug #: 50958
Summary: [C++0x] raw literal operator provides incorrect string
for integer literal '0'
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50967
Bug #: 50967
Summary: [C++0x] Literal operators are not found by
using-declarations
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50967
Daniel Krügler changed:
What|Removed |Added
Keywords||rejects-valid
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50967
Daniel Krügler changed:
What|Removed |Added
Keywords|rejects-valid |
--- Comment #2 from Daniel Krügler
20
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50976
Bug #: 50976
Summary: [C++0x] literal operator with unsigned long long
parameter not accepted
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50976
--- Comment #2 from Daniel Krügler
2011-11-03 12:03:51 UTC ---
Created attachment 25701
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25701
Test case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50976
--- Comment #3 from Daniel Krügler
2011-11-03 12:05:06 UTC ---
(In reply to comment #1)
> Could it be that there is a 'template' just above the declaration?
> Literal operator templates must have void argument.
No, there is nothing like this ne
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50976
--- Comment #6 from Daniel Krügler
2011-11-03 13:04:57 UTC ---
(In reply to comment #4)
> gcc version 4.7.0 20111031 (experimental) (GCC)
This difference shouldn't be essential, should it?
> I wonder if the testsuite was run when the gcc was b
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50976
--- Comment #7 from Daniel Krügler
2011-11-03 13:06:12 UTC ---
(In reply to comment #6)
> (In reply to comment #4)
> > gcc version 4.7.0 20111031 (experimental) (GCC)
>
> This difference shouldn't be essential, should it?
(Sorry, my reply conf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50976
--- Comment #10 from Daniel Krügler
2011-11-03 13:58:53 UTC ---
(In reply to comment #8)
I just send a corresponding email to the support address of this page. In
addition I removed my previous gcc installation completely and installed it
freshly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50976
--- Comment #11 from Daniel Krügler
2011-11-03 19:44:02 UTC ---
(In reply to comment #4)
> I can't imagine how this could be target dependent though.
I have a bit more information now: If I'm using the 32-bit version from
http://www.equation.com
||googlemail dot com
--- Comment #10 from Daniel Krügler
2011-11-08 18:16:45 UTC ---
(In reply to comment #8)
> Once we have ref-qualifiers, it should be OK to add the non-const overload
> with
> an lvalue ref-qualifier, though.
I think you need to add a di
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51013
--- Comment #12 from Daniel Krügler
2011-11-09 10:36:59 UTC ---
(In reply to comment #11)
> Can't you qualify the constexpr version with const&?
Yes.
> That wouldn't exactly
> match the signature in the standard, which is bad if someone tries
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50958
--- Comment #2 from Daniel Krügler
2011-11-09 10:42:18 UTC ---
(In reply to comment #1)
I have now tested gcc 4.7.0 2005, but the problem still seems to exist. I
can reproduce it on Windows XP 32 bit and Windows 7 64 bit.
||googlemail dot com
--- Comment #1 from Daniel Krügler
2011-11-09 12:23:54 UTC ---
Simplifying the test case and compiled with
-std=c++0x -Wall
//---
template
struct A {
virtual void DoPush(X const& x) = 0; // Line 3
void Push(X const& x) {
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51079
Bug #: 51079
Summary: [C++0x] Conversion function template ignored in the
presence of non-template conversion function
Classification: Unclassified
Product: gcc
Version: 4.7.0
||googlemail dot com
--- Comment #1 from Daniel Krügler
2011-11-10 18:10:28 UTC ---
Unfortunately the current standard says that your example is ill-formed. The
reason is based on the fact that member functions (including static ones) are
not parsed before the complete
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53221
Bug #: 53221
Summary: [C++11] basic_string lacks "copy/move constructors"
with allocator
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52282
--- Comment #4 from Daniel Krügler
2012-05-04 16:42:39 UTC ---
(In reply to comment #3)
> This ICE still occurs in the release version of gcc 4.7.0.
And also in 4.8.0 HEAD btw.
> The attached test-case compiles and runs successfully under clang
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225
--- Comment #13 from Daniel Krügler
2012-05-04 20:09:55 UTC ---
(In reply to comment #11)
> Jonathan, but there is "magical adjustment" as you put it, as the following
> code works correctly:
The difference in your modified example is that the c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225
--- Comment #25 from Daniel Krügler
2012-05-04 22:04:58 UTC ---
(In reply to comment #23)
> You don't even have a B::this_type typedef, how could (this_type*) possibly
> refer to anything except A*? Just by calling it "this_type" doesn't make it
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-05-05 16:32:18 UTC ---
I agree that the code needs to be rejected, but I think the invalid expression
should be
ov.get()
instead of
ov.get()
as indicated by the code comment. The same defect also exists in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53236
--- Comment #3 from Daniel Krügler
2012-05-05 18:57:03 UTC ---
Reduced test-case:
//-
template
struct enable_same
{};
template
struct enable_same
{
typedef U type;
};
template
struct other_variant
{
void get(){}
};
template
struct o
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-05-05 21:16:36 UTC ---
(In reply to comment #0)
> Looking at on the web at your documentation pages, there is no
> specialization of "std::array" for "std::array"; you just nudge the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53248
--- Comment #3 from Daniel Krügler
2012-05-06 11:21:47 UTC ---
(In reply to comment #2)
> Daniel, can you see other options besides adding a specialization? (which
> would
> be a straightforward task, I may even get around to do pretty soon when
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53236
--- Comment #7 from Daniel Krügler
2012-05-06 17:34:10 UTC ---
(In reply to comment #5)
> Here is a simplified code -> "gcc_error_simple.cpp"
> Shows two facets of the error.
>
> See the comments in the attached file.
Fixed and simplified that
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53248
--- Comment #6 from Daniel Krügler
2012-05-06 18:56:05 UTC ---
(In reply to comment #5)
> By the way - I think we discussed this already, bu now I can't find anything -
> what should we take the begin() == end() == unique value exactly to mean?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53236
--- Comment #9 from Daniel Krügler
2012-05-07 13:50:10 UTC ---
(In reply to comment #8)
[..]
> Here the corrected code with proper comments.
[..]
> auto yyy = d.get();// #ifndef WITH_USING_DECLARATION ->
> Compile-time error-> GCC is
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-05-10 19:49:27 UTC ---
The internal error also occurs in gcc 4.8.0 HEAD. The issue does not describe
it clearly, therefore I mention it here: The code is ill-formed.
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-05-15 10:53:22 UTC ---
I can confirm this for gcc 4.8.0 20120513 (experimental).
A current workaround is to replace the member declaration
constexpr Foo(const Foo a) : m_a(a) {}
by
constexpr Foo(const
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-05-18 18:27:16 UTC ---
The problem also exists for gcc 4.8.0 20120513 (experimental) with or without
activating C++11 support. Further, if the reference to the type in template f
is a dependent form, like
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-05-18 18:29:28 UTC ---
gcc 4.8.0 HEAD also accepts the code
||googlemail dot com
--- Comment #6 from Daniel Krügler
2012-05-22 13:57:07 UTC ---
(In reply to comment #5)
> I think this is just a dup of bug 52072.
I agree.
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-05-24 07:19:28 UTC ---
I don't see why the expression A::get() should not be a converted constant
expression of the type of the template parameter, please be more specific. The
rationale provided i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53473
--- Comment #1 from Daniel Krügler
2012-05-25 06:56:06 UTC ---
This looks indeed like an odd compiler error and one really needs all three
specifiers static, constexpr, and *any* exception-specification to produce the
problem. For completeness th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53473
--- Comment #3 from Daniel Krügler
2012-05-25 09:07:20 UTC ---
(In reply to comment #2)
> Does the standard allow exceptions in constexpr? A throw is not exactly a
> return statement, but according to the rule "constexpr function shall satisfy
>
||googlemail dot com
--- Comment #3 from Daniel Krügler
2012-05-25 20:09:20 UTC ---
An interesting aspect of this example is that when using gcc 4.8.0 20120520
(experimental) compiled in C++11 mode with -Wall it produces the warning
"7|warning: 'i' is use
||googlemail dot com
--- Comment #3 from Daniel Krügler
2012-05-25 20:29:48 UTC ---
At least for a mingw built of boost 1.49 and with gcc 4.8.0 20120520
(experimental) I get no runtime problem.
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-05-25 20:42:45 UTC ---
This error also exists in gcc 4.8.0 20120520 (experimental) with the slightly
modified error location (-Wall -std=c++11):
"12|internal compiler error: in build_target_expr_with_typ
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-05-27 14:32:40 UTC ---
While the test code is somewhat broken, I found some suspicious compiler
behaviour when rewriting this into the following form, compiled with
-std=c++11 -Wall using gcc 4.8.0 20120520
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53498
--- Comment #3 from Daniel Krügler
2012-05-27 16:09:04 UTC ---
(In reply to comment #2)
> As you mention it, you don't accidently know, how a correct version would
> look?
This request would be off-topic here, but I responded off-list to you.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53494
--- Comment #14 from Daniel Krügler
2012-05-29 21:16:57 UTC ---
(In reply to comment #13)
> Am I interpreting correctly that double braces are /required/ for std::array
> init lists but only when the subtype has has a multivariable initializer to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53494
--- Comment #18 from Daniel Krügler
2012-05-30 06:25:27 UTC ---
(In reply to comment #16)
> "If the initializer-list begins with a left brace,"
>
> which it does
>
> "then the succeeding comma-separated list of initializer-clauses initializes
>
||googlemail dot com
--- Comment #4 from Daniel Krügler
2012-06-04 12:41:06 UTC ---
(In reply to comment #2)
> Looks like an infinite recursion between tsubst and tsubst_copy_and_build,
> does
> that ring a bell to someone?
Could this be a similar problem as
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-06-06 07:48:59 UTC ---
This looks like a clang extension to me, even though I must say that the
standard is currently not as clear as it could be (Keeping in mind that the
core language is currently considering
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53585
--- Comment #3 from Daniel Krügler
2012-06-06 20:06:56 UTC ---
(In reply to comment #2)
> I wonder whether that was the intent, and if so, what their rationale was.
> IMO it's very arbitrary and unintuitive, and for the life of me I can't think
>
||googlemail dot com
--- Comment #2 from Daniel Krügler
2012-06-10 11:57:57 UTC ---
(In reply to comment #1)
> Seems like my files are too large to be attached, hence you can find them here
> http://people.ubuntu.com/~rohangarg/gcc/
They need to be attached, but y
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53627
--- Comment #3 from Daniel Krügler
2012-06-10 21:11:41 UTC ---
This does not look like a compiler defect to me. Z::n has never been defined
but is odr-used.
||googlemail dot com
--- Comment #4 from Daniel Krügler
2012-06-10 21:23:05 UTC ---
(In reply to comment #2)
> This is exactly:
>
> http://gcc.gnu.org/wiki/VerboseDiagnostics#missing_static_const_definition
I agree. But let me just add that the first of the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53627
--- Comment #5 from Daniel Krügler
2012-06-10 21:26:27 UTC ---
(In reply to comment #4)
> (In reply to comment #2)
> > This is exactly:
> >
> > http://gcc.gnu.org/wiki/VerboseDiagnostics#missing_static_const_definition
>
> I agree. But let me
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53628
Bug #: 53628
Summary: [C++11][DR 712] Compiler requires definition of static
member constants when not odr-used
Classification: Unclassified
Product: gcc
Version: 4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53628
Daniel Krügler changed:
What|Removed |Added
Keywords||link-failure
--- Comment #1 from Daniel
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53628
--- Comment #2 from Daniel Krügler
2012-06-10 21:43:24 UTC ---
(In reply to comment #1)
> I would like to add that exactly the same example is still the main example of
> the otherwise valid explanations in
>
> http://gcc.gnu.org/wiki/VerboseDia
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53627
--- Comment #8 from Daniel Krügler
2012-06-11 06:47:42 UTC ---
(In reply to comment #7)
> (In reply to comment #4)
> > because that was fixed with C++11 due to
> >
> > http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#712
> >
> > Th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53627
--- Comment #8 from Daniel Krügler
2012-06-11 06:47:42 UTC ---
(In reply to comment #7)
> (In reply to comment #4)
> > because that was fixed with C++11 due to
> >
> > http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#712
> >
> > Th
||googlemail dot com
--- Comment #3 from Daniel Krügler
2012-06-20 12:26:27 UTC ---
I disaqree. IMO the example shall be ill-formed and it does not match the
referenced stackoverflow example. The specialization
template<>
int foo();
does not match the primary te
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53721
--- Comment #1 from Daniel Krügler
2012-06-20 12:34:44 UTC ---
I agree that the example should be accepted. I would like to add one further
related example directly from the standard specification. The example from
[expr.prim.general] p3 is also
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53657
--- Comment #10 from Daniel Krügler
2012-06-20 15:10:16 UTC ---
(In reply to comment #9)
Yes, this is to be expected, because gcc currently does not implement
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1402
I think fixing that
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53657
--- Comment #14 from Paolo Carlini 2012-06-20
15:26:06 UTC ---
Thanks for the no-include testcase Jon. Thus are we talking about the core
defect mentioned by Daniel? Should move this discussion to a C++ issue.
--- Comment #15 from Daniel Krügler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53733
Bug #: 53733
Summary: [C++11][DR 1402] Move constructor/assignment operator
too often deleted
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFI
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-06-20 18:46:53 UTC ---
I agree. For C++11 code there exists one further similarity, namely that f()
has static linkage like a function explicitly declared static in namespace
scope.
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-06-21 14:31:02 UTC ---
The test case works in gcc 4.8.0 20120610 (experimental)
||googlemail dot com
--- Comment #2 from Daniel Krügler
2012-06-23 09:58:58 UTC ---
I agree with Andrew, there is no object defined in the code, so the behaviour
is expected.
Since you are using C++11 mode you can use a pair of braces here:
Myclass instance1{};
This
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-06-24 18:38:50 UTC ---
This problem seems not to exist in 4.8.x HEAD, the error message is:
"25|error: template argument 1 is invalid"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53782
Bug #: 53782
Summary: Pointer to static function member expression rejected
in class template
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFI
||googlemail dot com
--- Comment #2 from Daniel Krügler
2012-06-26 20:25:16 UTC ---
The problem still exists in gcc 4.8.0 20120610 (experimental) compiled with
-Wall -pedantic -std=c++11. Here a variation of Johannes example based on a
similar Clang bug report from Doug
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-06-27 22:18:16 UTC ---
The problem still persists in gcc 4.8.0 20120624 (experimental):
"5|internal compiler error: tree check: accessed elt 2 of tree_vec with 1 elts
in tsubst_pack_expansion, at cp/pt.c:9374"
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-06-27 22:30:33 UTC ---
The problem also persists in gcc 4.8.0 20120624 (experimental).
Simplified example free from library dependencies:
struct t { static const bool value = true; };
struct f { static const
||googlemail dot com
--- Comment #2 from Daniel Krügler
2012-07-03 17:27:32 UTC ---
The problem persist in gcc 4.8.0 20120624 (experimental), even though the error
message is different (and no ICE anymore):
|In function 'void g()':|
9|error: '(const
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-07-03 17:38:56 UTC ---
The same problem exists for gcc 4.8.0 20120624 (experimental)
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-07-04 06:43:20 UTC ---
Same problem with gcc 4.8.0 20120624 (experimental)
||googlemail dot com
--- Comment #3 from Daniel Krügler
2012-07-05 09:47:01 UTC ---
The problem also exists for gcc 4.8.0 20120624 (experimental)
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-07-11 19:48:17 UTC ---
The problem also exists in gcc 4.8.0 20120708 (experimental)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54025
--- Comment #13 from Daniel Krügler
2012-07-19 15:18:16 UTC ---
(In reply to comment #12)
> Ah! Let's add in CC both Benjamin and Daniel then.
I more and more tend to change my mind: I recommend to ignore the
recommendation of N3303 and to make
||googlemail dot com
--- Comment #7 from Daniel Krügler
2012-07-20 13:59:41 UTC ---
In this context it is presumably interesting to mention a recently intended
core language change:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1423
I believe this change
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54043
--- Comment #8 from Daniel Krügler
2012-07-20 14:04:43 UTC ---
(In reply to comment #7)
> In this context it is presumably interesting to mention a recently intended
> core language change:
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_act
||googlemail dot com
--- Comment #2 from Daniel Krügler
2012-07-20 14:07:55 UTC ---
(In reply to comment #1)
> I think this behaviour is intentional and correct.
I completely agree with that.
||googlemail dot com
--- Comment #4 from Daniel Krügler
2012-07-20 18:58:28 UTC ---
DR 1423 has now reached ready status,
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1423
so this seems like a good reason to consider a compiler change to evaluate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54043
--- Comment #10 from Daniel Krügler
2012-07-20 19:02:35 UTC ---
(In reply to comment #9)
> (In reply to comment #8)
> > > Jonathan, given the state of 1423, should I open a new reminder bugzilla
> > > entry
> > > to take care of this? AFAIK we h
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-07-20 19:18:03 UTC ---
Your example can be reduced to the following model code:
template
struct A
{
struct B : A { };
};
I can assure you that you cannot rely on that. This example has recently been
raised
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51213
Daniel Krügler changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-07-24 11:00:23 UTC ---
Strictly speaking you are right that this should be ill-formed as of the C++11
wording. This is due to the fact that [dcl.init.aggr] p11 allows brace-elision
*only* for the specific
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-07-24 11:07:53 UTC ---
The problem exists in gcc 4.8.0 20120722 (experimental) as well
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-07-25 18:41:03 UTC ---
The error still exists in gcc 4.8.0 20120722 (experimental):
internal compiler error: in unify, at cp/pt.c:16641
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54161
Bug #: 54161
Summary: sizeof(void) expressions are accepted
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54161
--- Comment #2 from Daniel Krügler
2012-08-02 20:13:29 UTC ---
(In reply to comment #1)
> Jason can you double check whether we
> want to reject even without -pedantic?
I hope it will be active even without -pedantic
> Anyway, Daniel, it would
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52072
Bug #: 52072
Summary: Several non-deduced context not recognized
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priorit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51786
--- Comment #3 from Daniel Krügler
2012-01-31 21:26:41 UTC ---
It seems to me that all these examples should be rejected (Thanks to Jens
Maurer for helping me here): At first it seems, that we can follow the grammar
chain starting from /declarati
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52114
--- Comment #4 from Daniel Krügler
2012-02-04 21:44:24 UTC ---
(In reply to comment #3)
> (PS: Daniel tweaked tuple_cat the same way)
There is a difference here: For tuple_cat we have a user constraint that says
that the template argument shall
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52114
--- Comment #11 from Daniel Krügler
2012-02-05 11:00:00 UTC ---
(In reply to comment #8)
> But using decltype((o<
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-02-07 13:51:59 UTC ---
(In reply to comment #0)
The core language is in the process to make it clear, that S().n no longer is a
null-pointer constant, see
http://www.open-std.org/jtc1/sc22/wg21/docs
||googlemail dot com
--- Comment #2 from Daniel Krügler
2012-02-12 13:26:04 UTC ---
My reading of 11.3 p9,
"A name nominated by a friend declaration shall be accessible in the scope of
the class containing the friend declaration."
tends to be that the exam
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52216
Bug #: 52216
Summary: [C++11][noexcept] Wrong exception deduction for some
forms of placement new
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNC
301 - 400 of 884 matches
Mail list logo
