Message ID | 20100623101545.GA9710@kam.mff.cuni.cz |
---|---|
State | New |
Headers | show |
On Wed, 23 Jun 2010, Jan Hubicka wrote: > I am defnitly trying to push things towards making WHOPR the official way > to build GCC binary. Hopefully we will get there for next release. Is the expectation that WHOPR builds of GCC will require GCC 4.6 (when building a cross compiler, say)? The present GCC build system puts various objects in .a files. Does this mean that WHOPR build of GCC requires LTO support for .a files, and so needs the linker plugin at present and does not work with GNU ld (for non-ELF hosts not supported by gold, for example) unless new features are added to GNU ld to support it (I hope such features are added to GNU ld)?
On Wed, Jun 23, 2010 at 1:30 PM, Joseph S. Myers <joseph@codesourcery.com> wrote: > On Wed, 23 Jun 2010, Jan Hubicka wrote: > >> I am defnitly trying to push things towards making WHOPR the official way >> to build GCC binary. Hopefully we will get there for next release. > > Is the expectation that WHOPR builds of GCC will require GCC 4.6 (when > building a cross compiler, say)? If we don't want to bootstrap a compiler for the host first then yes. > The present GCC build system puts various objects in .a files. Does this > mean that WHOPR build of GCC requires LTO support for .a files, and so > needs the linker plugin at present and does not work with GNU ld (for > non-ELF hosts not supported by gold, for example) unless new features are > added to GNU ld to support it (I hope such features are added to GNU ld)? ISTR somebody was working on teaching GNU ld to emit a resolution file. See the patch from Dave Korn in PR41376. I don't know if that was proposed to the binutils list yet. Richard. > -- > Joseph S. Myers > joseph@codesourcery.com >
> On Wed, Jun 23, 2010 at 1:30 PM, Joseph S. Myers > <joseph@codesourcery.com> wrote: > > On Wed, 23 Jun 2010, Jan Hubicka wrote: > > > >> I am defnitly trying to push things towards making WHOPR the official way > >> to build GCC binary. Hopefully we will get there for next release. > > > > Is the expectation that WHOPR builds of GCC will require GCC 4.6 (when > > building a cross compiler, say)? > > If we don't want to bootstrap a compiler for the host first then yes. > > > The present GCC build system puts various objects in .a files. Does this > > mean that WHOPR build of GCC requires LTO support for .a files, and so > > needs the linker plugin at present and does not work with GNU ld (for > > non-ELF hosts not supported by gold, for example) unless new features are > > added to GNU ld to support it (I hope such features are added to GNU ld)? > > ISTR somebody was working on teaching GNU ld to emit a resolution > file. See the patch from Dave Korn in PR41376. I don't know if > that was proposed to the binutils list yet. Option would be to modify our build system to not use libbackend.a that might be feasible solution for 4.6 if LD is not ready for plugins. With GOLD we link into GCC libiberty, libcpp and other stuff, but as far as I know linking backend + fronends with -fwhole-file should just work. (i.e. libiberty and libcpp are quite well behaved libraries) Honza > > Richard. > > > -- > > Joseph S. Myers > > joseph@codesourcery.com > >
Index: dominance.c =================================================================== --- dominance.c (revision 161199) +++ dominance.c (working copy) @@ -188,10 +188,10 @@ init_dom_info (struct dom_info *di, enum to be modified, obviously, if additional values are added to cdi_direction. */ -static unsigned int +static inline unsigned int dom_convert_dir_to_idx (enum cdi_direction dir) { - gcc_assert (dir == CDI_DOMINATORS || dir == CDI_POST_DOMINATORS); + gcc_checking_assert (dir == CDI_DOMINATORS || dir == CDI_POST_DOMINATORS); return dir - 1; } @@ -696,13 +696,13 @@ free_dominance_info (enum cdi_direction } /* Return the immediate dominator of basic block BB. */ -basic_block +inline basic_block get_immediate_dominator (enum cdi_direction dir, basic_block bb) { unsigned int dir_index = dom_convert_dir_to_idx (dir); struct et_node *node = bb->dom[dir_index]; - gcc_assert (dom_computed[dir_index]); + gcc_checking_assert (dom_computed[dir_index]); if (!node->father) return NULL; @@ -712,14 +712,14 @@ get_immediate_dominator (enum cdi_direct /* Set the immediate dominator of the block possibly removing existing edge. NULL can be used to remove any edge. */ -void +inline void set_immediate_dominator (enum cdi_direction dir, basic_block bb, basic_block dominated_by) { unsigned int dir_index = dom_convert_dir_to_idx (dir); struct et_node *node = bb->dom[dir_index]; - gcc_assert (dom_computed[dir_index]); + gcc_checking_assert (dom_computed[dir_index]); if (node->father) {