On Sun, 2 Dec 2007, Andreas Schwab wrote:
| 2007-11-30 Jan Hubicka <[EMAIL PROTECTED]>
|
| * ggc-common.c (dump_ggc_loc_statistics): Reset ggc_force_collect
| flag.
How could a newcomer guess why the gcc_force_collect flag needs to be
reset?
That is supposed to be written in
> If you have a better justification, i'd love to hear it.
Justification for what? I only tried to explain to Sam why we do things the
way we do, I didn't write the GNU Coding Standards either.
--
Eric Botcazou
> In the Ada revision histories, we have always given the what-and-the-why
> (and if necessary the why-not), and they have proved very helpful, I
> always found the RH's for gigi (done in the gcc style, much less helpful
> because they omitted the why).
Sorry, that's simply not true, the ChangeLog
On 12/2/07, Richard Kenner <[EMAIL PROTECTED]> wrote:
> > If all the changelog entry says is something like
> >
> > (xyz): new function
> >
> > I don't see much point, since a diff can always easily tell
> > you *what* was changed.
>
> The point is that, by just looking at the ChangeLog, you can te
> If all the changelog entry says is something like
>
> (xyz): new function
>
> I don't see much point, since a diff can always easily tell
> you *what* was changed.
The point is that, by just looking at the ChangeLog, you can tell when
xyz was introduced and by whom. I've used that quite a num
> Having said that, I find the lack of rationale for some changes to be a
> bit irritating. I know that this should be done through code comments,
> but those are often made across the changeset and in different files.
And it's often not appropriate to put the reason (or even nature) of the
chang
> > I'd go even further, and say if the GNU coding standards say we
> > shouldn't be putting descriptions of why we are changing things in the
> > ChangeLog, than they should be changed and should be ignored on this
> > point until they do. Pointing to them as the if they are The One True
> > Way
> On Sun, 2007-12-02 at 09:26 -0500, Robert Kiesling wrote:
> > > I guess nobody really loves writing ChangeLog entries, but in my opinion
> > > there
> > > are quite effective "executive summaries" for the patches and helpful to
> > > the
> > > reader/reviewer. Please let's not throw the bab
Robert Dewar <[EMAIL PROTECTED]> writes:
> I don't see much point, since a diff can always easily tell
> you *what* was changed.
A changelog does help recreate a change *set* though, since CVS is
lacking such a thing. Thus, the CL helps you determine what files to
diff.
True that SVN solves par
On 12/2/07, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> > Right, because surely one size fits all projects and possibilities,
>
> It was supposed to be the Coding Standards for The GNU Project.
Sorry, but again, this is not a good enough justification to me.
We do a lot of things different than "Th
Samuel Tardieu wrote:
For this pattern (isolated setting of one bit in the middle of a byte at
a random memory location), this is the best code on this platform AFAIK.
As an evidence, if you mark neither variable as volatile GCC generates
with -O3 -fomit-frame-pointer:
f:
orb $16,
On Mon, Dec 03, 2007 at 10:02:13AM +1100, Ben Elliston wrote:
> Having said that, I find the lack of rationale for some changes to be a
> bit irritating. I know that this should be done through code comments,
> but those are often made across the changeset and in different files.
> There is rarely
Eric Botcazou wrote:
I'd go even further, and say if the GNU coding standards say we
shouldn't be putting descriptions of why we are changing things in the
ChangeLog, than they should be changed and should be ignored on this
point until they do. Pointing to them as the if they are The One True
W
On Sun, 2 Dec 2007, Daniel Berlin wrote:
> I have never, in 7 years of working on and debugging gcc, found the
> ChangeLog to be useful in debugging a problem.
I find they are useful for finding what has changed in function X (or in
functions matching pattern Y) since 4.1, say (given a bug in 4.
Eric Botcazou wrote:
FWIW, I agree completely - I've never found ChangeLogs useful, I hate
writing them, and I think the linux-kernel guys these days generally have
much better checkin messages than we do.
I guess nobody really loves writing ChangeLog entries, but in my opinion there
are quit
Hans-Peter Nilsson wrote:
The comment *in the code* is lacking, other than that I don't
see much point in your rant; it's all been said before, for one.
It usually takes a while for newcomers to understand the
process, in particular the what-not-why of ChangeLogs... ;)
I actually think that of
> But the problem with ordering based on contributions is that people
> will then fight over whether company A or company B has contributed
> more; also, people who do their homework will know about, say,
> CodeSourcery's role in GCC even if we sort the list by alphabetical
> order. I'd rather avo
> This *is* the information I would expect to be present somewhere in
> GCC history. A clear and detailed information on why the change was
> necessary. Sure, in some case the checkin references a PR, but the PR
> often contains information of what didn't work before the change and
> the same infor
> Right, because surely one size fits all projects and possibilities,
It was supposed to be the Coding Standards for The GNU Project.
> and workflow and processes have certainly not changed since then.
In my opinion, it's now easier to work around their perceived deficiencies.
--
Eric Botcazo
Rask Ingemann Lambertsen wrote:
>So, here is the patch to implement the config.cache file trick: Create a
> config.cache file with all the right link test answers for newlib just
> before running configure, in both Makefile.tpl and config-ml.in. This allows
> sparc-unknown-elf to build libstdc
Richard Sandiford wrote:
> Anyway, given that there have been objections to the patch generally,
> I realise that the pre-approval is void.
I think there's no controversy over the libstdc++ change, so let's put
that in. If nothing else, it makes the libstdc++ configury more
self-consistent; if w
On Sun, 2007-12-02 at 21:36 +0100, Eric Botcazou wrote:
> > I'd go even further, and say if the GNU coding standards say we
> > shouldn't be putting descriptions of why we are changing things in the
> > ChangeLog, than they should be changed and should be ignored on this
> > point until they do. P
On Sun, 2007-12-02 at 09:26 -0500, Robert Kiesling wrote:
> > I guess nobody really loves writing ChangeLog entries, but in my opinion
> > there
> > are quite effective "executive summaries" for the patches and helpful to
> > the
> > reader/reviewer. Please let's not throw the baby with the b
On 12/2/07, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> > I'd go even further, and say if the GNU coding standards say we
> > shouldn't be putting descriptions of why we are changing things in the
> > ChangeLog, than they should be changed and should be ignored on this
> > point until they do. Poin
> I'd go even further, and say if the GNU coding standards say we
> shouldn't be putting descriptions of why we are changing things in the
> ChangeLog, than they should be changed and should be ignored on this
> point until they do. Pointing to them as the if they are The One True
> Way seems very
On 12/2/07, Bernd Schmidt <[EMAIL PROTECTED]> wrote:
> Richard Kenner wrote:
> >>> How could a newcomer guess why the gcc_force_collect flag needs to be
> >>> reset?
> >> That is supposed to be written in a comment. The change log entry
> >> should describe _what_ is being changed, so that you can
On 12/2/07, Richard Kenner <[EMAIL PROTECTED]> wrote:
> > > How could a newcomer guess why the gcc_force_collect flag needs to be
> > > reset?
> >
> > That is supposed to be written in a comment. The change log entry
> > should describe _what_ is being changed, so that you can find out when a
> >
Samuel Tardieu <[EMAIL PROTECTED]> writes:
> recent ChangeLog entry in gcc/ChangeLog is:
>From my understanding the gcc changelogs serve two purposes these days:
- Force the submitter to read (or rather speed read) the patch again
before sending it out.
- Serve as a "hash key" to search the g
[ Charset ISO-8859-1 unsupported, converting... ]
> > FWIW, I agree completely - I've never found ChangeLogs useful, I hate
> > writing them, and I think the linux-kernel guys these days generally have
> > much better checkin messages than we do.
>
> I guess nobody really loves writing ChangeLog
> FWIW, I agree completely - I've never found ChangeLogs useful, I hate
> writing them, and I think the linux-kernel guys these days generally have
> much better checkin messages than we do.
I guess nobody really loves writing ChangeLog entries, but in my opinion there
are quite effective "execu
Richard Kenner wrote:
>>> How could a newcomer guess why the gcc_force_collect flag needs to be
>>> reset?
>> That is supposed to be written in a comment. The change log entry
>> should describe _what_ is being changed, so that you can find out when a
>> particular change was made.
>
> Not quite.
> > How could a newcomer guess why the gcc_force_collect flag needs to be
> > reset?
>
> That is supposed to be written in a comment. The change log entry
> should describe _what_ is being changed, so that you can find out when a
> particular change was made.
Not quite. The comments are suppose
> Sure, but as you explained yourself in the message I cited, the reason
> to do this change was because of a problem in STABS info generation :)
"reason" is not quite appropriate in this case, "occasion" is more accurate.
--
Eric Botcazou
On Sun, 2 Dec 2007, Samuel Tardieu wrote:
> On 2/12, Andreas Schwab wrote:
>
> | That is supposed to be written in a comment. The change log entry
> | should describe _what_ is being changed, so that you can find out when a
> | particular change was made.
>
> This should be the job of the VCS, e.
> "Eric" == Eric Botcazou <[EMAIL PROTECTED]> writes:
>> Without digging in the mailing-list archives to see why you made
>> the change, if something new breaks on a STABS platform I will have
>> no hint that this change was in any way related to STABS.
Eric> But this change has nothing to do
Sam> How could a newcomer guess why the gcc_force_collect flag needs to
Sam> be reset?
Andreas> That is supposed to be written in a comment. The change log
Andreas> entry should describe _what_ is being changed, so that you
Andreas> can find out when a particular change was made.
Out of curiosit
> I'll take an example from one of your recent changes in gcc/ChangeLog:
>
>2007-11-19 Eric Botcazou <[EMAIL PROTECTED]>
>
>* stor-layout.c (lang_adjust_rli): Delete.
>(set_lang_adjust_rli): Likewise.
>(layout_type): Do not call lang_adjust_rli hook.
>
On 2/12, Eric Botcazou wrote:
| > I know this document and I think the part on ChangeLog doesn't achieve
| > its purpose:
| >
| > http://www.gnu.org/prep/standards/standards.html#Change-Logs
| >
| >Keep a change log to describe all the changes made to program source
| >files. The purpose
On 2/12, Andreas Schwab wrote:
| That is supposed to be written in a comment. The change log entry
| should describe _what_ is being changed, so that you can find out when a
| particular change was made.
This should be the job of the VCS, e.g. "svn log" and "svn blame".
Moreover, ChangeLogs are
> I know this document and I think the part on ChangeLog doesn't achieve
> its purpose:
>
> http://www.gnu.org/prep/standards/standards.html#Change-Logs
>
>Keep a change log to describe all the changes made to program source
>files. The purpose of this is so that people investigating bugs i
On 2/12, Eric Botcazou wrote:
| He indeed cannot, but the ChangeLog is not meant to make it possible either.
| See http://gcc.gnu.org/contribute.html, especially the GNU Coding Standards.
I know this document and I think the part on ChangeLog doesn't achieve
its purpose:
http://www.gnu.org/prep
> I tend to find GCC ChangeLog entries useless. For example, the more
>
> recent ChangeLog entry in gcc/ChangeLog is:
> | 2007-11-30 Jan Hubicka <[EMAIL PROTECTED]>
> |
> | * ggc-common.c (dump_ggc_loc_statistics): Reset ggc_force_collect
> | flag.
>
> How could a newcomer guess w
Samuel Tardieu <[EMAIL PROTECTED]> writes:
> As a recent committer to GCC, I am always surprised to see the content
> of ChangeLog entries and commit messages.
>
> I tend to find GCC ChangeLog entries useless. For example, the more
> recent ChangeLog entry in gcc/ChangeLog is:
>
> | 2007-11-30 Ja
As a recent committer to GCC, I am always surprised to see the content
of ChangeLog entries and commit messages.
I tend to find GCC ChangeLog entries useless. For example, the more
recent ChangeLog entry in gcc/ChangeLog is:
| 2007-11-30 Jan Hubicka <[EMAIL PROTECTED]>
|
| * ggc-common
Hello,
SMS currently works only on single-basic-block loops. This simplifies
the task of software pipelining. PR34263 is an example where outof-ssa
creates a non-empty latch block for a single-basic-block loop and thus
prevents SMS to be applied on it. This issue was raised in the past
(http://
On 1/12, Robert Dewar wrote:
>> I cannot see a reason not to use "orb $32,y" here instead of a three
>> steps read/modify/write operation. Is this only a missed optimization?
>> (in which case I will open a PR)
>
> Are you sure it is an optimization, the timing on these things is
> very subtle. W
46 matches
Mail list logo
