* G++ Bug List
@ 1998-10-23 4:36 Martin von Loewis
1998-10-25 4:08 ` Gerald Pfeifer
0 siblings, 1 reply; 6+ messages in thread
From: Martin von Loewis @ 1998-10-23 4:36 UTC (permalink / raw)
To: egcs
I started a list of bugs that are frequently reported, yet unlikely to
get fixed anytime soon. I'd like to see this document in
htdocs/c++bugs.html, and referenced from the FAQ.
Please comment. In particular, if I missed 'important' bugs, let me
know.
Regards,
Martin
<html>
<head>
<title>EGCS g++ Frequently Detected Bugs</title>
</head>
<body>
<h1>G++ FDB List</h1>
This is the list of bugs in g++ that are reported very often, yet not
fixed. While it is certainly better to fix bugs instead of documenting
them, this document might save people the effort of writing a bug
report when the bug is already well-known.
<p>There are many reasons why reported bugs don't get fix. It might be
difficult to fix, or fixing it might break compatibility. Often,
reports get a low priority when there is a simple work-around. In
particular, bugs caused by invalid C++ code have a simple work-around:
Fix the code.
<h2>G++ allows to access private structs</h2>
egcs-2.92.15 incorrectly accepts code like
<pre>
struct X{
private:
struct Y{};
};
X::Y z;
</pre>
Since Y is a private member of Y, the definition of z should be
rejected, but isn't. For other members of classes (functions and
data), access control is implemented.
<h2>export not implemented</h2>
As of egcs-2.92.15, the export keyword is not implemented. It allows
to move definitions of templates out of header files; exported
templates can be instantiated without a visible definition.
<h2>Using declarations in classes do not work</h2>
The Annotated Reference Manual (ARM) defines an access declaration for
cases like
<pre>
struct X{
protected:
int i;
};
class Y: private X{
public:
X::i;
};
void f()
{
Y y;
y.i=4;
}
</pre>
Even though X::i is protected, it is redeclared public in Y.
<p>Standard C++ extends this notion and aligns it with using
declarations available in namespaces. In Standard C++, the following
code is also valid
<pre>
struct X{
protected:
int i(bool);
};
class Y: private X{
public:
int i(int);
using X::i;
};
void f()
{
Y y;
y.i(true);
}
</pre>
A using declaration not only redeclares access, it also allows to
merge functions from the base class into the derived class, which is
convenient for overloading. In Standard C++, the ARM-style notation is
equivalent to using declarations.
<p>egcs-2.92.15 rejects this code. It treats using declarations in the
same way as ARM-style access declarations.
<h2>C++ Library not compliant</h2>
In Standard C++, the programmer can use a considerable run-time
library, including the STL (Standard Template Library), iostreams
for single-byte and wide characters, localization features, and
others.
<p>Many of the standard library features are not implemented in egcs
1.1. Others, such as iostreams, are supported, but not in a
complianted way (e.g. ostream is not basic_ostream<char>, and not
declared in std::).
<p>Work is underway to complete a <a href="libstdc++-v3.html">new C++
library</a> which will provide all the functionality in a compliant
way.
</body>
</html>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: G++ Bug List
1998-10-23 4:36 G++ Bug List Martin von Loewis
@ 1998-10-25 4:08 ` Gerald Pfeifer
0 siblings, 0 replies; 6+ messages in thread
From: Gerald Pfeifer @ 1998-10-25 4:08 UTC (permalink / raw)
To: Martin von Loewis; +Cc: egcs
On Fri, 23 Oct 1998, Martin von Loewis wrote:
> I started a list of bugs that are frequently reported, yet unlikely to
> get fixed anytime soon. I'd like to see this document in
> htdocs/c++bugs.html, and referenced from the FAQ.
Me, too. :-) Consider it approved, modulo the remarks below.
Please also add a link at the end of the "How to report bugs" FAQ Entry.
Perhaps we might want to rename that to "How to report bugs / Frequently
reported bugs".
> <title>EGCS g++ Frequently Detected Bugs</title>
I suggest to use "C++" or "C++ frontend" instead of "g++" to avoid
confusion. AFAIS, g++ is not that well-known a ``concept'' and many
users are actually invoking it as `gcc` or `c++`.
> <h1>G++ FDB List</h1>
Please refrain from introducing additional three-letter words. ;-)
Finally, I recommend to always add _explicit_ notes about the latest
release and its behavior. How about replacing "egcs-2.92.15" by "egcs 1.1
and egcs-2.92..." in various places?
Thanks for that effort!
Gerald
--
Gerald Pfeifer (Jerry) Vienna University of Technology
pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: G++ Bug List
1998-10-24 5:16 Ryszard Kabatek
@ 1998-10-25 13:53 ` Martin von Loewis
0 siblings, 0 replies; 6+ messages in thread
From: Martin von Loewis @ 1998-10-25 13:53 UTC (permalink / raw)
To: kabatek; +Cc: egcs
> - Egcs-1.1 does not throw std::bad_exception when appropriate.
I personally cannot confirm this bug. Egcs 1.1 does throw
bad_exception on sparc-sun-solaris, when appropriate.
> - For an overriding virtual function egcs allows
> a less restrictive exception specification.
This is not a frequently reported bug.
Regards,
Martin
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: G++ Bug List
[not found] <Pine.LNX.3.96.981024133916.3594A-100000.cygnus.egcs@rumcajs.chemie.uni-halle.de>
@ 1998-10-24 18:22 ` Jason Merrill
0 siblings, 0 replies; 6+ messages in thread
From: Jason Merrill @ 1998-10-24 18:22 UTC (permalink / raw)
To: kabatek, egcs
>>>>> Ryszard Kabatek <rysio@rumcajs.chemie.uni-halle.de> writes:
> - Egcs-1.1 does not throw std::bad_exception when appropriate.
> - For an overriding virtual function egcs allows
> a less restrictive exception specification.
These two are just bugs, and should be simple to fix. The ones in Martin's
list are of a larger scale.
> - Rounding problem on intel processors:
> double func(double x) {return x + 0.01;}
> double x = func(100.0);
> if (x - func(100.0) < DBL_EPSILON) --> false
This should go into a list of frequently reported non-bugs (along with
instructions on how to get the results people want).
Jason
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: G++ Bug List
@ 1998-10-24 5:16 Ryszard Kabatek
1998-10-25 13:53 ` Martin von Loewis
0 siblings, 1 reply; 6+ messages in thread
From: Ryszard Kabatek @ 1998-10-24 5:16 UTC (permalink / raw)
To: egcs
- Egcs-1.1 does not throw std::bad_exception when appropriate.
- For an overriding virtual function egcs allows
a less restrictive exception specification.
- Rounding problem on intel processors:
double func(double x) {return x + 0.01;}
double x = func(100.0);
if (x - func(100.0) < DBL_EPSILON) --> false
Ryszard Kabatek
--
Martin-Luther University Halle-Wittenberg
Department of Physical Chemistry
Geusaer Str. 88, 06217 Merseburg, Germany
Tel. +49 3461 46 2487 Fax. +49 3461 46 2129
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: G++ Bug List
[not found] <199810231101.MAA00699.cygnus.egcs@mira.isdn.cs.tu-berlin.de>
@ 1998-10-24 3:17 ` Jason Merrill
0 siblings, 0 replies; 6+ messages in thread
From: Jason Merrill @ 1998-10-24 3:17 UTC (permalink / raw)
To: Martin von Loewis, egcs
Looks good, thanks. We might want to include frequently reported non-bugs,
too.
Jason
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~1998-10-25 13:53 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1998-10-23 4:36 G++ Bug List Martin von Loewis
1998-10-25 4:08 ` Gerald Pfeifer
[not found] <199810231101.MAA00699.cygnus.egcs@mira.isdn.cs.tu-berlin.de>
1998-10-24 3:17 ` Jason Merrill
1998-10-24 5:16 Ryszard Kabatek
1998-10-25 13:53 ` Martin von Loewis
[not found] <Pine.LNX.3.96.981024133916.3594A-100000.cygnus.egcs@rumcajs.chemie.uni-halle.de>
1998-10-24 18:22 ` Jason Merrill
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).