This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Log messages


lucier@math.purdue.edu writes:

> Michael:
> 
> 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,

>From ChangeLog.RA

2001-02-23  Michael Matz  <matzmich@cs.tu-berlin.de>

	* 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  <matzmich@cs.tu-berlin.de>

	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
	identify_call_return_value.

	* 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  <dberlin@redhat.com>

	* 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,
not me.
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
performed.

> 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.



> 
> Brad


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]