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