On 17.02.23 17:27, Steve Kargl wrote:
On Fri, Feb 17, 2023 at 12:13:52PM +0100, Tobias Burnus wrote:
OK for mainline?
Short version: no.
Would you mind to write a reasoning beyond only a single word?
subroutine foo(n)
integer :: n
integer :: array(n*5)
integer :: my_len
...
my_len = 5
block
character(len=my_len, kind=4) :: str
my_len = 99
print *, len(str) ! still shows 5 - not 99
end block
end
Are you sure about the above comment?
Yes - for three reasons:
* On the what-feels-right side: It does not make any sense to print
any other value than 5 given that 'str' has been declared with len = 5.
* On the GCC side, the SAVE_EXPR ensures that the length is evaluated
early and then "saved" to ensure its original value is available
* The quoted text from the standard implies that this is what
should happen.
Why do you think that printing "5" is wrong? GCC does so since
years; it still does so with my patch.
Hence, can you elaborate? And also state which value you did expect instead?
* * *
The patch itself is about *deferred* length parameters, i.e.
'len=:', and thus for code like:
character(len=:), pointer :: str
...
allocate(character(len=4) :: str)
print *, len(str) ! should print 4
...
allocate(character(len=99) :: str)
print *, len(str) ! should now print 99
...
Currently, the SAVE_EXPR causes that the original value might
get used, which is often 0 (by chance 0 initialized) or some
random value like 57385973, depending what on what was on the
stack before. - There are more issues with deferred strings,
but at least one is solved by not having a SAVE_EXPR for
deferred-length character strings.
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
