This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available
- From: "ramana at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 22 Apr 2015 18:39:01 +0000
- Subject: [Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available
- Auto-submitted: auto-generated
- References: <bug-65837-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837
Ramana Radhakrishnan <ramana at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ramana at gcc dot gnu.org
--- Comment #2 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #1)
> Well,
>
> /* Return the ARM builtin for CODE. */
>
> tree
> arm_builtin_decl (unsigned code, bool initialize_p ATTRIBUTE_UNUSED)
> {
> if (code >= ARM_BUILTIN_MAX)
> return error_mark_node;
>
> return arm_builtin_decls[code];
> }
>
> and LTO passes in true for initialize_p ...
>
> Thus it looks like arm is simply missing LTO support for builtins
> (eventually a new symptom here because of the way we stream compiler
> options now, with target attributes)
Well, we defined TARGET_BUILTIN_DECL a few years back for precisely supporting
LTO streaming of builtins - can you elaborate further what target support is
missing and for quite a while this was working ?
What did we miss when adding that support ?