procyberian/emacs
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

* PROBLEMS (68000 C compiler problems): Remove obsolete section.

Browse source 
Not only are the compilers long-dead, the obsolete advice
typically doesn't apply to current Emacs sources.
This commit is contained in:
Paul Eggert 2012-06-04 10:17:48 -07:00
parent e364a2b7e1
commit a043d3535a
2 changed files with 6 additions and 44 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
etc/ChangeLog
View file

@ -1,3 +1,9 @@
2012-06-04 Paul Eggert <eggert@cs.ucla.edu>
* PROBLEMS (68000 C compiler problems): Remove obsolete section.
Not only are the compilers long-dead, the obsolete advice
typically doesn't apply to current Emacs sources.
2012-06-03 Chong Yidong <cyd@gnu.org>
* themes/wheatgrass-theme.el:

44
etc/PROBLEMS
View file

@ -3205,50 +3205,6 @@ causes the problem to go away.
The `contents' field of a Lisp vector is an array of Lisp_Objects,
so you may see the problem happening with indexed references to that.
** 68000 C compiler problems
Various 68000 compilers have different problems.
These are some that have been observed.
*** Using value of assignment expression on union type loses.
This means that x = y = z; or foo (x = z); does not work
if x is of type Lisp_Object.
*** "cannot reclaim" error.
This means that an expression is too complicated. You get the correct
line number in the error message. The code must be rewritten with
simpler expressions.
*** XCONS, XSTRING, etc macros produce incorrect code.
If temacs fails to run at all, this may be the cause.
Compile this test program and look at the assembler code:
struct foo { char x; unsigned int y : 24; };
lose (arg)
struct foo arg;
{
test ((int *) arg.y);
}
If the code is incorrect, your compiler has this problem.
In the XCONS, etc., macros in lisp.h you must replace (a).u.val with
((a).u.val + coercedummy) where coercedummy is declared as int.
This problem will only happen if USE_LISP_UNION_TYPE is manually
defined in lisp.h.
** C compilers lose on returning unions.
I hear that some C compilers cannot handle returning a union type.
Most of the functions in GNU Emacs return type Lisp_Object, which is
defined as a union on some rare architectures.
This problem will only happen if USE_LISP_UNION_TYPE is manually
defined in lisp.h.
This file is part of GNU Emacs.