Looks Ok by me.
Thanks,
Jerry
On Fri, Jan 17, 2025, 12:25 PM Harald Anlauf wrote:
> Dear all,
>
> the attached obvious patch extends G formatting to UNSIGNED by reusing
> the code for I formatting.
>
> Regtested on x86_64-pc-linux-gnu. OK for mainline?
>
> Thanks,
> Harald
>
>
I got as far as applying and regression testing version 2. I have queried
around for others to look over the patch. I will scan this one.
Since you are the expert in this area, we may just have you push and let
the pieces fall out.
I will get back to you later today.
Jerry
On Fri, Dec 20, 2024,
Thanks Paul.
Regards, Jerry
On Tue, Dec 17, 2024, 12:34 AM Paul Richard Thomas <
paul.richard.tho...@gmail.com> wrote:
> Hi All,
>
> This bug was so obviously in defiance of the standard that I pushed it to
> mainline as r15-6260. I meant to post this message immediately but was
> distracted bef
Looks good, OK to push.
On Sun, Dec 8, 2024, 1:39 PM Harald Anlauf wrote:
> Dear all,
>
> while looking at testcases with inquiry refs, I encountered two minor
> GMP memleaks due to double-initialization of GMP variables. Easily
> plugged by the attached patch.
>
> Regtested on x86_64-pc-linux-
Thanks Paul, got it.
On Mon, Nov 25, 2024, 3:13 AM Paul Richard Thomas <
paul.richard.tho...@gmail.com> wrote:
> Hi Jerry,
>
> OK by me.
>
> A small nit: s/too/to/ in the ChangeLog.
>
> Thanks for the patch
>
> Paul
>
>
> On Mon, 25 Nov 2024 at 02:50, Jerry D wrote:
>
>> I would like to commit t
Good to go.
On Fri, Oct 11, 2024, 9:06 AM Thomas Koenig wrote:
> Am 11.10.24 um 18:00 schrieb Thomas Koenig:
> > Hello world,
> >
> > the attached patch creates an unsigned "standard" for the
> > gfc_option.allow_std field.
> >
> > One of the main reason why people want UNSIGNED for Fortran is
>
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
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
Committed as obvious:
commit 061b13ed014ba0b6891800a5c7f852bf58e4d856
Author: Jerry DeLisle
Date: Thu Feb 16 18:13:56 2023 -0800
Fortran Tests: Allow passing on mingw.
gcc/testsuite/ChangeLog:
* gfortran.dg/bind_c_array_params_2.f90: Add *-*-ming* to
dg-final.
and
Attached patch fixes this problem by allowing the namespace pointer to
be set correctly regardless of error condition.
Regression tested on x86_64_linux_gnu.
OK for trunk and backports?
Regards,
Jerry
Author: Jerry DeLisle
Date: Sat Jan 28 20:00:34 2023 -0800
ICE in
Hi all,
Similar to a patch I committed a while ago for Cygwin, the attached
patch allows it to pass on the mingw version of gfortran.
It is trivial.
Ok for trunk?
Regards,
Jerrydiff --git a/gcc/testsuite/gfortran.dg/bind_c_array_params_2.f90 b/gcc/testsuite/gfortran.dg/bind_c_array_params_2.f9
The attached patch was provided by Steve Kargl. After exploring for
possible other checks I settled on leaving the patch intact.
Two existing test cases updated as different but sensible error messages
resulted.
Regression tested on main line.
OK to commit?
Regards,
Jerry
Author: Steve Kargl
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
-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
Looks good and I have tested. I will commit after one more double check
for regressions with the test case in the testsuite
I have been following Harris on this one for several days and tested the
patch before submitted here.
Thanks for patch Harris, much appreciated.
Regards,
Jerry
On 1/1
LGTM Paul, go for it.
On 12/26/20 8:37 AM, Paul Richard Thomas via Fortran wrote:
Ping!
On Sat, 12 Dec 2020 at 10:38, Paul Richard Thomas <
paul.richard.tho...@gmail.com> wrote:
Fortran: Fix some select rank issues [PR97694 and 97723].
Hi All,
Unlike select type, select rank selectors retai
Harold, Looks good. Thanks for the work!
Jerry
On 9/20/20 11:10 AM, Harald Anlauf wrote:
*ping*
Gesendet: Sonntag, 13. September 2020 um 23:24 Uhr
Von: "Harald Anlauf"
An: "fortran" , "gcc-patches"
Cc: "Paul Richard Thomas"
Betreff: [PATCH] PR fortran/90903 [part2] Add runtime checking for
ok, thanks .
On 9/15/20 1:35 PM, Harald Anlauf wrote:
As stated in the PR, the Fortran 2018 standard removed the restriction
prohibiting ELEMENTAL RECURSIVE procedures. Adjust the relevant check.
Regtested on x86_64-pc-linux-gnu.
OK for master?
Thanks,
Harald
PR fortran/97036 - [F2018] All
On 8/17/20 12:31 AM, Mark Eggleston wrote:
Please find attached a patch for PR96436.
OK to commit?
Looks good to me. Thanks for fixing this.
Regards,
Jerry
This look good, OK to commit.
Thanks,
Jerry
On 8/10/20 8:03 AM, Andre Vehreschild wrote:
Hi folks,
long time, no see. I was asked by Damian to do some Coarray stuff in gfortran
so here is the first step on fixing a bug. The issue at hand is, that the
coarray handling is not propagated correc
OK to commit and Backport.
On 6/18/20 1:11 AM, Mark Eggleston wrote:
Please find attached fix for PR95585.
OK to commit and backport?
Commit message:
Fortran : ICE in gfc_check_reshape PR95585
Issue an error where an array is used before its definition
instead of an ICE.
2020-06-18 Steven
OK to commit and backport.
On 6/30/20 11:12 PM, Mark Eggleston wrote:
Please find attached a patch which is a fix for PR95612. The original
patch is by Steve Kargl.
OK to commit and backport?
Commit message:
Fortran : ICE in gfc_check_pointer_assign PR95612
Output an error if the right ha
On 6/27/20 1:40 AM, Thomas Koenig via Fortran wrote:
Hi Mark,
Use -fdec-add-missing-indexes to enable feature. Also enabled by fdec.
A warning that the lower bound is being used for a mission dimension
is output unless suppressed by using -Wno-missing-index.
This is... seriously problemati
OK, and once again, thanks.
Jerry
On 6/17/20 12:27 PM, Harald Anlauf wrote:
Another corner case of buffer overflows during name mangling found by
Gerhard. We now check that the new buffer sizes suffice.
The patch is on top of the patches for PRs 95687, 95688, 95689.
Regtested on x86_64-pc-lin
OK, and thanks for Patch.
On 6/23/20 2:08 PM, Harald Anlauf wrote:
Dear all,
here's another case with a buffer that did overflow.
Regtested on x86_64-pc-linux-gnu.
OK for master / backports?
Thanks,
Harald
PR fortran/95827 - Buffer overflows with PDTs and long symbols
With submodules and
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
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/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
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/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
?
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 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
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 4:10 PM, Steve Kargl wrote:
The attached patch has been tested on x86_64-*-freebsd.
OK to commit?
OK Steve, thanks,
Jerry
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 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/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
statements. I cleared those by
throwing in an assert (false) since it cant happen unless something really goes
wrong somehow.
Regardless, regression tested on x86_64-pc-linux-gnu.
OK for trunk? No applicable test case.
Jerry
2019-09-22 Jerry DeLisle
PR libfortran/91593
* io
On 7/17/19 8:32 PM, Steve Kargl wrote:
I will be away until Monday. Plenty of time for a review.
---snip --
Something not quite right here in this comment.
+/* A BOZ literal constant can appear in a limited number of contexts.
+ gfc_invalid_boz() is a help function to simplify error/war
Could not get the use of gfc_get_errors to work right, it missed one of the
errors in initialazation_30.f90. So I just did the deed.
Regards,
Jerry
Committing to svn+ssh://jvdeli...@gcc.gnu.org/svn/gcc/trunk ...
A gcc/testsuite/gfortran.dg/initialization_30.f90
M gc
the job.
Also modified one test case and added a new to cover this in the testsuite.
Regression tested on x86_64-pc-linux-gnu.
OK for trunk?
Regards,
Jerry
2019-07-13 Jerry DeLisle
PR fortran/87233
* expr.c (check_restricted): Relax constraint C1279 which was
remo
On 6/22/19 11:32 AM, Steve Kargl wrote:
On Sat, Jun 22, 2019 at 11:23:48AM -0700, Jerry DeLisle wrote:
2019-06-22 Jerry DeLisle
PR fortran/89782
* io.c (gfc_resolve_dt): Check that internal units are not
character PARAMETER.
This part of the patch is missing
. Regression tested on
x86_64-pc-linux-gnu.
OK for trunk?
Regards,
Jerry
2019-06-22 Jerry DeLisle
PR fortran/89782
* io.c (gfc_resolve_dt): Check that internal units are not
character PARAMETER.
* gfortran.dg/io_constraints.f90: New test.
! { dg-do compile
I will see if I can get this one.
On 6/17/19 6:37 AM, Mark Eggleston wrote:
On 12/06/2019 19:11, Steve Kargl wrote:
On Tue, Jun 11, 2019 at 11:50:40AM +0200, Jakub Jelinek wrote:
On Tue, Jun 11, 2019 at 10:30:59AM +0100, Mark Eggleston wrote:
Jim MacArthur
Mark Eggleston
Two spa
On 6/14/19 3:56 PM, Steve Kargl wrote:
I have had this patch in my tree since the beginning of May.
During constant folding, gfortran would not issue an error
for overflow for integer exponentation. Bootstrapped
and regression tested multiple times on x86_64-*-freebsd?
OK to commit?
2019-06-15
On 5/17/19 12:33 PM, Janne Blomqvist wrote:
--- snip ---
And yes, while I think one year might be a quite optimistic timeframe
to get this fixed, I agree we shouldn't keep the workaround
indefinitely either. I think the best way would be if CBLAS & LAPACKE
would be fixed, and then we could tell
On 5/17/19 10:48 AM, Jeff Law wrote:
On 5/16/19 2:09 AM, Jakub Jelinek wrote:
Hi!
Fortran subroutines/functions that have CHARACTER arguments have also
hidden arguments at the end of the argument list which hold the string
length. This is something all Fortran compilers I've tried do and is
do
On 2/28/19 12:14 PM, Thomas Koenig wrote:
Hello world,
the attached patch fixes a wrong-code bug for gfortran where pointers
were not marked as escaping. A C_PTR can be stashed away and reused
later (at least as long as the variable it points to remains active).
This is not a regression, but I
On 3/9/19 4:44 AM, Thomas König wrote:
Hello world,
the attached patch fixes the rest of PR 71203 (i.e. the non-character
parts). I have checked in gdb that the shape set with this patch
does indeed not create a memory leak.
Regression-tested. OK for trunk?
(This makes three patches that are c
This patch is simple and obvious.
Regression tested on x86_64-pc-linux-gnu.
Test case attached. (Changelog for test case will be included)
I will commit tomorrow.
Regards,
Jerry
2019-02-23 Jerry DeLisle
PR fortran/84387
* trans-io.c (transfer_expr): Do not return if there
On 2/20/19 2:34 PM, Harald Anlauf wrote:
There was a rather obvious bug in the logic for checking the arguments
to the OPEN statement when NEWUNIT= was specified, which prohibited
the generation of the appropriate error message.
Regtested successfully.
OK for trunk?
Yes and thanks for patch.
On 2/13/19 2:38 PM, Harald Anlauf wrote:
The attached patch moves the check for labeled DO statements to
the place where a label is referenced instead of where a label
was defined, which lead to false positives.
Regtested on x86_64-pc-linux-gnu.
OK for trunk?
Thanks Harald,
All OK with test
On 2/12/19 10:22 PM, Martin Liška wrote:
PING^1.
On 2/4/19 1:46 PM, Martin Liška wrote:
On 2/4/19 10:56 AM, Martin Liška wrote:
Hi.
Starting from r266926 'switch (e->value.op.op)' is reached when
one using -fdec. That's wrong as -fdec causes to create a e->value.function.
I hope the proper fi
The attached patch is straight-forward and self explanatory.
Regression tested on x86-64-pc-linux-gnu. Test case attached.
OK for trunk?
2019-01-31 Jerry DeLisle
PR fortran/52564
* io.c (match_io): Add check for comma after '*' without subsequent
IO l
On 1/27/19 1:13 AM, Janne Blomqvist wrote:
On Sat, Jan 26, 2019 at 10:42 PM Jerry DeLisle
--- snip ---
Checking remove() for an error is a good idea, although speculating why
that happened might be confusing if the error happens for some other
reason? Particularly so on POSIX systems, where
Committed as simple and obvious. (With a ChangeLog Bobble fixed)
Regression tested on x86_64.
Committed r268301
M libgfortran/ChangeLog
M libgfortran/io/close.c
Regards,
Jerry
2019-01-26 Jerry DeLisle
PR libfortran/89020
* io/close.c (st_close
On 1/19/19 7:05 AM, Thomas Koenig wrote:
Hello world,
the attached patch fixes handling of contiguous dummy arguments when
the actual arguments are not contiguous.
The patch to trans-expr.c itself was written by Paul and attached to
the PR. I just added the test case. Regression-testing reveal
On 1/12/19 2:35 PM, Jerry DeLisle wrote:
Hi all,
As stated in the PR, the problem turns out to be an ungraceful return
after an error. Most namelist errors go through nml_err_ret, The one I
am removing did not and in the unique case of UNIT=5 after the error it
falls through and hits some
namelist
data structures.
This patch fixes it.
Regression tested on x86-64 and manually tested with a redirection to
stdin. (cat somefile | ./a.out )
I plan to commit today as simple along with a new testcase.
Regards.
Jerry
2019-01-12 Jerry DeLisle
PR libfortran/88776
* io
On 12/28/18 10:44 AM, Steve Kargl wrote:
Ping.
OK, thanks.
Jerry
On Tue, Dec 25, 2018 at 02:36:40PM -0800, Steve Kargl wrote:
Fortran 2018 has added IEEE_SUBNORMAL, IEEE_POSITIVE_SUBNORMAL, and
IEEE_NEGATIVE_SUBNORMAL as counterparts the same features with the
DENORMAL name. The attached p
OK Steve,
Jerry
On 12/28/18 10:43 AM, Steve Kargl wrote:
Ping.
On Tue, Dec 25, 2018 at 01:44:10PM -0800, Steve Kargl wrote:
Here's a Holiday present for Fortranners.
2018-12-25 Steven G. Kargl
* cpp.c (gfc_cpp_init): Add pre-defined macros for INTEGER(1)
INTEGER(2), INTE
On 12/28/18 10:43 AM, Steve Kargl wrote:
Ping.
On Mon, Dec 24, 2018 at 11:59:50AM -0800, Steve Kargl wrote:
All,
The IEEE modules and -ffpe-trap are to some extent orthogonal
features of gfortran. Unfortunately, some users have the
expectation of using -ffpe-trap for debugging while also usin
On 12/23/18 10:49 AM, Steve Kargl wrote:
This is a re-submission of a patch I submitted 15 months ago.
See https://gcc.gnu.org/ml/fortran/2017-09/msg00124.html
At that time one reviewer OK'd the patch for committing,
and one reviewer raised objections to the patch as I
chose to remove dubious ex
On 12/9/18 8:11 AM, Thomas Koenig wrote:
Hello world,
the attached patch fixes the wrong-code regression by changing the
way synchronous writes are handled on files using asynchronous I/O:
The are now handled synchronously.
This also means that two places where a wait instruction was
issued in
On 12/6/18 2:33 AM, Jakub Jelinek wrote:
On Wed, Dec 05, 2018 at 06:27:00PM -0800, Jerry DeLisle wrote:
I disagree completely. I assume the idea of -fdec-pad-with-spaces is to
accomodate some old dec fortran code. The only reason to use some other
character is if someone is writing new dec
On 12/4/18 9:04 AM, Fritz Reese wrote:
On Tue, Dec 4, 2018 at 10:12 AM Jakub Jelinek wrote:
Just a couple of random comments.
-fdec-pad-with-spaces option name doesn't look right, because it doesn't say
what the option affects. So perhaps have transfer in the option name?
[...]
Wouldn't it
On 11/29/18 11:37 PM, Janne Blomqvist wrote:
PING!
LGTM,
OK and thanks
Jerry
(for the GCC-7 branch, I'll commit it after the 7.4 release)
On Thu, Nov 22, 2018 at 11:17 AM Janne Blomqvist
wrote:
From backtrace.h for backtrace_create_state:
Calling this function allocates resources
On 11/24/18 2:51 PM, Dominique d'Humières wrote:
Hi Jerry,
OK for trunk?
Could you give me some time to post some comments in bugzilla?
Sure, no rush.
TIA
Dominique
change log for the testsuite.)
Jerry
2018-11-24 Jerry DeLisle
PR libfortran/88052
* io/format.c (parse_format_list): Implement constraint which prohibits
missing commas between format specifiers unless -std=legacy is given.
diff --git a/gcc/testsuite/gfortran.dg/comma_format_extension_4.f
On 11/22/18 11:43 AM, Jakub Jelinek wrote:
On Thu, Nov 22, 2018 at 11:00:13AM +0100, Jakub Jelinek wrote:
Ok for trunk if it passes bootstrap/regtest (so far just checked with
make check-gfortran RUNTESTFLAGS='dg.exp=pad_source*'
)?
Note, it passed bootstrap/regtest on x86_64-linux.
OK, and
On 11/11/18 7:59 AM, Thomas Koenig wrote:
Hello world,
the attached patch fixes both ICEs in the PR by adding some tests.
It was necessary to shuffle around a bit of code, plus to make sure that
double error reporting did not become too bad.
Regression-tested. OK for trunk?
Regards
Thoma
Committed as obvious. I had inserted this line to check effects of the
-fdec flags and forgot to delete it before my previous commit.
Author: jvdelisle
Date: Fri Nov 9 17:29:33 2018
New Revision: 265979
URL: https://gcc.gnu.org/viewcvs?rev=265979&root=gcc&view=rev
Log:
2018-11-0
On 11/4/18 1:51 AM, Bernhard Reutner-Fischer wrote:
On Sat, 3 Nov 2018 15:33:07 -0700
Jerry DeLisle wrote:
diff --git a/libgfortran/io/transfer.c b/libgfortran/io/transfer.c
index 31198a3cc39..0d26101cef0 100644
--- a/libgfortran/io/transfer.c
+++ b/libgfortran/io/transfer.c
@@ -260,22
ck in early versions so should probably go to 7
and 8 branches. Opinions welcome.
Regards,
Jerry
2018-11-04 Jerry DeLisle
* io/transfer.c (read_sf_internal): Add support for early
comma termination of internal unit formatted reads.
diff --git a/libgfortran/io/transfe
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 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
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,
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
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.
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
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.
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
1 - 100 of 561 matches
Mail list logo
