gcc compiles assert() to code that requires linking with gcc

[Martin Buchholz]

>>>>> "MvL" == Martin v Loewis <martin@loewis.home.cs.tu-berlin.de> writes:

>> But assert() is more important, because it affects *every* Sparc
>> Solaris machine, while integer multiply affects only (I'm speculating)
>> < 10% of Sparc Solaris machines, and `long long' only affects
>> libraries using non-portable features.

MvL> I believe your speculation is wrong. GCC, in default configuration,
MvL> will produce V7 binaries - independent of what the machine it happens
MvL> to be installed on supports. So dependency on libgcc.a affects the
MvL> majority of gcc sparc installations.

Well, let's see...

(martin@miho) ~/src $ cat mult.c
int mult (int lhs, int rhs) { return lhs * rhs; }
(martin@miho) ~/src $ gcc29 -c -S mult.c
(martin@miho) ~/src $ grep call mult.s
	call	.umul, 0
(martin@miho) ~/src $ nm /lib/libc.a | grep umul | grep FUNC
[7]	|       252|     168|FUNC |GLOB |0    |2      |__umul64
[3]	|         0|     540|FUNC |GLOB |0    |2      |.umul
(martin@miho) ~/src $ uname -a
SunOS miho.m17n.org 5.6 Generic_105181-05 sun4u sparc SUNW,Ultra-5_10

So, yes, you're right, gcc generates calls to .umul (I'm surprised).
(Aside: Sun cc 6.0 generates an smul instruction in this case!)

However, this is not a problem, since .umul is defined in libc.

Further digging (libc(4), libsys(4)) reveals that __assert is defined
in

The System V Application  Binary Interface, Third Edition.

while .umul is defined in

The SPARC Processor  Supplement to the above.

So __assert() is even more standard than .umul.  Because gcc choose to
implement integer multiply using the "standard" functions in libc, there
are no portability problems sharing object code between native cc and
gcc with respect to integer multiply and friends.

When then did gcc not choose to implement assert() in a similar
fashion using __assert(), eliminating problems with object code
sharing in library source that calls assert()??  (as I propose in my
patch http://gcc.gnu.org/ml/gcc-patches/2000-06/msg00886.html )

Again, __assert() is slightly more standard than .umul, although not
ANSI C.

The way integer multiply is handled in gcc is an argument *for*, not
against, my claim that gcc assert() should call __assert() on
platforms where __assert is in libc.

Having done the empirical experiments, I maintain my claim that
assert() is by far the biggest binary library portability problem.

Martin