Closed GoogleCodeExporter closed 9 years ago
The code is broken only for three iterative solvers: QMR, QMR2, and CSYM. The
problem occurs only when optimization is performed by compiler, probably due to
incorrect handling of static (inside function) variables, which carry
information between function calls. Also built-in intrinsics can be involved.
In particular, compiling with options '-g' or '-O0' produces correct code,
while '-g -fbuiltin' breaks the code. Also, '-O1' and larger breaks code in
combination with any other options, even '-O1 -fno-builtin' (which is strange).
I have localized the problematic variables and added several dumb statements to
iterative.c in r1136. This resolves the issue for icc 11.1 on cluster in
Novosibirsk. I have even tested the suite in tests/2exec on intel vs. gnu
compiler - and everything is fine.
This fix should be verified on other hardware/compiler versions.
Overall, I believe that this is a compiler bug, which is troubling that it may
affect other parts of code (in the future). Hopefully, this bug is fixed in
later versions of the compiler (at least one test with icc 12.0 suggests so).
Original comment by yurkin
on 13 May 2012 at 12:25
Chao Liu verified that the fix works for his cluster (with icc 11.1.073).
I have run a few extra tests on LISA cluster (in Amsterdam). For icc 11.0.074
the issue is irrelevant - code compiles and works fine both before and after
the fix. For icc 11.1.072 the issue is relevant (code is broken before the fix,
but fine afterwards).
Original comment by yurkin
on 14 May 2012 at 8:33
There is another problem with icc 11.1 using -O3 (but not -O2). It is
highlighted by r1309. Unfortunately, this time I couldn't find any simple fix,
so I just recommend not to use this version of icc.
Original comment by yurkin
on 17 Feb 2014 at 11:02
Original issue reported on code.google.com by
yurkin
on 11 May 2012 at 5:48