Distinguish processor-specific directives

[everythingfunctional]

25-142r1, 3.10 The processor-dependent directive

As specified, there exists potential problems in the future if more directives are added to the standard. If some compilers start defining their own directives, it may become tricky to work around those and standardize new ones. Not sure how likely that is or how much we should worry about it, but you may want to just start by requiring processor dependent directives to start with a single underscore. I.e example syntax # _ token-list EOL

[everythingfunctional]

To followup, as noted by @sblionel:

We do have that problem with intrinsics already, but it is a good idea to have a rule for distinguishing them. On the other hand, two different processors may choose to add the same-spelled directives that do different things.

and response by Patrick Fasano:

I think as soon as the programmer starts using processor-dependent directives, it's the programmer's responsibility to make sure it does what they think it does

To which I responded:

The problem is if a programmer starts using processor-dependent directives, and later a directive with the same spelling is added to the standard.

As Steve pointed out, the same problem already exists for intrinsic procedures, but we have scoping and the intrinsic statement to work around that. A similar solution for directives might be trickier to design.

And response from @sblionel:

Same issue for !DIR$ type compiler directives. We could recommend adding some sort of processor-specific prefix. I don't really like it but can't think of a better idea.

[gklimowicz]

Since C 1999, the sum total of the requirement is "A non-directive shall not begin with any of the directive names appearing in the syntax."

Their "non-directive" is what we call the "processor-dependent directive".

I'm usually not inclined to solve a problem in Fortran preprocessing that C has lived with for 26 years.

(My obvious exception to that rule is recognizing [ and ], and (/ and /) as bracketing symbols that must balance in function-like macro actual arguments. C botched this badly, I think. @bonachea filed #63 for us to do correctly in Fortran.)

[gklimowicz]

In discussion with @bonachea and @kc9jud today, we thought it might be good to add (in edits) a Note that advises implementations to use some implementation-specific prefix (such as _gnu_) for their processor-specific directives.