This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH, MPX, 2/X] Pointers Checker [2/25] Builtins


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.enkovich@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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]