Changed, here's the updated patch I'm going to check in.
REAL_CST is handled if it can be represented in different floating
point types without loss of precision or under fast math.
gcc/ChangeLog:
PR tree-optimization/103771
* match.pd (cond_expr_convert_p): Extend the match to h
On Wed, May 14, 2025 at 7:28 AM liuhongt wrote:
>
> So it won't do the unsafe truncation for double(1.001) to
> float(1.0)
> since there's precision loss.
> It's guarded by testcase pr103771-6.c
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
> Ok for trunk?
>
> REAL_CST
So it won't do the unsafe truncation for double(1.001) to float(1.0)
since there's precision loss.
It's guarded by testcase pr103771-6.c
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ok for trunk?
REAL_CST is handled if it can be represented in different floating
point typ