From mboxrd@z Thu Jan 1 00:00:00 1970 From: craig AT jcb-sc.com To: nik AT tiuk.ti.com Cc: craig AT jcb-sc.com Subject: Re: type based aliasing again Date: Tue, 14 Sep 1999 11:01:00 -0000 Message-id: <19990914175517.9373.qmail@deer> References: <199909141706.SAA08354@sun52.NIS.cambridge> <199909141726.SAA08296@tiuk.ti.com> X-SW-Source: 1999-09/msg00548.html >Richard Earnshaw writes: >>-ffast-math enables >>optimizations that the relevant standards disallow. -fstrict-aliasing >>does exactly the opposite. (That might be misinterpreted. -ffast-math and -fstrict-aliasing both enable optimizations. The former enables optimizations that the relevant standards disallows. The latter does not.) >But the math standard has had much longer to settle in and get adopted >in the existing code base. When new C alias standard has been around as long >as IEEE-754 then it may be time to flip the default... There's a confusion in that statement that reveals why, indeed, -ffast-math is not a precedent. Before IEEE-754, no code was written that *required* -ffast-math. IEEE-754 springing into existence caused programmers to start writing code that required -fno-fast-math, however. (Some already had been on systems -- CPU + library + compiler -- that effectively offered the same promises.) So specifying -ffast-math is saying "My code meets requirements above and beyond the present standards". Specifying -fstrict-analysis is saying "My code meets the presents standards". I don't know the history of the C aliasing requirement, but, offhand, it strikes me as highly unlikely that it does *not* constitute an incompatible change vis-a-vis former revisions of the standard. Even if so, it seems kinda silly for users to have to specify *any* option that says "My code meets the present standards", especially vis-a-vis the ISO C standard, when compiling code in a file with a name like "foo.c". tq vm, (burley) From mboxrd@z Thu Jan 1 00:00:00 1970 From: craig@jcb-sc.com To: nik@tiuk.ti.com Cc: craig@jcb-sc.com Subject: Re: type based aliasing again Date: Thu, 30 Sep 1999 18:02:00 -0000 Message-ID: <19990914175517.9373.qmail@deer> References: <199909141706.SAA08354@sun52.NIS.cambridge> <199909141726.SAA08296@tiuk.ti.com> X-SW-Source: 1999-09n/msg00548.html Message-ID: <19990930180200.r1kAYR6PVp3FeycjPfgD04xzLKUJ6FxtEk5WGN0LrMo@z> >Richard Earnshaw writes: >>-ffast-math enables >>optimizations that the relevant standards disallow. -fstrict-aliasing >>does exactly the opposite. (That might be misinterpreted. -ffast-math and -fstrict-aliasing both enable optimizations. The former enables optimizations that the relevant standards disallows. The latter does not.) >But the math standard has had much longer to settle in and get adopted >in the existing code base. When new C alias standard has been around as long >as IEEE-754 then it may be time to flip the default... There's a confusion in that statement that reveals why, indeed, -ffast-math is not a precedent. Before IEEE-754, no code was written that *required* -ffast-math. IEEE-754 springing into existence caused programmers to start writing code that required -fno-fast-math, however. (Some already had been on systems -- CPU + library + compiler -- that effectively offered the same promises.) So specifying -ffast-math is saying "My code meets requirements above and beyond the present standards". Specifying -fstrict-analysis is saying "My code meets the presents standards". I don't know the history of the C aliasing requirement, but, offhand, it strikes me as highly unlikely that it does *not* constitute an incompatible change vis-a-vis former revisions of the standard. Even if so, it seems kinda silly for users to have to specify *any* option that says "My code meets the present standards", especially vis-a-vis the ISO C standard, when compiling code in a file with a name like "foo.c". tq vm, (burley)