This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH, MPX, 2/X] Pointers Checker [2/25] Builtins
- From: Jeff Law <law at redhat dot com>
- To: Ilya Enkovich <enkovich dot gnu at gmail dot com>, gcc-patches at gcc dot gnu dot org
- Date: Wed, 23 Oct 2013 15:41:02 -0600
- Subject: Re: [PATCH, MPX, 2/X] Pointers Checker [2/25] Builtins
- Authentication-results: sourceware.org; auth=none
- References: <20131021114918 dot GB37888 at msticlxl57 dot ims dot intel dot com>
On 10/21/13 05:49, Ilya Enkovich wrote:
Out of curiosity, did you consider and/or discuss with Richard whether
or not to make these target-dependent or target-independent builtins? I
realize it's a bit problematic with Richard being involved during the
NDA portion and someone else during the review/integration portion, but
that's unfortunately where we are.
This patch introduces built-in functions used by Pointers Checker and flag to enable Pointers Checker. Builtins available for user are expanded in expand_builtin. All other builtins are not allowed in expand until generic version of Pointers Cheker is implemented.
Bootstrapped and tested on linux-x86_64.
2013-10-04 Ilya Enkovich <email@example.com>
* builtin-types.def (BT_FN_VOID_CONST_PTR): New.
* chkp-builtins.def: New.
* builtins.def: include chkp-builtins.def.
* builtins.c (expand_builtin): Support BUILT_IN_CHKP_INIT_PTR_BOUNDS,
BUILT_IN_CHKP_BNDMK, BUILT_IN_CHKP_BNDSTX, BUILT_IN_CHKP_BNDCL,
BUILT_IN_CHKP_BNDCU, BUILT_IN_CHKP_BNDLDX, BUILT_IN_CHKP_BNDRET,
BUILT_IN_CHKP_INTERSECT, BUILT_IN_CHKP_ARG_BND, BUILT_IN_CHKP_NARROW,
* common.opt (fcheck-pointers): New.
* toplev.c (process_options): Check Pointers Checker is supported.
* doc/extend.texi: Document Pointers Checker built-in functions.
I don't think we've generally encouraged target-independent builtins
which are only implemented on one target, though I can see the
possibility that these may need enough support code in gimple and beyond
that they may need to be target-independent.
I also find myself wondering if mudflap can/should be reimplemented on
top of these hooks (or perhaps we should remove it, I'm not aware of
anyone using it in the real world).
Anyway, like with the first patch, I'm trying to get a sense of some
design decisions as they're important for the review process.