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 > > TARGET_CUSTOM_FUNCTION_DESCRIPTORS > > 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 feature. 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 supporting it). > 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 jos...@codesourcery.com
