Re: [PATCH v2] C, ObjC: Add -Wunterminated-string-initialization

Hi David, Sorry for the half-year delay! I have some update. :) On Fri, Mar 24, 2023 at 10:53:22AM -0400, David Malcolm wrote: > On Fri, 2023-03-24 at 14:39 +0100, Alejandro Colomar via Gcc-patches > wrote: > > Warn about the following: > > > >     char  s[3] = "

Re: [PATCH v2] C, ObjC: Add -Wunterminated-string-initialization

On Sun, Oct 01, 2023 at 09:37:59AM +0200, Martin Uecker wrote: > > (I shortened the recipient list) > > Am Sonntag, dem 01.10.2023 um 02:55 +0200 schrieb Alejandro Colomar: > > > > > ... > > I ran the tests, and get some unexpected failure. I used dg-warni

[PATCH v3] C, ObjC: Add -Wunterminated-string-initialization

From: Alejandro Colomar Warn about the following: char s[3] = "foo"; Initializing a char array with a string literal of the same length as the size of the array is usually a mistake. Rarely is the case where one wants to create a non-terminated character sequence from a stri

[PATCH v4] C, ObjC: Add -Wunterminated-string-initialization

ists.gnu.org/archive/html/groff/2022-11/msg00063.html> Link: <https://inbox.sourceware.org/gcc/36da94eb-1cac-5ae8-7fea-ec66160cf...@gmail.com/T/> Acked-by: Doug McIlroy Cc: "G. Branden Robinson" Cc: Ralph Corderoy Cc: Dave Kemper Cc: Larry McVoy Cc: Andrew Pinski Cc: Jonatha

[PATCH v5] C, ObjC: Add -Wunterminated-string-initialization

roy Cc: "G. Branden Robinson" Cc: Ralph Corderoy Cc: Dave Kemper Cc: Larry McVoy Cc: Andrew Pinski Cc: Jonathan Wakely Cc: Andrew Clayton Cc: Martin Uecker Cc: David Malcolm Signed-off-by: Alejandro Colomar --- v5: - Fix existing C++-compat tests. [reported by ] gcc/c

Ping: [PATCH v5] C, ObjC: Add -Wunterminated-string-initialization

Hi, Gentle ping here. Thanks, Alex On Sun, Oct 01, 2023 at 06:24:00PM +0200, Alejandro Colomar wrote: > Warn about the following: > > char s[3] = "foo"; > > Initializing a char array with a string literal of the same length as > the size of the array is usual

[PATCH v6] C, ObjC: Add -Wunterminated-string-initialization

roy Cc: "G. Branden Robinson" Cc: Ralph Corderoy Cc: Dave Kemper Cc: Larry McVoy Cc: Andrew Pinski Cc: Jonathan Wakely Cc: Andrew Clayton Cc: Martin Uecker Cc: David Malcolm Cc: Mike Stump Cc: Joseph Myers Cc: Sandra Loosemore Signed-off-by: Alejandro Colomar --- Hi! v6: - S

Re: [PATCH v6] C, ObjC: Add -Wunterminated-string-initialization

On Tue, Mar 05, 2024 at 09:20:42PM +0100, Alejandro Colomar wrote: > Hi! > > v6: > - Small wording fix in c.opt > - Document the option in invoke.texi > > I tried again, but didn't find much alphabetic order in there, so put > it where Mike suggested, after

[PATCH v7] C, ObjC: Add -Wunterminated-string-initialization

roy Cc: "G. Branden Robinson" Cc: Ralph Corderoy Cc: Dave Kemper Cc: Larry McVoy Cc: Andrew Pinski Cc: Jonathan Wakely Cc: Andrew Clayton Cc: Martin Uecker Cc: David Malcolm Cc: Mike Stump Cc: Joseph Myers Cc: Sandra Loosemore Signed-off-by: Alejandro Colomar --- Range-diff agains

[PATCH v8] C, ObjC: Add -Wunterminated-string-initialization

: Andrew Pinski Cc: Jonathan Wakely Cc: Andrew Clayton Cc: Martin Uecker Cc: David Malcolm Cc: Mike Stump Cc: Joseph Myers Signed-off-by: Alejandro Colomar --- Hi! I've added a changelog to the commit message, as requested by Sandra, and noted her review. Have a lovely day! Alex

[PATCH v5 RESEND] C, ObjC: Add -Wunterminated-string-initialization

roy Cc: "G. Branden Robinson" Cc: Ralph Corderoy Cc: Dave Kemper Cc: Larry McVoy Cc: Andrew Pinski Cc: Jonathan Wakely Cc: Andrew Clayton Cc: Martin Uecker Cc: David Malcolm Signed-off-by: Alejandro Colomar --- v5: - Fix existing C++-compat tests. [reported by ] gcc/c

Re: [PATCH v5 RESEND] C, ObjC: Add -Wunterminated-string-initialization

Hi Mike, Joseph, On Sun, Feb 25, 2024 at 10:10:09AM -0800, Mike Stump wrote: > On Feb 6, 2024, at 2:45 AM, Alejandro Colomar wrote: > > > > Warn about the following: > > > >char s[3] = "foo"; > > No ObjC specific impact here, so no need for

Re: [PATCH v5 RESEND] C, ObjC: Add -Wunterminated-string-initialization

Hi Joseph, On Mon, Feb 26, 2024 at 03:24:32PM +, Joseph Myers wrote: > On Sun, 25 Feb 2024, Mike Stump wrote: > > > On Feb 6, 2024, at 2:45 AM, Alejandro Colomar wrote: > > > > > > Warn about the following: > > > > > >char s[3] = &qu

Re: [PATCH v5] C, ObjC: Add -Wunterminated-string-initialization

Hi, Gentle ping, just again a little before v14 stage 3. Do I need to do anything else with this patch? The CI seemed to say it's ok. Cheers, Alex On Sun, Oct 01, 2023 at 06:24:00PM +0200, Alejandro Colomar wrote: > Warn about the following: > > char s[3] = "foo&qu

[PATCH v9] C, ObjC: Add -Wunterminated-string-initialization

Cc: "G. Branden Robinson" Cc: Ralph Corderoy Cc: Dave Kemper Cc: Larry McVoy Cc: Andrew Pinski Cc: Jonathan Wakely Cc: Andrew Clayton Cc: David Malcolm Cc: Mike Stump Cc: Joseph Myers Cc: Konstantin Kharlamov Signed-off-by: Alejandro Colomar --- Hi! Here's another roun

Re: [PATCH v9] C, ObjC: Add -Wunterminated-string-initialization

On Sat, Jun 29, 2024 at 02:52:40PM GMT, Alejandro Colomar wrote: > Warn about the following: > > char s[3] = "foo"; > > Initializing a char array with a string literal of the same length as > the size of the array is usually a mistake. Rarely is the case where

Re: [PATCH v9] C, ObjC: Add -Wunterminated-string-initialization

On Sat, Jun 29, 2024 at 02:58:48PM GMT, Alejandro Colomar wrote: > On Sat, Jun 29, 2024 at 02:52:40PM GMT, Alejandro Colomar wrote: > > @@ -6450,6 +6452,8 @@ name is still supported, but the newer name is more > > descriptive.) > > -Wstring-compare > > -Wtype-

[PATCH v10] C, ObjC: Add -Wunterminated-string-initialization

-by: Martin Uecker Cc: "G. Branden Robinson" Cc: Ralph Corderoy Cc: Dave Kemper Cc: Larry McVoy Cc: Andrew Pinski Cc: Jonathan Wakely Cc: Andrew Clayton Cc: David Malcolm Cc: Joseph Myers Cc: Konstantin Kharlamov Signed-off-by: Alejandro Colomar --- Hi! v10 changes: - Fix a

[PATCH] doc: Document -fasm as the opposite of -fno-asm

gcc/ChangeLog: * doc/invoke.texi: Document -fasm. Signed-off-by: Alejandro Colomar --- gcc/doc/invoke.texi | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi index 30c4b002d1f..2d55f2715b3 100644 --- a/gcc/doc/invoke.texi

Re: [PATCH] doc: Document -fasm as the opposite of -fno-asm

On Mon, Jul 01, 2024 at 12:40:45PM GMT, Jakub Jelinek wrote: > On Mon, Jul 01, 2024 at 11:37:40AM +0200, Alejandro Colomar wrote: > > gcc/ChangeLog: > > > > * doc/invoke.texi: Document -fasm. > > Why? We have almost 1300 options which accept the negative forms >

Re: [COMMITTED] Regenerate c.opt.urls

Hi Mark, On Wed, Jul 17, 2024 at 06:07:20PM GMT, Mark Wielaard wrote: > > diff --git a/gcc/c-family/c.opt.urls b/gcc/c-family/c.opt.urls > > index 1b60ae4847b..df5f58a1eee 100644 > > --- a/gcc/c-family/c.opt.urls > > +++ b/gcc/c-family/c.opt.urls > > @@ -870,6 +870,9 @@ > > UrlSuffix(gcc/Warning-

Re: [PATCH v8] C, ObjC: Add -Wunterminated-string-initialization

Ping. I see that GCC-14 has been released recently. This is a gentle ping to see if this is a better time for this patch. Have a lovely day! Alex signature.asc Description: PGP signature

Re: [PATCH v5 3/3] c: Add __lengthof__ operator

Hello Jens, On Thu, Aug 08, 2024 at 07:35:12AM GMT, Jₑₙₛ Gustedt wrote: > Hello Alejandro, > > On Thu, 8 Aug 2024 00:44:02 +0200, Alejandro Colomar wrote: > > > +Its syntax is similar to @code{sizeof}. > > For my curiosity, do you also make the same distinction that wi

Re: [PATCH v5 3/3] c: Add __lengthof__ operator

Hi Martin, On Thu, Aug 08, 2024 at 09:39:59AM GMT, Martin Uecker wrote: > > $ /opt/local/gnu/gcc/lengthof/bin/gcc zero.c > > zero.c:18:12: error: variably modified ‘Z’ at file scope > >18 | static int Z[__lengthof__(Y)]; > > |^ > > > > > > See that D, which

Re: [PATCH v5 3/3] c: Add __lengthof__ operator

Hi Jens, On Thu, Aug 08, 2024 at 11:13:02AM GMT, Jens Gustedt wrote: > > but to maintain expectations, I think it would be better to do > > the same here. > > Just to compare, the recent additions in C23 typeof etc. only have the > parenthesized versions. So there would be precedent. And it reall

Re: [PATCH v5 3/3] c: Add __lengthof__ operator

On Thu, Aug 08, 2024 at 11:23:51AM GMT, Martin Uecker wrote: > > Not really. 'zero' is only true for [0] and for [*], but nor for > > [zero], right? > > > > All vla tests seem to pass if I remove that line. The only issue will > > be that > > > > void f(char (*a)[*], int (*x)[__lengthof__

Re: [PATCH v5 3/3] c: Add __lengthof__ operator

Hi Martin, Jens, Joseph, On Thu, Aug 08, 2024 at 06:30:42PM GMT, Martin Uecker wrote: > Am Donnerstag, dem 08.08.2024 um 18:23 +0200 schrieb Jens Gustedt: > > As said, even if we don't consider this problematic because we are used to > > the mildly complex case distinction that you just exposed o

Re: [PATCH v5 3/3] c: Add __lengthof__ operator

Hi Joseph, On Thu, Aug 08, 2024 at 05:31:05PM GMT, Joseph Myers wrote: > On Thu, 8 Aug 2024, Alejandro Colomar wrote: > > > How about having __lengthof__ behave like sizeof, but deprecate it in > > sizeof too? > > Deprecation would be a matter for WG14. Yep; I wouldn&

Re: [PATCH v5 3/3] c: Add __lengthof__ operator

Hi Martin, On Thu, Aug 08, 2024 at 08:16:50PM GMT, Martin Uecker wrote: > > It will serve me as a huge test suite anyway; so it's worth it even if > > just for myself. And it will uncover bugs. :) > > Did you implement a C++ version? Or are you talking about the C parts > of the code. I'll sta

Re: [PATCH v5 3/3] c: Add __lengthof__ operator

Hi Joseph, On Thu, Aug 08, 2024 at 05:31:05PM GMT, Joseph Myers wrote: > Actual bugs should of course be fixed. Here are the suspects: ./gcc/testsuite/gcc.target/powerpc/sse3-addsubps.c:80: for (i = 0; i < sizeof (vals) / sizeof (vals); i += 8) ./gcc/c-family/c-pragma.cc:1811:

Re: [PATCH v5 3/3] c: Add __lengthof__ operator

On Thu, Aug 08, 2024 at 08:36:36PM GMT, Joseph Myers wrote: > On Thu, 8 Aug 2024, Alejandro Colomar wrote: > > > Here are the suspects: > > > > ./gcc/testsuite/gcc.target/powerpc/sse3-addsubps.c:80: > > for (i = 0; i < sizeof (vals) / sizeof (vals);

Internal Compiler Error (was: [PATCH v5 0/3] c: Add __lengthof__ operator)

Hi! While running `make check -j24`, I've seen an internal compiler error. I've tried to reproduce it, but it only triggered once that time. This is the only log I've been able to collect. I hope it helps. lto1: internal compiler error: in lto_read_decls, at lto/lto-common.cc:1970

[PATCH v6 0/3] c: Add __lengthof__ operator

't been able to reproduce consistently. However, they are in parts of the repository that are unrelated to my changes, so I suspect those are problems that existed before my patches. (I've reported the ICE in an earlier subthread of this thread.) Have a lovely day! Alex Alejandro Colomar (

[PATCH v6 1/3] gcc/: Rename array_type_nelts() => array_type_nelts_minus_one()

_linear_ctor): Likewise. gcc/rust/ChangeLog: * backend/rust-tree.cc (array_type_nelts_top): Rename array_type_nelts() => array_type_nelts_minus_one() Suggested-by: Richard Biener Signed-off-by: Alejandro Colomar --- gcc/c/c-decl.cc | 10 +-

[PATCH v6 3/3] c: Add __lengthof__ operator

Romero Co-developed-by: Martin Uecker Signed-off-by: Alejandro Colomar --- gcc/c-family/c-common.cc| 26 gcc/c-family/c-common.def | 3 + gcc/c-family/c-common.h | 2 + gcc/c/c-decl.cc | 20 +++- gcc/c/c-parser.cc

[PATCH v6 2/3] Merge definitions of array_type_nelts_top()

geLog: * backend/rust-tree.h (array_type_nelts_top): * backend/rust-tree.cc (array_type_nelts_top): Remove function. Signed-off-by: Alejandro Colomar --- gcc/cp/cp-tree.h | 1 - gcc/cp/tree.cc| 13 - gcc/rust/backend/rust-tree.cc | 13 -

Re: [PATCH v6 3/3] c: Add __lengthof__ operator

On Fri, Aug 09, 2024 at 03:59:19PM GMT, Alejandro Colomar wrote: > This operator is similar to sizeof but can only be applied to an array, > and returns its length (number of elements). > > FUTURE DIRECTIONS: > > - We should make it work with array parameters to functions

[PATCH v7 0/3] c: Add __lengthof__ operator

Hi! v7: - Tests: - Fix 2 tests (whitespace fix). - Fix typo in comment. Alejandro Colomar (3): gcc/: Rename array_type_nelts() => array_type_nelts_minus_one() Merge definitions of array_type_nelts_top() c: Add __lengthof__ operator gcc/c-family/c-common.cc|

[PATCH v7 1/3] gcc/: Rename array_type_nelts() => array_type_nelts_minus_one()

_linear_ctor): Likewise. gcc/rust/ChangeLog: * backend/rust-tree.cc (array_type_nelts_top): Rename array_type_nelts() => array_type_nelts_minus_one() Suggested-by: Richard Biener Signed-off-by: Alejandro Colomar --- gcc/c/c-decl.cc | 10 +-

[PATCH v7 3/3] c: Add __lengthof__ operator

Romero Co-developed-by: Martin Uecker Signed-off-by: Alejandro Colomar --- gcc/c-family/c-common.cc| 26 gcc/c-family/c-common.def | 3 + gcc/c-family/c-common.h | 2 + gcc/c/c-decl.cc | 20 +++- gcc/c/c-parser.cc

[PATCH v7 2/3] Merge definitions of array_type_nelts_top()

geLog: * backend/rust-tree.h (array_type_nelts_top): * backend/rust-tree.cc (array_type_nelts_top): Remove function. Signed-off-by: Alejandro Colomar --- gcc/cp/cp-tree.h | 1 - gcc/cp/tree.cc| 13 - gcc/rust/backend/rust-tree.cc | 13 -

[PATCH v8 0/3] c: Add __lengthof__ operator

ve a lovely night! Alex Alejandro Colomar (3): gcc/: Rename array_type_nelts() => array_type_nelts_minus_one() Merge definitions of array_type_nelts_top() c: Add __lengthof__ operator gcc/c-family/c-common.cc| 26 gcc/c-family/c-common.def | 3 +

[PATCH v8 2/3] Merge definitions of array_type_nelts_top()

geLog: * backend/rust-tree.h (array_type_nelts_top): * backend/rust-tree.cc (array_type_nelts_top): Remove function. Signed-off-by: Alejandro Colomar --- gcc/cp/cp-tree.h | 1 - gcc/cp/tree.cc| 13 - gcc/rust/backend/rust-tree.cc

[PATCH v8 1/3] gcc/: Rename array_type_nelts() => array_type_nelts_minus_one()

loc_comps): (gfc_omp_clause_linear_ctor): Rename array_type_nelts() => array_type_nelts_minus_one() gcc/rust/ChangeLog: * backend/rust-tree.cc (array_type_nelts_top): Rename array_type_nelts() => array_type_nelts_minus_one() Suggested-by: Richard Biener Signed-off-by: Alejandro Colo

[PATCH v8 3/3] c: Add __lengthof__ operator

/llvm-project/issues/102836 Suggested-by: Xavier Del Campo Romero Co-developed-by: Martin Uecker Signed-off-by: Alejandro Colomar --- gcc/c-family/c-common.cc| 26 gcc/c-family/c-common.def | 3 + gcc/c-family/c-common.h | 2 + gcc/c/c-decl.cc

[WG14] Request for document number; _Lengthof

Hi David, I want to send an updated version of n2529. The original author didn't respond to my mail, so I'll take over. I've been preparing a GCC patch set for adding the feature to GCC, and have informed Clang developers about it too. The title would be _Lengthof - New pointer-proof keywo

Re: [committed] testsuite: Fix up sse3-addsubps.c

Hi Jakub, On Sat, Aug 10, 2024 at 10:57:25AM GMT, Jakub Jelinek wrote: > This is an obvious typo as can be seen in what the test does, what similar > tests committed in the same commit do (all the others use sizeof (vals) / > sizeof (vals[0])) and what the test originates from (i386/sse3-addsubps.

Re: [WG14] Request for document number; _Lengthof

On Tue, Aug 13, 2024 at 01:34:58AM GMT, Alejandro Colomar wrote: > Hi David, I obviously meant Daniel. :-) > > I want to send an updated version of n2529. The original author didn't > respond to my mail, so I'll take over. I've been preparing a GCC patch > set

v2.1 Draft for a lengthof paper

Hi, On Tue, Aug 13, 2024 at 01:34:58AM GMT, Alejandro Colomar wrote: > I want to send an updated version of n2529. The original author didn't > respond to my mail, so I'll take over. I've been preparing a GCC patch > set for adding the feature to GCC, and have informed

Re: v2.1 Draft for a lengthof paper

Hi Xavier, On Wed, Aug 14, 2024 at 12:38:53AM GMT, Xavier Del Campo Romero wrote: > I have been overseeing these last emails - Ahhh, good to know; thanks! :) > thank you very much for your > efforts, Alex! :-) > I did not reply until now because I do not have prior > experience with gcc inter

Re: v2.1 Draft for a lengthof paper

Hi Jens, Martin, On Wed, Aug 14, 2024 at 08:11:20AM GMT, Jens Gustedt wrote: > > Checking , I see that while several > > projects have a lengthof() macro, all of them use it with semantics > > compatible with this keyword, so it shouldn't break too much. Maybe > > t

Re: v2.1 Draft for a lengthof paper

Hi Aaron, Jens, On Wed, Aug 14, 2024 at 02:17:52PM GMT, Jens Gustedt wrote: > Am 14. August 2024 13:31:19 MESZ schrieb "Ballman, Aaron" > : > > Sorry for top-posting, my work account is stuck on Outlook. :-/ > > > > > For a WG14 paper you should add these findings to support that choice. > > > A

Re: v2.1 Draft for a lengthof paper

Hi Aaron, On Wed, Aug 14, 2024 at 12:40:41PM GMT, Ballman, Aaron wrote: > > We should not impose an implementation in the language where doing > > it in a header can be completely sufficient. > > But can doing this in a header be completely sufficient in practice? > e.g., the user who passes a po

Re: v2.1 Draft for a lengthof paper

Hi Aaron, On Wed, Aug 14, 2024 at 01:21:18PM GMT, Ballman, Aaron wrote: > > What regex did you use for searching? > > I went cheap and easy rather than trying to narrow down: > https://sourcegraph.com/search?q=context:global+lang:C+lengthof&patternType=regexp&sm=0 Ahh, context:global seems to be

Re: v2.1 Draft for a lengthof paper

Hi Martin, On Wed, Aug 14, 2024 at 03:50:00PM GMT, Martin Uecker wrote: > An operator that returns an array with all dimensions of a multi-dimensional > array would make a a lot of sense to me. > > > double array[4][3][2]; > > // array_dims(array) = (constexpr size_t[3]){ 4, 3, 2 } And what i

Re: v2.1 Draft for a lengthof paper

Hi Aaron, On Wed, Aug 14, 2024 at 01:59:58PM GMT, Ballman, Aaron wrote: > > Why would you be looping? lengthof only addresses the outer dimension > > sizeof would need a loop, no ? > > Due to poor reading comprehension, I missed in the paper that lengthof > works on the outer dimension. 😉 I thin

Re: v2.1 Draft for a lengthof paper

On Wed, Aug 14, 2024 at 03:50:21PM GMT, Jens Gustedt wrote: > > > > > > > > That said, I suspect WG14 would not be keen on standardizing > > > > `lengthof` without an ugly keyword given that there are plenty of other > > > > uses of it that would break: > > > > > > > > https://sourcegraph.com/g

Re: v2.1 Draft for a lengthof paper

Hi Aaron, On Wed, Aug 14, 2024 at 02:07:16PM GMT, Ballman, Aaron wrote: > > Ahh, context:global seems to be what I wanted. Where is that documented? > > For me it is the default when I go to https://sourcegraph.com/search but > there's documentation at > https://sourcegraph.com/docs/code-searc

[PATCH v9 0/3] c: Add __elementsof__ operator

- Cc: += Daniel, A., Eugene, Aaron, Paul I'll send as a reply the updated draft for a WG14 C2y proposal incorporating these changes. As usual, below is a range diff against v8. Have a lovely day! Alex Alejandro Colomar (3): gcc/: Rename array_type_nelts() => array_type_nelts_minus_

[PATCH v9 1/3] gcc/: Rename array_type_nelts() => array_type_nelts_minus_one()

loc_comps): (gfc_omp_clause_linear_ctor): Rename array_type_nelts() => array_type_nelts_minus_one() gcc/rust/ChangeLog: * backend/rust-tree.cc (array_type_nelts_top): Rename array_type_nelts() => array_type_nelts_minus_one() Suggested-by: Richard Biener Signed-off-by: Alejandro Colo

[PATCH v9 2/3] Merge definitions of array_type_nelts_top()

geLog: * backend/rust-tree.h (array_type_nelts_top): * backend/rust-tree.cc (array_type_nelts_top): Remove function. Signed-off-by: Alejandro Colomar --- gcc/cp/cp-tree.h | 1 - gcc/cp/tree.cc| 13 - gcc/rust/backend/rust-tree.cc

[PATCH v9 3/3] c: Add __elementsof__ operator

2/wg14/www/docs/n2529.pdf Link: https://inbox.sourceware.org/gcc/m8s4oqy--...@tutanota.com/T/ Link: https://github.com/llvm/llvm-project/issues/102836 Suggested-by: Xavier Del Campo Romero Co-developed-by: Martin Uecker Signed-off-by: Alejandro Colomar --- gcc/c-family/c-common.cc

[PATCH v10 0/3] c: Add __nelementsof__ operator

en some informal ones, but I prefer to pick them from explicit ones. Have a lovely day! Alex Alejandro Colomar (3): gcc/: Rename array_type_nelts() => array_type_nelts_minus_one() Merge definitions of array_type_nelts_top() c: Add __nelementsof__ operator gcc/c-family/c-common.cc

[PATCH v10 1/3] gcc/: Rename array_type_nelts() => array_type_nelts_minus_one()

loc_comps): (gfc_omp_clause_linear_ctor): Rename array_type_nelts() => array_type_nelts_minus_one() gcc/rust/ChangeLog: * backend/rust-tree.cc (array_type_nelts_top): Rename array_type_nelts() => array_type_nelts_minus_one() Suggested-by: Richard Biener Signed-off-by: Alejandro Colo

[PATCH v10 3/3] c: Add __nelementsof__ operator

om/T/ Link: https://github.com/llvm/llvm-project/issues/102836 Suggested-by: Xavier Del Campo Romero Co-developed-by: Martin Uecker Signed-off-by: Alejandro Colomar --- gcc/c-family/c-common.cc | 26 gcc/c-family/c-common.def | 3 + gcc/c-family/

[PATCH v10 2/3] Merge definitions of array_type_nelts_top()

geLog: * backend/rust-tree.h (array_type_nelts_top): * backend/rust-tree.cc (array_type_nelts_top): Remove function. Signed-off-by: Alejandro Colomar --- gcc/cp/cp-tree.h | 1 - gcc/cp/tree.cc| 13 - gcc/rust/backend/rust-tree.cc

Re: [PATCH v10 1/3] gcc/: Rename array_type_nelts() => array_type_nelts_minus_one()

Hi Jason, On Mon, Aug 19, 2024 at 12:46:13PM GMT, Jason Merrill wrote: > On 8/19/24 6:58 AM, Alejandro Colomar wrote: > > > > Link: > > https://inbox.sourceware.org/gcc-patches/9fffd80-dca-2c7e-14b-6c9b509a7...@redhat.com/T/#m2f661c67c8f7b2c405c8c7fc3152dd85dc729120 &

[PATCH v11 0/4] c: Add __nelementsof__ operator

range-diff against v10. Have a lovely day! Alex Alejandro Colomar (4): contrib/: Add support for Cc: and Link: tags gcc/: Rename array_type_nelts() => array_type_nelts_minus_one() Merge definitions of array_type_nelts_top() c: Add __nelementsof__ operator contrib/gcc-changelog/git_c

[PATCH v11 1/4] contrib/: Add support for Cc: and Link: tags

contrib/ChangeLog: * gcc-changelog/git_commit.py: (GitCommit): Add support for 'Cc: ' and 'Link: ' tags. Cc: Jason Merrill Signed-off-by: Alejandro Colomar --- contrib/gcc-changelog/git_commit.py | 5 - 1 file changed, 4 insertions(+), 1 deletion(-)

[PATCH v11 2/4] gcc/: Rename array_type_nelts() => array_type_nelts_minus_one()

gcc/rust/ChangeLog: * backend/rust-tree.cc (array_type_nelts_top): Rename array_type_nelts() => array_type_nelts_minus_one() Cc: Gabriel Ravier Cc: Martin Uecker Cc: Joseph Myers Cc: Xavier Del Campo Romero Cc: Jakub Jelinek Suggested-by: Richard Biener Signed-off-by: Alejandro Colomar

[PATCH v11 4/4] c: Add __nelementsof__ operator

azley Cc: Ville Voutilainen Cc: Alex Celeste Cc: Jakub Łukasiewicz Cc: Douglas McIlroy Cc: Jason Merrill Suggested-by: Xavier Del Campo Romero Co-authored-by: Martin Uecker Signed-off-by: Alejandro Colomar --- gcc/c-family/c-common.cc | 26 gcc/c-family/c-common.def

[PATCH v11 3/4] Merge definitions of array_type_nelts_top()

geLog: * backend/rust-tree.h (array_type_nelts_top) * backend/rust-tree.cc (array_type_nelts_top): Remove function. Signed-off-by: Alejandro Colomar --- gcc/cp/cp-tree.h | 1 - gcc/cp/tree.cc| 13 - gcc/rust/backend/rust-tree.cc

Re: [PATCH v11 1/4] contrib/: Add support for Cc: and Link: tags

Hi, On Tue, Aug 20, 2024 at 08:41:28PM GMT, Alejandro Colomar wrote: > contrib/ChangeLog: > > * gcc-changelog/git_commit.py: (GitCommit): There's a spurious ':' in the line above (before the '('). I've removed it for an eventual v12. >

[RFC v1 0/2] c: Add _Lengthof operator

may also not work well with C++ or some corner cases. Can somebody with more experience have a look at the code? I suspect this is not yet ready, and thus doesn't have a ChangeLog. Have a lovely day! Alex Alejandro Colomar (2): Merge definitions of array_type_nelts_top() c: Add _Lengthof(

[RFC v1 1/2] Merge definitions of array_type_nelts_top()

There were two identical definitions, and none of them are available where they are needed for implementing _Lengthof(). Merge them, and provide the single definition in gcc/tree.{h,cc}, where it's available for _Lengthof(). Signed-off-by: Alejandro Colomar --- gcc/cp/cp-t

[RFC v1 2/2] c: Add _Lengthof() operator

of it being really a pointer. Link: <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2529.pdf> Cc: Gabriel Ravier Cc: Martin Uecker Cc: Joseph Myers Signed-off-by: Alejandro Colomar --- gcc/Makefile.in | 1 + gcc/c-family/c-common.cc | 20 ++ gcc/c-family/c-comm

Re: [RFC v1 0/2] c: Add _Lengthof operator

Hi Martin, On Sun, Jul 28, 2024 at 04:42:26PM GMT, Martin Uecker wrote: > Am Sonntag, dem 28.07.2024 um 16:15 +0200 schrieb Alejandro Colomar: > > ... > > > > Does anyone know if we have the information available for getting that > > value from the 'tree'

[RFC v2 0/2] c: Add __lengthof__ operator

v2: - Add a GNU extension first; not using ISO C-reserved names. That is, add __lengthof__ instead of _Lengthof/lengthof. - Use 'in_lengthof' instead of 'in_sizeof'. Alejandro Colomar (2): Merge definitions of array_type_nelts_top() c: Add __lengthof__() opera

[RFC v2 1/2] Merge definitions of array_type_nelts_top()

There were two identical definitions, and none of them are available where they are needed for implementing _Lengthof(). Merge them, and provide the single definition in gcc/tree.{h,cc}, where it's available for _Lengthof(). Signed-off-by: Alejandro Colomar --- gcc/cp/cp-t

[RFC v2 2/2] c: Add __lengthof__() operator

of it being really a pointer. Link: <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2529.pdf> Cc: Gabriel Ravier Cc: Martin Uecker Cc: Joseph Myers Signed-off-by: Alejandro Colomar --- gcc/c-family/c-common.cc | 19 gcc/c-family/c-common.def | 3 ++ gcc/c-family/c-common.h

Re: [RFC v1 1/2] Merge definitions of array_type_nelts_top()

Hi Richard, On Mon, Jul 29, 2024 at 10:27:35AM GMT, Richard Biener wrote: > On Sun, Jul 28, 2024 at 4:16 PM Alejandro Colomar wrote: > > > > There were two identical definitions, and none of them are available > > where they are needed for implementing _Lengthof(). Merge

[PATCH v1] gcc/: Rename array_type_nelts() => array_type_nelts_minus_one()

: Likewise. * fortran/trans-openmp.cc: Likewise. * rust/backend/rust-tree.cc: Likewise. Suggested-by: Richard Biener Signed-off-by: Alejandro Colomar --- Range-diff against v0: -: --- > 1: 82efbc3c540 gcc/: Rename array_type_nelts() => array_type_nelts_minus_one()

[PATCH v2 0/1] gcc/: Rename array_type_nelts() => array_type_nelts_minus_one()

or so passes ...] - Rename array_type_nelts_top() => array_type_nelts() This would reduce chances of mistakes. Have a lovely day! Alex Alejandro Colomar (1): gcc/: Rename array_type_nelts() => array_type_nelts_minus_one() gcc/c/c-decl.cc | 10 +- gcc/c

[PATCH v2 1/1] gcc/: Rename array_type_nelts() => array_type_nelts_minus_one()

_linear_ctor): Likewise. gcc/rust/ChangeLog: * backend/rust-tree.cc (array_type_nelts_top): Rename array_type_nelts() => array_type_nelts_minus_one() Suggested-by: Richard Biener Signed-off-by: Alejandro Colomar --- gcc/c/c-decl.cc | 10 +-

Re: [RFC v1 0/2] c: Add _Lengthof operator

Hi Joseph, On Mon, Jul 29, 2024 at 11:13:08AM GMT, Joseph Myers wrote: > On Sun, 28 Jul 2024, Alejandro Colomar wrote: > > > gcc/Makefile.in | 1 + > > gcc/c-family/c-common.cc | 20 + > > gcc/c-family/c-common.def | 4 ++ > > gcc/

[RFC v3 1/3] gcc/: Rename array_type_nelts() => array_type_nelts_minus_one()

_linear_ctor): Likewise. gcc/rust/ChangeLog: * backend/rust-tree.cc (array_type_nelts_top): Rename array_type_nelts() => array_type_nelts_minus_one() Suggested-by: Richard Biener Signed-off-by: Alejandro Colomar --- gcc/c/c-decl.cc | 10 +-

[RFC v3 0/3] c: Add __lengthof__ operator

gnof(*p++): 2; p: 0x7fffe52379f0 typeof(*p++);p: 0x7fffe52379f0 lengthof(*q++): 44; p: 0x7fffe5237a48 lengthof(*q++): 88; p: 0x7fffe5237a48 alignof(*q++): 2; p: 0x7fffe52379f0 typeof(*q++);p: 0x7fffe5237a48 There are some things

[RFC v3 2/3] Merge definitions of array_type_nelts_top()

There were two identical definitions, and none of them are available where they are needed for implementing __lengthof__(). Merge them, and provide the single definition in gcc/tree.{h,cc}, where it's available for __lengthof__(). Signed-off-by: Alejandro Colomar --- gcc/cp/cp-t

[RFC v3 3/3] c: Add __lengthof__() operator

er Cc: Joseph Myers Cc: Jakub Jelinek Signed-off-by: Alejandro Colomar --- gcc/c-family/c-common.cc | 26 +++ gcc/c-family/c-common.def | 3 ++ gcc/c-family/c-common.h | 2 + gcc/c/c-decl.cc | 20 ++--- gcc/c/c-parser.cc | 61 +++-- g

Re: [RFC v3 3/3] c: Add __lengthof__() operator

Hi Martin, On Sun, Aug 04, 2024 at 07:38:49AM GMT, Martin Uecker wrote: > Am Sonntag, dem 04.08.2024 um 01:17 +0200 schrieb Alejandro Colomar: > > > > FUTURE DIRECTIONS: > > > > We could make it work with array parameters to functions, and > > so

Re: [RFC v3 3/3] c: Add __lengthof__() operator

Hi Martin, On Sun, Aug 04, 2024 at 11:39:26AM GMT, Martin Uecker wrote: > Am Sonntag, dem 04.08.2024 um 10:25 +0200 schrieb Alejandro Colomar: > > Hi Martin, > > > > On Sun, Aug 04, 2024 at 07:38:49AM GMT, Martin Uecker wrote: > > > Am Sonntag, dem 04.08.2024 um

Re: [RFC v3 3/3] c: Add __lengthof__() operator

On Sun, Aug 04, 2024 at 06:40:14PM GMT, Alejandro Colomar wrote: > > The last  > > case should return a non-constant. > > The last case [*] is only allowed in prototypes. How should we get the > non-constant value? It's just another way to say [], isn't it? >

Re: [RFC v3 3/3] c: Add __lengthof__() operator

Hi Martin, On Sun, Aug 04, 2024 at 06:43:46PM GMT, Alejandro Colomar wrote: > On Sun, Aug 04, 2024 at 06:40:14PM GMT, Alejandro Colomar wrote: > > > The last  > > > case should return a non-constant. > > > > The last case [*] is only allowed in prototypes. How s

Re: [RFC v3 3/3] c: Add __lengthof__() operator

On Sun, Aug 04, 2024 at 08:02:25PM GMT, Martin Uecker wrote: > Hi Alex, Hi Martin, > > Is this missing diagnostics? > > > > $ cat star.c > > void foo(char (*a)[3][*], int (*x)[__lengthof__(*a)]); > > void bar(char (*a)[*][3], int (*x)[__lengthof__(*a)]); > > void foos(char (*a)[

Re: [RFC v3 3/3] c: Add __lengthof__() operator

[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

Re: [RFC v3 3/3] c: Add __lengthof__() operator

Hi Martin, On Sun, Aug 04, 2024 at 11:39:26AM GMT, Martin Uecker wrote: > > BTW, I still don't understand what `if (! TYPE_DOMAIN (type))` means, > > within array_type_nelts_minus_one(). What code triggers that condition? > > Am I missing error handling for that? Thanks! > > For incomplete arra

Re: [RFC v3 3/3] c: Add __lengthof__() operator

On Mon, Aug 05, 2024 at 01:55:50PM GMT, Alejandro Colomar wrote: > Hi Martin, > > On Sun, Aug 04, 2024 at 11:39:26AM GMT, Martin Uecker wrote: > > > BTW, I still don't understand what `if (! TYPE_DOMAIN (type))` means, > > > within array_type_nelts_minus_one(). W

Re: [RFC v3 3/3] c: Add __lengthof__() operator

On Mon, Aug 05, 2024 at 01:57:35PM GMT, Alejandro Colomar wrote: > On Mon, Aug 05, 2024 at 01:55:50PM GMT, Alejandro Colomar wrote: > > Hi Martin, > > > > On Sun, Aug 04, 2024 at 11:39:26AM GMT, Martin Uecker wrote: > > > > BTW, I still don't understand

Re: [RFC v3 3/3] c: Add __lengthof__() operator

On Mon, Aug 05, 2024 at 01:58:18PM GMT, Alejandro Colomar wrote: > On Mon, Aug 05, 2024 at 01:57:35PM GMT, Alejandro Colomar wrote: > > On Mon, Aug 05, 2024 at 01:55:50PM GMT, Alejandro Colomar wrote: > > > Hi Martin, > > > > > > On Sun, Aug 04, 2024 at

Re: [RFC v3 3/3] c: Add __lengthof__() operator

Hi Martin, On Mon, Aug 05, 2024 at 03:35:06PM GMT, Martin Uecker wrote: > > > > > > For incomplete arrays, basically we have the following different > > > > > > variants for arrays: > > > > > > > > > > > > T[ ] incomplete: !TYPE_DOMAIN > > > > > > T[1] constant size: TYPE_MAX_VALUE == INTEGER_CS

  1   2   3   >