From: Richard Henderson <rth@redhat.com>
To: Alexandre Oliva <aoliva@redhat.com>
Cc: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>,
gcc-bugs@gcc.gnu.org, gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org,
libstdc++@gcc.gnu.org, oldham@codesourcery.com,
ro@TechFak.Uni-Bielefeld.DE
Subject: Re: Irix6 long doubles implemented wrong? (27_io/ostream_inserter_arith)
Date: Tue, 07 Jan 2003 22:57:00 -0000 [thread overview]
Message-ID: <20030107221549.GR12992@redhat.com> (raw)
In-Reply-To: <orptrn4lr0.fsf@free.redhat.lsd.ic.unicamp.br>
This should have been split into several smaller patches.
On Fri, Dec 27, 2002 at 11:47:15AM -0200, Alexandre Oliva wrote:
> * Makefile.in (FPBIT_FUNCS): Added _sf_to_tf.
> (DBBIT_FUNCS): Added _df_to_tf.
> (TPBIT_FUNCS): New.
> (libgcc.mk): Pass TPBIT and TPBIT_FUNCS down.
> (LIBGCC_DEPS): Added TPBIT.
> * mklibgcc.in: Support TPBIT and TPBIT_FUNCS.
Ok.
> * fp-bit.h: Define macros for TFmode floating-point constants
> in IEEE and IBM-extended TFmode types. Declare functions
> according to L_ macros.
> (TMODES): Define if __LDBL_MANT_DIG__ has one of
> the newly-supported widths.
> (TFtype, TItype, UTItype): Define if TMODES is defined.
> (MAX_UDI_INT, MAX_DI_INT, BITS_PER_DI): Likewise.
> (F_T_BITOFF, D_T_BITOFF): Define.
> (IMPLICIT_1, IMPLICIT_2): Cast constants to types that are
> guaranteed to be wide enough.
> * config/fp-bit.c: Check for L_ macros for tf functions.
> (__thenan_tf): New.
> (nan): Adjust.
> (pack_d, unpack_d): Support IEEE 854 and IBM-extended TFmode
> types.
> (_fpmul_parts): Support TFmode. Compute exponent adjustment
> from FRAC_NBITS, FRAC_BITS and NGARDS.
> (usi_to_float): Cast constants to be shifted to fractype
> instead of assuming long long is wide enough.
> (sf_to_tf, df_to_tf, __make_tp, tf_to_df, tf_to_sf): New.
Ok, I guess.
I'd kinda prefer that we use different names for the routines
than __addtf etc for the IBM format. This would allow the
IBM double-double format and the IEEE quad format routines to
co-exist on one platform, which would allow non-Irix to use a
more sensible format unambiguously.
I won't insist on this though.
> * print-rtl.c (print_rtx): Don't print MEM details in
> GENERATOR_FILEs.
Ok.
> * rtl.c (get_mode_alignment): Moved to...
> * stor-layout.c: ... here.
Ok.
> * calls.c (emit_library_call_value_1): Handle return values
> in a PARALLEL.
Ok. Yet another clue that these routines should be removed,
and replaced with the generic call functions.
> * expr.c (emit_group_store): Initialize dst with CONST0_RTX
> for the appropriate mode.
Ok.
> * optabs.c (expand_binop) <add, sub>: Return xtarget if we haven't
> been able to move the result to target.
Ok, I guess. How does this come up?
> * real.h (struct real_format): Add denorm_p, remove has_denorm.
> * real.c: Adjust all formats and references to has_denorm.
> * c-common.c (builtin_define_float_constants): Use denorm_p to
> define DENORM_MIN.
This one's sticky. Strictly speaking, the double-double format
isn't LIA-1 compliant (too few denormal bits), and so libstdc++
ought to be setting denorm_min to zero. On the other hand, I
can see that this value might still be useful for some people.
Run it by the libstdc++ language lawyers.
r~
next prev parent reply other threads:[~2003-01-07 22:16 UTC|newest]
Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-14 14:09 Kaveh R. Ghazi
2002-12-16 9:24 ` Rainer Orth
2002-12-16 9:51 ` Alexandre Oliva
2002-12-16 9:52 ` Rainer Orth
2002-12-16 12:23 ` Eric Christopher
2002-12-16 21:58 ` Kaveh R. Ghazi
2002-12-21 10:45 ` Alexandre Oliva
2002-12-22 6:02 ` Kaveh R. Ghazi
2002-12-22 10:24 ` Alexandre Oliva
2002-12-22 10:35 ` Alexandre Oliva
2002-12-23 9:46 ` Alexandre Oliva
2002-12-24 11:07 ` Kaveh R. Ghazi
2002-12-25 8:04 ` Alexandre Oliva
2002-12-26 13:48 ` Alexandre Oliva
2002-12-27 7:06 ` Alexandre Oliva
2002-12-29 0:22 ` Kaveh R. Ghazi
2002-12-29 6:06 ` Alexandre Oliva
2003-01-07 22:57 ` Richard Henderson [this message]
2003-01-08 18:16 ` Alexandre Oliva
2003-01-08 22:19 ` Richard Henderson
2003-01-09 9:29 ` Alexandre Oliva
2003-01-09 9:38 ` Alexandre Oliva
2003-01-10 1:18 ` Alexandre Oliva
2003-01-10 2:29 ` Richard Henderson
2003-01-19 21:02 ` Kaveh R. Ghazi
2003-01-19 22:15 ` Alexandre Oliva
2003-01-26 13:00 ` Alexandre Oliva
2003-01-28 17:32 ` Alexandre Oliva
2003-01-28 23:38 ` Alexandre Oliva
2003-01-26 15:20 ` Alexandre Oliva
2003-01-26 16:14 ` Alexandre Oliva
2003-01-26 18:40 ` Kaveh R. Ghazi
2003-01-26 21:24 ` Kaveh R. Ghazi
2003-01-26 21:25 ` Alexandre Oliva
2003-01-27 9:17 ` Kaveh R. Ghazi
2003-01-27 10:40 ` Alexandre Oliva
2003-01-28 4:52 ` Kaveh R. Ghazi
2003-01-28 17:31 ` Alexandre Oliva
2003-01-28 19:11 ` Kaveh R. Ghazi
2003-01-28 19:23 ` Kaveh R. Ghazi
2003-01-28 19:47 ` Rainer Orth
[not found] ` <15926.49701.3! 59482.666471@xayide.TechFak.Uni-Bielefeld.DE>
2003-01-29 6:56 ` Kaveh R. Ghazi
2003-01-29 10:07 ` Richard Henderson
2003-01-29 13:39 ` Alexandre Oliva
2003-01-29 17:26 ` Kaveh R. Ghazi
2003-01-29 18:10 ` Richard Henderson
2003-01-30 23:31 ` Irix6 native long double libcalls progress report (and problem) Kaveh R. Ghazi
2003-01-30 23:49 ` Richard Henderson
2003-02-03 13:22 ` Alexandre Oliva
2003-01-30 8:05 ` Irix6 long doubles implemented wrong? (27_io/ostream_inserter_arith) Kaveh R. Ghazi
2003-02-03 13:07 ` Alexandre Oliva
2003-02-03 15:18 ` Kaveh R. Ghazi
2003-02-03 16:37 ` Alexandre Oliva
2003-01-27 10:41 ` Alexandre Oliva
2003-01-26 21:54 ` Richard Henderson
2003-01-10 1:37 ` Alexandre Oliva
2003-01-26 10:07 ` Alexandre Oliva
2003-01-26 10:42 ` Alexandre Oliva
2003-01-26 10:45 ` Alexandre Oliva
2003-01-26 10:53 ` Alexandre Oliva
2003-01-26 12:07 ` Alexandre Oliva
2003-01-26 12:20 ` Alexandre Oliva
2003-01-26 12:50 ` Alexandre Oliva
2002-12-24 18:15 ` Kaveh R. Ghazi
2003-01-07 22:16 ` Richard Henderson
2003-01-07 22:40 ` Richard Henderson
2003-01-08 18:04 ` Alexandre Oliva
2003-01-08 22:29 ` Richard Henderson
2003-01-08 22:46 ` Zack Weinberg
2003-01-08 23:13 ` Richard Henderson
2003-01-09 7:27 ` Alexandre Oliva
2002-12-17 0:18 Billinghurst, David (CRTS)
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=20030107221549.GR12992@redhat.com \
--to=rth@redhat.com \
--cc=aoliva@redhat.com \
--cc=gcc-bugs@gcc.gnu.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=gcc@gcc.gnu.org \
--cc=ghazi@caip.rutgers.edu \
--cc=libstdc++@gcc.gnu.org \
--cc=oldham@codesourcery.com \
--cc=ro@TechFak.Uni-Bielefeld.DE \
/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).