Re: Merging the alias-improvements branch
> I will announce the time I am doing the last trunk -> alias-improvements > branch merge and freeze the trunk for that. > > Thus, this is a heads-up - if I collide with your planned merge schedule > just tell me and we can sort it out. I was planning to commit the vectorizer reorganization patch ( http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00573.html). Do you prefer that I wait, so it doesn't disturb the merge? Thanks, Ira
Re: Merging the alias-improvements branch
On Sun, 29 Mar 2009, Ira Rosen wrote:
>
> > I will announce the time I am doing the last trunk -> alias-improvements
> > branch merge and freeze the trunk for that.
> >
> > Thus, this is a heads-up - if I collide with your planned merge schedule
> > just tell me and we can sort it out.
>
> I was planning to commit the vectorizer reorganization patch (
> http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00573.html). Do you prefer
> that I wait, so it doesn't disturb the merge?
If you can commit the patch soon (like, before wednesday) you can go
ahead. The differences are not big (see attachment below for what
is the difference between trunk and branch in tree-vect-*), so I think
I can deal with the reorg just fine.
Thanks,
Richard.
Index: gcc/tree-vectorizer.c
===
--- gcc/tree-vectorizer.c (.../trunk) (revision 145210)
+++ gcc/tree-vectorizer.c (.../branches/alias-improvements)
(revision 145211)
@@ -973,7 +973,7 @@ slpeel_can_duplicate_loop_p (const struc
gimple orig_cond = get_loop_exit_condition (loop);
gimple_stmt_iterator loop_exit_gsi = gsi_last_bb (exit_e->src);
- if (need_ssa_update_p ())
+ if (need_ssa_update_p (cfun))
return false;
if (loop->inner
Index: gcc/tree-vect-analyze.c
===
--- gcc/tree-vect-analyze.c (.../trunk) (revision 145210)
+++ gcc/tree-vect-analyze.c (.../branches/alias-improvements)
(revision 145211)
@@ -3563,16 +3563,6 @@ vect_analyze_data_refs (loop_vec_info lo
return false;
}
- if (!DR_SYMBOL_TAG (dr))
-{
- if (vect_print_dump_info (REPORT_UNVECTORIZED_LOOPS))
-{
- fprintf (vect_dump, "not vectorized: no memory tag for ");
- print_generic_expr (vect_dump, DR_REF (dr), TDF_SLIM);
-}
- return false;
-}
-
base = unshare_expr (DR_BASE_ADDRESS (dr));
offset = unshare_expr (DR_OFFSET (dr));
init = unshare_expr (DR_INIT (dr));
@@ -3804,7 +3794,7 @@ vect_stmt_relevant_p (gimple stmt, loop_
/* changing memory. */
if (gimple_code (stmt) != GIMPLE_PHI)
-if (!ZERO_SSA_OPERANDS (stmt, SSA_OP_VIRTUAL_DEFS))
+if (gimple_vdef (stmt))
{
if (vect_print_dump_info (REPORT_DETAILS))
fprintf (vect_dump, "vec_stmt_relevant_p: stmt has vdefs.");
Index: gcc/tree-vect-transform.c
===
--- gcc/tree-vect-transform.c (.../trunk) (revision 145210)
+++ gcc/tree-vect-transform.c (.../branches/alias-improvements)
(revision 145211)
@@ -51,7 +51,7 @@ static bool vect_transform_stmt (gimple,
slp_tree, slp_instance);
static tree vect_create_destination_var (tree, tree);
static tree vect_create_data_ref_ptr
- (gimple, struct loop*, tree, tree *, gimple *, bool, bool *, tree);
+ (gimple, struct loop*, tree, tree *, gimple *, bool, bool *);
static tree vect_create_addr_base_for_vector_ref
(gimple, gimple_seq *, tree, struct loop *);
static tree vect_get_new_vect_var (tree, enum vect_var_kind, const char *);
@@ -1009,7 +1009,7 @@ vect_create_addr_base_for_vector_ref (gi
static tree
vect_create_data_ref_ptr (gimple stmt, struct loop *at_loop,
tree offset, tree *initial_address, gimple *ptr_incr,
- bool only_init, bool *inv_p, tree type)
+ bool only_init, bool *inv_p)
{
tree base_name;
stmt_vec_info stmt_info = vinfo_for_stmt (stmt);
@@ -1020,7 +1020,6 @@ vect_create_data_ref_ptr (gimple stmt, s
tree vectype = STMT_VINFO_VECTYPE (stmt_info);
tree vect_ptr_type;
tree vect_ptr;
- tree tag;
tree new_temp;
gimple vec_stmt;
gimple_seq new_stmt_list = NULL;
@@ -1068,42 +1067,33 @@ vect_create_data_ref_ptr (gimple stmt, s
}
/** (1) Create the new vector-pointer variable: **/
- if (type)
-vect_ptr_type = build_pointer_type (type);
- else
-vect_ptr_type = build_pointer_type (vectype);
-
- if (TREE_CODE (DR_BASE_ADDRESS (dr)) == SSA_NAME
- && TYPE_RESTRICT (TREE_TYPE (DR_BASE_ADDRESS (dr
-vect_ptr_type = build_qualified_type (vect_ptr_type, TYPE_QUAL_RESTRICT);
+ vect_ptr_type = build_pointer_type (vectype);
vect_ptr = vect_get_new_vect_var (vect_ptr_type, vect_pointer_var,
get_name (base_name));
- if (TREE_CODE (DR_BASE_ADDRESS (dr)) == SSA_NAME
- && TYPE_RESTRICT (TREE_TYPE (DR_BASE_ADDRESS (dr
+
+ /* If any of the data-references in the stmt group does not conflict
+ with the created vector data-reference use a ref-all pointer instead. */
+ if (STMT_VINFO_DR_GROUP_SIZE (stmt_info) > 1)
{
- get_alias_set (base_name);
- DECL_POINTER_ALIAS_SET (vect_ptr)
- = DECL_POINTER_ALIAS_SET (SSA_NAME_VAR (DR_BASE_ADDRESS (dr)));
+ gimple orig_s
Re: Merging the alias-improvements branch
Richard Guenther wrote on 29/03/2009 13:05:56:
> On Sun, 29 Mar 2009, Ira Rosen wrote:
>
> >
> > > I will announce the time I am doing the last trunk ->
alias-improvements
> > > branch merge and freeze the trunk for that.
> > >
> > > Thus, this is a heads-up - if I collide with your planned merge
schedule
> > > just tell me and we can sort it out.
> >
> > I was planning to commit the vectorizer reorganization patch (
> > http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00573.html). Do you prefer
> > that I wait, so it doesn't disturb the merge?
>
> If you can commit the patch soon (like, before wednesday) you can go
> ahead. The differences are not big (see attachment below for what
> is the difference between trunk and branch in tree-vect-*), so I think
> I can deal with the reorg just fine.
Great! I will commit it today or tomorrow then.
Thanks,
Ira
>
> Thanks,
> Richard.
>
>
> Index: gcc/tree-vectorizer.c
> ===
> --- gcc/tree-vectorizer.c (.../trunk) (revision 145210)
> +++ gcc/tree-vectorizer.c (.../branches/alias-improvements)
> (revision 145211)
> @@ -973,7 +973,7 @@ slpeel_can_duplicate_loop_p (const struc
>gimple orig_cond = get_loop_exit_condition (loop);
>gimple_stmt_iterator loop_exit_gsi = gsi_last_bb (exit_e->src);
>
> - if (need_ssa_update_p ())
> + if (need_ssa_update_p (cfun))
> return false;
>
>if (loop->inner
> Index: gcc/tree-vect-analyze.c
> ===
> --- gcc/tree-vect-analyze.c (.../trunk) (revision 145210)
> +++ gcc/tree-vect-analyze.c (.../branches/alias-improvements)
> (revision 145211)
> @@ -3563,16 +3563,6 @@ vect_analyze_data_refs (loop_vec_info lo
>return false;
> }
>
> - if (!DR_SYMBOL_TAG (dr))
> -{
> - if (vect_print_dump_info (REPORT_UNVECTORIZED_LOOPS))
> -{
> - fprintf (vect_dump, "not vectorized: no memory tag for ");
> - print_generic_expr (vect_dump, DR_REF (dr), TDF_SLIM);
> -}
> - return false;
> -}
> -
>base = unshare_expr (DR_BASE_ADDRESS (dr));
>offset = unshare_expr (DR_OFFSET (dr));
>init = unshare_expr (DR_INIT (dr));
> @@ -3804,7 +3794,7 @@ vect_stmt_relevant_p (gimple stmt, loop_
>
>/* changing memory. */
>if (gimple_code (stmt) != GIMPLE_PHI)
> -if (!ZERO_SSA_OPERANDS (stmt, SSA_OP_VIRTUAL_DEFS))
> +if (gimple_vdef (stmt))
>{
> if (vect_print_dump_info (REPORT_DETAILS))
> fprintf (vect_dump, "vec_stmt_relevant_p: stmt has vdefs.");
> Index: gcc/tree-vect-transform.c
> ===
> --- gcc/tree-vect-transform.c (.../trunk) (revision 145210)
> +++ gcc/tree-vect-transform.c (.../branches/alias-improvements)
> (revision 145211)
> @@ -51,7 +51,7 @@ static bool vect_transform_stmt (gimple,
> slp_tree, slp_instance);
> static tree vect_create_destination_var (tree, tree);
> static tree vect_create_data_ref_ptr
> - (gimple, struct loop*, tree, tree *, gimple *, bool, bool *, tree);
> + (gimple, struct loop*, tree, tree *, gimple *, bool, bool *);
> static tree vect_create_addr_base_for_vector_ref
>(gimple, gimple_seq *, tree, struct loop *);
> static tree vect_get_new_vect_var (tree, enum vect_var_kind, const char
*);
> @@ -1009,7 +1009,7 @@ vect_create_addr_base_for_vector_ref (gi
> static tree
> vect_create_data_ref_ptr (gimple stmt, struct loop *at_loop,
> tree offset, tree *initial_address, gimple *ptr_incr,
> - bool only_init, bool *inv_p, tree type)
> + bool only_init, bool *inv_p)
> {
>tree base_name;
>stmt_vec_info stmt_info = vinfo_for_stmt (stmt);
> @@ -1020,7 +1020,6 @@ vect_create_data_ref_ptr (gimple stmt, s
>tree vectype = STMT_VINFO_VECTYPE (stmt_info);
>tree vect_ptr_type;
>tree vect_ptr;
> - tree tag;
>tree new_temp;
>gimple vec_stmt;
>gimple_seq new_stmt_list = NULL;
> @@ -1068,42 +1067,33 @@ vect_create_data_ref_ptr (gimple stmt, s
> }
>
>/** (1) Create the new vector-pointer variable: **/
> - if (type)
> -vect_ptr_type = build_pointer_type (type);
> - else
> -vect_ptr_type = build_pointer_type (vectype);
> -
> - if (TREE_CODE (DR_BASE_ADDRESS (dr)) == SSA_NAME
> - && TYPE_RESTRICT (TREE_TYPE (DR_BASE_ADDRESS (dr
> -vect_ptr_type = build_qualified_type (vect_ptr_type,
TYPE_QUAL_RESTRICT);
> + vect_ptr_type = build_pointer_type (vectype);
>vect_ptr = vect_get_new_vect_var (vect_ptr_type, vect_pointer_var,
> get_name (base_name));
> - if (TREE_CODE (DR_BASE_ADDRESS (dr)) == SSA_NAME
> - && TYPE_RESTRICT (TREE_TYPE (DR_BASE_ADDRESS (dr
> +
> + /* If any of the data-references in the stmt group does not conflict
> + with the created vector data-reference use a ref-all pointer
> instead. *
Linking libgfortran with libiberty
Hi all, This mail is a request for some help from our local build machinery experts... We have a patch under testing for libgfortran to add runtime memleaks checking, and it uses libiberty's hash tables. So, we now link gfortran programs with libiberty. We also need to link in libiberty while building libgfortran (which I discovered because otherwise we get failures on darwin), by the following patch: Index: Makefile.am === --- Makefile.am (revision 145225) +++ Makefile.am (working copy) @@ -17,7 +17,7 @@ toolexeclib_LTLIBRARIES = libgfortran.la libgfortran_la_LINK = $(LINK) -libgfortran_la_LDFLAGS = -version-info `grep -v '^\#' $(srcdir)/ libtool-version` $(LTLDFLAGS) -lm $(extra_ldflags_libgfortran) $ (version_arg) +libgfortran_la_LDFLAGS = -version-info `grep -v '^\#' $(srcdir)/ libtool-version` $(LTLDFLAGS) -L../libiberty -liberty -lm $ (extra_ldflags_libgfortran) $(version_arg) myexeclib_LTLIBRARIES = libgfortranbegin.la myexeclibdir = $(libdir)/gcc/$(target_alias)/$(gcc_version)$ (MULTISUBDIR) i.e. we add "-L../libiberty -liberty" to libgfortran_la_LDFLAGS. My question is the following: is "-L../libiberty" the right way to tell the build machinery where to find the target libiberty, or is there something more clever to do? I see that libjava uses a variable named $ (here), but I couldn't get it working in libgfortran/Makefile.am, so I reverted to the simpler "../libiberty". Thanks for your help, FX PS: the current draft of the complete patch, if you are interested in it, is attached (it was put together by Tobias Burnus) memleak2.diff Description: Binary data PPS, to Dominique: this is the promised fix for Darwin :)
Re: Linking libgfortran with libiberty
On Sun, Mar 29, 2009 at 1:00 PM, FX wrote: > Hi all, > > This mail is a request for some help from our local build machinery > experts... We have a patch under testing for libgfortran to add runtime > memleaks checking, and it uses libiberty's hash tables. So, we now link > gfortran programs with libiberty. What do you mean by this? Linking libiberty to programs build with gfortran? Note that libiberty is not installed by default IIRC. > We also need to link in libiberty while > building libgfortran (which I discovered because otherwise we get failures > on darwin), by the following patch: > > Index: Makefile.am > === > --- Makefile.am (revision 145225) > +++ Makefile.am (working copy) > @@ -17,7 +17,7 @@ > > toolexeclib_LTLIBRARIES = libgfortran.la > libgfortran_la_LINK = $(LINK) > -libgfortran_la_LDFLAGS = -version-info `grep -v '^\#' > $(srcdir)/libtool-version` $(LTLDFLAGS) -lm $(extra_ldflags_libgfortran) > $(version_arg) > +libgfortran_la_LDFLAGS = -version-info `grep -v '^\#' > $(srcdir)/libtool-version` $(LTLDFLAGS) -L../libiberty -liberty -lm > $(extra_ldflags_libgfortran) $(version_arg) > > myexeclib_LTLIBRARIES = libgfortranbegin.la > myexeclibdir = $(libdir)/gcc/$(target_alias)/$(gcc_version)$(MULTISUBDIR) > > > i.e. we add "-L../libiberty -liberty" to libgfortran_la_LDFLAGS. My question > is the following: is "-L../libiberty" the right way to tell the build > machinery where to find the target libiberty, or is there something more > clever to do? I see that libjava uses a variable named $(here), but I > couldn't get it working in libgfortran/Makefile.am, so I reverted to the > simpler "../libiberty". I see that libgfortran is GPLv2 + exception while libiberty is LGPLv2. I think for statically linking libiberty into libgfortran there may be issues. Richard. > Thanks for your help, > FX > > > PS: the current draft of the complete patch, if you are interested in it, is > attached (it was put together by Tobias Burnus) > > > > > > PPS, to Dominique: this is the promised fix for Darwin :) >
Re: Minimum GMP/MPFR version bumps for GCC-4.5
On Sun, 2009-03-29 at 00:48 +, Joseph S. Myers wrote: > On Sat, 28 Mar 2009, David Edelsohn wrote: > > > > If you're able to compile and install GCC on a system then my experience > > > is that configuring and installing GMP and MPFR from .tar.gz is hassle > > > free (you must use --disable-shared on both) and does not take very long > > > relative to GCC bootstrap. On the GCC Compile Farm if you look > > > at it GMP and MPFR in /opt/cfarm are not compiled by root :). > > > > Graphite needs shared libgmpxx to avoid linking cc1 with libstdc++. > > I added the --with-host-libstdcxx configure option specifically so you can > link with static copies of GMP, MPFR, PPL, CLooG and with either a shared > or a static copy of libstdc++. I tested the following build process: export ROOT=/some/where gmp-4.2.4 ./configure --prefix=$ROOT/gmp-4.2.4 --disable-shared --enable-cxx mpfr-2.3.1 ./configure --prefix=$ROOT/mpfr-2.3.1 --disable-shared --with-gmp=$ROOT/gmp-4.2.4 ppl-0.10 ./configure --prefix=$ROOT/ppl-0.10 --disable-shared --with-gmp=$ROOT/gmp-4.2.4 cloog-ppl ./configure --prefix=$ROOT/cloog-ppl-1.5 --disable-shared --with-gmp=$ROOT/gmp-4.2.4 --with-ppl=$ROOT/ppl-0.10 trunk ../trunk/configure --prefix=$ROOT/trunk --enable-languages=c,ada --enable-__cxa_atexit --enable-threads=posix \ --with-gmp=$ROOT/gmp-4.2.4 --with-mpfr=$ROOT/mpfr-2.3.1 --with-ppl=$ROOT/ppl-0.10 \ --with-cloog=$ROOT/cloog-ppl-1.5 --with-host-libstdcxx=-lstdc++ However it fails during stage2: make[3]: Entering directory `/home/guerby/build-ppl/gcc' ... /home/guerby/build-ppl/./prev-gcc/xgcc -B/home/guerby/build-ppl/./prev-gcc/ -B/n/17/guerby/install-trunk-ppl/x86_64-unknown-linux-gnu/bin/ -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -Wc++-compat -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -o cc1-dummy c-lang.o stub-objc.o attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o c-semantics.o c-ppoutput.o c-cppbuiltin.o c-objc-common.o c-dump.o c-pch.o c-parser.o i386-c.o c-gimplify.o tree-mudflap.o c-pretty-print.o c-omp.o dummy-checksum.o \ main.o tree-browser.o libbackend.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -L/home/guerby/root/cloog-ppl-1.5/lib -lcloog -L/home/guerby/root/ppl-0.10/lib -lppl_c -lppl -lgmpxx -lstdc++ -L/home/guerby/root/gmp-4.2.4/lib -L/home/guerby/root/mpfr-2.3.1/lib -lmpfr -lgmp /usr/bin/ld: cannot find -lstdc++ collect2: ld returned 1 exit status make[3]: *** [cc1-dummy] Error 1 make[3]: Leaving directory `/home/guerby/build-ppl/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/home/guerby/build-ppl' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/home/guerby/build-ppl' make: *** [bootstrap] Error 2 What am I missing? Thanks in advance, Laurent
Re: [PPL-devel] PPL broken for Canadian-cross builds
Joseph S. Myers wrote: On Fri, 20 Mar 2009, Roberto Bagnara wrote: thanks for the detailed explanation. I admit we always have postoponed the issue of cross-compilation... to the point we almost forgot it. We will fix the PPL asap. Can we come back to you in case we are unsure about which defaults can be considered safe? I can test whether a candidate fixed tarball works (to build PPL and GCC in such an environment) in this case; [...] Hi there, the PPL 0.10.1 snapshots available at ftp://ftp.cs.unipr.it/pub/ppl/snapshots/ contain all the fixes to problems and glitches that have been reported to us and may affect GCC. Concerning cross-compilation, we have fixed the configuration procedure and made several portability improvements: we have tested these changes cross-compiling for arm-elf and i686-pc-mingw32. Please let us know if this is OK as far as GCC 4.4 is concerned. All the best, Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagn...@cs.unipr.it
Re: Deprecating Itanium1 for GCC 4.4
On Mon, Mar 23, 2009 at 7:28 PM, Steve Ellcey wrote:
> I think
> depreciating Itanium1 tuning for 4.4 and removing it in 4.5 is
> reasonable. Code generated and tuned for Itanium2 should run fine on
> Itanium1 (Merced). It won't be scheduled optimally of course, but it
> should run correctly.
(...)
> I will approve this patch, but it should say "Itanium1 tuning support"
> or something like that. The code will run on Itanium1, just not
> optimally.
Like so (with same changelog). I'll commit this before the end of the
week to the gcc-4_4-branch if no-one objects. Bootstrapped and tested
on ia64 with gcc-4_4-branch.
For gcc 4.5, should I wait with posting the cleanup patch until the
end of the development cycle, or can we go ahead and clean things up
now in stage 1?
Ciao!
Steven
* config/ia64/ia64.c (ia64_handle_option): Inform user that Itanium1
support is deprecated if the -mtune value is set to an Itanium1
variant.
Index: config/ia64/ia64.c
===
--- config/ia64/ia64.c (revision 145211)
+++ config/ia64/ia64.c (working copy)
@@ -5212,6 +5212,8 @@ fix_range (const char *const_str)
static bool
ia64_handle_option (size_t code, const char *arg, int value)
{
+ static bool warned_itanium1_deprecated;
+
switch (code)
{
case OPT_mfixed_range_:
@@ -5245,6 +5247,16 @@ ia64_handle_option (size_t code, const c
if (!strcmp (arg, processor_alias_table[i].name))
{
ia64_tune = processor_alias_table[i].processor;
+ if (ia64_tune == PROCESSOR_ITANIUM
+ && ! warned_itanium1_deprecated)
+ {
+ inform (0,
+ "value %<%s%> for -mtune= switch is deprecated",
+ arg);
+ inform (0, "GCC 4.4 is the last release with "
+ "Itanium1 tuning support");
+ warned_itanium1_deprecated = true;
+ }
break;
}
if (i == pta_size)
Re: Linking libgfortran with libiberty
On Sun, 29 Mar 2009, Richard Guenther wrote: > I see that libgfortran is GPLv2 + exception while libiberty is LGPLv2. I > think > for statically linking libiberty into libgfortran there may be issues. The license situation for libiberty is much more complicated than that; parts are GPL (no exception), parts LGPL, parts GPL + exception. See PR 32213. I am told the SC never discussed the 2003 message pointed to in that PR. Any changes now would probably also include converting the files to GPLv3 / LPGLv3 / GPLv3 + new runtime exception. If you wish to use particular files from libiberty in a runtime library, you'll need FSF approval to distribute them under GPL + exception (as in the C++ demangler) and should then compile those source files from within the build system for your runtime library (see how libstdc++ builds in the demangler from libiberty, for example) rather than doing something risky like linking with a mixed-license target libiberty. -- Joseph S. Myers jos...@codesourcery.com
Re: Minimum GMP/MPFR version bumps for GCC-4.5
On Sun, 29 Mar 2009, Laurent GUERBY wrote: > /home/guerby/build-ppl/./prev-gcc/xgcc -B/home/guerby/build-ppl/./prev-gcc/ > -B/n/17/guerby/install-trunk-ppl/x86_64-unknown-linux-gnu/bin/ -g -O2 > -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes > -Wcast-qual -Wold-style-definition -Wc++-compat -Wmissing-format-attribute > -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror > -fno-common -DHAVE_CONFIG_H -o cc1-dummy c-lang.o stub-objc.o attribs.o > c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o > c-common.o c-opts.o c-format.o c-semantics.o c-ppoutput.o c-cppbuiltin.o > c-objc-common.o c-dump.o c-pch.o c-parser.o i386-c.o c-gimplify.o > tree-mudflap.o c-pretty-print.o c-omp.o dummy-checksum.o \ > main.o tree-browser.o libbackend.a ../libcpp/libcpp.a > ../libdecnumber/libdecnumber.a ../libcpp/libcpp.a ../libiberty/libiberty.a > ../libdecnumber/libdecnumber.a -L/home/guerby/root/cloog-ppl-1.5/lib -lcloog > -L/home/guerby/root/ppl-0.10/lib -lppl_c -lppl -lgmpxx -lstdc++ > -L/home/guerby/root/gmp-4.2.4/lib -L/home/guerby/root/mpfr-2.3.1/lib -lmpfr > -lgmp > /usr/bin/ld: cannot find -lstdc++ > collect2: ld returned 1 exit status > make[3]: *** [cc1-dummy] Error 1 > make[3]: Leaving directory `/home/guerby/build-ppl/gcc' > make[2]: *** [all-stage2-gcc] Error 2 > make[2]: Leaving directory `/home/guerby/build-ppl' > make[1]: *** [stage2-bubble] Error 2 > make[1]: Leaving directory `/home/guerby/build-ppl' > make: *** [bootstrap] Error 2 > > What am I missing? If you are doing a bootstrap rather than building a cross compiler, and the host libstdc++ is not in a path searched by the compiler being built, you'll need --with-host-libstdcxx="-L/some/where -lstdc++" so the newly built compiler can find the host libstdc++. -- Joseph S. Myers jos...@codesourcery.com
Re: Deprecating Itanium1 for GCC 4.4
On Sun, 29 Mar 2009, Steven Bosscher wrote: > On Mon, Mar 23, 2009 at 7:28 PM, Steve Ellcey wrote: > > I think > > depreciating Itanium1 tuning for 4.4 and removing it in 4.5 is > > reasonable. Code generated and tuned for Itanium2 should run fine on > > Itanium1 (Merced). It won't be scheduled optimally of course, but it > > should run correctly. > (...) > > I will approve this patch, but it should say "Itanium1 tuning support" > > or something like that. The code will run on Itanium1, just not > > optimally. > > Like so (with same changelog). I'll commit this before the end of the > week to the gcc-4_4-branch if no-one objects. Bootstrapped and tested > on ia64 with gcc-4_4-branch. > > For gcc 4.5, should I wait with posting the cleanup patch until the > end of the development cycle, or can we go ahead and clean things up > now in stage 1? If the cleanup doesn't go on trunk at the same time as the deprecation patch goes on 4.4, the deprecation patch should go on trunk at that time until the cleanup is done, to avoid this being deprecated only on 4.4. (I think early stage 1 is a fine time for doing the cleanup.) -- Joseph S. Myers jos...@codesourcery.com
Re: Linking libgfortran with libiberty
If you wish to use particular files from libiberty in a runtime library, you'll need FSF approval to distribute them under GPL + exception I'm interested only in include/hashtab.h and libiberty/hashtab.c, which are both currently under GPL2. How does one ask for FSF approval to distribute them as GPL + exception? We'd like to be able to use them in the GNU Fortran runtime library. Thanks for your explanations, FX
Re: Minimum GMP/MPFR version bumps for GCC-4.5
On Sun, 2009-03-29 at 14:37 +, Joseph S. Myers wrote: > On Sun, 29 Mar 2009, Laurent GUERBY wrote: > > > /home/guerby/build-ppl/./prev-gcc/xgcc -B/home/guerby/build-ppl/./prev-gcc/ > > -B/n/17/guerby/install-trunk-ppl/x86_64-unknown-linux-gnu/bin/ -g -O2 > > -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes > > -Wmissing-prototypes -Wcast-qual -Wold-style-definition -Wc++-compat > > -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros > > -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -o cc1-dummy > > c-lang.o stub-objc.o attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o > > c-typeck.o c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o > > c-semantics.o c-ppoutput.o c-cppbuiltin.o c-objc-common.o c-dump.o c-pch.o > > c-parser.o i386-c.o c-gimplify.o tree-mudflap.o c-pretty-print.o c-omp.o > > dummy-checksum.o \ > > main.o tree-browser.o libbackend.a ../libcpp/libcpp.a > > ../libdecnumber/libdecnumber.a ../libcpp/libcpp.a > > ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a > > -L/home/guerby/root/cloog-ppl-1.5/lib -lcloog > > -L/home/guerby/root/ppl-0.10/lib -lppl_c -lppl -lgmpxx -lstdc++ > > -L/home/guerby/root/gmp-4.2.4/lib -L/home/guerby/root/mpfr-2.3.1/lib -lmpfr > > -lgmp > > /usr/bin/ld: cannot find -lstdc++ > > collect2: ld returned 1 exit status > > make[3]: *** [cc1-dummy] Error 1 > > make[3]: Leaving directory `/home/guerby/build-ppl/gcc' > > make[2]: *** [all-stage2-gcc] Error 2 > > make[2]: Leaving directory `/home/guerby/build-ppl' > > make[1]: *** [stage2-bubble] Error 2 > > make[1]: Leaving directory `/home/guerby/build-ppl' > > make: *** [bootstrap] Error 2 > > > > What am I missing? > > If you are doing a bootstrap rather than building a cross compiler, and > the host libstdc++ is not in a path searched by the compiler being built, > you'll need --with-host-libstdcxx="-L/some/where -lstdc++" so the newly > built compiler can find the host libstdc++. --with-host-libstdcxx="-L/usr/lib -lstdc++" fails earlier: make[3]: Entering directory `/home/guerby/build-ppl/gcc' ... gcc -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -Wc++-compat -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -o cc1-dummy c-lang.o stub-objc.o attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o c-semantics.o c-ppoutput.o c-cppbuiltin.o c-objc-common.o c-dump.o c-pch.o c-parser.o i386-c.o c-gimplify.o tree-mudflap.o c-pretty-print.o c-omp.o dummy-checksum.o \ main.o tree-browser.o libbackend.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -L/home/guerby/root/cloog-ppl-1.5/lib -lcloog -L/home/guerby/root/ppl-0.10/lib -lppl_c -lppl -lgmpxx -L/usr/lib -lstdc++ -L/home/guerby/root/gmp-4.2.4/lib -L/home/guerby/root/mpfr-2.3.1/lib -lmpfr -lgmp libbackend.a(builtins.o): In function `fold_builtin_1': ../../trunk/gcc/builtins.c:10319: undefined reference to `mpfr_j0' ../../trunk/gcc/builtins.c:10325: undefined reference to `mpfr_j1' ../../trunk/gcc/builtins.c:10331: undefined reference to `mpfr_y0' ../../trunk/gcc/builtins.c:10337: undefined reference to `mpfr_y1' libbackend.a(builtins.o): In function `fold_builtin_2': ../../trunk/gcc/builtins.c:10458: undefined reference to `mpfr_jn' ../../trunk/gcc/builtins.c:10464: undefined reference to `mpfr_yn' ../../trunk/gcc/builtins.c:10472: undefined reference to `mpfr_remainder' libbackend.a(builtins.o): In function `do_mpfr_remquo': ../../trunk/gcc/builtins.c:13372: undefined reference to `mpfr_remquo' libbackend.a(builtins.o): In function `do_mpfr_lgamma_r': ../../trunk/gcc/builtins.c:13450: undefined reference to `mpfr_lgamma' collect2: ld returned 1 exit status make[3]: *** [cc1-dummy] Error 1 make[3]: Leaving directory `/home/guerby/build-ppl/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/home/guerby/build-ppl' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/home/guerby/build-ppl' make: *** [bootstrap] Error 2 gue...@gcc17:~/build-ppl$ ls -l /usr/lib/libstdc++* lrwxrwxrwx 1 root root 18 2008-05-09 14:37 /usr/lib/libstdc++.so.5 -> libstdc++.so.5.0.7 -rw-r--r-- 1 root root 829896 2007-01-03 20:58 /usr/lib/libstdc++.so.5.0.7 lrwxrwxrwx 1 root root 18 2008-05-09 10:08 /usr/lib/libstdc++.so.6 -> libstdc++.so.6.0.8 -rw-r--r-- 1 root root 965344 2006-12-11 00:11 /usr/lib/libstdc++.so.6.0.8 If I rerun the failing gcc command removing manually the "-L/usr/lib" and keeping the "-lstdc++" it works and the resulting cc1-dummy is as follows: gue...@gcc17:~/build-ppl/gcc$ ldd ./cc1-dummy libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x2abc3000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x2adc1000) libc.so.6 => /lib/libc.so.6 (0x2aecf000) lib
Re: Minimum GMP/MPFR version bumps for GCC-4.5
On Sun, 29 Mar 2009, Laurent GUERBY wrote: > libbackend.a(builtins.o): In function `fold_builtin_1': > ../../trunk/gcc/builtins.c:10319: undefined reference to `mpfr_j0' > ../../trunk/gcc/builtins.c:10325: undefined reference to `mpfr_j1' > ../../trunk/gcc/builtins.c:10331: undefined reference to `mpfr_y0' > ../../trunk/gcc/builtins.c:10337: undefined reference to `mpfr_y1' It appears your problem is that the directory with libstdc++ in it also has an old MPFR version in it, so passing a -L option for it interferes with finding the right MPFR. In that case, --with-host-libstdc++=/usr/lib/libstdc++.so should work - you need to name the actual file to use for linking libstdc++ rather than giving -L and -l options. -- Joseph S. Myers jos...@codesourcery.com
Re: GCC 4.4 Branch Created
On Fri, 27 Mar 2009, Mark Mitchell wrote:
> The tasks that remain from branching.html are:
I believe everything needed for starting the new release branch is now
done apart from this:
> 13. Asking Danny Berlin to adjust PRs.
Daniel, could you change "4.4" to "4.4/4.5" in the summaries of all open
PRs ("4.4 Regression" -> "4.4/4.5 Regression", etc.) (through database
access, not manually editing each PR with the web interface)?
Once this is done I'll deal with closing 4.2 branch (manually - branch
closing involves interpreting the PR log for each 4.2 regression bug,
unlike branch opening where anything present at 4.4 branchpoint is
automatically present when 4.5 started).
--
Joseph S. Myers
jos...@codesourcery.com
Re: GCC 4.4 Branch Created
On Sat, 28 Mar 2009, Jakub Jelinek wrote: > On Sat, Mar 28, 2009 at 11:20:35AM +0100, Richard Guenther wrote: > > On Sat, Mar 28, 2009 at 9:01 AM, Eric Botcazou > > wrote: > > >> I have done this, and applied this patch to reflect that submitting a > > >> snapshot to the TP is not necessary after creating a release branch if > > >> one > > >> was submitted during stage 3 or 4 (now we have a long stabilisation > > >> period > > >> on trunk and a comparatively short one on the branch before release, > > >> submitting one from trunk is the right approach). > > > > > > Stage 4 needs to be documented on http://gcc.gnu.org/develop.html then. > > > > Technically Stage 4 is the same as release branch status (just without > > branching > > before). But indeed, we should update develop.html - does this need to go > > via > > the SC? > > We should probably drop current Stage 2 and just rename Stage 3 to Stage 2 > and Stage 4 to Stage 3 as well, I think this model worked very well in 4.4. If we do this make sure to update branching.html and translation.html where I recently inserted references to "stage 3 or 4". -- Joseph S. Myers jos...@codesourcery.com
Re: GCC 4.4 Branch Created
On Sun, Mar 29, 2009 at 11:27 AM, Joseph S. Myers
wrote:
> On Fri, 27 Mar 2009, Mark Mitchell wrote:
>
>> The tasks that remain from branching.html are:
>
> I believe everything needed for starting the new release branch is now
> done apart from this:
>
>> 13. Asking Danny Berlin to adjust PRs.
>
> Daniel, could you change "4.4" to "4.4/4.5" in the summaries of all open
> PRs ("4.4 Regression" -> "4.4/4.5 Regression", etc.) (through database
> access, not manually editing each PR with the web interface)?
>
Done
> Once this is done I'll deal with closing 4.2 branch (manually - branch
> closing involves interpreting the PR log for each 4.2 regression bug,
> unlike branch opening where anything present at 4.4 branchpoint is
> automatically present when 4.5 started).
>
> --
> Joseph S. Myers
> jos...@codesourcery.com
>
Re: Minimum GMP/MPFR version bumps for GCC-4.5
On Sun, 2009-03-29 at 15:21 +, Joseph S. Myers wrote:
> On Sun, 29 Mar 2009, Laurent GUERBY wrote:
>
> > libbackend.a(builtins.o): In function `fold_builtin_1':
> > ../../trunk/gcc/builtins.c:10319: undefined reference to `mpfr_j0'
> > ../../trunk/gcc/builtins.c:10325: undefined reference to `mpfr_j1'
> > ../../trunk/gcc/builtins.c:10331: undefined reference to `mpfr_y0'
> > ../../trunk/gcc/builtins.c:10337: undefined reference to `mpfr_y1'
>
> It appears your problem is that the directory with libstdc++ in it also
> has an old MPFR version in it, so passing a -L option for it interferes
> with finding the right MPFR. In that case,
> --with-host-libstdc++=/usr/lib/libstdc++.so should work - you need to name
> the actual file to use for linking libstdc++ rather than giving -L and -l
> options.
With --with-host-libstdc++=/usr/lib/libstdc++.so.6 the build did
succeed, thanks for your advices.
gue...@gcc17:~/build-ppl$ ldd gcc/cc1
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x2abc3000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x2adc1000)
libc.so.6 => /lib/libc.so.6 (0x2aecf000)
libm.so.6 => /lib/libm.so.6 (0x2b10c000)
/lib64/ld-linux-x86-64.so.2 (0x2aaab000)
Should we add to the documentation the steps to configure and
build an all-static but libstdc++ GCC (as in my first email)? Or less
ambitious in install.texi:
Typical values of @var{linker-args} might be
@samp{-lstdc++} or @samp{-Wl,-Bstatic,-lstdc++,-Bdynamic -lm}.
=>
Typical values of @var{linker-args} might be
@samp{/usr/lib/libstdc++.so.6}, @samp{-lstdc++} or
@samp{-Wl,-Bstatic,-lstdc++,-Bdynamic -lm}.
Sincerely,
Laurent
Re: GCC 4.4 Branch Created
On Sun, 29 Mar 2009, Daniel Berlin wrote:
> On Sun, Mar 29, 2009 at 11:27 AM, Joseph S. Myers
> wrote:
> > On Fri, 27 Mar 2009, Mark Mitchell wrote:
> >
> >> The tasks that remain from branching.html are:
> >
> > I believe everything needed for starting the new release branch is now
> > done apart from this:
> >
> >> 13. Asking Danny Berlin to adjust PRs.
> >
> > Daniel, could you change "4.4" to "4.4/4.5" in the summaries of all open
> > PRs ("4.4 Regression" -> "4.4/4.5 Regression", etc.) (through database
> > access, not manually editing each PR with the web interface)?
> >
> Done
Thanks. The "Serious regressions" link for 4.5 now gives a plausible
figure of 79, rather than the previous 2.
--
Joseph S. Myers
jos...@codesourcery.com
Re: [PPL-devel] PPL broken for Canadian-cross builds
On Sun, 29 Mar 2009, Roberto Bagnara wrote: > Joseph S. Myers wrote: > > On Fri, 20 Mar 2009, Roberto Bagnara wrote: > > > thanks for the detailed explanation. I admit we always have postoponed > > > the > > > issue of cross-compilation... to the point we almost forgot it. We will > > > fix the PPL asap. Can we come back to you in case we are unsure about > > > which > > > defaults can be considered safe? > > > > I can test whether a candidate fixed tarball works (to build PPL and GCC in > > such an environment) in this case; [...] > > Hi there, > > the PPL 0.10.1 snapshots available at > > ftp://ftp.cs.unipr.it/pub/ppl/snapshots/ > > contain all the fixes to problems and glitches that have been reported to > us and may affect GCC. Concerning cross-compilation, we have fixed the > configuration procedure and made several portability improvements: we > have tested these changes cross-compiling for arm-elf and i686-pc-mingw32. > > Please let us know if this is OK as far as GCC 4.4 is concerned. > All the best, I can confirm that PPL now builds successfully for i686-mingw32 host. The next problem is that CLooG (the tarball in the infrastructure directory) doesn't appear portable to this system (in the secondary platforms list for 4.4 and 4.5); I get: source/program.c:42:27: error: sys/resource.h: No such file or directory ... source/program.c:674: error: 'RUSAGE_SELF' undeclared (first use in this function) ... This does not appear to be a cross build problem; it appears this file uses this header, not available on MinGW, unconditionally with no configure checks. -- Joseph S. Myers jos...@codesourcery.com
Ideas for Google Summer of Code
Hello All, I am a PhD student who has been working with CUDA for the GPU and also gcc for Cell BE for about a year now. (By work I mean developing applications). I am looking to bring GCC closer to being able to support OpenCL as a Google Summer of Code. Here are some of my ideas: 1. Make an NVIDIA GPU backend 2. Make the OpenCL runtime for the Cell Processor 3. Make the OpenCL runtime for a homogeneous processor What idea is most valuable to the gcc community? Are there any other more valuable ideas? About me: I have been reading the gcc mailing list for about 6 months now, I have submitted my first patch to a simple package that comes with Ubuntu (glife). I have been programming in C for about 10 years and C++ for less. Phil Pratt-Szeliga
Re: Linking libgfortran with libiberty
Richard, On 29 Mar 2009, at 12:08, Richard Guenther wrote: On Sun, Mar 29, 2009 at 1:00 PM, FX wrote: Hi all, This mail is a request for some help from our local build machinery experts... We have a patch under testing for libgfortran to add runtime memleaks checking, and it uses libiberty's hash tables. So, we now link gfortran programs with libiberty. What do you mean by this? Linking libiberty to programs build with gfortran? Note that libiberty is not installed by default IIRC. That might be the intention - but (at least on OSX/Darwin) libiberty.a is installed, see also this thread for some elaboration on different permutations: http://gcc.gnu.org/ml/gcc-help/2008-06/msg9.html (I just built & installed from trunk on darwin9 and it is still the case that "make install" does this). Iain
Re: [PPL-devel] PPL broken for Canadian-cross builds
Hi,
On Sun, Mar 29, 2009 at 11:32, Joseph S. Myers wrote:
> I can confirm that PPL now builds successfully for i686-mingw32 host. The
> next problem is that CLooG (the tarball in the infrastructure directory)
> doesn't appear portable to this system (in the secondary platforms list
> for 4.4 and 4.5); I get:
>
> source/program.c:42:27: error: sys/resource.h: No such file or directory
> ...
> source/program.c:674: error: 'RUSAGE_SELF' undeclared (first use in this
> function)
> ...
>
> This does not appear to be a cross build problem; it appears this file
> uses this header, not available on MinGW, unconditionally with no
> configure checks.
>
I committed the attached fix to the cloog-ppl repo, and I will prepare
a new tar.gz for the gcc infrastructure.
Sebastian Pop
--
AMD - GNU Tools
diff --git a/configure.in b/configure.in
index 03f280a..6c27749 100644
--- a/configure.in
+++ b/configure.in
@@ -103,6 +103,8 @@ AC_HEADER_STDC
dnl Checks for library functions.
AC_CHECK_FUNCS(strtol)
+AC_CHECK_HEADER(sys/resource.h,[AC_DEFINE(HAS_SYS_RESOURCE_H)],
+ [AC_MSG_RESULT([no])])
dnl /**
dnl * Option setting *
diff --git a/include/cloog/cloog-config.h.in b/include/cloog/cloog-config.h.in
index ba2c92c..01429f4 100644
--- a/include/cloog/cloog-config.h.in
+++ b/include/cloog/cloog-config.h.in
@@ -1,2 +1,3 @@
#undef LINEAR_VALUE_IS_MP
#undef CLOOG_PPL_BACKEND
+#undef HAS_SYS_RESOURCE_H
diff --git a/source/program.c b/source/program.c
index 7814fa1..0587308 100644
--- a/source/program.c
+++ b/source/program.c
@@ -39,7 +39,6 @@
# include
# include
-# include
#include
# include
# include
@@ -47,6 +46,9 @@
# include
# include
# include "../include/cloog/cloog.h"
+#ifdef HAS_SYS_RESOURCE_H
+# include
+#endif
/**
@@ -614,7 +616,9 @@ CloogProgram * cloog_program_malloc (void)
*/
CloogProgram * cloog_program_generate(CloogProgram *program, CloogOptions *options)
{ float time ;
+#ifdef HAS_SYS_RESOURCE_H
struct rusage start, end ;
+#endif
CloogLoop * loop ;
#ifdef CLOOG_MEMORY
char status_path[MAX_STRING_VAL] ;
@@ -671,7 +675,10 @@ CloogProgram * cloog_program_generate(CloogProgram *program, CloogOptions *optio
}
}
+#ifdef HAS_SYS_RESOURCE_H
getrusage(RUSAGE_SELF, &start) ;
+#endif
+
if (cloog_program_loop (program))
{
loop = cloog_program_loop (program) ;
@@ -699,12 +706,14 @@ CloogProgram * cloog_program_generate(CloogProgram *program, CloogOptions *optio
cloog_program_set_loop (program, loop);
}
+#ifdef HAS_SYS_RESOURCE_H
getrusage(RUSAGE_SELF, &end) ;
/* We calculate the time spent in code generation. */
time = (end.ru_utime.tv_usec - start.ru_utime.tv_usec)/(float)(MEGA) ;
time += (float)(end.ru_utime.tv_sec - start.ru_utime.tv_sec) ;
options->time = time ;
-
+#endif
+
return program ;
}
Re: Minimum GMP/MPFR version bumps for GCC-4.5
On Fri, 27 Mar 2009, Ralf Corsepius wrote: >> I do see that FreeBSD Ports has mpfr 2.4.1. How advanced of them. > Amazing :-() It's possible I am missing something here. According to http://www.mpfr.org/mpfr-current/ (reachable from http://www.mpfr.org/ by following "Latest release") this is the latest official release, but your comments seem to indicate there is a problem with that? My daily testsuite runs on FreeBSD have been using this version for a while, and there are no problems striking out. I think. :-) Is there anything I might want to raise with the maintainer of that package? Gerald
Re: Ideas for Google Summer of Code
Hi, phil++ wrote: I am a PhD student who has been working with CUDA for the GPU and also gcc for Cell BE for about a year now. (By work I mean developing applications). I am looking to bring GCC closer to being able to support OpenCL as a Google Summer of Code. Here are some of my ideas: 1. Make an NVIDIA GPU backend 2. Make the OpenCL runtime for the Cell Processor 3. Make the OpenCL runtime for a homogeneous processor I'm no mentor and thus don't take my comment too seriously, but I've started to work with CUDA recently (and may be doing so for my Bachelor's thesis) and would *love* to see some gcc support in this direction! Regarding your points, I tend to favour point 1. Thinking about it, when adding support for Co-Arrays to the Fortran front-end, maybe we could allow NVIDIA cards as backend for Co-Array'ed programs? In general, it could be interesting to allow, for instance, writing kernels in Fortran, so existing code could be reused (or for the ones that like Fortran :D). Maybe some basic support for that could be achieved, too? (That is, gcc compiled kernels in some way.) Yours, Daniel
Re: Linking libgfortran with libiberty
On Sun, Mar 29, 2009 at 01:00:50PM +0200, FX wrote: > This mail is a request for some help from our local build machinery > experts... We have a patch under testing for libgfortran to add > runtime memleaks checking, and it uses libiberty's hash tables. So, we > now link gfortran programs with libiberty. We also need to link in > libiberty while building libgfortran (which I discovered because > otherwise we get failures on darwin), by the following patch: I don't think it is a good idea to turn libgfortran into a kitchen sink. memleak checking should be IMHO left to valgrind/mtrace and other memory allocators that track memory leaks. You should never link libiberty.a into target libraries, if really needed just #include the files from include/ and/or libiberty/ in your sources and rename the symbols, so that common libiberty symbols aren't exported from libgfortran. Jakub
gcc-4.3-20090329 is now available
Snapshot gcc-4.3-20090329 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20090329/ 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/branches/gcc-4_3-branch revision 145262 You'll find: gcc-4.3-20090329.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20090329.tar.bz2 C front end and core compiler gcc-ada-4.3-20090329.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20090329.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20090329.tar.bz2 C++ front end and runtime gcc-java-4.3-20090329.tar.bz2 Java front end and runtime gcc-objc-4.3-20090329.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20090329.tar.bz2The GCC testsuite Diffs from 4.3-20090326 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 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.
status of the plugins branch vs 4.4?
Hello All
What is the status of the plugins branch? I understood that once GCC
goes back in stage 1, the plugins branch should go into the trunk?
Or is this related to the recurring runtime licensing issues?
In other words, are there any hard reasons to avoid adding plugins into
the current trunk?
I understood that perhaps Diego Novillo (and some others GCC gurus)
would merge plugins into trunk as soon as the trunk is back in stage 1?
Or did I misunderstood?
Regards.
PS I am considering making the MELT branch as a plugin, but I won't
start doing that before plugins are in the trunk.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: GCC 4.4 Branch Created
On Sat, Mar 28, 2009 at 09:48:19AM -0700, Mark Mitchell wrote: > Jakub Jelinek wrote: > > >> Technically Stage 4 is the same as release branch status (just without > >> branching > >> before). But indeed, we should update develop.html - does this need to go > >> via > >> the SC? > > > > We should probably drop current Stage 2 and just rename Stage 3 to Stage 2 > > and Stage 4 to Stage 3 as well, I think this model worked very well in 4.4. > > I don't think SC approval is required. I think that the SC trusts me to > approve these kinds of minor mechanical adjustments to the process > (subject, of course, to the fact that people can appeal decisions they > don't like to the SC). I agree that this is a good strategy. So, let's > go ahead. The release process is the domain of the RM team, and the SC (at least this member, and I think others as well) has no interest in micromanaging it.
Re: status of the plugins branch vs 4.4?
On Sun, Mar 29, 2009 at 18:52, Basile STARYNKEVITCH wrote: > I understood that perhaps Diego Novillo (and some others GCC gurus) would > merge plugins into trunk as soon as the trunk is back in stage 1? Yes, I will merge plugins into trunk during stage 1. Hopefully soon. Diego.
Re: Minimum GMP/MPFR version bumps for GCC-4.5
Gerald Pfeifer wrote: On Fri, 27 Mar 2009, Ralf Corsepius wrote: I do see that FreeBSD Ports has mpfr 2.4.1. How advanced of them. Amazing :-() It's possible I am missing something here. According to http://www.mpfr.org/mpfr-current/ (reachable from http://www.mpfr.org/ by following "Latest release") this is the latest official release, but your comments seem to indicate there is a problem with that? Pardon, there seems to be a misunderstanding. I only was surprised to see FreeBSD shipping much newer versions of packages than most Linux distros (even those who claim to be "(b)leading edge"). Ralf
