From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Ing-Simmons To: law AT cygnus.com Cc: rms AT gnu.org, gcc AT gcc.gnu.org Subject: Re: type based aliasing again Date: Wed, 15 Sep 1999 09:56:00 -0000 Message-id: <199909151655.RAA05716@tiuk.ti.com> References: <13132.937411270@upchuck.cygnus.com> X-SW-Source: 1999-09/msg00632.html 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. Having the "new improved" gcc break previously stable and trusted free software does the movement as a whole no good at all. Jeffrey A Law writes: > > No, it allows _programmers_ that know what they are doing to get the > > benefit of their knowledge by the simple expedient of adding -fstrict-alias > > ing > > to Makefile.in and forgetting about it. > > > > While protecting sys-admins and users of open-source products that just > > build but do not write them from the bad habits that not-so-good/or > > too-clever-for-their-own-good programmers have developed over the decades. >So are you going to propose next that we turn off automatic register allocation >because some programmers don't have enough of a clue to write correct code? Of course not. The code I am talking about has been working fine for years, and obviously has no problems with register allocation and similar "old hat" optimizations. My entire argument is based on the fact that there are free/opensource applications "out there" which work fine with gcc-1.3 .. gcc-2.8.1 which break with late egcs-1.1.* and gcc-2.95.* Now when 'sys-admin@clueless.org' sends in a bug report on perl (say) we say "get new release" or "add -fno-strict-aliasing to ccflags". At best we make them spend 10s of minutes doing a rebuild and they are just grumpy. At worst the tell their collegues/manager "this free software is fragile, if any bit changes you have to go re-build everything" or similar. And then there are packages out there which are not actively maintained... > not using volatile for variables live across setjmp). There is a warning for that. And if it is going to fail it will have failed and so existing packages have it "right enough". > >Or are you going to propose that we turn off MEM_IN_STRUCT_P because some >clueless programmer violated the assumptions for that optimization? No, no 1000 times no. I don't care about "clueless" programmers - I care about USERS of applications written by clever programmers that (ab)used aliasing to get a job done. -- Nick Ing-Simmons Via, but not speaking for: Texas Instruments Ltd. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Ing-Simmons To: law@cygnus.com Cc: rms@gnu.org, gcc@gcc.gnu.org Subject: Re: type based aliasing again Date: Thu, 30 Sep 1999 18:02:00 -0000 Message-ID: <199909151655.RAA05716@tiuk.ti.com> References: <13132.937411270@upchuck.cygnus.com> X-SW-Source: 1999-09n/msg00632.html Message-ID: <19990930180200.JpRbmzn7Sqo9B3HAu-IHECQCHzCVg0GCi6B6LsdXZKA@z> 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. Having the "new improved" gcc break previously stable and trusted free software does the movement as a whole no good at all. Jeffrey A Law writes: > > No, it allows _programmers_ that know what they are doing to get the > > benefit of their knowledge by the simple expedient of adding -fstrict-alias > > ing > > to Makefile.in and forgetting about it. > > > > While protecting sys-admins and users of open-source products that just > > build but do not write them from the bad habits that not-so-good/or > > too-clever-for-their-own-good programmers have developed over the decades. >So are you going to propose next that we turn off automatic register allocation >because some programmers don't have enough of a clue to write correct code? Of course not. The code I am talking about has been working fine for years, and obviously has no problems with register allocation and similar "old hat" optimizations. My entire argument is based on the fact that there are free/opensource applications "out there" which work fine with gcc-1.3 .. gcc-2.8.1 which break with late egcs-1.1.* and gcc-2.95.* Now when 'sys-admin@clueless.org' sends in a bug report on perl (say) we say "get new release" or "add -fno-strict-aliasing to ccflags". At best we make them spend 10s of minutes doing a rebuild and they are just grumpy. At worst the tell their collegues/manager "this free software is fragile, if any bit changes you have to go re-build everything" or similar. And then there are packages out there which are not actively maintained... > not using volatile for variables live across setjmp). There is a warning for that. And if it is going to fail it will have failed and so existing packages have it "right enough". > >Or are you going to propose that we turn off MEM_IN_STRUCT_P because some >clueless programmer violated the assumptions for that optimization? No, no 1000 times no. I don't care about "clueless" programmers - I care about USERS of applications written by clever programmers that (ab)used aliasing to get a job done. -- Nick Ing-Simmons Via, but not speaking for: Texas Instruments Ltd.