The test cases under g[cc|++].dg/vect/vect.exp will be skipped on rv64gc after
this patch
gcc/testsuite/ChangeLog:
* lib/target-supports.exp: skip vector tests if target not supporting v
extension
Signed-off-by: Jerry Zhang Jian
---
gcc/testsuite/lib/target-supports.exp | 5 +
1 file
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
.
Thanks,
Harald
OK and thanks for patch.
Jerry
https://gcc.gnu.org/g:b55a35bcc80a7402576556c2f9d161229fb220ef
commit r13-8640-gb55a35bcc80a7402576556c2f9d161229fb220ef
Author: Jerry DeLisle
Date: Sun Apr 21 20:50:26 2024 -0700
libfortran: Fix handling of formatted separators.
Backport from mainline
lve.cc (resolve_symbol): Remove last chunk that checked
for finalization of unreferenced symbols.
gcc/testsuite/
PR fortran/114535
* gfortran.dg/pr114535d.f90: New test.
* gfortran.dg/pr114535iv.f90: Additional source.
Yes, OK Paul. Don't feel bad. It wasn't Tabs. LOL
Jerry
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
https://gcc.gnu.org/g:93adf88cc6744aa2c732b765e1e3b96e66cb3300
commit r14-9822-g93adf88cc6744aa2c732b765e1e3b96e66cb3300
Author: Jerry DeLisle
Date: Fri Apr 5 19:25:13 2024 -0700
libfortran: Fix handling of formatted separators.
PR libfortran/114304
PR
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 'point' – 0.3 is read and ios = 0 (as expected
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
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
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
with an incorrect separator as long as there is
at least one space in front of it.
New test case included. Regression tested on X86-64.
OK for trunk? Backport to 13 after some time.
Regards,
Jerrycommit 7d1a958d6b099ea88b6c51649baf5dbd5e598909
Author: Jerry DeLisle
Date: Wed Apr 3 18:07:30 2024
?
If this fix survives broader testing, I would like to backport.
Thanks,
Harald
P.S.: while trying to extend coverage of conforming code, I had
much fun also with other compilers (e.g. NAG panicking...)
OK, for trunk and we will see how it survives for a bit before back port.
Jerry -
https://gcc.gnu.org/g:41e767c482fc903ca5d54014b034c7526dbf8f1c
commit r14-9681-g41e767c482fc903ca5d54014b034c7526dbf8f1c
Author: Jerry DeLisle
Date: Tue Mar 26 16:44:17 2024 -0700
libgfortran: Fix file position after ENDFILE statement.
PR libfortran/107031
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
https://gcc.gnu.org/g:824a71f609b37a8121793075b175e2bbe14fdb82
commit r13-8417-g824a71f609b37a8121793075b175e2bbe14fdb82
Author: Jerry DeLisle
Date: Mon Mar 11 15:15:34 2024 -0700
libgfortran: [PR114304] Revert portion of PR105347 change.
PR libfortran/105437
https://gcc.gnu.org/g:0c179654c3170749f3fb3232f2442fcbc99bffbb
commit r14-9432-g0c179654c3170749f3fb3232f2442fcbc99bffbb
Author: Jerry DeLisle
Date: Mon Mar 11 15:15:34 2024 -0700
libgfortran: [PR114304] Revert portion of PR105347 change.
PR libfortran/105437
https://gcc.gnu.org/g:7ecea49245bc6aeb6c889a4914961f94417f16e5
commit r13-8411-g7ecea49245bc6aeb6c889a4914961f94417f16e5
Author: Jerry DeLisle
Date: Sat Feb 17 09:24:58 2024 -0800
libgfortran: [PR105473] Fix checks for decimal='comma'.
PR libfortran/105473
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
https://gcc.gnu.org/g:03932d3203bce244edd812b81921c2f16ea18d86
commit r14-9348-g03932d3203bce244edd812b81921c2f16ea18d86
Author: Jerry DeLisle
Date: Wed Mar 6 19:46:04 2024 -0800
Fortran: Fix issue with using snprintf function.
The previous patch used snprintf to set the message
https://gcc.gnu.org/g:21edfb0051ed8d0ff46d5638c2bce2dd71f26d1f
commit r14-9328-g21edfb0051ed8d0ff46d5638c2bce2dd71f26d1f
Author: Jerry DeLisle
Date: Tue Mar 5 20:49:23 2024 -0800
Fortran: Add user defined error messages for UDTIO.
The defines IOMSG_LEN and MSGLEN were redundant
On 3/5/24 1:51 PM, Harald Anlauf wrote:
Hi Jerry,
on further thought, do we sanitize 'child_iomsg'?
We pass it to snprintf as format.
Wouldn't a strncpy be sufficient?
Harald
Just to be safe I will bump char message[IOMSG_LEN] to char
message[IOMSG_LEN + 1]
This is like a C string vs
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
.
Objections?
Thanks,
Harald
Looks good to me. I think backport is OK as well.
Jerry -
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
the library.
Regressions tested on x86_64.
OK for trunk?
Regards,
Jerry
commit 640991bd6b83df4197b2eaec63d1e0e695e48b75
Author: Jerry DeLisle
Date: Wed Feb 28 20:51:06 2024 -0800
Fortran: Add user defined error messages for UDTIO.
The defines IOMSG_LEN and MSGLEN were redundant
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
. OK for mainline?
And a backport to 13-branch after some delay?
Thanks,
Harald
Yes, simple enough. OK.
Thanks,
Jerry
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
WRITE or unformatted
READ/WRITE until I get some feedback on the approach. If this approach
is OK I would like to commit and then do a separate patch for the cases
I just mentioned.
Feedback appreciated. Regression tested on x86_64. OK for trunk?
Jerry
Author: Jerry DeLisle
Date: Thu Feb 22
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
Steve,
I looked it over and looks reasonable. I will try to apply it next few
days and test here. If OK, I will commit.
Jerry
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
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
. Another temporarily disabled test was
re-enabled.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
Yes OK for mainline.
Thanks,
Jerry
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/fort
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
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".
,
This patch looks OK.
Thanks,
Jerry
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
apologize for the clutter, but we might as well get rid of it
now.
Two existing test cases needed to be adjusted and I am adding one new
test case to capture the changes in our testsuite.
Regression tested on X86_64.
OK for trunk? Do we need to backport this?
Regards,
Jerry
Author: Jerry
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
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
today
if I can. Paul is unavailable for a few weeks. Harald can chime in.
Do you have commit rights for gcc?
Your efforts are appreciated.
Regards,
Jerry
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
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
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
, and then, if no fallout, 13 at your discretion.
Regards,
Jerry
ted on x86_64-pc-linux-gnu. OK for mainline?
As this fixes a regression since 8-release, I plan to backport
to all active branches.
Thanks,
Harald
OK for Mainline and backport
Thanks Harald
Jerry
email.
Regardless, both good to go.
Thanks,
Jerry
... ;-) Used to ICE previously.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
This one is OK Harald.
Thanks,
Jerry
On 9/18/23 1:27 PM, Harald Anlauf via Fortran wrote:
Dear all,
as correctly analyzed by Jerry, the code for checking the consistency
of character lengths in array constructors did not properly initialize
the auxiliary variable used in "bounds checking". The attached patc
On 8/24/23 2:28 PM, Harald Anlauf via Fortran wrote:
Dear all,
the attached patch adds stricter bounds-checking for DATA statements
with implied-do. I chose to allow overindexing (for arrays of rank
greater than 1) for -std=legacy, as there might be codes in the wild
that need this (and this
as 'obvious' in
r14-3098-gb8ec3c952324f866f191883473922e250be81341
13-branch to follow in a few days.
Paul
Thanks Paul, I was about ready to do it myself.
Jerry
and lead to ICEs in various places. The solution
which removes the comparison for size > 0 also has the bonus that
it fixes a minor memory leak for the size==0 case...
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
Looks Good To Me.
OK,
Jerry
/* Set flags for the internal unit. */
The revised test case attached. It has been regression tested OK.
Regards,
Jerry! { dg-do run }
! { dg-options "-std=f2003" }
! PR109662-a semi-colon after namelist name accepted on input.
program testnmlread
implicit none
character(16) :: line = '
On 5/6/23 11:15 AM, Harald Anlauf via Fortran wrote:
Hi Jerry, Steve,
I think I have to pour a little water into the wine.
The patch fixes the reported issue only for a comma after
the namelist name, but we still accept a few other illegal
characters, e.g. ';', because:
#define is_separator(c
The attached patch adds a check for the invalid comma and emits a
runtime error if -std=f95,f2003,f2018 are specified at compile time.
Attached patch includes a new test case.
Regression tested on x86_64-linux-gnu.
OK for mainline?
Regards,
Jerry
Author: Jerry DeLisle
Date: Fri May 5 20
Forgot to copy the list on this.
Forwarded Message
Subject: Re: Hosting our gfortran MatterMost workspace
Date: Fri, 5 May 2023 10:24:11 -0700
From: Jerry D
To: Mark Wielaard
On 4/29/23 5:36 AM, Mark Wielaard wrote:
Hi,
On Fri, Apr 28, 2023 at 08:55:44PM +0200, Bernhard
suggestions of possible places we can host an
instance, please let me know. The software for the platform is open
source many folks self host, so we can do this.
I am not sure where gcc.gnu.org is hosted, but that might be a logical
place.
Best regards,
Jerry
On 4/18/23 12:39 PM, Harald Anlauf via Fortran wrote:
Dear all,
the attached patch adjusts the scan-tree-dump patterns of the
reported testcases which likely were run in a location such
that a path in an error message showing in the tree-dump might
have accidentally matched "free" or "data",
types, see PR. This was likely an oversight.
The attached fix is simple and regtests cleanly on x86_64-pc-linux-gnu.
OK for mainline?
Thanks,
Harald
Looks good to go.
Jerry
qualify for a backport. It's simple enough anyway.
Thanks,
Harald
OK, please proceed. Thanks for the patch.
Jerry
On 3/3/23 3:32 PM, Iain Sandoe wrote:
On 3 Mar 2023, at 23:11, Bernhard Reutner-Fischer via Fortran
wrote:
On 2 March 2023 02:23:10 CET, Jerry D wrote:
On 3/1/23 4:07 PM, Steve Kargl via Fortran wrote:
On Wed, Mar 01, 2023 at 10:28:56PM +0100, Bernhard Reutner-Fischer via Fortran
wrote
. It is a lot cleaner.
Jerry
Pushed, thanks for feedback
On 2/26/23 11:54 PM, Tobias Burnus wrote:
Just side remarks, the 0 init in the patch is fine.
On 27.02.23 03:53, Jerry D via Gcc-patches wrote:
regarding PACK: since this is a bogus warning as the compiler does
not realize that dim >= 1, wouldn't a
gcc_ass
On 2/26/23 12:59 PM, Harald Anlauf wrote:
Hi Jerry,
regarding PACK: since this is a bogus warning as the compiler does
not realize that dim >= 1, wouldn't a
gcc_assert (dim >= 1);
in the right place achieve the same effect, since the first argument
must be an array?
(It's dif
The attached patch is minor and self explanatory. I assume this should
wait for gfortran 14 since no regression involved. Please advise otherwise.
Regression tested on x86-64.
OK for trunk when the time is right?
Regards,
Jerry
Author: Jerry DeLisle
Date: Sat Feb 25 20:30:35 2023 -0800
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
,
Harald
Yes, OK
Thanks,
Jerry
,
Jerry
.
If it is suppose to be a notification, how about just the word "Alert"
or "Notice"
Regards,
Jerry
Jerry
I had this show up today. I have no idea what this is about.
Please advise.
Jerry
Forwarded Message
Subject: ☠ Buildbot (Sourceware): gcc - failed configure (failure) (master)
Date: Sun, 29 Jan 2023 19:31:23 +
From: buil...@sourceware.org
To: Jerry DeLisle
A new
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
,
I plan to backport as appropriate.
Thanks,
Harald
Yes, this is OK for all.
Thanks
Jerry
On 1/24/23 1:48 PM, Harald Anlauf via Fortran wrote:
Dear all,
when checking expressions for array sections, we need to ensure
that these use only type INTEGER. However, it does not make sense
to generate an internal error when encountering wrong types,
but rather take the ordinary route of
Committed:
It is not apparent to me that the testsuite/ChangeLog was updated. Maybe
there is a time delay on that?
Please be patient with me as I figure out how all this works.
ommit f963705752e9d0b79a340788166269af417e344e (HEAD -> master,
origin/master, origin/HEAD)
Author: Jerry DeLi
On 1/22/23 5:38 AM, Mikael Morin wrote:
Hello,
Le 22/01/2023 à 00:59, Jerry D via Fortran a écrit :
(...)
Proposed ChangeLog entry using git gcc-commit-mklog:
Author: Jerry DeLisle
Date: Sat Jan 21 15:47:19 2023 -0800
Revise the line end tests to pass on certain windows test
On 1/20/23 6:13 PM, Jerry DeLisle via Fortran wrote:
Hi all,
The attached patch modifies the following tests to check for line
endings. Some test environments inject superfluous /r characters at
ends of lines. The expression matching in dg-output tests are changed from:
(\n|\r\n|\r)
to
(\r
On 1/20/23 9:16 PM, Jerry D wrote:
On 1/20/23 5:46 PM, Jerry D wrote:
A PARAMETER value is not allowed in a DATA statement, similar to an
EQUIVALENCE.
The check for this was in gfc_assign_data_value() in data.cc which
turns out to be too late when trying to assign a zero sized array
On 1/20/23 5:46 PM, Jerry D wrote:
A PARAMETER value is not allowed in a DATA statement, similar to an
EQUIVALENCE.
The check for this was in gfc_assign_data_value() in data.cc which turns
out to be too late when trying to assign a zero sized array.
Correction, the chunk in data.cc must
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
A PARAMETER value is not allowed in a DATA statement, similar to an
EQUIVALENCE.
The check for this was in gfc_assign_data_value() in data.cc which turns
out to be too late when trying to assign a zero sized array.
To correct this, the check is moved to match_variable() in primary.cc
where
. The code is for MINGW; Cygwin does not set
that that
var and is likely to use return values closer to POSIX.
OK for mainline?
Tobias
OK, thanks fir fix.
Jerry
a real situation where it is needed, they can adjust.
Regards,
Jerry
On 1/5/23 7:33 PM, Jacob Bachmeyer via Fortran wrote:
NightStrike wrote:
On Fri, Dec 23, 2022 at 11:00 PM Jacob Bachmeyer
wrote:
NightStrike wrote:
On Wed, Dec 21, 2022 at 11:37 PM Jacob Bachmeyer
wrote:
[...]
So at least we know for sure that this particular instance of extra
characters
normal line ending which on UNIX will be
an LF and Windows an CR-LF.
I lose track of details in between looking ta the test cases. let me
know one of them to study that is gfortran side and will see what it is
doing.
Jerry
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
method than embedding print statements for debugging rather than do a
tone of work to enable something that is not really a legitimate use case.
FWIW,
Jerry
On 12/17/22 1:21 PM, Harald Anlauf via Fortran wrote:
Dear all,
the previous fix for pr103505 introduced a regression that could lead
to wrong array bounds when LBOUND/UBOUND were used in the array spec
of a declaration. The reason was that we tried to simplify too early
the array element
I have committed the obvious as simple.
The master branch has been updated by Jerry DeLisle :
https://gcc.gnu.org/g:7e76cd96950f49ce21246d44780e972d86b2bcdd
commit r13-4862-g7e76cd96950f49ce21246d44780e972d86b2bcdd
Author: Steve Kargl
Date: Thu Dec 22 20:38:57 2022 -0800
Remove
On 12/19/22 2:29 AM, Jakub Jelinek wrote:
On Sat, Dec 17, 2022 at 09:12:43AM -0800, Jerry D via Gcc-patches wrote:
The attached patch fixes a regression and is a patch from Steve. I have
regression tested it and provided a test case. It is fairly simple and I
will commit under the "s
to
speed on the git magic.
Regards,
Jerry
diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc
index 0f9b2ced4c2..1562dc22bc6 100644
--- a/gcc/fortran/decl.cc
+++ b/gcc/fortran/decl.cc
@@ -2221,6 +2221,14 @@ add_init_expr_to_sym (const char *name, gfc_expr **initp, locus *var_locus)
sym-&g
, looks good. See my unrelated question on mattermost.
Jerry
Hi Herald,
Looks good to me. I have always preferred informative messages.
Thanks,
Jerry
On 7/14/22 1:34 PM, Harald Anlauf via Fortran wrote:
Dear all,
the attached patch introduces error recovery for two cases of using
an invalid array in a declaration of an implied-shape array instead
Yes, Thank you Mikael!
On 4/22/22 6:59 AM, Thomas Koenig via Fortran wrote:
Hi Mikael,
Ping for the four patches starting at
https://gcc.gnu.org/pipermail/fortran/2022-April/057759.html :
https://gcc.gnu.org/pipermail/fortran/2022-April/057757.html
and conservative solution.
Regtested on x86_64-pc-linux-gnu. OK for mainline/11-branch?
Thanks,
Harald
Patch looks OK Harald, OK.
Thanks,
Jerry
to e.g. the 11-branch?
Thanks,
Harald
Yes, looks good, OK to commit
Regards,
Jerry
Perhaps someone could work on completing and merging the shared memory
(native) fortran coarrays branch.
Regards,
Jerry
On 3/9/22 6:39 AM, Martin Jambor wrote:
Hello,
I am pleased that I can announce that GCC has been accepted as a
mentoring organization of Google Summer of Code 2022
,
Jerry
1 - 100 of 741 matches
Mail list logo
