On Thu, 7 Sep 2023 18:35:29 GMT, Kim Barrett <kbarr...@openjdk.org> wrote:
>> Just for the record, this is very likely >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104475 . > > I'd like to not disable the warnings without a better understanding of the > problem. I agree with @theRealAph that gcc > bug 104475 is likely where the warning is coming from. But it may be that > giving gcc better control flow information > via appropriate `[[noreturn]]` or (something like) `std::unreachable()` might > be better. @kimbarrett @erikj79 Thanks for taking a look. > Generally when we disable warnings, we document in the bug why the warning is > benign or incorrect in this case, or file a followup bug to address it > properly. > I'd like to not disable the warnings without a better understanding of the > problem. I understand. I just can't figure out what's causing this. The call is a few nested templates and I don't understand why the type passed to the outermost one ends up as `void*` in the innermost one. > The fix for [JDK-8294031](https://bugs.openjdk.org/browse/JDK-8294031) was to > make various error reporting functions `[[noreturn]]`. Is there perhaps a > missing `[[noreturn]]` in the RISC-V code? I don't think the issue is RISC-V-specific. It's in two shared files (`xPageAllocator.cpp` and `zPageAllocator.cpp`). > Also, does the failure happen in release builds, or only (fast)debug builds? Both. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15593#issuecomment-1710783702
