diff options
| author | liuhongt <hongtao.liu@intel.com> | 2023-06-25 11:35:09 +0800 |
|---|---|---|
| committer | liuhongt <hongtao.liu@intel.com> | 2023-06-26 15:30:06 +0800 |
| commit | 77a50c772771f681085922b493922516c3c03e9a (patch) | |
| tree | 3d98bbae5e0cc8315da95c616723e35efd186f66 /libjava | |
| parent | 2916278d14e9ac28c361c396a67256acbebda6e8 (diff) | |
| download | gcc-77a50c772771f681085922b493922516c3c03e9a.zip gcc-77a50c772771f681085922b493922516c3c03e9a.tar.gz gcc-77a50c772771f681085922b493922516c3c03e9a.tar.bz2 | |
Don't use intermiediate type for FIX_TRUNC_EXPR when ftrapping-math.
> > Hmm, good question. GENERIC has a direct truncation to unsigned char
> > for example, the C standard generally says if the integral part cannot
> > be represented then the behavior is undefined. So I think we should be
> > safe here (0x1.0p32 doesn't fit an int).
>
> We should be following Annex F (unspecified value plus "invalid" exception
> for out-of-range floating-to-integer conversions rather than undefined
> behavior). But we don't achieve that very well at present (see bug 93806
> comments 27-29 for examples of how such conversions produce wobbly
> values).
That would mean guarding this with !flag_trapping_math would be the appropriate
thing to do.
gcc/ChangeLog:
PR tree-optimization/110371
PR tree-optimization/110018
* tree-vect-stmts.cc (vectorizable_conversion): Don't use
intermiediate type for FIX_TRUNC_EXPR when ftrapping-math.
gcc/testsuite/ChangeLog:
* gcc.target/i386/pr110018-1.c: Add -fno-trapping-math to dg-options.
* gcc.target/i386/pr110018-2.c: Ditto.
Diffstat (limited to 'libjava')
0 files changed, 0 insertions, 0 deletions