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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Mike Miller-4
Hi,

There are several BISTs in the Octave test suite that we know pass with
GNU libstdc++, and we also know they fail with LLVM libc++ due to known
defects or differences in the library.

I think we need a better way of making these tests conditional on the
use of the GNU libstdc++ library. The current runtime condition is
simply not sufficient.

Should we add a new interpreter function called 'is_gnu_libstdcxx'? Or
maybe define a new compile-time symbol that can be understood by
'__have_feature__'?

The condition on these tests should be either

  %!testif HAVE_GNU_LIBSTDCXX
  %!testif ; is_gnu_libstdcxx ()

instead of

  %!testif ; ! ismac ()

As written now, I can build Octave with the LLVM clang compiler and
libc++ library on a GNU/Linux system, all free software, and end up with
what look like 12 unexpected test failures and 5 regressions. Not good.

The tests in question are in dlmread.cc, mappers.cc, str2double.cc,
asech.m, importdata.m, and io.tst.

I don't think these problem tests should be tagged and commented as
being problems with the macOS operating system, they are more accurately
problems with the LLVM libc++ implementation, which can be used on any
operating system.

Maybe even better would be to fix these bugs in libc++, or work around
them in liboctave somehow.

--
mike

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

John W. Eaton
Administrator
On 04/14/2018 04:02 AM, Mike Miller wrote:

> The tests in question are in dlmread.cc, mappers.cc, str2double.cc,
> asech.m, importdata.m, and io.tst.
>
> I don't think these problem tests should be tagged and commented as
> being problems with the macOS operating system, they are more accurately
> problems with the LLVM libc++ implementation, which can be used on any
> operating system.

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.

> Maybe even better would be to fix these bugs in libc++, or work around
> them in liboctave somehow.

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.

jwe

Reply | Threaded
Open this post in threaded view
|

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

Mike Miller-4
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 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Mike Miller-4
On Sun, Apr 15, 2018 at 12:52:23 -0700, Mike Miller wrote:
> I will start looking at defining a new compile-time conditional for
> these tests.
[…]
> of these functions for complex arguments. It might be possible to work
> around this problem by calling the C complex equivalent math library
> functions.

I should add that I don't think any of this needs to be done for 4.4.

--
mike