Re: [PATCH v2 1/7] mangle: Introduce C typeinfo mangling API

Am Montag, dem 08.09.2025 um 20:05 -0700 schrieb Kees Cook: > On Mon, Sep 08, 2025 at 04:36:57PM -0700, Andrew Pinski wrote: > > On Mon, Sep 8, 2025 at 4:24 PM Kees Cook wrote: > > > > > > On Tue, Sep 09, 2025 at 12:13:19AM +0200, Martin Uecker wrote: > > > &g

Re: [PATCH v2 1/7] mangle: Introduce C typeinfo mangling API

Am Dienstag, dem 09.09.2025 um 00:12 +0200 schrieb Martin Uecker: > Am Montag, dem 08.09.2025 um 14:51 -0700 schrieb Kees Cook: > > On Sun, Sep 07, 2025 at 11:25:19AM +0200, Martin Uecker wrote: > > > Am Donnerstag, dem 04.09.2025 um 17:24 -0700 schrieb Kees Cook: > > >

Re: [PATCH v2 1/7] mangle: Introduce C typeinfo mangling API

Am Montag, dem 08.09.2025 um 14:51 -0700 schrieb Kees Cook: > On Sun, Sep 07, 2025 at 11:25:19AM +0200, Martin Uecker wrote: > > Am Donnerstag, dem 04.09.2025 um 17:24 -0700 schrieb Kees Cook: > > > To support the KCFI type-id which needs to convert unique function > > >

Re: [PATCH 1/2] c++: Implement P1494 and P3641 Partial program correctness [PR119060].

Am Freitag, dem 05.09.2025 um 11:46 +0200 schrieb Richard Biener: > On Fri, Sep 5, 2025 at 10:07?AM Jakub Jelinek wrote: > > > > On Fri, Sep 05, 2025 at 08:51:10AM +0100, Iain Sandoe wrote: > > > > BARRIER in RTL is like __builtin_unreachable (), so the observable > > > > checkpoint certainly can

Re: [PATCH v2 1/7] mangle: Introduce C typeinfo mangling API

Am Donnerstag, dem 04.09.2025 um 17:24 -0700 schrieb Kees Cook: > To support the KCFI type-id which needs to convert unique function > prototypes into unique 32-bit values, add a subset of the Itanium C++ > mangling ABI for C typeinfo of function prototypes, but then do > hashing, which is needed b

[C PATCH, v2] c: Warn when returning nested functions that require a non-local context.

This is the revised version adding the test to C_DECL_REGISTER. This meant I also had to change one place where it is set on function declarators before it becomes an error. Bootstrapped and regression tested on x86_64. Martin c: Warn when returning nested functions that require a non-loc

Re: [C PATCH, v2] c: Add -Wuse-after-missed-init [PR87038]

Am Donnerstag, dem 04.09.2025 um 18:22 + schrieb Joseph Myers: > On Thu, 4 Sep 2025, Martin Uecker wrote: > > > This change adds a warning -Wuse-after-missed-init which is similar to > > -Wjump-misses-init but better supports idiomatic C code by emitting a > >

[C PATCH, v2] c: Add -Wuse-after-missed-init [PR87038]

Thanks Joseph! Here is a revised path with the two issues and two typos fixed. Bootstrapped and regression tested on x86_64. c: Add -Wuse-after-missed-init [PR87038] This change adds a warning -Wuse-after-missed-init which is similar to -Wjump-misses-init but better supports i

Re: [PATCH v1 0/1] c: Add support for array parameters in _Countof

Am Mittwoch, dem 03.09.2025 um 22:03 +0200 schrieb Alejandro Colomar: > Hi Joseph, > > On Wed, Sep 03, 2025 at 03:44:28PM +, Joseph Myers wrote: > > On Wed, 3 Sep 2025, Alejandro Colomar wrote: > > > > > Hi Joseph, > > > > > > I'd like to ping about this thread. > > > > As far as I know, no

[C PATCH] c: Add -Wuse-after-missed-init [PR87038]

Here is another attempt to improve the situation with uninitialized variables. Instead of modifying -Wjump-misses-init, it adds a new warning that is called -Wuse-after-missed-init.   Thoughts? Should this go into -Wall or only -Wextra? Bootstrapped and regression tested for x86_64. Martin

Re: [PATCH v1 0/1] c: Add support for array parameters in _Countof

Am Montag, dem 18.08.2025 um 23:19 + schrieb Joseph Myers: > On Fri, 15 Aug 2025, Alejandro Colomar wrote: > > > Hi Joseph, > > > > On Thu, Aug 14, 2025 at 10:03:00PM +, Joseph Myers wrote: > > > On Thu, 14 Aug 2025, Alejandro Colomar wrote: > > > > > > > And I'm proposing it as a GNU ex

Re: [PATCH v1 1/1] c: Add support for array parameters in _Countof

Am Donnerstag, dem 14.08.2025 um 14:05 +0200 schrieb Alejandro Colomar: > Hi Martin, > > On Thu, Aug 14, 2025 at 01:37:55PM +0200, Martin Uecker wrote: > > Am Donnerstag, dem 14.08.2025 um 12:19 +0200 schrieb Alejandro Colomar: > > > Hi Martin, > > > > &g

Re: [PATCH v1 1/1] c: Add support for array parameters in _Countof

Am Donnerstag, dem 14.08.2025 um 12:19 +0200 schrieb Alejandro Colomar: > Hi Martin, > > On Thu, Aug 14, 2025 at 11:01:05AM +0200, Alejandro Colomar wrote: > > +void > > +decay_obvious (int a[2]) > > +{ > > + _Countof (typeof (a)); /* { dg-error "invalid" } */ > > + _Countof (a + 1); /* { dg-e

c: Warn when returning nested functions that require a non-local context.

This adds a warning for returning the address of a nested function where this is dangerous. c: Warn when returning nested functions that require a non-local context. This patch adds a mechanism to keep track whether nested functions require non-local context because they refere

Re: [PATCH 4/4] c: implement the defer keyword

Hi Anna, thanks for your patch! I did not have to time look at this (and I can't approve it), but here is something I noticed. You have an error for jumping into a defer block > > @@ -4244,10 +4274,29 @@ check_earlier_gotos (tree label, struct c_label_vars* > label_vars) > >if (

[C PATCH] Evaluate size expression only in the active branch of conditional operator [PR108931]

In preparation N3652, this removes some UB from the conditional operator when forming a composite type. This is an improvement also for earlier language modes (previously I submitted PR108931 for this). Bootstrapped and regression tested on x86_64. c: Evaluate size expression only in the

[C PATCH, v2] Fix ICE on invalid code involving bit fields [PR121217]

Sorry, Joseph. I am resending this because I forgot to include some fixes in the test directives in the patch before sending (I had tested it with these changes). As the only change is the dejagnu part and the rest was ok, I will wait a bit and then submit it if I do not hear any objections. B

[C PATCH] Fix ICE on invalid code involving bit fields [PR121217]

Fixes an ICE on invalid code (15/16 regression). Bootstrapped and regression tested on x86_64. c: Fix ICE on invalid code involving bit fields [PR121217] Under some error condition we can end up with NULL_TREEs for the type of bitfields, which can cause an ICE when testing for

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

Am Dienstag, dem 29.07.2025 um 13:49 + schrieb Qing Zhao: > > > On Jul 28, 2025, at 17:39, Martin Uecker wrote: > > > > Am Montag, dem 28.07.2025 um 20:48 + schrieb Qing Zhao: > > > > > > > On Jul 28, 2025, at 16:09, Martin Uecker wrote

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

Am Montag, dem 28.07.2025 um 17:45 -0700 schrieb Bill Wendling: > On Mon, Jul 28, 2025 at 4:29 PM Martin Uecker wrote: > > Am Montag, dem 28.07.2025 um 16:01 -0700 schrieb Bill Wendling: > > > On Mon, Jul 28, 2025 at 2:39 PM Martin Uecker wrote: > > > > Yes,

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

Am Montag, dem 28.07.2025 um 16:01 -0700 schrieb Bill Wendling: > On Mon, Jul 28, 2025 at 2:39 PM Martin Uecker wrote: > > Yes, forwards declarations are this simplest solution. > > > Forward declarations work until you get something complex. For > example, if we want to

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

Am Montag, dem 28.07.2025 um 23:39 +0200 schrieb Martin Uecker: > Am Montag, dem 28.07.2025 um 20:48 + schrieb Qing Zhao: > > > > > On Jul 28, 2025, at 16:09, Martin Uecker wrote: > > > > > > Am Montag, dem 28.07.2025 um 11:18 -0700 schrieb Yeoul Na: &

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

Am Montag, dem 28.07.2025 um 20:48 + schrieb Qing Zhao: > > > On Jul 28, 2025, at 16:09, Martin Uecker wrote: > > > > Am Montag, dem 28.07.2025 um 11:18 -0700 schrieb Yeoul Na: > > > > > > > > > > On Jul 28, 2025, at 10:27 AM, Qing Zhao

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

Am Montag, dem 28.07.2025 um 11:18 -0700 schrieb Yeoul Na: > > > > On Jul 28, 2025, at 10:27 AM, Qing Zhao wrote: > > > > > > > > > On Jul 26, 2025, at 12:43, Yeoul Na wrote: > > > > > > > > > > > > > On Jul 24, 2025, at 3:52 PM, Kees Cook wrote: > > > > > > > > On Thu, Jul 24, 2025 at

Re: [C PATCH] c: rewrite implementation of `arg spec' attribute.

Hi Alex, and this is how this could potentially be used in _Countof. Martin diff --git a/gcc/c/c-typeck.cc b/gcc/c/c-typeck.cc index ed6e56e7279..b46eb43bb5a 100644 --- a/gcc/c/c-typeck.cc +++ b/gcc/c/c-typeck.cc @@ -3771,6 +3771,26 @@ is_top_array_vla (tree type) return var; } + +tree

[C PATCH] c: rewrite implementation of `arg spec' attribute.

There are couple of unsolved problems and missing features related to -Wvla-parameter. I found it difficult to address these with the current implementation. Here is a patch to improve the  implementation of the `arg spec' attribute. This patch would also give us access to the type of the un

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

Am Freitag, dem 25.07.2025 um 20:07 -0700 schrieb Bill Wendling: > On Thu, Jul 24, 2025 at 2:53 PM Martin Uecker wrote: > > Am Donnerstag, dem 24.07.2025 um 14:25 -0700 schrieb Bill Wendling: > > > On Thu, Jul 24, 2025 at 8:03 AM Martin Uecker wrote: > > > > Am Do

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

Am Freitag, dem 25.07.2025 um 20:12 -0700 schrieb Bill Wendling: > On Thu, Jul 24, 2025 at 3:20 PM Martin Uecker wrote: > > Am Donnerstag, dem 24.07.2025 um 15:06 -0700 schrieb Bill Wendling: > > > > constexpr size_t size = 4; > > > > struct foo { > > &g

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

Am Donnerstag, dem 24.07.2025 um 15:06 -0700 schrieb Bill Wendling: > On Thu, Jul 24, 2025 at 11:11 AM Martin Uecker wrote: > > Am Donnerstag, dem 24.07.2025 um 16:26 + schrieb Aaron Ballman: > > > > > > constexpr size_t size = 4; > > struct foo { > >

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

Am Donnerstag, dem 24.07.2025 um 14:25 -0700 schrieb Bill Wendling: > On Thu, Jul 24, 2025 at 8:03 AM Martin Uecker wrote: > > Am Donnerstag, dem 24.07.2025 um 14:08 + schrieb Aaron Ballman: > > > On Wed, Jul 23, 2025 at 8:38 PM Martin Uecker wrote: ... > > &g

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

Am Donnerstag, dem 24.07.2025 um 19:19 + schrieb Aaron Ballman: > On Thu, Jul 24, 2025 at 6:11 PM Martin Uecker wrote: > > > > Am Donnerstag, dem 24.07.2025 um 16:26 + schrieb Aaron Ballman: > > > On Thu, Jul 24, 2025 at 3:03 PM Martin Uecker wrote: > > &

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

Am Donnerstag, dem 24.07.2025 um 16:26 + schrieb Aaron Ballman: > On Thu, Jul 24, 2025 at 3:03 PM Martin Uecker wrote: > > > > Am Donnerstag, dem 24.07.2025 um 14:08 + schrieb Aaron Ballman: > > > On Wed, Jul 23, 2025 at 8:38

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

Am Donnerstag, dem 24.07.2025 um 14:08 + schrieb Aaron Ballman: > On Wed, Jul 23, 2025 at 8:38 PM Martin Uecker wrote: > > ... > > > > That said, John McCall pointed out some usage patterns Apple has with > > > their existing feature: > > > > &

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

Am Mittwoch, dem 23.07.2025 um 12:58 -0700 schrieb Bill Wendling: > On Tue, Jul 22, 2025 at 11:22 PM Martin Uecker wrote: > > Am Montag, dem 21.07.2025 um 16:03 -0700 schrieb Bill Wendling: > > > On Mon, Jul 21, 2025 at 2:19 PM Martin Uecker wrote: > > > > ... >

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

Am Mittwoch, dem 23.07.2025 um 11:53 + schrieb Aaron Ballman: > On Wed, Jul 23, 2025 at 5:47 AM Martin Uecker wrote: > > > > This is a personal stance of mine, not a Clang community response. > > > > But this requires true collaboration, which can not > >

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

Am Mittwoch, dem 23.07.2025 um 12:34 -0700 schrieb Bill Wendling: > On Tue, Jul 22, 2025 at 10:47 PM Martin Uecker wrote: > > IMHO there are enough reasons to reject delayed parsing > > as bad design for C. We should work towards proper > > language features that cleanly

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

Am Mittwoch, dem 23.07.2025 um 00:30 -0700 schrieb Kees Cook: > On Wed, Jul 23, 2025 at 07:47:11AM +0200, Martin Uecker wrote: ... > > How would GCC want to define the syntax for expressions here? I still > think it should be possible to wire up something that matches it in > Cl

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

Am Montag, dem 21.07.2025 um 16:03 -0700 schrieb Bill Wendling: > On Mon, Jul 21, 2025 at 2:19 PM Martin Uecker wrote: > > Am Montag, dem 21.07.2025 um 04:29 -0700 schrieb Bill Wendling: > > > On Sun, Jul 20, 2025 at 4:41 AM Martin Uecker wrote: .. > > > > Re

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

IMHO there are enough reasons to reject delayed parsing as bad design for C. We should work towards proper language features that cleanly fit into the language, instead of pushing the boundaries with macros. But this requires true collaboration, which can not exist when one side is not able to

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

Am Montag, dem 21.07.2025 um 04:29 -0700 schrieb Bill Wendling: > On Sun, Jul 20, 2025 at 4:41 AM Martin Uecker wrote: > > I think the question is not whether this could be done somehow, > > but whether it should. Why design a language feature that requires > > storing

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

ing else you'd like to say or recommend. > > Disclaimer > -- > > No AI's were harmed in the making of this RFC, though one did have its > feelings > hurt. > > Share and enjoy! > -bw > > > [1] > https://discourse.llvm.org/t/rfc-b

Re: [PATCH] c: Revise -Wjump-misses-init to better support idiomatic C code [PR87038]

Am Montag, dem 16.06.2025 um 14:27 -0500 schrieb Segher Boessenkool: > On Mon, Jun 16, 2025 at 08:34:23PM +0200, Martin Uecker wrote: > > Am Montag, dem 16.06.2025 um 12:56 -0500 schrieb Segher Boessenkool: > > > So, now the warning no longer does what the name

Re: [PATCH] c: Revise -Wjump-misses-init to better support idiomatic C code [PR87038]

Am Montag, dem 16.06.2025 um 12:56 -0500 schrieb Segher Boessenkool: > Hi! > > On Sun, Jun 15, 2025 at 04:18:36PM +0200, Martin Uecker wrote: > > Instead of adding it to -Wextra, here is my attempt to improve this  > > warning as discussed in the PR and make it suitable for

[PATCH] c: Revise -Wjump-misses-init to better support idiomatic C code [PR87038]

Instead of adding it to -Wextra, here is my attempt to improve this  warning as discussed in the PR and make it suitable for -Wall. There were only two tests I had to add -Wno-jump-misses-init. Bootstrapped and regression tested for x86_64. c: Revise -Wjump-misses-init to better support i

[PATCH] c: remaining fix for the composite type inconsistency [PR120510]

Joseph, this fixes the remaining issue related to PR120510. It is related to this GNU extenions: https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Function-Prototypes.html#Function-Prototypes Here I simply override the type with the one with the prototype. This is not a perfect replacement for for

c: clean up some functions in c-typeck.cc

When looking for the casue of PR120510 I noticed there is some minor issues that make the code harder to understand which are left over from previous changes. Bootstrapped and regression tested for x86_64. c: clean up some functions in c-typeck.cc This removes two unnecessary vari

[PATCH] c: fix ICE for invalid code in generic selection [PR120303]

Small fix. Bootstrapped and regression tested for x86_64. Martin c: fix ICE for invalid code in generic selection [PR120303] Fix an error recovery ICE that occurs when a type name can not be parsed correctly in the controlling expression of a generic selection. gc

[PATCH 3/3] c: Add remove_qualifier helper function [PR120510]

Add a helper function to replace repeated code for removing qualifiers but not atomic. Make sure to also remove qualifiers but not atomic on the element type of arrays. PR c/120510 gcc/c/ChangeLog: * c-typeck.c (remove_qualifiers): New function. (composite_type_interna

[PATCH 2/3] c: partial fix for qualifier inconsistency II [PR120510]

This fixes a case where we invoke composite_type with types that do not have matching qualifiers. With this change, we can activate the checking assertion that makes sure the composite type is compatible with the two original types also for arrays. PR c/120510 gcc/c/ChangeLog:

[PATCH 1/3] c: partial fix for qualifier inconsistency [PR120510]

These three small patches fix some inconsistencies related to composite type which became apparent when moving the checking assertion. The first two are small fixes, while the third proposes to add a helper function for removing qualifers except atomic to make the code more robust. Bootstrappe

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 > > > > > > &

  1   2   3   4   5   >