Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!hplabs!hp-sdd!ncr-sd!crash!pnet01!jca
From: jca@pnet01.cts.com (John C. Archambeau)
Newsgroups: comp.os.minix
Subject: Re: Turbo C 1.5 Revisited...
Message-ID: <4162@crash.cts.com>
Date: 7 May 89 22:16:12 GMT
Sender: news@crash.cts.com
Organization: People-Net [pnet01], El Cajon CA
Lines: 49

mjw@vaxine.UUCP (Mike Wilt) writes:
>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


Would you mind telling us (especially me), how you corrected this bug?  I have
taken a good look at the code after calling Borland and this bug just doesn't
exist.  I have dumped both the -S generated code and have cranked the .obj
code through D86 and listed it to printer.  Everything is kosher.  My guess is
that A86 isn't doing something correctly or build.c has an error in it.  Right
now I'm just plain stuck on what to do about this problem and everything is
pretty much halted until I resolve this problem (and I have a 10 MB partition
waiting for Minix 1.3).  I figure it this way, if the people who have written
the Turbo C 1.5 articles have done it, then the bug is not in the compiler and
the only patch for Turbo C 1.5 is for the library module initgraph.  The only
other common denominator is the fact that I'm not using MASM which might be
botching up the cs register when I go to link up the A86 code and Turbo C
code.
 
 JCA

UUCP: {nosc ucsd hplabs!hp-sdd}!crash!pnet01!jca
ARPA: crash!pnet01!jca@nosc.mil
INET: jca@pnet01.cts.com