The MinGW from http://www.mingw.org/ does only support gcc 32 bit (host and target). The independent minGW-w64 project provides support for 64 bit, and also supports a much larger part of the Windows API. The MinGW-w64 project however does not provide official binary builds: These can be grabbed either from the personal build directories of the developers (the most popular being rubenvb), or from associated but independent projects like tdm-gcc or mingw-builds or msys2.

Source: http://wiki.qt.io/MinGW-64-bit

MinGW is based on GCC and binutils, along with other GNU software. GNU projects use so-called "GNU triplets" to specify architecture information. A triplet has this format:

machine-vendor-operatingsystem

The triplet was specified when the binaries were built.

MinGW-w64 is using w64 as the vendor field, and mingw32 as the operating system. Of course, mingw32 is not an operating system, but it is treated as one by the GCC and binutils build system and source code.

So these long names for the binaries are an artifact of the build system that GCC and binutils are using. All of these binaries are installed in the same directory, and so binaries that target different architectures (in this case 32-bit vs 64-bit) need to have different file names. The easiest way to do that is to prefix the binaries with the GNU triplet that describes those architectures.

MinGW is a GCC-port for Windows. Not all of the Windows API is supported (but for many programs the supported stuff is sufficient) and it´s only for 32bit-Programs (which often can run on 64bit-Windows too, but some can´t, and you can´t compile them as 64bit).

MinGW-w64 is a improved version which supports both 32bit and 64bit, and some more of the WinAPI (still not all, because thats much work, but more than MinGW).

MinGW-w64 only provides their source code, but no binaries to "just use" the compiler.

MinGW-builds is a somewhat separate project to provide binaries in the most useful configurations. To get a specialized build of MinGW-w64, manual compiling is still possible.

Using the MinGW-builds self-installer is the easiest way, if nothing unusual is needed. Also see here for help with the self-installer.

That depends on which variant of toolchain you're currently using. Both DWARF and SEH variants (which come starting from GCC 4.8.0) are only single-target. You can see it yourself by inspecting the directory structure of their distributions, i.e. they contain only the libraries with either 64- or 32-bit addressing, but not both. On the other hand, plain old SJLJ distributions are indeed dual-target, and in order to build 32-bit target, just supply -m32 flag. If that doesn't work, then just build with i686-w64-mingw32-g++.

BONUS

By the way, the three corresponding dynamic-link libraries (DLLs) implementing each GCC exception model are

1. libgcc_s_dw2-1.dll (DWARF);
2. libgcc_s_seh-1.dll (SEH);
3. libgcc_s_sjlj-1.dll (SJLJ).

Hence, to find out what exception model does your current MinGW-w64 distribution exactly provide, you can either

1. inspect directory and file structure of MinGW-w64 installation in hope to locate one of those DLLs (typically in bin); or
2. build some real or test C++ code involving exception handling to force linkage with one of those DLLs and then see on which one of those DLLs does the built target depend (for example, can be seen with Dependency Walker on Windows); or
3. take brute force approach and compile some test code to assembly (instead of machine code) and look for presence of references like ___gxx_personality_v* (DWARF), ___gxx_personality_seh* (SEH), ___gxx_personality_sj* (SJLJ); see Obtaining current GCC exception model.