This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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);



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]