--- 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
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
--- 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 ope
--- 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
--- 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 hap
--- 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
--- 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
--- 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/bug
--- 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
--- 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
--- 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
alid 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_
--- 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
--- 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
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
--- 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
--- 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
ion: 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
ty: 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
--- 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
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
; 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
an
--
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
--- 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
--
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
--- 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
--- 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
org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24939
--- 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
--- 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
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
--- 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
dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985
--- 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 template
--- 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
--- 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 ab
--- 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
oduct: 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
--- 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
--- 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
--- 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-leng
--- 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
--- 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
at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25209
--- 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
--- 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
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
--- 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
--- 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
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25465
--- 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
--- 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
--- 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
;
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
h 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: igodar
--- 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
--- 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).
--
htt
ct: 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
--- 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
--- 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 a
mponent: 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
--- 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
+
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29466
--- 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 part
ponent: 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
ersion: 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
--- 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
--- 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
--- 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
us: 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
--- 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
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
--- 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
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
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31454
--- 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
ormal
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
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
--- 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
--- 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
--- 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
u dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33150
oduct: 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
--- 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 an
atus: 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
--- 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 futu
--- 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 t
--- 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 #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 thi
--- 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 t
--- 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
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
--- 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 =
--- 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 = u
--- 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
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
signedTo: 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
--- 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
1 - 100 of 393 matches
Mail list logo
