Re: libgfortran: remove support for --enable-intermodule

2023-06-11 Thread Mikael Morin

Le 10/06/2023 à 22:28, FX Coudert via Fortran a écrit :

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109373
I don’t believe it is widely used, and it was removed from everywhere else in 
gcc.

Bootstrapped and regtested on x86_64-pc-linux-gnu.
OK to commit?

FX


OK, thanks.


Re: [PATCH] Fortran: add Fortran 2018 IEEE_{MIN,MAX} functions

2023-06-11 Thread Thomas Koenig via Fortran

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 enabled?

Running

nohup make -j7 check-fortran 
RUNTESTFLAGS="--target_board=unix/-mabi=ieeelongdouble/-mcpu=power9"&


from the gcc subdirectory yielded only a single failure:

grep ^FAIL nohup.out
FAIL: gfortran.dg/gomp/target-update-1.f90   -O   scan-tree-dump gimple 
"#pragma omp target update to\\(c \\[len: [0-9]+\\]\\) to\\(present:a 
\\[len: [0-9]+\\]\\) to\\(e \\[len: [0-9]+\\]\\) from\\(present:b 
\\[len: [0-9]+\\]\\) from\\(d \\[len: [0-9]+\\]\\)


and also ran the correct tests, as seen from gfortran.log; for example:

Executing on host: gfortran 
/home/tkoenig/gcc/gcc/testsuite/gfortran.dg/ieee/large_2.f90 
-mabi=ieeelongdouble -mcpu=power9   -fdiagnostics-plain-output 
-fdiagnostics-plain-output-O0   -pedantic-errors 
-fintrinsic-modules-path 
/home/tkoenig/gcc-bin/powerpc64le-unknown-linux-gnu/./libgfortran/ 
-fno-unsafe-math-optimizations -frounding-math -fsignaling-nans-lm 
-o ./large_2.exe(timeout = 300)
spawn -ignore SIGHUP gfortran 
/home/tkoenig/gcc/gcc/testsuite/gfortran.dg/ieee/large_2.f90 
-mabi=ieeelongdouble -mcpu=power9 -fdiagnostics-plain-output 
-fdiagnostics-plain-output -O0 -pedantic-errors -fintrinsic-modules-path 
/home/tkoenig/gcc-bin/powerpc64le-unknown-linux-gnu/./libgfortran/ 
-fno-unsafe-math-optimizations -frounding-math -fsignaling-nans -lm -o 
./large_2.exe^M

PASS: gfortran.dg/ieee/large_2.f90   -O0  (test for excess errors)
Setting LD_LIBRARY_PATH to 
.:/home/tkoenig/lib/../lib64:.:/home/tkoenig/lib/../lib64

Execution timeout is: 300
spawn [open ...]^M
PASS: gfortran.dg/ieee/large_2.f90   -O0  execution test

This is a test that fails on POWER with the IBM long double format,
so things look ok.  It also works when compiled individually.

So, this is looking good.

By the way, if you or any other gfortran maintainer would like an
account on the POWER virtual machine in question, that would be
no problem. I would ask the cluster administrators for permission
and then create the account (I have admin privileges on that
virtual machine).

> It’s not even clear to me what the IEEE kinds selected should be, in 
this case, depending on -mabi=ieeelongdouble


The "KIND=17" stuff should only be visible inside the library.

>
>> Regarding FX's patch: I am not quite sure that I am
>> actually testing the right thing if running the testsuite
>> there, so POWER should not hold up this patch.  If it turns
>> out that POWER needs additonal work on IEEE, we can always
>> add that later.
>
> Actually, it sounds like the situation is: the same target can
> have two ABIs based on a compile-time flag. That sounds like a job
> for multilib, i.e., we should compile libgfortran twice, one for
> each ABI. I am sure> this was considered and rejected, do you
> remember what was the rationale?

I don't remember discussing multilib in this context, sorry.

Best regards

Thomas


Re: libgfortran: remove support for --enable-intermodule

2023-06-11 Thread FX Coudert via Fortran
> OK, thanks.

Committed at 
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=ecc96eb5d2a0e5dd93365ef76a58d7f754273934

Re: [PATCH] Fortran: add Fortran 2018 IEEE_{MIN,MAX} functions

2023-06-11 Thread FX Coudert via Fortran
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 
0c2d6aa1be2ea85e751852834986ae52d58134d3 all IEEE functions manipulating real 
or complex arguments are actually expanded fully inline (we retain functions in 
libgfortran for backward compatibility).

The only IEEE functions that depend on libgfortran runtime are the 
“IEEE_SUPPORT_*” functions.

FX