compiler-bug

When implementing dynamic dispatch using dynamic on a generic class, and the generic type parameter is a private inner class on another class, the runtime binder throws an exception. For example: using System; public abstract class Dispatcher<T> { public T Call(object foo) { return CallDispatch((dynamic)foo); } protected abstract T CallDispatch(int foo); protected abstract T CallDispatch(string foo); } public class Program { public static void Main() { TypeFinder d = new TypeFinder(); Console.WriteLine(d.Call(0)); Console.WriteLine(d.Call("")); } private class TypeFinder : Dispatcher<CallType>

Consider the following snippet: struct Base { }; struct Derived : Base { }; void f(Base &) { std::cout << "f(Base&)\n"; } template <class T = int> void g() { Derived d; f(T{} ? d : d); // 1 } void f(Derived &) { std::cout << "f(Derived&)\n"; } int main() { g(); } In this case, I reckon that the function call to f at // 1 should be looked up in phase one, since its argument's type is unambigously Derived& , and thus be resolved to f(Base&) which is the only one in scope. Clang 3.8.0 agrees with me , but GCC 6.1.0 doesn't , and defers the lookup of f until phase two, where f(Derived&) is picked

program: #include <stdio.h> struct bar_t { int value; template<typename T> bar_t (const T& t) : value { t } {} // edit: You can uncomment these if your compiler supports // guaranteed copy elision (c++17). Either way, it // doesn't affect the output. // bar_t () = delete; // bar_t (bar_t&&) = delete; // bar_t (const bar_t&) = delete; // bar_t& operator = (bar_t&&) = delete; // bar_t& operator = (const bar_t&) = delete; }; struct foo_t { operator int () const { return 1; } operator bar_t () const { return 2; } }; int main () { foo_t foo {}; bar_t a { foo }; bar_t b = static_cast<bar_t>(foo);

You may consider this a bug report, however I'm curious if I am terribly wrong here, or if there is an explanation from Eric or someone else at Microsoft. Update This is now posted as a bug on Microsoft Connect. Description Consider the following class: class A { public object B { set { } } } Here, A.B is a write-only but otherwise fine property. Now, imagine we assign it inside of expression : Expression<Func<A>> expr = () => new A { B = new object { } }; This code makes C# compiler (both 3.5 .30729.4926 and 4.0 .30319.1) spit out Internal Compiler Error (0xc0000005 at address 013E213F):

The following code generates different results under debug mode and release mode (using Visual Studio 2008): int _tmain(int argc, _TCHAR* argv[]) { for( int i = 0; i < 17; i++ ) { int result = i * 16; if( result > 255 ) { result = 255; } printf("i:%2d, result = %3d\n", i, result) ; } return 0; } The output of debug mode, which is as expected: i: 0, result = 0 i: 1, result = 16 (...) i:14, result = 224 i:15, result = 240 i:16, result = 255 The output of release mode, where i:15 result is not correct: i: 0, result = 0 i: 1, result = 16 (...) i:14, result = 224 i:15, result = 255 i:16, result =

I'm trying to make a simple map to look up some data, but the results are coming out very strange: #include "stdafx.h" #include "atlstr.h" #include <map> enum InputTypes { Manual, Automatic, Assisted, Imported, Offline }; struct Params { int inputType; const char* moduleName; DWORD flag; }; int _tmain() { std::map<CString, Params> options { { "Add", { Manual, "RecordLib", 0 } }, { "Open", { Assisted, "ViewLib", 1 } }, { "Close", { Imported, "EditLib", 2 } }, { "Inventory", { Automatic, "ControlLib", 3 } }, { "Report", { Offline, "ReportLib", 4 } } }; for (std::map<CString, Params>::iterator

First, a little background (or skip down a little if not interested). I'm irritated and confused! This should be a pretty simple use case, and indeed my code has been compiling just fine with the Eclipse JDT compiler, so until now I've been configuring Maven to make sure to do this. It's been bothering me too much though that it doesn't compile with the Oracle JDK and OpenJDK, as I thought it may actually have been a problem with my code, so I've looked into it again. I thought perhaps that the bug was in the JDT compiler for allowing it to compile, not the Oracle JDK and OpenJDK for not