Re: [rfc] alpha-linux changing to 128-bit long double

Re: [rfc] alpha-linux changing to 128-bit long double

[Ulrich Weigand]

Jakub Jelinek wrote:

>On the other side, Alpha is not the only arch which want long double
>and changing SONAME is really painful.  alpha, sparc32 and ppc*
>are on the same boat.

Same for s390/s390x.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de

Re: [rfc] alpha-linux changing to 128-bit long double

[Richard Henderson]

On Sat, Mar 13, 2004 at 09:08:06AM +0100, Jakub Jelinek wrote:
> On the other side, Alpha is not the only arch which want long double
> and changing SONAME is really painful.

I was noticing this.


> http://sources.redhat.com/ml/libc-hacker/2002-08/msg00102.html
> was my initial attempt to handle this (even including support for
> compilation with 64bit or 128bit long double), it just did not handle
> *printf/*scanf, but I wrote in there how could that be solved.

My thought for handling printf/scanf was to do something like

sysdeps/generic/ldouble-compat.h:
#define DOUBLE_LDOUBLE_SAME_P	(sizeof(double) == sizeof(long double))

sysdeps/alpha/ldouble-compat.h:
extern __thread int __libc_double_ldouble_same;
#define DOUBLE_LDOUBLE_SAME_P	__libc_double_ldouble_same

and then use that like so:

vfscanf.c:
	if (!DOUBLE_LDOUBLE_SAME_P && (flags & LONGDBL))
	  {
	    long double d = ...
	    ...
	  }
	else if (flags & (LONGDBL | LONG))
	  {
	    double d = ...
	    ...
	  }
	else
	  ...

which would even save a teeny bit of code for those targets that
do not plan to change to have different sized doubles.  vfprintf 
is somewhat more complex, since there are at least three places
where we look at va_arg, but otherwise conceptually the same.

The tls variable would get set properly by the actual user-visible
entry points.  That seemed slightly easier than passing this down
as a conditionalized parameter to the internal function.

> I can revive this patch, finish it and it could be then used on
> alpha/sparc32/ppc*.

That would be cool.


r~

Re: [rfc] alpha-linux changing to 128-bit long double

[Jakub Jelinek]

On Sat, Mar 06, 2004 at 09:58:26PM -0800, Richard Henderson wrote:
> So I'm thinking that I'd like to finally get around to changing to
> 128-bit long double for alpha-linux.  I'm undecided how to go about
> doing this though.
> 
> The math routines would be easy to version, but things like printf
> definitely aren't.  Because of that, I was thinking that perhaps
> it might be best to just increment the soname to libc.so.6.2.  Which
> would be a good opportunity to get rid of some awful compatibility
> code in the alpha-linux glibc bits.
> 
> I would be comfortable getting all this done for glibc 2.3.4, and
> just say "use an older release if you don't want this abi change."
> Seems to me the ifdeffery (and worse, makefile ifdeffery) would be
> too awful to considering supporting both modes simultaneously.

On the other side, Alpha is not the only arch which want long double
and changing SONAME is really painful.  alpha, sparc32 and ppc*
are on the same boat.
Compatibility cruft can be easily solved with Ulrich's
attribute_compat_text_section.

http://sources.redhat.com/ml/libc-hacker/2002-08/msg00102.html
was my initial attempt to handle this (even including support for
compilation with 64bit or 128bit long double), it just did not handle
*printf/*scanf, but I wrote in there how could that be solved.

I can revive this patch, finish it and it could be then used on
alpha/sparc32/ppc*.

	Jakub

Re: [rfc] alpha-linux changing to 128-bit long double

[Falk Hueffner]

Richard Henderson <rth@twiddle.net> writes:

> Because of that, I was thinking that perhaps it might be best to
> just increment the soname to libc.so.6.2.
> [...]
> 
> Cc'ed to debian-glibc, since they're the only currently viable alpha
> distribution that I'm aware of.  I see yall are still using glibc
> 2.3.2.  What are debian's plans here wrt the next release (if there's
> ever to be one)?

The last time we changed the libc soname was extremely painful,
because all libraries need recompiling, and we had to mangle the
package name to have dpkg handle this. I'm not convinced 128 bit long
doubles for one architecture are worth this trouble. 

However, we plan to eventually improve dpkg to handle situations like
this since it's needed anyway e. g. for parallel installation of
x86-64 and i386 packages. Hopefully that would make this change
feasible. However that is very unlikely to happen for the next
release.

-- 
	Falk

Re: [rfc] alpha-linux changing to 128-bit long double

[GOTO Masanori]

At Sat, 6 Mar 2004 21:58:26 -0800,
Richard Henderson wrote:
> I would be comfortable getting all this done for glibc 2.3.4, and
> just say "use an older release if you don't want this abi change."
> Seems to me the ifdeffery (and worse, makefile ifdeffery) would be
> too awful to considering supporting both modes simultaneously.
> 
> As for gcc, I suppose I'll have to do something like a different
> configuration name, such as alpha-dec-linux-glibc6.2?  The patches
> to gcc (for any recent version) should be small; the support is
> already present because of Tru64, just have to turn it on.
> 
> Cc'ed to debian-glibc, since they're the only currently viable alpha
> distribution that I'm aware of.  I see yall are still using glibc
> 2.3.2.  What are debian's plans here wrt the next release (if there's
> ever to be one)?

We're no problem of the transition to libc6.2, and we can help you
(ex) build and test various packages using newer libc on alpha.

Unfortunatelly, Debian/sarge (next release) is getting to the final
step, so it's hard to replace libc6.1.  I'm impatient for debian's
current glibc to update its version which is based on the last year
(September) cvs, but it's still time to wait for new release.  So this
transition will be after sarge.

Regards,
-- gotom

Re: [rfc] alpha-linux changing to 128-bit long double

[Ulrich Drepper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Richard Henderson wrote:

> it might be best to just increment the soname to libc.so.6.2.

Certainly the safest method.  I assume there are countless programs
which blindly used long double across all platforms even though alpha
didn't really have it.


> Which
> would be a good opportunity to get rid of some awful compatibility
> code in the alpha-linux glibc bits.

Always welcome.


> I would be comfortable getting all this done for glibc 2.3.4, and
> just say "use an older release if you don't want this abi change."

Seems to be the most efficient way.  Somebody with sufficient need for
the compatibility versions has to plan to invest the time to maintain
appropriate patches on top of the last version before the switch.


> Seems to me the ifdeffery (and worse, makefile ifdeffery) would be
> too awful to considering supporting both modes simultaneously.

Definitely.

- -- 
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFAS6NO2ijCOnn/RHQRAg6MAJ4hAF96eKk/tefIYvGvEuW5n8JfkQCeOorb
RVU7c597dmbgpAwPoikluVk=
=8gKf
-----END PGP SIGNATURE-----

[rfc] alpha-linux changing to 128-bit long double

[Richard Henderson]

So I'm thinking that I'd like to finally get around to changing to
128-bit long double for alpha-linux.  I'm undecided how to go about
doing this though.

The math routines would be easy to version, but things like printf
definitely aren't.  Because of that, I was thinking that perhaps
it might be best to just increment the soname to libc.so.6.2.  Which
would be a good opportunity to get rid of some awful compatibility
code in the alpha-linux glibc bits.

I would be comfortable getting all this done for glibc 2.3.4, and
just say "use an older release if you don't want this abi change."
Seems to me the ifdeffery (and worse, makefile ifdeffery) would be
too awful to considering supporting both modes simultaneously.

As for gcc, I suppose I'll have to do something like a different
configuration name, such as alpha-dec-linux-glibc6.2?  The patches
to gcc (for any recent version) should be small; the support is
already present because of Tru64, just have to turn it on.

Cc'ed to debian-glibc, since they're the only currently viable alpha
distribution that I'm aware of.  I see yall are still using glibc
2.3.2.  What are debian's plans here wrt the next release (if there's
ever to be one)?

Myself, I have been thinking about working on a Fedora Core port for
Alpha, and it would be easiest if I just started out with the new
long double size.


r~