[Gomp-discuss] Re: Implementing OpenMP pragmas for the C frontend

[Per Bothner]

Steven Bosscher wrote:
> Some public standards are supported by the major compiler vendors, some
> are not.  OpenMP is one of those standards that *is* supported, probably
> because it was designed by the compiler vendors (OpenMP Review Board
> members: HP, Fujitsu, IBM, Intel, KAI, SGI, Sun, US Gov.(DEO))

That does not guarantee it's a good or clean standard, or that it
makes sense as a programming language standard.  Except for KAI (and
DEO - should that be DoE?) all of these are huge companies primarily
interested in selling hardware.  My "rebuttable assumption" is that
most (not all) of the committee were numerical people or hardware
people, neither of which group is known for good programming-language
design.

It also does not guarantee that it will be extensively used or
implemented.  Remember DSSSL.

Note - I'm not saying it's a bad design, nor that people shouldn't
implement it.  But that it was designed by a committee is no
guarantee of quality, only that it will presumably be implementable
and hopefully useful.  However, remember C++:  That was designed by
a lot of very smart people, resulting in an excessingly complicated
language, even though each decision made sense individually.

> Why not?  What is wrong with accepting a much-requested feature, that is
> implemented by most other serious compilers?  Any technical objections
> apart from the #pragma/_Pragma() thing?

I was objecting to any suggestion that the gcc community "must"
support OpenMP, or any pre-accepting of an OpenMP contribution.
On the other hand, we should not pre-reject it either.

I encourge people to implement OpenMP using Gcc.  I have no
objection to creating a branch for it, as long as it is
recognized as experimental, with no presumption that it will
be merged with the main-line.  *After* it is mature, and has
proved itself useful, then we may consider merging it in.

This is is not to be taken as official - it is just my
opinion, which is uninformed (and I don't have time enough
to learn very much about it).
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/