Hi all,
since everyone seems to agree that it makes in principle sense to have a
reduce libgfortran (even though a full one is nicer, if the system
permits), let's look at the patch itself ;-)
Bernd Schmidt wrote:
The ptx port by its nature is lacking features that are expected on
"normal" machines, such as alloca and indirect jumps. We have a subset
of the C library which contains functions that can be implemented on
the target (excluding things like file I/O other than printf which is
a ptx builtin).
It would be good to be able to also build as much of libgfortran as
possible, and the following patch is what I've been using so far. It
recognizes the target at configure time and restricts the list of
compiled files, as well as providing a LIBGFOR_MINIMAL define for
#ifdef tests. There's also a new file minimal.c which contains
alternative implementations of some functionality (using printf to
write error messages rather than fprintf and such). Constructors are
currently unimplemented on ptx and therefore the init function is
commented out.
Does printf work? I thought I/O is not supported? Or does it just accept
it for linking and drop it? I think Janne's patch has already dealt with
the issue of stack allocation.
What I dislike a bit about the feature is that it is not clear what
features will be supported for LIBGFOR_MINIMAL. Maybe configure.ac would
be a good place to describe which features are included there (e.g. no
I/O but "printf" etc.) and which aren't. That will make it easier to see
what has to be modifed if one will add another differently bare system
later on.
+#if 0
+/* Initialize the runtime library. */
#if 0'ed code shouldn't be in the patch.
+@LIBGFOR_MINIMAL_FALSE@gfor_helper_src = intrinsics/associated.c \
+@LIBGFOR_MINIMAL_FALSE@ intrinsics/abort.c intrinsics/access.c \
+@LIBGFOR_MINIMAL_FALSE@ intrinsics/args.c \
+@LIBGFOR_MINIMAL_FALSE@ intrinsics/bit_intrinsics.c \
...
+@LIBGFOR_MINIMAL_TRUE@gfor_helper_src = intrinsics/associated.c \
+@LIBGFOR_MINIMAL_TRUE@ intrinsics/abort.c intrinsics/args.c \
...
Can't one write this differently, avoiding having most lines repeated
and only a few missing from the second set? I am not an automake expert,
but can't one simply split this into different make variables - one set
which is in both and one which is not in minimal?
Otherwise, the RFC looks good to me.
Tobias
Tobias
