atomic header cannot be compiled into translation unit with -fkeep-inline-functions

Bug #1610220 reported by Dimitri John Ledkov
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
gcc
Fix Released
Medium
gcc-6 (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

With gcc-6 6.1.1-11ubuntu11:

$ echo '#include <atomic>' > foo.h
$ gcc -fdump-translation-unit -fkeep-inline-functions -c -x c++-header -fpermissive -w -fPIC foo.h
In file included from /usr/include/c++/6/atomic:41:0,
                 from foo.h:1:
/usr/include/c++/6/bits/atomic_base.h: In member function 'std::atomic<bool>::operator bool() const':
/usr/include/c++/6/bits/atomic_base.h:390:7: error: inlining failed in call to always_inline 'std::__atomic_base<_IntTp>::__int_type std::__atomic_base<_IntTp>::load(std::memory_order) const noexcept [with _ITp = bool; std::__atomic_base<_IntTp>::__int_type = bool; std::memory_order = std::memory_order]': function body not available
       load(memory_order __m = memory_order_seq_cst) const noexcept
       ^~~~
In file included from foo.h:1:0:
/usr/include/c++/6/atomic:81:27: note: called from here
     { return _M_base.load(); }
                           ^

Expected no errors, and translation unit dumped as before, as was with gcc 5.4.0-6ubuntu1:
$ gcc -std=c++11 -fdump-translation-unit -fkeep-inline-functions -c -x c++-header -fpermissive -w -fPIC foo.h

Revision history for this message
In , Doko-v (doko-v) wrote :

$ echo '#include <atomic>' > foo.h

$ gcc-6 -std=c++11 -fdump-translation-unit -fkeep-inline-functions -c -x c++-header -fpermissive -w -fPIC foo.h
In file included from /usr/include/c++/6/atomic:41:0,
                 from foo.h:1:
/usr/include/c++/6/bits/atomic_base.h: In member function 'std::atomic<bool>::operator bool() const':
/usr/include/c++/6/bits/atomic_base.h:390:7: error: inlining failed in call to always_inline 'std::__atomic_base<_IntTp>::__int_type std::__atomic_base<_IntTp>::load(std::memory_order) const noexcept [with _ITp = bool; std::__atomic_base<_IntTp>::__int_type = bool; std::memory_order = std::memory_order]': function body not available
       load(memory_order __m = memory_order_seq_cst) const noexcept
       ^~~~
In file included from foo.h:1:0:
/usr/include/c++/6/atomic:81:27: note: called from here
     { return _M_base.load(); }
                           ^

$ gcc-5 -std=c++11 -fdump-translation-unit -fkeep-inline-functions -c -x c++-header -fpermissive -w -fPIC foo.h

Revision history for this message
In , Redi (redi) wrote :

The always_inline attributes were added by r198733

Revision history for this message
In , Hubicka (hubicka) wrote :

OK, the callee in question is:

std::__atomic_base<_IntTp>::__int_type std::__atomic_base<_IntTp>::load(std::memory_order) const [with _ITp = bool; std::__atomic_base<_IntTp>::__int_type = bool; std::memory_order = std::memory_order]/139 (std::__atomic_base<_IntTp>::__int_type std::__atomic_base<_IntTp>::load(std::memory_order) const [with _ITp = bool; std::__atomic_base<_IntTp>::__int_type = bool; std::memory_order = std::memory_order]) @0x7ffff6625e60
  Type: function
  Visibility: external public comdat visibility_specified
  References:
  Referring:
  First run: 0
  Function flags:
  Called by:
  Calls:

and it is indeed not defined. So it seems C++ FE thinks that the function is unused and never does cgraph_finalize?

Honza

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gcc-6 - 6.1.1-11ubuntu12

---------------
gcc-6 (6.1.1-11ubuntu12) yakkety; urgency=medium

  * Update to SVN 20160805 (r239167, 6.1.1) from the gcc-6-branch.
    Fix PR target/71869 (PPC), PR target/72805 (x86), PR target/70677 (AVR),
    PR c++/72415.

  * Fix running the libjava testsuite.
  * Revert fix for PR target/55947, causing PR libstdc++/72813. LP: #1610220.

 -- Matthias Klose <email address hidden> Fri, 05 Aug 2016 15:09:39 +0200

Changed in gcc-6 (Ubuntu):
status: New → Fix Released
Revision history for this message
In , Rguenth (rguenth) wrote :

GCC 6.2 is being released, adjusting target milestone.

Revision history for this message
In , Jakub-gcc (jakub-gcc) wrote :

GCC 6.3 is being released, adjusting target milestone.

Revision history for this message
In , Jakub-gcc (jakub-gcc) wrote :

Created attachment 40485
gcc7-pr72813.patch

I guess the resolution of this PR depends on what exactly should happen when creating PCH files.
On -x c-header or -x c++-header, with -E we just preprocess, nothing unexpected.
For -S without -o it has been broken for many years, only partially "fixed" in r237955, but that change only affected the non-save-temps path, with -save-temps -S still fails:
error: output filename specified twice
For -S with -o, or -save-temps and say -c or none of -E/-S/-c, we produced some assembly.

Now, the sources say:
/* This is the point to write out a PCH if we're doing that.
   In that case we do not want to do anything else. */
and bails out early from those functions, but actually in the caller the compilation happily continues.

So, either the comment is wrong and we just want to produce full assembly (sometimes thrown away, because it is written into a temporary file, sometimes user visible), then we need something like the attached untested patch (plus perhaps the fixes for the -S -save-temps case). This choice means creating of *.gch files might be slightly slower than now, but not significantly, because most of the work is done anyway, and also means that if there are some post-parsing reported errors, they will be diagnosed.

Or, we do what the comment says and e.g. set flag_syntax_only at that point before the early return, which means that even callers would do nothing else. Compilation of PCH files would be faster, the assembly written would need to be declared to be unusable for anything, and perhaps some diagnostics would not be emitted if it would normally happen after the spot where we write the PCH file.

Revision history for this message
In , Jakub-gcc (jakub-gcc) wrote :

Created attachment 40486
gcc7-pr72813-2.patch

The other option (on IRC Richard says *.s file for PCH doesn't make sense).
In the case the file remains (i.e. -S or -save-temps), it will contain just .file directive and nothing else.

Revision history for this message
In , Jakub-gcc (jakub-gcc) wrote :

Author: jakub
Date: Wed Jan 11 18:08:57 2017
New Revision: 244328

URL: https://gcc.gnu.org/viewcvs?rev=244328&root=gcc&view=rev
Log:
 PR c++/72813
 * gcc.c (default_compilers): Don't add -o %g.s for -S -save-temps
 of c-header.

 * c-decl.c (pop_file_scope): Set flag_syntax_only to 1 after writing
 PCH file.

 * decl2.c (c_parse_final_cleanups): Set flag_syntax_only to 1 after
 writing PCH file.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/c/ChangeLog
    trunk/gcc/c/c-decl.c
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/decl2.c
    trunk/gcc/gcc.c

Revision history for this message
In , Jakub-gcc (jakub-gcc) wrote :

Fixed on the trunk.

Revision history for this message
In , Rguenth (rguenth) wrote :

GCC 6.4 is being released, adjusting target milestone.

Changed in gcc:
importance: Unknown → Medium
status: Unknown → Confirmed
Revision history for this message
In , Jakub-gcc (jakub-gcc) wrote :

GCC 6 branch is being closed, fixed in 7.x.

Changed in gcc:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.