achim wrote:
>
> Hi Eirik,
>
> the difference is very simple: all VACPP builds from IBM that have been
> released so far have been compiled without any optimizations. The reason
> for that is that once the optimizer is enabled, the binaries don't work
> anymore. Clearly bugs with the 3.6.5 optimizer. In order to solve this,
> IBM has to selectively enable all single optimizer features until they
> find the one that generates bad code. So they have plenty of optimizations
> left, just need to invest the time to find working settings.
Does this happen also with 3.6.5 fixpak 2? Here is the list of fixes in
the Fixpak 2 released 21. Dec. 2000.
DEFECT PROBLEM DESCRIPTION Fixpak 2
----------------------------------------------------------------------------
139319 Trap in _uheap_check()
145447 _threadstore() not exported
154155 /O+ causes an internal compiler error
159627 /O+ corrupts a variable being passed.
163298 Problem encountered when compiling with -O
165010 ICE when compiling with /O+
> Maybe someone from outside is willing to play with the /O* settings
> of VACPP?
>
> Also, gcc is supposed to have the better optimizer, especially pgcc
> and egcs but they currenctly generate corrupt binaries, too.
I did some tests a while ago. I used stepanov and oopack test.
(ftp://ftp.kai.com/pub/benchmarks/).
VACPP 4.0 generated quite a lot faster code than 3.6.5 and pgcc.
I also remember that vacpp 3.6.5 generated an awful code for the
stepanov
without /qarch=pentium2 (or maybe qtune?). Code generated with just /O
parameter was three times slower.
