This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Add D demangling support to libiberty


On 14 October 2014 15:28, Ian Lance Taylor <iant@google.com> wrote:
> On Tue, Oct 14, 2014 at 7:12 AM, Joel Brobecker <brobecker@adacore.com> wrote:
>>
>>> libiberty/ChangeLog
>>> 2014-08-05  Iain Buclaw  <ibuclaw@gdcproject.org>
>>>
>>>     * Makefile.in (CFILES): Add d-demangle.c.
>>>     (REQUIRED_OFILES): Add d-demangle.o.
>>>     * cplus-dem.c (libiberty_demanglers): Add dlang_demangling case.
>>>     (cplus_demangle): Likewise.
>>>     * d-demangle.c: New file.
>>>     * testsuite/Makefile.in (really-check): Add check-d-demangle.
>>>     * testsuite/d-demangle-expected: New file.
>>
>> As hinted on gdb-patches, this patch causes a GDB build failure
>> on Solaris 2.9, because it uses strtold which is not available.
>> According to gnulib's documentation, it should also break on
>> the following systems:
>>
>>         NetBSD 3.0, OpenBSD 3.8, Minix 3.1.8, IRIX 6.5, OSF/1 4.0,
>>         Solaris 9, Cygwin, MSVC 9, Interix 3.5, BeOS.
>>
>> This patch attempts to fix the issue by adding a configure check
>> for strtold and adjusts the code to use strtod if strtold does not
>> exist.
>>
>> Does this look OK to you? If yes, can one of the GCC maintainers
>> please review?
>
> It doesn't make sense to me to use strtod if strtold is required.  And
> if strtold is not required, then it seems to me that we should always
> use strtod.  It seems to me that the right options are either 1) use
> strtod unconditionally; 2) add strtold to libiberty
>
> Since option 1 is simpler, what bad things would happen if we use
> strtod unconditionally?
>
> Ian

I've just seen this, so I'll repeat what I've said in gdb patches too.

The call to strtold is only needed to decode templates which have a
floating point value encoded inside. This value may or may not have a
greater than double precision.

Replacing long double with double will be fine with me.  I'll accept
that I didn't consider legacy in hindsight, and in reality it would be
rather rare to stumble upon the need for strtold.

Regards
Iain


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]