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
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
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.
-
http://code.google.com/soc/gcc/about.html
Best of luck with your projects!
--
Laurynas, GSoC 2006 participant
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/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/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/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/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
> 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/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
> 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/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), \
>
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
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&#
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
[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
>> 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
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
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
> 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
> 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
> 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
>> 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
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
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/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
>&
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
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
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
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
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/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
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
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,
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
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 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 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
Hi all,
Just a reminder, as discussed on thread starting at
http://gcc.gnu.org/ml/gcc/2010-06/msg00092.html
--
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
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
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
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
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
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
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
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/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/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/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/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/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/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
> 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/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
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/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
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
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,
>
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
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
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
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
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/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
Hello everybody,
I'd like to participate in SoC, but first of all to get your feedback
about project choice before submitting a proposal.
I've done some GCC work a few years ago: I was involved with the DJGPP
port, also done several minor bugfixes outside that in the
infrastructure. So I have so
Hi,
Thanks for your comments. I'm replying to both emails at once, as they
are related.
2006/5/3, Daniel Jacobowitz <[EMAIL PROTECTED]>:
> - Assuming that Boehm GC turns out to be unusable for the compiler,
> finish the zone collector. Again, searching mailing list about what's
> unfinished wa
2006/5/3, Daniel Berlin <[EMAIL PROTECTED]>:
The number of *host* systems we support that don't have mmap is
approaching 0, if it is not there already :)
Uhm, at least DJGPP as a GCC host system is alive and does not support
mmap. But according to the following discussion, that's non-issue.
2006/5/4, Mark Mitchell <[EMAIL PROTECTED]>:
In the long run, I don't think we really want to be using garbage
collection at all.
[...]
All of the above should not in way be read as an argument against using
the zone collector -- it's actually an argument in favor of improving
the zone collec
Or just use 64K pages on Cygwin. It sounds like that's what's going
on. We may be fetching the page size incorrectly from the system.
In fact, see how bogus the code currently in ggc-zone.c is for the page
size?
Yes...
I suspect Cygwin is blameless here. The runtime page size detection
woul
Now I'm off to write proposal for Google.
Application draft can be found at http://www.cs.aau.dk/~lauras/application.txt
I haven't submitted it yet, so I can incorporate some corrections, if
you have any comments.
Thanks,
--
Laurynas
It seems fine to me. One note for copying collection; I don't know
that you need to solve the local variables problem. What I did during
development was support both copying and non-copying collection;
there's at least one suitable point (probably more - I did not look
very hard) for copying.
Daniel, first of all, how would you prefer to communicate on general
GCC issues? Is it OK to send e-mail to you and to gcc mailing list, or
should I send such mails to gcc mailing list only?
Some of the GCC roots live on the heap memory, e.g. ident_table. These
are not found by Boehm's GC by defa
Hi,
There is a root list, generated by gengtype from parsing the files
looking for those GTY markers.
So, if you look at ggc_mark_roots, you can see the walker that is
walking the root table.
If you look in your *build* directory, and grep for ggc_root_tab, you
will see where the roots are.
Hi,
Yet another question: there are several root lists: gt_ggc_rtab,
gt_ggc_deletable_rtab, gt_pch_cache_rtab, gt_pch_scalar_rtb. Now what
is what? I see that gt_ggc_rtab is an "ordinary" list. The deletable
one seems to have things that can be always collected? The names of
the last two ones sug
Hi,
One of the SoC requirements is to have public development. So I should
I create a branch of my current Boehm's GC experiments and commit my
code there? I'm not sure, because there exists a posibility that this
branch will be thrown away, if we don't go the Boehm's GC route. And
the current co
scribed in detail at
http://gcc.gnu.org/wiki/Garbage%20collection%20tuning. The branch is
maintained by Laurynas Biveinis.
--
Laurynas
Hi,
I'm somewhat stuck with debugging GCC+Boehm's GC bootstrap failure. At
one point cpplib starts producing cpp_string objects with len = 0.
They crash cpp_interpret_string. I'd like to add some assertions to
the code to catch zero-length cpp_strings as early as possible, but I
don't see any ass
Hi,
So far I've been debugging GCC bootstrap failures with Boehm's GC, and
now I'm stuck.
I used to register all GC roots at the startup of GCC, including
stringpool roots. That worked fine until first ht_expand() call, which
moves identifier hash table around in the memory and Boehm's GC still
2006/6/18, Daniel Berlin <[EMAIL PROTECTED]>:
Are you trying to do incremental marking?
If the root set changes in the middle of an incremental mark and it's
still got things from the old root set to mark, i bet it blows up, :)
I thought I was safe with disabled incremental collection.
Addition
You should probably copy Hans, or email the gc list, and see if they
have any idea.
I emailed GC list, let's see if I get any clues there...
--
Laurynas
Hi,
After following the mailing list for a while I got impression that it
is not trivial to interpret "make -k check" results, i.e. if you get
FAILs while testing your changes, that does not necessarily mean that
your code actually broke something, as FAILs are rather common.
So I guess that the
I'm still waiting for the testsuite to complete (it's been running
just for about 24 hours so far). In the meanwhile I'd like to discuss
the first performance results, which I've put on the Wiki:
First number is GCC with Boehm's GC and the number in parentheses is
GCC with page collector.
combin
Thanks for everybody who replied. I have extracted some information
from the replies and described it in
http://gcc.gnu.org/wiki/TestingGCC, see "Interpretation of testsuite
results". Please review and edit as you see fit.
--
Laurynas
2006/6/23, Steven Bosscher <[EMAIL PROTECTED]>:
Don't write off Boehm's GC just yet. You can't expect to beat
something that has seen a lot of tuning for GCC with something that
you got working only a few days ago. There are a lot of special tricks
especially in ggc-page that may put it at an ad
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
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
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
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
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.
--
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
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
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
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 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
> 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
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
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
1 - 100 of 120 matches
Mail list logo
