Re: type based aliasing again

[craig AT jcb-sc.com]

>Unfortunatly, it seems that one of
>the worst traits of the community is a rather cavilier attitude towards
>backward compatability. 

I agree wholeheartedly with that statement, taken out of context,
and believe I've raised it earlier in this thread (though perhaps in
private emails -- I've lost track).

My opinion is that the free-software community spends too little time
making sure its software is *engineered* correctly so true backwards
compatibility actually works.  I gather problems upgrading libc on
Linux are examples, as well as Linux-related problems between
versions of gcc.  There are no excuses for the problems I've heard
about, other than that the people working on the products didn't devote
enough time and energy to really study the issues.  (Perhaps they were
too busy arguing about precisely how to support broken code in some
forum somewhere?)

My concern remains: to the extent we spend time trying to accommodate
people who write, and refuse to maintain yet continue to distribute,
*broken* code, we do a *worse* job providing true backwards
compatibility, among many other things that *are*, properly, the job
of GCC (as well as other free-software components) to provide.

However, *in* context, that sentence could be interpreted to suggest
that GCC defaulting to -fno-alias-analysis would constitute
backwards compatibility.

That is false.  Else GCC behavior as of 2.8.1 and previous would
have to be considered a "feature", especially vis-a-vis alias
analysis.

And the whole point some people (like RMS) have been trying to make
is that we should *not* think of this as a "feature".

If it's not a feature, then backwards compatibility is not an issue.

>  In short, and in general, I think it is good policy to, if possible,
>include a warning whenever the behaviour of the compiler changes. I think
>the worst solution possible is the current silent corruption that is
>currently default in gcc.

We *did* issue a warning.  It's in the FAQ and elsewhere in the docs.

It's also in the fact that *every* new release of a compiler is likely
to change its behavior vis-a-vis a previous release.  Generally, that
is the whole *point* of a new release.  The question of "what changes
to behavior are acceptable and what are not" is not as "obvious" as
you might think, else we wouldn't be having these discussions.

And there is no current silent corruption that is default in GCC
as pertains this thread.  If you believe that, you were misinformed,
and should abstain from repeating this misinformation in any other
forum in the future.

The solution for "ordinary" programmers is just *so* simple: if you
like the way a given compiler version compiles your free software,
then offer its assembly output for the hosts you care to support
in lieu of end-user compilation using an arbitrary compiler or version.
(I.e. use "gcc -S" and distribute the .s file along with rules in
your Makefile to compile and link it, rather than the .c file,
when one exists for the target machine.)

Beyond that, you just can't expect the behavior of the compiler to
*not* change as your code is moved to another platform, another
compiler, another compiler version, even another set of libraries.

The whole problem here is simply one of miseducation, or ignorance,
on the part of people who think they know what GCC is.  We need not
change one line of code to fix *that* problem, and if we don't
fix that problem, rewriting GCC from scratch will not fix it either.
Certainly changing a few lines will have no worthwhile overall effect.

(Aside to dje: if you consider the above to be a "strawman" argument,
take a *good* look at what <mjbedy@mtu.edu> and others *recently* wrote
about how GCC should work and what it should do.  If I'm putting up and
knocking down strawmen, then please explain why they're coming from other
people, some of whom I've never met before, even on the Internet.)

        tq vm, (burley)