larryh@techbook.com (Larry Hutchison) (06/21/91)
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 TECHbooksanders@verity.com (Anders Wallgren) (06/22/91)
In article <1991Jun20.182817.2292@techbook.com>, larryh@techbook (Larry Hutchison) writes: > > 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. > As someone who has been using the MPW compilers for the last three years (OK, so I'm not a _complete_ veteran, but nonetheless...), I sympathize with you, but believe me, things are much better now than they were before, both in terms of product quality and product management's attitude towards the whole thing (at least they own the source to the C compiler now - I understand that wasn't the case for pre-3.0 - Gold Hills rings a bell). I, for one, am grateful that the MPW team is speeding up their release cycles a bit, both in terms of when final versions ship and when early versions are available to those who want/need them. ETO was a _great_ idea - laurels to whoever came up with the idea. This quickening means that those who push the bleeding edges of the mac development world get newer and better tools faster. An unfortunate side effect is that more bugs either slip through unnoticed, or slip by because of time constraints. As long as these bugs aren't fatal for the majority, I don't see why they should keep the rest of us from getting what we need. I suppose the argument can be made that you toss out another round of betas rather than go production, but at some point you have to cut the process off and move on, or you get stuck doing old things when you could be doing new things, and new things are what Apple should be about. It's a classic trade-off and I think the MPW team is doing a pretty good job. I also wish a complete bug list was available, but this is just one of those catch-22 situations - if you release the complete list, your product ends up looking shaky and people won't buy it, and if you don't release the whole list, why bother at all? To be honest, I don't think people would be too upset to see the whole bug list for MPW - it's a development environment geared for professional developers and not MicroSoft Word, after all. I've suggested this many a time to people at Apple, but aside from the (way out of date) Tools Bug Stack from an ETO or so ago, nothing's come of it. I suspect that assembling such a list isn't a trivial task, technically or politically. anders
gad@eclipse.its.rpi.edu (Garance A. Drosehn) (06/22/91)
In article <1991Jun21.233510.1859@verity.com> anders@verity.com (Anders Wallgren) writes: > In article <1991Jun20.182817.2292@techbook.com>, larryh@techbook (Larry Hutchison) writes: > > > > 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. > > > > As someone who has been using the MPW compilers for the last three > years (OK, so I'm not a _complete_ veteran, but nonetheless...), I > sympathize with you, but believe me, things are much better now than > they were before, both in terms of product quality and product > management's attitude towards the whole thing (at least they own the > source to the C compiler now - I understand that wasn't the case for > pre-3.0 - Gold Hills rings a bell). > > I, for one, am grateful that the MPW team is speeding up their release > cycles a bit, both in terms of when final versions ship and when early > versions are available to those who want/need them. ETO was a _great_ > idea - laurels to whoever came up with the idea. for the initial posting: While I can also wish for the day when people are perfect and products are shipped with no software bugs, I'd say the MPW team (of late) has been doing an awfully good job. You've got a CD-ROM with a few hundred megabytes of stuff on it, and there's only a few things that you can find to complain about. If you can write as massive a set of applications with as short a list of mixups, I'll be impressed. Until then, ease up a bit. I'd also like to echo the comments of Anders. It took me quite awhile to convince myself to spend the money for ETO, but now that I've done that I must admit that it is a really nice way to handle the distributions of all these products. - - - - - - - - Garance Alistair Drosehn = gad@eclipse.its.rpi.edu ITS Systems Programmer (handles NeXT-type mail) Rensselaer Polytechnic Institute; Troy NY USA
sw@nan.co.uk (Sak Wathanasin) (06/23/91)
In article <1991Jun21.233510.1859@verity.com>, anders@verity.com (Anders Wallgren) writes: > I, for one, am grateful that the MPW team is speeding up their release > cycles a bit, both in terms of when final versions ship and when early > versions are available to those who want/need them. ETO was a _great_ > idea - laurels to whoever came up with the idea. Hear, hear! I'll be renewing my subscription to ETO. Anyone else tried out SourceBug? I think it's great: a little bit slow, but useable even as it is (I suppose having an fx helps :-). A big hand for the author. A *tiny* gripe about ETO #4: I know the CD is made up months before hand, but is it not possible to put the latest tech notes on (even into a "Last minute" folder). Neither the Feb nor April TNs are on the ETO #4 or the develop 6 CDs. Sak Wathanasin Network Analysis Limited uucp: ...!ukc!nan!sw other: sw@network-analysis-ltd.co.uk phone: (+44) 203 419996 snail: 178 Wainbody Ave South, Coventry CV3 6BX, UK
wilde@hri.com (Scott Wilde) (06/27/91)
In article <0101000D.uzlfhb@nan.co.uk>, sw@nan.co.uk (Sak Wathanasin) writes: |> |> In article <1991Jun21.233510.1859@verity.com>, anders@verity.com (Anders Wallgren) writes: |> > I, for one, am grateful that the MPW team is speeding up their release |> > cycles a bit, both in terms of when final versions ship and when early |> > versions are available to those who want/need them. ETO was a _great_ |> > idea - laurels to whoever came up with the idea. |> |> Hear, hear! I'll be renewing my subscription to ETO. |> |> Anyone else tried out SourceBug? I think it's great: a little bit slow, |> but useable even as it is (I suppose having an fx helps :-). A big hand |> for the author. |> |> Sak Wathanasin |> Network Analysis Limited |> While on the subject of SourceBug, were there supposed to be release notes? There weren't any included with my copy of ETO, and I couldn't find anything on disk. Scott Wilde wilde@hri.com