[patch, Fortran] Enable -fwrapv for -std=legacy

Hello world, here's the patch that was discussed. Regression-tested. OK for trunk? Since this appeared only in gcc13, I see no need for a backport. I will also document this in the changes file. Best regards Thomas Set -frapv if -std=legacy is set. Fortran legacy codes sometimes cont

Re: [patch, Fortran] Enable -fwrapv for -std=legacy

Hi Richard, Since this appeared only in gcc13, I see no need for a backport. I will also document this in the changes file. The „problem“ It's a real problem, I am afraid... is latent forever, I’m not sure it’s good to amend the kitchen-sink >std=legacy option with -fwrapv since that has q

[patch, wwwdocs] Mention random number generators in porting_to.html

Hi, Text says it all. OK for web pages? Best regards Thomas Mention issues with integer owerflow for random number generators. This mentions the issues with integer overflow and how to work around them. diff --git a/htdocs/gcc-13/porting_to.html b/htdocs/gcc-13/porting_to.html index

Re: [PATCH] Fortran: procedures with BIND(C) attribute require explicit interface [PR85877]

Hi Harald, the Fortran standard requires an explicit procedure interface in certain situations, such as when they have a BIND(C) attribute (F2018:15.4.2.2). The attached patch adds a check for this. Regtested on x86_64-pc-linux-gnu. OK for mainline? While this fixes the ICE, it misses funct

Re: [PATCH] Fortran: procedures with BIND(C) attribute require explicit interface [PR85877]

Hi Harald, Am 18.03.23 um 19:52 schrieb Thomas Koenig via Gcc-patches: Hi Harald, the Fortran standard requires an explicit procedure interface in certain situations, such as when they have a BIND(C) attribute (F2018:15.4.2.2). The attached patch adds a check for this. Regtested on x86_64-pc

[patch, wwwdocs] Mention finalization

Hi, the sentence below seems a bit short for such a huge undertaking, but I could not think of anything else to day. Tested with "tidy -e". OK for wwwdocs? Best regards Thomas diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html index c8d757b6..a4b71ffa 100644 --- a/

[patch, fortran, doc] Explicitly mention undefined overflow

Here's also an update on the docs to explicitly mention behavior on overflow. Maybe this will reach another 0.05% of users... OK for trunk? Best regards Thomas gcc/fortran/ChangeLog: * gfortran.texi: Mention behavior on overflow. diff --git a/gcc/fortran/gfortran.texi b/gcc/f

Re: [patch, fortran, doc] Explicitly mention undefined overflow

Hi Paul, Yes, that's fine for trunk. I wonder if it is worth being explicit that linear congruential pseudo-random number generators can and do fail at -O3? I don't think we should put this into the docs, because that can change at any time. Maybe into porting_to.html, though (where I have on

Re: [patch, fortran, doc] Explicitly mention undefined overflow

I wrote: Yes, that's fine for trunk. I wonder if it is worth being explicit that linear congruential pseudo-random number generators can and do fail at -O3? I don't think we should put this into the docs, because that can change at any time.  Maybe into porting_to.html, though (where I have

Re: [PATCH, commited] Fortran: remove dead code [PR104321]

On 26.03.23 08:52, Paul Richard Thomas via Fortran wrote: If you will excuse the British cultural reference, that's a Norwegian Blue alright! Good spot. Still pining for the fjords, I gather?

Re: [PATCH] Fix fc-prototypes usage with C_INT64_T and non LP64 Targets.

Hi Andrew, "long long". This was just an oversight and a missing check. Committed as obvious after a bootstrap/test on x86_64-linux-gnu. Thanks! I think this one is obvious enough that it deserves a backport. I've cherry-picked this for gcc12, will do gcc11 tomorrow. Best regards T

Re: [PATCH] Fix fc-prototypes usage with C_INT64_T and non LP64 Targets.

Hi Steve, Hi Andrew, "long long". This was just an oversight and a missing check. Committed as obvious after a bootstrap/test on x86_64-linux-gnu. Thanks! I think this one is obvious enough that it deserves a backport. I've cherry-picked this for gcc12, will do gcc11 tomorrow. The patch

Re: [PATCH v2 4/7] fortran: use grep instead of fgrep

On 10.05.23 21:29, Bernhard Reutner-Fischer via Fortran wrote: On Mon, 27 Jun 2022 14:10:36 +0800 Xi Ruoyao wrote: fgrep has been deprecated in favor of grep -F for a long time, and the next grep release (3.8 or 4.0) will print a warning of fgrep is used. Stop using fgrep so we won't see the w

Re: [PATCH v2] Fortran: Narrow return types [PR78798]

On 14.05.23 14:27, Mikael Morin wrote: (...) @@ -2098,7 +2098,7 @@ ref_same_as_full_array (gfc_ref *full_ref, gfc_ref *ref)   there is some kind of overlap.   0 : array references are identical or not overlapping.  */ -int +bool   gfc_dep_resolver (gfc_ref *lref, gfc_ref *rref, gfc

Re: Advice with finding speed between O2 and O3

Hi Matt, Recently, one of the computing centers I run on updated their > OS. And in that update, the model went from "working with GNU" to "crashing with GNU". No code change on our side, just OS. That sounds suspicious, and points to possible bugs in the code. Hmm... does the upgrade mean

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

Hi Lipeng, May I know any comment or concern on this patch, thanks for your time 😄 Thanks for your patience in getting this reviewed. A few remarks / questions. Which strategy is used in this implementation, read-preferring or write-preferring? And if read-preferring is used, is there a dan

Re: Possible funding of gfortran work

On 26.05.23 23:22, Jerry D via Fortran wrote: Sorry about my messages getting chopped. On 5/25/23 9:34 PM, Jerry DeLisle via Fortran wrote: Hi all, I found this message in my spam folder tonight. Please look.  I also sent a note to Damian on this. Maybe we can get someone to push forward on

Re: Possible funding of gfortran work

Hi everybody, there is also another aspect. Could this Sovereign Tech Fund also include travel allowances to go to a GNU Cauldron or a WG5 meeting? This could be quite interesting, I think. What is the largest number of gfortran contributers who ever met in one place? Manchester, a few years a

Re: Possible funding of gfortran work

On 30.05.23 15:32, Andre Vehreschild wrote: Hi all, thank you for all your input. I have read the funding requirements and checked out the application form. We have to agree on a project goal and describe why it is critical to fund this project. Let me try a first shot on this: - Title: GFort

Re: Possible funding of gfortran work

On 31.05.23 05:46, Benson Muite wrote: > On 5/30/23 23:08, Thomas Koenig via Fortran wrote: >>> * Complete language intrinsic parallel programming paradigm coarrays. >>> This >>> includes completing native coarray support (thread based). As well as >>&g

Re: [Patch, fortran] PR37336 finalization

Hi Paul, I propose to backport r13-6747-gd7caf313525a46f200d7f5db1ba893f853774aee to 12-branch very soon. Is this something that we usually do? While finalization was basically broken before, some people still used working subsets (or subsets that were broken, and they adapted or wrote their

Re: [Patch, fortran] PR37336 finalization

Hi Paul, I want to get something approaching correct finalization to the distros, which implies 12-branch at present. Hopefully I can do the same with associate in a month or two's time. OK by me then. (I just wanted to be sure that we had this discussion :-) Best regards Thomas

Re: Possible funding of gfortran work

On 01.06.23 13:12, Benson Muite via Fortran wrote: R and Octave may also be good examples of use cases. More generally, Lapack is written in Fortran, and R uses Lapack (as we found out the hard way with PR 90329). And Lapack is really a foundation of linear algebra, which is at the heart of a

Re: Possible funding of gfortran work

On 01.06.23 12:59, Mikael Morin wrote: The latter paragraph seems more an answer to the question "why is it critical for gfortran to get funding" than "why is it critical for a funding body to choose gfortran"? Good point :-) One idea about the latter question: so that there is always a fr

Re: Possible funding of gfortran work

On 05.06.23 12:07, Andre Vehreschild wrote: R and Octave may also be good examples of use cases. Mhhh, both are not written in Fortran, right? They are not, but at least R uses Lapack, which is written in Fortran. And Lapack is about as central to scientific computing as you can be. Best rega

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

Hi together, On 6/6/23 21:11, FX Coudert via Gcc-patches wrote: Hi, I cannot see if there is proper support for kind=17 in your patch; at least the libgfortran/ieee/ieee_arithmetic.F90 part does not seem to have any related code. Can real(kind=17) ever be an IEEE mode? If so, something seri

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

Hi FX, Having a POWER system isn't enough, it also needs the IBM "advance toolchain", and (at least with current distros, which default to ibm long double), you need to dance counterclockwise three times... I mean you need to invoke configure with some special magic Thanks for the frank descri

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

Hi Steve, On Thu, Jun 08, 2023 at 12:17:02PM +0200, Thomas Koenig wrote: [...] Thanks for the explanation. As I likely will not use a POWER-based system, I only loosely followed the discussion. I don't remember if ibm double-double is REAL(16) or REAL(17). If ieee 128-bit is REAL(16), then

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

Hi FX, >> The KIND=17 is a bit of a kludge. It is not visible for >> user programs, they use KIND=16, but this is then translated >> to library calls as if it was KIND=17 if the IEEE 128-bit floats >> are selected > > Can you check what the IEEE test results are when -mabi=ieeelongdouble is ena

Re: [PATCH] Introduce hardbool attribute for C

Hi Alexandre, On Apr 6, 2023, Bernhard Reutner-Fischer wrote: 29 For C_BOOL, the internal representation of .TRUE._C_BOOL and .FALSE._C_BOOL shall be the same as those of 30 the C values (_Bool)1 and (_Bool)0 respectively. I'm not changing any of the standard types, FWIW. The proposed ext

Re: Test with an lto-build of libgfortran.

Hi Toon, During the GNU Tools Cauldron we discussed (at the BoF: IPA & LTO) the possibility (and hazards) of building the run time libraries for various compilers with -flto, enabling an -flto -static linking of programs with the run time library available during link time optimizations. Thi

Re: Test with an lto-build of libgfortran.

Hi Jakub, It is worse than that, usually the LTO format changes e.g. any time any option or parameter is added on a release branch (several times a year) and at other times as well. Hm, that makes LTO not very well suited for libraries... Though, admittedly GCC is the single package that act

[patch, fortran] Fix PR 99345, ICE with DO loop checking

Hello world, the attached, rather obvious patch fixes an ICE on valid which came about because I did not handle EXEC_IOLENGTH as start of an I/O statement when checking for the DO loop variable. This is an 11 regression. Thanks to Harald for reducing this down to the bare minimum. Regression-te

Fwd: MATMUL broken with frontend optimization.

Hi Steve, I can confirm the bug (it's already in gcc 10) and will take a look at it. Regards Thomas

Re: MATMUL broken with frontend optimization.

OK, so I've had a bit of time to look at the actual test case. I missed one very important detail before: This is a vector-matrix operation. For this, we do not have a good library routine (Harald just removed it because of a bug in buffering), and -fexternal-blas does not work because we do no

Re: MATMUL broken with frontend optimization.

I didn't finish the previous mail before hitting "send", so here is the postscript... OK, so I've had a bit of time to look at the actual test case.  I missed one very important detail before:  This is a vector-matrix operation. For this, we do not have a good library routine (Harald just remov

Re: MATMUL broken with frontend optimization.

Am 18.03.21 um 21:22 schrieb Steve Kargl: On Thu, Mar 18, 2021 at 07:24:21PM +0100, Thomas Koenig wrote: I didn't finish the previous mail before hitting "send", so here is the postscript... OK, so I've had a bit of time to look at the actual test case.  I missed one very important detail be

Re: MATMUL broken with frontend optimization.

Hi Steve, On my old core2 cpu, a quick test with N=1000 and NxN matrix suggest a cross over near N=1000 for REAL(4). This cpu doesn't have any AVX* instruction, so YMMV. Program follows .sig Looking at your data with AVX (which I think we can mostly count on now), - The library is always

Re: MATMUL broken with frontend optimization.

Am 19.03.21 um 07:19 schrieb Thomas Koenig: I'll work on a patch. So, here's a concept patch. It still needs a ChangeLog and testsuite adjustment, but this is what I would propose to use. Regards Thomas diff --git a/gcc/fortran/frontend-passes.c b/gcc/fortran/frontend-passes.c inde

[patch, fortran] Also use size estimate for vector-matrix matmul

Hell world, here is the patch I talked about earlier. It passes regression testing. OK for trunk? Best regards Thomas Add size check to vector-matrix matmul. It turns out the library version is much faster for vector-matrix multiplications for large sizes than what inlining can prod

Re: [patch, fortran] Also use size estimate for vector-matrix matmul

Hi Jerry and Steve, Yes Ok for trunk. Thanks for the heads-up and the review, committed as r11-7742. Best regards Thomas

I'm taking a leave of absence

Hell world, I'm taking a leave of absence from gfortran for a time. The reason is the current discussions on the gcc mailing list, which I do not adivse you to read if you value your mental health and healthy blood pressure :-| I have unassigned all bugs assigned to me and set them to NEW. B

[patch, fortran] Fix PR 100227, write with implied DO loop

Hello world, after a bit of an absence, I am now back, at least for some regression fixing (and for reviewing patches, if that is called for). So, here's a regression fix to start with. OK for trunk and affected branches (down to 9)? Best regards Thomas Do not replace variable op var

Re: [patch, fortran] Fix PR 100227, write with implied DO loop

Hi Jerry, Looks OK Thomas, Good for backport as well. Thanks. Committed to trunk so far, will add a git worktree for gcc11 next :-) Best regards Thomas

Re: REQ000031483977 || Fortran 2018

Hello Vishal, This is Vishal Keshri from Software Asset Management team of ExxonMobil. > My group Software Asset Management is responsible for software licensing in our organization. The Software Asset Management group at ExxonMobil > exists in large part to steward software license complian

Re: REQ000031483977 || Fortran 2018

On 11.07.21 13:09, I wrote: Fortran 2018 is not a software, it is a standard for the programming software Fortran. That should have been programming language, of course.

Re: [PATCH] PR fortran/100949 - [9/10/11/12 Regression] ICE in gfc_conv_expr_present, at fortran/trans-expr.c:1975

Hi Harald, we rather shouldn't consider a presence check for a non-dummy variable. Regtested on x86_64-pc-linux-gnu. OK for all affected branches? OK for all. Thanks for the patch! Best regards Thomas

Re: [PATCH, Fortran] Bind(c): CFI_signed_char is not a Fortran character type

Hi Sandra, The part of the patch to add tests for this goes on top of my base TS29113 testsuite patch, which hasn't been reviewed or committed yet. It is my understanding that it is not gcc policy to add xfailed test cases for things that do not yet work. Rather, xfail is for tests that late

Re: Pushing XFAILed test cases

On 16.07.21 20:22, Sandra Loosemore wrote: So it seems to me rather surprising to take the position that we should not be committing any new test cases that need to be XFAILed It is what I was told in no uncertain terms some years ago, which is where my current state of knowledge comes from. S

Re: Fwd: Curious Behavior with Fortran gfortran-10.2-catalina.dmg on macOS Big Sur Version 11.4

(Adding the OP). (2) I encountered a curious failure on compilation with the following statement using integer arithmetic: n= (m + 4)/5 with the message Error: Integer division truncated to constant ‘2’ at (1) [-Werror=integer-division] f951: all warnings being treated as errors This

Re: [PATCH 1/7] fortran: new abstract class gfc_dummy_arg

Hi Mikael, Introduce a new abstract class gfc_dummy_arg that provides a common interface to both dummy arguments of user-defined procedures (which have type gfc_formal_arglist) and dummy arguments of intrinsic procedures (which have type gfc_intrinsic_arg). good to see you again! So far, we

Re: gfortran on Apple M1 function address problem

Hi Alex, the problem you describe is well-known. It is a result of changes that Apple made to the ARM Application Binary Interface when introducing the M1, which disallow the a method that gcc (and, by extension, gfortran) use for invoking nested functions, the so-called trampolines. There is

Re: [PATCH] PR fortran/102287 - optional allocatable array arguments (intent out) of derived types with allocatable components are not properly passed to subroutines

Hello Harald, As nicely described in the PR, we mishandled the case of passing optional allocatable DT arguments with allocatable components when the INTENT was declared as INTENT(OUT), as we unconditionally tried to deallocate these components even when the argument was not present. The obviou

Re: [PATCH, Fortran] Fixes for F2018 C838 (PR fortran/101334)

Hi Sandra, This patch fixes some bugs in handling of assumed-rank arguments revealed by the TS29113 testsuite, allowing xfails to be removed from those testcases.  It was previously failing to diagnose an error when passing an assumed-rank argument to a procedure via a non-assumed-rank dummy,

Re: [Patch] Fortran: Add gfc_simple_for_loop aux function

Hi Tobias, This patch adds a useful auxiliary function to generate a loop. Looks good to me (and there are probably quite a few places where this could be useful). Best regards Thomas

Re: [Patch] Fortran: Fix assumed-size to assumed-rank passing [PR94070]

Hi Tobias, OK for mainline? As promised on IRC, here's the review. Maybe you can add a test case which shows that the call to the size intrinsic really does not happen. OK with that. Thanks for the patch! Best regards Thomas

Re: [PATCH] PR fortran/102458 - ICE tree check: expected array_type, have pointer_type in gfc_conv_array_initializer, at fortran/trans-array.c:6136

On 23.09.21 21:47, Harald Anlauf via Fortran wrote: Dear Fortranners, we missed certain intrinsics as being disallowed in constant expressions, which lead to an ICE when these intrinsics were used in a specification expression with an initializer. The intrinsics in question are listed in F2018:

Re: [Patch] Fortran: Fix associated intrinsic with assumed rank [PR101334] [was: [PATCH, Fortran] Fixes for F2018 C838 (PR fortran/101334)]

On 23.09.21 21:13, Tobias Burnus wrote: On 20.09.21 09:58, Tobias Burnus wrote: On 20.09.21 06:01, Sandra Loosemore wrote: This patch fixes some bugs in handling of assumed-rank arguments revealed by the TS29113 testsuite, ... giving a bogus error when passing one as the first argument to the

Re: [PATCH] PR fortran/102520 - [10/11/12 Regression] ICE in expand_constructor, at fortran/array.c:1802

Hi Harald, Gerhard's testcase triggers a NULL pointer dereference during the attempt to expand an invalid constructor. The simple and obvious solution is to catch that case. Regtested on x86_64-pc-linux-gnu. OK for all affected branches? OK. Thanks for the patch! Best regards Tho

Re: DGBSV: incorrect numerical results with -L/usr/lib64/atlas ?

Hi Jorge, I do not know if this forum is the most appropriate, but as it based using gfortran I will try to start here. I usually build the ATLAS library in some beta version without any numerical problem that I remember. In a circumstantial way, I have to use the system ATLAS library and, toda

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

On 04.10.21 16:14, Jakub Jelinek via Fortran wrote: Based on some IRC discussion, yet another option would be bump libgfortran SONAME (on all arches), make real(kind=16) on powerpc64le-linux mean always IEEE quad (starting with GCC 12) and if wanted add support for real(kind=15) meaning double

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

On 05.10.21 23:54, Segher Boessenkool wrote: Hi! On Tue, Oct 05, 2021 at 10:16:47PM +0200, Thomas Koenig wrote: On 04.10.21 16:14, Jakub Jelinek via Fortran wrote: Based on some IRC discussion, yet another option would be bump libgfortran SONAME (on all arches), make real(kind=16) on powerpc64

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

On 07.10.21 05:35, Michael Meissner via Fortran wrote: I tried this at one point. There are a lot of hidden assumptions that the kind number is the number of bytes. I'm sure it can be tracked down, but the problem is with these assumptions is you can't prove a negative (i.e. you never know that

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

On 07.10.21 17:33, Jakub Jelinek wrote: It will also be a compatibility issue if users have code compiled on a LE system with GCC 11 and earlier with KIND=16, it will not link with GCC 12. libgfortran ABI changed multiple times in the past already, e.g. the so.1 -> so.2 transition in 4.2 so.2

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

Hi Iain, If one wanted to prioritize library SO name stability - then, perhaps, the approach Jonathan mentioned has been used for libstdc++ (add new symbols for ieee128 with a different mangling to the existing r/c_16 ..) would be preferable (the FE then has to choose the relevant symbol/ mangli

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

Hi Iain, Things get interesting for user code, calling a routine compiled for double double with newer IEEE QP will result in breakage. That would not happen with the proposal above, since the library would have different entry points for the two formats. I meant the case where the user wri

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

On 09.10.21 01:18, Iain Sandoe wrote: I meant the case where the user writes, with an old, KIND=16 is double double compiler, subroutine foo(a) real(kind=16) :: a a = a + 1._16 end subroutine foo and puts it in a library or an old object file, and in new code with an IEEE QP compi

Re: [PATCH] PR fortran/102717 - ICE in gfc_simplify_reshape, at fortran/simplify.c:6843

H Harald, when simplifying RESHAPE we hit a gcc_assert for negative entries in the SHAPE array. Obvious solution: replace gcc_assert by an error message. Regtested on x86_64-pc-linux-gnu. OK for mainline? As this is a safe fix, I'd like to backport to suitable branches. OK for both. Thank

Re: [PATCH] PR fortran/102716 - ICE in gfc_validate_kind(): Got bad kind

Hi Harald, another simple and obvious fix: we need to reorder the argument checks to the SHAPE intrinsic so that invalid KIND arguments can be detected. Regtested on x86_64-pc-linux-gnu. OK for mainline? As I consider this a safe fix, I'd like to backport to suitable branches. Also OK for b

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

On 15.10.21 16:20, Jakub Jelinek wrote: [...] when one compiles integer function foo () foo = precision (0.0_16) end function foo integer function bar () bar = range (0.0_16) end function bar with -mabi=ibmlongdouble, I see 31 and 291, while with -mabi=ieeelongdouble 33 and 4931. The 0

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

On 15.10.21 20:11, Jakub Jelinek wrote: On Fri, Oct 15, 2021 at 08:05:38PM +0200, Thomas Koenig wrote: with -mabi=ibmlongdouble, I see 31 and 291, while with -mabi=ieeelongdouble 33 and 4931. The 0.0_8 precision/range values are 15 and 307, so neither precision of C long double if it is doubl

Re: [PATCH][WIP] Add install-dvi Makefile targets

Hi Eric, Hi, I have updated this patch and tested it with more languages now; I can now confirm that it works with ada, d, and fortran now. The only languages that remain untested now are go (since I'm building on darwin and go doesn't build on darwin anyways, as per bug 46986) and jit (which I

Re: [wwwdocs, committed] GCC 12: Add release note for Fortran TS29113 improvements

Hi Sandra, I've checked in the attached patch to announce the cleanup project that Tobias and I have been working on over the last several months in the GCC 12 release notes.  I also updated the page for TS29113 on the GCC wiki to reflect that anything that still doesn't work ought to be cons

Re: [PATCH, Fortran] Add testcase for PR100906

Hi Sandra, PR100906 ("Bind(c): failure handling character with len/=1") has been fixed by Tobias's rewrite of the GFC <-> C descriptor conversions.  I'd like to add José's testcase for that issue before closing it.  OK? OK. I think adding undisputed passing test cases from PRs for somethin

Re: libgomp.fortran/async_io_[1,2,3,4,8,9].f90 fail on FreeBSD

Hi Steve, libgomp.fortran/async_io_[1,2,3,4,8,9].f90 account for a number of FAILS on x86_64-*-freebsd. Please fix. I'd try to see what is going on, but I have been unable to boot gcc (and thus gfortran) on any of the *BSD machines running on the gcc compile farm, and more specifically on gcc

Re: [PATCH,Fortran 1/7] Fortran: make some trans* functions static

Hi Bernhard, what you're doing seems a useful clean-up, thanks. One point for discussion: -match +static match gfc_match_label (void) I have generally understood that the gfc_ prefix is for global variables and functions only. We do not always adhere to it (also since some global functi

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes (work in progress patches)

Hi Michael, I tried this out on the one POWER machine where I can get something installed :-) It runs Ubuntu 20.04, but does not appear to have the right glibc version; it has $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 20.04.1 LTS Release:

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes (2nd patch)

Hi Michael, It adds target hooks so the back end can overwrite the kind number for types. I made the IBM long double type use KIND=15 instead of KIND=16, and Float128 uses KIND=16 as we've discussed. The tests for long double are still failing, so I suspect we will need some way of signalling

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes (2nd patch)

Hi Jakub, On Sat, Oct 30, 2021 at 11:30:29AM +0200, Thomas Koenig wrote: - Have a compiler switch which selects between IEEE_QP and IBM_QP. This was a suggestion by Steve Lionel formerly of DEC and Intel, and they did that when they had a few floating point formats on the Alpha to choo

[RFC] User-visible changes for powerpc64-le-linux ABI changes

Hi, I have put together a summary of what users should see as a change. I've made this a diff against the current documentation. This is an RFC, please feel free to suggest any changes. I have put in a few remarks among the diff. If there is general agreement that this is the best way forward

Re: [PATCH] Fortran: Silence -Wmaybe-uninitialized warning

Hi Bernhard, gcc/fortran/ChangeLog: * resolve.c (resolve_fl_procedure): Initialize allocatable_or_pointer. Looking at the code, it is clear that this is a false positive, or a false maybe, but the semantics of C/C++ may well indicate that sym->result could change, although i

Re: [RFC] User-visible changes for powerpc64-le-linux ABI changes

Hi Bill, We had previously been concerned about whether the necessary name mangling support would be possible, but it sounds like you aren't overly worried about that. We can always add a letter to the kind number, or use a different number in the encoding, or someting This has to be done i

Re: [RFC] User-visible changes for powerpc64-le-linux ABI changes

On 01.11.21 18:45, Jakub Jelinek wrote: Note, if we go the way of C/C++ with -mabi=ieeelongdouble vs. -mabi=ibmlongdouble choosing between the two ABIs and libgfortran being ABI compatible with both, then we don't need to bump soname. Sounds like one major pain solved. I think we should do i

Re: [PATCH] PR fortran/91497 -- Silence conversion warnings for MIN1 and MAX1

Hi Manfred, In addition to the patches of Steve Kargl for PR 91497: The MIN1 and MAX1 intrinsics do explicit type conversions and should be silenced too for -Wconversion and -Wconversion-extra. Adjust testcase to only use *4 and *8 real types, provide a second testcase for *10 and *16 precision

Re: [PATCH] PR fortran/91497 -- Silence conversion warnings for MIN1 and MAX1

On 02.11.21 15:22, Manfred Schwarb wrote: Am 02.11.21 um 14:26 schrieb Thomas Koenig: Hi Manfred, In addition to the patches of Steve Kargl for PR 91497: The MIN1 and MAX1 intrinsics do explicit type conversions and should be silenced too for -Wconversion and -Wconversion-extra. Adjust testca

Re: [PATCH] PR fortran/91497 -- Silence conversion warnings for MIN1 and MAX1

Hi Manfred, looks good to me. Thanks for the patch! Best regards Thomas

[patch, fortran, wwwdocs] Fix name of argument to CO_REDUCE

Hello world, the attached patches fix the name of the function argument to CO_REDUCE to conform to Fortran 2018 instead of the TR. This is a user-visible change, so I have put this both into changes.html and porting_to.html. Regression-tested. OK for trunk? Best regards Thomas Autho

Re: [PATCH] PR fortran/103217 & 103218 - ICEs during simplification after r12-4967-gbcf3728abe848888

Hi Harald, I'd like to commit the attached patch as obvious within the next 24 hours unless anybody objects, or earlier if there is positive feedback. OK with a ChangeLog entry and the correct PR numbers (I believe they are 103137 and 103138) :-) Best regards Thomas

Re: [PATCH v3 0/5] fortran: Ignore unused arguments for scalarisation [PR97896]

Hi Mikael, Regression-tested on x86_64-linux-gnu. Ok for master? This looks quite good, and is (I think) a cleaner version than what we had before. OK. Thanks a lot for the patch(es)! Best regards Thomas

Re: [PATCH 0/2] fortran: Ignore unused arguments for scalarisation [PR97896]

On 07.11.21 17:17, Mikael Morin via Fortran wrote: Regression-tested on x86_64-linux-gnu. Ok for master and 11 branch? OK. Just one remark: Since just reverting my old patch would introduce a regression for that one revision, please squash the patches before committing. Thanks a lot for th

Re: [RFC] User-visible changes for powerpc64-le-linux ABI changes

Hi, is there an update on this? I am still waiting on a response for the account on the development machine. I assume we would to the development on a branch. My git fu is extremely weak, so I would appreciate if somebody did that for me. Is it actually possible to implement what I wrote in t

Re: [RFC] User-visible changes for powerpc64-le-linux ABI changes

On 16.11.21 00:42, Michael Meissner wrote: On Mon, Nov 15, 2021 at 09:27:38PM +0100, Thomas Koenig wrote: Hi, is there an update on this? I am still waiting on a response for the account on the development machine. I assume we would to the development on a branch. My git fu is extremely weak

Re: [PATCH] PR fortran/101329 - ICE: Invalid expression in gfc_element_size

On 17.11.21 22:28, Harald Anlauf via Fortran wrote: Dear Fortranners, as NULL() is not interoperable, we have to reject it. Confirmed by NAG. Other compilers show "interesting behavior". Obvious patch by Steve. Regtested on x86_64-pc-linux-gnu. OK for mainline? OK, and thanks! Best regard

Re: [RFC] User-visible changes for powerpc64-le-linux ABI changes

Hi Segher, On Mon, Nov 15, 2021 at 06:42:18PM -0500, Michael Meissner wrote: I assume we would to the development on a branch. My git fu is extremely weak, so I would appreciate if somebody did that for me. Sure, we can create an IBM vendor branch. It should not be an IBM branch, we should

Work on the power-ieee128 branch has hit a snag...

... in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103476, a very strange error where an invalid Makefile is generated with --enable-maintainer-mode on POWER. I'm not sure how to proceed from here. Maybe somebody with more make debug fu could take a look? Best regards Thomas

Re: Work on the power-ieee128 branch has hit a snag...

On 29.11.21 20:42, Florian Weimer via Fortran wrote: What's the whitespace situation? Usually the error means that the recipe is indented using spaces instead of tab. The error is on the line $(i_matmulavx128_c): m4/matmulavx128.m4 m4/matmul_internal.m4 $(I_M4_DEPS) where there is no whit

Re: Work on the power-ieee128 branch has hit a snag...

... which has been resolved. There was a stray semicolon in quite another place which led to this error. Thanks to Andreas for finding this so quickly! Best regards Thomas

[power-ieee128] What should the math functions be annotated with?

Hi, looking at the head of a generated gfortran library math function, for example bessel_r16.c, #if defined(GFC_REAL_16_IS_FLOAT128) #define MATHFUNC(funcname) funcname ## q #else #define MATHFUNC(funcname) funcname ## l #endif So (I suppose I can unravel the m4 code to generate this:-) what

[power-ieee128] What should the math functions be annotated with?

I am currently working on implementing the IEEE 128-bit floating on POWER. One of the things to decide is what to call the math functions for the library calls. Example: libgfortran/generated/bessel_r16.c currently has #if defined(GFC_REAL_16_IS_FLOAT128) #define MATHFUNC(funcname) funcname ##

Re: [power-ieee128] What should the math functions be annotated with?

On 01.12.21 21:54, Jakub Jelinek via Fortran wrote: Inside of libgfortran, I think it should depend on some macro defined in libgfortran.h. #if defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ \ && defined __GLIBC_PREREQ && __GLIBC_PREREQ (2, 32) then #define MATHFUNC(f

<    1   2   3   >