Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ulowell!vaxine!mjw
From: mjw@vaxine.UUCP (Mike Wilt)
Newsgroups: comp.os.minix
Subject: Re: Turbo C 1.5 Revisited...
Message-ID: <955@vaxine.UUCP>
Date: 28 Apr 89 15:17:17 GMT
References: <4105@crash.cts.com>
Reply-To: mjw@vaxine.cs.ulowell.edu (Mike Wilt)
Organization: Automatix Inc.,  Billerica, MA
Lines: 27

In article <4105@crash.cts.com> jca@pnet01.cts.com (John C. Archambeau) writes:
>I have found the problem with it and it turns out to be a nasty bug in the
>object code generator for switch statements.  If you compile with the -S
>option, the assembly code looks perfectly legal (it probably is), but if you
>take a debugger to the generated code for fsck.c, it turns out that the switch
>code does not match that (operand wise) to the assembly code.
> 
[more stuff]

I isolated that bug and sent a complete description to Borland.  They said
they couldn't reproduce it.  I didn't feel like sending them the entire source
to my program, so I let it go.  It is apparently a problem with the way the
assembler-end of the compiler generates code.  It was making a tight loop to
test some of the cases, and the jump-back instruction was pointing one
instruction after the test.  The result is that it runs the loop without
actually testing anything.  Inside the loop, there was a JNE followed by JMP.
The assembler code generated by the -S option had JE.  I believe the assembler
pass at the back end of the compiler substituted JNE+JMP without correcting
the offset from the end of the loop back to the beginning.  It was easy to make
this bug disappear, because rearranging the cases would move branches between
the loop tests and the jump table.

It was not in 1.0x, it appeared in 1.5, and it may be gone in 2.0.  I assume
their tech support guys didn't know about it, at least not when I was trying
to report it.

Mike