--- Comment #12 from mec at google dot com 2007-06-04 13:35 ---
Verified with my two test programs with snapshot gcc-4.3-20070601. Thanks for
the fast fix!
--
mec at google dot com changed:
What|Removed |Added
--- Comment #9 from paolo at gcc dot gnu dot org 2007-05-31 08:58 ---
Subject: Bug 32158
Author: paolo
Date: Thu May 31 08:58:47 2007
New Revision: 125217
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125217
Log:
gcc/cp
2007-05-31 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #10 from paolo at gcc dot gnu dot org 2007-05-31 11:14 ---
Subject: Bug 32158
Author: paolo
Date: Thu May 31 11:13:57 2007
New Revision: 125223
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125223
Log:
2007-05-31 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #11 from pcarlini at suse dot de 2007-05-31 11:15 ---
Fixed. Thanks again Michael for timely raising the issue.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #1 from pcarlini at suse dot de 2007-05-30 21:00 ---
Curious, this is actually a C++ front-end issue, a bug in my implementation of
__is_pod: currently it just forwards to pod_type_p, in cp/tree.c, and
apparently I was wrong to assume it exactly implements the Standard
--- Comment #2 from mark at codesourcery dot com 2007-05-30 21:08 ---
Subject: Re: uninitialized_fill compile failure if no default
assignment operator
pcarlini at suse dot de wrote:
--- Comment #1 from pcarlini at suse dot de 2007-05-30 21:00 ---
Curious, this is actually
--- Comment #3 from pcarlini at suse dot de 2007-05-30 21:25 ---
Thanks Mark. In fact, we have already a test for that, in ext/is_pod.cc. But we
have a problem with templates. This:
templatetypename T
struct A
{
A() { }
};
has __is_pod(Aint) true. Actually, the
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-05-30 21:31 ---
(In reply to comment #3)
has __is_pod(Aint) true. Actually, the problem affects also other front-end
traits, probably most of them :( :( They are not working correctly with
templates. First blush, any hint where
--- Comment #5 from mark at codesourcery dot com 2007-05-30 21:38 ---
Subject: Re: uninitialized_fill compile failure if no default
assignment operator
pcarlini at suse dot de wrote:
--- Comment #3 from pcarlini at suse dot de 2007-05-30 21:25 ---
Thanks Mark. In fact, we
--- Comment #6 from pcarlini at suse dot de 2007-05-30 21:46 ---
Many thanks to Andrew and Mark. I'm on it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32158
--- Comment #7 from mec at google dot com 2007-05-30 23:01 ---
I think the problem is independent of __is_pod. The new
std::uninitialized_fill has an if statement, not a template specialization.
Compilation always attempts to instantiate std::fill(__first_, __last_, __x),
whether that
--- Comment #8 from pcarlini at suse dot de 2007-05-30 23:21 ---
You are right, I was exactly noticing that at the same time as you. I'm fixing
that issue separately.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32158
12 matches
Mail list logo
