Re: support for pre-C99 compilers

Hi,

>It's more time-consuming to fix the various GC crashes that I'm observing
>on the various porting targets...
Some summary/stats would be nice at the end of your work: How much was caused by individual bugs in GCC, how much by subtly broken definitions in CLISP in some configurations.

BTW, the other day I had a feeling that some of the commit logs should mention in their one liner
summary that they are specific work-around for bugs in (current versions of) GCC.
The summary was overly general, whereas the patch actually and really was a work around for
some particular version of GCC on some particular machine or OS. This annoyed me, since perhaps
next year, GCC may be fixed, however the work-around in CLISP will likely remain for 10 years.

E.g. "Fix build failure on Linux/s390x."
https://sourceforge.net/p/clisp/clisp/ci/c845e414641a5c4805285f38239606c9b1397964/
but what it actually does is compile lisparit.c with -O1 instead of the normal -O2.

There's no configure check for it, it's simply hard-coded.

Same for eval.c with -O0 in some configurations. makemake.in reads:
  if [ $f = eval -a "$cpu" = ia64 -a $XCC_GCC = true ] ; then
    # gcc-2.96 on Linux/ia64 miscompiles eval.d when -O is used.
    flags2=$flags2' -O0'
  fi
gcc-2.xx? Even on my Amiga, I had something newer ;-)

-O0 for eval.d which contains the bytecode interpreter -- that must hurt performance!

(I'm not suggesting that configure should check for it, I'm just saying that it would be
useful for packagers to be able to identify work-arounds easily. Makemake.in counts 4300
lines, and the above is lost within them.)

Regards,
	Jörg

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
clisp-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/clisp-devel