[Bug 1610220] Re: atomic header cannot be compiled into translation unit with -fkeep-inline-functions
Bug Watch Updater
1610220 at bugs.launchpad.net
Wed Nov 7 13:40:00 UTC 2018
Launchpad has imported 14 comments from the remote bug at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72813.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.
------------------------------------------------------------------------
On 2016-08-05T12:13:40+00:00 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
Reply at:
https://bugs.launchpad.net/ubuntu/+source/gcc-6/+bug/1610220/comments/1
------------------------------------------------------------------------
On 2016-08-05T12:20:22+00:00 Redi wrote:
The always_inline attributes were added by r198733
Reply at:
https://bugs.launchpad.net/ubuntu/+source/gcc-6/+bug/1610220/comments/2
------------------------------------------------------------------------
On 2016-08-05T13:19:07+00:00 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
Reply at:
https://bugs.launchpad.net/ubuntu/+source/gcc-6/+bug/1610220/comments/3
------------------------------------------------------------------------
On 2016-08-22T08:26:36+00:00 Rguenth wrote:
GCC 6.2 is being released, adjusting target milestone.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/gcc-6/+bug/1610220/comments/5
------------------------------------------------------------------------
On 2016-08-22T08:27:42+00:00 Rguenth wrote:
GCC 6.2 is being released, adjusting target milestone.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/gcc-6/+bug/1610220/comments/6
------------------------------------------------------------------------
On 2016-08-22T08:48:43+00:00 Rguenth wrote:
GCC 6.2 is being released, adjusting target milestone.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/gcc-6/+bug/1610220/comments/7
------------------------------------------------------------------------
On 2016-08-22T08:50:08+00:00 Rguenth wrote:
GCC 6.2 is being released, adjusting target milestone.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/gcc-6/+bug/1610220/comments/8
------------------------------------------------------------------------
On 2016-12-21T10:59:19+00:00 Jakub-gcc wrote:
GCC 6.3 is being released, adjusting target milestone.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/gcc-6/+bug/1610220/comments/9
------------------------------------------------------------------------
On 2017-01-10T09:19:48+00:00 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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/gcc-6/+bug/1610220/comments/10
------------------------------------------------------------------------
On 2017-01-10T09:55:26+00:00 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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/gcc-6/+bug/1610220/comments/11
------------------------------------------------------------------------
On 2017-01-11T18:09:29+00:00 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
Reply at:
https://bugs.launchpad.net/ubuntu/+source/gcc-6/+bug/1610220/comments/12
------------------------------------------------------------------------
On 2017-01-11T20:32:17+00:00 Jakub-gcc wrote:
Fixed on the trunk.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/gcc-6/+bug/1610220/comments/13
------------------------------------------------------------------------
On 2017-07-04T08:50:17+00:00 Rguenth wrote:
GCC 6.4 is being released, adjusting target milestone.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/gcc-6/+bug/1610220/comments/14
------------------------------------------------------------------------
On 2018-10-26T11:17:04+00:00 Jakub-gcc wrote:
GCC 6 branch is being closed, fixed in 7.x.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/gcc-6/+bug/1610220/comments/15
** Changed in: gcc
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to gcc-6 in Ubuntu.
https://bugs.launchpad.net/bugs/1610220
Title:
atomic header cannot be compiled into translation unit with -fkeep-
inline-functions
Status in gcc:
Fix Released
Status in gcc-6 package in Ubuntu:
Fix Released
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
To manage notifications about this bug go to:
https://bugs.launchpad.net/gcc/+bug/1610220/+subscriptions
More information about the foundations-bugs
mailing list