This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Build breakage on darwin and pa64-hpux [was Re: Use -fbuilding-libgcc for more target macros used in libgcc]
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Andreas Schwab <schwab at linux-m68k dot org>
- Cc: Mike Stump <mikestump at comcast dot net>, Dominique Dhumieres <dominiq at lps dot ens dot fr>, <gcc-patches at gcc dot gnu dot org>, <iant at google dot com>, <dmalcolm at redhat dot com>
- Date: Mon, 8 Sep 2014 23:54:01 +0000
- Subject: Re: Build breakage on darwin and pa64-hpux [was Re: Use -fbuilding-libgcc for more target macros used in libgcc]
- Authentication-results: sourceware.org; auth=none
- References: <20140905225958 dot 0DE7FFF at mailhost dot lps dot ens dot fr> <B51EBCE2-8617-45CC-879D-490B87CA3263 at comcast dot net> <m2wq9hmd09 dot fsf at linux-m68k dot org>
On Sat, 6 Sep 2014, Andreas Schwab wrote:
> Mike Stump <mikestump@comcast.net> writes:
>
> > Index: config/pa/pa64-hpux.h
> > ===================================================================
> > --- config/pa/pa64-hpux.h (revision 214981)
> > +++ config/pa/pa64-hpux.h (working copy)
> > @@ -336,7 +336,7 @@ do { \
> > the sections are not actually used. However, we still must provide
> > defines to select the proper code path. */
> > #undef INIT_SECTION_ASM_OP
> > -#define INIT_SECTION_ASM_OP
> > +#define INIT_SECTION_ASM_OP ""
> > #undef FINI_SECTION_ASM_OP
> > #define FINI_SECTION_ASM_OP
>
> What about FINI_SECTION_ASM_OP?
My patch didn't do anything with FINI_SECTION_ASM_OP.
As it's not actually used on the host at all (unlike INIT_SECTION_ASM_OP),
it could be moved to libgcc_tm.h. However, my inclination is that it
would be confusing to have such closely related target macros in different
places, and so it would make sense to add FINI_SECTION_ASM_OP and
FINI_ARRAY_SECTION_ASM_OP to the target macros that are communicated to
libgcc via macros predefined with -fbuilding-libgcc. (This is without
prejudice to any possible future cleanup or refactoring of the macros in
this area.)
--
Joseph S. Myers
joseph@codesourcery.com