#SAS/C 5.10 Compiler Guru
24 messages in this thread
After lots of #ifdefing of the original source, I discovered the offending
code that causes SAS/C 5.10 to crash. Try compiling the code below as "lc
sasbug" (assuming it's named sasbug.c) and the compiler will catch a guru.
I've further isolated it to the #pragma that defines BltBitMap, but I don't
know enough about what the #pragma means to understand the problem. I did
notice that the #pragma was commented out in <proto/graphics.h> in Lattice
5.04, and if I do the same with 5.10, the code does compile.
#include <exec/types.h> #include <graphics/gfxmacros.h> #include
<proto/graphics.h>
extern struct RastPort *rp;
void junk(int x0, int y0) {
BltBitMap(rp->BitMap, x0, y0, 0, 0, 0, 0, 0, 0x0c0, 0xff, 0); }
P.S. Don't try to analyze what this code fragment does, it's way way out of
context.
Well, thank you word wrap. In that last example, format it to look like
real C code: put each #include on a separate line, and put the final curly
brace on a line by itself.
Nice piece of work. Now, if only SAS will see it here, maybe we'll hear
about a 'fix'.
Yeah, I spent about an hour or so #ifdefing and recompling until I narrowed
it down to the offending piece of code. I also posted it to Usenet. I
know SAS people read the messages here on CIS and on Usenet, so I'm sure
they'll get the word.
I, for one, am fed up installing new Lattice versions, compiling, crashing
on previously "ok" code, spending lots of time running omd to find out
where the compiler has decided to change the object so it does not work
anymore , giving up, (because I like writing code, not debugging
code-generators bad code) and re-installing my previous version from a
backup. The 5.0 release disaster had almost faded into darkness when my
nice shiny $40.00 5.10 update arrived. Now when I do something like… s 0
+= ( s0->ss.x + s0->high – s1->ss.x ) the thing forgets all about the "-
s1->ss.x" part. 5.04 likes it just fine. I guess I'll wait for 5.11 and try
again. Or just give up, try to get my $40.00 back. It takes a long time
for a 30% speedup in compile/link cycles to make up for the hours I spend
messing with this thing CPR seems to have it's ususal wierdnesses included
in this version as well, has anyone experienced it blowing up if you start
pressing keys before the profile file has been read, boom! croak! die! I
mean, get real guys. It's a shame to let a system which has had much
thought given to design and usefullness to be flawed with such trivial
stuff. I just don't trust it. Too bad.
Without pointing fingers at either Amiga compiler vendor, considering the
problems reported, it makes me wonder what their beta testing process is
like. I *know* how hard it is to find good beta testers. Sometimes I think
that even if you paid them, they couldn't do a good job. Some bugs seem
obvious when you find them. 🙂 But with a compiler, as opposed to a
program that feeds on mouse events and user decisions, you can run test
suites. I'm sure both Manx and Lattice have test suites; wouldn't they have
caught these bugs in generated code? Would either Manx or Lattice's
representatives care to comment on their testing procedures?
We do extensively internal (alpha) testing, as well as outside (beta)
testing. Our internal tests consist of:
running stress-test type suites, such as Plum Hall's stuff.
recompiling _everything_ with the new compiler, including itself
(called bootstrapping).
running as much PD and shareware example code as we can find
thorugh the compiler.
Compiling files with previously fixed bugs, to insure we don't break
something we already fixed.
After that's done, we release the compiler to our beta testers, who
(hopefully) bang on it for a significant amount of time.
Despite all this, bugs _do_ slip through, for the simple reason that a
compiler system (including assembler, linker, libraries, etc.) is massively
complex, and humans are prone to errors.
I can say that the bug-rates in SAS C and Aztec C are well within 'Industry
Norms' for such things – similar numbers of bugs crop up in PC C compilers,
Mainframe compilers, etc. etc. The best we can do is to find bugs and fix
them as quickly as possible, and to do what we can to insure that products
are tested as much as possible before release.
-Mike
Thanks for the info, but I can't believe it. 5.0 had problems with any
sort of expression between the square brackets of an array reference, as I
recall… how did that one slip through? A last minute bug fix that
didn't cause the test cycle to begin again?
The bug you're referring to wasn't anywhere near as simple as you suggest –
the operators used in the expression, the types of the variables involved,
and what was on the left hand side of the expression (i.e., was it an =, a
+=, etc.) all played a part in that bug.
That is the problem with compiler bugs – there are an unbelievable number
of combinations of ways to do things. C is especially prone to compiler
bugs because the language allows people to do things in so many different
ways.
To the person who encounters a bug, it may seem like "wow this is so
obvious, how could that ever slip through". But that's not at all true –
there are literally _millions_ of different unique expressions you can come
up with in C, and it's just not feasible to sit down and test every single
one.
Try maintaining a C compiler some day, and you'll understand the size of
the problem in trying to test it.
-Mike
I *do* sympathize! In fact, I say to myself, I can't imagine the magnitude
of support needed for any language product. Be it C, Arexx, assembler,
whatever. I know you can't test every possible expression, but in my case,
I hit this one several times in existing code that I tried to compile with
5.0.
Before you ship, must the compiler pass all tests? If a bug is "fixed",
does the product re-enter the test cycle?
Except for extreme situations, the compiler must pass our internal tests
before we release it. This has ended up delaying releases (it happened
twice in 5.0d that the release was delayed as new bugs were found), but we
feel it's generally better to delay a release and ship a stable product,
then to rush it and have a potential disaster on our hands.
An example of an 'extreme' situation is the string-squishing option -ss. A
problem with it was brought to our attention rather late in the beta test
cycle, which turned out to be a fundamental flaw in the design of that
particular piece of code. We chose to stub that code out in 5.0d rather
than try to make radical design changes, so that we could release a
compiler we were confident about.
-Mike
Mike, you make a good point about how an "obvious" bug can slip through.
That's the first thing I thought when SAS crashed trying to compile a very
simple BltBitMap call. But it turns out that the bug only shows up on
68000 Amigas when one of the parameters passed is an odd constant. It works
on 020's and 030's, it works if it's even, and it works if the value is
passed in as a variable. I could easily believe that SAS's test case for
this (assuming there was one) happened to use an even constant, or a
variable.
But there's no excuse for the getcwd() example I described in a previous
message. When compiled with registerized parameters, it always returned
NULL (or maybe it was a null string) regardless of the various combinations
of input parameters I tried. It was simply never tested.
John, I have 5.10 installed and have not had any problems so far. I agree
that there should be better testing, but I also agree with Mike. We
installed Microsoft 6.0 on our 386's at work a few months ago.. Wow! bug
city! Microsoft don't blow up though, they just fire tons of "Internal
compiler error, contact Microsoft etc…" messages at you. And when you
call them, they say "try turning off the optimizer". And the code we run
through it compiled & ran fine under older versions! I think this problem
exists on other platforms, and don't think SAS or Manx are any different.
Lets see how fast these bugs are corrected now.
-Troy
I've been running MSC 6.0 for quite some time under Windows. There were a
number of things that changed, but we haven't spotted any bugs yet. Sure,
with 1.5 or 2 megs of source code, it tends to overflow its heap space, but
we switched to intermediate files on disk, and the problems disappeared.
They're right… turn off the optimizer, it will screw you every time.
With Microsoft 6, most of the time the optimizer has problems with based
pointers. Overall though, I think it's a great package. Do you use the PWB?
We don't… It's to slow, even on our 33mhz 386. We also use Windows,
however it dont like some of our code, we change the dos timer tick rate
from 18.4 to 72.8 ticks a second to get better resolution during animation.
Windows don't like this. We are doing it the "Legal" way too, we still
update DOS 18 times a sec (the code was taken from examples sent from IBM).
-Troy
Troy,
We been using PWB for a project, and although it's slower than some
programs might be, I sure wish we had a similar 'suite' on the Amiga.
Features that I like:
The 'makefile builder'….I know how to use make in its various
incantations, but automating it certainly saves me some time.
Having two sets of 'options' one for debug, one for release.
The online 'help' (although those green (on our color preferences)
triangles delimiting stuff is a bit much)
Things I don't like:
The editor (but thats a RWAR issue)
The debugger (another RWAR, and I'm hardly unbiased)
it puts money in Bill Gates' pocket
Victor A. Wagner, Jr.
I don't know what they use. I work for a publisher who puts out about 3 to
5 titles a year, granted they are not nearly as ambitious as a full blown
'c' compiler but we do not have the kind of products that you can use a
test suite on. Our stuff does have bugs but they ususally come up under
odd situations. Some of the things I see in the Amiga world ( 2.0 for
instance ) seem to have glaring problems. I mean did someone NOT run
DPaint under 2.0 before they put it out? Were they pressed for time, knew
it would not work and put it out anyway? One of the reasons I am not an
early 3000 owner is the fear of losing a lot of software. As for Lattice, (
I do not have Manx ), I was a bit severe last night, and was a bit hard on
them. I put 5.10 back on today after a night's sleep and 1/2 bag of Poore
Brothers Cajun chips and it seemed to work pretty well. Early hours after
debugging isn't a good time to try a new compiler on untested code. It's
just it kills me when I find I've spent an hour or two tearing my hair out
and it turns out to be a problem in the compiler. I'm sure Lattice takes
pride in their work and wish them well.
There's absolutely nothing Commodore could have done about Dpaint III not
working under 2.0. EA forgot a WaitBlt() somewhere, and because of that it
dies under 2.0 since certain operations are faster than they were under
1.3.
-Mike
Ok, my mistake. It's just that the Amiga is in a rather fradile place
market wise, it's going to get some stiff competition from the new Apples
and the increasing onslaught of clones. The cpu is hanging on by it's
teeth to the low end of consumer ( thanks to the impending demise of the GS
) and continues to be virtually unknown to the general public. It's
regarded by most as a super game machine with some neat graphics software.
I love it ( since 1986 ) and want to move up, I just don't want all my
software to break.
James, I have used DPaint with the A3000 without problems, and under
2.0, it is overscan that causes problems. And you made it sound like it was
Commodore's fault and they should've made 2.0 work with DPaint, as if it
were CBM's fault that Electronic Arts used bad techniques!
BTW, don't forget that the current A3000s come with both 2.0 and 1.3.
— Ethan
I'm sure SAS and Manx both have extensive test suites, but they are
probably isolated examples. For each compiler release since 4.00, all
Lattice/SAS had to do was compile my one large program (of course they
don't have it…) and then *run* it. 5.10 didn't even compile it, and on
two or three of the patches since 4.00, the program would crash when it
ran, due to no fault of mine.
Lattice definitly rushed some of their patches. In 5.04 (I think) they
added support for many library function to use registerized parameters, but
they clearly never tried running a registerized getcwd() because it
returned the wrong result. That was fixed in 5.05. I would think they
would have a test for getcwd() and all the other functions. Automated
testing of compiler libraries is so easy (compared to automated testing of
user-interface programs) that they should have been doing it long ago.
I started with Lattice 4.00 and have applied every patch and update along
the way to get me to 5.10. The 5.04 patch was the first one where I
*didn't* encounter a bug that made old code break (on a rather large
project). One big reason I stayed with Lattice was the excellent support
on their BBS. Whenever I had a problem, all I had to do was check the BBS
and there was usually a work-around already available. If not, I would
post my problem and a work-around would appear in a day or two, and the
problem was fixed in the next free patch.
I'm concerned that without the BBS, SAS will not live up to my needs. I
posted the bug about the BltBitMap #pragma problem here and on Usenet.
After about a week, I got a response from SAS on Usenet saying it was a
known bug and vaguely suggesting a work-around. I also got mail from a SAS
user who had also encountered the problem and presented a more specific
work-around. The turn-around time to ask electronic questions just ain't
there, and I refuse to waste my time on the phone during the day when I
need to be working at my real job (nothing worse than listening to "music
on hold" while your boss is at the door asking why you missed the 2:00
deadline).
That's an added feature to SAS C 5.1 – they now accept more arguments for
registerized calling (like the #pragma stuff allows) of functions.
BltBitMap had too many params to work with a #pragma in previous versions,
which is why that line was commented out.
Now that you mention it, I see that's why they had it commented out prior
to 5.10. Of course, one wonders if it really does work. I don't know
whether the #pragma for BltBitMap is incorrect, or if the feature doesn't
work (I suspect the specific #pragma is hosed).