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
you 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
>
>
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:
>
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 = >buf;
> > x->count = 1;
> > p[10] = 1; // !
>
> This seems f
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
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 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
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
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,
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 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 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 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 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 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 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 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 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 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 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:
> > > >
> > > > >
>
> 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
>
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
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.
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.
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
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
(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:
>
Am Mittwoch, dem 26.07.2023 um 18:06 +0200 schrieb Martin Uecker:
>
> 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
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 Freitag, dem 15.09.2023 um 11:11 -0400 schrieb Marek Polacek:
> On Wed, Aug 30, 2023 at 10:46:14AM +0200, Martin Uecker wrote:
> > > Improving the security of software has been a major trend in the recent
> > > years. Fortunately, GCC offers a wide variety of fl
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
> 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
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
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 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 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
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
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
arch64 and X86, no issue.
>
> I've updated the Linux kernel's macros for the name change and done
> build tests with my first pass at "easy" cases for adding counted_by:
> https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/commit/?h=devel/counted_by=adc5b3cb48a049563dc673f348eab7b6beba8a9b
>
> Everything is working as expected. :)
>
> -Kees
>
--
Univ.-Prof. Dr. rer. nat. Martin Uecker
Graz University of Technology
Institute of Biomedical Imaging
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 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 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
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
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 relative
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 is 80
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 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
> 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?
>
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
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
>
> > 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:
> > >
> > >
> > >
e two is used”?
> >
> > I was just restating the above: if size information is available
> > via
> > both __alloc_size and __counted_by, the smaller of the two should
> > be
> > used.
>
> If we are consistent with LLVM’s RFC, __alloc_size >= __counted_by
> all the time.
> Then we can always use the counted_by info for the array size.
> >
> > >
> > > > This may be
> > > > desirable in a few situations. One example would be a large
> > > > allocation
> > > > that is slowly filled up by the program.
> > >
> > > So, for such situation, whenever the allocation is filled up, the
> > > field that hold the “counted_by” attribute should be increased at
> > > the same time,
> > > Then, the “counted_by” value always sync with the real
> > > allocation.
> > > > I.e. the counted_by member is
> > > > slowly increased during runtime (but not beyond the true
> > > > allocation size).
> > >
> > > Then there should be source code to increase the “counted_by”
> > > field whenever the allocated space increased too.
> > > >
> > > > Of course allocation size is only available in limited
> > > > situations, so
> > > > the loss of that info is fine: we have counted_by for
> > > > everything else.
> > >
> > > The point is: allocation size should synced with the value of
> > > “counted_by”. LLVM’s RFC also have the similar requirement:
> > > https://discourse.llvm.org/t/rfc-enforcing-bounds-safety-in-c-fbounds-safety/70854#maintaining-correctness-of-bounds-annotations-18
> >
> > Right, I'm saying it would be nice if __alloc_size was checked as
> > well,
> > in the sense that if it is available, it knows without question
> > what the
> > size of the allocation is. If __alloc_size and __counted_by
> > conflict,
> > the smaller of the two should be the truth.
>
> >
> > But, as I said, if there is some need to explicitly ignore
> > __alloc_size
> > when __counted_by is present, I can live with it; we just need to
> > document it.
> >
> > If the RFC and you agree that the __counted_by variable can only
> > ever be
> > (re)assigned after the flex array has been (re)allocated, then I
> > guess
> > we'll see how it goes. :) I think most places in the kernel using
> > __counted_by will be fine, but I suspect we may have cases where we
> > need
> > to update it like in the loop I described above. If that's true, we
> > can
> > revisit the requirement then. :)
>
> I guess if we can always keep the relationship: __alloc_size >=
> __counted_by all the time. Should be fine.
>
> Please check whether this is enough for kernel, I will check whether
> this is doable For GCC.
>
> thanks.
>
>
> Qing
> >
> > -Kees
> >
> > --
> > Kees Cook
>
--
Univ.-Prof. Dr. rer. nat. Martin Uecker
Graz University of Technology
Institute of Biomedical Imaging
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
> Committed as obvious.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.dg/nested-vla-1.c: Require effective target trampolines.
> * gcc.dg/nested-vla-2.c: Ditto.
> * gcc.dg/nested-vla-3.c: Ditto.
>
> CC: Martin Uecker
> Signed-off-by: Dimitar Dimitrov
> -
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
:
> 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. 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 wai
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-6
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.
101 - 200 of 242 matches
Mail list logo
