confirmed fixed in git master and 1.23.0-beta3

After some more testing- this is triggered by adding -O2 w/gcc 9.2.1 (testing w/Debian bullseye)

Same failure on 1.23.0~beta2, but a different looking backtrace:

$ gdb src/tests/elementary/elementary_suite core
GNU gdb (Debian 8.3-1) 8.3
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

patch is tested, confirmed working

Untested patch is at https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=917126;filename=10_fix_filemanager_handling.diff;msg=104

• Also install terminology-helpers.1

I can still reproduce this issue on 1.3.0.

Confirmed working, thanks!

I see, makes sense to me. Thanks for explaining.

But since gcc wants to use NEON even for constant assignments, I'm worried that -mfpu=neon will result in fragile binaries on non-NEON. Debian's armhf policy currently requires supporting non-NEON, even though full NEON is best for many people.

Ah - gcc is using NEON to zero an unsigned long long. That's because 77d2e0cb959 enabled -mfpu=neon -ftree-vectorize to fix breaks due to mixed NEON/non-NEON fpu code. Since Debian supports non-NEON armhf, I think we need --disable-neon.

Hmmm, but evas_common_cpu_neon_test looks like a runtime check to see if NEON is usable. evas_common_cpu_feature_test calls it with a handler installed for SIGILL. For some reason, it's not being trapped though.

As noted in the upstream report: this change may break ABI if callers can provide w or h greater than a signed int. If that's a concern, changing the .h to match the .c is probably better.

I don't know of an upstream version control repo, but the tarball is here: http://dl.exactcode.de/oss/exact-image/exact-image-1.0.1.tar.bz2

Was this api considered stable prior to the merge? If not, this isn't worth any more time.

exactimage can use software X11 and GL X11. It worked with 1.8, but fails to build against 1.20.

Sorry. Reproduced with 0.21.9. Backtrace:

Do you know any way to get that info? I've looked around, haven't found anything. I had two other ideas, not sure if either is workable: