#C COMPILER
10 messages in this thread
Well, at least until V6.51 the SAS compiler optimizer has several serious
problems. At least I have to use NOOPTGO NOOPTPEEP switches in order to get a
working program. I had several bugs in the final program with the optimizer
switch on. I have tried V6.55 and so far it now seems to work. But I haven't
finished testing V6.55 yet. From my experience, switching the compiler version
without serious testing is VERY dangerous. In the past the SAS compiler always
had some problems with the optimizer causing crashes in the compiled program.
As far as the GNU <-> SAS war goes, I agree the GNU optimizer is very good.
However, it really depends on the style of your program and the kind of
programs you write. At least in my case the optimizer doesn't do much of a
job… but things can be different…
Hi,
I refered to an article in 'Amiga Magazin' and they stated the SAS optimiser
works OK. But then, what is test in a magazine worth today?!?
Jochen Antesberger from Neuburg a.d. Donau – Bavaria/Germany
Titanic – Hindenburg – Challenger – Intel Pentium … what comes NeXT?
Magazines? Oh well, the question is, can you expect a reviewer to run standard
compiler tests? I think this makes a differences between a good and a bad
compiler review. But than, it seems to be impossible to find such reviews.
But I agree, the bugs in the compiler optimizer are hard to find and I usualy
get 3-4 bugs after compiling my Studio software with a new compiler (several MB
source code). Very often the bugs don't show up that easily (they don't always
result in crashes… often they trash the stack or memory for later suprises
;-). The early 6 and 6.5/6.51 versions do have serious problems. But as said, I
didn't had a bug yet with 6.55 but more testing has to be done with the GO.
(PS: one example – the small PNG gfx format library source here on CIS doesn't
compile right with the 6.51 GO but works fine with 6.55).
>Magazines? Oh well, the question is, can you expect a reviewer to run standard
>compiler tests? I think this makes a differences between a good and a bad
>compiler review. But than, it seems to be impossible to find such reviews.
I agree with this. But then again, in some ways and practicality
"standard compiler tests" is not straightforward, if it even has meaning.
It could potentially put at least one line in the sand though which would be
better than what we usually get. The mags suffer many serious problems,
and if they at least had a semi-goal, and were to state it, it would be
something 🙁
>But I agree, the bugs in the compiler optimizer are hard to find …
>(PS: one example – the small PNG gfx format library source here on CIS
>doesn't compile right with the 6.51 GO but works fine with 6.55).
It's also true that bugs in apps are sometimes hard to find.
How do you know it was not a bug in the lib source?
Ok in this one case if indeed you did track it and/or verify it
was indeed bad code generated, but you do not say. That something
works with optimization off and doesn't work with it on does not
exclusively mean that the optimizer is the sole culprit, just yet
another worm in the can. I have labelled this kind of situation
“good garbage''. (I suspect that you do have explicit GO details
in some of these cases though.)
How did I find out it's a bug in the optmizer? In this case simple: The library
works with NOOPTGO and it doesn't work with the optimizer. And the program
works with OPTGO and the SAS 6.55 compiler. Regarding the library. Yes, the PNG
library had a bug but this is something I found after testing and has been
reported to the author. I would never include a library in my software without
heavy testing… as I would never switch compiler versions without several
weeks testing…
When it comes to the other bugs I found in the optmizer: I traced them and
reported them…. In one case it took me a week to find the bug in the 6.51
peephole optimizer (gmrbl). Sometimes they said it's not a bug in SAS/C… but
in the end I was always right 😉 (simply luck…).
>How did I find out it's a bug in the optmizer? In this case simple: The library
>works with NOOPTGO and it doesn't work with the optimizer. And the program
>works with OPTGO and the SAS 6.55 compiler.
Although that might indicate to me that the optimizer should be on my list
of things to check out, even if consistent I'd hardly conclude from that
alone that the bug was in the optimizer. Given you mention heavy testing etc
neither did you.
Greg, I agree. I didn't conclude that that the Optimizer does cause the problem
just because the optimizer switch doesn't work… At least in one case it was
the linker…
But when I said I did heavy testing in some cases (as said, it took me weeks in
total), I surely did more than simply switching the optimizer feature on and
off. It drove me crazy…
Lucky you, I cannot get SAS 6.5 in the uk 🙁
Phill
Of course you can: the update to 6.55 is here on CIS. Or do you mean a new
package?
I only have SAS 6.3 at the moment, so I can't upgrade to 6.55 yet 🙁
Phill