Bug 181868 - gcc does not compile gmp with patches properly
Summary: gcc does not compile gmp with patches properly
Alias: None
Product: Fedora
Classification: Fedora
Component: gcc   
(Show other bugs)
Version: 5
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2006-02-17 10:55 UTC by Juergen Bullinger
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-02-17 22:12:47 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Juergen Bullinger 2006-02-17 10:55:22 UTC
Description of problem:
I downloaded the source of gmp 4.1.4 and applied two of the offical patches to
the source. Afterwards I compiled it and performed make check. Then I got some
errors which I didn't get when I compiled it on a FC4 x86_64 system using gcc 4.0.0.

Version-Release number of selected component (if applicable):
Es werden eingebaute Spezifikationen verwendet.
Ziel: x86_64-redhat-linux
Konfiguriert mit: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-
--with-cpu=generic --host=x86_64-redhat-linux
Thread-Modell: posix
gcc-Version 4.1.0 20060214 (Red Hat 4.1.0-0.27)

How reproducible:

Steps to Reproduce:
1. download the source of gmp 4.1.4 from

2. unpack it

3. download the patches from

5. unpack it in a separate new directory 

6. do ./install pathToYourGmpRootDirectory in this new directory

7. only install toom3 and mpn_rootrem (say y when asked and n otherwise)

8. do cd pathToYourGmpRootDirectory

9. do ./configure
10. do make

11. do make check

Actual results:
Not all of the checks pass

Expected results:
They should pass as in earlier versions of gcc. In 4.0.0 for example it worked
the same way.

Additional info:
This is most likely a bug in gcc and maybe not directly related to your package.

Comment 1 Juergen Bullinger 2006-02-17 10:56:46 UTC
Can I install gcc parallel in different versions?

Comment 2 Jakub Jelinek 2006-02-17 11:10:55 UTC
Far more often it is just a bug in the package, e.g. anything that relies on
undefined behavior can work for years and be broken by a compiler upgrade that
optimizes some more.
If you think it is a gcc bug, you need to debug this yourself and prove
it is a gcc bug, by distilling a small self-contained testcase.
I really can't debug all packages just because somebody thinks it might be
a gcc problem.

Comment 3 Juergen Bullinger 2006-02-17 15:01:33 UTC
No it is not a bug in the package. As I said it ran on FC4 using gcc 4.0.0.
I get another error in gcc if I use the genuine gmp source code and apply the
genuine amd64 code enhancements.
This also worked on FC4. I did it just some days ago. The source is exactly the
same but now it doesn't work anymore.

Comment 4 Jakub Jelinek 2006-02-17 15:06:03 UTC
Please reread what I said in #2.  The fact that it worked in FC4 using gcc 4.0.x
doesn't tell anything, still it is far more likely it is a gmp bug than a gcc bug
(from my past experience).
If you see the problem in gmp included in Fedora development, this should be
reassigned to gmp, otherwise you need to come up with a small self-contained
testcase.  You can use binary search (compile some objects with gcc32,
some with gcc) etc.

Comment 5 Juergen Bullinger 2006-02-17 15:09:30 UTC
To reproduce it you can do the following:

1. download the original code from the official gmp homepage
http://ftp.sunet.se/pub/gnu/gmp/gmp-4.1.4.tar.bz2 as well as the patch
which is also directly linked from the official gmp homepage!

2. unzip both in two differenct directories

3. do ./install pathToYourGmpDir
   in the mpn_amd64 directory just created

4. perform the following sequence of commands in the gmp-4.1.4 directory you
   just created

make check

As I said it surely is not a bug in the code. If you do the steps above on a
x86_64 installation (AMD) you will get the following messages:

lt-t-bswap: error while loading shared libraries: libgmp.so.3: cannot enable
executable stack as shared object requires: Permission denied
FAIL: t-bswap
lt-t-constants: error while loading shared libraries: libgmp.so.3: cannot enable
executable stack as shared object requires: Permission denied
FAIL: t-constants
lt-t-count_zeros: error while loading shared libraries: libgmp.so.3: cannot
enable executable stack as shared object requires: Permission denied
FAIL: t-count_zeros
lt-t-gmpmax: error while loading shared libraries: libgmp.so.3: cannot enable
executable stack as shared object requires: Permission denied
FAIL: t-gmpmax
lt-t-modlinv: error while loading shared libraries: libgmp.so.3: cannot enable
executable stack as shared object requires: Permission denied
FAIL: t-modlinv

Comment 6 Jakub Jelinek 2006-02-17 15:22:10 UTC
If it is so, then it doesn't have anything to do with gcc.
SELinux simply refuses to load libgmp.so.3, as it requires executable stack.
You need to build it in a way that the library either doesn't request executable
stack, or tell SELinux about it.
GCC automatically does the right thing for .c/.C/etc. sources when compiling
them, but when .s/.S is used, it is author's responsibility to make sure the
right thing happens.
Either by marking it in the assembly:
#ifdef __linux__
        .section .note.GNU-stack
or by assembling with --noexecstack as option (if invoked through gcc driver,
-Wa,--noexecstack), or by linking with -Wl,-z,noexecstack.
E.g. FC5 gmp spec file handles this by:
export CCAS="gcc -c -Wa,--noexecstack"
before doing configure.
This is nothing new btw, almost 3 years old thing.
The only difference is that FC5 SELinux policy enforces this by default even
for unconfined processes, unless told otherwise, while in FC5 and earlier
it was enforced by default only for confined processes.

Comment 7 Juergen Bullinger 2006-02-17 16:06:05 UTC
Thank you for this info. I'll tried it. It resolves the second problem.
In the meantime I tried to compile the patch mentioned first using the gcc32
command as you suggested. I get the same problem. 
It says

PASS: t-cmp
/bin/sh: line 1:  8605 Speicherzugriffsfehler  ${dir}$tst
FAIL: t-mul
PASS: t-mul_i
/bin/sh: line 1:  8645 Speicherzugriffsfehler  ${dir}$tst
FAIL: t-tdiv
PASS: t-tdiv_ui
/bin/sh: line 1:  8686 Speicherzugriffsfehler  ${dir}$tst
FAIL: t-fdiv

Which means "Memory access violation"

Comment 8 Juergen Bullinger 2006-02-17 17:22:39 UTC
I did some more analysis and found out that at lease one of the bugs happens
after a function terminates and before the next statement in the calling
function is executed.
The verry last statement which is executed is a printf. I inserted it at the end
of the function mpn_mul_n in file gmp-4.1.4/mpn/generic/mul_n.c. It should be
around line some lines before 901 (i inserted some other printf lines so i can't
say exactly).

I also inserted printf statements before the call to this function and know
exactly where it is called when the error happens. It happens right after the
first call of function mpz_mul in gmp-4.1.4/tests/mpz/t-fdiv.c returns (about
line 119 in the file).
Could this be caused by improper stack handling?

Comment 9 Juergen Bullinger 2006-02-17 22:08:58 UTC
Have you seen my latest comments?
How can you explain this?

Comment 10 Jakub Jelinek 2006-02-17 22:12:47 UTC
Please don't reopen this bug until you prove there is a GCC problem.

Comment 11 Juergen Bullinger 2006-02-17 22:27:54 UTC
I already did a lot of analysis. Was this just a waste of time?
I hope not. Sorry if I analize things which might be a problem for your
distribution and you just close the messages for the sake of your statistics
then I hope you really have good reasons.

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