"Experimental" features in releases

[Ivan Novick]

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.
> 
> 
>