Am Dienstag, dem 21.02.2023 um 14:21 + schrieb Richard Biener:
> On Tue, 21 Feb 2023, Martin Uecker wrote:
>
> >
> >
> > Hi Richard,
> >
> > can you look at this middle-end patch? It fixes two regressions.
>
> But gimplify_type_sizes recurses its
Hi Richard,
can you look at this middle-end patch? It fixes two regressions.
Martin
PS: I happy to do something about at variably_modified_type_p
in the middle-end, if you have a recommendation.
Am Mittwoch, dem 08.02.2023 um 13:02 +0100 schrieb Martin Uecker:
>
> Here is
Here is a patch for PR108375.
Bootstrapped and regession tested on x86_64-linux-gnu
Also there is a middle-end patch for PR107557 and PR108423:
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611562.html
and another C FE patch for PR105660:
Here is a fix for PR105660.
Bootstrapped and regression tested on x86-64.
Fix ICE related to implicit access attributes for VLA arguments [PR105660]
When constructing the specifier string when merging an access attribute
that encodes information about VLA arguments, the
Here is a fix for PR107557 and PR108423.
Bootstrapped and regression tested on x86-64.
Gimplify more size expression in parameters [PR107557] and [PR108234]
gimplify_parm_type only recursives into pointer type and
size expressions in other types (e.g. function types) were
This adds regression tests for an ICE on valid code that
seems gone on trunk, but the cause is still unclear.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103770
regressions tests for PR103770
This adds tests from bugzilla for PR103770 and duplicates.
testsuite/gcc.dg/
*
Here is a first patch to add UBSan instrumentation to
assignment, return, initialization of pointers
to variably modified types. This is based on the
other patch I just sent. Separating these should make
reviewing easier.
Here, I did not add tests for function arguments as
this is more
Because I want to add another argument to comptypes
and co. for UBSan instrumentation and this then
starts to become a bit unwiedly, here is a patch to
reorganize and simplify this a bit. This can wait
until stage 1. (The cache can be simplified further
by allocating it on the stack, but this
Am Dienstag, dem 20.12.2022 um 20:04 + schrieb Joseph Myers:
> On Tue, 20 Dec 2022, Martin Uecker via Gcc-patches wrote:
>
> > Here is a patch to remove the unused function
> > same_translation_unit_p and related code. The
> > code to check for structural equivalency
Here is a patch to remove the unused function
same_translation_unit_p and related code. The
code to check for structural equivalency of
structs / unions is kept (with some fixes)
because it will be needed for C2X.
c: Remove dead code related to type compatibility across TUs.
Code to
Am Samstag, den 15.10.2022, 10:53 +0200 schrieb Jakub Jelinek:
> On Sat, Oct 15, 2022 at 10:07:46AM +0200, Martin Uecker wrote:
> > But why? Do we really want to encourage people to
> > write such code?
>
> Of course these ++ cases inside of expressions are just obfusca
Am Freitag, den 14.10.2022, 23:20 +0200 schrieb Jakub Jelinek:
> On Fri, Oct 14, 2022 at 10:43:16PM +0200, Martin Uecker wrote:
> > Am Montag, den 10.10.2022, 10:54 +0200 schrieb Jakub Jelinek:
> > > Hi!
> > >
> > > My earlier patches gimplify the s
Am Montag, den 10.10.2022, 10:54 +0200 schrieb Jakub Jelinek:
> Hi!
>
> My earlier patches gimplify the simplest non-side-effects assumptions
> into if (cond) ; else __builtin_unreachable (); and throw the rest
> on the floor.
> The following patch attempts to do something with the rest too.
My
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 the
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
>
> On 2/22/2022 10:57 AM, Jakub Jelinek via Gcc-patches wrote:
> > On Tue, Feb 22, 2022 at 12:39:28PM -0500, Andrew MacLeod wrote:
> >>> That is EH, then there are calls that might not return because they leave
> >>> in some other way (e.g. longjmp), or might loop forever, might exit, might
>
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
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
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 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
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)
> >
> >
(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:
> > >
> > >
> >
>> is allocated via malloc. I was wrong, as this won't work on common
> >> platforms like x86-64 where malloc yields non-executable storage.
> >>
> >> gcc/
> >> * doc/invoke.texi (Code Gen Options):
> >> * doc/tm.texi.in (Trampolines):
> >> Docum
Hi Marek,
sorry for taking so long to respond.
Fri, 15 May 2015 15:38:43 +0200
Marek Polacek pola...@redhat.com:
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
(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 uec...@eecs.berkeley.edu
+
+ * gcc/gimple.c (infer_nonnull_range): Process nonzero attribute
Marek Polacek pola...@redhat.com:
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
means that the following
, GET_RTX_LENGTH( ... ))[N])
and have ubsan auto-generate the bound checking which
are now often manually added.
Martin
Martin Uecker uec...@eecs.berkeley.edu:
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
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 Uecker uec
Am Thu, 26 Feb 2015 10:05:14 +0100
Jakub Jelinek ja...@redhat.com:
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 have flexible array members, nor C89, so
Marek Polacek pola...@redhat.com:
(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.
Thu, 26 Feb 2015 07:36:54 +0100
Jakub Jelinek ja...@redhat.com:
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 accessed through
of
TYPE_MAX_VALUE (domain) == NULL_TREE.
Regression tested.
2015-02-25 Martin Uecker uec...@eecs.berkeley.edu
gcc/
* c-family/c-ubsan.c (ubsan_instrument_bounds): Remove
bogus check for flexible array members.
gcc/testsuite/
* gcc.dg/ubsan/bounds
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 against
2015-01-15 Martin Uecker uec...@eecs.berkeley.edu
* MAINTAINERS: (Write After Approval): Add myself.
Index: MAINTAINERS
===
--- MAINTAINERS (Revision 219713)
+++ MAINTAINERS (Revision 219714)
@@ -576,6 +576,7 @@
Philipp
Mon, 12 Jan 2015 11:00:44 -0700
Jeff Law l...@redhat.com:
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.
* gcc/c-family/c.opt: New option
Jeff Law l...@redhat.com:
On 01/13/15 17:40, Martin Uecker wrote:
Jeff Law l...@redhat.com:
On 01/13/15 10:34, Martin Uecker wrote:
Mon, 12 Jan 2015 11:00:44 -0700
Jeff Law l...@redhat.com:
On 11/11/14 23:13, Martin Uecker wrote:
...
Has this patch been bootstrapped
Jeff Law l...@redhat.com:
On 01/13/15 10:34, Martin Uecker wrote:
Mon, 12 Jan 2015 11:00:44 -0700
Jeff Law l...@redhat.com:
On 11/11/14 23:13, Martin Uecker wrote:
...
Has this patch been bootstrapped and regression tested, if so on what
platform.
x86_64-unknown-linux-gnu
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 uec
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 uec...@eecs.berkeley.edu
* doc/invoke.texi: Document -Wdiscarded-array-qualifiers
* doc/extend.texi: Document new behavior
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 now
-qualifiers.
Joseph Myers jos...@codesourcery.com:
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
revision. Main changes to the previous
/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 jos...@codesourcery.com:
On Tue, 28 Oct 2014, Martin Uecker
201 - 242 of 242 matches
Mail list logo
