Mbed-cli: Compiler Version mismatch

[jflynn129]

When using the latest GCC_ARM compile, the following is output. It isn't causing a failure but is troublesome to see displayed during compilation.

[Error] @,: Compiler version mismatch: Have 7.2.1; expected version >= 6.0.0 and < 7.0.0

ARM Version info:
arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 7-2017-q4-major) 7.2.1 20170904 (release) [ARM/embedded-7-branch revision 255204]
C

[theotherjimmy]

@jflynn129 That's a mirror of what we test with in CI. There are small corner cases where you can get incorrect output with Mbed OS + GCC 7. I'm not going to lay blame on which one is at fault.
[Mirrored to Jira]

[screamerbg]

@theotherjimmy Given that this is not stopping/aborting compile, should this be converted to [Warning]?
[Mirrored to Jira]

[jflynn129]

If it going to be announced as an error or warning then sufficient information should be provided to allow a user to take action (or not if they choose). At this point, this is simply an annoyance to the user.
[Mirrored to Jira]

[theotherjimmy]

@jflynn129 That information depends on how you want to install the compiler. We could include some text like "please configure a version of GCC_ARM within the expected version range".
[Mirrored to Jira]

[jflynn129]

@theotherjimmy the problem is that most people will go to https://launchpad.net/gcc-arm-embedded/+announcement/15015 OR https://developer.arm.com/open-source/gnu-toolchain/gnu-rm and download the ARM GCC tools. Then when you run the mbed compiler that error message is displayed. I know that keeping up with the GCC releases is probably something you don't want to do, but rather than announce "[Error]@" it would be better to say something like "[WARNING] mbed os version x.x has only been tested with ARM GCC tools version x.x through x.x, unexpected errors may occur with later version." or something like that. Announcing it as an error isn't true, because everything appears to work just fine. The latter statement is more descriptive of what the problem is. That is just MO though.
[Mirrored to Jira]

[theotherjimmy]

@jflynn129 Thanks for the suggestion on text. I like it and I can make a PR to update the text to something similar. RE: warning/error that was requested of me. I don't recall who, but my gut says that @sg- will have an opinion on the warning/error status.
[Mirrored to Jira]

[M-ichae-l]

Hi, guys. So what is the solution for this issue? Downgrade the GCC compiler? Or the "ERROR" is just a warning if compile succeed nothing is going to be wrong?
[Mirrored to Jira]

[geoffrey-vl]

Moreover, we've been using GCC7 since we started to use mbed-os 5. Was this problem only discovered recently or may it have been defect all along? What problems could we aspect from products that are already deployed?
[Mirrored to Jira]

[theotherjimmy]

@M-ichae-l @geoffrey-vl Your concerns are valid.

Or the "ERROR" is just a warning if compile succeed nothing is going to be wrong?

I recall at least one instance where GCC 6 emitted correct instructions and GCC 7 emitted bad instructions. I don't recall the details though, other than the device catastrophically failed (Hard fault I think) in < 1sec. At best, compile success with GCC 7 probably works. As we test with GCC 6, we can only make claims about what it willl do.

Was this problem only discovered recently or may it have been defect all along?

The defect is something that I have been aware of for about 2 months prior to the PR that added that ERROR/WARNING at the beginning of the compile.

What problems could we aspect from products that are already deployed?

Given that the only defect that I'm aware of crashed the device on boot, I think you should be pretty safe. Don't take my word for it though; you should have testing in place to verify that your devices boot and function correctly.

---

RE: WARNING vs. ERROR: I'm open to changing the text of the message and changing it to a warning. It my observation: Mbed OS Hal's can produce many warnings, so making something like this an Error may have been requested of me (by parties I don't recall) to make a conversation like this happen.
[Mirrored to Jira]

[theotherjimmy]

If I were to change the text, it would be to:

"[Warning] This version of Mbed OS has only been tested with GCC version 6, and unexpected errors may occur, even when compilation succeeds, when using the currently selected version: x.x.x."

I think that's accurate to the defect we have/had and provides enough information to allow a user to make an informed decision.
[Mirrored to Jira]

[geoffrey-vl]

That said, note that today marked the last release of GCC6 (https://gcc.gnu.org/ml/gcc/2018-10/msg00221.html).
Wouldn't that make it a good reason to support GCC7?

[unsignedint]

Is there an GitHub issue that is tracking progress towards GCC 7 support?

[yanyanem]

how to download GCC_ARM 6 Compiler and setup on ubuntu16.04 ?

[ConradBraam]

Hi Yanyenem,
Visit, https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads and then scroll down to the "6-2017-q2-update" should do it.

[cmonr]

Noticed this was still open. Since the discussion tapered off a while back, we ended up downgrading the error to a warning: https://github.com/ARMmbed/mbed-os/pull/7876

To answer other questions:

Is there an GitHub issue that is tracking progress towards GCC 7 support?

Not at this time. We _may_ be able to switch over to it for 5.12, but updating all three compilers at once seemed risky (IAR8 and ARMc6 are actively in progress).

That being said, we realized a while back that Travis CI has actually been running, GCC7 instead of GCC6, and I _personally_ haven't noticed issues jumping from 6 to 7, but GCC 6 is what our Jenkins CI (more exhaustive CI) tests againsts and uses for now.

Since the original question/issue was already addressed, I'll be closing this issue.

[CamelShoko]

change file can close the compiler waring tips
mbed-os/tools/toolchains/gcc.py

"GCC_RANGE = (LooseVersion("9.0.0"), LooseVersion("10.0.0"))"