This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Build problem with libgo runtime
- From: "William J. Schmidt" <wschmidt at linux dot vnet dot ibm dot com>
- To: gcc at gcc dot gnu dot org
- Cc: iant at google dot com, bergner at vnet dot ibm dot com
- Date: Thu, 10 May 2012 21:19:38 -0500
- Subject: Build problem with libgo runtime
I'm investigating another build failure for Fedora 17 (based on 4.7).
The failing compile from the build log is as follows:
/bin/sh ./libtool --tag=CC
--mode=compile /builddir/build/BUILD/gcc-4.7.0-20120504/obj-ppc64-redhat-linux/./gcc/xgcc -B/builddir/build/BUILD/gcc-4.7.0-20120504/obj-ppc64-redhat-linux/./gcc/ -B/usr/ppc64-redhat-linux/bin/ -B/usr/ppc64-redhat-linux/lib/ -isystem /usr/ppc64-redhat-linux/include -isystem /usr/ppc64-redhat-linux/sys-include -DHAVE_CONFIG_H -I. -I../../../libgo -I ../../../libgo/runtime -I../../../libgo/../libffi/include -I../libffi/include -pthread -fexceptions -fplan9-extensions -Wall -Wextra -Wwrite-strings -Wcast-qual -Werror -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I ../../../libgo/../libgcc -I ../../gcc/include -O2 -O3 -mtune=power7 -mcpu=power7 -g -fsigned-char -MT proc.lo -MD -MP -MF .deps/proc.Tpo -c -o proc.lo `test -f 'runtime/proc.c' || echo '../../../libgo/'`runtime/proc.c
The reported failure:
../../../libgo/runtime/proc.c: In function â__go_goâ:
../../../libgo/runtime/proc.c:1323:8: error: variable âspâ might be
clobbered by âlongjmpâ or âvforkâ [-Werror=clobbered]
../../../libgo/runtime/proc.c:1324:9: error: variable âspsizeâ might be
clobbered by âlongjmpâ or âvforkâ [-Werror=clobbered]
cc1: all warnings being treated as errors
The declarations in question are:
byte *sp;
size_t spsize;
G * volatile newg; // volatile to avoid longjmp warning
What's interesting here is that I don't see a problem when compiling for
a 32-bit target. However, it's also apparent that making "newg"
volatile was deemed sufficient up till now, so I am wondering if there
is something about our build options/environment that could cause the
problem.
I can work around the problem with the following patch, but would
appreciate any insights into whether this should be necessary, and if
not, what we're doing "wrong."
Thanks!
Bill
*** proc.c.orig 2012-05-10 21:02:13.394995624 -0500
--- proc.c 2012-05-10 21:01:36.050994265 -0500
*************** __go_go(void (*fn)(void*), void* arg)
*** 1323,1328 ****
--- 1323,1330 ----
byte *sp;
size_t spsize;
G * volatile newg; // volatile to avoid longjmp warning
+ byte * volatile vsp;
+ size_t volatile vspsize;
schedlock();
*************** __go_go(void (*fn)(void*), void* arg)
*** 1363,1374 ****
if(sp == nil)
runtime_throw("nil g->stack0");
getcontext(&newg->context);
! newg->context.uc_stack.ss_sp = sp;
#ifdef MAKECONTEXT_STACK_TOP
! newg->context.uc_stack.ss_sp += spsize;
#endif
! newg->context.uc_stack.ss_size = spsize;
makecontext(&newg->context, kickoff, 0);
newprocreadylocked(newg);
--- 1365,1379 ----
if(sp == nil)
runtime_throw("nil g->stack0");
+ vsp = sp;
+ vspsize = spsize;
+
getcontext(&newg->context);
! newg->context.uc_stack.ss_sp = vsp;
#ifdef MAKECONTEXT_STACK_TOP
! newg->context.uc_stack.ss_sp += vspsize;
#endif
! newg->context.uc_stack.ss_size = vspsize;
makecontext(&newg->context, kickoff, 0);
newprocreadylocked(newg);