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.
