[patch, fortran, committed] Set DECL_ARTIFICIAL on auxiliary variables

Hello world, committed to trunk as obvious and simple. Best regards Thomas Set DECL_ARTIFICIAL on gfortran internal variables. It seems we sometimes use DECL_ARTIFICIAL as choosing between different code paths. In order not to make -fdebug-aux-vars do different things, set

[patch, fortran, testsuite, committed] Fix some more coarray stuff

Hi, I have just committed the attached patch to a test case that was failing on the shared coarray branch. Again, the person who wrote the test case depended on only running on a single image :-) Best regards Thomas Correct coarray indices for test case. gcc/testsuite/ChangeLog:

Re: *PING* Re: [PATCH] Fortran : ICE in build_field PR95614

Hi Mark, I haven't yet committed this. I am unfamiliar with Andre, I've checked MAINTAINERS and I find Andre in the "Write after approval" section. Is Andre's approval sufficient? If so MAINTAINERS needs to be updated. The official list of people who can review is at

[patch, fortran, committed] Fix PR 96556, segfault on NULL pointer dereference

Hi, in the code about DO loop warning I recently introduced, there was a hidden NULL pointer dereference found by Jürgen Reuter and fixed as obvious and simple in r11-2636. Fix NULL pointer dereference in doloop_contained_function_call. Thanks to Jürgen for the bug report and to Dominique for

Re: [Patch, fortran] PR 93592 - Invalid UP/DOWN rounding with EN descriptor

Hi Dominique, I am trying t...@tkoenig.net. That works :-) I'll try to use that address in the future for my mails to the fortran mailing list, so it does not bounce for you. Best regards Thomas

ping**(5./7.) [patch, fortran] Fix memory leak on deallocation

In the meantime, here is a patch which fixes a regression I introduced when fixing a regression with a memory leak.  The important thing here is to realize that we do not need to finalize (and deallocate) multiple times for the same expression and the same component in the same namespace.  It

[patch, fortran] Fix memory leak on deallocation

Hello world, Our finalization handling is a mess. Really, we should get to try and get this fixed for gcc 11. In the meantime, here is a patch which fixes a regression I introduced when fixing a regression with a memory leak. The important thing here is to realize that we do not need to

[patch, fortran, committed] Fix PR 94578

Hello world, rather than touch 50% of the files in our libfortran subdirectory, I opted for the simple and obvious way - if the RHS is a pointer which may have a span, just create a temporary. (We're also qutie close to a release candidate if I count the P1 regressions correctly, so this is not

Re: [wwwdocs] Fix inverted option for disabling new feature (PR 94581)

Am 14.04.20 um 12:11 schrieb Jonathan Wakely: Committed as obvious. Thomas, please fix it if this isn't what you meant to say. Yep, that's what I meant to say. Thanks a lot! Regards Thomas

Re: [PATCH] analyzer: fix ICE on pointer arithmetic with incomplete types [PR 93774]

Hi David in principle, any valid test case (especially for an ICE) should count as obvious and simple, so no approval should be needed. Having said that, I think I would prefer a copy of the original test case rather than an include statement. Although we usually do not change or remove test

Re: [patch, fortran] Fix PR 85781, ICE on valid

Hi Tobias, I hope my patch covers all issues. – OK for the trunk? Yep. Thanks a lot for the patch! Regards Thomas

Re: [patch, fortran] Fix PR 85781, ICE on valid

Hi Tobias, the attached patch fixes an ICE which could occur for empty substrings (see test case). I think one should rather fix the following issue. I am not sure what you mean. Does that mean that fixing the following issue will also fix PR 85781, or that the PR should not be fixed?

[patch, fortran] Fix PR 85781, ICE on valid

Regression-tested. OK for trunk? Regards Thomas 2020-01-19 Thomas König PR fortran/85781 * resolve.c (resolve_substring): If the substring is empty, set it to (1:0) explicitly. 2020-01-19 Thomas König PR fortran/85781 * gfortran.dg/substr_

Re: [Patch, Fortran] PR91640 – Fix call to contiguous dummy

Hi Tobias, As a variant, I now use the latter (via the else branch). Either variant produces the same original tree. One can argue which variant is clearer; I think both are fine – pick one. I think the second one (the one you just attached) looks better. So, OK for trunk. Thanks for the

Re: [Patch, Fortran] PR91640 – Fix call to contiguous dummy

Hi Tobias, If one passes something which is not a variable as an argument, there is no point to do the copy-out – the copy-in is sufficient. Note that a the result of a pointer-returning function is regarded as variable. As cleanup, I also fixed the indentation (twice) and the pointless

[patch, fortran, committed] Error on Associate with a program

Hello world, yet another obvious and simple fix: You cannot really associate the main program with a variable. Committed as r279088 after regression-testing. Regards Thomas 2018-12-08 Thomas Koenig PR fortran/92780 * resolve.c (resolve_assoc_var): Issue error if

Re: [patch, fortran] Load scalar intent-in variables at the beginning of procedures

Am 20.11.19 um 23:18 schrieb Janne Blomqvist: On Wed, Nov 20, 2019 at 11:35 PM Thomas König wrote: Am 20.11.19 um 21:45 schrieb Janne Blomqvist: BTW, since this is done for the purpose of optimization, have you done testing on some suitable benchmark suite such as polyhedron, whether

Re: [patch, fortran] Load scalar intent-in variables at the beginning of procedures

Am 20.11.19 um 21:45 schrieb Janne Blomqvist: BTW, since this is done for the purpose of optimization, have you done testing on some suitable benchmark suite such as polyhedron, whether it a) generates any different code b) does it make it go faster? I haven't run any actual benchmarks.

Re: [patch, fortran] Load scalar intent-in variables at the beginning of procedures

Hi Tobias, I think you need to add at least VOLATILE to this list Yes, I'll do that. Any other comments? Regards Thomas

Re: [patch, fortran] Load scalar intent-in variables at the beginning of procedures

Hi Tobias, > On 11/12/19 1:42 PM, Thomas König wrote: >>> Ah, of course. I should have said module procedures. Or even module >>> procedures without bind(C)? >> It would probably be the latter. The change would actually be rather small: >> If conditions are me

Re: [patch, fortran] Load scalar intent-in variables at the beginning of procedures

Hi Janne, > Ah, of course. I should have said module procedures. Or even module > procedures without bind(C)? It would probably be the latter. The change would actually be rather small: If conditions are met, just add attr.value for INTENT(IN). This is something we should probably do when we

Re: [patch, fortran] Load scalar intent-in variables at the beginning of procedures

Hi Janne, Wouldn't it be even better to pass scalar intent(in) variables by value? The obvious objection of course is ABI, but for procedures with an explicit interface we're not following any particular ABI anyways? The problem with that is that we don't know when we compile a procedure if

[patch, fortran] Load scalar intent-in variables at the beginning of procedures

Hello world, the attached patch loads scalar INTENT(IN) variables to a local variable at the start of a procedure, as suggested in PR 67202, in order to aid optimization. This is controlled by front-end optimization so it is easier to catch if any bugs should turn up :-) This is done to make

Re: [Patch][Fortran] PR 92208 don't use function-result dummy variable as actual argument

Hi Tobias, I think this is also OK for gcc 9. Backporting regression fixes should always be all right under normal circumstances. Regards Thomas

Re: [Patch][Fortran] OpenMP+OpenACC: Remove bogus contigous-pointer check (PR/65438)

Hi Tobias, What about using gfc_is_not_contigous? This would allow to issue an error when we can prove the user made an error. Regards Thomas

Re: [patch][Fortran] Actually permit OpenMP's 'target simd'

Hi Bernhard, > Am 14.10.2019 um 11:58 schrieb Bernhard Reutner-Fischer > : > > On 14 October 2019 10:50:55 CEST, Jakub Jelinek wrote: >>> On Tue, Oct 08, 2019 at 02:04:17PM +0200, Tobias Burnus wrote: >>>testsuite/ >>>* gfortran.dg/gomp/target-simd.f90: New. >> >> John Reporte in

[patch, fortran, committed] Fix PR 92017

Hello world, I have committed the attached patch as obvious and simple after regression-testing. It fixes an ICE on valid for a corner case, so I don't really feel that it needs to be backported. If anybody disagrees, please speak up (or do it yourself :-) Regards Thomas 2019-10-13

Re: SPEC 521.wrf_r failing due to new fortran checks

Hi Joel, I've noticed that SPEC has been failing to build on trunk since the below commit, do you have access to SPEC? None of the gfortran maintainers has access to SPEC. do you know if this is due to a bug in the patch or a bug in SPEC? The SPEC suite has quite a few bugs, which SPEC

Re: [patch, fortran] Fix PR 91390 - treatment of extra parameter in a subroutine call

Hi Steve, OK. Thanks for taking on this task. Committed (r274902). Thanks for the review! As to the open question about how to handle this check, I would create -fallow-argument-mismatch (or whatever option name you like). gfortran issues an error if a mismatch is detected. -fallow-...

[patch, fortran] Fix PR 91390 - treatment of extra parameter in a subroutine call

Hello world, here is the next installment of checking for mismatched calls, this time for mismatching CALLs. The solution is to build a separate namespace with procedure arguments determined from the actual arguments the first time a procedure is seen, and then compare it against that on

[patch, fortran] Fix PR 90561

Hello world, this patch fixes a 9/10 regression by placing the variable used to hold a string length at function scope. I chose to implement this version of gfc_evaluate_now as a separate function because I have a sneaking suspicion this may not be the last time we are going to encounter

Re: [PATCH] fortran: C++ support for generating C prototypes

Hi Janne, I do not think we need to add header guards. The headers, as we emit them, contain prototypes only, so repeated inclusions Should be harmless. So. the potential disadvantage would be a teeny bit of compilation time vs the chance of header macro collision and resulting wrong code.

Re: [patch] Fix PR 84487, large rodata increase in tonto and other programs

Hi, thanks a lot for the extensive discussion :-) How should we now proceed, first for gcc 9, snd then for backporting? Use Richard‘s patch with the corresponding Fortran FE change? Regards Thomas

[patch, fortran, committed] Add a few more debug functions

Hello world, I have just committed this patch as obvious to make debugging a bit easier. No user impact, the code compiles :-) Regards Thomas 2019-03-31 Thomas Koenig * dump-parse-tree.c (debug): Add for symbol_attribute *, symbol_attribute and gfc_ref *

[patch, fortran] Fix the rest of PR 71203

are https://gcc.gnu.org/ml/fortran/2019-03/msg00022.html and https://gcc.gnu.org/ml/fortran/2019-02/msg00241.html. I'd appreciate somebody looking at these, I think I am close to the limit of concurrent patches in my tree :-) Regards Thomas 2019-03-09 Thomas König PR fortran

Re: [PATCH] Fix libgfortran/caf/single.c warnings (PR libgfortran/89593)

Hi Jakub, Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? Yes (also could be considered obvious, I guess). Thanks for the patch! Regards Thomas

[patch, fortran] Fix PR 89496, error with alternate return

Hello world, the attached patch fixes a regression introduced by my recent patch for PR 87689, where the alternate return arguments were not handled correctly. Some experimentation resulted in a test case which actually segfaulted on a normal compiler, instead of just being visible on an

Re: [patch, fortran] Fix PR 89174, segfault on allocate with MOLD

Hi Steve, I think this was introduced quite some time ago, not sure if it was ever documented anywhere. I guess we should do so. Probably want to document this in the testcase. I just checked and found 77 occurences in the test suite (most of them mine, to be sure). So, maybe an entry in

Re: [patch, fortran] Implement debug() for some Fortran data structures

Am 20.02.19 um 21:36 schrieb Steve Kargl: On Wed, Feb 20, 2019 at 09:10:51PM +0100, Thomas König wrote: Hello world, the attached patch implements a few versions of debug for Fortran data structures. It lets you type, for example (gdb) call debug (expr) and get some output which is readable

[patch, fortran] Implement debug() for some Fortran data structures

Hello world, the attached patch implements a few versions of debug for Fortran data structures. It lets you type, for example (gdb) call debug (expr) and get some output which is readable, instead of having to look at the structures yourself. This has no user impact, because thsese functions

Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include.

Hi Martin, I would change "among" to "between" in the sentence below. OK otherwise (not that I think an OK is really needed in this case). + The purpose of the directive is to provide an API among the GCC compiler and +the GNU C Library which would define vector implementations of math

Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include.

Hi Martin, > Thank you both useful comments! I installed that as r269035. Excellent work, thanks! Now a final step: Could you also add a short sentence to gcc-9/changes.html ? In German, we have a saying „Tue Gutes und rede darüber“, do good deeds and talk about it  Regards, Thomas

Re: [PR fortran/89348, patch] Fortran Command Options documentation fixes

Mark, > Patch and change log attached to PR. Could you please submit this the normal way, with the ChangeLog in the text and the patch ad attachment? Regards, Thomas

Re: [PATCH] Do not dereference NULL pointer in resolve_ref (PR fortran/89185).

Hi Martin, > Patch can bootstrap on x86_64-linux-gnu and survives regression tests. > > Ready to be installed? > Thanks, > Martin Ok. Thanks for the very quick fix! Regards Thomas

Re: [patch, fortran] Fix PR 57048

Hi Steve, Thanks for the patch, and OK to commit. Committed to trunk (r268372). Thanks! I will backport to the affected branches later in the week. Regards Thomas

Re: [patch, fortran] Fix PR 57048

Hi Steve, PR fortran/57048 * interface.c (gfc_compare_types): If a derived type and an integer both have a derived type, and they are identical, this is a C binding type and compares equal. I don't understand this sentence. How can an INTEGER have a derived

[patch, fortran] Fix PR 57048

Hello world, let the regression hunt continue! the attached patch fixes a long-time regression where a c_funptr from a module could not be found. The solution is a bit of a hack, but so is our whole implementation of the C interop stuff. Regression-tested. OK for trunk? Regards

Re: [patch, doc, fortran] Document FINDLOC

Am 29.10.18 um 12:31 schrieb Bernhard Reutner-Fischer: Hi! On Sun, 28 Oct 2018 15:13:49 +0100 Thomas König wrote: One question and some nits below. === --- intrinsic.texi (Revision 265569) +++ intrinsic.texi

[patch, doc, fortran] Document FINDLOC

Hi, here is the promised documentation for FINDLOC. Tested with "make dvi" and "make pdf". OK for trunk? Regards Thomas 2018-10-28 Thomas Koenig PR fortran/54613 * gfortran.texi (File format of unformatted sequential files): Replace random comma with

[patch, rfc] Clobber scalar intent(out) variables on entry

Hi, the patch below tries to clobber scalar intent(out) arguments on procedure entry. Index: trans-decl.c === --- trans-decl.c(Revision 264423) +++ trans-decl.c(Arbeitskopie) @@ -4143,6 +4143,19 @@

[patch, fortran] Fix PR 86837, wrong code regression in implied do loop in i/o

Hello world, this patch fixes a regression by correctly checking that the innner start, step or end values of an implied do loop do not depend on an outer loop variable. The check was actually done before, but gfc_check_dependency wasn't finding all relevant cases. Regression-tested. OK for

Re: Async I/O patch with compilation fix

Hi Cristophe, this is seriously weird - there is not even an I/O statement in that test case. One question: Is this real hardware or an emulator? Also, Could you try a few things? Run the test case manually. Do you still fail? Is there an error if the executable is run under valgrind? If you

Re: [PATCH][Fortran][v2] Use MIN/MAX_EXPR for min/max intrinsics

Hi Kyrlll, > Am 18.07.2018 um 13:17 schrieb Kyrill Tkachov : > > Thomas, Janne, would this relaxation of NaN handling be acceptable given the > benefits > mentioned above? If so, what would be the recommended adjustment to the > nan_1.f90 test? I would be a bit careful about changing behavior

Re: [patch, fortran] Asynchronous I/O, take 3

Hi Rainer, However, may (all?) gfortran tests now SEGV. One example is Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: Segmentation Fault Thread 2 received signal SIGSEGV, Segmentation fault. [Switching to Thread 1 (LWP 1)]

[patch, fortran] Asynchronous I/O, take 3

Hello world, the attached patch is the third take on Nicolas' and my patch for implementing asynchronous I/O. Some parts have been reworked, and several bugs which caused either incorrect I/O or hangs have been fixed in the process. I have to say that getting out these bugs has been much

Re: [PATCH] PR fortran/78571 -- Avoid ICE in invalid CHARACTER initialization

Hi Steve, Regression tested on x86_64-*-freebsd. OK to commit? OK, and thanks! Thomas

Re: [PATCH] PR fortan/85779 -- Fix NULL pointer dereference

Hi Steve, > Am 24.05.2018 um 02:24 schrieb Steve Kargl > : > > Subject says it all. OK to commit? OK. Thanks for the patch! Thomas > > 2018-05-23 Steven G. Kargl > >PR fortran/85779 >*decl.c (gfc_match_derived_decl): Fix NULL point dereference. > > 2018-05-23 Steven G. Kargl

Re: Document PR 84073 change in /gcc-8/porting_to.html

Am 10.05.2018 um 14:20 schrieb Thomas Koenig: Am 10.05.2018 um 12:33 schrieb Jonathan Wakely: Should the fix for PR 84073 be documented, so that users whose code is now rejected understand why, and how to fix it? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84073

[patch, fortran, doc, committed] Document BACK for MINLOC and MAXLOC

Hello world, I just commmitted the attached patch as obvious after checking that it passes "make info", "make dvi" and "make pdf". Regards Thomas 2018-05-10 Thomas Koenig PR fortran/54613 * intrinsic.texi: Document BACK for MINLOC and MAXLOC.

Re: PR85463 '[nvptx] "exit" in offloaded region doesn't terminate process'

Am 19.04.2018 um 13:59 schrieb Thomas Schwinge: The Fortran standard does not apply in this case. What does the OpenACC standard say about STOP in an offloaded region? Nothing explicitly, as far as I know. ;-/ Which means, that this either a) has to be forbidden, or b) some common sense

Re: PR85463 '[nvptx] "exit" in offloaded region doesn't terminate process' (was: [patch, libfortran, committed] Implement stop_numeric for minimal targets)

> Mapping exit to abort is weird, For Fortran, this is mapping STOP with a numeric code to abort. The Fortran standard does not apply in this case. What does the OpenACC standard say about STOP in an offloaded region? Regards, Thomas

Re: [patch, fortran] Fix PR 85387

Hi Andre, this looks good. Ok for trunk. Thanks for the patch. Committed as r259384. Thanks for the quick review! Looking at the serious regressions from the gcc home page, we are fast approaching the gcc 8 release. Serious regressions are below 100, and there are currently only So, if

[patch, fortran] Fix PR 85387

Hello world, the attached patch fixes the PR, an 8 regression caused by trying to convert a nested implied DO loop to an array for a case where this was not possible. Regression-tested. OK for trunk? Regards Thomas 2018-04-14 Thomas Koenig PR

[patch, middle-end] Fix PR 82976, non-trivial conversion at assignment

Hello world, the attached patch fixes a middle-end bug, which caused a Fortran regression. The solution was given by Andrew on IRC and in the PR, I did the testing. Regression-tested with "configure --enable-languages=all" and "make -k check" on x86_64-pc-linux-gnu. OK for trunk? Regards

[patch, libfortran] Fix PR 88235, buffer overrun in matmul

Hello world, the attached patch fixes a buffer overrun in matmul, an 8 regression. No test case since this was only detectable with the address sanitizer or with valgrind. Regression-tested on trunk. OK? Regards Thomas 2018-04-06 Thomas Koenig PR

[patch, libfortran, committed] Implement stop_numeric for minimal targets

Hello world, the recent patch to make the gfortran and libgomp testsuites more standard conforming, by replacing CALL ABORT() with STOP N, led to numerous testsuite failures on nvptx because stop_numeric was not implemented in minimal.c. I have committed the patch below in r259072 as obvious

Re: [patch, fortran] Simplify constants which come from parameter arrays

Am 03.04.2018 um 17:21 schrieb Dominique d'Humières: Hi Dominique, The new patch regtest fine now. However as said on IRC this looks as a kludge made necessary by a questionable (invalid) test. What I want to avoid is to have first an error and then a warning for the same thing. If we say

Re: [patch, fortran] Fix PR 85102, take 2

Hi Steve, else gfc_free_expr (n); Don't you need the above changes to avoid leaking memory? Correct. OK with those changes? Regards Thomas

[patch, fortran] Fix PR 85102, take 2

Hello world, here is the second version of the fix for PR 85102. This is a much more general approach, which actually uses simplification (while avoiding some "interesting" regressions when resolving, or simplifying, too soon...) Thanks to Dominique for the hint about the problem with my first

Re: [patch, fortran] Simplify constants which come from parameter arrays

Hi Dominique, If I am not mistaken, the patch causes: FAIL: gfortran.dg/pr71935.f90 -O (test for excess errors) FAIL: gfortran.dg/substr_6.f90 -O0 execution test FAIL: gfortran.dg/substr_6.f90 -O1 execution test FAIL: gfortran.dg/substr_6.f90 -O2 execution test FAIL:

[patch, fortran, committed] Fix error caused by running front-end optimizatins after error

Hello world, I have just committed r258900 as obvious on trunk to fix an out-of-memory error in front-end optimization, which was caused by gfortran's AST being in an inconsistent state. I suspect that this will also fix other, as yet unknown errors. I will backport to the other affected

Re: [Patch, fortran] PR84931 - Expansion of array constructor with constant implied-do-object goes sideways

Hi Paul, Bootstraps and regtests on FC27/x86_64 - OK for trunk, 7- and 6-branches? OK, and thanks for catching these extra cases! In general, I think we should not modifying original test case unless it is necessary, so I would prefer if you could add the extra tests to a separate test case.

Re: [patch fortran] PR 84924 - Erroneous error in C_F_POINTER

Hi Dominique, The attached patch allows scalar noninteroperable scalar derived type with -std=f2003 and -std=f2008. Regstrapped on x86_64-apple-darwin17. OK for trunk? OK. Regards Thomas

[patch, fortran] Simplify constants which come from parameter arrays

Hello world, the attached patch potentially saves some space in the object file by simplifying access to individual elements of a parameter array, which means that the original parameter may not be needed any more. Regression-tested. OK for trunk? Regards Thomas 2018-03-25 Thomas

[patch, fortran] Fix type conversion in large array constructors with iterators

Hello world, the attached patch fixes the bug that Steve found; the patch itself simply makes sure to copy a constructor instead of only the value of the constructor when converting types. Regressoin-tested. OK for trunk? Maybe this is also a candidate for gcc-7, because of the silent

Re: [PATCH] PR fortran/65453 -- procedure statement vs subprogram name clash

Hi Steve, The attached patch fixes an ICE by detecting a name clash between a procedure statement and a contained subprogram. Regression tested on x86_64-*-freebsd. The patch is OK. Thanks! Regards Thomas (In case anybody is wondering about my e-mail address: I have a new one and