111–120 of 300 posts
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.
Quoted post unavailable.
> Throwaway accounts are ok for sensitive information, but please don't create accounts routinely. HN is a community—users should have an identity that others can relate to.
Earlier quoted context omitted.
At a high level, GCC and LLVM are divided into two ends: the front and the back. The front end takes the source code and turns it into some form that's language agnostic (e.g. LLVM bitcode). The back end takes those structures and turns it into machine code. This allows the compiler to be modular. Old compilers didn't use this concept. So a C->x86 compiler and a Fortran->x86 one couldn't share code as easily. And if…
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…
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 C++ programs)
As I understand it an example when it comes to aliasing would be what happens if somebody typed a bunch of ASCII into a prompt and then the program... uudecodes the ASCII to get an integer, and begins just using that as a pointer to rummage around in some data structure.
Is that... OK? Obviously you can't do this in safe Rust, but even unsafe Rust says er, no, that's definitely not allowed (it might actually work but it isn't OK). But the ISO C++ standard says that so long as the ASCII string happened, by some cosmic accident, to be a "valid" address for a pointer after this transformation this works fine even if it now magically aliases a pointer we otherwise had no reason to believe could be aliased.
If we allow this, many optimisation opportunities vanish. So, LLVM doesn't allow it. Our "correct" C++ pointer uudecoding program doesn't work. However, a blanket prohibition blows up real tricks that people actually do, such as hiding flag bits in address values (unlike uudecoding ASCII inputs to make pointers). So LLVM provides behaviour that's not formally standardised anywhere but can be thought of as something akin to PNVI-ae (Provenance Not Via Integers - Address Exposed). If the program "exposes" addresses from pointers, then the compiler assumes it could see those addresses "magically" appear from somewhere else (e.g. a uuencoded string) and so it must choose optimisations accordingly.
One day perhaps C++ will actually document PNVI-ae or some similar scheme in the ISO standard. That day is not today (nor next year, this will not happen in C++ 23) but meanwhile you've got the problem that, in unsafe Rust you actually get whatever arbitrary semantics that were delivered by LLVM. Since they're not just "This is what C++ does" but only "This is how C++ works in Clang" that's even less portable.
As I wrote, this only burns unsafe Rust. If you don't write unsafe and just depend on other people's stuff to use that as necessary (e.g. obviously the standard library is full of unsafety) then it's not your problem to fix this when it breaks. But it sure would be nice if the people writing unsafe code would have more certainty on this sort of topic.
Rust is experimenting with "Strict Provenance" rules to see what happens if, instead, it makes its own provenance rules and dispenses with waiting for C and C++ programmers to actually decide what the rules are in their languages. https://doc.rust-lang.org/std/ptr/index.html#strict-provenan...
This is great! Gcc support opens up more platforms, more targets, and the opportunity to more easily integrate with the various common embedded toolchains that are built around gcc. And it's free software, for those that care, this matters.
> free software it seems like this term is misunderstood in English to mean "no money" .. perhaps "Libre Software" is a better starting description here
To understand the concept, you should think of “free” as in “free speech,” not as in “free beer.” We sometimes call it “libre software,” borrowing the French or Spanish word for “free” as in freedom, to show we do not mean the software is gratis.
Earlier quoted context omitted.
I didn't see this mentioned in any replies, but I think another reason why this is wanted is for Rust in the linux kernel development. If Rust can compile using GCC tooling, it should be easier to integrate into the build process for the Linux kernel. As it stands now, if Linux kernel development allowed Rust in areas of the kernel outside of modules and drivers, you need the GCC tool chain to build the kernel and th…
And while you can link a gcc-compiled kernel with llvm-compiled rust, apparently you lose some link-time optimization, and with that control-flow integrity [1]. That's a potential security concern for the kernel, in addition to the usability issues of using two toolchains. 1: https://www.cs.ucy.ac.cy/~elathan/papers/tops20.pdf
Earlier quoted context omitted.
> free software it seems like this term is misunderstood in English to mean "no money" .. perhaps "Libre Software" is a better starting description here
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.
Earlier quoted context omitted.
Yes, hence having its own column on cppreference, or a special flavour of bitcode for watchOS. In what concerns Apple, I think they mostly care about the C++ support needed to keep LLVM going, the C++14 based dialect for Metal Shading Language, and the subset used across IO and DriverKit. For everything else there is Objective-C and Swift. Then Google apparently drop off clang after the ABI break votes didn't went th…
Yep, the perma-frozen ABI decision sounded the death-knell for C++. Basically the committee committed collective hara-kiri with that decision. Thou Shalt Not Progress! It's so extraordinarily, mind-bogglingly stupid. But I guess it is time for the ageing C++ queen to pushed out of the mortal coil and let Princess Rust grab her long-overdue system crown.
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.
I have never understood why it was not called "Liberty Software" since the beginning. The confusion disappears, liberty exists in English as a sibling to "libre" from Spanish and French and everybody in the United States, where the term originally comes from, and the rest of the English-speaking world understands what it means. As for the grammar argument, you can--sort of--force `Liberty` to be an adjective (think "…
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.
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.
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.