[Bug libstdc++/54577] New: deque::erase() still takes iterator instead of const_iterator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54577 Bug #: 54577 Summary: deque::erase() still takes iterator instead of const_iterator Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: thunder...@gmail.com In C++11 mode, deque::erase() should be able to take const_iterator instead of iterator. It's not reflected in bits/deque.tcc yet. Checked 4.7, it's the same. (Line 193 of bits/deque.tcc:) template typename deque<_Tp, _Alloc>::iterator deque<_Tp, _Alloc>:: erase(iterator __position)
[Bug c++/47356] New: Internal error when assigning with incomplete uniform initializer list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47356 Summary: Internal error when assigning with incomplete uniform initializer list Product: gcc Version: 4.4.5 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: thunder...@gmail.com Created attachment 23027 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23027 preprocessed source gcc reports internal error when assigning an aggregate with a brace-enclosed initializer list (should report normal compile error instead). struct C { C(); }; struct A { bool i; C p[1]; }; void foo() { A a1; a1 = { false }; } $ g++ -std=c++0x -c gcc_bug.C gcc_bug.C: In function 'void foo()': gcc_bug.C:13: internal compiler error: in build_value_init_noctor, at cp/init.c:406
[Bug libstdc++/57666] New: valarray::operator= in c++11 mode does not adapt to size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57666 Bug ID: 57666 Summary: valarray::operator= in c++11 mode does not adapt to size Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: thunderliu at gmail dot com Non-member operators for valarray<> returns instance of _Expr<> (lazy evaluation?), instead of another valarray<>. This is non-conforming but probably not a bug. But if the returned value is assigned to another valarray<>, c++11 requires operator= to be size-adapting, but 4.7.2 does not do that for _Expr<>. For example: #include extern "C" int printf(const char *, ...); int main() { typedef std::valarray A; A a(3), b(3), d; d=a+b; printf("%d\n", d.size()); // 0, incorrect d=a; printf("%d\n", d.size()); // 3, correct } (Preprocessed source attached.)
[Bug libstdc++/57666] valarray::operator= in c++11 mode does not adapt to size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57666 thunderliu at gmail dot com changed: What|Removed |Added Target||x86_64-redhat-linux --- Comment #1 from thunderliu at gmail dot com --- Compile the code with -std=c++0x
[Bug libstdc++/57666] valarray::operator= in c++11 mode does not adapt to size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57666 --- Comment #3 from thunderliu at gmail dot com --- Sorry I missed that. But the remaining (which is the point of this bug) still stands. (In reply to Jonathan Wakely from comment #2) > (In reply to thunderliu from comment #0) > > Non-member operators for valarray<> returns instance of _Expr<> (lazy > > evaluation?), instead of another valarray<>. This is non-conforming but > > probably not a bug. > > 26.6.1 [valarray.syn]/3 "Any function returning a valarray is permitted > to return an object of another type, provided all the const member functions > of valarray are also applicable to this type."