https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68771
--- Comment #9 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Daniel Vollmer from comment #8)
> Using g++-7.4.0 I'm now seeing the following:
> - Step 1) (the compilation with "-flto -fprofile-generate") still works,
So - to be sure - this is LTO without "-g"?
(we should expect LTO to work in general, without the debug scenario)
> including the visibility warnings mentioned in Comment #2, in particular
>
> ld: warning: direct access in function
> '__GLOBAL__sub_I_65535_0_FaceBasedMeshPreprocessingArguments.cpp.lto_priv.
> 203' from file
> '/var/folders/02/yl3m8d4d0397mk6dxn6dpcqw0000gp/T//ccf8A4Wl.ltrans0.ltrans.
> o' to global weak symbol
> '__ZGVZNK4flis4Para9ValueNodeIbE11GetNodeTypeB5cxx11EvE1s' from file
> '/var/folders/02/yl3m8d4d0397mk6dxn6dpcqw0000gp/T//ccf8A4Wl.ltrans0.ltrans.
> o' means the weak symbol cannot be overridden at runtime. This was likely
> caused by different translation units being compiled with different
> visibility settings.
There are some cases where ld64 *thinks* that direct access to A from B
represents the problem it describes, but in fact the pathway isn't reachable
independently.
So, what we need is to determine that the CTOR mentioned cannot be invoked
independently of selecting the impl. represented by
__ZGVZNK4flis4Para9ValueNodeIbE11GetNodeTypeB5cxx11EvE1s.
What would be useful here is one case to review - as .s file (likely the
remainder repeat this circumstance).
> - Step 2 now no longer hangs, the Python extensions exits successfully and
> seems to generate / write profile data. The code executed to generate the
> profiles is multi-threaded.
> - Step 3 now fails (during "compilation" of the .cpp files) for at least one
> file with the following error:
So the 'symbol redefinition
___cold_sect_of_ComputeBoundingBox:
"
fails are gone, as expected.
> src/LinearSolver/InstantiationJacobi6.cpp: In member function
> 'flis::IndexedSubset<unsigned
> int>::Loop<flucs::BlockMatrix<Eigen::Matrix<double, 6, 6, 0, 6, 6>,
> flucs::SparseMatrixIndexMapping<true, unsigned int>
> >::MultiplyAdd(flis::ThreadedCommunicationContext&, flis::Reducer const&,
> flucs::BlockVector<Eigen::Matrix<double, 6, 1, 0, 6, 1>, unsigned int>
> const&, double, flucs::BlockVector<Eigen::Matrix<double, 6, 1, 0, 6, 1>,
> unsigned int> const&, flucs::BlockVector<Eigen::Matrix<double, 6, 1, 0, 6,
> 1>, unsigned int>&) const::{lambda(unsigned
> int)#1}>(flucs::BlockMatrix<Eigen::Matrix<double, 6, 6, 0, 6, 6>,
> flucs::SparseMatrixIndexMapping<true, unsigned int>
> >::MultiplyAdd(flis::ThreadedCommunicationContext&, flis::Reducer const&,
> flucs::BlockVector<Eigen::Matrix<double, 6, 1, 0, 6, 1>, unsigned int>
> const&, double, flucs::BlockVector<Eigen::Matrix<double, 6, 1, 0, 6, 1>,
> unsigned int> const&, flucs::BlockVector<Eigen::Matrix<double, 6, 1, 0, 6,
> 1>, unsigned int>&) const::{lambda(unsigned int)#1} const&) constvoid':
> src/LinearSolver/InstantiationJacobi6.cpp:21:1: error: corrupted profile
> info: profile data is not flow-consistent
> If I disable threading for the Profile generation (Step 2)), then the
> compilation in Step 3) seems to succeed, and I get a functioning result.
OK - so this is a new problem now, that we seem to have some issue with profile
generation in a multithreaded scenario.
