Re: [PATCH] Fortran : Fill in missing array dimensions using the lower, bound (for review)

Hi Mark, Use -fdec-add-missing-indexes to enable feature. Also enabled by fdec. A warning that the lower bound is being used for a mission dimension is output unless suppressed by using -Wno-missing-index. This is... seriously problematic. I forsee all sorts of not-so-funny interactions with

Re: [RFC patch] Clean all (sub)?module files

Hi Dominieque, While investigating pr95538, I see several module files that were not cleaned. Several were cleaned by a patch I had in my working directory. However new ones were not cleaned (e.g., gfortran.dg/pr95091.f90) due to continuation lines. This is now fixed with the attached

Re: [PATCH] PR fortran/95881 - [9/10/11 Regression] ICE in resolve_symbol, at fortran/resolve.c:15175

Hi Harald, here's another NULL pointer dereference on invalid code. Regtested on x86_64-pc-linux-gnu. OK for master / backports where appropriate? OK. (Also would have classified as obvious and simple, I think). Thanks for the patch Regards Thomas

Re: [PATCH] PR fortran/71706 - [8/9/10/11 Regression] [Coarray] ICE on using sync images with integer(kind<>4), with -fcoarray=lib -fcheck=bounds

Hi Harald, Here's a fix to bounds-checking code that manifests itself essentially with checking enabled. Once found and understood, the fix is trivial: just properly convert the argument kind of SYNC IMAGES for checking. OK. (I had checked if "images" would be used later on. Tt is, so

[patch, fortran, committed] Fix PR 95037, NULL location in error message

Hi, I just committed as obvious and simple the attached patch, as r11-1297-g4644e8f15f835a9934a8d289ee08ba4cb46cbfac . Regards Thomas Always use locations from get and put arguments for error messages. A simple and obvios patch - the error location was taken from a variable that was

[patch, Fortran, committed] Fix a crash with a developer's option

Committed as obvious, simple and risk-free after checking that it still compiles. It does not fix the PR in question, it it just something that was noted in one of the comments. Regards Thomas Avoid crash when global symbol table is empty with -fdump-fortran-global. This just avoids

Re: Ping [PATCH] PR fortran/95088 - Buffer overflows with PDTs, submodules and long symbols

Hi Harald, Here's a fix for another buffer overflow which is triggered by one of Gerhard's (in)famous testsuite. Looking at the way symbols are generated, I decided to partly use a simple solution recommended by Jakub Jelinek. Regtested with no new failures on x86_64-pc-linux-gnu. OK for

[patch] Add swap files for vim to .gitignore

Add swap files for vim to .gitignore. This patch adds the most common swap files for vim to .gitignore. The editor may leave those behind if is stopped or crashes. We already do the same kind of things for emacs. ChangeLog: * .gitignore: Add swap files for vim. diff --git

Re: [PATCH] PR fortran/95587 - ICE in gfc_target_encode_expr, at fortran/target-memory.c:362

Hi Harald, OK for master? OK. Thanks for the patch! Regards Thomas

Re: [PATCH] Fortran : ICE in gfc_check_reshape PR95585

Hi Mark, Please find attached fix for PR95585. OK to commit and backport? OK for master. For backport: Again, I am not sure we need this, but the fix is simple enough. So, I probably wouldn't backport this (it's not a regression), but I'll leave that up to you. Regards Thomas

Re: [PATCH] PR fortran/95687 - ICE in get_unique_hashed_string, at fortran/class.c:508

Hi Harald, Regtested again. OK now? OK. Thanks for the patch! Regards Thomas

Re: [PATCH] PR fortran/95707 - ICE in finish_equivalences, at fortran/trans-common.c:1319

Am 17.06.20 um 21:27 schrieb Harald Anlauf: OK for master / backports? OK. Thanks for the patch! Regards Thomas

Re: [PATCH] PR fortran/95688 - ICE in gfc_get_string, at fortran/iresolve.c:70

Hi Harald, OK for trunk? Backport if suitable? Yes for both. Thanks for the patch! Regards Thomas

Re: [PATCH] Fortran : ICE in resolve_fl_procedure PR95708

Hi Mark, Please find attached a fix for PR95708. OK for commit and backport? OK (it's a regression, after all). Thanks! Regards Thomas

Re: [PATCH] Fortran : ICE in gfc_validate_kind PR95586

Hi Mark, OK to commit OK for master. Since, according to the PR, this is not a regression and this is an ICE on invalid, I don't think a backport is needed. On the other hand, the patch is simple enough that I am quite certain that it will not hurt. So, I'll leave that up to you. Best

Re: [PATCH] Fortran : Missing gcc-internal-format PR42693

Am 17.06.20 um 09:10 schrieb Mark Eggleston: Please find attached patch for PR42693. OK to commit and backport? OK for trunk. For backporting, it makes little sense since nobody is going to do a new translation for the existing branches. Regards Thomas

Re: [PATCH] PR fortran/95826 - Buffer overflows with PDTs and long symbols

Hi Harald, Is the memory you allocate freed anywhere? We have a large number of memory leaks in the front end, but maybe we shouldn't add another one :-) my reading of the definition of XALLOCAVEC include/libiberty.h:#define XALLOCAVEC(T, N)((T *) alloca (sizeof (T) * (N))) and

Re: [PATCH] PR fortran/95828 - Buffer overflows with SELECT RANK

Hi Harald, Another case of buffer overflow, this time coming in pairs. Regtested on x86_64-pc-linux-gnu. OK for master? OK. Thanks for tackling this! I haven't checked, but you are probably setting a new record for bug fixes per second now :-) Best regards Thomas

Re: [PATCH] PR fortran/95880 - [9/10/11 Regression] ICE in gfc_add_type, at fortran/symbol.c:2030

Hi Harald, A rather straightforward issue (mis-)referencing the proper symbol name in an error message. OK for master / backport? OK, but don't forget the test case :-) Because the if takes up quite a few lines, it is also an option to write something like gfc_error ("Symbol %qs at %L

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

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

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

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

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, PR fortran/95503] [9/10/11 Regression] ICE in gfc_is_simply_contiguous, at fortran/expr.c:5844

Hi Harald, The following patch fixes an almost obvious ICE in invalid. Regtested on x86_64-pc-linux-gnu. OK for master, and backports to 9/10? OK. Thanks for the patch! Regards Thomas

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

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

Re: [PATCH] PR fortran/95544 - ICE in gfc_can_put_var_on_stack, at fortran/trans-decl.c:494

Hi Harald, one remark: Instead of + && !(strcmp(gfc_current_intrinsic, "associated") == 0 + || strcmp(gfc_current_intrinsic, "null") == 0 + || strcmp(gfc_current_intrinsic, "present") == 0)) could you maybe test sym->id ? OK with that change. Best regards,

Can we use safe-ctype.h in a library?

Hi, I am currently looking at making libgfortran use the TOUPPER et al functions from ctype-safe.h. Adding this in a gfortran header results in lots of Gcc/trunk-bin/x86_64-pc-linux-gnu/./libgfortran/.libs/libgfortran.so: undefined reference to `_sch_istable' errors. So, can we use this,

[patch, libfortran, committed] Suppress -Wstringop-overflow warning

Hi, I just committed as obvious the patch below. Disable -Wstringop-overflow warning after checking code path of caller. The warning that is disabled, only on this single line, has been inspected and found to be not applicable; it is known that the size of the buffer is safe.

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

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

[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] 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] PR 27318, warn if interfaces do not match

Hello world, this patch solves an PR which just had its 14th birthday, continuing the mission of alerting the user to mismatches where possible. Regression-tested (which led to a few of the extra checks for errors). OK for trunk? Regards Thomas Test global identifiers against what is

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

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

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

*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

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

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

Re: [PATCH] Darwin, libgfortran : Do not use environ directly from the library.

Hi Iain, tested on a number of Darwin platforms old and new, and on x86_64/powerpc64-linux, OK for master? … and backports to open branches? One question... +# ifdef __APPLE__ +#  include +#  define environ (*_NSGetEnviron ()) Is it guaranteed that crt_externs.h is present if __APPLE__

*ping* [patch, fortran] Correct fndecls for some library functions

this patch makes sure that we pass the correct fn decls for some of our library functions. cshift and others still remain to be implemented. This is a step in our voyage to stop lying to the middle end :-) Regression-tested. OK for trunk? Ping? (I am not 100% sure this mail ever made it

Re: [PATCH] libgfortran: Correct FP feature macro checks

Am 25.11.20 um 23:02 schrieb Maciej W. Rozycki: The Fortran intrinsis like HUGE, EPSILON, SELECTED_REAL_KIND etc would have to be handled correctly, both for simplification in the front end and in the library. Does the program print *,HUGE(1.0) print *,EPSILON(1.0) end print correct

Re: [PATCH] libgfortran: Correct FP feature macro checks

Hi Maciej, Infinity is the least of a problem, because as it turns out we have numerous FP library functions in libgfortran that require explicit porting to each FP format supported, like these settings: xbig = 26.543, xhuge = 6.71e+7, xmax = 2.53e+307; The Fortran intrinsis

[patch, Fortran testsuite, committed] Fix PR 98156

Hello world, I just committed the attached patch as obvious and simple. Best regards Thomas Author: Thomas Koenig Date: 2020-12-06 10:14:13 +0100 Upper cobound is determined by num_images(), not this_image(). gcc/testsuite/ChangeLog: PR testsuite/98156

Re: *ping* [patch, fortran] Correct fndecls for some library functions

Hi Iain, Is there some testcase that can be used to see a progression from applying this patch? I haven't been able to find anything. Previously, everything was passed as ". r r r r r r" and so on; there were also too many arguments for functions like findloc. Since "r " is the most

Re: [patch, fortran] Correct fndecls for some library functions

Am 27.11.20 um 16:46 schrieb Tobias Burnus: Hi Thomas, On 25.11.20 12:58, Tobias Burnus wrote: On 15.11.20 18:52, Thomas Koenig via Fortran wrote: +#define ADD_CHAR(c) do { *fp++ = c; *fp++ = ' '; } while(0) ... +  ADD_CHAR ('.');  /* Function return.  */ Shouldn't this be ".c" instead of ".

Re: [PATCH] expansion: Improve double-word modulo by certain constant divisors [PR97459]

Hello Jakub, thanks a lot for taking this on! As far as I can tell, the patch works very well, and really speeds up things. As (somewhat confusingly) discussed in the PR, there are a couple of things that could still be done incrementally with this method. Fist, it can be combined with, or

Re: [PATCH] libgfortran: Correct FP feature macro checks

Am 26.11.20 um 18:34 schrieb Maciej W. Rozycki: Yeah, I've seen it my Fortran reference (not an official standard though; I don't remember where to get them from and given I don't seem to have a copy, I suspect they are charged for). If you want to look at something quite close to the

Re: [PATCH] libgfortran: Correct FP feature macro checks

Am 26.11.20 um 19:05 schrieb Maciej W. Rozycki: What do you need this information for anyway? It's a check if the simplification to constants of these floating point types is done correctly. Another interesting thing to look at would be selected_real_kind. selected_real_kind(precision,

Re: [PATCH 00/31] VAX: Bring the port up to date (yes, MODE_CC conversion is included)

Am 23.11.20 um 22:51 schrieb Maciej W. Rozycki: /* Define to 1 if you have the header file. */ #undef HAVE_IEEEFP_H So perhaps it does do the "right thing" if you do not have this header file on your VAX operating system. Well it does not: In file included from

Re: [PATCH 00/31] VAX: Bring the port up to date (yes, MODE_CC conversion is included)

Am 24.11.20 um 07:04 schrieb Maciej W. Rozycki: I am going to give up at this point, as porting libgfortran to non-IEEE FP is surely well beyond what I can afford to do right now. Can you file a PR about this? Eliminating __builtin_inf and friends sounds doable. And does anybody know what we

Re: [PATCH] PR fortran/98017 - [8/9/10/11 Regression] Suspected regression using PACK

HI Harald, When substituting an array-valued character parameter variable, the call to gfc_copy_expr returns character length 1. Fix up the resulting length. I could not figure out whether this is a bug or a feature of gfc_copy_expr. But the fix to simplify_parameter_variable would not do any

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

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

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

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

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

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: Ping: [Patch, fortran] PR97694 - ICE with optional assumed rank class(*) argument (and PR97723)

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

Re: *PING* Re: [Patch] Fortran: Fix function decl's location [PR95847]

Hi Tobias, *PING* OK. Thanks for the patch! Best regards Thomas

Re: [Patch, fortran] PR83118 - [8/9/10/11 Regression] Bad intrinsic assignment of class(*) array component of derived type

Hi Paul, This all bootstraps and regtests on FC31/x86_64 - OK for master? This is a sizable patch, and from what I can see, it all looks plausible. So, I's say OK for master (with one nit, below), but maybe you could wait a day or so to give others the chance to look it over, too. The nit:

Re: [Patch][wwwdocs] gcc-11/changes.html update for OpenMP + !GCC$ attributes + project/libgomp/ omp 5.1 update

Hi Tobias, should the OpenMP news about Fortran be mentioned (also) in the Fortran section? Best regards Thomas

[patch, fortran] Correct fndecls for some library functions

Hello world, this patch makes sure that we pass the correct fn decls for some of our library functions. cshift and others still remain to be implemented. This is a step in our voyage to stop lying to the middle end :-) Regression-tested. OK for trunk? Best regards Thomas Generate

Re: [PATCH, v1] PR fortran/48958 - Add runtime diagnostics for SIZE intrinsic function

Hi Harald, Feedback, such as comments for improvement, are welcome. It feels a bit strange to have a check for an allocatable behind -fcheck=pointer, but I'm not sure that introducing a special check option would really be worth it. Regarding pointers: They are usually not nullified (unless

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

[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

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

[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

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

[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

Re: [PATCH] PR fortran/70070 - ICE on initializing character data beyond min/max bound

Hi Harald, the attached patch is pretty much self-explaining: check for bounds violation when initializing a substring in a data statement and treat the resulting error. If more detailed information should be emitted with the error message, I'm open for suggestions. Currently, we issue these

Re: [Patch, fortran] PR98565 - internal compiler error: in conv_function_val, at fortran/trans-expr.c:3950

Hi Paul, Regtested on FC33/x86_64 - OK in a few weeks for 9- and 10-branches? Yes, I think this is obvious enough for a backport. Thanks for the patch! Best regards Thomas

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, fortran] PR98573 - Dynamic type lost on assignment

Hi Paul, This is a relatively obvious patch. The chunk in trans-array.c is not part of the fix for the PR but does suppress some of the bad dtype's that arise from allocation of class objects. The part in trans-stmt.c provides vptrs for all class allocations if the expression3 is available.

Re: [PATCH Fortran] Re: PR fortran/93524 - rank >= 3 array stride incorrectly set in CFI_establish

Hi Harris! OK for master? I do not have write access, so someone will need to commit this for me. Reviewed, regression-tested and committed as https://gcc.gnu.org/g:1cdca4261e88f4dc9c3293c6b3c2fff3071ca32b Thanks for your patch, and welcome aboard! Best regards Thomas

Re: [PATCH] [8/9/10/11 Regression] [OOP] PR fortran/86470 - ICE with OpenMP

Hello Harald, OK for master / backports? OK. It is indeed fairly obvious, as you write. Should the testcase be moved to the gomp/ subdirectory? Yes. It's a compile-time test, and it will then only be run if the the compiler can do OpenMP. You will not need the +! { dg-options

Re: [Patch] Fortran: Fix Array dependency with local coarrays [PR98913] (was: Re: A question about coarrays and -Warray-temporaries)

Am 02.02.21 um 12:46 schrieb Tobias Burnus: Hi all, the attached patch now handles -fcoarray=single and access to the local image like no coarray access, using the same check a before. Actually, I think we could remove the if (..coarray..) check completely: For 'single', it is like no

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

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

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

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

Re: [patch, libgfortran] PR98825 Unexpected behavior of FORTRAN FORMAT expressions when suppressing new line with '$'

Hi Jerry, OK for trunk and backport to 10 since it is simple enough? OK for trunk. Because this is a user-visible change (even if we did the wrong thing before) I don't feel that we should backport (but I am open to suggestions otherwise). Could you also mention this in

Re: [Patch] Fortran: intrinsic.texi add missing arg to FINDLOC (was: FINDLOC documentation at https://gcc.gnu.org/onlinedocs/gfortran/FINDLOC.html)

Hi Tobias, I intent commit it as obvious, unless there are comments. Just one nit: MASK does not have to be an array, it can also be a scalar. It just has to be conformable. OK with that change. Best regards Thomas

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

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

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

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

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

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

Re: [Patch] Fortran: Fix ubound simplifcation [PR99027]

Hi Tobias, The problem which accessing dim= for an expression is that when the argument is an array, dim= and expr->rank are relative to the resulting array – but the array-ref also contains the DIMEN_ELEMENT which does not count for dim=/rank. OK for the trunk? (Reported against GCC 11, but I

Re: [Patch] Fortran: Fix rank of assumed-rank array [PR99043]

Hi Tobias, OK for mainline? Reported against GCC 10, not a regression but simple wrong-code fix; does it make sense to apply there was well? OK for both. Thanks for the patch! Best regards Thomas

<    1   2   3   4   5   >