OpenCL C spec editorial fixes

[bashbaug]

Editorial fixes for the OpenCL C spec. There are no functional changes.

I'm not super happy with the way the Asciidoctor attributes for the OpenCL C features worked out, especially how the attribute names don't have the double-underscore prefix, but Asciidoctor seemed to be tripping over the attributes when they had the prefix. I think this is workable for now, and Table 8. Address space behavior flows much better with the zero-width spaces, but this is definitely an area to revisit.

[Oblomov]

I think I've seen other reports in AsciiDoc about the handling of double-underscores. I'll try to give a look at it to see if I can solve the thing in a satisfactory way.

EDIT: I think I'm missing something, but most double-underscore usages are already properly escaped, and render correctly, that I can see (I did spot a couple that can be fixed, and I will provide a PR for them momentarily). Which attribute are missing the __?

[AnastasiaStulova]

Very nice improvements! Thanks... just a few small corrections/comments.

[bashbaug]

EDIT: I think I'm missing something, but most double-underscore usages are already properly escaped, and render correctly, that I can see (I did spot a couple that can be fixed, and I will provide a PR for them momentarily). Which attribute are missing the __?

Sorry bout that, I should have been clearer.

The rendering is all OK in the spec outputs, but I had to remove the double-underscore prefix from the attribute names in the spec sources, which is a touch confusing. Example:

OpenCL C compilers that define the feature macro {opencl_c_3d_image_writes}
must also define the feature macro {opencl_c_images}.

I would have rather written this as:

OpenCL C compilers that define the feature macro {__opencl_c_3d_image_writes}
must also define the feature macro {__opencl_c_images}.

This mostly worked, but some of the attributes didn't get substituted properly with the double-underscore prefix, and I couldn't figure out why it worked in some cases and not in others, even for the same feature attribute.

As a related aside, I really wanted to use the +TEXT+ syntax in the attribute name:

:opencl_c_3d_image_writes: pass:q[`+__opencl_c_<wbr>3d_<wbr>image_<wbr>writes+`]

vs. \ escaping the attribute name:

:opencl_c_3d_image_writes: pass:q[`\__opencl_c_<wbr>3d_<wbr>image_<wbr>writes`]

But this also didn't work, and I ended up with + in the rendered text.

Note, I didn't test the latest versions of Asciidoctor, so it's possible some of this behavior is a bug that has since been fixed.

[alycm]

LGTM.

[alycm]

Suggested change

	Program scope variables or variables with a `extern` or `static` storage class
	Program scope variables or variables with an `extern` or `static` storage class

[Oblomov]

@bashbaug I see, thanks for the clarification. My understanding is that double-underscores usually fail when more than one are in the same line of text.. Anyway, I have some commits that fix up some of the uses for existing macros and tries to uniformize some of the usages, I'll set it up in a PR for review.