On 10/21/13 05:49, Ilya Enkovich wrote:
Hi,
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.
Thanks,
Ilya
--
gcc/
2013-10-04 Ilya Enkovich <ilya.enkov...@intel.com>
* builtin-types.def (BT_FN_VOID_CONST_PTR): New.
(BT_FN_PTR_CONST_PTR): New.
(BT_FN_CONST_PTR_CONST_PTR): New.
(BT_FN_PTR_CONST_PTR_SIZE): New.
(BT_FN_PTR_CONST_PTR_CONST_PTR): New.
(BT_FN_VOID_PTRPTR_CONST_PTR): New.
(BT_FN_VOID_CONST_PTR_SIZE): New.
(BT_FN_PTR_CONST_PTR_CONST_PTR_SIZE): New.
* chkp-builtins.def: New.
* builtins.def: include chkp-builtins.def.
(DEF_CHKP_BUILTIN): New.
* builtins.c (expand_builtin): Support BUILT_IN_CHKP_INIT_PTR_BOUNDS,
BUILT_IN_CHKP_NULL_PTR_BOUNDS, BUILT_IN_CHKP_COPY_PTR_BOUNDS,
BUILT_IN_CHKP_CHECK_PTR_LBOUNDS, BUILT_IN_CHKP_CHECK_PTR_UBOUNDS,
BUILT_IN_CHKP_CHECK_PTR_BOUNDS, BUILT_IN_CHKP_SET_PTR_BOUNDS,
BUILT_IN_CHKP_NARROW_PTR_BOUNDS, BUILT_IN_CHKP_STORE_PTR_BOUNDS,
BUILT_IN_CHKP_GET_PTR_LBOUND, BUILT_IN_CHKP_GET_PTR_UBOUND,
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,
BUILT_IN_CHKP_EXTRACT_LOWER, BUILT_IN_CHKP_EXTRACT_UPPER.
* common.opt (fcheck-pointers): New.
* toplev.c (process_options): Check Pointers Checker is supported.
* doc/extend.texi: Document Pointers Checker built-in functions.
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.
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.
Jeff
