[patch, fortran] Fix PR 88411, wrong code with async I/O

Hello world, the attached patch fixes the wrong-code regression by changing the way synchronous writes are handled on files using asynchronous I/O: The are now handled synchronously. This also means that two places where a wait instruction was issued in such a case are no longer needed. I

Re: Fortran patches

Hi Steve, PR fortran/88139 * dump-parse-tree.c (write_proc): Alternate return. I dissent with this patch. The introduced error is meaningless and, as mentioned by comment #3 in the PR, avoiding the ICE in dump-parse-tree is not directly the issue. The code should be rejected in

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

Am 27.11.18 um 17:22 schrieb Steve Ellcey: Why wouldn't clang (flang) want to use the same mechanism as GCC/gfortran? I know there is some interest/work going on here for flang and we would like a consistent way to use pre-includes to define SIMD vector functions in both gfortran and flang. I

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

Hi Martin, he header file will be install by glibc (glibc-devel package). Why actually glibc-devel? Needing glibc-devel for fast compilation of Fortran seems to be counter-intuitive. Maybe glibc would be better. Regards Thomas

Re: Patch ping (Re: [PATCH] Fortran include line fixes and -fdec-include support)

Hi Jakub, Before 9.0 is released, we should also document the flag (and the extension it supports) in the manual, and note it in changes.html and on the Wiki. Would you also do that? Like this? Ok for trunk/wwwdocs? OK for trunk (and I don't think you need my OK for wwwdocs, but you have

Re: [PATCH] Replace sync builtins with atomic builtins

Hi Janne, PING! OK. Thanks for the patch! Regards Thomas

Re: Patch ping (Re: [PATCH] Fortran include line fixes and -fdec-include support)

Hi Jakub, I'd like to ping this patch, ok for trunk? OK. Thanks for the patch! Before 9.0 is released, we should also document the flag (and the extension it supports) in the manual, and note it in changes.html and on the Wiki. Would you also do that? Regards Thomas

[patch, committed] Fix PR 88073

Hello world, using the combined superpowers of Captain Obvious and Lieutenant Simple, I have committed the attached patch, which fixes a regression, as r266251, after regression-testing. I will backport to 8 and 7 in the next few days. Regards Thomas 2018-11-18 Thomas Koenig

Re: *Ping* Fix PR 70260, ICE on invalid

Hi Paul1 OK for trunk. Thanks for working on it. Committed as r266248. Thanks for the review! Regards Thomas

*Ping* Fix PR 70260, ICE on invalid

Hi, the attached patch fixes both ICEs in the PR by adding some tests. It was necessary to shuffle around a bit of code, plus to make sure that double error reporting did not become too bad. Regression-tested. OK for trunk? Ping? Regards Thomas

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

Hello world, the attached patch fixes both ICEs in the PR by adding some tests. It was necessary to shuffle around a bit of code, plus to make sure that double error reporting did not become too bad. Regression-tested. OK for trunk? Regards Thomas 2018-11-11 Thomas Koenig

Re: [PATCH, libgfortran] Remove recursion check

Hi Janne, 1) It's KISS 2) I can't find anything in the code that would lead to endless recursive invocation of the error printing functions. So, Ok for trunk? With async I/O, I think the possibilities of hitting concurrent errors have increased, so I'd still prefer the solution with

Re: [patch, libgfortran] PR78351 comma not terminating READ of formatted input field

Hi Jerry! Hi all, The attached patch adds code in read_sf_internal to handle early termination of reads in the presence of comma's. This is to support legacy codes which are not standard conforming as far as we can tell. The additions are executed only if -std=legacy is given at compile

Re: [fortran, patch, committed] Adjust error message

Please remove the trailing whitespace (after "length 1"). Done (r265732). 2018-11-02 Thomas Koenig PR fortran/46020 * decl.c (verify_bind_c_sym): Remove unnecessary space in error message. Ind

[patch, fortran] Fux PR 87782

an additional call to determine length of the substring. No test case because the failure was only exposed by an instrumented compiler. Regression-tested. OK for trunk? Regards Thomas 2018-11-01 Thomas Koenig PR fortran/87782 * frontend-passes.c (constant_string_length

[fortran, patch, committed] Adjust error message

Hello world, I just adjusted the error message for BIND(C) functions which return strings of length > 1. I just used the suggestion from the PR. Committed as obvious and simple (although I managed to use up three revisions to do it right :-) Regards Thomas 2018-11-01 Thomas Koe

Patches for gcc/fortran and libgfortran need to be discussed and approved on fortran mailing list

Hi, a gentle reminder: Patches which touch gcc/fortran or libgfortran need to be discussed on the fortran mailing list and approved by a reviewer. There have been a couple of commits recently where this wasn't followed, please remember to do so in the future. Regards Thomasa

[patch, testsuite] Committed test for PR 20520

Hi, I just committed the test case below so the bug can be closed. The error message is less than ideal, but at least it is something. Maybe I'll file a separate PR about translating error messages about artificial variables to user's variables. Regards Thomas 2018-10-31 Thomas

Re: Update GCC to autoconf 2.69, automake 1.15.1

Am 31.10.18 um 04:26 schrieb Joseph Myers: This patch (diffs to generated files omitted below) updates GCC to use autoconf 2.69 and automake 1.15.1. I think this should fix PR 82856. Maybe you could confirm that this restores automake functionality with perl 5.6.26, and mention the PR in the

[patch, fortran] Fix PR 85896, type confusion with min and max

-tested. OK for trunk? Regards Thomas 2018-10-30 Thomas Koenig PR fortran/85896 * simplify.c (simplify_min_max): Do not convert the type of the return expression. 2018-10-30 Thomas Koenig PR fortran/85896 * gfortran.dg/min_max_type.f90: New test

Re: [Patch, fortran] PR40196 - [F03] [F08] Type parameter inquiry (str%len, a%kind) and Complex parts (z%re, z%im)

Hi Paul, inq would be easier to understand and unambiguous imho. Why? inquiry_type seems fine to me. I think Bernhard means the name of the member, i. I think it makes sense to leave as it is - gfc_ref is a struct that occurs a lot in complicated expressions, and the other members are one

Re: [patch, fortran] Implement FINDLOC

Hi Paul, The patch is ready to go. Please correct the following tiny nits: I have corrected those. s/Check that en expression/Check that an expression/ s/Set this if resolution has already happened and it could be harmful/Set this if resolution has already happened. It could be harmful/

Re: [patch, fortran] Implement FINDLOC

Am 23.10.18 um 23:02 schrieb Thomas Koenig: So, I think this should be clear for trunk now.  I will supply the documentation later. Ping ** 0.571428 ?

[patch, fortran, committed] Clarify warning on missing location information

a confusing error message. This tries to make sure people don't mistake this for their own error. Committed as obvious, r265559. No test case because... well, this is not supposed to happen in the first place. Regards Thomas 2018-10-27 Thomas Koenig PR fortran/86907

Re: [patch, fortran] Implement FINDLOC

Am 23.10.18 um 18:16 schrieb Dominique d'Humières: Anyway, the attached patch fixes this, It now gives the error 4 |integer, parameter :: I_FINDLOC_BACK(1) = findloc([1,1],1, & |1 Error: transformational intrinsic 'findloc' at (1)

Re: [patch, fortran] Implement FINDLOC

Hi Dominique, With your patch, compiling the following test program logtest3 implicit none logical :: x = .true. integer, parameter :: I_FINDLOC_BACK(1) = findloc([1,1],1, & back=x) end program logtest3 gives an ICE I sometimes wonder where you get all these test cases

Fwd: [patch, fortran] Implement FINDLOC

Hi, again rejected due to being overly large... The whole message can be found at https://gcc.gnu.org/ml/fortran/2018-10/msg00102.html Weitergeleitete Nachricht Betreff: [patch, fortran] Implement FINDLOC Datum: Sun, 21 Oct 2018 19:36:35 +0200 Von: Thomas Koenig An: fort

Re: [Patc, fortran] PR85603 - ICE with character array substring assignment

Hi Paul, 2018-10-18 Paul Thomas PR fortran/85603 * frontend-passes.c (get_len_call): New function to generate a call to intrinsic LEN. (create_var): Use this to make length expressions for variable rhs string lengths. Clean up some white space issues.

Re: [Patch, fortran] PR87566 - ICE with class(*) and select

Hi Paul, Bootstrapped and regtested on FC28/x86_64 - OK for trunk? Looks good. Thanks! Regards Thomas

Re: [Patch, Fortran] PR87597 - fix off-by-one issue with inline matmul

Hi Tobias, Build and regtested on x86-64-linux. OK for the trunk and - after a grace time - for GCC 6, 7 and 8? Thanks for taking this on so quickly! I don't think that this will result in any missed optimizations. Ok. Thomas

Re: [Patch, fortran] PR87151 - allocating array of character

Hi Paul, Bootstraps and regtests on FC28/x86_64 - OK for trunk and later for 8-branch? OK. Thanks for the patch! Regards Thomas

Re: [Patch, Fortran] PR fortran/83522 – reject array-valued substrings

Hi Tobias, nice to hear from you again! Build and regtested on x86_64-linux. OK for the trunk? OK. Thanks for the patch! Regards Thomas

Re: [PATCH, libgfortran] Remove recursion check

Hi Janne, The error handling functions can be called from a signal handler, so they need to be async-signal-safe. I didn't know that. How can this happen? Regards Thomas

Re: [PATCH, libgfortran] Remove recursion check

Hi Jerry, Agree it should be fixed. I would think a mutex lock should work. Lock, issue error message, unlock. Even if there is recursion, since there is at least one error somewhere, It should be OK to pause the world to issue the error, and come back and finish. AS I think about it, maybe

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

Thomas Koenig PR fortran/86111 * gfortran.h (enum arith): Add ARITH_WRONGCONCAT. * arith.h (gfc_arith_error): Issue error for ARITH_WRONGCONCAT. (gfc_arith_concat): If the types of op1 and op2 are not character of if their kinds do not match, issue

[patch, committed] Fix PR 84640

Hi, I just committed the fix below as obvious and simple. No test case because the problem was only visible in with an instrumented compiler. Regards Thomas 2018-10-06 Thomas Koenig PR fortran/84640 * simplify.c (gfc_simplify_cshift): Extend size of hs_ex

Re: [patch,wip] warn on noncontiguous pointers

Hi Cesar, As of GCC 8, gfortran now errors when a pointer with a contiguous attribute is set to point to a target without a contiguous attribute. I think this is overly strict, and should probably be demoted to a pedantic warning as I've done in the attached patch. We had a lengthy discussion

[patch, fortran, committed] Another fallout from the INTENT(OUT) patch

Hello world, another obvious and simple one-line fix for fallout from the INTENT(OUT) clobber patch. Committed as r264539, after regression-testing. It seems our testsuite is not testing as many combinations in the language as I thought :-) Regards Thomas 2018-09-24 Thomas Koenig

Re: [PATCH, libgfortran] Remove recursion check

Hi Janne, libgfortran has a recursion check in the error handling paths. This works by checking the value of a static variable, and if it matches, aborting immediately instead of continuing error processing. Unfortunately, in a multi-threaded program, if two threads report an error at the same

[patch, fortran, committed] Fix regression caused by clobber for INTENT(OUT) patch

Hello world, the attached patch, committed as obvious, fixes a regression introduced by yesterday's patch. Apparently, clobber statements are even more finicky that I thought and do not work for saved variables either. Regards Thomas 2018-09-23 Thomas Koenig PR fortran

Re: [patch, fortran] Clobber some intent(out) variables on call

Hi Jerry, s/tue/due/ a = 12345689  < missing 7 digit? Yep, you're right. Corrected, committed as r264506. Regards Thomas

[patch, fortran] Clobber some intent(out) variables on call

see https://gcc.gnu.org/ml/fortran/2018-09/msg00148.html . This turned out to cause regressions; some details are outlined in the PR. Regression-tested. OK for trunk? Regards Thomas 2018-09-22 Thomas Koenig PR fortran/41453 * trans.h (gfc_conv_expr_reference): Ad

Re: [PATCH 08/25] Fix co-array allocation

Hi Damian, On a related note, two Sourcery Institute developers have attempted to edit the GCC build system to make the downloading and building of OpenCoarrays automatically part of the gfortran build process. Neither developer succeeded. We addressed integrating OpenCoarray into the gcc

Re: [patch, fortran] Inline BLAS calls to support conjg(transpose(a))

Hi Paul, This fine, except for one niggle. Rather than having the blas source in each testcase, why don't you put all the functions in a blas file and use the dg-additional-sources mechanism? Good idea, I have added this. Committed as r264411. Regards Thomas

Re: [Patch, fortran] PR87336] [8/9 regression] wrong output for pointer dummy assiocated to target actual argument

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

[patch, fortran] Inline BLAS calls to support conjg(transpose(a))

. The code is clear enough that I think the other cases should be OK. OK for trunk? Regards Thomas 2018-09-18 Thomas Koenig PR fortran/29550 * gfortran.h (gfc_expr): Add external_blas flag. * frontend-passes.c (matrix_case): Add case A2TB2T

Re: [Patch, fortran] PR85954 - [8/9 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:266

Hi Paul, Bootstraps and regtests on FC28/x86_64 - OK for trunk and 8-branch? Ok. Thanks for the patch! Regards Thomas

Re: [patch, libgfortran] Fix warning about mismatched type declarations.

Hi Jerry, The subject patch fixes the declaration for the vlist argument of the formatted_dtio function pointer definition which currently gives a warnings during compilation for mismatched types. Regression tested on x86_64-pc-linux. OK for trunk? OK. Thanks! Regards Thomas

Re: [Patch, fortran] PRs 80477 and 86481 - memory leaks following function calls.

Hi Paul, Bootstrapped and regtested on FC28/x86_64 - OK for trunk? OK, and thanks for the patch! Regards Thomas

[patch, libfortran] correct buffer size in library matmul

Hello world, the attached patch fixes a regression where the calculation of the size of the buffer for matmul was too small for ine special case. Regression-tested. OK for trunk? Regards Thomas 2018-08-25 Thomas Koenig PR libfortran/86704 * m4/matmul_internal.m4

Re: [PATCH,FORTRAN] Remove OS dependency in definition of ASYNC_IO

David, The recent fix for Async I/O on systems without Gthread cond support added an explicit test for _AIX. This test is unnecessary because __GTHREAD_HAS_COND is not defined on AIX. Protecting the use of __gthread_cond_t inside in the ASYNC_IO macro for the declaration of struct adv_cond is

Re: Async I/O patch with compilation fix

David, I will take the "thank you for restoring bootstrap for AIX" as implied in your e-mail. Second, the patch that you applied is unacceptable.  ASYNC_IO already is set to zero for AIX. There is a clear procedure for this something that you deem "unacceptable": Submit a patch (for which I

Re: Async I/O patch with compilation fix

Nicolas and I will be there. In the meantime, I have committed the following patch (r263788) as obvious after regression-testing on Linux both with ASYNC_IO set to 1 and to 0. Let me know how that works out. 2018-08-22 Thomas Koenig * async.h: Set ASYNC_IO to zero if _AIX is defined

Re: Optimization in load_generic_interfaces()

Hi Andrew, [please also copy in gcc-patches for patches] I'm continuing to look for optimizations to improve compile times for files which USE large numbers of modules containing large numbers of symbols. When the number of symbols becomes very large, find_symbol() becomes a slow- point,

Re: Async I/O patch with compilation fix

Hi everybody, Nicolas has committed the patch as r263750. PR 87048 now traces the armeb regression, which is assumed to resurface now. Let's really try and fix that one before 9.0 :-) Regards Thomas

Re: [PATCH] Unconditionally use MAX_EXPR/MIN_EXPR for MAX/MIN intrinsics

Hi Janne, On Fri, Aug 10, 2018 at 11:47 PM, Janne Blomqvist wrote: For floating point types, the question is what MAX(a, NaN) or MIN(a, NaN) should return (where "a" is a normal number). There are valid usecases for returning either one, but the Fortran standard doesn't specify which one

Re: Async I/O patch with compilation fix

Hi Christophe, Hi, This is done by +#if defined(__GTHREAD_HAS_COND) && defined(__GTHREADS_CXX0X) && !defined(__ARMEB__) +#define ASYNC_IO 1 +#else +#define ASYNC_IO 0 +#endif I tried this version of the patch, and I'm still seeing the regression on array_constructor_8.f90. Urgh...

Re: Async I/O patch with compilation fix

Hi Christophe, sorry that this took so long, but a holiday followed by a business trip seven timezones away can do that :-) I applied this patch, and again I still see regressions on armeb-none-linux-gnueabihf --with-cpu cortex-a9 --with-fpu neon-fp16 The info that you supplied in the PR

Re: Build fail on gthr-simple.h targets (Re: AsyncI/O patch committed)

Am 26.07.2018 um 22:54 schrieb Thomas Koenig: Hi Ulrich, The problem is that io/asynch.h unconditionally uses a couple of features that are not provided by gthr-simplex, in particular    __gthread_cond_t and    __gthread_equal / __gthread_self According to the documentation in gthr.h

Re: Build fail on gthr-simple.h targets (Re: AsyncI/O patch committed)

hours or so? If so, I would like to commit this. Otherwise, Nicolas and I will not be able to fix this for a week or so, and it would be best to revert the async I/O patch :-( Regards Thomas 2018-07-25 Thomas Koenig * io/async.h: Test for feature macros for __gthread_cond_t

Re: [PATCH][Fortran] Use MIN/MAX_EXPR for intrinsics or __builtin_fmin/max when appropriate

Hi Kyrill, Because the expansion now emits straightline code rather than conditionals and branches it should be easier to optimise in general, so I'd expect this to be an improvement overall. That said, I have benchmarked it on SPEC2017 on aarch64. If you have any benchmarks of interest to

Re: [Patch, Fortran] PR 85599: warn about short-circuiting of logical expressions for non-pure functions

Am 17.07.2018 um 19:19 schrieb Janus Weil: 2018-07-17 17:18 GMT+02:00 Fritz Reese : 2018-07-17 9:52 GMT+02:00 Janus Weil : In other words: Does it make sense to tone down -Wfunction-elimination, by only warning about impure functions? Here is an update of the patch which does that.

Re: [PATCH][Fortran] Use MIN/MAX_EXPR for intrinsics or __builtin_fmin/max when appropriate

Hi Kyrill, The current implementation expands to:     mvar = a1;     if (a2 .op. mvar || isnan (mvar))   mvar = a2;     if (a3 .op. mvar || isnan (mvar))   mvar = a3;     ...     return mvar; That is, if one of the operands is a NaN it will return the other argument. If both

Re: [Patch, Fortran] PR 85599: warn about short-circuiting of logical expressions for non-pure functions

Am 16.07.2018 um 10:06 schrieb Janus Weil: However, one point: I think that the warning should be under a separate warning, which should then be enabled by -Wextra. -Waggressive-function-elimination, could be reused for this, or something else I don't actually see such a flag in the manual.

Re: [Patch, Fortran] PR 85599: warn about short-circuiting of logical expressions for non-pure functions

Hi Janus, I tested it on a fairly large code base and found no further false positives. Also it still regtests cleanly. Ok for trunk? while I still disagree with this on principle, I will not stand in the way. However, one point: I think that the warning should be under a separate warning,

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

Am 15.07.2018 um 19:47 schrieb Rainer Orth: Because this does not appear to work with Linux. I, like most gfortran developers, work on Linux, and I would like to catch any failure during regression-testing on my own system, if possible. huh, what doesn't work? I've just finished an

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

Hi Rainer, I've now regtested the patch on i386-pc-solaris2.11 and sparc-sun-solaris2.11: no regressions and the new tests all PASS. Thanks, that is good news! However, I still don't understand why you insist on the hack with putting the async_io_*.f90 tests into the libgomp testsuite. Why

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

argument spec from ".X" to ".w". (gfc_trans_wait): Pass ID argument via reference. 2018-07-15 Nicolas Koenig Thomas Koenig PR fortran/25829 * gfortran.dg/f2003_inquire_1.f03: Add write statement. * gfortran.dg/f2003_io_1.f03: Add wait st

Re: [Patch, Fortran] PR 85599: warn about short-circuiting of logical expressions for non-pure functions

Hi Janus, The cleaner approach would certainly be to avoid short-circuiting of impure functions altogether. If we can all agree that this is a good idea, This is a fine example of logical short-circuiting - the condition you mention is false, therefore the rest need not be evaluated :-)

--enable-maintainer-mode currently broken, needs --disable-werror to complete bootstrap

Hi, this is a heads-up that configuring with --enable-maintainer-mode currently breaks bootstrap; see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86450 for details. Running configure with --enable-maintainer-mode --disable-werror allows bootstrap to proceed until the underlying issue is

Re: [patch, fortran] Handling of .and. and .or. expressions

Am 28.06.2018 um 19:21 schrieb Janus Weil: One thing that I always failed to comprehend is people's fixation on optimization. What's so great about your code running 0.1% faster if the second compiler you try gives you totally different results, with no hints The warning added for my patch is

Re: [patch, fortran] Handling of .and. and .or. expressions

Hi Janus, if we add a warning, we should add it both for if (flag .and. func()) and for if (func() .and. flag) because the standard also allows reversing the test (which my original test did). Regards Thomas

Re: [patch, fortran] Handling of .and. and .or. expressions

Am 27.06.2018 um 21:15 schrieb Janne Blomqvist: If the semantic model is unclear on whether a function with potential side-effects might or might not be evaluated, then IMNSHO the semantic model is shit, and should be fixed or replaced. I disagree here, strongly. We are talking Fortran, and

Re: [patch, fortran] Handling of .and. and .or. expressions

Hi Janus, I don't think it's ok to not evaluate expressions that have side effects The Fortran standard disagrees with you (as you know, this has been quoted previously). Evaluating a function in such a case is a missed optimization. > but as long as it is guarded by a non-default >

Re: [patch, fortran] Handling of .and. and .or. expressions

Hi Janus, with your patch, we would only warn about var .and. func() and not about func() .and. var. AFAIK, TRUTH_AND_EXPR does not guarantee that func() will always be exectued, or if it does, I have not seen the documentation; it just happens to match what we currently see (which may be

Re: [patch, fortran] Handling of .and. and .or. expressions

Hi Janus, I happen to hold the opinion that optimizing out a call to a pure function may be reasonable if it does not influence the result of an expression, but optimizing out an effectively impure function (i.e. one with side effects) is not a good idea at any time, since such an

Re: [patch, fortran] Handling of .and. and .or. expressions

Am 16.06.2018 um 12:53 schrieb Janus Weil: Yes. Back when I followed c.l.f, several experts did advise people to never use functions unless they were pure (or more or less effectively so, if they didn't fulfill the standard requirements for purity). Considering that at least some of those same

Re: [patch, fortran] Handling of .and. and .or. expressions

Am 14.06.2018 um 11:55 schrieb Jakub Jelinek: Or warn users that there is no evaluation ordering between the first and second operand, that both operands are evaluated and it is unspecified which is evaluated first? Wouldn't you then just warn all the time? Even without any impure procedures,

Re: [patch, fortran] Handling of .and. and .or. expressions

Am 14.06.2018 um 10:38 schrieb Janus Weil: Also, there are AFAIU other similar weirdness with impure functions. The standard allows a compiler to optimize y = f(x) + f(x) into y = 2 * f(x) even if f is impure, which is totally bonkers. Or even not call f at all, if the compiler determines

Re: [patch, fortran] Handling of .and. and .or. expressions

Hi Janne, What about more complicated expressions like, say, "func() .and. flag .and func2() .and. flag2" etc.? Can it move all the function calls to the end? Not at the moment. Like many of the front-end optimizations, this aims for the easy 80% which are relatively easy to achieve. IMHO

Re: [patch, fortran] Handling of .and. and .or. expressions

Am 13.06.2018 um 14:20 schrieb Janus Weil: Hi Thomas, the attached patch introduces the following changes: thanks a lot for working on this! If a logical .and. or .or. expression contains a reference to a function which is impure and which also does not behave like a pure function (i.e.

[patch, fortran] Handling of .and. and .or. expressions

599, where not all people were of the same opinion. Let us see where the discussion here leads us. Regression-tested (which found one bug in the testsuite). OK for trunk? Regards Thomas 2018-06-11 Thomas Koenig PR fortran/57160 PR fortran/85599 * dump-parse-t

Re: [PATCH] PR fortran/68544 -- Issue error for derived type used as actual arg

Hi Steve, The attach patch fixes an ICE that occurs when a user uses a derived type as an actual argument to subprogram. Regression tested on x86_64-*-freebsd and i586-*-freebsd. OK to commit? OK. Thanks!

Re: [patch, fortran] Remove bounds checking in DO loops for inline matmul

Hi Steve, On Sun, Jun 10, 2018 at 02:50:56PM +0200, Thomas Koenig wrote: OK for trunk? Yes. Thanks, committed as rev 261388. Regards Thomas

[patch, fortran] Remove bounds checking in DO loops for inline matmul

inlining. The Necessary checks are already performed outside the loop, so the inner tests are not needed. OK for trunk? Regards Thomas 2018-06-10 Thomas Koenig * gfortran.h (gfc_expr): Add no_bounds_check field. * frontend-passes.c (get_array_inq_function): Set

Re: Enforce F2008:C1282 and F2018:C1588

Hi Steve, The attached patch adresses part of an issue raised in PR fortran/63514 by enforcing F2008:C1282 and F2018:C1588. Regression tested on x86_64-*-freebsd. OK to commit? OK. Thanks! PS: the actual underlying point of PR fortran/63514 is bogus, and I recommend that it be closed with

Re: [PATCH] PR79854 - diagnostics: gfc_conv_constant_to_tree should be gfc_internal_error

Hi Dominique, Is the following patch OK for the trunk? TIA Dominique 2018-06-10 Dominique d'Humieres PR fortran/79854 * trans-const.c: Remove include "diagnostic-core.h" (gfc_conv_constant_to_tree): Replace fatal_error with gcc_unreachable. OK. Thanks!

Re: [Patch, Fortran] PR 85088: improve diagnostic for bad INTENT declaration

Hi Janus, I like what the patch does. However, I have one concern. * decl.c (match_attr_spec): Synchronize the DECL_* enum values with the INTENT_* values from the enum 'sym_intent'. This part + { GFC_DECL_BEGIN = 0, DECL_ALLOCATABLE = GFC_DECL_BEGIN, +DECL_IN = INTENT_IN,

Re: [PATCH] PR fortran/78278 -- Issue error message for double initialization

Hi Steve, The attach patch re-arranges code to permit gfortran to issue an error message under non-gnu -std=* options when an entity appears in a double initialization. Prior to this patch, the new testcase pr78278.f90 would compile without error. Regression tested on x86_64-*-freebsd. OK to

Re: [patch, fortran] Fix PR 85631, wrong size checking with allocatable arrays

Hi Steve, On Fri, Jun 08, 2018 at 09:06:55PM +0200, Thomas Koenig wrote: the attached patch fixes a bug which was uncovered by the PR in a matmul regression. The problem is that bounds checking on the LHS with reallocation on assignment makes no sense, and the original flag was not set

[patch, fortran] Fix PR 85631, wrong size checking with allocatable arrays

and the reduced test to the single test case. OK for trunk? Regards Thomas 2018-06-08 Thomas Koenig PR fortran/85631 * trans.h (gfc_ss): Add field no_bounds_check. * trans-array.c (gfc_conv_ss_startstride): If flag_realloc_lhs and ss->no_bounds_check is set,

Re: [PATCH] PR fortran/86059 -- NULL() cannot be in array constructor

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

[patch, fortran, committed] Fix PR 85641

Hello world, I have just committed the attached patch as obvious after regression-testing. Since this fixes a regression, I will backport to gcc8 and gcc7 in the next days. Regards Thomas 2018-06-06 Thomas Koenig PR fortran/85641 * frontend-passes.c (is_fe_temp

Re: [PATCH] PR fortran/86045 -- test for P=0 in mod(, 0)

Hi Steve, The attached patch re-arranges the code in gfc_simply_mod(). This allows gfortran to test if the 2nd argument is zero. Tested on i586-*-freebsd and x86_64-*-freebsd. OK to commit? OK. Thanks for the patch! Regards Thomas

Re: [wwwdocs] Add GCC 8 Fortran feature description

Hi Damian,     Partial support is provided for Fortran 2018 teams, which are hierarchical     subsets of images that execute independently of other image subsets. Committed. Regards Thomas

Re: [PATCH] PR fortran/85521 -- Zero length substrings in array aconstructors

Am 10.05.2018 um 17:41 schrieb Steve Kargl: It is certainly possible to give a warning, but it would be odd (to me) to warn about technically standard conforming code. Maybe we could add gfc_warning (0, "Standard-conforming code found, your code may run as expected"); at the end of the

Ping ** (6./7.) [patch, fortran] Implement BACK for minloc and maxloc

Regression-tested. OK for trunk? I'll hold off committing until gcc 8 is actually released, just in case. Ping? I'd like to get this off my tree before it rots, and also so I can focus on other things like supporting Nicolas' async I/O patch and getting rid of the recently reported

Fwd: [patch, fortran] Implement BACK for minloc and maxloc

ommitting until gcc 8 is actually released, just in case. Regards Thomas 2018-05-01 Thomas Koenig <tkoe...@gcc.gnu.org> PR fortran/54613 * check.c (gfc_check_minmaxloc): Remove error for BACK not being implemented. Use gfc_logical_4_kind for BACK.

Display priority in "Serious" bugs for gcc 8 from web page

Hello world, whenever I look at the list of serious bugs, I find myself chaning the columns to add the priority field. What do you think about adding the priority field when clicking on that link? A patch is attached. Regards Thomas Index: index.html

Re: [patch, fortran] Remove parallell annotation from DO CONCURRENT

Well, here's a variation which actually passes regression-test. Seems I implicitly believed that the implicit save on main program variables actually works... well, it turns out that it doesn't, which is now PR85364. OK for trunk? Thomas 2018-04-12 Thomas Koenig <tkoe...@gcc.gnu.

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