Play Compiler++
Sign in to queue


In order to successfully deliver new and innovative C++ compiler technology on a regular basis, compiler vendors must respond to yearly microprocessor advancements. Additionally, the C++ language continues to evolve (and at a faster pace than ever before) with new standards such as C++11, C++14 , and C++17.  Combined, the constant evolution of hardware, language, and tooling adds a great deal of complexity to an already complicated task: shipping innovative compiler technology at a predictable (and suitably fast) rate, while coming extremely close to providing "mission critical correctness."  This talk will provide deep insights into the details of delivering automatic parallelism from unaltered C++, scalar optimization to address code size in Windows, and security features in the latest generation of the VC++ compiler. Finally, Jim will introduce some compiler technologies that are currently in development; one's that might soon see the light of day. This should provide a peek under the covers for users as well as hardware manufacturers and language designers.







Download this episode

The Discussion

  • User profile image

    Ah, Roslyn for C++ ? Devil Phoenix Resurrection ??? Angel

  • User profile image

    The material was great, but the speed of delivery and expectations of the audience were far too low.

  • User profile image
    daniel kluss

    Why doesnt maskmovdqu on x86 work for masked stores when vectorizing conditionals?

  • User profile image

    With AVX2 you can use VPMASKMOV* and VMASKMOV* to load/store with masks.

  • User profile image
    Arne Vogel

    53:54 "makes sense?" – In fact, not a lot. A conversion from T ** to U ** is already forbidden for T != U. Even just adding a const is forbidden (except for at the top level or at the level of the first indireciton, i.e. T ** -> T **const or T ** to T *const *).

    In fact, the comp.lang.c FAQ has answered the question "Why cannot I convert a char ** to a const char **?" decades ago.

    (As far as assigning to a pointer (whether through dereferencing a pointer-to-pointer or not), the conversion options are also limited, i.e. you can add const or volatile, and convert to an unambiguous accessible base class.)

    Here is a simple example on showing how a conversion to base type is not allowed for the double indirection case:

    I chose MSVC for obvious reasons, but all other major compilers should and do reject this code because of the possibility of subverting the type system.

    Also, you can easily warn about bad code even if it is legal. This is not a conformance issue. At worst, your users might be upset if there are too many false positives.

    I do think you have a point that disproving aliasing is a very hard problem in C++, but the examples given are not correct, and do not do your talk a service.

Add Your 2 Cents