Hi,
> Running
> nohup make -j7 check-fortran
> RUNTESTFLAGS="--target_board=unix/-mabi=ieeelongdouble/-mcpu=power9"&
> from the gcc subdirectory yielded only a single failure:
I dug more into the code and I understand why all tests are running: since
db630423a97ec6690a8eb0e5c3cb186c91e3740d and
Hi FX,
>> The KIND=17 is a bit of a kludge. It is not visible for
>> user programs, they use KIND=16, but this is then translated
>> to library calls as if it was KIND=17 if the IEEE 128-bit floats
>> are selected
>
> Can you check what the IEEE test results are when
-mabi=ieeelongdouble is ena
Given the agreement that the patch is not making things for powerpc worse, and
the review by Steve, I have committed as
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=17bccd1d2c0fa1f08e0483c8ed841994a95febb0
Best,
FX
Hi Thomas,
> The KIND=17 is a bit of a kludge. It is not visible for
> user programs, they use KIND=16, but this is then translated
> to library calls as if it was KIND=17 if the IEEE 128-bit floats
> are selected
Can you check what the IEEE test results are when -mabi=ieeelongdouble is
enabled
Hi Steve,
On Thu, Jun 08, 2023 at 12:17:02PM +0200, Thomas Koenig wrote:
[...]
Thanks for the explanation. As I likely will not use a POWER-based
system, I only loosely followed the discussion. I don't remember
if ibm double-double is REAL(16) or REAL(17). If ieee 128-bit is
REAL(16), then
On Thu, Jun 08, 2023 at 12:17:02PM +0200, Thomas Koenig wrote:
> Hi together,
>
> > > On 6/6/23 21:11, FX Coudert via Gcc-patches wrote:
> > > > Hi,
> > > >
> > > > > I cannot see if there is proper support for kind=17 in your patch;
> > > > > at least the libgfortran/ieee/ieee_arithmetic.F90 par
Hi FX,
Having a POWER system isn't enough, it also needs the IBM "advance
toolchain", and (at least with current distros, which default to
ibm long double), you need to dance counterclockwise three
times... I mean you need to invoke configure with some special magic
Thanks for the frank descri
> Having a POWER system isn't enough, it also needs the IBM "advance
> toolchain", and (at least with current distros, which default to
> ibm long double), you need to dance counterclockwise three
> times... I mean you need to invoke configure with some special magic
Thanks for the frank descripti
Hi together,
On 6/6/23 21:11, FX Coudert via Gcc-patches wrote:
Hi,
I cannot see if there is proper support for kind=17 in your patch;
at least the libgfortran/ieee/ieee_arithmetic.F90 part does not
seem to have any related code.
Can real(kind=17) ever be an IEEE mode? If so, something seri
On Wed, Jun 07, 2023 at 08:31:35PM +0200, Harald Anlauf via Fortran wrote:
> Hi FX,
>
> On 6/6/23 21:11, FX Coudert via Gcc-patches wrote:
> > Hi,
> >
> > > I cannot see if there is proper support for kind=17 in your patch;
> > > at least the libgfortran/ieee/ieee_arithmetic.F90 part does not
> >
Hi FX,
On 6/6/23 21:11, FX Coudert via Gcc-patches wrote:
Hi,
I cannot see if there is proper support for kind=17 in your patch;
at least the libgfortran/ieee/ieee_arithmetic.F90 part does not
seem to have any related code.
Can real(kind=17) ever be an IEEE mode? If so, something seriously w
On Tue, Jun 06, 2023 at 09:35:26PM +0200, FX Coudert wrote:
> Hi Steve,
>
> I am not subscribed to the list (too little time, sadly), please keep me in
> CC of your responses.
>
Unfortunately, fx is using a gmail account. Emails from my
system to @gmail.com users are routinely and silently rej
Hi Steve,
I am not subscribed to the list (too little time, sadly), please keep me in CC
of your responses.
> 1. You added fmin, fmax, and friends. Are these used
>internally by gfortran in support of the IEEE_*
>functions or are these exposed to the user?
The math builtins are added
Hi,
> I cannot see if there is proper support for kind=17 in your patch;
> at least the libgfortran/ieee/ieee_arithmetic.F90 part does not
> seem to have any related code.
Can real(kind=17) ever be an IEEE mode? If so, something seriously wrong
happened, because the IEEE modules have no kind=17
Hi FX,
On 6/6/23 15:19, FX via Gcc-patches wrote:
Hi,
This patch adds four IEEE functions from the Fortran 2018 standard:
IEEE_MIN_NUM, IEEE_MAX_NUM, IEEE_MIN_NUM_MAG, and IEEE_MAX_NUM_MAG.
Bootstrapped and regtested on x86_64-pc-linux-gnu, both 32 and 64-bit. OK to
commit?
FX
it would b
On Tue, Jun 06, 2023 at 08:51:54AM -0700, Steve Kargl via Fortran wrote:
>
> Scratch 2. Another scan shows that you moduled the Fortran
s/you moduled/you added to
> module where interface are built. This will automatically
s/interface/interfaces
> catch and report the items in 2.
Complete
On Tue, Jun 06, 2023 at 08:43:36AM -0700, Steve Kargl via Fortran wrote:
> On Tue, Jun 06, 2023 at 03:19:18PM +0200, FX via Fortran wrote:
> > Hi,
> >
> > This patch adds four IEEE functions from the Fortran 2018
> > standard: IEEE_MIN_NUM, IEEE_MAX_NUM, IEEE_MIN_NUM_MAG,
> > and IEEE_MAX_NUM_MAG.
On Tue, Jun 06, 2023 at 03:19:18PM +0200, FX via Fortran wrote:
> Hi,
>
> This patch adds four IEEE functions from the Fortran 2018
> standard: IEEE_MIN_NUM, IEEE_MAX_NUM, IEEE_MIN_NUM_MAG,
> and IEEE_MAX_NUM_MAG.
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu, both 32
> and 64-bit. OK to
Hi,
This patch adds four IEEE functions from the Fortran 2018 standard:
IEEE_MIN_NUM, IEEE_MAX_NUM, IEEE_MIN_NUM_MAG, and IEEE_MAX_NUM_MAG.
Bootstrapped and regtested on x86_64-pc-linux-gnu, both 32 and 64-bit. OK to
commit?
FX
0001-Fortran-add-Fortran-2018-IEEE_-MIN-MAX-functions.patch
Des
19 matches
Mail list logo
