CircularlyReferenceable.cc:76: error: called from here /usr/local/lib/gcc/alphaev56-unknown-linux-gnu/4.3.0/../../../../ include/c++/4.3.0/bits/stl_multiset.h:91: error: inlining failed in call to 'std::multiset<const PatternDriver::CircularlyReferenceable*, std::less<const PatternDriver::CircularlyReferenceable*>, std::allocator<const PatternDriver::CircularlyReferenceable*> >:: ~multiset()': call is unlikely CircularlyReferenceable.cc:76: error: called from here gmake: *** [CircularlyReferenceable.o] Error 1 This error (actually a warning) makes no sense: how can a destructor call be unlikely? What does that mean? I suspect that the warning is badly worded. What is intended here? Also, multiset is in the STL, and Winline should not be reporting against it. alpha1:gcc>uname -a Linux alpha1 2.4.9-40 #1 Mon Sep 23 08:14:02 EDT 2002 alpha unknown alpha1:gcc>g++ -v Using built-in specs. Target: alphaev56-unknown-linux-gnu Configured with: ../gcc/configure --verbose --enable-languages=c++ --disable-linux-futex --disable-nls --disable-tls Thread model: posix gcc version 4.3.0 20070519 (experimental) alpha1:gcc>alias CONFIGURECVS alias CONFIGURECVS='../gcc/configure --verbose --enable-languages=c++ --disable-linux-futex --disable-nls --disable-tls >clog 2>&1 &' alpha1:gcc>alias BUILD alias BUILD='nice gmake CFLAGS='\'''\'' BOOT_CFLAGS='\'''\'' LIBCFLAGS='\''-g'\'' LIBCXXFLAGS='\''-g'\'' bootstrap >log 2>&1 &'
First the deconstructor was either defaulted to inline or marked as such. Second what are the full options do you use? If the call is unlikely (which it says in your case), then there is no reason to inline it. I bet this comes from exceptions.
Here is how I compile it: /usr/local/bin/g++ -c -O3 -DNDEBUG -Wuninitialized -pedantic-errors -Werror -Winline -ansi -fno-common -Wall -Wold-style-cast -Wsign-promo -Wpointer-arith -Wundef -Wwrite-strings -Winvalid-pch -Woverloaded-virtual -Wcast-qual -Wextra -Wredundant-decls -Wshadow -Wcast-align -Wcomment -fstrict-aliasing -Winit-self -Wmissing-include-dirs -Wswitch-default -Wswitch-enum -Wlogical-op -Wunused -fvisibility-inlines-hidden -MMD -fimplicit-templates -o CircularlyReferenceable.o CircularlyReferenceable.cc "froms" is the multiset. The destructor will be called in the normal case. There is an exception, but it is thrown before the multiset is even created. SeenMultiset froms; if (from != PDNULL) { froms.insert(from); } // Record we've been seen seen_map.insert(std::make_pair(this, froms)); return true; The warning points at the seen_map.insert and the return. Whole member function: bool CircularlyReferenceable:: _accumulate_delete_candidates( const CircularlyReferenceable * const from, SeenMap& seen_map) const { if (! _is_allocated()) { if (! get_strict()) { return false; } throw InternalException(_message(_msgtext("Inconsistent reference " "count: %s(0)::%s(1)"), name(), "_accumulate_delete_candidates"), __FILE__, __LINE__); } // Get our entry (if there is one) const SeenMap::iterator it(seen_map.find(this)); if (it == seen_map.end()) { // We haven't been seen before; make an entry SeenMultiset froms; if (from != PDNULL) { froms.insert(from); } // Record we've been seen seen_map.insert(std::make_pair(this, froms)); return true; } // We have been seen before, update the set of pointers to us if (from != PDNULL) { it->second.insert(from); } return false; }
Can you attach the preprocessed source?
Created attachment 13674 [details] Preprocessed source
(In reply to comment #3) > Can you attach the preprocessed source? > I did on June 10, I see the status is still Waiting.
OK, I am switching it to new again ;) However the warning really means that GCC decided to not inline the function because it thinks it is not profitable because it concluded that the call is infrequent. Perhaps you can suggest better wording? The cold regions can be controlled via hot-bb-frequency-fraction parameter. Honza
How can GCC conclude that a call is going to be infrequent? Doesn't that amount to predicting the future? Also, if an object is constructed, then it will be destroyed. So there is almost a 100% chance of calling the destructor if the class is used at all. Maybe I'm missing something. It would be best for the message to say the REAL reason for not inlining, whatever that may be. If that is not feasible, I would be OK with just saying "inlining call determined to be unprofitable". That is vague, but not confusing.
Yes, it is a prediction of future, see http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.43.6404 for details. Inline decision and branch prediction is set of heuristics that are based on common observations of the program behaviour. You can use -fprofile-generate/-fprofile-use when this technique fails (or provide self contained testcases how the heuristics can be improved)
Is this: http://gcc.gnu.org/ml/gcc-help/2012-07/msg00029.html related to this bug?
We no longer produce the warning. It does appear that the symbol in question is indeed not inlined, so I don't think the problem has gone latent and it really has been fixed somewhere in the previous 7 years.