public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Iain Sandoe <iain@sandoe.co.uk>
To: Joseph Myers <joseph@codesourcery.com>,
	Gaius Mulley <gaiusmod2@gmail.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>,
	"<ro@cebitec.uni-bielefeld.de>" <ro@CeBiTec.Uni-Bielefeld.DE>
Subject: Re: [PATCH] Darwin, crts: Provide scalb and significand as a crt [PR107631]
Date: Tue, 3 Jan 2023 20:07:41 +0000	[thread overview]
Message-ID: <77D8A0F8-2831-4A24-AF23-D39511BDC89E@sandoe.co.uk> (raw)
In-Reply-To: <44a1c1e5-c1b0-604c-aca5-bc42d93ee5ba@codesourcery.com>

Thanks Joseph,

> On 3 Jan 2023, at 18:15, Joseph Myers <joseph@codesourcery.com> wrote:
> 
> On Sat, 31 Dec 2022, Iain Sandoe wrote:
> 
>> builtins.def unconditionally defines these builtins to be DEF_EXT_LIB_BUILTIN
>> which expands to the libcall, this is currently hard-wired to FALLBACK_P = true.
>> 
>> but, AFAIU the builtins.def descriptions:
>> 
>> FALLBACK_P should be false if the libc (or libm, I suppose, if that’s different)
>> does not have the function, perhaps that’s an underlying bug or at least an
>> oversight?
>> 
>> (or, of course, I misunderstood the intent of that param)
> 
> FALLBACK_P true means that it's the user's responsibility, if calling 
> __builtin_X, to make sure the library function X is also available in 
> cases where the call doesn't get expected inline - that is, that the API 
> for that __builtin_X function is that it may call an underlying library 
> function X, which is expected to exist and have a compatible interface.
> 
> Information about whether a function is present in libc / libm is 
> generally only relevant when __builtin_X might expand to call Y instead of 
> X; then GCC needs to know whether Y is available.

Ah I had misunderstood the param.

Since the mechanism used by Modula-2 ‘forwards’ the builins by using them,
that means that it always produces the libcalls which results in link errors when
the m2 libraries are used (i.e. the user is not in control of the use/non-use).

>> - at present, it seems that this crt might be the least invasive 
>> solution (since ‘significand*()’ are not obsolete AFAIU, we still need 
>> to provide those implementations, regardless of any subsitution of 
>> scalbn*() in Modula-2).
> 
> The significand functions can be considered obsolete and were never in any 
> standard (thus glibc does not provide a version for _Float128, for 
> example).

So,  it seems that either:

 1. Modula-2 should not forward the builtins unless the target supports them,
    either by expansion or the relevant lib functions.  So that would need some
   configury and conditional build code.

 2. Preferrably it should not forward the obsolete/obsolescent cases:
       scalb*()
       significand*()

Additionally, if there is an actual use in the Modula-2 runtime (as opposed to
forwarding the functionality to the end user), then it should implement that avoiding
these obsolete functions.

I will withdraw my Darwin patch, and discuss with Gaius how to resolve this in
Modula-2.

thanks
Iain


> 
> -- 
> Joseph S. Myers
> joseph@codesourcery.com


  reply	other threads:[~2023-01-03 20:07 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-30 10:20 Iain Sandoe
2022-12-30 22:26 ` Joseph Myers
2022-12-31 12:12   ` Iain Sandoe
2023-01-03 18:15     ` Joseph Myers
2023-01-03 20:07       ` Iain Sandoe [this message]
2023-01-03 21:34         ` Joseph Myers

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=77D8A0F8-2831-4A24-AF23-D39511BDC89E@sandoe.co.uk \
    --to=iain@sandoe.co.uk \
    --cc=gaiusmod2@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=joseph@codesourcery.com \
    --cc=ro@CeBiTec.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).