As far as I understand, also from information here in the forum, the armgcc compiler version comes bundled with the MCUXpresso IDE.
That is a concept which has a major drawback: It means everytime the IDE is updated (for example because a bug in the debug toolchain has been fixed), it forces to also update the code generation toolchain. But the update of the code generation toolchain always has the inherent risk of breaking something that worked before.
So it means, all the existing projects have to be thorougly tested everytime the IDE is updated.
Why was it done like that?
For example Texas instruments does it differently: You can stick with your compiler through the whole lifetime of a project. It is a setting in the project preferences, which compiler to use. You can always update the IDE without the risk of breaking existing projects.
NXP do (occasionally) issue IDE-only fixes that are available through the IDE update function. This just updates the IDE.
However, your general concept holds. I would guess that it is much easier to manage a complete IDE+toolchain release - you can test the whole thing together and make sure it works. If you are trying to support a new IDE and (potentially) several older toolchains, I can image that it becomes a nightmare to test all combinations. I don't know about TI, but I know the NXP IDE team is tiny (I met some of them at a show a few years back).
So, if you need to stick to a toolchain, you are (mostly) stuck with a specific IDE version - bugs and all!
>...but I know the NXP IDE team is tiny (I met some of them at a show a few years back).
Which does not surprise me. It is the same as with many other companies of similar size.
> If you are trying to support a new IDE and (potentially) several older toolchains, I can image that it becomes a nightmare to test all combinations.
Many competitors provide free toolchains, backed by a similar sized team and similar level of support. This is IMHO o.k. if no fitness for industrial / commerial use is claimed. Free toolchains and free SDKs allow an easy entry for beginners, hobbyists and students, and are a rapid prototyping tool.
But working in this field for some years, I made the experience that commercial toolchains like Keil and IAR are worth their money if you need reliability, efficiency and support.
I cannot claim any knowledge of NXPs approach in this regard.
However, my company use the TI toolchain (CCS) for a Cortex-R based ECU project, which involves a RTOS certified for safe applications. The costs of a full RTOS license are in the 6-digit range. And since the certificate is tied to the compiler, TI has a strong incentive to keep the toolchain untouched unless explicitly asked.