Thread 106286675

Rust doesn't have this problem.

>>106286675 (OP)
works on my machine

neither does seppples

doubt

>>106286675 (OP)
i don't get it

Fake and gay. Possibly a compiler bug that has since been patched.

>>106286736
Code shouldn't show any hello world but it's showing it, meaning the compiler of the language is fucked up

>>106286736
An infinite loop is considered undefined behavior, so it was optimized away along with the rest of the function, including the return statement, since none of these should ever be executed.

>>106286803
>>106286736

>>106286814
so, did the compiler skip actual main function and regard unreachable() as main function?

>>106286814
so the compiler detects the infinite loop and since it's technically undefined behavior decides to not even the whole function?
lazy as fuck, just loop fuxkhead im trying to warm up the xpu

>>106286803
>An infinite loop is considered undefined behavior
Only some infinite loops are undefine behavior. while (1) and for (;;) are explicitly blessed, and any other loop that's found to be infinite at compile time is supposed to work as expected although there have been a lot of compiler bugs about them. The optimizer is only allowed to assume loops are finite if it's not told they're infinite.

>>106286675 (OP)
>Rust doesn't have this problem.
It does actually, it bears remembering that LLVM started out as a C++ optimizer and rustoids had to piss and shit themselves in public for about 11 years before they were able to get the loop behavior they wanted out of it. There were a lot of assmad blog posts about it at the time but if they didn't want C++ they shouldn't have used C++ because that's what LLVM is it's C++ for C++ not rust

not a problem in c++26, trivial infinite loops are no longer undefined behaviour

>>106286933
Why didn't rustfag build their own compiler backend instead of relying on llvm, which is dogshit?

>>106286675 (OP)
I just checked, it didnt print, just looped indefinitely.

>>106287050
It's a meme lang that's why

>>106286933
Despite using LLVM, Rust does not have this problem. If you drop something like this:
#[no_mangle]
pub fn main() {
loop {

}
}

pub fn unreachable() {
println!("Hello World!");
}
into Godbolt, you will find that main correctly has the infinite looping behavior. Turns out, while LLVM may have started as a library for use by Clang, it has evolved into a library intended to be used by a wide variety of languages, some of which may not make the same assumptions as C++.

>>106287050
The entire point of LLVM is that nobody has to write a backend ever again. Language development would be stunted if every language had to implement a backend for every target. And software compatibility would be fucked for new platforms if they needed to implement a backend for every language. Compiler backends should be language indpendent, and compiler frontends should be independent of code generators.

>>106286675 (OP)
>#include instead of import
>cout instead of println
Brown stinky jeet hands typed this post.

>>106286675 (OP)
>writes retarded code
>gets retarded results
Skill issue

>pc not increasing is undefined behavior
wat

>>106286675 (OP)
>>106286730
>>106286736
>>106286759
While I am not an expert on this subject, this is my impression:

Having a trivial infinite loop that does nothing was in versions of C++ prior to C++26 undefined behavior, for the sake of letting the compiler make assumptions and optimize further.

In C++26, this is no longer undefined behavior.
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2809r3.html
While this may constrain what optimizations can be done, if a programmer writes a trivial infinite loop, the intention was probably not that optimizations should be done.
A subset of other types of non-trivial infinite loops still cause undefined behavior as I understand it, to enable optimization.

These decisions are trade-offs. For instance, the Rust ecosystem is in some ways some of the time working in the other direction, providing more functions that are unsafe for the sake of enabling programmers to write programs that have better optimization possibilities, at the cost of increased difficulty and risk.
https://doc.rust-lang.org/std/primitive.i64.html#method.unchecked_add
Though Rust does hide it behind its "unsafe" keyword, making it clearly opt-in regarding risk of undefined behavior (though Rust's guarantees has some issues, drawbacks and practical limitations, such as when using no_std).

The past behavior of C++ caused a bug in Rust once.
https://github.com/rust-lang/rust/issues/28728

In general, except for some patterns of usage like typical trivial infinite loops, if a non-trivial infinite loop has no IO and such, it is likely a bug by the programmer, since such a loop would basically never be useful.

>>106287637
I use such loops all the time, fuck off stupid nigger.

>>106287647
Could you give an example of such an infinite loop, that is not trivial, and also has no IO or other relevant effect?

According to P2809R3:

// unchanged (undefined behavior if external doesn’t contain a side-effect)
void external();
while (true)
external();

>>106287669
you'll know when you need it yourself if you aren't a nocoder

>>106287669
If external is in another TU (compiler cannot know about whether it provokes a side effect or not) but does not contain a side effect then my program exhibits UB? That cannot possibly be correct.

>>106287193
>The entire point of LLVM is that nobody has to write a backend ever again. Language development would be stunted if every language had to implement a backend for every target. And software compatibility would be fucked for new platforms if they needed to implement a backend for every language. Compiler backends should be language indpendent, and compiler frontends should be independent of code generators.
While I think there is a huge amount of value to LLVM, and that it is good that it enables a lot of reuse across programming languages, some people are critical of LLVM. Though I am not sure if they are critical of LLVM as a concept or LLVM specifically as it is in practice. Zig, for instance, has work on other backends than LLVM.
https://ziggit.dev/t/can-someone-explain-why-zig-is-moving-away-from-llvm-but-in-simple-way/1226/6?u=andrewrk
https://ziglang.org/devlog/2025/#2025-07-23
I personally think that there should be room for both approaches, and that variety is fine and beneficial here. Even though it could be seen as split efforts, it also means not betting everything on one approach, and also having a more varied and probably healthier ecosystem, despite there being limitations in terms of experience, research, money, talent, volunteer work, etc.

GCC has evolved to also support multiple languages, though I do not know how it compares to LLVM on this point. LLVM has IR or something.

The usage of Rust may have also benefited other languages, since in practice for instance C's "restrict" (for no-aliasing optimizations) is rarely used in C, and therefore compilers for C were in practice often buggy for that use case, since it was a path very rarely tread by C programs. But Rust has no-aliasing optimizations basically everywhere internally as I understand it. I do not know if LLVM in turn has become less specialized for C or C++, however.

>>106287707
Do you agree or disagree with the reasonings in P2809R3 ?

undefined behavior should not exist. it's complete BS.
all compiler authors should be forced to write up a document explaining what they do in all cases of erroneous behavior on each platform and it should always be something reasonable.

read a dangling pointer? if the page was unmapped then page fault, otherwise it will just read whatever is in there.
unaligned memory access? on x64, nothing
etc

>>106287830
You are correct.

>>106287776
P2809R3 cites some optimization opportunities like reordering loops or something.

>It is easy for the C++ Standards Committee to instead align with C, and allow "trivial" infinite loops as C does. However, care must be taken when doing so. C++ has good reasons to specify that infinite loops are undefined behavior: it is desirable to express forward progress guarantees in a programming language because it unlocks a design space in concurrency and parallelism software and hardware design. An 80 minute deep-dive in this topic is available in [ForwardProgress]. A definition of "trivial" which continues supporting this design space is important to reach.
https://www.youtube.com/watch?v=CuWM-OrPitw

>>106286675 (OP)
Rust won

>>106287830
>>106287838

>>106287647
retard

>>106286814
Seems to be a regression in 13.0.0 and fixed in 19.1.0.

>>106287887
Rust and clang use the same compiler shit, so probably would have had the same issue.

>>106287915
>>106287920

>>106287637

>>106287894
give me ONE reason why undefined behavior should exist. give me ONE reason why OP's pic should ever happen.

>>106287050
A lot of work for basically no gain

>>106287050
Way ahead of you!
https://cranelift.dev/

>>106286883
>while (1) and for (;;) are explicitly blessed
In C. C and C++ are two different languages. There is no C/C++. They're as different as C++ and Rust.

>>106286675 (OP)
odd, clang++ has these only with O1/O2/O3 , g++ doesnt

im on clang 20.1.8, is this a recent new thing?

>>106288087
P2809R3 makes C and C++ closer to each other on this subject, though not the same on this subject.

>>106287969
Holes in the specification, most of them are on purpose for various reasons such as being incorrect/useless code(see OP) or just being the most appropriate thing to do
>>106287669
Crash handling, some compilers let you set the crash handler to an infinite loop instead of the language's or the stdc's
It's of limited use on a PC but for embedded os-less software it might be relevant?
>>106287515
Rust people are like narcissists, they do not operate on logic but on whatever's convenient for the hivemind.

>>106287969
>give me ONE reason why OP's pic should ever happen.
It doesn't happen with P2809R3.

>give me ONE reason why undefined behavior should exist.
1: Rust, both safe and unsafe, allows for undefined behavior. In safe Rust, add no_std and then cause a stack overflow.
2: Optimizations may in some cases become easier for a compiler to figure out if some program semantics are declared undefined.
3: It may be too expensive computationally at runtime, or not feasible, to ensure the semantics of the programming language to in all possible cases not have undefined behavior, at least in certain very constrained embedded systems.

Many other aspects are probably more complex.

>>106288174
>Crash handling, some compilers let you set the crash handler to an infinite loop instead of the language's or the stdc's
>It's of limited use on a PC but for embedded os-less software it might be relevant?
Might that be covered by trivial infinite loops, instead of non-trivial infinite loops? C++ used to have UB for trivial infinite loops, but P2809R3 changes that.

>>106287794
>GCC has evolved to also support multiple languages, though I do not know how it compares to LLVM on this point. LLVM has IR or something.
GCC has an IR called GIMPLE. And like LLVM IR, it also supports JIT stuff. I would think it reasonable for a new language to target either LLVM or GCC, but it would be weird to say "write your own code generator and optimizer".
>I do not know if LLVM in turn has become less specialized for C or C++, however.
Well, it's used for so many other languages that it would be a bit odd for it to still be specialized for C++.
>>106287830
Things like "read a dangling pointer" are more accurately "implementation defined" behavior. It's just that nobody wants to specify this shit for every implementation. Not every platform has "page fault" as a thing that exists.

>>106288364
>Not every platform
An overblown problem. Any new language starting design in 2025 realistically only has to care about 3 cpu architectures and 3 operating systems maximum. And several behaviors are inherently identical across all 9 possible permutations thereof, page faulting among them.

>>106288386
The people writing language specs don't care about unpredictability or hardware heterogeneity, they define undefined behavior based on what they hope might help their broken optimizers squeeze an extra 0.0001% performance out while risking killing a hospital full of people when it causes a bug. C still doesn't require floats to be IEEE 754, or integers to be 2s compliment, or bytes to be 8 bits.

>>106288413
C doesn't require compilers to support dogshit hardware either, your point?

>>106288364
i was describing what would happen on x64. on other platforms it would be different.
>It's just that nobody wants to specify this shit for every implementation
they should, because the alternative to that (undefined behavior) is the stupidest concept to ever exist. C++ comittee can greatly improve the language just by getting rid of it, and doing that would be fully backwards compatible.
>>106288174
>>106288258
none of these are good reasons since you can just do this >>106287830:
>all compiler authors should be forced to write up a document explaining what they do in all cases of erroneous behavior on each platform and it should always be something reasonable.

the performance excuse is extremely dubious to me. what real optimizations would you lose if you just made things implementation-defined instead? compiler vendors would just default to saying "whatever the hardware does" and leave it at that, which sounds pretty performant to me.

LLVM's C++ API is really unpleasant to work with.

>>106288386
>>106288413

>>106287894

>>106288499
>>106287894

>>106288562
>>106288549
>0 arguments
imagine being an undefined behavior advocate and you cannot even make up one bullshit argument to cover your ass lmao

>>106288258
>Rust, both safe and unsafe, allows for undefined behavior. In safe Rust, add no_std and then cause a stack overflow.
Stack smashing protection detects stack overflows in no_std Rust environment.
Also "because bare metal Rust can cause UB" is not a good reason to why make infinite loop in C++ an UB.

>>106288617
>Stack smashing protection detects stack overflows in no_std Rust environment.
Yet no_std disables the protections against UB stack overflow in Rust, as far as I know. Do you have a source to the contrary?

>Also "because bare metal Rust can cause UB" is not a good reason to why make infinite loop in C++ an UB.
This is moving the goal posts and attacking a strawman.

https://materialize.com/blog/rust-concurrency-bug-unbounded-channels/
https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF
https://bpb-us-e1.wpmucdn.com/sites.gatech.edu/dist/a/2878/files/2022/10/OSSI-Final-Report-3.pdf
https://archive.ph/uLiWX
https://archive.ph/rESxe
https://lkml.org/lkml/2025/2/6/1292

>>106286675 (OP)
>clang
That's a (You) problem. Only gcc is a valid compiler for c.

>>106288258
>Rust, both safe and unsafe, allows for undefined behavior. In safe Rust, add no_std and then cause a stack overflow.
This rarely happens because what you see in dev mode is pretty much what you will get in release mode.

You won't get this with C

>>106286730
There used to be a bug in Clang. somehow compiler deduced that main never terminates and just didn't generate the return and epilog. and when the execution eventually terminated the main it just fell through to next function in memory.

You can encounter a similar bug in C/C++ when you forget to return - by default it's a warning and not a bug.
But the fucking compiler sees this, assumes programmer thought the function should never return and just doesn't generate return instruction and the same thing happens. And this is NOT a bug according to compiler developers.

If I put this to godbolt
int main()
{
while (true);
}

void next()
{
__builtin_trap();
}


clang 12 is works fine
clang 18.1 to 13.0 outputs the fallthrough (at least some optimizations need to be enabled, -Og -Os or -O1)
main:

next():
ud2

clang 19 works fine again

>>106288663
>Yet no_std disables the protections against UB stack overflow in Rust, as far as I know. Do you have a source to the contrary?
https://doc.rust-lang.org/beta/rustc/exploit-mitigations.html#stack-smashing-protection

>>106286814
>>106286675 (OP)
Doesn't work in c.

>write a for loop
>the compiler optimizes it away
https://www.youtube.com/watch?v=vTxT5nsTh7E

>>106287637
this
/thread

>>106289210
do you work for nintendo?
does your son post on 4chan?

>>106287986
Should have been worked on as the default from day 1. The more compilers that are independent from LLVM the better.

>>106286675 (OP)
Nobody writes code like that so it's not an issue in practice, but this is: https://www.youtube.com/watch?v=vTxT5nsTh7E
If you for example have an array of size 9 and then a for loop that does for(size_t i = 0; i < 10; ++i) then gcc will know that your code is incorrect, but instead of reporting that it just removes the condition check, and ends up with an infinite loop that loops through all of your memory.

>>106286675 (OP)
>meanwhile in rust

>>106289393
>what is pointer provenance

>>106286840
It depends on how you look at it. It "calls" the main function, but since its empty and is missing return it just continues running instructions in memory. In this case it just so happens that "unreachable" function is placed after that in memory so it runs into that.

>>106289400
That's comparing integer values, not pointers. It fails for the same reason as OP: undefined behavior.

>>106286675 (OP)
Yet another Rust W.

>>106289423
it's a W for C++ though
Rust doesn't exist without LLVM

>>106289520
>Rust doesn't exist without LLVM
And it is not a problem.

Hare doesn't need LLVM.

>>106289708
And programmers do not need Hare.

>>106289708
because it uses QBE which generates slower and fatter code

>>106287669
testing kernel cpu process/thread schedulers

>>106289165
That is stack smashing protection, not stack overflow protection. And it relies on checking upon function return, while stack overflow UB can happen without ever returning from a function AFAIK. And the stack smashing protection is only mitigation as far as I can tell.

Basically, you're completely wrong.

>>106289210
>>106289389
He had undefined behavior in his program, the fault is purely his own.
If he wants easy-to-handle bounds checking, then he should use C++ and its abstractions, or Rust, or some other language, instead of C.

>>106289393
>>106289400
>>106289415
Rustacean samefag?

>>106289644
It is, and gccrs, Cranelift and other projects are in principle good things.

>>106286814
why does it keep the unreachable function if it's unreachable?

>>106286675 (OP)
Have you ever considered writing good code

>>106290399
But couldn't you then just either have a trivial infinite loop, or a non-trivial infinite loop that has some suitable effects?

>>106287969
Removing destructor calling code in generic collections for type where destructor does nothing.

>>106289402
i see

>>106290848
imagine an infinite loop with a SIMD call inside it for example.

>>106287920
It unironically doesn't

>>106286675 (OP)
>compiler fucks up nonsensical code
>blames the language

>>106288670
>make new language
>promise it NEVER HAS BUGS
>use it
>HAS BUGS
>tfw

>>106291315
Would it be viable for such a test to limit it to some very large number of iterations in a for-loop? Or would that not work, or hinder the test?

>>106291321
Rust literally had this issue until 2021 or smith. I think only llvm 13 fixed this. The original bug in llvm was open since 2006

>>106291451
how about you stop moving the goalpost
>Could you give an example of such an infinite loop, that is not trivial, and also has no IO or other relevant effect?

>>106290813
It isn't

>>106290814
If they added static to the function it would be removed from the assembly since the compiler knows it isn't used anywhere else, but since it isn't, it could be possibly called from another source function. Link time optimization can also optimize it out

>>106289210
If he used warnings and static-analysis, it would've told him about the possible buffer overrun. Not that it's perfect of course, but you should use the tools available: https://github.com/cpp-best-practices/cppbestpractices/blob/master/02-Use_the_Tools_Available.md

>>106286675 (OP)
That was a compiler bug, and you can put your rust turd deep inside your asshole.

>>106291670
The original claim:
>In general, except for some patterns of usage like typical trivial infinite loops, if a non-trivial infinite loop has no IO and such, it is likely a bug by the programmer, since such a loop would basically never be useful.

That claim does open up the door for peculiar cases, and I would argue that doing busywork in an infinite loop with any work done being thrown away, with the loop there purely for testing, and with no effects, constitutes such a peculiar case. If the non-trivial infinite loop never has any effects, it cannot really be used normally, and is only really useful indirectly for a test program or some purpose that is similarly rare. Since it is infinite, it also would probably not be possible if I understand correctly to properly stop its thread of execution without taking down the whole process.
https://stackoverflow.com/questions/12207684/how-do-i-terminate-a-thread-in-c11
It seems really awkward.

And for a test program, wouldn't a for-loop with a very large maximum number of iterations, be a decent substitute?

>>106291733
LLVM and rustc are both open source, which helps, but being reliant on just one compiler means that any major issues with that compiler or its general development that makes it undesirable or not an option to continue with it, will require work and effort to either make a new compiler for Rust from the ground up or fork the relevant components.

It is not nearly as bad as if it was closed-source and proprietary, vendor lock-in has killed many companies, and for ecosystems like Flash, it took years and lots of donations and volunteer work before alternatives to Flash player began appearing, a major alternative is Ruffle (written in Rust), and that is not yet completely up to par with Flash player.

But rustc has the issue of both having some LLVM-specific assumptions, and especially having very complex type system and solvers. The number of people in the world that understand Rust's type system and solvers in depth might be very, very small, and the subject is actively being researched and worked on, such as with the new Polonius solver. Polonius being a solver that last I heard could be as slow as 5000x slower than the current solver, making people suggest only using it for specific cases, not as a wholesale replacement of the current solver as I understood it.

I am not sure how gccrs will handle solvers. Will they use both the current solver and also Polonius?

What is the bus factor for specialists in Rust's type system and solvers?

>>106292171
>>106287637

>>106292268
>Since it is infinite, it also would probably not be possible if I understand correctly to properly stop its thread of execution without taking down the whole process.
taking down the whole process is valid in some cases. and pthread_kill() exists anyway. no one cares about the solution being "portable" or in std, especially for the use-case presented, which is platform specific anyway.
>wouldn't a for-loop with a very large maximum number of iterations, be a decent substitute?
no
------
i think you've been told before that this is not a debate club for training your retarded LLM, or whatever it is you're doing on /g/ lol

>>106292472
Having one backend means everyone focuses on improving that one. It's better this way than having multiple compilers, each implementing different subset of language with different quirks.
I never heard about any Rust project being blocked by a major issue in LLVM.

Which /g/tard has that meme on hand where some rustroon boasted about how simpler Rust is compared to C in a basic Hello World, but then someone brought up how the print function is a macro that when unwrapped is a bloated heap of shit?

>>106292863
incidentally, rustc_codegen_gcc is blocked on some libgccjit limitations. lol.
the polish kid who developed rustc_codegen_clr have been doing GSoC work on rustc_codegen_gcc this summer. the backend improved in general. but the focus is on improving support for non-mainstream targets.
https://github.com/rust-lang/rustc_codegen_gcc/issues/49
so, i say watch that space.
in any case, cranelift has been great for super-fast debug builds for some time already.

So you need to be careful as to the type of infinite loop you dream about.

>>106286736
non-conformant main() function, declared as returns int, but doesn't not have a return statement.
compiler goes looking for what will be in cpu cache to output instead of declared.
compiler goes crazy, because function is not actually conformant to spec, as int main() must return int.

>>106286675 (OP)
>>106293199
also
-Wall -Wextra

ikr, who would've thought? :DD

also go ahead and use pedantic for 1337 haxx0rz

>>106293084
macro_rules! eprintln {
() => {
$crate::eprint!("\n")
};
($($arg:tt)*) => {{
$crate::io::_eprint($crate::format_args_nl!($($arg)*));
}};
}

>he thinks va_args are better
i think you are the meme desu

>>106293084
In the meantime, printf is huge pile of macros. Rust fmt is much simpler in comparison and doesn't have runtime overhead of parsing format strings.

>>106292863
All the top programming languages have multiple compilers or runtimes for them. Javascript, C, C++, Python, Java, PHP, C#, etc. Yes, it requires more work, but it also means that not everything relies on just one implementation.

And you didn't address the very high complexity of the type system and solvers.

Posts in this thread have mentioned LLVM bugs affecting Rust.

Overall, I wonder if it could be worth investigating how and why all the major languages ended up with multiple compilers or runtimes, at least those that were open source to begin with. For instance, Mono for C# added Linux support for the C# language, and some of the Python runtimes are faster or have special concurrency focus. Javascript probably had too much of a peculiar development story, with the browser wars, to really compare with. gccrs would add support for more platforms that LLVM does not support, though rustc does have something like a gcc backend. Would gccrs offer other features or properties relative to rustc and LLVM?

>>106293199
>>106293220
Not all types of infinite loops are allowed in C++, and it has changed by version what is and is not allowed.

>>106293084
>>106293379
>>106293480
Samefag.

>>106293606
>but it also means that not everything relies on just one implementation.
Non issue

>you didn't address the very high complexity of the type system and solvers.
Because it is irrelevant to Rust using LLVM as the backend.

>>106286814
This is what happens when you insist on trying to construct the denotational semantics of a program with infinite loops. It decides that the code in main() must be an infinite loop followed by some unreachable code, optimises the loop away, and converts the function to a call in to the magical builtin with that name. (That's the first bug: it really shouldn't remove the loop.) Except that the user-defined function with the same name intercepts the call. (That's the second bug; the real builtin intrinsic ought to have a name that's illegal in C.)
Everything else follows; a function that does nothing but call another function with the same signature can be optimized by putting the two functions in the same memory location.

>>106295448
It's not a bug. It's optimizing based on undefined behavior

>>106295644
>its not a bug, its a bug the compiler deliberately introduced without telling you. That isn't a bug because we say it isn't
Cniles, everyone

>>106296031
nothing can be described as a bug in the presence of undefined behavior retard, because all claimed "bugs" are a subset of the undefined behavior universal set.
nta btw.

>>106296120
Precisely my point. These are obviously "bugs", by any reasonable definition, but because C and C++ are such dogshit languages, they have to lean on UB to avoid any sort of responsibility.

>>106296214
Not a bug when it's explicitly written as illegal in the standard

>>106296338
UR A DUMBO

>>106296338
You realize other languages have things are are "explicitly written as illegal in the standard", right?

They're called compiler errors.

>>106296338
>>106296438
Actually, hang on, you've got me thinking about this now. Aren't you Cniles always going on about how much "control" your language gives you? How "close to the hardware" it is? How do you square that with a compiler that's allowed to completely re-write the intent of your code, or insert new code that you never wrote without so much as the decency of a warning? How much "control" do you actually think you have?

>>106290814
Symbol visibility on Linux is a funny thing. Because of symbol interposition (e.g. LD_PRELOAD to replace malloc) all default visibility symbols within a library are technically modifiable by the dynamic linker at load time, since they could be replaced with a symbol from another library.

>>106296567
Not a Cnile, I was correcting the record. A lot of people here don't seem to have any idea what they're talking about.

>>106296567
the dissonance is maintained by the incorrect idea that c is a low-ish level language when it is not
the c standard describes a high-level language running on a virtual machine just like java
vendor-provided dialects of c might be truly low-level for its corresponding chip but the overwhelming majority of c code is c standard code

>>106294408
Wrong and ignoring relevant arguments.

Is this politicking for the sake of maintaining influence? If there is only rustc, everyone is beholden to whoever holds the reins of rustc development? I know that some rustaceans themselves have decried apparent conflict with gccrs, as if there were opposition to gccrs.

>>106295448
>>106296031
>>106296214
Yet Rust has plenty of cases where undefined behavior can happen as well.
https://materialize.com/blog/rust-concurrency-bug-unbounded-channels/
And there have been a lot of it in the Rust ecosystem, Rust would have been lost without Miri.

>>106296358
>>106296438
>>106296567
Are you being completely incompetent on purpose, or are you really that much of a poser that shouldn't be allowed near any computer?
https://materialize.com/blog/rust-concurrency-bug-unbounded-channels/

>>106286675 (OP)
This is no longer the case:
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2809r3.html

>>106299327
>Wrong and ignoring relevant arguments.
Your arguments make no sense. They boil down to "having one compiler backend is bad because it means you only have one compiler backend". You have provided no real example where this was actually a problem beyond "some time ago there was some LLVM bug" as if having multiple backends would save you from having bugs in a backend.

Show an example of non trivial Rust project that was canceled, abandoned or blocked for considerable amount of time because of some LLVM bug.
If there is no such case then all this FUD you are trying to spread is just your fantasy.

>106288670
>106299346
>106299356
If I spam same article over and over again I will finally get a (You)!

https://desuarchive.org/g/search/text/https%3A%2F%2Fmaterialize.com%2Fblog%2Frust-concurrency-bug-unbounded-channels%2F/

>>106286736
>i don't get it
brain dead

the whole shit is self explanatory

>>106300194
You are wrong yet again, and it is your arguments not mine, that make no sense. And my arguments did not rely on providing specific examples. For instance, before Flash player was removed from browsers, it was perfectly valid and logical to be skeptical or cautious about the reliance on a single proprietary runtime like Flash player. Likewise for vendor lock-in, before a technology is chosen, being cautious about just one supplier for a given technology can be perfectly reasonable and logical.

Why would disaster have to happen before even discussing potential issues?

But there are some possible examples, I recall having seen some people appear to have abandoned Rust after exponential-time compiler regression bugs were not resolved. Like, a Rust project compiled fine, but after a compiler version upgrade, the compilation times went exponential or even ended consistently in crashing. That may be one use case for gccrs - if for instance rustc upgrades its version, and it fucks things for some projects, projects might be able to switch to gccrs. However, this might not work all that well if rustc and gccrs share the same solvers.

Are you biased? Do you have great personal investment in rustc or LLVM, as per >>106299327 ? Or is all that you are concerned about truly just split effort?

>>106300204
Complete lack of counterarguments.

>>106300559
>For instance, before Flash player
Not LLVM nor Rust

>reliance on a single proprietary runtime
LLVM is not proprietary

>Like, a Rust project compiled fine, but after a compiler version upgrade, the compilation times went exponential or even ended consistently in crashing
You are yet to name any non trivial Rust project that was canceled, abandoned or blocked for considerable amount of time because of some LLVM bug.


Post an actual example of this being a problem in actual Rust project.

>>106300599
>Not LLVM nor Rust
I see, you're just lying and trolling, this extreme abstraction failure on your part requires too low intelligence for you to not deliberately lie and troll.

>LLVM is not proprietary
Yes, I discussed that in >>106292472 .

You clearly lie and troll on purpose. But others might still benefit from this debate despite your trolling.

These following examples are not of whole projects being abandoned, but are clear examples where the users could probably have switched to gccrs and handled the issue that way instead of being forced to return to a previous version.

https://github.com/rust-lang/rust/issues/75992#issuecomment-706742838
>I'm using tokio-postgres with actix-web and have the same problem. I compiled this and it took about 20 minutes (without the dependency's). With rust 1.45.2 it took about 13 seconds (without dependency's). I'm using decent hardware (Ryzen 3400g, 16 GB RAM and a Samsung NVMe SSD) and the rustc 1.49.0-nightly (b1af43b 2020-10-10) compiler. Rust 1.46 stable has the same problem.
>
>I think I will stay on 1.45.2 until this is fixed.
Might have abandoned Rust later.

https://github.com/rust-lang/rust/issues/75992#issuecomment-795446503

There may be cases that we have not been told about either. Especially considering the behavior of Rust zealots.
https://archive.ph/uLiWX
https://archive.ph/rESxe
https://lkml.org/lkml/2025/2/6/1292
And how parts of the Rust community went mad at the news of tsc being rewritten from Typescript to Go (and not their fan language, Rust).

>>106300599
>some LLVM bug.
Why would it have to be an LLVM bug and not a rustc bug?

Are you involved with the LLVM project?

>>106300599
>>106300913
https://github.com/rust-lang/rust/issues/132064#issuecomment-2865392577
>@Nutomic I'm aware of this but I consider that as a bug in rustc as it was faster before. I'm honestly really disappointed that this is still not fixed. Other than that I'm not sure what I'm supposed to do about it without doing a major diesel rewrite.

>>106300947
https://github.com/rust-lang/rust/issues/132064#issuecomment-2865544297
>It was only "faster before" because the cache implementation was unsound, as described in #132064 (comment). Improvements here will be possible with the new trait solver.
>In the meantime, I guess I'd suggest looking into whether it's possible to restructure that huge query causing issues. If the diesel implementation, + old solver behavior, depend on something like the size of the tables and the size of the query, the number of joins and predicates, etc. maybe splitting it up in smaller queries could help.

>>106300947
Who knows if Diesel will be abandoned in the future because of this.

>>106300913
You are yet to name any non trivial Rust project that was canceled, abandoned or blocked for considerable amount of time because of some LLVM bug.
Having to stay on a certain version because of some performance regression is far from being a serious issue nor it is somehow exclusive to LLVM only.

>>106300924
>Why would it have to be an LLVM bug
Because he keeps talking about LLVM bugs and reliance on LLVM.

>Are you involved with the LLVM project?
No

>>106300947
What about it?

>>106301183
You are a complete troll and liar.

>Having to stay on a certain version because of some performance regression is far from being a serious issue nor it is somehow exclusive to LLVM only.
How would the following not be a serious regression?
>I compiled this and it took about 20 minutes (without the dependency's). With rust 1.45.2 it took about 13 seconds (without dependency's).
How would it not be a serious regression if in one version of rustc, a Rust project compiles fine, but in the next, it crashes after way too long compilation times? There were reports of that in that issue.

>>Are you involved with the LLVM project?
>No
Is this yet another lie by you?

>>106301243
>How would the following not be a serious regression?
It is a serious regression. However that is not a serious issue. It can be mitigated simply by staying on different version and waiting for bugfix. That's how it is with every compiler out there. Compilers having bugs every now and then happens, and having multiple backends does not prevent such bugs from happening. Even more so, by having single backend, everyone's effort will be focused on fixing that one backend instead of producing multiple, half assed compilers. Like it is the case with C++, where each compiler covers different subset of the language, each have different bugs and quirks and each of them is incompatible with each other causing unfixable compatibility problems.
Unless, there are some unfixable LLVM bugs that Rust would have to suffer from, that could be easily fixed by changing the backend. We are yet to see that though.

>How would it not be a serious regression if in one version of rustc, a Rust project compiles fine, but in the next, it crashes after way too long compilation times?
I never claimed it is not a serious regression.

>Is this yet another lie by you?
You are the one who made that statement so the burden of proof is on you.
You are yet to prove that.

>>106300977
>Who knows if Diesel will be abandoned in the future because of this
https://github.com/diesel-rs/diesel
It seems to be doing fine

>>106286675 (OP)
hilariously, it did at one point, but it was because of an LLVM bug.

>>106290814
because C++ is shit, just like C. in rust you need to explicitly tell the compiler to not delete unused shit because it has a proper module system.

>>106296567
I kek'd once ages ago when gcc deleted a if (x == nullptr) branch because it deduced it was UB to assume X was ever nullptr. from that day on I was redpilled.

>>106289393
this is equally UB in C++ and C.

>>106301825
>It is a serious regression. However that is not a serious issue. It can be mitigated simply by staying on different version and waiting for bugfix.
Are you genuinely retarded? Low IQ? Why do you think they tagged it "P-critical
Critical priority" and only removed that tag once they were able to mitigate it in the compiler? Lots of projects crashing at compile-time or having 100+ times compilation times, and it is not a serious issue? If the compiler had not mitigated the issue relatively quickly, and people instead would have had to wait for months or years, that would have blocked upgrading, for projects that did nothing wrong.

Are you genuinely retarded? It clearly was a serious issue, thus they prioritized it highly ("critical") and worked to mitigate it in the compiler quickly.

>Unless, there are some unfixable LLVM bugs that Rust would have to suffer from, that could be easily fixed by changing the backend. We are yet to see that though.
You retarded idiot, the thread has already mentioned that! Other platforms! gcc has support for platforms that LLVM does not! That does not require gccrs, due to rustc having work on a backend for gcc, but it is clear that LLVM does not cover everything! How utterly moronic are you?

>You are the one who made that statement so the burden of proof is on you.
>You are yet to prove that.
Are you truly too stupid to not realize that I asked a question? Too stupid to see that you lie repeatedly?

Do everyone a favor and off yourself.

>>106301891
Diesel's main author has repeatedly complained about rustc.

>>106301961
Wrong, in both Rust, C and C++, no guarantees are given if there is undefined behavior.

>>106302068
>hysterical tranny realizes compilers are hard and you can't just install the latest and expect everything to work exactly the same.
give it some time, new release will be cut, the 1% of users abusing this feature will be happy and life moves the fuck on.
It's like none of you have ever dealt with GCC or clang in any professional capacity before.

>>106302083
what the fuck? Rust has a module system. compiler explorer literally tells you you need to mark free functions as no_mangle because it will just rm them from your code otherwise.

>>106302041
It is not UB in Rust as far as I know, and in C and C++, it might depend on specifically what is done, like which kinds of casts, I am not sure, would have to look it up.

>>106301988
Sounds wrong, are you sure that you understood that correctly?

>>106286675 (OP)
This is a you problem, and every programming language has it. You are a pretentious cocksucker, as evident by the code example. This is not a proper code in any imaginable way, a blind nigger could tell you that. It's time you kill yourself you fucking idiot.

>>106302100
Still wrong, when there is undefined behavior, anything can happen. In theory, the compiler can materialize functions out of thin air if there is undefined behavior. Or nasal demons. No guarantees are given.

>>106302148
>>106287637

>>106302114
might not be UB in rust, but LLVM definitely is causing it.
weirdly, g++ and clang++ give me different code for this which is funny.

>>106302093
>new release will be cut,
In this case the issue was mitigated relatively quickly for many users.

>the 1% of users abusing this feature
What abuse? Where would they be doing anything wrong? Was there anything esoteric in the different affected Rust projects at all?

>It's like none of you have ever dealt with GCC or clang in any professional capacity before.
Things are not always that easy. Consider this other issue:
https://github.com/NixOS/nixpkgs/issues/332957#issuecomment-2274824965
>On principle, rust 1.80 is a new language due to the incompatible change (however inadvertent), and should be treated as such. So I think we need to leave 1.79 in nixpkgs, a little while longer. We can, however, disable its hydra builds, such that downstream will learn about the issue through increased build times and have a chance to step up, before their toys break.
That issue has hundreds of comments and took a lot of work.

>hysterical tranny
Are you parroting what others have correctly told you, hysterical tranny? For I am neither hysterical nor a tranny, unlike you. I am, however, negatively surprised shown by the incredible stupidity shown by some rustaceans here.

>>106302202
#include
#include


auto fn() -> bool
{
uintptr_t a, b = {};
{
auto x = int{};
a = reinterpret_cast(&x);
}
{
auto x = int{};
b = reinterpret_cast(&x);
}
auto c = a == b;
std::print("{0} == {1}, {2}\n", a, b, c);
return c;
}


both deduce that c is always false, but gcc will offset them by 4 bytes always because how it generates code.

>>106302202
>might not be UB in rust, but LLVM definitely is causing it.
It is probably related to pointer provenance, as others have mentioned in this thread. It messes with pointers.

What code did you specifically write for C++? The specifics matter as to whether it is undefined behavior, implementation-defined behavior, or some other kind of behavior.

>>106302068
>Are you genuinely retarded? Low IQ?
Ad hominem

>Why do you think they tagged it "P-critical
>Critical priority" and only removed that tag once they were able to mitigate it in the compiler?
Probably because they found a way to mitigate it?

>Lots of projects crashing at compile-time or having 100+ times compilation times, and it is not a serious issue?
Can you name a few?

>If the compiler had not mitigated the issue relatively quickly, and people instead would have had to wait for months or years, that would have blocked upgrading, for projects that did nothing wrong.
Yeah, if it was a serious issue it would be a serious issue. But as it turns out, it's not.

>Are you genuinely retarded?
Ad hominem

>It clearly was a serious issue, thus they prioritized it highly ("critical") and worked to mitigate it in the compiler quickly.
Yeah. It was a serious regression and it was fixed quickly.
Just like it is in literally any compiler, no matter whenever it has one or multiple backends.
In the end of the day, it did not disrupted the project in a significant way. The project is doing fine despite Rust only using one compiler backend. Just like any other Rust project.

>You retarded idiot
Another ad hominem. You are getting desperate.

>Other platforms! gcc has support for platforms that LLVM does not! That does not require gccrs, due to rustc having work on a backend for gcc, but it is clear that LLVM does not cover everything!
No compiler covers everything.
What exact architecture were you, or someone you heard of, trying to target but couldn't because Rust uses LLVM instead of GCC?

>Are you truly too stupid
>How utterly moronic are you?
>Too stupid to see that you lie repeatedly?
>Do everyone a favor and off yourself.
You are getting way too emotional. Seems like you are running out of arguments.

>not realize that I asked a question?
It was a loaded question that accuses me of lying.
It is up to you to prove that my answer was a lie.

>>106286803
>An infinite loop is considered undefined behavior, so it was optimized away
Back in the day, a compiler that did shit like that was considered broken.

>>106286814
RAD was right. Nobody can takes the likes of clang seriously if they are pulling this bullshit. Delete code if it passes some obscure "Undefined Behavior" threshold.

>>106302537
Code that invokes undefined behavior is broken.

>>106290848
Why should a programmer trying to debug cpu scheduling have to leap through such exotic hoops to get a simple while loop to run? Why should a simply written infinite while loop not actually get compiled?

>>106286675 (OP)
>posts complete trash code/concept
>states language opinion
none of you build anything. there are Python niggers that do more in a day than you do in 3 quarters.
protip: you don't get to have language opinions until you have actually built things in several of them.

>>106302556
Why is an infinite while loop undefined behavior? What's undefined about it?

>>106302272
see right above your post.

>>106289393
>>106302240

For whatever reason, I cannot reproduce that Rust code.

fn main() {
let a = {
let v = 0;
&v as *const _ as usize
};
let b = {
let v = 0;
&v as *const _ as usize
};
println!("{a:?} == {b:?} eval. to {}", a == b);
println!("{a:?} == {b:?} eval. to {}", a == b);
}


gives different values for the usize variables, which then of course compare false.

Was that screenshot made by a rustacean that manipulated it?

>>106302486
My post is completely reasonable, and given your lies, trolling, behavior, etc., more than completely warranted. Please off yourself, you demented, moronic, idiotic, delusional, low-IQ retard.

You are trolling, and your posts are getting too low-IQ, too deceitful, and too inconsistent for others to gain anything from this excuse of a discussion.

And remember to do everyone a favor and off yourself. That is 100% fact, and you know that already.

>>106302537
>RAD was right. Nobody can takes the likes of clang seriously if they are pulling this bullshit. Delete code if it passes some obscure "Undefined Behavior" threshold.
Rust can also do all sorts of crazy things if you have undefined behavior in it. So can other languages.

>>106302747
>actually using rust
you are the manipulative shill in this scenario

>>106302570
Did you try reading the following?

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2809r3.html#intro

>It is easy for the C++ Standards Committee to instead align with C, and allow "trivial" infinite loops as C does. However, care must be taken when doing so. C++ has good reasons to specify that infinite loops are undefined behavior: it is desirable to express forward progress guarantees in a programming language because it unlocks a design space in concurrency and parallelism software and hardware design. An 80 minute deep-dive in this topic is available in [ForwardProgress]. A definition of "trivial" which continues supporting this design space is important to reach.

>>106302588
>>106302902

>>106302861
Nope, I have fixed bugs in code that rustaceans wrote that they couldn't figure out themselves how to fix, but I do not consider myself a rustacean nor Rust developer.
I am not manipulative, nor a shill.
And this case is not even originally written code, just copying the screenshot.

>>106302747
you're probably running a debug build try release

>>106302138
It was a bug in the Linux kernel, x was deferenced before checking if it was null so the compiler assumed it wasn't.

>>106296567
C is not close to the hardware. The C standard describes an abstract machine

>>106303289
you're stupid

>>106286736
An infinite loop that does absolutely nothing counts as UB, so the compiler is allowed to do crazy shit.

>>106296567
Idk, I don't need to justify anything, I just like the language.

>>106286675 (OP)
Garbage in garbage out

>>106286675 (OP)
This is because rust compiler doesn't try to optimize much the code it compiles.

That's why it's slow as fuck, thanks for showing it.

There is nothing undefined about an infinite loop. It's not unDefiNed. It's InDefinite.

>>106287647
>using a while true without even a tiny yield
Hands + timestamp, let's see how dark you are

>>106302041
>>106302202
I am revising my opinion, this is a bug in the language, the compiler or the optimizer used. As far as I can tell, each individual operation is valid, yet it gives a completely wrong result.

https://kosalab.dev/posts/pointer-to-usize-fun

Others have encountered this as well. Claim is that the bug is in LLVM. But I am not sure if Clang for C++ has this bug.

I am guessing that rustc or LLVM wrongly throws the usize conversion away and just uses the pointers for comparison, then compares the values (pointers), and since the provenance is not compared with and not printed (LLVM supports fat pointers), the same value is printed yet compares false.

Miri gives very different values for the pointers and claims no UB.

I do not know if the bug is with rustc or LLVM or the language.

>>106303216
Thank you, that makes it run as described.

>>106302240
I tried running this with Clang, but two different values are printed and the comparison gives 'false', even when passing -O3.

>>106303259
That sounds fine to me. Basic dead code elimination. A different language and compiler might have been able to give a warning or error about code being eliminated. But that may require the language to enable the compiler to detect whether the dead code was dead code due to code generation (if so, probably do not give a warning) or due to programmer mistake (if so, definitely give a warning or compile-time error). I wonder how Zig would have treated this, it has a lot of focus on compile-time programming, but also a lot of compile-time errors on stuff like unused variables.

All languages should allow same name for multiple parameters of a function. It's a very effective footgun to filter out normies.

>>106304065
I might be conflating fat pointers with something related, but LLVM as far as I remember does support something like storing extra information in some of the bits of a pointer.

>>106303968
Not if it is undefined behavior, since then the program might for instance removed the loop.

>>106304065
There's plenty of discussion about this elsewhere, you are not finding anything new.

Some background to get started
https://github.com/rust-lang/rust/issues/107975
https://github.com/llvm/llvm-project/issues/45725
https://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_260.htm
https://www.ralfj.de/blog/2018/07/24/pointers-and-bytes.html
https://www.ralfj.de/blog/2020/12/14/provenance.html
https://www.ralfj.de/blog/2022/04/11/provenance-exposed.html
https://www.ralfj.de/blog/2021/11/24/ub-necessary.html
https://gustedt.wordpress.com/2025/06/30/the-provenance-memory-model-for-c/

>>106286675 (OP)
also jobs

>>106304194
>all languages should have that useless feature
ok

>>106304216
esl jeet pls

>>106304065
>I tried running this with Clang, but two different values are printed and the comparison gives 'false', even when passing -O3.

huh?

~/.l/tmp> clang++ -O2 --std=c++23 x.cpp
~/.l/tmp> ./a.out
140729431585696 == 140729431585696, false
~/.l/tmp> clang++ --version
clang version 20.1.8 (Fedora 20.1.8-3.fc42)
Target: x86_64-redhat-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Configuration file: /etc/clang/x86_64-redhat-linux-gnu-clang++.cfg

>>106286675 (OP)
it doesn't matter if you are more irrelevant than pascal

>>106304768
Nothing ESL, I know that you were making fun of it, but I am pedantic.

>>106304826
ok... creepy. using iostream for output changes how the compiler generates the code so that a and b are offset and not reused. is some niggerlicious C++ modules bullshit? it also absolutely rapes compiler performance. haven't kept up with C++17 or greater.

>>106304502
>>106304856
notice how you faggots play popularity games
precisely because you don't code. you are akin to beer-ed up dads talking about how they could do better than an NFL lineman while watching the big game

>>106304480
Thank you for the links, I assumed as much, though.

I am surprised that it has not been fixed. Ralf Jung and others appear to be blaming LLVM.

>Yeah we know what it's triggered by: llvm/llvm-project#45725. It's a very hard to fix bug in LLVM boiling down to different parts of LLVM making contradicting assumptions about the semantics of lifetime intrinsics, fundamentally caused by never properly deciding and documenting the semantics of said intrinsics.

I know too little about that to really make any calls, but the developers of Rust and rustc appear to consider the bug to be on LLVM's side.

I wonder if gccrs would do better here.

I do not understand why https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119472 is not dismissed with "UB", since the pointers are unrelated (or whatever it is called) and thus should not be compared, as far as I recall. When they talk about "non-conformance", are they considering supporting it and making it work despite it being UB officially?

that's UB and you should be ashamed of yourself OP

>>106304826
>>106304890
It must be LLVM then. The Rust issues at >>106304480 also mention printing effecting the result.

https://github.com/rust-lang/rust/issues/107975#issuecomment-1427518946
> I experimented, figured out that they cannot, and tried to refactor my println!s, whereupon the program started behaving differently. (In the second linked program, uncommenting line 18 changes the output of line 19.)

I kind of understand better now why some people, like the creator of Zig, are a bit skeptical of LLVM. Though there is still a lot of value in LLVM.

>>106304856
>Fucking scratch is more popular than rust
LMAO, rustcels in suicide watch

>>106304856
I don't think that ranking is even slightly accurate. Redmonk is probably best, even though they consider their own way of measuring to be significantly flawed due to the decreasing popularity of Stackoverflow, apart from the other issues with heuristics.

Tiobe was probably never good. Many of the newer websites include statistics like Github stars, and Github stars are gamed to the extreme by the Rust community, giving Rust a large advantage in rankings. Rust is probably higher than current Redmonk (Redmonk might change their way of measuring), and probably lower than many of the newer websites. But who knows, maybe the Rust zealots will hold a knife at the throat of Redmonk and force them to use statistics that Rust zealots can game instead of some statistics that is difficult for everyone to game.

>>106304065
There was a good comment on orange reddit from an LLVM guy on the C providence model article. This is finally solving problems that have always been there but most people never knew had a name
https://news.ycombinator.com/item?id=44421185
>All C compilers have some notion of pointer provenance embedded in them, and this is true going back decades.
>The problem is that the documented definitions of pointer provenance (which generally amount to "you must somehow have a data dependency from the original object definition (e.g., malloc)") aren't really upheld by the optimizer, and the effective definition of the optimizer is generally internally inconsistent because people don't think about side effects of pointer-to-integer conversion. The one-past-the-end pointer being equal (but of different provenance) to a different object is a particular vexatious case.
>The definition given in TS6010 is generally the closest you'll get to a formal description of the behavior that optimizers are already generally following, except for cases that are clearly agreed to be bugs. The biggest problem is that it makes pointer-to-int an operation with side effects that need to be preserved, and compilers today generally fail to preserve those side effects (especially when pointer-to-int conversion happens more as an implicit operation).
>The practical effect of provenance--that you can't magic a pointer to an object out of thin air--has always been true. This is largely trying to clarify what it means to actually magic a pointer out of thin air; it's not a perfect answer, but it's the best answer anyone's come up with to date.

>>106305262
meant for >>106305095

Forward progress was another LLVM bug where too much C/C++ behavior was intertwined with the general compiler machinery. Fixed by LLVM 12
https://blog.rust-lang.org/inside-rust/2020/03/19/terminating-rust/

https://github.com/rust-lang/rust/issues/28728
Original bug reported 2006-10-22
https://bugs.llvm.org/show_bug.cgi?id=965

Yes, LLVM and other compiler frameworks will have bugs that you can't control but you give up a lot by trying to become independent from them. There's a world of hardware optimizations that they're never going to have the resources to claw back. Also they claimed the x86 support just works but it was missing a lot of things they got for free with LLVM and I don't trust when Andrew says LGTM and merges a +23,000 line commit with no comments.

>>106305241
>Redmonk
intentionally gamed to shill for rust, juts because theres a lot of """{""""c0ode""""" on """""github"""""" you think any of tie works?? unreal

>>106305335
Was the last paragraph meant to refer to Zig and maybe my comments on that, like in >>106305157 ?

I know very little about Zig, but I am not sure that one person will scale regarding the development of a systems programming language. Much can be said about Rust, but the shadowy cult leaders and charismatic preachers are great at luring people in.

Rust does reference both C++ and LLVM in places in its official documentation. Though I believe they are decreasing some of those references bit by bit (though not all).

>>106305392
Cute Rustacean, Redmonk currently probably penalizes Rust due to Rust Q&A probably being centered elsewhere, and Rust being a younger language.

>>106302588
Because standard says so.
I also consider this retarded but that's what they did.

>>106302816
>ad hominem
Yawn

>>106305448
You haven't offed yourself yet, you should do so, moronic, lying, trolling retard. And you know it's true that you're a troll and a retard, no matter how much you try to dismiss it.

>>106305405
everyone hates LLVM because it's literally a nightmare beast but it's also the most accessible; both in examples and cuck license, and peak performing.

>>106305206
I would love to know what is being shipped to production using scratch and who are the chads doing it.

maybe don't use shitty compiler like gcc and clang, use something like MSVC

>>106307398
maybe dont use shitty compiler like msvc, use something like icc

>>106307398
I wonder how many people are smuggling out illegal MSVC godbolt code