--- 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
: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24847
++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24717
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=24657
--- Comment #1 from igodard at pacbell dot net 2005-11-03 15:36 ---
Created an attachment (id=10127)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10127action=view)
compiler output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24657
--- Comment #2 from igodard at pacbell dot net 2005-11-03 15:36 ---
Created an attachment (id=10128)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10128action=view)
source code (compressed)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24657
--- Comment #3 from igodard at pacbell dot net 2005-11-03 16:43 ---
Here's a reduced case:
templateint x struct B {};
struct A {
templateint i
A(const Bi b) : j(i) {}
voidi() {}
int j;
};
int main() {
B5 b;
A a(b);
}
which gets you
at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24628
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=24630
org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24591
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24592
--- Comment #1 from igodard at pacbell dot net 2005-10-31 10:32 ---
Sorry, screwed up the explanation. Should be:
The access to inc is s-inc(). s is a FT*, which after parameter
substitution is a Gint*. b1T is a public base of GT, which after
substitution means that b1int is a public
--- Comment #3 from igodard at pacbell dot net 2005-10-31 22:48 ---
Ys of course; sorry :-(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24592
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
--
Summary: Fails to identify template using local classes
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
--- Comment #2 from igodard at pacbell dot net 2005-10-30 21:29 ---
I don't get it. The argument is Aint::iterator, which surely depends on
AE::iterator (with E taken as int). The problem also arises in the
simpler case:
#include iostream
templatetypename E
class A {
public:
class
--- Comment #3 from igodard at pacbell dot net 2005-10-31 00:53 ---
Here's an example that shows that AE::iterator depends on E:
templatetypename E
class A {
public:
class iterator {
E dummy;
};
iterator iter;
};
int main( int argc, char *argv
--- Comment #5 from igodard at pacbell dot net 2005-10-31 01:08 ---
Well, the actual argument type is wholely resolved at point of call. And the
formal parameter type is valid at the point where sort is defined. It will
recognize Aint as an AE, it will recognize Aint* as an AE
at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24567
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=24577
--
Summary: ICE
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http
--- Comment #1 from igodard at pacbell dot net 2005-10-26 08:17 ---
Created an attachment (id=10059)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10059action=view)
compiler output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24535
--- Comment #2 from igodard at pacbell dot net 2005-10-26 08:20 ---
Created an attachment (id=10060)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10060action=view)
source code (compressed)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24535
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24492
: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24499
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24375
';' token
--
Summary: bad diagnostic
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
--- Comment #2 from igodard at pacbell dot net 2005-10-12 19:23 ---
Well, how about:
foo.cc: In function `void bar()':
foo.cc:2: error: template argument `T' uses local type `bar()::X'
foo.cc:2: error: trying to instantiate `templateclass T struct foo'
foo.cc:2: error: invalid type
++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24291
--
Summary: ICE
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
http
--- Comment #1 from igodard at pacbell dot net 2005-10-08 19:54 ---
Created an attachment (id=9939)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9939action=view)
compiler output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24278
--- Comment #2 from igodard at pacbell dot net 2005-10-08 19:55 ---
Created an attachment (id=9940)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9940action=view)
source code (compressed)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24278
: 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24280
--- Comment #1 from igodard at pacbell dot net 2005-10-09 00:00 ---
Created an attachment (id=9943)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9943action=view)
compiler output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24280
--- Comment #2 from igodard at pacbell dot net 2005-10-09 00:01 ---
Created an attachment (id=9944)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9944action=view)
source code (compressed)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24280
--- Comment #3 from igodard at pacbell dot net 2005-10-09 00:37 ---
OK, I see what is going on now. Here's a simple case:
#includestring
class syntaxNoError : public std::exception {
std::string message;
};
which gets you:
scanner.cc:2: error: looser throw specifier
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
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
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
--- Additional Comments From igodard at pacbell dot net 2005-09-20 12:43
---
Bummer. I wonder why? I suppose the workaround is an inline helper function
wrapping the constructor, plus a couple of calls on the copy constructor...
Ivan
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Additional Comments From igodard at pacbell dot net 2005-09-20 18:36
---
So a constructor counts as a type for deduction purposes? I'd always thought of
it as a function, albeit a peculiar kind of one. It's the parentheses I suppose
:-)
Ivan
--
http://gcc.gnu.org/bugzilla
--- Additional Comments From igodard at pacbell dot net 2005-09-20 20:35
---
Oh yeah - I've fallen into (and reported) that one before. How quickly we
forget!
You know, a perhaps you meant 'this-foo'? in the diagnostic ould cut down on
the redundant reports you guys get :-)
Ivan
--- Additional Comments From igodard at pacbell dot net 2005-09-20 20:38
---
Many thanks for taking the time for the lengthy explanation. It is deeply
appreciated.
Ivan
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23977
--- Additional Comments From igodard at pacbell dot net 2005-09-12 12:48
---
Neil -
Backwards no doubt! I'm sure that any programmer who has studied the formal
syntax of C++ will have it correctly forwards. For the remaining 99.95% of
programmers (who like me tend to use parameter
be :-)
--
Summary: Is this right?
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
--- Additional Comments From igodard at pacbell dot net 2005-09-11 15:44
---
Nah, tried:
struct foo {
templatebool b
voidf();
templatetypename T, bool b
voidg();
};
template
voidfoo::ftrue() {}
template
voidfoo::ffalse() {}
templatetypename T, bool
--- Additional Comments From igodard at pacbell dot net 2005-09-12 01:14
---
Well, you may think it's clear but I am am counter-example :-) Perhaps
template parameter (in the message) is a formal term in the language syntax
specification (who but acompiler maven would know
--- Additional Comments From igodard at pacbell dot net 2005-09-12 03:17
---
In the case you give I count one template argument specificatiob, and two
template parameters.
As for a better message, how about: A template definition must have same number
of formal template specifications
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=23807
--- Additional Comments From igodard at pacbell dot net 2005-09-10 14:33
---
Simpler test case:
#includeiostream
int main () {
unsigned short us = 0;
unsigned int res = ~us;
std::cerr res: 0x std::hex res , us: 0x us \n;
return 0;
}
gets you:
~/ootbc
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=23749
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
CC: gcc-bugs at gcc dot gnu dot org
http
--- Additional Comments From igodard at pacbell dot net 2005-08-08 02:42
---
See also #23281
Should this and other reports about diagnostic quality be treated as
enhancement requests? I suppose tht it depends on what you consider
correctness. If that means conforming to standard
at pacbell dot net
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23263
--- Additional Comments From igodard at pacbell dot net 2005-08-06 20:40
---
Reopened as a complaint about the diagnostic. The naive (or even reasonably
sophisticated) user cannot figure out illegal partial specialization from that
message.
Comeau gives:
ComeauTest.c, line 7: error
: 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=23211
according to Comeau anyway)
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
--- Additional Comments From igodard at pacbell dot net 2005-07-24 00:22
---
Yes, the code is invalid; there should be a diagnostic. The problem is that you
get the wrong diagnostic. Please read the original report.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21413
--- Additional Comments From igodard at pacbell dot net 2005-07-24 00:26
---
Speaking as a mere user, I find the ICC diagnostic more informative.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20118
--- Additional Comments From igodard at pacbell dot net 2005-07-24 00:29
---
Sorry, I'll try to be more original in my PRs :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20308
--- Additional Comments From igodard at pacbell dot net 2005-07-24 01:03
---
I poked at it a little but the simplifications make the problem go away.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21909
: igodard at pacbell dot net
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22590
--- Additional Comments From igodard at pacbell dot net 2005-07-21 14:31
---
Created an attachment (id=9319)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9319action=view)
compiler output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22590
--- Additional Comments From igodard at pacbell dot net 2005-07-21 14:32
---
Created an attachment (id=9320)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9320action=view)
source code (compressed)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22590
--- Additional Comments From igodard at pacbell dot net 2005-07-21 14:49
---
The actual problem is a missing # on a #include statement, so the code is
invalid. But the error is reported not where that occurs but deep inside the
next included file. So this report is actually a complaint
--- Additional Comments From igodard at pacbell dot net 2005-07-22 01:25
---
Then Andrew's test case is not showing the problem. In the original, although
the message is the same as Andrew's, the line/file reference is deep inside a
system include that contains the first program text
--- Additional Comments From igodard at pacbell dot net 2005-07-22 05:50
---
# 1 opClock.cc
# 1 /home/ivan/ootbc/members/src//
# 1 built-in
# 1 command line
# 1 opClock.cc
include core.hh
# 1 ../../members/include/opClock.hh 1
# 1 /mnt/export/local/bin/../lib/gcc/i686-pc-linux-gnu/3.4.0
: igodard at pacbell dot net
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22361
--
Summary: Fails to link
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
--- Additional Comments From igodard at pacbell dot net 2005-07-08 18:49
---
Er - aren't the known to fail and known to work reversed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22361
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
--- Additional Comments From igodard at pacbell dot net 2005-06-30 21:48
---
Gabriel: no, it also happens with any pointer:
struct node { float*operator float*(); };
gets you:
foo.cc:1: error: operator `float*' declared to return `float'
And similarly for other types
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
'
--
Summary: multiple diagnostics
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
: 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=21907
--
Summary: Even poorer diagnostic
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
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=21909
--- Additional Comments From igodard at pacbell dot net 2005-06-04 10:32
---
Created an attachment (id=9027)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9027action=view)
compiler output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21909
--- Additional Comments From igodard at pacbell dot net 2005-06-04 10:32
---
Created an attachment (id=9028)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9028action=view)
source code (compressed)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21909
--- Additional Comments From igodard at pacbell dot net 2005-06-04 10:37
---
Sorry, my bad
--
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
--- Additional Comments From igodard at pacbell dot net 2005-06-04 10:42
---
Sorry, not my bad after all :-( I need some sleep.
Ivan
--
What|Removed |Added
--- Additional Comments From igodard at pacbell dot net 2005-06-04 18:55
---
So I did :-) So where does the `der2::der2(const void**)' come from?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21908
: 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=21917
--- Additional Comments From igodard at pacbell dot net 2005-06-04 22:22
---
p.s. I suppose that if there is only a single path to the virtual base then
explicit construction is meaningful and the explicit construction in the der*
classes is not wrong. But in the constructor for top
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
--- Additional Comments From igodard at pacbell dot net 2005-05-26 06:27
---
Created an attachment (id=8969)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8969action=view)
compiler output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21763
--- Additional Comments From igodard at pacbell dot net 2005-05-26 06:28
---
Created an attachment (id=8970)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8970action=view)
source code (compressed)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21763
--- Additional Comments From igodard at pacbell dot net 2005-05-23 18:10
---
Looks like it to me too, and I easily could have fallen into the same hole
twice
because it comes from a use of a shared library. Does a single fix make both go
away?
--
http://gcc.gnu.org/bugzilla
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=21727
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=21731
--
Summary: Syntax 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
--- Additional Comments From igodard at pacbell dot net 2005-05-22 20:24
---
The test doesn't #include any posix functions. The problem seems to be a partial
hide of the name, because a simple declaration works:
int index;
int main (){
index = 0;
}
gives no errors. Interestingly
to linker
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
--- Additional Comments From igodard at pacbell dot net 2005-05-21 10:01
---
Created an attachment (id=8942)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8942action=view)
compiler output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21696
--- Additional Comments From igodard at pacbell dot net 2005-05-21 10:02
---
Created an attachment (id=8943)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8943action=view)
linker symbols as reported by nm
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21696
--- Additional Comments From igodard at pacbell dot net 2005-05-21 10:02
---
Created an attachment (id=8944)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8944action=view)
source code (compressed)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21696
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
--
Summary: segv after 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
--- Additional Comments From igodard at pacbell dot net 2005-05-19 20:49
---
Created an attachment (id=8929)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8929action=view)
compiler output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21670
--- Additional Comments From igodard at pacbell dot net 2005-05-19 20:50
---
Created an attachment (id=8930)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8930action=view)
source code (compressed)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21670
201 - 300 of 392 matches
Mail list logo
