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 >
