public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Segher Boessenkool <segher@kernel.crashing.org>
Cc: Michael Meissner <meissner@linux.ibm.com>,
	gcc-patches@gcc.gnu.org, David Edelsohn <dje.gcc@gmail.com>,
	Bill Schmidt <wschmidt@linux.ibm.com>,
	Peter Bergner <bergner@linux.ibm.com>
Subject: Re: [PATCH] PowerPC Fix ibm128 defaults for pr70117.c test.
Date: Mon, 23 Nov 2020 20:10:49 +0100	[thread overview]
Message-ID: <20201123191049.GG3788@tucnak> (raw)
In-Reply-To: <20201123185929.GH2672@gate.crashing.org>

On Mon, Nov 23, 2020 at 12:59:29PM -0600, Segher Boessenkool wrote:
> On Sat, Nov 21, 2020 at 12:27:30AM -0500, Michael Meissner wrote:
> > On Thu, Nov 19, 2020 at 08:03:02AM -0600, Segher Boessenkool wrote:
> > > Sure -- I am suggesting to always define __IBM128_MAX__ and the like,
> > > which then can be used to define LDBL_MAX, but also can be used
> > > directly.
> > 
> > I have posted patches for this as a new set of patches.  Rather than trying to
> > create IBM 128-bit long double min/max/etc. defines, I just marked the test as
> > needing IBM 128-bit long double.
> > 
> > I did look into providing defines for these.  Unfortunately the function that
> > creates these (builtin_define_float_constants) is static.  And the caller of
> > that function (c_cpp_builtins) does not have a target hook or other method to
> > provide for these defines for MD specific floating point types.
> 
> So create the defines from somewhere in the backend, instead?  This
> isn't rocket science.
> 
> You can even leave the existing LDBL defines alone if you just override
> them later.

The current defines are quite complex code, because defining them is very
expensive and we don't want to pay that price at every compilation start
when most of the compilations never use those macros.
So they are magic deferred macros.

	Jakub


  reply	other threads:[~2020-11-23 19:10 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-15 17:17 Michael Meissner
2020-11-18  5:34 ` will schmidt
2020-11-18 21:43 ` Segher Boessenkool
2020-11-18 21:53   ` Jakub Jelinek
2020-11-18 22:29     ` Segher Boessenkool
2020-11-19  1:13       ` Paul A. Clarke
2020-11-19 14:08         ` Segher Boessenkool
2020-11-19  8:08       ` Michael Meissner
2020-11-19 14:03         ` Segher Boessenkool
2020-11-21  5:27           ` Michael Meissner
2020-11-23 18:59             ` Segher Boessenkool
2020-11-23 19:10               ` Jakub Jelinek [this message]
2020-11-23 20:13                 ` Segher Boessenkool

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=20201123191049.GG3788@tucnak \
    --to=jakub@redhat.com \
    --cc=bergner@linux.ibm.com \
    --cc=dje.gcc@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=meissner@linux.ibm.com \
    --cc=segher@kernel.crashing.org \
    --cc=wschmidt@linux.ibm.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).