On Fri, 29 May 2026 06:43:54 GMT, Jatin Bhateja <[email protected]> wrote:
>> @jbhateja BTW: the fuzzer is not yet fully ready and reviewed - there are >> some design questions over there. >> >> So I'm worried that if we now integrated this PR here, and took more time >> for the fuzzer, the fuzzer would really have very little to no time to find >> issues. > >> @jbhateja BTW: the fuzzer is not yet fully ready and reviewed - there are >> some design questions over there. >> >> So I'm worried that if we now integrated this PR here, and took more time >> for the fuzzer, the fuzzer would really have very little to no time to find >> issues. > > Hi @eme64, > > First, thanks for building the template fuzzer — it has consistently proven > to be an excellent tool for catching subtle codegen bugs, and we genuinely > appreciate the effort you've put into it. That work is highly valued. > > That said, the fuzzer (#30997) is tracked separately from this PR, and any > Float16-related issues it surfaces will be triaged and fixed in exactly the > same way we handle fuzzer-found issues for the other lane types today. The > in-tree validation in this PR already meets the bar we apply to other Vector > API types > > Best Regards @jatin-bhateja Just because it meets the bar we apply to other Vector API types does not mean it meets the bar to rush into JDK27. In fact, as our bar for integration keeps being raised due to both the JDK and the Vector API becoming more and more mature, it is only natural that what was accepted in the past may not be accepted now. In general, we often freeze the integration of improvements when we are close to branching off, this time it is also due to the incoming Valhalla. As a result, I don't see a reason for this PR to be an exception. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-4571789694
