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
