[pcwalton]

That would be a compiler for a language to C/C++. That design decision is virtually always a bad idea: LLVM has simpler semantics, allows proper GC, allows proper debug info, is widely portable, and avoids a needless AST serialization/deserialization step.

Don't compile to C.

[jjnoakes]

Please don't tell others what not to do.

First, there are cases where compiling other languages to C or C++ is better than via LLVM; interoperability and portability are two (yes, C and C++ are more portable than LLVM).

Second, I'm not really talking about compiling some wildly different language to C++. I'm talking about some simple syntactic sugar. The same syntactic sugar that would be in an existing C or C++ compiler's front end, except instead of adding it to all the frontends in the world and waiting years, I'd like to implement it just once and now.

[pcwalton]

Effort in this direction would be better spent just adding new features to clang (or GCC). It'll be so much easier than writing a new parser and semantic analysis for C++, which you will have to do if you want the new feature to behave properly in the presence of templates, etc. You'll end up wanting to just use clang's front end to help you, like most C++ tools do—and at that point why not just modify clang itself?

People bring up obscure platforms (though, interestingly, I can't recall anybody actually naming one of those platforms) all the time as motivation for compiling to C. But if you really need to do that, you can always revive the LLVM C backend. The fact that nobody has bothered to revive it and keep it up to date enough to be merged into LLVM proper, to me, is a strong indication that few people need support for these obscure platforms.

[jjnoakes]

> Effort in this direction would be better spent just adding new features to clang (or GCC).

In your opinion. This isn't a fact. For example, I know first hand of code that has to compile with compilers that are not in the set { gcc, clang, msvc }. What do I do then? (Oh, and those compilers are closed-source).

> You'll end up wanting to just use clang's front end to help you

Probably, although there are other options too

> and at that point why not just modify clang itself?

The changes I make, if useful to the community, would probably end up back in clang. But they would also remain a separate tool, because of all those other pesky compilers I work with.

> you can always revive the LLVM C backend

I'm not sure how that helps me; not only does it seem a terribly roundabout way to get what I'm looking for (instead of sugar -> c++ -> my c++ compiler, you are proposing sugar -> clang -> llvm -> c -> my c compiler), but I don't think objects produced by that pipeline would link with C++ objects produced from my native compilers, among other issues.

> The fact that nobody has bothered to revive it and keep it up to date enough to be merged into LLVM proper, to me, is a strong indication that few people need support for these obscure platforms.

Or, is it evidence that people using more obscure platforms (we're talking fortune 500 companies here) stick to languages that exist on their platforms for various reasons?

[solidsnack9000]

Although I don't agree with this poster, it seems odd that they're being downvoted.

[valarauca1]

>>>yes, C and C++ are more portable than LLVM

C and C++ are more portable then their own compiler's backend? LLVM is clang/clang++'s assembler

I get what your saying if you compile to C it can be more portable. But then you need to compile to some C standard.

K&R C? ANSI C? C90? C99? C11? Why not have a compiler flag for each? What about embedded C? What companies embedded C?

I can repeat this for C++

Compiling to C/C++ in a platform and standard agnostic way is impossible.

[jjnoakes]

Lots of languages do it already. How is it impossible?

[valarauca1]

No.

Lots of languages can give you a dump in 1 standard of C. You can't specify what C standard, or what platform to output outside of ARM/x64. NIM, Cython, C++ (via clang), [Ada/Cobalt/Fortran]-GCC, Perl, Agol, Oracle PL/SQL only support x86_64 and ARM.

Your argument was

    interoperability and portability

1) Rust outputs to the same object file format as C, and can be natively linked against C/C++ code. So interoperability is no issue.

2) You have no portability gain as you have 3 choices x86, x64, and ARM. All of which Rust already supports.

Also your main request

    $ rustc your_program.rs --emit llvm-ir
    $ llc -march=c -o your_program.c your_program.ll

or if you want C++

    $ rustc your_program.rs --emit llvm-ir
    $ llc -march=cpp -o your_program.cpp your_program.ll

[jjnoakes]

Who needs more than one dialect of C or C++? I don't. Any systems I'm interested in may not support clang, but they have C11 compilers and C++14 compilers.

Rust is not interoperable with C++ as far as I know, and even if it was, I'm not interested in Rust for this discussion for reasons I've mentioned elsewhere.

The LLVM C backend was removed. Julia devs have a version that supports the LLVM bit code that they require, but I believe it is not everything LLVM can produce.

I was under the impression that march=cpp output C++ code that rebuilt the IR, not implemented the source program.

Thanks for the advice, although none of it really applies to what I'm suggesting.

[posterboy]

> Please don't tell others what not to do.

kind of paradox to say that

[jjnoakes]

Is it?

Mine was worded as a polite request and his was worded as a command.