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
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
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
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
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
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
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
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 reverts commit
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?
> >
> >
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
> complicated cmake function.
Don't
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
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
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
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:
> > > > On Mon, Mar 18, 2024 at
d somewhat
> meaningless as a type name for a raw byte of memory or a minimal sized
> unsigned integer.
>
> Of course most alternative names for bytes would be typedefs of
> "unsigned char" and therefore work just the same way. But as noted
> before, uint8_t could
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++:
> >
> > struct B { float x;
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
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 with respect to aliasing by
> > removing
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
Am Mittwoch, dem 20.09.2023 um 13:40 -0700 schrieb Kees Cook via Gcc:
> On Sat, Sep 16, 2023 at 10:36:52AM +0200, Martin Uecker wrote:
> > > On Fri, Sep 15, 2023 at 08:18:28AM -0700, Andrew Pinski wrote:
> > > > On Fri, Sep 15, 2023 at 8:12 AM Qing Zhao wrote:
> > > > >
> > > > >
> > > > >
> >
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
Am Montag, dem 18.09.2023 um 10:47 +0200 schrieb Richard Biener via Gcc:
> On Mon, Sep 18, 2023 at 10:17 AM Martin Uecker wrote:
> >
> > Am Montag, dem 18.09.2023 um 09:31 +0200 schrieb Richard Biener via Gcc:
> > > On Sat, Sep 16, 2023 at 10:38 AM Martin Ueck
Am Montag, dem 18.09.2023 um 09:31 +0200 schrieb Richard Biener via Gcc:
> On Sat, Sep 16, 2023 at 10:38 AM Martin Uecker via Gcc
> wrote:
> >
> >
> >
> > (moved to gcc@)
> >
> > > On Fri, Sep 15, 2023 at 08:18:28AM -0700, Andrew Pinski wrote:
(moved to gcc@)
> On Fri, Sep 15, 2023 at 08:18:28AM -0700, Andrew Pinski wrote:
> > On Fri, Sep 15, 2023 at 8:12 AM Qing Zhao wrote:
> > >
> > >
> > >
> > > > On Sep 15, 2023, at 3:43 AM, Xi Ruoyao wrote:
> > > >
> > > > On Thu, 2023-09-14 at 21:41 +, Qing Zhao wrote:
> > > CLANG
Am Dienstag, dem 12.09.2023 um 11:25 +0200 schrieb Richard Biener via Gcc:
> On Tue, Sep 5, 2023 at 10:44 PM Toon Moene wrote:
> >
> > This is going to be an interesting discussion.
> >
> > In the upcoming GNU Tools Cauldron meeting the representation of complex
> > numbers in GCC will be
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
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.
*
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
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
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
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.
*
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.
---
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.
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
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
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
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
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?
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
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
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
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
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
> &g
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
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 t
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
Hi all,
is it still possible to have user branches in the repository?
If so, how do I create one? Simply pushing to users/uecker/vla
or something is rejected.
Martin
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
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
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
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
>
> > 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?
> >
> >
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
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
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
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.
>
>
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 of expressi
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
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
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
>
>
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,
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.
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
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
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
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
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
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
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
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
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
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
Am Donnerstag, dem 18.05.2023 um 20:59 + schrieb Qing Zhao:
>
> > On May 18, 2023, at 12:25 PM, Martin Uecker via Gcc wrote:
> >
> >
> >
> > > On Thu, May 11, 2023 at 11:14 PM Kees Cook via Gcc
> > > wrote:
> > > >
> > &
:
> 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/
> On Thu, May 11, 2023 at 11:14 PM Kees Cook via Gcc wrote:
> >
> > On Thu, May 11, 2023 at 08:53:52PM +, Joseph Myers wrote:
> > > On Thu, 11 May 2023, Kees Cook via Gcc wrote:
> > >
> > > > On Thu, May 11, 2023 at 06:29:10PM +0200, Alejandro Colomar wrote:
> > > > > On 5/11/23 18:07,
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
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
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
Can I please get permission for fixing this ICE?
https://gcc.gnu.org/pipermail/gcc-patches/2023-April/616221.html
Martin
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
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
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
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
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
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
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.
Am Freitag, dem 24.02.2023 um 10:01 -0600 schrieb Serge E. Hallyn:
> On Fri, Feb 24, 2023 at 09:36:45AM +0100, Martin Uecker wrote:
> > Am Donnerstag, dem 23.02.2023 um 19:21 -0600 schrieb Serge E. Hallyn:
...
> >
> > Yes, but one comment about terminology:. The C standard
> > differentiates
Am Freitag, dem 24.02.2023 um 03:01 + schrieb Peter Lafreniere:
...
>
> > Maybe it could do an exception for printing, that is, reading a pointer
> > is not a problem in itself, a long as you don't compare it, but I'm not
> > such an expert about this.
>
> One last thought: with the above
Am Freitag, dem 24.02.2023 um 02:42 +0100 schrieb Alex Colomar:
> Hi Serge, Martin,
>
> On 2/24/23 02:21, Serge E. Hallyn wrote:
> > > Does all this imply that the following is well defined behavior (and shall
> > > print what one would expect)?
> > >
> > > free(p);
> > >
> > > (void)
Am Donnerstag, dem 23.02.2023 um 19:21 -0600 schrieb Serge E. Hallyn:
> On Fri, Feb 24, 2023 at 01:02:54AM +0100, Alex Colomar wrote:
> > Hi Martin,
> >
> > On 2/23/23 20:57, Martin Uecker wrote:
> > > Am Donnerstag, dem 23.02.2023 um 20:23 +0100 schrieb Alex Colomar:
> > > > Hi Martin,
> > > >
Am Donnerstag, dem 23.02.2023 um 20:23 +0100 schrieb Alex Colomar:
> Hi Martin,
>
> On 2/17/23 14:48, Martin Uecker wrote:
> > > This new wording doesn't even allow one to use memcmp(3);
> > > just reading the pointer value, however you do it, is UB.
> >
> > memcmp would not use the pointer
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
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
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:
Am Freitag, dem 17.02.2023 um 12:35 +0100 schrieb Alejandro Colomar:
> Hi Martin,
>
> On 2/17/23 09:12, Martin Uecker wrote:
> > Am Freitag, dem 17.02.2023 um 02:04 +0100 schrieb Alejandro Colomar
> >
> >
> > >
> > > [...]
> > >
> > > >
> > > > I'm not convinced that it's useful to the
Am Freitag, dem 17.02.2023 um 02:04 +0100 schrieb Alejandro Colomar
>
> [...]
>
> >
> > I'm not convinced that it's useful to the end-user to warn about
> > the
> > "use of q itself" case.
>
> I didn't quote the standard because I couldn't find it. I was
> searching in C11,
> and it seems
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
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
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/
*
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
1 - 100 of 140 matches
Mail list logo
