On 10/11/23 12:39 PM, Harald Anlauf wrote:
Dear All,
the attached trivial patch fixes (= catches) a forgotten corner-case
in the detection of a name conflict between an internal procedure and
a local declaration for the case that the latter is a derived type.
Another torture test by Gerhard... ;
On 10/11/23 12:44 PM, Harald Anlauf wrote:
Dear All,
sorry for attaching the wrong patch - this time it is the correct one!
Harald
On 10/11/23 21:39, Harald Anlauf wrote:
Dear All,
the attached trivial patch fixes (= catches) a forgotten corner-case
in the detection of a name conflict betwee
On 10/16/23 12:11 PM, Harald Anlauf wrote:
Dear All,
the attached patch fixes a dependency check in frontend optimzation
for nested implied-do IO. The problem appeared for >= 3 loops only
as the check considered dependencies to be only of band form instead
of triangular form.
Regtested on x86_
On 11/16/23 5:01 AM, Tobias Burnus wrote:
This adds -std=f2023, which is mostly a prep patch for future changes.
However, Fortran 2023, https://j3-fortran.org/doc/year/23/23-007r1.pdf
changes two things which is taken
care in this patch:
(A) In "6.3.2.1 Free form line length":
Fortran 2018:
On 12/6/23 8:09 AM, Paul Richard Thomas wrote:
Dear All,
This patch was rescued from my ill-fated and long winded attempt to
provide a fix-up for function selector references, where the function is
parsed after the procedure containing the associate/select type
construct (PRs 89645 and 99065)
I am getting this failure to build from clean trunk.
In file included from ../../../../trunk/libgomp/config/linux/allocator.c:31:
../../../../trunk/libgomp/config/linux/allocator.c: In function
‘linux_memspace_alloc’:
../../../../trunk/libgomp/config/linux/allocator.c:70:26: error: format
‘%ld’
The following has been committed per discussion in the subject PR.
commit 95b70545331764c85079a1d0e1e19b605bda1456 (HEAD -> master,
origin/master, origin/HEAD)
Author: Jerry DeLisle
Date: Wed Dec 13 19:04:50 2023 -0800
fortran: Add degree based trig functions for F2023
PR f
The subject server hosted by the OSU Open Software Lab is being upgraded
to the latest LTS version of MatterMost (8.1). There may be some
interruptions of service.
I will send out a notice when this gets completed.
Thanks to the folks at OSU for their support.
Regards,
Jerry
On 12/19/23 12:02 AM, FX Coudert wrote:
When gfortran invokes the linker, it reads the linking spec from libgfortran.
This ends up doing things like:
-lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
where you can see that libgcc (both -lgcc and -lgcc_s) is linked in twice. This
wasn’t a problem, until the
On 12/19/23 1:10 PM, FX Coudert wrote:
Hi,
I am getting side notes about people having these issues with gfortran 13. Is
this something that should be backported.
I have already backported it in the latest Homebrew package (because we have
many users complaining about it). I intend to backp
On 1/3/24 3:12 AM, Tobias Burnus wrote:
On 22.12.23 03:36, Lipeng Zhu wrote:
This patch try to fix the bug when HAVE_ATOMIC_FETCH_ADD is
not defined in dec_waiting_unlocked function.
libgfortran/ChangeLog:
* io/io.h (dec_waiting_unlocked): Use
__gthread_rwlock_wrlock/__gthread_rwlo
Committed as simple and obvious. Initial patch thanks to Steve.
When using git gcc-commit-mklog how does one add in the coauthor?
The master branch has been updated by Jerry DeLisle :
https://gcc.gnu.org/g:add995ec117d756e61d207041cd32f937c1a1cd9
commit r14-6986-gadd995ec117d756e61d207041cd32f
On 1/7/24 1:34 PM, Harald Anlauf wrote:
Dear all,
the attached, actually rather obvious patch fixes an issue when
an optional dummy with the value attribute was passed as DIM
argument to the SIZE intrinsic. Instead of some hand-crafted,
incomplete presence check for the argument, it makes more
On 1/20/24 10:46 AM, Alexander Westbrooks wrote:
Hello and Happy New Year!
I wanted to follow up on this patch I made to address PR82943 for
GFortran. Has anyone had a chance to review it?
Thanks,
Alexander Westbrooks
Inserting myself in here just a little bit. I will apply and test toda
On 1/20/24 11:08 AM, Jerry D wrote:
On 1/20/24 10:46 AM, Alexander Westbrooks wrote:
Hello and Happy New Year!
I wanted to follow up on this patch I made to address PR82943 for
GFortran. Has anyone had a chance to review it?
Thanks,
Alexander Westbrooks
Inserting myself in here just a
On 1/20/24 12:08 PM, Harald Anlauf wrote:
Am 20.01.24 um 20:08 schrieb Jerry D:
On 1/20/24 10:46 AM, Alexander Westbrooks wrote:
Hello and Happy New Year!
I wanted to follow up on this patch I made to address PR82943 for
GFortran. Has anyone had a chance to review it?
Thanks,
Alexander
The attached patch attempts to fix the handling of the EN0.0E0 and
ES0.0E0 formatting by correctly calculating the number of digits needed
for the exponents and building those exponents into the float string.
My editor judiciously deleted trailing blank spaces in a number of
places. I apologi
On 1/30/24 12:36 PM, Harald Anlauf wrote:
Hi Jerry,
Am 30.01.24 um 19:15 schrieb Jerry D:
The attached patch attempts to fix the handling of the EN0.0E0 and
ES0.0E0 formatting by correctly calculating the number of digits needed
for the exponents and building those exponents into the float
On 1/30/24 12:36 PM, Harald Anlauf wrote:
Hi Jerry,
Am 30.01.24 um 19:15 schrieb Jerry D:
The attached patch attempts to fix the handling of the EN0.0E0 and
ES0.0E0 formatting by correctly calculating the number of digits needed
for the exponents and building those exponents into the float
On 1/30/24 12:36 PM, Harald Anlauf wrote:
Hi Jerry,
Am 30.01.24 um 19:15 schrieb Jerry D:
The attached patch attempts to fix the handling of the EN0.0E0 and
ES0.0E0 formatting by correctly calculating the number of digits needed
for the exponents and building those exponents into the float
On 2/4/24 3:31 AM, Anuj Mohite wrote:
Dear Fortran GCC developers,
I am Anuj, a Computer Science student from India. I am interested in
contributing to the Fortran frontend for GCC during GSoC 2024.
I got to know about this through the Martin J and GCC IRC channel. My
background is in C/C+
On 2/7/24 6:20 PM, Aranda Luna, Suzan wrote:
Hello, I need to use a package called "pytmatrix" and for that I have to
use, numpy, scipy and gfortran...the instructions says to use:
|install gfortran python-numpy python-scipy|
but I cant get it...someone has experience using gfortran in python?
On 2/8/24 1:03 PM, Harald Anlauf wrote:
Dear all,
the attached patch improves error recovery when we encounter an
array constructor where a unary operator (e.g. minus) is applied
and -frange-check is active. The solution is not to terminate
early in that case to avoid inconsistencies between ch
The attached patch fixes this PR by properly adjusting some variables
When using stream io. See log below. New test case included.
Regression tested on x86_64.
OK for trunk and backport?
Regards,
Jerry
ChangeLog:
libgfortran: Adjust bytes_left and pos for access="STREAM".
During tab
Pushed as simple and obvious.
Regards,
Jerry
commit 8221201cc59870579b9dc451b173f94b8d8b0993 (HEAD -> master,
origin/master, origin/HEAD)
Author: Steve Kargl
Date: Wed Feb 14 14:40:16 2024 -0800
Fortran: namelist-object-name renaming.
PR fortran/105847
gcc/fortran/Ch
On 2/16/24 1:40 PM, Harald Anlauf wrote:
Dear all,
this patch fixes a regression which was a side-effect of r14-8947,
losing the length of a deferred-length character variable when
passed as a dummy.
The new testcase provides a workout for deferred length to improve
coverage in the testsuite.
The attached patch fixes this one. Se the ChangeLog below for explanation.
OK for trunk?
I think simple enough to backport to 13 as well.
Regards,
Jerry
Author: Jerry DeLisle
Date: Fri Feb 16 17:06:37 2024 -0800
libgfortran: Fix namelist read.
PR libgfortran/107068
l
Hello,
I posted the attached patch in bugzilla some time ago. This includes a
new test case. The patch adds additional checks in key places to catch
eroneous use of semicolons
Regression tested on x86_64,
OK for trunk and later backport to 13?
Jerrydiff --git a/gcc/testsuite/gfortran.dg/pr1
On 2/21/24 10:30 AM, Steve Kargl wrote:
I have attached a patch to PR114024, see
https://gcc.gnu.org/pipermail/gcc-bugs/2024-February/854651.html
The patch contains a new testcase and passes regression
testing on x86_64-*-freebsd. Could someone castr an eye
over the patch and commit it?
Hi
On 2/21/24 12:28 PM, Harald Anlauf wrote:
On 2/21/24 20:41, Jerry D wrote:
On 2/21/24 10:30 AM, Steve Kargl wrote:
I have attached a patch to PR114024, see
https://gcc.gnu.org/pipermail/gcc-bugs/2024-February/854651.html
The patch contains a new testcase and passes regression
testing on
Hi all,
The attached fix adds a check for an error condition from a UDDTIO
procedure in the case where there is no actual underlying error, but the
user defines an error by setting the iostat variable manually before
returning to the parent READ.
I did not address the case of a formatted WRI
On 2/25/24 12:34 PM, Harald Anlauf wrote:
Hi Jerry,
On 2/22/24 20:11, Jerry D wrote:
Hi all,
The attached fix adds a check for an error condition from a UDDTIO
procedure in the case where there is no actual underlying error, but the
user defines an error by setting the iostat variable
On 2/25/24 12:26 PM, Harald Anlauf wrote:
Dear all,
the attached simple patch fixes an issue where we evaluated
polymorphic functions twice in assignments: once for the _data
component, and once for the _vptr. Using save_expr prevents
the double evaluation.
Regtested on x86_64-pc-linux-gnu. O
On 2/27/24 1:00 PM, Harald Anlauf wrote:
Dear all,
the attached patch fixes invalid Fortran in testcase
gfortran.dg/pr101026.f, which might prohibit progress
in fixing pr111781. (Note that the testcase was for a
tree-optimizer issue, not the Fortran frontend.)
OK for mainline?
Will commit wit
The attached patch adds the error checks similar to the first patch
previously committed.
I noticed a redundancy in some defines MSGLEN and IOMSG_LEN so I
consolidated this to one define in io.h. This is just cleanup stuff.
I have added test cases for each of the places where UDTIO is done in
On 2/29/24 1:47 AM, Bernhard Reutner-Fischer wrote:
On Wed, 28 Feb 2024 21:29:06 -0800
Jerry D wrote:
The attached patch adds the error checks similar to the first patch
previously committed.
I noticed a redundancy in some defines MSGLEN and IOMSG_LEN so I
consolidated this to one define in
On 2/29/24 10:13 AM, Steve Kargl wrote:
On Thu, Feb 29, 2024 at 09:36:43AM -0800, Jerry D wrote:
On 2/29/24 1:47 AM, Bernhard Reutner-Fischer wrote:
And, just for my own education, the length limitation of iomsg to 255
chars is not backed by the standard AFAICS, right? It's jus
On 2/29/24 12:56 PM, Steve Kargl wrote:
On Thu, Feb 29, 2024 at 10:28:19AM -0800, Jerry D wrote:
On 2/29/24 10:13 AM, Steve Kargl wrote:
On Thu, Feb 29, 2024 at 09:36:43AM -0800, Jerry D wrote:
On 2/29/24 1:47 AM, Bernhard Reutner-Fischer wrote:
And, just for my own education, the length
On 2/29/24 12:56 PM, Harald Anlauf wrote:
Dear all,
here's a first patch addressing issues with NULL as actual argument:
if the dummy is assumed-rank or assumed length, MOLD shall be present.
There is also an interp on interoperability of c_sizeof and NULL
pointers, for which we have a partiall
On 3/1/24 11:24 AM, rep.dot@gmail.com wrote:
Hi Jerry and Steve,
On 29 February 2024 19:28:19 CET, Jerry D wrote:
On 2/29/24 10:13 AM, Steve Kargl wrote:
On Thu, Feb 29, 2024 at 09:36:43AM -0800, Jerry D wrote:
On 2/29/24 1:47 AM, Bernhard Reutner-Fischer wrote:
And, just for my own
EN, child_iomsg)
+ 1;
free_line (dtp);
snprintf (message, child_iomsg_len, child_iomsg);
generate_error (&dtp->common, dtp->u.p.child_saved_iostat,
plus several more. Wouldn't it be better to increase the size of
message by one?
Thanks,
Harald
On 3/5/24
On 3/6/24 9:13 AM, Harald Anlauf wrote:
Hi Jerry,
can you please replace the user message in e.g. your new testcase
pr105456-wf.f90 by say:
piomsg="The users message containing % and %% and %s and other stuff"
This behaves as expected with Intel, but dies horribly with gfortran
after your patc
On 3/6/24 9:13 AM, Harald Anlauf wrote:
"The users message containing % and %% and %s and other stuff"
I see what you mean. our standard error messages are expecting values in
these places and since none are there, fault.
Should we simply output "The users message containing % and %% and %s
On 3/6/24 9:13 AM, Harald Anlauf wrote:
Hi Jerry,
can you please replace the user message in e.g. your new testcase
pr105456-wf.f90 by say:
piomsg="The users message containing % and %% and %s and other stuff"
This behaves as expected with Intel, but dies horribly with gfortran
after your patc
On 3/24/24 1:19 PM, Harald Anlauf wrote:
Dear all,
I noticed by chance that we have quite a lot of improperly specified do-do
directives in the testsuite.
% grep "dg-do run" gcc/testsuite/gfortran.dg/ -rl|wc -l
83
Note that with two blanks instead of just one a testcase does not get executed.
On 3/24/24 1:19 PM, Harald Anlauf wrote:
Dear all,
I noticed by chance that we have quite a lot of improperly specified do-do
directives in the testsuite.
% grep "dg-do run" gcc/testsuite/gfortran.dg/ -rl|wc -l
83
Note that with two blanks instead of just one a testcase does not get executed.
On 3/25/24 1:27 AM, Manfred Schwarb wrote:
Am 25.03.24 um 05:53 schrieb Jerry D:
On 3/24/24 1:19 PM, Harald Anlauf wrote:
Dear all,
I noticed by chance that we have quite a lot of improperly specified do-do
directives in the testsuite.
% grep "dg-do run" gcc/testsuite/gfortran.dg/
On 3/25/24 12:53 PM, Harald Anlauf wrote:
I noticed by chance that we have quite a lot of improperly specified do-do
directives in the testsuite.
% grep "dg-do run" gcc/testsuite/gfortran.dg/ -rl|wc -l
83
I think this is on purpose.
The idea to use a "feature" in dejagnu to only iterate once
On 3/25/24 3:30 PM, Harald Anlauf wrote:
On 3/25/24 12:53 PM, Harald Anlauf wrote:
I noticed by chance that we have quite a lot of improperly specified do-do
directives in the testsuite.
% grep "dg-do run" gcc/testsuite/gfortran.dg/ -rl|wc -l
83
I think this is on purpose.
The idea to use a
Hi all,
There has been a bit of discussio on which way to go on this.
I took a look today and this trivial patch gives the behavior concluded
on Fortran Discourse. See the bugzilla for all the relevant information.
Regresion tested on x86-64.
I will do the appropriate changelog.
OK for trun
On 3/27/24 1:42 PM, Harald Anlauf wrote:
Dear all,
the attached patch fixes a 10+ regression for cases where a
derived type with a pointer component is used in a DATA statement.
The failure looked obscure, see testcase comments, and pointed
to a possible issue in the resolution (order). For the
On 4/1/24 11:46 PM, Andrew Pinski wrote:
On Sun, Mar 24, 2024 at 1:19 PM Harald Anlauf wrote:
Dear all,
I noticed by chance that we have quite a lot of improperly specified do-do
directives in the testsuite.
% grep "dg-do run" gcc/testsuite/gfortran.dg/ -rl|wc -l
83
Note that with two blan
Hi all,
The attached log entry and patch (git show) fixes this issue by adding
logic to handle spaces in eat_separators. One or more spaces by
themselves are a valid separator. So in this case we look at the
character following the spaces to see if it is a comma or semicolon.
If so, I change
On 4/4/24 2:31 AM, Tobias Burnus wrote:
Hi Jerry,
Jerry D wrote:
The attached log entry and patch (git show) fixes this issue by adding
logic to handle spaces in eat_separators. One or more spaces by
themselves are a valid separator. So in this case we look at the
character following the
On 4/4/24 2:31 AM, Tobias Burnus wrote:
Hi Jerry,
--- snip ---
The patch looks mostly like I would expect, except for decimal='point'
and a ';' which is *not* preceded by a space.
Thanks for working on it.
Regarding the 'except' case:
--- snip ---
i.e. for the following string, I had *ex
On 4/4/24 2:41 PM, Tobias Burnus wrote:
Hi Jerry,
I think for the current testcases, I like the patch – the question is
only what's about:
',3' as input for 'comma' (or '.3' as input for 'point')
For 'point' – 0.3 is read and ios = 0 (as expected)
But for 'comma':
* GCC 12 reads nothing
On 4/5/24 10:47 AM, Jerry D wrote:
On 4/4/24 2:41 PM, Tobias Burnus wrote:
Hi Jerry,
I think for the current testcases, I like the patch – the question is
only what's about:
',3' as input for 'comma' (or '.3' as input for 'point')
For &
On 4/6/24 4:54 PM, Neil Carlson wrote:
What are the recommended options to use (e.g., --enable-libsanitize)
when building GCC from source for the purpose of locating gfortran bugs?
I'm trying to pin down a runtime memory corruption error, and I recall
seeing at various times in the past recomme
On 4/8/24 2:53 AM, Tobias Burnus wrote:
Jerry D wrote:
See attached updated patch.
It turned rather quickly out that this patch – committed as
r14-9822-g93adf88cc6744a – caused regressions.
Namely, real-world code use tab(s) as separator instead of spaces.
[For instance, PR114304 which
On 4/8/24 2:45 AM, Paul Richard Thomas wrote:
Hi All,
This one is blazingly 'obvious'. I haven't had the heart to investigate why somebody thought that it is a good idea to check if unreferenced symbols are finalizable because, I suspect, that
'somebody' was me. Worse, I tried a couple of other
Hi posted some thoughts on the subject at our mattermost workspace.
This particular PR caught my attention because I have done things like
this before. I am looking forward to gcc15. I think changing things at
this point might be a bit intrusive.
I am thinking about:
"The FNV-1a algorithm is
On 4/26/24 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 switched to
git, and i
On 6/3/24 1:12 PM, Harald Anlauf wrote:
Dear all,
the attached simple patch fixes an ICE for ALLOCATE with SOURCE=
of a deferred-length character array with source-expression
being an array of character with length zero. The reason was
that the array descriptor of the source-expression was disc
On 6/18/24 10:20 AM, Steve Kargl wrote:
On Tue, Jun 18, 2024 at 09:13:23AM +0200, Gerald Pfeifer wrote:
The original subsite has disappeared and we couldn't find it elsewhere.
https://github.com/gklimowicz/FCVS
gklimowicz is a flang developer and member of J3.
FWIW my copy of the tests st
On 6/23/24 11:33 PM, ΚΩΣΤΑΣ ΚΥΡΙΑΚΟΠΟΥΛΟΣ wrote:
TO THE GNU ORGANIZATION 24-6-2024
Goodmorning!I am a mechanical engineer who loves mathematics and work
after my graduate thesis in mechanical engineering with higher
mathematics and excellent knowledge of FORTRAN on a PhD research on the
Hi all,
The attached patch fixes this by avoiding looking for and avoiding the
EOF condition in the parent READ after returning from the child IO process.
I could not think of a simple test case yet since the problem occurred
only when redirecting the input to the test program via a pipe. If
On 7/22/24 8:13 AM, Jerry D wrote:
Hi all,
The attached patch fixes this by avoiding looking for and avoiding the
EOF condition in the parent READ after returning from the child IO process.
I could not think of a simple test case yet since the problem occurred
only when redirecting the
I plan to push this soon to hopefully fix some test breakage on some
architetures. It is simple and obvious. I did not get any feedback on
this and I do not have access to the machines in question.
Regression tested on linux-x86-64.
Regards,
Jerry
commit bc4ee05dc7c60d534ef927ac5e679f67fb99
Hi all,
Doing some catchup here. I plan to commit the following shortly. This is
one of Steve's patches posted on bugzilla.
I have created a new test case.
Regression tested on linux x86-64.
git show:
commit 4d4549937b789afe4037c2f8f80dfc2285504a1e (HEAD -> master)
Author: Steve Kargl
Date
Hi all,
The attached patch changes all the snprintf calls to regular gfc_error
calls to cleanup translation. I introduced a simple macro to facilitate
doing the checks that were being done in the bad_op code section.
From the description for the call to gfc_extend_expr interfaces are
mentio
On 8/6/24 1:31 PM, Harald Anlauf wrote:
Hi Jerry,
this is OK for mainline.
I have no reservations against a backport after a waiting period.
If Roland is fine with it and nobody else objects, 14-branch might
be ok.
Thanks for the patch!
Harald
Thankd for the review! Pushed
Jerry
On 8/19/24 4:43 AM, Andre Vehreschild wrote:
Hi all,
another ping on this patch.
Regtests ok on x86_64-pc-linux-gnu on updated master. Ok for mainline?
Regards,
Andre
Looks OK to go ahead Andre.
Thanks,
Jerry
On Fri, 9 Aug 2024 16:29:08 +0200
Andre Vehreschild wrote:
Ping!
O
On 8/20/24 5:35 AM, Andre Vehreschild wrote:
Hi all,
pinging this patch.
Regtests ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline?
Regards,
Andre
Your approach looks reasonable so I think OK to push.
Thanks,
Jerry
On 8/28/24 8:33 PM, John Harper wrote:
Hi Thomas
Thank you! I got part of the way there after discovering that
download-prerequisites had to be download_prerequisites, but make -j12
had a fatal error. What I did was
$ cd
% mkdir Gcc
% cd ~/Gcc
$ tar xvjf ../Downloads/gmp-6.2.1.tar.bz2
$ tar
On 8/29/24 7:53 PM, John Harper wrote:
Hi Thomas & Damian
Thank you. I'm running Ubuntu 24.04 in an x86_64 system.
I do have dpkg and it said
(lf) john:~/Gcc-build$ dpkg -S libc-header-start.h
libc6-dev:amd64: /usr/include/x86_64-linux-gnu/bits/libc-header-start.h
So I tried
$ sudo apt install
On 9/5/24 12:42 PM, Harald Anlauf wrote:
Dear all,
the attached simple patch fixes a corner case related to pr84868,
which was tracked separately. While Paul's patch for pr84868 added
the framework for treating len_trim in the specification part of
a character function, it missed the possibilit
Steve and others
We continue to run into issues with PRs like this. I would like to
close these out. I completely hate the mechanisms we have for the
options. Why? Because every time I look at it I have to think it
through ten ways to sunday. It is not straight forward.
What I would like
On 9/10/24 12:49 AM, Paul Richard Thomas wrote:
Hi All,
This correspondence touches on something that I was going to raise - how
do we incorporate experimental F202Y features?
I very much suppory this idea and would like to see Thomas and Pauls
patches go in under this option so we do not
On 10/12/24 9:04 AM, Thomas Koenig wrote:
Hello world,
the attached patch implements the constants for UNSIGNED for
ISO_FORTRAN_ENV and ISO_C_BINDING. With this, the implementation
of UNSIGNED for gfortran should be complete, modulo bugs, of course.
OK for trunk?
Looks good to go Thomas.
Th
On 10/4/24 12:54 AM, Thomas Koenig wrote:
Hello world,
please find attached the patch for implementing MAXLOC and MINLOC
for unsigned.
The patch is rather lengthy, but mostly due to combinatorial
explosion
with the different return values.
Next time we update the ABI, we should treat MAXLOC
On 10/18/24 3:35 PM, Tobias Burnus wrote:
This patch was motivated by David's talk at Cauldron – and by
getting rather bad locations for some diagnostics, where I wanted
to use the column number to ensure that all items are found.
The main problem was a missing gobbling of spaces, but still
rang
On 10/18/24 3:20 PM, Tobias Burnus wrote:
*Patch ping*
OK for trunk.
Jerry
Tobias Burnus wrote:
I noticed that several diagnostic strings were not tagged as translatable.
I fixed them by adding _ or G_ as prefix ( →gcc/ABOUT-GCC-NLS) and moved a single-use string to the
message to make it
The attached diff file begins some test suite cleanup.
The patch removes extra spaces between dg-do and the run directive, I
only have gone through gfortran.dg and not its sub-directories.
Interestingly, one of the tests fails when this space is removed. I
fixed that by adding in a -O in the d
On 10/20/24 1:16 PM, Harald Anlauf wrote:
Hi Jerry!
Am 20.10.24 um 21:53 schrieb Jerry D:
On 10/20/24 12:23 PM, Harald Anlauf wrote:
Hi Jerry!
Am 20.10.24 um 18:56 schrieb Jerry D:
The attached diff file begins some test suite cleanup.
The patch removes extra spaces between dg-do and the
On 10/20/24 12:23 PM, Harald Anlauf wrote:
Hi Jerry!
Am 20.10.24 um 18:56 schrieb Jerry D:
The attached diff file begins some test suite cleanup.
The patch removes extra spaces between dg-do and the run directive, I
only have gone through gfortran.dg and not its sub-directories
Pushed as stated in the PR to cleanup the test case.
commit 6604a05fa27bc21c3409e767552daca3fcf43964 (HEAD -> master,
origin/master, origin/HEAD)
Author: Jerry DeLisle
Date: Thu Oct 17 13:39:09 2024 -0700
Fortran: Add tolerance to real value comparisons.
gcc/testsuite/ChangeLog:
On 10/17/24 12:52 PM, Thomas Koenig wrote:
Hello world,
The attached patch fixes an ICE when an UNSIGNED-specific constant
is used from ISO_FORTRAN_ENV. The error message is not particularly
great, it is
Error: Unsigned: The symbol 'uint32', referenced at (1), is not in the
selected standard
Hi all,
I have been experimenting in the testsuite world. I have learned
a few things. Motivation here is getting rid of the two-spaces
"feature" after dg-do in "dg-do run" and provide a way to
explicitly make one pass on a test case with compile option -O.
See also PR 28032
Basically, the
On 10/29/24 2:00 PM, Harald Anlauf wrote:
Dear all,
while looking at the recent testcase gfortran.dg/pr115070.f90 with f951
running under valgrind, I noticed minor front-end memleaks of gfc_expr's
that are probably fallout from a code refactoring, which are fixed by
the attached.
Regtested on x
On 10/30/24 9:58 AM, Steve Kargl wrote:
On Wed, Oct 30, 2024 at 04:41:40PM +, Paul Richard Thomas wrote:
This wrinkle to PR115700 came about because the associate-name string
length was not being initialized, when an array selector had a substring
reference with non-constant start or end. Th
On 11/2/24 8:44 AM, Thomas Koenig wrote:
Ping **(5./7.) ?
MASKR and MASKL are obvious candidates for unsigned, too; in the
previous version of the doc patch, I had promised that these would
take unsigned arguments in the future. What I had in mind was
they could take an unsigned argument and re
On 11/12/24 5:23 AM, Paul Richard Thomas wrote:
Hi All,
The ChangeLog and comment make it clear what this patch does and why.
OK for mainline and backporting after a week or so?
Regards
Paul
In the test case:
A comment s/resul/result/
Also the test conditional
if (trim (array_strings2(i
On 9/21/24 9:55 AM, Jerry Delisle wrote:
I suggest that you go get the Fedora 40 or rawhide rpm packages already
built and updated. Just went search for Fedora repositories.
s/went/web/
You may need to pull some dependencies.
Regards,
Jerry
PS Don't try to reply to emails on cell phone. ;)
On 9/23/24 11:21 PM, Hans-Peter Nilsson wrote:
Here's a general approach to handle PR116701. I considered
adding manual deletions as quoted below and mentioned in the
PR, but seeing the handling of "integer 8" in
fortran-torture-execute I decided to follow that example:
better scan the source fo
On 9/18/24 1:20 PM, Thomas Koenig wrote:
OK for trunk?
OK and thanks.
Jerry
--- snip ---
On 9/24/24 5:46 PM, Hans-Peter Nilsson wrote:
Thanks for the review!
Date: Tue, 24 Sep 2024 17:10:27 -0700
Cc: Jerry D
From: Jerry D
On 9/23/24 11:21 PM, Hans-Peter Nilsson wrote:
I hope the inclusion of gfortran-dg.exp in
fortran-torture.exp is not controversial, but there's no
fo
I would like to commit the attached patch for Steve.
Regression tested on x86-64-linux-gnu.
OK for trunk?
Author: Steve Kargl
Date: Sun Nov 24 18:26:03 2024 -0800
Fortran: Check IMPURE in BLOCK inside DO CONCURRENT.
PR fortran/117765
gcc/fortran/ChangeLog:
On 11/25/24 3:09 AM, Paul Richard Thomas wrote:
Hi All,
The breakage was caused by the patch for PR109345. As it happens, this
part of the patch was not required to fix the PR and looked to be a
considerable simplification of the condition. Although correct that all
is left are class dummies,
On 11/27/24 12:31 PM, Harald Anlauf wrote:
Dear all,
the attached patch fixes a wrong-code issue with bounds-checking
enabled when doing I/O of an array section and an index is either
an expression or a function result. The problem does not occur
without bounds-checking.
When looking at the or
On 11/20/24 1:08 PM, Harald Anlauf wrote:
Dear all,
the attached, actually rather straightforward patch fixes the checking of
protected variables in submodules. When a variable was use-associated
in an ancestor module, we failed to properly diagnose this.
Regtested on x86_64-pc-linux-gnu. OK
1 - 100 of 300 matches
Mail list logo
