[committed] c: Add missing conditions in Walloc-size to avoid ICEs [PR112347]

2023-11-02 Thread Uecker, Martin
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

Re: [PATCH v4] Fix ICE when mixing VLAs and statement expressions [PR91038]

2021-11-16 Thread Uecker, Martin
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

Re: [PATCH v4] Fix ICE when mixing VLAs and statement expressions [PR91038]

2021-11-08 Thread Uecker, Martin
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

Re: [PATCH v4] Fix ICE when mixing VLAs and statement expressions [PR91038]

2021-11-07 Thread Uecker, Martin
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

[PATCH v4] Fix ICE when mixing VLAs and statement expressions [PR91038]

2021-10-31 Thread Uecker, Martin
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.

Re: [PATCH v4] Fix ICE when mixing VLAs and statement expressions [PR91038]

2021-10-19 Thread Uecker, Martin
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

[PATCH v4] Fix ICE when mixing VLAs and statement expressions [PR91038]

2021-10-17 Thread Uecker, Martin
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

Re: [PATCH v3] Fix ICE when mixing VLAs and statement expressions [PR91038]

2021-10-02 Thread Uecker, Martin
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

Re: [PATCH v3] Fix ICE when mixing VLAs and statement expressions [PR91038]

2021-09-23 Thread Uecker, Martin
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 > &

[PATCH v3] Fix ICE when mixing VLAs and statement expressions [PR91038]

2021-09-05 Thread Uecker, Martin
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

Re: [PATCH] Fix ICE when mixing VLAs and statement expressions [PR91038]

2021-08-23 Thread Uecker, Martin
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

Re: [C PATCH] qualifiers of pointers to arrays in C2X [PR 98397]

2021-08-22 Thread Uecker, Martin
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_

Re: [PATCH] Fix ICE when mixing VLAs and statement expressions [PR91038]

2021-08-15 Thread Uecker, Martin
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

[PATCH v2] Fix ICE when mixing VLAs and statement expressions [PR91038]

2021-08-14 Thread Uecker, Martin
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

Re: [C PATCH] Evaluate argument of sizeof that are structs of variable size.

2021-08-09 Thread Uecker, Martin
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

[C PATCH] Evaluate argument of sizeof that are structs of variable size.

2021-08-09 Thread Uecker, Martin
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

Re [PATCH] Fix ICE when mixing VLAs and statement expressions [PR91038]

2021-08-09 Thread Uecker, Martin
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

Re: Re: [PATCH] Fix ICE when mixing VLAs and statement expressions [PR91038]

2021-08-09 Thread Uecker, Martin
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

Re: Re: [PATCH] Fix ICE when mixing VLAs and statement expressions [PR91038]

2021-08-09 Thread Uecker, Martin
> 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

[PATCH] Fix ICE when mixing VLAs and statement expressions [PR91038]

2021-08-01 Thread Uecker, Martin
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

PING^2 [C PATCH] qualifiers of pointers to arrays in C2X [PR 98397]

2021-08-01 Thread Uecker, Martin
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

Re: [PATCH] incorrect arguments designated in -Wnonnull for arrays

2021-07-28 Thread Uecker, Martin
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

[PATCH] incorrect arguments designated in -Wnonnull for arrays

2021-07-25 Thread Uecker, Martin
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.

Re: [C PATCH] qualifiers of pointers to arrays in C2X [PR 98397]

2021-06-11 Thread Uecker, Martin
(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

[C PATCH] qualifiers of pointers to arrays in C2X [PR 98397]

2021-05-24 Thread Uecker, Martin
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

Re: [C PATCH] qualifiers of pointers to arrays in C2X [PR 98397]

2021-01-17 Thread Uecker, Martin
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

[C PATCH] [testsuite] bogus warning [P98029]

2020-12-23 Thread Uecker, Martin
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

[C PATCH] qualifiers of pointers to arrays in C2X [PR 98397]

2020-12-21 Thread Uecker, Martin
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

[C PATCH] Avoid incorrect warning for volatile in compound expressions [PR 98260]

2020-12-13 Thread Uecker, Martin
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

[C PATCH] Drop qualifiers of assignment expressions [PR 97981]

2020-12-13 Thread Uecker, Martin
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

[C PATCH] fix atomic loads [PR 97981]

2020-12-05 Thread Uecker, Martin
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

Re: [C PATCH] Do not drop qualifiers for _Atomic in typeof

2020-11-25 Thread Uecker, Martin
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

[C PATCH] Do not drop qualifiers for _Atomic in typeof

2020-11-23 Thread Uecker, Martin
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

Re: [C PATCH] Drop qualifiers during lvalue conversion

2020-11-23 Thread Uecker, Martin
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 >

Re: [C PATCH] Drop qualifiers during lvalue conversion

2020-11-19 Thread Uecker, Martin
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;

[C PATCH] Drop qualifiers during lvalue conversion

2020-11-18 Thread Uecker, Martin
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

Re: [C PATCH RFC] Drop qualifiers during lvalue conversion

2020-11-15 Thread Uecker, Martin
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 > >

Re: [r11-4813 Regression] FAIL: c-c++-common/Wimplicit-fallthrough-20.c -std=gnu++98 (test for warnings, line 36) on Linux/x86_64

2020-11-07 Thread Uecker, Martin
Thanks, Marek!

[C PATCH RFC] Drop qualifiers during lvalue conversion

2020-11-07 Thread Uecker, Martin
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

Re: [PATCH] mixing of labels and code in C2X

2020-11-06 Thread Uecker, Martin
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

Re: [PATCH] mixing of labels and code in C2X

2020-11-05 Thread Uecker, Martin
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 ---

Re: [PATCH] mixing of labels and code in C2X

2020-11-01 Thread Uecker, Martin
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

[PATCH] mixing of labels and code in C2X

2020-09-13 Thread Uecker, Martin
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

Re: [PATCH] gimplify: Don't optimize register const vars to static [PR93949]

2020-02-29 Thread Uecker, Martin
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

Re: [PATCH] gimplify: Don't optimize register const vars to static [PR93949]

2020-02-29 Thread Uecker, Martin
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).

Re: [RFC PATCH] __builtin_escape/__builtin_bless

2020-02-04 Thread Uecker, Martin
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

[RFC PATCH] __builtin_escape/__builtin_bless

2020-01-31 Thread Uecker, Martin
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

Re: [PATCH] doc: clarify the situation with pointer arithmetic

2020-01-31 Thread Uecker, Martin
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

Re: [PATCH] doc: clarify the situation with pointer arithmetic

2020-01-30 Thread Uecker, Martin
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 > >

Re: [PATCH] doc: clarify the situation with pointer arithmetic

2020-01-30 Thread Uecker, Martin
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

Re: [PATCH] doc: clarify the situation with pointer arithmetic

2020-01-29 Thread Uecker, Martin
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

Re: [PATCH] doc: clarify the situation with pointer arithmetic

2020-01-28 Thread Uecker, Martin
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

Re: [PATCH] doc: clarify the situation with pointer arithmetic

2020-01-28 Thread Uecker, Martin
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. > >

Re: [PATCH] doc: clarify the situation with pointer arithmetic

2020-01-27 Thread Uecker, Martin
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

Re: [PATCH] doc: clarify the situation with pointer arithmetic

2020-01-23 Thread Uecker, Martin
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: > > > > > > >

Re: [PATCH v6][C][ADA] use function descriptors instead of trampolines in C

2019-08-10 Thread Uecker, Martin
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

[PATCH v6][C][ADA] use function descriptors instead of trampolines in C

2019-06-24 Thread Uecker, Martin
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

[PING] [PATCH v5][C][ADA] use function descriptors instead of trampolines in C

2019-01-13 Thread Uecker, Martin
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

Re: [PATCH v4][C][ADA] use function descriptors instead of trampolines in C

2018-12-21 Thread Uecker, Martin
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

[PATCH v5][C][ADA] use function descriptors instead of trampolines in C

2018-12-20 Thread Uecker, Martin
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

Re: [PATCH v4][C][ADA] use function descriptors instead of trampolines in C

2018-12-19 Thread Uecker, Martin
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

Re: [PATCH v4][C][ADA] use function descriptors instead of trampolines in C

2018-12-19 Thread Uecker, Martin
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

Re: [PATCH v4][C][ADA] use function descriptors instead of trampolines in C

2018-12-18 Thread Uecker, Martin
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

Re: [PATCH v4][C][ADA] use function descriptors instead of trampolines in C

2018-12-18 Thread Uecker, Martin
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

Re: [PATCH v4][C][ADA] use function descriptors instead of trampolines in C

2018-12-18 Thread Uecker, Martin
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 > > > >

Re: [PATCH v4][C][ADA] use function descriptors instead of trampolines in C

2018-12-17 Thread 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

Re: [PATCH v4][C][ADA] use function descriptors instead of trampolines in C

2018-12-17 Thread Uecker, Martin
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

Re: [PATCH v4][C][ADA] use function descriptors instead of trampolines in C

2018-12-17 Thread 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

Re: [PATCH v4][C][ADA] use function descriptors instead of trampolines in C

2018-12-16 Thread Uecker, Martin
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: >

Re: [PATCH v4][C][ADA] use function descriptors instead of trampolines in C

2018-12-16 Thread Uecker, Martin
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

Re: [PATCH v4][C][ADA] use function descriptors instead of trampolines in C

2018-12-14 Thread Uecker, Martin
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

Re: [ping] Change static chain to r11 on aarch64

2018-12-13 Thread Uecker, Martin
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

Re: [ping] Change static chain to r11 on aarch64

2018-12-12 Thread Uecker, Martin
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

Re: [ping] Change static chain to r11 on aarch64

2018-12-12 Thread Uecker, Martin
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

[PATCH v4][C][ADA] use function descriptors instead of trampolines in C

2018-12-12 Thread Uecker, Martin
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

Re: [PATCH v3][C][ADA] use function descriptors instead of trampolines in C

2018-12-03 Thread Uecker, Martin
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, >

[PATCH v3][C][ADA] use function descriptors instead of trampolines in C

2018-11-04 Thread Uecker, Martin
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

Re: [00/10][RFC] Splitting the C and C++ concept of "complete type"

2018-10-18 Thread Uecker, Martin
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

Re: [00/10][RFC] Splitting the C and C++ concept of "complete type"

2018-10-18 Thread Uecker, Martin
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

Re: [00/10][RFC] Splitting the C and C++ concept of "complete type"

2018-10-17 Thread Uecker, Martin
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

Re: [00/10][RFC] Splitting the C and C++ concept of "complete type"

2018-10-15 Thread Uecker, Martin
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

Re: [PATCH v2][C][ADA] use function descriptors instead of trampolines in C

2018-08-22 Thread Uecker, Martin
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

Re: [PATCH v2][C][ADA] use function descriptors instead of trampolines in C

2018-08-21 Thread Uecker, Martin
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

[PATCH v2][C][ADA] use function descriptors instead of trampolines in C

2018-08-20 Thread Uecker, Martin
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

Re: [RFC] [PATCH][C][ADA] use function descriptors instead of trampolines in C

2018-08-18 Thread Uecker, Martin
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

[RFC] [PATCH][C][ADA] use function descriptors instead of trampolines in C

2018-08-11 Thread Uecker, Martin
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