Path: utzoo!utgpu!water!watmath!orchid!atbowler
From: atbowler@orchid.waterloo.edu (Alan T. Bowler [SDG])
Newsgroups: comp.lang.c
Subject: Re: noalias; parens honored
Keywords: ANSI C standard
Message-ID: <12211@orchid.waterloo.edu>
Date: 5 Jan 88 22:19:07 GMT
References: <6829@brl-smoke.ARPA> <2845@zeus.TEK.COM> <6860@brl-smoke.ARPA>
Reply-To: atbowler@orchid.waterloo.edu (Alan T. Bowler [SDG])
Organization: U. of Waterloo, Ontario
Lines: 28

In article <6860@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>
>>Also, how much worse will the code be when paren grouping must be honored?
>
>I don't think it matters much.  If your environment is such that the
>same result is obtained either way, which is true of many environments,
>the optimzer can go ahead and rearrange integer expressions at least.

If you have an situation where overflows are significant, then the
"honour parenthesis" rule forbids the compiler from making even simple
optimizations like constant folding.
If the result of a macro is something like
    ((a + 1) -1)
then an honour parenthesis rule means the compiler
can't optimize this to a simple "a" because it will have different
overflow characteristics.
    Note that this will apply to ALL floating point calculations,
and any integer calculations in an environment where there exists
a signal request that asks the system to report integer overflows.
    With the new rule parentheses are being asked to perform 2 distinct
actions
    1) override the default precedence rules
    2) specify the evaluation sequence.
I did not particularly care for the unary + kludge since I thought the
sequencing function was well enough served by the traditional
method of multiple statements.  However, it was certainly preferable
to the new rule which says I when I add parenthesis to make the
line clearly to the human reader, I may be making the generated code worse.