comp.lang.ada
 help / color / mirror / Atom feed
* New compiler error with new compiler
@ 2022-12-06 11:13 Jerry
  2022-12-06 11:36 ` Dmitry A. Kazakov
  2022-12-08 20:37 ` Simon Wright
  0 siblings, 2 replies; 8+ messages in thread
From: Jerry @ 2022-12-06 11:13 UTC (permalink / raw)


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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: New compiler error with new compiler
  2022-12-06 11:13 New compiler error with new compiler Jerry
@ 2022-12-06 11:36 ` Dmitry A. Kazakov
  2022-12-06 13:32   ` Simon Wright
  2022-12-08 20:37 ` Simon Wright
  1 sibling, 1 reply; 8+ messages in thread
From: Dmitry A. Kazakov @ 2022-12-06 11:36 UTC (permalink / raw)


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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: New compiler error with new compiler
  2022-12-06 11:36 ` Dmitry A. Kazakov
@ 2022-12-06 13:32   ` Simon Wright
  2022-12-08  4:07     ` Jerry
  0 siblings, 1 reply; 8+ messages in thread
From: Simon Wright @ 2022-12-06 13:32 UTC (permalink / raw)


"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.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: New compiler error with new compiler
  2022-12-06 13:32   ` Simon Wright
@ 2022-12-08  4:07     ` Jerry
  2022-12-08  8:15       ` Dmitry A. Kazakov
                         ` (2 more replies)
  0 siblings, 3 replies; 8+ messages in thread
From: Jerry @ 2022-12-08  4:07 UTC (permalink / raw)


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

Jerry

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: New compiler error with new compiler
  2022-12-08  4:07     ` Jerry
@ 2022-12-08  8:15       ` Dmitry A. Kazakov
  2022-12-08 10:29       ` Jeffrey R.Carter
  2022-12-08 20:30       ` G.B.
  2 siblings, 0 replies; 8+ messages in thread
From: Dmitry A. Kazakov @ 2022-12-08  8:15 UTC (permalink / raw)


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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: New compiler error with new compiler
  2022-12-08  4:07     ` Jerry
  2022-12-08  8:15       ` Dmitry A. Kazakov
@ 2022-12-08 10:29       ` Jeffrey R.Carter
  2022-12-08 20:30       ` G.B.
  2 siblings, 0 replies; 8+ messages in thread
From: Jeffrey R.Carter @ 2022-12-08 10:29 UTC (permalink / raw)


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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: New compiler error with new compiler
  2022-12-08  4:07     ` Jerry
  2022-12-08  8:15       ` Dmitry A. Kazakov
  2022-12-08 10:29       ` Jeffrey R.Carter
@ 2022-12-08 20:30       ` G.B.
  2 siblings, 0 replies; 8+ messages in thread
From: G.B. @ 2022-12-08 20:30 UTC (permalink / raw)


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.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: New compiler error with new compiler
  2022-12-06 11:13 New compiler error with new compiler Jerry
  2022-12-06 11:36 ` Dmitry A. Kazakov
@ 2022-12-08 20:37 ` Simon Wright
  1 sibling, 0 replies; 8+ messages in thread
From: Simon Wright @ 2022-12-08 20:37 UTC (permalink / raw)


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

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2022-12-08 20:37 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-12-06 11:13 New compiler error with new compiler Jerry
2022-12-06 11:36 ` Dmitry A. Kazakov
2022-12-06 13:32   ` Simon Wright
2022-12-08  4:07     ` Jerry
2022-12-08  8:15       ` Dmitry A. Kazakov
2022-12-08 10:29       ` Jeffrey R.Carter
2022-12-08 20:30       ` G.B.
2022-12-08 20:37 ` Simon Wright

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox