Re: libgfortran still fails to build for sh-elf
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
===
--- libgfortran/runtime/error.c (revision 118806)
+++ libgfortran/runtime/error.c (working copy)
@@ -285,7 +285,7 @@
if (!options.locus || cmp == NULL || cmp->filename == NULL)
return;
- st_printf ("At line %d of file %s\n", cmp->line, cmp->filename);
+ st_printf ("At line %ld of file %s\n", (long int) cmp->line, cmp->filename);
}
Re: [PATCH] COND_EXPRs in GIMPLE code and vectorizer
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 anything else (currently, it doesn't do it
at all).
I'd go for the second alternative.
It needs an amendment in your statement "fold and friends don't
recurse on trees..." for the special case of the comparison of a
COND_EXPR, but it avoids explicit checks and folding every time a pass
propagates anything into a COND_EXPR.
I think this emphasizes a problem with COND_EXPRs in GIMPLE (and
VEC_COND_EXPRs too for that matter; this poor aspect of the design has
been there forever): that in this case you cannot assume anymore the RHS
of a MODIFY_EXPR to be flat (the other case in which this does not hold
is load and stores).
I'd go for the first alternative, writing a fold_gimple_cond_expr
function that folds the comparison like this:
static tree
fold_gimple_cond_expr (tree temp)
{
tree temp = fold (COND_EXPR_COND (cond_expr));
if (temp == COND_EXPR_COND (cond_expr))
return fold (cond_expr);
else
return fold_build3 (COND_EXPR, TREE_TYPE (cond_expr), temp,
COND_EXPR_THEN (cond_expr), COND_EXPR_ELSE (cond_expr));
}
which can be used in fold_stmt. Roger will surely have more to say,
however.
(Remember that fold and friends are not GIMPLE-only. They are used also
by front-ends.)
Paolo
Hello,
I produced the following patch (attached), which I believe takes into
account Roger's remark and Paolo's suggestion.
I tested it, I bootstrapped with no regressions on i686-pc-linux-gnu.
Please, tell me what do you think. I hope it is ready for approval, I'd
really like to check these bits and pieces of work about COND_EXPRs
before I forget about the all matter. :-)
Cheers,
Roberto
2006-11-14 Roberto Costa <[EMAIL PROTECTED]>
* tree-vrp.c (extract_range_from_cond_expr): New.
(extract_range_from_expr): Handle COND_EXPR nodes used as expressions.
* tree-ssa-ccp.c (get_maxval_strlen): Handle COND_EXPR nodes used
as expressions.
(fold_stmt): Bug fix, avoid infinite recursion when folding COND_EXPRs.
* tree-ssa-forwprop.c (simplify_cond, forward_propagate_into_cond,
tree_ssa_forward_propagate_single_use_vars): Handle COND_EXPR nodes
used as expressions.
* tree-object-size.c (cond_expr_object_size): New.
(collect_object_sizes_for): Handle COND_EXPR nodes used as expressions.
Index: gcc/tree-vrp.c
===
--- gcc/tree-vrp.c (revision 118652)
+++ gcc/tree-vrp.c (working copy)
@@ -43,6 +43,7 @@ static sbitmap found_in_subgraph;
/* Local functions. */
static int compare_values (tree val1, tree val2);
+static void vrp_meet (value_range_t *, value_range_t *);
/* Location information for ASSERT_EXPRs. Each instance of this
structure describes an ASSERT_EXPR for an SSA name. Since a single
@@ -1862,6 +1863,40 @@ extract_range_from_unary_expr (value_ran
}
+/* Extract range information from a conditional expression EXPR based on
+ the ranges of each of its operands and the expression code. */
+
+static void
+extract_range_from_cond_expr (value_range_t *vr, tree expr)
+{
+ tree op0, op1;
+ value_range_t vr0 = { VR_UNDEFINED, NULL_TREE, NULL_TREE, NULL };
+ value_range_t vr1 = { VR_UNDEFINED, NULL_TREE, NULL_TREE, NULL };
+
+ /* Get value ranges for each operand. For constant operands, create
+ a new value range with the operand to simplify processing. */
+ op0 = COND_EXPR_THEN (expr);
+ if (TREE_CODE (op0) == SSA_NAME)
+vr0 = *(get_value_range (op0));
+ else if (is_gimple_min_invariant (op0))
+set_value_range (&vr0, VR_RANGE, op0, op0, NULL);
+ else
+set_value_range_to_varying (&vr0);
+
+ op1 = COND_EXPR_ELSE (expr);
+ if (TREE_CODE (op1) == SSA_NAME)
+vr1 = *(get_value_range (op1));
+ else if (is_gimple_min_invariant (op1))
+set_value_range (&vr1, VR_RANGE, op1, op1, NULL);
+ else
+set_value_range_to_varying (&vr1);
+
+ /* The resulting value range is the union of the operand ranges */
+ vrp_meet (&vr0, &vr1);
+ copy_value_range (vr, &vr0);
+}
+
+
/* Extract range information from a comparison expression EXPR based
on the range of its operand and the expression code. */
@@ -1903,6 +1938,8 @@ extract_range_from_expr (value_range_t *
extract_range_from_binary_expr (vr, expr);
else if (TREE_CODE_CLASS (code) == tcc_unary)
extract_range_from_unary_expr (vr, expr);
+ else if (code == COND_EXPR)
+extract_range_from_cond_expr (vr, expr);
else if (TREE_CODE_CLASS (code) == tcc_comparison)
extract_range_from_comparison (vr, expr);
else if (is_gimple_min_invariant (expr))
Index: gcc/tree-ssa-ccp.c
building gcc4-4.3.0-20061104/11 failure on OSX 10.3
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.3.0-2006 and I did not get
any answer, I tried the following:
(1) I replaced gcc/config/darwin.h by the file from gcc4-4.3.0-20061028,
and the build was done without obvious problem.
(2) Using the gcc/config/darwin.h from gcc4-4.3.0-2006, I replaced:
#define PREFERRED_DEBUGGING_TYPE DWARF2_DEBUG
by
#define PREFERRED_DEBUGGING_TYPE DBX_DEBUG
Then the original failure:
> strip: object: .//libgcc_s.1.dylib.tmp malformed object (unknown load
> command 8)
disappeared (along with the other messages such as:
> ranlib: file: ./libgcc.a(_trampoline.o) has no symbols
> ...
> /sw/lib/odcctools/bin/nm: no name list
> ...
> /sw/lib/odcctools/bin/ld: warning libgcc/./ppc64-fp_s.o could not
> understand DWARF debug information
> /sw/lib/odcctools/bin/ld: warning libgcc/./darwin-64_s.o could not
> understand DWARF debug information
> ...
However the build failed with:
> ...
> Configuring stage 2 in ./intl
> configure: creating cache ./config.cache
> checking whether make sets $(MAKE)... yes
> checking for a BSD-compatible install... /sw/bin/ginstall -c
> checking whether NLS is requested... yes
> checking for msgfmt... /sw/bin/msgfmt
> checking for gmsgfmt... /sw/bin/msgfmt
> checking for xgettext... /sw/bin/xgettext
> checking for msgmerge... /sw/bin/msgmerge
> checking for powerpc-apple-darwin7-gcc...
> /sw/src/fink.build/gcc4-4.3.0-20061115/darwin_objdir/./prev-gcc/xgcc
> -B/sw/src/fink.build/gcc4-4.3.0-20061115/darwin_objdir/./prev-gcc/
> -B/sw/lib/gcc4/powerpc-apple-darwin7/bin/
> configure: error: C compiler cannot create executables
> See `config.log' for more details.
> make[2]: *** [configure-stage2-intl] Error 77
> make[1]: *** [stage2-bubble] Error 2
> make: *** [all] Error 2
> checking for C compiler default output file name... ### execution of
> /var/tmp/tmp.1.iDjVLN failed, exit code 2
Using
#define CPP_SPEC "%{static:%{!dynamic:-D__STATIC__}}%{!static:-D__DYNAMIC__}"
instead of
#define CPP_SPEC "%{static:%{!dynamic:-D__STATIC__}}%{!static:-D__DYNAMIC__}" \
" %{pthread:-D_REENTRANT}"
or removing
#define NO_IMPLICIT_EXTERN_C
did not help (same failure).
Any idea about what's wrong with the new gcc/config/darwin.h when used
with OSX 10.3?
TIA
Dominique d'Humieres
Re: make clean no longer works properly?
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
Re: Has anyone seen mainline Fortran regression with SPEC CPU 2000/2006?
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 fixed, with help of users who have access to SPEC CPU2000. > Read want I wrote. I did not see this failure. It may be expected that I did not see this failure because this failure appears to occur while compiling code that is unavailable. I suspect that none of the people, who actively work on gfortran, saw this failure. Go back and read HJ's original email. Other than stating a regression has occurred, his email is content free. It is difficult to fix, or even investigate, a regression when one has no means to reproduce it. -- Steve
Do not use autoconf 2.60 yet
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 bootstrap/27814 > PR other/28994 > * configure.ac: Match powerpc*-*-darwin* for powerpc darwin checks. > * config.gcc (powerpc64-*-darwin*): New target. > * config.host: Ditto. > * config/rs6000/darwin64.h: New file. > * config/rs6000/x-darwin64: Ditto. > * config/rs6000/host-ppc64-darwin.c: Ditto. 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? 2.59, exactly, is the version documented in install.texi. In order to avoid random churn with versions going back and forth and different versions in different directories with no good reason, we must have a transition plan before changing the version used (and keep install.texi up to date throughout the transition with what version is used in what directory), and we have no such plan; certainly such changes are inappropriate on release branches. The changes to directory variables and new configure options in autoconf 2.60 make such a transition plan especially important (for example, we need to work out at what point the local configure options --with-datarootdir --with-docdir --with-htmldir get removed in each directory in favour of the standard options added in 2.60). 2.60 also needs automake 1.10 (and vice versa). -- Joseph S. Myers [EMAIL PROTECTED]
Re: Threading the compiler
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 in the best case, large parts of the compilation will still be serial. In the non-optimizing case, which is so important for the compile-debug-edit cycle, almost no parallelism will be possible. Well that is a completely different issue
Re: libgfortran still fails to build for sh-elf
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)
+++ libgfortran/runtime/error.c (working copy)
@@ -285,7 +285,7 @@
if (!options.locus || cmp == NULL || cmp->filename == NULL)
return;
- st_printf ("At line %d of file %s\n", cmp->line, cmp->filename);
+ st_printf ("At line %d of file %s\n", (int) cmp->line, cmp->filename);
}
Re: Extending GCC with pragma directive
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 internet for something to start from but
> unfortunately I could not find anything.
google("site:gcc.gnu.org inurl:gcc-patches pragma")
http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01560.html
[...]
--
Ferad Zyulkyarov
Barcelona Supercomputing Center
c/ Gran Capita 2-4, Nexus I, 204
08034 Barcelona - SPAIN
e-mail: [EMAIL PROTECTED]
tel: +34 934054294
fax: +34 934137721
Re: Has anyone seen mainline Fortran regression with SPEC CPU 2000/2006?
> 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
Re: bootstrap failure on arm
Compiling with --disable-bootstrap and using the resulting compiler to bootstrap gcc solved the problem. Rafael
Re: Has anyone seen mainline Fortran regression with SPEC CPU 2000/2006?
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 fixed, with help of users who have access to SPEC CPU2000. > It was a pilot error for SPEC CPU2000 on Linux/x86-64. I am looking into SPEC CPU 2006 failure on Linux/x86. H.J.
Re: Threading the compiler
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. The common case is that people just don't use the -j feature of make because 1) they don't know about it 2) their IDE doesn't know about it 3) they got burned by bad Makefiles 4) it's just too much typing 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++ compilation is way slower than C compilation.) Experiments with distributed make showed promise. It would be interesting to see if parallelizing the compiler (instead of just using 'make -j#') will give us an overall gain. Though it also seems fruitful to pursue some of the other optimizations you mentioned. -bw
gcc-4.2-20061114 is now available
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/gcc-4_2-branch revision 118820 You'll find: gcc-4.2-20061114.tar.bz2 Complete GCC (includes all of below) gcc-core-4.2-20061114.tar.bz2 C front end and core compiler gcc-ada-4.2-20061114.tar.bz2 Ada front end and runtime gcc-fortran-4.2-20061114.tar.bz2 Fortran front end and runtime gcc-g++-4.2-20061114.tar.bz2 C++ front end and runtime gcc-java-4.2-20061114.tar.bz2 Java front end and runtime gcc-objc-4.2-20061114.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.2-20061114.tar.bz2The GCC testsuite Diffs from 4.2-20061107 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.2 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Threading the compiler
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++ compilation is way slower than C compilation.) Experiments with distributed make showed promise. When using -j#, with enough parellel processes and assuming sufficient memory, you should be able to reach the point where you're either limited by the NFS server or by CPU availability. No amount of threading in the compiler will remove either bottleneck. -Geert
Host toolchain for building latest gcc release (4.1.1)
-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 seems that i'm getting errors beginning with the following file: top-gcc-dir/libssp/ssp.c The errors are clearly due to changes in the glibc (function protos not visible etc). Does anyone have a good example of host configuration (i.e. which gcc, glibc most importantly) to use for building gcc-4.1.1. This question expands to all current gcc that will get gcc-4.2 release status in a few months. I would like to thank you in advance Nikolaos Kavvadias -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFFWgroMPiy0tCWlz4RAld1AJ9LlsWJXttO05zLJI+tjwrZA5ZadwCgqMpz iQSAfaz301TVJAmjG3BEBhI= =PAVP -END PGP SIGNATURE-
Re: Threading the compiler
"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, so a number of threads will likely be blocked > > for I/O. > > I'm not really sure how this would play with SMP (as opposed to threading). > I don't see why you think threading could be particularly useful in the > linker? It's the pipeline of compiler optimisation passes that looks like an > obvious candidate for threading to me. 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. And the linker spends a reasonable amount of time computing relocations, which can be parallelized such that the relocations for each input file are computed independently. Ian
Re: Has anyone seen mainline Fortran regression with SPEC CPU 2000/2006?
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. There's been a minor parsing error -- Steve merely meant that the fact that he hadn't seen the error should be expected, not that the error itself should be. :) - Brooks
RE: Threading the compiler
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 active. Moreover, linking tends to be I/O >>> intensive, so a number of threads will likely be blocked >>> for I/O. >> >> I'm not really sure how this would play with SMP (as opposed to >> threading). I don't see why you think threading could be particularly >> useful in the linker? It's the pipeline of compiler optimisation passes >> that looks like an obvious candidate for threading to me. > > 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. That's not even thread-worthy, that just required bog-standard AIO techniques. Um, /are/ there suitably portable AIO techniques? I guess the answer is going to be "Yeah, spawn a posix thread and make an ordinary synchronous f* io call in there"! Heh. > And the linker spends a reasonable > amount of time computing relocations, which can be parallelized such > that the relocations for each input file are computed independently. Ooh yes, big win to be had there. cheers, DaveK -- Can't think of a witty .sigline today
RE: Threading the compiler
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 is to increase CPU availability by using > multiple cores. 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 in most circumstances to get 99% of the benefit there to be had. I suspect that the balance will tip when the number of cores starts to get huge, and that at some time in the future we would benefit of the extra parallelizability we could get from reducing the effective scheduling granularity by threading the compiler. cheers, DaveK -- Can't think of a witty .sigline today
Re: Threading the compiler
"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. > > That's not even thread-worthy, that just required bog-standard AIO > techniques. Um, /are/ there suitably portable AIO techniques? I guess the > answer is going to be "Yeah, spawn a posix thread and make an ordinary > synchronous f* io call in there"! Heh. There is a POSIX standard: aio_read and friends. However, on GNU/Linux, aio_read just does the read in a different thread anyhow. So aio_read and friends are just a slightly simpler threading interface. Ian
Re: Do not use autoconf 2.60 yet
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
Re: Threading the compiler
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 in most circumstances to get 99% of the benefit there to be had. Currently the serial step is linking, and for the typical builds I do it is the bottleneck as the c/c++ -> o step is highly parallelizable. Figure out how to make the linker parallel, and then we can talk.
Re: Has anyone seen mainline Fortran regression with SPEC CPU 2000/2006?
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 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 pilot error for SPEC CPU2000 on Linux/x86-64. I am looking > into SPEC CPU 2006 failure on Linux/x86. > revision 118764 seems with SPEC CPU 2K/2006 on both Linux/x86-64 and Linux/x86. H.J.
Re: Has anyone seen mainline Fortran regression with SPEC CPU 2000/2006?
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 pilot error for SPEC CPU2000 on Linux/x86-64. I am looking into SPEC CPU 2006 failure on Linux/x86. revision 118764 seems with SPEC CPU 2K/2006 on both Linux/x86-64 and Linux/x86. Was there an "okay" missing from that sentence, or is there still a problem? - Brooks
Re: Do not use autoconf 2.60 yet
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'll use that. Done, sorry about that. -eric
Re: Do not use autoconf 2.60 yet
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 src have been moved.) -- Joseph S. Myers [EMAIL PROTECTED]
Re: building gcc4-4.3.0-20061104/11 failure on OSX 10.3
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:
...
Since the problem is still there in gcc4-4.3.0-2006 and I did
not get
any answer, I tried the following:
(1) I replaced gcc/config/darwin.h by the file from
gcc4-4.3.0-20061028,
and the build was done without obvious problem.
(2) Using the gcc/config/darwin.h from gcc4-4.3.0-2006, I
replaced:
#define PREFERRED_DEBUGGING_TYPE DWARF2_DEBUG
by
#define PREFERRED_DEBUGGING_TYPE DBX_DEBUG
Then the original failure:
strip: object: .//libgcc_s.1.dylib.tmp malformed object (unknown load
command 8)
disappeared (along with the other messages such as:
ranlib: file: ./libgcc.a(_trampoline.o) has no symbols
...
/sw/lib/odcctools/bin/nm: no name list
...
/sw/lib/odcctools/bin/ld: warning libgcc/./ppc64-fp_s.o could not
understand DWARF debug information
/sw/lib/odcctools/bin/ld: warning libgcc/./darwin-64_s.o could not
understand DWARF debug information
...
However the build failed with:
...
Configuring stage 2 in ./intl
configure: creating cache ./config.cache
checking whether make sets $(MAKE)... yes
checking for a BSD-compatible install... /sw/bin/ginstall -c
checking whether NLS is requested... yes
checking for msgfmt... /sw/bin/msgfmt
checking for gmsgfmt... /sw/bin/msgfmt
checking for xgettext... /sw/bin/xgettext
checking for msgmerge... /sw/bin/msgmerge
checking for powerpc-apple-darwin7-gcc...
/sw/src/fink.build/gcc4-4.3.0-20061115/darwin_objdir/./prev-gcc/xgcc
-B/sw/src/fink.build/gcc4-4.3.0-20061115/darwin_objdir/./prev-gcc/
-B/sw/lib/gcc4/powerpc-apple-darwin7/bin/
configure: error: C compiler cannot create executables
See `config.log' for more details.
make[2]: *** [configure-stage2-intl] Error 77
make[1]: *** [stage2-bubble] Error 2
make: *** [all] Error 2
checking for C compiler default output file name... ### execution of
/var/tmp/tmp.1.iDjVLN failed, exit code 2
Using
#define CPP_SPEC "%{static:%{!dynamic:-D__STATIC__}}%{!static:-
D__DYNAMIC__}"
instead of
#define CPP_SPEC "%{static:%{!dynamic:-D__STATIC__}}%{!static:-
D__DYNAMIC__}" \
" %{pthread:-D_REENTRANT}"
or removing
#define NO_IMPLICIT_EXTERN_C
did not help (same failure).
Any idea about what's wrong with the new gcc/config/darwin.h when used
with OSX 10.3?
Most likely your problem is that you're using cctools that are too
old. Are you using cctools-622.3 or later? Generally, every time
Apple releases a new cctools, you need to upgrade to it.
You'll also need /usr/bin/dsymutil. You can fake this by symlinking
it to /bin/true.
Mike was considering simply declaring that GCC 4.3 won't work on Mac
OS 10.3. 10.3 is quite old now, and there will be very few users by
the time that 4.3 is released.
smime.p7s
Description: S/MIME cryptographic signature
Re: Has anyone seen mainline Fortran regression with SPEC CPU 2000/2006?
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 fixed, with help of users who have access to SPEC CPU2000. > >>> > >>It was a pilot error for SPEC CPU2000 on Linux/x86-64. I am looking > >>into SPEC CPU 2006 failure on Linux/x86. > > > >revision 118764 seems with SPEC CPU 2K/2006 on both Linux/x86-64 and > >Linux/x86. > > Was there an "okay" missing from that sentence, or is there still a problem? > Ooops, revision 118764 seems OK. I am verifying it now. H.J.
Re: Do not use autoconf 2.60 yet
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 > 2.59; I'm not sure what's holding that up now all subdirectories of gcc > and src have been moved.) At this point I believe there are no more blockers. Steve Ellcey would be the person to ask. -- Daniel Jacobowitz CodeSourcery
Re: libffi on Macintel?
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: target-libmudflap target-libffi target-zlib target-libjava target-libada gnattools target-libgfortran target-libobjc target-boehm- gc (Any other directories should still work fine.) :-( This is rather disturbing since I assumed that Sandro's patches were all properly checked into gcc trunk before gcc 4.2 branched. :-( no one seems to be submitting testresults for i386-apple-darwin8 http://gcc.gnu.org/ml/gcc-testresults/2006-11/msg00621.html
cleaning
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 Removing child 0x00383f20 PID 18728 from chain. make[1]: *** [stage1-start] Interrupt make: *** [clean-stage1-libiberty] Interrupt :-( Building the entire compile to clean it isn't reasonable, honest. Comes from: maybe-clean-stage1-libiberty: clean-stage1-libiberty clean-stage1: clean-stage1-libiberty clean-stage1-libiberty: @[ -f $(HOST_SUBDIR)/libiberty/Makefile ] || [ -f $ (HOST_SUBDIR)/stage1-libiberty/Makefile ] \ || exit 0 ; \ [ $(current_stage) = stage1 ] || $(MAKE) stage1-start; \ cd $(HOST_SUBDIR)/libiberty && \ $(MAKE) $(FLAGS_TO_PASS) \ CFLAGS="$(STAGE1_CFLAGS)" LIBCFLAGS="$ (STAGE1_CFLAGS)" clean where we do stage1-start. Also, now make clean isn't reliable: $ make -k clean rm -f stage_current mv: rename stage1-libdecnumber to prev-libdecnumber/stage1- libdecnumber: Directory not empty make[1]: *** [stage2-start] Error 1 make[1]: *** No rule to make target `clean'. make: *** [clean-stage2-gcc] Error 2 rm -f *.a TEMP errs core *.o *~ \#* TAGS *.E *.log make: Target `clean' not remade because of errors. morgan $ echo $? 2 If I just configure and then do a make clean, it doesn't work either: rm -f *.a TEMP errs core *.o *~ \#* TAGS *.E *.log cat: stage_last: No such file or directory make: invalid option -- a Usage: make [options] [target] ... Options: -b, -m Ignored for compatibility. [ ... ] make: Target `clean' not remade because of errors. :-(
Re: Has anyone seen mainline Fortran regression with SPEC CPU 2000/2006?
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 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 pilot error for SPEC CPU2000 on Linux/x86-64. I am looking > > >>into SPEC CPU 2006 failure on Linux/x86. > > > > > >revision 118764 seems with SPEC CPU 2K/2006 on both Linux/x86-64 and > > >Linux/x86. > > > > Was there an "okay" missing from that sentence, or is there still a problem? > > > > Ooops, revision 118764 seems OK. I am verifying it now. I was wrong. revision 118764 with -O2 still leads to segfault in wrf in SPEC CPU 2006 on Linux/x86. revision 118353 is OK. Linux/x86-64 is OK. I am looking into it now. H.J.
vectorizer data dependency graph
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? (http://gcc.gnu.org/ml/gcc/2005-09/msg00661.html). A grep for creat_ddg shows it's used in modulo-sched.c. So is this fertile ground for something to be implemented? Is it worth implementing a ddg graph for the vectorizer? Thanks
RE: Threading the compiler
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 arguments that, at the moment, that's >> sufficient in most circumstances to get 99% of the benefit there to be had. > > Currently the serial step is linking, and for the typical builds I do it > is the bottleneck as the c/c++ -> o step is highly parallelizable. Figure > out how to make the linker parallel, and then we can talk. I was only talking in terms of the benefit to be had vs. threading the linker! cheers, DaveK -- Can't think of a witty .sigline today
Re: vectorizer data dependency graph
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 noticed that although ddg.c exists its not used much? (http://gcc.gnu.org/ml/gcc/2005-09/msg00661.html). A grep for creat_ddg shows it's used in modulo-sched.c. So is this fertile ground for something to be implemented? Is it worth implementing a ddg graph for the vectorizer? What exactly do you hope to gain by building a ddg? If you have some algorithm that can take advantage of a ddg, sure, build one. Thanks
Re: vectorizer data dependency graph
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 > implemented. Also had a search throught the mailing list archives and > noticed that although ddg.c exists its not used much? > (http://gcc.gnu.org/ml/gcc/2005-09/msg00661.html). A grep for > creat_ddg shows it's used in modulo-sched.c. So is this fertile ground > for something to be implemented? Is it worth implementing a ddg graph > for the vectorizer? What exactly do you hope to gain by building a ddg? If you have some algorithm that can take advantage of a ddg, sure, build one. No algorithm in particular - I thought someone else might find it useful (which is why I asked).
Re: vectorizer data dependency graph
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 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? > > (http://gcc.gnu.org/ml/gcc/2005-09/msg00661.html). A grep for > > creat_ddg shows it's used in modulo-sched.c. So is this fertile ground > > for something to be implemented? Is it worth implementing a ddg graph > > for the vectorizer? > > What exactly do you hope to gain by building a ddg? > If you have some algorithm that can take advantage of a ddg, sure, build one. > No algorithm in particular - I thought someone else might find it useful (which is why I asked). There is a ddg in this patch if somebody wants the classic Allen&Kennedy way to look at the dependences: http://gcc.gnu.org/wiki/OptimizationCourse?action=AttachFile&do=get&target=loop-distribution-patch-against-gcc-4.1.0-release.patch Sebastian
