GCC Rust Approved by GCC Steering Committee • Hacker News Board

Re: GCC Rust Approved by GCC Steering Committee

#211

Post by notriddle » Mon, Jul 11, 2022, 10:47 PM UTC

mcdonje wrote: post #210

mbStavola wrote: post #199

I have mixed feelings about the idea of a GCC frontend for Rust. On one hand, having frontend diversity for a language helps bring new people into the language; think of the groups who can't use Rust because it doesn't support certain targets or can't integrate with their existing toolchain. There is a lot of talent that could be brought into Rust just by virtue of them being able to be included and the less barriers…

Pretty sure you have it backwards. GCC isn't going to be a front end for rust; rust is going to be a front end for GCC. As I understand it, the point of both GCC and LLVM are to handle those implementation specific behaviors so programming language developers don't have to handle that concern. I don't expect this to fracture the language, but simply to provide the ability to use the language in more places.

There are two GCC ports for Rust being developed at once: codegen_backend_gcc is a module in the reference implementation of rustc, while rust-gcc is a complete C++-based compiler: https://github.com/Rust-GCC/gccrs/wiki/Frequently-Asked-Ques...

Re: GCC Rust Approved by GCC Steering Committee

#212

Post by xiphias2 » Mon, Jul 11, 2022, 10:53 PM UTC

charcircuit wrote: post #120

sicp-enjoyer wrote: post #106

Earlier quoted context omitted.

One advantage is it forces the language to articulate standards instead of the implementation defining the feature set. Standards tend to give stability and longevity to the language, as well as making it possible to write new compilers and make it more portable.

That sounds a little circular. The benefit of alternate compilers is that it makes making alternate compilers easier. For stability compilers already have a large incentive not to break old programs. For longevity I don't really see how a standard affects it that much. For being more portable you do not need an entirely knew compiler.

Rust is ,,A language empowering everyone to build reliable and efficient software.'' (from the home page)

Reliability at the extremes (where it may be even life or death situation) requires the developer knowing what the program (s)he is writing exactly expresses in Rust.

Re: GCC Rust Approved by GCC Steering Committee

#213

Post by mbStavola » Mon, Jul 11, 2022, 10:53 PM UTC

mcdonje wrote: post #210

mbStavola wrote: post #199

I have mixed feelings about the idea of a GCC frontend for Rust. On one hand, having frontend diversity for a language helps bring new people into the language; think of the groups who can't use Rust because it doesn't support certain targets or can't integrate with their existing toolchain. There is a lot of talent that could be brought into Rust just by virtue of them being able to be included and the less barriers…

Pretty sure you have it backwards. GCC isn't going to be a front end for rust; rust is going to be a front end for GCC. As I understand it, the point of both GCC and LLVM are to handle those implementation specific behaviors so programming language developers don't have to handle that concern. I don't expect this to fracture the language, but simply to provide the ability to use the language in more places.

Sorry, to be clear, I'm referring to the CPP reimplementation of the Rust compiler that uses GCC as a backend (gccrs).

My concern with fragmentation is that this is essentially a reimplementation of Rust in another language (C++) targeting a different backend (GCC). It's only natural for there to be differences between the two, especially over a long period of time.

There is a separate initiative that may be more in line with what you're thinking which adds GCC backend support for the existing mainstream Rust compiler.

Re: GCC Rust Approved by GCC Steering Committee

#214

Post by wtetzner » Mon, Jul 11, 2022, 10:56 PM UTC

syvon wrote: post #23

brundolf wrote: post #17

Earlier quoted context omitted.

Huh, I didn't realize that

A common misconception is that GCC stands for GNU C Compiler, but it stands for GNU Compiler Collection. Perhaps why you did not realize ;)

But I assume the name of the gcc binary stands for GNU C Compiler?

Re: GCC Rust Approved by GCC Steering Committee

#215

Post by wtetzner » Mon, Jul 11, 2022, 10:59 PM UTC

kangalioo wrote: post #149

klez wrote: post #31

Earlier quoted context omitted.

Care to elaborate?

Maybe referring to the fact that GCCRS duplicates a ton of effort by reimplementing the frontend (parser, borrow checker, error messages etc.) for questionable benefit since you could keep the existing frontend and just swap out the LLVM backend for GCC (as done by the rustc_codegen_gcc project).

This ignores the benefits of having multiple implementations, e.g. you can use places where two implementations disagree with each other to track down bugs in one or both of them.

Re: GCC Rust Approved by GCC Steering Committee

#216

Post by not2b » Mon, Jul 11, 2022, 11:07 PM UTC

tialaramex wrote: post #114

sfink wrote: post #66

Earlier quoted context omitted.

Note that the language independence of the middle layer(s) is often incomplete. Language-level constructs sometimes get smuggled through the intermediate layer and get translated in code generation. Or the middle layer is theoretically generic but valid variants that haven't been used before are buggy or unimplemented. I think Rust on LLVM has a major example of this? IIUC, it's a big problem to turn on strict aliasi…

Worse than not being completely "language independent" sometimes LLVM's Intermediate Representation is not well defined at all. This is most common where C++ (as the main consumer of these semantics) doesn't define certain semantics, or, the semantics it standardises are just impossible to optimise so nobody really delivers them (ie they don't always work in your C++ programs when you compile them with actual modern…

This is incorrect. C and C++ have aliasing rules; the compiler is allowed to assume that your magic pointer does not alias an object that otherwise you had no reason to believe could be aliased. Google "strict aliasing rule" to learn the details.

Essentially, C and C++ already have a version of provenance for pointers and references, but it isn't identical to the Rust version.

Because some old codebases pull tricks of this kind (messing with pointers, doing casts without going through unions, etc), gcc (and clang) have a flag, -fno-strict-aliasing , to disable some optimizations that would be enabled by taking aliasing/provenance into account.

Re: GCC Rust Approved by GCC Steering Committee

#217

Post by not2b » Mon, Jul 11, 2022, 11:09 PM UTC

nrclark wrote: post #15

sdfhdhjdw3 wrote: post #11

What does a "front-end" mean exactly, in this context?

Compilers are often implemented as a front-end/back-end split. The front-end compiles your input language (C, C++, Rust, etc) down to a low-level language called an Intermediate Representation. Then the back-end of the compiler optimizes the IR and compiles it into object code. A family of compilers will usually share the back-end. This kind of split allows for deduplication across different compilers in the same fam…

GCC also has front ends (compile many languages into a a common form, GIMPLE), a "middle end" (optimization), and many back ends (for different processor architectures).

Re: GCC Rust Approved by GCC Steering Committee

#218

Post by astrange » Mon, Jul 11, 2022, 11:18 PM UTC

apple4ever wrote: post #196

tomjakubowski wrote: post #142

Earlier quoted context omitted.

Being on gcc, a long-lived platform, also helps ensure the survival of the language even if development of the current compiler (or LLVM) dies or withers.

GCC support of Objective-C is very very poor.

Reimplementing ObjC 2.0 would be very hard. You have to be precisely bug-compatible with Clang to implement ARC correctly.

Re: GCC Rust Approved by GCC Steering Committee

#219

Post by thrown_22 » Mon, Jul 11, 2022, 11:19 PM UTC

faisal_ksa wrote: post #98

What is the benefit of having multiple compilers for programming languages? Is there a scenario where a GCC compiled rust program would do something that an LLVM one can't do? Doesn't this cause fragmentation in the rust ecosystem? P.S.:I understand that people can work on any project they want. And I don't have the right to tell them not to. I'm just curious about the technical reasons for having multiple compilers.

>What is the benefit of having multiple compilers for programming languages?

Rust will need a standard.

The main reason why I don't take it seriously is that code written 5 years ago will often not compile today. For a language that pretends to be a systems language that is a non-starter. If you can't guarantee a 40 year shelf life of your code then no one working on systems cares.

People working on systems in the wild don't have the brain power to learn a new tool chain every decade, let alone every year. They are solving real problems and not writing blog posts.

Re: GCC Rust Approved by GCC Steering Committee

#220

Post by coldtea » Mon, Jul 11, 2022, 11:19 PM UTC

Beltalowda wrote: post #189

coldtea wrote: post #187

Earlier quoted context omitted.

> Right to repair has been all over the news, including mainstream news, and least in tech circles Has been in the kind of news Joe Average doesn't give a fuck about and even if they watch, they forget in 10 minutes. Techies spot mentions of it in the news because they already care for it and know the term. That's not the same as something being in the news that reach regular people (that would be more like some high…

Such hostile contempt... Lots of things to concern yourself about and not everyone is interested in everything which is fine, but it's gotten quite a bit of coverage and certainly a lot more people know about it, never mind laws are being discussed and actually passed. More importantly, explaining the concept is just a lot easier because it's significantly less abstract.

>Such hostile contempt...

No such thing. I'm fine with Joe Average, and I don't think everybody should know about everything, much less about the "right to repair" (much more important stuff for people to learn about, including politics and/or gas prices and other things that affect someone more).

I'm merely stating a fact: the "right to repair" is not something that has been covered in any degree for the regular persons to know or care about. Most of those that do are already familiar with the tech scene, if not as technies, then as gadget lovers and tinkerers.