3 compiler bugs in one month...

I think you should quit while your ahead, maybe head to the pub.

That's nuts. I've seen one in about thirty years :)

In our current project at work we've seen about 3 or 4 "Internal compiler error" bugs in MSVC over the last three months. This was all legal C++ code mind you, so it was a pain to find workarounds which MSVC would accept without throwing up all over itself.

We're the last two C++ errors?

In our current project at work we've seen about 3 or 4 "Internal compiler error" bugs in MSVC over the last three months. This was all legal C++ code mind you, so it was a pain to find workarounds which MSVC would accept without throwing up all over itself.

Had, a few of those and out of memory errors as well. Usually a rebuild solves them, but sometimes they can be a little more persistent. Also very annoying: Linker warnings due to excessively long symbols (which happens all too often with templates and MSVCs very limited symbol lengths...)

We're the last two C++ errors?

All three are related to using C++. If you meant if they are bugs in the C++ standard, no, just bugs in MSVC.

I've encountered just one, which existed in VS2013 up to and including first SP I belive. Having a double initializer-list like this:

const ecs::ComponentDeclaration::AttributeVector vAttributes =
{
    { L"Positioning", PositioningMode::NORMAL, offsetof(Character, positioning) },
    { L"ZOffset", core::generateTypeId<int>(), offsetof(Character, zOffset) }
};

Somehow caused the destructor of the first element being called twice (when doubling the array), resulting in a crash. The newer service packs fixed that, though.

EDIT: I originally made a thread about it:

http://www.gamedev.net/topic/660049-destructor-in-vector-called-too-often/

Was quite obnoxious because it was not appearent that it was a compiler bug.

Yeah I just wasn't sure if they were C#/VB errors. MS built a new compiler for 4.6 and I have heard about some bugs, at least one pretty serious (something about changing arguments to method calls in some circumstances).

Had, a few of those and out of memory errors as well. Usually a rebuild solves them, but sometimes they can be a little more persistent. Also very annoying: Linker warnings due to excessively long symbols (which happens all too often with templates and MSVCs very limited symbol lengths...)

Sadly enough rebuilds never fixed these issues for us. We did see a ton of out of memory errors though, it's not uncommon to see MSVC run out of heap space.

It's always a lot of fun to see a new engineer roll on to the project and encounter this issue, one can only wonder what it's using all that memory for.

one can only wonder what it's using all that memory for

Expanding all the options for templates.

Lots and lots of potentially valid expansions.

one can only wonder what it's using all that memory for

Expanding all the options for templates.

Lots and lots of potentially valid expansions.

Other compilers manage without so many issues.

Aside from that, name lookup in templates is FUBAR in MSVC anyways...

Tried to use a C ogg/vorbis library to play music in a Windows Store app, but the VS 2013 compiler for ARM crashed every time I tried to build it (worked fine for x86). Didn't manage to find a workaround so switched audio formats.

You should try the intel's compiler :D

But yeah, something horribly wrong is happanening @ MS lately.

Here's some more:

- VS 2012 doesn't like you to declare or reference static variables in lambdas, even when the lambda is marked to capture everything by reference. I think VS 2015 fixed that.

- VS 2012 let you mark both a function's declaration and definition as "inline", while having them be in separate source files from where they're used. 2015 doesn't let you do this anymore, you get an "unresolved external." This is a bit of a pain when converting old code over.

Bah, those are easy. Causing an ICE (Internal Compiler Error) with Visual C++ or GCC or even Clang is something I usually do at least once a month.

Now, when you get to _miscompilation bugs_ that require you to dig through the generated assembly and find out why perfectly correct code is exhibiting incorrect behavior... that's when you start to have fun.

(Sounds like Juliean hit one of those!)

Visual C++ is definitely the crashiest of the compilers, but it's also got a huge amount of refactoring necessary to implement feature that its aging design just can't handle. Fun fact: Visual C++'s actual compiler doesn't even generate an AST internally, and also the C++ frontend used by the IDE for Intellisense is an entirely different C++ parser licensed from EDG. GCC and Clang are both very far away from being free of bugs, though; you're not a real C++ programmer if you haven't filed at least 10 ICE reports to their respective bug trackers.

1 did cause a miscompilation for me, not an ICE as the minimal example in the report. 2 was also a miscompilation.

And 1 was great fun to debug, because the miscompilation occurred in a dll built with mingw that is being used by an MSVC exe. Everything hidden behind a C interface of course.

That's nuts. I've seen one in about thirty years

I've already went far beyond that =/ (albeit honestly it's all pretty much assembler issues rather than compiler, although every so often I have IDE issues too)

Bah, those are easy. Causing an ICE (Internal Compiler Error) with Visual C++ or GCC or even Clang is something I usually do at least once a month.

You're dangerous.