Passing -fno-lto by default?

[Markus Trippelsdorf]

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).

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)?

[Zack Weinberg]

On Thu, Feb 6, 2014 at 10:48 AM, Markus Trippelsdorf

Post by Markus Trippelsdorf
When using gcc with Link Time Optimization (-flto) enabled there are
certain configuration tests that always fail. For example the following
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).
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 not sure about the general case, but Firefox in particular is
still stuck on autoconf 2.13 and therefore anything we do on this end
won't do them the least bit of good.

zw

[Thomas Jahns]

Post by Markus Trippelsdorf
When using gcc with Link Time Optimization (-flto) enabled there are
certain configuration tests that always fail. For example the following
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.

Post by Markus Trippelsdorf
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.

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.

Thomas

[Markus Trippelsdorf]

Post by Thomas Jahns

Post by Markus Trippelsdorf
When using gcc with Link Time Optimization (-flto) enabled there are
certain configuration tests that always fail. For example the following
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.

Post by Thomas Jahns

Post by Markus Trippelsdorf
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.

Post by Thomas Jahns
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).

[Russ Allbery]

Post by Markus Trippelsdorf
Unfortunately the idiom above is quite common for visibility=hidden
testing.

Why would one not instead build the object and then use objdump on it to
look at the exported symbols? It's still not ideally portable, but it
seems like it should be more portable than trying to grep the assembly
output.

[Thomas Jahns]

Post by Russ Allbery
Why would one not instead build the object and then use objdump on it to
look at the exported symbols? It's still not ideally portable, but it
seems like it should be more portable than trying to grep the assembly
output.

could perhaps even nm solve that? Then using libtool, which tries to
find a BSD nm if available, would perhaps suffice.

Thomas
--
Thomas Jahns
DKRZ GmbH, Department: Application software

Deutsches Klimarechenzentrum
Bundesstraße 45a
D-20146 Hamburg

Phone: [phone]
Fax: [phone]
Email: Thomas Jahns <***@dkrz.de>

[Markus Trippelsdorf]

Post by Thomas Jahns

Post by Russ Allbery
Why would one not instead build the object and then use objdump on it to
look at the exported symbols? It's still not ideally portable, but it
seems like it should be more portable than trying to grep the assembly
output.

could perhaps even nm solve that? Then using libtool, which tries to
find a BSD nm if available, would perhaps suffice.

That could work if you look for symbols that change e.g. from 'W' to 't'
with -fvisibility=hidden. With -flto you will need binutils that use the
linker-plugin by default, but that's yet another issue.