From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Mitchell To: rms@gnu.org Cc: jbuck@synopsys.com, mrs@wrs.com, gcc@gcc.gnu.org Subject: Re: type based aliasing again Date: Sat, 11 Sep 1999 15:20:00 -0000 Message-id: <19990911152505P.mitchell@codesourcery.com> References: <199909100708.AAA00030@atrus.synopsys.com> <199909110724.DAA03071@psilocin.gnu.org> X-SW-Source: 1999-09/msg00442.html Someone (not RMS, but I have lost track of who, originally) wrote: In the end, if your argument is carried too far, the only solution would be to make -fno-strict-alias the default. I think that making -fno-strict-aliasing the default is sensible proposal, and worth debating. Whether or not it is the default should be based on a variety of considerations, including how many programs are "broken" by the more correct behavior, how many of those can and will be easily fixed, and how many are actively maintained. For example, the Linux kernel is not a good reason to change the default; it is easy for this actively maintained project to simply add -fno-strict-aliasing to their Makefiles, if appropriate. But, if it is true that most, or at least a lot, of programs do not follow the ISO rules, then it may be that we have set the default incorrectly. In my experience, there are not too many such programs; I have only seen one such cases in our customer's code, and that was very easily fixed. However, I make no claim that this code base is reprsentative of things compiled with GCC. I would much rather see us change the default, if that is really necessary, than muddy the waters with confusing semantics, semantics that will change due to minor adjustments to the compiler. Yes, this would mean that users cannot have their cake and eat it too: they cannot have the benefits of -fstrict-alaising and still not follow the ISO rules. But, they are no worse off than before we added the aliasing optimizations. The best strategy at this point, in my opinion, would be for someone to implement the warning. (Note that this is non-trivial.) Then, we can get some idea as to how much code is breaking the rules, and then judge whether or not he default is correct. We must also weigh the risk that people will not fix the code, unless we break it, and that we will therefore never be able to make -fstrict-aliasing the default. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Mitchell To: rms@gnu.org Cc: jbuck@synopsys.com, mrs@wrs.com, gcc@gcc.gnu.org Subject: Re: type based aliasing again Date: Thu, 30 Sep 1999 18:02:00 -0000 Message-ID: <19990911152505P.mitchell@codesourcery.com> References: <199909100708.AAA00030@atrus.synopsys.com> <199909110724.DAA03071@psilocin.gnu.org> X-SW-Source: 1999-09n/msg00442.html Message-ID: <19990930180200.1_Ew_BaMgFM7dtMHQgIjOoLELU3sG9_W_PV_UJtH23w@z> Someone (not RMS, but I have lost track of who, originally) wrote: In the end, if your argument is carried too far, the only solution would be to make -fno-strict-alias the default. I think that making -fno-strict-aliasing the default is sensible proposal, and worth debating. Whether or not it is the default should be based on a variety of considerations, including how many programs are "broken" by the more correct behavior, how many of those can and will be easily fixed, and how many are actively maintained. For example, the Linux kernel is not a good reason to change the default; it is easy for this actively maintained project to simply add -fno-strict-aliasing to their Makefiles, if appropriate. But, if it is true that most, or at least a lot, of programs do not follow the ISO rules, then it may be that we have set the default incorrectly. In my experience, there are not too many such programs; I have only seen one such cases in our customer's code, and that was very easily fixed. However, I make no claim that this code base is reprsentative of things compiled with GCC. I would much rather see us change the default, if that is really necessary, than muddy the waters with confusing semantics, semantics that will change due to minor adjustments to the compiler. Yes, this would mean that users cannot have their cake and eat it too: they cannot have the benefits of -fstrict-alaising and still not follow the ISO rules. But, they are no worse off than before we added the aliasing optimizations. The best strategy at this point, in my opinion, would be for someone to implement the warning. (Note that this is non-trivial.) Then, we can get some idea as to how much code is breaking the rules, and then judge whether or not he default is correct. We must also weigh the risk that people will not fix the code, unless we break it, and that we will therefore never be able to make -fstrict-aliasing the default. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com