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

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,

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

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

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

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 th

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

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

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

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

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

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

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: Eithe

Re: [PATCH] Make integer output faster in libgfortran

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=

Re: [PATCH] Make integer output faster in libgfortran

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 l

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

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

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

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

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

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

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

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 correc

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

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

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

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

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

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

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(

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

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 t

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

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

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

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

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

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.

Re: [power-ieee128] RFH: LTO broken

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

Re: [power-ieee128] OPEN CONV

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

Re: [power-ieee128] RFH: LTO broken

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 successfull

Re: [power-ieee128] RFH: LTO broken

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

Re: [power-ieee128] OPEN CONV

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

Re: [power-ieee128] OPEN CONV

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

Re: [power-ieee128] OPEN CONV

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 somethi

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

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 t

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

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

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

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 compl

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

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

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

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.

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 enric

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

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

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]

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

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 an

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

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 l

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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.

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

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 func

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

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]

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

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

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]

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-e

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

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 w

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

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 doubl

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

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 regard

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

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

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

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 conf

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

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! Reg

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

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 \

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

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 exhi

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

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

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

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

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

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

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 de

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

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

Re: [PATCH] libgfortran: Use __builtin_issignaling in libgfortran

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?

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

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

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

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

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

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

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

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 t

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

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

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

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

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

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 subrouti

Re: Optimization of spread

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

Re: adding attributes

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 For

Re: adding attributes

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 b

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

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: th

Re: Team Collaboration Considerations

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

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 pro

Re: testsuite under wine

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

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

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

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

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 imple

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

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 el

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

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 e

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

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‘ t

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

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

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 at

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

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 h

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

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 suggest

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

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

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

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-uninitial

Re: [Patch, fortran] PR37336 finalization

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

Re: F77 indexed file support

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 

Re: [Patch, fortran] PR37336 finalization

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 th

Re: [Patch, fortran] PR37336 finalization

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

Re: [Patch, fortran] PR37336 finalization

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?

Re: [Patch, fortran] PR37336 finalization

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 compo

Re: [Patch, fortran] PR37336 finalization

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

  1   2   3   >