PPL broken for Canadian-cross builds
I tried building GCC with Graphite enabled and all the libraries it requires in a Canadian cross configuration (build = i686-pc-linux-gnu, host = i686-mingw32, target = arm-none-eabi). This failed with:
configure:11279: checking for the possibility to control the FPU configure:11282: error: in `/scratch/gcc/nightly-2009-03-19-mainline/arm-none-eabi/obj/ppl-mainline-0-arm-none-eabi-i686-mingw32': configure:11285: error: cannot run test program while cross compiling See `config.log' for more details.
If you use AC_RUN_IFELSE you need to have a (safe) default (fourth argument) for cross compiling. An individual case is of course straightforward to fix, but it appears there are other such problems in PPL. For example, the GMP checks appear to treat GMP as not available in the cross compiling case; they should fall back to a compile/link test if they can't do an execution test; having found that I didn't go on to try to work out whether other defaults are safe or not. While the cross case may result in slightly less efficient code (if workarounds have to be enabled for bugs that may in fact not be present), it needs to allow the library to be built and to have all its features (or at least all the features used by GCC: the behavior of GCC on a host must not depend on whether PPL was cross compiled).
Would it be possible to have an official 0.10.1 bug-fix release with this fixed (and preferably without changes that would affect the code generated by GCC) for use with GCC 4.4 so that it is possible to enable Graphite in such configurations?
Joseph S. Myers wrote:
I tried building GCC with Graphite enabled and all the libraries it requires in a Canadian cross configuration (build = i686-pc-linux-gnu, host = i686-mingw32, target = arm-none-eabi). This failed with:
configure:11279: checking for the possibility to control the FPU configure:11282: error: in `/scratch/gcc/nightly-2009-03-19-mainline/arm-none-eabi/obj/ppl-mainline-0-arm-none-eabi-i686-mingw32': configure:11285: error: cannot run test program while cross compiling See `config.log' for more details.
If you use AC_RUN_IFELSE you need to have a (safe) default (fourth argument) for cross compiling. An individual case is of course straightforward to fix, but it appears there are other such problems in PPL. For example, the GMP checks appear to treat GMP as not available in the cross compiling case; they should fall back to a compile/link test if they can't do an execution test; having found that I didn't go on to try to work out whether other defaults are safe or not. While the cross case may result in slightly less efficient code (if workarounds have to be enabled for bugs that may in fact not be present), it needs to allow the library to be built and to have all its features (or at least all the features used by GCC: the behavior of GCC on a host must not depend on whether PPL was cross compiled).
Hi Joseph,
thanks for the detailed explanation. I admit we always have postoponed the issue of cross-compilation... to the point we almost forgot it. We will fix the PPL asap. Can we come back to you in case we are unsure about which defaults can be considered safe?
Would it be possible to have an official 0.10.1 bug-fix release with this fixed (and preferably without changes that would affect the code generated by GCC) for use with GCC 4.4 so that it is possible to enable Graphite in such configurations?
Work has already started for producing an official PPL 0.11 release. This will contain fixes for all the problems we discovered since the release of PPL 0.10 (mainly portability ones), a new "formatted output" feature that is needed in the MELT branch, plus other improvements, none of which affecting the code generated by GCC. I will write again when we can be more precise about the release schedule. All the best,
Roberto
On Fri, 20 Mar 2009, Roberto Bagnara wrote:
Hi Joseph,
thanks for the detailed explanation. I admit we always have postoponed the issue of cross-compilation... to the point we almost forgot it. We will fix the PPL asap. Can we come back to you in case we are unsure about which defaults can be considered safe?
I can test whether a candidate fixed tarball works (to build PPL and GCC in such an environment) in this case; telling what is safe is in general difficult without knowing the details of PPL internals and how it is used by GCC, and I don't have time right now to go through any differences in code generation between different hosts to see if they relate to PPL issues (and am not set up to build PPL or GCC directly on Windows to compare such a GCC with one built with a cross compiler to i686-mingw32 target).
Would it be possible to have an official 0.10.1 bug-fix release with this fixed (and preferably without changes that would affect the code generated by GCC) for use with GCC 4.4 so that it is possible to enable Graphite in such configurations?
Work has already started for producing an official PPL 0.11 release. This will contain fixes for all the problems we discovered since the release of PPL 0.10 (mainly portability ones), a new "formatted output" feature that is needed in the MELT branch, plus other improvements, none of which affecting the code generated by GCC. I will write again when we can be more precise about the release schedule.
I suggested a minimally fixed 0.10.1 to provide something maximally safe to use with 4.4 (or 4.4.1, etc., depending on the timing) without needing --disable-ppl-version-check; I'd be wary of explicitly approving multiple versions for use with 4.4, or increasing the recommended version from 0.10 to 0.11, at this late stage. For development for GCC 4.5, increasing the recommended version to 0.11 would seem appropriate.
Unfortunately building with a cross-compiler is so much a normal way of building GCC and the libraries it uses to me I didn't think PPL would need specific testing with it or that the portability testing of PPL done when support for using it was added to GCC would not have included it, so didn't test it before now.
Joseph S. Myers wrote:
On Fri, 20 Mar 2009, Roberto Bagnara wrote:
Work has already started for producing an official PPL 0.11 release. This will contain fixes for all the problems we discovered since the release of PPL 0.10 (mainly portability ones), a new "formatted output" feature that is needed in the MELT branch, plus other improvements, none of which affecting the code generated by GCC. I will write again when we can be more precise about the release schedule.
I suggested a minimally fixed 0.10.1 to provide something maximally safe to use with 4.4 (or 4.4.1, etc., depending on the timing) without needing --disable-ppl-version-check; I'd be wary of explicitly approving multiple versions for use with 4.4, or increasing the recommended version from 0.10 to 0.11, at this late stage. For development for GCC 4.5, increasing the recommended version to 0.11 would seem appropriate.
The point is that we had since long decided to make PPL 0.11, due to the many little glitches people has reported and due to the fact that the changes would not allow to preserve the ABI. Backporting all the changes to PPL 0.10 would be a lot of work and error-prone. Given that the release of GCC 4.4 is being delayed, what is the problem in having PPL 0.11 has a prerequisite instead of PPL 0.10? Notice that we can give a strong guarantee that no change is going to affect the code generated by GCC.
Unfortunately building with a cross-compiler is so much a normal way of building GCC and the libraries it uses to me I didn't think PPL would need specific testing with it or that the portability testing of PPL done when support for using it was added to GCC would not have included it, so didn't test it before now.
It is probably embarassing, but all this is completely new to us. We announced the PPL 0.10 release candidate on October 27th, 2008 on gcc-patches@gcc.gnu.org and the PPL 0.10 release on gcc@gcc.gnu.org on November 4th, 2008; no one raised this issue before. Anyway we are working on this full time now. All the best,
Roberto
On Fri, 20 Mar 2009, Roberto Bagnara wrote:
The point is that we had since long decided to make PPL 0.11, due to the many little glitches people has reported and due to the fact that the changes would not allow to preserve the ABI. Backporting all the changes to PPL 0.10 would be a lot of work and error-prone. Given that the release of GCC 4.4 is being delayed, what is the problem in having PPL 0.11 has a prerequisite instead of PPL 0.10? Notice that we can give a strong guarantee that no change is going to affect the code generated by GCC.
It would for example mean that people who had built PPL 0.10 for use with GCC, or installed a package from their GNU/Linux distribution, would find what they had built was no longer suitable and their distribution might not have a newer package. I'll leave the final decision up to the Graphite maintainers; I don't think this is something that should delay the release, or be changed after 4.4.0 is out, so if 4.4.0 goes out with 0.10 as the recommended version then the 4.4 series should stay with the recommended version being that not-cross-buildable version and 0.11 requiring using --disable-ppl-version-check.
Joseph S. Myers wrote:
On Fri, 20 Mar 2009, Roberto Bagnara wrote:
thanks for the detailed explanation. I admit we always have postoponed the issue of cross-compilation... to the point we almost forgot it. We will fix the PPL asap. Can we come back to you in case we are unsure about which defaults can be considered safe?
I can test whether a candidate fixed tarball works (to build PPL and GCC in such an environment) in this case; [...]
Hi there,
the PPL 0.10.1 snapshots available at
ftp://ftp.cs.unipr.it/pub/ppl/snapshots/
contain all the fixes to problems and glitches that have been reported to us and may affect GCC. Concerning cross-compilation, we have fixed the configuration procedure and made several portability improvements: we have tested these changes cross-compiling for arm-elf and i686-pc-mingw32.
Please let us know if this is OK as far as GCC 4.4 is concerned. All the best,
Roberto
On Sun, 29 Mar 2009, Roberto Bagnara wrote:
Joseph S. Myers wrote:
On Fri, 20 Mar 2009, Roberto Bagnara wrote:
thanks for the detailed explanation. I admit we always have postoponed the issue of cross-compilation... to the point we almost forgot it. We will fix the PPL asap. Can we come back to you in case we are unsure about which defaults can be considered safe?
I can test whether a candidate fixed tarball works (to build PPL and GCC in such an environment) in this case; [...]
Hi there,
the PPL 0.10.1 snapshots available at
ftp://ftp.cs.unipr.it/pub/ppl/snapshots/contain all the fixes to problems and glitches that have been reported to us and may affect GCC. Concerning cross-compilation, we have fixed the configuration procedure and made several portability improvements: we have tested these changes cross-compiling for arm-elf and i686-pc-mingw32.
Please let us know if this is OK as far as GCC 4.4 is concerned. All the best,
I can confirm that PPL now builds successfully for i686-mingw32 host. The next problem is that CLooG (the tarball in the infrastructure directory) doesn't appear portable to this system (in the secondary platforms list for 4.4 and 4.5); I get:
source/program.c:42:27: error: sys/resource.h: No such file or directory ... source/program.c:674: error: 'RUSAGE_SELF' undeclared (first use in this function) ...
This does not appear to be a cross build problem; it appears this file uses this header, not available on MinGW, unconditionally with no configure checks.
Hi,
On Sun, Mar 29, 2009 at 11:32, Joseph S. Myers joseph@codesourcery.com wrote:
I can confirm that PPL now builds successfully for i686-mingw32 host. The next problem is that CLooG (the tarball in the infrastructure directory) doesn't appear portable to this system (in the secondary platforms list for 4.4 and 4.5); I get:
source/program.c:42:27: error: sys/resource.h: No such file or directory ... source/program.c:674: error: 'RUSAGE_SELF' undeclared (first use in this function) ...
This does not appear to be a cross build problem; it appears this file uses this header, not available on MinGW, unconditionally with no configure checks.
I committed the attached fix to the cloog-ppl repo, and I will prepare a new tar.gz for the gcc infrastructure.
Sebastian Pop -- AMD - GNU Tools
participants (3)
-
Joseph S. Myers -
Roberto Bagnara -
Sebastian Pop