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&root=gcc&view=rev
Log:
2018-07-04 Jerry DeLisle
PR fortr
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,
un
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 L
On 07/15/2018 10:47 AM, Rainer Orth wrote:
Hi Thomas,
However, I still don't understand why you insist on the hack with
putting the async_io_*.f90 tests into the libgomp testsuite. Why not
just make the pthread requirement explicit with
{ dg-require-effective-target pthread }
{ dg-additional-
On 07/15/2018 11:46 AM, Rainer Orth wrote:
Hi Jerry,
Hmm, interesting. Which linux are you using?
Fedora 27.
Rainer
Works for me. Fedora 28. Do not know for other OS's
Jerry
-of-record if seen_dollar.
2021-02-07 Jerry DeLisle
libgfortran/ChangeLog:
PR libgfortran/98825
* io/transfer.c (next_record_w): Insert check for seen_dollar and if
so, skip issueing next record.
gcc/testsuite/ChangeLog:
* gfortran.dg/dollar_edit_descriptor_4.f: New test.
di
On 2/7/21 9:07 AM, Thomas Koenig wrote:
Hi Jerry,
OK for trunk and backport to 10 since it is simple enough?
OK for trunk.
Because this is a user-visible change (even if we did the wrong
thing before) I don't feel that we should backport (but I am
open to suggestions otherwise).
Could y
The attached patch is another provided from Steve Kargle in the PR report.
I have created a test case and regression tested the result.
OK for trunk?
Regards,
Jerry
libgfortran: Fix PR95647 by changing the interfaces of operators .eq.
and .ne.
The FE converts the old school .eq. to ==,
and
How do I get permissions set so that I can change status of bug reports
and assign to myself. My permissions got dissolved during some
evolution in the last year.
also
The master branch has been updated by Jerry DeLisle:
https://gcc.gnu.org/g:0631e008adc759cc801d0d034224ee6b4bcf31aa
commit
Hi all,
Attached patch adds to checks. In the case of IMPLICIT typing it checks
to see if the objects listed in the NAMELIST have defined types andf if
not, sets them to the default implicit types.
In the case of IMPLICIT NONE, the types are required be declared before
the NAMELIST. If an
On 2/19/21 8:00 AM, Tobias Burnus wrote:
In this example, the formal argument is a derived type
and not a class – hence, there is an ICE.
OK for the trunk?
This is OK, could you also check 89219 and 81499 and see if these are
the same or similar.
Much appreciated.
Jerry
On 2/19/21 1:33 AM, Tobias Burnus wrote:
On 09.02.21 12:52, Tobias Burnus wrote:
Hi all, hi Thomas,
On 02.02.21 18:15, Tobias Burnus wrote:
I think I will do a combination: If 'identical' is true, I think I
cannot remove it. If it is false, it can be identical or nonoverlapping
– which makes
Hi Harald, Looks Good to Me.
OK
Thanks
On 2/22/21 1:14 PM, Harald Anlauf via Fortran wrote:
Dear all,
when simplifying the RESHAPE intrinsic we lost the string length when
the resulting array had size zero. The attached patch sets the resulting
length from the source.
Regtested on x86_64-pc
Yes OK got mainline.
On 3/3/21 3:45 AM, Tobias Burnus wrote:
Rather obvious change – don't apply replacement multiple times.
OK for mainline?
Tobias
-
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München
Registergericht München HRB 106955, Geschäftsführer: Tho
Yes, OK, however, have you been able to test performance. I am only
curious. There was a test program we used back when this code was first
implemented in bugzilla. I do not remember the PR number off hand.
Jerry
On 2/23/21 1:46 PM, Harald Anlauf via Fortran wrote:
Dear all,
under certain ci
OK, thanks Dominique for spotting this.
On 3/4/21 9:02 AM, Tobias Burnus wrote:
Dominique found an issue ("regression") with this patch – and a testcase
omission.
The previous patch mishandled the noncommitted testcase of PR57871 – or
in other words: It did not promote 1.0_4 or 1.0_8 – as only
?
Jerry
2019-11-01 Jerry DeLisle
PR fortran/90374
* io.c (check_format): Allow zero width for D, E, EN, and ES
specifiers as default and when -std=F2018 is given. Retain
existing errors when using the -fdec family of flags.
2019-11-01 Jerry DeLisle
On 11/7/19 12:41 PM, Tobias Burnus wrote:
This fixes the gfortran.dg/continuation_6.f fails testsuite fails with newer
GLIBC.
The continuation line handling assumes that the line number starts at 0 (→
continue_line) and then can be incremented, if needed.
The problem came up with -pre_includ
On 5/18/21 11:36 AM, Harald Anlauf via Fortran wrote:
The generation of the new runtime check picked up the wrong attributes
in the case of CLASS array arguments. There is related new code in
gfc_conv_procedure_call which served as reference for the fix.
Regtested on x86_64-pc-linux-gnu.
OK fo
On 5/26/21 2:04 PM, Harald Anlauf via Fortran wrote:
Dear Fortranners,
Gerhard found a case where bounds-checking for an optional,
allocatable character dummy resulted in an ICE. We'd better
not call the presence check on a non-dummy symbol, as this
will hit an assert...
Regtested on x86_64-pc
LGTM, OK for trunk and back ports.
On 5/4/21 11:34 AM, Harald Anlauf via Fortran wrote:
PING!
---
Dear Fortranners,
Gerhard found a case where the mismatch of actual and formal argument lead
to an ICE instead of the relevant warning. Furthermore, the special case
of character argument avoide
The attached patch fixes the X editing.
Fairly self explanatory. I created the patch a few years back.
Regression tested on x86_64 and new test case.
OK for trunk?
Regards,
Jerrydiff --git a/gcc/testsuite/gfortran.dg/pr99210.f90 b/gcc/testsuite/gfortran.dg/pr99210.f90
new file mode 100644
inde
Ok and thanks.
On Fri, Aug 9, 2024, 7:33 AM Andre Vehreschild wrote:
> Ping!
>
> And the last ping in the series. I have a "bigger" patch in the queue and
> want
> the pending ones done beforehand.
>
> Regtested ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline?
>
> - Andre
>
> On Mon, 22 J
On 01/18/2016 11:01 AM, Jerry DeLisle wrote:
> This patch follows the suggestion Jakub made in the PR and is very
> straightforward.
>
The patch is simple enough. I will commit to trunk shortly if I hear from no
one.
Regards,
Jerry
> With the patch, an abort is given on actua
On 01/23/2016 04:26 AM, Thomas Koenig wrote:
> Hi Toon,
>
>> However, today I *did* run the test harness with your modification:
>
> ...
>
> Thanks for the testing!
>
> So, what do people think? Is the patch OK for trunk?
>
> Regards
>
> Thomas
>
Yes, OK.
Jerry
On 01/23/2016 02:40 PM, John David Anglin wrote:
> Ping.
>
> On 2015-12-28, at 2:58 PM, John David Anglin wrote:
>
>> The hppa*-*-hpux* target does not support __sync builtins. As a result,
>> libbacktrace does not
>> support backtraces when threads are active.
>>
>> Instead of always assuming
Ha all,
The attached patch with new test cases fixes these by replacing gcc_assert and
updating the error message depending on whether resolving an initialization
expression or not.
Regression tested on x86-64.
OK for trunk?
Jerry
2016-01-23 Jerry DeLisle
PR fortran/69397
On 01/27/2016 08:25 AM, Andre Vehreschild wrote:
> Hi all,
>
> attached are two patches one for trunk and one for the gcc-5-branch,
> which fix an ICE when BLOCK statements are not closed correctly (too
> many END BLOCKs). Unfortunately did the patch I tailored for gcc-5 not
> work on trunk.
>
>
Hi All,
Attached patch adds diagnostics to catch this.
Test case included. Regression tested on x86-64
OK for trunk?
Regards,
Jerry
PS Want to get this one out of the way so I can do the new namelist regression
with DELIM=NONE.
2016-02-06 Jerry DeLisle
PR fortran/50555
The attached patch reverts the guilty code. We were trying to honor delim=NONE
on namelist reads which is invalid.
Test cases updated. Regression tested on x86-64.
OK for trunk and back port in about a week?
Regards,
Jerry
2016-02-09 Jerry DeLisle
PR libgfortran/69668
* io
On 02/08/2016 11:28 AM, Harald Anlauf wrote:
> Hi,
>
> the simple patch below rejects arrays as do loop index
> variable before another (confusing) error message is emitted.
> Two new testcases derived from the PR, plus adaption of one
> testcase that relies on the old error message.
>
> Whoever
On 02/09/2016 06:45 PM, Jerry DeLisle wrote:
> The attached patch reverts the guilty code. We were trying to honor delim=NONE
> on namelist reads which is invalid.
>
> Test cases updated. Regression tested on x86-64.
>
> OK for trunk and back port in about a week?
>
No
On 02/11/2016 10:38 AM, Janne Blomqvist wrote:
> On Wed, Feb 10, 2016 at 4:45 AM, Jerry DeLisle wrote:
>> The attached patch reverts the guilty code. We were trying to honor
>> delim=NONE
>> on namelist reads which is invalid.
>>
>> Test cases updated. Regressi
on is through making sure what we read in matches
what we wrote out to the test scratch file
Regression tested on x86_64-Linux. OK for trunk? any thoughts on back porting
to 5 since it fixes a potentially bad pointer problem in push_char4?
Regards,
Jerry
2016-02-15 Jerry DeLisle
PR l
On 02/16/2016 12:06 AM, Christophe Lyon wrote:
> On 15 February 2016 at 23:16, Janne Blomqvist
> wrote:
>> On Mon, Feb 15, 2016 at 11:45 PM, Jerry DeLisle
>> wrote:
>>> The title of the PR should be "Mishandling of namelist comments" or
>>> "
On 02/16/2016 05:17 AM, Dominique d'Humières wrote:
> Hi Jerry,
>
>> Thanks for review. Committed to trunk r233436.
>
> The test gfortran.dg/read_bang4.f90 fails on x86_64-apple-darwin15:
>
> a.out(15552,0x7fff7b2e3000) malloc: *** error for object 0x7fb472804c00:
> pointer being freed was not
(15,*,iostat=ios) str1, str2
> close(15)
> end program
>
> valgrind shows a lot of errors before and after the commit.
>
> Dominique
>
>> Le 16 févr. 2016 à 18:58, Jerry DeLisle a écrit :
>>
>> Up until now we have not had a test case like this for kind
On 02/16/2016 05:37 PM, Jerry DeLisle wrote:
> See patch to fix this below.
>
Committed on trunk, r233500 after regression testing, -fsanitize=address
testing, and valgrind testing.
Jerry
giving the correct item number
(always zero) so I realized the item_count was not being incremented for each
object. So fixed this as well.
Regression tested on x86-64-Linux. One new test case and one modified.
OK for trunk? Not strictly a regression, but simple enough.
Jerry
2016-02-22 Jerry
The ice on this one is actually in libcpp but I don't want to mess around in
that area. Not sure why we were only doing a warning here.
I plan to commit the following to trunk with a ChangeLog entry under the simple
and obvious rule.
Let me no if any objections.
Jerry
diff --git a/gcc/fortran
This patch from Steve on c.l.f
Fixes the segfault from attempting a string compare where there is no string
yet.
Regression tested on x86-64. New test case.
OK for trunk.
Regards,
Jerry
2016-02-24 Jerry DeLisle
Steven G. Kargl
PR fortran/69110
* io.c
On 02/27/2016 01:12 PM, Tom de Vries wrote:
> On 25-02-16 01:54, Jerry DeLisle wrote:
>> This patch from Steve on c.l.f
>>
>> Fixes the segfault from attempting a string compare where there is no string
>> yet.
>>
>> Regression tested on x86-64. New test
On 02/28/2016 03:39 AM, Thomas Koenig wrote:
> I wrote:
>
>> So, OK for these branches?
>
> Patch at
>
> https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01364.html
>
> Regards
>
> Thomas
>>
>> 2016-02-18 Thomas Koenig
>>
>> PR fortran/68147
>> PR fortran/47674
>>
On 02/28/2016 03:42 AM, Thomas Koenig wrote:
> I wrote:
>
> Patch at
>
> https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00941.html
>
>> OK for trunk?
>>
>> Regards
>>
>> Thomas
>>
>> 2016-02-14 Thomas Koenig
>>
>> * dump-parse-tree.c (show_code_node): Print association
>>
On 03/03/2016 07:59 AM, Paul Richard Thomas wrote:
> Dear All,
>
> What started out as a provisional kludge, when first working on OOP,
> has come back to bite us after 7 years. A collision in derived type
> has values has been reported on clf. In principle, as pointed out in
> the clf thread, thi
have regression tested on X86-64 Linux. OK for trunk?
Regards,
Jerry
2013-12-15 Jerry DeLisle
PR libfortran/59419
* io/file_pos.c (st_rewind): Do proper return after
generate_error.
* io/open.c (edit_modes): Move action code inside block that
checks
item_count".
Regression tested on x86-64.
OK for trunk? I will add the test case from PR59700 to the test suite.
Regards,
Jerry
2014-01-10 Jerry DeLisle
Steven G. Kargl
PR libfortran/59700
PR libfortran/59764
* io/io.h (struct st_parameter_dt): Assig
My apologies please. I forgot to mention Dominiq for his superb assistance with
this patch and testing. Many thanks!
On 01/11/2014 09:13 AM, Jerry DeLisle wrote:
> The attached patch fixes both these bugs, combining Steve's patch and mine.
> Recent fixes of memory leaks placed th
On 09/24/2015 04:52 AM, Jim MacArthur wrote:
> Hi all, I'm following up on some old work my colleague Mark Doffman did to
> try
> and get support for the AUTOMATIC keyword into trunk. In the enclosed patch
> I've addressed the problem with it accepting 'automatic' outside -std=gnu (it
> will no
On 09/25/2015 12:13 PM, Steve Kargl wrote:
> The follwoing patch has been built and regression
> tested on x86_64-*-freebsd. There were no regression.
>
> The patch removes an assert, which allows gfortran
> to detect an invalid selector in SELECT TYPE statement.
>
OK, thanks for patch!
Jerry
On 09/25/2015 12:18 PM, Steve Kargl wrote:
> The attached patch has been built and regression tested on
> x86_64-*-freebsd. There were no regression.
>
> If the scalar-numeric-expr in an arithmetic-if is ar
> reference to NULL(), this is an invalid expression.
> By resolving the expression, then
On 11/05/2015 01:48 AM, Dominique d'Humières wrote:
> Is there any objection to commit the following (see comments 21 and 22)?
>
> Dominique
>
OK, simple.
On 11/10/2015 06:41 AM, Dominique d'Humières wrote:
> Index: gcc/testsuite/ChangeLog
> ===
> --- gcc/testsuite/ChangeLog (revision 229793)
> +++ gcc/testsuite/ChangeLog (working copy)
> @@ -1,3 +1,9 @@
> +2015-11-10 Dominique d'Hu
On 11/11/2015 10:34 AM, Steve Kargl wrote:
> This probably falls under the "obviously correct" moniker.
> It has been built and tested on i386-*-freebsd. OK to commit?
>
> The patch removes a gfc_internal_error(). I suspect that it
> was originally put into gfortran to cover "correctly written
>
On 11/13/2015 01:57 PM, Steve Kargl wrote:
> The attached patch fixes an ICE that occurs in arith.c(gfc_arith_concat)
> because op1 and op2 have incompatible typespecs. The fix is actually
> implemented in array.c(gfc_match_array_constructor) where the types
> of the elements in a constructor are
On 11/17/2015 08:05 AM, Steve Kargl wrote:
> The attached patch fixes an issue with SPREAD and the PARAMETER
> attribute when an array constructor is too large for expansion.
> gfortran now issues an error message and points to the
> -fmax-array-constructor.
>
> Patch built on i386-*-freebsd and
On 11/17/2015 12:34 PM, Steve Kargl wrote:
> Here's what looks like a fairly simple patch, but it leads
> to a question. Why does gfortran not try to reduce the
> components in a structure constructor in general? I've
> hidden the gfc_reduce_init_expr() behind a check for a
> DATA statement, but
On 11/22/2015 01:14 AM, Dominique d'Humières wrote:
> Is it OK to back port revision r227760 to 5.3?
> Tested on x86_64-apple-darwin14
>
> Dominique
>
I think its OK.
Jerry
On 11/22/2015 10:59 AM, Steve Kargl wrote:
> I have no idea if this is actually correct, but it restores bootstrap.
> OK to commit?
>
This looks correct to me. There should be no more in the lists than
OMP_LIST_NUM. Was there a PR for this and do we know when it broke?
Jerry
.
OK for trunk?
Jerry
2015-11-22 Jerry DeLisle
* io/write_float.def (output_float): Move block determining
room for leading zero to before checkng g0 formatting.
Index: fmt_g0_1.f08
===
--- fmt_g0_1.f08
On 11/22/2015 01:44 PM, Steve Kargl wrote:
> On Sun, Nov 22, 2015 at 01:32:56PM -0800, Jerry DeLisle wrote:
>> This minor patch brings the leading zero to emitting floats with g0 editing
>> by
>> moving the block of code up a little before the g0 is handled. This has been
&
Another old patch I forgot about. This one is fairly self explanatory. We were
not handling pending spaces for ADVANCE_NO and T editing.
Regression tested x86-64-linux. New test case.
OK for trunk?
Jerry
2015-11-22 Jerry DeLisle
PR libfortran/52251
* io/transfer.c
On 9/23/19 8:52 AM, Bernhard Reutner-Fischer wrote:
On 22 September 2019 22:51:46 CEST, Jerry DeLisle wrote:
Hi all,
The attached patch eliminates several warnings by adjusting which
enumerator is
used in the subject offending code. I fixed this by adding an
enumerator at the
end of the
On 9/23/19 8:12 PM, Jerry DeLisle wrote:
On 9/23/19 8:52 AM, Bernhard Reutner-Fischer wrote:
On 22 September 2019 22:51:46 CEST, Jerry DeLisle wrote:
Hi all,
The attached patch eliminates several warnings by adjusting which
enumerator is
used in the subject offending code. I fixed this by
On 9/28/19 10:11 AM, Steve Kargl wrote:
Committed as r276254.
I am getting this:
gfc -c -fcoarray=single pr91802.f90
f951: internal compiler error: free_expr0(): Bad expr type
0x809fc9 gfc_report_diagnostic
../../trunk/gcc/fortran/error.c:776
0x80b62a gfc_internal_error(char const*, .
On 10/1/19 4:10 PM, Steve Kargl wrote:
The attached patch has been tested on x86_64-*-freebsd.
OK to commit?
OK Steve, thanks,
Jerry
On 10/1/19 4:46 PM, Steve Kargl wrote:
The attached patch has been tested on x86_64-*-freebsd.
OK to commmit?
OK, thanks Steve.
In a previous patch, I specialized the simplfication of
an EXPR_OP to the case of an inserted parenthesis. This
was too restrictive as evidenced by the new test ca
On 10/1/19 5:06 PM, Steve Kargl wrote:
The attached patch has been tested on x86_64-*-freebsd.
OK to commit?
Ok Steve,
Thanks,
Jerry
The patch prevents an ICE by setting the locus of an
inquiry parameter.
2019-10-01 Steven G. Kargl
Looks good Tobias, OK,
Odd about that line in set_internal_unit. Probably leftover from a
copy/paste. I see in comment #5 of the PR that you mentioned trying the
assert to make sure it is useless code.
Thanks for the patch,
Jerry
On 3/11/21 2:38 AM, Tobias Burnus wrote:
Revised version – th
Yes Ok for trunk.
Thanks much!
On 3/19/21 10:37 AM, Thomas Koenig via Fortran wrote:
Hell world,
here is the patch I talked about earlier. It passes regression testing.
OK for trunk?
Best regards
Thomas
Add size check to vector-matrix matmul.
It turns out the library version is much
Hi Tobias and others,
Reembering some of my own history, we always have used a +1 on
'LENGTH_MAX' items to allow the C null termination on strings or buffers
for obvious reasons.
Certainly OK for trunk and backports.
Regards,
Jerry
On 3/21/21 9:08 AM, Tobias Burnus wrote:
The gfc_match_se
zes.
Regards,
Jerry
On 3/27/21 6:28 AM, dhumieres.domini...@free.fr wrote:
Le 2021-03-27 06:36, Jerry DeLisle a écrit :
On 3/26/21 10:38 AM, dhumieres.dominique--- via Fortran wrote:
I have proposed a similar patch in pr95998.
I cannot commit to git!-(
Thanks
Dominique
I do not see a patch
Yes OK for trunk and affected branches.
Thanks,
Jerry
On 3/31/21 2:08 PM, Harald Anlauf via Fortran wrote:
Dear all,
the simplification of the TRANSPOSE of a zero-sized array would lead to
an ICE if the result was used in a subsequent simplification of a MATMUL.
The reason was the lack of the
Paul,
This looks OK to me for Trunk. I believe 10 is in freeze so it may have
to wait or get release manager approval.
Jerry
On 4/1/21 6:44 AM, Paul Richard Thomas via Fortran wrote:
This one is trivial. The wrong error message was transformed by my patch
for PR98897 into an ICE. This patch
Committed this as simple one liner. I will probably backport this in a few
days.
Jerry
Committed r278660
M libgfortran/ChangeLog
M libgfortran/io/transfer.c
2019-11-24 Jerry DeLisle
PR fortran/92100
io/transfer.c (data_transfer_init_worker
On 11/24/19 2:20 PM, Jerry DeLisle wrote:
Committed this as simple one liner. I will probably backport this in a few
days.
Jerry
Committed r278660
M libgfortran/ChangeLog
M libgfortran/io/transfer.c
2019-11-24 Jerry DeLisle
PR fortran/92100
io/transfer.c
11-27 Jerry DeLisle
PR fortran/90374
* io.c (check_format): Allow zero width expoenent with e0.
io/format.c (parse_format_list): Relax format checking to allow
e0 exponent specifier.
* gfortran.dg/fmt_zero_width.f90: Update test.
diff --git a/gcc/fortran/i
On 11/28/19 7:53 AM, Steve Kargl wrote:
On Thu, Nov 28, 2019 at 07:45:25AM -0800, Jerry DeLisle wrote:
+ if (u == FMT_ZERO)
+ {
+ if (!gfc_notify_std (GFC_STD_F2018,
+ "Positive exponent width requir
On 08/22/2018 01:06 PM, Janne Blomqvist wrote:
The Fortran standard specifies (e.g. F2018 7.4.3.2) that intrinsic
procedures shall treat positive and negative real zero as equivalent,
unless it is explicitly specified otherwise. For {max,min}val there
is no such explicit mention. Thus, remove c
On 08/23/2018 01:12 PM, Thomas König wrote:
Hello world,
this patch fixes a regression by correctly checking that
the innner start, step or end values of an implied do
loop do not depend on an outer loop variable.
The check was actually done before, but gfc_check_dependency
wasn't finding all r
On 08/25/2018 12:38 PM, Thomas Koenig wrote:
Hello world,
the attached patch fixes a regression where the calculation of the size
of the buffer for matmul was too small for ine special case.
Regression-tested. OK for trunk?
Regards
Thomas
OK Thomas and thanks for the fix.
Jerry
All,
The subject patch fixes the declaration for the vlist argument of the
formatted_dtio function pointer definition which currently gives a
warnings during compilation for mismatched types.
Regression tested on x86_64-pc-linux.
OK for trunk?
Regards,
Jerry
2018-09-01 Jerry DeLisle
On 09/02/2018 04:49 AM, Thomas Koenig wrote:
Hi Jerry,
The subject patch fixes the declaration for the vlist argument of the
formatted_dtio function pointer definition which currently gives a
warnings during compilation for mismatched types.
Regression tested on x86_64-pc-linux.
OK for tr
the 'mod' patch.
If no objections, later today I will commit with the test case.
Regards,
Jerry
2018-09-03 Jerry DeLisle
* simplify.c (gfc_simplify_modulo): Re-arrange code to test
whether 'P' is zero and issue an error if it is.
diff --git a/gcc/fort
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
PR
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 m
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
+++ trunk/gcc/fortran
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 th
-27 Jerry DeLisle
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/fortran/trans-stmt.c
+++ b/gcc/fort
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 does not create a large
>>>
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.
>
> Regt
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
PR libgfortran/78549
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
view=rev
Log:
2017-12-02 Jerry DeLisle
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 internal unit
initial
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
Dominique d'Humieres
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?
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 transfo
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
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
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
PR libgfortran/81937
* io/list_read.c (next_char_internal): Don't attem
1 - 100 of 561 matches
Mail list logo
