Help needed diagnosing LibC++ test failures

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Help needed diagnosing LibC++ test failures

David Chisnall 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_array14.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

 


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Help needed diagnosing LibC++ test failures

David Chisnall via cfe-dev
Hi Martin,

Please provide the full test logs, including how the tests were invoked.

/Eric

On Mon, Feb 20, 2017 at 9:20 AM, Martin J. O'Riordan via cfe-dev <[hidden email]> wrote:

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_array14.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

 


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev



_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev