Bug in GCC 4.9.4 eabi VLE PowerPC

Showing results for 
Search instead for 
Did you mean: 

Bug in GCC 4.9.4 eabi VLE PowerPC

Contributor III

Dear NXP Team,

Starting some investigations of the multi-core MPC5748G I ran into a
compiler bug. I'm using the S32 Design Studio 2017 R1, the compiler is GCC
4.9.4 as packaged with the S32DS.

Here are compiler command line and compilation output:

Compiling DEVKIT-MPC5748G-startup for production
Compiling C file code-Z2/mzt_main_Z2.c for Z2
C:/ProgramFiles/NXP/s32ds_power_v2017.r1/Cross_Tools/powerpc-eabivle-4_9/bin/powerpc-eabivle-gcc.exe -c -mbig-endian -mvle -misel=yes -meabi -msdata=default -G8 -mregnames -fshort-double -fsingle-precision-constant -mcpu=e200z2 -msoft-float -mno-string -fno-common -fno-exceptions -ffunction-sections -fdata-sections -fshort-enums -fdiagnostics-show-option -finline-functions -fmessage-length=0 -fzero-initialized-in-bss -fno-tree-loop-optimize -Wall -Wno-main -Wno-old-style-declaration -Winline -Wextra -Wstrict-overflow=4 -Wmissing-declarations -Wno-parentheses -Wdiv-by-zero -Wcast-align -Wformat -Wformat-security -Wignored-qualifiers -Wsign-conversion -Wsign-compare -Werror=missing-declarations -Werror=implicit-function-declaration -Wno-nested-externs -Werror=int-to-pointer-cast -Werror=pointer-sign -Werror=pointer-to-int-cast -Werror=return-local-addr -Werror=missing-prototypes -Werror=missing-field-initializers -specs=nosys.specs --sysroot=C:/ProgramFiles/NXP/s32ds_power_v2017.r1/Cross_Tools/powerpc-eabivle-4_9/powerpc-eabivle/newlib -MMD -Wa,-a=bin/ppc/PRODUCTION/obj/mzt_main_Z2.lst -std=gnu11 -Icode-Z2 -Icode-Z4 -Icode-Z4/startup -DPRODUCTION -DNDEBUG  -save-temps=obj -fverbose-asm  -g1 -gdwarf-2 -Os -o bin/ppc/PRODUCTION/obj/mzt_main_Z2.o code-Z2/mzt_main_Z2.c
code-Z2/mzt_main_Z2.c: In function 'mzt_main_Z2':
code-Z2/mzt_main_Z2.c:171:12: warning: conversion to 'unsigned int' from 'int' may change the sign of the result [-Wsign-conversion]
            ++ mzt_cntMainLoopsCore2;
code-Z2/mzt_main_Z2.c:171:12: warning: right-hand operand of comma expression has no effect [-Wunused-value]
code-Z2/mzt_main_Z2.c:181:1: error: insn does not satisfy its constraints:
 } /* End of mzt_main_Z2 */
(insn 92 64 24 6 (set (reg:SI 31 %r31)
        (symbol_ref:SI ("mzt_cntMainLoopsCore2") [flags 0x86] <var_decl 03f53c60 mzt_cntMainLoopsCore2>)) code-Z2/mzt_main_Z2.c:171 1154 {*movsi_vle}
code-Z2/mzt_main_Z2.c:181:1: internal compiler error: in reload_cse_simplify_operands, at postreload.c:411
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

The source code has been attached as preprocessed file for easy
reproducibility. The tiny portion of my failing code can be found at the
very end of this file. Basically it is no more than:

_Atomic unsigned int mzt_cntMainLoopsCore2 = 0;
void _Noreturn mzt_main_Z2( signed int noArgs __attribute__((unused))
                          , const char *argAry[] __attribute__((unused))
        unsigned int u;
        for(u=0; u<7500000; ++u)
            ++ mzt_cntMainLoopsCore2; // Line 171
} // Line 181

The same C code compiles and executes in debug compilation. The relevant
differences in the compiler switches are: "-g3 -gdwarf-2 -Og" instead of
"-g1 -gdwarf-2 -Os"

The last point lets this issue appear a code optimizer problem. I tried
different optimizer settings. We get the same error with -Os, -Ofast, -O3
and -O2 but not with -O1 and -Og.

Note: The bad warning about signed/unsigned mismatch seems to be an
unrelated, second issue; it is emitted in the otherwise successful
debug compilation, too.

0 Kudos
2 Replies

NXP Employee
NXP Employee

A combination of optimization, atomic access, and small data area trigs this error.

It can be reproduced with the following code and compiling with options: -S -std=gnu11 -msdata -Os

extern _Atomic unsigned int v;
void foo (void)

{ ++v; }


It turns out that support for small data area with VLE is incomplete. I am testing a fix. If no regressions is found, it will be on the next release. 

Meanwhile, a work around is to not allocate atomic variables into small data area.

0 Kudos

NXP Employee
NXP Employee

Thank you for your report. I'll create a ticket for this.


0 Kudos