gcc Digest 20 Dec 2004 20:55:56 -0000 Issue 3935
Topics (messages 106857 through 106886):
cp tree question
106857 by: Stefan Strasser <sstrasser@systemhaus-gruppe.de>
Compiling for FreeBSD
106858 by: DarkPhoton <darkphotn@yahoo.com>
CVS Head: libada build fails
106859 by: Andreas Jaeger <aj@suse.de>
106860 by: Christian Joensson <christian.joensson@gmail.com>
106861 by: Andreas Jaeger <aj@suse.de>
106863 by: kenner@vlsi1.ultra.nyu.edu (Richard Kenner)
106864 by: kenner@vlsi1.ultra.nyu.edu (Richard Kenner)
106865 by: Eric Botcazou <ebotcazou@libertysurf.fr>
106866 by: Graham Stott <graham.stott@btinternet.com>
106867 by: kenner@vlsi1.ultra.nyu.edu (Richard Kenner)
gcc 4.0 libgcc_eh static linking
106862 by: "Roland Lengfeldner" <lengfeldner_roland@gmx.at>
The problem compiling s-fileio.adb
106868 by: kenner@vlsi1.ultra.nyu.edu (Richard Kenner)
Warning for different pointer signedness
106869 by: "Giovanni Bajo" <giovannibajo@libero.it>
106879 by: Paul Schlie <schlie@comcast.net>
106880 by: Andrew Pinski <pinskia@physics.uc.edu>
106885 by: Paul Schlie <schlie@comcast.net>
106886 by: Andrew Pinski <pinskia@physics.uc.edu>
Building GCC crosscompiler for powerpc platform !!
106870 by: "Manish Shah" <manish@juniper.net>
106871 by: jf <j_f@laposte.net>
-fdump-translation-unit considered harmful
106872 by: Joe Buck <Joe.Buck@synopsys.COM>
106874 by: Joe Buck <Joe.Buck@synopsys.COM>
PATCH: Ignore --disable-static in libiberty
106873 by: Alexandre Oliva <aoliva@redhat.com>
106876 by: "H. J. Lu" <hjl@lucon.org>
106877 by: Andrew Pinski <pinskia@physics.uc.edu>
106878 by: "H. J. Lu" <hjl@lucon.org>
106884 by: Alexandre Oliva <aoliva@redhat.com>
-fdump-translation-unit considered harmful (was Re: cp tree question)
106875 by: Joe Buck <Joe.Buck@synopsys.COM>
Compiling gnat with a different gcc
106881 by: "Luke A. Guest" <laguest@abyss2.demon.co.uk>
Popping registers
106882 by: "Sam Lauber" <sam124@operamail.com>
gcc pragma pack on hpux
106883 by: Eric Frias <efrias@syncad.com>
Administrivia:
To subscribe to the digest, e-mail:
gcc-digest-subscribe@gcc.gnu.org
To unsubscribe from the digest, e-mail:
gcc-digest-unsubscribe@gcc.gnu.org
To post to the list, e-mail:
gcc@gcc.gnu.org
----------------------------------------------------------------------
------------------------------------------------------------------------
Subject:
Re: cp tree question
From:
Stefan Strasser <sstrasser@systemhaus-gruppe.de>
Date:
Mon, 20 Dec 2004 04:49:27 +0100
To:
Stefan Strasser <sstrasser@systemhaus-gruppe.de>
To:
Stefan Strasser <sstrasser@systemhaus-gruppe.de>
CC:
gcc@gcc.gnu.org
this is additional information on this subject I sent here two days
ago which caused the dump-translation-unit discussion.
answers to bug 19073 please, not here.
---
ok, I took a closer look at this.
we all agree that type_decls(even c++ implicit ones) should be in
cp_binding_level::names, don't we?
decls get added to this list by name-lookup.c add_decl_to_level(),
which gets called by name-lookup.c:pushdecl()
pushdecl() checks if there is already a binding for the decl(via
namespace_binding()).
if there is(which is the case for the implicit type decls in current
version), it only calls add_decl_to_level() under certain
circumstances, one of these is: not being a TYPE_DECL.
in gcc version 3.3.4(which doesn't have this problem)
namespace_binding() returns 0, there is no binding, in current CVS
there is.
so, why is this?
because of these lines in
name-lookup.c:set_identifier_type_value_with_scope:
if (binding->value)
supplement_binding (binding, decl);
else
binding->value = decl;
I understand what they're doing but I don't understand why they are at
this point and were introduced in decl.c version 1.1114.
the cvs log message doesn't contain anything that's useful to me either.
why are these lines there? before this there was no assignment to
binding->value at all.
Thanks for your help
---
Stefan Strasser schrieb:
Good morning,
I'm wondering if it is a bug or desired behaviour that, in the current
release version of gcc, TREE_CHAIN()ing the cp_namespace_decls() result
doesn't bring up type_decl nodes of c++ enum's, but gcc version 3.3.4
does?
have they been moved into another list?
you can easily check this with -fdump-translation-unit on the code "enum
blah{};". there is no blah in the .tu file with version 3.4.3.
(don't put any enumerators in there because so the type_decl node gets
queued by the DECL_TYPE() of the enumerator node. but it's not in
cp_namespace_decls())
thanks for your help,
------------------------------------------------------------------------
Subject:
Compiling for FreeBSD
From:
DarkPhoton <darkphotn@yahoo.com>
Date:
Mon, 20 Dec 2004 00:31:09 -0800 (PST)
To:
gcc@gcc.gnu.org
To:
gcc@gcc.gnu.org
I have a working copy of GCC, running on WinXP. I need to compile
programs for FreeBSD (to upload to a webserver), but do not have root
access to the target FreeBSD machine. How do I set up GCC to compile
FreeBSD executables from a WinXP machine?
Many thanks.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
------------------------------------------------------------------------
Subject:
CVS Head: libada build fails
From:
Andreas Jaeger <aj@suse.de>
Date:
Mon, 20 Dec 2004 09:47:06 +0100
To:
gcc@gcc.gnu.org
To:
gcc@gcc.gnu.org
On Linux/AMD64 with current CVS building of Ada fails for me when
building the shared libada with the following error. Any ideas on who
to fix this?
/builds/gcc/misc/gcc/xgcc -B/builds/gcc/misc/gcc/ -B/opt/gcc/4.0-devel/x86_64-su
se-linux-gnu/bin/ -B/opt/gcc/4.0-devel/x86_64-suse-linux-gnu/lib/ -isystem /opt/
gcc/4.0-devel/x86_64-suse-linux-gnu/include -isystem /opt/gcc/4.0-devel/x86_64-s
use-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I/cvs/gcc/libgfortran -I. -iquote
/cvs/gcc/libgfortran/io -O2 -g -O2 -std=gnu99 -O2 -g -O2 -m32 -c /cvs/gcc/libgfo
rtran/generated/minloc1_8_i8.c -fPIC -DPIC -o .libs/minloc1_8_i8.o
s-fileio.adb: In function 'System.File_Io.Finalize':
s-fileio.adb:372: warning: '<anonymous>' is used uninitialized in this function
+===========================GNAT BUG DETECTED==============================+
| 4.0.0 20041220 (experimental) (x86_64-suse-linux-gnu) GCC error: |
| in make_decl_rtl, at varasm.c:867 |
| Error detected at s-fileio.adb:1090:1 |
| Please submit a bug report; see http://gcc.gnu.org/bugs.html. |
| Include the entire contents of this bug box in the report. |
| Include the exact gcc or gnatmake command that you entered. |
| Also include sources listed below in gnatchop format |
| (concatenated together with no headers between files). |
+==========================================================================+
Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:376
make[7]: *** [s-fileio.o] Error 1
make[7]: Leaving directory `/builds/gcc/misc/gcc/ada/rts'
make[6]: *** [gnatlib] Error 2
make[6]: Leaving directory `/builds/gcc/misc/gcc/ada'
make[5]: *** [gnatlib-shared-default] Error 2
Andreas
------------------------------------------------------------------------
Subject:
Re: CVS Head: libada build fails
From:
Christian Joensson <christian.joensson@gmail.com>
Date:
Mon, 20 Dec 2004 09:51:49 +0100
To:
Andreas Jaeger <aj@suse.de>
To:
Andreas Jaeger <aj@suse.de>
CC:
gcc@gcc.gnu.org
On Mon, 20 Dec 2004 09:47:06 +0100, Andreas Jaeger <aj@suse.de> wrote:
On Linux/AMD64 with current CVS building of Ada fails for me when
building the shared libada with the following error. Any ideas on who
to fix this?
uhm, what's the status of 64-bit compilation of Ada?
------------------------------------------------------------------------
Subject:
Re: CVS Head: libada build fails
From:
Andreas Jaeger <aj@suse.de>
Date:
Mon, 20 Dec 2004 10:00:02 +0100
To:
Christian Joensson <christian.joensson@gmail.com>
To:
Christian Joensson <christian.joensson@gmail.com>
CC:
gcc@gcc.gnu.org
Christian Joensson <christian.joensson@gmail.com> writes:
On Mon, 20 Dec 2004 09:47:06 +0100, Andreas Jaeger <aj@suse.de> wrote:
On Linux/AMD64 with current CVS building of Ada fails for me when
building the shared libada with the following error. Any ideas on who
to fix this?
uhm, what's the status of 64-bit compilation of Ada?
Builds but has a few failures, I don't know how critical - see
gcc-testresults for details, e.g.:
http://gcc.gnu.org/ml/gcc-testresults/2004-12/msg00821.html (ia64)
http://gcc.gnu.org/ml/gcc-testresults/2004-12/msg00807.html (x86-64)
Andreas
------------------------------------------------------------------------
Subject:
Re: CVS Head: libada build fails
From:
kenner@vlsi1.ultra.nyu.edu (Richard Kenner)
Date:
Mon, 20 Dec 04 08:28:40 EST
To:
aj@suse.de
To:
aj@suse.de
CC:
gcc@gcc.gnu.org
On Linux/AMD64 with current CVS building of Ada fails for me when
building the shared libada with the following error. Any ideas on who
to fix this?
s-fileio.adb: In function 'System.File_Io.Finalize':
s-fileio.adb:372: warning: '<anonymous>' is used uninitialized in this function
| 4.0.0 20041220 (experimental) (x86_64-suse-linux-gnu) GCC error:
| in make_decl_rtl, at varasm.c:867
I saw this last night, but didn't get a chance to investigate before I went
to sleep. If it still happens with this morning's sources, I'll do so this
afternoon.
------------------------------------------------------------------------
Subject:
Re: CVS Head: libada build fails
From:
kenner@vlsi1.ultra.nyu.edu (Richard Kenner)
Date:
Mon, 20 Dec 04 08:31:22 EST
To:
christian.joensson@gmail.com
To:
christian.joensson@gmail.com
CC:
gcc@gcc.gnu.org
uhm, what's the status of 64-bit compilation of Ada?
Used to mostly work. I had only five ACATS failures, though some were fixed
by patches I can't check in yet.
------------------------------------------------------------------------
Subject:
Re: CVS Head: libada build fails
From:
Eric Botcazou <ebotcazou@libertysurf.fr>
Date:
Mon, 20 Dec 2004 14:45:23 +0100
To:
Andreas Jaeger <aj@suse.de>
To:
Andreas Jaeger <aj@suse.de>
CC:
gcc@gcc.gnu.org
s-fileio.adb: In function 'System.File_Io.Finalize':
s-fileio.adb:372: warning: '<anonymous>' is used uninitialized in this
function +===========================GNAT BUG
DETECTED==============================+
| 4.0.0 20041220 (experimental) (x86_64-suse-linux-gnu) GCC error:
| | in make_decl_rtl, at varasm.c:867
| | Error detected at s-fileio.adb:1090:1
| | Please submit a bug report; see http://gcc.gnu.org/bugs.html.
| | Include the entire contents of this bug box in the report.
| | Include the exact gcc or gnatmake command that you entered.
| | Also include sources listed below in gnatchop format
| | (concatenated together with no headers between files).
| |
+==========================================================================
Same problem on x86.
------------------------------------------------------------------------
Subject:
Re: CVS Head: libada build fails
From:
Graham Stott <graham.stott@btinternet.com>
Date:
Mon, 20 Dec 2004 13:55:33 +0000 (GMT)
To:
Richard Kenner <kenner@vlsi1.ultra.nyu.edu>, aj@suse.de
To:
Richard Kenner <kenner@vlsi1.ultra.nyu.edu>, aj@suse.de
CC:
gcc@gcc.gnu.org
--- Richard Kenner <kenner@vlsi1.ultra.nyu.edu> wrote:
On Linux/AMD64 with current CVS building of Ada fails for me when
building the shared libada with the following error. Any ideas on who
to fix this?
s-fileio.adb: In function 'System.File_Io.Finalize':
s-fileio.adb:372: warning: '<anonymous>' is used uninitialized in this
function
| 4.0.0 20041220 (experimental) (x86_64-suse-linux-gnu) GCC error:
| in make_decl_rtl, at varasm.c:867
I saw this last night, but didn't get a chance to investigate before I went
to sleep. If it still happens with this morning's sources, I'll do so this
afternoon.
I saw this on Sunday's cvs for i686-pc-linux-gnu whereas on Saturday's cvs it
all worked.
------------------------------------------------------------------------
Subject:
Re: CVS Head: libada build fails
From:
kenner@vlsi1.ultra.nyu.edu (Richard Kenner)
Date:
Mon, 20 Dec 04 09:13:30 EST
To:
graham.stott@btinternet.com
To:
graham.stott@btinternet.com
CC:
gcc@gcc.gnu.org
I saw this on Sunday's cvs for i686-pc-linux-gnu whereas on Saturday's
cvs it all worked.
Likewise for me. And it's still broken. So I'll investigate shortly.
------------------------------------------------------------------------
Subject:
gcc 4.0 libgcc_eh static linking
From:
"Roland Lengfeldner" <lengfeldner_roland@gmx.at>
Date:
Mon, 20 Dec 2004 13:25:49 +0100 (MET)
To:
gcc@gcc.gnu.org
To:
gcc@gcc.gnu.org
Hello,
I try to link a C++ shared library with the static libstdc++.a and
libgcc.a/libgcc_eh.a libraries. The target is a shared library which is
independent of any other libraries except libc/libm. This works in gcc
version 2.95.3, 3.4.x and 4.0-20041205. In Version 4.0-20041212 & 20041219
this behaviour is changed. It seems that the parts taken of libgcc_eh are
now defined as local code instead of global code. The library libgcc_eh.a
looks the same in 20041212 & 20041205.
I use nm to see the difference,
nm libHugo | grep Unwind
Version 20041205 shows:
T _Unwind_Resume
whereas Version 20041212 shows:
t _Unwind_Resume
Information:
Host: i686-pc-linux-gnu
Binutils: 2.15
Reading specs from /opt/gcc_40a/lin6/lib/gcc/i686-pc-linux-gnu/4.0.0/specs
Configured with: /opt/gcc_compile/gcc-4.0-20041219/configure
--prefix=/opt/gcc_40a/lin6 --disable-nls --with-local-prefix=/opt/tools/lin6
--with-gnu-as --with-as=/opt/gcc_40a/lin6/bin/as --with-gnu-ld
--with-ld=/opt/gcc_40a/lin6/bin/ld --enable-__cxa_atexit
--enable-threads=posix --enable-shared --enable-languages=c,c++
Thread model: posix
gcc version 4.0.0 20041219 (experimental)
The compiler were bootstrapped and installed from scratch, with the same
options. I use gcc to link all obj files & the std libraries into one shared
object.
The Problem is, that I link another shared library libHugoPerl to the
resulting libHugo, in order have an interface to perl. A workaround would be
to link libgcc_eh.a also to libHugoPerl.
Is this now the correct behaviour, or a bug introduced with version
20041212? I looked through the diff file & furthermore read the mailing
lists but couldn't find anything related to this topic,
Regards,
Roland
------------------------------------------------------------------------
Subject:
The problem compiling s-fileio.adb
From:
kenner@vlsi1.ultra.nyu.edu (Richard Kenner)
Date:
Mon, 20 Dec 04 09:53:29 EST
To:
rth@gcc.gnu.org
To:
rth@gcc.gnu.org
CC:
gcc@gcc.gnu.org
This looks related to the recent changes you've been making to the handling
of variable-sized stuff.
If I grep s-fileio.adb.t03.generic for D.1275, I get
long int D.1275;
D.1275 = system__file_io__temp_file_record__next___OFFSET.22 * 8;
D.1278 = D.1275 /[ex] 8;
D.1609 = D.1275 /[ex] 8;
D.2334 = D.1275 /[ex] 8;
This all looks fine, except that each of the last two lines are in a
different function than the first three and there's no declaration of D.1275
in each of those latter two functions.
Given the extent of usage of variable-size stuff in Ada, it's probably a good
idea to at least build the RTS when you make changes in that area (that won't
be affected by the bootstrap problems you're having).
------------------------------------------------------------------------
Subject:
Warning for different pointer signedness
From:
"Giovanni Bajo" <giovannibajo@libero.it>
Date:
Mon, 20 Dec 2004 16:16:37 +0100
To:
"Mike Stump" <mrs@apple.com>
To:
"Mike Stump" <mrs@apple.com>
CC:
<gcc@gcc.gnu.org>
Mike,
since your patch: http://gcc.gnu.org/ml/gcc-patches/2004-07/msg01284.html has a
great impact on existing codebases (linux kernel guys say it triggers 6.5K
times in full build), would you mind adding an entry about this into
changes.html? It would help also to put a rationale there on why such a change
was made, since we will undoubtly get this asked many times.
Thanks
Giovanni Bajo
------------------------------------------------------------------------
Subject:
Warning for different pointer signedness
From:
Paul Schlie <schlie@comcast.net>
Date:
Mon, 20 Dec 2004 14:56:07 -0500
To:
<gcc@gcc.gnu.org>
To:
<gcc@gcc.gnu.org>
Giovanni Bajo
since your patch: http://gcc.gnu.org/ml/gcc-patches/2004-07/msg01284.html
has a great impact on existing codebases (linux kernel guys say it triggers
6.5K times in full build), would you mind adding an entry about this into
changes.html? It would help also to put a rationale there on why such a change
was made, since we will undoubtly get this asked many times.
It would seem that the change was unnecessary, and possibly even incorrect,
as although the objects they referance are not of the same signedness,
their pointers (which are the objects being compared) are completely
compatible, as the storage size and alignment they reference is defined by
the objects storage class (i.e. char, short, int, long, etc.) which would
seem to be insensitive to the objects signedness, are equivalent.
(although would expect a pedantic warning for (char *)cp == (int *)ip as
pointers to dissimilar storage types may not have equivalent semantics)
------------------------------------------------------------------------
Subject:
Re: Warning for different pointer signedness
From:
Andrew Pinski <pinskia@physics.uc.edu>
Date:
Mon, 20 Dec 2004 14:57:55 -0500
To:
Paul Schlie <schlie@comcast.net>
To:
Paul Schlie <schlie@comcast.net>
CC:
<gcc@gcc.gnu.org>
On Dec 20, 2004, at 2:56 PM, Paul Schlie wrote:
Giovanni Bajo
since your patch:
http://gcc.gnu.org/ml/gcc-patches/2004-07/msg01284.html
has a great impact on existing codebases (linux kernel guys say it
triggers
6.5K times in full build), would you mind adding an entry about this
into
changes.html? It would help also to put a rationale there on why
such a change
was made, since we will undoubtly get this asked many times.
It would seem that the change was unnecessary, and possibly even
incorrect,
as although the objects they referance are not of the same signedness,
their pointers (which are the objects being compared) are completely
compatible, as the storage size and alignment they reference is
defined by
the objects storage class (i.e. char, short, int, long, etc.) which
would
seem to be insensitive to the objects signedness, are equivalent.
Wrong, wrong, wrong, the change only moved a warning from -pedantic
to always on, in fact some compilers reject the code as it is invalid c.
-- Pinski
------------------------------------------------------------------------
Subject:
Re: Warning for different pointer signedness
From:
Paul Schlie <schlie@comcast.net>
Date:
Mon, 20 Dec 2004 15:47:25 -0500
To:
Andrew Pinski <pinskia@physics.uc.edu>
To:
Andrew Pinski <pinskia@physics.uc.edu>
CC:
<gcc@gcc.gnu.org>
From: Andrew Pinski <pinskia@physics.uc.edu>
Wrong, wrong, wrong, the change only moved a warning from -pedantic
to always on, in fact some compilers reject the code as it is invalid c.
-- Pinski
Which seems odd given (signed xxx *) and (unsigned xxx *) will always be
guaranteed to be pointers to the exact same size and aligned storage units;
(therefore at best, seems like a mistake to consider them incompatible
objects for the purpose of comparison, as no possible ambiguity exists).
------------------------------------------------------------------------
Subject:
Re: Warning for different pointer signedness
From:
Andrew Pinski <pinskia@physics.uc.edu>
Date:
Mon, 20 Dec 2004 15:55:11 -0500
To:
Paul Schlie <schlie@comcast.net>
To:
Paul Schlie <schlie@comcast.net>
CC:
<gcc@gcc.gnu.org>
On Dec 20, 2004, at 3:47 PM, Paul Schlie wrote:
From: Andrew Pinski <pinskia@physics.uc.edu>
Wrong, wrong, wrong, the change only moved a warning from -pedantic
to always on, in fact some compilers reject the code as it is
invalid c.
-- Pinski
Which seems odd given (signed xxx *) and (unsigned xxx *) will always be
guaranteed to be pointers to the exact same size and aligned storage
units;
(therefore at best, seems like a mistake to consider them incompatible
objects for the purpose of comparison, as no possible ambiguity exists).
The warning is only there for an implicit conversions nothing else, if
you
add a cast it will not warn. Well this is what the C standard say so
you are wrong again.
6.3.2.3 describes the conversions. Again this is invalid C (and C++ in
fact) so a warning is correct.
The only implicit conversion for pointers in C is to and from void*.
-- Pinski
------------------------------------------------------------------------
Subject:
Building GCC crosscompiler for powerpc platform !!
From:
"Manish Shah" <manish@juniper.net>
Date:
Mon, 20 Dec 2004 21:09:34 +0530
To:
<gcc@gnu.org>
To:
<gcc@gnu.org>
I am trying to build the GCC toolchain using the GCC-3.4.0, binutils-2.15 and the latest version of newlib, I am facing the following build error, which makes me think that probably my configuration is incorrect.
checking for inline... (cached) inline
checking whether byte ordering is bigendian... (cached) unknown
checking to probe for byte ordering... /usr/local/powerpc/powerpc-eabi/bin/ld: warning: cannot find entry symbol _start; defaulting to 01800074
/usr/local/src/gnu/BUILD/gcc/gcc/libgcc.a(eabi.o)(.text+0xc4): In function `__eabi':
/usr/local/src/gnu/BUILD/gcc/gcc/eabi.S:232: undefined reference to `__init'
/usr/local/src/gnu/BUILD/gcc/gcc/libgcc.a(eabi.o)(.got2+0x8):/usr/local/src/gnu/BUILD/gcc/gcc/eabi.S:146: undefined reference to `__SDATA_START__'
/usr/local/src/gnu/BUILD/gcc/gcc/xgcc -B/usr/local/src/gnu/BUILD/gcc/gcc/ -B/usr/local/powerpc/powerpc-eabi/bin/ -B/usr/local/powerpc/powerpc-eabi/lib/ -isystem /usr/local/powerpc/powerpc-eabi/include -isystem /usr/local/powerpc/powerpc-eabi/sys-include -c -DHAVE_CONFIG_H -O2 -g -O2 -I. -I/usr/local/src/gnu/gcc-3.4.0
/libiberty/../include -W -Wall -Wtraditional -pedantic -fPIC /usr/local/src/gnu/gcc-3.4.0/libiberty/regex.c -o pic/regex.o; \
else true; fi
/usr/local/src/gnu/gcc-3.4.0/libiberty/regex.c:132: warning: conflicting types for built-in function 'malloc'
/usr/local/src/gnu/gcc-3.4.0/libiberty/regex.c:160:25: strings.h: No such file or directory
In file included from /usr/local/src/gnu/gcc-3.4.0/libiberty/../include/xregex.h:26,
from /usr/local/src/gnu/gcc-3.4.0/libiberty/regex.c:195:
/usr/local/src/gnu/gcc-3.4.0/libiberty/../include/xregex2.h:548: warning: ISO C90 does not support `static' or type qualifiers in parameter array declarators
/usr/local/src/gnu/gcc-3.4.0/libiberty/regex.c: In function `init_syntax_once':
/usr/local/src/gnu/gcc-3.4.0/libiberty/regex.c:286: warning: implicit declaration of function `bzero'
/usr/local/src/gnu/gcc-3.4.0/libiberty/regex.c:8178: warning: unused parameter 'preg'
make[1]: *** [regex.o] Error 1
make[1]: Leaving directory `/usr/local/src/gnu/BUILD/gcc/powerpc-eabi/libiberty'
make: *** [all-target-libiberty] Error 2
Please Help,
Manish.
------------------------------------------------------------------------
Subject:
Re: Building GCC crosscompiler for powerpc platform !!
From:
jf <j_f@laposte.net>
Date:
Mon, 20 Dec 2004 17:02:36 +0100
To:
gcc@gnu.org
To:
gcc@gnu.org
Hi,
Didn't you get an earlier error ?
It may be usefull to provide the configure command you used...
regards,
JF
Manish Shah a écrit :
I am trying to build the GCC toolchain using the GCC-3.4.0,
binutils-2.15 and the latest version of newlib, I am facing the
following build error, which makes me think that probably my
configuration is incorrect.
checking for inline... (cached) inline
[...]
make: *** [all-target-libiberty] Error 2
Please Help,
Manish.
------------------------------------------------------------------------
Subject:
Re: -fdump-translation-unit considered harmful
From:
Joe Buck <Joe.Buck@synopsys.COM>
Date:
Mon, 20 Dec 2004 09:27:42 -0800
To:
Paul Brook <paul@codesourcery.com>
To:
Paul Brook <paul@codesourcery.com>
CC:
gcc@gcc.gnu.org, Gabriel Dos Reis <gdr@integrable-solutions.net>, Zack
Weinberg <zack@codesourcery.com>, Stefan Strasser
<sstrasser@systemhaus-gruppe.de>
On Sat, Dec 18, 2004 at 03:13:50PM +0000, Paul Brook wrote:
| Me ranting about -fdump-translation-unit had nothing to do with your
| problem, really, it's just that your message reminded me that I was
| going to bring that up.
I think -fdump-translation-unit should remain. I thereby volunteer to
take any question about it.
Ok: Where can I find the documentation for it?
Given this is intended for third party utilities it should be a stable and
well documented interface, right?
It is most emphatically *not* intended for third-party utilities. It is
not intended to be a path to interface other software to GCC; it's a debugging
aid.
------------------------------------------------------------------------
Subject:
Re: -fdump-translation-unit considered harmful
From:
Joe Buck <Joe.Buck@synopsys.COM>
Date:
Mon, 20 Dec 2004 09:35:03 -0800
To:
"Aaron W. LaFramboise" <aaronavay62@aaronwl.com>
To:
"Aaron W. LaFramboise" <aaronavay62@aaronwl.com>
CC:
Robert Dewar <dewar@adacore.com>, Stefan Strasser
<sstrasser@systemhaus-gruppe.de>, Gabriel Dos Reis
<gdr@integrable-solutions.net>, gcc@gcc.gnu.org
On Sun, Dec 19, 2004 at 02:35:06PM -0600, Aaron W. LaFramboise wrote:
4. A binary API that interfaced with GCC would require the client party
to the interface to adhere to the GPL, and thereby require the client to
be /free software/. Would this address Richard Stallman's concerns
about the danger of making it easy for proprietary non-free programs to
freeload off GCC?
For anyone interested in interfacing proprietary programs to GCC, that's
not even much of a speed bump.
As soon as that binary API is written, someone will write a small calling
program that will use the API to dump the translation unit into a nicely
documented XML format. The dumper will, of course, be released under the
GPL. Then the proprietary backend will simply read in the XML data.
That said, in the long term the free software world needs good code
analysis tools, so I suspect that at some point the FSF will have to
revisit this policy.
I understand the "GCC should be a compiler only." arguments, but it
seems there is a genuine demand in the free software community for a
high-quality source analyzer, particularly for languages like C++ where
this is not trivial. GCC seems to be very nearly where it needs to be
to fill this need.
Agreed; in any case the proprietary software world just licenses a very good
C++ front end from [some company, since we're not supposed to plug proprietary
software on this list, but most of us know who], for quite reasonable cost,
so the fact that they can't use the g++ front end doesn't slow them down
much.
But this is an argument that you'll have to make with RMS.
------------------------------------------------------------------------
Subject:
Re: PATCH: Ignore --disable-static in libiberty
From:
Alexandre Oliva <aoliva@redhat.com>
Date:
20 Dec 2004 15:28:39 -0200
To:
"H. J. Lu" <hjl@lucon.org>
To:
"H. J. Lu" <hjl@lucon.org>
CC:
binutils@sources.redhat.com, gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org
On Dec 19, 2004, "H. J. Lu" <hjl@lucon.org> wrote:
+# FIXME: libiberty doesn't support --disable-static
+enable_static=yes
You shouldn't need this in general. AM_DISABLE_SHARED should take
care of implicitly enabling static, unless --disable-static is
actually given in the command line. If libiberty absolutely needs the
static libiberty.a, then I can see why you'd want this (but I'd at
least print a warning); otherwise, I'd just leave it alone, and if
someone configures with --disable-static, they get what they asked
for.
------------------------------------------------------------------------
Subject:
Re: PATCH: Ignore --disable-static in libiberty
From:
"H. J. Lu" <hjl@lucon.org>
Date:
Mon, 20 Dec 2004 10:39:15 -0800
To:
Alexandre Oliva <aoliva@redhat.com>
To:
Alexandre Oliva <aoliva@redhat.com>
CC:
binutils@sources.redhat.com, gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org
On Mon, Dec 20, 2004 at 03:28:39PM -0200, Alexandre Oliva wrote:
On Dec 19, 2004, "H. J. Lu" <hjl@lucon.org> wrote:
+# FIXME: libiberty doesn't support --disable-static
+enable_static=yes
You shouldn't need this in general. AM_DISABLE_SHARED should take
care of implicitly enabling static, unless --disable-static is
actually given in the command line. If libiberty absolutely needs the
static libiberty.a, then I can see why you'd want this (but I'd at
least print a warning); otherwise, I'd just leave it alone, and if
someone configures with --disable-static, they get what they asked
for.
Apparently, they do
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19072
and expect --disable-static to work.
H.J.
------------------------------------------------------------------------
Subject:
Re: PATCH: Ignore --disable-static in libiberty
From:
Andrew Pinski <pinskia@physics.uc.edu>
Date:
Mon, 20 Dec 2004 13:41:01 -0500
To:
"H. J. Lu" <hjl@lucon.org>
To:
"H. J. Lu" <hjl@lucon.org>
CC:
binutils@sources.redhat.com, gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org,
Alexandre Oliva <aoliva@redhat.com>
On Dec 20, 2004, at 1:39 PM, H. J. Lu wrote:
On Mon, Dec 20, 2004 at 03:28:39PM -0200, Alexandre Oliva wrote:
On Dec 19, 2004, "H. J. Lu" <hjl@lucon.org> wrote:
+# FIXME: libiberty doesn't support --disable-static
+enable_static=yes
You shouldn't need this in general. AM_DISABLE_SHARED should take
care of implicitly enabling static, unless --disable-static is
actually given in the command line. If libiberty absolutely needs the
static libiberty.a, then I can see why you'd want this (but I'd at
least print a warning); otherwise, I'd just leave it alone, and if
someone configures with --disable-static, they get what they asked
for.
Apparently, they do
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19072
and expect --disable-static to work.
Well it is more than just that, AIX was also broken even without
--disable-static ...
-- Pinski
------------------------------------------------------------------------
Subject:
Re: PATCH: Ignore --disable-static in libiberty
From:
"H. J. Lu" <hjl@lucon.org>
Date:
Mon, 20 Dec 2004 10:45:22 -0800
To:
Andrew Pinski <pinskia@physics.uc.edu>
To:
Andrew Pinski <pinskia@physics.uc.edu>
CC:
binutils@sources.redhat.com, gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org,
Alexandre Oliva <aoliva@redhat.com>
On Mon, Dec 20, 2004 at 01:41:01PM -0500, Andrew Pinski wrote:
On Dec 20, 2004, at 1:39 PM, H. J. Lu wrote:
On Mon, Dec 20, 2004 at 03:28:39PM -0200, Alexandre Oliva wrote:
On Dec 19, 2004, "H. J. Lu" <hjl@lucon.org> wrote:
+# FIXME: libiberty doesn't support --disable-static
+enable_static=yes
You shouldn't need this in general. AM_DISABLE_SHARED should take
care of implicitly enabling static, unless --disable-static is
actually given in the command line. If libiberty absolutely needs the
static libiberty.a, then I can see why you'd want this (but I'd at
least print a warning); otherwise, I'd just leave it alone, and if
someone configures with --disable-static, they get what they asked
for.
Apparently, they do
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19072
and expect --disable-static to work.
Well it is more than just that, AIX was also broken even without
--disable-static ...
We were talking if libiberty needed
enable_static=yes
in configure.ac and NOTHING ELSE. It is unrelated to the AIX prolem.
H.J.
------------------------------------------------------------------------
Subject:
Re: PATCH: Ignore --disable-static in libiberty
From:
Alexandre Oliva <aoliva@redhat.com>
Date:
20 Dec 2004 18:45:53 -0200
To:
"H. J. Lu" <hjl@lucon.org>
To:
"H. J. Lu" <hjl@lucon.org>
CC:
binutils@sources.redhat.com, gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org
On Dec 20, 2004, "H. J. Lu" <hjl@lucon.org> wrote:
On Mon, Dec 20, 2004 at 03:28:39PM -0200, Alexandre Oliva wrote:
On Dec 19, 2004, "H. J. Lu" <hjl@lucon.org> wrote:
+# FIXME: libiberty doesn't support --disable-static
+enable_static=yes
You shouldn't need this in general. AM_DISABLE_SHARED should take
care of implicitly enabling static, unless --disable-static is
actually given in the command line. If libiberty absolutely needs the
static libiberty.a, then I can see why you'd want this (but I'd at
least print a warning); otherwise, I'd just leave it alone, and if
someone configures with --disable-static, they get what they asked
for.
Apparently, they do
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19072
and expect --disable-static to work.
I don't read that bug report that way. The error they get is surely
unexpected, and I suspect it's either derived from abusing the libtool
interfaces (e.g., assuming there is going to be a .o file at certain
locations on all platforms, which is not something you can always
assume), or perhaps by missing the patch with the ChangeLog entry
below in libiberty's copy of libtool. The answer depends on whether
the ar invocation that fails is issued by the libiberty Makefile or by
libtool, but this is not clear from the bug report. In either case,
the libiberty invocation of AR is broken on at least some platforms
AFAICT, because you can't assume there's going to be a .o in .libs/
just because --enable-shared was given or implied, just like you can't
assume there's going to be a .o outside .libs just because
--enable-static was given or implied. You have to handle it similarly
to the way libtool does (i.e., looking in the .lo file), including the
bit that was missing before dje's patch was installed.
2004-09-08 David Edelsohn <edelsohn@gnu.org>
* ltmain.sh: Use $pic_object as $non_pic_object if
$non_pic_object=none.
------------------------------------------------------------------------
Subject:
Re: -fdump-translation-unit considered harmful (was Re: cp tree question)
From:
Joe Buck <Joe.Buck@synopsys.COM>
Date:
Mon, 20 Dec 2004 09:37:00 -0800
To:
Gabriel Dos Reis <gdr@integrable-solutions.net>
To:
Gabriel Dos Reis <gdr@integrable-solutions.net>
CC:
Nathan Sidwell <nathan@codesourcery.com>, Zack Weinberg
<zack@codesourcery.com>, gcc@gcc.gnu.org
On Sat, Dec 18, 2004 at 02:31:06PM +0100, Gabriel Dos Reis wrote:
Nathan Sidwell <nathan@codesourcery.com> writes:
| Zack Weinberg wrote:
| > We should get rid of -fdump-translation-unit. It has never done what
| > people think it does, the output format has never been documented, no
| > one cares to improve either of those things, and we now have
| > tree-pretty-print.c which is language-independent and far easier to
| > read. No, it's not machine parseable, but neither is
| > -fdump-translation-unit's format, if you really sit down and think
| > about it.
|
| fine by me.
It would be a real mistake. If you don't care about it, and other
people are using it, that you should leave it useful to those people.
On any sensitive issue like this, dumping the feature would need an SC
decision. If Gaby's willing to maintain it, let it be.
------------------------------------------------------------------------
Subject:
Compiling gnat with a different gcc
From:
"Luke A. Guest" <laguest@abyss2.demon.co.uk>
Date:
Mon, 20 Dec 2004 20:14:06 +0000
To:
GCC ML <gcc@gcc.gnu.org>
To:
GCC ML <gcc@gcc.gnu.org>
Hi,
I've got a gcc installed that is named with a postfix (gcc343) but the
compile fails at xnmake because it doesn't take care of this in the
configure script.
Thanks,
Luke.
------------------------------------------------------------------------
Subject:
Popping registers
From:
"Sam Lauber" <sam124@operamail.com>
Date:
Mon, 20 Dec 2004 21:23:44 +0100
To:
gcc@gcc.gnu.org
To:
gcc@gcc.gnu.org
I was wondering, how do you pop a register (like EAX) into a C variable? Ideally, it would be
void *data = asm("pop (%eax)");
but that gave me a syntax error.
Samuel Lauber
------------------------------------------------------------------------
Subject:
Re: gcc pragma pack on hpux
From:
Eric Frias <efrias@syncad.com>
Date:
Mon, 20 Dec 2004 15:24:22 -0500
To:
John David Anglin <dave@hiauly1.hia.nrc.ca>
To:
John David Anglin <dave@hiauly1.hia.nrc.ca>
CC:
dave.anglin@nrc-cnrc.gc.ca, gcc@gcc.gnu.org
John David Anglin wrote:
[regarding enabling #pragma pack on HP-UX, which for some reason is
disabled in gcc]
The maximum alignment available for bss/common variables is 8 bytes
with the 32-bit SOM linker. That's the only restriction that I'm
aware of, Thus, it may be ok to define HANDLE_PRAGMA_PACK_PUSH_POP
in the file hpux.h.
I've just tried running the GCC test suite (make check-gcc), and it
looks good. I did three tests: first with the gcc-3.4.2 distribution,
next with HANDLE_PRAGMA_PACK_PUSH_POP in pa/pa-hpux.h, and finally
defining HANDLE_PRAGMA_PACK defined instead. The results of all three
tests were identical:
=== gcc Summary ===
# of expected passes 24024
# of expected failures 69
# of unresolved testcases 22
# of untested testcases 7
# of unsupported tests 373
/devel/syncad/build-gcc-3.4.2/gcc/xgcc version 3.4.2
I don't know how you choose which version of #pragma pack should be
enabled for this platform. If the choice is based on what the native
compilers do, it looks like the non-push-pop version is closer to the
desired behavior. The native HP compiler's pragma pack is documented
here:
http://docs.hp.com/en/8/pragmas.htm#pragma-pack
I'd like to make one of these #pragma pack options enabled by default
on HP-UX, unless there's a good reason why it should remain disabled.
Enabling it would make my life a lot easier and my source code a lot
cleaner (I'm not the only one, google turns up a two or three other
discussions where people had to work around the lack of #pragma pack
on hp). If this is possible, what can I do to help make it happen?
Thanks,
Eric
John David Anglin wrote:
I have a question about the HP-UX port of gcc, and from looking at the
gcc Contributors list it looks like you're the person to ask. I'm
working on porting some software (winelib) that makes heavy use of
#pragma pack, and gcc doesn't support this pragma on HP-UX. I was
hoping you could tell me why it is disabled.
I tried adding the HANDLE_PRAGMA_PACK define to gcc's config files and
it looks like #pragma pack started working correctly (I haven't run the
regression tests yet to confirm it).
I don't know. It hasn't come up in the period that I have been
involved in GCC.
If necessary, I think I can use __attribute__((packed,aligned(x))) to
work around this, but it needs to be applied on a
structure-by-structure
basis. The software I'm porting has about 10k lines surrounded by
pragma pack directives, so converting it to use attributes would be
very
tedious.
Do you know if turning on these options will break anything? Is there
any chance future releases of gcc will have this enabled by default?