Missing Features (The GNU D Compiler)

### 2.12 Missing Features and Deviations ¶

Some parts of the D specification are hard or impossible to implement with GCC, they should be listed here.

Bit Operation Intrinsics

  The Digital Mars D compiler implements the `core.bitop` intrinsics `inp`, `inpw`, `inpl`, `outp`, `outpw`, and `outpl`. These are not recognized by GNU D. On most targets, equivalent intrinsics that have the same effect would be `core.volatile.loadVolatile` and `core.volatile.storeVolatile` respectively (see Volatile Intrinsics).

  On x86 targets, if an `in` or `out` instruction is specifically required, that can be achieved using assembler statements instead.

      ubyte inp(uint port)
      {
          ubyte value;
          asm { "inb %w1, %b0" : "=a" (value) : "Nd" (port); }
          return value;
      }

      void outp(uint port, ushort value)
      {
          asm { "outb %b0, %w1" : : "a" (value), "Nd" (port); }
      }

Floating-Point Intermediate Values

  GNU D uses a software compile-time floating-point type that assists in cross-compilation and support for arbitrary target `real` precisions wider than 80 bits. Because of this, the result of floating-point CTFE operations may have different results in GNU D compared with other D compilers that use the host’s native floating-point type for storage and CTFE. In particular, GNU D won’t overflow or underflow when a target real features a higher precision than the host. Differences also extend to `.stringof` representations of intermediate values due to formatting differences with `sprintf("%Lg")`.

      version(GNU)
          assert((25.5).stringof ~ (3.01).stringof == "2.55e+13.01e+0");
      else
          assert((25.5).stringof ~ (3.01).stringof == "25.53.01");

Function Calling Conventions

  GNU D does not implement the `extern(D)` calling convention for x86 as described in the D specification hosted at https://dlang.org/spec/abi.html#function_calling_conventions.

  Instead, there is no distinction between `extern(C)` and `extern(D)` other than name mangling.

ImportC Limitations

  GNU D does not run the preprocessor automatically for any ImportC sources. Instead all C files are expected to be manually preprocessed before they are imported into the compilation.

Inline Assembler

  GNU D does not implement the D inline assembler for x86 and x86_64 as described in the D specification hosted at https://dlang.org/spec/iasm.html. Nor does GNU D predefine the `D_InlineAsm_X86` and `D_InlineAsm_X86_64` version identifiers to indicate support.

  The GNU D compiler uses an alternative, GCC-based syntax for inline assembler (see Inline Assembly).

Interfacing to Objective-C

  GNU D does not support interfacing with Objective-C, nor its protocols, classes, subclasses, instance variables, instance methods and class methods. The `extern(Objective-C)` linkage is ignored, as are the `@optional` and `@selector` attributes. The `D_ObjectiveC` version identifier is not predefined for compilations.

Pragma Directives

  Pragmas that are designed to embed information into object files or otherwise pass options to the linker are not supported by GNU D. These include `pragma(lib)`, `pragma(linkerDirective)`, and `pragma(startaddress)`.

SIMD Intrinsics

  The Digital Mars D compiler implements the `core.simd` intrinsics `__simd`, `__simd_ib`, `__simd_sto`. These are not recognized by GNU D, nor does GNU D predefine the `D_SIMD` version identifier to indicate support.

  On x86 targets, all intrinsics are available as functions in the `gcc.builtins` module, and have predictable equivalents.

      version (DigitalMars)
      {
          __simd(XMM.PSLLW, op1, op2);
          __simd_ib(XMM.PSLLW, op1, imm8);
      }
      version (GNU)
      {
          __builtin_ia32_psllw(op1, op2);
          __builtin_ia32_psllwi(op1, imm8);
      }

TypeInfo-based va_arg

  The Digital Mars D compiler implements a version of `core.vararg.va_arg` that accepts a run-time `TypeInfo` argument for use when the static type is not known. This function is not implemented by GNU D. It is more portable to use variadic template functions instead.