[Bug driver/103949] gcc fails to provide a standard conforming C11 or C++17 environment even when specifying -std=c11 or -std=c++17

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103949

--- Comment #9 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jörn Heusipp from comment #8)
> > Note in newer versions of glibc, libpthread is all intergrated into libc and
> > there is no issues again.
> > 
> > For Mac OS X/darwin you don't need -lm -pthread because libc has it.
> 
> Two examples where it works by chance is not sufficient to invalidate my
> point about the general case.

But it does mean the problem you're raising doesn't exist on two of GCC's
primary platforms. So the problem is "fixing itself" for many users.

> > >gcc libstdc++ implements std::thread. So what's your point again?
> > 
> > Because it implements it on top of pthreads.
> 
> Yeah, so that is an implementation detail because of which I am required to
> pass -pthread. Why should the user of gcc even care how std::thread is
> implemented? It literally makes no sense. You are supporting my point.

It's like that because linking to libpthread has historically caused
performance degradation for C++ programs, due to reference counting in
shared_ptr and the COW std::string using slower atomic ops if libpthread is
linked into the executable. So if the compiler implicitly added -lpthread to
every C++ program using C++11 or later, it would hurt the performance of
single-threaded programs.

It matters less for the std::string reference counting now, because most people
use the SSO string not the COW string, but it still affects std::shared_ptr.

With recent glibc versions we have a better way to detect whether the process
is single-threaded, and no longer make it depend on whether libpthread is
linked in or not. And with very recent versions, you don't need  -pthread at
all.

> Debian MinGW-w64 gcc is built in 2 flavours. One with Win32 and one with
> posix threading model support. The version with posix threading model
> support uses pthreads, and knows how to implement std::thread. Why is GCC
> assuming single-threaded in that context?

The fact the runtime is capable of supporting threads doesn't mean a given
program compiled by the user actually uses threads.

I understand your complaint, but I think it's unlikely we're going to change
anything in GCC.

The docs do not say that -std=c++17 is sufficient to get a fully C++17
conforming environment, so strictly speaking this report is not a bug. You're
complaining about something we don't aim for anyway. The implementation
documents that you need to add certain other flags for some features:

https://gcc.gnu.org/onlinedocs/libstdc++/manual/using.html#manual.intro.using.flags

This isn't ideal, but it's not easy to fix. And as already stated, some
platforms are changing so it Just Works anyway.