Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GCC Rust: GCC Front-End for Rust

github.com

Post reply on HN
Print view View original

171–179 of 179 posts

Re: GCC Rust: GCC Front-End for Rust

#171

Post by eru »

ncmncm wrote: post #140
anfilt wrote: post #137

Earlier quoted context omitted.

System programs can be in user space for instance a run time for another language. As for a compiler ideally its easy to port as its kinda of the bed rock to get any other system going. Although a compiler for some architecture or use cases is too large to be self hosted or does not make sense to be self hosted. So its not always a deal breaker for a compiler.

You seem to be confused about what C++ and C are, and even about what Gcc is and its relationship to programs it compiles. C++ is a language defined by ISO committee SC22/WG21 via the Standards 14882, most recently C++20 (superseding C++17). C is defined by SC22/WG14, in the same way. The most widely used implementations of these Standards -- Gcc, Clang, and MSVC -- are in fact the same project in each case (although…

> The most widely used implementations of these Standards -- Gcc, Clang, and MSVC -- are in fact the same project in each case (although MS's [until recently implemented] a long-superceded C Standard), and are, in fact, themselves C++ programs.

Yes. Though as far as suitability for 'systems programming' is concerned they might as well be Python programs or bash scripts, as long as they produce suitable output in an adequate amount of time.

Re: GCC Rust: GCC Front-End for Rust

#172

Post by gpderetta »

chubot wrote: post #168
gpderetta wrote: post #167

Earlier quoted context omitted.

Even with templates you can still keep the ABI stable, se for example libstdc++. Which is not surprising as they compile down to the equivalent C code.

I think your example is better evidence for my view. I remember this issue being mentioned in a CppCon talk: C++ 11 broke the ABI for STL (for efficiency as far as I remember), and the binary interface to libstdc++ changed as a result: https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_a... So the ABI can leak implementation details in nontrivial ways that library authors usually don't consider. It's better t…

The ABI break in libstdc++ has nothing to do with templates and it was not done by mistake.

The layout of std::string changed to conform to the new standard; exactly the same thing would have happened if std::string was a C POD type, there is no way around that.

In fact libstdc++ to this day still has the option to be compiled with the old ABI.

There have been other minor ABI breaks, mostly to fix bugs, which affect only a small number of programs.

Pure C libraries have exactly the same ABI stability issues caused by changes in layout of structures; to avoid this C libraries expose only opaque pointer sized handles to heap allocated objects. This is similar to C++ libraries only exposing pointers to virtual interfaces, but for high performance libraries, for example containers, this is not considered acceptable.

Re: GCC Rust: GCC Front-End for Rust

#173

Post by gpderetta »

volta87 wrote: post #157
gpderetta wrote: post #151

Earlier quoted context omitted.

The infinite loop being UB was added because it prevents some important code motion optimizations and makes it hard to reason about the memory model. You can find the details on the papers leading to the C++11 memory model.

> The infinite loop being UB was added because it prevents some important code motion optimizations Which ones? If this optimizations are so important, how come Rust was designed in such a way to make them impossible? Also, how does this fit, e.g., the benchmark game results which show that Rust is faster than C for all benchmarks considered there ?

Store sinking for example, which is unsafe unless the loop is guaranteed to terminate.

C does not have this guarantee (at least not in all cases). Also rust is compiled with the llvm backend, so my understanding is that in practice rust assumes that loops terminate. See:

https://github.com/rust-lang/rust/issues/28728

There are llvm directives that can be added to prevent the optimization, but they are rejected by the rust maintainers exactly because they would cause performance regressions.

Re: GCC Rust: GCC Front-End for Rust

#174

Post by gpderetta »

souprock wrote: post #152
gpderetta wrote: post #151

Earlier quoted context omitted.

The infinite loop being UB was added because it prevents some important code motion optimizations and makes it hard to reason about the memory model. You can find the details on the papers leading to the C++11 memory model.

Uh, so what? Letting the compiler assume that a "switch" without a default will never go there is a great optimization too. Why not put that in the standard? Actually, this is worse. Letting the loop be UB is like letting a true "if" be UB. Just never mind the code actually written; surely it doesn't mean what it says.

> Letting the compiler assume that a "switch" without a default will never go there is a great optimization too. Why not put that in the standard?

that's actually the case already. A missing default is UB if the switch condition does not match any of the cases. And C compilers already optimize accordingly.

Re: GCC Rust: GCC Front-End for Rust

#175

Post by CameronNemo »

IcePic wrote: post #148
CameronNemo wrote: post #108

Earlier quoted context omitted.

Who are these groups who are demanding such easy bootstrapping? OS or distro developers? Programmers working on embedded and/or safety critical systems? I know OpenBSD avoids rust because of the bootstrapping issue, but they also avoid LLVM because of a licensing issue.

OpenBSD uses clang/llvm on most arches by now for the system compiler.

Uf. Brain fart. I meant that they avoid GCC because of licensing.

Re: GCC Rust: GCC Front-End for Rust

#176

Post by chubot »

gpderetta wrote: post #172
chubot wrote: post #168

Earlier quoted context omitted.

I think your example is better evidence for my view. I remember this issue being mentioned in a CppCon talk: C++ 11 broke the ABI for STL (for efficiency as far as I remember), and the binary interface to libstdc++ changed as a result: https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_a... So the ABI can leak implementation details in nontrivial ways that library authors usually don't consider. It's better t…

The ABI break in libstdc++ has nothing to do with templates and it was not done by mistake. The layout of std::string changed to conform to the new standard; exactly the same thing would have happened if std::string was a C POD type, there is no way around that. In fact libstdc++ to this day still has the option to be compiled with the old ABI. There have been other minor ABI breaks, mostly to fix bugs, which affect…

The point is that data layout is an implementation detail not part of the C++ API, and exposing that through shared libraries isn't a great idea. People do it, but it's a big mess and not particularly well documented.

You can write conformant STL implementations that have completely different layouts. But the GNU one no longer had a valid layout, so it had to change.

So when you expose libstdc++ as a shared library, you're exposing a bunch of details that aren't part of the C++ standard.

If you write it in a header, then you can expect it to break callers via shared library. And templates must be in headers. This is a fundamental language issue.

I don't use Rust, but the point is "making a stable ABI" will expose it to these sorts of problems, i.e. implementation details leaking on specific architectures, outside of the language.

The projects that care about ABI stability, e.g. sqlite, don't expose layouts. They have only functions and not data in their headers.

Re: GCC Rust: GCC Front-End for Rust

#177

Post by jjnoakes »

kzrdude wrote: post #149
jjnoakes wrote: post #124

Ecstatic to see this. Once this stabilizes then I can switch my shop to rust and not look back. If I find some spare time I will absolutely try to find a way to contribute.

Do you mean that you will use this, or just have the alt implementation as a checkbox item? Because - I'm just guessing of course - for this to be a mature alternative compiler we might be looking at 5, 10 years in the future, or never. Just being realistic, things take time to grow (and it's also uncertain how they can ever be able to keep pace with the rapidly developing Rust project). With all this said, I would l…

I mean that I'd use it. If it takes a while then maybe I can get by with mrustc for a bit (haven't tried yet) but the net of it is that I need to support systems which llvm does not, which has kept me from using rust in product thus far.

Re: GCC Rust: GCC Front-End for Rust

#178

Post by gpderetta »

chubot wrote: post #176
gpderetta wrote: post #172

Earlier quoted context omitted.

The ABI break in libstdc++ has nothing to do with templates and it was not done by mistake. The layout of std::string changed to conform to the new standard; exactly the same thing would have happened if std::string was a C POD type, there is no way around that. In fact libstdc++ to this day still has the option to be compiled with the old ABI. There have been other minor ABI breaks, mostly to fix bugs, which affect…

The point is that data layout is an implementation detail not part of the C++ API, and exposing that through shared libraries isn't a great idea. People do it, but it's a big mess and not particularly well documented. You can write conformant STL implementations that have completely different layouts. But the GNU one no longer had a valid layout, so it had to change. So when you expose libstdc++ as a shared library,…

This thread is getting confusing.

Your original point was that for binary compatibility you write against the C ABI. I'm claiming that the C ABI has exactly the same fragile layout limitations and you can use the exact same workarounds in C++ (i.e. only expose pointers or make sure that your layout doesn't change).

I'm also claiming that templates are a red herring and have very little to do with ABI.

Re: GCC Rust: GCC Front-End for Rust

#179

Post by potatochup »

volta87 wrote: post #100
potatochup wrote: post #98

Does this mean that compilation target currently supported by GCC would now allow rust to target that architecture? Specifically I'm thinking of PPC cores with the VLE extension, which LLVM does not support (as far as I'm aware).

llvm does support ppc64le cores with VSX extension; if thats what you mean in fact, IBM uses LLVM proper as its own compiler backend for its ppc processors

The VLE I'm talking about is this: https://www.st.com/resource/en/user_manual/cd00161395-variab...

This may be a vendor-specific extension though?

Post reply on HN