Am Montag, dem 05.08.2024 um 20:10 +0000 schrieb Qing Zhao: > 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).
I agree with this. I would also much prefer to see a proper language extension, we should not really be any harder to implement than "counted_by" itself. Martin > > 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
