RFR: 8288048: Build failure with GCC 6 after JDK-8286562

[Kim Barrett]

On Wed, 8 Jun 2022 17:52:42 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8286562](https://bugs.openjdk.org/browse/JDK-8286562) added the `-Wstringop-overflow` pragma, which cannot be understood by GCC 6. There are already ways to make such pragmas conditional on GCC version.
> 
> Additional testing:
>  - [x] Linux x86_64 `fastdebug` build with GCC 6
>  - [x] Linux x86_64 `fastdebug` build with GCC 9
> 
> @YaSuenag, if you could test with GCC 12, that would be helpful.

So the `GCC diagnostic ignored` pragma doesn't ignore unknown warning options
the way `-Wno-xxx` is ignored for unknown `xxx` (unless there are other
warnings as well)? That's unfortunate, and kind of seems like a gcc bug. I
don't think there's an issue with it suppressing warnings for mistyped
options, since such a typo would lead to the warning one wants to suppress not
being suppressed, exposing the typo.  (Even if this were reported and such a
change were made, it wouldn't help with such an old compiler.)

The reason for using a specifically GCC disable there is because it's a
specifically GCC issue in this one place. Having to define a new macro for all
platforms for such a case seemed unwarranted. But the non-ignoring behavior
perhaps changes the calculation.

An alternative would be to disable `-Wunknown-pragmas` at the use-site, with a
comment about `-Wstringop-overflow` only being available since gcc7.

Another possibility would be to add `-Wunknown-pragmas` to the
PRAGMA_DISABLE_GCC_WARNING macro. (I think that's okay for the same reason I
think it would have been okay for gcc to ignore it in the first place.) But
maybe that's further than you want to (or should) go for the immediate issue,
and should instead be considered for a new RFE.

(And someday there should be a discussion about retiring support for older and
out of support versions of gcc.)

I *think* I have a mild preference for disabling `-Wunknown-pragmas` at the
use-site; uglifying the sole use-site to cope with a very specific issue at
that point seems maybe a little better than globally adding a new warning
ignorer (which may encourage future use rather than properly analyzing the
warnings; recall that most of the original warnings for this were addressed by
changing possibly questionable code).

But I won't insist on that approach, and am willing to accept this proposed
change as-is instead, hence marking it approved even though it's not my first
choice.

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

Marked as reviewed by kbarrett (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/9090