pgf95 6.0-4 information message overload

Hello,

I’m testing an eval version of pgf90/f95 v6.0-4 and during compilation I get bzillions of messages like so:

PGF90-I-0063-Gap in common block spccoeff_define$10 before sensor_type_name$ac (radiance.f90)
PGF90-I-0063-Gap in common block spccoeff_define$10 before polarization_type_name$ac (radiance.f90)
PGF90-I-0063-Gap in common block type_kinds$9 before fp_byte_sizes$ac (radiance.f90)
etc etc etc…

I get 1000’s of these info messages with 6.0-4, but I never got them with v5 (.0,.1, or.2). I don’t use common blocks in my f95 code so I assume these are due to an internal representation of data? Is the latest pgf95 storing data inefficiently? Is there something I can do in my code to make these info messages go away? (turning them off with a compilation switch is cheating :o)

Thanks for any info.

cheers,

paulv

Hi Paul,

What flags are you using? Informational messages should only appear if you are using the “-v” or “-Minform” flags. The message itself can apply to a module since internally pgf90 treats a module as a common block. I’m not sure why you’re seeing them with 6.0 but not 5.2. If its a concern, please drop a note to trs@pgroup.com and we can have one of our engineers take a look.

Thanks,
Mat

Hi Matt,

I do use the -Minform flag. I have no issue with info messages output, just with the sudden appearance of 1000’s of these messages with an upgrade.

What the info message, and your reply, say to me is that – in v6.0-4 – the order in which I declare parameters in a module, or components in a derived type, suffer from the same problem that poorly laid out common blocks do - misalignment of data on byte boundaries. I do not use the SEQUENCE statement in my derived type definitions so the compiler should be (?) free to rearrange those components to maximise memory usage/access efficiency. As to the same message for parameters in a module - that makes no sense.

Also, for the derived type associated info messages, all of the components are pointers to arrays that, at some point during execution, may be allocated to sizes that may satisfy any storage alignment rules. Why would an info message be issued for memory misalignment for an array pointer derived type component during compilation?

cheers,

paulv

Hi Paul,

After asking our senior compiler architect about this I have more information for you. As I noted before, internally pgf95/pgf90 treats modules as common blocks. With the 6.0 release, we have improved how the data within the complier generated common block is laid out so that is it aligned on cache boundaries. Unfortunately, this does create gaps within these common blocks and hence the informational messages. We agree that printing 1000’s of these messages is excessive and will try to remove this message when applied to compiler created common blocks in a future release.

Thanks,
Mat