Re: [PATCH, MPX, 2/X] Pointers Checker [8/25] Languages support

[Richard Biener]

On Tue, Nov 19, 2013 at 9:29 PM, Ilya Enkovich enkovich@gmail.com wrote:
 On 19 Nov 12:33, Jeff Law wrote:
 On 11/19/13 05:13, Ilya Enkovich wrote:
 On 19 Nov 13:00, Richard Biener wrote:
 I'd say not in the gimplifier either but in varpool (symbol table) code
 where the symbols are ultimatively registered with?
 
 Something like that?
 
 --- a/gcc/varpool.c
 +++ b/gcc/varpool.c
 @@ -151,6 +151,10 @@ varpool_node_for_decl (tree decl)
 node = varpool_create_empty_node ();
 node-decl = decl;
 symtab_register_node (node);
 +
 +  if (DECL_NIITIAL (decl))
 +chkp_register_var_initializer (decl);
 +
 return node;
   }
 Yea, I think that's what Richi is suggesting.
 jeff


 Great!  Here is a full version of the patch.  Bootstrap, make check and MPX 
 tests are OK with the change.

Please don't do this in varpool_node_for_decl but in
varpool_finalize_decl.

Richard.

 Thanks,
 Ilya
 --
 2013-11-19  Ilya Enkovich  ilya.enkov...@intel.com

 * varpool.c: Include tree-chkp.h.
 (varpool_node_for_decl): Register statically
 initialized decls in Pointer Bounds Checker.


 diff --git a/gcc/varpool.c b/gcc/varpool.c
 index 471db82..8487b6e 100644
 --- a/gcc/varpool.c
 +++ b/gcc/varpool.c
 @@ -34,6 +34,7 @@ along with GCC; see the file COPYING3.  If not see
  #include output.h
  #include gimple.h
  #include flags.h
 +#include tree-chkp.h

  /* List of hooks triggered on varpool_node events.  */
  struct varpool_node_hook_list {
 @@ -151,6 +152,10 @@ varpool_node_for_decl (tree decl)
node = varpool_create_empty_node ();
node-decl = decl;
symtab_register_node (node);
 +
 +  if (DECL_INITIAL (decl))
 +chkp_register_var_initializer (decl);
 +
return node;
  }

Re: [PATCH, MPX, 2/X] Pointers Checker [8/25] Languages support

[Ilya Enkovich]

On 20 Nov 10:59, Richard Biener wrote:
 On Tue, Nov 19, 2013 at 9:29 PM, Ilya Enkovich enkovich@gmail.com wrote:
  On 19 Nov 12:33, Jeff Law wrote:
  On 11/19/13 05:13, Ilya Enkovich wrote:
  On 19 Nov 13:00, Richard Biener wrote:
  I'd say not in the gimplifier either but in varpool (symbol table) code
  where the symbols are ultimatively registered with?
  
  Something like that?
  
  --- a/gcc/varpool.c
  +++ b/gcc/varpool.c
  @@ -151,6 +151,10 @@ varpool_node_for_decl (tree decl)
  node = varpool_create_empty_node ();
  node-decl = decl;
  symtab_register_node (node);
  +
  +  if (DECL_NIITIAL (decl))
  +chkp_register_var_initializer (decl);
  +
  return node;
}
  Yea, I think that's what Richi is suggesting.
  jeff
 
 
  Great!  Here is a full version of the patch.  Bootstrap, make check and MPX 
  tests are OK with the change.
 
 Please don't do this in varpool_node_for_decl but in
 varpool_finalize_decl.
 
 Richard.
 

Here it is.

Thanks,
Ilya
--

gcc/

2013-11-20  Ilya Enkovich  ilya.enkov...@intel.com

* cgraphunit.c: Include tree-chkp.h.
(varpool_finalize_decl): Register statically
initialized decls in Pointer Bounds Checker.


diff --git a/gcc/cgraphunit.c b/gcc/cgraphunit.c
index 8ab274b..6b6ec55 100644
--- a/gcc/cgraphunit.c
+++ b/gcc/cgraphunit.c
@@ -201,6 +201,7 @@ along with GCC; see the file COPYING3.  If not see
 #include regset.h /* FIXME: For reg_obstack.  */
 #include context.h
 #include pass_manager.h
+#include tree-chkp.h
 
 /* Queue of cgraph nodes scheduled to be added into cgraph.  This is a
secondary queue used during optimization to accommodate passes that
@@ -830,6 +831,9 @@ varpool_finalize_decl (tree decl)
  finished.  */
   if (cgraph_state == CGRAPH_STATE_FINISHED)
 varpool_assemble_decl (node);
+
+  if (DECL_INITIAL (decl))
+chkp_register_var_initializer (decl);
 }
 
 /* EDGE is an polymorphic call.  Mark all possible targets as reachable

Re: [PATCH, MPX, 2/X] Pointers Checker [8/25] Languages support

[Jeff Law]

On 11/20/13 06:49, Ilya Enkovich wrote:

On 20 Nov 10:59, Richard Biener wrote:

On Tue, Nov 19, 2013 at 9:29 PM, Ilya Enkovich enkovich@gmail.com wrote:

On 19 Nov 12:33, Jeff Law wrote:

On 11/19/13 05:13, Ilya Enkovich wrote:

On 19 Nov 13:00, Richard Biener wrote:

I'd say not in the gimplifier either but in varpool (symbol table) code
where the symbols are ultimatively registered with?


Something like that?

--- a/gcc/varpool.c
+++ b/gcc/varpool.c
@@ -151,6 +151,10 @@ varpool_node_for_decl (tree decl)
node = varpool_create_empty_node ();
node-decl = decl;
symtab_register_node (node);
+
+  if (DECL_NIITIAL (decl))
+chkp_register_var_initializer (decl);
+
return node;
  }

Yea, I think that's what Richi is suggesting.
jeff



Great!  Here is a full version of the patch.  Bootstrap, make check and MPX 
tests are OK with the change.


Please don't do this in varpool_node_for_decl but in
varpool_finalize_decl.

Richard.



Here it is.

Thanks,
Ilya
--

gcc/

2013-11-20  Ilya Enkovich  ilya.enkov...@intel.com

* cgraphunit.c: Include tree-chkp.h.
(varpool_finalize_decl): Register statically
initialized decls in Pointer Bounds Checker.
This is fine.  Note Richi's request to postpone this feature means this 
can't go in until the next stage1.  However, at that time, the approved 
hunks can be updated for the trunk and go in.  Ideally we'll have all 
the hunks reviewed and ready to go before then -- though once the 
current stage1 closes, everyone will be much more focused on bugfixing.


jeff

Re: [PATCH, MPX, 2/X] Pointers Checker [8/25] Languages support

[Richard Biener]

On Mon, Nov 18, 2013 at 5:45 PM, Jeff Law l...@redhat.com wrote:
 On 11/08/13 02:02, Ilya Enkovich wrote:

 Hi,

 Here is an updated patch version with no langhook.

 Regarding TLS objects issue - I do not think compiler should compensate
 the absence of instrumentation in libraries.  Compiler should be responsible
 for initialization of Bounds Tables for .tdata section.  Correct data copy
 is a responsibility of library.  User should use either instrumented library
 or wrapper calls if he needs this functionality.

 Thanks,
 Ilya
 --
 gcc/

 2013-11-06  Ilya Enkovich  ilya.enkov...@intel.com

 * c/c-parser.c: Include tree-chkp.h.
 (c_parser_declaration_or_fndef): Register statically
 initialized decls in Pointer Bounds Checker.
 * cp/decl.c: Include tree-chkp.h.
 (cp_finish_decl): Register statically
 initialized decls in Pointer Bounds Checker.
 * gimplify.c: Include tree-chkp.h.
 (gimplify_init_constructor): Register statically
 initialized decls in Pointer Bounds Checker.

 Is parsing really the right time to register these things with the checking
 framework?  Doesn't all this stuff flow through the gimplifier?  If so
 wouldn't that be a better place?

 If it can be done in the gimplifier, which seems good from the standpoint of
 simplifying the long term maintenance of the checking code.

 If there's a good reason to have this front-end, please explain it.

I'd say not in the gimplifier either but in varpool (symbol table) code
where the symbols are ultimatively registered with?

Richard.

 Thanks,
 Jeff

Re: [PATCH, MPX, 2/X] Pointers Checker [8/25] Languages support

[Ilya Enkovich]

On 19 Nov 13:00, Richard Biener wrote:
 On Mon, Nov 18, 2013 at 5:45 PM, Jeff Law l...@redhat.com wrote:
  On 11/08/13 02:02, Ilya Enkovich wrote:
 
  Hi,
 
  Here is an updated patch version with no langhook.
 
  Regarding TLS objects issue - I do not think compiler should compensate
  the absence of instrumentation in libraries.  Compiler should be 
  responsible
  for initialization of Bounds Tables for .tdata section.  Correct data copy
  is a responsibility of library.  User should use either instrumented 
  library
  or wrapper calls if he needs this functionality.
 
  Thanks,
  Ilya
  --
  gcc/
 
  2013-11-06  Ilya Enkovich  ilya.enkov...@intel.com
 
  * c/c-parser.c: Include tree-chkp.h.
  (c_parser_declaration_or_fndef): Register statically
  initialized decls in Pointer Bounds Checker.
  * cp/decl.c: Include tree-chkp.h.
  (cp_finish_decl): Register statically
  initialized decls in Pointer Bounds Checker.
  * gimplify.c: Include tree-chkp.h.
  (gimplify_init_constructor): Register statically
  initialized decls in Pointer Bounds Checker.
 
  Is parsing really the right time to register these things with the checking
  framework?  Doesn't all this stuff flow through the gimplifier?  If so
  wouldn't that be a better place?
 
  If it can be done in the gimplifier, which seems good from the standpoint of
  simplifying the long term maintenance of the checking code.
 
  If there's a good reason to have this front-end, please explain it.
 
 I'd say not in the gimplifier either but in varpool (symbol table) code
 where the symbols are ultimatively registered with?

Something like that?

--- a/gcc/varpool.c
+++ b/gcc/varpool.c
@@ -151,6 +151,10 @@ varpool_node_for_decl (tree decl)
   node = varpool_create_empty_node ();
   node-decl = decl;
   symtab_register_node (node);
+
+  if (DECL_NIITIAL (decl))
+chkp_register_var_initializer (decl);
+
   return node;
 }

Thanks,
Ilya

 
 Richard.
 
  Thanks,
  Jeff
 

Re: [PATCH, MPX, 2/X] Pointers Checker [8/25] Languages support

[Jeff Law]

On 11/19/13 05:00, Richard Biener wrote:

On Mon, Nov 18, 2013 at 5:45 PM, Jeff Law l...@redhat.com wrote:

On 11/08/13 02:02, Ilya Enkovich wrote:


Hi,

Here is an updated patch version with no langhook.

Regarding TLS objects issue - I do not think compiler should compensate
the absence of instrumentation in libraries.  Compiler should be responsible
for initialization of Bounds Tables for .tdata section.  Correct data copy
is a responsibility of library.  User should use either instrumented library
or wrapper calls if he needs this functionality.

Thanks,
Ilya
--
gcc/

2013-11-06  Ilya Enkovich  ilya.enkov...@intel.com

 * c/c-parser.c: Include tree-chkp.h.
 (c_parser_declaration_or_fndef): Register statically
 initialized decls in Pointer Bounds Checker.
 * cp/decl.c: Include tree-chkp.h.
 (cp_finish_decl): Register statically
 initialized decls in Pointer Bounds Checker.
 * gimplify.c: Include tree-chkp.h.
 (gimplify_init_constructor): Register statically
 initialized decls in Pointer Bounds Checker.


Is parsing really the right time to register these things with the checking
framework?  Doesn't all this stuff flow through the gimplifier?  If so
wouldn't that be a better place?

If it can be done in the gimplifier, which seems good from the standpoint of
simplifying the long term maintenance of the checking code.

If there's a good reason to have this front-end, please explain it.


I'd say not in the gimplifier either but in varpool (symbol table) code
where the symbols are ultimatively registered with?

That'd work for me.

jeff

Re: [PATCH, MPX, 2/X] Pointers Checker [8/25] Languages support

[Jeff Law]

On 11/19/13 05:13, Ilya Enkovich wrote:

On 19 Nov 13:00, Richard Biener wrote:

On Mon, Nov 18, 2013 at 5:45 PM, Jeff Law l...@redhat.com wrote:

On 11/08/13 02:02, Ilya Enkovich wrote:


Hi,

Here is an updated patch version with no langhook.

Regarding TLS objects issue - I do not think compiler should compensate
the absence of instrumentation in libraries.  Compiler should be responsible
for initialization of Bounds Tables for .tdata section.  Correct data copy
is a responsibility of library.  User should use either instrumented library
or wrapper calls if he needs this functionality.

Thanks,
Ilya
--
gcc/

2013-11-06  Ilya Enkovich  ilya.enkov...@intel.com

 * c/c-parser.c: Include tree-chkp.h.
 (c_parser_declaration_or_fndef): Register statically
 initialized decls in Pointer Bounds Checker.
 * cp/decl.c: Include tree-chkp.h.
 (cp_finish_decl): Register statically
 initialized decls in Pointer Bounds Checker.
 * gimplify.c: Include tree-chkp.h.
 (gimplify_init_constructor): Register statically
 initialized decls in Pointer Bounds Checker.


Is parsing really the right time to register these things with the checking
framework?  Doesn't all this stuff flow through the gimplifier?  If so
wouldn't that be a better place?

If it can be done in the gimplifier, which seems good from the standpoint of
simplifying the long term maintenance of the checking code.

If there's a good reason to have this front-end, please explain it.


I'd say not in the gimplifier either but in varpool (symbol table) code
where the symbols are ultimatively registered with?


Something like that?

--- a/gcc/varpool.c
+++ b/gcc/varpool.c
@@ -151,6 +151,10 @@ varpool_node_for_decl (tree decl)
node = varpool_create_empty_node ();
node-decl = decl;
symtab_register_node (node);
+
+  if (DECL_NIITIAL (decl))
+chkp_register_var_initializer (decl);
+
return node;
  }

Yea, I think that's what Richi is suggesting.
jeff

Re: [PATCH, MPX, 2/X] Pointers Checker [8/25] Languages support

[Ilya Enkovich]

On 19 Nov 12:33, Jeff Law wrote:
 On 11/19/13 05:13, Ilya Enkovich wrote:
 On 19 Nov 13:00, Richard Biener wrote:
 I'd say not in the gimplifier either but in varpool (symbol table) code
 where the symbols are ultimatively registered with?
 
 Something like that?
 
 --- a/gcc/varpool.c
 +++ b/gcc/varpool.c
 @@ -151,6 +151,10 @@ varpool_node_for_decl (tree decl)
 node = varpool_create_empty_node ();
 node-decl = decl;
 symtab_register_node (node);
 +
 +  if (DECL_NIITIAL (decl))
 +chkp_register_var_initializer (decl);
 +
 return node;
   }
 Yea, I think that's what Richi is suggesting.
 jeff
 

Great!  Here is a full version of the patch.  Bootstrap, make check and MPX 
tests are OK with the change.

Thanks,
Ilya
--
2013-11-19  Ilya Enkovich  ilya.enkov...@intel.com

* varpool.c: Include tree-chkp.h.
(varpool_node_for_decl): Register statically
initialized decls in Pointer Bounds Checker.


diff --git a/gcc/varpool.c b/gcc/varpool.c
index 471db82..8487b6e 100644
--- a/gcc/varpool.c
+++ b/gcc/varpool.c
@@ -34,6 +34,7 @@ along with GCC; see the file COPYING3.  If not see
 #include output.h
 #include gimple.h
 #include flags.h
+#include tree-chkp.h
 
 /* List of hooks triggered on varpool_node events.  */
 struct varpool_node_hook_list {
@@ -151,6 +152,10 @@ varpool_node_for_decl (tree decl)
   node = varpool_create_empty_node ();
   node-decl = decl;
   symtab_register_node (node);
+
+  if (DECL_INITIAL (decl))
+chkp_register_var_initializer (decl);
+
   return node;
 }
 

Re: [PATCH, MPX, 2/X] Pointers Checker [8/25] Languages support

[Ilya Enkovich]

Ping

2013/11/8 Ilya Enkovich enkovich@gmail.com:
 Hi,

 Here is an updated patch version with no langhook.

 Regarding TLS objects issue - I do not think compiler should compensate the 
 absence of instrumentation in libraries.  Compiler should be responsible for 
 initialization of Bounds Tables for .tdata section.  Correct data copy is a 
 responsibility of library.  User should use either instrumented library or 
 wrapper calls if he needs this functionality.

 Thanks,
 Ilya
 --
 gcc/

 2013-11-06  Ilya Enkovich  ilya.enkov...@intel.com

 * c/c-parser.c: Include tree-chkp.h.
 (c_parser_declaration_or_fndef): Register statically
 initialized decls in Pointer Bounds Checker.
 * cp/decl.c: Include tree-chkp.h.
 (cp_finish_decl): Register statically
 initialized decls in Pointer Bounds Checker.
 * gimplify.c: Include tree-chkp.h.
 (gimplify_init_constructor): Register statically
 initialized decls in Pointer Bounds Checker.


 diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
 index 9ccae3b..397b323 100644
 --- a/gcc/c/c-parser.c
 +++ b/gcc/c/c-parser.c
 @@ -56,6 +56,7 @@ along with GCC; see the file COPYING3.  If not see
  #include cgraph.h
  #include plugin.h
  #include omp-low.h
 +#include tree-chkp.h


  /* Initialization routine for this file.  */
 @@ -1682,6 +1683,12 @@ c_parser_declaration_or_fndef (c_parser *parser, bool 
 fndef_ok,
   maybe_warn_string_init (TREE_TYPE (d), init);
   finish_decl (d, init_loc, init.value,
init.original_type, asm_name);
 +
 + /* Register all decls with initializers in Pointer
 +Bounds Checker to generate required static bounds
 +initializers.  */
 + if (DECL_INITIAL (d) != error_mark_node)
 +   chkp_register_var_initializer (d);
 }
 }
   else
 diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
 index 1e92f2a..74df02f 100644
 --- a/gcc/cp/decl.c
 +++ b/gcc/cp/decl.c
 @@ -53,6 +53,7 @@ along with GCC; see the file COPYING3.  If not see
  #include splay-tree.h
  #include plugin.h
  #include cgraph.h
 +#include tree-chkp.h

  /* Possible cases of bad specifiers type used by bad_specifiers. */
  enum bad_spec_place {
 @@ -6379,6 +6380,12 @@ cp_finish_decl (tree decl, tree init, bool 
 init_const_expr_p,
  the class specifier.  */
   if (!DECL_EXTERNAL (decl))
 var_definition_p = true;
 +
 + /* If var has initilizer then we need to register it in
 +Pointer Bounds Checker to generate static bounds initilizer
 +if required.  */
 + if (DECL_INITIAL (decl)  DECL_INITIAL (decl) != error_mark_node)
 +   chkp_register_var_initializer (decl);
 }
/* If the variable has an array type, lay out the type, even if
  there is no initializer.  It is valid to index through the
 diff --git a/gcc/gimplify.c b/gcc/gimplify.c
 index 4f52c27..7aaac15 100644
 --- a/gcc/gimplify.c
 +++ b/gcc/gimplify.c
 @@ -48,6 +48,7 @@ along with GCC; see the file COPYING3.  If not see
  #include vec.h
  #include omp-low.h
  #include gimple-low.h
 +#include tree-chkp.h

  #include langhooks-def.h /* FIXME: for lhd_set_decl_assembler_name */
  #include tree-pass.h /* FIXME: only for PROP_gimple_any */
 @@ -4111,6 +4112,11 @@ gimplify_init_constructor (tree *expr_p, gimple_seq 
 *pre_p, gimple_seq *post_p,

 walk_tree (ctor, force_labels_r, NULL, NULL);
 ctor = tree_output_constant_def (ctor);
 +
 +   /* We need to register created constant object to
 +  initialize bounds for pointers in it.  */
 +   chkp_register_var_initializer (ctor);
 +
 if (!useless_type_conversion_p (type, TREE_TYPE (ctor)))
   ctor = build1 (VIEW_CONVERT_EXPR, type, ctor);
 TREE_OPERAND (*expr_p, 1) = ctor;

Re: [PATCH, MPX, 2/X] Pointers Checker [8/25] Languages support

[Jeff Law]

On 11/08/13 02:02, Ilya Enkovich wrote:

Hi,

Here is an updated patch version with no langhook.

Regarding TLS objects issue - I do not think compiler should compensate the 
absence of instrumentation in libraries.  Compiler should be responsible for 
initialization of Bounds Tables for .tdata section.  Correct data copy is a 
responsibility of library.  User should use either instrumented library or 
wrapper calls if he needs this functionality.

Thanks,
Ilya
--
gcc/

2013-11-06  Ilya Enkovich  ilya.enkov...@intel.com

* c/c-parser.c: Include tree-chkp.h.
(c_parser_declaration_or_fndef): Register statically
initialized decls in Pointer Bounds Checker.
* cp/decl.c: Include tree-chkp.h.
(cp_finish_decl): Register statically
initialized decls in Pointer Bounds Checker.
* gimplify.c: Include tree-chkp.h.
(gimplify_init_constructor): Register statically
initialized decls in Pointer Bounds Checker.
Is parsing really the right time to register these things with the 
checking framework?  Doesn't all this stuff flow through the gimplifier? 
 If so wouldn't that be a better place?


If it can be done in the gimplifier, which seems good from the 
standpoint of simplifying the long term maintenance of the checking code.


If there's a good reason to have this front-end, please explain it.

Thanks,
Jeff

(g)fortran support for MPX (was: Re: [PATCH, MPX, 2/X] Pointers Checker [8/25] Languages support)

[Tobias Burnus]

Ilya Enkovich wrote:

The issue is that users do not get what expect. I do not want someone
having mixed codes get instrumentation for his Java/Fortran/Ada
functions which slows them down and does nothing useful. What is the
point to allow checks of pointer bounds for language with no pointers?


Talking about Fortran, I wonder which modifications are required to get 
it working. Can you give some pointers? I lost a bit track.


(For readers, who haven't followed: See
http://gcc.gnu.org/wiki/Intel_MPX_support_in_the_GCC_compiler )

In Fortran, often an array is described by an array descriptor, a struct 
which carries both the pointer address and the array bounds. Thus, that 
makes it simpler to check for bound violations at runtime (existing 
-fcheck=bounds). However, arrays can also be passed as in a way that 
only the address is known – in that case, one has the same issues as 
with C. One place where the issue occurs is interoperating with C, but 
also within Fortran it can occur. I think especially for 
interoperability with C (C++ with extern c, etc.), having the checks 
would be useful.


I have to admit that it is not completely clear to me when to best add 
MPX annotations with Fortran, but as it is explicitly controlled by a 
compile-time flag, there is no real reason for not using it.


Tobias

Re: (g)fortran support for MPX (was: Re: [PATCH, MPX, 2/X] Pointers Checker [8/25] Languages support)

[Ilya Enkovich]

2013/11/18 Tobias Burnus bur...@net-b.de:
 Ilya Enkovich wrote:

 The issue is that users do not get what expect. I do not want someone
 having mixed codes get instrumentation for his Java/Fortran/Ada
 functions which slows them down and does nothing useful. What is the
 point to allow checks of pointer bounds for language with no pointers?


 Talking about Fortran, I wonder which modifications are required to get it
 working. Can you give some pointers? I lost a bit track.

 (For readers, who haven't followed: See
 http://gcc.gnu.org/wiki/Intel_MPX_support_in_the_GCC_compiler )

 In Fortran, often an array is described by an array descriptor, a struct
 which carries both the pointer address and the array bounds. Thus, that
 makes it simpler to check for bound violations at runtime (existing
 -fcheck=bounds). However, arrays can also be passed as in a way that only
 the address is known – in that case, one has the same issues as with C. One
 place where the issue occurs is interoperating with C, but also within
 Fortran it can occur. I think especially for interoperability with C (C++
 with extern c, etc.), having the checks would be useful.

 I have to admit that it is not completely clear to me when to best add MPX
 annotations with Fortran, but as it is explicitly controlled by a
 compile-time flag, there is no real reason for not using it.

Unfortunately I have only basic Fortran knowledge and cannot fully
estimate what may be required for its enabling.  From stability point
of view there should not be significant problem. Instrumentation
itself should work OK, but most probably you would get more
instrumentation than you want.  E.g. if you have array bounds placed
near array pointer, you do not need to use expensive Bounds Tables. If
you want only some particular type of pointers to be instrumented then
you need to add such feature.  Also some language features may be
required (e.g. for C new attributes were added to mark arrays with
variable size and functions not requiring instrumentation).

Ilya


 Tobias

Re: [PATCH, MPX, 2/X] Pointers Checker [8/25] Languages support

[Ilya Enkovich]

Hi,

Here is an updated patch version with no langhook.

Regarding TLS objects issue - I do not think compiler should compensate the 
absence of instrumentation in libraries.  Compiler should be responsible for 
initialization of Bounds Tables for .tdata section.  Correct data copy is a 
responsibility of library.  User should use either instrumented library or 
wrapper calls if he needs this functionality.

Thanks,
Ilya
--
gcc/

2013-11-06  Ilya Enkovich  ilya.enkov...@intel.com

* c/c-parser.c: Include tree-chkp.h.
(c_parser_declaration_or_fndef): Register statically
initialized decls in Pointer Bounds Checker.
* cp/decl.c: Include tree-chkp.h.
(cp_finish_decl): Register statically
initialized decls in Pointer Bounds Checker.
* gimplify.c: Include tree-chkp.h.
(gimplify_init_constructor): Register statically
initialized decls in Pointer Bounds Checker.


diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
index 9ccae3b..397b323 100644
--- a/gcc/c/c-parser.c
+++ b/gcc/c/c-parser.c
@@ -56,6 +56,7 @@ along with GCC; see the file COPYING3.  If not see
 #include cgraph.h
 #include plugin.h
 #include omp-low.h
+#include tree-chkp.h
 
 
 /* Initialization routine for this file.  */
@@ -1682,6 +1683,12 @@ c_parser_declaration_or_fndef (c_parser *parser, bool 
fndef_ok,
  maybe_warn_string_init (TREE_TYPE (d), init);
  finish_decl (d, init_loc, init.value,
   init.original_type, asm_name);
+
+ /* Register all decls with initializers in Pointer
+Bounds Checker to generate required static bounds
+initializers.  */
+ if (DECL_INITIAL (d) != error_mark_node)
+   chkp_register_var_initializer (d);
}
}
  else
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 1e92f2a..74df02f 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -53,6 +53,7 @@ along with GCC; see the file COPYING3.  If not see
 #include splay-tree.h
 #include plugin.h
 #include cgraph.h
+#include tree-chkp.h
 
 /* Possible cases of bad specifiers type used by bad_specifiers. */
 enum bad_spec_place {
@@ -6379,6 +6380,12 @@ cp_finish_decl (tree decl, tree init, bool 
init_const_expr_p,
 the class specifier.  */
  if (!DECL_EXTERNAL (decl))
var_definition_p = true;
+
+ /* If var has initilizer then we need to register it in
+Pointer Bounds Checker to generate static bounds initilizer
+if required.  */
+ if (DECL_INITIAL (decl)  DECL_INITIAL (decl) != error_mark_node)
+   chkp_register_var_initializer (decl);
}
   /* If the variable has an array type, lay out the type, even if
 there is no initializer.  It is valid to index through the
diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index 4f52c27..7aaac15 100644
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -48,6 +48,7 @@ along with GCC; see the file COPYING3.  If not see
 #include vec.h
 #include omp-low.h
 #include gimple-low.h
+#include tree-chkp.h
 
 #include langhooks-def.h /* FIXME: for lhd_set_decl_assembler_name */
 #include tree-pass.h /* FIXME: only for PROP_gimple_any */
@@ -4111,6 +4112,11 @@ gimplify_init_constructor (tree *expr_p, gimple_seq 
*pre_p, gimple_seq *post_p,
 
walk_tree (ctor, force_labels_r, NULL, NULL);
ctor = tree_output_constant_def (ctor);
+
+   /* We need to register created constant object to
+  initialize bounds for pointers in it.  */
+   chkp_register_var_initializer (ctor);
+
if (!useless_type_conversion_p (type, TREE_TYPE (ctor)))
  ctor = build1 (VIEW_CONVERT_EXPR, type, ctor);
TREE_OPERAND (*expr_p, 1) = ctor;

Re: [PATCH, MPX, 2/X] Pointers Checker [8/25] Languages support

[Richard Biener]

On Tue, Nov 5, 2013 at 3:08 PM, Ilya Enkovich enkovich@gmail.com wrote:
 2013/11/5 Richard Biener richard.guent...@gmail.com:
 On Tue, Nov 5, 2013 at 2:37 PM, Ilya Enkovich enkovich@gmail.com wrote:
 2013/11/5 Richard Biener richard.guent...@gmail.com:
 On Tue, Nov 5, 2013 at 2:20 PM, Ilya Enkovich enkovich@gmail.com 
 wrote:
 2013/11/5 Richard Biener richard.guent...@gmail.com:
 On Tue, Nov 5, 2013 at 2:02 PM, Ilya Enkovich enkovich@gmail.com 
 wrote:
 2013/11/4 Richard Biener richard.guent...@gmail.com:
 On Thu, Oct 31, 2013 at 10:11 AM, Ilya Enkovich 
 enkovich@gmail.com wrote:
 Hi,

 This patch adds support Pointer Bounds Checker into c-family and LTO 
 front-ends.  The main purpose of changes in front-end is to register 
 all statically initialized objects for checker.  We also need to 
 register such objects created by compiler.

 LTO is quite specific front-end.  For LTO Pointer Bounds Checker
 support macro just means it allows instrumented code as input because
 all instrumentation is performed before code is streamed out for LTO.

 But your patch doesn't even make use of the langhook...

 Use of langhook is in previous patch
 (http://gcc.gnu.org/ml/gcc-patches/2013-10/msg02408.html). Here is
 it's part:

 diff --git a/gcc/toplev.c b/gcc/toplev.c
 index db269b7..0eaf081 100644
 --- a/gcc/toplev.c
 +++ b/gcc/toplev.c
 @@ -1282,6 +1282,15 @@ process_options (void)
and -ftree-loop-linear));
  #endif

 +  if (flag_check_pointer_bounds)
 +{
 +  if (targetm.chkp_bound_mode () == VOIDmode)
 +   error (-fcheck-pointers is not supported for this target);
 +
 +  if (!lang_hooks.chkp_supported)
 +   flag_check_pointer_bounds = 0;
 +}
 +
/* One region RA really helps to decrease the code size.  */
if (flag_ira_region == IRA_REGION_AUTODETECT)
  flag_ira_region

 If we try to use -fcheck-pointers -flto for some unsupported language,
 code will not be instrumented.

 What's the reason to have unsupported languages?

 For some languages (e.g. Java) Pointer Bounds Checker does not make
 sense at all. Others may require additional support in front-end. The
 primary target is C family where solved problem is more critical.

 What does break if you enable it for Java or other unsupported
 languages?  That is, if LTO is able to handle a mixed Java and
 C binary then why can Java alone not handle it?

 In such case checker will produce useless overhead in Java code.
 Resulting code will probably report some bound violations because Java
 FE may generate code which seems wrong for Pointer Bounds Checker.

So it's only an issue that if you use it that it may trip over Java FE bugs?
Not a good reason to have a langhook - you can use the existing
post_options langhook for disallowing this?

Thanks,
Richard.

 Ilya


 Richard.

 Ilya

 Richard.

 Ilya


 Richard.

 Ilya


 You define CHKP as supported in LTO.  That means it has to be supported
 for all languages and thus you should drop the langhook.

 Richard.

 Thanks,
 Ilya
 --

 gcc/

 2013-10-29  Ilya Enkovich  ilya.enkov...@intel.com

 * c/c-lang.c (LANG_HOOKS_CHKP_SUPPORTED): New.
 * cp/cp-lang.c (LANG_HOOKS_CHKP_SUPPORTED): New.
 * objc/objc-lang.c (LANG_HOOKS_CHKP_SUPPORTED): New.
 * objcp/objcp-lang.c (LANG_HOOKS_CHKP_SUPPORTED): New.
 * lto/lto-lang.c (LANG_HOOKS_CHKP_SUPPORTED): New.
 * c/c-parser.c (c_parser_declaration_or_fndef): Register 
 statically
 initialized decls in Pointer Bounds Checker.
 * cp/decl.c (cp_finish_decl): Likewise.
 * gimplify.c (gimplify_init_constructor): Likewise.


 diff --git a/gcc/c/c-lang.c b/gcc/c/c-lang.c
 index 614c46d..a32bc6b 100644
 --- a/gcc/c/c-lang.c
 +++ b/gcc/c/c-lang.c
 @@ -43,6 +43,8 @@ enum c_language_kind c_language = clk_c;
  #define LANG_HOOKS_INIT c_objc_common_init
  #undef LANG_HOOKS_INIT_TS
  #define LANG_HOOKS_INIT_TS c_common_init_ts
 +#undef LANG_HOOKS_CHKP_SUPPORTED
 +#define LANG_HOOKS_CHKP_SUPPORTED true

  /* Each front end provides its own lang hook initializer.  */
  struct lang_hooks lang_hooks = LANG_HOOKS_INITIALIZER;
 diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
 index 9ccae3b..65d83c8 100644
 --- a/gcc/c/c-parser.c
 +++ b/gcc/c/c-parser.c
 @@ -1682,6 +1682,12 @@ c_parser_declaration_or_fndef (c_parser 
 *parser, bool fndef_ok,
   maybe_warn_string_init (TREE_TYPE (d), init);
   finish_decl (d, init_loc, init.value,
init.original_type, asm_name);
 +
 + /* Register all decls with initializers in Pointer
 +Bounds Checker to generate required static bounds
 +initializers.  */
 + if (DECL_INITIAL (d) != error_mark_node)
 +   chkp_register_var_initializer (d);
 }
 }
   else
 diff --git a/gcc/cp/cp-lang.c b/gcc/cp/cp-lang.c
 index a7fa8e4..6d138bd 100644
 --- 

Re: [PATCH, MPX, 2/X] Pointers Checker [8/25] Languages support

[Ilya Enkovich]

2013/11/6 Richard Biener richard.guent...@gmail.com:
 On Tue, Nov 5, 2013 at 3:08 PM, Ilya Enkovich enkovich@gmail.com wrote:
 2013/11/5 Richard Biener richard.guent...@gmail.com:
 On Tue, Nov 5, 2013 at 2:37 PM, Ilya Enkovich enkovich@gmail.com 
 wrote:
 2013/11/5 Richard Biener richard.guent...@gmail.com:
 On Tue, Nov 5, 2013 at 2:20 PM, Ilya Enkovich enkovich@gmail.com 
 wrote:
 2013/11/5 Richard Biener richard.guent...@gmail.com:
 On Tue, Nov 5, 2013 at 2:02 PM, Ilya Enkovich enkovich@gmail.com 
 wrote:
 2013/11/4 Richard Biener richard.guent...@gmail.com:
 On Thu, Oct 31, 2013 at 10:11 AM, Ilya Enkovich 
 enkovich@gmail.com wrote:
 Hi,

 This patch adds support Pointer Bounds Checker into c-family and LTO 
 front-ends.  The main purpose of changes in front-end is to register 
 all statically initialized objects for checker.  We also need to 
 register such objects created by compiler.

 LTO is quite specific front-end.  For LTO Pointer Bounds Checker
 support macro just means it allows instrumented code as input because
 all instrumentation is performed before code is streamed out for LTO.

 But your patch doesn't even make use of the langhook...

 Use of langhook is in previous patch
 (http://gcc.gnu.org/ml/gcc-patches/2013-10/msg02408.html). Here is
 it's part:

 diff --git a/gcc/toplev.c b/gcc/toplev.c
 index db269b7..0eaf081 100644
 --- a/gcc/toplev.c
 +++ b/gcc/toplev.c
 @@ -1282,6 +1282,15 @@ process_options (void)
and -ftree-loop-linear));
  #endif

 +  if (flag_check_pointer_bounds)
 +{
 +  if (targetm.chkp_bound_mode () == VOIDmode)
 +   error (-fcheck-pointers is not supported for this target);
 +
 +  if (!lang_hooks.chkp_supported)
 +   flag_check_pointer_bounds = 0;
 +}
 +
/* One region RA really helps to decrease the code size.  */
if (flag_ira_region == IRA_REGION_AUTODETECT)
  flag_ira_region

 If we try to use -fcheck-pointers -flto for some unsupported language,
 code will not be instrumented.

 What's the reason to have unsupported languages?

 For some languages (e.g. Java) Pointer Bounds Checker does not make
 sense at all. Others may require additional support in front-end. The
 primary target is C family where solved problem is more critical.

 What does break if you enable it for Java or other unsupported
 languages?  That is, if LTO is able to handle a mixed Java and
 C binary then why can Java alone not handle it?

 In such case checker will produce useless overhead in Java code.
 Resulting code will probably report some bound violations because Java
 FE may generate code which seems wrong for Pointer Bounds Checker.

 So it's only an issue that if you use it that it may trip over Java FE bugs?
 Not a good reason to have a langhook - you can use the existing
 post_options langhook for disallowing this?

The issue is that users do not get what expect. I do not want someone
having mixed codes get instrumentation for his Java/Fortran/Ada
functions which slows them down and does nothing useful. What is the
point to allow checks of pointer bounds for language with no pointers?

If I use post_options, I need to change hooks of languages that do not
care about checker to disable it. Now I have it disabled by default.
Using post_options will also require empty redefinition of
post_options in C languages with empty body which may be confusing.

If you do not like this hook, I can move all Pointer Bounds Checker
flags into c.opt and remove the hook. Should it be OK?

Thanks,
Ilya


 Thanks,
 Richard.

 Ilya


 Richard.

 Ilya

 Richard.

 Ilya


 Richard.

 Ilya


 You define CHKP as supported in LTO.  That means it has to be 
 supported
 for all languages and thus you should drop the langhook.

 Richard.

 Thanks,
 Ilya
 --

 gcc/

 2013-10-29  Ilya Enkovich  ilya.enkov...@intel.com

 * c/c-lang.c (LANG_HOOKS_CHKP_SUPPORTED): New.
 * cp/cp-lang.c (LANG_HOOKS_CHKP_SUPPORTED): New.
 * objc/objc-lang.c (LANG_HOOKS_CHKP_SUPPORTED): New.
 * objcp/objcp-lang.c (LANG_HOOKS_CHKP_SUPPORTED): New.
 * lto/lto-lang.c (LANG_HOOKS_CHKP_SUPPORTED): New.
 * c/c-parser.c (c_parser_declaration_or_fndef): Register 
 statically
 initialized decls in Pointer Bounds Checker.
 * cp/decl.c (cp_finish_decl): Likewise.
 * gimplify.c (gimplify_init_constructor): Likewise.


 diff --git a/gcc/c/c-lang.c b/gcc/c/c-lang.c
 index 614c46d..a32bc6b 100644
 --- a/gcc/c/c-lang.c
 +++ b/gcc/c/c-lang.c
 @@ -43,6 +43,8 @@ enum c_language_kind c_language = clk_c;
  #define LANG_HOOKS_INIT c_objc_common_init
  #undef LANG_HOOKS_INIT_TS
  #define LANG_HOOKS_INIT_TS c_common_init_ts
 +#undef LANG_HOOKS_CHKP_SUPPORTED
 +#define LANG_HOOKS_CHKP_SUPPORTED true

  /* Each front end provides its own lang hook initializer.  */
  struct lang_hooks lang_hooks = LANG_HOOKS_INITIALIZER;
 diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
 index 9ccae3b..65d83c8 100644
 --- a/gcc/c/c-parser.c
 +++ 

Re: [PATCH, MPX, 2/X] Pointers Checker [8/25] Languages support

[Richard Biener]

On Wed, Nov 6, 2013 at 11:55 AM, Ilya Enkovich enkovich@gmail.com wrote:
 2013/11/6 Richard Biener richard.guent...@gmail.com:
 On Tue, Nov 5, 2013 at 3:08 PM, Ilya Enkovich enkovich@gmail.com wrote:
 2013/11/5 Richard Biener richard.guent...@gmail.com:
 On Tue, Nov 5, 2013 at 2:37 PM, Ilya Enkovich enkovich@gmail.com 
 wrote:
 2013/11/5 Richard Biener richard.guent...@gmail.com:
 On Tue, Nov 5, 2013 at 2:20 PM, Ilya Enkovich enkovich@gmail.com 
 wrote:
 2013/11/5 Richard Biener richard.guent...@gmail.com:
 On Tue, Nov 5, 2013 at 2:02 PM, Ilya Enkovich enkovich@gmail.com 
 wrote:
 2013/11/4 Richard Biener richard.guent...@gmail.com:
 On Thu, Oct 31, 2013 at 10:11 AM, Ilya Enkovich 
 enkovich@gmail.com wrote:
 Hi,

 This patch adds support Pointer Bounds Checker into c-family and 
 LTO front-ends.  The main purpose of changes in front-end is to 
 register all statically initialized objects for checker.  We also 
 need to register such objects created by compiler.

 LTO is quite specific front-end.  For LTO Pointer Bounds Checker
 support macro just means it allows instrumented code as input because
 all instrumentation is performed before code is streamed out for LTO.

 But your patch doesn't even make use of the langhook...

 Use of langhook is in previous patch
 (http://gcc.gnu.org/ml/gcc-patches/2013-10/msg02408.html). Here is
 it's part:

 diff --git a/gcc/toplev.c b/gcc/toplev.c
 index db269b7..0eaf081 100644
 --- a/gcc/toplev.c
 +++ b/gcc/toplev.c
 @@ -1282,6 +1282,15 @@ process_options (void)
and -ftree-loop-linear));
  #endif

 +  if (flag_check_pointer_bounds)
 +{
 +  if (targetm.chkp_bound_mode () == VOIDmode)
 +   error (-fcheck-pointers is not supported for this target);
 +
 +  if (!lang_hooks.chkp_supported)
 +   flag_check_pointer_bounds = 0;
 +}
 +
/* One region RA really helps to decrease the code size.  */
if (flag_ira_region == IRA_REGION_AUTODETECT)
  flag_ira_region

 If we try to use -fcheck-pointers -flto for some unsupported language,
 code will not be instrumented.

 What's the reason to have unsupported languages?

 For some languages (e.g. Java) Pointer Bounds Checker does not make
 sense at all. Others may require additional support in front-end. The
 primary target is C family where solved problem is more critical.

 What does break if you enable it for Java or other unsupported
 languages?  That is, if LTO is able to handle a mixed Java and
 C binary then why can Java alone not handle it?

 In such case checker will produce useless overhead in Java code.
 Resulting code will probably report some bound violations because Java
 FE may generate code which seems wrong for Pointer Bounds Checker.

 So it's only an issue that if you use it that it may trip over Java FE bugs?
 Not a good reason to have a langhook - you can use the existing
 post_options langhook for disallowing this?

 The issue is that users do not get what expect. I do not want someone
 having mixed codes get instrumentation for his Java/Fortran/Ada
 functions which slows them down and does nothing useful. What is the
 point to allow checks of pointer bounds for language with no pointers?

 If I use post_options, I need to change hooks of languages that do not
 care about checker to disable it. Now I have it disabled by default.

No, you'd change the hooks to complain about the flag.

 Using post_options will also require empty redefinition of
 post_options in C languages with empty body which may be confusing.

 If you do not like this hook, I can move all Pointer Bounds Checker
 flags into c.opt and remove the hook. Should it be OK?

That works for me if for LTO it is enough to see the instrumented IL
to do the right thing, that is, no flag tests appear in middle-end code
[You can also simply add LTO to the list of supported languages of course,
still no flag checks hint at a proper design].

Richard.

 Thanks,
 Ilya


 Thanks,
 Richard.

 Ilya


 Richard.

 Ilya

 Richard.

 Ilya


 Richard.

 Ilya


 You define CHKP as supported in LTO.  That means it has to be 
 supported
 for all languages and thus you should drop the langhook.

 Richard.

 Thanks,
 Ilya
 --

 gcc/

 2013-10-29  Ilya Enkovich  ilya.enkov...@intel.com

 * c/c-lang.c (LANG_HOOKS_CHKP_SUPPORTED): New.
 * cp/cp-lang.c (LANG_HOOKS_CHKP_SUPPORTED): New.
 * objc/objc-lang.c (LANG_HOOKS_CHKP_SUPPORTED): New.
 * objcp/objcp-lang.c (LANG_HOOKS_CHKP_SUPPORTED): New.
 * lto/lto-lang.c (LANG_HOOKS_CHKP_SUPPORTED): New.
 * c/c-parser.c (c_parser_declaration_or_fndef): Register 
 statically
 initialized decls in Pointer Bounds Checker.
 * cp/decl.c (cp_finish_decl): Likewise.
 * gimplify.c (gimplify_init_constructor): Likewise.


 diff --git a/gcc/c/c-lang.c b/gcc/c/c-lang.c
 index 614c46d..a32bc6b 100644
 --- a/gcc/c/c-lang.c
 +++ b/gcc/c/c-lang.c
 @@ -43,6 +43,8 @@ enum c_language_kind c_language = clk_c;
  #define 

Re: [PATCH, MPX, 2/X] Pointers Checker [8/25] Languages support

[Ilya Enkovich]

2013/11/2 Joseph S. Myers jos...@codesourcery.com:
 On Thu, 31 Oct 2013, Ilya Enkovich wrote:

 This patch adds support Pointer Bounds Checker into c-family and LTO
 front-ends.  The main purpose of changes in front-end is to register all
 statically initialized objects for checker.  We also need to register
 such objects created by compiler.

 What happens with statically initialized TLS objects?  It would seem that
 you need something like how the C++ front end handles static constructors
 for C++11 thread-local objects, but I don't see anything obvious for that
 here.

This patch takes care of pointers initialized by linker.  TLS objects
are dynamically allocated for each thread and should have some
constructor to perform initialization.  And if there is such
constructors then it should be instrumented by Pointer Bounds Checker.
 Therefore it should not require additional changes in front-end,
right?

The only problem I now see for TLS objects is that in my constructors
initialize bounds for an actual TLS object, not for object in .tdata.
How can I refer to .tdata objects in GIMPLE to get correct bounds
initialization for .tdata section?

Thanks,
Ilya


 --
 Joseph S. Myers
 jos...@codesourcery.com

Re: [PATCH, MPX, 2/X] Pointers Checker [8/25] Languages support

[Ilya Enkovich]

2013/11/4 Richard Biener richard.guent...@gmail.com:
 On Thu, Oct 31, 2013 at 10:11 AM, Ilya Enkovich enkovich@gmail.com 
 wrote:
 Hi,

 This patch adds support Pointer Bounds Checker into c-family and LTO 
 front-ends.  The main purpose of changes in front-end is to register all 
 statically initialized objects for checker.  We also need to register such 
 objects created by compiler.

LTO is quite specific front-end.  For LTO Pointer Bounds Checker
support macro just means it allows instrumented code as input because
all instrumentation is performed before code is streamed out for LTO.

Ilya


 You define CHKP as supported in LTO.  That means it has to be supported
 for all languages and thus you should drop the langhook.

 Richard.

 Thanks,
 Ilya
 --

 gcc/

 2013-10-29  Ilya Enkovich  ilya.enkov...@intel.com

 * c/c-lang.c (LANG_HOOKS_CHKP_SUPPORTED): New.
 * cp/cp-lang.c (LANG_HOOKS_CHKP_SUPPORTED): New.
 * objc/objc-lang.c (LANG_HOOKS_CHKP_SUPPORTED): New.
 * objcp/objcp-lang.c (LANG_HOOKS_CHKP_SUPPORTED): New.
 * lto/lto-lang.c (LANG_HOOKS_CHKP_SUPPORTED): New.
 * c/c-parser.c (c_parser_declaration_or_fndef): Register statically
 initialized decls in Pointer Bounds Checker.
 * cp/decl.c (cp_finish_decl): Likewise.
 * gimplify.c (gimplify_init_constructor): Likewise.


 diff --git a/gcc/c/c-lang.c b/gcc/c/c-lang.c
 index 614c46d..a32bc6b 100644
 --- a/gcc/c/c-lang.c
 +++ b/gcc/c/c-lang.c
 @@ -43,6 +43,8 @@ enum c_language_kind c_language = clk_c;
  #define LANG_HOOKS_INIT c_objc_common_init
  #undef LANG_HOOKS_INIT_TS
  #define LANG_HOOKS_INIT_TS c_common_init_ts
 +#undef LANG_HOOKS_CHKP_SUPPORTED
 +#define LANG_HOOKS_CHKP_SUPPORTED true

  /* Each front end provides its own lang hook initializer.  */
  struct lang_hooks lang_hooks = LANG_HOOKS_INITIALIZER;
 diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
 index 9ccae3b..65d83c8 100644
 --- a/gcc/c/c-parser.c
 +++ b/gcc/c/c-parser.c
 @@ -1682,6 +1682,12 @@ c_parser_declaration_or_fndef (c_parser *parser, bool 
 fndef_ok,
   maybe_warn_string_init (TREE_TYPE (d), init);
   finish_decl (d, init_loc, init.value,
init.original_type, asm_name);
 +
 + /* Register all decls with initializers in Pointer
 +Bounds Checker to generate required static bounds
 +initializers.  */
 + if (DECL_INITIAL (d) != error_mark_node)
 +   chkp_register_var_initializer (d);
 }
 }
   else
 diff --git a/gcc/cp/cp-lang.c b/gcc/cp/cp-lang.c
 index a7fa8e4..6d138bd 100644
 --- a/gcc/cp/cp-lang.c
 +++ b/gcc/cp/cp-lang.c
 @@ -81,6 +81,8 @@ static tree get_template_argument_pack_elems_folded 
 (const_tree);
  #define LANG_HOOKS_EH_PERSONALITY cp_eh_personality
  #undef LANG_HOOKS_EH_RUNTIME_TYPE
  #define LANG_HOOKS_EH_RUNTIME_TYPE build_eh_type_type
 +#undef LANG_HOOKS_CHKP_SUPPORTED
 +#define LANG_HOOKS_CHKP_SUPPORTED true

  /* Each front end provides its own lang hook initializer.  */
  struct lang_hooks lang_hooks = LANG_HOOKS_INITIALIZER;
 diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
 index 1e92f2a..db40e75 100644
 --- a/gcc/cp/decl.c
 +++ b/gcc/cp/decl.c
 @@ -6379,6 +6379,12 @@ cp_finish_decl (tree decl, tree init, bool 
 init_const_expr_p,
  the class specifier.  */
   if (!DECL_EXTERNAL (decl))
 var_definition_p = true;
 +
 + /* If var has initilizer then we need to register it in
 +Pointer Bounds Checker to generate static bounds initilizer
 +if required.  */
 + if (DECL_INITIAL (decl)  DECL_INITIAL (decl) != error_mark_node)
 +   chkp_register_var_initializer (decl);
 }
/* If the variable has an array type, lay out the type, even if
  there is no initializer.  It is valid to index through the
 diff --git a/gcc/gimplify.c b/gcc/gimplify.c
 index 4f52c27..503450f 100644
 --- a/gcc/gimplify.c
 +++ b/gcc/gimplify.c
 @@ -4111,6 +4111,11 @@ gimplify_init_constructor (tree *expr_p, gimple_seq 
 *pre_p, gimple_seq *post_p,

 walk_tree (ctor, force_labels_r, NULL, NULL);
 ctor = tree_output_constant_def (ctor);
 +
 +   /* We need to register created constant object to
 +  initialize bounds for pointers in it.  */
 +   chkp_register_var_initializer (ctor);
 +
 if (!useless_type_conversion_p (type, TREE_TYPE (ctor)))
   ctor = build1 (VIEW_CONVERT_EXPR, type, ctor);
 TREE_OPERAND (*expr_p, 1) = ctor;
 diff --git a/gcc/lto/lto-lang.c b/gcc/lto/lto-lang.c
 index 0fa0fc9..b6073d9 100644
 --- a/gcc/lto/lto-lang.c
 +++ b/gcc/lto/lto-lang.c
 @@ -1278,6 +1278,8 @@ static void lto_init_ts (void)

  #undef LANG_HOOKS_INIT_TS
  #define LANG_HOOKS_INIT_TS lto_init_ts
 +#undef LANG_HOOKS_CHKP_SUPPORTED
 +#define 

Re: [PATCH, MPX, 2/X] Pointers Checker [8/25] Languages support

[Jakub Jelinek]

On Tue, Nov 05, 2013 at 04:54:38PM +0400, Ilya Enkovich wrote:
 2013/11/2 Joseph S. Myers jos...@codesourcery.com:
  On Thu, 31 Oct 2013, Ilya Enkovich wrote:
 
  This patch adds support Pointer Bounds Checker into c-family and LTO
  front-ends.  The main purpose of changes in front-end is to register all
  statically initialized objects for checker.  We also need to register
  such objects created by compiler.
 
  What happens with statically initialized TLS objects?  It would seem that
  you need something like how the C++ front end handles static constructors
  for C++11 thread-local objects, but I don't see anything obvious for that
  here.
 
 This patch takes care of pointers initialized by linker.  TLS objects
 are dynamically allocated for each thread and should have some
 constructor to perform initialization.  And if there is such
 constructors then it should be instrumented by Pointer Bounds Checker.
  Therefore it should not require additional changes in front-end,
 right?
 
 The only problem I now see for TLS objects is that in my constructors
 initialize bounds for an actual TLS object, not for object in .tdata.
 How can I refer to .tdata objects in GIMPLE to get correct bounds
 initialization for .tdata section?

You can't.  .tdata section is only used as data to copy to the TLS objects
when they are initialized (libc copies the whole .tdata section to the right
spot in the TLS are of each thread, followed by clearing the area
corresponding to .tbss section's size).  TLS objects can have dynamic
constructors (fairly recent change), but they don't have to, if they don't,
they are just initialized by the memcpy from .tdata section.

Jakub

Re: [PATCH, MPX, 2/X] Pointers Checker [8/25] Languages support

[Ilya Enkovich]

2013/11/5 Jakub Jelinek ja...@redhat.com:
 On Tue, Nov 05, 2013 at 04:54:38PM +0400, Ilya Enkovich wrote:
 2013/11/2 Joseph S. Myers jos...@codesourcery.com:
  On Thu, 31 Oct 2013, Ilya Enkovich wrote:
 
  This patch adds support Pointer Bounds Checker into c-family and LTO
  front-ends.  The main purpose of changes in front-end is to register all
  statically initialized objects for checker.  We also need to register
  such objects created by compiler.
 
  What happens with statically initialized TLS objects?  It would seem that
  you need something like how the C++ front end handles static constructors
  for C++11 thread-local objects, but I don't see anything obvious for that
  here.

 This patch takes care of pointers initialized by linker.  TLS objects
 are dynamically allocated for each thread and should have some
 constructor to perform initialization.  And if there is such
 constructors then it should be instrumented by Pointer Bounds Checker.
  Therefore it should not require additional changes in front-end,
 right?

 The only problem I now see for TLS objects is that in my constructors
 initialize bounds for an actual TLS object, not for object in .tdata.
 How can I refer to .tdata objects in GIMPLE to get correct bounds
 initialization for .tdata section?

 You can't.  .tdata section is only used as data to copy to the TLS objects
 when they are initialized (libc copies the whole .tdata section to the right
 spot in the TLS are of each thread, followed by clearing the area
 corresponding to .tbss section's size).  TLS objects can have dynamic
 constructors (fairly recent change), but they don't have to, if they don't,
 they are just initialized by the memcpy from .tdata section.

It's sad I cannot just initialize bounds in Bounds Tables for .tdata,
memcpy would do all the job for me copying them for each new TLS
instance. The other way is to move all bounds initialization for TLS
objects into separate constructor.  How can I make such constructor?


 Jakub

Re: [PATCH, MPX, 2/X] Pointers Checker [8/25] Languages support

[Richard Biener]

On Tue, Nov 5, 2013 at 2:02 PM, Ilya Enkovich enkovich@gmail.com wrote:
 2013/11/4 Richard Biener richard.guent...@gmail.com:
 On Thu, Oct 31, 2013 at 10:11 AM, Ilya Enkovich enkovich@gmail.com 
 wrote:
 Hi,

 This patch adds support Pointer Bounds Checker into c-family and LTO 
 front-ends.  The main purpose of changes in front-end is to register all 
 statically initialized objects for checker.  We also need to register such 
 objects created by compiler.

 LTO is quite specific front-end.  For LTO Pointer Bounds Checker
 support macro just means it allows instrumented code as input because
 all instrumentation is performed before code is streamed out for LTO.

But your patch doesn't even make use of the langhook...

Richard.

 Ilya


 You define CHKP as supported in LTO.  That means it has to be supported
 for all languages and thus you should drop the langhook.

 Richard.

 Thanks,
 Ilya
 --

 gcc/

 2013-10-29  Ilya Enkovich  ilya.enkov...@intel.com

 * c/c-lang.c (LANG_HOOKS_CHKP_SUPPORTED): New.
 * cp/cp-lang.c (LANG_HOOKS_CHKP_SUPPORTED): New.
 * objc/objc-lang.c (LANG_HOOKS_CHKP_SUPPORTED): New.
 * objcp/objcp-lang.c (LANG_HOOKS_CHKP_SUPPORTED): New.
 * lto/lto-lang.c (LANG_HOOKS_CHKP_SUPPORTED): New.
 * c/c-parser.c (c_parser_declaration_or_fndef): Register statically
 initialized decls in Pointer Bounds Checker.
 * cp/decl.c (cp_finish_decl): Likewise.
 * gimplify.c (gimplify_init_constructor): Likewise.


 diff --git a/gcc/c/c-lang.c b/gcc/c/c-lang.c
 index 614c46d..a32bc6b 100644
 --- a/gcc/c/c-lang.c
 +++ b/gcc/c/c-lang.c
 @@ -43,6 +43,8 @@ enum c_language_kind c_language = clk_c;
  #define LANG_HOOKS_INIT c_objc_common_init
  #undef LANG_HOOKS_INIT_TS
  #define LANG_HOOKS_INIT_TS c_common_init_ts
 +#undef LANG_HOOKS_CHKP_SUPPORTED
 +#define LANG_HOOKS_CHKP_SUPPORTED true

  /* Each front end provides its own lang hook initializer.  */
  struct lang_hooks lang_hooks = LANG_HOOKS_INITIALIZER;
 diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
 index 9ccae3b..65d83c8 100644
 --- a/gcc/c/c-parser.c
 +++ b/gcc/c/c-parser.c
 @@ -1682,6 +1682,12 @@ c_parser_declaration_or_fndef (c_parser *parser, 
 bool fndef_ok,
   maybe_warn_string_init (TREE_TYPE (d), init);
   finish_decl (d, init_loc, init.value,
init.original_type, asm_name);
 +
 + /* Register all decls with initializers in Pointer
 +Bounds Checker to generate required static bounds
 +initializers.  */
 + if (DECL_INITIAL (d) != error_mark_node)
 +   chkp_register_var_initializer (d);
 }
 }
   else
 diff --git a/gcc/cp/cp-lang.c b/gcc/cp/cp-lang.c
 index a7fa8e4..6d138bd 100644
 --- a/gcc/cp/cp-lang.c
 +++ b/gcc/cp/cp-lang.c
 @@ -81,6 +81,8 @@ static tree get_template_argument_pack_elems_folded 
 (const_tree);
  #define LANG_HOOKS_EH_PERSONALITY cp_eh_personality
  #undef LANG_HOOKS_EH_RUNTIME_TYPE
  #define LANG_HOOKS_EH_RUNTIME_TYPE build_eh_type_type
 +#undef LANG_HOOKS_CHKP_SUPPORTED
 +#define LANG_HOOKS_CHKP_SUPPORTED true

  /* Each front end provides its own lang hook initializer.  */
  struct lang_hooks lang_hooks = LANG_HOOKS_INITIALIZER;
 diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
 index 1e92f2a..db40e75 100644
 --- a/gcc/cp/decl.c
 +++ b/gcc/cp/decl.c
 @@ -6379,6 +6379,12 @@ cp_finish_decl (tree decl, tree init, bool 
 init_const_expr_p,
  the class specifier.  */
   if (!DECL_EXTERNAL (decl))
 var_definition_p = true;
 +
 + /* If var has initilizer then we need to register it in
 +Pointer Bounds Checker to generate static bounds initilizer
 +if required.  */
 + if (DECL_INITIAL (decl)  DECL_INITIAL (decl) != error_mark_node)
 +   chkp_register_var_initializer (decl);
 }
/* If the variable has an array type, lay out the type, even if
  there is no initializer.  It is valid to index through the
 diff --git a/gcc/gimplify.c b/gcc/gimplify.c
 index 4f52c27..503450f 100644
 --- a/gcc/gimplify.c
 +++ b/gcc/gimplify.c
 @@ -4111,6 +4111,11 @@ gimplify_init_constructor (tree *expr_p, gimple_seq 
 *pre_p, gimple_seq *post_p,

 walk_tree (ctor, force_labels_r, NULL, NULL);
 ctor = tree_output_constant_def (ctor);
 +
 +   /* We need to register created constant object to
 +  initialize bounds for pointers in it.  */
 +   chkp_register_var_initializer (ctor);
 +
 if (!useless_type_conversion_p (type, TREE_TYPE (ctor)))
   ctor = build1 (VIEW_CONVERT_EXPR, type, ctor);
 TREE_OPERAND (*expr_p, 1) = ctor;
 diff --git a/gcc/lto/lto-lang.c b/gcc/lto/lto-lang.c
 index 0fa0fc9..b6073d9 100644
 --- a/gcc/lto/lto-lang.c
 +++ b/gcc/lto/lto-lang.c
 @@ -1278,6 +1278,8 @@ 

Re: [PATCH, MPX, 2/X] Pointers Checker [8/25] Languages support

[Jakub Jelinek]

On Tue, Nov 05, 2013 at 05:13:12PM +0400, Ilya Enkovich wrote:
 It's sad I cannot just initialize bounds in Bounds Tables for .tdata,
 memcpy would do all the job for me copying them for each new TLS

Why do you think so?  glibc will surely use an internal version of
memcpy rather than the global one, so unless glibc is MPX enabled, it would
not do the job.

 instance. The other way is to move all bounds initialization for TLS
 objects into separate constructor.  How can I make such constructor?

Just create a constructor for those, similarly how the C++ FE for __thread
vars with constructors (or OpenMP lowering for #pragma omp threadprivate
vars with constructors) expands them.

Jakub

Re: [PATCH, MPX, 2/X] Pointers Checker [8/25] Languages support

[Ilya Enkovich]

2013/11/5 Richard Biener richard.guent...@gmail.com:
 On Tue, Nov 5, 2013 at 2:02 PM, Ilya Enkovich enkovich@gmail.com wrote:
 2013/11/4 Richard Biener richard.guent...@gmail.com:
 On Thu, Oct 31, 2013 at 10:11 AM, Ilya Enkovich enkovich@gmail.com 
 wrote:
 Hi,

 This patch adds support Pointer Bounds Checker into c-family and LTO 
 front-ends.  The main purpose of changes in front-end is to register all 
 statically initialized objects for checker.  We also need to register such 
 objects created by compiler.

 LTO is quite specific front-end.  For LTO Pointer Bounds Checker
 support macro just means it allows instrumented code as input because
 all instrumentation is performed before code is streamed out for LTO.

 But your patch doesn't even make use of the langhook...

Use of langhook is in previous patch
(http://gcc.gnu.org/ml/gcc-patches/2013-10/msg02408.html). Here is
it's part:

diff --git a/gcc/toplev.c b/gcc/toplev.c
index db269b7..0eaf081 100644
--- a/gcc/toplev.c
+++ b/gcc/toplev.c
@@ -1282,6 +1282,15 @@ process_options (void)
   and -ftree-loop-linear));
 #endif

+  if (flag_check_pointer_bounds)
+{
+  if (targetm.chkp_bound_mode () == VOIDmode)
+   error (-fcheck-pointers is not supported for this target);
+
+  if (!lang_hooks.chkp_supported)
+   flag_check_pointer_bounds = 0;
+}
+
   /* One region RA really helps to decrease the code size.  */
   if (flag_ira_region == IRA_REGION_AUTODETECT)
 flag_ira_region

If we try to use -fcheck-pointers -flto for some unsupported language,
code will not be instrumented.

Ilya


 Richard.

 Ilya


 You define CHKP as supported in LTO.  That means it has to be supported
 for all languages and thus you should drop the langhook.

 Richard.

 Thanks,
 Ilya
 --

 gcc/

 2013-10-29  Ilya Enkovich  ilya.enkov...@intel.com

 * c/c-lang.c (LANG_HOOKS_CHKP_SUPPORTED): New.
 * cp/cp-lang.c (LANG_HOOKS_CHKP_SUPPORTED): New.
 * objc/objc-lang.c (LANG_HOOKS_CHKP_SUPPORTED): New.
 * objcp/objcp-lang.c (LANG_HOOKS_CHKP_SUPPORTED): New.
 * lto/lto-lang.c (LANG_HOOKS_CHKP_SUPPORTED): New.
 * c/c-parser.c (c_parser_declaration_or_fndef): Register statically
 initialized decls in Pointer Bounds Checker.
 * cp/decl.c (cp_finish_decl): Likewise.
 * gimplify.c (gimplify_init_constructor): Likewise.


 diff --git a/gcc/c/c-lang.c b/gcc/c/c-lang.c
 index 614c46d..a32bc6b 100644
 --- a/gcc/c/c-lang.c
 +++ b/gcc/c/c-lang.c
 @@ -43,6 +43,8 @@ enum c_language_kind c_language = clk_c;
  #define LANG_HOOKS_INIT c_objc_common_init
  #undef LANG_HOOKS_INIT_TS
  #define LANG_HOOKS_INIT_TS c_common_init_ts
 +#undef LANG_HOOKS_CHKP_SUPPORTED
 +#define LANG_HOOKS_CHKP_SUPPORTED true

  /* Each front end provides its own lang hook initializer.  */
  struct lang_hooks lang_hooks = LANG_HOOKS_INITIALIZER;
 diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
 index 9ccae3b..65d83c8 100644
 --- a/gcc/c/c-parser.c
 +++ b/gcc/c/c-parser.c
 @@ -1682,6 +1682,12 @@ c_parser_declaration_or_fndef (c_parser *parser, 
 bool fndef_ok,
   maybe_warn_string_init (TREE_TYPE (d), init);
   finish_decl (d, init_loc, init.value,
init.original_type, asm_name);
 +
 + /* Register all decls with initializers in Pointer
 +Bounds Checker to generate required static bounds
 +initializers.  */
 + if (DECL_INITIAL (d) != error_mark_node)
 +   chkp_register_var_initializer (d);
 }
 }
   else
 diff --git a/gcc/cp/cp-lang.c b/gcc/cp/cp-lang.c
 index a7fa8e4..6d138bd 100644
 --- a/gcc/cp/cp-lang.c
 +++ b/gcc/cp/cp-lang.c
 @@ -81,6 +81,8 @@ static tree get_template_argument_pack_elems_folded 
 (const_tree);
  #define LANG_HOOKS_EH_PERSONALITY cp_eh_personality
  #undef LANG_HOOKS_EH_RUNTIME_TYPE
  #define LANG_HOOKS_EH_RUNTIME_TYPE build_eh_type_type
 +#undef LANG_HOOKS_CHKP_SUPPORTED
 +#define LANG_HOOKS_CHKP_SUPPORTED true

  /* Each front end provides its own lang hook initializer.  */
  struct lang_hooks lang_hooks = LANG_HOOKS_INITIALIZER;
 diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
 index 1e92f2a..db40e75 100644
 --- a/gcc/cp/decl.c
 +++ b/gcc/cp/decl.c
 @@ -6379,6 +6379,12 @@ cp_finish_decl (tree decl, tree init, bool 
 init_const_expr_p,
  the class specifier.  */
   if (!DECL_EXTERNAL (decl))
 var_definition_p = true;
 +
 + /* If var has initilizer then we need to register it in
 +Pointer Bounds Checker to generate static bounds initilizer
 +if required.  */
 + if (DECL_INITIAL (decl)  DECL_INITIAL (decl) != 
 error_mark_node)
 +   chkp_register_var_initializer (decl);
 }
/* If the variable has an array type, lay out the type, even if
  there is no initializer.  It is valid to index through the
 diff --git 

Re: [PATCH, MPX, 2/X] Pointers Checker [8/25] Languages support

[Ilya Enkovich]

2013/11/5 Jakub Jelinek ja...@redhat.com:
 On Tue, Nov 05, 2013 at 05:13:12PM +0400, Ilya Enkovich wrote:
 It's sad I cannot just initialize bounds in Bounds Tables for .tdata,
 memcpy would do all the job for me copying them for each new TLS

 Why do you think so?  glibc will surely use an internal version of
 memcpy rather than the global one, so unless glibc is MPX enabled, it would
 not do the job.

 instance. The other way is to move all bounds initialization for TLS
 objects into separate constructor.  How can I make such constructor?

 Just create a constructor for those, similarly how the C++ FE for __thread
 vars with constructors (or OpenMP lowering for #pragma omp threadprivate
 vars with constructors) expands them.

Will look into it. Thanks!

Ilya

 Jakub

Re: [PATCH, MPX, 2/X] Pointers Checker [8/25] Languages support

[Richard Biener]

On Tue, Nov 5, 2013 at 2:20 PM, Ilya Enkovich enkovich@gmail.com wrote:
 2013/11/5 Richard Biener richard.guent...@gmail.com:
 On Tue, Nov 5, 2013 at 2:02 PM, Ilya Enkovich enkovich@gmail.com wrote:
 2013/11/4 Richard Biener richard.guent...@gmail.com:
 On Thu, Oct 31, 2013 at 10:11 AM, Ilya Enkovich enkovich@gmail.com 
 wrote:
 Hi,

 This patch adds support Pointer Bounds Checker into c-family and LTO 
 front-ends.  The main purpose of changes in front-end is to register all 
 statically initialized objects for checker.  We also need to register 
 such objects created by compiler.

 LTO is quite specific front-end.  For LTO Pointer Bounds Checker
 support macro just means it allows instrumented code as input because
 all instrumentation is performed before code is streamed out for LTO.

 But your patch doesn't even make use of the langhook...

 Use of langhook is in previous patch
 (http://gcc.gnu.org/ml/gcc-patches/2013-10/msg02408.html). Here is
 it's part:

 diff --git a/gcc/toplev.c b/gcc/toplev.c
 index db269b7..0eaf081 100644
 --- a/gcc/toplev.c
 +++ b/gcc/toplev.c
 @@ -1282,6 +1282,15 @@ process_options (void)
and -ftree-loop-linear));
  #endif

 +  if (flag_check_pointer_bounds)
 +{
 +  if (targetm.chkp_bound_mode () == VOIDmode)
 +   error (-fcheck-pointers is not supported for this target);
 +
 +  if (!lang_hooks.chkp_supported)
 +   flag_check_pointer_bounds = 0;
 +}
 +
/* One region RA really helps to decrease the code size.  */
if (flag_ira_region == IRA_REGION_AUTODETECT)
  flag_ira_region

 If we try to use -fcheck-pointers -flto for some unsupported language,
 code will not be instrumented.

What's the reason to have unsupported languages?

Richard.

 Ilya


 Richard.

 Ilya


 You define CHKP as supported in LTO.  That means it has to be supported
 for all languages and thus you should drop the langhook.

 Richard.

 Thanks,
 Ilya
 --

 gcc/

 2013-10-29  Ilya Enkovich  ilya.enkov...@intel.com

 * c/c-lang.c (LANG_HOOKS_CHKP_SUPPORTED): New.
 * cp/cp-lang.c (LANG_HOOKS_CHKP_SUPPORTED): New.
 * objc/objc-lang.c (LANG_HOOKS_CHKP_SUPPORTED): New.
 * objcp/objcp-lang.c (LANG_HOOKS_CHKP_SUPPORTED): New.
 * lto/lto-lang.c (LANG_HOOKS_CHKP_SUPPORTED): New.
 * c/c-parser.c (c_parser_declaration_or_fndef): Register 
 statically
 initialized decls in Pointer Bounds Checker.
 * cp/decl.c (cp_finish_decl): Likewise.
 * gimplify.c (gimplify_init_constructor): Likewise.


 diff --git a/gcc/c/c-lang.c b/gcc/c/c-lang.c
 index 614c46d..a32bc6b 100644
 --- a/gcc/c/c-lang.c
 +++ b/gcc/c/c-lang.c
 @@ -43,6 +43,8 @@ enum c_language_kind c_language = clk_c;
  #define LANG_HOOKS_INIT c_objc_common_init
  #undef LANG_HOOKS_INIT_TS
  #define LANG_HOOKS_INIT_TS c_common_init_ts
 +#undef LANG_HOOKS_CHKP_SUPPORTED
 +#define LANG_HOOKS_CHKP_SUPPORTED true

  /* Each front end provides its own lang hook initializer.  */
  struct lang_hooks lang_hooks = LANG_HOOKS_INITIALIZER;
 diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
 index 9ccae3b..65d83c8 100644
 --- a/gcc/c/c-parser.c
 +++ b/gcc/c/c-parser.c
 @@ -1682,6 +1682,12 @@ c_parser_declaration_or_fndef (c_parser *parser, 
 bool fndef_ok,
   maybe_warn_string_init (TREE_TYPE (d), init);
   finish_decl (d, init_loc, init.value,
init.original_type, asm_name);
 +
 + /* Register all decls with initializers in Pointer
 +Bounds Checker to generate required static bounds
 +initializers.  */
 + if (DECL_INITIAL (d) != error_mark_node)
 +   chkp_register_var_initializer (d);
 }
 }
   else
 diff --git a/gcc/cp/cp-lang.c b/gcc/cp/cp-lang.c
 index a7fa8e4..6d138bd 100644
 --- a/gcc/cp/cp-lang.c
 +++ b/gcc/cp/cp-lang.c
 @@ -81,6 +81,8 @@ static tree get_template_argument_pack_elems_folded 
 (const_tree);
  #define LANG_HOOKS_EH_PERSONALITY cp_eh_personality
  #undef LANG_HOOKS_EH_RUNTIME_TYPE
  #define LANG_HOOKS_EH_RUNTIME_TYPE build_eh_type_type
 +#undef LANG_HOOKS_CHKP_SUPPORTED
 +#define LANG_HOOKS_CHKP_SUPPORTED true

  /* Each front end provides its own lang hook initializer.  */
  struct lang_hooks lang_hooks = LANG_HOOKS_INITIALIZER;
 diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
 index 1e92f2a..db40e75 100644
 --- a/gcc/cp/decl.c
 +++ b/gcc/cp/decl.c
 @@ -6379,6 +6379,12 @@ cp_finish_decl (tree decl, tree init, bool 
 init_const_expr_p,
  the class specifier.  */
   if (!DECL_EXTERNAL (decl))
 var_definition_p = true;
 +
 + /* If var has initilizer then we need to register it in
 +Pointer Bounds Checker to generate static bounds initilizer
 +if required.  */
 + if (DECL_INITIAL (decl)  DECL_INITIAL (decl) != 
 error_mark_node)
 +   chkp_register_var_initializer (decl);
 }

Re: [PATCH, MPX, 2/X] Pointers Checker [8/25] Languages support

[Ilya Enkovich]

2013/11/5 Richard Biener richard.guent...@gmail.com:
 On Tue, Nov 5, 2013 at 2:20 PM, Ilya Enkovich enkovich@gmail.com wrote:
 2013/11/5 Richard Biener richard.guent...@gmail.com:
 On Tue, Nov 5, 2013 at 2:02 PM, Ilya Enkovich enkovich@gmail.com 
 wrote:
 2013/11/4 Richard Biener richard.guent...@gmail.com:
 On Thu, Oct 31, 2013 at 10:11 AM, Ilya Enkovich enkovich@gmail.com 
 wrote:
 Hi,

 This patch adds support Pointer Bounds Checker into c-family and LTO 
 front-ends.  The main purpose of changes in front-end is to register all 
 statically initialized objects for checker.  We also need to register 
 such objects created by compiler.

 LTO is quite specific front-end.  For LTO Pointer Bounds Checker
 support macro just means it allows instrumented code as input because
 all instrumentation is performed before code is streamed out for LTO.

 But your patch doesn't even make use of the langhook...

 Use of langhook is in previous patch
 (http://gcc.gnu.org/ml/gcc-patches/2013-10/msg02408.html). Here is
 it's part:

 diff --git a/gcc/toplev.c b/gcc/toplev.c
 index db269b7..0eaf081 100644
 --- a/gcc/toplev.c
 +++ b/gcc/toplev.c
 @@ -1282,6 +1282,15 @@ process_options (void)
and -ftree-loop-linear));
  #endif

 +  if (flag_check_pointer_bounds)
 +{
 +  if (targetm.chkp_bound_mode () == VOIDmode)
 +   error (-fcheck-pointers is not supported for this target);
 +
 +  if (!lang_hooks.chkp_supported)
 +   flag_check_pointer_bounds = 0;
 +}
 +
/* One region RA really helps to decrease the code size.  */
if (flag_ira_region == IRA_REGION_AUTODETECT)
  flag_ira_region

 If we try to use -fcheck-pointers -flto for some unsupported language,
 code will not be instrumented.

 What's the reason to have unsupported languages?

For some languages (e.g. Java) Pointer Bounds Checker does not make
sense at all. Others may require additional support in front-end. The
primary target is C family where solved problem is more critical.

Ilya

 Richard.

 Ilya


 Richard.

 Ilya


 You define CHKP as supported in LTO.  That means it has to be supported
 for all languages and thus you should drop the langhook.

 Richard.

 Thanks,
 Ilya
 --

 gcc/

 2013-10-29  Ilya Enkovich  ilya.enkov...@intel.com

 * c/c-lang.c (LANG_HOOKS_CHKP_SUPPORTED): New.
 * cp/cp-lang.c (LANG_HOOKS_CHKP_SUPPORTED): New.
 * objc/objc-lang.c (LANG_HOOKS_CHKP_SUPPORTED): New.
 * objcp/objcp-lang.c (LANG_HOOKS_CHKP_SUPPORTED): New.
 * lto/lto-lang.c (LANG_HOOKS_CHKP_SUPPORTED): New.
 * c/c-parser.c (c_parser_declaration_or_fndef): Register 
 statically
 initialized decls in Pointer Bounds Checker.
 * cp/decl.c (cp_finish_decl): Likewise.
 * gimplify.c (gimplify_init_constructor): Likewise.


 diff --git a/gcc/c/c-lang.c b/gcc/c/c-lang.c
 index 614c46d..a32bc6b 100644
 --- a/gcc/c/c-lang.c
 +++ b/gcc/c/c-lang.c
 @@ -43,6 +43,8 @@ enum c_language_kind c_language = clk_c;
  #define LANG_HOOKS_INIT c_objc_common_init
  #undef LANG_HOOKS_INIT_TS
  #define LANG_HOOKS_INIT_TS c_common_init_ts
 +#undef LANG_HOOKS_CHKP_SUPPORTED
 +#define LANG_HOOKS_CHKP_SUPPORTED true

  /* Each front end provides its own lang hook initializer.  */
  struct lang_hooks lang_hooks = LANG_HOOKS_INITIALIZER;
 diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
 index 9ccae3b..65d83c8 100644
 --- a/gcc/c/c-parser.c
 +++ b/gcc/c/c-parser.c
 @@ -1682,6 +1682,12 @@ c_parser_declaration_or_fndef (c_parser *parser, 
 bool fndef_ok,
   maybe_warn_string_init (TREE_TYPE (d), init);
   finish_decl (d, init_loc, init.value,
init.original_type, asm_name);
 +
 + /* Register all decls with initializers in Pointer
 +Bounds Checker to generate required static bounds
 +initializers.  */
 + if (DECL_INITIAL (d) != error_mark_node)
 +   chkp_register_var_initializer (d);
 }
 }
   else
 diff --git a/gcc/cp/cp-lang.c b/gcc/cp/cp-lang.c
 index a7fa8e4..6d138bd 100644
 --- a/gcc/cp/cp-lang.c
 +++ b/gcc/cp/cp-lang.c
 @@ -81,6 +81,8 @@ static tree get_template_argument_pack_elems_folded 
 (const_tree);
  #define LANG_HOOKS_EH_PERSONALITY cp_eh_personality
  #undef LANG_HOOKS_EH_RUNTIME_TYPE
  #define LANG_HOOKS_EH_RUNTIME_TYPE build_eh_type_type
 +#undef LANG_HOOKS_CHKP_SUPPORTED
 +#define LANG_HOOKS_CHKP_SUPPORTED true

  /* Each front end provides its own lang hook initializer.  */
  struct lang_hooks lang_hooks = LANG_HOOKS_INITIALIZER;
 diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
 index 1e92f2a..db40e75 100644
 --- a/gcc/cp/decl.c
 +++ b/gcc/cp/decl.c
 @@ -6379,6 +6379,12 @@ cp_finish_decl (tree decl, tree init, bool 
 init_const_expr_p,
  the class specifier.  */
   if (!DECL_EXTERNAL (decl))
 var_definition_p = true;
 +
 + /* If var has initilizer then 

Re: [PATCH, MPX, 2/X] Pointers Checker [8/25] Languages support

[Richard Biener]

On Tue, Nov 5, 2013 at 2:37 PM, Ilya Enkovich enkovich@gmail.com wrote:
 2013/11/5 Richard Biener richard.guent...@gmail.com:
 On Tue, Nov 5, 2013 at 2:20 PM, Ilya Enkovich enkovich@gmail.com wrote:
 2013/11/5 Richard Biener richard.guent...@gmail.com:
 On Tue, Nov 5, 2013 at 2:02 PM, Ilya Enkovich enkovich@gmail.com 
 wrote:
 2013/11/4 Richard Biener richard.guent...@gmail.com:
 On Thu, Oct 31, 2013 at 10:11 AM, Ilya Enkovich enkovich@gmail.com 
 wrote:
 Hi,

 This patch adds support Pointer Bounds Checker into c-family and LTO 
 front-ends.  The main purpose of changes in front-end is to register 
 all statically initialized objects for checker.  We also need to 
 register such objects created by compiler.

 LTO is quite specific front-end.  For LTO Pointer Bounds Checker
 support macro just means it allows instrumented code as input because
 all instrumentation is performed before code is streamed out for LTO.

 But your patch doesn't even make use of the langhook...

 Use of langhook is in previous patch
 (http://gcc.gnu.org/ml/gcc-patches/2013-10/msg02408.html). Here is
 it's part:

 diff --git a/gcc/toplev.c b/gcc/toplev.c
 index db269b7..0eaf081 100644
 --- a/gcc/toplev.c
 +++ b/gcc/toplev.c
 @@ -1282,6 +1282,15 @@ process_options (void)
and -ftree-loop-linear));
  #endif

 +  if (flag_check_pointer_bounds)
 +{
 +  if (targetm.chkp_bound_mode () == VOIDmode)
 +   error (-fcheck-pointers is not supported for this target);
 +
 +  if (!lang_hooks.chkp_supported)
 +   flag_check_pointer_bounds = 0;
 +}
 +
/* One region RA really helps to decrease the code size.  */
if (flag_ira_region == IRA_REGION_AUTODETECT)
  flag_ira_region

 If we try to use -fcheck-pointers -flto for some unsupported language,
 code will not be instrumented.

 What's the reason to have unsupported languages?

 For some languages (e.g. Java) Pointer Bounds Checker does not make
 sense at all. Others may require additional support in front-end. The
 primary target is C family where solved problem is more critical.

What does break if you enable it for Java or other unsupported
languages?  That is, if LTO is able to handle a mixed Java and
C binary then why can Java alone not handle it?

Richard.

 Ilya

 Richard.

 Ilya


 Richard.

 Ilya


 You define CHKP as supported in LTO.  That means it has to be supported
 for all languages and thus you should drop the langhook.

 Richard.

 Thanks,
 Ilya
 --

 gcc/

 2013-10-29  Ilya Enkovich  ilya.enkov...@intel.com

 * c/c-lang.c (LANG_HOOKS_CHKP_SUPPORTED): New.
 * cp/cp-lang.c (LANG_HOOKS_CHKP_SUPPORTED): New.
 * objc/objc-lang.c (LANG_HOOKS_CHKP_SUPPORTED): New.
 * objcp/objcp-lang.c (LANG_HOOKS_CHKP_SUPPORTED): New.
 * lto/lto-lang.c (LANG_HOOKS_CHKP_SUPPORTED): New.
 * c/c-parser.c (c_parser_declaration_or_fndef): Register 
 statically
 initialized decls in Pointer Bounds Checker.
 * cp/decl.c (cp_finish_decl): Likewise.
 * gimplify.c (gimplify_init_constructor): Likewise.


 diff --git a/gcc/c/c-lang.c b/gcc/c/c-lang.c
 index 614c46d..a32bc6b 100644
 --- a/gcc/c/c-lang.c
 +++ b/gcc/c/c-lang.c
 @@ -43,6 +43,8 @@ enum c_language_kind c_language = clk_c;
  #define LANG_HOOKS_INIT c_objc_common_init
  #undef LANG_HOOKS_INIT_TS
  #define LANG_HOOKS_INIT_TS c_common_init_ts
 +#undef LANG_HOOKS_CHKP_SUPPORTED
 +#define LANG_HOOKS_CHKP_SUPPORTED true

  /* Each front end provides its own lang hook initializer.  */
  struct lang_hooks lang_hooks = LANG_HOOKS_INITIALIZER;
 diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
 index 9ccae3b..65d83c8 100644
 --- a/gcc/c/c-parser.c
 +++ b/gcc/c/c-parser.c
 @@ -1682,6 +1682,12 @@ c_parser_declaration_or_fndef (c_parser *parser, 
 bool fndef_ok,
   maybe_warn_string_init (TREE_TYPE (d), init);
   finish_decl (d, init_loc, init.value,
init.original_type, asm_name);
 +
 + /* Register all decls with initializers in Pointer
 +Bounds Checker to generate required static bounds
 +initializers.  */
 + if (DECL_INITIAL (d) != error_mark_node)
 +   chkp_register_var_initializer (d);
 }
 }
   else
 diff --git a/gcc/cp/cp-lang.c b/gcc/cp/cp-lang.c
 index a7fa8e4..6d138bd 100644
 --- a/gcc/cp/cp-lang.c
 +++ b/gcc/cp/cp-lang.c
 @@ -81,6 +81,8 @@ static tree get_template_argument_pack_elems_folded 
 (const_tree);
  #define LANG_HOOKS_EH_PERSONALITY cp_eh_personality
  #undef LANG_HOOKS_EH_RUNTIME_TYPE
  #define LANG_HOOKS_EH_RUNTIME_TYPE build_eh_type_type
 +#undef LANG_HOOKS_CHKP_SUPPORTED
 +#define LANG_HOOKS_CHKP_SUPPORTED true

  /* Each front end provides its own lang hook initializer.  */
  struct lang_hooks lang_hooks = LANG_HOOKS_INITIALIZER;
 diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
 index 1e92f2a..db40e75 100644
 --- a/gcc/cp/decl.c
 

Re: [PATCH, MPX, 2/X] Pointers Checker [8/25] Languages support

[Ilya Enkovich]

2013/11/5 Richard Biener richard.guent...@gmail.com:
 On Tue, Nov 5, 2013 at 2:37 PM, Ilya Enkovich enkovich@gmail.com wrote:
 2013/11/5 Richard Biener richard.guent...@gmail.com:
 On Tue, Nov 5, 2013 at 2:20 PM, Ilya Enkovich enkovich@gmail.com 
 wrote:
 2013/11/5 Richard Biener richard.guent...@gmail.com:
 On Tue, Nov 5, 2013 at 2:02 PM, Ilya Enkovich enkovich@gmail.com 
 wrote:
 2013/11/4 Richard Biener richard.guent...@gmail.com:
 On Thu, Oct 31, 2013 at 10:11 AM, Ilya Enkovich 
 enkovich@gmail.com wrote:
 Hi,

 This patch adds support Pointer Bounds Checker into c-family and LTO 
 front-ends.  The main purpose of changes in front-end is to register 
 all statically initialized objects for checker.  We also need to 
 register such objects created by compiler.

 LTO is quite specific front-end.  For LTO Pointer Bounds Checker
 support macro just means it allows instrumented code as input because
 all instrumentation is performed before code is streamed out for LTO.

 But your patch doesn't even make use of the langhook...

 Use of langhook is in previous patch
 (http://gcc.gnu.org/ml/gcc-patches/2013-10/msg02408.html). Here is
 it's part:

 diff --git a/gcc/toplev.c b/gcc/toplev.c
 index db269b7..0eaf081 100644
 --- a/gcc/toplev.c
 +++ b/gcc/toplev.c
 @@ -1282,6 +1282,15 @@ process_options (void)
and -ftree-loop-linear));
  #endif

 +  if (flag_check_pointer_bounds)
 +{
 +  if (targetm.chkp_bound_mode () == VOIDmode)
 +   error (-fcheck-pointers is not supported for this target);
 +
 +  if (!lang_hooks.chkp_supported)
 +   flag_check_pointer_bounds = 0;
 +}
 +
/* One region RA really helps to decrease the code size.  */
if (flag_ira_region == IRA_REGION_AUTODETECT)
  flag_ira_region

 If we try to use -fcheck-pointers -flto for some unsupported language,
 code will not be instrumented.

 What's the reason to have unsupported languages?

 For some languages (e.g. Java) Pointer Bounds Checker does not make
 sense at all. Others may require additional support in front-end. The
 primary target is C family where solved problem is more critical.

 What does break if you enable it for Java or other unsupported
 languages?  That is, if LTO is able to handle a mixed Java and
 C binary then why can Java alone not handle it?

In such case checker will produce useless overhead in Java code.
Resulting code will probably report some bound violations because Java
FE may generate code which seems wrong for Pointer Bounds Checker.

Ilya


 Richard.

 Ilya

 Richard.

 Ilya


 Richard.

 Ilya


 You define CHKP as supported in LTO.  That means it has to be supported
 for all languages and thus you should drop the langhook.

 Richard.

 Thanks,
 Ilya
 --

 gcc/

 2013-10-29  Ilya Enkovich  ilya.enkov...@intel.com

 * c/c-lang.c (LANG_HOOKS_CHKP_SUPPORTED): New.
 * cp/cp-lang.c (LANG_HOOKS_CHKP_SUPPORTED): New.
 * objc/objc-lang.c (LANG_HOOKS_CHKP_SUPPORTED): New.
 * objcp/objcp-lang.c (LANG_HOOKS_CHKP_SUPPORTED): New.
 * lto/lto-lang.c (LANG_HOOKS_CHKP_SUPPORTED): New.
 * c/c-parser.c (c_parser_declaration_or_fndef): Register 
 statically
 initialized decls in Pointer Bounds Checker.
 * cp/decl.c (cp_finish_decl): Likewise.
 * gimplify.c (gimplify_init_constructor): Likewise.


 diff --git a/gcc/c/c-lang.c b/gcc/c/c-lang.c
 index 614c46d..a32bc6b 100644
 --- a/gcc/c/c-lang.c
 +++ b/gcc/c/c-lang.c
 @@ -43,6 +43,8 @@ enum c_language_kind c_language = clk_c;
  #define LANG_HOOKS_INIT c_objc_common_init
  #undef LANG_HOOKS_INIT_TS
  #define LANG_HOOKS_INIT_TS c_common_init_ts
 +#undef LANG_HOOKS_CHKP_SUPPORTED
 +#define LANG_HOOKS_CHKP_SUPPORTED true

  /* Each front end provides its own lang hook initializer.  */
  struct lang_hooks lang_hooks = LANG_HOOKS_INITIALIZER;
 diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
 index 9ccae3b..65d83c8 100644
 --- a/gcc/c/c-parser.c
 +++ b/gcc/c/c-parser.c
 @@ -1682,6 +1682,12 @@ c_parser_declaration_or_fndef (c_parser 
 *parser, bool fndef_ok,
   maybe_warn_string_init (TREE_TYPE (d), init);
   finish_decl (d, init_loc, init.value,
init.original_type, asm_name);
 +
 + /* Register all decls with initializers in Pointer
 +Bounds Checker to generate required static bounds
 +initializers.  */
 + if (DECL_INITIAL (d) != error_mark_node)
 +   chkp_register_var_initializer (d);
 }
 }
   else
 diff --git a/gcc/cp/cp-lang.c b/gcc/cp/cp-lang.c
 index a7fa8e4..6d138bd 100644
 --- a/gcc/cp/cp-lang.c
 +++ b/gcc/cp/cp-lang.c
 @@ -81,6 +81,8 @@ static tree get_template_argument_pack_elems_folded 
 (const_tree);
  #define LANG_HOOKS_EH_PERSONALITY cp_eh_personality
  #undef LANG_HOOKS_EH_RUNTIME_TYPE
  #define LANG_HOOKS_EH_RUNTIME_TYPE build_eh_type_type
 +#undef 

Re: [PATCH, MPX, 2/X] Pointers Checker [8/25] Languages support

[Richard Biener]

On Thu, Oct 31, 2013 at 10:11 AM, Ilya Enkovich enkovich@gmail.com wrote:
 Hi,

 This patch adds support Pointer Bounds Checker into c-family and LTO 
 front-ends.  The main purpose of changes in front-end is to register all 
 statically initialized objects for checker.  We also need to register such 
 objects created by compiler.

You define CHKP as supported in LTO.  That means it has to be supported
for all languages and thus you should drop the langhook.

Richard.

 Thanks,
 Ilya
 --

 gcc/

 2013-10-29  Ilya Enkovich  ilya.enkov...@intel.com

 * c/c-lang.c (LANG_HOOKS_CHKP_SUPPORTED): New.
 * cp/cp-lang.c (LANG_HOOKS_CHKP_SUPPORTED): New.
 * objc/objc-lang.c (LANG_HOOKS_CHKP_SUPPORTED): New.
 * objcp/objcp-lang.c (LANG_HOOKS_CHKP_SUPPORTED): New.
 * lto/lto-lang.c (LANG_HOOKS_CHKP_SUPPORTED): New.
 * c/c-parser.c (c_parser_declaration_or_fndef): Register statically
 initialized decls in Pointer Bounds Checker.
 * cp/decl.c (cp_finish_decl): Likewise.
 * gimplify.c (gimplify_init_constructor): Likewise.


 diff --git a/gcc/c/c-lang.c b/gcc/c/c-lang.c
 index 614c46d..a32bc6b 100644
 --- a/gcc/c/c-lang.c
 +++ b/gcc/c/c-lang.c
 @@ -43,6 +43,8 @@ enum c_language_kind c_language = clk_c;
  #define LANG_HOOKS_INIT c_objc_common_init
  #undef LANG_HOOKS_INIT_TS
  #define LANG_HOOKS_INIT_TS c_common_init_ts
 +#undef LANG_HOOKS_CHKP_SUPPORTED
 +#define LANG_HOOKS_CHKP_SUPPORTED true

  /* Each front end provides its own lang hook initializer.  */
  struct lang_hooks lang_hooks = LANG_HOOKS_INITIALIZER;
 diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
 index 9ccae3b..65d83c8 100644
 --- a/gcc/c/c-parser.c
 +++ b/gcc/c/c-parser.c
 @@ -1682,6 +1682,12 @@ c_parser_declaration_or_fndef (c_parser *parser, bool 
 fndef_ok,
   maybe_warn_string_init (TREE_TYPE (d), init);
   finish_decl (d, init_loc, init.value,
init.original_type, asm_name);
 +
 + /* Register all decls with initializers in Pointer
 +Bounds Checker to generate required static bounds
 +initializers.  */
 + if (DECL_INITIAL (d) != error_mark_node)
 +   chkp_register_var_initializer (d);
 }
 }
   else
 diff --git a/gcc/cp/cp-lang.c b/gcc/cp/cp-lang.c
 index a7fa8e4..6d138bd 100644
 --- a/gcc/cp/cp-lang.c
 +++ b/gcc/cp/cp-lang.c
 @@ -81,6 +81,8 @@ static tree get_template_argument_pack_elems_folded 
 (const_tree);
  #define LANG_HOOKS_EH_PERSONALITY cp_eh_personality
  #undef LANG_HOOKS_EH_RUNTIME_TYPE
  #define LANG_HOOKS_EH_RUNTIME_TYPE build_eh_type_type
 +#undef LANG_HOOKS_CHKP_SUPPORTED
 +#define LANG_HOOKS_CHKP_SUPPORTED true

  /* Each front end provides its own lang hook initializer.  */
  struct lang_hooks lang_hooks = LANG_HOOKS_INITIALIZER;
 diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
 index 1e92f2a..db40e75 100644
 --- a/gcc/cp/decl.c
 +++ b/gcc/cp/decl.c
 @@ -6379,6 +6379,12 @@ cp_finish_decl (tree decl, tree init, bool 
 init_const_expr_p,
  the class specifier.  */
   if (!DECL_EXTERNAL (decl))
 var_definition_p = true;
 +
 + /* If var has initilizer then we need to register it in
 +Pointer Bounds Checker to generate static bounds initilizer
 +if required.  */
 + if (DECL_INITIAL (decl)  DECL_INITIAL (decl) != error_mark_node)
 +   chkp_register_var_initializer (decl);
 }
/* If the variable has an array type, lay out the type, even if
  there is no initializer.  It is valid to index through the
 diff --git a/gcc/gimplify.c b/gcc/gimplify.c
 index 4f52c27..503450f 100644
 --- a/gcc/gimplify.c
 +++ b/gcc/gimplify.c
 @@ -4111,6 +4111,11 @@ gimplify_init_constructor (tree *expr_p, gimple_seq 
 *pre_p, gimple_seq *post_p,

 walk_tree (ctor, force_labels_r, NULL, NULL);
 ctor = tree_output_constant_def (ctor);
 +
 +   /* We need to register created constant object to
 +  initialize bounds for pointers in it.  */
 +   chkp_register_var_initializer (ctor);
 +
 if (!useless_type_conversion_p (type, TREE_TYPE (ctor)))
   ctor = build1 (VIEW_CONVERT_EXPR, type, ctor);
 TREE_OPERAND (*expr_p, 1) = ctor;
 diff --git a/gcc/lto/lto-lang.c b/gcc/lto/lto-lang.c
 index 0fa0fc9..b6073d9 100644
 --- a/gcc/lto/lto-lang.c
 +++ b/gcc/lto/lto-lang.c
 @@ -1278,6 +1278,8 @@ static void lto_init_ts (void)

  #undef LANG_HOOKS_INIT_TS
  #define LANG_HOOKS_INIT_TS lto_init_ts
 +#undef LANG_HOOKS_CHKP_SUPPORTED
 +#define LANG_HOOKS_CHKP_SUPPORTED true

  struct lang_hooks lang_hooks = LANG_HOOKS_INITIALIZER;

 diff --git a/gcc/objc/objc-lang.c b/gcc/objc/objc-lang.c
 index bc0008b..5e7e43b 100644
 --- a/gcc/objc/objc-lang.c
 +++ b/gcc/objc/objc-lang.c
 @@ -49,6 +49,8 @@ enum c_language_kind 

Re: [PATCH, MPX, 2/X] Pointers Checker [8/25] Languages support

[Joseph S. Myers]

On Thu, 31 Oct 2013, Ilya Enkovich wrote:

 This patch adds support Pointer Bounds Checker into c-family and LTO 
 front-ends.  The main purpose of changes in front-end is to register all 
 statically initialized objects for checker.  We also need to register 
 such objects created by compiler.

What happens with statically initialized TLS objects?  It would seem that 
you need something like how the C++ front end handles static constructors 
for C++11 thread-local objects, but I don't see anything obvious for that 
here.

-- 
Joseph S. Myers
jos...@codesourcery.com

[PATCH, MPX, 2/X] Pointers Checker [8/25] Languages support

[Ilya Enkovich]

Hi,

This patch adds support Pointer Bounds Checker into c-family and LTO 
front-ends.  The main purpose of changes in front-end is to register all 
statically initialized objects for checker.  We also need to register such 
objects created by compiler.

Thanks,
Ilya
--

gcc/

2013-10-29  Ilya Enkovich  ilya.enkov...@intel.com

* c/c-lang.c (LANG_HOOKS_CHKP_SUPPORTED): New.
* cp/cp-lang.c (LANG_HOOKS_CHKP_SUPPORTED): New.
* objc/objc-lang.c (LANG_HOOKS_CHKP_SUPPORTED): New.
* objcp/objcp-lang.c (LANG_HOOKS_CHKP_SUPPORTED): New.
* lto/lto-lang.c (LANG_HOOKS_CHKP_SUPPORTED): New.
* c/c-parser.c (c_parser_declaration_or_fndef): Register statically
initialized decls in Pointer Bounds Checker.
* cp/decl.c (cp_finish_decl): Likewise.
* gimplify.c (gimplify_init_constructor): Likewise.


diff --git a/gcc/c/c-lang.c b/gcc/c/c-lang.c
index 614c46d..a32bc6b 100644
--- a/gcc/c/c-lang.c
+++ b/gcc/c/c-lang.c
@@ -43,6 +43,8 @@ enum c_language_kind c_language = clk_c;
 #define LANG_HOOKS_INIT c_objc_common_init
 #undef LANG_HOOKS_INIT_TS
 #define LANG_HOOKS_INIT_TS c_common_init_ts
+#undef LANG_HOOKS_CHKP_SUPPORTED
+#define LANG_HOOKS_CHKP_SUPPORTED true
 
 /* Each front end provides its own lang hook initializer.  */
 struct lang_hooks lang_hooks = LANG_HOOKS_INITIALIZER;
diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
index 9ccae3b..65d83c8 100644
--- a/gcc/c/c-parser.c
+++ b/gcc/c/c-parser.c
@@ -1682,6 +1682,12 @@ c_parser_declaration_or_fndef (c_parser *parser, bool 
fndef_ok,
  maybe_warn_string_init (TREE_TYPE (d), init);
  finish_decl (d, init_loc, init.value,
   init.original_type, asm_name);
+
+ /* Register all decls with initializers in Pointer
+Bounds Checker to generate required static bounds
+initializers.  */
+ if (DECL_INITIAL (d) != error_mark_node)
+   chkp_register_var_initializer (d);
}
}
  else
diff --git a/gcc/cp/cp-lang.c b/gcc/cp/cp-lang.c
index a7fa8e4..6d138bd 100644
--- a/gcc/cp/cp-lang.c
+++ b/gcc/cp/cp-lang.c
@@ -81,6 +81,8 @@ static tree get_template_argument_pack_elems_folded 
(const_tree);
 #define LANG_HOOKS_EH_PERSONALITY cp_eh_personality
 #undef LANG_HOOKS_EH_RUNTIME_TYPE
 #define LANG_HOOKS_EH_RUNTIME_TYPE build_eh_type_type
+#undef LANG_HOOKS_CHKP_SUPPORTED
+#define LANG_HOOKS_CHKP_SUPPORTED true
 
 /* Each front end provides its own lang hook initializer.  */
 struct lang_hooks lang_hooks = LANG_HOOKS_INITIALIZER;
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 1e92f2a..db40e75 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -6379,6 +6379,12 @@ cp_finish_decl (tree decl, tree init, bool 
init_const_expr_p,
 the class specifier.  */
  if (!DECL_EXTERNAL (decl))
var_definition_p = true;
+
+ /* If var has initilizer then we need to register it in
+Pointer Bounds Checker to generate static bounds initilizer
+if required.  */
+ if (DECL_INITIAL (decl)  DECL_INITIAL (decl) != error_mark_node)
+   chkp_register_var_initializer (decl);
}
   /* If the variable has an array type, lay out the type, even if
 there is no initializer.  It is valid to index through the
diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index 4f52c27..503450f 100644
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -4111,6 +4111,11 @@ gimplify_init_constructor (tree *expr_p, gimple_seq 
*pre_p, gimple_seq *post_p,
 
walk_tree (ctor, force_labels_r, NULL, NULL);
ctor = tree_output_constant_def (ctor);
+
+   /* We need to register created constant object to
+  initialize bounds for pointers in it.  */
+   chkp_register_var_initializer (ctor);
+
if (!useless_type_conversion_p (type, TREE_TYPE (ctor)))
  ctor = build1 (VIEW_CONVERT_EXPR, type, ctor);
TREE_OPERAND (*expr_p, 1) = ctor;
diff --git a/gcc/lto/lto-lang.c b/gcc/lto/lto-lang.c
index 0fa0fc9..b6073d9 100644
--- a/gcc/lto/lto-lang.c
+++ b/gcc/lto/lto-lang.c
@@ -1278,6 +1278,8 @@ static void lto_init_ts (void)
 
 #undef LANG_HOOKS_INIT_TS
 #define LANG_HOOKS_INIT_TS lto_init_ts
+#undef LANG_HOOKS_CHKP_SUPPORTED
+#define LANG_HOOKS_CHKP_SUPPORTED true
 
 struct lang_hooks lang_hooks = LANG_HOOKS_INITIALIZER;
 
diff --git a/gcc/objc/objc-lang.c b/gcc/objc/objc-lang.c
index bc0008b..5e7e43b 100644
--- a/gcc/objc/objc-lang.c
+++ b/gcc/objc/objc-lang.c
@@ -49,6 +49,8 @@ enum c_language_kind c_language = clk_objc;
 #define LANG_HOOKS_GIMPLIFY_EXPR objc_gimplify_expr
 #undef LANG_HOOKS_INIT_TS
 #define LANG_HOOKS_INIT_TS objc_common_init_ts
+#undef LANG_HOOKS_CHKP_SUPPORTED
+#define LANG_HOOKS_CHKP_SUPPORTED true
 
 /* Each front end provides its own lang hook initializer.  */
 struct lang_hooks lang_hooks =