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".

Reply via email to