On 3/5/25 6:34 AM, Andre Vehreschild wrote:
Hi all,
attached patch fixes a gimplification error when a pointer remapping on derived
type's components with deferred arrays is made. The issue boiled down to the
dependency analysis being to loose. It saw a dependency as soon as both sides
of the =>
On 2/10/25 2:25 AM, Andre Vehreschild wrote:
[PATCH 7/7] Fortran: Remove deprecated coarray routines [PR107635]
I have applied all patches. Regression tested OK here.
From patch 5 there was one reject:
patching file gcc/testsuite/gfortran.dg/coarray/send_char_array_1.f90
Hunk #1 FAILED at 39
On 2/13/25 11:59 AM, Thomas Koenig wrote:
Hello world,
this was an interesting regression. It came from my recent
patch, where an assert was triggered because a procedure artificial
dummy argument generated for a global symbol did not have the
information if if was a function or a subroutine.
On 2/13/25 1:42 PM, Harald Anlauf wrote:
Am 12.02.25 um 21:49 schrieb Jerry D:
The attached patch is fairly obvious. The use of notify_std is changed
to a gfc_error. Several test cases had to be adjusted.
Regression tested on x86_64.
OK for trunk?
This is not a review, just some random
On 2/13/25 11:48 AM, Jerry D wrote:
On 2/10/25 2:25 AM, Andre Vehreschild wrote:
[PATCH 7/7] Fortran: Remove deprecated coarray routines [PR107635]
I have applied all patches. Regression tested OK here.
From patch 5 there was one reject:
patching file gcc/testsuite/gfortran.dg/coarray
On 2/19/25 10:08 AM, Tobias Burnus wrote:
The attached patch does some ground-laying work for OpenMP
deep mapping - touching common gfortran code.
It does so by:
(1)gfc_tree_array_size now can determine the array size not only from
the passed Fortran gfc_expr but also using a descriptor, passe
This attached patch is intended to clarify the '-x' option using '-x
f77' as an example. I was not sure who should review.
Tested by inspecting the generated info file from make info.
OK for trunk and backport to 14?
Regards,
Jerry
Author: Jerry DeLisle
Date: Wed Feb 26 17:26:26 2025 -080
On 2/25/25 9:18 AM, Andre Vehreschild wrote:
Hi all,
for some recreation after all the coarray stuff, I found this pr cc'ed to me.
Taking a look at it, I figured that using a SAVE_EXPR on the lhs of the
assignment was doing the harm. The data seems to be not written back into the
vector shaped d
On 2/25/25 11:41 AM, Jürgen Bausa wrote:
In the meantime I found out what is causing the problem. There seems to
be a bug in the connection from gfortran to UCRT (Microsofts universal C
runtime, that ships with Windows 10 and 11). If I switch to a compiler
that uses MSVCRT (Microsoft Visual C run
On 5/10/25 11:33 AM, Harald Anlauf wrote:
Early ping.
Am 06.05.25 um 21:06 schrieb Harald Anlauf:
Dear all,
here's another rather obvious case where a temporary is needed for
an inquiry reference of a complex array which is a component of a
derived type. In contrast to PR119986, the argument
On 5/6/25 10:59 AM, Steve Kargl wrote:
On Tue, May 06, 2025 at 07:43:41PM +0200, Harald Anlauf wrote:
the new logic misses the following bad code:
print *, c_associated(c_loc(val), 42)
This now ICEs here.
I suggest to not 'return true' too early before all arguments
have been checked.
Hello all,
The attached patch revises the logic of the checks in
gfc_check_c_associated to handle previous cases that ICE'ed as seen in
the PR. There are multiple gotchas in these cases, particularly with the
optional c_ptr_2 argument.
I factored the logic into two new helper functions. This
On 5/17/25 10:22 AM, Jerry D wrote:
Hello all,
--- snip ---
PS
I managed to clean up the change log and add in Steve:
Author: Jerry DeLisle
Date: Sat May 17 09:45:14 2025 -0700
Fortran: Fix c_associated argument checks.
PR fortran/120049
gcc/fortran/ChangeLog
On 5/20/25 12:01 PM, Harald Anlauf wrote:
Hi Jerry!
Am 20.05.25 um 05:23 schrieb Jerry D:
On 5/19/25 1:50 PM, Harald Anlauf wrote:
Hi Jerry,
so contrary to what the name of patch claims (pr120049-final.diff),
it fixes only the case of direct use of iso_c_binding, but not the
indirect one
push the incremental patch now, go ahead.
Cheers,
Harald
Am 18.05.25 um 23:46 schrieb Jerry D:
On 5/18/25 2:34 PM, Jerry D wrote:
On 5/18/25 2:10 PM, Harald Anlauf wrote:
Hi Jerry,
I found 2 corner invalid cases which are silently accepted with
your patch when iso_c_binding is used indirectly
On 5/18/25 2:10 PM, Harald Anlauf wrote:
Hi Jerry,
I found 2 corner invalid cases which are silently accepted with
your patch when iso_c_binding is used indirectly:
print *, c_associated(c_loc(val), C_NULL_FUNPTR)
print *, c_associated(C_NULL_FUNPTR, c_loc(val))
These should get rejected
On 5/18/25 2:34 PM, Jerry D wrote:
On 5/18/25 2:10 PM, Harald Anlauf wrote:
Hi Jerry,
I found 2 corner invalid cases which are silently accepted with
your patch when iso_c_binding is used indirectly:
print *, c_associated(c_loc(val), C_NULL_FUNPTR)
print *, c_associated(C_NULL_FUNPTR
On 5/27/25 11:24 AM, Harald Anlauf wrote:
Dear all,
the attached patch fixes a variety of small issues with parsing of
inquiry references of substrings. The testcase exercises variations
of the examples in the PR and ensures that these are successfully
simplified.
Don't try it with other compi
On 5/27/25 12:39 PM, Harald Anlauf wrote:
Hi Jerry!
On 5/27/25 21:02, Jerry D wrote:
On 5/20/25 12:35 PM, Jerry D wrote:
On 5/20/25 12:01 PM, Harald Anlauf wrote:
Hi Jerry!
Am 20.05.25 um 05:23 schrieb Jerry D:
On 5/19/25 1:50 PM, Harald Anlauf wrote:
Hi Jerry,
so contrary to what the
After my last commit, I always rerun make check-fortran.
Now I see a bunch of fails. I reverted my patch locally and did a
rebuild and I still see these. Heralds patch still in there.
No failures after reverting this:
commit r16-914-g787a8dec1acedf5561c8ee43bed0b3653fca150d
Author: Harald Anl
On 5/27/25 2:19 PM, Harald Anlauf wrote:
Jerry, all,
that was entirely my fault - attempting a last-minute cleanup
that reordered code, trying to use a refactoring. I've put
on my brown bag and pushed a corrections as obvious as:
r16-921-g74a2281ae18c6d.
See attached.
Caveat: this was tested
On 5/20/25 12:35 PM, Jerry D wrote:
On 5/20/25 12:01 PM, Harald Anlauf wrote:
Hi Jerry!
Am 20.05.25 um 05:23 schrieb Jerry D:
On 5/19/25 1:50 PM, Harald Anlauf wrote:
Hi Jerry,
so contrary to what the name of patch claims (pr120049-final.diff),
it fixes only the case of direct use of
On 5/28/25 10:09 AM, Steve Kargl wrote:
On Wed, May 28, 2025 at 08:11:05AM -0700, Jerry D wrote:
The attached patch is simple and self explanatory in the git log entry.
Regression tested on X86_64-linux-gnu.
OK for trunk?
Yes, with one question.
commit
On 5/21/25 6:46 PM, George Rinker wrote:
When I run gfortran (13.1.0 installed 2023/08/20.17:50) from cmd.exe on
a source.f that generates a compiler error, I get a message listing the
first error line and column in normal text, then subsequent messages in
a different color, and then it hangs a
This was a followup to make the error message a little better.
Committed.
commit c69afa2f1bd7455457ab4e028a6bc51211b2dd20 (HEAD -> master,
origin/master, origin/HEAD)
Author: Jerry DeLisle
Date: Thu May 29 10:02:00 2025 -0700
Fortran: Make minor adjustment to error message.
I am getting this tonight.
Jerry
In file included from
/home/jerry/dev/usr/include/c++/16.0.0/x86_64-pc-linux-gnu/bits/gthr-default.h:35,
from
/home/jerry/dev/usr/include/c++/16.0.0/x86_64-pc-linux-gnu/bits/gthr.h:157,
from
/home/jerry/dev/usr/include/c++/16.
Hi all,
The attached patch fixes a latent issue where we were saving a parsed
and checked format string that had a missing comma. This resulted in the
correct error on the first use of the string, but a missed error on
subsequent uses of the string.
New test case provided.
Regression tested
On 6/15/25 1:22 PM, Harald Anlauf wrote:
Am 15.06.25 um 21:25 schrieb Harald Anlauf:
Dear all,
the attached patch fixes a rejects-valid: in an ALLOCATE statement with
MOLD= present, if the allocate-object has an explicit-shape-spec, the
compatibility of ranks is not required by the standard. (
On 6/18/25 2:02 PM, Mikael Morin wrote:
From: Mikael Morin
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
Was there a PR for this? or something you just ran into?
Not a problem either way, just curious.
It looks OK to me. OK for master.
Jerry
-- >8 --
gcc/fortran/ChangeL
On 6/10/25 1:55 PM, Harald Anlauf wrote:
Gesendet: Mittwoch, 4. Juni 2025 um 20:37
Von: "Jerry D"
An: "Mikael Morin" , "Harald Anlauf" ,
fortran@gcc.gnu.org
Betreff: Re: Execution time for gfortran regression testing
On 6/3/25 3:02 AM, Mikael Morin wrote:
The b
On 6/23/25 9:43 AM, Paul Richard Thomas wrote:
Hello All,
I was mulling over the F2018 status of gfortran, when I came across the
additions to the IMPORT statement. This seemed like such a useful
addition to fortran that I set about an implementation; thinking that
this would be low hanging f
On 6/23/25 12:39 PM, Harald Anlauf wrote:
Dear all,
here's an obvious fix for a rejects-valid when an interface was
renamed on use and is extended in the importing module. One check
incorrectly referred to the original interface name, not the
renamed one.
Regtested on x86_64-pc-linux-gnu. OK
On 6/13/25 11:20 PM, Paul Richard Thomas wrote:
Hi Jerry,
I have an octave script that does that. I last used it when I was
working on ASSOCIATE. I'll dig it out and send it to you.
Regards
Paul
Thanks Paul, I will have a look. I was thinking to use Python since many
other scripts in con
On 6/3/25 3:02 AM, Mikael Morin wrote:
Le 30/05/2025 à 22:28, Harald Anlauf a écrit :
When I'm working on a particular area of gfortran, I tend
to use RUNTESTFLAGS to limit what is tested. For example,
I just fixed SPREAD() for scalar source and ncopies < 1.
I do
% cd obj
% gmake
% cd gcc
% gm
The attached patch is simple and self explanatory in the git log entry.
Regression tested on X86_64-linux-gnu.
OK for trunk?
Regards,
Jerrycommit 845768cbead03f76265e491bcf5ea6de7020ff39
Author: Jerry DeLisle
Date: Wed May 28 07:56:12 2025 -0700
Fortran: Adjust handling of optional com
On 6/6/25 5:34 AM, FX Coudert wrote:
Hi,
In commit 5e918a4db9e4a5bdbeafec6881fa8b22a55d3789, regenerated files
were not included in the commit as they should have been. Therefore, a
whitespace fix was not propagated. Sync generated files now, as obtained
from a run with --enable-maintainer-mode.
On 6/27/25 1:08 PM, Toon Moene wrote:
On 6/27/25 17:41, Toon Moene wrote:
Note: as the timeline at the top of the source implies, I have worked on this
until early 2021.
This means it compiled with gfortran 10 and 11.
So the problem is probably introduced after these versions.
[ Of course,
On 6/27/25 1:48 PM, Harald Anlauf wrote:
Dear all,
my original patch caused a regression on previously working code where
an imported interface was *not* renamed-on-use, as the related new logic
did not expect a local_name to be an empty string.
Funnily, there was no previously existing test in
On 6/29/25 7:52 AM, Thomas Koenig wrote:
Hi Jerry,
real 0m7.426s
user 0m47.602s
sys 0m42.707s
Do you know if these numbers are for a shared-memory MPI implementation
or a traditional one?
Best regards
Thomas
I believe it is traditional. I was using OpenCoarrays with mpich.
On 7/19/25 10:59 AM, Toon Moene wrote:
On 7/19/25 18:32, Jerry D wrote:
I expanded on Toon's random_weather.f90 test using:
!integer, parameter :: DNX = 72, DNY = 70, DNZ = 30, BDSIZE = 4, HORSTEP =
1, VERSTEP = 100, FCLEN = 3600, TIMSTEP = 240
integer, parameter :: DNX = 1000
On 7/19/25 2:26 PM, Thomas Koenig wrote:
I wrote:
I have grave concerns.
At the last (to me an Nicolas) known state, before he was ousted
from the project, there were known race conditions, which can
cause freezing and/or data corruption.
I believe these have not been addressed, neither teste
On 7/17/25 9:37 PM, Jerry D wrote:
I have created a new gfortran-test branch on gcc here.
origin/devel/gfortran-test
This has the patches applied as needed to do the testing I have done.
When Andre's patches are approved I will revert and rebase this so we can test
the next set of
On 7/4/25 5:12 AM, Andre Vehreschild wrote:
Hi all,
attached patches goes on top of other 6 caf_shmem coarray patches and fixes
missing includes esp. on non-Linux systems. I have tested this on a FreeBSD,
which is very time consuming due to it being fully virtualized on my system.
Regtests ok o
On 7/7/25 8:39 AM, Andre Vehreschild wrote:
Ping!
OK for mainline.
Thanks,
Jerry
On Thu, 26 Jun 2025 15:32:47 +0200
Andre Vehreschild wrote:
Hi,
I found a bug in the module cleanup expression at the end of the test. In the
attached patch it is corrected.
Regtests ok on x86_64-pc-linux
Hello all,
I have done the following to test the collection of Andre's patches which
implement the subject -lcaf_shmem:
1) Successfully compiled and executed Toon's random_weather.f90 program. The
only question I have on this one is when I select an np value such that the slab
size does not
fortran/tsunami
Jerry
On 7/7/25 2:00 PM, Jerry D wrote:
Hello all,
I have done the following to test the collection of Andre's patches which
implement the subject -lcaf_shmem:
1) Successfully compiled and executed Toon's random_weather.f90 program. The
only question I have on this o
Hi all,
Quite a few years ago I created a gfortran-dev branch that I could keep up to
date with trunk by merging periodically.
It is still listed in the gcc website documentation. I tried to follow the
instructions in there to create a new branch. The purpose is so we can expand
on testers
On 7/10/25 2:27 AM, Andre Vehreschild wrote:
Hi all,
after Jerry had the idea to use OpenCoarray's tests to also test
caf_shmem, a few issue arose. Those have been fixed now in the updated
patch-series.
I have put all patches into one mail to allow the CIs to pick them all
up and hopefully test
On 7/11/25 10:36 PM, Tobias Burnus wrote:
Now, finally pushed as r16-2213-g451b6dbf475959.
Tobias
On June 27, 2025, Tobias Burnus wrote:
Background: In real-world code, one can find:
!$ACC DECLARE COPYIN(c1es, c2es, ...)
as here for the ICON weather model. This clearly implies that other
co
On 6/24/25 6:09 AM, Andre Vehreschild wrote:
Hi all,
this series of patches (six in total) adds a new coarray backend library to
libgfortran. The library uses shared memory and processes to implement
running multiple images on the same node. The work is based on work started by
Thomas and Nico
they get issues with a series of patches, that build upon each
other.
Just try it. The more feedback, the better.
Regards,
Andre
On Tue, 24 Jun 2025 11:07:23 -0700
Jerry D wrote:
On 6/24/25 6:09 AM, Andre Vehreschild wrote:
Hi all,
this series of patches (six in total) adds a new
On 7/2/25 9:40 AM, Jerry D wrote:
On 7/2/25 3:14 AM, Andre Vehreschild wrote:
Hi all,
I successfully created a big mess with the previous patch. First of all by
applying an outdated one and secondly by adding the conformance checks for
coranks in a3f1cdd8ed46f9816b31ab162ae4dac547d34ebc
On 7/2/25 4:12 PM, Jerry D wrote:
On 7/2/25 9:40 AM, Jerry D wrote:
On 7/2/25 3:14 AM, Andre Vehreschild wrote:
Hi all,
I successfully created a big mess with the previous patch. First of all by
applying an outdated one and secondly by adding the conformance checks for
coranks in
On 7/2/25 9:02 AM, Steve Kargl wrote:
On Wed, Jul 02, 2025 at 04:36:38AM -0700, Damian Rouson wrote:
git branch
gir checkout
git add
git commit
git rebase
git push
The above IS the process everyone uses on gcc. The email is only a "pull
request" for reviewing the patches. It works quite wel
On 7/2/25 3:14 AM, Andre Vehreschild wrote:
Hi all,
I successfully created a big mess with the previous patch. First of all by
applying an outdated one and secondly by adding the conformance checks for
coranks in a3f1cdd8ed46f9816b31ab162ae4dac547d34ebc. Checking the standard even
using AI (haha
On 7/1/25 12:51 PM, Harald Anlauf wrote:
Dear all,
the attached patch fixes the following minor issues found by running
f951 under valgrind for the just added new testcases coindexed_6.f90
and coindexed_7.f90:
- minor front-end memleaks with non-freed strings and lost GMP variables
(these are
Hi all,
With latest trunk this morning after Andre's commits I am still getting failures
with Toon's random_weather.f90.
Was there another patch I missed?
Jerry
$ gfc -fcoarray=single random-weather.f90
f951: internal compiler error: in gfc_ref_this_image, at fortran/expr.cc:5948
0x21dce1f i
On 6/27/25 1:08 PM, Toon Moene wrote:
On 6/27/25 17:41, Toon Moene wrote:
Note: as the timeline at the top of the source implies, I have worked on this
until early 2021.
This means it compiled with gfortran 10 and 11.
So the problem is probably introduced after these versions.
[ Of course,
On 6/26/25 12:22 AM, Andre Vehreschild wrote:
Hi Jerry,
thanks for testing. I have fixed IMO most of the whitespace issues in the
patch attached to this mail:
https://gcc.gnu.org/pipermail/fortran/2025-June/062349.html
About the 32 vs. 64 bit versions of the libraries: I never got in touch with
plify the process of
testing for those who would like to just check out the branch and build it.
Regards,
Jerry
On 7/17/25 5:44 PM, Jerry D wrote:
On 7/16/25 7:13 AM, Andre Vehreschild wrote:
Hi Jerry,
I am back on track.
--- snip ---
After some back and forth with Andre I finally understan
On 7/16/25 7:13 AM, Andre Vehreschild wrote:
Hi Jerry,
I am back on track.
--- snip ---
After some back and forth with Andre I finally understand the discrepancies I
was having here. Andre has an OpenCoarrays branch being used to update
OpenCoarrays to sync with changes to gfortran-16. Thi
On 7/19/25 5:06 PM, Jerry D wrote:
On 7/19/25 2:26 PM, Thomas Koenig wrote:
I wrote:
I have grave concerns.
At the last (to me an Nicolas) known state, before he was ousted
from the project, there were known race conditions, which can
cause freezing and/or data corruption.
I believe these
On 7/22/25 11:28 AM, Harald Anlauf wrote:
Dear all,
the attached patch fixes a long-standing issue with legacy code,
where an assumed-length character function is passed as actual
argument to a procedure, and when there is no explicit interface.
The solution is to do the same as in the case when
Everyone, as we identify issues during testing, can you please Open a PR so we
do not lose track. I started one already. I suggest we prefix the summary with
[caf_shmem] so we can see them easily.
Andre, if you have a patch on top of what I have in devel/gfortran-test to
address an issue can y
On 7/27/25 1:25 PM, Harald Anlauf wrote:
Gesendet: Sonntag, 27. Juli 2025 um 21:18
Von: "Mikael Morin"
An: "Andre Vehreschild"
CC: "Harald Anlauf" , fortran@gcc.gnu.org
Betreff: Re: Add: [Bug fortran/121043] [16 Regression] Tests of OpenCoarray
fail to pass, works on 15.1.1 20250712
Le 27/07/
With your updated patch addressing Steve's comments OK.
We have time for minor tweaks if necessary.
On 8/3/25 11:06 AM, Steve Kargl wrote:
On Sun, Aug 03, 2025 at 12:20:24PM +0100, Paul Richard Thomas wrote:
First, the easy one:
+ /* Match the binding name; depending on type (operator / gen
On 8/4/25 10:31 AM, Yuao Ma wrote:
Hi all,
I am trying to understand the effect of the lower argument in the c_f_pointer
procedure. If I am correct, should the following test case pass?
If FPTR is an array, its shape is specified by SHAPE; the lower
bounds are specified by LOWER if it is pr
On 1/1/22 10:27 AM, James Secan via Fortran wrote:
This may be considered OT, but from an old code wrangler who started with
FORTRAN II in the 1960s I want to thank everyone who keeps gfortran working and
current, and wish all of you the best in 2022.
Jim Secan
Seattle, WA 98115
Thanks James,
On 1/13/22 12:56 PM, Harald Anlauf via Fortran wrote:
Dear all,
there was a regression handling overloaded elemental intrinsics,
leading to an ICE on valid code. Reported by Urban Jost.
The logic for when we need to scalarize a call to an intrinsic
seems to have been broken during the 9-releas
Is there any reason these patches can not be applied and use this test
as a test case?
Regards,
Jerry
On 1/24/22 8:11 AM, Salvatore Filippone via Fortran wrote:
Thanks a lot
(yes, I suspected both gfortran and intel were wrong, precisely because I
could see why you'd need two FINAL calls, but
Remember the days when reading very old cryptic Fortran code? Remember
the fixed line lengths and cryptic variable names!
I fear the Standards committee has achieved history with the Standard
itself it is so difficult to understand sometimes.
Cheers to Paul and Harald for digging on this.
Je
For what it is worth.
On 2/10/22 11:49 AM, Harald Anlauf via Fortran wrote:
Hi Paul,
Am 10.02.22 um 13:25 schrieb Paul Richard Thomas via Fortran:
Conclusions on ifort:
(i) The agreement between gfortran, with the patch applied, and ifort is
strongest of all the other brands;
(ii) The disagree
On 2/23/22 2:21 PM, Harald Anlauf via Fortran wrote:
Dear Fortranners,
Fortran 2018 added a QUIET= specifier to STOP and ERROR STOP statements.
Janne already implemented the library side code four (4!) years ago,
but so far the frontend implementation was missing.
Furthermore, F2018 allows for
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.
Contr
On 4/4/22 12:04 PM, Harald Anlauf via Fortran wrote:
Dear all,
Steve's analysis (see PR) showed that we confused the case when a
symbol refererred to a recursive procedure which was named the same
as an intrinsic. The standard allows such recursive references
(see e.g. F2018:19.3.1).
The attac
On 4/4/22 12:09 PM, Harald Anlauf via Fortran wrote:
Am 29.03.22 um 23:41 schrieb Harald Anlauf via Fortran:
Dear all,
during error recovery on invalid declarations of functions as
coarrays we may hit multiple places with NULL pointer dereferences.
The attached patch provides a minimal and cons
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
https://gcc.gnu.org/pipermail/fortran/2022-
Elliot,
Let me know what system you want the compiler to run on?
Linux, Windows, PowerPC?
I can guide you through installing on some of these.
Usually we build it from source. However, many linux distributions have
packages you can install easily.
Cheers,
Jerry
On 4/23/22 9:31 AM, Elliot
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
of
Hi Paul,
Long time no chat. I hope you and yours are well.
I was planning to retire early next year, but with the economy going
south on us I am going to hold off a bit. What a crazy world we are in!
I thought I would drop you a note when I noticed a gfortran finalization
bug 107489. Then
Hi all,
Some of you may recall way back when I established the gfortran IRC
channel to facilitate collaboration on gfortran development.
I have had some discussions with a few people about advancing to newer
technology. One thing I have learned is that the gcc C++ team has
adopted the Matte
workspace. If anyone want to join send me
your email and I will send you an invite.
Well, as always, best regards,
Jerry
On 12/4/22 6:16 AM, Benson Muite wrote:
On 12/4/22 06:52, Jerry D via Fortran wrote:
3. Mattermost looks pretty good and was easy to set up. The free
version is a bit
On 12/8/22 9:25 AM, Tobias Burnus wrote:
Hi,
On 08.12.22 17:27, Steve Kargl via Fortran wrote:
On Wed, Dec 07, 2022 at 05:54:40PM -0800, Jerry D via Fortran wrote:
Other than Benson, I have received no sign of any interest from
gfortran
developers to adopt a teaming/collaboration platform
On 12/8/22 11:14 AM, Holcomb, Katherine A (kah3f) via Fortran wrote:
I was thinking I might try to contribute when I retire, though that may be in a year or
two. But it's been a very long time since I dove into a large software project and it's
intimidating. I do know C (really C++, I haven't
On 12/10/22 1:23 PM, Harald Anlauf via Fortran wrote:
Dear all,
I'm submitting the attached patch on behalf of Steve.
It fixes an ICE that occurs on an obscure use of a
statement function as argument to that function.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
OK, lo
On 12/13/22 12:10 AM, Janne Blomqvist wrote:
--- snip --
Any thoughts from all?
Hi,
I haven't commented earlier as I haven't been active in GFortran
development for a couple of years (new job, kids, etc. etc.). So don't
take my opinions too seriously.
But in general, yes, I do think IRC is sh
Hi all,
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 "simple" rule in a little while.
Thanks Steve for Patch. Thanks Harald for helping me get back up to
speed on the g
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
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 not need
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 spec,
On 12/23/22 6:08 AM, Thomas Schwinge wrote:
Hi!
On 2022-11-11T15:35:44+0100, Richard Biener via Fortran
wrote:
On Fri, Nov 11, 2022 at 3:13 PM Thomas Schwinge wrote:
For example, for Fortran code like:
write (*,*) "Hello world"
..., 'gfortran' creates:
struct __st_parameter_dt
On 1/5/23 1:14 PM, Harald Anlauf via Fortran wrote:
Resending as plain text, as the original version did not appear on the fortran
list...
Gesendet: Donnerstag, 05. Januar 2023 um 22:10 Uhr
Von: "Harald Anlauf"
An: "Paul Richard Thomas"
Cc: "fortran@gcc.gnu.org" , "Alessandro Fanfarillo"
On 1/11/23 4:06 AM, Thomas Schwinge wrote:
Hi!
Ping -- the '-mframe-malloc-threshold' idea, at least.
Note that while this issue originally did pop up for Fortran I/O, it's
likewise relevant for other functions that maintain big frames, for
example in newlib:
libc/string/libc_a-memmem.o:.
On 1/18/23 7:42 AM, Tobias Burnus wrote:
Reported by nightstrike, who also tested this patch.
On Windows, we call system() which works as described at
https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/system-wsystem?view=msvc-170
Namely, it only fails with "-1" if the command in
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
On 1/19/23 10:21 PM, Benson Muite via Fortran wrote:
On 1/19/23 22:03, NightStrike wrote:
On Thu, Jan 19, 2023, 13:33 Bernhard Reutner-Fischer
mailto:rep.dot@gmail.com>> wrote:
On 19 January 2023 13:52:55 CET, NightStrike via Fortran
mailto:fortran@gcc.gnu.org>> wrote:
>Yo
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
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 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/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
201 - 300 of 344 matches
Mail list logo
