This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH v4][C][ADA] use function descriptors instead of trampolines in C
- From: Martin Sebor <msebor at gmail dot com>
- To: Jeff Law <law at redhat dot com>, "Uecker, Martin" <Martin dot Uecker at med dot uni-goettingen dot de>, "joseph at codesourcery dot com" <joseph at codesourcery dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, "ebotcazou at adacore dot com" <ebotcazou at adacore dot com>
- Date: Fri, 14 Dec 2018 18:20:45 -0700
- Subject: Re: [PATCH v4][C][ADA] use function descriptors instead of trampolines in C
- References: <email@example.com> <firstname.lastname@example.org> <email@example.com> <alpine.DEB.firstname.lastname@example.org> <email@example.com> <alpine.DEB.firstname.lastname@example.org> <email@example.com> <alpine.DEB.firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org>
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 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
@@ -110,4 +110,7 @@ along with GCC; see the file COPYING3. If
#define LANG_HOOKS_TREE_INLINING_VAR_MOD_TYPE_P c_vla_unspec_p
+#define LANG_HOOKS_CUSTOM_FUNCTION_DESCRIPTORS true
#endif /* GCC_C_OBJC_COMMON */
I wonder if we even need the lang hook anymore. ISTM that a
that wants to use the function descriptors can just set
FUNC_ADDR_BY_DESCRIPTOR and we'd use the function descriptor,
use the trampoline. Thoughts?
The lang hook also affects the minimum alignment for function
pointers via the FUNCTION_ALIGNMENT macro (gcc/default.h). This
not appear to change the default alignment on any architecture, but
it causes a failure in i386/gcc.target/i386/attr-aligned.c when
requesting a smaller alignment which is then silently ignored.
Ugh. I didn't see that.
The test is new (2019-11-29 Martin Sebor), but one could
argue that we could simply remove this specific test as 'aligned'
is only required to increase alignment. Martin?
The test is meant to test that we do the right thing consistently. If
we're failing with your patch, then that needs to be addressed.
I haven't been paying attention here and so I don't know how the test
fails after the change. It's meant to verify that attribute aligned
successfully reduces the alignment of functions that have not been
previously declared with one all the way down to the supported minimum
(which is 1 on i386). I agree with Jeff that removing the test would
not be right unless the failure is due to some bad assumptions on my
part. If it's the built-in that fails that could be due to a bug in
it (it's very new).
I read your note as the test would fail if you dropped the
CUSTOM_FUNCTION_DESCRIPTORS macro, not that it was failing with your
I am not sure what the best approach is, but my preference
would be to remove the lang hook and the FUNCTION_ALIGNMENT
logic which will also fix the test case (the requested
alignment will be applied).
I would then instead add a warning (or error?) which triggers
only with -fno-trampolines if the user requests an alignment
which is too small for this mechanism to work.
Does this sound reasonable?
So I'm thinking we should wrap the existing patch as-is for the trunk
(we're well into stage3 after all). So leave the hook as-is for gcc-
We can then tackle removal of the hook, including twiddling
FUNCTION_ALIGNMENT for gcc-10.
Does that sound reasonable to you?
This is fine with me. So just confirm: I should install the
patch despite the regression?
We need to address the regression. Simply removing the test is probably
not the way to go.