Re: Improving BISTs that are known to fail with LLVM libc++

[Mike Miller]

On Sun, Apr 15, 2018 at 07:52:21 -0500, John W. Eaton wrote:
> I agree that ismac is the wrong thing to use here.  Unless it is possible to
> switch between the GNU and Clang libraries at run time, then I would prefer
> to use the compile-time conditional.

I will start looking at defining a new compile-time conditional for
these tests.

> Yes, if possible, it would be better to fix these problems or work around
> them in Octave rather than just skip the tests.
> 
> How many separate bugs are there in the LLVM libc++?  Have they been
> reported?  It seems best if we could fix them there, but even if we can, we
> may want to work around them in Octave.

One bug in LLVM is responsible for 9 of these test failures. It's the
one where a string like "4i" in an input stream is not handled correctly
when trying to read the input into a double.

  https://bugs.llvm.org/show_bug.cgi?id=17782

This leads to the test failures in dlmread, importdata, sscanf, and
str2double.

If I am remembering right, Octave is relying on the operator>>(double&)
function to output the value '4' and leave the input stream pointer on
the character 'i'. LLVM libc++ does not do this.

As far as I can tell on the LLVM bug report, the bug is stalled waiting
on some clarifying language added to the C++ standard.

A workaround might involve some drastic rewriting of the way that Octave
reads numbers from text input streams.


The other 8 test failures all have to do with problems in the complex
variants of the acos, acosh, asin, and asinh standard library functions.
I don't know if there are LLVM bug reports for these or not.

It looks to me like LLVM defines its own suboptimal inline definitions
of these functions for complex arguments. It might be possible to work
around this problem by calling the C complex equivalent math library
functions.

-- 
mike

signature.asc
Description: PGP signature