![]() |
ParaMonte Fortran 2.0.0
Parallel Monte Carlo and Machine Learning Library
See the latest version documentation. |
gfortran
version 10.3 gfortran
cannot handle regular allocation for assumed-length allocatable character types and returns the following error.gfortran
version 10.3-12, Intel Classic Fortran Compiler ifort
version 2021-2022 ifort
and GNU Fortran Compiler gfortran
share a common bug with opposing behavior.ifort
cannot handle assumed-length allocatable
output arguments of type character
.gfortran
cannot handle deferred-length allocatable
output arguments of type character
.gfortran
version 10.3-12, Intel Classic Fortran Compiler ifort
version 2021-2022 ifort
and GNU Fortran Compiler gfortran
share a common bug with opposing behavior.ifort
cannot handle assumed-length allocatable
output arguments of type character
.gfortran
cannot handle deferred-length allocatable
output arguments of type character
.ifort
version 2021.2.0, GNU Fortran Compiler gfortran
version 10-12 ifort
version 2021.2.0, GNU Fortran Compiler gfortran
version 10-12 ifx
version 2023.0.0 20221201 ifx
yields an ICE while compiling this module.ifort
can successfully compile this file.ifx
. ifort
version 2021.8.0 20221119, Intel LLVM Fortran Compiler ifx
version 2023.0.0 20221201 ifort
and Intel LLVM Fortran Compiler ifx
as of the specified versions above cannot find the minimum and maximum of a constant empty array of type character
.COL_SEQ_BEG
and COL_SEQ_END
in the module pm_str which are also needed in this module.ifort
version 2021.5 ifort
version 2021.5 ifort
version 2021.5 ifort
version 2021.5 ifort
version 2021.5 ifort
version 2021.5 ifort
version 2021.5 ifort
version 2021.5 ifort
version 2021.5 ifort
version 2021.5 gfortran
version 10-12 around line 230: Error allocating 283223642230368 bytes: Cannot allocate memory
.character
arrays of non-zero rank.allocatable
arrays of type character
are allocated with explicit shape in the allocation statement.character
types must be removed and replaced with the generic allocation once the bug is resolved.gfortran
version 10-12 around line 230: Error allocating 283223642230368 bytes: Cannot allocate memory
.character
arrays of non-zero rank.allocatable
arrays of type character
are allocated with explicit shape in the allocation statement.character
types must be removed and replaced with the generic allocation once the bug is resolved.gfortran
version 10.3-12, Intel Classic Fortran Compiler ifort
version 2021-2022 ifort
and GNU Fortran Compiler gfortran
share a common bug with opposing behavior.ifort
cannot handle assumed-length allocatable
output arguments of type character
.gfortran
cannot handle deferred-length allocatable
output arguments of type character
.
Status: Unresolved
Source: GNU Fortran Compiler gfortran
version 10.3-12
Description: GNU Fortran Compiler gfortran
currently does not accept deferred-length allocatable characters as actual argument to procedures with assumed-length allocatable dummy arguments.
Remedy (as of ParaMonte Library version 2.0.0): Avoid passing deferred-length allocatable
scalar character
arguments in the interfaces of the library until this GNU Fortran Compiler gfortran
bug is resolved.
Status: Unresolved, possibly Resolved in Intel Classic Fortran Compiler ifort
version 2023.
Source: Intel Classic Fortran Compiler ifort
version 2021.4
Description: The Intel Classic Fortran Compiler ifort
cannot compile interfaces with contiguous arguments whose lower bounds depend on the lower bounds of allocatable
input arguments.
The following is an illustration of the bug,
Status: Unresolved
Source: GNU Fortran Compiler gfortran
version 10.3
Description: There is still a bug in gfortran as of version 10.3, where the compiler fails to properly deallocate the array of origin in a call to intrinsic move_alloc
:
ifort
version 2021.2.0 ifort
version 2021.2.0 has a bug for use
ing the following two modules simultaneously in the implementation of the procedures in this module, ifort
version 2021.2.0, GNU Fortran Compiler gfortran
version 10, 11 ifort
version 2021.2.0 has a bug for the following interface definition
Status: Unresolved
Source: Intel Classic Fortran Compiler ifort
version 2021.2.0, GNU Fortran Compiler gfortran
version 10, 11
Description: The Intel Classic Fortran Compiler ifort
version 2021.2.0 has a bug for the following interface definition,
Status: Unresolved
Source: GNU Fortran Compiler gfortran
version 10, 11
Description: The GNU Fortran Compiler gfortran
cannot run examples that use procedure dummy arguments iseq()
with explicit interface, yielding the following error:
Status: Unresolved
Source: GNU Fortran Compiler gfortran
version 10-12
Description: There is an annoying gfortran bug concerning allocation of allocatable arrays of strings with assumed length type parameter.
The typical compiler error message is around line 230: Error allocating 283223642230368 bytes: Cannot allocate memory
.
This requires the allocation statement be explicit for character
arrays of non-zero rank.
This makes the already complex code superbly more complex and messy.
Remedy (as of ParaMonte Library version 2.0.0): For now, the allocatable
arrays of type character
are allocated with explicit shape in the allocation statement.
This explicit allocation for character
types must be removed and replaced with the generic allocation once the bug is resolved.
Status: Unresolved
Source: Intel Classic Fortran Compiler ifort
version 2021-2022
Description: There is an Intel compiler 2020-2022 bug in processing multiple CHECK_ASSERTION
macros in individual routines of this module in debug
compile mode.
The problem does not appear to exist in other compilation modes.
However, this bug does seem to be related to other similar instances where Intel Classic Fortran Compiler ifort
cannot tolerate frequent appearance of use
statements within a single submodule
.
Remedy (as of ParaMonte Library version 2.0.0): For now, the resolution was to remove and replace the checking macros with explicit merged block
statements.
A similar problem also was present in the implementation of pm_quadPack.
Status: Unresolved
Source: Intel Classic Fortran Compiler ifort
version 2021.5
Description: See pm_arraySplit for the description of a relevant bug in PDT name aliasing when compiled with Intel Classic Fortran Compiler ifort
version 2021.5 that also applies to this module.
Remedy (as of ParaMonte Library version 2.0.0): See pm_arraySplit for the remedy.
Status: Unresolved
Source: GNU Fortran Compiler gfortran
version 10.3
Description: The GNU Fortran Compiler gfortran
version 10.3 cannot not compile the allocation of PDT string container object temp
within the implementation of the corresponding procedures.
ifort
version 2021.5 ifort
version 2021.5 on WSL platform cannot correctly set the PDT type alias in a module use
statement generic interface can be extended to 2D input objects.ifort
version 2021.2.0, GNU Fortran Compiler gfortran
version 10-11 ifort
version 2021.2.0 has a bug for the following interface definition,ifort
version 2021.7 ifort
version 2021.7 on Microsoft WSL (and possibly other platforms) cannot properly call getRemapped(unique, ...)
when unique
is a contiguous character
array.ifort
version 2021.2.0, GNU Fortran Compiler gfortran
version 10-11 gfortran
version 10.3-11 gfortran
version 10.3-11 gfortran
version 10.3-11 gfortran
version 10.3-11 gfortran
version 10.3-11 gfortran
version 10.3-11 gfortran
version 10.3. gfortran
version 10.3-11 ifort
version 2021.4 ifort
version 2021.2 ifort
version 2021.2 yields an ICE for passing complex components to random_number()
or log()
.ifort
version 2021.4.ifort
versions on supercomputers often lags.complex
interface of the routines is now deprecated and removed.ifort
version 2021.4 ifort
version 2021.2 ifort
version 2021.2 yields an ICE for passing complex components to random_number()
or log()
.ifort
version 2021.4.ifort
versions on supercomputers often lags.complex
interface of the routines is now deprecated and removed.ifort
version 2021.8.0 20221119 ifort
cannot handle the creation of a module constant of type rngf_type as done for this object, yielding the following error.gfortran
version 10.3 gfortran
yields an internal compiler error with the expression rand = nint(temp, kind = IKG)
in pm_distUnif@routines[IK](@ref pm_kind::IK).inc.F90
file when IKG => integer_kinds(5)
on WSL OS.rand = int(0.5d0 + temp, kind = IKG)
.gfortran
version 11-13 gfortran
cannot properly construct the allocatable
scalar non-character
components of objects of type warn_type using the default constructor.unit
is set via the default constructor, the program behaves as if the unit
component of the object is allocated but unset, yielding a segmentation fault
error.gfortran
bug.
Status: Unresolved
Source: GNU Fortran Compiler gfortran
version 11-13
Description: GNU Fortran Compiler gfortran
cannot properly construct the allocatable
scalar non-character
components of objects of type mark_type using the default constructor.
For example, when unit
is set via the default constructor, the program behaves as if the unit
component of the object is allocated but unset, yielding a segmentation fault
error.
Remedy (as of ParaMonte Library version 2.0.0): For now, the custom constructor bypasses GNU Fortran Compiler gfortran
bug.
Status: Unresolved
Source: GNU Fortran Compiler gfortran
version 11-13
Description: GNU Fortran Compiler gfortran
cannot properly construct the allocatable
scalar non-character
components of objects of type warn_type using the default constructor.
For example, when unit
is set via the default constructor, the program behaves as if the unit
component of the object is allocated but unset, yielding a segmentation fault
error.
Remedy (as of ParaMonte Library version 2.0.0): For now, the custom constructor bypasses GNU Fortran Compiler gfortran
bug.
gfortran
version 11-13 gfortran
cannot properly construct the allocatable
scalar non-character
components of objects of type stop_type using the default constructor.unit
is set via the default constructor, the program behaves as if the unit
component of the object is allocated but unset, yielding a segmentation fault
error.gfortran
bug.
Status: Unresolved
Source: GNU Fortran Compiler gfortran
version 11-13
Description: GNU Fortran Compiler gfortran
cannot properly construct the allocatable
scalar non-character
components of objects of type warn_type using the default constructor.
For example, when unit
is set via the default constructor, the program behaves as if the unit
component of the object is allocated but unset, yielding a segmentation fault
error.
Remedy (as of ParaMonte Library version 2.0.0): For now, the custom constructor bypasses GNU Fortran Compiler gfortran
bug.
Status: Unresolved
Source: GNU Fortran Compiler gfortran
version 11-13
Description: GNU Fortran Compiler gfortran
cannot properly construct the allocatable
scalar non-character
components of objects of type stop_type using the default constructor.
For example, when unit
is set via the default constructor, the program behaves as if the unit
component of the object is allocated but unset, yielding a segmentation fault
error.
Remedy (as of ParaMonte Library version 2.0.0): For now, the custom constructor bypasses GNU Fortran Compiler gfortran
bug.
Status: Unresolved
Source: GNU Fortran Compiler gfortran
version 11-13
Description: GNU Fortran Compiler gfortran
cannot properly construct the allocatable
scalar non-character
components of objects of type note_type using the default constructor.
For example, when unit
is set via the default constructor, the program behaves as if the unit
component of the object is allocated but unset, yielding a segmentation fault
error.
Remedy (as of ParaMonte Library version 2.0.0): For now, the custom constructor bypasses GNU Fortran Compiler gfortran
bug.
Status: Unresolved
Source: GNU Fortran Compiler gfortran
version 11-13
Description: GNU Fortran Compiler gfortran
cannot properly construct the allocatable
scalar non-character
components of objects of type warn_type using the default constructor.
For example, when unit
is set via the default constructor, the program behaves as if the unit
component of the object is allocated but unset, yielding a segmentation fault
error.
Remedy (as of ParaMonte Library version 2.0.0): For now, the custom constructor bypasses GNU Fortran Compiler gfortran
bug.
ifx
version 2024.0.0 ifx
version 2024.0.0 memory sanitizer in debug compilation (with heap memory, serial shared library generation) reports an uninitialized heap memory allocation usage where the constructor opens the specified input file.ifort
version 2021.8.0 20221119 ifort
version 2021.8.0 20221119 cannot run the following function call within the implementation of the procedures,
Status: Unresolved
Source: Intel Classic Fortran Compiler ifort
version < 2021.10.0 20230609
Description: The Intel Classic Fortran Compiler ifort
returns a runtime error in Microsoft WSL,
Status: Unresolved
Source: GNU Fortran Compiler gfortran
version < 12
Description: The GNU Fortran Compiler gfortran
cannot compile interfaces with dummy arguments character(:), intent(out), allocatable, optional
.
This has created a redundancy for error handling in this procedure by requiring also to pass iostat
to control the occurrence of an error.
Without this bug, the allocation status of iomsg
could have been used to signal no occurrence of error.
Remedy (as of ParaMonte Library version 2.0.0): All iomsg
arguments are now assumed-length strings.
ifort
version 2021.5 ifort
version 2021.5 cannot not compile the following interface specification for the procedures, yielding "ambiguous interface" error.ifort
version 2021.8.0 20221119 ifort
version 2021.8.0 20221119 cannot run the following function call in the examples of getDecimal, gfortran
version 11.2 gfortran
version 11.2 cannot compile the following code, ifort
version 2021.8.0 20221119 ifort
thows a strange error for compiling this module when dia constant is use
d within this module.ifort
confuses this imported constant with the dummy procedure argument of the same type in procedures named getMatInitXXD_D2XX0*
or getMatInitXXD_D2XX1
.upp, low, dia
were renamed to vupp, vlow, vdia
to emphasize the value
attribute of these arguments and to resolve the Intel name-conflict bug.gfortran
version 11 gfortran
cannot handle submodule procedures with implicit procedures whose interfaces are solely declared in the parent module.gfortran
cannot recognize the procedure arguments without duplicating the full interface in the submodule.gfortran
gfortran
.gfortran
support, separate generic interfaces were instead developed for different sample weight types.gfortran
PDT bugs are resolved, the getVar generic interface can be extended to serve as a high-level wrapper for the weight-specific generic interfaces in this module.ifort
version 2021.8 pm_sampleCov@routines.inc.F90:238
.do concurrent
construct in the implementation.gfortran
gfortran
.gfortran
support, separate generic interfaces were instead developed for different sample weight types.gfortran
PDT bugs are resolved, the getVar generic interface can be extended to serve as a high-level wrapper for the weight-specific generic interfaces in this module.ifort
version 2021.11.1 Build 20231117_000000 ifort
version 2021.11.1 Build 20231117_000000. ESC should be ideally and portably defined as achar(27, kind)
, once the gfortran 11 bug is resolved.
Status: Unresolved
Source: GNU Fortran Compiler gfortran
version 10-12
Description: The character ESC
should be ideally and portably defined as achar(27, kind)
.
However, GNU Fortran Compiler gfortran
as of version 11 cannot handle this in component initializations.
Remedy (as of ParaMonte Library version 2.0.0): The character ESC
is defined a direct copy of the actual character via a preprocessor macro.
Status: Unresolved
Source: GNU Fortran Compiler gfortran
version 10.3-11
Description: The GNU Fortran Compiler gfortran
cannot handle IO of string arrays of zero-length of non-zero size in getStr()
in assertion check blocks.
The issue happens to be with deferred-length strings character(:,SKG), allocatable :: Array(:)
.
The Intel Classic Fortran Compiler ifort
can handle this properly.
Remedy (as of ParaMonte Library version 2.0.0): Avoid deferred-length strings where GNU Fortran Compiler gfortran
cannot compile.
gfortran
version 10.3-11 gfortran
cannot handle IO of string arrays of zero-length of non-zero size in getStr()
in assertion check blocks.character(:,SKG), allocatable :: Array(:)
.ifort
can handle this properly.gfortran
cannot compile.
Status: Unresolved
Source: Intel LLVM Fortran Compiler ifx
version 2024.0.0 20231017
Description: Intel LLVM Fortran Compiler ifx
This interface yields a segmentation fault error for all real
types supported when linked with the ParaMonte library built with Intel LLVM Fortran Compiler ifx
.
Remedy (as of ParaMonte Library version 2.0.0): For now, only Intel Classic Fortran Compiler ifort
will be used.
Status: Unresolved
Source: Intel Classic Fortran Compiler ifort
version 2021.11.0 20231010
Description: The runParaDRAML
interface for long double
yields a segmentation fault error.
Remedy (as of ParaMonte Library version 2.0.0): None as of today.