I'm currently try to replace my old volatileLoad/Store functions that utilized a `shared` bug as an alternative to `volatile`.  The used to look like this:

@inline T volatileLoad(T)(T* a)
{
    asm { "" ::: "memory"; };
    return *cast(shared T*)a;
}
@inline void volatileStore(T)(T* a, in T v)
{
    asm { "" ::: "memory"; };
    *cast(shared T*)a = v;
}

Now I'm implementing them like this:

private T volatileLoad(T)(T* a)
{
    static import core.bitop;
    static if (T.sizeof == 1)
    {
        return cast(T)core.bitop.volatileLoad(cast(ubyte*)a);
    }
    else static if (T.sizeof == 2)
    {
        return cast(T)core.bitop.volatileLoad(cast(ushort*)a);
    }
    else
    {
        return cast(T)core.bitop.volatileLoad(cast(uint*)a);
    }
}

private void volatileStore(T)(T* a, in T v)
{
    static import core.bitop;
    static if (T.sizeof == 1)
    {
        core.bitop.volatileStore(cast(ubyte*)a, cast(ubyte)v);
    }
    else static if (T.sizeof == 2)
    {
        core.bitop.volatileStore(cast(ushort*)a, cast(ushort)v);
    }
    else
    {
        core.bitop.volatileStore(cast(uint*)a, cast(uint)v);
    }
}

I have the volatileLoad/Store functions declared in a core.bitop file like so:

module core.bitop;

ubyte  volatileLoad(ubyte * ptr);
ushort volatileLoad(ushort* ptr);
uint   volatileLoad(uint  * ptr);
ulong  volatileLoad(ulong * ptr);

void volatileStore(ubyte * ptr, ubyte  value);
void volatileStore(ushort* ptr, ushort value);
void volatileStore(uint  * ptr, uint   value);
void volatileStore(ulong * ptr, ulong value);

However, when I compile, the intrinsics don't appear to be emitted and I get an undefined reference at link-time. core/bitop.d is located in source/runtime which is imported with the switch -Isource/runtime.

arm-none-eabi-gdc -c -O0 -nophoboslib -nostdinc -nodefaultlibs -nostdlib -fno-emit-moduleinfo -mthumb -mcpu=cortex-m4 -Isource/runtime -fno-bounds-check -fno-invariants -fno-in -fno-out -ffunction-sections -fdata-sections source/gcc/attribute.d source/board/lcd.d source/board/ILI9341.d source/board/package.d source/board/statusLED.d source/board/ltdc.d source/board/random.d source/board/spi5.d source/stm32f42/nvic.d source/stm32f42/gpio.d source/stm32f42/flash.d source/stm32f42/scb.d source/stm32f42/spi.d source/stm32f42/pwr.d source/stm32f42/ltdc.d source/stm32f42/trace.d source/stm32f42/rcc.d source/stm32f42/bus.d source/stm32f42/rng.d source/stm32f42/dma2d.d source/stm32f42/mmio.d source/main.d -o binary/firmware.o

arm-none-eabi-ld binary/firmware.o -Tlinker/linker.ld --gc-sections -o binary/firmware
binary/firmware.o: In function `_D8stm32f424mmio21__T13volatileStoreTbZ13volatileStoreFPbxbZv':
attribute.d:(.text._D8stm32f424mmio21__T13volatileStoreTbZ13volatileStoreFPbxbZv[_D8stm32f424mmio21__T13volatileStoreTbZ13volatileStoreFPbxbZv]+0x12): undefined reference to `_D4core5bitop13volatileStoreFPhhZv'

Analyzing the object file I see this: arm-none-eabi-nm binary/fimrware.o

U _D4core5bitop12volatileLoadFPhZh
U _D4core5bitop12volatileLoadFPkZk
U _D4core5bitop12volatileLoadFPtZt
U _D4core5bitop13volatileStoreFPhhZv
U _D4core5bitop13volatileStoreFPkkZv
U _D4core5bitop13volatileStoreFPttZv

Am I doing something wrong?

Thanks,
Mike

On 18 July 2017 at 22:41, Mike via D.gnu <d.gnu@puremagic.com> wrote:
>
> Analyzing the object file I see this: arm-none-eabi-nm binary/fimrware.o
>
> U _D4core5bitop12volatileLoadFPhZh
> U _D4core5bitop12volatileLoadFPkZk
> U _D4core5bitop12volatileLoadFPtZt
> U _D4core5bitop13volatileStoreFPhhZv
> U _D4core5bitop13volatileStoreFPkkZv
> U _D4core5bitop13volatileStoreFPttZv
>
> Am I doing something wrong?
>

Yes, the signature it looks for is FNbNiNf for volatileLoad and FNbNiNf for volatileStore.  That is nothrow, @nogc and @safe attributes respectively.

Just after module core.bitop; line, add:

nothrow:
@safe:
@nogc:

Regards
Iain.

On Tuesday, 18 July 2017 at 20:54:26 UTC, Iain Buclaw wrote:
> Just after module core.bitop; line, add:
>
> nothrow:
> @safe:
> @nogc:
>

Thanks, and sorry for the foolish mistake.  I'm getting a working binary now. Well, at least my status LED is blinking and I see my LCD screen trying to do something, though not the random rectangles I was expecting.  I suspect it's just a matter of debugging my hardware initialization procedures now.  I hope I'll have something to show soon, though I may need to obtain some new hardware.

Mike