From mboxrd@z Thu Jan 1 00:00:00 1970 From: craig AT jcb-sc.com To: ak AT muc.de Cc: craig AT jcb-sc.com Subject: Re: type based aliasing again Date: Thu, 16 Sep 1999 14:29:00 -0000 Message-id: <19990916184913.21978.qmail@deer> References: <199909151655.RAA05716@tiuk.ti.com> <13132.937411270@upchuck.cygnus.com> <19990915170504.15439.qmail@deer> X-SW-Source: 1999-09/msg00735.html >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) From mboxrd@z Thu Jan 1 00:00:00 1970 From: craig@jcb-sc.com To: ak@muc.de Cc: craig@jcb-sc.com Subject: Re: type based aliasing again Date: Thu, 30 Sep 1999 18:02:00 -0000 Message-ID: <19990916184913.21978.qmail@deer> References: <199909151655.RAA05716@tiuk.ti.com> <13132.937411270@upchuck.cygnus.com> <19990915170504.15439.qmail@deer> X-SW-Source: 1999-09n/msg00735.html Message-ID: <19990930180200.9pmkBURiLnaK7sB8SYuoM3x6lMXNzyy1EQBs8Ay5m8g@z> >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)