[Bug libstdc++/24595] std::tr1::get_deleter not declared

2005-11-12 Thread gcc-bugzilla at kayari dot org 


--- Comment #6 from gcc-bugzilla at kayari dot org  2005-11-12 14:12 ---
Created an attachment (id=10227)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10227&action=view)
alternative fix

This is a fixed version of the previous patch that passes tests on
linux-x86_64.

This patch makes all specialisations of get_deleter friends, not just the ones
where _Tp == _Tp1 ... but that's probably not a big deal.  


-- 

gcc-bugzilla at kayari dot org changed:

   What|Removed |Added

  Attachment #10194|0   |1
is obsolete||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24595

[Bug c++/25137] Warning "missing braces around initializer" causing problems with tr1::array

2005-12-06 Thread gcc-bugzilla at kayari dot org 


--- Comment #9 from gcc-bugzilla at kayari dot org  2005-12-06 13:07 ---
I've often found this warning to be a nuisance, because it's correct and
well-defined to omit some braces from the initializer.

There are many cases where the warning is useful, e.g. with aggregates that
have several members (which may be aggregates themselves), but when the type
contains a single member (possibly of array type) then the extra braces are
often just clutter.

Pff the top of my head, I would like a way to disable the warning iff the
aggregate has a single member and iff the initializer contains exactly the
right number of elements to initialize that single member.  e.g.

struct S { int s[3]; };
S s1 = { 1, 1, 1 };   // OK   - missing braces but correct number
S s2 = { 1, 1 };  // WARN - no initializer for s2.s[2]
S s3 = { { 1, 1 } };  // OK   - braces correct but missing init

I don't think this would be useful only for tr1::array, but for lots of similar
code.  Obvious and closely-related examples are the block and carray templates
in Austern and Josuttis's books.


-- 

gcc-bugzilla at kayari dot org changed:

   What|Removed |Added

 CC|            |gcc-bugzilla at kayari dot
   |    |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25137

[Bug c++/13590] [DR39] Non-existing ambiguity when inhering through virtuals two identical using declarations.

2005-12-10 Thread gcc-bugzilla at kayari dot org 


--- Comment #19 from gcc-bugzilla at kayari dot org  2005-12-10 13:17 
---
would the summary be clarified by changing "Non-existing ambiguity when
inhering through virtuals two identical using declarations" to "Ambiguity due
to two using declarations for same member of virtual base" ?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13590

[Bug c++/2316] g++ fails to overload on language linkage

2006-10-14 Thread gcc-bugzilla at kayari dot org 


--- Comment #13 from gcc-bugzilla at kayari dot org  2006-10-15 03:24 
---
If this ever gets fixed (which I hope it does) then maybe it should depend on
-std=c++98 so this continues to work by default, or it will break a lot of code
that incorrectly passes extern "C++" functions to e.g. pthread_create and
sigaction.  That's a lot of code.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316

[Bug c++/30111] New: Value-initialization of POD base class doesn't initialize members

2006-12-07 Thread gcc-bugzilla at kayari dot org 
#include 

int main()
{
struct pod {
int i;
};

struct inherit : pod {
inherit() : pod() {}
};

struct compose {
compose() : p() {}
pod p;
};

inherit i;
compose c;

std::cout << i.i << std::endl;
std::cout << c.p.i << std::endl;
}

In both cases the pod object is explicitly value-initialized, which according
to 8.5para5 means that "every non-static data member ... is value-initialized"

compose::pod::i is value-initialised, inherit::i is not.  This can be seen from
the values printed out for i.i and by using Purify.

Same result with GCC 4.1.1, 3.4.3, 3.3.4 on Solaris 9, GCC 3.4.3 on AIX 5/3

Valgrind is being weird so I can't test it on Linux, butI don't think it's
platform-dependent.


-- 
   Summary: Value-initialization of POD base class doesn't
initialize members
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at kayari dot org
GCC target triplet: sparc-sun-solaris2.9


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30111

[Bug c++/30111] Value-initialization of POD base class doesn't initialize members

2006-12-07 Thread gcc-bugzilla at kayari dot org 


--- Comment #1 from gcc-bugzilla at kayari dot org  2006-12-07 18:03 ---
Values printed out confirm it on Linux for 3.3.5 20050117 (prerelease) (SUSE
Linux), and official FSF 3.4.3, 4.0.1, 4.0.2, 4.1.1

N.B. I meant AIX 5.3, not 5/3


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30111

[Bug c++/30111] Value-initialization of POD base class doesn't initialize members

2006-12-08 Thread gcc-bugzilla at kayari dot org 


--- Comment #4 from gcc-bugzilla at kayari dot org  2006-12-08 10:36 ---
Richard, there's no difference between pod() and p() in this case, both are
value-initialisations of a POD class, therefore all non-static data members
should be value-initialised.  I cited 8.5p5 for good reason :)

Sun CC 6.1 and 8 and IBM xlC 6 get this right.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30111