[Bug c++/32158] uninitialized_fill compile failure if no default assignment operator
--- 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 Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32158
[Bug c++/32158] uninitialized_fill compile failure if no default assignment operator
--- 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 Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32158
[Bug c++/32158] uninitialized_fill compile failure if no default assignment operator
--- 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=gcc&view=rev&rev=125223 Log: 2007-05-31 Paolo Carlini <[EMAIL PROTECTED]> PR c++/32158 (libstdc++ bits) * include/bits/stl_uninitialized.h (__uninitialized_copy_aux, __uninitialized_fill_aux, __uninitialized_fill_n_aux): Remove. (struct __uninitialized_copy, struct __uninitialized_fill, struct __uninitialized_fill_n): Add. (uninitialized_copy, uninitialized_fill, uninitialized_fill_n): Adjust. * testsuite/20_util/specialized_algorithms/32158.cc: New. * include/bits/stl_uninitialized.h (uninitialized_copy(_InputIterator, _InputIterator, _ForwardIterator)): Robustify vs non-POD input. * include/bits/stl_vector.h (_M_fill_initialize): New. (vector(size_type, const value_type&, const allocator_type&), _M_initialize_dispatch(_Integer, _Integer, __true_type)): Use it. * testsuite/23_containers/vector/requirements/dr438/assign_neg.cc: Adjust dg-error line. * testsuite/23_containers/vector/requirements/dr438/insert_neg.cc: Likewise. * testsuite/23_containers/vector/requirements/dr438/ constructor_1_neg.cc: Likewise. * testsuite/23_containers/vector/requirements/dr438/ constructor_2_neg.cc: Likewise. Added: trunk/libstdc++-v3/testsuite/20_util/specialized_algorithms/32158.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/stl_uninitialized.h trunk/libstdc++-v3/include/bits/stl_vector.h trunk/libstdc++-v3/testsuite/23_containers/vector/requirements/dr438/assign_neg.cc trunk/libstdc++-v3/testsuite/23_containers/vector/requirements/dr438/constructor_1_neg.cc trunk/libstdc++-v3/testsuite/23_containers/vector/requirements/dr438/constructor_2_neg.cc trunk/libstdc++-v3/testsuite/23_containers/vector/requirements/dr438/insert_neg.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32158
[Bug c++/32158] uninitialized_fill compile failure if no default assignment operator
--- 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=gcc&view=rev&rev=125217 Log: gcc/cp 2007-05-31 Paolo Carlini <[EMAIL PROTECTED]> PR c++/32158 * semantics.c (finish_trait_expr): Complete the types. gcc/testsuite 2007-05-31 Paolo Carlini <[EMAIL PROTECTED]> PR c++/32158 * g++.dg/ext/is_pod_incomplete.C: New. Added: trunk/gcc/testsuite/g++.dg/ext/is_pod_incomplete.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32158
[Bug c++/32158] uninitialized_fill compile failure if no default assignment operator
--- 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
[Bug c++/32158] uninitialized_fill compile failure if no default assignment operator
--- 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 line is executed at run-time or not.
Here is an example with a class that is clearly not a POD.
===
#include
class Foo {
public:
Foo();
Foo(const Foo&);
~Foo();
private:
void* p;
void operator=(const Foo&);
};
void Alpha(Foo* start, Foo* end) {
Foo f;
std::uninitialized_fill(start, end, f);
}
[EMAIL PROTECTED]:~/exp-43-redux$ /home/mec/gcc-4.2.0/install/bin/g++ -Wall -S
u-fill-2.cc
[EMAIL PROTECTED]:~/exp-43-redux$ /home/mec/gcc-4.3-20070525/install/bin/g++
-Wall
-S u-fill-2.cc
u-fill-2.cc: In static member function 'static void std::__fill<
>::fill(_ForwardIterator, _ForwardIterator, const _Tp&) [with _ForwardIterator
= Foo*, _Tp = Foo, bool = false]':
/home/mec/gcc-4.3-20070525/install/lib/gcc/i686-pc-linux-gnu/4.3.0/../../../../include/c++/4.3.0/bits/stl_algobase.h:557:
instantiated from 'void std::__fill_aux(_ForwardIterator, _ForwardIterator,
const _Tp&) [with _ForwardIterator = Foo*, _Tp = Foo]'
/home/mec/gcc-4.3-20070525/install/lib/gcc/i686-pc-linux-gnu/4.3.0/../../../../include/c++/4.3.0/bits/stl_algobase.h:595:
instantiated from 'void std::fill(_ForwardIterator, _ForwardIterator, const
_Tp&) [with _ForwardIterator = Foo*, _Tp = Foo]'
/home/mec/gcc-4.3-20070525/install/lib/gcc/i686-pc-linux-gnu/4.3.0/../../../../include/c++/4.3.0/bits/stl_uninitialized.h:146:
instantiated from 'void std::uninitialized_fill(_ForwardIterator,
_ForwardIterator, const _Tp&) [with _ForwardIterator = Foo*, _Tp = Foo]'
u-fill-2.cc:15: instantiated from here
u-fill-2.cc:10: error: 'void Foo::operator=(const Foo&)' is private
/home/mec/gcc-4.3-20070525/install/lib/gcc/i686-pc-linux-gnu/4.3.0/../../../../include/c++/4.3.0/bits/stl_algobase.h:533:
error: within this context
[EMAIL PROTECTED]:~/exp-43-redux$
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32158
[Bug c++/32158] uninitialized_fill compile failure if no default assignment operator
--- 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
[Bug c++/32158] uninitialized_fill compile failure if no default assignment operator
--- 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 have already a test for that, in ext/is_pod.cc. But
> we
> have a problem with templates. This:
>
> template
> struct A
> {
> A() { }
> };
>
> has __is_pod(A) 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 I should fix my implementation?
Perhaps you need to call complete_type in the traits implementation to
ensure that A is completed, if it can be. (Or, if __is_pod
requires, by the language standards, a complete type, you can use
complete_type_or_else.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32158
[Bug c++/32158] uninitialized_fill compile failure if no default assignment operator
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-05-30 21:31 ---
(In reply to comment #3)
> has __is_pod(A) 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 I should fix my implementation?
Yes, complete the type :).
Here is a testcase which works correctly:
template
struct A
{
A() { }
};
A a;
int t[__is_pod(A)?-1:1];
- cut ---
If you remove the "A a;" the test fails.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32158
[Bug c++/32158] uninitialized_fill compile failure if no default assignment operator
--- 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:
template
struct A
{
A() { }
};
has __is_pod(A) 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 I should fix my implementation?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32158
[Bug c++/32158] uninitialized_fill compile failure if no default assignment operator
--- 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 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 concept of > POD-ness: it returns true for std::pair, which is *not* a POD. The problem is > that std::pair isn't an aggregate type, thus cannot be a POD. I think I should > just also check CP_AGGREGATE_TYPE_P, in order to fix that. Mark, can you > confirm that? Thanks in advance. pop_type_p is indeed to exactly implement the standard definition of POD. If it's giving the wrong answer, then we need to fix it. There is code to set CLASSTYPE_NON_POD_P for non-aggregates. So, I'm not sure what's going wrong, but we need to track it down. Let me know if you need help. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32158
[Bug c++/32158] uninitialized_fill compile failure if no default assignment operator
--- 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 concept of POD-ness: it returns true for std::pair, which is *not* a POD. The problem is that std::pair isn't an aggregate type, thus cannot be a POD. I think I should just also check CP_AGGREGATE_TYPE_P, in order to fix that. Mark, can you confirm that? Thanks in advance. -- pcarlini at suse dot de changed: What|Removed |Added CC||mark at codesourcery dot com AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|UNCONFIRMED |ASSIGNED Component|libstdc++ |c++ Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-05-30 21:00:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32158
