Re: Passing -fno-lto by default?

[Markus Trippelsdorf]

On 2014.02.06 at 17:30 +0100, Thomas Jahns wrote:
> On 02/06/14 16:48, Markus Trippelsdorf wrote:
> > When using gcc with Link Time Optimization (-flto) enabled there are
> > certain configuration tests that always fail. For example the following
> > test taken from Firefox's configure.in:
> >   ac_cv_visibility_default=no
> >   if ${CC-cc} -fvisibility=hidden -Werror -S conftest.c -o conftest.s 
> > >/dev/null 2>&1; then
> >     if ! egrep '\.(hidden|private_extern).*foo' conftest.s >/dev/null; then
> >       ac_cv_visibility_default=yes
> > ...
> > which greps the assembler output, will not succeed with -flto (because
> > it produces GIMPLE output in special sections).
> 
> this is broken on so many levels: 1. it totally relies on gcc which is a nice,
> if not the nicest, compiler but the scope of autotools is a bit broader, 2. it
> relies on the compiler being able to produce assembly equivalents which is
> probably possible for any compiler but very far from portable 3. it relies on
> the assembly following a particular symbol convention which is probably far 
> from
> universal. With cases like this I propose to ask what the intended purpose was
> in the first place and look for a saner approach. I can see that JIT software
> has special needs but I can see no good way to approach this in a framework
> aimed at virtualizing build environments.

Unfortunately the idiom above is quite common for visibility=hidden
testing.

> > Now my question is if it wouldn't be desirable to have autoconf pass the
> > -fno-lto flag automatically by default (instead of requiring each
> > project to add it by hand when needed)?
> 
> I'm very much opposed to autoconf adding arbitrary compiler flags, especially
> those which remove desirable features. Doing so "only" intermediately means 
> the
> configure tests essentially run with another environment putting their 
> validity
> unnecessarily into question.

Please note that the "environment" should be exactly the same for -flto
and -fno-lto. All features that pass configure tests with -fno-lto are
also available with -flto. Thus passing -fno-lto intermediately should
have no unexpected side effects.

> My recommendation would be to put some mechanism into your configure.ac that
> substitutes/adds to CFLAGS after the configure tests and before AC_OUTPUT and
> which is controlled solely by the users. I have this in several of my projects
> because profiling/tracing tools frequently must be used as compiler wrappers 
> but
> are not up to pass the tests or need extra flags that cannot be used in the 
> tests.

While that would work, it obviously requires manual intervention.

The issue will become urgent when gcc-4.9 gets released, because it
switched from "fat" LTO objects (that contain GIMPLE and the normal
object code) to "slim" LTO objects that only consists of the
intermediate internal representation (GIMPLE).

-- 
Markus