From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joe Buck To: rms@gnu.org (Richard Stallman) Cc: mrs@wrs.com, gcc@gcc.gnu.org, jbuck@synopsys.com Subject: Re: type based aliasing again Date: Fri, 10 Sep 1999 00:11:00 -0000 Message-id: <199909100708.AAA00030@atrus.synopsys.com> References: <199909100634.CAA01815@psilocin.gnu.org> X-SW-Source: 1999-09/msg00404.html RMS writes: > In C, we cannot divide all user code into "right" and "wrong" in this > kind of simple way, and certainly not based on the ISO standard. That > standard is just the decisions of a certain committee (which I was a > member of) about what cases conforming compilers should commit to > support. We must not let ourselves start thinking that C code is > "wrong", just because it is not conforming ISO C code. While I have some sympathy for that point of view, the reason that the type aliasing rules were added was to give scientific programmers what they were asking for: C that runs about as fast as Fortran. I don't want to break users' code when we can TELL what they mean, and many examples seem to fall into that category. But where we can't tell, we have to either exploit the ISO rules (e.g. -fstrict-alias) or not (-fno-strict-alias). In the end, if your argument is carried too far, the only solution would be to make -fno-strict-alias the default. But that penalizes the users that make the effort to learn the rule. I think that we don't disagree on general philosophy, only where to draw the line. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joe Buck To: rms@gnu.org (Richard Stallman) Cc: mrs@wrs.com, gcc@gcc.gnu.org, jbuck@synopsys.com Subject: Re: type based aliasing again Date: Thu, 30 Sep 1999 18:02:00 -0000 Message-ID: <199909100708.AAA00030@atrus.synopsys.com> References: <199909100634.CAA01815@psilocin.gnu.org> X-SW-Source: 1999-09n/msg00404.html Message-ID: <19990930180200.n_p3m1l9mQbrQfSA9xE9iIpzwEZ3JMXknwXNKyuOASY@z> RMS writes: > In C, we cannot divide all user code into "right" and "wrong" in this > kind of simple way, and certainly not based on the ISO standard. That > standard is just the decisions of a certain committee (which I was a > member of) about what cases conforming compilers should commit to > support. We must not let ourselves start thinking that C code is > "wrong", just because it is not conforming ISO C code. While I have some sympathy for that point of view, the reason that the type aliasing rules were added was to give scientific programmers what they were asking for: C that runs about as fast as Fortran. I don't want to break users' code when we can TELL what they mean, and many examples seem to fall into that category. But where we can't tell, we have to either exploit the ISO rules (e.g. -fstrict-alias) or not (-fno-strict-alias). In the end, if your argument is carried too far, the only solution would be to make -fno-strict-alias the default. But that penalizes the users that make the effort to learn the rule. I think that we don't disagree on general philosophy, only where to draw the line.