http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57063
--- Comment #4 from Nikolka 2013-04-25 13:51:21 UTC ---
It looks like the root of the issue is that static_cast produces an expression
with wrong value category sometimes.
#include
#include
#define PRINT_VALUE(...) \
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57063
--- Comment #2 from Nikolka 2013-04-25 07:19:20 UTC ---
The alias is added for convenience - we can quickly test handling of different
types so. It seems that there is no problem with class types and function
types, the error arises when T is a s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57063
Bug #: 57063
Summary: Valid static_cast from data member to rvalue reference
fails to compile
Classification: Unclassified
Product: gcc
Version: 4.8.1
Status: UNCONF
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56192
Bug #: 56192
Summary: global operator new() vs member operator new()
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54543
Bug #: 54543
Summary: Expression (condition ? array : throw expr)[index]
fails to compile
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54542
Bug #: 54542
Summary: SFINAE bug: handling new expressions
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54541
Bug #: 54541
Summary: SFINAE bug: handling incomplete return types
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Prior
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51317
Nikolka changed:
What|Removed |Added
Version|4.7.0 |4.8.0
--- Comment #1 from Nikolka 2012-09-10 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54506
--- Comment #8 from Nikolka 2012-09-10 06:26:02 UTC ---
(In reply to comment #7)
> (In reply to comment #3)
> > g++ v4.7.2 20120908 (prerelease) compiles the original example successfully,
> > but it fails to compile the following code:
>
> G++ i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54506
--- Comment #5 from Nikolka 2012-09-09 22:42:03 UTC ---
(In reply to comment #4)
These examples aren't similar. An implicitly defined move constructor performs
direct-initialization of non-static data members with the corresponding members
of the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54506
--- Comment #3 from Nikolka 2012-09-09 20:55:38 UTC ---
g++ v4.7.2 20120908 (prerelease) compiles the original example successfully,
but it fails to compile the following code:
template
struct A
{
A() {}
A(A cons
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54521
--- Comment #3 from Nikolka 2012-09-08 13:25:20 UTC ---
In both cases (for g++ v4.7.1 and v4.8.0) the only compiler option was
-std=c++11. Nothing magical.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54526
Bug #: 54526
Summary: <:: is incorrectly treated as digraph <: followed by
colon
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54521
--- Comment #2 from Nikolka 2012-09-08 12:36:29 UTC ---
(In reply to comment #1)
> Works fine with 4.6.3, 4.7.2 20120716 (prerelease) and
> 4.8.0 20120716 (experimental)
>
> As requested when submitting the bug, please provide the information re
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54506
--- Comment #2 from Nikolka 2012-09-08 12:17:24 UTC ---
(In reply to comment #1)
> How are you calling g++?
/mingw-gcc-4.7.1/bin/g++ test.cpp -std=c++11
> What version are you using?
Target: i686-pc-mingw32
Configured with: ../src/configure --p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54521
Bug #: 54521
Summary: g++ fails to call explicit constructors in the second
step of copy initialization
Classification: Unclassified
Product: gcc
Version: 4.7.1
Statu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54506
Bug #: 54506
Summary: Defaulted move constructors and move assignment
operators are erroneously defined as deleted
Classification: Unclassified
Product: gcc
Version: 4.7.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52625
Nikolka changed:
What|Removed |Added
CC||tsoae at mail dot ru
--- Comment #1 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51316
--- Comment #5 from Nikolka 2011-12-28 22:06:18 UTC ---
> On it.
There is an active core issue about alignof:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3309.html#1305
Probably, you should take into account the proposed resolution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51316
--- Comment #2 from Nikolka 2011-11-27 08:37:37 UTC ---
> Note that this usage is not valid in C1X.
Could you explain?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51317
Bug #: 51317
Summary: Wrong value category of conditional expression where
lvalue operands differ only in cv-qualification (see
DR 587)
Classification: Unclassified
Prod
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51316
Bug #: 51316
Summary: alignof doesn't work with arrays of unknown bound
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51312
--- Comment #2 from Nikolka 2011-11-26 15:33:36 UTC ---
> For the first one, you should write X{} instead of X() which looks too much
like a function type.
I agree, that was my mistake.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51312
Bug #: 51312
Summary: Wrong interpretation of converted constant expressions
(for template arguments and enumerator initializers)
Classification: Unclassified
Product: gcc
Versio
24 matches
Mail list logo
