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=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=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 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=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=55576
David Krauss changed:
What|Removed |Added
CC||potswa at mac dot com
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=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=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: UNCONFIR
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=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 #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
nu dot org
ReportedBy: potswa at mac dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41351
--- Comment #4 from potswa at mac dot com 2009-09-14 16:35 ---
I doubt that stable_partition can't be implemented with std::swap. If I
understand you the problem lies in the temporary_buffer, which is uninitialized
memory and hence un-swappable. One solution would be simp
--- Comment #6 from potswa at mac dot com 2009-09-14 18:00 ---
If the alternative stable_partition is faster, maybe it should be used anyway.
For large blocks, virtual memory allocation time may dominate computation, so
it should certainly be faster sometimes.
Back to rotate, I was
--- Comment #8 from potswa at mac dot com 2009-09-14 21:36 ---
Well, if fast is good, maybe you will consider this:
const _Distance __d = __gcd(__n, __k), __r = __n / __d;
for ( _Distance __i = 0; __i < __d; ++ __i ) {
_ValueType __tmp = *__fi
--- Comment #10 from potswa at mac dot com 2009-09-14 23:59 ---
I'll look into it. That's a long list to do and learn ;v) .
I think the general idea here is that the compiler is good at optimizing out
the useless moves generated by swap. It turns out that my code has less of
--- Comment #12 from potswa at mac dot com 2009-09-15 08:55 ---
Just for safekeeping, here's the body of the final code. It's much faster than
the current revision on my machine, 2.2 sec for 100 iterations rotating a 10
million int vector 5 places left or right, vs 10.5 sec
--- Comment #17 from potswa at mac dot com 2009-09-15 14:33 ---
Hmm, on my Core2 my impl still beats the present one on many cases of shift by
1, but the margin is narrower.
Shift by 1 is the only case where the temporary can really help, and I
eliminated it completely. I suppose I
--- Comment #21 from potswa at mac dot com 2009-09-15 14:56 ---
Just to be clear that "working properly" in this context means "working faster"
;v) .
I just coded up a special case for k = ± 1 that uses std::copy, which should
map to memmove for std::vector::iterat
--- Comment #23 from potswa at mac dot com 2009-09-15 15:29 ---
With the new special case, I get 3x faster than current for n = 100, k = 99.
Now it weighs in at 45 lines in my style, before conversion to official style,
and not coincidentally I don't really feel like posting it
--- Comment #25 from potswa at mac dot com 2009-09-23 21:07 ---
Hello Donald,
A week has passed. Do the papers usually take this long?
- thanks,
D
On Sep 15, 2009, at 1:45 PM, ass...@gnu.org via RT wrote:
Hello David,
Thank you for contributing to GNU software
--- Comment #28 from potswa at mac dot com 2009-10-05 05:01 ---
I'm still waiting for the IP assignment papers. This is kinda disappointing.
Hopefully I'll get a reply this time
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41351
--- Comment #30 from potswa at mac dot com 2009-10-07 19:57 ---
The FSF receptionist says that the lawyer seems to have taken an unannounced
vacation this week. It's now three weeks since I requested the forms (and since
he confirmed my request). What is the timeframe we're sh
--- Comment #32 from potswa at mac dot com 2009-10-10 01:15 ---
I have little experience in this field, so you would probably be a better judge
of the best alternative to complete revision. My suggested code is a complete
rewrite, based on creating a new algorithm from first principles
--- Comment #33 from potswa at mac dot com 2009-10-17 20:45 ---
I returned the copyright forms today, so now the wheels are turning :vD .
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41351
--- Comment #35 from potswa at mac dot com 2009-10-30 02:47 ---
I got PDF's of the completed forms. What now?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41351
--- Comment #37 from potswa at mac dot com 2009-10-30 03:55 ---
It seems like the goals are changing. Is this due to an approaching deadline?
The "super" algorithm is the product of making every case faster. Removing any
part of it (i.e. calls to std::copy) will regress perf
--- Comment #38 from potswa at mac dot com 2009-10-30 03:56 ---
Created an attachment (id=18932)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18932&action=view)
C++ snippet containing example function template
improved algorithm with forward/backward and std::cop
--- Comment #41 from potswa at mac dot com 2009-10-30 19:07 ---
Created an attachment (id=18934)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18934&action=view)
table of benchmarks comparing various algorithms and parameters
As the Euclidean ring division algorithm swe
--- Comment #42 from potswa at mac dot com 2009-10-30 19:14 ---
Sorry, "once per ring" doesn't guarantee more than one pass for k=2 and n odd,
or the test case I presented. Better to say there are k passes, although
performance should improve for n/k on the order of cach
--- Comment #44 from potswa at mac dot com 2009-11-03 03:56 ---
When does _GLIBCXX_MOVE3 do the wrong thing? I can see only doing the k=1
optimization #ifdef __GXX_EXPERIMENTAL_CXX0X__ after all, copying is the
misbehavior this bug is filed against in the first place! But std::move
--- Comment #47 from potswa at mac dot com 2009-11-03 17:21 ---
What is the function of the helper class? I suppose the user could get improved
performance by specializing __is_scalar, but that could have
unintended consequences (resulting from the class not being scalar), not to
--- Comment #50 from potswa at mac dot com 2009-11-03 17:53 ---
The current RAI algo uses a temporary regardless of size or class. We could put
in a "&& sizeof(_ValueType) < __MAX_TEMP_SIZE" or something
but stack overflow
from a single temporary doesn't se
--- Comment #54 from potswa at mac dot com 2009-11-03 20:43 ---
Created an attachment (id=18959)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18959&action=view)
A couple benchmarks for 32-bit mode and updated fwd+copy
Yikes. Just a second: yesterday I played around w
--- Comment #56 from potswa at mac dot com 2009-11-03 21:01 ---
Okay
I'm doing my best, anyway. I'll be holding off on other contributions
until I get a compiler capable of testing my code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41351
: 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 ---
Oh, here's a link to my version:
http://code.google.com/p/c-plus/source/browse/src/util.h#50
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
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
++
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
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
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=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.
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=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
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 ---
Oops, g::m does not need to be static constexpr to produce an error; the
specifiers should be removed to produce a minimal test.
: 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 ---
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 ---
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 #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 #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 #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 #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 #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 #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 #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 #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
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=57857
--- Comment #1 from David Krauss ---
Narrowing down the cause, the statement { 0; } silences the error but {
void(0); } does not.
: 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
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
++
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58147
David Krauss changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53251
Bug #: 53251
Summary: template keyword ignored between -> and member under
name collision with non-member
Classification: Unclassified
Product: gcc
Version: 4.7.0
Sta
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53618
Bug #: 53618
Summary: segfault on self-referential class partial
specialization argument
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53618
David Krauss changed:
What|Removed |Added
Severity|normal |minor
--- Comment #1 from David Krauss 20
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53660
Bug #: 53660
Summary: function pointer conversion function template with
nested-name-specifier ignored
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53815
Bug #: 53815
Summary: Explicit specialization of member enumeration of a
class template
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51437
--- Comment #11 from David Krauss 2012-02-19 11:09:28
UTC ---
(In reply to comment #10)
> (In reply to comment #9)
> > However, note that the standards also reserve various other classes of
> > names,
> > such as types ending in _t, for which GC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52809
Bug #: 52809
Summary: Template non-dependent static_assert diagnostics may
confuse
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
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
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=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.
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=51437
David Krauss changed:
What|Removed |Added
CC||potswa at mac dot com
--- Comment #4 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52040
Bug #: 52040
Summary: TR1 is not accessible using compiler flags alone
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
P
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55986
--- Comment #1 from David Krauss 2013-01-15 04:47:53
UTC ---
Passing `-O2` additionally causes it to skip a condition like `(i == 0 || i !=
0)`, so it looks like a general issue with expression simplification bypassing
ODR-use.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55986
--- Comment #2 from David Krauss 2013-01-15 04:48:47
UTC ---
Passing `-O2` additionally causes it to skip a condition like `(i == 0 || i !=
0)`, so it looks like a general issue with expression simplification bypassing
use.
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
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=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
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.
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
++
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
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
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=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
--- Comment #4 from potswa at mac dot com 2010-03-26 21:08 ---
The error doesn't occur if the friend is a template instance, so it really
doesn't hurt anyone. But it's weird.
template< int z >
class F {
friend class F<0>; // error only if <0&g
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: potswa at mac dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43595
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
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 #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=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
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=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() {} };
1 - 100 of 195 matches
Mail list logo
