your error is because gcc needs in the directory where you compile the header
files so first extract your w32api and runtime in that directory (step 05)
OK I got a lot of problems compile gcc 4.1.0 with mingw/msys
Finally its done
Because it took me a lot of time here the solution
http://prdownlo
On 2/23/06, Jens-Olaf Beismann <[EMAIL PROTECTED]> wrote:
> 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 Suse1
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 instructions discoura
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
>--target=sparc-linux --h
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=sparc-l
> 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!=
> 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
On Fri, Sep 30, 2005 at 11:03:31AM -0700, Joe Buck wrote:
> On Fri, Sep 30, 2005 at 10:06:07AM -0700, Mark Mitchell wrote:
> > 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 Chan
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
On Fri, Sep 30, 2005 at 10:06:07AM -0700, Mark Mitchell wrote:
> 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, cvs log confirms that
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
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, cvs log confirms that the revision was made to cp/init.c on
September 22.
It appears that the rel
--- 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
Mark Mitchell wrote:
> No, that's very weird; that was PR 23993, which I fixed. Or, thought I
> did. It's definitely fixed for me on x86_64-unknown-linux-gnu. But,
> the nature of the bug didn't seem at all system-dependent. I've checked
> that I have no local patches in my GCC 4.0.x tree. So
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
>
> Unfortunately, it is not zero-FAIL after
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/msg01324.html
>
> Unfortunately, i
> 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 to
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 some d
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
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
H. J. Lu wrote:
> On Tue, Sep 27, 2005 at 07:58:46AM -0700, Mark Mitchell 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 any
On Tue, Sep 27, 2005 at 07:58:46AM -0700, Mark Mitchell 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 regres
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 __
Benjamin Kosnik wrote:
>>to libstdc++ is the only obvious culprit. Benjamin, Jakub, are you
>>investigating these failures? We need to get this resolved ASAP.
>
>
> I'm on it.
Thanks!
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
> to libstdc++ is the only obvious culprit. Benjamin, Jakub, are you
> investigating these failures? We need to get this resolved ASAP.
I'm on it.
-benjamin
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-deja/g++.other/init5.C execution test
> > FAIL: g++.old-deja/g++.robert
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-deja/g++.other/init5.C execution test
> FAIL: g++.old-deja/g++.robertl/eb83.C (test for excess errors)
Do you have g++.log output fo
Eric Botcazou wrote:
> > The GCC 4.0.2 RC3 prerelease is spinning now.
>
> Regressions on Solaris 2.6, 7, 8 and 9:
> FAIL: ext/mt_allocator/check_allocate_big_per_type.cc execution test
> FAIL: ext/mt_allocator/check_delete.cc execution test
> FAIL: ext/mt_allocator/check_new.cc execution test
>
On 9/22/05, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> The GCC 4.0.2 RC3 prerelease is spinning now.
>
> If all goes well, it will be available later today.
whoa, I get a few regressions here, compare this with
http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg01019.html ...
LAST_UPDATED: Thu Sep
> > I have. I am awaiting solaris test details.
>
> Not very good: regressions on Solaris 2.6, 7, 8 and 9.
>
> FAIL: ext/mt_allocator/check_allocate_big_per_type.cc execution test
> FAIL: ext/mt_allocator/check_delete.cc execution test
> FAIL: ext/mt_allocator/check_new.cc execution test
> FAIL:
> The GCC 4.0.2 RC3 prerelease is spinning now.
Regressions on Solaris 2.6, 7, 8 and 9:
FAIL: ext/mt_allocator/check_allocate_big_per_type.cc execution test
FAIL: ext/mt_allocator/check_delete.cc execution test
FAIL: ext/mt_allocator/check_new.cc execution test
FAIL: ext/mt_allocator/deallocate_g
> I have. I am awaiting solaris test details.
Not very good: regressions on Solaris 2.6, 7, 8 and 9.
FAIL: ext/mt_allocator/check_allocate_big_per_type.cc execution test
FAIL: ext/mt_allocator/check_delete.cc execution test
FAIL: ext/mt_allocator/check_new.cc execution test
FAIL: ext/mt_allocator
Giovanni Bajo wrote:
> Mark Mitchell <[EMAIL PROTECTED]> wrote:
>
>
>>1. Release 4.0.2 without fixing this PR. (The bits are ready, sitting
>> on my disk.)
>>
>>2. Apply the patch, respin the release, and release it.
>>
>>3. Apply the patch, spin RC3, and go through another testing cycle.
>
>
Mark Mitchell <[EMAIL PROTECTED]> wrote:
> 1. Release 4.0.2 without fixing this PR. (The bits are ready, sitting
>on my disk.)
>
> 2. Apply the patch, respin the release, and release it.
>
> 3. Apply the patch, spin RC3, and go through another testing cycle.
My feeling is that these 4.0 rele
Mark Mitchell wrote:
1. Release 4.0.2 without fixing this PR. (The bits are ready, sitting
on my disk.)
2. Apply the patch, respin the release, and release it.
3. Apply the patch, spin RC3, and go through another testing cycle.
I vote for option 3., not 1. and also not 2. (sorry ;)
Pao
> 1. Release 4.0.2 without fixing this PR. (The bits are ready, sitting
>on my disk.)
Let's drop-kick this sucker to the ftp server already.
>Has Benjamin applied his patch on the 4.0 branch?
I have. I am awaiting solaris test details.
-benjamin
> So, my options are:
>
> 1. Release 4.0.2 without fixing this PR. (The bits are ready, sitting
>on my disk.)
>
> 2. Apply the patch, respin the release, and release it.
>
> 3. Apply the patch, spin RC3, and go through another testing cycle.
>
> My current plan is (2) because I think that this
Etienne Lorrain wrote:
> Hello,
>
> You really do not want to get a correction for:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23631
> before release?
I'd love to get a patch for this problem. -- but there's no readily
available prospect, and this is not a regression from 4.0.x. The
pri
On Sun, Sep 18, 2005 at 09:41:54AM -0700, Mark Mitchell wrote:
> Please test, post test results to gcc-testresults, and send me an email
> pointing at the results.
OK for powerpc64-unknown-linux-gnu:
http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00942.html
Janis
> Please test, post test results to gcc-testresults, and send me an email
> pointing at the results.
OK for sh4-unknown-linux-gnu:
http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00902.html
Regards,
kaz
> I filed them as bugs, not fixed them.
OK, thanks for confirming.
--
Eric Botcazou
On Sep 19, 2005, at 4:21 PM, Eric Botcazou wrote:
Anyways, all of the known failures with the obj-c++ with the GNU
runtime have been filed and someone needs to look into them.
Are you talking about these?
I filed them as bugs, not fixed them.
Thanks,
Andrew Pinski
> Anyways, all of the known failures with the obj-c++ with the GNU
> runtime have been filed and someone needs to look into them.
Are you talking about these?
=== obj-c++ tests ===
Running target unix
FAIL: obj-c++.dg/bitfield-1.mm (test for excess errors)
FAIL: obj-c++.dg/bitfi
On Sep 19, 2005, at 3:21 PM, Mike Stump wrote:
On Sep 18, 2005, at 2:43 PM, Ulrich Weigand wrote:
In fact, as far as I can recall, 4.0.2 will be the first
ever GCC release with zero testsuite FAILs across all
languages on s390-ibm-linux ...
[ rub eyes ]
[ head explodes ]
[ desperately tryi
> You didn't test --enable-languages=obj-c++
Yeah, it's a plot, we positively refuse to test everything Apple has *not*
contributed. ;-)
--
Eric Botcazou
> GCC 4.0.2 RC2 is now available here
Sill ok on arm-none-elf:
http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00938.html
Paul
On Sep 18, 2005, at 2:43 PM, Ulrich Weigand wrote:
In fact, as far as I can recall, 4.0.2 will be the first
ever GCC release with zero testsuite FAILs across all
languages on s390-ibm-linux ...
[ rub eyes ]
[ head explodes ]
[ desperately trying to make sense of the world ]
You didn't test -
> Please test, post test results to gcc-testresults, and send me an email
> pointing at the results.
Still OK for SPARC/Solaris:
http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00929.html
http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00930.html
http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg
On 9/19/05, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
>
> > I applied the patch by hand (not working with CVS) and it
> > does _not_ solve the problem.
> >
> In this case, I am sorry but the probability of a fix before the release
> is close to zero.
The problem with 4.0 is that it behaves comple
I applied the patch by hand (not working with CVS) and it
does _not_ solve the problem.
In this case, I am sorry but the probability of a fix before the release
is close to zero.
Paolo
--- Paolo Bonzini <[EMAIL PROTECTED]> wrote:
> Etienne Lorrain wrote:
> > Hello,
> >
> > You really do not want to get a correction for:
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23631
> > before release?
> >
> > I checked again with 4.0.2 20050917, and nothing
> > has changed sinc
Etienne Lorrain wrote:
Hello,
You really do not want to get a correction for:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23631
before release?
I checked again with 4.0.2 20050917, and nothing
has changed since:
http://gcc.gnu.org/ml/gcc/2005-09/msg00251.html
Etienne, does the patch
Hello,
You really do not want to get a correction for:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23631
before release?
I checked again with 4.0.2 20050917, and nothing
has changed since:
http://gcc.gnu.org/ml/gcc/2005-09/msg00251.html
Etienne.
_
Mark Mitchell wrote:
Please test, post test results to gcc-testresults, and send me an email
pointing at the results.
darwin ppc should be ok.
http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00898.html
Andreas
Mark Mitchell wrote:
> Please test, post test results to gcc-testresults, and send me an email
> pointing at the results.
s390(x)-ibm-linux is still fine:
http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00883.html
http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00884.html
In fact, as far as I
On Sun, 2005-09-18 at 09:41 -0700, Mark Mitchell wrote:
> Thanks to all who tested GCC 4.0.2 RC1.
>
> GCC 4.0.2 RC2 is now available here:
> [...]
> Please test, post test results to gcc-testresults, and send me an email
> pointing at the results.
Still ok for c,ada on x86 and x86_64-linux:
http
Eric Botcazou wrote:
>>GCC 4.0.2 RC1 is now available from FTP mirrors of gcc.gnu.org, in the:
>
>
> OK on SPARC/Solaris:
Thanks.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Looks good on powerp-ibm-aix5.2.0.0. All expected failures.
http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00806.html
David
Mark Mitchell <[EMAIL PROTECTED]> writes:
> GCC 4.0.2 RC1 is now available from FTP mirrors of gcc.gnu.org, in the:
>
> pub/gcc/prerelease-4.0.2-20050913/
>
> subdirectory.
>
> It's important to test the actual tarballs, rather than CVS, to check
> for any packaging issues. If you can, download a
> GCC 4.0.2 RC1 is now available from FTP mirrors of gcc.gnu.org, in the:
OK on SPARC/Solaris:
http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00788.html
http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00789.html
http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00790.html
http://gcc.gnu.org/ml/g
Paul Brook wrote:
> On Wednesday 14 September 2005 16:13, Mark Mitchell wrote:
>
>>GCC 4.0.2 RC1 is now available from FTP mirrors of gcc.gnu.org
>
>
> arm-none-elf results look good:
> http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00780.html
Thanks.
--
Mark Mitchell
CodeSourcery, LLC
[EMA
On Wednesday 14 September 2005 16:13, Mark Mitchell wrote:
> GCC 4.0.2 RC1 is now available from FTP mirrors of gcc.gnu.org
arm-none-elf results look good:
http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00780.html
Paul
On 9/14/05, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> GCC 4.0.2 RC1 is now available from FTP mirrors of gcc.gnu.org, in the:
looks pretty ok on sparc/sparc64 linux, see
http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00751.html my only
concern is the issues with treelang, see, e.g.,
http://gcc.
> It's important to test the actual tarballs, rather than CVS, to check
> for any packaging issues. If you can, download and build the tarballs,
> post test results to the gcc-testresults mailing list with and
> contrib/test_summary.
sh4-unknown-linux-gnu is ok:
http://gcc.gnu.org/ml/gcc-testres
Andreas Tobler wrote:
On Wed, 2005-09-14 at 08:13 -0700, Mark Mitchell wrote:
Assuming that no critical problems emerge, I'll do the final release
within the next week.
Libgcj seems broken with --enable-java-awt=gtk,xlib --enable-gtk-cairo.
(on darwin ppc and linux ppc at least, but I guess
Mark Mitchell wrote:
It's important to test the actual tarballs, rather than CVS, to check
for any packaging issues. If you can, download and build the tarballs,
post test results to the gcc-testresults mailing list with and
contrib/test_summary. If you encounter problems, please file them i
Laurent GUERBY wrote:
> On Wed, 2005-09-14 at 08:13 -0700, Mark Mitchell wrote:
>
>>Assuming that no critical problems emerge, I'll do the final release
>>within the next week.
>
>
> Looks good on x86-linux and x86_64-linux for Ada:
Thanks.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
Ulrich Weigand wrote:
> Mark Mitchell wrote:
>
>
>>It's important to test the actual tarballs, rather than CVS, to check
>>for any packaging issues. If you can, download and build the tarballs,
>>post test results to the gcc-testresults mailing list with and
>>contrib/test_summary. If you encou
Laurent GUERBY wrote:
On Wed, 2005-09-14 at 08:13 -0700, Mark Mitchell wrote:
Assuming that no critical problems emerge, I'll do the final release
within the next week.
Libgcj seems broken with --enable-java-awt=gtk,xlib --enable-gtk-cairo.
(on darwin ppc and linux ppc at least, but I guess o
On Wed, 2005-09-14 at 08:13 -0700, Mark Mitchell wrote:
> Assuming that no critical problems emerge, I'll do the final release
> within the next week.
Looks good on x86-linux and x86_64-linux for Ada:
http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00691.html
http://gcc.gnu.org/ml/gcc-testresult
Mark Mitchell wrote:
> It's important to test the actual tarballs, rather than CVS, to check
> for any packaging issues. If you can, download and build the tarballs,
> post test results to the gcc-testresults mailing list with and
> contrib/test_summary. If you encounter problems, please file th
On Wed, 14 Sep 2005, Dave Korn wrote:
> Original Message
> >From: Gcc K6 testing account
> >Sent: 14 September 2005 19:43
>
> > Ave gcc people
>
> ¡Hola!
>
> > Is "-DENABLE_CHECKING" supposed to happen in a RC/release?
> > Or has -DENABLE_CHECKING nothing to do with the configure
> >
Original Message
>From: Andrew Pinski
>Sent: 14 September 2005 19:56
>> Original Message
>>> From: Gcc K6 testing account
>>> Sent: 14 September 2005 19:43
>>
>>> Ave gcc people
>>
>> !Hola!
>>
>>> Is "-DENABLE_CHECKING" supposed to happen in a RC/release?
>>> Or has -DENABLE_
1 - 100 of 111 matches
Mail list logo
