[gcc r15-934] C23: allow aliasing for types derived from structs with variable size

https://gcc.gnu.org/g:d2cfe8a73b3c4195a25cde28e1641ef36ebb08c1 commit r15-934-gd2cfe8a73b3c4195a25cde28e1641ef36ebb08c1 Author: Martin Uecker Date: Fri May 24 12:35:27 2024 +0200 C23: allow aliasing for types derived from structs with variable size Previously, we set the aliasing

[gcc r15-933] C: allow aliasing of compatible types derived from enumeral types [PR115157]

https://gcc.gnu.org/g:867d1264fe71d4291194373d1a1c409cac97a597 commit r15-933-g867d1264fe71d4291194373d1a1c409cac97a597 Author: Martin Uecker Date: Sun May 19 23:13:22 2024 +0200 C: allow aliasing of compatible types derived from enumeral types [PR115157] Aliasing of enumeral

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

[gcc r15-912] C23: fix aliasing for structures/unions with incomplete types

https://gcc.gnu.org/g:86b98d939989427ff025bcfd536ad361fcdc699c commit r15-912-g86b98d939989427ff025bcfd536ad361fcdc699c Author: Martin Uecker Date: Sat Mar 30 19:49:48 2024 +0100 C23: fix aliasing for structures/unions with incomplete types When incomplete structure/union types

[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

[gcc r15-825] c: Fix for some variably modified types not being recognized [PR114831]

https://gcc.gnu.org/g:9f1798c1a93257526196a3c19828e40fb28ac551 commit r15-825-g9f1798c1a93257526196a3c19828e40fb28ac551 Author: Martin Uecker Date: Sat May 18 14:40:02 2024 +0200 c: Fix for some variably modified types not being recognized [PR114831] We did not evaluate

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: strtol(3) with QChar arguments

Am Sonntag, dem 05.05.2024 um 15:13 +0200 schrieb Alejandro Colomar: > Hi Martin, > > I was wondering why C23 didn't use QChar for strtol(3). It has the same > problems that string functions have: a const input string and a > non-const output string (the endptr). I am not sure whether strtol

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: Generated files in libgfortran for Fortran intrinsic procedures (was: Updated Sourceware infrastructure plans)

Am Donnerstag, dem 18.04.2024 um 14:01 +0200 schrieb Tobias Burnus: > Hi Janne, > > Janne Blomqvist wrote: > > back when I was active I did think about this > > issue. IMHO the best of my ideas was to convert these into C++ > > templates. I haven't looked at libgfortran but I didn't find it

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: Sourceware mitigating and preventing the next xz-backdoor

Am Samstag, dem 06.04.2024 um 15:00 +0200 schrieb Richard Biener: > On Fri, Apr 5, 2024 at 11:18 PM Andrew Sutton via Gcc wrote: > > > > > > > > > > > > > > > I think the key difference here is that Autotools allows arbitrarily > > > generated code to be executed at any time. More modern

[gcc r14-9805] Revert "Fix ICE with -g and -std=c23 related to incomplete types [PR114361]"

https://gcc.gnu.org/g:8057f9aa1f7e70490064de796d7a8d42d446caf8 commit r14-9805-g8057f9aa1f7e70490064de796d7a8d42d446caf8 Author: Martin Uecker Date: Fri Apr 5 12:14:56 2024 +0200 Revert "Fix ICE with -g and -std=c23 related to incomplete types [PR114361]" This reve

Re: Sourceware mitigating and preventing the next xz-backdoor

Am Mittwoch, dem 03.04.2024 um 13:46 -0500 schrieb Jonathon Anderson via Gcc: > Hello all, > > On Wed, 2024-04-03 at 16:00 +0200, Michael Matz wrote: > > > My take a way is that software needs to become less complex. Do  > > > we really still need complex build systems such as autoconf? > > > >

Re: Sourceware mitigating and preventing the next xz-backdoor

Am Mittwoch, dem 03.04.2024 um 18:02 +0200 schrieb Michael Matz: > Hello, > > On Wed, 3 Apr 2024, Martin Uecker wrote: > > > The backdoor was hidden in a complicated autoconf script... > > Which itself had multiple layers and could just as well have been a > complic

Re: Sourceware mitigating and preventing the next xz-backdoor

Am Mittwoch, dem 03.04.2024 um 16:00 +0200 schrieb Michael Matz: > Hello, > > On Wed, 3 Apr 2024, Martin Uecker via Gcc wrote: > > > > > Seems reasonable, but note that it wouldn't make any difference to > > > > this attack. The liblzma library was modifie

Re: Sourceware mitigating and preventing the next xz-backdoor

Am Dienstag, dem 02.04.2024 um 13:28 -0700 schrieb Ian Lance Taylor via Gcc: > > On Tue, Apr 2, 2024 at 1:21 PM Paul Koning via Gcc wrote: > > > > > > > > Would it help to require (rather than just recommend) "don't use root > > > > except for the actual 'install' step" ? > > > > Seems

[gcc r14-9763] Fix ICE with -g and -std=c23 related to incomplete types [PR114361]

https://gcc.gnu.org/g:871bb5ad2dd56343d80b6a6d269e85efdce5 commit r14-9763-g871bb5ad2dd56343d80b6a6d269e85efdce5 Author: Martin Uecker Date: Thu Mar 28 19:15:40 2024 +0100 Fix ICE with -g and -std=c23 related to incomplete types [PR114361] We did not copy TYPE_CANONICAL

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: aliasing

Am Montag, dem 18.03.2024 um 14:21 +0100 schrieb Richard Biener: > On Mon, Mar 18, 2024 at 12:56 PM Martin Uecker wrote: > > > > Am Montag, dem 18.03.2024 um 11:55 +0100 schrieb Martin Uecker: > > > Am Montag, dem 18.03.2024 um 09:26 +0100 schrieb Richard Biener: >

Re: aliasing

Am Montag, dem 18.03.2024 um 14:29 +0100 schrieb David Brown: > > On 18/03/2024 12:41, Martin Uecker wrote: > > > > > > Hi David, > > > > Am Montag, dem 18.03.2024 um 10:00 +0100 schrieb David Brown: > > > Hi, > > > >

Re: aliasing

Am Montag, dem 18.03.2024 um 11:55 +0100 schrieb Martin Uecker: > Am Montag, dem 18.03.2024 um 09:26 +0100 schrieb Richard Biener: > > On Mon, Mar 18, 2024 at 8:03 AM Martin Uecker wrote: > > > > > > > Let me give you an complication example made valid in C+

Re: aliasing

ompilers might guarantee not to do type-based alias analysis > and thus view all types as "byte types" in this way. For gcc, there > could be a kind of reverse "may_alias" type attribute to create such types. > > > > There are a number of oth

Re: aliasing

Am Montag, dem 18.03.2024 um 09:26 +0100 schrieb Richard Biener: > On Mon, Mar 18, 2024 at 8:03 AM Martin Uecker wrote: > > > > > > Hi, > > > > can you please take a quick look at this? This is intended to align > > the C standard with existing practice w

aliasing

Hi, can you please take a quick look at this? This is intended to align the C standard with existing practice with respect to aliasing by removing the special rules for "objects with no declared type" and making it fully symmetric and only based on types with non-atomic character types being

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: function parameters

Am Dienstag, dem 21.11.2023 um 02:30 + schrieb André Albergaria Coelho via Gcc: > Hello > > #include > > void func(char *ptr) { >     printf("\n%i",sizeof(ptr)); > } > > int main(void) { >     char arr[10]; >     printf("\n Sizeof arr %i",sizeof(arr)); >     func(arr); > >     

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

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

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):

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

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 1/4] c: runtime checking for assigment of VM types 1/4

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

C runtime checking for assigment of VM types

This is another revised series for checking for bounds consistency when assigning VM types. Based on feedback, I disentangled this from UBSan for  a three reasons: - I think it makes sense as a stand-alone feature similar to other run-time instrumentation features GCC already has. - Not all

[PATCH 4/4] 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 composite_type to support structs and unions. (composite_type): New wrapper function. (build_conditional_operator): Return

[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. gcc/c: * c-decl.cc (c_struct_hasher): Hash stable for struct

[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.

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

Implement redeclaration and compatibility rules for structures and unions in C23. gcc/c/: * c-decl.cc (previous_tag): New function. (get_parm_info): Turn off warning for C2X. (start_struct): Allow redefinitons. (finish_struct): Diagnose conflicts. *

c23 type compatibility rules, v3

Joseph, this is another revised series for the C23 rules for type compatibility. 1/4 c23: tag compatibility rules for struct and unions 2/4 c23: tag compatibility rules for enums 3/4 c23: aliasing of compatible tagged types 4/4 c23: construct composite type for tagged types The first two

Re: [PATCH] Reduce false positives for -Wnonnull for VLA parameters [PR98541]

Am Montag, dem 06.11.2023 um 21:01 -0700 schrieb Jeff Law: > > On 11/6/23 20:58, Hans-Peter Nilsson wrote: > > > From: Martin Uecker > > > Date: Tue, 31 Oct 2023 20:05:09 +0100 > > > > > Reduce false positives for -Wnonnull for VLA parameters [PR9

Re: RFC: the proposal to resolve the missing dependency issue for counted_by attribute

Am Freitag, dem 03.11.2023 um 07:22 +0100 schrieb Jakub Jelinek: > On Fri, Nov 03, 2023 at 07:07:36AM +0100, Martin Uecker wrote: > > Am Donnerstag, dem 02.11.2023 um 17:28 -0700 schrieb Bill Wendling: > > > On Thu, Nov 2, 2023 at 1:36 PM Qing Zhao wrote: > > > > &g

Re: RFC: the proposal to resolve the missing dependency issue for counted_by attribute

Am Donnerstag, dem 02.11.2023 um 17:28 -0700 schrieb Bill Wendling: > On Thu, Nov 2, 2023 at 1:36 PM Qing Zhao wrote: > > > > Thanks a lot for raising these issues. > > > > If I understand correctly, the major question we need to answer is: > > > > For the following example: (Jakub mentioned

Re: RFC: the proposal to resolve the missing dependency issue for counted_by attribute

Am Donnerstag, dem 02.11.2023 um 13:50 + schrieb Qing Zhao: > > > On Nov 2, 2023, at 3:57 AM, Richard Biener > > wrote: > > > > On Wed, Nov 1, 2023 at 3:47 PM Qing Zhao wrote: > > > > > > > > > > > > > On Oct 31, 2023, at 6:14 PM, Joseph Myers > > > > wrote: > > > > > > > > On Tue,

  1   2   3   4   >