I encourage everyone to have a glance over the Quake II source code

Quote:

---

Originally Posted by brewbuck

Your pet frustration notwithstanding, clang is pretty much taking over everything now. Android and iOS are both compiled with it, and Microsoft is switching to it. Get over it, man.

---

Why god why. I'll get over it when they fix it.

Quote:

---

Originally Posted by Epy

Why god why. I'll get over it when they fix it.

---

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.

Quote:

---

Originally Posted by Elkvis

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.

---

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.

Quote:

---

Originally Posted by stevesmithx

My props to John Carmack and his team. And I like the fanboy in you, but this raises a question: If John is God, then what do you call Dennis Ritchie? Meta-God??

---

Yep, Dennis Ritchie and Kernighan Meta Gods

Quote:

---

Originally Posted by Vespasian_2

Yep, Dennis Ritchie and Kernighan Meta Gods

---

And Ken Thompson and Bjarne Stroustrup.

Quote:

---

Originally Posted by Elkvis

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.

---

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).

Quote:

---

Originally Posted by Epy

Along comes Clang 3.4, suddenly test cases are failing out the wazoo.

---

Your test cases failed! Yay! The system works! What's your problem again?

Quote:

---

So, Clang's retard ass philosophy is to produce binaries that, even though no relevant warnings/errors are issued, doesn't work.

---

Let's get this part correct. Your code with undefined behavior doesn't work.

Quote:

---

It's really a shame because Clang is mostly faster than GCC and far better at producing meaningful warnings (or so I thought).

---

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!

Quote:

---

Originally Posted by brewbuck

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.



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!

---

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.

Quote:

---

Originally Posted by brewbuck

Let's get this part correct. Your code with undefined behavior doesn't work.

---

This.

You're being sour because clang actually traps your bugs, which no other compiler is able to. Deal with it. Fix it. Move on. I'd say it's retarded to rely on undefined behaviour.

Quote:

---

Originally Posted by Elysia

This.

You're being sour because clang actually traps your bugs, which no other compiler is able to. Deal with it. Fix it. Move on. I'd say it's retarded to rely on undefined behaviour.

---

Add another to the disappointment list, and also the list of people who can't read.

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?

Quote:

---

Originally Posted by Elysia

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?

---

I'd argue that, because it is emitting a UD2, it does know about the undefined behavior at build time, and should be able to emit a diagnostic.

Quote:

---

Originally Posted by Elkvis

I'd argue that, because it is emitting a UD2, it does know about the undefined behavior at build time, and should be able to emit a diagnostic.

---

You haven't explained what your problem is with the presence of these UD2 instructions. Do you not test your code?

EDITED: thought it was Epy I was replying to.

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.

Quote:

---

Originally Posted by Elysia

Are you trying to imply there's a bug that causes these instructions to trap when there's actually no undefined behaviour at all?

---

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.