[Bug lto/40790] plugin-api.h unconditionally includes stdint.h
--- Comment #19 from rguenth at gcc dot gnu dot org 2009-10-31 13:05 --- Well, LTO problem fixed. The plugin (GCC plugin, not linker plugin!) testsuite should be fixed up. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40790
[Bug lto/40790] plugin-api.h unconditionally includes stdint.h
--- Comment #18 from ebotcazou at gcc dot gnu dot org 2009-10-26 20:41 --- Fixed on Solaris 10 by http://gcc.gnu.org/ml/gcc-cvs/2009-10/msg00629.html There is still a problem in the testsuite though: http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg02530.html Executing on build: gcc -g -O2 /nile.build/botcazou/gcc-head/src/gcc/testsuite/\ gcc.dg/plugin/selfassign.c -I. -I/nile.build/botcazou/gcc-head/src/gcc/testsuit\ e -I/nile.build/botcazou/gcc-head/src/gcc/testsuite/../../gcc -I/nfs/nile/nile.\ build/botcazou/gcc-head/sparc-sun-solaris2.9/gcc/testsuite/gcc/../../../gcc -I\ /nile.build/botcazou/gcc-head/src/gcc/testsuite/../../include -I/nile.build/bot\ cazou/gcc-head/src/gcc/testsuite/../../libcpp/include -I/nile.build/botcazou/g\ cc-head/install_sparc/include -I/nile.build/botcazou/gcc-head/install_sparc/in\ clude -I/nile.build/botcazou/gcc-head/install_sparc/include -O -DIN_GCC -fPIC -\ shared -o selfassign.so(timeout = 300) In file included from /nile.build/botcazou/gcc-head/src/gcc/testsuite/../../gcc\ /gcc-plugin.h:28,^M from /nile.build/botcazou/gcc-head/src/gcc/testsuite/gcc.dg/pl\ ugin/selfassign.c:5:^M /nile.build/botcazou/gcc-head/src/gcc/testsuite/../../gcc/system.h:418:20: erro\ r: stdint.h: No such file or directory^M Stage 3 compiler has #define HAVE_STDINT_H 1 in auto-host.h so the include is triggered, but -I/nile.build/botcazou/gcc-head/sparc-sun-solaris2.9/gcc/include is not passed on the command line. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40790
[Bug lto/40790] plugin-api.h unconditionally includes stdint.h
-- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |major Last reconfirmed|2009-07-22 00:02:48 |2009-10-19 05:39:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40790
[Bug lto/40790] plugin-api.h unconditionally includes stdint.h
--- Comment #17 from ebotcazou at gcc dot gnu dot org 2009-10-12 06:10 --- Present on Solaris versions 10. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org GCC build triplet|mips-sgi-irix6.5| GCC host triplet|mips-sgi-irix6.5| GCC target triplet|mips-sgi-irix6.5| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40790
[Bug lto/40790] plugin-api.h unconditionally includes stdint.h
--- Comment #10 from ro at techfak dot uni-bielefeld dot de 2009-10-09 12:42 --- Subject: Re: plugin-api.h unconditionally includes stdint.h --- Comment #9 from espindola at google dot com 2009-10-08 18:20 --- [...] The only thing the compiler should need the plugin-api.h for is the enum ld_plugin_symbol_resolution. If we split plugin-api.h in two, we would be able to compile gcc itself without stdint.h. The problem with this approach is that the lto plugin would still fail to build in a system without stdint.h. Is it OK to have optional features like the gold plugin not supported in systems like Tru64 UNIX V4.0F? That would be no problem since AFAIK gold only supports ELF targets by design, and Tru64 UNIX uses ECOFF. Not even GNU ld supports that anymore (or the support has bitrotten to the point of being unusable). Yet another possibility would be to change the build system so that we always build the lto plugin with xgcc (in addition to the plugin-api.h split). No idea how hard this is. Why all those contortions if there seems to be an easy way out: just use the GCC_HEADER_STDINT macro from config/m4 and include the resulting (e.g.) gstdint.h instead of stdint.h? Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40790
[Bug lto/40790] plugin-api.h unconditionally includes stdint.h
--- Comment #11 from espindola at google dot com 2009-10-09 12:58 --- Why all those contortions if there seems to be an easy way out: just use the GCC_HEADER_STDINT macro from config/m4 and include the resulting (e.g.) gstdint.h instead of stdint.h? Interesting. One problem is that this header is also used on gold. Maybe we could do #ifdef HAVE_STDINT_H #include stdint.h #elif HAVE_INTTYPES_H #include inttypes.h #else #include gstdint.h #endif That way gcc would build on anything thanks to GCC_HEADER_STDINT and gold would require something with stdint.h or inttypes.h. Rainer Thanks! Rafael -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40790
[Bug lto/40790] plugin-api.h unconditionally includes stdint.h
--- Comment #12 from joseph at codesourcery dot com 2009-10-09 12:58 --- Subject: Re: plugin-api.h unconditionally includes stdint.h On Fri, 9 Oct 2009, ro at techfak dot uni-bielefeld dot de wrote: --- Comment #10 from ro at techfak dot uni-bielefeld dot de 2009-10-09 12:42 --- Subject: Re: plugin-api.h unconditionally includes stdint.h --- Comment #9 from espindola at google dot com 2009-10-08 18:20 --- [...] The only thing the compiler should need the plugin-api.h for is the enum ld_plugin_symbol_resolution. If we split plugin-api.h in two, we would be able to compile gcc itself without stdint.h. The problem with this approach is that the lto plugin would still fail to build in a system without stdint.h. Is it OK to have optional features like the gold plugin not supported in systems like Tru64 UNIX V4.0F? That would be no problem since AFAIK gold only supports ELF targets by design, and Tru64 UNIX uses ECOFF. Not even GNU ld supports that anymore (or the support has bitrotten to the point of being unusable). gold supports non-ELF hosts (or will once Andrew Pinski's MinGW host patches are in), and in due course should support plugins on such hosts. (I've no idea whether Tru64 has a dynamic loading interface making plugins on such a host possible at all, but if it has such an interface there is no reason in principle against someone adding support for plugins for a cross compiler and linker from Tru64 to an ELF target.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40790
[Bug lto/40790] plugin-api.h unconditionally includes stdint.h
--- Comment #13 from ro at techfak dot uni-bielefeld dot de 2009-10-09 13:21 --- Subject: Re: plugin-api.h unconditionally includes stdint.h --- Comment #11 from espindola at google dot com 2009-10-09 12:58 --- Why all those contortions if there seems to be an easy way out: just use the GCC_HEADER_STDINT macro from config/m4 and include the resulting (e.g.) gstdint.h instead of stdint.h? Interesting. One problem is that this header is also used on gold. Maybe we could do #ifdef HAVE_STDINT_H #include stdint.h #elif HAVE_INTTYPES_H #include inttypes.h #else #include gstdint.h #endif That way gcc would build on anything thanks to GCC_HEADER_STDINT and gold would require something with stdint.h or inttypes.h. Why the complications? Just use GCC_HEADER_STDINT in both gcc and gold and be done with it. If the intention is for gold to support platforms beyond GNU/Linux with ELF, it will run into the need sooner or later anyway. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40790
[Bug lto/40790] plugin-api.h unconditionally includes stdint.h
--- Comment #14 from ro at techfak dot uni-bielefeld dot de 2009-10-09 13:24 --- Subject: Re: plugin-api.h unconditionally includes stdint.h --- Comment #12 from joseph at codesourcery dot com 2009-10-09 12:58 --- [...] That would be no problem since AFAIK gold only supports ELF targets by design, and Tru64 UNIX uses ECOFF. Not even GNU ld supports that anymore (or the support has bitrotten to the point of being unusable). gold supports non-ELF hosts (or will once Andrew Pinski's MinGW host patches are in), and in due course should support plugins on such hosts. Ok, but only as a cross-linker to ELF targets, I suppose? (I've no idea whether Tru64 has a dynamic loading interface making plugins on such a host possible at all, but if it has such an interface there is no reason in principle against someone adding support for plugins for a cross compiler and linker from Tru64 to an ELF target.) Tru64 UNIX supports dlopen(3), so you should be set. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40790
[Bug lto/40790] plugin-api.h unconditionally includes stdint.h
--- Comment #15 from espindola at google dot com 2009-10-09 13:30 --- Why the complications? Just use GCC_HEADER_STDINT in both gcc and gold and be done with it. If the intention is for gold to support platforms beyond GNU/Linux with ELF, it will run into the need sooner or later anyway. I assumed GCC_HEADER_STDINT was gcc specific :-) Will try to code a patch with your suggestion. Rainer Thanks, Rafael -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40790
[Bug lto/40790] plugin-api.h unconditionally includes stdint.h
--- Comment #16 from joseph at codesourcery dot com 2009-10-09 14:44 --- Subject: Re: plugin-api.h unconditionally includes stdint.h On Fri, 9 Oct 2009, ro at techfak dot uni-bielefeld dot de wrote: gold supports non-ELF hosts (or will once Andrew Pinski's MinGW host patches are in), and in due course should support plugins on such hosts. Ok, but only as a cross-linker to ELF targets, I suppose? Yes. Non-ELF targets only via converting from ELF to some other format after linking (like uClinux targets using FLT, or arm-symbianelf, do right now with a separate converter not included in binutils). (Unlike gold, nothing in the design of LTO strongly links it to ELF; it uses ELF as a container for bytecode streams but should be adaptable to be able to use other formats - that allow arbitrary user-defined sections - as well if someone wishes to do so, and all that should be needed is a replacement of lto-elf.c for the other format or a generic version of it using BFD.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40790
[Bug lto/40790] plugin-api.h unconditionally includes stdint.h
--- Comment #9 from espindola at google dot com 2009-10-08 18:20 --- (In reply to comment #8) Raphael, can you look into this? Sure. Sorry about the delay. The only thing the compiler should need the plugin-api.h for is the enum ld_plugin_symbol_resolution. If we split plugin-api.h in two, we would be able to compile gcc itself without stdint.h. The problem with this approach is that the lto plugin would still fail to build in a system without stdint.h. Is it OK to have optional features like the gold plugin not supported in systems like Tru64 UNIX V4.0F? Yet another possibility would be to change the build system so that we always build the lto plugin with xgcc (in addition to the plugin-api.h split). No idea how hard this is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40790
[Bug lto/40790] plugin-api.h unconditionally includes stdint.h
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-10-07 09:33 --- Raphael, can you look into this? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||espindola at google dot com OtherBugsDependingO||41588 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40790
[Bug lto/40790] plugin-api.h unconditionally includes stdint.h
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-10-06 16:32 --- *** Bug 41607 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||sje at cup dot hp dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40790
[Bug lto/40790] plugin-api.h unconditionally includes stdint.h
--- Comment #6 from ro at techfak dot uni-bielefeld dot de 2009-10-05 12:51 --- Subject: Re: plugin-api.h unconditionally includes stdint.h --- Comment #5 from rguenth at gcc dot gnu dot org 2009-10-04 20:27 --- Rainer, I think the checks are in place to properly set HAVE_STDINT_H and HAVE_INTTYPES_H or provide defines for intptr_t and uintptr_t. Can you do actual verification if comment #2 fixes your issue? It works in IRIX 6.5 where the HAVE_STDINT_H check detects that the file, while present, doesn't work properly, and falls back to inttypes.h. It also works on Tru64 UNIX V5.1B, which lacks stdint.h, but has inttypes.h. I wouldn't have expected that lto-plugin.h is used on a non-ELF platform at all. It will break on Tru64 UNIX V4.0F which also lacks inttypes.h, since no replacement definitions of *intptr_t are present yet. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40790
[Bug lto/40790] plugin-api.h unconditionally includes stdint.h
--- Comment #4 from danglin at gcc dot gnu dot org 2009-10-04 20:11 --- The problem is also present on hppa64-hp-hpux11.11 with GCC versions earlier than 4.5. Comment #2 fixes the compilation error on this target. -- danglin at gcc dot gnu dot org changed: What|Removed |Added CC||danglin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40790
[Bug lto/40790] plugin-api.h unconditionally includes stdint.h
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-10-04 20:27 --- Rainer, I think the checks are in place to properly set HAVE_STDINT_H and HAVE_INTTYPES_H or provide defines for intptr_t and uintptr_t. Can you do actual verification if comment #2 fixes your issue? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40790
[Bug lto/40790] plugin-api.h unconditionally includes stdint.h
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-09-16 13:20 --- Does replacing the #include with #ifdef HAVE_STDINT_H #include stdint.h #endif #ifdef HAVE_INTTYPES_H #include inttypes.h #endif work for you? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40790
[Bug lto/40790] plugin-api.h unconditionally includes stdint.h
--- Comment #3 from ro at techfak dot uni-bielefeld dot de 2009-09-16 14:37 --- Subject: Re: plugin-api.h unconditionally includes stdint.h --- Comment #2 from rguenth at gcc dot gnu dot org 2009-09-16 13:20 --- Does replacing the #include with #ifdef HAVE_STDINT_H #include stdint.h #endif #ifdef HAVE_INTTYPES_H #include inttypes.h #endif work for you? The first part won't help on IRIX 6.5, which has stdint.h, but it's unusable in non-C99 mode. This is fixed (via fixincludes) in recent versions of gcc, though, which one could require to bootstrap. But again, if one bootstraps e.g with MIPSpro cc, it would fail again. The second part should help for e.g. Tru64 UNIX V5.1B, which has inttypes.h, but not on V4.0F, which lacks it. What needs to happen, I think, is a check if some header provides the necessary types and provide them otherwise. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40790
[Bug lto/40790] plugin-api.h unconditionally includes stdint.h
--- Comment #1 from bje at gcc dot gnu dot org 2009-07-22 00:02 --- Confirmed. -- bje at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-07-22 00:02:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40790
