Mbed-os: ARMC5 build of a mbed-os-example-blinky broken on Mbed OS master

[TeroJaasko]

Description

ARMC5 build of a mbed-os-example-blinky is broken on Mbed OS master. Reverting C++11 enablement from profiles fixes the errors.

Test environment:

• ARM Compiler 5.06 update 6 (build 750)
• Mbed OS 6a1ab73988e87ccae28ebb6f944a7d448e86d9d7
• mbed-os-example-blinky 880ed00bff6352cea56031d34b9d891ba21059e9
• target: K64F
• profile: release

First error:

mbed compile -m K64F -t ARMC5 --profile=release 
<..>
Building project mbed-os-example-blinky (K64F, ARMC5)
Scan: mbed-os-example-blinky
Compile [ 69.8%]: at24mac.cpp
[Error] SingletonPtr.h@136,0:  #260-D: explicit type is missing ("int" assumed)
[Error] SingletonPtr.h@136,0:  #65: expected a ";"
[ERROR] "./mbed-os/platform/SingletonPtr.h", line 136: Error:  #260-D: explicit type is missing ("int" assumed)
"./mbed-os/platform/SingletonPtr.h", line 136: Error:  #65: expected a ";"
./mbed-os/components/802.15.4_RF/atmel-rf-driver/source/at24mac.cpp: 0 warnings, 2 errors

fix:

diff --git c/platform/SingletonPtr.h w/platform/SingletonPtr.h
index 9d2cc66..982f8ea 100644
--- c/platform/SingletonPtr.h
+++ w/platform/SingletonPtr.h
@@ -131,7 +131,9 @@ struct SingletonPtr {

     // This is zero initialized when in global scope
     mutable void *_ptr;
-#if __cplusplus >= 201103L
+
+    // ARMC5 does not support alignas()
+#if (__cplusplus >= 201103L) && !(defined(__ARMCC_VERSION) && (__ARMCC_VERSION < 6120000))
     // Align data appropriately
     alignas(T) mutable char _data[sizeof(T)];
 #else

next error:

Compile [ 87.4%]: NetworkInterface.cpp
[Error] NetworkInterface.cpp@101,0:  #20: identifier "UINT_FAST8_MAX" is undefined
[ERROR] "./mbed-os/features/netsocket/NetworkInterface.cpp", line 101: Error:  #20: identifier "UINT_FAST8_MAX" is undefined
./mbed-os/features/netsocket/NetworkInterface.cpp: 0 warnings, 1 error

Issue request type

[ ] Question
[ ] Enhancement
[x] Bug

[ciarmcom]

Internal Jira reference: https://jira.arm.com/browse/MBOCUSTRIA-1269

[0xc0170]

@kjbracey-arm Can you review?

Latest bump to C++ standard basically enables C++1x. As result ARMC5 might not compile

[TeroJaasko]

@0xc0170 the first fix is not enough, at least one more is needed and perhaps others until the compilation succeeds.

[0xc0170]

@0xc0170 the first fix is not enough, at least one more is needed and perhaps others until the compilation succeeds.

I was too fast to press comment. We shall consider the latest bump to C++1x standard makes ARMC5 not compatible anymore. Let me check with @kjbracey-arm about the compability, I don't recall the details from top of my head.

Binaries in the codebase won't neither compile with ARMC5, therefore this incompatibility is known since 5.12. Does not mean we should break it, see comment below.

[0xc0170]

This comment wraps it nicely (using #ifdef for new standard in the current codebase): https://github.com/ARMmbed/mbed-os/issues/5507#issuecomment-448940342

[kjbracey-arm]

5.13 should be fixable, to at least not be less compatible than 5.12. There are no real C++11 code changes in master yet. That one is an attempt to take advantage of C++11, but it trips over the fact that ARM C 5 says it's C++11 but it is incomplete.

Internal discussions happening about how far to continue ARM C 5 support beyond 5.13.y - it seems clear to me we're going to need ARM C 5 PR CI, for compilation at a minimum, if that's support is going to happen.

[0xc0170]

@kjbracey-arm would these fixes be able to make into 5.13.0 rc3 ?

[kjbracey-arm]

Yes, I'll try to quickly turn around a PR to make blinky work again. Whether that will fix /everything/, I don't know...

[kjbracey-arm]

!(defined(__ARMCC_VERSION) && (__ARMCC_VERSION < 6120000))

Pro tip, btw. If you're trying to distinguish ARM C 5 and ARM C 6, rather than treat them the same, it's usually simpler to not actually look at __ARMCC_VERSION, ironically.

The reason you're trying to distinguish them is most often that they're actually two totally different compiler cores. One's the ARM/Norcroft compiler, and the other is Clang. So you're often best off distinguishing the families by their "compiler core" define - #ifdef __CC_ARM (used to be #ifdef __CC_NORCROFT) versus #ifdef __clang__.

The 4 compilers we deal with can be checked with __ICCARM__, __GNUC__, __clang__ and __CC_ARM. (For symmetry, the first one should be __IAR_SYSTEMS_ICC__, but __ICCARM__ is much shorter...)

[TeroJaasko]

@kjbracey-arm thanks for tip. That should reduce migraine caused by writing the ifdefs next time.