- User Since
- Dec 3 2013, 8:54 AM (313 w, 4 d)
Fri, Nov 29
Oct 14 2019
Sep 29 2019
Sep 25 2019
confirmed fixed in git master and 1.23.0-beta3
Sep 24 2019
After some more testing- this is triggered by adding -O2 w/gcc 9.2.1 (testing w/Debian bullseye)
Sep 23 2019
Sep 22 2019
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/>.
May 21 2019
Feb 3 2019
Jan 15 2019
patch is tested, confirmed working
Dec 22 2018
Nov 25 2018
- Also install terminology-helpers.1
I can still reproduce this issue on 1.3.0.
Oct 30 2018
Aug 20 2018
Confirmed working, thanks!
Aug 19 2018
Aug 18 2018
Mar 6 2018
I see, makes sense to me. Thanks for explaining.
Mar 4 2018
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.
Mar 3 2018
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.
Feb 25 2018
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.
Dec 2 2017
Nov 27 2017
Nov 26 2017
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.
Nov 5 2017
Oct 22 2017
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
Oct 19 2017
Was this api considered stable prior to the merge? If not, this isn't worth any more time.
Oct 18 2017
exactimage can use software X11 and GL X11. It worked with 1.8, but fails to build against 1.20.
Oct 8 2017
Sep 6 2017
Sorry. Reproduced with 0.21.9. Backtrace:
Sep 5 2017
Dec 21 2016
Nov 20 2016
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: