optimization option doesn't work as expected

Bug #1853865 reported by Hamidreza Shariati on 2019-11-25
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
GNU Arm Embedded Toolchain
Undecided
Unassigned

Bug Description

Our cpu is cortex M33 with DSP extension and FPU.
When optimization -O2 or -Os are used with toolchain:
arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 9-2019-q4-major) 9.2.1 20191025 (release) [ARM/arm-9-branch revision 277599]

it doesn't work as expected. Since we are running a big Bluetooth stack, it is not easy to localize any issue that is exposing.

To mitigate the issue I used:
arm-none-eabi-gcc (xPack GNU ARM Embedded GCC, 64-bit) 8.3.1 20190703 (release) [gcc-8-branch revision 273027]

that has only one bug but the rest works well.

FYI: the same code on CM3 works with any toochain.

If I use:
arm-none-eabi-gcc -mcpu=cortex-m33 -march=armv8-m.main -mthumb -mfloat-abi=hard -mfpu=fpv5-sp-d16

instead of
arm-none-eabi-gcc -mcpu=cortex-m33 -march=armv8-m.main+dsp -mthumb -mfloat-abi=hard -mfpu=fpv5-sp-d16
that means removing dsp extension, then bot toolchain work correctly with optimizations.

I have the following questions:
1- Is there any known bug when optimization is used with ARM or GNU toolchain for CM33+dsp?
2- What is the correct compile options when CM33+dsp+fpu is used?
3- If it helps I can share a piece of code to show the issue?

Thank you
Hamid

Hamidreza Shariati (hrshariati) wrote :

Here is the function that shows the issue:

__INLINE void co_write16p(void const *ptr16, uint16_t value)
{
    uint8_t *ptr=(uint8_t*)ptr16;

    *ptr++ = value&0xff;
    *ptr = (value&0xff00)>>8;
}
....

            while(val != NULL)
            {
                // copy element value
                co_write16p(&(data[cursor]), val->shdl);
                cursor += ATT_HANDLE_LEN;
                co_write16p(&(data[cursor]), val->ehdl);
                cursor += ATT_HANDLE_LEN;
                memcpy(&(data[cursor]), val->value, val->length);
                cursor += val->length;

                // next element
                val = val->hdr.next;
            }

val is pointer to void and data is uint8_t

when it goes to co_write16p(), it writes on the first two bytes but then instaed of writing on the third and fourth bytes (addresses), it writes again on the first and second bytes on the second calling of co_write16p().

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers