[llvm-bugs] [Bug 41409] possible silent bad code generation with inline static data member in clang-cl

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=41409

Karsten H <powerchord at web.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|DUPLICATE                   |FIXED

--- Comment #2 from Karsten H <powerchord at web.de> ---
(In reply to Tim Northover from comment #1)
> I know it's frustrating when bugs don't get the attention you think they
> deserve, but creating intentional duplicates isn't the way to fix it.
> 
> You might try getting people interested in other venues like llvm-dev or the
> IRC channel.
> 
> *** This bug has been marked as a duplicate of bug 37903 ***

Tim, you're misjudging me. There is no frustration at all. Instead, there are
concerns that this bug and its severity may have been overlooked.

Let me explain.

If you should happen to know this bug, you can safely work around it in your
own code: simply don't use this new C++17 language feature. However, if you
include library header files, you no longer have control over the bug because a
library might use this new feature.

It gets worse if you do not know this bug. I assume this applies to virtually
all programmers except me. Since clang is known as the most compliant and least
buggy compiler of the big 3, they would not hesitate to use this new feature.

What's the end result? In a best case scenario, this bug has absolutely no
effect in a program. In a worst case scenario, a program silently runs amok.

My personal opinion on the latter is the following: silent bad code generation
is the worst of all evil. It must never happen. A bug that can silently
generate bad code should have the highest priority.

Now, if you look at my two bug reports for clang-cl 6 and 7 you'll see that
this bug had exactly zero attention over a nine-month period. There are no
comments from others, and the CC list is virtually empty. So I suspected the
possibility that this bug was overlooked.

I decided to wait for clang-cl 8. If the bug is still there, I would report it
for clang-cl 8, too, but under a possibly better fitting heading that clearly
indicates what this bug could do to a program (silently generate bad code). My
hope was (and still is) that you guys who actually do all the work definitely
know this bug.

Honestly, I don't think this decision is inappropriate or wrong.

Of course, you guys can still judge the severity of this bug differently than I
do. Finally, it's your decision, not mine. Since I'm not involved in the
development of clang, I would have to accept that and hope for the best case
scenario in my programs until the bug is fixed.

OK, I think based on this answer you now know that I basically do not act
prematurely.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20190407/25a56fd7/attachment.html>