Re: [patch, Fortran] Fix some string temporaries

Le 18/07/2016 à 22:20, Thomas Koenig a écrit : Am 18.07.2016 um 20:58 schrieb Mikael Morin: Unfortunately not. The original code (before I lifted out the functionality) sometimes had GFC_DEP_ERROR at the end of the function, which was then removed by return fin_dep == GFC_DEP_OVERLAP

Re: [patch, Fortran] Fix some string temporaries

Le 17/07/2016 à 18:21, Thomas Koenig a écrit : Hi Mikael, Do we actually want to backport this? Technically, it is a regression, but people are not likely to notice much. It is not an ICE, neither a code correctness issue as far as I can see, so I would rather not backport. Fine with me.

Re: [patch, Fortran] Fix some string temporaries

Hello, Le 16/07/2016 à 15:38, Thomas Koenig a écrit : Hello world, this fixes PR 71902. The recent fix for PR 71783 introduced a performance and code size regression a string temporary was created for the test case when it was not actually needed. I also took the opportunity of renaming the

Re: [patch, fortran] PR62125 Nested select type not accepted (rejects valid)

Le 15/07/2016 à 03:26, Jerry DeLisle a écrit : Hit send too soon and forgot to fill out the subject line. Correctly given here. On 07/14/2016 10:47 AM, Jerry DeLisle wrote: This simple patch kindly provided by Marco solves the problem. Regression tested on x86_64-Linux, Test case provided

Re: [Fortran] Help with STAT= attribute in coarray reference

Le 30/06/2016 06:05, Alessandro Fanfarillo a écrit : Dear Mikael, thanks for your review and for the test. The attached patch, built and regtested for x86_64-pc-linux-gnu, addresses all the suggestions. The next patch will change the documentation related to the caf_get and caf_send functions

Re: [RFC] Change order of Fortran BLOCK_VARS (PR fortran/71687, take 2)

Le 01/07/2016 16:58, Jakub Jelinek a écrit : On Thu, Jun 30, 2016 at 08:06:54PM +0200, Jakub Jelinek wrote: So, is it intentional that pushdecl / getdecls acts like a LIFO? Though, it seems user vars are pushdecled in the reverse order of declarations, but gfc_add_decl_to_function is called in

[committed] Update e-mail address

MAINTAINERS === --- MAINTAINERS (révision 237453) +++ MAINTAINERS (révision 237454) @@ -289,7 +289,7 @@ Fortran Daniel Franke <franke.dan...@gmail.com> Fortran Thomas König <tkoe...@gcc.gnu.org> Fortran Daniel Kraft <d...@domob.eu> Fortran Toon Moene <t...@moene.org>

Re: [Patch, fortran] PR69423 - [6 Regression] Invalid optimization with deferred-length character

Le 20/02/2016 19:35, Paul Richard Thomas a écrit : The only way that I know to do this reliably is to drop the use of a has and to use the extended type names directly. This will take a bit of work! Maybe the vtab pointer can be used to discriminate between types? There is one vtab struct for

Re: [Patch, fortran] PR66089 fix elemental dependency mishandling

Le 03/02/2016 14:00, Paul Richard Thomas a écrit : Dear Mikael, The patch is OK for trunk. A small niggle: Although present in the original testcase, 'a' is unused. Indeed, I'll remove it. I am not in a position to find out for myself, right now, but does the testcase of comment #10 work

[Patch, fortran] PR66089 fix elemental dependency mishandling

). Regression-tested on x86_64-unknown-linux-gnu. OK for trunk? Mikael 2016-02-01 Mikael Morin <mik...@gcc.gnu.org> PR fortran/66089 * trans-expr.c (expr_is_variable, gfc_expr_is_variable): Rename the former to the latter and make it non-static. Update c

Re: [PATCH] RFC: Use Levenshtein spelling suggestions in Fortran FE

Hello, to get things moving again, a few comments on top of David Malcolm's: Le 01/12/2015 13:55, Bernhard Reutner-Fischer a écrit : David Malcolm nice Levenshtein distance spelling check helpers were used in some parts of other frontends. This proposed patch adds some spelling corrections to

Re: [PATCH] RFC: Use Levenshtein spelling suggestions in Fortran FE

Le 03/12/2015 10:29, Janne Blomqvist a écrit : On Tue, Dec 1, 2015 at 7:51 PM, Bernhard Reutner-Fischer wrote: As said, we could as well use a list of candidates with NULL as record marker. Implementation cosmetics. Steve seems to not be thrilled by the overall idea in

Re: [Fortran, patch, pr68218, backport to 5 and 4.9, v1] ALLOCATE with size given by a module function

Le 27/11/2015 13:20, Andre Vehreschild a écrit : Hi all, I have backported the patch for 68218 (multiple calls of the same function, where only one call is expected and reasonable) to gcc-5-branch and gcc-4_9-branch. Bootstrapped and regtested on x86_64-linux-gnu/f21. Ok for gcc-5-branch? Ok

Re: [PATCH 1/2] Implement Levenshtein distance

Hello, Le 30/10/2015 13:47, David Malcolm a écrit : This patch adds an implementation of Levenshtein distance to gcc, along with unit testing of the algorithm. I noticed two nits while looking at it. diff --git a/gcc/spellcheck.c b/gcc/spellcheck.c new file mode 100644 index

Re: [PATCH] PR fortran/68151 -- Check CASE selector for valid type

Hello Steve, Le 01/11/2015 22:16, Steve Kargl a écrit : The attach patch add checking for a valid type during matching of a CASE selector. Built and regression tested on i386-*-freebsd. OK to commit? [...] Index: gcc/fortran/match.c

Re: [PATCH] Pr fortran/68153 -- Enhance checking of RESHAPE shape arg

Le 01/11/2015 20:24, Steve Kargl a écrit : The attached patch enhances the check of the shape argument when it is a named constant. See the testcase for example. Built and regression tested on i386-*-freebsd. OK to commit? Looks good, yes. Thanks. Mikael

Re: [PATCH] PR fortran/67805 -- Check for invalid charlength

Le 24/10/2015 21:29, Dominique d'Humières a écrit : At revision r229288 compiling the following test [...] while it compiles without error at r229261. I believe the accesses to ref->u.ar should be guarded with ref->type == REF_ARRAY. Steve, a patch doing that is preapproved. Mikael

Re: [PATCH] PR fortran/68054 -- PROTECTED in modules only

Le 24/10/2015 19:50, Steve Kargl a écrit : The attached patch fixes an ICE that occurs when gfortran is not expecting a PROTECTED attribute. Built and tested on x86_64-*-freebsd. OK to commit? OK. Thanks. Mikael

Re: [testsuite] Fix potential race conditions in gfortran tests

Le 22/10/2015 22:04, Maxim Kuvyrkov a écrit : Hi, And this is a similar patch for gfortran.dg/streamio_N.f90 tests. OK to commit? Sure. Mikael

Re: [testsuite] Fix potential race conditions in gfortran tests

Le 16/10/2015 10:08, Christophe Lyon a écrit : Hi, We have noticed a few random failures in gfortran tests in our validations. Maxim investigated some of them and noticed a possible race condition in the streamio tests, for which he'll post a patch. I looked for other similar cases (checking

Re: [Patch, fortran, 5] Bakport Andre's r222477 deep copy fix for PR67818

Le 15/10/2015 12:18, Andre Vehreschild a écrit : Hi Mikael, hi all, I have checked that the patch (my initial one for pr59678) does compile and test fine. Given that the patch lives in trunk-6 for quite some time now, without any major complaints, I approve to commit to gcc-5. Thanks, I'll

Re: [PATCH] Fix another bootstrap-ubsan failure due to -Werror=maybe-uninitialized.

Le 08/10/2015 11:06, Maxim Ostapenko a écrit : Hi, running UBSan bootstrap on trunk, I've run to the such issue: /home/max/workspace/downloads/svn/trunk/gcc/fortran/parse.c: In function ‘gfc_statement decode_statement()’: /home/max/workspace/downloads/svn/trunk/gcc/fortran/parse.c:368:51:

Re: [Patch, fortran, pr65889, v1] [6 Regressions] [OOP] ICE with sizeof a polymorphic variable

Le 06/10/2015 16:22, Andre Vehreschild a écrit : Hi all, the attached patch fixes a 6 regression when the argument of sizeof() is a pointer to a class object, e.g., when the class object is intent(out). The patch improves the check if the parameter is a class object by previously checking

[Patch, fortran] COMMON block error recovery: PR 67758 (second pass)

the related memory management. - In gfc_restore_last_undo_checkpoint, when a symbol has been removed from the common block linked list, its common_next pointer is cleared. Regression tested on x86_64-linux. OK for trunk? Mikael 2015-10-06 Mikael Morin <mik...@gcc.gnu.org> PR fortran

[Patch, fortran, 5] Bakport Andre's r222477 deep copy fix for PR67818

by Dominique and H.J.Lu in the PR comments [6][7] [6] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67818#c7 [7] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67818#c8 No new test, the failure is already in the libgomp testsuite. OK for the 5 branch? Mikael 2015-10-04 Mikael Morin <mik...@gcc.gnu.

[fortran, committed] Remove dead code

Hello, I found an unused variable when working on pr67758. Committed as revision 228458. Mikael Index: ChangeLog === --- ChangeLog (révision 228457) +++ ChangeLog (révision 228458) @@ -1,5 +1,9 @@ 2015-10-04 Mikael Morin <

Re: [PATCH] fortran/67758 -- Prevent ICE caused by misplaced COMMON

Le 02/10/2015 18:44, Steve Kargl a écrit : On Fri, Oct 02, 2015 at 11:28:06AM +0200, Mikael Morin wrote: Le 01/10/2015 18:30, Steve Kargl a écrit : The call-stmt in the code is the start of an execution-construct A common-stmt is not allowed in an execution-construct. At least, that's how I

Re: [PATCH] fortran/67758 -- Prevent ICE caused by misplaced COMMON

Le 01/10/2015 18:30, Steve Kargl a écrit : I'm fine with your patch, although I find the error message to be somewhat confusing as no procedure appears in COMMON. Well, XX is implicitly a procedure. The call-stmt in the code is the start of an execution-construct. A common-stmt is not

Re: [PATCH] fortran/67758 -- Prevent ICE caused by misplaced COMMON

Le 01/10/2015 14:16, Mikael Morin a écrit : Le 01/10/2015 02:07, Steve Kargl a écrit : On Wed, Sep 30, 2015 at 05:06:30PM -0700, Steve Kargl wrote: Patch built and regression tested on x86_64-*-freebsd. OK to commit? The patch prevents the dereferencing of a NULL pointer by jumping out

Re: [PATCH] fortran/67758 -- Prevent ICE caused by misplaced COMMON

Le 01/10/2015 02:07, Steve Kargl a écrit : On Wed, Sep 30, 2015 at 05:06:30PM -0700, Steve Kargl wrote: Patch built and regression tested on x86_64-*-freebsd. OK to commit? The patch prevents the dereferencing of a NULL pointer by jumping out of the cleanup of a list of COMMON blocks. Hold

Re: [PATCH] fortran/66979 -- FLUSH requires a UNIT number in the spec-list

Le 01/10/2015 01:58, Steve Kargl a écrit : When FLUSH is used with a flulsh-spec-list, a unit is required. Thus, a statement like 'flush(iostat=i)' would lead to an ICE because gfortran was dereference a pointer to a non-existant unit number. The attached patch was built and tested on

Re: [PATCH] fortran/67616 -- Fix ICE in BLOCK with a DATA statement

Le 01/10/2015 02:03, Steve Kargl a écrit : The attached patch was built and tested on x86_64-*-freebsd. OK to commit? The patch prevents an ICE in a BLOCK construct that uses a DATA statement and default initialization. The problem was that the derived typed was declared in the host and was

[Patch, fortran] PR67721 deep copy missing when assigning derived type constructor to an array

that the deep_copy flag passed to gfc_trans_scalar_assign is set to true. Regression-tested on x86_64-unknown-linux-gnu. OK for trunk? Mikael 2015-09-26 Mikael Morin <mik...@gcc.gnu.org> PR fortran/67721 * trans-expr.c (gfc_trans_assignment_1): Remove the non-constantness con

Re: [PATCH] fortran/67616 -- Fix ICE within a BLOCK construct

Le 25/09/2015 23:41, Steve Kargl a écrit : The attached patch has been built and regression tested on x86_64-*-freebsd. No regression occurred. The patch removes a conditional within an assert() that triggers when a BLOCK construct is encountered. What happens here, I think, is symtree is a

[fortran, committed] Add PR55603 testcase

228150) +++ gcc/testsuite/ChangeLog (révision 228151) @@ -1,3 +1,8 @@ +2015-09-25 Mikael Morin <mik...@gcc.gnu.org> + + PR fortran/55603 + * gfortran.dg/allocatable_function_9.f90: New. + 2015-09-25 Oleg Endo <olege...@gcc.gnu.org> PR target/67675

Re: [Patch, fortran] PR40054 and PR63921 - Implement pointer function assignment - redux

Hello Paul, Le 25/09/2015 14:21, Paul Richard Thomas a écrit : Dear Mikael, dear all, Please find attached a revised version of the patch that, I believe, addresses all the comments. The patch is very much improved and these improvements are verified by the two extra testcases. Thanks a

Re: [Patch, fortran] PR40054 and PR63921 - Implement pointer function assignment - redux

Le 06/09/2015 18:40, Paul Richard Thomas a écrit : It helps to attach the patch :-) Paul On 6 September 2015 at 13:42, Paul Richard Thomas wrote: Dear All, The attached patch more or less implements the assignment of expressions to the result of a pointer

Re: [Patch, fortran] F2008 - implement pointer function assignment

Le 27/08/2015 16:54, FX a écrit : I think it shouldn’t be too hard to get the ambiguity lifted. We already can do it for array assignment vs. statement functions, so maybe we could get a hint from that? Well, for array assignments, the array is declared before, whereas for pointer functions,

[fortran, committed] Forward port test generic_31.f90 from the 5 branch

/= -10) call abort +end program p Index: gcc/testsuite/ChangeLog === --- gcc/testsuite/ChangeLog (révision 227009) +++ gcc/testsuite/ChangeLog (révision 227010) @@ -1,3 +1,8 @@ +2015-08-19 Mikael Morin mik...@gcc.gnu.org + + PR fortran

Re: [Patch] sext_hwi: Avoid left shift of negative value undefined behaviour

with clang, but I don't think it means anything. What do you think, OK? Mikael 2015-08-18 Mikael Morin mik...@gcc.gnu.org PR other/67042 * hwint.h (sext_hwi): Switch to unsigned for the left shift, and conditionalize the whole on __GNUC__. Add fallback code

Re: [Patch] sext_hwi: Avoid left shift of negative value undefined behaviour

Le 13/08/2015 12:56, Mikael Morin a écrit : Still, implementation-defined behavior is a progress over undefined behaviour. Even if it's not set in stone, the good thing about implementation-defined behaviour is that it's known to be non-random. So it can be checked, either with autoconf

Re: [Patch] sext_hwi: Avoid left shift of negative value undefined behaviour

Le 12/08/2015 22:07, Richard Sandiford a écrit : Jeff Law l...@redhat.com writes: On 08/12/2015 12:32 PM, Richard Biener wrote: On August 12, 2015 8:07:13 PM GMT+02:00, Jeff Law l...@redhat.com wrote: On 08/12/2015 11:12 AM, Richard Biener wrote: Prec is almost never a constant and is

Re: [Patch] sext_hwi: Avoid left shift of negative value undefined behaviour

Le 12/08/2015 13:09, Richard Biener a écrit : On Wed, Aug 12, 2015 at 1:07 PM, Markus Trippelsdorf mar...@trippelsdorf.de wrote: On 2015.08.12 at 13:01 +0200, Richard Biener wrote: What kind of error does ubsan run into? That is, for which 'prec'? See:

Re: [Patch, Fortran, 66927, v1] [6 Regression] ICE in gfc_conf_procedure_call

Le 06/08/2015 14:00, Mikael Morin a écrit : Let me have a look at it. So, I've had a look at it. This is a pandora box that I don't want to open. So your change is OK. However, could you clarify the comment? Function calls returning a class object are either pointer or allocatable, so

*ping* Re: [Patch, fortran] merge two gfc_trans_scalar_assign flags

Le 19/04/2015 16:54, Mikael Morin a écrit : Hello, while working on pr65792, I noticed that gfc_trans_scalar_assign's l_is_temp and dealloc flags are used only once, and at the same place. This patch merges them together. The calls are changed from gfc_trans_scalar_assign (...blah

*ping* Re: [Patch, fortran] PR66929 fix iso_varying_string ICE

Le 25/07/2015 20:33, Mikael Morin a écrit : Le 21/07/2015 23:10, Paul Richard Thomas a écrit : On 21 July 2015 at 14:53, Mikael Morin mikael.mo...@sfr.fr wrote: Hello, The fix for PR61831 committed recently [1] introduced/uncovered a NULLL pointer dereference with iso_varying_string, because

*ping* Re: [Patch] Show address operator ('') in front of strings and functions in dumps

Le 21/07/2015 13:52, Mikael Morin a écrit : Hello, this is a followup to the bug report/patch at: https://gcc.gnu.org/ml/gcc-patches/2015-07/msg01062.html It's a fortran quite unimportant bug, so I bet nobody cares. However, the bug could have been detected when the co_reduce support

*ping* Re: patch fortran, pr 59746, internal compiler error : segmentation fault

Le 29/07/2015 20:35, Mikael Morin a écrit : Hello, I'm unburrying the patch from the thread starting at: https://gcc.gnu.org/ml/gcc-patches/2014-03/msg00439.html I provide the patch in two flavors read-only (without whitespace changes) and write-only (with them). This has been tested

[Patch] sext_hwi: Avoid left shift of negative value undefined behaviour

Hello, this avoids an error found with bootstrap-ubsan. Regression tested on x86_64-unknown-linux-gnu. OK for trunk? Mikael 2015-08-05 Mikael Morin mik...@gcc.gnu.org * hwint.h (sext_hwi): Rewrite without undefined behaviour on negative SRC. diff --git a/gcc/hwint.h b/gcc

Re: [Patch, Fortran, 66927, v1] [6 Regression] ICE in gfc_conf_procedure_call

Le 06/08/2015 12:53, Andre Vehreschild a écrit : Dear all, the attached patch fixes a regression introduced by my patches for the F2008-style allocate(). In this case a function returning an array of BT_CLASS objects can not be conv'ed using conv_expr_descriptor, but needs to be

[Patch, fortran] Rename gfc_code's expr4 field

Hello, this renames the expr4 field of gfc_code to the more descriptive ext.lock.acquired_lock. Regression tested on x86_64-unkown-linux-gnu. OK for trunk? Mikael 2015-08-05 Mikael Morin mik...@gcc.gnu.org * gfortran.h (struct gfc_code): Move expr4 field

Re: [Patch, fortran] Rename gfc_code's expr4 field

Le 05/08/2015 21:24, Steve Kargl a écrit : On Wed, Aug 05, 2015 at 08:54:21PM +0200, Mikael Morin wrote: +/* LOCK/UNLOCK statements */ +struct +{ + gfc_expr *acquired_lock; +} +lock; Just curious. Why add a struct with a single member? I would have thought s/expr4

Re: [Bug fortran/52846] [F2008] Support submodules - part 3/3

Le 03/08/2015 14:36, Paul Richard Thomas a écrit : Dear Mikael, Thanks for your green light! I have been mulling over the trans-decl part of the patch and having been wondering if it is necessary. You mean marking entities as public? Or setting the hidden visibility attribute? Or both? I

Re: [Bug fortran/52846] [F2008] Support submodules - part 3/3

Le 29/07/2015 17:08, Paul Richard Thomas a écrit : Dear All, On 24 July 2015 at 10:08, Damian Rouson dam...@sourceryinstitute.org wrote: I love this idea and had similar thoughts as well. :D Sent from my iPhone On Jul 24, 2015, at 1:06 AM, Paul Richard Thomas paul.richard.tho...@gmail.com

Re: [PATCH] PR fortran/66942 -- avoid referencing a NULL C++ thing

Le 29/07/2015 18:45, Steve Kargl a écrit : On Wed, Jul 29, 2015 at 02:04:12PM +0200, Richard Biener wrote: On Wed, Jul 29, 2015 at 1:59 PM, Mikael Morin mikael.mo...@sfr.fr wrote: Le 29/07/2015 13:22, Richard Biener a écrit : On Wed, Jul 29, 2015 at 11:34 AM, Mikael Morin mikael.mo...@sfr.fr

Re: patch fortran, pr 59746, internal compiler error : segmentation fault

2015-07-29 Bud Davis jmda...@link.com Mikael Morin mik...@gcc.gnu.org PR fortran/59746 * symbol.c (gfc_restore_last_undo_checkpoint): Delete a common block symbol if it was put in the list. 2015-07-29 Bud Davis jmda...@link.com PR fortran/59746

[Patch, fortran] PR64921 class_allocate_18 failure

sets the flag. I think it can be backported. The test is already present on the trunk and 5 branch. I plan to add it to 4.9 as well. Regression tested on x86_64-unkown-linux-gnu. OK for 6/5/4.9 ? Mikael 2015-07-29 Mikael Morin mik...@gcc.gnu.org PR fortran/64921 * class.c

Re: [PATCH] PR fortran/66942 -- avoid referencing a NULL C++ thing

Le 29/07/2015 10:26, Richard Biener a écrit : Did you try using vec_safe_splice? That handles NULL retargs, not NULL or empty arglist. I think retargs is NULL.

Re: [PATCH] PR fortran/66942 -- avoid referencing a NULL C++ thing

Le 29/07/2015 13:22, Richard Biener a écrit : On Wed, Jul 29, 2015 at 11:34 AM, Mikael Morin mikael.mo...@sfr.fr wrote: Le 29/07/2015 10:26, Richard Biener a écrit : Did you try using vec_safe_splice? That handles NULL retargs, not NULL or empty arglist. I think retargs is NULL

Re: [PATCH] PR fortran/66942 -- avoid referencing a NULL C++ thing

Le 21/07/2015 21:08, Steve Kargl a écrit : When C++ was injected into trans-expr.c in the form of vec, it seems whomever did the conversion to vec forgot to check for a NULL C++ thing. This patch seems to avoid the problem, but having zero knowledge of C++ I could be wrong. OK for trunk?

Re: [Patch, fortran] PR66929 fix iso_varying_string ICE

Le 21/07/2015 23:10, Paul Richard Thomas a écrit : Hi Mikael, This looks fine to me - OK for trunk. Thanks for the patch Paul On 21 July 2015 at 14:53, Mikael Morin mikael.mo...@sfr.fr wrote: Hello, The fix for PR61831 committed recently [1] introduced/uncovered a NULLL pointer dereference

[fortran, committed] Fix PR64986 class_to_type_4.f90 test failure

Hello, I committed the patch for PR64984 that I had posted on bugzilla. It was approved by Paul: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64986#c13 Mikael

Re: [Bug fortran/52846] [F2008] Support submodules - part 3/3

Hello Paul, Le 23/07/2015 09:46, Paul Richard Thomas a écrit : Since all the private entities in a module have to be transmitted to their descendant submodules, whilst keeping them hidden from normal use statements, I have chosen to write the module file as usual and add a second part that

Re: [Patch, fortran] PR 37131, inline matmul

Le 21/07/2015 21:49, Thomas Koenig a écrit : Am 21.07.2015 um 19:26 schrieb Mikael Morin: I would like to avoid the hack in iresolve. So let's reuse the frontend-passes.c part of my patch (set resolved_isym) I would much prefer if that was put into gfc_resolve_fe_runtime_error, next

Re: [Patch, fortran] PR 37131, inline matmul

Le 20/07/2015 23:55, Thomas Koenig a écrit : Hi, I'm back from holiday, so I can finally reply. Am 13.07.2015 um 21:54 schrieb Thomas Schwinge: --- gcc/fortran/iresolve.c +++ gcc/fortran/iresolve.c @@ -2207,6 +2207,9 @@ gfc_resolve_fe_runtime_error (gfc_code *c) a-name = %VAL;

[committed] fix PR61831 test (was: Re: *Ping* Re: [Patch, fortran] PR61831 side-effect deallocation of variable components)

of array constructor elements Index: ChangeLog === --- ChangeLog (révision 226037) +++ ChangeLog (révision 226038) @@ -1,8 +1,14 @@ +2015-07-21 Mikael Morin mik...@gcc.gnu.org + + PR fortran/61831 + * gfortran.dg

[Patch] Show address operator ('') in front of strings and functions in dumps

as 'some_func' in the dump, instead of the rather innocent 'some_func'. So I propose the attached patch which does that change. Bootstrapped and regression tested (c,c++,fortran) on x86_64-linux. OK for trunk? Mikael 2015-07-21 Mikael Morin mik...@gcc.gnu.org * tre-pretty-print.c

[Patch, fortran] PR66929 fix iso_varying_string ICE

on x86_64-linux. OK for trunk? Mikael [1]: https://gcc.gnu.org/ml/gcc-patches/2015-06/msg01389.html 2015-07-20 Mikael Morin mik...@gcc.gnu.org PR fortran/61831 PR fortran/66929 * trans-array.c (gfc_get_proc_ifc_for_expr): Use esym as procedure symbol if available

Re: [Fortran, Patch] Passing function pointer to co_reduce

Le 17/07/2015 11:02, Mikael Morin a écrit : Le 16/07/2015 16:34, Damian Rouson a écrit : Alternatively, if it’s easy, please feel free to add the directives and commit. Never mind, I'll take care of it all. This is what I have committed: https://gcc.gnu.org/r225930 (trunk) https

Re: [Fortran, Patch] Passing function pointer to co_reduce

Le 16/07/2015 16:34, Damian Rouson a écrit : Alternatively, if it’s easy, please feel free to add the directives and commit. It's not very difficult, but there is some pain getting the number of escape backslashes right. Never mind, I'll take care of it all. Mikael

Re: [Fortran, Patch] Passing function pointer to co_reduce

Le 17/07/2015 20:40, Steve Kargl a écrit : On Fri, Jul 17, 2015 at 03:50:26PM +0200, Mikael Morin wrote: Le 17/07/2015 11:02, Mikael Morin a écrit : Le 16/07/2015 16:34, Damian Rouson a écrit : Alternatively, if it?s easy, please feel free to add the directives and commit. Never mind

Re: [Fortran, Patch] Passing function pointer to co_reduce

Le 17/07/2015 21:39, Mikael Morin a écrit : It seems that this commit has changed the scanning of other testcases. Will fix. Done: https://gcc.gnu.org/r225965 (trunk) https://gcc.gnu.org/r225969 (5 branch) Mikael Index: gcc/testsuite/gfortran.dg/coarray_collectives_16.f90

Re: [Patch, fortran] PR 37131, inline matmul

Le 15/07/2015 16:03, Thomas Schwinge a écrit : Hi! On Wed, 15 Jul 2015 13:44:38 +0200, Mikael Morin mikael.mo...@sfr.fr wrote: Le 13/07/2015 21:54, Thomas Schwinge a écrit : Original situation; _gfortran_runtime_error is not being properly declared (invoked via gcc/fortran/frontend

Re: [Patch, fortran] PR 37131, inline matmul

Hello, Le 13/07/2015 21:54, Thomas Schwinge a écrit : Original situation; _gfortran_runtime_error is not being properly declared (invoked via gcc/fortran/frontend-passes.c:runtime_error_ne), but, for example, _gfortran_error_runtime_at is being properly declared (invoked from elsewhere):

Re: [Fortran, Patch] Passing function pointer to co_reduce

Hello, Le 13/07/2015 17:31, Alessandro Fanfarillo a écrit : Dear all, during the implementation of co_reduce in OpenCoarrays I noticed that GFortran passes a pointer to function instead of the function name to co_reduce. More exactly there are two address operators ('') in a row (the

Re: [RFC, Fortran, (pr66775)] Allocatable function result

Le 10/07/2015 20:57, Steve Kargl a écrit : On Fri, Jul 10, 2015 at 06:20:47PM +0200, Mikael Morin wrote: I'm not completely convinced by the standard excerpts that have been quoted about this topic, as they don't have any explicit mention of allocatable variables/expressions. I did

Re: [RFC, Fortran, (pr66775)] Allocatable function result

Le 11/07/2015 12:36, Andre Vehreschild a écrit : Hi, snip On completion of execution of the function, the value returned is that of its function result. ... If the function result is not a pointer, its value shall be defined by the function. Now we can argue whether the shall

*Ping* Re: [Patch, fortran] PR61831 side-effect deallocation of variable components

Ping: https://gcc.gnu.org/ml/fortran/2015-06/msg00075.html Le 21/06/2015 11:48, Mikael Morin a écrit : Le 16/05/2015 18:43, Mikael Morin a écrit : Hello, this is about PR61831 where in code like: type :: string_t character(LEN=1), dimension(:), allocatable :: chars

Re: [Patch, Fortran, 66035, v2] [5/6 Regression] gfortran ICE segfault

hello Andre. Le 06/07/2015 13:54, Andre Vehreschild a écrit : Hi all, please find attached the next version of the patch for pr66035 fixing an ICE. Scope (copied from first submit): An ICE occurred when in a structure constructor an allocatable component of type class was initialized

Re: [RFC, Fortran, (pr66775)] Allocatable function result

Hello all, I'm not completely convinced by the standard excerpts that have been quoted about this topic, as they don't have any explicit mention of allocatable variables/expressions. For what it's worth, in my opinion, the handling of allocatable that was proposed by Andre makes sense to me.

Re: [Fortran, patch, pr64589, v1] [OOP] Linking error due to undefined integer symbol with unlimited polymorphism

Le 10/07/2015 16:51, Andre Vehreschild a écrit : Hi everyone, attached is a rather trivial patch to fix a linker issue when unlimited polymorphism is used and the vtabs of intrinsic types are referenced from two different locations (e.g. module and main program). Gfortran finds the vtab

Re: [Patch, fortran] PR61831 side-effect deallocation of variable components

Le 16/05/2015 18:43, Mikael Morin a écrit : Hello, this is about PR61831 where in code like: type :: string_t character(LEN=1), dimension(:), allocatable :: chars end type string_t type(string_t) :: prt_in (...) tmp = new_prt_spec ([prt_in

[Patch, fortran] PR66549 [5/6 regression] ICE with OMP PARALLEL

for trunk/5 ? Mikael 2015-06-18 Mikael Morin mik...@gcc.gnu.org PR fortran/66549 * resolve.c (resolve_global_procedure): Don't save and restore OpenMP state around the call to gfc_resolve. (gfc_resolve): Save OpenMP state on entry and restore it on return. 2015

Re: [Patch, fortran] PR66549 [5/6 regression] ICE with OMP PARALLEL

Le 18/06/2015 13:35, Jakub Jelinek a écrit : On Thu, Jun 18, 2015 at 01:18:18PM +0200, Mikael Morin wrote: I'm proposing here a fix for an OpenMP ICE regression introduced by me at http://gcc.gnu.org/r221586 That revision changed the order in which procedures are resolved, making it possible

Re: Fortran's C_CHAR type

Le 08/06/2015 17:31, Jan Hubicka a écrit : Hi, to furhter add to the topics to discuss, I noticed that Fortran FE seems to be quite ambivalent about C_CHAR type: [jh@gcc2-power8 gcc]$ cat ../b.f90 ! This testcase will abort if C_CHAR types are not interoperable module lto_type_merge_test

Re: Fortran's C_CHAR type

Le 10/06/2015 16:38, Jan Hubicka a écrit : [jh@gcc2-power8 gcc]$ cat ../b.f90 ! This testcase will abort if C_CHAR types are not interoperable module lto_type_merge_test use, intrinsic :: iso_c_binding implicit none contains function types_test1(V) bind(c) USE, INTRINSIC ::

Re: [Patch, fortran, PR44672, v6] [F08] ALLOCATE with SOURCE and no array-spec

Hello Andre, comments below (out of order, sorry). Le 29/05/2015 13:46, Andre Vehreschild a écrit : Hi Mikael, comments inline below: On Thu, 28 May 2015 20:06:57 +0200 Mikael Morin mikael.mo...@sfr.fr wrote: Le 28/05/2015 17:29, Andre Vehreschild a écrit

Re: [Patch, fortran, PR44672, v6] [F08] ALLOCATE with SOURCE and no array-spec

Le 28/05/2015 17:29, Andre Vehreschild a écrit : *** resolve_allocate_expr (gfc_expr *e, gfc_ *** 7103,7112 --- 7103,7123 if (!ref2 || ref2-type != REF_ARRAY || ref2-u.ar.type == AR_FULL || (dimension ref2-u.ar.dimen == 0)) { + /* F08:C633. */

Re: [Patch, fortran] PR66079 - [6 Regression] memory leak with source allocation in internal subprogram

Le 27/05/2015 23:09, Steve Kargl a écrit : On Wed, May 27, 2015 at 06:24:25PM +0200, Mikael Morin wrote: Le 27/05/2015 16:07, Andre Vehreschild a ?crit : Hi Paul, hi Mikael, about renaming the identifier emitted: I would like to keep it short. Remember, there is always a number attached

Re: [Patch, fortran] PR66079 - [6 Regression] memory leak with source allocation in internal subprogram

Le 27/05/2015 16:07, Andre Vehreschild a écrit : Hi Paul, hi Mikael, about renaming the identifier emitted: I would like to keep it short. Remember, there is always a number attached to it, which makes it unique. Furthermore does alloc_source_tmp sound unnecessarily long to me. It tastes

Re: [Patch, fortran] PR66079 - [6 Regression] memory leak with source allocation in internal subprogram

Le 25/05/2015 09:30, Paul Richard Thomas a écrit : Dear All, Lets see if I can get it right this time :-) Note that I have changed the name of the temporary variable in trans_allocate from 'atmp' to 'expr3' so that it is not confused with array temporaries. I agree with Andre willing to

Re: [Patch, fortran] PR66079 - [6 Regression] memory leak with source allocation in internal subprogram

hello Andre, Le 25/05/2015 12:24, Andre Vehreschild a écrit : Hi Paul, I am not quite happy with the naming of the temporary variable. When I initially set the prefix to atmp this was because the variable would be an array most of the time and because of the number appended to it should be

Re: [Patch, fortran, PR44672, v6] [F08] ALLOCATE with SOURCE and no array-spec

Le 19/05/2015 12:26, Andre Vehreschild a écrit : Hi all, update based on latest 65548 (v5) patch and current trunk. Description and issue addressed unchanged (see cite below). Bootstrapped and regtested on x86_64-linux-gnu/f21. Any volunteers to review? The initial version dates back to

[Patch, fortran] PR66257 [5/6 regression] elemental typebound calls rejected as actual argument

-05-23 Mikael Morin mik...@gcc.gnu.org PR fortran/66257 * resolve.c (resolve_actual_arglist): Don't throw an error if the argument with procedure pointer component is not a variable. 2015-05-23 Mikael Morin mik...@gcc.gnu.org PR fortran/66257 * typebound_call_27.f90: New file. diff --git

Re: PR fortran/44054 Convert all gfc_error_1 calls to gfc_error

Le 23/05/2015 01:04, Manuel López-Ibáñez a écrit : PING: https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01511.html This only needs approval from Fortran maintainers. I approved: https://gcc.gnu.org/ml/fortran/2015-05/msg00135.html But it seems I replied to the fortran list only. Mikael

Re: Ping ** 0.5 patch, fortran] Inline matmul with conjugate complex numbers

Le 21/05/2015 19:51, Thomas Koenig a écrit : Am 18.05.2015 um 00:05 schrieb Thomas Koenig: this patch extends the inline matmul functionality to conjugate complex numbers. Regression-tested. OK for trunk? OK (with the trivial change in the follow-up e-mail)? I'd like to start extending

Re: [Patch, fortran, pr65548, 2nd take, v5] [5/6 Regression] gfc_conv_procedure_call

Le 20/05/2015 10:24, Andre Vehreschild a écrit : Hi Mikael, when I got you right on IRC, then you proposed this change about the pointer attribute: diff --git a/gcc/fortran/trans-stmt.c b/gcc/fortran/trans-stmt.c index 6d565ae..545f778 100644 --- a/gcc/fortran/trans-stmt.c +++

Re: [Patch, fortran, pr65548, 2nd take, v5] [5/6 Regression] gfc_conv_procedure_call

Le 19/05/2015 10:50, Andre Vehreschild a écrit : Hi all, find attached latest version to fix 65548. Bootstraps and regtests ok on x86_64-linux-gnu/f21. OK. Thanks. Mikael

[Patch, fortran] PR61831 side-effect deallocation of variable components

Mikael Morin mik...@gcc.gnu.org PR fortran/61831 * trans-array.c (gfc_conv_array_parameter): Remove allocatable component deallocation code generation. * trans-expr.c (gfc_conv_expr_reference): Ditto. (expr_may_alias_variables): New function

Re: [patch, fortran] [5/6 Regression] Line continuation followed by comment character in string fails to compile

Le 14/05/2015 03:58, Jerry DeLisle a écrit : The attached patch reverts a change I made for pr65456 which caused this regression and adds a check for quotes farther down in the function. This avoids treating a '!' in a string as a comment and wiping the rest of the line. I found the added

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