Am Sonntag, dem 08.09.2024 um 02:26 -0700 schrieb Bill Wendling:
> On Sat, Sep 7, 2024 at 12:21 AM Jakub Jelinek wrote:
> > On Sat, Sep 07, 2024 at 07:50:29AM +0200, Martin Uecker wrote:
> > > > 2. Apple's implementation supports expressions in the '__counted_
Am Sonntag, dem 08.09.2024 um 02:09 -0700 schrieb Bill Wendling:
> On Fri, Sep 6, 2024 at 10:50 PM Martin Uecker wrote:
> >
> > Am Freitag, dem 06.09.2024 um 13:59 -0700 schrieb Bill Wendling:
> > > On Fri, Sep 6, 2024 at 12:32 PM Martin Uecker wrote:
> > >
Am Dienstag, dem 10.09.2024 um 13:51 + schrieb Qing Zhao:
> #define alloc(P, FAM, COUNT) ({ \
> typeof(P) __p; \
> size_t __size = sizeof(*P) + sizeof(*P->FAM) * COUNT; \
> __p = kmalloc(__size, GFP); \
> typeof(_Generic(__builtin_counted_by_ref(__p->FAM), \
>
Am Dienstag, dem 10.09.2024 um 20:36 +0200 schrieb Jakub Jelinek:
> On Tue, Sep 10, 2024 at 06:31:23PM +, Qing Zhao wrote:
> >
> >
> > > On Sep 10, 2024, at 14:09, Jakub Jelinek wrote:
> > >
> > > On Tue, Sep 10, 2024 at 06:02:45PM +, Qing Zhao wrote:
> > > > > #define alloc(P, FAM, COU
Hi Marek,
sorry for taking so long to respond.
Fri, 15 May 2015 15:38:43 +0200
Marek Polacek :
> On Sat, May 09, 2015 at 09:42:23AM -0700, Martin Uecker wrote:
> > here is a tentative patch to implement a new attribute nonzero,
> > which is similar to nonnull, but is not a fun
Hello Joseph and all,
here is a preliminary patch the implements the proposed
tag compatibility rules for C23 in GCC (N2863). It works
by tweaking the diagnostics in the FE and by recording
structs/union types to be able to set TYPE_CANONICAL to
a canonical definition (as per previous discussio
Am Dienstag, den 07.06.2022, 14:22 + schrieb Joseph Myers:
> On Tue, 7 Jun 2022, Martin Uecker wrote:
>
> > here is a preliminary patch the implements the proposed
> > tag compatibility rules for C23 in GCC (N2863). It works
>
> I don't see any response on th
(tested on x86_64-unknown-linux-gnu)
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 77d9352..2f79344 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+2015-05-09 Martin Uecker
+
+ * gcc/gimple.c (infer_nonnull_range): Process nonzero attribute.
+ * doc/invoki.texi
+
2015-05
of
TYPE_MAX_VALUE (domain) == NULL_TREE.
Regression tested.
2015-02-25 Martin Uecker
gcc/
* c-family/c-ubsan.c (ubsan_instrument_bounds): Remove
bogus check for flexible array members.
gcc/testsuite/
* gcc.dg/ubsan/bounds-2.c: New
* c-c
Thu, 26 Feb 2015 07:36:54 +0100
Jakub Jelinek :
> On Wed, Feb 25, 2015 at 10:01:07PM -0800, Martin Uecker wrote:
> > this patch removes a bogus check for flexible array members
> > which prevents array references to be instrumented in some
> > interesting cases. Arrays acce
Marek Polacek :
(Hi Marek and Jakub, I really appreciate your work on GCC and
ubsan. I just want to add the minor enhancements necessary
to make it really useful for me).
> > And this is broken code. I would argue that a user who uses the
> > ubsan *expects* this to be diagnosed. Atleast I was
Am Thu, 26 Feb 2015 10:05:14 +0100
Jakub Jelinek :
> On Thu, Feb 26, 2015 at 12:59:08AM -0800, Martin Uecker wrote:
> > > No, it is not bogus nor unnecessary.
> > > This isn't about just real flexible arrays, but similar constructs,
> > > C++ doesn't
to do instrumentation similar to clang
with -fsanitize=bounds.
Comments?
(regression testing in progress, but ubsan-related
tests all pass)
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index ec2cb69..cb6df20 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,11 @@
+2015-02-27 Martin U
TX)->u.fld, GET_RTX_LENGTH( ... ))[N])
and have ubsan auto-generate the bound checking which
are now often manually added.
Martin
Martin Uecker :
>
> I tested Marek's proposed change and it works correctly,
> i.e. arrays which are not part of a struct are now
> instrumented w
Marek Polacek :
> On Fri, Feb 27, 2015 at 11:53:14AM -0800, Martin Uecker wrote:
> >
> > I tested Marek's proposed change and it works correctly,
> > i.e. arrays which are not part of a struct are now
> > instrumented when accessed through a pointer. This also
&
2015-01-15 Martin Uecker
* MAINTAINERS: (Write After Approval): Add myself.
Index: MAINTAINERS
===
--- MAINTAINERS (Revision 219713)
+++ MAINTAINERS (Revision 219714)
@@ -576,6 +576,7 @@
Philipp Tomsich
Richard Biener wrote:
> On Mon, 26 Jan 2015, Jakub Jelinek wrote:
> > Then it probably should be ok. I'm really afraid of emitting more warnings
> > with such high false positive rate now.
>
> As the patch also mitigates some of the code bloat we get with
> the complete peeling (regression aga
/warning_at
previous versions (see v1 for a description of the main idea):
v2: https://gcc.gnu.org/ml/gcc/2014-10/msg00243.html
v1: https://gcc.gnu.org/ml/gcc/2014-10/msg00224.html
On Wed, 29 Oct 2014 16:43:16 +
"Joseph S. Myers" :
> On Tue, 28 Oct 2014, Martin Uecker wrote:
n
-Wdiscarded-array-qualifiers.
Joseph Myers :
> On Thu, 6 Nov 2014, Martin Uecker wrote:
> > This patch implements a new proposed behaviour for
> > pointers to arrays with qualifiers in C.
> >
> > I found some time to work on this again, so here is another
> >
Hi,
this proposed patch adds an option "-Warray-bounds=" in addition to
"-Warray-bound". "-Warray-bounds=1" corresponds to "-Warray-bound".
For higher warning levels more warnings about optional accesses
outside of arrays are emitted. For example, warnings for
arrays accessed through pointers are
e new ones. For some reason, the changes to this
file were missing in my previous versions. (scroll down to the
end for this file)
Thank you,
Martin
2014-12-08 Martin Uecker
* doc/invoke.texi: Document -Wdiscarded-array-qualifiers
* doc/extend.texi: Document new behavior for poi
Please consider this patch. The additional warnings would be useful
IMHO, are also emitted by clang, and the change seems trivial.
Previous discussion about potential false positives:
https://gcc.gnu.org/ml/gcc/2014-11/msg00114.html
Tue, 11 Nov 2014 22:13:20 -0800
Martin Uecker :
>
&
Mon, 12 Jan 2015 11:00:44 -0700
Jeff Law :
> On 11/11/14 23:13, Martin Uecker wrote:
...
> >
> >
> > * gcc/tree-vrp.c (check_array_ref): Emit more warnings
> > for warn_array_bounds >= 2.
> > * gcc/testsuite/gcc.dg/Warray-bounds-11.c: New test-case.
Jeff Law :
> On 01/13/15 10:34, Martin Uecker wrote:
> > Mon, 12 Jan 2015 11:00:44 -0700
> > Jeff Law :
> >> On 11/11/14 23:13, Martin Uecker wrote:
...
> >> Has this patch been bootstrapped and regression tested, if so on what
> >> platform.
> >
Jeff Law :
> On 01/13/15 17:40, Martin Uecker wrote:
> > Jeff Law :
> >> On 01/13/15 10:34, Martin Uecker wrote:
> >>> Mon, 12 Jan 2015 11:00:44 -0700
> >>> Jeff Law :
> >>>> On 11/11/14 23:13, Martin Uecker wrote:
> >
> > ...
Am Sonntag, dem 13.10.2024 um 10:56 +0200 schrieb Richard Biener:
> On Sat, 12 Oct 2024, Martin Uecker wrote:
>
> > Am Samstag, dem 12.10.2024 um 18:44 +0200 schrieb Richard Biener:
> > >
> > > > Am 12.10.2024 um 16:43 schrieb Martin Uecker :
> > > >
There is code which should not fail at run-time. For this,
it is helpful to get a warning when a compiler inserts traps
(e.g. sanitizers, hardbools, __builtin_trap(), etc.).
Having a warning for this also has many other use cases, e.g.
one can use it with some sanitizer to rule out that some
pi
Am Dienstag, dem 15.10.2024 um 12:15 +0200 schrieb Jakub Jelinek:
> On Tue, Oct 15, 2024 at 11:50:21AM +0200, Richard Biener wrote:
> > > Would it be reasonable to approve this patch now and I try
> > > to improve this later?
> >
> > On the patch itself:
> >
> > void
> > expand_builtin_trap (vo
Am Samstag, dem 12.10.2024 um 18:44 +0200 schrieb Richard Biener:
>
> > Am 12.10.2024 um 16:43 schrieb Martin Uecker :
> >
> >
> > There is code which should not fail at run-time. For this,
> > it is helpful to get a warning when a compiler inserts trap
I like to ping this patch.
Am Freitag, dem 09.08.2024 um 10:20 +0200 schrieb Martin Uecker:
> ok?
>
> Am Samstag, dem 29.06.2024 um 20:30 +0200 schrieb Martin Uecker:
> > Probably not entirely fool-proof when using statement
> > expressions in initializers, but
Hi Quin and Joseph,
I saw that there is now new code in tu_tagged_types_compatible
which makes structure type incompatible depending on whether
there is ac counted_by attribute. Is this what we want? I think a
warning might make more sense as this types are fundamentally
still compatible.
I a
Am Montag, dem 21.10.2024 um 21:09 + schrieb Joseph Myers:
> On Sat, 19 Oct 2024, Martin Uecker wrote:
>
> > Hi Quin and Joseph,
> >
> > I saw that there is now new code in tu_tagged_types_compatible
> > which makes structure type incompatible depending on whet
Am Dienstag, dem 22.10.2024 um 16:15 + schrieb Qing Zhao:
>
> > On Oct 21, 2024, at 17:29, Martin Uecker wrote:
> >
> > Am Montag, dem 21.10.2024 um 21:09 + schrieb Joseph Myers:
> > > On Sat, 19 Oct 2024, Martin Uecker wrote:
> > >
> > >
The recent patch to improve detection of variably modified types
also fixed some issues related to unspecified sizes.
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=9eae9268e41463927c9383004e58708048ec379f
There are some loose ends / possible cleanups which I missed and
which are addressed by
> >
> > Please reconsider? Why to we need to match LLVM here?<
>
> Matching llvm is not really the goal. I implemented it since it is
> useful optimization for code that builds small objects on heap and
> compiler can optimize away their use. This is relatively common for
> code with higer abstra
Am Freitag, dem 25.10.2024 um 14:03 + schrieb Qing Zhao:
>
> > On Oct 25, 2024, at 08:13, Martin Uecker wrote:
> >
> > > > I agree, and error makes sense. What worries me a little bit
> > > > is tying this to a semantic change in type compatibili
This version of the already approved patch only adds the missing
word "size" to the commit message and a missing "-std=gnu23" to
the first test. If there are no new comments, I will commit this
once the pre-commit CI tests are complete.
Bootstrapped and regression tested on x86_64.
Martin
).
Bootstrapped and regression tested on x86_64.
commit 599fa1480156391ad9e12e4c2bda23dee85bd11a
Author: Martin Uecker
Date: Sat Nov 9 10:48:52 2024 +0100
c: add Wzero-as-null-pointer-constant [PR117059]
Add warnings for the use of zero as a null pointer constant to the C FE
This patch enables the Wzero-as-null-pointer-constant for C.
The third version adds more tests.
Bootstrapped and regression tested on x86_64.
commit 3afa3065be59374389daebfb32490fb93ad63d88
Author: Martin Uecker
Date: Sat Nov 9 10:48:52 2024 +0100
c: add Wzero-as-null-pointer
Added tests with some non-NPC pointers converted to bool.
(BTW: For some reason we allowed 0 == nullptr but not
x ? 0 : nullptr in ISO C.)
Bootstrapped and regression tested on x86_64.
commit 5a29c43cca6fa5f50ad8266c5969a9420ef2488e
Author: Martin Uecker
Date: Sat Nov 9 10:48:52 2024
Here is a patch that hopefully fixes the last cases where we do not
tag variably-modified types correctly. It is probably best to look
at the c-typeck.cc changes first.
Martin
c: detect variably-modified types [PR117145,PR117245,PR100420]
This fixes two cases where variably-modif
I added a max element as suggested by Richard to force
the type to an int.
Regression tested on x86_64 but needs testing on arm-eabi.
Thiago, could you test this?
https://linaro.atlassian.net/browse/GNU-1224
Fix test failures for enum-alias-{1,2,3} on arm-eabi [PR117419]
The tes
Am Sonntag, dem 10.11.2024 um 11:32 +0100 schrieb Alejandro Colomar:
> Hi!
>
> Your favourite operator with the most controversial name comes back with
> support for [0], thanks to Martin Uecker. In movie theaters, and
> probably in GCC 16.
>
> For those who fight in a
Here is a fix for a mistake I made when recursively checking for
type compatibility.
Bootstrapped and regression tested on x86-64.
c: fix crash when checking for compatibility of structures [PR116726]
When checking for compatibility of structure or union types in
tagged_types
Am Mittwoch, dem 23.10.2024 um 14:32 + schrieb Qing Zhao:
>
> > On Oct 22, 2024, at 15:16, Martin Uecker wrote:
> >
> > > > >
> > > >
> > > > I doesn't really make sense when they are inconsistent.
> > > > Still, we
Hi Richard,
here is another version. This now just ignores the size for all trailing
arrays which I think is the right thing to do. It also modifies the lto
hashing which also seems to work (but needs more testing and I haven't
added tests to the patch yet).
I also added back the missing comp
e patch this should not matter anymore.
Martin
>
> thanks.
>
> Qing
> > On Nov 23, 2024, at 14:45, Martin Uecker wrote:
> >
> >
> > This patch tries fixes the errors we have because of
> > flexible array members. I am bit unsure about the exception
It seems we also miss a decl_attributes call for the fields
when building the composite type.
Bootstrapped and regression tested on x86_64.
c: Set attributes for fields when forming a composite type [PR117806]
We need to call decl_attributes when creating the fields for a composi
Bit-fields need additional checks for type compatiblity.
Bootstrapped and regression tested on x86_64.
c: correct type compatibility for bit-fields [PR117828]
Add missing test for consistency of bit-fields when comparing tagged
types for compatibility.
PR c/
Am Montag, dem 18.11.2024 um 17:55 + schrieb Qing Zhao:
> Hi,
>
> I am working on extending “counted_by” attribute to pointers inside a
> structure per our previous discussion.
>
> I need advice on the following question:
>
> Should -fsantize=bounds support array reference that was referen
Am Dienstag, dem 19.11.2024 um 09:18 -0800 schrieb Kees Cook:
> On Tue, Nov 19, 2024 at 05:41:13PM +0100, Martin Uecker wrote:
> > Am Dienstag, dem 19.11.2024 um 10:47 -0500 schrieb Marek Polacek:
> > > On Mon, Nov 18, 2024 at 07:10:35PM +0100, Martin Uecker wrote:
>
Am Montag, dem 18.11.2024 um 21:31 + schrieb Qing Zhao:
>
> > On Nov 18, 2024, at 13:10, Martin Uecker wrote:
>
...
> So, I guess that the more accurate question is, for the following:
>
> struct annotated {
> int b;
> int *c __attribute__ ((counted_by (b
re setting the buffer (or
at the same time). This could be ensured by making the
member 'n' const, so that it can only be changed by
overwriting the whole struct. But I am still thinking
about this.
In any case, I think for "counted_by" this is not an option
because it would b
Am Dienstag, dem 19.11.2024 um 10:47 -0500 schrieb Marek Polacek:
> On Mon, Nov 18, 2024 at 07:10:35PM +0100, Martin Uecker wrote:
> > Am Montag, dem 18.11.2024 um 17:55 + schrieb Qing Zhao:
> > > Hi,
> > >
> > > I am working on extending “counte
Am Mittwoch, dem 20.11.2024 um 15:27 + schrieb Qing Zhao:
>
> > On Nov 19, 2024, at 10:47, Marek Polacek wrote:
> >
> > On Mon, Nov 18, 2024 at 07:10:35PM +0100, Martin Uecker wrote:
> > > Am Montag, dem 18.11.2024 um 17:55 + schrieb Qing Zhao:
> >
This patch enables the Wzero-as-null-pointer-constant for C.
Bootstrapped and regression tested on x86_64.
c: add Wzero-as-null-pointer-constant [PR117059]
Add warnings for the use of zero as a null pointer constant to the C FE.
PR c/117059
gcc/c-family/
This patch enables the Wzero-as-null-pointer-constant for C.
The second version added more tests and fixes one condition
to not incorrectly warn for nullptr.
Bootstrapped and regression tested on x86_64.
c: add Wzero-as-null-pointer-constant [PR117059]
Add warnings for the use o
This patch tries fixes the errors we have because of
flexible array members. I am bit unsure about the exception
for the mode.
Bootstrapped and regression tested on x86_64.
Fix type compatibility for types with flexible array member
[PR113688,PR114014,PR117724]
verify_type che
Am Dienstag, dem 26.11.2024 um 15:15 + schrieb Qing Zhao:
>
> > On Nov 25, 2024, at 16:46, Martin Uecker wrote:
> >
> >
> > Hi Qing,
> >
> > Am Montag, dem 25.11.2024 um 17:40 + schrieb Qing Zhao:
> > > Hi, Martin,
> > >
gt; in the above, 'ref1' uses 'val1' as the number of the elements in
> 'p->array', and 'ref2' uses 'val2' as the number of elements in
> 'p->array’.
> "
> Has this feature been used by Linux kernel alread
Am Montag, dem 02.12.2024 um 20:15 + schrieb Qing Zhao:
>
> > On Nov 30, 2024, at 07:22, Martin Uecker wrote:
> >
> > Am Dienstag, dem 26.11.2024 um 20:59 + schrieb Qing Zhao:
> > > Think this over these days, I have another thought that need some
> >
Am Montag, dem 02.12.2024 um 16:31 + schrieb Qing Zhao:
>
> > On Nov 30, 2024, at 07:10, Martin Uecker wrote:
> >
> > Am Dienstag, dem 26.11.2024 um 15:15 + schrieb Qing Zhao:
> > >
> > > > On Nov 25, 2024, at 16:46, Martin Uecker
Bootstrapped and regression tested on x86_64.
c: Fix ICE when forming composite type for two structures / unions
[PR117548]
When forming the composite type from two tagged type, we need to find the
original type for a typedecl to get the correct tag.
PR c/117
Richard, ok for trunk then?
Am Freitag, dem 15.11.2024 um 02:11 -0300 schrieb Thiago Jung Bauermann:
> Hello,
>
> Martin Uecker writes:
>
> > I added a max element as suggested by Richard to force
> > the type to an int.
> >
> > Regression tested on
Here is a patch to fix a TBAA issue for tagged types. In principle,
this affects earlier language modes too, but I limited the change to
C23 for now because it was always wrong but is less of an issue before
C23. If there is no fallout, I would propose to later fix this also
for earlier version
Am Montag, dem 25.11.2024 um 10:35 +0100 schrieb Richard Biener:
> On Mon, 25 Nov 2024, Richard Biener wrote:
>
> > On Sat, 23 Nov 2024, Martin Uecker wrote:
> >
> > >
> > > This patch tries fixes the errors we have because of
> > > flexible array
Am Montag, dem 02.12.2024 um 22:58 + schrieb Qing Zhao:
>
> > On Dec 2, 2024, at 16:13, Martin Uecker wrote:
> >
> > Am Montag, dem 02.12.2024 um 20:15 + schrieb Qing Zhao:
> > >
> > > > On Nov 30, 2024, at 07:22, Martin Uecker wrote:
> >
ere declared with char b[1].
Martin
>
> Qing
> > I would make it
> > compatible but not allow redefinition as the types are different.
>
>
> >
> >
> > Martin
> >
> >
> > >
> > > thanks.
> > >
> >
Am Dienstag, dem 03.12.2024 um 14:31 + schrieb Qing Zhao:
>
> > On Dec 3, 2024, at 01:33, Martin Uecker wrote:
> >
> > Am Montag, dem 02.12.2024 um 22:58 + schrieb Qing Zhao:
> > >
> > > > On Dec 2, 2024, at 16:13, Martin Uecker wrote:
> &
Hi Richard,
this is another version. It now adds an "ignore_size" flag
to gimple_canonical_types_compatible_p and uses this instead
of having the complicated special case for arrays at the
end. Also zero-sized members are now ignored again, except
if they are arrays at the end where then only
Happy new year! Please consider the following patch.
Bootstrapped and regression tested on x86_64.
c: Restore warning for incomplete structures declared in parameter list
[PR117866]
In C23 mode the warning about declaring structures and union in
parameter lists was removed, b
As requested, I split up into one part for the TYPE_MODE and
another one for the array size to help with git bisecting. This
is the first part.
Bootstrapped and regression tested on x86_64.
Allow the TYPE_MODE of a type with an array as last member to differ from
another compatible type.
The second part now only contains the changes for array size.
I added back a special case for this instead of having the
'ignore_size' flag (which I would nevertheless assume might be
needed in the future when matching pointer types).
In this version, I added an exception to the special case t
Am Montag, dem 09.12.2024 um 16:20 + schrieb Qing Zhao:
>
> > On Dec 7, 2024, at 03:57, Martin Uecker wrote:
> >
> > Am Freitag, dem 06.12.2024 um 16:13 + schrieb Qing Zhao:
> > >
> > > > On Dec 6, 2024, at 10:56, Martin Uecker wrote:
> &g
Am Donnerstag, dem 12.12.2024 um 13:59 -0800 schrieb Bill Wendling:
> On Thu, Dec 12, 2024 at 1:28 PM Martin Uecker wrote:
> >
> > Am Montag, dem 09.12.2024 um 16:20 + schrieb Qing Zhao:
> > >
> > > > On Dec 7, 2024, at 03:57, Martin Uecker wro
Am Donnerstag, dem 05.12.2024 um 21:09 + schrieb Qing Zhao:
>
> > On Dec 3, 2024, at 10:29, Qing Zhao wrote:
> > >
> > > > >
> > > > > > >
> > > > > > > It would be clearer if you the syntax ".n" which resembles
> > > > > > > the syntax for designated initializers that is already us
Am Donnerstag, dem 05.12.2024 um 14:28 -0800 schrieb Bill Wendling:
> On Thu, Dec 5, 2024 at 1:09 PM Qing Zhao wrote:
> > > On Dec 3, 2024, at 10:29, Qing Zhao wrote:
> > > > On Dec 3, 2024, at 10:07, Martin Uecker wrote:
> > > > The language extension does n
Am Freitag, dem 06.12.2024 um 14:16 + schrieb Qing Zhao:
>
> > On Dec 5, 2024, at 17:31, Martin Uecker wrote:
> >
> > Am Donnerstag, dem 05.12.2024 um 21:09 + schrieb Qing Zhao:
> > >
> > > >
Am Freitag, dem 06.12.2024 um 16:13 + schrieb Qing Zhao:
>
> > On Dec 6, 2024, at 10:56, Martin Uecker wrote:
> >
> > Am Freitag, dem 06.12.2024 um 14:16 + schrieb Qing Zhao:
> > >
...
> > > >
> > > > I think the relevant sce
Hello Michael,
Am Mittwoch, dem 22.01.2025 um 16:54 +0100 schrieb Michael Matz:
> On Wed, 22 Jan 2025, Martin Uecker wrote:
>
> > > > So you do not need to look further. But maybe I am missing something
> > > > else.
> > >
> > > Like ...
>
Am Mittwoch, dem 22.01.2025 um 16:25 +0100 schrieb Michael Matz:
> Hello,
>
> On Wed, 22 Jan 2025, Martin Uecker wrote:
>
> > > You need to decide which is which after seeing the ".". I'm guessing
> > > what
> > > you mean is
Am Mittwoch, dem 22.01.2025 um 15:53 +0100 schrieb Michael Matz:
> Hello,
>
> On Tue, 21 Jan 2025, Martin Uecker wrote:
>
> > > > Coudn't you use the rule that .len refers to the closest enclosing
> > > > structure
> > > > even without
Hi Quin,
sorry, another idea I noted down some time ago which I would like
to mention.
> >
> > - use it only in limited contexts where you do not need to know
> > the type (e.g. this works for goto labels) or for a basic
> > counted_by attribute that only takes an identifier as we have i
Am Mittwoch, dem 22.01.2025 um 16:37 + schrieb Qing Zhao:
>
> > On Jan 22, 2025, at 11:22, Martin Uecker wrote:
> >
> >
> > Hello Michael,
> >
> > Am Mittwoch, dem 22.01.2025 um 16:54 +0100 schrieb Michael Matz:
> > > On Wed, 22 Jan 2025, M
Am Dienstag, dem 21.01.2025 um 21:15 +0100 schrieb Martin Uecker:
> Am Dienstag, dem 21.01.2025 um 19:45 + schrieb Joseph Myers:
> > On Tue, 21 Jan 2025, Martin Uecker wrote:
> >
> > > Coudn't you use the rule that .len refers to the closest enclosing
>
Am Dienstag, dem 21.01.2025 um 19:45 + schrieb Joseph Myers:
> On Tue, 21 Jan 2025, Martin Uecker wrote:
>
> > Coudn't you use the rule that .len refers to the closest enclosing structure
> > even without __self__ ? This would then also disambiguate between
> &
Am Mittwoch, dem 22.01.2025 um 17:30 +0100 schrieb Michael Matz:
> Hello,
>
> On Wed, 22 Jan 2025, Martin Uecker wrote:
>
> > > > In .y[1][3].z after .y you can decide whether y is a member of the
> > > > struct being initialized. If it is, it is a designa
Am Mittwoch, dem 22.01.2025 um 18:11 +0100 schrieb Martin Uecker:
> Am Mittwoch, dem 22.01.2025 um 16:37 + schrieb Qing Zhao:
> >
> > > On Jan 22, 2025, at 11:22, Martin Uecker wrote:
> > >
> > >
> > > Hello Michael,
> > >
> >
Am Donnerstag, dem 23.01.2025 um 17:39 + schrieb Qing Zhao:
>
> > On Jan 22, 2025, at 12:20, Martin Uecker wrote:
> >
> > Am Mittwoch, dem 22.01.2025 um 18:11 +0100 schrieb Martin Uecker:
> > > Am Mittwoch, dem 22.01.2025 um 16:37 + schrieb Qing Zhao:
>
Am Freitag, dem 24.01.2025 um 14:23 + schrieb Joseph Myers:
> On Thu, 23 Jan 2025, Martin Uecker wrote:
>
> > I can see why it could be seen in this way. But the designator
> > syntax could also be seen (more or less) as a tiny subset of
> > the expression syntax allow
Am Donnerstag, dem 23.01.2025 um 20:24 + schrieb Qing Zhao:
>
> > On Jan 23, 2025, at 13:27, Martin Uecker wrote:
> >
> > Am Donnerstag, dem 23.01.2025 um 17:39 + schrieb Qing Zhao:
> > >
> > > > On Jan 22, 2025, at 12:20, Martin Uecker
.
Am Donnerstag, dem 23.01.2025 um 15:27 +0100 schrieb Michael Matz:
> > Hello,
> >
> > On Wed, 22 Jan 2025, Martin Uecker wrote:
> >
> > > > > > > > > > If y is not a member it must be an expression, true. But
> > > > > > &
Am Freitag, dem 17.01.2025 um 15:34 -0800 schrieb Bill Wendling:
> On Fri, Jan 17, 2025 at 3:14 PM Joseph Myers wrote:
> >
> > On Fri, 17 Jan 2025, Qing Zhao wrote:
> >
> > > struct fc_bulk {
> > > ...
> > > struct fs_bulk fs_bulk;
> > > struct fc fcs[] __counted_by(fs_bulk.len);
> > > };
Am Dienstag, dem 21.01.2025 um 18:40 + schrieb Joseph Myers:
> On Tue, 21 Jan 2025, Qing Zhao wrote:
>
> > So, even after we introduce the designator syntax for counted_by attribute,
> > arbitrary expressions as:
> >
> > counted_by (.len1 + const)
> > counted_by (.len1 + .len2)
> >
> > St
Am Dienstag, dem 21.01.2025 um 21:13 + schrieb Joseph Myers:
> On Tue, 21 Jan 2025, Martin Uecker wrote:
>
> > The bigger issue seems that if you forward reference a member, you
> > do not yet know its type. So whatever syntax we pick, general expressions
> >
Am Donnerstag, dem 16.01.2025 um 21:18 + schrieb Qing Zhao:
>
..
>
> Although in the previous discussion, I agreed with Martin that we should use
> the
> designator syntax (i.e, counted_by (.n) instead of counted_by (n)) for the
> counted_by attribute for pointer fields, after more considera
this specific case as a workaround
and add a "sorry" for the alignment case (or should this
simply become an error?).
Bootstrapped and regression tested on x86_64.
commit 56c2c96ef4ebd24290fbf8f66b277d420a68b032
Author: Martin Uecker
Date: Sun Mar 16 10:54:17 2025 +0100
c: F
This is a partial fix for PR118765.
Bootstrapped and regression tested on x86_64.
commit 84ba284a14bb5249d923affbf3f0f95a993c3a29
Author: Martin Uecker
Date: Sat Mar 1 21:32:21 2025 +0100
c: Fix bug in typedef redefinitions of tagged types [PR118765]
When we redefine a
Here is a small patch fixing an error recovery issue.
Bootstrapped and regression tested on x86_64.
commit 465773af2bdd552184b935e5dc6b3db9e0e4e327
Author: Martin Uecker
Date: Sat Mar 1 17:21:25 2025 +0100
c: Fix ICE in error recovery when checking struct compatibility [PR118061
Hi David,
Am Donnerstag, dem 13.03.2025 um 19:23 -0700 schrieb David Tarditi:
>
> I skip your initiial part. I think this was all discussed before
(also in WG14) and I still come to different conclusions. Just
two comments:
...
>
> The VLA semantics are also problematic. User can side-effe
201 - 300 of 415 matches
Mail list logo
