Re: another baby step - namespace adjustments

["Zack Weinberg" <zack at codesourcery dot com>]

DJ Delorie <dj@redhat.com> writes:

>> It's not that it's not portable enough, it's that jumping through the
>> necessary hoops to link cc1 against libm.so when and only when this is
>> required is too much trouble.

Just for the record, I did some experiements to find out just how hard
this would be - and it's a doozy, because on some systems (e.g. i386
with glibc) sqrt() is an inline function in math.h, but only when
optimizing.  autoconf does its probe with optimization on, finds no
need for libm, and then we blow up trying to link stage1 cc1 which was
built with optimization off.

> 1. Provide a standard function that is missing on some platforms.
> 2. Provide a standard function that is broken on some platforms.
> 3. Provide a function that is widely used by many gnu projects.
> 4. Provide a common function that is difficult to implement portably.
>
> Given that there is a standard function that nearly all platforms
> provide in a standard library, I find it difficult to justify adding a
> non-standard semi-compatible replacement to libiberty for it.

I hear your concerns.  I have an alternate plan now: I will copy
e_sqrt.c from glibc into libiberty (with suitable modifications to
make it standalone).  This file will provide the function sqrt().  It
will be compiled into libiberty unconditionally.  However, I will not
put any prototype into libiberty.h; you'll have to include math.h to
get it.  This should allow the system library to provide an optimized
inline sqrt when available, but still give an adequate fallback that
doesn't require linking with libm.

Does this plan work for you?


Phil Edwards <phil@jaj.com> writes:
> What if it just gets moved into its own gcc/sqrt_approx.c file?  Would that
> fulfill the original goals?

No, it wouldn't, because the code that uses it (hashtable.c) is
going to be moved out of the gcc directory, and it might be useful to
have similar statistics in some of the other abstract data structures
provided by libiberty.

Jim Wilson <wilson@tuliptree.org> writes:

> Why not just always link with libm?
>
> I think we should fix gcc to always link with libm on targets that
> have one.  It is a historical accident that -lm is optional.  Now that
> ISO C requires a sqrt to exist, it is silly to require users to
> specify yet another option (-lm) in order to compile valid ISO C
> programs.  This would also eliminate some of the bug reports we get.

This is a fine idea, as long as it's done only when necessary, but
would not help build gcc itself.

zw