[cfe-dev] [EXTERNAL] Re: [libc++] Porting libc++ to embedded targets/compilers

Nagurne, James via cfe-dev cfe-dev at lists.llvm.org
Tue Sep 12 17:38:58 PDT 2017


Thanks, Eli.
This commit will actually do precisely what I was suggesting with regards to sync functions. Glad to see I want the only one wondering about this :)

I'll patch this into my branch next chance I get a give it a spin

JB
________________________________________
From: Friedman, Eli [efriedma at codeaurora.org]
Sent: Tuesday, September 12, 2017 5:01 PM
To: Nagurne, James; cfe-dev at lists.llvm.org
Cc: codegen at list.ti.com - Code Generation Team (May contain non-TIers)
Subject: [EXTERNAL] Re: [cfe-dev] [libc++] Porting libc++ to embedded   targets/compilers

On 9/12/2017 2:41 PM, Nagurne, James via cfe-dev wrote:
Hello,

I am a developer in the compiler division (CodeGen) at Texas Instruments. Our compiler targets a variety of embedded targets from DSPs like the C6000 to microcontrollers like the C2000 and MSP430. All of our compilers use a common, modified EDG C++ front end accepting a majority of the C++14 standard in addition to many extensions allowed by both GCC and Clang, such as __has_feature.

We’re investigating using libc++ in addition to our home grown and augmented C (and C++ implementation-specific behavior) library to fill out our C++ support. Having worked on this for a week or so, I’ve cultivated a list of issues whose answers/solutions will help guide me in completing and trying to upstream some/all of this work.

- Atomic builtins (__sync functions) are assumed to exist, and other atomic issues
Our first drop of C++14 will not have support for threads or atomics, since we’re still talking with other teams which support the low-level operations and APIs needed.
The CMakelists.txt file checks for atomic support, warning “Host compiler must support std::atomic”. Is this a major problem that could stop us from being able to use libc++ immediately?
For the __sync functions, we could define template functions to overload and perform the elemental operation without any guarantee of atomicity (I believe all uses are currently ‘int’ operations). Is this alright, assuming we will not be supporting multiple theads?

There's a CMake option LIBCXX_ENABLE_THREADS you can use to turn off multi-threaded support... but you might still have trouble with atomics.  See https://reviews.llvm.org/D35235 .

-Eli

--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project




More information about the cfe-dev mailing list