libstdc++/10082: Wrong semantics in uninitialized_fill_n
jkanze@caicheuvreuse.com
jkanze@caicheuvreuse.com
Fri Mar 14 15:07:00 GMT 2003
>Number: 10082
>Category: libstdc++
>Synopsis: Wrong semantics in uninitialized_fill_n
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: rejects-legal
>Submitter-Id: net
>Arrival-Date: Fri Mar 14 14:56:01 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator: James Kanze
>Release: g++3 (GCC) 3.2.2
>Organization:
>Environment:
054@~/tmp/news (98): uname -a
SunOS padev054 5.8 Generic_108528-13 sun4u sparc SUNW,Ultra-5_10
>Description:
The compiler fails to compile the attached legal code.
The reason for this is that the library has not
implemented uninitialized_fill_n (and presumably
uninitialized_fill) in a conforming manner.
Log of the compile:
------------------------------------------
g++3 --verbose ccelide.cc -o ccelide
Reading specs from /home/team02/jakan/gnu/lib/gcc-lib/sparc-sun-solaris2.8/3.2.2/specs
Configured with: ../gcc-3.2.2/configure --prefix=/home/team02/jakan/gnu --program-suffix=3 --enable-threads=posix
Thread model: posix
gcc version 3.2.2
/home/team02/jakan/gnu/lib/gcc-lib/sparc-sun-solaris2.8/3.2.2/cc1plus -v -D__GNUC__=3 -D__GNUC_MINOR__=2 -D__GNUC_PATCHLEVEL__=2 -D__GXX_ABI_VERSION=102 -Dsparc -Dsun -Dunix -D__svr4__ -D__SVR4 -D__PRAGMA_REDEFINE_EXTNAME -D__sparc__ -D__sun__ -D__unix__ -D__svr4__ -D__SVR4 -D__PRAGMA_REDEFINE_EXTNAME -D__sparc -D__sun -D__unix -Asystem=unix -Asystem=svr4 -D__NO_INLINE__ -D__STDC_HOSTED__=1 -D_XOPEN_SOURCE=500 -D_LARGEFILE_SOURCE=1 -D_LARGEFILE64_SOURCE=1 -D__EXTENSIONS__ -D__SIZE_TYPE__=unsigned int -D__PTRDIFF_TYPE__=int -D__WCHAR_TYPE__=long int -D__WINT_TYPE__=long int -D__GCC_NEW_VARARGS__ -Acpu=sparc -Amachine=sparc ccelide.cc -D__GNUG__=3 -D__DEPRECATED -D__EXCEPTIONS -quiet -dumpbase ccelide.cc -version -o /var/tmp//cc4LfBVo.s
GNU CPP version 3.2.2 (cpplib) (sparc ELF)
GNU C++ version 3.2.2 (sparc-sun-solaris2.8)
compiled by GNU C version 3.2.2.
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory "/home/team02/jakan/gnu/sparc-sun-solaris2.8/include"
#include "..." search starts here:
#include <...> search starts here:
/home/team02/jakan/gnu/include/c++/3.2.2
/home/team02/jakan/gnu/include/c++/3.2.2/sparc-sun-solaris2.8
/home/team02/jakan/gnu/include/c++/3.2.2/backward
/home/team02/jakan/gnu/include
/home/team02/jakan/gnu/lib/gcc-lib/sparc-sun-solaris2.8/3.2.2/include
/usr/include
End of search list.
ccelide.cc: In function `void std::_Construct(_T1*, const _T2&) [with _T1 =
Track, _T2 = Track]':
/home/team02/jakan/gnu/include/c++/3.2.2/bits/stl_uninitialized.h:191: instantiated from `_ForwardIter std::__uninitialized_fill_n_aux(_ForwardIter, _Size, const _Tp&, __false_type) [with _ForwardIter = Track*, _Size = int, _Tp = Track]'
/home/team02/jakan/gnu/include/c++/3.2.2/bits/stl_uninitialized.h:216: instantiated from `_ForwardIter std::uninitialized_fill_n(_ForwardIter, _Size, const _Tp&) [with _ForwardIter = Track*, _Size = int, _Tp = Track]'
ccelide.cc:26: instantiated from here
ccelide.cc:11: `Track::Track(const Track&)' is private
/home/team02/jakan/gnu/include/c++/3.2.2/bits/stl_construct.h:78: within this
context
------------------------------------------
>How-To-Repeat:
>Fix:
The standard defines the semantics in terms of code.
Why not use it?
>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="ccelide.cc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="ccelide.cc"
CiNpbmNsdWRlIDxvc3RyZWFtPgojaW5jbHVkZSA8aW9zdHJlYW0+CiNpbmNsdWRlIDxtZW1vcnk+
CgpjbGFzcyBUcmFjawp7CnB1YmxpYzoKICAgIFRyYWNrKCBpbnQgaSApIDsKcHJpdmF0ZToKICAg
IFRyYWNrKCBUcmFjayBjb25zdCYgb3RoZXIgKSA7Cgpwcml2YXRlOgogICAgaW50ICAgICAgICAg
ICAgICAgICBteUkgOwp9IDsKClRyYWNrOjpUcmFjayggaW50IGkgKQogICAgOiAgIG15SSggaSAp
CnsKfQoKaW50Cm1haW4oKQp7CiAgICBUcmFjayogICAgICAgICAgICAgIG1lbSA9IChUcmFjayop
OjpvcGVyYXRvciBuZXcoIDMgKiBzaXplb2YoIFRyYWNrICkgKSA7CiAgICBzdGQ6OnVuaW5pdGlh
bGl6ZWRfZmlsbF9uKCBtZW0sIDMsIFRyYWNrKCAyICkgKSA7CiAgICBmb3IgKCBpbnQgaSA9IDAg
OyBpIDwgMyA7ICsrIGkgKSB7CiAgICAgICAgbWVtWyBpIF0uflRyYWNrKCkgOwogICAgfQogICAg
OjpvcGVyYXRvciBkZWxldGUoIG1lbSApIDsKICAgIHJldHVybiAwIDsKfQo=
More information about the Gcc-bugs
mailing list