--- Comment #35 from steven at gcc dot gnu dot org 2008-12-20 09:54 ---
Re comment #34: Good idea, but add:
5) quadratic behaviour in find_temp_slot_from_address.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #19 from steven at gcc dot gnu dot org 2008-12-20 09:56 ---
Fixing all targets is beyond my hacking skills.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot
|dot org
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|steven at gcc dot gnu dot |unassigned at gcc dot gnu
|org
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot
|dot org
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #1 from steven at gcc dot gnu dot org 2008-12-20 15:50 ---
Probably 4.5 material (alias improvement branch).
You could try --param max-aliased-vops=0 as a work-around.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2008-12-21 00:33 ---
Created an attachment (id=16951)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16951&action=view)
Avoid expensive inline heuristics at O0, and speed up add_alias_set_conflicts
This problem is always g
--- Comment #8 from steven at gcc dot gnu dot org 2008-12-23 18:19 ---
The problem is that phi_translate returns an expression "eprime" of a different
type. For the test case of comment #6, we phi_translate
"(eq_expr,&state,obj_1)" to "(bool)1".
--- Comment #9 from steven at gcc dot gnu dot org 2008-12-23 18:51 ---
Hack demonstrates the problem:
Index: tree-ssa-pre.c
===
--- tree-ssa-pre.c (revision 142907)
+++ tree-ssa-pre.c (working copy)
@@ -3274,6
--- Comment #7 from steven at gcc dot gnu dot org 2008-12-23 18:59 ---
Please don't re-open bug reports because you "speculate" when others have
analyzed the issue properly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38608
--- Comment #1 from steven at gcc dot gnu dot org 2008-12-26 15:38 ---
GCC inline heuristics are just that: heuristics. They are not optimal for all
targets but only for those targets that they have been tuned for.
For AVR, nobody ever tuned the heuristics, despite several suggestions
--- Comment #1 from steven at gcc dot gnu dot org 2008-12-28 12:05 ---
GCC should not generate cmov instructions if you use -march={i586,c3} and, as
far as I can tell, it does not since gcc 3.2.
Since you have not provided a test case, there is nothing we can do with this
bug report
--- Comment #10 from steven at gcc dot gnu dot org 2008-12-28 12:20 ---
Re. comment #9
This is imho a bug, but I'd probably just fix it with a small documentation
update. Mark tends to describe the situation as it should be, but I wouldn't
want you to expect Mark, nor anyon
--- Comment #12 from steven at gcc dot gnu dot org 2008-12-28 12:51 ---
Undesirable. As Mark already pointed out, we'd probably end up breaking legacy
code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33932
--- Comment #15 from steven at gcc dot gnu dot org 2008-12-28 13:15 ---
Which part of "...as I don't think people are trying to..." gives you the
certainty that really "people don't"?
Anyway, as far as I'm concerned, this is end of discussion.
--- Comment #16 from steven at gcc dot gnu dot org 2008-12-28 13:23 ---
In fact, Mark's suggestion wouldn't actually work in all cases. With
-ffunction-sections, your function definition may end up in a section that will
be eliminated by the linker. And if the preceding sec
--- Comment #4 from steven at gcc dot gnu dot org 2008-12-30 13:36 ---
Subject: Bug 38584
Author: steven
Date: Tue Dec 30 13:35:00 2008
New Revision: 142963
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142963
Log:
PR middle-end/38584
* ipa-
--- Comment #5 from steven at gcc dot gnu dot org 2008-12-30 13:37 ---
We should not use the full bin-packing algorithm for any optimization level. A
simpler heuristic is called for. I'll see if I can come up with something.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38584
--- Comment #4 from steven at gcc dot gnu dot org 2008-12-31 14:44 ---
Unable to reproduce -> INVALID.
--
steven at gcc dot gnu dot org changed:
What|Removed |Ad
--- Comment #4 from steven at gcc dot gnu dot org 2009-01-02 18:21 ---
Confirmed at r134530 with the following reduced test case:
typedef unsigned int USItype __attribute__ ((mode (SI)));
typedef unsigned int UDItype __attribute__ ((mode (DI)));
typedef USItype halffractype;
typedef
--- Comment #5 from steven at gcc dot gnu dot org 2009-01-02 18:25 ---
The zero_extract:DI appears for the first time in the .163r.combine dump.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36003
--- Comment #1 from steven at gcc dot gnu dot org 2009-01-03 00:36 ---
Created an attachment (id=17024)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17024&action=view)
Add address -> temp slot map
Instead of huge list walks, just look up the address in the hash table a
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #1 from steven at gcc dot gnu dot org 2009-01-03 00:48 ---
Perhaps the front end should not emit this code on the latch?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from steven at gcc dot gnu dot org 2009-01-03 10:24 ---
Reviewer said: "So, this is ok with or without the volatile restriction." (see
http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00070.html). The committed patch
still seems to have this restriction...?
--- Comment #18 from steven at gcc dot gnu dot org 2009-01-03 15:24 ---
Closing this as a dup of bug 38582 because that bug has a test case.
*** This bug has been marked as a duplicate of 38582 ***
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from steven at gcc dot gnu dot org 2009-01-03 15:24 ---
*** Bug 15023 has been marked as a duplicate of this bug. ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2009-01-03 17:23 ---
I agree with Vlad, this is not a regression.
It'd still be nice if you can figure out a way to make this work, Vlad. It is
possible, perhaps, to split huge basic blocks up in chunks (e.g. separate basic
bloc
--- Comment #8 from steven at gcc dot gnu dot org 2009-01-04 00:15 ---
Subject: Bug 38584
Author: steven
Date: Sun Jan 4 00:15:08 2009
New Revision: 143040
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143040
Log:
PR middle-end/38584
* cfg
--- Comment #3 from steven at gcc dot gnu dot org 2009-01-04 00:16 ---
Subject: Bug 38586
Author: steven
Date: Sun Jan 4 00:15:58 2009
New Revision: 143041
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143041
Log:
PR middle-end/38586
* function.c
--- Comment #4 from steven at gcc dot gnu dot org 2009-01-04 00:17 ---
.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #9 from steven at gcc dot gnu dot org 2009-01-04 00:17 ---
.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from steven at gcc dot gnu dot org 2009-01-04 14:45 ---
Can you fill in the "known-to-work" field please, if you think this is a
regression?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38722
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |critical
Status|UNCONFIRMED |NEW
--- Comment #9 from steven at gcc dot gnu dot org 2009-01-04 18:45 ---
Thanks HJ for looking into this. I think revision 143027 is not the cause,
it's more likely that it uncovers a latent bug. I'm trying to reduce Joost's
code to a small test case. So far, what I&#
--- Comment #6 from steven at gcc dot gnu dot org 2009-01-04 15:13 ---
Does not fail for me on i686-pc-cygwin with gcc version 4.4.0 20090103
(experimental) [trunk revision 143030]. What target are you compiling for?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38722
--- Comment #10 from steven at gcc dot gnu dot org 2009-01-04 19:51 ---
Created an attachment (id=17031)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17031&action=view)
Failing test case (still needs all the .mod files)
This is as far as I can reduce it with delta.
Joost
--- Comment #11 from steven at gcc dot gnu dot org 2009-01-04 20:02 ---
Note that this test case ICEs in IRA, but I've checked that it ICEs on the same
insn, and in both cases we're looking at incorrect recog_data.
$ gdb --args ../f951.exe -O t.f90
GNU gdb 6.8.0.20080328-c
--- Comment #12 from steven at gcc dot gnu dot org 2009-01-04 21:07 ---
This fixes it for me. However, I'm no RTL expert, and especially combine I
know nothing about :-)
I'll test/post this and see how the RTL guru's judge it.
* combine.c (try_combine): Adjust
--- Comment #13 from steven at gcc dot gnu dot org 2009-01-04 21:38 ---
My patch is wrong. The changes are reverted by undo_all() later on. However,
the bug still is in combine.c. It should not leave insns with the wrong
INSN_CODE.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #14 from steven at gcc dot gnu dot org 2009-01-04 21:39 ---
Leaving this to an RTL expert.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from steven at gcc dot gnu dot org 2009-01-07 09:37 ---
I have no intention to fix this in 4.3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38584
--- Comment #13 from steven at gcc dot gnu dot org 2009-01-08 10:21 ---
Reopening...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #14 from steven at gcc dot gnu dot org 2009-01-08 10:22 ---
...to unassign and avoid spam from cnstar9988 (who is free to test/submit the
patch if it's so important for him/her to have this bug fixed in gcc 4.3).
--
steven at gcc dot gnu dot org changed:
--- Comment #5 from steven at gcc dot gnu dot org 2009-01-09 20:55 ---
Joern, re. comment #4, Richi refers to my patch to enable PRE at -Os, see [1].
An extension to this patch that we tested on x86 machines, is to disable PRE
for scalar integer registers, via SMALL_REGISTER_CLASSES
--- Comment #19 from steven at gcc dot gnu dot org 2009-01-13 08:19 ---
Joern, nobody is forcing you to follow the crowd if you think the crowd is
going in the wrong direction.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38401
--- Comment #8 from steven at gcc dot gnu dot org 2009-01-14 10:54 ---
Re comment #7
Those patches are just proof-of-concept, and wouldn't actually help without
additional changes in tree-ssa-pre.c. If you want, I can make the patches
apply and work properly, and send them to y
--- Comment #4 from steven at gcc dot gnu dot org 2009-01-15 11:15 ---
Re. #3
Yes, the pro/epilogues are special.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38854
--- Comment #2 from steven at gcc dot gnu dot org 2009-01-17 18:05 ---
That code is ancient, and wrong from day 1 if your analysis is correct :-)
http://gcc.gnu.org/viewcvs/trunk/gcc/alias.c?r1=21967&r2=23060
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38879
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot
|dot org
--- Comment #2 from steven at gcc dot gnu dot org 2009-01-19 22:49 ---
Yah, seen -> CONFIRMED
--
steven at gcc dot gnu dot org changed:
What|Removed |Ad
--- Comment #11 from steven at gcc dot gnu dot org 2009-01-19 22:53 ---
I vote WONTFIX. No user is ever going to notice this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38871
--- Comment #13 from steven at gcc dot gnu dot org 2009-01-20 23:01 ---
Created an attachment (id=17155)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17155&action=view)
Throttle PRE, hookize SMALL_REGISTER_CLASSES
This is the patch I have in my local tree (bootstrapped&am
--- Comment #6 from steven at gcc dot gnu dot org 2009-01-20 23:16 ---
-static bool code_motion_path_driver (insn_t, av_set_t, ilist_t,
- cmpd_local_params_p, void *);
+static int code_motion_path_driver (insn_t, av_set_t, ilist_t
--- Comment #18 from steven at gcc dot gnu dot org 2009-01-24 20:51 ---
The patch could be backported GCC 4.3 if folks want to have it fixed there.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36365
--- Comment #68 from steven at gcc dot gnu dot org 2009-05-07 15:40 ---
Be careful with -frename-registers, it is quadratic in the size of a basic
block. For Bradley's test cases it will certainly give a slow-down.
I have tried a rewrite of -frename-registers, but I keep running
--- Comment #77 from steven at gcc dot gnu dot org 2009-05-07 17:50 ---
Re. comment #75: Just the fact that an option is enabled in both releases
doesn't mean the pass behind it is doing the same thing in both releases. What
the scheduler does, depends heavily on the code you fe
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
CC||steven at gcc dot gnu dot
--- Comment #15 from steven at gcc dot gnu dot org 2009-05-10 13:51 ---
The late stack slot allocation idea will just cause other problems, like
missing CSE of addresses. GCC should just get the conflicts right somehow...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39604
--- Comment #17 from steven at gcc dot gnu dot org 2009-05-10 14:22 ---
How will dropping the MEM_EXPRs solve the wrong coalescing in cfgexpand?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39604
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
CC|steven at gcc dot gnu dot |
|org |
AssignedTo
--- Comment #3 from steven at gcc dot gnu dot org 2009-05-14 20:24 ---
FWIW:
-fstrength-reduce is a no-op
-fcse-follow-jumps is a no-op
-fcse-skip-blocks -is a no-op (the crash will be fixed before the day is over)
-fforce-addr isa no-op
The gnuboy maintainers should probably look
--- Comment #4 from steven at gcc dot gnu dot org 2009-05-14 20:57 ---
Subject: Bug 40144
Author: steven
Date: Thu May 14 20:56:54 2009
New Revision: 147543
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147543
Log:
PR driver/40144
* opts.c (common_handl
--- Comment #5 from steven at gcc dot gnu dot org 2009-05-14 20:57 ---
http://gcc.gnu.org/viewcvs?view=rev&revision=147543
--
steven at gcc dot gnu dot org changed:
What|Removed |A
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #3 from steven at gcc dot gnu dot org 2009-05-28 18:15 ---
This will never be implemented.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from steven at gcc dot gnu dot org 2009-06-03 08:16 ---
Ramana, can you please add the exact command line you are using (so that I can
see what flags you use and what cpu you target) and the exact output you are
expecting? I have hacked things such that the store is
--- Comment #11 from steven at gcc dot gnu dot org 2009-06-03 08:25 ---
s/L4/L5/
my punishment from manually typing over the assembly from my laptop screen into
bugzilla on the desktop :-/
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34849
--- Comment #1 from steven at gcc dot gnu dot org 2009-06-03 10:36 ---
This code comes from the split2 (split insns after reload). So this is target
specific. It surprises me that non-legitimate constants are accepted before
reload on ARM (at least in thumb mode). It may be (and IMHO
--- Comment #2 from steven at gcc dot gnu dot org 2009-06-03 10:57 ---
FWIW it looks like the define_split at arm.c:5060 (of r147729) is triggered.
Richard E., is there a reason for lowering load-immediates so late in the
pipeline?
--
steven at gcc dot gnu dot org changed
--- Comment #4 from steven at gcc dot gnu dot org 2009-06-04 12:52 ---
This is one of the "GCC 4.5 pending patches". Now would be a good time to do
something with this patch -- like, submitting it.
--
steven at gcc dot gnu dot org changed:
What
--- Comment #2 from steven at gcc dot gnu dot org 2009-06-04 12:53 ---
This is one of the "GCC 4.5 pending patches". Since we are in stage 1, now is a
good time to submit this patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38091
--- Comment #32 from steven at gcc dot gnu dot org 2009-06-04 12:54 ---
Jerry, was the patch submitted already?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32784
--- Comment #11 from steven at gcc dot gnu dot org 2009-06-04 12:55 ---
Oh, the temptation to close this as WONTFIX Objections?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #35 from steven at gcc dot gnu dot org 2009-06-04 12:58 ---
This bug is marked as one of the "GCC 4.5 pending patches" PRs. Why? I see no
pending patch...?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20548
nditional return not always profitable with -Os
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot
--- Comment #1 from steven at gcc dot gnu dot org 2009-06-06 17:56 ---
I tested the patch on arm-elf ("-march=armv7-r" and "-march=armv7 -mthumb"),
trunk revision 148235, -Os, unpatched and patched, with CSiBE:
armv7-r:
unpatched : 3557127 bytes
patched : 355
--- Comment #3 from steven at gcc dot gnu dot org 2009-06-08 11:41 ---
"might be" is such a useless statement.
Carrot, you are aware of the -fdump-rtl-all and -dAP options, I assume? Then
you should have no trouble finding out:
1) Where the move comes from
2) Why postreload
--- Comment #9 from steven at gcc dot gnu dot org 2009-06-08 22:43 ---
There shouldn't be a "!". Just make use optimize_function_for_speed_p(cfun).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39284
--- Comment #10 from steven at gcc dot gnu dot org 2009-06-08 22:45 ---
Honza, what do the basic blocks 2 and 71 look like for you, exactly? I see no
memory load. But I have local crossjumping patches -- as you know ;-) -- so I
am probably not looking at the same dumps as you are
--- Comment #5 from steven at gcc dot gnu dot org 2009-06-09 08:34 ---
Hmm, I was under the impression that postreload-cse could move instructions
too, but that was just wishful thinking.
I don't really see how the scheduler can solve this. The scheduler would have
to know wha
--- Comment #16 from steven at gcc dot gnu dot org 2009-06-11 19:48 ---
The patch is in 4.4. Apparently it doesn't work? I'll have another look...
--
steven at gcc dot gnu dot org changed:
What|Removed
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot
|dot org
--- Comment #6 from steven at gcc dot gnu dot org 2009-06-13 23:45 ---
I would still like to know why these constants can't be lowered earlier.
Exposing the split-up insns may allow CSE to do a better job, etc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40327
--- Comment #2 from steven at gcc dot gnu dot org 2009-06-14 18:04 ---
For reference:
Broken by http://gcc.gnu.org/viewcvs?view=rev&revision=148471
--
steven at gcc dot gnu dot org changed:
What|Removed |A
--- Comment #28 from steven at gcc dot gnu dot org 2009-06-14 19:54 ---
Created an attachment (id=17995)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17995&action=view)
Patch agains r148322, works pre-RA only
Joern's original ifcvt.c patch only dealt with p
--- Comment #2 from steven at gcc dot gnu dot org 2009-06-18 14:00 ---
Why does the zero-bits machinery in combine not make these redundant extensions
go away?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40487
--- Comment #2 from steven at gcc dot gnu dot org 2009-06-20 05:56 ---
There is an optimization that does this (thread prologue/epilogue insns) but it
is not always a profitable transformation, see e.g. PR40361.
You should analyze why this transformation doesn't happen for your
--- Comment #3 from steven at gcc dot gnu dot org 2009-06-20 07:23 ---
Output from ./cc1 -march=armv5te -mthumb -Os PR40499.c -dAP:
.file "PR40499.c"
.text
.align 1
.global dual_feasible
.code 16
.thumb_func
--- Comment #5 from steven at gcc dot gnu dot org 2009-06-22 08:06 ---
The only way to really fix this, is to make an RTL epilogue for thumb. Turning
to Richard Earnshaw again for advice...
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #8 from steven at gcc dot gnu dot org 2009-06-22 08:12 ---
Re. Comment #5:
I have no plans to sumbit this patch. But do feel free to foster-parent it ;-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28050
--- Comment #6 from steven at gcc dot gnu dot org 2009-06-22 16:21 ---
Is there anything in the tool chain that handles this right now (linker maybe)?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from steven at gcc dot gnu dot org 2009-06-22 16:25 ---
Since this is inherently a heuristics issue, and the IRA heuristics result in
overall better code size according to Vlad, I would like to propose we close
this PR as WONTFIX. Would anyone object to that?
--
http
--- Comment #5 from steven at gcc dot gnu dot org 2009-06-22 16:29 ---
How is this different from bug 39837?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from steven at gcc dot gnu dot org 2009-06-22 16:32 ---
Did that patch go in already?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from steven at gcc dot gnu dot org 2009-06-22 16:36 ---
Is this related to bug 39715?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40487
--- Comment #11 from steven at gcc dot gnu dot org 2009-06-22 16:41 ---
IIUC comment #8, this bug depends on bug 29336.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from steven at gcc dot gnu dot org 2009-06-22 16:14 ---
Note that we usually add the name of the committer to the ChangeLog too, like
so:
2009-06-22 Steven Bosscher <...>
Matthias Klose <...>
etc.
But thanks for handling the patch. Fi
201 - 300 of 3051 matches
Mail list logo
