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

On 07/15/2018 07:21 AM, Rainer Orth wrote: Hi Thomas, I am currently testing the patch at https://gcc.gnu.org/ml/fortran/2018-07/msg8.html so far, so good! IMO the tests should go to gfortran.dg (they pass my tests). I put the asycn_io_*.f90 tests into libgomp.fortran because, under

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

On 07/15/2018 04:19 AM, Thomas Koenig wrote: Hi everybody, I am currently testing the patch at https://gcc.gnu.org/ml/fortran/2018-07/msg8.html so far, so good! IMO the tests should go to gfortran.dg (they pass my tests). I put the asycn_io_*.f90 tests into libgomp.fortran because,

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

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: https://gcc.gnu.org/viewcvs?rev=262416=gcc=rev Log: 2018-07-04 Jerry DeLisle PR fortran/82009

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

On 06/27/2018 06:48 AM, Paul Richard Thomas wrote: 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

[patch, Fortran] Bug 85983 - ICE in check_dtio_interface1, at fortran/interface.c:4748

This patch is simple, eliminates an assert and allows further processing to give reasonable diagnostics. Regression tested. I don't think we really need a test case, but I can add one of the cases from the PR. OK for trunk? Regards, Jerry 2018-06-23 Jerry DeLisle PR fortran

[patch, libgfortran] PR86070 - [7 regression] gfortran.dg/fmt_zero_digits.f90 segmentation fault

I have not confirmed this fixes the segfault reported, but valgrind reports jump or move on uninitialized for the test case and this fixes that part. I will commit as obvious/simple on trunk and follow through on 7 and 8. Regression tested on x86_64. Regards, Jerry 2018-06-09 Jerry

Re: [Patch, Fortran] PR25829: Asynchronous I/O (v2)

On 06/05/2018 06:58 AM, Rainer Orth wrote: Hi Nicolas, Because they were originally intended for the gfortran test suite, but I couldn't run it there because of libpthread. I will change the numbering scheme. the way that libpthread dependency is currently handled seems weird to me: right

[patch, libgfortran] Bug 85840 - Memory leak in write.c

The attached patch is a follow on from my previous for this PR. I could not reproduce the problem on these code paths, but one should not assume it won't happen. Patch is obvious and I will commit shortly. Regression tested on x86_64. 2018-05-28 Jerry DeLisle PR libgfortran

Re: [PATCH,Fortran] Allow pointer initialization in DATA

On 05/24/2018 06:14 PM, Steve Kargl wrote: The attach patch allows for pointer initialization in a DATA statement per F2018. Yes, it's weird that a data-constant-object is not a named parameter. The 'data-constant-object' is required to have the SAVE and TARGET attribute. Built and regression

[patch, committed, libgfortran] PR85906 - Conditional jump depends on uninitialized value in write_integer

allocs for every write operation. 2018-05-26 Jerry DeLisle <jvdeli...@gcc.gnu.org> PR libgfortran/85906 * io/write.c (write_integer): Initialise the fnode format to FMT_NONE, used for list directed write. (BUF_STACK_SZ): Bump default buffer size up to

[patch, libgfortran, committed] Bug 85840 - Memory leak in write.c

The following committed as obvious after regression testing. 2018-05-26 Jerry DeLisle <jvdeli...@gcc.gnu.org> PR libgfortran/85840 * io/write.c (write_float_0): Use separate local variable for the float string length. Author: jvdelisle Date: Sat May 26 17:30:5

Re: [patch, rfc] Fortran async I/O support

On 05/21/2018 09:05 AM, Nicolas Koenig wrote: Hey everyone, Thomas and I have been working on adding asynchronous I/O to libgfortran. The patch is almost done, the only thing still missing is to link libgfortran against libpthread if it exists(which is for some reason necessary despite using

Re: [Patch, Fortran, pr85507, v1] Modell variable dependencies in coarray expression correctly.

On 04/30/2018 01:52 AM, Andre Vehreschild wrote: Hi all, attached patch partially reverts r259385 preventing an ICE. At the same time the check_dependency routine is parameterized correctly so that variable dependencies in coarray expressions are determined more precisely. Bootstrapped and

Re: [patch, fortran] Fix PR 85111, some more zero size stuff

On 03/29/2018 11:07 AM, Thomas Koenig wrote: Hello world, the attached patch fixes PR 85111, a regression introduced with my recent simplification patches.  Seems like the zero-size saga has yet another chapter :-) Regression-tested. OK for trunk? Looks OK, Thanks, Jerry Regards

Re: [patch,fortran] Bug 69497 - ICE in gfc_free_namespace

On 03/27/2018 01:53 PM, Mikael Morin wrote: Le 26/03/2018 à 03:53, Jerry DeLisle a écrit : On 03/25/2018 02:11 PM, Mikael Morin wrote: Le 25/03/2018 à 21:27, Jerry DeLisle a écrit : On 03/25/2018 10:49 AM, Mikael Morin wrote: Le 25/03/2018 à 00:25, Jerry DeLisle a écrit : On 03/24/2018 02

Re: [patch, fortran] Fix character parameter arrays as formats

On 03/25/2018 09:11 AM, Thomas Koenig wrote: Hello world, the attached pach fixes the PR by creating one single big string from a parameter array. OK for trunk? Nice, you put it right where I thought it should go in resolution. Yes, OK, Thanks Jerry

Re: [patch,fortran] Bug 69497 - ICE in gfc_free_namespace

On 03/24/2018 02:56 PM, Steve Kargl wrote: On Sat, Mar 24, 2018 at 02:25:36PM -0700, Jerry DeLisle wrote: 2018-03-24 Jerry DeLisle <jvdeli...@gcc.gnu.org> Dominique d'Humieres <domi...@gcc.gnu.org> PR fortran/84506 * symbol.c (gfc_free_namesp

[patch,fortran] Bug 69497 - ICE in gfc_free_namespace

for the testsuite with appropriate ChangeLog, etc. 2018-03-24 Jerry DeLisle <jvdeli...@gcc.gnu.org> Dominique d'Humieres <domi...@gcc.gnu.org> PR fortran/84506 * symbol.c (gfc_free_namespace): Delete the assert and if refs count is less than zero, free t

Re: [patch, fortran] Fix empty substrings when simplifying

On 03/24/2018 05:46 AM, Thomas Koenig wrote: Hell world, the attached patch is fairly self-explanatory, it fixes an out-of-memory condition. Regression-tested. OK for trunk? Yes, and thanks for fix. Jerry

Re: [PATCH] PR fortran/69395 -- don't exceed max allowed array dimensions

On 03/14/2018 06:23 PM, Steve Kargl wrote: The attachedi patch detects situations where the sum of an array's rank and corank exceeds the maximum allowed by the Standard. Regression tested on x86_64-*-freebsd. 2018-03-14 Steven G. Kargl PR fortran/69395 *

Re: [PATCH] PR fortran/83939 -- Enforce F2018 C15100

On 03/11/2018 01:48 PM, Steve Kargl wrote: The attach patch enforces F2018:C15100. Similar constraints are present in older versions of the standard. The patch and testcase are sufficiently explanatory. Regression tested on x86_64-*-freebsd. OK to commit? Looks OK Steve. Jerry

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

On 03/11/2018 12:23 PM, Paul Richard Thomas wrote: 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

Re: [patch, fortran] Fix PR 78238, ICE with SELECT TYPE with -fdefault-integer-8

On 02/24/2018 12:04 PM, Thomas Koenig wrote: Hello world, the attached patch fixes a 7/8 regression with SELECT TYPE where the constant had the wrong type with -fdefault-integer-8. Regression-tested. OK for trunk and gcc-7? Regards Thomas 2018-01-24  Thomas Koenig 

Fwd: Re: [PATCH] PR fortran/84511 -- Fix C_LOC in a transfer statement

Forwarded Message Subject: Re: [PATCH] PR fortran/84511 -- Fix C_LOC in a transfer statement Date: Fri, 23 Feb 2018 08:30:29 -0800 From: Jerry DeLisle <jvdeli...@charter.net> To: s...@troutmask.apl.washington.edu On 02/22/2018 12:01 PM, Steve Kargl wrote: All, The at

[patch, fortran] Bug 84506 - [6/7/8 Regression]INQUIRE(pos=) always sets pos=0 with -fdefault-integer-8

this adjustment. The attached patch is trivial. Regression tested on x86_86-pc-linux-gnu. I will back port to 6 an 7 after approval here. I will use the case in the PR as a new test case. OK for trunk? Regards, Jerry 2018-02-23 Jerry DeLisle <jvdeli...@gcc.gnu.org> PR fortran

[patch, committed] PR84389

Committed the following as obvious and simple to trunk with new test case. Author: jvdelisle Date: Sun Feb 18 19:19:47 2018 New Revision: 257795 URL: https://gcc.gnu.org/viewcvs?rev=257795=gcc=rev Log: 2018-02-18 Jerry DeLisle <jvdeli...@gcc.gnu.org> PR fortran/84389

Re: [Fortran, PATCH, coarray, v1] Extend caf_*_by_ref () API by a type specifier

On 02/18/2018 07:39 AM, Andre Vehreschild wrote: Hi all, attached patch fixes an issue with the coarray API. When a component of a derived type coarray was referenced using a caf_*_by_ref () function and that component was not an array with a descriptor, then the type of the component was not

[PATCH libgfortran] PR84412 [7/8 Regression] Erroneous "Inquire statement identifies an internal file" error

Hi all, The following patch is trivial and I plan to commit in the next day or so to trunk and gcc 7. Regression tested on x86_64-pc-gnu-linux. Regards, Jerry 2018-02-18 Jerry DeLisle <jvdeli...@gcc.gnu.org> PR libgfortran/84412 * io/transfer.c (finalize_transfer):

Re: *ping* [patch, fortran] Fix handling of assumed-size arrays in inline matmul

On 02/17/2018 06:22 AM, Thomas Koenig wrote: Am 12.02.2018 um 11:46 schrieb Thomas Koenig: Hello world, the attached patch fixes a regression where a rejects-valid would be issued. OK for the affected branches, trunk and gcc-7? PING ** (5.D0/7.D0) ? Yes, OK Jerry

Re: [Patch, fortran] PR37577 - [meta-bug] change internal array descriptor format for better syntax, C interop TR, rank 15

On 01/22/2018 12:24 PM, Thomas Koenig wrote: > Am 22.01.2018 um 20:59 schrieb Janne Blomqvist: >> On Mon, Jan 22, 2018 at 9:12 PM, Paul Richard Thomas >> wrote: >>> This patch has been triggered by Thomas's recent message to the list. >>> Not only did I start work

Re: [PATCH] PR fortran/83900 -- follow-up to set type

On 01/20/2018 12:19 PM, Steve Kargl wrote: > The attache patch is a follow-up to my patch for > PR fortran/83900, which removed a bogus assert. > This allowed gfc_simplify_matmul to do its job, > except it did not properly set the type of the > result. The attach fixes that issue. > >

Re: [patch, committed] PR83811 fortran 'e' format broken for single digit exponents

On 01/14/2018 09:42 AM, Jerry DeLisle wrote: > Hello all, > > I committed the following as trivial. > > Regression tested on x86_64-pc-linux-gnu. > > This is a regression on 7 so I will backport. > > Regards, > > Jerry > > 2018-01-18 Jerry DeLisle

[patch, committed] PR83811 fortran 'e' format broken for single digit exponents

Hello all, I committed the following as trivial. Regression tested on x86_64-pc-linux-gnu. This is a regression on 7 so I will backport. Regards, Jerry 2018-01-18 Jerry DeLisle <jvdeli...@gcc.gnu.org> PR libgfortran/83811 * write.c (select_buffer): Adjust buffer s

[patch, fortran] DTIO write format stored in a string leads to severe errors

-linux-gnu. The patch is simple. I will roll in a test case soon. Regards, Jerry 2018-01-13 Jerry DeLisle <jvdeli...@gcc.gnu.org> PR fortran/82007 * resolve.c (resolve_transfer): Delete code looking for 'DT' format specifiers in format strings. Set formatted t

Re: [PATCH] Implementation of RANDOM_INIT from F2018

On 01/08/2018 04:58 PM, Steve Kargl wrote: > On Sun, Jan 07, 2018 at 06:52:22PM -0800, Steve Kargl wrote: >> >> I have zero knowledge about co-arrays and especially zero >> knowledge about gfortran internals for co-arrays. I'm >> disinclined to waste another 12 hours trying to get gfortran >> to

Re: [PATCH] PR 78534 Change character length from int to size_t

On 01/03/2018 03:37 AM, Janne Blomqvist wrote: > On Sat, Dec 30, 2017 at 10:58 PM, Jerry DeLisle <jvdeli...@charter.net> wrote: >> On 12/30/2017 12:35 PM, Janne Blomqvist wrote: >>> On Sat, Dec 30, 2017 at 7:16 PM, Thomas Koenig <tkoe...@netcologne.de> >>

Re: [PATCH] PR 78534 Change character length from int to size_t

On 12/30/2017 12:35 PM, Janne Blomqvist wrote: > On Sat, Dec 30, 2017 at 7:16 PM, Thomas Koenig wrote: ---snip--- > > I can provide that stuff as a separate patch, or merge it into the > original megapatch and resubmit that, whichever way you prefer. I would prefer we

Re: [patch, committed] Bug 83613 - [8 Regression] Executing gfortran.dg/inquire_internal.f90 hangs on darwin

On 12/29/2017 02:40 PM, Jerry DeLisle wrote: > Committed as obvious after regression testing on x86_64-pc-linux-gnu. > > Dominiq: Please confirm is fixed. > > Regards, > > Jerry > The actual patch, Dominiq confirmed the issue was fixed: diff --git a/libgfortran/io

[patch, committed] Bug 83613 - [8 Regression] Executing gfortran.dg/inquire_internal.f90 hangs on darwin

Committed as obvious after regression testing on x85_64-pc-linux-gnu. Dominiq: Please confirm is fixed. Regards, Jerry Author: jvdelisle Date: Fri Dec 29 22:36:25 2017 New Revision: 256035 URL: https://gcc.gnu.org/viewcvs?rev=256035=gcc=rev Log: 2017-12-29 Jerry DeLisle <jvd

Re: [patch, lingfortran] Bug 83560 - list-directed formatting of INTEGER is missing plus on output

On 12/25/2017 12:06 PM, Jerry DeLisle wrote: > On 12/25/2017 05:10 AM, Dominique d'Humières wrote: >> Dear Jerry, >> >> The lines >> >> +a=12.3456 >> >> and >> >> +open(unit=10,sign='plus') >> >> in gfortran.dg/integer_plus.

Re: [patch, lingfortran] Bug 83560 - list-directed formatting of INTEGER is missing plus on output

On 12/25/2017 05:10 AM, Dominique d'Humières wrote: > Dear Jerry, > > The lines > > +a=12.3456 > > and > > +open(unit=10,sign='plus') > > in gfortran.dg/integer_plus.f90 could probably be removed. > Yes, left over from some other testing I was doing > From comment 2 in the PR (and the

Re: [patch, lingfortran] Bug 83560 - list-directed formatting of INTEGER is missing plus on output

Correction, I used write_decimal for everything except namelist writes. On 12/24/2017 08:02 PM, Jerry DeLisle wrote: > Attached patch changes the use of write_integer for the test case which uses > the > sign='plus' specifier when opening a file and using list directed output. To >

[patch, lingfortran] Bug 83560 - list-directed formatting of INTEGER is missing plus on output

in a new function namelist_write_integer. Regression tested on x86_64-pc-linux. OK for trunk? Regards, Jerry 2017-12-25 Jerry DeLisle <jvdeli...@gcc.gnu.org> PR libgfortran/83560 * io/write.c (write_integer): Modify to use write_decimal. Change paramter from len t

Re: [PATCH] Support -std=f2018

On 12/17/2017 02:02 AM, Janne Blomqvist wrote: > The Fortran committee has decided to rename the upcoming Fortran 2015 > standard to Fortran 2018. This is not a reflection of a three year > delay in the process, but rather they are following other standards in > adopting the year of publication

[patch, libgfortran] Bug 81937 - stack-buffer-overflow on memcpy

sread is basically a wrapper on memcpy The patch is fairly straight forward. Regression tested on x86_64-pc-linux-gnu. OK for trunk and back ports as I find? Regards, Jerry 2017-12-16 Jerry DeLisle <jvdeli...@gcc.gnu.org> PR libgfortran/81937 * io/list_

Re: [patch, libgfortran] Memory issues related to PR78549

Ping: If no objection, I will commit to trunk on Wednesday evening. On 12/10/2017 07:55 PM, Jerry DeLisle wrote: > Hi all, > > While doing addition testing for the subject mentioned PR I discovered > numerous > un-freed memory allocations. I reported the problem in comme

[patch, libgfortran] Memory issues related to PR78549

closure similar to pre-connected units. The internal stream structures are created and freed at the beginning and end of each I/O operation. I fix a few loose ends. Regression tested on x86_64. OK for trunk? Also needed for same issue in 7. Regards, Jerry 2017-12-11 Jerry DeLisle <jvd

Re: [patch, fortran] Implement Maxval in compile-time-constants

On 12/10/2017 12:31 PM, Thomas Koenig wrote: > Hello world, > > the attached patch allows for maxval in parameter statements > with DIM and MASK arguments. > > It does so by removing a function which does only a partial > job and using the machinery which is already in use for the > other

Re: Ping**(5./7.) [patch, fortran] Implement maxval for characters

On 12/03/2017 01:48 AM, Thomas Koenig wrote: > Am 28.11.2017 um 19:40 schrieb Thomas Koenig: >> Hello world, >> >> the attached patch implements maxval for characters, an F2003 feature >> that we were missing up to now. >> >> Regression-tested on x86_64-pc-linux-gnu. >> >> OK for trunk? > > Ping?

[patch, libgfortran] Bug 83191 - [7/8 Regression] Writing a namelist with repeated complex numbers

Hi all, I plan to commit the attached patch with a test case shortly. It is relatively simple. Thanks to Dominique for pinpointing the location right away. Regression tested on x86_64-pc-linux-gnu. Regards, Jerry 2017-12-03 Jerry DeLisle <jvdeli...@gcc.gnu.org> Dom

[patch, committed] PR83225 - [8.0 regression] runtime error in transfer.c

-02 Jerry DeLisle <jvdeli...@gcc.gnu.org> PR libgfortran/83225 * io/io.h (is_internal_unit): Use the unit_is_internal bit. * io/transfer.c (data_transfer_init): Set the bit to true for internal umits. Use that bit for checks for interna

Re: [PATCH] Use __BYTE_ORDER__ predefined macro instead of runtime check

On 11/22/2017 04:34 AM, Janne Blomqvist wrote: > By using the __BYTE_ORDER__ predefined macro we don't need the > determine_endianness function anymore. > > Regtested on x86_64-pc-linux-gnu, Ok for trunk? > Looks good, thanks for patch! Jerry

[patch, libgfortran] Bug 78549 - [7/8 Regression] Very slow formatted internal file output

pr78549.f $ time ./a.out real0m29.915s user0m28.750s sys 0m0.971s Regression tested on x86-64-linux. I will commit to trunk in a day and back port to 7 in a few more days if no objections. The patch is simple. Regards, Jerry 2017-11-19 Jerry DeLisle <jvdeli...@gcc.gnu.

Re: [PATCH] PR 44292 Handle large record lengths

On 11/18/2017 11:55 AM, Janne Blomqvist wrote: > Now that the ABI supports large record lengths, there's a few places > in libgfortran where we need to use larger types. For internal units > which by definition are in-memory, it's enought to use ptrdiff_t, for > external units gfc_offset. > >

Re: [PATCH] Make NEXTREC specifier for INQUIRE work for large record numbers

On 11/18/2017 08:59 AM, Janne Blomqvist wrote: > On Sat, Nov 18, 2017 at 6:00 PM, Thomas Koenig wrote: >> Hi Janne, >> >>> This is accomplished by making the NEXTREC specifier be a 8 byte >>> integer where supported. >>> >>> I wasn't able to come up with a testcase that

Re: [Patch, fortran] PR81758 - [7/8 Regression] [OOP] Broken vtab

On 10/26/2017 12:20 PM, Andre Vehreschild wrote: > Hi Paul, > > Without having tested the patch, it looks reasonable to me. So ok from my > side. > > - Andre > Seconded, thanks. Jerry

Re: [Patch] Edit contrib/ files to download gfortran prerequisites

On 10/21/2017 11:17 AM, Bernhard Reutner-Fischer wrote: > On 21 October 2017 at 02:26, Damian Rouson > wrote: >> >> Hi Richard, >> >> Attached is a revised patch that makes the downloading of Fortran >> prerequisites optional via a new --no-fortran flag that can be

Re: [Patch, fortran] PR82586 - [PDT] ICE: write_symbol(): bad module symbol

On 10/20/2017 12:17 PM, Steve Kargl wrote: > On Fri, Oct 20, 2017 at 07:55:17PM +0100, Paul Richard Thomas wrote: >> >> In the last hour, I have added fixes for PRs 82587 and 82589. Please >> review them together with 82586. >> >> I will stop work on Gerhard's PDT bugs until this patch is

Re: [Patch, fortran] PR82586 - [PDT] ICE: write_symbol(): bad module symbol

On 10/20/2017 11:55 AM, Paul Richard Thomas wrote: > Dear All, > > In the last hour, I have added fixes for PRs 82587 and 82589. Please > review them together with 82586. > > I will stop work on Gerhard's PDT bugs until this patch is committed. > Fortunately, Steve Kargl has proposed fixes for

Re: [patch, fortran] Fix PR 82567

On 10/17/2017 03:36 PM, Thomas Koenig wrote: > Hello world, > > this patch fixes a regression with long compile times, > which came about due to our handling of array constructors > at compile time.  This, togeteher with a simplification in > front end optimization, led to long compile times and

Re: [patch, fortran] Fix PR 79795

On 10/15/2017 11:09 AM, Thomas Koenig wrote: > Hello world, > > the attached patch fixes a regression by turning an ICE-on-invalid into > an error message (and making sure that it fits). > > Regression-tested on trunk. > > OK for all affected branches (8/7/6)? > Yes, OK, thanks. Jerry

Re: [Patch, fortran] PR82550 - program using submodules fails to link

On 10/17/2017 11:33 AM, Paul Richard Thomas wrote: > The attached patch has a comment that explains what is going on. > > Bootstrapped and regtested on FC23/x86_64 - OK for trunk and 7-branch? > Yes, looks OK for both. Thanks. Jerry

Re: [PATCH] Fortran -- Handle BOZ in accordance with F2008/2015.

On 10/06/2017 01:34 PM, Steve Kargl wrote: > All, > > I have spent the last few days trying to reconcile the various Fortran > standards' requirements for handling BOZ. The short story is that J3 > over the last 27 years has made incompatible changes to the interpretation > of a BOZ (under some

Re: [patch, fortran] Set implicit ASYNCHRONOUS attribute

On 10/04/2017 02:41 PM, Thomas Koenig wrote: > Hello world, > > the attached patch sets the implicit ASYNCHRONPUS according to F2008, > 9.6.2.5: > > # If a variable is used in an asynchronous data transfer statement as > # • an item in an input/output list, > # • a group object in a namelist, or

Re: [patch, fortran] Error for non-contiguous pointers

On 10/03/2017 11:35 AM, Thomas Koenig wrote: > Hello world, > > I have re-thought and simplified the patch for PR49232. > This now uses gfc_is_simply_contiguous, in the > non-strict version.  I have also opted for an error > because, well, the use cases rejected by this are really > errors, and

Re: [patch, fortran] Warn about out-of-bounds access with DO subscripts

On 09/23/2017 05:33 AM, Thomas Koenig wrote: > Hello world, > > here is an update and a ping for my patch at > > https://gcc.gnu.org/ml/gcc-patches/2017-09/msg01104.html > > This patch warns unconditionally for > >   REAL A(3) >   DO I=1,4 > A(I) = 42. >   END DO > > while only warning

Re: [Patch] Edit contrib/ files to download gfortran prerequisites

On Thu, 21 Sep 2017 09:40:49Richard Biener wrote: > On Wed, Sep 20, 2017 at 10:35 PM, Damian Rouson > wrote: > >> Attached is a patch that adds the downloading of gfortran prerequisites > OpenCoarrays and MPICH in the contrib/download_prerequisites script. The >

Re: [Patch, fortran] Bug fixes, including regressions, for the associate construct

On 09/20/2017 09:45 AM, Paul Richard Thomas wrote: > In the last update to the Parameterized Derived Types implementation, > I fixed PR60483 as a side effect. I then checked all the ASSOCIATE > bugs and noted that I was responsible for a number of regressions due > to a patch that I applied last

Re: [patch, libgfortran] PR78387 OpenMP segfault/stack size exceeded writing to internal file

ping - I will commit if I hear no objections. Jerry On 08/19/2017 10:12 PM, Jerry DeLisle wrote: > Hi all, > > I have decided to simply delete the internal unit stack altogether. > > The original intent was to save time with internal unit I/O by avoiding > reallocating a

Re: [patch, fortran] Fix regression with inline matmul

On 08/26/2017 11:24 AM, Thomas Koenig wrote: > Hello world, > > to relieve the boredom on the fortran mailing list and to fix > a regression I thought I'd submit a patch :-) > > Apparently, a call to CONJG wasn't picking up the right > typespec, which led to an ICE with gimplification later. >

[patch, fortran] Bug 81296 - derived type I/o problem

? Regards, Jerry 2017-08-21 Jerry DeLisle <jvdeli...@gcc.gnu.org> PR fortran/81296 * trans-io.c (get_dtio_proc): Add check for format label and set formatted flag accordingly. Reorganize the code a little. diff --git a/gcc/fortran/trans-io.c b/gcc/fortran/trans-io.

[patch, libgfortran] PR78387 OpenMP segfault/stack size exceeded writing to internal file

no significant change in performance. Regression tested on x86_64-linux. No new test case. OK for trunk and then I think this should be backported to 7. Regards, Jerry 2017-08-20 Jerry DeLisle <jvdeli...@gcc.gnu.org> PR libgfortran/78387 * io/list_read.c (nml_read_obj): Remo

Re: *ping* [patch, fortran] Fix PR 81116, missing dependency handling for allocatable character

On 08/13/2017 10:35 AM, Thomas Koenig wrote: the attached patch fixes the PR by adding a dependency check for the case of concatenation operators. Regression-tested. OK for trunk? Ping? Regards Thomas OK, Thanks for patch. Jerry

Re: [patch, gcc doc + fortran] Make -Ofast honor -fmax-stack-var-size

Looks OK, thanks. Jerry On 08/04/2017 12:32 PM, Thomas Koenig wrote: > Am 04.08.2017 um 14:09 schrieb Thomas Koenig: >> Hello world, >> >> the attached patch > > This time, really attached, even with ChangeLog! > > Regards > > Thomas > > 2017-08-04 Thomas Koenig >

Re: [ patch, libfortran] Fix PR 81581

On 07/30/2017 11:55 AM, Thomas Koenig wrote: > Hello world, > > the attached patch performs a runtime-check for the dim arguments > for transformational intrinsic functions. > > I debated with myself a bit if I should make this depend on > bounds checking, but I finally decided against it. The

Re: [patch, fortran] Fix another dependency check for reallocation on assignment

On 07/23/2017 04:27 AM, Thomas Koenig wrote: > Hello world, > > in PR 66102, I found a patch by Mikael which has never been applied. > After dusting it off, finding that it looks reasonable and fixes > the test case in question I'd like to apply this. > > Regression-tested. OK for trunk? > OK,

Re: [Patch, fortran] PR34640 - ICE when assigning item of a derived-component to a pointer

On 07/11/2017 07:23 AM, Paul Richard Thomas wrote: > Well, a bit earlier than anticipated, here is the final version that > puts right all the wrinkles that I know about. > > Bootstraps and regtests - OK for trunk? > > Paul Somewhere in the threads on this, there was mentioned ABI

[patch, fortran] PR80164 ICE in gfc_format_decoder at gcc/fortran/error.c:933

-27 Jerry DeLisle <jvdeli...@gcc.gnu.org> PR fortran/80164 * trans-stmt.c (gfc_trans_call): If no code expr, use code->loc as warning/error locus. diff --git a/gcc/fortran/trans-stmt.c b/gcc/fortran/trans-stmt.c index e4f1da54..a1e1dff7 100644 --- a/gcc/fort

Re: [PATCH, libgfortran] proposed fix for SPEC CPU2017 621.wrf_s failures

On 06/25/2017 05:50 PM, Jim Wilson wrote: > As mentioned in bug 81195, I see openmp related failures due to a lack > of locking of the newunit_stack and newunit_tos variables. The code > locks when pushing onto the stack, but does not lock when popping from > the stack. This can cause multiple

[patch, committed] Bug 81160 - arith.c:2009: bad statement order ?

Committed as obvious: Committing to svn+ssh://jvdeli...@gcc.gnu.org/svn/gcc/trunk ... M gcc/fortran/ChangeLog M gcc/fortran/arith.c Committed r249627 After regression testing. Jerry --- trunk/gcc/fortran/arith.c 2017/06/24 19:31:24 249626 +++

Re: [patch, libfortran] Speed up cshift for dim > 1

On 06/14/2017 12:41 PM, Thomas Koenig wrote: > Hello world, > > the attached patch implements a blocked algorithm for > improving the speed of cshift for dim > 1. > > It uses the fact that > > integer, dimension (n1,n2,n3) :: a, b > > b = cshift(a,shift,3) > > is identical, as far as the

Re: [patch, fortran] Fix PR 80988

On 06/09/2017 01:47 PM, Thomas Koenig wrote: Hello world, the attached patch fixes the PR by not doing a replacement of (a(i,i),i=1,3) by an array expression (which does not exist). Regression-tested. OK for trunk? OK, thanks Regards Thomas 2017-06-09 Thomas Koenig

Re: [patch, libfortran] Fix matmul result zeroing for empty arguments

On 06/05/2017 02:52 AM, Thomas Koenig wrote: > Hello world, > > the attached patch moves the zeroing of the result variable before the > early return. This is done so that the result for zero-sized arguments > is still valid. > > The bug was only in the library version, but I have also added a

Re: [Patch, fortran] PR35339 Optimize implied do loops in io statements

On 06/03/2017 06:48 AM, Nicolas Koenig wrote: > Hello everyone, > > here is a version of the patch that includes a workaround for PR 80960. I have > also included a separate test case for the failure that Dominique detected. > The > style issues should be fixed. > > Regression-tested. OK for

Re: [patch, libgfortran] PR53029 missed optimization in internal read (without implied-do-loop)

On 05/29/2017 09:51 AM, Thomas Koenig wrote: Hi Jerry, Regression tested on x86_64. I have added a test case which will check the execution time of the loop. The previous results of the REAd were correct, just took a long time on large arrays. OK for trunk? OK. It might be good if you

[patch, libgfortran] PR53029 missed optimization in internal read (without implied-do-loop)

led. Regression tested on x86_64. I have added a test case which will check the execution time of the loop. The previous results of the REAd were correct, just took a long time on large arrays. OK for trunk? Regards, Jerry 2017-05-28 Jerry DeLisle <jvdeli...@gcc.gnu.org>

Re: [patch, fortran] Create some temporary variables for matmul arguments

On 05/28/2017 02:40 PM, Thomas Koenig wrote: Hello world, the attached patch generates some more opportunities for matmul inlining by creating temporaries if arguments overlap, if the return is from a function or something similar. With this, we are pretty much coming to the end of the matmul

Re: [Patch, fortran] PR35339 Optimize implied do loops in io statements

On 05/27/2017 12:49 PM, Nicolas Koenig wrote: Hello everyone, attached is a patch to simplify implied do loops in io statements by replacing them with their respective array slices. For example "WRITE (*,*) (a(i), i=1,4,2)" becomes "WRITE (*,*) a(1:4:2)". Ok for trunk? Thanks for patch.

Re: [patch, libfortran] AMD-specific versions of library matmul

On 05/25/2017 02:57 PM, Thomas Koenig wrote: Hi everybody, I have committed the patch (with the corrections for the name) as rev 248472. The infrastructure is in place, so we will be able to make any fine-tuning easily. Regards Thomas Based on my testing I think it is close enough as

Re: [patch, libfortran] AMD-specific versions of library matmul

On 05/25/2017 10:20 AM, Janne Blomqvist wrote: On Thu, May 25, 2017 at 1:45 PM, Thomas Koenig wrote: Hello world, the attached patch speeds up the library version of matmul for AMD chips by selecting AVX128 instructions and, depending on which instructions are

Re: [patch, libfortran] AMD-specific versions of library matmul

On 05/25/2017 03:45 AM, Thomas Koenig wrote: Hello world, the attached patch speeds up the library version of matmul for AMD chips by selecting AVX128 instructions and, depending on which instructions are supported, either FMA3 (aka FMA) or FMA4. Jerry tested this on his AMD systems, and found

Re: [patch, fortran] Handle MATMUL(TRANSPOSE(A),B) in inline matmul

On 05/17/2017 02:41 PM, Thomas Koenig wrote: > Hello world, > > after receiving no negative feedback on my RFC patch, I have deciced > to submit the patch. > > The attached patch handles MATMUL(TRANSPOSE(A),B) in inlining matmul. > Speed is a bit faster than the library version. > >

Re: [Patch, Fortran, OOP] PR 80766: [7/8 Regression] ICE with type-bound procedure returning an array

On 05/21/2017 09:14 AM, Janus Weil wrote: Hi all, the attached patch fixes an ICE-on-valid regression by making sure that the relevant vtype symbol is resolved properly (for further discussion see the PR). The patch regtests cleanly on x86_64-linux-gnu. Ok for trunk and 7-branch? Cheers,

Re: [patch, fortran] PR80333 Namelist dtio write of array of class does not traverse the array

On 05/18/2017 07:06 PM, Steve Kargl wrote: On Thu, May 18, 2017 at 05:16:45PM -0700, Jerry DeLisle wrote: 2017-05-18 Paul Thomas <pa...@gcc.gnu.org> PR fortran/80333 * trans-io.c (nml_get_addr_expr): If we are dealing with class type data set tmp tree

[patch, fortran] PR80333 Namelist dtio write of array of class does not traverse the array

et tmp tree to get that address. (transfer_namelist_element): Set the array spec to point to the the class data. 2017-05-18 Paul Thomas <pa...@gcc.gnu.org> Jerry DeLisle <jvdeli...@gcc.gnu.org> PR fortran/80333 * list_read.c (nml_read_obj

[patch, fortran] PR80741 [Regression 7/8] DTIO wrong code causes incorrect behaviour of namelist READ

for trunk and then back port to 7 in about a week? Regards, Jerry 2017-05-16 Jerry DeLisle <jvdeli...@gcc.gnu.org> PR fortran/80741 * trans-io.c (transfer_namelist_element): Change check from NULL_TREE to null_pointer_node. 2017-05-16 Jerry DeLisle &

Re: [patch, libgfortran] [7/8 Regression] Crash of runtime gfortran library during integer transformation

On 05/15/2017 03:51 PM, Steve Kargl wrote: > On Mon, May 15, 2017 at 01:10:43PM -0700, Jerry DeLisle wrote: >> >> 2017-05-15 Jerry DeLisle <jvdeli...@gcc.gnu.org> >> >> PR libgfortran/80727 >> * transfer.c (read_sf_internal): Remove bogus code

Re: [Patch, fortran] PR80554 [f08] variable redefinition in submodule

On 05/15/2017 04:10 AM, Paul Richard Thomas wrote: The attached bootstraps and regtests on FC23/x86_64 - OK for trunk and later for 7-branch? The comment in the patch and the ChangeLog are sufficiently clear that no further explanation is needed here. Looks OK Paul, thanks, Jerry

[patch, libgfortran] [7/8 Regression] Crash of runtime gfortran library during integer transformation

) Regards, Jerry 2017-05-15 Jerry DeLisle <jvdeli...@gcc.gnu.org> PR libgfortran/80727 * transfer.c (read_sf_internal): Remove bogus code to detect EOR. (read_block_form): For internal units, generate EOR if no more bytes left in unit and we are trying t

Re: [Patch, fortran] PR80442 Handle DATA statement with iteration var in array slice

On 05/13/2017 04:56 AM, Nicolas Koenig wrote: > Ping > Also, attached is a better test case. > > > On 05/09/2017 10:49 PM, Nicolas Koenig wrote: >> Hello everyone, >> >> since everybody seems to be submitting patches the last few days, I thought I >> might as well :) >> Attached is a patch that

<    1   2   3   4   5   6   >