Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!rice!uw-beaver!zephyr.ens.tek.com!tektronix!percy!qiclab!techbook!larryh From: larryh@techbook.com (Larry Hutchison) Newsgroups: comp.sys.mac.programmer Subject: MPW Bugs and other complaints Message-ID: <1991Jun20.182817.2292@techbook.com> Date: 20 Jun 91 18:28:17 GMT Reply-To: larryh@techbook.com (Larry Hutchison) Organization: TECHbooks - Beaverton, Oregon - Public Access Unix Lines: 152 When I received ETO #4 yesterday and saw MPW C 3.2 final, I was anxious to see if the two bugs I had reported many months ago had been fixed. To make a long and frustrating story short only one of the two had been fixed AND at least one new bug had been introduced since 3.2b6. It is then with great restraint that I make the following meek statement: Gee, I wish Apple would fix the bugs in their darn compilers. Further, I wish they would not release "final" versions containing known outstanding code generation bugs. Even yet further, I wish that COMPLETE bug lists were readily available. I apologize in advance for this outburst. But while I am at it, why must the assembler persist in putting out bogus warning messages like the following? # 144: XDPoint PROC EXPORT ### Warning 216 ### If last BRA.S to import is to next instruction, BAD CODE will be generated (add nop) File "hd:MPW:IgorSrc:Igor2:compmisc.a"; line 144 Is it too much to ask that they fix either the code generator or the warning condition detector? (The condition mentioned in the warning does not apply in my code) As penance for this outburst, I am including the text of the two Outside Bug Reporter submissions that apply to MPW 3.2 C final. I would like to encourage all csmp groupies to provide a cc of their bug reports to this group. ***************************************** Bug #1 (reported 12/31/90 for MPW C 3.1,3.2b3; still there in 3.2 final): ***************************************** The following source code... /* * test.c */ int foo(double value); void bar(int index); static int quiet; static void foobar( extended theVal) { foo(theVal); if(quiet) return; bar(123); } results in the following incorrect obj code: 00000000: 4E56 0000 'NV..' LINK A6,#$0000 00000004: F227 E080 '.'..' FMOVEM FP7,-(A7) 00000008: F22E 4B80 0008 '..K...' FMOVE.X $0008(A6),FP7 0000000E: F227 6B80 '.'k.' FMOVE.X FP7,-(A7) 00000012: 4EBA 0000 'N...' JSR foo ; id: 4 00000016: 4AAD 0000 'J...' TST.L quiet ; id: 5 0000001A: 6608 'f.' BNE.S *+$000A ; 00000024 0000001C: 707B 'p{' MOVEQ #$7B,D0 ; '{' 0000001E: 2F00 '/.' MOVE.L D0,-(A7) 00000020: 4EBA 0000 'N...' JSR bar ; id: 3 00000024: 4FEF 0010 'O...' LEA $0010(A7),A7 00000028: F21F D001 '....' FMOVEM (A7)+,FP7 0000002C: 4E5E 'N^' UNLK A6 0000002E: 4E75 'Nu' RTS The error above is in the stack cleanup when the branch at 1A is taken. The cleanup code at 24 is used for both branches but is appropriate only if the branch is NOT taken. Changing foobar's parameter to double results in correct code. MPW 3.2B3 produces similar results. C test.c -elems881 DumpObj test.c.o -m foobar > tmp ***************************************** Bug #2(reported 6/20/91 for MPW C 3.2 final): ***************************************** Here is a line of code from a moderately complex function: }while(lop != TERMOP && !(special & ( (psymb==')') & (Top()==0) ))); And here is the correct code as produced by the 3.2b6 compiler: MOVEQ #$18,D0 CMP.L lop,D0 ; id: 16 BEQ.S *+$0028 ; 00000142 MOVEQ #$29,D0 ; ')' CMP.L D7,D0 SEQ D0 NEG.B D0 MOVE.L D0,-(A7) JSR Top ; id: 14 MOVE.L D0,D1 MOVE.L (A7)+,D0 TST.L D1 SEQ D1 NEG.B D1 AND.B D0,D1 MOVEQ #$00,D0 MOVE.B D1,D0 TST.L D0 AND.L D5,D0 BEQ *-$0092 ; 000000AC And here is the difference between the b6 compiler (tmp1) and the "final" compiler (tmp2). Nonmatching lines (File "hd:tmp1"; Line 116:120; File "hd:tmp2"; Line 117:119) 116 MOVE.L D0,-(A7) 117 JSR Top ; id: 14 118 MOVE.L D0,D1 119 MOVE.L (A7)+,D0 120 TST.L D1 117 MOVE.L D0,-$000C(A6) 118 JSR Top ; id: 14 119 MOVE.L -$000C(A6),D0 Note that the "final" compiler trashes the return value from Top(). Flags: -r -elems881 -mc68020 -mbg full -opt off had no effect If desired, I could try to provide a self contained module that would reproduce the bug. The bug is probably caused by the register starved environment and I might need some tips on how to easily generate such a condition. ***************************************** end of bug list Larry Hutchinson WaveMetrics@AppleLink.Apple.COM or... -- larryh@techbook.COM ...!{tektronix!nosun,uunet}techbook!larryh Public Access UNIX at (503) 644-8135 (1200/2400) Voice: +1 503 646-8257 Public Access User --- Not affiliated with TECHbooks