Next version with the improved location. I assume the [PATCH]
should become part of the commit message.
Bootstrapped and regression tested on x86_64.
c: Error message for incorrect use of static in array declarations.
Add an explicit error messages when c99's static is
used wi
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 c/1123
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 point
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.
L
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 I und
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 expre
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 patc
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 compu
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 mo
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 pa
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 some o
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
wit
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 parameters wi
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.
gcc/t
(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
-pedantic
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 pedwar
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 tel
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, but
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 (gimplify_modify
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 (&t);
> > }
> >
> > Not sure what to do about it, maybe 'convert' is
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 cou
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.
> > S
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
--- a/gcc/c/Change
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 (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 b/gcc/c/
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).
Best
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 +6014,31
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
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. Con
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 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 use n
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 tes
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 functio
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 at
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 des
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
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 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 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 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
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 fro
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
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
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,
>
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 sup
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'
> > there w
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 types
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 thi
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 wh
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
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
flag
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 gcc.dg/cwsc1.cfa
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 ha
87 matches
Mail list logo
