1. Forum
  2. Usenet
  3. COMP.LANG.ADA

  • New compiler error with new compiler

    From Jerry@21:1/5 to All on Tue Dec 6 03:13:48 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dmitry A. Kazakov@21:1/5 to Jerry on Tue Dec 6 12:36:41 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simon Wright@21:1/5 to Dmitry A. Kazakov on Tue Dec 6 13:32:27 2022
    "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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jerry@21:1/5 to All on Wed Dec 7 20:07:07 2022
    So the correctness of an Ada program can depend on the processor that it runs on?

    Jerry

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dmitry A. Kazakov@21:1/5 to Jerry on Thu Dec 8 09:15:00 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jeffrey R.Carter@21:1/5 to Jerry on Thu Dec 8 11:29:29 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From G.B.@21:1/5 to Jerry on Thu Dec 8 21:30:12 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simon Wright@21:1/5 to All on Thu Dec 8 20:37:18 2022
    This might be a little more portable if it was written using if .. elsif
    .. etc

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)