| I'm testing a proposed compiler now. Our test system takes a few days.
(My system disk went "south", and wasn't being backed up. 8-{)
I then plan to update the various notes and IPMT cases with the solution,
once its well tested.
We also have another user problem which may compete for this ECO kit.
We may need to discuss whether your customer needs a one-off of what
I have now (once its tested!) if I need to postpone the ECO to include
this other problem.
Sorry about the lack of status, we have been working on this issue.
Charlie
|
| I have taken over the responsibility for the support of ADA from
Ren�, and herewith also the responsibility for this problem. And
I already got a complain from the customer. He wants to know what's
going on. The problem is now pending for allmost 4 month and he is
getting tired to find workarounds for the bugs in the V3.2 compiler
just because he cannot use V3.3 (his words).
So, when does the ECO kit become available you promised in the
previous reply? (he would need the Alpha variant of the kit)
Even if you cannot tell me a final date, please let me know the
current state and a estimated time frame.
Thanks in advance
Edwin
|
| This text describes changes to the OpenVMS Alpha V3.3 ECO compiler
concerning exported subprogram's passing mechanisms for string data.
A series of customer problem reports have made changes and
clarification necessary.
The fix described below will be in an Ada ECO kit, ADAAE23033,
which is currently being processed for ECO submission. Look for an
announcement in note stream 3644.*, or contact me directly if you
need an early kit.
This change affects exported subprograms only on DEC Ada on OpenVMS
Alpha only. This memo will also document what the new behavior will
be for a variety of situations.
History of this issue:
1. DEC Ada V3.0 used VAX Descriptors for passing string data in
exported subprograms, which conforms to the VMS calling
standard.
2. DEC Ada V3.2 changed to use dope vectors (different format,
internal to DEC Ada format) to pass string data. This was
for several reasons, including efficiency, and support of
array indexes with 64 bit integer types (descriptors can not
be used for this case).
3. IPMT HPAQ73436, Ada note 3602. User reported
problems with V3.2, exporting an Ada subprogram and calling
it from Fortran. Fortran passes a VAX Descriptor, and Ada
used it as if it were a dope vector. Program got an access
violation, because Fortran did not understand dope vectors.
4. DEC Ada V3.3 was changed, intending to return to the V3.0
behavior, to use VAX descriptors for exported subprograms.
This change fixed IPMT HPAQ73436, but made the importing and
exporting of an Ada subprogram use different passing
mechanisms (importing Ada subprograms default to dope vectors
unless an explicit passing mechanism is given).
5. IMPT ZUO100962, Ada note 3784. User had problems with V3.3
change for HPAQ73436.
Ada engineering answered that the new behavior is was
expected, explained why, and gave recommended source changes.
6. Ada note 3819. Same user reports problem with variant record
and CONSTRAINT_ERROR. They had changed their source, due to
Ada's answer for IPMT ZUO100962, specifying "default" to
pragma interface, instead of "ada". This does not pass
information on the constrainedness of in-out and out record
parameters.
DEC Ada V3.3 ECO for OpenVMS Alpha will return to the V3.2 behavior.
Dope vectors will be the default for exported Ada subprograms without
pragmas detailing what parameter's passing mechanism should be.
Note that subprograms explicitly giving passing mechanisms in pragmas
will get the mechanisms specified in the pragma. That will not be
changed by this compiler change.
Users exporting Ada subprograms to non-Ada languages with string data
may again need to specify passing mechanisms of descriptors for use
with other subprograms not written in Ada:
pragma export_procedure( ...
mechanism => DESCRIPTOR (class => <class_name>))
See the Language Reference Manual, section 13.9a.1.4 for more
information.
Alternatively, a new compiler switch can be used:
/EXPORT_INTERFACE = { ADA | FORTRAN | DEFAULT }
which will specify a preferred language interface for exported
subprograms as is done with the INTERFACE pragma for imported
subprograms. This compiler qualifier will be in effect for all
exported subprograms in a compilation unless a specific pragma is
given with a passing mechanism.
o ADA will specify to use the dope vector passing mechanism.
o FORTRAN or DEFAULT will specify the descriptor passing
mechanism.
|
| The customer has reported a problem which he is shure that it occures since he
is using this ECO kit. I have found reports in this conference to such problems
which are said to be fixed in V3.2. Could it be that this fix got lost for the
ECO?
In the log below, for the first message (NOTORIGSRC) he is almost shure that
this has occured before and should therefore not be the reason for the problem.
BADBODPACK and the following NOSEGLIST however is new.
Any ideas?
Edwin
--------------------------------------------------------------------------------
OpenVMS Alpha DEBUG Version V6.2-100
%DEBUG-I-INITIAL, language is ADA, module set to TEST_ET_BEDIENUNGS_BUFFER
%DEBUG-I-NOTATMAIN, type GO to get to start of main program
%DEBUG-W-SCRNOSRCLIN, no source line for address 00449930 for display in Source
View
DBG> go
%DEBUG-I-NOTORIGSRC, original version of source file not found
file used is
SCRATCH_DISK_1:[VE.WORK.LOCAL_ACS._003]TEST_ET_BEDIENUNGS_BUFFER.ADC;12
break at routine TEST_ET_BEDIENUNGS_BUFFER
DBG> SET BREAK ILET_ET_BEDIENUNGS_BUFFER.%LINE 760
DBG> go
break at
ILET_ET_BEDIENUNGS_BUFFER\J_BUFFER$TASK_BODY.BLOCK$666.SUBMIT_BEDIENUNG.
BEDIEN_BLOCK.BLOCK$701.%LINE 760 in %TASK 10
DBG> step/in
%DEBUG-I-DYNMODSET, setting module ILET_ET_BEDIENUNGS_BUFFER_.BEDIENSTEU__6
%DEBUG-I-BADBODPACK, incorrect package spec name in body-spec
ILET_ET_BEDIENUNGS_BUFFER_,
module ILET_ET_BEDIENUNGS_BUFFER_.BEDIENSTEU__6
%DEBUG-F-NOSEGLIST, the debugger detected an error when trying to access a
source display
segment in routine DBG$MUI_ADD_NEW_MODULE.
Logging enabled - this is being written to log file DBGERR.LOG
The following information may be helpful to the DEBUG maintainers.
If you wish to report this problem please include:
o The stack dump that follows.
o The debugger version number.
o The program being debugged, both source and image.
o The last, if not all, commands entered to the debugger.
o Any other information that may be helpful.
The version of the debugger is: OpenVMS Alpha DEBUG Version V6.2-100
Due to this internal error this debugging session may be unreliable.
%DEBUG-F-NOSEGLIST, the debugger detected an error when trying to access a
source display
segment in routine DBG$MUI_REMAP_MODULE.
stepped to ILET_ET_BEDIENUNGS_BUFFER_.BEDIENSTEU.SEND_BEDIENUNG.%LINE 2969+72 in
%TASK 10
%DEBUG-W-NOLINXXX, line 2969 does not exist in module
ILET_ET_BEDIENUNGS_BUFFER_.BEDIENSTEU__6
DBG>
|