Disclaimer: I'm one of the founders of Ferrous Systems.
Ferrocene as a compiler is not inherently more suitable for safety critical applications than stock rustc as distributed by the rust project. It is for all intents and purposes the rust projects compiler, with all the certification paperwork - that's quite a stack of paper if you include all of it, but it doesn't change any of the functionality.
However, on a support/organizational level, there are quite a few differences. We run our own CI for all of our supported targets which allows us to provide different QA levels than the rust project does or even could support.
We do provide higher levels of assurance on some targets compared to upstream. For example, the aarch64-unknown-none target is treated as "tier 2" by the Rust project, meaning they don't run any tests for it. Instead, Ferrocene treats it as fully supported, and we ensure all tests pass on it when we merge any change (contributing back fixes when something breaks).
We can also provide support for targets that are not in the rust projects tree, or even require legal paperwork for access to test hardware etc., to the point that we can provide binary only targets that cannot be made available via the rust project.
On a support level, we also provide support for existing rust version, to the point of long term support for certified versions (2 years by default, more or less infinite with a separate support contract).
There's also minor things that are interesting to organizations: Notification of known issues, signed installers, ...
All of these things do not change the compilers behavior, but can be quite essential for organizations with long term, safety critical projects.
Is there a list with supported targets? Do you focus on ARM or are there other targets common in automotive, for example Power Architecture like the NXP MPC series?
We have other targets on the roadmap and can implement/qualify targets on request, so if you‘re interested in a specific target, we‘d be happy to talk.
Ferrocene as a compiler is not inherently more suitable for safety critical applications than stock rustc as distributed by the rust project. It is for all intents and purposes the rust projects compiler, with all the certification paperwork - that's quite a stack of paper if you include all of it, but it doesn't change any of the functionality.
However, on a support/organizational level, there are quite a few differences. We run our own CI for all of our supported targets which allows us to provide different QA levels than the rust project does or even could support.
We do provide higher levels of assurance on some targets compared to upstream. For example, the aarch64-unknown-none target is treated as "tier 2" by the Rust project, meaning they don't run any tests for it. Instead, Ferrocene treats it as fully supported, and we ensure all tests pass on it when we merge any change (contributing back fixes when something breaks).
We can also provide support for targets that are not in the rust projects tree, or even require legal paperwork for access to test hardware etc., to the point that we can provide binary only targets that cannot be made available via the rust project.
On a support level, we also provide support for existing rust version, to the point of long term support for certified versions (2 years by default, more or less infinite with a separate support contract).
There's also minor things that are interesting to organizations: Notification of known issues, signed installers, ...
All of these things do not change the compilers behavior, but can be quite essential for organizations with long term, safety critical projects.