Wierdness in SCO 386 'cc' -O option
Robert J Woodhead
trebor at biar.UUCP
Mon Mar 13 10:54:59 AEST 1989
Ran into a wierd problem this weekend when I tried to use the -Ox compiler
option. Previously, I was using -O, which optimizes for speed. -Ox
does this, plus 'Reduces restrictions on aliases' (?), 'eliminates common
subexpressions' and 'loop optimizations'.
Consider the following fragment, from a project I am writing (no "you
could write this easier", this was actually one of the first 'c' programs
I ever wrote, being a pascaholic, etc, etc):
i=0;
i=i || ( (c1=='U') && (c2=='I') );
i=i || ( (c1=='A') && (c2=='C') );
i=i || ( (c1=='B') && (c2=='I') );
i=i || ( (c1=='C') && (c2=='H') );
i=i || ( (c1=='A') && (c2=='L') );
i=i || ( (c1=='L') && (c2=='O') );
i=i || ( (c1=='X') && (c2=='B') );
The meaning is clear; if c1&c2 are UI, AC, BI, CH, AL, LO or XB, i
should be set to TRUE (nonzero). If not, FALSE (zero).
And, when compiled with the -O option, this is the case. It works
fine. But when compiled with -Ox it breaks. It returns TRUE no
matter what c1 and c2 are!
This is with SCO Xenix System V 2.2.4 for the Tandy 4000.
I assume there is a middling chance that the problem is a subtle (or
not so subtle) point about C and logical expressions that I have
missed, but either way, I'd like to know what's going on so I don't
go through the agonizing trackdown process again.
--
* Robert J Woodhead * The true meaning of life is cunningly encrypted and *
* uunet!biar!trebor * hidden somewhere in this signature... *
* Biar Games, Inc. * ...no, go back and look again *
More information about the Comp.unix.xenix
mailing list