Hi,
I want to add run-time support for checking for equality of
the size expressions where pointers to variable-length arrays
are required to be compatible.
I wonder if you could give some advise on how to approach
this. One general question is where this should be added.
For example, I think
Am Donnerstag, den 18.04.2019, 11:56 +0200 schrieb Richard Biener:
> On Thu, Apr 18, 2019 at 11:31 AM Richard Biener
> wrote:
> >
> > On Wed, Apr 17, 2019 at 4:12 PM Uecker, Martin
> > wrote:
> > >
> > > Am Mittwoch, den 17.04.2019, 15:34 +0200 schr
Am Donnerstag, den 18.04.2019, 11:45 +0100 schrieb Peter Sewell:
> On Thu, 18 Apr 2019 at 10:32, Richard Biener
> wrote:
> An equality test of two pointers, on the other hand, doesn't necessarily
> mean that they are interchangeable. I don't see any good way to
> avoid that in a provenance
Am Donnerstag, den 18.04.2019, 14:30 +0200 schrieb Richard Biener:
> On Thu, Apr 18, 2019 at 1:57 PM Uecker, Martin
> wrote:
> >
> > Am Donnerstag, den 18.04.2019, 11:56 +0200 schrieb Richard Biener:
> > > On Thu, Apr 18, 2019 at 11:31 AM
Am Donnerstag, den 18.04.2019, 07:42 -0600 schrieb Jeff Law:
> On 4/18/19 6:20 AM, Uecker, Martin wrote:
> > Am Donnerstag, den 18.04.2019, 11:45 +0100 schrieb Peter Sewell:
> > > On Thu, 18 Apr 2019 at 10:32, Richard Biener
> > > wrote:
...
> > 4.) Compile
Am Donnerstag, den 18.04.2019, 14:42 +0200 schrieb Richard Biener:
> On Thu, Apr 18, 2019 at 2:20 PM Uecker, Martin
> wrote:
> >
> > Am Donnerstag, den 18.04.2019, 11:45 +0100 schrieb Peter Sewell:
> > > On Thu, 18 Apr 2019 at 10:32, Richard Biener
> > > wro
Am Freitag, den 19.04.2019, 10:19 +0200 schrieb Jens Gustedt:
> Hello,
>
> On Thu, 18 Apr 2019 14:42:22 +0200 Richard Biener
> wrote:
>
> > On Thu, Apr 18, 2019 at 2:20 PM Uecker, Martin
> > wrote:
> > > 1.) Compilers do not use conditional equivalences
Am Freitag, den 19.04.2019, 10:35 +0100 schrieb Peter Sewell:
> On 19/04/2019, Jens Gustedt wrote:
> > Hello Peter,
> >
> > On Fri, 19 Apr 2019 10:11:43 +0100 Peter Sewell
> > wrote:
> >
> > > On 19/04/2019, Jakub Jelinek wrote:
> > > > On Fri, Apr 19, 2019 at 10:19:28AM +0200, Jens Gustedt
Am Donnerstag, den 18.04.2019, 15:49 +0100 schrieb Peter Sewell:
> On Thu, 18 Apr 2019 at 14:54, Uecker, Martin
> wrote:
> >
> > Am Donnerstag, den 18.04.2019, 07:42 -0600 schrieb Jeff Law:
> > > On 4/18/19 6:20 AM, Uecker, Martin wrote:
> > > > Am Donnerst
Am Mittwoch, den 24.04.2019, 21:30 +0200 schrieb Philipp Klaus Krause:
> Am 24.04.19 um 20:41 schrieb Jeff Law:
> > > > > 4.) Compilers make sure that exposed objects never
> > > > > are allocated next to each other (as Jens proposed).
> > > >
> > > > Ugh. Not sure how you enforce that.
Hi Richard,
Am Mittwoch, den 17.04.2019, 11:41 +0200 schrieb Richard Biener:
> On Wed, Apr 17, 2019 at 11:15 AM Peter Sewell
> wrote:
> >
> > On 17/04/2019, Richard Biener wrote:
> > > On Fri, Apr 12, 2019 at 5:31 PM Peter Sewell
> > > wrote:
...
> > > So this is not what GCC implements
Am Mittwoch, den 17.04.2019, 15:34 +0200 schrieb Richard Biener:
> On Wed, Apr 17, 2019 at 2:56 PM Uecker, Martin
> wrote:
> >
> > Am Mittwoch, den 17.04.2019, 14:41 +0200 schrieb Richard Biener:
> > > On Wed, Apr 17, 2019 at 1:53 PM Uecker, Martin
> > &g
Am Mittwoch, den 17.04.2019, 14:41 +0200 schrieb Richard Biener:
> On Wed, Apr 17, 2019 at 1:53 PM Uecker, Martin
> wrote:
> >
> > > Since
> > > your proposal is based on an abstract machine there isn't anything
> > > like a pointer with multiple
Am Mittwoch, den 02.10.2019, 12:47 +0200 schrieb Richard Biener:
> On Wed, Oct 2, 2019 at 12:46 PM Richard Biener
> wrote:
> >
> > On Tue, Oct 1, 2019 at 7:49 PM Uecker, Martin
> > wrote:
...
> > >
> > > In particular, the idea is to make structs
Am Mittwoch, den 02.10.2019, 14:18 +0200 schrieb Richard Biener:
> On Wed, Oct 2, 2019 at 1:57 PM Uecker, Martin
> wrote:
> >
Thank you for your answers.
> > Finally, how does LTO does it? It somehow also needs to unify
> > different tagged types? Could we reus
Am Mittwoch, den 02.10.2019, 15:12 +0200 schrieb Richard Biener:
> On Wed, Oct 2, 2019 at 3:10 PM Richard Biener
> wrote:
> >
> > On Wed, Oct 2, 2019 at 2:35 PM Uecker, Martin
> > wrote:
> > >
> > > Am Mittwoch, den 02.10.2019, 14:18 +0200 schrieb R
Am Mittwoch, den 02.10.2019, 17:37 +0200 schrieb Richard Biener:
> On October 2, 2019 3:55:43 PM GMT+02:00, "Uecker, Martin"
>
> wrote:
> > Am Mittwoch, den 02.10.2019, 15:12 +0200 schrieb Richard Biener:
> > > On Wed, Oct 2, 2019 at 3:10 PM Richard Biener
&g
Hi,
I have a proposal for making changes to the rules for
compatibility of tagged types in C2X (N2366). This was
received with interest by WG14, so there is a chance
that this could get accepted into C2X.
In particular, the idea is to make structs (+ unions, enums)
with the same tag and the
Am Freitag, den 04.10.2019, 14:28 +0200 schrieb Richard Biener:
> On Fri, Oct 4, 2019 at 1:55 PM Uecker, Martin
> wrote:
> >
> > Am Freitag, den 04.10.2019, 12:29 +0200 schrieb Richard Biener:
> > > On Wed, Oct 2, 2019 at 8:24 PM Uecker, Martin
> > > wrot
Am Freitag, den 04.10.2019, 12:29 +0200 schrieb Richard Biener:
> On Wed, Oct 2, 2019 at 8:24 PM Uecker, Martin
> wrote:
> >
> > Am Mittwoch, den 02.10.2019, 17:37 +0200 schrieb Richard Biener:
> >
> > ...
> >
> > > > > Oh, and LT
In the following example, it seems
that 'bar' could be optimized to
return '1' and every else could be
optimized away. Or am I missing
something? Do I need to add
some specific compiler flags?
static int a = 1;
static int *p;
extern
void foo(void)
{
p =
}
extern
int bar(void)
{
return
Am Dienstag, den 11.02.2020, 21:43 +0100 schrieb Richard Biener:
> On February 11, 2020 9:32:14 PM GMT+01:00, "Uecker, Martin"
>
> wrote:
> >
> > In the following example, it seems
> > that 'bar' could be optimized to
> > return '1' and every else c
I tested a recent GCC from git and noticed a couple
of new warnings for VLA parameters.
(Martin, I assume this is your work. First, let me
say: thank you! I think this is really important.)
Here is some feedback from running this on an
existing code base. See below for comments and
toy
Hi all,
the following code compiles into a mov instruction
on x86_64. I wonder why. The struct has alignment 4,
so a mov might not be atomic if the struct is not
alligned to its full size. For this reason,
I expected a call to libatomic instead
(LLVM does this). What am I missing?
The
Am Montag, den 16.11.2020, 12:10 +0100 schrieb Peter Zijlstra:
> ( restoring at least linux-toolcha...@vger.kernel.org, since that
> seems
> to have gone missing )
>
> On Mon, Nov 16, 2020 at 10:11:50AM +0100, Richard Biener wrote:
> > On Sun, Nov 15, 2020 at 11
Am Dienstag, den 17.11.2020, 11:31 -0800 schrieb Linus Torvalds:
> On Tue, Nov 17, 2020 at 11:25 AM Jakub Jelinek wrote:
> >
> > It would need to be typeof( (typeof(type)) (type) ) to not be that
> > constrained on what kind of expressions it accepts as arguments.
>
> Yup.
>
> > Anyway, it
> On Wed, Nov 04, 2020 at 07:31:42PM +0100, Uros Bizjak wrote:
> > Hello!
> >
> > I was looking at the recent linux patch series [1] where segment
> > qualifiers (named address spaces) were introduced to handle percpu
> > variables. In the patch [2], the author mentions that:
> >
> > --q--
> >
Am Montag, den 17.05.2021, 09:08 +0200 schrieb Richard Biener:
> On Sun, May 16, 2021 at 8:57 AM Uecker, Martin
> wrote:
> >
> >
> > Hi Richard,
> >
> > I noticed that GCC 11 has different behavior in the following
> > example r
Am Montag, den 17.05.2021, 09:44 +0200 schrieb Richard Biener:
> On Mon, May 17, 2021 at 9:32 AM Uecker, Martin
> wrote:
> >
> >
> > Am Montag, den 17.05.2021, 09:08 +0200 schrieb Richard Biener:
> > > On Sun, May 16, 2021 at 8:57 AM Uecker, Martin
> >
Hi Richard,
I noticed that GCC 11 has different behavior in the following
example relative to 10.2 with -O2. I wonder whether this
is an intentional change and if yes, what are the rules?
Thanks!
Martin
https://godbolt.org/z/57res7ax1
#include
#include
__attribute__((__noinline__,
I wonder if we could get a nice short command-line option
for recommended safety/security related flags.
We have -Ox for optimization and -Wall for a useful set
of recommended warnings.
I am thinking about options such as
-ftrapv
-fsanitize=undefined -fsanitize-undefined-trap-on-error
Hi Richard,
here is another case where it seems that TBAA goes
wrong. Since this is not in a loop, it seems this
is something else than what we discussed. Is
this a known issue?
Best,
Martin
#include
#include
union u {
long x;
long long y;
};
__attribute__((noinline,noclone))
long
Am Dienstag, dem 29.11.2022 um 14:58 + schrieb Michael Matz:
> Hey,
>
> On Tue, 29 Nov 2022, Alex Colomar via Gcc wrote:
>
> > How about the compiler parsing the parameter list twice?
>
> This _is_ unbounded look-ahead. You could avoid this by using "."
> for
> your new syntax. Use
Hi,
Am Dienstag, dem 29.11.2022 um 15:44 + schrieb Michael Matz:
> Hey,
>
> On Tue, 29 Nov 2022, Uecker, Martin wrote:
>
> > It does not require any changes on how arrays are represented.
> >
> > As part of VM-types the size becomes part of the type and t
A while ago Eric Botcazou added support for function descriptors
as a replacement for trampolines. This is used in Ada, but not
in C where it would also imply a change of ABI. Still, as nested
functions are generally not used across interface boundaries,
I thought it would be really useful to
Am Montag, den 20.08.2018, 22:34 + schrieb Joseph Myers:
> On Mon, 20 Aug 2018, Uecker, Martin wrote:
>
> > This is a new version which adds proper changelog entries and
> > a test case (no actual code changes).
>
> Please include the overall description of a
Am Dienstag, den 21.08.2018, 21:34 + schrieb Joseph Myers:
> On Tue, 21 Aug 2018, Uecker, Martin wrote:
>
> > > I don't see why this is target-specific (if it is, the documentation for
> > > users in invoke.texi should explain what targets it works for and wha
When running the test suite with this patch applied and
"-fno-trampolines", there are some errors. Most of it is expected
(e.g. nested-6.c calls qsort which fails because it has not
itself been compiled with -fno-trampolines).
One test case for __builtin_call_with_static_chain
in
This is a new version which adds proper changelog entries and
a test case (no actual code changes).
Bootstrapped an regression tested on x86_64.
gcc/
* common.opt (flag_trampolines): Change default.
* calls.c (prepare_call_address): Remove check for
Hi Richard,
as Joseph pointed out, there are some related discussions
on the WG14 reflector. How a about moving the discussion
there?
I find your approach very interesting and that it already
comes with an implementation is of course very useful
But I don't really understand the reasons why
Am Donnerstag, den 18.10.2018, 20:53 +0100 schrieb Richard Sandiford:
> "Uecker, Martin" writes:
> > Hi Richard,
> >
> > responding here to a couple of points.
> >
> > For bignums and for a type-descibing type 'type'
> > ther
Hi Richard,
responding here to a couple of points.
For bignums and for a type-descibing type 'type'
there were proposals (including from me) to implement
these as variable-sized types which have some restrictions,
i.e. they cannot be stored in a struct/union.
Most of the restrictions for these
Am Mittwoch, den 17.10.2018, 13:30 +0100 schrieb Richard Sandiford:
> [ Sorry that there were so many typos in my last reply, will try to
> do better
> this time... ]
...
> I think the key difference between sizeless types and full C99-style
> VLAs is that the size and layout of sizeless
Hi Joseph,
here is a new version of this patch which adds a warning
for targets which do not support -fno-trampolines and
only runs the test case on architectures where this is
supported. It seems that documentation for this general
feature has improved in the meantime so I only mention
C as
Hi Wilco,
Am Mittwoch, den 12.12.2018, 22:04 + schrieb Wilco Dijkstra:
> Hi Martin,
>
> > Does a non-executable stack actually improve security?
>
> Absolutely, it's like closing your front door rather than just leave it open
> for anyone.
The question is whether it is like closing the
Hi Jeff,
thank you. I fixed all the minor issues, but see below.
Am Montag, den 03.12.2018, 14:56 -0700 schrieb Jeff Law:
> On 11/4/18 1:48 PM, Uecker, Martin wrote:
> > Hi Joseph,
> >
> > here is a new version of this patch which adds a warning
> > for target
Am Mittwoch, den 12.12.2018, 18:53 + schrieb Wilco Dijkstra:
> Hi,
>
> > > On 12 Dec 2018,@18:21, Richard Earnshaw (lists)
>
> wrote:
>
> > > However, that introduces an issue that that
> > > code is potentially used across multiple versions of gcc, with
> > > potentially different choices
Am Montag, den 17.12.2018, 10:28 -0700 schrieb Jeff Law:
> On 12/16/18 3:45 PM, Uecker, Martin wrote:
> > Am Sonntag, den 16.12.2018, 09:13 -0700 schrieb Jeff Law:
> > > On 12/16/18 6:45 AM, Uecker, Martin wrote:
> > > > Am Freitag, den 14.12.2018, 18:20 -0700 schrieb
Am Montag, den 17.12.2018, 10:31 -0700 schrieb Martin Sebor:
> On 12/16/18 6:45 AM, Uecker, Martin wrote:
> > Am Freitag, den 14.12.2018, 18:20 -0700 schrieb Martin Sebor:
> > > On 12/14/18 4:36 PM, Jeff Law wrote:
> > > > On 12/14/18 3:05 AM, Uecker, Martin
Am Montag, den 17.12.2018, 15:25 + schrieb Szabolcs Nagy:
> On 16/12/2018 22:45, Uecker, Martin wrote:
> > Am Sonntag, den 16.12.2018, 09:13 -0700 schrieb Jeff Law:
> > > Ultimately using function descriptors is an ABI breaking choice and we
> > > might declare that
Am Dienstag, den 18.12.2018, 09:03 -0700 schrieb Jeff Law:
> On 12/18/18 8:32 AM, Jakub Jelinek wrote:
> > On Tue, Dec 18, 2018 at 10:23:46AM -0500, Paul Koning wrote:
> > >
> > >
> > > > On Dec 17, 2018, at 2:23 PM, Szabolcs Nagy
> > > >
Am Dienstag, den 18.12.2018, 17:24 +0100 schrieb Jakub Jelinek:
> On Tue, Dec 18, 2018 at 09:03:41AM -0700, Jeff Law wrote:
> > Right. This is the classic example and highlights the ABI concerns. If
> > we use the low bit to distinguish between a normal function pointer and
> > a pointer to a
Am Dienstag, den 18.12.2018, 17:29 +0100 schrieb Martin Uecker:
> Am Dienstag, den 18.12.2018, 17:24 +0100 schrieb Jakub Jelinek:
> > On Tue, Dec 18, 2018 at 09:03:41AM -0700, Jeff Law wrote:
> > > Right. This is the classic example and highlights the ABI concerns. If
> > > we use the low bit to
Am Montag, den 17.12.2018, 10:28 -0700 schrieb Jeff Law:
> > But the alignment increase itself on 'i386' and 'aarch64'
> > might be unacceptable. In this case, the only safe change
> > is to make the higher alignment also depend on
> > "-fno-trampolines". Would this be acceptable?
>
> Unclear
Am Freitag, den 21.12.2018, 16:13 -0500 schrieb Hans-Peter Nilsson:
> On Tue, 18 Dec 2018, Uecker, Martin wrote:
> > Am Dienstag, den 18.12.2018, 17:29 +0100 schrieb Martin Uecker:
> > > Am Dienstag, den 18.12.2018, 17:24 +0100 schrieb Jakub Jelinek:
> > > > On T
Am Freitag, den 14.12.2018, 18:20 -0700 schrieb Martin Sebor:
> On 12/14/18 4:36 PM, Jeff Law wrote:
> > On 12/14/18 3:05 AM, Uecker, Martin wrote:
> > >
> > > Am Donnerstag, den 13.12.2018, 16:35 -0700 schrieb Jeff Law:
> > > > On
Am Sonntag, den 16.12.2018, 09:13 -0700 schrieb Jeff Law:
> On 12/16/18 6:45 AM, Uecker, Martin wrote:
> > Am Freitag, den 14.12.2018, 18:20 -0700 schrieb Martin Sebor:
> > > On 12/14/18 4:36 PM, Jeff Law wrote:
> > > > On 12/14/18 3:05 AM, Uecker, Martin wrote:
>
Am Donnerstag, den 13.12.2018, 16:35 -0700 schrieb Jeff Law:
> On 12/12/18 11:12 AM, Uecker, Martin wrote:
...
> > > > diff --git a/gcc/c/c-objc-common.h b/gcc/c/c-objc-common.h
> > > > index 78e768c2366..ef039560eb9 100644
> > > > --- a/gcc/c/c-objc-commo
Hi Wilco,
Am Donnerstag, den 13.12.2018, 16:33 + schrieb Wilco Dijkstra:
> Uecker, Martin wrote:
> > Am Mittwoch, den 12.12.2018, 22:04 + schrieb Wilco Dijkstra:
> > > Hi Martin,
> > >
> > > > Does a non-executable stack actually improve secur
Is there a change that we can move forward with this?
I think this is a very useful feature and might be especially
important if GCC is going to activate -Wtrampoline with
-Wall on some architectures.
Best,
Martin
Am Sonntag, den 04.11.2018, 21:48 +0100 schrieb Martin Uecker:
> Hi Joseph,
>
Does this patch have a change? This version seems risk-free and
is a clear improvement from simply doing nothing for
'-fno-trampolines'. Also it is useful in situations where
one cannot have an executable stack.
I am currently thinking about working
around this problem by calling nested
Am Sonntag, den 16.12.2018, 09:13 -0700 schrieb Jeff Law:
> It's also important to remember that not every target which uses
> function descriptors uses the LSB. On some targets the LSB may switch
> between modes (arm vs thumb for example). So on those targets the use
> of descriptors may imply
Am Dienstag, den 18.12.2018, 17:42 +0100 schrieb Jakub Jelinek:
> On Tue, Dec 18, 2018 at 04:33:48PM +0000, Uecker, Martin wrote:
> > > Yes, something like this. If the trampolines are pre-allocated, this could
> > > even avoid the need to clear the cache on archs
Hi,
here is a new version of this patch. It makes "-fno-trampolines"
work for C which then makes it possible to use nested functions
without executable stack. The only change in this version is in
the documentation.
Maybe it could be reconsidered at this stage?
Bootstrapped and regression
Am Freitag, den 09.08.2019, 16:45 -0600 schrieb Jeff Law:
> On 6/24/19 3:35 PM, Uecker, Martin wrote:
> >
> >
> > Hi,
> >
> > here is a new version of this patch. It makes "-fno-trampolines"
> > work for C which then makes it possible to
Am Samstag, den 29.02.2020, 10:57 +0100 schrieb Jakub Jelinek:
> On Sat, Feb 29, 2020 at 09:50:00AM +0000, Uecker, Martin wrote:
> > One could also simply remove the error in varasm.c. This
> > would preserve the optimization. As a side effect, this
> > would allow register wi
One could also simply remove the error in varasm.c. This
would preserve the optimization. As a side effect, this
would allow register without __asm__ at file scope, but
there do not seem to be any disadvantages. (register
at file scope is already diagnosed by the C FE when
using --pedantic).
Am Mittwoch, den 29.01.2020, 09:45 +0100 schrieb Richard Biener:
> On Tue, Jan 28, 2020 at 1:24 PM Uecker, Martin
> wrote:
> > >
> > > Note for the current PTA implementation there's almost no cases we can
> > > handle conservatively enough. Consider
Hi Richard,
thank you for your response.
Am Montag, den 27.01.2020, 15:42 +0100 schrieb Richard Biener:
> On Fri, Jan 24, 2020 at 12:46 AM Uecker, Martin
> wrote:
> >
> > Am Donnerstag, den 23.01.2020, 14:18 +0100 schrieb Richard Biener:
> > > On Wed, Jan 22, 20
Am Freitag, den 31.01.2020, 09:02 +0100 schrieb Richard Biener:
> On Thu, Jan 30, 2020 at 6:09 PM Uecker, Martin
> wrote:
> >
> > Am Donnerstag, den 30.01.2020, 16:50 + schrieb Michael Matz:
> > > Hi,
> > >
> > > On Thu, 30 Jan 2020, Uecker, M
Am Donnerstag, den 30.01.2020, 16:50 + schrieb Michael Matz:
> Hi,
>
> On Thu, 30 Jan 2020, Uecker, Martin wrote:
>
> > > guarantees face serious implementation difficulties I think
> > > so the only alternative to PVNI (which I think is implementable
> >
Hi Richard and Joseph,
for discussion: here is my simple patch
for __builtin_escape/__builtin_bless.
Maybe it does something stupid.
Best,
Martin
diff --git a/gcc/builtins.c b/gcc/builtins.c
index e4a8694054e..d0046135213 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -6014,6
Am Dienstag, den 28.01.2020, 11:01 +0100 schrieb Richard Biener:
> On Tue, Jan 28, 2020 at 8:20 AM Alexander Monakov wrote:
> >
> > On Tue, 28 Jan 2020, Uecker, Martin wrote:
> >
> > > > (*) this also shows the level of "obfuscation" needed to fool com
Am Dienstag, den 28.01.2020, 10:20 +0300 schrieb Alexander Monakov:
> On Tue, 28 Jan 2020, Uecker, Martin wrote:
>
> > > (*) this also shows the level of "obfuscation" needed to fool compilers
> > > to lose provenance knowledge is hard to predict.
> >
Am Dienstag, den 04.02.2020, 15:01 +0100 schrieb Richard Biener:
> On Sat, Feb 1, 2020 at 1:04 AM Uecker, Martin
> wrote:
> >
> >
> >
> > Hi Richard and Joseph,
> >
> > for discussion: here is my simple patch
> > for __builtin_escape/__builti
Am Donnerstag, den 30.01.2020, 09:30 +0100 schrieb Richard Biener:
> On Wed, Jan 29, 2020 at 3:00 PM Uecker, Martin
> wrote:
...
> > > I guess I'd me much more happy if PVNI said that when
> > > an integer is converted to a pointer and the integer
> > > is valu
Am Donnerstag, den 23.01.2020, 14:18 +0100 schrieb Richard Biener:
> On Wed, Jan 22, 2020 at 12:40 PM Martin Sebor wrote:
> >
> > On 1/22/20 8:32 AM, Richard Biener wrote:
> > > On Tue, 21 Jan 2020, Alexander Monakov wrote:
> > >
> > > > On Tue, 21 Jan 2020, Richard Biener wrote:
> > > >
> > >
Hi Joseph,
here is the (unfinished) patch to support
mixing of labels in C2X.
I preserved existing tests by adding
"-std=c17 -pedantic-error"
So far, I haven't figured out how
to fix the OpenMP related warning
in 'gcc.dg/gomp/barrier-2.c'.
Best,
Martin
diff --git a/gcc/c/c-parser.c
Am Montag, den 23.11.2020, 20:21 + schrieb Joseph Myers:
> On Mon, 23 Nov 2020, Uecker, Martin wrote:
>
> > Joseph,
> >
> > here is the patch to not drop qualifiers for _Atomic in
> > typeof. I am not sure whether this is appropriate in
> > stage3, b
Hi Joseph,
the patch to drop qualifiers during lvalue conversion
was broken, because the code to emit atomic loads did
not trigger anymore. I now added a test that scans for
"atomic_load".
I should have taken the new warning for
_Atomic int y;
y; // warning statement with no effect
as a
Am Montag, den 23.11.2020, 14:55 +0100 schrieb Christophe Lyon:
> Hi,
>
>
> On Thu, 19 Nov 2020 at 07:34, Uecker, Martin
> wrote:
> >
> >
> > Here is another version of the patch. The
> > only difference is the additional the check
>
Joseph,
here is the patch to not drop qualifiers for _Atomic in
typeof. I am not sure whether this is appropriate in
stage3, but I wanted to leave it here for you to comment
and so that it does not lost.
First, I noticed that the change to drop qualifiers
in lvalue conversion also implies that
Here is a patch to drop qualifiers in assignment expressions.
-- Martin
C: Drop qualifiers of assignment expressions. [PR98047]
ISO C17 6.5.15.1 specifies that the result is the
type the LHS would have after lvalue conversion.
2020-12-12 Martin Uecker
gcc/c/
PR c/98047
Here is a patch that fixes an incorrect warning for volatile
that appeared with the lvalue change.
-- Martin
C: Avoid incorrect warning for volatile in compound expressions [PR98260]
2020-12-12 Martin Uecker
gcc/c/
PR c/98260
* c-parser.c (c_parser_expression): Look into
Here is a patch that adds the minor corrections needed for
qualifiers of pointers to arrays in C23.
-- Martin
C: Correct qualifiers for pointers to arrays according to C2X [PR98397]
2020-12-12 Martin Uecker
gcc/c/
PR c/98397
* c-typeck.c (comp_target_types): Change
With the fix to PR98047 "C: Drop qualifiers of assignment expressions."
also the new incorrect warning for assignment of certain volatile expressions
introduced by dropping qualifiers in lvalue conversion (PR97702)
disappeared [P98029]. This patch only adds a test case.
-- Martin
C: Add test
Am Donnerstag, den 19.11.2020, 18:58 + schrieb Joseph Myers:
> On Thu, 19 Nov 2020, Uecker, Martin wrote:
...
>
> > +void g(void)
> > +{
> > + volatile int j;
> > + typeof((0,j)) i21; i21 = j;;
> > + typeof(+j) i22; i22 = j;;
> > + typeof(-j) i23;
Here is another version of the patch. The
only difference is the additional the check
using 'tree_ssa_useless_type_conversion'.
Best,
Martin
C: Drop qualifiers during lvalue conversion. PR97702
2020-11-XX Martin Uecker
gcc/
* gcc/gimplify.c
To better understand what impact this may have, I added code
to drop the qualifiers in 'convert_lvalue_to_rvalue'. Here
is the patch.
There are three new errors in the testsuite:
In 'gcc.dg/cond-constqual-1.c' we test for the opposite
behavior for conditional operators. I do not know why.
We
Thanks, Marek!
Am Montag, den 09.11.2020, 23:41 + schrieb Joseph Myers:
> On Sat, 7 Nov 2020, Uecker, Martin wrote:
> > t = (const T) { { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 } };
> > test ();
> > }
> >
> > Not sure what to do about it, maybe 'convert' is not
> >
Am Montag, den 14.09.2020, 20:30 + schrieb Joseph Myers:
> On Sun, 13 Sep 2020, Uecker, Martin wrote:
>
> > Hi Joseph,
> >
> > here is the (unfinished) patch to support
> > mixing of labels in C2X.
>
> I think there should be explicit tests for old stan
Hi Joseph,
here is the revised patch. I remove the 'fallthrough'
code as suggested, so everything becomes even simpler.
Some tests had to be changed then, but it seems Ok to
me.
Best,
Martin
diff --git a/gcc/c/ChangeLog b/gcc/c/ChangeLog
index ca844ca775a..c656b5f4cc5 100644
---
Am Freitag, den 06.11.2020, 22:07 + schrieb Joseph Myers:
> On Fri, 6 Nov 2020, Uecker, Martin wrote:
>
> > Hi Joseph,
> >
> > here is the revised patch. I remove the 'fallthrough'
> > code as suggested, so everything becomes even simpler.
> > Some tests
Am Freitag, den 01.01.2021, 00:01 + schrieb Joseph Myers:
>
>
> I'd expect c2x-* tests to use -std=c2x not -std=gnu2x. Tests needing
> -std=gnu2x can be gnu2x-* tests, but you should be able to test the types
> using _Generic without needing any gnu2x features. c2x-* tests should
> also
(PING. In case you missed this. Sorry, forgot to CC you.)
Am Montag, den 24.05.2021, 08:05 +0200 schrieb Martin Uecker:
> Hi Joseph,
>
> I found some time to update this patch. The only real change
> of the patch is the qualifier in the conditional expression for
> pointer to arrays in C2X. All
Hi Joseph,
I found some time to update this patch. The only real change
of the patch is the qualifier in the conditional expression for
pointer to arrays in C2X. All the rest are the warnings,
which were wrong in the last version.
I hope I got this correct this time in combination with
Am Donnerstag, den 12.08.2021, 16:58 + schrieb Joseph Myers:
> On Mon, 24 May 2021, Uecker, Martin wrote:
>
> > - else if (VOID_TYPE_P (TREE_TYPE (type1))
> > - && !TYPE_ATOMIC (TREE_TYPE (type1)))
> > - {
> > - if ((TREE_
Am Montag, den 16.08.2021, 06:49 +0200 schrieb Martin Uecker:
> Am Montag, den 16.08.2021, 00:30 -0400 schrieb Jason Merrill:
> > On 8/1/21 1:36 PM, Uecker, Martin wrote:
> > > Here is an attempt to fix some old and annoying bugs related
> > > to VLAs and statement
Am Montag, den 16.08.2021, 00:30 -0400 schrieb Jason Merrill:
> On 8/1/21 1:36 PM, Uecker, Martin wrote:
> >
> > Here is an attempt to fix some old and annoying bugs related
> > to VLAs and statement expressions. In particulary, this seems
> > to fix the issues with va
1 - 100 of 120 matches
Mail list logo
