As mentioned in a recent post, I changed from a 2015 GNAT on Mac Intel to 2022 compiler on Mac ARM.

I don't know if this is of interest but I am now getting a compiler error that I never got before. It is in the Ada bindings to MPFR https://www.mpfr.org/. The problematic code is in this SVN checkout that I have never laid eyes on but which worked well in the past, certainly without compiler errors..

The error that I am now getting is

mpfr-floats.adb:788:27: error: duplication of choice value: 15 at line 787

Here are lines around the referenced lines from that file. The first line (function...) is numbered 783.

function Generic_Round (X : MPFR_Float) return F
is begin
case F'Base'Digits is
when Float'Digits => return F(mpfr_get_flt(X.Value, default_rounding_mode));
when Long_Float'Digits => return F(mpfr_get_d (X.Value, default_rounding_mode));
when Long_Long_Float'Digits => return F(mpfr_get_ld (X.Value, default_rounding_mode));
when others => raise Constraint_Error;
end case;
end Generic_Round;

When I comment out line 788 the error does not appear. I have not used this binding for a long time and have not tested it today so I don't know the effect of this modification. The file is several years old and I don't know if the current code base for the bindings is the same--my concern here is the new Ada compiler complaint.

Jerry

On 2022-12-06 12:13, Jerry wrote:
> As mentioned in a recent post, I changed from a 2015 GNAT on Mac Intel to 2022 compiler on Mac ARM.
>
> I don't know if this is of interest but I am now getting a compiler error that I never got before. It is in the Ada bindings to MPFR https://www.mpfr.org/. The problematic code is in this SVN checkout that I have never laid eyes on but which worked well in the past, certainly without compiler errors.
>
> The error that I am now getting is
>
> mpfr-floats.adb:788:27: error: duplication of choice value: 15 at line 787
>
> Here are lines around the referenced lines from that file. The first line (function...) is numbered 783.
>
> function Generic_Round (X : MPFR_Float) return F
> is begin
> case F'Base'Digits is
> when Float'Digits => return F(mpfr_get_flt(X.Value, default_rounding_mode));
> when Long_Float'Digits => return F(mpfr_get_d (X.Value, default_rounding_mode));
> when Long_Long_Float'Digits => eturn F(mpfr_get_ld (X.Value, default_rounding_mode));
> when others => raise Constraint_Error;
> end case;
> end Generic_Round;
>
> When I comment out line 788 the error does not appear. I have not used this binding for a long time and have not tested it today so I don't know the effect of this modification. The file is several years old and I don't know if the current code base for the bindings is the same--my concern here is the new Ada compiler complaint.

Looks like Long_Long_Float has at least same mantissa as Long_Float.
What are the actual values of Long_Float'Digits and Long_Long_Float'Digits?

Anyway it is all permitted:

ARM 3.5.7(16):

"An implementation is allowed to provide additional predefined floating
point types, declared in the visible part of Standard, whose
(unconstrained) first subtypes have names of the form Short_Float,
Long_Float, Short_Short_Float, Long_Long_Float, etc. Different
predefined floating point types are allowed to have the same base
decimal precision. However, the precision of Float should be no greater
than that of Long_Float. Similarly, the precision of Short_Float (if
provided) should be no greater than Float. Corresponding recommendations
apply to any other predefined floating point types. There need not be a
named floating point type corresponding to each distinct base decimal
precision supported by an implementation."

But bindings look very strange to me:

1. Long_Long_Float may not exist at all.
2. When dealing with a C library, use C types defined in Interfaces.C!

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> Looks like Long_Long_Float has at least same mantissa as
> Long_Float. What are the actual values of Long_Float'Digits and
> Long_Long_Float'Digits?

You can get a listing of package Standard by compiling with -gnatS.

On aarch64, with the aarch64 compiler,

type Short_Float is digits 6
range -16#0.FFFF_FF#E32 .. 16#0.FFFF_FF#E32;
for Short_Float'Size use 32;

type Float is digits 6
range -16#0.FFFF_FF#E32 .. 16#0.FFFF_FF#E32;
for Float'Size use 32;

type Long_Float is digits 15
range -16#0.FFFF_FFFF_FFFF_F8#E256 .. 16#0.FFFF_FFFF_FFFF_F8#E256;
for Long_Float'Size use 64;

type Long_Long_Float is digits 15
range -16#0.FFFF_FFFF_FFFF_F8#E256 .. 16#0.FFFF_FFFF_FFFF_F8#E256;
for Long_Long_Float'Size use 64;

With the x86_64 compiler,

type Short_Float is digits 6
range -16#0.FFFF_FF#E32 .. 16#0.FFFF_FF#E32;
for Short_Float'Size use 32;

type Float is digits 6
range -16#0.FFFF_FF#E32 .. 16#0.FFFF_FF#E32;
for Float'Size use 32;

type Long_Float is digits 15
range -16#0.FFFF_FFFF_FFFF_F8#E256 .. 16#0.FFFF_FFFF_FFFF_F8#E256;
for Long_Float'Size use 64;

type Long_Long_Float is digits 18
range -16#0.FFFF_FFFF_FFFF_FFFF#E4096 .. 16#0.FFFF_FFFF_FFFF_FFFF#E4096;
for Long_Long_Float'Size use 128;

Don't forget that on aarch64, x86_64 code is 'emulated' by Rosetta.

So the correctness of an Ada program can depend on the processor that it runs on?

Jerry

On 2022-12-08 05:07, Jerry wrote:
> So the correctness of an Ada program can depend on the processor that it runs on?

If you make legality of your program dependent on the attribute of
*machine* types what else do you expect?

(The program, you presented, is IMO poorly written and incorrect)

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 2022-12-08 05:07, Jerry wrote:
> So the correctness of an Ada program can depend on the processor that it runs on?

The code you presented is compiler-dependent. It cannot be presumed to be
portable to another compiler, or even (as you discovered) to another version of
the same compiler.

--
Jeff Carter
“[T]here are lots of people out there writing software
that should really be out cleaning toilets instead.”
Brian Catlin
173

On 08.12.22 05:07, Jerry wrote:
> So the correctness of an Ada program can depend on the processor that it runs on?

The correctness of the Ada program will depend
on the correctness of its assumptions ;-)

declare
Freezing_Cold : constant Integer :=
Integer'Last / 1_000;
begin
Put ("Water freezes at ");
Put (Freezing_Cold, Width => 2);
Put (" degrees Fahrenheit");
end;

The case statement of the program shown in your message
features a technique (of the few that are available to
the C programmer) for testing properties of an implementation
of C, at compile time.

Software configuration for the target platform can remove
the need for this kind of case distinction. Source text
will be restricted to normal program logic.

This might be a little more portable if it was written using if .. elsif
... etc