[Bug c++/26974] hidden declarations klobber STL
--- Comment #4 from igodard at pacbell dot net 2006-04-19 06:36 --- I can send you a linked binary with symbols, for either x86 Linux or Cygwin. Would that help? Ivan -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974
[Bug c++/27215] New: fails to resolve
enum A{b,c};
enum M{n,o};
class foo {
public:
operator A() { return b; }
operator int() { return 0; }
};
int main() {
foo a;
unsigned int x = a;
}
gets you:
~/ootbc/sim/test$ g++ foo.cc
foo.cc: In function `int main()':
foo.cc:10: error: conversion from `foo' to `unsigned int' is ambiguous
foo.cc:5: note: candidates are: foo::operator A()
foo.cc:6: note: foo::operator int()
However, the path foo->int->unsigned int is shorter than the path
foo->A->int->unsigned int, so the former should be chosen.
Ivan
--
Summary: fails to resolve
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27215
[Bug c++/26974] hidden declarations klobber STL
--- Comment #6 from igodard at pacbell dot net 2006-04-20 02:43 --- Don't know what to do then - the actual failing binary comprises 200k lines over a hundred or so modules, all in our internal build environment. The problem pretty clearly had something to do with overloading operator,() and a call inside the STL leaking out to an overload in our code, because it went away when I changed the name of our operator. However, I wasn't able to reduce the case. So I guess close it. Maybe somebody else will get lucky :-) Thanks anyway Ivan -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974
[Bug libstdc++/26974] hidden declarations klobber STL
--- Comment #9 from igodard at pacbell dot net 2006-04-20 08:20 --- I believe it is a bug because my declaration should not be able to hijack the use inside the STL, which should only be seeing the declarations that were visible where the STL function was defined, which did not include any of my code. That is, my operator should not have been on the resolution list for the STL use. Your example has the STL declaration *after* the operator declaration, so the operator is visible. The test case I sent in had the STL first. Also, even if my operator was visible, why was it called when it wants a specReg left operand and didn't get one? The other overloads also all want particular classes as left operands, and the STL case should have been none of them, even if they were visible. You have created a case where the left operand is int but mine declarations all have particular classes as left operand. The operator,() is used here as a metaprogramming device so that a comma-separated list can be eaten and and its elements lightly processed and then saved in a compile-time structure for later processing. The particular situation requires that the form be syntactically a comma-separated list, and some other operator or functional notation would not do. As I recall, the swapping template was because I needed to work around a language restriction whereby operator,() cannot discriminate on the second operand (being by definition defined for left operand and anything). The swapping let me double-dispatch so I could dispatch (in the second invocation) on what had been the right operand but was now the left. But I no longer recall. Is there anything in the Standard that precludes having a templated operator,()? I'd guess that the same bug might be evidenced with operator&& and operator|| as well, because these three have nonstandard (er - uncommon) binding behavior. Hope this helps Ivan -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974
[Bug libstdc++/26974] hidden declarations klobber STL
--- Comment #12 from igodard at pacbell dot net 2006-04-20 09:28 --- I don't think that the problem is in the STL. The STL can be as tricky as it wants, including use of operator,(). It should not be possible for the actual operator,()s I declared to hijack the STL the way that happened, because 1) my declarations were out of scope for the STL code and 2) their signatures did not match the STL call site. This suggests a compiler bug to me, not an STL mis-design. A bug for this operator is not unlikely, because operator,() has unusual semantics that would force non-standard handling within the compiler, and the special code for it is probably not exercised as well as the main operator invocation path. It certinly looks to me like a template that uses operator,() that is defined before a second declaration of that operator but instantiated after the second declaration is seeing the second dec when parsing the body of the instantiation Ivan -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974
[Bug libstdc++/26974] hidden declarations klobber STL
--- Comment #13 from igodard at pacbell dot net 2006-04-20 09:31 --- p.s. Another requirement for the failure probably is that the second declaration has to be a templated operator,() of the form I used i.e. right argument a free template argument. Ivan -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974
[Bug libstdc++/26974] hidden declarations klobber STL
--- Comment #16 from igodard at pacbell dot net 2006-04-20 09:57 --- Well, I don't see how the templating of the STL code can influence whether or not my declarations are in scope or not. BTAIM, my declarations are certainly inappropriate for what the STL is looking for at the call site. Assuming that user declarations are in scope, the only thing I can think of that the STL might do to avoid unwittingly falling into user code in cases like this is to apply boost-style concept checks, which would have immediately eliminated my operators from consideration in this case. However, adding concept checks to a large hunk of wooly code is not trivial. We use them, and our experience is that they are well worth the effort because they expose subtle bugs in our semantics, but they are not free to implement, especially if the code was not originally written with concept-checking in mind. Ivan -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974
[Bug libstdc++/26974] hidden declarations klobber STL
--- Comment #17 from igodard at pacbell dot net 2006-04-20 09:58 --- Yes, you pick up my operator in Wolfgang's test case. But in the original submission the vector code is *before* my operators, which are consequently out of scope for the STL code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974
[Bug libstdc++/26974] hidden declarations klobber STL
--- Comment #25 from igodard at pacbell dot net 2006-04-20 18:40 --- Wolfgang: the whitspace paper is wonderful! Actually, Bjorne explains why operator,() was overloadable in the Rationale. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974
[Bug libstdc++/26974] hidden declarations klobber STL
--- Comment #26 from igodard at pacbell dot net 2006-04-20 19:15 --- Sorry, fat fingered a submit before message was done, please ignore immediately previous message. Corrected full one follows later Ivan -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974
[Bug libstdc++/26974] hidden declarations klobber STL
--- Comment #28 from igodard at pacbell dot net 2006-04-21 04:07 ---
Wolfgang: the whitspace paper is wonderful! Actually, Bjorne explains why
operator,() was overloadable in the Rationale.
I still think that there is a problem here. If you try to overload other
built-in operators in a way that intercepts the normal meaning you get:
"foo1.cc:2: error: 'int operator+(int, int)' must have an argument of class or
enumerated type", so maybe the compiler should have flagged my declarations.
But I think that the actual error is that *in my actual code* every one of my
operator,() declarations had a local class as one or the other or both
argument.
However, the intercepted usage was (int&, &). Consequently
the usage should have failed to identify my declarations and so should not have
intercepted.
Note that #18 simplifies all the arguments to "int", but that was not the
original case. If you change #18 to what actually happened:
#include
namespace mine1
{
template
struct mini_iter
{
mini_iter(U* p)
: _M_current(p) { }
U&
operator*() const
{ return *_M_current; }
mini_iter&
operator++()
{
++_M_current;
return *this;
}
private:
U* _M_current;
};
}
namespace mine2
{
template
_OutputIterator
fill_n(_OutputIterator __first, _Size __n, const _Tp& __value)
{
for (; __n > 0; --__n, ++__first)
*__first = __value;
return __first;
}
template
void f(W* p) { fill_n(mine1::mini_iter(p), 1, *p); }
}
struct bar{ int i;};
template
T operator,(bar i, T t) { std::cerr << "interceptor\n"; return i; }
int main()
{
bar arr[1];
mine2::f(arr);
}
then the declaration does *not* intercept the STL, i.e. it does not fail. Yet i
my actual (more complicated) case it still did.
So we have a test case (#18) that shows the problem but is correct behavior; a
test case (this one) that doesn't fail; and my original code that looks like
the
second but fails like the first, but which I cannot provide to you.
I think there's a bug here, but I agree that we don't have enough to
demonstrate
its existance much less fix it. So let's close the ticket and hope somebody
else
reports it (if bug it is) in something that is small enoughh to manage.
Thanks for your help and the useful discussion.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974
[Bug c++/28311] New: Rejects template invocation with valid class
Something earlier has made "pointer" into a magic word. If you change the name of the class into anything else then the error goes away, and likewise if you compile the file with only the minimal include set that it needs. -- Summary: Rejects template invocation with valid class Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: igodard at pacbell dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28311
[Bug c++/28311] Rejects template invocation with valid class
--- Comment #1 from igodard at pacbell dot net 2006-07-08 10:19 --- Created an attachment (id=11853) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11853&action=view) compiler output -v -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28311
[Bug c++/28311] Rejects template invocation with valid class
--- Comment #2 from igodard at pacbell dot net 2006-07-08 10:21 --- Created an attachment (id=11854) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11854&action=view) save-temps source (compressed) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28311
[Bug c++/28330] New: finds wrong template overload; peculiar diagnostic
The error is an invocation of operator<<(ring&, loadRequest*).
ring defines operator<<(ring&, cacheRequest*), and
cacheRequest is a public base of the actual loadRequest argument. If the right
argument is explicitly cast to cacheRequest* (as shown in the line immediately
before the reported error) the correct operator<< is found and invoked.
However, when the argument is the derived class the compiler finds and invokes
an irrelevant definition of operator<< and then blows up inside it. The
definition it finds is declared by template wideUint and in particular
by wideUint<1>: operator<<(wideUint<1>, const uint32_t&). Somehow it seems to
decide that it can turn a ring& into a wideUint<1>, and then
complains that it can't turn a cacheRequest* into a uint32_t (which is a
typedef
for unsigned int).
It seems to me that the compiler should be able to match the intended operator
by converting to the base class. However, even if it cannot then shouldn't it
just say "no match found for ..." rather than accepting the bogus match and
then
complaining about the conversion to uint32_t?
--
Summary: finds wrong template overload; peculiar diagnostic
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28330
[Bug c++/28330] finds wrong template overload; peculiar diagnostic
--- Comment #1 from igodard at pacbell dot net 2006-07-10 20:11 --- Created an attachment (id=11855) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11855&action=view) compiler output -v -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28330
[Bug c++/28330] finds wrong template overload; peculiar diagnostic
--- Comment #2 from igodard at pacbell dot net 2006-07-10 20:11 --- Created an attachment (id=11856) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11856&action=view) save-temps source (compressed) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28330
[Bug c++/40127] New: Fails to identify template function with default args
This code:
template
voidfoo(int i, void(*f)(T*) = 0, T* a = 0) {}
int main() {
foo(5);
return 0;
}
gets you:
foo.cc: In function int main():
foo.cc:5: error: no matching function for call to foo(int)
So I figured that binding required an actual type, so I tried making it
explicit in the default values:
template
voidfoo(int i, void(*f)(T*) = static_cast(0),
T* a = static_cast(0)) {}
int main() {
foo(5);
return 0;
}
But that gets me the same error.
I'm not sure whether argument types can be bound from default arguments in the
standard, but if they can't then I should get a diagnostic at the declaration
of the template. The actual message is cryptic and unhelpful.
--
Summary: Fails to identify template function with default args
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40127
[Bug c++/40538] New: Compiler crashes
This code:
typedef typeof(1.0df) decimal32_t;
decimal32_t foo(decimal32_t x) { return x; }
int main() {
decimal32_t d;
d = foo(d);
return 0;
}
gets you:
~/ootbc/personal/ivan$ g++ foo.cc
foo.cc:2: internal compiler error: in write_builtin_type, at cp/mangle.c:1852
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
--
Summary: Compiler crashes
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40538
[Bug c++/40538] Compiler crashes while using decimal float point in a function argument
--- Comment #2 from igodard at pacbell dot net 2009-06-24 16:34 --- Probably not the same as 39131, because this ices only if the function is declared. Both the typedef and the data declaration compile OK without the function, whereas 39131 seems to ice without any use at all. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40538
[Bug c++/41050] New: Placement new not seeing base class protected functions
This code:
#include
class foo {
protected:
foo() {}
foo(int) {}
public:
};
class bar : public foo {
public:
bar() : foo() {
new (this) foo(5);
}
};
bar b;
gets you:
~/ootbc/sim$ g++ foo.cc
foo.cc: In constructor bar::bar():
foo.cc:5: error: foo::foo(int) is protected
foo.cc:12: error: within this context
--
Summary: Placement new not seeing base class protected functions
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41050
[Bug c++/41050] Placement new not seeing base class protected functions
--- Comment #2 from igodard at pacbell dot net 2009-08-13 02:47 --- Well, if the call is on foo then surely a foo can call; its own methods, whereas if the call is on bar then a bar should see the protected methods of its base class foo. Either way it should be visible. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41050
[Bug c++/24717] New: spurious error
enum A{a,b,c};
template void f(const U&, int) {}
template void f(const U&, int) {}
template void f(const U&, int) {}
template void f(const U&, int, int) {}
template void f(const U&, int, int) {}
template void f(const U&, int, int) {}
int main() {
bool b;
f(b, 5);
f(b, 5);
f<>(b, 5);
f(b, 5, 10);
f(b, 5, 10);
f<>(b, 5, 10);
}
gets you:
~/ootbc/members/src$ g++ foo.cc
foo.cc: In function `int main()':
foo.cc:11: error: invalid conversion from `int' to `A'
foo.cc:12: error: invalid conversion from `int' to `A'
Ivan
--
Summary: spurious error
Product: gcc
Version: 3.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24717
[Bug c++/24847] New: Instantiates un-called copy constructor
enum A{b,c};
template
struct foo {
explicitfoo(T& t);
explicitfoo(foo);
};
int main() {
int i;
foo v(i);
}
gets you:
~/ootbc/members/src$ g++ foo.cc
foo.cc: In instantiation of `foo':
foo.cc:10: instantiated from here
foo.cc:5: error: invalid constructor; you probably meant `foo
(const foo&)'
The error arises because it thinks I am instantiating "foo(foo)", i.e. a copy constructor that is not taking a const reference argument.
But I'm not; I'm instantiating the plain constructor "foo(int&)".
The second constructor is intended to catch the case: "foo(foo", i.e. to convert an instance of foo with second argument zero to a foo with
any other second argument. It looks like when it is expanding the argument type
of the second constructor (i.e. "foo") that it is not just parsing the
resulting template but also applying the "valid copy constructor?" check for
that type. But as that second constructor is never called by anyone it the
compiler should just syntax check it (valid) and not semantic check it (invalid
for "foo(T, 0, A)" but valid for everything else).
Ivan
--
Summary: Instantiates un-called copy constructor
Product: gcc
Version: 3.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24847
[Bug c++/24847] Instantiates un-called copy constructor
--- Comment #2 from igodard at pacbell dot net 2005-11-15 00:30 --- The original was much more sensible - and much bigger :-) Ivan -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24847
[Bug c++/24889] New: ICE
-- Summary: ICE Product: gcc Version: 3.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: igodard at pacbell dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24889
[Bug c++/24889] ICE
--- Comment #1 from igodard at pacbell dot net 2005-11-16 11:36 --- Created an attachment (id=10249) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10249&action=view) compiler output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24889
[Bug c++/24889] ICE
--- Comment #2 from igodard at pacbell dot net 2005-11-16 11:37 --- Created an attachment (id=10250) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10250&action=view) source code (compressed) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24889
[Bug c++/24939] New: operator< in middle of expression is parsed as template
-- Summary: operator< in middle of expression is parsed as template Product: gcc Version: 3.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: igodard at pacbell dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24939
[Bug c++/24939] operator< in middle of expression is parsed as template
--- Comment #1 from igodard at pacbell dot net 2005-11-19 10:11 --- Created an attachment (id=10290) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10290&action=view) compiler output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24939
[Bug c++/24939] operator< in middle of expression is parsed as template
--- Comment #2 from igodard at pacbell dot net 2005-11-19 10:12 --- Created an attachment (id=10291) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10291&action=view) source code (compressed) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24939
[Bug c++/24983] New: Needs a warning?
struct foo { const void f(); };
void foo::f(){}
gets you:
~/ootbc/members/src$ g++ foo.cc -Wall
foo.cc:2: error: prototype for `void foo::f()' does not match any in class
`foo'
foo.cc:1: error: candidate is: const void foo::f()
foo.cc:2: error: `void foo::f()' and `const void foo::f()' cannot be overloaded
Comeau gives a warning on the declaration and one error (not two) on the
definition.
--
Summary: Needs a warning?
Product: gcc
Version: 3.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24983
[Bug c++/24983] Needs a warning?
--- Comment #3 from igodard at pacbell dot net 2005-11-22 03:45 ---
The 3.0 is the best error, but I like the warning that comeau also gives:
Comeau C/C++ 4.3.3 (Aug 6 2003 15:13:37) for ONLINE_EVALUATION_BETA1
Copyright 1988-2003 Comeau Computing. All rights reserved.
MODE:strict errors C++
"ComeauTest.c", line 1: warning: type qualifier on return type is meaningless
struct foo { const void f(); };
^
"ComeauTest.c", line 2: error: declaration is incompatible with
"const void foo::f()" (declared at line 1)
void foo::f(){}
^
1 error detected in the compilation of "ComeauTest.c".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24983
[Bug c++/24985] New: Line info in diagnostics is very unfriendly
Showing the source line in the diagnostic, with a caret ("^") inder the column
in error, is much friendlier. The best I've ever seen also was graceful when
the error was inside a maco expansion; it showed the position in the token list
of each nested macro, limited to a dozen or so tokens on either side of the
error (or nested macro invoke) in case of long macro bodies. Macros are less
common in C++, but are still used heavily in legacy code (and by legacy
programmers :-) ). Figuring out the expansion by hand, or having to do a -E and
then compile the expanded source, are both pains in the butt.
Ivan
--
Summary: Line info in diagnostics is very unfriendly
Product: gcc
Version: 3.4.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985
[Bug c++/24983] Needs a warning?
--- Comment #5 from igodard at pacbell dot net 2005-11-22 04:05 --- On the contrary, "const void" is a valid type, because the difference between "const void*" and "void*" preserved the typeless constness, which can be important in disambiguating templates. So if "const void" is valid as a pointer target, it is also (syntactically) valid as a function return type. It's just not meaningful, so EDG gives a warning. Note that the gcc diagnostic is the same if the return type is int/const int, so it's nothing to do with "void". Ivan -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24983
[Bug c++/9925] ostrstream (buf, size) << "..." does not work properly
--- Comment #13 from igodard at pacbell dot net 2005-11-30 23:58 --- Two bugs: -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9925
[Bug c++/9925] ostrstream (buf, size) << "..." does not work properly
--- Comment #14 from igodard at pacbell dot net 2005-12-01 00:06 ---
Two bugs:
1) diagnostic, about location of deprecated files
2) constructor as non-const lvalue, where using a constructor as left-operand
of
"<<" produces screwey output.
I'm concerned about the second. I can write:
foo& f = foo();
so the constructor is yielding non-const. I can pass the constructor to a
function:
void bar(foo& f){}; bar(foo());
So why can't I pass a constructor to operator<< and get the correct output?
Emitting a diagnostic for this usage makes no sense to me.
Ivan
Ivan
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9925
[Bug c++/9925] ostrstream (buf, size) << "..." does not work properly
--- Comment #16 from igodard at pacbell dot net 2005-12-01 00:20 --- Sorry Gaby; I fat-fingered a partial post. Is there any way to delete a posting made in error? Ivan -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9925
[Bug c++/25208] New: ICE
-save-temps interacts with -MMD option. Code ices with -MMD and without -save-temps; with -save-temps it complains "too many file names". The attached save-temps output was made with -MMD omitted but otherwise the same command line. -- Summary: ICE Product: gcc Version: 3.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: igodard at pacbell dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25208
[Bug c++/25208] ICE
--- Comment #1 from igodard at pacbell dot net 2005-12-01 18:09 --- Created an attachment (id=10380) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10380&action=view) compiler output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25208
[Bug c++/25208] ICE
--- Comment #2 from igodard at pacbell dot net 2005-12-01 18:10 --- Created an attachment (id=10381) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10381&action=view) source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25208
[Bug c++/25208] ICE
--- Comment #4 from igodard at pacbell dot net 2005-12-01 18:20 --- Here's what the compiler got. ~/ootbc/common/xptsys/test/src$ make test g++ -I/home/ivan/ootbc/common/include -I/home/ivan/ootbc/common/xptsys/include -I/home/ivan/boost/include/boost-1_33 -g -o0 -fmessage-length=80 -Wall -Wextra -MMD -c -o testXwctype.o testXwctype.cc cc1plus: testXwctype.d: No such file or directory cc1plus: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25208
[Bug c++/25208] ICE
--- Comment #6 from igodard at pacbell dot net 2005-12-01 18:25 --- The bug appears to be due to an interaction between -MMD and -Wall -Wextra. If I omit the warnings options then it compiles OK. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25208
[Bug c++/25208] ICE
--- Comment #7 from igodard at pacbell dot net 2005-12-01 18:27 --- Changing to -O0 also clears the ICE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25208
[Bug c++/25209] New: Spurious warning on placement new
-- Summary: Spurious warning on placement new Product: gcc Version: 3.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: igodard at pacbell dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25209
[Bug c++/25209] Spurious warning on placement new
--- Comment #1 from igodard at pacbell dot net 2005-12-01 19:35 --- Created an attachment (id=10382) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10382&action=view) compiler output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25209
[Bug c++/25209] Spurious warning on placement new
--- Comment #2 from igodard at pacbell dot net 2005-12-01 19:36 --- Created an attachment (id=10383) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10383&action=view) source code (compressed) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25209
[Bug preprocessor/25356] New: -MT appends target name, rather than replacing it
The -MT option with -MMD is supposed to substitute for the target in the generated makefile. In most cases it seems to do so. However (using the attached file, which is a rename .ii file), the command: g++ -c -o accum.o -MMD accum.cc produces the makefile: accum.o: accum.cc as expected, but the command: g++ -c -o accum.o -MMD -MTfoo accum.cc produces: foo accum.o: accum.cc instead of the correct: foo: accum.cc -- Summary: -MT appends target name, rather than replacing it Product: gcc Version: 3.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: igodard at pacbell dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25356
[Bug preprocessor/25356] -MT appends target name, rather than replacing it
--- Comment #1 from igodard at pacbell dot net 2005-12-11 18:43 --- Created an attachment (id=10453) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10453&action=view) source code (compressed) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25356
[Bug preprocessor/25356] -MT appends target name, rather than replacing it
--- Comment #3 from igodard at pacbell dot net 2005-12-11 18:57 --- Reported *and patched* two years ago and still not fixed? What gives? Ivan -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25356
[Bug c++/25465] New: Failure to apply constructor
The code passes the result of one function to a return statement in another, where the returned type has a constructor from the argument type. I'm expecting that the constructor will be invoked silently, but get a diagnostic. This appears to be a regression; the code worked in 3.4.0. A simple version of the logic gets no diagnostic, so here's the whole thing. -- Summary: Failure to apply constructor Product: gcc Version: 3.4.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: igodard at pacbell dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25465
[Bug c++/25465] Failure to apply constructor
--- Comment #1 from igodard at pacbell dot net 2005-12-17 20:45 --- Created an attachment (id=10520) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10520&action=view) compiler output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25465
[Bug c++/25465] Failure to apply constructor
--- Comment #2 from igodard at pacbell dot net 2005-12-17 20:45 --- Created an attachment (id=10521) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10521&action=view) source code (compressed) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25465
[Bug c++/25465] Failure to apply constructor
--- Comment #3 from igodard at pacbell dot net 2005-12-17 21:04 --- Never mind- the problem was an incompatibility between iint32_t and ptrdiff_t on a particular platform. Sorry for the spam. -- igodard at pacbell dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25465
[Bug c++/25721] New: fails to recognize cast to "long long"
The code:
void f(int i){}
int main() {
f(long(3));
f(long long(3));
}
gets you
~/ootbc/asm$ g++ foo.cc
foo.cc: In function `int main()':
foo.cc:4: error: expected primary-expression before "long"
--
Summary: fails to recognize cast to "long long"
Product: gcc
Version: 3.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25721
[Bug c++/25748] New: Template instantiated twice
In 3.4.4 under Cygwin (but not under 3.4.0 and Debian GNU/Linux) the following
situation causes "duplicate definition" linker errors:
1) A template class has a static data member:
template struct foo { static T t; };
2) The static member is template-defined at file scope in one module:
template T foo::t = 0;
3) And also defined in the anonymous namespace in another module:
namespace { template T foo::t = 0; }
4) The template itself is instantiated in the namespace in the same module:
namespace { foo f; }
5) and also at file scope in some other module:
foo g;
then the linker produces "multiple definition" messages for the static member.
I am not sure whether collect2 is instantiating the same template twice, or
whether it is instantiating each of the two templates once each but is not
qualifying the name of the anonymous version with the namespace name.
--
Summary: Template instantiated twice
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25748
[Bug c++/23211] [4.0/4.1/4.2 regression] using dec in nested class doesn't import name
--- Comment #12 from igodard at pacbell dot net 2006-08-22 20:28 --- If the "using" is invalid then there should be a diagnostic on line 7 that says so. -- igodard at pacbell dot net changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23211
[Bug c++/23211] using dec in nested class doesn't import name
--- Comment #14 from igodard at pacbell dot net 2006-08-22 20:38 --- Not, it's an error: invalid text is accepted without diagnostic (if the identifier introduced with the "using" is not itself used, then the using statement is invalid but gets no diagnostic). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23211
[Bug c++/29008] New: Fails to accept templated constructor
The code:
class foo {
public:
template
foo(int i) : j(i) {}
template
void bar(int i) { j = i; }
template
static
void baz(int i) {}
int j;
};
int main() {
foo::baz(3);
foo* p; p->bar(3);
new foo(3);
return 0;
}
gets you:
~/ootbc/chips$ g++ foo.cc
foo.cc: In function âint main()â:
foo.cc:8: error: âfooâ is not a template
foo.cc:8: error: no matching function for call to âfoo::foo(int)â
foo.cc:1: note: candidates are: foo::foo(const foo&)
The constructor was declared as a template, and declaring other functions works
OK.
I can believe that parsing a templated constructor for a templated class is
tough and so declaring templated constructors may be illegal. But if it is
illegal to have templated constructors then the error should be flagged at the
attempted declaration of one, rather than this peculiar message at the
invocation site. But it looks to me like the parser hit the "<" in "foo<", saw
that foo was not a template, and gave up before looking to see that the foo
constructor *was* a template.
--
Summary: Fails to accept templated constructor
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29008
[Bug c++/29008] Fails to accept templated constructor
--- Comment #2 from igodard at pacbell dot net 2006-09-10 21:18 --- On further checking, you can have a templated constructor and invoke it - so long as it is fully resolved by the data arguments. You only get the diagnostic when the desired template has to be explicitly qualified. The compiler knows that qualification will be required because none of the function arguments depend on the template argument, so the template argument would have to be supplied explicitly and the declaration could be flagged at once (if this is in fact illegal) I think that the qualified invocation I reported is unambiguous, and certainly works for plain functions. But it's peculiar enough that both you and icc might have made the same mistake. Does the standard explicitly disallow this? If not then it should be accepted. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29008
[Bug c++/29008] Fails to accept templated constructor
--- Comment #4 from igodard at pacbell dot net 2006-10-10 14:17 --- Yes, there IS something you can do about it. The compiler already checks whether a template is resolved by its data arguments (the message is something like "nothing of foo depends on any template argument and so ..."), so this construction can be and should be diagnosed at point of declaration of the constructor. Please reopen and change to a diagnostic issue. If for some reason the error cannot be diagnosed at the constructor, then fix the existing error messoge to something just a *bit* more enlightening :-) Ivan -- igodard at pacbell dot net changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29008
[Bug c++/29427] New: uncallable constructor template should be warned.
class foo {
public:
template
foo(int i) : j(i) {}
template
void bar(int i) { j = i; }
template
static
void baz(int i) {}
int j;
};
int main() {
foo::baz(3);
foo* p; p->bar(3);
new foo(3);
return 0;
}
gets you:
~/ootbc/chips$ g++ foo.cc
foo.cc: In function âint main()â:
foo.cc:8: error: âfooâ is not a template
foo.cc:8: error: no matching function for call to âfoo::foo(int)â
foo.cc:1: note: candidates are: foo::foo(const foo&)
The problem is that the constructor was declared as a template, hence cannot be
called (see bug# 29008). This can be detected at the declaration and a warning
should issue.
OK.
--
Summary: uncallable constructor template should be warned.
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29427
[Bug c++/29008] Fails to accept templated constructor
--- Comment #6 from igodard at pacbell dot net 2006-10-11 05:36 --- Done -- igodard at pacbell dot net changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29008
[Bug c++/29466] New: pointless error on implicit destructor
The code:
#include
#include
class der1 : public std::exception { std::string s;};
int main() {
der1 d;
return 0;
}
gets you:
~/ootbc/common$ g++ foo.cc
foo.cc:3: error: looser throw specifier for 'virtual der1::~der1()'
/usr/include/c++/4.1.0/exception:58: error: overriding 'virtual
std::exception::~exception() throw ()'
I understand that the throw specification (an abortion in general IMO; why it
was ever adopted after the experience with CLU is beyond me) of an overload in
a
derived class but be a subset of the specifications in the overloaded functions
in the base class(es). However in the case of implicitly generated functions,
requiring the user to explicitly say:
~der1() throw() {}
in the derived class is just silly. It also introduces non-portable
implementation dependencies where, as here, the base class is a system class
with unknown and frequently changing throw specification that vary across
hosts.
Ivan
--
Summary: pointless error on implicit destructor
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29466
[Bug c++/29466] pointless error on implicit destructor
--- Comment #2 from igodard at pacbell dot net 2006-10-13 21:49 --- Fair enough w/r/t standard base classes if the standard does indeed define the throw specifications for each class's destructors. But the same dependency appears on any base class, whether standard, 3rd party, or locally written. That dependency is necessary for a destructor you actually write, but it's just silly to require it on the compiler generated ones. Can't the compiler generate the right throw specification? Ivan -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29466
[Bug c++/30623] New: Ignores "using"
template struct foo1 { T* next; };
struct foo2 : public foo1 {};
struct foo3 : public foo1, public foo2 {using foo1::next;};
int main() { foo3 f; f.next = 0; }
gets you:
~$ g++ foo.cc
foo.cc: In function 'int main()':
foo.cc:5: error: request for member 'next' is ambiguous
foo.cc:1: error: candidates are: foo2* foo1::next
foo.cc:1: error: foo3* foo1::next
--
Summary: Ignores "using"
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30623
[Bug c++/30624] New: ignores explicit qualification
template struct foo { T*bar(); };
struct foo1 : public foo, public foo { };
int main() { foo1 f; f.bar(); }
gets you:
~/foo$ g++ foo.cc
foo.cc: In function 'int main()':
foo.cc:3: error: request for member 'bar' is ambiguous
foo.cc:1: error: candidates are: T* foo::bar() [with T = bool*]
foo.cc:1: error: T* foo::bar() [with T = int]
foo.cc:3: error: expected primary-expression before 'int'
foo.cc:3: error: expected `;' before 'int'
--
Summary: ignores explicit qualification
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30624
[Bug c++/30624] ignores explicit qualification
--- Comment #2 from igodard at pacbell dot net 2007-01-28 20:03 --- I thought (according to the ARM) that all functions of a template class were implicitly function templates. Ordinarily the correct instantiation is determined by the object, but when both are inherited then it needs qualification. No? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30624
[Bug c/24577] diagnostic informative note labelled "error"
--- Comment #4 from igodard at pacbell dot net 2007-02-01 01:03 --- My employer does not permit employees to contribute to open source projects due to IP concerns. What's your second choice? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24577
[Bug c++/30624] ignores explicit qualification
--- Comment #4 from igodard at pacbell dot net 2007-02-11 06:04 --- Thank you. Is that obscure or what :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30624
[Bug c++/30836] New: template T[] doesn't catch T[5]
The code:
#include
template struct foo {
static const int i = 0; };
template<>
template struct foo {
static const int i = 1; };
int main() {
int v[5];
std::cerr << foo::i << ":" << foo::i << "\n";
return 0;
}
prints:
0:1
which shows that int[5] is not caught by a T[] specialization. This may be the
standard, but I'm not sure and submit it anyway in case it's a bug.
--
Summary: template T[] doesn't catch T[5]
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30836
[Bug c++/30836] template T[] doesn't catch T[5]
--- Comment #1 from igodard at pacbell dot net 2007-02-17 19:11 ---
p.s. I know I can catch it with:
template<>
template
struct foo {...}
but I though that plain "[]" would catch it too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30836
[Bug c++/30837] New: typeof fails
struct foo{ typedef int bar; };
int main() {
foo f;
typeof(f)::bar i = 0;
return 0;
}
gets you:
~/ootbc/sim/test$ g++ foo.cc
foo.cc: In function 'int main()':
foo.cc:4: error: expected initializer before 'i'
--
Summary: typeof fails
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30837
[Bug c++/30837] typeof fails
--- Comment #2 from igodard at pacbell dot net 2007-02-17 20:50 --- Not fixed for four years? How come? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30837
[Bug c++/30891] New: poor diagnostic
The code:
int main() {
int i = 0;
namespace foo {
int j = 0;
}
return 0;
}
gets you:
~/ootbc/sim$ g++ foo.cc
foo.cc: In function 'int main()':
foo.cc:3: error: expected primary-expression before 'namespace'
foo.cc:3: error: expected `;' before 'namespace'
In contrast, Comeau gives:
Comeau C/C++ 4.3.8 (Aug 19 2006 13:36:48) for ONLINE_EVALUATION_Alpha1
Copyright 1988-2006 Comeau Computing. All rights reserved.
MODE:strict errors C++
"ComeauTest.c", line 3: error: namespace definition is not allowed
namespace foo {
^
"ComeauTest.c", line 2: warning: variable "i" was declared but never referenced
int i = 0;
^
1 error detected in the compilation of "ComeauTest.c".
--
Summary: poor diagnostic
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30891
[Bug c++/31454] New: "protected" protects againt derived class
The code:
struct base {
protected:
virtual void foo() {}
};
struct der : public base {
virtual void foo() { p->foo(); }
base* p;
};
gets you:
~/ootbc/sim/test$ g++ foo.cc
foo.cc: In member function 'virtual void der::foo()':
foo.cc:3: error: 'virtual void base::foo()' is protected
foo.cc:7: error: within this context
--
Summary: "protected" protects againt derived class
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31454
[Bug c++/20682] lost parser
--- Comment #12 from igodard at pacbell dot net 2007-04-10 02:45 --- Funny indeed - that's a scream :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20682
[Bug c++/32888] New: Declared long long double has wrong type
The code:
int main() {
long long double x;
long long double v = 0.0;
}
gets you:
~/ootbc/common$ g++ foo.cc
foo.cc: In function 'int main()':
foo.cc:3: warning: converting to 'long long int' from 'double'
Either "long long double" is illegal and should be flagged on both
declarations, or it is legal and should give you a floating point type not
"long long int".
--
Summary: Declared long long double has wrong type
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32888
[Bug c++/32966] New: bad diagnostic
This:
#include
class system { system() {} };
int foo(system* p) {}
gets you:
~/ootbc/systemspec/build$ g++ foo.cc
foo.cc:4: error: 'p' was not declared in this scope
foo.cc:4: error: expected ',' or ';' before '{' token
The problem is that the function int system(...) is in scope so "system" on
line 4 is not recognized as a type and I guess the compiler is trying to parse
it as an expression (with "*" as the multiply operator). However, there's no
language construction " ()" that I know of.
--
Summary: bad diagnostic
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32966
[Bug c++/32966] bad diagnostic
--- Comment #1 from igodard at pacbell dot net 2007-08-02 05:32 --- Doh! a constructor. Sorry to trouble you. -- igodard at pacbell dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32966
[Bug c++/32190] wrong error recovery on parsing template arguments
--- Comment #9 from igodard at pacbell dot net 2007-08-17 10:37 --- Subject: Re: wrong error recovery on parsing template arguments Begging your pardon, but what's wrong with the one I put in already? Ivan manu at gcc dot gnu dot org wrote: > --- Comment #8 from manu at gcc dot gnu dot org 2007-08-17 10:28 --- > Ivan, would you like to write, test and post the testcase? Once it is approved > I can commit it for you (with your name of course!). > A starting point will be http://gcc.gnu.org/wiki/HowToPrepareATestcase, if you > need further help, please contact me. > > > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32190
[Bug c++/32190] wrong error recovery on parsing template arguments
--- Comment #11 from igodard at pacbell dot net 2007-08-17 17:25 ---
Subject: Re: wrong error recovery on parsing template arguments
Seems impractical. I don't have access to the old versions or mainline,
and don't know what magic to put in the source for your system to use.
I'm sure all that could be fixed, but it's more likely to take more of
someone's time holding my hand than it would be to do it themselves. If
I were doing a hundred of them it would be worth the investment, but for
a one-off it seems hardly useful.
Ivan
manu at gcc dot gnu dot org wrote:
> --- Comment #10 from manu at gcc dot gnu dot org 2007-08-17 10:50 ---
> (In reply to comment #9)
>
>> Subject: Re: wrong error recovery on parsing template arguments
>>
>> Begging your pardon, but what's wrong with the one I put in already?
>>
>>
>
> Nothing is wrong, but to be useful for GCC testsuite, we need to add some
> markers (for example, // { dg-error "template argument 1 is invalid" }) and
> then run an old version and check that the test fails and run it for mainline
> and check that the test passes. Then the patch adding the testcase is
> submitted
> to gcc-patches for review with an appropriate changelog, approved and
> committed. I think it would be a feasible contribution from you, letting more
> advance developers like Paolo to focus on more complex stuff.
>
> But if you don't want to do it just say so, no problem at all.
>
>
>
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32190
[Bug c++/33150] New: frend functions of template get new diagnostic
The following code received no diagnostic in 4.0.1, but on 4.2.1 gets:
~/ootbc/personal/ivan$ g++ foo.cc
foo.cc: In instantiation of 'foo2':
foo.cc:16: instantiated from here
foo.cc:12: error: redefinition of 'void bar(int)'
foo.cc:5: error: 'void bar(int)' previously defined here
Test case:
template
class foo1 {
public:
friend
voidbar(T t) {};
};
template
class foo2 {
public:
friend
voidbar(T t) {};
};
foo1 f1;
foo2 f2;
int main() {}
This may just be a result of tightening up gcc to the standard and the code
always was wrong, but I submit the report in case it is actually a regression
in a rarely-used part of the language.
As I understand it, every function defined in a template is considered to
itself be a template, and hence having a template function that is also a
definition does not count as a duplicate definition no matter how many times
the template is instantiated. However, that seems to no longer apply for
friends declared and defined in templates. Note that both friends refer to the
same function, which is textually declared identically.
Incidentally, declaring the friends "inline" makes no difference to the
diagnostic, whereas it would for a plain function. Possibly the construction
does in fact reflect the standard, but the inline keyword is mishandled? I
leave to the language lawyers whether this is valid or a regression, but in any
case you might want to add this code to your regression suite.
--
Summary: frend functions of template get new diagnostic
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33150
[Bug c++/33156] New: preprocessor precedence of string concatenation backwards?
The code:
#include
#define foo(b) #b
int main() {
std::cerr << foo( "this is a long string "
"broken across lines "
"but constiuting one argument to the macro ") << "\n";
}
produces:
~/ootbc/personal/ivan$ a.out
"this is a long string " "broken across lines " "but constiuting one argument
to the macro "
Shouldn't the embedded quotes be elided?
--
Summary: preprocessor precedence of string concatenation
backwards?
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33156
[Bug c++/33156] preprocessor precedence of string concatenation backwards?
--- Comment #2 from igodard at pacbell dot net 2007-08-23 17:50 --- Whether # is before or after string concatenation, string concatenation should happen *sometime* and doesn't. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33156
[Bug c++/33156] preprocessor precedence of string concatenation backwards?
--- Comment #4 from igodard at pacbell dot net 2007-08-23 19:30 --- Ah! I see. So if string cat is after there's only one string, which does contain embedded quotes as printed. And if string cat were before you couldn't compose a string out of a sequence of macro calls and literals. Makes sense, sorry to bother you. -- igodard at pacbell dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33156
[Bug c++/33176] New: strange diagnostic
The code:
template
bool confirm(T t, int i) { return t == i; }
int main() {
int i = 0, j = 1, k = 2;
if (i == j) && confirm(j, k) ) { i = 2; }
return 0;
}
gets you:
~/ootbc/sim/src$ g++ foo.cc
foo.cc: In function 'int main()':
foo.cc:5: error: expected `;' before '(' token
foo.cc:5: error: label 'confirm' used but not defined
The actual problem is an extra ")" after "i == j", with nary a label anywhere.
--
Summary: strange diagnostic
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33176
[Bug c++/33176] strange diagnostic with "if (a) && b"
--- Comment #2 from igodard at pacbell dot net 2007-08-29 01:02 --- Why does it think a template is a label? I would understand if the code were: lab: if (i == 0) && lab) ... but it knows that "confirm" is a function template at this point, and can't be a future label. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33176
[Bug c++/33176] strange diagnostic with "if (a) && b"
--- Comment #4 from igodard at pacbell dot net 2007-08-29 02:27 --- OK, I see. I doubt I'm the only one who is confused by the report of a mis-used obscure gcc-only "feature" instead of an all-too-common parenthesis error :-) However, if you are emitting diagnostics on the fly then you have little choice but accept the last valid parse, which exposes you to trouble when the user has excess closers. In the compilers I've done we didn't do the diagnostics on the fly, but the diagnostic emitter backed up the parse to previous levels of the bracket tree and reparsed omitting either the opener or the last preceding closer at each level. We took the parse that got farthest, reporting a "probably" excess or missing bracket at the point where it did (or did not) appear. This avoided nearly all of the cascaded errors that gcc produces. Of course, that was in the days when a recompile was half an hour not 20 seconds, and getting the compiler as far as you could was a big help to the programmer :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33176
[Bug c++/11756] ICE's when using typeof in template function parameter type declarations
--- Comment #6 from igodard at pacbell dot net 2007-10-04 01:15 --- Can you spell kludge? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11756
[Bug c++/11756] ICE's when using typeof in template function parameter type declarations
--- Comment #9 from igodard at pacbell dot net 2007-10-04 08:58 --- My apologies, perhaps I'm misunderstanding the jargon. I took the fix comment to mean that typeof in the context reported would produce a diagnostic saying that gcc could not compile the construct, and that this was acceptable because typeof would be acceptable in a typedef and the typedef'd name could be used instead of a literal "typeof". Under that understanding, I called it a kludge. There are any number of contexts in which a type is accepted but a declaration is not, and especially in macro expansions it may be quite inconvenient to force the writer to manually declare the type. It tends to expose the internals of an abstraction when one wants a clean abstract interface that looks and acts like an expression or primary, and could be implemented as such if typeof were accepted in all contexts. If that is not a correct interpretation of "sorry" and "decltype" then I regret pulling your chain, and would like to know what these do mean if you would take the time to explain. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11756
[Bug c++/11756] ICE's when using typeof in template function parameter type declarations
--- Comment #10 from igodard at pacbell dot net 2007-10-04 09:02 --- Sorry, I don't understand "As you can see in the comment threads for some of the other bug reports about typeof in templates". The only other report cited as a duplicate to this one is 11757, and that has no real comments at all. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11756
[Bug c++/11756] ICE's when using typeof in template function parameter type declarations
--- Comment #12 from igodard at pacbell dot net 2007-10-04 14:23 --- Pays to show your ignorance; then you learn something :-) I thank you. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11756
[Bug c++/20019] New: incorrect overflow warning
The code:
#include
static const char lwb = 0x80;
static const char upb = 0x7f;
static const size_t cnt = upb - lwb + 1;
static const char lwba = 0x80;
static const char upba = 0x01;
static const size_t cnta = upba - lwba + 1;
static const char lwbb = 0xff;
static const char upbb = 0x7f;
static const size_t cntb = upbb - lwbb + 1;
static const char lwbc = 0x00;
static const char upbc = 0x7f;
static const size_t cntc = upbc - lwbc + 1;
int main() {
return 0;
}
gets you:
~/ootbc/common/src$ c++ foo.cc
foo.cc:5: warning: integer overflow in expression
foo.cc:9: warning: integer overflow in expression
foo.cc:13: warning: integer overflow in expression
which (as I read the promotion rules) is incorrect. First lwb and upb should be
promoted to int, then subtraction is done, and then the addition. This gives no
overflow. However, it appears that the subtraction is actually being done in
char, not int, because the results actually do overflow 127 on all but the last
case.
Have the promotion rules changed?
Ivan
--
Summary: incorrect overflow warning
Product: gcc
Version: 3.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20019
[Bug c++/20019] incorrect overflow warning
--- Additional Comments From igodard at pacbell dot net 2005-02-17 03:09
---
Turns out that the promotion rules aren't the problem, because you still get the
same message even with *explicit* promotion - the code:
#include
static const char lwb = 0x80;
static const char upb = 0x7f;
static const size_t cnt = int(upb) - int(lwb) + 1;
int main() {
return 0;
}
gets you:
~/ootbc/common/src$ c++ foo.cc
foo.cc:5: warning: integer overflow in expression
which *has* to be wrong regardless of the promotion rules.
Ivan
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20019
[Bug c++/20019] incorrect overflow warning
--- Additional Comments From igodard at pacbell dot net 2005-02-17 03:37
---
WADR, but "char" on my (x86 Linux) machine in fact signed. So I tried:
#include
static const char lwb = 0x80;
static const char upb = 0x7f;
static const int lwbi = lwb;
static const int upbi = upb;
static const size_t cnt = upb - lwb;
static const size_t cnti = upbi - lwbi;
int main() {
return 0;
}
Now I get:
~/ootbc/common/src$ c++ foo.cc
foo.cc:7: warning: integer overflow in expression
foo.cc:8: warning: integer overflow in expression
Surely after I have assigned the chars to ints and done the arithmetic in int
there cannot be an overflow, but I'm still getting a warning. And the result of
the subtraction is positive on a machine with signed chars, so it can't be the
assignment to the size_t.
Reopened - please look again.
Ivan
--
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20019
[Bug c++/20019] incorrect overflow warning
--- Additional Comments From igodard at pacbell dot net 2005-02-17 04:10 --- Please: yes, the int value lwbi arising from the conversion of char(0x80) is the int value 0xff80, i.e. int(-128); you are quite right about that. That value is being *subtracted* from the int value upbi arising from the conversion of char(0x7f) which is the value 0x007f, i.e. 127. If you subtract -128 from 127, i.e (127 - (-128)), the result is 255, a positive number and there is NO overflow. This is signed subtract and it is permitted to subtract a negative from a positive. The result is exact. The result of the subtract is the positive number int(255). That can be converted to size_t (which is unsigned in in this case) also without overflow. Yet there is still a warning message. If the problem here is not clear, please pass this report on to your other colleagues for a second opinion. Thank you. Ivan -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20019
[Bug c++/20021] New: warning behavior depends on textual format of literal constant
in:
#include
static const signed char lwb = 0x80;
static const signed char lwba = -128;
static const signed char upb = 127;
static const size_t cnta = upb - lwba;
static const size_t cnt = upb - lwb;
int main() {
return 0;
}
the two variables lwb and lwba are of identical type and numeric value.
However,
the compiler gives:
~/ootbc/common/src$ g++ foo.cc
foo.cc:7: warning: integer overflow in expression
i.e. only warning on the use of lwb (reordering does not change this). It
should
warn on both or (correctly) neither.
This bug is related to bug #20019
--
Summary: warning behavior depends on textual format of literal
constant
Product: gcc
Version: 3.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20021
[Bug c++/20118] New: spurious error
The code:
templatestruct foo {
static const int i; };
const int foo::i = 5;
int main() { return 0;}
gets you:
~/ootbc/members/src$ g++ foo.cc
foo.cc:4: error: too few template-parameter-lists
foo.cc:4: error: expected `,' or `;' before '=' token
I'm pretty sure that the code is valid, but if it isn't then it's still an
awful
error message.
Ivan
--
Summary: spurious error
Product: gcc
Version: 3.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20118
[Bug c++/20118] spurious error
--- Additional Comments From igodard at pacbell dot net 2005-02-21 09:29 --- Adding "template<>" indeed made the diagnostic go away. Can you change this report to a complaint about the rather unhelpful diagnostic? Ivan -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20118
