||googlemail dot com
--- Comment #3 from Daniel Krügler
2012-08-16 19:41:00 UTC ---
(In reply to comment #1)
> Open the header with your favorite editor and you will see why (spoiler:
> setjmp
> is defined as a macro in C)
You are right, but I initially tho
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54289
--- Comment #5 from Daniel Krügler
2012-08-16 19:46:16 UTC ---
(In reply to comment #4)
> Sorry, but I think standard declares that all function should be in std.
No. 17.6.1.2 [headers] only says so for non-macros:
"In the C++ standard library,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54289
--- Comment #8 from Daniel Krügler
2012-08-16 19:54:10 UTC ---
(In reply to comment #6)
> I think standard of C std libs declares setjmp as a function. So, it should be
> function.
I'm not looking at any code, but C says:
"The header defines t
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-08-19 07:30:30 UTC ---
Just for the record: This problem does no longer exist in gcc 4.8 (tested for
4.8.0 20120729 (experimental))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54319
--- Comment #3 from Daniel Krügler
2012-08-19 12:13:32 UTC ---
(In reply to comment #2)
> Daniel can you double check?
Good that you ask. There must by some problem with my gcc installation, because
I get different results from different contex
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54276
--- Comment #3 from Daniel Krügler
2012-08-19 12:14:53 UTC ---
(In reply to comment #2)
> Daniel can you please double check this one too? Today I'm definitely seeing
> the undefined reference.
It seems that I need to fix my gcc installation as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54293
--- Comment #7 from Daniel Krügler
2012-08-20 22:17:45 UTC ---
(In reply to comment #6)
> — If E2 is a non-static data member and the type of E1 is “cq1 vq1 X”, and the
> type of E2 is “cq2 vq2
> T”, the expression designates the named member of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54293
--- Comment #9 from Daniel Krügler
2012-08-21 06:13:50 UTC ---
(In reply to comment #8)
> > I agree with your analysis, but would like to point out that there is change
> > planned to essentially this part of the wording due to
> >
> > http://w
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54293
--- Comment #11 from Daniel Krügler
2012-08-21 08:07:28 UTC ---
(In reply to comment #10)
> > In other words: In this case IsValid(&ref_int) will hold for the same
> > reasons
> > as it holds for IsValid(&ref_obj).
>
> That is true, and I didn'
||googlemail dot com
--- Comment #6 from Daniel Krügler
2012-08-25 20:31:42 UTC ---
(In reply to comment #5)
> Comeau rejects it for me, the problem happens at compile time.
Just for the record: Visual Studio 2012 Beta also rejects the code for similar
reason.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54388
--- Comment #3 from Daniel Krügler
2012-08-28 13:43:42 UTC ---
(In reply to comment #2)
> The fix is to remove the constexpr from array::at, which isn't required by the
> standard anyway:
It's not required, but I would like to encourage you to k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54388
--- Comment #4 from Daniel Krügler
2012-08-28 13:53:18 UTC ---
(In reply to comment #3)
> (In reply to comment #2)
> > The fix is to remove the constexpr from array::at, which isn't required by
> > the
> > standard anyway:
>
> It's not required
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54388
--- Comment #6 from Daniel Krügler
2012-08-28 14:07:11 UTC ---
(In reply to comment #5)
> The paper does have implementation experience, and experience shows we got it
> wrong ;)
We implemented it wrong is a different message than "we couldn't i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54388
--- Comment #8 from Daniel Krügler
2012-08-28 20:34:34 UTC ---
(In reply to comment #4)
> > Replace
> >
> > return __n < _Nm ?
> >_M_instance[__n] : throw out_of_range(__N("array::at"));
> >
> > by
> >
> > return __n < _Nm
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-08-30 21:51:07 UTC ---
I can see the same problem with gcc 4.8.0 20120819 (experimental) (Let me add
that the test example should remove the invalid semicolons after each function
definition).
This should be
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-08-31 20:13:42 UTC ---
For gcc 4.8.0 20120819 (experimental) I'm getting an ICE instead:
"20|internal compiler error: canonical types differ for identical types
void(index_t)__attribute__((const))
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-09-04 15:30:53 UTC ---
(In reply to comment #0)
> The is_unsigned<> type trait is not detecting the underlying signedness of a
> C++11 enum class or enum.
This is what the standard requires. The d
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54483
--- Comment #3 from Daniel Krügler
2012-09-05 11:12:13 UTC ---
(In reply to comment #1)
> This is invalid as per [class.static.data]/3 :
On C++11 level it should be valid, because odr-usage does not happen here
according to [basic.def.odr] p3:
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-09-06 15:42:07 UTC ---
I can confirm the problem for gcc 4.8 trunk for os=win32 arch=64bit systems
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-09-07 05:37:56 UTC ---
The language requires that the presence of a user-declared copy-constructor
(which you have used in your code) shall prevent the compiler-declared move
constructor. When _BUG_ is defined
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-09-07 05:40:24 UTC ---
This bug report looks invalid to me for the same reason as bug 54510
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-09-07 05:52:51 UTC ---
I can confirm the problem for gcc 4.8.0 20120819 (experimental). I reduced the
example to get rid of some "magic" values, which are not relevant to be
present. One important r
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54557
--- Comment #1 from Daniel Krügler
2012-09-12 20:54:26 UTC ---
The compiler behaviour looks correct to me. The difference of the lambda
expressions in bar and foo3 compared to the other two is that these are
capture-free lambdas and thus have a c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54738
Bug #: 54738
Summary: [C++11][SFINAE] Hard errors for pointer-to-member
function expressions
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status
||googlemail dot com
--- Comment #2 from Daniel Krügler
2012-09-29 23:07:59 UTC ---
(In reply to comment #1)
> I haven't bothered analysing the code, but Comeau and Clang agree it's
> ambiguous, so GCC is probably right.
I agree with Jonathan, the cod
||googlemail dot com
--- Comment #3 from Paolo Carlini 2012-09-30
09:44:27 UTC ---
Hi,
> There is an implementation of hypot, so I'm wondering if we can't do
> better.
You mean in the libc? It's possible because as you can see the autoconf tes
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-10-01 11:54:47 UTC ---
Simplified to get rid of library dependencies:
//---
template
struct c
{
int (*f)(int) = [](int i){return i + i;};
};
//---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54769
--- Comment #1 from Daniel Krügler
2012-10-02 06:04:56 UTC ---
In C++03 this was supposed to be ill-formed, but - as Mike Miller explained to
me - with the acceptance of CWG (no kidding ;-))
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54777
Bug #: 54777
Summary: [C++11] Comma operator in constexpr environment can
cause ICE
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49171
--- Comment #4 from Daniel Krügler
2012-10-03 16:22:24 UTC ---
(In reply to comment #3)
> Daniel, what's the status of this issue? Is there some consensus that GCC is
> actually Ok, we don't really want to reject reinterpret_casts?
My opinion i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49171
--- Comment #6 from Daniel Krügler
2012-10-03 18:46:09 UTC ---
(In reply to comment #5)
> Ok, thanks. Sorry about the naive question: is it already clear what it means
> for reinterpret_cast uses to be "well-defined" in this sense?
This is sure
||googlemail dot com
--- Comment #3 from Daniel Krügler
2012-10-03 21:20:01 UTC ---
This happens also with gcc 4.8 HEAD. Further simplifications and removal of
library dependencies:
//---
void use(int){}
template
class C
{
public:
void f
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-10-04 07:11:14 UTC ---
Also occurs on gcc 4.8.0 20120930 (experimental).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54812
Bug #: 54812
Summary: [C++11] Delete expression doesn't respect access of
defaulted destructor
Classification: Unclassified
Product: gcc
Version: 4.8.0
Stat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49171
--- Comment #8 from Daniel Krügler
2012-10-05 14:17:18 UTC ---
(In reply to comment #7)
> Thus I understand that currently GCC is accepting *all sorts* of
> reinterpret_cast uses in constexpr functions, right? That is, also those with
> unspeci
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54812
--- Comment #2 from Daniel Krügler
2012-10-05 21:00:31 UTC ---
(In reply to comment #1)
> Anyway, here, I only wanted to ask you if this is a show-stopper for your
> work,
> because I don't know how much time it will take.
While I think that t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51199
--- Comment #2 from Daniel Krügler
2012-10-06 07:58:56 UTC ---
(In reply to comment #1)
CWG 1417 is now in ready state, which is a good opportunity to implement the
clarification. Meanwhile some traits (like is_copy/move_constructible) should
be
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-10-06 08:05:43 UTC ---
Also occurs on gcc 4.8.0 20120930 (experimental), pointing here to
"main.cpp|12|internal compiler error: in based_loc_descr, at dwarf2out.c:10193"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54812
--- Comment #6 from Daniel Krügler
2012-10-06 08:11:48 UTC ---
(In reply to comment #5)
I double-checked whether this might be related to
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1507
from a different perspective, but I'm pr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54835
Bug #: 54835
Summary: [C++11] Explicit default constructors not respected
during copy-list-initialization
Classification: Unclassified
Product: gcc
Version: 4.8.0
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-10-07 18:02:17 UTC ---
The example works in 4.8 HEAD.
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-10-09 14:23:36 UTC ---
I can reproduce this error with gcc 4.8.0 20120930 (experimental), were I get:
"main.cpp|7|internal compiler error: tree check: expected enumeral_type, have
template_type_pa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53000
--- Comment #13 from Daniel Krügler
2012-10-10 10:42:20 UTC ---
(In reply to comment #11)
> Thus, the library bits are done in mainline, right Daniel?
In regard to std::common_type, yes. But while making std::common_type
sfinae-friendly I searc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53000
--- Comment #16 from Daniel Krügler
2012-10-10 10:55:02 UTC ---
(In reply to comment #12)
> So we now have:
>
> common_type::type -> const int&
> common_type::type -> int
>
> ?
>
> If we are going with this resolution, I think the 1 argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53000
--- Comment #18 from Daniel Krügler
2012-10-10 11:04:23 UTC ---
(In reply to comment #17)
> The patch is already in, of course. In hindsight, I think we shouldn't have
> bundled the SFINAE bits with addressing LWG 2141, which, I realize now, is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53000
--- Comment #20 from Daniel Krügler
2012-10-10 11:08:09 UTC ---
(In reply to comment #19)
It is more than that, because *my* own test-cases rely on the decay assumption.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54922
Bug #: 54922
Summary: [C++11][DR 1359] constexpr constructors require
initialization of all union members
Classification: Unclassified
Product: gcc
Version: 4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54922
--- Comment #1 from Daniel Krügler
2012-10-13 20:54:14 UTC ---
(In reply to comment #0)
Some copy'n-paste error occurred while attempting to format the code example.
The correct code under investigation was:
//
class nullable_in
||googlemail dot com
--- Comment #2 from Daniel Krügler
2012-10-17 19:36:14 UTC ---
The ICE still occurs in gcc 4.8.0 20121014 (experimental) with the message:
"internal compiler error: in convert_nontype_argument, at cp/pt.c:5533"
Let me add that your exam
||googlemail dot com
--- Comment #3 from Daniel Krügler
2012-10-17 19:55:34 UTC ---
I agree that this should be accepted (The grammar of a /simple-declaration/ in
Clause 7 says so).
||googlemail dot com
--- Comment #2 from Daniel Krügler
2012-10-20 20:24:19 UTC ---
Your issue looks invalid to me, because you are never providing a pointer to
function declarator.
Lets look first at your simplified example:
auto (*ff) -> int (int)
This would be
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-10-21 13:36:28 UTC ---
The code presented code example seems incomplete, because it is accepted as
written. Here a complete code-example compiled with gcc 4.8.0 20121014
(experimental) using the compiler flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55017
Bug #: 55017
Summary: [C++11] Rvalue-reference member should cause copy
constructor not deleted, but still declared
Classification: Unclassified
Product: gcc
Version: 4.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55039
--- Comment #1 from Daniel Krügler
2012-10-23 18:15:38 UTC ---
I agree, an intrinsic is needed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55039
--- Comment #3 from Daniel Krügler
2012-10-23 20:56:36 UTC ---
(In reply to comment #2)
During the Portland meeting the issue
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1384
was discussed and core had consensus *not* to suppor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043
--- Comment #10 from Daniel Krügler
2012-10-24 06:37:05 UTC ---
(In reply to comment #9)
> (In reply to comment #8)
> > is this a bug in is_constructible?
>
> I don't think so. The implementation of the copy constructor is irrelevant,
> only th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043
--- Comment #12 from Daniel Krügler
2012-10-24 08:33:47 UTC ---
(In reply to comment #11)
> That seems inconsistent with 20.9.4.3/6
>
> the predicate condition for a template specialization is_constructible Args...> shall be satisfied if and on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043
--- Comment #14 from Daniel Krügler
2012-10-24 09:23:22 UTC ---
(In reply to comment #13)
> So to make the testcase compile (which it should) I'd need to use sfinae to
> disable the container members, which means writing constraints based on
> C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043
--- Comment #17 from Daniel Krügler
2012-10-24 17:48:07 UTC ---
(In reply to comment #15)
> > 1) It will prevent the incomplete type support
>
> Ouch... but not required by the standard.
I agree, but I consider that as a high price.
> > 2) Th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043
--- Comment #18 from Daniel Krügler
2012-10-24 18:12:25 UTC ---
(In reply to comment #17)
> Looking at the concrete problem here I think the only thing that is needed
> is a conditional noexcept for all containers move constructors (which is
>
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-10-26 17:24:35 UTC ---
This is no compiler defect: The A constructor is explicit and won't be
considered within a copy-initialization context. You need a
direct-initialization context like the one that
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55120
--- Comment #3 from Daniel Krügler
2012-10-29 19:20:26 UTC ---
(In reply to comment #2)
> This is http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#7 which
> was
> closed as NAD saying "This is what was intended" but I'm not sure what
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55120
--- Comment #6 from Daniel Krügler
2012-10-30 07:28:47 UTC ---
(In reply to comment #4)
> I think the standard is unclear on this. That defect report has been queried
> by
> experts.
Let me clarify that I have not even tried to interpret the st
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55120
--- Comment #7 from Daniel Krügler
2012-10-30 19:48:21 UTC ---
(In reply to comment #5)
> Curious that G++, Comeau and Clang all accept the example in CWG issue 7,
> despite the rationale (and Mike) indicating it's intended that a virtual
> priv
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-10-31 21:56:58 UTC ---
I think your example codes involves at least two different issues here. In the
following my data was realized by using gcc 4.8.0 20121014 (experimental) with
the flags
-Wall -std=c++11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25466
--- Comment #8 from Daniel Krügler
2012-11-01 07:11:56 UTC ---
(In reply to comment #7)
The error is real. The original example belongs to 5.2.8 p2:
"When typeid is applied to a **glvalue expression** whose type is a polymorphic
class type [..]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25466
--- Comment #10 from Daniel Krügler
2012-11-01 09:10:56 UTC ---
(In reply to comment #9)
I don't think that the standard says (or intends to say) that an implementation
has to defer all evaluations here. For example, assume you provide
polymorp
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-11-01 10:58:06 UTC ---
I really think that Pythy should fix this implementation, because it is not
supported by the C++11 standard. Any compiler accepting that is defect.
According to 9.4.2 p3:
"A static
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55159
--- Comment #3 from Daniel Krügler
2012-11-01 15:11:51 UTC ---
(In reply to comment #2)
Hmmh, it doesn't look like that one, maybe I was wrong about an existing issue.
But it seems that gcc doesn't ignore the const (in "const T*" or "const auto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55159
--- Comment #4 from Daniel Krügler
2012-11-02 08:10:14 UTC ---
(In reply to comment #3)
> But it seems that gcc doesn't ignore the const (in "const T*" or "const
> auto*")
> for functions here, which seems to be the root of the second problem (
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55159
--- Comment #5 from Daniel Krügler
2012-11-02 08:57:33 UTC ---
I need to insert another correction. My attempt to simplify the reporters bug
failed because I was mislead by the report description that "visual studio 2012
work fine" interpreting
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55159
--- Comment #7 from Daniel Krügler
2012-11-02 11:39:07 UTC ---
(In reply to comment #6)
> Thus, Daniel, is this invalid?
I think this part of the problem is indeed valid:
template
struct min_t
{
static bool less(T0 x, T1 y) { return x < y
||googlemail dot com
--- Comment #11 from Daniel Krügler
2012-11-06 19:23:51 UTC ---
The associated core issue
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1495
has now ready state, so I think this issue could now be unsuspended
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55226
Bug #: 55226
Summary: [C++11] ICE regression in regard to anonymous unions
and constexpr
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52965
--- Comment #4 from Daniel Krügler
2012-11-07 18:45:09 UTC ---
(In reply to comment #2)
I agree with Jonathan and James this issue can be closed.
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-11-07 22:25:29 UTC ---
I would expect that the designated initializer would be .a="" and not
a:"" (as specified by C99), but I agree that even with that change the
revised code
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-11-08 21:33:48 UTC ---
The ICE also exists for gcc 4.8.0 20121104 (experimental):
"4|internal compiler error: in expand_expr_real_1, at expr.c:9280|"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55244
--- Comment #4 from Daniel Krügler
2012-11-08 23:52:52 UTC ---
(In reply to comment #2)
Agreed, looks like an invalid issue to me.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56976
--- Comment #3 from Daniel Krügler ---
(In reply to Akim Demaille from comment #2)
You are right, I misread your code example in the haste. I agree that this is
not related to CWG 1604 (we have no mixed case) and I think it is clear that
both init
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57314
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57335
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.kruegler at googlemail dot com
While attempting to upgrade std::function for functions with ref-qualifiers I
found that the following code gives an ICE for gcc 4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57384
--- Comment #2 from Daniel Krügler ---
I have the impression that this *could* be related to
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1488
This is unchecked yet, because I'm leaving my place here.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57388
--- Comment #2 from Daniel Krügler ---
(In reply to Daniel Krügler from comment #0)
> While attempting to upgrade std::function for functions with ref-qualifiers
> [..]
Oops, I meant std::is_function of-course.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57248
--- Comment #3 from Daniel Krügler ---
The code looks valid to me. I think that Paolo just wanted to point out that
the library implementation does not cause this. I agree with him and can
confirm that the code is also rejected when emulating the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56991
--- Comment #4 from Daniel Krügler ---
(In reply to Matheus Izvekov from comment #2)
> I get also a similar bug:
>
> #include
>
> //is accepted by gcc
> constexpr std::initializer_list good1 = { 1, 2, 3 };
>
> struct foo { int a, b; };
>
> //
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57392
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57397
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57403
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
IRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.kruegler at googlemail dot com
When attempting to update the library test cases that use the test_category
template I stumbled across compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57406
Daniel Krügler changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47765
--- Comment #8 from Daniel Krügler ---
(In reply to Paolo Carlini from comment #7)
> Do we have a DR # for this issue?
It seems to me that this is
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1391
submitted by Jason with a simpli
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57388
--- Comment #3 from Daniel Krügler ---
Extending std::is_function in regard to ref-qualified functions will depend on
that issue. I haven't found a way to get around these ICEs in the (updated)
test cases.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52216
--- Comment #4 from Daniel Krügler ---
(In reply to Paolo Carlini from comment #3)
It seems that this is CWG 1465 and it will be resolved by
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1351
It seems that this bug entry is fixed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52216
--- Comment #6 from Daniel Krügler ---
(In reply to Paolo Carlini from comment #5)
It would be great to have these test cases added.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57408
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57408
--- Comment #3 from Daniel Krügler ---
Further simplification down to a library-free test case:
//--
template
struct Impl
{
Callable func;
Impl(Callable f) : func(f) { }
virtual
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57416
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57416
--- Comment #4 from Daniel Krügler ---
If you remove the still existing member initializer in func1, does the ICE
still exist? (On 4.9 after removal of that initializer I could compile and run
the program). Are all the compiler flags necessary to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57416
--- Comment #5 from Daniel Krügler ---
(In reply to Daniel Krügler from comment #4)
We had a clash here, but except for my first observation the remaining
questions are still relevant.
101 - 200 of 884 matches
Mail list logo
