On Thu, Jul 31, 2025 at 01:34:14PM -0700, Steve Kargl wrote:
>
> It seems that
>
> module foo
> implicit none
> private
> public bar
> generic :: bar => bar, bah
> end module
>
> is not accepted.
>
As a follow-up, this is accepted with yo
On Wed, Jul 23, 2025 at 05:53:17PM +0100, Paul Richard Thomas wrote:
>
>
> Regtests on x86_64/FC42 - OK for mainline?
>
Here's another testcase that fails.
% gfcx -o z a_gen2.F90 && ./z
42.000
43.500
% gfcx -o z -DGEN a_gen2.F90
a_gen2.F90:9:21:
9 |generic :: ba
On Wed, Jul 23, 2025 at 05:53:17PM +0100, Paul Richard Thomas wrote:
>
> The attached implements the F2018 generic statement, which has the same
> semantics as the typebound version but can appear in any specification
> statement.
>
> As it says in the first comment in the patch, use is made of t
On Tue, Jul 29, 2025 at 10:29:37PM +0200, Harald Anlauf wrote:
>
> - I am a little confused about the handling of the access specification.
> After the first "public :: g", NAG complains about the
>
> generic, public :: g ...
>
> and only allows
>
> generic :: g ...
>
> Then duplicate pub
On Sun, Jul 27, 2025 at 02:47:14PM +0200, Mikael Morin wrote:
> From: Mikael Morin
>
> Regression-tested on x86_64-pc-linux-gnu.
> OK for master?
>
Looks ok to me. Of course, the last time I reviewed one
of your patches, polymorphism got in the way of what appeared
to be straight forward clea
On Sat, Jul 26, 2025 at 11:57:50PM +0800, Yuao Ma wrote:
>
> On 7/26/2025 11:25 PM, Steve Kargl wrote:
> > On Sat, Jul 26, 2025 at 09:14:43PM +0800, Yuao Ma wrote:
> > > + add_sym_4s ("split", GFC_ISYM_SPLIT, CLASS_IMPURE,
> > > + BT_UNKNOWN, 0, GFC_
On Sat, Jul 26, 2025 at 09:14:43PM +0800, Yuao Ma wrote:
>
> + add_sym_4s ("split", GFC_ISYM_SPLIT, CLASS_IMPURE,
> + BT_UNKNOWN, 0, GFC_STD_F2023,
> + gfc_check_split, NULL, gfc_resolve_split,
> + "string", BT_CHARACTER, dc, REQUIRED, INTENT_IN,
> + "set"
On Sun, Jul 20, 2025 at 12:39:00AM +0800, Yuao Ma wrote:
> On 7/18/2025 11:43 PM, Yuao Ma wrote:
> > I noticed that hex(16128084538487209988) evaluates to
> > 0xdfd27774, and it looks like the higher bits weren't being
> > zeroed out as expected. After I explicitly added pos =
> > convert(g
On Sat, Jul 19, 2025 at 12:08:44AM +0800, Yuao Ma wrote:
> Hi Tobias,
>
> On 7/18/2025 3:16 PM, Tobias Burnus wrote:
> > I am wondering whether we should implement it – for kind=1 (and at
> > least for set len=1) by a call to BUILT_IN_MEMCHR / BUILT_IN_MEMRCHR.
> > For set len > 1, a loop around
On Sun, Jul 13, 2025 at 10:59:32AM +0200, Mikael Morin wrote:
>
> Regression tested on x86_64-pc-linux-gnu.
> OK for master?
>
Yes, with one observation below.
> diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
> index 1561936daf1..af62e17442b 100644
> --- a/gcc/fortran/tran
All, Paul,
In testing Paul's recent addition of support for IMPORT,
I have uncovered an ICE due to mangled source code. The
code leads to a NULL pointer dereference. The patch that
follows my .sig fixes the issue. Note the testcase has one
FAIL.
% gmake check-fortran RUNTESTFLAGS="dg.exp=impor
All,
Paul recently committed a change that brings gfortran's
IMPORT statement into conformance with the Fortran 2018
and 2023. (Thanks, Paul!).
Here's a note for the Release Notes. I'm not who needs
to approve this or who can actually do the commit.
diff --git a/htdocs/gcc-16/changes.html b
On Wed, Jul 09, 2025 at 08:50:08AM +0200, Andre Vehreschild wrote:
>
> why shall the testcase be invalid?
See the 2nd bullet in Fortran 2023, 9.7.1.3 Allocation
of allocatable variables.
An allocatable variable has a status of "unallocated"
if it is not allocated.
...
An allocata
On Mon, Jul 07, 2025 at 08:53:16PM +0200, Harald Anlauf wrote:
> Andre,
>
> I still don't get it, and the present version made it worse for me...
>
> So let's see what I was thinking. There are the following types of
> functions:
>
> (0) impure, non-elemental functions, which likely have side-e
On Sun, Jul 06, 2025 at 09:09:53PM +0800, Yuao Ma wrote:
> Hi Tobias,
>
> On 7/6/2025 6:34 PM, Tobias Burnus wrote:
> > As that commit is from 2020 and 2.69 in from 2012, it seems as if your
> > autoconf is too new. Can you re-check that the right version is at the
> > beginning of the PATH?
> >
On Sun, Jul 06, 2025 at 08:43:06AM +0800, Yuao Ma wrote:
> Hi Steve,
>
> On 7/6/2025 12:25 AM, Steve Kargl wrote:
> > On Sat, Jul 05, 2025 at 05:20:02PM +0800, Yuao Ma wrote:
> > > diff --git a/libgfortran/configure b/libgfortran/configure
> > > index 9898a94a37
Paul,
Either resolve.cc has sufficiently evolved since you
submitted your patch or the patch is somehow mangled.
When I apply it to my tree for resolve.cc, I see
Hunk #1 succeeded at 3919.
Hunk #2 succeeded at 4223.
Hunk #3 succeeded at 7940 (offset -28 lines).
Hunk #4 succeeded at 8068 (offset
On Sat, Jul 05, 2025 at 05:20:02PM +0800, Yuao Ma wrote:
>
> diff --git a/libgfortran/configure b/libgfortran/configure
> index 9898a94a372..971f1e9df5e 100755
> --- a/libgfortran/configure
> +++ b/libgfortran/configure
> @@ -16413,7 +16413,7 @@ else
> We can't simply define LARGE_OFF_T to b
On Thu, Jul 03, 2025 at 10:12:52PM +0200, Mikael Morin wrote:
> From: Mikael Morin
>
> Regression-tested on aarch64-unknown-linux-gnu.
> OK for master?
>
Yes. Almost looks obvious once someone finds and fixes the issue.
Thanks for the patch.
--
Steve
On Thu, Jul 03, 2025 at 02:43:43PM +0200, Michael Matz wrote:
> Hello,
>
> On Thu, 3 Jul 2025, Yuao Ma wrote:
>
> > This patch adds the required function for Fortran trigonometric functions to
> > work with glibc versions prior to 2.26. It's based on glibc source commit
> > 632d895f3e5d98162f77b9
On Thu, Jul 03, 2025 at 12:56:24AM +0800, Yuao Ma wrote:
>
> This patch adds the required function for Fortran trigonometric functions to
> work with glibc versions prior to 2.26. It's based on glibc source commit
> 632d895f3e5d98162f77b9c3c1da4ec19968b671.
>
> I've built it successfully on my en
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
>
> It’s time to move beyond emailing patches! (Please.)
I don't use git other than 'git clone', 'git reset --hard',
and 'git diff'. If gfortran development
Andre,
I've never built gcc for aarch64-freebsd. I was going to
suggest doing the full bootstrap, but that seems to be too
slow. On amd64, I use
../gcc/configure --prefix=$WDIR \
--enable-languages=c,c++,fortran,lto \
--enable-bootstrap \
--disable-nls \
--disable-libssp \
--disa
On Sun, Jun 29, 2025 at 06:54:53PM -0700, Steve Kargl wrote:
> On Sun, Jun 29, 2025 at 03:30:21PM -0700, Steve Kargl wrote:
> > On Sun, Jun 29, 2025 at 11:07:31AM -0700, Steve Kargl wrote:
> > > On Sun, Jun 29, 2025 at 10:35:39AM -0700,
Yet, another head scratcher.
../../../gcc/libgfortran/caf/shmem/supervisor.c:235:27: error: 'environ'
undeclared (first use in this function)
235 | for (char **e = environ; *e; ++e, ++n)
| ^~~
I see 'extern char **environ;' in shmem.c. Is this sup
On Sun, Jun 29, 2025 at 07:06:57PM -0700, Steve Kargl wrote:
> On Sun, Jun 29, 2025 at 06:54:53PM -0700, Steve Kargl wrote:
> >
> > /usr/local/bin/ld: cannot find -lcaf_shmem: No such file or directory
> > collect2: error: ld returned 1 exit status
> > compiler exited
On Sun, Jun 29, 2025 at 06:54:53PM -0700, Steve Kargl wrote:
>
> /usr/local/bin/ld: cannot find -lcaf_shmem: No such file or directory
> collect2: error: ld returned 1 exit status
> compiler exited with status 1
>
> The freshly built gfortran cannot find the libcaf_shmem.a.
On Sun, Jun 29, 2025 at 03:30:21PM -0700, Steve Kargl wrote:
> On Sun, Jun 29, 2025 at 11:07:31AM -0700, Steve Kargl wrote:
> > On Sun, Jun 29, 2025 at 10:35:39AM -0700, Steve Kargl wrote:
> > >
> > > === gfortran Summary ===
> > >
> &g
On Sun, Jun 29, 2025 at 11:07:31AM -0700, Steve Kargl wrote:
> On Sun, Jun 29, 2025 at 10:35:39AM -0700, Steve Kargl wrote:
> >
> > === gfortran Summary ===
> >
> > # of expected passes73149
> > # of unexpected failures522
I
On Sun, Jun 29, 2025 at 08:36:38PM +0200, Andre Vehreschild wrote:
>
> I would do git am pr88076_v1_1.patch or patch -p1 each of the patch files. Then they go where they ought to be.
Thanks. I needed -p1 for v1_5 and v1_6.
> Pro tip: create a new branch before doing the git am, then you can ju
On Sun, Jun 29, 2025 at 10:35:39AM -0700, Steve Kargl wrote:
>
> Just applied the 6 patch (with the update part 5). I'm
> seeing a significant increase in the number of failures
> in 'make check-fortran' testing.
>
Just re-applied your patches in the top-level g
On Sun, Jun 29, 2025 at 10:35:39AM -0700, Steve Kargl wrote:
>
> === gfortran Summary ===
>
> # of expected passes73149
> # of unexpected failures522
> # of expected failures 343
> # of unresolved testcases 78
>
On Thu, Jun 26, 2025 at 10:15:01AM +0200, Andre Vehreschild wrote:
>
> I deem this library fit for educational and research use,
> where small to medium sized problems are researched. I do
> not expect it to support a long term running application,
> because is does not join adjacent blocks in th
On Tue, Jun 24, 2025 at 03:09:33PM +0200, Andre Vehreschild wrote:
>
> 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 starte
Thanks for cleaning up gfortran code. I was curious about
what the GNU Coding Standard said about this case, but it
does not consider initialization of subobjects. I did find
5.3 Clean Use of C Constructs
...
Don't make the program ugly just to placate static
analysis tools such as l
On Wed, Jun 25, 2025 at 04:09:26PM +0200, Martin Jambor wrote:
> Hi,
>
> When compiling fortran/match.cc, clang emits a warning
>
> fortran/match.cc:5301:7: warning: variable 'p' is used uninitialized
> whenever 'if' condition is true [-Wsometimes-uninitialized]
>
> which looks accurate, so t
test. There will be bugs, because nobody is perfect.
>
> @Steve caf_shmem does not use MPI. It is a shared memory, single node, multi
> process approach. Just to prevent any misunderstanding.
>
> Thanks for all the testing.
>
> Regards,
> Andre
>
> On Tue, 24
On Tue, Jun 24, 2025 at 09:00:46PM +0200, Harald Anlauf wrote:
>
> here's an obvious fix for a recent regression: substring offset
> calculations used a wrong type that crashed in gimplification.
> Andre basically OK'ed it in the PR, but here it is nevertheless.
>
> Regtested on x86_64-pc-linux-g
Damian,
I submitted a patch a long time ago to make -fcoarray=single the
default behavior. The patch made -fcoarray=none a NOP. With
inclusion of a shmem implementation of the runtime parts, this
might be the way to go. I'll leave that decision to Andre, Thomas,
and Nicolas.
I believe that the
On Tue, Jun 17, 2025 at 12:05:34PM +0300, Janne Blomqvist wrote:
> On Mon, Jun 16, 2025 at 9:41 PM Harald Anlauf wrote:
> >
> > Am 16.06.25 um 02:18 schrieb Steve Kargl:
> > > Harald,
> > >
> > > I did a quick glance at the patch and did not see anything
would overflow assignment to integer(kind=4), and does not
> return ERANGE as in v1 of this patch. There is no need to modify
> the existing testcasese stat_{1,2}.f90.
>
> Cheers,
> Harald
>
> Am 12.06.25 um 22:12 schrieb Harald Anlauf:
> > Hi Steve,
> >
> > On 6
On Wed, Jun 11, 2025 at 10:18:37PM +0200, Harald Anlauf wrote:
>
> the attached patch is a first attempt to fix some issues with the GNU
> intrinsics STAT/LSTAT/FSTAT which are g77 heritage. This patch is
> preparatory for dealing with the issue reported in PR82480 in that
> the default version o
On Fri, Jun 06, 2025 at 02:34:09PM +0200, FX Coudert wrote:
>
> 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 wit
On Fri, May 30, 2025 at 09:03:27PM +0200, Harald Anlauf wrote:
>
> the time needed for running the gfortran testsuite has increased so
> much that I am looking for options to get this down to something
> that is more bearable when working on a Fortran-only patch.
>
> I am already building with --
On Fri, May 30, 2025 at 07:37:49PM +0200, Harald Anlauf wrote:
>
> here's a patch fixing the handling of parameter inquiries of
> constant complex arrays. It profits from previous fixes for
> inquiries of substrings and essentially adds only the simplification
> of %re/%im applies to complex arra
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 845768cbead03f76265e491bcf5ea6de7020ff39
> Author: Jerry DeLisle
>
On Tue, May 27, 2025 at 02:17:46PM +, Yuao Ma wrote:
>
> I've reverted the recent format changes, as three reviewers indicated they
> caused more harm than good.
>
Thank you.
> Are there any functional problems I need to address?
I did not see any additional functional issues. Patch is
OK
On Mon, May 26, 2025 at 09:30:59AM +, Yuao Ma wrote:
> Hi Steve,
>
> > I looked at the patch in a bit more detail, and
> > I am not thrilled with large-scale whitespace
> > changes mingled with functional changes. It makes
> > the patch harder to read and review.
>
> I'm not sure which file y
On Sun, May 25, 2025 at 04:56:48AM +, Yuao Ma wrote:
>
> Thanks for your review! I've updated the patch.
>
> > this range_check() is unneeded.
>
> Done.
>
> > As a side note, the error message is slightly misleading
> > (although it will not be issued). Technically, x = -1 or 1
> > are all
Apologies for late a late reply. A quick skim of the code
suggests that you can eliminate some of the range_check()
calls in the simplifications. For example, you have
+gfc_expr *
+gfc_simplify_acospi (gfc_expr *x)
+{
+ gfc_expr *result;
+
+ if (x->expr_type != EXPR_CONSTANT)
+return NULL;
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.
>
Good catch, Harald. We
On Mon, May 05, 2025 at 08:30:09PM -0700, Jerry D wrote:
> Attached patch fixes this by checking for BT_VOID and EXPR_FUNCTION.
>
> Thank you for guidance from Steve in the PR and Vincent for
> identifying the problem.
>
> Two test case files added to the testsuite.
>
> Regression tested on x86_
On Wed, Apr 16, 2025 at 04:44:23AM +, ZAPART CHRISTOPHER ANDREW wrote:
>
> After a recent upgrade from Fedora 41 to 42 the gfortran got updated from 14
> to 15.0.1:
>
> [chris@fedora FITSWEBQLSE]$ gfortran --version
> GNU Fortran (GCC) 15.0.1 20250329 (Red Hat 15.0.1-0)
>
> The new version
On Mon, Apr 07, 2025 at 02:42:10PM +0800, Gwen Fu wrote:
> Thanks for your reply !
> >The word "parameter" has very a specific meaning in Fortran. The
> >entity that is passed into a function or subroutine is an "actual
> >argument". The entity within the functions associated with the
> >"actual ar
On Sat, Apr 05, 2025 at 03:16:45PM +0800, Gwen Fu wrote:
> My doubt :
> 1.Does the compilation option only need to support fortran versions above
> 9, o5r does it also need to support fortran 77?
gfortran started life as a Fortran 95 compiler. It should
support anything that is Fortran 95 or late
On Thu, Mar 27, 2025 at 03:43:49PM +, Yuao Ma wrote:
>
> Thanks for sharing more details. I’ve realized that implementing half-cycle
> trig functions can be quite tricky. If I get the chance to refine the patch,
> I’d like to go through each function one by one (if the reviewers don’t mind),
>
On Fri, Apr 04, 2025 at 02:40:06AM -0400, NightStrike wrote:
>
> Is this email list still active? :)
Are you subscribed to the list?
First reply:
https://gcc.gnu.org/pipermail/fortran/2025-March/061963.html
Second reply:
https://gcc.gnu.org/pipermail/fortran/2025-March/061981.html
--
Steve
On Sun, Mar 30, 2025 at 02:06:31PM +, Yuao Ma wrote:
>
> I have uploaded a draft proposal for the 'Fortran – 2018/202x' project to the
> platform. You can also find a PDF version at this Google Drive link:
> https://drive.google.com/file/d/1cSRPuWpXWHMwHdNItQluEYspLfylqZcU.
I rarely follow ra
On Fri, Mar 28, 2025 at 02:02:03PM -0400, NightStrike wrote:
>
> Should I open a bugzilla PR about this?
>
Submit the 3-character patch to fix the error to
point to -fallow-invalid-boz instead of the negative
form -fno-allow-invalid-boz, which seems to have
led to a manner of confusion.
Other th
starting point for the project!
>
> Yuao
> ____
> From: Steve Kargl
> Sent: Tuesday, March 25, 2025 2:25
> To: Yuao Ma
> Cc: fortran@gcc.gnu.org
> Subject: Re: GSoC Fortran – 2018/202x – Inquiry About Project Scope
>
> I've already written a prototype of the half-cycl
TL;DR version: fix your code.
On Tue, Mar 25, 2025 at 11:04:52AM -0400, NightStrike wrote:
> Between GCC 9 and 10, the following code now errors out:
>
Did you read the Release Notes for 10.1? Under the Fortran header:
The handling of a BOZ literal constant has been reworked to provide
On Tue, Mar 25, 2025 at 08:34:51PM +0800, Gwen Fu wrote:
> I found out that "-fcheck=*" is an option for runtime checking, but the
> relevant options are commented out.
> OPT_fcheck_ = 1070,/* -fcheck= */
> /* OPT_fcheck_assert = 1071, *//* -fcheck=assert */
On Mon, Mar 24, 2025 at 09:40:38PM +0100, Thomas Koenig wrote:
>
> Regression-tested. Again no test case because I don't know
> how. During testing, I also found that vtabs were dumped,
> this is also corrected.
>
> OK for trunk?
Thanks for working on this, but ...
>
> /* This section deals
On Mon, Mar 24, 2025 at 08:46:50PM +0200, Janne Blomqvist wrote:
> On Mon, Mar 24, 2025 at 8:25 PM Steve Kargl
> wrote:
> >
> > I've already written a prototype of the half-cycle trig
> > functions.
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=1131
I've already written a prototype of the half-cycle trig
functions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113152
There are two issues that need to be address. First, some
operating systems provide half-cycle trig functions in their
libm. The initial patch tries to use libm functions if
f
On Sun, Mar 23, 2025 at 10:09:46AM +0100, Thomas Koenig wrote:
> Hi Paul,
>
> > By the way, the standard just specifies integer for 'dim' in reduce,
> > which I take to mean it should be default_integer_kind.
>
> Hmm... I'm not sure that this is actually the case; I believe it
> can actually be a
On Wed, Mar 19, 2025 at 11:08:58PM +0100, Harald Anlauf wrote:
>
> the attached patch addresses an actually very long-standing issue
> with bogus bounds checks for components of nested derived types in
> assignments when an intermediate level has the POINTER attribute
> instead of the ALLOCATABLE
On Sat, Mar 08, 2025 at 01:52:06PM +0100, Thomas Koenig wrote:
>
> the attached patch fixes an ICE regresseion where undo state was not
> handled properly when generating formal from actual arguments, which
> occurred under certain conditions with the newly introduced
> -Wexternal-argument-mismatc
Andre,
Here's a bit of wordsmith. I removed the abbreviation "Esp."
I'm not sure if there is additional markup needed; especially,
with the "-fcoarray=single" I inserted.
Coarray support has been reworked to allow access to components
in derived types that have not been compiled with coarray
On Thu, Mar 06, 2025 at 10:49:08PM +0100, Harald Anlauf wrote:
>
> Thanks for the speedy review!
>
It was a bit easier than normal. After I submitted
the PR, I started to poke around in fortran/resolve.cc
to see if I could deal with the issue. I saw that you
grab the PR last night, and left yo
On Thu, Mar 06, 2025 at 10:04:08PM +0100, Harald Anlauf wrote:
>
> this patch fixes an interesting regression that prevented substring
> bounds checks from being generated if the substring start was not a
> variable, but rather a constant or an expression.
>
> The fix I chose turned out to be a l
On Mon, Mar 03, 2025 at 03:58:24PM +0100, Andre Vehreschild wrote:
>
> attached patches fix a 12-regression, when a caf token is requested from an
> abstract class-typed dummy. The token was not looked up in the correct spot.
> Due the class typed object getting an artificial variable for direct d
On Sat, Mar 01, 2025 at 03:56:21PM +0100, Harald Anlauf wrote:
>
> the attached patch fixes a front-end memleak that is seen when
> running f951 under valgrind and while parsing invalid uses of
> NULLIFY.
>
> I had this in my tree for some time without any problems, in an
> attempt to further red
On Sun, Feb 16, 2025 at 09:36:20AM +0100, Thomas Koenig wrote:
>
> this patch is a variation of Jakub's patch in the PR, which
> avoids overflow on the mask used for exponentiation and
> fixes unsigned HOST_WIDE_INT. I tried testing this on
> a POWER machine, but --with-build-config=bootstrap-ubs
On Fri, Feb 07, 2025 at 09:31:12PM +0100, Harald Anlauf wrote:
>
> Regtested on x86_64-pc-linux-gnu. OK for mainline?
>
Looks reasonable.
> While it is a really old bug but wrong code, I'd like to backport
> this also at least to 14-branch. Any reservations?
If it passes regression testing,
On Mon, Feb 03, 2025 at 01:34:09PM -0500, Andi McClure wrote:
>
> open(10,file=path,access='stream',form='unformatted',action='read',iostat=file_error)
You opened the file with form='unformatted'.
> READ (iu,"()", ADVANCE='NO', POS=file_pos) ! iu is file unit
You then try to use a format statem
> Summary: It is my opinion from the FORTRAN 2023 spec that the first test
> program above should have worked and the additional steps in the second
> test program should not have been necessary. Have I misread the spec, is
> there something wrong with my code, or have I identified a bug in gfortra
On Sat, Feb 01, 2025 at 09:49:17PM +0100, Harald Anlauf wrote:
> Am 01.02.25 um 21:03 schrieb Steve Kargl:
> > On Sat, Feb 01, 2025 at 07:25:51PM +0100, Harald Anlauf wrote:
> > >
> > > the attached patch downgrades different constant character lengths in an
> >
On Sat, Feb 01, 2025 at 07:25:51PM +0100, Harald Anlauf wrote:
>
> the attached patch downgrades different constant character lengths in an
> array constructor from a GNU to a legacy extension, so that users get a
> warning with -std=gnu. We continue to generate an error when standard
> conforman
On Mon, Jan 13, 2025 at 01:23:58AM +0100, Manfred Schwarb wrote:
> Am 11.01.25 um 07:36 schrieb Steve Kargl:
> > On Fri, Jan 10, 2025 at 05:19:34PM +, Paul Richard Thomas wrote:
> >>
> >> As of today, Gerhard Steinmetz has no fewer than 33 regressions to his name
&g
On Fri, Jan 10, 2025 at 05:19:34PM +, Paul Richard Thomas wrote:
>
> As of today, Gerhard Steinmetz has no fewer than 33 regressions to his name
> out of a total of 54 for fortran and libgfortran. It's time that some of
> these bugs are swatted, I think :-)
>
PR 70949 appears to have been fi
On Fri, Jan 10, 2025 at 05:19:34PM +, Paul Richard Thomas wrote:
>
> As of today, Gerhard Steinmetz has no fewer than 33 regressions to his name
> out of a total of 54 for fortran and libgfortran. It's time that some of
> these bugs are swatted, I think :-)
>
This patch fixes PR71844. As th
On Fri, Jan 10, 2025 at 09:41:13PM +, Harald Anlauf wrote:
>
> There is one question to the reviewer(s), or those knowing better
> than me how to handle IEEE infinity and NaN: with -Ofast, I needed
> to add "-fno-finite-math-only" to the new testcase
> gfortran.dg/ieee/out_of_range.f90, as the
On Fri, Jan 10, 2025 at 05:19:34PM +, Paul Richard Thomas wrote:
>
> As of today, Gerhard Steinmetz has no fewer than 33 regressions to his name
> out of a total of 54 for fortran and libgfortran. It's time that some of
> these bugs are swatted, I think :-)
>
When I was much more active in a
On Wed, Jan 08, 2025 at 10:33:53AM +0100, Jakub Jelinek wrote:
>
> As mentioned in the PR, there is a *.mod incompatibility between GCC 14 and
> GCC 15, at least when using iso_c_binding or iso_fortran_env intrinsic
> modules, because new entries have been added to those modules in the middle,
> c
On Tue, Jan 07, 2025 at 03:28:31PM +0100, Thomas Koenig wrote:
> Hello world,
>
> the attached patch does what it says in the ChangeLog entry.
>
> Tested with "make dvi" and "make pdf".
>
> OK for trunk?
>
OK.
--
Steve
I'm ok withi your patch. It seems to also catch PR113928.
You may want to give others a chance to chime in.
--
steve
On Thu, Dec 19, 2024 at 09:34:38PM +, Harald Anlauf wrote:
>
> the check for potential aliasing of lhs and rhs currently shortcuts
> if the types differ. This is a problem
On Wed, Dec 18, 2024 at 10:09:26AM -0800, Jerry D wrote:
> On 12/18/24 4:11 AM, Harald Anlauf wrote:
> > Hi Steve,
> >
> > thanks for the draft patch.
> >
> > I haven't looked close enough, but you may have to add support
> > for 'asis' being an optional dummy variable. The following
> > example
On Wed, Dec 18, 2024 at 01:11:14PM +0100, Harald Anlauf wrote:
>
> I haven't looked close enough, but you may have to add support
> for 'asis' being an optional dummy variable. The following
> example crashes here with a segfault:
>
(program snipped for brevity)
>
> There are other intrinsics
All,
First, I would like to thank both mikael and fx for providing
help in my debugging of the in-lining in trans-intrinsic.cc.
It seems I have forgotten much of what I once knew about trees.
I have attached a patch that implements F2023 F_C_STRING() to
https://gcc.gnu.org/bugzilla/show_bug.cgi?
On Mon, Dec 16, 2024 at 04:53:42AM -0800, Damian Rouson wrote:
> including automatic GPU offloading. Then a few months ago, the death blow
> that I couldn’t work around was robust support for kind type parameters.
>
gfortran doesn't have robust kind type parameters?
% cat xx.f90
program foo
I have taken the attempt at inlining f_c_string()
as far as I can. The WIP patch is attached to the
PR along with the final issue that I cannot resolve.
If anyone wants to finish the patch, feel free to
do so.
--
Steve
On Fri, Dec 13, 2024 at 03:09:57PM -0800, Steve Kargl wrote:
> On Fri, Dec 13, 2024 at 10:54:03PM +0100, Mikael Morin wrote:
> > Le 13/12/2024 à 21:55, Steve Kargl a écrit :
> > > On Mon, Dec 09, 2024 at 06:39:19PM -0800, Steve Kargl wrote:
> > > >
> > > &
On Fri, Dec 13, 2024 at 10:54:03PM +0100, Mikael Morin wrote:
> Le 13/12/2024 à 21:55, Steve Kargl a écrit :
> > On Mon, Dec 09, 2024 at 06:39:19PM -0800, Steve Kargl wrote:
> > >
> > > I've an almost complete implementation of F_C_STRING,
> > > but need
On Mon, Dec 09, 2024 at 06:39:19PM -0800, Steve Kargl wrote:
>
> I've an almost complete implementation of F_C_STRING,
> but need a bit of insight on the inlining that I'm
> trying to implement. In pseudo-code, F_C_STRING is
>
> case 1. f_c_string(string)
FX,
You're likely correct that the creation of an expression for
c_null_char is overkill. I copied the code from gfc_conv_concat_op()
in trans-expr.cc to get the 'f_c_string(s) -> trim(s) // c_null_char'.
This was the motivation of creating a string. If I look at the
-fdump-tree-orginal for
On Tue, Dec 10, 2024 at 09:05:02AM +0100, FX Coudert wrote:
> Hi Steve,
>
> > I've an almost complete implementation of F_C_STRING,
> > but need a bit of insight on the inlining that I'm
> > trying to implement.
>
> Maybe I can help. Can you send in your current patch?
>
FX,
I've attached the
All,
I've an almost complete implementation of F_C_STRING,
but need a bit of insight on the inlining that I'm
trying to implement. In pseudo-code, F_C_STRING is
case 1. f_c_string(string) = trim(string) // c_null_char
case 2. f_c_string(string, asis=.false.) = trim(string) // c_n
On Mon, Nov 25, 2024 at 10:05:49PM +, Harald Anlauf wrote:
> Dear all,
>
> the attached patch fixes an ICE when passing an inquiry reference of a complex
> array to an assumed-rank dummy argument by terminating the search for the
> array reference before we hit the inquiry reference. (The arr
On Fri, Nov 01, 2024 at 01:01:39PM +0100, Mikael Morin wrote:
> Le 30/10/2024 à 23:00, Harald Anlauf a écrit :
> >
> > given that Jakub changed lots of whitespace in r15-4624-g50332a4fdd3243,
> > you may want to rebase your patches onto HEAD of trunk.
> >
> > May I also suggest to attach the patc
1 - 100 of 333 matches
Mail list logo
