public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
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~

  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).