Dear all, hello Harald,
On 12.10.21 22:50, Harald Anlauf wrote:
while working on a fix for PR102685, I encountered issues with the testsuite.
...
(1) gfortran.dg/derived_constructor_char_1.f90
The constructor is shorter than the array component txt in DT t5.
Commit r0-101989.
@Tobias: can you comment?
Simply change 'txt(4)' to 'txt(2)'.
(2) gfortran.dg/pr70931.f90
Committed by Richard Biener, fixing an ICE on an invalid testcase by Gerhard.
I think we safely can mark this one as invalid and emit an error, right?
No - we still want to check the bug fix in gcc/dwarf2out.c's
native_encode_initializer,
i.e.
- if (val
+ if (val && fieldsize != 0
I think you should just change:
+ type(t), parameter :: z = t(1, [2])
to ... = t(1, [])
(3) gfortran.dg/transfer_simplify_2.f90
The constructor has more elements than the array component in the DT and is
invalid.
Commit r0-80854.
We had already before:
"Fixed invalid initialization" and "Fixed invalid array constructor."
for that file. Thus, changing it again to fix a bug is fine :-)
That looks like a combined pasto + thinko. In
subroutine dt_to_integer1
real, parameter :: r1(4) = (/1.0_4,2.0_4,3.0_4,4.0_4/)
type :: mytype
integer(4) :: i(4)
real(4) :: x(4)
end type mytype
and in the next one:
subroutine character16_to_dt
character(16), parameter :: c1 = "abcdefghijklmnop"
character(16) :: c2 = c1
type :: mytype
real(4) :: x(2)
end type mytype
type (mytype), parameter :: dt1(2) = transfer (c1, mytype
((/1.0,2.0,3.0,4.0/)), 2)
...
if (any (dt1(1)%x .ne. dt2(1)%x)) STOP 12
if (any (dt1(2)%x .ne. dt2(2)%x)) STOP 13
end subroutine character16_to_dt
I think you can simply remove the ',3.0, 4.0' in the 'dt1' line.
Along these lines, I think we should always reject code having too many elements
in a constructor. Is there agreement on this? This would need fixing case (3).
Is there a reason to accept cases where the constructor is shorter than the
array
component in the DT? Some extension? Shall we give a warning for these cases
instead of an error? Based on -std flags?
At the moment I do not see any good reason for having
too many or too few elements. Also the testsuite use
indicates rather bugs and not intentional use.
Thus, I would simply give an error in either case.
I think that also matches the behavior of other
compilers such as ifort but I have not tested it.
(I think you alluded that you did test it with ifort
and it gave errors for both too long and too short
array constructors.)
I would change the testcases as mentioned, but maybe
it makes sense to add the invalid use in the new
testcase as some might exercise some corner cases
(size = 0, ...)?
As you had "derived_constructor_char_1.f90" in the list:
Having ["abc", "a", "ab cdefg"] is also invalid – as either the
strings have to be changed (space-padded on the right) to have
the same length or a typespec as in
[ character(len=<n>) :: "....", ".." ]
has to be used. But I can see that it easily can happen that the
strings are of different length and the user then expects that
the compiler handles it correctly™, especially before the
typespec was permitted. (GCC attempts to do this, including
warnings/errors in that case.)
But for array elements, it seems to be unlikely that there is
size mismatch on purpose or by accidentally expecting that
the compiler corrects this.
Any constructive comment appreciated!
I wonder why you are only interested in constructive ones ... ;-)
Thanks,
Tobias
-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
