Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
GCC build triplet: sparc-sun-solaris2.9
GCC host trip
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27527
--- Comment #1 from sebor at roguewave dot com 2006-05-10 01:07 ---
Here's a test case designed to exhaustively exercise all cases mentioned in
14.8.2, p2. Hope it helps.
$ cat ~/tmp/t.cpp && (c=1; while [ $c -lt 15 ]; do printf "%s: " "$c"; gcc
-DCA
--- Comment #2 from sebor at roguewave dot com 2006-05-12 16:27 ---
EDG points out to me that both the original test case and the one from comment
#1 are ambiguous because only the declaration of the signature of the function
(and thus only the declaration of its return type and its
--- Comment #3 from sebor at roguewave dot com 2006-05-12 16:30 ---
Created an attachment (id=11446)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11446&action=view)
Corrected test program exercising SFINAE.
After modifying the test program from comment #1 to correc
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
GCC build triplet: sparc-sun-solaris2.9
GCC host triplet: sparc-sun-solaris2.9
GCC target tr
--- Comment #2 from sebor at roguewave dot com 2006-05-16 17:35 ---
I'm not sure what you find wrong with my "attitude" but yes, I did send Sun a
note about it pointing them to this problem report.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27629
--- Comment #4 from sebor at roguewave dot com 2006-05-17 15:12 ---
Here's the verbose output from the compiler driver:
$ gcc -v t.c
Using built-in specs.
Target: sparc-sun-solaris2.9
Configured with: /build/sebor/gcc-4.1.0/configure --enable-languages=c,c++
--prefix=/usr/loca
--- Comment #5 from sebor at roguewave dot com 2006-05-17 17:43 ---
I'm told that the fault is due to a known problem in the Sun libc:
6372620 printstack() segfaults when called from static function
It this doesn't provide sufficient detail to work around the bug in gcc
(as
--- Comment #7 from sebor at roguewave dot com 2006-05-17 18:34 ---
Maybe it's one of the runtime library functions that's static (maybe _start?).
The diff between the two .s files is empty.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27629
--- Comment #9 from sebor at roguewave dot com 2006-05-17 21:35 ---
Here's what I learned from Sun:
Here is the test case from that bug report:
[Makefile]
main: main.o libshibby.so
gcc -L. -lshibby -Wl,-R. -o main main.o
main.o: main.c
gcc -c -o main.o m
address of a function template
specialization
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor
bor/tmp/t.cpp,
line 21
Abort (core dumped)
--
Summary: std::operator<<(ostream&, string) sets badbit instead of
failbit on failure
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priorit
ception with -m64 -static on
ppc/linux
Product: gcc
Version: 3.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at rogu
--- Comment #2 from sebor at roguewave dot com 2006-07-11 21:42 ---
Libc says it's 2.3.3 (20040412).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28351
--- Comment #2 from sebor at roguewave dot com 2006-07-13 19:07 ---
If it is in our (Rogue Wave) current code, could you please let us know where
so we can look into fixing it? (It's doesn't matter whther gcc does the right
thing here or not, our code should be portable
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38126
t: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38476
: inefficient code on trivial try/catch statement
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave
--- Comment #3 from sebor at roguewave dot com 2008-12-30 20:08 ---
Quoting [lib.istream], p2:
Both [formatted and unformatted] input functions are described as if
they obtain (or extract) input characters by calling rdbuf()->sbumpc()
or rdbuf()->sgetc(). They may use
struct S { T foo (); };
>>> template T S::foo () { return T (); };
>>> template struct S;
>>> extern template struct S;
>>> int main () { return S().foo (); }
--
Summary: extern template declaration accepted after explicit
instantiation
Pr
std::streamsize main()xsgetn(char*, std::streamsize): Assertion `!"xsgetn should not be
called"' failed.
Aborted
--
Summary: istream::read() calls streambuf::xsgetn()
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: nor
--- Comment #2 from sebor at roguewave dot com 2009-01-04 22:37 ---
Some additional background on the problem: it's likely that the gcc binary
used to reproduce the problem on Red Hat Enterprise Linux AS release 4 has
been configured and built on SUSE Linux Enterprise Server 10. S
--- Comment #12 from sebor at roguewave dot com 2009-01-09 16:57 ---
(In reply to comment #3)
> Created an attachment (id=17044)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17044&action=view) [edit]
As others have mentioned, the codecvt facet in your test case is b
-c t.cpp
4.3.1
t.cpp: In function 'void foo(size_t)':
t.cpp:7: warning: format '%lu' expects type 'long unsigned int', but argument 3
has type 'size_t'
$
--
Summary: missing -Wformat warning on const char format string
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
GCC build triplet: all
GCC host triplet: all
GCC target tri
ncorrect signature
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
GCC build
--- Comment #7 from sebor at roguewave dot com 2005-12-08 00:08 ---
FWIW, I think Andrew makes a good point in comment #1. The algorithms really
should return the iterator, otherwise the caller may not be able to find out
the state of the iterator after the algorithm returns (e.g., when
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
GCC build triplet: all
GCC host triplet: all
GCC target triplet: all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25306
--- Comment #10 from sebor at roguewave dot com 2005-12-08 15:51 ---
No, I don't. The standard is clear and most of us seem to think it's "by
design." Rather I am suggesting is that we might want to discuss with the whole
LWG changing the return type as an enhan
--- Comment #15 from sebor at roguewave dot com 2005-12-08 16:27 ---
(In reply to comment #11)
Okay, I see your concern.
Well, IMO, your signatures are better than those required by the standard so if
you care about 100% compliance you (or Paolo -- and I promise not to beat him
--- Comment #3 from sebor at roguewave dot com 2006-01-10 16:14 ---
(In reply to comment #2)
I'm not sure what you mean. Could you show what one of the algorithms would
look like with a Size that's not convertible to an integer?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25306
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28656
--- Comment #3 from sebor at roguewave dot com 2006-09-11 21:25 ---
This sounds like it might be related to
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#309. If so, and if
this case is important to you (the submitter) it might be helpful to give the
committee a little
--- Comment #5 from sebor at roguewave dot com 2006-09-12 00:16 ---
The reason why I think library issue 309 may be relevant is because while the
arithmetic extraction operator>>() is a formatted input function (and thus
subject to 27.6.1.1, p4, and required to begin by construc
--- Comment #5 from sebor at roguewave dot com 2006-09-12 16:16 ---
(In reply to comment #4)
Shouldn't the output be:
6
azerty123
9
--
sebor at roguewave dot com changed:
What|Removed |
--- Comment #8 from sebor at roguewave dot com 2006-09-12 17:24 ---
No, I'm not sure. I got the output with our implementation but the latest
working paper doesn't seem to support it (I had misread the text in 27.7.1.2,
p2 to require that pptr() == epptr() uncoditionally r
--- Comment #10 from sebor at roguewave dot com 2006-09-12 17:44 ---
I think you're right. Even my own issue 562 is clear on this. I must have a bug
in the implementation of the resolution of the issue.
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#562
--
g array
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
GCC build triplet: all
GCC host
--- Comment #2 from sebor at roguewave dot com 2006-09-22 16:57 ---
Yes, but 5.3.5, p1 says "The operand shall have a pointer type, or a class
type having a single conversion function (12.3.2) to a pointer type." and
not "shall be convertible to a pointer type." No
--- Comment #3 from sebor at roguewave dot com 2006-09-26 16:31 ---
The response I got from EDG is that the expression is well-formed because of
5, p8. They do agree that issuing a warning would be useful and opened an
enhancement request.
FWIW, I think it should be ill-formed with
--- Comment #5 from sebor at roguewave dot com 2006-09-26 18:56 ---
You mean something like: if (is_pointer (p)) delete p;
I suppose that could happen but why should it be any different than other
non-sensical but lexically valid constructs with undefined behavior that
require a
--- Comment #7 from sebor at roguewave dot com 2006-09-26 21:43 ---
You're right, those weren't the best examples, but I still think they
illustrate the point. The code in them is plain ill-formed even though
it never gets executed, because it just doesn't make sense. de
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
GCC build triplet: all
GCC host triplet: all
GCC target triplet: all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29273
--- Comment #8 from sebor at roguewave dot com 2006-09-28 16:16 ---
The EDG guys don't think this is worth spending the committee's time on so I
won't
be proposing any change to the standard. Issuing just a warning rather than an
error is good enough for me.
Also, I open
--- Comment #5 from sebor at roguewave dot com 2006-10-02 19:19 ---
Interesting. The vanilla EDG front end rejects it as expected. I wonder why
Intel
accepts it when neither EDG nor gcc does. Maybe we should open a bug with them
to
find out ;-)
--
http://gcc.gnu.org/bugzilla
--- Comment #3 from sebor at roguewave dot com 2006-10-13 21:02 ---
You're right, I missed that. I confess I don't quite understand the rationale
for this in the standard and I'm not aware of any plaform that causes problems
for such calls but based on Doug Gwyn's
portedBy: sebor at roguewave dot com
GCC build triplet: all
GCC host triplet: all
GCC target triplet: all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29465
--- Comment #4 from sebor at roguewave dot com 2006-10-13 21:09 ---
I opened bug 29465 with a request for the new warning.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28656
n, max, et al
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
GCC build triplet: sparc-sun-solaris
GC
ct: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30811
exception specification in
__PRETTY_FUNCTION__
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at
--- Comment #2 from sebor at roguewave dot com 2007-02-15 21:29 ---
No, I'm not aware of any such paper. AFAIK, neither __FUNCTION__ nor
__PRETTY_FUNCTION__ is specified by either C or C++, or proposed for inclusion
either of them (I could be wrong). They're gcc extensions, a
--- Comment #4 from sebor at roguewave dot com 2007-02-15 23:06 ---
The wording proposed in N1970 for the C++ __func__ indentifier reads:
-1- The identifier __func__ shall be implicitly declared by the translator
as if, immediately following the opening brace of each function
--- Comment #6 from sebor at roguewave dot com 2007-03-09 18:25 ---
(In reply to comment #5)
Good point! I hadn't thought of that. Since that option is out and __FUNCTION__
should simply behave identically to __func__ and be disallowed in global or
namespace scope function arg
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31158
ion: 4.1.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31176
--- Comment #3 from sebor at roguewave dot com 2007-03-14 19:04 ---
(In reply to comment #1)
> Interesting. Do the attributes apply to derived classes automatically?
I would say no.
>
[...]
> Is D also allowed to reorder members a and b? even with an explicit
> _
--- Comment #4 from sebor at roguewave dot com 2007-03-14 19:05 ---
(In reply to comment #2)
> Note actually some compilers actually do this even without an attribute. This
> is related to the art hack.
Out of curiosity, which compiler does it? And what's the art hack?
--- Comment #6 from sebor at roguewave dot com 2007-03-15 19:54 ---
(In reply to comment #5)
I've checked all three but none of them seems to achieve an optimal layout in a
modified template case. Let me attach my test program.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31176
--- Comment #7 from sebor at roguewave dot com 2007-03-15 19:55 ---
Created an attachment (id=13212)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13212&action=view)
test case for data member reordering
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31176
--- Comment #8 from sebor at roguewave dot com 2007-03-15 23:51 ---
Some additional comments on the request precipitated by a discussion with the
implementers of another compiler:
The rationale for allowing the attribute on individual members is to provide
fine-grained control over
--- Comment #7 from sebor at roguewave dot com 2007-07-15 00:03 ---
In cases when the compiler can figure out that the cast is unnecessary it would
be even better if it would optimize it away than to complain to the user about
not being able to do it.
--
http://gcc.gnu.org/bugzilla
--- Comment #5 from sebor at roguewave dot com 2007-08-05 00:31 ---
There are third party tools that track these types of problems. Some of them
have started to make their way into compilers. For example, the HP static
analysis tool called Code Adviser is integrated into the HP aCC
--- Comment #3 from sebor at roguewave dot com 2007-09-12 03:47 ---
You remember correctly :)
To avoid zeroing it out use 'new buffer' w/o the parentheses.
--
sebor at roguewave dot com changed:
What|Removed
--- Comment #2 from sebor at roguewave dot com 2007-09-12 03:56 ---
(In reply to comment #1)
> This is not a bug, 0 will be pasted as the same size as an int which means it
> will most likely not be passed as the same size as a NULL pointer.
I don't know about "most lik
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33786
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: all
GCC host triplet: all
GCC target triplet: all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20644
--- Additional Comments From sebor at roguewave dot com 2005-03-26 01:08
---
I can imagine that it may not be straightforward to fix but I can't think of a
reason why a warning could ever be useful in this case (i.e., when the code is
provably safe). I could of course be mi
g &va_list to va_list*
Product: gcc
Version: 3.2.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
C
--- Additional Comments From sebor at roguewave dot com 2005-04-11 17:33
---
(In reply to comment #1)
Right. I understand why it doesn't compile and how to work around it (with gcc
at least). What I'm still not convinced of is that it's not a strict conformance
bug. The
--- Additional Comments From sebor at roguewave dot com 2005-04-11 17:51
---
Yes, I read that comment but I still don't see anything in the standard the
footnote is in conflict with and I don't see it on the WG14 DR list(*). If the
footnote is bogus and va_list can't
--- Additional Comments From sebor at roguewave dot com 2005-04-13 22:06
---
(In reply to comment #5)
Thanks for the pointer. Let me try again to explain why I object to the
footnote:
The footnote assumes that the reader will make the extrapolation that 1) since
va_list is an object
signedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37062
rity: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37063
pure function with side-effects
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gc
--- Comment #1 from sebor at roguewave dot com 2008-08-08 19:47 ---
Similarly, functions declared with the const attribute such as f1() in the
test case below that violate the compiler's assumptions should be diagnosed:
$ cat -n t.C && g++ -c -O2 -Wall -W t.C
1
warning on throw statement
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.
--- Comment #2 from sebor at roguewave dot com 2008-08-09 22:51 ---
I'm not sure what you're trying to say but it sure looks like a bug to me.
How else is one supposed to throw an exception without triggering this
warning?
Btw., the argument of a throw expression can throw, a
--- Comment #4 from sebor at roguewave dot com 2008-08-10 02:23 ---
My gcc is yesterday's build:
gcc version 4.4.0 20080808 (experimental) (GCC)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37070
--- Comment #2 from sebor at roguewave dot com 2008-08-27 16:48 ---
Is this by any chance related to bug 24511?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37256
FIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37404
t: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37405
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
GCC build triplet: x86_64-redhat-linux
GCC host triplet: x86_64-redhat-linux
GCC target triplet: x86_64-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35176
--- Comment #3 from sebor at roguewave dot com 2008-02-13 15:46 ---
I used setrlimit() only to emulate low disk space conditions. The same
"problem"
occurs in a pure C++ program (i.e., one that makes no POSIX or other non-C++
calls) when it really does run out of disk space.
--- Comment #5 from sebor at roguewave dot com 2008-02-13 16:37 ---
I understand that POSIX requires the signal but I'm not sure I see what that
has to do with filebuf. C++ specifies that filebuf member functions behave
"as if" by calling the C stdio functions.
See 27
--- Comment #7 from sebor at roguewave dot com 2008-02-13 18:15 ---
I see I should have checked the actual stdio behavior instead of relying on
the standard. Recent Linux and Solaris both do, in fact, generate SIGXFSZ out
of C stdio. AIX 5.3 does not, and neither does HP-UX 11.23
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35711
igned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39159
--- Comment #4 from sebor at roguewave dot com 2009-02-12 16:49 ---
(In reply to comment #0)
I'm not sure I understand your rationale or I agree that this is a bug. IIUC,
string(1, CHAR_MAX) indicates that groups may be of arbitrary length, which
includes "123,456" This
--- Comment #1 from sebor at roguewave dot com 2009-02-12 17:02 ---
In addition, as the test case below shows, the warning is issued inconsistently
between classes and functions, suggesting that the instance of the warning on
the class declaration on line 2 might be a bug rather than a
--- Comment #17 from sebor at roguewave dot com 2009-02-14 21:21 ---
Created an attachment (id=17300)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17300&action=view)
Unified money_get and num_get test case and results.
Attached is a unified test case with test results on
--- Comment #18 from sebor at roguewave dot com 2009-02-14 21:41 ---
I was too hasty -- the attached test case is buggy: it's missing a seek to
the beginning of the stream after the first extraction, making the results
for the num_get part meaningless.
(In reply to comme
--- Comment #20 from sebor at roguewave dot com 2009-02-14 21:58 ---
Created an attachment (id=17301)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17301&action=view)
Corrected unified demo.
Attached a corrected unified demo with assertions removed and with output on
--- Comment #5 from sebor at roguewave dot com 2009-02-17 15:48 ---
(In reply to comment #0)
> I can't think of a scenario where one would want to write x.f() over X::f()
> when f() is static. I'd like a warning for this so I can catch with -Werror.
FWIW, I've
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39219
--- Comment #4 from sebor at roguewave dot com 2009-02-17 21:00 ---
Thanks for looking into so quickly!
In addition to the missing warnings mentioned in the initial report I would
expect a warning for each of the references to e below (i.e., on lines 3, 9,
and 15), analogously to those
--- Comment #6 from sebor at roguewave dot com 2009-02-18 16:50 ---
(In reply to comment #5)
> Should attribute work on enum constants?
Not sure if this is a question for me but IMO, it should. I would expect
individual enumerators to be more heavily referenced than their ty
E on ill-formed sizeof() in variadic
template
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave d
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39639
1 - 100 of 182 matches
Mail list logo
