On Aug 5, 2024, at 06:33, Martin Uecker <uec...@tugraz.at> wrote: > > Am Montag, dem 05.08.2024 um 11:50 +0200 schrieb Jakub Jelinek: >> On Mon, Aug 05, 2024 at 11:45:56AM +0200, Alejandro Colomar wrote: >>> [CC += Kees, Qing] >>> >>> Hi Joseph, >>> >>> On Sun, Aug 04, 2024 at 08:34:24PM GMT, Alejandro Colomar wrote: >>>> On Sun, Aug 04, 2024 at 08:02:25PM GMT, Martin Uecker wrote: >>>> D'oh! I screwed it. I wanted to have written this: >>>> >>>> $ cat star.c >>>> void foo(char (*a)[3][*], int (*x)[__lengthof__(*a)]); >>> >>> I think this answers your question of if we want __lengthof__ to >>> evaluate its operand if the top-level array is non-VLA but an inner >>> array is VLA. >>> >>> We clearly want it to not evaluate, because we want this __lengthof__ >>> to be a constant expression, ... >> >> But if you don't evaluate the argument, you can't handle counted_by. >> Because for counted_by you need the expression (the object on which it is >> used). > > You would not evaluate only when the size is an integer constant > expression, which would not apply to counted_by.
I still don’t feel very comfortable on the idea of applying “__lengthof__()” operator on flexible array members with “counted_by” attributes. My major concerns are: 1. I thought that the new operator “__lengthof__(expr)" might need to stick to the TYPE of the expr just as the operator sizeof (expr). Sizeof will just error when the TYPE of the expr does not include the size information (for Incomplete types including flexible array members), I expect the same behavior for the new operator “__lenghof__(expr)”. The “counted-by” attribute currently is not in the TYPE system, and we plan to add it into the TYPE system later through language standard (or an GCC extension). If that happens, then both the “sizeof” and the “__lengthof__” operators should be automatically evaluate the “size" or the “length” for the expr through its TYPE. (Just as the current VLA, its size and length already in the TYPE, therefore both “sizeof” and “__lengthof__” should evaluate VLA. however, at this time, it’s not a good idea to mess up the operator “sizeof” or the new operator “__lengthof__” with the information outside of the TYPE system. (Even though the information outside of TYPE can provide the size or length info). 2. For the purpose of PR116016 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016): add __builtin_set_counted_by(P->FAM, COUNT) or equivalent The most important functionality the kernel needs from compilers is a way to SET the counted_by field. Unless the new operator “__lengthof__” returns a LVALUE that can be assigned to, it cannot meet the requirement from kernel. However, from my understanding of the new “__lengthof__”, it will be similar as “sizeof”, will not be a Lvalue. Therefore, for PR116016, we still need a new builtin, specific for the counted_by attribute. Just my 2 cents. Qing > Martin > >
