(I shortened the recipient list)
Am Sonntag, dem 01.10.2023 um 02:55 +0200 schrieb Alejandro Colomar:
> >
...
> I ran the tests, and get some unexpected failure. I used dg-warning,
> but maybe I used it wrong? Here's the output:
>
> ```
> output is:
> /home/alx/src/gnu/gcc/wustr/gcc/testsui
Am Donnerstag, dem 05.10.2023 um 15:35 -0700 schrieb Kees Cook:
> On Thu, Oct 05, 2023 at 04:08:52PM -0400, Siddhesh Poyarekar wrote:
> > 2. How would you handle signedness of the size field? The size gets
> > converted to sizetype everywhere it is used and overflows/underflows may
> > produce int
Am Freitag, dem 06.10.2023 um 06:50 -0400 schrieb Siddhesh Poyarekar:
> On 2023-10-06 01:11, Martin Uecker wrote:
> > Am Donnerstag, dem 05.10.2023 um 15:35 -0700 schrieb Kees Cook:
> > > On Thu, Oct 05, 2023 at 04:08:52PM -0400, Siddhesh Poyarekar wrote:
> > > > 2. H
Bootstrapped and regression tested on x86_64.
c: error for function with external and internal linkage [PR111708]
Declaring a function with both external and internal linkage
in the same TU is translation-time UB. Add an error for this
case as already done for objects.
C programmers increasingly use static to indicate that
pointer parameters are non-null. Clang can exploit this
for warnings and optimizations. GCC has some warnings
but not all warnings it has for nonnull. Below is a
patch to add a nonnull attribute automatically for such
arguments and to re
> On Thu, Jul 27, 2023 at 07:06:03PM +, Joseph Myers wrote:
> > I think there should be tests for _Atomic _BitInt types. Hopefully atomic
> > compound assignment just works via the logic for compare-and-exchange
> > loops, but does e.g. atomic_fetch_add work with _Atomic _BitInt types?
>
Am Freitag, dem 28.07.2023 um 16:03 +0200 schrieb Martin Uecker:
>
> > On Thu, Jul 27, 2023 at 07:06:03PM +, Joseph Myers wrote:
> > > I think there should be tests for _Atomic _BitInt types. Hopefully
> > > atomic
> > > compound assignment just works vi
Am Freitag, dem 28.07.2023 um 16:26 +0200 schrieb Jakub Jelinek:
> On Fri, Jul 28, 2023 at 04:03:39PM +0200, Martin Uecker wrote:
> > > On Thu, Jul 27, 2023 at 07:06:03PM +, Joseph Myers wrote:
> > > > I think there should be tests for _Atomic _BitInt types. H
Am Freitag, dem 28.07.2023 um 17:10 +0200 schrieb Jakub Jelinek:
> On Fri, Jul 28, 2023 at 04:53:30PM +0200, Martin Uecker wrote:
> > > The thing is that user doesn't have much control over those
> > > padding bits, so whether _Atomic operations on long double (when it
Am Montag, dem 31.07.2023 um 14:33 + schrieb Michael Matz:
> Hello,
>
> On Fri, 28 Jul 2023, Martin Uecker wrote:
>
> > > > Sorry, somehow I must be missing something here.
> > > >
> > > > If you add something you would create a new value and
Am Dienstag, dem 01.08.2023 um 15:54 + schrieb Michael Matz:
> Hello,
>
> On Mon, 31 Jul 2023, Martin Uecker wrote:
>
> > > Say you have a loop like so:
> > >
> > > _Atomic T obj;
> > > ...
> > > T expected1, expected2, ne
Am Mittwoch, dem 09.08.2023 um 20:10 + schrieb Qing Zhao:
>
> > On Aug 9, 2023, at 12:21 PM, Michael Matz wrote:
...
>
> By definition, the sizeof() of a struct with FAM might not be the same as the
> non-FAM one.
> i.e, for the following two structures, one with FAM, the other with fixed
Am Donnerstag, dem 10.08.2023 um 13:59 + schrieb Qing Zhao:
>
> > On Aug 10, 2023, at 2:58 AM, Martin Uecker wrote:
> >
> > Am Mittwoch, dem 09.08.2023 um 20:10 + schrieb Qing Zhao:
> > >
> > > > On Aug 9, 2023, at 12:21 PM, Michael Matz wro
Am Donnerstag, dem 10.08.2023 um 16:42 +0200 schrieb Jakub Jelinek:
> On Thu, Aug 10, 2023 at 04:38:21PM +0200, Martin Uecker wrote:
> > Am Donnerstag, dem 10.08.2023 um 13:59 + schrieb Qing Zhao:
> > >
> > > > On Aug 10, 2023, at 2:58 AM, Martin Uecker wrote
Am Donnerstag, dem 10.08.2023 um 10:58 -0400 schrieb Siddhesh Poyarekar:
> On 2023-08-10 10:47, Martin Uecker wrote:
> > Am Donnerstag, dem 10.08.2023 um 16:42 +0200 schrieb Jakub Jelinek:
> > > On Thu, Aug 10, 2023 at 04:38:21PM +0200, Martin Uecker wrote:
> > > > Am
Am Donnerstag, dem 19.10.2023 um 16:33 -0700 schrieb Kees Cook:
> On Wed, Oct 18, 2023 at 09:11:43PM +, Qing Zhao wrote:
> > As I replied to Martin in another email, I plan to do the following to
> > resolve this issue:
> >
> > 1. No specification for signed or unsigned for counted_by field.
Am Freitag, dem 20.10.2023 um 18:48 + schrieb Qing Zhao:
>
> > On Oct 20, 2023, at 2:34 PM, Kees Cook wrote:
> >
> > On Fri, Oct 20, 2023 at 11:50:11AM +0200, Martin Uecker wrote:
> > > Am Donnerstag, dem 19.10.2023 um 16:33 -0700 schrieb Kees Cook:
> &g
>
> C programmers increasingly use static to indicate that
> pointer parameters are non-null. Clang can exploit this
> for warnings and optimizations. GCC has some warnings
> but not all warnings it has for nonnull. Below is a
> patch to add a nonnull attribute automatically for such
> argumen
Am Montag, dem 23.10.2023 um 16:37 + schrieb Qing Zhao:
>
> > On Oct 23, 2023, at 11:57 AM, Richard Biener
> > wrote:
> >
> >
> >
> > > Am 23.10.2023 um 16:56 schrieb Qing Zhao :
> > >
> > >
> > >
> > > > On Oct 23, 2023, at 3:57 AM, Richard Biener
> > > > wrote:
> > > >
> > > > >
Am Montag, dem 23.10.2023 um 20:06 +0200 schrieb Martin Uecker:
> Am Montag, dem 23.10.2023 um 16:37 + schrieb Qing Zhao:
> >
> > > On Oct 23, 2023, at 11:57 AM, Richard Biener
> > > wrote:
> > >
> > >
> >
Am Montag, dem 23.10.2023 um 14:43 -0400 schrieb Siddhesh Poyarekar:
> On 2023-10-23 14:06, Martin Uecker wrote:
> > We should aim for a good integration with the BDOS pass, so
> > that it can propagate the information further, e.g. the
> > following should work:
> >
&
Am Montag, dem 23.10.2023 um 19:00 + schrieb Qing Zhao:
>
> > On Oct 23, 2023, at 2:31 PM, Martin Uecker wrote:
> >
> > Am Montag, dem 23.10.2023 um 20:06 +0200 schrieb Martin Uecker:
> > > Am Montag, dem 23.10.2023 um 16:37 + schrieb Qing Zhao:
> > &
Am Montag, dem 23.10.2023 um 12:52 -0700 schrieb Kees Cook:
> On Fri, Oct 20, 2023 at 09:54:05PM +0200, Martin Uecker wrote:
> > Am Freitag, dem 20.10.2023 um 18:48 + schrieb Qing Zhao:
> > >
> > > > On Oct 20, 2023, at 2:34 PM, Kees Cook wrote:
> > > &
Am Dienstag, dem 24.10.2023 um 20:30 + schrieb Qing Zhao:
> Hi, Sid,
>
> Really appreciate for your example and detailed explanation. Very helpful.
> I think that this example is an excellent example to show (almost) all the
> issues we need to consider.
>
> I slightly modified this example
Am Dienstag, dem 24.10.2023 um 22:51 + schrieb Qing Zhao:
>
> > On Oct 24, 2023, at 4:38 PM, Martin Uecker wrote:
> >
> > Am Dienstag, dem 24.10.2023 um 20:30 + schrieb Qing Zhao:
> > > Hi, Sid,
> > >
> > > Really appreciate for you
Am Mittwoch, dem 25.10.2023 um 08:43 +0200 schrieb Richard Biener:
>
> > Am 24.10.2023 um 22:38 schrieb Martin Uecker :
> >
> > Am Dienstag, dem 24.10.2023 um 20:30 + schrieb Qing Zhao:
> > > Hi, Sid,
> > >
> > > Really appreciate for you
Am Mittwoch, dem 25.10.2023 um 12:25 +0200 schrieb Richard Biener:
>
> > Am 25.10.2023 um 10:16 schrieb Martin Uecker :
> >
> > Am Mittwoch, dem 25.10.2023 um 08:43 +0200 schrieb Richard Biener:
> > >
> > > > > Am 24.10.2023 um 22:38 schrieb Marti
Am Mittwoch, dem 25.10.2023 um 06:25 -0400 schrieb Siddhesh Poyarekar:
> On 2023-10-25 04:16, Martin Uecker wrote:
> > Am Mittwoch, dem 25.10.2023 um 08:43 +0200 schrieb Richard Biener:
> > >
> > > > Am 24.10.2023 um 22:38 schrieb Martin Uecker :
> > > >
Am Mittwoch, dem 25.10.2023 um 13:13 +0200 schrieb Richard Biener:
>
> > Am 25.10.2023 um 12:47 schrieb Martin Uecker :
> >
> > Am Mittwoch, dem 25.10.2023 um 06:25 -0400 schrieb Siddhesh Poyarekar:
> > > > On 2023-10-25 04:16, Martin Uecker wrote:
> > &
Am Mittwoch, dem 25.10.2023 um 15:32 -0700 schrieb Kees Cook:
> On Wed, Oct 25, 2023 at 10:27:41PM +, Qing Zhao wrote:
> >
> >
> > > On Oct 25, 2023, at 6:06 PM, Kees Cook wrote:
> > >
> > > On Wed, Oct 25, 2023 at 01:27:29PM +, Qing Zhao wrote:
> > > > A. Add an additional argument, t
Hi Sid and Jakub,
here is the patch discussed in PR 109334.
Martin
tree-optimization/109334: Improve computation for access attribute
The fix for PR104970 restricted size computations to the case
where the access attribute was specified explicitly (no VLA).
It also rest
Am Donnerstag, dem 26.10.2023 um 10:45 +0200 schrieb Richard Biener:
> On Wed, Oct 25, 2023 at 8:16 PM Martin Uecker wrote:
> >
> > Am Mittwoch, dem 25.10.2023 um 13:13 +0200 schrieb Richard Biener:
> > >
> > > > Am 25.10.2023 um 12:47 schrieb Martin Uecker
Am Donnerstag, dem 26.10.2023 um 11:20 +0200 schrieb Martin Uecker:
> Am Donnerstag, dem 26.10.2023 um 10:45 +0200 schrieb Richard Biener:
> > On Wed, Oct 25, 2023 at 8:16 PM Martin Uecker wrote:
> > >
> > > Am Mittwoch, dem 25.10.2023 um 13:13 +0200 schrieb Richard Bi
Am Donnerstag, dem 26.10.2023 um 17:48 +0200 schrieb Richard Biener:
>
> > Am 26.10.2023 um 16:58 schrieb Qing Zhao :
> >
> >
> >
> > > On Oct 26, 2023, at 4:56 AM, Richard Biener
> > > wrote:
> > >
> > > > On Thu, Oct 26, 2023 at 7:22 AM Jakub Jelinek wrote:
> > > >
> > > > On Wed, Oct 2
Am Donnerstag, dem 26.10.2023 um 09:13 -0700 schrieb Kees Cook:
> On Thu, Oct 26, 2023 at 10:15:10AM +0200, Martin Uecker wrote:
> > but not this:
> >
x->count = 11;
> > char *p = &x->buf;
> > x->count = 1;
> > p[10] = 1; // !
>
> This seems f
Am Donnerstag, dem 26.10.2023 um 16:41 + schrieb Qing Zhao:
>
> > On Oct 26, 2023, at 5:20 AM, Martin Uecker wrote:
> >
> > Am Donnerstag, dem 26.10.2023 um 10:45 +0200 schrieb Richard Biener:
> > > On Wed, Oct 25, 2023 at 8:16 PM Martin Uecker wrote:
>
u derive a pointer and pass it on, it gets
difficult. But if you want safety, you just have to
to simply avoid this in code.
What we could potentially do is add restrictions so
that the access to buf always has to go via x->buf
or you get at least a warning.
Martin
>
> Qing
>
Am Freitag, dem 27.10.2023 um 14:32 + schrieb Qing Zhao:
>
> > On Oct 27, 2023, at 3:21 AM, Martin Uecker wrote:
> >
> > Am Donnerstag, dem 26.10.2023 um 19:57 + schrieb Qing Zhao:
> > > I guess that what Kees wanted, ""fill the array without kn
Thanks, Sid!
(one comment below)
Am Donnerstag, dem 26.10.2023 um 07:51 -0400 schrieb Siddhesh Poyarekar:
> On 2023-10-26 04:37, Martin Uecker wrote:
>
> > /* ... and either PARM is void * or has a type that is complete and
> > has a
>
Am Montag, dem 18.09.2023 um 23:26 +0200 schrieb Martin Uecker:
>
> 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
>
This is a revised part of previously posted patch which
I split up. C FE changes which another false positive
were already merged, but I still need approval for this
middle-end change. It would be nice to get this in,
because it fixes some rather annoying (for me atleast)
false positive warning
Here is a patch that adds the missing cases for vla size instrumentation.
This now includes all cases where a type with size < 0 is created,
which is already UB and not just cases where a VLA is allocated. But
a VLA can be allocated based on an typedef, which is also now
indirectly protected in
Am Mittwoch, dem 01.11.2023 um 14:47 + schrieb Qing Zhao:
>
> > On Oct 31, 2023, at 6:14 PM, Joseph Myers wrote:
> >
> > On Tue, 31 Oct 2023, Qing Zhao wrote:
> >
> > > 2.3 A new semantic requirement in the user documentation of "counted_by"
> > >
> > > For the following structure includin
Am Dienstag, dem 31.10.2023 um 22:19 + schrieb Joseph Myers:
> On Tue, 31 Oct 2023, Martin Uecker wrote:
>
> > > + if (TREE_CODE (arg) == INTEGER_CST
> > > + && tree_int_cst_lt (arg, TYPE_SIZE_UNIT (ttl)))
>
> What if TYPE_SIZE_UNIT (tt
Am Mittwoch, dem 01.11.2023 um 18:14 + schrieb Qing Zhao:
> Joseph and Martin,
>
> For the task to replace every reference to a FAM field with an call to
> .ACCESS_WITH_SIZE,
> Where in the C FE I should look at?
>
> Thanks a lot for the help.
>
>
build_component_ref in c_decl.cc
Martin
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, 3
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 t
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
(resending from a different account, as emails seem to do not
go out from my other account at this time)
Am Montag, den 02.08.2021, 16:05 +0200 schrieb Martin Uecker:
> > On Sun, Aug 1, 2021 at 7:37 PM Uecker, Martin
> > wrote:
> > >
> > >
> > >
Hi
Am Dienstag, den 03.08.2021, 10:10 +0200 schrieb Richard Biener:
> On Tue, Aug 3, 2021 at 7:32 AM Martin Uecker wrote:
> >
> >
> > (resending from a different account, as emails seem to do not
> > go out from my other account at this time)
> >
> >
Am Dienstag, den 03.08.2021, 11:26 +0200 schrieb Richard Biener:
> On Tue, Aug 3, 2021 at 10:28 AM Martin Uecker
> wrote:
> >
> > Hi
> > Am Dienstag, den 03.08.2021, 10:10 +0200 schrieb Richard Biener:
> > > On Tue, Aug 3, 2021 at 7
Am Dienstag, den 03.08.2021, 11:26 +0200 schrieb Richard Biener:
> On Tue, Aug 3, 2021 at 10:28 AM Martin Uecker wrote:
>
> Does the same issue arise with writing the testcases as
>
> ({ ... }) + i;
>
> ? How can we fix it then if you also need to support
>
>
Am Montag, den 09.08.2021, 15:52 +0200 schrieb Eric Botcazou:
> > I think the patch makes sense but the comment says
> >
> > Java requires that we elaborated nodes in source order. That
> > means we must gimplify the inner expression followed by each
> > of
> > the indices, in o
related
to PR29970 where statement expressions need to be evaluated so that
the size is well defined.
2021-08-12 Martin Uecker
gcc/c/
PR c/101838
PR c/29970
* c-typeck.c (c_expr_sizeof_type): Evaluate
size expressions for structs of variable size.
gcc
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.
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
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
> >
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
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
> > >
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:
>
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
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 foll
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/
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
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:
> >
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, packed
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.
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 can
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 composi
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 war
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
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!
> &
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:
* c-typeck.c
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
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: gcc.dg/gn
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 gcc.dg/g
> 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 specifi
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 continu
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 func
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 sup
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
> >
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-
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
different
> > > 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 alignmen
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
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&
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 doe
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 alth
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
> Improving the security of software has been a major trend in the recent
> years. Fortunately, GCC offers a wide variety of flags that enable extra
> hardening. These flags aren't enabled by default, though. And since
> there are a lot of hardening flags, with more to come, it's been difficult
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
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 were
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
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.
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
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 compo
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 c
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 (struc
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 (p
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): Ins
1 - 100 of 406 matches
Mail list logo
