Mert Sonsuz
--
View this message in context:
http://www.nabble.com/gcc-4.0.2-t837679.html#a3438878
Sent from the gcc - Dev forum at Nabble.com.
t; Recently I've changed to Suse10.0 which now has gcc 4.0.2, and I'm not
> able to compile my VPN client anymore:
This looks more like a kernel issue. Try getting flames from
linux-kernel@vger.kernel.org instead.
Richard.
Dear all,
I used to work with the Nortel Contivity VPN client (3.3) under Suse9.0
for quite some time. The client had been built using the standard gcc
included in that Suse distribution (3.3.6?).
Recently I've changed to Suse10.0 which now has gcc 4.0.2, and I'm not
able to comp
configure of libstdc++
would take more than a day to complete. See:
http://gcc.gnu.org/ml/gcc-help/2005-05/msg00307.html
and its follow ups for more info.
I started with gcc 3.3.2.
#!/bin/sh
ulimit -S -d unlimited
export CONFIG_SHELL=/usr/local/bin/bash
../gcc-4.0.2/configure -v
Anatoly Krivitsky wrote:
>
> Have you tried to build gcc 4.0.2 from the source on
> Windows XP Pro?
>
I recently built gcc-4.1 snapshot successfully on Windows XP. I will list down
the steps I followed, they should work with the 4.0.2 version also. Note that
gcc build
Dear Sirs,
Have you tried to build gcc 4.0.2 from the source on
Windows XP Pro?
Here is what I did.
1. Downloaded gcc-4.0.2.tar.gz.
2. Checked integrity of gcc-4.0.2.tar.gz using md5 and
jacksum.
3. Downloaded MinGW-4.1.0.exe.
4. Installed gcc version 3.4.2 (mingw-special).
5. Downloded and
specs.
Target: powerpc-apple-darwin7.9.0
Configured with: /users/william/dev/gcc/gcc-4.0.2/configure
--enable-languages=c,c++,ada,java,objc
--disable-nls
--enable-threads=posix
--disable-multilib
--enable-libada
--program-suffix=-4.0.2_590
--p
Dear sirs,
As per your request in gcc-4.0.2/INSTALL/finalinstall.html, I herewith send
you the following information on my build & installation of GCC:
- config.guess states "i686-pc-linux-gnu"
- gcc -v output:
Using built-in specs.
Target: i686-pc-linux-gnu
Configured wit
On its' way. Thanks!
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Botcazou
Sent: Tuesday, November 22, 2005 3:22 PM
To: [EMAIL PROTECTED]
Cc: gcc@gcc.gnu.org
Subject: Re: compiling gcc-4.0.2 on solaris 9
> It is 4325 lines, should I ju
> It is 4325 lines, should I just email it to you instead
> of the whole group?
Yes, compressed.
--
Eric Botcazou
gcc-4.0.2 on solaris 9
> Although I had #!/bin/sh at the beginning, it was taking my
> SHELL as tcsh. I have stuck in (via notes) SHELL=/bin/ksh;export SHELL
> and I am rebuilding it right now. Thanks!
Could you post the config.log file of the target libiberty?
--
Eric Botcazou
> Although I had #!/bin/sh at the beginning, it was taking my
> SHELL as tcsh. I have stuck in (via notes) SHELL=/bin/ksh;export SHELL
> and I am rebuilding it right now. Thanks!
Could you post the config.log file of the target libiberty?
--
Eric Botcazou
: compiling gcc-4.0.2 on solaris 9
configure shell: /bin/sh
gnu make: GNU Make 3.80
Although I had #!/bin/sh at the beginning, it was taking my
SHELL as tcsh. I have stuck in (via notes) SHELL=/bin/ksh;export SHELL
and I am rebuilding it right now. Thanks!
-Original Message-
From: [EMAIL
PROTECTED] On Behalf Of Eric Botcazou
Sent: Tuesday, November 22, 2005 1:25 PM
To: [EMAIL PROTECTED]
Cc: gcc@gcc.gnu.org
Subject: Re: compiling gcc-4.0.2 on solaris 9
> I put:
>
> printenv CC
> echo $CC
> which cc
>
> in the script and only got output for the which cmd as
> /opt
> I put:
>
> printenv CC
> echo $CC
> which cc
>
> in the script and only got output for the which cmd as
> /opt/SUNWspro/bin/cc. I even reran the script with CC not set, just to make
> sure. Thanks!
Hum... let's try the basic checks then:
- what is your configure shell?
- what is your version of
: Tuesday, November 22, 2005 12:42 PM
To: [EMAIL PROTECTED]
Cc: gcc@gcc.gnu.org
Subject: Re: compiling gcc-4.0.2 on solaris 9
> Ok, here is my script (note I am in a directory with only the
> script below when I execute the script below):
>
> CC=cc /export/home/src/net/gnu/gcc-4.0.2/confi
> Ok, here is my script (note I am in a directory with only the
> script below when I execute the script below):
>
> CC=cc /export/home/src/net/gnu/gcc-4.0.2/configure
> gmake bootstrap>make_err 2>&1
>
> I get the exact same errors (at least as far as I see).
The t
Ok, here is my script (note I am in a directory with only the
script below when I execute the script below):
CC=cc /export/home/src/net/gnu/gcc-4.0.2/configure
gmake bootstrap>make_err 2>&1
I get the exact same errors (at least as far as I see).
Also, I had actually looked at the
Hi!
I just did a bootstrap build of gcc 4.0.2 on an Intel P4 and here is
the feedback according to http://gcc.gnu.org/install/finalinstall.html :
compile/gcc-4.0.2> ./config.guess
i686-pc-linux-gnu
compile/gcc4> /opt/gcc4/bin/gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Conf
> CC to cc only. So, now the script is:
>
> CC=cc
> export CC
> ../gcc-4.0.2/configure
> gmake bootstrap
Do not export CC and do not use a relative path:
CC=cc $absolute_path/configure ...
> Also, the ask why I was using the flags I was. The only reference I found
> to
Thanks to everyone for the information below. I have change the
CC to cc only. So, now the script is:
CC=cc
export CC
../gcc-4.0.2/configure
gmake bootstrap
and I get the errors:
checking for sparc-sun-solaris2.9-gcc... no
checking for gcc... no
checking for sparc-sun-solaris2.9-cc... no
> Although the compiler's executable is composed of 32-bit code, it can
> generate 32 or 64 bit code, which is what I meant by "both compilers".
Ah! Indeed, but you're going to further confuse the readers. :-)
I think the best terminology is "32-bit multilib compiler" for
sparc-sun-solaris and
On Fri, Nov 18, 2005 at 09:35:28PM +0100, Eric Botcazou wrote:
> > Also, sparc-sun-solaris2.9 doesn't mean "32-bit compiler", it means
> > "build both compilers, defaulting to 32 bits".
>
> No, the compiler is purely 32-bit, only the libraries are of both flavors.
We are using the term in a diffe
> Also, sparc-sun-solaris2.9 doesn't mean "32-bit compiler", it means
> "build both compilers, defaulting to 32 bits".
No, the compiler is purely 32-bit, only the libraries are of both flavors.
--
Eric Botcazou
On Fri, Nov 18, 2005 at 09:17:11PM +0100, Eric Botcazou wrote:
> > > mkdir objectdir;cd objectdir
> > > CC="cc -xildoff -xarch=v9"
> > > export CC
> >
> > Why are you choosing those flags?
>
> Probably because they are advertised on:
> http://gcc.gnu.org/install/specific.html#sparc64-x-solaris2
>
> > mkdir objectdir;cd objectdir
> > CC="cc -xildoff -xarch=v9"
> > export CC
>
> Why are you choosing those flags?
Probably because they are advertised on:
http://gcc.gnu.org/install/specific.html#sparc64-x-solaris2
> Just do CC=cc, you will get both a 32-bit and a 64-bit compiler. What
> seems
xarch=v9"
> export CC
Why are you choosing those flags?
> ../gcc-4.0.2/configure
> gmake bootstrap
>
> I get the following errors:
>
> stage1/xgcc -Bstage1/ -B/usr/local/sparc-sun-solaris2.9/bin/ -g -O2
> -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototyp
GCC 4.0.2 has been successfully built on Fedora Core 3
config.guess returned:
> i686-pc-linux-gnu
gcc -v returned:
> Using built-in specs.
> Target: i686-pc-linux-gnu
> Configured with: /home/devel/gcc/gcc- 4.0.2/configure --program-suffix=-4.0.2
> Thread model: posix
> gcc ve
Generic_118558-14 sun4u sparc SUNW,Sun-Blade-1500.
I try to do a bootstrap with the following using gnu make 3.80:
mkdir objectdir;cd objectdir
CC="cc -xildoff -xarch=v9"
export CC
../gcc-4.0.2/configure
gmake bootstrap
I get the following errors:
stage1/xgcc -Bstage1/ -B/usr/local
specs.
Target: powerpc-apple-darwin7.9.0
Configured with: ../gcc-4.0.2/configure
--prefix=/users/William/develop/gcc/install
--enable-languages=c,ada
--disable-nls
--enable-threads=posix
--disable-multilib
Thread model: posix
gcc version 4.0.2
GNAT
Successful "make bootstrap" of native gcc-4.0.2 on PowerPC 405.
Output of config.guess:
powerpc-unknown-linux-gnu
Output of gcc -v:
Using built-in specs.
Target: powerpc-unknown-linux-gnu
Configured with: ../gcc-4.0.2/configure --prefix=/usr --with-cpu=405
--without-fp --enable-lan
to x86_64 builds in full.
Regards
Mark Fortescue.
-Original Message-
From: Nathanael Nerode [mailto:[EMAIL PROTECTED]
Sent: 02 November 2005 00:29
To: [EMAIL PROTECTED]
Cc: gcc@gcc.gnu.org; [EMAIL PROTECTED]
Subject: Re: GCC 4.0.2 Canadian Cross Compile
Mark Fortesque wrote:
&g
Mark Fortesque wrote:
>I did not specify all the commandline arguments used in my email. I am
>using --build= in the GCC builds (as required). The build arguments
>in use when things go pair shaped are:
>'/L64/src/gcc-4.0.0/gcc-4.0.2-p01/configure --build=i686-pc-linux-gnu
>
Jim Wilson <[EMAIL PROTECTED]> writes:
> Rainer Emrich wrote:
>> rm -f /appl/shared/gcc/Linux/i686-pc-linux-gnu/gcc-4.0.2/bin/; \
>> ln /appl/shared/gcc/Linux/i686-pc-linux-gnu/gcc-4.0.2/bin/gfortran
>> /appl/shared/gcc/Linux/i686-pc-linux-gnu/gcc-4.0.2/bin/; \
On Tue, 2005-11-01 at 11:39, Steven Bosscher wrote:
> Wasn't this whole issue fixed by this patch:
> http://gcc.gnu.org/ml/gcc-patches/2005-10/msg01785.html
Yes. Andreas Schwab's patch appears to fix this correctly.
--
Jim Wilson, GNU Tools Support, http://www.specifix.com
On Tuesday 01 November 2005 19:59, Jim Wilson wrote:
> Rainer Emrich wrote:
> > rm -f /appl/shared/gcc/Linux/i686-pc-linux-gnu/gcc-4.0.2/bin/; \
> > ln /appl/shared/gcc/Linux/i686-pc-linux-gnu/gcc-4.0.2/bin/gfortran
> > /appl/shared/gcc/Linux/i686-pc-linux-gnu/gcc-4.0.
Rainer Emrich wrote:
rm -f /appl/shared/gcc/Linux/i686-pc-linux-gnu/gcc-4.0.2/bin/; \
ln /appl/shared/gcc/Linux/i686-pc-linux-gnu/gcc-4.0.2/bin/gfortran
/appl/shared/gcc/Linux/i686-pc-linux-gnu/gcc-4.0.2/bin/; \
Looking at gcc/fortran/Make-lang.in we see that the command here is
rm
Hi DJ Delorie,
I did not specify all the commandline arguments used in my email. I am
using --build= in the GCC builds (as required). The build arguments
in use when things go pair shaped are:
'/L64/src/gcc-4.0.0/gcc-4.0.2-p01/configure --build=i686-pc-linux-gnu
--target=sparc-linux --host=
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
if [ -f f951 ] ; then \
if [ -f gfortran-cross ] ; then \
rm -f /appl/shared/gcc/Linux/i686-pc-linux-gnu/gcc-4.0.2/bin/gfortran; \
/usr/bin/install -c gfortran-cross
/appl/shared/gcc/Linux/i686-pc-linux-gnu/gcc-4.0.2/bin/gfortran
> In a Canadian Cross Compile, 'target' == 'host' != 'build' and the
> compiler that is created may not run on the computer building the
> compiler.
You're describing a cross-built native, not a canadian.
http://gcc.gnu.org/onlinedocs/gccint/Configure-Terms.html
Whenever --target=foo and build!=
Hi,
I have been having problems building GCC 4.0.2 using a GCC 4.0.2 cross
compiler.
The issue appears to be that the 'is_cross_compiler' macro in the
configure scripts does not check to see if 'build' = 'host'. It only
check to see if 'target' = '
I managed to build gcc-4.0.2 using MinGW 5.0.0 candidate gcc 3.4.4 with command
`make bootstrap' and configured with flag --enable-languages=c,c++ in MSys
together with msysDTK 1.0.1 and upgraded autoconf(2.59), automake(1.82) and
libtool(1.5) on a WinXP system. Since lack of test
Successfully built and installed GCC 4.0.2 on i686-pc-linux-gnu Debian
Testing/Unstable
# config.guess
i686-pc-linux-gnu
# gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc/configure --enable-threads --with-cpu=i686
Thread model: posix
gcc
I managed to build gcc-4.0.2 using MinGW 5.0.0 candidate gcc 3.4.4 with flag
--enable-languages=c,c++ in MSys together with msysDTK 1.0.1 and upgraded
autoconf(2.59), automake(1.82) and libtool(1.5) on a WinXP system. Since lack
of test tools, testing is skipped, while the compilers work indeed
config.guess => i686-pc-cygwin
$ gcc -v
Using built-in specs.
Target: i686-pc-cygwin
Configured with: /cygdrive/e/gcc-4.0.2/configure
Thread model: single
gcc version 4.0.2
I didn't take any special action regarding "Whether you enabled all
languages or a subset of them."
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Albert Chin schrieb:
> On Wed, Oct 12, 2005 at 02:29:56PM +0200, Rainer Emrich wrote:
>
>>Compiler version: 4.0.2
>>Platform: mips-sgi-irix6.5
>>configure flags:
>>- - --prefix=/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/install
>>- - --with-gnu-as
>>-
On Wed, Oct 12, 2005 at 02:29:56PM +0200, Rainer Emrich wrote:
> Compiler version: 4.0.2
> Platform: mips-sgi-irix6.5
> configure flags:
> - - --prefix=/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/install
> - - --with-gnu-as
> - - --with-as=/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/install/bin/as
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Compiler version: 4.0.2
Platform: ia64-unknown-linux-gnu
configure flags:
- --prefix=/SCRATCH/gcc-build/Linux/ia64-unknown-linux-gnu/install
- --with-gnu-as
- --with-as=/SCRATCH/gcc-build/Linux/ia64-unknown-linux-gnu/install/bin/as
- --with-gnu-ld
- --
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Compiler version: 4.0.2
Platform: x86_64-unknown-linux-gnu
configure flags:
- --prefix=/SCRATCH/gcc-build/Linux/x86_64-unknown-linux-gnu/install
- --with-gnu-as
- --with-as=/SCRATCH/gcc-build/Linux/x86_64-unknown-linux-gnu/install/bin/as
- --with-gnu-l
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Compiler version: 4.0.2
Platform: mips-sgi-irix6.5
configure flags:
- - --prefix=/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/install
- - --with-gnu-as
- - --with-as=/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/install/bin/as
- - --with-gnu-ld
- - --with-l
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Compiler version: 4.0.2
Platform: i686-pc-linux-gnu
configure flags:
- --prefix=/SCRATCH/gcc-build/Linux/i686-pc-linux-gnu/install
- --with-gnu-as
- --with-as=/SCRATCH/gcc-build/Linux/i686-pc-linux-gnu/install/bin/as
- --with-gnu-ld
- --with-ld=/SCRAT
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Compiler version: 4.0.2
Platform: mips-sgi-irix6.5
configure flags:
- --prefix=/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/install
- --with-gnu-as
- --with-as=/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/install/bin/as
- --with-gnu-ld
- --with-ld=/SCRATCH
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Compiler version: 4.0.2
Platform: hppa2.0w-hp-hpux11.00
configure flags:
- --prefix=/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/install
- --with-gnu-as
- --with-as=/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/install/bin/as
- --with-ld=/usr/ccs/bi
Dear list,
[EMAIL PROTECTED]:~/GNU/gcc-4.0.2/SRC#gcc -v
Using built-in specs.
Target: alphaev68-dec-osf5.1b
Configured with:
../configure
--host=alphaev68-dec-osf5.1b
--enable-threads=posix
--enable-languages=c,c++,f95,objc,java,treelang
--prefix=/usr/local
--enable-version-specific-runtime
Dear list,
# gcc -v
Using built-in specs.
Target: alphaev56-dec-osf5.1b
Configured with:
../configure
--enable-threads=posix
--enable-languages=c,c++,treelang
--prefix=/usr/local
--enable-version-specific-runtime-libs
--enable-shared
--enable-nls
--enable-interpreter
Thread model: posix
g
> Done.
Thank you very much.
--
Eric Botcazou
Eric Botcazou wrote:
> Agreed. But I'm requesting a "caveat" note about the Solaris regression here:
> http://gcc.gnu.org/gcc-4.0/changes.html#4.0.2
> mentioning the workaround (g++ -pthreads) and the link:
> http://gcc.gnu.org/ml/gcc-cvs/2005-09/msg00984.html
Done.
Thanks,
--
Mark Mitche
Mark Mitchell wrote:
> 1. Move the ChangeLog entries on the 4.0 branch to accurately reflect
> the released bits.
>
> 2. Modify Bugzilla to reset the target milestone for the three PRs in
> question.
>
> 3. Modify gcc_release to prevent this situation in future.
These steps have now been taken.
Eric Botcazou wrote:
>>I've decided not to do another release. I think it's too much effort
>>for too little gain. The C++ and m68k patches are things that might
>>just as easily not have been applied in the first place; we certainly
>>wouldn't have considered either PR a showstopper. The Solari
> I've decided not to do another release. I think it's too much effort
> for too little gain. The C++ and m68k patches are things that might
> just as easily not have been applied in the first place; we certainly
> wouldn't have considered either PR a showstopper. The Solaris problem
> is unfort
Kean Johnston wrote:
>> I'd appreciate feedback. (I don't promise to be bound by the majority
>> view, though.)
>
> I seem to recall in the past that they did patch releases.
> From both a tagging purity point of view and reproducability
> point ov view, why not create a branch off 4.0.2, apply t
I'd appreciate feedback. (I don't promise to be bound by the majority
view, though.)
I seem to recall in the past that they did patch releases.
From both a tagging purity point of view and reproducability
point ov view, why not create a branch off 4.0.2, apply the
fixes that were missed, tag it
Matthias Klose wrote:
Mark Mitchell writes:
Daniel Jacobowitz wrote:
My inclination is to do nothing (other than correct the target
milestones on these bugs in bugzilla) and move on. The Solaris problem
is bad, and I beat up on Benjamin to get it fixed, but I'm not sure it's
a crisis meriti
Mark Mitchell writes:
> Daniel Jacobowitz wrote:
>
> >>My inclination is to do nothing (other than correct the target
> >>milestones on these bugs in bugzilla) and move on. The Solaris problem
> >>is bad, and I beat up on Benjamin to get it fixed, but I'm not sure it's
> >>a crisis meriting anoth
On Fri, Sep 30, 2005 at 10:59:45AM -0700, H. J. Lu wrote:
> It doesn't have to a formal release. I would just make a snapshot from
> the 4.0 branch and point the affected people to it. If there isn't
> enough, you can always make another snapshot. You can update 4.0.2
> release web page and mention
release according to the current ChangeLog, but
> > > in fact it wasn't:
> >
> > Indeed, cvs log confirms that the revision was made to cp/init.c on
> > September 22.
> >
> > It appears that the release automation failed, and that, in fact, the
> > a
On Fri, Sep 30, 2005 at 10:54:22AM -0700, Mark Mitchell wrote:
> Was this a regression from 4.0.0 or 4.0.1?
I doubt it.
> > Personally, I'd do a 4.0.3 based on current bits.
>
> The problem is that it's not just me banging on the release button
> (which does itself take quite a lot of time, sinc
>
> Indeed, cvs log confirms that the revision was made to cp/init.c on
> September 22.
>
> It appears that the release automation failed, and that, in fact, the
> allegedly final GCC 4.0.2 bits are in fact the early version of GCC
> 4.0.2 that I never uploaded because of the la
On Fri, Sep 30, 2005 at 10:54:22AM -0700, Mark Mitchell wrote:
> Daniel Jacobowitz wrote:
>
> >>My inclination is to do nothing (other than correct the target
> >>milestones on these bugs in bugzilla) and move on. The Solaris problem
> >>is bad, and I beat up on Benjamin to get it fixed, but I'm
Mark Mitchell <[EMAIL PROTECTED]> writes:
> The key question is whether to do an immediate 4.0.3 to catch up to what
> we intended. (That's not entirely trivial, in that things have now been
> checked in on the 4.0 branch, so we would have to temporarily back out
> some patches, or apply tags ver
Daniel Jacobowitz wrote:
>>My inclination is to do nothing (other than correct the target
>>milestones on these bugs in bugzilla) and move on. The Solaris problem
>>is bad, and I beat up on Benjamin to get it fixed, but I'm not sure it's
>>a crisis meriting another release cycle. The C++ change
On Fri, Sep 30, 2005 at 10:06:07AM -0700, Mark Mitchell wrote:
> The key question is whether to do an immediate 4.0.3 to catch up to what
> we intended. (That's not entirely trivial, in that things have now been
> checked in on the 4.0 branch, so we would have to temporarily back out
> some patche
pears that the release automation failed, and that, in fact, the
allegedly final GCC 4.0.2 bits are in fact the early version of GCC
4.0.2 that I never uploaded because of the last-minute changes for
Solaris and such.
I'm incredibly depressed.
I suspect that the reason for this is th
--- Ulrich Weigand wrote:
> Comparing the cp/ChangeLog files from 4.0.2 and the
> 4_0 branch, it looks
> like the fix is in the release according to the
> current ChangeLog, but
> in fact it wasn't:
Indeed,
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/init.c.diff?cvsroot=gcc&only_with_tag=gc
ix is in the release according to the current ChangeLog, but
in fact it wasn't:
[EMAIL PROTECTED] fsf]$ diff -u gcc-4.0.2/gcc/cp/ChangeLog
gcc-4_0/gcc/cp/ChangeLog
--- gcc-4.0.2/gcc/cp/ChangeLog 2005-09-21 05:56:51.0 +0200
+++ gcc-4_0/gcc/cp/ChangeLog2005-09-30 12:40:52.0 +
Ulrich Weigand wrote:
> Mark Mitchell wrote:
>
>
>>GCC 4.0.2 has been released.
>
>
> Results on s390(x)-ibm-linux are here:
> http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg01323.html
> http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg01324.html
>
> Unfo
On 9/29/05, Ulrich Weigand <[EMAIL PROTECTED]> wrote:
> Mark Mitchell wrote:
>
> > GCC 4.0.2 has been released.
>
> Results on s390(x)-ibm-linux are here:
> http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg01323.html
> http://gcc.gnu.org/ml/gcc-testresults/2005-09/m
> Indeed this is clearly correct. And one does wonder how this
> missing line has managed to not cause problems elsewhere...
I've installed the patch on the mainline, after bootstrapping/regtesting it on
x86_64-suse-linux. Do you want me to put it on the 4.0 branch too?
--
Eric Botcazou
BTW, did you get a chance to look into:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24003
I haven't yet, but I normally use x86_64, so I'm not running into it.
And I'm also confused about the EH_REGION stuff.
This restores bootstrap on x86 and x86_64-linux, thanks
for looking into this.
http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg01332.html
http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg01333.html
BTW, did you get a chance to look into:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24003
which i
On 9/29/05, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> > sparc64-linux
> > http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg01019.html
>
> Just to make it clear: that's not a SPARC 64-bit Ada compiler, only a 32-bit
> Ada compiler with a questionable name.
Right!
--
Cheers,
/ChJ
> Other platforms with one or few ACATS failures:
[...]
> sparc-solaris2.8
> http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg01077.html
The problem is generic (PR ada/20753), although it only shows up in the ACATS
testsuite at -O2 on SPARC and PA for some reasons.
> sparc64-linux
> http://g
On Thu, Sep 29, 2005 at 07:32:46AM -0400, Richard Kenner wrote:
> The real fix is below, though I haven't run it throuh a testing cycle yet.
> I was wondering how this ever worked:
Indeed this is clearly correct. And one does wonder how this
missing line has managed to not cause problems elsewher
Mark Mitchell wrote:
> GCC 4.0.2 has been released.
Results on s390(x)-ibm-linux are here:
http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg01323.html
http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg01324.html
Unfortunately, it is not zero-FAIL after all; at the last
minute this one appears
Laurent GUERBY wrote:
> The patch to restore Ada bootstrap is a one liner: just revert
> the gimplify.c part of 2005-09-24 Richard Henderson's change
> in your tree (see below).
>
> I don't know what is the policy on patches that break Ada on x86-linux
> (here by revealing a latent middle-end bug
Hello again!
Okay, gcc-4.0.2 built just fine on an embedded mpc8540 (ppc, e500, SPE
extension):
$ ./gcc -v
Using built-in specs.
Target: powerpc-unknown-linux-gnu
Configured with: ../gcc-4.0.2/configure --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-languages=c,c++,objc
The patch to restore Ada bootstrap is a one liner: just revert
the gimplify.c part of 2005-09-24 Richard Henderson's change
in your tree (see below).
The real fix is below, though I haven't run it throuh a testing cycle yet.
I was wondering how this ever worked:
*** stor-layout.c
The patch to restore Ada bootstrap is a one liner: just revert
the gimplify.c part of 2005-09-24 Richard Henderson's change
in your tree (see below).
I don't know what is the policy on patches that break Ada on x86-linux
(here by revealing a latent middle-end bug - but I think latent or not
policy
Hello!
GCC 4.0.2 has been released.
Great! Thank you all! :-))
Well, I am using an embedded mpc8540 (ppc, e500, SPE extension) system
and can work like on a native system. Currently, the system is not very
busy, so I can run some tests if it's useful for you...
Can you tell me (point to
Laurent GUERBY <[EMAIL PROTECTED]> writes:
> Many thanks to people enabling Ada in their builds!
I'd like to enable it for 4.1 CVS but that one is failing since last
week as reported in bugzilla :-(
Andreas
--
Andreas Jaeger, [EMAIL PROTECTED], http://www.suse.de/~aj
SUSE LINUX Products GmbH
> Many thanks to people enabling Ada in their builds!
Indeed, thanks to you, and thanks to Laurent for collecting these
results, and also filing bugzilla PRs when regressions are detected.
Arno
GCC 4.0.2 has been released.
This release is a minor release, containing primarily fixes for
regressions in GCC 4.0.1 releative to previous releases.
http://gcc.gnu.org/gcc-4.0/changes.html#4.0.2
This release is available from the FTP servers listed here:
http://www.gnu.org/order/ftp.html
The
Zero ACATS fail on three platforms:
x86-linux
http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg01292.html
x86_64-linux
http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg01293.html
s390-linux
http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg01257.html
Other platforms with one or few ACATS failur
On 9/28/05, Christian Joensson <[EMAIL PROTECTED]> wrote:
> On 9/27/05, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> > Now that Benjamin and Eric have fixed the Solaris issues in libstdc++
> > (yay!), I know of no reason not to spin a release. I'm going to take a
> > final pass through the open PRs
On 9/27/05, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Now that Benjamin and Eric have fixed the Solaris issues in libstdc++
> (yay!), I know of no reason not to spin a release. I'm going to take a
> final pass through the open PRs and look for show-stoppers. Is anyone
> aware of regressions from
njamin Kosnik <[EMAIL PROTECTED]>
> Eric Botcazou <[EMAIL PROTECTED]>
>
> * include/ext/mt_allocator.h
> (__per_type_pool<...true>::_S_initialize_once): Always call
> _M_initialize_once.
> (__common_pool<..
c Botcazou <[EMAIL PROTECTED]>
* include/ext/mt_allocator.h
(__per_type_pool<...true>::_S_initialize_once): Always call
_M_initialize_once.
(__common_pool<...true>::_S_initialize_once): Same.
2005-09-20 Release Manager
* GCC 4.0.2 released.
Will it be updated before 4.0.2 is released?
H.J.
Now that Benjamin and Eric have fixed the Solaris issues in libstdc++
(yay!), I know of no reason not to spin a release. I'm going to take a
final pass through the open PRs and look for show-stoppers. Is anyone
aware of regressions from previous 4.0.x releases that are wrong-code,
ice-on-valid, o
On 9/23/05, Christian Joensson <[EMAIL PROTECTED]> wrote:
> On 9/23/05, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> > Christian Joensson wrote:
> >
> > > FAIL: g++.dg/other/profile1.C (test for excess errors)
> > > FAIL: g++.old-deja/g++.law/profile1.C (test for excess errors)
> > > XPASS: g++.old-d
On Friday, September 23, 2005, at 08:31 AM, Andrew Morrow wrote:
If I look at the assembly listings in thunk32.s and visibility32.s I
see the same listing that defines __i686.get_pc_thunk.bx in both
files:
.section
.gnu.linkonce.t.__i686.get_pc_thunk.bx,"ax",@progbits
.globl __
1 - 100 of 179 matches
Mail list logo
