Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: d dot frey at gmx dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42600
Summary: [c++0x] std::bind not assignable to std::function
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: d dot frey at gmx dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42593
--- Comment #1 from d dot frey at gmx dot de 2009-12-29 15:05 ---
Note that the code is actually quite broken, the main problem which causes the
ICE is:
decltype( impl::select< From, To > )
which should read something like:
decltype( impl::select< From, To >() )
I mean
s lousy ICE
Product: gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: d dot frey at gmx dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42539
--- Comment #5 from d dot frey at gmx dot de 2009-03-17 07:30 ---
(In reply to comment #4)
> Maybe Daniel, but this is a completely separate issue.
That's why I asked if I should open yet another PR for it :) I've done that
now: PR c++/39478
--
http://gcc.gnu
ful message.
--
Summary: please improve recursive template instantiation
diagnostics
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot
--- Comment #3 from d dot frey at gmx dot de 2009-03-16 23:49 ---
One more thought on the diagnostics: There are two cases: Incomplete types
(like in the initial example in the description of this PR) and recursive
template instantiations (see attachment). I think the latter produces a
--- Comment #27 from d dot frey at gmx dot de 2009-03-16 19:08 ---
Thanks Paolo. I've opened PR c++/39475 for the type traits intrinsics.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39405
--- Comment #1 from d dot frey at gmx dot de 2009-03-16 19:05 ---
Created an attachment (id=17468)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17468&action=view)
show inconsistency for is_abstract
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39475
mal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: d dot frey at gmx dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39475
--- Comment #23 from d dot frey at gmx dot de 2009-03-14 08:53 ---
Created an attachment (id=17463)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17463&action=view)
show inconsistency with is_abstract
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39405
--- Comment #22 from d dot frey at gmx dot de 2009-03-14 08:52 ---
(In reply to comment #21)
> Now I think I know the conservative way we want to go for the branch: just
> change shared_ptr<>::operator* to always use something with the same semantics
> of std::tr1::add
--- Comment #17 from d dot frey at gmx dot de 2009-03-13 16:41 ---
(In reply to comment #16)
> Note, just tweaking is_function like this, doesn't completely fix the issue
> for
> me, only the reduced testcase using is_abstract...
And actually I don't even understan
--- Comment #12 from d dot frey at gmx dot de 2009-03-13 14:53 ---
(In reply to comment #11)
> I understand. Too bad that we can't make it to work for 4.3.x without
> regressing on libstdc++/35637 :( I'm puzzled by the fact that the tr1 version
> works, only is_
--- Comment #10 from d dot frey at gmx dot de 2009-03-13 13:14 ---
(In reply to comment #8)
> Moreover, if we ""fix"" this issue at the library level without dealing with
> the real C++ front-end issue, we regress on libstdc++/35637, of course.
OK, I see. So
--- Comment #6 from d dot frey at gmx dot de 2009-03-13 12:49 ---
(In reply to comment #5)
More information on this:
> > > The bug is in both 4.3.3 and 4.3.2, however it isn't in 4.3.0 on a
> > > sparcv9-sun-solaris2.10 box with 64bits. Haven't got any 4
--- Comment #5 from d dot frey at gmx dot de 2009-03-13 12:23 ---
(In reply to comment #4)
> > The bug is in both 4.3.3 and 4.3.2, however it isn't in 4.3.0 on a
> > sparcv9-sun-solaris2.10 box with 64bits. Haven't got any 4.3.1 to try.
>
> Ok. I went thro
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: d dot frey at gmx dot de
GCC host triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39131
--- Comment #1 from d dot frey at gmx dot de 2008-07-27 16:19 ---
*** Bug 36950 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36949
--- Comment #1 from d dot frey at gmx dot de 2008-07-27 16:19 ---
Sorry, reporting it *once* should be enough :-}
*** This bug has been marked as a duplicate of 36949 ***
--
d dot frey at gmx dot de changed:
What|Removed |Added
does not initialize
enable_shared_from_this' internal shared_count
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
does not initialize
enable_shared_from_this' internal shared_count
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
--- Comment #20 from d dot frey at gmx dot de 2008-02-28 12:42 ---
According to DR 425's proposed resolution, GCC is already doing the right
thing, so I'm closing this bug report.
--
d dot frey at gmx dot de changed:
What|Removed
--- Comment #6 from d dot frey at gmx dot de 2008-02-28 08:14 ---
I looked at bug #99, but I am unsure whether this bug is really a dup of it.
#99 is about overloads and occurs with user types, while this bug is about
partial template specializations and occurs only with certain types
--- Comment #4 from d dot frey at gmx dot de 2008-02-27 21:58 ---
More information:
I checked out the trunk and checked it again. The bug is still present, but
while testing it, I noticed that the problem does not occur with my own types,
only with types from the standard library
--- Comment #2 from d dot frey at gmx dot de 2008-02-27 12:02 ---
I understand where the names come from, but that doesn't make the message
correct. Consider the specialization in the example program to use <_T2,_T1>
(note the reversed order) and an instantiation with , th
ur with partial specialization.
--
Summary: __PRETTY_FUNCTION__ produces inconsistent output
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot
27 matches
Mail list logo
