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 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 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 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
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 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
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 Tue, Dec 19, 2023 at 09:07:08PM +0100, Harald Anlauf wrote:
> Dear all,
>
> in Fortran 2018 a few intrinsics were extended and now support
> additional optional arguments. See PR 85836 for the meta-bug,
> and in particular:
>
> 96583 - get_environment_variable
> 96584 - get_command
> 96585 -
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 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 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
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 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
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 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 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 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 Fri, Jan 26, 2024 at 03:44:26PM +0200, Elias Toivanen wrote:
>
> I stumbled upon a Fortran quirk regarding the ranges for integers.
> The standard stipulates that the ranges be symmetric even though
> as we know two's complement signed integers have asymmetrical
> ranges, e.g. int8 kind can var
On Fri, Jan 26, 2024 at 09:23:56PM +0100, FX Coudert wrote:
>
> This is, for example, legal code (and handled by gfortran as expected):
>
> use iso_fortran_env
> implicit none
> integer(int8) :: j
> data j /-128_int8/
> print *, j
> end
>
Interesting example.
% gfcx -o z a.f90 &&
On Fri, Jan 26, 2024 at 11:38:01PM +0100, FX Coudert wrote:
> > Interesting example.
> >
> > % gfcx -o z a.f90 && ./z
> > -128
> > % gfcx -o z -pedantic a.f90 && ./z
> > a.f90:5:20:
> >
> >5 | data j /-128_int8/
> > |1
> > Error: Integer too big for its kind at (1)
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
All,
Suppose one is working in a funding-constrained environment
such as an academician with limited grant funding. If one
wanted to dabble in GPU offloading with gcc/gfortran, what
recommendations would one have for minimum required hardware?
In addition, are there any vendor software layers tha
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
If you have a gcc bugzilla account, add a comment to the
exist bug with your example. The execution paths through
gfortran for CLASS and "derive type" have significant overlap,
so likely a patch the CLASS issue may also fix your issue.
Note, if you comment out the generic interface for "child",
t
On Sat, Feb 03, 2024 at 02:37:05PM +0100, Richard Biener wrote:
>
> > Am 03.02.2024 um 01:22 schrieb Steve Kargl
> > :
> >
> > All,
> >
> > Suppose one is working in a funding-constrained environment
> > such as an academician with limited grant
On Sat, Feb 03, 2024 at 09:15:21PM +0300, Benson Muite wrote:
> >>>
I wrote:
> >>> Suppose one is working in a funding-constrained environment
> >>> such as an academician with limited grant funding. If one
> >>> wanted to dabble in GPU offloading with gcc/gfortran, what
> >>> recommendations wo
All, consider this simple code:
module foo
contains
subroutine bar
character(len=:), allocatable :: s(:)
call bah(s)
end subroutine bar
end module foo
If one compiles with -fdump-tree-original, one see (with some pruning)
void bar ()
{
integer(kind=8)
On Sat, Feb 10, 2024 at 06:00:42PM -0800, Steve Kargl wrote:
>
> The problem here is that sym->ts.u.cl->length == NULL. If I change
> the conditional to
>
> if (sym->ts.type == BT_CHARACTER
> && sym->ts.u.cl->length
> && !INTEG
On Sun, Feb 11, 2024 at 11:56:52AM +0100, Mikael Morin wrote:
> Hello,
>
> Le 11/02/2024 à 03:00, Steve Kargl a écrit :
> > All, consider this simple code:
> >
> >module foo
> > contains
> >subroutine bar
> > character(len=:)
On Sat, Feb 10, 2024 at 06:00:42PM -0800, Steve Kargl wrote:
> All, consider this simple code:
>
> module foo
> contains
> subroutine bar
> character(len=:), allocatable :: s(:)
> call bah(s)
> end subroutine bar
> end module fo
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
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
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 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.
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 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 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 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
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 Wed, Feb 28, 2024 at 10:42:36PM +, Ken Woolridge wrote:
> A little background: I have Intel's Fortran90 compiler which
> I used for years. However, I recently had to reinstall it
> and found that the key was no longer valid. Intel did not
> have the decency to return my emails so I looked
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
On Thu, Feb 29, 2024 at 10:28:19AM -0800, Jerry D wrote:
> On 2/29/24 10:13 AM, Steve Kargl wrote:
> > 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 educa
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 Wed, Mar 13, 2024 at 12:05:16PM +, Ken Woolridge wrote:
>
> When I attempt to link my test program (FF.F90) which calls UPPER_CASE (an
> assembly routine) I get the following error:
>
> C:/Program
> Files/GCC/bin/../lib/gcc/i686-pc-mingw32/13.2.0/../../../../i686-pc-mingw32/bin/ld.exe:
>
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 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 Sat, Apr 06, 2024 at 05:54:43PM -0600, Neil Carlson wrote:
> What are the recommended options to use (e.g., --enable-libsanitize) when
> building GCC from source for the purpose of locating gfortran bugs? I'm
> trying to pin down a runtime memory corruption error, and I recall seeing
> at variou
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 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
Andre,
I have not seen an answer to your email. I just built gcc/gfortran with
a build directory named objx/. My 'make -j6 check-fortran' completed
without issues (other than the usual broken libsaniziter tests and
confusion of gmake versus make and $MAKE). From your description, it
would certa
I don't know too much about the testsuite infrastructure.
You'll likely need to ping jakub or tobias, who seem to
be the most active gomp contributors.
On my FreeBSD system, I have my sources in gcc/gccx, build in
gcc/objx, and install into $HOME/work/x.
For building and testing, I have a script
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 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
FYI,
For those that do not follow J3, their meeting just finished
this week. One noteworthy paper that passed was 24-166.txt,
"A modest proposal for adding an UNSIGNED type to Fortran".
The paper appears to have been author by Thomas (tkoening@).
Big "Thank You" to Thomas. I have wanted an unsi
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 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 -
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 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 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
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 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
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?
> >
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 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
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 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 Sat, Sep 07, 2024 at 08:17:42PM -0700, Jerry D wrote:
> Steve and others
>
> We continue to run into issues with PRs like this. I would like to close
> these out. I completely hate the mechanisms we have for the options. Why?
> Because every time I look at it I have to think it through ten w
On Mon, Sep 09, 2024 at 12:26:53AM -0700, Damian Rouson wrote:
> On Sat, Sep 7, 2024 at 22:26 Steve Kargl
> wrote:
>
> > On Sat, Sep 07, 2024 at 08:17:42PM -0700, Jerry D wrote:
> >
> >
> > I personally would like to see -std=f2023 made the default.
>
>
, relative to F2003, and I
> suggest that, in memory of Reinhold, this continue as a DIN
> proposal. @Thomas, are you willing to carry this forward or should I
> transfer it to being a UK proposal?
>
> Best regards
>
> Paul
>
>
> On Mon, 9 Sept 2024 at 18:34, Steve Kargl
&
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 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
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 Sun, Oct 06, 2024 at 07:16:18PM +1100, John Campbell wrote:
>
> I can confirm that the bug is not evident in equation.com's Gfortran 11.1.0
This is your problem.
> and earlier, but is present from Gfortran 11.3.0.
Program seems to wo
On Fri, Oct 18, 2024 at 09:51:21PM +0200, Thomas Koenig wrote:
> Am 18.10.24 um 19:11 schrieb Thomas Koenig:
> > Hello world,
> >
> > I am thinking how to add UNSIGNED to the documentation of the
> > intrinsics. Taking BGT, the alphabetically first one, one
> > could
>
> ... send the e-mail too
On Fri, Oct 18, 2024 at 11:35:40AM +0200, Arjen Markus wrote:
>
> The current version of the standard is Fortran 2018 ...
>
The current version of the Fortran standard is ISO/IEC 1539-1:2023;
more commonly known as Fortran 2023.
--
Steve
On Sat, Oct 19, 2024 at 05:38:30PM +, Wyche, George G
PW wrote:
>
> My Fortran project is based on -std=f2008. The GNU Fortran (For GCC version
> 15.0.0) manual's 8.260 STAT example does not link if -std=f2008 is on the
> command line: gfortran -std=f2008 test_st
On Thu, Oct 24, 2024 at 07:46:28PM +0200, Thomas Koenig wrote:
>
> Peter Klausler noted in the discussion on github that Sun Fortran,
> from which the UNSIGNED proposal was drawn, used UNSIGNED instead
> of UINT for conversion of other types to UNSIGNED
> (see https://docs.oracle.com/cd/E19205-01/
On Thu, Oct 24, 2024 at 10:22:29PM +0200, Thomas Koenig wrote:
>
> > I'll note that match.cc(gfc_match_type_spec) has to deal with
> > REAL as a possible intrinsic function. See the comment
> >
> >/* REAL is a real pain because it can be a type, intrinsic subprogram,
> > or list item i
On Tue, Oct 29, 2024 at 04:47:24PM +0900, Kazuyoshi Furutaka wrote:
> I've filed a report, and immediately it was marked as a duplicate
> of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101826
>
Thanks. I was unaware that someone had reported a
similar bug report. Sorry about the extra effort
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 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 Mon, Oct 28, 2024 at 06:00:18PM +0900, Kazuyoshi Furutaka wrote:
> Dear gfortran experts...
>
> The attached program runs OK, but `ptype`ing using gdb
> on the deferred-length character array returns empty(?)
> result, as the following (the results for integer and
> real arrays are correct ):
>
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 Wed, Nov 13, 2024 at 05:33:20PM +0100, Thomas Koenig wrote:
> Am 13.11.24 um 15:55 schrieb Toon Moene:
> >
> > Since the Fortran 95 Standard it does (in the current Standard: 7.4.3.2
> > Real type):
> >
> > The real type includes a zero value. Processors that distinguish between
> > positive a
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 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
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 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, 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 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 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
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
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,
> 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 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 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
> >
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 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
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
1 - 100 of 335 matches
Mail list logo
