On 11/15/06, Sashan Govender <[EMAIL PROTECTED]> wrote:
On 11/15/06, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> On 11/14/06, Sashan Govender <[EMAIL PROTECTED]> wrote:
> > Hi
> >
> > I was looking at the vectorizer
> > (http://gcc.gnu.org/projects/tree-ssa/vectorization.html) and noticed
> > that
On 11/15/06, Daniel Berlin <[EMAIL PROTECTED]> wrote:
On 11/14/06, Sashan Govender <[EMAIL PROTECTED]> wrote:
> Hi
>
> I was looking at the vectorizer
> (http://gcc.gnu.org/projects/tree-ssa/vectorization.html) and noticed
> that in section 6 it says that there is no data dependence graph
> imple
On 11/14/06, Sashan Govender <[EMAIL PROTECTED]> wrote:
Hi
I was looking at the vectorizer
(http://gcc.gnu.org/projects/tree-ssa/vectorization.html) and noticed
that in section 6 it says that there is no data dependence graph
implemented. Also had a search throught the mailing list archives and
On 14 November 2006 19:40, Joe Buck wrote:
> On Tue, Nov 14, 2006 at 07:15:19PM -, Dave Korn wrote:
>> Geert's followup explained this seeming anomaly: he means that the crude
>> high-level granularity of "make -j" is enough to keep all cpus busy at
>> 100%, and I'm fairly persuaded by the a
Hi
I was looking at the vectorizer
(http://gcc.gnu.org/projects/tree-ssa/vectorization.html) and noticed
that in section 6 it says that there is no data dependence graph
implemented. Also had a search throught the mailing list archives and
noticed that although ddg.c exists its not used much?
(ht
On Tue, Nov 14, 2006 at 12:03:39PM -0800, H. J. Lu wrote:
> On Tue, Nov 14, 2006 at 11:56:01AM -0800, Brooks Moses wrote:
> > H. J. Lu wrote:
> > >On Tue, Nov 14, 2006 at 09:17:49AM -0800, H. J. Lu wrote:
> > >>On Tue, Nov 14, 2006 at 09:43:20AM -0500, David Edelsohn wrote:
> > >>> No failure shoul
While trying to clean, I noticed that
$ make -k -j6 clean
does:
make[5]: *** [insn-recog.o] Interrupt
make[5]: *** [s-attrtab] Interrupt
make[4]: *** [all-stage1-gcc] Interrupt
make[3]: *** [stage1-bubble] Interrupt
Reaping losing child 0x00383f20 PID 18728
make[2]: *** [all] Interrupt
Removi
On Nov 12, 2006, at 3:21 PM, Jack Howarth wrote:
Can anyone confirm that the libffi shared libraries are properly
built in gcc 4.2 branch (or trunk)
No, they aren't built:
The following languages will be built: c,c++,java
*** This configuration is not supported in the following subdirectories
On Tue, Nov 14, 2006 at 08:05:59PM +, Joseph S. Myers wrote:
> On Tue, 14 Nov 2006, Eric Christopher wrote:
>
> > Done, sorry about that.
>
> Thanks. Hopefully we can get a planned transition done (for gcc and src)
> before 4.3. (I suspect the first step will be the move of toplevel to
>
On Tue, Nov 14, 2006 at 11:56:01AM -0800, Brooks Moses wrote:
> H. J. Lu wrote:
> >On Tue, Nov 14, 2006 at 09:17:49AM -0800, H. J. Lu wrote:
> >>On Tue, Nov 14, 2006 at 09:43:20AM -0500, David Edelsohn wrote:
> >>> No failure should be expected. It is a bug and a regression and
> >>>should be fi
On 14/11/2006, at 3:13 AM, Dominique Dhumieres wrote:
In http://gcc.gnu.org/ml/gcc-help/2006-11/msg00058.html I reported the
following:
Building snapshot gcc4-4.3.0-20061104 on OSX 10.3.9 with
odcctools 590-20060413 using a modified Fink script (working
with the previous snapshot) failed with
On Tue, 14 Nov 2006, Eric Christopher wrote:
> Done, sorry about that.
Thanks. Hopefully we can get a planned transition done (for gcc and src)
before 4.3. (I suspect the first step will be the move of toplevel to
2.59; I'm not sure what's holding that up now all subdirectories of gcc
and sr
On Nov 14, 2006, at 11:32 AM, Eric Christopher wrote:
You appear to have regenerated configure, on both mainline and 4.2
branch,
with autoconf 2.60. Could you please regenerate it with 2.59 in both
places?
Sure, I'll have to dig it up somewhere. It appears to be the default
on FC6, I'l
H. J. Lu wrote:
On Tue, Nov 14, 2006 at 09:17:49AM -0800, H. J. Lu wrote:
On Tue, Nov 14, 2006 at 09:43:20AM -0500, David Edelsohn wrote:
No failure should be expected. It is a bug and a regression and
should be fixed, with help of users who have access to SPEC CPU2000.
It was a pilo
On Tue, Nov 14, 2006 at 09:17:49AM -0800, H. J. Lu wrote:
> On Tue, Nov 14, 2006 at 09:43:20AM -0500, David Edelsohn wrote:
> > > Steve Kargl writes:
> >
> > Steve> I have not seen this failure, but that may be expected
> > Steve> since SPEC CPU 2000 isn't freely available.
> >
> > No fai
On Tue, Nov 14, 2006 at 07:15:19PM -, Dave Korn wrote:
> Geert's followup explained this seeming anomaly: he means that the crude
> high-level granularity of "make -j" is enough to keep all cpus busy at 100%,
> and I'm fairly persuaded by the arguments that, at the moment, that's
> sufficient
You appear to have regenerated configure, on both mainline and 4.2
branch,
with autoconf 2.60. Could you please regenerate it with 2.59 in both
places?
Sure, I'll have to dig it up somewhere. It appears to be the default
on FC6, I'll use that.
-eric
"Dave Korn" <[EMAIL PROTECTED]> writes:
> > It's irrelevant to the main discussion here, but in fact there is a
> > fair amount of possible threading in the linker proper, quite apart
> > from LTO. The linker spends a lot of time reading large files, and
> > the I/O wait can be parallelized.
>
>
On 14 November 2006 15:38, Robert Dewar wrote:
> Geert Bosch wrote:
>
>> Given that CPU usage is at 100% now for most jobs, such as
>> bootstrapping GCC, there is not much room for any improvement
>> through threading.
>
> Geert, I find this a bit incomprehensible, the whole point
> of threading
On 14 November 2006 18:30, Ian Lance Taylor wrote:
> "Dave Korn" <[EMAIL PROTECTED]> writes:
>
>>> The main place where threading may make sense, especially
>>> with LTO, is the linker. This is a longer lived task, and
>>> is the last step of compilation, where no other parellel
>>> processes are
David Edelsohn wrote:
Steve Kargl writes:
Steve> I have not seen this failure, but that may be expected
Steve> since SPEC CPU 2000 isn't freely available.
No failure should be expected. It is a bug and a regression and
should be fixed, with help of users who have access to SPEC CPU2000
"Dave Korn" <[EMAIL PROTECTED]> writes:
> > The main place where threading may make sense, especially
> > with LTO, is the linker. This is a longer lived task, and
> > is the last step of compilation, where no other parellel
> > processes are active. Moreover, linking tends to be I/O
> > intensive
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Howdy
i'm trying to build gcc-4.1.1 (of release status) on my x86/Linux (it
is an RH 9.0).
I have tried the following two setups:
a) gcc-3.2.2 (as RH 9.0 is shipped with), glibc-2.3.2 (the same)
b) gcc-3.4.3 (custom built), glibc as above.
It seem
On Nov 14, 2006, at 12:49, Bill Wendling wrote:
I'll mention a case where compilation was wickedly slow even
when using -j#. At The MathWorks, the system could take >45 minutes
to compile. (This was partially due to the fact that the files were
located on an NFS mounted drive. But also because C
Snapshot gcc-4.2-20061114 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20061114/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.2 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Nov 10, 2006, at 9:08 PM, Geert Bosch wrote:
Most people aren't waiting for compilation of single files.
If they do, it is because a single compilation unit requires
parsing/compilation of too many unchanging files, in which case
the primary concern is avoiding redoing useless compilation.
T
On Tue, Nov 14, 2006 at 09:43:20AM -0500, David Edelsohn wrote:
> > Steve Kargl writes:
>
> Steve> I have not seen this failure, but that may be expected
> Steve> since SPEC CPU 2000 isn't freely available.
>
> No failure should be expected. It is a bug and a regression and
> should be
Compiling with --disable-bootstrap and using the resulting compiler to
bootstrap gcc solved the problem.
Rafael
> Steve Kargl writes:
Steve> I have not seen this failure, but that may be expected
Steve> since SPEC CPU 2000 isn't freely available.
No failure should be expected. It is a bug and a regression and
should be fixed, with help of users who have access to SPEC CPU2000.
David
Thanks a lot. This is going to be a good starting point.
Ferad Zyulkyarov
On 11/13/06, Sebastian Pop <[EMAIL PROTECTED]> wrote:
On 11/13/06, Ferad Zyulkyarov <[EMAIL PROTECTED]> wrote:
> Hi,
>
> May you point me out some sources about writing new #pragma directives
> in GCC. I looked at the int
I suggest that you test the following patch and report back to us:
I got the patch wrong (it's not a real printf function we have there):
Index: libgfortran/runtime/error.c
===
--- libgfortran/runtime/error.c (revision 118806)
+++
Geert Bosch wrote:
Given that CPU usage is at 100% now for most jobs, such as
bootstrapping GCC, there is not much room for any improvement
through threading.
Geert, I find this a bit incomprehensible, the whole point
of threading is to increase CPU availability by using
multiple cores.
Even
On Thu, 9 Nov 2006, [EMAIL PROTECTED] wrote:
> Author: echristo
> Date: Thu Nov 9 23:56:57 2006
> New Revision: 118633
>
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118633
> Log:
> 2006-11-09 Eric Christopher <[EMAIL PROTECTED]>
>
> PR bootstrap/26892
> PR bootstra
Now I get:
make[1]: *** No rule to make target `clean'. Stop.
make: *** [clean-stage4-gcc] Error 2
It turns out I had a fix already approved, but never checked in. Fixed
(and my apologies).
Paolo
On Tue, Nov 14, 2006 at 09:43:20AM -0500, David Edelsohn wrote:
> > Steve Kargl writes:
>
> Steve> I have not seen this failure, but that may be expected
> Steve> since SPEC CPU 2000 isn't freely available.
>
> No failure should be expected. It is a bug and a regression and
> should be
In http://gcc.gnu.org/ml/gcc-help/2006-11/msg00058.html I reported the
following:
> Building snapshot gcc4-4.3.0-20061104 on OSX 10.3.9 with
> odcctools 590-20060413 using a modified Fink script (working
> with the previous snapshot) failed with:
> ...
Since the problem is still there in gcc4-4.
Paolo Bonzini wrote:
a) if anyone propagates a value anywhere, she should check whether the
propagated value is part of a comparison in a COND_EXPR (and
explicitly fold the comparison, if so).
b) in case of a COND_EXPR, fold_ternary (...) in fold-const.c folds
the comparison before doing anyt
And why would you think (twice) that the best place for reporting this
is neither the gfortran mailing-list, nor bugzilla?
I suggest that you test the following patch and report back to us:
Index: libgfortran/runtime/error.c
===
---
38 matches
Mail list logo
