Add warning for the case when a function call can not be instrumened.
gcc/c-family/:
* c.opt (Wvla-parameter-missing-check): Add warning.
gcc/c/:
* c-typeck.cc (process_vm_constraints): Add warning.
gcc/doc/:
* invoke.texi (Wvla-parameter-missing-check): Document warni
(corrected address)
> On Mon, 20 Nov 2023, Jakub Jelinek wrote:
>
> > On Mon, Nov 20, 2023 at 08:37:55AM +, Richard Biener wrote:
> > > > I'm not sure about that, it would be nice for them to be usable there,
> > >
> > > Btw, I think that {( .. )} should be made usable in sizeof () and
>
Thanks Joseph, I will sent an updated series tomorrow.
Richard, maybe you could look at what I wrote below
about my use of TYPE_CANONICAL ? Does this make sense?
Am Donnerstag, dem 23.11.2023 um 23:47 + schrieb Joseph Myers:
> On Thu, 16 Nov 2023, Martin Uecker wrote:
>
> &
Note that there is an additional change in parser_xref_tag
to address the issue regarding completeness in redefinition
which affects also structs / unions. The test c23-tag-6.c
was changed accordingly.
c23: tag compatibility rules for struct and unions
Implement redeclaration and compatibilit
(only tests were changed)
c23: tag compatibility rules for enums
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 p
(this patch was still not updated and needs more work, so
only included now for completeness)
c23: construct composite type for tagged types
Support for constructing composite type for structs and unions
in C23.
gcc/c:
* c-typeck.cc (composite_type_internal): Adapted from
com
(this mostly got an extended description and more
comments, also tests were reorganized)
c23: aliasing of compatible tagged types
Tell the backend which types are equivalent by setting
TYPE_CANONICAL to one struct in the set of equivalent
structs. Structs are considered equivalent by ignorin
Am Montag, dem 27.11.2023 um 08:36 -0700 schrieb Jeff Law:
>
> On 11/23/23 10:05, Hans-Peter Nilsson wrote:
> > > From: Hans-Peter Nilsson
> > > Date: Thu, 16 Nov 2023 05:24:06 +0100
> > >
> > > > From: Martin Uecker
> > > > Date: Tue,
Am Montag, dem 27.11.2023 um 16:54 +0100 schrieb Martin Uecker:
> Am Montag, dem 27.11.2023 um 08:36 -0700 schrieb Jeff Law:
> >
> > On 11/23/23 10:05, Hans-Peter Nilsson wrote:
> > > > From: Hans-Peter Nilsson
> > > > Date: Thu, 16 Nov 2023 05:24:06 +0100
Am Dienstag, dem 28.11.2023 um 01:00 + schrieb Joseph Myers:
> On Sun, 26 Nov 2023, Martin Uecker wrote:
>
> > My understand is that it is used for aliasing analysis and also
> > checking of conversions. TYPE_CANONICAL must be consistent with
> > the idea the m
Am Dienstag, dem 28.11.2023 um 10:47 + schrieb Richard Biener:
> On Tue, 28 Nov 2023, Joseph Myers wrote:
>
> > On Sun, 26 Nov 2023, Martin Uecker wrote:
> >
>
> > > > I also think more rationale is needed for ignoring sizes like this. 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
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 nonnu
This marks structures which include a byte array
as typeless storage.
Bootstrapped and regression tested on x86_64.
c: Add support for byte arrays in C2Y
To get correct aliasing behavior requires that structures and unions
that contain a byte array, i.e. an array of non-atom
This fixes an ICE when redeclaring a struct and having
an aligned attribute in one version in C23.
Bootstrapped and regression tested on x86_64.
c: Fix ICE for redeclaration of structs with different alignment [PR114727]
For redeclarations of struct in C23, if one has an alignme
This adds missing code for handling error marks.
Bootstrapped and regression tested on x86_64.
c: Fix ICE for incorrect code in comptypes_verify [PR115696]
The new verification code produces an ICE for incorrect code. Add the
same logic as already used in comptypes to to ba
Probably not entirely fool-proof when using statement
expressions in initializers, but should be good enough.
Bootstrapped and regression tested on x86_64.
c: Diagnose declarations that are used only in their own initializer
[PR115027]
Track the declaration that is currently be
Am Montag, dem 01.07.2024 um 14:29 -0300 schrieb Thiago Jung Bauermann:
> Hello Martin,
>
> Martin Uecker writes:
>
> > This should fix the test failures introduced by the fix for PR115157.
> >
> > Tested on x86_64 and also tested with -m32.
> >
> >
Am Dienstag, dem 09.07.2024 um 17:28 + schrieb Joseph Myers:
> On Sat, 29 Jun 2024, Martin Uecker wrote:
>
> > + bool typeless = flag_isoc2y
> > + && ((char_type_p (type)
> > +&a
Am Dienstag, dem 09.07.2024 um 19:11 -0300 schrieb Thiago Jung Bauermann:
> Hello Martin,
>
> Martin Uecker writes:
>
> > BTW: Did you try the other testsuite patch as well?
> >
> > [PATCH] Fix test errors after r15-1394 for sizeof(int)==sizeof(long)
> >
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
This marks structures which include a byte array
as typeless storage for all C language modes.
Bootstrapped and regression tested on x86_64.
c: Add support for byte arrays in C2Y
To get correct aliasing behavior requires that stru
This is the third revision for my patch series to check bounds
consistency at run-time when assigning VM types. Relative
to the last version, mostly the tests were simplified and some
coding style issues fixed.
It adds a new code instrumentation option that inserts
run-time checks to ensure bo
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 (struct instrument_dat
Add warning for the case when a function call can not be instrumented
and add documentation for instrumentation of function calls.
gcc/c-family/:
* c.opt (Wvla-parameter-missing-check): Add warning.
gcc/c/:
* c-typeck.cc (process_vm_constraints): Add warning.
gcc/doc/:
* invoke.texi (Wvla-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): Instrument functions
cal
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 (process_v
correct email.
Am Montag, dem 15.07.2024 um 09:19 +0200 schrieb Martin Uecker:
> This is the third revision for my patch series to check bounds
> consistency at run-time when assigning VM types. Relative
> to the last version, mostly the tests were simplified and some
> coding
Am Montag, dem 15.07.2024 um 09:45 -0700 schrieb Kees Cook:
> On Mon, Jul 15, 2024 at 09:19:49AM +0200, Martin Uecker wrote:
> > The instrumentation is guarded by a new instrumentation flag -fvla-bounds,
> > but runtime overhead should generally be very low as most checks are
>
Am Montag, dem 15.07.2024 um 13:05 -0700 schrieb Kees Cook:
> On Mon, Jul 15, 2024 at 07:20:31PM +0200, Martin Uecker wrote:
> > No, there are still two many missing pieces. The following
> > works already
> >
> > int h(int n, int buf[n])
> > {
> > retu
c-patches/2024-July/657254.html
>
> > On Jul 15, 2024, at 16:58, Martin Uecker wrote:
> >
> > Am Montag, dem 15.07.2024 um 13:05 -0700 schrieb Kees Cook:
> > > On Mon, Jul 15, 2024 at 07:20:31PM +0200, Martin Uecker wrote:
> > > > No, there are still t
d to be documented to inform user the
> current behavior,
> then the users will have an accurate expectation on what might happen with
> this
> option.
That makes sense.
>
> Later some error message might need to be issued at the same time when the
> trap happens.
>
> >
. After addressof or array-to-pointer decay we construct
new pointer types that have to be marked variably modified if the pointer
target is variably modified.
2024-05-18 Martin Uecker
PR c/114831
gcc/c/
* c-typeck.cc (array_to_pointer_conversion
in typeof and did not produce warnings when jumping over declarations
> using typeof. After addressof or array-to-pointer decay we construct
> new pointer types that have to be marked variably modified if the pointer
> target is variably modified.
>
> 2024-0
and add -Woverflow warning.
2024-05-18 Martin Uecker
PR c/115109
gcc/c/
* c-decl.cc (build_enumerator): When redeclaring an
enumerator convert value to previous type.
gcc/testsuite/
* gcc.dg/pr115109.c: New test
previous declaration. Convert initializers with different type accordingly
and add -Woverflow warning.
2024-05-18 Martin Uecker
PR c/115109
gcc/c/
* c-decl.cc (build_enumerator): When redeclaring an
enumerator convert value to previous
Am Montag, dem 20.05.2024 um 21:30 + schrieb Joseph Myers:
> On Sun, 19 May 2024, Martin Uecker wrote:
>
> > c23 specifies that the type of a redeclared enumerator is the one of the
> > previous declaration. Convert initializers with different type
> > acc
For enum and integer we allow aliasing by specifically returning
via a langhook the aliasing set of the underlying type.
But this is not sufficient for derived types, i.e. pointers to
enums and pointers to compatible integers also need to have the
same aliasing set.
We also allow forward declara
Am Donnerstag, dem 23.05.2024 um 14:30 -0700 schrieb Ian Lance Taylor:
> On Thu, May 23, 2024 at 2:00 PM Joseph Myers wrote:
> >
> > On Tue, 21 May 2024, Martin Uecker wrote:
> > >
> > > C: allow aliasing of compatible types derived fro
This is another version of this patch with two changes:
- I added a fix (with test) for PR 115177 which is just the same
issue for hardbools which are internally implemented as enums.
- I fixed the golang issue. Since the addition of the main variant
to the seen decls is unconditional I removed
This is the patch I sent previously, but I tried to improve the
description and added a long comment. This patch is needed so
that we do not have to update TYPE_CANONICAL of structures / unions
when a tagged type is completed that is (recursively) pointed to
by a member of the structure / union
This is similar to the enum issue, where setting the alias set to zero
is insufficient because also derived types need to be able to alias.
After this change, it is also possible to add checking assertions that
verify TYPE_CANONICAL for all tagged types at end of each call to the
comptypes famil
Freitag, dem 24.05.2024 um 17:39 +0200 schrieb Martin Uecker:
> This is another version of this patch with two changes:
>
> - I added a fix (with test) for PR 115177 which is just the same
> issue for hardbools which are internally implemented as enums.
>
> - I fixed the golang is
of a redeclared enumerator is the one of the
previous declaration. Convert initializers with different type accordingly
and emit an error when the value does not fit.
2024-06-01 Martin Uecker
PR c/115109
gcc/c/
* c-decl.cc (build_enumerator): When
Am Donnerstag, dem 08.08.2024 um 00:09 +0200 schrieb Alejandro Colomar:
> Hi Martin,
> >
...
> > >
> > > I would personally prefer supporting [0], and consider that not
> > > supporting [*] is a bug in the implementation of [*] (and thus not my
> > > problem).
> > >
> > > However, since GCC doe
> > your test with a reference to the bug for now and I will try fix this ASAP.
>
> I'll send v6 in a moment; feel free to insist in this if you disagree
> after seeing it, but I think it works well without the line.
>
> >
> > Martin
>
> Cheers,
> Alex
>
--
Univ.-Prof. Dr. rer. nat. Martin Uecker
Graz University of Technology
Institute of Biomedical Imaging
Am Donnerstag, dem 08.08.2024 um 16:56 +0200 schrieb Jens Gustedt:
> Am 8. August 2024 13:28:57 MESZ schrieb Joseph Myers :
> > On Thu, 8 Aug 2024, Alejandro Colomar wrote:
> >
> > > Hi Jens,
> > >
> > > On Thu, Aug 08, 2024 at 11:13:02AM GMT, Jens Gustedt wrote:
> > > > > but to maintain expecta
Am Donnerstag, dem 08.08.2024 um 18:23 +0200 schrieb Jens Gustedt:
> As said, even if we don't consider this problematic because we are used to
> the mildly complex case distinction that you just exposed over several
> paragraphs, it doesn't mean that we should
> do it, nor does it mean that it w
Am Donnerstag, dem 08.08.2024 um 20:04 +0200 schrieb Alejandro Colomar:
>
...
> >
> > *If* the feature were adopted into C++26, we could then consider if
> > existing macros should be renamed to look more like the future language
> > feature.
> >
> > Target code is at least always compiled wi
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 should be good enough.
>
>
> Bootstrapped and regression tested on x86_64.
>
>
>
> c: Diagnose decl
would all work out.
Martin
>
> ~Aaron
>
> -Original Message-
> From: Jens Gustedt
> Sent: Wednesday, August 14, 2024 8:18 AM
> To: Ballman, Aaron ; Alejandro Colomar
> ; Xavier Del Campo Romero
>
> Cc: Gcc Patches ; Daniel Plakosh
> ; Martin Ueck
Am Mittwoch, dem 14.08.2024 um 16:12 +0200 schrieb Alejandro Colomar:
> Hi Martin,
>
> On Wed, Aug 14, 2024 at 03:50:00PM GMT, Martin Uecker wrote:
> > An operator that returns an array with all dimensions of a multi-dimensional
> > array would make a a lot of sense to me.
Am Mittwoch, dem 14.08.2024 um 14:52 + schrieb Ballman, Aaron:
> > I would love to see a proposal for adding this GNU extension to ISO C.
> > Did nobody do it yet? I could try to, if I find some time. (But I'll take
> > a longish time for that; if anyone else
> > does it, it would be
> great
> > > > + int b;
> > > > > + float f;
> > > > > +};
> > > > > +int n;
> > > > > + };
> > > > > + char c[] __attribute__ ((counted_by (b)));
> > > > > +} *array_nested_annotated;
> > > > > +
> > > > > +struct nested_flex {
> > > > > + struct {
> > > > > +union {
> > > > > + unsigned int b;
> > > > > + float f;
> > > > > +};
> > > > > +int n;
> > > > > + };
> > > > > + char c[];
> > > > > +} *array_nested_flex;
> > > > > +
> > > > > +#define MY_ALLOC(P, FAM, COUNT) ({ \
> > > > > + typeof(P) __p; \
> > > > > + size_t __size = sizeof(*P) + sizeof(*P->FAM) * COUNT; \
> > > > > + __p = (typeof(P)) __builtin_malloc(__size); \
> > > > > + __builtin_memset(__p, 0, __size); \
> > > > > + if (__builtin_get_counted_by (__p->FAM)) \
> > > > > + *(__builtin_get_counted_by(__p->FAM)) = COUNT; \
> > > > > + P = __p; \
> > > > > +})
> > > > > +
> > > > > +int count;
> > > > > +
> > > > > +int main(int argc, char *argv[])
> > > > > +{
> > > > > + MY_ALLOC(array_annotated, c, 10);
> > > > > + if (array_annotated->b != 10)
> > > > > +__builtin_abort ();
> > > > > +
> > > > > + MY_ALLOC(array_flex, c, 20);
> > > > > + if (array_flex->b == 20)
> > > > > +__builtin_abort ();
> > > > > +
> > > > > + MY_ALLOC(array_nested_annotated, c, 30);
> > > > > + if (array_nested_annotated->b != 30)
> > > > > +__builtin_abort ();
> > > > > +
> > > > > + MY_ALLOC(array_nested_flex, c, 40);
> > > > > + if (array_nested_flex->b == 40)
> > > > > +__builtin_abort ();
> > > > > +
> > > > > + count = array_annotated->b * 2 + array_nested_annotated->b * 3;
> > > > > + struct annotated * annotated_p;
> > > > > + struct flex * flex_p;
> > > > > + struct nested_annotated * nested_annotated_p;
> > > > > + struct nested_flex * nested_flex_p;
> > > > > +
> > > > > + MY_ALLOC(annotated_p, c, count);
> > > > > + if (annotated_p->b != count)
> > > > > +__builtin_abort ();
> > > > > +
> > > > > + MY_ALLOC(flex_p, c, count * 2);
> > > > > + if (flex_p->b == count * 2)
> > > > > +__builtin_abort ();
> > > > > +
> > > > > + MY_ALLOC(nested_annotated_p, c, count * 3);
> > > > > + if (nested_annotated_p->b != count * 3)
> > > > > +__builtin_abort ();
> > > > > +
> > > > > + MY_ALLOC(nested_flex_p, c, count * 4);
> > > > > + if (nested_flex_p->b == count * 4)
> > > > > +__builtin_abort ();
> > > > > +
> > > > > + return 0;
> > > > > +}
> > > > > diff --git a/gcc/testsuite/gcc.dg/builtin-get-counted-by.c
> > > > > b/gcc/testsuite/gcc.dg/builtin-get-counted-by.c
> > > > > new file mode 100644
> > > > > index 000..5eca12bc992
> > > > > --- /dev/null
> > > > > +++ b/gcc/testsuite/gcc.dg/builtin-get-counted-by.c
> > > > > @@ -0,0 +1,54 @@
> > > > > +/* Testing the correct usage of the new __builtin_get_counted_by. */
> > > > > +/* { dg-do compile } */
> > > > > +/* { dg-options "-O" } */
> > > > > +
> > > > > +#include
> > > > > +
> > > > > +struct annotated {
> > > > > + size_t b;
> > > > > + int other;
> > > > > + int c[] __attribute ((counted_by (b)));
> > > > > +} *array_annotated;
> > > > > +
> > > > > +struct flex {
> > > > > + size_t b;
> > > > > + int other;
> > > > > + int c[];
> > > > > +} *array_flex;
> > > > > +
> > > > > +#define MY_ALLOC(P, FAM, COUNT) ({ \
> > > > > + typeof(P) __p; \
> > > > > + size_t __size = sizeof(*P) + sizeof(*P->FAM) * COUNT; \
> > > > > + __p = (typeof(P)) __builtin_malloc(__size); \
> > > > > + if (__builtin_get_counted_by (__p->FAM)) \
> > > > > +*(__builtin_get_counted_by(__p->FAM)) = COUNT; \
> > > > > + __p; \
> > > > > +})
> > > > > +
> > > > > +extern char c_count;
> > > > > +extern short s_count;
> > > > > +extern int i_count;
> > > > > +extern long l_count;
> > > > > +extern float f_count;
> > > > > +
> > > > > +extern int * foo ();
> > > > > +
> > > > > +int main(int argc, char *argv[])
> > > > > +{
> > > > > + /* The good usages. */
> > > > > + MY_ALLOC(array_annotated, c, 10);
> > > > > + MY_ALLOC(array_flex, c, 20);
> > > > > + MY_ALLOC(array_annotated, c, c_count);
> > > > > + MY_ALLOC(array_flex, c, i_count);
> > > > > + MY_ALLOC(array_annotated, c, l_count);
> > > > > + MY_ALLOC(array_flex, c, c_count * 3);
> > > > > + MY_ALLOC(array_annotated, c, l_count * i_count);
> > > > > +
> > > > > + /* The bad usages, issue errors. */
> > > > > + __builtin_get_counted_by (); /* { dg-error "wrong number of
> > > > > arguments to" } */
> > > > > + __builtin_get_counted_by (array_annotated->c, 10); /* { dg-error
> > > > > "wrong number of arguments to" } */
> > > > > + __builtin_get_counted_by (array_annotated->other); /* { dg-error
> > > > > "the argument must be an array" } */
> > > > > + __builtin_get_counted_by (foo()); /* { dg-error "the argument
> > > > > must be an array" } */
> > > > > +
> > > > > + return 0;
> > > > > +}
> > > > > --
> > > > > 2.31.1
>
>
--
Univ.-Prof. Dr. rer. nat. Martin Uecker
Graz University of Technology
Institute of Biomedical Imaging
Am Mittwoch, dem 21.08.2024 um 16:34 +0200 schrieb Martin Uecker:
> Am Mittwoch, dem 21.08.2024 um 14:12 + schrieb Qing Zhao:
>
> >
> > Yes, I do feel that the approach __builtin_get_counted_by is not very good.
> > Maybe it’s better to provide
> > A. __builti
gt; > pointed by
> > > > > > > diff --git a/gcc/testsuite/gcc.dg/builtin-get-counted-by-1.c
> > > > > > > b/gcc/testsuite/gcc.dg/builtin-get-counted-by-1.c
> > > > > > > new file mode 100644
> > > > > > > index 0
;
or, if one expects only specific types:
__auto_type ret = counted_by_ref (array_annotated->c);
_Generic (ret, void*: 0, int*: *(int*)ret = 10,
size_t*: *(size_t*)ret = 10);
But yes, a bit less elegant.
Martin
> Thanks a lot for your help.
>
> Qing
>
>
> > On
Am Montag, dem 26.08.2024 um 13:30 -0700 schrieb Kees Cook:
> On Mon, Aug 26, 2024 at 07:30:15PM +, Qing Zhao wrote:
> > Hi, Martin,
> >
> > Looks like that there is some issue when I tried to use the _Generic for
> > the testing cases, and then I narrowed down to a
> > small testing case tha
Am Montag, dem 26.08.2024 um 17:21 -0700 schrieb Kees Cook:
> On Mon, Aug 26, 2024 at 11:01:08PM +0200, Martin Uecker wrote:
> > Am Montag, dem 26.08.2024 um 13:30 -0700 schrieb Kees Cook:
> > > On Mon, Aug 26, 2024 at 07:30:15PM +, Qing Zhao wrote:
> > > > Hi,
Am Dienstag, dem 04.06.2024 um 08:33 +0200 schrieb Jakub Jelinek:
> Hi!
>
> The following testcase ICEs in ipa-free-lang, because the
> fld_incomplete_type_of
> gcc_assert (TYPE_CANONICAL (t2) != t2
> && TYPE_CANONICAL (t2) == TYPE_CANONICAL (TREE_TYPE
> (t)));
> a
The patch fails on arm because the tests make assumptions
about enums that are not true everywhere. Should we just
limit the tests to x86?
Martin
Am Montag, dem 03.06.2024 um 17:37 + schrieb Joseph Myers:
> On Sat, 1 Jun 2024, Martin Uecker wrote:
>
> > This is a new version
specifies that the type of a redeclared enumerator is the one of the
previous declaration. Convert initializers with different type accordingly
and emit an error when the value does not fit.
2024-06-01 Martin Uecker
PR c/115109
gcc/c/
* c-decl.cc
As discussed this replaces the use of check_qualified_type with
a simple check for qualifiers as suggested by Jakub in
c_update_type_canonical.
Martin
Bootstrapped and regression tested on x86_64.
C23: Fix ICE related to incomplete structures [PR114930,PR115502].
The fix for PR1
Am Dienstag, dem 18.06.2024 um 17:27 +0200 schrieb Richard Biener:
>
> > Am 18.06.2024 um 17:20 schrieb Martin Uecker :
> >
> >
> > As discussed this replaces the use of check_qualified_type with
> > a simple check for qualifiers as suggested by Jakub in
>
Hi all,
I am working paper for the following syntax extension
int a[10];
int (*a)[*] = &a;
This would not be a wide pointer, it will just initialize
the size of the type from the initializer. This would
also work for VM type. So the result is a conventional
pointer to an arrays and either a
Am Mittwoch, dem 19.06.2024 um 08:04 +0200 schrieb Richard Biener:
>
> > Am 18.06.2024 um 20:18 schrieb Martin Uecker :
> >
> > Am Dienstag, dem 18.06.2024 um 17:27 +0200 schrieb Richard Biener:
> > >
> > > > > Am 18.06.2024 um 17:20 schrieb
Am Mittwoch, dem 19.06.2024 um 08:29 +0200 schrieb Jakub Jelinek:
> On Wed, Jun 19, 2024 at 08:04:55AM +0200, Richard Biener wrote:
> > > > Note a canonical type should always be unqualified (for
> > > > classical qualifiers, not address space or atomic qualification)
> > >
> > > The logic in buil
Am Mittwoch, dem 19.06.2024 um 08:57 +0200 schrieb Richard Biener:
> On Wed, 19 Jun 2024, Martin Uecker wrote:
>
> > Am Mittwoch, dem 19.06.2024 um 08:04 +0200 schrieb Richard Biener:
> > >
> > > > Am 18.06.2024 um 20:18 schrieb Martin Uecker :
> > > >
This fixes the test failures introduced by the fix for PR115109.
Tested on x86_64 and also tested with -m32.
Fix test errors after r15-1394 for sizeof(int)==sizeof(long) [PR115545]
Some tests added to test the type of redeclarations of enumerators
in r15-1394 fail on architec
This should fix the test failures introduced by the fix for PR115157.
Tested on x86_64 and also tested with -m32.
Fix test errors introduced with fix for PR115157.
Fix tests introduced when fixing PR115157 that assume
sizeof(enum)==sizeof(int)
by adding the flag -fno-short-en
ction prototype scope" is then suppressed.
Bootstrapped and regression tested on x86_64.
commit 1157d04764eeeb51fa1098727813dbc092e11dd2
Author: Martin Uecker
Date: Sat Nov 4 14:39:19 2023 +0100
C: Error message for incorrect use of static in array declarations.
Add an expl
Thanks Marek, here is the second version which should
implement all your suggestions.
(BTW: Without the newline of the end, the test case has
undefined behavior..., not that we need to care.)
Bootstrapped and regression tested on x86_64.
[PATCH] c: Error message for incorrect use of st
Am Sonntag, dem 28.07.2024 um 16:15 +0200 schrieb Alejandro Colomar:
...
>
> Does anyone know if we have the information available for getting that
> value from the 'tree' object? Or do we need some refactor first in
> order to keep that information?
What I wanted to try is to not immediately a
Am Sonntag, dem 04.08.2024 um 01:17 +0200 schrieb Alejandro Colomar:
>
> FUTURE DIRECTIONS:
>
> We could make it work with array parameters to functions, and
> somehow magically return the length designator of the array,
> regardless of it being really a pointer.
And maybe fl
Am Sonntag, dem 04.08.2024 um 10:25 +0200 schrieb Alejandro Colomar:
> Hi Martin,
>
> On Sun, Aug 04, 2024 at 07:38:49AM GMT, Martin Uecker wrote:
> > Am Sonntag, dem 04.08.2024 um 01:17 +0200 schrieb Alejandro Colomar:
> > >
> > > FUTURE DIRECTIONS:
> >
Hi Alex,
Am Sonntag, dem 04.08.2024 um 18:40 +0200 schrieb Alejandro Colomar:
> Hi Martin,
>
> On Sun, Aug 04, 2024 at 11:39:26AM GMT, Martin Uecker wrote:
> > Am Sonntag, dem 04.08.2024 um 10:25 +0200 schrieb Alejandro Colomar:
> > > Hi Martin,
> > >
> &g
Hi Alex,
Am Sonntag, dem 04.08.2024 um 19:49 +0200 schrieb Alejandro Colomar:
> Hi Martin,
>
> On Sun, Aug 04, 2024 at 06:43:46PM GMT, Alejandro Colomar wrote:
> > On Sun, Aug 04, 2024 at 06:40:14PM GMT, Alejandro Colomar wrote:
> > > > The last
> > > > case should return a non-constant.
> > >
Am Sonntag, dem 04.08.2024 um 20:34 +0200 schrieb Alejandro Colomar:
> On Sun, Aug 04, 2024 at 08:02:25PM GMT, Martin Uecker wrote:
> > Hi Alex,
>
> Hi Martin,
>
> > > Is this missing diagnostics?
> > >
> > > $ cat star.c
> > >
gt; On Sun, Aug 04, 2024 at 08:02:25PM GMT, Martin Uecker wrote:
> > > D'oh! I screwed it. I wanted to have written this:
> > >
> > > $ cat star.c
> > > void foo(char (*a)[3][*], int (*x)[__lengthof__(*a)]);
> >
> > I think this answers you
> > > > Hi Martin,
> > > >
> > > > On Sun, Aug 04, 2024 at 11:39:26AM GMT, Martin Uecker wrote:
> > > > > > BTW, I still don't understand what `if (! TYPE_DOMAIN (type))`
> > > > > > means,
> > > > > > wit
Am Montag, dem 05.08.2024 um 17:27 +0200 schrieb Alejandro Colomar:
> Hi Martin,
>
...
> > But I think you might make it unnecessarily complicated. It
> > should be sufficient to look at the outermost size. You
> > can completely ignore thatever happens There
> > should be three cases if I am n
Am Montag, dem 05.08.2024 um 20:10 + schrieb Qing Zhao:
> On Aug 5, 2024, at 06:33, Martin Uecker wrote:
> >
> > Am Montag, dem 05.08.2024 um 11:50 +0200 schrieb Jakub Jelinek:
> > > On Mon, Aug 05, 2024 at 11:45:56AM +0200, Alejandro Colomar wrote:
&
Am Dienstag, dem 06.08.2024 um 14:22 +0200 schrieb Alejandro Colomar:
> Hi!
>
> - The tests seem to work as expected if I compile them manually, and
>run (the one that should be run) as a normal program. The one that
>should not be run also gives the expected diagnostics.
>Can anyone
Am Dienstag, dem 06.08.2024 um 16:12 +0200 schrieb Alejandro Colomar:
> Hi Martin,
>
> On Tue, Aug 06, 2024 at 03:37:13PM GMT, Martin Uecker wrote:
> > Am Dienstag, dem 06.08.2024 um 14:22 +0200 schrieb Alejandro Colomar:
> > > Hi!
> > >
> > > - The t
Am Mittwoch, dem 07.08.2024 um 01:12 +0200 schrieb Alejandro Colomar:
Hi Alex,
a coupled of comments below.
> --- a/gcc/c/c-parser.cc
> +++ b/gcc/c/c-parser.cc
> @@ -74,7 +74,17 @@ along with GCC; see the file COPYING3. If not see
> #include "bitmap.h"
> #include "analyzer/analyzer-language.
would be correct.
>
> What do you think?
I think the logic in your patch is OK as is. It does not exactly
what you want, as it now treats some [0] as [*] but I would not
make the logic more complex here when we will fix it properly
anyway.
>
> Does anyone oppose treating [0]
for discussion.
2024-04-12 Martin Uecker
Jakub Jelinek
PR lto/114574
PR c/114361
gcc/
* ipa-free-lang-data.cc (fld_incomplete_type_of): Allow
either of the types in the assert to have TYPE_STRUCTURAL_EQUALITY_P.
gcc/c/
* c-decl.cc
(new email for Joseph)
Am Sonntag, dem 14.04.2024 um 14:30 +0200 schrieb Martin Uecker:
> I had to revert the old patch because it broke LTO which lead
> to PR114574. We now set TYPE_STRUCTURAL_EQUALITY and properly
> update TYPE_CANONICAL for such types and also for pointers
> t
Am Freitag, dem 03.05.2024 um 14:13 +0200 schrieb Richard Biener:
> TYPE_STRUCTURAL_EQUALITY_P is part of our type system so we have
> to make sure to include that into the type unification done via
> type_hash_canon. This requires the flag to be set before querying
> the hash which is the biggest
Am Freitag, dem 03.05.2024 um 18:23 +0200 schrieb Richard Biener:
>
> > Am 03.05.2024 um 17:33 schrieb Martin Uecker :
> >
> > Am Freitag, dem 03.05.2024 um 14:13 +0200 schrieb Richard Biener:
> > > TYPE_STRUCTURAL_EQUALITY_P is part of our type system so we have
Am Freitag, dem 03.05.2024 um 19:30 +0200 schrieb Jakub Jelinek:
> On Fri, May 03, 2024 at 05:32:12PM +0200, Martin Uecker wrote:
> > Am Freitag, dem 03.05.2024 um 14:13 +0200 schrieb Richard Biener:
> > > TYPE_STRUCTURAL_EQUALITY_P is part of our type system so we have
>
Am Freitag, dem 03.05.2024 um 20:18 +0200 schrieb Jakub Jelinek:
> On Fri, May 03, 2024 at 08:04:18PM +0200, Martin Uecker wrote:
> > A change that is not optimal but would avoid a lot of trouble is to
> > only use the tag of the struct for computing a TYPE_CANONICAL, which
> &
Am Freitag, dem 03.05.2024 um 20:48 +0200 schrieb Richard Biener:
>
> > Am 03.05.2024 um 20:37 schrieb Martin Uecker :
> >
> > Am Freitag, dem 03.05.2024 um 20:18 +0200 schrieb Jakub Jelinek:
> > > > On Fri, May 03, 2024 at 08:04:18PM +0200, Martin Uecker wr
Am Freitag, dem 03.05.2024 um 21:16 +0200 schrieb Jakub Jelinek:
> > On Fri, May 03, 2024 at 09:11:20PM +0200, Martin Uecker wrote:
> > > > > > TYPE_CANONICAL as used by the middle-end cannot express this but
> > > >
> > > > Hm. so how does it work
Am Montag, dem 06.05.2024 um 09:00 +0200 schrieb Richard Biener:
> On Sat, 4 May 2024, Martin Uecker wrote:
>
> > Am Freitag, dem 03.05.2024 um 21:16 +0200 schrieb Jakub Jelinek:
> > > > On Fri, May 03, 2024 at 09:11:20PM +0200, Martin Uecker wrote:
> > > > &
Am Montag, dem 06.05.2024 um 11:07 +0200 schrieb Richard Biener:
> On Mon, 6 May 2024, Martin Uecker wrote:
>
> > Am Montag, dem 06.05.2024 um 09:00 +0200 schrieb Richard Biener:
> > > On Sat, 4 May 2024, Martin Uecker wrote:
> > >
> > > > Am Freitag, d
Alex,
I am all for making things more consistent, but there is also a cost
to changing stuff too much. length is the established
term in most programming languages and I would recommend to stick
to it.
Note that it is not true that the standard consistently refers to
char a[3][n]
as a VLA
Am Freitag, dem 06.09.2024 um 13:59 + schrieb Qing Zhao:
>
> > On Sep 5, 2024, at 18:22, Bill Wendling wrote:
> >
> > Hi Qing,
> >
> > Sorry for my late reply.
> >
> > On Thu, Aug 29, 2024 at 7:22 AM Qing Zhao wrote:
> > >
> > > Hi,
> > >
> > > Thanks for the information.
> > >
> > > Y
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 Freitag, dem 06.09.2024 um 13:59 + schrieb Qing Zhao:
> > >
> > > > On Sep 5, 2024, at 18:22, Bill Wendl
_counted_by(&x)) = 10;
https://godbolt.org/z/41E3oj84o
So why not do this then?
Martin
>
> Is this acceptable?
>
> thanks.
>
> Qing
> > On Sep 6, 2024, at 16:59, Bill Wendling wrote:
> >
> > On Fri, Sep 6, 2024 at 12:32 PM Martin Uecker wrote:
> &
Am Samstag, dem 07.09.2024 um 08:16 +0200 schrieb Martin Uecker:
> Am Samstag, dem 07.09.2024 um 00:12 + schrieb Qing Zhao:
> > Now, if
> >
> > 1. __builtin_get_counted_by should return a LVALUE instead of a pointer
> > (required by CLANG’s design)
> > And
101 - 200 of 406 matches
Mail list logo
