Hi Qing, On Mon, Aug 05, 2024 at 10:41:43PM GMT, Martin Uecker wrote: > 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)”.
Let's be cautious, and start by having an error on FAMs in the first implementation. We can discuss support for attributes in a later iteration. So, I agree. > > > > 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. I'm curious; how do you plan to make counted_by as part of the type system? I've read the paper for using a .identifier length designator (n3188; <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3188.htm>), but that's a constant, and doesn't use an attribute. > > > > 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). Okay. > 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, No; it won't be an lvalue; and the approach with an lvalue gives you a way to both read and write in a single feature, so it's quite nice. ;) > > 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. Yep. > > > > Therefore, for PR116016, we still need a new builtin, specific for > > the counted_by attribute. Yep. Have a lovely night! Alex -- <https://www.alejandro-colomar.es/>
signature.asc
Description: PGP signature
