
Compiler Bugs Found When Porting Chromium to VC++ 2015 - cpeterso
https://randomascii.wordpress.com/2016/03/24/compiler-bugs-found-when-porting-chromium-to-vc-2015/
======
stinos
_And I have to say that the Microsoft team was amazing. They were very
supportive, and helpful, and it was clear that they really wanted VC++ 2015 to
be as good as possible_

Rather anecdotical of course, but I had the same impression. File a _proper_
bug report and you get a reply in the next couple of days, typically starting
with _thanks for the excellent bug report ... will try to get the fix in the
next update_. Found a couple of bugs in VS2012 and VS2013 and they were
resolved in either the next update or in the next version. Practically
speaking it usually took somwhere between 1 - 3 months, which isn't too bad
all things considered. Like, I've also had much worse experiences with some
competitors where I'd file a report including a possible fix (something like
'change <= to <' in soure x line y), and 6 months later there even hasn't ben
a reply let alone a fix.. Anyway with VS2015 it even seems like they cranked
it up a notch beacuse the bugs I encountered already had a fix in the update I
didn't manage to install yet :]

~~~
jobu
> _Like, I 've also had much worse experiences with some competitors where I'd
> file a report including a possible fix (something like 'change <= to <' in
> soure x line y), and 6 months later there even hasn't ben a reply let alone
> a fix._

 _cough_ Apple _cough_ ...

A few years ago I reported an issue for iOS that _never_ got a response. When
I made it to WWDC 6 months after reporting it, I went the support session and
ended up running into the guy that wrote the bug. He was aware of the issue,
it had been reported a few times, and he gave me a workaround until they
released the fix. It was nice to finally get a resolution, but the whole
process was seriously fucked up. After the fix was released in the next
version of iOS they closed my bug report without a single comment.

~~~
Alupis
Sounds like they're using an internal tracker not publically accessible...
making the public one more of a pony show than anything.

Sadly, this is common for a lot of places (they're afraid internal discussions
would get negative attention if made public in some tracker).

~~~
AceJohnny2
> (they're afraid internal discussions would get negative attention if made
> public in some tracker)

Mostly, they're afraid internal discussion would leak super-seekrit info about
their product pipeline. You know how anal they can be about their product
announcements.

I mean, they get worked up about leaks like this:
[http://arstechnica.com/apple/2016/03/unreleased-12-inch-
macb...](http://arstechnica.com/apple/2016/03/unreleased-12-inch-macbook-
early-2016-shows-up-in-os-x-server-update/)

------
progers7
At the bottom of the article Bruce mentions the slashdot comments went
downhill. This is the first time I've visited slashdot in years and I'm sad to
see an old haunt turned so bad. The equivalent reddit thread is significantly
more interesting, positive, and hacker-ish:
[https://tech.slashdot.org/story/16/03/25/141256/chromium-
bei...](https://tech.slashdot.org/story/16/03/25/141256/chromium-being-ported-
to-vc-scrubbed-of-compiler-bugs#comments)
[https://www.reddit.com/r/programming/comments/4bvswj/compile...](https://www.reddit.com/r/programming/comments/4bvswj/compiler_bugs_found_when_porting_chromium_to_vc)

~~~
distances
I overstayed at Slashdot. I kept visiting it probably due to a long habit of
it being the first news site I'd check while code was compiling. Just
ingrained in muscle memory.

Then, one day, I realized most discussions had turned vile. Cynical rants that
would find fault with absolutely anything, and I would feel dirtier reading
it.

It's really a shame, a bit like seeing an old friend that ended up with wrong
choices in life.

~~~
noir_lord
> Cynical rants that would find fault with absolutely anything.

I think that is just comments on the internet in general, everywhere has them,
I had to work hard at stopping it bothering me, you can't bath in negativity
and not get wet.

------
ikeboy
"I generally don't consider my own software adequately enough tested until its
tests have turned up a bug in a compiler/toolchain."

[https://www.reddit.com/r/Bitcoin/comments/2rrxq7/on_why_010s...](https://www.reddit.com/r/Bitcoin/comments/2rrxq7/on_why_010s_release_notes_say_we_have_reason_to)

~~~
Ono-Sendai
You're not going to discover compiler bugs if you stick to language features
and compilers that have been thoroughly trodden, and don't push the limits in
any special way (massive functions etc..).

~~~
derf_
For an example of what Greg Maxwell might consider "adequate testing", see
[https://www.ietf.org/proceedings/82/slides/codec-4.pdf](https://www.ietf.org/proceedings/82/slides/codec-4.pdf)
(he is the one responsible for all of the testing described in that
presentation).

Slide 20 lists no less than 8 toolchain bugs found with a codebase of less
than 50k lines of C code (no C++), using only thoroughly trodden language
features, without "massive functions" or anything else. Admittedly 4 of those
bugs were in pre-release versions of gcc, but the rest weren't.

~~~
Ono-Sendai
I've heard ICC is pretty buggy. Tinycc seems a bit obscure. pre-release
versions of GCC as you mentioned are not well-trodden.

~~~
nkurz
_I 've heard ICC is pretty buggy._

Perhaps historically ICC was buggy, but I don't think it's true anymore. I
often test highly optimized C code with GCC, Clang, and ICC, and anecdotally
I'd say that the likelihood of hitting a compiler bug when compiling for a
current Intel processor is about the same for each.

For me, crashing bugs and true miscompilation are rare with all three, but
come up occasionally. Performance differences are usually within +/\- 20% on
microbenchmarks, with each having about equal chances of being the fastest or
slowest.

------
BinaryIdiot
> _" I worked on one project where in addition to finding several compiler
> bugs I also found a flaw in the design of the processor, but that’s an NDA
> tale for another day…"_

Yeah I really want to hear this story; whens the NDA expire or does it never?
:)

~~~
RyJones
I wonder if he worked with early UltraSPARC chips. There were tales of an
interesting bug report from the NSA. It's been 20 years, so I probably have
every detail wrong, but it was something like a missed implementation of a
version of ROTL that the CPU was basically emulating at several orders of
magnitude performance penalty. No other customer found it.

------
xvilka
It would be nice if MSVC will create something like clang-cl [1] to handle
--options like others do, for easier compiling of pure Makefile opensource
projects.

[1]
[http://clang.llvm.org/docs/MSVCCompatibility.html](http://clang.llvm.org/docs/MSVCCompatibility.html)

~~~
tavert
Why use MSVC at all when Clang has a perfectly good gcc-style driver? There's
also this
[http://git.savannah.gnu.org/cgit/automake.git/tree/lib/compi...](http://git.savannah.gnu.org/cgit/automake.git/tree/lib/compile)
wrapper script which is useful once in a while for invoking MSVC from inside
Cygwin or MSYS (though MSYS2 broke this, last I checked).

~~~
xvilka
We (radare2 project) already being built by gcc, clang and tcc. Every time new
compiler support added it reveal some new errors. This is why we have interest
in trying MSVC too. Thank you for the script!

------
pfarnsworth
For over a decade I've felt that Visual Studio is consistently the best
product that Microsoft has released. Which makes sense since many if not most
of their developers rely on it to make other product.

~~~
vvanders
Yup, MSVC is the bar that I hold every other IDE to. IntelliJ comes close but
all others (Eclipse I'm looking at you) fall far short.

------
PaulHoule
You haven't programmed in C if you haven't found a compiler bug.

------
macjohnmcc
I'm currently working to create a project demonstrating a Visual Studio 2015
C++ compiler crash that exhibits only when using the Inline Function Expansion
optimization. The Visual Studio team has proven very responsive.

------
vmorgulis

        char key[5] = { 0 };
    
        Simple enough – this is supposed to zero the entire array, but instead it only zeroed the first four bytes.
    

In C++ and on the stack "{0}" is not required as memory is zeroized. On heap
(in a new) "{0,0,0,0,0}" should be used (or memset()). Not sure about that in
C.

My understanding is that it's not a bug.

~~~
MaulingMonkey

      #include <iostream>
      
      int main() {
          int nope_not_initialized;
          std::cout << nope_not_initialized << "\n";
      }
    
      cc1plus: warnings being treated as errors
      In function 'int main()':
      Line 5: warning: 'nope_not_initialized' is used uninitialized in this function
    

( [http://codepad.org/6xrFQZuL](http://codepad.org/6xrFQZuL) )

Edit: And a C version. Amusingly, it will print "0" if I only use one printf
statement:

    
    
      #include <stdio.h>
      
      int main() {
          int nope_not_initialized;
          printf("%d", nope_not_initialized);
          printf("%d", nope_not_initialized);
      }
    
      -142791388-142791388
      Exited: ExitFailure 10
    

( [http://codepad.org/TgGfL7QW](http://codepad.org/TgGfL7QW) )

Edit x2: Apparently "implicit return 0 from main" is only a thing in C++? And
here I'd assumed it was some silly carryover from C...

( [http://codepad.org/JIH9ZteL](http://codepad.org/JIH9ZteL) )

