This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [LTO merge][13/15] Add LTO front end
On Wed, 30 Sep 2009, Diego Novillo wrote:
> On Wed, Sep 30, 2009 at 16:56, Joseph S. Myers <joseph@codesourcery.com> wrote:
>
> > You'll need to ensure there is some fix or workaround in place before the
> > merge to trunk to avoid breaking the build. Â(If the problem code is only
> > included in the LTO front end, rather than in files built unconditionally
> > such as the streamer, disabling LTO for affected hosts may be a temporary
> > workaround to allow the code to merge.)
>
> Breaking the build where?
sparc-sun-solaris2.10, with whatever configurations of bootstrap compiler
don't have hidden visibility support, if the relevant files are compiled
other than when building the plugin.
> >> >> +/* This needs to be included after config.h. ÂOtherwise, _GNU_SOURCE will not
> >> >> + Â be defined in time to set __USE_GNU in the system headers, and strsignal
> >> >> + Â will not be declared. Â*/
> >> >> +#include <sys/mman.h>
> >> >
> >> > mmap and <sys/mman.h> are also not portable to all supported hosts (e.g.
> >> > MinGW). ÂThere should be configure tests and a suitable fallback.
> >>
> >> Added to PR41526.
> >
> > Likewise.
>
> Same question. What primary/secondary targets are broken?
i686-mingw32 host, any ELF target (supposing that libelf is installed, so
that LTO would get enabled by default).
I believe merges should avoid causing known regressions even on platforms
that are not primary or secondary; it's the treatment of a regression that
was unknown until after the patch goes in that depends on the status of
the platforms in question. But the above are primary or secondary hosts
and targets.
--
Joseph S. Myers
joseph@codesourcery.com