On Apr 30, 2005, at 5:28 AM, Bill Northcott wrote:
There are a number of problems:
1. Since I am using a PPC7455 based computer 64bit executables
won't run and the 64 bit libraries are effectively cross
compilations. So the configure scripts need the same APPLE LOCAL
mods used in libstdc++
On Apr 30, 2005, at 7:51 PM, Bill Northcott wrote:
However, if they are enabled in the build, libobjc and libgfortran
do build. Are they likely to be functional?
I'd hate to guess, seems make check would tell you if they do. I'd
expect there might be an issue with selecting the right multilib
On Apr 30, 2005, at 8:11 AM, Andrew Pinski wrote:
Note why again are you using Apple's branch. It does not get all
fixes
which the 4.0 release branch will get.
It has all that the 4.0.0 release got. Next time we merge, we'll
pull in all the then current 4.0 release branch fodder. As we switc
On Wed, 2005-04-27 at 19:14 +0200, Richard Guenther wrote:
> Jeffrey A Law wrote:
> > On Wed, 2005-04-27 at 16:19 +0200, Richard Guenther wrote:
> >
> >>fold_indirect_ref, called from the gimplifier happily converts
> >>
> >> const char *a;
> >>
> >>...
> >>
> >> *(char *)&a[x] = 0;
> >>
> >>to
>
I am tracking an ICE in VRP that triggers only in Ada. Given
this:
1 D.1480_32 = nam_30 - 30361;
2 if (D.1480_32 <= 1) goto ; else goto ;
3 :;
4 D.1480_94 = ASSERT_EXPR ;
5 goto ();
for name D.1480_94. However, the type of D.1480 is:
(gdb) ptu
On 5/2/05, Scott Robert Ladd <[EMAIL PROTECTED]> wrote:
> You might want to a look at my just-published review of GCC 4.0, where I
> compare it's performance on some well-known applications, including LAME
> and POV-Ray, on Pentium 4 and Opteron. In terms of POV-Ray, 4.0 produced
> a smaller execut
On Fri, 11 Mar 2005, Giovanni Bajo wrote:
>> You may not have noticed that Gerald is away until 13 March. Otherwise
>> website patches do get reviewed quickly.
> I think they are not reviewed quickly enough anyway. I do not have
> evidence (statistics) to bring forward, so feel free to ignore my
On Fri, 2005-04-29 at 17:29, Amir Fuhrmann wrote:
> 1. If I am ONLY interested in the compiler, and do NOT want to build
> libraries, what would be the process ??
"make all-gcc" will build just the compiler without the libraries.
> 2. I looked at newlib, but wasn't sure of the process of includin
> "Thorsten" == Thorsten Glaser <[EMAIL PROTECTED]> writes:
Thorsten> libjava is a pain in the ass, regarding "writes to build directory
Thorsten> during installation time". libtool relinking issues, and the list
Thorsten> of headers to be installed. I have worked around these, but it's
Thorst
Paolo Carlini wrote:
Hi Mark,
I agree; that's why I asked to see the patches.
Humm, maybe a couple of links are in order, for your convenience:
http://gcc.gnu.org/ml/gcc-cvs/2005-03/msg00681.html
http://gcc.gnu.org/ml/gcc-cvs/2005-03/msg00679.html
(I understand that Kriang volunteered to
E. Weddington wrote:
The suggestion to look at Dan Kegel's crosstool is a good one,
>> but crosstool only handles cross compilers to linux, and hence isn't relevant here.
There have been patches to it for building on Cygwin,
plus the occasional success story on Cygwin, IIRC.
(Perhaps Dan can comm
On Mon, May 02, 2005 at 11:27:12PM +0900, Peter O'Gorman wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Marc Espie wrote:
> | How about replacing that piece of junk that is called libtool with
> | something else ?
> |
> | Preferably something that works.
>
>
>
>
> I will be happy
The code below runs significantly slower when compiled in 64 bit with 3.4.3 than
it does in 3.3.4, and both are significantly slower than a 32 bit compile.
Can anyone tell what's going on:
1) between 32 and 64 bits
2) between 3.3.4 and 3.4.3
Thanks.
amd64 3200, 1024k cache
with gcc 3.4.3
-O
>
> On Mon, 2005-05-02 at 19:14 +0200, Biagio Lucini wrote:
> > While discussing whether including gcc 4.0 in a Linux distro, someone
> > pointed
> > out this:
> >
> > http://lists.kde.org/?l=kde-devel&m=111471706310369&w=2
> >
> > I have checked the gcc bugzilla and either I am wrong or there
On Mon, 2005-05-02 at 19:14 +0200, Biagio Lucini wrote:
> While discussing whether including gcc 4.0 in a Linux distro, someone pointed
> out this:
>
> http://lists.kde.org/?l=kde-devel&m=111471706310369&w=2
>
> I have checked the gcc bugzilla and either I am wrong or there is nothing
> relevan
While discussing whether including gcc 4.0 in a Linux distro, someone pointed
out this:
http://lists.kde.org/?l=kde-devel&m=111471706310369&w=2
I have checked the gcc bugzilla and either I am wrong or there is nothing
relevant. Does anyone know some more?
Thanks
Biagio
I have added a mailing list summary for last December to
http://gccnews.chatta.us . I welcome your opinions, either on this list or
privately.
--
rick f.
End DRM for brains !
The World has latched itself to you; change shape and watch the fireworks.
You are someone's predecessor.
http://gccnews.c
> Do you know why GCC4 is deprecated on sparc-openbsd ? It's simply
> because no-one so far has been able to dedicate the CPU time to track
> down the few bugs that prevented us from switching to gcc 3.x from 2.95.
>
> That's right, I said CPU-time. It takes too long to bootstrap the compiler,
>
Hi Mark,
> I agree; that's why I asked to see the patches.
Humm, maybe a couple of links are in order, for your convenience:
http://gcc.gnu.org/ml/gcc-cvs/2005-03/msg00681.html
http://gcc.gnu.org/ml/gcc-cvs/2005-03/msg00679.html
(I understand that Kriang volunteered to regtest and, if n
I am tracking an ICE in VRP that triggers only in Ada. Given
this:
1 D.1480_32 = nam_30 - 30361;
2 if (D.1480_32 <= 1) goto ; else goto ;
3 :;
4 D.1480_94 = ASSERT_EXPR ;
5 goto ();
When visiting statemen #4, VRP tries to create the range [-INF, 1]
for name D
Michael Matz wrote:
Hi,
On Sat, 30 Apr 2005, Kriang Lerdsuwanakij wrote:
Sure, this code compiles with 4.1 and 3.4 but doesn't compile with 4.0.
Although the code is valid, I'd bet it doesn't work the way the
programmer of the above code (or other 99% who doesn't track
the standard closely) would
On Mon, 2 May 2005, Michael Matz wrote:
> I'm a fan of release early, release often. Really. Even if this means
> we would end up with a 4.0.20 after half a year.
While I wouldn't be _that_ agressive, on FreeBSD where I maintain GCC
in the ports collection, I'm usually tracking our weekly snaps
Mark Mitchell <[EMAIL PROTECTED]> writes:
| Richard Guenther wrote:
| > On 4/29/05, Mark Mitchell <[EMAIL PROTECTED]> wrote:
| >
| >>Joseph S. Myers wrote:
| >>
| >>>What's the position on closing 3.4 regression bugs which are fixed in 4.0
| >>>and where it doesn't seem worthwhile to attempt to ba
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Marc Espie wrote:
| How about replacing that piece of junk that is called libtool with
| something else ?
|
| Preferably something that works.
I will be happy to see your bug reports and/or patches. Whining on the gcc
list has never been known to fix
Richard Guenther wrote:
On 4/29/05, Mark Mitchell <[EMAIL PROTECTED]> wrote:
Joseph S. Myers wrote:
What's the position on closing 3.4 regression bugs which are fixed in 4.0
and where it doesn't seem worthwhile to attempt to backport a fix?
They should be closed as FIXED, with a note. It would be
Hello,
This morning, I've posted a short review of GCC 4.0, comparing it to the
3.4.3 on a number of real-world benchmarks (LAME, POV-Ray, the Linux
kernel, and SciMark2). You'll find the results here:
http://www.coyotegulch.com/reviews/gcc4/index.html
Also, I've posted Acovea analysis fo
> OK, I guess the latest compilers from Sun ship with a better "as".
> Unfortunately I'm stuck with Sun Studio One 7 for now. Maybe it should
> be documented that a recent version of "as" is needed by gcc.
A version not affected by the bug. 4.0.0 bootstraps on Solaris 2.5.1 with
as: WorkShop Comp
tbp wrote:
Shameless plug with my own performance analysis regarding SSE on x86-64.
I've ported my coherent raytracer which mostly uses intrinsics in the
hot path (and no transcendentals).
While gcc4.x compiled binaries are ~5% slower than those compiled with
icc8.1 on ia32 (best case), it's the ot
Hi,
The build fails with the following message:
ld: fatal: relocation error: R_SPARC_DISP32:
file .libs/libstdc++.lax/libsupc++convenience.a/vterminate.o:
symbol : offset 0xfccd33ad is non-aligned
Probably a Sun 'as' bug, a similar problem was reported on Solaris 7:
http://gcc.gnu.org/install/spec
Simple question, but I'm not entirely clear from reading the documentation
If I have a gcc configured for i686-* target system and I use that compiler to
build a package without any -m submodel options , is the generated code
1) only suitable for i686 and better, or
2) tuned for i686 and better
Amir Fuhrmann kirjoitti:
1. If I am ONLY interested in the compiler, and do NOT want to build
libraries, what would be the process ??
Be happy with what you already have?
Ok
- 'make all-gcc' builds ONLY GCC
- 'make install-gcc' installs ONLY GCC
The "ONLY GCC" of course means the stuff
James E Wilson kirjoitti:
Amir Fuhrmann wrote:
checking whether byte ordering is bigendian... cross-compiling...
unknown
checking to probe for byte ordering...
/usr/local/powerpc-eabi/bin/ld: warning: cannot find entry symbol
_start; defaulting to 01800074
Looking at libiberty configure, I see i
Hi There!
I hope that's not OT here, but it was discussed a long time ago in here:
http://gcc.gnu.org/ml/gcc/2004-01/msg01766.html
But I don't get the idea of how to fix it:
I am running into troubles to build the
glibc-2.3.5 with the latest
gcc-3.4-200504xx on the latest
2.6.11.x kernels.
on an mp
On 4/29/05, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Joseph S. Myers wrote:
> > What's the position on closing 3.4 regression bugs which are fixed in 4.0
> > and where it doesn't seem worthwhile to attempt to backport a fix?
>
> They should be closed as FIXED, with a note. It would be wrong to
Hi,
On Sat, 30 Apr 2005, Kriang Lerdsuwanakij wrote:
> Sure, this code compiles with 4.1 and 3.4 but doesn't compile with 4.0.
> Although the code is valid, I'd bet it doesn't work the way the
> programmer of the above code (or other 99% who doesn't track
> the standard closely) would expect.
No
E. Weddington kirjoitti:
I don't know if the specific combination will work, but one could
always try. At least it's sometimes a better starting point for
building a lot of cross-toolchains.
If building more than 1000 cross-GCCs is already "a lot of", then the
experience got from that says it
is
Hi,
On Thu, 28 Apr 2005, Mark Mitchell wrote:
> I'd rather not rush to a 4.0.1 release.
I'm a fan of release early, release often. Really. Even if this means we
would end up with a 4.0.20 after half a year. Basically I can think of
only one reason _not_ to release after a critical bug is fi
How about replacing that piece of junk that is called libtool with
something else ?
Preferably something that works.
Between it's really poor quoting capabitilities, and the fact that
half the tests are done at configure time, and half the tests are done
at run-time, libtool is really poor engine
In article <[EMAIL PROTECTED]> you write:
>The alternative of course is to do only crossbuilds. Is it reasonable
>to say that, for platforms where a bootstrap is no longer feasible, a
>successful crossbuild is an acceptable test procedure to use instead?
No.
I've been playing enough with crossbu
39 matches
Mail list logo