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
===
---
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
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.
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
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
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
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)
+++
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
> 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
Compiling with --disable-bootstrap and using the resulting compiler to
bootstrap gcc solved the problem.
Rafael
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
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
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 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
-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
"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
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
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
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
"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.
>
>
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
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
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
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 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
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 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, 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 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 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
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 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
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 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
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 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/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
38 matches
Mail list logo
