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

281–290 of 300 posts

Re: GCC Rust Approved by GCC Steering Committee

#281

Post by steveklabnik »

dleslie wrote: post #279
nickitolas wrote: post #273

Earlier quoted context omitted.

So it's not about platform support, but about toolchain integration? Who benefits from that, projects using C/C++ who want to use a rust library? Or is it about distro package maintainers?

The toolchains support helps embedded developers, mainly. For example, Xtensa and AVR toolchains are generally byzantine monstrosities of makefiles, Python, dialog, etc; so having them be given a low effort means to consume rust is a boon. Ideally, rust is just another source file in the srcdir soup. That said, gcc supports more platforms than llvm; including esoteric and unpopular desktop configurations. Personally,…

Incidentally, Xtensa has hired someone for the last… year or so? To make using Rust on their stuff work well.

AVR support is almost there in mainline rustc but has a codegen bug or two, last I heard.

Re: GCC Rust Approved by GCC Steering Committee

#282

Post by School-Cotton »

steveklabnik wrote: post #280
School-Cotton wrote: post #246

Earlier quoted context omitted.

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

In that specific case, the inherent impl is preferred, so there’s no ambiguity. however this can still cause a breaking change if the inherent impl has a different type signature than the trait. And yes, there are tons of things that can subtly break code. That’s why the rust project runs the entire open source ecosystems’ tests as part of the testing process for the compiler. It’s not all of the code in existence, b…

> In that specific case, the inherent impl is preferred, so there’s no ambiguity.

That is even worse. It means your code can silently start doing the wrong thing rather than erroring, if the inherent impl does something different from the trait.

> And yes, there are tons of things that can subtly break code.

This isn't some obscure bug in some deep edge case though, it's a completely normal and common way of using the language (implementing your own traits on foreign types) predictably leading to breakage in an obvious way. I am not sure why it should be called "subtle".

Anyway, given this issue, I think the meme that Rust is backwards-compatible is really oversold. It'd be more honest to frame it as "we hope releases are backwards-compatible, but we like adding new functions to the stdlib, so no promises" rather than marketing BC as a major selling point as is done now.

> In practice, the experience that the vast majority of users report to us is that they do not experience breakage when upgrading the compiler.

It's anecdotal for sure, but I'm personally aware of times when the exact situation I'm describing has happened and caused headaches for people.

Re: GCC Rust Approved by GCC Steering Committee

#283

Post by steveklabnik »

cozzyd wrote: post #209
steveklabnik wrote: post #198

Earlier quoted context omitted.

Where's the "purchase" part there? I see a download link, and it seemed to download the toolchain? I don't have any projects lying around to actually try it out, but it looks complete? I briefly looked at the license and it seems that if you're getting it for free, then its all good, you just get no support. (I only write Rust on ARM and so am unfamiliar with the various toolchains they offer, honestly.)

Ah, ok I saw this table: https://i.imgur.com/5ofzjC3.png and that trying to download required an account (which is not true for the GCC toolset) and assumed they'd make you pay something. But maybe they just try to trick you into thinking you might have to... (or I am easily fooled). edit: My legalese is not great, but isn't the the license saying that you can't legally distribute software compiled with the LLVM-base…

There’s that but but there’s also the “got it for free” thing above that; seems distinct from a “noncommercial license.”

But who knows, honestly they make this stuff as confusing as possible, it seems.

Re: GCC Rust Approved by GCC Steering Committee

#284

Post by not2b »

tialaramex wrote: post #243
not2b wrote: post #216

Earlier quoted context omitted.

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

You are incorrect. The C++ standard says a whole lot about it, and has detailed aliasing rules and rules about which pointers are valid. Your "magic trick", depending on details, isn't a standard conforming program; the standard will say that it has undefined behavior. That's why, as you say, the optimizer assumes you can't possibly have such a pointer, but what you get wrong is that the C++ standard describes the rules, in detail.

I've been doing this stuff for a long time, going back to egcs and even before.

Re: GCC Rust Approved by GCC Steering Committee

#285

Post by not2b »

steveklabnik wrote: post #226
not2b wrote: post #216

Earlier quoted context omitted.

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…

As a small point of order here (not saying you're wrong, just to elaborate a bit): * Rust doesn't have strict aliasing/tbaa * Rust does have "restrict" semantics (in C via the keyword and in C++ via common vendor extensions) And yeah, Rust is considering a provenance model that's different than PNVI-ae.

Yes, understood. But in Rust (without going through unsafe code), you can't write a program that will produce a reference to a u16 that overlaps with half of a global u32. In C/C++ you could cast a pointer that way and turn it into a reference, but the compiler is allowed to assume, even though you wrote that, that the u16 (unsigned short) reference can't refer to some particular global u32 (unsigned int), and if it has it in a register it won't reload it. The program has undefined behavior (you could use unions and get implementation-defined behavior, which will depend on little-endian vs big-endian).

Re: GCC Rust Approved by GCC Steering Committee

#286

Post by zRedShift »

steveklabnik wrote: post #281
dleslie wrote: post #279

Earlier quoted context omitted.

The toolchains support helps embedded developers, mainly. For example, Xtensa and AVR toolchains are generally byzantine monstrosities of makefiles, Python, dialog, etc; so having them be given a low effort means to consume rust is a boon. Ideally, rust is just another source file in the srcdir soup. That said, gcc supports more platforms than llvm; including esoteric and unpopular desktop configurations. Personally,…

Incidentally, Xtensa has hired someone for the last… year or so? To make using Rust on their stuff work well. AVR support is almost there in mainline rustc but has a codegen bug or two, last I heard.

I think you meant Espressif, Steve. They have a fork of LLVM with Xtensa support they’re looking to upstream (still a few things missing, like the DSP/AI instructions in ESP32-S3, and I think the codegen is better on GCC for now). And the folks at esp-rs who work at ESP and outside contributors maintain a Rust toolchain and standard library (based on ESP-IDF) which they also want to upstream. There’s also a baremetal target which has a dedicated developer in ESP, it’s pretty amazing. Although esp32-s3 is going to be the last Xtensa chip from them, they’re planning on moving to RISC V, wholesale, with all their products in the last year based on it. Ferrous Systems even designed a Rust specific devkit based on their RISC V esp32-c3, to teach embedded Rust on.

I bet Cadence was ripping them off for the IP, which is a shame…

Any talks in Oxide about porting Hubris to RISC V? I hear getting your hands on Cortex-M*s in bulk is still pretty challenging these days.

Re: GCC Rust Approved by GCC Steering Committee

#287

Post by steveklabnik »

zRedShift wrote: post #286
steveklabnik wrote: post #281

Earlier quoted context omitted.

Incidentally, Xtensa has hired someone for the last… year or so? To make using Rust on their stuff work well. AVR support is almost there in mainline rustc but has a codegen bug or two, last I heard.

I think you meant Espressif, Steve. They have a fork of LLVM with Xtensa support they’re looking to upstream (still a few things missing, like the DSP/AI instructions in ESP32-S3, and I think the codegen is better on GCC for now). And the folks at esp-rs who work at ESP and outside contributors maintain a Rust toolchain and standard library (based on ESP-IDF) which they also want to upstream. There’s also a baremetal…

Ahh whoops you’re right, lol. Embarrassing.

Hubris was designed to be easy to port to RISC-V, so yes! We didn’t end up doing that though. Someone else did though! https://github.com/oxidecomputer/hubris/discussions/365

Re: GCC Rust Approved by GCC Steering Committee

#288

Post by kragen »

dolni wrote: post #271
kragen wrote: post #141

Earlier quoted context omitted.

No, the idea of freedom of speech predates the US Constitution, by decades, centuries, or millennia, depending on your definition: https://en.wikipedia.org/wiki/Freedom_of_speech#Origins https://en.wikipedia.org/wiki/Freedom_of_thought#/media/File... https://en.wikipedia.org/wiki/Freedom_of_thought#History_of_... https://en.wikipedia.org/wiki/Areopagitica https://en.wikipedia.org/wiki/Freedom_of_the_press#History htt…

Do you think that the free software movement would have adopted "free as in speech" if the US was hostile to free speech?

Certainly, but it would have started somewhere that wasn't hostile to free speech. The Netherlands 20 years from now, maybe, or Korea when the computer is invented 150 years in the future in the early stages of the Industrial Revolution.

Re: GCC Rust Approved by GCC Steering Committee

#289

Post by tialaramex »

not2b wrote: post #284
tialaramex wrote: post #243

Earlier quoted context omitted.

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

You are incorrect. The C++ standard says a whole lot about it, and has detailed aliasing rules and rules about which pointers are valid. Your "magic trick", depending on details, isn't a standard conforming program; the standard will say that it has undefined behavior. That's why, as you say, the optimizer assumes you can't possibly have such a pointer, but what you get wrong is that the C++ standard describes the ru…

>> The C++ standard says a whole lot about it

Nope, it says nothing whatsoever on the subject of provenance. Periodically people make a run up and try to get this fixed. N2676 is currently in front of WG14 (ie the C standards committee) with the long term hope that if WG14 takes this fix, or something like it, WG21 (C++) could be persuaded to eventually take a similar fix - although lots of people don't like N2676 and want something else (the more vague your "something else" the more popular). If the standard had "a whole lot" to say about provenance you'd be able to quote some of it. but I suggest reading N2676 for an example of what is not yet standard

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2676.pdf

> has detailed aliasing rules and rules about which pointers are valid

Aliasing rules forbid some type punning shenanigans, but again, and I will repeat myself, that's not what's going on here.

DR260 (Defect Report number 260, about twenty years ago) asks WG14 what their standard says about such magic tricks, and their response basically says well, compilers are allowed to somehow know about provenance, so actually our Standard is correct and this is working as intended. What's working as intended? Well, whatever your compiler actually does.

What a great standard! Note that this response isn't incorporated into subsequent versions of the standard, it's just basically known in the industry, oh yeah, that's DR260, don't worry about it.

> I've been doing this stuff for a long time, going back to egcs and even before.

That's nice, but it's not terribly relevant here, except that it means you remember an era when people didn't even realise this was a problem. It still was a problem, they just didn't know it was a problem yet. And hey, you know about that experience too, because apparently you didn't know this was a problem after 2004 either.

Rust would like not to kick this can down the road for 18 years and counting, which is why Aria Beingessner's experiment is happening.

Re: GCC Rust Approved by GCC Steering Committee

#290

Post by tialaramex »

not2b wrote: post #285
steveklabnik wrote: post #226

Earlier quoted context omitted.

As a small point of order here (not saying you're wrong, just to elaborate a bit): * Rust doesn't have strict aliasing/tbaa * Rust does have "restrict" semantics (in C via the keyword and in C++ via common vendor extensions) And yeah, Rust is considering a provenance model that's different than PNVI-ae.

Yes, understood. But in Rust (without going through unsafe code), you can't write a program that will produce a reference to a u16 that overlaps with half of a global u32. In C/C++ you could cast a pointer that way and turn it into a reference, but the compiler is allowed to assume, even though you wrote that, that the u16 (unsigned short) reference can't refer to some particular global u32 (unsigned int), and if it…

> without going through unsafe code

None of this matters in Rust without unsafe. Pointers technically exist outside unsafe, but you can't do very much with them (you cannot, for example, dereference a pointer). And yes, Rust says that the attempted type pun you describe, which you would need unsafe to create, is Undefined Behaviour.

> you could use unions and get implementation-defined behavior

Type punning with unions is also Undefined Behaviour in C++. The sanctioned way to perform type punning is to memcpy() the data from type A to type B. C++ 20 provides a built-in way to ask for this to be done std::bit_cast

Post reply on HN