Re: GCC 3.0 Branch: Guidelines

[Colm Smyth <Colm dot Smyth at Sun dot COM>]

Hi Joe,

Thanks for your informed and thought-provoking response; I'd like to
try to clarify what I'm really trying to do.

I realise that this must look like I'm trying to achieve some
Sun-specific hidden agenda, but I'm really looking for no more and no
less than what I've said in this and my previous mail.

I use proprietary and open-source tools, I contribute to
proprietary and open-source projects, I write code and I
use a compiler every day of the week. Everything I'm looking
for from gcc, I'm looking for from Sun's compilers. If I had
a way to ask the same things from other vendor's compilers,
I would do it on principle because I think that silently supporting
non-standard features is a sneaky trap (there are some examples
I could quote, but I'm sure you can think of at least a few).

>From: Joe Buck <jbuck@synopsys.COM>
>Subject: Re: GCC 3.0 Branch: Guidelines
>To: Colm.Smyth@sun.com
>Cc: gcc@gcc.gnu.org, mark@codesourcery.com
>MIME-Version: 1.0
>Content-Transfer-Encoding: 7bit
>
>Colm Smyth writes:
>> - gcc only produces a warning when you assign to a const variable
>> - gcc only produces a warning when you return a value from a void function
>
>I don't see any reason not to turn these warnings into errors.
>For the second one, I can't even see any reason why anyone would
>ever not want the condition diagnosed.  So this should be fixed.
>
>> My second category of issues basically applies to all of the gcc extensions
>> that aren't in ISO C (and to a lesser extent, some features that have
>> come into ISO C, but perhaps not in the same way as they are implemented
>> in gcc).
>
>There are two flavors of ISO C, 89 vs 99.  Existing gcc releases
>precede the finalization of the new standard, so it cannot be
>expected to conform.  But many of the changes between the two
>standards are the adoption by ISO of some of the more popular
>GNU extensions.  If those extensions weren't there before, ISO
>might not now have them.  So gcc need not apologize.

This isn't about seeking any apologies for gcc; gcc is a great
compiler on an unreal number of platforms and has consistently
stayed on the leading edge in terms of features and robustness
(at least in the major releases, and when it didn't it was no
worse than some releases of proprietary products).

It's just that it would be great if developers using gcc could
get support from the compiler to tell them when they are using
an unportable feature.


>> Some widely diverging examples of this kind of problem include:
>> 
>> - support of __FUNCTION__ instead of ISO C __func__ 
>
>We can't abandon __FUNCTION__, it is far older than __func__.
>
>> - macro definitions can include strings with newlines
>
>I don't know to what extent this is a problem.  There has been
>argument over strings with newlines; they are nice for asm but
>perhaps not so useful otherwise.

The only problem is that most compilers don't support it, so
they barf on code like

#define mymacro "this and that
  and this is on the next line"
  
Again this is really about letting compilers take advantage of
gcc features but choose to know when the feature is unportable
by getting specific warnings (that they could search for by
looking for "ISO" or "ANSI").

>> - difficulty of distinguishing lint-type warnings from ISO/ANSI C warnings
>>   (no specific compiler flag for standards-compliance and no search string
>>   that can be used to filter ISO/ANSI-related warnings if -pedantic is
>>   used).
>
>Are you asking for a flag that says "be completely silent about all
>conforming programs"?  I'm not sure that that would really promote code
>quality if no one removed lint-type problems from their code.  And GCC (at
>least in snapshots) does have specific flags for checking conformance to
>different standards (e.g. c89 vs c99).

I'm only asking for a flag that would specifically highlight use of gcc
extensions that aren't in ISO C; it would be great if you could
choose which version of the standard you are choosing to conform with
but even if the standard was only C99 that would be a big step in helping
developers who choose to write portable code.

>> - common use of gcc-specific feature-test macros (e.g. use of __GNUC__ to
>>   decide if inline keyword is supported).
>
>In pre-c99 this was necessary.  You could ask the autoconf folks to come
>up with better tests, but it'll take years before all the C programmers
>learn about this.  "long long" is a similar story; it's supported by
>many compilers but not all coders know this.

I agree it's not going to be quick or easy, but if we had a GNU or
GCC document that suggested some "standard" compiler feature-test
macros, then the larger open-source projects would certainly consider
adopting it and many proprietary projects could (and do) learn a lot from 
GNU standards and open-source development in general. By the by,
from my perspective there are increasingly fewer major software companies
that don't have some employees who contribute regularly on company-time to 
open-source projects (a few of those projects aren't seen as open-source,
but many vendors, including Sun, are significant contributors to
bread-and-butter software like X11).

>> Basically my concerns are due to the tremendous success of open-source
>> and specifically the gcc compiler suite; because gcc is so ubiquitous,
>> it would be great if it helped to support developers who want to stay
>> compliant with the language standards or who want to create source that
>> can be compiled with platform compilers.
>
>"platform compilers"?  Do you mean "the compiler Sun sells?"

The one that Sun sells, the one that Microsoft sells, the ones that
Borland sells, the ones that other UNIX vendors sell; there
are always reasons to use a specific compiler. Often gcc is an
excellent choice, but not always. I think there is an interest among
open-source developers in getting the widest possible adoption and
encouraging contributions from everyone and anyone; if a developer
is using gcc themselves but wants to make their code available to
people who would sometimes prefer to use another compiler, they
could use some help from the compiler to tell them when they are
writing unportable code. I think this help is most needed with a
compiler like gcc that *is* on the leading edge in terms of features;
it's very easy to use one of these features without knowing it and
suddenly to lose the ability to write portable code when you have to.

>While gcc can be improved in this regard, I could assemble a list of
>similar length of issues with Sun's C++ -- many nonstandard coding
>practices are accepted by that compiler.  In my company, we have lots of
>code developed on that platform that doesn't easily port.  It's a tough
>job to get right.

You're right and I'm banging heads with some of Sun's compiler folks right
now to say that we can't do this; we have to help developers write
portable code. If you have some issues with Sun's compilers where it
supports specific extensions without offering a flag to provide
clear warnings about portability issues, let me know and I'll be
only to happy to raise it with them. I don't think I could in all
honesty ask the maintainers of gcc to do anything that I wouldn't
be prepared to ask Sun's compiler engineers to do.

>> As a developer, I'd like to do
>> this because sometimes the platform-compiler can produce debug information
>> that my platform debugger uses to provide better debugging support
>> (multi-threading and runtime memory checking).
>
>For Suns, I'd like to have the union of the features provided by dbx and
>gdb.  dbx handles multithreading and has a few other nice features, but
>has many more restrictions on method calls than gdb does.  For visual
>debugging, I like DDD better than the proprietary Sun stuff.

DDD is great, I use it myself on both dbx and gdb.

>> If I were a release
>> engineer, I might do it because a platform-specific compiler can 
>> extract the best out of the CPU.
>
>The gcc team's effort would be better spent improving performance, than on
>encouraging people to move to proprietary compilers.  And proprietary
>compilers (especially for C++) have very large numbers of bugs.  I've
>spent years of work making large amounts of C++ code work around all the
>compiler bugs in Sun C++, HP aCC, MSVC, and yes, g++.  Release engineers
>supporting multiple platforms would be better off just dealing with the
>bugs in one C++ front end, rather than many, even if there is a small
>performance penalty (performance differences are less than SPEC scores
>suggest because of benchmark-specific tuning by proprietary compiler
>developers).

I'm not interested in encouraging anyone to move to proprietary
compilers; I believe in the right tool for the right job.

As an aside, every compiler (even gcc) has bugs, though I would acknowledge
that gcc probably has fewer bugs in most releases. C++ has had a long
and rich history of buggy implementations and every new feature was
essentially unusable unless you knew that you were always going to
use one specific compiler and could live with that compilers benefits
and limitations).

I'm just focussing on C and the fact that there are often reasons to
use a different compiler; I mentioned performance and because I
see real application benchmarks, I see that sometimes a compiler other
than gcc does a slightly better job on a specific CPU. I agree that
given the additional complexity of C++ and it's history of different bugs
on different compilers, sometimes knowing one devil is better than
half-knowing one per platform. Performance is not the only reason.

I don't want to lose sight of my basic goal, which is how can I get
the compiler to tell me when I'm writing code that uses a compiler-specific
feature and I think that many other developers could use that information.
You mentioned that Sun's compiler's also silently supports unportable
features, I think that's just as unacceptable and must also be fixed;
I'm doing what I can to champion that goal at Sun and I'll share my
progress with you if it's of interest. I'd like to work with anyone
who's interested in doing the same for gcc.

Colm.