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

Compared to the previous version I changed the name of the warning to "Walloc-size" which matches "Wanalyzer-allocation-size" but is still in line with the other -Walloc-something warnings we have. I also added it to Wextra. I found PR71219 that requests the warning and points out that  it is r

[C PATCH 1/6 v2] c: reorganize recursive type checking

Thanks Joseph, below is a a revised version of this patch with slight additional changes to the comment of tagged_types_tu_compatible_p. ok for trunk? Martin Am Mittwoch, dem 06.09.2023 um 20:59 + schrieb Joseph Myers: > On Sat, 26 Aug 2023, Martin Uecker via Gcc-patches wr

[C PATCH] c: flag for tag compatibility rules

Add a flag to turn tag compatibility rules on or off independent from the language version. gcc/c-family: * c.opt (flag_tag_compat): New flag. gcc/c: * c-decl.cc (diagnose_mismatched_decls, start_struct, finish_struct, start_enum, finish_enum): Support flag. * c-

[C PATCH 6/6] 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 composit

[C PATCH 5/6] 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

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

Allow redefinition of enum types and enumerators. gcc/c: * c-decl.cc (start_num): Allow redefinition. (finish_enum): Diagnose conflicts. (build_enumerator): Set context. (diagnose_mismatched_decls): Diagnose conflicting enumerators. (push_decl): Preserve

[C PATCH 3/6] 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. * c-tre

[C PATCH 2/6] c23: recursive type checking of tagged type

Adapt the old and unused code for type checking for C23. gcc/c/: * c-typeck.c (struct comptypes_data): Add anon_field flag. (comptypes, comptypes_check_unum_int, comptypes_check_different_types): Remove old cache. (tagged_tu_types_compatible_p): Rewrite. --- gc

[C PATCH 1/6] c: reorganize recursive type checking

Reorganize recursive type checking to use a structure to store information collected during the recursion and returned to the caller (warning_needed, enum_and_init_p, different_types_p). gcc/c: * c-typeck.cc (struct comptypes_data): Add structure. (tagged_types_tu_compatible_p,

c23 type compatibility rules, v2

This is a revised series for the C23 rules for type compatibility. 1/6 c: reorganize recursive type checking 2/6 c23: recursive type checking of tagged type 3/6 c23: tag compatibility rules for struct and unions 4/6 c23: tag compatibility rules for enums 5/6 c23: aliasing of compatible tagged t

[committed] fix misleading identation breaking bootstrap

Committed as obvious. fix misleading identation breaking bootstrap Fix identation issue introduced by 966f3c13 "Fix format attribute for printf". gcc/c-family/ChangeLog: * c-format.cc: Fix identation. diff --git a/gcc/c-family/c-format.cc b/gcc/c-fami

c: Support for -Wuseless-cast [RR84510]

This patch adds the missing support for -Wuseless-cast to the C FE as requested by some users. It found about  50 useless casts in one of my projects without false  positives. (I also implemented a detection for various unneeded pointer casts in convert_for_assignment such as unneeded casts fro

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

I am sure this has been discussed before, but seeing that you test for a specific formula, let me point out the following: There at least three different size expression which could make sense. Consider short foo { int a; short b; char t[]; };  Most people seem to use sizeof(struct foo) + N

[C PATCH] Support typename as selector in _Generic

Clang now has an extension which accepts a typename for _Generic. This is simple to implement and is useful. Do we want this? Clang calls it a "Clang extension" in the pedantic warning. I changed it to "an extension" I am not sure what the policy is. Do we need an extra warning option? Clan

[committed] c: Less warnings for parameters declared as arrays [PR98536]

I splitted up the patch into two parts and committed only the FE parts which were already approved and the tests. This solves one of the two issues. Bootstrapped and regression tested on x86_64-pc-linux-gnu. Less warnings for parameters declared as arrays [PR98536] To avoid false

[C PATCH] _Generic should not warn in non-active branches [PR68193,PR97100]

Here is a patch to reduce false positives in _Generic. Bootstrapped and regression tested on x86_64-linux. Martin c: _Generic should not warn in non-active branches [PR68193,PR97100] To avoid false diagnostics, use c_inhibit_evaluation_warnings when a generic association is k

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

Am Mittwoch, dem 02.08.2023 um 16:45 + schrieb Qing Zhao: > > > On Aug 1, 2023, at 10:31 AM, Martin Uecker wrote: > > > > Am Dienstag, dem 01.08.2023 um 13:27 + schrieb Qing Zhao: > > > > > > > On Aug 1, 2023, at 3:51 AM, Mar

Re: [V1][PATCH 0/3] New attribute "element_count" to annotate bounds for C99 FAM(PR108896)

Am Dienstag, dem 01.08.2023 um 15:45 -0700 schrieb Kees Cook: > On Mon, Jul 31, 2023 at 08:14:42PM +, Qing Zhao wrote: > > /* In general, Due to type casting, the type for the pointee of a pointer > >does not say anything about the object it points to, > >So, __builtin_object_size can n

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

Am Dienstag, dem 01.08.2023 um 13:27 + schrieb Qing Zhao: > > > On Aug 1, 2023, at 3:51 AM, Martin Uecker via Gcc-patches > > wrote: > > > > > Hi Martin, > > > Just wondering if it'd be a good idea perhaps to warn if alloc size is >

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

Am Dienstag, dem 01.08.2023 um 02:11 +0530 schrieb Prathamesh Kulkarni: > On Fri, 21 Jul 2023 at 16:52, Martin Uecker via Gcc-patches > wrote: > > > > > > > > This patch adds a warning for allocations with insufficient size > > based on the "alloc_si

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

Am Montag, dem 31.07.2023 um 15:39 -0400 schrieb Siddhesh Poyarekar: > On 2023-07-21 07:21, Martin Uecker via Gcc-patches wrote: > > > > > > This patch adds a warning for allocations with insufficient size > > based on the "alloc_size" attribute and the

[PING 3] [PATCH] Less warnings for parameters declared as arrays [PR98541, PR98536]

Joseph, I would appreciate if you could take a look at this? This fixes the remaining issues which requires me to turn the warnings off with -Wno-vla-parameter and -Wno-nonnull in my projects. Am Montag, dem 03.04.2023 um 21:34 +0200 schrieb Martin Uecker: > > With the relatively new warning

[C PATCH]: Add Walloc-type to warn about insufficient size in allocations

This patch adds a warning for allocations with insufficient size based on the "alloc_size" attribute and the type of the pointer  the result is assigned to. While it is theoretically legal to assign to the wrong pointer type and cast it to the right type later, this almost always indicates an er

[PING 2] [PATCH] Less warnings for parameters declared as arrays [PR98541, PR98536]

Ok for gcc-14 now? Am Dienstag, dem 04.04.2023 um 19:31 -0600 schrieb Jeff Law: > > > On 4/3/23 13:34, Martin Uecker via Gcc-patches wrote: > > > > > > With the relatively new warnings (11..) affecting VLA bounds, > > I now get a lot of false positiv

Re: [PATCH] core: Support heap-based trampolines

Am Mittwoch, dem 19.07.2023 um 15:23 +0100 schrieb Iain Sandoe: > Hi Martin, > > > On 19 Jul 2023, at 11:43, Martin Uecker via Gcc-patches > > wrote: > > > > Am Mittwoch, dem 19.07.2023 um 10:29 +0100 schrieb Iain Sandoe: > > > > > On 19 Jul

Re: [PATCH] core: Support heap-based trampolines

Am Mittwoch, dem 19.07.2023 um 10:29 +0100 schrieb Iain Sandoe: > Hi Martin, > > > On 19 Jul 2023, at 10:04, Martin Uecker > > wrote: > > > > > On 17 Jul 2023, > > > > > > > > > > You mention setjmp/longjmp - on darwin and other platforms > > > requiring > > > > > non-stack based trampolines

Re: [PATCH] core: Support heap-based trampolines

> > > On 17 Jul 2023, > > >> You mention setjmp/longjmp - on darwin and other platforms > requiring > >> non-stack based trampolines > >> does the system runtime provide means to deal with this issue like > an > >> alternate allocation method > >> or a way to register cleanup? > > > > There

Re: [V1][PATCH 0/3] New attribute "element_count" to annotate bounds for C99 FAM(PR108896)

Am Montag, dem 17.07.2023 um 16:40 -0700 schrieb Kees Cook: > On Mon, Jul 17, 2023 at 09:17:48PM +, Qing Zhao wrote: > > > > > On Jul 13, 2023, at 4:31 PM, Kees Cook > > > wrote: > > > > > > In the bug, the problem is that "p" isn't known to be allocated, > > > if I'm > > > reading that corr

Re: [V1][PATCH 0/3] New attribute "element_count" to annotate bounds for C99 FAM(PR108896)

Am Dienstag, dem 18.07.2023 um 16:25 + schrieb Qing Zhao: > > > > On Jul 18, 2023, at 12:03 PM, Martin Uecker > > wrote: > > > > Am Dienstag, dem 18.07.2023 um 15:37 + schrieb Qing Zhao: > > > > > > > > > > On Jul 17, 2023, at 7:40 PM, Kees Cook > > > > wrote: > > > > > > > > On Mon

Re: [V1][PATCH 0/3] New attribute "element_count" to annotate bounds for C99 FAM(PR108896)

Am Dienstag, dem 18.07.2023 um 15:37 + schrieb Qing Zhao: > > > > On Jul 17, 2023, at 7:40 PM, Kees Cook > > wrote: > > > > On Mon, Jul 17, 2023 at 09:17:48PM +, Qing Zhao wrote: > > > > > > > On Jul 13, 2023, at 4:31 PM, Kees Cook > > > > wrote: > > > > > > > > In the bug, the probl

Re: [V1][PATCH 0/3] New attribute "element_count" to annotate bounds for C99 FAM(PR108896)

Am Donnerstag, dem 06.07.2023 um 18:56 + schrieb Qing Zhao: > Hi, Kees, > > I have updated my V1 patch with the following changes: > A. changed the name to "counted_by" > B. changed the argument from a string to an identifier > C. updated the documentation and testing cases accordingly. > > A

Re: [V1][PATCH 1/3] Provide element_count attribute to flexible array member field (PR108896)

Am Freitag, dem 16.06.2023 um 16:21 + schrieb Joseph Myers: > On Fri, 16 Jun 2023, Martin Uecker via Gcc-patches wrote: > > > > Note that no expressions can start with the '.' token at present. As > > > soon > > > as you invent a new kind o

Re: [V1][PATCH 1/3] Provide element_count attribute to flexible array member field (PR108896)

Am Donnerstag, dem 15.06.2023 um 16:55 + schrieb Joseph Myers: > On Thu, 15 Jun 2023, Qing Zhao via Gcc-patches wrote: > ... > > 1. Update the routine “c_parser_postfix_expression” (is this the right > > place? ) to accept the new designator syntax. > > Any design that might work with an exp

Re: [RFC] Add stdckdint.h header for C23

Hi Jakup, two comments which may or may not be helpful: Clang extended _Generic in a similar way: https://github.com/llvm/llvm-project/commit/12728e144994efe84715f4e5dbb8c3104e9f0b5a Although for _Generic you can achieve the same with checking for compatiblilty of pointer to the type, and I do

Re: [C PATCH 3/4] introduce ubsan checking for assigment of VM types 3/4

Am Dienstag, dem 30.05.2023 um 22:59 + schrieb Joseph Myers: > On Mon, 29 May 2023, Martin Uecker via Gcc-patches wrote: > > >     Support instrumentation of function arguments for functions > >     called via a declaration.  We can support only simple size > > Wh

Re: [C PATCH 3/4] introduce ubsan checking for assigment of VM types 3/4

c: introduce ubsan checking for assigment of VM types 3/4 Support instrumentation of function arguments for functions called via a declaration. We can support only simple size expressions without side effects, because the UBSan instrumentation is done before the call, b

Re: [C PATCH 2/4] introduce ubsan checking for assigment of VM types 2/4

c: introduce ubsan checking for assigment of VM types 2/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 UBSan checks for each bound. gc

Re: [C PATCH 4/4] introduce ubsan checking for assigment of VM types 4/4

c: introduce ubsan checking for assigment of VM types 4/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

[C PATCH 1/4] introduce ubsan checking for assigment of VM types 1/4

Hi Joseph and Martin, this series adds UBSan checking for assignment of variably-modified types, i.e. it checks that size expressions on both sides of the  assignment match. 1. no functional change, adds a structure argument to the comptypes family functions in the C FE. 2. checking for all as

Re: [V1][PATCH 2/3] Use the element_count atribute info in builtin object size [PR108896].

Thank you for working on this! Here are a couple of comments: How is the size for an object with FAM defined? There are at least three possible choices: offset(..) + N * sizeof sizeof(..) + N * sizeof or the size of a struct with the replacement array. Or is this not relevant here? I wou

[C PATCH] -Wstringop-overflow for parameters with forward-declared sizes

This is a minor change so that parameter that have forward declarations for with -Wstringop-overflow. Bootstrapped and regression tested on x86_64. c: -Wstringop-overflow for parameters with forward-declared sizes Warnings from -Wstringop-overflow do not appear for parameters d

Re: [committed] testsuite: Require trampolines for nestev-vla tests

Thanks! I will try to not forget this next time. Am Donnerstag, dem 25.05.2023 um 21:20 +0300 schrieb Dimitar Dimitrov: > Three recent test cases declare nested C functions, so they fail on > targets lacking support for trampolines. Fix by adding the necessary > filter. > > Committed as obvious

Re: [C PATCH v3] Fix ICEs related to VM types in C 2/2

Am Dienstag, dem 23.05.2023 um 10:18 +0200 schrieb Richard Biener: > On Tue, May 23, 2023 at 8:24 AM Martin Uecker > wrote: > > > > Am Dienstag, dem 23.05.2023 um 08:13 +0200 schrieb Richard Biener: > > > On Mon, May 22, 2023 at 7:24 PM Martin Uecker v

Re: [C PATCH v3] Fix ICEs related to VM types in C 2/2

Am Dienstag, dem 23.05.2023 um 08:13 +0200 schrieb Richard Biener: > On Mon, May 22, 2023 at 7:24 PM Martin Uecker via Gcc-patches > wrote: > > > > > > > > This version contains the middle-end changes for PR109450 > > and test cases as before. The main

[C PATCH v3] Fix ICEs related to VM types in C 2/2

This version contains the middle-end changes for PR109450 and test cases as before. The main middle-end change is that we use gimplify_type_sizes also for parameters and remove the special code that also walked into pointers (which is incorrect).   In addition, in the C FE this patch now also

[C PATCH v3] Fix ICEs related to VM types in C 1/2

Hi Joseph, I had to create another revision of the patch because of some case I had overlooked (vm-types pointed-to by parameters declared as I arrays). I splitted the patch up in two parts for easier reviewing. The first part only has the FE changes and most of the tests. The only minor chan

[C PATCH] Remove dead code related to type compatibility across TUs.

Repost for stage 1. C: Remove dead code related to type compatibility across TUs. Code to detect struct/unions across the same TU is not needed anymore. Code for determining compatibility of tagged types is preserved as it will be used for C2X. Some errors in the unused

[C PATCH v2] Fix ICEs related to VM types in C [PR106465, PR107557, PR108423, PR109450]

: > On Thu, 18 May 2023, Martin Uecker via Gcc-patches wrote: > > > + /* we still have to evaluate size expressions */ > > Comments should start with a capital letter and end with ". ". > > > diff --git a/gcc/testsuite/gcc.dg/nested-vla-1.c > > b/

[PING] [C PATCH] Fix ICEs related to VM types in C [PR106465, PR107557, PR108423, PR109450]

Ping. Ok, for trunk? Bootstrapped and tested on x86_64-linux-gnu with no regressions. Fix ICEs related to VM types in C [PR106465, PR107557, PR108423, PR109450] Size expressions were sometimes lost and not gimplified correctly, leading to ICEs and incorrect evaluation order

[committed, gcc 12] Fix ICE related to implicit access attributes for VLA arguments [PR105660]

Bootstrapped and regression tested on x86-64. Fix ICE related to implicit access attributes for VLA arguments [PR105660] When constructing the specifier string when merging an access attribute that encodes information about VLA arguments, the string was constructed in ran

Re: Re: GCC 12.2.1 Status Report (2023-05-02), branch frozen for release

Am Donnerstag, dem 04.05.2023 um 09:53 + schrieb Richard Biener: > On Thu, 4 May 2023, Martin Uecker wrote: > > > > > Can I please get permission for fixing this ICE? > > > > https://gcc.gnu.org/pipermail/gcc-patches/2023-April/616221.html > > Please wait until after the branch is unfrozen.

Re: Re: GCC 12.2.1 Status Report (2023-05-02), branch frozen for release

Can I please get permission for fixing this ICE? https://gcc.gnu.org/pipermail/gcc-patches/2023-April/616221.html Martin

PING [C PATCH - backport 12] Fix ICE related to implicit access attributes for VLA arguments [PR105660]

Ok for 12.3 ? Am Mittwoch, dem 19.04.2023 um 18:39 +0200 schrieb Martin Uecker: > Ok to cherrypick for 12? It is in GCC 13 and fixes an > annoying ICE. > > Martin > > > > Here is a fix for PR105660. > > Bootstrapped and regression tested on x86-64. > > > Fix ICE related to implicit

Re: [PATCH] Less warnings for parameters declared as arrays [PR98541, PR98536]

Am Dienstag, dem 04.04.2023 um 19:31 -0600 schrieb Jeff Law: > > On 4/3/23 13:34, Martin Uecker via Gcc-patches wrote: > > > > > > With the relatively new warnings (11..) affecting VLA bounds, > > I now get a lot of false positives with -Wall. In general, I find &g

[C PATCH - backport 12] Fix ICE related to implicit access attributes for VLA arguments [PR105660]

Ok to cherrypick for 12? It is in GCC 13 and fixes an annoying ICE. Martin Here is a fix for PR105660. Bootstrapped and regression tested on x86-64. Fix ICE related to implicit access attributes for VLA arguments [PR105660] When constructing the specifier string when merging

Re: Fix ICEs related to VM types in C [PR106465, PR107557, PR108424, PR109450]

Am Mittwoch, dem 12.04.2023 um 00:32 + schrieb Joseph Myers: > On Tue, 11 Apr 2023, Martin Uecker via Gcc-patches wrote: > > > Ok, here is another attempt on fixing issues with size expression. > > Not all are regressions, but it does not make sense to try to split &g

Fix ICEs related to VM types in C [PR106465, PR107557, PR108424, PR109450]

Ok, here is another attempt on fixing issues with size expression. Not all are regressions, but it does not make sense to try to split it up. Martin Fix ICEs related to VM types in C [PR106465, PR107557, PR108424, PR109450] Size expressions were sometimes lost and not gimpl

Re: [PATCH] Less warnings for parameters declared as arrays [PR98541, PR98536]

Am Dienstag, dem 04.04.2023 um 19:31 -0600 schrieb Jeff Law: > > On 4/3/23 13:34, Martin Uecker via Gcc-patches wrote: > > > > > > With the relatively new warnings (11..) affecting VLA bounds, > > I now get a lot of false positives with -Wall. In general, I find &g

[PATCH] Less warnings for parameters declared as arrays [PR98541, PR98536]

With the relatively new warnings (11..) affecting VLA bounds, I now get a lot of false positives with -Wall. In general, I find the new warnings very useful, but they seem a bit too aggressive and some minor tweaks are needed, otherwise they are too noisy. This patch suggests two changes: 1. F

Re: [PATCH] gimplify size expressions in parameters for all types [PR107557] [PR108423]

Am Dienstag, dem 21.02.2023 um 14:21 + schrieb Richard Biener: > On Tue, 21 Feb 2023, Martin Uecker wrote: > > > > > > > Hi Richard, > > > > can you look at this middle-end patch? It fixes two regressions. > > But gimplify_type_sizes recurses itself, but in particular _not_ > for pointer t

Re: [PATCH] gimplify size expressions in parameters for all types [PR107557] [PR108423]

Hi Richard, can you look at this middle-end patch? It fixes two regressions. Martin PS: I happy to do something about at variably_modified_type_p  in the middle-end, if you have a recommendation. Am Mittwoch, dem 08.02.2023 um 13:02 +0100 schrieb Martin Uecker: > > Here is a fix for PR1

[C PATCH] Detect all variably modified types [PR108375]

Here is a patch for PR108375. Bootstrapped and regession tested on x86_64-linux-gnu Also there is a middle-end patch for PR107557 and PR108423: https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611562.html and another C FE patch for PR105660: https://gcc.gnu.org/pipermail/gcc-patches/20

[C PATCH] Fix ICE related to implicit access attributes for VLA arguments [PR105660]

Here is a fix for PR105660. Bootstrapped and regression tested on x86-64. Fix ICE related to implicit access attributes for VLA arguments [PR105660] When constructing the specifier string when merging an access attribute that encodes information about VLA arguments, the string

[PATCH] gimplify size expressions in parameters for all types [PR107557] [PR108423]

Here is a fix for PR107557 and PR108423. Bootstrapped and regression tested on x86-64. Gimplify more size expression in parameters [PR107557] and [PR108234] gimplify_parm_type only recursives into pointer type and size expressions in other types (e.g. function types) were

[PATCH] regression tests for 103770 fixed on trunk

This adds regression tests for an ICE on valid code that seems gone on trunk, but the cause is still unclear. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103770 regressions tests for PR103770 This adds tests from bugzilla for PR103770 and duplicates. testsuite/gcc.dg/ * pr103770.c:

[C PATCH] (for STAGE 1) UBSan instrumentation for assignment of VM types

Here is a first patch to add UBSan instrumentation to assignment, return, initialization of pointers to variably modified types. This is based on the other patch I just sent. Separating these should make reviewing easier. Here, I did not add tests for function arguments as this is more complicat

[C PATCH] (for STAGE 1) Reorganize comptypes and related functions

Because I want to add another argument to comptypes and co. for UBSan instrumentation and this then starts to become a bit unwiedly, here is a patch to reorganize and simplify this a bit. This can wait until stage 1. (The cache can be simplified further by allocating it on the stack, but this c

Re: [C PATCH] remove same_translation_unit_p

Am Dienstag, dem 20.12.2022 um 20:04 + schrieb Joseph Myers: > On Tue, 20 Dec 2022, Martin Uecker via Gcc-patches wrote: > > > Here is a patch to remove the unused function > > same_translation_unit_p and related code. The > > code to check for structural equivalency

[C PATCH] remove same_translation_unit_p

Here is a patch to remove the unused function same_translation_unit_p and related code. The code to check for structural equivalency of structs / unions is kept (with some fixes) because it will be needed for C2X. c: Remove dead code related to type compatibility across TUs. Code to

Re: [PATCH] middle-end IFN_ASSUME support [PR106654]

Am Samstag, den 15.10.2022, 10:53 +0200 schrieb Jakub Jelinek: > On Sat, Oct 15, 2022 at 10:07:46AM +0200, Martin Uecker wrote: > > But why? Do we really want to encourage people to > > write such code? > > Of course these ++ cases inside of expressions are just obfuscation. > But the point is to

Re: [PATCH] middle-end IFN_ASSUME support [PR106654]

Am Freitag, den 14.10.2022, 23:20 +0200 schrieb Jakub Jelinek: > On Fri, Oct 14, 2022 at 10:43:16PM +0200, Martin Uecker wrote: > > Am Montag, den 10.10.2022, 10:54 +0200 schrieb Jakub Jelinek: > > > Hi! > > > > > > My earlier patches gimplify the simplest non-side-effects assumptions > > > into i

Re: [PATCH] middle-end IFN_ASSUME support [PR106654]

Am Montag, den 10.10.2022, 10:54 +0200 schrieb Jakub Jelinek: > Hi! > > My earlier patches gimplify the simplest non-side-effects assumptions > into if (cond) ; else __builtin_unreachable (); and throw the rest > on the floor. > The following patch attempts to do something with the rest too. My r

Re: [PATCH 0/2] tree-optimization/104530 - proposed re-evaluation.

> > On 2/22/2022 10:57 AM, Jakub Jelinek via Gcc-patches wrote: > > On Tue, Feb 22, 2022 at 12:39:28PM -0500, Andrew MacLeod wrote: > >>> That is EH, then there are calls that might not return because they leave > >>> in some other way (e.g. longjmp), or might loop forever, might exit, might > >>>

Re: [PATCH] Document that -fno-trampolines is for Ada only [PR100735]

> > Jeff et. al. > > > On 9 Jun 2021, at 17:23, Jeff Law via Gcc-patches > > wrote: > > On 5/25/2021 2:23 PM, Paul Eggert wrote: > >> The GCC manual's documentation of -fno-trampolines was apparently > >> written from an Ada point of view. However, when I read it I > >> understandably mistoo