https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107952
--- Comment #18 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Qing Zhao from comment #15) > > On Jan 25, 2023, at 11:12 AM, siddhesh at gcc dot gnu.org > > <gcc-bugzi...@gcc.gnu.org> wrote: > >> > >>> The first is handled by the function just fine, > >> > >> No, even the first case is not recognized by the current > >> “array_ref_flexible_size_p”, it’s not been identified as a flexible array > >> right now. > >> Shall we include this case into “array_ref_flexible_size_p”? (It’s a GCC > >> extension). > > > > In the first case, array_ref_flexible_size_p recognizes S2.flex.data as > > having > > flexible size. The tests in my patch[1] for this bug checks for this. > Oh, yes. That’s right. > > > > However, array_ref_flexible_size_p does not recognize S2.flex as having > > flexible size. It might make sense to support that, i.e. any struct or > > union > > with the last element as a flex array should be recognized as having > > flexible > > size. > > Since S2.flex is not an “array_ref”, it’s correct for > array_ref_fleixble_size_p to return false for it, I think. Yes, that's correct. The routine is supposed to answer if an actual _access_ is to a flexible size part. The whole aggregate is not part of a flexible size part here. tree-object-size usually wants to know if a pointer points to an object with flexible size which is really something different and might not share much with the logic in array_ref_fleixble_size_p
