Re: [Patch] Fortran: Avoid SAVE_EXPR for deferred-len char types

[Tobias Burnus <tobias@codesourcery.com>]

On 20.02.23 11:41, Richard Biener wrote:
> 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.

For VLA-kind of variables, SAVE_EXPR makes sense
(code wise: if '!deferred') - and that use in gfortran
should remain unchanged.


However, Fortran also has deferred-length variables where one has:

character(len=:), pointer :: str
! ...
allocate(character(len=42) :: str)
!...
end


which has the dump:

   integer(kind=8) .str;
   character(kind=1)[1:.str] * str;

   str = (character(kind=1)[1:.str] *) __builtin_malloc (42);
   .str = 42;

The length variable is - a bit oddly - linked to the
data variable its TREE_TYPE - i.e. via the upper bound for
the domain / TYPE_SIZE / TYPE_SIZE_UNIT.

Currently, it happens that the SAVE_EXPR is used, e.g.
   size = D.1234;  // which D.1234 is the SAVE_EXPR
instead of the current value
   size = .str;
which leads to wrong results. As '.str' is an aritificial
variable, the issue of a user modifying the value does not exist.

* * *

As mentioned in the TODO for 'deferred', I think we really want
to have NULL as upper value for the domain for the type, but that
requires literally hundred of changes to the compiler, which
I do not want to due during Stage 4, but that are eventually
required.* — In any case, this patch fixes some of the issues
in the meanwhile.

Tobias

* The number of deferred-length bugs is really huge; especially when
used with derived types.

-----------------
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