Roberto Bagnara bagnara@cs.unipr.it writes:
Ian Lance Taylor wrote:
I'm having some trouble building the Graphite support.
Using ftp://gcc.gnu.org/pub/gcc/infrastructure/ppl-0.10.2.tar.gz :
- Unlike gcc, does not support a --with-gmp option.
- Does support a --with-libgmpxx-prefix option.
What is the trouble with this? I mean, is it a matter of syntax (you prefer the option to be called --with-gmp) or semantics (the --with-libgmpxx-prefix does not do the right thing)?
Let me start by saying that my message was aimed at the gcc developers who have brought PPL and CLooG into the gcc build. My message was not aimed at the PPL developers. When MPFR and GMP were brought into the build, Kaveh spent quite a bit of time getting everything working smoothly. I think that the graphite developers need to spend a similar amount of time getting the PPL and CLooG builds working smoothly.
--with-gmp vs. --with-libgmpxx-prefix is a matter of syntax. Since all gcc developers have to build these packages, it's inconvenient to have to remember different configure options for different packages.
- If GMP was not built with C++ support, fails at build time.
Yes, the C++ interface of GMP is required. On the other hand, also the core of PPL is written in C++. In whhich sense requiring the C++ interface of GMP is a trouble?
This is not a problem with PPL. It's a problem with the existing build instructions for gcc developers.
- If GMP was not built with exception support, complains at configure time, and recommends using CPPFLAGS=-fexceptions when building GMP.
Well, "complain" is not the right word. The PPL configuration script simply warns about the fact that the bounded memory capabilities of the PPL are not available. Which is not a problem for GCC, since these capabilities are not used by CLooG. The message was designed not to alarm people unnecessarily. It says: "This is OK, if you do not plan to use the bounded memory capabilities offered by the PPL." Do you think a different wording could help?
Since I don't actually know anything about PPL, the message didn't mean anything to me. I didn't know whether GCC used those features or not. So this is a problem with the existing build instructions: they need to document this message and state clearly that it may be ignored for purposes of using PPL with GCC.
- CPPFLAGS is for preprocessor flags, and -fexceptions is not a preprocessor flag. However, I admit that setting CFLAGS does not work correctly, as GMP seems to have special requirements for it.
In facto, our use of CPPFLAGS is motivated by the fact that using CFLAGS for that purpose was not working, once upon a time. See:
http://www.cs.unipr.it/pipermail/ppl-devel/2001-October/000639.html http://www.cs.unipr.it/pipermail/ppl-devel/2001-October/000663.html
Perhaps it works now: we will check again and, in case it works, we will amend the configuration script, documentation and web site.
It will still fail as these messages describe. When the user sets CFLAGS, it overrides the default CFLAGS setting. The best way to make this work may be to work with the GMP developers. Again, this is not a responsibility of the PPL developers, and in fact I have no idea whether this matters for the ways in which GCC uses PPL.
- I think they mean -funwind-tables anyhow.
We do that because:
-funwind-tables Similar to -fexceptions, except that it will just generate any needed static data, but will not affect the generated code in any other way. You will normally not enable this option; instead, a language processor that needs this handling would enable it on your
As far as I know, enabling -funwind-tables for C code is sufficient to throw exceptions from C++ code to C++ code across that C code. The documentation is somewhat misleading. You never need to specify this option when your program is written entirely in one language. Things are different in multi-language programs.
Ian