From mboxrd@z Thu Jan 1 00:00:00 1970 From: Toon Moene To: David Edelsohn Cc: Mark Mitchell , craig AT jcb-sc.com, nik AT tiuk.ti.com, richard.earnshaw AT arm.com, N8TM AT aol.com, gcc AT gcc.gnu.org, espie AT quatramaran.ens.fr Subject: Re: type based aliasing again Date: Tue, 14 Sep 1999 16:01:00 -0000 Message-id: <37DED310.96247CB9@moene.indiv.nluug.nl> References: <9909142158.AA25870@marc.watson.ibm.com> X-SW-Source: 1999-09/msg00564.html David Edelsohn wrote: > >>>>> I wrote: > Toon> I reread K&R II (Chapter 5 "Pointers and Arrays" and Appendix C "Summary > Toon> of Changes") and nowhere they say these restrictions against using > Toon> differently typed pointers "are new with the ANSI/ISO Standard". > This viewpoint does not cover large groups of compiler users. > Many programmers wrote code using differently typed pointers -- either > because it was natural or because they wree trying to elicit certain > behavior from the compiler. This code behaved as expected when compiled > with GCC using default commandline flags until this latest release. I do not deny that there are programmers who _think_ that that sort of type-mixing pointing is "allowed" - we can all count the "bug reports" we get because they do. What I'm trying to establish is whether those programmers had a right to believe this was allowed *based on the Standard previous to the current Standard*, namely K&R I. If K&R I allowed it, it is an incompatible change with ANSI/ISO C 89, and I am willing to cut the old hands some slack. If not - there's a simple compile time option to turn off the unwanted behaviour. Perhaps it helps if I explain why I have little patience with this sort of trickery (with the above caveat in mind): Every month or so, somebody chastizes Digital's Fortran on comp.lang.fortran for an "obvious and heinous" bug, because the following construct doesn't do what they think it should: REAL A(N) ... IF (I .GT. 0 .AND. I .LE. N .AND. A(I) .GT. 0.0) THEN ... when the compiled code crashes with a Segmentation Violation. Why ? Well, simply because the Fortran definition of .AND. doesn't imply ordering; it's simply a commutative LOGICAL expression (in this case two, with three operands). The operands can legally be evaluated in any order, and as soon as the truth value of the expression can be determined (because one of the operands evaluates to .FALSE.) no other evaluation has to take place, but is also not prohibited. The experts take a deep breath, and explain to the (often experienced Fortran) programmer that this is completely legal. I've watched this now for several years, *and I have never seen the Digital Fortran guys give in*. There isn't an advertised optimisation level at which this is guaranteed not to happen. -- Toon Moene (toon@moene.indiv.nluug.nl) Saturnushof 14, 3738 XG Maartensdijk, The Netherlands Phone: +31 346 214290; Fax: +31 346 214286 GNU Fortran: http://gcc.gnu.org/onlinedocs/g77_news.html From mboxrd@z Thu Jan 1 00:00:00 1970 From: Toon Moene To: David Edelsohn Cc: Mark Mitchell , craig@jcb-sc.com, nik@tiuk.ti.com, richard.earnshaw@arm.com, N8TM@aol.com, gcc@gcc.gnu.org, espie@quatramaran.ens.fr Subject: Re: type based aliasing again Date: Thu, 30 Sep 1999 18:02:00 -0000 Message-ID: <37DED310.96247CB9@moene.indiv.nluug.nl> References: <9909142158.AA25870@marc.watson.ibm.com> X-SW-Source: 1999-09n/msg00564.html Message-ID: <19990930180200.6hjqhmGoYS-qDwSDrenm2ocTy_ITLxb1QXpSQuoKBwQ@z> David Edelsohn wrote: > >>>>> I wrote: > Toon> I reread K&R II (Chapter 5 "Pointers and Arrays" and Appendix C "Summary > Toon> of Changes") and nowhere they say these restrictions against using > Toon> differently typed pointers "are new with the ANSI/ISO Standard". > This viewpoint does not cover large groups of compiler users. > Many programmers wrote code using differently typed pointers -- either > because it was natural or because they wree trying to elicit certain > behavior from the compiler. This code behaved as expected when compiled > with GCC using default commandline flags until this latest release. I do not deny that there are programmers who _think_ that that sort of type-mixing pointing is "allowed" - we can all count the "bug reports" we get because they do. What I'm trying to establish is whether those programmers had a right to believe this was allowed *based on the Standard previous to the current Standard*, namely K&R I. If K&R I allowed it, it is an incompatible change with ANSI/ISO C 89, and I am willing to cut the old hands some slack. If not - there's a simple compile time option to turn off the unwanted behaviour. Perhaps it helps if I explain why I have little patience with this sort of trickery (with the above caveat in mind): Every month or so, somebody chastizes Digital's Fortran on comp.lang.fortran for an "obvious and heinous" bug, because the following construct doesn't do what they think it should: REAL A(N) ... IF (I .GT. 0 .AND. I .LE. N .AND. A(I) .GT. 0.0) THEN ... when the compiled code crashes with a Segmentation Violation. Why ? Well, simply because the Fortran definition of .AND. doesn't imply ordering; it's simply a commutative LOGICAL expression (in this case two, with three operands). The operands can legally be evaluated in any order, and as soon as the truth value of the expression can be determined (because one of the operands evaluates to .FALSE.) no other evaluation has to take place, but is also not prohibited. The experts take a deep breath, and explain to the (often experienced Fortran) programmer that this is completely legal. I've watched this now for several years, *and I have never seen the Digital Fortran guys give in*. There isn't an advertised optimisation level at which this is guaranteed not to happen. -- Toon Moene (toon@moene.indiv.nluug.nl) Saturnushof 14, 3738 XG Maartensdijk, The Netherlands Phone: +31 346 214290; Fax: +31 346 214286 GNU Fortran: http://gcc.gnu.org/onlinedocs/g77_news.html