From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on ip-172-31-65-14.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 Path: eternal-september.org!reader01.eternal-september.org!aioe.org!jsz7MSurcLFfjpj9fQtAZA.user.46.165.242.91.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: New compiler error with new compiler Date: Tue, 6 Dec 2022 12:36:41 +0100 Organization: Aioe.org NNTP Server Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: gioia.aioe.org; logging-data="54087"; posting-host="jsz7MSurcLFfjpj9fQtAZA.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org"; User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.5.1 X-Notice: Filtered by postfilter v. 0.9.2 Content-Language: en-US Xref: reader01.eternal-september.org comp.lang.ada:64676 List-Id: 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