This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: x*alloc optimizations
- To: meissner at cygnus dot com, meyering at ascend dot com
- Subject: Re: x*alloc optimizations
- From: Michael Meissner <meissner at cygnus dot com>
- Date: Wed, 20 May 1998 15:22:24 -0400
- Cc: drepper at cygnus dot com, egcs at cygnus dot com
| Michael Meissner <meissner@cygnus.com> writes:
| | This is an unneeded micro-optimization. I would rather burn the 2-3
| | instructions for every xmalloc call than add a bunch of configure support and
| | ifdefs to complicate the code. Especially for Canadian crosses where you can't
| | test the behavior of the runtime system. Another problem is that when GCC
| | configured it, malloc/calloc/realloc behaved in one fashion, but when the user
| | put the binary compiler on his/her system, the system malloc in the shared
| | library now behaves differently.
|
| I admit it may not be worth it, but it can be done without
| complicating the code. Uses of *alloc functions don't change
| at all, and the only ifdefs I added (when I did this for fileutils)
| were in the replacement lib/*alloc.c functions. The m4 tests assume
| *alloc are broken when cross compiling.
While linux gnulibc{1,2} may or may not change the behavior of malloc, I have
witnessed this at OSF, where one revision of OSF/1 had malloc do one behavior
(crash on NULL pointer to realloc or return NULL, I forget which), and the next
revision did another behavior (return unique pointer). I as supplier of
compiler binaries then would have my releases not work, if I built the compiler
on one revision, and had users on the other revision tried to use the
compiler. Depending on a configure test for malloc/realloc behavior is utterly
dangerous for providers of binary software.
--
Michael Meissner, Cygnus Solutions (Massachusetts office)
4th floor, 955 Massachusetts Avenue, Cambridge, MA 02139, USA
meissner@cygnus.com, 617-354-5416 (office), 617-354-7161 (fax)