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
>> 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
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))
{
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
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
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
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,
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
ÊñÜôçóç êáé áãïñÜ öèçíþí áåñïðïñéêþí åéóéôçñßùí.
Wolrdwide: Aegean, Olympic , British Airways etc
Káëýôåñç ôéìÞ, áëáæùíôáò åôáéñéåò êáé çìåñïìéíéá!
WebPage: http://tinyurl.com/kp99l9
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 (
-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
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
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
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
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
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
"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
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/
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~
> 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 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
21 matches
Mail list logo
