PowerPC VLE GCC: Compiler Bug, invalid Instruction emitted

[peter_vranken]

Dear NXP Team,

Compiling a C source file using your GCC for PPC VLE we encountered a problem. The compiler successfully completed but the assembler rejected the generated assembly file in the second pass. Inspection of the assembly listing revealed an invalid instruction, which had been emitted by the compiler pass.

The C compiler is:

"powerpc-eabivle-gcc.exe (GCC) 4.9.4 20160726 (Sat May 27 11:09:55 CDT 2017 build.sh rev=gd8b6c20 s=F494 ELe200 -V release_gd8b6c20_build_Fed_ELe200_ML0)"

This is the command line. We have removed some -I<path> switches. The problem appeared with -O3 and likely with -Os but not with -O2:

powerpc-eabivle-gcc.exe -c -mcpu=e200z4 -mbig-endian -mvle -misel=yes -meabi -msdata=default -G8 -mregnames -fshort-double -fsingle-precision-constant -mhard-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 -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 --sysroot=C:/ProgramFiles/MinGW-powerpc-eabivle-4.9.4/powerpc-eabivle/newlib -MMD -std=gnu11 -Icode -DPRODUCTION -DNDEBUG -DTL42 -g1 -gdwarf-2 -O3 -o bin/ppc/PRODUCTION/obj/bcc_ulim5.o thisFolderStandsForAnyPathToCustomerCode/codeSampleCustomer/Integration/sohr5.c

Our problem analysis:

For source code line 265, the compiler emits the instruction

e_bc 1,28,$+12

The instruction tries to evaluate the compare register CR7, which is not permitted in this VLE instruction. The original Book E instruction bc uses the 5 Bit field BI to select a compare result bit and would allow the value of 28 (see EREF, 6.4, p. 413) but the VLE instruction e_bc has only 4 Bit for field BI32 (despite of its name) and restricts the range of accessible compare result bits to 0..15 (see VLE, p. 3-13 = 45). Accordingly, the assembler complains about the 28.
Many other assembly code locations from the same file make use of instruction e_mcrf to first move the otherwise inaccessible compare result bits to the accessible range and evaluate only then (see snippet below). The faulty code pattern has seen just once in the entire project.

EREF: "EREF: A Programmer's Reference Manual for Freescale Power Architecture Processors", EREF_RM, Rev. 1 (EIS 2.1), 06/2014

VLE: "Variable-Length Encoding (VLE) Programming Environments Manual: A Supplement to the EREF", VLEPEM, Rev. 0, 07/2007

Here is a snippet from the generated assembly code (written by the compiler). Unfortunately, the full assembly listing and the original source file can't be disclosed because of intellectual property concerns:

(..)
.L247:
.loc 1 4672 0
e_mcrf %cr0,%cr7
e_beq %cr0,.L248
.loc 1 4673 0
e_lbz %r6,Sbccsohr5124_RSWE@sda21(%r0)
se_cmpi %r6,0
e_beq %cr0,.L249
e_lhz %r24,X_Sbccsohr5124_Unit_Delay6@sda21(%r0)
.L250:

(..)

.L262:
.loc 1 4798 0
e_beq %cr1,.L263
.loc 1 4799 0
e_lbz %r6,Sbccsohr5121_RSWE@sda21(%r0)
e_cmpi %cr1,%r6,0
e_beq %cr1,.L264
e_lhz %r0,X_Sbccsohr5121_Unit_Delay6@sda21(%r0)
.L265:
cmpl %cr7,%r7,%r0
e_bc 1,28,$+12 /* Book E instruction bc used as (invalid) VLE instruction e_bc */
mr %r6,%r7
e_b $+8
mr %r6,%r0
e_sth %r6,Sbccsohr5121_Modl2@sda21(%r0)
.loc 1 4823 0
e_sth %r6,X_Sbccsohr5121_Unit_Delay6@sda21(%r0)

(..)

Kind regards

Peter Vranken

[stanish]

Hello Peter,

Thank you indeeed for the detailed analysis of the compiler issue you are facing.

In fact this is a known issue (CMPE200GCC-183) that has been fixed in the latest version of GCC compiler (Version 280218) - release notes:

https://www.nxp.com/docs/en/release-note/S32DS-POWER-v1-2-RN.pdf

If possible I'd recommend you to download and install the latest S32DS for Power v2.1 (https://community.nxp.com/t5/S32-Design-Studio-Knowledge-Base/S32-Design-Studio-for-Power-Architectu...) and use this version of build tools instead.

Hope it helps.

Stan

[peter_vranken]

Thanks a lot, Stan. I'm a bit confused. I regularly updated the S32 Design
Studio (last recently in December 2020 to Update 14) and each time I did,
I looked for version updates of GCC. If I run gcc with command line
--version, then I get from S32DS PA 2.1, Update 14:

S32 Design Studio, V 2.1, latest update (no. 14):

powerpc-eabivle-gcc-4.9.4.exe (BLD = 1607) 4.9.4 20160726 (build.sh rev=gceb1328 s=F494 -i /opt/freescale ELe200 -V release_gceb1328_build_Fed_ELe200_ML3)
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

In our project, we indeed run an elder version, which responds:

powerpc-eabivle-gcc-4.9.4.exe (GCC) 4.9.4 20160726 (Sat May 27 11:09:55 CDT 2017 build.sh rev=gd8b6c20 s=F494 ELe200 -V release_gd8b6c20_build_Fed_ELe200_ML0)
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Both give "4.9.4 20160726" as version designation and this is the reason,
why I didn't upgrade the project's compiler.

In your post, you mention "Version 280218" as current version designation.
This seems to be related to year 2018, our looks rather like 2016, both
wouldn't be very recent. How does all of this fit together? Won't we get
the new GCC with the Update 14 of the Design Studio? Do we need to
download it somehow differently? Is there an explicit download site for
the compiler tool chain?

Regards

Peter

[stanish]

Hi Peter,

I agree that GCC versioning for S32DS Power is bit of confusing.

The GCC version reflects the official version of the tools that we use as a base for the build tools. 

Our releases cannot increment this version since it they are not the official GCC releases. Rather they should be considered as customizations. To differentiate between the releases you should check the build timestamp or build number (added later).

See below the snippet from the release notes document:

The version information (emitted via –version or -v) output format has changed to precisely
define a build BLD identifier as an integer value whose value will always increase with each
subsequent release. Example:

$ powerpc-eabivle-gcc --version
powerpc-eabivle-gcc (BLD = 1607) 4.9.4 20160726 (build.sh rev=gceb1328 s=F494 \
-i /opt/freescale ELe200 -V release_gceb1328_build_Fed_ELe200_ML3)

$ powerpc-eabivle-gcc -v<snip>
gcc version 4.9.4 20160726 (build.sh rev=gceb1328 s=F494 -i /opt/freescale \
ELe200 -V release_gceb1328_build_Fed_ELe200_ML3) (BLD = 1607)

Perhaps @alexanderfedoto could you possibly comment on this one?

Regards,

Stan