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
I have reviewed this and all looks good.
I also regression tested on x86_64-pc-linux-gnu.
I don't want to do a bunch of individual commits.
Steve, if you can do a ChangeLog I can commit in one blast.
Regards,
Jerry
On 3/13/21 1:33 PM, Steve Kargl via Fortran wrote:
The following patch fixes
excess errors)
FAIL: gfortran.dg/pr96025.f90 -O (internal compiler error)
FAIL: gfortran.dg/pr96025.f90 -O (test for errors, line 5)
FAIL: gfortran.dg/pr96025.f90 -O (test for excess errors)
On 3/13/21 8:46 PM, Jerry DeLisle wrote:
I have reviewed this and all looks good.
I also
urnus wrote:
On 14.03.21 06:13, Jerry DeLisle wrote:
Well, I am seeing the falling upon a closer look. I do not know if
related to the patch yet. Lets make sure this is fixed.
FAIL: gfortran.dg/pr87907.f90 -O (internal compiler error)
FAIL: gfortran.dg/pr87907.f90 -O (test for excess e
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
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 in 95998. Do you need help to do a commit?
Jerry
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
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
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
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
On Fri, Apr 26, 2024, 2:47 AM Tobias Burnus wrote:
> Hi Bernhard, hello all,
> Bernhard Reutner-Fischer wrote:
>
> PS: unfortunately the git branch
> (https://gcc.gnu.org/git/?p=gcc.git;a=log;h=refs/heads/aldot/fortran-fe-stringpool
> ) mentioned in mail (I) lived in the old git, before we swit
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 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
Hi all,
I spotted this today on the Fortran-Lang Discourse.
It would not be setting precednce for us to allow an extension and turn
this into a warning with -std=gnu and an error of strict compliance is
wanted.
https://fortran-lang.discourse.group/t/error-the-leftmost-part-ref-in-a-data-ref-cann
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
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
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
Hi all,
I found this message in my spam folder tonight.
Please look. I also sent a note to Damian on this.
Maybe we can get someone to push forward on te native coarrays work?
Other thoughts?
Jerry
Hello all,
As of today the free hosting of our MatterMost workspace is ended. The
MatterMost cloud service organization decided to end free accounts.
Fortunately, the platform is Open Source and we owe a tremendous
gratitude to the Oregon State University Open Software Lab (OSUOSL)for
providi
23 matches
Mail list logo