On Fri, Aug 21, 2009 at 5:37 AM, Steven Bosscher wrote:
> On Fri, Aug 21, 2009 at 10:52 AM, Laurynas
> Biveinis wrote:
BTW, it does not deal with types that in some instances have variables
allocated in proper GC way (with a path from GC root) and in some
instances not. Fixing these
> I assume that at some point in time, ada didn't depend on an
> existing gnat,
Yeah, but that point in time was close to 20 years ago ...
The best way to do something like this is to make a cross-compiler to OS/2,
build assembler files, copy them into the OS/2 native build treee, assemble
them,
On 08/21/2009 04:01 PM, Jean Christophe Beyler wrote:
/* If we have a 0, use r0 instead */
Don't do this. See how, e.g. alpha and mips handle the zero register.
You want to leave this as (const_int 0) throughout compilation.
r~
On Fri, Aug 21, 2009 at 03:40:57PM -0700, Paul Smedley wrote:
> I'm wanting to update the GNU ADA compiler for OS/2... I'm currently
> building GCC 4.3.x and 4.4.x on OS/2 (C/C++/fortran) but for ADA
> configure complains about not finding gnat. The problem is that the
> only gnat compiled for OS/
"Paul Smedley" writes:
> I assume that at some point in time, ada didn't depend on an existing
> gnat, so if I could find that version, I could compile a version of
> gnat to get me started?? Otherwise it's a bit chicken and egg :(
Gnat needs a relatively recent gnat to compile itself. You us
Dear all,
I actually have determined that doing what I say below is a bad idea
since it will probably lessen the impact of future optimizations in
the compiler. However, I'm curious to know why it didn't work :-)
Here goes: I've been working on getting better code generation and one
thing I notic
Hi All,
I'm wanting to update the GNU ADA compiler for OS/2... I'm currently
building GCC 4.3.x and 4.4.x on OS/2 (C/C++/fortran) but for ADA
configure complains about not finding gnat. The problem is that the
only gnat compiled for OS/2 was years ago using a different toolchain
so it's not s
On 08/21/2009 02:37 PM, Jerry Quinn wrote:
OK, I've gotten almost this far and can bootstrap (the asterisk is
actually not the very first char and I have to figure that out).
However, in the referenced test case, both typeinfos are apparently
merged, thus returning the same pointer for their name
On Thu, 2009-08-20 at 15:22 +0100, Dave Korn wrote:
> Your patch puts the asterisk into the namespace identifier decl, so it ends
> up in both the rtti NTBS name string, and also in the generated asm name for
> the objects. What I think you need to do is use an identifier for the
> anonymous nam
Philip Herron writes:
> But after i return true in lang_init i get the error:
>
> gpy1: internal compiler error: in init_excess_precision, at toplev.c:2160
>
> Really not sure where i can start to debug this any help would be
> great.
You debug this by looking at line 2160 of toplev.c and readin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hey
I'm working on my own front-end its all just a skeleton based quite
closely off the java front-end/treelang,
But after i return true in lang_init i get the error:
gpy1: internal compiler error: in init_excess_precision, at toplev.c:2160
Really n
To whom it may concern:
Regarding the 16 gfortran failures involving gfortran.dg/stat_[12].f90
as seen in http://gcc.gnu.org/ml/gcc-testresults/2009-08/msg02179.html
(and all other recent testsuite reports from me):
It turns out that my gcc objdir was in a tmp directory owned by the
wheel group (
ÊñÜôçóç êáé áãïñÜ öèçíþí áåñïðïñéêþí åéóéôçñßùí.
Wolrdwide: Aegean, Olympic , British Airways etc
Káëýôåñç ôéìÞ, áëáæùíôáò åôáéñéåò êáé çìåñïìéíéá!
WebPage: http://tinyurl.com/kp99l9
Laurynas Biveinis writes:
> [Third try. Apparently the compressed dump was still too big to get through]
>
> So I got fed up with trying to navigate gengtype maze of type_p,
> pair_p and others and trying to figure out the difference between
> GC_POINTED_TO and GC_USED and what is so "maybe" abou
Paul Edwards wrote:
> >> /* Store in OUTPUT a string (made with alloca) containing an
> >>assembler-name for a local static variable named NAME.
> >>LABELNO is an integer which is different for each call. */
> >>
> >> #ifdef TARGET_PDPMAC
> >> #define ASM_FORMAT_PRIVATE_NAME(OUTPUT, NAME,
2009/8/21 Steven Bosscher :
> Not to discourage you, but, eh... --
On the contrary, I think this is a very interesting idea.
> wouldn't it be a much more useful
> project to move RTL out of GC space completely instead of improving GC
> for rtxes? The life time of RTL is pretty well defined by no
2009/8/21 Paolo Bonzini :
>> Here tem should not be allocated on GC memory.
>
> I disagree, as this would not apply to tem only but also to anything
> allocated to fold it. This is not going to be maintainable (what if fold
> create temporary types, which need to be in GC memory definitely?).
I s
On Fri, Aug 21, 2009 at 10:52 AM, Laurynas
Biveinis wrote:
>>> BTW, it does not deal with types that in some instances have variables
>>> allocated in proper GC way (with a path from GC root) and in some
>>> instances not. Fixing these is going to be hard.
>>
>> Do you have some examples?
>
> Trees
On 08/21/2009 10:52 AM, Laurynas Biveinis wrote:
Trees and rtxes mostly. I haven't got around to taking a closer look,
but for example folders love allocating temporary trees. For example,
in tree-ssa-ccp.c:fold_gimple_assign,
if (COMPARISON_CLASS_P (op0))
{
>> BTW, it does not deal with types that in some instances have variables
>> allocated in proper GC way (with a path from GC root) and in some
>> instances not. Fixing these is going to be hard.
>
> Do you have some examples?
Trees and rtxes mostly. I haven't got around to taking a closer look,
bu
1) Stop abusing current GC by allocating structures there that GC
knows nothing about, i.e. there is never a path from GC roots to any
variables of that type and so gengtype does not produce markers it.
That's good.
BTW, it does not deal with types that in some instances have variables
alloc
21 matches
Mail list logo
