public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Henderson <rth@twiddle.net>
To: Jakub Jelinek <jakub@redhat.com>
Cc: libc-alpha@sources.redhat.com, gcc@gcc.gnu.org,
	debian-glibc@lists.debian.org
Subject: Re: [rfc] alpha-linux changing to 128-bit long double
Date: Sun, 14 Mar 2004 01:58:00 -0000	[thread overview]
Message-ID: <20040314015821.GA19652@twiddle.net> (raw)
In-Reply-To: <20040313080806.GM3822@sunsite.ms.mff.cuni.cz>

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~

  reply	other threads:[~2004-03-14  1:58 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-07  5:58 Richard Henderson
2004-03-07 22:34 ` Ulrich Drepper
2004-03-08  1:28 ` GOTO Masanori
2004-03-09 18:38 ` Falk Hueffner
2004-03-13 10:17 ` Jakub Jelinek
2004-03-14  1:58   ` Richard Henderson [this message]
2004-03-13 16:36 Ulrich Weigand

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040314015821.GA19652@twiddle.net \
    --to=rth@twiddle.net \
    --cc=debian-glibc@lists.debian.org \
    --cc=gcc@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=libc-alpha@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).