Invalid code generation with dynamic commons

[lpoujoulat]

We are using dynamic commons to map shared memory between processes in order to emulate VAX shared commons. We ran into a weird problem where all the RECORD in a given common overlaps at the begining of the common allocated memory. Digging in that, we have found that the compiler was not generating correct offsets for the RECORDs in the common, althougth the offsets for all scalars are correct. If we remove the dynamic option in the compiler parameter. All is OK.

I have attached a dissassembly of the code with the corresponding source. If all was correct, we should have a 4 bytes offset in the calculated location of the TRK record.

We have workaround this by grouping all the commons field in a single record that encapsulates the original records and scalars of the commons. This is OK, but we have a lot of work to handle this as all variable access have to be changed (and our code is pretty big)

Do you know any solution to this ?

[Steven_L_Intel1]

An extract of assembly code is not helpful in diagnosing the problem. If you would like the issue investigated, file a report with Intel Premier Support and attach a ZIP of the project with everything needed to build and reproduce the problem.

Let me also suggest that dynamic common is not the best substitute for VMS shared commons and was not intended for that purpose. In fact, you can get pretty much the same VMS behavior with DLLEXPORTed COMMONs when the DLL is linked to specify read-write sharing. An example of using a DLL to share data between processes is provided as "DLLDLL_Shared_Data".

[lpoujoulat]

Thanks for your quick answer. As you suggest we will post this problem in the premier support. Anyway the attached listing contains also with the assembly, the full source code (20 lines) and all the compilation options, so I don't see what is missing to reproduce the problem ...

Using the DLL sharing is not possible in our case because the shared memory we use is allocated in Windows shared memory by our framework and we want not to change this.

[jimdempseyatthecove]

lpoujoulat,

Assuming the results of your encapsulation requires a change in your program to

temp = CAPSULE%VARIABLE * 2.0

and you do not want to find and edit all references to the common variable, you might find it appropriate to have the Fortran PreProcessor perform the edits as part of the compilation. Steps

Step 1:

In the user type that defines VARIABLE change the case. Example: Variable
The shared common data is instantiated with the CAPSULE containing the re-cased variables

Step 2:

Create an include file for the Fortran preprocessor to use,such as CAPSULE.INC, containing the replacement macros. Example: #define VARIABLE CAPSULE%Variable

Step 3:

In your code source files add a Fortran preprocessor directive to include the new header.
#include 'CAPSULE.INC'
Note, add this towards the top of the file. The auto-edit changes become effective from the #include to the end of the file and are not limited to a scoping unit.

Step 4:

Change your project files to specify the compilation is to use the Fortran Preprocessor

The advantage of this is: Except for the addition of the #include statement(s) there is no change to your source code
The disadvantageof this is: When debugging you will need to pre-pend the capsule name to examine the variable.

Jim Dempsey

[lpoujoulat]

Thanks for the tip, it may helps. Anyway, we have submitted the problem to premier support with a minimal project to reproduce the problem

Regards
Laurent Poujoulat