Re: RFC: Building a minimal libgfortran for nvptx

[Janne Blomqvist <blomqvist dot janne at gmail dot com>]

On Fri, Nov 14, 2014 at 11:28 PM, Tobias Burnus <burnus@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