|Optimizations and Language Definitions firstname.lastname@example.org (Dale Worley) (1988-09-13)|
|Re: Optimizations and Language Definitions email@example.com (1988-09-20)|
|Re: Optimizations and Language Definitions firstname.lastname@example.org (Henry Spencer) (1988-09-22)|
|From:||Henry Spencer <email@example.com>|
|Date:||Thu, 22 Sep 88 05:22:31 EDT|
In article <firstname.lastname@example.org> our moderator writes:
>[No, pragmas aren't supposed to change the semantics of code...
A common misunderstanding. In fact, the last two drafts have not clearly
specified whether they are allowed to or not. Neither interpretation is
self-contradictory. The most common argument against is that one is not
supposed to interpret one paragraph of a standard without considering the
rest, and therefore #pragma is bounded by the rest of the standard. The
counter-argument is that the same reasoning applies in reverse: one cannot
understand the rest of the standard without considering that that one
little paragraph about #pragma may have the power to change it all.
There was some sentiment for resolving this ambiguity, but I don't know
whether anything will be done now (nothing was done in the May draft).
>... since floating point operations are not in general
>associative the "as if" rule would rule out rearranging such operations
>except in the rare case where the compiler can prove that the results are
This indeed appears to be the case. The sloppy old C wording about how
the compiler is free to rearrange is pretty much gone, replaced by the
"as if" clause. But the "as if" clause is more restrictive, since it
seldom applies to floating point, and in general doesn't even apply to
integers (although in fact the only real problem with integers is the
occurrence of overflow, and an implementation which ignores overflow
can rearrange integer expressions to its heart's content).
Henry Spencer at U of Toronto Zoology
Return to the
Search the comp.compilers archives again.