Cc: Christoph Lameter <clameter@...>, Paul Mackerras <paulus@...>, <heiko.carstens@...>, <horms@...>, Stefan Richter <stefanr@...>, Linux Kernel Mailing List <linux-kernel@...>, David Miller <davem@...>, Paul E. McKenney <paulmck@...>, Ilpo Järvinen <ilpo.jarvinen@...>, <ak@...>, <cfriesen@...>, <rpjday@...>, Netdev <netdev@...>, <jesper.juhl@...>, <linux-arch@...>, <zlynx@...>, Andrew Morton <akpm@...>, <schwidefsky@...>, Chris Snook <csnook@...>, Herbert Xu <herbert@...>, Linus Torvalds <torvalds@...>, <wensong@...>, <wjiang@...>
>> The documentation simply doesn't say "+m" is allowed. The code to
Easy.
The GCC documentation you're referring to is the user's manual.
See the blurb on the first page:
"This manual documents how to use the GNU compilers, as well as their
features and incompatibilities, and how to report bugs. It corresponds
to GCC version 4.3.0. The internals of the GNU compilers, including
how to port them to new targets and some information about how to write
front ends for new languages, are documented in a separate manual."
_How to use_. This documentation doesn't describe in minute detail
everything the compiler does (see the source code for that -- no, it
isn't described in the internals manual either).
If it doesn't tell you how to use "+m", and even tells you _not_ to
use it, maybe that is what it means to say? It doesn't mean "+m"
doesn't actually do something. It also doesn't mean it does what
you think it should do. It might do just that of course. But treating
writing C code as an empirical science isn't such a smart idea.
No need to guess at what you said, even if you managed to delete
your own mail already, there are plenty of free web-based archives
around. You said:
and that to me reads as complaining that the ISO C standard "isn't
very good" and that the GCC documentation is 10**5482 times worse
even. Which of course is hyperbole and cannot be true. It also
isn't helpful in any way or form for anyone on this list. I call
that whining.
Yes, documentation of that size often has shortcomings. No surprise
there. However, great effort is made to make it better documentation,
and especially to keep it up to date; if you find any errors or
omissions, please report them. There are many ways how to do that,
see the GCC homepage.</end-of-marketing-blurb>
You're allowed to say whatever you want. Let's have a quote again
shall we? I said:
I read that as a friendly request, not a prohibition. Well maybe
not actually friendly, more a bit angry. A request, either way.
"Problem report", a bugzilla ticket. Sorry for using terminology
unknown to you.
Actually not -- PRs make sure issues aren't forgotten (although
they might gather dust, sure). But yes, submitting patches is a
Great Thing(tm).
When code like you want to write becomes a supported feature, that
will be reflected in the user manual. It is completely nonsensical
to expect everything that is *not* a supported feature to be mentioned
there.
Hey, maybe that character trait is good for something, then.
Now to build a business plan around it...
Segher
-
