Re: [patch] Fix PR libfortran/95177, ctype.h functions should not be called with char arguments

[Thomas Koenig via Fortran]

On 17.12.21 00:34, FX via Fortran wrote:

unrelated PS: I’ve been thinking aloud and benchmarking faster integer I/O for 
libgfortran at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98076
Comments are welcome on the proposed design, I think the current proposal is a 
low-hanging fruit (not risky, much faster).


Quick test integrating the idea into libgfortran, here are the timings to make 
a formatted write of 10 million integers into a string:

- very small value (1), negligible speedup (2.273s to 2.248s)
- small value (1042), speedup of 28% (3.224s to 2.350s)
- huge(0_8), speed up of 50% (5.914s to 2.560s)
- huge(0_16), speed up of 83% (19.46s to 3.31s)

Conclusion: this looks quite interesting!


Yes indeed.

I’m not sure what use cases people have for writing lots of formatted integers, 
but this doesn’t sound too bad.


If there is an obvoius speed-up to be had, we should go for it, for
a) the coolness value and
b) because somebody might need it :-)



Further thought: fast 64-bit itoa() implementations, under the MIT license 
(https://github.com/jeaiii/itoa) promise a speed-up of 2 to 10 times compared 
to naive implementation. That could bring us down further, but we probably 
cannot incorporate that, right?


Not sure about that.  We could reverse-engineer the algorithm,
if necessary (and if we are convinced that it is mathematically
correct :-)



Two questions:

1. This is easy, am I missing something? Some reason why it was never tried 
before?


Round tuits seem to have been lacking :-)


2. Why is gfc_xtoa() in runtime/error.c? We should probably move it.


No idea, and yes.

Re: [patch] Fix libfortran/98507, handling of timezone near year boundaries

[Thomas Koenig via Fortran]

Hi FX,


DATE_AND_TIME can return incorrect values for non-UTC timezones, near the new 
year, when the local time and UTC time are in different years. 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98507

Attached patch fixes the issue by correcting the logic to account for that 
wrapping of “day of the year” around new year. I include a testcase, which 
checks the sanity of values returned by DATE_AND_TIME. Since the bug only 
occurs for a few hours every year, and depends on local timezone, I could not 
think of a better (systematic) test.

I also want to propose (it’s not directly needed to fix the bug) that we switch 
our time routines to rely on clock_gettime() instead of gettimeofday(), when 
available. This is in line with POSIX.1-2008, which marks gettimeofday() as 
obsolete, recommending the use of
clock_gettime() instead.

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


OK.

Thanks for fixing this in time for the new year 2022 :-)

Regards

Thomas

Re: [patch, Fortran] Make REAL(KIND=16) detection more robust

[Thomas Koenig via Fortran]

Hi FX,

I am not sure the logic is correct for POWER (old style) where we have
a 16-byte long double made up from two 8-byte doubles, which is not
__float128 (IFmode), see

https://gcc.gnu.org/pipermail/fortran/2021-November/056912.html

I have a proposal: Since I am currently trying to unravel this
on the power-ieee128 branch, I would like to take this on,
if that is fine with you.

Best regards

Thomas

Re: [patch, Fortran] IEEE support for aarch64-apple-darwin

[Thomas Koenig via Fortran]

Hi FX,


Since support for target aarch64-apple-darwin has been submitted for review, 
it’s time to submit the Fortran part, i.e. enabling IEEE support on that target.

The patch has been in use now for several months, in a developer branch shipped 
by some distros on macOS (including Homebrew). It was authored more than a year 
ago, but I figured it wasn’t relevant to submit until the target was actually 
close to be in trunk: 
https://github.com/iains/gcc-darwin-arm64/commit/b107973550d3d9a9ce9acc751adbbe2171d13736

Bootstrapped and tested on aarch64-apple-darwin20 (macOS Big Sur) and 
aarch64-apple-darwin21 (macOS Monterey).

OK to merge?


OK, and thanks for the patch!

Best regards

Thomas

Re: [patch, Fortran] Make REAL(KIND=16) detection more robust

[Thomas Koenig via Fortran]

Hi FX,


I’m not opposed, but I’d really like to get this into the current branch. It is 
a much less invasive change than the power-ieee128 work. The only case I 
changed is the case where there is a kind 16, and there is a long double, but 
the long double is neither kind 10 neither kind 16. I don’t think there is such 
a platform currently (otherwise it wouldn’t have worked).


I did a bootstrap and test on POWER, and it did not
cause any regressions.

So, OK for trunk.  Thanks for the patch!

Regards

Thomas

Re: [PATCH] Simplify integer output-related functions in libgfortran

[Thomas Koenig via Fortran]

First merry Christmas to all!


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


OK.

Thanks for the (preliminary) patch!

Re: [PATCH] Make integer output faster in libgfortran

[Thomas Koenig via Fortran]

Hi FX,


The patch has been bootstrapped and regtested on two 64-bit targets: 
aarch64-apple-darwin21 (development branch) and x86_64-pc-gnu-linux. I would 
like it to be tested on a 32-bit target without 128-bit integer type. Does 
someone have access to that?


There are two possibilities: Either use gcc45 on the compile farm, or
run it with

make -k -j8 check-fortran RUNTESTFLAGS="--target_board=unix'{-m32,-m64}'"

which is the magic incantation to also use -m32 binaries.  You'll need
the 32-bit support on your Linux system, of course (which you can
check quickly with a "hello world" kind of program with -m32).

Regards

Thomas

Re: [PATCH] Make integer output faster in libgfortran

[Thomas Koenig via Fortran]

Hi fX,


right now I don’t have a Linux system with 32-bit support. I’ll see how I can 
connect to gcc45, but if someone who is already set up to do can fire a quick 
regtest, that would be great;)


I tested this on x86_64-pc-linux-gnu with

make -k -j8 check-fortran RUNTESTFLAGS="--target_board=unix'{-m32,-m64}'"

and didn't see any problems.

So, OK for trunk.

(We could also do something like that for a 32-bit system, but
that is another kettle of fish).

Thanks for taking this up!

Best regards

Thomas

Re: [PATCH] Make integer output faster in libgfortran

[Thomas Koenig via Fortran]

Hi FX,



(We could also do something like that for a 32-bit system, but
that is another kettle of fish).


We probably wouldn’t get a speed-up that big. Even on 32-bit targets
(at least common ones), the 64-bit type and its operations (notably
division) are implemented via CPU instructions, not library calls.


I'll look at this a bit more closely and report :-)


 At this point, the output of integers is probably bound by the
many layers of indirection of libgfortran's I/O system (which
are necessary because of the rich I/O formatting allowed by
the standard).


There are a few things we could do.  Getting a LTO-capable version
of libgfortran would be a huge step, because the compiler could
then strip out all of these layers.  The speed of

  character:: c


  write (*,'(A)', advance="no") c

could stand some improvement :-)

Regards

Thomas

Re: [power-ieee128] libgfortran: Small progress on the library side

[Thomas Koenig via Fortran]

Hi Jakub,


Ok for power-ieee128 branch?


OK. Thanks for stepping up!  I am a little distracted right now, but
I think I will also continue working on this for a bit.

Best regards

Thomas

Re: [power-ieee128] gfortran, v2: Introduce gfc_type_abi_kind

[Thomas Koenig via Fortran]

Hi Jakub,


Actually playing with that (e.g. for matmul) revealed a brown paper bag
bug in the previous patch, fixed thusly:


OK.

Thanks a lot!

Best regards

Thomas

[power-iee128] How to specify linker flags

[Thomas Koenig via Fortran]

Hi Michael,


If you are building libraries that contain modules with multiple long double
types, you must use the '-mno-gnu-attribute'.  We also use the '-Wno-psabi'
option, which silences the warning that you are switching long double types (if
glibc is not 2.34 or newer).  We may need to tweak -Wno-psabi for use with
Fortran.


I am now at the point where the object files are also compiled correctly
for the gfortran specifics:

 <_gfortran_specific__abs_r17>:
   0:   09 00 43 f4 lxv vs34,0(r3)
   4:   48 16 40 fc xsabsqp v2,v2
   8:   20 00 80 4e blr

However, the linker complains, as you said it would, about the different
formats:

/opt/at15.0/bin/ld: .libs/maxloc0_4_r16.o uses IBM long double, 
.libs/_abs_r17.o uses IEEE long double
/opt/at15.0/bin/ld: failed to merge target specific data of file 
.libs/_abs_r17.o


I know next to nothing about libtool, so I do not know how to
add the flags so the linker can find them.

Any pointers?

(I have not yet committed the changes because I do not want to
commit something that does not compile.  If anybody wants to
take a look, it's on the ieee128 virtual machine under
/home/tkoenig/ieee ).

Regards

Thomas

Re: [power-iee128] How to specify linker flags

[Thomas Koenig via Fortran]

On 02.01.22 23:58, Thomas Koenig wrote:

Hi Michael,

If you are building libraries that contain modules with multiple long 
double
types, you must use the '-mno-gnu-attribute'.  We also use the 
'-Wno-psabi'
option, which silences the warning that you are switching long double 
types (if
glibc is not 2.34 or newer).  We may need to tweak -Wno-psabi for use 
with

Fortran.


I am now at the point where the object files are also compiled correctly
for the gfortran specifics:

 <_gfortran_specific__abs_r17>:
    0:   09 00 43 f4 lxv vs34,0(r3)
    4:   48 16 40 fc xsabsqp v2,v2
    8:   20 00 80 4e blr

However, the linker complains, as you said it would, about the different
formats:

/opt/at15.0/bin/ld: .libs/maxloc0_4_r16.o uses IBM long double, 
.libs/_abs_r17.o uses IEEE long double
/opt/at15.0/bin/ld: failed to merge target specific data of file 
.libs/_abs_r17.o


I know next to nothing about libtool, so I do not know how to
add the flags so the linker can find them.

Any pointers?


One additional point.  The linker does not understand
-mno-gnu-attribute:

$ /opt/at15.0/bin/ld -mno-gnu-attribute
/opt/at15.0/bin/ld: unrecognised emulation mode: no-gnu-attribute
Supported emulations: elf64lppc elf32lppc elf32lppclinux elf32lppcsim 
elf64ppc elf32ppc elf32ppclinux elf32ppcsim


So, waiting for info to proceed.

Best regards

Thomas

[patch, power-ieee128, committed] Make the library functions compile correctly

[Thomas Koenig via Fortran]

Hello world,

the attached patch lets the library compile correctly, as far as I
have been able to determine.

Committed to the branch.

Best regards

Thomas

Make sure the Fortran specifics have real(kind=16).

This brings the library to compile with all specific functions.
It also corrects the patsubst patterns so the right files
get the flags.

It was necessary to manually add -D__powerpc64__ because apparently
this is not set for Fortran.

libgfortran/ChangeLog:

* Makefile.am: Correct files for compilation flags. Add
-D__powerpc64__ for Fortran sources.  Get kinds.inc from
grep of kinds.h and kinds-override.h.
* Makefile.in: Regenerate.
* config.h.in: Regenerate.
* configure: Regenerate.
* configure.ac: Add -mno-gnu-attribute to compile flags.
* generated/_abs_c17.F90: Regenerate.
* generated/_abs_r17.F90: Regenerate.
* generated/_acos_r17.F90: Regenerate.
* generated/_acosh_r17.F90: Regenerate.
* generated/_aimag_c17.F90: Regenerate.
* generated/_aint_r17.F90: Regenerate.
* generated/_anint_r17.F90: Regenerate.
* generated/_asin_r17.F90: Regenerate.
* generated/_asinh_r17.F90: Regenerate.
* generated/_atan2_r17.F90: Regenerate.
* generated/_atan_r17.F90: Regenerate.
* generated/_atanh_r17.F90: Regenerate.
* generated/_conjg_c17.F90: Regenerate.
* generated/_cos_c17.F90: Regenerate.
* generated/_cos_r17.F90: Regenerate.
* generated/_cosh_r17.F90: Regenerate.
* generated/_dim_r17.F90: Regenerate.
* generated/_exp_c17.F90: Regenerate.
* generated/_exp_r17.F90: Regenerate.
* generated/_log10_r17.F90: Regenerate.
* generated/_log_c17.F90: Regenerate.
* generated/_log_r17.F90: Regenerate.
* generated/_mod_r17.F90: Regenerate.
* generated/_sign_r17.F90: Regenerate.
* generated/_sin_c17.F90: Regenerate.
* generated/_sin_r17.F90: Regenerate.
* generated/_sinh_r17.F90: Regenerate.
* generated/_sqrt_c17.F90: Regenerate.
* generated/_sqrt_r17.F90: Regenerate.
* generated/_tan_r17.F90: Regenerate.
* generated/_tanh_r17.F90: Regenerate.
* kinds-override.h: Adjust to trunk.
Change condition to single line so it can be grepped.
* m4/specific.m4: Make sure that real=kind16 is used
for _r17.F90 and _c17.F90 files.
* m4/specific2.m4: Likewise.
* mk-kinds-h.sh: Adjust to trunk.
diff --git a/libgfortran/Makefile.am b/libgfortran/Makefile.am
index f3e358368cc..efc79d0d0b7 100644
--- a/libgfortran/Makefile.am
+++ b/libgfortran/Makefile.am
@@ -1075,15 +1075,16 @@ $(patsubst %.F90,%.lo,$(patsubst %.f90,%.lo,$(notdir $(gfor_specific_src: AM
 selected_real_kind.lo selected_int_kind.lo: AM_FCFLAGS += -fallow-leading-underscore
 
 # Build *_r17.F90 and *_c17.F90 with additional -mabi=ieeelongdouble on powerpc64le-linux.
+
 if HAVE_REAL_17
-$(patsubst %_r17.F90,%.lo,$(notdir $(gfor_specific_src))): AM_FCFLAGS += -mabi=ieeelongdouble
-$(patsubst %_r17.c,%.lo,$(notdir $(gfor_specific_src))): AM_FCFLAGS += -mabi=ieeelongdouble
-$(patsubst %_c17.F90,%.lo,$(notdir $(gfor_specific_src))): AM_FCFLAGS += -mabi=ieeelongdouble
-$(patsubst %_c17.c,%.lo,$(notdir $(gfor_specific_src))): AM_FCFLAGS += -mabi=ieeelongdouble
-$(patsubst %_r16.F90,%.lo,$(notdir $(gfor_specific_src))): AM_FCFLAGS += -mabi=ibmlongdouble
-$(patsubst %_r16.c,%.lo,$(notdir $(gfor_specific_src))): AM_FCFLAGS += -mabi=ibmlongdouble
-$(patsubst %_c16.F90,%.lo,$(notdir $(gfor_specific_src))): AM_FCFLAGS += -mabi=ibmlongdouble
-$(patsubst %_c16.c,%.lo,$(notdir $(gfor_specific_src))): AM_FCFLAGS += -mabi=ibmlongdouble
+$(patsubst %_r16.F90,%_r16.lo,$(notdir $(gfor_specific_src))): AM_FCFLAGS += -mabi=ibmlongdouble
+$(patsubst %_c16.F90,%_c16.lo,$(notdir $(gfor_specific_src))): AM_FCFLAGS += -mabi=ibmlongdouble
+$(patsubst %_r17.F90,%_r17.lo,$(notdir $(gfor_specific_src))): AM_FCFLAGS += -mabi=ieeelongdouble -D__powerpc64__
+$(patsubst %_c17.F90,%_c17.lo,$(notdir $(gfor_specific_src))): AM_FCFLAGS += -mabi=ieeelongdouble -D__powerpc64__
+$(patsubst %_r16.c,%_r16.lo,$(notdir $(gfor_built_src))): AM_CFLAGS += -mabi=ibmlongdouble
+$(patsubst %_c16.c,%_c16.lo,$(notdir $(gfor_built_src))): AM_CFLAGS += -mabi=ibmlongdouble
+$(patsubst %_r17.c,%_r17.lo,$(notdir $(gfor_built_src))): AM_CFLAGS += -mabi=ieeelongdouble
+$(patsubst %_c17.c,%_c17.lo,$(notdir $(gfor_built_src))): AM_CFLAGS += -mabi=ieeelongdouble
 endif
 
 if IEEE_SUPPORT
@@ -1154,8 +1155,8 @@ I_M4_DEPS9=$(I_M4_DEPS) m4/ifindloc2.m4
 kinds.h: $(srcdir)/mk-kinds-h.sh
 	$(SHELL) $(srcdir)/mk-kinds-h.sh '@LIBGOMP_CHECKED_INT_KINDS@' '@LIBGOMP_CHECKED_REAL_KINDS@' '$(FCCOMPILE)' > $@ || rm $@
 
-kinds.inc: kinds.h
-	grep '^#' < kinds.h > $@
+kinds.inc: kinds.h $(srcdir)/kinds-override.h
+	cat kinds.h $(srcdir)/kinds-override.h | grep '^#' | grep -v include > $@
 
 c99_

Re: [power-iee128] libgfortran: Use -mno-gnu-attribute in libgfortran

[Thomas Koenig via Fortran]

Hi Jakub,


On Mon, Jan 03, 2022 at 11:33:32AM +0100, Jakub Jelinek wrote:

The idea behind this is that libstdc++ is written such that it can handle
both IBM extended and IEEE quad long double, so its object files are
compatible with both.


Now tested on powerpc64le-linux (and together with the regenerated file),
ok for power-ieee128?


Since you posted it, I had already tested this and included it into the
patch I pushed a couple of minutes ago.

So, OK, and I already pushed it :-)

Thanks a lot for your help in this!

Best regards

Thomas

Re: [power-ieee128] libquadmath: Use -mno-gnu-attribute in libquadmath

[Thomas Koenig via Fortran]

On 03.01.22 16:24, Jakub Jelinek via Fortran wrote:

Ok for power-ieee128?


OK.

Thanks!

Best regards

Thomas

Re: [power-ieee128] libgfortran: -mabi=ieeelongdouble I/O

[Thomas Koenig via Fortran]

Hi Jakub,


So, either we'd need to add e.g. preprocessing support for gfortran.map
or some other way how to make certain symbols appear conditionally at
different symbol versions, or another option would be to choose different
symbol names for those for the powerpc64le-linux cases
(e.g._gfortran_transfer_{real,complex}ieee128{,_write}).

Any preferences?


My personal preference would be the ieee128 variant, it would be cleaner
that way, but I have no strong opinion either way.

So, that variant is OK from my side, but maybe you could wait for
a day or so for anybody else to chime in.

Best regards

Thomas

Re: [power-ieee128] libgfortran: -mabi=ieeelongdouble I/O

[Thomas Koenig via Fortran]

On 03.01.22 17:26, Jakub Jelinek wrote:


so we could similarly have something like:
#if !(defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ && 
__SIZEOF_LONG_DOUBLE__ == 16)
 _gfortran_transfer_complex128;
 _gfortran_transfer_complex128_write;
#endif
...
#if !(defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ && 
__SIZEOF_LONG_DOUBLE__ == 16)
 _gfortran_transfer_real128;
 _gfortran_transfer_real128_write;
#endif
...
#if defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ && 
__SIZEOF_LONG_DOUBLE__ == 16
   _gfortran_transfer_complex128;
   _gfortran_transfer_complex128_write;
   _gfortran_transfer_real128;
   _gfortran_transfer_real128_write;
#endif


That would also work for me.


or make that dependent on HAVE_GFC_REAL_17 or whatever else (with suitable
includes that only define macros and not actual C code).


With my most recent commit, HAVE_GFC_REAL_17 can now be found in
kinds.inc if all of the macros above are defined, that should
be suitable.

I found that __powerpc64__ is not defined when compiling *.F90 files
(which is why I added them by hand). Not sure how the preprocessor is
invoked on gfortran.map, but if things don't work, this could be
related :-)

So, it's OK either way with me.  What do others think?

Best regards

Thomas

Re: [power-ieee128] libgfortran, fortran: -mabi=ieeelongdouble I/O

[Thomas Koenig via Fortran]

Hi Jakub,


clearly there is still work to fix (but seems e.g. most of the lto tests
are related to the gnu attributes stuff:(  ).


This is looking better than what I expected.  Apart from LTO, I expect
that a couple of files still do not have the correct flags set when
compiling, or maybe some types are wrong. This is now something
that can be debugged in detail.


Ok?


OK.  And thanks!

Best regards

Thomas

Re: [power-ieee128] libgfortran: -mabi=ieeelongdouble I/O fix

[Thomas Koenig via Fortran]

On 04.01.22 14:41, Jakub Jelinek via Fortran wrote:

Ok for power-ieee128?


OK.

Re: [power-ieee128] fortran, libgfortran: Assorted -mabi=ieeelongdouble I/O fixes

[Thomas Koenig via Fortran]

On 04.01.22 15:23, Jakub Jelinek via Fortran wrote:

Ok for power-ieee128?


Also OK.

Best regards

Thomas

Re: [power-ieee128] fortran, libgfortran: Add remaining missing *_r17 symbols

[Thomas Koenig via Fortran]

Hi Jakub,


Following patch adds remaining missing *_r17 entrypoints, so that
we have 91 *_r16 and 91 *_r17 entrypoints (and 24 *_c16 and 24 *_c17).

This fixes:
FAIL: gfortran.dg/dec_math.f90   -O0  execution test
FAIL: gfortran.dg/dec_math.f90   -O1  execution test
FAIL: gfortran.dg/dec_math.f90   -O2  execution test
FAIL: gfortran.dg/dec_math.f90   -O3 -fomit-frame-pointer -funroll-loops 
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/dec_math.f90   -O3 -g  execution test
FAIL: gfortran.dg/dec_math.f90   -Os  execution test
FAIL: gfortran.dg/ieee/dec_math_1.f90   -O0  execution test
FAIL: gfortran.dg/ieee/dec_math_1.f90   -O1  execution test
FAIL: gfortran.dg/ieee/dec_math_1.f90   -O2  execution test
FAIL: gfortran.dg/ieee/dec_math_1.f90   -O3 -fomit-frame-pointer -funroll-loops 
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/ieee/dec_math_1.f90   -O3 -g  execution test
FAIL: gfortran.dg/ieee/dec_math_1.f90   -Os  execution test

Ok for power-ieee128?


Looks good to me.

Thanks!

Thomas

Re: [power-ieee128] fortran, libgfortran: Assorted -mabi=ieeelongdouble I/O fixes

[Thomas Koenig via Fortran]

Hi Jakub,


This test FAILs because
f951: Error: '-mabi=ieeelongdouble' requires full ISA 2.06 support
compiler exited with status 1
FAIL: gfortran.dg/pr47614.f   -O0  (test for excess errors)
As powerpc64le* only supports -mcpu=power8 and newer, I think we shouldn't
be testing with that option.

Ok for power-ieee128?


OK (I would also consider it obvious).



Though, I'm still unsure on what we should do with the array descriptors.
typedef struct dtype_type
{
   size_t elem_len;
   int version;
   signed char rank;
   signed char type;
   signed short attribute;
}
dtype_type;

Is elem_len really element length, or kind, or both?


It is specified as a length, and should be set correctly also
for complex (where it is twice the length).


It seems a lot of code uses that interchangeably, is there anything where
we'd rely on whether it is the IBM extended real(kind=16) or IEEE quad
real(kind=16) (either in libgfortran or elsewhere)?


I think we use sizeof in all relevant files.


At least in libgfortran/generates/*, GFC_DESCRIPTOR_SIZE is mostly used
as mask_kind (I think the mask arrays are always logical not real/complex,
right?), or for logical stuff like matmul_l*.


Yes, masks are always of type logical, so that should not be an issue.

There are two direct uses of elem_len in caf/singe.c, one in
date_and_time.c and one in io/transfer.c.  There is also some
use of a variable of that name ISO_Fortran_binding.c, which can
be checked later.

Best regards

Thomas

Re: [power-ieee128] RFH: LTO broken

[Thomas Koenig via Fortran]

On 06.01.22 06:00, Michael Meissner via Fortran wrote:

I pushed the patch to the branch.


Test results are looking quite good right now.

What is still missing is the conversion for unformatted I/O, both
ways.  I'll start doing some stuff on it. Just one question:
What are functions that I can use to convert from IBM long double
to IEEE and long double and vice versa?  It was in an e-mail somewhere,
but I cannot find it at the moment.

Best regards

Thomas

Re: [power-ieee128] OPEN CONV

[Thomas Koenig via Fortran]

On 07.01.22 10:22, Jakub Jelinek wrote:

On Thu, Jan 06, 2022 at 09:01:54PM +0100, Thomas Koenig wrote:


On 06.01.22 06:00, Michael Meissner via Fortran wrote:
What is still missing is the conversion for unformatted I/O, both
ways.  I'll start doing some stuff on it. Just one question:
What are functions that I can use to convert from IBM long double
to IEEE and long double and vice versa?  It was in an e-mail somewhere,
but I cannot find it at the moment.


So, what's the plan for that?
Can't find CONVERT= in Fortran 2018, so I assume it is a non-standard
extension,


Correct.


https://www.intel.com/content/www/us/en/develop/documentation/fortran-compiler-oneapi-dev-guide-and-reference/top/language-reference/file-operation-i-o-statements/open-statement-specifiers/open-convert-specifier.html#open-convert-specifier
documents the Intel one


We followed Intel on that one.  NAG also has it
(although the details differ).


and we accept
CONVERT='native'
CONVERT='swap'
CONVERT='big_endian'
CONVERT='little_endian'
Now, I suppose for powerpc64le we want to add
some more, but the question is how they play together
with the byteswapping and how to name them, so that
it is clear they talk about REAL/COMPLEX KIND=16 format
and nothing else.  Can we (or do we) want to allow
multiple comma separated strings from the orthogonal
choices, like
CONVERT='big_endian,ibm_extended'
CONVERT='swap,ieee_extended'
or add ibm_extended, ieee_extended and strings that
combine those with swap, big_endian and little_endian
ibm_extended_swap, ieee_extended_little etc.?


In

https://gcc.gnu.org/pipermail/fortran/2021-October/056895.html

I made a suggestion how how the format could look like.  I used
a plus sign instead of a comma because I thought the environment
variable should follow the same syntax as the CONVERT specifier,
and I did not want to think about having commas in there :-)

Thinking about this again after some time, I think the syntax of
the environment variable would be clearer if the keywords for
the two conversions were separate, so somethig like

big_endian;r16_ieee;r16_ibm:10-20;

for the environment variable and

CONVERT="big_endian,r16_ibm"

would probably be better.


Best regards

Thomas

Re: [power-ieee128] RFH: LTO broken

[Thomas Koenig via Fortran]

Hi Jakub,


00251038  06ad0015 R_PPC64_JMP_SLOT    
__cabsieee128 + 0
All these should for POWER_IEEE128 use atan2q@QUADMATH_1.0 etc.


So, seems all these come from f951 compiled sources.
For user code, I think the agreement was if you want to use successfully
-mabi=ieeelongdouble, you need glibc 2.32 or later, which is why the Fortran
FE doesn't conditionalize on whether glibc 2.32 is available or not and just
emits __WHATEVERieee128 entrypoints.


That was the idea, I think.


But for Fortran compiled sources in libgfortran, we need to use
__WHATEVERieee128 only if glibc 2.32 or later and WHATEVERq (from
libquadmath) otherwise.
I guess easiest would be to do this always in the FE, but we need to
determine in the FE if the target is glibc 2.32 or later.


Instead of determining this in the front end, maybe we can add
an option (documented, but marked as useful as only for internal
use and with no guarantee that it will remain) and use that option
when compiling libgfortran.


On the other side, on glibc 2.32+ build, we still use some libquadmath APIs
when we shouldn't:
readelf -Wr 
/home/jakub/gcc/obj/powerpc64le-unknown-linux-gnu/libgfortran/.libs/libgfortran.so.5
 | grep QUADMATH
002502c8  00260015 R_PPC64_JMP_SLOT    
fmaq@QUADMATH_1.0 + 0
002505f8  00670015 R_PPC64_JMP_SLOT    
tanq@QUADMATH_1.0 + 0
00250930  009b0015 R_PPC64_JMP_SLOT    
fabsq@QUADMATH_1.0 + 0
00250940  009d0015 R_PPC64_JMP_SLOT    
sinq@QUADMATH_1.0 + 0
00250c98  00cf0015 R_PPC64_JMP_SLOT    
copysignq@QUADMATH_1.0 + 0
00251038  01070015 R_PPC64_JMP_SLOT    
cosq@QUADMATH_1.0 + 0
00251068  010a0015 R_PPC64_JMP_SLOT    
fmodq@QUADMATH_1.0 + 0
These should use __fmaieee128, __tanieee128 etc. instead.


This one seems easily fixed by the following patch, ok for power-ieee128?


OK!

Best regards

Thomas

Re: [power-ieee128] RFH: LTO broken

[Thomas Koenig via Fortran]

Hi Jakub,


So, the following patch adds -fbuilding-libgfortran option and uses
it together with TARGET_GLIBC_M* checks to decide whether to use
libquadmath APIs (for the IEEE quad kind=16 if -fbuilding-libgfortran
and not glibc or glibc is older than 2.32) or glibc 2.32 APIs
(otherwise).  This way, libgfortran uses solely the libquadmath APIs
on glibc < 2.32 and __*ieee128 APIs on glibc 2.32, while user code
always uses the latter.

Ok for power-ieee128?


OK!

Best regards

Thomas

Re: [power-ieee128] OPEN CONV

[Thomas Koenig via Fortran]

On 07.01.22 20:52, Jakub Jelinek wrote:

Here is completely untested patch that implements something,
but doesn't implement the gcc option stuff, nor the CONVERT=
syntax to supply multiple conversion options nor done anything
about env var nor any testcases.

But it tries to have the native/swap/big/little choice orthogonal from
native/r16_ieee/r16_ibm with r16_ieee and r16_ibm only supported on
ppc64le-linux.

For INQUIRE it has the so far perhaps manageable set of possibilities
handled so that it uses string literals and doesn't have to construct
those strings at runtime (haven't studied how it would need to be done).

I'm afraid I don't know that stuff enough to move forward from this.


That looks like the direction to go.

I will take it from there and see if I can find some hours over the
weekend to work on something. Unfortunately, my daytime job will
kick in again on Monday :-)

One thing that one has to watch out for is a big-endian IBM long double
file, so the byte swapping will have to be done before assigning
the value.

Best regards

Thomas

Re: [power-ieee128] OPEN CONV

[Thomas Koenig via Fortran]

On 07.01.22 22:48, Jakub Jelinek wrote:

On Fri, Jan 07, 2022 at 10:40:50PM +0100, Thomas Koenig wrote:

One thing that one has to watch out for is a big-endian IBM long double
file, so the byte swapping will have to be done before assigning
the value.


I've tried to handle that right, i.e. on unformatted read with
byte-swapping and r16 <-> r17 conversions first do byte-swapping
and then r16 <-> r17 conversions, while for unformatted writes
first r16 <-> r17 conversions and then byte-swapping.


I have tried to unravel the different cases here, I count six
(lumping together the environment variables, the CONVERT specifier
and -fconvert, and leaving out the byte swapping)

CompilerConvert   Read action Write action

IEEENone  NoneNone
IEEEIEEE  NoneNone
IEEEIBM   IBM->IEEE   IEEE->IBM

IBM None  NoneNone
IBM IEEE  IEEE->IBM   IBM->IEEE
IBM IBM   NoneNone

From this table, it is clear that the compiler has to inform
the library about the option it is using, I think it is best
encoded in the number passed to _gfortran_set_convert.

Old programs should continue to run with the new library, so
the absence of a call to _gfortran_set_convert, or a call
which sets byte swapping, should have the old meaning, i.e
IBM long double. A program which uses IEEE long double should
then call _gfortran_set_convert with a suitable argument to
let the library know what to do, just in case.

I think this is what I will start working on.

Best regards

Thomas

Re: [power-ieee128] OPEN CONV

[Thomas Koenig via Fortran]

On 08.01.22 15:02, Jakub Jelinek via Fortran wrote:

Note, as for byteswapping, apparently it wasn't ever working right fox
the IBM extended real(kind=16) and complex(kind=16).


The lack of bug reports since the conversion feature was introduced in
2006, more than 15 years ago, tells us something, I guess...

[power-ieee128, patch, committed] Implement CONVERT specifier

[Thomas Koenig via Fortran]

Hi,

I just pushed the attached patch to the branch.  It works with the
attached test case for -mabi=ibmlongdouble and -mabi=ieeelongdouble.
The test case is not quite ready for inclusion in the test suite;
it still leaves its last data files behind, and it needs to be
dejagnuified and put with the right options into the right
directory.  Not quite sure how to do this.


Still to do: the environment variables and -fconvert.

For the -fconvert option, I would like to see the same sort
of syntax as in the convert option, something like

-fconvert=r16_ieee,big-endian

but I do not know how to massage the *.opt files to accomplish
that.

Regarding specifying via environment variables:  Next on
my agenda.

So, here's the patch.

Implement CONVERT specifier for OPEN.

This patch, based on Jakub's work, implements the CONVERT
specifier for the power-ieee128 brach.  It allows specifying
the conversion as r16_ieee,big_endian and the other way around,
based on a table.  Setting the conversion via environment
variable and via program option does not yet work.

gcc/ChangeLog:

* flag-types.h (enum gfc_convert): Add flags for
conversion.

gcc/fortran/ChangeLog:

* libgfortran.h (unit_convert): Add flags.

libgfortran/ChangeLog:

* Makefile.in: Regenerate.
* io/file_pos.c (unformatted_backspace): Mask off
R16 parts for convert.
* io/inquire.c (inquire_via_unit): Add cases for
R16 parts.
* io/open.c (st_open): Add cases for R16 conversion.
* io/transfer.c (unformatted_read): Adjust for R16 conversions.
(unformatted_write): Likewise.
(us_read): Mask of R16 bits.
(data_transfer_init): Likewiese.
(write_us_marker): Likewise.


! { dg-do run }
program tescht
  implicit none
  real (kind=16), parameter :: one_third = 3
  call test_sanity
  call test_sanity("r16_ieee")
  call test_sanity("r16_ieee,big_endian")
  call test_sanity("r16_ibm")
  call test_sanity("big_endian,r16_ibm")
  call test_ibm("r16_ibm")
  call test_ibm("r16_ibm,swap")
  call test_ibm("r16_ibm,big_endian")
  call test_ibm("r16_ibm,little_endian")
  call test_ibm("swap,r16_ibm")
  call test_ibm("big_endian,r16_ibm")
  call test_ibm("little_endian,r16_ibm")
contains
  subroutine test_sanity(convert)
character(len=*), optional :: convert
real(kind=16) :: a, b, c, d
complex(kind=16) :: c1, c2
real(kind=16) :: arr(2)
complex(kind=16), dimension(10) :: c_arr
real(kind=16), dimension(10) :: a_arr, b_arr
integer :: i

if (present(convert)) then
   open(10,file="dat",form="unformatted",convert=convert,status="replace")
else
   open(10,file="dat",form="unformatted",status="replace")
end if

a = atan(1._16)*4

! Writing a single value and reading it back again
write (10) a
rewind (10)
read (10) b
if (abs(a-b) > 1e-30) stop 10

! Writing out a KIND=16 complex number and reading
! it back again
rewind(10)
c1 = cmplx(a, one_third,16)
rewind(10)
write (10) c1
rewind(10)
c2 = 0
read (10) c2
if (abs(c1 - c2) > 1e-10) stop 11

! Reading it back in as two reals
rewind(10)
read (10) c,d
if (abs(c-a) > 1e-30 .or. abs(d-one_third) > 1e-30) stop 12

! Reading it back as an array of two reals
rewind(10)
read (10) arr
if (abs(arr(1) - a) > 1e-30 .or. abs(arr(2) - one_third) > 1e-30) stop 13
close(10)

! Writing out a complex array
c_arr = [(1._16/(1._16+cmplx(0,i,16)),i=1,size(c_arr))]
rewind(10)
write (10) c_arr
rewind(10)
read (10) (a_arr(i), b_arr(i),i=1,10)
if (any (abs(real(c_arr)-a_arr) > 1e-30) .or. any(abs(aimag(c_arr)-b_arr) > 1e-30)) stop 14
  end subroutine test_sanity

  subroutine test_ibm(convert)
  ! Specific checks for writing and reading IBM long doubles as pairs
  ! of doubles.
character(len=*) :: convert
double precision::  x1, x2, x3, x4
real(kind=16) :: a, b, c
complex(kind=16) :: c1, c2
real(kind=16) :: rf(2)

a = atan(1._16)*4

open (10,file=convert // ".dat",status="replace",form ="unformatted",convert=convert)
! Writing a single value and reading it back again
write (10) a
rewind(10)
read (10) b
if (abs(a-b) > 1e-30) stop 1
return
! Writing out a KIND=16 value and reading it back again as a
! pair of doubles.

rewind(10)
read (10) x1, x2
b = real(x1,kind=16) + real(x2,kind=16)
if (abs(a-b) > 1e-30) stop 2

! Writing out a KIND=16 complex number and reading
! it back again
rewind (10)
c1 = cmplx(a, one_third,16)
write (10) c1
rewind (10)
read (10) c2
if (abs(c1 - c2) > 1e-10) stop 3

! Reading it back as a KIND=16 REAL array
rewind(10)
read (10) rf
if (abs(rf(1) - a) > 1e-30 .or. abs(rf(2) - one_third) > 1e-30) stop 4

! Reading it back as four double precision values
rewind (10)
read (10) x1, x2, x3, x4
b = real(x1,kind=16) + real(x2,ki

[power-ieee128, committed] Enable conversion selection via environment variable

[Thomas Koenig via Fortran]

Hello world,

I have just pushed the attched patch to the branch.

With this patch, the program

tkoenig@gcc-fortran:~/Tst$ cat write_env.f90
program main
  real(kind=16) :: x
  character (len=30) :: conv
  x = 1/3._16
  open 
(10,file="out.dat",status="replace",access="stream",form="unformatted")

  inquire(10,convert=conv)
  print *,conv
  write (10) 1/3._16
end program main

gives the result:

tkoenig@gcc-fortran:~/Tst$ GFORTRAN_CONVERT_UNIT="r16_ibm:10" ./a.out && 
od -w64 -t x1 out.dat

 LITTLE_ENDIAN,R16_IBM
000 55 55 55 55 55 55 d5 3f 56 55 55 55 55 55 75 3c
020
tkoenig@gcc-fortran:~/Tst$ GFORTRAN_CONVERT_UNIT="r16_ieee:10" ./a.out 
&& od -w64 -t x1 out.dat

 LITTLE_ENDIAN,R16_IEEE
000 80 55 55 55 55 55 55 55 55 55 55 55 55 55 fd 3f
020
tkoenig@gcc-fortran:~/Tst$ 
GFORTRAN_CONVERT_UNIT="big_endian:10;r16_ieee:10" ./a.out && od -w64 -t 
x1 out.dat

 BIG_ENDIAN,R16_IEEE
000 3f fd 55 55 55 55 55 55 55 55 55 55 55 55 55 80
020

so things look OK.  In the next few days, I will do a bit more
testing to see if I have missed any corner cases.

So, the only thing missing is handling of the options, but
I think that is not critical (and could be added later; two
separate possibilities might just be enough for most users :-)

So... time to merge the branch into trunk before stage 4
kicks in?

Best regards

Thomas


Handle R16 conversion for POWER in the environment variables.

This patch handles the environment variables for the REAL(KIND=16)
variables like for the little/big-endian routines, so users without
who have no access to the source or are unwilling to recompile
can use this.

Syntax is, for example

GFORTRAN_CONVERT_UNIT="r16_ieee:10;little_endian:10" ./a.out

libgfortran/ChangeLog:

* runtime/environ.c (R16_IEEE): New macro.
(R16_IBM): New macro.
(next_token): Handle IBM R16 conversion cases.
(push_token): Likewise.
(mark_single): Likewise.
(do_parse): Likewise, initialize endian.
diff --git a/libgfortran/runtime/environ.c b/libgfortran/runtime/environ.c
index fe16c080797..ff10fe53f68 100644
--- a/libgfortran/runtime/environ.c
+++ b/libgfortran/runtime/environ.c
@@ -247,6 +247,11 @@ init_variables (void)
 #define SWAP 258
 #define BIG  259
 #define LITTLE   260
+#ifdef HAVE_GFC_REAL_17
+#define R16_IEEE 261
+#define R16_IBM  262
+#endif
+
 /* Some space for additional tokens later.  */
 #define INTEGER  273
 #define END  (-1)
@@ -392,6 +397,15 @@ next_token (void)
   result = match_word ("swap", SWAP);
   break;
 
+#ifdef HAVE_GFC_REAL_17
+case 'r':
+case 'R':
+  result = match_word ("r16_ieee", R16_IEEE);
+  if (result == ILLEGAL)
+	result = match_word ("r16_ibm", R16_IBM);
+  break;
+
+#endif
 case '1': case '2': case '3': case '4': case '5':
 case '6': case '7': case '8': case '9':
   result = match_integer ();
@@ -414,7 +428,8 @@ push_token (void)
 
 /* This is called when a unit is identified.  If do_count is nonzero,
increment the number of units by one.  If do_count is zero,
-   put the unit into the table.  */
+   put the unit into the table.  For POWER, we have to make sure that
+   we can also put in the conversion btween IBM and IEEE long double.  */
 
 static void
 mark_single (int unit)
@@ -428,7 +443,11 @@ mark_single (int unit)
 }
   if (search_unit (unit, &i))
 {
+#ifdef HAVE_GFC_REAL_17
+  elist[i].conv |= endian;
+#else
   elist[i].conv = endian;
+#endif
 }
   else
 {
@@ -437,7 +456,11 @@ mark_single (int unit)
 
   n_elist += 1;
   elist[i].unit = unit;
+#ifdef HAVE_GFC_REAL_17
+  elist[i].conv |= endian;
+#else
   elist[i].conv = endian;
+#endif
 }
 }
 
@@ -481,6 +504,8 @@ do_parse (void)
 
   /* Parse the string.  First, let's look for a default.  */
   tok = next_token ();
+  endian = 0;
+
   switch (tok)
 {
 case NATIVE:
@@ -499,6 +524,15 @@ do_parse (void)
   endian = GFC_CONVERT_LITTLE;
   break;
 
+#ifdef HAVE_GFC_REAL_17
+case R16_IEEE:
+  endian = GFC_CONVERT_R16_IEEE;
+  break;
+
+case R16_IBM:
+  endian = GFC_CONVERT_R16_IBM;
+  break;
+#endif
 case INTEGER:
   /* A leading digit means that we are looking at an exception.
 	 Reset the position to the beginning, and continue processing
@@ -571,6 +605,19 @@ do_parse (void)
 	goto error;
 	  endian = GFC_CONVERT_BIG;
 	  break;
+#ifdef HAVE_GFC_REAL_17
+	case R16_IEEE:
+	  if (next_token () != ':')
+	goto error;
+	  endian = GFC_CONVERT_R16_IEEE;
+	  break;
+
+	case R16_IBM:
+	  if (next_token () != ':')
+	goto error;
+	  endian = GFC_CONVERT_R16_IBM;
+	  break;
+#endif
 
 	case INTEGER:
 	  push_token ();

Re: [power-ieee128, committed] Enable conversion selection via environment variable

[Thomas Koenig via Fortran]

On 11.01.22 14:19, Jakub Jelinek via Fortran wrote:

On Mon, Jan 10, 2022 at 11:44:13PM +0100, Thomas Koenig wrote:

Hello world,

I have just pushed the attched patch to the branch.


Thanks.

Here is a patch to fix up the ppc64be vs. ppc64le byteswapping
of IBM extended real(kind=16) and complex(kind=16).
Similarly to the BT_COMPLEX case it halves size and doubles nelems
for the bswap_array calls.  Of course for r16_ibm and r16_ieee conversions
one needs to make sure it is only done when the on file data is in that
format and not in IEEE quad.



The patch is OK.


So... time to merge the branch into trunk before stage 4
kicks in?


IMHO yes.  We need to git merge master; git rebase of course
before trying to cherry-pick those commits into trunk and pushing there.


I would prefer if somebody else did this - my lack of git-fu would
forseeably lead to some unforseen problems :-)


Best regards

Thomas

[patch, libgfortran, power-ieee128] Add multiple defaults for GFORTRAN_CONVERT_UNIT

[Thomas Koenig via Fortran]

Hello world,

with this patch, it is now possible to specify both the
endianness and the REAL(KIND=16) format using the
environment variable GFORTRAN_CONVERT_UNIT.  The following
now works:

koenig@gcc-fortran:~/Tst$ cat write_env.f90
program main
  real(kind=16) :: x
  character (len=30) :: conv
  x = 1/3._16
  open 
(10,file="out.dat",status="replace",access="stream",form="unformatted")

  inquire(10,convert=conv)
  print *,conv
  write (10) 1/3._16
end program main
tkoenig@gcc-fortran:~/Tst$ gfortran -g -static-libgfortran write_env.f90
tkoenig@gcc-fortran:~/Tst$ GFORTRAN_CONVERT_UNIT="little_endian;r16_ibm" 
&& ./a.out

 LITTLE_ENDIAN,R16_IBM
tkoenig@gcc-fortran:~/Tst$ 
GFORTRAN_CONVERT_UNIT="little_endian;r16_ieee" && ./a.out

 LITTLE_ENDIAN,R16_IEEE
tkoenig@gcc-fortran:~/Tst$ GFORTRAN_CONVERT_UNIT="big_endian;r16_ieee" 
&& ./a.out

 BIG_ENDIAN,R16_IEEE
tkoenig@gcc-fortran:~/Tst$ GFORTRAN_CONVERT_UNIT="big_endian;r16_ibm" && 
./a.out

 BIG_ENDIAN,R16_IBM

Since the branch has been pushed to trunk, I don't think we need
it any more (or do we?), so OK for trunk?

Best regards

Thomas

Allow for multiple defaults in endianness and r16 in GFORTRAN_CONVERT_UNIT.

With this patch, it is possible to specify multiple defaults inthe
GFORTRAN_CONVERT_UNIT environment variable so that, for example, R16_IEEE
and BIG_ENDIAN can be specified together.


libgfortran/ChangeLog:

* runtime/environ.c: Allow for multiple default values so that
separate default specifications for IBM long double format and
endianness are possible.

diff --git a/libgfortran/runtime/environ.c b/libgfortran/runtime/environ.c
index 3d60950234d..a53c64965b6 100644
--- a/libgfortran/runtime/environ.c
+++ b/libgfortran/runtime/environ.c
@@ -499,78 +499,79 @@ do_parse (void)
 
   unit_count = 0;
 
-  start = p;
-
   /* Parse the string.  First, let's look for a default.  */
-  tok = next_token ();
   endian = 0;
-
-  switch (tok)
+  while (1)
 {
-case NATIVE:
-  endian = GFC_CONVERT_NATIVE;
-  break;
+  start = p;
+  tok = next_token ();
+  switch (tok)
+	{
+	case NATIVE:
+	  endian = GFC_CONVERT_NATIVE;
+	  break;
 
-case SWAP:
-  endian = GFC_CONVERT_SWAP;
-  break;
+	case SWAP:
+	  endian = GFC_CONVERT_SWAP;
+	  break;
 
-case BIG:
-  endian = GFC_CONVERT_BIG;
-  break;
+	case BIG:
+	  endian = GFC_CONVERT_BIG;
+	  break;
 
-case LITTLE:
-  endian = GFC_CONVERT_LITTLE;
-  break;
+	case LITTLE:
+	  endian = GFC_CONVERT_LITTLE;
+	  break;
 
 #ifdef HAVE_GFC_REAL_17
-case R16_IEEE:
-  endian = GFC_CONVERT_R16_IEEE;
-  break;
+	case R16_IEEE:
+	  endian = GFC_CONVERT_R16_IEEE;
+	  break;
 
-case R16_IBM:
-  endian = GFC_CONVERT_R16_IBM;
-  break;
+	case R16_IBM:
+	  endian = GFC_CONVERT_R16_IBM;
+	  break;
 #endif
-case INTEGER:
-  /* A leading digit means that we are looking at an exception.
-	 Reset the position to the beginning, and continue processing
-	 at the exception list.  */
-  p = start;
-  goto exceptions;
-  break;
+	case INTEGER:
+	  /* A leading digit means that we are looking at an exception.
+	 Reset the position to the beginning, and continue processing
+	 at the exception list.  */
+	  p = start;
+	  goto exceptions;
+	  break;
 
-case END:
-  goto end;
-  break;
+	case END:
+	  goto end;
+	  break;
 
-default:
-  goto error;
-  break;
+	default:
+	  goto error;
+	  break;
 }
 
-  tok = next_token ();
-  switch (tok)
-{
-case ';':
-  def = endian;
-  break;
+  tok = next_token ();
+  switch (tok)
+	{
+	case ';':
+	  def = def == GFC_CONVERT_NONE ? endian : def | endian;
+	  break;
 
-case ':':
-  /* This isn't a default after all.  Reset the position to the
-	 beginning, and continue processing at the exception list.  */
-  p = start;
-  goto exceptions;
-  break;
+	case ':':
+	  /* This isn't a default after all.  Reset the position to the
+	 beginning, and continue processing at the exception list.  */
+	  p = start;
+	  goto exceptions;
+	  break;
 
-case END:
-  def = endian;
-  goto end;
-  break;
+	case END:
+	  def = def == GFC_CONVERT_NONE ? endian : def | endian;
+	  goto end;
+	  break;
 
-default:
-  goto error;
-  break;
+	default:
+	  goto error;
+	  break;
+	}
 }
 
  exceptions:

Re: [PATCH] PR fortran/83079 - ICE and wrong code with TRANSFER and character(kind=4)

[Thomas Koenig via Fortran]

Hi Harald,


An early *ping* ...


OK.  Thanks for the patch!

Best regards

Thomas

Re: [pushed 3/3] testsuite: Enrich tests with variants failing on the branch.

[Thomas Koenig via Fortran]

Hi Mikael,


Backporting the fix for pr103789 on the 11 branch revealed a lack of test
coverage for the tests provided with that fix.  Indeed, the tests use the KIND
argument of the respective intrinsics only with keyword arguments.
This adds variants with non-keyword arguments.

The tests enriched this way fail on the branch if the fix is cherry-picked
straightforwardly.  The fix will have to be tweaked slightly there.


As a general principle, we should not add or amend test cases unless
it is wrong code that we need to remove

The reason is that changing a test case makes regression testing,
especially the automated version, harder - if a test starts failing,
is it due to a change in the test case or a change in the compiler
or library?

I don't think there is a need to revert this patch, but please
add separate test cases if you have new things to test in
the future.

Best regards

Thomas

Re: [patch, libgfortran, power-ieee128] Add multiple defaults for GFORTRAN_CONVERT_UNIT

[Thomas Koenig via Fortran]

On 13.01.22 22:58, Thomas Koenig via Fortran wrote:

with this patch, it is now possible to specify both the
endianness and the REAL(KIND=16) format using the
environment variable GFORTRAN_CONVERT_UNIT.


I have now pushed this to trunk.

Best regards

Thomas

Re: [PATCH] PR fortran/103692 - [11/12 Regression] ICE in add_init_expr_to_sym, at fortran/decl.c:2062

[Thomas Koenig via Fortran]

Hi Harald,


after lengthy debugging of this PR it became obvious that we killed
the typespec while trying to expand an empty array constructor.

Bad idea, but easy to fix.

Regtested on x86_64-pc-linux-gnu.  OK for mainline and 11-branch?


OK.

Thanks for the patch!

Best regards

Thomas

Re: [PATCH] Fortran: Fix scope for OMP AFFINITY clause iterator variables [PR103695]

[Thomas Koenig via Fortran]

Hi Sandra,


This patch is for PR103695, marked as a P1 regression.  OK to check in?


I'm not an OpenMP expert, but this looks straightforward enough.

I assume you ran a regression-test?  OK if that is the case.

Thanks for the patch!

Best regards

Thomas

Re: [PATCH] fortran: Extend -fconvert= option for ppc64le r16_ieee and r16_ibm

[Thomas Koenig via Fortran]

Hi Jakub,


This patch on top of the previously posted option handling changes patch
allows specifying -fconvert=swap,r16_ieee etc. (but will error on it
when not on powerpc64le because in the library such swapping is only
implemented for HAVE_REAL_17).

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?


OK!

This is a much cleaner solution than what I had in mind, but didn't
start work on, which was to make the option into a string and parse
by hand.

Best regards

Thomas

Re: [PATCH] PR fortran/104127 - [9/10/11/12 Regression] ICE in get_array_charlen, at fortran/trans-array.c:7244

[Thomas Koenig via Fortran]

Hello Harald,


when simplifying TRANSFER with a MOLD argument of type character
and with SIZE=0 we lose the character length.

This happens in all gfortran versions and results in wrong code.
The purported regression is that at some point in the 9-development
this lead to a (previously possibly latent) ICE.

The attached patch sets up the character length in the typespec and
fixes the ICE.  There is another generic hidden/latent problem with
array constructors of size 0 passed to procedures (see e.g. pr86277)
which will remain and is beyond the scope of this fix.

Regtested on x86_64-pc-linux-gnu.  I also fixed a minor logic bug
in testcase transfer_simplify_11.f90.

OK for mainline?  Backports to branches?


OK for both.

Thanks for the patch!

Regards

Thomas

Re: [PATCH] Fortran: detect signaling NaNs on targets without issignaling macro in libc

[Thomas Koenig via Fortran]

On 24.01.22 15:23, FX via Fortran wrote:

Then it’s OK to commit for me, but you will need approval from release managers 
at this stage.

Hum… I submitted it before stage 4 started, does that count?


Yes, it does.

(There is also some leeway granted to non-release-critical languages
like Fortran.  RM approval is only needed once a branch has been
frozen).

Best regards

Thomas

Re: [PATCH] PR fortran/104211 - ICE in find_array_section, at fortran/expr.cc:1720

[Thomas Koenig via Fortran]

Hi Harald,


when referencing a bad array section after an erroneous previous
declaration we might hit an assert.  The assert can be replaced
by a more gracious error recovery.  Reported by Gerhard.

Regtested on x86_64-pc-linux-gnu.  OK for mainline?


OK.

Thanks for the patch!

Best regards

Thomas

Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

[Thomas Koenig via Fortran]

Hi Paul,


I have gone back to the start and have gone through finalizable derived
type assignments with the F2018 in hand. I have had a dreadful time with
direct by reference function calls and still am struggling with assignment
number 6 in the attached. I would be very grateful if you would run this
testcase for the other brands.


This is the output of nagfor 7.1, no idea how correct this is.

Best regards

Thomas

 At start of program: final_count =0
 ***

 1st assignment: No finalization because MyType unallocated.
 After 1st assignment(var not allocated): final_count =0(0)
 ***

 2nd assignment: MyType(=simple(1,MyType) finalized before assignment
 finalize simple - Mytype2%ind =1
 After 2nd assignment(var allocated): final_count =1(1)
 ***

 3rd assignment: MyTypeArray(%ind = [41 42]) finalized before assignment

 finalize simple(:) - MyTypeArray%ind=   42  43
 After 3rd assignment(array var allocated): final_count =1(1)
 ***

 Deallocation generates final call with self = simple (21, ThyType)
 4th assignment: MyTypeArray finalized before assignment
 Mtype finalized before assignment with self = simple (11, MyType)
 Function result finalized after assignment with self = simple (99, MyType)

 finalize simple - ThyType%ind =   21
 finalize simple - MyType%ind =   11
 After 4th assignment(array var allocated) :final_count =2(3)
 ***

 5th assignment: MyTypeArray finalized before assignment
 1] First finalization is of 'res' in constructor3 with:
 Self = [complicated (-1, constructor3, 0.0), complicated (-1, 
ThyTypeArra1, 0.0)]
 2] ThyTypeArray is finalized before assignment and after evaluation of 
constructor3

 Self = [3 times complicated (-1, ThyTypeArra1,0.0)]
 3] Function result finalized after assignment with
 Self = [complicated (-1, ThyTypeArra2, 0.0), complicated (-1, 
ThyTypeArra2, 0.0)]


 constructor3: final_count =  0
 finalize complicated(2) - constructor3 =0   0  0.00  0.00
 finalize simple(:) - constructor3%ind=0   0
 finalize complicated(3) - ThyTypeArra1 =   -1  -1  -1  0.00  0.00  0.00
 finalize simple(:) - ThyTypeArra1%ind=   -1  -1  -1
 finalize complicated(2) - ThyTypeArra2 =1   3  2.00  4.00
 finalize simple(:) - ThyTypeArra2%ind=1   3
 finalize complicated(2) - IypeArra2 =    3  2.00  4.00
 finalize simple(:) - IypeArra2%ind=    3
 finalize complicated(2) - IypeArra2 =    3  2.00  4.00
 finalize simple(:) - IypeArra2%ind=    3
 After 5th assignment(array var allocated):  10(6)

 ***
 Deallocate ThyTypeArray.
 finalize complicated(2) - ThyTypeArra2 =1   3  2.00  4.00
 finalize simple(:) - ThyTypeArra2%ind=1   3

 ***
 6th assignment: A repeat of the previous with an allocatable function 
result.

 This should give the same result as the 5th assignment.

 constructor4: final_count =  0
 finalize complicated(2) - constructor4 =1   1  1.00  1.00
 finalize simple(:) - constructor4%ind=1   1
 finalize complicated(2) - ThyTypeArra2 =1   3  2.00  4.00
 finalize simple(:) - ThyTypeArra2%ind=1   3
 finalize complicated(3) - ThyTypeArra1 =   -1  -1  -1  0.00  0.00  0.00
 finalize simple(:) - ThyTypeArra1%ind=   -1  -1  -1
 After 6th assignment(array var allocated):   6(6)

 ***
 Deallocations at end

 finalize simple - MyType%ind =   99
 After 1st deallocation: 1
 finalize simple - ThyType2%ind =   22
 After 2nd deallocation: 2
 finalize simple(:) - ThyType%ind=   21  22
 After 3rd deallocation: 3

Re: [PATCH] PR fortran/77693 - ICE in rtl_for_decl_init, at dwarf2out.c:17378

[Thomas Koenig via Fortran]

Hi Harald,


Regtested on x86_64-pc-linux-gnu.  OK for mainline?


Looks good to me.  Thanks for the patch!

Best regards

Thomas

Re: [PATCH] PR fortran/104619 - [10/11/12 Regression] ICE on list comprehension with default derived type constructor

[Thomas Koenig via Fortran]

Hi Harald,


a recently introduced shape validation for an array constructor
against the declared shape of a DT component failed to punt if
the shape of the constructor cannot be determined at compile time.

Suggested solution: skip the shape check in those cases.

Regtested on x86_64-pc-linux-gnu.  OK for mainline / affected branches?


Looks good to me.

Thanks for the patch!

Best regards

Thomas

Re: Problem setting buffer size for gfortran ( v 11.2)

[Thomas Koenig via Fortran]

On 25.02.22 21:53, Bertini, Denis Dr. via Fortran wrote:

It seems that the value set in the foreseen environment variable is just
ignored.
And always a buffer size of 8kiB is used, which is the default values
for formatted I/O harcoded in libgfortran.
The only way to change this value is editing and recompiling the libgfortran.


This is really strange, I also cannot reproduce this.

With the Ubuntu-supplied gfortran 9.3.0 I get (just setting a few
semi-random numbers for the unformatted buffer size).

$ cat write.f90
program main
  implicit none
  integer, parameter :: n=100
  integer, dimension(n) :: x
  integer :: i
  x = [(i,i=1,n)]
  open (10,file="tst.dat",form="unformatted",action="write")
  do i=1,1000
write (10) x
  end do
end program main
$ gfortran write.f90
$ strace -e write ./a.out
write(3, 
"\220\1\0\0\1\0\0\0\2\0\0\0\3\0\0\0\4\0\0\0\5\0\0\0\6\0\0\0\7\0\0\0"..., 
408) = 408
write(3, 
"\220\1\0\0\1\0\0\0\2\0\0\0\3\0\0\0\4\0\0\0\5\0\0\0\6\0\0\0\7\0\0\0"..., 
65688) = 65688
write(3, 
"\220\1\0\0\1\0\0\0\2\0\0\0\3\0\0\0\4\0\0\0\5\0\0\0\6\0\0\0\7\0\0\0"..., 
65688) = 65688
write(3, 
"\220\1\0\0\1\0\0\0\2\0\0\0\3\0\0\0\4\0\0\0\5\0\0\0\6\0\0\0\7\0\0\0"..., 
65688) = 65688
write(3, 
"\220\1\0\0\1\0\0\0\2\0\0\0\3\0\0\0\4\0\0\0\5\0\0\0\6\0\0\0\7\0\0\0"..., 
65688) = 65688
write(3, 
"\220\1\0\0\1\0\0\0\2\0\0\0\3\0\0\0\4\0\0\0\5\0\0\0\6\0\0\0\7\0\0\0"..., 
65688) = 65688
write(3, 
"\220\1\0\0\1\0\0\0\2\0\0\0\3\0\0\0\4\0\0\0\5\0\0\0\6\0\0\0\7\0\0\0"..., 
65688) = 65688
write(3, 
"\220\1\0\0\1\0\0\0\2\0\0\0\3\0\0\0\4\0\0\0\5\0\0\0\6\0\0\0\7\0\0\0"..., 
13464) = 13464

+++ exited with 0 +++
$ GFORTRAN_UNFORMATTED_BUFFER_SIZE=20 strace -e write ./a.out
write(3, 
"\220\1\0\0\1\0\0\0\2\0\0\0\3\0\0\0\4\0\0\0\5\0\0\0\6\0\0\0\7\0\0\0"..., 
408) = 408
write(3, 
"\220\1\0\0\1\0\0\0\2\0\0\0\3\0\0\0\4\0\0\0\5\0\0\0\6\0\0\0\7\0\0\0"..., 
100368) = 100368
write(3, 
"\220\1\0\0\1\0\0\0\2\0\0\0\3\0\0\0\4\0\0\0\5\0\0\0\6\0\0\0\7\0\0\0"..., 
100368) = 100368
write(3, 
"\220\1\0\0\1\0\0\0\2\0\0\0\3\0\0\0\4\0\0\0\5\0\0\0\6\0\0\0\7\0\0\0"..., 
100368) = 100368
write(3, 
"\220\1\0\0\1\0\0\0\2\0\0\0\3\0\0\0\4\0\0\0\5\0\0\0\6\0\0\0\7\0\0\0"..., 
100368) = 100368
write(3, 
"\220\1\0\0\1\0\0\0\2\0\0\0\3\0\0\0\4\0\0\0\5\0\0\0\6\0\0\0\7\0\0\0"..., 
6120) = 6120

+++ exited with 0 +++
$ GFORTRAN_UNFORMATTED_BUFFER_SIZE=21 strace -e write ./a.out
write(3, 
"\220\1\0\0\1\0\0\0\2\0\0\0\3\0\0\0\4\0\0\0\5\0\0\0\6\0\0\0\7\0\0\0"..., 
408) = 408
write(3, 
"\220\1\0\0\1\0\0\0\2\0\0\0\3\0\0\0\4\0\0\0\5\0\0\0\6\0\0\0\7\0\0\0"..., 
105264) = 105264
write(3, 
"\220\1\0\0\1\0\0\0\2\0\0\0\3\0\0\0\4\0\0\0\5\0\0\0\6\0\0\0\7\0\0\0"..., 
105264) = 105264
write(3, 
"\220\1\0\0\1\0\0\0\2\0\0\0\3\0\0\0\4\0\0\0\5\0\0\0\6\0\0\0\7\0\0\0"..., 
105264) = 105264
write(3, 
"\220\1\0\0\1\0\0\0\2\0\0\0\3\0\0\0\4\0\0\0\5\0\0\0\6\0\0\0\7\0\0\0"..., 
91800) = 91800

+++ exited with 0 +++
$ GFORTRAN_UNFORMATTED_BUFFER_SIZE=210 strace -e write ./a.out
write(3, 
"\220\1\0\0\1\0\0\0\2\0\0\0\3\0\0\0\4\0\0\0\5\0\0\0\6\0\0\0\7\0\0\0"..., 
408) = 408
write(3, 
"\220\1\0\0\1\0\0\0\2\0\0\0\3\0\0\0\4\0\0\0\5\0\0\0\6\0\0\0\7\0\0\0"..., 
407592) = 407592

+++ exited with 0 +++
$ GFORTRAN_UNFORMATTED_BUFFER_SIZE=2100 strace -e write ./a.out
write(3, 
"\220\1\0\0\1\0\0\0\2\0\0\0\3\0\0\0\4\0\0\0\5\0\0\0\6\0\0\0\7\0\0\0"..., 
408) = 408
write(3, 
"\220\1\0\0\1\0\0\0\2\0\0\0\3\0\0\0\4\0\0\0\5\0\0\0\6\0\0\0\7\0\0\0"..., 
407592) = 407592

Re: [PATCH] fortran: Fix up initializers of param(0) PARAMETERs [PR103691]

[Thomas Koenig via Fortran]

On 25.03.22 12:34, Jakub Jelinek via Fortran wrote:

What is the behavior with a RANGE_EXPR when one has { [0..10] = ++i;
}, is that applying the side-effects 11 times or once ?


For side effects during the evaluation of expression, Fortran has a
clear "if you depend on it, it's your fault" rule.  In F 2018, it says

10.1.7  Evaluation of operands

1 It is not necessary for a processor to evaluate all of the operands of
an expression, or to evaluate entirely each operand, if the value of the
expression can be determined otherwise.

Also, the semantics of

a(a:b) = expr

say that the expression on the LHS is evaluated only once before
assignment.  So, anything that looks like that should be translated
to

tmp = ++i;
[0..10] = tmp;

Re: allocatable arrays and -fmax-stack-var-size

[Thomas Koenig via Fortran]

Hi Steve,


So, it seems that at some point in the past, the option
-fmax-stack-var-size was expanded to allow the placement
of an allocatable array into static memory.  This has
a possibly unintended consequence in that automatic
deallocation of an allocatable array does not (or can
not) occur.


Sounds like a bug to me, and if your test program worked
in a previous release, it's a regression.

Probably best to open a PR.

Best regards

Thomas

Re: [PATCH] PR fortran/105138 - Bogus error when function name does not shadow an intrinsic when RESULT clause is used

[Thomas Koenig via Fortran]

Hi Harald,


Steve's analysis (see PR) showed that we confused the case when a
symbol refererred to a recursive procedure which was named the same
as an intrinsic.  The standard allows such recursive references
(see e.g. F2018:19.3.1).

The attached patch is based on Steve's, but handles both functions
and subroutines.  Testcase verified with NAG and Crayftn.

Regtested on x86_64-pc-linux-gnu.  OK for mainline?

This bug is a rejects-valid, but could also lead to wrong code,
see e.g. the PR, comment#4.  Would this qualify for a backport
to e.g. the 11-branch?


OK for both.

Thanks for the patch!

Best regards

Thomas

Re: [PATCH, v2] PR fortran/105184 - ICE in gfc_array_init_size, at fortran/trans-array.cc:5841

[Thomas Koenig via Fortran]

Hi Harald,


Regtested again with no new failures.  OK for mainline?


Looks good to me.  Thanks for the patch!

Best regards

Thomas

Re: *PING* [PATCH 0/4] Use pointer arithmetic for array references [PR102043]

[Thomas Koenig via Fortran]

Hi Mikael,

Ping for the four patches starting at 
https://gcc.gnu.org/pipermail/fortran/2022-April/057759.html :

https://gcc.gnu.org/pipermail/fortran/2022-April/057757.html
https://gcc.gnu.org/pipermail/fortran/2022-April/057760.html
https://gcc.gnu.org/pipermail/fortran/2022-April/057758.html
https://gcc.gnu.org/pipermail/fortran/2022-April/057761.html

Richi accepted the general direction and the middle-end interaction.
I need a fortran frontend ack as well.


Looks good to me.

Thanks a lot for taking this on! This would have been a serious
regression if released with gcc 12.

Best regards

Thomas

Re: [PATCH] fortran: Compare non-constant bound expressions. [PR105379]

[Thomas Koenig via Fortran]

Hi Mikael,


this fixes a regression caused by my recent PR103662 patch.

Regression tested on x86_64-pc-linux-gnu. OK for master?


OK.  Good to see that a bit of optimization can also sneak in with
a bug fix :-)

Best regards

Thomas

Re: *PING* [PATCH 0/4] Use pointer arithmetic for array references [PR102043]

[Thomas Koenig via Fortran]

On 26.04.22 16:40, Hans-Peter Nilsson wrote:


These, or specifically r12-8227-g89ca0fffa48b79, "fortran:
Pre-evaluate string pointers. [PR102043]" have further
exposed (the issue existed before but now fails for more
platforms) PR78054 "gfortran.dg/pr70673.f90 FAILs at -O0",
at least for cris-elf and apparently also
s390x-ibm-linux-gnu.

In the PR it is mentioned that running the test through
valgrind shows invalid accesses also on x86_64-linux-gnu.
Could it be that the test-case is invalid and has undefined
behavior?  I don't know fortran so I can't tell.


You're right.  I just looked at the test case and can confirm
what Steve Kargl observed in the PR, it is in fact invalid.
You cannot do

  a = a

after deallocating a.

I've assigned the PR to myself and will commit the change to
dg-do compile soon (unless anybody objects).

Best regards

Thomas

[patch, fortran, doc] Mention new CONVERT options for POWER

[Thomas Koenig via Fortran]

Hi,

as we say in German "Nicht documentiert ist nicht gemacht", if
it is not documented, it wasn't done.

So I thought it would be time to document the changes to the various
ways of specifying CONVERT before gcc12 went out of the door, so
here is a patch for that.

If that goes in, I will also write up something for gcc-12/changes.html.

OK for trunk?  Suggestions for improvements?

Best regards

Thomas

Document changes to CONVERT for -mabi-ieeelongdouble for POWER

gcc/fortran/ChangeLog:

* gfortran.texi: Mention r16_ieee and r16_ibm.
* invoke.texi: Likewise.diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index f8737f4d323..6f622fb9898 100644
--- a/gcc/fortran/gfortran.texi
+++ b/gcc/fortran/gfortran.texi
@@ -589,7 +589,7 @@ Malformed environment variables are silently ignored.
 * GFORTRAN_SHOW_LOCUS::  Show location for runtime errors
 * GFORTRAN_OPTIONAL_PLUS:: Print leading + where permitted
 * GFORTRAN_LIST_SEPARATOR::  Separator for list output
-* GFORTRAN_CONVERT_UNIT::  Set endianness for unformatted I/O
+* GFORTRAN_CONVERT_UNIT::  Set conversion for unformatted I/O
 * GFORTRAN_ERROR_BACKTRACE:: Show backtrace on run-time errors
 * GFORTRAN_FORMATTED_BUFFER_SIZE:: Buffer size for formatted files
 * GFORTRAN_UNFORMATTED_BUFFER_SIZE:: Buffer size for unformatted files
@@ -686,11 +686,12 @@ when @command{a.out} is the compiled Fortran program that you want to run.
 Default is a single space.
 
 @node GFORTRAN_CONVERT_UNIT
-@section @env{GFORTRAN_CONVERT_UNIT}---Set endianness for unformatted I/O
+@section @env{GFORTRAN_CONVERT_UNIT}---Set conversion for unformatted I/O
 
 By setting the @env{GFORTRAN_CONVERT_UNIT} variable, it is possible
 to change the representation of data for unformatted files.
-The syntax for the @env{GFORTRAN_CONVERT_UNIT} variable is:
+The syntax for the @env{GFORTRAN_CONVERT_UNIT} variable for
+most systems is:
 @smallexample
 GFORTRAN_CONVERT_UNIT: mode | mode ';' exception | exception ;
 mode: 'native' | 'swap' | 'big_endian' | 'little_endian' ;
@@ -711,14 +712,24 @@ the modes are the same as for the @code{CONVERT} specifier:
 for unformatted files.
 @item @code{BIG_ENDIAN} Use the big-endian format for unformatted files.
 @end itemize
+For POWER systems which support @option{-mabi=ieeelongdouble},
+there are additional options, which can be combined with the
+others with commas. Those are
+@itemize @w{}
+@item @code{R16_IEEE} Use IEEE 128-bit format for @code{REAL(KIND=16)}.
+@item @code{R16_IBM} Use IBM @code{long double} format for
+@code{REAL(KIND=16)}.
+@end itemize
 A missing mode for an exception is taken to mean @code{BIG_ENDIAN}.
 Examples of values for @env{GFORTRAN_CONVERT_UNIT} are:
 @itemize @w{}
-@item @code{'big_endian'}  Do all unformatted I/O in big_endian mode.
+@item @code{'big_endian'}  Do all unformatted I/O in big_endian mod.e
 @item @code{'little_endian;native:10-20,25'}  Do all unformatted I/O
 in little_endian mode, except for units 10 to 20 and 25, which are in
 native format.
 @item @code{'10-20'}  Units 10 to 20 are big-endian, the rest is native.
+@item @code{'big_endian,r16_ibm'} Do all unformatted I/O in big-endian
+mode and use IBM long double for output of @code{REAL(KIND=16)} values.
 @end itemize
 
 Setting the environment variables should be done on the command
@@ -1736,7 +1747,7 @@ the @code{CONVERT} specifier on the @code{OPEN} statement.
 @xref{GFORTRAN_CONVERT_UNIT}, for an alternative way of specifying
 the data format via an environment variable.
 
-Valid values for @code{CONVERT} are:
+Valid values for @code{CONVERT} on most systems are:
 @itemize @w{}
 @item @code{CONVERT='NATIVE'} Use the native format.  This is the default.
 @item @code{CONVERT='SWAP'} Swap between little- and big-endian.
@@ -1745,6 +1756,15 @@ for unformatted files.
 @item @code{CONVERT='BIG_ENDIAN'} Use the big-endian representation for
 unformatted files.
 @end itemize
+On POWER systems which support @option{-mabi=ieeelongdouble},
+there are additional options, which can be combined with the others
+with commas. Those are
+@itemize @w{}
+@item @code{CONVERT='R16_IEEE'} Use IEEE 128-bit format for
+@code{REAL(KIND=16)}.
+@item @code{CONVERT='R16_IBM'} Use IBM @code{long double} format for
+real@code{REAL(KIND=16)}.
+@end itemize
 
 Using the option could look like this:
 @smallexample
diff --git a/gcc/fortran/invoke.texi b/gcc/fortran/invoke.texi
index 5c7501a28b1..c0932f6cd70 100644
--- a/gcc/fortran/invoke.texi
+++ b/gcc/fortran/invoke.texi
@@ -1435,10 +1435,20 @@ These options affect the runtime behavior of programs compiled with GNU Fortran.
 @item -fconvert=@var{conversion}
 @opindex @code{fconvert=}@var{conversion}
 Specify the representation of data for unformatted files.  Valid
-values for conversion are: @samp{native}, the default; @samp{swap},
-swap between big- and little-endian; @samp{big-endian}, use big-endian
-representation for unformatted files; @samp{little-endian}, use little-endian
-representati

[patch, wwwdocs] Mention POWER IEEE128 changes for gcc 12

[Thomas Koenig via Fortran]

Hi,

the attached patch documents the support for IEEE long double for
Fortran.  OK?  Suggestions for better wording?

Best regards

Thomas


Mention support for IEEE 128-bit long double for Fortran.

* htdocs/gcc-12/changes.html: Mention support for IEEE
128-bit long double for Fortran.diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
index e9f132c0..083d713e 100644
--- a/htdocs/gcc-12/changes.html
+++ b/htdocs/gcc-12/changes.html
@@ -497,6 +497,14 @@ function Multiply (S1, S2 : Sign) return Sign is
 conforming to the Fortran 2018 standard.  Previous versions
 used OPERATOR which conforms to TS 18508.
   
+  
+On POWER systems which support it, -mabi=ieeelongdouble
+now uses IEEE 128-bit for REAL(KIND=16).
+R16_IBM and R16_IEEE have been added to the
+-fconvert option, the CONVERT specifyer of
+the OPEN statement and the GFORTRAN_CONVERT_UNIT
+environment variable.
+  
 
 
 

Re: [patch, fortran, doc] Mention new CONVERT options for POWER

[Thomas Koenig via Fortran]

On 28.04.22 19:17, Bernhard Reutner-Fischer wrote:

ISTM that this should be s/mod.e/mode./ ?


Yep, fixed as obvious and simple on trunk with
r13-49-g4a8b45e8bc8246bd141dad65f571a3e0cc499c6b .

OK for backport to gcc-12? (This is both extremely safe and
not particularly important :-)

Best regards

Thomas

*ping* [patch, wwwdocs] Mention POWER IEEE128 changes for gcc 12

[Thomas Koenig via Fortran]

the attached patch documents the support for IEEE long double for
Fortran.  OK?  Suggestions for better wording?


I'd like to get this in before the gcc12 release.  It would also
qualify as obviously correct, I think :-) so I'll commit this
on Sunday unless there are any objections.

Patch at

https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593780.html

Best regards

Thomas

Re: *ping* [patch, wwwdocs] Mention POWER IEEE128 changes for gcc 12

[Thomas Koenig via Fortran]

Hi Mikael,


OK in any case.  Anything is better than nothing.


Here is what I committed, with one final tweak.

Thanks!

Best regards

Thomas

--- a/htdocs/gcc-12/changes.html
+++ b/htdocs/gcc-12/changes.html
@@ -501,6 +501,15 @@ function Multiply (S1, S2 : Sign) return Sign is
 conforming to the Fortran 2018 standard.  Previous versions
 used OPERATOR which conforms to TS 18508.
   
+  
+On POWER systems which support it, the 
-mabi=ieeelongdouble

+option now selects the IEEE 128-bit floating point format
+for REAL(KIND=16).
+R16_IBM and R16_IEEE have been added to the
+-fconvert option, the CONVERT specifyer of
+the OPEN statement and the 
GFORTRAN_CONVERT_UNIT

+environment variable.
+  
 

Re: [PATCH] Fortran: check POS and LEN arguments simplifying bit intrinsics [PR105986]

[Thomas Koenig via Fortran]

Hi Harald,


we need to check the POS (and LEN) arguments of bit intrinsics
when simplifying, e.g. when used in array constructors.
Otherwise we ICE.  Found by Gerhard.

The fix is straightforward, see attached.

Regtested on x86_64-pc-linux-gnu.  OK for mainline?


OK.

Thanks for the patch!

Regards

Thomas

Re: [PATCH 6/8] fortran: use grep -F instead of fgrep

[Thomas Koenig via Fortran]

Hi,


On Fri, 2022-06-24 at 13:13 +0200, Bernhard Reutner-Fischer wrote:


-   if $(SHELL) -c 'install-info --version | sed 1q | fgrep -s -v -i debian' 
>/dev/null 2>&1; then \
+   if $(SHELL) -c 'install-info --version | sed 1q | grep -F -s -v -i debian' 
>/dev/null 2>&1; then \
   echo " install-info --delete --info-dir=$(DESTDIR)$(infodir) 
$(DESTDIR)$(infodir)/gfortran.info"; \
   install-info --delete --info-dir=$(DESTDIR)$(infodir) 
$(DESTDIR)$(infodir)/gfortran.info || : ; \
 else : ; fi; \


I'd replace -s >/dev/null 2>&1 with -q while at it.

But why is -F used here in the first place?
I do not see much in debian that can be interpreted as a regex?


I'm not sure.  It was there since 2004.  Perhaps the author thinks fgrep
may save several CPU cycles :).  I'll just use a plain grep in PATCH v2.

Rainer: do you have some idea about the availability of "-q" on
different hosts?  If you agree I'll use it instead of -s > /dev/null
too.


Is there any particular reason why we should not use the result of
AC_PROG_FGREP ?  AC_PROG_GREP should also work.

Re: [PATCH] Fortran: handle explicit-shape specs with constant bounds [PR105954]

[Thomas Koenig via Fortran]

Hello Harald,


after simplification of constant bound expressions of an explicit
shape spec of an array, we need to ensure that we never obtain
negative extents.  In some cases this did happen, and we ICEd
as we hit an assert that this should never happen...

The original testcase by Gerhard exhibited this for sizeof()
of a derived type with an array component, but the issue is
more fundamental and affects other intrinsics during
simplification.

A straightforward solution "fixes up" the upper bound in the
shape spec when it is known to be below lower bounds minus one.

Regtested on x86_64-pc-linux-gnu.  OK for mainline?


OK.  Thanks for the patch!

Regards

Thomas

Re: [PATCH] Fortran: fix simplification of INDEX(str1,str2) [PR105691]

[Thomas Koenig via Fortran]

Hello Harald,


compile time simplification of INDEX(str1,str2,back=.true.) gave wrong
results.  Looking at gfc_simplify_index, this appeared to be close to
a complete mess, while the runtime library code - which was developed
later - was a relief.

The solution is to use the runtime library code as template to fix this.
I took the opportunity to change string index and length variables
in gfc_simplify_index to HOST_WIDE_INT.

Regtested on x86_64-pc-linux-gnu.  OK for mainline?

As this is a wrong-code issue, would this qualify for backports to
open branches?


OK for both.

Thanks for the patch!


Best regards

Thomas

Re: [RFC] fortran: restore array indexing for all descriptor arrays [PR102043]

[Thomas Koenig via Fortran]

Hi Mikael,


Feel free to comment, do we need this?


Thanks for taking this on.

One thought: If we have to bite the bullet and break the ABI, why not go
all the way and use the C descriptors in ISO_Fortran_binding.h as
gfortran's native format?

Best regards

Thomas

Re: Inquiry: Country of Origin for gfortran

[Thomas Koenig via Fortran]

Hi Cynthia,

> Hello, my name is Cynthia and I am a Supply Chain Risk Management
> Analyst at NASA. NASA is currently conducting a supply chain
> assessment of gfortran. As stated in Sections 208 and 514 of the
> Consolidated Appropriations Act, 2022, Public Law 117-103,
> enacted March 15, 2022, a required step of our process is to
> verify the Country of Origin (CoO) information for the
> product (i.e., the country where the products were developed,
> manufactured, and assembled.)

> As gfortran is open source, we understand that this inquiry is
> not directly applicable, as contributions may be made from
> individuals from around the world. In this case, NASA is
> interested in confirming the following information:

> 1.  Is there an organization which sponsors/publishes the project, or 
> a primary developer who audits the code for potential 
vulnerabilities, > errors, or malicious code? Y/N


gfortran is not an independent project, it is part of the Gnu Compiler
Collection, https://gcc.gnu.org/ .  As such, any evaluation you
may already have made of gcc also should also apply to gfortran,
and I am also addressing this mail to the gcc mailing list, where
it is more appropriate, especially since I personally am unclear
about the current relationship with the Free Software Foundation.

Regarding gfortran specifically:  Code changes are reviewed by
the individuals listed in the file

https://gcc.gnu.org/git/?p=gcc.git;a=blob_plain;f=MAINTAINERS;hb=HEAD

(where you can search for Fortran).

> 2.  Does gfortran have an overseeing organization or individual
>   along these lines? Y/N

See my previous reply.

> 1.  If so, please provide the name of the organization and country
> they are established in

> If the information above is unknown or cannot be provided, we
> request that you provide the country or list of countries where
> the majority of contributions originate from to satisfy Sections
> 208 and 514 of the Consolidated Appropriations Act, 2022, Public
> Law 117-103, enacted March 15, 2022.

Main contributions to gfortran, i.e. the Fortran front end to gcc and
its supporting library, came (in no particular order) from the UK, the
US, France, Finland, Germany, the Netherlands and the Czech Republic.
Up to 2006, there were also some contributors from China.

Best regards

Thomas

Re: [PATCH, v3] Fortran: detect blanks within literal constants in free-form mode [PR92805]

[Thomas Koenig via Fortran]

Hi Harald,


This introduces the helper function gfc_match_next_char, which is
your second option.


I would be a little bit concerned about compilation times
with the additional function call overhead.

The function is used only in one place; would it make
sense to put it into primary.cc and declare it static?

Best regards

Thomas

Re: [PATCH] libfortran: Fix up boz_15.f90 on powerpc64le with -mabi=ieeelongdouble [PR106079]

[Thomas Koenig via Fortran]

Hi Jakub,


The boz_15.f90 test FAILs on powerpc64le-linux when -mabi=ieeelongdouble
is used (either default through --with-long-double-format=ieee or
when used explicitly).
The problem is that the read/write transfer routines are called with
BT_REAL (or BT_COMPLEX) type and kind 17 which is magic we use to say
it is the IEEE quad real(kind=16) rather than the IBM double double
real(kind=16).  For the floating point input/output we then handle kind
17 specially, but for B/O/Z we just treat the bytes of the floating point
value as binary blob and using 17 in that case results in unexpected
behavior, for write it means we don't estimate right how many chars we'll
need and print  etc. rather than what we should, and
even with explicit size we'd print one further byte than intended.
For read it would even mean overwriting some unrelated byte after the
floating point object.

Fixed by using 16 instead of 17 in the read_radix and write_{b,o,z} calls.

Bootstrapped/regtested on powerpc64le-linux, ok for trunk / 12.2?


OK for both.

Best regards

Thomas

Re: [PATCH] libgfortran: Use __builtin_issignaling in libgfortran

[Thomas Koenig via Fortran]

Hi Jakub,


The following patch makes use of the new __builtin_issignaling,
so it no longer needs the fallback implementation and can use
the builtin even where glibc provides the macro.

Bootstrapped/regtested on x86_64-linux, i686-linux, powerpc64le-linux
and powerpc64le-linux, ok for trunk?


OK. Can you mention PR 105105 in the ChangeLog when you commit?

Thanks for the patch!

Best regards

Thomas

Re: [PATCH] Fortran: Add IEEE_SIGNBIT and IEEE_FMA functions

[Thomas Koenig via Fortran]

Hi FX,


Maybe the ping is a bit early, as you know I’m not very active anymore, so I do 
not know what are the current policies. In particular, how much leeway do I 
have to commit the patch if there is no comment from another maintainer?

I am fairly confident about the code, because I wrote the original IEEE 
implementation so I know it very well. I believe it would probably be better to 
commit this and have it tested on mainline, that wait for too long. I intend to 
submit further patches and improvements in this area, once those are merged.



Looks good in principle.

Just a couple of remarks:

Both of these functions are new with Fortran 2018, could you add
a standards version check?

And, more general: I don't think we document which part of the IEEE
arithmetic we support. It might be a good idea to add that to the manual
(but not for this patch).

So, OK with the version check.

Best regards

Thomas

Re: [PATCH 09/10] fortran: Support clobbering of variable subreferences [PR88364]

[Thomas Koenig via Fortran]

Hi Mikael,


This adds support for clobbering of partial variable references, when
they are passed as actual argument and the associated dummy has the
INTENT(OUT) attribute.
Support includes array elements, derived type component references,
and complex real or imaginary parts.

This is done by removing the check for lack of subreferences, which is
basically a revert of r9-4911-gbd810d637041dba49a5aca3d085504575374ac6f.
This removal allows more expressions than just array elements,
components and complex parts, but the other expressions are excluded by
other conditions: substrings are excluded by the check on expression
type (CHARACTER is excluded), KIND and LEN references are rejected by
the compiler as not valid in a variable definition context.

The check for scalarness is also updated as it was only valid when there
was no subreference.


First, thanks a lot for digging into this subject. I have looked through
the patch series, and it looks very good so far.

I have a concern about this part, though.  My understanding at the
time was that it is not possible to clobber an individual array
element, but that this clobbers anything off the pointer that this
is based on.

So,

  integer, dimension(3) :: a

  a(1) = 1
  a(3) = 3
  call foo(a(1))

would also invalidate the store to a(3).  Is my understanding correct?
If so, I think this we cannot revert that patch (which was introduced
because of a regression).

Best regards

Thomas

Re: [PATCH 09/10] fortran: Support clobbering of variable subreferences [PR88364]

[Thomas Koenig via Fortran]

On 18.09.22 11:10, Mikael Morin wrote:

Le 18/09/2022 à 08:12, Richard Biener a écrit :
On Sat, Sep 17, 2022 at 9:33 PM Mikael Morin  
wrote:


Le 17/09/2022 à 19:03, Thomas Koenig via Fortran a écrit :


I have a concern about this part, though.  My understanding at the
time was that it is not possible to clobber an individual array
element, but that this clobbers anything off the pointer that this
is based on.


Well, we need the middle-end guys to give a definitive answer on this
topic, but I think it would be a very penalizing limitation if that was
the case.  I have assumed that the clobber spanned the value it was
applied on, neither more nor less, so just the array element in case of
array elements.


There is IL verification that the LHS of a CLOBBER is either
a declaration or a pointer dereference, no array or component
selection is allowed there.  Now, nothing should go wrong here,
but we might eventually just drop those CLOBBERs or ICE if
we frontend hands us an "invalid" one.



Obviously I have assumed too much here; it's probably best to drop this 
patch.


Probably, yes.

It is unfortunate as there is some desirable behavior within reach here. 


I think some of the desired behavior can still be salvaged.  For
example, for

  subroutine foo(a,n)
integer :: n
integer, dimension(n), intent(in) :: n

...

  subroutine bar(a)
integer, intent(out) :: a

...

  integer :: a(3)

  call foo(a,3)
  call foo(a(1),3)

clobbers for the whole array can still be generated, but not for

  call foo(a(2),2)

so one would have to look at the lower bound.

For this case, it would be helpful to clobber a range a(2:), but that
is a wishlist item for the future ;-)

What is unsafe, currently, is

  call bar(a(1))

Best regards

Thomas

Re: [PATCH 09/10] fortran: Support clobbering of variable subreferences [PR88364]

[Thomas Koenig via Fortran]

On 19.09.22 22:50, Mikael Morin wrote:

Le 19/09/2022 à 21:46, Harald Anlauf a écrit :

Am 18.09.22 um 22:55 schrieb Mikael Morin:

Le 18/09/2022 à 20:32, Harald Anlauf a écrit :


Assumed shape will be on the easy side,
while assumed size likely needs to be excluded for clobbering.


Isn’t it the converse that is true?
Assumed shape can be non-contiguous so have to be excluded, but assumed
size are contiguous, so valid candidates for clobbering. No?


I really was referring here to *dummies*, as in the following example:

program p
   integer :: a(4)
   a = 1
   call sub (a(1), 2)
   print *, a
contains
   subroutine sub (b, k)
 integer, intent(in)  :: k
 integer, intent(out) :: b(*)
!   integer, intent(out) :: b(k)
 if (k > 2) b(k) = k
   end subroutine sub
end program p

Assumed size (*) is just a contiguous hunk of memory of possibly
unknown size, which can be zero.  So you couldn't set a clobber
for the a(1) actual argument.

Couldn't you clobber A entirely?  If no element of B is initialized in 
SUB, well, A has undefined values on return from SUB.  That's how 
INTENT(OUT) works.


Yes, I think so - you are passing the starting element of an array
to an assumed-size array via storage association rules.

It has to be an explicit interface, of course, otherwise it is
unclear if an array or an array element is passed.

Best regards

Thomas

Re: [PATCH 09/10] fortran: Support clobbering of variable subreferences [PR88364]

[Thomas Koenig via Fortran]

Hi Harald,


I think I understand much of what is said, but I feel that I do
not really understand what *clobber* means for the different
beasts we are discussing (although I have an impression of what
it means for a scalar object).


Obviously, "clobber" means taking a big stick and hitting the beast
in question over the head with it :-)

More seriously: My understanding of a clobber it is a hint to
the middle end that the value in question will not be used,
and that operations leading to this value can be removed,
unless they are used otherwise.

If I'm wrong or imprecise, I'm sure somebody will correct me :-)

Regards

Thomas

Re: Proxy ping [PATCH] Fortran: Fix automatic reallocation inside select rank [PR100103]

[Thomas Koenig via Fortran]

Hello Harald,


the patch for this PR was submitted for review by Jose here:

   https://gcc.gnu.org/pipermail/fortran/2021-April/055934.html

but unfortunately was never reviewed.

I verified that it works on mainline and x86_64-pc-linux-gnu,
and I think that it is fine.

Although the above mail suggests that there is a dependency
on the fix for another PR with a rather lengthy patch,
it appears that this is no longer the case.  It might be
that the fix for PR100245 (another reallocation issue)
already did the necessary job.

So OK for mainline?


Looks good to me. Thanks for picking up these patches!

Best regards

Thomas

[patch, RFC. Fortran] Some clobbering for INTENT(OUT) arrays

[Thomas Koenig via Fortran]

Hi,

following Mikael's recent patch series, here is a first idea
of what extending clobbering to arrays wold look like.

The attached patch works for a subset of cases, for example

program main
  implicit none
  interface
subroutine foo(a)
  integer, intent(out) :: a(*)
end subroutine foo
  end interface
  integer, dimension(10) :: a
  call foo(a)
end program main

and

program main
  implicit none
  interface
subroutine foo(a)
  integer, intent(out) :: a(:)
end subroutine foo
  end interface
  integer, dimension(10) :: a
  a(1) = 32
  a(2) = 32
  call foo(a)
end program main

but it does not cover cases like an assumed-size array
being handed down to an INTENT(OUT) argument.

What happens if the

+ if (!sym->attr.allocatable && !sym->attr.pointer
+ && !POINTER_TYPE_P (TREE_TYPE 
(sym->backend_decl)))



part is taken out is that the whole descriptor can be clobbered in
such a case, which is of course not what is wanted.

I am a bit stuck of how to generate a reference to the first element
of the array (really, just dereferencing the data pointer)
in the most elegant way.  I am currently leaning towards
building a gfc_expr, which should work, but would be less
than elegant.

So, anything more elegant at hand?

Best regards

Thomasdiff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index 4f3ae82d39c..bbb00f90a77 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -43,6 +43,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "gimplify.h"
 #include "tm.h"		/* For CHAR_TYPE_SIZE.  */
 
+#include "debug.h"
 
 /* Calculate the number of characters in a string.  */
 
@@ -5981,7 +5982,6 @@ post_call:
 gfc_add_block_to_block (&parmse->post, &block);
 }
 
-
 /* Generate code for a procedure call.  Note can return se->post != NULL.
If se->direct_byref is set then se->expr contains the return parameter.
Return nonzero, if the call has alternate specifiers.
@@ -6099,6 +6099,7 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
 {
   bool finalized = false;
   tree derived_array = NULL_TREE;
+  tree clobber_array = NULL_TREE;
 
   e = arg->expr;
   fsym = formal ? formal->sym : NULL;
@@ -6896,10 +6897,23 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
 	 fsym->attr.pointer);
 		}
 	  else
-		/* This is where we introduce a temporary to store the
-		   result of a non-lvalue array expression.  */
-		gfc_conv_array_parameter (&parmse, e, nodesc_arg, fsym,
-	  sym->name, NULL);
+		{
+		  /* This is where we introduce a temporary to store the
+		 result of a non-lvalue array expression.  */
+		  gfc_conv_array_parameter (&parmse, e, nodesc_arg, fsym,
+	sym->name, NULL);
+		  if (fsym && fsym->attr.intent == INTENT_OUT
+		  && gfc_full_array_ref_p (e->ref, NULL))
+		{
+		  gfc_symbol *sym = e->symtree->n.sym;
+		  if (!sym->attr.allocatable && !sym->attr.pointer
+			  && !POINTER_TYPE_P (TREE_TYPE (sym->backend_decl)))
+			clobber_array
+			  = gfc_build_array_ref (e->symtree->n.sym->backend_decl,
+		 build_int_cst (size_type_node, 0),
+		 NULL_TREE, true, NULL_TREE);
+		}
+		}
 
 	  /* If an ALLOCATABLE dummy argument has INTENT(OUT) and is
 		 allocated on entry, it must be deallocated.
@@ -6952,6 +6966,13 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
    tmp, build_empty_stmt (input_location));
 		  gfc_add_expr_to_block (&se->pre, tmp);
 		}
+
+	  if (clobber_array != NULL_TREE)
+		{
+		  tree clobber;
+		  clobber = build_clobber (TREE_TYPE(clobber_array));
+		  gfc_add_modify (&clobbers, clobber_array, clobber);
+		}
 	}
 	}
   /* Special case for an assumed-rank dummy argument. */

Re: Optimization of spread

[Thomas Koenig via Fortran]

Hi,

Mikael beat me to a mail saying essentially the same things by
a few minutes, so I'm just adding a few details.


There are two places where inlining can be done:
  * In front-end passes where the parsed fortran code is rewritten 
before generating the intermediary code for the optimizers.  Thomas 
König can help you there.


I most certainly can.  frontend-passes.cc contains, among other
functionality, a function to inline MATMUL for small sizes, so
much of the infrastructure is already there.

  * Directly in the code generation for the optimizers.  It is (much) 
more complex but can avoid the need for temporaries.  I can help you there.


Some links about our development process and conventions:
https://gcc.gnu.org/contribute.html
https://gcc.gnu.org/git.html


And, if you're into hacking gfortran, some starting pointers are at
https://gcc.gnu.org/wiki/GFortranHacking . But always free feel to ask!

Best regards

Thomas

Re: adding attributes

[Thomas Koenig via Fortran]

On 04.11.22 21:59, Bernhard Reutner-Fischer via Fortran wrote:

And not sure if fellow gfortraners would accept this attribute
target_clones in there in the first place..


It might actually be useful.  Is there any change about
the calling sequence or anything else that should be visible
in a Fortran module or the calling sequence?

Thomas

Re: adding attributes

[Thomas Koenig via Fortran]

Hi Bernhard,


If you think that we want to add support for that attribute, i can
submit a proper patch. Just let me know please.


I think this attribute makes sense, especially if people want to
compile once and then port to different architectures.

So, yes please submit a patch, if you would be so kind :-)

Best regards

Thomas

Re: [PATCH] Fortran: error recovery on associate with bad selector [PR107577]

[Thomas Koenig via Fortran]

Hi Harald,


please find attached an obvious patch by Steve for a technical
regression that resulted from improvements in error recovery
of bad uses of associate.

Regtested on x86_64-pc-linux-gnu.

Will commit soon unless there are comments.


Obvious enough, I think.  Thanks!


As a sidenote: the testcase shows that we resolve the associate
names quite often, likely more often than necessary, resulting
in many error messages produced for the same line of code.  In
the present case, each use of the bad name produces two errors,
one where it is used, and one at the associate statement.
That is probably not helpful for the user.


We have an "error" flag in gfc_expr, which we use infrequently to
avoid repetitions of errors.  If an error has already been issued
for an expression, then we could set this.  We would have to be careful
about resetting the error on matching though, so it is probably better
to only use it during resolution.

Best regards

Thomas

Re: Team Collaboration Considerations

[Thomas Koenig via Fortran]

Hi Katherine,


Is there some kind of "getting started" guide?


There's https://gcc.gnu.org/wiki/GFortranHacking which has some
pointers.  It could also use a bit of an update (file names are now
.cc instead of .c :-)

Best regards

Thomas

Re: testsuite under wine

[Thomas Koenig via Fortran]

On 16.12.22 03:20, NightStrike via Fortran wrote:


When I run the testsuite under wine, I'm getting a lot of ANSI escape
sequences.  We had fixed this long ago, but it seems to be back.  Any
idea what I should change in my configuration to have this not happen?


This should probably be fixed properly in some *.exp file, but you can
try setting the GCC_COLORS environment variable to an empty string
before running the test.

Regards

Thomas

Re: testsuite under wine

[Thomas Koenig via Fortran]

On 17.12.22 01:26, NightStrike wrote:

On Fri, Dec 16, 2022 at 1:44 AM Thomas Koenig  wrote:


On 16.12.22 03:20, NightStrike via Fortran wrote:


When I run the testsuite under wine, I'm getting a lot of ANSI escape
sequences.  We had fixed this long ago, but it seems to be back.  Any
idea what I should change in my configuration to have this not happen?


This should probably be fixed properly in some *.exp file, but you can
try setting the GCC_COLORS environment variable to an empty string
before running the test.


That didn't help.  It looks like this is always escape 25h to start
the output and 25l to end it, which I think is turning the cursor on
and off (based on https://en.wikipedia.org/wiki/ANSI_escape_code).  I
apparently fixed this previously by building wine with
--without-curses
(https://www.mail-archive.com/gcc@gcc.gnu.org/msg86366.html), but that
option to wine was removed.  Is there a way to hack this on the Deja
side to ignore the escapes?  Or to tell it to run in a way that makes
wine not emit them?


Truth is, I don't know.

I have included the gcc mailing list in this reply, where more
knowledgeable people can be found :-)

Re: [PATCH v2] libgfortran: Replace mutex with rwlock

[Thomas Koenig via Fortran]

Hi Lipeng,


This patch try to introduce the rwlock and split the read/write to
unit_root tree and unit_cache with rwlock instead of the mutex to
increase CPU efficiency. In the get_gfc_unit function, the percentage
to step into the insert_unit function is around 30%, in most instances,
we can get the unit in the phase of reading the unit_cache or unit_root
tree. So split the read/write phase by rwlock would be an approach to
make it more parallel.


No comment on the code itself, as yet... but I'd like to know how
throroughly you tested it, using which tools, and on which programs.
Did you use valgrind --tool=helgrind or --tool=drd?  Since it is
prone to race conditions, did you also test Fortran's asynchronous I/O?

Best regards

Thomas

Re: Fw: Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

[Thomas Koenig via Fortran]

Hi Paul,

first, thanks for taking on this rather monumental task!


Given the scale of the overall patch, I am beginning to have a lot of
sympathy with Thomas's suggestion that the finalization calls should be
moved to the front end! I will take a quick look to see how easy this would
be to implement.


There is one drawback if you do this in the front end:  There are a few
places where it is not possible to add code without running into ICEs
later, like WHERE/ELSEWHERE, which is why fronend_passes.cc keeps track
of these things.

Best regards

Thomas

[patch, fortran] Fix common subexpression elimination with IEEE rounding (PR108329)

[Thomas Koenig via Fortran]

Hello world,

this patch fixes Fortran's handling of common subexpression elimination
across ieee_set_rouding_mode calls.  It does so using a rather big
hammer, by issuing a memory barrier to force reload from memory
(and thus a recomputation).

This is a rather big hammer, so if there are more elegant ways
to fix it, I am very much open to suggestions.

If PR 34678 is fixed, then this solution can also be applied here.

OK for trunk?  How do you feel about a backport?

Best regards

Thomas

Add memory barrier for calls to ieee_set_rounding_mode.

gcc/fortran/ChangeLog:

PR fortran/108329
* trans-expr.cc (trans_memory_barrier): New functions.
(gfc_conv_procedure_call): Insert memory barrier for
ieee_set_rounding_mode.

gcc/testsuite/ChangeLog:

PR fortran/108329
* gfortran.dg/rounding_4.f90: New test.diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index 4f3ae82d39c..29be7804e11 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -5981,6 +5981,20 @@ post_call:
 gfc_add_block_to_block (&parmse->post, &block);
 }
 
+/* Helper function - generate a memory barrier.  */
+
+static tree
+trans_memory_barrier (void)
+{
+  tree tmp;
+
+  tmp = gfc_build_string_const (sizeof ("memory"), "memory");
+  tmp = build5_loc (input_location, ASM_EXPR, void_type_node,
+		gfc_build_string_const (1, ""), NULL_TREE, NULL_TREE,
+		tree_cons (NULL_TREE, tmp, NULL_TREE), NULL_TREE);
+  ASM_VOLATILE_P (tmp) = 1;
+  return tmp;
+}
 
 /* Generate code for a procedure call.  Note can return se->post != NULL.
If se->direct_byref is set then se->expr contains the return parameter.
@@ -7692,6 +7706,19 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
   else
 conv_base_obj_fcn_val (se, base_object, expr);
 
+  /* FIXME: Special handing of ieee_set_rounding_mode - we clobber
+ memory here to avoid common subexpression moving code past calls
+ to ieee_set_rounding_mode.  This should only be done for
+ floating point, but currently gcc offers no other possibility.
+ See PR 108329.  */
+
+  if (sym->from_intmod == INTMOD_IEEE_ARITHMETIC
+  && strcmp (sym->name, "ieee_set_rounding_mode") == 0)
+{
+  tree tmp = trans_memory_barrier ();
+  gfc_add_expr_to_block (&post, tmp);
+}
+
   /* If there are alternate return labels, function type should be
  integer.  Can't modify the type in place though, since it can be shared
  with other functions.  For dummy arguments, the typing is done to
diff --git a/gcc/testsuite/gfortran.dg/rounding_4.f90 b/gcc/testsuite/gfortran.dg/rounding_4.f90
new file mode 100644
index 000..e8799da67dc
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/rounding_4.f90
@@ -0,0 +1,31 @@
+! { dg-do run }
+module y
+  implicit none
+  integer, parameter :: wp = selected_real_kind(15)
+contains
+  subroutine foo(a,b,c)
+use ieee_arithmetic
+real(kind=wp), dimension(4), intent(out) :: a
+real(kind=wp), intent(in) :: b, c
+type (ieee_round_type), dimension(4), parameter :: mode = &
+ [ieee_nearest, ieee_to_zero, ieee_up, ieee_down]
+call ieee_set_rounding_mode (mode(1))
+a(1) = b + c
+call ieee_set_rounding_mode (mode(2))
+a(2) = b + c
+call ieee_set_rounding_mode (mode(3))
+a(3) = b + c
+call ieee_set_rounding_mode (mode(4))
+a(4) = b + c
+  end subroutine foo
+end module y
+
+program main
+  use y
+  real(kind=wp), dimension(4) :: a
+  call foo(a,0.1_wp,0.2_wp)
+  if (a(1) <= a(2)) stop 1
+  if (a(3) <= a(4)) stop 2
+  if (a(1) /= a(3)) stop 3
+  if (a(2) /= a(4)) stop 4
+end program main

Re: Fw: Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

[Thomas Koenig via Fortran]

Hi Paul,


What causes the ICES?


There were a few PRs along this line.  Usually, it is the
front-end pass inserting code which is illegal Fortran, and
the later stages then asserting that it doesn't happen.

Here are a few examples:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50690 (function
elimination in OMP Workshare)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50564 (forall)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69154 (matmul
in where)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69742 (in
associate).

If you want to do the finalization of function results via
a front end pass, creating a variable and then assigning it
from within these constructs can cause these kinds of problems.

Best regards

Thomas

Re: [patch, fortran] Fix common subexpression elimination with IEEE rounding (PR108329)

[Thomas Koenig via Fortran]

Hi Richard,


Am 08.01.2023 um 14:31 schrieb Paul Richard Thomas via Fortran 
:

Hi Thomas,

Following your off-line explanation that the seemingly empty looking
assembly line forces an effective reload from memory, all is now clear.


It’s not a full fix (for register vars) and it’s ‚superior‘ to the call itself 
only because asm handling is implemented in a rather stupid way in the Alias 
oracle.  So I don’t think this is a „fix“ at all.


There are no register variables in Fortran, this is Fortran FE only,
and it is a fix in the sense that correct code is no longer miscompiled.

There's a FIXME in the code pointing to the relevant PR precisely
because I think that this is less than elegant (as do you, obviously).
Do you have other suggestions how to implement this?  If PR 34678
is solved, this would probably provide a mechanism that we could
simply re-use.

Best regards

Thomas

Re: [patch, fortran] Fix common subexpression elimination with IEEE rounding (PR108329)

[Thomas Koenig via Fortran]

Hi Richard,


There is no reliable way to get this correct at the moment and if there
were good and easy ways to get this working they'd be implemented already.


OK, I then withdraw the patch (and have unassigned myself from the PR).

Best regards

Thomas

Re: nvptx, libgfortran: Switch out of "minimal" mode

[Thomas Koenig via Fortran]

Hi Thomas,


On 2023-01-20T22:04:02+0100, I wrote:

We've been (t)asked to enable (portions of) GCC/Fortran I/O for nvptx
offloading, which means building a normal (non-'LIBGFOR_MINIMAL')
configuration of libgfortran.


This is achieved by 'nvptx, libgfortran: Switch out of "minimal" mode',
see attached, again based on WIP work by Andrew Stubbs.  This I've just
pushed to devel/omp/gcc-12 branch in
commit c7734c6fbb5513b4da6306de7bc85de9b8547988, and would like to push
to master branch once other pending GCC patches have been accepted.


Looks good to me.

Regards

Thomas

Re: [PATCH] Fortran: fix NULL pointer dereference in gfc_check_dependency [PR108502]

[Thomas Koenig via Fortran]

Hi Harald,


the code in the PR demonstrates that dependency checking in the
frontend optimization was not recovering well from invalid code,
leading to a NULL pointer dereference.  An easy and really obvious
fix.

Regtested on x86_64-pc-linux-gnu.  OK for mainline?


Yes indeed (and I would not have minded if you had indeed
committed it as obvious and simple).

Thanks for the patch!

Best regards

Thomas

Re: Buildbot (Sourceware): gcc - failed configure (failure) (master)

[Thomas Koenig via Fortran]

On 30.01.23 14:52, Mark Wielaard wrote:

Hi Steve,

On Sun, 2023-01-29 at 22:27 -0800, Steve Kargl via Gcc wrote:

Please remove the skull and cross bones in the subject line.


That is the default "hazard symbol" buildbot uses if a build turns from
success to failure. If you have a better suggestion you might want to
contact upstream https://buildbot.net/ We'll pick up the new default
when we'll upgrade.

Or if you think we should use a custom email template:
https://docs.buildbot.net/latest/manual/configuration/report_generators/formatter.html
You can provide a patch to build...@sourceware.org.
The code for our instance can be found here:
https://sourceware.org/git/builder.git


I usually put e-mails with such unicode characters into my spam folder
automatically.

If that's what you want, that is fine with me.

Regards

Thomas

Re: [PATCH] Fortran: improve checking of character length specification [PR96025]

[Thomas Koenig via Fortran]

Hi Harald,


the attached patch fixes an ICE on invalid (non-integer)
specification expressions for character length in function
declarations.  It appears that the error handling was
already in place (mostly) and we need to essentially
prevent run-on errors.

Regtested on x86_64-pc-linux-gnu.  OK for mainline?

As a very minor matter of style, you might want to write

  function_result_typed = check_function_result_typed ();

instead of

  if (check_function_result_typed ())
function_result_typed = true;

OK either way.


The PR is marked as a 10/11/12/13 regression, so I would
like to backport this as far as it seems reasonable.


Also OK.

Thanks for the patch!

Best regards

Thomas

Re: [patch, libgfortran] Initailize some variable to get rid of nuisance warnings.

[Thomas Koenig via Fortran]

Hi Jerry,


I should have clarified in my posts that the warnings are on the use of 
sstride[0], mstride[0] or both.



In a sense it is a 
regression. It showed up when builds started to use -Wmaybe-unitialized.


I think this is OK for trunk now, and backport for up to whenever
-Wmaybe-uninitialized was introduced into the build.

The "regression-only" rule is mostly motivated by not introducing
new bugs (and for Fortran, we have a bit of leeway), and I would
be hard to pressed to think of a patch less likely to introduce
regressions.

Thanks for the patch!

Best regards

Thomas

Re: [Patch, fortran] PR37336 finalization

[Thomas Koenig via Fortran]

Paul,

first of all, thank you very much indeed for the hard work you put into
this!  This is a great step for gfortran.


I can hurry this along to get the patch
into 13-branch or I can wait until 14-branch opens.


Personally, I think that this fixes so many bugs, and makes
the compiler so much better, that I would prefer having it
in gcc-13.  Finalization was only of very limited use before,
and the risk of meaningful regressions (short of a build
failure) is therefore very low.

Again, thanks a lot!

Best regards

Thomas

Re: F77 indexed file support

[Thomas Koenig via Fortran]

Hi Roland,


  210  OPEN (UNIT=K_DRAW_CHAN,
  1    FILE=DRAWING_DATA,
  2    STATUS='OLD',
  3    ORGANIZATION='INDEXED',


I'd never heard of that one up to now.


  4    ACCESS='KEYED',
  5    RECORDTYPE='FIXED',
  6    FORM='UNFORMATTED',
  7    RECL=K_DRAWING_RECORD_SIZE/4,
  8    CARRIAGECONTROL='FORTRAN',
  9    KEY=(1:8:CHARACTER),
  1    DISP='KEEP',
  2    IOSTAT=L_DRAW_ERR,
  3    ERR=999)

The ORGANIZATION='INDEXED' is key.

GnuCOBOL

https://gnucobol.sourceforge.io/

uses the BerkleyDB (sp?) library so the standard COBOL indexed file 
support from the big computers can at least be mimicked.


I'm searching everywhere and I cannot find Gnu Fortran (any flavor) 
having an ORGANIZATION clause in the OPEN().


ORGANIZATION is not an extension that gfortran supports.
ifort, which traces its lineage back to VMS Fortran, supports
ORGANIZATION, but not 'INDEXED', according to

https://www.intel.com/content/www/us/en/develop/documentation/fortran-compiler-oneapi-dev-guide-and-reference/top/language-reference/file-operation-i-o-statements/open-statement-specifiers/open-organization-specifier.html

This is likely a Fortran interface to a VMS speciality; the older
operating systems had stuff like that.  UNIX did away with all
the record-orientation (I also remember VSAM and ISAM data sets
on old IBM mainframes) and UNIX and derivatives, and Windows, now
just offers the "stream of bytes" model.

So, if you need the functionality, you will have to implement it
yourself, possibly via a database.

Best regards

Thomas

Re: [Patch, fortran] PR37336 finalization

[Thomas Koenig via Fortran]

Hi Paul,

Last night, I scoped out the work required to get the patch ready to 
commit. Sorting out the testcases will be the main load since they have 
grown "organically". I propose to change over to one test for each 
paragraph of F2018 7.5.6.2/7.5.6.3  and to 
verify them against the other brands. I suspect that this will allow a 
weeding out of the existing tests. It will take me a couple of weeks.


I am a little bit concerned that this might bring us too close to the
release date. We are down to 22 P1 regressions as of now.

Richard, what do you think?

Best regards

Thomas

Re: [Patch, fortran] PR37336 finalization

[Thomas Koenig via Fortran]

On 08.03.23 09:14, Richard Biener wrote:

While Fortran is not considered release critical it would be bad to
break say the build of SPEC CPU 2017 or Polyhedron very late in the
cycle.  I'd lean towards postponing this to early stage1 and eventually
backport it for GCC 13.2 if you would like this feature to be implemented
for GCC 13.


And now comes the problem - no Fortran maintanier has access to SPEC
2017, as far as I know.  The curse of closed-source benchmarks...

How extensive is SPEC using finalization?  My personal guess would be
that it is not used extensively, since gfortran's implementation is
pretty broken at the moment.

Polyhedron we can test, of course, but a grep of the sources shows
that finalization is not used there at all.


But it's of course the Fortran maintainers decision.

Even though Fortran isn't release critical we might ask you to revert
if any such severe problems show up.


Sure.

Best regards

Thomas

Re: [Patch, fortran] PR37336 finalization

[Thomas Koenig via Fortran]

On 08.03.23 15:55, Paul Richard Thomas via Fortran wrote:

As noted below, rnflow.f90 hangs with the unpatched mainline at -O3 but
runs successfully at -O2.


I can confirm that.


I presume that this is a serious regression since it involves optimization?
Which component should I post it against?


Probably against tree-optimization.  If later analysis determines that
it is something else, people will reassign it.

This one probably calls for bisection.

Regards

Thomas

Re: [Patch, fortran] PR37336 finalization

[Thomas Koenig via Fortran]

On 08.03.23 22:35, I wrote:

On 08.03.23 15:55, Paul Richard Thomas via Fortran wrote:

As noted below, rnflow.f90 hangs with the unpatched mainline at -O3 but
runs successfully at -O2.


I can confirm that.

I presume that this is a serious regression since it involves 
optimization?

Which component should I post it against?


Probably against tree-optimization.  If later analysis determines that
it is something else, people will reassign it.

This one probably calls for bisection.


I have submitted this as

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109075 .

Paul, thanks for catching this!

@Richard: Is there a possibility of doing regular Polyhedron runs
at Suse in addition to the SPEC runs?  This could also be interesting.

Best regards

Thomas

Re: [Patch, fortran] PR37336 finalization

[Thomas Koenig via Fortran]

Hi Paul,


-fdefault-integer-8 does indeed fix the problem with 
rnflow.f90 but breaks tfft2.f90, with a type mismatch at lines 36 and 44.


       integer(8), parameter   :: jmul =  843314861  ! multiplicateur
       integer(8), parameter   :: jadd =  453816693  ! constante additive
Does the job and is portable.



I think -frwapv (as suggested by Jakub) would be the better choice.
The problem is the linear congruential pseudo-random number generators
which were much used in earlier times (and are still present in
legacy code), which violate the Fortran standards by assuming silent
truncation.

If a new optimization breaks this (widespread, but illegal) idiom,
maybe the best way to deal with it is to add -frwapv to -std=legacy.

What do you think?

Best regards

Thomas