This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH v2][C][ADA] use function descriptors instead of trampolines in C
On Wed, 22 Aug 2018, Uecker, Martin wrote:
> Am Dienstag, den 21.08.2018, 21:34 +0000 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 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.
> > How does one tell which targets do or do not support it?
> There is a target hook
> But I am not sure how to get this information to the testsuite.
Presumably through defining a check_* function in target-supports.exp that
has a list of targets supporting the feature. Together with
cross-references in all the relevant places: the hook documentation in
target.def (and thus the generated file tm.texi) should say that the list
in target-supports.exp needs to be kept in sync if changing what targets
implement the hook, and the list in target-supports.exp should similarly
have a comment referencing the hook, and the user-level documentation in
invoke.texi should list the relevant architectures, again with comments
pointing in both directions between it and the other places needing
updating when a change is made to the set of architectures supporting the
Except: if the feature doesn't work on some targets, I'd expect an attempt
to use -fno-trampolines on other targets to produce a sorry () message
from the compiler, so it's immediately obvious to the user that the
requested semantics are not being achieved. And once you've got that
sorry (), it should be something the check_* function can reliably test
for (try compiling a trivial file with -fno-trampolines and see if it
works, via check_no_compiler_messages*), so you don't need the list of
targets in target-supports.exp in that case (but the documentation would
need to say something about the option giving an error on targets not
> there seems to be infrastructure to implement this. The information seems
> to come from a "target_info" structure (?) but I do not see where this
> is populated.
target_info comes from DejaGnu. Sometimes a board file may set variables
in target_info. But for anything that is an architecture property of GCC,
the board file should not need to set it; GCC should know the information
itself. The board file is more for describing board-specific information
(e.g. memory available).
Joseph S. Myers