Steven Bosscher wrote:
> Kaz, can you commit a patch for sh.c?
I've just applied the patch below.
Regards,
kaz
--
2009-05-08 Kaz Kojima
* config/sh/sh.c: Do not include c-pragma.h.
--- ORIG/trunk/gcc/config/sh/sh.c 2009-05-06 07:11:59.0 +0900
+++ trunk/gcc/conf
On Thu, May 7, 2009 at 6:00 PM, Andrew Pinski wrote:
> Thanks,
> Andrew Pinski
>
> ChangeLog:
>
> * config/spu/spu.c: Remove include of c-common.c
Yes I did have a typo in the changelog I sent to the list, I changed
it before committing (s/c-common.c/c-common.h/).
Thanks,
Andrew Pinski
On Fri, May 1, 2009 at 1:46 PM, Steven Bosscher wrote:
>> config/spu/spu.c:#include "c-common.h"
>
> These I will need to check via a cross compiler. Andrew P., maybe you
> can look at SPU?
It was not needed since:
2006-11-30 Andrew Pinski
* config/spu/spu.c (spu_builtin_range): Move
Snapshot gcc-4.5-20090507 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20090507/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
* Dave Korn wrote on Wed, May 06, 2009 at 07:08:17PM CEST:
> Ralf Wildenhues wrote:
> > I don't yet see why you would need any kind of libtool hacking.
>
> Because of this:
>
> > You also have to ensure that the sub libraries are self-contained, or at
> > least their interdependencies form a di
On Sun, May 3, 2009 at 6:34 AM, Kaz Kojima wrote:
> Steven Bosscher wrote:
> [snip]
>> config/sh/sh.c:#include "c-pragma.h"
>
> FYI, I've confirmed that there are no problems without
> this line for sh4-unknown-linux-gnu.
>
> Regards,
> kaz
>
And I have successfully bootstrapped with this
Dave Korn wrote:
> Hi,
>
> This may be a bit of a noob question, but why does the var_decl for a class'
> vtable have a DECL_CONTEXT referring to the owning record_type, but the
> var_decl for its typeinfo doesn't?
Hmm, I think I found the answer: because it's secretly actually an interna
Dear all,
I come back to you with another weirdness due to bad code generation
on my target architecture. I have a very simplified (for the moment)
rtx_costs and my address_cost is inspired by the i386 version.
However, I actually patched in the whole i386_rtx_cost function,
constraints, predicate
Hi,
This may be a bit of a noob question, but why does the var_decl for a class'
vtable have a DECL_CONTEXT referring to the owning record_type, but the
var_decl for its typeinfo doesn't?
(On i386/PE, this leads to typeinfo not being dllexported.)
cheers,
DaveK
DJ Delorie wrote:
Ian, thanks for reporting this. I'll investigate this more. It
affects only ports using priority allocation (I know only one which
is m32c). DJ just recently reported a reload failure problem on
m32c. Probably that is because of this wrong code.
In checking through th
Forgot to copy the reply to the mailing list.
David
-- Forwarded message --
From: Xinliang David Li
Date: Wed, May 6, 2009 at 10:08 AM
Subject: Re: [Announcement] Creating lightweight IPO branch
To: Richard Guenther
On Wed, May 6, 2009 at 2:00 AM, Richard Guenther
wrote:
> O
Alex Turjan wrote:
--- On Thu, 5/7/09, Maxim Kuvyrkov wrote:
From: Maxim Kuvyrkov
Subject: Re: scheduling question
To: atur...@yahoo.com
Cc: "Vladimir Makarov" , gcc@gcc.gnu.org
Date: Thursday, May 7, 2009, 1:01 PM
Alex Turjan wrote:
Hi,
During scheduling Im confronted with the fact that an
Alex Turjan wrote:
Hi,
During scheduling Im confronted with the fact that an instruction is moved
from the ready list to queued with the cost 2, while according to my
expectations the insn should have been moved to queued with cost 1.
High, Alex. I could look at this, if you have a test and
Paolo Bonzini wrote:
> I'll go for Tuesday unless I get a "go" from either Richard Earnshaw
> (ARM maintainer and global reviewer) or Ramana Radhakrishnan (who's
> taking care of bootstrapping the ARM-fixing patch).
That's fine.
Thank you for taking the ARM situation into account,
--
Mark Mitc
> The slush that I requested last week has been lifted. However, I have
> asked for relative calm until the cond-optab branch has been merged to
> mainline, which will hopefully occur on Friday, May 8th.
cond-optab branch was bootstrapped on arm-linux among other targets, so
the merge should not
On Thu, May 7, 2009 at 3:05 PM, Andrew Haley wrote:
> Dave Korn wrote:
>> Andrew Haley wrote:
>>> eCos@ wrote:
>>
===
int *p;
int main(void)
{
p++;
__asm__ __volatile__ (""::);
p++;
}
>
Dave Korn wrote:
> Andrew Haley wrote:
>> eCos@ wrote:
>
>>> ===
>>> int *p;
>>>
>>> int main(void)
>>> {
>>> p++;
>>> __asm__ __volatile__ (""::);
>>> p++;
>>> }
>>> ===
>
>>> assembly
--- On Thu, 5/7/09, Maxim Kuvyrkov wrote:
> From: Maxim Kuvyrkov
> Subject: Re: scheduling question
> To: atur...@yahoo.com
> Cc: "Vladimir Makarov" , gcc@gcc.gnu.org
> Date: Thursday, May 7, 2009, 1:01 PM
> Alex Turjan wrote:
> > Hi,
> > During scheduling Im confronted with the fact that an
>
Andrew Haley wrote:
> eCos@ wrote:
>> ===
>> int *p;
>>
>> int main(void)
>> {
>> p++;
>> __asm__ __volatile__ (""::);
>> p++;
>> }
>> ===
>> assembly code is like:
>> 'addl $4, %eax'
Nicolas COLLIN wrote:
> Hello,
> first of all excuse me for my english but I'm french so sometimes I make
> some mistakes (many ?).
> I wonder if the intermediate representation (tree) that you describe on
> this page (http://gcc.gnu.org/onlinedocs/gccint/Trees.html#Trees) was
> already implented i
Ralf Wildenhues schrieb:
> * Matthias Klose wrote on Wed, May 06, 2009 at 09:44:07AM CEST:
>> On arm-linux-gnueabi there are regressions of the form
>>
>> /usr/bin/ld: ./atomic-1.exe: hidden symbol `__sync_val_compare_and_swap_4' in
>> /home/doko/gcc/4.4/gcc-4.4-4.4.0/build/gcc/libgcc.a(linux-atomi
Alex Turjan wrote:
Hi,
During scheduling Im confronted with the fact that an instruction is moved
from the ready list to queued with the cost 2, while according to my
expectations the insn should have been moved to queued with cost 1.
Did anybody experience similar problem?
From what you desc
> The problem is that the dependencies in ada/gcc-interface/Make-lang.in
> are out of date.
Indeed, sorry about that.
Now fixed.
* gcc-interface/Make-lang.in: Update dependencies
The change in sinput.adb itself is actually a change adding two new functions,
not yet used, so with no visi
e...@sunnorth.com.cn wrote:
> Here is an optimization question about gcc compiler, we wonder whether it
> is a bug or not.
>
> A simple test program here:
> ===
> int *p;
>
> int main(void)
> {
> p++;
> __asm__ __volatile__ (""::);
>
Hello,
first of all excuse me for my english but I'm french so sometimes I make
some mistakes (many ?).
I wonder if the intermediate representation (tree) that you describe on
this page (http://gcc.gnu.org/onlinedocs/gccint/Trees.html#Trees) was
already implented in egcs 1.1.
Indeed I have to w
cc/../move-if-change ada/bldtools/snamest/snames.nh ada/snames.h
touch ada/stamp-snames
make[3]: Leaving directory `/usr/local/gcc/gcc-20090507/Build/gcc'
make[2]: *** [all-stage1-gcc] Error 2
make[2]: Leaving directory `/usr/local/gcc/gcc-20090507/Build'
make[1]: *** [stage1-bub
Hi
Here is an optimization question about gcc compiler, we wonder whether it
is a bug or not.
A simple test program here:
===
int *p;
int main(void)
{
p++;
__asm__ __volatile__ (""::);
p++;
}
===
> -Original Message-
> From: Michael Matz [mailto:m...@suse.de]
> Sent: 06 May 2009 18:00
> To: Richard Earnshaw
> Cc: Paolo Bonzini; Joern Rennecke; Ramana Radhakrishnan;
> m...@codesourcery.com; gcc@gcc.gnu.org
> Subject: Re: Setting ARM PIC register (Was: RE: GCC 4.5.0 Status Report
>
28 matches
Mail list logo
