Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Want to consistent i386-compatible binaries compiled x86_64|
|Product:||Red Hat Enterprise Linux 3||Reporter:||Göran Uddeborg <goeran>|
|Component:||glibc||Assignee:||Jakub Jelinek <jakub>|
|Status:||CLOSED ERRATA||QA Contact:|
|Fixed In Version:||Doc Type:||Enhancement|
|Doc Text:||Story Points:||---|
|Last Closed:||2004-09-02 01:57:32 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Göran Uddeborg 2004-06-03 09:04:24 EDT
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.
Comment 1 Suzanne Hillman 2004-06-07 17:42:41 EDT
Internal RFE bug #125480 entered; will be considered for future releases.
Comment 2 Jakub Jelinek 2004-06-08 03:35:20 EDT
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.
Comment 3 Göran Uddeborg 2004-06-09 10:42:18 EDT
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.
Comment 4 Robert Perkins 2004-06-30 17:13:36 EDT
So, is this closable? It has a related feature request.
Comment 5 Göran Uddeborg 2004-07-07 12:44:50 EDT
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?
Comment 6 Jakub Jelinek 2004-07-07 12:50:53 EDT
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.
Comment 7 Jay Turner 2004-08-20 07:57:25 EDT
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.
Comment 8 Jay Turner 2004-09-02 01:57:32 EDT
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