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

[Richard Biener <richard dot guenther at gmail dot com>]

On Mon, Nov 18, 2013 at 5:45 PM, Jeff Law <law@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.enkovich@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
>