https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98228
Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot
gnu.org
Status|NEW |ASSIGNED
CC|ebotcazou at gcc dot gnu.org |
--- Comment #16 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> # High-level flow of the resulting crashes:
>
> - the procedure sem_type__get_next_interp has an output parameter of
> record type sem_type__interp and overwrites that completely.
> - in locations that call sem_type__get_next_interp, local variables of
> type sem_type__interp get wrapped by maybe_pad_type in an outer
> padding record for proper alignment. the padding record has a single
> field "F" for the inner record.
> - on s390x, that field gets falsely flagged as nonaddressable (see
> zoom-in below).
> - as a consequence of that flag, type based alias analysis does not
> relate the padded record to the alias set of the inner record.
> - modref_may_conflict disambiguates references to the local variables
> (padded record) from sem_type__get_next_interp actually overwriting
> the (inner) record -- "correct" decision based on the data, but
> clearly the wrong result.
> - as a result, loops that iterate via sem_type__get_next_interp are
> "optimized" into endless loops, because their abort condition is
> never checked against the updated data.
> - these loops overrun All_Interp.Table and trigger assertions or
> segfault (i've seen both).
Thanks for the detailed investigation. The effect of nonaddressability on
alias sets is as expected, but it is invalid to take the address of a
nonaddressable field of course.
