On Monday, 8 February 2021 at 11:09:49 UTC, Imperatorn wrote:
> Talking with some colleges. They have some questions regarding D:
>
> 1. Is D ready for prime time á la safety critical applications?
> (I guess they mean GDC on ARM for example)
>
> 2. Are there any plans to make a certified compiler?

Just to put it into some perspective. I have worked with so called certified C/C++ compilers in the automotive industry. I remember encountered several bugs in those compilers as well they are usually far behind when adopting the new language standards. Compare this to GCC, when was the last time you encountered a bug in that compiler? I can't remember any.

The certified compilers which are not better than GCC are usually proprietary and cost money for each user. Here we have a product that is essentially worse than GCC and cost money. What it is really about is a form of corruption. The only positive side is that if you find a bug you can put pressure on the company that provides the compiler but usually that takes several months.

On Tuesday, 9 February 2021 at 10:10:05 UTC, IGotD- wrote:
> Just to put it into some perspective. I have worked with so called certified C/C++ compilers in the automotive industry. I remember encountered several bugs in those compilers as well they are usually far behind when adopting the new language standards.
As I said, fixing bugs is NOT required for certification.
It is only necessary to document them.

> The certified compilers which are not better than GCC are usually proprietary and cost money for each user.
You can qualify a tool to be used in an ISO compliant build process on your own (in your company). We do this regularly for every little script we use. But to qualify something as complex as a compiler is a huge lot of work.
This is why getting an official certificate (from e.g. TÜV) is so expensive that a vendor NEEDS to sell it and can't give it away for free.

> Here we have a product that is essentially worse than GCC and cost money. What it is really about is a form of corruption.
Harsh words.
If you don't want to pay for a compiler, qualify it yourself. You'll see it cost you at least the same amount of money (or time).

> Compare this to GCC, when was the last time you encountered a bug in that compiler? I can't remember any.
But this is only because also there the bugs are quiet good documented in bugzilla and so can easily be avoided.
Having this documentation will help you a lot in qualifying the compiler yourself.

On Tuesday, 9 February 2021 at 11:25:26 UTC, Dominikus Dittes Scherkl wrote:
> As I said, fixing bugs is NOT required for certification.
> It is only necessary to document them.

Out of curiosity, what happens next then? I assume the goal is to certify your application. In the process of certifying your application, wouldn't you have to prove that the application does not trigger any of the documented bugs in the certified tools? This could well be harder to do than fixing the bugs in the tools.

-- Bastiaan.

On Tuesday, 9 February 2021 at 12:38:21 UTC, Bastiaan Veelo wrote:
> On Tuesday, 9 February 2021 at 11:25:26 UTC, Dominikus Dittes Scherkl wrote:
>> As I said, fixing bugs is NOT required for certification.
>> It is only necessary to document them.
>
> Out of curiosity, what happens next then? I assume the goal is to certify your application. In the process of certifying your application, wouldn't you have to prove that the application does not trigger any of the documented bugs in the certified tools? This could well be harder to do than fixing the bugs in the tools.
>
> -- Bastiaan.

I'm not aware that any certification requires explicit proof that you avoid those bugs. This is mostly covered indirectly by two things: you need to adhere to the safety manual for the tools you use and you need a pretty rigorous testing regime for your product. The mandated test coverage should be good enough to detect misbehaving code introduced by faulty tools.

On Tuesday, 9 February 2021 at 10:10:05 UTC, IGotD- wrote:
> On Monday, 8 February 2021 at 11:09:49 UTC, Imperatorn wrote:
>> Talking with some colleges. They have some questions regarding D:
>>
>> 1. Is D ready for prime time á la safety critical applications?
>> (I guess they mean GDC on ARM for example)
>>
>> 2. Are there any plans to make a certified compiler?
>
> Just to put it into some perspective. I have worked with so called certified C/C++ compilers in the automotive industry. I remember encountered several bugs in those compilers as well they are usually far behind when adopting the new language standards. Compare this to GCC, when was the last time you encountered a bug in that compiler? I can't remember any.
>
> The certified compilers which are not better than GCC are usually proprietary and cost money for each user. Here we have a product that is essentially worse than GCC and cost money. What it is really about is a form of corruption. The only positive side is that if you find a bug you can put pressure on the company that provides the compiler but usually that takes several months.

There is a fair amount of hate in this post that I can't agree with. I've worked with certified compilers, too. It was mainly one of the major products in the field. The package was a mixed bag. The custom IDE is lacking and the proprietary build tools are not very good, but the actual compiler for our target platform turned out to be very good. We threw it at a pretty big preexisting codebase and it worked (we had a few places where we were relying on subtle UB - that's on us). Compared to GCC, the generated code would consistently be smaller and thus faster, even when I compared unoptimized builds to GCC with optimizations (curiously, speed optimized GCC output was smaller than size optimized output!).

On Tuesday, 9 February 2021 at 13:35:36 UTC, Gregor Mückl wrote:
> On Tuesday, 9 February 2021 at 10:10:05 UTC, IGotD- wrote:
>> [...]
>
> There is a fair amount of hate in this post that I can't agree with. I've worked with certified compilers, too. It was mainly one of the major products in the field. The package was a mixed bag. The custom IDE is lacking and the proprietary build tools are not very good, but the actual compiler for our target platform turned out to be very good. We threw it at a pretty big preexisting codebase and it worked (we had a few places where we were relying on subtle UB - that's on us). Compared to GCC, the generated code would consistently be smaller and thus faster, even when I compared unoptimized builds to GCC with optimizations (curiously, speed optimized GCC output was smaller than size optimized output!).

What architecture was this running on? I say that because small is often not fast on a big machine - and the reason why fast gave smaller code is probably because of the weird non-determinism you get in big compilers as more stuff is inlined giving way to more information for the optimizer to use locally.

On Tuesday, 9 February 2021 at 13:22:22 UTC, Gregor Mückl wrote:
> On Tuesday, 9 February 2021 at 12:38:21 UTC, Bastiaan Veelo wrote:
>> On Tuesday, 9 February 2021 at 11:25:26 UTC, Dominikus Dittes Scherkl wrote:
>>> As I said, fixing bugs is NOT required for certification.
>>> It is only necessary to document them.
>>
>> Out of curiosity, what happens next then? I assume the goal is to certify your application. In the process of certifying your application, wouldn't you have to prove that the application does not trigger any of the documented bugs in the certified tools? This could well be harder to do than fixing the bugs in the tools.
>>
>> -- Bastiaan.
>
> I'm not aware that any certification requires explicit proof that you avoid those bugs. This is mostly covered indirectly by two things: you need to adhere to the safety manual for the tools you use and you need a pretty rigorous testing regime for your product. The mandated test coverage should be good enough to detect misbehaving code introduced by faulty tools.

This makes me wonder what certifying the tool practically brings to the table, apart from doors that can be entered with a certificate only. If certification of the tool does not improve the safety of the product and does not make it easier to test the safety of the product, I have the feeling that the certificate only improves perceived safety.

Your other comment that the certified commercial compiler you used produced higher quality binaries is not necessarily due to the certification, but likely due to available funds.

-- Bastiaan.

On Tuesday, 9 February 2021 at 13:35:36 UTC, Gregor Mückl wrote:
>
> There is a fair amount of hate in this post that I can't agree with.

Then you have a crewed up idea what hate means. Hate does not mean that you disagree with someone.

> I've worked with certified compilers, too. It was mainly one of the major products in the field. The package was a mixed bag. The custom IDE is lacking and the proprietary build tools are not very good, but the actual compiler for our target platform turned out to be very good. We threw it at a pretty big preexisting codebase and it worked (we had a few places where we were relying on subtle UB - that's on us). Compared to GCC, the generated code would consistently be smaller and thus faster, even when I compared unoptimized builds to GCC with optimizations (curiously, speed optimized GCC output was smaller than size optimized output!).

The main reason some company uses a certain "certified" compiler is because the customer demands it. There in between anything is possible with any kind of back room deal. Just like doctors get money under the table in order to promote a certain drug, which we know is commonplace.

The compiler I have worked with had a number of bugs and then I tried GCC and of course it ran perfectly with better code generation. The answer is of course obvious GCC is used by the hundreds of thousands and many contributing to the compiler. This compared to a small company creating some "certified" compiler. I'm all of commercial SW but I cannot deny that the huge backing of the GCC compilers is hard to beat. If I would decide which compiler to use I would of course go with GCC and skip the certified compiler, however it is the customers that dictates what to use.

On Monday, 8 February 2021 at 11:09:49 UTC, Imperatorn wrote:
> Talking with some colleges. They have some questions regarding D:
>
> 1. Is D ready for prime time á la safety critical applications?
> (I guess they mean GDC on ARM for example)
>
> 2. Are there any plans to make a certified compiler?

One would presumably certify some version of the D compiler, let's say 2.095.0, and would have to use that for years to come. Perhaps patch version updates would be okay (2.095.1), but no updating to 2.096.0 without re-certifying.

My experience is that Dub projects tend to stop compiling after perhaps 5 or so versions on average. That means that if D libraries are used, one would have to start maintaining them themselves after some time. This isn't a showstopper, since such maintenance is not a major burden assuming the library is already stable and no new features are desired. But it means that if someone releases a D library 3 years after the certification, the new library probably can't be used without considerable porting effort. One would be fairly much stuck with what exists at certification time.

On Tuesday, 9 February 2021 at 14:14:42 UTC, Bastiaan Veelo wrote:
> On Tuesday, 9 February 2021 at 13:22:22 UTC, Gregor Mückl wrote:

>> I'm not aware that any certification requires explicit proof that you avoid those bugs.[...]
>
> This makes me wonder what certifying the tool practically brings to the table, apart from doors that can be entered with a certificate only.
Nothing. It's a key to some doors. If you like to enter them, you have to have the key. It's the same as with every certificate.
E.g. if you don't have a CE-certificate, you can't sell your product in the EU.
If you don't have the ISO-certificate, can't sell your controller software to a major vendor.

> If certification of the tool does not improve the safety of the product and does not make it easier to test the safety of the product, I have the feeling that the certificate only improves perceived safety.
No, the certificate ensures that someone put intense thoughts about safety into the tool and documented what usecases it is good for and what you need to avoid to create a safe product with it. Thoughts that you would have to do yourself if you use a tool without that certificate.

I know, here are a lot of people that have very little trust in thoughts that someone else put into something, but it's their choice: use something certified or spent a lot of time to prove it yourself.
If you proof it yourself anyway, a certificate maybe really useless for you.