forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

EQUIVALENCE compiler issue

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
wahorger



Joined: 13 Oct 2014
Posts: 1217
Location: Morrison, CO, USA

PostPosted: Sun Dec 18, 2016 2:49 pm    Post subject: EQUIVALENCE compiler issue Reply with quote

I make use of equivalence rarely, usually to work around some issue with data typing, or trying to use a logical for a %rb. The code snippet below compiles perfectly, but the execution shows that the EQUIVALENCE is not in force.

Code:
   logical   record_function_enabled,playback_function_enabled
   integer record_fileunit,playback_fileunit
   equivalence (record_function_enabled,  record_fileunit),(playback_function_enabled,  playback_fileunit)
   common/record_playback_common/record_function_enabled,playback_function_enabled,record_fileunit,playback_fileunit
   print *,loc(record_function_enabled),loc(record_fileunit)
    end

The LOC of these two variables should be the same, but they are not.
Back to top
View user's profile Send private message Visit poster's website
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Sun Dec 18, 2016 3:24 pm    Post subject: Reply with quote

The problem is with your COMMON, but the compiler does not give you a good diagnostic message about it.

You are not allowed to specify any member of a common block more than once in the list of items to be placed in common. Because of the equivalence, you are doing this forbidden thing.

Replace the common block declaration by, say,
Code:
common/record_playback_common/record_function_enabled,playback_function_enabled

and your errors should be resolved.

Note, however, that according to the Fortran standard when you place two different types (logical and integer, for example) in an equivalence pair, defining one of the pair makes the other undefined. The wording in the standard:
Quote:
16.5.6 Events that cause variables to become undefined
45 Variables become undefined as follows:
46 (1) When a variable of a given type becomes defined, all associated variables of different type
47 become undefined.

Few compilers, unless asked to do so, will actually make this "undefinition" happen, but do note that you are taking a risk by relying on the compiler's turning a blind eye on this.
Back to top
View user's profile Send private message
wahorger



Joined: 13 Oct 2014
Posts: 1217
Location: Morrison, CO, USA

PostPosted: Sun Dec 18, 2016 4:30 pm    Post subject: Reply with quote

Fully aware that what I did was not allowed. Occasionally, one does make an error, especially when developing new code, yes?

I expected an error message, either at the EQUIVALENCE or at the COMMON declarations. Got neither, needed reporting.
Back to top
View user's profile Send private message Visit poster's website
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Sun Dec 18, 2016 4:45 pm    Post subject: Reply with quote

Yes, of course, but I would have expected a compile time error, not a run-time error. Gfortran says: Error: Symbol 'record_fileunit' at (1) is already in a COMMON block.

I can now see why you added the PRINT statement with LOC() -- the compiler built the application with no error messages!

I hope Paul will have this case looked at.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Mon Dec 19, 2016 3:30 pm    Post subject: Reply with quote

Thanks for the feedback. I have made a note that the compiler should trap this error.
Back to top
View user's profile Send private message AIM Address
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Mon Jan 30, 2017 2:46 pm    Post subject: Reply with quote

This has now been fixed for the next release.
Back to top
View user's profile Send private message AIM Address
wahorger



Joined: 13 Oct 2014
Posts: 1217
Location: Morrison, CO, USA

PostPosted: Tue Jan 31, 2017 12:51 am    Post subject: Reply with quote

Thanks, Paul!
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group