On Wed, Mar 27, 2024 at 04:30:42PM +0100, Mikael Morin wrote:
> Hell(o),
>
> it didn't take long for my recent patch for PR111781 to show a regression.
> The fix proposed here is actually the one Harald posted in the PR.
> I can't imagine a case where it wouldn't do the right thing.
> Regression
On Tue, Mar 19, 2024 at 04:17:32PM +0100, FX Coudert wrote:
>
> These two (independent) patches add two tiny Fortran 2023 features: new
> ISO_FORTRAN_ENV named constants and SELECTED_LOGICAL_KIND intrinsic.
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu.
> Please review, and let me know
On Tue, Mar 05, 2024 at 08:06:10PM -0800, Jerry D wrote:
> On 3/5/24 1:51 PM, Harald Anlauf wrote:
> > Hi Jerry,
> >
> > on further thought, do we sanitize 'child_iomsg'?
> > We pass it to snprintf as format.
> >
> > Wouldn't a strncpy be sufficient?
> >
> > Harald
> >
> >
>
> Just to be
On Thu, Feb 29, 2024 at 09:36:43AM -0800, Jerry D wrote:
> On 2/29/24 1:47 AM, Bernhard Reutner-Fischer wrote:
>
> > And, just for my own education, the length limitation of iomsg to 255
> > chars is not backed by the standard AFAICS, right? It's just our
> > STRERR_MAXSZ?
>
> Yes, its what we
All,
Consider,
! { dg-do run }
program foo
implicit none
real y
associate (x => log(cmplx(-1,0)))
y = x%im
if (int(100*y)-314 /= 0) stop 1
end associate
end program
% gfcx -c a.f90
a.f90:6:13:
6 | y = x%im
| 1
Error: Symbol 'x' at (1) has no
On Fri, Feb 23, 2024 at 10:15:17PM +0100, Harald Anlauf wrote:
> Hi Steve, all,
>
> here's an updated patch with an enhanced testcase that also
> checks MOLD= besides SOURCE=.
>
> Regtested on x86_64-pc-linux-gnu. Is it OK for mainline?
>
>From my viewpoint, yes.
Thanks for finding a better
On Thu, Feb 22, 2024 at 09:22:37PM +0100, Harald Anlauf wrote:
> Hi Steve!
>
> On 2/22/24 01:52, Steve Kargl wrote:
> > On Wed, Feb 21, 2024 at 01:42:32PM -0800, Steve Kargl wrote:
> > > On Wed, Feb 21, 2024 at 10:20:43PM +0100, Harald Anlauf wrote:
> > > >
On Wed, Feb 21, 2024 at 01:42:32PM -0800, Steve Kargl wrote:
> On Wed, Feb 21, 2024 at 10:20:43PM +0100, Harald Anlauf wrote:
> > On 2/21/24 22:00, Steve Kargl wrote:
> > > memleak vs ICE. I think I'll take one over the other.
> > > Probably need to free code->expr3
On Wed, Feb 21, 2024 at 10:20:43PM +0100, Harald Anlauf wrote:
> On 2/21/24 22:00, Steve Kargl wrote:
> > Unfortunately, valgrind does not work on AMD FX-8350 cpu.
>
> Do you mean valgrind does not work at all?
> For gcc, you need to configure --enable-valgrind-annotations
On Wed, Feb 21, 2024 at 09:28:16PM +0100, Harald Anlauf wrote:
> On 2/21/24 20:41, Jerry D wrote:
> > On 2/21/24 10:30 AM, Steve Kargl wrote:
> > > I have attached a patch to PR114024, see
> > >
> > > https://gcc.gnu.org/pipermail/gcc-bugs/2024-February/854651.
I have attached a patch to PR114024, see
https://gcc.gnu.org/pipermail/gcc-bugs/2024-February/854651.html
The patch contains a new testcase and passes regression
testing on x86_64-*-freebsd. Could someone castr an eye
over the patch and commit it?
--
Steve
On Tue, Feb 20, 2024 at 08:53:37PM +0100, Harald Anlauf wrote:
> On 2/19/24 16:19, Peter Hill wrote:
> > Hi Harald,
> >
> > Thanks for your help, please see the updated and signed-off patch below.
>
> Pushed: https://gcc.gnu.org/g:14ba8d5b87acd5f91ab8b8c02165a0fd53dcc2f2
>
Harald, Thanks for
On Mon, Feb 12, 2024 at 09:57:08PM +0100, Harald Anlauf wrote:
> Dear all,
>
> the attached patch fixes a mis-handling of optional dummy arguments
> passed to optional dummy arguments of procedures with the bind(c)
> attribute. When those procedures are expecting CFI descriptors,
> there is no
Jerry,
The patch looks good to me, but please give Harald a chance
to comment.
--
steve
On Fri, Feb 02, 2024 at 07:17:55PM -0800, Jerry D wrote:
> On 1/30/24 12:36 PM, Harald Anlauf wrote:
> > Hi Jerry,
> >
> > Am 30.01.24 um 19:15 schrieb Jerry D:
> > > The attached patch attempts to fix the
On Sun, Jan 28, 2024 at 08:56:24PM +0100, Harald Anlauf wrote:
>
> Am 28.01.24 um 12:39 schrieb Mikael Morin:
> > Le 24/01/2024 à 22:39, Harald Anlauf a écrit :
> > > Dear all,
> > >
> > > this patch is actually only a followup fix to generate the proper name
> > > of an array reference in
On Wed, Jan 24, 2024 at 11:13:05AM +0200, Janne Blomqvist wrote:
> On Wed, Jan 24, 2024 at 10:28 AM FX Coudert wrote:
> > > Now, if
> > > the OS adds cospi() to libm and it's in libm's symbol map, then the
> > > cospi() used by gfortran depends on the search order of the loaded
> > > libraries.
>
On Tue, Jan 23, 2024 at 01:37:54PM +0200, Janne Blomqvist wrote:
>
> > - If I get this right, to take one example, the Fortran front-end will emit
> > a call to gfortran_acospi_r4(), libgfortran provides this as a wrapper
> > calling acospif(), which is called either from libm or from
On Tue, Jan 23, 2024 at 01:37:54PM +0200, Janne Blomqvist wrote:
> On Tue, Jan 23, 2024 at 11:09 AM FX Coudert wrote:
> >
> > Hi Steve,
>
> Hello, long time no see.
Time is short and we're all busy with life, but it is nice to see
familiar names!
>
> > Thanks for the patch. I’ll take time to
On Tue, Jan 23, 2024 at 06:40:27AM -0800, Steve Kargl wrote:
> On Tue, Jan 23, 2024 at 10:08:43AM +0100, FX Coudert wrote:
> > Hi Steve,
> >
> > Thanks for the patch. I’ll take time to do a proper review, but
> > after a first read I had the following questions:
&
On Tue, Jan 23, 2024 at 10:08:43AM +0100, FX Coudert wrote:
> Hi Steve,
>
> Thanks for the patch. I’ll take time to do a proper review, but
> after a first read I had the following questions:
>
> - "an OS's libm may/will contain cospi(), etc.”: do those functions
> conform to any standard? Are
All,
I have attached a new patch to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113152
which addresses the following issues.
PR113152 -- implement half-cycle trigonometric functions
PR113412 -- better error message for atan(y,x)
PR113413 -- implement atand(y,x)
The patch clocks in at 3488
On Fri, Jan 19, 2024 at 06:47:36PM +0100, Mikael Morin wrote:
>
> I tested this on x86_64-pc-linux-gnu without regression.
> There is no new test, as the problem is visible on an
> existing test with valgrind or an asan-instrumented compiler.
> OK for master?
>
Yes. After your explanation,
On Sat, Jan 13, 2024 at 10:12:42PM +0100, Harald Anlauf wrote:
>
> (2) a missing optional argument for SIZE to the ISHFTC intrinsic
> shall be equivalent to using BIT_SIZE(I).
>
> Regtested on x86_64-pc-linux-gnu. OK for mainline?
>
> As I consider the patch safe, I'd like to backport to
On Tue, Jan 02, 2024 at 08:31:15PM +0100, Harald Anlauf wrote:
>
> we might want to update changes.html to reflect this. How about:
>
> diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
> index 403feb06..9b16f5e3 100644
> --- a/htdocs/gcc-14/changes.html
> +++
On Mon, Dec 18, 2023 at 07:11:59PM +0100, Harald Anlauf wrote:
> Dear all,
>
> starting with Fortran 2018, DATE_AND_TIME allowed a non-default
> integer VALUES argument.
>
> While gfortran accepts this silently, this failed at runtime
> because the library implementation beyond kind=4 and kind=8
On Wed, Nov 22, 2023 at 10:36:00AM +0100, Mikael Morin wrote:
>
> OK with this fixed (and the previous comments as you wish), if Steve has no
> more comments.
>
No further comments. Thanks for your patients, Harald.
As side note, I found John Reid's "What's new" document
where it is noted
Harald,
Sorry about delayed response. Got side-tracked by Family this weekend.
On Sun, Nov 19, 2023 at 09:46:46PM +0100, Harald Anlauf wrote:
>
> On 11/19/23 01:04, Steve Kargl wrote:
> > On Sat, Nov 18, 2023 at 11:12:55PM +0100, Harald Anlauf wrote:
> > > Regtested o
On Sat, Nov 18, 2023 at 11:12:55PM +0100, Harald Anlauf wrote:
>
> Fortran 2023 added restrictions on integer arguments to SYSTEM_CLOCK.
> The attached patch implements these.
>
> I was struggling with the way we should handle features that are sort-of
> deleted in a new standard, but not
On Fri, Nov 03, 2023 at 07:56:20PM +0100, Harald Anlauf wrote:
> Dear all,
>
> this is a rather weird bug with a very simple fix. If a procedure pointer
> is referenced in a CALL, a symbol was created shadowing the original
> declaration if it was host-associated. Funnily, this affected only
>
On Tue, Oct 31, 2023 at 02:11:08PM +, Paul Richard Thomas wrote:
> I found this 'obvious' fix, while going through PRs assigned to me.
>
> Regtests. OK for mainline?
>
Yes. Fell free to backport if you have time and desire.
--
Steve
On Mon, Oct 16, 2023 at 08:31:20PM +0200, Harald Anlauf wrote:
>
> Am 16.10.23 um 19:11 schrieb Tobias Burnus:
> > Yesterday, someone was confused because the signal handler did not work.
> >
> > It turned out that the created Fortran procedure used as handler used
> > pass by reference - and
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 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 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
>
an: Fix default type bugs in gfortran [PR99139, PR99368]
>
> 2023-07-08 Steve Kargl
ka...@gcc.gnu.org.
> gcc/fortran
> PR fortran/99139
> PR fortran/99368
> * match.cc (gfc_match_namelist): Check for host associated or
> defined types before applying default type.
> (gf
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.
> > >
> >
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 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 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
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 tha
6 0
>
>
> So there seems to be a consensus that "," and ";" must be rejected,
> and tab is accepted (makes real sense), but already the termination
> character "/" and comment character "!" are treated differently.
> And how do we want to tre
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.
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 :
> > > >
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 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()
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
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 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
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 reaso
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 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 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 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 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 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 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 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 Mon, Apr 25, 2022 at 09:26:26AM +0200, Richard Biener wrote:
> On Sat, Apr 23, 2022 at 8:40 PM Steve Kargl via Gcc-patches
> wrote:
> >
> > ping.
>
> I have tested the patch on x86_64-linux and pushed it.
>
Thanks.
--
Steve
ping.
On Fri, Apr 15, 2022 at 09:23:43AM -0700, Steve Kargl wrote:
> Can someone, anyone, please commit the attach patch, which is
> also attached to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89125
> where one can read the audit trail. The original patch was
> submitted
Can someone, anyone, please commit the attach patch, which is
also attached to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89125
where one can read the audit trail. The original patch was
submitted 2 years ago, and required manual intervention due to
the recent *.c to *.cc rename.
Back story:
On Sun, Oct 24, 2021 at 09:00:52PM +0200, Harald Anlauf wrote:
> Dear Fortranners, Steve,
>
> I've created PR 102917 for tracking this issue and packaged
> the attached patch.
>
> Regtested on x86_64-pc-linux-gnu. OK mainline?
>
Thanks for picking this up. The patch looks good to me,
but
On Sat, Jun 05, 2021 at 04:04:51PM +0200, Andre Vehreschild wrote:
>
> I was asked to backport the patch for pr98301 to gcc-11. The patches have
> been in mainline for two weeks without any defect reports I could fined. The
> patch for mainline applied with a bit of shift cleanly.
>
> Regstested
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, just rebased to
> current master.
>
> Regtested fine on
On Mon, May 03, 2021 at 11:21:10AM +0200, Andre Vehreschild wrote:
> Ping!
>
> Ok for trunk?
>
> I have looked at other patches, but none was patching any location I have
> worked on previously. Therefore I can't return the favor of reviewing any
> currently open patches and have to ask for
On Sat, Mar 27, 2021 at 03:11:05PM -0700, Jerry DeLisle wrote:
> Pushed:
>
> To git+ssh://gcc.gnu.org/git/gcc.git
> 651684b462f..01685676a93 master -> master
>
> Author: Steve Kargl
> Date: Sat Mar 27 15:02:16 2021 -0700
>
> fortran: Fix off-by-one
This patch fixes an off-by-one buffer overflow issue.
Please commit.
diff --git a/gcc/fortran/misc.c b/gcc/fortran/misc.c
index 8a96243e80d..3d449ae17fe 100644
--- a/gcc/fortran/misc.c
+++ b/gcc/fortran/misc.c
@@ -124,8 +124,10 @@ gfc_basic_typename (bt type)
const char *
gfc_typename
1 - 100 of 1281 matches
Mail list logo
