[cfe-commits] [PATCH] First OpenMP patch

[Douglas Gregor]

On Dec 19, 2012, at 3:30 AM, Dmitri Gribenko <gribozavr at gmail.com> wrote:

> On Wed, Dec 19, 2012 at 1:02 PM, Alexey Bataev <a.bataev at gmx.com> wrote:
>> Dmitry, thanks for a good advice about :option:. Fixed patch is in the
>> attach.
> 
> LGTM.  I think that there is a consensus about command line flags and
> warnings, so this can go in.

Sorry to come late to the party, but I think this is the wrong approach for our users. Our current behavior is that we simply drop "-fopenmp". If we change that behavior to 

	warning: Experimental OpenMP support enabled

how have we helped the user? At best, it does nothing and they ignore the warning. At worst, it opens up a ton of questions: should I depend on the experimental implementation? What does it actually do? What was it doing before? How do I shut this warning off? This is especially important to consider for options like -fopenmp that currently exist for GNU compatibility. Changing the behavior in any way other than actually implementing that functionality is not a net win for users.

All we need for OpenMP at this stage is a new LangOpt for OpenMP (which is part of the patch) and a -cc1 option "-fopenmp" that turns on that LangOpt. It also makes sense to define _OPENMP when that LangOpt is true, so that we can write a test for -fopenmp.

It is very important that "-fopenmp" still be dropped by the driver. The -fopenmp at the -cc1 level will be separate, and used for our testing. Once OpenMP is actually usable, we can wire the driver's -fopenmp up to the -cc1 -fopenmp.

As noted elsewhere, we need a design document to discuss, and when we roughly agree on what's in there, it should go into the repository under "docs" and evolve from a design document to an internals document. There's no point in having a stub for user-level documentation of OpenMP support; that can come later, when we actually have something for users to use.


	- Doug