[Bug libstdc++/54577] New: deque::erase() still takes iterator instead of const_iterator

2012-09-13 Thread thunderliu at gmail dot com
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

2011-01-19 Thread thunderliu at gmail dot com
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

2013-06-21 Thread thunderliu at gmail dot com
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

2013-06-21 Thread thunderliu at gmail dot com
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

2013-06-21 Thread thunderliu at gmail dot com
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."