Compiler Bugs Found When Porting Chromium to VC++ 2015
randomascii.wordpress.com
randomascii.wordpress.com
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 :]
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.
Sadly, this is common for a lot of places (they're afraid internal discussions would get negative attention if made public in some tracker).
That's understandable for a company like Apple. It just pissed me off that they had a workaround, possibly for months, and never bothered to respond to my report.
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...
I'd bet the teams were quite unhappy...
I was into Slashdot back in the 1990s. I lost interest about 15 years ago. When the Sourceforge thing happened I was mildly surprised to see that Slashdot still existed.
A lot of the experts who got annoyed, probably had been following it from then. But as time went by, being said expert got tiring. Eventually the trolls drove them away.
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.
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.
That does often mean that more of the comments might be seen as negative, some might be offensive to some people, and some might contain misinformation. But it works the other way, too, where some of the best commentary I've seen anywhere has been there, often from people posting as Anonymous Coward.
notices@slashdotmedia.com 18 Mar (11 days ago)
to me 2016-03-17
Dear Site User,
Fair processing notice - Data Protection Act 1998
We are writing to let you know that with effect from 27 January 2016, the Slashdot Media business, which provides online services through various web sites including Slashdot.org and SourceForge.net (the "Slashdot Media Services") has been purchased by SourceForge Media LLC of 1660 Logan Avenue, San Diego, California, 92113, USA ("we" or "us").
As a result your personal data have been transferred to us and will be used in connection with the continued provision of the Slashdot Media Services to you. Your personal data will continue to be processed fairly and lawfully in accordance with the Data Protection Act 1998 for the same purposes as those it was originally collected by Dice Career Solutions Inc and/or eFinancialCareers Limited including to:
* continue to provide you with information (by electronic means or otherwise) about other services we offer that are similar to those that you have already received or enquired about; * carry out our obligations arising from any contracts entered into between you and us; * provide you with the information and services you request from us; * tell you about changes to the Slashdot Media Services; and * ensure that the content made available through the Slashdot Media Services is presented in the most effective manner for you and your device.
Further information on how your personal data may be processed, who it may be disclosed to and how it will be stored can be found in the Slashdot Media Services privacy policy available at: http://www.slashdotmedia.com/privacy-statement/
You can ask us to remove all your account data, stop processing your personal data and to stop contacting you for marketing purposes at any time. * For SourceForge.net, please contact us at sfnet_ops@slashdotmedia.com * For Slashdot, please contact us at privacy@slashdot.org * For FreeCode, please contact us at freecode-privacy@slashdotmedia.com * For SlashdotMedia.com, please contact us at sfnet_ops@slashdotmedia.com
Please let us know if you have any queries. Yours sincerely, Logan Abbott The team at SourceForge Media LLC
https://www.reddit.com/r/Bitcoin/comments/2rrxq7/on_why_010s...
I have come across a lot of transient miscompilation in visual studio, I guess, usually when doing incremental rebuilds. I was thinking more of persistent miscompilations as things you are unlikely to find on the 'well trodden path'
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.
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.
https://connect.microsoft.com/VisualStudio/feedback/details/...
I didn't file a bug as it'd already been reported - although in my case, the trigger was using a logging macro which used __LINE__ from a lambda IIRC. Nothing terribly spectacular.
The last bug I remember reporting was default constructor parameters not instantiating templates correctly. Something like void f(int i = some_template<int>::func()); would fail to generate, and thus link against, some_template<int>::func. f might've needed to be a constructor. Sadly the connect bug is 404 and web.archive.org didn't capture the page. They said they would fix it in VS2008 SP2, but I ended up checking and finding they'd fixed it in SP1.
Even ignoring ICEs, I'd say I probably hit at least one confirmed compiler bug a year minimum when doing regular C++ development.
The circumstances needed to trigger this bug weren't special, I never nailed it down entirely but it was just something like performing an integer division at just the wrong spot. Vararg function calls are extremely well trodden, and clang at the time was pretty mature. Yet there was a bug, all the same.
Consider that entire industries (aerospace, etc) routinely ship code with compiler optimization disabled, to avoid getting bit by compilers trying to do clever things.
char key[5] = { 0 };
// Work around VC++ 2015 Update 1 code-gen bug:
// https://connect.microsoft.com/VisualStudio/feedback/details/2291638
key[4] = 0;
(((av_alias32*)(key))->u32 = (argc));
The first problem is that an int may have an alignment constraint. Since writing an int to an allocation that is made based on char could violate this constraint, the code is invalid. It doesn't matter that x86 won't actually enforce this. The code is still invalid. Since that line of code is invalid, all code paths that will reach it are also invalid, as are all code paths from it. This makes the entire test program invalid; it is legit for the compiler to emit a program that immediately crashes or insults your mom.
The second problem is when the char array is checked to see if it contains the 42. An access as char is always permitted, so the code narrowly misses having an aliasing violation, but remember that the type AS ACTUALLY WRITTEN is not char. The only thing that can be legitimately done with the value is to write it elsewhere, for example when implementing a function like memcpy. An int need not be stored in little-endian form, big-endian form, two's complement, or anything else sane... and the language standard allows for this by prohibiting what this code is doing. As with the other bug: all code paths which involve the standards violation are invalid, making the whole test program invalid. The compiler is permitted to emit code that crashes or insults your mom.
gcc/clang are within their rights to break programs that break the aliasing rules, but VC++ is not required to do so and they choose not to.
There have been some excellent articles talking about how the current state of undefined behavior as understood by gcc/clang is crazy. One that I like is this one: http://blog.regehr.org/archives/761
Obviously some types of undefined behavior cannot be 'normalized', such as use-after-free, but treating the aliasing in that bug as undefined behavior is a committee decision that many developers think is ill advised.
Another recent article that I can't find pokes some holes in the idea that the latitude given to compilers by undefined behavior improves performance.
For your second example of undefined behavior I'm afraid I don't understand. Are you saying that even if the line of code that aliases the array is removed that "if (key[0] != 42)" is still undefined behavior? If so please explain. You say "the type AS ACTUALLY WRITTEN is not char" but I'm not sure what type you are referring to, and if you mean '42' that is true but not relevant because in a comparison between key[0] and '42' "key[0]" is converted to int by the standard integral conversions and then a particularly boring comparison is done.
If that code is undefined then the standards committee is definitely crazy and no code is conforming.
Reading it out as a long or float would be prohibited by aliasing rules, even if those types happen to be the same size. When you do "if(key[0] != 42)" you are reading out the value in key[0] as char, which is OK, but the content is undefined. You can't legitimately compare an undefined value with 42.
There is a special exception for char. You don't violate the aliasing rules when you load part of the int as a char. This special exception is very limited. It's for implementing functions like memcpy. (but not of that name, since "memcpy" is reserved)
The special exception doesn't make the data meaningful when loaded as char. The bits could be in any order. When you load part of an int into a char, the only legitimate thing you can do with it is to store it as if doing a memcpy.
Depending on how you read the C standard, you might even need an unsigned char to avoid trap representations. People argue this both ways.
That all said, not even gcc is this cruel.
No details were given as to what I was doing that crashed them though, and the bug was eventually fixed.
Yeah I really want to hear this story; whens the NDA expire or does it never? :)
char key[5] = { 0 };
Simple enough – this is supposed to zero the entire array, but instead it only zeroed the first four bytes.
My understanding is that it's not a bug.
No, it isn't. Globals are.
And since the explicit initializer is provided it definitely is a bug to not zero all bytes.
#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
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
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...