Nicholas Nethercote <[EMAIL PROTECTED]> writes:
> 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_
Nicholas Nethercote <[EMAIL PROTECTED]> writes:
> Commit logs are basically invisible;
That's just a (fixable) problem in your coding setup. In other
projects it is very common to use tools like cvs annotate / cvsps /
git blame / git log / etc. to find the reasons for why code is the way
it is. I
Oliver.
Have you got a chance to take a look at the materials?
If yes, what do you think on it?
Yours sincerely,
George.
[EMAIL PROTECTED] ?:
Thank you for your reply, Oliver.
Briefly speaking the solution to the problems you have mentioned looks
like this:
1. take a loot at the first pi
> Sorry, but again, this is not a good enough justification to me.
> We do a lot of things different than "The GNU Project".
> So do plenty of parts of the "official GNU project".
> They use different coding standards, bug tracking systems, version
> control systems, checkin policies, etc, than eac
> OK, sounds reasonable, but then I don't understand the logic behind
> avoiding this instruction sequence for the volatile case, this is
> two accesses at the bus level so what's the difference?
There's no difference from that perspective. The logic behind what's
generated is that instead of tr
>From the last GCC Summit we learned about (Fortran) Frontend Based
Optimizations from Toon and it was suggested to tackle one issue by
promoting arrays to a first-class middle-end type. Discussion with
Sebastian also reveals that this makes sense to ease the analysis
of the into-GRAPHITE transfo
Richard Kenner wrote:
OK, sounds reasonable, but then I don't understand the logic behind
avoiding this instruction sequence for the volatile case, this is
two accesses at the bus level so what's the difference?
There's no difference from that perspective. The logic behind what's
generated is
On Mon, Dec 03, 2007 at 04:16:17PM +0300, [EMAIL PROTECTED] wrote:
> Have you got a chance to take a look at the materials?
> If yes, what do you think on it?
Nope, sorry, too busy with other things.
OG.
Eric Botcazou wrote:
On the SPARC, this produced an executable I couldn't run
on the simulator. It looked like the .text segment may
have increased enough to not fit in the simulator.
Weird. The EH tables should probably not end up in .text.
RTEMS applications are statically linked
> There are in fact, already programs that will generate GNU format
> changelogs from svn log (see http://ch.tudelft.nl/~arthur/svn2cl/)
> It would be very easy to run these as part of the release process.
Sure, but I think that's bad for this project since I support the idea
that the svn log shou
On 12/3/07, Richard Kenner <[EMAIL PROTECTED]> wrote:
> > Sorry, but again, this is not a good enough justification to me.
> > We do a lot of things different than "The GNU Project".
> > So do plenty of parts of the "official GNU project".
> > They use different coding standards, bug tracking syste
> Right, but it would seem this is a good canididate for combination. This
> is especially true since often Volatile is used with the sense of Atomic
> in Ada, and it is not a bad idea to combine these in practice, giving an
> atomic update (right, nothing in the language requires it, but it is
> d
Mark Mitchell <[EMAIL PROTECTED]> writes:
> 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
[EMAIL PROTECTED] (Richard Kenner) writes:
>
> Yes, but none of those are visible other than to the development community.
> People who obtain the source distributions of projects don't get to see
> those things. They DO see things like the ChangeLog format and coding
> and documentation conventio
> Except they aren't, across large parts of the GNU project.
>
> You may find it the same in the "traditional" parts of the GNU project
> (IE coreutils, emacs, etc).
> It's certainly not the same across any of the newer parts of the GNU project.
Perhaps, but GCC has always been considered, like e
[ Charset ISO-8859-1 unsupported, converting... ]
> On 12/3/07, Richard Kenner <[EMAIL PROTECTED]> wrote:
> > > Sorry, but again, this is not a good enough justification to me.
> > > We do a lot of things different than "The GNU Project".
> > > So do plenty of parts of the "official GNU project".
>
> It would be probably reasonable these days to require of someone who
> wants to do serious development to just download a SVN checkout
> for that [or they can use svnweb on http://gcc.gnu.org]
I agree. But I think the idea of the ChangeLog is for somewhere just short
of "serious development".
On 12/02/07 05:05, Samuel Tardieu wrote:
Maybe we should consider dropping ChangeLogs and using better checkin
messages.
I'm not sure people will want to drop ChangeLogs anytime soon. I don't
find them all that useful, but I *have* used them extensively when doing
archeology. It gives you
> > t1 = y | 2;
> > y = t1;
> >
> > are very hard to tell apart at the RTL level. Though it's clear that
> > a single instruction might best match the expect semantics of the former,
> > it's a lot less clear that it would for the latter.
>
> I think it would still be OK for the latter,
Robert Kiesling wrote:
That's because, although the GNU project strictly - and correctly,
experience has shown - monitors its code base, with the propagation
of the Free Software development model, newer Free Software
contributors who maintain their code on sites like sourceforge.net,
are sub
Richard Kenner wrote:
Right, but it would seem this is a good canididate for combination. This
is especially true since often Volatile is used with the sense of Atomic
in Ada, and it is not a bad idea to combine these in practice, giving an
atomic update (right, nothing in the language requires i
> I'm not sure people will want to drop ChangeLogs anytime soon. I don't
> find them all that useful, but I *have* used them extensively when doing
> archeology. It gives you the initial thread to pull when finding out
> about changes.
>
> What I *do* miss a lot is a an easier way to link fro
I would like to reinterpret (not convert/cast) a 32-bit integer to a
32-bit float in GIMPLE. Is using a NOP_EXPR with the wanted type the
correct way of doing this?
The reinterpretation of a value is needed to optimize reads and writes
to unions. I modified the value numbering pass which worked f
On Mon, Dec 03, 2007 at 04:07:35PM +, Richard Sandiford wrote:
> And I haven't yet looked at why the tests are failing. I was just noting
> that they did. It looks from PR21185 that Rask was seeing the same thing
> on mipsisa64-elf, and TBH, I was so unsurprised that they were failing that
>
Diego Novillo wrote:
> The history is something one finds on the mailing lists. So, my
> proposal is to add a commit-time check that makes sure that the commit
> message contains a URL to the message describing the change. IIUC, such
> check shouldn't be hard to implement (Dan?)
I'd much prefer
On 12/3/07, Sjodin, Jan <[EMAIL PROTECTED]> wrote:
> I would like to reinterpret (not convert/cast) a 32-bit integer to a
> 32-bit float in GIMPLE. Is using a NOP_EXPR with the wanted type the
> correct way of doing this?
You want to use the tree code called VIEW_CONVERT_EXPR.
Thanks,
Andrew Pins
Bernd Schmidt <[EMAIL PROTECTED]> writes:
> Diego Novillo wrote:
> > The history is something one finds on the mailing lists. So, my
> > proposal is to add a commit-time check that makes sure that the commit
> > message contains a URL to the message describing the change. IIUC, such
> > check sh
Bernd Schmidt wrote:
I'd much prefer the text from the mail message be repeated in the commit
log. Removes one step of indirection both when writing and reading the log.
I guess that could work, but that wouldn't give a way into the history
for the change. Several times there is a post-mort
> I'd much prefer the text from the mail message be repeated in the commit
> log. Removes one step of indirection both when writing and reading the log.
I would as well. Especially if you're trying to scan a large part of
the log looking for something.
On 12/03/07 13:50, Richard Kenner wrote:
I guess that could work, but that wouldn't give a way into the history
for the change. Several times there is a post-mortem discussion on the
patch, leading to more patches.
How about both?
Sure.
Diego.
> I guess that could work, but that wouldn't give a way into the history
> for the change. Several times there is a post-mortem discussion on the
> patch, leading to more patches.
How about both?
On Mon, 2007-12-03 at 13:58 -0500, Diego Novillo wrote:
> On 12/03/07 13:50, Richard Kenner wrote:
> >> I guess that could work, but that wouldn't give a way into the history
> >> for the change. Several times there is a post-mortem discussion on the
> >> patch, leading to more patches.
> >
> >
Richard Kenner wrote:
t1 = y | 2;
y = t1;
are very hard to tell apart at the RTL level. Though it's clear that
a single instruction might best match the expect semantics of the former,
it's a lot less clear that it would for the latter.
I think it would still be OK for the latt
Hello!
What is the reason for GCC (trunk version) installing the
header file as `PREFIX/lib/gcc/*/*/include-fixed/limits.h' instead of
putting it into `PREFIX/lib/gcc/*/*/include/', which is what
gcc-4_2-branch and earlier have been doing?
The leads to a problem as follows. You're about to boot
Snapshot gcc-4.1-20071203 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20071203/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Thomas Schwinge <[EMAIL PROTECTED]> writes:
> Is this a GCC issue or should the glibc build system be adding a
> ``-isystem [GCC target]/4.3.0/include-fixed''?
The latter.
http://sourceware.org/ml/libc-alpha/2007-03/msg00017.html
Ian
Hello!
On Mon, Dec 03, 2007 at 03:18:42PM -0800, Ian Lance Taylor wrote:
> Thomas Schwinge <[EMAIL PROTECTED]> writes:
> > Is this a GCC issue or should the glibc build system be adding a
> > ``-isystem [GCC target]/4.3.0/include-fixed''?
>
> The latter.
>
> http://sourceware.org/ml/libc-alpha/2
Thomas Schwinge <[EMAIL PROTECTED]> writes:
> Hello!
>
> On Mon, Dec 03, 2007 at 03:18:42PM -0800, Ian Lance Taylor wrote:
> > Thomas Schwinge <[EMAIL PROTECTED]> writes:
> > > Is this a GCC issue or should the glibc build system be adding a
> > > ``-isystem [GCC target]/4.3.0/include-fixed''?
>
Hello!
On Mon, Dec 03, 2007 at 05:05:10PM -0800, Ian Lance Taylor wrote:
> Thomas Schwinge <[EMAIL PROTECTED]> writes:
> > On Mon, Dec 03, 2007 at 03:18:42PM -0800, Ian Lance Taylor wrote:
> > > Thomas Schwinge <[EMAIL PROTECTED]> writes:
> > > > Is this a GCC issue or should the glibc build syste
Hello!
Execuse me but I have something bothering me.
I inserted a method into rest_of_compilation() (before calling
rest_of_handle_life()) to insert some new insn before insn were
translated to asm. But after my modification, when processing some
insn moving one pseudo reg to another ps
On Mon, 3 Dec 2007, Andi Kleen wrote:
Commit logs are basically invisible;
That's just a (fixable) problem in your coding setup. In other
projects it is very common to use tools like cvs annotate / cvsps /
git blame / git log / etc. to find the reasons for why code is the way
it is. In fact in
41 matches
Mail list logo
