On 05/14/2010 10:27 PM, Michael Raitza wrote:
Up to now I have basic support up and running. The hash map to the loop
is missing and I have not figured out yet what I need it for, but Basile
mentioned it to be necessary to reliably attach data to the loop data
type.
Actually, this is not real
On Fri, 14 May 2010, Mark Mitchell wrote:
> >> But, of course, arm-elf is really a dead ABI at this point...
> >
> > hmmm... if it's dead enough, it becomes a moot point, doesn't it?
>
> It's pretty dead. Richard Earnshaw recently suggested deprecating
> arm-elf in GCC 4.6. I think that's reas
> On Fri, May 14, 2010 at 9:33 PM, Eric Botcazou wrote:
> >> Ugh. This presents a chicken-and-egg problem to symbol resolution
> >> and type-merging.
> >>
> >> To be clear, the issue is sth like
> >>
> >> unit1
> >> -
> >> int size;
> >> int a[size];
> >>
> >> unit2
> >> --
> >> extern in
> If it isn't, then you can either punt on arm-elf, or enable some
> EABI functionality there. If, on the other hand, you think there's
> a problem when using the EABI, then we should talk about how to
> solve it.
EABI works fine, we're just working through our array of
things-to-be-tested and a
DJ Delorie wrote:
>> Yes, but presumably you could make those pseudo-ops ARM-specific,
>> rather than EABI specific?
>
> Could, but gcc doesn't always know the specific .fpu. I imagine
> version-sync nightmares too, so IMHO we should either do a
> command-line thing from gcc, or just forget it i
> Yes, but presumably you could make those pseudo-ops ARM-specific,
> rather than EABI specific?
Could, but gcc doesn't always know the specific .fpu. I imagine
version-sync nightmares too, so IMHO we should either do a
command-line thing from gcc, or just forget it if EABI works.
DJ Delorie wrote:
>> I thought this stuff already existed in arm-eabi toolchains. If it
>> doesn't exist in arm-elf, then you should be able to use it there too.
>
> The EABI toolchains use eabi-specific pseudos to set the .fpu.
Yes, but presumably you could make those pseudo-ops ARM-specific,
Hi,
I am just working on integrating the struct loop as a boxed type in
MELT. I had a short discussion with Basile on the basic definitions and
changes to be made in melt-runtime.*.
One problem was the garbage collection of the loop structure but it
turned out to that I misjudged this garbage col
> The compiler should generate a pseudo-op that is processed by the
> assembler. If the right pseudo-op doesn't already exist, it needs
> to be added to both the assembler and compiler.
The assembler has pseudo-s for ".fpu" which says what kind of FPU it
has, but the generic hard/soft choice is
On Fri, May 14, 2010 at 9:33 PM, Eric Botcazou wrote:
>> Ugh. This presents a chicken-and-egg problem to symbol resolution
>> and type-merging.
>>
>> To be clear, the issue is sth like
>>
>> unit1
>> -
>> int size;
>> int a[size];
>>
>> unit2
>> --
>> extern int size;
>> extern a[size];
>
> Ugh. This presents a chicken-and-egg problem to symbol resolution
> and type-merging.
>
> To be clear, the issue is sth like
>
> unit1
> -
> int size;
> int a[size];
>
> unit2
> --
> extern int size;
> extern a[size];
>
> ? And you get the a's merged but a diagnostic about mismatched ty
On 14 May 2010 13:01, Bernd Roesch wrote:
> Hi
>
> I compile the GCC4.5.0 on cygwin and when i use it in cygwin shell, all is ok.
> But when i use it on dev-cpp the output contain some crap chars, because GCC
> output utf8 error
> messages
>
> Is there a way to avoid that GCC output text in utf8 ?
DJ Delorie wrote:
>> I am strongly of the opinion that the right way to do this is to have
>> the compiler generate appropriate directives in the assembly files it
>> generates -- and to have users do the same. Relying on the defaults is
>> just too dangerous.
>
> So... where should this go?
Th
> I am strongly of the opinion that the right way to do this is to have
> the compiler generate appropriate directives in the assembly files it
> generates -- and to have users do the same. Relying on the defaults is
> just too dangerous.
So... where should this go?
A release canidate for GCC 4.3.5 is available from
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3.5-RC-20100514
and shortly its mirrors. It has been generated from SVN revision 159394.
I have sofar bootstrapped and tested the release candidate on
x86_64-unknown-linux-gnu. Please test it and report
On Fri, May 14, 2010 at 3:34 PM, Toon Moene wrote:
> On 04/25/2010 01:24 PM, Toon Moene wrote:
>
>> Richard Guenther wrote:
>
> [ Concerning this assert ]
>
>>> It is checking that for one symbol we only have one definition.
>>>
>>> You are using -fuse-linker-plugin?
>>
>> Indeed, I do (all of our
On 04/25/2010 01:24 PM, Toon Moene wrote:
Richard Guenther wrote:
[ Concerning this assert ]
It is checking that for one symbol we only have one definition.
You are using -fuse-linker-plugin?
Indeed, I do (all of our code ends up in libraries - .a files - so I
have to, to make -flto -fwho
On Fri, 14 May 2010, Steven Bosscher wrote:
> On Fri, May 14, 2010 at 3:04 PM, Richard Guenther wrote:
>
> > Priority # Change from Last Report
> > --- ---
> > P1 0
> > P2 104 - 28
> > P3 0 -
On Fri, May 14, 2010 at 3:04 PM, Richard Guenther wrote:
> Priority # Change from Last Report
> --- ---
> P1 0
> P2 104 - 28
> P3 0 - 1
> --- ---
> Tota
Status
==
The 4.3 branch is now frozen for the preparation of a 4.3.5
release.
The branch is ageing and changes to it should be limited to
obviously correct changes. In the past month I have skimmed
through the bugs that were fixed for 4.4 and backported a
bunch of obvious regression fixes.
Hi
I compile the GCC4.5.0 on cygwin and when i use it in cygwin shell, all is ok.
But when i use it on dev-cpp the output contain some crap chars, because GCC
output utf8 error
messages
Is there a way to avoid that GCC output text in utf8 ?
Here is dev-cpp source.Its since long time not forthe
On Fri, May 14, 2010 at 07:18, Richard Guenther
wrote:
> It probably also can be re-implemented as gdb python script?
Really? Wicked. I like that.
Diego.
On Fri, May 14, 2010 at 1:24 PM, Eric Botcazou wrote:
> Hi,
>
> most of the remaining warnings issued by the LTO compiler on object files
> compiled from Ada are caused by a small flaw in the GIMPLE types merging
> process: it is done before symbols are merged so compatible types (typically
> doma
Ours is a vliw processor too, but my focus was on register allocation.
Unfortunately, the instruction with unspec is still marked to interfere
with all virtual registers and hence gets spilled. I was hoping the one
with unspecs might do better there, but no change there. So, i end up
with simil
Yes, we use this instead of unspec_volatile out of performance concern.
Our target is a VLIW processor, so there is more opportunities to move
instructions around. Did you observe any instruction that should be
moved but not?
Cheers,
Bingfeng
> -Original Message-
> From: Hariharan Sandan
Hi,
most of the remaining warnings issued by the LTO compiler on object files
compiled from Ada are caused by a small flaw in the GIMPLE types merging
process: it is done before symbols are merged so compatible types (typically
domain types of arrays) whose distinguishing features depend on sym
Hi Bengfeng,
Changing my instruction patterns similar to the ones that you sent does
get over the correctness issue. Setting the imaginary register
explicitly this way and adding those extra unspec patterns does seem to
work. But, performance-wise, it still doesn't give me anything. Did you
de
On Thu, May 13, 2010 at 11:45 PM, Diego Novillo wrote:
> On 5/4/10 15:11 , Wolfgang kaifler wrote:
>
>> (gdb) p browse_tree (current_function_decl)
>> No symbol "browse_tree" in current context.
>> (gdb)
>>
>> What i'm doing wrong? Any ideas?
>
> The tree browser code has bitrotted to the point th
28 matches
Mail list logo
