https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53660
David Krauss changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53660
--- Comment #2 from David Krauss ---
(In reply to Andrew Pinski from comment #1)
> I don't think this is a bug.
Right, the behavior looks correct.
As for a nested-name-specifier working in this context, it works if it's not
dependent. As for th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66284
--- Comment #3 from David Krauss ---
… Woops, that f is the function parameter, not the target. So it's not a
conflicting requirement, but it could be a template for fixing the the copy
constructor constraint.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66284
--- Comment #2 from David Krauss ---
The converting constructor requirements also say more explicitly,
shall not throw exceptions when f is a function pointer
or a reference_wrapper for some T.
Probably the copy constructor should be worded
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: potswa at mac dot com
Target Milestone: ---
A braced-init-list in a default function argument does not receive friendship
as it should.
class A {
A() {}
friend int ok(A);
friend int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56568
--- Comment #5 from David Krauss ---
(In reply to fuzzyTew from comment #4)
The original testcase is invalid. initializer_list is special in that it
behaves like a reference, so adding && doesn't make a difference.
I'm working on an ISO proposa
++
Assignee: unassigned at gcc dot gnu.org
Reporter: potswa at mac dot com
Target Milestone: ---
false should not convert to pointer types since C++11. This program is ill
formed in C++03 and well formed in C++11.
struct s {
s( long ) {}
};
struct t {
t( void * ) {}
}
void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55409
--- Comment #15 from David Krauss ---
> On 2015–06–18, at 5:58 AM, redi at gcc dot gnu.org
> wrote:
>
> These changes shouldn't affect the ABI.
Eh… the simplest case of a fancy pointer is a raw pointer to a class derived
from value_type. The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55409
--- Comment #13 from David Krauss ---
Nice!
Just a few things:
1. Line 304: rebind isn’t an official member of allocator_traits. Prefer
rebind_alloc.
2. _M_put_node is assuming no fancy pointers: its parameter is a
_Node_alloc_traits::pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66559
--- Comment #2 from David Krauss ---
That bug only mentions missing allocator_traits support.
It looks like the problem here is that _List_node declares a member _Tp and
initializes it, whereas it should declare aligned storage for a _Tp and let
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: potswa at mac dot com
Target Milestone: ---
Created attachment 35790
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35790&action=edit
Test case
A std::set
++
Assignee: unassigned at gcc dot gnu.org
Reporter: potswa at mac dot com
Target Milestone: ---
std::allocator_traits does not contain a member is_equal, as required since
C++11.
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: potswa at mac dot com
Target Milestone: ---
std::function elides reference_wrappers from the target. This is not
conforming.
#include
#include
struct s { void operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66001
--- Comment #1 from David Krauss ---
If a non-constexpr constructor is addend to struct dt, the behavior is
different, and inconsistent between a bound temporary and an initializer_list
sequence.
#include
struct dt
{ dt() {} ~ dt() {} };
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: potswa at mac dot com
Target Milestone: ---
Works in 4.9.2, broken in 5.1. Not sure about 5.
struct x {
struct dt { ~ dt() {} }
const & m = {};
} cx;
in const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59766
--- Comment #9 from David Krauss ---
I didn't send it to gcc-patches. It's never been necessary for me before. I
suppose I can collect the examples here into a testcase file. In the meantime,
anyone else is free to take charge and submit it on th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65159
--- Comment #12 from David Krauss ---
I did exactly the steps that I mentioned: cleanly build r220825, update to
r22, and build again without cleaning first. The object being to roughly
replicate the conditions when the bug was originally obs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65159
--- Comment #10 from David Krauss ---
I made a clean build of r220825, and it succeeded. Then I downgraded to
r22, and it produced similar link errors, although not in type_info.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65159
--- Comment #8 from David Krauss ---
It was an updated tree. I'm not sure what revision it was updated from, but it
was probably late January.
Sorry for the delay, my machine got completely hosed by a bad RAM chip. Took
the filesystem with it. S
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: potswa at mac dot com
The grammar seems to be missing an allowance for the && token after a
class-specifier. This fails:
struct {} && m = {};
This works:
struct {} const && m = {};
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: potswa at mac dot com
In r220825 on Darwin/x64, the build fails with a complaint that
type_info::__is_pointer_p is undefined, although it's still there in
libstdc++-v3/libsupc++/tinfo.cc as ever.
If I go to that
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: potswa at mac dot com
In r220825 on Darwin/x64, the build fails with a complaint that
type_info::__is_pointer_p is undefined, although it's still there in
libstdc++-v3/libsupc++/tinfo.cc as ever.
If I go to that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59766
--- Comment #6 from David Krauss ---
Created attachment 34541
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34541&action=edit
Fix: disable the error for friend declarators.
The fix is simple. Tested and submitted for approval. (I am a reg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59766
--- Comment #5 from David Krauss ---
Created attachment 34538
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34538&action=edit
ChangeLog entry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62221
David Krauss changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60262
David Krauss changed:
What|Removed |Added
CC||potswa at mac dot com
--- Comment #1
++
Assignee: unassigned at gcc dot gnu.org
Reporter: potswa at mac dot com
#include
struct b {
virtual ~ b() {}
};
struct d : b {
~ d () {}
};
int main() {
d o;
o.~b();
new( & o ) d;
}
This is ill formed but is accepted. Clang, EDG, and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58844
--- Comment #11 from David Krauss ---
On 2014–08–12, at 3:10 PM, jakub at gcc dot gnu.org
wrote:
> Please see https://gcc.gnu.org/ml/gcc-patches/2009-04/msg01490.html for
> reasoning why gcc considers it valid.
That reasoning goes awry at “ISO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58844
David Krauss changed:
What|Removed |Added
CC||potswa at mac dot com
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61613
--- Comment #6 from David Krauss ---
The patch should already pass the coding standards. I'm already legally
registered as a contributor.
Arthur, can you take care of the rest of the process? (Did you get my email?)
I'd like to take it 100% but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61613
--- Comment #4 from David Krauss ---
Created attachment 33288
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33288&action=edit
Fix
Well, I decided to Do The Right Thing for users. Here is a working patch.
Let's see what the maintainers do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61613
David Krauss changed:
What|Removed |Added
CC||potswa at mac dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61584
--- Comment #2 from David Krauss ---
C "compatible type" determines integer conversion rank (C11 §6.3.1.1). C++
fixes the rank by a heuristic which the implementation cannot decide (C++11
§4.5/3).
Currently, enum promotions are incompatible betw
++
Assignee: unassigned at gcc dot gnu.org
Reporter: potswa at mac dot com
This is not a library bug because std::underlying_type simply wraps the
__underlying_type() intrinsic.
enum x {};
static_assert( std::is_same< std::underlying_type< x >::type, int >::value,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61492
--- Comment #1 from David Krauss ---
Oops, objects hide enumerations in this context too.
enum e { m } e = e::m; // Same error
I neglected to check this because I thought I'd used it a while ago, but it
turns out I'd worked around the problem.
++
Assignee: unassigned at gcc dot gnu.org
Reporter: potswa at mac dot com
Name lookup of a nested-name-specifier should only find entities with
associated scopes: namespaces, classes, and enumerators. GCC allows a function
name to hide an enumerator. (Classes and namespaces are
NCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: potswa at mac dot com
GCC incorrectly rejects this value-initialization of an array element:
int a[] = { {} }; // error: braces around scalar initializer for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60297
--- Comment #1 from David Krauss ---
Woops, I neglected to check a POD class type. Removing the destructor from
"notpod" has no effect. The condition seems to apply to all scalar types
instead.
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: potswa at mac dot com
The resolution to DR 1651 seems inconsistently applied. This program should
print "check" before "destroy", but if the reference is bound to membe
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: potswa at mac dot com
This declaration is ill-formed according to the last sentence of [dcl.init]
§8.5/7, "If a program calls for the default initialization of an object of a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42844
David Krauss changed:
What|Removed |Added
CC||potswa at mac dot com
--- Comment #17
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57350
--- Comment #11 from David Krauss ---
No, that code wasn't right either. I'll just leave it at this and a caveat to
the reader:
inline void *align( std::size_t alignment, std::size_t size,
void *&ptr, std::size_t &space ) {
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57350
--- Comment #9 from David Krauss ---
Whoa, there's a nasty bug there, if alignment > space.
inline void *align( std::size_t alignment, std::size_t size,
void *&ptr, std::size_t &space ) {
std::uintptr_t pn = reinterpret_ca
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57350
--- Comment #7 from David Krauss ---
Haha, it looks like the MSVC devs forgot to subtract 1. Typical.
I did test my code in a real arena allocator, by the way, so that sort of thing
would not have gotten through.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57350
--- Comment #5 from David Krauss ---
Just re-reading now, std::size_t should be std::uintptr_t, but I don't see
anything else that could cause UB. The bitwise "negative" arithmetic should be
OK because it's all on unsigned values.
And if GNU styl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57350
--- Comment #4 from David Krauss ---
Hmm, I recall preparing to submit a patch but not being able to decide which
header to modify.
Here's the aforementioned MIT-licensed code. The MIT license only requires
attribution which is satisfied by the c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59872
--- Comment #7 from David Krauss ---
That's a better factoring. I was just avoiding creating a new, named function.
Thanks!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59872
David Krauss changed:
What|Removed |Added
Attachment #31884|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59872
--- Comment #4 from David Krauss ---
Created attachment 31884
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31884&action=edit
SFINAE based fix
This seems stylistically OK, but I did copy-paste the implementation of moving.
Perhaps the commo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59872
--- Comment #3 from David Krauss ---
Thanks, I'm working on it now.
Is there some precedent for this kind of SFINAE in libstdc++? The hard part is
getting the style right. Metaprogramming looks weird in 80 columns.
As for the defect report, my t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59872
--- Comment #1 from David Krauss ---
It looks like the allocator-aware update introduced a copying branch to the
move constructor, to handle the case of transferring an object from one
stateful allocator to another.
The branch on _Alloc_traits::_
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: potswa at mac dot com
This fails because the std::map move constructor apparently invokes a copy
operation. It was working recently (on trunk), so it looks like a regression.
#include
#include
std::map< int,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59186
David Krauss changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59186
--- Comment #1 from David Krauss ---
Just to clarify, in the last paragraph, decltype(this) has the same meaning in
both cases according to the standard but the bug causes it to refer to the
inner type instead of the outer type.
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: potswa at mac dot com
In the following TU, GCC 4.9 accepts the "error" line and rejects the "Same as
previous" line.
The "this" keyword is well-defined inside
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57520
David Krauss changed:
What|Removed |Added
CC||potswa at mac dot com
--- Comment #3 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58147
David Krauss changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
++
Assignee: unassigned at gcc dot gnu.org
Reporter: potswa at mac dot com
Although the usage is a bit dubious, name lookup of the identifier after a
nested-name-specifier should not find a template parameter name. But it does,
seemingly only for a template template parameter.
template< typen
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: potswa at mac dot com
[dcl.fct.default] 8.3.6/3 says
A default argument shall be specified … in a template-parameter (14.1); in the
latter case, the initializer-clause shall be an assignment-expression.
So a default
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: potswa at mac dot com
#include
struct s { void f() &; };
s *p;
auto b = std::bind( &s::f, p );
Resulting error:
error: forming reference to qualified function type ‘void() &’
The original case produced
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57857
--- Comment #1 from David Krauss ---
Narrowing down the cause, the statement { 0; } silences the error but {
void(0); } does not.
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: potswa at mac dot com
The following program complains that "declval() must not be used!" in a static
assertion if -Wall is passed. But declval() is only present in the unevaluated
context of a decltype speci
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57714
--- Comment #17 from David Krauss ---
Yes, my preprocessor classifies the backslash-after-preprocessing as a
whitespace token. I simply don't intend to make textual preprocessing output.
With raw strings, UCNs, and user-defined literals, there's j
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57714
--- Comment #15 from David Krauss ---
Corrections to previous: Harald's comment is #11, and I meant to refer to the
commits in my repo from
http://code.google.com/p/c-plus/source/detail?r=d462b650c355b606545158f4da7365180b699752
up through
http://
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57714
--- Comment #14 from David Krauss ---
Harald's comment #10 is almost accurate, but for two things:
1. Actually the C standard does care whether whitespace is added. Whitespace is
visible in the result of stringizing, and when comparing duplicate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57714
--- Comment #10 from David Krauss ---
I don't plan on fixing this in GCC, but I did implement the feature today in my
own preprocessor, http://code.google.com/p/c-plus/source/list . It does require
a handshake between phases 2 and 3, because a tok
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57714
--- Comment #8 from David Krauss ---
Probably what happened:
1. In preserving visual appearance, tokens not separated by spaces are kept
together.
2. Line splicing happens before spaces are identified for the above.
3. The { and return tokens are
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57714
--- Comment #7 from David Krauss ---
Oh, OK, now I followed that link. Splicing is supposed to be transparent unless
you specify -P. This still qualifies as a bug.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57714
--- Comment #6 from David Krauss ---
Just to clarify the last comments, the input
main(){\
return 0;
}
translates via cpp to
main(){
return 0;
}
i.e. no splicing is apparent in the output.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57714
--- Comment #5 from David Krauss ---
What? That makes even less sense. Are you guys familiar with the concept of
line splicing? See "phases of translation" in the Standard, namely phase 2.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57714
--- Comment #3 from David Krauss ---
See section 9 of the manual:
http://gcc.gnu.org/onlinedocs/gcc-4.8.1/cpp/Preprocessor-Output.html#Preprocessor-Output
The output from the C preprocessor looks much like the input, except that all
preprocessing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57714
--- Comment #2 from David Krauss ---
Andrew, are you sure? The zero should remain on the same line as the "return"
token.
: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: potswa at mac dot com
main(){\
return 0;
}
preprocesses to
main(){return
0;
}
The problem only appears in output from the -E option; observing the newline
within the program as with
#define main(){\
return 0;
}
main
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57673
--- Comment #1 from David Krauss ---
Oops, g::m does not need to be static constexpr to produce an error; the
specifiers should be removed to produce a minimal test.
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: potswa at mac dot com
In this example, template g compiles without issue but each member in d chokes
the parser. The only difference is grouping parentheses, which shouldn't be
significant.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57593
--- Comment #2 from David Krauss ---
The maintainer (Mike Miller at EDG) said simply that he will add it to the
list, but as far as I know a number isn't assigned until the new list is
drafted. The title is "access granted by friendship to class-s
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: potswa at mac dot com
The access granted by friendship extends into the "member declarations of the
befriended class" (11.3/2). Friend declarations are member-declarations but not
member declarations per
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57429
--- Comment #1 from David Krauss ---
To clarify the example, it's failing at definition time. There are two separate
failures illustrated, a function template and a class template.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57419
--- Comment #5 from David Krauss ---
Does this also fix #57429?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57419
--- Comment #2 from David Krauss ---
I guess the proper terminology would be taking its pointer. Nonstatic members
don't really have addresses. Anyway what I was doing was determining the
argument of a functor with one operator() overload using &f
++
Assignee: unassigned at gcc dot gnu.org
Reporter: potswa at mac dot com
The example below should fail with access to a deleted function, but is
accepted by GCC 4.9. Clang correctly rejects it.
The issue is that [basic.lookup.argdep] §3.4.2/2 is defined in terms of
namespace
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: potswa at mac dot com
A dependent function call can't be resolved until instantiation time, but if
there's only one candidate visible from the template definition, that candidate
i
ormal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: potswa at mac dot com
Using reference-to-member syntax on a private, deleted function in a SFINAE
context fails as a hard error as a use of a deleted function. But it can't be
acces
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57350
--- Comment #1 from David Krauss ---
Oh, here's a link to my version:
http://code.google.com/p/c-plus/source/browse/src/util.h#50
: unassigned at gcc dot gnu.org
Reporter: potswa at mac dot com
C++11 §20.6.5 [ptr.align] remains unimplemented.
Several years ago I published what now appears to be a compliant
implementation, but it was under the MIT license. Does that disqualify that
code, or me, from submitting a patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56567
--- Comment #8 from David Krauss 2013-03-11 22:51:12
UTC ---
Oops, I didn't see the preceding comment & checkin before submitting that.
Maybe that's a better place to check, but we might keep the extra test cases.
Make sure that the remain
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56567
--- Comment #7 from David Krauss 2013-03-11 22:42:46
UTC ---
Created attachment 29647
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29647
alternative fix
Yes. However, the above fix doesn't catch all instances of doing so; for
ex
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56567
--- Comment #4 from David Krauss 2013-03-10 02:18:18
UTC ---
Note, there is nothing in the Standard to prohibit return of an
initializer_list value, so this rejects programs which are conformant.
Unless/until #56568 is resolved, doing so
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56568
Bug #: 56568
Summary: std::initializer_list return value contents lost
prematurely
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56567
Bug #: 56567
Summary: ICE with lambda return type deduction and
braced-init-list
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49122
--- Comment #8 from David Krauss 2013-03-08 07:57:03
UTC ---
Oops, I didn't read the original code closely enough. To be OK by the above
interpretation, the local initializer_list variable would need to be eliminated
from main() and the lo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49122
David Krauss changed:
What|Removed |Added
CC||potswa at mac dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55576
David Krauss changed:
What|Removed |Added
CC||potswa at mac dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56333
--- Comment #2 from David Krauss 2013-02-15 15:43:07
UTC ---
Also fixed within a day of updating my sources. Thanks guys!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56333
Bug #: 56333
Summary: cannot use typedef name in inheriting constructor
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56317
--- Comment #1 from David Krauss 2013-02-14 09:35:12
UTC ---
(But, perfect forwarding equivalent to the inheriting constructor semantic does
work around the issue.)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56317
Bug #: 56317
Summary: inheriting constructor fails to move brace-initialized
object
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56283
--- Comment #1 from David Krauss 2013-02-11 04:57:46
UTC ---
Note, defining the trait with the expression
declval()(declval()...) does work. Clang 3.1/libc++ behaves the
same way.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56283
Bug #: 56283
Summary: std::result_of does not gracefully SFINAE (not define
::type)
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55986
--- Comment #3 from David Krauss 2013-01-15 08:02:55
UTC ---
Likewise this is allowed:
switch( 0 )
case i-i: ;
I think this is a purposeful language extension, which could use a switch to
disable. It would be nice if static_assert we
1 - 100 of 195 matches
Mail list logo
