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

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

[manx-bugzilla at problemloesungsmaschine dot de]

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

            Bug ID: 103949
           Summary: gcc fails to provide a standard conforming C11 or
                    C++17 environment even when specifying -std=c11 or
                    -std=c++17
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: driver
          Assignee: unassigned at gcc dot gnu.org
          Reporter: manx-bugzilla at problemloesungsmaschine dot de
  Target Milestone: ---

Consider the following simple C11 program:
```
#include <math.h>
#include <stdbool.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#if !defined(__STDC_NO_THREADS)
#include <threads.h>
#endif

#if !defined(__STDC_NO_THREADS)

static int mythread(void * arg) {
        int param = *(int*)arg;
        double value = pow((double)param, (double)param);
        printf("%f\n", value);
        return 1;
}

bool test(int param) {
        thrd_t t;
        memset(&t, 0, sizeof(thrd_t));
        if (thrd_create(&t, &mythread, &param) != thrd_success) {
                return false;
        }
        int result = 0;
        if (thrd_join(t, &result) != thrd_success) {
                return false;
        }
        return (result != 0);
}

#else

bool test(int param) {
        double value = pow((double)param, (double)param);
        printf("%f\n", value);
        return true;
}

#endif

int main(int argc, const char * argv []) {
        (void)argv;
        return test(argc) ? EXIT_SUCCESS : EXIT_FAILURE;
}
```

When I invoke `gcc -std=c11`, it fails to build the program:
```
manx@appendix:~/tmp$ gcc -std=c11 -O3 -Wall -Wextra -Wpedantic c11.c -o test
/usr/bin/ld: /tmp/ccxASC6u.o: in function `mythread':
c11.c:(.text+0x11): undefined reference to `pow'
/usr/bin/ld: /tmp/ccxASC6u.o: in function `test':
c11.c:(.text+0x53): undefined reference to `thrd_create'
/usr/bin/ld: c11.c:(.text+0x7b): undefined reference to `thrd_join'
collect2: error: ld returned 1 exit status
manx@appendix:~/tmp$
```
(gcc (Debian 11.2.0-13) 11.2.0 on a amd64 Debian Testing system, as of today).

It works when I invoke gcc as `gcc -std=c11 -pthread -lm`:
```
manx@appendix:~/tmp$ gcc -std=c11 -O3 -Wall -Wextra -Wpedantic c11.c -lm
-pthread -o test
manx@appendix:~/tmp$
```

Looking at C++, g++ is slightly better in that it does not barf for math,
however it also fails for threads:
```
manx@appendix:~/tmp$ cat cxx17.cpp

#if defined(__STDCPP_THREADS__) && (__STDCPP_THREADS__ == 1)

#include <iostream>
#include <thread>

#include <cmath>

static void mythread(double param) {
        double value = std::pow(param, param);
        std::cout << value << std::endl;
        return;
}

bool test(int param) {
        {
                std::thread t{&mythread, static_cast<double>(param)};
                t.join();
        }
        return true;
}

int main(int argc, const char * argv []) {
        static_cast<void>(argv);
        return test(argc) ? 0 : 1;
}

#else

#error "no threads"

#endif

manx@appendix:~/tmp$ g++ -std=c++17 -O3 -Wall -Wextra -Wpedantic cxx17.cpp -o
test
/usr/bin/ld: /tmp/cc1ItNk0.o: in function `test(int)':
cxx17.cpp:(.text+0xd7): undefined reference to `pthread_create'
collect2: error: ld returned 1 exit status
manx@appendix:~/tmp$ g++ -std=c++17 -O3 -Wall -Wextra -Wpedantic cxx17.cpp
-pthread -o test
manx@appendix:~/tmp$
```

For MinGW, it's just confused:
```
manx@appendix:~/tmp$ i686-w64-mingw32-g++-posix -std=c++17 -O3 -Wall -Wextra
-Wpedantic -mthreads cxx17.cpp -o test
cxx17.cpp:30:2: error: #error "no threads"
   30 | #error "no threads"
      |  ^~~~~

manx@appendix:~/tmp$ i686-w64-mingw32-g++-posix -std=c++17 -O3 -Wall -Wextra
-Wpedantic -mthreads -D__STDCPP_THREADS__=1 cxx17.cpp -o test
manx@appendix:~/tmp$ i686-w64-mingw32-g++-posix --version
i686-w64-mingw32-g++-posix (GCC) 10-posix 20210110
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

manx@appendix:~/tmp$
```

The C11 as well as the C++17 standards both include both, math and threads, yet
gcc fails to provide a complete implementation without adding baroque options.
Even more so, gcc *claims* to support threads, when it actually does not.

Now, I am aware of historic reasons why things came to be the way they
currently (which is ~50 years later) still are, however I completely fail to
see why it is really necessary to still complicate building standard conforming
programs for modern users. The original reasons are irrelevant to the common
case nowadays.

I am also aware of embedded situations where the fragmented behavior *could* be
desirable.

I therefore suggest:
 1. Implicitly link anything mandated by the respective standard for a complete
implementation when the user requests standard-compliance via -std= switch.
 2. Add compiler option -fno-math, which (optionally) cuts off linking some
standard libraries by default if possible on the respective platform.
 3. Add compiler option -fno-threads, which (optionally) cuts off linking some
standard libraries by default if possible on the respective platform, and which
implies setting __STDC_NO_THREADS as per C11 standard or unsetting
__STDCPP_THREADS__ as per C++ standard.
 4. Deprecate and warn about -lm.
 5. Deprecate and warn about -pthread, -pthreads, -mthread, -mthreads, and
-threads.
 6. Fix the inconsistency for MinGW, which does not claim __STDCPP_THREADS__
even when using Posix threading model, where it actually supports threads.

I do not care jack what gcc does when the user specifies -std=gnu11 or
-std=gnu++17. If you still think these quirks make sense there, leave them as
they are for GNU standards.

I am also aware that -lm is not strictly speaking gcc's business and might be
better suited for a bug report against the C library (glibc in my case),
however it's the compiler that I am requesting C11 support from, thus it IMHO
is the compiler's responsibility to provide an adequate implementation.

I somewhat expect you may be tempted to disregard or close this bug report as
irrelevant or maybe a duplicate, but I honestly urge you to reconsider gcc's
utterly quirky behavior here. It makes no sense, and it's about time to
actually fix the problem.

The re-iterate the problem for a last concise time:
When I request -std=c11, I expect to get a working C11 environment, which if
!__STDC_NO_THREADS provides adequate support for multi-threaded programs. The
same applies for C++, and also for the MinGW case (see -mthreads). The defaults
must adhere to the standard.

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

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The c and c++ standard does not talks about how to invoke the compiler. POSIX
does but that is a different standard all together.

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

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Also gcc implements the compiler, it is up to the other vendor to implement the
rest of the c library. Gcc does not implement printf either.

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

[manx-bugzilla at problemloesungsmaschine dot de]

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

Jörn Heusipp <manx-bugzilla at problemloesungsmaschine dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |---

--- Comment #3 from Jörn Heusipp <manx-bugzilla at problemloesungsmaschine dot de> ---

> The c and c++ standard does not talks about how to invoke the compiler. POSIX does but that is a different standard all together.

I'm not asking gcc to implement whatever POSIX demands or deems reasonable from
a C compiler. I am asking -std=c11, or -std=c++17, which are ISO standards, for
which gcc by default only provides incomplete implementations while it would be
actually easy to provide complete implementations, and that would simplify
building.

If the standard does not demand anything, why are you even linking libc by
default then? There is no explanation or reasoning for the inconsistency
between different aspects of the standard.

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

This is exactly the same problem, and as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358#c2 Andreas Schwab said:
"That doesn't mean that the mistake should be repeated."

I very much agree. And I very much want to see the earlier mistakes repaired as
well.

Consider the atomics issue to be also required to fix in order to close this
bug.

> Also gcc implements the compiler, it is up to the other vendor to implement the rest of the c library. Gcc does not implement printf either.

gcc libstdc++ implements std::thread. So what's your point again?

You did not address any of the standard violating behavior concerning
advertising thread support at all.

I did ask to not outright disregard this bug report. I suggest re-reading my
report, and at least try to acknowledge my reasoning, and reconsider.
Outright closing the bug feels just completely disrespectful.

These broken and surprising defaults, and even more surprising differences
between platforms that result from the broken defaults have cost the whole
industry presumably multi-million-dollar figures of money over the last decade,
and will continue to do so forever, if nothing gets actually fixed. And if you
want to disregard that argument because I cannot prove it, fine. I myself have
wasted probably days of my life with these quirks. I honestly cannot remember
which platform wants -pthread, which platform needs -lpthreads, which platform
needs -latomic, which platform wants -lm, which platform does not provide -lm
at all. It's a complete mess, and gcc is in the position to fix it, because it
*knows*.

Changing back to UNCONFIRMED so that *other* people can have a look.

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

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
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.

>gcc libstdc++ implements std::thread. So what's your point again?

Because it implements it on top of pthreads. While C threads is implemented
inside the libc.

I still think this should not be done on the GCC side as it is changing/fixing
on the glibc side of things already.

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

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement

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

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
>You did not address any of the standard violating behavior concerning advertising thread support at all.

There is no standard violating behavior with respect to thread support. Again
the C/C++ standard don't say how you invoke the compiler. POSIX has a section
on that but as I mentioned that is a different story all together.

In the case of mingw, the problem is how GCC was configured:
#ifndef THREAD_MODEL_SPEC
      /* Targets that define THREAD_MODEL_SPEC need to define
         __STDCPP_THREADS__ in their config/XXX/XXX-c.c themselves.  */
      if (cxx_dialect >= cxx11 && strcmp (thread_model, "single") != 0)
        cpp_define (pfile, "__STDCPP_THREADS__=1");
#endif

Which means add -mthread will not fix the issue there. You need to get a GCC
which is configured correctly to not to be single threaded.

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

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
If you want __STDC_NO_THREADS defined file a bug about that but gcc will need
to record which versions of glibc has C11 thread defined or not.
You could use __has_include extension which will handle that mostly for you
really.

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

[schwab@linux-m68k.org]

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

--- Comment #7 from Andreas Schwab <schwab@linux-m68k.org> ---
This is only a matter of QoI and/or documentation.

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

[manx-bugzilla at problemloesungsmaschine dot de]

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

--- Comment #8 from Jörn Heusipp <manx-bugzilla at problemloesungsmaschine dot de> ---

> 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.

> >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.

> While C threads is implemented
> inside the libc.

If it was implemented in libc, I would not be seeing "c11.c:(.text+0x53):
undefined reference to `thrd_create'". Something is wrong with your argument. I
actually do not know where it is implemented. And I should not be needing to
know. Again, you are supporting my point.

> If you want __STDC_NO_THREADS defined file a bug about that but gcc will need to record which versions of glibc has C11 thread defined or not.

The compiler is required to know that by the C standard.

> You could use __has_include extension which will handle that mostly for you really.

That's not how the C standard specifies to do to check for thread support.

> I still think this should not be done on the GCC side as it is
> changing/fixing on the glibc side of things already.

There are more platforms that GCC targets than just glibc. glibc alone cannot
fix the general case.

> In the case of mingw, the problem is how GCC was configured:

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? That seems like a broken configuration to me
that gcc should not allow to be buildable, which looks like a bug to me. (or I
am misunderstanding what you are saying)

[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.

[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 #10 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #9)
> (In reply to Jörn Heusipp from comment #8)

> > 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.

Oh I missed the part about __STDCPP_THREADS__ not being defined for mingw-w64.
That seems like it's worth a distinct bug report that can focus just on that.

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

[pinskia at gcc dot gnu.org]

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

--- Comment #11 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #10)
> Oh I missed the part about __STDCPP_THREADS__ not being defined for
> mingw-w64. That seems like it's worth a distinct bug report that can focus
> just on that.

I don't think that is a bug though because that mingw toolchain was configured
with --enable-threads=single in that case (so libstdc++ does not have the full
support). Most likely it needs to be configured with --enable-threads=win32 to
support that.

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

[pinskia at gcc dot gnu.org]

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

--- Comment #12 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
See also
https://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/29e406ed.c6291.1541803dcf9.Coremail.lh_mouse%40126.com/
.
Mingw thread support is always lacking behind because there are not enough
developers doing development there so ....

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

[manx-bugzilla at problemloesungsmaschine dot de]

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

--- Comment #13 from Jörn Heusipp <manx-bugzilla at problemloesungsmaschine dot de> ---
(In reply to Jonathan Wakely from comment #10)

> Oh I missed the part about __STDCPP_THREADS__ not being defined for
> mingw-w64. That seems like it's worth a distinct bug report that can focus
> just on that.

I have reported https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003382 for
the debian package.

[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 #14 from Jonathan Wakely <redi at gcc dot gnu.org> ---
What is the output of x86_64-w64-mingw32-g++-posix -v

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

[manx-bugzilla at problemloesungsmaschine dot de]

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

--- Comment #15 from Jörn Heusipp <manx-bugzilla at problemloesungsmaschine dot de> ---
(In reply to Jonathan Wakely from comment #14)
> What is the output of x86_64-w64-mingw32-g++-posix -v

manx@appendix:~$ x86_64-w64-mingw32-g++-posix -v
Using built-in specs.
COLLECT_GCC=x86_64-w64-mingw32-g++-posix
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-w64-mingw32/10-posix/lto-wrapper
Target: x86_64-w64-mingw32
Configured with: ../../src/configure --build=x86_64-linux-gnu --prefix=/usr
--includedir='/usr/include' --mandir='/usr/share/man'
--infodir='/usr/share/info' --sysconfdir=/etc --localstatedir=/var
--disable-option-checking --disable-silent-rules
--libdir='/usr/lib/x86_64-linux-gnu' --libexecdir='/usr/lib/x86_64-linux-gnu'
--disable-maintainer-mode --disable-dependency-tracking --prefix=/usr
--enable-shared --enable-static --disable-multilib --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --libdir=/usr/lib
--enable-libstdcxx-time=yes --with-tune=generic --with-headers
--enable-version-specific-runtime-libs --enable-fully-dynamic-string
--enable-libgomp --enable-languages=c,c++,fortran,objc,obj-c++,ada --enable-lto
--enable-threads=posix --program-suffix=-posix
--program-prefix=x86_64-w64-mingw32- --target=x86_64-w64-mingw32
--with-as=/usr/bin/x86_64-w64-mingw32-as
--with-ld=/usr/bin/x86_64-w64-mingw32-ld --enable-libatomic
--enable-libstdcxx-filesystem-ts=yes --enable-dependency-tracking
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10-posix 20210110 (GCC)
manx@appendix:~$

[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 #16 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jörn Heusipp from comment #15)
> --enable-threads=posix --program-suffix=-posix

Then it should be defining __STDCPP_THREADS__=1, odd.

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

[manx-bugzilla at problemloesungsmaschine dot de]

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

--- Comment #17 from Jörn Heusipp <manx-bugzilla at problemloesungsmaschine dot de> ---

(In reply to Jonathan Wakely from comment #9)
> (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.

The overall problem hurts users the most when porting between different
platforms, thus major platforms having one way of doing things that will not
work on minor platforms does not really solve the problem. This frustrates
users. And that is what I am (amongst other things) intending to address here.
And it's not really fixing itself. Others fix it, because GCC thus far has
refused to fix it.
Also, what about libm?



About POSIX, as brought up in the atomics issue: I do not particularly care
what POSIX allows or demands. My software also targets multiple platforms that
are not POSIX. I use GCC on platforms that are not POSIX. If POSIX proposes a
bad and broken interface, that is not a reason to only do it as bad as even
remotely allowed by POSIX. Only because POSIX does not *require* you to
auto-link -lm, this does not imply that POSIX *forbids* you to do so.



threads:

> > > >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.

Thanks for the explanation, however I feel this indeed is a pure
quality-of-implementation issue and in particular still very much an
implementation detail, and thus something GCC or the platform should solve
themselves, instead of offloading the problem of knowing about such intricate
details onto the user.

This questionable (see later) optimization also completely misses the common
case of using a shared_ptr in a multi-threaded application but only in a
limited single-thread context (which was the situation for almost every single
time I have ever used shared_ptr). C++ does need a non-thread-safe flavour of
std::shared_ptr, but that's an entirely different discussion, let's not go
there.
It certainly is not a reason to complicate things for the user.

> And with very recent versions, you don't
> need -pthread at all.

That's progress, however I still do need it on Debian Testing, which is about
as recent and bleeding edge as I am willing to invest time into.

And if it is so, and actually fixed in a "proper" way, what again is the reason
why GCC still wants to stick to the old way of doing things and offloads the
(now unneeded on modern platforms) knowledge requirement onto each user? If you
really think a platform-specific global flag in the C library is the proper
solution to detect multi-threadedness (I could not agree less, but that's not
really relevant here), just over-link on other platforms and put them under
pressure to adapt a similar solution (if they even care about this
optimization).
"The 'bug' is fixed, let's still hurt users with the work-around."

> > 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.

Isn't it still important for correctness in an application vs library situation
where one is multi-threaded and the other isn't? When considering C++11
threadsafe-statics, the compiler must always know whether the resulting binary
could ever be used multi-threaded, doesn't it? I think, it should, for
standards-compliance reasons, assume so, unless explicitly opted-out by the
user via -fno-threads as I suggested (indeed very similar in semantics and
implications as -fno-exceptions or -fno-rtti currently are, and it already
exists in a more limited form as -fno-threadsafe-statics). That however maybe
even more so implies that the user would be required to pass -pthread, even if
they, in their local context, might not even care about threads. Maybe. Or is
it always using threadsafe-initialization no matter what? I honestly do not
know. Documentation does not tell. (see below)

I actually do have precisely that use case: A shared library, which itself does
not touch any threads at all, however, in 1 place relies on C++11
thread-safe-statics in order to one-time-initialize some internal tables.

> 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

Well, I guess one could call it a "partially documented bug" :)

And it's not even accurately documented, it seems. It tells me that I need to
pass -pthread, however building my example for MinGW-w64-posix (after working
around the __STDCPP_THREADS__ issue) does not appear to require -pthread. It
builds and links and appears to work properly without it. Adding -pthread also
does not fix the missing __STDCPP_THREADS__ definition. So for MinGW-w64, it
does do the right thing and automatically links pthread. Why only there?
However, -mthreads is not automatically set for MinGW, and not documented at
the URL you linked, yet still required for standard compliance according to
other documentation?!? Why all these inconsistencies?
But, it actually turns out to not be required in the end, because it does
basically nothing whatsoever at all for MinGW-w64 (see below). Why does it even
exist there? Documentation is again seriously lacking.

> -latomic	Linking to libatomic is required for some uses of ISO C++11 <atomic>.

That also is not exactly precise. Which are these "some" uses? If GCC, as it
seems, is so concerned about not linking atomic ever when it is not strictly
required, yet it is giving users only a very vague indication of when it could
be required, the user is unable to make an informed decision here. If
overlinking is problematic, the user needs to know the precise conditions. If
it is not, GCC really should just link it.

Also, it's documented for libstdc++, so I do argue that GCC should have read
libstdc++'s documentation and acted accordingly to implement -std=c++17. It's
GCC (as in the driver, not the project) that is using libstdc++. It is thus
GCC's responsibility to drag in the required transitive dependencies. That's
how transitive dependencies are handled EVERYWHERE ELSE.


Let's look at all these thread-related options in detail, sorted by category as
in https://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html#Option-Summary

c++:

-fno-threadsafe-statics

> Do not emit the extra code to use the routines specified in the C++ ABI for thread-safe initialization of local statics. You can use this option to reduce code size slightly in code that doesn’t need to be thread-safe.

So I may deduce, that otherwise thread-safe initialization is always used, even
if !__STDCPP_THREADS__ (where it would not be required by the standard, I
think). Or may I not?!?
If we look at a platform that is actually single-threaded (DJGPP), it looks
like GCC is providing "threadsafe" statics even there by default, which is
useless.

optimization:

-fthread-jumps

> Perform optimizations that check to see if a jump branches to a location where another comparison subsumed by the first is found. If so, the first branch is redirected to either the destination of the second branch or a point immediately following it, depending on whether the condition is known to be true or false.

Not even thread-related. Unfortunate overloading of the same word.

preprocessor:

-pthread

> Define additional macros required for using the POSIX threads library. You should use this option consistently for both compilation and linking. This option is supported on GNU/Linux targets, most other Unix derivatives, and also on x86 Cygwin and MinGW targets.

Why does the user who is only using C11 thrd or C++11 std::thread need be know
that GCC (or the standard C library that GCC implies) implements these with
POSIX threads? That's an implementation detail. As a user, I am concluding,
that I do in fact not have to pass that option, because I myself am not using
POSIX threads whatsoever at all.
On which platforms does it define additional macros? And which ones? Does this
have implications for the C standard library headers? Does it have implications
for the C++ standard library headers? Does it have implications for
__STDC_NO_THREADS__ or __STDCPP_THREADS__?

linker:

-pthread

> Link with the POSIX threads library. This option is supported on GNU/Linux targets, most other Unix derivatives, and also on x86 Cygwin and MinGW targets. On some targets this option also sets flags for the preprocessor, so it should be used consistently for both compilation and linking.

See above.

-lpthread

Is that different to -pthread for the linker? If so, how? If not, why does
-pthread exist?

hppa:

-threads

> Add support for multithreading with the dce thread library under HP-UX. This option sets flags for both the preprocessor and linker.

Same issues as with -pthread.

solaris2:

-pthreads

> This is a synonym for -pthread.

I guess compatibility with sunc?

x86:

-mthreads

> Support thread-safe exception handling on MinGW. Programs that rely on thread-safe exception handling must compile and link all code with the -mthreads option. When compiling, -mthreads defines -D_MT; when linking, it links in a special thread helper library -lmingwthrd which cleans up per-thread exception-handling data.

Why is this not the default for a multi-threaded standard version? Or is it?
Documentation is not clear. Documentation is also arguably just wrong for
MinGW-w64 (see below).

x86 windows:

-mthread
-mthreads

Inconsistently documented as either -mthread
(<https://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html#Option-Summary>) or
-mthreads
(<https://gcc.gnu.org/onlinedocs/gcc/x86-Windows-Options.html#x86-Windows-Options>)

> This option is available for MinGW targets. It specifies that MinGW-specific thread support is to be used.

I would assume (based on Windows platform knowledge), that this could imply
linking the multi-threaded version of the MSVCRT library, however documentation
is rather vague in my opinion. However, the shared library version of the
MSVCRT only ever comes in a multi-threaded version.
Also, this is either the same option as the identically named -mthreads, or it
is not. The user is seriously confused here.

-mthread is not accepted by my MinGW GCC.
-mthreads does nothing. I did check the implementation: The only measurable
thing it actually does for MinGW-w64, is define _MT globally. This macro is
checked nowhere. And it is set by any MinGW-w64 C library header
unconditionally anyway. The mingwthrd library in MinGW-w64 does nothing:
<https://github.com/mirror/mingw-w64/blob/d8842c6f535a91698c3b26a8e5b86d0062ea340f/mingw-w64-crt/libsrc/mingwthrd_mt.c#L1>.
I did not check original MinGW thoroughly, however a quick test revealed that
even there, _CRT_MT (see
<https://github.com/gcc-mirror/gcc/blob/6795e6ae66096d52a62e20ed33a47599233ab3d5/libgcc/config/i386/gthr-win32.h#L370>)
is always !=0 for me.


I would not need to ask ***any*** of these question, if gcc, or at least -std=,
actually did the reasonable thing by default in the first place.



math:

> https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html
> -nolibc
> Do not use the C library or system libraries tightly coupled with it when linking. Still link with the startup files, libgcc or toolchain provided language support libraries such as libgnat, libgfortran or libstdc++ unless options preventing their inclusion are used as well. This typically removes -lc from the link command line, as well as system libraries that normally go with it and become meaningless when absence of a C library is assumed, for example -lpthread or -lm in some configurations. This is intended for bare-board targets when there is indeed no C library available.

The docs say, it would not auto-link libm and libpthread if I pass -nolibc,
however that really is only valuable information if it would actually do so by
default in the first place when not passing -nolibc. Given that math and
threads do belong to the standard, I still do think that these libraries should
be implied by default if required on the respective platform (and excluded with
-nolibc, as documented). GCC chooses the libc it links. It is thus responsible
to (if possible) make up for missing functionality in this libc.



atomics:

Oh, and what about the --as-needed argument brought up in the atomics issue? Do
you really think GCC itself should strive for minimal linking on a particular
platform that does not provide that facility at all in the first place? That's
solely a platform issue, and nothing GCC has to worry about. It is even
completely irrelevant for correctness. This whole argument is just pre-mature
optimization. Linking a huge glibc.so (50% of which is random POSIX and kernel
stuff that I did not even ask for) and libstdc++.so, and then over-engineering
around and argueing about a 30kB/~110symbols library for atomics? I mean,
REALLY?
I assume the real reason here is again wider atomics dragging in POSIX locks.
And the actual real problem, again, is C++ missing a shared_ptr optimized for
single-threaded usage.
Please name only one single program, that *requires atomics*, and *is not using
wide atomics*, and *is single-threaded*, and *uses shared_ptr*, and *cares
about shared_ptr performance*, and *is not important enough to suggest a
non-atomic-refcount shared_ptr for ISO C++*. Name only 1. Because that is the
absurdly narrow case you are optimizing for here, and burdening the user with
your implementation details for. It really makes no sense. If you are unable to
provide an optimization without requiring user knowledge in the
non-optimization case, the correct solution is to not provide that optimization
by default, but only when a user specifically asks for it. The few people
desiring the optimized single-threaded shared_ptr are currently benefiting from
that optimization at the cost of everyone else. That's a wrong tradeoff to
make.



> I understand your complaint, but I think it's unlikely we're going to change
> anything in GCC.
> You're complaining about something we don't aim for anyway.
> This isn't ideal, but it's not easy to fix. And as already stated, some
> platforms are changing so it Just Works anyway.

Thanks for acknowledging the problem. However it's sad that you still do not
appear to realize the amount of grief it causes for users. I honestly think you
should aim for solving these issues. Currently, everything related to these
issues gets offloaded onto every single user. Solving it in the one single
place that inevitably already needs to know these details anyway would be a
more scalable solution for everyone.



All these issues are a tremendous user experience nightmare, and it sadly looks
like I absolutely have to point out every single one of them explicitly by
asking every single detail question possible, so that you actually can in fact
feel and realize the mess you have created for users to deal with. It ***IS***
a bug, and it's not primarily about documentation. It's about sane defaults.
The mess GCC has created here wastes every user's time. You seem to expect
users to know all the intricate details about every platform that you sometimes
have documented in a few words without further explanation, and sometimes not
even that. That's honestly not a reasonable expectation in my opinion. All
these are implementation details that a user of the ISO standards should not
need to have to know about. That's seriously not how standards are supposed to
be used. Standards exist to shield users from implementation details.

[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 #18 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jörn Heusipp from comment #17)
> All these issues are a tremendous user experience nightmare,

OK.

 and it sadly
> looks like I absolutely have to point out every single one of them
> explicitly by asking every single detail question possible, so that you
> actually can in fact feel and realize the mess you have created for users to
> deal with.

I think you'll just make people ignore your pages of ranting.

Patches to improve the docs are welcome.

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

[frankhb1989 at gmail dot com]

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

frankhb1989 at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |frankhb1989 at gmail dot com

--- Comment #19 from frankhb1989 at gmail dot com ---
(In reply to Jonathan Wakely from comment #18)
> (In reply to Jörn Heusipp from comment #17)
> > All these issues are a tremendous user experience nightmare,
> 
> OK.
> 
>  and it sadly
> > looks like I absolutely have to point out every single one of them
> > explicitly by asking every single detail question possible, so that you
> > actually can in fact feel and realize the mess you have created for users to
> > deal with.
> 
> I think you'll just make people ignore your pages of ranting.
> 
> Patches to improve the docs are welcome.

It may be quite difficult to improve the docs without the first step from the
maintainers to make the sensible default clear enough. Anyway, whether the
issue a bug or an enhancement depends on how the spec says, but this does not
work when the spec in the doc is just missing. Besides the supported standards
(which are specs), users have to guess what features are expected by default,
or silently accept the status quo (everything is by design). This will need
additional communication between the maintainers to prevent real bugs being
ignored, hence, inefficient and error-prone.

This even happens when the spec is clear. For example, [intro.multithread]/1
explicitly allows the programs under a hosted implementation having concurrent
threads (not in C++98/03, though), and whether multi-threading is supported in
a freestanding implementation is implementation-defined. As I've checked
(https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Implementation.html) this entry
is missing, which is a bug because it fails to meet the mandated requirements
for conformance in the spec (the standard). However, usually users have no
enough knowledge to fix it. Virtually only the maintainers know what should be
here. No *policies* are visible for others.

In this issue, about the some parts of C++, silent degradation of performance
is certainly bad, so keeping `-pthread` away by default makes sense, esp. for
programs without knowledge of multi-threading environment (which can be at
least conforming to C++98/03) as the assumptions. It is also not a bug in the
sense that the standard actually allows single-threading if the doc bug above
is fixed (with the acknowledgement that single-thread model for host
implementations are not conforming after C++03). However, chasing for
performance over other concerns cannot be the policy in general. In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100937 the direction is actually
the opposite. AFIAK all the primary platforms in the release criteria
(https://gcc.gnu.org/gcc-14/criteria.html) support ELF and (most of) POSIX, so
it seems that preventing to sacrifice the features available on these platforms
is one of the candidate of the policies. But this is just my guess, and
specific for the releases; I fail to find any closer to guarantees in other GCC
docs. So, please clarify such concerned meta issues to reduce potential
disagreements at first.

[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 #20 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to frankhb1989 from comment #19)
> It may be quite difficult to improve the docs without the first step from
> the maintainers to make the sensible default clear enough. Anyway, whether
> the issue a bug or an enhancement depends on how the spec says, but this
> does not work when the spec in the doc is just missing.

What does "when the spec in the doc is just missing" mean?

> Besides the
> supported standards (which are specs), users have to guess what features are
> expected by default, or silently accept the status quo (everything is by
> design). This will need additional communication between the maintainers to
> prevent real bugs being ignored, hence, inefficient and error-prone.

What **concrete** issue are you talking about? I see nothing actionable in what
you've written above. We need communication ... OK. The maintainers
communicate. What are you expecting to happen?

> This even happens when the spec is clear. For example, [intro.multithread]/1
> explicitly allows the programs under a hosted implementation having
> concurrent threads (not in C++98/03, though), and whether multi-threading is
> supported in a freestanding implementation is implementation-defined. As
> I've checked
> (https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Implementation.html) this
> entry is missing, which is a bug because it fails to meet the mandated
> requirements for conformance in the spec (the standard).

It fails to meet the requirements for a freestanding implementation, yes. But
not for a hosted implementation.

If you have concrete suggestions for changes to the docs, please make them.
This bug report is just long, unfocused complaints and so is not going to
achieve much.

> However, usually
> users have no enough knowledge to fix it. Virtually only the maintainers
> know what should be here. No *policies* are visible for others.

Well it should be pretty obvious from other docs that --enable-threads=single
means no threads (for both hosted and freestanding). What "policies" are you
asking for?

> In this issue, about the some parts of C++, silent degradation of
> performance is certainly bad, so keeping `-pthread` away by default makes
> sense, esp. for programs without knowledge of multi-threading environment
> (which can be at least conforming to C++98/03) as the assumptions. It is
> also not a bug in the sense that the standard actually allows
> single-threading if the doc bug above is fixed (with the acknowledgement
> that single-thread model for host implementations are not conforming after
> C++03).

If you configure GCC in a non-conforming configuration then it's
non-conforming. That's not a bug. If you don't want threads to be disabled,
don't disable them when configuring GCC. If you got a build of GCC from
somebody else and they configured it in a non-conforming way, you should talk
to them. It's not a GCC bug.

Anyway, the standard doesn't require that new threads can actually be created,
it's always possible for the std::thread constructor to fail due to reaching
resource limits, and it's conforming for the limit to be a single thread in the
program.

> However, chasing for performance over other concerns cannot be the
> policy in general. In https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100937
> the direction is actually the opposite. AFIAK all the primary platforms in
> the release criteria (https://gcc.gnu.org/gcc-14/criteria.html) support ELF
> and (most of) POSIX, so it seems that preventing to sacrifice the features
> available on these platforms is one of the candidate of the policies. But
> this is just my guess, and specific for the releases; I fail to find any
> closer to guarantees in other GCC docs. So, please clarify such concerned
> meta issues to reduce potential disagreements at first.

I have absolutely no idea what you're saying here.

As stated previously, the standard doesn't say you the compiler needs to be
invoked, and GCC never claims that -std=c11 is sufficient to link to libm. It
might be an improvement if the GCC manual documented that additional options
such as -lm or -pthread might be needed for a conforming environment, and that
some parts of "the implementation" need to be provided outside of GCC, e.g. by
your OS libc (as stated previously, the C++ library already *does* document
that -pthread might be required for std::thread support).

It's nonsense to suggest that only maintainers can make such changes to the
docs, since it's clear and obvious that GCC does not provide everything the
standard refers to as "the implementation", that doesn't require specialized
knowledge.

Unfocused ranting and complaining isn't going to achieve anything. If you're
not happy with the docs, suggest changes.

I'm inclined to close this bug because there is nothing actionable here (except
"make everything work how I want when I say -std=c11" which seems unlikely to
happen).

[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 #21 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #20)
> It's nonsense to suggest that only maintainers can make such changes to the
> docs, since it's clear and obvious that GCC does not provide everything the
> standard refers to as "the implementation", that doesn't require specialized
> knowledge.
> 
> Unfocused ranting and complaining isn't going to achieve anything. If you're
> not happy with the docs, suggest changes.

For example, anybody could propose something like this:

--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -136,6 +136,14 @@ designated by @var{byte-size} in the following text. 
Refer to the NIST,
 IEC, and other relevant national and international standards for the full
 listing and explanation of the binary and decimal byte size prefixes.

+GCC only provides part of what the C and C++ standards refer to as
+"an implementation" of the language. To get a conforming hosted implementation
+it is necessary to combine GCC with a C library, libc, which is usually part
+of the operating system, e.g., the GNU C Library provides libc for GNU/Linux
+systems. Some C and C++ programs might require linking to additional libraries
+in order to get a complete hosted implementation, e.g., @option{-lm},
+@option{-latomic}, and @option{-pthread} may be required in some cases.
+
 @c man end

 @xref{Option Index}, for an index to GCC's options.


I'm sure this could be improved, but it's a concrete suggestion instead of
unfocused complaints.