From mboxrd@z Thu Jan 1 00:00:00 1970 From: mark@codesourcery.com To: torvalds@transmeta.com Cc: craig@jcb-sc.com, davem@redhat.com, chip@perlsupport.com, egcs@egcs.cygnus.com Subject: Re: Linux and aliasing? Date: Thu, 03 Jun 1999 23:45:00 -0000 Message-id: <19990603234839L.mitchell@codesourcery.com> References: <19990604015713.18068.qmail@deer> X-SW-Source: 1999-06/msg00113.html I don't think the cast rule is by any means the right obvious default. For one thing, it pessimizes object-oriented C code that does downcasts through an inheritance hierarchy. There's no reason that we shouldn't be able to use type-based alias analysis in such situations, but your proposal would make it not happen. You can use -fno-strict-aliasing to get the "traditional" behavior. The only affect on your code will be that some optimizations that used not to happen, but would with -fstrict-aliasing, will still not happen. What's the big deal? If -fstrict-aliasing had never been implemented, you wouldn't be complaining would you? So, we've improved GCC, and we've preserved the old behavior. GCC has plenty of odd rules and way too many options. We don't need more. The exception, I think, is when there's something that you can only do with a language extension or special flag. Extended asm's are one such; you just can't do it without an extension. So, we have it. But, here, you just don't like ANSI/ISO C, and wish it had different semantics. You *could* express what you want in legal ANSI/ISO C, and then GCC would do the right thing, with its default flags. If we come up with a rule that turns off strict aliasing only for code which is non legal ANSI/ISO C, then perhaps we should issue a warning (on the illegal construct) and then turn off strict aliasing. But, I don't think you should expect us to do this any time soon (without financial incentive, or a noble volunteer). -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com From mboxrd@z Thu Jan 1 00:00:00 1970 From: mark@codesourcery.com To: torvalds@transmeta.com Cc: craig@jcb-sc.com, davem@redhat.com, chip@perlsupport.com, egcs@egcs.cygnus.com Subject: Re: Linux and aliasing? Date: Wed, 30 Jun 1999 15:43:00 -0000 Message-ID: <19990603234839L.mitchell@codesourcery.com> References: <19990604015713.18068.qmail@deer> X-SW-Source: 1999-06n/msg00113.html Message-ID: <19990630154300.oN6JEgHKAa5YVKjY7NLSWP5m53-MNy68Zm0vp9kPaFY@z> I don't think the cast rule is by any means the right obvious default. For one thing, it pessimizes object-oriented C code that does downcasts through an inheritance hierarchy. There's no reason that we shouldn't be able to use type-based alias analysis in such situations, but your proposal would make it not happen. You can use -fno-strict-aliasing to get the "traditional" behavior. The only affect on your code will be that some optimizations that used not to happen, but would with -fstrict-aliasing, will still not happen. What's the big deal? If -fstrict-aliasing had never been implemented, you wouldn't be complaining would you? So, we've improved GCC, and we've preserved the old behavior. GCC has plenty of odd rules and way too many options. We don't need more. The exception, I think, is when there's something that you can only do with a language extension or special flag. Extended asm's are one such; you just can't do it without an extension. So, we have it. But, here, you just don't like ANSI/ISO C, and wish it had different semantics. You *could* express what you want in legal ANSI/ISO C, and then GCC would do the right thing, with its default flags. If we come up with a rule that turns off strict aliasing only for code which is non legal ANSI/ISO C, then perhaps we should issue a warning (on the illegal construct) and then turn off strict aliasing. But, I don't think you should expect us to do this any time soon (without financial incentive, or a noble volunteer). -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com