public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Uecker, Martin" <Martin.Uecker@med.uni-goettingen.de>
To: "joseph@codesourcery.com" <joseph@codesourcery.com>
Cc: "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>,
	"law@redhat.com"	<law@redhat.com>,
	"ebotcazou@adacore.com" <ebotcazou@adacore.com>
Subject: Re: [PATCH v2][C][ADA] use function descriptors instead of trampolines in C
Date: Tue, 21 Aug 2018 06:17:00 -0000	[thread overview]
Message-ID: <1534832264.15600.1.camel@med.uni-goettingen.de> (raw)
In-Reply-To: <alpine.DEB.2.21.1808202227370.646@digraph.polyomino.org.uk>

Am Montag, den 20.08.2018, 22:34 +0000 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 change in every version 
> submitted.  That is, the patch submission message should both include a 
> description of the current version (as in a git-style commit message) and, 
> if relevant, a description of what changed relative to the previous 
> version of the patch (which would not go in the commit message).

Thank you. I will keep this in mind in the future.

> A key thing I'm not clear on is what the user-visible difference in 
> compiler behavior is supposed to be with this patch.  Whatever that 
> user-visible difference is, I'd expect it to result in some change to the 
> documentation of -ftrampolines in invoke.texi (describing the new feature, 
> or changing a description of a limitation of an existing feature, or 
> something like that).

The option -fno-trampolines already exists and is documented.
From the description one would think that using this option would
turn off generation of trampolines and replace them by descriptors.
This then eliminates the need for an executable stack for nested
functions.

The user visible change of my patch is that it now actually works for
the C language. So I don't think this patch needs to change the 
documentation as it makes the behavior match the existing documentation.  


Neverthless, I think the documentation of the existing option should
be improved to document the remaining limitations of this option
regarding languages and architectures. I am happy to add such
wording, and propose it as an independent patch.


> > +/* { dg-do run { target x86_64-*-* } } */
> 
> It is always wrong for a test to use x86_64-*-* like that, because 
> anything that should be tested for 64-bit code generation for an x86_64 
> target should also be tested for i[34567]86-*-* -m64, and if you don't 
> want to test for 32-bit code generation, you need to avoid testing for 
> x86_64-*-* -m32, which that test would test for.  Anything genuinely 
> x86-specific should go in gcc.target/i386 and then be conditioned on 
> effective-target keywords such as lp64 if necessary.

Thank you, I will fix this. In fact, it should be tested for all
targets which currently support custom function descriptors.

> 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 what it 
> doesn't work for) anyway.  I'd expect it to be a target-independent 
> feature with a target-independent test or tests.

My understanding is that this is a target-independent feature which
has not yet been implemented for all targets. The existing
documentation does not reflect this.


> Once there is sufficient user-level documentation showing what the 
> intended semantics are, then it may be possible to evaluate how the 
> implementation achieves that.

Please refer to the existing documentation of -ftrampolines and
-fno-trampolines.

My original submission also gives some background information:

https://gcc.gnu.org/ml/gcc-patches/2018-08/msg00705.html

The original generic functionality was introduced with
this patch:

https://patchwork.ozlabs.org/patch/642247/


Best,
Martin

  reply	other threads:[~2018-08-21  6:17 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-11 16:41 [RFC] [PATCH][C][ADA] " Uecker, Martin
2018-08-18 16:33 ` Uecker, Martin
2018-08-20 14:07   ` [PATCH v2][C][ADA] " Uecker, Martin
2018-08-20 22:35     ` Joseph Myers
2018-08-21  6:17       ` Uecker, Martin [this message]
2018-08-21 21:34         ` Joseph Myers
2018-08-22  6:09           ` Uecker, Martin
2018-08-22 15:49             ` Joseph Myers
2018-11-04 20:49               ` [PATCH v3][C][ADA] " Uecker, Martin
2018-12-03 10:29                 ` Uecker, Martin
2018-12-03 21:56                 ` Jeff Law
2018-12-12 18:12                   ` [PATCH v4][C][ADA] " Uecker, Martin
2018-12-13 23:35                     ` Jeff Law
2018-12-14 10:05                       ` Uecker, Martin
2018-12-14 23:36                         ` Jeff Law
2018-12-15  1:20                           ` Martin Sebor
2018-12-16 13:46                             ` Uecker, Martin
2018-12-16 16:13                               ` Jeff Law
2018-12-16 22:46                                 ` Uecker, Martin
2018-12-17 15:26                                   ` Szabolcs Nagy
2018-12-17 18:22                                     ` Uecker, Martin
2018-12-17 19:24                                       ` Szabolcs Nagy
2018-12-18 15:23                                         ` Paul Koning
2018-12-18 15:32                                           ` Jakub Jelinek
2018-12-18 16:03                                             ` Jeff Law
2018-12-18 16:25                                               ` Jakub Jelinek
2018-12-18 16:29                                                 ` Uecker, Martin
2018-12-18 16:33                                                   ` Uecker, Martin
2018-12-18 16:42                                                     ` Jakub Jelinek
2018-12-19 19:53                                                       ` Uecker, Martin
2018-12-19 20:08                                                         ` Jakub Jelinek
2018-12-19 21:28                                                           ` Wilco Dijkstra
2018-12-21 21:41                                                     ` Hans-Peter Nilsson
2018-12-21 22:07                                                       ` Uecker, Martin
2018-12-20 13:29                                                   ` Wilco Dijkstra
2018-12-18 16:27                                               ` Uecker, Martin
2018-12-17 17:29                                   ` Jeff Law
2018-12-17 18:07                                     ` Uecker, Martin
2018-12-17 18:41                                       ` Andreas Schwab
2018-12-21  8:03                                     ` [PATCH v5][C][ADA] " Uecker, Martin
2019-01-13 21:19                                       ` [PING] " Uecker, Martin
2019-01-14 20:16                                         ` Jeff Law
2019-06-24 21:35                                     ` [PATCH v6][C][ADA] " Uecker, Martin
2019-08-09 23:42                                       ` Jeff Law
2019-08-10 10:16                                         ` Uecker, Martin
2018-12-19 19:11                                 ` [PATCH v4][C][ADA] " Uecker, Martin
2018-12-17 17:31                               ` Martin Sebor
2018-12-17 18:09                                 ` Uecker, Martin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1534832264.15600.1.camel@med.uni-goettingen.de \
    --to=martin.uecker@med.uni-goettingen.de \
    --cc=ebotcazou@adacore.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=joseph@codesourcery.com \
    --cc=law@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).