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
: 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
: 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 #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 meanwhile have
diagnostics
Product: gcc
Version: 4.3.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
--- 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.org/bugzilla
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 #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=17468action=view)
show inconsistency for is_abstract
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39475
--- 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 #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
--- 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_reference
--- 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=17463action=view)
show inconsistency with is_abstract
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39405
--- 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 through the change which went
--- 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.3.1 to try.
I've copied to header
--- 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 maybe not worth the effort to fix
--- 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_reference is really
--- 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 understand why it works even
++
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
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
ReportedBy: d dot frey
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
ReportedBy: d dot frey
--- 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
--- 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 #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 #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 |Added
: __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 org
ReportedBy: d dot frey at gmx dot
--- 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 int,double
--- 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
27 matches
Mail list logo
