major internal compiler error on amd64 FreeBSD

[Steve Kargl]

troutmask:sgk[210] ~/work/bin/pcc -c zxc.c
major internal compiler error: zxc.c, line 13
troutmask:sgk[211] cat zxc.c
#include <stdlib.h>
#include <math.h>

void
parcomp(int start)
{
double *cost;
int i;

cost = malloc(start * sizeof *cost);

for (i = 0; i < start; i++)
cost[i] = HUGE_VAL;
}

A heavily edited pre-processed version of the above is

troutmask:sgk[212] ~/work/bin/pcc -c z.c
major internal compiler error: z.c, line 17
troutmask:sgk[213] cat z.c

typedef unsigned long __uint64_t;
typedef __uint64_t __size_t;
typedef __size_t size_t;

void *malloc(size_t) __attribute__((__malloc__));

void
parcomp(int start)
{
double *cost;
int i;

cost = malloc(start * sizeof *cost);

for (i = 0; i < start; i++)
cost[i] = __builtin_huge_val();
}

[Steve Kargl]

Post by Steve Kargl
troutmask:sgk[212] ~/work/bin/pcc -c z.c
major internal compiler error: z.c, line 17
troutmask:sgk[213] cat z.c
typedef unsigned long __uint64_t;
typedef __uint64_t __size_t;
typedef __size_t size_t;
void *malloc(size_t) __attribute__((__malloc__));
void
parcomp(int start)
{
double *cost;
int i;
cost = malloc(start * sizeof *cost);
for (i = 0; i < start; i++)
cost[i] = __builtin_huge_val();
}

Simplify testcase.

void
parcomp(void)
{
double cost;
cost = __builtin_huge_val();
}

If I compile pcc with gcc, then the resulting pcc
can compile the above compiles.

If I compile pcc with itself, then the resulting
pcc fails to compile the above code.

I have no clue on how to debug this one. :(

[Steve Kargl]

Post by Steve Kargl
Simplify testcase.
void
parcomp(void)
{
double cost;
cost = __builtin_huge_val();
}
If I compile pcc with gcc, then the resulting pcc
can compile the above compiles.
If I compile pcc with itself, then the resulting
pcc fails to compile the above code.
I have no clue on how to debug this one. :(

troutmask:sgk[214] cd ~/pcc/pcc/cc//ccom
troutmask:sgk[215] gdb ./ccom
GNU gdb 6.1.1 [FreeBSD]
(gdb) run z.c
Starting program: /usr/home/sgk/pcc/pcc/cc/ccom/ccom z.c

Program received signal SIGSEGV, Segmentation fault.
0x00000000004025d0 in builtin_check () at ./builtins.c:630
630 return NIL;
(gdb) bt
#0 0x00000000004025d0 in builtin_check () at ./builtins.c:630
Error accessing memory address 0x7fff7ff00008: Bad address.

[Iain Hibbert]

Post by Steve Kargl

Post by Steve Kargl
Simplify testcase.
void
parcomp(void)
{
double cost;
cost = __builtin_huge_val();
}
If I compile pcc with gcc, then the resulting pcc
can compile the above compiles.
If I compile pcc with itself, then the resulting
pcc fails to compile the above code.
I have no clue on how to debug this one. :(

troutmask:sgk[214] cd ~/pcc/pcc/cc//ccom
troutmask:sgk[215] gdb ./ccom
GNU gdb 6.1.1 [FreeBSD]
(gdb) run z.c
Starting program: /usr/home/sgk/pcc/pcc/cc/ccom/ccom z.c
Program received signal SIGSEGV, Segmentation fault.
0x00000000004025d0 in builtin_check () at ./builtins.c:630
630 return NIL;

I'd guess, that the builtin_check() function or something it called has
corrupted the return value held on the stack, or the stack pointer.. you
could compile with -fstack-protector to verify that, and a bit more
debugging with breakpoints might pin down the defective code..

iain

[Steve Kargl]

Post by Iain Hibbert

Post by Steve Kargl

Post by Steve Kargl
Simplify testcase.
void
parcomp(void)
{
double cost;
cost = __builtin_huge_val();
}
If I compile pcc with gcc, then the resulting pcc
can compile the above compiles.
If I compile pcc with itself, then the resulting
pcc fails to compile the above code.
I have no clue on how to debug this one. :(

troutmask:sgk[214] cd ~/pcc/pcc/cc//ccom
troutmask:sgk[215] gdb ./ccom
GNU gdb 6.1.1 [FreeBSD]
(gdb) run z.c
Starting program: /usr/home/sgk/pcc/pcc/cc/ccom/ccom z.c
Program received signal SIGSEGV, Segmentation fault.
0x00000000004025d0 in builtin_check () at ./builtins.c:630
630 return NIL;

I'd guess, that the builtin_check() function or something it called has
corrupted the return value held on the stack, or the stack pointer.. you
could compile with -fstack-protector to verify that, and a bit more
debugging with breakpoints might pin down the defective code..

Adding -fstack-protect did not reveal anything new.

If I comple pcc without optimization and then recompile
pcc with itself without optimization, the above code
compiles. Without optimization, I see

.section .rodata
.align 8
.L15:
.long 0x0,0x7ff00000
.text
.align 4
.globl parcomp
.type parcomp,@function
parcomp:
pushq %rbp
movq %rsp,%rbp
subq $16,%rsp
.L11:
.L13:
movsd .L15(%rip),%xmm0
movsd %xmm0,-8(%rbp)
.L12:
leave
ret
.size parcomp,.-parcomp
.ident "PCC: pcc 1.1.0.DEVEL 20110807 for x86_64-unknown-freebsd9.0"
.end

[Steve Kargl]

Post by Steve Kargl
troutmask:sgk[210] ~/work/bin/pcc -c zxc.c
major internal compiler error: zxc.c, line 13

This issue on amd64-*-freebsd is directly related
to the -xtemps option of ccom. I've hacked the
Makefile in ccom to add various combinations of
-xdeljumps, -xtemps, and -xinline to CFLAGS.

PS: note -xinline is not documented in ccom.1 but
is mentioned in cc.1.

[Steve Kargl]

Post by Steve Kargl

Post by Steve Kargl
troutmask:sgk[210] ~/work/bin/pcc -c zxc.c
major internal compiler error: zxc.c, line 13

This issue on amd64-*-freebsd is directly related
to the -xtemps option of ccom. I've hacked the
Makefile in ccom to add various combinations of
-xdeljumps, -xtemps, and -xinline to CFLAGS.
PS: note -xinline is not documented in ccom.1 but
is mentioned in cc.1.

Well, I've removed setting -xtemps when pcc is used
with the -O options, and the resulting pcc actually
works!

I have just built the hierloom-doctools programs with
pcc and the resulting nroff and troff work. This
is the first time that pcc has been able to be build
a functioning hierloom-doctools on amd64-*-freebsd.

[Iain Hibbert]

Post by Steve Kargl

Post by Steve Kargl

Post by Steve Kargl
troutmask:sgk[210] ~/work/bin/pcc -c zxc.c
major internal compiler error: zxc.c, line 13

This issue on amd64-*-freebsd is directly related
to the -xtemps option of ccom. I've hacked the
Makefile in ccom to add various combinations of
-xdeljumps, -xtemps, and -xinline to CFLAGS.
PS: note -xinline is not documented in ccom.1 but

added

Post by Steve Kargl
Well, I've removed setting -xtemps when pcc is used
with the -O options, and the resulting pcc actually
works!

I find that -xtemps often seems to be the cause of errors, but since that
code is actually quite simple it is not generally the fault of -xtemps
directly, but rather that use of it increases what I would call register
pressure, and so is revealing the problem only..

iain

[Steve Kargl]

Post by Iain Hibbert

Post by Steve Kargl

Post by Steve Kargl

Post by Steve Kargl
troutmask:sgk[210] ~/work/bin/pcc -c zxc.c
major internal compiler error: zxc.c, line 13

This issue on amd64-*-freebsd is directly related
to the -xtemps option of ccom. I've hacked the
Makefile in ccom to add various combinations of
-xdeljumps, -xtemps, and -xinline to CFLAGS.
PS: note -xinline is not documented in ccom.1 but

added

Post by Steve Kargl
Well, I've removed setting -xtemps when pcc is used
with the -O options, and the resulting pcc actually
works!

I find that -xtemps often seems to be the cause of errors, but since that
code is actually quite simple it is not generally the fault of -xtemps
directly, but rather that use of it increases what I would call register
pressure, and so is revealing the problem only..

Once I found that -xtemps was related to the problem, I
did look through the code. Yes, the code looks quite
simple. If -xtemps is triggering an issue with register
pressure, I'm fairly confident that I have insufficient
brain power to find and fix the issue.

[Anders Magnusson]

Hi,

Post by Steve Kargl

Post by Steve Kargl

Post by Steve Kargl
troutmask:sgk[210] ~/work/bin/pcc -c zxc.c
major internal compiler error: zxc.c, line 13

This issue on amd64-*-freebsd is directly related
to the -xtemps option of ccom. I've hacked the
Makefile in ccom to add various combinations of
-xdeljumps, -xtemps, and -xinline to CFLAGS.
PS: note -xinline is not documented in ccom.1 but
is mentioned in cc.1.

Well, I've removed setting -xtemps when pcc is used
with the -O options, and the resulting pcc actually
works!

Note that -xtemps is needed to be able to do almost
any types of optimizations. Without it variables will
never be put in registers.

-- Ragge

Post by Steve Kargl
I have just built the hierloom-doctools programs with
pcc and the resulting nroff and troff work. This
is the first time that pcc has been able to be build
a functioning hierloom-doctools on amd64-*-freebsd.

[Steve Kargl]

Post by Anders Magnusson
Hi,

Post by Steve Kargl

Post by Steve Kargl

Post by Steve Kargl
troutmask:sgk[210] ~/work/bin/pcc -c zxc.c
major internal compiler error: zxc.c, line 13

This issue on amd64-*-freebsd is directly related
to the -xtemps option of ccom. I've hacked the
Makefile in ccom to add various combinations of
-xdeljumps, -xtemps, and -xinline to CFLAGS.
PS: note -xinline is not documented in ccom.1 but
is mentioned in cc.1.

Well, I've removed setting -xtemps when pcc is used
with the -O options, and the resulting pcc actually
works!

Note that -xtemps is needed to be able to do almost
any types of optimizations. Without it variables will
never be put in registers.

This patch appears to
(a) fix
(b) workaround
(c) cover-up
(d) all of the above
the issue.

Index: cc/ccom/builtins.c
===================================================================
RCS file: /cvsroot/pcc/cc/ccom/builtins.c,v
retrieving revision 1.30
diff -c -p -r1.30 builtins.c
*** cc/ccom/builtins.c 11 Aug 2011 18:31:31 -0000 1.30
--- cc/ccom/builtins.c 11 Aug 2011 18:58:54 -0000
*************** static char nLDOUBLE[] = { 0x7f, 0xff, 0
*** 576,582 ****

#define VALX(typ,TYP) { \
typ d; \
! int x; \
x = MIN(sizeof(n ## TYP), sizeof(d)); \
memcpy(&d, v ## TYP, x); \
nfree(f); \
--- 576,582 ----

#define VALX(typ,TYP) { \
typ d; \
! volatile int x; \
x = MIN(sizeof(n ## TYP), sizeof(d)); \
memcpy(&d, v ## TYP, x); \
nfree(f); \

[Anders Magnusson]

Hi,

I have just checked in a fix for this, it was an interesting bug to find :-)
The problem was that a double were put onto the stack, but the type
propagation code had casted it to a char and therefore reserved too
little space on the stack.

Thanks for good bug reports!

-- Ragge

Post by Steve Kargl

Post by Anders Magnusson
Hi,

Post by Steve Kargl

Post by Steve Kargl

Post by Steve Kargl
troutmask:sgk[210] ~/work/bin/pcc -c zxc.c
major internal compiler error: zxc.c, line 13

This issue on amd64-*-freebsd is directly related
to the -xtemps option of ccom. I've hacked the
Makefile in ccom to add various combinations of
-xdeljumps, -xtemps, and -xinline to CFLAGS.
PS: note -xinline is not documented in ccom.1 but
is mentioned in cc.1.

Well, I've removed setting -xtemps when pcc is used
with the -O options, and the resulting pcc actually
works!

Note that -xtemps is needed to be able to do almost
any types of optimizations. Without it variables will
never be put in registers.

This patch appears to
(a) fix
(b) workaround
(c) cover-up
(d) all of the above
the issue.
Index: cc/ccom/builtins.c
===================================================================
RCS file: /cvsroot/pcc/cc/ccom/builtins.c,v
retrieving revision 1.30
diff -c -p -r1.30 builtins.c
*** cc/ccom/builtins.c 11 Aug 2011 18:31:31 -0000 1.30
--- cc/ccom/builtins.c 11 Aug 2011 18:58:54 -0000
*************** static char nLDOUBLE[] = { 0x7f, 0xff, 0
*** 576,582 ****
#define VALX(typ,TYP) { \
typ d; \
! int x; \
x = MIN(sizeof(n ## TYP), sizeof(d)); \
memcpy(&d, v ## TYP, x); \
nfree(f); \
--- 576,582 ----
#define VALX(typ,TYP) { \
typ d; \
! volatile int x; \
x = MIN(sizeof(n ## TYP), sizeof(d)); \
memcpy(&d, v ## TYP, x); \
nfree(f); \