This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH v2] Fix libgfortran cross compile configury w.r.t newlib
- From: Steve Ellcey <sellcey at mips dot com>
- To: Marcus Shawcroft <marcus dot shawcroft at gmail dot com>
- Cc: Mike Stump <mikestump at comcast dot net>, Tobias Burnus <burnus at net-b dot de>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, "fortran at gcc dot gnu dot org" <fortran at gcc dot gnu dot org>, Richard Earnshaw <Richard dot Earnshaw at arm dot com>
- Date: Tue, 12 Nov 2013 08:41:10 -0800
- Subject: Re: [PATCH v2] Fix libgfortran cross compile configury w.r.t newlib
- Authentication-results: sourceware.org; auth=none
- References: <52443AFE dot 5050802 at arm dot com> <1380298134 dot 5988 dot 61 dot camel at ubuntu-sellcey> <52497156 dot 5010203 at arm dot com> <524AB4AD dot 6070508 at arm dot com> <CAFqB+PxJR53JGV3f8dy7SNRHbdVMc0aqAC5ruFC6S0WXtksE5w at mail dot gmail dot com> <525DA2D7 dot 5080509 at net-b dot de> <A7ECA8A4-5136-471E-A5E2-89D7B9977C9D at comcast dot net> <CAFqB+Pwx+N0VcFQaUpc2J6Wz5r6GwKYgDQnPMg2vvGHE++srDw at mail dot gmail dot com> <1382633270 dot 2558 dot 104 dot camel at ubuntu-sellcey> <CAFqB+PwXF_hp_zD7n3+i+Fp7PL3i6JSSVmmAmbeNQmBUeL1_vQ at mail dot gmail dot com>
On Wed, 2013-11-06 at 17:32 +0000, Marcus Shawcroft wrote:
> Exactly, hard wiring the newlib interface into the configury of other
> libraries is questionable, but the patch applied to libgfortran goes
> beyond hard wiring details of the interface, it hard wires incorrect
> details of the interface when sizeof(long double) != sizeof(double).
Actually, libstdc++ hardwires incorrect information too. In its
configure it checks to see if long_double_math_on_this_cpu is set to
'yes' and then defines the *L math routines if it is not set. But the
variable is never set to true anywhere. The comment in configure.ac
says:
# At some point, we should differentiate between architectures
# like x86, which have long double versions, and alpha/powerpc/etc.,
# which don't. For the time being, punt.
I tested to see if this approach would work with libgfortran and MIPS by
not defining HAVE_STRTOLD and I could still build and run the testsuite.
In fact (at least on MIPS) we never use strtold because
GFC_REAL_16_IS_FLOAT128 is defined and that takes precedence and calls a
different routine to do the conversion.
> The argument that the patch is OK because libjava and libstdc++ also
> use this idiom, is also rather questionable, because the libgfortran
> patch goes beyond the idiom used in those other libraries by hard
> wiring an assumption that does not hold universally.
libgfortran is no better or worse then libstdc++ in this regard.
> On that basis, I think the the libgfortran patch should be reverted
> since it caused a regression.
>
> /Marcus
I understand that you don't like the patch and that you don't think
'libstdc++ does it too' is an adequate rationale, but at some point
being able to build is more important then having a clean looking
configure script and if we revert my patch, I can't build Fortran on
MIPS.
If you don't want to check in you patch that checks to see if we can
link in the exit routine, I would support removing the HAVE_STRTOLD
setting completely or putting it under a long_double_math_on_this_cpu
check (that is always false) like the libstdc++ configure script has.
Either of these changes would allow me to build. But just removing my
original patch leaves me unable to build at all and I don't know of a
'clean' way to fix that and apparently neither did the people working on
the libstdc++ and libjava configure scripts so I do object to reverting
my patch.
Steve Ellcey
sellcey@mips.com