[Bug c/44715] New: Break in increment expression of "for" statement inconsistent with g++
The following program exhibits different behavior with gcc vs. g++: dgregor$ cat t.c #include int main() { int i; for( i = 0; i < 3; ) for( ; ; ({ i++; break; }) ) printf( "%d\n", i ); } With gcc, the break in the statement expression applies to the outer "for" loop, so we get just "0" as output: dgregor$ gcc t.c && ./a.out 0 with g++, the break in the statement expression applies to the inner "for" loop, so we get "0" "1" and "2" as the output: dgregor$ g++ t.c && ./a.out 0 1 2 g++ seems to have the right behavior here, and in any case g++ can't really be changed now: Qt's foreach macro depends on having "break" bind to the inner for loop. -- Summary: Break in increment expression of "for" statement inconsistent with g++ Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal 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++/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 draft. How will C++0x ever move forward? GCC is uniquely situated to lead the way to C++0x. Our support for C++03 is excellent, and the code is open and (relatively) accessible to experimenters. There are patches "out there" for rvalue references, decltype, variadic templates, and concepts, among other things. If the patch is ready, and we think the feature is worth pursuing, we should accept the patch. Our acceptance allows greater experimentation with and understanding of new ideas within the C++ community and how they interact, and will improve the C++0x language as a whole. Of course, it also means that GCC will have one of the most mature implementations of the upcoming C++0x features once C++0x is finally written in stone. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20599
[Bug libstdc++/30571] New: Use of C++0x keywords in libstdc++-v3 headers
The headers in ext/pb_ds use the identifier `static_assert' as the name of a class (which emulates static assertions). The class itself is declared in libstdc++-v3/include/ext/pb_ds/detail/type_utils.hpp and is used from a handful of other headers. This means that these facilities cannot be used with -std=c++0x and will warn if the -Wc++0x-compat flag goes in (see http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01971.html). I have two suggestions: 1) Rename class `static_assert' to something that isn't a C++0x keyword. 2) When __GXX_EXPERIMENTAL_CXX0X__ is defined, change the macro PB_DS_STATIC_ASSERT to use the real static_assert instead of this workaround. The macro is defined in several places, all of which will have to change anyway (when the static_assert class is renamed). I know this affects 4.3; I'm not sure if it affects (or matters for) 4.2 or earlier, but I suggest at least doing #1 everywhere that ext/pb_ds is available. -- Summary: Use of C++0x keywords in libstdc++-v3 headers Product: gcc Version: 4.3.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=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 opted to give this new functionality a new keyword, knowing that it breaks backward compatibility (in an admittedly small way). If we don't like the spelling, this is the time to complain directly to the committee. Unless we get them to change the spelling (very doubtful), we're going to have to deal with this. Other keywords are coming down the pipe... I expect that by April we'll also have "decltype" and "constexpr" to deal with, and in the future we'll probably also see "concept" and "concept_map", among other things. The -Wc++0x-compat warning is proposed to help us (and our users) make this transition smoothly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30571
[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 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 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 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 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 |com Status|NEW |ASSIGNED Last reconfirmed|2008-09-17 21:02:56 |2008-09-24 04:37:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37553
[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
--- 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 Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|4.3.3 |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37553
[Bug c++/38174] New: Missing some built-in candidates for operator overloading
GCC fails to compile the following example, because it isn't generating all of the necessary built-in candidates for operator== and operator-: struct VolatileIntPtr { operator int volatile *(); }; struct ConstIntPtr { operator int const *(); }; void test_with_ptrs(VolatileIntPtr vip, ConstIntPtr cip) { bool b1 = (vip == cip); long p1 = vip - cip; } Note that in the (first) error message: /Users/dgregor/op.cpp: In function void test_with_ptrs(VolatileIntPtr, ConstIntPtr): /Users/dgregor/op.cpp:10: error: no match for operator== in vip == cip /Users/dgregor/op.cpp:10: note: candidates are: operator==(const int*, const int*) /Users/dgregor/op.cpp:10: note: operator==(volatile int*, volatile int*) we're missing the built-in candidate operator==(const volatile int*, const volatile int*) that would be picked. -- Summary: Missing some built-in candidates for operator overloading Product: gcc Version: 4.0.1 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal 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=38174
[Bug c++/21802] New: Two-stage name lookup fails for operations
The following program should compile (and does on recently EDG-base compilers), because the operator== is build when the template is parsed (it is non-dependent). However, GCC looks up the == operator at instantiation time and finds the second, incorrect definition of operator==. This is similar to Bug 2922, but deals with operators instead of normal function names, which GCC handles (very) differently internally. template struct wrap {}; template bool& operator==(wrap, wrap); template void g(T, wrap > x) { bool& b = x == x; } template int& operator==(wrap >, wrap >); void h() { wrap > x; g(17, x); } -- Summary: Two-stage name lookup fails for operations Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ 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
[Bug libstdc++/27162] New: search_n uses == when it should use binary_pred
The binary predicate variant of search_n for forward iterators uses the "==" operator where it should be calling __binary_pred. Patch (against GCC 4.1.0, should also apply to the trunk) attached. Bug report courtest of ConceptGCC's type checker :) --- include/bits/stl_algo.h.old 2006-04-14 11:59:59.0 -0400 +++ include/bits/stl_algo.h 2006-04-14 12:00:08.0 -0400 @@ -748,7 +748,7 @@ __n = __count; _ForwardIterator __i = __first; ++__i; - while (__i != __last && __n != 1 && *__i == __val) + while (__i != __last && __n != 1 && __binary_pred(*__i, __val)) { ++__i; --__n; 2006-04-14 Douglas Gregor <[EMAIL PROTECTED]> * include/bits/stl_algo.h (__search_n): Use __binary_pred, not ==. -- Summary: search_n uses == when it should use binary_pred Product: gcc 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
In the following test case, the two "baz" functions are ill-formed. Since the expression being returned is non-dependent, the improper return value should be detected when the template is initially parsed. template struct Foo { int i; }; struct Baz { int* j; }; template struct Bar : public Foo, Baz { using Baz::j; char* baz () { return j; } // { dg-error "cannot convert" } }; template struct Bar2 : Baz { using Baz::j; char* baz () { return j; } // { dg-error "cannot convert" } }; -- Summary: Inadequate type-checking for non-dependent 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 dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27167
[Bug libstdc++/27404] New: Rope iterators are not InputIterators
Rope iterators (both const and mutable) do not meet the requirements of an Input Iterator, because their dereference operator only operates on non-const objects. Table 72 of the C++98 Standard requires the valid expression *a, where a is a const iterator, but this valid expression does not work with a non-const operator*. To fix, make operator* and everything it relies on "const". This might have an unfortunate ripple effect; an alternative (but ugly) approach would be to add a new operator* to _Rope_iterator and _Rope_const_iterator that const_cast's and forwards: reference operator*() const { return *const_cast<_Rope_iterator&>(*this); } reference operator*() const { return *const_cast<_Rope_const_iterator&>(*this); } This problem is very unlikely to cause problems in user code, but it makes ConceptGCC sad. -- Summary: Rope iterators 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/bugzilla/show_bug.cgi?id=27404
[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 depends on the constness of the argument type; use result_of to get the appropriate result type given the argument type. See also TR1 DR 10.24 "Mem_fn result_type for pointer to data member". -- doug dot gregor at gmail dot com changed: What|Removed |Added CC| |doug dot gregor at gmail dot | |com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24800
[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 function object in TR1, because the arguments are accepted by T&. Strictly speaking, this is not a bug. However, there are several ways that we could make this work, because John is doing some very sensible things here [*]. Some ideas are: (1) Strong-arm a C++ front-end guru into implementing rvalue references, then use them in the TR1 function objects. Heck, we'll need 'em for C++0x anyway :) (2) When we know the argument types (e.g., when the T in reference_wrapper is a function pointer, member function pointer, or class that is derived from unary_function or binary_function), we could inject operator() overloads that have precise type signatures, e.g., T::result_type operator()(T::argument_type const&); That's really messy and would require quite a bit of refactoring in reference_wrapper to get right. (3) Provide variants of operator() that accept "const T&" arguments in addition to those that accept "T&" arguments. This makes bind/mem_fn/reference_wrapper easier to use, but the number of overloads blows up exponentially. Since we've already run into compilation time issues, we'd have stop doing this once we hit four to five arguments (then we get the "I just added one more argument and everything blew up!" bug reports). (4) Strong-arm a C++ front-end guru into allowing the conversion operator (operator T&() const) to actually work for function call expressions, making most of reference_wrapper::operator() magically go away. (Peter Dimov has suggested this before, but it hasn't really worked its way through the committee). (1) is the forward-looking solution; (2) and (3) are hacks that could make the code even uglier (ick!). (4) only fixes the problem for reference_wrapper. At this point, I favor (1) strongly, but I'm not in a position to strong-arm nor am I in a position to implement rvalue references myself. [*] One thing in the code that perhaps shouldn't work is passing the literal 0 as the argument to reference_wrapper::operator() That means that we need to be able to realize that it's a literal 0 (tricky, messy, but doable; see the construction-from-literal-zero trick in tr1::function<>) and then convert that to a NULL test_type*. I don't think John meant to test that, and I don't really think we should care if it's broken. A slightly simplified version of John's test case that does work properly follows. Replace any of null_tt, null_ttc, or zero in the calls to reference_wrapper objects to trigger compiler errors. #include struct test_type { int member(); int cmember()const; int member2(char); int cmember2(char)const; }; struct functor1 : public std::unary_function { double operator()(int)const; }; struct functor2 : public std::binary_function { double operator()(int, char)const; }; template void verify_return_type(T, T) { } int main() { test_type* null_tt = 0; const test_type* null_ttc = 0; int zero; std::tr1::reference_wrapper* pr1; verify_return_type((*pr1)(0), double()); std::tr1::reference_wrapper* pr2; verify_return_type((*pr2)(0), double()); std::tr1::reference_wrapper* pr3; verify_return_type((*pr3)(null_tt), int()); std::tr1::reference_wrapper* pr4; verify_return_type((*pr4)(null_ttc), int()); std::tr1::reference_wrapper* pr5; verify_return_type((*pr5)(zero), double()); std::tr1::reference_wrapper* pr1b; verify_return_type((*pr1b)(0,0), double()); std::tr1::reference_wrapper* pr2b; verify_return_type((*pr2b)(0,0), double()); std::tr1::reference_wrapper* pr3b; verify_return_type((*pr3b)(null_tt,zero), int()); std::tr1::reference_wrapper* pr4b; verify_return_type((*pr4b)(null_ttc), int()); std::tr1::reference_wrapper* pr5b; verify_return_type((*pr5b)(zero,zero), double()); } -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24803
[Bug libstdc++/24818] New: tr1::reference_wrapper improperly calls nullary function objects
tr1::reference_wrapper::operator()() should not dereference get() before calling the function object, because get() returns a reference (not a pointer). -- Summary: tr1::reference_wrapper improperly calls nullary function objects 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 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=24818
[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=10225&action=view) Mainline (4.1.0) patch to test and fix this problem The fix is trivial. The changes to the test case cause failures that are fixed by the patch to ref_wrap_iterate.h. All of the tr1/3_function_objects tests still pass on i686-pc-linux-gnu. 2005-11-12 Douglas Gregor <[EMAIL PROTECTED]> * include/tr1/ref_wrap_iterate.h (reference_wrapper::operator()()): Don't dereferene the result of get() before calling it; it's already a reference. * testsuite/tr1/3_function_objects/reference_wrapper/invoke.cc: Test nullary calls to reference_wrappers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24818