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

GCC Rust Approved by GCC Steering Committee

gcc.gnu.org

Post reply on HN
Print view View original

241–250 of 300 posts

Re: GCC Rust Approved by GCC Steering Committee

#241

Post by netheril96 »

zetaposter wrote: post #102
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.

1. GCC has more backends than LLVM. 2. Competition is good in general. 3. I expect this will trigger inconsistencies between GCC and rustc; because Rust doesn't really have a specification. Which will force both parties to discuss and solve them.

> I expect this will trigger inconsistencies between GCC and rustc; because Rust doesn't really have a specification. Which will force both parties to discuss and solve them.

More likely that GCC has to follow all the bugs and quirks of rustc or no people will use GCC for Rust.

Re: GCC Rust Approved by GCC Steering Committee

#242

Post by dagmx »

superkuh wrote: post #201
dagmx wrote: post #144

Earlier quoted context omitted.

This is an odd take that I feel is rooted in a misunderstanding. rust intentionally has a fairly rapid release schedule, so that you don't end up with a big release every year that introduces several possibly breaking changes. Features aren't randomly scheduled for each release. Instead each release is a snapshot of what's been stabilized by that point. If you prefer some arbitrary concept of stability, then you can…

This is the perspective of a developer. I am trying to explain the perspective of an open source desktop user who's ran into the backwards incompatibility in 4 out of 5 rust tools I've attempted to compile for use. The Rust language is fine. Great, even. Most Rust devs are bleeding edge types that always use the latest features. Hopefully this changes as Rust matures.

The rust compiler rarely breaks backwards compatibility, so I'd be curious to see what issues you actually hit.

Perhaps you mean forwards compatibility, in which case yes perhaps that's an issue but I'm not sure why you'd want bigger, slower release cadence when it would likely make your problem worse , when libs update but updating your compiler potentially causes significant other changes as is the case with C++ for example

Re: GCC Rust Approved by GCC Steering Committee

#243

Post by tialaramex »

not2b wrote: post #216
tialaramex wrote: post #114

Earlier quoted context omitted.

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 o…

I understand the confusion. C and C++ do indeed have aliasing rules and those rules do, as you point out, forbid type punning tricks. But as you can see I wasn't talking about type punning. Our uuencoded value isn't a type pun, and our pointer isn't the wrong type, it's the correct type with, miraculously, the correct value - It's a magic trick!

The C++ Standard is OK with this magic trick. Executing this trick in the C++ abstract machine is no problem at all.

However in a real world compiler this is a huge problem - because the optimiser assumes I can't possibly have such a pointer. Where would I get it from? This is where provenance comes into the picture. Where did my pointer come from, that's what provenance means. The C++ standard has nothing to say about provenance but your compiler depends on it.

Re: GCC Rust Approved by GCC Steering Committee

#244

Post by ByteJockey »

pornel wrote: post #176
j16sdiz wrote: post #140

The rust borrow checker is under-specified (for a good reason). Can forsee lots of incompatible with two implementation

It won't be. They plan to use the exact same code! Rust is designed to compile fine without any borrow checking (it reduces it to the C level of safety, but valid programs generate valid code). GCC will compile itself without a borrow checker. Then it will compile the existing borrow checker written in Rust, and then recompile itself with borrow checking.

> They plan to use the exact same code!

Did they announce a change of plans? Their website just says that they have no plans for a borrow checker (i.e. it's not required to actually implement rust).

From the website for the project:

> There are no immediate plans for a borrow checker as this is not required to compile rust code and is the last pass in the RustC compiler. This can be handled as a separate project when we get to that point.

Link here: https://rust-gcc.github.io/

Re: GCC Rust Approved by GCC Steering Committee

#245

Post by adastra22 »

mistrial9 wrote: post #193
adastra22 wrote: post #190

Earlier quoted context omitted.

"Libre" is not a word in the English language. Pretty sure that's not going to be clearer.

feature not a bug? asking a question is the first step to a new understanding

You’re assuming genuine curiosity which probably isn’t there.

Re: GCC Rust Approved by GCC Steering Committee

#246

Post by School-Cotton »

steveklabnik wrote: post #225
thrown_22 wrote: post #219

Earlier quoted context omitted.

>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 wi…

> code written 5 years ago will often not compile today. citation needed. Yes, there's a few programs that relied on unsound things for which this is true, but that's a relatively small part of the overall amount of code.

Doesn’t every implementation of a new function on a standard type possibly break existing code?

For example if I have a trait Foo with a function bar, and I impl Foo for HashMap, and then a new version of std comes out that has named something HashMap::bar, now every call to my_map.bar() is ambiguous

Re: GCC Rust Approved by GCC Steering Committee

#247

Post by tialaramex »

superkuh wrote: post #201
dagmx wrote: post #144

Earlier quoted context omitted.

This is an odd take that I feel is rooted in a misunderstanding. rust intentionally has a fairly rapid release schedule, so that you don't end up with a big release every year that introduces several possibly breaking changes. Features aren't randomly scheduled for each release. Instead each release is a snapshot of what's been stabilized by that point. If you prefer some arbitrary concept of stability, then you can…

This is the perspective of a developer. I am trying to explain the perspective of an open source desktop user who's ran into the backwards incompatibility in 4 out of 5 rust tools I've attempted to compile for use. The Rust language is fine. Great, even. Most Rust devs are bleeding edge types that always use the latest features. Hopefully this changes as Rust matures.

I feel like the set of people who

* Want to compile the software, not just install a pre-built binary * But, don't want to actually hack on the software and so don't care about up-to-date tools

... is probably rather small. Even for them, though, surely just an old source version will work? Or is there some reason that doesn't help?

Re: GCC Rust Approved by GCC Steering Committee

#248

Post by [deleted] »

goodpoint wrote: post #101
rascul wrote: post #63

Earlier quoted context omitted.

The term has been around for decades now, and seems to be fairly well understood in the tech world. It doesn't take much to say "free as in speech, not beer" to the few people left who need to understand it.

"free software" is still misleading and "free as in speech" is hardly accurate. They both fail to convey what it's really about.

[deleted]

Re: GCC Rust Approved by GCC Steering Committee

#249

Post by ChrisRackauckas »

jcranmer wrote: post #41
sdfhdhjdw3 wrote: post #33

Earlier quoted context omitted.

Oh damn, THIS is what the "intermediate representation" i keep hearing about is. I knew that Julia uses LLVM. I also knew that Julia has something called IR, but i didn't know what it was. So Julia's IR is probably LLVM's IR...

I suspect Julia has its own IR that is later lowered into LLVM IR. One of the aspects of multiple compilers is that it's basically a massive tower of IRs that get progressively lowered into lower- and lower-level IRs.

https://stackoverflow.com/a/43456211/1544203 is a little old, but still very much relevant. Julia has an untyped IR that it lowers into, then typed IR on which inference is performed, then it lowers to LLVM which lowers it to native. You can introspect the IR at these steps by taking a function call and doing `@code_lowered`, `@code_typed`, `@code_llvm`, and `@code_native`.

For some examples, the compiler plugins interface acts on typed IR, so things like Diffractor for automatic differentiation or JET static analysis and EscapeAnalysis.jl act there. Notably, Zygote automatic differentiation acted on the untyped IR. GPUCompiler.jl does some operations on the typed IR then lowers to the LLVM IR level and then intercepts the normal compilation process to choose alternative backends (e.g. compile to .ptx for compilation of native Julia to CUDA). Enzyme.jl uses the Enzyme LLVM-based automatic differentiation, so it does some actions on the typed IR before lowering to LLVM and then injecting the Enzyme LLVM pass before compiling via GPUCompiler.jl (now to the normal CPU backend).

Re: GCC Rust Approved by GCC Steering Committee

#250

Post by charcircuit »

xiphias2 wrote: post #212
charcircuit wrote: post #120

Earlier quoted context omitted.

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.

>requires the developer knowing what the program (s)he is writing exactly expresses in Rust.

That just need documentation. You don't need a standard for that.

Post reply on HN