Re: Updated Sourceware infrastructure plans

Am 18.04.24 um 01:27 schrieb Mark Wielaard: We also should make sure that all generated files (either in git or in the release/snapshot tar balls) can be reliably and reproducibly regenerated. This also helps the (pre-commit) CI buildbots. We already have the autoregen bots for gcc and

Re: Fortran: Use non conflicting file extensions for intermediates [PR81615]

Hi Paul and Harald, 'from' is slightly better but either will be understood. Committed with "from" (which I managed to spell correctly on the second try). Best regards Thomas

Re: Fortran: Use non conflicting file extensions for intermediates [PR81615]

Replying to myself... I think this also desevers a mention in changes.html.  Here is something that I came up with.  OK? Or does anybody have suggestions for a better wording? Or maybe this is better: diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html index

Re: Fortran: Use non conflicting file extensions for intermediates [PR81615]

Hi Rimvydas, Documentation part. The makeinfo gcc/fortran/gfortran.texi does not seem to have any new warnings. Thanks for your work on this! I think this also desevers a mention in changes.html. Here is something that I came up with. OK? Or does anybody have suggestions for a better

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

Hi Lipeng, Sure, as your comments, in the patch V6, I added 3 test cases with OpenMP to test different cases in concurrency respectively: 1. find and create unit very frequently to stress read lock and write lock. 2. only access the unit which exist in cache to stress read lock. 3. access the

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[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

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

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

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

[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] 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

[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

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

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

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

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

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

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

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

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

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

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

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: [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‘

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

[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

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

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

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

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

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

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

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

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. 

[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

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

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

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

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

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

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

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

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,

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

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

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

*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: [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

[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

[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

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

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]

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

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

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

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

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

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

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

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

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

  1   2   3   >