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 fo
unction in a new function
namelist_write_integer.
Regression tested on x86_64-pc-linux.
OK for trunk?
Regards,
Jerry
2017-12-25 Jerry DeLisle
PR libgfortran/83560
* io/write.c (write_integer): Modify to use write_decimal.
Change paramter from len to kind to be better
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 outpu
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 attach
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.d
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&root=gcc&view=rev
Log:
2017-12-29 Jerry
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
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 split into two patches. Thi
On 01/03/2018 03:37 AM, Janne Blomqvist wrote:
> On Sat, Dec 30, 2017 at 10:58 PM, Jerry DeLisle wrote:
>> 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
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 e
The following committed as obvious after regression testing.
2018-05-26 Jerry DeLisle
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:52 2018
New Revision: 260793
allocs for every write operation.
2018-05-26 Jerry DeLisle
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 avoid allocs on
small
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
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 libgfo
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 now
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
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 fo
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
-linux-gnu.
The patch is simple. I will roll in a test case soon.
Regards,
Jerry
2018-01-13 Jerry DeLisle
PR fortran/82007
* resolve.c (resolve_transfer): Delete code looking for 'DT'
format specifiers in format strings. Set formatted to true if a
format
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
PR libgfortran/83811
* write.c (select_buffer): Adjust buffer size up by 1.
diff --git a
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 De
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.
>
> Regression
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 late relative to stage 3 but debu
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
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
PR libgfortran/84412
* io/transfer.c (finalize_transfer): After completing
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 kn
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&root=gcc&view=rev
Log:
2018-02-18 Jerry DeLisle
PR fortran/84389
* io.c (chec
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
PR fortran/84506
* trans-io.c
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
To: s...@troutmask.apl.washington.edu
On 02/22/2018 12:01 PM, Steve Kargl wrote:
All,
The attached patch handles C_LOC in
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
PR fortran
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
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
2018-03-
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
* decl.c (merge_array
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
testsuite with
appropriate ChangeLog, etc.
2018-03-24 Jerry DeLisle
Dominique d'Humieres
PR fortran/84506
* symbol.c (gfc_free_namespace): Delete the assert and if refs
count is less than zero, free the namespece. Something is
halfway and other e
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
Dominique d'Humieres
PR fortran/84506
* symbol.c (gfc_free_namespace): Delete the assert and if refs
count is less
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
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
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
Tho
My apologies for kidnapping this thread:
On 9/20/18 1:01 PM, Thomas Koenig wrote:
Hi Damian,
On a related note, two Sourcery Institute developers have attempted to
edit
the GCC build system to make the downloading and building of OpenCoarrays
automatically part of the gfortran build process.
Janne, this looks OK. Since you are touching on configuration and posix
dependencies have you tested under any other systems?
Jerry
On 9/21/18 1:41 AM, Janne Blomqvist wrote:
PING
On Wed, Sep 12, 2018 at 10:17 PM Janne Blomqvist
wrote:
When producing error and warning messages, libgfortran
On 9/21/18 1:16 PM, Damian Rouson wrote:> On Fri, Sep 21, 2018 at 9:25
AM Jerry DeLisle wrote:
>
>> The actual library source code is contained mostly in one source file.
>
> There are as many files as there are options for the underlying
> parallel programming
> model.
Committed as OKed by Janus on bugzilla.
Author: jvdelisle
Date: Sat Sep 22 17:49:19 2018
New Revision: 264505
URL: https://gcc.gnu.org/viewcvs?rev=264505&root=gcc&view=rev
Log:
2018-09-22 Jerry DeLisle
PR fortran/87318
* gfortran.dg/dtio_1.f90: Update test to va
Minor typo, see below.
On 9/22/18 10:23 AM, Thomas Koenig wrote:
Hello world,
the attached patch lets the middle-end know that variables
associated with intent(out) arguments become undefined, by
issuing an assignment to a special value (a "clobber")
before entering the procedure.
Originally,
On 10/6/18 10:00 AM, Janne Blomqvist wrote:
On Mon, Sep 24, 2018 at 10:18 PM Janne Blomqvist
wrote:
On Mon, Sep 24, 2018 at 7:48 PM Thomas Koenig
wrote:
Hi Janne,
libgfortran has a recursion check in the error handling paths. This
works by checking the value of a static variable, and if
On 10/6/18 10:53 AM, Thomas Koenig wrote:
Hello world,
the attached patch fixes an ICE regression by issuing an error
when a clever combination of array constructors ends up
in gfc_arith_concat with mismatched types, before resultion
has a chance to report the error.
Regression-tested. OK for t
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 regt
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
Hi,
The attached patch adds a compile time check for negative unit numbers given in
an INQUIRE statement. A new test case is provided and one updated.
Regression tested on x86-64.
OK for trunk?
2014-09-06 Jerry DeLisle
PR fortran/61933
* io.c (gfc_match_inquire): Add error
On 06/09/14 21:08, Janne Blomqvist wrote:
> On Sun, Sep 7, 2014 at 12:51 AM, Jerry DeLisle wrote:
>> Hi,
>>
>> The attached patch adds a compile time check for negative unit numbers given
>> in
>> an INQUIRE statement. A new test case is provided and one upda
) = 5
+++ exited with 0 +++
I can not think of a test case for this.
Regression tested on x86-64 Linux.
OK for trunk?
Regards,
Jerry
2013-11-15 Jerry DeLisle
PR fortran/59108
* io/unix.c (regular_file): If the ACTION is read only set
creat
On 11/15/2013 01:05 PM, Janne Blomqvist wrote:
> On Fri, Nov 15, 2013 at 9:11 PM, Jerry DeLisle wrote:
>> The attached patch sets the create flag for the case where action is
>> specified
>> as read only.
>
> I was looking at this yesterday, but didn't have time
Committed as obvious. Missed it on my earlier patch.
2014-10-05 Jerry DeLisle
PR libgfortran/63460
* io/unit.c (init_units): Initialize the DELIM flag to
UNSPECIFIED for the STDIN unit so that the flag is
correctly set later.
r215908
Index: unit.c
On 06/06/2014 07:47 PM, Janne Blomqvist wrote:
> PING
>
> On Tue, May 27, 2014 at 11:50 PM, Janne Blomqvist
> wrote:
>> Hi,
>>
>> the attached patch implements the idea in
>> https://gcc.gnu.org/ml/fortran/2013-04/msg00258.html ; though it
>> turned out it was much simpler than what I envisaged b
trunk and 4.9?
Regards,
Jerry
2014-06-25 Jerry DeLisle
PR libgfortran/61499
* io/list_read.c (eat_spaces): Use a 'for' loop instead of
'while' loop to skip the loop if there are no bytes left in the
string. Only seek if actual spaces can b
On 26/06/14 04:29, Paul Richard Thomas wrote:
> Hi Jerry,
>
> The patch looks to be OK for trunk.
>
> Did you check it with the NIST by any chance?
>
Yes, tested fine.
Jerry
Jerry
2014-06-28 Jerry DeLisle
PR libgfortran/61640
* io/list_read.c (next_char_internal): Adjust the read length to
a single wide character. (eat_spaces): Add missing paren.
* io/unix.c (mem_read4): Use the correct mem_alloc function for
wide char
ry for the
testsuite changes.
Regression tested on x86-64-linux. OK to trunk? followed to 5.1?
Regards,
Jerry
2015-05-14 Jerry DeLisle
PR fortran/65903
* io.c (format_lex): Change to NONSTRING when checking for
possible doubled quote.
* scanner.c (gfc_next_ch
* ping *
On 05/13/2015 06:58 PM, Jerry DeLisle wrote:
> 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
On 05/16/2015 08:17 AM, Mikael Morin wrote:
snip
>>
>> Index: gcc/testsuite/gfortran.dg/continuation_13.f90
>> ===
>> --- gcc/testsuite/gfortran.dg/continuation_13.f90(revision 223105)
>> +++ gcc/testsuite/gfortran.dg/con
On 05/16/2015 08:11 AM, Steve Kargl wrote:
> On Sat, May 16, 2015 at 07:52:38AM -0700, Jerry DeLisle wrote:
>> * ping *
>>
>>> 2015-05-14 Jerry DeLisle
>>>
>>> PR fortran/65903
>>> * io.c (format_lex): Change to NONSTRI
On 05/16/2015 10:45 AM, Jerry DeLisle wrote:
--- snip ---
> Thanks Steve,
>
> Committed revision 223248.
>
>
I had some time to play with this a little more this afternoon.
I am going to commit the following little patchlet that gives us the nice
warning we should ha
On 05/16/2015 12:58 PM, Jerry DeLisle wrote:
> On 05/16/2015 10:45 AM, Jerry DeLisle wrote:
> --- snip ---
>
>> Thanks Steve,
>>
>> Committed revision 223248.
>>
>>
>
> I had some time to play with this a little more this afternoon.
>
> I am
On 06/05/2015 04:55 PM, Steve Kargl wrote:
> The attached patch checks that TYPE IS and CLASS IS
> return a type spec or a derived type spec. Regression
> tested without any new failures. OK to commit?
>
OK, thanks,
Jerry
t area.
Regression tested on x86-64. I will dejanuize the test case attached.
OK for trunk?
Jerry
2015-04-17 Jerry DeLisle
PR libgfortran/56743
* io/list_read.c (CASE_SEPARATORS): Add case for '!'.
(is_separator): Add condition
I have had this simple patch in my trunk for quite some time and it has tested
OK.
I plan to commit with a test case based on the one in the PR today.
Regards,
Jerry
2015-04-21 Jerry DeLisle
PR libgfortran/65234
* io/format.c (parse_format_list): Set the seen_dd flag in
On 03/06/2015 04:23 PM, Janne Blomqvist wrote:
The patch as is causes gfortran.dg/open_errors.f90 to fail, due to
changed error messages. I'm a bit unsure of to fix this, as now
strerror* is used to generate part of the message, and thus the
message can be different on different targets, and eve
timeit.f08 program
to show the overhead is very very low. (also attached)
Regression tested on x86-64 and PowerPC. I am not set up to test on
Cygwin/Windows platforms. If someone can do this, please do.
OK for trunk?
Regards,
Jerry
2015-03-07 Jerry DeLisle
PR fortran/64432
On 03/08/2015 04:58 PM, Steve Kargl wrote:
On Mon, Mar 09, 2015 at 01:07:25AM +0200, Janne Blomqvist wrote:
So I would prefer if we just hardcode the error values in the frontend
(-HUGE, 0, 0), in case somebody tries to use the kind=1,2 versions,
thus also removing the need for the new library f
?
Regards,
Jerry
2015-03-14 Jerry DeLisle
PR fortran/64432
*trans-intrinisic.c (conv_intrinsic_system_clock): Check the
smallest kind passed in user arguments and hard-code results for
KIND=1 or KIND=2 to indicate no clock available.
2015-03-14 Jerry DeLisle
Attachment on this one.
On 03/14/2015 07:22 AM, Jerry DeLisle wrote:
On 03/08/2015 04:58 PM, Steve Kargl wrote:
On Mon, Mar 09, 2015 at 01:07:25AM +0200, Janne Blomqvist wrote:
So I would prefer if we just hardcode the error values in the frontend
(-HUGE, 0, 0), in case somebody tries to use
On 03/12/2015 12:18 AM, Tobias Burnus wrote:
There are two groups of features which are not properly implemented with remote
access:
* "caf(:)[i]%a" might have a byte stride which is not compatible with the size
of "a". (Fix: new array descriptor.)
* All access which involves dereferencing point
On 03/10/2015 02:59 PM, Tobias Burnus wrote:
This patch completes the description of the coarray library functions, invoked
for -fcoarray=lib.
OK for the trunk?
(The currently documented functions can be seen at
https://gcc.gnu.org/onlinedocs/gfortran/Coarray-Programming.html )
Tobias
OK, th
trunk and then 4.9, 4.8?
Regards,
Jerry
2015-03-20 Jerry DeLisle
PR libgfortran/59513
* io/transfer.c (data_transfer_init): Only error if -std=f95 or
higher.
Index: libgfortran/io/transfer.c
On 03/21/2015 07:11 AM, Paul Richard Thomas wrote:
--- snip ---
I would very much like to say that this is OK for trunk but we are
hard up against the end of stage 4 and so it should really wait for
backporting to 5.2.
IMHO, since gfortran is not release critical, we should consider, in the
On 03/22/2015 08:47 AM, Janne Blomqvist wrote:
On Sat, Mar 21, 2015 at 12:24 AM, Jerry DeLisle wrote:
The attached patch allows the attempt to READ or WRITE after an EOF for
legacy code. The runtime error is suppressed for -std=legacy and -std=gnu.
For standard conformance the error is
On 03/22/2015 08:47 AM, Janne Blomqvist wrote:
On Sat, Mar 21, 2015 at 12:24 AM, Jerry DeLisle wrote:
The attached patch allows the attempt to READ or WRITE after an EOF for
legacy code. The runtime error is suppressed for -std=legacy and -std=gnu.
For standard conformance the error is
Committed as obvious and simple.
revision 221682.
Regards,
Jerry
2015-03-25 Jerry DeLisle
PR libgfortran/65541
* io/write.c (nml_write_obj): Convert '+' to '%' before emitting
object names in namelists
tested on 4.9 and 5.0.
I will commit in the next few days, giving others a chance to review.
New test case attached. I used STOP rather than abort just to change things up a
bit if the case fails. (yes I could have used -fall-intrinsics)
Regards
Jerry
2015-03-27 Jerry DeLisle
PR
On 03/28/2015 07:20 AM, H.J. Lu wrote:
I think this caused:
FAIL: gfortran.dg/io_constraints_8.f90 -O (test for errors, line 64)
FAIL: gfortran.dg/io_constraints_8.f90 -O (test for errors, line 65)
FAIL: gfortran.dg/io_constraints_8.f90 -O (test for errors, line 66)
FAIL: gfortran.dg/i
On 03/28/2015 07:20 AM, H.J. Lu wrote:
--- snip ---
I think this caused:
FAIL: gfortran.dg/io_constraints_8.f90 -O (test for errors, line 64)
FAIL: gfortran.dg/io_constraints_8.f90 -O (test for errors, line 65)
FAIL: gfortran.dg/io_constraints_8.f90 -O (test for errors, line 66)
FAIL:
On 03/29/2015 09:25 AM, Steve Kargl wrote:
On Sat, Mar 28, 2015 at 01:01:57AM +0100, Dominique Dhumieres wrote:
AFAICT your test succeeds without your patch and does not test that the ICE
reported by FX is gone (indeed it is with your patch).
New patch and testcase. The ChangeLog entries ar
On 04/02/2015 03:28 AM, Andre Vehreschild wrote:
Ping!
This should be in 5.1. Dominique and I feel like this patch is nearly obvious.
Regards,
Andre
On Wed, 25 Mar 2015 14:35:54 +0100
Andre Vehreschild wrote:
Hi all,
please find attached a fix for the recently introduced regression
On 04/05/2015 05:32 AM, Thomas Koenig wrote:
--- snip ---
So, what do you think about this?
Thomas
I am curious about what performance gain results from this? I can see saving a
library call to our runtime libraries. Do you have some timing results?
Jerry
-fsanitize=address and valgrind on a
number of existing test cases. Changelog is fairly clear I think.
OK for trunk?
Regards,
Jerry
2015-04-12 Jerry DeLisle
PR libgfortran/65089
* io/format.h (free_format): New function to free memory
allocated for building format error
On 06/23/2015 01:36 AM, Janne Blomqvist wrote:
> On Sun, Jun 21, 2015 at 4:57 PM, Thomas Koenig wrote:
>> *ping*
>>
>> https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00966.html
>>
>>
>>> Hello world,
>>>
>>> the attached patch emits a warning for constant integer division.
>>> While correct accordi
On 07/01/2015 10:53 AM, Steve Kargl wrote:
> The attached patch special cases unary minus/plus when
> gfotran tries to match a function keyword in a mangled
> statement. The testcase contains examples, but for
> context consider 'c = exp(-a) )' where the final ')'
> is erronous. gfortran is tryin
27;s case in the PR now works as expected.
OK for trunk?
Regards,
Jerry
2015-01-18 Jerry DeLisle
PR fortran/61933
* trans-io.c (set_parameter_value): Delete use of has_iostat.
Redefine to not generate any runtime error check calls.
(set_parameter_value_chk): R
ping
This PR has been marked as a regression, so I suppose we ought to get it fixed.
On 01/18/2015 09:10 PM, Jerry DeLisle wrote:
I reopened this PR to do some cleanup and to address a use case presented by
Joost in comment #7 of the subject PR.
The fundamental problem: if the variable
On 01/19/2015 11:28 PM, Tobias Burnus wrote:
Hi Jerry, hi all,
sorry for the slow patch review. I also still want to review your other inquire
patch.
Jerry DeLisle wrote:
The fundamental problem: if the variable containing the unit number in an
INQUIRE statement is of type KIND greater than 4
On 01/21/2015 03:33 PM, Tobias Burnus wrote:
Hi Jerry et al.,
Jerry DeLisle wrote:
I have added the following to libgfortran.h and used them (see patch)
/* Special unit numbers used to convey certain conditions. Numbers -3
thru -9 available. NEWUNIT values start at -10. */
#define
On 01/30/2015 04:10 AM, Andre Vehreschild wrote:
Hi all,
I fear this fix is not so obvious in one location, I therefore ask for a
review. The attached patch fixes:
- a duplicate code fragment (possibly due to merged twice),
- the indentation in the trans-expr.c block (in my first patch), and
-
The attached patch fixes this issue.
Regression tested on x86-64.
New test case attached.
OK for trunk?
Regards,
Jerry
2015-02-01 Jerry DeLisle
PR fortran/64506
* scanner.c (gfc_next_char_literal): Check for '!' and if found,
clear the comment and go ba
After Stage 4 of course.
On 02/01/2015 04:44 AM, Jerry DeLisle wrote:
The attached patch fixes this issue.
Regression tested on x86-64.
New test case attached.
OK for trunk?
Regards,
Jerry
2015-02-01 Jerry DeLisle
PR fortran/64506
* scanner.c (gfc_next_char_literal): Check
On 02/01/2015 08:34 PM, Jerry DeLisle wrote:
The test case should have the print *, astring changed to call abort.
Jerry
! { dg-do run }
! { dg-options "-std=gnu" }
! PR64506 fixed form source
character(25) :: astring
100 format('This format is OK.'
&)
On 02/01/2015 01:02 PM, Tobias Burnus wrote:
Jerry DeLisle wrote:
The attached patch fixes this issue.
Regression tested on x86-64.
New test case attached.
OK for trunk?
Looks ok (together with a changelog for the test case).
However, I tried a similar fixed-form program and it failed
ion tested on x86-64 Linux.
OK for trunk followed by backports?
I can not include a specific testsuite test case, it would take way too long to
run.
Regards,
Jerry
2015-02-07 Jerry DeLisle
PR libgfortran/60956
* io/fbuf.c (fbuf_flush_list): New function that only flus
/obvious, with a Changelog for the
testsuite as well.
Regards,
Jerry
2015-02-09 Jerry DeLisle
PR libgfortran/57822
* io/write_float.def (output_float): If doing g0 editing and
exponent is zero, do not emit exponent.
Index: write_float.def
On 02/08/2015 05:10 PM, Jerry DeLisle wrote:
The attached patch fixes this by checking for the case when we are doing g0
editing and the exponent is 0.
Regression tested on X86-64. For the larger kinds, we are on a different code
path out of necessity, so we need to address this corner case
On 02/15/2015 09:48 AM, Mikael Morin wrote:
[*] I have a few failing testcases (also without the patch), namely the
following; does this ring a bell ?
FAIL: gfortran.dg/erf_3.F90
FAIL: gfortran.dg/fmt_g0_7.f08
FAIL: gfortran.dg/fmt_en.f90
FAIL: gfortran.dg/nan_7.f90
FAIL: gfortran.dg/quad_2.f90
101 - 200 of 561 matches
Mail list logo
