This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Move Asan instrumentation to sanopt pass
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: Yury Gribov <y dot gribov at samsung dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Konstantin Serebryany <kcc at gcc dot gnu dot org>, Dmitry Vyukov <dvyukov at google dot com>, Viacheslav Garbuzov <v dot garbuzov at samsung dot com>, Marek Polacek <polacek at redhat dot com>
- Date: Wed, 23 Jul 2014 22:09:35 +0200
- Subject: Re: [PATCH] Move Asan instrumentation to sanopt pass
- Authentication-results: sourceware.org; auth=none
- References: <53C922DE dot 6020000 at samsung dot com> <CAFiYyc3=eaf92H=H-wUv3OUx-62s7_Vup8h0TAbLe_gBmTQp_A at mail dot gmail dot com> <53CE720A dot 4030002 at samsung dot com> <CAFiYyc0Fv5jWCNwcZU=2MYHSqo0h=ZdsBvMas4rUhEPsNevmVg at mail dot gmail dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Tue, Jul 22, 2014 at 04:20:04PM +0200, Richard Biener wrote:
> On Tue, Jul 22, 2014 at 4:15 PM, Yury Gribov <email@example.com> wrote:
> > On 07/22/2014 05:57 PM, Richard Biener wrote:
> >>> I probably could
> >>> provide fnspec with (EAF_DIRECT | EAF_NOCLOBBER | EAF_NOESCAPE) or
> >>> even EAF_UNUSED for these functions but this does not seem
> >>> to be supported in current middle-end.
> >> Simply add the "fn spec" attribute to the functions?
> > Problem is that internal functions don't seem to support this
> > (gimple_statement_call::fntype and gimple_statement_call::internal_fn
> > occupy the same field). I wasn't sure about the reasons for this
> > so decided change them in original patch. Do you think we should we allow
> > fntype for internal functions?
> Ah.... internal fns. Those cannot have attributes indeed (technical
> Martin was working on putting those flags elsewhere (cgraph, though internal
> functions don't have cgraph nodes either ...). Maybe it was a bad idea to use
> internal functions for ASAN.
But if it is a builtin function, then users can use it directly, which is
not really desirable.
For internal-fn, we already support ECF* constants, guess either we could
add support for EAF* too, through internal-fn.def, or we need support for
normal builtins that are inaccessible to users (but using . or space
in names is too ugly IMHO for that).