Bug 125173 - Want to consistent i386-compatible binaries compiled x86_64
Summary: Want to consistent i386-compatible binaries compiled x86_64
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: glibc   
(Show other bugs)
Version: 3.0
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact:
Keywords: FutureFeature
Depends On:
TreeView+ depends on / blocked
Reported: 2004-06-03 13:04 UTC by Göran Uddeborg
Modified: 2007-11-30 22:07 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-02 05:57:32 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2004:384 normal SHIPPED_LIVE Updated glibc packages 2004-09-02 04:00:00 UTC

Description Göran Uddeborg 2004-06-03 13:04:24 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.4.2)

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):

How reproducible:

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 21:42:41 UTC
Internal RFE bug #125480 entered; will be considered for future releases.

Comment 2 Jakub Jelinek 2004-06-08 07:35:20 UTC
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

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 14:42:18 UTC
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 21:13:36 UTC
So, is this closable?  It has a related feature request.

Comment 5 Göran Uddeborg 2004-07-07 16:44:50 UTC
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

Comment 6 Jakub Jelinek 2004-07-07 16:50:53 UTC
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 11:57:25 UTC
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 05:57:32 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.