I forget to guard against some more cases.
Committed as obvious.
Martin
c: Add missing conditions in Walloc-size to avoid ICEs [PR112347]
Fix ICE because of forgotten checks for pointers to void
and incomplete arrays.
Committed as obvious.
PR
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
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
Am Montag, den 08.11.2021, 19:13 +0100 schrieb Martin Uecker:
> Am Montag, den 08.11.2021, 12:13 -0500 schrieb Jason Merrill:
> > On 11/7/21 01:40, Uecker, Martin wrote:
> > > Am Mittwoch, den 03.11.2021, 10:18 -0400 schrieb Jason Merrill:
>
> ...
>
> > > Tha
Am Montag, den 08.11.2021, 12:13 -0500 schrieb Jason Merrill:
> On 11/7/21 01:40, Uecker, Martin wrote:
> > Am Mittwoch, den 03.11.2021, 10:18 -0400 schrieb Jason Merrill:
...
> >
> > Thank you! I made these changes and ran
> > bootstrap and tests again.
>
> H
Am Mittwoch, den 03.11.2021, 10:18 -0400 schrieb Jason Merrill:
> On 10/31/21 05:22, Uecker, Martin wrote:
> > Hi Jason,
> >
> > here is the fourth version of the patch.
> >
> > I followed your suggestion and now make this
> > transformation sooner in po
Hi Jason,
here is the fourth version of the patch.
I followed your suggestion and now make this
transformation sooner in pointer_int_sum.
I also added a check to only do this
transformation when the pointer is not a
VAR_DECL, which avoids it in the most
common cases where it is not necessary.
Am Montag, den 18.10.2021, 12:35 -0400 schrieb Jason Merrill:
> On 10/17/21 09:52, Uecker, Martin wrote:
> >
> > Here is the 4th version of the patch. I tried to implement
> > Jason's suggestion and this also fixes the problem. But
> > I am not sure
Here is the 4th version of the patch. I tried to implement
Jason's suggestion and this also fixes the problem. But
I am not sure I understand the condition on
the TREE_SIDE_EFFECTS ...
And there is now another problem:
c_finish_omp_for in c-family/c-omp.c does not seem
to understand the
Am Donnerstag, den 23.09.2021, 17:37 -0400 schrieb Jason Merrill:
> On 9/23/21 15:49, Uecker, Martin wrote:
> > Am Mittwoch, den 22.09.2021, 17:18 -0400 schrieb Jason Merrill:
> > > On 9/5/21 15:14, Uecker, Martin wrote:
> > > > Here is the third version of the
Am Mittwoch, den 22.09.2021, 17:18 -0400 schrieb Jason Merrill:
> On 9/5/21 15:14, Uecker, Martin wrote:
> > Here is the third version of the patch. This also
> > fixes the index zero case. Thus, this should be
> > a complete fix for 91038 and should fix all cases
> &
Here is the third version of the patch. This also
fixes the index zero case. Thus, this should be
a complete fix for 91038 and should fix all cases
also supported by clang. Still not working is
returning a struct of variable size from a
statement expression (29970) when the size depends
on
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 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, 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
Here is an update version of the patch. I now reorder
only the gimplification and not other preparation so that
replacing PLACEHOLDER_EXPRs for Ada should continue
to work. I also removed a call to gimplify_type_sizes
somewhere else, which also caused some similar problemes.
This seems to fix
Am Montag, den 09.08.2021, 21:42 + schrieb Joseph Myers:
> On Mon, 9 Aug 2021, Uecker, Martin wrote:
>
> > Evaluate arguments of sizeof that are structs of variable size.
> >
> > Evaluate arguments of sizeof for all types of variable size
> > and not just fo
Here is a patch which changes the behavior of sizeof
when applied to structs of variable size (a GNU
extension) to evaluate its arguments as it does
for VLAs. This is a breaking change, but it seems
this is required if we want to fix [PR29970] (and
it is also more consistent). Together with the
Am Montag, den 02.08.2021, 16:19 +0200 schrieb Martin Uecker:
>
> Am Montag, den 02.08.2021, 16:05 +0200 schrieb Martin Uecker:
> > > On Sun, Aug 1, 2021 at 7:37 PM Uecker, Martin
> > > wrote:
> > > >
> > > > Here is an attempt to fix so
Am Montag, den 02.08.2021, 16:05 +0200 schrieb Martin Uecker:
> > On Sun, Aug 1, 2021 at 7:37 PM Uecker, Martin
> > wrote:
> > >
> > >
> > > Here is an attempt to fix some old and annoying bugs related
> > > to VLAs and statement expressions. In
> On Sun, Aug 1, 2021 at 7:37 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 variably-modified t
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 variably-modified types which are
returned from statement expressions (which works on clang),
but there are still bugs remaining related to structs
Am Freitag, den 11.06.2021, 21:25 +0200 schrieb Martin Uecker:
> (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
Am Dienstag, den 27.07.2021, 10:55 -0600 schrieb Martin Sebor:
> On 7/26/21 12:22 PM, Jeff Law via Gcc-patches wrote:
> >
> > On 7/25/2021 10:23 AM, Uecker, Martin wrote:
> > > Two arguments are switched for -Wnonnull when
> > > warning about array parameter
Two arguments are switched for -Wnonnull when
warning about array parameters with bounds > 0
and which are NULL.
This patch corrects the mistake.
Martin
2021-07-25 Martin Uecker
gcc/
* calls.c (maybe_warn_rdwr_sizes): Correct argument
numbers in warning that were switched.
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
(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
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 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 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
> >
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
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__,
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
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
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
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 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
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, 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
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
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
>
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
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
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 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
> >
> 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--
> >
Thanks, Marek!
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
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
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 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
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 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
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 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 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
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 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
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 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
> >
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 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
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.
> >
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 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:
> > > >
> > >
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
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
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, 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, 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
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 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
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 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.
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 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 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 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 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, 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, 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 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
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
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 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 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 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
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: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 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, 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 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 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
1 - 100 of 120 matches
Mail list logo
