bigcheesegs

That may be the point, but it's not the premise. Even the title is based on this flawed idea. If the author wants to make a point, they can do so without trying to drive it with incorrect ideas.

Yet again someone ignoring the line:

> for which the Standard imposes no requirements.

C89 had no requirements, C99 clarified that the line that followed was non-normative.

The entire premise of this article is flawed.

Apple Clang gets its own column because it doesn't align with the official LLVM release schedule, which is also why it doesn't use the upstream version numbers.

The Model X and Model S do not have this camera.

It's the overhead VS. passing a raw pointer. The itanium ABI says that std::unique_ptr has to be passed by address due to its special member functions (the ABI doesn't know if it stores a pointer to itself).

Compilers have an attribute to remove this overhead, but it's an ABI break to do it.

The best part about Facebook's preprocessor (warp) was that it was slower than Clang (https://news.ycombinator.com/item?id=7489532).

But the preprocessor isn't what makes compiling C++ slow. It's a combination of the complex grammar, and ahead of time optimization of a (mostly) static language. Turns out you can compile code really fast if you don't actually try to optimize it.

What do you mean by wild compiler hacks?

It still causes confusion, even on the committee. stdlib is non ambiguous, short, and easy to say.

Nothing in C++20 contracts requires any checking to be done at compile time. The only options currently required are runtime checking and no checking.

The first example is handled by constinit (or whatever we end up calling it) and the second is handled by consteval, although it has to be put in a function.

constexpr functions aren't restricted to compile time, they can also be used at runtime. Thus constexpr functions can show up in the final executable. Constexpr functions can also control what gets compiled in the first place. For example you can use the result of a constexpr evaluation to instantiate a template.

Yeah, on variable decls it does indeed mean const. It also means inline on functions and static data members (but not global variables).

constexpr evaluation results are needed in the frontend long before LLVM IR ever comes into the picture.

Also, people have done interesting things in constexpr that currently suffer from slow compile times: https://github.com/hanickadot/compile-time-regular-expressio...

That risk has nothing to do with this work. That's an inherent risk with compile time evaluation.

C++ defines constant evaluation to be the same as normal evaluation, although C++20 is adding a way to tell when you're evaluating at compile time so you can avoid things like inline asm at compile time.

constexpr doesn't even mean const_statement. All it means is don't emit an error if constant evaluation calls this function.

Google has been a contributor to LLVM for about 10 years, and a major contributor for most of that time.

At no point have they tried to force something into LLVM that goes against the wishes of the community. They have always worked with the LLVM community to improve LLVM, and LLVM has benefited greatly from Google's contributions. I expect this project to be no different.

Correct. clang is always going to default to targeting whatever the platform ecosystem is. I don't see linux distros moving away from glibc any time soon.

The notion that a LLVM libc would in some way make other libc's "second class" is completely unfounded. libc++ vs. libstdc++ is proof of this.

A major issue with removing UB exploitation is that you've now created C, but each compiler implements a different C. It becomes harder to port code, and you end up with bugs that can be harder to catch, especially if don't consider what you're doing an error, as now you can't even use the sanitizers.

What my team has been looking at to help developers that have these issues is providing low overhead ways to give defined, but likely to crash, behavior for these cases. This helps protects against UB without creating C. An example would be variable auto-init, which intentionally doesn't support zero init, as that is likely to hide bugs: https://reviews.llvm.org/D54604

I'm fine with fully defining some things that are currently UB or IB. I'm also fine with keeping things as UB. What I'm not fine with is creating this implicit C that programmers think they know what it is, but it's not actually defined anywhere, and not everyone working on the compiler is on the same page about.

Implementation defined behavior isn't actually any easier to reason about. Compilers are free to choose "assumes this never happens" as their behavior, as there is no limit on what can happen. This is different from implementation defined value or unspecified behavior (which generally has a list of options).

Use a variant type like llvm::Expected.

This has always been a problem in talking about modules in C++. Everyone has a different idea of what a module is.

Currently every compiler except MSVC plans to make module files version locked. Different versions of the same compiler will use different module files.

Personally I find little value in portable module files, as you need to be able to rebuild modules anyway to handle pretty much any change to compile flags.

He was previously. The current EWG Chair is Ville Voutilainen.

Modules are not a build system. You will still need a build system to build real C++ code.

The idle checks all happen in the kernel scheduling code which runs on every CPU/core/hyperthread between doing real work. There isn't a separate core which hands out work or controls them. The kernel knows which CPUs are active because it's the one running things, not because it asks the CPU if it ran any code.

On a single CPU system it works because when the current process stops running (calls sleep, does IO, etc...) the kernel looks to see if there's anything else to do, if not, it knows the system is now idle.

Don't use reinterpret_cast for type-punning in c++, you'll end up with UB. You should instead use memcpy.

The problem with this kind of approach is over time it removes the ability to use any other implementation. You are no longer using C, you are using <Implementation>C.

This becomes a problem when a different implementation adds amazing tools for finding bugs (the sanitizer suite, for instance), and you can't use them because your code doesn't build with any other implementation.

> N.B. Accessing registers modified by the hardware may be treated as a multi-threaded application. Therefore, it is worth considering using std::atomic<T> instead of volatile T.

This is incorrect. Compilers are allowed to reorder and combine atomics as long as they follow the rules. See: https://github.com/jfbastien/no-sane-compiler

There's more to it than that. C++ is designed for implementations to produce fast code. "Leave no room between C++ and Assembly" has been a guiding principle of C++. This is not true of Python, and thus the engineering effort required for an implementation to reach the same level of performance is huge, if at all possible.

Rust is the first language I've seen that even has a chance though.

It's by design that you need a meta-build system. Ninja build files were not designed to be written by hand, not even ninja itself has hand written ninja files.

clang-cl is just a compiler. It relies on VS to provide the C and C++ standard libraries. VS 2017 has the filesystem library and it should work with clang-cl 6.