So you're wanting the dependent DLL to use MSVCR100?  Have you
considered using the static libraries instead?

Ah, yes, exactly, this solves the problem with different runtimes. Thank you!

However, unfortunately I still get the same unstable results using DLLs compiled by MinGW in Visual Studio 2010.

I found  that problem is in quadmath_snprintf, which converts __float128 to a string. 
Sometimes it returns correct result, sometimes - returned string is a junk. 
quadmath_snprintf relies heavily on stdio using FILE and others runtime features. 
Now runtimes are the same and I am out of ideas what can be wrong.

Same code compiled in MinGW runs nicely - no floating bugs.

Could it be something with how Visual Studio-compiled application loads DLL? Relocations or other? 
I've tried -Wl,--dynamicbase -Wl,--nxcompat, this also doesn't help.

I would appreciate any further ideas on how to build DLLs in MinGW so that they are compatible with usage in Visual Studio applications.
To sum up, I already have the same runtimes in MinGW & VS, enabled DEP/ASLR. 
But still IO functions in DLL give upredictable results, sometimes they work, sometimes they don't.