Out of curiosity, is the first rule a win or canonicalisation?

Are you sure about std::set?
https://llvm.org/docs/ProgrammersManual.html#set

You could just a a file to clang docs with:
Clang assumes that memcpy(p, p, n) is safe.

How about making it explicit: The source location and the destination location may overlap.

How about a malformed module map is not loaded and gives no errors?

When you extended the thread pool for high cores counts for Windows, I thought the other way around. I want to you use the distributed thinlto locally. Then each ninja job is single threaded and ninja can schedule everything. This probably won't be a desirable solution for Windows.

You can buy a PRIMEHPC FX700 from Fujitsu. It has a A64FX CPU with SVE.

No worries. I added @ributzka and @cishida as reviewers because they should know.

Here is v530:
https://opensource.apple.com/tarballs/ld64/ld64-530.tar.gz

Do you want to add something similar to:
https://github.com/llvm/llvm-project/blob/master/llvm/unittests/TextAPI/TextStubV4Tests.cpp#L593
for DriverKit?

You can add DriverKit here:
https://github.com/llvm/llvm-project/blob/master/llvm/include/llvm/TextAPI/MachO/Platform.h#L33
and here:
https://github.com/llvm/llvm-project/blob/master/llvm/include/llvm/BinaryFormat/MachO.h#L499

I don't know whether the name of your downstream target is a secret. Wouldn't it help you to add a fake 16bit per char target to clang and add units tests to prevent regressions?

And you can write it as

auto_ptr is deprecated since C++11 and will be removed in C++17.

Sorry. I meant ABI. Can link GCC .o files with Clang .o files using the attributes?

I would appreciate it, if somebody could commit this patch on my behalf.
Thorsten Schuett
schuett@gmail.com

Stupid questions.

• Is it for convenience? You get arrays, global variables, structs, ... . Vectorization becomes easier ...
• Are there any potential performance benefits over scalable vectors?
• Is it compatible with GCC?

added missing "alignment"

I wanted to save space. I know that the alignment is missing there, but the line is already too long.

add/updated test

introduced in https://reviews.llvm.org/D45319

Replaced (...) by ;

Feel free to ignore: "On Subnormal Floating Point and Abnormal Timing"
http://www.ieee-security.org/TC/SP2015/papers-archived/6949a623.pdf

Mach-O is my toy project. The real one will be COFF/Windows.

Now, I realized that I cannot use/develop malloc/free redirectors on Darwin.

I see, but this solution seems to be a very Linux/ELF way of doing it. I could not find anything similar for Mach-O.

• fixed linting
• minimal entry point

See the c++ core guide rules:
http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rh-override

There was a redirector for the round function:
https://reviews.llvm.org/D69020

See below:
https://github.com/llvm/llvm-project/blob/master/libc/docs/redirectors.rst

Pardon my cmake, but don't you need a CMakeLists.txt in the GISel sub-directory?

You could try:

clangxx_host -Xclang -fdump-record-layouts %p/Inputs/layout.cpp -emit-llvm -o /dev/null

AArch64 has a sub-directory for GlobalISel related things:
https://reviews.llvm.org/D81116

In D82923#2126259, @jyknight wrote:

I suggest removing the extraneous level of directory "Darwin" -- just put the files in "llvm/tools/llvm-libtool-darwin", name the source "llvm-libtool-darwin.cpp", and say you're adding "llvm-libtool-darwin" in the commit message.

While it's weird to have a darwin-specific tool for creating archives and shared libraries, that's the status quo. And moving that to an LLVM implementation is entirely reasonable. Let's just not pretend this is ever going to be something else other than that.

Maybe the linting problem is not unique to Darwin, but highlights a more general problem with this approach. So far development was limited to Linux.

I don't know whether linking without systemb is supported at all, but LLVM libc is designed to be layered on top of the system libc. It seems to be a problem of the include order.

Did you miss the aarch64 entry points?

Does this change undo https://reviews.llvm.org/rG050ed9720f84343d859c530b8b692eb6141e6a63 ?

Notes:

• llvm-objcopy cannot do aliases for Mach-O. It can only rename symbols.
• ld64 supports an alias_list option to create aliases. It would probably require the mangled names.
• clang does not support the alias attribute for Darwin.
• use llvm-readobj to extract the mangled names from the entry point sections.

add missing include

some cmake improvements

copy and paste api.td from linux ...

Add a redirector for malloc/free as a temporary solution?

https://opensource.apple.com/source/ld64/ld64-530/doc/man/man1/ld.1.auto.html
https://opensource.apple.com/source/ld64/ld64-530/

Neither PlatformType nor PlatformKind cover all cases of -platform_version, but TextAPI uses PlatformKind.

Shouldn't "kRepMovsBSize = -1" be "kRepMovsBSize =SIZE_MAX"?

Would it help the reader to say: The function is written in pure C++ *and not in assembler/intrinsics* for several reasons:

No worries. I just wanted to point out that there are other efforts to define floating-point behaviour beyond fast-math.

constrained math: https://llvm.org/docs/LangRef.html#constrained-floating-point-intrinsics

I watched the talk, but I still prefer compile-time errors over runtime crashes.

As an outsider: In Swift, reading an uninitialized variable is a compile-time error. Clang is not powerful enough to do this analysis. Aren't you really looking for the Clang Intermediate Language (CIL) ?

Do what ever you want, but I would go with the slow and safe strlen implementation until somebody proves that strlen is a performance issue.

Sorry, my mistake. With "avoid the sanitizer dancing" I meant that the compiler should do the instrumentation instead of doing it manually, which is error-prone.

I am starting to believe that it is better to stay with the slow and safe strlen implementation. Avoid the sanitizer dancing. Spend more energy on adding features. So that people start using this libc. Then you can use a profiler to find the hot functions.

Pattern matching? Most compilers can recognize matrix-matrix multiplication. It bit me once.
It might eventually learn these SIMD patterns.

No worries. I am only afraid that a future compiler detects the UB and starts to optimize.

glibc is doing it in a similar way. It exhibits the same UB.
https://sourceware.org/git/?p=glibc.git;a=blob;f=string/strlen.c;h=f934e1a1e897c0176c04566a182f092dc1ab2a37;hb=HEAD

AddressSanitizer is already unhappy about EmptyString.

Some stylistic improvements.

Added SevenBytes and SixBytes

For reference, this was also discussed in https://reviews.llvm.org/D77279.

Unfortunately, this fails on OSX when ${LIBC_TARGET_OS} == "darwin" in libc/test/config/CMakeLists.txt. Windows might have a similar problem. I have no intent building libc. It fails with having libc in LLVM_ENABLE_PROJECTS.

No worries.

Thanks for doing that! But it looks odd to attach the dependencies to the output file.

How does it relate to the -MJ option?

Are you planning to do this recursively?
The minimizer does not help much for the following example, while Sema.h contains 10,000 lines of useless code.

#include "clang/Sema/Sema.h"

Thx, for doing this. Are you planning to do a follow up for Clang? I have been hacking this myself locally.

Is it possible that the tests were excluded from the commit?