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
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
On Sat, Nov 16, 2024 at 02:55:11PM +0100, Thomas Koenig wrote:
>
> Steve found a test case where unsigned constants were not handled
> in a module. Single-line patch committed as obvious and simple,
> r15-5341-g66096151afc6631f8f2a3458b154c5daa822b963 .
>
> Best regards
>
> Thomas
>
Than
On Fri, Nov 01, 2024 at 10:00:29AM +0100, Thomas Koenig wrote:
>
> during testing, I noticed that parameters of the form
> - mod(u1,u2) were rejected with an unknown type. The fix
> is straightforward, but required an adjustment to another
> test case.
>
> Regression-tested. OK for trunk?
>
Ye
On Wed, Oct 30, 2024 at 04:41:40PM +, Paul Richard Thomas wrote:
> This wrinkle to PR115700 came about because the associate-name string
> length was not being initialized, when an array selector had a substring
> reference with non-constant start or end. This, of course, caused
> subsequent re
On Sat, Oct 26, 2024 at 05:16:54PM +0200, Thomas Koenig wrote:
>
> OK for trunk?
>
OK, but see below.
> +@item @code{SUM}, @pxref{SUM}
> +@item @code{TRANSPOSE}, @pxref{TRANSPOSE}
> +@item @code{TRANSFER}, @pxref{TRANSFER}
> @end itemize
> +
> +The following intrincis are enabled with @option{
On Sat, Sep 28, 2024 at 08:32:00PM +0200, Thomas Koenig wrote:
> Hello world,
>
> here's another small patch for FINDLOC for unsigned.
>
> OK for trunk?
>
OK. Other than UNSIGNED being a new experimental feature,
this patch almost qualifies as "Obvious".
--
Steve
OK. Thanks for the patch.
--
steve
On Sat, Sep 28, 2024 at 09:33:20AM +0200, Thomas Koenig wrote:
>
> this patch, consisting almost entirely of the test cases, implements
> CSHIFT and EOSHIFT for unsigneds.
>
> OK for trunk?
>
> Implement CSHIFT and EOSHIFT for unsigned.
>
> gcc/for
On Fri, Sep 27, 2024 at 08:12:01PM +0200, Andre Vehreschild wrote:
>
> the testcase is in the coarray directory, where tests are executed mit
> -fcoarray=single and lib. I don't know about none. Because the code stops
> compiling when it encounters a coarray with no single or lib. Therefore I
> su
On Fri, Sep 27, 2024 at 03:20:43PM +0200, Andre Vehreschild wrote:
>
> attached patch fixes a runtime issue when a coarray was passed as
> parameter to a procedure that was itself a parameter. The issue here
> was that the coarray was passed as array pointer (i.e. w/o descriptor)
> to the function
On Sat, Sep 14, 2024 at 11:02:42AM -0700, Steve Kargl wrote:
>
> While I understand the intent of 'positive form' vs 'negative form', the
> above might be clearer as
>
>Usage of intrinsics can be implemented either by generating a call
>to the libgf
On Fri, Sep 13, 2024 at 12:27:07PM +0200, Mikael Morin wrote:
> >
> > gcc/fortran/ChangeLog:
> >
> > * invoke.texi(finline-intrinsics): Document new flag.
> > * lang.opt (finline-intrinsics, finline-intrinsics=,
> > fno-inline-intrinsics): New flags.
> > * options.cc (gfc_post_opt
OK. Sorry about dropping the balli on a review.
I thought it had already been approved and committed.
--
steve
On Fri, Sep 13, 2024 at 12:19:48PM +0200, Mikael Morin wrote:
> Ping:
>
> https://gcc.gnu.org/pipermail/fortran/2024-July/060640.html
>
> Maybe I could argue that I can self approve,
On Sun, Aug 18, 2024 at 12:10:18PM +0200, Thomas Koenig wrote:
> Hello world,
>
> this version of the patch includes DOT_PRODUCT, MATMUL and quite
> a few improvements for simplification.
>
All,
I have gone through Thomas's current patch and sent a
few emails with comments to him. To keep thin
On Thu, Sep 05, 2024 at 09:07:20AM +0200, Thomas Koenig wrote:
> Ping (a little bit)?
>
> With another weekend coming up, I would have some time to
> work on incorporating any feedback, or on putting in
> more intrinsics.
>
Last comment as I've made it to the end of the patch.
Your testcases ar
On Thu, Sep 05, 2024 at 09:07:20AM +0200, Thomas Koenig wrote:
> Ping (a little bit)?
>
> With another weekend coming up, I would have some time to
> work on incorporating any feedback, or on putting in
> more intrinsics.
>
In the documentation, you have
+Generally, unsigned integers are only p
ault) to a legacy extension (warning by default).
>
> The feature is tested in at least 4 gfortran testcases. I adjusted
> the pattern of one of these tests to check for the downgrade.
>
> Regtested on x86_64-pc-linux-gnu. OK for mainline?
>
> Thanks,
> Harald
>
>
On Fri, Aug 30, 2024 at 06:46:47PM +0200, Harald Anlauf wrote:
> Am 30.08.24 um 18:33 schrieb Steve Kargl:
> > On Thu, Aug 29, 2024 at 10:05:35PM +0200, Harald Anlauf wrote:
> > >
> > >
> > > Should we downgrade this extension to GFC_STD_LEGACY?
> >
On Thu, Aug 29, 2024 at 10:05:35PM +0200, Harald Anlauf wrote:
>
> Am 29.08.24 um 21:53 schrieb Steve Kargl:
> > Thanks for the patch. If you have not already opened a new PR for the
> > other issue with C8107, I'll open one later today. It's likely that
> > w
Thanks for the patch. If you have not already opened a new PR for the
other issue with C8107, I'll open one later today. It's likely that
we need to check the namelist-group-name for USE association in
match.cc:gfc_match_namelist.
Hmmm, it seems we already catch the error, but accept it as an
ex
On Tue, Aug 27, 2024 at 06:46:08PM +0200, Thomas Koenig wrote:
> Steve,
>
> > On Sun, Aug 18, 2024 at 12:10:18PM +0200, Thomas Koenig wrote:
> > >
> > > this version of the patch includes DOT_PRODUCT, MATMUL and quite
> > > a few improvements for simplification.
> >
> > Thomas,
> >
> > Your upd
On Wed, Aug 21, 2024 at 12:17:46PM +0200, Andre Vehreschild wrote:
>
> attached small patch removes a VIEW_CONVERT that I erroneously inserted during
> patching pr110033. PR86468 fixes the (co-)rank computation and therefore this
> VIEW_CONVERT is IMO obsolete. I think it may cause hard to find ru
On Sun, Aug 18, 2024 at 12:10:18PM +0200, Thomas Koenig wrote:
>
> this version of the patch includes DOT_PRODUCT, MATMUL and quite
> a few improvements for simplification.
Thomas,
Your updated patch applied cleanly on top-of-tree gcc.
Bootstrap and regression testing on amd64-*-freebsd
comple
On Thu, Aug 08, 2024 at 11:09:10AM +0200, Mikael Morin wrote:
>
> These patches are about inlining, there is no manipulation of the parse
> tree. So I would rather use a separate option (-finline-intrinsics?).
I've only followed the discussion from afar, but gcc already supports
a -finline and -
Thanks for the patch and chasing down the magic.
Path is ok to commit.
--
steve
On Fri, Jul 19, 2024 at 05:32:26PM +0100, Paul Richard Thomas wrote:
> Hi All,
>
> Ping!
>
> I understand now why this works. The scope of the block is merged and so
> all the previous declarations that would othe
On Fri, Jun 28, 2024 at 10:00:53PM +0200, Harald Anlauf wrote:
>
> the attached patch fixes an ICE occuring for ALLOCATE with SOURCE
> (or MOLD) of deferred character length in the scalar case, which
> looked obscure because the ICE disappears at -O1 and higher.
>
> The dump tree suggests that it
On Tue, Jun 18, 2024 at 09:13:23AM +0200, Gerald Pfeifer wrote:
> The original subsite has disappeared and we couldn't find it elsewhere.
>
https://github.com/gklimowicz/FCVS
gklimowicz is a flang developer and member of J3.
--
Steve
On Thu, May 09, 2024 at 01:37:32PM +0800, Kewen.Lin wrote:
>
> >
> > That said, Fortran has the concept of model numbers, which
> > are set in arith.c. Does this change give the expected
> > value for ibm128? For example, with "REAL(16) X", one
> > has "DIGITS(X) = 113", which is the precision
On Wed, May 08, 2024 at 01:27:53PM +0800, Kewen.Lin wrote:
>
> Previously effective target fortran_real_c_float128 never
> passes on Power regardless of the default 128 long double
> is ibmlongdouble or ieeelongdouble. It's due to that TF
> mode is always used for kind 16 real, which has precisio
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 t
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 i
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 safe
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 ha
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 I
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 s
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->
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 ta
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 sp
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 derive
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 libgfortra
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 d
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 th
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 l
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, the
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 13
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
> +++ b/htdocs/gcc-14/
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 that
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 describ
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
> r
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 'si
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 emit
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 character
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
> con
Fortran: 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.
> (
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.
> > >
> > &g
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
> end
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 t
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 fea
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.
https://gcc.gn
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
> zero-sized
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 lurkers
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 par
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 rej
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 segfau
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
2-line/right: ret 666 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 differen
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
suggest
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 its
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 nev
1 - 100 of 1022 matches
Mail list logo
