[Bug driver/81358] New: libatomic not automatically linked with C11 code

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

[Bug driver/81358] New: libatomic not automatically linked with C11 code

marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358

            Bug ID: 81358
           Summary: libatomic not automatically linked with C11 code
           Product: gcc
           Version: 7.1.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: driver
          Assignee: unassigned at gcc dot gnu.org
          Reporter: fxcoudert at gcc dot gnu.org
  Target Milestone: ---

This is on macOS 10.12 (Darwin 16.6.0). Compiling C11 code with -std=c11 fails
to link, unless one specifies -latomic

$ cat a.c
#include <stdio.h>
#include <complex.h>
#include <stdatomic.h>

int main(void)
{
    _Atomic long double _Complex x = 0.0 + 0.0*I;
    for (int i=0; i<1000; i++) {
        x += 1.0;
    }
    printf("(%Lf,%Lf)\n",creall(x), cimagl(x));
    printf("%zu\n",sizeof(x));
    return 0;
}

$ gcc-7 -std=c11 a.c -latomic
$ gcc-7 -std=c11 a.c        
Undefined symbols for architecture x86_64:
  "___atomic_feraiseexcept", referenced from:
      _main in cceeEpua.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status


------

From Homebrew report at https://github.com/Homebrew/homebrew-core/issues/14633

$ gcc-7 -v
Using built-in specs.
COLLECT_GCC=gcc-7
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/7.1.0/libexec/gcc/x86_64-apple-darwin16.6.0/7.1.0/lto-wrapper
Target: x86_64-apple-darwin16.6.0
Configured with: ../configure --build=x86_64-apple-darwin16.6.0
--prefix=/usr/local/Cellar/gcc/7.1.0
--libdir=/usr/local/Cellar/gcc/7.1.0/lib/gcc/7
--enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-7
--with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr
--with-mpc=/usr/local/opt/libmpc --with-isl=/usr/local/opt/isl
--with-system-zlib --enable-checking=release --with-pkgversion='Homebrew GCC
7.1.0' --with-bugurl=https://github.com/Homebrew/homebrew-core/issues
--disable-nls --with-native-system-header-dir=/usr/include
--with-sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk
Thread model: posix
gcc version 7.1.0 (Homebrew GCC 7.1.0)
Reply | Threaded
Open this post in threaded view
|

[Bug driver/81358] libatomic not automatically linked with C11 code

marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358

Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |link-failure
             Target|                            |x86_64-apple-darwin16.5.0
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2017-07-08
               Host|                            |x86_64-apple-darwin16.5.0
     Ever confirmed|0                           |1
              Build|                            |x86_64-apple-darwin16.5.0
Reply | Threaded
Open this post in threaded view
|

[Bug driver/81358] libatomic not automatically linked with C11 code

marxin at gcc dot gnu.org
In reply to this post by marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358

--- Comment #1 from Marc Glisse <glisse at gcc dot gnu.org> ---
That seems similar to using sqrt, which requires explicitly linking with libm.
Reply | Threaded
Open this post in threaded view
|

[Bug driver/81358] libatomic not automatically linked with C11 code

marxin at gcc dot gnu.org
In reply to this post by marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358

--- Comment #2 from Andreas Schwab <[hidden email]> ---
That doesn't mean that the mistake should be repeated.
Reply | Threaded
Open this post in threaded view
|

[Bug driver/81358] libatomic not automatically linked with C11 code

marxin at gcc dot gnu.org
In reply to this post by marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358

--- Comment #3 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
See what I said in
<https://gcc.gnu.org/ml/gcc-patches/2013-11/msg02605.html> - I think
linking --as-needed -latomic --no-as-needed makes sense by default when
--as-needed is supported.  The problem would be any platforms where (a)
there is no --as-needed support, but (b) shared libraries are supported
and linking with a shared library introduces a dependency into the binary
even if no symbols from that shared library are used.
Reply | Threaded
Open this post in threaded view
|

[Bug driver/81358] libatomic not automatically linked with C11 code

marxin at gcc dot gnu.org
In reply to this post by marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358

--- Comment #4 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
In the libm case, POSIX has an explicit list of headers whose functions
may require particular libraries to be linked in.  libatomic is required
for use of language features without any reference to functions from any
header.
Reply | Threaded
Open this post in threaded view
|

[Bug driver/81358] libatomic not automatically linked with C11 code

marxin at gcc dot gnu.org
In reply to this post by marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358

--- Comment #5 from Jeff Hammond <jeff.science at gmail dot com> ---
Indeed, _Atomic is a language keyword and doesn't require any headers (the
inclusion of stdatomic.h in this code is superfluous), so the "header->explicit
library" argument doesn't apply.

In any case, I do not see why language intrinsics that require headers should
require libraries.  Why is sqrt() from math.h different from fprintf() from
stdio.h?  Maybe POSIX requires that, but ISO C11 doesn't, and I'm using
-std=c11 not -std=posix.

--as-needed would greatly enhance user experience for both this and libm.
Reply | Threaded
Open this post in threaded view
|

[Bug driver/81358] libatomic not automatically linked with C11 code

marxin at gcc dot gnu.org
In reply to this post by marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358

--- Comment #6 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
The design of what's in separate libraries is historical; since it
probably predates shared libraries, the reason isn't obvious (with shared
libraries, before --as-needed, it avoided unnecessary runtime
dependencies).  The conformance documentation for an implementation as a
whole (compiler plus libraries) would of course specify using -std=c11
-pedantic -lm -latomic, or whatever.  For a new libc implementation for
Unix-like systems it would be natural just to use libc.so for everything,
subject to performance issues from causing everything to be (potentially)
multithreaded by linking with pthreads functions.  Note e.g. glibc moved
some clock/timer functions from librt to libc a while back to avoid such
issues from linking in librt.

The POSIX rules for the c99 utility, which correspond more or less to the
traditional division into libraries on Unix-like systems, are at:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/c99.html
Reply | Threaded
Open this post in threaded view
|

[Bug driver/81358] libatomic not automatically linked with C11 code

marxin at gcc dot gnu.org
In reply to this post by marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358

--- Comment #7 from Joseph S. Myers <jsm28 at gcc dot gnu.org> ---
This came up in the RISC-V BoF today.
Reply | Threaded
Open this post in threaded view
|

[Bug driver/81358] libatomic not automatically linked with C11 code

marxin at gcc dot gnu.org
In reply to this post by marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358

--- Comment #8 from Andreas Schwab <[hidden email]> ---
See also bug 84568 and bug 86005.
Reply | Threaded
Open this post in threaded view
|

Re: [Bug driver/81358] libatomic not automatically linked with C11 code

Joseph Myers
In reply to this post by marxin at gcc dot gnu.org
I should also note the testsuite point I mentioned in the BoF, and related
points about building target libraries, which mean this is more
complicated than just the driver specs change:

There is testsuite logic (see gcc/testsuite/lib/atomic-dg.exp) to locate
libatomic for build-tree testing and set appropriate -L options and
LD_LIBRARY_PATH.

This is only used in gcc/testsuite/gcc.dg/atomic/atomic.exp at present.  
If the driver specs change to use "--as-needed -latomic --no-as-needed"
whenever libatomic is built (obviously they shouldn't do so for
configurations not building libatomic, whether because unsupported for the
target or because disabled at configure time), linking *any* target
program will then require libatomic to be somewhere that ld can find it
(because ld requires a library named with -l to be somewhere it can find,
even inside --as-needed; it can only know whether a library is needed
after seeing what symbols it defines).

Thus, that logic would need to be used globally for all testsuites.  In
addition, all configure tests in target libraries that run link tests, and
linking of shared target libraries, would need to pass appropriate -L
options to find libatomic, and we'd need to make sure the target library
dependencies in toplevel Makefile.def ensure libatomic is built before
other target libraries are configured for this to work.  I think libgcc
should still be built before libatomic and so we'd need some driver option
to disable linking with libatomic that would be passed when linking shared
libgcc.

--
Joseph S. Myers
[hidden email]
Reply | Threaded
Open this post in threaded view
|

[Bug driver/81358] libatomic not automatically linked with C11 code

marxin at gcc dot gnu.org
In reply to this post by marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358

--- Comment #9 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
I should also note the testsuite point I mentioned in the BoF, and related
points about building target libraries, which mean this is more
complicated than just the driver specs change:

There is testsuite logic (see gcc/testsuite/lib/atomic-dg.exp) to locate
libatomic for build-tree testing and set appropriate -L options and
LD_LIBRARY_PATH.

This is only used in gcc/testsuite/gcc.dg/atomic/atomic.exp at present.  
If the driver specs change to use "--as-needed -latomic --no-as-needed"
whenever libatomic is built (obviously they shouldn't do so for
configurations not building libatomic, whether because unsupported for the
target or because disabled at configure time), linking *any* target
program will then require libatomic to be somewhere that ld can find it
(because ld requires a library named with -l to be somewhere it can find,
even inside --as-needed; it can only know whether a library is needed
after seeing what symbols it defines).

Thus, that logic would need to be used globally for all testsuites.  In
addition, all configure tests in target libraries that run link tests, and
linking of shared target libraries, would need to pass appropriate -L
options to find libatomic, and we'd need to make sure the target library
dependencies in toplevel Makefile.def ensure libatomic is built before
other target libraries are configured for this to work.  I think libgcc
should still be built before libatomic and so we'd need some driver option
to disable linking with libatomic that would be passed when linking shared
libgcc.
Reply | Threaded
Open this post in threaded view
|

[Bug driver/81358] libatomic not automatically linked with C11 code

marxin at gcc dot gnu.org
In reply to this post by marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358

--- Comment #10 from Andreas Schwab <[hidden email]> ---
All these failure modes can already be observed on riscv-linux, where -pthread
implies -latomic.