Hi all, I expect, that in our special case, the alignment problems cannot cause problems, because all is Fortran INTEGER and therefore at least 4-byte-aligned. With intentionally misaligned handles, the new derived type handle seems to work better (but not worse) than integer handles. I've attached a small test code to solve the question, whether - INTEGER and - TYPE handle; SEQUENCE INTEGER :: val; END TYPE handle is passed to a C back-end in the same way. Does it produce the expected results on all compilers: IBM (several compilers) Cray (ditto?) NAG Fortran Intel gfortran Oracle/Sun Pathscale Portland Group Possibly g95 I checked with Intel: cc -c handle_test_c.c ifort -o handle_test handle_test.f90 handle_test_c.o fortcom: Warning: handle_test.f90, line 42: The structure contains one or more misaligned fields. [SEQUENCE_A] TYPE sequence_A -------^ fortcom: Warning: handle_test.f90, line 49: The structure contains one or more misaligned fields. [SEQUENCE_B] TYPE sequence_B -------^ ./handle_test hd_1 = 12, hd_2 = 13 (expected: 12, 13) hd_i=112, hd_t%val=113 (expected: 112, 113) hd_1 = 14, hd_2 = 15 (expected: 14, 15) strA%handle=114, strB%handle%val=115 (expected: 114, 115) hd_1 = 24, hd_2 = 75 (expected: 25, 75) strA%handle=225, seqB%handle%val=775 (expected: 225, 775) handle_test(12868): unaligned access to 0x600000000000cf29, ip=0x4000000000003530 hd_1 = 84, hd_2 = 35 (expected: 84, 35) handle_test(12868): unaligned access to 0x600000000000cf29, ip=0x4000000000003571 seqA%handle=884, strB%handle%val=335 (expected: 884, 335) handle_test(12868): unaligned access to 0x600000000000cf29, ip=0x4000000000003530 hd_1 = 94, hd_2 = 95 (expected: 94, 95) handle_test(12868): unaligned access to 0x600000000000cf29, ip=0x4000000000003571 seqA%handle=994, seqB%handle%val=995 (expected: 994, 995) Result: All works, but there is really a small difference: - With misaligned INTEGER handle seqA, some runtime warnings occur - With new derive-type handle seqB, **NO** runtime warnings occur It would be helpful, if you can check with some other compilers. If you find another alignment problem with some other tests for exactly these two types (no other derived types), then please can you report. The test program should test, whether internally the Fortran compiler produces a subroutine call with an argument list for both handle types that fits to the same C back-end: int*. Rolf ----- "N.M. Maclaren" <[email protected]> wrote:
Sorry. Posted in haste, and I forgot a critical paragraph.
With those structures, also try seeing what they do when you remove each of 'x' and 'y' in turn. Specifically, does 'z' continue to be in the same location?
In the SPECIFIC example of a single default integer in a sequence type, it will a rare compiler that lays it out differently. But all of the INTEGER, INTEGER BIND(C), sequence type and derived type without the SEQUENCE may have different sizes and alignments. And, on SOME systems, a pointer to one of those may not be usable as a pointer to another.
_______________________________________________ mpi3-fortran mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran
-- Dr. Rolf Rabenseifner . . . . . . . . . .. email [email protected] High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)