An Intel employee reports it should be fixed in the upcoming 2026.0 release.
https://community.intel.com/t5/Intel-oneAPI-DPC-C-Compiler/Bug-icx-2025-3-3-miscompiles-loop-conditional-logic-in-gnulib/m-p/1744299/thread-id/4734#M4736 On Tue, Apr 14, 2026, at 10:44 AM, Harmen Stoppels wrote: > I've quoted your message in > https://community.intel.com/t5/Intel-oneAPI-DPC-C-Compiler/Bug-icx-2025-3-3-miscompiles-loop-conditional-logic-in-gnulib/m-p/1744299. > > Yesterday they were very quick to respond. > > On Tue, Apr 14, 2026, at 10:11 AM, Paul Eggert wrote: >> On 2026-04-13 15:32, Bruno Haible via Gnulib discussion list wrote: >>> Whereas the abort()s in test-mcel.c look like a compiler bug: When I compile >>> with "-O2 -g" instead of "-O2", the abort occurs at a different line... >> >> Looks like a compiler bug to me too. Harmen, do you know how to report >> compiler bugs to Intel? Is that something you can do for us? >> >> Here's how to reproduce the bug: >> >> git clone https://git.savannah.gnu.org/git/gnulib.git >> cd gnulib >> ./gnulib-tool --create-testdir --dir foo mcel >> cd foo >> ./configure CC=icx >> make check >> >> This fails test-mcel-1.sh, test-mcel-2.sh, test-mcel-3.sh, >> test-mcel-5.sh. You can more easily reproduce a failure by running this >> command next: >> >> cd gltests >> ./test-mcel 1 >> >> This outputs: >> >> test-mcel.c:108: assertion 'sgn (mcel_tocmp (to_ascii, prev, c)) == cmp' >> failed >> >> before dumping core. The test failure occurs because the code generated >> by idx is wrong. Source code that looks like this: >> >> for (int ch = 0x80; ch < 0x200; ch++) >> { >> mcel_t c = mcel_ch (ch, 2); >> ASSERT (c.ch == ch); >> ASSERT (c.len == 2); >> ASSERT (!c.err); >> ASSERT (mcel_cmp (c, c) == 0); >> ASSERT (mcel_eq (c, c)); >> ASSERT (mcel_tocmp (to_ascii, c, c) == 0); >> ASSERT (mcel_cmp (prev, c) < 0); >> ASSERT (mcel_cmp (c, prev) > 0); >> ASSERT (! mcel_eq (prev, c)); >> ASSERT (! mcel_eq (c, prev)); >> ASSERT (mcel_tocmp (to_ascii, c, c) == 0); >> int cmp = to_ascii (c.ch) ? -1 : 1; >> ASSERT (sgn (mcel_tocmp (to_ascii, prev, c)) == cmp); >> ASSERT (sgn (mcel_tocmp (to_ascii, c, prev)) == -cmp); >> prev = c; >> } >> >> turns into the following assembly-language loop when compiled by icx >> 2025.3.3 (2025.3.3.20260319): >> >> xorl %eax, %eax >> .p2align 4 >> .LBB0_14: # =>This Inner Loop Header: Depth=1 >> leal (%rax,%rax), %ecx >> leal 1(%rcx), %edx >> andb $127, %dl >> addb $2, %cl >> andb $126, %cl >> cmpb %cl, %dl >> jae .LBB0_15 >> # %bb.63: # in Loop: Header=BB0_14 Depth=1 >> incl %eax >> cmpl $191, %eax >> jne .LBB0_14 >> >> where .LBB0_15 prints the assertion failure for the "sgn (mcel_tocmp >> (to_ascii, prev, c)) == cmp" test. In other words, all the assertions >> tests have been optimized away except for the "sgn (mcel_tocmp >> (to_ascii, prev, c)) == cmp" test, and that test is optimized away half >> the time but the half that isn't optimized away to nothing is optimized >> into incorrect code. >> >> In contrast GCC 15.2.1 20260123 (Red Hat 15.2.1-7) generates the >> following code, which is slower but correct: >> >> movl $127, %esi >> jmp .L5 >> .p2align 4,,10 >> .p2align 3 >> .L8: >> addl $2, %esi >> movl $1, %eax >> .L9: >> andl $127, %edx >> xorl %edi, %edi >> movl %edx, %ecx >> subl %eax, %ecx >> testl %ecx, %ecx >> setg %dil >> shrl $31, %ecx >> subl %ecx, %edi >> cmpl $-1, %edi >> jne .L73 >> subl %edx, %eax >> xorl %edx, %edx >> testl %eax, %eax >> setg %dl >> shrl $31, %eax >> subl %eax, %edx >> cmpl $1, %edx >> jne .L74 >> cmpl $511, %esi >> je .L75 >> .L5: >> leal 1(%rsi), %edx >> movl %edx, %eax >> andl $127, %eax >> je .L8 >> movl %esi, %ecx >> movl %edx, %esi >> movl %ecx, %edx >> jmp .L9 >> .L75: >> >> ... where .L73 prints the failure for "sgn (mcel_tocmp (to_ascii, prev, >> c)) == cmp", and .L74 prints the failure for "sgn (mcel_tocmp (to_ascii, >> c, prev)) == -cmp".
