Re: Distributivity and types (Wclodius)
22 May 1999 20:40:59 -0400

          From comp.compilers

Related articles
Distributivity and types (Sanjay Pujare) (1999-05-22)
Re: Distributivity and types (1999-05-22)
Re: Distributivity and types (1999-05-27)
Re: Distributivity and types (1999-05-27)
Re: Distributivity and types (1999-05-29)
Re: Distributivity and types (1999-05-29)
| List of all articles for this month |

From: (Wclodius)
Newsgroups: comp.compilers
Date: 22 May 1999 20:40:59 -0400
Organization: AOL
References: 99-05-111
Keywords: optimize, standards, Fortran, comment

>Consider the expression
>Because of distributivity this can be changed to
>But I have a question: Can this be done always? What happens when a
>is unsigned and (b+c) is signed? Does anybody have any insight into this?
>[Depends on your language definition. In Fortran, the answer is always
>yes, in other languages, sometimes yes, sometimes no. -John]

In Fortran 95, and I believe all earlier versions of the Fortran
standard the answer is sometimes yes, sometimes no. See section Parentheses, if they make a difference, and they almost
always can in floating point, have to be respected. For integer
arithmetic the answer is more subtle. It is possible that the cases
where parentheses in integer arithmetic can make a difference involve
undefined behavior and the processor may therefore be able to justify
applying distributivity and still be standard conforming.

Note, however, that while Fortran requires respecting parentheses it
does not require respecting the absence of parentheses, i.e., it can

a*b + a*c



but it cannot rewrite

(a*b) + (a*c)

to the same form. Fortran is looser than some other languages, e.g., C, in
allowing commutivity to be exploited.

William B. Clodius
[I went back and checked. Fortran 66 allowed the compiler to substitute
any mathematically equivalent expression regardless of parens, while
Fortran 77 required that parens be honored. -John]

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.