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
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://
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
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
> 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
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 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, 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
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
> 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.
>
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
> "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
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.
> 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
> > 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
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.
> 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
[ 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
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
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
> >
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, 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 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
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
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
> 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
> 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
> 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
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
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
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:
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 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
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 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
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 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
> > 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
> 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
> 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
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
> 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
> 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
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
46 matches
Mail list logo
