On Fri, Nov 14, 2014 at 11:28 PM, Tobias Burnus <bur...@net-b.de> wrote: > Hi Tobias, > > Bernd Schmidt wrote: >>> >>> 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. >> >> >> printf (or more accurately vprintf) is supported by ptx as a magic builtin >> function. We have a printf wrapper around vprintf in our newlib.
So the normal stdin/out/err file descriptors are not available? > And that prints to the normal screen? That makes debugging easier than I had > hoped for. > >> What was Janne's patch? > > > He changed stack allocation to static/heap allocation; the patch was > committed 36h ago, broke Cesar's bootstrap and is here: > https://gcc.gnu.org/ml/fortran/2014-11/msg00052.html To be fair, most of the fixes were in the I/O library, or for various I/O related syscall wrappers, which probably aren't of interest for the nvptx backend. In any case, libgfortran doesn't use alloca() nor VLA's anymore, if there were any issues related to that when doing your patch you might want to review it and see if you can make the minimal version a bit more complete. >>> 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. >> >> >> My view is that it makes no sense to generalize this at the moment when it >> is unknown what another target that uses this would look like. The time to >> revisit this is when there is another target. Are you committed to helping whoever will be doing the support for the next minimal target then? Otherwise it seems a bit unfair to leave it to them to clean up the mess? > Well, one can still add some notes what is supported and what isn't – not > only for that hypothecial case but also when doing other changes to the > library (adding new functions). Yes, something like this would be nice. Otherwise it seems really easy to inadvertently break nvptx. -- Janne Blomqvist
