On Wed, 16 Aug 2023 15:59:13 PDT (-0700), jeffreya...@gmail.com wrote:
On 8/16/23 07:50, Robin Dapp wrote:
But if it's a float16 precision issue then I would have expected both
the computations for the lhs and rhs values to have suffered
similarly.
Yeah, right. I didn't look closely enough. The problem is not the
reduction but the additional return-value conversion that is omitted
when calculating the reference value inline.
The attached is simpler and does the trick.
Regards
Robin
Subject: [PATCH v2] RISC-V: Fix reduc_strict_run-1 test case.
This patch fixes the reduc_strict_run-1 testcase by converting
the reference value to double and back to the tested type.
Without that omitted the implicit return-value conversion and
would produce a different result for _Float16.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/reduc/reduc_strict_run-1.c:
Perform type -> double -> type conversion for reference value.
OK
I'm not opposed to merging the test change, but I couldn't figure out
where in C the implicit conversion was coming from: as far as I can tell
the macros don't introduce any (it's "return _float16 * _float16"), I'd
had the patch open since last night but couldn't figure it out.
We get a bunch of half->single->half converting in the generated
assembly that smelled like we had a bug somewhere else, sorry if I'm
just missing something...
jeff