Red Hat Bugzilla – Bug 125173
Want to consistent i386-compatible binaries compiled x86_64
Last modified: 2007-11-30 17:07:02 EST
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
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.cc -E -O c.c
where c.c the attached little program.
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
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
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.