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 ' > 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::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]) @0x76625e60
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