This is the mail archive of the
mailing list for the GCC project.
Re: Log messages
- To: lucier at math dot purdue dot edu
- Subject: Re: Log messages
- From: Daniel Berlin <dberlin at redhat dot com>
- Date: 23 Feb 2001 01:22:48 -0500
- Cc: matzmich at cs dot tu-berlin dot de, gcc-patches at gcc dot gnu dot org
- References: <200102230347.f1N3lmR03508@polya.math.purdue.edu>
> Your recent log message:
> Log message:
> Toon want to test new-regalloc branch. So let him ;)
> is somewhat annoying, especially since the changes don't seem to be
> accessible (spelling?) from the gcc-cvs web page for some reason.
Look at the first ChangeLog.RA message i have below, that's the one
(in this case, of course). You are correct though, he should just use
the changelog entries as the commit message, IMHO.
> I'm afraid that, with the rather casual log messages of you and Dan,
2001-02-23 Michael Matz <firstname.lastname@example.org>
* ra.c (colorize_one_web): only use array-ref, if HARD_REG_SET
really is an array (in debug-output).
2001-02-20 Michael Matz <email@example.com>
Bootstraps again on x86.
* ra.c (live_out_1): preliminar support for REG_NO_CONFLICTS blocks.
(init_one_web): base spill_cost on reg_spill_cost().
(colorize_one_web): More Bad Web (tm) handling. Now recursively
trying to spill already colored long neighbors to prevent spilling
short living Bad Webs.
(everywhere): some commentary, finally merged Daniel's changes,
so there exists one ra.c now ;).
* sibcall.c (call_ends_block_p): Honor return of
* Makefile.in (BOOT_CFLAGS): add -O2 again.
(LIBGCC2_CFLAGS): remove -save-temps, add -O2.
* toplev.c (flag_new_regalloc): default to 1.
(rest_of_compilation): honor -fno-new-ra to fall back to
local/global register allocation (the mainline code). I like
it to be able to test if something (like new crashes) depends on
the new register allocator.
<more entries from michael>
2001-02-03 Daniel Berlin <firstname.lastname@example.org>
* bitmap.h : Add dump_bitmap, bitmap_zero, bitmap_union_of_diffs,
bitmap_a_or_b, bitmap_a_and_b, bitmap_first_set_bit,
bitmap_last_set_bit. All for compatibility with sbitmap's.
* bitmap.c (bitmap_zero): New function.
(bitmap_union_of_diffs): New function.
(bitmap_first_set_bit): New function.
(bitmap_last_set_bit): New function.
* df.h: Change to use bitmaps, not sbitmaps, to save memory.
* df.c: Change to use bitmaps, not sbitmaps, to save memory.
I don't see what's causal about these changelog entries.
If you mean commit log, once again, i copy the commit log entries from
the changelog entries, unless there is some reason i can't.
> and the lack of postings to gcc-patches explaining what the purpose
> of various changes is, and what I understand to be a complete lack
> of a log message for the latest merge from the head,
Now then, it bounced the commit message, not me. It also generated it,
I can't resend it without reformatting 5000 lines by hand. I'm not
about to do that. Sorry.
There is a Changelog.RA entry that says a mainline merge was
> no-one will be
> able to trace the development of the RA branch, or the reason for
> some of the code.
Which is why i've been spending time commenting it, as has Michael.
If you suggest to michael that his commit log entries should just be
the same as the changelog entries for the given code, i'm sure he'd be
happy to oblige you.