Or at least offer a command-line switch to disable that behavior, or to enable the issuance of a warning in that scenario. I read What Every C Programmer Should Know About Undefined Behavior, and I understand their rationale for emitting those instructions, but I definitely agree with your complaints that they don't even emit a warning for recognized undefined behavior, when they generate those instructions.
What can this strange device be?
When I touch it, it gives forth a sound
It's got wires that vibrate and give music
What can this thing be that I found?
That article was useful.
I finally know why languages deliberately allow for undefined behaviour!! My question was always why dont languages force the programmer to follow safe procedures. Turns out that by allowing for undefined behaviour but not stepping on it allows for performance gains.
My gripe basically started with working on a project I'm involved with, OCE. I have spent months reducing compiler warnings and fixing small bugs, etc. GCC and MSVC were very happy with it, we even reduced some test failures in the process. Along comes Clang 3.4, suddenly test cases are failing out the wazoo. So, this is code that: a) compiles correctly with MSVC and GCC, b) does not issue any major warnings under -Wall -Wextra (and the MSVC equivalent), c) does not issue anything major under Clang's -Weverything, d) compiles without errors obviously.
So, Clang's retard ass philosophy is to produce binaries that, even though no relevant warnings/errors are issued, doesn't work. What the ........ is the point of making the binary if it's not going to run?
On top of this, this is actually two separate issues: one is a bug, because sometimes the ud2 only happens when optimization is used, other times it just happens period (intentional).
It's really a shame because Clang is mostly faster than GCC and far better at producing meaningful warnings (or so I thought).
Your test cases failed! Yay! The system works! What's your problem again?
Let's get this part correct. Your code with undefined behavior doesn't work.So, Clang's retard ass philosophy is to produce binaries that, even though no relevant warnings/errors are issued, doesn't work.
I think the shame is that you've become mentally hung up on a particular issue and you've gone into an infinite loop. Move on!It's really a shame because Clang is mostly faster than GCC and far better at producing meaningful warnings (or so I thought).
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
I'm disappointed in you, up until this point you've been a voice of reason and great knowledge, never thought I'd see you devolve into compiler fanboy status.
Not going to hijack further; my last remark is that OCE compiles/works without hiccups on GCC, MSVC, ICC, Borland, and HP aC++ on many architectures (x86, SPARC, MIPS, ARM, etc etc). To say that Clang 3.2/3.4 comes along and is "right" in the 2010s vs. more mature compilers on a codebase professionally developed (OPEN CASCADE) dating back to the 90s, is retarded. On top of direct professional efforts by the company that makes this CAD kernel, others have basically done all we can to ensure code quality, evaluating as many compiler warnings from different compilers and using static analyzers, etc.
Then enlighten us as to the problem because from what I see the problem is very vague.
From what I gather, you're complaining about how clang generates these trap instructions for undefined behaviour because they are messing up your code. And as the article says, they're generated because the compiler cannot always catch undefined behaviour at compile time. Are you trying to imply there's a bug that causes these instructions to trap when there's actually no undefined behaviour at all?
What can this strange device be?
When I touch it, it gives forth a sound
It's got wires that vibrate and give music
What can this thing be that I found?
Does it know about loop bounds that can be read from the user? Does it know 100% for sure that all function pointers will be initialized before use? Sometimes a compiler just can't do enough static analysis because a) it takes too long time or b) because it's too complicated or c) because it depends on how the code executes in runtime (e.g. dependencies on user input), so the compiler just can't tell if it's undefined behaviour or not. Sometimes it's also just too verbose, such as decisions it makes when optimizing. That's why it's emitting those instructions. To trap undefined behaviour at runtime when it can't guarantee things at compile time. That article posted before was really insightful. It really also points out why clang does as it does.
Yes.
Re-read everything I wrote and tell me what is more likely:
a) Clang is the only compiler on the planet that can supposedly catch this mysterious undefined behavior, uncatchable by its own sanitizers and -Weverything, which apparently has been ignored/uncaught by numerous other compilers, static analyzers, and professional/open-source software developers since the early 1990s.
b) These other compilers, GCC, MSVC, Intel C++, etc., all serious, production-level compilers, process this code without major warnings/errors and produce binaries that work as intended/expected, and have for years because the code is "correct" (enough). OCE is definitely not perfect, but at most is guilty of type punning in terms of undefined behavior. Thing is, what crashes does not correlate with where the type punning takes place in the code.
Also, whats with the "your"? Again, this is code developed by professionals, professionals with graduate degrees in CS, not just anyone can program a CAD kernel.