I assume it’s too late for new project ideas. I’m adding Milan Curcic in
cc to confirm.
Damian
On Wed, Mar 9, 2022 at 18:09 Jerry D via Fortran
wrote:
> Perhaps someone could work on completing and merging the shared memory
> (native) fortran coarrays branch.
>
> Regards,
>
> Jerry
>
> On 3/9/
https://wg5-fortran.org/N1151-N1200/N1191.pdf
On Fri, May 27, 2022 at 21:19 Scott Mehring via Fortran
wrote:
> Where is the download link for FORTRAN 95?
>
>
>
>
>
>
>
> Scott A. Mehring
>
> 6604 Carlisle Pike
>
> Mechanicsburg, PA 17050
>
> (717) 379-2404
>
>
>
>
On Mon, Jun 13, 2022 at 8:27 AM Jonathan Wakely via Fortran <
fortran@gcc.gnu.org> wrote:
>
> Yes, it does that, but takes 400 lines of shell script to do so.
>
> If you want "relatively easy ways to build GCC painlessly" then you
> can do it with nine lines of shell commands.
>
> Or in about 80,
On Mon, Jun 13, 2022 at 8:27 AM Jonathan Wakely via Fortran <
fortran@gcc.gnu.org> wrote:
>
> It doesn't include them, but they are standard system packages that
> everybody can install without downloading the sources and building
> them from scratch.
unless the person is on a system on which th
Thanks for asking this, Jerry!
Sourcery Institute has a (small) amount of funding that can be offered for
this work in case that helps.
Damian
On Wed, Nov 2, 2022 at 6:32 PM Jerry D via Fortran
wrote:
> Hi Paul,
>
> Long time no chat. I hope you and yours are well.
>
> I was planning to retir
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 specifiers
but possibly a good first exercise.
Damian
On Thu, Feb 23, 2023 at
Thanks for working on this, guys. I made a few suggestions below.
Damian
On Wed, May 31, 2023 at 5:25 AM Andre Vehreschild via Fortran <
fortran@gcc.gnu.org> wrote:
>
> - Dependencies (on the project as well as projects that depend on the
> technology; max 300 words)
>
> CP2K https://www.cp2k
It has been a few years since I used Ubuntu. If I recall correctly, I think
you can just use
sudo apt install gcc
and that will install gcc, g++, and gfortran. My Linux knowledge is
limited. I never figured out how to install a specific version of GCC on
Ubuntu so I think you just get what you
A program compiled with gfortran terminates with a segmentation fault
at an intrinsic assignment to an allocatable array component of a
derived type with a kind type parameter. Please see below. I tried
several workarounds, including replacing the intrinsic assignment with
a type-bound defined as
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.
I would absolutely love that too. I’ve lost countless hours chasing down
issues (in other compilers) that didn’t make sta
Hi Steve,
I hope the gfortran developers won't commit a patch that replaces
existing behavior with a stub that simply emits an error message. It
has been a while since I looked at the previous emails regarding
problems with the current behavior so I'm not expressing an opinion
about the current b
The email below seems to be the most recent email on native coarray
support. Has there been any more recent work or plans for committing a
patch? Could someone tell me whether the planned feature will work on
Windows without requiring the Windows Subsystem for Linux? Asking for a
friend. :)
Dam
On Tue, Nov 2, 2021 at 8:56 AM Sandra Loosemore
wrote:
>
> ... I will hold off on that if it's going to cause problems.
>
> Thanks for taking on this task, Sandra. I'm not aware of the technical
issues around mark-up formatting and the transition that's happening, but I
hope nothing holds up a l
In TS 18508, the second summy argument of co_reduce was named
"operator." In the Fortran 2018 standard, the corresponding argument
has the name "operation." GFortran accepts the non-standard keyword
argument name "operator" and rejects the standard name "operation."
% cat co_reduce.f90
implici
The Fortran 2023 interpretation document clause 15.5.2.10 paragraph 5
allows a dummy argument procedure pointer to have a corresponding
actual argument that is a valid target for the dummy pointer in a
pointer assignment statement. I believe this feature first appeared
in the 2008 standard. Gfortr
I'm attempting to submit the code below to Bugzilla, but the site
appears to be hanging. I'll try again later. Presumably this should
be added to the deferred-length character metabug. This code executes
without error when compiled with gfortran 14.2.0, but seg faults when
compiled with a recent
I just submitted the following as the above PR:
The code below compiles without error with gfortran 12 and 13 but
causes internal compiler errors with gfortran 14.2.0 and 15.
% cat all.f90
implicit none
type string_t
end type
associate(string_array => get_string([string_t::]))
end ass
This is now PR 118747 and it has been marked as blocking 68241.
D
On Tue, Feb 4, 2025 at 10:10 AM Damian Rouson wrote:
>
> I'm attempting to submit the code below to Bugzilla, but the site
> appears to be hanging. I'll try again later. Presumably this should
> be added
This is a big deal, Andre! Thanks for working on this patch. I have some
test code that I can dig up if that’s helpful. Have you tested with nested
derived type components, i.e., allocatable components that are themselves
derived types that have allocatable components?
The need for this featur
I don’t think the standard requires providing the stop code to the OS, but
it recommends doing so. So this is a great idea. Thanks for working on
coarray features.
Damian
On Thu, Dec 19, 2024 at 04:14 Andre Vehreschild wrote:
> Hi all,
>
> attached patch fixes a rather old open issue, that I
On Tue, Dec 17, 2024 at 20:05 Steve Kargl
wrote:
> On Mon, Dec 16, 2024 at 04:53:42AM -0800,
Or, perhaps, you care to qualify your generalization?
Thanks for asking. When I tried using kind type parameters on derived
types with gfortran a few months ago, I gave up because the issues appeared
to
The first error message in my previous email led me to the following
constraint:
“*C1130* A *variable-name *that appears in a LOCAL or LOCAL_INIT
*locality-spec *shall not have the ALLOCATABLE, INTENT (IN), or OPTIONAL
attribute, shall not be of finalizable type, shall not have an allocatable
ult
I recently built the master branch of Iain's fork of gcc in order to test
the support for locality specifiers. I have verified that the branch I
built contains the commit mentioned in this email thread
20b8500cfa522ebe0fcf756d5b32816da7f904dd. The code below isn't designed to
do anything useful
In case it would help to see another open-source implementation, there
exists a public branch of LLVM that parallelizes DO CONCURRENT using
OpenMP. The LLVM fork and git tag that I’ve used since November is cited
in the “CPU Parallelism on Perlmutter” slide at
http://go.lbl.gov/just-write-fortran.
In case it helps anyone to see how significant the reduction in
complexity can be with support for locality specifiers, we have
Fortran 2008, 2018, and 2023 versions of the "do concurrent" construct
that lies at the heart of our neural-network training code here:
https://github.com/BerkeleyLab/fia
If this moves forward, I’d like to offer example code to target in Fiats (
https://go.lbl.gov/fiats). I presented automatic parallelization results
produced by compiling with LLVM flang-new for inference at the PAW-ATM
workshop at SC24 (see https://go.lbl.gov/just-write-fortran). It would be
great
F2008_LOCALITY macro switches to default locality. In this code,
the biggest savings comes from reduce locality.
Damian
On Mon, Mar 10, 2025 at 10:20 Jerry D wrote:
> On 3/10/25 4:29 AM, Damian Rouson wrote:
> > If this moves forward, I’d like to offer example code to target in Fiats
> > (htt
With gfortran 12.4.0, 13.3.0, and 14.2.0, the program below prints
"T". With gfortran 15, the program crashes with an error message
that indicates that a pointer is being freed that was not allocated.
% cat all.f90
implicit none
type string_t
character(len=:), allocatable :: string_
e
An associate construct causes the alloc error "pointer being freed was
not allocated" when the selector is a structure constructor for a
derived type with an allocatable component and a procedure pointer
component. This same error occurs if a function returning the same
type replaces the structure
gfortran 12, 13, 14, and 15 all reject the source allocation of a pure
function result object's allocatable component with the message "Bad
allocate-object at (1) for a PURE procedure". Removing "pure"
eliminates the error. Alternatively, removing the separate procedure
interface also eliminates
For an assumed-type, assumed-rank complex dummy argument in a C interface,
gfortran 11.2.0 passes a CFI_cdesc_t object with a "type" member that does
not match the corresponding CFI_type_float_Complex and
CFI_type_double_Complex values. In the case of a complex(c_float_complex)
argument, the passed
mplex = 1028
> CFI_type_double_Complex = 2052
>
> Cheers
>
> Paul
>
>
> On Sun, 6 Feb 2022 at 03:39, Damian Rouson via Fortran <
> fortran@gcc.gnu.org> wrote:
>
>> For an assumed-type, assumed-rank complex dummy argument in a C interface,
>> gfortran 11.2.0
In case it's useful to gfortran developers, the Reference-Counter
repository (https://github.com/sourceryinstitute/reference-counter)
contains a test/compiler_test.f90 file that separately tests each of the
scenarios in which Fortran 2018 clause 7.5.6.3 requires type finalization
to occur. Thanks
gfortran 12.2 accepts the code below if the "allocatable" attribute is
removed:
% cat gfortran-lock-issue.f90
use iso_fortran_env
type foo
type(lock_type), allocatable :: bar
end type
type(foo) foobar[*]
end
% gfortran -fcoarray=single gfortran-lock-issue.f90
gfortran-lock-issue.f90:
I just added a shorter reproducer (below) to PR 100650. Is this also
related to PR 49324?
Damian
% cat reshape-array-constructor.f90
implicit none
type foo_t
integer, allocatable :: bar(:)
end type
type(foo_t) foo(2,1)
integer :: i, j, n(2,2,1) = reshape([-1,-1,1,1], [2,2,1])
35 matches
Mail list logo
