Opened 19 years ago
Last modified 18 years ago
#86 closed defect
Error reported by NAG Linux compiler in ropp_1dvar_pge.f90 — at Version 2
| Reported by: | Dave Offiler | Owned by: | Dave Offiler |
|---|---|---|---|
| Priority: | normal | Milestone: | 1.2 |
| Component: | ropp_1dvar | Version: | 0.8 |
| Keywords: | NAG Linux 1DVAR PGE | Cc: | dave.offiler@…, michael.rennie@… |
Description (last modified by )
f95 -I../build -O3 -dusty -I/data/nwp1/grassaf/ropp/nag//include -c -o ropp_1dvar_pge.o `test -f '../qc/ropp_1dvar_pge.f90' || echo './'`../qc/ropp_1dvar_pge.f90 ../qc/ropp_1dvar_pge.f90: In function `ropp_1dvar_pge_1dbangle_': ../qc/ropp_1dvar_pge.f90:111: error: request for member `weights_' in something not a structure or union ../qc/ropp_1dvar_pge.f90: In function `ropp_1dvar_pge_1drefrac_': ../qc/ropp_1dvar_pge.f90:162: error: request for member `weights_' in something not a structure or union make[1]: *** [ropp_1dvar_pge.o] Error 1
Change history (2)
comment:1 by , 19 years ago
| Status: | new → assigned |
|---|
comment:2 by , 19 years ago
| Cc: | added |
|---|---|
| Description: | modified (diff) |
Note:
See TracTickets
for help on using tickets.

In ropp_1dvar_pge.f90 subroutine ropp_1dvar_pge_1dbangle (similar code exists in ropp_1dvar_pge_1drefrac):
! 2.4 Set PGE weights ! ------------------- if (config % pge_apply) then where (obs % weights > 0) obs % weights = diag % pge_weights <=== line 111/162 end where endifError is generated for NAG under RHEL4 (V5.0) and RH9 (v4.2). Optimisaiton level has no effect. NAG HP-UX also complains:
(it actually generates 3 identical messages per line; deleted here for clarity)
Changing the key lines to:
allows compilation without the error messages. However, this might not allow correct masking from the WHERE test, so probably isn't a solution.
Also,
also makes the error messages go away. So the apparant error may not be directly related to 'obs' but to 'diag'? Something related to the fact that obs%weights is a pointer? Is this NAG being overly picky, an out-and-out compiler bug or a piece of code that looks correct but is in fact is a bit dodgy to the F95 standard? [This source file compiles with no problems with ifort (v9), pgf90 & g95; gfc has an internal bug before getting this far...]