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
