背景
在调试一个数值库中的问题时，我能够确定数字错误的第一个出现位置。然而，C++代码本身似乎是正确的。于是我查看了Visual Studio C++编译器生成的汇编代码，并开始怀疑这是一个编译器bug。
代码
我能够在代码的一个高度简化、隔离版本中复现该行为:
sourceB.cpp:
double alwaysOneB(double a[3]) {
return 1.0;
}
main.cpp:
#include <iostream>
__declspec(noinline)
bool alwaysTrue() {
return true;
}
__declspec(noinline)
double alwaysOneA(const double a[3]) {
return 1.0;
}
double alwaysOneB(double a[3]); // implemented in sourceB.cpp
int main() {
double* result = new double[2];
if (alwaysTrue()) {
double v[3];
v[0] = 0.0;
v[1] = 0.0;
v[2] = 0.0;
alwaysOneB(v);
double d = alwaysOneA(v); // d = 1
std::cout << "d = " << d << std::endl; // output: "d = 1" (as expected)
result[0] = d * v[2];
result[1] = d * d; // should be: 1 * 1 => 1
}
if (alwaysTrue()) {
std::cout << "result[1] = " << result[1] << std::endl; // output: "result[1] = 2.23943e-47" (expected: 1)
}
delete[] result;
return 0;
}
代码包含一些对必要函数的虚假调用（不幸的是），但期望行为应该还是很清楚的。变量
d被赋值为1.0，然后乘以本身。此结果应再次为1.0，将其写入数组并打印到控制台。因此，期望的输出是：d = 1
result[1] = 1
然而，获得的输出是：
d = 1
result[1] = 3.77013e+214
测试环境
该代码使用 Visual Studio Community 2019 自带的 C++ 编译器测试（最新更新，VS 16.11.9，VC++ 00435-60000-00000-AA327）。问题只在启用优化选项（/O2）时出现。使用 /Od 进行编译会生成正确的输出结果。
在简化示例中（不是编译完整库时的原始问题），我还必须禁用“完整程序优化”，否则编译器会摆脱我的虚假函数调用。
这个简化示例只有在针对 x86 编译时才会重现问题（其他示例为 x64 时重现问题）。
完整的编译命令行如下所示：/permissive- /ifcOutput "Release\" /GS /analyze- /W3 /Gy /Zc:wchar_t /Zi /Gm- /O2 /sdl /Fd"Release\vc142.pdb" /Zc:inline /fp:precise /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_UNICODE" /D "UNICODE" /errorReport:prompt /WX- /Zc:forScope /Gd /Oy- /Oi /MD /FC /Fa"Release\" /EHsc /nologo /Fo"Release\" /Fp"Release\DecimateBug2.pch" /diagnostics:column
完整的 Visual Studio 解决方案可下载：https://drive.google.com/file/d/1EyoX0uXEkvfJ_Fh649k9XjJQPdDUMik7/view?usp=sharing
GNU 编译器和 Clang 都会生成正确输出结果的二进制文件。
问题
这段代码是否存在我无法看到并且导致错误结果的未定义行为？还是应该将其报告为编译器的错误？
编译器生成的汇编代码
对于两行乘法操作：
result[0] = d * v[2];
result[1] = d * d;
编译器生成以下汇编代码：
00CF1432 movsd xmm1,mmword ptr [esp+18h] // Load d into first part of xmm1
00CF1438 unpcklpd xmm1,xmm1 // Load d into second part of xmm1
00CF143C movups xmm0,xmmword ptr [esp+30h] // Load second operands into xmm0
00CF1441 mulpd xmm0,xmm1 // 2 multiplications at one
00CF1445 movups xmmword ptr [esi],xmm0 // store result
显然它试图使用 "mulpd" 一次执行两个乘法操作。在前两行中，它成功地将“d”操作数加载到 "xmm1" 寄存器的两个部分中 (作为第一个操作数)。但是，在尝试加载第二个操作数 ("v[2]" 和 "d") 时，它只是从 "v[2]" 地址 ("esp+30h") 加载了 128 位。这对于第一个乘法的第二个操作数 ("v[2]") 这很好，但并非适用于第二个乘法 (与 "d" 相乘)。显然，代码假定 "d" 在内存中紧跟着 "v"。然而，它不是。变量 "d" 实际上从未被存储在内存中，似乎只存在于寄存器中。
这让我强烈怀疑编译器存在漏洞。但是，我想确认一下是否有任何未定义的行为，使错误的汇编得到了证明。
DecimalBug2.zip的解决方案，并确认了该 Bug。 - prapin