On Wed, 8 Feb 2023, Qing Zhao wrote: > > > > On Feb 7, 2023, at 6:37 PM, Joseph Myers <jos...@codesourcery.com> wrote: > > > > On Tue, 7 Feb 2023, Qing Zhao via Gcc-patches wrote: > > > >> Then, this routine (flexible_array_type_p) is mainly for diagnostic > >> purpose. > >> It cannot be used to determine whether the structure/union type recursively > >> include a flexible array member at the end. > >> > >> Is my understanding correct? > > > > My comments were about basic principles of what gets diagnosed, and the > > need for different predicates in different contexts; I wasn't trying to > > assert anything about how that maps onto what functions should be used in > > what contexts. > Okay. > > But I noticed that “flexible_array_type_p” later was moved from FE to > middle-end and put into tree.cc, tree.h as a general utility routine, and to > > /* Determine whether TYPE is a structure with a flexible array member, > or a union containing such a structure (possibly recursively). */ > > However, since this routine does not cover the cases when the structure > with flexible array member was recursively embedded into structures, (which > we > agreed that it should be considered as a flexible sized type). > > Therefore, I feel that It might not be proper to include this routine in > middle end > (and actually no other places In middle end use this routine so far). > > That’s the reason I asked the previous question. > > It might be better to move the routine “flexible_array_type_p” back from > middle-end to > FE for the diagnosis purpose only.
It's always dangerous to move functions with such a descriptive name to a place where it suggests wider use is applicable. Also since objc/objc-act.cc has a function with the same name (if that had same content before r10-5097-g4569f8b3652ae1 then the function should have been moved to c-family/ instead). The only "middle-end" use, btw., is in ./config/nios2/nios2.cc, intoduced by said revision and your points probably mean this change was misguided and flexible_array_type_p isn't the thing to fix here. flexible-size _objects_ are clearly denoted by DECL_SIZE being non-constant - though the case of .sdata is quite odd and the issue fixed is probably running into a bug elsewhere ... Sandra? Thanks, Richard.
