[Bug c/44715] New: Break in increment expression of for statement inconsistent with g++

Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: doug dot gregor at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44715

[Bug c++/38174] New: Missing some built-in candidates for operator overloading

at gcc dot gnu dot org ReportedBy: doug dot gregor at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38174

[Bug c++/37553] [4.3/4.4 Regression] ICE in build_c_cast

--- Comment #5 from doug dot gregor at gmail dot com 2008-10-14 16:03 --- Fixed on mainline -- doug dot gregor at gmail dot com changed: What|Removed |Added

[Bug c++/37553] [4.3/4.4 Regression] ICE in build_c_cast

--- Comment #3 from doug dot gregor at gmail dot com 2008-09-24 06:01 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2008-09/msg01667.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37553

[Bug c++/37553] [4.3/4.4 Regression] ICE in build_c_cast

-- doug dot gregor at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |doug dot gregor at gmail dot |dot org

[Bug c++/31141] [4.3 regression] ICE with ellipsis in template parameter list

--- Comment #1 from doug dot gregor at gmail dot com 2007-03-27 15:10 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00799.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31141

[Bug c++/31372] [4.3 Regression] Segfault in cp/parser.c: cp_parser_parameter_declaration

--- Comment #2 from doug dot gregor at gmail dot com 2007-03-27 15:10 --- Does the following patch solve the problem? http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00799.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31372

[Bug c++/31140] [4.3 regression] ICE with ellipsis in template parameter list

--- Comment #1 from doug dot gregor at gmail dot com 2007-03-27 15:12 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00799.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31140

[Bug c++/31138] [4.3 regression] ICE with ellipsis

--- Comment #4 from doug dot gregor at gmail dot com 2007-03-27 15:12 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00799.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31138

[Bug middle-end/30666] [4.3 Regression] warning: canonical types differ for identical types double __complex__ and double __complex__

--- Comment #8 from doug dot gregor at gmail dot com 2007-03-03 19:50 --- Patch is here: http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00191.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30666

[Bug middle-end/30666] [4.3 Regression] warning: canonical types differ for identical types double __complex__ and double __complex__

--- Comment #6 from doug dot gregor at gmail dot com 2007-02-26 15:26 --- This looks like a straightforward fix to build_common_tree_nodes2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30666

[Bug c++/29993] typdef declaration of cv-qualified function in class

--- Comment #3 from doug dot gregor at gmail dot com 2007-01-29 13:50 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01828.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29993

[Bug libstdc++/30571] New: Use of C++0x keywords in libstdc++-v3 headers

++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: doug dot gregor at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30571

[Bug libstdc++/30571] Use of C++0x keywords in libstdc++-v3 headers

--- Comment #2 from doug dot gregor at gmail dot com 2007-01-24 04:36 --- (In reply to comment #1) This is the normal problem adding a keyword in any language, I don't see why C++0x 's static_assert not use a keyword in the already reserved identifier namespace? The C++ committee

[Bug c++/20599] variadic template support

--- Comment #4 from doug dot gregor at gmail dot com 2006-09-12 18:27 --- It's a chicken-and-egg problem. Nobody on the committee wants to standardize anything that isn't existing practice, but we only want to accept patches for features that have been written into the current working

[Bug libstdc++/27404] New: Rope iterators are not InputIterators

are not InputIterators Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: doug dot gregor at gmail dot com http://gcc.gnu.org

[Bug libstdc++/27162] New: search_n uses == when it should use binary_pred

Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: doug dot gregor at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27162

[Bug c++/27167] New: Inadequate type-checking for non-dependent expressions in return statements

expressions in return statements Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: doug dot gregor at gmail

[Bug libstdc++/24800] tr1::mem_fn returns a function object that does not inherit from std::unary_function/binary_function

--- Comment #4 from doug dot gregor at gmail dot com 2005-11-12 11:33 --- This is not a bug. TR1 3.5 refers to member function pointers, not member data pointers as in the submitted test case. mem_fn has no result_type for member data pointers because the constness of the result type

[Bug libstdc++/24803] tr1::reference_wrapper and pointers to member functions

--- Comment #2 from doug dot gregor at gmail dot com 2005-11-12 13:23 --- I don't know how to classify this. The basic problem is one that isn't really solveable without rvalue references: you can't pass a literal (e.g., 0) into the operator() of a reference_wrapper or any other

[Bug libstdc++/24818] New: tr1::reference_wrapper improperly calls nullary function objects

Version: 4.1.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: doug dot gregor at gmail dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc

[Bug libstdc++/24818] tr1::reference_wrapper improperly calls nullary function objects

--- Comment #1 from doug dot gregor at gmail dot com 2005-11-12 13:31 --- Created an attachment (id=10225) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10225action=view) Mainline (4.1.0) patch to test and fix this problem The fix is trivial. The changes to the test case cause

[Bug c++/21802] New: Two-stage name lookup fails for operations

++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: doug dot gregor at gmail dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21802