Bug 32258 - Testsuite reports - FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c
Summary: Testsuite reports - FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c
Status: UNCONFIRMED
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 4.3.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: patch
Depends on:
Blocks:
 
Reported: 2007-06-08 16:31 UTC by Rob
Modified: 2009-02-28 14:10 UTC (History)
1 user (show)

See Also:
Host: i686-pc-linux-gnu
Target: i686-pc-linux-gnu
Build: i686-pc-linux-gnu
Known to work:
Known to fail:
Last reconfirmed:


Attachments
Patch main configure script to detect mpfr library and header version mismatch (664 bytes, patch)
2007-06-14 07:41 UTC, Rob
Details | Diff
Patch main configure script to use mpfr 2.2.1, also detect mpfr library and header version mismatch - submitted to gcc-patches@gcc.gnu.org (711 bytes, patch)
2007-06-23 09:30 UTC, Rob
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Rob 2007-06-08 16:31:47 UTC
I installed http://www.mpfr.org/mpfr-current/mpfr-2.2.1.tar.bz2 and applied the most recent patches. My version is 2.2.1-p5 .

I get this as a result of "make -i check":

FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c  -O0  scan-tree-dump pow
FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c  -O1  scan-tree-dump pow
FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c  -O2  scan-tree-dump pow
FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c  -O3 -fomit-frame-pointer  scan-tree-dump pow
FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c  -O3 -g  scan-tree-dump pow
FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c  -Os  scan-tree-dump pow


Here are a couple of my results from a while ago, and recent:

Results for 4.3.0 20070601 (experimental) testsuite on i686-pc-linux-gnu
http://gcc.gnu.org/ml/gcc-testresults/2007-06/msg00073.html

Results for 4.3.0 20070521 (experimental) testsuite on i686-pc-linux-gnu
http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg01083.html


Here are some other people's results - some used the --with-mpfr option:

Compiled using "--with-mpfr=/remote/atg5/jbuck/mpfr-linux" :
Results for 4.3.0 20070608 (experimental) testsuite on i686-pc-linux-gnu
http://gcc.gnu.org/ml/gcc-testresults/2007-06/msg00396.html

Results for 4.3.0 20070608 (experimental) testsuite on ia64-suse-linux-gnu
http://gcc.gnu.org/ml/gcc-testresults/2007-06/msg00391.html

Compiled using "--with-gmp=/opt/gcc-nightly/gmp-mpfr --with-mpfr=/opt/gcc-nightly/gmp-mpfr":
Results for 4.3.0 20070608 (experimental) testsuite on powerpc64-unknown-linux-gnu
http://gcc.gnu.org/ml/gcc-testresults/2007-06/msg00387.html


The other people don't seem to have this error occur. I have no reason to think they are using a more recent version of mpfr - since there is none. Perhaps they are using an older version.


Looking at the surrounding log entries (edited for similarity of test type):

Executing on host: /opt/gcc-4_3-build-2/gcc/xgcc -B/opt/gcc-4_3-build-2/gcc/ /root/downloads/gcc-4_3-trunk/gcc/testsuite/gcc.dg/torture/builtin-noret-2.c   -Os   -fno-show-column  -lm   -o builtin-noret-2.exe    (timeout = 300)
PASS: gcc.dg/torture/builtin-noret-2.c  -Os  (test for excess errors)

Executing on host: /opt/gcc-4_3-build-2/gcc/xgcc -B/opt/gcc-4_3-build-2/gcc/ /root/downloads/gcc-4_3-trunk/gcc/testsuite/gcc.dg/torture/builtin-pow-mpfr-1.c   -Os  -fdump-tree-original -fno-show-column -S  -o builtin-pow-mpfr-1.s    (timeout = 300)
PASS: gcc.dg/torture/builtin-pow-mpfr-1.c  -Os  (test for excess errors)
FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c  -Os  scan-tree-dump pow

Executing on host: /opt/gcc-4_3-build-2/gcc/xgcc -B/opt/gcc-4_3-build-2/gcc/ /root/downloads/gcc-4_3-trunk/gcc/testsuite/gcc.dg/torture/builtin-power-1.c   -Os  -ffast-math -fno-show-column  -lm   -o builtin-power-1.exe    (timeout = 300)
PASS: gcc.dg/torture/builtin-power-1.c  -Os  (test for excess errors)


I notice that this one test is applied differently than the surrounding ones. With the constant folding difficulties we are having at the moment (on i686-pc-linux-gnu) we might want to check the folding on the other tests too.
Comment 1 kargl 2007-06-08 17:14:25 UTC
(In reply to comment #0)
> I installed http://www.mpfr.org/mpfr-current/mpfr-2.2.1.tar.bz2 and applied the
> most recent patches. My version is 2.2.1-p5.

What does p4 do?

Comment 2 Rob 2007-06-09 03:17:17 UTC
>> From kargl@gcc.gnu.org
> I installed http://www.mpfr.org/mpfr-current/mpfr-2.2.1.tar.bz2 and applied
> the most recent patches. My version is 2.2.1-p5.
>> What does p4 do?

They only offer the patches mixed together, interspersed in a single file. I had a quick look at the site and did not spot a "patch changelog" only a "version changelog". The newest patch is recommended and available at: http://www.mpfr.org/mpfr-current/ . 

P4 might be from last year. You would need to view or disassemble the patch file to see what you would get with only P4.

Comment 3 kargl 2007-06-09 17:06:01 UTC
(In reply to comment #2)
> >> From kargl@gcc.gnu.org
> > I installed http://www.mpfr.org/mpfr-current/mpfr-2.2.1.tar.bz2 and applied
> > the most recent patches. My version is 2.2.1-p5.
> >> What does p4 do?
> 
> They only offer the patches mixed together, interspersed in a single file. I
> had a quick look at the site and did not spot a "patch changelog" only a
> "version changelog". The newest patch is recommended and available at:
> http://www.mpfr.org/mpfr-current/ . 
> 
> P4 might be from last year. You would need to view or disassemble the patch
> file to see what you would get with only P4.
> 

Yeah, I know.  I already read the patch.  You failed to answer my 
question.  P4 is a change to mpfr's pow implementation, which obviously
conflicts with GCC's use of this function.  Either revert that part of
the patch, or determine what changed and update GCC.
Comment 4 Rob 2007-06-11 17:00:50 UTC
Pardon me. I was not trying to be unobservant.

I'll have a look at gcc and see if _I_ can build a patch to test the version of mpfr and alter operation / configuration / etc. as needed to allow older versions of mpfr and the current version to co-exist.
Comment 5 Rob 2007-06-11 18:46:50 UTC
I just built gcc version 4.3.0 20070611 and noticed this:

# grep -B4 -A2 undefined\ reference\ to /opt/gcc-4_3-build/gcc/testsuite/gcc/gcc.log | head -n 6
Executing on host: /opt/gcc-4_3-build/gcc/xgcc -B/opt/gcc-4_3-build/gcc/ /root/downloads/gcc-4_3-trunk/gcc/testsuite/gcc.dg/torture/builtin-math-3.c   -Os   -fno-show-column  -lm   -o builtin-math-3.exe    (timeout = 300)
PASS: gcc.dg/torture/builtin-math-3.c  -Os  (test for excess errors)
Executing on host: /opt/gcc-4_3-build/gcc/xgcc -B/opt/gcc-4_3-build/gcc/ /root/downloads/gcc-4_3-trunk/gcc/testsuite/gcc.dg/torture/builtin-math-4.c   -O0   -fno-show-column  -lm   -o builtin-math-4.exe    (timeout = 300)
/tmp/ccjYQMCb.o: In function `main':
builtin-math-4.c:(.text+0x79): undefined reference to `link_error'
builtin-math-4.c:(.text+0xdc): undefined reference to `link_error'


This is new, it looks like someone is working on that part of the code.

In order to avoid any duplication of efforts I'm going to hold off on your suggestion "determine what changed and update GCC".

Comment 6 Rob 2007-06-12 04:56:16 UTC
A few days ago the testsuite of "C" produced this sort of result:

                === gcc tests ===


Running target unix
FAIL: gcc.c-torture/execute/20050316-2.c execution,  -O0
FAIL: gcc.c-torture/execute/20050316-2.c execution,  -O1
FAIL: gcc.c-torture/execute/20050316-2.c execution,  -O2
FAIL: gcc.c-torture/execute/20050604-1.c execution,  -O3 -fomit-frame-pointer -funroll-loops
FAIL: gcc.c-torture/execute/20050604-1.c execution,  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions
FAIL: gcc.c-torture/execute/mayalias-2.c compilation,  -O3 -g  (internal compiler error)
UNRESOLVED: gcc.c-torture/execute/mayalias-2.c execution,  -O3 -g
FAIL: gcc.c-torture/execute/mayalias-3.c compilation,  -O3 -g  (internal compiler error)
UNRESOLVED: gcc.c-torture/execute/mayalias-3.c execution,  -O3 -g
FAIL: gcc.dg/compat/vector-2 c_compat_x_tst.o-c_compat_y_tst.o execute
FAIL: gcc.dg/builtin-apply4.c execution test
FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c  -O0  scan-tree-dump pow
FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c  -O1  scan-tree-dump pow
FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c  -O2  scan-tree-dump pow
FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c  -O3 -fomit-frame-pointer  scan-tree-dump pow
FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c  -O3 -g  scan-tree-dump pow
FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c  -Os  scan-tree-dump pow
FAIL: gcc.dg/tree-ssa/gen-vect-11.c scan-tree-dump-times vectorized 1 loops 1
FAIL: gcc.dg/tree-ssa/gen-vect-11a.c scan-tree-dump-times vectorized 1 loops 1
XPASS: gcc.dg/tree-ssa/update-threading.c scan-tree-dump-times Invalid sum 0
XPASS: gcc.dg/vect/vect-iv-4.c scan-tree-dump-times vectorized 1 loops 1
FAIL: gcc.target/i386/pr21291.c (test for excess errors)

                === gcc Summary ===

# of expected passes            45864
# of unexpected failures        18
# of unexpected successes       2
# of expected failures          135
# of unresolved testcases       2
# of untested testcases         35
# of unsupported tests          309
/opt/gcc-4_3-build/gcc/xgcc  version 4.3.0 20070609 (experimental)


Now I get this:

                === gcc tests ===

Schedule of variations:
    unix

Running target unix
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using /root/downloads/gcc-4_3-trunk/gcc/testsuite/config/default.exp as tool-and-target-specific interface file.
Running /root/downloads/gcc-4_3-trunk/gcc/testsuite/gcc.dg/dg.exp ...
FAIL: gcc.dg/builtin-apply4.c execution test

                === gcc Summary ===

# of expected passes            9946
# of unexpected failures        1
# of expected failures          54
# of unsupported tests          170
/opt/gcc-4_3-build/gcc/xgcc  version 4.3.0 20070611 (experimental)


A HUGE difference. The GNU/Linux apt-get or aptitude in combination with installing mpfr yourself _might_ have caused a problem with the include files.

A "standard" configuration of mpfr (without any extra configuration options) creates and installs a static library _only_ in /usr/local/lib.

When gcc 4.3.0 is configured and built without extra "mpfr" options it uses the mpfr library in /usr/lib (in preference to the newer one in /usr/local/lib).



# ls -l /usr/include/mpfr.h /usr/local/include/mpfr.h 
-rw-r--r-- 1 root root  34500 May  7 05:29 /usr/include/mpfr.h
-rw-r--r-- 1 root staff 34500 Jun  6 17:37 /usr/local/include/mpfr.h


# diff -Naur /usr/include/mpfr.h /usr/local/include/mpfr.h 
(Prints Nothing)


# grep -B3 MPFR_VERSION_STRING /usr/include/mpfr.h                           
#define MPFR_VERSION_MAJOR 2
#define MPFR_VERSION_MINOR 2
#define MPFR_VERSION_PATCHLEVEL 1
#define MPFR_VERSION_STRING "2.2.1-p5"


I don't know how I got my "/usr/include/mpfr.h" and "/usr/local/include/mpfr.h"
the same (and neither relevant for /usr/lib/libmpfr*) but I fixed that.


The preceeding actions cause "gcc/toplev.c" to print a warning about different
library versions. GCC builds this way without complaining about it.


# /opt/gcc-4_3-build/gcc/cc1 -fpreprocessed test_1.i -dumpbase test_1.c -mtune=athlon-xp -march=athlon-xp -auxbase test_1 -O0 -version -o test_1.s
GNU C version 4.3.0 20070611 (experimental) (i686-pc-linux-gnu)
        compiled by GNU C version 4.3.0 20070611 (experimental), GMP version 4.2.1, MPFR version 2.2.1-p5.
warning: MPFR header version 2.2.1-p5 differs from library version 2.2.0.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
options passed:  -fpreprocessed test_1.i -mtune=athlon-xp -march=athlon-xp
 -O0
options enabled:  -falign-loops -fargument-alias -fbranch-count-reg
 -fcommon -fearly-inlining -feliminate-unused-debug-types
 -femit-class-debug-always -ffunction-cse -fgcse-lm -fident
 -finline-functions-called-once -fivopts -fkeep-static-consts
 -fleading-underscore -fmath-errno -fmove-loop-invariants
 -fpcc-struct-return -fpeephole -fsched-interblock -fsched-spec
 -fsched-stalled-insns-dep -fshow-column -fsigned-zeros
 -fsplit-ivs-in-unroller -ftoplevel-reorder -ftrapping-math -ftree-loop-im
 -ftree-loop-ivcanon -ftree-loop-optimize -ftree-scev-cprop
 -ftree-vect-loop-version -fvar-tracking -fzero-initialized-in-bss -m32
 -m3dnow -m80387 -m96bit-long-double -maccumulate-outgoing-args
 -malign-stringops -mfancy-math-387 -mfp-ret-in-387 -mglibc -mieee-fp -mmmx
 -mno-red-zone -mno-sse4 -mpush-args -msse -mtls-direct-seg-refs
Compiler executable checksum: 75d249b8da4189a62f5df6c013a2e257

Execution times (seconds)
 parser                :   0.00 ( 0%) usr   0.01 (13%) sys   0.01 ( 7%) wall      25 kB ( 2%) ggc
 dominance computation :   0.00 ( 0%) usr   0.01 (12%) sys   0.01 ( 7%) wall       0 kB ( 0%) ggc
 expand                :   0.01 (20%) usr   0.00 ( 0%) sys   0.01 ( 7%) wall       6 kB ( 1%) ggc
 TOTAL                 :   0.05             0.08             0.14               1156 kB
Extra diagnostic checks enabled; compiler may run slowly.
Configure with --enable-checking=release to disable checks.



After re-installing mpfr this is what it prints instead:


# /opt/gcc-4_3-build/gcc/cc1 -fpreprocessed test_1.i -dumpbase test_1.c -mtune=athlon-xp -march=athlon-xp -auxbase test_1 -O0 -version -o test_1.s
GNU C version 4.3.0 20070611 (experimental) (i686-pc-linux-gnu)
        compiled by GNU C version 4.3.0 20070611 (experimental), GMP version 4.2.1, MPFR version 2.2.1-p5.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
options passed:  -fpreprocessed test_1.i -mtune=athlon-xp -march=athlon-xp
 -O0
options enabled:  -falign-loops -fargument-alias -fbranch-count-reg
 -fcommon -fearly-inlining -feliminate-unused-debug-types
 -femit-class-debug-always -ffunction-cse -fgcse-lm -fident
 -finline-functions-called-once -fivopts -fkeep-static-consts
 -fleading-underscore -fmath-errno -fmove-loop-invariants
 -fpcc-struct-return -fpeephole -fsched-interblock -fsched-spec
 -fsched-stalled-insns-dep -fshow-column -fsigned-zeros
 -fsplit-ivs-in-unroller -ftoplevel-reorder -ftrapping-math -ftree-loop-im
 -ftree-loop-ivcanon -ftree-loop-optimize -ftree-scev-cprop
 -ftree-vect-loop-version -fvar-tracking -fzero-initialized-in-bss -m32
 -m3dnow -m80387 -m96bit-long-double -maccumulate-outgoing-args
 -malign-stringops -mfancy-math-387 -mfp-ret-in-387 -mglibc -mieee-fp -mmmx
 -mno-red-zone -mno-sse4 -mpush-args -msse -mtls-direct-seg-refs
Compiler executable checksum: 75d249b8da4189a62f5df6c013a2e257

Execution times (seconds)
 parser                :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 8%) wall      25 kB ( 2%) ggc
 TOTAL                 :   0.05             0.05             0.12               1156 kB
Extra diagnostic checks enabled; compiler may run slowly.
Configure with --enable-checking=release to disable checks.


I'm going to bump this up from "normal" to "major" since:

1): This essentially blocks this version and revision from having the "C" compiler declared a _possible_ candidate for release (only one error) ( - thats not _my_ call if it is actually release quality).

2): There may be people trying to fix what is not broken and worrying about errors in the testsuite that can't be fixed by a "change to mpfr's pow implementation".

3): The "C" compiler is used to compile everything else (and has never worked with so few errors). This is likely to affect all other parts of gcc.


The configure script needs to make the same check as "gcc/toplev.c"'s print_version() does. It needs to fail and not continue if there is that problem.


There is NO compatability problem with mpfr 2.2.1-p5 and gcc version 4.3.0 20070611 on the i686-pc-linux-gnu _IF_ you have configure halt if version checking fails.
Comment 7 Andrew Pinski 2007-06-12 05:00:08 UTC
> # of expected passes            9946

Something is messed up with your dejagnu because there should be many more tests.
Comment 8 Rob 2007-06-12 10:53:21 UTC
>> should be many more tests.

It's OK. I followed the advice on page http://gcc.gnu.org/install/test.html - Section "0.1 How can you run the testsuite on selected tests?".

make check-gcc RUNTESTFLAGS="dg-torture.exp"


I did that so I could check quickly and post here; so people would not be trying to fix what is NOT broken and know the correct place to look for the trouble.


Just completed the whole test on everything - see here:
http://gcc.gnu.org/ml/gcc-testresults/2007-06/msg00573.html


Also please look at the end of the report. I made a mod to the test_summary to catch assembler errors - and it found some ...
Comment 9 Richard Biener 2007-06-12 15:15:20 UTC
I see those as well, on x86_64-unknown-linux-gnu

FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c  -O0  scan-tree-dump pow
FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c  -O1  scan-tree-dump pow
FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c  -O2  scan-tree-dump pow
FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c  -O3 -fomit-frame-pointer  scan-tree-d
ump pow
FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c  -O3 -g  scan-tree-dump pow
FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c  -Os  scan-tree-dump pow

./gcc/cc1 --version
GNU C version 4.3.0 20070612 (experimental) (x86_64-unknown-linux-gnu)
        compiled by GNU C version 4.3.0 20070612 (experimental), GMP version 4.2.1, MPFR version 2.2.0.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Comment 10 Andrew Pinski 2007-06-12 15:31:29 UTC
This is not a bug.
Here is the deal, the reporter compiled GCC with the new headers but is using the old library (which is known to be buggy).
Comment 11 Rob 2007-06-13 08:06:18 UTC
The configure script should check the headers against the library version.

Two people from "gcc.gnu.org" and I all got nailed by this. It may bite others with less computer knowledge than ourselves.


The "bug" is this:

1): The configure script needs a sanity check since GCC compiles and works reasonably well with the library / header mixup.

2): It is the GCC configure script that is choosing the wrong headers to match the library it chose. 

3a): _IF_ GCC wants /usr/lib/libmpfr.so/.a it should use /usr/include/mpfr.h

3b): _IF_ GCC wants /usr/local/lib/libmpfr.so/.a it should use /usr/local/include/mpfr.h
Comment 12 Rob 2007-06-13 09:32:09 UTC
>> Comment #10 From Andrew Pinski 2007
>> This is not a bug.
>> Here is the deal, the reporter compiled GCC with the new headers but is using
>> the old library (which is known to be buggy).

> Comment #6 From Rob
> warning: MPFR header version 2.2.1-p5 differs from library version 2.2.0.


I double checked. Configure is taking it's library from /usr/lib/ and using /usr/local/include/mpfr.h


The MPFR docs say:

`MPFR_VERSION_STRING' is the version as a string constant, which can be compared to the result of `mpfr_get_version' to check at run time the header file and library used match:

          if (strcmp (mpfr_get_version (), MPFR_VERSION_STRING))
             fprintf (stderr, "Error, header and library files do not match\n");


So we need something as simple as this added to the main configure script:

          if (strcmp (mpfr_get_version (), MPFR_VERSION_STRING)) return 1;
Comment 13 Rob 2007-06-13 09:38:59 UTC
Reopen bug reason: Request we add proposed fix to main configuration script.
Comment 14 Richard Biener 2007-06-13 12:08:53 UTC
Can you provide a working patch?
Comment 15 Rob 2007-06-13 23:39:39 UTC
>Can you provide a working patch?

Soon. I am trying to fix the math inaccurcy in GCC 4.3.0 and merge a a new math library. You can try sticking that oneliner into your configure if your in a rush.
Comment 16 Rob 2007-06-14 07:41:18 UTC
Created attachment 13702 [details]
Patch main configure script to detect mpfr library and header version mismatch

I have made best efforts to make a compatable patch by reading several configure files and attempted to ensure this will work on as many systems as possible.

Would a few people who are expert on scripting and maintaining GCC coding standards review this patch and make any repairs they deem neccesary.

It should work as-is but I've been trying do do a few things at once today.
Comment 17 Rob 2007-06-17 14:07:47 UTC
Due to the bugs in mpfr ( http://www.mpfr.org/mpfr-2.2.1/#bugs ) we should probably _require_ a recent version. 

It would be kind of someone else to make that patch - I am kinda busy at the moment. The section "File: mpfr.info,  Node: Miscellaneous Functions" provides the macros. Mpfr p5 may have bugs in it but it is the newest available so we should require that version at least.

Using an old version (without an expect script to print a "WARNING:" line in
the testsuite) will drive people buggy trying to find out why their code is broken when in fact it is the user's library that is needing fixing.

Applying these changes can clean a few errors off the testsuite and put us a step closer to a release. Please don't prefer patching the testsuite to skip tests on the basis that the user has an old unsupported version of mpfr.

The lines in configure that need changes are:
#if MPFR_VERSION < MPFR_VERSION_NUM(2,2,0)
#if MPFR_VERSION < MPFR_VERSION_NUM(2,2,1)
Comment 18 Rob 2007-06-17 20:46:46 UTC
Page: http://gcc.gnu.org/install/prerequisites.html says:

MPFR Library version 2.2.1 (or later)
Necessary to build GCC. It can be downloaded from http://www.mpfr.org/. The version of MPFR that is bundled with GMP 4.1.x contains numerous bugs. Although GCC may appear to function with the buggy versions of MPFR, there are a few bugs that will not be fixed when using this version. ...


If we want that page to be correct then the "MPFR_VERSION_NUM(2,2,0)" must be changed to at least "MPFR_VERSION_NUM(2,2,1)" (mandatory) and the second ["MPFR_VERSION_NUM(2,2,1)"] should require p5 (good idea).
Comment 19 Rob 2007-06-20 05:09:46 UTC
Just tried MPFR version 2.3.0 - it works fine.
Comment 20 Rob 2007-06-23 09:30:28 UTC
Created attachment 13766 [details]
Patch main configure script to use mpfr 2.2.1, also detect mpfr library and header version mismatch - submitted to gcc-patches@gcc.gnu.org
Comment 21 Rob 2009-02-28 14:10:40 UTC
(In reply to comment #20)
> Created an attachment (id=13766) [edit]
> Patch main configure script to use mpfr 2.2.1, also detect mpfr library and
> header version mismatch - submitted to gcc-patches@gcc.gnu.org
> 

This also affects 'lto' (since the patch submitted was never applied).


# gcc/xgcc -v
Using built-in specs.
COLLECT_GCC=gcc/xgcc
Target: x86_64-unknown-linux-gnu
Configured with: ../lto_trunk/configure --prefix=/usr/local/lto --enable-languages=lto,c++ --enable-multilib --disable-stage1-checking --enable-checking=release --with-gmp=/usr/local --with-mpfr=/usr/local
Thread model: posix
gcc version 4.4.0 20090218 (experimental) [lto revision 144460] (lto merged with rev 144262) 


# touch delete.c

# gcc/xgcc -v -I/usr/local/include -B/usr/src/lto_build/prev-gcc/ delete.c 2>&1 | head -29 | tail

#include <...> search starts here:
 /usr/src/lto_build/./prev-gcc/include
 /usr/src/lto_build/./prev-gcc/include-fixed
 /usr/local/include
 /usr/include
End of search list.
GNU C (lto merged with rev 144262) version 4.4.0 20090218 (experimental) [lto revision 144460] (x86_64-unknown-linux-gnu)
	compiled by GNU C version 4.3.2, GMP version 4.2.4, MPFR version 2.4.1-p1.
warning: GMP header version 4.2.4 differs from library version 4.2.2.
warning: MPFR header version 2.4.1-p1 differs from library version 2.3.1.


Rob