5.2 and "static attibute(section..."

Hi Uwe,

It looks to me as if this is intended behavior, since 'a' is static and this compilation module (file) only writes to it. Adding a 'getter' will force the compiler to keep 'a'.

Any particular reason you would want to keep 'a' in this example?

As to why 5.2 drops it and previous versions didnt, I assume it's due to a new optimization. See https://gcc.gnu.org/gcc-5/changes.html

"* Inter-procedural optimization improvements:
...
     * Write-only variables are now detected and optimized out."

Hope that answers your question.

Cheers,
Andre

"Any particular reason you would want to keep 'a' in this example?"

For my case (ethernut/nut/arch/cm3/cmsis/cortex_init.c) the variable
in question is the interrupt table in RAM.
__attribute__((section(".vtable")))
void (*g_pfnRAMVectors[NUM_INTERRUPTS])(void*);

For M0_plus and M3/M4 remapping tha table with
 SCB->VTOR = (uint32_t)g_pfnRAMVectors;
is the getter.

For STM32F0, VTOR is not available. However memory at 0x20000000
may be remapped to 0x0 with
    SYSCFG->CFGR1 |= SYSCFG_CFGR1_MEM_MODE;
so there is no explicit getter.

So this change unexpectedly broke STM32F0 interrupt handling for me.

At least a warning about the unused variable should have been emitted.

Hi Uwe,

I understand your frustration. Unfortunately -Wunused-but-set-variables doesnt pick this one up. You could try asking upstream for such a warning when this optimization is done. I don't know if there was a reason not to or whether no one thought of doing it.

As for the test case above, adding volatile to 'a' would prevent it from being optimized away.

I couldn't completely follow your use case but it sounds to me like the cmsis code should be updated to make sure whatever the 'a' equivalent is there, does not get optimized away.

Hope this helps.

Cheers,
Andre

I already updated the code to omit the "static".

I am not going to report upstream. The problem is to deep into the intrinsics of compiler for me...

I suggest you still use volatile though, I suspect '-flto' will still optimize away 'a' if it is not volatile. Using volatile here will guarantee the optimization would be semantically incorrect.

You probably mean s/incorrect/correct?

Thanks Andre Vieira, that solved my question.