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
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
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
++
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 potswa at mac dot com ---
On 2015–06–18, at 5:58 AM, redi at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org
wrote:
These changes shouldn't affect the ABI.
Eh… the simplest case of a fancy pointer is a raw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55409
--- Comment #13 from David Krauss potswa at mac dot com ---
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
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=35790action=edit
Test case
A std::set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66559
--- Comment #2 from David Krauss potswa at mac dot com ---
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
++
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 functional
#include cassert
struct s
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 constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66001
--- Comment #1 from David Krauss potswa at mac dot com ---
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 initializer_list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59766
--- Comment #9 from David Krauss potswa at mac dot com ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65159
--- Comment #10 from David Krauss potswa at mac dot com ---
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 #12 from David Krauss potswa at mac dot com ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65159
--- Comment #8 from David Krauss potswa at mac dot com ---
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
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 file
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 file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59766
--- Comment #5 from David Krauss potswa at mac dot com ---
Created attachment 34538
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34538action=edit
ChangeLog entry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59766
--- Comment #6 from David Krauss potswa at mac dot com ---
Created attachment 34541
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34541action=edit
Fix: disable the error for friend declarators.
The fix is simple. Tested and submitted
++
Assignee: unassigned at gcc dot gnu.org
Reporter: potswa at mac dot com
#include new
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60262
David Krauss potswa at mac dot com changed:
What|Removed |Added
CC||potswa at mac dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62221
David Krauss potswa at mac dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58844
--- Comment #11 from David Krauss potswa at mac dot com ---
On 2014–08–12, at 3:10 PM, jakub at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org
wrote:
Please see https://gcc.gnu.org/ml/gcc-patches/2009-04/msg01490.html for
reasoning why gcc considers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61613
--- Comment #4 from David Krauss potswa at mac dot com ---
Created attachment 33288
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33288action=edit
Fix
Well, I decided to Do The Right Thing for users. Here is a working patch.
Let's see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61613
--- Comment #6 from David Krauss potswa at mac dot com ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58844
David Krauss potswa at mac dot com changed:
What|Removed |Added
CC||potswa at mac dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61613
David Krauss potswa at mac dot com changed:
What|Removed |Added
CC||potswa at mac dot
++
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,
enum does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61584
--- Comment #2 from David Krauss potswa at mac dot com ---
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
++
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61492
--- Comment #1 from David Krauss potswa at mac dot com ---
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
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 type ‘int
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42844
David Krauss potswa at mac dot com changed:
What|Removed |Added
CC||potswa at mac dot com
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
const-qualified
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 member i
instead of np
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60297
--- Comment #1 from David Krauss potswa at mac dot com ---
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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57350
--- Comment #11 from David Krauss potswa at mac dot com ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57350
--- Comment #9 from David Krauss potswa at mac dot com ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57350
--- Comment #4 from David Krauss potswa at mac dot com ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57350
--- Comment #5 from David Krauss potswa at mac dot com ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57350
--- Comment #7 from David Krauss potswa at mac dot com ---
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=59872
--- Comment #7 from David Krauss potswa at mac dot com ---
That's a better factoring. I was just avoiding creating a new, named function.
Thanks!
: 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 map
#include memory
std::map int
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59872
--- Comment #1 from David Krauss potswa at mac dot com ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59872
--- Comment #3 from David Krauss potswa at mac dot com ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59872
--- Comment #4 from David Krauss potswa at mac dot com ---
Created attachment 31884
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31884action=edit
SFINAE based fix
This seems stylistically OK, but I did copy-paste the implementation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59872
David Krauss potswa at mac dot com changed:
What|Removed |Added
Attachment #31884|0 |1
is obsolete
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59186
David Krauss potswa at mac dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
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 the body of a nonstatic member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59186
--- Comment #1 from David Krauss potswa at mac dot com ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57520
David Krauss potswa at mac dot com changed:
What|Removed |Added
CC||potswa at mac dot com
++
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 typename
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58147
David Krauss potswa at mac dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
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 functional
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
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 specifier.
The issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57857
--- Comment #1 from David Krauss potswa at mac dot com ---
Narrowing down the cause, the statement { 0; } silences the error but {
void(0); } does not.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57714
--- Comment #14 from David Krauss potswa at mac dot com ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57714
--- Comment #15 from David Krauss potswa at mac dot com ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57714
--- Comment #17 from David Krauss potswa at mac dot com ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57714
--- Comment #10 from David Krauss potswa at mac dot com ---
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
: 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=57714
--- Comment #2 from David Krauss potswa at mac dot com ---
Andrew, are you sure? The zero should remain on the same line as the return
token.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57714
--- Comment #3 from David Krauss potswa at mac dot com ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57714
--- Comment #5 from David Krauss potswa at mac dot com ---
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 #6 from David Krauss potswa at mac dot com ---
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 #7 from David Krauss potswa at mac dot com ---
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 #8 from David Krauss potswa at mac dot com ---
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
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=57673
--- Comment #1 from David Krauss potswa at mac dot com ---
Oops, g::m does not need to be static constexpr to produce an error; the
specifiers should be removed to produce a minimal test.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57593
--- Comment #2 from David Krauss potswa at mac dot com ---
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
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 se, so
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57419
--- Comment #5 from David Krauss potswa at mac dot com ---
Does this also fix #57429?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57429
--- Comment #1 from David Krauss potswa at mac dot com ---
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 #2 from David Krauss potswa at mac dot com ---
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
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
is accessed
++
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
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
accessed
: 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=57350
--- Comment #1 from David Krauss potswa at mac dot com ---
Oh, here's a link to my version:
http://code.google.com/p/c-plus/source/browse/src/util.h#50
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56567
--- Comment #7 from David Krauss potswa at mac dot com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56567
--- Comment #8 from David Krauss potswa at mac dot com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56567
--- Comment #4 from David Krauss potswa at mac dot com 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
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=56568
Bug #: 56568
Summary: std::initializer_list return value contents lost
prematurely
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49122
David Krauss potswa at mac dot com changed:
What|Removed |Added
CC||potswa at mac
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55576
David Krauss potswa at mac dot com changed:
What|Removed |Added
CC||potswa at mac
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56333
--- Comment #2 from David Krauss potswa at mac dot com 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=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=56317
--- Comment #1 from David Krauss potswa at mac dot com 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=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=56283
Bug #: 56283
Summary: std::result_of does not gracefully SFINAE (not define
::type)
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56283
--- Comment #1 from David Krauss potswa at mac dot com 2013-02-11 04:57:46
UTC ---
Note, defining the trait with the expression
declvalFn()(declvalArgTypes()...) does work. Clang 3.1/libc++ behaves the
same way.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55986
--- Comment #3 from David Krauss potswa at mac dot com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55986
Bug #: 55986
Summary: RHS of logical operators may render LHS unevaluated in
constant-expression
Classification: Unclassified
Product: gcc
Version: unknown
1 - 100 of 193 matches
Mail list logo
