ParaMonte Fortran 2.0.0
Parallel Monte Carlo and Machine Learning Library
See the latest version documentation.
Bug List
Type pm_arrayCenter::setCentered

Status: Unresolved
Source: GNU Fortran Compiler gfortran version 10.3
Description: GNU Fortran Compiler gfortran cannot handle regular allocation for assumed-length allocatable character types and returns the following error.
Type pm_arrayCompact::getCompact

Status: Unresolved
Source: GNU Fortran Compiler gfortran version 10.3-12, Intel Classic Fortran Compiler ifort version 2021-2022
Description: Intel Classic Fortran Compiler ifort and GNU Fortran Compiler gfortran share a common bug with opposing behavior.
Intel Classic Fortran Compiler ifort cannot handle assumed-length allocatable output arguments of type character.
GNU Fortran Compiler gfortran cannot handle deferred-length allocatable output arguments of type character.

Remedy (as of ParaMonte Library version 2.0.0): For now, a preprocessor macro defines two separate interfaces for the two compilers so that both compilers can compile this file.
This minor interface difference should not impact the usage of this module with different compilers.
Type pm_arrayComplement::getComplement

Status: Unresolved
Source: GNU Fortran Compiler gfortran version 10.3-12, Intel Classic Fortran Compiler ifort version 2021-2022
Description: Intel Classic Fortran Compiler ifort and GNU Fortran Compiler gfortran share a common bug with opposing behavior.
Intel Classic Fortran Compiler ifort cannot handle assumed-length allocatable output arguments of type character.
GNU Fortran Compiler gfortran cannot handle deferred-length allocatable output arguments of type character.

Remedy (as of ParaMonte Library version 2.0.0): For now, a preprocessor macro defines two separate interfaces for the two compilers so that both compilers can compile this file.
This minor interface difference should not impact the usage of this module with different compilers.
Type pm_arrayFind::getCountLoc

Status: Unresolved
Source: Intel Classic Fortran Compiler ifort version 2021.2.0, GNU Fortran Compiler gfortran version 10-12
Description: The Intel Fortran compiler Classic 2021.2.0 has a bug for the following interface definition
Type pm_arrayFind::getLoc

Status: Unresolved
Source: Intel Classic Fortran Compiler ifort version 2021.2.0, GNU Fortran Compiler gfortran version 10-12
Description: The Intel Fortran compiler Classic 2021.2.0 has a bug for the following interface definition
Module pm_arrayInit

Status: Unresolved
Source: Intel LLVM Fortran Compiler ifx version 2023.0.0 20221201
Description: Intel LLVM Fortran Compiler ifx yields an ICE while compiling this module.
By contrast, the Intel classic Fortran compiler ifort can successfully compile this file.
The origins of the ICE remain unexplored as of today.

Remedy (as of ParaMonte Library version 2.0.0): Avoid compiling the library with Intel LLVM Fortran Compiler ifx.
Type pm_arrayMinMax::setMinMaxVal

Status: Unresolved
Source: Intel Classic Fortran Compiler ifort version 2021.8.0 20221119, Intel LLVM Fortran Compiler ifx version 2023.0.0 20221201
Description: The Intel Classic Fortran Compiler 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.
This has prevented the definition of the constants COL_SEQ_BEG and COL_SEQ_END in the module pm_str which are also needed in this module.
For example, the following code yields an Internal Compiler Error:
Type pm_arrayRank::getRankDense

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 ifort 2021.5 that also applies to this module.
Remedy (as of ParaMonte Library version 2.0.0): See pm_arraySplit for the remedy.
Type pm_arrayRank::getRankFractional

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 ifort 2021.5 that also applies to this module.
Remedy (as of ParaMonte Library version 2.0.0): See pm_arraySplit for the remedy.
Type pm_arrayRank::getRankModified

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 ifort 2021.5 that also applies to this module.
Remedy (as of ParaMonte Library version 2.0.0): See pm_arraySplit for the remedy.
Type pm_arrayRank::getRankOrdinal

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 ifort 2021.5 that also applies to this module.
Remedy (as of ParaMonte Library version 2.0.0): See pm_arraySplit for the remedy.
Type pm_arrayRank::getRankStandard

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 ifort 2021.5 that also applies to this module.
Remedy (as of ParaMonte Library version 2.0.0): See pm_arraySplit for the remedy.
Type pm_arrayRank::setRankDense

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 ifort 2021.5 that also applies to this module.
Remedy (as of ParaMonte Library version 2.0.0): See pm_arraySplit for the remedy.
Type pm_arrayRank::setRankFractional

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 ifort 2021.5 that also applies to this module.
Remedy (as of ParaMonte Library version 2.0.0): See pm_arraySplit for the remedy.
Type pm_arrayRank::setRankModified

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 ifort 2021.5 that also applies to this module.
Remedy (as of ParaMonte Library version 2.0.0): See pm_arraySplit for the remedy.
Type pm_arrayRank::setRankOrdinal

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 ifort 2021.5 that also applies to this module.
Remedy (as of ParaMonte Library version 2.0.0): See pm_arraySplit for the remedy.
Type pm_arrayRank::setRankStandard

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 ifort 2021.5 that also applies to this module.
Remedy (as of ParaMonte Library version 2.0.0): See pm_arraySplit for the remedy.
Type pm_arrayRebind::setRebound

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.
Type pm_arrayRefill::setRefilled

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.
Type pm_arrayRefine::getRefined

Status: Unresolved
Source: GNU Fortran Compiler gfortran version 10.3-12, Intel Classic Fortran Compiler ifort version 2021-2022
Description: Intel Classic Fortran Compiler ifort and GNU Fortran Compiler gfortran share a common bug with opposing behavior.
Intel Classic Fortran Compiler ifort cannot handle assumed-length allocatable output arguments of type character.
GNU Fortran Compiler gfortran cannot handle deferred-length allocatable output arguments of type character.

Remedy (as of ParaMonte Library version 2.0.0): For now, a preprocessor macro defines two separate interfaces for the two compilers so that both compilers can compile this file.
This minor interface difference should not impact the usage of this module with different compilers.
Type pm_arrayRemap::setRemapped


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:

Module pm_arrayRemove

Status: Unresolved
Source: Intel Classic Fortran Compiler ifort version 2021.2.0
Description: The Intel Classic Fortran Compiler ifort version 2021.2.0 has a bug for useing the following two modules simultaneously in the implementation of the procedures in this module,
Type pm_arrayRemove::getRemoved

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
Type pm_arrayReplace::getReplaced


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:

Type pm_arrayResize::setResized


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.

Type pm_arraySort::setSorted


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.

Type pm_arraySplit::setSplit

Status: Unresolved
Source: Intel Classic Fortran Compiler ifort version 2021.5
Description: This Intel Classic Fortran Compiler 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.
The following is a sample code demonstrating the issue,
Type pm_arrayUnique::getUnique

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,
Type pm_arrayUnique::setUnique

Status: Unresolved
Source: Intel Classic Fortran Compiler ifort version 2021.7
Description: The Intel Classic Fortran Compiler ifort version 2021.7 on Microsoft WSL (and possibly other platforms) cannot properly call getRemapped(unique, ...) when unique is a contiguous character array.

Remedy (as of ParaMonte Library version 2.0.0): For now, the remappings are done separately using the Fortran syntax to bypass the problem.
This bug cost half a day of human life to identify.
Type pm_arrayVerbose::getVerbose

Status: Unresolved
Source: Intel Classic Fortran Compiler ifort version 2021.2.0, GNU Fortran Compiler gfortran version 10-11
Description: See the bug described in getUnique.

Remedy (as of ParaMonte Library version 2.0.0): See the bug described in getUnique.
(=) Type pm_container::assignment(=)

Status: Unresolved
Source: GNU Fortran Compiler gfortran version 10.3-11
Description: The elemental implementations of the procedures under this generic interface yield incorrect results with gfortran 10.3.
Remedy (as of ParaMonte Library version 2.0.0): Currently unknown.
(/=) Type pm_container::operator(/=)

Status: Unresolved
Source: GNU Fortran Compiler gfortran version 10.3-11
Description: The elemental implementations of the procedures under this generic interface yield incorrect results with gfortran 10.3.
Remedy (as of ParaMonte Library version 2.0.0): Currently unknown.
(<) Type pm_container::operator(<)

Status: Unresolved
Source: GNU Fortran Compiler gfortran version 10.3-11
Description: The elemental implementations of the procedures under this generic interface yield incorrect results with gfortran 10.3.
Remedy (as of ParaMonte Library version 2.0.0): Currently unknown.
(<=) Type pm_container::operator(<=)

Status: Unresolved
Source: GNU Fortran Compiler gfortran version 10.3-11
Description: The elemental implementations of the procedures under this generic interface yield incorrect results with gfortran 10.3.
Remedy (as of ParaMonte Library version 2.0.0): Currently unknown.
(==) Type pm_container::operator(==)

Status: Unresolved
Source: GNU Fortran Compiler gfortran version 10.3-11
Description: The elemental implementations of the procedures under this generic interface yield incorrect results with gfortran 10.3.
Remedy (as of ParaMonte Library version 2.0.0): Currently unknown.
(>) Type pm_container::operator(>)

Status: Unresolved
Source: GNU Fortran Compiler gfortran version 10.3-11
Description: The elemental implementations of the procedures under this generic interface yield incorrect results with GNU Fortran Compiler gfortran version 10.3.
(>=) Type pm_container::operator(>=)

Status: Unresolved
Source: GNU Fortran Compiler gfortran version 10.3-11
Description: The elemental implementations of the procedures under this generic interface yield incorrect results with gfortran 10.3.
Remedy (as of ParaMonte Library version 2.0.0): Currently unknown.
Type pm_distExp::setExpRand

Status: possibly Resolved in Intel Classic Fortran Compiler ifort version 2021.4
Source: Intel Classic Fortran Compiler ifort version 2021.2
Description: The Intel Classic Fortran Compiler ifort version 2021.2 yields an ICE for passing complex components to random_number() or log().
This appears to have been fixed in Intel Classic Fortran Compiler ifort version 2021.4.

Remedy (as of ParaMonte Library version 1.5): For now, the implementations are kept separately, since the installation of the new Intel Classic Fortran Compiler ifort versions on supercomputers often lags.

Remedy (as of ParaMonte Library version Oct, 2022): The complex interface of the routines is now deprecated and removed.
Type pm_distNegExp::setNegExpRand

Status: possibly Resolved in Intel Classic Fortran Compiler ifort version 2021.4
Source: Intel Classic Fortran Compiler ifort version 2021.2
Description: The Intel Classic Fortran Compiler ifort version 2021.2 yields an ICE for passing complex components to random_number() or log().
This appears to have been fixed in Intel Classic Fortran Compiler ifort version 2021.4.

Remedy (as of ParaMonte Library version 1.5): For now, the implementations are kept separately, since the installation of the new Intel Classic Fortran Compiler ifort versions on supercomputers often lags.

Remedy (as of ParaMonte Library version Oct, 2022): The complex interface of the routines is now deprecated and removed.
Subprogram pm_distUnif::rngf

Status: Unresolved
Source: Intel Classic Fortran Compiler ifort version 2021.8.0 20221119
Description: Intel Classic Fortran Compiler ifort cannot handle the creation of a module constant of type rngf_type as done for this object, yielding the following error.
Type pm_distUnif::setUnifRand


Status: Unresolved
Source: GNU Fortran Compiler gfortran version 10.3
Description: GNU Fortran Compiler 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.

Remedy (as of ParaMonte Library version 2.0.0): For now, the expression is replaced with rand = int(0.5d0 + temp, kind = IKG).


Status: Unresolved
Source: Intel LLVM Fortran Compiler ifx version 2025.0.0 20241008
Description: Intel LLVM Fortran Compiler ifx version 2025.0.0 20241008 cannot compile the following two lines of code in the include file pm_distUnif@routines.inc.F90.

Type pm_err::mark_type

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.
Type pm_err::note_type


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.

Type pm_err::show

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.
Type pm_err::stop_type


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.

Type pm_err::warn_type


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.

Type pm_io::display_type

Status: Unresolved
Source: Intel LLVM Fortran Compiler ifx version 2024.0.0
Description: The Intel LLVM Fortran Compiler 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.
Type pm_io::getFormat

Status: Unresolved
Source: Intel Classic Fortran Compiler ifort version 2021.8.0 20221119
Description: The Intel Classic Fortran Compiler ifort version 2021.8.0 20221119 cannot run the following function call within the implementation of the procedures,
Type pm_io::openArg_type


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.

Type pm_io::show

Status: Unresolved
Source: Intel Classic Fortran Compiler ifort version 2021.5
Description: The Intel Classic Fortran Compiler ifort version 2021.5 cannot not compile the following interface specification for the procedures, yielding "ambiguous interface" error.
Type pm_mathNumSys::getNumeral

Status: Unresolved
Source: Intel Classic Fortran Compiler ifort version 2021.8.0 20221119
Description: The Intel Classic Fortran Compiler ifort version 2021.8.0 20221119 cannot run the following function call in the examples of getDecimal,
Type pm_matrixDet::getMatDet

Status: Unresolved
Source: GNU Fortran Compiler gfortran version 11.2
Description: The GNU Fortran Compiler gfortran version 11.2 cannot compile the following code,
Type pm_matrixInit::getMatInit

Status: Unresolved
Source: Intel Classic Fortran Compiler ifort version 2021.8.0 20221119
Description: Intel Classic Fortran Compiler ifort thows a strange error for compiling this module when dia constant is used within this module.
Apparently, Intel Classic Fortran Compiler ifort confuses this imported constant with the dummy procedure argument of the same type in procedures named getMatInitXXD_D2XX0* or getMatInitXXD_D2XX1.

Remedy (as of ParaMonte Library version 2.0.0): There does not appear to exist any way to resolve this intel error currently, other than not importing the constant dia in this module.
Instead, one has to use dia_type() to call the procedures when resolving the generic interface.
As such, the argument names 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.
Type pm_quadTest::test_isFailedQuad

Status: Unresolved
Source: GNU Fortran Compiler gfortran version 11
Description: The GNU Fortran Compiler gfortran cannot handle submodule procedures with implicit procedures whose interfaces are solely declared in the parent module.
The GNU Fortran Compiler gfortran cannot recognize the procedure arguments without duplicating the full interface in the submodule.
For example, gfortran fails to compile the following submodule procedure interface,
For example, gfortran returns the following error code,
Module pm_sampleCov

Status: See Unresolved, See this page for more information.

Source: GNU Fortran Compiler gfortran
Description: Ideally, there should be only one generic interface in this module for computing the biased/corrected/weighted variance.
This requires ability to resolve the different weight types, which requires custom derived types for weights.
Fortran PDTs are ideal for such use cases. However, the implementation of PDTs is far from complete in GNU Fortran Compiler gfortran.

Remedy (as of ParaMonte Library version 2.0.0): Given that the importance of GNU Fortran Compiler gfortran support, separate generic interfaces were instead developed for different sample weight types.
Once the GNU Fortran Compiler 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.
Type pm_sampleCov::getCov

Status: Unresolved
Source: Intel Classic Fortran Compiler ifort version 2021.8
Description: Intel ifort (possibly only with heap memory allocation) yields a segfault error in OpenMP parallel code at pm_sampleCov@routines.inc.F90:238.
The root cause of the segmentation fault was determined to be due to the use of do concurrent construct in the implementation.

Remedy (as of ParaMonte Library version 2.0.0): For now, all do concurrent statements are converted back to normal do loops.
Module pm_sampleVar

Status: See Unresolved, See this page for more information.

Source: GNU Fortran Compiler gfortran
Description: Ideally, there should be only one generic interface in this module for computing the biased/corrected/weighted variance.
This requires ability to resolve the different weight types, which requires custom derived types for weights.
Fortran PDTs are ideal for such use cases. However, the implementation of PDTs is far from complete in GNU Fortran Compiler gfortran.

Remedy (as of ParaMonte Library version 2.0.0): Given that the importance of GNU Fortran Compiler gfortran support, separate generic interfaces were instead developed for different sample weight types.
Once the GNU Fortran Compiler 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.
Type pm_sampling::getErrSampling

Status: Unresolved
Source: Intel LLVM Fortran Compiler ifx version 2024.0.2 20231213
Description: Intel LLVM Fortran Compiler ifx cannot handle compilation of the pm_sampling implementation include file.
Type pm_str::isEndedWith

Status: Unresolved
Source: Intel Classic Fortran Compiler ifort version 2021.11.1 Build 20231117_000000
Description: The following example fails on Windows and Linux with Intel Classic Fortran Compiler ifort version 2021.11.1 Build 20231117_000000.
Module pm_strANSI

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.

Type pm_sysInfo::getSysInfo

Status: Unresolved
Source: Intel LLVM Fortran Compiler ifx version 2025.0.0 20241008
Description: Intel LLVM Fortran Compiler ifx version 2025.0.0 20241008 yields the following segfault error at runtime for using the css_type array constructor syntax.
deallocate the array of origin in a call to intrinsic move_alloc:
Type pm_val2str::getStr


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.

Type pm_val2str::setStr

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.
Module runParaDRAM


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.