On Wed, Aug 23, 2023 at 09:16:08PM +0200, Harald Anlauf via Fortran wrote:
>
> here's a simple patch for a very old PR that suggests a more helpful
> error message for an automatic object in a COMMON. The patch also
> suppresses the less helpful old error message after the new one has
> been
On Sat, Aug 12, 2023 at 10:41:10AM -0300, Jorge D'Elia via Fortran wrote:
>
> $ test-march.exe
>
> Program received signal SIGILL: Illegal instruction.
>
This, to me, suggests that the backend is emitting a wrong
assembly language code. I suspect that you'll need to
compare the generated
On Thu, Jul 27, 2023 at 09:39:53PM +0200, Harald Anlauf via Fortran wrote:
> Dear all,
>
> when passing a character actual argument to an assumed-type dummy
> (TYPE(*)), we should not pass the character length for that argument,
> as otherwise other hidden arguments that are passed as part of the
On Thu, Jul 27, 2023 at 01:36:46PM -0400, Allin Cottrell via Fortran wrote:
> I have old fortran source code (not my own work) for a specialized
> statistical program that I and others find quite useful.
>
> A few years ago I was able to compile it on Linux using gfortran with
> std=legacy (and
On Wed, Jul 26, 2023 at 09:33:22PM +0200, Harald Anlauf via Fortran wrote:
> I am going to get the brown bag for today... This is now the right
> corrected patch.
>
> Sorry for all the noise!
>
Third times a charm (as the saying goes).
Looks good to me. Thanks for the patch.
--
Steve
On Sun, Jul 16, 2023 at 10:30:59PM +0200, Harald Anlauf via Fortran wrote:
> Dear all,
>
> some intrinsics may return character results with the same
> characteristics as their first argument (e.g. PACK, MINVAL, ...).
> If the first argument is of deferred-length, we need to derive
> the
On Tue, Jul 11, 2023 at 09:39:31PM +0200, Harald Anlauf via Fortran wrote:
> Dear all,
>
> for intrinsic procedures we derive the typespec of the formal symbol
> attributes from the actual arguments. This can have an undesired
> effect for character actual arguments, as the argument passing
>
On Sat, Jul 08, 2023 at 03:23:31PM +0100, Paul Richard Thomas wrote:
> The attached patch incorporates two of Steve's "Orphaned Patches" -
> https://gcc.gnu.org/pipermail/fortran/2023-June/059423.html
Thanks Paul for picking up the pieces I left behind.
A few nits below.
> They have in common
On Tue, Jul 04, 2023 at 11:26:26AM +0200, Mikael Morin wrote:
> Le 04/07/2023 à 01:56, Steve Kargl a écrit :
> > On Mon, Jul 03, 2023 at 10:49:36PM +0200, Harald Anlauf via Fortran wrote:
> > >
> > > Indeed, this is a nice demonstration.
> > >
> > > While playing, I was wondering whether the
On Mon, Jul 03, 2023 at 10:49:36PM +0200, Harald Anlauf via Fortran wrote:
>
> Indeed, this is a nice demonstration.
>
> While playing, I was wondering whether the following code is conforming:
>
> program p
> call s ((1))
> contains
> subroutine s (x)
> integer :: x
> x = 42
>
On Thu, Jun 29, 2023 at 10:38:42PM -0500, Alexander Westbrooks via Fortran
wrote:
> I have finished my testing, and updated my patch and relevant Changelogs. I
> added 4 new tests and all the existing tests in the current testsuite
> for gfortran passed or failed as expected. Do I need to attach
On Wed, Jun 21, 2023 at 05:12:22PM +0100, Paul Richard Thomas wrote:
> Committed as r14-2022-g577223aebc7acdd31e62b33c1682fe54a622ae27
>
> Thanks for the help and the review Harald. Thanks to Steve too for
> picking up Neil Carlson's bugs.
>
It's only natural. You fix bugs in a long desired
On Sat, Jun 17, 2023 at 10:14:43AM +0100, Paul Richard Thomas via Fortran wrote:
>
> PS This leaves 89645 and 99065 as the only real blockers to PR87477.
>
Hate to be the bearer of bad news, but Neil Carlson has added
a couple PRs about associate that may not be listed in 87447.
On Fri, Jun 16, 2023 at 07:18:54PM +, Michael Schneider via Fortran wrote:
> Hello,
>
> I'm looking for a forum that can provide answers to
> questions arising with GNU Fortran. Is this the right place?
>
fortran@gcc is normally used for discussion about the
development of the gfortran
On Mon, Jun 12, 2023 at 11:12:45PM +0200, Harald Anlauf via Fortran wrote:
> Dear all,
>
> the attached - actually rather small - patch is the result of a
> rather intensive session with Mikael in an attempt to fix the
> situation that we did not create proper temporaries when passing
>
If anyone is so inclined, the patches in the following
PR's can be committed and the PR closed. These are
patches for gfortran.
69101 91960 95613 99139 99368 99798
100607 103795 103796 104626 105594 101967
101951 104649 106050 106500 107266 107406
107596
This is an opportunity for
On Thu, Jun 08, 2023 at 12:17:02PM +0200, Thomas Koenig wrote:
> Hi together,
>
> > > On 6/6/23 21:11, FX Coudert via Gcc-patches wrote:
> > > > Hi,
> > > >
> > > > > I cannot see if there is proper support for kind=17 in your patch;
> > > > > at least the libgfortran/ieee/ieee_arithmetic.F90
On Wed, Jun 07, 2023 at 08:31:35PM +0200, Harald Anlauf via Fortran wrote:
> Hi FX,
>
> On 6/6/23 21:11, FX Coudert via Gcc-patches wrote:
> > Hi,
> >
> > > I cannot see if there is proper support for kind=17 in your patch;
> > > at least the libgfortran/ieee/ieee_arithmetic.F90 part does not
>
On Tue, Jun 06, 2023 at 09:35:26PM +0200, FX Coudert wrote:
> Hi Steve,
>
> I am not subscribed to the list (too little time, sadly), please keep me in
> CC of your responses.
>
Unfortunately, fx is using a gmail account. Emails from my
system to @gmail.com users are routinely and silently
On Tue, Jun 06, 2023 at 08:51:54AM -0700, Steve Kargl via Fortran wrote:
>
> Scratch 2. Another scan shows that you moduled the Fortran
s/you moduled/you added to
> module where interface are built. This will automatically
s/interface/interfaces
> catch and report the items in
On Tue, Jun 06, 2023 at 08:43:36AM -0700, Steve Kargl via Fortran wrote:
> On Tue, Jun 06, 2023 at 03:19:18PM +0200, FX via Fortran wrote:
> > Hi,
> >
> > This patch adds four IEEE functions from the Fortran 2018
> > standard: IEEE_MIN_NUM, IEEE_MAX_NUM, IEEE_MIN_NUM_MA
On Tue, Jun 06, 2023 at 03:19:18PM +0200, FX via Fortran wrote:
> Hi,
>
> This patch adds four IEEE functions from the Fortran 2018
> standard: IEEE_MIN_NUM, IEEE_MAX_NUM, IEEE_MIN_NUM_MAG,
> and IEEE_MAX_NUM_MAG.
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu, both 32
> and 64-bit. OK to
On Sat, Jun 03, 2023 at 07:50:19AM +0200, Thomas Koenig via Fortran wrote:
> Hi Paul,
>
> > I propose to backport
> > r13-6747-gd7caf313525a46f200d7f5db1ba893f853774aee to 12-branch very
> > soon.
>
> Is this something that we usually do?
>
> While finalization was basically broken before, some
;
> On Fri, 2 Jun 2023, 16:27 Steve Kargl via Fortran,
> wrote:
>
> > On Fri, Jun 02, 2023 at 03:53:44PM +0100, Paul Richard Thomas via Fortran
> > wrote:
> > > Hi Jorge,
> > >
> > > As I posted in the Intel Community, the error generated
On Fri, Jun 02, 2023 at 03:53:44PM +0100, Paul Richard Thomas via Fortran wrote:
> Hi Jorge,
>
> As I posted in the Intel Community, the error generated by gfortran
> (and nagfor) is consistent with the F2003 constraint: C1210 (R1209)
> The IMPORT statement is allowed only in an interface-body.
>
On Thu, May 25, 2023 at 04:05:11PM +, Thompson, Matt (GSFC-610.1)[SCIENCE
SYSTEMS AND APPLICATIONS INC] via Fortran wrote:
> Thomas,
>
> Well, the code did not change. Period. Neither did the compiler. It was 12.3.
> (We can't use GCC 13 because it seems not to like something in our
On Sun, May 14, 2023 at 10:04:25PM +0200, Harald Anlauf via Fortran wrote:
>
> Fortran allows functions in variable definition contexts when the
> result variable is a pointer. We already handle this for the
> non-CLASS case (in 11+), but the logic that checks the pointer
> attribute was looking
On Tue, May 09, 2023 at 08:35:00PM +0200, Harald Anlauf wrote:
> On 5/9/23 20:29, Steve Kargl via Gcc-patches wrote:
> >
> > It's not needed. See above. gfc_state_stack->previous is referenced
> > a few lines above the if-stmt. The reference will segfault if the
> > pointer is NULL.
> >
>
>
On Tue, May 09, 2023 at 08:24:16PM +0200, Harald Anlauf wrote:
> Hi Paul,
>
> On 5/9/23 17:51, Paul Richard Thomas via Gcc-patches wrote:
> > Hi All,
> >
> > Thanks to Steve Kargl for the fix. It caused finalize_8.f03 to fail because
> > this testcase checked that finalizable derived types could
Harald,
Thanks for keeping us honest. I didn't check what other
separators might cause a problem.
After 2 decades of working on gfortran, I've come to conclusion
that -std=f2018 should be the default. When f2023 is ratified,
the default becomes -std=f2023. All GNU fortran extension
should be
On Fri, May 05, 2023 at 08:41:48PM -0700, Jerry D via Fortran wrote:
> 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.
essity, the argument is declared to be of the derived type
> with the final binding, the gfortran and nagfor errors are correct IMHO.
> ifort compiles it without complaint.
>
> I have marked this as "waiting" pending a contrary interpretation.
>
> Cheers
>
&
All,
PR97122 shows an issue with finalization.
It seems I attached a diff to the PR in 2020,
which allows the code to compile. The diff
applied to today's trunk still allows the
code to compile but there is now at least
1 regression with finalize_8.f03.
Even with my patch, I'm uncertain as to
On Sat, Apr 22, 2023 at 08:43:53PM +0200, Mikael Morin wrote:
> >
> OK, let's go with your patch as originally submitted then.
>
Mikael, thanks for looking at the original patch and
suggested an alternative location to attempt to fix
the bug. Halrald, thanks for following up on Mikael's
On Sat, Apr 22, 2023 at 05:17:30PM +0200, Mikael Morin wrote:
> Le 22/04/2023 à 15:52, Steve Kargl a écrit :
> > On Sat, Apr 22, 2023 at 11:25:41AM +0200, Mikael Morin wrote:
> > >
> > > Le 20/04/2023 à 22:01, Harald Anlauf via Fortran a écrit :
> > > > Dear all,
> > > >
> > > > Fortran 2018
On Sat, Apr 22, 2023 at 11:25:41AM +0200, Mikael Morin wrote:
>
> Le 20/04/2023 à 22:01, Harald Anlauf via Fortran a écrit :
> > Dear all,
> >
> > Fortran 2018 added a clarification that the *result* of a function
> > whose result *variable* has the ALLOCATABLE attribute is a *value*
> > that
On Sat, Apr 22, 2023 at 07:46:12AM -0300, Jorge D'Elia wrote:
> > On Fri, Apr 21, 2023 at 08:33:31AM -0300, Jorge D'Elia wrote:
> >>
> >> One question: is there any chance of encoding with coarrays using
> >> extended precision (80 bits) at least inside a multicore computer?
> >> (as if to
On Fri, Apr 21, 2023 at 08:33:31AM -0300, Jorge D'Elia wrote:
> Dear GFortran developers,
>
> One question: is there any chance of encoding with coarrays using
> extended precision (80 bits) at least inside a multicore computer?
> (as if to simplify a bit).
>
> To date, the possibility of
On Mon, Apr 17, 2023 at 09:47:50PM +0200, Bernhard Reutner-Fischer via Fortran
wrote:
> Ping!
>
> Harald fixed the leak in set_exponent in the meantime.
> As stated in the cover-letter, it was bootstrapped and regtested
> without regression on x86_64-foo-linux.
>
> I consider it obvious, but
On Fri, Apr 14, 2023 at 09:49:22PM +0200, Harald Anlauf wrote:
>
> On 4/14/23 21:33, Steve Kargl via Gcc-patches wrote:
> > I was wondering about the difference between set_exponent()
> > and scale(), and found that set_exponent() talks about IEEE
> > values while scale() doesn't. I'm wondering
On Fri, Apr 14, 2023 at 12:33:18PM -0700, Steve Kargl via Fortran wrote:
>
>If X is an IEEE NaN, the result is the same NaN.
>
A better testcase as gfortran will quiet a NaN on assignment.
program foo
integer i
equivalence(i,y)
i = int(z'7FC0BEEF',4) ! Add paylo
On Fri, Apr 14, 2023 at 08:59:24PM +0200, Harald Anlauf via Fortran wrote:
>
> the compile-time simplification of intrinsic SET_EXPONENT was
> broken since the early days of gfortran for argument X < 1
> (including negative X) and for I < 0. I identified and fixed
> several issues in the
All,
The systems that I've used while hacking on gfortran
bugs and features are starting to show their age. I'm
in the early stage of put together the wishlist for
a budget friendly replacement. While I'll likely go
with a Ryzen7 cpu, NVME M2 drives, and as much memory
as I can afford, I'm
On Thu, Mar 30, 2023 at 07:39:55PM +0200, Thomas Koenig via Fortran wrote:
> Hi Andrew,
>
> > "long long". This was just an oversight and a missing check.
> >
> > Committed as obvious after a bootstrap/test on x86_64-linux-gnu.
>
> Thanks!
>
> I think this one is obvious enough that it
On Fri, Mar 10, 2023 at 07:01:29PM +0100, Richard Biener via Fortran wrote:
>
>
> > Am 10.03.2023 um 18:54 schrieb Thomas Koenig via Fortran
> > :
> >
> > Hello world, here's the patch that was discussed.
> >
> > Regression-tested. OK for trunk?
> >
> > Since this appeared only in gcc13, I
On Thu, Mar 09, 2023 at 08:18:08AM +, Richard Biener wrote:
>
> the existing comment already explains the issue. I suppose
> -fdefault-integer-8 would also work around the issue?
>
Please, no. -fdefault-* options should have been removed
from gfortran years ago. Without a careful review,
On Wed, Mar 08, 2023 at 07:32:55AM +, Paul Richard Thomas wrote:
>
> Could you please review the patch on that self same time scale? I would be
> happy to have feedback one file at a time.
>
Yes, I'll commit time to review individual patches. Smaller
patches are typically easier to review.
On Tue, Mar 07, 2023 at 03:58:32PM +0100, Thomas Koenig via Fortran wrote:
> Paul,
>
> first of all, thank you very much indeed for the hard work you put into
> this! This is a great step for gfortran.
Ditto**2
> > I can hurry this along to get the patch
> > into 13-branch or I can wait until
On Fri, Mar 03, 2023 at 10:24:07PM +0100, Mikael Morin wrote:
> Hello,
>
> Le 03/03/2023 à 20:57, Steve Kargl via Fortran a écrit :
> > On Thu, Mar 02, 2023 at 11:03:48PM +0100, Harald Anlauf via Fortran wrote:
> > > - if (attr->class_ok)
> > > -/* Cl
On Thu, Mar 02, 2023 at 11:03:48PM +0100, Harald Anlauf via Fortran wrote:
> - if (attr->class_ok)
> -/* Class container has already been built. */
> + /* Class container has already been built with same name. */
> + if (attr->class_ok
> + && ts->u.derived->components->attr.dimension
On Thu, Mar 02, 2023 at 01:07:32AM +0100, Bernhard Reutner-Fischer wrote:
> On Wed, 1 Mar 2023 07:39:40 -0800
> Steve Kargl via Gcc-patches wrote:
>
> > In fact, Hollerith should be hidden behind a -fallow-hollerith
> > option and added to -std=legacy.
>
> While i'd be all for that, in my mind
On Wed, Mar 01, 2023 at 10:28:56PM +0100, Bernhard Reutner-Fischer via Fortran
wrote:
> libgfortran/caf/single.c |6 ++
> libgfortran/io/async.c |6 ++
> libgfortran/io/format.c |3 +--
> libgfortran/io/transfer.c|6 ++
> libgfortran/io/unix.c
On Wed, Mar 01, 2023 at 10:40:15AM +0100, Tobias Burnus wrote:
> > --- /dev/null
> > +++ b/gcc/testsuite/gfortran.dg/pr103628.f90
> > @@ -0,0 +1,14 @@
> > +! { dg-do compile { target powerpc*-*-* } }
> > +! { dg-options "-O2 -mabi=ibmlongdouble" }
> > +
> > +! Test to ensure that it reports an
On Mon, Feb 27, 2023 at 09:54:38PM +0100, Harald Anlauf via Fortran wrote:
>
> as found by the reporter, the result of the intrinsic IBITS
> differed from other compilers (e.g. Intel, NAG) for the corner
> case that the LEN argument was equal to BIT_SIZE(I), which is
> explicitly allowed by the
On Thu, Feb 23, 2023 at 07:24:26AM -0800, Damian Rouson wrote:
> I wonder if a relatively easy starting point would be enabling the
> declaration of do concurrent construct variables:
>
> do concurrent (integer :: i = 1:n)
>
> It’s a minor convenience and less exciting than adding locality
On Tue, Feb 21, 2023 at 10:18:58PM +0100, Harald Anlauf via Fortran wrote:
> Dear all,
>
> the attached simple patch detects and rejects CHARACTER components
> of derived types whose length specification is non-integer.
>
> Regtested on x86_64-pc-linux-gnu. OK for mainline?
>
> This PR is also
On Mon, Feb 20, 2023 at 07:56:14AM +0100, Tobias Burnus wrote:
> On 17.02.23 17:27, Steve Kargl wrote:
> > On Fri, Feb 17, 2023 at 12:13:52PM +0100, Tobias Burnus wrote:
> > > OK for mainline?
> > Short version: no.
>
> Would you mind to write a reasoning beyond only a single word?
>
> > >
On Fri, Feb 17, 2023 at 12:13:52PM +0100, Tobias Burnus wrote:
> Short version:
>
> This fixes potential and real bugs related to 'len=:' character variables
> as for the length/byte size an old/saved expression is used instead of
> the current value. - That's fine but not for allocatable/pointer
On Wed, Feb 15, 2023 at 10:28:00PM +0100, Harald Anlauf via Fortran wrote:
> Dear all,
>
> I've committed the attached obvious and trivial patch for a NULL
> pointer dereference on behalf of Steve and after regtesting on
> x86_64-pc-linux-gnu as r13-6066-ga418129273725fd02e881e6fb5e0877287a1356c
On Fri, Feb 10, 2023 at 10:07:24PM +0100, Harald Anlauf via Fortran wrote:
> Hello all,
>
> I actually like the idea of supporting the suggested attributes,
> provided they work and behave the same way with and without LTO.
>
> - NOINLINE: I disagree with Steve here; we shouldn't invent a new
>
On Fri, Feb 10, 2023 at 10:38:04AM +0200, Rimvydas Jasinskas wrote:
> On Fri, Feb 10, 2023 at 10:24 AM Steve Kargl via Fortran
> wrote:
> > > would it be possible to extend gfortran attribute support to handle
> > > NOINLINE too? Like: "!GCC$ ATTRIBUTES noinline ::
On Fri, Feb 10, 2023 at 07:42:47AM +0200, Rimvydas Jasinskas via Fortran wrote:
> Hello everyone,
>
> would it be possible to extend gfortran attribute support to handle
> NOINLINE too? Like: "!GCC$ ATTRIBUTES noinline :: ...".
It looks to me like you are conflating three independent topics.
On Fri, Feb 03, 2023 at 08:03:36PM +0100, Jakub Jelinek via Fortran wrote:
> Hi!
>
> The first testcase in the PR (which I haven't included in the patch because
> it is unclear to me if it is supposed to be valid or not) ICEs since extra
> hash table checking has been added recently. The problem
On Tue, Jan 31, 2023 at 10:38:02PM +0800, LIU Hao wrote:
> 在 2023-01-31 21:13, Thomas Schwinge 写道:
> > Hi!
> >
> > On 2023-01-30T14:50:08-0800, Steve Kargl via Fortran
> > wrote:
> > > Does the skull and crossbones convey anymore info tha
On Mon, Jan 30, 2023 at 11:07:46PM +0100, Gerald Pfeifer wrote:
> On Mon, 30 Jan 2023, Steve Kargl via Gcc wrote:
> > Bingo. In the case of non-[a-zA-Z] characters in the
> > Subject (or Fromi or To) line, the spam folder is normally
> > named /dev/null.
>
> Hmm, so any digit, parenthesis, or
On Mon, Jan 30, 2023 at 03:46:30PM +0100, Thomas Koenig wrote:
> On 30.01.23 14:52, Mark Wielaard wrote:
> > Hi Steve,
> >
> > On Sun, 2023-01-29 at 22:27 -0800, Steve Kargl via Gcc wrote:
> > > Please remove the skull and cross bones in the subject line.
> >
> > That is the default "hazard
On Sun, Jan 29, 2023 at 07:49:35PM +, Sam James via Fortran wrote:
>
>
> > On 29 Jan 2023, at 19:36, Jerry D via Gcc wrote:
> >
> > I had this show up today. I have no idea what this is about.
> >
> > Please advise.
> >
>
> Sorry Jerry, false positive -- something went wrong with
> the
On Sat, Jan 28, 2023 at 06:07:50PM +0100, Harald Anlauf via Fortran wrote:
>
> a USE associated symbol shall not appear in a COMMON block
> (F2018:C8121) and needs to be diagnosed. The patch is
> fairly obvious.
>
> Regtested on x86_64-pc-linux-gnu. OK for mainline?
>
> As the PR is marked as
On Wed, Jan 25, 2023 at 10:59:22PM +0100, Harald Anlauf via Fortran wrote:
> Dear all,
>
> the attached patch fixes two issues: first it addresses a NULL pointer
> dereference on invalid input, triggered by the provided testcase.
>
> Second, while analyzing the context of the affected code, I
On Mon, Jan 23, 2023 at 10:23:54PM +0100, Harald Anlauf via Fortran wrote:
>
> the code in the PR demonstrates that dependency checking in the
> frontend optimization was not recovering well from invalid code,
> leading to a NULL pointer dereference. An easy and really obvious
> fix.
>
>
On Mon, Jan 23, 2023 at 09:34:59PM +0100, Harald Anlauf via Fortran wrote:
>
> we did not check array element triplets for validity strictly enough
> (i.e. defensively in the case of invalid code), so we could encounter
> non-integer constant expressions that were passed to mpz_get_si.
>
> The
On Thu, Jan 12, 2023 at 02:31:12AM +, Jerry DeLisle via Fortran wrote:
> Hi all,
>
> I spotted this today on the Fortran-Lang Discourse.
>
> It would not be setting precednce for us to allow an extension and turn
> this into a warning with -std=gnu and an error of strict compliance is
>
On Wed, Dec 21, 2022 at 07:27:11PM -0500, Lipeng Zhu via Fortran wrote:
> This patch try to introduce the rwlock and split the read/write to
> unit_root tree and unit_cache with rwlock instead of the mutex to
> increase CPU efficiency. In the get_gfc_unit function, the percentage
> to step into
On Thu, Dec 22, 2022 at 10:13:04PM +0100, Harald Anlauf via Fortran wrote:
>
> the attached patch adds a check for statement function bodies for
> invalid uses of dummy arguments. This fixes an ICE-on invalid.
>
> Regtested on x86_64-pc-linux-gnu. OK for mainline?
>
Yes. Thanks for the
On Tue, Dec 20, 2022 at 09:40:23PM +0100, Harald Anlauf via Fortran wrote:
>
> we obviously forgot to extend the C interoperability check of the
> type of function results to CLASS variables and thus did not reject
> them. Wrong code could lead to an ICE, see testcase by Gerhard.
>
> Regtested
On Thu, Dec 15, 2022 at 01:51:26PM +0100, Federico Perini via Fortran wrote:
>
> 3. Of the optimization flags "-fpeel-loops" is the one that triggers the
> failing tests
>
> 3. in dtio_4.f90, the first test fails for 1) non-extended class; 2)
> derived-type READ. Write works; extended type
On Mon, Dec 12, 2022 at 08:49:50PM +0100, Harald Anlauf via Fortran wrote:
>
> Committed as r13-4623-gcf5327b89ab610.
>
To be clear, I have no problems with this commit.
But, just a FYI, there is gfc_peek_ascii_char(),
which allows you to look at the next character
without having to keep track
On Sun, Dec 11, 2022 at 11:33:43PM +0100, Harald Anlauf via Fortran wrote:
> Dear all,
>
> the attached patch improves checking of array specs in two ways:
> - bad assumed size array spec
> - a bad first array element spec may already trigger an error,
> leading to a more consistent behavior
>
On Sat, Dec 10, 2022 at 10:14:06PM +0100, Harald Anlauf via Fortran wrote:
> Dear all,
>
> we should not try to simplify ISHFTC if the SIZE argument
> is known to be outside the allowed range. It's better to
> generate an error by terminating the simplification.
>
> Regtested on
On Sat, Dec 10, 2022 at 12:10:20PM -0800, Jerry D wrote:
> 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
> >
On Thu, Dec 08, 2022 at 10:59:42PM +0100, Harald Anlauf via Fortran wrote:
> Dear all,
>
> a fairly obvious, or rather trivial fix that appeared while
> analyzing another pr and that can be treated independently:
> reject duplicate CONTIGUOUS attributes.
>
> (Intel and NAG reject this, Cray
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. I am a bit
> disappointed. Maybe my intent was misunderstood. I am not suggesting
> replacing
On Wed, Dec 07, 2022 at 09:57:20PM +0100, Harald Anlauf via Fortran wrote:
> Dear all,
>
> we need to be careful about zero-sized arrays in arithmetic
> reductions (unary & binary), as we otherwise may hit a NULL
> pointer dereference on valid code.
>
> The actual fix is straightforward, see
On Sun, Dec 04, 2022 at 01:49:51PM -0800, Demian Sanchez Lopez via Fortran
wrote:
> Hello Fortran Admin,
>
> I would love to begin my computer programming journey, but I am having
> problems at the installation point. Where do I install the GCC compilers? I
> accidentally deleted the location on
On Tue, Nov 22, 2022 at 10:15:39PM +0100, Harald Anlauf via Fortran wrote:
> Minor addition:
>
> program foo
> implicit none
> real(8) :: i
> integer, parameter :: q(*) = [(kind(i), integer :: i = 1, 3)]
> print *, q
> end program foo
>
> This prints
>
>8 8
On Sun, Nov 20, 2022 at 10:28:40PM +0100, Harald Anlauf via Fortran wrote:
>
> for unknown reasons I cannot reply to your mail on gmane,
> so trying directly via mailing list.
>
I forgot to address this. I updated my OS on Thursday afternoon,
and when I rebooted, sendmail failed to start. It
On Sun, Nov 20, 2022 at 10:28:40PM +0100, Harald Anlauf via Fortran wrote:
> Steve,
>
> for unknown reasons I cannot reply to your mail on gmane,
> so trying directly via mailing list.
>
> I tried your patch, and it works on the supplied testcases.
>
> However, there is a scoping issue for the
On Tue, Nov 15, 2022 at 05:13:19PM -0800, Steve Kargl via Fortran wrote:
> F2008 introduced the inclusion of a typespec in a forall
> statement, and thn F2018 a typespec was allowed in an
> implied-do. There may even be a few bug reports.
New patch and two test cases (don't kno
On Wed, Nov 16, 2022 at 04:47:50PM -0800, Steve Kargl via Fortran wrote:
> On Wed, Nov 16, 2022 at 04:32:39PM -0800, Steve Kargl via Fortran wrote:
> > On Wed, Nov 16, 2022 at 01:30:07PM -0800, Steve Kargl via Fortran wrote:
> > > On Tue, Nov 15, 2022 at 05:13:19PM -0800, Steve
On Wed, Nov 16, 2022 at 04:32:39PM -0800, Steve Kargl via Fortran wrote:
> On Wed, Nov 16, 2022 at 01:30:07PM -0800, Steve Kargl via Fortran wrote:
> > On Tue, Nov 15, 2022 at 05:13:19PM -0800, Steve Kargl via Fortran wrote:
> > > F2008 introduced the inclusion of a ty
On Wed, Nov 16, 2022 at 01:30:07PM -0800, Steve Kargl via Fortran wrote:
> On Tue, Nov 15, 2022 at 05:13:19PM -0800, Steve Kargl via Fortran wrote:
> > F2008 introduced the inclusion of a typespec in a forall
> > statement, and thn F2018 a typespec was allowed in an
> > implie
On Wed, Nov 16, 2022 at 10:58:18PM +0100, Harald Anlauf via Fortran wrote:
>
> @Steve: please close PR if you think everything is ok.
>
Thanks. I'll close the pr.
--
Steve
On Tue, Nov 15, 2022 at 05:13:19PM -0800, Steve Kargl via Fortran wrote:
> F2008 introduced the inclusion of a typespec in a forall
> statement, and thn F2018 a typespec was allowed in an
> implied-do. There may even be a few bug reports.
>
New patch. This one handles the example o
On Tue, Nov 15, 2022 at 06:31:16PM -0800, Steve Kargl via Fortran wrote:
> On Tue, Nov 15, 2022 at 05:13:19PM -0800, Steve Kargl via Fortran wrote:
> > F2008 introduced the inclusion of a typespec in a forall
> > statement, and thn F2018 a typespec was allowed in an
> > implie
On Tue, Nov 15, 2022 at 05:13:19PM -0800, Steve Kargl via Fortran wrote:
>
> This patch allows the above to compile and execute.
> It has only had some light testing, and I do not know
> if nested forall and implied-do loops do work. Feel
> free to commit as I cannot.
>
On Tue, Nov 15, 2022 at 05:13:19PM -0800, Steve Kargl via Fortran wrote:
>
> This patch allows the above to compile and execute.
> It has only had some light testing, and I do not know
> if nested forall and implied-do loops do work. Feel
> free to commit as I cannot.
For ne
On Tue, Nov 15, 2022 at 05:13:19PM -0800, Steve Kargl via Fortran wrote:
> F2008 introduced the inclusion of a typespec in a forall
> statement, and thn F2018 a typespec was allowed in an
> implied-do. There may even be a few bug reports.
>
Forgot to ask. Anyone know how nam
F2008 introduced the inclusion of a typespec in a forall
statement, and thn F2018 a typespec was allowed in an
implied-do. There may even be a few bug reports.
Consider,
program foo
implicit none
integer, parameter :: n = 9
integer a(n,n), b(n), j
b = [(k, integer
On Thu, Mar 31, 2022 at 08:36:37PM +0200, Thomas Koenig wrote:
> Hi Steve,
>
> > So, it seems that at some point in the past, the option
> > -fmax-stack-var-size was expanded to allow the placement
> > of an allocatable array into static memory. This has
> > a possibly unintended consequence in
So, it seems that at some point in the past, the option
-fmax-stack-var-size was expanded to allow the placement
of an allocatable array into static memory. This has
a possibly unintended consequence in that automatic
deallocation of an allocatable array does not (or can
not) occur.
program foo
1 - 100 of 140 matches
Mail list logo
