https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112896
Edwin Lu <ewlu at rivosinc dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ewlu at rivosinc dot com
--- Comment #1 from Edwin Lu <ewlu at rivosinc dot com> ---
(In reply to Li Pan from comment #0)
> The gcc.dg/pr30957-1.c test case is failed in RISC-V backend when build with
> below options.
>
> -march=rv64gcv_zvl1024b_zvfh_zfh -mabi=lp64d -O2 -mcmodel=medlow
> --param=riscv-autovec-preference=fixed-vlmax -funroll-loops
> -fassociative-math -fno-trapping-math -fno-signed-zeros
> -fvariable-expansion-in-unroller -fdump-rtl-expand-details -lm
> gcc/testsuite/gcc.dg/pr30957-1.c -o test.elf
>
> The test gcc/testsuite/gcc.dg/pr30957-1.c may be similar as below.
>
> float __attribute__((noinline))
> foo (float d, int n)
> {
> unsigned i;
> float accum = d;
>
> for (i = 0; i < n; i++)
> accum += d;
>
> return accum;
> }
>
> int
> main ()
> {
> /* When compiling standard compliant we expect foo to return -0.0. But the
> variable expansion during unrolling optimization (for this testcase
> enabled
> by non-compliant -fassociative-math) instantiates copy(s) of the
> accumulator which it initializes with +0.0. Hence we expect that foo
> returns +0.0. */
> if (__builtin_copysignf (1.0, foo (0.0 / -5.0, 10)) != 1.0)
> abort ();
> exit (0);
> }
>
> Have an initial investigation that RISC-V backend always get LPT_NONE when
> unroll_loops, as the step of loop will be dynamic after vectorizing, and get
> the simple loop flag as false, then the pass unroll_loops will do nothing
> for non simple loop.
>
> We may need further investigation for this case.
Our postcommit ci recently identified the testcase aborts on several other
configurations now.
Additional targets (linux and newlib):
- rv64gcv
- rv64 Vector Crypto
- rv64 RVA23U64 Profile
Logs and testsuite report can be found
https://github.com/patrick-rivos/gcc-postcommit-ci/issues/290
