This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [fortran, patch] IEEE intrinsic modules (ping)

Janne Blomqvist wrote:
> On Mon, Jul 7, 2014 at 11:29 AM, FX <> wrote:
> > PS: I didnât touch libcaf, as I assume this might be compiled with a different compiler. Am I right?
> My understanding is that libcaf is delivered in source form, and the
> end user is expected to compile it against the correct MPI library on
> the target. So yes, one could be a bit more conservative here than in
> libgfortran proper (although one could expect the user to have access
> to the gcc version corresponding to gfortran..). But Tobias certainly
> knows better.

I think the proper libcaf handling still has to be sorted out.

libcaf_single, is automatically build and installed with GCC. GCC's
libgfortran/caf/mpi*c is unused. (There is also libgfortran/caf/libcaf.h,
used by single.c and mpi.c.)

The current external library, mostly written by Alessandro, currently ships
with its own libcaf.h plus some minimal definitions from libgfortran.h to
interface to the array descriptor. (To be replaced by TS29113's ISO*h file,
which we provide on the fortran-dev branch.) That external library also
provides a single version but also MPI, GASNet and ARMCI versions. Those
currently build with any C compiler and it should stay that way. This makes
is way easier to build on HPC systems. Especially with GASNet, where the
header files check that one uses exactly the same version of the compiler
as the one used to compile GASNet itself. (Some HPC systems ship with
GASNet libraries; in my case, also in a GCC 4.8 compiled version.)

Due to the MPI dependency, the idea is definitely to be able to continue to
compile the library externally (it also makes the integration into Linux
distros easier as it can then be bundled with MPI instead of being tight to
GCC). One can still think of optionally also building it (MPI, possibly
GASNet, version) with GCC, which means that it also integrates into GCC's
build process.

> > PS2: A third issue Iâve though about is: should we get rid of the following __GNUC__ test? libgfortran is not used as a standalone Fortran runtime library, and I think it is (and never will) be built by something else than a stage3 compiler.
> >
> >> #ifndef __GNUC__
> >> #define __attribute__(x)
> >> #define likely(x)       (x)
> >> #define unlikely(x)     (x)
> >> #else
> >> #define likely(x)       __builtin_expect(!!(x), 1)
> >> #define unlikely(x)     __builtin_expect(!!(x), 0)
> >> #endif
> What about --disable-bootstrap? Does it just skip stage1 and stage2,
> and stage3 is used to compile libgfortran, or is the host compiler
> used to build libgfortran as well? If the former, yes I guess we can
> remove #ifnderf __GNUC__ stuff?

I think for libgfortran, it uses the just-compiled compiler. However,
for some other libraries like libgcc and libiberty, I think it uses the
system compiler without re-compiling them again with the newly build


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]