[Bug c++/35890] New: __attribute__((format)) fails for methods of template classes

Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zak at transversal dot com GCC build triplet: x86_64_pc_linux_gnu GCC host triplet: x86_64-pc-linux-gnu GCC target triplet: x86_64_pc_linux_gnu http://gcc.gnu.org/bugzilla

[Bug c++/35773] New: [4.3 regression] auto_ptr references don't convert

Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zak at transversal dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35773

[Bug c++/31899] New: [4.2/4.3 regression] -g and using declaration causing ICE in reference_to_unused

++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zak at transversal dot com GCC build triplet: x86_64_pc_linux_gnu GCC host triplet: x86_64-pc-linux-gnu GCC target triplet: x86_64_pc_linux_gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31899

[Bug c++/31187] New: [4.2 regression] extern declaration of variable in anonymous namespace prevents use of its address as template argument

Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zak at transversal dot com GCC build triplet: x86_64-pc-linux-gnu GCC host

[Bug c++/27177] [4.0 Regression] ICE in build_simple_base_path, at cp/class.c:474

--- Comment #8 from zak at transversal dot com 2006-08-18 11:21 --- However, that patch breaks the following code, which requires *implicit* derived-to-base conversion: struct Z {}; struct A : Z {}; Z* implicitToZ (Z*); struct B : A { static

[Bug c++/26195] [4.0/4.1/4.2 regression] pragma interface no longer handles explicit names

--- Comment #9 from zak at transversal dot com 2006-03-01 15:57 --- The previous target milestone was 4.0.3 -- does the retargeting mean that this regression will not be fixed on that branch at all? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26195

[Bug c++/26195] [4.0/4.1/4.2 regression] pragma interface no longer handles explicit names

--- Comment #7 from zak at transversal dot com 2006-02-14 12:08 --- (We are currently using these pragmas extensively to ensure that various symbols are laid down *only* in low-level libraries, as a partial workaround for the COMDAT/dlopen issues described in http://gcc.gnu.org/ml/gcc

[Bug c++/26195] [4.0 regression] pragma interface no longer handles explicit names

--- Comment #4 from zak at transversal dot com 2006-02-13 18:46 --- Marking as 4.0 regression, filling in versions known to work/fail. Here is a patch, tested against mainline, which seems to fix this: http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01002.html -- zak at transversal

[Bug c++/26195] pragma interface no longer handles explicit names

--- Comment #1 from zak at transversal dot com 2006-02-10 15:00 --- I think the bug here is that handle_pragma_interface in gcc/cp/lex.c is calling get_file_info(filename), which refers to the name in the #pragma, rather than get_file_info(lbasename(input_filename)) -- hence

[Bug c++/26195] pragma interface no longer handles explicit names

--- Comment #2 from zak at transversal dot com 2006-02-10 15:53 --- On thinking about this further, I don't understand the application of lbasename to the input_filename before it is passed to get_fileinfo. I included this for consistency with the code in cxx_make_type that checks

[Bug c++/26195] pragma interface no longer handles explicit names

--- Comment #3 from zak at transversal dot com 2006-02-10 17:05 --- After making the change suggested in comment #1, the following test case demonstrates the problem mentioned in comment #2. $ g++ -Wall -pedantic -I. foo.cc nm -A foo.o [no output] If you switch the name in the pragma

[Bug c++/26195] New: pragma interface no longer handles explicit names

: unassigned at gcc dot gnu dot org ReportedBy: zak at transversal dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26195

[Bug libstdc++/26127] New: tr1/hashtable compile errors

Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zak at transversal dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26127

[Bug libstdc++/26131] New: TR1 unordered associative containers: insert with hint returns wrong type

at gcc dot gnu dot org ReportedBy: zak at transversal dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26131

[Bug libstdc++/26132] New: tr1/hashtable: rehash not implemented

++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zak at transversal dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26132

[Bug libstdc++/26131] TR1 unordered associative containers: insert with hint returns wrong type

--- Comment #2 from zak at transversal dot com 2006-02-06 15:18 --- Sorry, my mistake -- I thought I had checked this on both. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26131

[Bug target/18300] Infinite loop when passing object with 3+ base classes by value

--- Additional Comments From zak at transversal dot com 2004-11-12 16:33 --- Amended patch: http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00948.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18300

[Bug target/18300] Infinite loop when passing object with 3+ base classes by value

--- Additional Comments From zak at transversal dot com 2004-11-10 12:36 --- I've submitted a patch which fixes this: http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00811.html -- What|Removed |Added

[Bug target/18300] New: Infinite loop when passing object with 3+ base classes by value

Version: 3.3.4 Status: UNCONFIRMED Severity: normal Priority: P2 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zak at transversal dot com CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: x86_64-pc

[Bug target/18300] Infinite loop when passing object with 3+ base classes by value

-- What|Removed |Added Keywords||compile-time-hog Known to fail||3.2.3 3.3.3 3.3.4 3.3.5