Re: GCC commandline option names for thread support

[David Edelsohn <dje at watson dot ibm dot com>]

>>>>> "Martin v Loewis" writes:

Martin> It seems like a good idea to have a standard option when the library
Martin> being used is the Posix threads library. However, on some targets
Martin> (e.g. Solaris), you have two different libraries, so you need two
Martin> different options. Furthermore, on some targets, gcc would link a
Martin> thread library, but it won't be pthreads. I don't know how intuitive
Martin> it would be to call the option -pthread in this case; perhaps this is
Martin> what you meant with "bite the bullet"?

	Currently we have -pthread, -pthreads, -threads, and -mthreads.
If we want to accept -pthread and -pthreads (or even -pthread*) only for
pthreads, that is fine.

	I would like to define the GCC commandline namespace, e.g.

	-pthread: pthreads
	-threads: platform-dependent threads

where those two options are documented and are guaranteed to be reserved
options in the GCC driver commandline namespace.

	OR

move all thread definitions into the "-m" range, e.g. -mthreads and
-mpthread. 

	The current ad hoc spillage into the gcc commandline namespace is
bad, IMHO.  The rules seem to be: 1) "-m" for options that the compiler
needs to know about and any time one can utilize SUBTARGET_SWITCHES /
SUBTARGET_OVERRIDE_OPTIONS.  2) Any other option letters when they are
available, regardless of the precedent that sets and the complexity that
may introduce later.

	Targets should not be allowed the entire, unused commandline
namespace to define as they please.  Commandline options should be
documented.  I thought that "-m" was the namespace for target options.  If
we want to expand that to include -pthread and -threads, that is fine, but
we should define that convention.

David