On Mon, Feb 20, 2023 at 11:05 AM Tobias Burnus <tob...@codesourcery.com> wrote: > > 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
Generally SAVE_EXPR is used to make sure an expression is only evaluated once. It's DECL_EXPR that ensures something is evaluated early and available. So generally "unwrapping" a SAVE_EXPR looks dangerous to me unless the SAVE_EXPR is really never necessary. Richard. > * 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
