RFR: 8301244: Replace legacy pragma implementations in HotSpot's compilerWarnings.hpp [v7]

[Julian Waters]

On Sun, 29 Jan 2023 06:38:19 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> HotSpot has a few legacy implementations of pragmas in some of its macros in compilerWarnings.hpp, they should be cleaned up and use a more modern approach. Rename PRAGMA macro in compilerWarnings_gcc.hpp as well since it can be used for more than just compiler warnings
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   compilerWarnings_gcc.hpp

The aim was to introduce a way to easily use pragmas inside macro implementations in HotSpot which behave identically to if one had used `#pragma`, regardless of any quirks on any platform/compiler, competing with the regular `#pragma` preprocessor directive is otherwise not the goal of this change. Defining differing pragmas which are compiler specific based on `#ifdef` blocks are a different issue too, all this proposal intends to do is make it easy for defining pragmas inside macros, as mentioned above. The vast majority of the compilers that can be used to compile HotSpot (that is to say, all of them except for Visual C++) don't have an easy way to do this that doesn't involve the hassle of defining one-off helper macros directly where they're used to expand the input to properly feed into `_Pragma` (see compilerWarnings_gcc.hpp for instance).  I get that this might sound slightly petty, but I'd prefer if macros defined for the sole purpose of solving a local issue were somewhat 
 kept to a minimum in HotSpot if they could be avoided. This can also be especially helpful in shared code where a one-for-all macro that contains a pragma is needed, where there is much less incentive for deciding on using __pragma or not. Regarding Kim's concerns, I could indeed make the implementation use __pragma if `#ifdef _MSC_VER` is true, but I don't really see the need for doing that, since Visual C++ pretty much treats __pragma and `_Pragma` identically (to the point that they share the same bugs), and doing so would just be extra code which would behave the same

I forgot to mention `PRAGMA_UTIL` was just `PRAGMA` earlier on and in macros.hpp, I changed it after hearing Kim's concerns, but now after looking back at it I think I should've kept it for review

-------------

PR: https://git.openjdk.org/jdk/pull/12255