On Jan 21, 2021, Sebastian Huber wrote:
> Which target properties determine that a-nallfl__wraplf.ads should be
> used?
The question really is what makes the default a-nallfl.ads unusable for
a target. It works when the Ada type Long_Long_Float and the C long
double type are nop-convertible.
Hello Alexandre,
On 13/01/2021 19:40, Alexandre Oliva wrote:
Would you like to take a stab at it yourself, or should I?
I can try to figure out a patch, but I have to guess how it works.
What's needed is adding
LIBGNAT_TARGET_PAIRS += \
a-nallfl.adsI have this issue also for AArch64.
On Jan 13, 2021, Sebastian Huber wrote:
> This is probably not RTEMS-specific. I guess it is a general riscv issue.
You're right, but the riscv*-linux-gnu configuration already has the
fix.
>> Would you like to take a stab at it yourself, or should I?
> I can try to figure out a patch, but I
On 13/01/2021 17:45, Alexandre Oliva wrote:
Hello, Sebastian,
On Jan 13, 2021, Sebastian Huber wrote:
I have a similar issue on riscv-rtems*:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98595
Can this be fixed also with a patch to gcc/ada/Makefile.rtl?
Yeah, that's definitely the way to
Hello, Sebastian,
On Jan 13, 2021, Sebastian Huber wrote:
> I have a similar issue on riscv-rtems*:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98595
> Can this be fixed also with a patch to gcc/ada/Makefile.rtl?
Yeah, that's definitely the way to go.
I'm afraid the fix will be a little
Hello Alexandre,
On 19/10/2020 13:52, Alexandre Oliva wrote:
On Oct 19, 2020, Andreas Schwab wrote:
-nostdinc a-nallfl.ads -o a-nallfl.o
a-nallfl.ads:48:13: warning: intrinsic binding type mismatch on return value
a-nallfl.ads:48:13: warning: intrinsic binding type mismatch on argument 1
On October 23, 2020 4:23:35 PM GMT+02:00, Alexandre Oliva
wrote:
>On Oct 22, 2020, Alexandre Oliva wrote:
>
>> On Oct 18, 2020, Alexandre Oliva wrote:
>>> The option is provided by default, but there is an alternate version
>>> that doesn't, that is used for vxworks targets.
>
>> vxworks float
On Oct 22, 2020, Alexandre Oliva wrote:
> On Oct 18, 2020, Alexandre Oliva wrote:
>> The option is provided by default, but there is an alternate version
>> that doesn't, that is used for vxworks targets.
> vxworks float EFs not precise enough -> use long float
> From: Alexandre Oliva
>
On Oct 22, 2020, Eric Botcazou wrote:
>> So I'm going ahead and checking this in, approved by Eric Botcazou.
>> (Rainer's followup patch is coming up separately but momentarily)
>>
>>
>> aarch64-* and ppc*-linux-gnu long long float/long double mismatch
> Does this fix
Rainer Orth wrote:
> Hi Alexandre,
>
>> On Oct 19, 2020, Andreas Schwab wrote:
>>
>>> -nostdinc a-nallfl.ads -o a-nallfl.o
>>> a-nallfl.ads:48:13: warning: intrinsic binding type mismatch on return value
>>> a-nallfl.ads:48:13: warning: intrinsic binding type mismatch on argument 1
>>>
> So I'm going ahead and checking this in, approved by Eric Botcazou.
> (Rainer's followup patch is coming up separately but momentarily)
>
>
> aarch64-* and ppc*-linux-gnu long long float/long double mismatch
Does this fix https://gcc.gnu.org/PR97504 for PowerPC64? Note that S/390 is
On Oct 22, 2020, Alexandre Oliva wrote:
> (some regressions remain on x86 and x86_64,
> so further changes are expected
Here's the fix I'm installing. I'd failed to add the __nolibm bit to
x86*-vxworks in the Ada.Numerics.Aux revamp patch. Then, when I added
__wraplf for low-precision real
On Oct 18, 2020, Alexandre Oliva wrote:
> The Aux_Short_Float unit is implemented in terms of the Aux_Float one,
> and the others rely on the elementary functions from the C Math
> library for float, double and long double types, respectively.
Use Aux_Long_Float for all real types on LynxOS
On Oct 18, 2020, Alexandre Oliva wrote:
> The option is provided by default, but there is an alternate version
> that doesn't, that is used for vxworks targets.
vxworks float EFs not precise enough -> use long float
From: Alexandre Oliva
Some acats-4 tests that check the precision of Float
On Oct 20, 2020, Rainer Orth wrote:
> your patch similarly broke sparc*-sun-solaris* bootstrap. The attached
> snippet on top of this workaround fixes that.
Thanks, here's what I'm installing, approved by me with my build
machinery maintainer hat on ;-)
Use Aux_Long_Long_Float wraplf for
On Oct 19, 2020, Alexandre Oliva wrote:
> Hello, Andreas,
> On Oct 19, 2020, Andreas Schwab wrote:
>> -nostdinc a-nallfl.ads -o a-nallfl.o
>> a-nallfl.ads:48:13: warning: intrinsic binding type mismatch on return value
>> a-nallfl.ads:48:13: warning: intrinsic binding type mismatch on argument
Hi Alexandre,
> On Oct 19, 2020, Andreas Schwab wrote:
>
>> -nostdinc a-nallfl.ads -o a-nallfl.o
>> a-nallfl.ads:48:13: warning: intrinsic binding type mismatch on return value
>> a-nallfl.ads:48:13: warning: intrinsic binding type mismatch on argument 1
>> a-nallfl.ads:48:13: warning: profile
Hello, Andreas,
On Oct 19, 2020, Andreas Schwab wrote:
> -nostdinc a-nallfl.ads -o a-nallfl.o
> a-nallfl.ads:48:13: warning: intrinsic binding type mismatch on return value
> a-nallfl.ads:48:13: warning: intrinsic binding type mismatch on argument 1
> a-nallfl.ads:48:13: warning: profile of
/opt/gcc/gcc-20201019/Build/./gcc/xgcc -B/opt/gcc/gcc-20201019/Build/./gcc/
-B/usr/aarch64-suse-linux/bin/ -B/usr/aarch64-suse-linux/lib/ -isystem
/usr/aarch64-suse-linux/include -isystem /usr/aarch64-suse-linux/sys-include
-c -g -O2 -fPIC -W -Wall -gnatpg -nostdinc a-nallfl.ads -o
Instead of mapping elementary functions for all types to a single
type, use the intrinsics available for the various base types.
A new Ada.Numerics.Aux_Generic_Float is introduced to explicitly
dispatch, based on the 'Digits attribute of the base type, to the
various newly-added
20 matches
Mail list logo
