It looks like for a while now (5 years) some code that was meant to do
smart things in Mutex.cpp hasn't been doing such smart things:
I don't know if this change was even deliberate since it came in with
another change & the description doesn't mention it. Should we do away
with this logic if it hasn't been needed all this time? Reinstate it
(with the old logic? or with a configure-based preprocessor variable
instead)?
On some (linux?) implementations, various pthread APIs are defined as "weak extern" symbols in libc and strong definitions in libpthreads. The idea of this check is thus to detect if pthreads is linked into the app and enable threads if so.
-Chris
Sorry, right - I should've been more clear. I understand that that's
what the declaration/boolean used to do:
static const bool pthread_enabled = static_cast<bool>(pthread_mutex_init);
But that's not what the code does now - the change you made 5 years
ago changed it to a constant:
static const bool pthread_enabled = true;
(I found this because the return outside the 'if (pthread_unabled) {
... return }' was marked as unreachable by -Wunreachable-code). Since
it hasn't actually been doing anything for 5 years - should we just
remove the variable & all the conditions (unconditionally using
pthreads), or reinstate the smarts it used to have (testing the weak
symbol)?
Aha, I'm completely fine with constant folding this all away. Simple is good.
-Chris
Sounds good. Committed as r148206 (including a similar fix in
RWMutex.cpp - which propagated the same quirk when it was
copy/pasted/created from Mutex.cpp)
I've attached a patch containing some other fixes to remove
unreachable code in LLVM - this isn't comprehensive, but a start based
on -Wunreachable-code. Is this sort of thing OK to commit as I work
through it? About the most noteworthy parts are:
1) two instances of code deliberately if(false)ed out with comments
explaining that developers can bring it back in once something works
or to aid in debugging. I switched these to #if 0 instead - I realize
this means those code snippets may bitrot since they won't be compiled
anymore. Is this the right thing? Should we have some construct for
"deliberately unreachable" code like this? (perhaps like the
parentheses warning - some quirky syntax people could use when they
intend to create an always false condition)
2) Mostly it was just replacing trailing returns that used to be there
to satisfy GCC with llvm_unreachable instead. (also there were a lot
of break/return/etc after llvm_Unreachables which were easily removed)
- David
llvm_unreachable_fixes.diff (5.99 KB)
IMHO, the weird syntax is already in use, and -Wunreachable-code shouldn’t warn on this. Blatantly deliberate stuff isn’t interesting to me as a compiler warning, especially as it makes debugging code very annoying. I want to be able to random place ‘if (0)’ into code as needed during debugging without having a -Werror build break.
I would exempt 0 and false is whole conditions, or maybe others…
Anyways, my 2 cents.