------- Comment #8 from hp at gcc dot gnu dot org 2008-02-26 22:47 -------
(In reply to comment #7)
> If we don't have a way to truncate a file, we won't have an
> easy time enforcing Fortran semantics. Are there any other
> ways of truncating a file on that particular target?
I can certainly add support for this particular target, but the same goes for
*all* newlib targets except sh and spu.
> a) refuse to configure for that target at all
I mentioned this in the analysis (second url in description), but I'd advise
against it, as it'd imply breaking builds for all newlib targets configured
without --enable-targets=all-except-fortran - except for the one that marks
fortran as unsupported (using unsupported_languages in top/configure.ac).
> b) fail at runtime (noisily) and xfail the
> corresponding test cases
*sigh* ok, I'll do it, except for the noise. As I mentioned, there are a few
bugs there anyway, but nobody commented on that.
> c) juggle the file offsets, never read past the
> (logical) end of file and do a copy-on-close. Yuck.
Not me.
> My personal preference would go towards b), but again - there
> has to be a way of truncating a file, right?
There's no incentive. Bare-iron targets rarely really care about having a full
POSIX-or-whatever set of file operations.
--
hp at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|unassigned at gcc dot gnu |hp at gcc dot gnu dot org
|dot org |
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|0000-00-00 00:00:00 |2008-02-26 22:47:59
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35293
