https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123870
--- Comment #12 from Robin Dapp <rdapp at gcc dot gnu.org> ---
(In reply to Ilya Kurdyukov from comment #11)
> I tried gcc-16, ICE (validate_change_or_fail) disappeared.
>
> > gcc version 16.0.0 20251214 (experimental)
> > [trunk r16-6108-g427ddf95eef] (Debian 16-20251214-1)
>
> There are still some places that give incorrect results.
>
> I have the following code:
>
> if (condition == true) {
> #if RVV_PATH1
> RVV code here
> #else
> scalar code here
> #endif
> } else {
> // exit(1);
> #if RVV_PATH2
> RVV code here
> #else
> scalar code here
> #endif
> }
>
> condition == true, RVV_PATH1 = 1, RVV_PATH2 = 1 -> result has artifacts
> condition == true, RVV_PATH1 = 1, RVV_PATH2 = 0 -> result looks correct
>
> This means that the RVV code for the "condition == false" path breaks the
> RVV code for the "condition == true" path, even if it isn't executed during
> run.
>
> When I uncomment the line with exit(1), the result looks correct but is
> slightly different (file hash differs from build with RVV_PATH2 = 0).
>
> After compilation, three runs are made, and all the results is the same
> (same file hash), there is no randomness at runtime: same input = same
> output.
>
> This is image processing using floating point calculations, fused
> multiply-add and the order in which floating point sums are calculated - may
> slightly change the result, but will not create visible artifacts.
Hmm, this shouldn't happen. If the code doesn't happen to have undefined
behavior somewhere we definitely need to have a look at it.
Do you have a reproducer, even if it's not minimal?
