This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH], Add configuration checks to PowerPC --with-long-double-format=ieee
- From: Michael Meissner <meissner at linux dot ibm dot com>
- To: Segher Boessenkool <segher at kernel dot crashing dot org>
- Cc: Michael Meissner <meissner at linux dot ibm dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, David Edelsohn <dje dot gcc at gmail dot com>, Bill Schmidt <wschmidt at linux dot vnet dot ibm dot com>
- Date: Fri, 6 Jul 2018 09:38:02 -0400
- Subject: Re: [PATCH], Add configuration checks to PowerPC --with-long-double-format=ieee
- References: <20180706055137.GA14803@ibm-toto.the-meissners.org> <20180706113855.GP16221@gate.crashing.org>
On Fri, Jul 06, 2018 at 06:38:55AM -0500, Segher Boessenkool wrote:
> On Fri, Jul 06, 2018 at 01:51:37AM -0400, Michael Meissner wrote:
> > case "$target:$with_long_double_format" in
>
> > - xpowerpc64*-*-linux*:*)
>
> So this case could never happen. The changelog should mention it fixes
> that bug (and having it as a separate patch is much preferred!)
I assume what happened is I accidently added the 'x' to the working copy after
submitting the patch, but before committing it and I didn't notice it. Since
it is in configuration support, it isn't part of the test sutie, and it wasn't
noticed.
I can add a line to the ChangeLog if desired.
> Other than this thing, the original code was easier to read. What does
> this part of the patch improve?
You complained that you were getting errors when using the system glibc (based
on 2.27 on an Ubuntu system) and using --with-long-double-format=ieee (where it
would die in the middle of building libstdc++-v3).
I wrote the patch to check that the glibc has the support so it fails when
configuring the compiler and gives a sensible message (need glibc 2.28). But
it doesn't really change anything. If you have an appropriate glibc, it will
build without the patch, and if you don't, it will fail. But it should be
friendlier to people building the compiler to understand why it failed.
I could duplicate the tests for glibc 2.28 (and AT-next alpha) for big endian
and little endian if desired, but it seemed clearer to me to combine the code
rather than duplicate the tests.
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meissner@linux.ibm.com, phone: +1 (978) 899-4797