> On Feb 9, 2023, at 5:35 AM, Richard Biener <rguent...@suse.de> wrote: > > 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 routine “flexible_array_type_p” in objc/objc-act.cc is a little different from the one in middle-end:
It includes the ARRAY_TYPE in addition to RECORD_TYPE and UNION_TYPE. > > 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. Yes, I guess so. Qing > 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.
