[cfe-dev] Cortex-M4F Assembly Code Generation Incorrect for float casting, causing HardFaults

Dan Walmsley via cfe-dev cfe-dev at lists.llvm.org
Thu Aug 10 07:25:54 PDT 2017


Well I can workaround by marking the method with:
__attribute__ ((optnone))

I would expect code that compiles with no optimizations to work with optimizations on clang. (if it were bug free 😉)

Also this bug also shows up if you use uint32 so not limited to floats.

So its not currently possible to read a uint32 value from a buffer at an unaligned position. This should work shouldn’t it?

The issue is with using VLDR instruction.

Thanks

Dan

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

From: mats petersson<mailto:mats at planetcatfish.com>
Sent: 10 August 2017 15:21
To: Dan Walmsley<mailto:dan at walms.co.uk>
Cc: Hans Wennborg<mailto:hans at chromium.org>; cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>
Subject: Re: [cfe-dev] Cortex-M4F Assembly Code Generation Incorrect for float casting, causing HardFaults

Does the C and C++ standards not state that loading a value from an unaligned addres (e.g. float from an address not aligned to 4) is undefined behaviour?
I'm not saying SO is the definitive reference for this, but it would seem like it says so, with a reference to the spec:
https://stackoverflow.com/questions/28893303/is-a-misaligned-load-due-to-a-cast-undefined-behavior

Whilst it may well be that this "works" on some archiectures (particularly x86), I do believe it's perfectly valid to produce code that assumes aligned data.
Or am I missing something on the subject?

--
Mats

On 10 August 2017 at 14:50, Dan Walmsley via cfe-dev <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>> wrote:

If have filed a bug here:



https://bugs.llvm.org/show_bug.cgi?id=34143

From: cfe-dev <cfe-dev-bounces at lists.llvm.org<mailto:cfe-dev-bounces at lists.llvm.org>> on behalf of Dan Walmsley via cfe-dev <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>>
Sent: 10 August 2017 13:41:39
To: cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>; Hans Wennborg
Subject: [cfe-dev] Cortex-M4F Assembly Code Generation Incorrect for float casting, causing HardFaults


Basically the following code can repro the issue:



Compile flags are:

Wall -c -fshort-enums -ggdb3 -std=c++14 -fno-rtti -fno-exceptions -mfpu=fpv4-sp-d16 -mfloat-abi=hard -mfpu=fpv4-sp-d16 -mfloat-abi=hard -ffunction-sections -fdata-sections -O1 -target arm-none-eabi -mcpu=cortex-m4 -mthumb



code to reproduce is:



```

template <typename T> inline T Read (uint8_t* data)
{
    auto valuePtr = reinterpret_cast<T*> (data);

    auto value = *valuePtr;

    return value;
}

static float test = 180.0f;

int main (void)
{
    uint8_t* data = new uint8_t[8];

    memcpy (data, &test, sizeof (float));

    auto value = Read<float> (data);



    memcpy (data + 1, &test, sizeof (float));

    value = Read<float> (data + 1); // hard fault here!

    return value;
}

```



My diagnosis is that when it dereferences the float pointer it uses the VLDR instruction, https://developer.arm.com/docs/100069/0607/advanced-simd-instructions-32-bit/vldr



This instruction can only be used on word aligned boundaries.



So It works for first call to my Read method, but the second call which is not aligned, it crashes.



Not sure who is the right person to fix this.



I will reply with  a bug, once I manage to login to the bug database.
Thanks

Dan



_______________________________________________
cfe-dev mailing list
cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170810/487f7f5c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: C4A00CD5A20340FE86C8B91EC77895FB.png
Type: image/png
Size: 158 bytes
Desc: C4A00CD5A20340FE86C8B91EC77895FB.png
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170810/487f7f5c/attachment.png>


More information about the cfe-dev mailing list