[cfe-dev] clang/bindings tests for builds constrained to certain targets

Nagurne, James via cfe-dev cfe-dev at lists.llvm.org
Mon Feb 17 14:29:23 PST 2020


I wanted to check in with a solution I came up with that seems novel with regards to the rest of the python bindings tests.
I noticed that 'tls' is a valid feature in include/clang/Basic/Features.def, and maps to the target's isTLSSupported() value.

So I modified the test source to utilize that fact:

int tls_none;
thread_local int tls_dynamic;
_Thread_local int tls_static;

#if __has_feature(tls)
    int tls_supported;
#endif

I then test for the presence of a 'tls_supported' cursor and change the checks from DYNAMIC and STATIC to NONE.
It works well, but I believe this isn't in the spirit of the test as-written. I could also have added default flags to change the target to one known to support TLS to ensure both thread_local and _Thread_local work.

JB

From: cfe-dev [mailto:cfe-dev-bounces at lists.llvm.org] On Behalf Of Nagurne, James via cfe-dev
Sent: Monday, February 17, 2020 4:05 PM
To: 'cfe-dev at lists.llvm.org'
Subject: [EXTERNAL] [cfe-dev] clang/bindings tests for builds constrained to certain targets

Hi all, I have a question regarding the python unittests in the clang/bindings directory.

I'm running into an issue where my LLVM check-all is failing in the 'test_tls_kinds.py' unittest file. The toolchain I've built is one whose default (and only available) target is one which has TLSSupported set to false in the clang/lib/Basic/Targets/*.(h|cpp) file.

The test unconditionally attempts to use the TLS language features and fails due to the above configuration being false.

I've found no uses of skips in this test suite other than skipping when 'os.fspath' isn't available, or when the test is run on Windows. I was hoping for a 'skip if feature not enabled'.

The only other method I've found is just to not run all of these tests at all. I can do this through a special case in the clang/bindings/python/tests CMakeLists, but I'd rather not do so unless there's no better way.
Any ideas?

Thanks,
J.B. Nagurne
Code Generation
Texas Instruments
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200217/3aaff7b0/attachment.html>


More information about the cfe-dev mailing list