RFC: Clang and libstdc++ versions, string.h and cstring conflicts, and glibc patches.

Is that another variant of the problem I was seeing compiling the program below?
See my earlier message with the subject: clang and gcc -O3 bug amongst other issues?
and Howard’s comments of WCHAR_H_CPLUSPLUS_98_CONFORMANCE on the message I mentioned.

Is this related?

Yes, I believe that's essentially the same issue -- glibc has the C++ versions of the wcschr function (when GCC > 4.4) just like the functions in cstring.

I would guess your problem is that the Windows C library, much like glibc when compiled with GCC > 4.4, defines the correct C++ prototypes -- but that libc++ doesn't recognize that it's doing so. The bug 7983 that I mentioned has a little more discussion of what was happening with glibc in that case.

The fix is presumably similar -- either define the CPLUSPLUS_98_CONFORMANCE macros somewhere, or add a clause to the checks for them that also checks for the relevant Windows C library.

- Brooks


To whom it may concern,

I am the CEO and co-founder of Ajax Compilers (http://www.ajaxcompilers.com), an EDA startup established in Jan. 2012.

The job:

We are in urgent need of an LLVM developer/specialist/guru for a specific short term, full-time commercial project.
Please let us know within the following few days if you are interested and willing to undertake the project.

Details follow:

The task is to develop an LLVM backend for our in-house typed-assembly language named NAC (N-Address Code). The backend should be able to translate LLVM IR to NAC. NAC is both an abstract machine as well as an intermediate representation for most of our in-house tools. A manual of the NAC programming language can be found here:

http://www.nkavvadias.com/hercules/nac-refman.html (HTML format)

and here:

http://www.nkavvadias.com/hercules/nac-refman.pdf (PDF format).

The developer will be required to:

1) Develop the backend as part of the LLVM 3.3 version (latest release) or the current mainline (which ever is deemed more appropriate). You will be required to deliver all the necessary code, and transfer copyright to Ajax Compilers. You will be requested to not disclose the code to any third party or reuse it for your own projects. These requirements will all be described in the context of a legal document (contract + NDA). Further, you will be requested to not use any code repository allowing public access.

2) Translate valid LLVM IR to NAC. Please note that NAC: a) does not support structs and unions, b) arrays are single-dimensional. For this reason you will need to use the LLVM infrastructure for struct/union decomposition and array flattening. This is also the situation for classic hardware targets, e.g. RISC machines. On the other side, NAC supports custom floating-point arithmetic, so both float and double arithmetic should be supported (long doubles is not an immediate priority).

3) In case that this is mandatory and no other alternative exists, make suggestions for updating the NAC specification in order to better match the LLVM IR.

4) We expect that the working NAC backend will be able to process realistic, large-scale ANSI/ISO C codes. We suggest that you use the CHStone test suite: http://www.ertl.jp/chstone/ for evaluation; all these codes should produce valid NAC. Please use clang for C-to-LLVM translation.

You may choose to use the tblgen tool for backend development. Among the existing LLVM backends in the official release, the PTX backend may be considered somewhat close to NAC since it is an "abstract" machine as well. On the other side, the approach used by the LLVM 3.0 C backend (custom backend not using tblgen) or the up-to-date C++ (Cpp) backend may also be viable.

In case you are interested:

1) Please let us know of your flat rate for the entire project.

2) We expect that you will work full-time (100%) or near full-time (75%) on the LLVM-NAC project.

3) Give us your estimate for the project duration. Our own educated guess is that for an LLVM expert, NAC backend development will require something between 6 to 12 weeks. Thus the proposed contract is for a 2 or 3 month duration. However, this can also be negotiated.

We can also supply you with additional helper materials and tools such as:

- EBNF NAC grammar.
- NAC yacc/bison grammar.
- NAC lex/flex scanner.
- NAC grammar for the Gold Parsing System.
- TXL grammar for NAC.
- Numerous examples of C code translated to NAC using our prototype C frontend.
- Numerous examples of handwritten NAC programs.
- A NAC-to-C backend tool to help you with evaluating the behavior NAC programs.

Yours sincerely,
Nikolaos Kavvadias <nkavvadias@ajaxcompilers.com>
Ajax Compilers
Athens, Greece