Re: [PATCH] c: Enable -Wjump-misses-init for -Wc++-compat

Am Dienstag, dem 03.06.2025 um 11:22 -0700 schrieb Andrew Pinski: > On Tue, Jun 3, 2025 at 11:18 AM Martin Uecker wrote: > > > > Am Dienstag, dem 03.06.2025 um 10:56 -0700 schrieb Andrew Pinski: > > > On Tue, Jun 3, 2025 at 10:45 AM Martin Uecker wrote: > > >

Re: [PATCH] c: Enable -Wjump-misses-init for -Wc++-compat

Am Dienstag, dem 03.06.2025 um 10:56 -0700 schrieb Andrew Pinski: > On Tue, Jun 3, 2025 at 10:45 AM Martin Uecker wrote: > > > > > > This version only contains the fix for -Wc++-compat. > > Note this was recorded as PR 120078. I didn't notice the typo when I >

[PATCH] c: Enable -Wjump-misses-init for -Wc++-compat

This version only contains the fix for -Wc++-compat. Bootstrapped and regression tested for x86_64. Martin c: Enable -Wjump-misses-init for -Wc++-compat Fix a typo that prevented the warning from being activated with -Wc++compat. gcc/c-family/ChangeLog: * c.o

Re: [PATCH] c: Enable -Wjump-misses-init in -Wextra and -Wc++-compat [PR87038]

Am Montag, dem 02.06.2025 um 18:45 + schrieb Joseph Myers: > On Mon, 2 Jun 2025, Martin Uecker wrote: > > > According to the discussion in the bugzilla there seems to be > > some consensus to activate the warning for -Wextra (I am also > > looking into implementing th

Re: [PATCH] c: Enable -Wjump-misses-init in -Wextra and -Wc++-compat [PR87038]

Am Montag, dem 02.06.2025 um 13:19 -0500 schrieb Segher Boessenkool: > Hi! > > On Mon, Jun 02, 2025 at 05:50:08PM +0200, Martin Uecker wrote: > > According to the discussion in the bugzilla there seems to be > > some consensus to activate the warning for -Wextra (I am

[PATCH] c: Enable -Wjump-misses-init in -Wextra and -Wc++-compat [PR87038]

According to the discussion in the bugzilla there seems to be some consensus to activate the warning for -Wextra (I am also looking into implementing the suggested improvements that may make it suitable fo r-Wall). When making this change, I also noticed that it was not working for -Wc++-compat

[PATCH] c: fix ICE with enum completed with packed attribute after forward decl [PR116892]

I *believe* TYPE_PACKED should be propagated to existing main variants. Bootstrapped and regression tested for x86_64. Martin c: fix ICE with enum completed with packed attribute after forward decl [PR116892] After forward declaration of an enum and when completing it with the

[PATCH] c: Move checking assertions from recursion when forming composite types to avoid ICE.

After looking a bit more at this, it turns out that it is still possible to trigger the assertion that checks that the composite type is compatible to the original types when using self-referential types where it then sees composite types which are still under construction. This patch now moves

[PATCH v3] c: fix ICE related to tagged types with attributes in diagnostics [PR120380]

I had accidentally swapped dg-warning and dg-error in the test for the last version. I will commit this one if it passes checks. Martin c: fix ICE related to tagged types with attributes in diagnostics [PR120380] get_aka_type will create a new type for diagnostics, but for tagge

[PATCH v2] c: fix ICE related to tagged types with attributes in diagnostics [PR120380]

Am Donnerstag, dem 29.05.2025 um 20:57 + schrieb Joseph Myers: > On Thu, 29 May 2025, Martin Uecker wrote: > > > get_aka_type will create a new type for diagnostics, but for tagged > > types > > attributes will then be ignored with a warning. This can

[PATCH] c: fix ICE related to tagged types with attributes in diagnostics [PR120380]

This fixes an error recovery issue. Bootstrapped and regression tested for x86_64. Martin c: fix ICE related to tagged types with attributes in diagnostics [PR120380] get_aka_type will create a new type for diagnostics, but for tagged types attributes will then be ignored wit

[PATCH] c: fix ICE for mutually recursive structures [PR120381]

This is a fun one.  Bootstrapped and regression tested for x86_64. Martin c: fix ICE for mutually recursive structures [PR120381] For invalid nesting of a structure definition in a definition of itself or when using a rather obscure construction using statement expression

Re: [GCC16 stage 1][PATCH v2 0/3] extend "counted_by" attribute to pointer fields of structures

to pointer references with > >counted_by attributes, the hardest part is to get the INDEX of the > >corresponding array ref from the offset computation expression of > >the pointer ref. > > > > I do need some careful review on the 3rd part of the patch. And I do wonder > > for the access to pointer arrays: > > > > struct annotated { > > int b; > > int *c __attribute__ ((counted_by (b))); > > } *p_array_annotated; > > > > p_array_annotated->c[annotated_index] = 2; > > > > Is it possible to generate ARRAY_REF instead of INDIRECT_REF for the above > > p_array_annotated->c[annotated_index] > > in C FE? then we can keep the INDEX info in the IR and avoid all the hacks > > to get the index from the OFFSET computation expression. > > > > The whole patch set has been rebased on the latest trunk, bootstrapped > > and regression tested on both aarch64 and x86. > > > > Let me know any comments and suggestions. > > > > Thanks. > > > > Qing > -- Univ.-Prof. Dr. rer. nat. Martin Uecker Graz University of Technology Institute of Biomedical Imaging

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

Am Dienstag, dem 15.04.2025 um 14:50 +0200 schrieb Michael Matz: > Hello, ... > > struct A { > > int *buf __counted_by(len); // 'len' *must* be in the struct. > > int len; > > }; > > ... means that we would have to implement general delayed parsing for > expressions in C parsers. I have to

Re: .ACCESS_WITH_SIZE and pointer ranges

Am Freitag, dem 11.04.2025 um 18:14 + schrieb Qing Zhao: > > > On Apr 11, 2025, at 13:37, Martin Uecker wrote: > > > > Am Freitag, dem 11.04.2025 um 17:08 + schrieb Qing Zhao: > > > > > > > On Apr 11, 2025, at 12:20, Martin Uecker wrote: >

Re: .ACCESS_WITH_SIZE and pointer ranges

Am Freitag, dem 11.04.2025 um 13:55 -0400 schrieb Siddhesh Poyarekar: > On 2025-04-11 13:37, Martin Uecker wrote: > > > My understanding is that such issue with the implicit data flow > > > dependency information missing is only for the > > > counted_by attribute

Re: .ACCESS_WITH_SIZE and pointer ranges

Am Freitag, dem 11.04.2025 um 17:08 + schrieb Qing Zhao: > > > On Apr 11, 2025, at 12:20, Martin Uecker wrote: > > > > Am Freitag, dem 11.04.2025 um 16:01 + schrieb Qing Zhao: > > > > > > > On Apr 11, 2025, at 10:53, Martin Uecker wrote: >

Re: .ACCESS_WITH_SIZE and pointer ranges

Am Freitag, dem 11.04.2025 um 16:01 + schrieb Qing Zhao: > > > On Apr 11, 2025, at 10:53, Martin Uecker wrote: > > > > Am Freitag, dem 11.04.2025 um 10:42 -0400 schrieb Andrew MacLeod: > > > On 4/11/25 10:27, Qing Zhao wrote: > > > > > >

Re: .ACCESS_WITH_SIZE and pointer ranges

Am Freitag, dem 11.04.2025 um 10:42 -0400 schrieb Andrew MacLeod: > On 4/11/25 10:27, Qing Zhao wrote: > > > > > On Apr 10, 2025, at 11:12, Martin Uecker wrote: > > > > > > Am Donnerstag, dem 10.04.2025 um 10:55 -0400 schrieb Siddhesh Poyarekar: > > >

Re: Questions on replacing a structure pointer reference to a call to .ACCESS_WITH_SIZE in C FE

Am Donnerstag, dem 10.04.2025 um 17:05 + schrieb Qing Zhao: > Hi, Martin, > > Thanks a lot for all your comments and questions, really helpful. > > ... > > > > An example I could imagine is when you memcpy > > the struct. (but it is also not entirely clear why this > > should not be allo

Re: .ACCESS_WITH_SIZE and pointer ranges

Am Donnerstag, dem 10.04.2025 um 10:55 -0400 schrieb Siddhesh Poyarekar: > On 2025-04-10 10:50, Andrew MacLeod wrote: > > Its not clear to me exactly what is being asked, but I think the > > suggestion is that pointer references are being replaced with a builtin > > function called .ACCESS_WITH_S

Re: Questions on replacing a structure pointer reference to a call to .ACCESS_WITH_SIZE in C FE

Am Donnerstag, dem 10.04.2025 um 06:56 -0400 schrieb Siddhesh Poyarekar: > On 2025-04-10 01:41, Martin Uecker wrote: > > I have some questions about this: The access would add new reads > > to the size field. For counted_by, so far, those are somehow > > coupled to the

Re: Questions on replacing a structure pointer reference to a call to .ACCESS_WITH_SIZE in C FE

Am Mittwoch, dem 09.04.2025 um 18:31 + schrieb Qing Zhao: > Hi, Joseph and Martin, > > When I implemented the patch to attach the counted_by information to an array > reference (FAM reference) in C FE, > The work was done inside the routine “build_component_ref” in > gcc/c/c-typeck.cc

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

Am Montag, dem 07.04.2025 um 14:44 +0200 schrieb Michael Matz: > Hello, > > On Sat, 5 Apr 2025, Bill Wendling wrote: > > > > > > > So, a different attribute name “counted_by_exp” might be better? > > > > > > > > > > I would prefer Martins empty-decl idea to that: "counted_by(;len+0)" > > > > > (

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

Am Montag, dem 31.03.2025 um 13:59 -0700 schrieb Bill Wendling: > > I'd like to offer up this to solve the issues we're facing. This is a > > combination of everything that's been discussed here (or at least that > > I've been able to read in the centi-thread :-). Thanks! I think this proposal

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

Am Dienstag, dem 01.04.2025 um 17:13 -0700 schrieb Bill Wendling: > On Tue, Apr 1, 2025 at 8:29 AM Martin Uecker wrote: > > Am Dienstag, dem 01.04.2025 um 15:01 + schrieb Qing Zhao: > > > > On Apr 1, 2025, at 10:04, Martin Uecker wrote: > > > > Am Mont

[PATCH] c: fix checking for a tag for variably modified tagged types [PR119612]

The checking assertion added for PR118765 https://gcc.gnu.org/cgit/gcc/commit/?id=accbc1b90bd942aa36ac1485a21056b774ce02df did indeed catch some case I hadn't considered. I think there might be other cases in the C FE where we test for !TYPE_NAME and where this might be slightly wrong, but I

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

Am Freitag, dem 04.04.2025 um 18:51 +0200 schrieb Michael Matz: > Hello, > > On Fri, 4 Apr 2025, Qing Zhao wrote: > > > So, a different attribute name “counted_by_exp” might be better? > > I would prefer Martins empty-decl idea to that: "counted_by(;len+0)" > (looks up 'len' normally, i.e. does

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

Am Freitag, dem 04.04.2025 um 15:22 + schrieb Qing Zhao: > Hi, Michael, > > Thanks a lot for raising these questions for the parser implementation of the > new syntax. > > I started thinking about how to implement this new syntax inside counted_by > attriubte > In GCC C FE. Since I have v

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

Am Dienstag, dem 01.04.2025 um 18:58 + schrieb Qing Zhao: > > > On Apr 1, 2025, at 11:28, Martin Uecker wrote: > > > > Am Dienstag, dem 01.04.2025 um 15:01 + schrieb Qing Zhao: > > > > > > > On Apr 1, 2025, at 10:04, Martin Uecker wrote: &g

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

Am Dienstag, dem 01.04.2025 um 15:01 + schrieb Qing Zhao: > > > On Apr 1, 2025, at 10:04, Martin Uecker wrote: > > > > > > > > Am Montag, dem 31.03.2025 um 13:59 -0700 schrieb Bill Wendling: > > > > I'd like to offer up this to solve the

[PATCH] Doc: -Wzero-as-null-pointer-constant is also available for C [PR119173]

Here is a small documentation patch. Martin Doc: -Wzero-as-null-pointer-constant is also available for C [PR119173] The warning -Wzero-as-null-pointer-constant is now not only supported in C++ but also in C. Change the documentation accordingly. PR c/119173

[PATCH v2] c: Fix tagname confusion for typedef redefinitions [PR118765]

I looked at this again and do not need a workaround anymore. I did not implement any restrictions preventing typedef  redeclarations from having different alignment, because merge_decls does not include any such restrictions at this time. I could write another patch for this, but I think this w

Re: [PATCH] c: Fix tagname confusion for typedef redefinitions [PR118765]

Am Montag, dem 17.03.2025 um 23:25 + schrieb Joseph Myers: > On Sun, 16 Mar 2025, Martin Uecker wrote: > > > This is a workaround for another issue related to PR118765. > > I do not yet understand what goes wrong in merge_decls in > > this case (somehow we end

[PATCH] c: Fix ICE in error recovery when checking struct compatibility [PR118061]

Here is a small patch fixing an error recovery issue. Bootstrapped and regression tested on x86_64. commit 465773af2bdd552184b935e5dc6b3db9e0e4e327 Author: Martin Uecker Date: Sat Mar 1 17:21:25 2025 +0100 c: Fix ICE in error recovery when checking struct compatibility [PR118061

[PATCH] c: Fix tagname confusion for typedef redefinitions [PR118765]

this specific case as a workaround and add a "sorry" for the alignment case (or should this simply become an error?). Bootstrapped and regression tested on x86_64. commit 56c2c96ef4ebd24290fbf8f66b277d420a68b032 Author: Martin Uecker Date: Sun Mar 16 10:54:17 2025 +0100 c: F

[PATCH] c: Fix bug in typedef redefinitions of tagged types [PR118765]

This is a partial fix for PR118765. Bootstrapped and regression tested on x86_64. commit 84ba284a14bb5249d923affbf3f0f95a993c3a29 Author: Martin Uecker Date: Sat Mar 1 21:32:21 2025 +0100 c: Fix bug in typedef redefinitions of tagged types [PR118765] When we redefine a

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

Am Freitag, dem 14.03.2025 um 14:42 -0400 schrieb John McCall: > On 14 Mar 2025, at 14:13, Martin Uecker wrote: > > > Am Freitag, dem 14.03.2025 um 10:11 -0700 schrieb David Tarditi: > > > Hi Martin, > > > > > > The C design of VLAs misunderstood dependent

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

Am Montag, dem 10.03.2025 um 15:00 -0400 schrieb John McCall: > ... > That said, my preference is still to just give preference to the field name, > which sidesteps any need for disambiguation syntax and avoids this whole > problem where structs can be broken by just adding a global variable tha

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

nt type was specified in terms of other members in the > same object. > > As for the rules around scoping, we only need to rules that differ because > the original design was flawed and missed common use cases. > > David > > > > On Mar 13, 2025, at 11:16 PM, Marti

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

future evolution of the language. Martin Am Freitag, dem 14.03.2025 um 07:16 +0100 schrieb Martin Uecker: > Hi David, > > Am Donnerstag, dem 13.03.2025 um 19:23 -0700 schrieb David Tarditi: > > > > I skip your initiial part. I think this was all discussed before > >

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

Hi David, Am Donnerstag, dem 13.03.2025 um 19:23 -0700 schrieb David Tarditi: > > I skip your initiial part. I think this was all discussed before (also in WG14) and I still come to different conclusions.  Just two comments: ... > > The VLA semantics are also problematic. User can side-effe

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

Am Donnerstag, dem 13.03.2025 um 19:48 +0100 schrieb JeanHeyd Meneide: > On Thu, Mar 13, 2025 Martin Uecker wrote: > > ... > Part of this problem is self-inflicted: VLAs in structures are > a GNU extension and not an ISO C feature (for reasons like this one).  Note that this

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

Am Donnerstag, dem 13.03.2025 um 15:41 + schrieb Qing Zhao: > > > On Mar 12, 2025, at 12:40, Martin Uecker wrote: > > > > Am Mittwoch, dem 12.03.2025 um 16:20 + schrieb Qing Zhao: > > > > > > > On Mar 10, 2025, at 15:34, Martin Uecker wrote:

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

Am Mittwoch, dem 12.03.2025 um 16:58 + schrieb Joseph Myers: > On Wed, 12 Mar 2025, Martin Uecker wrote: > > > For a designator > > > > struct foo { int n; } a = { .n = 1 }; > > > > we also refer to a member 'n' of an instance 'a' of

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

Am Mittwoch, dem 12.03.2025 um 16:20 + schrieb Qing Zhao: > > > On Mar 10, 2025, at 15:34, Martin Uecker wrote: > > > > Am Montag, dem 10.03.2025 um 15:00 -0400 schrieb John McCall: > > > > > > > ... > > > > > That said, my

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

Am Montag, dem 10.03.2025 um 16:45 -0400 schrieb John McCall: > > On 10 Mar 2025, at 15:34, Martin Uecker wrote: > > > > Am Montag, dem 10.03.2025 um 15:00 -0400 schrieb John McCall: > > > > > > That said, my preference is still to just give prefe

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

Am Montag, dem 10.03.2025 um 19:30 -0400 schrieb John McCall: > On 10 Mar 2025, at 18:30, Martin Uecker wrote: > > Am Montag, dem 10.03.2025 um 16:45 -0400 schrieb John McCall: > > > > .. > > > > > > > > > > > > While the next example

Re: [GCC16 stage 1][RFC][PATCH 0/3]extend "counted_by" attribute to pointer fields of structures

Am Freitag, dem 24.01.2025 um 14:23 + schrieb Joseph Myers: > On Thu, 23 Jan 2025, Martin Uecker wrote: > > > I can see why it could be seen in this way. But the designator > > syntax could also be seen (more or less) as a tiny subset of > > the expression syntax allow

Re: [GCC16 stage 1][RFC][PATCH 0/3]extend "counted_by" attribute to pointer fields of structures

. Am Donnerstag, dem 23.01.2025 um 15:27 +0100 schrieb Michael Matz: > > Hello, > > > > On Wed, 22 Jan 2025, Martin Uecker wrote: > > > > > > > > > > > > If y is not a member it must be an expression, true. But > > > > > > &

Re: [GCC16 stage 1][RFC][PATCH 0/3]extend "counted_by" attribute to pointer fields of structures

Am Donnerstag, dem 23.01.2025 um 20:24 + schrieb Qing Zhao: > > > On Jan 23, 2025, at 13:27, Martin Uecker wrote: > > > > Am Donnerstag, dem 23.01.2025 um 17:39 + schrieb Qing Zhao: > > > > > > > On Jan 22, 2025, at 12:20, Martin Uecker

Re: [GCC16 stage 1][RFC][PATCH 0/3]extend "counted_by" attribute to pointer fields of structures

Am Donnerstag, dem 23.01.2025 um 17:39 + schrieb Qing Zhao: > > > On Jan 22, 2025, at 12:20, Martin Uecker wrote: > > > > Am Mittwoch, dem 22.01.2025 um 18:11 +0100 schrieb Martin Uecker: > > > Am Mittwoch, dem 22.01.2025 um 16:37 + schrieb Qing Zhao: >

Re: [GCC16 stage 1][RFC][PATCH 0/3]extend "counted_by" attribute to pointer fields of structures

Hi Quin, sorry, another idea I noted down some time ago which I would like to mention. > > > > - use it only in limited contexts where you do not need to know > > the type (e.g. this works for goto labels) or for a basic > > counted_by attribute that only takes an identifier as we have i

Re: [GCC16 stage 1][RFC][PATCH 0/3]extend "counted_by" attribute to pointer fields of structures

Am Mittwoch, dem 22.01.2025 um 18:11 +0100 schrieb Martin Uecker: > Am Mittwoch, dem 22.01.2025 um 16:37 + schrieb Qing Zhao: > > > > > On Jan 22, 2025, at 11:22, Martin Uecker wrote: > > > > > > > > > Hello Michael, > > > > >

Re: [GCC16 stage 1][RFC][PATCH 0/3]extend "counted_by" attribute to pointer fields of structures

Am Mittwoch, dem 22.01.2025 um 16:37 + schrieb Qing Zhao: > > > On Jan 22, 2025, at 11:22, Martin Uecker wrote: > > > > > > Hello Michael, > > > > Am Mittwoch, dem 22.01.2025 um 16:54 +0100 schrieb Michael Matz: > > > On Wed, 22 Jan 2025, M

Re: [GCC16 stage 1][RFC][PATCH 0/3]extend "counted_by" attribute to pointer fields of structures

Am Mittwoch, dem 22.01.2025 um 17:30 +0100 schrieb Michael Matz: > Hello, > > On Wed, 22 Jan 2025, Martin Uecker wrote: > > > > > In .y[1][3].z after .y you can decide whether y is a member of the > > > > struct being initialized. If it is, it is a designa

Re: [GCC16 stage 1][RFC][PATCH 0/3]extend "counted_by" attribute to pointer fields of structures

Hello Michael, Am Mittwoch, dem 22.01.2025 um 16:54 +0100 schrieb Michael Matz: > On Wed, 22 Jan 2025, Martin Uecker wrote: > > > > > So you do not need to look further. But maybe I am missing something > > > > else. > > > > > > Like ... >

Re: [GCC16 stage 1][RFC][PATCH 0/3]extend "counted_by" attribute to pointer fields of structures

Am Mittwoch, dem 22.01.2025 um 16:25 +0100 schrieb Michael Matz: > Hello, > > On Wed, 22 Jan 2025, Martin Uecker wrote: > > > > You need to decide which is which after seeing the ".". I'm guessing > > > what > > > you mean is

Re: [GCC16 stage 1][RFC][PATCH 0/3]extend "counted_by" attribute to pointer fields of structures

Am Mittwoch, dem 22.01.2025 um 15:53 +0100 schrieb Michael Matz: > Hello, > > On Tue, 21 Jan 2025, Martin Uecker wrote: > > > > > Coudn't you use the rule that .len refers to the closest enclosing > > > > structure > > > > even without

Re: [GCC16 stage 1][RFC][PATCH 0/3]extend "counted_by" attribute to pointer fields of structures

Am Dienstag, dem 21.01.2025 um 21:13 + schrieb Joseph Myers: > On Tue, 21 Jan 2025, Martin Uecker wrote: > > > The bigger issue seems that if you forward reference a member, you > > do not yet know its type. So whatever syntax we pick, general expressions > >

Re: [GCC16 stage 1][RFC][PATCH 0/3]extend "counted_by" attribute to pointer fields of structures

Am Dienstag, dem 21.01.2025 um 21:15 +0100 schrieb Martin Uecker: > Am Dienstag, dem 21.01.2025 um 19:45 + schrieb Joseph Myers: > > On Tue, 21 Jan 2025, Martin Uecker wrote: > > > > > Coudn't you use the rule that .len refers to the closest enclosing >

Re: [GCC16 stage 1][RFC][PATCH 0/3]extend "counted_by" attribute to pointer fields of structures

Am Dienstag, dem 21.01.2025 um 19:45 + schrieb Joseph Myers: > On Tue, 21 Jan 2025, Martin Uecker wrote: > > > Coudn't you use the rule that .len refers to the closest enclosing structure > > even without __self__ ? This would then also disambiguate between > &

Re: [GCC16 stage 1][RFC][PATCH 0/3]extend "counted_by" attribute to pointer fields of structures

Am Dienstag, dem 21.01.2025 um 18:40 + schrieb Joseph Myers: > On Tue, 21 Jan 2025, Qing Zhao wrote: > > > So, even after we introduce the designator syntax for counted_by attribute, > > arbitrary expressions as: > > > > counted_by (.len1 + const) > > counted_by (.len1 + .len2) > > > > St

Re: [GCC16 stage 1][RFC][PATCH 0/3]extend "counted_by" attribute to pointer fields of structures

Am Freitag, dem 17.01.2025 um 15:34 -0800 schrieb Bill Wendling: > On Fri, Jan 17, 2025 at 3:14 PM Joseph Myers wrote: > > > > On Fri, 17 Jan 2025, Qing Zhao wrote: > > > > > struct fc_bulk { > > > ... > > > struct fs_bulk fs_bulk; > > > struct fc fcs[] __counted_by(fs_bulk.len); > > > };

Re: [GCC16 stage 1][RFC][PATCH 0/3]extend "counted_by" attribute to pointer fields of structures

Am Donnerstag, dem 16.01.2025 um 21:18 + schrieb Qing Zhao: > .. > > Although in the previous discussion, I agreed with Martin that we should use > the > designator syntax (i.e, counted_by (.n) instead of counted_by (n)) for the > counted_by attribute for pointer fields, after more considera

[PATCH] c: Restore warning for incomplete structures declared in parameter list [PR117866]

Happy new year! Please consider the following patch. Bootstrapped and regression tested on x86_64. c: Restore warning for incomplete structures declared in parameter list [PR117866] In C23 mode the warning about declaring structures and union in parameter lists was removed, b

Re: Should -fsanitize=bounds support counted-by attribute for pointers inside a structure?

Am Donnerstag, dem 12.12.2024 um 13:59 -0800 schrieb Bill Wendling: > On Thu, Dec 12, 2024 at 1:28 PM Martin Uecker wrote: > > > > Am Montag, dem 09.12.2024 um 16:20 + schrieb Qing Zhao: > > > > > > > On Dec 7, 2024, at 03:57, Martin Uecker wro

Re: Should -fsanitize=bounds support counted-by attribute for pointers inside a structure?

Am Montag, dem 09.12.2024 um 16:20 + schrieb Qing Zhao: > > > On Dec 7, 2024, at 03:57, Martin Uecker wrote: > > > > Am Freitag, dem 06.12.2024 um 16:13 + schrieb Qing Zhao: > > > > > > > On Dec 6, 2024, at 10:56, Martin Uecker wrote: > &g

[PATCH v3 2/2] Fix type compatibility for types with flexible array member [PR113688,PR114713,PR117724]

The second part now only contains the changes for array size. I added back a special case for this instead of having the 'ignore_size' flag (which I would nevertheless assume might be needed in the future when matching pointer types). In this version, I added an exception to the special case t

[PATCH v3 1/2] Fix type compatibility for types with flexible array member [PR113688,PR114713,PR117724]

As requested, I split up into one part for the TYPE_MODE and  another one for the array size to help with git bisecting. This is the first part. Bootstrapped and regression tested on x86_64. Allow the TYPE_MODE of a type with an array as last member to differ from another compatible type.

[PATCH] Fix type compatibility for types with flexible array member [PR113688,PR114014,PR117724]

Hi Richard, this is another version. It now adds an "ignore_size" flag to gimple_canonical_types_compatible_p and uses this instead of having the complicated special case for arrays at the end. Also zero-sized members are now ignored again, except if they are arrays at the end where then only

Re: Should -fsanitize=bounds support counted-by attribute for pointers inside a structure?

Am Freitag, dem 06.12.2024 um 16:13 + schrieb Qing Zhao: > > > On Dec 6, 2024, at 10:56, Martin Uecker wrote: > > > > Am Freitag, dem 06.12.2024 um 14:16 + schrieb Qing Zhao: > > > ... > > > > > > > > I think the relevant sce

Re: Should -fsanitize=bounds support counted-by attribute for pointers inside a structure?

Am Freitag, dem 06.12.2024 um 14:16 + schrieb Qing Zhao: > > > On Dec 5, 2024, at 17:31, Martin Uecker wrote: > > > > Am Donnerstag, dem 05.12.2024 um 21:09 + schrieb Qing Zhao: > > > > > > >

Re: Should -fsanitize=bounds support counted-by attribute for pointers inside a structure?

Am Donnerstag, dem 05.12.2024 um 14:28 -0800 schrieb Bill Wendling: > On Thu, Dec 5, 2024 at 1:09 PM Qing Zhao wrote: > > > On Dec 3, 2024, at 10:29, Qing Zhao wrote: > > > > On Dec 3, 2024, at 10:07, Martin Uecker wrote: > > > > The language extension does n

Re: Should -fsanitize=bounds support counted-by attribute for pointers inside a structure?

Am Donnerstag, dem 05.12.2024 um 21:09 + schrieb Qing Zhao: > > > On Dec 3, 2024, at 10:29, Qing Zhao wrote: > > > > > > > > > > > > > > > > > > > > > > It would be clearer if you the syntax ".n" which resembles > > > > > > > the syntax for designated initializers that is already us

Re: Should -fsanitize=bounds support counted-by attribute for pointers inside a structure?

Am Dienstag, dem 03.12.2024 um 14:31 + schrieb Qing Zhao: > > > On Dec 3, 2024, at 01:33, Martin Uecker wrote: > > > > Am Montag, dem 02.12.2024 um 22:58 + schrieb Qing Zhao: > > > > > > > On Dec 2, 2024, at 16:13, Martin Uecker wrote: > &

Re: Fix type compatibility for types with flexible array member [PR113688,PR114014,PR117724]

ere declared with char b[1]. Martin > > Qing > > I would make it > > compatible but not allow redefinition as the types are different. > > > > > > > > Martin > > > > > > > > > > thanks. > > > > >

Re: Should -fsanitize=bounds support counted-by attribute for pointers inside a structure?

Am Montag, dem 02.12.2024 um 22:58 + schrieb Qing Zhao: > > > On Dec 2, 2024, at 16:13, Martin Uecker wrote: > > > > Am Montag, dem 02.12.2024 um 20:15 + schrieb Qing Zhao: > > > > > > > On Nov 30, 2024, at 07:22, Martin Uecker wrote: > >

Re: Should -fsanitize=bounds support counted-by attribute for pointers inside a structure?

Am Montag, dem 02.12.2024 um 20:15 + schrieb Qing Zhao: > > > On Nov 30, 2024, at 07:22, Martin Uecker wrote: > > > > Am Dienstag, dem 26.11.2024 um 20:59 + schrieb Qing Zhao: > > > Think this over these days, I have another thought that need some > >

Re: Fix type compatibility for types with flexible array member [PR113688,PR114014,PR117724]

Am Montag, dem 02.12.2024 um 16:31 + schrieb Qing Zhao: > > > On Nov 30, 2024, at 07:10, Martin Uecker wrote: > > > > Am Dienstag, dem 26.11.2024 um 15:15 + schrieb Qing Zhao: > > > > > > > On Nov 25, 2024, at 16:46, Martin Uecker

Re: Should -fsanitize=bounds support counted-by attribute for pointers inside a structure?

gt; in the above, 'ref1' uses 'val1' as the number of the elements in > 'p->array', and 'ref2' uses 'val2' as the number of elements in > 'p->array’. > " > Has this feature been used by Linux kernel alread

Re: Fix type compatibility for types with flexible array member [PR113688,PR114014,PR117724]

Am Dienstag, dem 26.11.2024 um 15:15 + schrieb Qing Zhao: > > > On Nov 25, 2024, at 16:46, Martin Uecker wrote: > > > > > > Hi Qing, > > > > Am Montag, dem 25.11.2024 um 17:40 + schrieb Qing Zhao: > > > Hi, Martin, > > >

[C PATCH] c: Set attributes for fields when forming a composite type [PR117806]

It seems we also miss a decl_attributes call for the fields when building the composite type. Bootstrapped and regression tested on x86_64. c: Set attributes for fields when forming a composite type [PR117806] We need to call decl_attributes when creating the fields for a composi

[PATCH] c: correct type compatibility for bit-fields [PR117828]

Bit-fields need additional checks for type compatiblity. Bootstrapped and regression tested on x86_64. c: correct type compatibility for bit-fields [PR117828] Add missing test for consistency of bit-fields when comparing tagged types for compatibility. PR c/

Re: Fix type compatibility for types with flexible array member [PR113688,PR114014,PR117724]

e patch this should not matter anymore. Martin > > thanks. > > Qing > > On Nov 23, 2024, at 14:45, Martin Uecker wrote: > > > > > > This patch tries fixes the errors we have because of > > flexible array members. I am bit unsure about the exception

Re: Fix type compatibility for types with flexible array member [PR113688,PR114014,PR117724]

Hi Richard, here is another version. This now just ignores the size for all trailing arrays which I think is the right thing to do. It also modifies the lto hashing which also seems to work (but needs more testing and I haven't added tests to the patch yet). I also added back the missing comp

Re: Fix type compatibility for types with flexible array member [PR113688,PR114014,PR117724]

Am Montag, dem 25.11.2024 um 10:35 +0100 schrieb Richard Biener: > On Mon, 25 Nov 2024, Richard Biener wrote: > > > On Sat, 23 Nov 2024, Martin Uecker wrote: > > > > > > > > This patch tries fixes the errors we have because of > > > flexible array

Fix type compatibility for types with flexible array member [PR113688,PR114014,PR117724]

This patch tries fixes the errors we have because of flexible array members. I am bit unsure about the exception for the mode. Bootstrapped and regression tested on x86_64. Fix type compatibility for types with flexible array member [PR113688,PR114014,PR117724] verify_type che

Re: Should -fsanitize=bounds support counted-by attribute for pointers inside a structure?

re setting the buffer (or at the same time). This could be ensured by making the member 'n' const, so that it can only be changed by overwriting the whole struct. But I am still thinking about this. In any case, I think for "counted_by" this is not an option because it would b

Re: Should -fsanitize=bounds support counted-by attribute for pointers inside a structure?

Am Mittwoch, dem 20.11.2024 um 15:27 + schrieb Qing Zhao: > > > On Nov 19, 2024, at 10:47, Marek Polacek wrote: > > > > On Mon, Nov 18, 2024 at 07:10:35PM +0100, Martin Uecker wrote: > > > Am Montag, dem 18.11.2024 um 17:55 + schrieb Qing Zhao: > >

Re: Should -fsanitize=bounds support counted-by attribute for pointers inside a structure?

Am Dienstag, dem 19.11.2024 um 10:47 -0500 schrieb Marek Polacek: > On Mon, Nov 18, 2024 at 07:10:35PM +0100, Martin Uecker wrote: > > Am Montag, dem 18.11.2024 um 17:55 + schrieb Qing Zhao: > > > Hi, > > > > > > I am working on extending “counte

Re: Should -fsanitize=bounds support counted-by attribute for pointers inside a structure?

Am Montag, dem 18.11.2024 um 21:31 + schrieb Qing Zhao: > > > On Nov 18, 2024, at 13:10, Martin Uecker wrote: > ... > So, I guess that the more accurate question is, for the following: > > struct annotated { > int b; > int *c __attribute__ ((counted_by (b

Re: Should -fsanitize=bounds support counted-by attribute for pointers inside a structure?

Am Dienstag, dem 19.11.2024 um 09:18 -0800 schrieb Kees Cook: > On Tue, Nov 19, 2024 at 05:41:13PM +0100, Martin Uecker wrote: > > Am Dienstag, dem 19.11.2024 um 10:47 -0500 schrieb Marek Polacek: > > > On Mon, Nov 18, 2024 at 07:10:35PM +0100, Martin Uecker wrote: >

Re: Should -fsanitize=bounds support counted-by attribute for pointers inside a structure?

Am Montag, dem 18.11.2024 um 17:55 + schrieb Qing Zhao: > Hi, > > I am working on extending “counted_by” attribute to pointers inside a > structure per our previous discussion. > > I need advice on the following question: > > Should -fsantize=bounds support array reference that was referen

[PATCH] c: fix incorrect TBAA for tagged types across translation units [PR117490]

Here is a patch to fix a TBAA issue for tagged types. In principle, this affects earlier language modes too, but I limited the change to C23 for now because it was always wrong but is less of an issue before C23. If there is no fallout, I would propose to later fix this also for earlier version

[PATCH] c: Fix ICE when forming composite type for two structures / unions [PR117548]

Bootstrapped and regression tested on x86_64. c: Fix ICE when forming composite type for two structures / unions [PR117548] When forming the composite type from two tagged type, we need to find the original type for a typedecl to get the correct tag. PR c/117

Re: [PATCH] Fix test failures for enum-alias-{1,2,3} on arm-eabi [PR117419]

Richard, ok for trunk then? Am Freitag, dem 15.11.2024 um 02:11 -0300 schrieb Thiago Jung Bauermann: > Hello, > > Martin Uecker writes: > > > I added a max element as suggested by Richard to force > > the type to an int. > > > > Regression tested on

[PATCH] Fix test failures for enum-alias-{1,2,3} on arm-eabi [PR117419]

I added a max element as suggested by Richard to force the type to an int. Regression tested on x86_64 but needs testing on arm-eabi. Thiago, could you test this? https://linaro.atlassian.net/browse/GNU-1224 Fix test failures for enum-alias-{1,2,3} on arm-eabi [PR117419] The tes

[PATCH v5] c: add Wzero-as-null-pointer-constant [PR117059]

Added tests with some non-NPC pointers converted to bool. (BTW: For some reason we allowed 0 == nullptr but not x ? 0 : nullptr in ISO C.) Bootstrapped and regression tested on x86_64. commit 5a29c43cca6fa5f50ad8266c5969a9420ef2488e Author: Martin Uecker Date: Sat Nov 9 10:48:52 2024

[PATCH v4] c: add Wzero-as-null-pointer-constant [PR117059]

). Bootstrapped and regression tested on x86_64. commit 599fa1480156391ad9e12e4c2bda23dee85bd11a Author: Martin Uecker Date: Sat Nov 9 10:48:52 2024 +0100 c: add Wzero-as-null-pointer-constant [PR117059] Add warnings for the use of zero as a null pointer constant to the C FE

  1   2   3   4   5   >