[Bug middle-end/110796] New: builtin_iseqsig fails some tests in armv8l-linux-gnueabihf

[Bug middle-end/110796] New: builtin_iseqsig fails some tests in armv8l-linux-gnueabihf

[thiago.bauermann at linaro dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110796

            Bug ID: 110796
           Summary: builtin_iseqsig fails some tests in
                    armv8l-linux-gnueabihf
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: thiago.bauermann at linaro dot org
                CC: fxcoudert at gcc dot gnu.org
  Target Milestone: ---
            Target: armv8l-unknown-linux-gnueabihf

Commit 34cf27a64e7a "Add __builtin_iseqsig()" introduced the mentioned builtin
along with some new tests. Unfortunately they have some failures in
armv8l-linux-gnueabihf:

Running gcc:gcc.dg/torture/dg-torture.exp ...
FAIL: gcc.dg/torture/builtin-iseqsig-1.c -Os  execution test
FAIL: gcc.dg/torture/builtin-iseqsig-2.c -Os  execution test
FAIL: gcc.dg/torture/builtin-iseqsig-3.c -Os  execution test

gcc.log doesn't have any hint on what actually went wrong. E.g.:

Executing on host:
/home/thiago.bauermann/.cache/builds/gcc-native-aarch32/gcc/xgcc
-B/home/thiago.bauermann/.cache/builds/gcc-native-aarch32/gcc/
/home/thiago.bauermann/src/gcc/gcc/testsuite/gcc.dg/torture/builtin-iseqsig-1.c
   -fdiagnostics-plain-output    -Os  -fsignaling-nans  -lm  -o
./builtin-iseqsig-1.exe    (timeout = 300)
spawn -ignore SIGHUP
/home/thiago.bauermann/.cache/builds/gcc-native-aarch32/gcc/xgcc
-B/home/thiago.bauermann/.cache/builds/gcc-native-aarch32/gcc/
/home/thiago.bauermann/src/gcc/gcc/testsuite/gcc.dg/torture/builtin-iseqsig-1.c
-fdiagnostics-plain-output -Os -fsignaling-nans -lm -o ./builtin-iseqsig-1.exe
PASS: gcc.dg/torture/builtin-iseqsig-1.c   -Os  (test for excess errors)
Setting LD_LIBRARY_PATH to
:/home/thiago.bauermann/.cache/builds/gcc-native-aarch32/gcc::/home/thiago.bauermann/.cache/builds/gcc-native-aarch32/gcc
Execution timeout is: 300
spawn [open ...]
FAIL: gcc.dg/torture/builtin-iseqsig-1.c   -Os  execution test

The problem is still present in trunk as of commit 2a3556376c69 "match.pd:
Implement missed optimization (~X | Y) ^ X -> ~(X & Y) [PR109986]" from today.

Reproduced on Ubuntu 22.04 with:

$ ~/src/gcc/configure \
      --disable-bootstrap \
      --disable-multilib \
      --with-mode=thumb \
      --with-arch=armv8-a \
      --with-float=hard \
      --with-fpu=neon-fp-armv8 \
  && make -j 60 \
  && make -C gcc check-c RUNTESTFLAGS=gcc.dg/torture/dg-torture.exp

[Bug target/110796] builtin_iseqsig fails some tests in armv8l-linux-gnueabihf

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110796

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Does pr91323.c fail on arm?

[Bug target/110796] builtin_iseqsig fails some tests in armv8l-linux-gnueabihf

[thiago.bauermann at linaro dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110796

--- Comment #2 from Thiago Jung Bauermann <thiago.bauermann at linaro dot org> ---
Thanks for the quick response!

(In reply to Andrew Pinski from comment #1)
> Does pr91323.c fail on arm?

No, all its tests pass:

PASS: gcc.dg/torture/pr91323.c   -O0  (test for excess errors)
PASS: gcc.dg/torture/pr91323.c   -O0  execution test
PASS: gcc.dg/torture/pr91323.c   -O1  (test for excess errors)
PASS: gcc.dg/torture/pr91323.c   -O1  execution test
PASS: gcc.dg/torture/pr91323.c   -O2  (test for excess errors)
PASS: gcc.dg/torture/pr91323.c   -O2  execution test
PASS: gcc.dg/torture/pr91323.c   -O3 -g  (test for excess errors)
PASS: gcc.dg/torture/pr91323.c   -O3 -g  execution test
PASS: gcc.dg/torture/pr91323.c   -Os  (test for excess errors)
PASS: gcc.dg/torture/pr91323.c   -Os  execution test
PASS: gcc.dg/torture/pr91323.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (test for excess errors)
PASS: gcc.dg/torture/pr91323.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
PASS: gcc.dg/torture/pr91323.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  (test for excess errors)
PASS: gcc.dg/torture/pr91323.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test

[Bug target/110796] builtin_iseqsig fails some tests in armv8l-linux-gnueabihf

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110796

--- Comment #3 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
Do the failure only occur at -Os? Does it pass at -O0, -O1, -O2?
And could you possibly run builtin-iseqsig-1.c under gdb and obtain a
backtrace?

[Bug target/110796] builtin_iseqsig fails some tests in armv8l-linux-gnueabihf

[thiago.bauermann at linaro dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110796

--- Comment #4 from Thiago Jung Bauermann <thiago.bauermann at linaro dot org> ---
Thanks for looking into this.

(In reply to Francois-Xavier Coudert from comment #3)
> Do the failure only occur at -Os?

Only at -Os. The FAILs I mentioned in the bug report are the only ones that
occur.

> Does it pass at -O0, -O1, -O2?

Yes.

> And could you possibly run builtin-iseqsig-1.c under gdb and obtain a
> backtrace?

Here it is:

thiago.bauermann@tcwg-jade-03-dev:~/tmp$
/home/thiago.bauermann/.cache/builds/gcc-native-aarch32/gcc/xgcc
-B/home/thiago.bauermann/.cache/builds/gcc-native-aarch32/gcc/
/home/thiago.bauermann/src/gcc/gcc/testsuite/gcc.dg/torture/builtin-iseqsig-1.c
   -fdiagnostics-plain-output    -Os  -fsignaling-nans -ggdb3  -lm  -o
./builtin-iseqsig-1.exe
thiago.bauermann@tcwg-jade-03-dev:~/tmp$ gdb builtin-iseqsig-1.exe
Reading symbols from builtin-iseqsig-1.exe...
(gdb) r
Starting program: /home/thiago.bauermann/tmp/builtin-iseqsig-1.exe
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".

Program received signal SIGABRT, Aborted.
__libc_do_syscall () at ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:47
47      ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S: No such file or
directory.
(gdb) bt
#0  __libc_do_syscall () at ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:47
#1  0xf7e8d2ca in __pthread_kill_implementation (threadid=4160625664,
signo=signo@entry=6,
    no_tid=no_tid@entry=0) at pthread_kill.c:43
#2  0xf7e8d30c in __pthread_kill_internal (signo=6, threadid=<optimized out>)
at pthread_kill.c:78
#3  0xf7e5c840 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#4  0xf7e4d5e4 in __GI_abort () at abort.c:79
#5  0x00010426 in main ()
    at
/home/thiago.bauermann/src/gcc/gcc/testsuite/gcc.dg/torture/builtin-iseqsig-1.c:30
(gdb) frame 5
#5  0x00010426 in main ()
    at
/home/thiago.bauermann/src/gcc/gcc/testsuite/gcc.dg/torture/builtin-iseqsig-1.c:30
30        if (fetestexcept (FE_INVALID)) __builtin_abort ();
(gdb)

[Bug target/110796] builtin_iseqsig fails some tests in armv8l-linux-gnueabihf

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110796

--- Comment #5 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
OK, so it signals FE_INVALID on the first test. Can you run this with the same
options, and see what happens?

-------
#include <fenv.h>
#include <stdio.h>

void
ftrue (float x, float y)
{
  if (!__builtin_iseqsig (x, y))
    __builtin_abort ();
}

int
main ()
{
  volatile float f1, f2;

  f1 = 0.f; f2 = 0.f;
  if (fetestexcept (FE_INVALID)) printf("Invalid 1\n");
  ftrue (f1, f2);
  if (fetestexcept (FE_INVALID)) printf("Invalid 2\n");

  return 0;
}
-------

One surprising thing is that the directive "dg-add-options ieee" in the test
did not apparently add any other option for IEEE conformance…

[Bug target/110796] builtin_iseqsig fails some tests in armv8l-linux-gnueabihf

[rearnsha at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110796

--- Comment #6 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
Is the exception status supposed to be in a defined state when the test runs? 
Shouldn't there be a call to feclearexcept (FE_ALL_EXCEPT) at the start of the
test?

[Bug target/110796] builtin_iseqsig fails some tests in armv8l-linux-gnueabihf

[thiago.bauermann at linaro dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110796

--- Comment #7 from Thiago Jung Bauermann <thiago.bauermann at linaro dot org> ---
(In reply to Francois-Xavier Coudert from comment #5)
> OK, so it signals FE_INVALID on the first test. Can you run this with the
> same options, and see what happens?

It ran normally:

thiago.bauermann@tcwg-jade-03-dev:~/tmp$ cat test-1.c
#include <fenv.h>
#include <stdio.h>

void
ftrue (float x, float y)
{
    if (!__builtin_iseqsig (x, y))
        __builtin_abort ();
}

int
main ()
{
    volatile float f1, f2;

    f1 = 0.f; f2 = 0.f;
    if (fetestexcept (FE_INVALID)) printf("Invalid 1\n");
    ftrue (f1, f2);
    if (fetestexcept (FE_INVALID)) printf("Invalid 2\n");

    return 0;
}
thiago.bauermann@tcwg-jade-03-dev:~/tmp$
/home/thiago.bauermann/.cache/builds/gcc-native-aarch32/gcc/xgcc
-B/home/thiago.bauermann/.cache/builds/gcc-native-aarch32/gcc/ test-1.c 
-fdiagnostics-plain-output    -Os  -fsignaling-nans -ggdb3  -lm  -o ./test-1
thiago.bauermann@tcwg-jade-03-dev:~/tmp$ ./test-1
thiago.bauermann@tcwg-jade-03-dev:~/tmp$ echo $?
0
thiago.bauermann@tcwg-jade-03-dev:~/tmp$

> One surprising thing is that the directive "dg-add-options ieee" in the test
> did not apparently add any other option for IEEE conformance…

Ah, that's an interesting thread to pull. I'll investigate if there's any
option we should be adding.

[Bug target/110796] builtin_iseqsig fails some tests in armv8l-linux-gnueabihf

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110796

--- Comment #8 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
(In reply to Richard Earnshaw from comment #6)
> Is the exception status supposed to be in a defined state when the test
> runs?  Shouldn't there be a call to feclearexcept (FE_ALL_EXCEPT) at the
> start of the test?

Isn't the exception status guaranteed to be defined (and not signaling) when
the program starts?

But adding feclearexcept (FE_ALL_EXCEPT); at the beginning of main() could not
hurt, for sure.

[Bug target/110796] builtin_iseqsig fails some tests in armv8l-linux-gnueabihf

[rearnsha at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110796

--- Comment #9 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
proc add_options_for_ieee { flags } {
    if { [istarget alpha*-*-*]
         || [istarget sh*-*-*] } {
       return "$flags -mieee"
    }
    if { [istarget rx-*-*] } {
       return "$flags -mnofpu"
    }
    return $flags
}

So it looks like this isn't expecting to add anything in most cases.

[Bug target/110796] builtin_iseqsig fails some tests in armv8l-linux-gnueabihf

[thiago.bauermann at linaro dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110796

--- Comment #10 from Thiago Jung Bauermann <thiago.bauermann at linaro dot org> ---
(In reply to Francois-Xavier Coudert from comment #8)
> (In reply to Richard Earnshaw from comment #6)
> > Is the exception status supposed to be in a defined state when the test
> > runs?  Shouldn't there be a call to feclearexcept (FE_ALL_EXCEPT) at the
> > start of the test?
> 
> Isn't the exception status guaranteed to be defined (and not signaling) when
> the program starts?
> 
> But adding feclearexcept (FE_ALL_EXCEPT); at the beginning of main() could
> not hurt, for sure.

I tried adding feclearexcept (FE_ALL_EXCEPT); at the beginning of main() but it
didn't make a difference.

[Bug target/110796] builtin_iseqsig fails some tests in armv8l-linux-gnueabihf

[rearnsha at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110796

Richard Earnshaw <rearnsha at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2023-07-26
                 CC|                            |rearnsha at gcc dot gnu.org
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #11 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
Confirmed.  It only happens when generating Thumb code.  For Arm code it works
correctly.

I think the problem is that the Thumb code generator is emitting vcmf, while
the Arm code generator uses vcmfe - the latter sets the exception bits.

I'm not sure why the code is different yet, still investigating.

[Bug target/110796] builtin_iseqsig fails some tests in armv8l-linux-gnueabihf

[rearnsha at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110796

Richard Earnshaw <rearnsha at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |rearnsha at gcc dot gnu.org
             Status|NEW                         |ASSIGNED

--- Comment #12 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
Working on a patch.

[Bug target/110796] builtin_iseqsig fails some tests in armv8l-linux-gnueabihf

[xry111 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110796

Xi Ruoyao <xry111 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |xry111 at gcc dot gnu.org

--- Comment #13 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to Francois-Xavier Coudert from comment #8)
> (In reply to Richard Earnshaw from comment #6)
> > Is the exception status supposed to be in a defined state when the test
> > runs?  Shouldn't there be a call to feclearexcept (FE_ALL_EXCEPT) at the
> > start of the test?
> 
> Isn't the exception status guaranteed to be defined (and not signaling) when
> the program starts?

It should be guaranteed.  Otherwise it indicates a bug in kernel or libc.

> But adding feclearexcept (FE_ALL_EXCEPT); at the beginning of main() could
> not hurt, for sure.