Re: type based aliasing again

[craig@jcb-sc.com]

>craig@jcb-sc.com writes:
>
>> >What you repeatedly miss is that there are many many more
>> >people that use gcc as the "free software install tool" than there are 
>> >who actually write programs. 
>> 
>> What you, and others, repeatedly miss is that GCC is a compiler,
>> not a free-software install tool.
>> 
>> If I wanted to work on a free-software install tool, I'd work on RPM
>> or something like that.
>
>Just reading the GCC installation document proves you wrong on this one
>(GCC definitely uses itself as a free-software install tool). Lots of
>other software does too. For example it is the standard installation
>method of GNU software as distributed on ftp.gnu.org.

Please quote where the GCC install documents claim GCC is a free-software
install tool.

My understanding of the GCC installation procedure is that GCC is used
to compile *itself* as well as a few other components that are shipped
with *it*.  Therefore it is the responsibility of the GCC maintainers
to ensure those *tools* are properly coded with respect to the same
standard (extended ISO C) compiled by GCC.

I'll note that, in past incarnations of this discussion, it has
been pointed out that there are (at least apparent) instances
of the bug in GCC code itself, and that I cannot recall a *single*
instance in which a GCC developer said "well, that's not really
a bug so much as the compiler breaking existing code".

>Just ignoring that common use of the compiler just does not serve the
>user base, nor I think the GNU project, well.

I never said anything about "ignoring" a common use of the compiler.

I strongly suggest people stop claiming GCC is a free-software install
tool.  It is not.  It is a compiler.  Free-software install *procedures*
may well *use* it as a tool, but that leaves the responsibility
of correctly invoking it to compile C code (e.g. providing
the -fno-alias-analysis option) entirely in the hands of the maintainers
of those *procedures*.

>> If you think the problem is so bad, then go and fix *it* in all the
>> code you think is too "stable and trusted" to be permitted to fail
>> due to its own bugs.  Do not make GCC worse by having it paper over
>> the problem for any amount of time.  That does a long-term disservice
>> to users.  I refuse to participate in pandering to users' short-term
>> wants by threatening our ability to meet their long-term *needs*.
>
>Because fixing it often needs major data structure changes (overlap ->
>explicit union), which are often just impossible to submit into a
>stable code freezed production release mainteance tree. Because of
>gcc's lack of anonymous unions in C it usually requires changes to
>every user of that possible overlapped data structure, it is not possible
>to encapsulate it.

That's why we offer -fno-alias-analysis, which is going beyond
the strict mandate of an ISO C compiler to compile ISO C code.

>If I tried to tell Jeff to change all users of e.g. tree or rtx in
>the stable freezed gcc branch to fix some obscure[1] bug caused by
>behaviour change in third party software he would laugh me out of the list.

I doubt that.  We (not he) would probably limit our course of action
to one of two responses:

  -  Delay the release to fix the code (or at least work around the
     problem, i.e. the equivalent of supplying -fno-alias-analysis).

  -  Document that the third-party software in question is not supported
     by this new release (ideally by disabling it so it won't appear
     to work even to users who don't read docs)

The response you and others would offer, "scream loudly about how
that behavior change in third-party software broke working code like
GCC and therefore must be changed back", would not be offered by
anyone taken seriously as a core developer for a product like GCC.

        tq vm, (burley)