Ok, point taken, and that is very reasonable.
What might be useful is a short article on the gcc web page for users
describing general guidelines regarding which features are generally
highly tested and supported and which are not.
This way you can add many experimental feautres and users will know to
check the website to understand the limitations of the available features.
That could be better than having constant warnings for people who
actually want to use the experimental feautres, or even worse no warning
and people using functionality that gcc insiders know is dodgy and the
users don't know.
Ivan
Joe Buck wrote:
On Tue, Apr 18, 2006 at 06:14:27AM +0000, Ivan Novick wrote:
Is it documented anywhere which gcc features should not be trusted or
are known to have faults?
The only source of "known to have faults" is the bug database.
However, in any complex piece of software with many options, it simply
isn't possible to test all combinations of those options. If there are
twenty binary flags, that's over a million combinations. If you use a
combination of flags that no gcc user in the word has ever chosen before,
you might find a bug that no user has ever found before.
Flags that almost everyone uses are the most heavily tested. -O/-O1, -O2,
and -O3 are very heavily used; -Os is starting to get to that point. A
few of the -f flags are used commonly enough to be considered tested, but
if you're conservative I would warn that the use of *any* -f flags
increase the risk that you'll find a compiler bug, simply because
relatively few users are testing them heavily (you Gentoo folk are out
there on the edge).
But to answer your first question: gcc should not be trusted, nor should
any other compiler. You need to thoroughly test executable code, so that
if the compiler does go wrong, you will find the problem. Now, gcc is
good enough so that problems found in executables are overwhelmingly due
to errors in the source code, not errors in the compiler. But there
are no guarantees.
