Thanks Joseph,
> On 3 Jan 2023, at 18:15, Joseph Myers <jos...@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
> jos...@codesourcery.com
