ADA V3.5 on ALPHA platform

ADA V3.5 on ALPHA platform

[Adrian Birkett]

I have posted this on the VMS newsgroup but I thought you guys may like
to be made aware of it.

----------------------------------

Here's one for Compaq product engineering if ever I saw one!!

Without going into great detail, I don't think that the ADA product for
Alpha works properly.

Consider the function:

 begin

  I := INTEGER'VALUE ("-");

  TEXT_IO.PUT_LINE ("INTEGER'VALUE (""-"") returns " & INTEGER'IMAGE
(I));

 exception
  when others =>
   TEXT_IO.PUT_LINE ("INTEGER'VALUE (""-"") raises an exception");

 end;

On a VAX running ADA 3.5-1 under VMS 7.1, the above code raises the
exception condition as you would expect since the "-" is not numeric.

On an Alpha running ADA 3.5-2 (EV6 patch on ES40) the above code sets
the variable I to ZERO and doesn't raise the exception. This can have
some serious repercussions if you are developing 'mission critical'
applications - as is the wont of ADA programmers. You would also have to

consider array boundaries and the like.

Also, the supplied libraries for 3.5 Alpha are the same as those for 3.4

Alpha (checked LIB_.ADC text version) but the VAX ones show several
changes between the versions. The Alpha libraries also contain modules
which have been renamed from their VAX equivalents (some SMG routines)
not to mention the fact that some routines in the VAX version have been
omitted from the Alpha version (eg GET_HOSTNAME in LIB_.ADC).

Has anybody else noticed this?

This may have already been raised with Compaq. I just thought that
others may like to be made aware of the problem.

Does anybody have any further comments?

Regards,

Ade

-- Everybody is entitled to my own opinion --

Re: ADA V3.5 on ALPHA platform

[Gautier]

Wow! Your bug runs nice (DEC Ada 3.5-2)...

%ACS-I-CL_LINKING, Invoking the OpenVMS Linker for OPENVMS_AXP target
$ ru bug
INTEGER'VALUE ("-") returns  0

There is another one, very strange: in my multi-precision library,
there is a constant boolean (DEBUG) that cause testings on multi-numbers,
only with a call to a Test function with an `in' parametre. It is
algorithmically neutral.

With DEBUG=true or no `suppress_all' pragma, the decimals of pi
(Test_int.adb) are calculated correctly. With DEBUG=false and
suppress_all on, the decimals of Pi are not calculated correctly at all
(instead of 1000 decimals, you obtain numbers like -172348687, which
is a slightly inaccurate approximation...). 

You can test it using
  http://members.xoom.com/gnatlist/multi002.zip

I suspect the optimizer... (case signaled to Compaq).

Otherwise I find DEC Ada an excellent compiler (at least
in terms of efficiency!)

-- 
Gautier

_____\\________________\_______\
http://members.xoom.com/gdemont/