J3/03-222 Date: 04 August 2003 To: J3 From: Van Snyder Subject: Subgroup response to papers N1558, N1559 and N1565 Re: WG5/N1566 1 August 2003 ISO/IEC JTC1/SC22/WG5 N1566 Van Snyder Subgroup response to papers N1558, N1559 and N1565 Subgroup studied paper N1558 and the commentaries on it in N1559 and N1565. Concerning part I, subgroup decided that there are no new substantial performance problems. There may be minor performance penalties in the case that arrays have the same shape, but these decline in relative importance as array size increases. The relationship between loop fusion or jamming, and allocatable array assignment, is not changed by automatic reallocation in the case of differing shapes. That is, processors could not generate fused loops for consecutive assignments without seeing the ALLOCATE statements and being able to analyze them in Fortran 95, and providing for automatic reallocation in the case of differing shapes does not make that analysis either easier or more difficult. Providing for automatic reallocation in the case of differing shapes does not introduce semantic differences into Fortran 95 programs. If a program has differing shapes of allocatable arrays on the two sides of an intrinsic assignment it does not conform to the Fortran 95 standard, and if the shapes are conformant, the current draft requires that the processor _shall_not_ deallocate and reallocate the left-hand side, so the program would continue to have the same meaning as in Fortran 95. Subgroup concluded that no new semantic difficulties are introduced by providing for automatic reallocation in the case of differing shapes. If the shapes are different, the assignment is nonsense unless the left-hand side is deallocated and reallocated. If the draft did not provide for automatic reallocation in the case of differing shapes, it would make no sense other than to require the shapes to conform, in which case the program would have no choice but to do explicitly what the current draft requires the processor to do. Subgroup could not determine exactly what concerned Kurt in part II. We followed Aleksandar Donev's advice in N1559 and asked Malcolm to study the question. Malcolm found no new issue. Concerning part III, subgroup agreed with Alaksandar Donev that it is hopeless to define the value of an object completely. Although 4.5.7 was revised at the recent joint meeting, subgroup does not agree that the status quo ante was better. Concerning part IV, subgroup agreed with Richard Maine's observation in N1565 that function side effects are not new. Fortran programmers have already learnt how to arrange programs so that function references that cause side effects necessary to the correct operation of their programs are sure to be executed if the expression containing the reference is evaluated. The semantics of C functions do not change anything in this respect.