Dear all,
In the spirit of c/c++ using the .i/.ii extensions for intermediates,
use the .fi/.fii intermediate extensions for gfortran fixed/free form
sources when -save-temps is invoked to avoid various issues.
The documentation part will be submitted separately, because it
involves adding a
> Likely GFC_INTEGER_8 or int64_t or compatible. We have 32/64bit and
> -fdefault-integer-8 to deal with…
That’s why I am suggesting either “int” or “size_t”, i.e., a well-defined C
type. Means we don’t have to deal with -fdefault-integer.
FX
Hi Steve,
> At one time, we kept track of things that would break
> libgfortran's ABI on the wiki. You can find the list
> at https://gcc.gnu.org/wiki/LibgfortranAbiCleanup.
> This could be old and moldy as I haven't checked in
> on ABI changes in a long time.
this looks indeed old and moldy...
Hi FX,
> Hi Harald,
>
> > If we do not want to break the existing ABI, so that we can
> > link gfortran-13 and gfortran-14+(?) compiled code, we need
> > to keep _gfortran_get_command_i4 & friends, and introduce
> > new library functions that are able to handle the new
> > requirements.
>
> I
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 12/19/23 1:10 PM, FX Coudert wrote:
Hi,
I am getting side notes about people having these issues with gfortran 13. Is
this something that should be backported.
I have already backported it in the latest Homebrew package (because we have
many users complaining about it). I intend to
Hi,
> I am getting side notes about people having these issues with gfortran 13. Is
> this something that should be backported.
I have already backported it in the latest Homebrew package (because we have
many users complaining about it). I intend to backport but will wait for a
conservative
Hi Harald,
> If we do not want to break the existing ABI, so that we can
> link gfortran-13 and gfortran-14+(?) compiled code, we need
> to keep _gfortran_get_command_i4 & friends, and introduce
> new library functions that are able to handle the new
> requirements.
I have been thinking about
On 12/19/23 12:02 AM, FX Coudert wrote:
When gfortran invokes the linker, it reads the linking spec from libgfortran.
This ends up doing things like:
-lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
where you can see that libgcc (both -lgcc and -lgcc_s) is linked in twice. This
wasn’t a problem, until
Hi Julian & Thomas,
the patch LGTM - and seemingly also Thomas is somewhat fine with it -
and it includes the stand-alone testcase.
* * *
I guess, you don't know the answer to Thomas question, i.e. whether
that's a bug in CUDA or in our use of the CUDA API?
CUDA's spec itself,
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 - get_command_argument
with an optional ERRMSG.
How are we going to deal with
The subject server hosted by the OSU Open Software Lab is being upgraded
to the latest LTS version of MatterMost (8.1). There may be some
interruptions of service.
I will send out a notice when this gets completed.
Thanks to the folks at OSU for their support.
Regards,
Jerry
Hi Julian,
On 16.12.23 14:25, Julian Brown wrote:
OpenMP/OpenACC: Reorganise OMP map clause handling in gimplify.cc
This patch has been separated out from the C++ "declare mapper"
support patch. It contains just the gimplify.cc rearrangement
work, mostly moving
When gfortran invokes the linker, it reads the linking spec from libgfortran.
This ends up doing things like:
-lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
where you can see that libgcc (both -lgcc and -lgcc_s) is linked in twice. This
wasn’t a problem, until the new macOS linker, which gives a warning
14 matches
Mail list logo
