hi,
I have been porting tic54x to gcc. I use gcc-4.2.2 version. I write some
simplest c54x.h and c54x.c and a empty md, and I
compile it to generate the tic54x-gcc compiler.
But when I execute the compiler I generate I got a segmentation fault error. Is
there anything must be define in c54x.c
On Tue, 11 Dec 2007, Jon Smirl wrote:
> On 12/11/07, Nicolas Pitre <[EMAIL PROTECTED]> wrote:
> > On Tue, 11 Dec 2007, Nicolas Pitre wrote:
> >
> > > OK, here's something else for you to try:
> > >
> > > core.deltabasecachelimit=0
> > > pack.threads=2
> > > pack.deltacachesize=1
Hello Everyone,
I got past that negdi2 and some errors..now I am trying to compile
some linux module, and it says I am not able to find this constraint:
init/main.c: In function 'start_kernel':
init/main.c:441: error: insn does not satisfy its constraints:
(insn 112 110 478 12 (set (mem:QI (re
Junio C Hamano wrote:
Linus Torvalds <[EMAIL PROTECTED]> writes:
So what you actually want to do is to just re-use already packed delta
chains directly, which is what we normally do. But you are explicitly
looking at the "--no-reuse-delta" (aka "git repack -f") case, which is why
it then blow
Nicolas Pitre wrote:
On Tue, 11 Dec 2007, David Miller wrote:
From: Nicolas Pitre <[EMAIL PROTECTED]>
Date: Tue, 11 Dec 2007 12:21:11 -0500 (EST)
BUT. The point is that repacking the gcc repo using "git repack -a -f
--window=250" has a radically different memory usage profile whether you
do
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On Tue, 11 Dec 2007, Jon Smirl wrote:
>> >
>> > So if you want to use more threads, that _forces_ you to have a bigger
>> > memory footprint, simply because you have more "live" objects that you
>> > work on. Normally, that isn't much of a problem, sinc
On Tue, 11 Dec 2007, Jon Smirl wrote:
> >
> > So if you want to use more threads, that _forces_ you to have a bigger
> > memory footprint, simply because you have more "live" objects that you
> > work on. Normally, that isn't much of a problem, since most source files
> > are small, but if you ha
On Tue, 11 Dec 2007, Jon Smirl wrote:
> This makes sense. Those runs that blew up to 4.5GB were a combination
> of this effect and fragmentation in the gcc allocator.
I disagree. This is insane.
> Google allocator appears to be much better at controlling fragmentation.
Indeed. And if fragment
On 12/11/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Tue, 11 Dec 2007, Jon Smirl wrote:
> >
> > So why does our threaded code take 20 CPU minutes longer (12%) to run
> > than the same code with a single thread?
>
> Threaded code *always* takes more CPU time. The only thing you can hope
>
On Tue, 11 Dec 2007, David Miller wrote:
> From: Nicolas Pitre <[EMAIL PROTECTED]>
> Date: Tue, 11 Dec 2007 12:21:11 -0500 (EST)
>
> > BUT. The point is that repacking the gcc repo using "git repack -a -f
> > --window=250" has a radically different memory usage profile whether you
> > do the r
On 12/11/07, Jon Smirl <[EMAIL PROTECTED]> wrote:
>
> Total CPU time 196 CPU minutes vs 190 for gcc. Google's claims of
> being faster are not true.
Depends on your allocation patterns. For our apps, it certainly is :)
Of course, i don't know if we've updated the external allocator in a
while, i'l
From: Nicolas Pitre <[EMAIL PROTECTED]>
Date: Tue, 11 Dec 2007 12:21:11 -0500 (EST)
> BUT. The point is that repacking the gcc repo using "git repack -a -f
> --window=250" has a radically different memory usage profile whether you
> do the repack on the earlier 2.1GB pack or the later 300MB pac
On Tue, 11 Dec 2007, Linus Torvalds wrote:
> That said, I suspect there are a few things fighting you:
>
> - threading is hard. I haven't looked a lot at the changes Nico did to do
>a threaded object packer, but what I've seen does not convince me it is
>correct. The "trg_entry" access
Hello,
I tried to define a new machine mode for a data type only allocated to
certain registers, e.g., MAC registers. I first used an unused PDI mode
(same as Blackfin porting).
In target-modes.def file:
PARTIAL_INT_MODE (DI);
Then in my test program, I tried to define a new data type using P
On Tue, 11 Dec 2007, Jon Smirl wrote:
>
> So why does our threaded code take 20 CPU minutes longer (12%) to run
> than the same code with a single thread?
Threaded code *always* takes more CPU time. The only thing you can hope
for is a wall-clock reduction. You're seeing probably a combination
On 12/11/07, Nicolas Pitre <[EMAIL PROTECTED]> wrote:
> On Tue, 11 Dec 2007, Nicolas Pitre wrote:
>
> > OK, here's something else for you to try:
> >
> > core.deltabasecachelimit=0
> > pack.threads=2
> > pack.deltacachesize=1
> >
> > With that I'm able to repack the small gcc pack
On Tue, 11 Dec 2007, Nicolas Pitre wrote:
> OK, here's something else for you to try:
>
> core.deltabasecachelimit=0
> pack.threads=2
> pack.deltacachesize=1
>
> With that I'm able to repack the small gcc pack on my machine with 1GB
> of ram using:
>
> git repack -a -f
On 12/11/07, Nicolas Pitre <[EMAIL PROTECTED]> wrote:
> On Tue, 11 Dec 2007, Nicolas Pitre wrote:
>
> > And yet, this is still missing the actual issue. The issue being that
> > the 2.1GB pack as a _source_ doesn't cause as much memory to be
> > allocated even if the _result_ pack ends up being th
On Tue, 11 Dec 2007, Nicolas Pitre wrote:
> And yet, this is still missing the actual issue. The issue being that
> the 2.1GB pack as a _source_ doesn't cause as much memory to be
> allocated even if the _result_ pack ends up being the same.
>
> I was able to repack the 2.1GB pack on my machin
On Tue, 11 Dec 2007, Jon Smirl wrote:
> Switching to the Google perftools malloc
> http://goog-perftools.sourceforge.net/
>
> 10% 30 828M
> 20% 15 831M
> 30% 10 834M
> 40% 50 1014M
> 50% 80 1086M
> 60% 80 1500M
> 70% 200 1.53G
> 80% 200 1.85G
> 90% 260 1.87G
> 95% 520 1.97G
On Tue, 11 Dec 2007, Jon Smirl wrote:
> I added the gcc people to the CC, it's their repository. Maybe they
> can help up sort this out.
Unless there is a Git expert amongst the gcc crowd, I somehow doubt it.
And gcc people with an interest in Git internals are probably already on
the Git maili
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
/SCRATCH/gcc-build/Linux/i686-pc-linux-gnu/gcc-4.3.0/gcc-4.3.0/./prev-gcc/xgcc
- -B/SCRATCH/gcc-build/Linux/i686-pc-linux-gnu/gcc-4.3.0/gcc-4.3.0/./prev-gcc/
- -B/opt/gcc/Linux/i686-pc-linux-gnu/gcc-4.3.0/i686-pc-linux-gnu/bin/ -c -g
-O2
- -fomit-fr
22 matches
Mail list logo
