If a procedure argument is of a derived type with allocatable components, and the argument is intent(out) and

optional, then calling the procedure with this argument absent produces a segmentation fault.

XLF considers size-zero variables to be initially undefined, and disallows returning them as function results unless they

are assigned.

• This causes compilation to fail when using "-qhalt=e" (or CMake; for some reason, CMake seems to add this
  itself?).
• While normally it is indeed an error for code to return an uninitialized variable, for a size-zero variable there is
  usually no requirement by the standard, and assignment to such a variable does nothing.

A where statement is vectorized by executing both branches and merging the result according to the mask. Therefore,

you cannot rely on the mask to filter out operations that result in out-of-bounds accesses, uses of uninitialized data, or

floating point exceptions.

If a routine uses an intrinsic function, and then is renamed (via use association) to have the same name as that

intrinsic, there's an internal error.

Workarounds:

1. Avoid reusing a name that belongs to an intrinsic procedure, except when wrapping that procedure for
   compatibility.
2. Wrap the function in a generic interface, even if there is only one version.

• Forum post: https://software.intel.com/en-us/forums/topic/532181

If a dummy argument has the "contiguous" attribute, and the actual argument passed is not contiguous, the data is

properly packed into a temporary, but the compiler incorrectly frees the temporary, resulting in a run-time crash.

• https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56789

The intrinsics "erf" and "erfc" are actually external functions that are automatically linked in, rather than intrinsics. This

distinction matters mostly because it means that they are not generic and do not have an explicit interface. If you use

"erf" for a double precision variable, rather than "derf", you can silently get the wrong version.

• Workaround: always use shr_spfn_erf and shr_spfn_erfc; this is necessary anyway in order to compile with NAG
  versions that lack these functions entirely.

write statements in OpenMP threaded regions to a file opened with the "newunit" specifier can hang

(even if the opening of the file is done outside of a threaded region)

See https://github.com/ESCOMP/CTSM/issues/1331 for details

Specific intrinsics, such as "sin" and "dcos", do not have the "pure" attribute even if the generic intrinsic is pure. The

Fortran standard does not specify this behavior, and in any case, the standards committee is considering deprecating

the specific intrinsics in 2015.

GNU

Instead of a dedicated fpp, GNU uses a "traditional" C preprocessor (i.e. one with behavior similar to preprocessors

that existed before the standards of the 90's). Some implications:

• Unlike with other Fortran preprocessors, "&" is not recognized as a line continuation character. Unfortunately, this
  means that there is no portable way to do line continuation within a function macro.
• Other Fortran-isms (e.g. ".lt." as a synonym for "<") are not portable.
• It may be difficult to predict how special characters will be treated within macros.
• It takes finesse to do token concatenation.

14.01.0000.0007

Probably stack size

issue, not a bug.

13.0.1 - 14.0.2

Fixed in version 15.

Not present in Intel 12

Optimization issue causes the compiler to produce wrong code for certain loops.

• Workaround: Compile with reduced optimization (no higher than "-O"), or reorder loops to avoid the bug.
• Affected CAM-FV when using compiler version 14 or later.
• Reproducer for the bug.

13-15.0.2

(Regression from 12)

Reported via CISL by

Jim Edwards.

Intel reports a fix in

version 15.0.3

In some cases with OpenMP and optimization enabled, setting an entire array to a scalar value can fail, e.g. the last

row in the array is not properly set.

<=15.0.0

Appears fixed in

15.0.1

There are some bugs having to do with deallocating a length zero pointer, which show up if using nagfor's memory

tracing features or OpenMP.

<= 5.3.1

NAG believes this to

be fixed in 6.0

One or more bugs related to the location of use statements. The compiler may emit spurious errors about undefined

variables unless you move use statements around (from module to procedure level, or vice versa).

• These errors are hard to predict, but as a rule of thumb, try to order use statements in a module such that lower
  level modules precede higher level ones.
• Report: http://www.pgroup.com/userforum/viewtopic.php?p=16742#16742
• PGI TPR is #20566.

<= 14.1

Fixed in 14.7

If a module has the "private" attribute, and it uses a generic interface block to define a specific interface with the same

name as the generic, some uses may be unable to resolve the procedure reference.

• Report: http://www.pgroup.com/userforum/viewtopic.php?p=16742#16742
• PGI TPR is #20565.

<= 14.1

Fixed in 14.7

Pointers are sometimes modified when they shouldn't be?

• This is a placeholder for a bug that is not very well understood yet.
• Detected with a certain version of CAM's tracer_data.F90
• Code in question involves a pointer component that should never be modified (passed as intent(in) to a function
  and otherwise unused), a type with several pointers that are allocated and deallocated by functions that are called,
  and a bare pointer used as input. Somehow the first pointer is being changed to point to the last, even though
  they appear in no statements together. This occurs some time during the first two loop iterations.
• Sole known instance of this bug goes away if you add print statements in certain locations, and has not been
  reproduced with a reduced test case.

<= 14.9

tracer_data case was

fixed in 14.10

Pointer array components of a derived type seem to randomly be resized to 0 when they are passed into a

subroutine. As in: call foo(some_vars%bar(bounds%begc:bounds%endc, :)). Within foo, the corresponding dummy

argument then appears to be size 0. A number of incarnations of this problem has been observed in CLM4.5 after the

big refactor in r081.

Initial problems were seen with pgi 13.9, when using the mpi-serial library. However, this was later observed without

mpi-serial. Sometimes the problem only occurs when building threaded. Basically, it seems that any seemingly minor

change to the build can push the compiler into a situation where this problem occurs in seemingly-random places. 

A similar problem was observed with a subroutine argument (an assumed-shape array), which was passed on to

another subroutine. The actual argument was a pointer component of a derived type (a filter in CLM).  

A similar problem was observed in CLM when the actual argument was obtained from a function call, as in:

call foo(..., cnveg_inst%get_some_var(...)).

Workarounds:

• Often it works to either insert a print statement before the subroutine call (e.g., writing the ubound of the offending
  variable before making the subroutine call), or assigning the ubound of the offending variable to a temporary, as in:
  dummy_to_make_pgi_happy = ubound(somearr, 1). 
•  In one case (UpdateAccVars in CLM's CNDVType.F90), the standard workaround (printing or assigning the
  ubound of the offending array) did not work. In this case, the workaround that worked was to declare the dummy
  argument as a pointer (note that the actual argument was already a pointer).
• For the case where the actual argument was obtained from a function call, the workaround was to assign
  the result of the function call to a temporary variable, as in:
  some_var(:) = cnveg_inst%get_some_var(...)
  call foo(..., some_var)

Note that using pgi 14.10 allows some of the previously-failing CLM tests to pass, but also causes failures in new

places (e.g., ERS_D_Lm20.1x1_smallvilleIA.ICLM45BGCCROP.yellowstone_pgi now fails on line 278 of

SoilBiogeochemNitrogenStateType.F90,  which is an assert on the size of the decomp_cpools_col argument).

 <= 14.10

Reported to PGI.

No clear reproducer

now in 15.1?

Also observed in 15.10

reported fixed in 16.5

Some installations of PGI seem to have excessive stack usage when run on certain files, triggering an internal

compiler error. The only known workaround is to attempt to isolate sections of the code that cause the problem, and

make pointless changes until it consistently compiles (almost pure trial-and-error). Luckily this bug seems rare.

<= 13.7

No longer

reproducable.

Assumed fixed.

Internal compiler error when compiling CLM.

• Exact cause is uncertain, but this may represent a problem with the .mod files produced for certain modules, e.g.
  TemperatureType.

>= 14.1

Fixed in 14.10

The IEEE intrinsic modules are not implemented.

• Ticket here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29383

<=4.9

Fixed in 5.1

Various.

Most fixed by 4.8

Problems accessing allocatable arrays within a polymorphic array.

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58043

Workaround: if possible, declare the offending variable using 'type' rather than 'class'

<= 4.9.

Bug report filed

Import statement does not work properly with entities renamed via use statement. Workaround is to use an

unqualified import statement.

4.6 - 4.7 only.

Fixed in 4.8

Polymorphic pointers may lose information about their subclass in certain situations, preventing this information from

being discoverable through "select type" (i.e. run-time type identification). This is extremely unpredictable.

Here is an example where introducing an extra pointer copy loses information about the dynamic type.

Workarounds:

• Avoid using run-time type identification (preferred, as it is rarely necessary).
• Implement your own run-time type identification (e.g. by providing methods to query dynamic type).
• Rearrange code and add select type constructs until the code works (i.e. pure trial and error).

<=XLF 14.1.0000.0006

Turned out to be an

error due to wrong

intent in the test case.

Internal compiler error when assigning the output of the "eoshift" intrinsic directly to an allocatable array. This only

applies when using xlf2003. Workaround is to replace the array on the left side with a section of itself.

• E.g. replace foo = eoshift(...) with foo(:) = eoshift(...)


XLF 14.1.0000.0004

Fixed in XLF

14.1.0000.0006

(In practice, this is the

2013-11 build on Mira.)

Code involving procedure pointers can sometimes jump to a bad location, leading to illegal instruction errors.

• This error was never isolated well enough to report, but the case that triggered it no longer does so on recent
  versions of the compiler on Mira, suggesting that it was fixed by an update.

XLF 14.1.0000.0006

Tentatively seems fixed

in 14.1.0000.0009

Valid uses of user-defined constructors are rejected by the compiler, if they are called on the outputs of functions

(i.e. on "rvalues").

• This occurs regardless of what the contents of the type are. Any function will experience this bug if it is called using
  a generic name that's the same as the name of a type.

<= 13.0.1

Fixed in 13.1.2

Internal compiler error when assigning the output of the "merge" intrinsic to an allocatable array, if the option

"-assume realloc_lhs" is passed to the compiler. (This option is necessary for full Fortran 2003 support.)

• In Intel 12, this bug seems to be triggered by all assignments from "merge".
• In Intel 13, this bug seems to be triggered only by assignments where some of the arguments to "merge" are
  scalars.

Workarounds:

• Replace array on the left hand side with a section (see the "eoshift" bug for IBM).
• Replace the line containing the "merge" call with a "where" construct, or a loop surrounding an "if" construct.

<=13.1.2

Fixed in 14.0.1

<=13.1.2

Fixed in 14.0.1

Internal compiler error when using a structure constructor inside a user-defined constructor, in certain conditions.

• For instance, say you have a type called "foo" that only contains an integer array. Then the following code does
  not compile:
  • type(foo) function new_foo(b, c)
        integer :: b(:), c(:)
        new_foo = foo(b + c)
    end function new_foo
• Report: http://software.intel.com/en-us/forums/topic/508943

<=14.0.2

Fixed in version 15.

Intel

PGI

Internal compiler error when using a structure constructor to produce a type with a procedure pointer.

• For Intel, applies only if the pointer is to a function (not subroutine), and only to calls in the same module as where
  the type is defined.
• For PGI, a spurious warning for functions, an internal compiler error for subroutines.
• Intel report: http://software.intel.com/en-us/forums/topic/508945
• PGI report (see numbers 4 and 5): http://www.pgroup.com/userforum/viewtopic.php?t=4273

<=15.0.0 (Intel)

14.1 (PGI)

Reported through

Intel and PGI forums.

PGI fixed in 14.7

Intel fixed in 15.0.1

Intel

PGI

Spurious error when using a structure constructor directly on an array section (or the output of some intrinsics). For

PGI, this is only a warning.

• Applies only when the type being constructed is an extension of some other type.
• Assuming that the type is foo, with a 1D integer array component, a1 is a 1D array, and a2 is 2D:
  
  • This is OK: b = foo(a1)
  • This is OK: b = foo(a2(:,1) + 0)
  • This triggers the error: b = foo(a2(:,1))
  • This triggers a similar error on Intel: b = foo(spread(1, 1, 5))
• Intel report: http://software.intel.com/en-us/forums/topic/508951
• PGI report (see number 3): http://www.pgroup.com/userforum/viewtopic.php?t=4273

14.0.2 (Intel)

14.1 (PGI)

PGI fixed in 14.7

Intel fixed in 15.0.0

Stack corruption when allocating a polymorphic variable under certain specific circumstances.

• This seems to be related to pointers to functions that return a certain kind of derived type.
• For details see the report: http://software.intel.com/en-us/forums/topic/508990

<=14.0.2

Fixed in 15.0.0

Internal compiler error when calling a generic procedure on a component of a derived type, under some conditions.

i.e., if bar_type contains a generic procedure do_stuff, then this could cause an internal compiler error:

call foo%bar%do_stuff

I haven't determined the exact conditions when this problem occurs and doesn't occur.

Workaround: call the specific version of the procedure rather than using the generic.

<= 13.1.2.

Fixed in 14.0.2

Internal compiler error when assigning the output of max/min to an entire allocatable array, if one of the arguments of

max or min is a scalar.

• This bug occurs only when the compiler flag "-assume realloc_lhs" is set, but CESM does set this.
• A workaround is to make the left-hand side an array section, i.e. "foo(:) = max(bar, 2)". The "(:)" doesn't do
  anything, except to work around the bug.

<=13.0.1

Fixed in 13.1.2

Internal compiler error when using a structure constructor to create any extended type, if the base types are not in

scope.

• The simplest workaround is to make sure that all base types are in scope where the constructor is called.

Intel 13 only.

Fixed in Intel 14.

Intel 12 did not have

this issue.

Segmentation fault when doing intrinsic assignment on a derived type variable, which has a component that is a

derived type with defined assignment.

• Bug report: https://software.intel.com/en-us/forums/topic/532429

<=15.0.0

Reported to Intel via

forums. Fixed in Intel 16.

And fixed in Intel 15 version

from Oct/2014.

Error when using pointer bounds remapping to set a pointer component of a derived type. Workaround is to remap to

a temporary pointer, then set the pointer component from the temporary.

<=5.3.1

Fixed in 6.0

If you have a function without a result clause, and you reference the name of the output variable in an associate

construct, the name is erroneously treated as referring to the function itself rather than the output variable.

<=5.3.1

Fixed in 6.0

NAG seems to be the last compiler to implement namelist I/O for allocatable/pointer arrays.

<=5.3.1

Implemented in 6.0

Internal compiler error when calling a generic type-bound function inside an implied do loop.

• Code to reproduce the error.

<=6.0 (edit 1017)

Fixed in edit 1019

<=13.7

Fixed in 13.9.

Cannot create a literal empty array (syntax in Fortran 2003 is [integer::]). Workaround is to define a function that

returns an empty array of the desired type.

<=13.7

Fixed in 13.9

Compile-time errors when using a structure constructor for a derived type with default initialization.

• Normally, code is erroneously rejected with a message about missing constructor arguments.
• If a structure constructor has no arguments, the error message is instead about an empty type.

<=11.5

Fixed in 12.5

<=12.5

Fixed in 12.10

<=12.10

Fixed in 13.3

Scope of type-bound procedures is not handled correctly, causing clashes between method names and names in

module scope.

• This bug seems to have multiple incarnations.
• Report for 14.3: http://www.pgroup.com/userforum/viewtopic.php?t=4285

<=14.3

Fixed in 14.7

When using intrinsic assignment to copy an object with an allocated polymorphic component, dynamic type

information is lost.

<=13.9

Fixed in 13.10

The compiler erroneously rejects code that attempts to allocate non-polymorphic variables of derived type, when the

type has no components. The message complains that the type is empty, but Fortran allows this.

Workarounds:

• Make the variable polymorphic (class(foo) instead of type(foo)). However, this causes a problem if you use
  a structure constructor with "source=". Example: "allocate(bar, source=foo())"
• Add a meaningless, unused component to the type definition.
• Report: http://www.pgroup.com/userforum/viewtopic.php?p=16683#16683

<=13.10

Fixed in 14.7

Intrinsic assignment sometimes fails to work properly for variables of derived type, when the derived type contains

a pointer component and an allocatable component. In this case, the variable on the left-hand side of the assignment

ends up with uninitialized values for all of its components (even simple scalar components).

Workarounds:

• Change the allocatable derived type component to a pointer - this is probably the easiest workaround
• It sometimes works to rearrange the order of the derived type components in the derived type declaration
• Otherwise, it seems to work to define your own assignment operator for objects of that derived type

<=13.9

PGI claims a fix in 14.2

PGI encounters an internal error sometimes, when programs use types with type-bound operators (e.g. operator (+))

from a module.

• This seems to have something to do with creating unnamed temporary objects.
• Typical error messages include "mkexpr1: bad id" and "sym_of_ast: unexpected ast".
• Report: http://www.pgroup.com/userforum/viewtopic.php?t=4219

<=14.1

Fixed in 14.7

PGI does not yet support using the "associate" statement on expressions (rvalues) of arrays. Array elements are

usually fine, but other expressions (e.g. those involving arithmetic) do not seem to work yet.

• TPR FS#20727

<=14.7, and ==15.1

Fixed in 14.9

Broken again in 15.1

Fixed again in 15.4

<=13.9

Fixed as of 14.1

PGI has an internal "Lowering Error" for some code that uses intrinsics to set array sizes/bounds.

• This is triggered by using "size" on an argument to define the size of a function's result, for a function in an
  interface block, which is then used to specify the interface of a deferred binding.
• A similar bug involving the use of "-i8" was fixed in 14.3.
• Report (see first issue): http://www.pgroup.com/userforum/viewtopic.php?p=16706#16706
  

<=14.3

Fixed in 14.7

PGI has an internal compiler error if you forget the "nopass" attribute on a procedure pointer/binding.

• In this case, the code is invalid anyway.
• Report (see number 1): http://www.pgroup.com/userforum/viewtopic.php?t=4273

14.1

Fixed in 14.7

PGI rejects valid code that uses a structure constructor for a polymorphic type that inherits a procedure binding.

• Report (see number 2): http://www.pgroup.com/userforum/viewtopic.php?t=4273

14.1

Fixed in 14.7

Calling a function from a function pointer bound to a type, when the pointer is default-initialized to null(), causes an

internal compiler error.

• Report (see number 4): http://www.pgroup.com/userforum/viewtopic.php?t=4273

14.1

Fixed in 14.7

PGI has an internal compiler error if you import a type into an interface earlier in the file than you define the type.

• In this case the code is invalid anyway for a compiler that does not look ahead for type definitions (e.g. NAG
  rejects it).
• Report (see number 6): http://www.pgroup.com/userforum/viewtopic.php?p=16675#16675

14.1

Fixed in 14.3

PGI does not accept "select type" for distinguishing a type with a name that starts with "record".

• Report (see number 7): http://www.pgroup.com/userforum/viewtopic.php?p=16676#16676

14.1

Fixed in 14.7

PGI does not accept a generic binding on a type that aliases only one specific procedure, if that procedure is

deferred, if the module does not have a "contains" in it.

• Report (see number 8): http://www.pgroup.com/userforum/viewtopic.php?p=16678#16678

14.1

Fixed in 14.7

PGI produces code with a linking error, if compiling a type that has a polymorphic component of one of its own

classes, and does certain things with that type, in a module with a save statement.

• Report (see number 9): http://www.pgroup.com/userforum/viewtopic.php?p=16678#16678

14.1

Fixed in 14.7

The compiler does not recognize that two procedures have compatible interfaces, if one is defined in an interface

block and the other is a module procedure, if the procedures accept a procedure with an explicit interface.

• Only triggers when "procedure(interface_name)" is used, not with an interface block local to the procedure.
• Report (see second issue): http://www.pgroup.com/userforum/viewtopic.php?p=16706#16706

14.1

Fixed in 14.7

Overridden methods are broken (at least for types with multiple methods).

• If you override more than one method of a type, and call the method, at run-time you end up entering the wrong
  procedure.
• Original report from the forums: http://www.pgroup.com/userforum/viewtopic.php?t=3883

<=13.6

Fixed in 13.7.

pgfortran rejects apparently valid code by saying that it cannot invoke an abstract interface, giving the name of a type-

bound procedure that has been overridden with a concrete implementation and which is not actually being called in

the given location. It is not clear what triggers this behavior.

• Reproducer is pFUnit 3.

13.9-14.10

pFUnit builds in 15.1

pgfortran rejects apparently valid code by saying that a particular type-bound procedure has not been explicitly

declared, despite the fact that (1) the type-bound procedure is declared in the given derived type, and (2) that

type-bound procedure is not actually being called in the file that generates the error. In the one observed instance,

the file giving the error referenced many types that all had the same names for type-bound procedures (e.g., Init).

• A workaround was to rename these methods in the newly-introduced type (e.g., rename Init to IrrigationInit in
  that type).
• TPR FS#21165

<= 14.10

Fixed in 15.1

Case where method calls could only be resolved if the methods had not been renamed to something different from

the original procedure's name.

• TPR FS#21166

<=14.10

Fixed in version 15

(official release will be

15.1)

pgfortran encounters a segfault when compiling CLM's filterMod, if the flag "-Mallocatable=03" is given (needed for full

Fortran 2003 compliance).

• This has been reproduced with a smaller case involving two stubs and a slightly modified version of clmtype.F90.
• This probably has something to do with the large number of derived type pointer components in clmtype, since
  removing enough of these types (regardless of which ones?) will get rid of the bug.
• TPR FS#20758

<=14.7

Fixed in 14.9

pgfortran 14.7 has an internal compiler error when compiling the file in the attached tarball.

• Based on the line number cited, this seems to have something to do with using move_alloc to transfer an
  allocatable component from one object to another.
• TPR FS#20796
• The tarball.

<=14.7

Fixed in 14.9

pgfortran 14 fails to look recursively through subobjects of a derived type object when doing automatic deallocation.

• Reproducer (run with valgrind to see unfreed memory)
• TPR FS#21079

<=14.10

Fixed in 15.1

pgfortran 14 internal compiler error with "-Mallocatable=03" and allocatable components of allocatable components.

• Reproducer (only has error with -Mallocatable=03)
• TPR FS#21080

<=14.10

Fixed in 15.1

pgfortran 14 gives a warning if you set the values pointed to by pointer components of intent(in) values, even though

the Fortran standard allows this.

• Reproducer (compile with -c)
• TPR FS#21081

<=14.10

Fixed in 15.1

pgfortran 14 loses information about variables declared in the child class of a polymorphic entity allocated with

"source=".
i.e., if you have something with this pattern:
type, abstract :: foo_base_type
integer, allocatable :: barvar1(:)
end type

type, extends(foo_base_type) :: foo_concrete_type
integer, allocatable :: barvar2(:)
end type

class(foo_base_type) :: my_foo

Then, if the dynamic type of my_foo is foo_concrete_type, my_foo%barvar2 will sometimes get resized to 0, although
my_foo%barvar1 is fine.

This can be reproduced with:

PET_P15x2_Ly3.f10_f10.ICLM45BGCCROP.yellowstone_pgi.clm-irrig_o3_reduceOutput

run on this tag, although the problem is not actually threading-related.

• Reproducer is test_poly_pointers.F90 from this tarball.
• TPR FS#21130

 <=14.10

Fixed in 15.1

When not all allocatable fields are allocated in the parent class of a polymorphic entity allocated with "source=", the

allocation may cause a segfault.

• Reproducer is dumps_core_when_run.F90 from this tarball.

<=14.10.

Fixed in PGI 15; the

official release will be

15.1

pgfortran 14 sometimes has trouble with sourced allocation of a polymorphic entity.

For example, in this tag many tests, such as

ERS_D.f10_f10.ICLM45.yellowstone_pgi.clm-reduceOutput

die at runtime in the sourced allocation of ozone_inst, line 287 of models/lnd/clm/src/main/clm_instMod.F90:

allocate(ozone_inst, source = create_and_init_ozone_type(bounds))

That allocate line works fine if creating an instance of ozone_type, but NOT if creating an instance of ozone_off_type.

The same allocate statement works fine in the n09 tag, where the difference is that n09 has some variables declared

in ozone_type rather than in ozone_base_type.

• A reduced test case is test_alloc_child in this tarball.

 <= 14.10

Fixed in PGI 15; the

official release will be

15.1

pgfortran 15 hangs after a compile time glibc error.

• Reproducer is pgi_glibc_error.F90 in this tarball.
• TPR FS#21129.

<= 14.10

Fixed in 15.1

When building CLM code with mpi-serial, using pgi14.7, Bill Sacks encountered the error:

PGF90-F-0000-Internal compiler error. normalize_forall_array: non-conformable   37663
(/glade/p/work/sacks/cesm_code/clm_modular_irrigation/models/lnd/clm/src/main/clm_initializeMod.F90: 723)

PGF90/x86-64 Linux 14.7-0: compilation aborted

This was with this tag e.g., for ERS_Lm3.1x1_smallvilleIA.ICLM45BGCCROP.yellowstone_pgi
A workaround was to print the size of the array arguments just before the subroutine call on line 723. 

• The "normalize_forall_array: non-conformable" internal compiler error also occurs using this tag, e.g., for
  PET_P15x2_Lm13.f10_f10.IHISTCLM45BGC.yellowstone_pgi.clm-reduceOutput In this case, the problem
  appeared in clm_driver, in the call to CalcIrrigationNeeded.
  The workaround in this case was to declare a new subroutine local variable - an allocatable array.
  (see r65797 on the branch https://svn-ccsm-models.cgd.ucar.edu/clm2/branches/ozone_polymorphism )

<= 14.10

Fixed in 15.1? No

known case triggers it

anymore.

Regression in early access version 15.0 of PGI. This should not be necessary to work around because it will probably

be fixed by the release. The issue is that association to expressions of the form "bar%x(:)" will not work if "bar%x is an

allocatable array.

• TPR FS#21192

15.0 only

pgfortran 14 and 15 give internal compiler errors when setting an allocatable character variable equal to an expression

that involves a function result.

For example:

character(len=:), allocatable :: mystring

mystring = 'hello' // two_char_string()

results in:

PGF90-S-0000-Internal compiler error. string_expr_length: ast not string op      13

Workaround: introduce an intermediate variable, as in:

character(len=:), allocatable :: temp_string
character(len=:), allocatable :: mystring

temp_string = two_char_string()
mystring = 'hello' // temp_string

Reproducer is test_allocatable_char_broken.F90 in pgi_allocatable_char.tar

 <= 15.4

Fixed in 15.7

POSSIBLE BUG: Allocatable character components of derived types sometimes get filled with garbage?

This showed up in a few yellowstone-pgi tests (using pgi 15.10) in

https://svn-ccsm-models.cgd.ucar.edu/clm2/branch_tags/product_pools_gridcell2_tags/

 product_pools_gridcell2_n02_clm4_5_8_r172

and was fixed in tag product_pools_gridcell2_n03_clm4_5_8_r172

by changing allocatable character variables to fixed-length.

Specifically, this is in SpeciesIsotopeType and SpeciesNonIsotopeType. In the n02 tag, I got failures like:

I'm not positive that this is a compiler bug - it might have been programmer error. I'm filing it here to keep an

eye on it.

 <= 15.10

May have been

programmer error

rather than a compiler

bug

reported fixed in 16.5

Adding an interface to subroutines in seq_infodata_mod.F90 caused a compiler error:

*** glibc detected *** /glade/u/ssg/ys/opt/pgi/15.10/

linux86-64/15.10/bin/pgf901: free(): invalid next size (fast): 0x000000000242fb00 ***
 recipe for target 'seq_infodata_mod.o' failed gmake: *** [seq_infodata_mod.o] Error 127

The issue was caused by adding a new interface to seq_infodata_GetData and seq_infodata_PutData. The code

which triggered the PGI compiler error is in the current version of cime/driver_cpl/shr/seq_infodata_mod.F90 in

sections set off by #ifndef CPRPGI.

 15.10 although it

seems to also be in

other versions.

reported fixed in 16.5

PGI

Cray

Operators in IEEE_ARITHMETIC are not always elemental/pure when they should be.

• For PGI, the operators can be used on scalars, with a spurious warning for pure procedures.
• For Cray, using the operators in a pure procedure causes an error

<=13.7 (PGI)

Fixed in 13.9 (PGI)

Fixed in an unknown

version for Cray.

GNU

Finalization is not supported by gfortran yet.

<=4.8

4.9 has preliminary

support (at least code

with finalization should

compile).

(Fortran 2008)

Multidimensional pointer bounds remapping can be confused by lower bounds of an array that are lower than 1.

• TPR 19660

<=13.10

Fixed in 14.1

(Fortran 2008)

The compiler claims that the "contiguous" attribute is incompatible with "intent", and rejects valid code in which

dummy arguments have both.

• Workaround: put "intent" before "contiguous".
• Report: http://www.pgroup.com/userforum/viewtopic.php?t=4406

<=14.1

Fixed in 14.7

(Extensions and the preprocessor)

Bugs involving the preprocessor and line length limits. NAG's fpp guarantees that if the input file obeys the 132

character limit, then so will the output file. However, there have been a few bugs that result in:

• Two lines being merged together when the first one contains blank characters that exceed the 132 character limit.
• Line continuation characters ("&") being inserted in inappropriate locations in lines.

<=5.3.1

Fixed in 6.0

(Extensions and the preprocessor)

Bugs involving function macros given no arguments. If you define a function macro, then refer to the name of that

macro without providing arguments (e.g. in comments about the macro), the preprocessor may produce odd output,

such as files that are incomplete, or an infinite number of control characters.

Workarounds:

• Always give a function macro the right number of arguments, even in comments.
• Use "-Wp,-macro=no_com" to turn off macro expansion in comments.

<=6.0 (edit 1017)

Report filed w/ NAG

support. Nag reports

a fix in edit 1032.