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
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
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:
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/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
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:
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 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 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 not
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
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
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
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,
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
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
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
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
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
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
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
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
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.
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
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.
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,
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
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
Paul, great for getting this posted! I would approve but maybe Sandra
should.
Regardless, thanks for getting this together.
Best Regards,
Jerry
On 11/2/21 1:18 AM, Paul Richard Thomas via Fortran wrote:
Hi Sandra,
Some weeks ago Andrew Benson triggered me to recover a patch for
Looks OK.
Cheers
On 10/29/21 11:58 AM, Bernhard Reutner-Fischer via Fortran wrote:
ping
On Wed, 5 Sep 2018 14:57:04 +
Bernhard Reutner-Fischer wrote:
From: Bernhard Reutner-Fischer
Aids debugging the fortran FE.
gcc/ChangeLog:
2017-11-12 Bernhard Reutner-Fischer
*
Looks good and simple. Proceed. Thanks
Jerry
On 10/28/21 5:05 PM, Bernhard Reutner-Fischer via Fortran wrote:
ping
[Rebased, re-regtested cleanly. Ok for trunk?]
On Wed, 5 Sep 2018 14:57:31 +
Bernhard Reutner-Fischer wrote:
From: Bernhard Reutner-Fischer
compiling
This one looks OK. Sorry I missed it earlier. Thanks again for the patch!
Jerry
On 10/9/21 12:27 PM, Harald Anlauf via Fortran wrote:
*Ping*
Am 03.10.21 um 21:20 schrieb Harald Anlauf via Fortran:
Dear Fortranners,
when initializing parameter arrays from scalars, we did handle only
the
On 10/8/21 2:33 PM, Harald Anlauf via Fortran wrote:
Dear Fortranners,
F2018:10.1.5.5.1(2) requires the same interpretation of old and new-style
relational operators. We internally distinguish between old and new style,
but try to map appropriately when used.
This mapping was missing when
Harald,
Looks good. OK and thanks for your time and efforts.
Jerry
On 9/23/21 12:47 PM, Harald Anlauf via Fortran wrote:
Dear Fortranners,
we missed certain intrinsics as being disallowed in constant expressions,
which lead to an ICE when these intrinsics were used in a specification
Good to go Tobias.
Jerry
On 7/14/21 5:50 AM, Burnus, Tobias wrote:
Ping**2
On Juli 8, 2021 I wrote:
*Ping*
I intent to incorporate Sandra's suggestions, except for the beginning of line
spacing - that's needed to avoid exceeding the 80 character line limit. I did
not include an updated
Looks OK Thomas,
Good for backport as well.
Regards,
Jerry
On 7/4/21 9:09 AM, Thomas Koenig via Fortran wrote:
Hello world,
after a bit of an absence, I am now back, at least for some regression
fixing (and for reviewing patches, if that is called for).
So, here's a regression fix to start
yes, please commit
On 5/21/21 8:08 AM, Steve Kargl via Fortran wrote:
On Fri, May 21, 2021 at 10:09:02AM +0200, Andre Vehreschild wrote:
Ping, ping!
Please find attached a rebased version of the patch for the RANDOM_INIT issue
with coarray Fortran. Nothing changed to the previous version,
101 - 139 of 139 matches
Mail list logo
