[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: x86_64 problems/fix (was: alloc.c problem when GC_MARK_STACK is GC_U
Re: x86_64 problems/fix (was: alloc.c problem when GC_MARK_STACK is GC_USE_GCPROS_AS_BEFORE)
Mon, 12 Jul 2004 10:24:51 -0400
Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux)
address@hidden (Kim F. Storm) writes:
> Barry Fishman <address@hidden> writes:
>> I was unable to make any change to alloc.c that would fix the GC_MARK_STACK
>> problem without later crashes in the build while compiling the lisp
> Does the following patch work (if you undo the patch you suggested below)?
That was my first attempt at fixing the problem. The emacs (bootstrap)
build then failed later on during a lisp compile. I could not
diagnose what was causing it, but at the time assumed it was a
garbage collector problem.
Trying it again I get the following during a bootstrap build:
completion.el:2354:15:Warning: reference to free variable `c-mode-map'
completion.el:2364:15:Warning: reference to free variable `fortran-mode-map'
Fatal error (11)make: *** [compile] Error 1
make: Leaving directory `/home/barry/src/gen/emacs/lisp'
make: *** [bootstrap] Error 2
>> However, I suspect the attached change to src/s/gnu-linux.h is
>> approprate. This produces a working emacs (for me) on a amd64
>> gnu-linux system (SuSE 9.1), although it sidesteps the problem in
> This is a good change -- have you been using that for some time
> now without problems? If so, I will commit your patch.
I have been using it since July 6 without problems. Am I the only
one using emacs on a amd64 gnu-linux kernel?
I used the __amd64__ C define to identify the x86_64 processor. Under
SuSE 9.1 (gcc 3.3.3) __x86_64__ is also automatically defined. I
don't know if there is any advantage in picking one over the other.
The rest of the emacs sources does not seem to make this check
although the src/m/amdx86-64.h file wrongly declares that __x86_64 is