From mboxrd@z Thu Jan 1 00:00:00 1970 From: David.Billinghurst@riotinto.com To: gcc-gnats@gcc.gnu.org Subject: libgcj/1736: [irix 6.5] Cannot create libgcj - Arg list too long Date: Sun, 01 Apr 2001 00:00:00 -0000 Message-id: <20010122234744.22312.qmail@sourceware.cygnus.com> X-SW-Source: 2001-q1/msg00611.html List-Id: >Number: 1736 >Category: libgcj >Synopsis: [irix 6.5] Cannot create libgcj - Arg list too long >Confidential: no >Severity: serious >Priority: medium >Responsible: unassigned >State: open >Class: sw-bug >Submitter-Id: net >Arrival-Date: Mon Jan 22 15:56:05 PST 2001 >Closed-Date: >Last-Modified: >Originator: David Billinghurst >Release: cvs 20010115 >Organization: >Environment: mips-sgi-ixi6.5 >Description: Cannot create ligcj.la. Apparently this is a known problem. `/exd4/billingd/obj/gcc-java/mips-sgi-irix6.5/mabi=64/libjava' /bin/sh ./libtool --mode=link /exd4/billingd/obj/gcc-java/gcc/xgcc -B/exd4/billingd/obj/gcc-java/gcc/ -B/exd4/billingd/tmp/gcc/mips-sgi-irix6.5/bin/ -B/exd4/billingd/tmp/gcc/mips-sgi-irix6.5/lib/ -isystem /exd4/billingd/tmp/gcc/mips-sgi-irix6.5/include -mabi=64 -L/exd4/billingd/obj/gcc-java/mips-sgi-irix6.5/mabi=64/libjava -g -mabi=64 -o libgcj.la -rpath /exd4/billingd/tmp/gcc/lib/mabi=64 -L/exd4/billingd/obj/gcc-java/mips-sgi-irix6.5/mabi=64/libjava/../libstdc++- v3/libsupc++ -lsupc++ -rpath /exd4/billingd/tmp/gcc/lib/mabi=64 -version-info `grep -v '^#' /exd4/billingd/src/gcc/libjava/libtool-version` prims.lo posix.lo jni.lo ... ... ... /lang/s_sin.lo boehm.lo no-threads.lo `ar t ../libffi/.libs/libffi.a 2>/dev/null | sed 's/\.o/\.lo/g' | sed 's/^/..\/libffi\//g'` ./libltdl/libltdlc.la make[4]: execvp: /bin/sh: Arg list too long make[4]: *** [libgcj.la] Error 127 >How-To-Repeat: With cvs gcc, enable libgcj in top level configure.in make bootstrap >Fix: Is it possible to build libgcj incrementally? >Release-Note: >Audit-Trail: >Unformatted: >>From fgouget@codeweavers.com Sun Apr 01 00:00:00 2001 From: fgouget@codeweavers.com To: gcc-gnats@gcc.gnu.org Subject: c++/1600: The placement of __attribute__ confuses g++ Date: Sun, 01 Apr 2001 00:00:00 -0000 Message-id: <20010110025645.2466.qmail@sourceware.cygnus.com> X-SW-Source: 2001-q1/msg00134.html Content-length: 2889 >Number: 1600 >Category: c++ >Synopsis: The placement of __attribute__ confuses g++ >Confidential: no >Severity: serious >Priority: medium >Responsible: unassigned >State: open >Class: rejects-legal >Submitter-Id: net >Arrival-Date: Tue Jan 09 19:06:00 PST 2001 >Closed-Date: >Last-Modified: >Originator: Francois Gouget >Release: CVS 2001/01/08 >Organization: >Environment: Debian Linux on Intel ('testing' distribution as of about 2001/01/08) libc6: 2.2-6 >Description: When compiling the code included below with g++ from CVS 2001/01/08 I get: $ /usr/local/opt/gcc-20010108/bin/g++ -c test1.cpp test1.cpp:14: cannot convert `void (*)()' to `void (*)()' for argument `1' to `int atexit(void (*)())' Here's more information about g++ used: $ /usr/local/opt/gcc-20010108/bin/g++ -v Reading specs from /usr/local/opt/gcc-20010108/bin/../lib/gcc-lib/i686-pc-linux-gnu/2.97/specs Configured with: ./src/configure --prefix=/usr/local/opt/gcc --exec-prefix=/usr/local/opt/gcc --enable-shared --enable-threads --enable-languages=c,c++ gcc version 2.97 20010108 (experimental) The same code compiles fine if the second declaration of m_func is used instead of the first one, or if one uses g++ 2.95.2. On my machine that would be: $ g++ -v Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.2/specs gcc version 2.95.2 20000220 (Debian GNU/Linux) Maybe the placement of __attribute__ is illegal, although it does seem allowed in other contexts, but in any case g++ should not complain about the call to atexit (which is why I have set Class to rejects-legal). Before I managed to reproduce this problem in a small example I had this problem in a piece of code (in the MFC) where m_func and the atexit call were thousands of lines apart. I found that fixing all the m_func-style definitions as per the workaround was necessary before g++ would stop complaining about atexit. This problem seems to only affect the declaration of pointers to function that are a field of a class. If the declaration concerns a global variable or a function parameter the placement of __attribute__ seems to cause no ill side-effect (i.e. I did not have to change those). On last word: the reason I'm using g++ from CVS is because I need the '__attribute__((com_interface))'. >How-To-Repeat: Compile the following: --- cut here --- extern int atexit (void (*__func) (void)) throw (); class SomeClass { public: void (__attribute__((__stdcall__)) *m_func)(); //void __attribute__((__stdcall__)) (*m_func)(); }; void foo() { } char _term = (char)atexit(&foo); --- cut here --- >Fix: The workaround is to move __attribute__ out of the parenthesis enclosing the name of the pointer to function (see the commented out declaration of m_func). >Release-Note: >Audit-Trail: >Unformatted: >>From lerdsuwa@gcc.gnu.org Sun Apr 01 00:00:00 2001 From: lerdsuwa@gcc.gnu.org To: lerdsuwa@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org Subject: Re: c++/1733 Date: Sun, 01 Apr 2001 00:00:00 -0000 Message-id: <20010220082601.3533.qmail@sourceware.cygnus.com> X-SW-Source: 2001-q1/msg01511.html Content-length: 540 The following reply was made to PR c++/1733; it has been noted by GNATS. From: lerdsuwa@gcc.gnu.org To: gcc-gnats@gcc.gnu.org, lerdsuwa@gcc.gnu.org, snyder@fnal.gov Cc: Subject: Re: c++/1733 Date: 20 Feb 2001 08:24:29 -0000 Synopsis: C++ ICE in copy_body_r with optimization on State-Changed-From-To: analyzed->closed State-Changed-By: lerdsuwa State-Changed-When: Tue Feb 20 00:24:29 2001 State-Changed-Why: Fixed in the mainline and gcc 3.0 branch. http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=1733&database=gcc