Hi, I'm Derrick Coetzee and I'm a grad student working with Daniel
Wilkerson et al on the Hard Object project at UC Berkeley (see
http://www.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-97.html). To
minimize implementation effort, we'd like to use gcc as the compiler
for our platform. The main tr
The idea I got is about removing .got section in ELF format totally.
Before we go, let's see the limitation on the idea
1) It must be deployed on aligned segment model, such as Linux, which cs.start
= ds.start.
2) Currently, I only know how to do on x86 ELF.
Here is a typical sample in PIC model
On Mon, Nov 23, 2009 at 13:59, Rafael Espindola wrote:
> 2009-11-23 Rafael Avila de Espindola
>
> * lto-wrapper.c (lto_wrapper_exit): Don't try to delete files if
> being called recursively.
OK.
Diego.
2009/11/22 Leandro Nini :
> Hi,
>
> in gcc-4.5 lto-wrapper may end up in an endless loop in case of error:
>
> if for example a 'maybe_unlink_file' call from 'lto_wrapper_exit' fails it
> calls 'fatal_perror' which in turn calls 'lto_wrapper_exit' again causing
> an infinity of
>
> lto-wrapper: del
Hi,
I'm using the latest gcc 4.5 to compile the latest linux kernel(rc8).
$ mips64el-unknown-linux-gnu-gcc --version
mips64el-unknown-linux-gnu-gcc (GCC) 4.5.0 20091123 (experimental)
and encountered this error:
$ make ARCH=mips CROSS_COMPILE=mips64el-unknown-linux-gnu- mm/rmap.o
On Nov 23, 2009, at 10:17, Ian Bolton wrote:
> Regardless of the architecture, I can't see how an unbalanced tree would
> ever be a good thing. With a balanced tree, you can still choose to
> process it in either direction (broad versus deep) - whichever is better
> for your architecture - but,
On 11/23/2009 11:32 AM, Paul Edwards wrote:
So, given the scope below, can someone please explain what
4.4 changes are affecting me and what I need to do to overcome
them?
I think your best bet is to grep the changelogs for what has changes,
and see what was done for other ports. Many target
David Edelsohn wrote:
> On Fri, Nov 20, 2009 at 10:05 AM, Ian Bolton
> wrote:
> > From some simple experiments (see below), it appears as though GCC
> aims
> > to
> > create a lop-sided tree when there are constants involved (func1
> below),
> > but a balanced tree when there aren't (func2 below)
Piotr Wyderski wrote:
> Dave Korn wrote:
>
>> If that doesn't fix it please let me know.
>
> The solution was correct, with binutils 2.20
> the problem disappeared. There is another
> one, however on the snapshot 20091119:
>
> ../../gcc/lto-streamer-out.c: In function 'write_global_references':
2009/11/23 Christian Joensson:
> Seems to me that http://gcc.gnu.org/ml/gcc-cvs/2009-11/msg00648.html
> might cause this:
>
> /usr/local/src/trunk/objdir/./prev-gcc/xgcc
> -B/usr/local/src/trunk/objdir/./prev-gcc/
> -B/usr/local/gnu/i686-pc-cygwin/bin/
> -B/usr/local/gnu/i686-pc-cygwin/bin/
> -B/us
"Paul Edwards" writes:
> Index: gcc4/config.sub
> diff -c gcc4/config.sub:1.3 gcc4/config.sub:1.4
> *** gcc4/config.sub:1.3 Mon Nov 23 12:58:07 2009
> --- gcc4/config.sub Mon Nov 23 22:47:08 2009
You should send patches for config.{guess,sub} to
.
Andreas.
--
Andreas Schwab, sch...@redhat.com
Dave Korn wrote:
> If that doesn't fix it please let me know.
The solution was correct, with binutils 2.20
the problem disappeared. There is another
one, however on the snapshot 20091119:
../../gcc/lto-streamer-out.c: In function 'write_global_references':
../../gcc/lto-streamer-out.c:2201:7: e
Ok, now that 3.4.6 is fully working, I made a start on the 4.4 port.
4.4 appears to have invalidated a lot of 3.4.6 things. Below are all
the changes I needed to make just to get an xgcc executable
built. I didn't really know what most of it was about, but the
purpose was just to scope the chan
On Mon, 23 Nov 2009, Jakub Jelinek wrote:
> On Thu, Nov 19, 2009 at 08:01:57PM +0100, Thomas Gleixner wrote:
> > Just compiled with -mincoming-stack-boundary=4 and the problem goes
> > away as gcc now thinks that the incoming stack is already 16 byte
> > aligned. But that might break code which ac
On Thu, Nov 19, 2009 at 08:01:57PM +0100, Thomas Gleixner wrote:
> Just compiled with -mincoming-stack-boundary=4 and the problem goes
> away as gcc now thinks that the incoming stack is already 16 byte
> aligned. But that might break code which actually uses SSE
Please don't do this, lying to the
Seems to me that http://gcc.gnu.org/ml/gcc-cvs/2009-11/msg00648.html
might cause this:
/usr/local/src/trunk/objdir/./prev-gcc/xgcc
-B/usr/local/src/trunk/objdir/./prev-gcc/
-B/usr/local/gnu/i686-pc-cygwin/bin/
-B/usr/local/gnu/i686-pc-cygwin/bin/
-B/usr/local/gnu/i686-pc-cygwin/lib/ -isystem
/usr/
On 11/22/2009 10:48 AM, John Nowak wrote:
Hello. I would like to get the necessary forms for copyright assignment
to GCC for future work on GNAT. I was told this is the way to kick off
the process.
I sent them offlist.
Paolo
17 matches
Mail list logo
