On 6/7/07, Bernardo Innocenti <[EMAIL PROTECTED]> wrote:
Harvey Harrison wrote:
> The final results of a repository holding a clone of trunk:
With or without branches? (shouldn't matter that much, just
for the record)
Just trunk.
> Size of git packs:
> pack + index - 286344kB
> git svn met
> Zdenek Dvorak <[EMAIL PROTECTED]> writes:
>
> > The problem is, that it does not give any speedups (it is almost
> > completely compile-time neutral for compilation of preprocessed
> > gcc sources). I will check whether moving also edges to pools
> > changes anything, but so far it does not see
> Hello,
>
> as discussed in http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01133.html,
> it might be a good idea to try moving cfg to alloc pools. The patch
> below does that for basic blocks (each function has a separate pool
> from that its basic blocks are allocated). At the moment, the patch
On Jun 7, 2007, at 10:33 PM, Mark Mitchell wrote:
I am aware of three remaining projects which are or might be
appropriate
for Stage 1:
I wasn't sure of the Objective-C 2.0 timing until recently... I'd
like to contribute it during stage 2.
Brooks Moses wrote (on the Fortran BIND(C) project):
I don't believe this project has been documented very well (if at all)
on the standard Wiki page for Stage-1 projects, but I haven't looked at
it in a while. I am also not entirely certain whether this qualifies as
a Stage 1 or a Stage 2 pro
Hello,
> > The problem is, that it does not give any speedups (it is almost
> > completely compile-time neutral for compilation of preprocessed
> > gcc sources). I will check whether moving also edges to pools
> > changes anything, but so far it does not seem very promising :-(
>
> Well, the ben
On Thu, 7 Jun 2007, Mark Mitchell wrote:
> I am aware of three remaining projects which are or might be appropriate
> for Stage 1:
Do we at this point believe that the people who were working on updating
the TYPE_ARG_TYPES changes (from the old LTO branch) for trunk are not now
going to have th
On Thu, Jun 07, 2007 at 08:40:14AM +1000, Ben Elliston wrote:
> On Wed, 2007-06-06 at 16:46 +0200, Gerald Pfeifer wrote:
>
> > In that case it's probably not that good of a idea to promote it (unless
> > the maintainers are in favor, of course ;-).
>
> I'm happy to leave things as they are for no
On Thu, Jun 07, 2007 at 10:33:26PM -0700, Mark Mitchell wrote:
> I am aware of three remaining projects which are or might be appropriate
> for Stage 1:
>
> In the interests of moving forwards, I therefore plan to close this
> exceptionally long Stage 1 as of next Friday, June 15th. The projects
Hello everyone,
For my bachelor thesis I'm modifying gcc to use machine learning to
predict the optimal unroll factor for different loops (inspired from
this paper: http://www.lcs.mit.edu/publications/pubs/pdf/MIT-LCS-TR-938.pdf).
I've compiled gcc 4.1.2 on my machine and I've located the
loop-u
On 6/8/07, Brooks Moses <[EMAIL PROTECTED]> wrote:
Mark Mitchell wrote:
> In the interests of moving forwards, I therefore plan to close this
> exceptionally long Stage 1 as of next Friday, June 15th. The projects
> named above may be merged, even though we will be in Stage 2 -- but no
> other f
Hello everyone,
For my bachelor thesis I'm modifying gcc to use machine learning to
predict the optimal unroll factor for different loops (inspired from
this paper: http://www.lcs.mit.edu/publications/pubs/pdf/MIT-LCS-TR-938.pdf).
I've compiled gcc 4.1.2 on my machine and I've located the
loop-u
H.J.,
Yes, that is possible
Marius
-Original Message-
From: H. J. Lu [mailto:[EMAIL PROTECTED]
Sent: Friday, June 08, 2007 6:07 AM
To: Mark Mitchell
Cc: GCC; Kenneth Zadeck; Andrew Pinski; Cornea, Marius
Subject: Re: GCC 4.3.0 Status Report (2007-06-07)
On Thu, Jun 07, 2007 at 10:33:26P
All,
I have booked a 2 bedroom suite at Les Suites for 07/17 checkin and
07/21 checkout. If someone would like to take the second bedroom (or
the living room & daybed) we can split costs.
-All 4 nights please
-Everyone's name will be added to the reservation to avoid checkin
problems.
If you're
I recall there were supposed to be some unresolved
issues with creating shared libraries for ada on darwin
in the past. Have those been resolved or will they be
addressed for the gcc 4.3.0 release? I ask because I
am considering adding ada to the set of languages built
for a future fink gcc43 pa
> "Richard" == Richard Kenner <[EMAIL PROTECTED]> writes:
Richard> The simplest example of that is an uninitialized variable.
Richard> I think the best approach is to use flags set by the front
Richard> end to indicate which of these is to be the case. For C, I
Richard> believe (1) is always
> With Java the middle end should never see an uninitialized variable.
> Uninitialized variables are precluded by the language definition, or
> the bytecode verifier.
Then if there's no other way in the language to create an undefined value,
Java should certainly use the "undefined" choice, like C
On 08 Jun 2007, at 16:31, Stefan Ciobaca wrote:
Hello everyone,
For my bachelor thesis I'm modifying gcc to use machine learning to
predict the optimal unroll factor for different loops (inspired from
this paper: http://www.lcs.mit.edu/publications/pubs/pdf/MIT-LCS-
TR-938.pdf).
Interesting
The comment for note_stores() (in rtlanal.c) says:
/* Call FUN on each register or MEM that is stored into or clobbered by X.
(X would be the pattern of an insn).
But this doesn't happen when a register is modified by e.g. a PRE_DEC
expression. Is this an oversight or intentional? If int
Mike Stump wrote:
> On Jun 7, 2007, at 10:33 PM, Mark Mitchell wrote:
>> I am aware of three remaining projects which are or might be appropriate
>> for Stage 1:
>
> I wasn't sure of the Objective-C 2.0 timing until recently... I'd like
> to contribute it during stage 2.
That's OK with me, but w
On Jun 8, 2007, at 12:50 PM, Mark Mitchell wrote:
That's OK with me, but with two caveats:
We are in the final stages of releasing this, so most development and
testing has been done as well as ensuring that C and C++ are
unaffected. This should help us meet the safeness goals. Thanks for
I'm working with a target that has a call instruction
similar to SPARC: the address of the calling instruction
is saved in a link register (lr). The actual return address
is, like SPARC, lr+8.
It seemed to me that the right thing would be to have the
initial value of the "return address" column
Rask Ingemann Lambertsen <[EMAIL PROTECTED]> writes:
>The comment for note_stores() (in rtlanal.c) says:
>
> /* Call FUN on each register or MEM that is stored into or clobbered by X.
>(X would be the pattern of an insn).
>
>But this doesn't happen when a register is modified by e.g.
Joseph S. Myers wrote:
> On Thu, 7 Jun 2007, Mark Mitchell wrote:
>
>> I am aware of three remaining projects which are or might be appropriate
>> for Stage 1:
>
> Do we at this point believe that the people who were working on updating
> the TYPE_ARG_TYPES changes (from the old LTO branch) for
Brooks Moses wrote:
> Several members of the GFortran team (primarily Chris Rickett and Steve
> Kargl) have been working on a project to add the BIND(C) functionality
> from the Fortran 2003 standard. This provides for a standard means of
> linking Fortran code with code that uses standard C link
Mark Mitchell wrote:
> > I attached a diff file for 14 files of the new structures
> > and documents. You and other maintainers are welcome to
> > check it. Thanks a lot!
>
> Thank you for posting this.
>
> Things about which I am clueless:
>
> What is the difference between a _Fract type a
Mark Mitchell wrote:
Brooks Moses wrote:
Several members of the GFortran team (primarily Chris Rickett and Steve
Kargl) have been working on a project to add the BIND(C) functionality
from the Fortran 2003 standard. This provides for a standard means of
linking Fortran code with code that uses
c4xfp/combined/gcc/testsuite/gcc.dg/fixed-point/fixed-point.exp
...
=== gcc Summary ===
# of expected passes997
/home/fu/dev/gcc4xfp/build64/gcc/xgcc version 4.3.0 20070608 (experimental)
make[1]: Leaving directory `/home/fu/dev/gcc4xfp/build64/gcc'
Running
/h
Snapshot gcc-4.3-20070608 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20070608/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
Andrew,
I tested mipsel-linux and mips64-elf on the pointer_plus branch for c,
and c++.
For r125291 mips64-elf the only regressions are those that would be
expected (I think):
-PASS: gcc.dg/matrix/matrix-1.c scan-ipa-dump-times Flattened 3 dimensions 1
+FAIL: gcc.dg/matrix/matrix-1.c scan-i
Hello,
> The number of floating point ops. in loop body.
> The number of memory ops. in loop body.
> The number of operands in loop body.
> The number of implicit instructions in loop body.
> The number of unique predicates in loop body.
> The number of indirect references in loop body.
> The numb
On 6/7/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
* PTR_PLUS branch.
I believe that this branch should be included in GCC 4.3. Andrew,
would you please update me as to its status?
Yes, the summary is the branch has two autovector regressions in the
testsuite, not directly related to the I
Fu, Chao-Ying wrote:
> Right now, the fixed-point support is a configure-time option.
> Each target can decide to support it or not. I think there is no
> harm to enable for every target. But, each target needs to modify
> tm.h tm.c tm-modes.def to set or change some target macros.
I would
Joe Buck wrote:
> On Wed, Jun 06, 2007 at 11:13:16AM -0700, Lothar Werzinger wrote:
>> when I build a coverage build of my software I get some undefined symbols
>> like global constructors keyed to src_utility_Tree.cpp_90B986A5_564B8955
>>
>> I did some investigation and as you can see in the bel
Lothar Werzinger wrote:
Joe Buck wrote:
Sounds like it. I suggest that you file a bug report, with a complete
testcase, so that it can be fixed.
AFAIK the proposed way to file a bug is to preprocess the file that fails
and to attach the preprocessed file to the bug.
That's the usual way in
35 matches
Mail list logo
