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). -- Joseph S. Myers jos...@codesourcery.com
