Re: [RFC] gfortran's coarray (library version): configure/build and the testsuite
Hello,
* Jorge D'ELIA wrote on Wed, Apr 06, 2011 at 01:24:58AM CEST:
> Here there are few comments from my college Lisandro Dalcin,
> an external developer of PETSc, e.g. see
> - Mensaje original -
> > The current scheme is that the user somehow compiles
> > the communication library (libcaf) [2] and then builds
> > and links doing something like:
> >
> > mpif90 -fcoarray=lib fortran.f90 -lcaf_mpi
> >
> > or alternatively
> >
> > gfortran -fcoarray=lib fortran.f90 -lcaf_mpi
> > -I/usr/lib64/mpi/gcc/openmpi/include
> > -L/usr/lib64/mpi/gcc/openmpi/lib64
> > -lmpi
> >
> > with some -I, -L -l are added.
> > (Cf. "mpif90 -show" of some MPI implementations.)
> >
> > The resulting program is then run using, e.g.,
> >
> > mpiexec -n 3 ./a.out
> >
> > Alternatively, it could be just "-lcaf_single"
> > which is run like normal ("./a.out").
I think one of the most important things is that you allow to override
both the running of mpif90 and the mpiexec commands, so as to allow
batch environments (qsub, llrun). Although, parsing of output might
need to be more complex in that case, too. But if only to allow for
different mpiexec.* incarnations this would be good.
> > (In any case, only static libraries should be created;
> > the libraries could then be installed
> > in $PREFIX/$lib/gcc/$target/$version/, where
> > already libgcc.a etc. are located.)
>
> COMMENT: well, using shared libraries would certainly help
> users to switch the underlying MPI implementation at runtime.
> This is an feature should be considered.
The MPI implementations I know all have pairwise incompatible ABIs,
prohibiting any kind of switching at run time. If anything, GCC
might consider making it easy to build and install in parallel the
library for multiple MPI implementations.
Cheers,
Ralf
Re: Parameter not passed in call expr
Hello Ludovic,
ludovic.cour...@inria.fr (Ludovic Courtès) a écrit:
> The attached plug-in builds a function like this:
>
> my_function (void * parm.0)
> {
> __builtin_puts (parm.0);
> }
>
> However, the generated assembly clears the first-argument register
> (%edi) before calling ‘puts’, instead of actually passing the parameter:
>
> my_function:
> .LFB0:
> .file 1 "tt.c"
> .loc 1 1 0
> .cfi_startproc
> .loc 1 1 0
> xorl%edi, %edi ;; %edi shouldn’t be cleared
> jmp puts
> .cfi_endproc
>
> Any idea what I’m doing wrong?
[...]
> static void
> define_function (void *gcc_data, void *user_data)
> {
> tree decl, void_ptr;
> location_t loc = input_location;
>
> void_ptr = build_pointer_type (void_type_node);
> decl = build_decl (loc, FUNCTION_DECL, get_identifier ("my_function"),
>build_function_type_list (void_type_node,
> void_ptr, NULL_TREE));
>
> tree parm;
> parm = build_decl (loc, PARM_DECL,
>create_tmp_var_name ("parm"),
>void_ptr);
It looks like a:
DECL_ARG_TYPE (parm) = void_ptr;
might be helpful here.
> DECL_CONTEXT (parm) = decl;
> TREE_USED (parm) = true;
> DECL_ARGUMENTS (decl) = parm;
[...]
--
Dodji
Re: Confirming a bug in new bugzilla?
On Sat, 25 Sep 2010, Manuel López-Ibáñez wrote: > All the status have well-defined meanings: > > http://gcc.gnu.org/bugs/management.html > > Unfortunately, there is some duplication: > > http://gcc.gnu.org/bugzilla/page.cgi?id=fields.html Quite some duplication, in fact. By virtue of the patch below I am consolidating a significant portion thereof, leaving the instance provided by Bugzilla (which is also used for help links provided by the Bugzilla user interface) in place and shortening our local page. Two concrete items remain open: A. Status WAITING and SUSPENDED are not yet described in the Bugzilla description of the fields even though our Bugzilla instances provides them. They should be moved there, and I'll be happy to take pointers on how to best update this (in a way that the next Bugzilla version update does not kill those changes). B. Severity and Priority need to be consolidated, both in terms of documentation and since, so far, we had not described Trivial and Blocker in GCC. Alas, they are being used. Fun, fun, fun. I guess the best approach is to slightly tweak the text we have in Bugzilla, and similar to the patch below the remove it from the bugs/management.html page. Frédéric, do you have any advice? Gerald Index: bugs/management.html === RCS file: /cvs/gcc/wwwdocs/htdocs/bugs/management.html,v retrieving revision 1.28 diff -u -r1.28 management.html --- bugs/management.html31 Dec 2010 14:49:31 - 1.28 +++ bugs/management.html9 Apr 2011 19:28:50 - @@ -55,29 +55,12 @@ Bugzilla offers a number of different fields. From a maintainer's perspective, these are the relevant ones and what their values mean: - - - -Status -Resolution - - - -The status field indicates the general health of a bug. Only -certain status transitions are allowed. -The resolution field indicates what happened to this bug. - - - +The status and resolution fields define and track the life cycle of a +bug. In addition to their http://gcc.gnu.org/bugzilla/page.cgi?id=fields.html";>regular +descriptions, we also use two adition status values: -UNCONFIRMED -The PR has been filed and the responsible person(s) notified. - -NEW -A maintainer has verified that this is indeed a bug in GCC. Every -once in a while, old reports will need to be rechecked, to find out -whether the bug still exists. WAITING The submitter was asked for further information, or asked to try @@ -91,60 +74,8 @@ sought. If the problem cannot be solved at all, it should be closed rather than suspended. -ASSIGNED -This bug is not yet resolved, but is assigned to the proper -person. From here bugs can be given to another person and become -NEW, or resolved and become RESOLVED. - -REOPENED -This bug was once resolved, but the resolution was deemed -incorrect. For example, a WORKSFORME bug is -REOPENED when more information shows up and the bug is now -reproducible. From here bugs are either marked ASSIGNED -or RESOLVED. - - - - -No resolution yet. All bugs which are in one of these "open" states -have the resolution set to blank. All other bugs -will be marked with one of the following resolutions. - - - - - -RESOLVED - A resolution has been found for this bug. The bug is either closed -for good, or can be re-opened and change to REOPENED. - - - - -FIXED - A fix for this bug is checked into the tree and tested. - -INVALID - The problem described is not a bug. -WONTFIX - The problem described is a bug which will never be fixed. - -DUPLICATE - The problem is a duplicate of an existing bug. Marking a bug -duplicate requires the bug# of the duplicating bug and will at -least put that bug number in the description field. - -WORKSFORME - All attempts at reproducing this bug were futile, reading the -code produces no clues as to why this behavior would occur. If -more information appears later, please re-assign the bug, for -now, file it. - - - - The following two fields describe how serious a bug is from a user's perspective (severity) and which priority we assign to it in fixing it:
gcc-4.7-20110409 is now available
Snapshot gcc-4.7-20110409 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.7-20110409/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 172231 You'll find: gcc-4.7-20110409.tar.bz2 Complete GCC (includes all of below) MD5=df0d1085bcc4b367ba6d944006b7c4fb SHA1=4ba3cbb537155ca66410da2cf7f26205aadf7cd9 gcc-core-4.7-20110409.tar.bz2C front end and core compiler MD5=a679050331cd3525811efe9ebd7c1532 SHA1=bda1f803b0cd8ea10a0d4a66844e5202b093844b gcc-ada-4.7-20110409.tar.bz2 Ada front end and runtime MD5=cf55cdefd7f83095b3830893e0768106 SHA1=f3368697e1c1030c35c1d66940b3a0a2bf94363a gcc-fortran-4.7-20110409.tar.bz2 Fortran front end and runtime MD5=24d71ae3155b6ce4721d95e559c0e2de SHA1=795d6fc9ee9d4eee7f132cacaf6e06ca010eabb9 gcc-g++-4.7-20110409.tar.bz2 C++ front end and runtime MD5=b270a6bcd94db43aa254c2e3638a4ec7 SHA1=a6be583bbd2c9ab57b5872da4fd3e40bc4f9d78d gcc-go-4.7-20110409.tar.bz2 Go front end and runtime MD5=11929d55d80830f016bc913401752c14 SHA1=ce156d6ea528d624e03ccc7a380b14f036e534f1 gcc-java-4.7-20110409.tar.bz2Java front end and runtime MD5=29bcb0fe2a8df960b5e3910fa8319c25 SHA1=ccffbeb8f4cc2be821558cc53ecfe9205ffb2852 gcc-objc-4.7-20110409.tar.bz2Objective-C front end and runtime MD5=b77af4dda5cc30999b6c754a87e3b8a1 SHA1=9915f6c40e585bce1b7189864627317159214f9f gcc-testsuite-4.7-20110409.tar.bz2 The GCC testsuite MD5=3eec971c84481f2486c0d48083870d59 SHA1=eb1ab6100f54fc963a6a92ba676a9ffe91b5ccfc Diffs from 4.7-20110402 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.7 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.
Confusing error messages when with linking with LTO?
Hi, I just tried compiling with LTO for the first time. I can't figure out what to try based on the error message below. Is there a HTML page I should be looking at? It seems that this did not work: g++-4.6 -isystem ../../../master/boost/include -ffast-math -DNDEBUG -DNDEBUG_DP -funroll-loops -fweb -flto -fuse-linker-plugin -march=native -pipe -O3 -isystem /usr/lib/openmpi/include -isystem /usr/lib/openmpi/include/openmpi -pthread -pedantic -pthread -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -Wall -Wextra -Wno-sign-compare -Woverloaded-virtual -Wstrict-aliasing -o alignment-gild alignment-gild.o alignment.o alphabet.o sequence.o util.o rng.o tree.o sequencetree.o optimize.o findroot.o setup.o imodel.o probability.o sequence-format.o model.o distance-methods.o alignment-random.o alignment-util.o randomtree.o tree-util.o inverse.o io.o ../boost/lib/filesystem/libboost_filesystem.a ../boost/lib/program_options/libboost_program_options.a -lgsl -lgslcblas -lm /usr/bin/ld.gold: error: /tmp/cc4IJUrh.ltrans12.ltrans.o: multiple definition of '_ZTV18RootedSequenceTree.local.4048' /usr/bin/ld.gold: /tmp/cc4IJUrh.ltrans7.ltrans.o: previous definition here /usr/bin/ld.gold: error: /tmp/cc4IJUrh.ltrans12.ltrans.o: multiple definition of '_ZTT18RootedSequenceTree.local.4049' /usr/bin/ld.gold: /tmp/cc4IJUrh.ltrans7.ltrans.o: previous definition here collect2: ld returned 1 exit status So, it looks like the virtual table for class RootedSequenceTree is defined in multiple places. But the file name cc4IJUrh.ltrans12.ltrans.o doesn't clearly correspond to any input file name. Is there any way for me to find out which *.o files have definitions for this symbol, and why they are problematic only with LTO? -BenRI P.S. Apparently this did work: g++-4.6 -isystem ../../../master/boost/include -ffast-math -DNDEBUG -DNDEBUG_DP -funroll-loops -fweb -flto -fuse-linker-plugin -march=native -pipe -O3 -isystem /usr/lib/openmpi/include -isystem /usr/lib/openmpi/include/openmpi -pthread -pedantic -pthread -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -Wall -Wextra -Wno-sign-compare -Woverloaded-virtual -Wstrict-aliasing -o bali-phy sequence.o tree.o alignment.o substitution.o moves.o rng.o exponential.o eigenvalue.o parameters.o likelihood.o mcmc.o choose.o sequencetree.o sample-branch-lengths.o util.o randomtree.o alphabet.o smodel.o bali-phy.o hmm.o dp-engine.o dp-array.o dp-matrix.o 3way.o 2way.o sample-alignment.o sample-tri.o sample-node.o imodel.o 5way.o sample-topology-NNI.o setup.o rates.o matcache.o sample-two-nodes.o sequence-format.o util-random.o alignment-random.o setup-smodel.o sample-topology-SPR.o alignment-sums.o alignment-util.o probability.o model.o alignment-constraint.o substitution-cache.o substitution-star.o monitor.o substitution-index.o tree-util.o myexception.o pow2.o partition.o proposals.o n_indels.o distribution.o parsimony.o version.o slice-sampling.o timer_stack.o setup-mcmc.o io.o logger.o AIS.o ../boost/lib/mpi/libboost_mpi.a ../boost/lib/serialization/libboost_serialization.a -pthread -L/usr/lib/openmpi/lib -lmpi_cxx -lmpi -lopen-rte -lopen-pal -ldl -Wl,--export-dynamic -lnsl -lutil -lm -ldl ../boost/lib/filesystem/libboost_filesystem.a ../boost/lib/program_options/libboost_program_options.a -lgsl -lgslcblas -lm If I don't use LTO (that is, if I remove "-flto -fuse-linker-plugin") then everything works.
Re: Confirming a bug in new bugzilla?
On Sat, 9 Apr 2011, Gerald Pfeifer wrote: > -NEW > -A maintainer has verified that this is indeed a bug in GCC. Every > -once in a while, old reports will need to be rechecked, to find out > -whether the bug still exists. I think this text is superior for GCC to that on the generic page and so we should replace the text on the generic page by this GCC-specific text. > -RESOLVED > - A resolution has been found for this bug. The bug is either closed > -for good, or can be re-opened and change to REOPENED. Likewise. We don't use VERIFIED and CLOSED in GCC, proper text should reflect the existence of only one closed state with a genuine meaning and not mention the others (ideally they'd be completely hidden). -- Joseph S. Myers jos...@codesourcery.com
