Re: [Ping x 3, Fortran, Patch, coarray, PR84246, v2] Fix for [Coarray] ICE in conv_caf_send, at fortran/trans-intrinsic.c:1950
Hi Jerry, thanks for the review. Committed as: gcc-15-3035-g35f56012806 Thanks again, Andre On Mon, 19 Aug 2024 08:46:45 -0700 Jerry D wrote: > On 8/19/24 4:43 AM, Andre Vehreschild wrote: > > Hi all, > > > > another ping on this patch. > > > > Regtests ok on x86_64-pc-linux-gnu on updated master. Ok for mainline? > > > > Regards, > > Andre > > > > Looks OK to go ahead Andre. > > Thanks, > > Jerry > > > On Fri, 9 Aug 2024 16:29:08 +0200 > > Andre Vehreschild wrote: > > > >> Ping! > >> > >> On Wed, 17 Jul 2024 15:15:51 +0200 > >> Andre Vehreschild wrote: > >> > >>> Hi all, > >>> > >>> attached patch fixes an ICE in coarray code, where the coarray expression > >>> already was a pointer, which confused the compiler. Furthermore have I > >>> removed a rewrite to a caf_send late in the trans-phase. This is now done > >>> in the resolve stage to have only a single place for these rewriting > >>> actions. > >>> > >>> Regtests ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline? > >>> > >>> Regards, > >>> Andre > >>> -- > >>> Andre Vehreschild * Email: vehre ad gmx dot de > >> > >> > > > > > > -- > > Andre Vehreschild * Email: vehre ad gmx dot de > -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: [PATCH v2 10/10] fortran: Add -finline-intrinsics flag for MINLOC/MAXLOC [PR90608]
Hello,
Le 19/08/2024 à 21:44, Harald Anlauf a écrit :
Hi Mikael,
apart from patch #04/10, which did not apply cleanly here, I was
able to test your patch. It seems to work with a manual workaround
(-fno-frontend-optimize) to work around this problem.
Might be a local issue...
Huh? That's unexpected, patches were rebased before submitting, and I
don't think there was any recent activity in that area of the compiler
anyway.
That said, it works as advertised. Thanks for separating out the
IEEE-NaN tests.
What I did not fully get is the way you deal with -finline-intrinsics= .
Currently there are only MINLOC and MAXLOC, but in the future there
could be many more intrinsics. Given that you need 2 bits per
intrinsic in flag_inline_intrinsics, how future-proof is that?
Well, I don't expect that many candidate intrinsics for the flags;
currently SUM and PRODUCT could be added, and probably IALL, IANY and
IPARITY as well. Remember that having both a libgfortran and a frontend
implementation is a prerequisite.
For the future, 2 bits gives room to 16 intrinsics, and if we extend to
64 bits, to 32 intrinsics without much hassle. Having only 1 bit per
intrinsic would be certainly more future proof but I haven't found how
to do it. Zero bit (aka no per-intrinsic setting) would be even more
future-proof, but less convenient. As a last resort possibility the
.opt framework gives the possibility to accumulate options in a vector
and have them processed "by hand". It seemed more convenient to me to
just use 2 bits per intrinsic, but we can fall back to manual processing
if we get out of bits at some point.
Using only 1 bit per intrinsic was what I tried first, but then the
default value has to be set before processing the flags, which means no
default value depending on optimization, as optimization level is not
known at that time. I tried using EnabledBy(O || Ofast || Og) to set
default value dependending on optimization, but this doesn't work either
because the "O" covers all levels (-O0, -O1, -O2, -O3) without
distinction. And finally EnabledBy(O1 || O2 || O3 || Ofast || Og) is
not accepted because "O1", "O2" and "O3" are not valid option names.
I can certainly drop the per-intrinsic setting to have unlimited room
for future intrinsics. Or if you have ideas on how to only use one bit
per intrinsic, I'm all ears. Or maybe the testcases are too cumbersome,
and with a slight modification of behaviour we can save one bit (for
example, also generate inline code for -O0). What do you think?
In the documentation, you have:
+The set of intrinsics permitting the choice of implementation variant
through
+@code{-finline-intrinsics} is currently limited to non-scalar
@code{MAXLOC} and
+@code{MINLOC}.
Why do you say "non-scalar"? The new inlining is done for these
intrinsics when the DIM argument is absent. The result characteristics
however is:
"If DIM does not appear, the result is an array of rank one and of
size equal to the rank of ARRAY; ..."
and I thought the implementation does just that and does that right.
(With DIM present, the result is an array of rank rank(arg)-1.)
Can you clarify the wording in a way that is better understandable?
Yeah, these patches are all about non-scalar MINLOC/MAXLOC. But there
is also the scalar MINLOC/MAXLOC case which has pre-existing inline code
support (and on which these patches are based). The scalar case (aka
with DIM present, and ARRAY of rank 1) is always inlined, so the flag
has no effect on it.
Does this sound better?:
The set of intrinsics allowed as argument to @code{-finline-intrinsics=}
is currently limited to @code{MAXLOC} and @code{MINLOC}. The effect of
the flag is moreover limited to calls of those intrinsics without
@code{DIM} argument and with @code{ARRAY} of a non-@code{CHARACTER} type.
Otherwise the Fortran parts look fine to me.
Thanks for the review.
For the changes to gcc/flag-types.h you might need an OK from the
gcc maintainers.
Thanks,
Harald
[Fortran, Patch, PR86468, v1] Fix propagation of corank to array components in derived types.
Hi all,
attached patch fixes an ICE in gimplify by assuring that the corank of a
non-pointer, non-coarray array component in a derived type is zero. Previously
(erroneously) the full corank of the type has been used. There is one exception
for pointer typed array components in coarray derived types. These can be
associated only to coarray array targets (compare F2018 C1024 and C1026).
Therefore for those the corank is still propagated.
Regtests ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
From 0ba7ab80bce08f0b3c6f1f4928f95c87b4bbd39d Mon Sep 17 00:00:00 2001
From: Andre Vehreschild
Date: Fri, 16 Aug 2024 15:07:39 +0200
Subject: [PATCH] [Fortran] Fix coarray rank for non-coarrays in derived types.
[PR86468]
The corank was propagated to array components in derived types. Fix
this by setting a zero corank when the array component is not a pointer.
For pointer typed array components propagate the corank of the derived
type to allow associating the component to a coarray.
gcc/fortran/ChangeLog:
PR fortran/86468
* trans-intrinsic.cc (conv_intrinsic_move_alloc): Correct
comment.
* trans-types.cc (gfc_sym_type): Pass coarray rank, not false.
(gfc_get_derived_type): Only propagate codimension for coarrays
and pointers to array components in derived typed coarrays.
gcc/testsuite/ChangeLog:
* gfortran.dg/coarray_lib_this_image_2.f90: Fix array rank in
tree dump scan.
* gfortran.dg/coarray_lib_token_4.f90: Same.
* gfortran.dg/coarray/move_alloc_2.f90: New test.
---
gcc/fortran/trans-intrinsic.cc| 2 +-
gcc/fortran/trans-types.cc| 16 +++---
.../gfortran.dg/coarray/move_alloc_2.f90 | 55 +++
.../gfortran.dg/coarray_lib_this_image_2.f90 | 2 +-
.../gfortran.dg/coarray_lib_token_4.f90 | 4 +-
5 files changed, 68 insertions(+), 11 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/coarray/move_alloc_2.f90
diff --git a/gcc/fortran/trans-intrinsic.cc b/gcc/fortran/trans-intrinsic.cc
index 586fc65f21d..ceda7843fa9 100644
--- a/gcc/fortran/trans-intrinsic.cc
+++ b/gcc/fortran/trans-intrinsic.cc
@@ -12906,7 +12906,7 @@ conv_intrinsic_move_alloc (gfc_code *code)
gfc_add_expr_to_block (&block, tmp);
}
- /* Move the pointer and update the array descriptor data. */
+ /* Copy the array descriptor data. */
gfc_add_modify_loc (input_location, &block, to_se.expr, from_se.expr);
/* Set "from" to NULL. */
diff --git a/gcc/fortran/trans-types.cc b/gcc/fortran/trans-types.cc
index bc582085f57..ba2ffba8ec1 100644
--- a/gcc/fortran/trans-types.cc
+++ b/gcc/fortran/trans-types.cc
@@ -2386,7 +2386,7 @@ gfc_sym_type (gfc_symbol * sym, bool is_bind_c)
else if (sym->attr.allocatable)
akind = GFC_ARRAY_ALLOCATABLE;
type = gfc_build_array_type (type, sym->as, akind, restricted,
- sym->attr.contiguous, false);
+ sym->attr.contiguous, sym->as->corank);
}
}
else
@@ -2909,12 +2909,14 @@ gfc_get_derived_type (gfc_symbol * derived, int codimen)
else
akind = GFC_ARRAY_ALLOCATABLE;
/* Pointers to arrays aren't actually pointer types. The
- descriptors are separate, but the data is common. */
- field_type = gfc_build_array_type (field_type, c->as, akind,
- !c->attr.target
- && !c->attr.pointer,
- c->attr.contiguous,
- codimen);
+ descriptors are separate, but the data is common. Every
+ array pointer in a coarray derived type needs to provide space
+ for the coarray management, too. Therefore treat coarrays
+ and pointers to coarrays in derived types the same. */
+ field_type = gfc_build_array_type (
+ field_type, c->as, akind, !c->attr.target && !c->attr.pointer,
+ c->attr.contiguous,
+ c->attr.codimension || c->attr.pointer ? codimen : 0);
}
else
field_type = gfc_get_nodesc_array_type (field_type, c->as,
diff --git a/gcc/testsuite/gfortran.dg/coarray/move_alloc_2.f90 b/gcc/testsuite/gfortran.dg/coarray/move_alloc_2.f90
new file mode 100644
index 000..4a8e54ced6b
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/coarray/move_alloc_2.f90
@@ -0,0 +1,55 @@
+!{ dg-do run }
+
+! Check gimplify with checking works. [PR86468]
+! This rather complicated code is needed to produce two "different"
+! types in the move_alloc.
+
+! Contributed by Juergen Reuter
+
+module classes
+ implicit none
+ private
+ public :: wrapped_coarray
+
+ type :: wrapped_point
+ integer, allocatable :: point(:)
+ contains
+ procedure :: add => wrapped_point_add
+ end type wrapped_point
+
+ type :: wrapped_coarray
+ type(wrapped_point), allocatable :: caf(:)[:]
+ end type wrapped_coarray
+
+contains
+
+ subroutine wrapped_point_add(self, to_add)
+class(wrapped_point), intent(inout) :: self
+integer, intent(in) :: to_add
+integer, allocatable :: point(:)
+integer :: points_number
+
+if (allocated(self
Re: [Ping x2 , Fortran, Patch, PR77518, (coarray), v4] Fix ICE in sizeof(coarray)
Hi all,
pinging this patch.
Regtests ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline?
Regards,
Andre
On Fri, 9 Aug 2024 16:30:52 +0200
Andre Vehreschild wrote:
> Ping!
>
> @Paul, you already had a look at this patch, but I made some changes. Or they
> ok?
>
> - Andre
>
> On Fri, 19 Jul 2024 13:26:21 +0200
> Andre Vehreschild wrote:
>
> > Hi Paul,
> >
> > thanks for the review.
> >
> > > While I realise that this is not your doing, should we not
> > > check DECL_LANG_SPECIFIC ()) before touching GFC_DECL_SAVED_DESCRIPTOR?
> >
> > I like that idea. I have added it. But what should we do when
> > DECL_LANG_SPECIFIC is not set? I have chosen to add a gcc_unreachable(), but
> > that will trigger an ICE in the future should the prerequisites not be met.
> >
> > > Or is access guaranteed by the REF_COMPONENT check?
> >
> > Well, as we have seen, it is not. At least that is not guaranteed to my
> > knowledge.
> >
> > When you don't like this solution solution, then I will dig deeper to figure
> > what is going on and how to resolve it.
> >
> > > A micro-nit line 12 s/User/Use/
> >
> > Ups, thanks, fixed.
> >
> > Not merging yet, therefore updated patch attached.
> >
> > - Andre
> >
> > >
> > > Apart from this, it looks to be eminently obvious. OK for mainline.
> > >
> > > Paul
> > >
> > >
> > > On Thu, 18 Jul 2024 at 14:16, Andre Vehreschild wrote:
> > >
> > > > Hi all,
> > > >
> > > > the attached patch fixes an ICE when the object supplied to sizeof() is
> > > > a coarray of class type. This is fixed by taking the class object from
> > > > the se's class_container.
> > > >
> > > > Regtests ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline?
> > > >
> > > > Regards,
> > > > Andre
> > > > --
> > > > Andre Vehreschild * Email: vehre ad gcc dot gnu dot org
> > > >
> >
> >
> > --
> > Andre Vehreschild * Email: vehre ad gmx dot de
>
>
> --
> Andre Vehreschild * Email: vehre ad gmx dot de
--
Andre Vehreschild * Email: vehre ad gmx dot de
From 976c84f608eb9b00940ec30b147e542f90f217a0 Mon Sep 17 00:00:00 2001
From: Andre Vehreschild
Date: Thu, 18 Jul 2024 14:53:31 +0200
Subject: [PATCH] Fortran: Fix ICE in sizeof(coarray) [PR77518]
Use se's class_container where present in sizeof().
PR fortran/77518
gcc/fortran/ChangeLog:
* trans-intrinsic.cc (gfc_conv_intrinsic_sizeof): Use
class_container of se when set.
gcc/testsuite/ChangeLog:
* gfortran.dg/coarray/sizeof_1.f90: New test.
---
gcc/fortran/trans-intrinsic.cc| 13 ++---
.../gfortran.dg/coarray/sizeof_1.f90 | 27 +++
2 files changed, 37 insertions(+), 3 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/coarray/sizeof_1.f90
diff --git a/gcc/fortran/trans-intrinsic.cc b/gcc/fortran/trans-intrinsic.cc
index fd2da463825..0ecb0439778 100644
--- a/gcc/fortran/trans-intrinsic.cc
+++ b/gcc/fortran/trans-intrinsic.cc
@@ -8216,10 +8216,17 @@ gfc_conv_intrinsic_sizeof (gfc_se *se, gfc_expr *expr)
else if (arg->rank > 0
|| (arg->rank == 0
&& arg->ref && arg->ref->type == REF_COMPONENT))
- /* The scalarizer added an additional temp. To get the class' vptr
- one has to look at the original backend_decl. */
- byte_size = gfc_class_vtab_size_get (
+ {
+ /* The scalarizer added an additional temp. To get the class' vptr
+ one has to look at the original backend_decl. */
+ if (argse.class_container)
+ byte_size = gfc_class_vtab_size_get (argse.class_container);
+ else if (DECL_LANG_SPECIFIC (arg->symtree->n.sym->backend_decl))
+ byte_size = gfc_class_vtab_size_get (
GFC_DECL_SAVED_DESCRIPTOR (arg->symtree->n.sym->backend_decl));
+ else
+ gcc_unreachable ();
+ }
else
gcc_unreachable ();
}
diff --git a/gcc/testsuite/gfortran.dg/coarray/sizeof_1.f90 b/gcc/testsuite/gfortran.dg/coarray/sizeof_1.f90
new file mode 100644
index 000..b26f8416406
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/coarray/sizeof_1.f90
@@ -0,0 +1,27 @@
+!{ dg-do run }
+
+! Check that pr77518 is fixed.
+! Based on code by Gerhard Steinmetz
+
+program coarray_sizeof_1
+ type t
+ end type
+ type t2
+integer :: v = 42
+ end type
+ type t3
+type(t2) :: s
+integer :: n = 1
+ end type
+
+ class(t), allocatable :: z[:]
+ class(t2), allocatable :: z2[:]
+ class(t3), allocatable :: z3[:]
+
+ if (sizeof(z) /= 0) stop 1
+ if (sizeof(z2) /= sizeof(integer)) stop 2
+ allocate(z3[*])
+ if (sizeof(z3) /= sizeof(z2) + sizeof(integer)) stop 3
+ if (sizeof(z3%s) /= sizeof(z2)) stop 4
+end
+
--
2.46.0
Re: [Ping x2 , Fortran, Patch, PR77518, (coarray), v4] Fix ICE in sizeof(coarray)
On 8/20/24 5:35 AM, Andre Vehreschild wrote: Hi all, pinging this patch. Regtests ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline? Regards, Andre Your approach looks reasonable so I think OK to push. Thanks, Jerry
Re: [PATCH v2 10/10] fortran: Add -finline-intrinsics flag for MINLOC/MAXLOC [PR90608]
Hi Mikael,
Am 20.08.24 um 11:51 schrieb Mikael Morin:
Hello,
Le 19/08/2024 à 21:44, Harald Anlauf a écrit :
Hi Mikael,
apart from patch #04/10, which did not apply cleanly here, I was
able to test your patch. It seems to work with a manual workaround
(-fno-frontend-optimize) to work around this problem.
Might be a local issue...
Huh? That's unexpected, patches were rebased before submitting, and I
don't think there was any recent activity in that area of the compiler
anyway.
staring at that patch and the code revealed that Andre's coarray rank
stuff interfered, so you might see a merge conflict. I managed to
resolve this, and then everything passes. Good!
That said, it works as advertised. Thanks for separating out the
IEEE-NaN tests.
What I did not fully get is the way you deal with -finline-intrinsics= .
Currently there are only MINLOC and MAXLOC, but in the future there
could be many more intrinsics. Given that you need 2 bits per
intrinsic in flag_inline_intrinsics, how future-proof is that?
Well, I don't expect that many candidate intrinsics for the flags;
currently SUM and PRODUCT could be added, and probably IALL, IANY and
IPARITY as well. Remember that having both a libgfortran and a frontend
implementation is a prerequisite.
Yes, these are the primary candidates. Maybe NORM2; MINVAL, MAXVAL;
FINDLOC; CSHIFT as well.
For the future, 2 bits gives room to 16 intrinsics, and if we extend to
64 bits, to 32 intrinsics without much hassle. Having only 1 bit per
intrinsic would be certainly more future proof but I haven't found how
to do it. Zero bit (aka no per-intrinsic setting) would be even more
future-proof, but less convenient. As a last resort possibility the
.opt framework gives the possibility to accumulate options in a vector
and have them processed "by hand". It seemed more convenient to me to
just use 2 bits per intrinsic, but we can fall back to manual processing
if we get out of bits at some point.
Using only 1 bit per intrinsic was what I tried first, but then the
default value has to be set before processing the flags, which means no
default value depending on optimization, as optimization level is not
known at that time. I tried using EnabledBy(O || Ofast || Og) to set
default value dependending on optimization, but this doesn't work either
because the "O" covers all levels (-O0, -O1, -O2, -O3) without
distinction. And finally EnabledBy(O1 || O2 || O3 || Ofast || Og) is
not accepted because "O1", "O2" and "O3" are not valid option names.
I can certainly drop the per-intrinsic setting to have unlimited room
for future intrinsics. Or if you have ideas on how to only use one bit
per intrinsic, I'm all ears. Or maybe the testcases are too cumbersome,
and with a slight modification of behaviour we can save one bit (for
example, also generate inline code for -O0). What do you think?
Since the logic is essentially ternary, using 2 bits is natural.
I was not sure if we would be limited to 16 intrinsics, which would
be fairly small, since I did not see what types are possible.
32 is probably good enough for the next decade or so...
In the documentation, you have:
+The set of intrinsics permitting the choice of implementation variant
through
+@code{-finline-intrinsics} is currently limited to non-scalar
@code{MAXLOC} and
+@code{MINLOC}.
Why do you say "non-scalar"? The new inlining is done for these
intrinsics when the DIM argument is absent. The result characteristics
however is:
"If DIM does not appear, the result is an array of rank one and of
size equal to the rank of ARRAY; ..."
and I thought the implementation does just that and does that right.
(With DIM present, the result is an array of rank rank(arg)-1.)
Can you clarify the wording in a way that is better understandable?
Yeah, these patches are all about non-scalar MINLOC/MAXLOC. But there
is also the scalar MINLOC/MAXLOC case which has pre-existing inline code
support (and on which these patches are based). The scalar case (aka
with DIM present, and ARRAY of rank 1) is always inlined, so the flag
has no effect on it.
I was asking because you refer by "scalar" or "non-scalar" to the
result, not to the argument. This looked like non-standard use of
language to me.
Does this sound better?:
The set of intrinsics allowed as argument to @code{-finline-intrinsics=}
is currently limited to @code{MAXLOC} and @code{MINLOC}. The effect of
the flag is moreover limited to calls of those intrinsics without
@code{DIM} argument and with @code{ARRAY} of a non-@code{CHARACTER} type.
Yes, this is better. Do you want to add something like:
The case of rank-1 argument and @code{DIM} argument present, i.e.
@code{MAXLOC}(A(:),@code{DIM}=1)} or @code{MINLOC}(A(:),@code{DIM}=1)}
is inlined unconditionally for numeric rank-1 array argument A.
Thanks,
Harald
Otherwise the Fortran parts look fine to me.
Thanks for the review.
For the changes to gcc/flag-types.h you might need an OK from the
gcc ma
Re: [Fortran, Patch, PR86468, v1] Fix propagation of corank to array components in derived types.
Hi Andre, Am 20.08.24 um 13:52 schrieb Andre Vehreschild: Hi all, attached patch fixes an ICE in gimplify by assuring that the corank of a non-pointer, non-coarray array component in a derived type is zero. Previously (erroneously) the full corank of the type has been used. There is one exception for pointer typed array components in coarray derived types. These can be associated only to coarray array targets (compare F2018 C1024 and C1026). Therefore for those the corank is still propagated. the patch is OK for mainline, but the formatting violates the coding style here: @@ -2909,12 +2909,14 @@ gfc_get_derived_type (gfc_symbol * derived, int codimen) else akind = GFC_ARRAY_ALLOCATABLE; /* Pointers to arrays aren't actually pointer types. The -descriptors are separate, but the data is common. */ - field_type = gfc_build_array_type (field_type, c->as, akind, -!c->attr.target -&& !c->attr.pointer, -c->attr.contiguous, -codimen); +descriptors are separate, but the data is common. Every +array pointer in a coarray derived type needs to provide space +for the coarray management, too. Therefore treat coarrays +and pointers to coarrays in derived types the same. */ + field_type = gfc_build_array_type ( ^^^ Please move this opening parenthesis to the next line, otherwise the indenting with emacs goes sideways. + field_type, c->as, akind, !c->attr.target && !c->attr.pointer, + c->attr.contiguous, + c->attr.codimension || c->attr.pointer ? codimen : 0); } else field_type = gfc_get_nodesc_array_type (field_type, c->as, Thanks, Harald Regtests ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline? Regards, Andre -- Andre Vehreschild * Email: vehre ad gmx dot de
Open MP: threadprivate
Hi, gfortran from gcc/11.3.0 tells me that the iteration variable of a loop parallelized with the !$omp do construct must not have the threadprivate attribute. Is this standard-conforming? Other compilers, e.g. CRAY, don't complain. Thanks and best regards, M. Rheinhardt
Installing gfortran-14
I did this in my Ubuntu 22.04 system with no trouble: (lf) john:~$ sudo add-apt-repository ppa:ubuntu-toolchain-r/test but the next step failed: (lf) john:~$ sudo apt install gfortran-14 Reading package lists... Done Building dependency tree... Done Reading state information... Done Package gfortran-14 is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source E: Package 'gfortran-14' has no installation candidate (lf) john:~$ What should I have done? -- John Harper, School of Mathematics and Statistics Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand. e-mail john.har...@vuw.ac.nz
Re: Installing gfortran-14
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 get. However, what I liked about Ubuntu was that it seemed to be aggressive about installing more up-to-date versions of GCC than some other Linux distributions, so if it's an option, you might get a newer version of GCC by updating your Ubuntu kernel and then the above apt command again. I think the latest version is Ubuntu 24. FWIW, I mostly used the Lubuntu lightweight Ubuntu distribution. If you really need GCC 14 and the above advice doesn't help, you might try running the OpenCoarrays installer script to build whatever version you want from source: git clone https://github.com/sourceryinstitute/opencoarrays cd opencoarrays ./install.sh --package gcc --install-version 14 --install-prefix --num-threads 4 or run ./install.sh. --help for additional options or shorter versions of the above options. I hope this is all helpful. Damian On Tue, Aug 20, 2024 at 4:08 PM John Harper wrote: > I did this in my Ubuntu 22.04 system with no trouble: > > (lf) john:~$ sudo add-apt-repository ppa:ubuntu-toolchain-r/test > > but the next step failed: > > (lf) john:~$ sudo apt install gfortran-14 > Reading package lists... Done > Building dependency tree... Done > Reading state information... Done > Package gfortran-14 is not available, but is referred to by another > package. > This may mean that the package is missing, has been obsoleted, or > is only available from another source > > E: Package 'gfortran-14' has no installation candidate > (lf) john:~$ > > What should I have done? > > -- John Harper, School of Mathematics and Statistics > Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand. > e-mail john.har...@vuw.ac.nz >
Re: Installing gfortran-14
To install a specific version of gcc, you could perhaps use pkgsrc (NetBSD package manager, but it works on every system, including Linux). Serge On Aug 21, 2024 at 07:35 +0800, Damian Rouson , wrote: > 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 get. However, what I liked about Ubuntu was that > it seemed to be aggressive about installing more up-to-date versions of GCC > than some other Linux distributions, so if it's an option, you might get a > newer version of GCC by updating your Ubuntu kernel and then the above apt > command again. I think the latest version is Ubuntu 24. FWIW, I mostly used > the Lubuntu lightweight Ubuntu distribution. > > If you really need GCC 14 and the above advice doesn't help, you might try > running the OpenCoarrays installer script to build whatever version you want > from source: > > git clone https://github.com/sourceryinstitute/opencoarrays > cd opencoarrays > ./install.sh --package gcc --install-version 14 --install-prefix > --num-threads 4 > > or run ./install.sh. --help for additional options or shorter versions of the > above options. > > I hope this is all helpful. > > Damian > > > > > On Tue, Aug 20, 2024 at 4:08 PM John Harper wrote: > > > I did this in my Ubuntu 22.04 system with no trouble: > > > > > > (lf) john:~$ sudo add-apt-repository ppa:ubuntu-toolchain-r/test > > > > > > but the next step failed: > > > > > > (lf) john:~$ sudo apt install gfortran-14 > > > Reading package lists... Done > > > Building dependency tree... Done > > > Reading state information... Done > > > Package gfortran-14 is not available, but is referred to by another > > > package. > > > This may mean that the package is missing, has been obsoleted, or > > > is only available from another source > > > > > > E: Package 'gfortran-14' has no installation candidate > > > (lf) john:~$ > > > > > > What should I have done? > > > > > > -- John Harper, School of Mathematics and Statistics > > > Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand. > > > e-mail john.har...@vuw.ac.nz
