On 05/09/2016 12:41 AM, Richard Biener wrote:
> On Fri, 6 May 2016, Richard Biener wrote:
>
>> On Fri, 6 May 2016, Richard Biener wrote:
>>
>>>
>>> The following patch fixes another case of missing DECL_EXPR in the FE.
>>>
>>> Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
>>>
>>>
On 05/07/2016 11:42 AM, Paul Richard Thomas wrote:
> Dear Jakub,
>
> As you might have noticed, I am forced to spend a couple of months out
> from gfortran support in order to move from France back to the UK. I
> am therefore dealing very sporadically with patches. Since we seem to
> have entered
results of the patch gives the following:
$ gfc s.f
s.f:4:9:
if ( x(1) < 0 .or.
1
Error: Can not process after the IF statement shown at (1)
f951: Error: Unexpected end of file in ‘s.f’
OK for trunk?
Regards,
Jerry
2016-05-18 Jerry DeLisle
PR fortran/66
On 05/20/2016 04:36 AM, Jakub Jelinek wrote:
> Hi!
>
> We ICE at -O0 while compiling the testcase below, because we don't reset
> two vars that are reset in all other places in frontend-passes.c when
> starting to process an unrelated statement. Without this,
> we can emit some statement into a p
On 05/22/2016 04:53 AM, Andre Vehreschild wrote:
> Hi Jerry,
>
> I have tested your patch and gave it a review and the only thing I like
> to have is a testcase. Can you provide one from the PR? With a testcase
> I say the patch is ok for trunk and thanks for the patch.
>
> Please note, I don't h
On 05/22/2016 06:00 PM, Jerry DeLisle wrote:
> On 05/22/2016 04:53 AM, Andre Vehreschild wrote:
>> Hi Jerry,
>>
>> I have tested your patch and gave it a review and the only thing I like
>> to have is a testcase. Can you provide one from the PR? With a testcase
>>
Committed rev r236628 as simple and obvious. I munged the Changelog then fixed
it.
New Revision: 236628
"https://gcc.gnu.org/viewcvs?rev=236628";
2016-05-23 Jerry DeLisle
* io/list_read (eat_spaces): Eat '\r' as part of spaces.
* gfortran.dg/nam
fixes this. Regression tested on x86_64. New test case
provided.
OK for trunk?
Regards,
Jerry
2015-08-28 Jerry DeLisle
PR libgfortran/67367
* io/unix.c (buf_read): Check for error condition and if found
return the error code.
Index: unix.c
On 08/28/2015 11:59 PM, FX wrote:
> Hi Jerry,
>
> The patch is OK, but I’m a bit puzzled about what the testcase does.
>
> It tests that we can OPEN a directory, but not READ from it? I didn’t know
> that was expected (to be able to OPEN a directory), and I find it somewhat
> puzzling. Can you
On 08/28/2015 10:18 PM, Jerry DeLisle wrote:
> I found that in read_buf where raw_read is called, no checks for errors were
> being made, raw_read returns the number of bytes read or an error code. In
> the
> test case, an error occurs and we proceeded to use the resulting error cod
On 09/01/2015 11:18 AM, Steve Kargl wrote:
> On Tue, Sep 01, 2015 at 11:16:27AM -0700, Steve Kargl wrote:
>> open(unit=10, file='junko.dir',iostat=ios,action='read',access='stream')
>> if (ios.ne.0) call abort
>> read(10, iostat=ios) c
>> - if (ios.ne.21) call abort
>> + if (ios.ne.
On 11/04/2016 07:11 AM, Christophe Lyon wrote:
On 4 November 2016 at 14:48, Christophe Lyon wrote:
On 30 October 2016 at 21:40, Thomas Koenig wrote:
Hi Jerry,
--- snip ---
The new test fails at execution on arm and aarch64:
gfortran.dg/fmt_t_9.f -O0 execution test
gfortran.dg/fmt_
On 11/13/2016 04:55 PM, Steve Kargl wrote:
On Sun, Nov 13, 2016 at 04:08:50PM -0800, Jerry DeLisle wrote:
Hi all,
Attached patch implements a fast blocked matrix multiply. The basic algorithm is
derived from netlib.org tuned blas dgemm. See matmul.m4 for reference.
The matmul() function is
On 11/13/2016 11:03 PM, Thomas Koenig wrote:
Hi Jerry,
I think this
+ /* Parameter adjustments */
+ c_dim1 = m;
+ c_offset = 1 + c_dim1;
should be
+ /* Parameter adjustments */
+ c_dim1 = rystride;
+ c_offset = 1 + c_dim1;
Regarding options for matmul: It is po
On 11/14/2016 11:22 PM, Thomas Koenig wrote:
Hi Jerry,
With these changes, OK for trunk?
Just going over this with a fine comb...
One thing just struck me: The loop variables should be index_type, so
const index_type m = xcount, n = ycount, k = count;
[...]
index_type a_dim1, a
On 11/15/2016 07:59 AM, Jerry DeLisle wrote:
On 11/14/2016 11:22 PM, Thomas Koenig wrote:
Hi Jerry,
With these changes, OK for trunk?
Just going over this with a fine comb...
One thing just struck me: The loop variables should be index_type, so
const index_type m = xcount, n
Committed after approval on bugzilla to eliminate warnings.
2016-11-16 Jerry DeLisle
PR libgfortran/51119
* Makefile.am: Remove -fno-protect-parens -fstack-arrays.
* Makefile.in: Regenerate.
r242517 = 026291bdda18395d7c746856dd7e4ed384856a1b (refs/remotes/svn/trunk
On 11/16/2016 01:30 PM, Thomas Koenig wrote:
Hello world,
the attached patch adds an AVX-specific version of the matmul
intrinsic to the Fortran library. This works by using the target_clones
attribute.
For testing, I compiled this on powerpc64-unknown-linux-gnu,
without any ill effects.
Also
necessary updates of the testsuite quad_2.f90.
OK for trunk?
Regards,
Jerry
2015-12-12 Jerry DeLisle
PR libfortran/pr68867
* io/write.c (set_fnode_default): For kind=16, set the decimal precision
depending on the platform binary precision, 106 or 113.
Index: gcc
Attached patch eliminate this problem by reverting a portion of the previous
patch to pr65089.
Regression tested on x86_64-Linux. I will add test case from the PR.
OK for trunk and then back port to 5x?
Regards,
Jerry
2015-12-26 Jerry DeLisle
PR libfortran/68987
io
state.
Regression tested on x86-64-linux.
OK for trunk and then back port to 5 in about a week?
A test case will be included, similar to that given by Dominique in the PR.
Regards,
Jerry
2016-01-18 Jerry DeLisle
PR fortran/65996
* error.c (gfc_error): Save the state of
On 04/28/2013 11:31 AM, Janne Blomqvist wrote:
> PING
>
> On Fri, Apr 19, 2013 at 1:30 PM, Janne Blomqvist
> wrote:
>> Hi,
>>
>> the attached patch improves the performance for unformatted and
>> unbuffered files. Currently unbuffered unformatted really means that
>> we don't buffer anything and
On 04/28/2013 01:16 PM, Janne Blomqvist wrote:
> Hi,
>
> while looking at system_clock due to the recent Windows patches, it
> occurred to me that the Unix versions can be simplified somewhat. The
> attached patch does this.
>
> Regtested on x86_64-unknown-linux-gnu, Ok for trunk?
>
OK for trun
The attached patch resolves this PR by treating '!', the Fortran comment mark,
as a valid separator between values. Thus, when encountered while reading a
value, the read is ended normally with whatever value was encountered. This is
an extension beyond the Standards which require a separator bef
On 05/04/2013 05:13 PM, Jerry DeLisle wrote:
> The attached patch resolves this PR by treating '!', the Fortran comment mark,
> as a valid separator between values. Thus, when encountered while reading a
> value, the read is ended normally with whatever value was encountere
On 05/04/2013 06:30 PM, Steve Kargl wrote:
> On Sat, May 04, 2013 at 05:13:51PM -0700, Jerry DeLisle wrote:
>>
>> CASE_SEPARATORS:/* Not a repeat count. */
>> case EOF:
>> +case '!':
>
> if (c == '!')
>
On 05/05/2013 05:47 AM, Steve Kargl wrote:
> On Sat, May 04, 2013 at 10:25:19PM -0700, Jerry DeLisle wrote:
>> On 05/04/2013 06:30 PM, Steve Kargl wrote:
>>> On Sat, May 04, 2013 at 05:13:51PM -0700, Jerry DeLisle wrote:
>>>>
>>>>CAS
On 03/15/2013 01:42 PM, Tilo Schwarz wrote:
Hi,
this is a ping for
[Patch, libfortran] PR51825 - Fortran runtime error: Cannot match namelist
object name
http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00316.html
Regards,
Tilo
OK, once trunk opens. Thanks for patch. Do you have commit
On 03/28/2013 03:21 AM, Tobias Burnus wrote:
> Tobias Burnus wrote:
>> b) To copy the format string
>>
>> The attached patch does the latter. The current hashing algorithm avoids hash
>> collisions by checking whether the value is exactly the same - and the value
>> is given by the format string. T
On 03/28/2013 06:48 AM, Tobias Burnus wrote:
> gfortran supports "?" and "=?" as input with namelists (a somewhat common
> vendor
> extension). Either of those can be used with stdin to print the available
> fields
> of the namelist. With non-stdin input, the ? and =? lines are simply ignored.
>
on x86-64.
OK for trunk?
Regards,
Jerry
2013-03-29 Jerry DeLisle
PR libfortran/56786
* io/list_read.c (nml_parse_qualifier): Remove spurious next_char call
when checking for EOF. Use error return mechanism when EOF detected.
Do not return false unless
On 04/01/2013 07:03 AM, Janus Weil wrote:
> Ping!
>
> (I hope I didn't "anti-advertise" this patch too much ;)
>
>
OK for trunk.
Jerry
its loops.
Regression tested on x86-64. Test case attached.
OK for trunk?
Jerry
2013-04-01 Jerry DeLisle
PR libfortran/56660
* io/list_read.c (nml_read_obj): Do not reset the read error flag
inside nml_read_obj. If the read error flag is found set just exit.
On 04/27/2014 04:57 AM, Andreas Schwab wrote:
> Jerry DeLisle writes:
>
>> +static void
>> +push_char4 (st_parameter_dt *dtp, gfc_char4_t c)
>> +{
>> + gfc_char4_t *new, *p = (gfc_char4_t *) dtp->u.p.saved_string;
>> +
>> + if (p == NULL)
>&g
push_char I have referred to as worker functions.
The revised test case is attached.
Regression tested on x86-64. OK for trunk? and later 4.9
Jerry
2014-05-04 Jerry DeLisle
PR libfortran/52539
* io/io.h (gfc_unit): New function pointers *next_char_fn_ptr
and
86-64 linux.
OK for trunk and then 4.9? Test case from PR.
Regards,
Jerry
2014-05-04 Jerry DeLisle
PR libfortran/61049
* io/list_read.c (list_formatted_read_scalar): Use eat_separator
and delete extraneous code.
Index: list_r
On 05/05/2014 07:34 AM, Dominique Dhumieres wrote:
> As posted in the PR, neither the patch in the PR nor the one in this thread
> fixes the test for powerpc-apple-darwin9.
>
I have tested the patch on powerpc linux and it works. That is a Bigendian
machine. Also tested on x86-64 -m32 and -m64. Un
Hello all,
The attached patch fixes this PR by not seeking if the next character is a
space.
Regression tested on x86-64. New test case provided.
OK for trunk and back ports?
Regards.
Jerry
2014-05-23 Jerry DeLisle
PR libgfortran/61173
* io/list_read.c (eat_spaces): If
On 05/24/2014 05:14 AM, Dominique Dhumieres wrote:
> Ping!
>
> https://gcc.gnu.org/ml/gcc-patches/2014-05/msg00219.html
>
> Dominique
>
>
Yes, OK, thanks for fixes.
Jerry
case attached with patch.
OK for trunk?
Regards,
Jerry
2014-05-24 Tobias Burnus
PR fortran/55117
* trans-io.c (nml_full_name, transfer_namelist_element): Insert
a '+' rather then '%' to differentiate namelist variable names
that are based o
I attached the wrong test case.
use the one attached.
On 05/24/2014 07:14 PM, Jerry DeLisle wrote:
> Hi folks,
>
> This patch combines Tobias front-end patch with my libgfortran patch to
> resolve
> this PR.
>
> To denote extended derived types (classes) we use a &
On 01/19/2014 06:24 AM, Dominique d'Humières wrote:
> The attached patch fixes these bugs and adds the tests. See the PRs for =
> the rationale of the changes.
> Regression tested on x86_64-apple-darwin13 and powerpc-apple-darwin9.
> OK for trunk, 4.8.3, and 4.7.4 (after testing)?
>
> Regards,
> D
I have committed for Dominiq some followup minor cleanup.
Index: io/write_float.def
===
--- io/write_float.def (revision 206864)
+++ io/write_float.def (working copy)
@@ -373,7 +373,7 @@
updown:
rchar = '0';
- if (ft != FMT_
are a test case.
Regression tested on x86_64.
OK for trunk or hold for next stage?
Regards,
Jerry
2014-03-01 Jerry DeLisle
PR libfortran/60148
* io/inquire.c (inquire_via_unit): In the case of
DELIM_UNSPECIFIED set inquire return string to "NONE".
On 03/02/2014 12:50 PM, Tobias Burnus wrote:
--- snip ---
>
> gfortran seems to be special as it defaults to printing the " (quote)
> delimiter
> by default while other compilers seem to default to "none".
>
Looking back at the draft F95 standard that I have I am amazed. As you stated
in your
lengths to calculate the
position in the string where the error occurs.
Test case attached.
Regression tested on x86-64.
OK for trunk?
2014-07-12 Jerry DeLisle
PR libgfortran/61632
* io/format.c (format_error): Avoid invalid string pointer by
using the fortran string length
On 03/07/2014 02:05 PM, Dominique d'Humières wrote:
>
> Hi all!
>
> Patch for pr60128. It is basically the patch posted at =
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D60128#c7. I have made tmp =
> volatile (although I did not see any differences between -m32 and -m64) =
> and added a commen
t_char.
I also remove some unneeded error checks.
Regression tested on X86_64 gnu. No need for a new test case since no new
functionality is added.
OK for trunk? The PR is marked as a regression, so I think this could be the
last piece and call it done.
Regards,
Jerry
2014-03-08 Jer
On 03/08/2014 02:45 AM, Tobias Burnus wrote:
--- snip ---
>
> I think that code is okay.
>
> I wonder whether it can happen that we read one character too far: i.e.
> stell()
> == end of string; offset++ -> one behind. As one then immediately steps back
> (due to "offset < limit" plus offset--),
On 03/08/2014 04:58 AM, Steven Bosscher wrote:
> On Sat, Mar 8, 2014 at 7:38 AM, Jerry DeLisle wrote:
>> The speedup is accomplished by simply skipping over spaces without calling
>> next_read, then backing up one character and letting the existing execution
>> path
>>
on X86-64-Gnu-Linux. No new test case needed.
OK for trunk?
Regards,
Jerry
2014-03-08 Jerry DeLisle
PR libfortran/38199
Index: read.c
===
--- read.c (revision 208303)
+++ read.c (working copy)
@@ -677,7 +67
On 03/09/2014 05:39 PM, Jerry DeLisle wrote:
> Hi all,
>
> This final patch does two things.
>
> First: In read.c it implements a simple space skipping scheme in read_decimal
> where I found a lot of repeated next_char calls happening. This gives a pretty
> good boost
On 03/12/2014 11:46 AM, Tobias Burnus wrote:
> Jerry DeLisle wrote:
>> + if (dtp->common.unit == 0)
>> +{
>> + len = string_len_trim (dtp->internal_unit_len,
>> + dtp->internal_unit);
>> + if (len > 0)
>> +
problem particularly manifests for empty reads that do no other actual file
reading except in (finish_list_read).
Regression tested on x86-64-linux-gnu. NIST tested. test case provided.
Ok for trunk?
Regards,
Jerry
2014-03-14 Jerry DeLisle
PR libfortran/58324
* io/list_read.c
checking for the comma and end-of-line
conditions which are also done in eat_separator.
Regression tested on x86-64-gnu. No test case can be done since it require
terminal input to read.
OK for trunk?
Regards,
Jerry
2014-03-16 Jerry DeLisle
PR libfortran/58324
* io/list_read.c
_std & GFC_STD_GNU ? DELIM_QUOTE : DELIM_NONE;
else
dtp->u.p.current_unit->delim_status =
dtp->u.p.current_unit->flags.delim;
}
If std= was used at compile time for std=f95, f2003, f2008, set the default
delimiter to 'NONE' if not otherwise specified.
,
Jerry
2014-03-29 Jerry DeLisle
PR libfortran/52539
* io/list_read.c: Add uchar typedef. (push_char4): New function
to save kind=4 character. (next_char_utf8): New function to read
a single UTF-8 encoded character value. (read_chracter): Update
to use the
I plan to commit the following patch to 4.10, 4.9, 4.8, and 4.7.
It is a partial revert of the patch to PR38199 which is an optimization of
internal unit reads.
The original patch was too aggressive. After this revert, I will investigate
further to see if I can refine it further.
Regards,
Jerr
Relates to PR60810
On 04/11/2014 04:10 PM, Jerry DeLisle wrote:
> I plan to commit the following patch to 4.10, 4.9, 4.8, and 4.7.
>
> It is a partial revert of the patch to PR38199 which is an optimization of
> internal unit reads.
>
> The original patch was too aggressive.
On 04/11/2014 04:31 PM, Tobias Burnus wrote:
> Jerry DeLisle wrote:
>> I plan to commit the following patch to 4.10, 4.9, 4.8, and 4.7.
>>
>> It is a partial revert of the patch to PR38199 which is an optimization of
>> internal unit reads.
>>
>> The origina
Ping! This is PR52539
On 03/29/2014 09:58 PM, Jerry DeLisle wrote:
> Hi all,
>
> The attached patch fixes namelist read/write and list directed read/write to
> support UTF-8.
>
> I have attached a preliminary test case to use to experiment with this. I
> will
> n
On 04/13/2014 10:48 AM, Jerry DeLisle wrote:
> Ping! This is PR52539
>
Without comment or objections, I will commit this patch this weekend to trunk.
Regards,
Jerry
> On 03/29/2014 09:58 PM, Jerry DeLisle wrote:
>> Hi all,
>>
>> The attached patch fixes namelist r
On 12/20/2012 03:23 AM, Thomas Koenig wrote:
Ping?
Thomas
Hi Janus,
Oops, right. Here is the correct one.
Yes, OK
Regards,
Jerry
On 12/15/2012 08:32 AM, Janne Blomqvist wrote:
Hello,
the attached patch fixes PR 55539 (4.8 regression). Regtested on
x86_64-unknown-linux-gnu, Ok for trunk?
2012-12-15 Janne Blomqvist
PR fortran/55539
* io/write_float.def (output_float): Take into account decimal dot.
t
The attached patch fixes this bug by not assigning the new unit value to the
user variable until after the OPEN is successful.
Regression tested on Linux X86-64.
OK for trunk with the test case from the PR?
Regards,
Jerry
2012-12-26 Jerry DeLisle
PR libfortran/48960
* io
Greetings,
The attached patch implements the missing INQUIRE(99, STREAM=str) functionality
required by the Fortran 2008 Standard.
Regression tested on x86-64.
OK for trunk with test case from the PR?
Regards,
Jerry
2012-12-27 Jerry DeLisle
PR fortran/48976
* gfortran.h
On 12/27/2012 03:12 AM, Tobias Burnus wrote:
Dear Jerry,
thanks for the patch.However, I wonder about the following:
Will that be backward compatible with binaries compiled with GCC < 4.8 or will
that cause problems? I have the feeling that it is okay as the flag ("cf2")
indicating whether "str
Hi,
The attached patch fixes this problem by not calling hit_eof if EOF can be a
valid separator.
Regression tested on x86-64.
OK for trunk with test case from PR?
Regards,
Jerry
2012-12-27 Jerry DeLisle
PR libfortran/55818
* io/list_read.c (read_real): Do not call
On 12/27/2012 05:51 PM, Jerry DeLisle wrote:
Hi,
The attached patch fixes this problem by not calling hit_eof if EOF can be a
valid separator.
Regression tested on x86-64.
OK for trunk with test case from PR?
Regards,
Jerry
2012-12-27 Jerry DeLisle
PR libfortran/55818
* io
This updated patch addresses the issues with infinities, nans, characters, and
valid reals.
OK for trunk?
Test case attached.
Regards,
Jerry
Index: list_read.c
===
--- list_read.c (revision 194731)
+++ list_read.c (working copy)
On 01/02/2013 01:00 AM, Tobias Burnus wrote:
Jerry DeLisle wrote:
This updated patch addresses the issues with infinities, nans, characters, and
valid reals.
And complex.
OK for trunk?
Test case attached.
Thanks for the patch. It looks okay (with a ChangeLog).
ChangeLog created
On 02/19/2013 02:40 PM, Janne Blomqvist wrote:
Hi,
attached is an attempt to fix writing formatted sequential I/O to a
pipe (The PR was reopened in comment #22, which refers to formatted
I/O so the PR title is incorrect). I think the underlying reason was
that the introduction of the ssize() mem
On 10/30/2011 07:50 PM, Steve Kargl wrote:
I've had this patch in my i386-*-freebsd and x86_64-*-freebsd
for more than a week. Several 'gmake check-gfortran' have
been run during that time without a regression.
OK for trunk?
OK, thanks for patch.
Jerry
On 10/31/2011 11:51 AM, Janne Blomqvist wrote:
Hi,
I'd like to revert the fix for PR 45723 that was committed previously
for the following reasons:
- Using stat("/path/to/file", ...) to infer something about an open
file descriptor is racy.
- As I argued in http://gcc.gnu.org/ml/fortran/2011-1
On 11/07/2011 12:28 PM, Janne Blomqvist wrote:
PING!
On Mon, Oct 31, 2011 at 20:57, Janne Blomqvist
wrote:
Hi,
here's an updated version of my patch that gets rid of _commit along
with a section in the manual describing data consistency and
durability issues.
See also the thread starting at
On 05/11/2012 09:07 AM, Janne Blomqvist wrote:
PING #2!
On Wed, May 2, 2012 at 10:22 PM, Janne Blomqvist
wrote:
PING
On Thu, Apr 26, 2012 at 12:08 AM, Janne Blomqvist
wrote:
Hi,
currently when -frange-check is enabled, we check for overflow when
doing a formatted read of an integer value
On 08/26/2011 05:40 AM, Thomas Koenig wrote:
Hello world,
the attached patch fixes the PR by doing comparisions for wide
characters as unsigned 4-byte ints.
I have put the comparison function into libgfortran.h because I will
need it for MINLOC and friends for characters.
OK for trunk? Which b
On 03/12/2012 05:28 PM, Janne Blomqvist wrote:
Hi,
currently when writing a value of type real or complex using
list-directed output, the G0 edit descriptor, or namelist output,
gfortran chooses the number of significant digits such that a
binary->ascii->binary roundtrip recovers the original va
On 03/08/2012 05:40 PM, Janne Blomqvist wrote:
Hi,
the attached patch implements some improvements for formatted writes
of floating point values. Currently libgfortran uses snprintf() to
fill a buffer with a fixed amount of digits, regardless of the digits
required, and then rounding or zero ext
On 03/15/2012 02:55 AM, Janne Blomqvist wrote:
On Thu, Mar 15, 2012 at 01:52, Jerry DeLisle wrote:
I like the idea behind this patch. I confess, I have not studied the two
test cases that you are modifying, but the changes seem to stick out with
too many digits there. Is this really correct
On 03/15/2012 11:42 AM, Janne Blomqvist wrote:
PING! (At this point, obviously for trunk only)
Yes, OK for trunk.
On Mon, Feb 13, 2012 at 20:20, Janne Blomqvist
wrote:
Hi,
the attached patch changes the low-level libgfortran IO dispatching
mechanism to use shared vtables for each stream
On 04/10/2012 08:32 AM, Thomas Koenig wrote:
Hello world,
this patch effectively trims the spaces from the string on
list-directed reads. This avoids the large overhead on
processing these spaces when reading from long lines.
I didn't do this for internal units which are arrays because
this wou
On 05/26/2011 11:10 PM, Tobias Burnus wrote:
Attached is a small coarray fix, solving two issues:
- For -fcoarray=single, nonallocatable coarrays are nonpointer - but currently
they get set the "restrict" qualifier. (With -fcoarray=lib, nonallocatble
coarrays are always pointers.)
Fixed by n
a minor performance improvement. It
eliminates a bit of code.
Regression tested on x86-64.
OK for trunk? then later back port to 4.6 after some proving time?
Jerry
2011-06-03 Jerry DeLisle
PR libgfortran/48906
* write.c (write_d, write_e, write_f, write_en, write_es, write_rea
On 06/03/2011 05:51 AM, jerry DeLisle wrote:
Hi,
The attached patch, which includes test cases, fixes this bug by eliminating the
code which used floating point instructions to determine the 'r' value as
outlined in the Fortran standard under G formatting.
Essentially, the code no
On 06/10/2011 05:12 AM, Tobias Burnus wrote:
This patch fixes parts of the PR 49324: There was a deep copy missing for
assigning an array constructor of a DT with allocatable components.
Whether a deep copy is done, depends on a flag. I think the flag has been added
to avoid a deep copy and mult
On 06/10/2011 10:08 AM, Thomas Koenig wrote:
I wrote:
Hello world,
the attached patch extends removing trailing TRIMs in assignments for
cases like a // trim(b). Regression-tested. OK for trunk?
Thomas
This time with the test case corrected (cleanup of the *.original file)
and a more mean
On 06/11/2011 12:23 AM, Thomas Henlich wrote:
I don't agree with this; with the patch we now output 10 significant
digits, whereas 9 is sufficient for a binary->ascii->binary roundtrip.
So please retain the "reduce d by one when E editing is used" thing
for list format and G0. This is just a side
On 06/11/2011 12:23 AM, Thomas Henlich wrote:
I don't agree with this; with the patch we now output 10 significant
digits, whereas 9 is sufficient for a binary->ascii->binary roundtrip.
So please retain the "reduce d by one when E editing is used" thing
for list format and G0. This is just a side
On 06/16/2011 12:22 AM, Tobias Burnus wrote:
Hi all,
if the RHS is an array constructor, gfortran didn't deep copy
allocatable components. That was fixed for the trunk by the patch at
http://gcc.gnu.org/ml/fortran/2011-06/msg00095.html
The wrong-code issue is not a regression and code leadin
On 06/17/2011 12:02 PM, Janne Blomqvist wrote:
PING.
Also, here's a slightly simplfied testcase:
Yes, OK
Jerry
On 06/27/2011 03:18 PM, Thomas Koenig wrote:
Hello world,
the attached patch fixes PR 49479, a regression for 4.7 and 4.6. Test
case was supplied by Joost, the approach to the patch was suggested by
Tobias in comment#4 of the PR. The patch certainly looks safe enough.
Regression-tested. OK for
On 07/12/2011 01:05 AM, Janne Blomqvist wrote:
PING
On Mon, Jul 4, 2011 at 00:57, Janne Blomqvist wrote:
Hi,
the attached patch fixes the remaining cases of handling input that
ends in EOF instead of a normal separator for list formatted read of
the primitive types. Ok for trunk and 4.6?
Y
On 07/20/2011 03:30 PM, Tobias Burnus wrote:
This patch partially undoes the change done in PR 46010.
For that patch, first (comment 7)
+ || !dtp->u.p.ionml->touched)
was added - and after not solving the problem, the complete change was (comment
9 and committed version)
+ || !dtp->u.p.ionml-
On 07/22/2011 02:51 PM, Tobias Burnus wrote:
Local, nostatic/nonallocable DT variables were rejected if they contained
(allocatable) coarray components. However, those are allowed - I had initially
misread the constraint.
C526 A coarray or an object with a coarray ultimate
component shall be a d
On 07/23/2011 03:20 AM, Tobias Burnus wrote:
Jerry DeLisle wrote:
I would say OK for trunk and then backport in a few weeks. If you feel like
being conservative you could use
|| (dtp->u.p.ionml->type == BT_DERIVED && !dtp->u.p.ionml->touched)) but I do
not think it is
On 07/22/2011 02:49 PM, Tobias Burnus wrote:
Tobias Burnus wrote:
This patch adds a "token" element as last element in the descriptor such that
is can be easily ignored when passing a descriptor to a noncoarray descriptor
dummy.
Handling coarray descriptors differently from noncoarray descript
On 04/14/2011 11:53 PM, Janne Blomqvist wrote:
Hi,
as is well known, sprintf() is prone to buffer overflow, hence
snprintf(). libgfortran uses snprintf() in some places, but not
everywhere. Rather than analyzing every sprintf() call for a potential
overflow, the attached patch takes the dogmatic
On 04/15/2011 07:28 AM, Michael Matz wrote:
--- snip ---
I'll make the DECL_EXPR conditional on the size being variable. As Tobias
already okayed the patch I'm planning to check in the slightly modified
variant as below, after a new round of testing.
Thats A-OK
Thanks,
Jerry
Hi,
I plan to commit the following simple and obvious patch.
Regression tested on x86-64-linux-gnu.
I will apply the test case in the PR to the testsuite.
Regards,
Jerry
2011-04-15 Jerry DeLisle
PR libgfortran/48589
* io/write_float.def (write_infnan): Set width properly
401 - 500 of 561 matches
Mail list logo
