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

string lengths. Clean up some white space issues. 2018-10-18 Paul Thomas PR fortran/85603 * gfortran.dg/deferred_character_23.f90 : Check reallocation is occurring as it should.. On Sat, 22 Sep 2018 at 11:23, Paul Richard Thomas wrote: > > Yet another 'obvious' deferred cha

Re: [Patch, fortran] PR58618 - Wrong code with character substring and ASSOCIATE

Patch for the PR70149 regression committed as revision 265263. Likewise the patch for PR58618 has been committed as revision 265264. Cheers Paul On Wed, 17 Oct 2018 at 22:17, Tobias Burnus wrote: > > Hi Paul, > > Paul Richard Thomas wrote: > > This problem concerned assoc

Re: [Patch, fortran] PR58618 - Wrong code with character substring and ASSOCIATE

. Paul On Wed, 17 Oct 2018 at 22:17, Tobias Burnus wrote: > > Hi Paul, > > Paul Richard Thomas wrote: > > This problem concerned associate targets being substrings. It turns > > out that they are returned as pointer types (with a different cast for > > unity based

Re: [Patch, Fortan] PR 87632 - fix select type ICE

Hi Tobias, Thanks for taking care of that so quickly. Juergen is proving to be a loyal friend to gfortran by coming back to us so quickly on regressions and reducing testcases. He deserves a good service. Cheers Paul On Wed, 17 Oct 2018 at 20:59, Tobias Burnus wrote: > > Due to using the

[Patch, fortran] PR58618 - Wrong code with character substring and ASSOCIATE

This problem concerned associate targets being substrings. It turns out that they are returned as pointer types (with a different cast for unity based substrings ***sigh***) and so can be assigned directly to the associate name. The patch quite simply removed the condition that such targets be

[Patch, fortran] PR56386 - [F03] ICE with ASSOCIATE construct and an derived type array component

This is a semi-obvious patch that fixes no fewer than five PRs: 56386, 58906, 77385, 80260 & 82077. The last two are marked as 7/8/9 regressions and so, although I haven't tested it yet, I suppose that the others must be too. Thanks to Dominique for picking up the other four PRs that are fixed by

Re: [Patch, Fortran] PR87556 – for FORM TEAM also use argse.pre/post

Hi Tobias, Following our exchange off-list, I rather agree with you that a testcase is pointless. Besides which, I do not see this regressing :-) OK for trunk and, if you are feeling strong, 8-branch. Thanks and welcome back. Paul On Mon, 15 Oct 2018 at 20:46, Tobias Burnus wrote: > > as the

Re: [Patch, Fortran] PR67125 - ALLOCATE with source-expr lbounds/ubound off by one

Hi Tobias, Your patch is OK for trunk and, I would suggest 8-branch. As a matter of curiosity, why did you not use the condition: if (!(expr3_desc && GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (expr3_desc))) ? Your solution is fine, though. Cheers Paul On Fri, 12 Oct 2018 at 12:29, Tobias Burnus

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

Committed as revision 265171. Thanks to you, Dominique and, of course, Tobias. Paul On Mon, 15 Oct 2018 at 10:15, Thomas Koenig wrote: > > Hi Paul, > > > Bootstrapped and regtested on FC28/x86_64 - OK for trunk? > > Looks good. Thanks! > > Regards > > Thomas -- "If you can't

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

Tobias started this patch and I finished it in answering a question that he had about a problem with the gimplifier. Along the way, I tried the associate version of the select type test case and found that it failed in a different way. The chunk in resolve_assoc_var fixes that. Bootstrapped and

Re: [Patch, Fortran] PR58787 ICE (error recovery) in check_proc_interface

Hi Tobias, This is OK. Thanks for the patch and the extra careful regtesting :-) Paul On Fri, 12 Oct 2018 at 00:17, Tobias Burnus wrote: > > Next patch, next try … > > The problem is the following: We have a use-associated symbol (a > function) – which is once referenced (by use association).

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

nsion or how other Fortran compilers behave. > > GNU Fortran probably should be compatible with other Fortran > compilers, even if the behavior is not pedantically conformant with > the standard. > > Thanks, David > > On Wed, Oct 10, 2018 at 7:12 PM Paul Richard Thomas > w

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

This seems to have caused errors in the testsuite. I guess that the problem is that the testcases are invalid :-( >From David Edelsohn: Error: Substring reference of nonscalar not permitted at (1) arrayio_11.f90 arrayio_12.f90 associate_23.f90 data_char_1.f90 deferred_character_2.f90

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

Hi Dominique, Thanks for the testing. Although the tests for PR80931 and PR83196, comment #4, compiled OK, when I attempted to use the modules both segfaulted for the same reason ('span' not being set on the array descriptor) and these required a slightly different version of the same tweak. The

{Patch, fortran] PR86372 - [8/9 Regression] Segfault on ASSOCIATE statement with CHARACTER variable

I have fixed this as 'obvious' on 8-branch(r264925) and trunk(r264915). Paul 2018-10-08 Paul Thomas Backport from trunk PR fortran/86372 * trans-stmt.c (trans_associate_var): Character associate names with variable string length do not have to be deferred length for the

[Patch, fortran] PR87151 - allocating array of character

This turned out to be rather more than the allocation... The ChangeLog and the patch tell the story well enough. Bootstraps and regtests on FC28/x86_64 - OK for trunk and later for 8-branch? Cheers Paul 2018-10-07 Paul Thomas PR fortran/87151 * trans-array.c (gfc_get_array_span):

[Patch, fortran] PR87359 [9 regression] pointer being freed was not allocated

After testing by Dominique and Juergen. Committed as revision 264725. Thanks to Dominique and juergen for doing all the hard work! Cheers Paul 2018-09-30 Paul Thomas PR fortran/87359 * trans-array.c (gfc_is_reallocatable_lhs): Correct the problem introduced by r264358, which

Re: [Patch, fortran] PRs 70752 and 72709 - more deferred character length bugs

ran.dg/deferred_character_26.f90 : New test. * gfortran.dg/deferred_character_27.f90 : New test to verify that PR82617 remains fixed. On Sun, 30 Sep 2018 at 09:02, Paul Richard Thomas wrote: > > Hi Dominique, > > It's the patch for pr70752 that causes the trouble, which I

Re: [Patch, fortran] PRs 70752 and 72709 - more deferred character length bugs

Hi Dominique, It's the patch for pr70752 that causes the trouble, which I had guessed from the point in trans.c where the ICE occurs. I am onto it. Thanks again Paul On Wed, 26 Sep 2018 at 16:52, Dominique d'Humières wrote: > > > Is se->string_length guaranteed to be of type

Re: [Patch, fortran] PRs 70752 and 72709 - more deferred character length bugs

Hi Dominique, Thanks for the heads up - I will check it out and fix it next week before doing any commits. Cheers Paul On 26 September 2018 at 16:52, Dominique d'Humières wrote: >> Is se->string_length guaranteed to be of type gfc_array_index_type_here? >> If so, why? And if not, maybe a

[Patch, fortran] PRs 70752 and 72709 - more deferred character length bugs

This patch is a bit more complicated than some of the previous posts. However, the ChangeLog explains the story pretty clearly. Bootstraps and regtests on FC21/x86_64 - OK for trunk and 8-branch? Again, better names for the testcases will be determined before committing. Paul 2018-09-25 Paul

[Patch, fortran] PR70149 - [F08] Character pointer initialization causes ICE

This is yet another deferred length character bug. The fix speaks for itself. I'll dream up a more suitable name for the testcase before committing. Bootstraps and regtests on FC21/x86_64 - OK for trunk and 8-branch? Paul 2018-09-25 Paul Thomas PR fortran/70149 * trans-decl.c

[Patch, fortran] PR65677 - Incomplete assignment on deferred-length character variable

This is yet another deferred character length problem that this time is caused by a dependency in assignment between lhs and rhs string_lengths. The comment in the testcase explains all. Bootstraps and regtests on FC21/x86_64 - OK for trunk and 8-branch? I cannot commit until next week. Paul

Re: [PATCH] Do array index calculations in gfc_array_index_type

Hi Janne, Good catch - thanks for dealing with this. OK for trunk. Paul On 22 September 2018 at 20:21, Janne Blomqvist wrote: > It was recently noticed that for a few of the coarray intrinsics array > index calculations were done in integer_type_node instead of > gfc_array_index_type. This

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

Yet another 'obvious' deferred character fix. Committed to trunk as r264502. Will backport in about ten days time. Paul 2018-09-22 Paul Thomas PR fortran/85603 * trans-array.c (gfc_alloc_allocatable_for_assignment): Test the charlen backend_decl before using the VAR_P macro.

[Patch, fortran] PR77325 - ICE in gimplify_var_or_parm_decl, at gimplify.c:1933

This is yet another deferred character problem occurring at exactly the same place as 87239 and 84109. I found another bug while going along and so have fixed that too. Bootstrapped and regtested on FC28/x86_64. I will apply all three to 8-branch in slightly more than one week's time. Paul

[Patch, fortran] PR87359 [9 regression] pointer being freed was not allocated

This bug was something of a disaster for Jeurgen Reuter and so I set to it right away. Jeurgen's reduction of the failing programs save a huge amount of time and the fix turned out to be a one-liner. Committed after testing by Dominique. Bootstrapped and regtested on FC28/x86_64. Paul Author:

[Patch, fortran] PR84109 - ICE in adjustl on allocatable array of strings

As Dominique pointed out (and I denied initially - sorry!) this PR is essentially the same as PR87239 except that an intrinsic, rather than an extrinsic, function is involved. I have treated it in the same way but have added a slight improvement to keep scalar elemental calls outside of the

[Patch, fortran] PR87239 - ICE in deferred-length string

This is sufficiently 'obvious' that I have committed the patch to trunk as revision 264409. My inclination is to commit it to 8-branch as well since deferred character bugs were one of the complaints in the fortran standards survey. OK? Paul 2018-09-18 Paul Thomas PR fortran/87239

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

Hi Thomas, 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? Cheers Paul On 18 September 2018 at 18:46, Thomas Koenig wrote: > Hello world, > > this patch

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

Thanks Thomas, I'll take a look at your in a few minutes. Cheers Paul On 18 September 2018 at 18:50, Thomas Koenig wrote: > Hi Paul, > >> Bootstraps and regtests on FC28/x86_64 - OK for 8- and 9-branches? > > > OK. Thanks for the patch! > > Regards > > Thomas -- "If you can't

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

This one came up on clf yesterday. Thanks to Jeurgen Reuter for posting the PR. This is further fallout from the array descriptor changes. I decided not to pick out the special case involved but to set the 'span' field for all new (ie. 'parm') descriptors. A bit of fiddling around with

Re: [Patch, fortran] PR64120 - [F03] Wrong handling of allocatable character string

Hi Janne, Thanks. Committed as revision 264365. Paul On 17 September 2018 at 11:34, Janne Blomqvist wrote: > On Mon, Sep 17, 2018 at 1:10 PM Paul Richard Thomas > wrote: >> >> This patch is relatively trivial. This initialization of the string >> length was not bein

[Patch, fortran] PR64120 - [F03] Wrong handling of allocatable character string

This patch is relatively trivial. This initialization of the string length was not being done. Bootstraps and regtests on FC28/x86_64. OK for trunk? Paul 2018-09-17 Paul Thomas PR fortran/64120 * trans-decl.c (gfc_get_symbol_decl): Flag allocatable, scalar characters with a

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

I spent far more time on this PR because I was focusing on entirely the wrong place in the code. Or, rather the clue that was needed for the fix was elswhere. The type declarations for the deferred character length dummies were not being generated. Rather than being a problem in the associate

Re: [PATCH][libgfortran] Fix uninitialized variable use in fallback_access

Hi Kyrill, This indeed is an obvious change. OK for trunk and 7- and 8-branches. Thanks for the patch Paul On 14 September 2018 at 09:06, Kyrill Tkachov wrote: > Hi all, > > I've been tracking down a bug in a Fortran program on a newlib target and it > boils down to fallback_access doing

[Patch, fortran] PR87284 - [7/8/9 Regression] Allocation of class arrays with mold results in "conditional jump or move depends on uninitialised value"

The above has been fixed as 'obvious' on all three branches. Revisions 264249, 264251 and 264288. Cheers Paul 2018-09-13 Paul Thomas PR fortran/87284 * trans-expr.c (gfc_trans_class_init_assign): Access to to array elements of the dynamic type requires that the array

[Bug fortran/87277] [8/9 regression] Segfault on using array component of class scalar pointer as an actual argument

Fixed as 'obvious' on trunk and 8-branch in revisions 264210 and 264213 respectively. Paul 2018-09-11 Paul Thomas PR fortran/87277 * expr.c (is_subref_array): Add the check of dimensionality for class, dummy, pointer arrays. 2018-09-11 Paul Thomas PR fortran/87277 *

Re: [Patch, Fortran, F03] PR 85395: private clause contained in derived type acquires spurious scope

Hi Janus, That's OK for trunk and, I would suggest 8-branch. Thanks for the patch. Paul On 9 September 2018 at 17:31, Janus Weil wrote: > Hi all, > > the attached patch fixes a problem with the accessibility of procedure > pointer components (private/public attribute). It is rather >

Re: [Patch, Fortran] PR 86830: [8/9 Regression] Contiguous array pointer function result not recognized as contiguous

Hi Janus, That's fine - OK for both branches. Thanks Paul On 9 September 2018 at 21:34, Janus Weil wrote: > Hi all, > > the attached patch fixes a rejects-valid regression, where a > type-bound procedure call was not correctly detected to have a > contiguous result. The patch is functionally

Re: [Patch, fortran] PR86328 - [8/9 Regression] Runtime segfault reading an allocatable class(*) object in allocate statements

Hi Janus, Thanks for the review. I decided to commit just the parts that address the regression to both branches. Assignment to polymorphic variables is in such a mess that I did not consider it sensible to apply part of a fragment of Band Aid. I will raise a PR for the bugs that I know of.

[Patch, fortran] PR86328 - [8/9 Regression] Runtime segfault reading an allocatable class(*) object in allocate statements

The attached patch fixes PR86328 and PR86760. The regression was caused by my commit r252949. The parts of the patch that fix the PRs are in trans.c and trans-array.c. The problem was caused by fixing the expressions that would provide the 'span' in gfc_build_array_ref, since the latter expected

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

Committed as r263916. Thanks for taking a look over it, Thomas. Paul On Mon, 27 Aug 2018 at 20:26, Thomas Koenig wrote: > > Hi Paul, > > > Bootstrapped and regtested on FC28/x86_64 - OK for trunk? > > OK, and thanks for the patch! > > Regards > > Thomas -- "If you can't explain it

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

This patch grew from the original patch for PR80477 because it was found that the array valued version leaked memory as well. Then, I found that the assignment in class_result_9.f90 ICEd, while trying to fix the array valued test, class_result_8.f90. Finally, while I was about it, I fixed PR86481,

Re: [Patch, Fortran, F08] PR 86888: allocatable components of indirectly recursive type

Hi Janus, > the attached patch fixes the PR in the subject line in a rather > straightforward fashion. Pointer components of indirectly recursive > type are working already, as well as allocatable components of > directly recursive type. It seems this case was simply forgotten. That is correct.

[[Patch, fortran] PR86863 - [OOP][F2008] type-bound module procedure name not recognized

I have cast around for a better way to fix this bug but have not come up with anything. Although brute force, the patch does the job. The testcase has been extended to include a MODULE PROCEDURE in a submodule, which I think must have been the contributor's original intention. Bootstrapped and

Re: [Patch, fortran] A first small step towards CFI descriptor implementation

wrote: > > Hi Paul, > > 2018-07-31 14:06 GMT+02:00 Paul Richard Thomas > : > > Daniel Celis Garza and Damian Rouson have developed a runtime library > > and include file for the TS 29113 and F2018 C descriptors. > > https://github.com/sourceryinstitute/ISO_For

Re: [Patch, fortran] A first small step towards CFI descriptor implementation

Hi Richard, Ah yes, you are absolutely right. I will sit on it for a bit and do the interchange at the descriptor conversion stage for now. Thanks Paul On Tue, 31 Jul 2018 at 15:57, Richard Biener wrote: > > On Tue, Jul 31, 2018 at 2:07 PM Paul Richard Thomas > wrote: > > &

[Patch, fortran] A first small step towards CFI descriptor implementation

Daniel Celis Garza and Damian Rouson have developed a runtime library and include file for the TS 29113 and F2018 C descriptors. https://github.com/sourceryinstitute/ISO_Fortran_binding The ordering of types is different to the current 'bt' enum in libgfortran.h. This patch interchanges

[Patch, fortran] PR80477 - [OOP] Polymorphic function result generates memory leak

Several attempts, including mine, were made to fix this bug since it was posted. They were all attacking the wrong place. Instead of providing the free of the class _data as part of the call to 'add_a_type' it should be included in the post block of the argument processing in the call to

Re: [Patch, fortran] PR66679 - [OOP] ICE with class(*) and transfer

Ping! On Thu, 5 Jul 2018 at 08:51, Paul Richard Thomas wrote: > > The comment in the patch says it all. > > Bootstrapped and regtested on FC28/x86_64 - OK for trunk? > > Paul > > 2018-07-05 Paul Thomas > > PR fortran/66679 > * trans-intrinsic.c (gf

[Patch, fortran] PR66679 - [OOP] ICE with class(*) and transfer

The comment in the patch says it all. Bootstrapped and regtested on FC28/x86_64 - OK for trunk? Paul 2018-07-05 Paul Thomas PR fortran/66679 * trans-intrinsic.c (gfc_conv_intrinsic_transfer): Class array elements are returned as references to the data element. Get the class

Re: [patch, committed, fortran] PR82009 [F08] ICE with block construct

Thanks, Jerry. On Wed, 4 Jul 2018 at 19:14, Jerry DeLisle wrote: > > This patch committed as obvious after regression testing and auditing > the code. New test case added. > > Author: jvdelisle > Date: Wed Jul 4 18:08:16 2018 > New Revision: 262416 > > URL:

[Patch, fortran] PR86242 [6/7/8/9 Regression] [OOP] ICE for derived type with allocatable component and proc-ptr component

This patch is 'obvious' and I will commit to trunk tomorrow night if there are no objections. The other branches will follow next week. Bootstrapped and regtested on FC28/x86_64. Cheers Paul 2018-06-30 Paul Thomas PR fortran/82969 PR fortran/86242 * trans-array.c

Re: [Patch, fortran] PR45305 - Array-valued calls to elementals are not simplified

Ok, thanks. I think that I will stick to trunk, since we do not seem to have been overwhelmed with demand to fix this! Regards Paul On Sat, 30 Jun 2018 at 15:37, Jerry DeLisle wrote: > > On 06/27/2018 06:48 AM, Paul Richard Thomas wrote: > > I posted a patch for this on the PR in

[Patch, fortran] PR45305 - Array-valued calls to elementals are not simplified

I posted a patch for this on the PR in August 2010. Dominique pointed out that it caused repeated error messages in some testcases; eg. arithmetic_overflow_1.f90 As it happens, that seems to have crept in at some time even without the patch for this PR. Nevertheless, I have modified the patch

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

Thanks, Steve. Committed to trunk as revision 261857. 8-branch will be patched in a few days. Any opinions about 7-branch? Cheers Paul On 21 June 2018 at 16:23, Steve Kargl wrote: > On Thu, Jun 21, 2018 at 09:02:53AM +0100, Paul Richard Thomas wrote: >> The original problem

Re: [Patch, fortran] PR49630 - [OOP] ICE on obsolescent deferred-length type bound character function

Ping! On 19 June 2018 at 10:16, Paul Richard Thomas wrote: > I got caught with a wild goose chase with this one. I tried to get it > to work before seeing the standard reference in trans-expr.c. In fact, > it would be impossible to fix because there is no way to resolve > differe

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

The original problem was fixed by the patch for PR84546. This patch fixes a variant that appears in comment #6. The fix is completely straightforward and described by the comments and ChangeLogs. Bootstrapped and regtested on FC28/x86_64 - OK for trunk? I am not sure that this problem is a

[Patch, fortran] PR49630 - [OOP] ICE on obsolescent deferred-length type bound character function

I got caught with a wild goose chase with this one. I tried to get it to work before seeing the standard reference in trans-expr.c. In fact, it would be impossible to fix because there is no way to resolve different instances of the abstract interface with different character lengths.

Re: [Committed] PR fortran/86110 -- Avoid NULL pointer dereference

Great! Thanks, Steve. On 13 June 2018 at 20:43, Steve Kargl wrote: > Committed as obviously. > > 2018-06-13 Steven G. Kargl > > PR fortran/86110 > * array.c (gfc_resolve_character_array_constructor): Avoid NULL > pointer dereference. > > 2018-06-13 Steven G. Kargl >

Re: [Patch, fortran] PR36497 - USE association, cray pointers and error checking

Committed as revision 261127. The PR is closed. The permissions of my ssh keys were changed by a system update; hence the difficulties with updating my tree. Paul On 3 June 2018 at 09:29, Paul Richard Thomas wrote: > I was going to commit this as obvious but GNU-central seems to be > d

[Patch, fortran] PR36497 - USE association, cray pointers and error checking

I was going to commit this as obvious but GNU-central seems to be down. I will do so when I can. I only intend to apply it to trunk since it has been around since 2008-06-11 without any clamor to fix it :-) I don't recall why I took it on in the first place. Cheers Paul 2018-06-03 Paul Thomas

[Patch, fortran] PR 49636 - [F03] ASSOCIATE construct confused with slightly complicated case

This patch is a straightforward recycling of existing code to replace an incomplete copy elsewhere. Bootstraps and regtests on FC27/x86_64 - OK for trunk down to 7-branch? Paul 2018-05-19 Paul Thomas PR fortran/49636 * trans-array.c (gfc_get_array_span): Renamed

[Patch, fortran] PR80657 - [7/8/9 Regression] Loop in character function declaration

I intend to commit this as 'obvious' once the patches for PR82923 and 82275 are out of the way. Paul 2018-05-19 Paul Thomas PR fortran/80657 * resolve.c (flag_fn_result_spec): Use the 'sym' argument to test for self refs to the function result in the character

Re: [Patch, fortran] PR82923 - Automatic allocation of deferred length character using function result

Thanks! I will take this as an OK to commit. Regards Paul On 19 May 2018 at 10:18, Dominique d'Humières wrote: > The patch works as expected and fixes also PRs 66694 and 82617. > > Thanks, > > Dominique > -- "If you can't explain it simply, you don't understand it well

[Patch, fortran] PR82275 - gfortran rejects valid & accepts invalid reference to dimension-remapped type SELECT TYPE selector

This patch is verging on 'obvious' since there was no attempt being made to detect dimensions where the array reference of the selector is an element. In fact, I made an attempt when the bug was first reported to do this, Not realizing that the elements were coming through as DIMEN_UNKNOWN, the

[Patch, fortran] PR82923 - Automatic allocation of deferred length character using function result

The ChangeLog and the comments in the patch tell all. Bootstrapped and regtested on FC27/x86_64. OK for 7-branch through to trunk? Paul 2018-05-17 Paul Thomas PR fortran/82923 * trans-array.c (gfc_alloc_allocatable_for_assignment): Set the charlen

[Patch, fortran] PR85742 sizeof allocatable arrays returning wrong value

I intend to apply this 'obvious' patch to trunk and 8-branch tonight, unless there are any objections. Bootstrapped and regetested on FC27/x86_64. Paul 2018-05-13 Paul Thomas PR fortran/85742 * trans-types.c (gfc_get_dtype_rank_type): Reorder evaluation of

[Patch, fortran] PR68846 - Pointer function as LValue doesn't work when the assignment regards a dummy argument.

Committed as obvious in revision 260113. I will commence backporting as soon as I can. Thanks to Mirco Valentini for the initial fix, which he posted on 2017-02-28. Cheers Paul 2018-05-10 Paul Thomas PR fortran/68846 PR fortran/70864 * resolve.c

Re: [Ping, Fortran, Patch, PR81773, PR83606, coarray, v1] Fix coarray get to array with vector indexing

Hi Andre, This is OK for trunk. Thanks for the patch Paul On 13 April 2018 at 08:34, Andre Vehreschild wrote: > Ping > > On Sun, 8 Apr 2018 14:25:50 +0200 > Andre Vehreschild wrote: > >> Hi all, >> >> attached patch fixes (to my knowledge) the two PRs 81773 and

[Patch, fortran] PR84931 - Expansion of array constructor with constant implied-do-object goes sideways

Thomas already committed a fix for the original problem (revisions 258641, 258666 & 258667). However, I found another testcase that still failed - that of multiple array constructors with iterators, within an array constructor without an iterator. The attached fixes this and streamlines the

[Patch, fortran] PR84546 - [7/8 Regression] Bad sourced allocation of CLASS(*) with source with CLASS(*) component

This regression came about because the vtable deep copy for derived types with unlimited polymorphic components was not making use of the _len parameter to compute the memory to be allocated and the offsets to array elements. The ChangeLogs are reasonably self explanatory. Bootstraps and

Re: Simplification and a zero sized array

Hi Steve, This looks to be OK to commit. Thanks Paul On 3 March 2018 at 02:01, Steve Kargl wrote: > All, > > I would like to commit the attach patch, which fixes > a number of ICE's when simplification runs into a > size zero array. gfortran does not have

[Patch, fortran] PR80965 - [7/8 Regression] ICE with class argument and -O2 optimization

Fixed as 'obvious' on 7-branch and trunk in r258213 and 258195 respectively. Paul 2018-03-03 Paul Thomas PR fortran/80965 * resolve.c (build_loc_call): Change symtree name from 'loc' to '_loc'. 2018-03-03 Paul Thomas PR fortran/80965 *

Re: [Patch, fortran] PR84219 - [8 Regression] ICE: Invalid expression in gfc_target_interpret_expr

Hi Christophe, I committed the wrong test :-( Corrected r258128. Many thanks Paul On 2 March 2018 at 08:38, Paul Richard Thomas <paul.richard.tho...@gmail.com> wrote: > Hi Christophe, > > I was not aware. Thanks for letting me know. > > It's wierd that there is no er

Re: [Patch, fortran] PR84219 - [8 Regression] ICE: Invalid expression in gfc_target_interpret_expr

By golly you are right! Je vous en remercie :-) Paul On 2 March 2018 at 08:41, Christophe Lyon <christophe.l...@linaro.org> wrote: > On 2 March 2018 at 09:38, Paul Richard Thomas > <paul.richard.tho...@gmail.com> wrote: >> Hi Christophe, >> >> I was n

Re: [Patch, fortran] PR84219 - [8 Regression] ICE: Invalid expression in gfc_target_interpret_expr

happens? Note that 7-branch behaves correctly. Cheers Paul On 2 March 2018 at 08:26, Christophe Lyon <christophe.l...@linaro.org> wrote: > On 1 March 2018 at 14:28, Paul Richard Thomas > <paul.richard.tho...@gmail.com> wrote: >> Committed as 'obvious' in revision 258098. >

[Patch, fortran] PR84219 - [8 Regression] ICE: Invalid expression in gfc_target_interpret_expr

Committed as 'obvious' in revision 258098. Paul 2018-03-01 Paul Thomas PR fortran/84219 * target-memory.c (gfc_interpret_derived): Assert that BT_VOID components are caf tokens. (gfc_target_interpret_expr): Treat BT_VOID expressions as integers. 2018-03-01 Paul Thomas

Re: [Patch, fortran] PR84538 - [8 Regression] Array of derived type elements incorrectly accessed in function

ebruary 2018 at 09:34, Paul Richard Thomas <paul.richard.tho...@gmail.com> wrote: > Hi All, > > The attached fixes this PR by dint of the change in class.c. The > changes to trans-array.c are largely cosmetic but the move of the call > to 'build_class_array_ref' ensures t

Re: [Patch, fortran] PR83901 - [8 Regression] ICE in fold_convert_loc, at fold-const.c:2402

Committed as revision 258076. Paul On 27 February 2018 at 19:35, Paul Richard Thomas <paul.richard.tho...@gmail.com> wrote: > Hi All, > > I will commit this patch as obvious tomorrow night unless there are > objections in the meantime. > > Bootstraps and regtests on FC

[Patch, fortran] PR83901 - [8 Regression] ICE in fold_convert_loc, at fold-const.c:2402

Hi All, I will commit this patch as obvious tomorrow night unless there are objections in the meantime. Bootstraps and regtests on FC27/x86_64 - OK? Paul 2018-02-27 Paul Thomas PR fortran/83901 * trans-stmt.c (trans_associate_var): Make sure that the se expression is a

[Patch, fortran] PR84538 - [8 Regression] Array of derived type elements incorrectly accessed in function

Hi All, The attached fixes this PR by dint of the change in class.c. The changes to trans-array.c are largely cosmetic but the move of the call to 'build_class_array_ref' ensures that all class array references go by this route. Boostrapped and regtested on FC27/x86_64 - OK to commit? Regards

[Patch, fortran] PR83149 [8 Regression] ICE on SELECT CASE: crash_signal in toplev.c:325

Hi All, The original bug is fixed as 'obvious' in revision 257938. This is indeed a regression. The bug in comments 2 and 7 is fixed in revision 257934. This, however, is not a regression. The summary will be changed accordingly. The 'obvious' tag comes about because both bugs have a common

[Patch, fortran] PR83148 [8 regression] ICE: crash_signal from toplev.c:325

Committed as 'obvious' in revision 257930. Cheers Paul 2018-02-23 Paul Thomas PR fortran/83148 * trans-const.c : Clean up some whitespace issues. * trans-expr.c (gfc_conv_initializer): If an iso_c_binding derived type has a kind value of zero, set it to

Re: [Patch, fortran] PR83344 - Use of uninitialized memory with ASSOCIATE and strings

Committed as revision 257827. > 1. The resolve.c part of the patch seems to have incorrect indentation? I can't see what you are referring to. I'll correct it if needs be > > 2. Instead of gfc_index_zero_node would it be better to use > build_zero_cst (gfc_charlen_type_node)? Or is the

Re: [Patch, fortran] PR83344 - Use of uninitialized memory with ASSOCIATE and strings

racter associate names, whose character length is a PARM_DECL. 2018-02-19 Paul Thomas <pa...@gcc.gnu.org> PR fortran/83344 * gfortran.dg/associate_22.f90: Enable commented out test. * gfortran.dg/associate_36.f90: New test. On 18 February 2018 at 21:01, Paul Richard Thomas <p

Re: [patch, fortran] Remove workaround introduced because of PR80945

Hi Thomas, I have tested this with the new version of the patch for PR83344 - it is OK for trunk. Thanks Paul On 18 February 2018 at 16:17, Thomas Koenig wrote: > Hello world, > > after Paul's fix for PR80945, the code in frontend-passes.c meant > to circumvent this

Re: [Patch, fortran] PR83344 - Use of uninitialized memory with ASSOCIATE and strings

Sun, Feb 18, 2018 at 5:48 PM, Paul Richard Thomas > <paul.richard.tho...@gmail.com> wrote: >> Bootstraps and regtests on FC27/x86_64 - OK for trunk? > > Hi, > > thanks for looking into this! > > 1. The patch itself is missing... > > 2. Could you unco

[Patch, fortran] PR83344 - Use of uninitialized memory with ASSOCIATE and strings

Bootstraps and regtests on FC27/x86_64 - OK for trunk? Paul 2018-02-18 Paul Thomas PR fortran/83344 * resolve.c (resolve_assoc_var): Character associate names that have no length expression that have variable targets and are not deferred length have assumed

[Patch, fortran] PR80945 - Invalid code with allocatable character array in READ/WRITE statement

Committed as 'obvious' - revision 257788. This patch works fine on 7-branch. I will commit it there in a day or two unless there is any objection. Cheers Paul 2018-02-18 Paul Thomas PR fortran/80945 * trans-array.c (gfc_conv_expr_descriptor): Set parmtype from

Re: [Patch, fortran] PR84115] [8 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'indirect_ref' in add_decl_as_local, at fortran/trans-decl.c:256

Thanks. Committed as revision 257781. Paul On 16 February 2018 at 15:21, Steve Kargl <s...@troutmask.apl.washington.edu> wrote: > On Fri, Feb 16, 2018 at 07:07:53AM +0000, Paul Richard Thomas wrote: >> > Oddly, the failing test in associate_35.f90 is the only one that works &

Re: [Patch, fortran] PR84115] [8 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'indirect_ref' in add_decl_as_local, at fortran/trans-decl.c:256

> Oddly, the failing test in associate_35.f90 is the only one that works > in 7-branch. I have left the PR open and changed the title > accordingly. The attached patch fixes this. OK for trunk? Paul 2018-02-16 Paul Thomas PR fortran/84115 * resolve.c

Re: [Patch, fortran] PR84074 Incorrect indexing of array when actual argument is an array expression and dummy is polymorphic

Committed as revision 257564 with the comment reworded. Thanks Paul On 11 February 2018 at 16:37, Steve Kargl <s...@troutmask.apl.washington.edu> wrote: > On Sun, Feb 11, 2018 at 03:08:52PM +0000, Paul Richard Thomas wrote: >> >> PR fortran/84074 >> * trans-expr.c

[Patch, fortran] PR84074 Incorrect indexing of array when actual argument is an array expression and dummy is polymorphic

Hi All, This patch makes sure that offsets and bounds are correct in passing derived types to class formal arrays. It is straightforward enough as not to require explanation. Bootstraps and regtests on FC25/x86_64 - OK for trunk? Paul 2018-02-11 Paul Thomas PR

Re: [Patch, fortran] PR 56691 - [OOP] Allocatable array: wrong offset when passing to CLASS dummy

PR fortran/56691 * gfortran.dg/type_to_class_4.f03: New test. On 27 January 2018 at 12:41, Paul Richard Thomas <paul.richard.tho...@gmail.com> wrote: > I am worried that this fix seems to easy by half and so I am posting > it for approval, rather than committing it as obvio

Re: [Patch, Fortran] PR 84273: Reject allocatable passed-object dummy argument (proc_ptr_47.f90)

Hi Janus, As Steve said, welcome back! I hope that you will post the news of this fix and the correction of the testcases on clf. Talking of which, have you posted the problems that others have found as PRs? It was one of my long deferred tasks to make a start on validating the testsuite and to

Re: [PATCH] PR fortran/82049 -- resolve a charlen if possible

Hi Steve, That's OK for trunk and, if you are possessed of the intestinal fortitude, 6- and 7-branches. Thanks Paul On 7 February 2018 at 02:17, Steve Kargl wrote: > The attached patch fixes PR fortran/82049. Prior to this > patch, gfortran was fouling up

[Patch, fortran] PR84115] [8 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'indirect_ref' in add_decl_as_local, at fortran/trans-decl.c:256

Committed a partial patch as 'obvious' in revision 257363. Oddly, the failing test in associate_35.f90 is the only one that works in 7-branch. I have left the PR open and changed the title accordingly. Paul 2018-02-04 Paul Thomas PR fortran/84115 * trans-decl.c

Re: [RFA PATCH] Bug 84094 - several correctness issues in gfortran.dg

Hi Dominique, The patch is OK. By all means open the PR for the missing/confusing diagnostics. Thanks Paul On 4 February 2018 at 13:01, Dominique d'Humières wrote: > Is the following patch OK? For associate_23.f90 I have restricted should_work > to two elements, an

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