Re: GCC 4.9.0 Released

[Sebastian Huber]

The Git mirror seems to have no gcc-4_9_0-release tag.

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

Re: GCC 4.9.0 Released

[David Brown]

On 22/04/14 15:10, Jakub Jelinek wrote:
> One year and one month passed from the time when the last major version
> of the GNU Compiler Collection has been announced, so it is the time again
> to announce a new major GCC release, 4.9.0.
> 
> GCC 4.9.0 is a major release containing substantial new
> functionality not available in GCC 4.8.x or previous GCC releases.
> 

Well done everyone - thanks and congratulations to all involved in
another solid step forward for gcc.

Re: C PreProcessor GCC-specific features ideas.

[gwenael chailleu]

Solal,

Ian is right, m4 corresponds better to what you've got in mind

Your idea (strengthening the preprocessing phase) of C is already
(mostly) implemented : it is called Cawen. Please have a look at :

http://www.melvenn.com/en/cawen/why-cawen/

In short : C99 + m4 = Cawen

And your idea is a very good one !

It is almost frightening to see what can be done with a little type
introspection, a serious preprocessing phase, very few builtin
patterns and good old C99 : namely all the C++ present and future
magic tricks written in a more elegant style + a much more powerful
templating system + a much easier profiling and runtime analysis
(Cawen produces C, not C++)...

Our first benchmarks aren't that bad :

http://www.melvenn.com/en/google-benchmark/

http://www.melvenn.com/en/cawen/cawen-and-the-web-2/

At the moment, we lack resources to create an open source project and
we use Cawen as an internal tool.

Best regards

TS & GC

2014-04-23 2:18 GMT+02:00 Ian Lance Taylor :
> On Tue, Apr 22, 2014 at 9:38 AM, Solal  wrote:
>>
>> I've got ideas for improve the preprocessor with specific features.
>>
>> The basic idea is to make the preprocessing language a complete
>> programming language.
>
> We are very unlikely to add such features to GCC unless they first
> become part of the C or C++ language standard.
>
> There are other preprocessors better suited for general purpose
> programming, such as m4.
>
> Ian

Re: C PreProcessor GCC-specific features ideas.

[David Brown]

On 22/04/14 18:38, Solal wrote:
> I've got ideas for improve the preprocessor with specific features.
> 
> The basic idea is to make the preprocessing language a complete
> programming language.
> That can be useful for includes things like Autotools and advanced
> Makefiles directly in the source code, and have just a tiny Makefile for
> compile.
> 
> 0. Multiple defines on one variable.
> The "constants" will be transformed in "variables".
> 
> 1. Assertions
> #assert  
> will be transformed in :
> #if !
> #
> #endif
> (And will be of course re-preprocessed.)
> 
> 2. Calculating
> #calculate  
> will be transformed in :
> #define  
> (And will be of course re-preprocessed.)
> Example :
> #calculate N 1+1
> will be transformed in :
> #define N 2
> (That can works with any type : bools, etc.)

Much is already handled by the compiler today - "#define N (1 + 1)" will
work just as well as "#define N 2".

I think a lot of the potential advanced uses of such pre-processor
"magic" can be better handled by C++ "constexpr" (and possibly template
calculations).  For my 2 cents, I would think it would be a far better
idea to make a gcc extension to C to support C++ "constexpr" in C mode.
 It would have much more potential uses, be consistent with C++, and be
consistent with the gcc extension tradition of supporting useful C and
C++ features for both languages.

> 
> 3. Executing shell commands
> #exec-sh  
> The shell command  while be executed and the result
> (stdout) of the shell command will be putted in 

This screams "security hole" so loudly that it could never be
considered.  People understand that running "make" can call arbitrary
programs - people do not expect /compilers/ to do so.

> 
> 4. Read and write files
> #read-file  
> will put the content of the file  in , and if  is
> modified,  is modified too.
> 

Again, this is stepping /way/ outside the appropriate bounds of a
built-in pre-processor.


I don't disagree with the idea of improving upon autotools.  But I don't
think adding features to the pre-processor is the way to go.

The C pre-processor is a historic relic that exists because C/C++ does
not have proper modules (hence "#include"), it did not have proper
constants (hence "#define ARRAY_SIZE 100" macros), it did not have
inline functions (hence "#define VECTOR_SIZE(x, y) sqrt((x), (y))"
macros), and it did not have templates, typedefs, and many other
features of modern C and C++.

It would be far more useful to work towards eliminating the use of the
pre-processor, rather than extending it.  Some of that can be done by
porting C++ features into C (as gcc extensions, until the happy day when
they hopefully get included in the standards) - "constexpr" is one, and
the greater flexibility of "const" and "static const" as compile-time
constants (for things like array size and switch labels, which are legal
in C++ but not C).

The big step would be to support modules in cooperation with LLVM, and
thus eliminate "#include":

Re: reviewers for wide int.

[Richard Biener]

On Tue, 22 Apr 2014, Mike Stump wrote:

> On Apr 22, 2014, at 12:48 PM, Kenneth Zadeck  wrote:
> > 
> >>> While of course one hopes that there will be no issues with wide-int, a
> >>> change of this size will have some pain no matter how well we have
> >>> tested it.  Having three reviewers will assure problems are resolved
> >>> quickly.
> >> Works for me.  I suppose this mainly covers wide-int.[CH], right?
> > if you want to define it that narrowly you can.   it really depends on how 
> > much help you want and how much you trust us not to go beyond what is 
> > reasonable.   All three of us have been at this long enough to know when to 
> > ask for help.
> 
> There is a large class of bugs that can creep in due to the subtle 
> change of interface from double-int to wide-int.  These happen outside 
> of the wide-int.[ch] code and seem statistically more likely by a large 
> margin than bugs in wide-int.[ch].  The good news, resolving them is 
> easy enough with side-by-side comparisons (say of dump files and .s 
> files).  Most of those fixes I’d expect to be trivial (for some 
> definition of trivial).

Yeah.  Note that it's difficult to define "reviewer for code that
uses wide-int", thus my question (that is, what do you put into
MAINTAINERS and how would you interpret the entry).

But as always we apply common sense to reviewer/maintainership
areas.

Richard.

-- 
Richard Biener 
SUSE / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
GF: Jeff Hawn, Jennifer Guild, Felix Imend"orffer

gcc-4.9.0 manual

[Rainer Emrich]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Not Found

The requested URL /onlinedocs/gcc-4.9.0/libstdc++-api.pdf.gz was not found on
this server.

Apache Server at gcc.gnu.org Port 80
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTV4jYAAoJEB3HOsWs+KJb1d4H/jgVEMJWehmLledmOfIwnOQc
n5vGJCz6B633gKk5TVbh/WL8r2Ovh3EgCU/aS1Y+Cz6Z99XoB9Ju1X+yC71tX3+h
J8Yu4UWRtvjwGTnrry60Q2XxwTCmavzrm4MhQOcg4w5skjIE1Mhkpz2wX9O23ZZN
yvdRdTSB8O/temrTfCBkaS7LIyUeUi3qURemGVzSJLjnif5Vh0ao/dyUaQoXYX/B
fYzda6jLrVFuAHb6cGmbxrYg8f+EktuPtcOIsHM9p1SyVLd29fp/JGkuaTycwUHJ
4J/PfMLlw5TZ3py4QjazkZe8liyNlmqHCq3+b4Wxv6sz+XdAxfBV4sKc5mZJxo0=
=Z6LN
-END PGP SIGNATURE-

Re: gcc-4.9.0 manual

[Jonathan Wakely]

On 23 April 2014 10:33, Rainer Emrich wrote:
>
> The requested URL /onlinedocs/gcc-4.9.0/libstdc++-api.pdf.gz was not found on
> this server.

Yes, onlinedocs/gcc-4.9.0/libstdc++-api-gfdl.xml.gz is also missing, I
didn't figure out how to generate them yet!

Re: gcc-4.9.0 manual

[Richard Biener]

On Wed, Apr 23, 2014 at 11:45 AM, Jonathan Wakely  wrote:
> On 23 April 2014 10:33, Rainer Emrich wrote:
>>
>> The requested URL /onlinedocs/gcc-4.9.0/libstdc++-api.pdf.gz was not found on
>> this server.
>
> Yes, onlinedocs/gcc-4.9.0/libstdc++-api-gfdl.xml.gz is also missing, I
> didn't figure out how to generate them yet!

Comes up after each release ... and I always ask the one generating it
to document how to do that in releasing.html ...

Richard.

Re: [GSoC] Generating patterns from meta-description

[Richard Biener]

On Tue, Apr 22, 2014 at 6:39 PM, Prathamesh Kulkarni
 wrote:
> Hi,
> Thank-you for selecting me for GSoC 2014, I am looking forward to
> working with GCC community. I am grateful to Richard Biener and Diego Novillo
> for choosing to mentor me for this project. Unfortunately, I couldn't
> reply last week because I am in the middle of university exams, I
> apologize for that.
>
> * Time Commitments:
> I have university exams up-to 5th May, and couple of exams on 24th may
> and 27th may. Thereafter I am completely free, and can commit up-to
> 50 hours per week on average.
>
> * Few questions regarding genmatch:
>
> a) Lexical analysis and Parsing:
> I believe this is already in place. We would continue with
> hand-written recursive descent parser.

That's correct.  Cleanups/extensions can be applied as necessary.

> b) Intermediate representations:
> For representing "matching" operands
> we will need to use a decision tree (I am not yet decided on how it would be
> implemented). For "simplification" operands, we can use AST (struct operand).
>
> For example:
> (match_and_simplify
>   (negate (negate @0))
>   @0)
>
> (match_and_simplify
>   (negate (bit_not @0))
>   (minus @0 { integer_one_node; }))
>
> There would be 2 AST's to represent @0 and (minus @0 { integer_one_node; } ).
> And one decision tree representing matching operands for both expressions.
> Something like:
>   negate
> negateminus
> @0 @0   { integer_one_node' }

Yes.

> c) Code generation:
> Currently code-generation is done for gimple by walking the AST by
> calling .gen_gimple_match and .gen_gimple_transform on each node.
> Would it be a good idea to separate code gen interfaces
> (.gen_gimple_match and .gen_gimple_transform) from AST ?
> We would be having two IR's (decision-tree and AST) and two targets
> (generic and gimple). Code-generation for pattern-matching shall be
> performed by tree-walk
> of decision tree and for transforms by tree-walk of AST.

Yeah, not using virtual methods here is fine with me.  Certainly the
current code generator is a quick hack used for prototyping.  You
can completely rewrite it using modern C++ techniques if you like
(you have to stick to C++04 though).

> d) Handling Commutative operators:
> Should it be hard-coded in genmatch which operators are commutative ?
> Internally the pattern would be duplicated with operands reversed.

First, for some operand kinds GCC already presents you with a canonicalized
operand order - see gimple-match-head.c and how it calls
commutative_tree_code (code) && tree_swap_operands_p ().  That usually
applies to 'leafs' only (at least on GIMPLE where the ops are just two
SSA names for complex expressions).

But that already gives you the idea of what tree codes are commutative
(though that's not exposed to the parser / AST in a useful way).  Ideally
we'd extend tree.def with a 'commutative' flag so we can implement
commutative_tree_code by clever preprocessing and do the same in
genmatch.c.

That leaves the question on what pattens (and which nodes of the
pattern tree) to actually apply the commutation (given that the
number of permutations to try grows exponentially with expression
complexity).

We have two choices here - explicitely mark to commutate nodes
somehow, like for example with '+' on the operator

(match_and_simplify
  (MINUS_EXPR (+PLUS_EXPR @0 @1) @0)
  @1)

or we only commutate the outermost node (doesn't catch the example)
or we only commutate leaf nodes (usually not necessary due to
the code in gimple-match-head.c).

Explicit marking at least doesn't require us to solve the "what operators
are commutative" problem, so I'd go with that (for now).

> e) Finalizing syntax:
> For example: plus vs PLUS vs PLUS_EXPR, currently all of them are accepted.
> (I would prefer lowercase version). Similarly free-form if vs
> lisp-style (if ...) etc.

Yes.  I also prefer the lowercase version without the _EXPR part.
Similar for the function call matching - use 'cabs', not BUILT_IN_CABS.
Leaves us with the ambiguity of BUILT_IN_ABS and ABS_EXPR ... ;)
I believe they have compatible behavior (but for -ftrapv/-fwrapv they
differ in handling of the most negative integer).  Let's defer that issue
(I thought of requiring to say abs_expr / built_in_abs on conflict).

> * Upto 19th may:
> I plan to do the following upto 19th May:
> a) Separate code-gen interfaces from AST and add simple fixes to genmatch.

Good.  It would also be nice to do e) from above - settle on the lower-case
without _expr and built_in_ suffix/prefix variants.

> b) Study forwprop patterns.
> c) Try to solve missed optimization bugs.
> If there's something else I would need to do, I would be happy to hear
> about that.

I'd say take the existing match.pd (which is really just a "testcase"
for genmatch right now, apart from the bits commented with
Transforms formerly done by tree-ssa-forwprop.c:associate_plusminus),
strip it down and make sure we have a testcase for each transf

Re: reviewers for wide int.

[Kenneth Zadeck]

On 04/23/2014 04:04 AM, Richard Biener wrote:

On Tue, 22 Apr 2014, Mike Stump wrote:


On Apr 22, 2014, at 12:48 PM, Kenneth Zadeck  wrote:

While of course one hopes that there will be no issues with wide-int, a
change of this size will have some pain no matter how well we have
tested it.  Having three reviewers will assure problems are resolved
quickly.

Works for me.  I suppose this mainly covers wide-int.[CH], right?

if you want to define it that narrowly you can.   it really depends on how much 
help you want and how much you trust us not to go beyond what is reasonable.   
All three of us have been at this long enough to know when to ask for help.

There is a large class of bugs that can creep in due to the subtle
change of interface from double-int to wide-int.  These happen outside
of the wide-int.[ch] code and seem statistically more likely by a large
margin than bugs in wide-int.[ch].  The good news, resolving them is
easy enough with side-by-side comparisons (say of dump files and .s
files).  Most of those fixes I’d expect to be trivial (for some
definition of trivial).

Yeah.  Note that it's difficult to define "reviewer for code that
uses wide-int", thus my question (that is, what do you put into
MAINTAINERS and how would you interpret the entry).

But as always we apply common sense to reviewer/maintainership
areas.

richi.

This is not without precedent.   The dataflow reviewers are authorized 
to review changes to data flow anywhere in the rtl level and back ends. 
   In the many years that that has been in place none of us "went 
rogue".We will be conservative.


kenny


Richard.

Re: C PreProcessor GCC-specific features ideas.

[Renato Golin]

On 23 April 2014 09:03, David Brown  wrote:
> Again, this is stepping /way/ outside the appropriate bounds of a
> built-in pre-processor.
>
> I don't disagree with the idea of improving upon autotools.  But I don't
> think adding features to the pre-processor is the way to go.

I completely agree.


> The big step would be to support modules in cooperation with LLVM, and
> thus eliminate "#include":

>From what it seems, this is the only sane thing to do in the compiler.

While that's not an option, Make magic looks a lot less dirty than any
pre-processor extension.

cheers,
--renato

gcc-4.9-20140423 is now available

[gccadmin]

Snapshot gcc-4.9-20140423 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20140423/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.9 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_9-branch 
revision 209725

You'll find:

 gcc-4.9-20140423.tar.bz2 Complete GCC

  MD5=9ec9799d622a9828cbe6970e2e002f97
  SHA1=f9f66b8c2ce3ee78b117992f061d760af22d8171

Diffs from 4.9-20140416 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.9
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Need some help with a possible bug

[George R Goffe]

Hi,

I'm trying to build the latest gcc and am getting a message from the process 
"collect2: error: ld returned 1 exit status" for this library 
/usr/lsd/Linux/lib/libgmp.so. Here's the full msg: 
"/usr/lsd/Linux/lib/libgmp.so: could not read symbols: File in wrong format"

When I use the file command on this library, I get this:

file libgmp.so.10.2.0
libgmp.so.10.2.0: ELF 64-bit LSB shared object, x86-64, version 1 
(SYSV), dynamically linked, 
BuildID[sha1]=c8ca89cca80d669102f5b3e8e077b5d00f47bf78, not stripped


I'm running Fedora 19 X86_64 and, as far as I know, building for this 
architecture. I just built the latest gmp, mpc, mpfr hoping that that was the 
problem but I still get the msg.

Here's a more elaborate snip of the build log. I have the complete log if it's 
needed.

Thanks,

George...




file libgmp.so.10.2.0
libgmp.so.10.2.0: ELF 64-bit LSB shared object, x86-64, version 1 
(SYSV), dynamically linked, 
BuildID[sha1]=c8ca89cca80d669102f5b3e8e077b5d00f47bf78, not stripped




make[8]: Leaving directory 
`/sdc1/exphome/clipper/export/home/tools/gcc/obj-i686-pc-linux-gnu/
x86_64-unknown-linux-gnu/32/libjava/classpath/native/jni/midi-alsa'
Making all in java-math
make[8]: Entering directory 
`/sdc1/exphome/clipper/export/home/tools/gcc/obj-i686-pc-linux-gnu/
x86_64-unknown-linux-gnu/32/libjava/classpath/native/jni/java-math'
/bin/bash ../../../libtool --tag=CC   --mode=compile 
/tools/gcc/obj-i686-pc-linux-gnu/./gcc/xgcc 
-B/tools/gcc/obj-i686-pc-linux-gnu/./gcc/ 
-B/usr/lsd/Linux/x86_64-unknown-linux-gnu/bin/ -B/usr/ls
mv -f .deps/maxloc0_4_i4.Tpo .deps/maxloc0_4_i4.Plo
/bin/bash ./libtool  --tag=CC   --mode=compile 
/tools/gcc/obj-i686-pc-linux-gnu/./gcc/xgcc 
-B/tools/gcc/obj-i686-pc-linux-gnu/./gcc/ 
-B/usr/lsd/Linux/x86_64-unknown-linux-gnu/bin/ -B/usr/lsd/Linu
libtool: compile:  /tools/gcc/obj-i686-pc-linux-gnu/./gcc/xgcc 
-B/tools/gcc/obj-i686-pc-linux-gnu/./gcc/ 
-B/usr/lsd/Linux/x86_64-unknown-linux-gnu/bin/ 
-B/usr/lsd/Linux/x86_64-unknown-linux-gnu/l
libtool: compile:  /tools/gcc/obj-i686-pc-linux-gnu/./gcc/xgcc 
-B/tools/gcc/obj-i686-pc-linux-gnu/./gcc/ 
-B/usr/lsd/Linux/x86_64-unknown-linux-gnu/bin/ 
-B/usr/lsd/Linux/x86_64-unknown-linux-gnu/l
libtool: compile:  /tools/gcc/obj-i686-pc-linux-gnu/./gcc/xgcc 
-shared-libgcc -B/tools/gcc/obj-i686-pc-linux-gnu/./gcc -nostdinc++ 
-L/tools/gcc/obj-i686-pc-linux-gnu/x86_64-unknown-linux-gnu/libs
mv -f .deps/tsan_symbolize_addr2line_linux.Tpo 
.deps/tsan_symbolize_addr2line_linux.Plo
/bin/bash ./libtool  --tag=CC   --mode=compile 
/tools/gcc/obj-i686-pc-linux-gnu/./gcc/xgcc 
-B/tools/gcc/obj-i686-pc-linux-gnu/./gcc/ 
-B/usr/lsd/Linux/x86_64-unknown-linux-gnu/bin/ -B/usr/lsd/Linu
libtool: compile:  /tools/gcc/obj-i686-pc-linux-gnu/./gcc/xgcc 
-B/tools/gcc/obj-i686-pc-linux-gnu/./gcc/ 
-B/usr/lsd/Linux/x86_64-unknown-linux-gnu/bin/ 
-B/usr/lsd/Linux/x86_64-unknown-linux-gnu/l
libtool: compile:  /tools/gcc/obj-i686-pc-linux-gnu/./gcc/xgcc 
-B/tools/gcc/obj-i686-pc-linux-gnu/./gcc/ 
-B/usr/lsd/Linux/x86_64-unknown-linux-gnu/bin/ 
-B/usr/lsd/Linux/x86_64-unknown-linux-gnu/l
mv -f .deps/gnu_java_math_GMP.Tpo .deps/gnu_java_math_GMP.Plo
/bin/bash ../../../libtool --tag=CC   --mode=link 
/tools/gcc/obj-i686-pc-linux-gnu/./gcc/xgcc 
-B/tools/gcc/obj-i686-pc-linux-gnu/./gcc/ 
-B/usr/lsd/Linux/x86_64-unknown-linux-gnu/bin/ -B/usr/lsd/L
libtool: link: /tools/gcc/obj-i686-pc-linux-gnu/./gcc/xgcc 
-B/tools/gcc/obj-i686-pc-linux-gnu/./gcc/ 
-B/usr/lsd/Linux/x86_64-unknown-linux-gnu/bin/ 
-B/usr/lsd/Linux/x86_64-unknown-linux-gnu/lib/
/usr/lsd/Linux/lib/libgmp.so: could not read symbols: File in wrong 
format
collect2: error: ld returned 1 exit status
make[8]: *** [libjavamath.la] Error 1
make[8]: Leaving directory 
`/sdc1/exphome/clipper/export/home/tools/gcc/obj-i686-pc-linux-gnu/
x86_64-unknown-linux-gnu/32/libjava/classpath/native/jni/java-math'
make[7]: *** [all-recursive] Error 1
make[7]: Leaving directory 
`/sdc1/exphome/clipper/export/home/tools/gcc/obj-i686-pc-linux-gnu/
x86_64-unknown-linux-gnu/32/libjava/classpath/native/jni'
make[6]: *** [all-recursive] Error 1
make[6]: Leaving directory 
`/sdc1/exphome/clipper/export/home/tools/gcc/obj-i686-pc-linux-gnu/
x86_64-unknown-linux-gnu/32/libjava/classpath/native'
make[5]: *** [all-recursive] Error 1
make[5]: Leaving directory 
`/sdc1/exphome/clipper/export/home/tools/gcc/obj-i686-pc-linux-gnu/
x86_64-unknown-linux-gnu/32/libjava/classpath'
make[4]: *** [all-recursive] Error 1
make[4]: Leaving directory 
`/sdc1/exphome/clipper/export/home/tools/gcc/obj-i686-pc-linux-gnu/
x86_64-unknown-linux-gnu/32/libjava'
make[3]: *** [multi-do] Error 1
make[3]: Leaving directory 
`/sdc1/exphome/clipper/export/home/tools/gcc/obj-i686-pc-linux-gnu/
x86_64-unknown-linux-gnu/libjava'
make[2]: *** [all-multi] Error 2
make[2]: Leaving directory 
`/sdc1/exphome/clipper/export/home/tools/gcc/obj-i686-pc-linux-gnu/
x86_64-unknown-linux-gnu/libjava'
make[1]: *** [all-target-libjava] Error 2
make[1]: *** Waiting for un

Re: Need some help with a possible bug

[Marc Glisse]

(should have been gcc-h...@gcc.gnu.org, please send any follow-ups there)

On Wed, 23 Apr 2014, George R Goffe wrote:


I'm trying to build the latest gcc


Do you really need gcj? If not, please disable java.

and am getting a message from the 
process "collect2: error: ld returned 1 exit status" for this library 
/usr/lsd/Linux/lib/libgmp.so. Here's the full msg: 
"/usr/lsd/Linux/lib/libgmp.so: could not read symbols: File in wrong 
format"


You are doing a multilib build (--disable-multilib if you don't want 
that), so it tries to build both a 64 bit and a 32 bit versions of 
libjavamath.so, both of which want to link to GMP. So you need both 
versions of GMP installed as well.


I thought the configure script in classpath would detect your missing 32 
bit GMP and disable use of GMP in that case, but apparently not... You may 
want to file a PR in bugzilla about that if there isn't one already. But 
you'll need to provide more info there: your configure command line, the 
file config.log in the 32 bit version of classpath, etc.


--
Marc Glisse