Re: -fobey-inline (was Re: gcc and inlining)

[dewar at gnat dot com (Robert Dewar)]

>  It's a road that no
> sane developer would want to go down. Why don't you spend the effort to
> get the standard amended if a particular case is important?

Because the standard cannot cover everything. For example, there is no way that
the formal standard can legitimately talk about inlining *requiring* inlining,
because semantically it should be neutral whether inlining takes place, and we
are always talking about an as-if semantic model in a standard. Standards always
get into trouble when they start saying things that are semantic rubbish (my
perspective here is from the point of view of working on language standards
since the early 70's [when I worked on the Algol-68 defining documents].)

Let's take something as simple as defining the semantics of malloc and free. Well
you know that an implementation that completely ignores free is completely
unacceptable, but it is extremely hard to define *whY* that is unacceptable in
a standard. We deliberately leave many things unsaid since they are simply out
of scope. This does not mean they are unimportant, just that they operate at
a different level of abstraction from the standard.

As for sane developers going down this path, I have been in the commercial compiler
field for some 30 years now, and for every compiler I have worked on, there was a
difficult-to-deal with area of things that people expect to work but which are not
mandated by the standard. Yes, they are tough to deal with, but as far as I can tell
they have not driven me insane :-)

> How about C aliasing issues? Those are carefully outlined in the
> standard, and yet we've had perhaps thousands of emails on that subject.

I would say that any C compiler which does not provide a way of bypassing the
aliasing rules (i.e. stopping the optimizer from taking advantage of them, needs
some careful definition), is a poor implementation of C from a pragmatic point
of view. There is far too much legacy "junk" code that in practice cannot be
modified to behave. Obviously GCC itself agrees with this point of view :-)

In the case of Realia COBOL we faced an even more difficult problem which is that
there were bugs in the IBM Mainframe COBOL implementation which 

a) were definitely inconsistent with the standard
b) which were depended on by a lot of legacy code.

We found that it was in practice more essential to provide IBM compatibility than
it was to provide standard compatibility (we did as I remember provide an option
for the behavior there). It was a marginal case, but even marginal things often
show up in the real world of very large legacy programs.

A standard is simply a tool for helping to ensure commonality between what all
compilers implement and what all users expect of these compilers, but it is 
over-simplistic to think that it can do 100% of the job.