bobm@hpfcmgw.HP.COM (Bob Montgomery) (06/14/89)
For your information:
This is a preliminary version of a warning that will eventually be sent
to all customers receiving the 6.5 Release of Series 300 HP-UX.
Bob Montgomery
Support Somewhere
Hewlett-Packard
=========================================================================
A defect has been detected in the 6.5 global optimizer that you
should understand. The optimizer may make an incorrect
optimization in translating certain infrequent but legal C
constructs. The resulting executable code can corrupt program
data.
FORTRAN code is not affected by the problem.
The problem occurs when the optimizer detects a common
subexpression on the right hand side of an assignment statement.
If the necessary conditions occur, an incorrect reuse of the
left hand side of the assignment may occur. The necessary
conditions are:
1) The entire right hand sides of two or more assignment
statements is the same.
2) The assignments are not separated by any statement
that causes a change in normal sequential control flow.
3) The assignments do not contain function calls and
function calls are not made between the assignment
statements.
4) The left hand side of the first assignment has a side
effect.
If all of these conditions occur and the optimizer determines
that the common subexpression is sufficiently complex to justify
a substitution, it may generate an incorrect code sequence.
For example, the following program will generate different
results if it is globally optimized:
main()
{
int a[16], *ptr, i;
ptr = a;
i = 0;
while (i < 4)
{
/* In the following, "i * 7" is common. "*ptr++"
has a side effect.
*/
*ptr++ = i * 7;
*ptr++ = i * 7;
i++;
}
printf("Expect\t0,0,7,7,14,14,21,21\n\t");
for (i = 0; i < 7; i++)
printf("%d,", a[i]);
printf("%d\n", a[7]);
}
If this program is run unoptimized or optimized at level +O1,
you will see:
Expect 0,0,7,7,14,14,21,21
0,0,7,7,14,14,21,21
If, however, the program is optimized at level +O2 (or -O) you
will see this incorrect result:
Expect 0,0,7,7,14,14,21,21
0,0,0,7,0,0,14,0
This defect has been fixed for the 7.0 and later releases.
Several workarounds exist to avoid the problem in the 6.5
release. Any of the following will work:
1) Change the source code to avoid side effects on the
left hand side of an assignment. This will not cause
any degradation in performance. For example, The
affected assignment statements above could be rewritten
as
*ptr = i * 7;
ptr++;
*ptr = i * 7;
ptr++;
2) Turn off common subexpression elimination. This may
cause some reduced level of performance of the
translated code. The most painless way to do this is to
add the following option to the cc command line or to
the CCOPTS environment variable:
"-W g,-d"
For example, CCOPTS can be reset in a user's .profile
file for sh or ksh shell use. In this way makefiles
will not have to be altered. A sample setting could be
CCOPTS="-W g,-d"
Be sure that CCOPTS is exported from the shell.
Note that in release 7.0 the optimizer will give a
non-fatal warning if this option is invoked to advise
you to remove it from your list of options.
3) Optimize at a lower level of optimization. Common
subexpression elimination is performed only with level
+O2 (or -O) optimization. Expect to see a lower level
of performance from the executable code in this case.
You can specify a lower level of optimization by either
specifying +O1 in the CCOPTS or the cc command line, or
by inserting the compiler directive
# pragma OPT_LEVEL 1
before the functions containing the suspected assignment
statements. Full optimization may then be turned back on
by inserting the compiler directive
# pragma OPT_LEVEL 2
after the functions containing the suspected assignment
statements. See the "C Programmer's Guide" (HP Part
Number 98794-90030) for further details about the use of
pragmas.tml@hemuli.atk.vtt.fi (Tor Lillqvist) (06/16/89)
In article <1080061@hpfcmgw.HP.COM> bobm@hpfcmgw.HP.COM (Bob Montgomery) writes: > A defect has been detected in the 6.5 global optimizer that you ... > Several workarounds exist to avoid the problem in the 6.5 ... Or, use gcc... -- Tor Lillqvist Technical Research Centre of Finland, Computing Services (VTT/ATK) tml@hemuli.atk.vtt.fi [130.188.52.2]