From mboxrd@z Thu Jan  1 00:00:00 1970
From: craig@jcb-sc.com
To: rms@gnu.org
Cc: craig@jcb-sc.com
Subject: Re: type based aliasing again
Date: Thu, 30 Sep 1999 18:02:00 -0000
Message-ID: <19990912155150.19110.qmail@deer>
References: <199909100708.AAA00030@atrus.synopsys.com> <19990910152622.9143.qmail@deer> <199909110725.DAA03149@psilocin.gnu.org> <19990911104435.13384.qmail@deer> <199909120800.EAA04250@psilocin.gnu.org>
X-SW-Source: 1999-09n/msg00464.html
Message-ID: <19990930180200.BNRFqNJpP4YRc5RLVXGPa0PohsgZ7mUZV3Po4mQeiqA@z>

>Some people argue that users will "get the wrong ideas" if any of
>these cases do work.  Well, if that is possible, it is happening now,
>because some of these cases do work.  With -O0, they all work.  Unless
>we do #4, some of them will always work.

Right.  My feeling is, it's better, as long as it's reasonably easy
and doesn't hurt performance, for the default to be consistent with
what users (who don't know the standard inside and out) expect.

If we could be sure we had a "captive audience" that would respond
to our completely ignoring the not-quite-standard code as buggy and
needing fixing, we might indeed help the industry as a whole, and
GCC in particular, become "better".  I.e. users would have no
choice but to fix their code, and, for codes that are likely to
outlast IA32 (vs. Merced/McKinley), the sooner the better, given
the typical "depreciation" on expertise on any given chunk of code.

But we don't have that big a captive audience.  Among other things,
GCC needs as much widespread, volunteer testing done on it as possible,
and the more code it "captures" by working and performing reasonably
well on it, even if it isn't perfectly standard code, the better GCC
becomes.

That some of that code will appear to stop working when ported to
new architectures will be perceived by some as GCC being "wrong",
putting us right back in today's boat vis-a-vis those users.

In the meantime, GCC will have become better, and hopefully better-
respected, before that happens, thus reducing the percentage of
its users who decide GCC has truly "stopped working" rather than
(finally) go and fix the code.  That might be enough to convince
as many people as would ever be feasible anyway that the broken code,
not GCC, finally needed fixing.

So if we worry less about accommodating that code now, we risk losing
more of it *now* to volunteer testing and gaining market share.

But, if we worry much more about accommodating that code, we risk
spending time on that rather than actually making GCC work for
correct code, which can *also* lose us lots of users and code.

It's that latter drop-off I'm more concerned about, if not so much
in number of lines of legacy code, in number of lines of new code
that gets written.  But the former drop-off isn't something we
can completely ignore.

(This is basically the same rationale as one of the ones I was using
to explain my support for doing 80-bit floating-point spills on IA32,
in case anyone was wondering.  One important difference between the
two issues is that at least one viable and effective specification
exists saying that 80-bit spills *should* be done, whereas a
standard exists saying that accommodating C code playing alias
games need *not* be done.)

        tq vm, (burley)