Path: utzoo!utgpu!watmath!watdragon!violet!afscian
From: afscian@violet.waterloo.edu (Anthony Scian)
Newsgroups: comp.lang.c
Subject: Re: Microsoft C 5.1 - bug
Message-ID: <13303@watdragon.waterloo.edu>
Date: 14 Apr 89 18:11:38 GMT
References: <1051@dgbt.uucp> <3758@uhccux.uhcc.hawaii.edu>
Sender: daemon@watdragon.waterloo.edu
Reply-To: afscian@violet.waterloo.edu (Anthony Scian)
Organization: U. of Waterloo, Ontario
Lines: 23

In article <3758@uhccux.uhcc.hawaii.edu> wilson@uhccux.UUCP (Tom Wilson) writes:
>In article <1051@dgbt.uucp> lew@dgbt.crc.dnd.ca (Lew Stelmach) writes:
>>The following program compiles successfully on Microsoft C5.1,
>>Microsoft Quick C 2.0, TurboC, DEC VAX Ultrix C, Sun Unix C, and other
>>compilers.  However, it does not run correctly when compiled using
>>Microsoft C5.1. Note that it runs correctly on Microsoft Quick C 2.0.
>[ Program listing and output deleted]
>1.  I ran this and confirm the bug in MSC 5.1
>2.  When I specified no compiler optimzation (/Od), the bug went away.  While
>    I don't have time to look at the object output, it looks like maybe some
>    incorrect overoptimization.
The problem is probably in the -Oa (ignore aliasing) optimization.
The 'ignore aliasing' optimzation will assume that any indirection
will not invalidate any other value that may be stored in registers
or temporaries. The 'ignore aliasing' optimization is a dangerous 
optimization to perform especially in the 'anything goes' form 
that Microsoft uses. (Turbo C has the same problem in certain cases)
Basically, -Ox is unusable because -Ox turns on this optimization.
The 'loop optimzations' switch -Ol is also dangerous because it can 
break working programs (although at a lesser rate).

//// Anthony Scian afscian@violet.uwaterloo.ca afscian@violet.waterloo.edu ////
"I can't believe the news today, I can't close my eyes and make it go away" -U2