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

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' object? Or do we need some refactor first in > order to keep that information? What I wanted to try is to not immediately

Re: [PATCH v3 1/4] c: runtime checking for assigment of VM types

d to be documented to inform user the > current behavior, > then the users will have an accurate expectation on what might happen with > this > option. That makes sense. > > Later some error message might need to be issued at the same time when the > trap happens. > > >

Re: C runtime checking for assigment of VM types, v3

c-patches/2024-July/657254.html > > > On Jul 15, 2024, at 16:58, Martin Uecker wrote: > > > > Am Montag, dem 15.07.2024 um 13:05 -0700 schrieb Kees Cook: > > > On Mon, Jul 15, 2024 at 07:20:31PM +0200, Martin Uecker wrote: > > > > No, there are still t

Re: C runtime checking for assigment of VM types, v3

Am Montag, dem 15.07.2024 um 13:05 -0700 schrieb Kees Cook: > On Mon, Jul 15, 2024 at 07:20:31PM +0200, Martin Uecker wrote: > > No, there are still two many missing pieces. The following > > works already > > > > int h(int n, int buf[n]) > > { > > retu

Re: C runtime checking for assigment of VM types, v3

Am Montag, dem 15.07.2024 um 09:45 -0700 schrieb Kees Cook: > On Mon, Jul 15, 2024 at 09:19:49AM +0200, Martin Uecker wrote: > > The instrumentation is guarded by a new instrumentation flag -fvla-bounds, > > but runtime overhead should generally be very low as most checks

Re: C runtime checking for assigment of VM types, v3

correct email. Am Montag, dem 15.07.2024 um 09:19 +0200 schrieb Martin Uecker: > This is the third revision for my patch series to check bounds > consistency at run-time when assigning VM types. Relative > to the last version, mostly the tests were simplified and some > coding

[PATCH v3 2/4] c: runtime checking for assigment of VM types

Support instrumentation of function arguments for functions called via a declaration. We can support only simple size expressions without side effects, because the run-time instrumentation is done before the call, but the expressions are evaluated in the callee. gcc/c: * c-typeck.cc

[PATCH v3 3/4] c: runtime checking for assigment of VM types

Support instrumentation of functions called via pointers. To do so, record the declaration with the parameter types, so that it can be retrieved later. gcc/c: c-decl.cc (get_parm_info): Record function declaration for arguments. c-typeck.cc (process_vm_constraints): Instrument functions

[PATCH v3 4/4] c: runtime checking for assigment of VM types

Add warning for the case when a function call can not be instrumented and add documentation for instrumentation of function calls. gcc/c-family/: * c.opt (Wvla-parameter-missing-check): Add warning. gcc/c/: * c-typeck.cc (process_vm_constraints): Add warning. gcc/doc/: * invoke.texi

[PATCH v3 1/4] c: runtime checking for assigment of VM types

When checking compatibility of types during assignment, collect all pairs of types where the outermost bound needs to match at run-time. This list is then processed to add runtime checks for each bound. gcc/c-family: * c-opt (fvla-bounds): New flag. gcc/c: * c-typeck.cc (struct

C runtime checking for assigment of VM types, v3

This is the third revision for my patch series to check bounds consistency at run-time when assigning VM types. Relative to the last version, mostly the tests were simplified and some coding style issues fixed. It adds a new code instrumentation option that inserts run-time checks to ensure

[PATCH v2] c: Add support for byte arrays in C2Y

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 This marks structures which include a byte array as typeless storage for all C language modes. Bootstrapped and regression tested on x86_64. c: Add support for byte arrays in C2Y To get correct aliasing behavior requires that

Re: [PATCH] Fix test errors introduced with fix for PR115157

Am Dienstag, dem 09.07.2024 um 19:11 -0300 schrieb Thiago Jung Bauermann: > Hello Martin, > > Martin Uecker writes: > > > BTW: Did you try the other testsuite patch as well? > > > > [PATCH] Fix test errors after r15-1394 for sizeof(int)==sizeof(long) > >

Re: [PATCH] c: Add support for byte arrays in C2Y

Am Dienstag, dem 09.07.2024 um 17:28 + schrieb Joseph Myers: > On Sat, 29 Jun 2024, Martin Uecker wrote: > > > + bool typeless = flag_isoc2y > > + && ((char_type_p (type) > > +&a

Re: [PATCH] Fix test errors introduced with fix for PR115157

Am Montag, dem 01.07.2024 um 14:29 -0300 schrieb Thiago Jung Bauermann: > Hello Martin, > > Martin Uecker writes: > > > This should fix the test failures introduced by the fix for PR115157. > > > > Tested on x86_64 and also tested with -m32. > > >

[PATCH] c: Diagnose declarations that are used only in their own initializer [PR115027]

Probably not entirely fool-proof when using statement expressions in initializers, but should be good enough. Bootstrapped and regression tested on x86_64. c: Diagnose declarations that are used only in their own initializer [PR115027] Track the declaration that is currently

[PATCH] c: Fix ICE for incorrect code in comptypes_verify [PR115696]

This adds missing code for handling error marks. Bootstrapped and regression tested on x86_64. c: Fix ICE for incorrect code in comptypes_verify [PR115696] The new verification code produces an ICE for incorrect code. Add the same logic as already used in comptypes to to

[PATCH] c: Fix ICE for redeclaration of structs with different alignment [PR114727]

This fixes an ICE when redeclaring a struct and having an aligned attribute in one version in C23. Bootstrapped and regression tested on x86_64. c: Fix ICE for redeclaration of structs with different alignment [PR114727] For redeclarations of struct in C23, if one has an

[PATCH] c: Add support for byte arrays in C2Y

This marks structures which include a byte array as typeless storage. Bootstrapped and regression tested on x86_64. c: Add support for byte arrays in C2Y To get correct aliasing behavior requires that structures and unions that contain a byte array, i.e. an array of

[PATCH v2] c: Error message for incorrect use of static in array declarations

Thanks Marek, here is the second version which should implement all your suggestions.   (BTW: Without the newline of the end, the test case has undefined behavior..., not that we need to care.) Bootstrapped and regression tested on x86_64. [PATCH] c: Error message for incorrect use of

[C PATCH] C: Error message for incorrect use of static in array declarations

prototype scope" is then suppressed. Bootstrapped and regression tested on x86_64. commit 1157d04764eeeb51fa1098727813dbc092e11dd2 Author: Martin Uecker Date: Sat Nov 4 14:39:19 2023 +0100 C: Error message for incorrect use of static in array declarations. Add an explicit error

[PATCH] Fix test errors introduced with fix for PR115157

This should fix the test failures introduced by the fix for PR115157. Tested on x86_64 and also tested with -m32. Fix test errors introduced with fix for PR115157. Fix tests introduced when fixing PR115157 that assume sizeof(enum)==sizeof(int) by adding the flag

[PATCH] Fix test errors after r15-1394 for sizeof(int)==sizeof(long) [PR115545]

This fixes the test failures introduced by the fix for PR115109. Tested on x86_64 and also tested with -m32. Fix test errors after r15-1394 for sizeof(int)==sizeof(long) [PR115545] Some tests added to test the type of redeclarations of enumerators in r15-1394 fail on

Re: [C PATCH] Fix ICE related to incomplete structures in C23 [PR114930,PR115502].

Am Mittwoch, dem 19.06.2024 um 08:57 +0200 schrieb Richard Biener: > On Wed, 19 Jun 2024, Martin Uecker wrote: > > > Am Mittwoch, dem 19.06.2024 um 08:04 +0200 schrieb Richard Biener: > > > > > > > Am 18.06.2024 um 20:18 schrieb Martin Uecker : > > > >

Re: [C PATCH] Fix ICE related to incomplete structures in C23 [PR114930,PR115502].

Am Mittwoch, dem 19.06.2024 um 08:29 +0200 schrieb Jakub Jelinek: > On Wed, Jun 19, 2024 at 08:04:55AM +0200, Richard Biener wrote: > > > > Note a canonical type should always be unqualified (for > > > > classical qualifiers, not address space or atomic qualification) > > > > > > The logic in

Re: [C PATCH] Fix ICE related to incomplete structures in C23 [PR114930,PR115502].

Am Mittwoch, dem 19.06.2024 um 08:04 +0200 schrieb Richard Biener: > > > Am 18.06.2024 um 20:18 schrieb Martin Uecker : > > > > Am Dienstag, dem 18.06.2024 um 17:27 +0200 schrieb Richard Biener: > > > > > > > >

assumed size

Hi all, I am working paper for the following syntax extension int a[10]; int (*a)[*] = This would not be a wide pointer, it will just initialize the size of the type from the initializer. This would also work for VM type. So the result is a conventional pointer to an arrays and either a

Re: [C PATCH] Fix ICE related to incomplete structures in C23 [PR114930,PR115502].

Am Dienstag, dem 18.06.2024 um 17:27 +0200 schrieb Richard Biener: > > > Am 18.06.2024 um 17:20 schrieb Martin Uecker : > > > >  > > As discussed this replaces the use of check_qualified_type with > > a simple check for qualifiers as suggested by Jakub in >

[C PATCH] Fix ICE related to incomplete structures in C23 [PR114930,PR115502].

As discussed this replaces the use of check_qualified_type with a simple check for qualifiers as suggested by Jakub in c_update_type_canonical. Martin Bootstrapped and regression tested on x86_64. C23: Fix ICE related to incomplete structures [PR114930,PR115502]. The fix for

[C PATCH, v4] Fix for redeclared enumerator initialized with different type [PR115109]

specifies that the type of a redeclared enumerator is the one of the previous declaration. Convert initializers with different type accordingly and emit an error when the value does not fit. 2024-06-01 Martin Uecker PR c/115109 gcc/c/ * c-decl.cc

Re: [C PATCH, v3] Fix for redeclared enumerator initialized with different type [PR115109]

The patch fails on arm because the tests make assumptions about enums that are not true everywhere. Should we just  limit the tests to x86? Martin Am Montag, dem 03.06.2024 um 17:37 + schrieb Joseph Myers: > On Sat, 1 Jun 2024, Martin Uecker wrote: > > > This is a new version

Re: [PATCH] c: Fix up pointer types to may_alias structures [PR114493]

Am Dienstag, dem 04.06.2024 um 08:33 +0200 schrieb Jakub Jelinek: > Hi! > > The following testcase ICEs in ipa-free-lang, because the > fld_incomplete_type_of > gcc_assert (TYPE_CANONICAL (t2) != t2 > && TYPE_CANONICAL (t2) == TYPE_CANONICAL (TREE_TYPE > (t))); >

[C PATCH, v3] Fix for redeclared enumerator initialized with different type [PR115109]

of a redeclared enumerator is the one of the previous declaration. Convert initializers with different type accordingly and emit an error when the value does not fit. 2024-06-01 Martin Uecker PR c/115109 gcc/c/ * c-decl.cc (build_enumerator): When

Re: [C PATCH, v2]: allow aliasing of compatible types derived from enumeral types [PR115157]

tag, dem 24.05.2024 um 17:39 +0200 schrieb Martin Uecker: > This is another version of this patch with two changes: > > - I added a fix (with test) for PR 115177 which is just the same > issue for hardbools which are internally implemented as enums. > > - I fixed the golang issu

[C23 PATCH]: allow aliasing for types derived from structs with variable size

This is similar to the enum issue, where setting the alias set to zero is insufficient because also derived types need to be able to alias. After this change, it is also possible to add checking assertions that verify TYPE_CANONICAL for all tagged types at end of each call to the comptypes

[C23 PATCH, v2] fix aliasing for structures/unions with incomplete types

This is the patch I sent previously, but I tried to improve the description and added a long comment. This patch is needed so that we do not have to update TYPE_CANONICAL of structures / unions when a tagged type is completed that is (recursively) pointed to  by a member of the structure /

[C PATCH, v2]: allow aliasing of compatible types derived from enumeral types [PR115157]

This is another version of this patch with two changes: - I added a fix (with test) for PR 115177 which is just the same issue for hardbools which are internally implemented as enums. - I fixed the golang issue. Since the addition of the main variant to the seen decls is unconditional I

Re: [C PATCH]: allow aliasing of compatible types derived from enumeral types [PR115157]

Am Donnerstag, dem 23.05.2024 um 14:30 -0700 schrieb Ian Lance Taylor: > On Thu, May 23, 2024 at 2:00 PM Joseph Myers wrote: > > > > On Tue, 21 May 2024, Martin Uecker wrote: > > > > > > C: allow aliasing of compatible types derived fro

[C PATCH]: allow aliasing of compatible types derived from enumeral types [PR115157]

For enum and integer we allow aliasing by specifically returning via a langhook the aliasing set of the underlying type. But this is not sufficient for derived types, i.e. pointers to enums and pointers to compatible integers also need to have the same aliasing set. We also allow forward

Re: [C PATCH, v2] Fix for redeclared enumerator initialized with different type [PR115109]

Am Montag, dem 20.05.2024 um 21:30 + schrieb Joseph Myers: > On Sun, 19 May 2024, Martin Uecker wrote: > > > c23 specifies that the type of a redeclared enumerator is the one of the > > previous declaration. Convert initializers with different type > > acc

[C PATCH, v2] Fix for redeclared enumerator initialized with different type [PR115109]

of the previous declaration. Convert initializers with different type accordingly and add -Woverflow warning. 2024-05-18 Martin Uecker PR c/115109 gcc/c/ * c-decl.cc (build_enumerator): When redeclaring an enumerator convert value to previous

[C PATCH] Fix for redeclared enumerator initialized with different type [PR115109]

and add -Woverflow warning. 2024-05-18 Martin Uecker PR c/115109 gcc/c/ * c-decl.cc (build_enumerator): When redeclaring an enumerator convert value to previous type. gcc/testsuite/ * gcc.dg/pr115109.c: New test

Re: [C PATCH] Fix for some variably modified types not being recognized [PR114831]

in typeof and did not produce warnings when jumping over declarations > using typeof. After addressof or array-to-pointer decay we construct > new pointer types that have to be marked variably modified if the pointer > target is variably modified. > > 2024-0

[C PATCH] Fix for some variably modified types not being recognized [PR114831]

. After addressof or array-to-pointer decay we construct new pointer types that have to be marked variably modified if the pointer target is variably modified. 2024-05-18 Martin Uecker PR c/114831 gcc/c/ * c-typeck.cc (array_to_pointer_conversion

Re: [PATCH] middle-end/114931 - type_hash_canon and structual equality types

Am Montag, dem 06.05.2024 um 11:07 +0200 schrieb Richard Biener: > On Mon, 6 May 2024, Martin Uecker wrote: > > > Am Montag, dem 06.05.2024 um 09:00 +0200 schrieb Richard Biener: > > > On Sat, 4 May 2024, Martin Uecker wrote: > > > > > > > Am Freitag, d

Re: [PATCH] middle-end/114931 - type_hash_canon and structual equality types

Am Montag, dem 06.05.2024 um 09:00 +0200 schrieb Richard Biener: > On Sat, 4 May 2024, Martin Uecker wrote: > > > Am Freitag, dem 03.05.2024 um 21:16 +0200 schrieb Jakub Jelinek: > > > > On Fri, May 03, 2024 at 09:11:20PM +0200, Martin Uecker wrote: > > >

Re: [PATCH] middle-end/114931 - type_hash_canon and structual equality types

Am Freitag, dem 03.05.2024 um 21:16 +0200 schrieb Jakub Jelinek: > > On Fri, May 03, 2024 at 09:11:20PM +0200, Martin Uecker wrote: > > > > > > TYPE_CANONICAL as used by the middle-end cannot express this but > > > > > > > > Hm. so how does it work

Re: [PATCH] middle-end/114931 - type_hash_canon and structual equality types

Am Freitag, dem 03.05.2024 um 20:48 +0200 schrieb Richard Biener: > > > Am 03.05.2024 um 20:37 schrieb Martin Uecker : > > > > Am Freitag, dem 03.05.2024 um 20:18 +0200 schrieb Jakub Jelinek: > > > > On Fri, May 03, 2024 at 08:04:18PM +0200, Mart

Re: [PATCH] middle-end/114931 - type_hash_canon and structual equality types

Am Freitag, dem 03.05.2024 um 20:18 +0200 schrieb Jakub Jelinek: > On Fri, May 03, 2024 at 08:04:18PM +0200, Martin Uecker wrote: > > A change that is not optimal but would avoid a lot of trouble is to > > only use the tag of the struct for computing a TYPE_CANONICAL, which > &

Re: [PATCH] middle-end/114931 - type_hash_canon and structual equality types

Am Freitag, dem 03.05.2024 um 19:30 +0200 schrieb Jakub Jelinek: > On Fri, May 03, 2024 at 05:32:12PM +0200, Martin Uecker wrote: > > Am Freitag, dem 03.05.2024 um 14:13 +0200 schrieb Richard Biener: > > > TYPE_STRUCTURAL_EQUALITY_P is part of our type system so we have

Re: [PATCH] middle-end/114931 - type_hash_canon and structual equality types

Am Freitag, dem 03.05.2024 um 18:23 +0200 schrieb Richard Biener: > > > Am 03.05.2024 um 17:33 schrieb Martin Uecker : > > > > Am Freitag, dem 03.05.2024 um 14:13 +0200 schrieb Richard Biener: > > > TYPE_STRUCTURAL_EQUALITY_P is part of our type system so we have

Re: [PATCH] middle-end/114931 - type_hash_canon and structual equality types

Am Freitag, dem 03.05.2024 um 14:13 +0200 schrieb Richard Biener: > TYPE_STRUCTURAL_EQUALITY_P is part of our type system so we have > to make sure to include that into the type unification done via > type_hash_canon. This requires the flag to be set before querying > the hash which is the

Re: [C PATCH, v2] Fix ICE with -g and -std=c23 related to incomplete types [PR114361]

(new email for Joseph) Am Sonntag, dem 14.04.2024 um 14:30 +0200 schrieb Martin Uecker: > I had to revert the old patch because it broke LTO which lead > to PR114574. We now set TYPE_STRUCTURAL_EQUALITY and properly > update TYPE_CANONICAL for such types and also for pointers > t

[C PATCH, v2] Fix ICE with -g and -std=c23 related to incomplete types [PR114361]

for discussion. 2024-04-12 Martin Uecker Jakub Jelinek PR lto/114574 PR c/114361 gcc/ * ipa-free-lang-data.cc (fld_incomplete_type_of): Allow either of the types in the assert to have TYPE_STRUCTURAL_EQUALITY_P. gcc/c/ * c-decl.cc

Re: [PATCH v8 1/5] Provide counted_by attribute to flexible array member field (PR108896)

Am Mittwoch, dem 10.04.2024 um 19:35 + schrieb Qing Zhao: > > > On Apr 10, 2024, at 15:05, Martin Uecker wrote: > > > > Am Mittwoch, dem 10.04.2024 um 20:25 +0200 schrieb Martin Uecker: > > > Am Mittwoch, dem 10.04.2024 um 17:35 + schrieb Joseph Myers: >

Re: [PATCH v8 1/5] Provide counted_by attribute to flexible array member field (PR108896)

Am Mittwoch, dem 10.04.2024 um 20:25 +0200 schrieb Martin Uecker: > Am Mittwoch, dem 10.04.2024 um 17:35 + schrieb Joseph Myers: > > On Fri, 29 Mar 2024, Qing Zhao wrote: > > > > > + /* Issue error when there is a counted_by attribute with a different > >

Re: [PATCH v8 1/5] Provide counted_by attribute to flexible array member field (PR108896)

Am Mittwoch, dem 10.04.2024 um 17:35 + schrieb Joseph Myers: > On Fri, 29 Mar 2024, Qing Zhao wrote: > > > + /* Issue error when there is a counted_by attribute with a different > > + field as the argument for the same flexible array member field. */ > > There's another case of this to

Re: [C PATCH] fix aliasing for structures/unions with incomplete types

Am Dienstag, dem 02.04.2024 um 20:42 + schrieb Joseph Myers: > On Tue, 2 Apr 2024, Martin Uecker wrote: > > > [C23]fix aliasing for structures/unions with incomplete types > > > > When incomplete structure/union types are completed later, compatibility > >

[C PATCH] fix aliasing for structures/unions with incomplete types

While fixing the other issue, I realized that the way the equivalence classes are computed for TYPE_CANONICAL did not take into account that completion of struct types also affectes compatibility of types that contain pointers to them. So the algorithm must be more conservative creating bigger

[C PATCH] Fix ICE with -g and -std=c23 related to incomplete types [PR114361]

I did not copy TYPE_CANONICAL to incomplete variants when they are completed. Bootstrapped and regession tested on x86_64 Fix ICE with -g and -std=c23 related to incomplete types [PR114361] We did not copy TYPE_CANONICAL to the incomplete variants when completing a structure.

Re: [PATCH v4 0/4]New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

Am Montag, dem 29.01.2024 um 15:09 + schrieb Qing Zhao: > Thank you! > > Joseph and Richard, could you also comment on this? > > > On Jan 28, 2024, at 5:09 AM, Martin Uecker wrote: > > > > Am Freitag, dem 26.01.2024 um 14:33 + schrieb Qing Zhao: > >

Re: [PATCH v4 0/4]New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

Am Freitag, dem 26.01.2024 um 14:33 + schrieb Qing Zhao: > > > On Jan 26, 2024, at 3:04 AM, Martin Uecker wrote: > > > > > > I haven't looked at the patch, but it sounds you give the result > > the wrong type. Then patching up all use cases instead of t

Fix ICE with -g and -std=c23 when forming composite types [PR113438]

Debug output ICEs when we do not set TYPE_STUB_DECL, fix this. Fix ICE with -g and -std=c23 when forming composite types [PR113438] Set TYPE_STUB_DECL to an artificial decl when creating a new structure as a composite type. PR c/113438 gcc/c/

Re: [PATCH v4 0/4]New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

I haven't looked at the patch, but it sounds you give the result the wrong type. Then patching up all use cases instead of the type seems wrong. Martin Am Donnerstag, dem 25.01.2024 um 20:11 + schrieb Qing Zhao: > Thanks a lot for the testing. > > Yes, I can repeat the issue with the

[C PATCH] Fix ICE for composite type for structs with unsigned bitfields [PR113492]

C23: Fix ICE for composite type for structs with unsigned bitfields [PR113492] This patch fixes a bug when forming a composite type from structs that contain an unsigned bitfield declared with int while using -funsigned-bitfields. In such structs the unsigned integer type was not compatible

[C PATCH] C: Fix type compatibility for structs with variable sized fields.

This patch hopefully fixes the test failure we see with gnu23-tag-4.c. It does for me locally with -march=native (which otherwise reproduces the problem). Bootstrapped and regession tested on x86_64 C: Fix type compatibility for structs with variable sized fields. This fixes the test

Re: [r14-6770 Regression] FAIL: gcc.dg/gnu23-tag-4.c (test for excess errors) on Linux/x86_64

ochen > > > -Original Message- > > From: Martin Uecker > > Sent: Friday, December 22, 2023 5:39 PM > > To: gcc-regress...@gcc.gnu.org; gcc-patches@gcc.gnu.org; Jiang, Haochen > > ; Joseph Myers > > Subject: Re: [r14-6770 Regression] FAIL:

Re: [r14-6770 Regression] FAIL: gcc.dg/gnu23-tag-4.c (test for excess errors) on Linux/x86_64

ad commit > commit 23fee88f84873b0b8b41c8e5a9b229d533fb4022 > Author: Martin Uecker > Date: Tue Aug 15 14:58:32 2023 +0200 > > c23: tag compatibility rules for struct and unions > > caused > > FAIL: gcc.dg/gnu23-tag-4.c (test for excess errors) > > with GC

[V6] c23: construct composite type for tagged types

This version now sets DECL_NONADDRESSABLE_P, DECL_PADDING_P and C_DECL_VARIABLE_SIZE and adds three new tests: c23-tag-alias-7.c, c23-tag-composite-10.c, and gnu23-tag-composite-5.c. Martin Support for constructing composite types for structs and unions in C23. gcc/c: *

Re: [PATCH] c: Split -Wcalloc-transposed-args warning from -Walloc-size, -Walloc-size fixes

Am Dienstag, dem 19.12.2023 um 12:20 -0500 schrieb Jason Merrill: > On 12/19/23 03:47, Jakub Jelinek wrote: > > On Tue, Dec 19, 2023 at 08:11:11AM +0100, Martin Uecker wrote: > > > Am Montag, dem 18.12.2023 um 20:14 +0100 schrieb Jakub Jelinek: > > > > Hi! > &

Re: [PATCH] c: Split -Wcalloc-transposed-args warning from -Walloc-size, -Walloc-size fixes

Am Dienstag, dem 19.12.2023 um 09:47 +0100 schrieb Jakub Jelinek: > On Tue, Dec 19, 2023 at 08:11:11AM +0100, Martin Uecker wrote: > > Am Montag, dem 18.12.2023 um 20:14 +0100 schrieb Jakub Jelinek: > > > Hi! > > > > > > The following patch changes -W

Re: [PATCH] c: Split -Wcalloc-transposed-args warning from -Walloc-size, -Walloc-size fixes

Am Montag, dem 18.12.2023 um 20:14 +0100 schrieb Jakub Jelinek: > Hi! > > The following patch changes -Walloc-size warning to no longer warn > about int *p = calloc (1, sizeof (int));, because as discussed earlier, > the size is IMNSHO sufficient in that case, for alloc_size with 2 > arguments

[V5] [C PATCH 4/4] c23: construct composite type for tagged types

Support for constructing composite types for structs and unions in C23. gcc/c: * c-typeck.cc (composite_type_internal): Adapted from composite_type to support structs and unions. (composite_type): New wrapper function. (build_conditional_operator): Return

[V5] [C PATCH 3/4] c23: aliasing of compatible tagged types

Tell the backend which types are equivalent by setting TYPE_CANONICAL to one struct in the set of equivalent structs. Structs are considered equivalent by ignoring all sizes of arrays nested in types below field level. The following two structs are incompatible and lvalues with these types

[V5] [C PATCH 2/4] c23: tag compatibility rules for enums

Allow redefinition of enum types and enumerators. Diagnose nested redefinitions including redefinitions in the enum specifier for enum types with fixed underlying type. gcc/c: * c-tree.h (c_parser_enum_specifier): Add parameter. * c-decl.cc (start_enum): Allow redefinition.

[V5] [C PATCH 1/4] c23: tag compatibility rules for struct and unions

Here is the revised series. The first three patches only have changes in the tests as well as the return value changes.   The fourth patch was now also revised, with changes and tests to make sure that the composite type works correctly for bit-fields, anonymous structs/unions, alignment,

v2 [C PATCH] Fix regression causing ICE for structs with VLAs [PR 112488]

I revised version which fixes a problem with breaking other callers of finish_rust. Please ignore the previous one. Bootstrapped and regression tested on x86_64 Fix regression causing ICE for structs with VLAs [PR 112488] A previous patch the fixed several ICEs related to size expressions of

[C PATCH] Fix regression causing ICE for structs with VLAs [PR 112488]

This fixes a regression caused by my previous VM fixes. Fix regression causing ICE for structs with VLAs [PR 112488] A previous patch the fixed several ICEs related to size expressions of VM types (PR c/70418, ...) caused a regression for structs where a DECL_EXPR is not generated anymore

Re: [C PATCH, v2] Add Walloc-size to warn about insufficient size in allocations [PR71219]

Am Mittwoch, dem 06.12.2023 um 16:01 +0100 schrieb Jakub Jelinek: > On Wed, Dec 06, 2023 at 03:56:10PM +0100, Martin Uecker wrote: > > > That would be my preference because then the allocation size is > > > correct and it is purely a style warning. > > > It

Re: [C PATCH, v2] Add Walloc-size to warn about insufficient size in allocations [PR71219]

Am Mittwoch, dem 06.12.2023 um 15:21 +0100 schrieb Jakub Jelinek: > On Wed, Dec 06, 2023 at 02:34:10PM +0100, Martin Uecker wrote: > > > Further I think > > > "size less than or equal to the size requested" > > > is quite ambiguous in the calloc case, isn'

Re: [C PATCH, v2] Add Walloc-size to warn about insufficient size in allocations [PR71219]

Am Mittwoch, dem 06.12.2023 um 14:34 +0100 schrieb Martin Uecker: > Am Mittwoch, dem 06.12.2023 um 13:57 +0100 schrieb Jakub Jelinek: > > On Wed, Dec 06, 2023 at 08:31:12PM +0800, Xi Ruoyao wrote: > > > On Wed, 2023-12-06 at 13:24 +0100, Jakub Jelinek wrote: > > > > I

Re: [C PATCH, v2] Add Walloc-size to warn about insufficient size in allocations [PR71219]

fferent > > > between either order of arguments) isn't it completely valid to allocate > > > char array with sizeof (struct S) elements and then store a struct S > > > object > > > into it? > > > > In PR112364 Martin Uecker has pointed out the alignment m

Re: [gcc15] nested functions in C

Am Dienstag, dem 05.12.2023 um 21:08 + schrieb Joseph Myers: > On Mon, 4 Dec 2023, Martin Uecker wrote: > > > > The key feature of lambdas (which failed to make it into C23) for this > > > purpose is that you can't convert them to function pointers, which &

Re: [gcc15] nested functions in C

Am Montag, dem 04.12.2023 um 19:51 +0100 schrieb Jakub Jelinek: > On Mon, Dec 04, 2023 at 01:27:32PM -0500, Siddhesh Poyarekar wrote: > > [Branching this into a separate conversation to avoid derailing the patch, > > which isn't directly related] > > > > On 2023-12-04

Re: [gcc15] nested functions in C

Am Montag, dem 04.12.2023 um 15:35 -0500 schrieb Siddhesh Poyarekar: > On 2023-12-04 13:48, Martin Uecker wrote: > > > I empathize with Jakub's stated use case though of keeping the C > > > frontend support for testing purposes, but that could easily be done > > >

Re: [gcc15] nested functions in C

Am Montag, dem 04.12.2023 um 21:33 + schrieb Joseph Myers: > On Mon, 4 Dec 2023, Siddhesh Poyarekar wrote: > > > On 2023-12-04 13:48, Martin Uecker wrote: > > > > I empathize with Jakub's stated use case though of keeping the C > > > > frontend support

Re: [gcc15] nested functions in C

Am Montag, dem 04.12.2023 um 13:27 -0500 schrieb Siddhesh Poyarekar: > [Branching this into a separate conversation to avoid derailing the > patch, which isn't directly related] > > On 2023-12-04 12:21, Martin Uecker wrote: > > I do not really agree with that. Nested functions

Re: [PATCH] gcc: Disallow trampolines when -fhardened

Am Montag, dem 04.12.2023 um 11:46 -0500 schrieb Siddhesh Poyarekar: > On 2023-12-04 11:39, Andreas Schwab wrote: > > On Dez 04 2023, Siddhesh Poyarekar wrote: > > > > > For hardened code in C, I think we really should look to step away from > > > nested functions instead of adding ways to

Re: [PATCH] gcc: Disallow trampolines when -fhardened

> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > -- >8 -- > It came up that a good hardening strategy is to disable trampolines > which may require executable stack. Therefore the following patch > adds -Werror=trampolines to -fhardened. This would add a warning about

Re: [PATCH 3/4] c23: aliasing of compatible tagged types

Am Dienstag, dem 28.11.2023 um 10:47 + schrieb Richard Biener: > On Tue, 28 Nov 2023, Joseph Myers wrote: > > > On Sun, 26 Nov 2023, Martin Uecker wrote: > > > > > > > I also think more rationale is needed for ignoring sizes like this. Is > > &

Re: [PATCH 3/4] c23: aliasing of compatible tagged types

Am Dienstag, dem 28.11.2023 um 01:00 + schrieb Joseph Myers: > On Sun, 26 Nov 2023, Martin Uecker wrote: > > > My understand is that it is used for aliasing analysis and also > > checking of conversions. TYPE_CANONICAL must be consistent with > > the idea the m

Re: Ping: [PATCH] Fix PR112419

Am Montag, dem 27.11.2023 um 16:54 +0100 schrieb Martin Uecker: > Am Montag, dem 27.11.2023 um 08:36 -0700 schrieb Jeff Law: > > > > On 11/23/23 10:05, Hans-Peter Nilsson wrote: > > > > From: Hans-Peter Nilsson > > > > Date: Thu, 16 Nov 2023 05:24:06 +0100

Re: Ping: [PATCH] Fix PR112419

Am Montag, dem 27.11.2023 um 08:36 -0700 schrieb Jeff Law: > > On 11/23/23 10:05, Hans-Peter Nilsson wrote: > > > From: Hans-Peter Nilsson > > > Date: Thu, 16 Nov 2023 05:24:06 +0100 > > > > > > > From: Martin Uecker > > > > Date: Tue,

[V4] [PATCH 3/4] c23: aliasing of compatible tagged types

(this mostly got an extended description and more comments, also tests were reorganized) c23: aliasing of compatible tagged types Tell the backend which types are equivalent by setting TYPE_CANONICAL to one struct in the set of equivalent structs. Structs are considered equivalent by

[V4] [PATCH 4/4] c23: construct composite type for tagged types

(this patch was still not updated and needs more work, so only included now for completeness) c23: construct composite type for tagged types Support for constructing composite type for structs and unions in C23. gcc/c: * c-typeck.cc (composite_type_internal): Adapted from

[V4] [PATCH 2/4] c23: tag compatibility rules for enums

(only tests were changed) c23: tag compatibility rules for enums Allow redefinition of enum types and enumerators. Diagnose nested redefinitions including redefinitions in the enum specifier for enum types with fixed underlying type. gcc/c: * c-tree.h (c_parser_enum_specifier): Add

[V4] [C PATCH 1/4] c23: tag compatibility rules for struct and unions

Note that there is an additional change in parser_xref_tag to address the issue regarding completeness in redefinition which affects also structs / unions. The test c23-tag-6.c was changed accordingly. c23: tag compatibility rules for struct and unions Implement redeclaration and

Re: [PATCH 3/4] c23: aliasing of compatible tagged types

Thanks Joseph, I will sent an updated series tomorrow. Richard, maybe you could look at what I wrote below about my use of TYPE_CANONICAL ? Does this make sense? Am Donnerstag, dem 23.11.2023 um 23:47 + schrieb Joseph Myers: > On Thu, 16 Nov 2023, Martin Uecker wrote: > &g

Re: [PATCH] c-family, middle-end: Add __builtin_c[lt]zg (arg, 0ULL) exception

(corrected address) > On Mon, 20 Nov 2023, Jakub Jelinek wrote: > > > On Mon, Nov 20, 2023 at 08:37:55AM +, Richard Biener wrote: > > > > I'm not sure about that, it would be nice for them to be usable there, > > > > > > Btw, I think that {( .. )} should be made usable in sizeof () and >

[PATCH 4/4] c: runtime checking for assigment of VM types 4/4

Add warning for the case when a function call can not be instrumened. gcc/c-family/: * c.opt (Wvla-parameter-missing-check): Add warning. gcc/c/: * c-typeck.cc (process_vm_constraints): Add warning. gcc/doc/: * invoke.texi (Wvla-parameter-missing-check): Document

  1   2   3   >