Hi -
> Another "problem" with gengtype is that it doesn't know what types can
> end up in a PCH. The CFG data structures can *never* be in a PCH, but
> there still are PCH writer functions. This is true for many other data
> structures as well.
Yes, gengtype does not differentiate between GC and
> === Approach: Use the Boehm collector.
>
> The general approach is to define allocation and deallocation
> functions to the Boehm collector that handle memory within the
> PCH range. We would also provide a class to register global
> roots at the point of declaration of those roots. We would lik
>>> GRAMMAR
>>>
>>> Support adding a second discriminator. This support is not for
>>> multiple inheritance, but for single inheritance when a second
>>> discriminator is used to further refine it. Look at struct
>>> tree_omp_clause. It contains a sub union. We can represent the
>>> hierarchy l
Lawrence -
I don't have an opinion from the rest of compiler point of view, but
gengtype implementation-wise, it certainly looks doable. One minor
comment below -
> GRAMMAR
>
> Support adding a second discriminator. This support is not for
> multiple inheritance, but for single inheritance when
2012/7/4 Jonathan Wakely :
> At some point in the past few weeks it became impossible to build
> trunk from a sparse checkout that omits certain directories.
>
> Because I nearly always configure with --enable-languages=c,c++ I use
> git's core.sparseCheckout=true config or "svn update --set-depth"
>> I agree that such conversion will have to be done at some point, but
>> I'm not sure if a big rewrite should happen way before the rest of the
>> code will start to use gengtype-annotated C++ data structures.
>
> Wait, I don't follow. gengtype supporting C++ data structures is
> different than
2012/3/2 Diego Novillo :
> It already is. We bootstrap in C++ mode. I don't see a problem starting to
> move some code to C++. Whether this is a good chunk of code to convert is
> another question.
Sorry, I should have been more precise and said "not the best first
module choice to convert to C
Basile -
> I'm quite tempted to start working on a rewrite of gengtype in C++ (using
> C++03 standard).
>
> One of the reasons is that gengtype is really in bad shape, and nobody
> understands it well. Another reason is that gengtype needs to be enhanced to
> accept at least common C++ containers
Basile -
2011/10/19 Basile Starynkevitch :
> On Wed, Oct 19, 2011 at 04:31:48PM +0300, Laurynas Biveinis wrote:
>> In the end I believe that it is the patches that talk. Whatever
>> patches are going to be submitted, reviewed and accepted, that is
>> going to be GCC&#
Basile -
2011/10/18 Basile Starynkevitch :
> Still, I find strange that while some very smart & nice GCC guys want to get
> rid of Ggc,
> no patch made into the trunk towards that goal (which I Basile dislike and
> don't share,
> so don't expect me Basile to work on this.).
Well, there is my RT
2011/8/15 Andreas Schwab :
> I think it was meant to be this:
>
> #define ggc_alloc_rtvec_sized(NELT) \
> ggc_alloc_zone_rtvec_def (sizeof (struct rtvec_def) \
> + ((NELT) - 1) * sizeof (rtx), \
>
> On Mon, Aug 15, 2011 at 2:16 PM, 王亮 wrote:
>> The size it allocates is
>>
>> (sizeof (struct rtvec_def) + ((NELT) - 1)) * sizeof (rtx)
>> Originally, the allocated size is
>>
>> sizeof (struct rtvec_def) + ((NELT) - 1) * sizeof (rtx)
Yes, this is correct, good catch.
>> (sizeof (struct rtv
2011/5/1 Mark Mitchell :
> The GCC Steering Committee appointed me to the role of GCC Release
> Manager on March 22, 2000, as part of the GCC 3.0 release cycle. Eleven
> years and umpteen releases later, it's time for me to relinquish that
> position.
Mark -
Thank you for your service as a RM du
> Thanks Diego, please send me the form. I'll sign it as soon as my
> contributions require it.
Don't wait; sign it right away - it might take a while to process it.
--
Laurynas
2011/4/27 Dimitrios Apostolou :
> * ggc_internal_alloc_stat() or maybe implementing proper memory management
> instead of garbage collection, for hottest caller
This one can easily take much more time than three months. I've been
working in this area, right now I'm working on allocating RTL outsid
2011/3/7 Basile Starynkevitch :
> However, some source files considered by gengtype are outside of $(srcdir)
> because they are somewhere else in the GCC source tree.
> So most of the source files considered by gengtype are indeed in the
> $(srcdir) of the gcc/Makefile.in that is in the gcc/ sub
2011/2/13 Joseph S. Myers :
> User-visible improvements relative to 4.5 should also be
> documented in gcc-4.6/changes.html if not already mentioned there.
We also have a new section for developer-visible changes which would
be helpful for plugin and out-of-the-tree front-/back-end developers,
ple
2011/2/8 Hans-Peter Nilsson :
> On Thu, 27 Jan 2011, Laurynas Biveinis wrote:
>> Thus I propose to separate the two. To avoid introducing another
>> --enable-checking option, let's move the annotations to the "misc"
>> checking and also enable "misc"
2011/2/4 Basile Starynkevitch :
> An obvious strategy is to use the hardware watchpoint feature of GDB.
> However, one cannot nicely put a watchpoint on an address which is not
> mmap-ed yet.
Actually, you can do this with a recent enough GDB (7.1 AFAIK). It
will keep watchpoint disabled until the
2011/1/28 Basile Starynkevitch :
>> Its intention is to mention noteworthy internal changes, i.e. changes
>> interesting for, say, maintainers of backends/frontends outside the
>> tree, and of course plugin developers upgrading from 4.5 to 4.6.
>>
>
>
> I am not sure to understand what is the socia
On gc-improv I am working on PCH (mis-)feature that it stores a few
RTXes in a PCH file through tree (think tree_decl_with_rtl). I would
like to keep GTY completely away from RTL and that requires keeping
away RTL from PCH too.
In recent discussions on increasing GCC modularity, were there any
sug
2011/1/27 H.J. Lu :
> I think it is useful. I have run --enable-checking=valgrind once and it
> took daays to finish. But I haven't got time analyze the result.
Do you mean, bootstrap + testsuite? IIRC someone submitted a few bug
reports (fixed now) in a row some three years ago which loo
2011/1/27 Richard Guenther :
> On Thu, Jan 27, 2011 at 1:23 PM, Laurynas Biveinis
> wrote:
>> The --enable-checking=valgrind does two things. First, it provides
>> Valgrind annotations for internal GCC allocators so that Valgrind has
>> a better idea about memory blocks w
I have just added a new section (approved by Gerald) to the bottom of
http://gcc.gnu.org/gcc-4.6/changes.html
Its intention is to mention noteworthy internal changes, i.e. changes
interesting for, say, maintainers of backends/frontends outside the
tree, and of course plugin developers upgrading fr
The --enable-checking=valgrind does two things. First, it provides
Valgrind annotations for internal GCC allocators so that Valgrind has
a better idea about memory blocks which are not supposed to be
accessed. Second, it actually invokes Valgrind on every compiler
invocation. This makes the option
Hi -
2010/11/12 Bingfeng Mei :
> Hello,
> In our port, I created a new NOTE to preserve pragma info. The
> note is generated as follows in expanding builtins.
>
> rtx note = emit_note(NOTE_INSN_LOOPCOUNT_PRAGMA_BEG);
> rtx vector = gen_rtx_PARALLEL (VOIDmode,
>
NERS to reflect your appointment.
I've just committed the following:
Index: ChangeLog
===
--- ChangeLog (revision 165606)
+++ ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2010-10-18 Laurynas Biveinis
+
+ * MAINTAIN
2010/9/14 Diego Novillo :
> Incidentally, this is an issue I would like to address. We need
> someone interested in maintaining the GC machinery. Any volunteers?
> Laurynas?
Thanks for the suggestion. In fact, I was meaning to apply. But I can
see a few things that need to be considered:
- Most
variable_size annotations mask the fact
that c-lang.h does not have it. This is something that really should
be diagnosed by gengtype.
I will apply it to trunk later as obvious.
gcc/ChangeLog:
2010-09-14 Laurynas Biveinis
* c-lang.h (struct lang_type): Add variable_size GTY option.
gcc
2010/9/13 Dennis, CHENG Renquan :
> On Mon, Sep 13, 2010 at 8:16 PM, Laurynas Biveinis
> wrote:
>> I am the author of how these macros are generated, but somehow I have
>> missed this thread initially. Could you send me off-list that
>> gtype-desc.h file?
>
> The pro
> renq...@flyer-1-1:~/src/gcc-4.6-build$ grep -RsInw
> ggc_alloc_cleared_lang_type gcc/
> gcc/gtype-desc.h:2451:#define ggc_alloc_cleared_lang_type() ((struct
> lang_type *)(ggc_internal_cleared_alloc_stat (sizeof (struct
> lang_type) MEM_STAT_INFO)))
>
> this definition just doesn't accept any arg
2010/9/6 Basile Starynkevitch :
> On Mon, 6 Sep 2010 06:36:48 +0300
> Laurynas Biveinis wrote:
>
>> 2010/9/2 Basile Starynkevitch :
>> > Hello Laurynas, Diego & all the list.
>> >
>> > A precise question about gengtype (the current trunk one)
>&g
2010/9/2 Basile Starynkevitch :
> Hello Laurynas, Diego & all the list.
>
> A precise question about gengtype (the current trunk one)
>
> I have the impression that every member of the 'param_structs' variable
> in gengtype.c (viewed as a linked list of types linked thru their next
> field) is also
2010/8/27 :
> We recompiled GCC-trunk r162692 with the following modification :
>
> In function output_type_enum of gcc/gengtype.c, we replaced
>
> - if (s->kind == TYPE_PARAM_STRUCT && s->u.s.line.file != NULL)
> + if (s->kind == TYPE_PARAM_STRUCT && s->u.param_struct.line.file != NULL)
>
> And
2010/8/27 :
> We think that the enum type_kind discriminates fields union in struct type.
> So for TYPE_PARAM_STRUCT we believe that
> the param_struct field of union u inside struct type is used. If this is
> true, the test s->u.s.line.file != NULL is meaningless when s->kind ==
> TYPE_PARAM_
2010/8/25 Basile Starynkevitch :
> On Wed, 2010-08-25 at 22:41 +0300, Laurynas Biveinis wrote:
>>
>> > Besides, testing any gengtype change is very expensive for us (&
>> > probably for others), because we have to regenerate all the gt*.[ch]
>> > generate
2010/8/25 Basile Starynkevitch :
> I am not at all sure we would be able to sent them separately, in such a
> way that gengtype still works correctly with each patch applied one by
> one.
It's hard to tell without looking at your patch, but your cleanups do
sound independent. Also you can define t
2010/8/24 Basile Starynkevitch :
> Hello All
>
> Jeremie Salvucci and me Basile are working on improving gengtype. Our
> patch is still buggy [curious people might retrieve it from
> http://starynkevitch.net/Basile/gengtype-r163335-24august-2010.diff
I was meaning to take a look to get an idea wha
2010/7/14 Basile Starynkevitch :
> I am quite sure that at some point in the past, the mark_hook did work.
>
> But I have the impression that with the current gengtype, they don't.
[...]
> Does any one have a working example of mark_hook GTY?
Have you ruled out user errors here? Are there any mark
Hi,
2010/7/13 Basile Starynkevitch :
> The type machinery then provides allocators that take a parameter indicating
> an exact size of object being allocated (like malloc does)
>
> and the exemple should better be
>
>
> Then the objects of struct sorted_fields_type are allocated in GC memory as
Hi,
Sorry for the delayed reply.
> Do you think it is only my misunderstanding (as everyone noticed, my
> English language is poor since it is not my native language), or a bug
> of the gengtype documentation, or a bug in gengtype code? Can several
> GTY tags appear for the same union component a
2010/6/15 Basile Starynkevitch :
> /*** NOTE: june 2010.
>
> GCC 4.6 has a new typed garbage collected allocator; so any
> GTY-ed struct FOO_ST should be allocated using ggc_alloc_FOO_ST
> or ggc_alloc_cleared_FOO_ST.
> ***/
> #if BUILDING_GCC_VERSION >= 4006 && defined(g
2010/6/8 Joern Rennecke :
> Quoting Laurynas Biveinis :
>
>> I forgot in my previous e-mail the actual diff and the ChangeLogs of
>> the gc-improv merge, attaching now.
>
> Your gcc/gcc/cp/ChangeLog entry starts with 'Likewise.'
I have noticed it before the actua
On x86_64/linux, the merge does not cause any new testsuite
regressions, except the fact that two new testcases were added during
the freeze:
gfortran.dg/proc_ptr_27.f90
g++.dg/cpp0x/decltype23.C
So now I am more or less done with testing, and I am waiting for any
complaints :)
--
Laurynas
Hi all,
I've committed the gc-improv code to trunk. The testsuite is still
running, however bootstrap went fine on x86_64/linux. Due to nature of
the changes, any problems should show up as bootstrap compile errors
and on x86_64/linux I don't expect them.
The problems are more (although IMHO not
Hi all,
Just a reminder, as discussed on thread starting at
http://gcc.gnu.org/ml/gcc/2010-06/msg00092.html
--
Laurynas
2010/6/2 Richard Guenther :
> On Wed, Jun 2, 2010 at 1:51 PM, David Edelsohn wrote:
>> On Wed, Jun 2, 2010 at 2:07 AM, Laurynas Biveinis
>>> All the patches from gc-improv merge have been approved. Due to the
>>> scope of the changes, the merge will need trunk freeze. T
2010/6/2 Ian Lance Taylor :
>> Ian, do you have an idea on how to avoid _M_impl dependency in
>> gengtype or what else to do about it?
>>
>> Because we can trivially make gengtype mark the vector itself and mark
>> whatever was put into vector, but not _M_impl.
>
> I don't think I understand the qu
2010/6/2 Ian Lance Taylor :
> As you say, gengtype includes specific support for VEC. Using
> std::vector instead will require some work in gengtype, but not too
> much. Currently gengtype generates code like this for a VEC:
>
> size_t l0 = (size_t)(((*x).base).num);
> for (i0 = 0;
2010/6/2 Basile Starynkevitch :
> I am not entirely convinced of that. VEC is supported not only by
> infamous vec.h macros (which we surely want to replace by some template,
> possibly std::vec) but also by gengtype (and the Gcc Garbage Collector).
>
> I strongly believe we will need a garbage col
Hello all -
All the patches from gc-improv merge have been approved. Due to the
scope of the changes, the merge will need trunk freeze. Thus I am
planning to do it next Tuesday, at 7am CEST. The freeze should last
about 2-3 hours.
Alternatively I could also do the merge tomorrow at the same time,
Basile -
FYI I have started a page on gengtype and its improvement areas:
http://gcc.gnu.org/wiki/gengtype . Maybe you'd like to add some notes
there on e.g. what enhancements are required for better plugin support
and similar.
Cheers,
--
Laurynas
2010/4/13 Dave Korn :
> Until I find time to do a more major rewrite, anyone who wants to do testing
> on Cygwin could do worse than apply the sticking-plaster patch that I posted
> at:
>
> http://www.mail-archive.com/cygwin-patc...@cygwin.com/msg04677.html
>
> and build themselves a locally mod
2010/4/27 Diego Novillo :
> On 4/19/10 10:43 , Laurynas Biveinis wrote:
>
>> 1) New API in libiberty for creating of hash tables and splay trees
>> with user-specified callbacks for allocation. Needs libiberty
>> maintainer review.
>> 2) Make gengtype accept varia
2010/4/20 Richard Guenther :
> On Mon, Apr 19, 2010 at 4:43 PM, Laurynas Biveinis
[...]
>> from
>> foo *x = (foo *)ggc_alloc (sizeof (x));
>> to
>> foo *x = ggc_alloc_foo ();
[...]
> Sounds good to me. With a typed interface we should know
> the alignment requi
2010/4/19 Basile Starynkevitch :
> Laurynas Biveinis wrote:
>> The goal of the branch is to make the type of GC-allocated objects
>> known to GC at allocation time, by changing the allocation interface
>> from
>> foo *x = (foo *)ggc_alloc (sizeof (x));
>> to
>&
Hi,
Now that GCC is in the stage1 and gc-improv branch work is finished as
I see it, I propose to merge it to mainline.
The goal of the branch is to make the type of GC-allocated objects
known to GC at allocation time, by changing the allocation interface
from
foo *x = (foo *)ggc_alloc (sizeof (x
2010/3/13 Basile Starynkevitch :
> b. the plugin invocation convention could be improved. In particular, one
> could have (as it is the case of many other major plugin-ehancable software,
> e.g. Mozilla, Qt, Gtk, ...) a specific directory to install plugins, and
> invoke gcc -fplugin=treehydra inst
>> You might want to look at the gengtype debugging dump support on
>> gc-improv branch, which I will submit shortly for 4.6 trunk.
>
> Thanks! Yes, I looked at your gengtype.c in your branch, and it is the kind
> of code I was dreaming of.
> Usually, in persistency machinery, the code to reload d
> 1. (in ordinary non plugin mode, within a plugin-enabled GCC) gengtype
> not only generates all the necessary gt*.h files, but also generate an
> easy-to-parse textual representation (perhaps in JSON or XML or Lispy
> syntax) of all the data it has processed (that is of all the GTY-ed
> data desc
> MELT only need gengtype to generate its gt-melt-runtime.h but I have no idea
> if that file depends upon the configuration (and notably the target for
> which GCC is built). The GTY-ed data of MELT does not depend (IMHO) upon the
> configuration directly (in the sense that there is no #ifdef arou
> static GTY(( is_param(union tree_code) )) htab_t boud_ins = NULL;
Ah, now it's clear. You probably wanted "union tree_node" with n, not c, here.
--
Laurynas
Hi,
It's hard to tell. The normal definition of tree_code is enum in
tree.h and it is an atomic type with respect GCC garbage collection.
But the names like gt_gcc_mx_tree_code suggest that GCC internals try
to treat it as a struct or some other non atomic type. Any chance
that your source does n
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
>> 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
[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" about
GC_MAYBE_POINTED_TO, thus I extende
Hi all,
I saw that folks on IRC were wondering about branch commits that were
not posted to gcc-patches. I was planning to emerge from stealth mode
once the branch had something that could be useful for trunk, but
since there is interest I will post status and plans now.
Right now there are three
I have updated
http://gcc.gnu.org/wiki/SvnBranch
with information on how to use svn 1.5.0 to maintain branches.
Please review, comment, edit etc. - especially in the places marked
"untested" :)
Thanks,
--
Laurynas
Daniel Berlin :
> Errr, the format is not pre-1.5.0
> It was svnadmin upgraded a while ago.
>
>
> On Sat, Apr 25, 2009 at 5:06 AM, Laurynas Biveinis
> wrote:
>> Hi,
>>
>> Apparently the server is already running svn 1.5.5 but the repository
>> format is pr
Hi,
Apparently the server is already running svn 1.5.5 but the repository
format is pre-1.5.0. If the repository format was upgraded, we could
start using proper svn merge support for branch maintenance and get
rid of manual merges and svnmerge.py. There is even an upgrade path
from the svnmerge.p
Hi,
I was (and largely still am) in your situation. I'd suggest to start,
if you already haven't done so, by just trying building
(bootstrapping) GCC as needed for development, running testsuite,
learning how to compare two testsuite runs. Then try running cc1 under
gdb, familiarize with the GCC o
Hello,
Since mainline is in, or is about to enter very soon, stage 3, I have
created a new branch "gc-improv" for GC work and related changes that
are not strictly bug fixes. The difference from the old boehm-gc
branch is that this one will not contain Boehm's GC integration.
As my previous email
Hello,
I've spent last two months at Google quietly working on the boehm-gc
branch from my last year's SoC project -
http://gcc.gnu.org/wiki/Garbage_collection_tuning . To recap, I've
integrated Boehm's GC into GCC proper, adjusted gengtype and GGC
support files to generate typed GC allocators for
http://code.google.com/soc/gcc/about.html
Best of luck with your projects!
--
Laurynas, GSoC 2006 participant
2006/12/12, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
I've come across an issue with using the -pg switch for profiling on the
DJGPP DOS platform, using GCC 4.1.0.
I suggest that you send this report to [EMAIL PROTECTED], the
DJGPP port of GCC maintainers are much more likely to respond there.
-
I am not sure to understand what if_marked or deletable means in GTY context
"Deletable" just sets the pointer to NULL on garbage collection, in
practice making it a weak pointer. "If_marked" provides a callback for
a bit more sophisticated weak pointers, so that an user-provided
routine can tel
However, there is still a question which puzzles me a lot? Why gengtype is
not a sort of filter or generator (like yacc is) taking a (list of) files on
input and producing a file on output?
This question puzzles me too. Would be nice to have something in
Makefile machinery that would grep source
Hey, just cause SoC is over doesn't mean i'm not happy to answer your
questions to the degree I can, so please, keep cc'ing me.
That's great, thanks :)
> I'd like to get your feedback about design of frontend-specific type
> tag infrastructure in gengtype.
>
> First of all, how things are done
Hi all,
(Daniel, now that SoC is over, I guess this is the last my email with
CC: to you, unless you prefer otherwise :)
I'd like to get your feedback about design of frontend-specific type
tag infrastructure in gengtype.
First of all, how things are done currently in WIP version:
1) A big enum
> 1) Any advise on selecting Linux distro?
Any one will do. Or Windows, MS-DOS, AIX, IRIX, Solaris, Mac OS/X, or
any other platform GCC runs on. Use whatever you're comfortable with.
But note that on Windows (Cygwin) GCC testsuite runs several orders of
magnitude slower than on Linux: it lite
gengtype doesn't support anonymous structures or unions, you need to
give them a name. (I don't remember if this is simply a limitation of
the existing implementation or if it's more fundamental.)
OK, naming them has helped. Out of curiosity, why does following
typedef int *lambda_vector;
typ
At the risk of stating the obvious, those parentheses after "GTY" look
unbalanced to me.
Of course, these were fixed very soon :)
--
Laurynas
> ../../gcc-boehm-custom-marking/gcc/value-prof.h:48: syntax error,
> unexpected '*', expecting ')'
>
> What should I do about it?
>
Have to typedef the pointer due to gengtype silliness, IIRC.
IE typedef struct histogram_value_t *histogram_value_t_p;
then use histogram_value_t_p in the structu
Hi,
For typed GC allocation I've to add GTY markers for a few datatypes.
An example from value-prof.h:
Before:
struct histogram_value_t
{
struct
{ /* <--- line 48, error below occurs here */
tree value;/* The value to profile. */
tree stmt;
2006/7/25, Basile STARYNKEVITCH <[EMAIL PROTECTED]>:
A theoritical alternative might be to use a precise copying collector
like Qish. http://starynkevitch.net/Basile/qishintro.html In
practice, this would be impractical (even if the GTY marker could
help) because it requires changing a lot of c
GCC is just too huge to try and implement reference counting
just to see what it would do, right? All managed structures would have
to include a base class with the count in it and all new references would
have to be through a macro...
That's certainly possible, maybe even interesting, but I'm
2006/7/25, Daniel Berlin <[EMAIL PROTECTED]>:
There probably are.
But at some point, if you are tuning boehm's to this point, what is the
advantage of it over just writing your own collector like ggc-page? :)
Indeed. That's why I always welcome opinions, should I continue with
Boehm's or stop
2006/7/24, Andrew Pinski <[EMAIL PROTECTED]>:
No, GC is just not running as you have too much memory to cause it to
run with --disable-checking :).
Oh! Now my performance results have totally different interpretation
under Linux...
--
Laurynas
> 4) I have configured Linux compilers with "--disable-checking". I was
> quite surprised to see that GGC times have disappeared from the "-Q
> -ftime-report -fmem-report" output. Is this expected by design
> behaviour? What minimum configure options will cause GGC time to
> reappear?
Yes that is
Hi,
(This email is quite long; if you are not interested in performance
data, scroll down for my questions that you might be able to answer)
Below are some performance results with --with-gc=boehm. This
collector since the last posted results at
http://gcc.gnu.org/ml/gcc/2006-06/msg00729.html, h
So, gcj still uses boehm-gc 6.3-hacked-to-bits. Is there any chance of
bringing it up to date (at least version 6.7)?
I suggest to use boehms-gc branch for public test of 6.7 import, this
way you could test how the newer collector operates as a libgcj
runtime while I could test it as a host GCC
Hi,
This patch does three things:
1) Fix broken --with-gc=page. Now it is possible to build GCC with
these two collectors from exactly same sources.
2) Boehms's GC makes GCC print collector warnings time from time about
very large blocks being allocated. These warnings are meaningless, so
they a
Since I got advised both for and against adding a ChangeLog entry, I'm
inclined to leave things as they are for now unless somebody beats me
to it.
--
Thanks,
Laurynas
You forgot a ChangeLog entry for
r115313 | lauras | 2006-07-10 12:44:48 -0700 (Mon, 10 Jul 2006) | 2 lines
Fix spaces to tabs in the last commit.
I'm not sure. I think that my ChangeLog entry by my previous commit
(the br
This patch broke building GCC because Makefile indention was done with
spaces instead of a TAB.
Obvious fix commited, r115313. That will teach me how to think "oh
well that's a tiny patch I sent a month ago, I'll just copy it from
the mail archives instead of locating it on my disk".
Sorry.
--
c&view=rev&rev=115310
> Log:
> fixincludes:
> 2006-07-10 Laurynas Biveinis <[EMAIL PROTECTED]>
>
> PR bootstrap/20437
> * Makefile.in (configure, config.h.in): change into $(srcdir)
> before autoconf or autoheader call.
This patch broke building
2006/6/25, Paulo J. Matos <[EMAIL PROTECTED]>:
> combine.c: top mem usage: 52180k (13915k). GC execution time 0.66
> (0.61) 4% (4%). User running time: 0m16 (0m14).
>
How are you collecting top mem usage?
Sorry, that's not the top mem usage, but rather peak GC allocated
bytes. Determining them
2006/6/23, David Nicol <[EMAIL PROTECTED]>:
Is it possible to turn garbage collection totally off for a null-case
run-time comparison or would that cause thrashing except for very
small jobs?
It should be possible to adopt ggc-none for usage in GCC proper with
little effort. Shouldn't cause tra
Hi,
> combine.c: top mem usage: 52180k (13915k). GC execution time 0.66
> (0.61) 4% (4%). User running time: 0m16 (0m14).
Are these with checking on or off? Normally checking is on, you have
to go out of your way to turn it off. If it were on, the real
numbers are going to look much worse tha
1 - 100 of 120 matches
Mail list logo
