Re: [PATCH] PR fortran/96086 - ICE in gfc_match_select_rank, at fortran/match.c:6645

Am 06.07.20 um 22:11 schrieb Harald Anlauf: More NULL pointer dereferences on invalid code, detected by Gerhard. Regtested on x86_64-pc-linux-gnu. OK for master? OK. This is actually a regression (does not occur with gcc-8), so if you feel like it, feel free to backport this. However, if yo

Re: [PATCH] Fortran : accepts pointer initialization of DT dummy args, PR45337

Am 09.07.20 um 09:51 schrieb Mark Eggleston: Please find attached a fix for this PR. I think the discussion of intent muddied the waters for this PR. As I understand it initialisation of variables implies the save attribute. The save attribute is incompatible with the dummy attribute so an err

Re: [PATCH] Fortran : Implicitly type parameter causes an invalid error, PR96038

Am 09.07.20 um 10:00 schrieb Mark Eggleston: Please find attached patch for fix PR.  The original patch was provided by Steve Kargl in the initial problem report. OK to commit to master and backport? OK for master. Same remark as just - not a regression, so if you decide to backport, please

Re: [PATCH] Fortran : ICE in gfc_find_array_ref(): No ref found PR95981

Hi Mark, Fortran  :  ICE in gfc_find_array_ref(): No ref found PR95981 OK for master. With regards to backporting, copy & paste my remarks from the previous e-mails :-) Best regards Thomas

Re: [PATCH, part 2] PR fortran/95980 - ICE in get_unique_type_string, at fortran/class.c:485

Hi Harald, This is not a regression, so I don't think we will need a backport. understood. On the downside, another patch I was working on unfortunately partially overlaps with the present one in resolve.c. At some point, there will be a conflict between the work involved in either producing

[patch, fortran, committed] Fix PR 96073, ICE on new warning

Hello world, I have just committed the attached patch to master as obvious and simple. Explanation is in the ChangeLog below. Best regards Thomas Fix ICE on warning with new interface check (the patch for PR 27318). In the test case, there was a warning about INTENT where an EXTERNAL

*ping* [patch, fortran] Fix PR 96018, wrong code caused by implicit_pure

Ping? the attached patch fixes a 9/10/11 regression where we left over an implicit_pure attribute when a non-implicit_pure procedure was called. The fix is explained in the ChangeLog.

Re: *ping* [patch, fortran] Fix PR 96018, wrong code caused by implicit_pure

Hi Paul, The patch looks fine to me but I have two questions: (i) Why is this not done in resolve.c? Of course it doesn't matter where the function resides :-) I put it into frontend-passes.c because it makes heavy use of gfc_code_walker, and out of habit. If you prefer, I can of course move

[patch, fortran, committed] Fix PR 96220, error with -fc-prototypes

Hello world, I have just committed the attached patch as simple and obvoius. The problem was that, for a test case like module f_global_vars_m use, intrinsic :: iso_c_binding, sp => c_float, dp => c_double implicit none real(dp), bind(c) :: one= 1.0_dp, four= 4.0_dp end module f_global_vars_m t

Re: **PING** [PATCH] PR fortran/89574 - [8/9/10/11 Regression] ICE in conv_function_val, at fortran/trans-expr.c:3792

Hi Harald, **ping** OK, that solution looks really good. Also, definetely worth backporting. Thanks a lot for the patch! Best regards Thomas

Re: [Patch] OpenMP: Update gcc/fortran/*.texi

Hi Tobias, can you also update https://gcc.gnu.org/gcc-11/changes.html ? Best regards Thomas

Re: [Patch fortran] PR 93567 - G edit descriptor uses E instead of F editing in rounding mode UP

Hi Dominique, also committed. Regards Thomas

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

Hi Dominique, I have committed the patch after regression-testing. Dou you want to backport this, as well? (And if one of my e-mails bounced, you can try the other one. Originally, I wanted to switch completely, but the bouncing problem made that impossible...) Best regards Thomas

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

Am 24.07.20 um 23:19 schrieb dhumieres.domini...@free.fr: Le 2020-07-24 20:50, Thomas Koenig a écrit : Hi Dominique, I have committed the patch after regression-testing. Thanks. Dou you want to backport this, as well? IMO it is worth the work. OK. The patch for PR 93592 is now

Re: [PATCH] Fortran : Don't warn for LOGICAL kind conversion PR96319

Hi Mark, LOGICAL values fit regardless of kind so warnings are unnecessary. The PR referred to the warning produced for -Wconversion.  This patch also suppresses the warning for -Wconversion-extra. -Wconversion produces "Possible change of value in conversion from LOGICAL(4) to LOGICAL(1) ..

Re: [PATCH] Fortran : ICE in gfc_conv_scalarized_array_ref PR53298

Hi Mark, Please find attached a fix for PR53298. OK. Thanks for the patch! Regards Thomas

Re: [PATCH] Map filename from print in gfortran with -ffile-prefix-map (PR96069)

Hi Yichao, Forwarding to fort...@gcc.gnu.org as suggested by Dominique d'Humieres. On Sun, Jul 5, 2020 at 9:29 PM Yichao Yu wrote: I think this remapping should happen with `file-prefix-map` but shouldn't with `debug-prefix-map` (though if it happens for both it's also not too bad) and I be

Re: [Patch, fortran] PR96320 - gfortran 8-10 shape mismatch in assumed-length dummy argument character array

Hi Paul, This is my first foray into gfortran for quite a little while so I am going cautiously on this 'obvious' patch. The comment in the patch and the ChangLog are clear enough that no further explanation is needed. Regtests on FC31.x86_64 - OK for trunk? If I read the PR correctly, this i

Re: [Patch, fortran] PR96325 - Unclassifiable statement with syntax similar to a type-bound procedure call is accepted

Hi Paul, The attached patch regtests on FC31/x86_64 - OK for trunk? OK. Thanks for the patch! Best regards Thomas

[patch, fortran] Compile-time check for change in DO variable in contained procedures

Hello world, the attached patch issues an error for something that I am sure most people did at least once (I know I did), something like do i=1,10 call foo end do ... contains subroutine foo do i=1,5 ... end do which is, of course, illegal, but the programmer's fault. We

Re: [patch, fortran] Compile-time check for change in DO variable in contained procedures

Hi Paul, This is OK by me. Committed (or should I say "pushed"?), thanks! Is it worth testing the INTENT variants? I added a test for INTENT(INOUT), here's the version of the test case that was committed. Best regards Thomas program main implicit none integer :: i1, i2, i3, i

Re: [patch, fortran] Compile-time check for change in DO variable in contained procedures

Hi Paul, I must say that I was thinking rather more of the INTENT(IN) case to make sure that it is accepted. Ah, I misunderstood that. You're right - also check legal code :-) I've committed the attached test case as obvious (after verifying that it passes. It checks against functions and su

Committed Fortran test case for PR

es most 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 for

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

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

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, committed] Fix PR 94270

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

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. * interf

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

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 st

[patch, fortran] Fix PR PR93500

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

Re: [patch, fortran] Fix PR PR93500

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

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

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 dim

[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

[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

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, fortran] Fix PR 93956, wrong pointer when returned via function

Regards 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. 20

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 for the

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 it

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 som

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

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

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

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

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

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: 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] 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. * generated/

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 i

[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

[patch, fortran] Fix memory leaks for finalized types

it 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 fortra

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

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

Re: [PATCH] Fortran : ICE in gfc_trans_label_assign PR50392

Hi Mark, ping Looks good. Thanks!

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] 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, 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 contrib/gcc-git-customiza

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

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

PING**(5./7.) [patch, fortran] Fix memory leaks for finalized types

Am 24.05.20 um 20:55 schrieb Thomas Koenig via Fortran: Hello world, this patch fixes a 8/9/10/11 regression, where finalized types were not finalized (and deallocated), which led to memory leaks. Hi, OK for trunk? The patch is simple enough (and the regression bad enough) that I'll c

Re: [PATCH] FAT library support for libatomic, libgfortran, libgomp, libstdc++

Hi David, After trying various options, the best solution seems to be the inclusion of target-specific Makefile fragments. Directly adding the rules to the Makefiles conflicts with Automake conditionals syntax. And Makefile fragments are easily extendible to other targets, such as Darwin. It avo

Re: [Patch, fortran] PR fortran/66833,67938,95214 ICE on using assumed rank character array

Hi Jose, Proposed patch to PRs 66833, 67938 and 95214 ICE(s) on using assumed rank character array in different situations. Reviewed and committed with some trival changes: It is better not to use STOP codes > 255, so I just counted them up. Some changes to the ChangeLog: Mentioned all PRs t

Re: [PATCH] Fortran : ICE in maybe_canonicalize_comparison_1 PR92993

Hi Mark, OK to commit? Yes. As a general rule, I think that committing test cases for PRs that have been fixed by something else falls under the "obvious and simple" rule - no approval required. Thanks! Regards Thomas

Re: [PATCH] fortran/95509 - fix spellcheck-operator.f90 regression

Hi Tom, My earlier patch to add case handling to the spell checker caused a Fortran regression. I believe I must have misread the test results. This patch fixes the problem by changing the cutoff. I chose this value because the previous patch effectively multiplied the result of get_edit_dist

Re: [Patch, fortran] PR 98022

Hi Paul, Fortran: Enable inquiry references in data statements [PR98022]. This patch speaks for itself. Regtests on FC31/x86_64 - OK for master? Looks good. Thanks a lot for the patch! Best regards Thomas

[patch, fortran] Optionally improve debugging of auxiliary variables

Hello world, I have struggled with debugging the GENERIC generated by the Fortran front end because it is only possible to look at the code via -fdump-tree-original, but it is not possible to inspect the values; additionally, the D.3456 form makes it hard to read which variable is which. This pa

[patch, fortran, committed] Improved parse dump for coarrays

Hello world, I have just committed as obvious and simple (and as no-user-impact) an improvement to the tree dump, plus the ability to call debug(array_reference) in the debugger. The revision is r11-5967. The dump for a coarray assignment now looks like ASSIGN main:a(FULL)[THIS_IMAGE] 4.200

Re: [patch, fortran] Optionally improve debugging of auxiliary variables

Hi Iain, If it’s part of a symbol used by the rest of the toolchain (assembler, linker debugger) then it’s also important to note that some OS/tool pairs might be more constrained than the one you’ve tested.  In particular, some assemblers will not accept all characters in an  identifier.

Re: [patch, fortran] Optionally improve debugging of auxiliary variables

Hi Iain, yes a configure option is a possible way around a conflict. I was thinking more along making it a run-time option. This is an option which will only be used by a developer, who should know what the source code contains and what the tool chain supports (and who can try out an unders

Re: [patch, fortran] Optionally improve debugging of auxiliary variables

Hi Iain, I guess the hard thing is for the developer to know that (s)he wants the option and what to do when a conflict occurs. Actually, I just hit on a much simpler solution. We translate all symbols to lower case (except for those with BIND(C), which do not matter in this context). So, p

Re: [patch, fortran] Optionally improve debugging of auxiliary variables

Am 13.12.20 um 20:59 schrieb Iain Sandoe via Fortran: For bonus points you can prefix with _GFC_ which puts the symbols in the implementation’s namespace (at least for C-Family purposes) and therefore means that a clash with a user’s symbols is the user’s problem … I don't think this is necessa

Re: [PATCH] PR fortran/98284 - ICE in get_array_index

Hi Harald, ICE-on-invalid: testcase by Arseny, draft patch by Steve, slightly polished and regtested by me on x86_64-pc-linux-gnu. OK for master. Thanks for the patch! Best regards Thomas

Re: [PATCH] PR fortran/98307 - Dependency check fails when using "allocatable"

Hi Harald, OK for master? Since we generate wrong code under the given circumstances, what do people think about backports? OK for master. The patch is also simple enough that the risk of regressions is almost nil, so backports are also OK. Best regards Thomas

Re: [Patch] Fortran: Delay vtab generation until after parsing [PR92587]

Hi Tobias, Calling gfc_find_vtab during resolution during parsing comes too early for finalizers. This patch just moves it to the resolution, which seems to be the simplest solution. Ah, finalizers - one area where we still are deficient WRT Fortran 2003. Thanks for doing things in this area!

Re: [Patch] Fortran: Delay vtab generation until after parsing [PR92587]

Hi Tobias, Thanks for the quick review! It helps when I'm on holiday :-) Best regards Thomas

Re: [PATCH] PR fortran/93685 - [9/10/11 Regression] ICE in gfc_constructor_append_expr, at fortran/constructor.c:135

Hi Harald, OK for master? As it is a regression, I intend to backport as seems applicable. Looks good to me. Thanks for the patch! Best regards Thomas

Re: [OG10] Fortran: delinearize multi-dimensional array accesses

Hi Sandra, The attached patch implements delinearization of array accesses in the Fortran front end, something that has been discussed for a long time. Definitely - among others, this is the subject of PR 14741, which is by now quite historic. I've been asked to try to get this patch commit

Re: Ping: [Patch, fortran] PR97694 - ICE with optional assumed rank class(*) argument (and PR97723)

Hi Paul, Ping! OK. Thanks a lot! Best regards Thomas

Re: [Patch, fortran] PR93833 - [8/9/10 Regression] ICE in trans_array_constructor, at fortran/trans-array.c:2566

Hi Paul, Retested on FC33/x86_64 - OK for master, then 9&10 branches in a few weeks? OK. Thanks a lot for the patch! Best regards Thomas

Re: [Patch, fortran] PR97612 [F08] Structure constructor of type with nested allocatable array components fails to compile

Hi Paul, Regtests on FC33/x86_64 - OK for master? OK. Thanks for the patch! Best regards Thomas

[patch, shared coarrays, committed] Fix

Hello world, I just committed the attached patch to the branch as https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=4726e39b0be3c0bc55e43d2d300f0d0b9529d883 . It is sometimes astonishing, if you shake code a bit, how many bugs came crawling out :-) Best regards Thomas Make STAT and E

[patch, shared memory coarray, committed] Fix SYNC IMAGES(*)

Hi, a rather obvious patch for SYNC IMAGES(*) failing because it did not deal with a -1 argument. Make SYNC IMAGES(*) work by handling size of -1 in library. libgfortran/ChangeLog: * caf_shared/sync.c (sync_table): Change size argument and index to int. * caf_shared/syn

[patch, committed, coarray_native] Fix CO_REDUCE with RESULT_IMAGE

Hi, I just committed the attached patch to the branch. I had also merged the trunk to branch previously, so it should be more or less up to date by now. Best regards Thomas Fix CO_REDUCE with RESULT_IMAGE. gcc/fortran/ChangeLog: * trans-array.c (gfc_conv_ss_descr

Re: [PATCH] PR fortran/78746 - invalid access after error recovery

Hi Harald, OK for master? Open branches where testcase class_61.f90 exists? OK for both (as you wrote, this one is really obvious). Best regards Thomas

[patch, fortran shared coarrays, committed]

Hello world, after the discussions about PTHREAD_PROCESS_SHARED and after observing that on Cygwin the program simply hangs because this flag is not implemented there, the best way is to check for errors and exit with a clear error message instead of some mysterious hang. Committed after OK from

[patch, coarray_native, committed] Increase initial size on Darwin

Hello world, the patch (committed after Nicolas' OK) should make it possible to go one step further in testing with Darwin. So, it might now be possible to do another round of testing, to see if there are any other walls to hit :-) Best regards Thomas Use an initial shared memory size

Re: [PATCH] PR fortran/95530, PR fortran/95537 - Buffer overflows with long symbols

Am 05.06.20 um 18:45 schrieb Harald Anlauf: The testcases for fixes of buffer overflows did show some fallout in the testsuite that occurred only with suitably instrumented compilers. Bill Seurer provided useful backtraces on powerpc64 that helped to nail down the issues. To verifiy that the new

Re: [PATCH] PR fortran/95091 - Buffer overflows with submodules and long symbols

Hi Harald, There's another case of buffer overflows when F2008 submodules are used. Buffer sizes are further increased, and checks for overflow are put into place. OK for master? OK, also for the backport. Thanks a lot! Regards Thomas

[patch, fortran test suite, committed]

I just committed the attached test case as obvious. Added test case for a PR which has been fixed in the meantime. gcc/testsuite/ChangeLog: PR tree-optimization/50439 * gfortran.dg/loop_interchange_2.f: New test. C { dg-do compile } C { dg-options "-std=legacy

Re: [PATCH] fortran/95509 - fix spellcheck-operator.f90 regression

Hi Tom, Bernhard> Yes, this is probably OK although Fortran is case- Bernhard> insensitive. I think we lowercase names coming in from the Bernhard> source (at least for the internal identifier nodes), so we Bernhard> should not be affected by any case change. I already checked it in, but FWIW i

Re: [PATCH] fortran/95509 - fix spellcheck-operator.f90 regression

Hi Bernhard, For Fortran identifiers, that would be really good. Would you do that? Is it really needed? We do not enter internal helper names (class names, anything artificial, anything leading underscore or leading uppercase) to the suggestions proposals so should never actually recommend a

Re: [Patch, fortran] PR fortran/94022 - Array slices of assumed-size arrays

Hi Jose, Proposed patch to Bug 94022 - Array slices of assumed-size arrays. Patch tested only on x86_64-pc-linux-gnu. Reviewed, regression-tested and commited as r11-1228-g6a07010b774cb5a0b1790b857e69d3d8534eebd2 . Thanks for the patch! Regards Thomas

Re: [Patch, fortran] PR fortran/52351, 85868 Wrong array section bounds when passing to an intent-in pointer dummy

Hi Jose, Proposed patch to PRs 52351, 85868 Wrong array section bounds when passing to an intent-in pointer dummy. First, thanks for working on this and for this patch. Regarding the patch, there are a few style issues which I fixed for the commit. If you could try to adhere to a few more of

Re: [Patch, fortran] PR fortran/95331 - Unlimited polymorphic arrays have wrong bounds

Hi Jose, Proposed patch to PR95331 - Unlimited polymorphic arrays have wrong bounds. Patch tested only on x86_64-pc-linux-gnu. reviewed, ChangeLog reformatted, committed as r11-1235-g2ee70f5d161edd99a7af97d166b251bcf83cd91b . Thanks a lot for the patch! Do you have interest in getting write

<    9   10   11   12   13   14   15   16   >