On Thu, 10 Jan 2013, Michael Zolotukhin wrote: > Thanks for the responses! > I'll think about your warnings and decide whether I could afford such > effort or not, but anyway, I wanted to start from GCC, not glibc. > Am I getting it right, that before any other works we need to fix PR > 34678 (that's correct number, thanks Mark!), making all passes take > into account that calls could change rounding-modes/raise exceptions, > i.e. make all calls optimization barriers? At least, when no > 'aggressive' options were passed to the compiler.
There are various overlapping bugs in Bugzilla for issues where -frounding-math -ftrapping-math fail to implement all of FENV_ACCESS (I think of exceptions and rounding modes support together, since they have many of the same issues and both are covered by FENV_ACCESS, although it may be possible to fix only a subset of the issues, e.g. just rounding modes without exceptions). To what extent the issues really duplicate each other isn't entirely clear; I'd advise looking at all the testcases in all relevant PRs (both open (576 20785 27682 29186 30568 34678), and others marked as duplicates of open ones), even if you then end up only working on a subset of the problems. Yes, doing much related to rounding modes really requires making the compiler respect them properly for -frounding-math. That's not quite calls being optimization barriers in general, just for floating point. * General calls may set, clear or test exceptions, or manipulate the rounding mode (as may asms, depending on their inputs / outputs / clobbers). * Floating-point operations have the rounding mode as input. They may set (but not clear or test) floating-point exception flags. * Thus in general floating-point operations may not be moved across most calls (or relevant asms), or values from one side of a call reused for the same operation with the same inputs appearing on the other side of the call. * Statements such as "(void) (a * b);" can't be eliminated because they may raise exceptions. (That's purely about exceptions, not rounding modes.) Personally I'd think a natural starting point on the compiler side would be to write a reasonably thorough and systematic testsuite for such issues. That would cover all operations, for all floating-point types (including ones such as __float128 and __float80), and conversions between all pairs of floating-point types and either way between each floating-point type and each integer type (including __int128 / unsigned __int128), with operands being any of (constants, non-volatile variables initialized with constants, volatile variables, vectors) and results being (discarded, stored in non-volatile variables, stored in volatile variables), in all the rounding modes, testing both results and exceptions and confirming proper results when an operation is repeated after changes of rounding mode or clearing exceptions. The idea would be that the tests would all be expected to pass once the problems in this area have been fixed. They'd be run over different optimization options, like the existing torture tests, as well as over variants such as -mfpmath=387 / -mfpmath=sse where applicable. Right now, some would probably pass (especially with "volatile" and at -O0), others fail. The difficulty might be in setting up good XFAIL state for such tests to reflect what does / does not work before the compiler has been cleaned up in this area - that state is probably pretty complicated right now. I suppose a testsuite could be kept external until the tests all pass on some targets, but it would seem better to be able to have the tests in-tree while work is done incrementally on making the compiler better in this area, so that the improvements in a patch can readily be seen as "N XFAILs removed". (More could certainly be done on the glibc testsuite side to cover exceptions / rounding modes issues better there as well, although there's more existing coverage of such issues now than there is in the GCC testsuite.) > That work seems to be quite big and it really can cause huge tests Yes, there is certainly a huge amount that can be improved regarding floating-point issues in the GNU toolchain in general (GCC and glibc), and room for plenty of people to work on different improvements; I'd certainly be glad to see any improvements on such floating-point infrastructure (which historically has received less development attention than, for example, optimization or porting). > fallout, but when it's done adding new subcodes for operations with > rounding shouldn't cause any new fails (as we won't change behavior of > 'default' operations). Once you're supporting operations with constant rounding, for it to be useful you'll need a way for source code to generate them - whether detecting fesetround pairs as you previously suggested, or the constant rounding mode C bindings in the draft first part of the TS for C bindings to IEEE 754-2008. So even if in theory you don't change anything about how existing code is handled, I expect the changes would still involve some risk of fallout. -- Joseph S. Myers jos...@codesourcery.com
