Re: *Ping* [PR fortran/88299, patch] - [F18] COMMON in a legacy module produces bogus warnings in dependent code

Hi Harald, Ping! On 02/11/19 23:09, Harald Anlauf wrote: The attached patch moves the check for this F2018 obsolescent feature to a better place where the warning is only emitted when the COMMON is declared. No warning should be emitted when such a legacy module is simply used. Regtested o

Re: [PR fortran/89077, patch, part 3] - ICE using * as len specifier for character parameter

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

Re: [patch, fortran] Fix PR 87689, wrong decls / ABI violation on POWER

I have now committed the patch as r268992. Janne and Richard, thanks for the review and the comments. Am 18.02.19 um 13:50 schrieb Richard Biener: On Sun, Feb 17, 2019 at 7:19 PM Thomas Koenig wrote: Regression tests turned up a few ICEs (now fixed), plus two very invalid test cases, which I

Re: [patch, fortran] Fix PR 87689, wrong decls / ABI violation on POWER

Hi Janne, I'm not really sure if there is any good reason why GFortran occasionally generates these varargs declarations, hence my suggestion to get rid of them. Unless the middle-end is planning to get rid of untyped function decls? Are they still being generated after the patch went in? I'm

[patch, fortran] Fix PR 89384

gards Thomas 2019-02-18 Thomas Koenig PR fortran/89384 * trans-expr.c (gfc_conv_gfc_desc_to_cfi_desc): If the dummy argument is contiguous and the actual argument may not be, use gfc_conv_subref_array_arg. 2019-02-18 Thomas Koenig PR fortran/

[patch, fortran] Fix PR 86119, spurios warning for len(classtype) with -Wconversion

Hello world, the attached patch fixes the 8/9 regression by inserting the conversion at the right place. Regression-tested. OK for trunk, and for 8 when it re-opens? Regards Thomas 2019-02-19 Thomas Koenig PR fortran/86110 * class.c (gfc_get_len_component): Add

Re: [patch, fortran] Fix PR 87689, wrong decls / ABI violation on POWER

Bob, Some of us still use varargs interfaces (in my case, Fortran calling C stdarg subroutines). The problem for us is that that sometimes using varargs made standard- conforming Fortran code like, in file a.f subroutine foo(a) print *,a end and in file main.f progra

Re: [PR fortran/89266, patch] - ICE with TRANSFER of len=0 character array constructor

Hi Harald, OK for trunk? Or rather wait for post-9.1? I think this can go into current trunk. Thanks! Regards Thomas

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

-24 Thomas Koenig PR fortran/89174 * trans-expr.c (gfc_find_and_cut_at_last_class_ref): Add is_mold to garguments. If we are dealing with a MOLD, call gfc_expr_to_initialize(). * trans-stmt.c (gfc_trans_allocate): For MOLD, pass is_mold=true to

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

Hi Dominique, I see a double space in ! { dg-do run } Is this intended? Yes, it is. This is for tests which should not be run with all the options cycling, but only once. I think this was introduced quite some time ago, not sure if it was ever documented anywhere. I guess we should do so

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

Hi Dominique, AFAICT there is no patch attached. I guess that would have helped :-) Here it is. 2019-02-25 Thomas Koenig PR fortran/89496 * trans-types.c (get_formal_from_actual_arglist): If the actual arglist has no expression, the corresponding formal

[patch, fortran] Fix pointers not escaping via C_PTR

this patch introducing regressions are really, really low. Regression-tested. OK for trunk? Regards Thomas 2019-02-29 Thomas Koenig PR fortran/71544 * trans-types.c (gfc_typenode_for_spec) Set ts->is_c_interop of C_PTR and C_FUNPTR. (create_fn_s

Re: [patch, fortran] Fix pointers not escaping via C_PTR

Hi Steve, On Thu, Feb 28, 2019 at 09:14:48PM +0100, Thomas Koenig wrote: the attached patch fixes a wrong-code bug for gfortran where pointers were not marked as escaping. A C_PTR can be stashed away and reused later (at least as long as the variable it points to remains active). This is

Re: [PR fortran/89516, patch] - ICE in gfc_calculate_transfer_sizes at gcc/fortran/check.c:5506

Hi Harald, Adding -Wsurprising as option to gfortran exercised a code path that I hadn't seen when working on simplifications for the TRANSFER intrinsic. While regtesting, I realized that one of the checks was too strict when the MOLD argument was scalar and of size 0 and should only apply to a

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

affected branches? Regards Thomas 2019-03-02 Thomas Koenig PR fortran/72714 * resolve.c (resolve_allocate_expr): Add some tests for coarrays. 2019-03-02 Thomas Koenig PR fortran/72714 * gfortran.dg/coarray_allocate_11.f90: New test

Re: [patch, fortran] Fix pointers not escaping via C_PTR

I wrote: First, this talks about a C pointer having a target.  Second, you can re-estabilsh the association to a different pointer to the Fortran program. There is another point to consider: This is interoperability with C we are dealing with, so we also have to follow C semantics. And, love i

Re: [PR fortran/71203, patch] - ICE on zero-length arrays or substrings

Hi Harald, To the reviewer: I am not 100% sure that my solution is correct, but it solves the issues reported and regtests cleanly on x86_64-pc-linux-gnu. OK for trunk? Backports? I don't see how adding the charlen to the current namespace can hurt, so I think this is OK. Regarding backport

[patch, fortran] Fix PR 66089, ICE (plus wrong code) in dependency handling

gfc_walk_variable_expr. Once this was gone, a wrong-code issue appeared which was fixed by the part in gfc_scalar_elemental_arg_saved_as_reference (is that the longest function name in gfortran?). Regression-tested. OK for all affected branches? Regards Thomas 2019-03-06 Thomas Koenig PR

Re: [patch, fortran] Fix PR 66089, ICE (plus wrong code) in dependency handling

Am 08.03.19 um 08:04 schrieb Bernhard Reutner-Fischer: Please change call abort to stop N in the test? Done. Anything else? OK for trunk? Regards Thomas

Re: [PATCH] Fix overflowing integer to an integer exponent

Hi Steve, It has been regression tested on x86_64-*-freebsd. OK to commit? Yes, I think that is OK. Since this changes user-visible behavior, could you also add a short notice to gcc-9/changes.html ? Regards Thomas

Re: [patch, fortran] Fix pointers not escaping via C_PTR

Hi Jerry, I think you want to to IF STOP instead of printing some test values or dou you just want dg-conpile? You're correct, I wanted a dg-do run. Here is the version of the test case that I committed. Thanks for the review (and the other one). Regards Thomas ! { dg-do run }

[patch, fortran] Fix PR 87734, rejects-valid

PUBLIC or PRIVATE as simple external procedures. This is a 7/8/9 regression, backporting may also include backporting Steve's patch for PR 88376 (I haven't checked yet). OK for trunk and the other open branches? Regards Thomas 2019-03-09 Thomas Koenig PR for

Re: [Patch, fortran] PRs 89363 and 89364 - wrinkles with assumed rank

Hi Paul, (ii) PR89364 points out that ubound and shape should be returning -1 for the final dimension and not 0, for assumed rank entities argument associated with assumed size arrays. What a mix of features... Bootstrapped and regtested on FC29/x86_64 - OK for trunk? OK. Thanks for the pa

[patch, fortran] Fix PR 87673, rejects-valid

Thomas 2019-03-10 Thomas Koenig PR fortran/87673 * match.c (gfc_match_type_spec): Remove call to gfc_resolve_expr for character length. 2019-03-10 Thomas Koenig PR fortran/87673 * gfortran.dg/charlen_17.f90: New patch. Inde

Re: [patch, fortran] Fix PR 87673, rejects-valid

Am 10.03.19 um 21:15 schrieb Steve Kargl: On Sun, Mar 10, 2019 at 09:04:18PM +0100, Thomas Koenig wrote: ! { dg-do compile } ! PR 87673 - used to cause errors about non-pure functions. ! A fragment from Richard Townsend's iso_varying_string, as modified by ! Ian Harvey to include

Re: [patch, fortran] Fix PR 87673, rejects-valid

Am 10.03.19 um 22:12 schrieb Thomas Koenig: You're probably right, I will fix this.  Ugh... OK, so here is the updated test case, without the copyright stuff. OK for trunk now? :-) Regards Thomas ! { dg-do compile } ! PR 87673 - used to cause errors about non-pure func

[patch, fortran] Fix PR 66695, 77746 and 79485

f entry in gfc_get_extern_function_decl, just ignore it. Regressoin-tested. OK for trunk? Regards Thomas 2019-03-12 Thomas Koenig PR fortran/66695 PR fortran/77746 PR fortran/79485 * gfortran.h (gfc_symbol): Add bind_c component. (gfc_get_gsy

Re: [PR fortran/60091, patch] - Misleading error messages in rank-2 pointer assignment to rank-1 target

Hi Harald, how about the attached version? It is quite verbose and produces messages like Error: Expected list of 'lower-bound-expr:' or list of 'lower-bound-expr:upper-bound-expr' at (1) I think this way of specifying error messages +#define BOUNDS_SPEC_LIST "list of %" ... +

Re: [patch, fortran] Fix PR 66695, 77746 and 79485

Hi Steve, Regressoin-tested. OK for trunk? Looks good to me. Committed as r269635, with one correction: When checking with SVN, I found that I had misnumbered the test cases - I have now committed them as binding_label_tests_30.f90 to binding_label_tests_33.f90. Thanks for the review! Regar

Re: [PR72741] Encode OpenACC 'routine' directive's level of parallelism inside Fortran module files

Am 13.03.19 um 18:50 schrieb Thomas Schwinge: There are many ways to deal with it without bumping MOD_VERSION in a backwards but not forwards compatible way, so that a newer compiler will be able to parse old *.mod files, and newer compiler new ones as long as this problematic stuff doesn't appea

[patch, doc, fortran] Add Q edit descriptor

Hello world, this doc patch adds the Q edit descriptor to the non-implemented extension list. Tested with "make dvi", "make pdf" and "make info". Suggestions? OK for trunk? Regards Thomas

Re: [patch, doc, fortran] Add Q edit descriptor

Am 13.03.19 um 23:55 schrieb Steve Kargl: On Wed, Mar 13, 2019 at 11:48:12PM +0100, Thomas Koenig wrote: Hello world, this doc patch adds the Q edit descriptor to the non-implemented extension list. Tested with "make dvi", "make pdf" and "make info". Suggesti

[patch, fortran] Fix PR 84394

Hello world, this patch fixes a rejects-valid 7/8/9 regression where subroutines like _deallocate are added to a derived type in a block data, and because they were marked PRIVATE, an error occurred. This solution is look for this particular case by checking for an underscore as the first letter

Re: [patch, fortran] Fix PR 84394

Am 15.03.19 um 21:31 schrieb Steve Kargl: Patch is missing? Entirely correct. Here it is. Regards Thomas Index: symbol.c === --- symbol.c (Revision 269635) +++ symbol.c (Arbeitskopie) @@ -1689,7 +1689,15 @@ gfc_add_subro

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

Hello world, this patch fixes an ICE on invalid 9 regression by converting two asserts into gfc_error, plus fixups to the rest of the code. Regression-tested. OK for trunk? Regards Thomas Index: gfortran.h === --- gfortran

Re: [PATCH] Fix up diagnostics emitted by fortran FE load_line (PR fortran/89724)

Hi Jakub, Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? OK. Thanks for the patch! Regards Thomas

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

Hi Domoinique, + gfc_error ("Error in component call at %L", and call x%z%g() ! { dg-error "Error in typebound call" } Corrected. If there isn't anything else, I'll commit tonight (as three quarters obvious) to keep down the number of concurrent patches in my tree :-) Regards

[patch, fortran] Fix PR 68009, wrong prototype in runtime_error

_gfortran_runtime_error where setting %eax to zero indicates that we are indeed using varargs, because %eax contains the number of float arguments, which is zero. No test case, because there is not really a good way to check for this. So, OK for trunk? Regards Thomas 2019-03-17 Thomas Koenig

Re: [PR fortran/85797, patch] - ICE in gfc_element_size, at fortran/target-memory.c:126

Hi Harald, My reading of the standard suggests that this is not allowed: SOURCE shall be a scalar or array of any type. MOLD shall be a scalar or array of any type. ... I read the stanard differently. For comparison, look at UNPACK: # VECTOR shall be a rank-one array of any type. a

Re: [Patch, Fortran, F03] PR 71861: [7/8/9 Regression] ICE in write_symbol(): bad module symbol

Hi Janus, the attached one-line patch fixes an ICE-on-invalid regression with abstract interfaces. Regtests cleanly on x86_64-linux-gnu. Ok for trunk and the release branches (7 and 8)? OK for all. Thanks for the patch! Regards Thomas

Re: [PR72741] Encode OpenACC 'routine' directive's level of parallelism inside Fortran module files

Hi Thomas, Are there any further questions, or am I good to commit my patch as posted? Problem is, I have never looked into module writing / reading in any detail, so it will take a few days for me to get up to speed so I can really review your patch. If, in the meantime, maybe somebody else

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

ICE. The solution also has two parts: Make sure that a hard error is delivered in this case, and make sure the check is done every time. Regression-tested. OK for trunk and other affected branches? Regards Thomas 2019-03-22 Thomas Koenig PR fortran/78865 * interface.c

Re: [PATCH][doc] Fix typos in MINLOC, MAXLOC documentation

Hi Kyrill, I think there's a typo in the documentation of the MINLOC and MAXLOC intrinsics. It implies that when the BACK argument is true it returns the first occurrence of the min/max value, but my understanding is that it should return the last occurrence. This patch fixes the documentatio

Re: [Patch, fortran] PR88247 - [8/9 Regression] ICE in get_array_ctor_var_strlen, at fortran/trans-array.c:2068

Hi Paul, Bootstraps and regtests on FC29/x86_64 - OK for 8- and 9-branches? OK. Thanks for the patch! Regards Thomas

Re: PING [RFA patch, Fortran] PR60144 - Misleading error message when missing "then" after "if" and "else if"

Hi Dominique, Patch posted at https://gcc.gnu.org/ml/fortran/2019-03/msg00098.html I think the patch is OK. I think the patch is probably appropriate for stage 1 once that reopens. Regards Thomas

Re: [Patch, Fortran, F08] PR 85537: Invalid memory reference at runtime when calling subroutine through procedure pointer

Hi Janus, the attached patch implements some missing constraints from Fortran 2008 concerning procedure pointer initialization (cf. the standard quote in comment #18), thus fixing two accepts-invalid and ICE-on-invalid problems. I do not think this is correct. F2008: # 12.2.2.4 Procedure poi

Re: [Patch, Fortran, F08] PR 85537: Invalid memory reference at runtime when calling subroutine through procedure pointer

Am 27.03.19 um 22:54 schrieb Thomas Koenig: I do not think this is correct. ... and I missed the point that this was specifically about initializations. So, OK from my side. Thanks! Regards Thomas

Re: [Patch, fortran] PR87127 - External function not recognised from within an associate block

Hi Paul, Bootstrapped and regtested on FC29/x86_64 - OK for trunk? OK - looks obvious enough, and, IMO, is quite unlikely to cause a regressions. Thanks for the patch! Regards Thomas

[patch, fortran] Fix PR 87352, far too many deallocations

trunk and backporting? Regards Thomas 2019-03-31 Thomas Koenig PR fortran/87352 * gfortran.h (gfc_component): Add finalized field. * class.c (finalize_component): If the component is already finalized, return early. Set component->finalized on e

Re: [patch, fortran] Fix PR 87352, far too many deallocations

Am 31.03.19 um 18:10 schrieb Thomas Koenig: Hello world, the attached patch Now really attached. ! { dg-do compile } ! { dg-additional-options "-fdump-tree-original" } ! PR 87352 - this used to cause an excessive number of deallocations. module testmodule implicit none publ

Re: [Patch, fortran] PR89904 - ICE in gfortran starting with r270045

Hi Harald, OK for trunk (and affected backports)? Yes, OK. Thanks! (For cases like this, it often makes sense to wait a week or so before backporting something, to see if anything comes up). Regards Thomas

[ patch, fortran, committed] Fix PR 89981, rejects valid

were already in place, I simply added the condition for the entry itself. I will wait a week or so before committing to gcc-8, the only other affected branch. Regards Thomas 2019-04-06 Thomas Koenig PR fortran/89981 * resolve.c (resolve_global_procedure): If the global

*ping* [patch, fortran] Fix PR 87352, far too many deallocations

Am 31.03.19 um 18:16 schrieb Thomas Koenig: Am 31.03.19 um 18:10 schrieb Thomas Koenig: Hello world, the attached patch Now really attached. Ping?

[patch, fortran, committed] Fix error messages for translation

Hello world, I have just committed the attached patch as obvious and simple. It fixes an error message so that it can be extracted for translation. No test case because it does not change anything (which was verified by regression-testing). Regards Thomas 2019-04-11 Thomas Koenig

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

the Fortran part? Regards Thomas 2019-04-13 Thomas Koenig PR fortran/84487 * trans-decl.c (gfc_get_symbol_decl): Mark _def_init as artificial. 2019-04-13 Thomas Koenig PR fortran/84487 * varasm.c (bss_initializer_p): If we are compiling

Re: [Patch, fortran] PRs 89843 and 90022 - C Fortran Interop fixes.

Hi Paul, Please find attached the updated patch, which fixes the problem with -m32 in PR90022, eliminates the temporary creation for INTENT(IN) dummies and fixes PR89846. While it looks like it should be intrusive because of its size, I believe that the patch is still safe for trunk since it i

[patch, fortran] Inline packing for array temporaries

for backporting) Regards Thomas 2019-04-28 Thomas Koenig PR fortran/88821 * expr.c (gfc_is_simply_contiguous): Return true for an EXPR_ARRAY. * trans-array.c (is_pointer): New function. (gfc_conv_array_parameter): Call gfc_conv_subref_array_arg

Re: [patch, fortran] Inline packing for array temporaries

Hi Paul, Could you provide the patch, please, or was it already posted? Actually, no. I was so intent on providing the test cases that I missed the patch itself :-) Here it is. Regards Thomas Index: fortran/expr.c === -

Re: [PATCH][GCC 10][RFC] Fix PR testsuite/90113

Hi Roman, FAIL: gfortran.dg/inline_matmul_1.f90 scan-tree-dump-times optimized "_gfortran_matmul" 0 With matmul, there are three versions you can get: The library version (called as _gfortran_matmul), the inline version or a direct call to the corresponding BLAS routine. Which one is called, a

Re: module_column not initialized in write_module()

Hi Andrew, Fixing this seems to be simple: --- gcc/fortran/module.c(revision 270772) +++ gcc/fortran/module.c(working copy) @@ -6052,6 +6052,9 @@ write_module (void) { int i; + /* Initialize the column counter. */ + module_column = 1; + /* Write the operator inte

[patch, fortran] Fix PR 61968

Hello world, the attached patch fixes an error where TYPE(*) ended up in a vtab, with not-so delectable results. The solultion is simple - do not create a vtab if the actual argument is TYPE(*). This also clears the ICE for my inline packing patch which was reported by Dominique. Regression-te

Re: [patch, fortran] Fix PR 61968

ately. In the meantime, here is the one-line patch with the test case above with -O3 added, so any failure will be noted soon. OK for trunk? Regards Thomas 2019-05-02 Thomas Koenig PR fortran/61968 * interface.c (compare_actual_formal): Do not create a vtab if

[patch, committed] Fix gcc-7 regression in front-end optimization

Thomas 2019-05-05 Thomas Koenig PR fortran/90344 * frontend-passes.c (create_var): Bring into sync with gcc 8. 2019-05-05 Thomas Koenig PR fortran/90344 * gfortran.dg/pr90344.f90: New test. Index: frontend-passes.c

[patch, fortran] C prototype writing improvements for gfortran

with their transition to something that does not violate gfortran's ABI. Tested with "make dvi" and "make info". Otherwise, since these flags are not tested in the testsuite (maybe they should be, I just don't know how), regression test passed. OK? 2019-05-08 Thomas

Re: [patch, fortran] C prototype writing improvements for gfortran

Hi Steve,> dicsouraged? Fixed. Otherwise, looks ok to me. Committed, thanks. Let's see where this leads... Regards Thomas

Ping [patch, fortran] Fix PR 61968

Hi, ping? Not for me, I still get % gfc pr61968.f90 -c -O3 pr61968.f90:32:0:     32 | call test_lib (a, int (sizeof (a), kind=c_size_t))    | internal compiler error: in gfc_trans_create_temp_array, at fortran/trans-array.c:1265 You're right, I will clear this up separately. In th

[patch, fortran] Inline argument packing

Hello world, this new version of the inlie argument packing patch (PR 88821) avoids the ICE on the test case for PR 61968. Otherwise it is unchanged. Regression-tested. OK for trunk? Regards Thomas 2019-05-11 Thomas Koenig PR fortran/88821 * expr.c

Re: [patch, fortran] Inline argument packing

Hi Dominique, How ever adding the new tests is a real PITA!-( Could you improve the naming scheme for them What should be the preferrred naming scheme for a test that is split? I'm open to suggestions (but also, the naming convention should not matter once the test cases are committed). Rega

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

Am 12.05.19 um 00:02 schrieb Jakub Jelinek: Is it correct to use macros in user namespace? Shouldn't they be say __ prefixed, or even have __GFC_ or __GFORTRAN_ in them? I think Jakub has a point there -- something like __GFC_DOUBLE_COMPLEX would probably be better. So, OK with that change.

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

Am 12.05.19 um 10:29 schrieb Janne Blomqvist: Thanks, committed as r271106. I prefixed the macros with __GFORTRAN_, as that seems clearer to users where those come from as gfc seems used mostly in the compiler internals. Sounds good. Any opinions whether it should be committed to 9 as well?

Re: [PATCH] libfortran/90038: Use posix_spawn instead of fork

Hi Janne, fork() semantics can be problematic. Most unix style OS'es have posix_spawn which can be used to replace fork + exec in many cases. For more information see e.g. https://www.microsoft.com/en-us/research/uploads/prod/2019/04/fork-hotos19.pdf This replaces the one use of fork in libgf

Re: [PATCH] libfortran/90038: Use posix_spawn instead of fork

Am 16.05.19 um 22:10 schrieb Janne Blomqvist: On Thu, May 16, 2019 at 10:59 PM Thomas Koenig wrote: Hi Janne, fork() semantics can be problematic. Most unix style OS'es have posix_spawn which can be used to replace fork + exec in many cases. For more information see e.g.

Re: [PATCH] libfortran/90038: Use posix_spawn instead of fork

Hi Janne, I differ there. A longer explanation: fork() is standard POSIX. Not all systems have posix_spawn. For those systems which do not have it, we would cause a regression by simply removing that functionality for this. The patch is OK from my side if you add fork() as a fallback option

Re: [PATCH] Export forgotten _gfortran_{,m,s}findloc0_i2 (PR fortran/54613)

Hi Jakub, I've found that gfortran.map doesn't export these 3 symbols (while it does export other variants, with i1, i4, i8, i16, etc.). Do we want to export them from both GCC 9.2 and 10 the following way, or just on the trunk using GFORTRAN_10? Both, please. Tested on x86_64-linux. Anothe

Re: [PATCH] Add workaround for broken C/C++ wrappers to LAPACK (PR fortran/90329)

Hi Jakub, Could we easily detect at resolve time whether a subroutine/function makes any implicitly prototyped calls and limit this workaround to those cases (i.e. only old-style Fortran)? I've mentioned it in the PR, but not sure how exactly to check that. I think we could to that. We could

[patch, fortran] Put workaround for broken C/Lapack wrappers behind flag

uot; all passed. OK for trunk? Regards Thomas 2019-05-18 Thomas Koenig PR fortran/90329 * invoke.texi: Document -fbroken-callers. * lang.opt: Add -fbroken-callers. * trans-decl.c (create_function_arglist): Only set DECL_HIDDEN_STRING_LENGTH if fla

*ping* [patch, fortran] Inline argument packing

Am 11.05.19 um 15:10 schrieb Thomas Koenig: Hello world, this new version of the inlie argument packing patch (PR 88821) avoids the ICE on the test case for PR 61968. Otherwise it is unchanged. Regression-tested. OK for trunk? Ping?

Re: [patch, fortran] Put workaround for broken C/Lapack wrappers behind flag

: ChangeLog === --- ChangeLog (Revision 271375) +++ ChangeLog (Arbeitskopie) @@ -1,3 +1,11 @@ +2019-05-19 Thomas Koenig + + PR fortran/90329 + * invoke.texi: Document -fbroken-callers. + * lang.opt: Add -fbroken-callers. + * trans

Re: [PATCH] PR fortran/69101 -- IEEE_SELECTED_REAL_KIND part I

Hi Steve, Well, that was quick. Moving code around is problematic. Thanks for checking. The patch is OK for trunk. Regards Thomas

[patch, fortran] Fix PR 68426, simplification of SPREAD

empel/Spread> cat ChangeLog 2019-01-09 Thomas Koenig PR fortran/68426 * simplify.c (gfc_simplify_spread): Also simplify if the type of source is an EXPR_STRUCTURE. 2019-01-09 Thomas Koenig PR fortran/68426 * gfortran.dg/spread_simplify_1.f90: New tes

Re: ISO_Fortran_binding patch

Hi Paul, This is an updated version of the earlier patch. The main addition is a second testcase that checks the errors emitted by the CFI API functions. I notice that the header file ISO_Fortran_binding.h is found twice in the patch. Is there any particular reason why you do not want to use

Re: ISO_Fortran_binding patch

Hi Paul, Incidentally, we need to make sure that it is distributed in the include directory. I have yet to figure out how to do that. It already does that, that was part of what I sent you :-) It's the +gfor_c_HEADERS = $(srcdir)/ISO_Fortran_binding.h +gfor_cdir = $(libdir)/gcc/$(target_ali

Re: [PATCH] PR fortran/86322 -- Enforce F2018:C877

Hi Steve! The attached patche fixes the PR. gfortran was not enforcing F2018:C877 and would ICE. Tested on x86_64-*-freebsd. Ok to commit? OK. Thanks for the patch! Regards Thomas

[Patch, fortran] Fix PR59345, repacking of a packed temporary array

Hello world, the attached patch fixes a rather bad missed optimization, where the generated temporary array for SUBROUTINE S1(A) REAL :: A(3) CALL S2(-A) END SUBROUTINE was packed and unpacked(!). Regression-tested. OK for trunk? Regards Thomas 2019-01-10 Thomas Koenig

[patch, fortran] Fix the rest of PR 59345

Hello world, this patch fixes the rest of the PR by making sure we do not pack/unpack for function results which are either allocatable or explicit shape arrays. Regression-tested. OK for trunk? Regards Thomas 2019-01-12 Thomas Koenig PR fortran/59345 * trans

[patch, fortran, committed] Fix PR 57792

Hell world, as part of the contiguous improvement process in gfortran, I have committed the patch below as obvious. gfortran now does not pack/unpack if a function result is contiguous. Regards Thomas 2019-01-13 Thomas Koenig PR fortran/57992 * trans-array.c

[patch, fortran] Add -fwrite-module-files option

sure how to check for the presence or absence of a module file in dejagnu. OK for trunk? Regards Thomas 2019-01-13 Thomas Koenig PR fortran/82215 * invoke.texi: Document -fwrite-module-files. * lang.opt: Add -fwrite-module-files. * parse.c (gf

Re: [patch, fortran] Add -fwrite-module-files option

Hi Steve, On Sun, Jan 13, 2019 at 11:28:00PM +0100, Thomas Koenig wrote: the attached patch adds a -fwrite-module-files options, but the main point is that it adds its opposite, -fno-write-module-files. This has advantages in parallel compiling, as it is quite fast to generate a module file

[patch, fortran] Fix PR 43072

Hello world, the attached patch fixes a missed optimization where a substring equal in length to the original variable currently leads to an unneeded temporary. Regression-tested. OK for trunk? Regards Thomas 2019-01-15 Thomas Koenig PR fortran/43072 * resolve.c

Re: [patch, fortran] Fix PR 43072

Hi Steve, On Tue, Jan 15, 2019 at 10:58:33PM +0100, Thomas Koenig wrote: the attached patch fixes a missed optimization where a substring equal in length to the original variable currently leads to an unneeded temporary. Regression-tested. OK for trunk? Yes. See below. Thanks. 2019

[patch, fortran] Fix PR 88871

systems, so we will notice if it regresses. OK for trunk? Regards Thomas 2019-01-17 Thomas Koenig PR fortran/88871 * resolve.c (resolve_ref): Fix logic for removal of reference. Index: resolve.c

Re: [patch, fortran] Fix PR 88871

Am 17.01.19 um 07:30 schrieb Thomas Koenig: No test case because, well - it did show up on a few systems, so we will notice if it regresses. OK for trunk? Both Dominique and Jürgen confirmed that it fixes the PR. I will commit this tomorrow unless there are any objections - I'd like t

[patch, fortran] Fix contiguous dummy arguments

different code being generated. I put corresponding run time tests into the new test case to make sure that no wrong code is being generated. I have also tested the new test case and the compiler with valgrind. OK for trunk? Regards Thomas 2018-01-19 Thomas Koenig Paul Thomas

Re: [Patch, Fortran] PR 37835 -fno-automatic does not work for derived types with default initalizer

Hi Dominique, The patch for gcc/fortran/resolve.c is the modernized version of Paul’s patch in comment 4. It causes some regressions due to "Duplicate SAVE » warnings. They are silenced by the patch for gcc/fortran/symbol.c unless -pedantic is used as documented in the change for gcc/fortran/i

Re: [PATCH] PR fortran/77960 -- inpute-item can't be function

Hi Steve, The attached patch has been tested on x86_64-*-freebsd. PR fortran/77960 uses a procedure pointer to expose the bug, but it applied to any external subprogram. So, the patch checks for the external attribute. OK to commit? OK, and thanks. Regards Thomas

[patch, fortran] Move some array packing to front end

rtain condition, it is usually straightforward to check for the condition and then simply not do the optimization. So, comments? Bug reports? OK for trunk if nobody has come up with a bug in the next few days? Regards Thomas 2019-01-22 Thomas Koenig PR fortran/88821

Re: [PR88579, patch] Calculating power of powers of two

Hi Harald, here's my revised patch for the treatment of (2**e) ** n and (- 2**e) ** n, trying to take into account the bitwidth of the result. I've also extended the testcase to sample different integer kinds. ChangeLogs see below. Note: I don't have commit rights, so please somebody else tak

Re: [patch, fortran] Move some array packing to front end

Hi Dominique, FAIL: gfortran.dg/internal_pack_4.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test with -m32. gfc /opt/gcc/work/gcc/testsuite/gfortran.dg/internal_pack_4.f90 -O3 -funroll-loops -ftracer -m32 is enough to trigger the miscomp

Re: [patch, fortran] Move some array packing to front end

Hi, for the record, the attached version of the patch regtests cleanly and also passes the test that Dominique pointed out. I will defer this until stage 1 reopens. Regards Thomas Index: fortran/expr.c === --- fortran/expr

Re: [PR fortran/57553, patch] - bad error message for invalid use of STORAGE_SIZE

Hi Harald, OK for trunk? OK. Also not likely to cause a regression, so I think this is quite fine for now. Regards Thomas

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