[cfe-dev] Help needed diagnosing LibC++ test failures

[Martin J. O'Riordan via cfe-dev]

I am investigating various failures when running the LibC++ test-suite (v4.0
branch, svn rev #294535), and a couple of them have me really stumped.  The
following two tests were failing:

 

language.support/support.dynamic/new.delete/new.delete.array/sized_delete_ar
ray14.pass.cpp

language.support/support.dynamic/new.delete/new.delete.single/sized_delete14
.pass.cpp

 

and I realised that I needed to add '-fsized-deallocation'.  This fixed the
'array' version, but curiously the 'single' version still fails, and none of
the three versions of 'operator delete' are being called.  We have not made
any changes to the C++ front-end, so I don't understand how our target might
cause this.

 

The other group of failures is a lot more strange, and I haven't been able
to track down that could be wrong.  Most of the tests in the following
directories fail:

 

containers/associative/map/map.access

containers/associative/map/map.cons

containers/associative/map/map.modifiers

containers/associative/map/map.ops

and:

containers/associative/set

 

and all in the same way.  In each case the 'map' or 'set' is reporting
'm.size()' as '2' instead of the expected value, and the 'assert' for this
causes the test to fail.  The logic of what is happening disappears deeply
into the template iterator expansions for the construction of the 'map' or
'set' from the array of 'pair's provided to the constructor, and I am
wondering is anybody has any tips on how I can approach identifying why
these are breaking in this way?

 

The only thing that I can think of in our target that might be anyway
unusual, is that we have selected 'IEEESingle' for both 'float' and
'double', and all of these examples involve 'pair<int, double>', but even so
I can't think how this would impact these tests.

 

Thanks,

 

            MartinO

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170220/8c891d96/attachment.html>