https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90378
Christophe Lyon <clyon at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2020-03-11
CC| |clyon at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #7 from Christophe Lyon <clyon at gcc dot gnu.org> ---
I am able to reproduce the failure with the same commit mentioned by Maxim in
comment #3. Using a more recent trunk (Feb 21, 2020) made the problem
disappear.
I'm using -Os -flto -mthumb, with a GCC bootstrapped on an armv7 machine
(cortex-a15, NVidia jetson-tk1).
Like Maxim said in comment #1, if I copy the binary and runtime libs
(libgfortran, etc....) to an ARMv8 machine with AArch32 mode support, the
execution is successful.
The failure looks like this:
====================================
[...]
increment 1 attempt 1
increment size= 5.000000e-02
sum of previous increments=0.000000e+00
ilin=0
iteration 1
Segmentation fault
====================================
Under gdb:
Program received signal SIGSEGV, Segmentation fault.
0xb6deab58 in ?? () from /home/christophe.lyon/calculix.broken/lib/libc.so.6
(gdb) bt
#0 0xb6deab58 in ?? () from
/home/christophe.lyon/calculix.broken/lib/libc.so.6
#1 0xb6deb01e in ?? () from
/home/christophe.lyon/calculix.broken/lib/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
When using valgrind (3.11.0), several errors are reported before reaching the
point where the code normally crashes, but execution continues:
====================================
[...]
increment 1 attempt 1
increment size= 5.000000e-02
sum of previous increments=0.000000e+00
ilin=0
iteration 1
largest residual force= 203.899659
no convergence
iteration 2
====================================
Most of the errors are "Invalid write of size 4" or "Use of uninitialised value
of size 4" in bpabi.S lines 256-259, which correspond to macro expansion of
push_for_divide and pop_for_divide in aeabi_uldivmod. The errors are about
reading/writing in the stack.
When using valgrind (3.13.0) on ARMv8 hardware, it does not report any error,
so I'm puzzled: was it a bug in valgrind-3.11.0, or are some glibc ifuncs
changing the behaviour?
Anyway, I still don't know where the program crashes on ARMv7 hardware.
