[Bug lto/40790] New: plugin-api.h unconditionally includes stdint.h

[Bug lto/40790] New: plugin-api.h unconditionally includes stdint.h

[ro at gcc dot gnu dot org]

I tried to build the lto branch as of 20090709 on IRIX 6.5 with GCC 3.4.5 as
bootstrap compiler.  The build fails like this:

% gcc -c  -g -fkeep-inline-functions -DIN_GCC   -W -Wall -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute
-Wold-style-definition -fno-common  -DHAVE_CONFIG_H -I. -I.
-I/vol/gcc/src/gcc-lto/gcc -I/vol/gcc/src/gcc-lto/gcc/.
-I/vol/gcc/src/gcc-lto/gcc/../include
-I/vol/gcc/src/gcc-lto/gcc/../libcpp/include -I/vol/gcc/include
-I/vol/gcc/include -I/vol/gcc/src/gcc-lto/gcc/../libdecnumber
-I/vol/gcc/src/gcc-lto/gcc/../libdecnumber/dpd -I../libdecnumber  
-I/vol/gcc/include -I/vol/gcc/include/libelf 
/vol/gcc/src/gcc-lto/gcc/lto-streamer-in.c -o lto-streamer-in.o
In file included from /vol/gcc/src/gcc-lto/gcc/tree-flow.h:29,
                 from /vol/gcc/src/gcc-lto/gcc/lto-streamer-in.c:36:
/vol/gcc/src/gcc-lto/gcc/gimple.h: In function `gimple_op':
/vol/gcc/src/gcc-lto/gcc/gimple.h:1578: warning: cast discards qualifiers from
pointer target type
/vol/gcc/src/gcc-lto/gcc/gimple.h: In function `gimple_op_ptr':
/vol/gcc/src/gcc-lto/gcc/gimple.h:1592: warning: cast discards qualifiers from
pointer target type
In file included from /vol/gcc/src/gcc-lto/gcc/../include/plugin-api.h:29,
                 from /vol/gcc/src/gcc-lto/gcc/lto-streamer.h:26,
                 from /vol/gcc/src/gcc-lto/gcc/lto-streamer-in.c:49:
/usr/include/stdint.h:5:2: #error This header file is to be used only for c99
mode compilations
make: *** [lto-streamer-in.o] Error 1

While the native IRIX 6.5 stdint.h could be used with -std=c99 (or gnu99), this
will fail completely on platforms that lack stdint.h completely.  Using a
sufficiently new gcc as bootstrap compiler that provides stdint.h itself would
be a workaround, but gcc is supposed to be buildable with any C90 compiler.


-- 
           Summary: plugin-api.h unconditionally includes stdint.h
           Product: gcc
           Version: lto
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: ro 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

[bje at gcc dot gnu dot org]

------- 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|0000-00-00 00:00:00         |2009-07-22 00:02:48
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40790

[Bug lto/40790] plugin-api.h unconditionally includes stdint.h

[rguenth at gcc dot gnu dot org]

------- 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

[ro at techfak dot uni-bielefeld dot de]

------- 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

[danglin at gcc dot gnu dot org]

------- 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

[rguenth at gcc dot gnu dot org]

------- 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

[ro at techfak dot uni-bielefeld dot de]

------- 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

[pinskia at gcc dot gnu dot org]

------- 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

[rguenth at gcc dot gnu dot org]

------- 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

[espindola at google dot com]

------- 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

[ro at techfak dot uni-bielefeld dot de]

------- 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

[espindola at google dot com]

------- 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

[joseph at codesourcery dot com]

------- 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

[ro at techfak dot uni-bielefeld dot de]

------- 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

[ro at techfak dot uni-bielefeld dot de]

------- 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

[espindola at google dot com]

------- 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

[joseph at codesourcery dot com]

------- 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

[ebotcazou at gcc dot gnu dot org]

------- 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

[ebotcazou at gcc dot gnu dot org]

-- 

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

[ebotcazou at gcc dot gnu dot org]

------- 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

[rguenth at gcc dot gnu dot org]

------- 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