||googlemail dot com
--- Comment #2 from Daniel Krügler
2011-11-18 19:03:14 UTC ---
(In reply to comment #1)
> template
> struct foo {
> template
> using next = typename foo::next;
> template <>
> using next<10> = int; // not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51213
Bug #: 51213
Summary: [C++11][DR 1170] Access control checking has to be
done under SFINAE conditions
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51210
--- Comment #2 from Daniel Krügler
2011-11-19 13:59:18 UTC ---
I agree, this issue seems to be a DUP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51222
Bug #: 51222
Summary: [C++11][SFINAE] Unevaluated combined delete new
expression completely broken
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51222
--- Comment #2 from Daniel Krügler
2011-11-21 07:51:49 UTC ---
When fixing this problem, I suggest to add the following tests as well, which
also fail currently (In previous builds sometimes one of these forms worked
when the other failed):
//--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51295
Bug #: 51295
Summary: [C++11][noexcept] Wrong c'tor exception-specification
with non-trivial d'tor
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51305
Bug #: 51305
Summary: [C++11][constexpr] noexcept-specifier overconstraints
constexpr functions
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCON
||googlemail dot com
--- Comment #1 from Daniel Krügler
2011-11-26 16:02:58 UTC ---
(In reply to comment #0)
> I was going to report the case where it doesn't as a bug, but after a look at
> the standard, it looks like it should always require the parenthese
||googlemail dot com
--- Comment #1 from Daniel Krügler
2011-11-28 20:49:52 UTC ---
(In reply to comment #0)
> #include
> template
> struct A {
> template std::enable_if::value>::type>
> A(A const&){}
> };
> cons
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51336
--- Comment #3 from Daniel Krügler
2011-11-29 07:08:45 UTC ---
(In reply to comment #1)
> When you instantiate A, the declaration of the template constructor
> is
> also instantiated, but at that point A is an incomplete type.
I just recognize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51336
--- Comment #7 from Daniel Krügler
2011-11-29 10:50:37 UTC ---
(In reply to comment #5)
> All right, now the is_abstract behavior is settled, do you think the fixed
> code
> provided by Daniel in comment #1 should produce a warning, since the
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51336
--- Comment #9 from Daniel Krügler
2011-11-29 11:36:34 UTC ---
(In reply to comment #8)
> Looks interesting, although since we're talking about a future standard (at
> least I assume that's what you are talking about? Or are temploids coming up
||googlemail dot com
--- Comment #1 from Daniel Krügler
2011-12-03 19:17:09 UTC ---
(In reply to comment #0)
> gcc version 4.7.0 2012 (experimental) (GCC)
Also in 4.7.0 2026 (experimental)
> Two seemingly relate ICEs when dealing with pointer to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51373
--- Comment #2 from Daniel Krügler
2011-12-03 19:33:55 UTC ---
(In reply to comment #1)
> Even with the constexpr specifier that declaration should be ill-formed,
> because the class definition must be complete for an in-class static data
> memb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51452
--- Comment #7 from Daniel Krügler
2011-12-09 15:57:15 UTC ---
Please note that this issue here is a simply a dup of bug 51295, which is a
compiler defect and *not* a library problem. See [class.dtor] p3:
"A declaration of a destructor that does
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51526
Bug #: 51526
Summary: [C++11][constexpr] constexpr delegating constructor
should be accepted
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIR
||googlemail dot com
--- Comment #1 from Daniel Krügler
2011-12-17 23:49:07 UTC ---
This looks like an invalid issue to me. According to [class.static.data] p3:
"[..] A static data member of literal type can be declared in the
class definition with the cons
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51609
Bug #: 51609
Summary: [C++11] unique_ptr::reset rejects
cv-compatible argument pointers
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51609
--- Comment #3 from Daniel Krügler
2011-12-19 07:07:52 UTC ---
(In reply to comment #2)
> While I agree the code is reasonable, I think an LWG issue is needed, because
> I
> don't think GCC's behaviour is in conflict with the standard.
I agree,
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-01-15 12:46:47 UTC ---
(In reply to comment #0)
> If a move constructor is defined, then the copy assignment operator is
> deleted,
> even if a copy constructor is defined.
>
> In the n30
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29859
--- Comment #3 from Daniel Krügler
2012-01-19 19:01:20 UTC ---
A new core issue has been opened for this problem:
http://www.open-std.org/jtc1/sc22/wg21/prot/14882fdis/cwg_active.html#1401
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51973
--- Comment #3 from Daniel Krügler
2012-01-24 08:57:09 UTC ---
Another observation: Whether or whether not the problem occurs depends on the
order of the two template declarations. Inverting the current order makes the
program valid.
My gut feel
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51199
--- Comment #1 from Daniel Krügler
2012-01-26 19:32:03 UTC ---
Related to this bug:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1417
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-01-29 13:59:50 UTC ---
Yes, C++11 has relaxed the constraints and supports variables of internal
linkage as well. E.g. a variable declared with the static keyword in namespace
scope is feasible now. But your
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52036
--- Comment #4 from Daniel Krügler
2012-01-29 17:28:14 UTC ---
(In reply to comment #3)
> However compilation still fails if pi is given internal linkage by declaring
> it > static, i.e.
>
> int main()
> {
> static constexpr float pi = 3.14;
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-01-30 08:56:28 UTC ---
The compiler behaves conforming: An elaborated type specifier is not allowed in
this context (see [expr.type.conv] p1 which says "A simple-type-specifier
(7.1.6.2) or typename-spec
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52036
--- Comment #7 from Daniel Krügler
2012-01-30 19:28:05 UTC ---
(In reply to comment #4)
> (In reply to comment #3)
> > However compilation still fails if pi is given internal linkage by
> > declaring it > static, i.e.
> >
> > int main()
> > {
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52018
--- Comment #2 from Daniel Krügler
2012-01-31 07:33:25 UTC ---
(In reply to comment #1)
> A simple workaround is to introduce a local typename-specifier:
>
> typedef class string c_t;
> h(c_t(42));
or use a static_cast (which has the additional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79393
--- Comment #6 from Daniel Krügler ---
(In reply to Jakub Jelinek from comment #5)
> Which DR has been filed for this and has there been any progress on it?
I understood the previous comments to refer to
http://www.open-std.org/jtc1/sc22/wg21/d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83830
--- Comment #1 from Daniel Krügler ---
Looks like an oversight on my side when I implemented
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0607r0.html for gcc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83956
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83956
--- Comment #3 from Daniel Krügler ---
(In reply to Daniel Krügler from comment #2)
> My understanding is that this is actually CWG 1353, discussed during the
> Bloomington 2011(!) meeting and still unresolved. This is item 17 in this
> document
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83981
--- Comment #11 from Daniel Krügler ---
(In reply to Jonathan Wakely from comment #10)
> Perhaps Daniel can comment, since he wrote the resolution of lwg 2033.
>
> Daniel, if the intent was that vector::resize(size_type) must only move,
> even i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58074
--- Comment #10 from Daniel Krügler ---
(In reply to Jonathan Wakely from comment #9)
> (In reply to Daniel Krügler from comment #0)
> > The deleted default constructor should not prevent type Trivial of being
> > trivial (Maybe this part of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61754
--- Comment #4 from Daniel Krügler ---
(In reply to Martin Sebor from comment #3)
> I find the [[deprecated]] behavior for the test cases here reasonable and
> useful: the struct type is declared deprecated and so its subsequent uses
> are diagno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61754
--- Comment #6 from Daniel Krügler ---
(In reply to Martin Sebor from comment #5)
> Would the solution described in bug 79078 comment 14 do what you're looking
> for?
Yes, that sounds plausible. But I'm just wondering: Don't you consider the
cur
||googlemail dot com
--- Comment #2 from Daniel Krügler
2012-11-14 09:45:56 UTC ---
On gcc 4.8 HEAD on my mingw-64-bit-system the program behaves normally and just
outputs "catched"
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-11-14 14:43:03 UTC ---
Reducing:
//--
struct foo {
foo(int a, float b);
};
struct bar : foo {
template
bar(Args&&... args) : foo(2, args){}
};
b
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
--- Comment #3 from Daniel Krügler
2012-11-19 07:26:11 UTC ---
(In reply to comment #2)
> What does 'rejects-valid' keywords mean?
It means that the compiler rejects valid code, see
http://gcc.gnu.org/bugzilla/describekeywords.cgi
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-11-19 19:16:43 UTC ---
I can see the exact same behaviour in gcc 4.8.0 20121104 (experimental).
I agree that the current behaviour looks like a defect defect and my tentative
guess is that this might be due
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-11-21 22:08:55 UTC ---
This seems to be fixed in 4.8.0 HEAD
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-11-23 22:21:30 UTC ---
I observe the same thing with gcc 4.8.0 20121104 (experimental) on my
mingw-x86_64 system. Odd.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55663
Bug #: 55663
Summary: [C++11] Alias template combined with constexpr
function is considered non-const
Classification: Unclassified
Product: gcc
Version: 4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55680
--- Comment #1 from Daniel Krügler
2012-12-15 16:44:08 UTC ---
The same problem exists for gcc 4.8.0 20121209 (experimental). The code looks
valid to me. I tried to deduce the root of the compiler problem here. For
example trying to rewrite it a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55710
Bug #: 55710
Summary: [C++11] Linkage errors with lambdas
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Pri
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55710
--- Comment #3 from Daniel Krügler
2012-12-15 18:57:37 UTC ---
(In reply to comment #2)
Note that my first example is not related to NSDMIs, it occurs in a static data
member initializer.
The actual reason for understanding the possible reasons
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55710
--- Comment #6 from Daniel Krügler
2012-12-15 19:55:56 UTC ---
(In reply to comment #5)
So will the following do that:
//
template
struct X {
static void (*code) ();
};
template
void (*X::code) () = []{}; // Line 7
int ma
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55710
--- Comment #7 from Daniel Krügler
2012-12-17 13:54:20 UTC ---
(In reply to comment #3)
I have now much confidence that our production code (based on GCC 4.7.2) fails
due to bug 55015. Fortunately there is a known workaround for that one.
To ma
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55720
Bug #: 55720
Summary: [C++11] Linkage errors of static data member
initializers with lambdas
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55720
Daniel Krügler changed:
What|Removed |Added
Keywords||link-failure
Known to fail|
||googlemail dot com
--- Comment #6 from Daniel Krügler
2012-12-19 11:56:32 UTC ---
(In reply to comment #0)
I suggest to also read the proposal
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3396.htm
It points out some general problems with allocation of
||googlemail dot com
--- Comment #3 from Daniel Krügler
2012-12-20 23:47:16 UTC ---
Looks like a dup of bug 55663 to me
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-12-22 17:30:37 UTC ---
Using gcc 4.8.0 20121209 (experimental) (also mingw, but 64-bit on Windows 7)
returns "false" for me.
||googlemail dot com
--- Comment #2 from Daniel Krügler
2013-01-07 22:54:45 UTC ---
The same problem seems to exist for gcc 4.8.0 20121209 and for the signatures
void insert(iterator __position, initializer_list __l)
(should be:
iterator insert(iterator __position
||googlemail dot com
--- Comment #1 from Daniel Krügler
2013-01-07 23:09:07 UTC ---
The problem also exists for gcc 4.8.0 20121209 (experimental), I agree that the
code should be accepted.
||googlemail dot com
--- Comment #1 from Daniel Krügler
2013-01-07 23:25:12 UTC ---
The problem also occurs for gcc 4.8.0 20121209 (experimental). Let me remark
that according to C++11 the variable s_Memmap could not be used in constant
expressions, because it contains
||googlemail dot com
--- Comment #4 from Daniel Krügler
2013-01-07 23:27:57 UTC ---
The same problem also occurs in gcc 4.8.0 20121209 (experimental)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55879
--- Comment #3 from Daniel Krügler
2013-01-08 20:26:33 UTC ---
(In reply to comment #2)
> If I understand you right, then you mean that the s_Memmap is not an
> "constexpr" array. As far as I understand this is not an issue that schould
> preven
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55914
Bug #: 55914
Summary: [C++11] Pack expansion for class member expression
fails in lambda expressions
Classification: Unclassified
Product: gcc
Version: 4.7.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55914
--- Comment #2 from Daniel Krügler
2013-01-09 10:39:29 UTC ---
(In reply to comment #1)
> I suspect this is just a different manifestation of PR41933.
Thanks Paolo, I partially agree. Indeed the problem is not depending on class
member expressi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55914
--- Comment #5 from Daniel Krügler
2013-01-09 11:37:49 UTC ---
(In reply to comment #4)
You are right, I missed the CD2 tag
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55924
Bug #: 55924
Summary: [C++11] Not all copy-assignment operator forms are
correctly detected
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55924
--- Comment #1 from Daniel Krügler
2013-01-09 18:32:26 UTC ---
Remark: The noexcept specifier was added unintentionally and is not relevant to
reproduce the described problem.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55924
--- Comment #4 from Daniel Krügler
2013-01-09 18:43:52 UTC ---
Oops I failed to read the error description correctly. The compiler is correct,
so please declare this as INVALID. Sorry for the noise.
||googlemail dot com
--- Comment #2 from Daniel Krügler
2013-01-11 13:22:13 UTC ---
When using gcc 4.8.0 20130106 (experimental)
with flags
-Wall -std=c++11 -pedantic
I get an internal compiler error for the line:
static constexpr Test x(42);
"12|internal com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55931
--- Comment #3 from Daniel Krügler
2013-01-11 13:26:46 UTC ---
(In reply to comment #1)
> Most likely because Test is not complete at the time of parsing.
But this should be considered as a compiler defect, right?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55944
Bug #: 55944
Summary: [C++11] static local member with constexpr c'tor
causes ICE
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55931
--- Comment #5 from Daniel Krügler
2013-01-11 18:32:13 UTC ---
The ICE bug of 4.8.0 has been submitted as bug 55944
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55977
Bug #: 55977
Summary: [C++11] vector range construction imposes unnecessary
conversion constraints
Classification: Unclassified
Product: gcc
Version: 4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55979
Bug #: 55979
Summary: [C++11] std::list range construction imposes
unnecessary conversion constraints
Classification: Unclassified
Product: gcc
Version: 4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55977
--- Comment #1 from Daniel Krügler
2013-01-14 22:18:08 UTC ---
I just notice that the implementation of construct should be changed to
template
void construct(U* p, Args&&... args)
{
::new (static_cast(p)) U(std::forward(args)...);
||googlemail dot com
--- Comment #1 from Daniel Krügler
2013-01-15 22:01:16 UTC ---
Reduced example (free of library stuff):
template
struct A {};
template
struct test
{
static constexpr unsigned pole(unsigned P)
{ return P>MaxP? MaxP:P; }
template
us
||googlemail dot com
--- Comment #7 from Daniel Krügler
2013-01-16 09:03:56 UTC ---
I stumbled across a similar problem recently within a member function of a
class template:
//
template
struct A {
static bool test() {
static bool
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043
--- Comment #25 from Daniel Krügler
2013-01-16 09:43:07 UTC ---
(In reply to comment #24)
> That really feels like a hack.
It is also broken, I think. The P/R has the effect that is_copy_constructible
is now out-of-sync with is_constructible, so
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56009
Bug #: 56009
Summary: Nested global destruction semantics not working
(mingw)
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56011
Bug #: 56011
Summary: [C++11] std::atomic and std::atomic_bool miss
volatile assignment operator overload
Classification: Unclassified
Product: gcc
Version: 4.8.0
||googlemail dot com
--- Comment #1 from Daniel Krügler
2013-01-17 15:06:50 UTC ---
I agree. Today I needed to duplicate std::lock_guard because of this problem
||googlemail dot com
--- Comment #1 from Daniel Krügler
2013-01-19 12:07:54 UTC ---
This code surely is not valid. Lambda expressions are restricted and they are
neither allowed in constant expressions (5.19 p2 b8) nor can they appear in an
unevaluated operand (5.1.2 p2).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56039
--- Comment #3 from Daniel Krügler
2013-01-19 17:20:21 UTC ---
(In reply to comment #2)
You make a good point, but my remaining argument would focus on the fact that
the expression
false && [](){}
is always invalid because it attempts to combi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56039
--- Comment #5 from Daniel Krügler
2013-01-19 20:20:43 UTC ---
(In reply to comment #4)
> (In reply to comment #3)
> I seem to find that the expression in question
> >
> > false && [](){}
> >
> is valid because there is a implicit conversion s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56039
--- Comment #6 from Daniel Krügler
2013-01-20 12:27:20 UTC ---
(In reply to comment #0)
> The code uses C++11 lambda expressions in a constant expression context for
> the SFINAE. As far as I can tell, SFINAE should apply since the lambda occurs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55223
--- Comment #3 from Daniel Krügler
2013-01-20 19:56:22 UTC ---
(In reply to comment #2)
> The underlying compiler supports additional __ATOMIC_HLE_ACQUIRE/RELEASE
> memmodel flags for TSX, but this was not exposed to the C++ wrapper.
> Handle it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56009
Daniel Krügler changed:
What|Removed |Added
CC||ktietz at gcc dot gnu.org
--- Comment #
||googlemail dot com
--- Comment #2 from Daniel Krügler
2013-01-24 11:56:31 UTC ---
While I agree that the ICE needs to be fixed, let me add in here that any
conversion that requires the equivalent of a reinterpret_cast is not valid in a
constant expression in C++11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56095
--- Comment #4 from Daniel Krügler
2013-01-24 12:07:25 UTC ---
(In reply to comment #3)
> I cant reproduce the crash with any version
Here is what I get with my mingw-64 gcc 4.8.0 20130120 (experimental):
"main.cpp||In function 'int main(int,
||googlemail dot com
--- Comment #1 from Daniel Krügler
2013-01-25 13:03:27 UTC ---
I can see the same warning for gcc 4.8.0 20130120 (experimental). It's
essential to have -02 set (maybe even higher). I agree that the diagnostics
seems incorrect and the code see
||googlemail dot com
--- Comment #1 from Daniel Krügler
2013-01-30 20:24:06 UTC ---
GCC 4.8.0 trunk behaves similar. I think the situation is currently not clear
by the language. It looks like a manifestation of
http://www.open-std.org/jtc1/sc22/wg21/docs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69700
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69717
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69717
--- Comment #2 from Daniel Krügler ---
This is fixed in the current trunk (Tested on gcc HEAD 6.0.0 20160207
(experimental)). Btw.: Your test case is confusing. A better test case would be
the following one, where the static assertion tests the e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69898
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69924
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70254
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71545
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81468
--- Comment #1 from Daniel Krügler ---
It seems that the implementation simply forgot to constrain overload
resolution, since this is the complete definition of the affected constructor:
template
constexpr time_point(const time_point& __t)
:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81468
--- Comment #2 from Daniel Krügler ---
Shouldn't add a DR-1177 tag? (I forgot the exact construction pattern for this)
This may also help to validate that all other wording changes by this issue had
been implemented.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79162
--- Comment #16 from Daniel Krügler ---
(In reply to Jonathan Wakely from comment #15)
> Thanks, Daniel. Let's reopen this to make the T -> const T& changes.
I'm now working at that problem, thereby also attempting to implement the full
P/R of L
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81632
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
++
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.kruegler at googlemail dot com
Target Milestone: ---
Since the recent update of "Feature-testing recommendations for C++",
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0096r4.html#recs.cpp11
t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81950
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
501 - 600 of 884 matches
Mail list logo
