[Note: lang/gcc6's xgcc's cc1 was built by clang for the stage of the lang/gcc6 bootstrap that was in use below. So the code generation problem is clang's, not gcc6's or xgcc's.]

The below was found while trying to figure out why a bootstrap lang/gcc6 build on a armv6/cortex-a7 stable/11  -r307797 crashes in xgcc's cc1 with SIGSYS for some of what xgcc tries to build. I'm recording this here while pursuing the system problems the context has also exposed: truss's error handling for watching the failing cc1 has crash problems of its own.

The cc1 crash (when under gdb) shows a stack address as the pc value once the problem happens. In more detail, when ( in gcc/gimple-match-head.c ):

bool
gimple_resimplify1 (gimple_seq *seq,
                    code_helper *res_code, tree type, tree *res_ops,
                    tree (*valueize)(tree))
{
. . .
}

returns the armv6 pc ends up with a stack address instead of a code address.

[There may be other cc1 routines with similar problems. I've only analyzed the one example stack corruption.]

Eliminating the long names (mostly) in the gdb disassembly output for gimple_resimplify1 so the code is easier to see --and showing function stack-handing preamble/post-amble code only:

Dump of assembler code for function _Z18gimple_resimplify1PP6gimpleP11code_helperP9tree_nodePS5_PFS5_S5_E:
0x0105d5ec  push	{r0, r1, r4, r6, r8, r11, sp, lr}
0x0105d5f0  add	r11, sp, #16	; 0x10
0x0105d5f4  sub	sp, sp, #88	; 0x58
. . .
0x0105d7e0  sub	sp, r11, #16	; 0x10
0x0105d7e4  pop	{r4, r5, r6, r10, r11, pc}

Note that, just after restoring sp to its value from just after the push, the pop does not match the push and restores what was r11 (a pointer into the stack) to the pc register, matching the observed behavior that gdb shows: execution of stack contents.

I have used stepi in gdb to go up to and through the pop and so have seen the evidence of the corruption fairly directly: just after the pop things are messed up in gdb with a stack address shown for the pc value.

So it is a code generation defect for at least armv6 / cortext-a7.


Context details:

root@bananapi-m3:/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/armv6-portbld-freebsd11.0/libgcc # svnlite info /mnt/usr/ports | grep "Re[lv]"
Relative URL: ^/head
Revision: 424540
Last Changed Rev: 424540

root@bananapi-m3:/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/armv6-portbld-freebsd11.0/libgcc # uname -apKU
FreeBSD bananapi-m3 11.0-STABLE FreeBSD 11.0-STABLE #0 r307797M: Sat Oct 29 10:54:45 PDT 2016     markmi@FreeBSDx64:/usr/local/src/crochet/work/obj/arm.armv6/usr/src/sys/ALLWINNER  arm armv6 1100505 1100505

(So stable/11 -r307797 was built with crochet, not with my usual procedure.)


The crashing cc1 shows crash problems in truss. ktrace reports odd information from the stack corruption as well but does not crash.

So for now the environment with all these issues is being kept in a form appropriate to testing the stable/11 truss issue(s). For example John Baldwin is working on truss for the its issue(s) and when he asks I rebuild world/kernel with his truss related updates and report what happened. (truss does not work yet for handling the cc1 failure as of when I wrote this.)

root@bananapi-m3:/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/armv6-portbld-freebsd11.0/libgcc # more /etc/make.conf 
DEFAULT_VERSIONS+=perl5=5.22
WRKDIRPREFIX=/usr/obj/portswork
WITH_DEBUG=
WITH_DEBUG_FILES=
MALLOC_PRODUCTION=
#
CFLAGS+= -mcpu=cortex-a7
CXXFLAGS+= -mcpu=cortex-a7
CPPFLAGS+= -mcpu=cortex-a7

So -mcpu=cortex-a7 was part of the CFLAGS/CXXFLAGS context while lang/gcc6 was being built. I'm not trying alternatives for such for now as I'm keeping the truss-testing context in place.