On Tue, Jan 22, 2019 at 7:48 AM Joseph Myers <jos...@codesourcery.com> wrote: > > On Mon, 21 Jan 2019, H.J. Lu wrote: > > > TI->SF and TI->DF conversions in libgcc2.c: > > > > FSTYPE > > FUNC (DWtype u) > > { > > ... > > } > > > > have no rounding mode support. We should replace __floattisf, __floattidf, > > __floatuntisf and __floatuntidf in libgcc2.c with these from soft-fp. > > Please explain what you mean by "have no rounding mode support" (i.e., the > exact flow through a function that is incorrect in a non-default rounding > mode). This patch is missing testcases - which of course should be > architecture-independent. (Any bug in libgcc2.c should first have an > architecture-independent fix - it can't be considered fixed based on a fix > for one architecture. Then, if some other approach is optimal on > particular architectures, they can get optimized variants.) > > I believe all those function implementations are designed so that only a > single rounding occurs, which is for the final result, so no explicit > handling of rounding modes is ever needed (the integer code before then > may set up sticky bits appropriately to ensure the floating-point parts of > the code only need a single rounding, which works in all modes), but maybe > there are bugs in certain cases. To identify the correct fix, we need > details of the exact code path being used (the exact values of the various > macros, choices for the various conditional parts of the function, values > each variable has at each point) and where the existing, > rounding-mode-independent logic goes wrong. > > -- > Joseph S. Myers > jos...@codesourcery.com
Hi Joseph, I believe HJ is proposing patch to fix bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88931. In the test case of the bug, the "#pragma STDC FENV_ACCESS ON" is used and there are four rounding modes: { ROUNDING (FE_DOWNWARD), ROUNDING (FE_UPWARD), ROUNDING (FE_TOWARDZERO), ROUNDING (FE_TONEAREST) } The current _floattisf from libgcc2 doesn't support those four rounding modes. BR, Terry