[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 stdio.h
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++/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*) built-in
/Users/dgregor/op.cpp:10: note: operator==(volatile int*,
volatile int*) built-in
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++/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++/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 |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++/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
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++/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++/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++/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 class T
struct Foo {
int i;
};
struct Baz
{
int* j;
};
template class T
struct Bar : public FooT, Baz {
using Baz::j;
char* baz () { return j; } // { dg-error cannot convert }
};
template class T
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++/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_wrapperT
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_wrapperT::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_wrapperint (test_type::*)()::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 tr1/functional
struct test_type
{
int member();
int cmember()const;
int member2(char);
int cmember2(char)const;
};
struct functor1 : public std::unary_functionint, double
{
double operator()(int)const;
};
struct functor2 : public std::binary_functionint, char, double
{
double operator()(int, char)const;
};
template class T
void verify_return_type(T, T)
{
}
int main()
{
test_type* null_tt = 0;
const test_type* null_ttc = 0;
int zero;
std::tr1::reference_wrapperdouble (int)* pr1;
verify_return_type((*pr1)(0), double());
std::tr1::reference_wrapperdouble (*)(int)* pr2;
verify_return_type((*pr2)(0), double());
std::tr1::reference_wrapperint (test_type::*)()* pr3;
verify_return_type((*pr3)(null_tt), int());
std::tr1::reference_wrapperint (test_type::*)()const* pr4;
verify_return_type((*pr4)(null_ttc), int());
std::tr1::reference_wrapperfunctor1* pr5;
verify_return_type((*pr5)(zero), double());
std::tr1::reference_wrapperdouble (int, char)* pr1b;
verify_return_type((*pr1b)(0,0), double());
std::tr1::reference_wrapperdouble (*)(int, char)* pr2b;
verify_return_type((*pr2b)(0,0), double());
std::tr1::reference_wrapperint (test_type::*)(char)* pr3b;
verify_return_type((*pr3b)(null_tt,zero), int());
std::tr1::reference_wrapperint (test_type::*)()const* pr4b;
verify_return_type((*pr4b)(null_ttc), int());
std::tr1::reference_wrapperfunctor2* 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_wrapperT::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=10225action=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
[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.
templateclass T struct wrap {};
templatetypename T bool operator==(wrapT, wrapT);
templatetypename T
void g(T, wrapwrapint x)
{
bool b = x == x;
}
templatetypename T int operator==(wrapwrapT , wrapwrapT );
void h()
{
wrapwrapint 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
