Re: [Patch] Add to the libgfortran/newlib bodge to "detect" ftruncate support in ARM/AArch64/SH

[James Greenhalgh <james.greenhalgh@arm.com>]

On Sun, Aug 30, 2015 at 02:46:26PM +0100, Hans-Peter Nilsson wrote:
> (Pruned the CC list a bit as lists are included anyway)
> 
> On Fri, 28 Aug 2015, James Greenhalgh wrote:
> > On Fri, Aug 28, 2015 at 10:40:31AM +0100, James Greenhalgh wrote:
> > > On Tue, Aug 25, 2015 at 03:44:05PM +0100, FX wrote:
> > > > > 2015-08-25  James Greenhalgh  <james.greenhalgh@arm.com>
> > > > >
> > > > > 	* configure.ac: Auto-detect newlib function support unless we
> > > > > 	know there are issues when configuring for a host.
> > > > > 	* configure: Regenerate.
> > > >
> > > > Thanks for CC?ing the fortran list.
> > > >
> > > > Given that this is newlib-specific code, even though it?s in libgfortran
> > > > configury, you should decide and commit what?s best. I don?t think we have
> > > > any newlib expert in the Fortran maintainers.
> > > >
> > > > Wait for 48 hours to see if anyone else objects, though.
> > >
> > > OK, it has been 48 hours and I haven't seen any objections. The newlib
> > > patch has now been committed.
> > >
> > > I agree with Marcus' suggestion that we put the more comprehensive patch
> > > (which requires the newlib fix) on trunk and my original patch (which does
> > > not) on the release branches.
> > >
> > > I'll go ahead with that later today.
> >
> > Now in place on trunk (r227301), gcc-5-branch (r227302) and gcc-4_9-branch
> > (r227304).
> >
> > Give me a shout if you see issues in your build systems.
> 
> Since you asked: I saw a build failure for cris-elf matching the
> missing-kill-declaration issue, and I don't like much having to
> take manual steps force a new newlib version. It isn't being
> automatically updated because there are regressions in my gcc
> test-suite results.  I guess autodetecting the kill-declaration
> issue in libgfortran is unnecessary complicated, in presence of
> a fixed newlib trunk.  All in all, I appreciate you don't force
> a new newlib on release branches.

Hi,

I could postpone the pain until after the release of GCC 6, by that
point the newlib change will have a little longer to make it in to
people's trees. On the other hand, this seems like the best way to fix
the issue, and we are probably as well to do it now while we are still
sitting in stage 1.

I don't want to cause you too much inconvenience, so if you'd like, I
can revert the more comprehensive patch from trunk for now. I would be
very keen to push it again, either late in GCC 6 development, or soon
after the opening of GCC 7.

Otherwise, if you're happy enough with the fix staying in place, I'll
just leave it.

Sorry to have caused you any issues.

James