On Mon, Jan 21, 2019 at 4:58 PM Joseph Myers <jos...@codesourcery.com> wrote: > > On Tue, 22 Jan 2019, Terry Guo wrote: > > > 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 > > Which isn't supported by GCC. Any test involving rounding modes should > ensure inputs and results are volatile (or use asm, etc., but volatile is > simpler for tests) to make sure that computations aren't moved across > rounding mode changes (which can happen even with -frounding-math, > -frounding-math only affects a few things like constant folding, without > preventing such code movement). > > > The current _floattisf from libgcc2 doesn't support those four rounding > > modes. > > It doesn't need to mention rounding modes anywhere. The basic design of > all those conversion functions is that, given the input, they determine > other inputs to other conversions with the property that only a single > floating-point rounding occurs in the sequence of operations and that the > input to that rounding is similar enough to the input to the original > operation (through careful use of sticky bits etc.) that the result of > that rounding will always be the correct result of the original operation, > independent of the rounding mode. > > For example, it's always valid, in any rounding mode, to convert TImode to > SFmode by changing the TImode input to a nicer one (at most top 64 bits > nonzero, say, so that conversions from DImode can be used as an > intermediate step) such that the top 25 bits (starting with the first > nonzero bit, for positive or unsigned arguments) of the two values agree, > and the two values also agree in whether any lower-order bits are nonzero. > That sort of thing is what the code in libgcc2.c is trying to do. > > Some of that logic is complex, and it's entirely possible it has bugs. > But the correct fix must be an architecture-independent one in libgcc2.c; > any architecture-specific version is just a subsequent optimization on top > of that. In general, for any bug, you need to work out where the buggy > code is (meaning understanding the intended interfaces between bits of the > compiler that are involved in this question), and fix it there rather than > doing a target-specific workaround. If you want to do a target-specific > workaround (like this patch is), you need to call out up front that your > patch is just a workaround and give strong justification for that approach > (e.g. some way in which the proper general fix would be destabilizing at > the current development stage). > > The current description of the bug "Wrong __floattisf and __floattidf are > selected in libgcc" is completely inappropriate unless the assertion is > that one of the #if conditionals in libgcc2.c is wrong (in which case that > #if conditional, or the code it guards, should be corrected).
The testcase at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88931 with -frounding-math. __floattisf and __floattidf from libgcc2.c give the wrong results for FE_UPWARD and FE_TOWARDZERO. -- H.J.
