On 9/9/06, Mark Mitchell <[EMAIL PROTECTED]> wrote:
Kenny Simpson wrote:
> What is the status of the 4.1 branch? Any word on 4.1.2?
My current plan is to do a 4.1.2 along with 4.2.0. My concern has been
that with 4.2.0 moving slowly, trying to organize another release might
just distract the d
My original attempt to build gcc trunk yesterday used the
cctools from Xcode 2.3 and produced the failure...
/bin/sh ./libtool --mode=compile /sw/src/fink.build/gcc4-4.1.999-20060908/darwin
_objdir/./gcc/xgcc -B/sw/src/fink.build/gcc4-4.1.999-20060908/darwin_objdir/./gc
c/ -B/sw/lib/gcc4/powerp
hi,
I am looking into implementing a new instrumentation pass in gcc
called a "globalizer" and I would be really grateful for feedback
on whether or not such a pass could be considered for inclusion
(from a purely technical perspective).
1) Rationale
I work on network simulation too
On 09 September 2006 16:34, mathieu lacage wrote:
> The idea is to change the way the address of a global
> variable is calculated: rather than merely access a memory
> area directly or through the GOT, we need to add another
> level of indirection.
>
> The simplest way to add another level of in
On Sat, 2006-09-09 at 16:52 +0100, Dave Korn wrote:
> I think this would be a great feature to have, even if it did only work with
> simple globals and couldn't handle TLS.
>
> Disclaimer: I haven't thought it through thoroughly yet :) Nor am I sure
> whether the better solution might not be
On Sat, 2006-09-09 at 17:34 +0200, mathieu lacage wrote:
> Another solution would be to do something like this:
>
> extern void *magic_function (void *variable_uid);
>
> static int a;
> void foo (void)
> {
> void *ptr = magic_function (&a);
> int *pa = (int *)ptr;
> *pa = 1;
>
Snapshot gcc-4.2-20060909 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20060909/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.2 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
(Google does not requires me to write this report, yet I would like to
bring some attention to the project, hoping that patches are reviewed
and open issues are discussed.)
The following is the final report on my Google's Summer of Code
project. It summarises what we have achieved so far, which i
Using the cctools from Xcode 2.4, the failure changes and moves to the linkage
of libgfortran itself...
ld: .libs/maxloc0_4_r16.o unknown flags (type) of section 2
(__TEXT,__literal16) in load command 0
ld: .libs/maxloc0_8_r16.o unknown flags (type) of section 2
(__TEXT,__literal16) in load c
On Tue, Sep 05, 2006 at 01:27:45PM -0700, Steve Ellcey wrote:
> I am not sure what the 'right' way to do this is. I wound up editing
> /usr/share/dejagnu/remote.exp to change 'set timeout 300' to 'set
> timeout 2000' and I edited /usr/share/dejagnu/config/unix.exp to change
> 'set status [remote_
Eric,
One last question. Is it correct to assume that when
the newer cctools with the literal16 support becomes
available, things like 'integer(16)' will become available
in gfortran for darwin?
Jack
Jack Howarth wrote:
Eric,
One last question. Is it correct to assume that when
the newer cctools with the literal16 support becomes
available, things like 'integer(16)' will become available
in gfortran for darwin?
Seems reasonable to expect that it could be made to happen.
-eric
Has anyone else noticed that the testcase
long-long-cst1.c has started to fail on both
powerpc-apple-darwin8.5.0 and on other ppc
targets like powerpc64-unknown-linux-gnu? It
appears to be still passing as of r116775 and
to be failing as of r116778.
Jack
On Sat, 2006-09-09 at 22:16 -0400, Jack Howarth wrote:
> It appears to be still passing as of r116775 and
> to be failing as of r116778.
The testcase was just added at r116777 so it cannot be a regression.
-- Pinski
Andrew,
Odd. When I do 'svn log', the entry for r116777 doesn't show
a testcase being added. Oh, well.
Jack
That's not correct. The linker support only exists in ld64 for Xcode
2.4. It fails like this for ld(32). 32-bit Darwin targets shouldn't be
using this assembly feature...
Shantonu
On Sep 9, 2006, at 12:16 PM, Eric Christopher wrote:
Using the cctools from Xcode 2.4, the failure changes an
Shantonu Sen wrote:
That's not correct. The linker support only exists in ld64 for Xcode
2.4. It fails like this for ld(32). 32-bit Darwin targets shouldn't be
using this assembly feature...
Right, I knew that. Looks like I have a typo though. Bah.
I'll fix it shortly. Though nothing wrong
17 matches
Mail list logo
