From mboxrd@z Thu Jan 1 00:00:00 1970 From: "R. Kelley Cook" To: "egcs@egcs.cygnus.com" Subject: Re: type based aliasing again Date: Mon, 13 Sep 1999 10:55:00 -0000 Message-id: X-SW-Source: 1999-09/msg00498.html On 13 Sep 1999 13:05:39 +0200, Richard Earnshaw wrote: > >mark@codesourcery.com said: >> I think that making -fno-strict-aliasing the default is sensible >> proposal, and worth debating. > > >It is the default at -O1 or less. I would be inclined to argue that this >should be adequate for "legacy" code and that the higher levels of >optimization should be allowed to fully exploit the provisions of the C >standard (this is not to suggest that a warning shouldn't be generated if >possible). > >We are somewhat constrained by our relatively limited number of >optimization levels (0, 1, 2, 3, s); I guess extending the range is hard, >mainly because of a user-education issue. But it would be useful if we >could have a level above which we say that we assume that code fully >conforms to the C (or other relevant) standard. > What would be wrong with -fno-strict-aliasing the default for -O(1,2,3,s) and have a new -O4 enable it (ie "-O4" == "-O3 -fstrict-aliasing"). This would guarantee all current software and their make files to still generate correct code, yet still make it extremely easy to enable the optimizations for fully ISO/ANSI compliant software. Its seems like far too easy a solution to me. -- Kelley Cook From mboxrd@z Thu Jan 1 00:00:00 1970 From: "R. Kelley Cook" To: "egcs@egcs.cygnus.com" Subject: Re: type based aliasing again Date: Thu, 30 Sep 1999 18:02:00 -0000 Message-ID: X-SW-Source: 1999-09n/msg00498.html Message-ID: <19990930180200.ZwJLAm36bKsvAtqyvBAIPdHhZh4lwFrgyMrATltPN2Y@z> On 13 Sep 1999 13:05:39 +0200, Richard Earnshaw wrote: > >mark@codesourcery.com said: >> I think that making -fno-strict-aliasing the default is sensible >> proposal, and worth debating. > > >It is the default at -O1 or less. I would be inclined to argue that this >should be adequate for "legacy" code and that the higher levels of >optimization should be allowed to fully exploit the provisions of the C >standard (this is not to suggest that a warning shouldn't be generated if >possible). > >We are somewhat constrained by our relatively limited number of >optimization levels (0, 1, 2, 3, s); I guess extending the range is hard, >mainly because of a user-education issue. But it would be useful if we >could have a level above which we say that we assume that code fully >conforms to the C (or other relevant) standard. > What would be wrong with -fno-strict-aliasing the default for -O(1,2,3,s) and have a new -O4 enable it (ie "-O4" == "-O3 -fstrict-aliasing"). This would guarantee all current software and their make files to still generate correct code, yet still make it extremely easy to enable the optimizations for fully ISO/ANSI compliant software. Its seems like far too easy a solution to me. -- Kelley Cook