Re: [PATCH, committed] [9/10/11 Regression] PR fortran/95104 - Segfault on a legal WAIT statement

Am 28.05.20 um 21:58 schrieb Harald Anlauf: The initial commit for this PR uncovered a latent issue with unit locking in the Fortran run-time library. Add check for valid unit. This only came up because Solaris, unlike Linux, links the pthreads library by default, so it will not be found in a

Re: [PATCH] libgfortran: Export forgotten _gfortran_{,m,s}findloc{0,1}_c10 [PR95390]

Hi Jakub, Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk and 10.2? OK. Thanks a lot! Regards Thomas

Re: [PATCH, committed] [9/10/11 Regression] PR fortran/95104 - Segfault on a legal WAIT statement

Hi Harald, There are two possible fixes for this: (1) guard the call to unlock_unit by: diff --git a/libgfortran/io/transfer.c b/libgfortran/io/transfer.c index cd51679ff46..296be0711a2 100644 --- a/libgfortran/io/transfer.c +++ b/libgfortran/io/transfer.c @@ -4508,7 +4508,8 @@ st_wait_async

Re: [PATCH, committed] [9/10/11 Regression] PR fortran/95104 - Segfault on a legal WAIT statement

Am 26.05.20 um 23:33 schrieb Harald Anlauf: Committed as obvious. The invalid NULL pointer dereference was discovered by Steve Kargl. Will backport in a few days, when I figure out how to do it now. Thanks for committing this. The way to backport now is to first run

Re: [PATCH] PR fortran/95090 - ICE: identifier overflow

Am 26.05.20 um 23:16 schrieb Harald Anlauf: Yet another obvious case of insufficient size of a temporary buffer. OK for master? Yes. Thanks a lot! Regards Thomas

Re: [PATCH] PR94397 the compiler consider "type is( real(kind(1.)) )" as a syntax error

Hi Mark, ping the patch looks good do me. Regards Thomas

Re: [PATCH] Fortran : ICE in gfc_trans_label_assign PR50392

Hi Mark, ping Looks good. Thanks!

Re: PR libfortran/95195 - improve runtime error for namelist i/o to unformatted file

Hello Harald, Without the patch below, an attempted namelist write to an unformatted file - which is prohibited by the standard - would generate the following runtime error: At line 12 of file pr95195.f90 (unit = 10, file = 'test.dat') Fortran runtime error: End of record followed by some

Re: [PATCH] PR fortran/95089 - ICE in gfc_get_derived_type, at fortran/trans-types.c:2843

Hi Harald, Another rather obvious case of a buffer too small to hold a name-mangled symbol, this time with coarrays enabled. OK for master? OK. Thanks!

Re: [Patch] PR fortran/95106 - truncation of long symbol names with EQUIVALENCE

Hi Harald, OK for master? The patch is OK. Regarding the test case - I think it should be OK. If not, expect to hear from people soon, you could then still restrict it to Linux (or something else along those lines). Regards Thomas

[patch, fortran] Fix memory leaks for finalized types

will be interesting to see if any other finalizer bugs are affected. So, OK for trunk and for backporting to all affected branches? Regards Thomas Finalization depends on the expression, not on the component. gcc/fortran/ChangeLog: 2020-05-24 Thomas Koenig PR fortran/943

[patch, fortran, committed] Fix PR 95191, hang on invalid ID for WAIT

: 2020-05-23 Thomas Koenig PR libfortran/95191 * libgfortran.h (libgfortran_error_codes): Add LIBERROR_BAD_WAIT_ID. libgfortran/ChangeLog: 2020-05-23 Thomas Koenig PR libfortran/95191 * io/async.c (async_wait_id): Generate error if ID is higher

Re: New mklog script

Hi, what's currently in trunk (as of a few hours ago) fails for me with File "contrib/mklog.py", line 36, in from unidiff import PatchSet ModuleNotFoundError: No module named 'unidiff' I think this is an error which would have to be taken into account one way or another - maybe include

Re: [PATCH] libgfortran: Use __builtin_cpu_is/__builtin_cpu_supports

Am 21.05.20 um 07:53 schrieb H.J. Lu via Fortran: * m4/matmul.m4: Don't include . Use __builtin_cpu_is/__builtin_cpu_supports * generated/matmul_c10.c: Regenerated. * generated/matmul_c16.c: Likewise. * generated/matmul_c4.c: Likewise. *

Re: ChangeLog files - server and client scripts (git cherry-pick)

Hm, one question: I find the r11-1234 type commit to be much more readable, in ChangeLog files and everywhere else. Would it be possible to have that format instead of "cherry picked from commit $HEX_SOUP" ?

Re: [PATCH] x86: Move cpuinfo.h from libgcc to common/config/i386

Am 19.05.20 um 04:16 schrieb H.J. Lu via Fortran: Tested on Linux/x86 and Linux/x86-64. OK for master? Libfortran parts are OK. Regards Thomas

Re: PR fortran/95053 - division by zero constants

Am 15.05.20 um 22:33 schrieb Harald Anlauf: Here's a new attempt to finally fix this PR and any known fallout. In order to handle division by zero in declarations, but still accept the code snippet adapted from 521.wrf_r (from spec2017), I removed the hunk that was added to fix PR94399, and

[patch, libfortran, committed]

Koenig PR libfortran/95119 * io/close.c (close_status): Add CLOSE_INVALID. (st_close): Return early on invalid STATUS parameter. 2020-05-14 Thomas Koenig PR libfortran/95119 * testsuite/libgomp.fortran/close_errors_1.f90: New test. diff --git a/libgfortran

Re: [Patch] PR fortran/93499 - ICE on division by zero in declaration statements

Hi Harald, the attached should be mostly self-explaining. Division by zero handling appeared to be incomplete. It was not dealt with properly when occurring in declaration statements. We now try to handle this. OK for mainline? OK. Thanks for the patch! Regards Thomas

Re: [Patch] (general Fortran + OpenMP) [Fortran] Fix/modify present() handling for assumed-shape optional (PR 94672)

Hi Tobias, For assumed shape, gfortran generates an "arg.0 = arg->data" artificial variable – and with optional one has something like if (arg != NULL && arg->data != NULL)   {     arg.0 = arg->data;     lbound.0 = ...   } And an "if (present(arg))" becomes "if (arg != NULL && arg->data

Re: [PATCH] gfortran: Get asan library from TEST_ALWAYS_FLAGS

Hi H.J., I checked in this patch to fix: https://gcc.gnu.org/pipermail/gcc-regression/2020-May/072549.html Thanks for the fix!

Re: [patch, fortran][8/9/10 Regression] PR59107 Fortran : Spurious warning message with -Wsurprising

Am 27.04.20 um 11:50 schrieb Mark Eggleston: On 27/04/2020 09:56, Thomas Koenig wrote: Am 27.04.20 um 09:51 schrieb Mark Eggleston: Please find attached three slightly different patches based on a patch for PR59107 originally developed by Janus Weil and Dominique d'Humieres for gcc-5

[patch, fortran, testsuite] Subdirectory for -fsanitize=address tests

Hello world, because the test case for PR 94788 requires -fsanitize=address to expose the double free, I have created a subdirectory under gfortran.dg where such test cases can go. I have tested this with make check-fortran RUNTESTFLAGS="asan.exp=*" and it works; with a compiler that

Re: [patch, fortran] Fix PR 93956, wrong pointer when returned via function

Am 21.04.20 um 23:55 schrieb Thomas Koenig: Hello world, this one took a bit of detective work. ... and also caused a regression, see PR 94788. Reverted on trunk so far, so the upcoming release is OK. This will still take some more work, I suppose... Regards Thomas

Re: [patch, fortran][8/9/10 Regression] PR59107 Fortran : Spurious warning message with -Wsurprising

Am 27.04.20 um 09:51 schrieb Mark Eggleston: Please find attached three slightly different patches based on a patch for PR59107 originally developed by Janus Weil and Dominique d'Humieres for gcc-5. The last comment regarding the patch was on 2015-03-21 consequently the code has moved on

Re: [patch, fortran] Fix PR 93956, wrong pointer when returned via function

Hi Paul, You didn't attach the testcase but never mind, I am sure that it is OK :-) You're right. I thought I had it in the git diff, but then again, I am still learning the niceties (and not-so-niceties) of git. Test case is attached, for completeness. OK for trunk and, if you feel like

Re: [Patch v2, fortran] PR fortran/90350 - ubound ICE on assumed size array even though explicit bound is specified

Hi Jose, On 21/04/20 16:38, Thomas Koenig wrote: Do you have commit privileges? It not, I can commit it for you. No i do not. I would be grateful if you could. Done, as https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=808a6eadda1a353ce3a70556feac128580491b24 . Thanks a lot

[patch, fortran] Fix PR 93956, wrong pointer when returned via function

rds Thomas 2020-04-21 Thomas Koenig PR fortran/93956 * expr.c (gfc_check_pointer_assign): Also set subref_array_pointer when a function returns a pointer. * interface.c (gfc_set_subref_array_pointer_arg): New function. (gfc_procedure_use): Call it. 2020-04

Re: [Patch v2, fortran] PR fortran/90350 - ubound ICE on assumed size array even though explicit bound is specified

Hi Jose, Proposed patch to Bug 90350 - ubound ICE on assumed size array even though explicit bound is specified Patch tested only on x86_64-pc-linux-gnu. Best regards, José Rui Looks good. Do you have commit privileges? It not, I can commit it for you. Regards Thomas

[patch, committed] Add numerous symbol attributes to -fdump-fortran-original

where attributes are not what they should be. If you see anything that is still missing, please freel free to add. Committed as obvious (no user impact) after testing that the compiler still compiles :-) Regards Thomas 2020-04-20 Thomas Koenig * dump-parse-tree.c (show_attr

[patch, committed] Fix for PR 91800

Hello world, I just committed as obvious (alternatively, reviewed and committed) Steve's patch for PR 91800 from the PR, after regression-testing. Regards Thomas PR 91800 - reject Hollerith constants as type initializer. 2020-04-20 Steve Kargl Thomas Koenig PR

Re: [Patch, fortran] PR fortran/90350 - ubound ICE on assumed size array even though explicit bound is specified

Am 19.04.20 um 20:03 schrieb José Rui Faustino de Sousa via Fortran: Hi Thomas! > ? In other words, maybe a check on the upper bound > of the last dimension would be better? > You mean enforcing: C928 (R921) The second subscript shall not be omitted from a subscript-triplet in the last

Re: [Patch fortran/93364] [9/10 Regression] ICE in gfc_set_array_spec, at fortran/array.c:879

Hi Harald, The attached patch fixes that. OK for mainline / backport to 9-branch? OK for both. Thanks a lot for the patch! Regards Thomas

Re: [Patch, fortran] PR fortran/90350 - ubound ICE on assumed size array even though explicit bound is specified

Hi Jose, first, thanks for coming on board! A question: Do you have a copyright assignment yet? This patch is probably short enough that it can be accepted without it, but if you're planning to contribute more (which I certainly hope) then it would make sense to do this. Regarding your patch,

Re: [patch, fortran] Fix PR PR93500

Hi Fritz, First, it appears if simplify_bound_dim returns _bad_expr (and a div/0 occurs) then this code will free _bad_expr. I'm not sure whether or not that can actually occur, but it is certainly incorrect, since _bad_expr points to static storage. The only other possible case is bounds[d] ==

[patch, fortran] Fix PR PR93500

2020-04-16 Thomas Koenig PR fortran/93500 * resolve.c (resolve_operator): If both operands are NULL, return false. * simplify.c (simplify_bound): If a division by zero was seen during bound simplification, free the corresponcing expression

Re: [patch, fortran] Fix ICE on invalid, PR 94090

Hi Fritz, While you're touching the code anyway, how would you feel about replacing the nearby "goto done"s with a chain of "else if"? There's really no reason I can see for goto here, since the block following the conditions is already "done". I think this would really be pushing things at

Re: [patch, fortran] Fix ICE on invalid, PR 94090

Am 15.04.20 um 12:33 schrieb Tobias Burnus: On 4/15/20 12:26 PM, Thomas Koenig via Fortran wrote: +   /* Turn erros into warnings with -std=gnu and -std=legacy, Only glanced at it – but can you also fix the old* typo "erro(r)s"? Yes, I think I can manage that :-

Re: [patch, fortran] Fix ICE on invalid, PR 94090

there, and at the target of a goto statement. So, here's an updated patch. OK for trunk? Regards Thomas 2020-04-13 Thomas Koenig PR fortran/94090 * gfortran.dg (gfc_compare_interfaces): Add optional argument bad_result_characteristics. * interface.c

[patch, fortran, committed] Fix PR 94270

artifical dummy arguments. 2020-04-14 Thomas Koenig PR fortran/94270 * interface.c (gfc_get_formal_from_actual_arglist): Always set artificial attribute for symbols. * trans-decl.c (generate_local_decl): Do not warn if the symbol is artifical. 2020-04-14 Thomas

Re: *ping* Re: [Patch][Fortran] Fix name conflict check for use-assoc (PR 92736)

Hi Tobias, *ping* OK. Thanks for the patch! Regards Thomas

[patch, fortran] Fix ICE on invalid, PR 94090

the ABI), so I changed that into a hard error. OK for trunk? Regards Thomas 2020-04-13 Thomas Koenig PR fortran/94090 * gfortran.dg (gfc_compare_interfaces): Add optional argument bad_result_characteristics. * interface.c (gfc_check_result_characteristics

Committed Fortran test case for PR

of the current gfortran maintainers. (I was going to write up what I did to commit this patch, but being surprised by error messages and then trying to get around them does not really make for a good recipe...) Regards Thomas 2020-04-12 Thomas Koenig PR fortran/94091

Re: [Patch, 10 Regression] fortran: ICE in gfc_match_assignment PR93600

Hi Mark, Please find attached a fix for PR93600. This builds on the patch originally submitted to the PR by Steve Kargl, the dreaded "Unclassifiable statement error" is replaced by the correct error message. It would have been posted earlier had not one of the test cases failed as a result

Re: [Patch, 9/10 Regression] fortran: ICE in build_entry_thunks PR93814

Hi Mark, Please find attached Steve Kargl's fix for PR93814. The attached patch does not match the ChangeLog; it seems to be for PR93484. Regards Thomas

Re: [Patch, fortran] PR93581 - [9/10 Regression] ICE in gfc_get_dataptr_offset, at fortran/trans-array.c:6951

Hi Paul, ***ping*** OK. Thanks for the patch! Regards Thomas

Re: [patch, fortran] PR93486 - ICE on valid with nested submodules and long submodule names

Am 01.03.20 um 23:42 schrieb Steve Kargl: PS: in general, after multiple pings, just commit the patch. ... well, maybe after a "If there is no reply within a couple of days, I will commit this" :-) Regards Thomas

Re: [Patch, fortran] PR92959 - ICE in gfc_conv_associated, at fortran/trans-intrinsic.c:8634

Hi Paul, Regtested on FC31/x86_64 - OK for trunk? OK. Thanks for the patch! Regards Thomas

Re: [Patch, fortran] PR92976 - [8/9/10 Regression][OOP] ICE in trans_associate_var, at fortran/trans-stmt.c:1963

Hi Paul, Regtested on x86_64/FC31 - OK for trunk and 8-/9- branches ? OK, and thanks for the patch. I think it makes sense to get this into gcc 9.3, which would need a backport before the 5th of March. Regards Thomas

Re: maxval on -inf and nan in Fortran

Am 28.02.20 um 17:58 schrieb Steve Kargl: Replacing MIN_EXPR/MAX_EXPR (everywhere?) would seem to be a pessimization for correctly written code. Also note the following part of changes.html for 9.2: The MAX and MIN intrinsics are no longer guaranteed to return any particular value in case one

Re: [PATCH] fortran: ICE using undeclared symbol in array constructor, PR93484

Hi Mark, Might need gfc_reduce_init_expr (e); here.  The kind type parameter should be a constant expression. Not needed. I've also checked use of the kind argument, it is evidently checked elsewhere: if k is allowed to be implicitly declared and is used as the kind argument

Re: [Regression, patch][Fortran] ICE in gfc_conv_constant_to_tree PR93604

Hi Mark, **ping** OK! Regards Thomas

Re: [9/10 Regression, fortran, patch] ICE in simplify_findloc_nodim, at fortran/simplify.c:5513

Hi Mark, OK for both trunk and gcc-9. Thanks for taking this up, and thanks to Steve for debugging this in the first place! Regards Thomas

Re: [patch, committed] Fix trailing space in diagnostic

Am 23.02.20 um 17:11 schrieb Thomas Koenig: Committed as simple and obvious, r10-6802-g7260547dbffd8e6442f99da8adf98ab0ce294e4e. Better with the patch, of course. diff --git a/gcc/fortran/interface.c b/gcc/fortran/interface.c index 429abc79ca2..4106fe5831b 100644 --- a/gcc/fortran/interface.c

[patch, fortran, committed] Add missing closing parenthises in error message.

Another trival patch. Regards Thomas Add missing closing parenthises in error message. 2020-02-23 Thomas Koenig PR fortran/93889 * interface.c (compare_parameter): Fix error message. diff --git a/gcc/fortran/ChangeLog b/gcc/fortran/ChangeLog index

[patch, committed] Fix trailing space in diagnostic

Committed as simple and obvious, r10-6802-g7260547dbffd8e6442f99da8adf98ab0ce294e4e. Regards Thomas Fix error message. 2020-02-23 Thomas Koenig PR fortran/93890 * interface.c: Replace "can not" by "cannot" and remove trailing

Re: [Patch, fortran] PR57710 - [OOP] [F08] _vptr not set for allocatable CLASS component inside BLOCK

Hi Paul, Regtested on FC31/x86_64 - OK for head? Looks good. Best of luck committing! Regards Thomas

Re: [patch, libfortran] Fix race condition in asynchronous I/O

Now committed to trunk after Jerry's OK, as https://gcc.gnu.org/g:3fe1910509e32d611b3a7b8503502103bc53b5e4 I have to say I still have trouble establishing a git workflow which works smoothly. You will notice an "asdf" in the commit message which was not really meant to be there... Regards

Re: [PATCH] libgfortran: Fix and simplify IO locking [PR92836]

Hi Janne, Simplify IO locking in libgfortran. The new IO implementation avoids accessing units without locks, as seen in PR 92836. It also avoids lock inversion (except for a corner case wrt namelist query when reading from stdin and outputting to stdout), making it easier to verify

Re: [9/10 Regression, PATCH] fortran: ICE in gfc_validate_kind(): Got bad kind [PR93580]

Hi Mark, OK for master and gcc 9 branch? Looks good. Thanks! Regards Thomas

Re: [8/9/10 Regression, patch][PR93714] ICE in gfc_check_same_strlen, at fortran/check.c:1253

Hi Mark, OK to commit? Yes, OK. Thanks a lot for the patch! Regards Thomas

Re: [Regression, patch][Fortran] ICE: Invalid expression in gfc_element_size PR93601

Hi Mark and Steve, OK to commit? Yes. Again, thanks a lot! Regards Thomas

Re: [Regression, patch][Fortran] ICE in gfc_typenode_for_spec PR93603

Hi Mark and Steve, OK to commit? OK (bordering on obvious). Thanks to both of you! Regards Thomas

[patch, libfortran] Fix race condition in asynchronous I/O

--tool=helgrind and valgrind --tool=drd, both of which showed no (new) failures for all of the async_io_*.f90 tests. So, OK for trunk and gcc-9? Regards Thomas 2020-02-17 Thomas Koenig PR fortran/93599 * io/async.c (destroy_adv_cond): Do not destroy lock

Re: [Patch] [OpenMP] Add missing parameters to omp_lib documentation (PR fortran/93541)

Hi Tobias, OK? – And for which branches? OK for all branches (assuming you checked with "make pdf" and "make dvi"). Thanks for doing this - our documentation is not always quite up to date... Regards Thomas

Re: [PATCH] libgfortran: Fix and simplify IO locking [PR92836]

Hi Janne, Simplify IO locking in libgfortran. The new IO implementation avoids accessing units without locks, as seen in PR 92836. It also avoids lock inversion (except for a corner case wrt namelist query when reading from stdin and outputting to stdout), making it easier to verify

Re: [patch, fortran] Fix PR 44960, accepts invalid reference on function

Hello world, I found an ommission in primary.c which prevented issuing a more specific error instead of "syntax error" for the case when a function was declared in an EXTERNAL statement, and I have now gone for the "Unexpected junk after foo" variant. Regression-tested. OK for trunk? Regards

Re: [patch, fortran] Fix PR 44960, accepts invalid reference on function

Am 18.01.20 um 12:44 schrieb Tobias Burnus: function_reference_1.f90:9:8:     9 | print *, foo(1)%a ! { dg-error "Syntax error" }   |    1 Error: Syntax error in expression at (1) The error message is not helpful at all. Well, yes. It is no better than what we currently have for

Re: [patch, fortran] Fix PR 44960, accepts invalid reference on function

Am 17.01.20 um 15:42 schrieb Steve Kargl: Gfortran probably should not try to guess what the user thought s/he wanted. The generic "Syntax error" would seem to apply here. To me, foo(1)%a looks much more like an array reference rather than a function reference. OK, so here's a patch which

[patch, fortran] Fix PR 44960, accepts invalid reference on function

Hello world, here is my first patch made from the git world. It certainly took enough time to work out how to to this, but I think I have it figured out now... Anyway, the fix is rather straightforward. We cannot have a reference on a function. If this slipped through on parsing, let's issue

Re: [patch, fortran] Fix PR 65428, ICE on nested empty array constructors

Hi Tobias, I am not completely happy about the introduction of yet another two global variables, but I also do not see an easy way out. Hence: OK. Actually, I wasn't too happy myself, but, like you, I didn't find anything better. I was playing around with the following test case – you might

*ping* [patch, fortran] Fix PR 65428, ICE on nested empty array constructors

Am 02.01.20 um 23:35 schrieb Thomas Koenig: Hello world, the attached patch fixes an ICE where an array constructor containing an empty array constructor with a type didn't get the type from the inner constructor. The solution is to stash the type away in yet another variable and only use

Fortran patches to be reviewed (was: [Patch, Fortran] PR91640 – Fix call to contiguous dummy)

Hi Tobias, PS: I lost a bit the overview. Is there any patch pending review or otherwise pending? From my side, there is the patch for PR 65428, https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00040.html Apart from that, I don't see any outstanding patches. Regards Thomas

Re: [Patch, Fortran] PR 92994 – add more ASSOCIATE checks

Hi Tobias, Build on x86-64-gnu-linux. OK for the trunk? Looks good. Thanks for the patch! Regards Thomas

[patch, fortran] Fix PR 65428, ICE on nested empty array constructors

, and the type has not been set some other way. Regression-tested. OK for trunk? Regards Thomas Save typespec for empty array constructor. 2020-01-02 Thomas Koenig PR fortran/65428 * array.c (empty_constructor): New variable. (empty_ts): New variable

[patch, fortran, committed] Fix dependency for %re and %im

. 2020-01-01 Thomas Koenig PR fortran/93113 * dependency.c (gfc_dep_resolver): Handle REF_INQUIRY in switch for ref types. 2020-01-01 Thomas Koenig PR fortran/93113 * gfortran.dg/dependency_58.f90: New test. Index: dependency.c

Re: [patch, libfortran] Fortran 2018: Support d0.d, e0.d, es0.d, en0.d, g0.d and ew.d e0 edit descriptors

Hi Jerry, OK for trunk? Looks good. I also think that your approach that DEC stuff should be checked later is good. If it passes the testsuite, that's good enough for a commit. Thanks for the patch! Regards Thomas

*ping*[patch, fortran] Fix PR 91541, ICE on valid for INDEX

Am 19.12.19 um 08:23 schrieb Thomas Koenig: Regression-tested. OK for trunk? Ping?

*ping* [patch, fortran] Updated fix PR 92961, ICE on division by zero error in array bounds

Am 22.12.19 um 16:28 schrieb Thomas Koenig: here is an update for the fix for PR 92961, which also takes care of the second test case in the PR (included in the first one). The patch itself should be clear enough - make sure that there is a MATCH_ERROR on matching an array spec which contains

Re: [Patch] OpenACC – support "if" + "if_present" clauses with "host_data"

Hi Tobias, Build on x86-64-gnu-linux without offloading and with nvptx offloading. OK for the trunk? I can't really say a lot about OpenACC, but the changes do look reasonable. So, OK for trunk. Regards Thomas

[patch, fortran] Updated fix PR 92961, ICE on division by zero error in array bounds

for array spec and a division of zero error has been seen, return MATCH_ERROR. 2019-12-22 Thomas Koenig PR fortran/92961 * gfortran.dg/arith_divide_2.f90: New test. Index: gfortran.h === --- gfortran.h

Re: [Patch] PR92990 - fix error message for invalid argument of NULLIFY

Am 20.12.19 um 22:33 schrieb Harald Anlauf: The fix for PR70853 changed an ICE-on-invalid for NULLIFY into a misleading error message. The patch below rectifies that. OK for trunk? OK. Thanks for the patch! Regards Thomas

Re: *Ping* Introduce -finline-arg-packing

Hi Jakub, This patch broke: +FAIL: compiler driver --help=fortran option(s): "^ +-.*[^:.]\$" absent from output: " -finline-arg-packingPerform argument packing inline" That test verifies that the help texts of all options are terminated with dot or semicolon. Thanks, and sorry for

Re: [pach, fortran] Fix PR 92961, ICE on division by zero error in array bounds

the attached patch fixes an ICE in an array declaration where the specified size came from 0/0. This is an 8/9/10 regression. Actually, it does not fix all testcases in the PR, so some more tweaking is still needed. Regards Thomas

OpenACC regression and development pace

Hi, I just saw this: FAIL: gfortran.dg/goacc/finalize-1.f -O scan-tree-dump-times gimple "(?n)#pragma omp target oacc_enter_exit_data map\\(delete:MEM\\[\\(c_char \\*\\)[^\\]]+\\] \\[len: [^\\]]+\\]\\) map\\(to:del_f_p \\[pointer set, len: [0-9]+\\]\\) map\\(alloc:del_f_p\\.data

[pach, fortran] Fix PR 92961, ICE on division by zero error in array bounds

of the patch. Rather than try to transport state across I do not know how many levels of calls, I chose a global variable. Regression-tested. OK for all affected branches? Regards Thomas 2019-12-20 Thomas Koenig PR fortran/92961 * gfortran.h (gfc_seen_div0): Add declaration

Re: [Patch, Fortran] PR 92996 – fix rank resolution EXPR_ARRAY

Hi Tobias, One has the choice between (a) Using the location where the expression was defined (in the     scoping unit) – currently done     (i.e. replacing expr->where by expr->symtree->n.sym->where) (b) using the location where the parameter is used, i.e. keeping     expr->where despite

[patch, fortran] Fix PR 91541, ICE on valid for INDEX

, but for this bug fix, I left the functionality as is). Regression-tested. OK for trunk? Regards Thomas 2019-12-19 Thomas Koenig PR fortran/91541 * intrinsic.c (add_sym_4ind): New function. (add_functions): Use it for INDEX. (resolve_intrinsic): Also

Re: [Patch, fortran] PR92753 - [9/10 Regression] ICE in gfc_trans_call, at fortran/trans-stmt.c:392

Hi Paul, Regtested on FC31/x86_64 - OK for 9- and 10- branches? OK. Thanks for the patch! Regards Thomas

*Ping* Introduce -finline-arg-packing

Am 10.12.19 um 22:22 schrieb Thomas Koenig: Steve made an excellent suggestion: -finline-arg-packing . So, OK with that change? In other words, is https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00485.html OK with renaming the option to -finline-arg-packing ? Regards Thomas

Re: [Patch, Fortran] PR92898 - [9/10 Regression] ICE in gfc_check_is_contiguous, at fortran/check.c:7157

Hello Harald, Index: gcc/fortran/check.c === --- gcc/fortran/check.c (Revision 279183) +++ gcc/fortran/check.c (Arbeitskopie) @@ -7154,7 +7154,9 @@ bool gfc_check_is_contiguous (gfc_expr *array) { if (array->expr_type ==

[patch, fortran, committed] Fix PR 91643, repacking of assumed rank argument

Hello world, this fixes a regression introduced by my inline repacking patch. With the test case, it is simple and obvious enough - do not repack an assumed rank argument (which makes no sense). Committed as obvious and simple as r279203 after regression-testing. 2019-12-10 Thomas Koenig

Re: [patch, fortran] Introduce -finline-pack

Am 09.12.19 um 17:30 schrieb Thomas Koenig: Maybe -finline-repack would be a better name? -finline-internal-pack? Steve made an excellent suggestion: -finline-arg-packing . So, OK with that change? Regards Thomas

[patch, fortran, committed] Fix PR 92863, 'ICE in gfc_typename

ough to cure the ICE. Regards Thomas 2019-12-10 Thomas Koenig PR fortran/92863 * misc.c (gfc_typename): If derived component is NULL for derived or class, return "invalid type" or "invalid class", respectively. 2019-12-10 T

Re: [patch, fortran] Introduce -finline-pack

Hi Richard, Just as a suggestion, maybe we'd want to extend this to other intrinsics in future so a -fno-inline-intrinsic=pack[,...] is more future proof? (I'd inline all intrinsics by default thus only provide the negative form). You can avoid the extra option parsing complexity by only

[patch, fortran] Add NULL check before checking interfaces

Thomas Koenig PR fortran/92764 * interface.c (gfc_procedure_use): Check for existence of derived component before using (twice). 2018-12-08 Thomas Koenig PR fortran/92764 * gfortran.dg/interface_44.f90: New test. Index: interface.c

[patch, fortran] Fix PR 92755

Koenig PR fortran/92755 * dependency.c (gfc_dep_resolver): Move skipping of _data ref into the loop. 2019-12-08 Thomas Koenig PR fortran/92755 * gfortran.dg/dependency_57.f90: New test. Index: dependency.c

[patch, fortran] Introduce -finline-pack

it off on a by-file basis if they don't want it. OK for trunk? Regards Thomas Introduce -finline-pack. 2019-12-07 Thomas Koenig PR middle-end/91512 PR fortran/92738 * invoke.texi: Document -finline-pack. * lang.opt: Add -finline-pack

*ping* [patch, fortran] Fix PR 91783

Am 24.11.19 um 18:09 schrieb Thomas Koenig: Hello world, this patch fixes a 10 regression in dependency checking. The approach is simple - if gfc_dep_resolver is handed references with _data, remove that. Regression-tested. OK for trunk? Ping?

[patch, fortran] Fix PR 91783

Koenig PR fortran/91783 * dependency.c (gfc_dep_resolver): Do not look at _data component if present. 2019-11-24 Thomas Koenig PR fortran/91783 * gfortran.dg/dependency_56.f90: New test. Index: fortran/dependency.c

<    1   2   3   4   5   6   7   8   9   10   >