See https://bugs.gentoo.org/955114#c2.
x86 done
arm64 done
arm done
ppc64 done
ppc done
hppa done
FYI: I want to note that gperf-3.3 (and probably 3.2.1) generate new conditional code to put "[[fallthrough]];" before various places that intentionally pass through from one "case" to another in a "switch" block, to suppress related warnings. But this may conflict with some build systems that may modify the generated code to do something similar before trying to compile it, ending up with two such "[[fallthrough]];"'s, which is an outright compiler error (not just a warning). For example chromium or qtwebengine (at least some versions); see bug #953436. There are various obvious possible workarounds if you encounter this in a specific environment, but I haven't tracked down the "cleanest" way to achieve portability (version-agnostic) to avoid both warnings (gperf-3.1.2) AND errors (gperf-3.2.1+), automatically in different environments. (Commentary: I'm not sure how common the warning is; perhaps 953436's approach of letting the old version warn isn't too bad. Generally, this kind of "can't easily avoid warning in one environment without completely breaking other environments" does not seem very common in my experience. Although some years ago I wrote my own std::auto_ptr replacement (it is not large) when some compilers started warning about it, but other compilers didn't have std::unique_ptr yet...) ---- Possibly no action: There probably isn't much (if anything) Gentoo developers can or should do about this to support non-portage-managed build systems. Perhaps it would make sense to keep the previous version (3.1-r2) in the tree (but not the default) for a while to allow users more flexibility about when they declare a transition flag day? Although (a) temporarily masking the new version is only one possible workaround, and (b) they could always copy the previous version ebuild into their own overlay, if they go with this general approach at all...
Well, I won't hurry to clean it up, but I'm not particularly worried about the case you mention either.. we're only aware of qtwebengine+chromium being affected and both were using the same tool to do that (qtwebengine inheriting it from chromium). But users are free to put the version in a local repository if they want to stick with it as well. The fixes should also always be easy?
i.e. If one is really bothered by it, you can always pass -Wno-x to the generated output. But I'll try to keep it around for a while.
