Hide Forgot
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.4.2) Gecko/20040301 Description of problem: We use both plain i386 machines and x86_64 machines to build programs which are to run on any i386 machine. To get precisely the same result, we compile with "-m32 -march=i386 -mcpu=i386" among the flags. In most situations, this generates code which is effectively equivalent. But we recently in our tests discovered a case where we actually get different results depending on compilation machine. It involves the ceil(3) function. When compiled on x86_64, the traditional call of the library function is generated. When compiled on i386 however, an inline version of this function comes from /usr/include/bits/mathinline.h. We'd appreciate an enhancement where the i386 inline functions are available on the x86_64 platform too, at least when generating code for i386. Version-Release number of selected component (if applicable): glibc-headers-2.3.2-95.20 How reproducible: Always Steps to Reproduce: 1.cc -E -O c.c where c.c the attached little program. Additional info: We haven't isolated the precise value which makes the two versions give different result. We don't claim that either is incorrect, it could very well be within specs in both cases. What we are looking for is consistency.
Internal RFE bug #125480 entered; will be considered for future releases.
bits/mathinline.h and bits/string2.h is (hopefully quickly) getting away (well, kept only for old GCCs), as its role is taken over by GCC which can do better. See e.g. http://sources.redhat.com/ml/libc-hacker/2004-05/msg00043.html http://sources.redhat.com/ml/libc-hacker/2004-05/msg00048.html In this light I'm not sure if I want to duplicate that 25k header for x86-64 (it would need duplication, as on x86-64 it needs to be surrounded by #if __WORDSIZE == 32). If you want consistency for now, just go with -D__NO_MATH_INLINES.
I'm not going to argue it should be done on any particular side of the glibc/gcc border. You know that much better than I do, and as long as we get consistent behaviour, we are happy. (Preferably, it should be a fast behaviour too. :-) We used -fno-inlines for this file as a temporary workaround, but I suppose -D__NO_MATH_INLINES is better in that it has less side effects.
So, is this closable? It has a related feature request.
By "related feature request", do you refer to the RFE mentioned in comment 1? Does that RFE ask for implementing something along the lines mentioned in comment 2? (I can't check myself since it is an internal only bug.) If I have understood this correctly, then sure, THIS bugzilla can be closed. It would then also have been interesting to be able to follow bug 125480. Are the restrictions on it needed, or could it be made public?
In 2.3.2-95.22 I have added a patch (not upstream though and probably not going there ever) which provides the i386 mathinline.h #if __WORDSIZE == 32, plus additional md5sum check which will alert me to redo the patch any time i386 mathinline.h changes. <bits/string.h> has not been handled the same though, but that header isn't actually used unless -D__USE_STRING_INLINES, so shouldn't affect code which wants to be consistent.
Confirmed that the code is present in 2.3.2-95.26. Moving to Modified, and the fix will be available in the U3 glibc errata.
An errata has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2004-384.html