https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17314
--- Comment #24 from Ivan Godard ---
OP here.
Yes, no one would *intentionally* try to derive from a virtual private. But one
could - and I did - derive a class with. It took no little wild geese chasing
from the diagnostic to find that a
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: igodard at pacbell dot net
Target Milestone: ---
This source:
extern int si; extern unsigned ui;
int main(int argc, char** argv) {
return argc==0?si:ui; }
compiled with this command
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12672
--- Comment #11 from Ivan Godard ---
OP here; better late than never :-)
IANALL, but the portions of the standard cited by Jonathan all refer to
argument evaluation, while the problem here is in the result type. Why is the
result even being
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12672
--- Comment #6 from Ivan Godard ---
Twelve years and counting? :-)
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: igodard at pacbell dot net
This code:
#includecstddef
class A {
public:
int i;
};
int main() {
int x = __builtin_offsetof(A, i);
int j = std::offsetof(A, i);
}
gets you this:
s6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54545
Bug #: 54545
Summary: diagnostic overflow
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53068
--- Comment #4 from Ivan Godard igodard at pacbell dot net 2012-04-22
06:08:28 UTC ---
Looking a little further at this, I don't think we can use init_array at all,
even if it ran in reverse order.
Consider TUs in a .a library, where some
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53068
--- Comment #6 from Ivan Godard igodard at pacbell dot net 2012-04-22
07:46:20 UTC ---
Yes, but. Order is not defined, but order dependencies are inescapable in C++
which has a tendency to invoke constructors where you least expect them - when
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
Ivan Godard igodard at pacbell dot net changed:
What|Removed |Added
CC||igodard
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #98 from Ivan Godard igodard at pacbell dot net 2012-04-22
17:44:24 UTC ---
It's OK if you reverse the default order - make it sideways if it gets a faster
Firefox. We can cope.
It's OK is you dump ctors for init_array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #101 from Ivan Godard igodard at pacbell dot net 2012-04-22
19:35:08 UTC ---
Well, it's easy to say that it's the other guy's problem, but it isn't. You are
assuming that the linker is always gnu ld; for big shops with multi-platform
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #103 from Ivan Godard igodard at pacbell dot net 2012-04-22
21:52:40 UTC ---
I may be just displaying my ignorance, but my understanding is that order under
init_array is governed by order of pointers within the array itself
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53068
Bug #: 53068
Summary: collect2 breaks link order control
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53068
--- Comment #3 from Ivan Godard igodard at pacbell dot net 2012-04-22
04:49:46 UTC ---
Wow - this will break a lot of big users - we are far from the only ones who
find priorities unusable.
BTAIM, it appears that our choice is to use an option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52321
--- Comment #2 from Ivan Godard igodard at pacbell dot net 2012-02-21
15:30:42 UTC ---
Somewhere there's an attept to coerce a to b that sees the source is a class
and the target is a class and tries to see if the source is derived from
target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52321
--- Comment #4 from Ivan Godard igodard at pacbell dot net 2012-02-21
17:38:30 UTC ---
Define an enum of reasons with success first, flop the sense of the test so
that false means coercion was OK (grep to find all calls and put a ! in front
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52321
Bug #: 52321
Summary: poor diagnostic of invalid cast
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52288
Bug #: 52288
Summary: Trouble with operator?: and lambdas
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52288
--- Comment #3 from Ivan Godard igodard at pacbell dot net 2012-02-17
00:00:48 UTC ---
As lambdas get used more you will get this kind of report a lot. I suggest you
head off a lot of nuisance by having any lambda/lambda type comparisons emit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52212
--- Comment #6 from Ivan Godard igodard at pacbell dot net 2012-02-12
17:14:34 UTC ---
I'll put in a report to clang. One of you guys is right- are you well enough
connected to jointly figure out who it is?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52212
Bug #: 52212
Summary: friend declaration doesn't see previous friend of same
function
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52212
--- Comment #1 from Ivan Godard igodard at pacbell dot net 2012-02-12
07:46:10 UTC ---
p.s. FWIW, clang accepts this and Comeau does not.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42356
--- Comment #12 from Ivan Godard igodard at pacbell dot net 2011-10-22
15:52:54 UTC ---
Manual said:
g++ could also specify which ones are viable candidates, and which ones are not
even viable, and for the ones not viable, explain why.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42356
--- Comment #16 from Ivan Godard igodard at pacbell dot net 2011-10-23
01:28:48 UTC ---
(In reply to comment #15)
(In reply to comment #12)
Manual said:
g++ could also specify which ones are viable candidates, and which ones
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49729
Summary: diagnostic cascade
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36231
--- Comment #16 from Ivan Godard igodard at pacbell dot net 2011-04-20
21:06:39 UTC ---
Would it be possible to wrap each #include of a C file in a namespace,
adjusting the references from the C++ library accordingly? The namespace to be
used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36231
--- Comment #19 from Ivan Godard igodard at pacbell dot net 2011-04-21
00:22:08 UTC ---
I notice that Bugzilla is carrying this as enhancement and unconfirmed.
Seems odd :-)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45963
Summary: inconsistent and poor array initialization diagnostic
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
--- Comment #14 from igodard at pacbell dot net 2010-08-31 02:20 ---
Reopened, based on following communication from Clark Nelson
+
In one interpretation, it means the rvalue evaluation of b and f
--- Comment #10 from igodard at pacbell dot net 2010-08-29 18:00 ---
I agree that Nelson's proposal (in particular 5.17p1 -assignment and compound
assignment operators) defines the ordering as:
- evaluation of operands
- assignment
- evaluation of assignment expression i.e. evaluating
--- Comment #11 from igodard at pacbell dot net 2010-08-29 18:24 ---
Note to Nelson, for the record here:
There is a disagreement about C++ sequence semantics happening in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45437
The gist is the following code:
bool b = false;
bool f
--- Comment #6 from igodard at pacbell dot net 2010-08-28 17:49 ---
Thank you. Don't know about C, but this is C++ in which operators are function.
BTW, even in C the standard goes to some lengths in places to make things that
look like functions but have odd semantics be defined
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=45437
--- Comment #2 from igodard at pacbell dot net 2010-08-28 04:11 ---
No it must be evaluated as if it was:
operator|=(a, f())
Exactly. The arguments (a and f()) must be evaluated to their parameter types
(bool and bool) before the call to |=. There *is* a sequence point; it's
--- Comment #4 from igodard at pacbell dot net 2010-08-28 04:32 ---
Yes, I understand that the comma is not a sequence point, and a may be
evaluated (to a) in any order w/r/t f() (to bool). But it is not legal to
evaluate a to bool before the call of |=, because |= takes empbool/emp
++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45064
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=44579
--- Comment #4 from igodard at pacbell dot net 2010-06-06 00:50 ---
Wow - a blast from the past! FWIW, I still think that the anonymous is
confusing. That 4.6 drops one of the messages is an improvement though...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20313
--- Comment #9 from igodard at pacbell dot net 2010-04-30 14:24 ---
This is not a fault of POSIX, because I'm *not* using POSIX. I'm using C++
ostream. Because I'm not using POSIX I expect to be able to declare (for
example) int open = 0; without a problem - open is not a reserved key
--- Comment #3 from igodard at pacbell dot net 2010-04-29 23:35 ---
Reopened, because comment#2 mistakes the problem. I don't want to get anything
included into namespace std. However, I also do not want tyo get C header names
imported into my application's global space merely because I
--- Comment #6 from igodard at pacbell dot net 2010-04-30 05:28 ---
I guess I'm still not being clear. I'm not using *any* of those names; I'm not
using C; I'm not using POSIX. I'm only using ostream, which is a plain old C++
library, but when I include ostream I'm getting C library
--- Comment #3 from igodard at pacbell dot net 2010-03-08 15:37 ---
You sure that you want to ban this? Looks like you'll just have to unban it
again. From http://en.wikipedia.org/wiki/Decltype:
In December 2008, a concern was raised to the committee by Jaakko Järvi over
the inability
--
Summary: typeof doesn't act like a type in ::
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot
--- Comment #15 from igodard at pacbell dot net 2010-01-12 01:12 ---
Should I submit a second report so there is one for accepts invalid and a
different one for diagnostic quality?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41970
--- Comment #9 from igodard at pacbell dot net 2010-01-10 22:23 ---
Comeau gives this diagnostic:
ComeauTest.c, line 1: error: use of a type with no linkage to declare a
variable
with linkage
enum {a, b, c} A = a;
^
This message give the true nature
--- Comment #5 from igodard at pacbell dot net 2009-12-14 14:58 ---
There's no question that there was an error here. The report is on the
diagnostic. I'm sorry if I hadn't made that clear.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42356
--- Comment #2 from igodard at pacbell dot net 2009-12-14 04:51 ---
Well, I see several issues with the diagnostics.
1) The call is not ambiguous, because if it were (only) ambiguous then removing
the base baz would disambiguate. Instead the case without baz gets you:
s3:~/ootbc
dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42356
--- Comment #5 from igodard at pacbell dot net 2009-12-08 15:20 ---
Both proposals befriend more than the minimum actually needed by program
semantics. The former befriends any member of freeListbar, baz, not just foo;
the latter any member of any freeList at all. In addition
: 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=42328
--- Comment #3 from igodard at pacbell dot net 2009-12-08 02:16 ---
I stand corrected about Comeau - I missed the error and only noticed the
warning. Regardless, there must be some way to solve this problem:
templatetypename T, typename U
class freeList {
public:
void foo
: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42242
--- Comment #9 from igodard at pacbell dot net 2009-12-01 19:02 ---
FWIW, I think it is a design error in the standard. The resize function seems
to be designed from an assumption that the vector type T is POD. The second
argument should not be a T, it should be a constructor, so any
--- Comment #11 from igodard at pacbell dot net 2009-12-01 19:26 ---
Subject: Re: vector::resize could be split up into two
different functions
We await r-value references with baited breath :-)
chris at bubblescope dot net wrote:
--- Comment #10 from chris at bubblescope dot
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
--- 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
--- 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
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
--- Comment #5 from igodard at pacbell dot net 2009-04-16 17:02 ---
Wow! Six years and counting! This might be my oldest outstanding bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12672
--- Comment #2 from igodard at pacbell dot net 2008-10-13 15:18 ---
Deprecated or not, shouldn't it work up until when it is actually removed?
And forgive me, but I don't understand the relevance of DR 109 here. Perhaps
you meant some other number?
Lastly, if this is not a compiler
--- Comment #4 from igodard at pacbell dot net 2008-10-13 16:06 ---
Ah - I was looking at language DR109, not library DR109. However, the correct
DR says the committee approved the example reported here (and adds the fix) so
gcc appears to be in error to fail it. However
--- Comment #6 from igodard at pacbell dot net 2008-10-13 17:01 ---
Then I'm hopelessly confused. It's clear that my report and the example in
DR109 are the same problem. You say: The example in DR 109 does *not* compile
if the additional operator() are not added and does when
--- Comment #8 from igodard at pacbell dot net 2008-10-13 17:55 ---
OK, thanks for your time.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37811
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37811
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
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=36961
--- Comment #1 from igodard at pacbell dot net 2008-07-29 00:52 ---
Oops - sorry, posted wrong test case:
enum A{a};
enum B{b};
enum C{c};
enum D{d};
class bottom {};
templatetypename E class attr {
public: E v;
operator E() { return v;}
};
templatetemplatetypename class node
--- Comment #3 from igodard at pacbell dot net 2008-07-29 00:54 ---
p.s. Comeau likes the (correct, second) test case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36961
--- Comment #5 from igodard at pacbell dot net 2008-07-29 01:07 ---
Please confirm that it is an error with your associates.
First, Comeau likes it.
Second, other template functions have no trouble identifying a template base
class given a derived class. What is different about
--- Comment #6 from igodard at pacbell dot net 2008-07-29 02:32 ---
FWIW, Visual Studio has been reported to me as accepting the test case too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36961
--- Comment #1 from igodard at pacbell dot net 2008-07-23 06:59 ---
Second the motion - I too have had to tie myself in knots (generating source
code that is then compiled...) to get the effect of this extension.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33877
: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36626
class argument
Product: gcc
Version: 4.3.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
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36231
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=36163
--- Comment #2 from igodard at pacbell dot net 2008-05-06 21:39 ---
Isn't ::foo the using'd class from name? If not, how does one befriend a class
that comes from a using?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36163
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=35228
--- Comment #7 from igodard at pacbell dot net 2008-01-25 22:35 ---
Yes, it has always been understood that this code is invalid. The report is
about the quality of the diagnostic that was given, not whether a diagnostic
should be given. The diagnostics (three of them for one error
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
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
--- 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
--- 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
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33150
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
--- 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
--- 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
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
--- 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
++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32888
--- Comment #4 from igodard at pacbell dot net 2007-06-04 14:27 ---
Well, in my ignorance, I'd say that the symptoms are consistent with scanning
forward to the next , regardless of what gets scanned over, such an
unmatched or statement-lists.
--
http://gcc.gnu.org/bugzilla
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=32190
--- Comment #2 from igodard at pacbell dot net 2007-06-02 23:40 ---
Either way, it is reporting on the first line after the point of actual error
that contains a use of a template. The space between error and report is thus
arbitrarily large and may cross files, and the flagged line has
--- 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
at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31454
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
1 - 100 of 392 matches
Mail list logo
